Wednesday, June 6, 2012

Posted by azhar_artazie Posted on 5:42 PM | 1 comment

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.










Categories:

1 comment:

  1. kita juga punya nih jurnal mengenai normalisasi data, silahkan dikunjungi dan dibaca , berikut linknya
    http://repository.gunadarma.ac.id/bitstream/123456789/5392/1/PPT%20WEW.pdf
    semoga bermanfaat yaa :)

    ReplyDelete