Pertemuan IV Advanced Entity Relationship Diagram Fak. Teknik Jurusan Teknik Informatika Universitas Pasundan Caca E. Supriana, S.Si.,MT.
[email protected] i id
2014
Hi E tit L h (W k E tit ) Himpunan Entitas Lemah (Weak Entity) y Himpunan entitas yang tidak memiliki
primary key disebut himpunan entitas lemah. lemah y Keberadaan entitas lemah bergantung pada eksistensinya dalam sebuah relasi terhadap entitas lainnya.
2
Hi E tit L h (W k E tit ) Himpunan Entitas Lemah (Weak Entity) – Identifikasi relasi dengan menggunakan double diamond y Diskriminator Di k i i t (atau ( t key parsial) dari k i l) d i himpunan entitas lemah adalah atribut‐ atribut yang dapat membedakan entitas entitas‐ entitas yang ada di himpunan entitas lemah. y Primary key dari y y himpunan p entitas lemah dibentuk dari primary key himpunan entitas (kuat) dimana enititas lemah bergantung, serta diskriminator dari entitas lemah itu sendiri 3
Himpunan Entitas Lemah y Penggambaran himpunan entitas lemah menggunakan dobel persegi
panjang. y Diskriminator dari himpunan entitas lemah digambarkan menggunakan garis bawah yang terputus‐putus k i b h t t t y payment‐number – diskriminator himpunan entitas payment y Primary key untuk payment – (loan‐number, payment‐number)
4
Himpunan Entitas Lemah y Primary key dari entitas kuat tidak secaraeksplisit
tersimpan dalam entitas lemah,karena hal tersebut secara implisit merupakan identifikasi b i li i k id ifik i relasi. y Jika loan‐number secara eksplisit tersimpan, Jik l b k li it t i payment mungkin merupakan entitas kuat, tapi kemudian relasi antara payment dan loan akan diduplikasikan oleh relasi secara implisit oleh atribut loan‐number common to payment and loan p y 5
C t h Hi E tit L h Contoh Himpunan Entitas Lemah y Pada suatu Universitas, course adalah entitas kuat
dan course‐offering dapat dimodelkan sebagai entitas lemah y Diskriminator course‐offering berisi semester ( (termasuk tahun) dan section‐number (jika terdiri ) (j dari beberapa bagian) y Jika kita modelkan course‐offering sebagai entitas k k kuat maka course‐number akan didefinsikan b k did fi ik sebagai atribut. Kemudian relasi dengan course akan secara implisit berisi atribut coursenumber 6
S i li i Spesialisasi y Merupakan proses desain top‐down; dengan
end_desain subgrouping didalam himpunan entitas yang berbeda dari himpunan entitas lain y g p y Subgrouping ini menjadi himpunan entitas yang levelnya lebih rendah dan memiliki atribut yang tidak dimiliki pada level atasnya. tidak dimiliki pada level atasnya y Digambarkan dengan komponen triangle berlabel ISA (Contoh : customer “is a” person). y Inheritan Atribut – Semua atribut dan relasi pada level lebih tinggi akan diturunkan pada himpunan entitas level bawahnya. 7
S i li i Spesialisasi
8
G li i Generalisasi y Merupakan proses desain bottom‐up –
mengkombinasikan jumlah himpunan entitas yang mempunyai fitur sama ke level yang lebih tinggi y Spesialisasi dan generalisasi merupakan kebalikan
satu sama lain
9
S i li i V G li i Spesialisasi Vs. Generalisasi y Mungkin terdapat kondisi di mana terjadi
multiple‐specialization. Contoh : entitas permanent employee vs temporary employee dan permanent‐employee vs temporary‐employee, dan officer vs secretary vs teller. Setiap employee dapat menjadi anggota dari permanent‐employee atau temporary‐employee dan juga sekaligus menjadi anggota salah satu dari officer, secretary, atau teller y Relationship ISA juga sering disebut sebagai relationship superclass – p p subclass 10
Constraint pada Specialization/Generalization y Constraint di mana entitas dapat menjadi anggota dari
himpunan entitas dengan level lebih rendah. – condition condition‐defined. Contoh : all customers over defined. Contoh : all customers over 65 years are members of seniorcitizen – user‐defined y Constraint yang menyatakan boleh tidaknya entitas
termasuk ke dalam lebih dari satu himpunan entitas yang p y g lebih rendah pada satu generalisasi yang sama – Disjoint – Overlapping 11
C t i t d Constraint pada Specialization/Generalization y Constraint completeness : menyatakan apakah
sebuah entitas pada level yang lebih tinggi harus termasuk ke dalam paling tidak salah satu dari entitas lebih rendah dalam sebuah generalisasi – total : sebuah entitas harus termasuk ke dalam salah satu entitas lebih rendah – partial: sebuah entitas tidak harus termasuk ke dalam salah satu dari entitas lebih rendah 12
A i Agregasi y Pada contoh ternary relationship works‐on, misalkan kita ingin
menyimpan informasi manager untuk pekerjaan yang dilakukan oleh seorang employee pada sebuah branch y Contoh ER dengan redundant relationship
13
Agregasi y ER dengan agregasi
14
A i Agregasi y Relationship sets works‐on dan manages
menunjukkan informasi yang overlap y Setiap anggota p gg relationship manages berkaitan p g dengan g sebuah relationship works‐on y Akan tetapi, beberapa anggota relationship works‐on mungkin tidak berkaitan dengan relationship manages. Sehingga relationship workson tidak dapat dihilangkan.
15
A i Agregasi y Redundansi tersebut dapat diatasi dengan agregasi
– Relationship dijadikan sebagai sebuah entitas abstrak – Relationship antar p relationship diijinkan p j – Abstraksi relationship menjadi entitas baru y Tanpa redundancy, diagram berikut menunjukkan : – Seorang employee melakukan sebuah pekerjaan tertentu pada sebuah branch – Kombinasi dari seorang employee, branch dan job dapat diasosiasikan dengan seorang manager
16
Hal‐hal yang harus diperhatikan dalam perancangan E‐R y Penggunaan atribut atau entitas untuk
merepresentasikan sebuah objek y Pemilihan penggunaan entitas atau relationship untuk merepresentasikan kondisi dunia nyata y Pemilihan penggunaan relationship ternary atau sepasang relationship binary y Pemilihan penggunaan entitas kuat atau lemah P ilih i k l h y Penggunaan spesialisasi/generalisasi y Penggunaan agregasi 17
ERD Banking Enterprise ERD Banking Enterprise
18
Si b l i b l d l N t i ER Simbol‐simbol dalam Notasi ER
19
Si b l i b l d l N t i ER Simbol‐simbol dalam Notasi ER
20
Alternatif Notasi E‐R Alternatif Notasi E‐R
21
Penurunan Skema ER ke Tabel Penurunan Skema ER ke Tabel y Primary key membolehkan himpunan entitas dan
y y y y
himpunan relasi diekspresikan secara uniform (seragam) sebagai tabel yang merepresentasikan conten dari basis data Basis data yang sesuai dengan diagram E‐R diagram dapat direpresentasikan dengan kumpulan tabel. U k i hi Untuk setiap himpunan entitas yang berhubungan ada i b h b d sebuah tabel unik yang di sebut dengan hubungan entitas atau himpunan relasi S ti t b l Setiap tabel memiliki jumlah kolom (secara umum disebut iliki j l h k l ( di b t atribut); yang memiliki nama yang unik. Konversi Diagram ER ke format Tabel adalah dasar untuk memperoleh basisdata relasional dari diagram ER 22
Representasi Himpunan Entitas sebagai Tabel y Himpunan Strong entity diturunkan ke dalam tabel
dengan atribut yang sama
23
Atribut Komposit dan Multivalued y Atribut komposit akan dipecah dengan membuat
atribut terpisah untuk masing‐masing komponennya. p y – Contoh : Himpunan entitas customer mempunyai atribut name yang terdiri dari first‐ name dan last last‐name. Penurunan name. Penurunan ke tabel akan menjadi dua atribut yaitu name.first‐name dan name.last‐name
24
Atribut Komposit dan Multivalued y Atribut multivalued M dari entitas E direpesentasikan oleh tabel
terpisah EM – Tabel EM memiliki atribut yang berhubungan dengan primary key dari E dan atribut yang berhubungan dengan atribut multivalued M – Contoh : Atribut Multivalued dependent‐names of employee direpresentasikan oleh tabel employee‐dependent‐names ( employee‐id, dname) l id d ) ‐ Setiap nilai atribut multivalued dipetakan pada baris terpisah tabel EM y C Contoh : Entitas employee dengan p y g p primary key John dan y yJ dependents Johnson dan Johndotir dipetakan dalam dua baris : (John, Johnson) dan (John, Johndotir)
25
Merepresentasikan Himpunan Entitas Lemah y Himpunan weak entity akan menjadi tabel yang
didalamnya ada kolom untuk primary key yang merupakan identifikasi dari strong entity
26
Representasi Himpunan Relasi ke dalam Tabel y Himpunan Relasi Banyak‐ke‐banyak (many to many)
direpresentasikan dalam tabel dengan kolom untuk primary key dari masing masing entitas yang primary key dari masing‐masing entitas yang berhubungan dan semua atribut deskriptif himpunan relasi tersebut. y Contoh : tabel untuk himpunan relasi borrower
27
Representasi ERD
28
Tabel‐tabel Redundan Tabel tabel Redundan y Himpunan relasi banyak‐ke‐satu (many to one) dan
satuke‐banyak (one to many) di mana mempunyai jenis total participation pada sisi banyak (many side) jenis total participation pada sisi‐banyak (many side) dapat direpresentasikan dengan menambah atribut ekstra pada sisi‐banyak (many side), mengandung p y ( y ), g g primary key pada sisi‐satu (one side)
29
Tabel‐tabel Redundan Tabel‐tabel Redundan y Contoh : Daripada membuat tabel untuk merepresentasikan
relasi accountbranch, tambahkan satu atribut relasi branch pada himpunan entitas account
30
Tabel‐tabel Redundan y Untuk himpunan relasi satu‐ke‐satu (one‐to‐one y relationship sets), salah satu sisi (side) dapat dipilih untuk
menjadi sisi‐banyak (many‐side) menjadi sisi banyak (many side) y Jika pada sisi‐banyak(many‐side) jenis partisipasinya adalah (partial‐participation), mengganti tabel untuk representasi relationship set dengan menambahkan atribut ekstra dapat menyebabkan munculnya nilai null y Tabel yang merepresentasikan relationship set yang menghubungkan weak entity dengan strong entity‐nya h b k k i d i bersifat redundan
31
Representasi spesialisasi dalam tabel y Metode 1:
– Bentuklah tabel untuk level entitas yang lebih tinggi gg – Bentuklah tabel untuk tiap level entitas lebih rendah, termasuk primary key dari level entitas y g yang lebih tinggi dan atribut lokal gg – Kekurangan: Untuk mendapatkan informasi tentang contoh : employee membutuhkan pengaksesan dua tabel
32
Representasi spesialisasi dalam tabel Representasi spesialisasi dalam tabel y Metode 2 :
– Bentuklah tabel untuk tiap himpunan entitas dengan semua atribut lokal dan turunan (inheritan) t ib t l k l d t (i h it ) – Jika spesialisasi adalah total, tabel untuk mengeneralisasi entitas (person) tidak dibutuhkan untuk disimpan • Dapat didefinisikan sebagai relasi view yang terdiri dari • Dapat didefinisikan sebagai relasi “view” yang terdiri dari gabungan tabel tabel spesialisasi • Tapi tabel eksplisit dapat masih diperlukan untuk batasan foreign key – Kekurangan : street dan city dapat tersimpan redundan untuk persons sebagai customers dan employees
33
Relasi yang menggambarkan Agregasi y Untuk merepresentasikan agregasi, buatlah tabel
yang terdiri dari : – primary key dari relasi agregasi – primary key dari himpunan entitas yang berhubungan – Setiap atribut deskriptif
34
Relasi yang menggambarkan Agregasi y Contoh : untuk merepresentasikan agregasi manages antara relasi
works‐on dan himpunan entitas manager, Buatlah tabel manages(employee‐id, branch‐name, title, manager‐name) y Tabel works‐on adalah redundan menyebabkan nilai null untuk atribut manager‐name pada tabel manager
35
