NORMALISASI

selamat malem  sobat-sobat,..
sudah seminggu gak mosting, kadang kangen juga,..
sekarang kita akan bahas NORMALISASI hoho,. sepertinya susah ya, menormalkan database,.
tapi enggak kok, sekarang kita gak makek postgreSQL atau MYSQL. tapi memakai microsoft exel,
kelihatannya mudahkan, nah sebelum kita coba,

A. Landasan Teori

LANGKAH-LANGKAH PEMBENTUKAN NORMALISAS

• 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. Data dikumpulkan apa adanya sesuai dengan saat menginput.

Dari tabel di Pelanggan Biaya (Tabel 9.3) di atas terdapat multiple value pada beberapa atributnya. Misalkan terdapat dua (2) nilai untuk No_Property yaitu PG4 dan PG16 untuk Nama Pelanggan (Nama) Badi. 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)

• BENTUK NORMAL KE SATU (FIRST NORMAL FORM / 1 NF)

Pada tahap ini dilakukan penghilangan beberapa group elemen yang berulang agar menjadi 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:

Setiap data dibentuk dalam flat file, data dibentuk dalam satu record demi satu record nilai dari field berupa “atomic value”.

tidak ada set atribute yang berulang atau bernilai ganda.

telah ditentukannya primary key untuk tabel / relasi tersebut.

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 Pelanggan yang sesuai pada setiap baris. Hasil dari tabel yang telah memenuhi bentuk normal pertama dapat dilihat pada Tabel 9.4. kita dapat mengidentifikasi primary key untuk relasi 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)

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

FULL FUNCTIONAL DEPENDENCY (Ketergantungan Fungsional Sepenuhnya)

Suatu ketergantungan fungsional A →B adalah ketergantungan fungsional sepenuhnya, jika perpindahan beberapa atribut dari A menghasilkan tepat satu pasangan pada atribut B. Suatu ketergantungan fungsional A →B adalah ketergantungan fungsional sebagian, jika ada beberapa atribut yang dapat dihilangkan dari A sementara ketergantungan tersebut tetap berlaku /berfungsi.

Sebagai contoh dapat dilihat pada suatu ketergantungan fungsional di bawah ini.
NIK, Nama →Kd_Cabang.
Dari kasus di atas dapat dikatakan bahwa masing-masing nilai dari NK, Nama berasosiasi/berelasi dengan nilai tunggal dari Kd_Cabang. Dengan demikian, relasi di atas tidak memiliki ketergantungan fungsional sepenuhnya (full funcional dependency), karena Kd_Cabang juga masih memiliki ketergantungan fungsional pada himpunan bagian dari (NIK, Nama). Dengan kata lain, Kd_Cabang adalah Full functional dependecy hanya pada NIK.

Bentuk normal kedua memungkinkan suatu relasi memiliki composite key, yaitu relasi dengan primary key yang terdiri dari dua atau lebih atribyut. Suatu relasi yang memiliki sigle atribut untuk primary keynya secara otomatis pada akhirnya menjadi 2-NF. Syarat normal kedua (2-NF) sebagai berikut.

Bentuk data telah memenuhi kriteria bentuk normal kesatu.

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

Dengan demikian untuk membentuk normal kedua haruslah sudah ditentukan primary keynya. Primary key tersebut haruslah lebih sederhana, lebih unik, dapat mewakili atribute lain yang menjadi anggotanya, dan lebih sering digunakan pada tabel / relasi tersebut.

Langkah pertama kita harus mengidentifikasi ketergantungan fungsional dalam relasi Pelanggan_Biaya, sebagai berikut.

No_Pelanggan, No_Property →Tgl_Pinjam, Tgl_Selesai

No_Pelanggan →Nama

No_Property →Alamat_Property, Biaya, No_Pemilik, Nama_Pemilik

No_Pemilik → Nama_Pemilik

Gambar 9.2 di bawah ini akan mengilustrasikan ketergantungan fungsional yang berada dalam relasi Pelanggan_Biaya.
Berdasarkan Functional Dependency (Ketergantungan Fungsional) relasi Pelanggan_Biaya pada gambar 9.2 di atas, maka dapat dilihat beberapa kondisi sebagai berikut.

Primary key pada Pelanggan_Biaya di atas adalah No_Pelanggan, dan No_Property.

Atribut Pelanggan (Nama) hanya memiliki (partially dependency) ketergantungan pada sebagian / pada salah satu primary key di relasi Pelanggan_Biaya yaitu hanya atribut No_Pelanggan.

Sementara atribut-atribut property (Alamat_property, Biaya, No_Pemilik,Nama_Pemilik), juga hanya memiliki (partially dependency) ketergantungan pada sebagian / pada salah satu primary key di relasi Pelanggan_Biaya yaitu hanya atribut No_Property.

Atribut-atribut Biaya Property (Tgl_Pinjam, Tgl_Selesai), memiliki (fully dependent) tergantung sepenuhnya pada semua primary key di relasi Pelanggan_Biaya yaitu atribut No_Pelanggan, dan No_Property.

Pada gambar 9.2 di atas juga menunjukkan sebuah (transitive dependency) ketergantungan transitif terhadap primary key, namun hal itu tidak akan melanggar ketentuan pada normalisasi ke dua (2-NF). Ketergantungan transitive akan dihilangkan pada normalisasi ketiga (3-NF).

Seluruh identifikasi yang dilakukan pada point 1 sampai 4 di atas menunjukkan bahwa relasi Pelanggan_Biaya di atas belum memenuhi kriteria bentuk normal ke dua (2-NF). Kita perlu membuat beberapa relasi Pelanggan_Biaya di atas ke dalam bentuk normal ke dua (2-NF), agar seluruh atribut non-key (yang bukan primary key) dapat memiliki ketergantungan sepenuhnya (full functionally dependent) terhadap primary key.
Ketiga buah relasi tersebut dapat ditulis dalam bentuk ini.

Relasi / Tabel Pelanggan dengan atribut-atribut: No_Pelanggan, Nama. {No_Pelanggan berfungsi sebagai primary key pada tabel / relasi tersebut}.

Relasi / Tabel Biaya dengan atribut-atribut: No_Pelanggan, No_Property,Tgl_Pinjam, Tgl_Selesai. {No_Pelanggan dan No_Property berfungsi sebagai primary key pada tabel / relasi tersebut}.

Relasi / Tabel Property_Pemilik dengan atribut-atribut: No_Property, Alamat_Property, Biaya, No_Pemilik, Nama_Pemilik. { No_Property berfungsi sebagai priamry key pada tabel / relasi tersebut}.

Tabel / Relasi yang telah memenuhi kriteria normal ke dua (2-NF) adalah sebagai berikut.

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 di dalam 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).

Transitive Dependency (ketergantungan transitif)
Suatu kondisi dimana A, B, dan C adalah atribut-atribut dari suatu relasi sedemikian sehingga A âB dan B âC, maka A âC (C memiliki ketergantungan transitif terhadap A melalui B), dan harus dipastikan bahwa A tidak memiliki ketergantungan fungsional (functional dependent) terhadap B atau C).
Sebagai contoh dapat dilihat ketergantungan fungsional yang ditunjukkan pada relasi Staff_Brach di Tabel 9.3 sebagai berikut. NIK âKd_Cabang dan Kd_ Cabang âAlamat_Cabang

Dapat dilihat ketergantungan transitif NIK âAlamat_Cabang dapat terjadi melalui atribut Kd_Cabang.
Syarat normal ketiga (Third Normal Form / 3 NF) sebagai berikut.

Bentuk data telah memenuhi kriteria bentuk normal kedua.

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.

Sebagai contoh kita dapat melihat beberapa ketergantungan fungsional (functinal dependencies) pada relasi Pelanggan, Biaya, dan Property_Pemilik berikut ini.

Relasi / Tabel Pelanggan terdiri dari atribut-atribut:
No_Pelanggan âNama {No_Pelanggan sebagai primary key}

Relasi / Tabel Biaya terdiri dari atribut-atribut:
No_Pelanggan, No_property âTgl_Pinjam, Tgl_Selesai{No_Pelanggan, dan No_property sebagai primary key}

Relasi / Tabel Property_Pemilik terdiri dari atribut-atribut
No_property âAlamat_Property, Biaya, No_Pemilik, Nama_Pemilik,No_Pemilik âNama_Pemilik{No_property sebagai primary key}

Seluruh atribut non-primary key pada relasi Pelanggan dan Biaya di atas terlihat memiliki ketergantungan fungsional (functional dependency) terhadap primary key dari masing-masing tabel / relasi. Relasi / tabel Pelanggan dan Biaya di atas tidak memiliki ketergantungan transitif (transitive dependency), sehingga tabel tersebut telah memenuhi kriteria normal ketiga (3-NF).

Seluruh atribut non-primary key pada relasi Property_Pemilik di atas terlihat memiliki ketergantungan fungsional (functional dependency) terhadap primary key, kecuali Nama_Pemilik yang masih memiliki ketergantungan fungsional (functional dependency) terhadap No_Pemilik. Inilah contoh ketergantungan dari transitif (transitive dependency), yang terjadi ketika atribut non-primary key (Nama_Pemilik) bergantung secara fungsi terhadap satu atau lebih atribut non-primary key lainnya (No_Pemilik). Kita harus menghilangkan ketergantungan transitif (transitive dependency) tersebut dengan menjadikan relasi Property_Pemilik menjadi 2 relasi / tabel dengan format / bentuk sebagai berikut.

Relasi / Tabel Property_Untuk_Pemilik yang terdiri dari atribut-atribut:
No_property âAlamat_Property, Biaya, No_Pemilik{No_property sebagai primary key}

Dan relasi Pemilik yang terdiri dari atribut-atribut:
No_Pemilik âNama_Pemilik{No_Pemilik sebagai primary key}

Bila digambarkan ke dalam tabel menjadi seperti berikut ini.

Kita dapat membuat suatu diagram dekomposisi yang akan menjelaskan proses / tahapan uji normalisasi dari bentuk normal kesatu sampai dengan normal ketiga pada relasi Pelanggan_Biaya seperti pada gambar 9.5

Hasil akhir normalisasi tabel Pelanggan_Biaya sampai ke bentuk normal ketiga adalah sebagai berikut.

B. Hasil Praktikum

1. bentuk unnormalisasi

2. bentuk 1 NF (ini berbentuk 1 table, tapi berhubung pkek snipping tool eh jdi 2)

3. 2 NF

3. 3 NF

4. Hasil Akhir

yang ini tugas rumah hehe

1. bentuk unnormalisasi

2. 1 NF

3. 2 NF

4. 3 NF

5 . hasil akhir

C. KESIMPULAN

menuru dasar teori yang telah kita simak di atas,.. 

Normalisasi dapat kita katakan adalah suatu langkah sistematis untuk menjamin akan struktur database memungkinkan untuk general purpose query dan bebas dari insertion dan deletion anomalies.

tapi Normalisasi ini menyebabkan hilangnya integrasi data.

D. kritik dan saran

nah kita telah selesai membuat normalisasi pada table, gampang kan,.
cuma di ketik, dan mengatur mulai unnormalisasi, menjadi 1 NF, 2 NF, 3 NF sampai hasil akir,.
saran
kalau ngerjain usahakan teliti ya,.. :)

 daftar pustaka

modulDBD-uin maliki malang

http://serba---ada.blogspot.com/2012/12/normalisasi-database.html

http://informatika.web.id/definisi-dan-tujuan-normalisasi.htm