Desain Database Relasional

DIKLAT TEKNIS UMUM
DESAIN PENGELOLAAN DATABASE
MODUL
Desain Database
Relasional
Oleh
Dr. Khamami Herusantoso
Sanyoto Gondodiyoto
Widyaiswara Pusdiklat Keuangan Umum
KEMENTERIAN KEUANGAN REPUBLIK INDONESIA
BADAN PENDIDIKAN DAN PELATIHAN KEUANGAN
PUSDIKLAT KEUANGAN UMUM
JAKARTA
2011
Judul Modul:
Desain Database Relasional
Penulis:
Dr. Khamami Herusantoso
Sanyoto Gondodiyoto
Cetakan Pertama:
2011
Modul: Desain Database Relasional
ii
Puji syukur kami panjatkan ke hadirat Tuhan yang Maha Esa, karena hanya
atas berkat rahmat-Nya kita semua masih diberikan kesempatan untuk
melaksanakan tugas-tugas terkait kediklatan hingga saat ini, terutama bagi
penulis yang telah diberi kesempatan untuk menyusun dan menyelesaikan modul
ini dengan baik.
Modul Structure and Query Language untuk Diklat Teknis Umum
Pengelolaan Database ini disusun oleh Saudara Khamami Herusantoso dan
Saudara Agus Hekso Pramudijono berdasarkan Surat Keputusan Kepala
Pusdiklat Nomor KEP-003/PP.7/2011 tanggal 28 Januari 2011 tentang
Pembentukan Tim Penyusunan Modul Diklat Teknis Umum (DTU) Desain
Pengelolaan Database di Lingkungan Pusdiklat Keuangan Umum Tahun
Anggaran 2011.
Kami menyetujui modul ini digunakan sebagai bahan ajar bagi para
peserta Diklat Teknis Umum Pengelolaan Database. Modul ini merupakan salah
satu bahan ajar yang diperlukan selain 4 (empat) modul lain yang saling
melengkapi yaitu Modul Pengenalan Konsep Database, Modul Desain Database
Relasional, Modul Pemrograman SQL, dan Modul Pengelolaan Database, yang
kesemuanya menjadi sarana dalam membantu pencapaian tujuan pembelajaran
dalam Diklat Teknis Umum Pengelolaan Database.
Akhirnya, semoga Modul Diklat ini dapat bermanfaat bagi peserta diklat
pada khususnya dan masyarakat luas pada umumnya.
Jakarta, Juni 2011
Kepala Pusat
Pendidikan dan Pelatihan Keuangan Umum
Tony Rooswiyanto
NIP 195604041982031001
Modul: Desain Database Relasional
iii
HALAMAN JUDUL
IDENTITAS MODUL
KATA PENGANTAR
Halaman
i
ii
DAFTAR ISI
iii
DAFTAR GAMBAR
vi
DAFTAR TABEL
PETUNJUK PENGGUNAAN MODUL
PETA KONSEP MODUL
A.
vii
viii
PENDAHULUAN
1.
Deskripsi Singkat
3.
Standar Kompetensi dan Kompetensi Dasar
2.
4.
B.
v
Prasyarat Kompetensi
Relevansi Modul
KEGIATAN BELAJAR
1.
Kegiatan Belajar 1 : Pengantar Desain Database
a.
Pengertian Desain Database
c.
Latihan
b.
d.
e.
f.
2.
Model Database
Rangkuman
Tes Formatif
Umpan Balik dan Tindak Lanjut
Kegiatan Belajar 2 : Entity Relation Model
a.
Entitas dan Atribut
Modul: Desain Database Relasional
iv
b.
Relasi Antar Entitas
d.
Latihan
c.
e.
f.
g.
3.
Fitur ER Model
Rangkuman
Tes Formatif
Umpan Balik dan Tindak Lanjut
Kegiatan Belajar 3 : Konsep Normalisasi
a.
Atribut Kunci
c.
Bentuk Normalisasi
b.
d.
e.
f.
g.
Ketergantungan Fungsional
Latihan
Rangkuman
Tes Formatif
Umpan Balik dan Tindak Lanjut
PENUTUP
TES SUMATIF
KUNCI JAWABAN (LATIHAN, TES FORMATIF, &TES SUMATIF)
DAFTAR PUSTAKA
Modul: Desain Database Relasional
v
Tabel 3.1
Contoh Update Anomaly
Tabel 3.3
Contoh Delete Anomaly
Tabel 3.2
Tabel 3.4
Tabel 3.5
Tabel 3.6
Tabel 3.7
Tabel 3.8
Tabel 3.9
Tabel 3.10
Tabel 3.11
Tabel 3.12
Tabel 3.13
Tabel 3.14
Tabel 3.15
Tabel 3.16
Tabel 3.17
Tabel 3.18
Halaman
Contoh Insert Anomaly
Tabel Mata Kuliah
Contoh Tabel
Tabel Nilai
Tabel Mahasiswa
Tabel Versi Pertama
Tabel Versi Kedua
Contoh Tabel T-1
Contoh Tabel T-2
Contoh T-1hasil
Contoh Tabel T-1-1
Contoh Tabel T-1-2
Contoh Tabel T-1-3
Contoh Tabel T-1-1
Contoh Tabel T-1-1-1
Contoh Tabel T-1-1-2
Modul: Desain Database Relasional
vi
Gambar 1.1
Tahapan Perancangan Database
Gambar 2.2
Contoh Himpunan Entitas
Gambar 2.1
Gambar 2.3
Gambar 2.4
Gambar 2.5
Gambar 2.6
Gambar 2.7
Himpunan Entitas Mahasiswa
Gambaran Himpunan Entitas di Tabel
Contoh Atribut Komposit
Entitas Mahasiswa dengan Atribut
Relasi Digambarkan dengan Belah Ketupat
Himpunan
Entitas
Mahasiswa
Himpunan Entitas Organisasi
Gambar 2.8
Contoh Derajat Relasi Unary
Gambar 2.10
Contoh Derajat Relasi Ternary
Gambar 2.9
Gambar 2.11
Gambar 2.12
Gambar 2.13
Gambar 2.14
Gambar 2.15
Gambar 2.16
Gambar 2.17
Gambar 2.18
Gambar 2.19
Gambar 2.20
Gambar 2.21
Gambar 2.22
Gambar 2.23
Gambar 2.24
Gambar 2.25
Halaman
Berelasi
dengan
Contoh Derajat Relasi Binary
Relasi dengan Kardinalitas 1 ke 1
Relasi dengan Kardinalitas 1 ke Banyak
Relasi dengan Kardinalitas Banyak ke 1
Relasi dengan Kardinalitas Banyak ke Banyak
Contoh Diagram ER
Relasi 1 ke 1
Relasi 1 ke Banyak
Relasi Banyak ke 1
Relasi banyak ke Banyak
Contoh Himpunan Entitas Lemah
Contoh Spesialisas
Contoh Agregasi
Relasi Dipandang Sebagai Himpunan Entitas
Ringkasan Notasi pada Diagram ER
Atribut Multivalued Dipecah Menjadi Entitas Baru
Modul: Desain Database Relasional
vii
Gambar 2.26
Gambar 2.27
Gambar 2.28
Gambar 2.29
Gambar 2.30
Gambar 2.31
Gambar 2.32
Gambar 3.1
Atribut Himpunan Entitas Kuat Dipresentasikan ke
Dalam Tabel
Penurunan Himpunan Entitas Lemah ke Tabel
Penurunan Kardinalitas Relasi N to N Menjadi Tabel
Representasi Spesialisasi ke Tabel Metoda 1
Representasi Spesialisasi ke Tabel Metoda 1
Representasi Agregasi untuk Tabel Mata Kuliah,
Dosen, dan Dosen Mengajar Mata Kuliah
Representasi Agregasi untuk Tabel Mahasiswa dan
Mahasiswa Mengambil Mata KUliah
Diagram Normalisasi
Modul: Desain Database Relasional
viii
Modul ini merupakan salah satu bagian dari 5(lima) modul yang diperlukan
dan bersifat saling melengkapi, yaitu:
1. Modul Pengenalan Konsep Database;
2. Modul Desain Database Relasional;
3. Modul Structured Query Language;
4. Modul Pemrograman SQL;
5. Modul Pengelolaan Database.
yang kesemuanya tersebut menjadi satu paket dan dimaksudkan dalam rangka
pencapaian tujuan pembelajaran pada Diklat Teknis Umum Desain Pengelolaan
Database.
Modul Desain Database Relasional ini terdiri dari tiga kegiatan belajar (KB),
yaituPengantar Desain Database, Entity Relationship Model dan Konsep
Normalisasi. Modul ini perlu untuk dibaca secara berurutan dari KB 1 hingga KB3
agar konsep Desain Database Relasional menjadi lebih mudah dipahami.
Pada akhir setiap kegiatan belajar diberikan rangkuman yang berisi intisari
dari materi yang sudah dibahas sebelumnya.Selanjutnya untuk mengevaluasi
pemahaman pembaca, disetiap akhir kegiatan belajar juga disajikan tes formatif.
Meskipun sudah disediakan kunci jawaban atas pertanyaan-pertanyaan dalam
Tes Formatif, peserta disarankan untuk tidak melihat dulu kunci jawaban, namun
sebaiknya peserta mengejakan terlebih dahulu Tes Formatif sesuai dengan
alokasi waktu yang diberikanbaru kemudian melakukan penilaian secara mandiri
dan mengecek nilainya dengan kriteria umpan balik, apakah sudah tercapai
dengan baik. Jika nilai baik belum tercapai, maka peserta disarankan membaca
kembali materi dan mengulangi mengerjakan soal tes sampai memperoleh hasil
yang diharapkan.
Modul: Desain Database Relasional
ix
PENGANTAR DESAIN DATABASE
Pengertian Desain Database
Model Database
ENTITY RELATIONSHIP MODEL
Entitas dan Atribut
Relasi Antar Entitas
Fitur ER Model
KONSEP NORMALISASI
Atribut Kunci
Ketergantungan Fungsional
Bentuk Normalisasi
Modul: Desain Database Relasional
x
A. PENDAHULUAN
1. Deskripsi
Mata pelajaran ini membahas
2. Standar Kompetensi
Setelah mengikuti mata pelajaran ini, peserta diharapkan mampu
menjelaskan desain database relasional
3. Kompetensi Dasar
Setelah selesai mengikuti pembelajaran ini, peserta diklat diharapkan
mampu:
a. menjelaskan pengertian desain database;
b. menjelaskan entity relation model;
c. menjelaskan konsep normalisasi
4. Relevansi Modul
Setelah
mempelajari
modul
ini
diharapkan
peserta
dapat
mengaplikasikannya dalam pekerjaan yang menjadi tugas pokok dan
fungsinya.
.
Modul: Desain Database Relasional
1
B. KEGIATAN BELAJAR
1. Kegiatan Belajar 1
PENGANTAR DESAIN DATABASE
Indikator
Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan
mampu:


menjelaskan pengertian desain database;
menjelaskan model database
a) Pengertian Desain Database
Pada bagian ini akan dijelaskan pengertian desain database.
Desain database merupakan proses untuk merepresentasikan fakta
dunia nyata (real world) yang dikehendaki ke dalam sistem komputer,
sehingga
mudah
dipahami
pemakai
dengan
kemudahan implementasi dan pemrosesannya.
mempertimbangkan
Istilah ‘dunia nyata’ (real world) bermakna terhadap keseluruhan
data yang belum terstruktur yang secara nyata ada/terkait dalam lingkup
sistem yang sedang ditinjau. Dunia nyata disini bisa dikatakan sebagai
sebuah domain secara utuh/penuh maupun subdomain, sebagai contoh
jika kita menganggap suatu perusahaan sebagai suatu domain maka
kita dapat menganggap unit-unit yang ada dalam perusahaan tersebut
adalah subdomain atau bisa saja sebuah proses bisnis atau aktivitas
yang ada di perusahaan tersebut juga bisa kita anggap sebagai sebuah
subdomain bahkan domain. Setiap dunia nyata (real world) yang ada
memiliki karakter yang tidak sama/unik. Sebagai contoh dunia nyata
bagi sistem perbankan pasti tidak sama dengan dunia nyata bagi sistem
Modul: Desain Database Relasional
2
rumah sakit. Pertanyaannya adalah apakah dunia nyata di bank yang
satu dengan bank yang lain pasti sama?
Permasalahan dalam perancangan database adalah bagaimana
merancang struktur logikal dan fisikal dari satu atau lebih database
untuk memenuhi kebutuhan informasi yang diperlukan oleh pengguna
sesuai dengan aplikasi-aplikasi yang ditentukan. (Waliyanto, 2000).
Dengan permasalahan tersebut dapat ditentukan beberapa tujuan
utama perancangan database,yaitu :
a. memenuhi kebutuhan informasi sesuai dengan yang diperlukan
oleh pengguna untuk aplikasi tertentu;
b. mempermudah pemahaman terhadap struktur informasi yang
tersedia dalam database;
c. memberikan keterangan tentang persyaratan pemrosesan dan
kemampuan sistem, seperti lama tidaknya mengakses data,
kapasitas memori yang tersedia dan sebagainya.
Tahapan-tahapan proses perancangan untuk memenuhi tujuan
tersebut adalah:
a. mengumpulkan dan menganalisis persyaratan;
b. merancang konsepsual database;
c. memilih Database Management Software (DBMS);
d. merancang logikal database;
e. merancang fisikal database (pemetaan model data);
f.
iImplementasi sistem database.
Secara khusus proses perancangan berisikan 2 aktifitas paralel.
Aktifitas yang pertama melibatkan perancangan dari isi data dan struktur
database,
sedangkan
aktifitas
kedua
mengenai
perancangan
pemrosesan database dan aplikasi-aplikasi perangkat lunak.
Modul: Desain Database Relasional
3
Gambar 1.1 Tahapan perancangan database (Kompilasi dari Elmasri R,
1994).
Dua
aktifitas
ini
saling
menjalin,
misalnya
:
kita
dapat
mengidentifikasikan data item yang akan disimpan dalam database
dengan menganalisa aplikasi-aplikasi database.
Dua aktifitas ini juga saling mempengaruhi satu sama lain.
Contohnya : fase perancangan database secara fisik, pada saat kita
memilih struktur penyimpanan dan jalur-jalur akses dari file-file database
yang tergantung pada aplikasi-aplikasi yang akan menggunakan file-file
tersebut.
Modul: Desain Database Relasional
4
Di lain pihak, kita biasanya menentukan perancangan aplikasi-
aplikasi database dengan mengarah kepada konstruksi skema database
yang telah ditentukan selama aktifitas yang pertama.
Enam fase di atas tidak harus diproses berurutan. Pada beberapa
hal, rancangan tersebut dapat dimodifikasi dari yang pertama dan
sementara itu mengerjakan fase yang terakhir (feedback loop antara
fase) dan feedback loop dalam fase sering terjadi selama proses
perancangan.
Fase 1 merupakan kumpulan informasi yang berhubungan dengan
penggunaan database. Fase 6 merupakan implementasi databasenya.
Fase 1 dan 6 kadang-kadang
bukan merupakan bagian dari
perancangan database, tetapi merupakan bagian dari siklus kehidupan
sistem informasi secara umum. Inti dari proses perancangan database
adalah fase 2,4,5.
Fase 1: Pengumpulan Data dan Analisa
Proses identifikasi dan analisa kebutuhan-kebutuhan data disebut
pengumpulan
data dan analisa. Untuk
menentukan kebutuhan-
kebutuhan suatu sistem database, pertamatama harus mengenal
bagian-bagian lain dari sistem informasi yang akan berinteraksi dengan
sistem database, termasuk para pemakai yang ada dan para pemakai
yang baru serta aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para
pemakai dan aplikasi inilah yang kemudian dikumpulkan dan dianalisa.
Aktifitas-aktifitas pengumpulan data dan analisa :
1. Menentukan kelompok pemakai dan bidang-bidang aplikasinya
Menentukan
aplikasi utama dan
kelompok
user
yang
akan
menggunakan database. Individu utama pada tiap-tiap kelompok
pemakai dan bidang aplikasi yang telah dipilih merupakan peserta
utama pada langkah-langkah berikutnya dari pengumpulan dan
spesifikasi data.
Modul: Desain Database Relasional
5
2. Peninjauan dokumentasi yang ada
Dokumen yang ada yang berhubungan dengan aplikasi-aplikasi
dipelajari dan dianalisa. Dokumen-dokumen lainnya (seperti :
kebijaksanaan-kebijaksanaan, form, report, dan bagan organisasi)
diuji dan ditinjau kembali untuk menguji apakah dokumen-dokumen
tersebut
berpengaruh
spesifikasi.
terhadap
kumpulan
data
dan
proses
3. Analisa lingkungan operasi dan pemrosesan data
Informasi yang sekarang dan yang akan datang dipelajari. Termasuk
juga analisa jenis-jenis transaksi dan frekuensi-frekuensi transaksinya
dan juga arus informasi dalam sistem. Input-output data untuk
transaksi-transaksi tersebut diperinci.
4. Daftar pertanyaan dan wawancara
Tuliskan tanggapan-tanggapan dari pertanyaan-pertanyaan yang
telah dikumpulkan dari para pemakai database yang berpotensi.
Ketua kelompok (individu utama) dapat diwawancarai sehingga input
yang banyak dapat diterima dari mereka dengan memperhatikan
informasi yang berharga dan mengadakan prioritas.
Fase 2: Perancangan database secara konseptual
Tujuan dari fase ini adalah menghasilkan conceptual schema
untuk database yang tergantung pada sebuah DBMS yang spesifik.
Sering menggunakan sebuah high-level data model seperti ER/EER
model selama fase ini. Dalam conceptual schema, kita harus memerinci
aplikasi-aplikasi database yang diketahui dan transaksi-transaksi yang
mungkin.
Fase perancangan database secara konseptual mempunyai 2
aktifitas paralel :
1. Perancangan skema konseptual :
menguji kebutuhan-kebutuhan data dari suatu database yang
merupakan hasil dari fase 1, dan menghasilkan sebuah skema
konseptual yang independen terhadap
Modul: Desain Database Relasional
DBMS. Skema ini dapat
6
dihasilkan dengan menggabungkan bermacam-macam kebutuhan
user dan secara langsung membuat skema database atau dengan
merancang skema-skema yang terpisah dari kebutuhan tiap-tiap user
dan kemudian menggabungkan skema-skema tersebut. Model data
yang digunakan pada perancangan skema konseptual bersifat
independen terhadap DBMS dan langkah selanjutnya adalah memilih
sebuah DBMS untuk melaksanakan rancangan tersebut.
2. Perancangan transaksi :
menguji aplikasi-aplikasi database dimana kebutuhan-kebutuhannya
telah dianalisa pada fase 1, dan menghasilkan perincian transaksitransaksi ini. Kegunaan fase ini yang diproses secara paralel
bersama
fase
perancangan
skema konseptual
adalah
untuk
merancang karakteristik dari transaksi-transaksi database yang telah
diketahui pada suatu DBMS-independent. Transaksi-transaksi ini
akan digunakan untuk memproses dan memanipulasi database suatu
saat dimana database tersebut dilaksanakan.
Fase 3: Pemilihan DBMS
Pemilihan database di tentukan oleh beberapa faktor, diantaranya:
faktor teknik,ekonomi, dan politik organisasi.
Contoh faktor teknik :
Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis
DBMS (relational, network, hierarchical, dll), struktur penyimpanan, dan
jalur akses yang mendukung DBMS, pemakai, dll.
Faktor-faktor ekonomi dan organisasi yang mempengaruhi satu
sama lain dalam pemilihan DBMS :
1. Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki,
maka suatu jenis hirarki dari DBMS harus dipikirkan.
Modul: Desain Database Relasional
7
2. Personal yang telah terbiasa dengan suatu sistem
Jika staf programmer dalam suatu organisasi sudah terbiasa dengan
suatu DBMS, maka hal ini dapat mengurangi biaya latihan dan waktu
belajar.
3. Tersedianya layanan penjual
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk
membantu memecahkan beberapa masalah sistem.
Fase 4: Perancangan database secara logika (pemetaan model
data)
Fase selanjutnya dari perancangan database adalah membuat
sebuah skema konseptual dan skema eksternal pada model data dari
DBMS yang terpilih. Fase ini dilakukan oleh pemetaan skema
konseptual dan skema eksternal yang dihasilkan pada fase 2. Pada fase
ini, skema konseptual ditransformasikan dari model data tingkat tinggi
yang digunakan pada fase 2 ke dalam model data dari DBMS yang
dipilih pada fase 3.
Pemetaannya dapat diproses dalam 2 tingkat :
1. Pemetaan system-independent
Pemetaan
ke
dalam
model
data
DBMS
dengan
tidak
mempertimbangkan karakteristik atau hal-hal yang khusus yang
berlaku pada implementasi DBMS dari model data tersebut.
2. Penyesuaian skema ke DBMS yang spesifik
Mengatur skema yang dihasilkan pada langkah 1 untuk disesuaikan
pada implementasi yang khusus di masa yang akan datang dari
suatu model data yang digunakan pada DBMS yang dipilih.
Hasil dari fase ini memakai perintah-perintah DDL dalam bahasa
DBMS yang dipilih yang menentukan tingkat skema konseptual dan
eksternal dari sistem database. Tetapi dalam beberapa hal, perintahperintah DDL memasukkan parameter-parameter rancangan fisik
Modul: Desain Database Relasional
8
sehingga DDL yang lengkap harus menunggu sampai fase perancangan
database secara fisik telah lengkap.
Fase ini dapat dimulai setelah pemilihan sebuah implementasi
model data sambilmenunggu DBMS yang spesifik yang akan dipilih.
Contoh: jika memutuskan untuk menggunakan beberapa relational
DBMS tetapi belum memutuskan suatu relasi yang utama. Rancangan
dari skema eksternal untuk aplikasi-aplikasi yang spesifik seringkali
sudah selesai selama proses ini.
Fase 5: Perancangan database secara fisik
Perancangan database secara fisik merupakan proses pemilihan
struktur-struktur penyimpanan dan jalur-jalur akses pada file-file
database untuk mencapai penampilan yang terbaik pada bermacammacam aplikasi.
yang
Selama fase ini, dirancang spesifikasi-spesifikasi untuk database
disimpan
yang
berhubungan
dengan
struktur-struktur
penyimpanan fisik, penempatan record dan jalur akses. Berhubungan
dengan internal schema (pada istilah 3 level arsitektur DBMS).
Beberapa petunjuk dalam pemilihan perancangan database
secara fisik :
1. Response time :
waktu yang diperlukan dari suatu transaksi database yang diajukan
hingga memperoleh jawaban atau respons. Pengaruh utama pada
response time yang di bawah kendali DBMS yaitu : waktu akses
database untuk data item yang ditunjuk oleh suatu transaksi.
Response time juga dipengaruhi oleh beberapa faktor yang tidak
berada di bawah kendali DBMS yaitu: beban sistem, penjadwalan
sistem operasi atau penundaan komunikasi.
2. Space utility :
jumlah ruang penyimpanan yang digunakan oleh file-file database
dan struktur jalur akses ke database yaitu index dan jalur akses
lainnya.
Modul: Desain Database Relasional
9
3. Transaction through put
rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem
database,
dan merupakan parameter kritis dari sistem transaksi
(misal : digunakan pada pemesanan tempat di pesawat, bank, dll).
Hasil dari fase ini adalah penentual awal dari struktur penyimpanan
dan jalur akses untuk file-file database.
Fase 6: Implementasi sistem database
Setelah perancangan secara logika dan secara fisik lengkap, kita
dapat melaksanakan sistem database. Perintah-perintah dalam DDL
dan SDL(storage definition language) dari DBMS yang dipilih, dihimpun
dan digunakan untuk membuat skema database dan file-file database
(yang kosong). Sekarang database tersebut dimuat (disatukan) dengan
datanya.
Jika data harus dirubah dari sistem komputer sebelumnya,
perubahan-perubahan yang rutin mungkin diperlukan untuk format ulang
datanya yang kemudian dimasukkan ke database yang baru. Transaksitransaksi
database
programmmer aplikasi.
sekarang
harus
dilaksanakan
oleh
para
Spesifikasi secara konseptual diuji dan dihubungkan dengan kode
program dengan perintah-perintah dari embedded DML yang telah
ditulis dan diuji. Suatu saat transaksi tersebut telah siap dan data telah
dimasukkan ke dalam database, maka fase perancangan dan
implementasi telah selesai, dan kemudian fase operasional dari sistem
database dimulai.
Sebuah sistem database merupakan komponen dasar sistem
informasi organisasi yang lebih besar. Oleh karena itu siklus hidup
aplikasi database berhubungan dengan siklus hidup sistem informasi.
Siklus
kehidupan
sistem
informasi
merupakan
macro
lifecycle
sementara itu siklus kehidupan database merupakan micro lifecycle.
Aktifitas-aktifitas yang berhubungan dengan database sebagai
micro life cycle dan termasuk fase-fasenya diantaranya : system
definition, design, implementation, loading atau data conversion,
Modul: Desain Database Relasional
10
application conversion, testing dan validation, operation, monitoring dan
maintenance.
Proses perancangan database merupakan bagian dari micro
lifecycle. Sedangkan kegiatan-kegiatan yang terdapat di dalam proses
tersebut diantaranya : pengumpulan data dan analisis, perancangan
database secara konseptual, pemilihan DBMS, perancangan database
secara logika (data model mapping), perancangan database secara
fisik, dan implementasi sistem database.
b) Model data
Model database adalah suatu konsep yang terintegrasi dalam
menggambarkan hubungan (relationships) antar data dan batasanbatasan (constraint) data dalam suatu sistem database. Model database
yang paling awal adalah berbasis model flat file (file datar), dimana
semua record disimpan dalam bentuk sebuah file biasa. Pada model ini,
tidak ada hubungan (relationship) yang bisa didefinisikan atau dibuat
diantara record-record tersebut. Dengan tidak adanya hubungan antar
record, maka record-record tersebut hanya bisa diakses dengan cara
berurutan (sekuensial). Sebagai contoh, jika ingin menemukan suatu
record pelanggan ke 50, maka akan dilakukan pencarian dari record
pertama sampai ke record 49 secara berurutan. Model ini sesuai dengan
kondisi dimana semua record akan diproses secara keseluruhan, tapi
tidak sesuai jika hanya ingin mencari record yang sesuai saja dalam
suatu database.
Model selanjutnya adalah hierarchial model (model hirarki), yang
secara luas digunakan dalam lingkungan komputer mainframe. Model ini
diturunkan dari Information Management Systems pada tahun 1950an
dan diadopsi oleh perusahaan-perusahaan seperti bank, asuransi dan
masih digunakan hingga sampai hari ini. Model ini dirancang dengan
hubungan yang terstruktur sehingga memungkinkan dan mempermudah
akses terhadap suatu data atau record. Dengan menggunakan skema
dari suatu pohon yang dibalik, hubungan yang terjadi dalam model
hirarki ini adalah parent-child dan one-to-many. Setiap tabel parent bisa
Modul: Desain Database Relasional
11
mempunyai beberapa child tabel, namun setiap child tabel hanya
mempunyai satu parent tabel. Karena struktur datanya permanen, dan
secara eksplisit terhubung antara satu sama lainnya, maka proses
pengaksesan data akan lebih cepat. Meskipun demikian, model struktur
yang bersifat kaku ini menyebabkan beberapa masalah. Penambahan
child tabel tidak bisa dilakukan jika tidak terhubung dengan parent tabel.
Misalnya, jika parent tabelnya adalah “Dokter” dan child tabelnya adalah
“Pasien”, maka penambahan pasien akan bergantung dengan dokter.
Dengan kata lain, penambahan record seorang pasien harus juga
menambahkan record seorang dokter. Begitu juga jika sebuah parent
tabel dihapus, maka child-child tabel dibawahnya juga akan terhapus.
Berdasarkan model hirarki pohon terbalik juga, pendekatan desain
database selanjutnya dibuat yaitu network model. Model ini menerapkan
hubungan yang lebih rumit dari model hirarki, sebagai contoh suatu
pohon bisa memiliki cabang yang banyak. Pada model ini, tabel-tabel
terhubung dalam sebuah himpunan, dimana sebuah record dalam tabel
owner akan dihubungkan dengan beberapa record dalam tabel member.
Seperti halnya model hirarki, pengaksesan data pada network model
juga berlangsung sangat cepat. Namun demikian, model ini juga
mempunyai beberapa masalah. Misalnya, seorang user harus paham
betul secara menyeluruh struktur database yang ada untuk memperoleh
sebuah data atau informasi. Jika strukturnya berubah, maka segala
informasi yang berkaitan dengannya akan berubah juga.
Pada tahun 1970-an, hubungan antar database (database
relational) dikembangkan dengan
pesat dan begitu rumit, dimana
nantinya akan mendominasi penggunaan konsep ini dalam semua
industri.
Pada model database relational, data disimpan dalam sebuah
relations (relasi), biasanya disebut dengan tabel. Kumpulan dari tabel,
record (atau tuples), dan fields (atau attributes) adalah komponenkomponen dasar yang membentuk suatu relasi database. Setiap data
individual, disimpan dalam field di suatu tabel dan setiap record terdiri
dari beberapa field yang membentuk suatu tabel.
Modul: Desain Database Relasional
12
Model database relational dikembangkan dari proposal oleh Dr.
E.F. Codd yang berjudul “A Relational Model of Data for Large Shared
Databanks” pada tahun 1970. Codd adalah seorang peneliti ilmiah di
IBM, yang menjelaskan cara yang baik untuk mengelola data yang ada
dalam jumlah besar. Model hirarki dan network pada waktu itu
cenderung bermasalah dengan redundansi dan integritas data. Dengan
menggabungkan disiplin ilmu aljabar, kalkulus dan lojik ke suatu data,
Codd membangun suatu model yang lebih komplek.
TUGAS DAN LATIHAN
1.
2.
Apakah tujuan dari proses desaindatabase?
Sebutkan tahapan proses desain database?
RANGKUMAN
Perancangan database merupakan proses untuk merepresentasikan
fakta dunia nyata (real world) yang dikehendaki ke dalam sistem komputer,
sehingga mudah dipahami pemakai dengan mempertimbangkan kemudahan
implementasi dan pemrosesannya.
Modul: Desain Database Relasional
13
TES FORMATIF KEGIATAN BELAJAR 1
1. Dalam menganalisis suatu domain, hal-hal yang harus diperhatikan adalah
sebagai berikut kecuali…
A. Pendefinisian masalah
B. Business process oriented
C. Aturan/rule yang jelas
D. Identifikasi entitas dan relasi
E.Identifikasi produktivitas domain
2. Berikut ini jenis model database kecuali...
A. Relational
B. Heuristik
C. Network
D. Hirarkial
E. Object oriented
3. Hal-hal berikut ini yang berhubungan dengan metodologi perancangan
database kecuali...
A. Cara pembuatan database
B. Perancangan fisik
C. Operasi recovery
D. Perancangan lojik
E. Penentuan entitas dan relasi
4. Output berupa ER-D dihasilkan dalam tahapan dalam perancangan basis
data yaitu:
A. Tahap Mendefinisikan Kebutuhan
B. Tahap Rancangan Konsep Basis Data
C. Tahap Rancangan Implementasi
D. Tahap Rancangan Fisik Basis Data
Modul: Desain Database Relasional
14
UMPAN BALIK DAN TINDAK LANJUT
Periksalah jawaban Saudara dengan kunci jawaban test formatif KB 1.
Hitunglah jumlah jawaban Saudara yang sesuai dengan kunci jawaban,
kemudian gunakan rumus di bawah ini untuk mengetahui tingkat penguasaan
Saudara terhadap materi.
Rumus =
Jumlah jawaban yang sesuaikunci
Jumlah semua soal
X 100%
Penjelasan tingkat penguasaan
91 – 100 %
= Amat Baik
81 – 90,99 %
= Baik
61 – 70,99%
= Kurang
71 – 80,99%
0 – 60,99%
= Cukup
= Amat Kurang
Kalau Saudara mencapai tingkat penguasaan 80% atau lebih, maka
Saudara dapat meneruskan dengan materi pada KB 2. Tetapi apabila nilai
Saudara kurang dari 80%, maka kami sarankan Saudara mengulangi materi
pada KB 1, terutama materi yang Saudara belum kuasai.
Modul: Desain Database Relasional
15
2. Kegiatan Belajar 2
ENTITY DAN RELATIONSHIP MODEL
Indikator
Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan
mampu:
 menjelaskan entitas dan atribut;
 menjelaskan relasi antar entitas;
 menjelaskan fitur ER Model
a) Entitas dan Atribut
Definisi entitas adalah objek yang dirasa penting di sistem
tersebut, yang bisa berupa :
– Objek Konkrit
Contoh : Orang, Buku
– Objek Abstrak
Contoh : Jadwal, Pinjaman, Tabungan
Heru adalah salah satu contoh dari entitas. Sedangkan Heru,
Dewi, Yati merupakan himpunan entitas orang. Dapat kita katakan
bahwaHimpunan Entitas (Entity Set):Sekelompok entitas yang sejenis
dan berada dalam lingkup yang sama. Kumpulan entitas orang dengan
karakteristik mempunyai nim, prodi, dsb bisa kita katakan merupakan
himpunan entitas mahasiwa. Entitas menunjuk kepada pada individu
suatu objek sedangkan himpunan entitas menunjuk pada rumpun
(family) dari individu tersebut.
Modul: Desain Database Relasional
16
Heru
Entitas orang
Dewi
Yati
entitas orang
Mahasiswa
Himpunan entitas orang yang mempunyai kesamaan karakteristik
yaitu nim, prodi, dsb membentuk himpunan entitas ‘mahasiswa’
Gambar 2.1 Himpunan Entitas Mahasiswa
Sebuah entitas / himpunan entitas dapat di gambarkan / di
notasikan dengan sebuah gambar persegi panjang. Berikut merupakan
contoh entitas mahasiwa, jadwal dan pinjaman.
Mahasiswa
Jadwal
Pinjaman
Gambar 2.2 Contoh himpunan entitas
Setiap entitas mempunyai atribut yang melekat pada entitas
tersebut. Berikut gambaran konseptual database (* entitas dan atribut)
yang direfleksikan kedalam bentuk fisik dari database (* tabel dan
kolom).
Atribut Entitas
NIM
30107001
30207001
30307001
NAMA
Heru
Dewi
Yati
PROGRAM STUDI
Manajemen Informatika
Teknik Komputer
Komputerisasi Akuntansi
MAHASISWA
Modul: Desain Database Relasional
Entitas 1
Entitas 2
Entitas 3
17
Gambar Error! No text of specified style in document..1
Gambaran Himpunan entitas di Tabel
Atribut merupakan gambaran karakteristik dari sebuah entitas atau
himpunan entitas. Contoh : atribut untuk himpunan entitas mahasiswa
adalah nim, nama, alamat, ipk, program studi, hobi, dsb.
Setiap atribut mempunyai domain value set yaitu batasan batasan
yang dibolehkan bagi suatu atribut.
Tipe – tipe atribut dapat dibedakan.
– Simple dan Composite
Atribut Simple yaitu suatu atribut yang tidak bisa dibagi menjadi
bagian yang lebih kecil lagi. Contoh atribut simple adalah Jenis
Kelamin. Atribut Compositeyaitu suatu atribut yang dapat di bagi
menjadi beberapa bagian. Contoh atribut composite Nama dapat di
bagi menjadi nama depan dan nama belakang.
Gambar Error! No text of specified style in document..2
Contoh Atribut Komposit
– Single value dan multivalued
Atribut Single value yaitu suatu atribut yang bisa di isi paling banyak 1
nilai untuk setiap baris data. Contoh atribut single value adalah Jenis
Kelamin. Atribut Multivalued yaitu suatu atribut yang bisa lebih dari 1
nilai yang sejenis untuk setiap baris data. Contoh atribut mutlivalued
value adalah Alamat, No telp dan hobi. Ketiga atribut tersebut bisa
berisi lebih dari 1. Contoh untuk 1 entitas orang bisa mempunyai lebih
dari 1 nilai untuk atribut hobi yang isinya musik, olahraga begitu juga
Modul: Desain Database Relasional
18
untuk telp dan alamat (* karena bisa mempunyai > 1 no telp dan > 1
alamat)
– Derived attribute
Derived Attribute yaitu suatu atribut yang nilainya didapatkan dari
hasil pengolahan atribut lain. Contoh atribut derived adalah umur
yaitu didapatkan dari perhitungan tanggal lahir dan tanggal sekarang.
IPK yang didapatkan dari penjumlahan nilai di bagi dengan jumlah
sks yang diambil.
Notasi atribut digambarkan dengan gambar elips. Atribut kunci
biasa di beri tanda # atau garis bawah. Contoh himpunan entitas
mahasiswa mempunyai atribut nim sebagai key, prodi, nama, ipk, dsb
nama
prodi
ipk
#nim
Mahasis
Gambar 2.5 Entitas mahasiswa dengan Atribut
b) Relasi antar entitas
ER menggambarkan entitas-entitas dengan atributnya yang saling
berelasi. Relasi menggambarkan hubungan antara entitas satu dengan
entitas yang lain sesuai dengan proses bisnisnya. Notasi relasi didalam
diagram ER digambarkan dengan notasi belah ketupat.
Perhatikan contoh relasi antara mahasiswa dengan organisasi
berikut.
Modul: Desain Database Relasional
19
Gambar Error! No text of specified style in document..3 Relasi di
gambarkan dengan belah ketupat
Gambar di atas menunjukkan hubungan antara entitas mahasiswa
dan entitas organisasi. Relasi yang terjadi adalah relasi mempunyai,
dimana mahasiwa mempunyai organisasi. Entitas mahasiwa memiliki
atribut nim, nama, alamat, prodi, ipk, dsb. Sedangkan entitas organisasi
memiliki atribut kd_organisasi, nama_organisasi, jenis_organisasi (*
olahraga/kesenian/jurusan dsb). 1 Mahasiswa bisa mempunyai 0 atau
lebih organisasi pada semester dan tahun ajaran tertentu. 1 Organisasi
bisa di punyai 0 atau lebih mahasiswa pada semester dan tahun ajaran
tertentu. Kardinalitas relasi adalah n ke n. Dampak dari kardinalitas n ke
n ini, relasi menjadi atribut, primary key dari entitas mahasiwa dan
primary key dari entitas organisasi masuk ke tabel relasi sebagai atribut.
Atribut tambahan berupa semester dan tahun ajaran merupakan atribut
tambahan pada tabel relasi mempunyai, atribut ini disebut atribut
deskriptif. Atribut deskriptif ini muncul karena adanya kebutuhan dari
proses bisnis untuk mencatat historis mahasiwa tersebut per semester
dan tahun ajaran tertentu, sehingga bisa di lihat track record organisasi
mahasiwa tersebut selama belajar di kampus dari semester ke semester
berikutnya.
Berikut merupakan contoh gambaran antara entitas mahasiwa dan
entitas organisasi
Dewi
Yati
Heru
Organisai LINUX
Organisai Pecinta Satwa
Dewi
Mempunyai organisasi Pecinta Satwa
Di semester 1 tahun ajaran 2010/2011
.
Gambar Error! No text of specified style in document..4 Himpunan
Modul: Desain Database Relasional
20
Entitas
Mahasiwa
Entitas Organisasi
Berelasi
dengan
Himpunan
Derajat Himpunan Relasi
Jika dilihat dari jumlah entitas yang dihubungkan oleh sebuah
relasi, maka kita bisa membagi menjadi 3 macam:
 Unary(Hanya me-relasi-kan 1 entitas)
Gambar Error! No text of specified style in document..5 Contoh
Derajat Relasi Unary
Relasi di atas menggambarkan entitas karyawan yang
ber-relasi
dengan entitas karyawan. Entitas karyawan bisa merupakan
karyawan biasa tetapi bisa juga merupakan manajer. Relasi yang
terjadi yaitu relasi karyawan bekerja untuk manajer (* entitas manajer
adalah salah satu karyawan juga). Perhatikan kardinalitas relasinya,
1 karyawan hanya bekerja untuk 1 manajer, tetapi 1 manajer bisa
mempunyai banyak bawahan.
 Binary (me-relasi-kan 2 entitas)
Gambar Error! No text of specified style in document..6 Contoh
Derajat Relasi Binary
Relasi di atas menggambarkan entitas pelangan yang ber-relasi
dengan entitas pinjaman. 1 pelanggan bisa mempunyai banyak
Modul: Desain Database Relasional
21
nomor pinjaman, dan 1 nomor pinjaman hanya untuk 1 pelanggan.
 Ternary (me-relasi-kan 3 entitas)
Gambar Error! No text of specified style in document..7 Contoh
Derajat Relasi Ternary
Relasi di atas menggambarkan entitas karyawan yang ber-relasi
dengan entitas cabang dan entitas pekerjaan melalui relasi
bekerja_di. 1 karyawan bekerja di sebuah id pekerjaan tertentu dan
juga bekerja di sebuah cabang tertentu. Ada 3 entitas yang terlibat
dari relasi di atas
Kardinalitas Relasi
Kardinalias relasi menggambarkan banyaknya jumlah maksimum
entitas dapat ber-relasi dengan entitas pada himpunann entitas yang
lain. Pada himpunan relasi biner, pemetaan kardinalitas relasi dapat
berupa salah satu dari pilihan berikut :
 Satu ke Satu
Modul: Desain Database Relasional
22
Gambar Error! No text of specified style in document..8 Relasi
dengan Kardinalitas 1 ke 1
Relasi di atas menggambarkan bahwa untuk setiap entitas di
himpunan entitas A berpasangan dengan maksimal 1 entitas di
himpunan entitas B. Asumsi kita akan membuat sebuah tugas yaitu
menjadi pj_cuci_piring. 1 Orang di tugaskan untuk menjadi
pj_cuci_piring di maksimal 1 hari. Begitupun juga jika di balik, pada 1
hari, maksimal 1 orang yang menjadi pj_cuci_piring. Dari A ke B
kardinalitasnya maksimal 1, dan dari B ke A kardinalitasnya maksimal
1. Oleh karena itu relasi ini berkardinalitas 1 ke 1.
 Satu ke Banyak
Gambar Error! No text of specified style in document..9 Relasi
dengan Kardinalitas 1 ke Banyak
Relasi di atas menggambarkan bahwa untuk setiap entitas di
himpunan entitas A berpasangan dengan banyak entitas di himpunan
Modul: Desain Database Relasional
23
entitas B. Asumsi yang berbeda di pakai ketika memandang relasi ini,
1 orang bisa memperoleh pj_cuci_piring untuk > 1 hari. Tetapi 1 hari
hanya di pj-kan hanya untuk maksimal 1 orang. Dari A ke B
kardinalitasnya maksimal adalah banyak, dan dari B ke A
kardinalitasnya maksimal 1. Oleh karena itu relasi ini berkardinalitas 1
ke banyak.
 Banyak ke Satu
Gambar Error! No text of specified style in document..10 Relasi
dengan Kardinalitas Banyak ke 1
Relasi di atas menggambarkan bahwa untuk setiap entitas di
himpunan entitas A berpasangan dengan maksimal 1 entitas di
himpunan entitas B. Asumsikan bahwa untuk 1 hari pj_cuci_piring
boleh di berikan pada banyak orang, sedangkan 1 orang hanya di
berikan tugas untuk menjadi pj_cuci_piring sebanyak maksimal 1
hari. Dari A ke B kardinalitasnya maksimal adalah 1, dan dari B ke A
kardinalitasnya maksimal adalah banyak. Oleh karena itu relasi ini
berkardinalitas banyak ke 1.
 Banyak ke Banyak
Modul: Desain Database Relasional
24
Gambar Error! No text of specified style in document..11 Relasi
dengan Kardinalitas Banyak ke Banyak
Relasi di atas menggambarkan bahwa untuk setiap entitas di
himpunan entitas A berpasangan dengan maksimal banyak entitas di
himpunan entitas B. Asumsikan bahwa dalam 1 hari pj_cuci_piring
bisa di bebankan pada banyak orang dan 1 orang bisa di bebankan
untuk menjadi pj_cuci_piring lebih dari 1 hari. Dari A ke B
kardinalitasnya maksimal adalah banyak, dan dari B ke A
kardinalitasnya maksimal adalah banyak. Oleh karena itu relasi ini
berkardinalitas banyak ke banyak.
Key
Penggunaan key merupakan cara untuk membedakan suatu
entitas didalam himpunan entitas dengan entitas lain. Key dipilih karena
unik, untuk setiap entitas sehingga bisa di bedakan dari entitas yang
lain. Kita bisa mendefinisikan key sebagai satu atau gabungan dari
beberapa atribut yang dapat membedakan semua row dalam relasi
secara unik.
Macam key ada 3 yaitu :
 Superkey
Superkey yaitu satu atau lebih atribut (kumpulan atribut) yang dapat
membedakan satiap baris data dalam sebuah relasi secara unik.
Contoh super key yaitu =
•
Nim, nama, alamat, kota
•
Nim, nama
•
Nim, nama, alamat
Modul: Desain Database Relasional
25
•
Nim
 Candidate key
Kumpulan atribut minimal yang dapat membedakan setiap baris data
dalam sebuah relasi secara unik. Contoh Nim
 Primary key
Primary key merupakan salah satu dari candidate key yang terpilih.
Alasan pemilihan primary key :
•
Lebih sering di jadikan acuan
•
Jaminan keunikan key lebih baik
•
Lebih ringkas
Contoh dari primary key adalah Nim
Diagram ER
Merupakan diagram model konseptual untuk menggambarkan
struktur logis dari database berbasis grafis.
nama
#nim
Mahasisw
alamat
ipk
umur
kota
#kd_org
nama
Organisasi
m
prodi
jenis
Gambar Error! No text of specified style in document.-12 Contoh
Diagram ER
Notasi yang digunakan di Diagram ER adalah :
Garis
: Link yang menghubungkan atara Entitas dengan
dan entitas dengan relasi atau entitas
atribut,
Elips dobe : Menunjukkan atribut yang multivalued
Elips dengan garis terputus : Menunjukkan atribut turunan
Constraint Cardinalitas
Dalam
menggambarkam
kardinalitas
pada
Diagram
ER,
digunakan garis panah (->) yang menunjukkan “Satu” atau garis biasa
Modul: Desain Database Relasional
26
(—) yang menunjukkan “Banyak”.
nama
#nim
Mahasisw
alamat
ipk
#kd_org
kota
Organisasi
m
umur
nama
prodi
jenis
Gambar Error! No text of specified style in document..13 Relasi 1
ke 1
1 Mahasiswa hanya boleh menjabat 1 jabatan dalam 1 periode tertentu.
1 Jabatan hanya boleh di jabat oleh 1 mahasiswa dalam 1 periode
tertentu.
nama
#nim
Mahasisw
alamat
ipk
umur
#kd_org
kota
m
prodi
nama
Organisasi
jenis
Gambar Error! No text of specified style in document..14 Relasi 1
ke banyak
1 Jabatan hanya boleh dijabat oleh 1 mahasiswadalam 1 periode
tertentu dan 1 organisasi tertentu.
1 Mahasiswa boleh menjabat 1 jabatan dalam 1 periode tertentu di
organisasi yang berbeda.
nama
#nim
Mahasisw
alamat
ipk
umur
#kd_org
kota
m
prodi
nama
Organisasi
jenis
Gambar Error! No text of specified style in document..15 Relasi
Banyak ke 1
Modul: Desain Database Relasional
27
1 Jenis Beasiswa boleh diberikan untuk banyak mahasiwa
1 Mahasiwa hanya boleh mendapatkan 1 Jenis beasiwa
nama
#nim
Mahasisw
alamat
ipk
umur
#kd_org
kota
nama
Organisasi
m
prodi
jenis
Gambar Error! No text of specified style in document..16 Relasi
Banyak ke Banyak
1 Mahasiswa boleh mengambil banyak mata kuliah
1 Mata kuliah boleh diambil banyak mahasiwa
 Himpunan Entitas Lemah
Secara umum, Himpunan Entitas Lemah tidak memiliki primary
key dan selalu bergantung pada entitas lain. Notasi entitas lemah
digambarkan dengan double persegi panjang, sedangkan relasi untuk
himpunan entitas lemah digambarkan dengan double diamond.
Diskriminator / key parsialadalah atribut – atribut yg dpt membedakan
entitas – entitas yang terdapat di himpunan entitas lemah. Diskriminator
tidak sama dengan primary key. Konsep diskriminator hanya di pakai
pada himpunan entitas lemah. Primary keypada Himpunan Entitas
lemah ada 2 yaitu primary key dari entitas kuat yg berelasi dan
diskriminator / key parsialnya. Diskriminator di notasikan dengan garis
bawah yang putus putus.
#nip
Pegawai
nama
jabatan
Nama penerima
Nomor
Tunjangan
Besar tunjangan
Gambar 2.20 Contoh Himpunan Entitas Lemah
Modul: Desain Database Relasional
28
Relasi
di
atas
menggambarkan
bahwa
seorang
pegawai
mendapatkan fasilitas tunjangan dari perusahaan tempat dia bekerja.
Tunjangan dalam hal ini adalah entitas lemah. Tunjangan sebagai
entitas tidak bisa berdiri sendiri, tunjangan harus bergantung pada
entitas pegawai (* tidak akan ada tunjangan jika tidak ada pegawai).
Kardinalitas relasi yang terjadi pada himpunan entitas lemah
biasanya merupakan banyak ke 1 / 1 ke banyak dengan kardinalitas 1 di
himpunan entitas yang lebih kuat.

Spesialisasi
Spesialisasi
merupakan
proses
desain
top-down
dengan
mendesain subgrouping didalam didalam himpunan entitas yang
berbeda dari himpunan entitas. Tujuan dari spesialisasi adalah
memberikan gambaran konseptual tentang perbedaan karakteristik dari
himpunan entitas yang hampir serupa dengan konsep sub grouping /
pengelompokan.
Subgrouping di atas menjadi himpunan entias yang levelnya lebih
rendah dan memiliki atribut tersendiri yang tidak dimiliki pada level di
atasnya. Atribut ini khas dan merupakan pembeda dari entitas di
subgroup yang lain. IS A dinotasikan dengan gambar segitiga berlabel
IS A.
Sifat dari spesialisasi adalah inheritan atribut yaitu atribut pada
level tinggi secara otomatis akan di turunkan pada level di bawahnya.
Modul: Desain Database Relasional
29
nama
#Id_pegawai
Pegawai
Gaji Per Bulan
Upah Per Jam
IS A
Besar
tunjangan
Pegawai Tetap
Pegawai Honorer
Gambar 2.21 Contoh Spesialisasi
Contoh
di
Jumlah Jam Kerja
atas
menggambarkan
bahwa
entitas
pegawai
mempunyai 2 subgroup yaitu pegawai tetap dan pegawai honorer.
Kedua entitas pegawai tetap dan pegawai honorer sama sama
mempunyai atribut turunan yaitu nama dan id_pegawai dari entitas
pegawai. Perbedaan dari pegawai tetap dan pegawai honorer terdapat
di atribut yang melekat pada subgroup-nya. Atribut besar tunjangan dan
gaji perbulan hanya terdapat di himpunan entitas pegawai tetap,
sedangkan atribut upah per jam dan jumlah jam kerja terdapat di
himpunan entitas pegawai honorer.

Generalisasi
Generalisasi
merupakan
proses
desain
bottom-up
dengan
mengkombinasikan jumlah himpunan entitas yang digunakan secara
bersama sama. Spesialisasi dan generalisasi sama sama digambarkan
dengan notasi IS A, yang membedakan adalah sudut pandangnya saja.
Jika Spesialisasi kita mendefinisikan entitas secara umum kemudian
mencari subgroup dari entitas tersebut, tetapi generalisasi memandang
sebaliknya, dari adanya subgroupsubgroup yang berbeda kemudian di
cari entitas umum yang mewakili 2 himpunan entitas tersebut.

Agregasi
Agregasi adalah enkapsulasi dari entitas entitas yang berelasi (*n-
n). Pada umumnya terbentuk dari kardinalitas relasi banyak ke banyak.
Didalam konsep agregasi terdapat istilah enkapsulasi relasi dari kedua
entitas. Enkapsulasi di perlukan karena kedua himpunan entitas yang
ber-relasi tersebut merupakan 1 kesatuan yang tidak bisa di pisah.
Modul: Desain Database Relasional
30
Notasi agregasi di gambarkan dengan gambar persegi panjang yang
membungkus himpunan entitas yang saling ber-relasi.
Gambar 2.22 Contoh Agregasi
Gambar di atas menunjukkan relasi dosen mengajar sebuah mata
kuliah dan mahasiswa mengambil mata kuliah yang diajarkan oleh
dosen tertentu. Agregasi di perlukan dikarenakan tidak di mungkinkan
mahasiwa untuk mengambil mata kuliah tanpa adanya dosen yang
bersedia untuk mengajar mata kuliah tersebut. Dalam kasus di atas
menekankan bahwa himpunan entitas dosen harus ber-relasi terlebih
dahulu dengan himpunan entitas mata kuliah, kemudian relasinya di
pandang sebagai 1 entitas yang ber-relasi dengan himpunan entitas
mahasiwa lewat relasi mengambil. Primary key dari kedua himpunan
entitas dosen dan mata kuliah akan secara implisit masuk ke relasi
mengajar dengan di tambah 2 atribut deskriptif (* semester dan
thn_ajaran). Relasi tersebut di anggap sebagai 1 entitas seperti gambar
di bawah ini.
Gambar 2.23 Relasi di pandang sebagai Himpunan Entitas
Modul: Desain Database Relasional
31

Ringkasan notasi simbol di ER
Gambar 2.24 Ringkasan Notasi pada Diagram ER
Modul: Desain Database Relasional
32
c) Penurunan Skema ER ke Tabel
Penurunan skema dimaksudkan untuk mengubah sebuah konsep
hubungan entitas dan relasi kedalam bentuk fisik tabel tabel yang berelasi.
Inti dari Entity Relationship adalah menggambarkan hubungan di dunia
nyata kedalam bentuk entitas entitas yang saling ber-relasi, dari diagram ini
bisa di buat kedalam bentuk tabel yang langsung di implementasikan
kedalam database.
Secara umum penurunan diagram ER ke tabel memiliki aturan
sebagai berikut :
 Setiap himpunan entitas menjadi Tabel (* baik himpunan entitas
kuat atau lemah)
 Setiap atribut menjadi kolom di tabel
 Kardinalitas relasi akan menentukan jumlah tabel yang terbentuk
(* akan di bahas di bawah lebih detail)
1) Representasi atribut sebagai Kolom
Pada atribut bertipe simple, single danderived direpresentasikan
sama persis seperti diagram ER. Tetapi untuk atribut komposit dan
multivalued mempunyai aturan tersendiri.
Atribut komposit akan dipecah dengan membuat atribut terpisah
untuk masing masing komponennya. Contoh atribut nama pada tabel
mahasiwa, di pecah menjadi 2 kolom yaitu nama depan dan nama
belakang.
Atribut multivalued mengharuskan untuk di pecah menjadi 2 Tabel.
Atribut multivalued M dari entitas E direpesentasikan oleh tabel terpisah
EM. Perhatikan gambar di bawah yang menunjukkan bagaimana
penurunan sebuah atribut multivalued:
Modul: Desain Database Relasional
33
Gambar 2.25 Atribut multivalued di pecah menjadi entitas baru
2) Representasi Himpunan Entitas sebagai Tabel
Himpunan entitas kuat di representasikan kedalam tabel dengan
kolom sama persis dengan atribut yang sudah di definisikan di diagram
ER. Perhatikan gambar di bawah ini :
Gambar 2.26 Atribut himpunan entitas kuat di representasikan
kedalam tabel
Himpunan entitas lemah akan menjadi tabel tersendiri yang
didalamnya ada kolom primary key yang merupakan identifikasi dari
himpunan entitas kuat.Contoh di bawah menggambarkan himpunan
entitas lemah di turunkan kedalam tabel.
Modul: Desain Database Relasional
34
Gambar 2.27 Penurunan Himpunan Entitas Lemah ke tabel
3) Representasi Relasi (* pada kardinalitas N to N)
Relasi dari Himpunan Banyak ke Banyak direpresentasikan
kedalam Tabel tersendiri dengan primary key dari 2 Entitas menjadi
atribut di Tabel Relasi. Perhatikan relasi banyak ke banyak berikut dan
contoh penurunan ke tabel :
Modul: Desain Database Relasional
35
Gambar 2.28 Penurunan Kardinalitas relasi N to N menjadi Tabel
4) Hubungan kardinalitas dengan tabel yang terbentuk
Kardinalitas relasi dari Himpunan Entitas yang saling ber-relasi
akan menentukan banyaknya tabel yang bisa di buat. Adapun aturannya
sebagai berikut :

1 ke 1
Pilih primary key di 1 himpunan entitas untuk menjadi foreign key bagi
himpunan entitas yang lain.

1 ke banyak / banyak ke 1
Primary key pada Tabel berkardinalitas sedikit menjadi foreign key pada
tabel berkardinalitas banyak.

Banyak ke banyak
Sudah jelas di atas
5) Representasi Spesialisasi (IS A)
Ada 2 pendekatan yang dipakai didalam menurunkan spesialisasi
kedalam tabel.
Pendekatan 1
 Bentuklah tabel untuk level entitas yg lebih tinggi
 Bentuklah tabel untuk level entitas yg lebih rendah (*dengan
Modul: Desain Database Relasional
36
memasukkan primary key pada level yg lebih tinggi ke tabel dengan
level yang lebih rendah)
Gambar 2.29 Representasi spesialisasi ke tabel metoda 1
Pendekatan 2
 Bentuklah tabel untuk tiap himpunan entitas dengan semua atribut
lokal dan turunan.
 Bisa jadi tabel pada level tinggi tidak perlu di simpan jika
spesialisasi adalah total. Jika diperlukan bisa dibuat view yang
menggabungkan tabel-tabel spesialisasi.
Gambar 2.30 Representasi spesialisasi ke tabel metoda 1
6) Representasi Agregasi
Untuk merepresentasikan agregasi, buatlah tabel yang terdiri dari :
 Foreign key dari himpunan entitas yang berhubungan
 Setiap atribut deskriptif
 Atribut baru untuk primary key di tabel relasi
Modul: Desain Database Relasional
37
Gambar 2.31 Representasi Agregasi untk tabel mata kuliah,
dosen dan Dosen mengajar mata kuliah
Gambar 2.32
Representasi Agregasi untuk tabel Mahasiwa dan
Mahasiwa Mengambil Mtkul
Modul: Desain Database Relasional
38
TUGAS DAN LATIHAN
1.
2.
RANGKUMAN
Modul: Desain Database Relasional
39
TES FORMATIF KEGIATAN BELAJAR 2
(Waktu: 20 menit)
1.
Manakah yang bukan merupakan entitas dari pilihan di bawah
A.
Dosen
B.
C.
___________
Mata Kuliah
Mempunyai
D.
Penjadwalan
E.
Nasabah
2.
Notas persegi panjang bisa memberikan makna _________
B.
Himpunan Entitas
A.
C.
Entitas
A dan B benar
D.
E.
Atribut
Relasi
3.
Berikut ini merupakan domain value set bagi sebuah atribut didalam
A.
Simple
B.
C.
konse EntityRelationship, kecuali _________
Composit
Single value
D.
E.
Multivalued
Surrogate key
4.
Dibawah ini merupakan alasan yang benar tentang makna Atribut
A.
Muncul hanya jika 2 entitas
B.
C.
deskriptif ________
bertemu di sebuah relasi
Dibolehkan di konsep ER
Atribut yang di turunkan
D.
E.
Atribut yang dipercaya sebagai
key
Pernyataan di atas salah semua
dari atribut lain
Modul: Desain Database Relasional
40
5.
Pada gambar di atas, derajat himpunan relasinya adalah ________
B.
Binary
A.
Unary
C.
Ternary
6.
Perhatikan relasi berikut
A.
B.
C.
D.
E.
Four-ary
Tidak ada jawaban yang benar
Relasi di atas merupakan contoh dari relasi _________
Agregasi
Spesialisasi
Generalisasi
D.
E.
Modul: Desain Database Relasional
WeakEntity
Salah semua
41
7.
Banyak tabel yang bisa di hasilkan dari relasi di soal nomor 4 di atas
adalah _________
A.
3 Tabel
C.
5 Tabel
B.
4 Tabel
D.
6 Tabel
E.
7 Tabel
8
Gambar himpunan entitas berikut menggambarkan _______
A.
Himpunan Entitas
D.
Relasi
Lemah
E.
Atribut
B.
Himpunan
Entitas
C.
Himpunan
Entitas
9.
Banyak tabel yang bisa di hasilkan dari relasi di soal nomor 4 di atas
Kuat
adalah _________
A.
3 Tabel
C.
5 Tabel
B.
10
4 Tabel
D.
E.
Network
Setiap atribut pasti menjadi 1 kolom. Pernyataan tersebut _______
A
Benar
C
Benar pada kondisi tertentu
B
7 Tabel
Salah
Modul: Desain Database Relasional
D.
E.
Salah pada kondisi tertentu
C dan D benar
42
UMPAN BALIK DAN TINDAK LANJUT
Periksalah jawaban Saudara dengan kunci jawaban test formatif KB 2.
Hitunglah jumlah jawaban Saudara yang sesuai dengan kunci jawaban,
kemudian gunakan rumus di bawah ini untuk mengetahui tingkat penguasaan
Saudara terhadap materi.
Rumus =
Jumlah jawaban yang sesuai kunci
Jumlah semua soal
X 100%
Penjelasan tingkat penguasaan
91 – 100 %
= Amat Baik
81 – 90,99 %
= Baik
61 – 70,99%
= Kurang
71 – 80,99%
0 – 60,99%
= Cukup
= Amat Kurang
Kalau Saudara mencapai tingkat penguasaan 80% atau lebih, maka
Saudara dapat meneruskan dengan materi pada KB 3. Tetapi apabila nilai
Saudara kurang dari 80%, maka kami sarankan Saudara mengulangi materi
pada KB 2, terutama materiyang Saudara belum kuasai.
Modul: Desain Database Relasional
43
3. Kegiatan Belajar 3
KONSEP NORMALISASI
Indikator
Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan
mampu:
 menjelaskan atribut kunci;
 menjelaskan ketergantungan fungsional;
 menjelaskan bentuk normalisasi.
a) Atribut Kunci
Normalisasi adalah langkah-langkah sistematis untuk menjamin
bahwa struktur database memungkinkan untuk general purpose query
dan bebas dari insertion, update dan deletion anomalies yang dapat
menyebabkan hilangnya integritas data (E.F. Codd, 1970).
Pada dasarnya normalisasi dilakukan untuk memperbaiki desain
tabel yang kurang baik sehingga penyimpanan data menjadi lebih
efisien dan bebas anomali data. Untuk memperjelas pemahaman
tentang proses normalisasi, perhatikan diagram berikut:
Gambar 3.1 Diagram Normalisasi
Intinya, normalisasi dilakukan terhadap desain tabel yang sudah
ada dengan tujuan untuk meminimalkan redundansi (pengulangan) data
dan menjamin integritas data dengan cara menghidari 3 Anomali Data:
Update, Insertion dan Deletion Anomaly.
Modul: Desain Database Relasional
44
Update Anomaly
NIM
1-01
1-01
2-01
2-01
2-02
Tabel 3.1 Contoh Update Anomaly
Nama_Mhs Kd_Jur Nama_Jur
Heru
TE
Dewi
IF
Informatika IF-001
IF
Informatika IF-002
Heru
Dewi
Yati
TE
IF
Elektro
Kode_MK Nama_MK
Elektro
TE-001
DU-001
Informatika DU-001
Elektronika
SKS Nilai
English
Algoritma
English
Database
3
A
3
B
2
A
2
C
2
A
Tabel di atas adalah contoh tabel yang memiliki desain yang
kurang baik. Perhatikan bahwa jika kita ingin meng-update jumlah sks
mata kuliah English dari 2 menjadi 3 sks, maka kita harus mengupdate
lebih dari 1 record, yaitu baris 2 dan 4.
Jika hanya salah satu baris saja yang di-update, maka data
menjadi tidak konsisten (ada mata kuliah English dengan 2 sks dan ada
mata kuliah English dengan 3 sks) . Kondisi seperti inilah yang disebut
dengan update anomaly.
Insertion Anomaly
NIM
1-01
1-01
2-01
2-01
2-02
Tabel 3.2 Contoh Insert Anomaly
Nama_Mhs
Heru
Heru
Dewi
Dewi
Yati
Kd_Jur
TE
TE
Nama_Jur
Elektro
TE-001
Elektro
DU-001
Informatika
DU-001
IF
Informatika
IF
Informatika
IF
Kode_MK
Nama_MK
Elektronika
SKS
English
IF-001
Algoritma
IF-002
Database
English
3
2
3
2
2
Nilai
A
A
B
C
A
Pada tabel yang sama seperti contoh di atas, terjadi pula insertion
anomaly. Misalkan terdapat mahasiswa baru dengan nim 1-02 bernama
‘Zubaedah’ dengan kode jurusan ‘TE’ dan nama jurusan ‘Elektro’.
Data mahasiswa tersebut tidak dapat dimasukkan ke dalam tabel
sebab dia belum mengambil kuliah apapun (misalnya karena belum
Modul: Desain Database Relasional
45
melakukan registrasi). Kondisi inilah yang disebut dengan insertion
anomaly.
Deletion Anomaly
NIM
1-01
1-01
Tabel 3.3 Contoh Delete Anomaly
Nama_Mhs
Heru
TE
Heru
2-01
Dewi
2-02
Yati
2-01
Kd_Jur
TE
Dewi
Nama_Jur
Kode_MK
Nama_MK
SKS
Elektro
DU-001
English
2
Informatika
DU-001
Elektro
IF
Informatika
IF
Informatika
IF
TE-001
Elektronika
IF-001
Algoritma
IF-002
Database
3
Nilai
3
English
2
2
A
A
B
C
A
Pada contoh tabel di atas terjadi deletion anomaly. Perhatikan
bahwa jika kita menghapus data mahasiswa bernama ‘Yati’ maka kita
harus menghapus data pada baris ke 5, hal ini akan mengakibatkan kita
juga kehilangan data mata kuliah ‘Database’. Kondisi inilah yang disebut
dengan deletion anomaly.
Selain 3 anomali di atas, ada beberapa konsep yang mendasari
normalisasi.
Adapun
konsep-konsep
penting
yang
mendasari
normalisasi adalah konsep mengenai super key, candidate key, primary
key, functional dependencydan tentu saja bentuk-bentuk normal yang
menjadi acuan kita dalam melakukan normalisasi terhadap desain
sebuah tabel. Pemahaman terhadap konsep-konsep ini sangat penting
dan akan dibahas di beberapa sub bab berikutnya.
 The Three Keys
Konsep tentang key adalah konsep yang penting untuk
memahami keterkaitan antar atribut data dalam tabel dan akan
sangat berguna dalam proses normalisasi. Dalam setiap tabel,
terdapat 3 macam key:
a) Super key
Super key adalah satu atribut atau gabungan atribut (kolom) pada
tabel yang dapat membedakan semua baris secara unik.
Modul: Desain Database Relasional
46
b) Candidate key
Candidate key disebut juga dengan minimal super key, yaitu super
key yang tidak mengandung super key yang lain. Setiap candidate
key pasti merupakan super key, namun tidak semua super key
akan menjadi candidate key.
c) Primary key
Primary key adalah salah satu candidate key yang dipilih (dengan
berbagai pertimbangan) untuk digunakan dalam DBMS. Tiap tabel
hanya memiliki 1 primary key, namun primary key tersebut bisa
saja dibentuk dari beberapa atribut (kolom).
Untuk memperjelas pemahaman kita terhadap 3 macam key di
atas, perhatikan contohnya pada tabel mata_kuliah di bawah ini:
Kode_MK
Tabel 3.4 Tabel Mata Kuliah
Nama_MK
U-001
English
F-001
Algoritma
U-002
F-002
F-003
E-001
Kalkulus
Database
Artificial Intelligence
Elektronika
Semester
2
2
1
3
1
2
5
4
SKS
3
3
2
3
Beberapa super key dari tabel di atas adalah:
1. (kode_mk)
Dari 6 baris data yang ada pada tabel di atas tak ada satupun yang
memiliki kode_mk yang sama.
2. (nama_mk)
Demikian pula dengan nama_mk, masing-masing baris data memiliki
nama_mk yang unik. Tidak ada satupun baris data yang memiliki
kolom nama_mk dengan nilai yang sama persis.
3. (kode_mk,nama_mk,semester)
Walaupun beberapa baris data memiliki kolom semester dengan nilai
yang sama (misalnya baris 1&4, baris 2&3) namun tidak ada satupun
Modul: Desain Database Relasional
47
baris data yang memiliki kombinasi kode_mk, nama_mk dan
semester yang sama persis.
4. (kode_mk,nama_mk, sks)
Kombinasi kode_mk, nama_mk dan sks juga digolongkan sebagai
super key dengan alasan yang kurang lebih sama dengan poin 3.
5. (kode_mk,nama_mk, semester, jml_temu)
Kombinasi kode_mk, nama_mk, semester dan jml_temu juga
digolongkan sebagai super key dengan alasan yang kurang lebih
sama dengan poin 3 dan 4.
Sedangkan yang bukan super key adalah:
1. (sks)
Perhatikan bahwa kolom sks tidak bisa membedakan baris data
secara unik, contohnya baris data 2,3, 4 dan 6 sama-sama memiliki
kolom sks bernilai 3.
2. (semester)
Kolom semester juga tidak bersifat unik, contohnya baris data 1 dan 4
sama-sama memiliki kolom semester bernilai 2
3. (semester, sks)
Kombinasi semester dan sks juga tidak membedakan tiap baris data
secara unik, contohnya baris data ke 2 dan 3 sama-sama memiliki
kolom semester bernilai 1 dan sama-sama memiliki kolom sks
bernilai 3
Candidate key dari tabel mata_kuliah dipilih dari super key yang
sudah ada. Super key yang akan menjadi candidate key adalah super
key yang tidak mengandung super key lain di dalamnya.
Perhatikan 5 super key yang sudah kita peroleh dari analisis
sebelumnya:
1. (kode_mk)
2. (nama_mk)
3. (kode_mk,nama_mk,semester)
4. (kode_mk,nama_mk, sks)
5. (kode_mk,nama_mk, semester, jml_temu)
Modul: Desain Database Relasional
48
Super key yang hanya teridiri dari satu atribut data pasti akan
menjadi candidate key sebab tidak mungkin mengandung super key
yang lain. Oleh karena itu super key pada poin 1 dan 2 otomatis menjadi
candidate key. Super key pada poin 3 tidak menjadi candidate key
sebab dalam kombinasi (kode_mk, nama_mk, semester) terdapat super
key yang lain yaitu (kode_mk). Dengan demikian, poin 4 dan 5 juga
bukan candidate key.
Dari analisis ini, kita memperoleh 2 buah candidate key yaitu
(kode_mk) dan (nama_mk). Salah satu dari beberapa candidate key ini
akan dipilih untuk digunakan dalam DBMS sebagai primary key. Ada
beberapa pertimbangan untuk memilih primary key, di antaranya adalah
jaminan keunikan yang lebih kuat, representasi yang lebih baik dan lainlain.
b) Ketergantungan Fungsional
Functional dependency (FD) atau kebergantungan fungsional adalah
constraint atau batasan/ ketentuan antara 2 buah himpunan atribut pada
sebuah tabel.
JIka A dan B adalah himpunan atribut dari tabel T, kebergantungan
fungsional antara A dan B biasanya dinyatakan dalam notasi notasi A  B.
Notasi A  B berarti:
 A menentukan B
 B secara fungsional bergantung kepada A.
A  B jika memenuhi syarat berikut ini :
Pada sebuah tabel T, jika ada dua baris data atau lebih dengan nilai
atribut A yang sama maka baris-baris data tersebut pasti akan memiliki nilai
atribut B yang sama Namun hal ini tidak berlaku sebaliknya.
Untuk lebih jelasnya perhatikan tabel berikut ini:
Modul: Desain Database Relasional
49
Tabel 3.5 Contoh Tabel
NIM
1-01
1-01
2-01
2-01
2-02
Nama_Mhs Kd_Jur
Nama_Jur
Heru
TE
Elektro
Dewi
IF
Informatika
Heru
TE
Dewi
IF
Yati
IF
Elektro
Informatika
Informatika
Kode_MK
Nama_MK
SKS
TE-001
Elektronika
3
IF-001
Algoritma
3
DU-001
DU-001
IF-002
English
English
Database
2
2
2
Nilai
A
A
B
C
A
Contoh kebergantungan fungsional yang terdapat pada tabel di atas:
 NIM  Nama_mhs
Untuk setiap baris data, jika NIM = 1-01 pasti Nama_mhs = ‘Heru’,
walaupun belum tentu semua mahasiswa yang bernama Heru memiliki NIM
= 1-01
 NIM  Kd_jur
Untuk setiap baris data, jika NIM = 1-01 pasti Kd_jur = ‘TE’, walaupun tidak
semua baris data dengan kd_jur ‘TE’ memiliki kolom NIM bernilai 1-01
 NIM  Nama_Jur
Untuk setiap baris data dengan kolom NIM bernilai 1-01 pasti
memiliki kolom Nama_Jur = ‘Elektro’, walaupun tidak semua orang di
jurusan Elektro memiliki NIM = 1-01. Demikian pula tidak semua baris data
pada tabel dengan kolom Nama_Jur = ‘Elektro’ memiliki kolom NIM = 1-01
Penulisan kebergantungan fungsional dari 3 poin di atas dapat diringkas
menjadi (NIM)  (nama_mhs, kd_jur, nama_jur)
Dengan demikian, dari tabel tersebut dapat kita simpulkan beberapa
kebergantungan fungsional (FD) sebagai berikut:
•
FD1: (nim)  (nama_mhs, kd_jur, nama_jur)
•
FD3: (kode_mk)  (nama_mk, sks)
•
•
FD2: (kd_jur)  (nama_jur)
FD4: (nim,kode_mk)  (nilai)
Ada beberapa jenis kebergantungan fungsional, di antaranya yaitu:
a. Partial Functional dependency
b. Transitive Functional dependency
Modul: Desain Database Relasional
50
c. Multivalued Functional dependency
Ketiganya adalah konsep penting dalam normalisasi, namun dalam
sub bab ini kita hanya akan membahas mengenai Partial Functional
dependency dan Transitive Functional dependency.
a) Partial Funcional Dependency
Partial Functional dependency atau kebergantungan fungsional
parsial terjadi bila:
•
•
BA
B adalah bagian dari candidate key
Dengan kata lain jika (B,C) adalah candidate key dan B  A maka
A bergantung secara parsial terhadap (B,C) atau (B,C) menentukan A
secara parsial.
Untuk lebih jelasnya perhatikan tabel berikut ini:
Tabel 3.6 Tabel Nilai
NIM
Nama_Mhs
1-01
Heru
1-01
Heru
2-01
Dewi
2-01
Dewi
2-02
Yati
Kode_MK
Nilai
TE-001
A
IF-001
B
DU-001
DU-001
IF-002
A
C
A
Pada tabel di atas perhatikan bahwa:
1. Super
key
:
(nim,kode_mk),
(nim,nama_mhs,kode_mk,nilai)
(nim,nama_mhs,kode_mk)
dan
2. Dari super key yang sudah diperoleh pada poin 1, maka dipilih
super key yang akan menjadi candidate key yaitu (nim,kode_mk)
3. FD: (nim)  (nama_mhs)
Dari analisis poin 2 dan 3 maka dapat disimpulkan bahwa terjadi
kebergantungan fungsional parsial dimana (nama_mhs) bergantung
kepada (nim,kode_mk) secara parsial atau dapat juga dikatakan bahwa
(nim,kode_mk) menentukan (nama_mhs) secara parsial.
Modul: Desain Database Relasional
51
b) Transitive Functional dependency
Transitive Functional dependency atau kebergantungan fungsional
transitif terjadi jika:

AB

BC
Jika A  B
dan B  C maka A  C. Dengan kata lain A
bergantung secara transitif terhadap C melalui B atau A menentukan C
secara transitif melalui B.
Untuk lebih jelasnya perhatikan contoh tabel berikut ini:
Tabel 3.7 Tabel Mahasiswa
NIM
1-01
1-01
2-01
2-01
2-02
Nama_Mhs Kd_Jur
Nama_Jur
Heru
TE
Elektro
Dewi
IF
Informatika
Heru
Dewi
Yati
TE
IF
IF
Elektro
Informatika
Informatika
FD1: (nim) (nama_mhs, kd_jur, nama_jur)
FD2: (kd_jur) (nama_jur)
Dengan
demikian
dapat
disimpulkan
bahwa
(nama_jur)
bergantung secara transitif terhadap (nim) melalui (kd_jur) atau dapat
juga dikatakan bahwa (nim)  (nama_jur) secara transitif melalui
(kd_jur).
c) Bentuk Normalisasi
Bentuk Normal adalah sekumpulan kriteria yang harus dipenuhi oleh
sebuah desain tabel untuk mencapai tingkat/level bentuk normal tertentu.
Parameter yang biasanya digunakan dalam menentukan kriteria bentuk
normal adalah Functional dependency & The Three Keys.
Modul: Desain Database Relasional
52
Masing-masing bentuk normal memiliki kriteria dan level tertentu
yang tidak mungkin dicapai tanpa memenuhi kriteria bentuk nomal level
yang berada di bawahnya. Makin tinggi level bentuk normal yang dicapai
maka kualitas desain tabel tersebut dinyatakan makin baik dan semakin
kecil peluang terjadinya anomali dan redundansi data.
Normalisasi dilakukan dengan cara menerapkan Bentuk-Bentuk
Normal secara bertahap dari level terendah sampai level yang dikehendaki.
Walaupun ada beberapa bentuk normal namun jika desain tabel tertentu
sudah memenuhi kriteria 3rd NF atau BCNF maka desain tabel itu biasanya
dianggap sudah ‘cukup normal’.
Bentuk Normal Pertama (1st Normal Form)
Bentuk normal pertama atau First Normal Form (1st NF) adalah bentuk
normal yang memiliki level terendah.
Kriteria 1st NF:
• Tidak ada atribut (kolom) pada tabel yang bersifat multi-value
Sebuah atribut disebut bersifat multivalue jika dalam sebuah baris data
pada kolom tersbut terdapat lebih dari satu nilai. Misalnya kolom telepon
yang berisi ‘0813xx, 022xxx’ dan seterusnya.
• Tidak memiliki lebih dari satu atribut dengn domain yang sama
Sebuah tabel dikatakan memiliki lebih dari satu atribut dengan domain
yang sama jika pada tabel tersebut terdapat lebih dari satu kolom yang
digunakan untuk menyimpan data yang jenisnya sama. Misalnya kolom
telepon1, telepon2, telepon3 dan seterusnya.
Untuk lebih jelasnya perhatikan 2 versi contoh tabel T berikut ini:
Tabel 3.8 Tabel Versi pertama
NIM
Nama_Mhs
Telp_1
Telp_2
Kd_
1-01
Heru
0813xx
022xxx
TE
2-02
Yati
0852xx
031xxx
IF
2-01
Dewi
0812xx
021xxx
Jur
IF
Modul: Desain Database Relasional
Nama_Jur
Kode_
Nama_MK
Elektro
TE-001
Elektronika
3
A
Informatika
IF-002
Database
2
A
Informatika
MK
IF-001
Algoritma
SKS
3
Nilai
B
53
Tabel T versi pertama ini memiliki 2 atribut dengan domain yang
sama yaitu kolom telp_1 dan telp_2. Hal ini menunjukkan bahwa tabel T
versi pertama ini belum memenuhi syarat 1st NF.
NIM
Nama_Mhs
Tabel 3.9 Tabel Versi ke dua
Telepon
Kd_Jur
Nama_Jur
Kode_MK
Nama_MK
SKS
Nilai
1-01
Heru
0813xx,
TE
Elektro
TE-001
Elektronika
3
A
2-01
Dewi
0812xx,
IF
Informatika
IF-001
Algoritma
3
B
2-02
Yati
0852xx,
IF
Informatika
IF-002
Database
2
A
021xxx
021xxx
031xxx
Tabel T versi ke dua ini juga belum memenuhi sayarat 1st NF karena
kolom telepon bersifat multivalue.
Solusi agar tabel T memenuhi syarat 1st NF adalah dengan
melakukan pemecahan tabel atau dekomposisi tabel. Namun perlu diingat,
dekomposisi tabel harus dilakukan dengan cermat agar data tetap
konsisten (perubahan hanya terjadi pada struktur tabel tapi tidak terjadi
perubahan pada data)
Perhatikan bahwa (nim)  (telepon). Dengan demikian, kita dapat
memecah tabel T menjadi tabel T-1 dan tabel T-2 berikut ini:
Tabel 3.10 Contoh Tabel T-1
NIM
Nama_Mhs
Kd_Jur
Nama_Jur
Kode_MK
Nama_MK
SKS
Nilai
2-01
Dewi
IF
Informatika
IF-001
Algoritma
3
B
1-01
2-02
Heru
Yati
TE
IF
Elektro
Informatika
Modul: Desain Database Relasional
TE-001
IF-002
Elektronika
Database
3
2
A
A
54
Tabel 3.11 Contoh Tabel T-2
NIM
Telepon
1-01
022xxx
1-01
2-01
2-01
2-02
2-02
0813xx
0812xx
021xxx
0852xx
031xxx
Baik Tabel T1 maupun tabel T2 tidak memiliki atribut bersifat
multivalue. Tabel T1 dan T2 juga tidak memiliki lebih dari satu atribut
dengan domain yang sama. Dengan demikian dapat disimpulkan bahwa
tabel T1 dan T2 telah memenuhi syarat 1st NF dan siap untuk diperiksa
apakah memenuhi syarat bentuk normal level berikutnya (2nd NF)
Bentuk Normal Ke Dua (2nd Normal Form)
Kriteria 2nd NF:
• Memenuhi 1st NF
Desain tabel yang tidak memenuhi syarat 1st NF sudah pasti tidak
akan memenuhi syarat 2nd NF
• Tidak ada Partial Functional dependency
Partial Functional dependency terjadi bila (B,C) adalah candidate key
dan B  A
Untuk lebih jelasnya perhatikan tabel T-1hasil tahap sebelumnya:
Tabel 3.12 Contoh T-1hasil
NIM
Nama_Mhs Kd_Jur Nama_Jur
2-01
Dewi
1-01
2-02
Kode_MK Nama_MK
Heru
TE
Elektro
Yati
IF
Informatika IF-002
IF
E-001
Informatika IF-001
SKS Nilai
Elektronika 3
A
Database
A
Algoritma
3
2
B
Perhatikan bahwa:
1. (nim, kode_mk) adalah candidate key
2. FD1: (nim)  (nama_mhs, kd_jur, nama_jur)
Modul: Desain Database Relasional
55
3. FD2: (kode_mk)  (nama_mk, sks)
4. FD3: (nim,kode_mk)  nilai
Berarti Terjadi Partial Functional dependency:
• FD 1: (nim,kode_mk)  (nama_mhs,kd_jur,nama_jur) secara
parsial
• FD 2: (nim,kode_mk)  (nama_mk,sks) secara parsial
Walaupun tabel T-1 telah memenuhi syarat 1st NF namun karena
terjadi partial functional dependency maka tabel T-1 belum memenuhi
syarat 2nd NF.
Solusinya adalah dengan melakukan dekomposisi terhadap tabel T-1
dengan tetap menjaga agar datanya tetap konsisten. Hal ini dapat
dilakukan dengan melakukan dekomposisi tabel sesuai FD1, FD2
dan FD3 yang telah kita analisis sebelumnya. Adapun hasil
dekomposisi dari tabel T-1 adalah 3 tabel berikut ini:
Tabel 3.1 Contoh Tabel T-1-1
NIM
Nama_Mhs
Kd_Jur
Nama_Jur
1-01
Heru
TE
Elektro
2-02
Yati
IF
Informatika
2-01
Dewi
IF
Tabel 3.2 Contoh Tabel T-1-2
Informatika
Kode_MK Nama_MK
SKS
DU-001
English
2
Database
2
TE-001
Elektronika 3
IF-001
Algoritma
IF-002
Modul: Desain Database Relasional
3
56
Tabel 3.3 Contoh Tabel T-1-3
NIM
Kode_MK Nilai
1-01
DU-001
1-01
2-01
2-01
2-02
TE-001
A
IF-001
B
DU-001
IF-002
A
C
A
Ketiga tabel hasil dekomposisi tersebut sudah tidak mengalami
partial functional dependency. Dengan demikian ketiga tabel tersebut
telah
memenuhi syarat 2nd NF dan siap untuk diperiksa apakah
memenuhi syarat bentuk normal level berikutnya (3rd NF).
Adapun Tabel T-2 (hasil dekomposisi pada tahap 1st NF) juga tidak
mengalami partial functional dependency sehingga sudah memenuhi
2nd NF, tidak perlu didekomposisi lagi dan dapat langsung diperiksa
apakah memenuhi 3rd NF bersama-sama dengan tabel T-1-1, T-1-2
dan T-1-3.
Bentuk Normal Ke Tiga (3rd Normal Form)
Umumnya jika sebuah tabel telah memenuhi syarat bentuk normal
ke tiga (3rd NF) maka tabel tersebut sudah dianggap ‘cukup normal’.
Bentuk normal ke 3 adalah bentuk normal yang biasanya menjadi syarat
minimum bagi sebuah desan tabel walaupun akan lebih baik jika juga
memenuhi BCNF.
Kriteria 3rd NF:
• Memenuhi 2nd NF
Desain tabel yang tidak memenuhi syarat 2nd NF sudah pasti tidak
akan memenuhi syarat 3rd NF
• Tidak ada Transitive Functional dependency
Transitive functional dependency terjadi bila AB dan BC
Untuk lebih jelasnya perhatikan tabel T-1-1 dari tahap sebelumnya:
Modul: Desain Database Relasional
57
Tabel 3.4 Contoh tabel T-1-1
NIM
Nama_Mhs Kd_Jur Nama_Jur
2-01
Dewi
1-01
2-02
Heru
TE
Elektro
Yati
IF
Informatika
IF
Informatika
Perhatikan bahwa:
FD1: (nim)  (nama_mhs, kd_jur, nama_jur)
FD2: (kd_jur)  (nama_jur)
Berarti Terjadi Transitive FD:
(nim)  (nama_jur) secara transitif melalui (kd_jur)
Walaupun tabel T-1-1 telah memenuhi syarat 2nd NF namun karena
terjadi transitive functional dependency maka tabel T1 belum
memenuhi syarat 3rd NF. Solusinya adalah dengan melakukan
dekomposisi terhadap tabel T-1-1 dengan tetap menjaga agar
datanya tetap konsisten sesuai FD1dan FD2. Adapun hasil
dekomposisi dari tabel T-1-1 adalah 2 tabel berikut ini:
Tabel 3.5 Contoh Tabel T-1-1-1
NIM
Nama_Mhs
1-01
Heru
TE
2-02
Yati
IF
2-01
Dewi
Kd_Jur
IF
Tabel 3.18 Contoh Tabel T-1-1-2
Kd_Jur
TE
IF
IF
Modul: Desain Database Relasional
Nama_Jur
Elektro
Informatika
Informatika
58
Bentuk Normal Boyce Codd (BC Normal Form)
Boyce Codd Normal Form atau bentuk normal Boyce-Codd adalah
bentuk normal yang levelnya di atas 3rd NF. Kriteria BCNF:
• Memenuhi 3rd NF
Desain tabel yang tidak memenuhi syarat 3rd NF sudah pasti tidak
akan memenuhi syarat BCNF
• Untuk semua FD yang terdapat di tabel, ruas kiri dari FD tersebut
adalah super key
Jika ada satu saja FD pada tabel dimana ruas kirinya bukan super
key maka desain tabel tersebut belum memenuhi syarat BCNF.
Solusinya adalah dengan melakukan dekomposisi tabel dan tetap
mempertahankan konsistensi data seperti beberapa contoh pada sub
bab sebelumnya
Jarang ada kasus dimana sebuah tabel memenuhi 3rd NF tapi tidak
memenuhi BCNF. Umumnya sebuah tabel dikategorikan sudah
‘cukup normal’ jika sudah memenuhi kriteria BCNF. Jika tidak
memungkinkan untuk memenuhi kriteria BCNF, maka 3rd NF juga
sudah dianggap cukup memadai.
Bentuk-Bentuk Normal Lainnya
Selain bentuk-bentuk normal yang sudah diperkenalkan pada
beberapa sub bab sebelumnya, masih ada beberapa bentuk-bentuk
normal lain. Beberapa diantaranya adalah sebagai berikut:
1. Bentuk Normal ke-4 (4th NF)
diperkenalkan oleh Ronald Fagin pada tahun 1977
2. Bentuk Normal ke-5 (5th NF)
diperkenalkan oleh Ronald Fagin pada tahun 1979
3. Domain/Key Normal Form (DKNF)
diperkenalkan oleh Ronald Fagin pada tahun 1981
4. Bentuk Normal ke-6 (6th NF)
diperkenalkan oleh Date, Darwen dan Lorentzos pada tahun 2002
LATIHAN
Lakukan normalisasi untuk tabel berikut ini sampai mencapai BCNF
Modul: Desain Database Relasional
59
Modul: Desain Database Relasional
60
Jawilem
Jawilem
Jawilem
Juminten
A-02
A-02
A-02
A-03
Juminten
Jamal
A-01
A-03
Jamal
Nama_Ang
A-01
Id_Ang
B-03
B-01
B-02
B-02
B-03
B-02
B-01
Kd_Buku
Buku Anu
Buku Ini
Buku Itu
Buku Itu
Buku Anu
Buku Itu
Buku Ini
Jdl_Buku
Fiksi
Fiksi
Non Fiksi
Non Fiksi
Fiksi
Non Fiksi
Fiksi
Jns_Buku
R-01
R-01
R-02
R-02
R-01
R-02
R-01
No_Rak
31-Jan-09
31-Jan-09
23-Feb-09
14-Feb-09
31-Jan-09
31-Jan-09
23-Feb-09
Tgl_Pinjam
23-Feb-09
23-Feb-09
1-Mar-09
23-Feb-09
14-Feb-09
23-Feb-09
1-Mar-09
l_Kembali
RANGKUMAN
Modul: Desain Database Relasional
61
TES FORMATIF KEGIATAN BELAJAR 3
1.
Normalisasi bertujuan untuk _____
A. Membuat desain tabel menjadi lebih efisien
B. Menghidari update dan insertion anomaly
C. Meminimalkan redundansi data
D. Menghindari deletion anomaly
E. Semua benar
2.
Atribut atau sekumpulan atribut yang dapat membedakan setiap baris
data dalam tabel secara unik disebut _____
A. Super key
B. Candidate key
C. Primary key
D. Functional dependency
E. Tidak ada jawaban yang benar
3.
Jika diketahui FD1: (A,B)  (C) dan FD2: (C) (D,E) maka dapat
disimpulkan bahwa _____
A. Terjadi transitive functional dependency
B. Tabel tersebut tidak memenuhi syarat 3rd NF
C. (A,B)  (C,D)
D. Pilihan A dan B benar
E. Pilihan A, B dan C benar
4.
Syarat 2nd NF adalah _____
A. Tabel harus memiliki lebih dari 1 candidate key
B. Tidak boleh ada atribut atau kolom yang bergantung secara fungsional
pada sebagian dari candidate key
C. Tabel harus memiliki primary key
D. Tidak terjadi transitive functional dependency
E. Tidak ada jawaban yang benar
Modul: Desain Database Relasional
62
5.
Syarat 3nd NF adalah _____
A. Tabel harus bebas dari partial functional dependency
B. Tabel harus memiliki candidate key
C. Tidak terdapat multivalue atribut
D. Memenuhi syarat BCNF
E. Memenuhi syarat 2nd NF dan bebas dari transitive functional
dependency
6.
Pernyataan yang benar tentang primary key adalah _____
A. Setiap primary key pasti merupakan super key
B. Setiap primary key pasti merupakan candidate key
C. Primary key dalam sebuah tabel boleh lebih dari satu
D. Primary key boleh terdiri dari sekumpulan atribut
E. Semua jawaban benar
7.
Atribut atau sekumpulan atribut yang tidak dapat membedakan setiap
baris data dalam tabel secara unik disebut _____
A. Super key
B. Candidate key
C. Primary key
D. Functional dependency
E. Non key
8.
Jika sebuah tabel T dipastikan telah memenuhi syarat BCNF maka dapat
disimpulkan bahwa _____
A. Tabel T pasti memenuhi syarat 1st NF
B. Tabel T pasti bebas dari partial functional dependecy
C. Tabel T pasti bebas dari transitivefunctional dependency
D. Semua ruas kiri FD pada tabel T pasti merupakan super key
E. Semua benar
Modul: Desain Database Relasional
63
9.
Salah satu contoh denormalisasi adalah _____
A. View
B. Sequence
C. Materialized View
D. Index
E. Tidak ada jawaban yang benar
10. Dampak penerapan denormalisasi diantaranya _____
A. Penyimpanan data menjadi lebih boros
B. Performa database menjadi makin lambat
C. Kecepatan query menurun karena datanya redundan
D. Tabel menjadi mengalami partial functional dependency
E. Tidak ada jawaban yang benar
UMPAN BALIK DAN TINDAK LANJUT
Periksalah jawaban Saudara dengan kunci jawaban test formatif KB 3.
Hitunglah jumlah jawaban Saudara yang sesuai dengan kunci jawaban,
kemudian gunakan rumus di bawah ini untukmengetahui tingkat penguasaan
Saudara terhadap materi.
Rumus =
Jumlah jawaban yang sesuai kunci
Jumlah semua soal
X
100%
Penjelasan tingkat penguasaan
91 – 100 %
81 – 90,99 % = Baik
= Amat Baik
71 – 80,99% = Cukup
61 – 70,99% = Kurang
0 – 60,99% = Amat Kurang
Kalau Saudara mencapai tingkat penguasaan 80% atau lebih, maka
Saudara telah memahami modul ini. Tetapi apabila nilai Saudara kurang dari
80%, maka kami sarankan saudara mengulangi materi pada KB 3, ini
terutama materi yang saudara belum kuasai.
Modul: Desain Database Relasional
64
.
Modul: Desain Database Relasional
65
Modul: Desain Database Relasional
66
TES FORMATIF KEGIATAN BELAJAR 1
1.
b
7.
c
3.
b
9.
b
2.
4.
5.
6.
d
d
b
d
TES FORMATIF KEGIATAN BELAJAR 2
8.
d
10. b
11. b
12. d
1.
c
9.
3.
a
11. a
2.
4.
5.
6.
7.
8.
d
d
c
a
a
b
TES FORMATIF KEGIATAN BELAJAR 3
c
10. d
12. b
13. d
14. c
15. a
1.
b
9.
3.
b
11. c
2.
4.
5.
6.
7.
8.
a
a
b
b
a
c
Modul: Desain Database Relasional
d
10. b
12. a
13. b
14. c
15. d
67
TES SUMATIF
1.
b
11. c
3.
d
13. b
2.
4.
5.
6.
7.
8.
9.
c
a
d
b
b
b
b
10. a
Modul: Desain Database Relasional
12. a
14. c
15. d
16. a
17. b
18. d
19. c
20. a
68
1. Raghu Ramakrishnan / Johannes Gehrke “Database Management
2.
System” Second edition.
Modul: Desain Database Relasional
69