Normalisasi Database

NORMALISASI Database

NORMALISASI

DefinisiNormalisasi adalah suatu teknik untuk mengorganisasi data ke dalam tabel-tabel untuk memenuhi kebutuhan pemakai di dalam suatu organisasi.

Tujuan dari normalisasi

( Untuk menghilangkan kerangkapan data( Untuk mengurangi kompleksitas( Untuk mempermudah pemodifikasian data

Proses Normalisasi

( Data diuraikan dalam bentuk tabel, selanjutnya dianalisis berdasarkan persyaratan tertentu ke beberapa tingkat.

( Apabila tabel yang diuji belum memenuhi persyaratan tertentu, maka tabel tersebut perlu dipecah menjadi beberapa tabel yang lebih sederhana sampai memenuhi bentuk yang optimal.

Tahapan Normalisasi

Bentuk Tidak NormalMenghilangkan perulangan groupBentuk Normal Pertama (1NF)Menghilangkan ketergantungan sebagianBentuk Normal Kedua (2NF)Menghilangkan ketergantungan transitifBentuk Normal Ketiga (3NF)Menghilangkan anomali-anomali hasil dariketergantungan fungsionalBentuk Normal Boyce-Codd (BCNF)Menghilangkan Ketergantungan MultivalueBentuk Normal Keempat (4NF)Menghilangkan anomali-anomali yang tersisaBentuk Normal Kelima

Ketergantungan Fungsional

Definisi :Atribut Y pada relasi R dikatakan tergantung fungsional pada atribut X (R.X > R.Y), jika dan hanya jika setiap nilai X pada relasi R mempunyai tepat satu nilai Y pada R.

Misal, terdapat skema database Pemasok-barang :Pemasok (No-pem, Na-pem)

Tabel PEMASOK-BARANG

No-pem Na-pem

P01 BaharuP02 SinarP03 Harapan

Ketergantungan fungsional dari tabel PEMASOK-BARANG adalah :No-pem > Na-pem

Ketergantungan Fungsional PenuhDefinisi :Atribut Y pada relasi R dikatakan tergantung fungsional penuh pada atribut X pada relasi R, jika Y tidak tergantung pada subset dari X ( bila X adalah key gabungan)

Contoh :KIRIM-BARANG( No-pem, Na-pem, No-bar, Jumlah)

No-pem Na-pem No-bar Jumlah

P01 Baharu B01 1000P01 Baharu B02 1500P01 Baharu B03 2000P02 Sinar B03 1000P03 Harapan B02 2000

Ketergantungan fungsional :No-pem > Na-pemNo-bar, No-pem > Jumlah (Tergantung penuh thd keynya)

Ketergantungan TransitifDefinisi :Atribut Z pada relasi R dikatakan tergantung transitif pada atribut X , jika atribut Y tergantung pada atribut X pada relasi R dan atribut Z tergantung pada atribut Y pada relasi R. ( X Y, Y Z , maka X Z )

Contoh :

No-pem Kode-kota Kota No-bar JumlahP01 1 Jakarta B01 1000P01 1 Jakarta B02 1500P01 1 Jakarta B03 2000P02 3 Bandung B03 1000P03 2 Surabaya B02 2000

Ketergantungan fungsional :No-pem Kode-kotaKode-kota Kota , makaNo-pem Kota

Bentuk Normal Kesatu (1NF)Suatu relasi dikatakan sudah memenuhi Bentuk Normal Kesatu bila setiap data bersifat atomik yaitu setiap irisan baris dan kolom hanya mempunyai satu nilai data

Tabel KIRIM-1 (Unnormal)

No-pem Kode-kota Kota No-bar Jumlah

P01 1 Jakarta B01 1000B02 1500B03 2000P02 3 Bandung B03 1000P03 2 Surabaya B02 2000

Tabel KIRIM-2 (1NF)

No-pem Kode-kota Kota No-bar Jumlah

P01 1 Jakarta B01 1000P01 1 Jakarta B02 1500P01 1 Jakarta B03 2000P02 3 Bandung B03 1000P03 2 Surabaya B02 2000Diagram Ketergantungan Fungsional

Kode-kotaNo-pemKotaJumlah

No-bar

Bentuk Normal Kedua (2NF)Suatu relasi dikatakan sudah memenuhi Bentuk Normal Kedua bila relasi tersebut sudah memenuhi bentuk Normal kesatu, dan atribut yang bukan key sudah tergantung penuh terhadap keynya.

Tabel PEMASOK-1 (2NF)

No-pem Kode-kota Kota

P01 1 JakartaP02 3 BandungP03 2 Surabaya

Bentuk Normal Ketiga (3NF)Suatu relasi dikatakan sudah memenuhi Bentuk Normal ketiga bila relasi tersebut sudah memenuhi bentuk Normal kedua dan atribut yang bukan key tidak tergantung transitif terhadap keynya.

Tabel KIRIM-3 (3NF)

No-pem No-bar Jumlah

P01 B01 1000P01 B02 1500P01 B03 2000P02 B03 1000P03 B02 2000

Tabel PEMASOK-2 (3NF) Tabel PEMASOK-3 (3NF)

No-pem Kode-kota Kode-kota Kota

P01 1 1 JakartaP02 3 2 SurabayaP03 2 3 Bandung

Normalisasi pada database perkuliahan

Asumsi :( Seorang mahasiswa dapat mengambil beberapa mata kuliah( Satu mata kuliah dapat diambil oleh lebih dari satu mahasiswa( Satu mata kuliah hanya diajarkan oleh satu dosen( Satu dosen dapat mengajar beberapa mata kuliah( Seorang mahasiswa pada mata kuliah tertentu hanya mempunyai satu nilai

Tabel MAHASISWA-1 ( Unnormal )

No-Mhs Nama- Mhs Jurusan Kode- MK Nama-MK Kode-Dosen Nama-Dosen Nilai2683 Welli MI MI350 Manajamen DB B104 Ati AMI465 Analsis Prc. Sistem B317 Dita B5432 Bakri Ak. MI350 Manajemen DB B104 Ati CAKN201 Akuntansi Keuangan D310 Lia BMKT300 Dasar Pemasaran B212 Lola A

Tabel MAHASISWA-2 ( 1NF )No-Mhs Nama- Mhs Jurusan Kode-MK Nama-MK Kode-Dosen Nama- Dosen Nilai2683 Welli MI MI350 Manajamen DB B104 Ati A2683 Welli MI MI465 Analsis Prc. Sistem B317 Dita B5432 Bakri Ak. MI350 Manajemen DB B104 Ati C5432 Bakri Ak. AKN201 Akuntansi Keuangan D310 Lia B5432 Bakri Ak. MKT300 Dasar Pemasaran B212 Lola A

Diagram Ketergantungan Fungsional

Nama_Mhs

No-Mhs Jurusan

NilaiNama-MK

Kode-MK Kode-Dosen

Nama-Dosen

Tabel KULIAH (2NF)Kode-MK Nama-MK Kode-Dosen Nama-DosenMI350 Manajamen DB B104 AtiMI465 Analsis Prc. Sistem B317 DitaAKN201 Akuntansi Keuangan D310 LiaMKT300 Dasar Pemasaran B212 Lola

Tabel MAHASISWA-3 (3NF)No-Mhs Nama-Mhs Jurusan2683 Welli MI5432 Bakri Ak.

Tabel NILAI (3NF)No-Mhs Kode MK Nilai2683 MI350 A2683 MI465 B5432 MI350 C5432 AKN201 B5432 MKT300 A

Tabel MATAKULIAH (3NF)Kode-MK Nama-MK Kode-DosenMI350 Manajamen DB B104MI465 Analsis Prc. Sistem B317AKN201 Akuntansi Keuangan D310MKT300 DasarPemasaran B212

Tabel DOSEN (3NF)Kode- Dosen Nama-DosenB104 AtiB317 DitaB310 LiaB212 Lola

https://apipfudin.wordpress.com/materi-kuliah-informatika/normalisasi-database/Pengertian Normalisasi Data Base Dan contohNormalisasiMar 5Posted by jewynerNORMALISASINormalisasi merupakan teknik analisis data yang mengorganisasikan atribut-atribut data dengan cara mengelompokkan sehingga terbentuk entitas yang non-redundant, stabil, dan fleksible

Normalisasi dilakukan sebagai uji coba pada suatu relasi secara berkelanjutan untuk menentukan apakah relasi itu sudah baik, yaitu dapat dilakukan proses insert,update,delete, dan modifikasi pada satu atau beberapa atribut tanpa mempengaruhi integritas data dalam relasi tersebut.

*Pada proses normalisasi terhadap tabel pada database dapat dilakukan dengan tiga tahap normalisasi antara lain :

1. BENTUK TIDAK NORMAL (UNNORMALIZED FORM)Bentuk ini merupakan kumpulan data yang akan direkam, tidak ada keharusan

mengikukti format tertentu, dapat saja data tidak lengkap atau terduplikasi. Datadikumpulkan apa adanya sesuai dengan saat menginput.

Untuk mentransformasikan tabel yang belum ternomalisasi di atas menjadi tabel yang memenuhi kriteria 1NF adalah kita harus merubah seluruh atribut yang multivalue menjadi atribut single value, dengan cara menghilangkan repeating group pada tabel di atas.

Repeating Group (elemen data berulang) adalah (No_Property, Alamat_Property,Tgl_Pinjam, Tgl_Selesai, Biaya, No_Pemilik, Nama_Pemilik)

2. BENTUK NORMAL KE SATU (FIRST NORMAL FORM / 1 NF)Pada tahap ini dilakukan penghilangan beberapa group elemen yang berulang agarmenjadi satu harga tunggal yang berinteraksi di antara setiap baris pada suatu tabel, dan setiap atribut harus mempunyai nilai data yang atomic (bersifat atomic value). Atom adalah zat terkecil yang masih memiliki sifat induknya, bila terpecah lagi maka ia tidak memiliki sifat induknya.

Syarat normal ke satu (1-NF) antara lain:1. setiap data dibentuk dalam flat file, data dibentuk dalam satu record demi satu recordnilai dari field berupa atomic value.

2. tidak ada set atribute yang berulang atau bernilai ganda.

3. telah ditentukannya primary key untuk tabel / relasi tersebut.

4. tiapatribut hanya memiliki satu pengertian.

Langkah pertama yang dilakukan pada Tabel Pelanggan Biaya (pada Tabel 9.3)tersebut adalah menghilangkan elemen data yang berulang dengan data-data Pelangganyang sesuai pada setiap baris. Hasil dari tabel yang telah memenuhi bentuk normalpertama dapat dilihat pada Tabel 9.4. kita dapat mengidentifikasi primary key untukrelasi Pelanggan_Biaya yang masih memiliki composite key (No_Pelanggan,No_Property). Pada kasus ini kita akan memperoleh primary key yang bersifat compositekey.Relasi Pelanggan_Biaya dapat didefinisikan sebagai berikut. Pelanggan_Biaya =(No_Pelanggan, No_Property, Nama, Alamat_Property, Tgl_Pinjam, Tgl_Selesai, Biaya,No_Pemilik, Nama_Pemilik)

3. BENTUK NORMAL KE DUA (SECOND NORMAL FORM / 2 NF)Bentuk normal kedua didasari atas konsep full functional dependency (ketergantungan fungsional sepenuhnya) yang dapat didefinisikan sebagai berikut.Jika A adalah atribut-atribut dari suatu relasi, B dikatakan full functional dependency (memiliki ketergantungan fungsional terhadap A, tetapi tidak secara tepat memiliki ketergantungan fungsional dari subset (himpunan bagian) dari A.

Syarat normal kedua (2-NF) sebagai berikut.1. Bentuk data telah memenuhi kriteria bentuk normal kesatu.

2. Atribute bukan kunci (non-key) haruslah memiliki ketergantungan fungsionalsepenuhnya (fully functional dependency) pada kunci utama / primary key.

Tabel Tabel Pelanggan Biaya dalam bentuk normal kedua (2-NF)

4. BENTUK NORMAL KE TIGA (THIRD NORMAL FORM / 3 NF)Walaupun relasi 2-NF memiliki redudansi yang lebih sedikit dari pada relasi 1-NF,namun relasi tersebut masih mungkin mengalami kendala bila terjadi anomalyperemajaan (update) terhadap relasi tersebut.Misalkan kita akan melakukan update terhadap nama dari seorang Pemilik (pemilik), seperti Durki (No_Pemilik: CO93), kita harus melakukan update terhadap dua baris dalam relasi Property_Pemilik (lihat Tabel 9.5, (c) relasi Property_Pemilik). Jika kita hanya mengupdate satu baris saja, sementara baris yang lainnya tidak, maka data didalam database tersebut akan inkonsisten / tidak teratur. Anomaly update ini disebabkan oleh suatu ketergantungan transitif (transitive dependency). Kita harus menghilangkan ketergantungan tersebut dengan melakukan normalisasi ketiga (3-NF).

Syarat normal ketiga (Third Normal Form / 3 NF) sebagai berikut.1. Bentuk data telah memenuhi kriteria bentuk normal kedua.

2. Atribute bukan kunci (non-key) harus tidak memiliki ketergantungan transitif, dengan kata lain suatu atribut bukan kunci (non_key) tidak boleh memiliki ketergantungan fungsional (functional dependency) terhadap atribut bukan kunci lainnya, seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap priamry key di relasi itu saja.

Seluruh atribut non-primary key pada relasi Pelanggan dan Biaya di atas terlihatmemiliki ketergantungan fungsional (functional dependency) terhadap primary key darimasing-masing tabel / relasi. Relasi / tabel Pelanggan dan Biaya di atas tidak memilikiketergantungan transitif (transitive dependency), sehingga tabel tersebut telah memenuhi

kriteria normal ketiga (3-NF).Seluruh atribut non-primary key pada relasi Property_Pemilik di atas terlihatmemiliki ketergantungan fungsional (functional dependency) terhadap primary key,kecuali Nama_Pemilik yang masih memiliki ketergantungan fungsional (functionaldependency) terhadap No_Pemilik. Inilah contoh ketergantungan dari transitif (transitivedependency), yang terjadi ketika atribut non-primary key (Nama_Pemilik) bergantungsecara fungsi terhadap satu atau lebih atribut non-primary key lainnya (No_Pemilik). Kitaharus menghilangkan ketergantungan transitif (transitive dependency) tersebut denganmenjadikan relasi Property_Pemilik menjadi 2 relasi / tabel dengan format / bentuksebagai berikut.

Relasi / Tabel Property_Untuk_Pemilik yang terdiri dari atribut-atribut:

Alamat_Property, Biaya, No_Pemilik(No_property

{No_property sebagai primary key}

Dan relasi Pemilik yang terdiri dari atribut-atribut:

Nam(No_Pemilik a_Pemilik

{No_Pemilik sebagai primary key}

Hasil akhir normalisasi tabel Pelanggan_Biaya sampai ke bentuk normal ketiga adalah

sebagai berikut X fn `&%.0pt; font-family:Calibri,sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Times New Roman; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

4. BENTUK NORMAL KE TIGA (THIRD NORMAL FORM / 3 NF)Walaupun relasi 2-NF memiliki redudansi yang lebih sedikit dari pada relasi 1-NF,

namun relasi tersebut masih mungkin mengalami kendala bila terjadi anomaly

peremajaan (update) terhadap relasi tersebut.

Misalkan kita akan melakukan update terhadap nama dari seorang Pemilik (pemilik), seperti Durki (No_Pemilik: CO93), kita harus melakukan update terhadap dua baris dalam relasi Property_Pemilik (lihat Tabel 9.5, (c) relasi Property_Pemilik). Jika kita hanya mengupdate satu baris saja, sementara baris yang lainnya tidak, maka data didalam database tersebut akan inkonsisten / tidak teratur. Anomaly update ini disebabkan oleh suatu ketergantungan transitif (transitive dependency). Kita harus menghilangkan ketergantungan tersebut dengan melakukan normalisasi ketiga (3-NF).

Syarat normal ketiga (Third Normal Form / 3 NF) sebagai berikut.1. Bentuk data telah memenuhi kriteria bentuk normal kedua.

2. Atribute bukan kunci (non-key) harus tidak memiliki ketergantungan transitif, dengan kata lain suatu atribut bukan kunci (non_key) tidak boleh memiliki ketergantungan fungsional (functional dependency) terhadap atribut bukan kunci lainnya, seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap priamry key di relasi itu saja.Seluruh atribut non-primary key pada relasi Pelanggan dan Biaya di atas terlihatmemiliki ketergantungan fungsional (functional dependency) terhadap primary key darimasing-masing tabel / relasi. Relasi / tabel Pelanggan dan Biaya di atas tidak memilikiketergantungan transitif (transitive dependency), sehingga tabel tersebut telah memenuhikriteria normal ketiga (3-NF).

Seluruh atribut non-primary key pada relasi Property_Pemilik di atas terlihatmemiliki ketergantungan fungsional (functional dependency) terhadap primary key,kecuali Nama_Pemilik yang masih memiliki ketergantungan fungsional (functionaldependency) terhadap No_Pemilik. Inilah contoh ketergantungan dari transitif (transitivedependency), yang terjadi ketika atribut non-primary key (Nama_Pemilik) bergantungsecara fungsi terhadap satu atau lebih atribut non-primary key lainnya (No_Pemilik). Kitaharus menghilangkan ketergantungan transitif (transitive dependency) tersebut denganmenjadikan relasi Property_Pemilik menjadi 2 relasi / tabel dengan format / bentuksebagai berikut.

Relasi / Tabel Property_Untuk_Pemilik yang terdiri dari atribut-atribut:

Alamat_Property, Biaya, No_Pemilik(No_property

{No_property sebagai primary key}

Dan relasi Pemilik yang terdiri dari atribut-atribut:

Nama_Pemilik(No_Pemilik

{No_Pemilik sebagai primary key}

Hasil akhir normalisasi tabel Pelanggan_Biaya sampai ke bentuk normal ketiga adalah

sebagai berikut:

Seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja.

https://jewyner.wordpress.com/category/pengertian-normalisasi-data-base-dan-contohnya/Fungsi,Tujuan dan Normalisasi Database

arif wicaksono | 7:32 AM | IT Normalisasi database merupakansuatu pendekatan sistematis untuk meminimalkan redundansi data pada suatu database agar database tersebut dapat bekerja dengan optimal. Jika anda seorang database administrator ketika terjadi sesuatu pada database seperti penurunan kinerja, mungkin anda akan ditanya apakah database tersebut telah di normalisasi?

Fungsi Normalisasi DatabasePada ilmu database atau basis data, normalisasi digunakan untuk menghindari terjadinya berbagai anomali data dan tidak konsistensinya data. Ini merupakan funsi secara umum. Dalam beberapa kasus normalisasi ini sangat penting untuk menunjang kinerja database dan memastikan bahwa data dalam database tersebut aman dan tidak terjadi kesalahan jika mendapat perintah SQL terutama DML yaitu update, insert, dan delete.

Perlu diketahui dalam beberapa kasus Normalisasi database terkadang harus diubah menjadi bentuk denormalisasi, terutama untuk data yang telah besar dan membengkak. Denormalisasi ini ditujukan untuk meningkatkan performance dengan meletakkan beberapa field menjadi satu tabel sehingga mudah di tarik. Denormalisasi ini sering digunakan untuk menarik data yang besar dari database.

Tujuan Normalisasi DatabaseTujuan normalisasi database adalah untuk menghilangkan dan mengurangi redudansi data dan tujuan yang kedua adalah memastikan dependensi data (Data berada pada tabel yang tepat).

Jika data dalam database tersebut belum di normalisasi maka akan terjadi 3 kemungkinan yang akan merugikan sistem secara keseluruhan.

1. INSERT Anomali : Situasi dimana tidak memungkinkan memasukkan beberapa jenis data secara langsung di database.

2. DELETE Anomali: Penghapusan data yang tidak sesuai dengan yang diharapkan, artinya data yang harusnya tidak terhapus mungkin ikut terhapus.

3. UPDATE Anomali: Situasi dimana nilai yang diubah menyebabkan inkonsistensi database, dalam artian data yang diubah tidaksesuai dengan yang diperintahkan atau yang diinginkan.

Normalisasi Database Normalisasi Database terdiri dari banyak bentuk, dalam ilmu basis data ada setidaknya 9 bentuk normalisasi yang ada yaitu1NF,2NF,3NF,EKNF,BCNF,4NF,5NF,DKNF, dan6NF. Namun dalam prakteknya dalam dunia industri bentuk normalisasi ini yang paling sering digunakan ada sekitar 5 bentuk.

Normal FormData yang direkam dan dimasukkan secara mentah dalam suatu tabel pada bentuk ini sangat mungkin terjadi inkonsistensi dan anomali data

Contoh Normal Form

Contoh normal form

Pada bentuk ini ada beberapa ciri ciri yang penting, yang pertama adalah akan terjadi anomali dalam insert, update, dan delete. Hal ini menyebabkan beberapa Fungsi DML di MYSQL tidak dapat berjalan dengan baik. Sebagai contoh jika ingin menghapus penerbit maka data judul buku akan ikut terhapus begitu juga jika ingin menghapus peminjam, maka data penerbit dan buku yang harusnya tidak terhapus akan ikut hilang.

First Normal Form (1NF)Bentuk normal yang pertama atau 1NF mensyaratkan beberapa kondisi dalam sebuah database, berikut adalah fungsi dari bentuk normal pertama ini.

Menghilangkan duplikasi kolom dari tabel yang sama.

Buat tabel terpisah untuk masing-masing kelompok data terkait dan mengidentifikasi setiap baris dengan kolom yang unik (primary key).

Contoh Normalisasi Database 1NF

Normalisasi Database 1NF

Pada intinya bentuk normalisasi 1NF ini mengelompokkan beberapa tipe data atau kelompok data yang sejenis agar dapat dipisahkan sehingga anomali data dapat di atasi. Contoh adalah ketika kita ingin menghapus, mengupdate, atau menambahkan data peminjam, maka kita tidak bersinggungan dengan data buku atau data penerbit. Sehingga inkonsistensi data dapat mulai di jaga.

Second normal form (2NF)Syarat untuk menerapkan normalisasi bentuk kedua ini adalah data telah dibentuk dalam 1NF, berikut adalah beberapa fungsi normalisasi 2NF.

Menghapus beberapa subset data yang ada pada tabel dan menempatkan mereka pada tabel terpisah.

Menciptakan hubungan antara tabel baru dan tabel lama dengan menciptakan foreign key.

Tidak ada atribut dalam tabel yang secara fungsional bergantung pada candidate key tabel tersebut.

Contoh normalisasi database bentuk 2NF

Contoh Normalisasi Database 2NF

Contoh di atas kita menggunakan tabel bantuan yaitu tabel transaksi, pada intinya bentu kedua ini adalah tidak boleh ada field yang berhubungan dengan field lainnya secara fungsional. Contoh Judul Buku tergantung dengan id_Buku sehingga dalam bentuk 2NF judul buku dapat di hilangkan karena telah memiliki tabel master tersendiri.

Third Normal Form (3NF)Normalisasi database dalam bentuk 3NF bertujuan untuk menghilangkan seluruh atribut atau field yang tidak berhubungan dengan primary key. Dengan demikian tidak ada ketergantungan transitif pada setiap kandidat key. Syarat dari bentuk normal ketiga atau 3NF adalah :

Memenuhi semua persyaratan dari bentuk normal kedua.

Menghapus kolom yang tidak tergantung pada primary key.

Contoh Normalisasi Database Bentuk 3NF

Tidak semua kasus atau tabel dapat kita sesuaikan dengan berbagai bentuk normalisasi ini, untuk contoh 3NF kita akan mengambil contoh dari tabel order.

Normalisasi Database Bentuk 3NF

Pada tabel pertama di atas, apakah semua kolom sepenuhnya tergantung pada primary key? tentu tidak, hanya saja ada satu field yaitu total yang bergantung pada harga dan jumlah, total dapat dihasilkan dengan mengalikan harga dan jumlah. Bentuk 3NF dalam tabel di atas dapat dilakukan dengan membuang field Total.

Bentuk SQL

SELECT ORDERID,HARGA, JUMLAH, TOTALFROM ORDER

Menjadi

SELECT ORDERID, HARGA*JUMLAH AS TOTALFROM ORDER

BCNFBoyceCodd normal formMerupakan sebuah teknik normalisasi database yang sering disebut 3.5NF, memiliki hubungan yang sangat erat dengan bentuk 3NF. Pada dasarnya adalah untuk menghandle anomali dan overlooping yang tidak dapat di handle dalam bentuk 3NF. Normalisasi database bentuk ini tergantung dari kasus yang disediakan, tidak semua tabel wajib di normalisasi dalam bentuk BCNF.

Posted by arif wicaksono at 7:32 AM

Email This

HYPERLINK "http://www.blogger.com/share-post.g?blogID=5100317839505944078&postID=1039220326573082873&target=blog" \o "BlogThis!" \t "_blank" BlogThis!

HYPERLINK "http://www.blogger.com/share-post.g?blogID=5100317839505944078&postID=1039220326573082873&target=twitter" \o "Share to Twitter" \t "_blank" Share to Twitter

HYPERLINK "http://www.blogger.com/share-post.g?blogID=5100317839505944078&postID=1039220326573082873&target=facebook" \o "Share to Facebook" \t "_blank" Share to FacebookNewer Post Older Post Home

Subscribe to: Post Comments (Ahttp://enryuguy.blogspot.com/2014/12/normalisasi-database.htmlDescription of normalization

Normalization is the process of organizing data in a database. This includes creating tables and establishing relationships between those tables according to rules designed both to protect the data and to make the database more flexible by eliminating redundancy and inconsistent dependency.

Redundant data wastes disk space and creates maintenance problems. If data that exists in more than one place must be changed, the data must be changed in exactly the same way in all locations. A customer address change is much easier to implement if that data is stored only in the Customers table and nowhere else in the database.

What is an "inconsistent dependency"? While it is intuitive for a user to look in the Customers table for the address of a particular customer, it may not make sense to look there for the salary of the employee who calls on that customer. The employee's salary is related to, or dependent on, the employee and thus should be moved to the Employees table. Inconsistent dependencies can make data difficult to access because the path to find the data may be missing or broken.

There are a few rules for database normalization. Each rule is called a "normal form." If the first rule is observed, the database is said to be in "first normal form." If the first three rules are observed, the database is considered to be in "third normal form." Although other levels of normalization are possible, third normal form is considered the highest level necessary for most applications.

As with many formal rules and specifications, real world scenarios do not always allow for perfect compliance. In general, normalization requires additional tables and some customers find this cumbersome. If you decide to violate one of the first three rules of normalization, make sure that your application anticipates any problems that could occur, such as redundant data and inconsistent dependencies.

The following descriptions include examples.

First normal form

Eliminate repeating groups in individual tables.

Create a separate table for each set of related data.

Identify each set of related data with a primary key.

Do not use multiple fields in a single table to store similar data. For example, to track an inventory item that may come from two possible sources, an inventory record may contain fields for Vendor Code 1 and Vendor Code 2.

What happens when you add a third vendor? Adding a field is not the answer; it requires program and table modifications and does not smoothly accommodate a dynamic number of vendors. Instead, place all vendor information in a separate table called Vendors, then link inventory to vendors with an item number key, or vendors to inventory with a vendor code key.

Second normal form

Create separate tables for sets of values that apply to multiple records.

Relate these tables with a foreign key.

Records should not depend on anything other than a table's primary key (a compound key, if necessary). For example, consider a customer's address in an accounting system. The address is needed by the Customers table, but also by the Orders, Shipping, Invoices, Accounts Receivable, and Collections tables. Instead of storing the customer's address as a separate entry in each of these tables, store it in one place, either in the Customers table or in a separate Addresses table.

Third normal form

Eliminate fields that do not depend on the key.

Values in a record that are not part of that record's key do not belong in the table. In general, any time the contents of a group of fields may apply to more than a single record in the table, consider placing those fields in a separate table.

For example, in an Employee Recruitment table, a candidate's university name and address may be included. But you need a complete list of universities for group mailings. If university information is stored in the Candidates table, there is no way to list universities with no current candidates. Create a separate Universities table and link it to the Candidates table with a university code key.

EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not always practical. If you have a Customers table and you want to eliminate all possible interfield dependencies, you must create separate tables for cities, ZIP codes, sales representatives, customer classes, and any other factor that may be duplicated in multiple records. In theory, normalization is worth pursing. However, many small tables may degrade performance or exceed open file and memory capacities.

It may be more feasible to apply third normal form only to data that changes frequently. If some dependent fields remain, design your application to require the user to verify all related fields when any one is changed.

Other normalization forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal form do exist, but are rarely considered in practical design. Disregarding these rules may result in less than perfect database design, but should not affect functionality.

Normalizing an example table

These steps demonstrate the process of normalizing a fictitious student table.

1. Unnormalized table:

Student#AdvisorAdv-RoomClass1Class2Class3

1022Jones412101-07143-01159-02

4123Smith216201-01211-02214-01

2. First Normal Form: No Repeating Groups

Tables should have only two dimensions. Since one student has several classes, these classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above records are indications of design trouble.

Spreadsheets often use the third dimension, but tables should not. Another way to look at this problem is with a one-to-many relationship, do not put the one side and the many side in the same table. Instead, create another table in first normal form by eliminating the repeating group (Class#), as shown below:

Student#AdvisorAdv-RoomClass#

1022Jones412101-07

1022Jones412143-01

1022Jones412159-02

4123Smith216201-01

4123Smith216211-02

4123Smith216214-01

3. Second Normal Form: Eliminate Redundant Data

Note the multiple Class# values for each Student# value in the above table. Class# is not functionally dependent on Student# (primary key), so this relationship is not in second normal form.

The following two tables demonstrate second normal form:

Students

Student#AdvisorAdv-Room

1022Jones412

4123Smith216

Registration

Student#Class#

1022101-07

1022143-01

1022159-02

4123201-01

4123211-02

4123214-01

4. Third Normal Form: Eliminate Data Not Dependent On Key

In the last example, Adv-Room (the advisor's office number) is functionally dependent on the Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table, as shown below:

Students

Student#Advisor

1022Jones

4123Smith

Faculty

NameRoomDept

Jones41242

Smith21642

Back to the top | Give Feedback

HYPERLINK "javascript:void(0);" REFERENCESAhlo, Hamilton M., Randy Brown and Peter Colclough. FoxPro 2: A Developer's Guide: Expert Guidance for Industrial-Strength Programming. John Wiley & Sons, October 1991. Pages 220-225.

Jennings, Roger. Using Access 1.1 for Windows. Que Corporation, July 1993. Pages 799-800.

Back to the top | Give Feedbackhttps://support.microsoft.com/en-us/kb/209534/en-us