bab 2 landasan teori 2.1 teori-teori tentang basis...
TRANSCRIPT
BAB 2
LANDASAN TEORI
2.1 Teori-teori tentang Basis Data
Aplikasi basis data sudah umum digunakan dalam kehidupan kita sehari-hari.
Sebagai contoh, pembelian barang menggunakan kartu kredit, pemesanan tiket pada
agen perjalanan, peminjaman buku di perpustakaan, dan pengambilan uang di bank
sering menggunakan aplikasi basis data. Sebelum adanya aplikasi basis data seperti
DBMS, penyimpanan data masih menggunakan penyimpanan berbasis file (File-
based System).
Pendekatan File-based System menurut Connoly (2002, p7) adalah suatu
kumpulan program aplikasi yang memberikan layanan pada end user seperti laporan.
Setiap program menjelaskan dan mengatur masing-masing datanya. Dari sistem ini
ditemui banyak kelemahan, antara lain:
Data yang terpisah dan terisolasi
Adanya duplikasi data
Ketergantungan data
Format file yang tidak sesuai
Query yang tetap sehingga tidak dapat menangani perkembangan program
aplikasi
Untuk mengatasi keterbatasan pada sistem ini, maka dikembangkanlah
pendekatan basis data dan DBMS (Database Management System). Pendekatan basis
data ini memperbaiki kelemahan-kelemahan pada file-based system.
8
2.1.1 Pengertian Basis Data
Menurut Connoly (2002, p14), basis data adalah kumpulan dari data-
data yang terkait secara logikal beserta penjelasannya yang dirancang untuk
memenuhi kebutuhan organisasi. Menurut C.J. Date (1990, p5) sistem basis
data adalah suatu sistem yang pada dasarnya menyimpan record-record secara
terkomputerisasi dengan tujuan memelihara informasi dan menyediakan
informasi tersebut berdasarkan permintaan. Menurut Ramakrishnan dan
Gehrke (2003, p4) basis data adalah sekumpulan data yang menggambarkan
aktifitas dari satu atau lebih organisasi yang terkait.
2.1.2 Database Management System
Definisi DBMS menurut Connoly (2002, p16) adalah sistem piranti
lunak dimana user dapat mendefinisikan, membuat, menjaga dan mengontrol
akses ke basis data. Fasilitas-fasilitas yang dimiliki DBMS, antara lain:
• Memperbolehkan user untuk mendefinisikan basis data, biasanya
menggunakan Data Definition Language (DDL), dimana dapat
dispesifikasikan tipe data , struktur, dan batasan pada data yang disimpan
dalam basis data tersebut.
• Memperbolehkan user untuk menambah, mengedit, menghapus dan
mendapatkan kembali data. Biasanya dengan menggunakan suatu Data
Manipulation Language (DML), dimana terdapat suatu fasilitas untuk
pengaksesan data yang disebut sebagai Query Language. Bahasa Query
9
yang paling diakui dan secara de facto merupakan standar bagi DBMS
adalah Structured Query Language (SQL).
• Mengontrol akses ke basis data. Sebagai contoh:
o Sistem keamanan yang mencegah user tidak berwenang mengakses
data
o Sistem terintegrasi yang menjaga konsistensi penyimpanan data
o Sistem kontrol concurrency yang memperbolehkan akses bersama ke
basis data
o Sistem kontrol recovery yang dapat mengembalikan data ke keadaan
sebelumnya apabila terjadi kegagalan perangkat keras atau perangkat
lunak.
o Terdapat suatu katalog yang dapat diakses oleh user yang berisi
deskripsi data di dalam basis data.
Penggunaan DBMS memiliki keuntungan dan juga kekurangan.
Adapun keuntungan penggunaan DBMS, antara lain:
1. Kontrol terhadap pengulangan data
2. Konsistensi data
3. Semakin banyak informasi yang didapat dari data yang sama
4. Pemakaian data secara bersama
5. Meningkatkan integritas data
6. Meningkatkan keamanan data
7. Penetapan standarisasi
8. Pengukuran biaya
9. Keseimbangan dari persyaratan yang saling bertubrukan
10
10. Meningkatkan pengaksesan data
11. Meningkatkan produktivitas
12. Memperbaiki pemeliharaan data melalui independensi data
13. Memperbaiki pengaksesan data secara bersama-sama
14. Mengembangkan layanan backup dan recovery
Adapun kerugian penggunaan DBMS, antara lain:
1. Kompleksitas
2. Size /Ukuran
3. Biaya dari suatu DBMS
4. Biaya penambahan perangkat keras
5. Biaya konversi ke sistem baru
6. Kinerja
7. Dampak lebih lanjut bila terjadi kegagalan
2.1.3 Data Definition Language
Menurut Connoly (2002, p40), Data Definition Language (DDL)
adalah suatu bahasa yang memperbolehkan DBA atau user untuk
mendeskripsikan nama dari entiti, atribut, dan relasi yang dibutuhkan pada
aplikasi, bersamaan dengan batasan keamanan dan integritas yang terkait. DDL
juga digunakan untuk menspesifikasikan skema basis data.
Beberapa contoh DDL, antara lain:
1. Create Table
Perintah CREATE TABLE digunakan untuk membuat tabel dengan
mendefinisikan tipe data untuk tiap kolom
11
Bentuk umum:
CREATE TABLE table_name
( column_name data_type [NULL|NOTNULL],
column_name data_type[NULL|NOTNULL]
...
)
2. Drop Table
Perintah DROP TABLE digunakan untuk menghapus tabel beserta
seluruh datanya.
Bentuk umum:
DROP TABLE table_name;
3. Alter Table
Perintah ALTER TABLE digunakan untuk menambah atau mengurangi
kolom dan constrain.
Bentuk umum:
ALTER TABLE table_name
[ADD column_name data_type [NULL|NOTNULL]]
[DROP column_name data_type [RESTRICT|CASCADE]]
[ADD constrain_name]
[DROP constrain_name [RESTRICT|CASCADE]]
12
2.1.4 Data Manipulation Language
Menurut Connoly (2002, p41), Data Manipulation Language (DML)
adalah suatu bahasa yang mendukung operasi dasar manipulasi data yang ada
dalam basis data. DML dapat dibedakan menjadi dua, yaitu DML prosedural
dan DML non-prosedural.
DML prosedural adalah sebuah bahasa yang memungkinkan pemakai
untuk memberitahu sistem mengenai data yang dibutuhkan dan bagaimana
mendapatkan data tersebut. Sedangkan DML non-prosedural adalah bahasa
yang memungkinkan pemakai untuk menyatakan data apa yang dibutuhkan
tanpa perlu memikirkan bagaimana cara mendapatkannya.
Operasi manipulasi data biasanya meliputi:
• Pemasukan data baru ke dalam basis data
• Modifikasi dari penyimpanan data di basis data
• Pengembalian data yang terdapat di basis data
• Penghapusan data dari basis data
Beberapa contoh DML, yaitu:
1. Select
Perintah SELECT digunakan baik untuk menampilkan sebagian atau
seluruh isi dari sebuah tabel maupun menampilkan kombinasi isi dari
beberapa tabel.
Bentuk umum:
SELECT column_name FROM table_name WHERE condition
13
2. Insert
Perintah INSERT digunakan untuk menambahkan satu atau beberapa baris
data baru ke dalam tabel.
Bentuk umum:
INSERT INTO table_name(column list) VALUES (value list)
3. Update
Perintah UPDATE digunakan untuk mengubah isi dari satu atau beberapa
atribut dari suatu tabel.
Bentuk umum:
UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition
4. Delete
Perintah DELETE digunakan untuk menghapus sebagian atau seluruh isi
tabel.
Bentuk umum:
DELETE FROM table_name WHERE condition
2.1.5 Normalisasi
Dalam membuat suatu basis data, harus dilakukan langkah normalisasi
terlebih dahulu. Normalisasi (Connoly, p376) adalah suatu teknik untuk
menghasilkan sekumpulan relasi dengan properti yang diinginkan dari data
yang diberikan oleh perusahaan. Proses Normalisasi pertama kali
dikembangkan oleh E.F. Codd terdiri dari tiga bentuk normal, yang lebih sering
14
disebut 1NF, 2NF, dan 3NF. Selanjutnya R. Boyce dan E. F. Codd
memperkenalkan bentuk 3NF yang lebih sempurna yang disebut BCNF. Semua
bentuk normal ini didasarkan pada ketergantungan fungsional diantara atribut
pada suatu relasi. Kemudian muncul bentuk-bentuk normal yang lebih tinggi
dari BCNF yang diperkenalkan sebagai 4NF dan 5NF.
Tujuan dari normalisasi adalah sebagai berikut:
1. Meminimalisasi pengulangan data dan memaksimalkan stabilitas
2. Menghasilkan suatu rancangan basis data yang fleksibel yang dapat
dikembangkan dengan mudah
3. Meningkatkan kehandalan dan bebas dari update anomali.
Tahapan normalisasi:
1. Normalisasi pertama (1NF)
Menurut Connoly (2002, p388), bentuk normal pertama adalah
suatu relasi dimana titik pertemuan antara baris dan kolom berisi hanya
satu nilai. Kondisi ini dapat dicapai dengan cara menghilangkan perulangan
data.
Suatu relasi dikatakan mencapai bentuk normal pertama jika
memenuhi syarat sebagai berikut:
• Setiap baris dan kolom berisi atribut yang bernilai tunggal
• Atribut multi-value sudah dihilangkan
• Primary key sudah ditentukan
15
2. Normalisasi kedua (2NF)
Menurut Connoly (2002, p392), bentuk normal kedua adalah sebuah
relasi dalam bentuk normal pertama dan setiap atribut yang bukan primary
key bergantung fungsional sepenuhnya pada primary key. Bentuk normal
kedua ini menghilangkan ketergantungan sebagian pada primary key.
Suatu relasi dapat dikatakan mencapai bentuk normal kedua jika
memenuhi syarat sebagai berikut:
• Berada dalam bentuk normal pertama
• Semua atribut yang bukan primary key bergantung fungsional
sepenuhnya kepada primary key.
3. Normalisasi ketiga (3NF)
Menurut Connoly (2002, p394), bentuk normal ketiga adalah
sebuah relasi dalam bentuk normal pertama dan kedua, dan atribut non
primary key tidak bergantung secara transitif terhadap primary key.
Ketergantungan transitif adalah sebuah kondisi dimana A, B, dan C adalah
atribut dari suatu relasi dimana jika A → B dan B → C maka A → C (C
mempunyai ketergantungan transitif pada A melalui B).
Suatu relasi dapat dikatakan mencapai bentuk normal ketiga jika
memenuhi syarat sebagai berikut:
• Berada dalam bentuk normal pertama dan kedua
• Setiap atribut non primary key tidak memiliki ketergantungan
transitif kepada primary key.
16
4. Normalisasi Boyce-Codd (BCNF)
Menurut Connoly (2002, p398), BCNF dapat tercapai jika dan
hanya jika setiap determinannya adalah sebuah candidate key. Determinan
adalah sebuah atribut dimana beberapa atribut yang lain masih bergantung
fungsional secara penuh.
Perbedaan bentuk normal ketiga dan bentuk BCNF adalah dalam
hal ketergantungan fungsional A→ B. Bentuk normal ketiga mengijinkan
ketergantungan ini jika B adalah primary key dan A bukan candidate key.
Sedangkan dalam bentuk BCNF, ketergantungan ini diijinkan dimana A
harus merupakan candidate key.
Suatu relasi dikatakan BCNF bila di dalamnya berisi atribut yang
berfungsi sebagai kandidat key sehingga salah satu dari kandidat key
tersebut menjadi primary key.
5. Normalisasi keempat (4NF)
Menurut Connoly (2002, p408), bentuk normal keempat adalah
sebuah relasi dalam bentuk BCNF yang tidak mengandung ketergantungan
multi-valued nontrivial. Multi-valued dependency (MVD) adalah
ketergantungan antara atribut. Sebagai contoh: A, B, C pada sebuah relasi
dimana setiap nilai dari A terdapat sekumpulan nilai untuk B dan
sekumpulan nilai untuk C tetapi sekumpulan masing-masing nilai untuk B
dan C berdiri sendiri.
Suatu relasi dapat dikatakan mencapai bentuk normal keempat jika
memenuhi syarat sebagai berikut:
17
• Berada dalam bentuk BCNF
• Tidak terdapat atribut yang memiliki ketergantungan multi-valued
6. Normalisasi kelima (5NF)
Menurut Connoly (2002, p410), bentuk normal kelima adalah
sebuah relasi yang tidak mempunyai join dependency. Sebagai contoh,
relasi R dengan subset-subset atribut dari R (misal: A.B,...,Z) dikatakan
menunjukan join dependency jika dan hanya jika setiap nilai R sama
dengan gabungan dari proyeksinya pada A,B,...,Z.
2.2 Teori Perancangan Basis Data
Dalam perancangan basis data, perlu diperhatikan tentang siklus hidup dari
aplikasi basis data itu sendiri. Struktur dari siklus hidup aplikasi basis data tidaklah
harus benar-benar sekuensial, tetapi terlibat dalam suatu perulangan dari bagan-
bagan yang sebelumnya merupakan umpan balik. Sebagai contoh, masalah yang
dihadapi selama perancangan basis data adalah masih diperlukannya analisis dan
pengumpulan data tambahan.
Untuk aplikasi basis data kecil dengan jumlah pengguna yang sedikit, siklus
hidup tidaklah sangat kompleks. Bagaimanapun juga, ketika perancangan sedang
dilakukan pada suatu aplikasi basis data ukuran sedang dengan jumlah pengguna
sekitar 10 sampai ribuan user, dengan menggunakan ratusan queries dan program
aplikasi, siklus hidup akan menjadi kompleks. Berikut adalah siklus hidup aplikasi
basis data:
18
Perencanaan Basis Data
Definisi Sistem
Analisa dan PengumpulanKebutuhan
PerancanganAplikasi
Pemilihan DBMS(Optional)
Prototyping(Optional) Implementasi
Data ConversionAnd Loading
Testing
OperationalMaintenance
Database Design
Conceptual DatabaseDesign
Logical DatabaseDesign
Physical DatabaseDesign
Gambar 2.1 Siklus Hidup Aplikasi Basis Data
(Sumber: Connoly, 2002, p272)
19
Berikut ini adalah ringkasan aktivitas utama yang ada di setiap langkah dari
siklus hidup aplikasi basis data, antara lain:
• Perencanaan basis data: merencanakan bagaimana tahapan dari siklus
hidup bisa direalisasikan dengan baik. Dalam perencanaan basis data
terdapat 2 hal yang perlu diperhatikan seksama, antara lain:
Fasilitas yang didukung basis data
Tujuan pembuatan basis data
• Definisi sistem: menspesifikasikan ruang lingkup dan batasan dari
aplikasi basis data, penggunanya, dan juga cakupan aplikasi tersebut
• Analisis dan pengumpulan kebutuhan: mengumpulkan dan menganalisis
permintaan user dan area ruang lingkup
• Perancangan basis data meliputi: Perancangan konseptual, logikal, dan
fisik dari basis data
• Pemilihan DBMS (optional)
Hal lain yang perlu kita perhatikan adalah pemilihan DBMS yang tepat
untuk mendukung aplikasi basis data kita. Bila tidak ada DBMS, maka
bagian yang tepat dari siklus hidup dimana harus melakukan pemilihan
adalah diantara fase perancangan konseptual dan logikal basis data.
Langkah utama dalam memilih DBMS adalah sebagai berikut:
o Mendefinisikan term of reference
Term of reference untuk pemilihan DBMS dibuat untuk menyatakan
tujuan, ruang lingkup pembelajaran, dan tugas-tugas yang harus
20
dikerjakan. Dokumen ini juga meliputi deskripsi dari kriteria
(berdasarkan spesifikasi kebutuhan user) yang digunakan untuk
mengevaluasi produk DBMS.
o Menuliskan dua atau tiga produk
Kriteria-kriteria penting untuk suksesnya implementasi dapat
digunakan untuk menghasilkan daftar awal untuk evaluasi produk
DBMS. Sebagai contoh, keputusan untuk memasukkan produk
DBMS dapat tergantung dari tersedianya dana, tingkat dari
dukungan vendor, kompatibilitas dengan software lain, dan apakah
produk tersebut dijalankan pada hardware khusus atau tidak.
o Mengevaluasi produk
Ada banyak fitur yang dapat digunakan untuk mengevaluasi produk
DBMS. Untuk tujuan evaluasi, fitur ini dapat dilihat sebagai suatu
kelompok (contohnya, data definition) atau secara individual
(contohnya, tipe data). Pendekatan yang berguna untuk
mengevaluasi ini adalah dengan mengukur bobot fitur-fitur dalam
hubungan dengan pentingnya dalam organisasi dan setelah
mendapatkan total semua bobot dapat digunakan untuk
membandingkan produk-produk tersebut.
o Merekomendasikan pilihan dan menghasilkan laporan
Langkah terakhir dari pemilihan DBMS adalah dengan
mendokumentasikan proses dan menyediakan pernyataan pemilihan
dan rekomendasi terhadap produk DBMS tertentu.
21
• Perancangan aplikasi basis data: melakukan desain tampilan user dan
program aplikasi yang menggunakan dan memproses basis data
• Prototyping (optional): membangun suatu model kerja dari aplikasi basis
data, yang mana mempersilahkan desainer atau user untuk
memvisualisasikan dan mengevaluasi bagaimana gambaran sistem secara
keseluruhan dan fungsinya
• Implementasi
Implementasi (Connoly, p292) merupakan realisasi fisik dari basis data
dan perancangan aplikasi. Implementasi basis data dapat dicapai dengan
menggunakan Data Definition Language (DDL) dari DBMS yang terpilih
atau Graphical User Interface (GUI), yang menyediakan fungsionalitas
yang sama ketika menyembunyikan pernyataan DDL level rendah. DDL
digunakan untuk menciptakan struktur basis data dan file kosong basis
data. Program aplikasi diimplementasikan menggunakan bahasa 3GL
atau 4GL dimana bagian dari program aplikasi ini adalah transaksi basis
data, yang diimplementasikan dengan menggunakan Data Manipulation
Language (DML).
• Data conversion and loading: memindahkan data dari sistem yang lama
ke sistem yang baru
• Testing aplikasi: basis data dites untuk melihat apakah masih ada error
dan memvalidasi sesuai dengan keinginan user
• Operational maintenance: Aplikasi basis data benar-benar
diimplementasikan. Sistem ini akan terus dimonitor dan dipelihara.
22
Apabila diperlukan suatu permintaan / fungsi akan dimasukkan ke dalam
aplikasi basis data melalui tahapan-tahapan proses yang ada dalam siklus
hidup.
2.3 Keamanan dan Integritas Basis Data
2.3.1 Keamanan Basis Data
Menurut Connoly (2002, p522), pengertian keamanan basis data adalah
suatu mekanisme yang melindungi basis data dari suatu kejadian yang
disengaja ataupun tidak disengaja.
Basis data merupakan sumber essential perusahaan yang harus
dilindungi dengan menggunakan kontrol yang memadai. Beberapa issue
keamanan yang perlu diperhatikan, antara lain:
• Pencurian data (Theft and Fraud)
• Hilangnya kerahasiaan data (loss of confidentiality)
• Hilangnya privasi (loss of privacy)
• Hilangnya integritas (loss of integrity)
• Hilangnya ketersediaan data (loss of availability)
Kontrol keamanan berbasis komputer yang dapat digunakan untuk
mengatasi permasalahan di atas dan dapat digunakan pada lingkungan multi-
user, antara lain:
• Authorisasi
Merupakan pemberian hak kepada seseorang untuk dapat mengakses
sistem secara sah
23
• Authentifikasi
Merupakan mekanisme yang menentukan apakah user adalah pengguna
sebenarnya.
• View
Merupakan hasil dinamik dari satu atau lebih operasi relasional pada
operasi dasar untuk menghasilkan relasi lainnya. View adalah relasi
virtual dimana tidak benar-benar ada di basis data tetapi dihasilkan
tergantung dari permintaan khusus user pada suatu waktu.
• Backup dan Recovery
Merupakan proses berkala dimana menyalin semua isi basis data dan
menyimpan file tersebut ke dalam media penyimpanan.
• Integritas
Batasan integritas juga membantu dalam menjaga keamanan sistem
basis data dengan cara mencegah data menjadi tidak valid atau
memberikan hasil yang tidak benar.
• Enkripsi
Merupakan pengkodean data dengan algoritma khusus yang akan
mengubah data menjadi tidak dapat dibaca oleh program lain tanpa
adanya kunci dekripsi.
• Teknologi RAID
RAID (Redundant Array of Independent Disks) adalah teknologi yang
bekerja pada disk array yang besar dimana terdiri dari pengaturan
24
beberapa disk independent untuk meningkatkan kehandalannya dan
pada waktu yang sama juga meningkatkan kinerjanya
2.3.2 Integritas Basis Data
Dalam menjaga integritas relasional basis data, ada beberapa batasan
yang perlu diperhatikan yaitu:
• Entity Integrity
Di dalam relasi dasar, atribut dari primary key tidak boleh null atau
kosong.
• Referential Integrity
Bila terdapat foreign key suatu tabel dalam suatu relasi, nilainya harus
sesuai dengan nilai primary key-nya di tabel lain.
• Enterprise Constrains
Aturan tambahan yang dispesifikasi oleh user atau DBA dari suatu
perusahaan.
2.4 Metodologi Perancangan Basis Data
Menurut Connoly (2002, p418) metodologi perancangan basis data adalah
pendekatan terstruktur yang menggunakan prosedur, teknik, alat, dan dokumentasi
yang dapat mendukung dan memfasilitasi suatu proses perancangan.
Metodologi perancangan terdiri dari bagian-bagian yang masing-masingnya
memiliki sejumlah langkah yang akan menuntun desainer dalam merencanakan,
mengatur, mengontrol dan mengevaluasi perkembangan basis data.
25
Metodologi perancangan basis data itu sendiri meliputi 3 bagian utama, yaitu
perancangan konseptual, logikal ,dan fisikal. Masing-masing fase akan dijelaskan di
bawah secara lebih rinci.
2.4.1 Perancangan Konseptual Basis Data
Tujuan dari desain konseptual basis data menurut Connoly (2002,p419)
adalah untuk membuat suatu model informasi yang akan digunakan di dalam
suatu organisasi, yang bebas dari segala pertimbangan fisik.
Langkah 1: Membangun Lokal Konseptual Data model untuk setiap view
Langkah 1.1: Mengidentifikasi Tipe Entiti
Langkah 1.2: Mengidentifikasi Tipe Relasi
Langkah 1.3: Identifikasi dan Asosiasikan Atribut dengan Entiti atau Relasi
Langkah 1.4: Menentukan Domain Atribut
Langkah 1.5: Menentukan Kandidat dan Primary key
Langkah 1.6: Menggunakan Enhanced Modelling Concepts ( langkah optional)
Langkah 1.7: Mengecek Redudansi
Langkah 1.8: Validasi Lokal Konseptual Model dengan Transaksi User
Langkah 1.9: Mereview dengan User
Berikut ini penjelasan dari langkah-langkah yang telah disebutkan di
atas secara lebih detil:
Langkah 1.1: Mengidentifikasi Tipe Entiti
Tujuan dari langkah ini adalah untuk mengidentifikasi entiti utama
yang dibutuhkan oleh user. Langkah pertama dalam membangun suatu lokal
konseptual data model adalah mendefinisikan objek utama dimana user
26
memang membutuhkannya. Salah satu metode untuk mengidentifikasi tipe
entiti yang utama adalah dengan mengidentifikasi kata benda atau frasa kata
benda yang telah disebutkan oleh user.
Langkah 1.2: Mengidentifikasi Tipe Relasi
Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang
penting diantara berbagai tipe entiti yang telah diidentifikasikan. Biasanya,
relasi diidentifikasikan menggunakan kata kerja atau frasa kata kerja
Relasi yang paling umum adalah relasi binary. Dengan kata lain, relasi
antar entiti yang persis antar dua entiti saja. Bagaimanapun, harus diperhatikan
relasi yang komplek yang melibatkan lebih dari dua entiti dan relasi rekursif
yang hanya melibatkan satu entiti.
Adapun langkah-langkah dalam mengidentifikasi tipe relasi adalah
sebagai berikut:
• Gunakan Entiti – Relationship (ER) diagrams
Pengguna akan lebih cepat mengerti suatu perancangan basis data
dengan cara divisualisasikan dibandingkan dengan bila dituliskan
dalam bentuk tekstual. Penggunaan Entiti – Relationship (ER) diagram
untuk merepresentasikan entiti dan bagaimana entiti yang satu
berhubungan dengan entiti yang lain. Penggunaan Entiti – Relationship
disarankan untuk membantu dalam membuat gambaran besar dari
perancangan basis data yang sedang dikembangkan.
27
• Tentukan Pembatas Multiplicity dari Tipe Relasi
Setelah terdapat relasi antar entiti, maka langkah berikutnya adalah
menentukan multiplicity setiap relasi. Jika memang ada suatu nilai yang
spesifik dari suatu multiplicity maka akan lebih baik apabila
didokumentasikan
• Mengecek Fan dan Chasm Traps
Definisi dari Fan Traps (Connoly, p352) adalah suatu model yang
merepresentasikan suatu relasi antar entiti tetapi alur relasinya
memperlihatkan ambiguitas. Definisi dari Chasm Traps (Connoly,
p353) adalah suatu model dimana diduga ada hubungan antar tipe entiti,
tetapi tidak ada alur relasi antar kedua entiti tersebut.
• Mengecek setiap entiti mempunyai relasi minimal satu
Pada saat pembuatan Entiti Relationship (ER) diagram, pastikan setiap
entiti mempunyai minimal satu relasi dengan entiti yang lain.
Pengecualian umum terhadap aturan ini adalah basis data dengan relasi
tunggal.
Langkah 1.3: Identifikasi dan asosiasikan atribut dengan entiti atau tipe
relasi
Tujuan dari langkah ini adalah untuk mengidentifikasikan dan
mengasosiasikan atribut dari entiti atau tipe relasi.
Simple/Composite Atribut
Sangatlah penting menentukan apakah suatu atribut tersebut simple atau
composite. Composite Atribut adalah atribut yang dibangun dari simple atribut.
28
Sebagai contoh atribut alamat bisa saja dibuat simple dan menyimpan beberapa
detail dari alamat sebagai suatu nilai, contoh: Kebun Jeruk Raya 128, Jakarta,
11530. Bagaimanapun juga, atribut alamat dapat juga merepresentasikan
sebuah composite atribut, yang terdiri dari beberapa detail yang mempunyai
nilai terpisah dalam atribut jalan (“ Kebun Jeruk Raya 128”), kota (“Jakarta”),
kode pos (“11530”). Atribut alamat dapat dijadikan simple atau composite
atribut tergantung kebutuhan user.
Jika user tidak membutuhkan detail dari atribut alamat seperti nama
jalan, kota, kode pos, dsb maka sebaiknya atribut alamat tersebut tetap dibuat
sebagai simple atribut. Sedangkan jika user membutuhkan detail dari atribut
alamat seperti nama jalan, kota, kode pos, dsb maka sebaiknya atribut alamat
dibuat sebagai composite atribut.
Single/Multi-valued Attribute
Suatu atribut juga dapat mempunyai satu atau lebih nilai, contohnya:
atribut nomor telepon. Seseorang dapat saja mempunyai nomor telepon lebih
dari satu, apabila memang demikian adanya maka dapat disebut Multi-valued
Atributte. Tetapi apabila atribut tersebut hanya mempunyai satu nilai maka
disebut sebagai Single Atributte.
Derived Attribute
Atribut yang nilainya tergantung dengan nilai atribut yang lain, maka
atribut ini disebut sebagai Derived Attribute. Sebagai contoh:
• Umur dari seorang staff
• Banyaknya properti yang dimanage oleh Staff Manager
29
Langkah 1.4: Menentukan Domain Atribut
Tujuan dari langkah ini adalah untuk menentukan domain dari atribut
yang ada di dalam Lokal Konseptual Data Model. Sebagai Contoh, antara lain:
• Atribut dari nomor staff terdiri dari lima karakter tipe string dimana dua
karakter pertama adalah huruf, sedangkan tiga karakter sisa berupa
angka.
• Nilai yang mungkin untuk atribut sex adalah ‘M’ dan ‘F’. Ini
merupakan domain dari atribut yang menggunakan karakter tunggal.
Langkah 1.5: Menentukan Kandidat dan Primary key
Tujuan dari langkah ini adalah mengidentifikasi kandidat key dari
setiap tipe entiti, dan jika memang terdapat lebih dari satu kandidat key, pilih
salah satu untuk menjadi primary key.
Pada saat pemilihan primary key diantara banyak kandidat key,
gunakan petunjuk berikut untuk membantu menseleksi
• Merupakan kandidat key dengan jumlah set yang paling sedikit
• Merupakan kandidat key yang nilainya jarang sekali berubah
• Merupakan kandidat key dengan jumlah karakter paling sedikit
• Merupakan kandidat key dengan jumlah paling sedikit dari nilai
maksimumnya (untuk tipe atribut dengan tipe numerik)
• Merupakan kandidat key yang paling mudah digunakan dari sudut pandang
pengguna
30
Langkah 1.6: Menggunakan Enhanced Modelling Concept (Optional)
Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan
Enhanced Modelling Concept, seperti specialization, generalization,
aggregation, dan composition.
Jika penggunaan pendekatan specialization, maka perhatikan perbedaan
yang terlihat secara maksimal antar entiti satu atau banyak subclasses dari
superclass entiti. Jika anda menggunakan pendekatan generalization, maka
anda akan mengidentifikasi persamaan antara entiti yang ada untuk membentuk
superclass.
Langkah 1.7: Mengecek Redudansi
Tujuan dari langkah ini adalah untuk mengecek apakah ada redudansi
dalam model basis data. Pada langkah ini, dilakukan pengujian Lokal
Konseptual Data Model secara spesifik, apabila ada redudansi maka dapat
dihilangkan dengan dua langkah berikut:
• Menguji kembali hubungan one-to-one (1:1)
• Menghilangkan relasi redudansi
Langkah 1.8: Validasi Model Konseptual Lokal dengan Transaksi User
Tujuan dari langkah ini adalah memastikan bahwa lokal konseptual
model mendukung transaksi yang dibutuhkan oleh user. Pengujian dilakukan
dengan dua pendekatan untuk memastikan bahwa lokal konseptual data model
mendukung transaksi yang dibutuhkan:
• Deskripsikan Transaksi
• Gunakan Alur Transaksi
31
Langkah 1.9: Mereview Lokal Konseptual Data Model dengan user
Tujuan dari langkah ini adalah memastikan bahwa model yang ada
sudah sesuai dengan permintaan user. Hasil akhir dari perancangan konseptual
basis data adalah memproses pembuatan suatu model dari informasi yang akan
digunakan di dalam suatu organisasi, yang independensinya tidak tergantung
dengan apapun.
2.4.2 Perancangan Logikal Basis Data
Perancangan logikal basis data menurut Connoly (2002,p441) adalah
merancang suatu model informasi berdasarkan spesifik model yang ada (seperti
model relasional), tetapi tidak tergantung pada DBMS tertentu dan
pertimbangan fisik lainnya.
Logikal basis data mendesain suatu map untuk setiap lokal konseptual
data. Jika terdapat lebih dari satu pandangan user, maka lokal logikal data
model akan dikombinasikan menjadi suatu global logikal data model yang
merepresentasikan semua pandangan user dari suatu perusahaan.
Langkah 2: Membuat dan Memvalidasi Lokal Logikal Data Model untuk
Setiap Bagian
Langkah 2.1: Menghilangkan Bagian yang Tidak Sesuai dengan Model Relasi
(optional)
Langkah 2.2: Menganalisis Relasi untuk Lokal Logikal Data Model
Langkah 2.3: Memvalidasi Relasi dengan Normalisasi
Langkah 2.4: Memvalidasi Relasi dengan Transaksi User
32
Langkah 2.5: Men-check Integritas Basis Data
Langkah 2.6: Me-review Lokal Logikal Data Model dengan User
Langkah 3: Membangun dan Memvalidasi Global Logikal Data Model
Langkah 3.1 : Menggabungkan Lokal Logikal Data Model menjadi Global
Model
Langkah 3.2 : Memvalidasi Global Logikal Data Model
Langkah 3.3 : Men-check untuk Kemungkinan Pengembangan di Masa Depan
Langkah 3.4 : Mereview Global Logikal Data Model dengan User
Berikut ini detail mengenai langkah-langkah yang disebutkan di atas, antara
lain:
Langkah 2: Membuat dan Memvalidasi Model Data Lokal Logikal untuk
Setiap Bagian
Adapun tujuan dari langkah membuat dan memvalidasi model data
logikal untuk setiap bagian adalah untuk membangun suatu model data lokal
logikal dari suatu model lokal konseptual yang merepresentasikan perusahaan
dan kemudian memvalidasi model ini untuk memastikan strukturnya benar, dan
memastikan bahwa model tersebut mendukung transaksi yang diminta.
Langkah 2.1: Menghilangkan Bagian yang Tidak Sesuai dengan Model
Relasi (Optional)
Tujuan dari langkah ini adalah untuk memperbaiki lokal konseptual
data model dengan menghilangkan fitur yang tidak kompatibel dengan model
relasi.
33
Bagian yang akan dibahas pada langkah ini antara lain:
1. Menghilangkan many-to-many(*:*) tipe relasi binary
2. Menghilangkan many-to-many(*:*) tipe relasi rekursif
3. Menghilangkan Tipe Relasi komplek
4. Menghilangkan Multi-valued atribut
Langkah 2.2: Menganalisis Relasi untuk Lokal Logikal Data Model
Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk lokal
logikal data model yang merepresentasikan suatu entiti, relasinya, dan juga
atribut yang telah diidentifikasi. Adapun pendeskripsian bagaimana relasi dapat
diturunkan dari struktur data model yang ada sekarang, antara lain:
1. Tipe Entiti Kuat
2. Tipe Entiti Lemah
3. One-to-many (1:*) Tipe relasi binary
4. One-to-one (1:1) Tipe relasi binary
5. One-to-one (1:1) Tipe relasi rekursif
6. Superclass/ subclass tipe relasi
7. Many-to-many tipe relasi binary
8. Tipe Relasi Komplek
9. Atribut Multi-valued
Langkah 2.3: Memvalidasi Relasi dengan Normalisasi
Tujuan dari langkah ini adalah untuk memvalidasi relasi dalam lokal
logikal data model dengan menggunakan teknik normalisasi. Tujuan dari
normalisasi itu sendiri adalah sebagai berikut:
34
1. Menghilangkan kumpulan relasi dari inserting, updating, delete
dependency yang tidak diharapkan
2. Mengurangi kebutuhan restrukturisasi kumpulan relasi dan
meningkatkan life spam program aplikasi
3. Membuat model relasional lebih informatif
Tahapan Normalisasi:
1. Normalisasi pertama (1NF) menghilangkan perulangan
2. Normalisasi kedua (2NF) menghilangkan ketergantungan sebagian
3. Normalisasi ketiga (3NF) menghilangkan ketergantungan transitif
4. Normalisasi BCNF, suatu relasi dikatakan BCNF bila didalamnya berisi
atribut yang berfungsi sebagai kandidat key sehingga salah satu dari
kandidat key tersebut menjadi kunci utama.
Langkah 2.4: Memvalidasi Relasi dengan Transaksi User
Tujuan dari langkah ini adalah untuk memastikan bahwa relasi di dalam
lokal logikal data model mendukung transaksi yang diminta user. Pada langkah
ini, pengecekan bahwa relasi yang dibuat di langkah sebelumnya juga
mendukung transaksi ini dan juga pastikan bahwa tidak ada error dalam relasi
yang telah dibuat.
Langkah 2.5: Men-check Integritas Basis Data
Tujuan dari langkah ini adalah untuk mendefinisikan ruang lingkup
integritas yang diperlihatkan kepada user. Dalam hal ini ada 5 tipe dari ruang
lingkup integritas, antara lain:
• Data yang diminta
35
• Domain pembatas atribut
• Entity Integrity
Di dalam relasi dasar, atribut dari primary key tidak boleh null atau
kosong. Suatu primary key merupakan suatu atribut yang
mendefinisikan bahwa setiap record/tuple itu unik satu sama lain.
• Referential Integrity
Bila terdapat foreign key suatu tabel dalam suatu relasi, nilainya harus
sesuai dengan nilai primary key-nya di tabel lain.
• Enterprise Constrains
Aturan tambahan yang dispesifikasi oleh user atau DBA dari suatu
perusahaan.
Langkah 2.6: Me-review Lokal Logikal Data Model dengan user
Tujuan dari langkah ini adalah untuk memastikan bahwa lokal logikal
data model dan membuat dokumentasi yang mendeskripsikan model tersebut
sebagai representasi yang sesuai dengan keadaan sebenarnya.
Langkah 3: Membangun dan Memvalidasi Global Logikal Data Model
Tujuan dari langkah ini adalah untuk mengkombinasikan suatu
individual lokal logikal data model ke dalam suatu global logikal data model
yang merepresentasikan suatu enterprise
Langkah 3.1: Menggabungkan Lokal Logikal Data Model menjadi Global
Model
36
Tujuan dari langkah ini adalah untuk menggabungkan suatu lokal
logikal data model ke dalam suatu global logikal data model dari suatu
enterprise. Beberapa tugas dari pendekatan ini adalah sebagai berikut:
1. Mereview nama dan isi dari suatu entiti / relasi dan kandidat key
2. Mereview nama dan isi dari relasi/foreign key
3. Menggabungkan entiti/relasi dari Lokal Data Model
4. Memasukkan (tanpa penggabungan) entiti/relasi unik pada setiap Lokal
Data Model
5. Menggabungkan relasi/foreign key dari Lokal Data Model
6. Memasukkan (tanpa penggabungan) relasi/foreign key unik pada setiap
Lokal Data Model
7. Mengecek untuk entiti, relasi, foreign key yang hilang
8. Mengecek foreign key
9. Mengecek batasan integritas
10. Membuat global ER/relasi diagram
11. Mengupdate Dokumentasi
Langkah 3.2: Memvalidasi Global Logikal Data Model
Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat
dari global logikal data model dengan menggunakan teknik normalisasi dan
memastikan bahwa relasi yang dibuat mendukung transaksi.
Langkah 3.3: Mengecek untuk kemungkinan pengembangan di masa
depan
37
Tujuan dari langkah ini adalah untuk menentukan apakah ada
perubahan penting yang mungkin terjadi di masa mendatang dan juga
memperhatikan apakah global logikal data model dapat mengakomodasi
perubahan tersebut.
Langkah 3.4: Mereview Global Logikal Data Model dengan User
Tujuan dari langkah ini adalah memastikan bahwa global logikal data
model memang merepresentasikan enterprise yang ada.
2.4.3 Perancangan Fisik Basis Data
Menurut Connoly (2002, p478), merupakan proses yang
mendeskripsikan implementasi basis data pada penyimpanan sekunder. Ini juga
mendeskripsikan relasi dasar, struktur penyimpanan dan metde pengaksesan
yang efektif, bersama dengan batasan integritas yang terkait dan ukuran
keamanan.
Langkah 4: Menerjemahkan Global Logikal Data Model untuk Target
DBMS
Tujuan dari langkah ini adalah untuk membuat suatu skema basis data
relasional dari global logikal data model yang dapat diimplementasikan di
target DBMS.
Langkah 4.1: Desain Relasi Dasar
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan relasi dasar yang diidentifikasikan di global logikal data
model pada target DBMS.
38
Untuk memulai proses desain fisik, pertama-tama dikumpulkan
informasi tentang relasi yang dihasilkan selama perancangan logikal basis data.
Informasi yang diperlukan dapat didapatkan dari kamus data dan definisi dari
relasi dijelaskan menggunakan DBDL (Database Design Language). Untuk
setiap relasi yang diidentifikasikan di global logikal data model, terdapat suatu
definisi yang terdiri dari:
• Nama dari relasi
• Daftar dari atribut yang simpel
• Primary key, alternate key, dan foreign key
• Daftar dari atribut turunan
• Batasan integritas dari setiap foreign key yang diidentifikasi
Dari kamus data, dari setiap atributnya dapat diketahui:
• Domain atribut, yang terdiri dari tipe data, panjang, dan batasan-batasan
pada domain tersebut
• Nilai default optional untuk atribut
• Apakah atribut boleh bernilai null
Langkah 4.2: Desain Representasi Data Turunan ( Derived Data)
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan suatu data turunan pada global logikal data model di target
DBMS.
Atribut yang nilainya didapatkan dari menghitung nilai dari atribut lain
yang diketahui disebut sebagai atribut turunan atau kalkulasi. Sebagai contoh:
• Jumlah staff yang bekerja di cabang kantor tertentu
39
• Total gaji bulanan dari semua staff
• Jumlah properti yang ditangani oleh seorang staff
Langkah 4.3: Desain Batasan Enterprise
Tujuan dari langkah ini adalah untuk mendesain suatu batasan
enterprise untuk DBMS yang dipakai.
Mengupdate suatu relasi dapat dibatasi oleh aturan-aturan perusahaan
yang ada. Perancangan batasan tersebut tergantung pada DBMS yang
digunakan, fasilitas yang dimiliki oleh sistem dibandingkan dengan DBMS
yang lain. Seperti pada langkah sebelumnya, bila sistem mempunyai aturan
yang sesuai dengan aturan standard SQL, maka beberapa batasan lebih mudah
untuk diimplementasikan.
Langkah 5: Desain Representasi Fisik
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
paling optimal untuk menyimpan relasi dasar dan indeks yang diperlukan untuk
mencapai kinerja yang diinginkan dimana relasi dan data akan disimpan pada
penyimpanan sekunder.
Langkah 5.1: Menganalisis Transaksi
Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari
transaksi yang akan dijalankan di basis data dan untuk menganalisis transaksi
yang penting.
Untuk melakukan perancangan basis data fisik yang efektif, maka perlu
mengetahui tentang transaksi dan query yang akan dijalankan di basis data. Ini
40
meliputi informasi kualitatif dan kuantitatif. Dalam menganalisis transaksi,
dapat diidentifikasi kriteria performansi sebagai berikut:
• Transaksi yang sering digunakan dan mempunyai dampak besar pada
kinerja
• Transaksi yang penting bagi operasi bisnis
• Durasi waktu dalam harian atau mingguan dimana akan ada permintaan
yang tinggi dalam basis data
Langkah 5.2: Memilih Organisasi File
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
efisien untuk setiap relasi dasar. Dalam banyak kasus, DBMS relasional akan
menyediakan sedikit atau bahkan tidak ada pilihan untuk memilih organisasi
file walaupun beberapa mempunyai indeks yang spesifik. Untuk memahami
organisasi file dan indeks, berikut ini adalah beberapa organisasi file yang ada
adalah sebagai berikut:
• Heap
• Hash
• Index Sequential Access Method (ISAM)
• B+-Tree
• Clusters
Langkah 5.3: Memilih Indeks
Tujuan dari langkah ini adalah untuk menentukan apakah
menambahkan indeks akan membantu kinerja dari suatu sistem atau tidak.
Biasanya pemilihan atribut untuk indeks adalah sebagai berikut:
41
• Atribut yang sering digunakan untuk operasi join, dimana akan
membuat operasi ini lebih efisien
• Atribut yang sering digunakan untuk mengakses suatu tuple di dalam
relasi yang ada
Langkah 5.4: Memperkirakan Kebutuhan Disk Space
Tujuan dari langkah ini adalah untuk memperkirakan jumlah disk space
yang dibutuhkan oleh basis data.
Merupakan suatu persyaratan dimana implementasi fisik basis data
harus ditangani oleh konfigurasi hardware terkini. Bahkan bila ini tidak
menjadi masalah, perancang harus menentukan estimasi dari jumlah disk space
yang dibutuhkan untuk menyimpan basis data. Perkiraan penggunaan disk
sangat tergantung dari DBMS yang dipakai dan hardware yang digunakan
untuk mendukung basis data. Secara umum, perkiraan didasarkan pada ukuran
dari tiap tuple dan jumlah tuple dalam relasi.
Langkah 6: Desain Tampilan User
Tujuan dari langkah ini adalah untuk merancang tampilan user yang
diidentifikasikan selama pengumpulan kebutuhan dan analisis pada siklus
hidupa aplikasi basis data relasional.
Langkah 7: Desain Mekanisme Keamanan
Tujuan dari langkah ini adalah untuk merancang ukuran keamanan dari
basis data yang dispesifikasi oleh user. Basis data merupakan sumber
42
perusahaan yang penting maka pengamanan terhadap sumber ini sangatlah
penting. Secara umum, DBMS relasional menyediakan dua tipe pengamanan
basis data, yaitu:
• Keamanan sistem mengatasi masalah akses dan penggunaan basis data
pada level sistem, seperti username dan password.
• Keamanan data mengatasi masalah akses dan penggunaan objek basis
data (seperti relasi dan tampilan) dan tindakan yang dapat user lakukan
pada objek.
43