2 Desember 2022

MATERI BIG DATA

PERTEMUAN IX
DESAIN BASIS DATA

ADE IRMA RIZMAYANTI , M.KOM

 Desain Basis Data & ER Diagram (ERD)
Proses desain basis data dpt dibagi menjadi 6 langkah:
3 langkah pertama sangat relevan dengan ER model:
1. Analisis kebutuhan (Requirements Analysis)
2. Desain basis data konseptual (Conceptual Database
Design)
3. Desain basis data logikal (Logical Database Design)

3 langkah berikutnya di luar cakupan desain ER:

4. Penghalusan skema (Schema Refinement)
5. Desain basis data fisik (Physical Database Design)
6. Desain aplikasi & sekuritas (Application and Security Design)
Contoh: Narasi Kebutuhan
Suatu perusahaan membutuhkan sebuah basis data guna mencatat semua data
pegawai, departemen, dan berbagai proyek yang ditanganinya. Penjelasan dari
sebagian data yang diperoleh setelah fase analisis dan pengumpulan kebutuhan adalah
seperti berikut:
1. Perusahaan terdiri dari sejumlah departemen, yang masing- masing mempunyai
sebuah nama dan nomor departemen yang unik. Setiap departemen dipimpin oleh
seorang pegawai yang bertindak sebagai manajer dari departemen tersebut. Untuk
ini perlu dicatat tanggal mulai kapan manajer tersebut diangkat. Sebuah
departemen dapat ditempatkan di lebih dari satu lokasi.
2. Sebuah departemen dapat mengendalikan sejumlah proyek. Setiap proyek
mempunyai sebuah nomor dan nama yang unik, serta mempunyai satu lokasi
tertentu.
3. Data pegawai yang perlu dicatat berupa nama, nomor pegawai, alamat, gaji, jenis
kelamin, dan tempat serta tanggal lahir. Seorang pegawai dipekerjakan di satu
departemen tertentu dan dapat dilibatkan dalam lebih dari satu proyek. Perlu
dicatat jumlah jam per minggu dari setiap pegawai yang terlibat dalam suatu suatu
proyek. Selain itu perlu juga dicatat pegawai yang menjadi supervisor langsung
dari sejumlah pegawai lainnya.
4. Untuk keperluan asuransi pegawai, maka perlu dicatat anggota keluarga dari setiap
pegawai. Data yang dicatat berupa nama anggota keluarga, tanggal lahir, jenis
kelamin, dan hubungan keluarga (sebagai isteri/suami atau anak).
Overview Desain Basis Data

Desain konseptual:
 entities dan relationships apa yang ada dalam suatu
perusahaan?
 Informasi apa dari entities dan relationships yang harus
disimpan dalam basis data?
 Integrity constraints dan business rules apa saja yang
harus diberlakukan?
 `skema’ basis data dalam ER Model dapat disajikan
dalam bentuk diagram (ER Diagram / ERD)
 ERD dapat dipetakan menjadi skema relasional
Notasi ERD
Dasar Dasar ER Model
• Entity : Objek dunia nyata yang dapat dibedakan secara unik dengan
objek-objek lainnya. Sebuah entity dijelaskan (dalam DB) dengan
menggunakan satu set attributes
• Entity Set : Sekumpulan entities yang sama.
Contoh : semua mahasiswa, semua mata kuliah
Semua entities dalam sebuah entity set mempunyai sekumpulan
attributes yang sama
Setiap entity mempunyai sebuah key (dapat lebih dari satu)
Setiap attribute mempunyai sebuah domain
Dasar Dasar ER Model

• Relationship : Assosiasi antara dua atau lebih entities

Contoh : Siti Works_in Information Systems Department
• Relationship Set: Sekumpulan relationship yang sama .
 Sebuah n relationship set R merelasikan n entity sets E1 ….EN; dimana setiap relationship dlm R
melibatkan entitas e1  E1, ..., en  En
 Entity set yang sama dpt berpartisipasi dlm sejumlah relationship sets yang berbeda, atau dlm “peran”
yang berbeda dlm suatu set yang sama.
 Key Constraints
• Perhatikan Works_In: Seorang
employees dapat bekerja dibanyak
departments; sebuah department
dapat mempunyai banyak
employees.
• Sebaliknya, setiap department
paling banyak mempunyai satu
manager, berdsarakan key
constraint pada relasi manages.
Relasi satu ke satu – 1 to 1
Relasi satu ke banyak – 1 to M
Relasi banyak ke satu – M to 1
Relasi banyak ke banyak – M to M
Contoh Relasi Unary
Contoh Relasi Binary
Contoh Relasi Ternary
Contoh Instance from “ Works_In” Relationship Set
Participation Constraint
Menentukan apakah keberadaan sebuah entitas tergantung pada hubungannya ke entitas lain
melalui jenis relasinya
Ada 2 jenis:
1. Partisipasi Total partisipasi pegawai dalam relasi “bekerja untuk”, memberikan arti
bahwa setiap data pada pegawai, harus direlasikan pada sebuah departemen. Atau tidak ada
data pegawai yang tidak berelasi dengan data departemen
2. Partisipasi sebagian partisipasi pegawai dalam relasi “mengepalai” terhadap departemen,
tidak setiap data pada pegawai dihubungkan dengan departemen dengan relasi ini. Atau tidak
semua pegawai mengepalai departemen
Participation Constraint (Cont’d)
– Apakah setiap department mempunyai seorang manager?
• Jika ya, hal ini menyatakan participation constraint: partisipasi dari Departments
dlm Manages adalah total, sedang partisipasi Employee dlm manages adalah
partial.
• Setiap nilai did dlm tabel Departments hrs muncul pada setiap baris dalam tabel
Manages (dengan nilai non-null ssn !)
 Weak Entities
– Sebuah weak entity dapat diidentifikasi secara unik hanya dengan memperhatikan key
dari entity lainnya (owner entity).
– Owner entity set dan weak entity set hrs berpartisipasi dlm sebuah one-to-many
relationship set (one owner, many weak entities).
– Weak entity set hrs mempunyai partisipasi total dalam
identifying relationship set.
 ISA (`is a’) Hierarchies
• Seperti dlm C++, Java, atau PL lainnya, attributes dpt diwariskan (inherited).
• Jika dideklarasi “A ISA B”, maka setiap entity A juga termasuk dlm entity B.
• Overlap constraints: Dapatkah Ali menjadi seorang Hourly_Emps dan
sekaligus juga sebagai seorang Contract_Emps entity? (Allowed/disallowed)
• Covering constraints: Apakah setiap Employees entity hrs juga menjadi
seorang Hourly_Emps atau seorang Contract_Emps entity? (Yes/no)
• Alasan pengunaan ISA:
– Utk menambah “descriptive attributes” yang berlaku secara spesifik utk sebuah
subclass tertentu.
– Utk mengidentifikasi entitities yang berpartisipasi dlm
sebuah relationship.
 Aggregation

– Digunakan bilamana harus memodel kan

sebuah relationship yang melibatkan
(entitity sets dan) relationship set.
– Aggregation Memungkinkan utk
memperlakukan sebuah relationship set
sebagai sebuah entity set utk tujuan
partisipasi dalam sejumlah relationships
(lainnya).
Aggregation v.s. ternary relationship:
Monitors adalah sebuah relationship,dengan sebuah descriptive
attribute. Dpt juga dikatakan bahwa setiap sponsorship di-monitor
oleh paling sedikit seorang employee.
Desain Konseptual Menggunakan ER Model
Pilihan-pilihan desain:
– Apakah sebuah konsep harus dimodelkan sebagai sebuah entity atau sebuah attribute ?
– Apakah sebuah konsep harus dimodelkan sebagai sebuah entity atau sebuah relationship
?
– Identifying relationship: Binary atau Ternary ? atau Aggregation?
• Constraints dalam ER Model:
– Sebanyak mungkin semantik dari data dituangkan dalam diagram ER
– Tetapi mungkin beberapa “constraints” tidak dapat digambarkan dalam digram
ER
 Entity v.s. Attribute
• Contoh, apakah address harus dimodelkan sebagai attribute dari entity Employee
atau sebagai sebuah entity (yang dihubungkan ke entity Employee oleh sebuah
relationship) ?
• Bergantung pada penggunaan informasi address yang diinginkan, dan juga semantik
dari data, maka salah satu dari alternatif berikut dapat digunakan:
• Jika untuk setiap Employee diperbolehkan memiliki sejumlah addresses, maka
address harus dimodelkan sebagai sebuah entity (karena sebuah attribute tidak
boleh memiliki banyak nilai / multi-valued)
• Jika struktur (city, street, dll.) dianggap penting, misalnya diinginkan utk
mencari (retrieve) data employee berdasarkan nama city, maka address harus
dimodelkan sebagai sebuah entity (karena nilai-nilai dari attribute harus atomic)
Entity v.s. Attribute (Cont’d)
• Works_In4 tidak membolehkan seorang “employee” utk bekerja di sebuah
“department” utk dua periode atau lebih
• Namun, jika diinginkan utk mencatat beberapa nilai dari sebuah “descriptive attribute”
utk setiap nilai dari sebuah relationship, maka sebuah entity baru Duration dapat
didefinisikan
Entity v.s. Relationship (Cont’d)
• ERD pertama OK, jika seorang manager diberikan kebijakan utk menentukan
budget (dbudget)yang terpisah utk setiap department yang dipimpinnya
• Bagaimana jika seorang manager diberikan kebijakan utk menentukan budget
yang meliputi semua dept yang dipimpinnya?
– Redundancy: dbudget yang disimpan untuk setiap dept yang dikelola
oleh seorang manager.
– Misleading: Menganjurkan dbudget untuk diasosiasikan dengan
kombinasi department-mgr
 Binary v.s. Ternary Relationships

• Jika setiap “policy” hanya dimiliki oleh 1 employee, dan setiap dependent dikaitkan
dengan policy tersebut, maka ERD petama kurang akurat!

• ERD kedua lebih baik. Constraints tambahan apa yang terdapat dalam ERD kedua?
Binary v.s. Ternary Relationships (Cont’d)
• Contoh sebelumnya mengilustrasikan sebuah kasus dimana dua buah binary
relationships adalah lebih baik daripada satu ternary relationship.
• Sebuah contoh untuk kasus sebaliknya: sebuah relasi ternary Contracts
merelasikan entity sets Parts, Departments dan Suppliers, and mempunyai attribut
deskriptif qty. Tidak ada kombinasi binary relationships yang pas untuk
menggantikannya:
– S “dpt-menyuplai” P, D “memerlukan” P, dan D “berbisnis” S
tdk mengimplikasikan bahwa D telah menyepakati untuk membeli P
dari S.
– Bagaimana attribut deskriptif qty harus dicatat dalam ERD?
 Rangkuman
• Desain Konseptual mengikuti analisis kebutuhan
Menghasilkan deskripsi tingkat tinggi (high-level) dari data yang akan disimpan dalam
basis data
• ER Model sangat populer untuk desain konseptual Konsepsinya sangat ekspresif,
dekat dengan cara
bagaimana orang berfikir mengenai hubungan antar data dari aplikasi-asplikasi mereka
• Konsepsi dasar: entities, relationships, dan attributes
(dari entities dan relationships).
• Beberapa konsepsi tambahan: weak entities, ISA hierarchies, dan aggregation.
• Catatan: terdapat banyak variasi dari ER model.
 Rangkuman
• Beberapa jenis integrity constraints dpt
dalam ER model:
dinyatakan key constraints, participation
constraints, dan overlap/covering constraints utk ISA
hierarchies. Beberapa foreign key constraints dapat juga
diimplikasikan dalam definisi sebuah relationship set.

• Beberapa (khususnya, functional

dependencies)
constraints tidak dapat dinyatakan dalam ER model
• Constraints memainkan peran penting dalam menentukan
desain basis data yang terbaik bagi suatu perusahaan
 Rangkuman
• Desain ER bersifat subyektif. Seringkali terdapat banyak cara untuk
memodelkan sebuah skenario! Alternatif-alternatif desain
memerlukan kecerdikan, khususnya untuk suatu perusahaan besar.
Beberapa pilihan yang umum meliputi:
• Entity v.s. attribute, entity v.s. relationship, binary atau tenary
relationship, perlu atau tidak untuk menggunakan ISA hierarchies,
dan perlu atau tidak untuk menggunakan aggregation?
• Jaminan desain basis data yang baik: skema relasional yang
dihasilkan harus dianalisis dan disempurnakan lebih lanjut. Untuk
ini, informasi Functional Dependencies dan teknik normalisasi
data menjadi penting untuk digunakan!
 Referensi

• Muhammad Haris, Gregory Shakhnarovich, Norimichi Ukita;

• https://openaccess.thecvf.com/content_
cvpr_2018/html/Haris_Deep_Back-
Projection_Networks_CVPR_2018_paper.html,
• https://jurnal- ppi.kominfo.go.id/index.php/jppi/article/view/
341
Terima Kasih