Logical Database Design and the Relation Model

Logical Database Design and the Relation Model

The Relational Data Model

Model data relational pertama kali diperkenalkan sekitar tahun 1970 oleh E.F Cood,kemudian oleh IBM(Cood,1970). dua proyek penelitian awal diluncurkan untuk membuktikan kelayakan model relasional dan untuk mengembangkan sistem prototype. Pertama pengembangan System R (Prototype DBMS-RDBMS) selama tahun 1970. Kedua pengembangan Ingres secara Academically Oriented RDBMS.Penggunaan RDBMS secara komesial dilakukan sekitar tahun 1980-an. Sekarang RDBMS dijadikan sebagai pedoman dalam management database.

Sebuah Relational Data Model mewakili sebuah data yang berada dalam sebuah tabel dengan berpedomana pada teori matemaika, sehingga kita memerlukan sebuah konsep yang simple untuk mendeskripsikan suatu relational model. Komponen suatu relational model memiliki 3 komponen  (Fleming and von Helle,1989) :

1.     Struktur Data : data yang dibentuk / disusun dalam bentuk tabel yang terdiri dari baris dan kolom

2.    Manipulasi Data : Penggunaan alat yang memadai untuk memanipulasi sebuah data dalam sebuah relational model. Misal SQL

3.    Integrity Data : Fasilitas yang dimasukkan untuk menentukan aturan bisnis yang menjaga integritas data ketika dimanipulasi oleh system

Relation Data Structure

Dalam sebuah relation data structure kita dapat mengenal istilah – istilah sebagai

1.     Relation : Hubungan antar sebuah tabel dalam sebuah data

2.    Primary Key : Atribut ( kumpulan/kombinasi atrribut) yang memiliki identitas unik dalam sebuah baris di sebuah data

3.    Composite Key : Sebuah primary key yang terdiri lebih dari 1 atribut

4.    Foreign key : Atribut dalam relasi database yang berfungsi sebagai kunci utama dari relasi lain dalam database yang sama.

Sifat – Sifat Relation Data Model

1.   Setiap relasi (atau tabel) dalam database memiliki nama unik

2.   Tidak ada atribut yang bernilai banyak dalam suatu hubungan \

3.   Setiap baris unik, tidak ada dua baris dalam suatu relasi yang identik

4.   Setiap atribut dalam kolom dan tabel memiliki nama unik

5.   Urutan kolom (dari kiri ke kanan)

6.   Urutan baris ( dari atas ke bawah)

Integrity Constraints

Domain Constrains

Relation data model memiliki domain dapat digunakan sebagai set nilai yang ditetapkan ke sebuah atribut

Entity Integrity

Aturan sebuah entity integrity dimana sebuah aturan yang dirancang untuk memastikan bahwa setiap relasi memiliki primary key dengan nilai primary key valid atau null.

Action Assertions

Aturan dalam bisnis

Referential Integrity

Aturan sebuah referential integrity dimana sebuah aturan yang dirancang untuk menyatakan foreign key dan primary key memiliki kecocokan nilai dalam sebuah relasi yang lain dengan nilai foreign key valid atau null

Well Structured Relations

Relasi yang berisi redundansi data minimal dan memungkinkan pengguna untuk menyisipkan, menghapus, dan memperbarui baris tanpa menyebabkan inkonsistensi data. Tiga tipe anomaly antara lain :

1.     Insertion Anomaly : menambahkan baris baru memaksa pengguna untuk membuat data duplikat

2.    Deletion Anomaly : menghapus baris dapat menyebabkan hilangnya data yang akan diperlukan untuk baris lain di masa depan

3.    Modification Anomaly : Mengubah data anomali dalam suatu baris memaksa perubahan ke baris lain karena duplikasi

Transforming EER Diagrams into Relations

Menstransformasikan sebuah Diagram ER ke Model Relasi

Beberapa langkah diantaranya :

1.     Transformasi Regular Entitas

l  Atribut Sederhana : Atribut E-R memetakan langsung ke relasi berbentuk tabel

l  Atribut Komposit : Menggunakan atribut yang komponennya sederhana

l  Atribut Bernilai Banyak : dimana sebuah relasi memiliki atribut dengan salah satu atribut memiliki atribut turunan

2.    Tranformasi Tipe Entitas Lemah

Menjadi hubungan terpisah dengan foreign key yang diambil dari entitas superior

Primary Key terdiri dari:

·         Identifikasi parsial dari entitas yang lemah

·         Kunci utama untuk mengidentifikasi hubungan (entitas yang kuat)

3.    Transformasi Relasi Binary

·         Transformasi Relasi Binary ( 1 : M)

Di satu sisi akan menjadi foreign key di banyak sisi

·         Transformasi Relasi Binary ( M : N )

Membuat hubungan baru dengan primary key dari dua entitas sebagai primary key nya

·         Transformasi Relasi Binary ( 1 : 1 )

Primery key wajib menjadi kunci foreign key di sisi yang optimal

4.    Transformasi Relasi Asosiatif

Ada dua pengidentifikasian Entitas antara lain :

·         Identifier Not Assigned

Default primary key untuk hubungan asosiasi terdiri dari primary key dari dua entitas (seperti dalam hubungan M: N)

·         Identifier Assigned

Sebuah data terkadang memiliki pemodelan data yang akan melakukan pengidentifikasian sendiri secara tetap , alasannya entitas tipe asosiatif memiliki pengidentifikasian alami yang familiar bagi end user dan pengidentifikasian default yang tidak unik

5.    Transformasi Relasi Unary

·         Transformasi Relasi Unary ( 1 : M )

Rekursif foreign key dalam hubungan yang sama

·         Transformasi Relasi Unary ( M : N )

Ø  Satu untuk tipe entitas

Ø  Satu untuk hubungan asosiatif di mana primary key memiliki dua atribut, keduanya diambil dari primary key entitas

6.    Transformasi Relasi Ternary

·         Satu relasi untuk setiap entitas dan satu untuk entitas asosiatif

·         Entitas asosiatif memiliki foreign key untuk setiap hubungan dalam entitas

7.    Transformasi Relasi Supertype/Subtype

·         Satu relasi untuk supertipe dan untuk setiap subtipe

·         Atribut Supertype (termasuk pengidentifikasi dan diskriminator subtipe) masuk ke dalam hubungan supertype

·         Atribut subtipe masuk ke setiap subtipe; primery key dari hubungan supertipe juga menjadi primary key dari hubungan subtipe

·         Hubungan 1: 1 terjalin antara supertipe dan setiap subtipe, dengan supertipe sebagai tabel utama

Data Normalization

Terutama alat untuk memvalidasi dan meningkatkan desain logis sehingga memenuhi batasan tertentu yang menghindari duplikasi data yang tidak perlu

Proses penguraian hubungan dengan anomali untuk menghasilkan hubungan yang lebih kecil dan terstruktur dengan baik.

Functional Dependencies and Keys

Functional Dependency : Nilai satu atribut (penentu) menentukan nilai atribut lainnya

Candidate keys :

·         Pengidentifikasi unik. Salah satu candidate key akan menjadi primary key

·         Setiap bidang non-kunci secara fungsional tergantung pada setiap candidate key

First Normal Form

·         Tidak ada atribut multinilai

·         Setiap nilai atribut adalah atomic

Anomalies in this Table

·         Insertion– jika produk baru dipesan untuk pesanan 1007 pelanggan yang ada, data pelanggan harus dimasukkan kembali, menyebabkan duplikasi

·         Deletion – jika kami menghapus Meja Makan dari Pesanan 1006, kami kehilangan informasi tentang harga dan penyelesaian item ini

·         Update – mengubah harga ID produk 4 membutuhkan pembaruan dalam beberapa catatan

Second Normal Form

1NF PLUS setiap atribut non-kunci sepenuhnya secara fungsional bergantung pada SELURUH Primary Key

·         Setiap atribut non-kunci harus ditentukan oleh seluruh kunci, bukan hanya oleh sebagian kunci

·         Tidak ada dependensi fungsional parsial

Third Normal Form

2NF PLUS tanpa dependensi transitif (ketergantungan fungsional pada atribut non-primary-key)

Catatan: Ini disebut transitif, karena primary key adalah penentu untuk atribut lain, yang pada gilirannya merupakan penentu untuk yang ketiga

Solusi: Penentu non-kunci dengan dependensi transitif masuk ke tabel baru, penentu non-kunci menjadi kunci utama di tabel baru dan tetap sebagai kunci asing di tabel lama

Merging Relations

·         View Integration : Menggabungkan entitas dari beberapa model ER ke dalam hubungan umum

·         Masalah yang harus diperhatikan ketika menggabungkan entitas dari model ER yang berbeda:

Ø  Sinonim – dua atau lebih atribut dengan nama berbeda tetapi artinya sama

Ø  Homonim – atribut dengan nama yang sama tetapi artinya berbeda

Ø  Ketergantungan transitif – bahkan jika relasi berada dalam 3NF sebelum penggabungan, mereka mungkin tidak setelah penggabungan

Ø  Hubungan supertipe / subtipe – mungkin disembunyikan sebelum penggabungan

 Sumber : 

Modern Database Management Eighth Edition by Jeffrey A. Hoffer, Mary B. Prescott,

Fred R. McFadden

Universitas Buana Perjuangan Karawang