107

Desain Database

Dr. Khamami Herusantoso

1/107

Kompetensi Dasar 1.   2.

       

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 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 melakukan tahapan model entity-relationship dalam mendesain database dengan baik


2/107

Kompetensi Dasar 3.

4.

            

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

menggunakan komponen database dalam mendesain database dengan baik Menggunakan Table Menggunakan Query Menggunakan Form Menggunakan Report Menggunakan Macro Menggunakan Module


3/107

Agenda  Database planning  System definition

 Requirement collection & analysis  Database design


4/107

Database planning System definition Requirement collection & analysis

DB System Development Lifecycle

Db Design DBMS selection (opt)

Conceptual db design Logical db design

Application design

Physical db design Prototyping (opt)

Implementation Data conversion & loading Testing


Operational 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


6/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


7/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


8/107

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

tifikasi tugas tertentu yg harus didukung oleh database


9/107

Example: Mission Objectives for DreamHome Database System


10/107




Application design


Implementation Data conversion & loading Testing



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


12/107

Example: System Boundary for DreamHome Database System


13/107

Contoh: User View


14/107




Application design


Implementation Data conversion & loading Testing Dr. Khamami Herusantoso


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


16/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

17/107

Requirement & Specification Doc


18/107

Requirement & Specification Doc


19/107




Application design




Database Design  Proses untuk membuat sebuah rancangan

database yang akan mendukung mission statement dan mission objective perusahaan

 Approach:  Bottom-up  Top-down


21/107

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

Dunia Nyata

Unnormalized ubah ke format tabel Form (UNF)

Bentuk normal tahap ketiga (3NF)

buat diagram ER hilangkan group berulang

Bentuk hilangkan normal tahap ketergantungan kedua (2NF) transitif

hilangkan ketergantungan parsial

Diagram ER petakan ke tabel Bentuk normal pertama (1NF)

22/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


23/107

Contoh: Perancangan Database Bottom-up

 Kumpulan atribut: NIP, Nama, NoUnit, NamaUnit,

NIPAtasan, Nama Atasan NIP

Nama

NoUnit

002

Yudo

01

001 003 004 005 006


Budi Tuti

Yono Yeni

Yudi

NamaUnit NIPAtasan

NamaAtasan

01

Setjen

006

Yudi

02

BPPK

004

Yono

02 03 01

Setjen BPPK DJP

Setjen

006 008 009

010

Yudi Yani

Yuni

Yana

24/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


25/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


26/107

Contoh: Perancangan Database TopDown NIP

Nama

NamaUnit

NoUnit

NIP

dipecah

Pegawai

Nama

Pegawai Dr. Khamami Herusantoso

NamaUnit Bekerja

NoUnit Unit 27/107




Application design




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


29/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


30/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


31/107

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

Dunia Nyata

Unnormalized ubah ke format tabel Form (UNF)

Bentuk normal tahap ketiga (3NF)

buat diagram ER hilangkan group berulang

Bentuk hilangkan normal tahap ketergantungan kedua (2NF) transitif

conceptual DB design

hilangkan ketergantungan parsial

Logical DB design

Diagram ER

petakan ke tabel

Bentuk normal pertama (1NF)

Physical DB Design 32/107

Normalisasi Database

33/107

Pengantar 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

34/107

Persoalan yang Ditimbulkan oleh Redundansi: Contoh NIP 1001 1002 1003 1004 1005

Nama Yana Yani Yono Yuni Yuno

Jabatan Kepala Pusat Kepala Pusat Kepala Bidang Pelaksana Pelaksana

Grading 23 23 20 15 15

 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) 35/107

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.

Solusi : Normalisasi

36/107

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 menghasilkan tabel-tabel yang berkualitas baik.

37/107

Normalisasi Sebuah tabel dikatakan baik (efisien) atau normal jika memenuhi 3 kriteria sbb: 1.

2. 3.

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. Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation). Tidak melanggar Boyce-Code Normal Form (BCNF) (-akan dijelaskan kemudian-) 38/107

Normalisasi Jika kriteria ketiga (BCNF) tidak dapat terpenuhi, maka paling tidak tabel tersebut tidak melanggar Bentuk Normal tahap ketiga (3rd Normal Form / 3NF).

39/107

Langkah – Langkah Normalisasi

40/107

Tabel Universal Tabel Universal (Universal / Star Table)  sebuah tabel yang merangkum semua kelompok data yang saling berhubungan, bukan merupakan tabel yang baik. Misalnya:

41/107

Tabel Universal NIP

037

Nina

Nama

No_klien

K05

Martini

K08

Anton Eka

K02

038

Tono

K04

039

Hadi

K06

Sarmini

K10

Andin

K24

Buyung

K90

Nama_klien

Mitha

Indah

42/107

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 Adalah kebalikan dari notasi sebelumnya.

43/107

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-003

TV SS 14”

450.000

P11

PT Tunas Jaya

Surabaya

T-002 T-004 T-005

TV SN 21” TV M 34” TV S 24”

950.000 4.500.000 1.200.000

P22 P33 P44

PT Sumber

PT Mekar PT Holic

Jakarta

Semarang

Semarang 44/107

Dependensi Fungsional 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 45/107

Dependensi Fungsional  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}  Kode  Nm_Pemasok (yang ini bagaimana?) 46/107

Bentuk-bentuk Normal

1. 2. 3. 4. 5. 6.

Bentuk Normal Tahap Pertama (1st Normal Form / 1NF) Bentuk Normal Tahap Kedua (2nd Normal Form / 2NF) Bentuk Normal Tahap (3rd Normal Form / 3NF) Boyce-Code Normal Form (BCNF) Bentuk Normal Tahap (4th Normal Form / 4NF) Bentuk Normal Tahap (5th Normal Form / 5NF)

47/107

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 atomic (tidak dapat dibagi-bagi lagi)

48/107

Data Tidak Ternormalisasi NIP

037

Nina

Nama

No_klien

K05

Martini

K08

Anton Eka

K02

038

Tono

K04

039

Hadi

K06

Sarmini

K10

Andin

K24

Buyung

K90

Nama_klien

Mitha

Indah

49/107

Data 1NF NIP

037

Nina

037

Nina

037 038 038 039 039 039

Nina Tono Tono Hadi Hadi Hadi

Nama

No_klien

K05

Martini

K02

Sarmini

K08 K04 K10

K06 K24 K90

Nama_klien

Anton Eka

Andin Mitha

Buyung Indah

50/107

Contoh 2 (composite) JadwalKuliah Kodekul

NamaKul

Dosen

Kelas

Jadwal

• 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: JadwalKuliah Kodekul

NamaKul

Dosen

Kelas

JadwalHari

JadwalJam 51/107

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 52/107

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 53/107

Contoh Functional dependencynya sbb:

{NIM, mk_kode}  nihuruf (fd1) NIM  {mhs_nama, mhs_alamat} (fd2) Mk_kode  {mk_nama, mk_sks} (fd3)

fd1 fd2 fd3

(NIM, mk_kode, nihuruf) (NIM, mhs_nama, mhs_alamat) (mk_kode, mk_nama, mk_sks)

 Tabel Nilai  Tabel Mahasiswa  Tabel MataKuliah

54/107

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.

55/107

Contoh Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF: Pegawai NIP

Nama

Alm_Jalan

Alm_Kota

Alm_Provinsi Alm_Kodepos

 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:

Pegawai (NIP, nama, alm_jalan, alm_kodepos) Kodepos (alm_kodepos, alm_provinsi, alm_kota) 56/107

107

Recommend Documents