2.1.17 Perancangan Basis Data (Database Design)
2.1.17.1 Perancangan Basis Data Konseptual (Conceptual Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:293), Perancangan basis data konseptual adalah proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan, independen dari semua pertimbangan fisikal.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:442), Tujuan perancangan basis data konseptual adalah untuk membangun sebuah model data konseptual dari persyaratan data dari perusahaan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:440–459), Langkah-langkah dalam membangun model data konseptual adalah sebagai berikut :
1. Membangun model data konseptual
a. Langkah 1.1 : Mengdentifikasi tipe entitas b. Langkah 1.2 : Mengidentifikasi tipe relasi
c. Langkah 1.3 : Mengidentifikasi dan mengasosiasikan atribut dengan entitas atau relasi jenis
d. Langkah 1.4 : Menentukan domain atribut
e. Langkah 1.5 : Menentukan candidate, primary, and alternate key attributes
f. Langkah 1.6 : Mempertimbangkan penggunaan konsep model yang disempurnakan (langkah opsional)
g. Langkah 1.7 : Memeriksa model untuk redundansi
h. Langkah 1.8 : Validasi model konseptual terhadap transaksi pengguna
i. Langkah 1.9 : Ulasan model data konseptual dengan pengguna
Berikut adalah penjelasan dari langkah-langkah diatas. 1. Langkah 1 : Membangun model data konseptual
membangun model data konseptual sesuai dengan kebutuhan data pada perusahaan, Tahap pertama dalam perancangan basis data konseptual adalah membangun satu atau lebih model data konseptual yang sesuai dengan kebutuhan data dari perusahaan. (Thomas Connolly dan Carolyn Begg, 2005:442–443)
Tahapan-tahapan yang dilakukan pada langkah pertama adalah : 1. Langkah 1.1 : Mengidentifikasi tipe entitas
Mendefinisikan objek-objek utama user. Objek-objek ini merupakan tipe-tipe entitas untuk model tersebut. Salah satu metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan user dengan mengidentifikasi kata benda. Contohnya adalah staff number, staff name, property number, property room dan sebagainya. (Thomas Connolly dan Carolyn Begg, 2005:443–444)
2. Langkah 1.2 : Mengidentifikasi tipe relasi
Setelah mengidentifikasi tipe entitas, langkah selanjutnya yaitu mengidentifikasikan semua relasi-relasi penting yang ada diantara tipe entitas yang telah diidentifikasikan. Setelah
mengidentifikasikan relasi, langkah selanjutnya yaitu menentukan multiplicity dari setiap relasi. Batasan multiply digunakan untuk memeriksa dan memelihara kualitas data. (Thomas Connolly dan Carolyn Begg, 2005:445–447)
3. Langkah 1.3 : Mengidentifikasi dan menghubungkan atribut dengan tipe entitas atau relationship
Langkah berikutnya yaitu mengidentifikasi atribut-atribut yang terdapat dalam suatu entitas. Biasanya berupa kata benda atau frasa kata benda dari spesifikasi kebutuhan user. Ada 3 jenis atribut, yaitu : Simple atau composite attributes, single atau multi-value attributes, derived attributes. (Thomas Connolly dan Carolyn Begg, 2005:447–450)
4. Langkah 1.4 : Menentukan domain atribut
Tahap ini bertujuan untuk menentukan domain atribut di model data konseptual lokal. Domain merupakan kumpulan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Sebuah model data yang baik menentukan domain untuk setiap atribut dan termasuk sekumpulan nilai-nilai yang diperbolehkan untuk atribut juga ukuran dan format dari atribut. (Thomas Connolly dan Carolyn Begg, 2005:450-451)
5. Langkah 1.5 : Menentukan atribut candidate key, primary key, dan alternate key
Candidate key adalah kunci yang unik atau tidak mungkin sama atau berbeda dengan yang lain, dapat dipakai untuk mengidentifikasi satu baris dalam tipe entitas. Primary key adalah candidate key yang dipilih sebagai kunci primer untuk mengidentifikasikan setiap entitas. Langkah ini bertujuan untuk mengidentifikasi candidate key untuk setiap tipe entitas, jika terdapat lebih dari satu candidate key kemudian pilih salah satunya menjadi primary key. Alternate key merupakan candidate key yang tidak dipilih menjadi primary key. (Thomas Connolly dan Carolyn Begg, 2005:451–452)
6. Langkah 1.6 : Mempertimbangkan penggunaan enhanced modeling concepts (optional step)
Mempertimbangkan penggunaan enhanced modeling concepts seperti specialization atau generalization, aggregation, dan composition. Jika memilih pendekatan specialization, usahakan untuk memperhatikan perbedaan antara entitas dengan mendefinisikan satu atau lebih subclass dari sebuah entitas superclass. Jika memilih menggunakan pendekatan generalization, usahakan untuk mengidentifikasikan fitur-fitur umum antara entitas untuk mendefinisikan generalisasi entitas superclass. Pendekatan aggregation digunakan untuk mempresentasikan relasi “mempunyai sesuatu” atau “bagian dari” relasi antara tipe-tipe entitas, dimana yang satu mempresentasikan “keseluruhan” dan yang lain sebagai “bagiannya”. Pendekatan composition digunakan untuk mempresentasikan sebuah asosiasi antara tipe-tipe entitas dimana terdapat kepemilikan yang kuat dan relasi antara “keseluruhan” dan “bagiannya”. (Thomas Connolly dan Carolyn Begg 2005:453–481)
7. Langkah 1.7 : Cek model untuk redudansi
Tahap ini bertujuan untuk memeriksa model data konseptual lokal, apakah masih ada redudansi pada model. Dua aktivitas pada tahap ini, yaitu :
i. Memeriksa kembali relasi one-to-one (1 :1)
Saat identifikasi entitas, mungkin saja kita menemukan dua entitas yang merepresentasikan objek yang sama pada perusahaan. Untuk kejadian ini kedua entitas tersebut harus digabungkan. Jika primary key berbeda, pilih salah satu untuk menjadi primary key dan biarkan yang lain menjadi alternate key.
ii. Menghilangkan relasi yang redundan
Data model yang baik sangat diharapkan untuk tidak memiliki relasi yang redudan. Suatu relasi dikatakan
redudansi jika terdapat informasi yang sama yang diperbolehkan oleh relasi lain.
iii. Mempertimbangkan dimensi waktu Dimensi waktu dalam relasi sangat penting dalam menentukan redudansi. (Thomas Connolly dan Carolyn Begg, 2005:453–456) 8. Langkah 1.8 : Validasi model konseptual lokal dengan transaksi
user
Tahap ini bertujuan untuk memastikan bahwa model konseptual mendukung kebutuhan transaksi yang diperlukan bagi view. Dua pendekatan untuk memastikan model data konseptual mendukung kebutuhan transaksi, yaitu:
i. Mendeskripsikan transaksi
Memeriksa apakah semua informasi (entitas, relasi, dan atributnya) yang dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan sebuah deskripsi dari setiap kebutuhan transaksi.
ii. Menggunakan jalur transaksi
Memvalidasi model data terhadap kebutuhan transaksi yang melibatkan diagram yang merepresentasikan jalur setiap transaksi dalam diagram ER. (Thomas Connolly dan Carolyn Begg, 2005:456–458)
9. Langkah 1.9 : Meninjau kembali model data konseptual lokal dengan user Pada langkah ini, user akan meninjau ulang model data konseptual. Jika terjadi anomali pada model data, maka harus dilakukan perubahan yang mungkin memerlukan pengulangan langkah-langkah sebelumnya. Proses ini akan terus diulang sampai model data benar-benar menjadi representasi aktual dari perusahaan. (Thomas Connolly dan Carolyn Begg, 2005:458) 2.1.17.2 Perancangan Basis Data Logikal (Logical Database Design) Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:294), Perancangan basis data logikal adalah proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan
berdasarkan pada model data yang spesifik, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:442), Tujuan perancangan basis data logikal adalah untuk menerjemahkan model data konseptual menjadi model data logikal dan kemudian untuk memvalidasi model ini untuk memeriksa bahwa itu secara struktural benar dan mampu mendukung transaksi yang diperlukan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:462–493) Langkah-langkah dalam membangun model data logikal adalah sebagai berikut:
2. Langkah 2 : Membangun model data logikal
a. Langkah 2.1 : Menurunkan relasi untuk model data logikal b. Langkah 2.2 : Validasi relasi dengan menggunakan
normalisasi
c. Langkah 2.3 : Validasi relasi terhadap transaksi pengguna d. Langkah 2.4 : Memeriksa kendala integritas
e. Langkah 2.5 : Meninjau kembali model data logikal dengan pengguna
f. Langkah 2.6 : Menggabungkan model data logikal ke dalam model global (optional step)
g. Langkah 2.7 : Memeriksa perkembangan di masa depan Berikut adalah penjelasan dari langkah-langkah diatas.
a. Langkah 2.1 : Menurunkan relasi untuk model data logikal Tahap ini bertujuan untuk membuat relasi untuk model data logikal untuk merepresentasikan entitas, relasi dan atribut yang telah diidentifikasikan. Cara–cara yang dapat dilakukan untuk mendapatkan relasi dari data model yang ada adalah tipe entitas kuat, tipe entitas lemah, tipe relasi binary one-to-many (1:*), tipe relasi binary one-to-one (1:1), relasi rekursif one-to-one(1:1), tipe relasi superclass / subclass, tipe relasi binary many-to-many (*:*),
tipe relasi kompleks, atribut multi-valued. (Thomas Connolly dan Carolyn Begg, 2005:463–472)
b. Langkah 2.2 : Validasi relasi menggunakan normalisasi
Normalisasi digunakan untuk memastikan relasi dan atribut yang mendukung kebutuhan dari perusahaan. Juga redudansi data yang minimal pada relasi untuk menghindari masalah yang mungkin terjadi. Proses normalisasi terdiri dari UNF, 1NF, 2NF, 3NF. (Thomas Connolly dan Carolyn Begg, 2005:473–474)
c. Langkah 2.3 : Validasi relasi terhadap transaksi pengguna.
Tujuan pada tahap ini yaitu untuk memvalidasi model data logikal untuk memastikan bahwa model data mendukung kebutuhan transaksi yang telah tercantum didalam spesifikasi kebutuhan user. Validasi transaksi seperti ini sudah dilakukan pada tahap 1.8, namun kembali dilakukan untuk memeriksa relasi-relasi yang telah dibuat pada langkah sebelumnya juga mendukung transaksi ini. Juga untuk memastikan tidak terdapat kesalahan dalam pembuatan relasi-relasi. (Thomas Connolly dan Carolyn Begg, 2005:474)
d. Langkah 2.4 : Memeriksa kendala integritas.
Kendala integritas adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten (Thomas Connolly dan Carolyn Begg, 2005:474–478)
Tipe integrity constraint, yaitu : i. required data
ii. attribute domain constraints iii. multiplicity
iv. entity integrity v. referential integrity vi. general constraints
e. Langkah 2.5 : Meninjau Kembali model data logikal dengan pengguna
Tahapan ini Untuk meninjau model data logikal dengan pengguna dan untuk memastikan bahwa mereka mempertimbangkan model data yang terbentuk merupakan representasi data perusahaan tersebut. (Thomas Connolly dan Carolyn Begg, 2005:478–479) f. Langkah 2.6 : Menggabungkan model data logikal ke dalam
model global (optional step)
Tahapan ini bertujuan untuk menggabungkan model data logical local ke dalam data model single global logical yang mewakili semua user views dari basis data. Aktivitas dalam tahap ini, yaitu:
i. Menggabungkan model data logikal lokal ke dalam model global,
ii. Validasi model data logikal global,
iii. Meninjau kembali model data logikal global dengan user (Thomas Connolly dan Carolyn Begg, 2005:479–590). g. Langkah 2.7 : Memeriksa perkembangan di masa depan
Tujuan dari tahap ini adalah untuk menentukan apakah ada perubahan yang signifikan di masa depan dan untuk memperkirakan apakah model data logikal bisa mengakomodasi perubahan tersebut. (Thomas Connolly dan Carolyn Begg, 2005:490)
2.1.17.3 Perancangan Basis Data Fisikal (Physical Database Design)