ARSIP BULANAN : November 2012

NORMALISASI BASIS DATA

20 November 2012 19:13:03 Dibaca : 478

NORMALISASI BASIS DATA

       https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcRY5qkA3TTMV-zhsJTPOzJ60-ik_7C0OIuVtEw6Y-VjywmsGLyu

    Sebelum berbicara tentang normalisasi pada database, adakalanya kita mengetahui dahulu apa itu database. DataBase (basis data dalam bahasa indonesia) dapat diartikan sebagai kumpulan sejumlah data berupa informasi yang disimpan dengan struktur yang sedemikian rupa sehingga dapat diolah kemudian dengan mudah. Sedangkan untuk membuat suatu database yang harus diperhatikan adalah jenis data;

 

* Data Master, yaitu data yang sifatnya tidak selalu berubah-ubah. Data master ini digunakan sebagai pendukung di dalam proses input transaksi.

 

* Data Transaksi, yaitu data yang akan selalu muncul dan berubah. Data transaksi ini selalu bergantung kepada master.

      https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcTT5lcb3_pCNNfgxOCyYgHCB_yhUF8wZ-HOWxyaRvXV54V5-ndm

Normalisasi Pada Database,

Yang dimaksud dengan normalisasi pada database adalah proses pernormalan suatu database yang disusun agar menghindari terjadinya redudancy (kemubaziran data). Dalam melakukan normalisasi, ada beberapa tahap yang harus dilakukan,

 1. Unnormalized

 Pada tahap ini, kita mengambil seluruh data yang ada dan diperlukan dalam database itu sendiri. Misalnya pada contoh bon faktur di bawah ini,

Kita ambil data-data yang diperlukan pada database nantinya, sperti * Nama Supplier * Alamat Supplier * No. Telp. * No. Nota * Tanggal Transaksi * Kode Barang * Nama Barang * Harga * Quantity * Total * Subtotal * Pemberi * Penerima

 2. Normal Satu

 Pada tahap ini, kita bagi seluruh data yang diperlukan menjadi beberapa bagian berdasarkan jenis data tersebut,

 Supplier * Nama Supplier * Alamat * No. Telp.

 Transaksi * No. Nota * Kode Barang * Tanggal Transaksi * Nama Barang * Harga Barang * Satuan * Quantity * Total * Sub Total

 3. Normal Dua

 Pada tahap ini, kita bagi berdasarkan jenis dan memberikan primary key pada masing-masing tabel,

 Supplier * Kode Supplier * Nama Supplier * Alamat * No. Telp.

 Master Barang * Kode Barang * Nama Barang * Harga * Satuan

 

Transaksi * No. Nota * Tanggal Transaksi * Kode Barang * Nama Barang * Harga * Satuan * Quantity * Pemberi * Penerima

 4. Normal Tiga

 Pada tahap ini, kita bagi menjadi lebih terperinci untuk menghindari terjadinya redudancy,

 Supplier * Tetap

 Master Barang * Tetap

 Transaksi Dibagi menjadi: Header Transaksi * No. Nota * Tanggal Transaksi * Kode Supplier * Pemberi * Penerima

Detail Transaksi * No. Nota * Kode Barang * Quantity

 Syarat perlunyya normalisasi:

·  Fleksibilitas

Struktur database harus menunjang semua cara untuk menampilan data, sehingga ketika user menjalankan aplikasi dan meminta sesuatu dalam datbase, database harus dapat berjlan memenuhi permintaan user.

·  integritas data

Semua data dalam database yang berkaitan harus terhubung dalam suatu relationship. Sehingga ketika suatu data berubah,maka semua data yang berkaitan dengan data tersebut harus dapat berubah secara otomatis.

·  Efficiency

Pada database, ukuran suatu database merupakan hal yang penting. Maka dalam database, kita harus mengurangi redudansi data yang bisa menyebabkan ukuran databse membengkak.

·  Menghindari modification anomaly

Desain database yang baik menyajikan suatu keyakinan bahwa ketika user melakukan perubahan dalam database, maka tidak terjadi hal yang tidak diinginkan.

Kapan tidak memakai normalisasi

·  ketika kita ingin mempertahankan kesederhanaan database, sehingga user dapat melakukan query sendiri.

·  jika tidak ingin melakukan query yang rumit. normalisasi biasanya akan membuat rumit query karena melibatkan banyak tabel.

·  tidak selamanya normalisasi membuat baik, malah akan menyebabkan database semakin buruk

Keuntungan dari normalisasi, yaitu :1. Meminimalkan ukuran penyimpanan yang diperlukan untuk menyimpan data.2. Meminimalkan resiko inkonsistensi data pada basis data3. Meminimalkan kemungkinan anomali pembaruan4. Memaksimalkan stabilitas struktur dataWELL STRUCTURE RELATION adalah sebuah relasi yang jumlah kerangkapan datanya sedikit (minimum Amount Of Redundancy), serta memberikan kemungkinan bagi user untuk melakukan INSERT, DELETE, dan MODIFY terhadap baris-baris data pada relation tersebut, yang tidak berakibat terjadinya ERROR atau INKONSESTENSI DATA, yang disebabkan oleh operasi –operasi tersebutContoh :Terdapat sebuah relation Course, dengan ketentuan sbb:Setiap mahasiswa hanya boleh mengambil satu matakuliah saja.Setiap matakuliah mempunyai uang kuliah yang standar (tidak tergantung pada mahasiswa yang mengambil matakuliah tsb).

Konsep Penting dalam Teknik Normalisasi !a. Field/ Atribut KunciKunci - kunci ini pun dipergunakan Komponen Basis Data Relasional ..Super keyYaitu himpunan dari satu atau lebih entitas yang digunakan untuk mengidentifikasikan secara unik sebuah entitas dalam entitas set.Candidate keyYaitu satu attribute atau satu set minimal atribute yang mengidentifikasikan secara unik suatu kejadian yang spesifik dari entity.Primary keyYaitu satu atribute atau satu set minimal atribute yang tidak hanya mengidentifikasikan secara unik suatu kejadian yang spesifik tapi juga dapat mewakili setiap kejadian dari suatu entityAlternate KeyYaitu kunci kandidat yang tidak dipakai sebagai primary keyForeign keyyaitu satu atribute (atau satu set atribute) yang melengkapi satu relationship (hubungan yang menunjukkan ke induknya.dari entity.

Kebergantungan Fungsi1. Ketergantungan Fungsional (Fungsional Dependent)Keterkaitan antar hubungan antara 2 atribute pada sebuah relasi. Dituliskan dengan cara : A -> B, yang berarti :Atribute B fungsionality Dependent terhadap atribute A atau Isi (value) atribute A menentukan isi atribute BDefinisi dari functional dependent :Diketahui sebuah relasi R, atribute Y dari R adalah FD pada atribute X dari R ditulis R.X -> R.Y jika dan hanya jika tiap harga X dalam R bersesuaian dengan tepat satu harga Y dalam R2. Fully Functinaly Dependent (FFD)Suatu rinci data dikatakan fully functional dependent pada suatu kombinasi rinci data jika functional dependent pada kombinasi rinci data dan tidak functional dependent pada bagian lain dari kombinasi rinci data.

Definisi dari FDD:Atribute Y pada relasi R adalah FFD pada atribute X pada relasi R jika Y FD pada X tida FD pada himpunan bagian dari X3. Ketergantungan PartialSebagian dari kunci dapat digunakan sebagai kunci utama4. Ketergantungan TransitifMenjadi atribute biasa pada suatu relasi tetapi menjadi kunci pada realasi lain5. DeterminanSuatu atribute (field) atau gabungan atribute dimana beberapa atribute lain bergantung sepenuhnya pada atribute tersebut

Normalisasi database biasanya jarang dilakukan dalam database skala kecil, dan dianggap tidak diperlukan pada penggunaan personal. Namun seiring dengan berkembangnya informasi yang dikandung dalam sebuah database, proses normalisasi akan sangat membantu dalam menghemat ruang yang digunakan oleh setiap tabel di dalamnya, sekaligus mempercepat proses permintaan data.

Proses normalisasi model data dapat diringkas sebagai berikut:

a.       Menemukan entitas-entitas utama dalam model data.

b.      Menemukan hubungan antara setiap entitas.

c.       Menentukan atribut yang dimiliki masing-masing entitas.

Normalisasi model data dilakukan dengan mengikuti langkah-langkah sederhana, mengubahnya agar memenuhi apa yang disebut sebagai bentuk normal pertama, kedua, lalu ketiga secara berturutan.

                                  https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcRIqNIS5aEHEbdiBtPNdoA86ekpfPBCnaP0qVgathKQ9Ghxx575hA

Langkah-Langkah Normalisasi

 1.Bentuk Normal Pertama ( 1NF )

https://lh3.googleusercontent.com/_lZYWOmn8v6c/TXinKeF1j1I/AAAAAAAAARk/DEBPnUi97kw/b.jpg

Sebuah model data dikatakan memenuhi bentuk normal pertama apabila setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai. Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut adalah kandidat untuk menjadi entitas tersendiri.

 2.Bentuk Normal Kedua ( 2NF )

Tabel 1

https://lh6.googleusercontent.com/_lZYWOmn8v6c/TXinN_4yrqI/AAAAAAAAARw/wrdQiZ63DN8/c.jpg

Tabel 2

https://lh3.googleusercontent.com/_lZYWOmn8v6c/TXinLeT5zYI/AAAAAAAAARo/qnQEKRmEQbQ/d.jpg

Tabel 3

https://lh5.googleusercontent.com/_lZYWOmn8v6c/TXinMvcug0I/AAAAAAAAARs/h7fjXD8BNfU/e.jpg

Sebuah model data dikatakan memenuhi bentuk normal kedua apabila ia memenuhi bentuk normal pertama dan setiap atribut non-identifier sebuah entitas bergantung sepenuhnya hanya pada semua identifier entitas tersebut.

 

3.Bentuk Normal Ketiga (3NF)

          https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcT0rpDKHAbcjcU9rH754eLq6VSn5YQIrPnBqjO62VlRX53LHPtq

Tabel 1 dan 2 sudah memenuhi criteria bantuk 3NF, namun tidak untuk tabel 3, karena bila kita ingin merubah value bobot dari nilai, maka kita akan melakukan perubahan pada banyak record/baris yang lainnya. Sehingga pada bentuk 3NF, tabel 3 dapat dipecah lagi menjadi 2 tabel agar memenuhi kriteria bentuk 3NF.

Tabel 3a

https://lh3.googleusercontent.com/_lZYWOmn8v6c/TXinP3gvtaI/AAAAAAAAAR0/y-eYgNIfavo/f.jpg

Tabel 3b

https://lh6.googleusercontent.com/_lZYWOmn8v6c/TXinHfaQxwI/AAAAAAAAARc/3iixEQfSfSI/g.jpg

B.FIRST NORMAL FORM ( 1NF )

Implementasi 1-NF dari table data yang belum ternormalisasi di atas adalah dengan cara mengeliminasi keberadaan repeating groups dan dekomposisi relasi menjadi dua atau lebih dengan syarat “tidak boleh ada informasi yang hilang karena proses dekomposisi” Adapun caranya adalah :

1. Membuat 3 tabel yang memiliki fungsi sebagai berikut :

oTBFaktur, berfungsi untuk menyediakan atribut-atribut yang bersifat atomic dari tiap nomor faktur (ID_Faktur), seperti : Tanggal, Nama_Pelanggan, Total_Bayar, Diskon dan Nama_Petugas

oTBProduk, berfungsi untuk menyediakan atribut-atribut yang berulang atau tidak bernilai tunggal pada tiap nomor faktur (ID_Faktur), seperti : Nama_Barang dan harga

oTBTransaksiDetail, berfungsi sebagai penghubung antara nomor faktur (ID_Faktur) dengan kode barang (ID_Barang) agar proses dekomposisi tidak menyebabkan kerusakan informasi.

2. Menentukan type data dari tiap atribut dan membuat digram relasional sebagai berikut

3. Pada table TBTransaksiDetail terdapat atribut “Harga” yang berfungsi untuk menyimpan harga per transaksi, sedangkan atribut “Harga_Default” yang terdapat pada table TBProduk adalah atribut yang berfungsi untuk menyimpan harga barang terbaru dari tiap jenis barang.Hal ini berguna untuk mengantisipasi adanya perubahan harga dari waktu ke waktu.

4. Primary key yang digunakan pada TBTransaksiDetail adalah “ID_Transaksi”. Atribut kunci tersebut merupakan candidate key yang dibentuk dari superkey hasil penggabungan 2 atribut yaitu : ID_Faktur dan ID_Barang

C.SECOND NORMAL FORM( 2NF )

·  Suatu relasi berada dalam 2nd normal form jika dan hanya jika:

·  Berada dalam bentuk first normal form (1-NF)

·  Semua atribut bukan kunci memiliki dependensi sepenuhnya dengan kunci primer (Primary Key)

Jika kita lihat kembali relasi bentuk 1-NF yang telah dibuat sebelumnya, maka atribut bukan kunci pada table TBFaktur yang tidak memiliki dependensi sepenuhnya dengan primary key (ID_Faktur), yaitu : “Nama_Petugas”. Oleh sebab itu dekomposisi relasi perlu dilakukan kembali dengan cara :

1.      Mengeliminasi atribut “Nama_Petugas” dari table TBFaktur

2.      Membuat tabel TBPetugas, menyediakan atribut-atribut yang terkait dengan identitas dan data pelanggan

THIRD NORMAL FORM ( 3NF )

Pada Second Normal Form (2-NF) atribut yang terkait dengan “Nama_Pelanggan” tidak didekomposisi dari table TBFaktur karena atribut tersebut masih memiliki dependensi fungsional dengan primary key (ID_Faktur) karena tiap nomor faktur akan berbeda untuk tiap pembeli/pelanggan. Tetapi pada tahap 3-NF (Third Normal Form), atribut “Nama_Pelanggan” harus didekomposisi relasi karena pada tahap ini atribut bukan kunci tidak boleh ada yang berdependensi transitif dengan kunci primer.

Atribut “Nama_Pelanggan” dikatakan berdependensi transitif terhadap primary key (ID_Faktur) karena :

1.      ID_Pelanggan → Nama_Pelanggan (Nama_Pelanggan berdependensi fungsional terhadap ID_Pelanggan)

2.      ID_Faktur → ID_Pelanggan (ID_Pelanggan berdependensi fungsional terhadap ID_Faktur, karena tiap nomor faktur akan dikeluarkan untuk suatu ID_Pelanggan tertentu)

3.      Sehingga dikatakan bahwa ID_Faktur memiliki dependensi transitif terhadap atribut Nama_Pelanggan