107

Desain Database

Dr. Khamami Herusantoso

1/107

Agenda Database planning System definition Requirement collection & analysis Database design


2/107

Database Database planning planning System System definition definition

DB System Development Lifecycle

Requirement Requirement collection collection & & analysis analysis

Db Design DBMS DBMS selection selection (opt) (opt)

Conceptual Conceptual db db design design

Logical Logical db db design design

Application Application design design

Physical Physical db db design design

Prototyping Prototyping (opt) (opt)

Implementation Implementation Data Data conversion conversion & & loading loading Testing Testing


Sekolah Tinggi IlmuOperational Statistik (STIS) Operational maintenance maintenance

Step 1: Database Planning Mengatur aktivitas-aktivitas yang memungkinkan

tahapan database system development lifecycle dilaksanakan seefisien dan seefektif mungkin Dua langkah penting dalam perencanaan: 1. Mendefinisikan mission statement untuk database system 2. Mengideintifikasi mission objectives


4/107

(i) Mission Statement Paparan misi menolong dalam menjelaskan tujuan

dari proyek database dan memberikan arah yang lebih jelas kepada pembuatan database system yang efisien dan efektif


5/107

Perusahaan Broker (Property)  Contoh: tujuan dari DreamHome database system adalah

untuk mengelola data yang digunakan dan dibuat guna mendukung bisnis sewa properti oleh client dan pemilik properti, dan juga untuk membantu kerjasama dan information sharing diantara cabang


6/107

(ii) Mission Objectives Setiap sasaran misi hendaknya dapat mengiden-

tifikasi tugas tertentu yg harus didukung oleh database


7/107

Example: Mission Objectives for DreamHome Database System


8/107

Database Database planning planning System System definition definition Requirement Requirement collection collection & & analysis analysis

Db Design DBMS DBMS selection selection (opt) (opt)

Conceptual Conceptual db db design design

Logical Logical db db design design

Application Application design design

Physical Physical db db design design


Implementation Implementation Data Data conversion conversion & & loading loading Testing Testing


Sekolah Tinggi IlmuOperational Statistik (STIS) Operational maintenance maintenance

Step 2: System Definition Menjelaskan: 1. scope dan batasan dari database system 2. view-view utama dari pemakai

User view mendefinisikan apa-apa yang diminta

pada database system dari sudut pandang: .Jabatan pekerjaan (misal, manager atau supervisor) atau .Enterprise application area (misal, marketing, personnel,

or stock control). Dr. Khamami Herusantoso

10 /107

Example: System Boundary for DreamHome Database System


11 /107

Contoh: User View


12 /107

Database Database planning planning System System definition definition Requirement Requirement collection collection && analysis analysis

Db Design Conceptual Conceptual db db design design DBMS DBMS selection selection (opt) (opt)

Application Application design design Logical Logical db db design design Physical Physical db db design design


Implementation Implementation Data Data conversion conversion && loading loading Testing Testing Dr. Khamami Herusantoso

13 Operational Operational maintenance maintenance /107

Step 3: Requirements Collection and Analysis Proses pengumpulan dan penganalisaan informasi

tentang bagian organisasi yang akan disupport oleh sistem database yang akan dibuat Hasil diatas digunakan untuk mengidentifikasi

permintaan pemakai terhadap sistem yang baru Hasil dari step ini adalah users’ requirements

specification document Dr. Khamami Herusantoso

14 /107

Aktivitas yang Dilakukan 1. Identifikasi aplikasi utama dan kelompok pemakai

yang akan menggunakan database yang akan dirancang. 2. Studi dan analisa dokumentasi yang ada yang

berhubungan dengan aplikasi yang akan dibuat. 3. Studi lingkungan operasi dan rencana penggunaan

informasi. Analisa jenis transaksi dan frekuensi pelaksanaannya Dr. Khamami Herusantoso

15 /107

Requirement & Specification Doc


16 /107

Requirement & Specification Doc


17 /107






Operational Operational maintenance maintenance 18 /107

Database Design Proses untuk membuat sebuah rancangan

database yang akan mendukung mission statement dan mission objective perusahaan Approach: Bottom-up Top-down


19 /107

Bottom-Up and Top-Down Approach

Sumber data (laporan, form dll)

Dunia Nyata

Unnormalized ubah ke format tabel Form (UNF)

buat diagram ER hilangkan group berulang

Diagram ER petakan ke tabel

Bentuk normal tahap ketiga (3NF)

Bentuk hilangkan normal tahap ketergantungan kedua (2NF) transitif

hilangkan ketergantungan parsial

Bentuk normal pertama (1NF)

20 /107

Database Design Approaches Bottom-up: represented by normalization process Dimulai dari level atribut-atribut dasar (yaitu entitas,

properti dan relationship), dimana dengan analisa dari asosiasi diantara atribut-atribut tsb, atribut dikelompokkan menjadi tabel-tabel yang merepresentasikan tipe entitas dan hubungan diantara entitas Tepat untuk perancangan Database yang sederhana

dengan jumlah atribut yang relatif sedikit


21 /107

Contoh: Perancangan Database Bottom-up Kumpulan atribut: NIP, Nama, NoUnit, NamaUnit,

NIPAtasan, Nama Atasan NIP

Nama

NoUnit

NamaUnit NIPAtasan

NamaAtasan

001

Budi

01

Setjen

006

Yudi

002

Yudo

01

Setjen

006

Yudi

003

Tuti

02

BPPK

004

Yono

004

Yono

02

BPPK

008

Yani

005

Yeni

03

DJP

009

Yuni

006

Yudi

01

Setjen

010

Yana


22 /107

Contoh: Perancangan Database Bottom-up (lanjutan) Dikelompokkan kedalam tiga jenis entitas (dengan

proses normalisasi) Pegawai (atribut ke-1 dan ke2), Unit (atribut ke-3 dan ke-4), dan Atasan (atribut ke-5 dan ke-6) Entitas-entitas tersebut menjadi tabel


23 /107

Database Design Approaches Top-Down: illustrated by the ER model concepts Dimulai dari pengembangan data model yang berisikan

beberapa high-level entitas dan relationship, dan kemudian mengaplikasikan top-down refinement secara berturut-turut untuk mengidentifikasi entitas dengan level yang lebih rendah, relationship dan atribut-atribut yang terasosiasi Tepat untuk perancangan Database yang kompleks


24 /107

Contoh: Perancangan Database Top-Down NIP

Nama

NamaUnit NoUnit dipecah dipecah

Pegawai

NIP

Nama

Pegawai


NamaUnit

Bekerja

NoUnit

Unit 25 /107






26 Operational Operational maintenance maintenance /107

Conceptual Database Design Proses pembuatan sebuah model dari data yang

digunakan pada sebuah perusahaan, tidak bergantung pada pertimbangan fisik. Model data dibuat dengan menggunakan informasi yang

tertulis dalam users’ requirements specification Model data konseptual adalah sumber dari

informasi untuk fase perancangan logikal


27 /107

Logical Database Design Proses pembuatan sebuah model berdasarkan

pada sebuah model data yang spesifik (misalnya relasional), tetapi tidak bergantung pada DBMS tertentu dan pertimbangan fisik lainnya. Model data konseptual diproses dan dipetakan ke

model data logikal  hasilnya adalah tabel-tabel relational yang telah dinormalisasi


28 /107

Physical Database Design Proses pembuatan deskripsi dari implementasi

Database pada media penyimpanan sekunder. Mendeskripsikan tabel dasar (base relation),

organisasi file dan indeks yang digunakan untuk mendapatkan akses yang efisien. Disesuaikan terhadap sistem DBMS tertentu


29 /107

Bottom-Up and Top-Down Approach Sumber data (laporan, form dll)

Dunia Nyata

Unnormalized ubah ke format tabel Form (UNF)

buat diagram ER hilangkan group berulang

Diagram ER

conceptual DB design petakan ke tabel

Bentuk normal tahap ketiga (3NF)

Bentuk hilangkan normal tahap ketergantungan kedua (2NF) transitif

hilangkan ketergantungan parsial

Bentuk normal pertama (1NF)

Logical DB design Physical DB Design 30 /107

Pemodelan Data Dengan Entity Relationship (ER)

Pokok Bahasan ke-4 31/107

Agenda Konsep model ER Multiplicity


32/107

Entity Relationship Diagram mgrStart Date

staffNo Supervisor

Staff

Supervises Supervisee

1

1

M

1

M

Manage

Has

branchNo

1 Branch

1

1

Registers M clientNo


Client

1

State States s

M

Preference

33/107

Konsep Model ER 1. Tipe/himpunan entitas (entity type) 2. Tipe/himpunan relasi (relationship type) 3. Atribut (attributes)


34/107

1. Tipe Entitas Tipe entitas (entity type) Kumpulan dari objek-objek yang memiliki properti/ karakteristik yang sama, yang diidentifikasi oleh suatu perusahaan/pemakai memiliki keberadaan yang bebas. Kejadian Entitas (entity occurrence) Objek/instance dari tipe entitas yang dapat diidentifikasikan secara unik.


35/107

Contoh Tipe Entitas


36/107

Diagram ER dari Tipe Entitas Staff dan Branch Dilambangkan sebagai empat persegi panjang

yang diberi label dengan nama entitas, yang biasanya merupakan kata benda tunggal Huruf pertama nama entitas adalah huruf besar


37/107

2. Tipe Relasi Tipe relasi (relationship type) Sekumpulan asosiasi/hubungan diantara jenis entitas yang memiliki arti tertentu Kejadian relasi (relationship occurrence) Asosiasi/hubungan yang dapat diidentifikasi secara unik, termasuk satu occurrence untuk setiap jenis entitas yang berpartisipasi


38/107

Diagram ER dari Relasi Branch Has Staff Nama relasi adalah kata kerja atau frase yang

mengandung kata kerja (e.g., Supervises & LeasedBy) Huruf pertama dari setiap kata adalah huruf besar

Branch

Has

Staff

“Branch has staff” Dr. Khamami Herusantoso

39/107

Semantic Net Tipe Relasi Has

entity occurrence


relationship occurrence

entity occurrence

40/107

Derajat Relasi Derajat relasi (degree of a relationship) Jumlah entitas yang berpartisipasi dalam suatu relasi

Derajat relasi: Dua disebut biner (binary) Tiga disebut ternary Empat disebut quaternary Dr. Khamami Herusantoso

41/107

Relasi Biner: Owns dan Has

Owns

Branch

Has

Staff

“Branch has staff”


42/107

Relasi Ternary: Registers Relasi direpresentasikan dengan menggunakan

lambang diamond Nama relasi dituliskan didalam diamond tersebut

Staf mendaftarkan klien pada sebuah kantor cabang


43/107

Relasi Quaternary: Arranges

Pengumpul derma membuat tawaran (bid) atas nama pembeli yang didukung oleh institusi keuangan


44/107

Jenis Relasi Relasi tunggal (recursive/unary relationship) Suatu relasi dimana jenis entitas yang sama

berpartisipasi lebih dari sekali dengan fungsi yang berbeda-beda Relasi dapat diberikan nama fungsi (role name)

untuk menunjukkan tujuan dari setiap jenis entitas yang berpartisipasi pada sebuah relasi


45/107

Relasi Tunggal: Supervises dgn Nama Fungsi Supervisor dan Supervises

Supervisor Super vises

Staff

Supervisee

Role name


46/107

Entitas yang Terasosiasi Melalui Dua Relasi Berbeda Dengan Nama Fungsi

Manages Has


47/107

3. Atribut Atribut Properti dari sebuah entitas atau relasi.

Domain atribut Himpunan dari nilai-nilai yang mungkin dari satu atau

lebih atribut.


48/107

Jenis Atribut Atribut sederhana (simple/atomic attribute) Atribut komposit/campuran (composite attribute) Atribut bernilai-tunggal (single-valued Attribute) Atribut bernilai-jamak (multi-valued Attribute) Atribut turunan (derived attribute)


49/107

Atribut sederhana Atribut yang terdiri dari komponen tunggal dengan

keberadaan bebas. Contoh: jabatan dan gaji pada entitas staf

gaji


jabatan

50/107

Atribut Komposit/Campuran Atribut terdiri dari beberapa komponen, setiap

komponen keberadaannya bebas Contoh: atribut alamat pada entitas Branch yang dapat

dipecah menjadi nama jalan, kota dan kode pos. Keputusan untuk memecah atribut ini bergantung pada

view pemakai terhadap data. jalan

kota

pos

alamat Dr. Khamami Herusantoso

51/107

Atribut Bernilai-Tunggal Atribut yang menyimpan nilai tunggal untuk setiap

occurrence/instance dari sebuah entitas Contoh, setiap occurrence dari entitas Branch

memiliki nomor branch (branchNo) atribut yang bernilai tunggal. branchN o


52/107

Atribut bernilai-jamak  Atribut yang menyimpan nilai jamak untuk setiap

occurrence dari tipe entitas. Contoh, setiap occurrence dari tipe entitas Branch

dapat memiliki nilai atribut telNo lebih dari satu.

telNo


53/107

Atribut Turunan Atribut yang merepresentasikan sebuah nilai dari

turunan nilai sebuah atribut atau himpunan atribut yang berhubungan (atribut-atribut tersebut tidak selalu harus dari tipe entitas yang sama) Contoh Atribut durasi yang dihitung dari atribut rentStart dan rentFinish Atribut totalStaff yang dihitung dengan menghitung total jumlah

kemunculan dari entitas staff durasi


54/107

Contoh Diagram ER beserta Atributnya composite attribute

fname name nip bdate

attribute as PK

lname name number

sex address salary

Employee

degree multi-valued attribute


WorksFor

location

Department number of employees derived attribute

55/107

Contoh Diagram ER beserta Atributnya composite attribute

fname name nip bdate

lname

attribute for relationship

year name number

sex address salary

Employee

degree multi-valued attribute


attribute as PK

WorksFor

location

Department number of employees derived attribute

56/107

Tipe Entitas Tipe Entitas Kuat (Strong Entity Type) Tipe Entitas Lemah (Weak Entity Type)


57/107

Tipe Entitas Kuat Tipe entitas yang keberadaannya bebas dari

keberadaan entitas lain. Tiap occurrence dari entitas ini secara unik dapat diidentifikasi dengan menggunakan atribut primary key dari tipe entitas tsb. fname name nip bdate

lname sex address salary

Employee

degree Dr. Khamami Herusantoso

58/107

Tipe Entitas Lemah Tipe entitas yang keberadaannya bergantung dari

keberadaan entitas lain. Tidak dapat melakukan identifikasi occurrence entitas dengan hanya menggunakan atribut-atribut pada entitas ini. fname name nip bdate

lname

maxRent

sex address salary

Employee

States

prefType

Preference

degree Dr. Khamami Herusantoso

59/107

Multiplicity Dalam sebuah relationship pada Database

terdapat batasan-batasan yang terstruktur (Structural Constraints). Tipe utama dari batasan disebut multiplicity yang

mencerminkan aturan dari sistem yang akan dibuat oleh user.


60/107

Multiplicity Derajat relasi yang paling umum adalah biner

(binary) Rasio kardinalitas (Multiplicity) dari relasi biner: Satu-ke-satu/one-to-one (1:1) Satu-ke-banyak/one-to-many (1:*) atau 1:N Banyak-ke-banyak/many-to-many (*:*) atau M:N atau N:N Dr. Khamami Herusantoso

61/107

Semantic Net dari Tipe Relasi Staff Manages Branch


62/107

Multiplicity dari Relasi Staff Manages Branch (1:1)

staffNo

Staff

1

Manages

Sebuah Branch dikelola oleh hanya 1 Staff


branchNo

Multiplicity

1

Branch

Seorang Staff mengelola 0 atau 1 Branch

63/107

Semantic Net dari Tipe Relasi Staff Oversees PropertyForRent


64/107

Multiplicity dari Tipe Relasi Staff Oversees PropertyForRent (1:M)

staffNo

Staff

propertyNo

1

Oversees

Sebuah Property diawasi oleh 0 atau 1 Staff


M

PropertyForRent

Seorang Staff mengawasi 0 atau banyak Property

65/107

Semantic Net dari Tipe Relasi Newspaper Advertises PropertyForRent


66/107

Multiplicity dari Tipe Relasi Newspaper Advertises PropertyForRent (M:N)

name

Newspaper

propertyNo

M

Advertises

Sebuah Property diiklankan oleh 0 atau banyak koran


N

PropertyForRent

Sebuah koran mengiklankan 1 atau banyak Property

67/107

Komponen Multiplicity Multiplicity dibentuk dari dua tipe batasan/restriksi

pada relasi yaitu: Kardinalitas (cardinality) dan Batasan partisipasi (participation constraint)


68/107

Komponen Multiplicity Kardinalitas Menerangkan jumlah maksimum dari occurrence relasi

yang mungkin bagi sebuah entitas yang berpartisipasi dalam suatu tipe relasi. Batasan partisipasi Menentukan apakah semua atau hanya sebagian entitas

occurrence saja yang berpartisipasi pada sebuah relasi. Dr. Khamami Herusantoso

69/107

Multiplicity Sebagai Kardinalitas dan Batasan Partisipasi Cardinality sebuah branch dikelola oleh max seorang staff

ratio cardinality  1:1

seorang staff mengelola max sebuah branch

staffNo

Staff

branchNo

1

Manages

1

Branch

tidak semua staff semua branch harus ada jadi pengelola (optional) yang mengelola (mandatory) participation Dr. Khamami Herusantoso

70/107

Bacalah! mgrStart Date

staffNo Supervisor

Staff

Supervises Supervisee

1

1

M

1

M

Manage

Has

branchNo

1 Branch

1

1

Registers M clientNo


Client

1

State s

M

Preference

71/107

Latihan Penulisan ERD


72/107

Pemetaan Diagram ER ke Tabel

Pokok Bahasan ke-5 77/107

Agenda Tujuan pemetaan Pemetaan berdasarkan entity type Pemetaan berdasarkan relationship type Pemetaan berdasarkan attribute


78/107

Tujuan Membuat tabel-tabel untuk diagram ER dimana

tabel-tabel tersebut merepresentasikan entitas, relasi dan atribut pada diagram ER tersebut. Hubungan antara entitas (relasi) direpresentasikan

oleh mekanisme Primary Key (PK)/Foreign Key (FK).


79/107

Diagram ER postcode street fName

city

lName position

name staffNo

proper tyNo

Staff

Registers

N

N

1

Client

telNo

name fName

rooms

M

1

clientNo

type rent

Property ForRent

sex

DOB

address

view Date com ment

Views States

1

Preference

prefType

maxRent

lName


80/107

Pemetaan Diagram ER ke Tabel Pemetaan dilakukan berdasarkan element berikut: 1. Tipe entitas kuat (strong entity types) Entity type 2. Tipe entitas lemah (weak entity types) 3. Tipe relasi biner One-to-many (1:*) 4. Tipe relasi biner One-to-one (1:1) Relationship type 5. Tipe relasi recursive/unary 6. Tipe relasi biner many-to-many (*:*) 7. Tipe relasi kompleks 8. Multi-valued attributes Attribute Dr. Khamami Herusantoso

81/107

1. Pemetaan Entitas Kuat (Strong Entity) Untuk setiap strong entity, buatlah sebuah tabel

yang meliputi semua atribut sederhana yang ada pada entitas tersebut. Jika ada atribut komposit, tambahkan hanya

bagian atribut sederhananya saja.


82/107

Contoh Pemetaan Contoh: hasil pemetaan dari entitas Staff adalah Staff (staffNo, fName, lName, position, sex, DOB) Primary Key staffNo fName

lName Name

staffNo

position sex

Staff DOB staffNo


fName

lName

Position

Sex

DOB

83/107

2. Pemetaan Entitas Lemah (Weak Entity) Untuk setiap weak entity, buat sebuah tabel

dengan menambahkan semua atribut sederhana yang ada pada entitas tersebut. PK dari weak entity adalah diturunkan secara

parsial atau penuh dari setiap entitas pemilik; Jadi identifikasi PK dari weak entity tidak dapat dilakukan

sampai semua relationship pada entitas pemilik selesai dipetakan. Dr. Khamami Herusantoso

84/107

Contoh Pemetaan Hasil pemetaan weak entity Preference: Preference (prefType, maxRent) Primary Key Tidak ada (pada saat ini) prefType prefType

maxRent

maxRent

Preference


85/107

Hasil Pemetaan Semua Entitas fName

lName position

name staffNo

Staff staffNo

fName

lName

Position

Sex

DOB

sex Staff DOB

fName

Client

lName name

telNo

clientNo

fName

lName

telNo

clientNo Client


86/107

Hasil Pemetaan Semua Entitas prefType

Preference

maxRent

prefType

maxRent

Preference

postcode street proper tyNo

city type

address

rent Property ForRent

PropertyForRent property No

street

city

postcode

type

rooms

rent

rooms


87/107

3. Pemetaan Relasi Biner 1:N Untuk setiap relasi biner 1:N, entitas pada sisi 1

dari relasi dijadikan entitas parent dan entitas pada sisi banyak (N) dijadikan sebagai entitas child. Untuk merepresentasikan relationship ini,

duplikasikan atribut PK ke tabel yang merepresentasikan entitas child yang berfungsi sebagai FK.


88/107

Contoh Pemetaan Hasil pemetaan dari relasi Staff Registers Client Staff (staffNo, fName, lName, position, sex, DOB) • Primary key staffNo Client (clientNo, fName, lName, telNo, staffNo) • Primary key clientNo, Alternate key telNo, • Foreign key staffN0 references Staff(staffNo)


89/107

Contoh Pemetaan Staff staffNo

fName

lName

Position

Sex

DOB

Staff 1 duplikasikan

Registers N

Client clientNo

fName

lName

telNo

staffNo

Client


90/107

4. Pemetaan Relasi Biner 1:1 a. Partisipasi Mandatory pada dua sisi relasi 1:1 Gabungkan entitas yang terlibat ke dalam satu tabel dan

pilih salah satu PK sebagai PK pada tabel baru tsb.


91/107

Contoh Pemetaan (Mandatory di Dua Sisi) Client States Preference setiap klien harus punya satu preference dan setiap preference harus dimiliki oleh satu klien ClientPref (clientNo, fName, lName, telNo, prefType,

maxRent, staffNo) Primary key clientNo Foreign key staffNo references Staff(staffNo)


92/107

Contoh Pemetaan (Mandatory di Dua Sisi) Client clientNo

fName

lName

telNo

staffNo

Client 1 States 1

digabung menjadi tabel baru

Preference prefType

maxRent

Prefe rence ClientPref clientNo


fName

lName

telNo

prefType

maxRent

staffNo

93/107

Pemetaan Relasi Biner 1:1 b. Partisipasi Mandatory pada salah satu sisi relasi biner 1:1 Identifikasi entitas parent dan child dengan menggunakan

batasan partisipasi • Entitas dengan partisipasi optional pada relationship dijadikan sebagai entitas parent, dan entitas dengan partisipasi mandatory dijadikan sebagai entitas child.

Jika relasi mempunyai atribut, tambahkan atribut tersebut

pada tabel child.


94/107

Contoh Pemetaan (Mandatory pada salah satu sisi) Jika Client States Preference memiliki partisipasi

optional pada entitas Client. Klien boleh tidak mempunyai preference tetapi setiap

preference harus dimiliki oleh satu klien Client (clientNo, fName, lName, telNo, staffNo) • Primary key clientNo • Foreign key staffNo references Staff(staffNo) Preference (clientNo, prefType, maxRent) • Primary key clientNo • Foreign key clientNo references Client(clientNo) Dr. Khamami Herusantoso

95/107

Contoh Pemetaan (Mandatory pada salah satu sisi) Client clientNo

fName

lName

telNo

staffNo

Client date comme nt

1 States 1 Prefe rence


Preference clientNo

prefType

maxRent

date

comment

96/107

Pemetaan Relasi Biner 1:1 c. Partisipasi optional pada dua sisi relasi 1:1 • Penentuan entitas parent dan child adalah bebas


97/107

Contoh Pemetaan (Opsional pada dua sisi) Staff Uses Car Tidak semua staff menggunakan mobil dan tidak semua mobil digunakan oleh seorang staff Jika tidak ada info tambahan, maka pilihannya adalah

bebas; duplikasikan nilai PK pada entitas Staff ke entitas Car, atau sebaliknya. Jika diasumsikan bahwa hampir semua mobil digunakan

oleh staff dan hanya sebagian kecil dari staff menggunakan mobil: • Staff sebagai entitas parent dan Car sebagai entitas child Dr. Khamami Herusantoso

98/107

5. Pemetaan Relasi Recursive/Unary Jika di dua sisi atau salah satu sisi merupakan

partisipasi mandatory, representasikan relasi recursive dengan menduplikasi PK. Jika di dua sisi merupakan partisipasi optional

buatlah tabel baru yang hanya terdiri dari copy dua PK dengan nama diubah sesuai fungsi.


99/107

Contoh Jika di salah-satu sisi Partisipasi Mandatory

fName

lName name

1 Supervises

position sex

Staff

10

DOB staffNo

duplikasi dari staffNo

Staff staffNo


fName

lName

Position

Sex

DOB

supNo

100 /107

Contoh Jika di dua sisi Partisipasi Optional Staff staffNo

fName

lName

Position

Sex

DOB

lName name

1 Supervises

fName

position sex

Staff

10

DOB staffNo


Supervise staffNoSr

duplikasi dari staffNo yg merupakan FK di tabel ini

staffNoSe

101 /107

6. Pemetaan Relasi Biner N:M Buat sebuah tabel untuk merepresentasikan relasi tsb

dan tambahkan semua atribut relasi tersebut. Duplikasikan atribut PK dari entitas yang berpatisipasi

pada relasi ke dalam tabel baru. Duplikat tsb bertindak sebagai FK. FK ini adalah juga sebagai PK dari tabel baru tsb (tetapi

mungkin dengan kombinasi dari suatu atribut relasi tsb). Contoh: Client Views PropertyForRent Dr. Khamami Herusantoso

102 /107

Contoh Pemetaan (many-tomany) Client clientNo

fName

lName

telNo

Client ClientProperty

N

Views M

clientNo

view Date com ment

propertyNo

viewDate

comment

PropertyForRent property No

street

city

postcode

type

rooms

rent

Property ForRent


103 /107

7. Pemetaan Relasi Kompleks Buat tabel baru untuk merepresentasikan relasi tsb

dan tambahkan atribut yang ada pada relasi tsb ke tabel baru. Duplikat atribut PK dari semua entitas yang

berpartisipasi dan tambahkan ke tabel baru tsb untuk menjadi FK.


104 /107

Pemetaan Relasi Kompleks Relasi ternary Registers Staff No

Staff

Date Joined

branch No

1 Registers

1

Branch Registration

N Client


clientNo

branchNo

staffNo

dateJoined

client No

105 /107

8. Multi-valued attributes Buatlah sebuah tabel baru untuk

merepresentasikan atribut multi-valued (bernilai jamak). Duplikasikan PK dari entitas dan tambahkan pada

tabel baru tsb yang berfungsi sebagai FK.


106 /107

Contoh Pemetaan (multi-valued attribute) Contoh pada Branch user view Branch (branchNo, street, city, postcode) • Primary key branchNo

Telephone (telNo, branchNo) • Primary key telNo • Foreign key branchNo reference Branch(branchNo)

Branch branchNo street

street

city

postcode

telNo

city postcode

branchNo Branch


telNo

Phone branchNo

telNo

107 /107

107

Recommend Documents