Bab2 model entity relationship

©Silberschatz, Korth and Sudarshan2.1Database System Concepts

Bab 2 : Model Entity-RelationshipBab 2 : Model Entity-Relationship

Kumpulan Entity

Kumpulan Relationship

Hasil Desain

Kendala Pemetaan

Kunci

Diagram E-R

Keistimewaan Perluasan E-R

Desain dari Skema Database E-R

Reduksi dari Skema E-R ke Tabel


Entity SetsEntity Sets

Database dapat dimodelkan sebagai: kumpulan dari entity (entitas)

hubungan antar entity (entitas)

Entity adalah suatu obyek yang dapat dikenali dari obyek yang lain.

Contoh : seseorang yang khusus, perusahaan, peristiwa, tanaman.

Entity mempunyai atribut Contoh : seseorang mempunyai nama dan alamat

Kumpulan entity adalah suatu kumpulan entity dengan tipe yang sama yang berbagi properti yang sama pula.

Contoh : kumpulan orang, perusahaan, tanaman, tempat liburan


Kumpulan Entitas Pelangganan (Kumpulan Entitas Pelangganan (customer) customer) dan Pinjaman (dan Pinjaman (loan)loan)

customer-id customer- customer- customer- loan- amount name street city number


AttributesAttributes

Entity ditampilkan oleh sekumpulan attribute, yang mana properti deskriptifnya dikuasai oleh seluruh anggota dalam kumpulan entity.

Contoh :

customer = (customer-id, customer-name, customer-street, customer-city)

loan = (loan-number, amount)

Domain –adalah satuan nilai yang diperbolehkan pada setiap attribute

Tipe attribute : Simple (sederhana) dan composite (gabungan) attributes.

Single-valued (satu-fungsi ) dan multi-valued (multi-fungsi ) attributes

Contoh : atribut multi-fungsi : nomor telepon

Derived (asal) attributes

Dapat diperhitungkan dari atribut lain

Contoh : umur, tanggal kelahiran


Composite AttributesComposite Attributes


Relationship SetsRelationship Sets

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

Contoh :

(Hayes, A-102) depositor


Relationship Set Relationship Set borrowerborrower


Relationship Sets (lanjutan)Relationship Sets (lanjutan) Attribute dapat merupakan properti dari relationship set.

Sebagai contoh: depositor merupakan relationship set antara entity sets customer dan account mungkin beratribut access-date


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)


Mapping Cardinalities (Cardinalitas Pemetaan)Mapping Cardinalities (Cardinalitas Pemetaan)

Mengungkap jumlah entitas ke entitas yang lain bisa dihubungkan melalui relationship set.

Paling banyak digunakan dalam menggambarkan relationship sets biner ..

Untuk relationship set biner cardinalitas pemetaan harus merupakan salah satu dari tipe berikut: One to one (satu ke satu)

One to many (satu ke banyak)

Many to one (banyak ke satu)

Many to many (banyak ke banyak)



One to one One to many

Note: Beberapa elemen di A dan B mungkin tidak dipetakan ke elemen manapun di himpunan lain



Many to one Many to many

Note: Beberapa elemen di A dan B mungkin tidak dipetakan pada elemen mana pun di himpunan lain.


Mapping Cardinalities mempengaruhi Mapping Cardinalities mempengaruhi ER DesignER Design

Dapat membuat access-date sebagai atribut dari account, bukan atribut relationship , jika tiap account hanya mempunyai satu pelanggan

Misal, hubungan dari account ke pelanggan adalah banyak ke satu, atau secara equivalent, pelanggan ke account adalah satu ke banyak.


E-R DiagramsE-R Diagrams

Rectangles melambangkan set-set entitas .

Diamonds melambangkan set-set hubungan (relationship) . Lines menghubungkan atribut dengan set-set entitas serta set-set entitas

dengan set-set hubungan (relationship). Ellipses mewakili attributes

Double ellipses mewakili atribut multivalued .

Dashed ellipses menunjukkan sifat yang didapat..

Underline menunjukkan sifat kunci pokok (akan dipelajari nanti)


E-R Diagram dengan Composite, Multivalued, E-R Diagram dengan Composite, Multivalued, dan Derived Attributesdan Derived Attributes


Relationship Sets dengan Attributes RolesRelationship Sets dengan Attributes Roles


RolesRoles

Satuan entity dalam suatu relationship tidak perlu terpisah Label “manager” dan “worker” disebut sebagai tugas (roles);

mereka menetapkan bagaimana entitas pegawai berinteraksi dengan pekerjaan untuk relationship sets

Roles ditunjukkan di E-R diagram dengan memberi label pada garis yang menyambungkan diamond ke segi empat.

Label role adalah merupakan pilihan, dan dipergunakan untuk menjelaskan ilmu semantik relationship


Cardinality Constraints (keterbatasan kardinalitas)Cardinality Constraints (keterbatasan kardinalitas)

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

borrower


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


Many-To-One Relationships (Many-To-One Relationships (HubunganHubungan Banyak-Ke-BanyakBanyak-Ke-Banyak))

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


Many-To-Many Relationship (Many-To-Many Relationship (HubunganHubungan Banyak-Ke-BanyakBanyak-Ke-Banyak))

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


Notasi Alternatif untuk Batasan Notasi Alternatif untuk Batasan CardinalitasCardinalitas

Batas cardinalitas juga bisa mengungkapkan keterbatasan partisipasi


Keys (kunci-kunci)Keys (kunci-kunci)

Super key (super kunci) dari set entitas adalah satu atau lebih atribut yang mana nilainya secara unik menentukan masing-masing entitas .

Candidate key (calon kunci) dari suatu set entitas adalah Super key minimal

Customer-id (id pelanggan) adalah Candidate key dari pelanggan

account-number (nomer rekening ): adalah candidate key dari account

Meski beberapa candidate key mungkin ada, salah satu candidate key dipilih untuk menjadi primary key (kunci pokok).


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)


Diagram E-R dengan Hubungan Ternary Diagram E-R dengan Hubungan Ternary ((Ternary Relationship)Ternary Relationship)


Keterbatasan Cardinalitas pada Hubungan Ternary Keterbatasan Cardinalitas pada Hubungan Ternary (Ternary Relationship)(Ternary Relationship)

Diperbolehkan tak lebih dari satu anak panah dari hubungan ternary (atau derajat yang lebih besar) untuk menunjukkan keterbatasan cardinalitas

Misal. Suatu anak panah dari wroks-on ke job menunjukkan masing-masing pegawai mengerjakan tak lebih dari satu pekerjaan di cabang yang mana pun.

Jika ada lebih dari satu anak panah, ada dua cara untuk mendefinisikan artinya.

misal. Hubungan ternary R di antara A, B dan C dengan anak panah ke B dan C bisa berarti :

1. Tiap-tiap entitas A dihubungkan dengan entitas unik dari B dan C atau

2. Masing-masing pasang entitas dari (A, B) dihubungkan dengan entitas unik C, dan masing-masing pasang (A, C) dihubungkan dengan entitas unik B

Tiap alternatif sudah dipakai pada formalisme berbeda

Untuk menghindari kebingungan tidak diijinkan menggunakan lebih dari satu anak panah


Binary Vs. Hubungan NonbinaryBinary Vs. Hubungan Nonbinary (Non-Binary (Non-Binary Relationships)Relationships)

Beberapa hubungan yang kelihatannya non biner mungkin sebaiknya ditampilkan menggunakan hubungan biner

Misal. Hubungan ternary orang tua, menghubungkan seorang anak ke bapak dan ibunya, hal ini paling baik diganti oleh dua hubungan biner, bapak dan ibu

Dengan menggunakan dua hubungan biner memungkinkan informasi sebagian (misal hanya ibu yang tahu)

Tetapi ada beberapa hubungan yang secara alami non-biner

misal. works-on


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


Design IssuesDesign Issues

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)


Weak Entity Sets (Set-set Entitas Weak Entity Sets (Set-set Entitas Lemah) Lemah)

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.


Weak Entity Sets / Weak Entity Sets / Set-Set Entitas lemah Set-Set Entitas lemah (lanjutan) (lanjutan)

Kita menggambarkan set entitas lemah dengan segi empat dobel

Kita menekankan discriminator pada set entitas lemah dengan garis pisah.

payment-number – discriminator dari set entitas payment

Primary key untuk payment – (loan-number, payment-number)


Weak Entity Sets / Weak Entity Sets / Set-Set Entitas Lemah Set-Set Entitas Lemah (lanjutan)(lanjutan)

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


Contoh Lain Set Entitas LemahContoh Lain Set Entitas Lemah

Di universitas, kursus (course) adalah entitas kuat dan penawaran-kursus (course-offering) bisa diperagakan sebagai entitas lemah

Discriminator dari course-offering adalah semester (termasuk tahun) dan bagian-jumlah (section-number) (jika terdapat lebih dari satu bagian)

Jika kita peragakan course-offering sebagai entitas kuat kita akan peragakan course-number sebagai sifat.

Kemudian relationship dengan course akan tersirat pada attribute course-number


SpesialisasiSpesialisasi

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.


Contoh SpesialisasiContoh Spesialisasi


GeneralisasiGeneralisasi

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

level lebih rendah


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


Aggregation (Aggregation (Aggregasi/Penjumlahan)Aggregasi/Penjumlahan)

Menganggap hubungan ternary works-on , yang telah kami lihat di awal

Misal kami ingin mencatat manajer untuk tugas yang dilakukan oleh seorang pegawai di suatu cabang


Aggregation / Aggregation / Penjumlahan (lanjutan)Penjumlahan (lanjutan)

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

combination ) mungkin mempunyai manager


Diagram E-R Dengan AggregationDiagram E-R Dengan Aggregation


Penetapan E-R DesignPenetapan E-R Design

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.


Diagram E-R bagi Perusahaan PerbankanDiagram E-R bagi Perusahaan Perbankan


Ringkasan Simbol2 yang digunakan Ringkasan Simbol2 yang digunakan dalam notasi E-Rdalam notasi E-R


Ringkasan Simbol2 (lanjutan)Ringkasan Simbol2 (lanjutan)


Alternatif notasi E-RAlternatif notasi E-R


UMLUML

UML: Unified Modeling Language

UML mempunyai banyak bagian yang secara grafis memperagakan aspek berbeda dari seluruh software system

UML Class Diagrams bersesuaian dengan diagram E-R, tetapi dengan beberapa perbedaan.


Ringkasan dari UML Class Diagram NotationRingkasan dari UML Class Diagram Notation


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 Diagram Notation (lanjutan)UML Class Diagram Notation (lanjutan)

*Note reversal of position in cardinality constraint depiction


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.


Melambangkan Set-Set Entitas sebagai Tabel Melambangkan Set-Set Entitas sebagai Tabel

Set entitas kuat berkurang menjadi tabel dengan sifat yang sama


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)


Merepresentasi Set Entitas LemahMerepresentasi Set Entitas Lemah

Set entitas lemah menjadi sebuah tabel yang menyertakan kolom untuk primary key dari set entitas kuat pengenal


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.

Misal. : tabel untuk set hubungan borrower


Kelebihan Tabel Kelebihan Tabel

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).


Representing Specialization as TablesRepresenting Specialization as Tables

Method 1: Form a table for the higher level entity

Form a table for each lower level entity set, include primary key of higher level entity set and local attributes

table table attributespersonname, street, city customername, credit-ratingemployeename, salary

Drawback: getting information about, e.g., employee requires accessing two tables


Representing Specialization as Tables Representing Specialization as Tables (Cont.)(Cont.)

Method 2: Form a table for each entity set with all local and inherited

attributestable table attributes

personname, street, citycustomername, street, city, credit-ratingemployee name, street, city, salary

If specialization is total, no need to create table for generalized entity (person)

Drawback: street and city may be stored redundantly for persons who are both customers and employees


Relations Corresponding to Relations Corresponding to AggregationAggregation

To represent aggregation, create a table containing

primary key of the aggregated relationship,

the primary key of the associated entity set

Any descriptive attributes


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

End of Chapter 2End of Chapter 2


E-R Diagram for Exercise 2.10E-R Diagram for Exercise 2.10


Existence DependenciesExistence Dependencies

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.

Bab2 model entity relationship

Business

Transcript of Bab2 model entity relationship