ERD & Normalisasi Lanjutan Pertemuan Minggu Ke-7
Kompetensi Khusus Mahasiswa mampu menganalisis kekurangan pada ERD awal dan menyempurnakannya menjadi ERD akhir (C4)
Extended Entity Relationship Model Kadang mengacu sebagai enhanced entity relationship model, adalah hasil dari penambahan bentuk semantik ke model entity relationship (ER) asli. Diagram yang menggunakan EERM dinamakan EER Diagram (EERD).
Entity Supertype & Subtype Karena karyawan memiliki beragam keahlian & kualifikasi khusus, maka pemodel data harus menemukan berbagai cara untuk mengelompokkan karyawan berdasarkan karakteristiknya. Pengelompokkan karyawan menjadi beberapa tipe memberikan 2 keuntungan penting: Menghindari nilai NULL dalam atribut ketika beberapa karyawan memiliki karakteristik yang tidak dimiliki oleh karyawan lain. Tipe karyawan tertentu dapat berpartisipasi dalam hubungan yang unik untuk tipe karyawan tersebut.
Entitas supertype adalah tipe entitas umum yang terhubung ke satu atau lebih entitas subtype. Entitas supertype berisi karakteristik umum, & entitas subtype berisi karakteristik uniknya masing-masing. Berikut adalah 2 kriteria yang membantu desainer menentukan kapan menggunakan subtype & supertype: Harus ada jenis atau tipe entitas yang berbeda & teridentifikasi dalam lingkungan user. Tiap jenis atau tipe instance yang berbeda harus memiliki satu atau lebih atribut yang unik untuk jenis atau tipe instance tersebut.
Misalnya dalam perusahaan penerbangan terdapat karyawan yang berprofesi sebagai pilot, mekanik, sekretaris, akuntan, dsb. Pilot memiliki karakteristik yang sama dengan karyawan lainnya seperti nama belakang & tgl mulai bekerja. Selain itu, banyak karakteristik pilot yang tidak dimiliki oleh karyawan lain, seperti jam terbang, pelatihan, dsb. Jika semua data karyawan dicampur dalam satu tabel maka banyak atribut yang bernilai NULL bagi karyawan yang bukan pilot. Dari kriteria di atas, pilot sesuai dengan 2 kriteria tersebut sehingga PILOT dapat menjadi subtype dari EMPLOYEE. Demikian juga MEKANIK dan AKUNTAN dapat menjadi subtype karena merupakan jenis karyawan & memiliki atribut unik. KASIR tidak dapat menjadi subtype karena tidak memenuhi salah satu kriteria yaitu tidak memiliki atribut unik.
NULL pada Atribut Unik
Spesialisasi Entitas supertype & subtype diatur dalam hirarki spesialisasi, yang menggambarkan pengaturan entitas supertype tingkat tinggi (entitas induk) & entitas subtype tingkat rendah (entitas anak). Hubungan yang digambarkan dalam hirarki spesialisasi kadang dideskripsikan sebagai hubungan “is a”. Dalam hirarki spesialisasi, subtype hanya muncul dalam konteks supertype, & tiap subtype hanya dapat memiliki 1 supertype yang berhubungan langsung dengannya. Hirarki spesialisasi dapat memiliki banyak tingkat hubungan supertype/ subtype – yaitu supertype memiliki banyak subtype, dan 1 subtype adalah supertype dari subtype lain di bawahnya.
Hirarki spesialisasi memiliki arti sbb: Mendukung atribut inheritance. Mendefinisikan atribut supertype khusus yang dikenal sebagai subtype discriminator. Mendefinisikan disjoint/ overlapping constraint & complete/ partial constraint.
Hirarki Spesialisasi
Inheritance Properti inheritance memungkinkan suatu entitas subtype mewarisi atribut dan hubungan dari supertype. Satu karakteristik inherintance yang penting adalah semua entitas subtype mewarisi atribut PK dari supertypenya. Entitas subtype mewarisi semua hubungan dimana entitas supertype berpartisipasi. Supertype & subtype memiliki hubungan 1:1.
Hubungan Supertype-Subtype EMPLOYEE-PILOT
Subtype Discriminator Adalah atribut dalam entitas supertype yang menentukan subtype mana yang berhubungan dengan kemunculan supertype tersebut. Subtype discriminator & nilai untuk tiap subtype ditunjukkan dalam diagram ER. Tetapi tidak semua tool pemodelan ER melakukan hal itu. Misalnya MS Visio menunjukkan subtype discriminator tetapi tidak nilainya. Nilainya dapat ditambahkan secara manual ke sisi garis penghubungnya menggunakan Visio text tool. Kondisi perbandingan untuk atribut subtype discriminator secara default adalah sama dengan (=). Akan tetapi, dalam beberapa situasi subtype discriminator memiliki kondisi perbandingan lain seperti lebih besar (>), lebih kecil (<).
Disjoint & Overlapping Constraint Entitas supertype dapat memiliki entitas subtype disjoint atau overlapping. Subtype disjoint/ nonoverlapping adalah subtype yang mengandung subset unik dari entitas supertype; dengan kata lain, tiap instance entitas dari supertype dapat muncul hanya dalam 1 subtype. Subtype overlapping adalah subtype yang mengandung subtype tidak unik dari entitas supertype; artinya tiap instance entitas dari supertype dapat muncul di lebih dari 1 subtype.
Hirarki Spesialisasi dengan Subtype Overlapping
Atribut Discriminator dengan Subtype Overlapping DISCRIMINATOR ATTRIBUTES COMMENT Professor Administrator Y N The Employee is a member of the Professor subtype The Employee is a member of the Administrator subtype The Employee is both a Professor & an Administrator
Completeness Constraint Menentukan apakah kemunculan entitas supertype harus menjadi anggota dari paling sedikit 1 subtype. Terdiri dari parsial & total. Partial completeness berarti tidak setiap kemunculan supertype adalah anggota dari subtype; beberapa kemunculan supertype tidak menjadi anggota dari subtype apapun. Total completeness berarti setiap kemunculan supertype harus menjadi anggota dari paling sedikit 1 subtype. Dalam Visio, garis horizontal tunggal di bawah lingkaran menandakan partial completeness constraint; garis horizontal ganda di bawah lingkaran menggambarkan total completeness constraint.
Skenario Constraint Hirarki Spesialisasi
Spesialisasi & Generalisasi Spesialisasi adalah proses top-down dari mengidentifikasi tingkat yang lebih rendah, entitas subtype yang lebih spesifik dari entitas supertype di tingkat yang lebih tinggi. Spesialisasi berdasarkan pada pengelompokkan karakteristik & hubungan yang unik dari subtype. Generalisasi adalah proses bottom-up dari mengidentifikasi tingkat yang lebih tinggi, entitas supertype yang lebih umum dari entitas subtype di tingkat yang lebih rendah. Generalisasi berdasarkan pada pengelompokkan karakteristik & hubungan yang umum dari subtype.
Entity Clustering Digunakan untuk meminimalisasi jumlah entitas dalam ERD. Entity cluster adalah jenis entitas “virtual” yang digunakan untuk mewakili beberapa entitas & hubungan dalam ERD. Entity cluster dibuat dengan menggabungkan beberapa entitas yang saling berhubungan menjadi objek entitas tunggal, abstrak. Ketika menggunakan entity cluster, atribut tidak perlu ditampilkan.
ERD Tiny College menggunakan entity cluster
Integritas Entitas : Memilih PK Karakteristik utama dari entitas adalah PK yang mengidentifikasi tiap instance entitas & berfungsi untuk menjamin integritas entitas. Oleh karena itu, pemilihan PK yang benar berdampak langsung pada efisiensi & efektivitas dari implementasi database. Natural Key & Primary Key Natural key atau natural identifier adalah pengenal yang diterima untuk mengidentifikasi objek di dunia nyata. Familiar untuk end user & membentuk sebagian dari kosakata bisnis sehari-hari. Natural key biasanya digunakan sebagai PK dari entitas.
Panduan Pemilihan PK Memahami fungsi PK yaitu untuk menjamin integritas entitas, bukan untuk mendeskripsikan entitas. PK & FK digunakan untuk mengimplementasi hubungan antar entitas. Berikut karakteristik PK yang diinginkan: Memiliki nilai unik & tidak boleh NULL. Tidak boleh mengandung arti semantik. Harus permanen & tidak berubah. Memiliki jumlah atribut seminimal mungkin. Memiliki tipe data numerik. Tidak boleh menggunakan atribut yang mungkin mengandung resiko keamanan atau pelanggaran.
Kapan harus menggunakan Composite PK? Walaupun PK seharusnya menggunakan jumlah atribut seminimal mungkin, akan tetapi hal itu tidak berarti composite PK tidak diperbolehkan dalam model. Composite PK berguna dalam 2 kasus berikut: Sebagai pengenal entitas komposit dimana tiap kombinasi PK diperbolehkan hanya muncul sekali dalam hubungan M:N. Sebagai pengenal entitas lemah dimana entitas lemah memiliki hubungan kuat dengan entitas induk.
Hubungan M:N antara STUDENT & CLASS
Kapan harus menggunakan PK Pengganti? Dalam beberapa kasus, natural key yang ada tidak sesuai menjadi PK sehingga perlu membuat PK Pengganti. PK Pengganti adalah PK yang dibuat oleh desainer database untuk menyederhanakan identifikasi instance entitas. PK Pengganti tidak berarti dalam lingkungan user & hanya muncul untuk membedakan 1 instance dengan yang lain. Keuntungannya adalah karena tidak memiliki nilai intrinsik, maka nilainya dihasilkan oleh DBMS sehingga dapat dipastikan selalu unik .
Kasus Desain ERD Implementasi hubungan 1:1 Aturan dasar yang sederhana adalah meletakkan PK dari sisi yang satu (entitas induk) ke sisi yang banyak (entitas dependen) sebagai FK. Dimana harus menempatkan FK ketika hubungannya 1:1? Berikut pilihannya: Tempatkan FK di kedua entitas. Solusi ini tidak direkomendasikan karena menduplikasi pekerjaan & dapat bertentangan dengan hubungan lain yang ada. Tempatkan FK di salah satu entitas. PK dari salah satu entitas muncul sebagai FK dalam entitas lainnya. Pertanyaannya: PK mana yang seharusnya digunakan sebagai FK? Jawabannya ada di tabel berikut.
Pemilihan FK dalam Hubungan 1:1 CASE ER RELATIONSHIP CONSTRAINTS ACTION 1 One side is mandatory & the other side is optional Place the PK of the entity on the mandatory side in the entity on the optional side as a FK, & make the FK mandatory. 2 Both sides are optional Select the FK that causes the fewest nulls, or place the FK in the entity in which the (relationship) role is played. 3 Both sides are mandatory See case 2, or consider revising your model to ensure that the two entities do not belong together in a single entity.
Hubungan 1:1 antara DEPARTMENT & EMPLOYEE
Memelihara sejarah dari data time-variant Normalnya, perubahan data dilakukan dengan mengubah nilai atribut yang ada dengan nilai baru tanpa melihat nilai sebelumnya. Akan tetapi dalam beberapa situasi, sejarah dari nilai atribut harus dipertahankan. Data time-variant mengacu pada data yang nilainya berubah seiring waktu & sejarah perubahan datanya disimpan. Untuk memodelkan data time-variant, dibutuhkan 1 entitas baru dalam hubungan 1:M dengan entitas lain. Entitas baru ini akan berisi nilai baru, tgl perubahan, & atribut lain yang berhubungan dengan kejadian yang dimodelkan.
Memelihara Histori Gaji & Manajer
Fan Traps Hubungan redundan Design trap muncul ketika hubungan tidak diidentifikasi dengan baik atau lengkap & ditampilkan dalam cara yang tidak konsisten dengan dunia nyata. Fan trap muncul ketika terdapat 1 entitas dalam 2 hubungan 1:M dengan entitas lain, sehingga menghasilkan hubungan antar entitas lain yang tidak diekspresikan dalam model. Hubungan redundan Hubungan redundan muncul ketika terdapat beberapa jalur hubungan antar entitas yang berhubungan. Beberapa desain menggunakan hubungan redundan sebagai cara untuk menyederhanakan desain.
ERD Salah: Adanya Masalah Fan Trap
ERD Benar: Eliminasi Masalah Fan Trap
Hubungan Redundan
Prosedur Normalisasi dalam Desain Database ERD dibuat melalui melalui proses iteratif, yang diawali dengan identifikasi entitas, atribut, & hubungannya. Kemudian hasilnya digunakan untuk mengidentifikasi entitas & atribut tambahan. ERD menyediakan gambar besar, atau tampilan makro dari kebutuhan &operasi data perusahaan. Normalisasi fokus pada karakteristik dari entitas tertentu; yaitu mewakili pandangan mikro dari entitas dalam ERD. Memodifikasi ERD awal untuk menampung entitas tambahan yang ditemukan.
Review Materi Mahasiswa mengerjakan tugas yang ada di portal.