gambar 1.a). Biasanya atribut-atribut multivalue sering dihapus dari entitasnya, kemudian dibentuk entitas baru yang memiliki relationship dengan entitas tempat atribut multivalue dihapus.
Pada gambar 1.b, tipe entitas baru WARNA menggantikan atribut WARNA. Sekarang ada relationship banya-ke-banyak antara MOBIL dan WARNA, JENIS WARNA dipilih sebagai kunci utama (yaitu JENIS WARNA). WARNA harus juga memiliki beberapa atribut bukan kunci.
Kelompok Data Berulang. Kelompok berulang merupakan sekumpulan dua atau lebih atribut multivalue yang secara logika berrelasi. Contoh gambar 2(a) merupakan form kartu pasien yang menunjukkan data bagi pasien dan kapan pasien tersebut berkunjung ke suatu klinik. Gambar 2(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 dokter dan diperiksa untuk satu gejala tiap berkunjung)
(a) Entitas dengan Atribut Multivalue
(b) Atribut Multivalue Dihapus
Gambar 1. Penghapusan Atribut Multivalue dari Entitas
Gambar 2. Penghapusan Kelompok Berulang
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 4 menunjukkan representasi alternative dari relationship ternary yang digambarkan pada gambar 3. Pada gambar 4, tipe entitas (gerund) PENGIRIMAN menggantikan relationship Mengirim pada gambar 3. Simbol belah ketupat diikutsertakan dalam symbol persegi panjang untuk entitas sebagai pengingat bahwa entitas ini dihasilkan dari suatu relationship.
Gambar 3. Relationship Ternary
Gambar 4. Tipe Entitas Shipment (Gerund)
Perlu diingat bahwa notasi belah ketupat tidak digunakan sepanjang garis 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, relationship Mengirim dari gambar 3 tidak dapat dibagi ke dalam tiga relationship binary antara PENGIRIMAN dan PABRIK, ALAT dan GUDANG.
Pada relationship binary dengan kardinalitas banyak-ke-banyak, tidak ada masalah apakah relationship ini ditampilkan sebagai gerund atau entitas. Dengan DBMS relational, relationship banyak-ke-banyak baik sebagai gerund ataupun entitas diimplementasikan dalam cara yang sama, yaitu sebagai tabel database. Untuk relationship ternary atau berderajat yang lebih tinggi, jika salah satu tidak dapat lebih relationship bukan relationship banyak, maka relationship ini tidak dapat ditampilkan sebagai entitas.
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.
(a) Entitas Produk dengan Kelompok Berulang
(b) Entitas Produk dengan Riwayat Harga
Gambar 5. Contoh Isi Database yang Berubah dari Waktu ke Waktu
GENERALIZATION / GENERALISASI
Generalization adalah konsep tentang beberapa entitas yang merupakan subtype-subtipe dari tipe yang lebih umum, misalkan penumpang bisnis merupakan subtipe dari tipe entitas yang lebih umum yang disebut penumpang. Categorization adalah konsep kebalikannya, yaitu suatu entitas memiliki subtype-subtipe yang lebih khusus, misalkan subtype mobil adalah sedan, mobil sport, van, convertible.
Subtipe dan Supertipe atau Subklas dan Superklas
Satu tantangan utama dalam pembuatan model data adalah untuk mengenal dan menunjukkan entitas-entitas yang hamper sama satu sama lain, yaitu entitas-entitas yang menggunakan sifat atau karakteristik yang sama/umum, tetapi memiliki satu atau lebih sifat/karakteristik yang berbeda. Misalkan, suatu organisasi memiliki tiga tipe pegawai, yaitu pegawai honorer, pegawai bulanan dan konsultan. Beberapa atribut yang penting untuk tipe pegawai ini adalah :
1) Pegawai honorer : NIP,NAMA,ALAMAT,TGL MASUK,UPAH PERJAM 2) Pegawai bulanan : NIP,NAMA,ALAMAT,TGL MASUK,GAJI,KEAHLIAN 3) Konsultan : NIP,NAMA,ALAMAT,TGL MASUK,NO.KONTRAK
TARIF PERHARI
Perlu diingat bahwa semua tipe pegawai memiliki beberapa atribut yang umum, yaitu NIP,NAMA,ALAMAT dan TGL MASUK. Tiap tipe pegawai juga memiliki satu atau lebih atribut unik yang membedakan dari tipe yang lain (missal UPAH PERJAM adalah unik untuk pegawai honorer).Jika model data dikembangkan dalam situasi sepeti ini, maka ada tiga pilihan yang harus dipertimbangkan, yaitu :
pegawai dan pemakai harus hati-hati untuk memilih tipe entitas yang benar bila menggunakan sistem ini.
Definisikan supertipe yang disebut PEGAWAI, dengan subtIpe-subtipenya PEGAWAI HONORER, PEGAWAI BULANAN dan KOSULTAN. Pendekatan ini memanfaatkan karakteristik umum dari semua pegawai, juga mengenali karakteristik yang berbeda dari tiap tipe (lihat gambar 6.)
Gambar 6. Supertipe Pegawai dengan Subtipenya
Gambar 6 menunjukkan representasi supertipe PEGAWAI beserta subtipenya dengan menggunakan notasi ERD. Supertipe adalah tipe entitas umum (seperti PEGAWAI) yang dibagi ke dalam beberapa subtype. Subtipe adalah subset dari supertipe yang menggunakan atribut-atribut umum atau relationship yang berbeda dari subset-subset yang lain. Subtipe-subtipe suatu entitas bertindak/bekerja dalam cara yang sama seperti tipe entitas biasa. Misalkan subtype-subtipe suatu entitas memiliki atribut-atribut dan mungkin memiliki relationship dengan entitas lainya.
Pada gambar 6, atribut-atribut umum untuk semua pegawai diletakkan pada tipe entitas PEGAWAI. Kunci utama PEGAWAI, sama seperti untuk ketiga subtipenya adalah NIP. Atribut-atribut khusus untuk tiap subtype diletakkan hanya pada masing-masing subtype yang bersangkutan.
Relationship antara subtype dan supertipe disebut relationship ISA. Persegi panjang dengan sudut-sudutnya melingkar digunakan untuk menunjukkan relationship ISA. Relationship ini dibaca dari subtipe ke supertipe, misalkan ‘PEGAWAI HONORER ISA PEGAWAI’.
Seperti yang ditunjukkan pada gambar 6, kardinalitas relationship dari subtype ke supertipe adalah manadatory one. Kardinalitas disebut mandatory one karena instance suatu subtype selalu merupakan instance dari supertipe (pegawai bulanan selalu merupakan seorang pegawai).
Sebaliknya, relationship dari supertipe ke subtype adalah optional nol atau satu (seorang pegawai mungkin atau mungkin bukan seorang pegawai bulanan). Karena reklationship kardinalitas ini selalu sama dalam relationship ISA, notasi kardinalitas dihapuskan pada diagram-diagram berikutnya.\ Pemakaian atau tidaknya relationship subtype merupakan keputusan yang dibuat oleh pembuat model data dalm tiap situasi. Subtipe-subtipe ditunjukkan untuk tiap (atau kedua) keadaan berikut :
1) Atribut-atribut yang berbeda digunakan untuk menerangkan tiap subtype entitas, seperti dalam contoh PEGAWAI.
Gambar 7 merupakan contoh dari pemakaian relationship subtype yang melukiskan kedua situasi ini. Tipe entitas PASIEN rumah sakit terdiri dari dua subtype, yaitu PASIEN RAWAT JALAN dan PASIEN Rawat inap (kunci utamanya adalah NO.PASIEN). Semua pasien (kedua subtype) memiliki atribut TGL.DAFTAR, dan tiap subtype entitas ditunjuk DOKTER yang akan bertanggung jawab terhadapnya sampai pasien ini sembuh. Pasien rawat jalan memiliki atribut TGL.KEMBALI, sementara pasien rawat inap memiliki TGL.KELUAR. Hanya pasien rawat inap ditentukan TEMPAT TIDUR-nya (dan tiap tempat tidur mingkin atau mungkin tidak ditempati oleh seorang pasien).
Gambar 7. Relationship ISA dalam Rumah Sakit
Subtipe Exclusive
Pada tiap contoh relationship ISA yang telah dibahas diatas (gbr. 6 dan gbr 7) ada garis melingkar di bawah entitas supertipe yang melewati garis-garis relationship ISA menunjukkan relationship exclusive.
Relationship exclusive berarti bahwa subtype-subtipe adalah mutually exclusive dan sebagai hasilnya tiap instance supertipe harus merupakan satu anggota dari tepat satu subtype. Misalkan pada gbr 6 tiap pegawai harus merupakan pegawai honorer, pegawai bulanan atau konsultan.
Subtipe Exhaustive. Pada gbr 6, subtype adalah exhaustive; yaitu tidak ada subtype tanbahan untuk ketiga subtype yang digambarkan pada gambar ini. Sehingga, setiap instance PEGAWAI harus merupakan anggota tepat satu subtype. Begitu pula pada gambar 7, tiap PASIEN RAWAT INAP, karena tidak ada tipe-tipe lainnya.
Situasi subtipe exhaustive mungkin berakhir bila situasi bisnis yang sedang dibuat model atau dikembangkan sudah terstruktur dengan baik dan dikenal oleh pembuat model data.
Subtipe Nonexhaustive. Bila subtype-subtipe adalah nonexhaustive, beberapa (tetapi tidak semua) subtype telah didefinidikan untuk satu supertipe. Misalkan pada gambar 8(a) tiga subtype (MOBIL, TRUK, dan MOTOR)telah didefinisikan untuk tipe entitas KENDARAAN. Untuk menunjukkan bahwa ada subtipe yang tidak terdefinisi, suatu persegi panjang telah dibiarkan kosong pada ERD yang digambarkan pada gambar 8. Bersama dengan garis melingkar, notasi ini menunjukkan bahwa tiap instance KENDARAAN adalah salah satu dalam subklas yang tidak terdefinisikan atau jika tidak tepat dalam satu subklas yang sudah terdefinisi. Dengan kata lain, suatu kendaraan merupakan salah satu dari mobil, truk, motor atau bukan dari ketiganya.
instance dari supertipe mungkin dimiliki oleh lebih dari satu subtype secara simultan. Contoh dari situasi ini digambarkan pada gambar 8(b). Subtipe – subtipe yang terdefinisi dari KENDARAAN adalah MOBIL, TRUK, KENDARAAN BERODA EMPAT, dan SEPEDA (kotak kosong diikutsertakan untuk menunjukkan subtipe-subtipe yang tidak terdefinisi).
Pada contoh ini suatu instance KENDARAAN BERODA EMPAT). Dalam pembentukan model ER, penghapusan garis melingkar menunjukkan kemungkinan dari suatu instance dimiliki oleh lebih dari satu subtype. Subtipe mungkin merupakan subtype exhaustive atau nonexhaustive (untuk exhaustive kotak kosong akan dihapuskan dari ERD).
Subtipe nonexclusive mungkin berakhir bila situasi bisnis tidak dimengerti dengan baik dan cukup rumit. Metode alternative dari pembentukan subtype-subtipe dan relationship mungkin tersedia untuk menghilangkan overlap diantara subtype.
Pegawai NIP
Nama Alamat
a
TglMasu k
Pegawai Honorer
