erd

Suplemen ERD –Modul Basisdata 2009/2010

Copyright @ Jurusan Teknik Informatika FTI UII Halaman 1

SUPLEMEN ERD

(cuplikan dari modul Basisdata 2009/2010)

Penulis: Nur Wijayaning R., S.Kom



Kompetensi Setelah menyelesaikan modul ini, praktikan diharapkan mampu:

a. Menjelaskan tahapan pembuatan basisdata.

b. Mendeskripsikan komponen Entity Relationship Diagram (ERD).

c. Membuat pemodelan dengan ERD untuk kasus sederhana.

d. Mengonversi ERD ke dalam bentuk tabel, baik secara manual maupun dengan bantuan

CASE Tool.

Hubungan Basisdata dan ERD

Tampilan basisdata secara lojik mirip dengan tampilan software spreadsheet (semisal Open Office Calc atau

Microsoft Excel), yakni berupa tabel dua dimensi: (1) baris, dan (2) kolom. Sebuah file spreadsheet biasanya

terdiri dari satu atau beberapa tabel; dan jika diperlukan data dari tabel lain, hubungan tersebut bisa

diimplementasikan dengan menyalin link ke sel yang dituju. Perhatikan ilustrasi pada gambar 1 berikut:

Gambar 1. (kiri) Sheet Rekapitulasi yang memuat link ke sheet lain. (kanan) Sheet Tugas yang berisi data nilai

setiap tugas dan reratanya.

Link menuju data lainnya (dalam contoh ini: data di sheet lain) ditunjukkan oleh kursor pada sel B2. Sebagai

jembatan penghubung, fungsi link ini mirip dengan “link” yang berlaku dalam tabel-tabel basisdata. Di

basisdata, link ini dikenal sebagai “Foreign Key”. Kelebihan Foreign Key dibandingkan link biasa pada

spreadsheet bisa dilihat pada Bab DDL, sedangkan cara pemakaian Foreign Key bisa dilihat pada Bab JOIN. Lalu,

bagaimana cara pembuatannya? Mari kita mulai dari tahap awal, yakni perancangan basisdata (dengan model

data berupa ERD), baru dilanjutkan dengan implementasi secara fisik dalam bentuk tabel seperti yang akan

dibahas dalam Bab DDL.

Memulai Merancang Basisdata

Basisdata adalah sekumpulan data yang saling bertautan dan merupakan representasi dari sebagian dunia

nyata (Ramakhrisnan, 2004). Oleh karena itu, pembuatan basisdata pun harus sesuai dengan kasus dan ruang

lingkupnya. Setelah itu, dicari fakta-fakta dari arsip-arsip fisik kemudian dianalisis. Sebagai contoh, ketika



hendak migrasi dari pengarsipan manual ke basisdata (dalam kasus supermarket), kita bisa menelusuri data

dan informasi yang muncul pada struk pembelian (untuk pelanggan), struk penerimaan barang di gudang,

laporan penjualan untuk manajer, laporan retur barang, dan lain-lain. Seluruh bukti fisik dikumpulkan, dicari

benang merahnya (keterkaitan antar data, red), dan dipertajam dengan bantuan informasi verbal dari (calon)

pengguna basisdata. Baru setelah itu, digambarkan dalam ERD dan dikonversi ke bentuk tabel. Secara ringkas,

tahapannya adalah sebagai berikut:

1. Menentukan kasus dan ruang lingkup basisdata

2. Mengumpulkan fakta untuk data-data yang akan disimpan di basisdata.

3. Memodelkan fakta ke dalam ERD. Proses ini bersifat iteratif, terutama untuk basisdata besar, dalam hal

penentuan fakta sebagai atribut atau sebagai entitas.

4. Mengonversi ERD ke dalam bentuk tabel, lengkap dengan properti tabel (kolom, tipe data, dan panjang

data).

5. Menjalankan DDL untuk mengimplementasikan tabel ke software DBMS (misalnya Oracle DB).

Contoh Kasus

Untuk memudahkan pemahaman, sekarang marilah kita buat basisdata sangat sederhana untuk praktikum di

Jurusan Teknik Informatika FTI UII! Agar lebih fokus, kasus dan ruang lingkupnya akan dibatasi sebagai berikut:

Apa yang akan disimpan dalam basisdata ini? Jawabannya adalah: data praktikan, lab, nama praktikum,

dan nilainya.

Fakta apa saja yang muncul?

1. Terdapat data praktikan yang meliputi NIM, Nama dan nomor telpon.

2. Terdapat 4 laboratorium pelaksana praktikum, yakni lab Sirkel, PIT, KSC dan Sisjarkom.

3. Lab Sirkel menangani praktikum Basisdata, RPL, dan PW. Sedangkan lab PIT mengelola praktikum

Alpro1 dan Struktur Data. Lab KSC untuk praktikum PBO dan Lab Sisjarkom untuk praktikum SO dan

Jarkom.

4. Praktikan mengambil praktikum sesuai dengan alokasi lab-nya, sehingga tidak dimungkinkan ada

praktikan mengambil praktikum Basisdata di Lab PIT, misalnya.

5. Selesai menjalani praktikum, praktikan akan memperoleh nilai (agar lebih sederhana, diasumsikan

hanya dibuat basisdata untuk menyimpan nilai khusus dalam 1 semester).

Fakta-fakta yang terkumpul dalam bentuk narasi (teks) tersebut selanjutnya diubah ke bentuk model data ERD

(Entity Relationship Diagram). Bagaimana cara menggambarnya? Mari terlebih dahulu kita pelajari komponen

pembentuk ERD yang digambar dalam bentuk simbol-simbol. Perlu diingat bahwa terdapat beragam versi

simbol ERD; simbol yang dipakai disini diambil dari buku "Database System COncepts 6th edition" karangan

Abraham Silberschatz.



Mengenal Komponen ERD

Terdapat lima macam komponen utama ERD, yakni:

a. Entity (entitas)

b. Attribute (atribut)

c. Unique Identifier

d. Relationship (hubungan antar entitas)

e. Kardinalitas

Mari kita bahas satu per satu! 1. Entity (entitas)

Entitas adalah konsep dasar dalam pemodelan basis data berupa individu yang mewakili sesuatu yang nyata

dan dapat dibedakan dari sesuatu yang lain. Kumpulan individu entitas disebut sebagai himpunan entitas. Di

dunia nyata, entitas berupa:

1. objek yang dapat diidentifikasikan

2. bisa dibedakan dari objek lain, serta

3. mempunyai karakteristik tertentu, dimana informasi yang berkaitan dengan objek yang bersangkutan

dikumpulkan.

Dalam ERD, entitas dilambangkan dengan simbol kotak (▭). Contoh entitas dalam dunia akademik antara lain

mahasiswa, dosen, mata kuliah, dan ruang kuliah. Sedangkan contoh entitas dalam toserba antara lain

pegawai, barang, dan rak.

2. Attribute (atribut)

Atribut adalah karakteristik atau properti dari entitas yang menyajikan penjelasan detail tentang entitas

tersebut. Atribut bisa bersifat WAJIB (harus ada), atau opsional (bisa ada, bisa pula tidak). Atribut

dilambangkan dengan simbol elips (ᴑ).

Atribut melekat pada entitas, layaknya atribut dalam seragam sekolah SMU, misalnya. Atribut-atribut inilah

yang membedakan antara seragam SMU dan seragam SMP, serta membedakan seragam SMU milik Andi dan

seragam SMU Budi. Dalam konteks basisdata, entitas barang memiliki atribut kode barang, nama barang,

harga, harga diskon, dan lain-lain. Kaitan erat antara entitas dan atributnya ini disimbolkan seperti pada

Gambar 2 berikut:

Barang

Kode Nama

Harga Hrabat

Stok



3. Unique Identifier

Sesuai dengan namanya, unique identifier adalah atribut yang bernilai berbeda untuk masing-masing individu

dalam himpunan entitas. Dalam analogi seragam SMU di dunia nyata, diketahui bahwa badge dan warna

seragam Andi dan Budi boleh sama, tetapi label nama dada tentu berbeda. Begitu pula dengan dunia

basisdata; nama atau tanggal lahir mahasiswa boleh jadi kebetulan sama, tetapi ada satu data yang pasti

berbeda, yakni NIM. Sehingga NIM inilah yang disebut sebagai unique identifier.

Untuk membedakannya dengan atribut-atribut biasa, dalam gambar ERD, unique identifier ditandai dengan

garis bawah (lihat atribut Kode pada Gambar 2 di atas).

4. Relationship (hubungan atau relasi antar entitas)

Kelebihan utama basisdata dibandingkan penyimpanan dalam file terletak pada kemampuan untuk saling

berinteraksi antar data. Interaksi inilah yang disebut sebagai relationship. Contoh yang paling mudah dipahami

adalah hubungan antara data mahasiswa dan data mata kuliah. Apa nama relasinya? Ya, benar: mahasiswa

mengambil mata kuliah. Demikian pula hubungan antara data dosen dan mata kuliah, yakni dengan nama

relasi: dosen mengampu mata kuliah.

Cara termudah untuk mendapatkan keterkaitan antar data adalah dengan mencari kata kerja yang mungkin

menghubungkan antar dua data atau lebih. Dalam contoh di atas, terdapat dua macam kata kerja: mengambil

dan mengampu. Relationship digambarkan dalam bentuk diamond (◇). Relasi inilah yang nantinya akan

diimplementasikan ke basisdata dalam bentuk “jembatan penghubung” antar data, yakni Foreign Key (bisa

dirujuk ke bab DDL).

5. Kardinalitas

Relationship secara lengkap tidak hanya dilihat dari nama relasinya, tetapi juga jumlah kejadian di entitas yang

terlibat dalam relasi tersebut. Contohnya adalah 1 pembeli menerima 1 struk bukti transaksi pembelian, 1

dosen bisa mengajar beberapa mata kuliah, dan lain-lain. Rasio jumlah kejadian antara dua entitas inilah yang

disebut dengan kardinalitas. Hanya ada empat kardinalitas yang mungkin terjadi, yakni:

One to one (1:1) : Satu entitas di A terhubung dengan maksimal satu entitas di B, dan begitu

sebalilknya. Misalnya, setiap tenaga sales diberi amanah untuk menjalankan hanya satu mobil box.

One to many (1:N) : Satu entitas di A terhubung ke sejumlah entitas di B, dan satu entitas di B hanya

terhubung dengan maksimal satu entitas di A. Misalnya seorang kustomer boleh mengirim lima surat pesanan

(request order), tetapi 1 order hanya berasal dari 1 kustomer.

Many to one (N:1) : Kebalikan dari kardinalitas 1:N.

Many to many (N:M) : Sebuah entitas di A terhubung ke sejumlah entitas di B, dan demikian juga

sebaliknya. Misalnya mahasiswa mengambil matakuliah. Si Ahmad mengambil matakuliah Alpro 2 (A), Basis

Data (A), dsb. Sedangkan Kelas Alpro 2 (A) sendiri berisi Ahmad, Budi, Citra, Dody, Zezen, dsb.



Berikut contoh penggambaran relationship lengkap dengan kardinalitasnya:

Translasi Fakta ke Simbol ERD

Fakta-fakta sudah terkumpul lengkap; begitu pula dengan notasi. Sekarang mari kita translasikan fakta satu per

satu:

1) Terdapat data praktikan yang meliputi NIM, Nama dan nomor telpon.

>> Komponen ERD:

Entitas ke-1: Praktikan, dengan tiga atribut: NIM, Nama, dan Nomor telpon

Unique identifier entitas ini: NIM.

2) Terdapat 4 laboratorium pelaksana praktikum, yakni lab Sirkel, PIT, KSC dan Sisjarkom.

>> Entitas ke-2: Laboratorium, dengan atribut: Nama lab.

Nama lab tidak disarankan menjadi unique identifier, sehingga perlu dibuat sendiri: Kode lab. Total atribut 2

buah.

3) Lab Sirkel menangani praktikum Basisdata, RPL, dan PW. Sedangkan lab PIT mengelola praktikum Alpro1

dan Struktur Data. Lab KSC untuk praktikum PBO dan Lab Sisjarkom untuk praktikum SO dan Jarkom.

>> Entitas ke-3: Praktikum, dengan atribut: Nama praktikum.

Unique identifier entitas ini dibuat sendiri, yakni: Kode Praktikum, sehingga total memiliki 2 atribut.

Terdapat hubungan (relationship) antara entitas praktikum dan lab, sehingga bisa dimunculkan kata kerja: Lab

mengelola Praktikum.

4) Praktikan mengambil praktikum sesuai dengan alokasi lab-nya, sehingga tidak dimungkinkan –misal-

praktikan mengambil praktikum Basisdata di Lab PIT.

>> Tidak ada entitas baru di fakta ke-4 ini.

Tapi terdapat relationship tambahan, yakni: Praktikan mengambil praktikum.

5) Selesai menjalani praktikum, praktikan akan memperoleh nilai.

>> Bagaimana dengan nilai? Apakah nilai akan menjadi atribut Praktikan? Tentu tidak, karena 1 praktikan bisa

memperoleh sebanyak 8 macam nilai praktikum selama kuliah di Jurusan Teknik Informatika. Atau nilai

termasuk atribut dari Praktikum? Juga bukan, karena 1 praktikum diikuti ratusan praktikan, sehingga tidak

mungkin 1 praktikum memiliki ratusan nilai. Oleh karena nilai hanya akan muncul ketika praktikan mengambil

Mata

kuliah Mahasiswa

Ambil

Kuliah

M N



praktikum, maka nilai akan menjadi atribut dari relationship tersebut. Apakah hal tersebut dibolehkan? Tentu

saja. Keadaan ini sama halnya dengan kemunculan atribut “total pembelian” pada relationship Pembeli

membeli barang. Atribut tersebut tidak bisa menempel, baik di entitas pembeli maupun entitas barang.

Hasil translasi fakta bisa dilihat pada ERD di Gambar 4.

Dari ERD Menuju Tabel Sesungguhnya Menggambar ERD cukup mudah bukan? Insya'Allah. Perlu diingat, bahwa gambar ERD di atas dikategorikan

sebagai ERD Lojik. ERD jenis ini merupakan model data yang mudah dibaca dan dimengerti, karena terdiri dari

gambar-gambar visual dan hubungan antar objek terlihat secara eksplisit. Tapi, basisdata tidak menyimpan

data dalam diagram ini, melainkan ke bentuk tabel yang terdiri dari kolom dan baris-baris untuk menyimpan

data. Tabel adalah representasi model data relasional yang kita pelajari sekarang. Oleh karenanya, kita perlu

mengkonversi kotak, elips, dan diamond menjadi tabel-tabel.

Tabel adalah representasi data dua dimensi: kolom dan baris. Dalam basisdata, baris menunjukkan isi data

sesungguhnya (Ahmad, 08-05-2005, Bandung, dan lain-lain). Oleh karena model data hanya menggambarkan

struktur data (bukan isinya!), maka pembahasan tabel untuk saat ini dibatasi pada penamaan tabel dan kolom.

Mengenai pengisian baris akan dibahas pada Bab DML, insya Allah.

Terdapat empat aturan sederhana (aturan lebih lengkap bisa dibaca di buku “Database System Concepts”)

dalam mengonversi ERD ke bentuk Tabel, yakni:

1) Entitas akan menjadi tabel

2) Atribut akan menjadi kolom, dan unique identifier akan menjadi Primary Key.

3) Khusus untuk relationship beratribut atau relationship berkardinalitas N:M akan dikonversi menjadi tabel

tersendiri.

4) Jika terdapat relationship, unique identifier pada entitas-entitas terhubung akan menjadi kolom tambahan

(Foreign Key).

Untuk kardinalitas 1:N atau N:1, Foreign Key berasal dari entitas yang berasio 1.

Untuk kardinalitas N:M, Foreign Key di tabel baru berasal dari entitas-entitas yang berelasi.

Praktikan

Praktikum

Lab mengambil

dikelola

NIM

Nama

No Telp

Kode Pr

Nama Pr

Kode Lab

Nam

aLab Nilai

M N 1 N



Sehingga didapatkan:

1. Tabel Praktikan, dengan 3 kolom (NIM, Nama dan, NoTelp). Perhatikan bahwa nama tabel dan nama

kolom harus terdiri dari 1 kata; jika lebih, maka harus digabungkan supaya membentuk 1 kata, sehingga

“No telpon” adalah salah.

2. Tabel Laboratorium, dengan 2 kolom (KodeLab, NamaLab).

3. Tabel Praktikum, dengan 2 kolom (KodePr, NamaPr).

4. Tabel Praktikan_has_Praktikum, dengan 3 kolom (KodePr, NIM, Nilai). Perhatikan bahwa nama tabel ini

terlalu panjang, sehingga sebaiknya dipersingkat.

Sebelum diimplementasikan dalam skrip DDL (untuk membuat basisdata sesungguhnya dalam software

DBMS), perlu dilakukan pendefinisian tipe data dan panjang kolom (disebut pula ERD Fisik). Daftar tipe data

yang didukung oleh Oracle DB bisa dilihat pada bab DDL. Sehingga, secara ringkas, hasil konversi ERD tersebut

bisa dilihat pada Gambar 5 di bawah.

Gambar ERD Fisik ini dibuat dengan bantuan CASE Tool (Computer Aided Software Engineering) yang gratis,

yakni DBDesigner4. Dengan bantuan tool ini, proses konversi dari ERD ke bentuk tabel dan skrip DDL (untuk

pembuatan tabel) menjadi jauh lebih mudah karena bersifat otomatis. Oleh karena ada kemudahan

pemrogaman tersebut, diharapkan mahasiswa bisa lebih fokus terhadap proses analisis dalam perancangan

basisdata.

erd

Documents

Transcript of erd