2.3.8 Tahap-Tahap Perancangan Basis Data
2.3.8.1 Perancangan Basis Data Konseptual
Langkah-langkah dalam metodologi percancangan basis data konseptual adalah sebagai berikut (Begg, Connolly, 2005, p442):
• Langkah 1 – Membangun Local Conceptual Data Model - Langkah 1.1 Mengidentifikasi tipe entitas
Tujuan dari langkah ini adalah untuk mengidentifikasi tipe entitas yang terutama dibutuhkan oleh pengguna. Satu metode untuk mengidentifikasi entitas adalah tentukan kebutuhan pengguna terlebih dahulu. Dan pada langkah ini dilakukan identifikasi kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek besar seperti orang, tempat, benda, atau konsep dapat digunakan untuk mencari tipe entitas. Cara lain adalah dengan mencari objek yang bebas. (Begg, Connolly, 2005, p443)
- Langkah 1.2 Identifikasi tipe relasi
Tujuannya adalah untuk mengidentifikasi relasi penting yang tersedia diantara tipe-tipe entitas (Begg, Connolly, 2005, p445) - Langkah 1.3 Mengidentifikasi dan menghubungkan atribut
dengan entitas atau tipe relasi
Tujuannya adalah untuk menghubungkan atribut dengan entitas atau tipe relasi yang tepat. Atribut yang dimiliki oleh setiap
34 entitas dan relasi wajib memenuhi karakteristik atribut yaitu simple/composite attribute, single/multi-valued attribute, dan
derived attribute. (Begg, Connolly, 2005, p447)
- Langkah 1.4 menentukan domain atribut
Bertujuan untuk menentukan domain atribut didalam local conceptual data model. Sebuah domain adalah kumpulan nilai
dimana satu atau lebih atribut memperoleh nilai true atau benar. Setiap atribut di dalam relasi ditetapkan dalam domain. (Begg, Connolly, 2005, p450)
- Langkah 1.5 Menentukan atribut Candidate Key dan Primary Key Digunakan untuk identifikasi candidate key setiap tipe entitas, dan jika ada lebih dari satu candidate key, maka akan terpilih satu untuk menjadi primary key dan yang lain akan menjadi alternate key (Begg, Connolly, 2005, p451). Untuk memilih
primary key diantara candidate key, pergunakan aturan berikut
untuk membantu pemilihan primary key :
Candidate key dengan minimal kumpulan dari atribut Candidate key dengan nilai yang paling sedikit berubah. Candidate key dengan jumlah karakter yang paling sedikit
(untuk yang memiliki textual attributes)
Candidate key dengan nilai maximum yang paling kecil (untuk yang dengan numerical attributes)
Candidate key yang paling mudah digunakan dari sudut pandang pengguna.
35 - Langkah 1.6 Pertimbangkan penggunaan dari enhanced modeling
concepts (langkah pilihan)
Tujuannya adalah untuk mempertimbangkan penggunaan dari peningkatan model konsep, seperti specialization / generalization, generalization, aggregation, dan composition.
Specialization adalah proses memaksimalkan perbedaan antara
anggota sebuah entitas dengan mengidentifikasi karakteristik yang membedakan entitas tersebut. Generalization adalah proses meminimalkan perbedaan antar entitas dengan mengidentifikasi sifat umum entitas. Aggregation menunjukkan ’memiliki’ atau ’bagian dari’ relationship diantara tipe entitas, dimana yang satu menunjukkan ’keseluruhan’ dan ’bagian’ (Begg, Connolly, 2005, p453).
- Langkah 1.7 Model pemeriksaan untuk redudancy
Digunakan untuk memeriksa conceptual model agar terhindar dari redudansi dalam model (Begg, Connolly, 2005, p453). Dua kegiatan yang dilakukan pada hal ini adalah :
Memeriksa kembali One-to-one (1:1) Relationship.
Dalam mengidentifikasi entitas, mungkin dapat menemukan dua entitas atau lebih yang menggambarkan objek yang sama dalam suatu organisasi.
Menghilangkan Relasi redundant
Sebuah relasi dikatakan redundant apabila informasi yang sama dapat diperoleh pada relasi lainnya.
36 - Langkah 1.8 melakukan validasi conceptual model dengan
transaksi yang dilakukan pengguna
Untuk memastikan bahwa local conceptual model mendukung transaksi yang dibutuhkan (Begg, Connolly, 2005, p456). Dua pendekatan yang memungkinkan untuk memastikan local conceptual data model mendukung kebutuhan transaksi :
Menggambarkan transaksi
Memeriksa semua informasi (entities, relationship, dan attributes) yang dibutuhkan oleh setiap transaksi dan
dihasilkan oleh model, dengan dokumentasi sebuah penjelasan dari setiap kebutuhan transaksi.
Menggunakan transaction pathways
Melakukan validasi data terhadap kebutuhan transaksi dengan penggambaran diagram yang mewakili pathway yang diambil oleh setiap transaksi secara langsung pada diagram ER.
- Langkah 1.9 Melihat kembali conceptual data model bersama pengguna
Untuk memastikan bahwa data model adalah merupakan representasi yang benar dari kebutuhan dari suatu organisasi (Begg, Connolly, 2005, p458).
37 2.3.8.2 Perancangan Basis Data Logikal
Perancangan basis data logika adalah suatu proses pembangunan sebuah model dari data yang digunakan di dalam suatu perusahaan berdasarkan sebuah model data yang spesifik, tetapi tidak bergantung pada suatu DBMS tertentu dan pertimbangan fisikal lainnya. (Begg, Connolly, 2005, p439).
Langkah-langkah perancangan basis data logikal adalah sebagai berikut (Begg, Connolly, 2005, p462):
• Langkah 2. Membangun dan melakukan validasi logical data model Tujuannya adalah untuk menerjemahkan conceptual data model kedalam logical data model dan kemudian memvalidasi model tersebut agar benar secara struktural dan mampu mendukung transaksi-transaksi yang dibutuhkan (Begg, Connolly, 2005, p462). Aktivitas yang ada pada langkah tersebut adalah :
- Langkah 2.1 Menentukan Relasi-Relasi untuk logical data model Tujuannya adalah menciptakan relasi untuk logical data model untuk merepresentasikan entitas-entitas, relasi-relasi, dan atribut-atribut yang telah diidentifikasikan (Begg, Connolly, 2005, p463). Relationship yang mungkin terjadi pada model data konseptual:
• Strong Entity Type
Strong Entity Type adalah tipe entitas yang keberadaannya
tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari Strong entity type adalah setiap
38 tipe entiti yang terjadi dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering disebut dengan parent atau owner atau
dominant entities (Begg, Connolly, 2005, p354).
• Weak Entity type
Weak entity type adalah tipe entitas yang keberadaannya
bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut dengan child, dependent, atau
subordinate entities (Begg, Connolly, 2005, p355).
• One-to-many (1:*) binary relationship types
Untuk setiap 1:* binary relationship, entitas pada ‘satu sisi’ dari relasi dianggap sebagai entitas parent dan entitas pada ‘banyak sisi’ dianggap sebagai entitas child. Untuk merepresentasikan relasi ini, tampilkan salinan atribut primary key dari entitas parent ke dalam relasi yang
merepresentasikan entitas child, untuk berlaku sebagai foreign key (Begg, Connolly, 2005, p465).
• One-to-one (1:1) binary relationship types
Membuat relasi-relasi yang memperlihatkan sebuah relasi 1:1 sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasi entitas-entitas parent dan child dalam relasi (Begg, Connolly, 2005, p465).
relasi-39 relasi untuk merepresentasikan participation constraint berikut:
- Mandatory Participation pada 2 sisi dari 1:1 relationship
Pada kasus ini, harus digabungkan entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas-entitas aslinya untuk menjadi
primary key pada relasi yang baru, sedangkan yang
lainnya dijadikan alternate key. (Begg, Connolly, 2005, p466)
- Mandatory Participation pada 1 sisi dari relasi 1:1 Pada kasus ini dapat diidentifikasi entitas-entitas parent dan child untuk relasi 1:1 dengan menggunakan
participation constraint. Entitas yang mempunyai
pilihan participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap
sebagai child. (Begg, Connolly, 2005, p466)
- Optional Participation pada 2 sisi dari 1:1 relationship Primary key dapat dipilih berdasatkan atas kasus yang
ada (Begg, Connolly, 2005, p467) • One-to-one (1:1) recursive relationship types
Untuk sebuah 1:1 recursive relationship, ikuti aturan yang dijelaskan diatas untuk sebuah 1:1 relationship.
40 Dalam kasus tertentu relasi 1:1, entity kedua sisi dari relationship adalah sama. Untuk 1:1 recursive
relationship dengan mandatory participation pada 2 sisi,
representasikan recursive relationship sebagai relasi tunggal dengan salinan 2 primary key. Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus dubah namanya untuk menandakan
relationship yang direpresentasikan.
(Begg, Connolly, 2005, p467) • Superclass/subclass relationship types
Untuk setiap superclass / subclass relationship dalam conceptual data model, dapat diidentifikasi entitas
superclass sebagai entiti parent dan entiti subclass sebagai
entitas child. Pilihan yang paling sesuai tergantung dari
sejumlah faktor seperti disjointnese dan participation constraint pada superclass/subclass relationship apakah
subclass-subclass terlibat dalam distinct relationship dan
jumlah participant dalam relasi superclass / subclass (Begg, Connolly, 2005, p467).
• Many-to-many (*:*) binary relationship types
Untuk setiap relasi biner many-to-many (*:*), buatlah relasi yang mewakili relasi dan mencakup seluruh atribut yang menjadi bagian dari relasi. Dilakukan penyalinan
41 atribut primary key untuk entity yang berpartisipasi didalam relasi kedalam relasi yang baru sebagai foreign key (Begg, Connolly, 2005, p469) .
• Complex relationship types
Untuk setiap relasi kompleks, buat sebuah relasi untuk merepresentasikan relasi dan meliputi semua atribut yang merupakan bagian dari relasi tersebut. Lalu buat salinan primary key dari entitas yang berhubungan dalam relasi
kompleks kedalam relasi baru, untuk berlaku sebagai foreign key.
• Multi-valued attributes
Untuk setiap atribut yang memiliki banyak nilai yang ada pada entity, buatlah relasi untuk mewakili atribut multi-value dan mencakup primary key dari entity pada relasi
yang baru sebagai foreign key (Begg, Connolly, 2005, p471).
- Langkah 2.2 Melakukan validasi relasi dengan menggunakan normalisasi
Tujuannya adalah untuk melakukan validasi terhadap relasi-relasi dalam logical data model dengan menggunakan teknik normalisasi. (Begg, Connolly, 2005, p473).
Normalisasi merupakan teknik untuk menghasilkan sekumpulan relasi-relasi dengan properti-properti yang diinginkan, sesuai
42 dengan kebutuhan data-data yang diberikan oleh suatu perusahaan (Begg, Connolly, 2005, p388). Tujuan dari normalisasi ini adalah untuk mengurangi redudansi data (pengulangan data) dan update anomaly.
Update anomaly dibedakan menjadi 3, yaitu insert anomaly,
update anomaly, dan modification anomaly/update anomaly.
Delete anomaly adalah kejanggalan yang terjadi terhadap suatu
tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah tabel pada saat dilakukan penambahan suatu record yaitu berupa pelanggaran terhadap batasan integritas.
Modification/update anomaly adalah kejanggalan yang terjadi
pada suatu tabel pada saat dilakukan pengubahan suatu rekaman. (Begg, Connolly, 2005, p392).
Proses dari normalisasi melewati tahap seperti berikut (Begg, Connolly, 2005, p401):
a. First normal form (1NF), yang bertujuan menghilangkan perulangan data
b. Second normal form (2NF), yang bertujuan untuk menghilangkan ketergantungan parsial pada Primary Key. c. Third Normal Form (3NF), yang bertujuan untuk
43 - Langkah 2.3 melakukan validasi relasi pada transaksi user
Langkah ini dilakukan untuk memastikan bahwa relasi didalam Local logical data model mendukung transaksi yang
dibutuhkan. (Begg, Connolly, 2005, p474). - Langkah 2.4 memeriksa batasan integrity
Bertujuan untuk memeriksa batasan integritas yang direpresentasikan dalam logical data model (Begg, Connolly, 2005, p474). Batasan integritas dibagi menjadi 5 bagian, yaitu :
a. Data yang dibutuhkan (Required Data)
Beberapa atribut harus selalu mengandung nilai yang bernilai valid, dengan kata lain, tidak boleh diperbolehkan mempunyai nilai null.
b. Batasan domain atribut
Setiap atribut mempunyai domain, yaitu sekumpulan nilai yang pasti.
c. Multiplicity
Multiplicity merepresentasikan batasan yang ditempatkan
pada relasi diantara data dalam basisdata. d. Integritas entitas
Primary key dari sebuah entitas tidak boleh bernilai null.
Batasan ini harus dipertimbangkan ketika kita mengidentifikasi primary key untuk tiap tipe entitas.
44 e. Integritas referensial
Integritas referensial berarti jika foreign key berisi sebuah nilai, maka nilai tersebut harus menunjuk tuple yang ada di dalam relasi parent. Umumnya, jika partisipasi dari relasi child dalam relationship adalah mandatory, maka nilainya tidak boleh null. Tetapi jika partisipasi dari relasi child dalam relasi dapat dipilih, maka boleh null.
f. Batasan umum
Pengubahan pada entitas mungkin dapat diatur oleh batasan-batasan yang mengatur transaksi ’real world’ yang direpresentasikan oleh perubahan tersebut.
- Langkah 2.5 Melihat ulang model local logical data dengan pengguna
Bertujuan untuk melihat kembali logical data model untuk memastikan bahwa pengguna mempertimbangkan model data logikal untuk menjadi representasi yang sebenarnya dari kebutuhan data perusahaan. (Begg, Connolly, 2005, p478).
- Langkah 2.6 Menggabungkan Local logical data model kedalam global model.
Langkah ini bertujuan untuk merepresentasikan semua user views dari database (Begg, Connolly, 2005, p479).
Langkah-langkahnya adalah sebagai berikut :
a. Melihat kembali nama dan isi datri entitas/relasi serta candidate keys.
45 Bertujuan untuk mengidentifikasi munculnya dua masalah potensial sebagai berikut :
o Memiliki nama yang sama, tetapi sebenarnya tidak sama (homonim)
o Adalah sebenarnya sama, tetapi memiliki nama yang berbeda (sinonim)
b. Melihat kembali nama dan isi dari relationship/foreign key c. Menggabungkan entitas/relasi dari model data lokal.
d. Memasukkan (tanpa menggabungkan) entitas/relasi yang unik ke dalam setiap model data
e. Menggabungkan relasi/foreign key dari local data model f. Memasukkan (tanpa menggabungkan) relasi / foreign key
yang unik kedalam setiap model data
g. Mengecek untuk entitas/relasi dan relasi / foreign key yang tertinggal.
h. Mengecek foreign key
i. Mengecek integrity constraint
j. Menggambarkan diagram ER / relasi global k. Melakukan update dokumentasi.