Perancangan Basis Data

Slides:



Advertisements
Presentasi serupa
NORMALISASI DATA Basis Data.
Advertisements

Normalisasi Pertemuan Minggu Ke-6.
TEKNIK PERANCANGAN BASIS DATA
Normalisasi.
Normalisasi Basis Data
Normalisasi Basis Data
Normalization 1.
NORMALISASI.
NORMALISASI.
Pengantar Basis Data Sumber :
NORMALISASI.
Normalisasi Basis Data
SISTEM BASIS DATA STMIK – AUB SURAKARTA
1 Analisis dan Perancangan Perangkat Lunak PEMODELAN DATA.
Definisi, Ketergantungan, Langkah-Langkah
Mentari Puji Lestari TI 2B D3
SQL 2. Database TRANSACTION Tabel yang terlibat : Customer berisi data pelanggan (nama, alamat, dll) OderInfo berisi info pemesanan oleh pelanggan (tgl.
Normalisasi (bagian I)
Perancangan Database Pertemuan 07 s.d 08
Sistem Basis Data Renni Angreni, M.Kom.
Normalisasi dan Functional Dependency
UNIVERSUTAS NEGERI MAKASSAR
Normalisasi Basis data 11.
C H A P T E R 4 Normalisasi 1NF Chapter 8 - Process Modeling.
1 Minggu 10, Pertemuan 20 Normalization (cont.) Matakuliah: T0206-Sistem Basisdata Tahun: 2005 Versi: 1.0/0.0.
Mapping dari ERD ke Tabel
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 9 Relational Database Design by ER- to-Relational Mapping.
NORMALISASI BASIS DATA
Database design Siti Asmiatun, M.Kom.
NORMALISASI.
NORMALISASI.
Materi Kuliah Basis Data
Perancangan Basis Data
MODEL RELASIONAL.
NORMALISASI.
Contoh kasus Normalisasi
Normalisasi PERTEMUAN KE-7.
Sistem Basis Data Rahajeng Ratnaningsih, S. Kom STMIK – AUB Surakarta
Transformasi Himpunan Dan Normalisasi
NORMALISASI DATA Basis Data.
Desain Basis Data – Bagian 6
Normalisasi Tabel Database.
Basis Data 1 Rudi Hartono, S.E, M.Kom.
Normalization 1.
DESAIN DATABASE DAN NORMALISASI
NORMALISASI.
Matakuliah : Sistem Basisdata Versi Materi
BAB 2 NORMALISASI.
Pertemuan Minggu Ke-10 NORMALISASI.
Desain Basis Data – Bagian 6
Normalization 1.
Normalisasi.
ISTILAH-ISTILAH DALAM NORMALISASI
Normalisasi.
PERTEMUAN KE-11 NORMALISASI DATA (I).
NORMALISASI PERTEMUAN 17.
Normalisasi Basis Data
Pertemuan ke-13 Normalisasi Betha Nurina Sari.
NORMALISASI DATA Gede Aditra Pradnyana, S.Kom., M.Kom.
DESAIN DATABASE DAN NORMALISASI
NORMALISASI SBD SESI 6.
NORMALISASI.
Normalisasi.
NORMALISASI.
Normalization 1.
Sistem Basis Data – Bab 4 NORMALISASI.
Normalisasi Didi Supriyadi, S.T., M.Kom Pertemuan ke-7
NORMALISASI SBD1 SESI 8.
Draw a picture that shows where the knife, fork, spoon, and napkin are placed in a table setting.
NORMALISASI DATABASE Achmad fitro, M.Kom.
Transcript presentasi:

Perancangan Basis Data Normalization Feri Sulianta Perancangan Basis Data Re-Arrange by : Education Fair Use material

Learning Objectives Referential Integrity Functional Dependency Transitive Dependency 1NF, 2NF, 3NF

NORMALISASI Normalisasi adalah suatu teknik untuk mengorganisasi data ke dalam table – table untuk memenuhi kebutuhan pemakai

Tujuan Dari Normalisasi Menghilangkan Kerangkapan Data Mengurangi Kompleksitas Mempermudah Pemodifikasian Data

Proses Normalisasi Data diuraikan dalam bentuk tabel, selanjutnya di analisis berdasarkan persyaratan tertentu ke beberapa tingkat Apabila tabel yang diuji belum memenuhi persyaratan, maka tabel tersebut perlu dipecah menjadi beberapa tabel yg lebih sederhana sampai memenuhi kriteria optimal

Tahapan Normalisasi BENTUK TIDAK NORMAL Menghilangkan perulangan group BENTUK NORMAL PERTAMA (1NF) Menghilangkan ketergantungan sebagian BENTUK NORMAL KEDUA (2NF) Menghilangkan ketergantungan transitif BENTUK NORMAL KETIGA (3NF)

Ketergantungan Fungsional Atribut Y pada relasi R dikatakan tergantung fungsional pada atribut X, jika dan hanya jika stp nilai X pada relasi R mempunyai tepat satu nilai Y pada R Misal,terdapat skema db pemasok-barang: pemasok(no-pem,na-pem)

Tabel Pemasok-barang CTH KET FUNGSIONAL : NO-PEMNA-PEM NO-PEM NA-PEM BAHARU SINAR HARAPAN CTH KET FUNGSIONAL : NO-PEMNA-PEM

Ketergantungan Fungsional Penuh Atribut y pada relasi r dikatakan tergantung fungsional penuh pada atribut x pd relasi r, jika y tidak tergantung pd subset dr x (bila x adalah key gabungan) Kirim-barang(no-pem,na-pem, nobar, jumlah)

Tabel Kirim-barang CTH KET FUNGSIONAL : NO-PEMNA-PEM NO-BAR JUMLAH P01 P02 P03 BAHARU SINAR HARAPAN B01 B02 B03 1000 1500 2000 CTH KET FUNGSIONAL : NO-PEMNA-PEM NO-BAR,NO-PEMJUMLAH (TERGANTUNG PENUH THD KEYNYA)

Ketergantungan Sebagian NO-PEM KODE-KOTA KOTA NO-BAR JUMLAH P01 P02 P03 1 3 2 JAKARTA BANDUNG SURABAYA B01 B02 B03 1000 1500 2000

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)

Ketergantungan Transitif NO-PEM KODE-KOTA KOTA NO-BAR JUMLAH P01 P02 P03 1 3 2 JAKARTA BANDUNG SURABAYA B01 B02 B03 1000 1500 2000 KET FUNGSIONAL : NO-PEM  KODE-KOTA KODE-KOTA  KOTA, MAKA NO-PEM  KOTA

CONTOH NORMALISASI BENTUK UN NORMAL s/d BENTUK NORMAL KE-TIGA (3NF)

Tabel Kirim-1 (Unnormal) NO-PEM KODE-KOTA KOTA NO-BAR JUMLAH P01 P02 P03 1 3 2 JAKARTA BANDUNG SURABAYA B01 B02 B03 1000 1500 2000

Bentuk Normal Kesatu (1nf) Suatu relasi dikatakan sdh memenuhi bentuk normal kesatu bila setiap data bersifat atomik, yaitu setiap irisan baris dan kolom hanya mempunyai satu nilai data

Tabel Kirim-2 (1nf) NO-PEM KODE-KOTA KOTA NO-BAR JUMLAH P01 P02 P03 1 JAKARTA BANDUNG SURABAYA B01 B02 B03 1000 1500 2000

KODE-KOTA NO-PEM JUMLAH KOTA NO-BAR 1 3 2 JAKARTA BANDUNG SURABAYA B01 B02 B03 1000 1500 2000 KODE-KOTA NO-PEM JUMLAH KOTA NO-BAR

Bentuk Normal Kedua (2nf) Suatu relasi dikatakan sdh memenuhi bentuk normal kedua bila relasi tersebut sudah memenuhi bentuk normal pertama dan atribut yang bukan key sudah tergantung penuh terhadap key nya

Tabel Pemasok-1 (2nf) NO-PEM KODE-KOTA KOTA P01 P02 P03 1 3 2 JAKARTA BANDUNG SURABAYA

Bentuk Normal Kedua (2nf) TABEL KIRIM-3 (2NF) NO-PEM NO-BAR JUMLAH P01 P02 P03 B01 B02 B03 1000 1500 2000

Bentuk Normal Ketiga (3nf) Suatu relasi dikatakan sdh memenuhi bentuk normal ketiga bila relasi tersebut sudah memenuhi bentuk normal kedua dan atribut yang bukan key sudah tidak tergantung transitif terhadap key nya

Bentuk Normal Ketiga (3nf) TABEL KIRIM-3 (3NF) NO-PEM NO-BAR JUMLAH P01 P02 P03 B01 B02 B03 1000 1500 2000 TABEL PEMASOK-2 (3NF) TABEL PEMASOK-3 (3NF) KODE-KOTA KOTA 1 3 2 JAKARTA BANDUNG SURABAYA NO-PEM KODE-KOTA P01 P02 P03 1 3 2

The Question & Quiz Ubah bentuk tabel tidak normal berikut sampai memenuhi bentuk normal 3 (3NF)

Normalisasi Database Perkuliahan NO-MHS NAMA-MHS KODE- MK JURUSAN NAMA-MK KODE- DOSEN NAMA-DOSEN NILAI 2683 5432 WELLI BAKRI MI350 MI465 AK201 MK300 MI AK MANAJEMEN DB ANALISIS PRC SISTEM AKUNT.KEUANGAN DASAR PEMASARAN B104 B317 D310 B212 ATI DITA LIA LOLA A B C ASUMSI : SEORANG MHS DAPAT MENGAMBIL BEBERAPA MATAKULIAH SATU MATAKULIAH DAPAT DIAMBIL OLEH LBH DR 1 MHSW SATU MATAKULIAH HANYA DIAJARKAN SATU DOSEN SATU DOSEN DAPAT MENGAJAR BEBERAPA MATAKULIAH SEORANG MHSW PD MATAKULIAH TERTENTU HANYA MEMPUNYAI SATU NILAI

Diagram Ketergantungan Fungsional NAMA-MHS NO-MHS JURUSAN NILAI NAMA-MK KODE-MK KODE-DOSEN NAMA-DOSEN

Normalisasi – Contoh II

Un Normal Form The data we would want to store could be expressed as: Project No Project Name Employee No Employee Name Rate category Rate 1203 Madagascar travel site 11 Jessica Brookes A £90 12 Andy Evans B £80 16 Max Fat C £70 1506 Online estate agency 17 Alex Branton

Normalization 1 We could place the data into a table called: tblProjects_Employees Project No. Project Name Employee No. Employee Name Rate category Rate 1203 Madagascar travel site 11 Jessica Brookes A £90 12 Andy Evans B £80 Madagascat travel site 16 Max Fat C £70 1506 Online estate agency 17 Alex Branton

Normalization 2 We now have 3 tables: tblProjects Project No Project Name 1023 Madagascar travel site 1056 Online estate agency tblProjects_Employees Project No Employee No 1023 11 12 16 1056 17 tblEmployees Employee No Employee Name Rate Category Rate 11 Jessica Brookes A £90 12 Andy Evans B £80 16 Max Fat C £70 17 Alex Branton

Normalization Looking at the project note the reduction in: Redundant data The text “Madagascar travel site” is stored once only, not for each occurrence of an employee working on the project. Inconsistent data Because we only store the project name once we are less likely to enter “Madagascat” The link is made through the key, Project No. Obviously there is no way to remove this duplication without losing the relation altogether, but it is far more efficient storing a short number repeatedly, than a large chunk of text.

Normalization The solution, as before, is to remove this excess data to another table. We do this by: Looking for Transitive Relationships Relationships where a non-key attribute is dependent on another non-key attribute. Hourly rate should depend on rate category BUT rate category is not a key Removing Transitive Relationships As before we remove the redundant data and place it in a separate table. In this case we create a new table tblRates and add the fields rate category and hourly rate. We then delete hourly rate from the employees table.

Normalization 3 We now have 4 tables: tblProjects Project No Project Name 1023 Madagascar travel site 1056 Online estate agency tblProjects_Employees Project No Employee No 1023 11 12 16 1056 17 tblEmployees Employee No Employee Name Rate Category 11 Jessica Brookes A 12 Andy Evans B 16 Max Fat C 17 Alex Branton tblRates Rate Category Rate A £90 B £80 C £70

Normalization Again, we have cut down on redundancy and it is now impossible to assume Rate category A is associated with anything but £90. Our model is now in its most efficient format with: Minimum REDUNDANCY Minimum INCONSISTENCY

Normalisasi – Contoh III

First Normal Form (1NF) “Flattening” the table All columns (fields) must have no repeating items in columns Solution: make a separate table for each set of attributes with a primary key (parser, append query)

Second Normal Form (2NF) In 2NF and every non-key column is fully dependent on the (entire) primary key Means : Does the key field imply the rest of the fields? Do we need to know both OrderID and Item to know the Customer and Date? Solution: Remove to a separate table (Make Table)

Third Normal Form (3NF) In 3NF, every non-key column is mutually independent means : no transitive dependency like calculations Solution: Put calculations in queries and forms

Transitive Dependency Transitive Dependency is a condition where A, B and C are attributes of a relation such that if A  B and B  C, then C is transitively dependent on A through B. (Provided that A is not functionally dependent on B or C).

DreamHome Example

Example - Normalization UNF to 1NF Relation

Example - Normalization UNF to 1NF Relation

Example - Normalization UNF to 1NF Relation

Second Normal Form (2NF) A relation that is in 1NF, and Every non-primary-key attribute is functionaly dependent only on the primary key, but not any subset of the primary key.

1NF to 2NF Identify the primary key for the 1NF relation. Identify the functional dependencies in the relation. If partial dependencies exist on the primary key remove them by placing them in a new relation.

FDs for Customer_Rental Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Customer (Customer_No, Cname) Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)

FDs for Customer_Rental Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Customer (Customer_No, Cname) Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)

FDs for Customer_Rental Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Customer (Customer_No, Cname) Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)

FDs for Customer_Rental Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Customer (Customer_No, Cname) Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)

FDs for Customer_Rental Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Customer (Customer_No, Cname) Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)

Example - Normalization Customer_Rental to 2NF Relations

Third Normal Form (3NF) Remove transitive dependency. E.g.: Property_Owner (Property_No, PAddress, Rent, Owner_No, OName) Therefore, the 3 NF is a relation that is in 1NF and 2NF and in which no non-primary-key attribute is transitively dependent on the primary key.

2NF to 3NF Identify the primary key in the 2NF relation. Identify functional dependencies in the relation. If transitive dependencies exist on the primary key remove them by placing them in a new relation along with a copy of their dominant.

Example - Normalization FDs for Customer_Rental Relation

Example - Normalization Property_Owner to 3NF Relations 39

Example - Normalization Process of Decomposition

Summary of 3NF Relations 41