Relational Database Design

Relational Database Design Oleh: Alberta P. Makur Rahanti Natalia 1

Pengantar • Dalam bab ini akan dibahas tentang masalah design database relational. • Pada umumnya, tujuan dari design database relational adalah untuk membangun sebuah himpunan dari relasi skema sehingga kita bisa menyimpan informasi tanpa kerancuan, dan kita bisa mengambil data dengan mudah.

2

• Pendekatan pertama yaitu : desain skema dalam bentuk normal. • Dalam bab ini, kita akan mendefine normal form menggunakan functional dependencies dan type2 lain dari ketergantungan data.

3

6.1 Pitfalls in RelationalDatabase Design • Sebelum mulai, kita akan melihat kesalahan2 apa yang akan terjadi pada design database yang tidak baik, dimana : • pengulangan informasi • Ketidakmampuan untuk menampilkan beberapa info. 4

• Untuk contoh, kita akan menggunakan skema relasi yang digunakan di bab2 sebelumnya, yaitu iformasi tentang loan/pinjaman yang sekarang disimpan di 1 relasi, lending, yaitu : Lending-schema = (branch-name, branch-city, assets, customer-name, loan-number, amount) Tabel 6.1.doc

5

• Tabel 6.1 menunjukan contoh dari relasi lending. Tuple-t dalam relasi lending mempunyai arti secara intuitive sebagai berikut: – t[assets] adalah tabel asset dari branch-name t[branch-name] – t[branch-city] adalah kota dimana branch-name t[branch-name] berada – t[loan-number] adalah nomor loan yang menunjuk ke setiap pinjaman yang dibuat oleh t[branch-name] pada customer name t[customer-name]

6

– t[amount] adalah jumlah pinjaman dari seseorang yang loan-numbernya t[loan-number]

 Misalkan kita ingin menambahkan loan baru di database kita, misalkan: Loan baru dibuat oleh cabang Perryridge pada Adams, dengan jumlah $1500, loan-number L31. Maka:

7

• Kita harus menambahkan tuple: (Perryridge, Horseneck, 1700000, Adams,

L-31, 1500) ke Lending-Schema. Jadi, secara umum, data asset dan city untuk setiap cabang harus mucul ketika setiap pinjaman dibuat oleh branch.

8

 Pengulangan informasi yang terjadi di alternatif tabel ini-lah yang tidak kita inginkan untuk terjadi, sebab bisa mempersulit proses pengupdate-an database.  Contoh :

Misalnya cabang Perryridge pindah dari Horseneck ke Newtown. Dalam design original kita, satu tuple dari relasi branch perlu diubah. Sedangkan dalam alternative design kita, banyak tuple dari relasi lending yang perlu diubah. Jadi untuk mengupdate database dalam relasi lending lebih repot daripada kita mengupdate database dalam design original kita.

9

• Masalah lainnya : – Kita tidak bisa menampilkan secara langsung informasi tentang cabang ( branch-name, branch-city, asset) Kecuali, setidaknya ada satu pinjaman yang dibuat di salah satu cabang Hal ini terjadi karena relasi lending butuh nilai dari loan-number, amount, dan customer-name.

10

• Solusinya, yaitu dengan memperkenalkan null values untuk mengatasi masalah pengupdatean, dimana null values ini juga sulit untuk diatasi • Jika kita tidak ingin menggunakan null values, maka informasi tentang cabang hanya bisa dibuat ketika pinjaman pertama dibuat di cabang tersebut • Lebih buruknya, kita harus menghapus semua informasi ini ketika semua pinjaman sudah lunas • Pada original design informasi tentang cabang bisa tersedia tanpa atau dengan pinjaman pertama harus dibuat terlebih dahulu di bank, dan tanpa menggunkaan null values.

11

Decomposition • Tabel 6.1 adalah contoh relasi yang tidak baik, sehingga kita harus membagi sebuah relasi skema yang mempunyai banyak atribut menjadi beberapa skema dengan atribut yang lebih sedikit • Sekarang, kita akan membagi alternativ design kita ( Lending-relation), menjadi 2 skema yaitu skema brach customer dan skema customerloan, dengan menuliskan : 12

• Branch-customer = ∏ brach-name,brach-city,assets,customername (lending) stomer-name, loan-number, • customer-loan = cu∏ amount (lending) Tabel 6.2& Tabel 6.3.doc • Namun, ada beberapa kasus dimana kita harus merekonstruksi relasi loan, contoh: misalnya kita ingin menemukan semua cabang yang mempunyai loan dengan jumlah < $1000.

13

• Terlihat bahwa tidak ada relasi yang berisi data ini berdasarkan tabel 6.2 dan 6.3, sehingga kita harus merekonstruksi relasi lending, dengan cara: • Branch-customer |x| customer-loan

Tabel 6.4.doc

• Ada perbedaan antara tabel 6.1 dan tabel 6.4, dimana setiap tuple yang muncul di tabel 6.1 ada di tabel 6.4, tapi ada tuple2 di tabel 6.4 tidak ada di tabel 6.1 , yaitu:

14

• • • •

(Dowtown, Brooklyn, 9000000, Jomes, L-93) (Perryridge, Horseneck, 1700000, Hayes, L-16, 1300) (Mianus, Horseneck, 400000, Jones, L-17, 1000 ) (North Town, Rye, 3700000, hayes, L-15, 1500)

Perhatikan Query: Temukan semua cabang yang telah membuat pinjaman dalam jumlah kurang dari $1000 Berdasarkan tabel 6.1 : Mianus, Round Hill Berdasarkan tabel 6.4 : Mianus, Round Hill, Downtown, dengan mengaplikasikan:

15

•

∏

Branch-name(

amount<1000

σ

(branch-customer |x| customer-loan ))

Periksa contoh ini lebih teliti: Jika seorang customer mempunyai beberapa loan dari cabang2 yang berbeda, kita tidak bisa tahu pinjaman mana yang dipinjam dari cabang apa. Walaupun pada tabel 6.4 kita mendapatkan beberapa tambahan tuple daripada tabel 6.1 (lending), kita sebenarnya mendapatkan informasi lebih sedikit. Mengapa???? Karena secara umum, kita tidak mampu untuk menampilkan infotentang customer yang mana yang merupakan peminjam dari suatu cabang.

16

• Karena kurangnya info ini, kita menyebut dekomposisi dari lending skema ke Branchcustomer-skema dan customer-loan-skema : a lossy decomposition/ a lossy-join decomposition. • Dekomposisi yang bukan a lossy decomposition disebut a lossless-join dekomposition. • Berdasarkan penjelasan sebelumnya,secara umum a lossy-join decomposition adalah database design yang tidak baik

17

• Terdapat 1 atribut yang dimiliki bersama-sama oleh branch-customer-scheme dan Costomer-loan-schema • branch-customer-scheme Costomer-loan-schema = {customer-name} • Kita dapat merepresentasikan hubungan antara loannumber dan branch name dengan customer-name. Gambaran ni tidak cukup arena seorang customer mungkin memiliki beberapa pinjaman dan pinjaman

18

• Dalam Lending-Scheme dikelompokkan menjadi 2 scheme yaitu • Branch-scheme = (branch-name, branch-city, assets) • Loan-info-scheme=(branch-name, customer-name, loannumber, amount) • Terdapat 1 atribut yang dimiliki bersama-sama dua scheme ini yaitu: • Branch-loan-scheme dan customer-loan-scheme = {branchname}

19

• Artinya, satu-satunya cara untuk merepresntasikan hubungan antara misalnya customer name dengan assets adalah denganbranch name.

• Perbedaan antara contoh ini dengan contoh sebelumnya : assets dari branch name sama, tanpa memperhatikan pelanggan yang dimaksud. Sementara pada Assosiasi Lending branch dengan sebuah jumlah pinjaman tertentu yang bergantung pada pelanggan yang dimaksud 20

• Untuk setiap branch-name, terdapat tepat satu nilai assets dan secara tepat satu branch-city, sedangkan kalimat yang sama tidak dapat dibuat oleh customer-name. • The functional dependency: branch-name assets-branch-city dapat dibuat tetapi customer-name secara funcional tidak dapat ditentukan oleh loannumber.

21

• Misalkan R adalah relation-scheme. Sebuah himpunan dari relation-scheme {R1,R2,….,Rn} adalah dekomposisi dari R jika R = R1 U R2 U R3 U…. • {R1,R2,….,Rn} adalah dekomposisi dari R jika untuk i=1,2,…,n setiap Ri adalah subset dari R dan setiap atribut dalam R muncul minimal sekali pada Ri.

22

• Misalkan r adalah relasi pada scheme R, dan misalkan ri = ∏ Ri (r)untuk i=1,2,…,n . • Maka {r1,r2,….,rn}adalah database sebagai akibat dari dekomposisi R menjadi {R1,R2, ….,Rn}. r r1 |x | r2 |x|. . . . . |x| rn

⊆

23

• Untuk membuktikan bahwa pernyataan di atas benar, misalkan sebuat tuple t dalam relasi r. • Ketika kita menghitung relasi r1,r2,….,rn tuple t membangun sebuah tuple ti dalam setiap ri, i=1,2,…,n • n tuples digabung untuk meng-regenerate t ketika kita menghitung r1 |x| r2 |x|. . . .|x| rn.

24

Secara umum r r1 |x| r2 |x| r3 |x|……….. Rn Contoh: • n=2 • r = lending-scheme • r1 = branch-cuctomer-scheme • r2 = customer-loan-scheme • r = the relation shown in figure 1 • r1 =the relation shown in figure 2 • r2 = the relation shown in figure 3 • r1 |x| r2=the relation shown in figure 4

≠

25

Dekomposisi dari Lending-scheme dalam Branch-scheme dan loan-info-scheme lossless karena fungsional dependency branch-name assets-branch-city hold on Branch-scheme.

26

• Misalkan C merepresentasikan sebuah himpunan dari sebuah database. Sebuah dekomposisi {R1,R2,….,Rn} dari sebuah relasi scheme R adalah lossless-join-decomposition R jika untuk setiap relasi r pada scheme R yang legal terhadap C r = R1(r) |x| R2(r) |X| … |x| Rn(r)

∏

∏

∏

27