This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Relationship adalah kesesuaian antar beberapa entity Contoh:
Hayes depositor A-102customer entity relationship set account entity
Relationship set adalah hubungan matematika antara entity n>2, tiap bagiannya diambil dari satuan entity {(e1, e2, … en) | e1 E1, e2 E2, …, en En} dimana (e1, e2, …, en) adalah relationship
Tingkatan Tingkatan Relationship SetRelationship Set
Mengacu pada jumlah entity sets yang terlibat dalam relationship set.
Relationship sets yang melibatkan dua entity sets adalah binary (atau tingkat dua).
Umumnya, hampir semua relationship sets dalam sistem database adalah binary.
Relationship sets mungkin melibatkan lebih dari dua entity sets.
Contoh : misal seorang pegawai bank bekerja (bertanggung jawab) dalam beberapa cabang, dengan tugas yang berlainan dalam setiap cabang yang berlainan pula. Maka disini terdapat relationship set ternary antara entity sets pegawai (employee), tugas (job) dan cabang (branch)
Relationships antara lebih dari dua entity sets sangat jarang. Kebanyakan hubungan adalah binary (akan dibahas lebih jauh nanti)
Kami mengungkapkan keterbatasan cardinalitas dengan menggambarkan baik itu batas yang ditujukan (), menandakan “one,” atau garis yang tak ditujukan (—), menandakan “many,” di antara relationship set dan set entitas.
E.g.: Seperti : Relationship satu-ke-satu : seorang pelanggan dihubungkan dengan tak lebih dari satu pinjaman via
hubungan borrower pinjaman dihubungkan dengan tak lebih dari satu orang pelanggan via
One-To-Many Relationship (Hubungan satu ke banyakOne-To-Many Relationship (Hubungan satu ke banyak))
Pada satu-ke-banyak hubungan pinjaman dihubungkan dengan tak lebih dari satu orang pelanggan via peminjam, seorang pelanggan dihubungkan dengan beberapa (termasuk 0) yang meminjami via borrower
Di dalam many-to-one relationship seorang pelanggan dihubungkan dengan beberapa (mungkin 0) pinjaman via peminjam, pinjaman dihubungkan dengan beberapa (mungkin 0) pelanggan via peminjam
Peran serta Set Entitas padaPeran serta Set Entitas pada Relationship Set Relationship Set
Total participation (Total partisipasi): (ditunjukkan dengan garis dobel): setiap entitas di set entitas mengambil bagian paling sedikit satu relationship pada relationship set
Misal. Partisipasi pinjaman pada peminjam adalah keseluruhan
setiap pinjaman harus mempunyai seorang pelanggan yang menghubungkan ke itu (pinjaman) via peminjam
Partial participation (Partial partisipasi): beberapa entitas mungkin tidak mengambil bagian dalam relationship (hubungan) yang mana pun pada relationship set..
misal partisipasi pelanggan pada peminjam adalah parsial
Key untuk Relationship Set Key untuk Relationship Set
Kombinasi primary keys (kunci pokok) dari set entitas yang berpartisipasi membentuk super key (kunci super) pada relationship set (set hubungan).
customer-id, account-number (pelanggan-id, rekening-jumlah) adalah super key (kunci pokok) dari depositor
CATATAN: ini berarti sepasang set-set entitas bisa mempunyai tak lebih dari satu relationship (hubungan) pada suatu relationship set tertentu.
Misal. jika kami menginginkan untuk melacak semua access-dates ke masing-masing rekening oleh masing-masing pelanggan, kita tidak bisa mengambil relationship (hubungan) untuk masing-masing akses. Tapi kita tetap bisa menggunakan sifat multivalued
Harus mempertimbangkan pemetaan cardinalitas dari relationship set di saat mengambil keputusan apa calon kuncinya (candidate key)
Tetap perlu mempertimbangkan ilmu semantik dari set hubungan (relationship set) dalam memilih primary key (kunci pokok) bila timbul masalah adanya lebih dari satu candidate key (calon kunci)
Mengubah Hubungan Non Biner ke Bentuk BinerMengubah Hubungan Non Biner ke Bentuk Biner
Secara umum, hubungan non biner mana pun bisa dilambangkan memakai hubungan biner dengan membuat set entitas buatan. Mengganti R di antara set-set entitas A, B dan C di samping set entitas
E, dan tiga set hubungan (relationship sets ):
1. RA, menghubungkan E dan A 2.RB, menghubungkan E dan B 3. RC, menghubungkan E dan C
Menciptakan atribut pengenal khusus bagi E Menambah atribut mana pun dari R ke E Untuk setiap hubungan (ai, bi, ci) di R, menciptakan
1. Entitas baru ei di set entitas E 2. menambah (ei, ai) ke RA
3. menambah (ei, bi) ke RB 4. menambah (ei, ci) ke RC
Mengubah Hubungan Non Biner (lanjutan)Mengubah Hubungan Non Biner (lanjutan)
Juga perlu menterjemahkan keterbatasan
Menterjemahkan semua keterbatasan bisa jadi tidak mungkin
Mungkin ada permisalan di skema terjemahan yang tidak dapat merespon segala kejadian di R yang mana pun
Latihan : menambahkan keterbatasan ke hubungan RA, RB dan RC untuk menjamin bahwa entitas yang baru diciptakan berhubungan kepada persis satu entitas pada masing-masing set-set entitas A, B dan C
Kami bisa menghindari terciptanya pengenalan atribut dengan membuatkan E suatu set entitas yang lemah (akan digambarkan tak lama lagi) yang dapat dikenali dari tiga set hubungan
Menggunakan set-set entitas vs. Atribut Pilihan utamanya tergantung pada struktur perusahaan yang dimodelkan, dan pada ilmu semantik yang dihubungkan dengan sifat dalam pertanyaan.
Menggunakan set-set entitas vs. relationship sets. Pedoman yang mungkin adalah mengarahkan suatu set hubungan untuk menggambarkan sebuah tindakan yang terjadi antar entitas
Binary versus n-ary relationship sets Walaupun mungkin untuk mengganti set hubungan (relationship set) nonbiner manapun (n-ary, untuk n > 2) dengan beberapa set hubungan biner yang jelas, set hubungan n-ary menunjukkan lebih jelas bahwa beberapa entitas mengambil bagian pada satu hubungan.
Penempatan atribut hubungan (relationship attributes)
Set entitas yang tidak mempunyai kunci pokok (primary key) disebut sebagai set entitas lemah (weak entity set.).
Keberadaan set entitas lemah tergantung pada keberadaan set entitas pengenal (identifying entity set) harus berhubungan dengan set entitas pengenal melalui jumlah
total, satu-ke-banyak set hubungan (one to many relationship) dari set pengenal ke set entitas lemah
Hubungan pengenal (Identifying relationship ) digambarkan dengan memakai dobel diamond
Discriminator (atau kunci parsial) pada set entitas lemah adalah set dari sifat (atribut) yang membedakan antara semua entitas dari set entitas lemah.
Kunci pokok (primary key ) dari set entitas lemah terbentuk oleh kunci pokok (primary key ) dari set entitas kuat yang mana set entitas lemah keberadaannya tergantung, ditambah discriminator dari set entitas lemah.
Catatan: primary key dari set entitas kuat tidak disimpan secara gamblang/jelas dengan set entitas lemah, karena hal ini tersirat pada relationship (hubungan) pengenal.
Jika loan-number disimpan secara jelas/gamblang, payment bisa dibuat entitas kuat, tetapi kemudian hubungan (relationship ) antara payment dan loan akan disalin oleh hubungan (relationship) tersirat yang ditegaskan oleh sifat (attribut) loan-number biasa ke payment dan loan
Proses desain atas-bawah (Top-down); kami mengarahkan sub-pengelompokan dalam set entitas yang khas dari entitas lain di dalam set.
Sub-pengelompokan ini menjadi set-set entitas dengan level lebih rendah yang mempunyai sifat/atribut atau mengambil bagian dalam hubungan/relationship yang tidak diterapkan dalam set entitas dengan level lebih tinggi.
Digambarkan dengan komponen segitiga (triangle) berlabel ISA (misal. Customer “adalah seseorang/ person”).
Attribute inheritance (Attribut warisan) – set entitas dengan level lebih rendah mewarisi semua sifat / atribut dan partisipasi hubungan/ relationship dari set entitas dengan level lebih tinggi yang mana hal ini terhubung.
Proses desain dasar-ke atas (bottom-up) – menggabungkan sejumlah set entitas yang membagi fitur yang sama menjadi set entitas dengan level lebih tinggi.
Spesialisasi dan generalisasi adalah kebalikan sederhana satu dengan yang lain; mereka diwakilkan dalam diagram E-R dengan cara yang sama.
Syarat-syarat spesialisasi dan generalisasi dapat dipakai bergantian
Spesialisasi dan Generalisasi (lanjutan)Spesialisasi dan Generalisasi (lanjutan)
Bisa mempunyai spesialisasi berlipat ganda pada set entitas berdasarkan fitur yang berbeda.
Misal. Pegawai-permanen (permanent-employee) vs. Pegawai-sementara (temporary-employee), atau bisa juga pegawai kantor vs. sekretaris vs. teller (officer vs. secretary vs. teller ).
Tiap pegawai khusus (particular employee ) akan menjadi seorang anggota dari satu pegawai-permanen (permanent-employee)
atau pegawai-sementara (temporary-employee), dan juga seorang anggota dari satu pegawai kantor (officer),
sekretaris(secretary), atau teller
Hubungan/relationship ISA juga merujuk kepada hubungan superkelas - subkelas (superclass - subclass )
Keterbatasan desain pada Keterbatasan desain pada Spesialisasi/GeneralisasiSpesialisasi/Generalisasi
Keterbatasan yang mana entitas bisa menjadi anggota dari set entitas dengan level lebih rendah yang diberikan. condition-defined (kondisi-yang ditentukan)
Misal. semua pelanggan di atas 65 tahun adalah anggota dari set entitas warganegara-senior (senior-citizen); warganegara-senior ISA orang (senior-citizen ISA person).
user-defined (pemakai-yang ditentukan) Keterbatasan pada entitas ataupun bukan bisa masuk pada lebih
dari satu set entitas dengan level lebih rendah dalam satu generalisasi. Disjoint
suatu entitas bisa hanya masuk dalam satu set entitas dengan level lebih rendah
dicatat pada diagram E-R dengan tulisan disjoint di samping segitiga ISA
Overlapping (penumpukan) suatu entitas bisa masuk pada lebih dari satu set entitas dengan
Keterbatasan Desain pada Keterbatasan Desain pada Spesialisasi/Generalisasi (lanjutan) Spesialisasi/Generalisasi (lanjutan)
Completeness constraint (Keterbatasan sempurna) -menetapkan apakah entitas pada set entitas level lebih tinggi harus termasuk dalam paling sedikit salah satu dari set-set entitas level lebih rendah dalam generalisasi. total :entitas harus masuk dalam salah satu dari set entitas level
lebih rendah
partial: entitas tidak perlu termasuk dalam salah satu set entitas level lebih rendah
Set hubungan works-on dan manages mewakili penumpukan information Tiap hubungan manages bersesuaian dengan hubungan works-on Tetapi, beberapa hubungan works-on mungkin tidak bersesuaian dengan
hubungan manages yang manapun Jadi kami tidak dapat membuang hubungan works-on
Menghapus kelebihan ini melalui penjumlahan (agregation) Memperlakukan hubungan sebagai entitas abstrak membolehkan hubungan antar hubungan mengabstraksi hubungan ke dalam entitas baru
Tanpa memperkenalkan kelebihan (redundancy), diagram berikut mewakili: seorang pegawai yang mengerjakan pekerjaan khusus di cabang khusus seorang pegawai (employee), cabang (branch), pekerjaan kombinasi (job
Penggunaan sifat atau set entitas untuk melambangkan obyek.
Konsep dunia nyata sebenarnya diungkapkan paling baik dengan set entitas atau set hubungan.
Penggunaan hubungan ternary vs pasangan hubungan biner.
Penggunaan set entitas kuat atau lemah.
Penggunaan spesialisasi/generalisasi – menyumbang ke modularity (modularitas) pada bentuk.
Penggunaan penjumlahan/agregation – bisa menganggap set entitas jumlah/agregate sebagai satu kesatuan tanpa memperhatikan detail dari struktur internalnya.
UML Class Diagrams (lanjutan)UML Class Diagrams (lanjutan)
Set-set entitas diperlihatkan sebagai kotak-kotak, dan sifat diperlihatkan dalam kotak, atau bisa juga seperti elipsis terpisah pada E-R diagram.
Set-set hubungan biner dilambangkan di UML hanya dengan memberi garis batas yang menyambung set-set entitas. Nama set hubungan ditulis berdampingan dengan garis.
Peran yang dimainkan oleh set entitas pada set hubungan juga dapat ditetapkan dengan menulis nama peran di atas garis, berdampingan dengan set entitas.
Nama set hubungan secara alternatif mungkin ditulis di sebuah kotak, beserta dengan sifat dari set hubungan, dan kotak disambungkan, memakai garis bertitik-titik, ke garis yang menggambarkan set hubungan.
Hubungan nonbiner secara langsung tidak bisa dilambangkan di UML -- mereka mesti dibalik ke hubungan biner .
UML Class Diagrams (lanjutan) UML Class Diagrams (lanjutan)
Keterbatasan cardinalitas ditetapkan dalam bentuk l…h, di mana l menunjukkan jumlah minimum dan h jumlah maksimum hubungan dimana suatu entitas bisa mengambil bagian.
Perhatikan : posisi dari keterbatasan adalah persis kebalikan dari posisi keterbatasan dalam E-R diagram.
Keterbatasan 0.. * pada sisi E2 dan 0.. 1 pada sisi E1 berarti bahwa tiap entitas E2 tersebut dapat mengambil bagian paling banyak dalam satu hubungan, sedangkan masing-masing entitas E1 bisa mengambil bagian dalam banyak hubungan; dengan kata lain, hubungannya adalah banyak ke satu dari E2 ke E1.
Nilai tunggal, seperti 1 atau * mungkin ditulis di pinggir; nilai tunggal 1 di pinggir diperlakukan sama dengan 1.. 1, sedangkan * adalah sama dengan 0.. *.
Penurunan Skema E-R ke dalam TabelPenurunan Skema E-R ke dalam Tabel
Primary keys (Kunci pokok) memungkinkan set-set entitas dan set-set hubungan diungkapkan secara seragam sebagai tabel-tabel yang melambangkan isi database.
Database yang menyesuaikan diri ke diagram E-R bisa diwakili oleh sekumpulan tabel.
Untuk tiap set entitas dan set hubungan terdapat sebuah tabel unik yang menandakan nama dari set entitas atau set hubungan yang berhubungan.
Tiap tabel mempunyai sejumlah kolom (umumnya berhubungan dengan sifat), yang mempunyai nama unik.
Membalik diagram E-R menjadi bentuk tabel adalah dasar untuk memperoleh pola database relasional dari E-R diagram.
Atribut Kombinasi (Atribut Kombinasi (Composite)Composite) dan Nilai dan Nilai Ganda (Ganda (Multivalued)Multivalued)
Atribut kombinasi dikeluarkan dengan membuat atribut terpisah untuk masing-masing komponen atribut misal. Memberikan set entitas customer dengan atribut kombinasi nama
dengan komponen atribut first-name dan last-name, tabel yang berhubungan dengan set entitas mempunyai dua atribut name.first-name and name.last-name
Atribut nilai ganda M dari entitas E diwakili oleh tabel EM yang terpisah Table EM mempunyai atribut yang cocok dengan primary key E dan
atribut yang cocok dengan atribut nilai ganda M misal. Atribut nilai ganda dependent-names dari pegawai diwakili oleh
tabel employee-dependent-names( employee-id, dname) Masing-masing nilai dari atribut nilai ganda dipetakan ke dalam baris
terpisah dari tabel EM misal., entitas pegawai dengan primary key John dan
tanggungan/dependents Johnson dan Johndotir memetakan ke dua jajaran/baris: : (John, Johnson) dan (John, Johndotir)
Merepresentasikan Set Hubungan Merepresentasikan Set Hubungan ((Relationship SetsRelationship Sets)) sebagai Tabel sebagai Tabel
Set hubungan banyak-ke-banyak (many to many) diwakilkan sebagai tabel dengan kolom-kolom untuk primary key - primary key dari kedua set entitas yang mengambil bagian, dan setiap sifat deskriptif dari set hubungan.
Set-set hubungan banyak-ke-satu (many to one) dan satu-ke-banyak (one to many) yang total di sisi many bisa diwakilkan dengan menambahkan atribut ekstra ke sisi banyak (many), berisi primary key pada sisi one.
Misal. : Daripada membuat tabel untuk hubungan account-branch, lebih baik menambahkan atribut branch ke set entitas account
Redundancy of Tables (Cont.)Redundancy of Tables (Cont.)
For one-to-one relationship sets, either side can be chosen to act as the “many” side That is, extra attribute can be added to either of the tables
corresponding to the two entity sets
If participation is partial on the many side, replacing a table by an extra attribute in the relation corresponding to the “many” side could result in null values
The table corresponding to a relationship set linking a weak entity set to its identifying strong entity set is redundant. E.g. The payment table already contains the information that would
appear in the loan-payment table (i.e., the columns loan-number and payment-number).
Relations Corresponding to Relations Corresponding to Aggregation (Cont.)Aggregation (Cont.)
E.g. to represent aggregation manages between relationship works-on and entity set manager, create a table manages(employee-id, branch-name, title, manager-name)
Table works-on is redundant provided we are willing to store null values for attribute manager-name in table manages
If the existence of entity x depends on the existence of entity y, then x is said to be existence dependent on y. y is a dominant entity (in example below, loan)
x is a subordinate entity (in example below, payment)
loan-payment paymentloan
If a loan entity is deleted, then all its associated payment entities must be deleted also.