NORMALISASI LANJUT

BAB I

PENDAHULUAN

1.1        LATAR BELAKANG

Basis data dapat diumpamakan sama dengan lemari arsip data. Dengan adanya basis data kita jadi lebih gampang untuk menyampaikan informasi yang tersimpan dalam lemari arsip data.

      Penyampaian informasi melalui basis data selalu dibuat sesimpel dan seringkas mungkin serta tidak menhilangkan informasi yang ingin disampaikan. Bentuk penyampai informasi seperti ini biasanya dilakukan pada sebuah bentuk tabel yang disebut tabel Universal.
Tabel universal menyampaikan semua informasi yang ada seringkas mungkin dan tanpa menhilangkan satupun informasi. Tetapi kita sering tidak melihat data atau informasi yang tertera pada tabel Universal.

       Supaya kita dapat melihat informasi yang tertera pada tabel universal sehingga tidak ada data yang tidak terbaca atau data tertambah, yang bukan merupakan sebuah data yang tertera pada tabel universal. Maka kita lakukan dengan cara menormalisasi data tersebut.

 Perancangan merupakan suatu hal yang sangat penting dalam pembuatan basis data. Permasalahan yang dihadapi pada waktu perancangan yaitu bagaimana basis data yang akan dibangun ini dapat memenuhi kebutuhan saat ini dan masa yang akan datang. Untuk itu diperlukan perancangan basis data baik secara fisik maupun secara konseptualnya. Perancangan konseptual akan menunjukkan entity dan relasinya berdasarkan proses yang diinginkan oleh organisasinya. Untuk menentukan entity dan relasinya perlu dilakukan analisis data tentang informasi yang ada dalam spesifikasi di masa yang akan datang.

Suatu basis data dibangun berdasarkan kebutuhan informasi dalam suatu organisasi, oleh sebab itu pada umumnya perancangan basis data dimulai dari pengamatan kebutuhan informasi.

Proses perancangan basis data , dibagi menjadi 3 tahapan yaitu :

Ø  Perancangan basis data secara konseptual, tahapan ini merupakan upaya untuk membuat model yang masih bersifat konsep..

Ø  Perancangan basis data secara logis, merupakan tahapan untuk memetakan model konseptual kemodel basis data yang akan dipakai (modal relasional, hirarkis, atau jaringan).

Ø  Perancangan ini tidak bergantung pada DBMS yang akan dipakai, itulah sebabnya perancangan basis data secara logis terkadang disebut pemetaan model data.

Ø  Perancangan basis data secara fisis, merupakan tahapan untuk menuangkan perancangan basis data yang bersifat logis menjadi basis data fisis yang tersimpan pada media penyimpanan eksternal (yang spesifik terhadap DBMS yang dipakai ).

1.2        TUJUAN

a. Agar kita memiliki basis data yang kompak dan efesien dalam penggunaan ruang  penyimpanan
b. Agar cepat dalam pengaksesan data
c. Agar mudah dalam pemanipulasian data
d. Agar tidak terjadi pengulanggan data
e. Agar tidak ada data yang tersembunyi

f. Menghilangkan kerangkapan data, mengurangi kompleksitas, & untuk mempermudah pemodifikasian data.

1.3        TINJAUAN PUSTAKA

1.3.1 Pengertian Basisdata :

1.      Basisdata merupakan kumpulan tabel-tabel atau files yang saling berelasi.

2.      Basisdata merupakan kumpulan data non-redundant yang dapat digunakan bersama (shared) oleh system aplikasi yang berbeda atau basis data merupakan kumpulan data non redundant yang saling terkait satu sama lainya yang dinyatakan oleh atribut-atribut kunci dari table-tabelnya.

Karena tidak semua pengguna basisdata terlatih dengan baik dan penggunanya terbagi dalam beberapa tingkatan, maka kompleksitas basisdata akan tersembunyi dari para penggunanya melalui beberapa level abstraksi data, yaitu :

1.      Level Fisik : merupakan tingkatan terendah dalam abstraksi data yang menunjukkan bagaimana data disimpan, yang pada umunya tidak terlihat oleh oleh pengguna atau programmer aplikasinya

2.      Level konseptual : mengambarkan data apa saja yang sebenarnya (secara fungsional) disimpan didalam basisdata beserta relasi-relasinya didalam basisdata, dimana administrator basisdata (DBA) membangun dan mengolah basisdata, contohnya: penguna akan mengetahui bahwa data penjualan disimpan didalam tabel-tabel barang, produksi, keuangan, marketing

3.      Level View : merupakan tingkatan tertinggi, yaitu pengguna aplikasi dan programmer hanya mengenal struktur data.

Dalam merancang database harus dapat dijawab apabila kita diberikan data, maka bagaimana kita menentukan struktur logik yang tepat untuk data tersebut, atau bagaimana kita menentukan relation-relation yang diperlukan dan apa atributnya.

Semua relation dalam relational database selalu sudah ternormalisasi, dalam arti bahwa semua relation sudah didefinisikan terhadap domain sederhana, yaitu domain yang hanya berisi nilai atomik. Dalam normalisasi lanjutan kita berusaha untuk menghilangkan/mengurangi data yang duplikasi atau mubazir agar supaya mendapatkan bentuk yang baik, hemat tempat, hemat waktu, hemat biaya dan yang memberikan respon yang baik dan cepat.

Metode Normalisasi adalah suatu proses perancangan database untuk mendapatkan bentuk normal. Normalisasi berkaitan dengan suatu proses sedang Normal Form berkaitan dengan output proses.Jika suatu relasi berada dalam bentuk normal , maka ia juga termasuk dalam bentuk normal tersebut didalamnya /dibawahnya. Contoh : jika suatu berada dalam bentuk 2 NF , maka relasi tersebut termasuk pula dalam bentuk 1NF.

1.3.2 Model Konseptual Basis data

          Perancangan model konseptual basis data dalam sebuah organisasi menjadi tugas dari Administrator basis data. Model konseptual merupakan kombinasi beberapa cara untuk memproses data untuk beberapa aplikasi. Model konseptual tidak tergantung pada aplikasi individual, DBMS digunakan, Hardware komputer dan model fisiknya. Pada perancangan model konseptual basis data ini penekanan dilakukan pada struktur data dan relasi antara file. Pada perancangan model konseptual ini dapat dilakukan dengan menggunakan model data relasional.

1.3.3 Field (Atribut) Kunci

setiap file selalu terdapat kunci dari file berupa field atau satu set field yang dapat mewakili record. Misalnya Nomor Pokok Mahasiswa (NPM) merupakan kunci dari tabel mahasiswa suatu Perguruan Tinggi, setiap pencarian cukup dengan menyebut nomor mahasiswa tersebut maka dapat diketahui identitas mahasiswa lainnya seperti nama, alamat dan atribut lainnya.

Nomor Pegawai (NIP) bagi data dosen, NIK untuk data karyawan, Kode_Kuliah untuk data Mata kuliah, dan lain sebagainya.

1.3.4 Jenis Atribut Pada Entitas

Atribut yang melekat pada suatu entitas ada bermacam tipe seperti yang akan dijelaskan sebagai berikut :

1.      Atribut Sederhana : atribut sederhana merupakan atribut atomik yang tidak dapat lagi dipecah menjadi atribut lain. Contoh

Entitas mahasiswa mempunyai atribut sederhana berupa NIM, Nama Mahasiswa .

2.      Atribut Komposit : atribut komposit merupakan atribut yang masih dapat dipecah menjadi sub-sub atribut yang masing-masing memiliki arti tersendiri.

Contoh : entitas mahasiswa mempunyai atribut alamat. Alamat disini dapat dipecah menjadi sub atribut seperti nama_kota, kode_pos.

3.      Atribut Bernilai Tunggal : yaitu atribut yang hanya memiliki satu nilai untuk setiap barisnya.

Contoh : entitas mahasiswa mempunyai atribut NPM, Nama, Alamat isi data dari atribut ini hanya boleh diisi dengan 1 data. Setiap mahasiswa hanya memiliki 1 NPM, 1 Nama, 1 Alamat.

4.      Atribut Bernilai Jamak : yaitu atribut yang boleh memiliki lebih dari satu nilai untuk setiap barisnya.

Contoh : entitas mahasiswa mempunyai atribut Hobby isi data dari atribut ini boleh lebih dari 1 data. Mahasiswa Roshita memiliki NPM 13402021 beralamat di Jalan Garuda 32 Yogyakarta memiliki Hobby (Olah Raga, Nyanyi, Masak dan Nonton TV)

5.      Atribut Harus Bernilai : yaitu atribut yang harus memiliki nilai data untuk setiap barisnya. Biasanya atribut seperti ini sudah ditetapkan dalam perancangan tabelnya sehingga jika dalam pengisian dokosongi akan terjadi kesalahan.

Contoh : entitas mahasiswa mempunyai atribut NPM dan Nama_Mahasiswa yang harus diisi datanya, sebab jika tidak diisi akan terjadi kekacauan dalam basis data.

6.      Atribut Bernilai Null : yaitu atribut yang boleh tidak memiliki nilai data untuk setiap barisnya.

Contoh : entitas mahasiswa mempunyai atribut Alamat, Hobby, Nama_Pacar yang boleh untuk tidak diisi tetapi kalau diisi akan lebih baik,

7.      Atribut Turunan : yaitu atribut yang nilai-nilainya diperoleh dari pengolahan atau dapat diturunkan dari atribut lain yang berkaitan.

Contoh : entitas mahasiswa mempunyai atribut IPK yang diperoleh dari pengolahan atribut Nilai pada tabel (entitas Nilai) dengan kode NIM mahasiswa yang sama dan diproses sehingga menghasilkan IPK untuk mahasiswa yang bersangkutan.

1.3.5 Teknik Normalisasi

Dalam merancang database harus dapat dijawab apabila kita diberikann data, maka bagaimana kita menentukan struktur logik yang tepat untuk data tersebut, atau bagaimana kita menentukan relation-relation yang diperlukan dan apa atributnya.

Semua relation dalam relational database selalu sudah ternormalisasi, dalam arti bahwa semua relation sudah didefinisikan terhadap domain sederhana, yaitu domain yang hanya berisi nilai atomik. Dalam normalisasi lanjutan kita berusaha untuk menghilangkan/mengurangi data yang duplikasi atau mubazir agar supaya mendapatkan bentuk yang baik, hemat tempat, hemat

waktu, hemat biaya dan yang memberikan respon yang baik dan cepat.

Metode Normalisasi adalah suatu proses perancangan database untuk mendapatkan bentuk normal. Normalisasi berkaitan dengan suatu proses sedang Normal Form berkaitan dengan output proses.Jika suatu relasi berada dalam bentuk normal , maka ia juga termasuk dalam bentuk normal tersebut didalamnya /dibawahnya. Contoh : jika suatu berada dalam bentuk 2 NF , maka relasi tersebut termasuk pula dalam bentuk 1NF.

Suatu relation dikatakan sudah berada pada bentuk normalisasi tertentu bila memenuhi beberapa batasan tertentu pada tingkat tersebut. Tingkat normalisasi yang lebih tinggi dianggap lebih baik dari tingkat dibawahnya.

Tingkat-tingkat normalisasi :

1. Relation umum (yang belum dan yang sudah ternormalisasi)

2. 1NF (First Normal Form) relation yang sudah ternormalisasi.

3. 2NF (Second Normal Form) relation.

4. 3NF (Third Normal Form) relation.

5. BCNF (Boyce Codd Normal Form) relation.

6. 4NF (Fourth Normal Form) relation.

7. PJ/NF (Project Join Normal Form) atau 5NF (Fifth Normal Form) relation

Aplikasi yang dapat diselesaikan hanya sampai bentuk normal 3. Aplikasi Normal Form BCNF - DKNF cenderung menggunakan aplikasi matematika yang lebih rumit dibandingkan dengan bentuk aplikasi 1 NF - 3 NF. Bentuk DKNF sampai sekarang masih sebagai hipotesa belum dibuktikan. Untuk 6NF dan 7NF dan seterusnya belum terpikirkan saat ini. Dalam Unnormalized Relational masih banyak ditemui bentuk normal seperti tabel yang telah dicatat diatas yang mempunyai ciri berulang (data redudant) dalam suatu grup.

Beberapa pengertian mengenai normalisasi :

1.      Istilah Normalisasi berasal dari E. F.Codd, salah seorang perintis teknologi basis data. selain dipakai sebagai metodologi tersendiri untuk menciptakan struktur tabel 9 relasi) dalam basis data (dengan tujuan utnuk mengurangi kemubaziran data) , normalisasi terkadang hanya diipakai sebagai perangkat verifikasi terhadap tabel-tabel yang dihasilkan oleh metodologi lain ( misalnya E-R). Normalisasi memberikan panduan yang sangat membantu bagi pengembang untuk mencegah penciptaan struktur tabel yang kurang fleksibel atau mengurangi keflekxibelan.

2.      Kroenke mendefinisikan normalisasi sebagai proses untuk mengubah suatu relasi yang memiliki masalah tertentu ke dalam dua buah relasi atau lebih yang tida memiliki masalah tersebut. Masalah yang dimaksud oleh kroenke ini sering disebut dengan istilah anomali.

3.      Normalisasi merupakan sebuah teknik dalam logical desain sebuah basis data / database, teknik pengelompokkan atribut dari suatu relasi sehingga membentuk struktur relasi yang baik (tanpa redudansi).

4.      Normalisasi adalah suatu proses memperbaiki / membangun dengan model data relasional, dan secara umum lebih tepat dikoneksikan dengan model data logika.

Proses normalisasi adalah proses pengelompokan data elemen menjadi tabel-tabel yang menunjukkan entity dan relasinya. Pada proses normalisasi dilakukan pengujian pada beberapa kondisi apakah ada kesulitan pada saat menambah/menyisipkan, menghapus, mengubah dan mengakses pada suatu basis data. Bila terdapat kesulitan pada pengujian tersebut maka perlu dipecahkan relasi pada beberapa tabel lagi atau dengan kata lain perancangan basis data belum optimal.

1.3.6 Kebergantungan Fungsi

Kebergantungan Fungsi didefinisikan sebagai hubungan antara satu relasi dengan relasi lainnya.

Misalnya : sebuah relasi R, atribut Y dan R adalah bergantung fungsi pada atribut X dari R jika dan hanya jika setiap nilai X dalam R punya hubungan dengan tepat satu nilai Y dalam R (dalam setiap satu waktu). File relasi pegawai atribut berisi : No Pegawai, No KTP, Nama, Tempat Lahir, Tgl Lahir, Alamat, Kota. Isi dari atribut nama bergantung pada No Pegawai. Jadi dapat dikatakan bahwa atribut nama bergantung secara fungsi pada No Pegawai dan Nomor Pegawai menunjukkan secara fungsi nama. jika anda mengetahui no pegawai maka anda dapat menentukan nama pegawai tersebut.

Isi dari atribut nama bergantung pada No Pegawai. Jadi dapat dikatakan bahwa atribut nama bergantung secara fungsi pada No Pegawai dan Nomor Pegawai menunjukkan secara fungsi nama. jika anda mengetahui no pegawai maka anda dapat menentukan nama pegawai tersebut. Notasi untuk kebergantungan fungsi ini adalah

Teknik Model Data Relasional ada 2 yaitu :

1.      Teknik Normalisasi

2.      Teknik Entity Relationship

Namun yang akan dibahas lebih lanjut adalah Teknik Normalisasi.

1.3.7 Ketergantungan Fungsional

            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 data base Pemasok-barang:

            Pemasok (No-pem, Na-pem)

Tabel PEMASOK-BARANG

Ketergantungan fungsional dari table PEMASOK-BARANG adalah:

            No-pem à Na-pem

1.3.8 Ketergantungan Funsional Penuh

            Atribut Y pada relasi R dikatakan tergantung fungsional penuh pada atribut X pada relasi R, jika Y tidak bergantung pada subset dari X (bila X adalah key gabungan).

Contoh:

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

Ketergantungan Fungsional:

No-pem à Na-pem

No-bar, No-pem à Jumlah                 (tergantung penuh terhadap key-nya)

1.3.9 Ketergantungan Transitif

            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:

Ketergantungan transitif:

No-pem à Kode-kota

Kode-kota à Kota, maka

No-pem à Kota

BAB II

PEMBAHASAN

2.1 Bentuk-Bentuk Normal

Berikut adalah bentuk-bentuk normal :

1. Bentuk Normal Tahap Pertama (1st Normal Form / 1NF)
2. Bentuk Normal Tahap Kedua (2nd Normal Form / 2NF)
3. Bentuk Normal Tahap (3rd Normal Form / 3NF)
4. Boyce-Code Normal Form (BCNF)
5. Bentuk Normal Tahap (4th Normal Form / 4NF)
6. Bentuk Normal Tahap (5th Normal Form / 5NF)

2.1.1        Normal Pertama (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.

Aturan :

ü  Tidak adanya atribut multi-value, atribut komposit atau kombinasinya.

ü  Mendefinisikan atribut kunci.

ü  Setiap atribut dalam tabel tersebut harus bernilai atomic (tidak dapat dibagi-bagi lagi)

Contoh 1 : Atribut Multi Value

Misalkan Data  mahasiswa sebagai berikut :

Atau

Didekomposisi menjadi :

·         Tabel Mahasiswa

·         Tabel Hobi

            Contoh 2 : Composite

            Misalkan :

            Jadwal Kuliah

Kodekul

NamaKul

Dosen

Kelas

Jadwal

·         Dimana nilai pada atribut jadwal berisi gabungan antara Hari dan Jam

·         Jika asumsi hari dan jam memegang peranan penting dalam sistem basis data, maka atribut Jadwal perlu dipisah menjadi JadwalHari dan JadwalJam.

Kodekul

NamaKul

Dosen

Kelas

JadwalHari

JadwalJam

                                   

2.1.2        Normal Kedua (2NF)

Suatu relasi dikatakan sudah memenuhi Bentuk Normal Kedua bila relasi tersebut sudah memenuhi bentuk Normalkesatu, dan atribut yang bukan key sudah tergantung penuh terhadap keynya.

Aturan :

ü  Sudah memenuhi dalam bentuk normal

            kesatu (1NF)

ü  Semua atribut bukan kunci hanya boleh tergantung (functional dependency) pada atribut kunci

ü  Jika ada ketergantungan  parsial maka atribut tersebut harus dipisah pada tabel yang lain

ü  Perlu ada tabel penghubung ataupun kehadiran foreign key bagi atribut-atribut yang telah dipisah tadi

Contoh :

Tabel berikut memenuhi 1NF tapi tidak termasuk 2NF:

     

Mhs_npm

mhs_nama

mhs_alamat

mk_kode

mk_nama

mk_sks

nihuruf

Ø  Tidak memenuhi 2NF, karena {Mhs_nrp, mk_kode} yang dianggap sebagai primary key sedangkan:

      {Mhs_npm, mk_kode}               à     mhs_nama

      {Mhs_npm, mk_kode}   à     mhs_alamat

      {Mhs_npm, mk_kode}              à      mk_nama

      {Mhs_npm, mk_kode}              à      mk_sks

      {Mhs_npm, mk_kode}              à      nihuruf

     

Ø  Tabel di atas perlu didekomposisi menjadi beberapa tabel yang memenuhi syarat 2NF

Functional dependencynya:

{Mhs_npm, mk_kode}  à    nihuruf                                             (fd1)

Mhs_npm                  à    {mhs_nama, mhs_alamat}                              (fd2)

Mk_kode                    à    {mk_nama, mk_sks}                          (fd3)

Jadi :

fd1             (mhs_nrp, mk_kode, nihuruf)             à Tabel Nilai

fd2             (Mhs_nrp, mhs_nama, mhs_alamat)    à Tabel Mahasiswa

fd3 (mk_kode, mk_nama, mk_sks)                      à Tabel MataKuliah

2.1.3        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.

Aturan :

ü    Sudah berada dalam bentuk normal kedua (2NF)

ü   Tidak ada ketergantungan transitif  (dimana atribut bukan kunci tergantung pada atribut bukan kunci lainnya).

Contoh :

Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF:

NPM

Nama

Alm_Jalan

Alm_Kota

Alm_Provinsi

Alm_Kodepos

Ø  karena masih terdapat atribut non primary key (yakni alm_kota dan alm_Provinsi) yang memiliki ketergantungan terhadap atribut non primary key yang lain (yakni alm_kodepos):

alm_kodepos à {alm_Provinsi, alm_kota}

Ø  Sehingga tabel tersebut perlu didekomposisi menjadi:

Mahasiswa (NPM, nama, alm_jalan, alm_kodepos)

Kodepos (alm_kodepos, alm_provinsi, alm_kota)

2.1.4        Boyce-Cod Normal Form (BCNF)

          Setelah 3NF, semua masalah normalisasi hanya melibatkan tabel yang mempunyai tiga kolom ataulebih dan semua kolom adalah kunci. Banyak praktisi berpendapat bahwa menempatkan entitas pada3NF sedah culup karena sangat jarang entitas yang berada pada entitas 3NF bukan merupakan 4NFdan 5NF. Lebih lanjut, mereka berpendapat bahwa keuntungan yang didapat dari mengubah entitas ke4NF dan 5NF sangat kecil sehingga tidak perlu dikerjakan.Bentuk Normal Boyce-Code (BCNF) adalah versi 3NF yang lebih teliti dan berhubungan dengan tabelrelasional yang mempunyai :

          (a) banyak kunci kandidat,

          (b) kunci kandidat gabungan, dan

          (c) kuncikandidat yang saling tumpang tindih.

          BCNF didasarkan pada konsep penentu. Sebuah kolom penentu adalah kolom di mana kolom-kolomlain sepenuhnya tergantung secara fungsional. Sebuah tabel relasional berada pada BCNF jika danhanya jika setiap penentu adalah kunci kandidat.

Contoh:

No_Mhs	No_Tlp	Kode_Mk	Nilai
0231	88681	AM211	A
0231	88681	PAM261	B
0231	88681	PAM367	A
0232	88682	PAM333	C
0232	88682	PAM241	A
0233	88683	PAM345	B
0343	88683	PAM337	A
0345	88685	PAM522	B

            Diasumsikan bahwa setiap mahasiswa mempunyai telepon dengan nomor yang berbeda. Relasi DAFT_NILAI mempunyai dua buah candidate key, yaitu No_Mhs+Kd_Mk dan No_Tlp+Kd_Mk. Atribut Kd_Mk berpartisipasi pada kedua candidate key. Sehingga ketiga keadaan sebagai penyebab munculnya BCNF ada pada relasi tersebut. Relasi tersebut tidak memuat transitive dependency jadi relasi memenuhi syarat bentuk normal ketiga (3NF).

Anomali:

            Jika akan disisipkan No_Tlp untuk seorang mahasiswa baru, hal ini tidak akan bisa dilakukan sebelum mahasiswa tersebut mengikuti minimal satu mata kuliah. Kegagalan ini karena nilai Kd_Mk, sebagai salah satu atribut yang berperan dalam primary key, tidak diketahui pada saat penyisipan. Jika akan dilakukan penghapusan pada tuple mahasiswa 0347 karena mahasiswa tersebut membatalkan mata kuliah PAM 432, informasi tentang nomor telepon mahasiswa tersebut ikut hilang.

            Untuk menghilangkan anomali, relasi dipecah menjadi dua buah relasi yang lebih kecil. Dalam memecah relasi tersebut perlu diperhatikan functional dependence yang ada yaitu:

            No_Mhs, Kd_Mk àNilai

            No_Tlp, Kd_Mk à Nilai

            No_Mhs à No_Tlp

Pada functional dependency ketiga, No_Mhs merupakan determinan tetapi bukan merupakan candidate key, sehingga relasi dipecah menjadi relasi nilai dan telepon.

Relasi bentuk normal Boycee-Codd

a.       NILAI (No_Mhs, Kode_Mk, Nilai)

No_Mhs	Kode_Mk	Nilai
0231	211	A
0231	261	B
0231	267	A
0232	333	C
0232	241	A
0233	345	B
0233	337	A
0345	522	B
0347	432	B

b.      TELEPON (No_Mhs, No_Tlp)

No_Mhs	No_Tlp
0231	88681
0232	88682
0233	88683
0345	88685

2.1.5        Normal Keempat (4NF)

               Bentuk normal 4NF terpenuhi dalam sebuah tabel jika telah memenuhi bentuk BCNF, dan tabel tersebut tidak boleh memiliki lebih dari sebuah multivalued attribute. Untuk setiap multivalued dependencies (MVD) juga harus merupakan functional dependencies.

Contoh :

Misal, tabel berikut tidak memenuhi 4NF:

               Setiap employee dapat bekerja di lebih dari project dan dapat memiliki lebih dari satu skill. Untuk kasus seperti ini tabel tersebut harus di-dekomposisi menjadi:

(Employee, Project)

(Employee, Skill)

2.1.6        Normal Kelima (5NF)

Ø  Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah lossless decomposition menjadi tabel-tabel yg lebih kecil.

Ø  Jika 4 bentuk normal sebelumnya dibentuk berdasarkan functional dependency, 5NF dibentuk berdasarkan konsep join dependence. Yakni apabila sebuah tabel telah di-dekomposisi menjadi tabel-tabel lebih kecil, harus bisa digabungkan lagi (join) untuk membentuk tabel semula

Contoh :

Terdapat hubungan dealer yang menangani suatu perusahaan distributor kendaraan, Dalam hal ini distributor memiliki sejumlah produk kendaraan.

Dealer	Distributor	Kendaraan
Sumber Jaya	Nissan	Truk Nissan
Sumber Jaya	Toyota	Toyota Kijang
Sumber Jaya	Toyota	Truk Dyna
Asterindo	Nissan	Sedan Nissan

                    Relasi tersebut memenuhi dependensi gabungan :

        (Dealer Distributor, Distributor Kendaraan, Dealer Kendaraan)

        Sehinggan relasi tersebut dapat didekomposisi menjadi 3 buah relasi, yaitu :

·         Deal _Dist (Dealer Distributor)

·         Dist_Kend (Distributor Kendaraan)

·         Deal_Kend (Dealer_Kendaraan)

                   

Bentuk normal kelima (5NF) yang terkadang disebut PJ/NF (Project Join/ Normal Form), menggunakan acuan dependensi gabungan.

Dealer	Distributor
Sumber Jaya	Nissan
Sumber Jaya	Toyota
Asterindo	Nissan

Distributor	Kendaraan
Nissan	Truk Nissan
Nissan	Sedan Nissan
Toyota	Toyota Kijang
Toyota	Truk Dyna

 

Dealer	Distributor	Kendaraan
Sumber Jaya	Nissan	Truk Nissan
Sumber Jaya	Nissan	Sedan Nissan
Sumber Jaya	Toyota	Toyota Kijang
Sumber Jaya	Toyota	Truk Dyna
Asterindo	Nissan	Truk Nissan
Asterindo	Nissan	Sedan Nissan

Dealer	Kendaraan
Sumber Jaya	Truk Nissan
Sumber Jaya	Sedan Nissan
Sumber Jaya	Toyota Kijang
Sumber Jaya	Truk Dyna
Asterindo	Sedan Nissan

BAB III

PENUTUP

3.1 Kesimpulan

Tahap-tahap proses reduksi pada normalisasi, yaitu :

1. Ambil projection pada relation 1NF awal untuk mengeliminasi semua nonfull functional dependence, sehingga menghasilkan relation 2NF.

2. Ambil projection pada relation 2NF untuk mengeliminasi semua transitive dependence, sehingga menghasilkan kumpulan relation 3NF.

3. Ambil projection pada relation 3NF untuk mengeliminasi semua sisa functional dependence di mana determinantnya bukan candidate key, sehingga menghasilkan relation BCNF.

Catatan : Tahap 1 sampai dengan 3 dapat dipersingkat sebagai berikut :

Ambil projection dari relation awal untuk mengeliminasi semua FD di mana determinantnya bukan candidate key.

4. Ambil projection pada relation BCNF untuk mengeliminasi MVD yang bukan FD juga, sehingga menghasilkan kumpulan relation 4NF.

5. Ambil projection pada relation 4NF untuk mengeliminasi semua JD yang bukan implementasi dari candidate key.

Seorang ahli (Fagin) menambahkan suatu tingkat normalisasi yaitu (3.3)NF sebagai peningkatan dari 3NF, serupa dengan BCNF, bukan merupakan 4NF. Selain itu juga menambahkan satu tingkat normalisasi lagi yaitu DK/NF (Domain Key Normal Form) yang tidak menyinggung sama sekali tentang FD, MVD maupun JD. DK/NF terjadi bila setiap relation yang terjadi memenuhi batasan-batasan (constraints) tertentu yaitu sebagai akibat dari batasan key (key constraints) dan batasan domain (domain constraints).

Key constraints adalah ketentuan/batasan tentang atribut atau kombinasinya yang merupakan candidate key.

Domain Constraints adalah ketentuan/batasan dimana nilai atribut tertentu berada pada himpunan nilai yang sudah ditentukan batas-batasnya.

Dinyatakan juga bahwa DK/NF juga otomatis 5NF, sehingga juga 4NF dan (3.3)NF. DK/NF tidak harus selalu tercapai dan tidak juga terjawabnya pertanyaan secara pasti kapan hal tersebut dapat dicapai.

3.2 Saran

Di dalam penulisan, penulis masih perlu untuk mencari buku panduan yang banyak membahas tentang normlisasi lanjut. Agar dalam penjelasan dapat terinci dan  mendefinikasikannya lebih singkat jelas berbobot dalam setiap katanya terdapat point-point yang bermanfaat. Begitu juga dalam pengolahan data yang lebih baik dan harus teliti.

Daftar Pustaka

http://yusup-doank-2.blogspot.com/2011/06/normalisasi-lanjutan.html

Sistem Basis Data – Normalisasi « Fairuz el Said.htm

http://dc335.4s.io/doc/rOm18mOf/preview.html

http://zulfiandri.wordpress.com/basis-data/normalisasi-data/