1. Relasi 1-1. Relasi ini jarang ditemui dalam model data yang benar, sehingga saat Anda
menemukannya, kemungkinan besar hal itu berarti masih ada yang belum sempurna
dari model data Anda; relasi 1-1 sering berarti kedua entitas tersebut sebenarnya adalah
kesatuan, satu entitas tunggal. Kemungkinan lain adalah relasi 1-1 ini adalah relasi
turunan atau relasi non-identifying (identitas unik satu entitas tidak bergantung pada
identitas unik entitas lain) namun jenis relasi kedua ini jarang ditemui.
2. Relasi 1-N. Relasi ini yang paling umum ditemui dalam model data.
3. Relasi M-N. Relasi ini juga sering ditemui dalam model data, dan sering pula dapat
dinormalkan lebih jauh lagi. Langkah yang dapat ditempuh untuk menormalkan relasi
M-N:
a. Buat sebuah entitas baru sebagai penghubung antara kedua entitas dengan relasi MN
tersebut. Entitas penghubung ini akan memiliki hubungan 1-M dengan masingmasing
entitas awal. Identifier entitas penghubung dapat dibuat tersendiri, atau
dengan cara mewarisi identifier kedua entitas awal dan membuat keduanya
identifier unik entitas penghubung ini. Sering kali akan ada atribut lain yang
dimiliki oleh entitas penghubung tersebut. Entitas Kelas dalam contoh model data
kita dapat menjadi contoh entitas penghubung. Apabila tidak ada entitas
penghubung yang dapat diciptakan, relasi M-N tetap harus diubah untuk
menghindari kesulitan dalam konversi model data menjadi skema database fisik.
4. Menterjemahkan Model Data
Setelah sebuah model data dinormalisasikan dan siap diubah menjadi database fisik, ada
beberapa langkah penterjemahan yang harus dilakukan:
1. Setiap entitas menjadi tabel tersendiri.
2. Setiap atribut menjadi kolom-kolom tabel tersebut, dengan tipe data yang sesuai.
3. Identifier entitas tersebut menjadi kolom ID yang tidak boleh kosong (NOT NULL) dan
berisi indeks yang unik. ID unik ini dalam database dinamakan primary key.
4. Relasi diterjemahkan menjadi foreign key.
Skema fisik model data yang dihasilkan tampak dalam Gambar 4. Perhatikan penghilangan
spasi, penentuan tipe data dan penyeragaman kapitalisasi untuk portabilitas skema untuk
digunakan dalam berbagai implementasi RDBMS yang mungkin berbeda dalam casesensitivity.
Gambar 4.
Dan perintah SQL untuk menciptakan ketiga tabel tersebut adalah:
CREATE TABLE dosen (
nip INTEGER NOT NULL AUTO_INCREMENT,
nama_lengkap VARCHAR(20) NOT NULL,
nomor_kontak VARCHAR(20) NULL,
PRIMARY KEY(nip)
)
TYPE=InnoDB;
CREATE TABLE kelas (
kode INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nama_matakuliah INTEGER UNSIGNED NOT NULL,
7
id_tugas_matakuliah INTEGER NOT NULL,
id_dosen INTEGER NOT NULL,
ruang_kuliah VARCHAR(5) NULL,
PRIMARY KEY(kode, nama_matakuliah, id_tugas_matakuliah),
INDEX kelas_FKIndex1(id_dosen),
INDEX kelas_FKIndex2(id_tugas_matakuliah)
)
TYPE=InnoDB;
CREATE TABLE tugas_matakuliah (
id INTEGER NOT NULL,
deskripsi TEXT NULL,
batas_penyerahan DATETIME NULL,
PRIMARY KEY(id)
)
TYPE=InnoDB;
Script SQL di atas menggunakan tipe data dan konfigurasi tabel yang didukung oleh MySQL.
Deklarasi TYPE=InnoDB untuk setiap tabel adalah agar MySQL menggunakan InnoDB yang
mendukung penggunaan foreign key. Tanpa deklarasi tersebut MySQL secara default akan
menggunakan mesin penyimpan MyISAM yang tidak dapat mendukung foreign key.
4.1. Foreign Key
Beberapa catatan khusus mengenai penterjemahan relasi menjadi foreign key:
1. Relasi 1-1 diterjemahkan menjadi “identifier salah satu tabel menjadi foreign key dalam
tabel lain”. Keputusan mengenai tabel mana yang harus menerima identifier tabel lain
dapat diambil sesuai keinginan, dan secara teori tidak begitu berpengaruh. Namun,
seringkali pertimbangan praktis yang akan menentukan tabel mana yang akan berisi
foreign key.
2. Khusus untuk penggunaan MySQL sebagai penyimpan database: sampai MySQL versi
5.0 hanya storage engine InnoDB yang mendukung penggunaan foreign key. Mesin
penyimpanan lain yang digunakan MySQL versi 5.0 atau dibawahnya (seperti MyISAM
atau BDB) tidak mendukung konfigurasi FOREIGN KEY dalam perintah SQL
CREATE TABLE, dan akan mengabaikannya apabila ia ditemui.
5. Contoh Penggunaan Database Ternormalisasi
Untuk model data non-trivial, database ternormalisasi hampir selalu berisi lebih dari satu tabel,
sehingga demi kemudahan pengelolaan, biasanya satu database hanya berisi tabel-tabel yang
terkait dalam satu model data saja. Di bawah ini terdapat contoh query SQL untuk database
ternormalisasi untuk membedakan dengan model data yang hanya menggunakan satu tabel.
INSERT INTO dosen(nama_lengkap,nip) VALUES('Jusuf Kalla',127001);
INSERT INTO kelas(id_dosen, kode) VALUES(127001, 1);
INSERT INTO kelas(id_dosen, kode) VALUES(127001, 2);
Perintah INSERT di atas akan menambah data dosen baru dan dua kelas yang diampu beliau.
INSERT INTO tugas_matakuliah(id, deskripsi,batas_penyerahan)
VALUES(102,
'Implementasikan sebuah compiler untuk bahasa Small-C,
lengkap dengan detail grammar yang digunakan.
Compiler tersebut harus menghasilkan kode assembler
8086
yang dapat dikompilasi oleh Turbo Assembler atau
NASM.',
'2006-12-01');
UPDATE kelas,dosen SET id_tugas_matakuliah=102
WHERE kelas.id_dosen=dosen.nip AND
dosen.nama_lengkap='Jusuf Kalla';
INSERT INTO tugas_matakuliah(id, deskripsi,batas_penyerahan)
VALUES(102,
'Implementasikan sebuah compiler untuk bahasa Small-C,
lengkap dengan detail grammar yang digunakan.
Compiler tersebut harus menghasilkan kode assembler
8086
yang dapat dikompilasi oleh Turbo Assembler atau
NASM.',
'2006-12-01');
UPDATE kelas,dosen SET id_tugas_matakuliah=102
WHERE kelas.id_dosen=dosen.nip AND
dosen.nama_lengkap='Jusuf Kalla';
SELECT t.deskripsi, t.batas_penyerahan
FROM tugas_matakuliah t, kelas k, dosen d
WHERE k.id_tugas_matakuliah=t.id AND
k.id_dosen=d.nip AND
d.nama_lengkap='Jusuf Kalla';
Perintah SELECT di atas akan menampilkan informasi tentang deskripsi sebuah tugas yang
diberikan pada kelas-kelas matakuliah yang diampu oleh dosen tersebut, ditambah dengan
informasi tanggal penyerahan tugas terakhir.
Model data di atas dan semua query yang diberikan kepada database yang dihasilkan masih
sangat sederhana (Salah satunya adalah penggunaan asumsi bahwa beberapa kelas untuk
matakuliah tertentu hanya diampu oleh satu dosen dan mendapat tugas satu-persatu secara
sekuensial – asumsi yang terlalu baik hati) dan tidak sepenuhnya memanfaatkan semua
kemudahan dan potensi yang ditawarkan baik oleh SQL maupun oleh fasilitas-fasilitas setiap
implementasi RDBMS yang mendukung SQL.
Demi keringkasan dan kesederhanaan contoh, saya tidak membahas antara lain mengenai relasi
turunan (inheritance) serta berbagai notasi grafis model data lain seperti ER dan berbagai
turunannya.
Aplikasi yang saya gunakan untuk menggambar model data dan menterjemahkannya menjadi
skema database fisik adalah DBDesigner 4 dari fabForce yang secara eksplisit mendukung
MySQL dan berbagai mesin penyimpanan yang digunakan produk tersebut. Script SQL
CREATE TABLE yang dihasilkan kemudian ditulis ke clipboard untuk di-paste ke artikel ini
dan ke file .sql untuk dieksekusi oleh MySQL (versi 5.0). Batasan-batasan terkait mesin
penyimpanan yang saya paparkan di atas tidak berlaku pada implementasi RDBMS lain (tabel
dalam PostgreSQL dan SQL Server, misalnya, secara default mendukung foreign key).
Sebagai latihan, Anda dapat mencoba memperluas model data di atas atau membuat model data
sendiri, lalu menggunakan perintah query yang lebih efisien; salah satu contoh adalah perintah
SELECT dengan modifier INNER / OUTER JOIN yang memberi Anda kendali yang lebih
besar dan fleksibel untuk mendapat set hasil yang Anda inginkan dari sumber data multi-tabel.
0 Komentar untuk "Normalisasi Database (Bag 2)"