Normalisasi

Suatu data model harus bersih dari : ketidak konsistensian, redundansi, duplikasi dll. Untuk itu diperlukan upaya Normalisasi sehingga setiap atribut pada data model hanya memiliki satu nama yang unik.

Normalisasi adalah suatu usaha untuk melakukan analisa terhadap model data untuk mendapatkan bahwa setiap atribut dalam suatu entitas akan sangat bergantungan, atau secara sederhana dapat dikatakan bahwa dalam prakteknya bahwa yang dapat dimasukkan dalam Entitas (Record) Personil atribut (atau field) adalah sesuatu yang menjelaskan tentang personil itu sendiri, bila tidak taruh ditempat lainnya.

Misalnya, ada record Personil, maka pada record personil tersebut bisa dimasukkan segala item data yang berkaitan dengan objek data personil tersebut, seperti pada contoh, namun hal tersebut tidak dianjurkan oleh teori basis data

Id_Personil Alamat Umur Jabatan Pengurangan_gaji

Tidak boleh, harus dipisahkan menjadi satu record sendiri

Tgl_Pembayaran

Diuraikan menjadi 2 record :

Record personil

tabel Perosnil tersebut di uraikan (decomposition) menjadi 2 tabel yang terpisah dimana pada tabel Personil yang baru setiap field akan berisi : Id-personil, alamat, umur, jabatan, tidak boleh ada Tgl_pembayaran, Pengurangan-gaji, yang ini harus dibuat satu tabel tersendiri, misalnya dinamakan Tabel Pembayaran memiliki record Pengurangan-Pembayaran dimana field atau atributnya menjelaskan tentang : Id-personil, tgl-pembayaran, pengurangan-gaji dst.

Id_Personil Tgl_Pembayaran Pengurangan_Gaji

Id_Personil Alamat Umur Jabatan

Record personil

Record Pengurangan_Pembayaran_Gaji

Normalisasi 1

Definisinya adalah :Semua entitas harus memiliki kunci, gabungan dari kombinasi satu atau lebih atribut yang secara unik mengidentifikasikan satu kemunculan dari entitas tersebut.

Untuk setiap kemunculan satu entitas maka setiap atribut harus memiliki satu dan hanya satu nilai (value). Atau dengan kata lain sebuah table terpenuhi pada bentuk normal tahap satu bila table tersebut tidak memiliki atribut bernilai banyak /pengulangan grup

Persyaratan 1 pada normalisasi 1 adalah bahwa setiap entitas harus punya kunci, contoh nomor_part menunjukkan satu buah part akan tetapi bila yang digunakan nama_kustomer dantelepon_kustomer maka karena nama_kustomer lebih merepotkan selain panjangnya maka lebih mudah menggunakan telepon_kustomer sebagai kunci.

Persyaratan 2 pada normalisai 1 adalah setiap entitas harus bebas dari pengulangan grup, contoh 1 : record departemen, kita ketahui bahwa pada satu departemen banyak personil yang bekerja, sehingga apabila recordnya berisikan atribut : Id_departemen dan Id_personil, maka dengan satu Id_departemen akan memunculkan banyak Id-personil ini akan menghasilkan error karena Id_personil akan muncul berulang-ulang dan banyak., maka untuk itu Id_personil harus dikeluarkan dari record departemen dan dijadikan satu record sendiri yang kita namakan, misalnya record personil, adapun hubungan antara departemen dengan personil adalah 1 ke banyak (1 to M).

Normalisasi 2

Definisinya adalah :Suatu relasi dikatakan pada normalisasi tahap 2 adalah jika dan hanya jika berada dalam normalisasi 1 dan hanya jika setiap atribut benar2 tergantung fungsional (KF) pada primari key secara utuh. Suatu relasi tidak pada tahap 2 apabila ketergantungannya masih parsial, masih ketergantungan pada selain primer key.

Contoh : pada rekord nilai ada pada tahap 2, namun apabila ditambahkan field nama-mahasiswa maka relasi dikatakan tidak pada normalisasi 2, karena nama-mahasiswa tidak tergantung pada kode_kul, hanya tergantung pada NIM, sedangkan kode_kul adalah prime key juga. Untuk itu nama mahasiswa harus dikeluarkan dari rekord nilai.

Record nilai, pada kondisi I record nilai telah memenuhi tahap 2N tapi bila + tuple /item data/field nama-_mhs (Kondisi II) maka record nilai tidak lagi pada normalisasi 2.

Kode-Kul NIM Kode_Nilai

Kode-Kul NIM Kode_NilaiNama_mhsKode_Nilai

Kondisi 2

Kondisi 1

Normalisasi 3

Definisinya adalah :Suatu relasi dikatakan pada normalisasi tahap 3 adalah jika dan hanya jika berada pada normalisasi tahap 2 dan setiap atribut bukan key nontransitif tergantung pada primari key. Atau dapat dikatakan bahwa non key atribut tidak boleh tergantung pada non key atribut lainnya. Contoh relasi dalam tabel Mahasiswa :

Tabel Mahasiswa

Nim Nama_mhs Alamat_mhs Tgl_lahir

980001 Ahmad Ablar Jl.Merdeka No.10 Jakarta 40121 2 Jan 1979

980002 Boedipekerti Jl.Gajah Mada No.2 Jakarta 45123 6 Okt 1978

980003 Mathias Mulus Jl.Adil No. 203, Bogor 43212 13 Mei 1978

980004 Buyut Biyung Jl.Gajah Mada No.2 Jakarta 45123 23 Agt 1977

Pada relasi tabel mahasiswa maka alamat_mhs adalah atribut komposit, yang berisi nama jalan, nomor rumah, nama_kota, kode_pos., demikian Tgl_lahir tediri atas tangggal, bulan, tahun (defoult system)

Pertama Tabel Mahasiswa atribut komposite dididekomposisikan,

Nim

Nama_mhs

Alamat_Jalan

Nama_kota

Kode_pos

Tgl_lahir

Nim

Nama_mhs

Alamat_mhs

Tgl_lahir

Tabel Mhs

Nim

Nama_mhs

Alamat_Jalan

Nama_kota

Kode_pos

Tabel Mhs

Nim

Nama_mhs

Alamat_Jalan

Nama_Kota

Tgl_Lahir

Tabel Alamat

Alamat_Jalan

Nama_kota

Kode_pos

Didekomposisikan lagi menjadi 2 tabel, Tabel_Mhs dan Tabel_Alamat

Nim Nama_mhs Alamat_Jalan Nama_Kota Tgl_Lahir

980001 Ahmad Ablar Jl.Merdeka No.10 Jakarta 2 Jan 1979

980002 Boedipekerti Jl.Gajah Mada No.2 Jakarta 6 Okt 1978

980003 Buyut Biyung Jl.Adil No. 203, Bogor 13 Mei 1978

980004 Mathias Mulus Jl.Gajah Mada No. Jakarta 23 Agt 1977

Alamat_mhs Nama_Kota Kode_Pos

Jl.Merdeka No.10 Jakarta 40121

Jl.Gajah Mada No.2 Jakarta 45123

Jl.Adil No. 203 Bogor 43212

Karena terdapat 2 mahasiswa yang memiliki alamat sama, maka cukup disimpan satu saja

Tabel 2, belum sampai tahap 3 dan belum memenuhi BCNF, karena perlu dipecah/ diuraikan lebih lanjut karena ketiganya dapat merupakan key dari yang lain.

Alamat_mhs Kode_Pos Kode_Pos Nama_Kota

Jl.Merdeka No.10 40121 40121 Jakarta

Jl.Gajah Mada No.2 45123 45123 Jakarta

Jl.Adil No. 203, 43212 43212 Bogor

Jl.Gajah Mada No.2 Jakarta 45123

Alamat 1 Alamat 2

Normalisasi 4Normalisasi sampai dengan tahap 3 sudah cukup memadai untuk tabel memiliki kualitas baik, namun kadang pembahasan normalisasi tahap 4 dilakukan karena adanya sifat ketergantungan banyak nilai pada satu tabel dan merupakan pengembangan dari ketergantungan fungsional

Normalisasi 5Normalisasi tahap 5 berkaitan dengan relasi antar tabel. Pembahasan 4 dan 5 cukup rumit sehingga tidak terlalu dibahas pada mata kuliah ini.

•Normalisasi dan denormalisasi memiliki kelebihan dan kekurangan.•Normalisasi akan meningkatkan data integrity tetapi akan juga meningkatkan Query complexity.•Sebaliknya Denormalisasi akan mengurangi data integrity dan juga mengurangi Query Compexity

Tujuan normalisasi adalah untuk membuat agar data yang ada tidak redundan dan memiliki data integrity yang kuat sehingga ketika kita melakukan relasi antara table akan dengan mudah kita menjaga dataintegrity dan mendapatkan datanya.

Normalisasi Table sendiri terbagi atas bentuk normal ke 1 sampai bentuk normal ke 4. lebih jelasnya baca tentang konsep RDBMS.

Bentuk Table yang tidak memenuhi bentuk normal (tidak dinormalisasi contohnya)Table DATAKARYAWANNo_KYW, NAMAKARYAWAN, DEPARTEMEN, SEKSI, ALAMAT, KOTADalam menentukan normalisasi suatu database akan bergantung pada Functional Dipendency dari setiap Tuple (Field/Column) yang akan menentukan seberapa normal Satu Table.

Dari Gambaran diatas Table DDATAKARYAWAN merupakan Table yang tidak dinormalisasi. Karena kita tidak melihat adanya Functional Dipendency

Kalo kita lihat kemungkinan ketergantungan fungsinal ( artinya tergantung pada) yang berlaku adalah :No NAMAKARYAWAN, DEPARTEMENDEPARTEMEN SEKSINAMAKARYAWANALAMATKOTA ALAMAT

Akibat kita melakukan design table yang tidak dinormalisasi seperti diatas kita kan mengalami kesulitan untuk membentuk suatu relasi antara table.

No_Kyw

Nama_Karyawan Departemen Seksi

Alamat Kota

1 A. Hanif IT Application Dev

Cideng Jakarta

2 Kusmawanti IT Application Dev Cideng Jakarta

3 Boboy Sales

Telesales

Ancol Bekasi

Jika boboy kita hapus dari Table Kita maka Data departemen Sales juga akan terhapus berikut Kota bekasi (Integritas data Terganggu). Padahal Departemen sales tetap ada meskipun tidak memiliki karyawan demikian juga dengan kota bekasi. Sehingga untuk kasus ini perlu di normalisasi menjadi table berikut.

Table karyawan

NoKyw Namakaryawan KodeDepartemen KodeSeksi Alamat KodeKota

Table Departemen

KodeDepartemen NamaDepartement

Table Seksi

KodeDepartemen KodeSeksi NamaSeksi

Table Kota

KodeKota NamaKota

Dengan struktur hasil normalisasi ini memungkinkan data integrity akan tetap terjamin. Untuk meningkatkan performance dan data integrity ini proses normalisasi dilakukan dan sebagian besar dilakukan dalam OLTP.

Setiap ketergantungan fungsional pada colum di suatu table pada implementasinya akan memungkinkan column tersebut dinominasilkan menjadi KEY baik itu Primary Key maupun secondary Key, dan dari sinilah konsep penentuan Key dan Index dimulai pada tahapan design. yang pada akhirnya akan mementukan waktu akses yang diperlukan untuk mendapatkan suatu informasi dari table yang kita design. sini kita baru mulai menentukan desain database yang mempertimbangkan performance.

kapan denormalisasi dilakukan? Biasanya Untuk OLAP dan DataWarehouse Pendekatan designnya berbeda dengan OLTP sebagian besar table dibuat denormalized untuk lebih meningkatkan performace. Desaign yang dibuat menggunakan Star schema atau snowflake Schema.

The design of a data warehouse database and online analytical processing (OLAP) cubes is fundamentally different than a transactional processing database (OLTP). The data warehouse is specifically designed to facilitate super fast query times and multi-dimensional analysis. The following table summarizes the major differences between OLTP and OLAP system design.

OLTP SystemOnline Transaction Processing(Operational System)

OLAP SystemOnline Analytical Processing(Data Warehouse)

Source of data Operational data; OLTPs are the original sourceof the data.

Consolidation data; OLAP data comes from thevarious OLTP Databases

Purpose of data To control and run fundamental business tasks

To help with planning, problem solving, anddecision support

What the dataReveals

A snapshot of ongoing business processes Multi-dimensional views of various kinds ofbusiness activities

Inserts andUpdates

Short and fast inserts and updates initiated byend users

Periodic long-running batch jobs refresh the data

Queries Relatively standardized and simple queriesReturning relatively few records

Often complex queries involving aggregations

ProcessingSpeed

Typically very fast Depends on the amount of data involved; batchdata refreshes and complex queries may takemany hours; query speed can be improved bycreating indexes

SpaceRequirements

Can be relatively small if historical data isarchived

Larger due to the existence of aggregationstructures and history data; requires more indexesthan OLTP

DatabaseDesign

Highly normalized with many tables Typically de-normalized with fewer tables; use ofstar and/or snowflake schemas

Backup andRecovery

Backup religiously; operational data is critical to run the business,data loss is likely to entailsignificant monetary loss and legal liability

Instead of regular backups, some environmentsmay consider simply reloading the OLTP data as arecovery method