Desain Database
Kompetensi Dasar
1. menjelaskan konsep dan pengertian desain database pada Microsoft
Access dengan baik
Menjelaskan konsep dan pengertian desain database dengan metode top down Menjelaskan konsep dan pengertian desain database dengan metode bottom up menjelaskan proses desain database dengan baik
2. mendesain database dengan baik
Mendesain database pada tahap pengumpulan requirement dan analisis Mendesain database pada tahap pembuatan conceptual database design Mendesain database pada tahap pemilihan DBMS
Mendesain database pada tahap data model mapping/pembuatan logical database
design
Mendesain database pada tahap pembuatan physical database design Mendesain database pada tahap implementasi system database
Kompetensi Dasar
3. menerapkan normalisasi database dalam mendesain database
dengan baik
Menjelaskan teori normalisasi Database Menjelaskan tujuan normalisasi database Menerapkan teknik normalisasi database
Menjelaskan anomali pada proses normalisasi database
menerapkan key database dalam mendesain database dengan baik Menjelaskan pengertian key
Menerapkan macam-macam key
4. menggunakan komponen database dalam mendesain database
dengan baik Menggunakan Table Menggunakan Query Menggunakan Form Menggunakan Report Menggunakan Macro Menggunakan Module Dr. Khamami Herusantoso
Agenda
Database planning
System definition
Requirement collection & analysis
Database planning System definition
Requirement collection & analysis
Conceptual db design Logical db design Physical db design
Implementation
Data conversion & loading Testing Operational maintenance Application design DBMS selection (opt) Prototyping (opt) Db Design DB System Development Lifecycle
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
(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
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
(ii) Mission Objectives
Setiap sasaran misi hendaknya dapat
mengiden-tifikasi tugas tertentu yg harus didukung oleh database
Example: Mission Objectives for DreamHome Database System
Database planning System definition
Requirement collection & analysis
Conceptual db design Logical db design Physical db design
Implementation
Data conversion & loading Testing Operational maintenance Application design DBMS selection (opt) Prototyping (opt) Db Design
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,
Example: System Boundary for
Database planning System definition Requirement collection & analysis Conceptual db design Logical db design Physical db design Implementation
Data conversion & loading Testing Operational maintenance Application design DBMS selection (opt) Prototyping (opt) Db Design
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
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.
19/107
Database planning System definition Requirement collection & analysis Conceptual db design Logical db design Physical db design Implementation
Data conversion & loading Application design DBMS selection (opt)
Prototyping (opt)
Database Design
Proses untuk membuat sebuah rancangan
database yang akan mendukung mission
statement dan mission objective perusahaan
Approach:
Bottom-up Top-down
Bottom-Up and Top-Down
Approach
Sumber data (laporan, form dll) Unnormalized Form (UNF) ubah ke format tabel Bentuk normal pertama (1NF) hilangkan ketergantungan parsial Bentuk normal tahap kedua (2NF) hilangkan ketergantungan transitif Bentuk normal tahap ketiga (3NF) hilangkan group berulang Diagram ER Dunia Nyata buat diagram ER petakan ke tabelDatabase 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
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
Contoh: Perancangan Database
Bottom-up (lanjutan)
Dikelompokkan kedalam tiga jenis entitas (dengan
proses normalisasi) Pegawai (atribut 1 dan
ke-2), Unit (atribut ke-3 dan ke-4), dan Atasan (atribut ke-5 dan ke-6)
Entitas-entitas tersebut menjadi tabel
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
Contoh: Perancangan Database
Top-Down
dip
ec
ah
NIP Nama NamaUnit
Pegawai NIP Nama NoUnit Unit NamaUnit NoUnit Pegawai Bekerja Dr. Khamami Herusantoso
Database planning System definition Requirement collection & analysis Conceptual db design Logical db design Physical db design Implementation
Data conversion & loading Application design DBMS selection (opt)
Prototyping (opt)
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
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
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.
conceptual DB design
Logical DB design
buat diagram ER
Bottom-Up and Top-Down
Approach
Sumber data (laporan, form dll) Unnormalized Form (UNF) ubah ke format tabel Bentuk normal pertama (1NF) hilangkan ketergantungan parsial Bentuk normal tahap kedua (2NF) hilangkan ketergantungan transitif Bentuk normal tahap ketiga (3NF) hilangkan group berulang Diagram ER Dunia Nyata petakan ke tabelPengantar Penyempurnaan Skema:
Persoalan yang Ditimbulkan oleh
Redundansi
Redundansi ruang penyimpanan: beberapa data disimpan secara berulang
Update anomaly: Jika satu copy data terulang tsb diubah, inkonsistensi data dpt terjadi kecuali kalau semua copy dari data tsb diubah dengan cara yang sama
Insertion anomaly: Mungkin dpt terjadi kesulitan utk
menyisipkan data tertentu kecuali kalau beberapa data tidak terkait lainnya juga ikut disisipkan
Deletion anomaly: Mungkin dpt terjadi kesulitan utk
menghapus data tertentu tanpa harus kehilangan beberapa data tidak terkait lainnya
Persoalan yang Ditimbulkan oleh
Redundansi: Contoh
Redundansi ruang penyimpanan: Pelaksana yang berkorespondensi dg
grading 15 diulang dua kali
Update anomaly: Nilai Jabatan (yg terkait dengan nilai grading) dlm baris
pertama dpt diubah tanpa membuat perubahan yg sama pada baris kedua
Insertion anomaly: Kesulitan utk menyisipkan pegawai baru kecuali nilai
grading untuk jabatan dari pegawai tsb sudah diketahui
Deletion anomaly: Jika semua baris yang terkait dg nilai jabatan tertentu
dihapus (misalnya baris utk pegawai ‘Yono’ dihapus), maka kita akan
kehilangan informasi ketergantungan antara nilai jabatan dan nilai grading yang diasosiasikan dengan nilai rating tsb (yaitu jabatan = Kepala Bidang dan grading = 20)
NIP Nama Jabatan Grading
1001 Yana Kepala Pusat 23
1002 Yani Kepala Pusat 23
1003 Yono Kepala Bidang 20
1004 Yuni Pelaksana 15
Penyebab Anomali
Mengapa anomali - anomali ini terjadi ?
Karena menggabungkan dua tema (konsep entitas) dalam satu
relasi. Ini mengakibatkan duplikasi – duplikasi sebagai akibat dari ketergantungan antar atribut yang tidak pada tempatnya.
Normalisasi
Normalisasi adalah proses pembentukan struktur
database sehingga sebagian besar ambiguity bisa dihilangkan.
Tahap Normalisasi dimulai dari tahap paling ringan
(1NF) hingga paling ketat (5NF)
Biasanya hanya sampai pada tingkat 3NF atau
BCNF karena sudah cukup memadai untuk
Normalisasi
Sebuah tabel dikatakan baik (efisien) atau normal jika memenuhi 3 kriteria sbb:
1. Jika ada dekomposisi (penguraian) tabel, maka
dekomposisinya harus dijamin aman (Lossless-Join
Decomposition). Artinya, setelah tabel tersebut diuraikan / didekomposisi menjadi tabel-tabel baru, tabel-tabel baru tersebut bisa menghasilkan tabel semula dengan sama persis.
2. Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation).
Normalisasi
Jika kriteria ketiga (BCNF) tidak dapat terpenuhi, maka paling tidak tabel tersebut tidak melanggar Bentuk Normal tahap ketiga (3rd Normal Form / 3NF).
Tabel Universal
Tabel Universal (Universal / Star Table) sebuah tabel yang merangkum semua kelompok data
yang saling berhubungan, bukan merupakan tabel yang baik.
Tabel Universal
NIP Nama No_klien Nama_klien
037 Nina K05 Martini K08 Anton K02 Sarmini 038 Tono K04 Eka K10 Andin 039 Hadi K06 Mitha K24 Buyung K90 Indah
Functional Dependency
Notasi: A B
A dan B adalah atribut dari sebuah tabel. Berarti secara fungsional A menentukan B atau B
tergantung pada A, jika dan hanya jika ada 2 baris data dengan nilai A yang sama, maka nilai B juga sama
• Notasi: A B atau A x B
Functional Dependency
Contoh tabel pemasok
Kode Nama_Brg Harga Kd_Pemasok Nm_Pemaso
k Kota T-001 TV SN 14” 600.000 P22 PT Sumber Jakarta T-002 TV SN 21” 950.000 P22 PT Sumber Jakarta T-003 TV SS 14” 450.000 P11 PT Tunas Jaya Surabaya T-004 TV M 34” 4.500.000 P33 PT Mekar Semarang
Berdasarkan tabel tersebut, diperoleh: Kode Nama_Brg Kode Harga Kode Kd_Pemasok Kode Nm_Pemasok Kd_Pemasok Nm_Pemasok
Setiap Kode pasti berhubungan dengan satu Nama_Brg begitu juga antara Kode dan Harga. Begitu seterusnya.
Misalnya: T-001 hanya cocok dengan 1 barang, yaitu TV SN 14” Catatan: Bagaimana kalau dibalik?
Harga tidak menentukan barangnya, (karena banyak barang mempunyai harga yang sama); tapi satu jenis barang punya satu harga.
Nama_Brg Kode
Nm_Pemasok Kode_Pemasok
Perhatikan bagian ini: Kode Nama_Brg Kode Harga Kode Kd_Pemasok Kode Nm_pemasok Kd_Pemasok Nm_Pemasok
Ternyata, Kode menentukan lebih dari satu atribut. Notasinya dapat diganti sebagai berikut:
Kode {Nama_Brg, Harga, Kd_Pemasok}
Bentuk-bentuk Normal
1. Bentuk Normal Tahap Pertama (1st Normal Form
/ 1NF)
2. Bentuk Normal Tahap Kedua (2nd Normal Form /
2NF)
3. Bentuk Normal Tahap (3rd Normal Form / 3NF)
4. Boyce-Code Normal Form (BCNF)
5. Bentuk Normal Tahap (4th Normal Form / 4NF)
Bentuk Normal Tahap Pertama
(1st Normal Form / 1NF)
Bentuk normal 1NF terpenuhi jika sebuah tabel
tidak memiliki atribut bernilai banyak (multivalued attribute), atribut composite atau kombinasinya dalam domain data yang sama.
Setiap atribut dalam tabel tersebut harus bernilai
Data Tidak Ternormalisasi
NIP Nama No_klien Nama_klien
037 Nina K05 Martini K08 Anton K02 Sarmini 038 Tono K04 Eka K10 Andin 039 Hadi K06 Mitha K24 Buyung K90 Indah
Data 1NF
NIP Nama No_klien Nama_klien
037 Nina K05 Martini 037 Nina K08 Anton 037 Nina K02 Sarmini 038 Tono K04 Eka 038 Tono K10 Andin 039 Hadi K06 Mitha 039 Hadi K24 Buyung 039 Hadi K90 Indah
Contoh 2 (composite)
JadwalKuliah
Kodekul NamaKul Dosen Kelas Jadwal
Kodekul NamaKul Dosen Kelas JadwalHari JadwalJam
• Dimana nilai pada atribut jadwal berisi gabungan antara Hari dan Jam.
• Jika asumsi hari dan jam memegang peranan penting dalam sistem database, maka atribut Jadwal perlu
dipisah sehingga menjadi JadwalHari dan JadwalJam sbb:
Bentuk Normal Tahap Kedua
(2nd Normal Form)
Bentuk normal 2NF terpenuhi dalam sebuah tabel
jika telah memenuhi bentuk 1NF, dan semua atribut selain primary key, secara utuh memiliki Functional Dependency pada primary key
Sebuah tabel tidak memenuhi 2NF, jika ada atribut
yang ketergantungannya (Functional Dependency) hanya bersifat parsial saja (hanya tergantung pada sebagian dari primary key)
Jika terdapat atribut yang tidak memiliki
ketergantungan terhadap primary key, maka atribut tersebut harus dipindah atau dihilangkan
Contoh
Tabel berikut memenuhi 1NF tapi tidak termasuk 2NF:
NIM Nama Alamat Mk_kode mk_nama mk_sks nihuruf
• Tidak memenuhi 2NF, karena {NIM, mk_kode} yang dianggap sebagai primary key sedangkan:
{NIM, mk_kode} mhs_nama {NIM, mk_kode} mhs_alamat {NIM, mk_kode} mk_nama {NIM, mk_kode} mk_sks
{NIM, mk_kode} nihuruf
• Tabel di atas perlu didekomposisi menjadi beberapa tabel yang memenuhi syarat 2NF
Contoh
Functional dependencynya sbb:
{NIM, mk_kode} nihuruf (fd1)
NIM {mhs_nama, mhs_alamat} (fd2)
Mk_kode {mk_nama, mk_sks} (fd3)
fd1 (NIM, mk_kode, nihuruf) Tabel Nilai
fd2 (NIM, mhs_nama, mhs_alamat) Tabel Mahasiswa fd3 (mk_kode, mk_nama, mk_sks) Tabel MataKuliah
Bentuk Normal Tahap Ketiga
(3rd Normal Form /3NF)
Bentuk normal 3NF terpenuhi jika telah
memenuhi bentuk 2NF, dan jika tidak ada atribut non primary key yang memiliki ketergantungan terhadap atribut non primary key yang lainnya.
Contoh
Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF:
NIP Nama Alm_Jalan Alm_Kota Alm_Provinsi Alm_Kodepos Pegawai
karena masih terdapat atribut non primary key (yakni alm_kota dan alm_Provinsi) yang memiliki ketergantungan terhadap atribut non primary key yang lain (yakni alm_kodepos):
alm_kodepos {alm_Provinsi, alm_kota}
Sehingga tabel tersebut perlu didekomposisi menjadi: