BAB 2 LANDASAN TEORI

Transkripsi

1 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 (Filebased 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 2.1.1 Pengertian Basis Data Menurut Connoly (2002, p14), basis data adalah kumpulan dari datadata 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 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

3 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

4 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 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

5 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

6 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

7 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 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

8 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

9 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

10 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

11 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 baganbagan 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

12 Perencanaan Basis Data Definisi Sistem Analisa dan Pengumpulan Kebutuhan Pemilihan DBMS (Optional) Database Design Conceptual Database Design Logical Database Design Perancangan Aplikasi Physical Database Design Prototyping (Optional) Implementasi Data Conversion And Loading Testing Operational Maintenance Gambar 2.1 Siklus Hidup Aplikasi Basis Data (Sumber: Connoly, 2002, p272) 19

13 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

14 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

15 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

16 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 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 multiuser, antara lain: Authorisasi Merupakan pemberian hak kepada seseorang untuk dapat mengakses sistem secara sah 23

17 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

18 beberapa disk independent untuk meningkatkan kehandalannya dan pada waktu yang sama juga meningkatkan kinerjanya 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

19 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 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

20 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

21 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

22 Sebagai contoh atribut alamat bisa saja dibuat simple dan menyimpan beberapa detail dari alamat sebagai suatu nilai, contoh: Kebun Jeruk Raya 128, Jakarta, 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 ( ). 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

23 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

24 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

25 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 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

26 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

27 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

28 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

29 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

30 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

31 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 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

32 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

33 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

34 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

35 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

36 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