ENTITY RELATIONSHIP DIAGRAM

1

ENTITY RELATIONSHIP DIAGRAM

1

PENDAHULUAN

Bab ini akan membahas bagaimana profesional sistem menggambarkan model data secara grafik dengan menggunakan entity relationship diagram yang kadang-kadang dikenal sebagai ERD (istilah ini yang akan selalu digunakan) atau diagram ER.

Dengan kata lain, ERD adalah suatu model jaringan yang menggunakan susunan data yang disimpan dalam sistem secara abstrak. Jadi, jelaslah bahwa ERD ini berbeda dengan DFD yang merupakan suatu model jaringan fungsi yang akan dilaksanakan oleh sistem , sedangkan ERD merupakan model jaringan data yang menekankan pada struktur-struktur dan relationship data.

Biasanya ERD ini digunakan oleh profesional sistem untuk berkomunikasi dengan pemakai eksekutif tingkat tinggi dalam suatu organisasi (seperti: wakil presiden direktur dan manajer yang tidak tertarik pada pelaksanaan operasi-operasi sistem sehari-hari). Pemakaian ini lebih tertarik pada data-data apa saja yang dibutuhkan untuk bisnis mereka? Bagaimana data tersebut berelasi dengan data lainnya? Siapa saja yang diperkenankan untuk mengakses data tersebut?

ERD juga menguntungkan bagi profesional sistem, karena ERD memperlihatkan hubungan antara data store pada DFD. Hubungan ini tidak terlihat pada DFD, karena DFD hanya memusatkan perhatian pada fungsi-fungsi sistem bukan pada data yang dibutuhkan.

2

NOTASI ERD

Seperti telah disebutkan diatas bahwa ERD merupakan alat pembuatan model data secara grafik, maka ERD memiliki notasi-notasi yang digunakan untuk menggambarkan model data. Notasi-notasi yang digunakan pada bab ini merupakan notasi yang sering digunakan pada artikel dan buku, seperti pada artikel oleh Chen; buku oleh James Martin, Elmasri, C.J. Date dan Fred R.Mc Fadden & Jeffrey A.Hoffer.

Notasi-notasi ERD ini dapat dilihat pada Gambar 3.1. Setiap notasi pada ERD mewakili komponen-komponen ERD yang akan dibahas pada sub berikut.

3

KOMPONEN ERD

Komponen utama ERD adalah entitas (entity), relationship dan atribut (attribute). Masing-masing komponen ini akan dibahas dibawah berikut, sedangkan komponen-komponen lainnya akan diperkenalkan pada sub bab-sub bab berikutnya.

Gambar 3.1 Notasi ERD DASAR ARTI Notasi 1 Notasi 2 Derajat Relationship Entitas Entitas Lemah Relationship Identifying Relationship Gerund Atribut

Atribut Kunci Utama

Atribut Multivalue Atribut Komposisi Derived Attribute Unary Binary Ternary

3 DASAR ARTI Notasi 1 Notasi 2 Kardinalitas Relationship 1 1 1 M M M 1:1 1:M 0:1 0:M Relationship

Class– Subclass / Subtype – Supertype

Kardinalitas satu-ke-satu

Kardinalitas satu-ke-banyak Kardinalitas banyak-ke-banyak

Kardinalitas Mandatory One

Kardinalitas Banyak (1,2,….,M)

Kardinalitas Optional 0 atau 1

Kardinalitas Optional 0 atau

banyak (0,1,2,….,M)

Relationship Class-Subclass

Relationship Eksklusif

Gambar 3.1 Notasi ERD (Lanjutan) ISA

Entitas

Entitas adalah sesuatu dalam dunia nyata dengan keberadaan yang bebas baik secara fisik maupun secara abstrak. Entitas dengan keberadaan secara fisik dapat didefinisikan sebagai orang, benda, tempat. Sedangkan, Entitas dengan keberadaan secara abstrak adalah kejadian dan konsep. Beberapa contoh dari Entitas diatas adalah :

 Orang : PEGAWAI, MAHASISWA, PASIEN

 Tempat : NEGARA, DAERAH, KOTA

 Benda : KENDARAAN, MESIN, OBAT

 Kejadian: PENJUALAN, PEMBELIAN, PENDAFTARAN

 Konsep : REKENING, KURSUS, MATA KULIAH, PEKERJAAN

Ada perbedaan penting antara tipe entitas dengan instance entitas. Tipe entitas (kadang-kadang disebut kelas entitas) adalah sekumpulan entitas yang menggunakan sifat dan karakteristik yang sama. Masing-masing tipe entitas dalam ERD diberikan nama yang mewakili satu kelas/set dan biasanya menggunakan kata benda. Contoh: MAHASISWA,

KOTA, KURSUS (Lihat Gambar 3.2)

Gambar 3.2 Komponen Tipe Entitas

Instance entitas (intance) adalah satu kejadian tunggal dari tipe entitas. Gambar 3.3 menerangkan perbedaan antara tipe entitas dan dua instancenya. Banyak instance dari tipe entitas tersebut yang mewakili data yang disimpan dalam database. Misalkan, hanya ada satu tipe entitas MAHASISWA, tetapi ada banyak instance dari entitas ini yang disimpan dalam database.

Mahasiswa

Kota

Kursus

Tipe Entitas : MAHASISWA

Atribut : NPM NAMA ALAMAT RT/RW KOTA KODEPOS T_LAHIR TGL LAHIR

Instance dari MAHASISWA : 10292432 50293701 Mawarwati Amir Samsudin Jl. ABC No.13 Jl. BDF No. 35

001/004 012/003

Jakarta Selatan Jakarta Timur

12920 13444

Semarang Jakarta

5

Atribut

Tiap tipe entitas memiliki sekumpulan atribut yang berkaitan dengannya. Dengan kata lain, atribut merupakan sifat atau karakteristik suatu entitas yang menyediakan penjelasan detail tentang entitas tersebut. Bukan hanya entitas yang memiliki atribut, tetapi relationship.

Dibawah ini, diberikan contoh beberapa tipe entitas beserta atributnya :

 MAHASISWA : NPM, NAMA, ALAMAT, RT/RW, KOTA, KODEPOS

 MOBIL : NO_MOBIL, WARNA, JENIS, CC

 PEGAWAI : NIP, NAMA, ALAMAT, KEAHLIAN

Ada beberapa tipe atribut tersebut yang perlu diperhatikan dalam penggambaran ERD, yaitu atribut kunci kandidat (candidate key) dan kunci utama (primary key); atribut bernilai tunggal (single-value attribute) dan bernilai jamak (multivatue attribute); atribut komposisi (composite attribute) dan atomic (atomic attribute); dan atribut yang dihasilkan (derived attribute). Kesemua tipe atribut ini akan dijelaskan pada sub bab-sub bab berikut.

Atribut kunci kandidat dan kunci utama

Setiap atribut harus memiliki satu atau sekumpulan atribut yang mengidentifikasikan setiap instancenya secara unik dan membedakan satu instance dengan instance lainnya dari satu tipe entitas yang sama. Satu atribut atau kombinasi atribut yang mengidentifikasikan setiap instance suatu entitas secara unik disebut kunci kandidat. Kunci kandidat untuk

MAHASISWA pada contoh diatas adalah NPM.

Beberapa entitas mungkin memiliki lebih dari satu kunci kandidat. Satu kunci kandidat untuk PEGAWAI adalah NIP; kunci kandidat yang kedua adalah kombinasi dari

NAMA dan ALAMAT (disini diasumsikan bahwa tidak ada dua pegawai dengan nama

yang sama mempunyai alamat yang sama pula). Jika ada lebih dari satu kunci kandidat, profesional sistem harus memilih salah satu kunci kandidat sebagai kunci utama. Jadi, kunci utama adalah kunci kandidat yang dipilih sebagai identifier untuk satu tipe entitas.

Ada beberapa kriteria untuk memilih kunci utama, yaitu :

 Pilih kunci kandidat yang tidak akan berubah nilainya selama suatu tipe entitas masih

digunakan dalam database.

 Pilih kunci kandidat yang membuat tiap Instance dari entitas memiliki nilai, jadi

atributnya dijamin memiliki nilai-nilai yang valid dan tidak null.

Gambar 3.4 menunjukkan tampilan untuk tipe entitas MAHASISWA dengan menggunakan notasi ERD.

Gambar 3.4 Entitas dengan Atribut-atributnya

Mahasiswa

Kodepos NPM Kota Nama Alamat Rt_Rw

Atribut bernilai tunggal dan jamak

Banyak atribut memiliki satu nilai tunggal untuk satu, entitas tertentu, atribut seperti ini disebut Atribut bernilai tunggal. Misalkan, entitas MAHASISWA memiliki satu nilai untuk NPM.

Ada juga atribut yang memiliki sekelompok nilai untuk setiap instance entitas, contohnya atribut WARNA untuk entitas MOBIL. Atribut seperti ini disebut sebagai Atribut multivalue atau bernilai jamak.

Penggambaran atribut bernilai, tunggal dan jamak dapat dilihat pada Gambar 3.5.

Gambar 3.5 Entitas dengan atribut single value dan multivalue

Atribut komposisi dan atomic

Suatu atribut mungkin terdiri dari beberapa atribut yang lebih kecil dengan arti bebas dari atribut itu sendiri. Atribut ini disebut Atribut komposisi, seperti atribut NAMA untuk entitas PEGAWAI (Lihat Gambar 3.6)

Gambar 3.6 Entitas dengan atribut komposisi

Ada juga suatu atribut yang tidak dapat dibagi kedalam beberapa atribut yang lebih kecil, atribut ini disebut Atribut atomic, misalkan atribut JENIS untuk entitas MOBIL.

Mobil

No.mobil _CC Jenis Warna

Pegawai

Nm_Belakang Nama Nm_Tengah Nm_Depan

7

Derived Atribut / Atribut yang dihasilkan

Pada beberapa kasus, ada dua atau lebih nilai atribut yang berelasi, misalkan atribut UMUR dan TGL.LAHIR untuk entitas MAHASISWA. Nilai atribut UMUR dapat ditentukan dengan tanggal sekarang dan nilai atribut TGL.LAHIR mahasiswa yang bersangkutan. Atribut UMUR ini disebut Derived attribute dan dikatakan bahwa atribut UMUR dihasilkan dari atribut TGL.LAHIR. Penggambaran atribut ini dengan menggunakan notasi ERD dapat dilihat pada Gambar 3.7.

Gambar 3.7

Relationship

Relationship merupakan hubungan yang terjadi antara instance-instance dari satu atau lebih tipe entitas. Misalkan, suatu perguruan tinggi tertarik untuk mengetahui mata kuliah apa saja yang telah diambil oleh tiap mahasiswanya. Hal ini menuju pada suatu relationship (yang disebut Mengambil) antara entitas MAHASISWA dan

MATA_KULIAH yang dapat digambarkan sebagai berikut :

Gambar 3.8 Entitas dengan Relationship Mengambil

Gambar 3.8 diatas menunjukkan relationship banyak-ke-banyak, artinya tiap mahasiswa mungkin mengambil lebih dari satu mata kuliah, dan tiap mata kuliah mungkin diambil oleh lebih dari satu mahasiswa. Hal yang lebih penting dari relationship

Mengambil adalah bahwa relationship Mengambil dapat digunakan untuk menentukan

mata kuliah apa saja yang diambil oleh seorang mahasiswa tertentu, sebaliknya dengan relationship Mengambil mahasiswa-mahasiswa yang telah mengambil mata kuliah tertentu dapat dicari.

Seperti entitas, relationship juga mungkin memiliki atribut atau sifat yang membedakannya dengan relationship lainnya. Misalkan, suatu perguruan tinggi ingin

Mahasiswa Tgl_lahir Umur Mahasiswa Mengambil l Mata_Kuliah

mencatat semester berapa, seorang mahasiswa mengambil tiap mata kuliah yang ditawarkan. Jadi Gambar 3.8 diatas dapat diperbaiki seperti pada Gambar 3.9.

Gambar 3.9 Relationship Mengambil dengan atribut SEMESTER

Perlu diingat bahwa sebaliknya relationship diberi nama dengan menggunakan frasa kata kerja yang singkat dan deskriptif pada si pemakai.

Derajat Relationship

Derajat Relationship adalah jumlah entitas yang berpartisipasi dalam satu relationship. Jadi, relationship Mengambil pada contoh diatas adalah relationship berderajat dua, karena ada dua entitas, yaitu entitas MAHASISWA dan MATA_KULIAH.

Ada tiga derajat relationship yang sering digunakan dalam ERD, yaitu unary (berderajat satu), binary (berderajat dua) dan ternary (berderajat tiga). Relationship yang berderajat lebih tinggi mungkin ada saja, tetapi relationship ini jarang, digunakan dalam praktek, sehingga pembahasan derajat relationship ini hanya dibatasi pada tiga derajat yang disebutkan diatas. Contoh-contoh relationship unary, binary dan ternary dapat dilihat pada Gambar 3.10.

Gambar 3.10 Derajat Relationship

Relationship Unary yang sering disebut juga Relationship Rekursif merupakan relationship antara instance-instance dari satu entitas saja. Pada Gambar 3.10 (a), relationship Menikahi menunjukkan relationship satu-ke-satu antara instance-instance dari entitas PEGAWAI.

Mahasiswa _Mengambil Mata_Kuliah

Semester

Mahasiswa _Menikah

(a) Relationship Unary

Bekerja Dept Pegawai (b) Relationship Binary Jumlah Pabrik Gudang Alat Mengirimkan (c) Relationship Ternary

9 Relationship Binary merupakan relationship antara instance-instance dari dua tipe entitas. Relationship ini yang paling umum digunakan dalam pembuatan model data. Gambar 3.10 (b) menunjukkan bahwa relationship Bekerja untuk merupakan relationship banyak-ke-satu, artinya seorang pegawai hanya dapat bekerja untuk satu departemen dan satu departemen memiliki banyak pegawai.

Relationship Ternary merupakan relationship antara instance-instance dari tiga tipe entitas secara serentak. Pada Gambar 3.10 (c), relationship Mengirimkan mencatat jumlah suatu alat tertentu yang dikirimkan oleh suatu pabrik menuju ke suatu gudang yang telah ditentukan. Masing-masing entitas mungkin berpartisipasi satu atau banyak dalam suatu relationship ternary.

Perlu dicatat bahwa relationship ternary tidak sama dengan tiga relationship binary.

Kardinalitas dalam Relationship

Misalkan ada dua tipe entitas, A dan B, yang dihubungkan dengan satu relationship. Kardinalitas suatu relationship adalah jumlah instance entitas B yang dapat atau harus dihubungkan dengan tiap instance entitas A.

Kardinalitas untuk relationship yang umum adalah :

 satu-ke-satu (one-to-one)  satu-ke-banyak (one-to-many)  banyak-ke-banyak (many-to-many)

Contoh Kardinalitas dalam relationship adalah pertimbangan relationship berikut untuk film video :

Gambar 3.11 Contoh Kardinalitas Relationship

Dari contoh diatas jelaslah bahwa suatu toko video mungkin memiliki lebih dari satu copy untuk film-film tertentu, tetapi toko tersebut mungkin tidak memiliki satu copy pun dari suatu film tertentu dalam persediaan. Dengan demikian dibutuhkan notasi yang lebih rinci untuk menunjukkan range kardinalitas untuk suatu relationship.

Kardinalitas minimum dan maksimum. Kardinalitas minimum suatu relationship adalah jumlah minimum instance dari entitas B yang mungkin berhubungan dengan tiap instance dari entitas A. Pada contoh sebelumnya, jumlah minimum copy film yang tersedia

untuk suatu film adalah ‘nol’. Kardinalitas maksimum adalah jumlah maksimum instance. Untuk contoh diatas, jumlah maksimumnya adalah “banyak” (suatu nilai tak terdefinisi

yang lebih dari satu). Dengan menggunakan notasi pada Gambar 3.1, relationship ini digambarkan sebagai berikut :

Film _{Disimpan sbg} Copy_Film

Film _{Disimpan sbg} Copy_Film

Pada Gambar 3.12, simbol nol pada garis dekat entitas COPY FILM berarti kardinalitas minimum nol, sementara notasi berkaki tiga, berarti kardinalitas maksimum banyak.

Sudah tentu suatu relationship adalah dua Arah (bidirectional), sehingga ada juga notasi kardinalitas yang dekat entitas FILM. Perhatikan bahwa minimum dan maksimum entitas ini keduanya sama, yaitu kardinalitas itu. Hal ini disebut Kardinalitas mandatory one. Dengan kata lain, tiap copy suatu film yang disimpan harus merupakan satu copy tepat satu film.

Umumnya partisipasi dalam suatu relationship mungkin optimal/parsial atau mandatory/total untuk entitas yang terlibat. Jika kardinalitas minimum adalah nol, maka partisipasi adalah optional, sedangkan jika kardinalitas minimum adalah satu, partisipasi adalah mandatory.

Contoh-contoh dari tiga relationship yang menampilkan semua kombinasi kardinalitas minimum dan maksimum yang mungkin dapat dilihat pada Gambar 3.13.

(a) Kardinalitas Mandatory

(b) Kardinalitas Satu Optional, Satu Mandatory

(c) Kardinalitas Optional

Gambar 3.13 Contoh-contoh Kardinalitas dalam Relationship Pasien Memiliki Riwayat Penyakit Pegawai Ditugaskan pada Proyek Pegawai Menikah dengan

11 Dari Gambar 3.13, ada tiga deskripsi singkat dari masing-masing kardinalitas, yaitu:

 PASIEN Memiliki RIWAYAT PENYAKIT (Gambar 3.13(a)). Setiap pasien memiliki

satu riwayat penyakit atau lebih (diasumsikan bahwa kunjungan awal pasien selalu dicatat sebagai suatu instance dari RIWAYAT PENYAKIT). Tiap instance RIWAYAT PENYAKIT dimiliki oleh tepat satu PASIEN (kardinalitas mandatory one yang lain).

 PEGAWAI Ditugaskan pada PROYEK (Gambar 3.13(b)). Tiap PROYEK memiliki

paling sedikit satu PEGAWAI yang ditugaskan pada proyek ini (beberapa proyek memiliki lebih dari satu pegawai). Tiap PEGAWAI mungkin atau tidak (optional) ditugaskan pada PROYEK yang ada, atau mungkin ditugaskan pada beberapa PROYEK.

 PEGAWAI Menikahi PEGAWAI (Gambar 3.13(c)). ERD ini adalah kardinalitas nol

atau satu dalam kedua arah, karena seorang pegawai mungkin atau tidak menikah.

Mungkin juga kardinalitas maksimum merupakan jumlah yang sudah pasti, bukan nilai banyak yang berubah-ubah. Misalkan, kebijakan, perusahaan menyatakan bahwa seorang pegawai mungkin bekerja pada paling banyak lima proyek pada waktu yang sama. Dengan aturan ini, angka lima dapat ditempatkan diatas atau dibawah garis berkaki tiga dekat entitas PROYEK pada Gambar 3.13(b).

Ketergantungan Keberadaan (Existence Dependency). Konsekuensi dari kardinalitas mandatory one adalah bahwa suatu instance dari tiap entitas tidak akan ada, kecuali bila ada suatu instance dari tipe entitas yang direlasikan. Misalkan, suatu instance dari entitas COPY FILM tidak akan ada kecuali entitas.

FILM yang direlasikan sudah ada. Dengan kata lain, ketergantungan keberadaan berarti bahwa suatu instance dari satu entitas tidak akan ada tanpa keberadaan instance dari entitas lain yang direlasikannya.

Istilah lain yang sering digunakan untuk tipe entitas yang memiliki kardinalitas mandatory one adalah entitas lemah (weak entity). Entitas lemah adalah suatu tipe entitas yang memiliki ketergantungan keberadaan atau suatu entitas yang tidak memiliki atribut kunci utama. Oleh sebab itu, suatu instance dari entitas lemah tidak akan ada secara bebas, tetapi tergantung pada keberadaan instance entitas lainnya. Dengan kata lain, beberapa instance entitas tidak dapat dibedakan satu sama lain, karena kombinasi dan nilai atribut entitas-entitas tersebut sama. Untuk contoh film video, COPY FILM adalah entitas lemah.

Identifying Relationship. Seperti telah dijelaskan diatas bahwa entitas lemah sering

tidak memiliki identifier alami (atau kunci kandidat), maka kunci utama dari entitas parent/pemilik (entitas tempat entitas lemah, bergantung) sering digunakan sebagai bagian kunci utama dari entitas anak (child) yang bergantung. Gambar 3.12 dapat diperbaiki seperti pada Gambar 3.14.

Gambar 3.14 Contoh Entitas Lemah

Pada gambar diatas, tampaklah bahwa kunci utama entitas parent FILM, yaitu NO_FILM, adalah bagian dari kunci utama entitas anak COPY FILM (NO_COPY adalah bagian lain dari kunci utamanya). Suatu Identifying relationship merupakan relationship tempat kunci utama entitas parent digunakan sebagai bagian kunci utama dari entitas anak.

Ada dua keuntungan dari Identifying Relationship, yaitu :

1. Integritas data. Ketergantungan keberadaan dikuatkan karena kunci utama yang dipakai bersama-sama (oleh sebab itu entitas lemah tidak akan ada kecuali entitas parent ada). 2. Memudahkan pengaksesan entitas anak. Pada contoh diatas, COPY FILM dapat dicari

jika nomor film dan nomor copy diketahui.

Gerund

Gerund (yang kadang-kadang disebut entitas komposisi) adalah suatu relationship banyak-ke-banyak yang menjadi entitas dengan relationship (yang memiliki kardinalitas satu-ke-banyak, Gambar 3.15 menunjukkan representasi alternatif dari relationship ternary yang digambarkan pada Gambar 3.10(c). Pada gambar 3.15, tipe entitas (gerund) PENGIRIMAN menggantikan relationship Mengirim pada Gambar 3.10(c). Simbol belah ketupat diikut-sertakan dalam simbol persegi panjang untuk entitas sebagai pengingat bahwa entitas ini, dihasilkan dari suatu relationship.

Tiap instance PENGIRIMAN merepresentasikan pengiriman yang sesungguhnya dilakukan oleh pabrik alat tertentu menuju ke gudang yang sudah ditentukan. JUMLAH pengiriman merupakan atribut PENGIRIMAN. Nomor pengiriman, diberikan untuk tiap pengiriman yang dilaksanakan dan merupakan atribt kunci utama (Lihat Gambar 3.15)

Gambar 3.15 Tipe Entitas SHIPMENT (Gerund)

Film Disimpan Sbg

Nm Film

No Film No Film No Copy

Copy_Film No Pengiriman Jumlah Gudang Pabrik _Pengiri man Alat

13 Perlu diingat bahwa notasi belah ketupat tidak digunakan sepanjang, garis dari gerund ke entitas-entitas lainnya. Hal ini karena garis-garis ini bukan menampilkan relationship binary. Untuk mempertahankan arti yang sama seperti relationship ternary pada Gambar 3.10(c), relationship Mengirim dari Gambar 3.10(c) tidak dapat dibagi kedalam tiga relationship bianry antara PENGIRIMAN dan PABRIK, ALAT dan GUDANG.

Pada relationship binary dengan kardinalitas banyak-ke-banyak, tidak ada salah apakah relationship ini ditampilkan sebagai gerund atau entitas. Dengan BMS relational, relationship banyak-ke-banyak baik sebagai gerund ataupun identitas diimplementasikan dalam cara yang sama, yaitu sebagai tabel database. Untuk relationship ternary atau berderajat yang lebih tinggi, jika salah satu atau lebih relationship bukan relationship banyak, maka relationship ini tidak dapat ditampilkan sebagai entitas.

PEMBUATAN MODEL ATRIBUT MULTIVALUE

Pada pembahasan atribut sebelumnya, WARNA digunakan sebagai contoh atribut multivalue. Penggambaran atribut ini menggunakan elips bergaris ganda (Lihat Gambar 3.16(a)). Biasanya atribut-atribut multivalue sering dihapus dari entitasnya, kemudian dibentuk entitas baru yang memiliki relationship dengan entitas tempat atribut multivalue dihapus.

Pada Gambar 3.16(b), tipe entitas baru WARNA menggantikan atribut WARNA. Sekarang ada relationship banyak-ke-banyak antara MOBIL dari WARNA, JENIS WARNA dipilih sebagai kunci utama WARNA. Secara tipikal, untuk menjadi entitas disamping memiliki kunci utama (yaitu JENIS WARNA) WARNA harus juga memiliki beberapa atribut bukan kunci.

Kelompok Data Berulang. Kelompok Data Berulang merupakan sekumpulan atau lebih atribut multivalue yang secara logika bervariasi. Contoh, Gambar 3.17(a) merupakan form kartu pasien yang menunjukkan data bagi pasien dan pasien tersebut berkunjung ke suatu klinik. Gambar 3.17(b) merupakan ERD awal dari tipe entitas PASIEN dengan tiga atribut multivalue untuk tiap pasien, yaitu TGL KUNJUNG, DOKTER dan GEJALA. Ketiga atribut ini secara logika direlasikan dan membentuk kelompok berulang (disini diasumsikan bahwa hanya ada satu kunjungan pada tanggal tertentu dan bahwa pasien hanya menemui seorang dan diperiksa untuk satu gejala tiap berkunjung).

(a) Entitas dengan Atribut Multivalue Mobil

Warna Jenis

(b) Atribut Multivalue Dihapus

Gambar 3.16 Penghapusan Atribut Multivalue dari Entitas

Gambar 3.17(c) menunjukkan hasil penghapusan kelompok berulang dari PASIEN. Tipe entitas baru yang disebut RIWAYAT PASIEN dibentuk, dan tiga atribut multivalue yang membentuk kelompok berulang dipindahkan dari entitas PASIEN. TGL KUNJUNG dipilih sebagai kunci utama tipe entitas baru ini. Ada relationship satu-ke-banyak dari PASIEN dan RIWAYAT PASIEN, dan RIWAYAT PASIEN adalah entitas lemah.

PEMBUATAN MODEL DATA TERGANTUNG PADA WAKTU

Isi database berubah dari waktu ke waktu. Misalkan, dalam database yang berisi: Informasi produk, harga untuk tiap produk mungkin berubah bila biaya bahan, upah kerja dan kondisi pasar berubah. Jika hanya harga saat ini dibutuhkan, maka hanya nilai harga ini yang perlu ditampilkan.

Gambar 3.18(a) menunjukkan hal ini sebagai serangkaian harga dan tanggal berlakunya tiap harga tersebut. Hal ini menghasilkan kelompok data berulang yang memasukkan atribut-atribut HARGA dan TGL BERLAKU. Pada Gambar 3.18(b), kelompok berulang ini diganti dengan entitas baru, (entitas lemah) yang diberi nama RIWAYAT HARGA. Relationship antara PRODUK dan RIWAYAT HARGA adalah Memiliki.

Kartu Pasien

No. Pasien : A0014 Nama Pasien : Amelia Indah Alamat : Jl. XYZ

Tgl.

Kunjungan Dokter Gejala

03-02-95 Amir Demam

17-06-95 Hasan Sakit Tenggorokan

16-08-95 Amir Flu …… …… …… Warna Mobil Memiliki CC JenisWarna No Mobil Jenis

15 (a) Contoh Data

(b) Entitas dengan Kelompok Berulang

(c) Kelompok Berulang Dihapus

Gambar 3.17 Penghapusan Kelompok Berulang

NORMALISASI

Dalam merancang data base arus dapat di jawab apabila kita di berikan data,maka bagaimana kita menentukan struktur logik yang tepat untuk data tersebut, atau bagaimana kita menentukan rellation-relation yang di perlukan dan apa atributnya.

Semua relation dan relational data baseselalu sudah ternormalisasi, dalam arti bahwa semua relation sudah di definisikan terhadap domain sederhana, yaitu domain yang hanya berisi nilai atomik. Dalam normalisasi lanjutan kita berusaha untuk menghilangkan/mengurangi data yang di duplikasi atau mubazir agar supaya mendapatkan bentuk yang baik,hemat tempat, hemat waktu, hemat biaya dan menberikan respon yang baik dan cepat.

Pasien Nama Pasien No Pasien _Alamat Tgl Kunjungan Dokter Gejala Pasien Riwayat Pasien Memiliki Tgl Kunjungan2 Tgl Kunjungan1

No Pasien Nama Pasien _Alamat

No Pasien Tgl Kunjungan

Metode normalisasi adala suatu pproses perancangan data base untuk mendapatkan bentuk normal. Normalisasi berkaitan dengan suatu proses sedang Normal From berkaitan dengan output proses. Jika suatu relasi berada dalam bentuk normal, maka ia juga termasuk dalam bentuk normal tersebut di dalamnya/di bawahnya. Contoh : jika suatu berada dalam bentuk 2NF, maka relasi tersebut termasuk pula dalam bentuk 1NF.

Suatu relation dikatakan sudah berada pada bentuk normalisasi tertentu bila memenuhi beberapa batasan tertentu pada tingkat tersebut. Tingkat normalisasi yang lebih tinggi di anggap lebih baik dari tingkat dibawahnya.

Tingkat-tingkat normalisasi :

1. Relation umum (yang belum dan yang sudah ternormalisasi) 2. 1NF (First Normal Form) relation yang sudah ternormalisasi. 3. 2NF (Secound Normal Form) relation.

4. 3NF (Third Normal Form) relation.

5. BCNF (Boyce Codd Normal Form) relation. 6. 4NF (Fourth Normal Form) relation.

7. PJ/NF(Project Join Normal Form) atau 5NF(Fifth Normal Form) relation

Aplikasi yang dapt diselesaikan hanya sampai bentuk normal 3. Aplikasi Normal Form BCNF – DKNF cenderung menggunakan aplikasi matematika yang lebih rumit di bandingkan dengan bentuk aplikasi 1NF – 3NF. Bentuk DKNF sampai sekarang masih sebagai hipotesa belum di buktikan. Untuk 6NF dan 7NF dan seterusnya belum terpikirkan saat ini.

Dalam Unnormalized Relation masih banyak ditemui bentuk normal seperti tabel yang telahh dicatat di atas yang menpunyai ciri berulang (data redudant) dalam suatu grup.

1NF 2NF 3NF BCNF 4NF 5NF

17

LANGKAH - LANGKAH NORMALISASI

Menghilangkan ciri yang berulang

Menghilangkan ketergantungan partial

Menghilangkan ketergantungan transitil

FUNCTIONALLY DEPENDENT DAN FUNCTIONALLY DETERMINES

Suatu atribut Y di sebut functionally dependent tarhadap atribut X dalam suatu relation R bila setiap nilai X di R hanya ada satu hubungan ketergantungan dengan nilai Y di R pada suatu saat. Ditulis R.X R.Y

Contoh dalam database suplier dan part, atribut SNAME,STATUS dan CITY dari relation S semua tergantung pada (functionally dependent) terhadap atribut S# karena setiap nilai S# hanya ada satu hubungan dengan nilai-nilai di SNAME, STATUS dan CITY.

Dalam simbol dapat kita tulis sebagai : S.S# → S. SNAME

S.S# → S.STATUS S.S# → S.SCITY

Atau S.S → S.(SNAME,STATUS,CITY)

S.S# → S.SNAME menyatakan S.SNAME functionally dependent terhadap S.S# Atau

sebaliknya S.S# functionally determines S.SNAME

Functionally dependent (FD) adalah salah sat dari batasan integritas (Integrity Constraints).

Gambar 1. Functional Dependent di relasion S,P, dan SP UNNORMALIZED RELATION 1 NF 2 NF 3 NF S# SNAM EE STATU S CITY S# P# PNAME COLOR WEIGHT CITY P # QT_Y

FIRST NORMAL FORM (1NF)

SP1 SP2 S# P# QTY S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

Suatu relation di katakan sudah berada pada 1NF jika dan hanya jika semua nilai atributnya adala atomik (tunggal)

Contoh relation FIRST (S#,STATUS,CITY,P#,QTY), dimana STATUS atau CITY tidak secara penuh tergantung pada primary key,STATUS dan CITY tidak mutually independent. Primary key di sini adalah S#,P#

S# PQ P# QTY S1 P1 300 P2 200 P3 400 P4 200 P5 100 S2 P6 100 P1 300 S3 P2 400 S4 P2 200 P2 200 P4 300 P5 400 P# S# QT Y CITY STATUS

19 FIRST

S# STATUS CITY P# QTY

S1 20 LONDON P1 300 S1 20 LONDON P2 200 S1 20 LONDON P3 400 S1 20 LONDON P4 200 S1 20 LONDON P5 100 S1 20 LONDON P6 100 S2 10 PARIS P1 300 S2 10 PARIS P2 200 S3 10 PARIS P2 200 S4 20 LONDON P2 200 S4 20 LONDON P4 300 S4 20 LONDON P5 400

Gambar 3. Functional Dependent dan contoh data di relasi FIRST

Di sini masih terdapat banyak kesulitan bila ingin melaksanakan operasidata misalnya : INSERT : kita tidak dapat memasukan data pemasok yang berdomisili di suatu kota

sampai pemasok tersebut memasok paling tidak satu bahan. Di gambar 3 tidak terdapat S5 yng berdomisili di athena, karena S# Adalah merupakan primary key bersama P# dan belum perna mengirim barang, maka tidak boleh muncul, sehingga tidak boleh P# kosong (Null)

DELETE : bila misalnya kita hapus salh satu tuple, kita tidak hanya Kehilang data tentang pengirim barang, tetapi juga data bahwa satu emasok berdomisili di kota mana. Misalnya bila hapus tuple yang nilai S# = S3 dan P# = P2, maka kita kehilangan data bahwa S3 berdomisili di paris

UPDATE : suatu kota muncul berulang-ulang, sehingga apabila kita akan merubah bahwa S1 pindah dari london ke amsterdam, maka akan mendapatkan persoalan untuk mencari semua S1 dan merubah london ke amsterdam berikut statusnya yang berubah.

Pemecahan pertama adalah dengan memecah relation FIRST menjadi dua, yaitu SECOND (S#,STATUS,CITY) dan SP(S#,P#,QTY). Contohnya dapat di lihat pada gambar 4, yang menggambarkan functional dependent serta isi relation SECOND dan SP. Di sini sudah dapat di tambahkan pemasok S5 yang berdomisili di athena di relation SECOND, tetapi tidak dapat di tambahkan di SP.

S# CITY STATUS P # S # QT Y

SECOND SP S# P# QTW S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

Gambar 4. Functional Dependence dan contoh data di relation SECOND dan SP

Dari gambar pemecahan ini sudah akan mengurangi persoalan-persoalan operasi di atas, baik insert, delete maupun update. Dengan struktur ini kita sudah menghilangkan nonfull functional dependence. Sehingga kita dapat buat definisi dari tingkat normalisasi berikutnya.

SECOND NORMAL FORM (2NF)

Suatu relation sudah berada pada 2NF, jika dan hanya jika sudah berada pada 1NF dan setiap atribut yang bukan key, fully functional dependency terhadap primary key.

Reduksi relation FIRST ke SECOND dan SP adalah suatu contoh nonloss decomposition. Relation SECOND dan SP adalah hahsil dari projection dari relation FIRST, dan sebaliknya FISRST adalah hasil natural join dan relation SECOND dan SP. Tetapi struktur SECOND di sini masih juga menimbulkan persoalan karena atribut-atribut yang bukan key belum mutual independence. Ketergantungan (dependency) STATUSterhadap S# adalah functional, tetapi masih tergantung juga terhadap CITY (masih transitive dependence).

Bila setiap S# menentukan nilai CITY dan STATUS, dan kemudian CITY menentukan juga nilai STATUS transitive dependence ini juga menimbulkan persoalan terhadap operasi update antara STATUS dan CITY.

S# STATUS CITY S1 20 London S2 10 Saris S3 10 Paris S4 20 London S5 30 Athena

21 INSERT : Kita tidak dapat memasukan data bahwa suato kota mempunyai nilai STATUS tertentu, misalnya kita tidak dapat menyatakan bahwa pemasok barang dari ROMA harus mempunyai STATUS 50 sampai kita mempunyai pemasok yang berada di kota tersebu. Alasannya adalah sebelum pemasok tersebut muncul kita tidak punya nilai primary key. DELETE : Bila kita hanya menghapus tuple suatu kota tertentu, kita menghapus tidak

data mengenai pemasok tersebutt. Misalnya bila kita menghapus tuple yang berisi S5,kita kan kehilangan nilai status untuk kota Athena yang berisi 30.

UPDATE : Nilai status kota dan relation SECOND muncul berkali-kali. Bila kita ingin mengubah nilai status kota London dari 20 menjadi 3, maka kita akan di berikan persoalan baik untuk pencairan semua kota dan juga mungkin salah penulisan.

Cara memecahnya adalah dengan memecah relation SECOND menjadi dua dengan operasi projection, yaitu SC(S#,CIITY) dan SC(CITY,STATUS), seperti di dapat di gambar 5. Dalam gambar 5 terlihat bahwa kita mengeliminasi transitive dependence dari STATUS terhadap S#. sehingga kita dapat mendefinisikan tingkat normalisasi berikutnya yaitu 3NF.

Gambar 5. Functional dependence dan contoh data direlation SC dan CS

THIRD NORMAL FORM (3NF)

Suatu relation sudah berada pada 3NF bila sudah berada dalam 2NF dan setiap atribut yang bukan key tidak dependent terhadap atribut lain (tidak transitive) Kecuali primary key (nontransitively dependent terhadap primary key).

Dalam relation SC, atribut S# sebagai primary key, dan di dalam relation CS atribut CITY sebagai Primary key.

Sifat transitif : a=b, b=c, maka a=c.

S# CITY S1 London S2 Paris S3 Paris S4 London S5 Athena CITY STATUS Athena 30 London 20 Paris 10

SC

CS

BOYCE/CODD NORMAL FORM (BCNF)

Definisi 3NF diperkuat lagi dan di sederhanakan dengen definisi dari BCNF, yaitu tidak menunjuk ke 1NF, 2NF, maupun konsep full dan transitive dependence. Dalam definisi ini kita pergunakan istilah (functional) determinant sebagai atribut diaman semua atribut lainnya fully functionally deoendent terhadapnya.

Sehingga definisi dari suatuu relation itu sudah berada pada BCNF, bila setiap determinant adalah merupakan candidate key.

Suatu relation yang sudah pada 3NF belum tentu pada BCNF,tetapi relation yang sudah pada BCNF pasti pada 3NF.

Contoh : dalam gambar 5 relation STJ berada pada 3NF tetapi tidak pada BCNF karena terjadi overlap candidate key (S,J) dan (S,T)

STJ

S J T

Smith Math Prof. White Smith Physics Prof. Green Jones Math Prof. White Jones Physics Prof. Green

Gambar 6,functional dependence dancontoh data di relation STJ

FOURTH NORMAL FORM (4NF)

Dalam normalisasi ini kita mengenal adanya tipe baru dari ketergantungan (dependency) yaitu Multivalued Dependency, (MVD), yang merupakan generalisasi dari functional dependence. Atau sebaliknya. FD adalah peristiwa kusus dari MVD dimana himpunan nilai dependent berisi satu nilai saja. Sebagai contoh relation di gambar 7 ini. MTD

MTKUL DOSEN TEXT

Physics Prof. Green Basic Mechanics Physics Prof. Green Principles of Optics Physics Prof. Brown Basic Mechanics Physics Prof. Brown Principles of Optics Physics Prof. Black Basic Mechanics Physics Prof. Black Principles of Optics

Math Prof. White Modern Algebra

23 Mata kuliah physics di berikanoleh tiga dosen yaitu Prof. Green, Prof. Brown, Prof. White, sedangkan mata kuliah Math di berikan oleh satu dosen yaitu Prof. White untukmata kuliah physics mempergunakan dua text yaitu Modern Algebra dan Projective Geometry.

Relation ini berada pada BCNF karena tidak ada functional determinants lain kecuali MTKUL. Tetapi kita lihat banyak duplikasi data, sehingga struktur ini dapat kita pecah kecuali dua relation MD dan MT seperti pada gambar 8.

MTKUL TEXT

Physics BasicMechanics

Physics Principles of Optics

Math Modern Algebra

Math Projective Geometry

Gambar 8. Relation MD dan MT

Terdapat dua MVD di relation MDT yaitu : MDT.MTKUL ---- > ---- > MDT.DOSEN MDT.MTKUL ---- > ---- > MDT.TEXT

Artinya atribut MDT.DOSEN multydependent terhadap atribut MDT.MTKUL atau atribut MDT.MTKUL multidetermines atribut MDT.DOSEN. begitu juga untuk yang kedua. Sehingga definisi dari MVD adalah :

Bila dalam suatu relation R terdapat atribut A, B, dan C multi …… dependence R.A  R.B terjadi di R, bila himpunan darinilai B macth (cocok) dengan pasang nilai A danC

di R, hanya tergantungpada nilai A dan bebas terhadap nilai C. R.A ---- > ---- > R.B | R.C

Contoh :

MDT.MTKUL ---- > ---- > MDT.DOSEN | MDT.TEXT

MVD terjadi hanya bila dalam relation mempunyai paling sedikit tiga atribut. Definisi 4NF :

Suatu relation berada pada 4NF bila terjadi MVD di R yaitu A ---- > ---- > B. Kemudian semua atribut di R juga Functionally dependent pada A.

4NF lebih baik dari BCNF Yaitu setiap relation 4NF berada pada BCNF. Semua relation dapat nonloss decomposed ke dalam kumpulan 4NF relation.

MTKUL DOSEN

Physics Prof. Green

Physics Prof. Brown

Physics Prof. Black

FIFTH NORMAL FORM (5NF) atau PROJECT-JOINNORMAL FORM (PJNF)

Suatu relation dapat terus dilakukan proses nonloss-decomposition sampai semua projection berada pada 5NF. Tetapi hal inijuga ada keterbatasan yaitujoin dependency(JD), yaitu bila projection dapat di lakukan sehingga tidak ada nilai yang hilang, apabila di join kembali. JD adalah generalisasi dari MVD.

Suatu relation R barada pada 5NF bila setiap join dependency di R di buat dengan candidate key di R. Contoh : SPJ S# P# J# S1 P1 J2 S1 P2 J1 S2 P1 J1 S1 P1 J1 Join pada P# Join pada (J#,S#) SPJ awal

Gambar 9. Relation SPJ dengan operasi join dari projection-projectionnya

Beberapa persoalan update di SPJ adalah seperti contoh pada gambar 10.

S# P# J# S1 P1 J2 S1 P2 J1 S# P# S1 P1 S1 P2 S2 P1 P# J# P1 J2 P2 J1 P1 J1 J# S# J2 S1 J1 S1 J1 S2 S# P# J# S1 P1 J2 S1 P1 J1 S1 P2 J1 S2 P1 J2 S2 P1 J1

25 KESIMPULAN

Tahap-tahap roses reduksi pada normalisasi, yaitu :

1. ambil projection pada relation 1NF awal untuk mengeliminasi semua nonfull functional dependence, sehingga menghasilkan relation 2NF.

2. ambil projection pada relation 2NF untuk mengeliminasi semua transitive dependence, sehingga menghasilkan kumpulan relation 3NF.

3. ambil projection pada relation 3NF untuk mengeliminasi semua sisa functional dependence dimana determinannya bukan candidate key, sehingga menghasilkan relation BNCF.

Catatan : tahap 1 sampai dengan 3 dapat di persingkat sebagai berikut :

Ambil projection dari relation awal untuk mengeliminasi semua FD dimana determinannya bukan candidate key.

4. ambil projection pada reklation BNCF untuk mengeliminasi MVD yang bukan FD juga, sehingga menghasilkan kumpulan relation 4NF.

5. ambil projection pada relation 4NF u ntuk mengeliminasi semua JD yang bukan implementasi dasri candidate key.

Seseorang ahli (fagin) menambahkan suatu tingkat normalisasi yaitu (3.3)NF sebagai peningkatan dari 3NF, serupa dengan BNCF, bukan merupakan 4 NF. Selain itu juga menambahkan satu tingkat normalisasi lagi yaitu DK/NF (domain Key Normal Form ) yang tidak menyinggung sama sekali tentang FD, MVD maupun JD. DK/NF terjadi bila setiap relation yang terjadi memenuhi batasan-batasan (constraints) tertentu yaitu sebagai akibat dari batasan key ( key constraints ) dan batasan domain (domain constraints).

Key constraints adalah ketentuan/ batasan tentang atribut atau kombinasinya yang merupakan candidate key.

Domain constraints adalah ketentuan/batasan dimana nilai atribut tertentu berada pada himpunan nilai yang sudah di tentukan batasan-batasannya.

Di nyatakan juga bahwa DK/NF juga otomatis 5NF,sehingga juga 4NF dan (3.3)NF. DK/NF tidak harus selalu tercapai dan tidak juga terjawabnya pertanyaan secara pasti kapan hal tersebut dapat tercapai.