Normalisasi.

Presentasi berjudul: "Normalisasi."— Transcript presentasi:

1 Normalisasi

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

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

4 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 Record personil Id_Personil Alamat Umur Jabatan Pengurangan_gaji Tidak boleh, harus dipisahkan menjadi satu record sendiri Tgl_Pembayaran Diuraikan menjadi 2 record :

5 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. Record personil Id_Personil Tgl_Pembayaran Pengurangan_Gaji Alamat Umur Jabatan Record Pengurangan_Pembayaran_Gaji

6 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

7 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 dan telepon_kustomer maka karena nama_kustomer lebih merepotkan selain panjangnya maka lebih mudah menggunakan telepon_kustomer sebagai kunci.

8 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).

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

10 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. Kondisi 1 Kode-Kul NIM Kode_Nilai Kondisi 2 Kode-Kul NIM Kode_Nilai Nama_mhsKode_Nilai

11 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 :

12 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 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)

13 Pertama Tabel Mahasiswa atribut komposite dididekomposisikan,
Nim Nama_mhs Alamat_Jalan Nama_kota Kode_pos Tgl_lahir Nim Nama_mhs Alamat_mhs Tgl_lahir

14 Didekomposisikan lagi menjadi 2 tabel, Tabel_Mhs dan Tabel_Alamat
Nim Nama_mhs Alamat_Jalan Nama_Kota Tgl_Lahir Tabel Mhs Nim Nama_mhs Alamat_Jalan Nama_kota Kode_pos Tabel Alamat Alamat_Jalan Nama_kota Kode_pos

15 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 6 Okt 1978 980003 Buyut Biyung Jl.Adil No. 203, Bogor 13 Mei 1978 980004 Mathias Mulus Jl.Gajah Mada No. 23 Agt 1977 Alamat_mhs Nama_Kota Kode_Pos Jl.Merdeka No.10 Jakarta 40121 Jl.Gajah Mada No.2 45123 Jl.Adil No. 203 Bogor 43212 Karena terdapat 2 mahasiswa yang memiliki alamat sama, maka cukup disimpan satu saja

16 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 1 Alamat 2 Alamat_mhs Kode_Pos Nama_Kota Jl.Merdeka No.10 40121 Jakarta Jl.Gajah Mada No.2 45123 Jl.Adil No. 203, 43212 Bogor Jl.Gajah Mada No.2 Jakarta

17 Normalisasi 4 Normalisasi 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 5 Normalisasi tahap 5 berkaitan dengan relasi antar tabel. Pembahasan 4 dan 5 cukup rumit sehingga tidak terlalu dibahas pada mata kuliah ini.

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

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

20 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, DEPARTEMEN DEPARTEMEN SEKSI NAMAKARYAWANALAMAT KOTA  ALAMAT Akibat kita melakukan design table yang tidak dinormalisasi seperti diatas kita kan mengalami kesulitan untuk membentuk suatu relasi antara table.

21 No_Kyw Nama_Karyawan Departemen Seksi Alamat Kota 1 A. Hanif IT Application Dev Cideng Jakarta 2 Kusmawanti 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.

22 Table karyawan NoKyw Namakaryawan KodeDepartemen KodeSeksi Alamat
KodeKota Table Departemen KodeDepartemen NamaDepartement Table Seksi KodeDepartemen KodeSeksi NamaSeksi Table Kota KodeKota NamaKota

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

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

25 OLTP System Online Transaction Processing (Operational System) OLAP System Online Analytical Processing (Data Warehouse) Source of data Operational data; OLTPs are the original source of the data. Consolidation data; OLAP data comes from the various OLTP Databases Purpose of data To control and run fundamental business tasks To help with planning, problem solving, and decision support What the data Reveals A snapshot of ongoing business processes Multi-dimensional views of various kinds of business activities Inserts and Updates Short and fast inserts and updates initiated by end users Periodic long-running batch jobs refresh the data Queries Relatively standardized and simple queries Returning relatively few records Often complex queries involving aggregations Processing Speed Typically very fast Depends on the amount of data involved; batch data refreshes and complex queries may take many hours; query speed can be improved by creating indexes Space Requirements Can be relatively small if historical data is archived Larger due to the existence of aggregation structures and history data; requires more indexes than OLTP Database Design Highly normalized with many tables Typically de-normalized with fewer tables; use of star and/or snowflake schemas Backup and Recovery Backup religiously; operational data is critical to run the business, data loss is likely to entail significant monetary loss and legal liability Instead of regular backups, some environments may consider simply reloading the OLTP data as a recovery method