• Tidak ada hasil yang ditemukan

BAB 2 LANDASAN TEORI

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB 2 LANDASAN TEORI"

Copied!
44
0
0

Teks penuh

(1)

7

LANDASAN TEORI

2.1 Teori Database

2.1.1 Pengertian Data

Pengertian Data menurut Whitten et al. (2004, p23), data adalah fakta mentah mengenai orang, tempat, kejadian, dan hal-hal penting yang dalam organisasi. Tiap fakta, tanpa disertai fakta lainnya, secara relatif tidak ada artinya.

Pengertian Data menurut Atzeni et al. (2003, p2) data adalah merupakan suatu bentuk penyimpanan informasi yang harus diterjemahkan terlebih dahulu untuk menghasilkan informasi.

Data sendiri tidak mempunyai makna, tetapi setelah diterjemahkan dan dihubungkan dengan benar, data menghasilkan informasi yang memungkinkan kita dalam meningkatkan pengetahuan.

2.1.2 Pengertian Sistem

Pengertian sistem menurut pendapat O’Brien (2002, p8) sistem secara sederhana dapat diartikan sebagai sebuah kumpulan dari elemen – elemen yang saling berhubungan atau berinteraksi yang menbentuk suatu kesatuan.

Pengertian sistem menurut Mulyadi (1997, p2) pada dasarnya sistem adalah sekelompok unsur yang berhubungan erat satu dengan yang lainnya, yang berfungsi untuk mencapai tujuan tertentu.

(2)

2.1.3 Pengertian Database dan Sistem Database

Menurut Atzeni et al. (2003, p2) database adalah suatu koleksi data, digunakan dalam menampilkan informasi yang diinginkan kepada sebuah sistem informasi.

Menurut Connoly dan Begg (2002, p14) database merupakan suatu kumpulan data yang terhubung secara logic, dan deskripsi dari data tersebut yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi. Artinya database merupakan tempat penyimpanan data yang besar, dimana dapat digunakan secara simultan oleh banyak pengguna.

2.1.4 Sistem Manajemen Database (DBMS)

Menurut Connolly dan Begg (2002, p16) DBMS adalah sebuah sistem Piranti lunak yang memungkinkan pengguna untuk mendefinisikan, menciptakan, memelihara, dan mengontrol akses ke dalam database.

Menurut Atzeni et al. (2003, p2) DBMS adalah sistem Piranti lunak yang mempunyai kemampuan untuk mengatur database yang sangat besar, terbagi, dan memastikan reabilitas dan keamanan data.

Menurut Connolly dan Begg (2002, p16) disebutkan bahwa DBMS menyediakan fasilitas-fasilitas sebagai berikut :

a. Data Definition Language ( DDL ) b. Data Manipulation Language ( DML )

(3)

c. Akses control, sebagai berikut :

a. Security system b. Integrity Sytem

c. Concurrency Control System d. Recovery Control Sytem e. User Accessible Catalog

2.1.5 Data Definition Language ( DDL )

Data Definition Language adalah bahasa yang memungkinkan administrator database atau pengguna untuk mendeskripsikan dan menamai

entitas, atribut, dan hubungan dari entitas yang dibutuhkan oleh aplikasi, bersama dengan semua batasan integritas dan keamanan yang terkait (Connolly dan Begg , 2002, p40)

2.1.6 Data Manipulation Language (DML)

Data Manipulation Language adalah bahasa yang menyediakan

kumpulan operasi untuk mendukung operasi manipulasi dan sederhana pada data yang tersimpan di dalam database. (Connolly dan Begg, 2002, p41)

(4)

Operasi dari Data Manipulation Language biasanya mencakup operasi seperti :

a. Memasukan data baru ke dalam database

b. Memodifikasi data yang tersimpan di dalam database c. Mengambil data yang tersimpan di dalam database d. Menghapus data dari database

2.1.7 Komponen dari Lingkungan DBMS

Menurut Connolly dan Begg (2002, p18) terdapat lima komponen utama di dalam suatu lingkungan DBMS. Lima komponen utama yang terdapat pada sistem manajemen database antara lain :

1. Hardware (Piranti Keras) 2. Software (Piranti Lunak) 3. Data

4. Procedures 5. People

Komponen terakhir pada DBMS adalah orang atau user yang terlibat dalam sistem tersebut, yang dapat dikelompokan menjadi tiga jenis user yaitu : a. Application programmer

b. End–User

(5)

2.1.8 Kelebihan dan kekurangan Sistem Database

Menurut Connolly dan Begg (2002, p25) sistem database mempunyai beberapa keuntungan antara lain :

a. Control of Data Redudancy b. Data Consistency

c. Sharing of Data

d. Improved Data Integrity e. Improved Scurity

f. Improved Data Accesibility and Responsiveness g. Increased Productivity

h. Increased Concurrency

i. Improved Backup dan Recovery Services

Sedangkan, menurut Connolly dan Begg (2002, pp29-30) sistem manajeman database juga memiliki beberapa kekurangan seperti :

a. Complexity b. Size

c. Cost of DBMS d. Cost of Conversion e. Performance

(6)

2.1.9 Model Relational Database Management System (RDBMS) 2.1.9.1 Struktur Data Relational (Connolly and Begg, 2002, p 72)

a. Relasi, direpresentasikan sebagai tabel b. Atribut adalah kolom pada tabel c. Tuple adalah baris pada tabel (record)

d. Domain adalah himpunan nilai dari satu atau lebih atribut e. Derajat (Degree) adalah banyaknya atribut/kolom pada tabel f. Cardinality adalah banyaknya tuple atau baris pada tabel

g. Relational Database adalah kumpulan relasi ternormalisasi dengan nama relasi yang jelas

Relasi Database 1. Skema relasi

Nama relasi didefinisikan oleh himpunan pasangan atribut dan nama domain

2. Skema Database Relasional

(7)

Sifat – sifat Relasi

1. Nama relasi berbeda satu sama lain dalam skema relasional 2. Setiap sel (baris, kolom) dari relasi berisi satu nilai atomik 3. Setiap atribut memiliki nama yang berbeda

4. Nilai suatu atribut berasal dari domain yang sama 5. Setiap tuple berbeda, dan tidak ada duplikasi tuple

Kunci Relasi (Relational Keys) 1. Superkey

Sebuah atribut atau himpunan yang mengidentifikasi secara unik

tuple – tuple yang ada dalam relasi

2. Candidate key

Superkey yang tidak bisa di urai lagi, tidak bisa di komposisi

3. Primary key

Candidate key yang dipilih untuk identifikasi tuple secara unik

dalam suati relasi 4. Alternate key

Candidate key yang tidak terpilih sebagai primary key

5. Foreign key

Atribut atau himpunan atribut dalam relasi yang dibandingkan dengan candidate key pada beberapa relasi

(8)

2.1.9.2 Integrasi Relasi (Relational Integrity)

Menurut Connolly and Begg (2002, p81) integrasi relasi terbagi atas:

a. Null

b. Entity Integrity

Pada relasi dasar, tidak ada atribut ataupun primary key yang bernilai Null

c. Referential Integrity

Jika terdapat foreign key dalam suatu relasi, maka nilai foreign key tersebut akan dibandingkan (match) dengan nilai candidate key dari beberapa tuple pada relasi itu sendiri atau nilai foreign key harus

Null seluruhnya. d. Enterprise Constraint

(9)

2.1.10 Entity Relationship Modelling Tipe Entitas (Entity Type)

Konsep dasar dari Model ER adalah tipe entitas, yaitu kumpulan dari objek-objek dengan sifat (properti) yang sama, yang diidentifikasi oleh enterprise mempunyai eksistensi yang independent. Keberadaannya dapat berupa fisik maupun abstrak.

Entity Occurrence, yaitu pengidentifikasian objek yang unik dari

sebuah tipe entity. Setiap entity diidentifikasikan dan disertakan propertinya.

Tipe Relasi (Relationship Type)

Tipe relasi adalah kumpulan keterhubungan yang mempunyai arti (meaningfull associations) antara entitas yang ada.

Relationship occurrence yaitu keterhubungan yang diidentifikasi secara

unik yang meliputi keberadaan tiap entitas yang berpartisipasi.

Derajat Tipe Relasi (Degree of Relationship Type)

Jumlah entitas yang berpartisipasi dalam suatu relationship. Derajat relasi terdiri dari :

1. Binary Relationship 2. Ternary Relationship 3. Quartenary Relationship 4. Unary Relationship

(10)

Atribut

Merupakan sifat-sifat (properti) dari sebuah entitas atau tipe relasi. Atribut domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Macam-macam atribut :

1. Simple Attribute 2. Composite Attribute 3. Single-valued Attribute 4. Multi-valued Attribute 5. Derived Attribute Kunci (Keys) 1. Candidate Key

Jumlah minimal atribut-atribut yang dapat mengidentifikasikan setiap kejadian / record secara unik.

2. Primary Key

Candidate key yang dipilih untuk mengidentifikasikan setiap kejadian / record dari suatu entitas secara unik.

3. Composite Key

Candidate key yang terdiri dari dua atau lebih atribut.

Strong and Weak Entity Types

Strong entity type yaitu entitas yang keberadaannya tidak bergantung

(11)

sedangkan weak entity type adalah entitas yang keberadaannya bergantung pada entitas lain, dan juga sering disebut child, dependent, subordinate.

Structural Constraint

Batasan utama pada relationship disebut dengan multiplicity, yaitu jumlah (range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relasi. Relasi yang paling umum adalah binary relationship. Macam-macam

binary relationship antara lain :

1. one – to – one ( 1 : 1 )

Relasi dari Karyawan mengatur Cabang 2. one – to – many ( 1 : * )

Relasi dari Karyawan melayani Konsumen 3. many – to – many ( * : *)

Relasi Koran mengiklankan Produk

Multiplicity dibentuk dari dua macam batasan pada relasi : 1. Cardinality

Menjelaskan jumlah maksimum dari kejadian relasi yang mungkin untuk entitas yang berpartisipasi di dalam relasi tersebut.

2. Participation

Menetapkan apakah seluruh atau sebagian entitas yang berpartisipasi dalam suatu relasi.

(12)

Masalah pada ER Modelling

Beberapa masalah yang dihadapi dengan model ER diantaranya :

1. Fan Traps

Fan traps adalah sebuah kondisi dimana sebuah model

merepresentasikan sebuah relasi antara tipe entitas, tetapi jalur antara entitas ambigu.

2. Chasm Traps

Chasm traps adalah kondisi dimana sebuah model menunjukan

keberadaan suatu relasi antar tipe entitas, tetapi jalurnya tidak terdapat antara occurrence entitas tertentu.

2.1.11 Normalisasi

Normalisasi merupakan sebuah teknik untuk menghasilkan sebuah kumpulan dari relasi-relasi dengan atribut-atribut yang diinginkan, berdasarkan kebutuhan data perusahaan. (Connolly and Begg, 2002, p376) Tahapan-tahapan normalisasi, antara lain :

1. Bentuk Normal pertama (1NF)

Sebuah tabel dinyatakan mempunyai bentuk normal pertama jika sebuah tabel memiliki domain yang sederhana dan tidak terdapat

repeating group. Jadi aturan yang berlaku pada 1NF adalah

mendefinisikan primary key, tidak adanya repeating group, dan semua atribut non-key harus bergantung pada atribut primary key.

(13)

2. Bentuk Normal kedua (2NF)

Bentuk ini mempunyai syarat yaitu data harus memenuhi kriteria 1NF dan tidak memiliki ketergantungan parsial (data hanya bergantung pada sebagian primary key). Jadi, bentuk normal kedua adalah berdasarkan konsep full funcional dependency (ketergantungan fungsional secara utuh) pada seluruh primary key dari relasi tersebut. 3. Bentuk Normal Ketiga (3NF)

Sebuah tabel dikatakan memenuhi bentuk normal ketiga jika semua atribut non-key dari suatu relasi bersifat mutually independent. Dengan demikian tidak ada atribut non-key yang bersifat functional dependent terhadap atribut non-key yang lain. Jadi aturan yang berlaku adalah harus sudah berada dalam bentuk normal kedua dan tidak ada ketergantungan transitif (dimana field non-key tergantung pada field non-key lainnya.)

2.1.12 Siklus Hidup Database

Siklus Hidup Database merupakan komponen mendasar suatu sistem informasi, dimana pengembangan atau pemakaiannya harus dilihat dari perspektif yang lebih luas berdasarkan kebutuhan organisasi.

(14)

Database Planning Physical Database Design Logical Database Design Conceptual Database Design Requirements Collection and Analysis System Definition Database Design Testing Data Conversion and

Loading Implementation Prototyping (optional) DBMS Selection (optional) Application Design Operational Maintenance

(15)

1. Database Planning (Perencanaan database)

Merupakan aktivitas manajemen yang memungkinkan tahapan dari siklus hidup database direalisasikan sebaik mungkin. Perencanaan database harus terintegrasi dengan keseluruhan strategi sistem informasi dari organisasi.

2. System Definition (Definisi Sistem)

Menjelaskan batasan-batasan dan cakupan dari aplikasi database dan sudut pandang user (user view) yang utama. User view mendefinisikan apa yang diwajibkan dari suatu aplikasi database dari perspektif aturan kerja khusus (seperti manajer atau supervisor) atau area aplikasi interface (seperti marketing, personalia, atau stock control). Aplikasi database dapat memiliki satu atau lebih user view.

3. Requirement Collection and Analysis (Analisis dan Pengumpulan Kebutuhan)

Suatu proses pengumpulan dan analisa informasi mengenai bagian organisasi yang didukung oleh aplikasi database, dan menggunakan informasi tersebut untuk identifikasi kebutuhan user akan sistem yang baru.

(16)

4. Database Design

Merupakan suatu proses pembuatan, sebuah desain database yang akan mendukung tujuan dan operasi suatu enterprise. Tujuan utamanya adalah merepresentasikan data dan relasi antar data yang dibutuhkan oleh seluruh area aplikasi utama dan user group, menyediakan model data yang mendukung segala transaksi yang diperlukan pada data, dan menspesifikasikan desain minimal yang secara tepat disusun untuk memenuhi kebutuhan performa yang ditetapkan pada sistem (misal waktu respon).

Pendekatan dalam desain database, antara lain : a. Top-down

b. Bottom-up c. Inside-out d. Mixed

Data Modelling memiliki dua kegunaan utama, yaitu membantu

dalam memahami arti (semantik) dari data dan memfasilitasi komunikasi mengenai informasi yang dibutuhkan. Pembuatan model data dapat menjawab pertanyaan mengenai entitas, relasi dan atribut.

Tiga fase desain database:

a Conceptual database design b Logical database design c Physical database design

(17)

5. DBMS selection (optional)

Pemilihan DBMS yang tepat untuk mendukung aplikasi database. Dapat dilakukan kapanpun sebelum menuju desain logikal asalkan terdapat cukup informasi mengenai kebutuhan sistem.

6. Application Design (Desain Aplikasi)

Desain user interface dan program aplikasi yang menggunakan dan memproses data. Desain database dan aplikasi merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu transaction design dan

user interface design.

7. Prototyping (optional)

Membuat model karya suatu aplikasi database. Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu requirement

prototyping dan evolutionary prototyping

8. Implementation

Merupakan realisasi fisik dari database dan desain aplikasi. Implementasi

database dicapai dengan menggunakan :

1. DDL untuk membuat skema database dan file database yang kosong. 2. DDL untuk membuat user view yang diinginkan.

3. 3GL dan 4GL untuk membuat program aplikasi, termasuk transaksi

database disertakan dengan menggunakan DML, atau ditambahkan

(18)

9. Data Conversion and Loading

Pemindahan data yang ada kedalam database baru dan mengkonversikan aplikasi yang ada agar dapat digunakan pada database yang baru. Tahapan ini dibutuhkan ketika sistem database baru menggantikan sistem yang lama. DBMS biasanya memiliki utilitas yang memanggil ulang file yang sudah ada kedalam database baru.

10. Testing

Suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Pengujian hanya akan terlihat jika terjadi kesalahan database.

11. Operational maintenance

Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi meliputi :

a. Pengawasan performa sistem, jika performa menurun, maka memerlukan perbaikan atau pengaturan ulang database.

b. Pemeliharaan dan pembaharuan aplikasi database (jika dibutuhkan). c. Penggabungan kebutuhan baru kedalam aplikasi database.

2.1.13 Desain Metodologi Konseptual, Logikal, dan Fisikal Database

Desain metodologi adalah pendekatan terstruktur yang menggunakan prosedur, teknik, tools, dan dokumentasi untuk mendukung dan memfasilitasi proses desain. (Connolly and Begg, 2002, p418)

(19)

Menurut Connolly dan Begg (2002, pp422-502), proses perancangan dibagi ke dalam tiga tahap utama, yaitu tahap konseptual, tahap logikal, dan tahap fisikal. Langkah-langkah dalam perancangan database adalah sebagai berikut:

a. Desain Konseptual Database

Perancangan konseptual database merupakan proses membangun model dari data yang digunakan pada perusahaan, terbebas dari semua pertimbangan fisikal, seperti tujuan DBMS, program aplikasi, bahasa pemrograman yang digunakan, platform piranti keras, masalah tampilan. (Connolly and Begg, 2002, p)

Perancangan konseptual database meliputi langkah-langkah sebagai berikut :

Langkah 1 : Membangun model data konseptual database untuk setiap view

1.1 Identifikasi tipe entitas

Tujuannya adalah untuk mengidentifikasikan tipe-tipe entitas yang dibutuhkan. (Connolly and Begg, 2002, p424))

Langkah pertama adalah mendefinisikan objek-objek utama di mana pengguna mempunyai ketertarikan dengan objek tersebut. Objek-objek inilah yang disebut tipe-tipe entitas untuk model.

(20)

1.2 Identifikasi tipe relationship

Tujuannya untuk mengidentifikasikan hubungan atau

relationship penting yang ada di antara tipe-tipe entitas yang telah

diidentifikasikan. (Connolly and Begg, 2002, p424)

1.3 Mengidentifikasi dan menghubungkan atribut dengan entitas atau tipe relationship

Tujuannya untuk menghubungkan atribut dengan entitas atau tipe relationship yang sesuai dan mendokumentasikan detail dari setiap atribut.

1.4 Menentukan domain atribut

Tujuannya untuk menentukan domain untuk atribut-atribut dalam model data konseptual lokal. Selain itu, juga didokumentasikan setiap detail dari domain tersebut. Domain merupakan sekumpulan nilai-nilai dari satu atau lebih atribut yang menggambarkan nilai yang dimiliki.

1.5 Menentukan atribut candidate key, primary key, dan alternate key Tujuannya adalah untuk mengidentifikasikan candidate key untuk setiap tipe entitas, jika terdapat lebih dari satu candidate key, pilih satu untuk dijadikan primary key dan yang lainnya sebagai

alternate key.

Cara untuk memilih primary key dari candidate key adalah sebagai berikut:

a. Candidate key dengan set atribut yang minimal b. Candidate key yang nilainya jarang berubah

(21)

c. Candidate key yang karakternya paling sedikit

d. Candidate key yang mempunyai nilai maksimum paling kecil e. Candidate key yang mudah digunakan dari sudut pandang

user

1.6 Mempertimbangkan penggunaan konsep enchanced modelling (optional)

Tujuannya untuk mempertimbangkan penggunaan dari konsep

enchanced modelling seperti spesialisasi, generalisasi, agregasi

(aggregation), dan komposisi (composition). 1.7 Memeriksa model dari redudancy

Tujuannya adalah untuk memeriksa apabila ada redundancy pada model data. Pada langkah ini, model konseptual diuji untuk memeriksa apakah terdapat redudancy atau perulangan dalam data dan memindahkannya jika ada. Pada langkah ini terdapat dua aktivitas, yaitu:

a. Menguji ulang hubungan one-to-one b. Menghilangkan hubungan yang redundan c. Mempertimbangkan dimensi waktu

1.8 Memvalidasi model konseptual dari transaksi pengguna (user) Tujuannya untuk memastikan apakah model konseptual telah mendukung transaksi yang dibutuhkan oleh perusahaan.

Untuk memastikan bahwa model data lokal konseptual benar-benar mendukung transaksi di view, digunakan dua macam pendekatan, yaitu:

(22)

a. Mendeskripsikan transaksi-transaksi

b. Menggunakan jalur-jalur (pathway) transaksi 1.9 Me-review model data konseptual dengan pengguna

Tujuannya adalah untuk memastikan bahwa model tersebut sudah merupakan representasi sebenarnya dari permintaan data oleh perusahaan.

Model data konseptual juga mencakup diagram ER dan dokumentasi pendukung yang mendeskripsikan model data. Bila terdapat kejanggalan pada model data, maka harus dibuat perubahan yang sesuai.

b. Desain Logikal Database

Tujuan dari tahapan ini yakni menerjemahkan model data menjadi sebuah model data logikal dan kemudian memvalidasi model tersebut untuk memeriksa apakah strukturnya sudah tepat dan mampu mendukung transaksi-transaksi yang dibutuhkan.

Desain logikal database terdiri dari langkah-langkah sebagai berikut:

Langkah 2 : Membangun dan memvalidasi model data lokal logikal untuk setiap view

2.1 Menghilangkan fitur-fitur yang tidak sesuai dengan model relasional

Tahap ini merupakan tahap penyesuaian dari model data lokal konseptual agar bisa digunakan dengan lebih mudah oleh sistem.

(23)

Penghilangan fitur yang tidak kompatibel memiliki empat tahapan, yaitu:

a. Menghilangkan relasi many to many ( *:* )

b. Menghilangkan relasi rekursif many to many ( *:* ) c. Menghilangkan tipe relasi kompleks

d. Memindahkan atribut multi-valued

2.2 Mendapatkan relasi untuk model data logikal

Tujuannya membuat hubungan untuk model data logikal untuk merepresentasikan entitas-entitas, relationships, dan atribut-atribut yang sudah diidentifikasi.

Relasi yang dimiliki oleh setiap entitas ditunjukkan oleh mekanisme dari primary key atau foreign key.

2.3 Memvalidasi transaksi dengan menggunakan normalisasi

Pada tahap ini, dilakukan validasi terhadap transaksi di model data lokal logikal menggunakan teknik normalisasi untuk mengembangkan model data sehingga terhindar dari duplikasi data yang tidak diperlukan.

2.4 Memvalidasi relasi dengan transaksi pengguna

Tujuannya adalah untuk memastikan bahwa hubungan-hubungan dalam model data logikal mendukung transaksi yang dibutuhkan oleh view.

(24)

2.5 Mendefinisikan integrity constraints

Integrity constraint adalah batasan-batasan yang digunakan

untuk menjaga agar database tidak menjadi inkonsisten. Ada lima tipe dari integrity constraint, antara lain:

a. Required data ( data atau nilai yang valid ) b. Batasan atribut domain

c. Entity integrity ( primary key tidak boleh null ) d. Referential integrity

e. Enterprise contraint ( batasan pada organisasi ) 2.6 Memeriksa model data lokal logikal dengan pengguna

Pada tahap ini dilakukan kaji ulang untuk memastikan bahwa model data lokal logikal sudah sesuai dengan apa yang dibutuhkan oleh pengguna.

Langkah 3 : Membangun dan memvalidasi model data global logikal 3.1 Menggabungkan model data logikal

Pada tahap ini, digabungkan model data logikal individual ke dalam model data logikal global organisasi.

3.2 Memvalidasi model data global lokal

Memvalidasi relasi yang telah dibuat dari model data global dengan menggunakan teknik normalisasi dan memastikan bahwa relasi ini telah mendukung transaksi yang diperlukan.

(25)

3.3 Memeriksa untuk kemungkinan perubahan di masa mendatang Memastikan apakah ada perubahan yang signifikan yang dapat diperkirakan dan memastikan apakah model data logikal global ini dapat mendukung perubahan-perubahan ini.

3.4 Memeriksa model data global logikal dengan pengguna

Tujuan dari tahap ini adalah untuk memastikan bahwa model data logikal global merupakan representasi nyata dari organisasi.

c. Desain Fisikal Database

Perancangan database fisikal merupakan proses untuk menghasilkan suatu deskripsi mengenai implementasi dari database pada secondary

storage.

Deskripsi ini menjelaskan tentang hubungan dasar, file organisasi, dan indeks yang digunakan untuk mengakses data secara efisien, serta batasan-batasan integritas yang berhubungan dan pengukuran keamanan atau sekuriti.

Langkah-langkah dari merancang model data fisikal meliputi langkah-langkah sebagai berikut:

Langkah 4 : Menerjemahkan model data logikal untuk DBMS yang digunakan

Tujuannya untuk menghasilkan suatu skema database relasional dari model data logikal yang dapat diimplementasikan dalam target DBMS. Aktivitas-aktivitas dalam tahapan ini mencakup, antara lain:

(26)

4.1 Mendesain relasi dasar

Tujuannya untuk menentukan bagaimana representasi dari hubungan dasar diidentifikasikan dalam model data logika dalam target

DBMS.

4.2 Mendesain representasi dari derived data

Tujuannya untuk menentukan bagaimana merepresentasikan data yang dihasilkan dari model data logikal dalam target DBMS. Desain dari derived data harus didokumentasikan dengan tujuan untuk memilih rancangan yang sesuai. Contoh dari deriver atau calculated

attributes, misalnya jumlah karyawan yang bekerja di satu cabang

tertentu.

4.3 Mendesain batasan-batasan umum (general constraints)

Tujuannya untuk mendesain batasan-batasan umum untuk target

DBMS.

Rancangan dari batasan atau constraint ini tergantung dari pilihan DBMS, beberapa sistem menyediakan fasilitas lain daripada mendefinisikan batasan-batasan umum.

Langkah 5 : Mendesain gambaran fisik mengenai database

Tujuannya untuk menentukan organisasi file yang optimal untuk menyimpan hubungan dasar dan indeks yang dibutuhkan untuk mencapai hasil performa yang maksimal, yakni cara bagaimana relasi dan tuple disimpan di secondary storage.

(27)

5.1 Analisa transaksi-transaksi

Untuk membuat sebuah desain database fisikal yang efektif maka kita harus mengetahui transaksi atau query yang akan dijalankan dalam database.

5.2 Memilih organisasi file yang digunakan

Tujuannya adalah untuk menentukan organisasi file yang tepat untuk setiap relasi dasar. Salah satu dari tujuan utama dari perancangan database fisikal adalah untuk menyimpan dan mengakses data dengan cara yang efisien.

Ada lima tipe organisasi file, yakni Heap, Hash, Indexed

Sequenced Access Method (ISAM), B-Tree, Clusters.

5.3 Memilih indeks yang akan digunakan

Tujuannya untuk menentukan apakah menambahkan indeks akan meningkatkan performa dari sistem.

5.4 Memperkirakan disk space yang diperlukan

Tujuannya untuk memperkirakan jumlah ruang atau space dari disk yang akan dibutuhkan untuk mendukung implementasi database pada secondary storage.

Perkiraan perlu dibuat untuk menentukan apakah konfigurasi piranti keras yang telah ada mampu mendukung implementasi

(28)

1. Menghitung tempat penyimpanan untuk menyimpan data

Langkah-langkah yang dapat digunakan untuk memperkirakan jumlah tempat yang dibutuhkan untuk menyimpan data pada tabel :

a. Tentukan jumlah baris yang akan digunakan pada tabel : Jumlah baris pada tabel = Num_Rows

b. Jika terdapat panjang yang tetap dan variabel panjang kolom pada definisi tabel, hitung tempat penyimpanan untuk setiap kelompok kolom dalam baris data. Ukuran kolom tergantung pada tipe data dan perincian panjang. Banyaknya kolom =

Num_Cols dan banyaknya variabel panjang kolom = Num_Variable_Cols. Maksimal ukuran semua variabel

panjang kolom = Max_Var_Size.

c. Jika terdapat panjang kolom yang tetap pada tabel, sebuah bagian baris, dikenal dengan null bitmap, disiapkan menangani kemungkinan null pada kolom. Untuk menghitung ukurannya: Null Bitmap = 2 + ( ( Num_Cols + 7 ) / 8 ), hanya bilangan bulat pada ekspresi tersebut yang harus digunakan. d. Jika terdapat variabel panjang kolom pada tabel, tentukan

berapa banyak tempat penyimpan yang digunakan untuk menyimpan kolom dalam baris.

Total ukuran variabel panjang kolom (Variable_Data_Size) =

(29)

Jika tidak terdapat variabel panjang kolom jadikan

Variable_Data_Size menjadi nol.

e. Menghitung ukuran baris : Total Ukuran Baris (Row_Size) =

Fixed_per_page + Variable_Data_Size + Null_Bitmap + 4

Nilai akhir yaitu 4, mewakili header baris data.

f. Menghitung jumlah baris per halaman (8096 bytes per halaman) : Jumlah Baris per halaman (Row_per_page) =

(8096) / ( Row_Size + 2 )

g. Jika sebuah clustered index akan dibuat ada tabel, hitung jumlah baris cadangan yang kosong per halaman, tergantung pada penerapan fill factor. Jika tidak ada clustered index yang akan dibuat, tetapkan fill factor menjadi 100.

Banyaknya Baris yang Kosong per halaman

(Free_Rows_per_page) = 8096 x (( 100 – FillFactor ) / 100) / Row_Size

Fill Factor digunakan pada penghitungan nilai bilangan bulat

daripada persentase.

h. Menghitung banyaknya halaman yang dibutuhkan untuk menyimpan semua baris:

Banyaknya Baris (Num_Page) = Num_Rows /

(Rows_per_page – Free_Rows_per_page)

Perkiraan banyaknya halaman harus dibulatkan ke atas pada keseluruhan jumlah halaman terdekat.

(30)

i. Terakhir, menghitung jumlah tempat penyimpanan yang dibutuhkan untuk menyimpan data pada tabel (total 8192 bytes per halaman): Ukuran Tabel (Bytes) = 8192 x

Num_Pages

Tempat penyimpanan untuk menyimpan data =

Data_Space_Used

2. Menghitung tempat yang digunakan untuk menyimpan clustered index

Tahap-tahap yang dapat digunakan untuk memperkirakan jumlah tempat yang dibutuhkan untuk menyimpan clustered index

a. Penentuan clustered index dapat termasuk panjang yang tetap dan variabel panjang kolom untuk memperkirakan ukuran dari clustered index, harus menentukan tempat untuk setiap kelompok kolom yang ditempatkan dalam baris indeks.

Banyaknya kolom per kunci indeks = Num_Ckey_Size

Jumlah bytes pada semua panjang kolom kunci yang tetap =

Fixed_Ckey_Size

Maksimal ukuran semua variabel panjang kolom kunci =

Max_Var_Ckey_Size

b. Jika terdapat panjang kolom yang tetap pada clustered index, bagian pada baris indeks disiapkan untuk null bitmap, penghitungan ukuran : Index null bitmap

(31)

Hanya bagian bilangan bulat pada ekspresi di atas yang harus digunakan.

c. Jika terdapat variabel panjang kolom pada indeks, tentukan berapa banyak tempat penyimpanan yang digunakan untuk menyimpan kolom dalam baris indeks :

Total Ukuran Panjang Variabel Panjang Kolom (Vrbl_Ckey_Size) : 2 + (Num_Variabel_Ckey_Cols x 2) +

Max_Var_Ckey_Size

Jika tidak ada variabel panjang kolom, set

Variable_Ckey_Size jadi nol.

d. Menghitung ukuran kolom indeks

Total Ukuran Kolom Indeks (Cindex_Row_Size) =

Fixed_Ckey_Size + Variabel_Ckey_Size + Cindex_Null_Bitmap + 1 + 8

e. Menghitung banyaknya baris indeks per halaman (8096 bytes bebas per halaman) :

Banyaknya Baris Indeks per halaman (Cindex_Rows_per_page) = 8096 / ( Cindex_Row_size + 2 )

f. Menghitung banyaknya halaman yang dibutuhkan untuk menyimpan semua baris indeks pada tiap level indeks

Banyaknya Halaman (level 0) (Num_Pages_Clevel_0) =

(Data_Spaced_Used) / 8192 / Cindex_Rows_per_pages

Banyaknya Halaman (level 1) (Num_Pages_Clevel_1) =

(32)

Ulangi perhitungan yang kedua, membagi jumlah perhitungan halaman dari level n sebelumnya dengan Cindex_Rows_per_page sampai jumlah halaman untuk level n (Num_Pages_Clevel_n) sama dengan satu (halaman sumber

indeks). Sebagai contoh, untuk menghitung jumlah halaman yang dibutuhkan untuk level indeks kedua :

Banyaknya Halaman (level 2) (Num_Pages_Clevel_2) =

Num_Pages_Clevel_1 / Cindex_Rows_per_pages

Jumlahkan banyaknya halaman yang dibutuhkan untuk menyimpan setiap level indeks:

Total Banyaknya Halaman (Num_Cindex_Pages) =

Num_Pages_Clevel_0 + Num_Pages_Clevel_1 + Num_Pages_Clevel_2 + … + Num_Pages_Clevel_n

g. Menghitung ukuran dari clustered index (total 8192 bytes per halaman) : Ukuran clustered index (bytes) = 8192 x

Num_Cindex_pages

3. Menghitung tempat yang digunakan untuk menyimpan setiap tambahan clustered index

Tahap-tahap yang digunakan untuk memperkirakan jumlah tempat penyimpanan yang dibutuhkan untuk menyimpan setiap tambahan nonclustered index.

a. Definisi nonclustered index dapat termasuk panjang yang tetap. Untuk memperkirakan ukuran nonclustered index,

(33)

harus dihitung tempat penyimpanan untuk setiap kelompok kolom yang ditempatkan dalam baris indeks.

Banyaknya kolom pada kunci indeks = Num_Keys_Cols Jumlahkan bytes pada kunci indeks = Fixed_Key_Size

Banyaknya variabel panjang kunci kolom =

Max_Var_Key_Size

b. Jika terdapat panjang kolom yang tetap pada indeks, bagian baris indeks disimpan untuk menyimpan kolom dalam baris indeks.

Indeks Null Bitmap = 2 + ( ( Num_Keys_Cols + 7 ) / 8 ) Hanya bagian bilangan bulat pada ekspresi di atas harus digunakan.

c. Jika terdapat variabel panjang kolom pada indeks, tentukan berapa banyak tempat penyimpanan yang digunakan untuk menyimpan kolom dalam baris indeks:

Total Ukuran Variabel Panjang Kolom (Variable_Key_Size)

= 2 + (Num_Variable_Keys_Cols x 2) + Max_Var_key_Size

d. Menghitung ukuran baris indeks nonleaf

Total Ukuran Baris Indeks (NL_Index_Row_Size) =

Fixed_Key_Size + Variabel_Key_Size + Index_Null_Bitmap + 1 + 8

e. Menghitung banyaknya baris indeks nonleaf per halaman : Banyaknya baris indeks nonleaf per halaman

(34)

f. Menghitung ukuran baris indeks leaf

Total Ukuran Baris Leaf (Index_Row_Size) = Cindex_Row_Size + Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1

g. Menghitung jumlah baris indeks level leaf per halaman :

Jumlah Baris Indeks Level Leaf per halaman

(Index_Rows_Per_Page) = 8096 / ( Index_Row_Size +2 )

h. Menghitung jumlah baris indeks kosong cadangan per halaman berdasarkan pada fill factor yang ditetapkan untuk

nonclustered index

Jumlah Baris Indeks Kosong Cadangan per halaman

(Free_Indes_Rows_Per_Page) = 8096 x ( (100 – fill factor) / 100 ) / Index_Row_Size

Fill factor digunakan pada perhitungan sebuah nilai bulat

pada persentase.

i. Menghitung jumlah halaman yang dibutuhkan untuk menyimpan semua baris indeks pada tiap level indeks :

Jumlah Halaman (level 0) (Num_Pages_Level_0) =

Num_Rows / (Index_Rows_Per_Pages – Free_Index_Rows_Per_Page)

Jumlah Halaman (level 1) (Num_Pages_Level_1) =

(35)

Ulangi perhitungan kedua, membagi jumlah halaman dari

level n saebelumnya dengan NL_Index_Row_Per_Page

sampai jumlah halaman yang dibutuhkan untuk menyimpan setiap level indeks :

Total Jumlah Halaman (Nim_Index_Pages) =

Nim_Pages_Level_0 + Nim_Pages_Level_0 + … +

Nim_Pages_Level_n

j. Terakhir menghitung ukuran nonclustered index : Ukuran nonclustered index = 8192 x Num_Index_Pages 4. Menghitung ukuran tabel

Menghitung ukuran tabel (bytes) = Data_Space_Used +

Clustered_Index_Size + Nonclustered_Index_Size + … n

Langkah 6 : Merancang view dari pengguna (user views)

Tujuan dari langkah ini adalah untuk merancang view pengguna yang teridentifikasi selama pengumpulan permintaan dan tahap analisis dari siklus hidup perkembangan sistem database

Langkah 7 : Merancang mekanisme sekuriti

Tujuannya untuk merancang mekanisme sekuriti atau keamanan untuk database seperti yang telah diminta oleh pengguna pada tahapan awal siklus hidup perkembangan sistem database.

Relational DBMS menyediakan dua tipe dari keamanan database,

(36)

Langkah 8 : Mempertimbangkan pengenalan dari redundansi yang terkontrol

Dilakukan normalisasi dengan tujuan agar dapat menngkatkan performa dari sistem dengan menghilangkan redudansi.

Langkah 9 : Memonitor dan mengatur sistem operasional

Memonitor dan meningkatkan performa dari sistem dengan memperbaiki desain yang tidak sesuai atau perubahan kebutuhan.

2.1.14 Fourth Generation Language (4GLs)

Menurut Connolly dan Begg (2002, p42), dibandingkan dengan 3 rd GL yang merupakan bahasa pemrograman prosedural, 4th GL merupakan bahasa pemrograman non prosedural : user mendefinisikan apa yang akan dilakukan dan bukan bagaimana.

Keunggulan yang ditawarkan oleh 4th GL adalah penggunaan baris kode yang lebih sedikit dibanding 3rd GL yang berarti peningkatan produktifitas. Contoh dari 4th GL : SQL.

2.1.15 Cross Functional Flowchart

Flowchart yang menggambarkan hubungan suatu proses dengan orang yang bertanggungjawab terhadap proses. Proses yang terjadi dimasukkan ke dalam kolom berdasarkan orang yang bertanggungjawab terhadap proses tersebut.

(37)

2.1.16 State Transition Diagram

Menurut Yourdan (1989, p259), State Transition Diagram (STD) merupakan sebuah perilaku model yang bergantung pada sekumpulan keadaan sistem, dimana keadaan tersebut adalah setiap modus perilaku sistem yang diamati. Komponen-komponen utama dalam STD antara lain :

1. Keadaan sistem (system state)

Merupakan keadaan yang terjadi di dalam sistem pada waktu tertentu. Keadaan sistem dilambangkan dengan bentuk seperti gambar berikut.

Gambar 2.2 Notasi Keadaan Sistem

2. Perubahan keadaan (change of state)

Gambar 2.3 Notasi Perubahan Keadaan

3. Kondisi dan aksi

(38)

Menurut Pressman (2001, p317), State Transition Diagram (STD) menggambarkan kebiasaan dari suatu sistem dengan menggambarkan kondisi dan kejadian yang menyebabkan perubahan suatu kondisi. Selain itu, dapat dikatakan State Transition Diagram menunjukan aksi apa yang diambil sebagai akibat dari suatu kejadian.

2.2 Teori-teori Khusus Berhubungan dengan Topik

2.2.1 Manajemen Kantor

Mengutip dari http://hadisugito.fadla.or.id, yang dimaksud dengan manajemen kantor adalah studi tentang perencanaan, pengorganisasian, pengarahan, pengkoordinasian dan pengawasan pekerjaan ketatausahaan untuk mencapai tujuan yang telah diperkirakan.

Dua arti manajemen kantor dilihat dari :

1. Sudut manajemen, manajemen kantor merupakan kegiatan untuk

merencanakan, mengarahkan, mengendalikan, mengkoordinasikan, mengawasi, mengurus, menyempurnakan dan

menertibkan tatausaha kantor.

2. Sudut sasaran, manajemen kantor adalah segala kegiatan penataan yang ditujukan kepada segala hal yang berhubungan dengan pelaksanaan tatausaha dalam sistem perkantoran untuk mencapai sasaran organisasi.

(39)

2.2.1.1 Fungsi Kantor

Fungsi - fungsi kantor yang bersifat kepemerintahan yaitu :

1. Untuk menerima keterangan berupa surat-surat, warkat-warkat dan lain-lain.

2. Untuk mencatat keterangan.

3. Untuk menyusun keterangan : pembukuan, inventarisasi, perbekalan.

4. Untuk memberi keterangan.

5. Untuk menjamin barang-barang yang ada di dalam kantor. Fungsi - fungsi kantor yang bersifat perusahaan :

1. Untuk menerima keterangan berupa surat-surat, warkat-warkat dan lain-lain.

2. Untuk mencatat keterangan.

3. Untuk menyusun keterangan : pembukuan, inventarisasi, perbekalan.

4. Untuk memberi keterangan.

5. Untuk menjamin barang - barang yang ada di dalam kantor.

6. Melengkapi tujuan pokok perusahaan, misalnya : penyusunan upah, metode pelaksanaan, dan produktivitas.

2.2.1.2 Aspek Manajemen Kantor

1. Tujuan, yang dapat dirumuskan untuk menilai dan menetapkan keberhasilan mengarahkan dan mengkoordinasian elemen-elemen manajemen.

(40)

2. Organisasi, meliputi kegiatan pembentukan staf dan alokasi tugas untuk staf tersebut.

3. Metode, adalah urutan pelaksanaan bagaimana dana di mana pelaksanaan manajemen dilangsungkan.

4. Personalia, meliputi perekrutan staf, tempat, latihan, dan penghentian karyawan.

5. Lingkungan, meliputi bangunan kantor, perabot dan kondisi jasmani di dalam kantor.

6. Mesin dan perlengkapan, mencakup segenap benda mati yang digunakan dalam kantor untuk membantu pelaksanaan kerja.

2.2.2 Teori Pembelian

Pembelian adalah adalah keinginan membeli yang membutuhkan banyak pemahaman (www.thefreedictionary.com).

Menurut Render pembelian adalah perolehan barang dan jasa. Transaksi dalam pembelian dibedakan menjadi dua jenis, yaitu:

1. Pembelian tunai, yaitu jenis transaksi di mana pembayaran langsung dilakukan pada saat penerimaan barang.

2. Pembelian kredit, yaitu jenis transaksi di mana pembayaran tidak dilakukan pada saat penyerahan barang, tetapi dilakukan selang beberapa waktu sesuai perjanjian dengan pihak pemasok.

(41)

Sedangkan beradasarkan jenis pemasok, pembelian dibedakan menjadi dua jenis , yaitu:

1. Pembelian lokal, yaitu pembelian dari pemasok dalam negeri. 2. Pembelian impor, yaitu pembelian yang dilakukan dari pemasok

luar negeri.

Menurut Mulyadi (20001,p299), fungsi yang terkait dalam sistem pembelian adalah:

1. Fungsi gudang, bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan.

2. Fungsi pembelian, bertanggung jawab utnuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih.

3. Fungsi penerimaan, bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima oleh perusahaan.

4. Fungsi akuntansi, yang berkaitan dengan fungsi pencatatan uang dan pencatatan persediaan.

(42)

2.2.3 Teori Persediaan

Persediaan adalah suatu aktiva yang meliputi barang – barang milik perusahaan dengan maksud untuk dijual dalam suatu periode usaha yang normal. (http://library.gunadarma.ac.id/)

Sedangkan menurut Mulayadi (2001, p579) fungsi yang terkait dalam sistem perhitungan fisik persediaan adalah:

1. Panitia perhitungan fisik persediaan

Panitia ini berfungsi untuk melaksanakan perhitungan fisik persediaan dan menyerahkan hasil perhitungan tertentu kepada bagiankartu persediaan unutk digunakan sebagai dasar adjustment terhadap catatan persediaan dalam kartu persediaan.

2. Fungsi akuntansi

Dalam sistem perusahaan fisik persediaan, fungsi ini bertanggung jawab untuk:

a. Mencantumkan harga pokok pokok satuan persediaan yang dihitung ke dalamdaftar hasil perhitungan fisik.

b. Mengalihkan kuantitas dan harga pokok per satuan yang tercantum dfatar hasil perhitungan fisik.

c. Mencantumkan harga pokok total dalam daftar hasil perhitungan fisik persediaan.

d. Melakukan adjustment terhadap kartu persediaan

(43)

e. Membuat bukti memorial untuk mencatat adjustment data persediaan dalam jurnal umum berdasarkan hasil perhitungan fisik persediaan.

3. Fungsi Gudang

Dalam sistem perhitungan fisik persediaan, fungsi gudang bertanggung jawab untuk melakukan adjustment data kuantitas persediaan yang dicatat dalam kartu gudang berdasarkan hasil perhitungan fisik.

2.2.4 Office Automation

Mengutip dari Wikipedia.org, yang dimaksud dengan Office

Automation adalah mesin-mesin terkomputerisasi atau software yang

secara digital digunakan untuk membuat, mengumpulkan, menyimpan, memanipulasi dan menampilkan informasi-informasi yang dibutuhkan di suatu organisasi untuk menyelesaikan tugas dan tujuan tertentu. Penyimpanan data mentah, transfer data secara elektronik, serta manajemen informasi secara elektronik dari suatu bisnis merupakan aktifitas dasar dari suatu sistem Office Automation. Office Automation mengoptimalkan dan mengotomatisasi prosedur-prosedur kantor yang sebelumnya.

Yang menjamin kelangsungan suatu Office Automation adalah LAN, yang memungkinkan user untuk saling mengirim data, mail, bahkan suara di dalam suatu jaringan. Semua fungsi-fungsi dalam suatu

(44)

kantor, seperti mengetik, mengisi, mengcopy, fax, telex, mikrofilm dan manajemen arsip, telepon termasuk ke dalam kategori ini.

LAN sendiri adalah suatu jaringan komputer yang menjangkau sebagian kecil area seperti rumah, kantor, atau dalam gedung. Diharapkan dengan adanya LAN, semua bagian yang berada dalam ruang lingkup skripsi ini dapat saling terhubung dan saling bertukar data serta informasi

2.2.5 Microsoft Visual Basic

Microsoft Visual Basic adalah sebuah bahasa pemrograman untuk windows dan internet untuk membuat suatu sistem aplikasi. Visual Basic

sama seperti Pascal dan C tetapi tidak berjalan pada operasi MS-DOS.

2.2.6 Crystal Report

Crystal Report adalah tool untuk membuat laporan yang akurat,

karena di dalamnya banyak sekali fitur-fitur yang memudahkan dalam membuat laporan. User dapat membuat laporan sesuai dengan yang dibutuhkan dan mengubah fitur dari laporan tanpa report designer. User juga dapat membuat variasi dari laporan dengan menyimpan file RPT yang dimodifikasi dengan nama lain.

Gambar

Gambar 2.1 Database Application Lifecycle

Referensi

Dokumen terkait

Hasil deteksi tebing yang terakhir di atas masih berupa citra aras keabuan, untuk mengubahnya menjadi citra biner dapat digunakan operasi thresholding, atau dapat juga

Hal tersebut sejalan dengan hasil penelitian yang menujukkan faktor paling dominan dengan kasus difteri di Puskesmas Bangkalan tahun 2016, yaitu seorang anak yang

Skor hidung berair selama 8 minggu kelompok BCG dan kontrol Gambar 4 tampak skor gejala hidung berair juga terjadi penurunan dengan perbedaan bermakna baik pada kelompok BCG

Setiap program CD yang dilakukan PT Indo Tambangraya Megah memberikan kontribusi nyata dalam pemberdayaan masyarakat untuk mencapai keberlanjutan dan kemandirian,

Surfaktan anionik bereaksi dengan biru metilen membentuk pasangan ion berwarna biru yang larut dalam pelarut organik. Intensitas warna biru yang terbentuk diukur dengan

telah terjadi pisah tempat tinggal selama 6 bulan;--- Menimbang, bahwa dari fakta-fakta tersebut diatas, maka Majelis Hakim berpendapat bahwa rumah tangga antara

 Menemukan berbagai perangkat lunak program aplikasi berbasis pengolah angka  Menemukan berbagai perangkat lunak program aplikasi berbasis pengolah grafis  Menemukan

Laju pendinginan yang maksimum tidak akan tercapai dengan metode ini, sehingga tujuan pembentukan baja yang seluruh bagiannya bermikrostruktur martensit (untuk baja karbon