Model Basis Data Relasional IK203 Sistem Basis Data Pertemuan #3 Suryo Widiantoro, ST, MMSI, M.Com(IS)

Model data relational memudahkan designer untuk fokus pada perwujudan lojikal dari data dan relationship yang dimiliki, dan tidak memusingkan detil penyimpanan secara fisikal Mobil automatic >< mobil manual

Capaian Pembelajaran Mahasiswa/i mampu menjelaskan model basis data relational: Konsep dasar relation Key dan jenis-jenisnya Integrity rules Functional dependencies Relationship dalam data relational Index

Konsep dasar relasi (relation)

Relasi (Relation ) Relasi adalah tabel 2-dimensi berisi baris dan kolom yang memiliki karakteristik: Baris berisi data mengenai sebuah entity Kolom berisi data mengenai attribute dari entity Sel dalam tabel berisi sebuah nilai tunggal Semua data dalam sebuah kolom berjenis sama Setiap kolom memiliki sebuah nama yang unik Urutan kolom tidaklah penting Urutan baris tidaklah penting Tidak ada 2 baris yang memiliki kumpulan data yang bernilai identik

Contoh relation EMPLOYEE

Contoh tabel nonrelational dengan banyak nilai dalam satu sel

Contoh tabel nonrelational dengan kolom dengan isi nilai berbeda

Format Deskripsi Relation NAMA_RELATION (KolomKe1, KolomKe2, … , KolomKen) Contoh: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) Disebut juga sebagai relational schema, yaitu perwujudan tabel database dalam bentuk teks dimana setiap tabel dituliskan namanya diikuti daftar attribute dalam tanda kurung bentuk kata tunggal

Pemakaian Istilah

Jenis-jenis kunci (key)

Kunci (Key ) Sebuah key adalah satu atau lebih kolom dalam sebuah relation yang digunakan untuk mengidentifikasi sebuah baris

? Non-unique key Query menghasilkan lebih dari 1 baris Unique key Query menghasilkan 1 baris yang unik

Composite Key Sebuah key yang terdiri dari dua atau lebih attribute disebut sebagai composite key Composite keys bisa saja unique atau nonunique Contoh: (LastName, Department) (LastName, FirstName, Department)

Candidate Key Candidate key adalah key yang secara unik mengidentifikasi setiap baris dalam sebuah relation Candidate key dapat berupa key kolom-tunggal atau bisa berupa composite key

Primary Key Primary key adalah candidate key yang telah dipilih sebagai key utama yang akan digunakan oleh DBMS untuk secara unik mengidentifikasi setiap baris di dalam sebuah relation

Perhatikan deskripsi relation berikut: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) Yang bisa menjadi candidate key: EmployeeNumber adalah unique key Email adalah unique key composite key (FirstName, LastName, DepartmentName) adalah unique key

Yang layak menjadi primary key adalah EmployeeNumber sehingga deskripsi dituliskan sebagai berikut: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) PK diberi garis bawah

Surrogate Key Surrogate key adalah sebuah kolom dengan identifier unik yang ditambahkan oleh DBMS pada sebuah tabel untuk menjadi primary key Nilai unik pada surrogate key diberikan oleh DBMS setiap kali sebuah baris dibuat, dan nilainya tidak pernah berubah

surrogate key menjadi primary key Misal ada relation dengan deskripsi sebagai berikut: PROPERTY (Street, City, State, ZIP, OwnerID) Untuk memudahkan maka ditambah surrogate key sebagai primary key sehingga deskripsi relation menjadi: PROPERTY (PropertyID, Street, City, State, ZIP, OwnerID) surrogate key menjadi primary key

Foreign Key Attribute yang menjadi primary key pada relation pertama bila digunakan pada relation kedua maka attribute yang terdapat di relation kedua disebut sebagai foreign key

Misal terdapat dua relation dideskripsikan sebagai berikut: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) dan DEPARTMENT (DepartmentName, BudgetCode, OfficeNumber, DepartmentPhone) Bila attribute Department pada EMPLOYEE berrelasi dengan attribute DepartmentName (PK) pada DEPARTMENT maka Department pada EMPLOYEE menjadi foreign key milik DEPARTMENT

referential integrity constraint Deskripsinya menjadi: EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) DEPARTMENT (DepartmentName, BudgetCode, OfficeNumber, DepartmentPhone) dan Department pada EMPLOYEE harus ada dalam DepartmentName pada DEPARTMENT FK dicetak miring referential integrity constraint

Referential Integrity Constraint Dalam kebanyakan kasus, integrity rules diperlukan karena sangat penting memastikan bahwa setiap nilai pada sebuah foreign key cocok/sesuai dengan nilai pada primary key Untuk menjaga integrity ini maka null value tidak diperbolehkan pada primary key dan sedapat mungkin harus dihindari

Null Value Keberadaan null value dalam sebuah tabel biasanya adalah indikasi akan buruknya rancangan database Null value, bila digunakan sembarangan, dapat menyebabkan masalah karena memiliki beberapa makna. Misalnya sebuah null value dapat berarti: Nilai yang tidak diketahui dari attribute Nilai yang diketahui dari attribute, namun hilang Sebuah kondisi yang “not applicable”

REMEMBER THIS! A null is no value at all. It does not mean a zero or a space. A null is created when you press the Enter key or the Tab key to move to the next entry without making a prior entry of any kind. Pressing the Spacebar creates a blank (or a space)

Misal ada tiga relation dideskripsikan sebagai berikut: CUSTOMER (CustomerNumber, CustomerLastName, CustomerFirstName, Phone) COURSE (CourseNumber, Course, CourseDate, Fee) ENROLLMENT (CustomerNumber, CourseNumber, AmountPaid) Dengan dua referential integrity constraint: CustomerNumber pada ENROLLMENT harus ada dalam CustomerNumber pada CUSTOMER dan CourseNumber pada ENROLLMENT harus ada dalam CourseNumber pada COURSE

Ketergantungan fungsional functional dependencies

Misal kita membeli permen yang satuannya berharga Rp100, sehingga bisa dihitung dengan rumus: HargaPermen = JumlahPermen x Rp100 Secara fungsi maka HargaPermen tergantung pada JumlahPermen yang dibeli. Hal ini dinyatakan sebagai functional dependency yang dituliskan: JumlahPermen  HargaPermen Dengan kata lain JumlahPermen menentukan HargaPermen, dimana variabel di sisi kiri (JumlahPermen) disebut sebagai determinant untuk HargaPermen

Bila dimodifikasi menjadi: HargaTotal = JumlahUnit x HargaUnit Dimana HargaTotal bergantung pada JumlahUnit dan HargaUnit: (JumlahUnit, HargaUnit)  HargaTotal Composite (JumlahUnit, HargaUnit) adalah determinant untuk HargaTotal

Istilah functional dependence dapat dinyatakan secara sederhana seperti berikut: Attribute A  Attribute B Attribute B secara fungsional bergantung pada attribute A bila setiap nilai di kolom A menentukan satu dan hanya satu nilai di kolom B

Functional dependencies ini nantinya dapat digunakan untuk menentukan attribute mana pada sebuah relation yang menjadi candidate key untuk primary key

EmployeeNumber  FirstName, LastName, Department, Email, Phone (LastName, Department)  EmployeeNumber, FirstName, Email, Phone (FirstName, LastName, Department)  EmployeeNumber, Email, Phone

Relationship data relational

1:M relationship adalah pemodelan relational yang ideal 1:M relationship adalah pemodelan relational yang ideal. Jenis relationship ini yang seharusnya menjadi norma dalam rancangan database relational 1:1 relationship biasanya jarang terjadi dalam rancangan database relational M:N relationship tidak dapat diimplementasikan dalam model relational. Selanjutnya M:N relationship dapat diubah menjadi dua 1:M relationship

indeks

Indeks adalah sebuah pengaturan yang terurut yang digunakan untuk secara lojik mengakses baris dalam sebuah tabel

Komponen Indeks

penutup

Terima Kasih