Desain Fisik Basis Data

Yusuf Priyandari

@Agustus 2010

2

Contents

Click to add Title1

Click to add Title2

Click to add Title3

Click to add Title4

pri.and.ari@2010

3

Tahap Pengembangan Basis Data

Model

pri.and.ari@2010

1

2

3

4 5

6 7

1

Topics discussed

4

Database Design Methodology

pri.and.ari@2010

Topics discussed

5

Introduction

Physical database design adalah tahap transformasi

struktur basis data yang berbentuk logikal ke dalam tabel-

tabel basis data menggunakan aplikasi DBMS.

Meskipun dalam tahapan ini fokus pada implementasi

desain basis data ke dalam DBMS, namun dimungkinkan

adanya proses feedback kembali ke proses-proses

sebelumnya.

Transformasi logikal desain basis data menjadi fisikal basis

data memerlukan pemahaman tentang spesifikasi berbagai

kemampuan aplikasi DBMS, misalkan bagaimana membuat

tabel2, apakah mendukung konsep relasional, tipe data apa

yang didukung, berapa kapasitas yang dimiliki, dll

pri.and.ari@2010

6

1. Design Base Tables

Satukan dan pahami informasi tabel yang telah dibuat dalam

logikal basis data yang terdapat dalam kamus data/definisi tabel .

Untuk setiap tabel, pastikan terdapat informasi:

Nama tabel

Daftar fields

Primary key, alternate key, dan foreign key

Batasan Integritas referensial untuk setiap FK

Untuk setiap field, pastikan terdapat informasi:

Domain field: tipe data, size, dan batasan lainnya.

Nilai default untuk field

Apakah field boleh bernilai null.

Apakah field berupa field turunan, dan bagaimana menyusunnya.

pri.and.ari@2010

7

1. Design Base Tables

Contoh:

Selanjutnya, buatlah tabel-tabel basis data ke dalam

DBMS.

Gunakan aplikasi yang memiliki GUI jika belum memahami

benar penggunaan SQL dalam pembuatan basis data.

pri.and.ari@2010

8

1. Design Base Tables

pri.and.ari@2010

9

1. Design Base Tables

Jangan lupa untuk membangun relasinya, khususnya jikamenggunakan RDBMS dan dipertimbangkan untukmempertahankan relasi di dalam struktur basis data.

Pada prinsipnya, adanya integritas relasi dalam struktur basis data yang dimasukkan dalam RDBMS tidak selalu diperlukan, yang terpenting strukturnya sudah mendukung adanya model relasi.

Pembuatan relasi dalam sejumlah aplikasi RDBMS tercermindalam pembuatan foreign key, baik melalui sintaks SQL, GUI, dan GUI with drag and drop facility.

.

pri.and.ari@2010

10

2. Design Representation of

Derived Data

pri.and.ari@2010

Terdapat sejumlah atribut turunan seperti usia, lama kerja, dan jumlahpinjaman yang telah dilakukan seorang pelanggan.

Atribut ini diturunkan dari field data yang telah ada, misal masa kerjadiperoleh dari selisih waktu kini dikurangi mulai kerja.

Atribut turunan

pada prinsipnya

dapat ditampilkan

dengan dua cara:1. Menggunakan

tabel query.

.

11

2. Design Representation of

Derived Data

pri.and.ari@2010

.

2. Menambahkan sebuah field yang menyimpan data atribut

turunan tersebut.

• Misal, atribut masa kerja disimpan menjadi 1 atau 2 field di

tabel staff. tidak relevan karena frekuensi penggunaan

informasi ini sangat rendah.

• Misal, atribut jumlah pinjaman seorang pelanggan. Atribut ini

untuk melihat apakah seorang pelanggan telah mencapai

maksimum peminjaman (kerena misalkan maksimum sekali

pinjam adalah 5 buah). frekuensi penggunaan informasi ini

sangat sering sehingga boleh saja dibuatkan field sendiri.

Sehingga setiap kali pelanggan menambah peminjaman, maka

sell field tersebut di update.

.

12

3. Design Remaining Business Rules

pri.and.ari@2010

Aturan-aturan yang berkaitan dengan proses bisnis dapat

diimplementasikan dalam dua bentuk:

1. Menggunakan program tersendiri di interface.

• Misal, untuk membatasi seorang pelanggan maksimum

meminjam 5 buah, maka di dalam desain interface dibuatkan

program untuk mengecek terlebih dahulu jumlah peminjaman,

sebelum dieksekusinya proses peminjaman.

• Misal, menjamin data yang dimasukkan adalah tanggal untuk

data bertipe tanggal

2. Menggunakan trigger yang terdapat di DBMS.

• Namun tidak semua DBMS mendukung penggunaan trigger.

Check terlebih dahulu kapabilitas DBMS yang digunakan.

13

4. Analisis Transaksi dan Pengindekan

pri.and.ari@2010

Perancangan fisik basis data sangat memerlukan

pemahaman mengenai transaksi yang akan didukung oleh

basis data.

Hal-hal yang perlu dipamahi kembali antara lain:

Frekuensi transaksi yang berjalan dan akan terjadi

kedepannya.

Transaksi yang kritis bagi bisnis perusahaan

Waktu-waktu dimana terjadi peningkatan transaksi

14

4.1 Analisis Transaksi

pri.and.ari@2010

1. Petakan Transaksi ke dalam tabel (rangkuman Chptr.9)

Proses ini menghasilkan informasi, tabel-tabel mana saja yang terlibatdalam suatu transaksi.

15

4.1 Analisis Transaksi

pri.and.ari@2010

2. Estimasikan frekuensi transaksi.

Proses ini menghasilkan informasi transaksi mana yang sangat pentinguntuk dicermati sungguh-sungguh (terkait frekuensi transaksi).

16

4.1 Analisis Transaksi

pri.and.ari@2010

2. Susun Dokumen Analisis Transaksi.

Untuk tiap transaksi, identifikasi:

Tabel dan field yang diakses, dan tipe akses yang dilakukan

(insert, update, delete, atau retrieval). Untuk update,

perhatikan field yang bertindak sebagai key yang tidak boleh

diupdate.

Fields yang digunakan untuk suatu pencarian. Identifikasi

pula kondisi pencarian.

Untuk query, identifikasi tabel dan field yang terlibat.

• Kondisi query, fields untuk pengurutan, pengelompokan, fungsi

penjumlahan, dll

Frekuensi kejadian transaksi dalam suatu waktu

17

4.1 Analisis Transaksi

pri.and.ari@2010

2. Susun Dokumen Analisis Transaksi.

18

4.2 Menentukan Indeks

pri.and.ari@2010

Pembuatan indek untuk beberapa field tertentu berguna

untuk mempercepat proses pencarian atau transaksi.

Indeks adalah salah satu bentuk metode pengorganisasian

record.

Indek umumnya diberikan untuk:

Field yang sangat sering diakses untuk operasi

penggabungan.

Field yang sering dijadikan acuan pengurutan data.

19

4.2 Menentukan Indeks

pri.and.ari@2010

Panduan menentukan indeka. Jangan memberikan indek pada tabel yang kecil. Dimungkinkan

pencarian lebih efisien bila tanpa indek untuk tabel yang kecil.

b. Secara umum, buatlah indek untuk primary. Although the SQL standard provides a clause for the specification of primary keys as discussed in Step 3.1 covered in the last chapter, note that this does not guarantee that the primary key will be indexed in some RDBMSs.

c. Buat indek untuk fields yang banyak dipakai dalam data retrieval. Misal, buatlah index untuk tabel Member bagi field lname (last name).

d. Buat index untuk sebuah foreign key jika ia sering diakses. Misal, sering dilakukan query penggabungan tabel VideoItem dengan Branch pada field branchNo (the branch number). Sehingga, mungkin lebihefisien menambahkan index di tabel VideoItem untuk branchNo.

20

4.2 Menentukan Indeks

pri.and.ari@2010

Panduan menentukan indek

e. Buat index untuk field yang sering terlibat dalam:

a. selection or join criteria;

b. ORDER BY;

c. GROUP BY;

d. Operasi lain seperti UNION or DISTINCT.

f. Buat index bagi field yang dipakai untuk fungsi built-in

functions. Misal, membuat index salary.

21

4.2 Menentukan Indeks

pri.and.ari@2010

Panduan menentukan indek

g. Hindari membuat index bagi field yang sering di update.

h. Hindari membuat index bagi suatu field apabila proses

retrieval data menampilkan lebih dari 25% dari jumlah

record. Meskipun data yang tersimpan sangat besar.

i. Hindari membuat index bagi field yang berisi data string

berukuran besar.

22

4.2 Menentukan Indeks

pri.and.ari@2010

Indes tambahan untuk StayHome

23

4.2 Menentukan Indeks

pri.and.ari@2010

Indes tambahan untuk StayHome

24

4.2 Desain User View

pri.and.ari@2010

Desain user view dapat dilakukan tanpa harus

membuatnya menggunakan aplikasi tambahan seperti VB,

PHP dll.

Desain user view dapat dibuat dengan menggunakan

query.

Ada beberapa bentuk umum user view:

a. Form tampilan data di aplikasi nantinya.

b. Form laporan (reports) yang nantinya akan dicetak (print)

c. Form input/update/pencarian data.

Dari ketiga bentuk user view tersebut, pada umumnya

aplikasi RDBMS hanya mendukung untuk pembuatan a

dan b. Bagian c harus dibuat dengan aplikasi lain.

25

4.2 Desain User View

pri.and.ari@2010

Daftar karyawan StayHome, diurutkan berdasarkan kantor

cabang

26

4.2 Desain User View

pri.and.ari@2010

Daftar transaksi peminjaman di sebuah cabang.

27

4.2 Desain User View

pri.and.ari@2010

Daftar Karyawan.

28

Diskusi

pri.and.ari@2010

29

Tugas Mandiri

Baca buku [1] chapter 15

pri.and.ari@2010