BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI 2.1 Teori Dasar Sistem Basis Data 2.1.1 Data Menurut Everest (1986, p3), data adalah fakta yang dipresentasikan dengan nilai berupa angka, karakter string, atau symbol yang memiliki arti dalam beberapa konteks. Menurut Turban (2005, p38), data merupakan kumpulan fakta atau deskripsi dasar dari sesuatu, kejadian, aktifitas, dan transaksi, yang diambil, dicatat, disimpan dan dikelompokkan, tetapi tidak diatur untuk menyatakan suatu arti tertentu. Menurut Whitten (2004, p27, p553), data adalah fakta mentah mengenai orang, tempat, kejadian, dan apapun yang penting bagi perusahaan. Dimana setiap fakta sebenarnya, jika berdiri sendiri, relatif tidak memiliki arti. Data merupakan sebuah sumber daya yang harus dikendalikan dan dikelola. Jadi, dapat disimpulkan bahwa data adalah fakta yang dipresentasikan dengan nilai mengenai sesuatu, kejadian, aktifitas, dan transaksi yang perlu dikontrol dan dikelola sehingga dapat berguna bagi suatu pihak/organisasi. 7

8 2.1.2 Basis Data Menurut Turban (2005, p37), basis data merupakan kumpulan file, tabel, relations, dan lain-lain yang saling berhubungan, yang menyimpan data dan asosiasi-asosiasi diantaranya. Menurut Whitten (2004, p548), basis data adalah koleksi dari file yang saling berhubungan. Menurut Connolly dan Begg (2005, p15), basis data adalah sekumpulan data yang saling berhubungan dimana dirancang untuk mencapai informasi yang diperlukan dalam suatu organisasi. Artinya basis data adalah tempat penyimpanan data yang besar dimana bisa digunakan secara simultan atau secara bersamaan oleh banyak departemen dan pemakai lainnya (user). Di dalam basis data semua item data diintegrasikan untuk menghindarkan duplikasi data (redudancy). Basis data tidak hanya mengandung data operasional organisasi, tetapi juga deskripsi dari data tersebut (meta-data). Sehingga dapat disimpulkan bahwa basis data merupakan suatu kumpulan data yang saling berhubungan antara satu dengan yang lainnya, yang dapat digunakan secara simultan atau secara bersamaan oleh banyak user, dan item data pada basis data diintegrasikan untuk menghindarkan duplikasi data. 2.1.2.1 Karakteristik Basis Data Menurut Mannino (2004, p4), basis data memiliki beberapa karakteristik, yaitu :

9 a) Persistent, artinya data berada pada tempat penyimpanan yang stabil seperti pada magnetic disk. Variabel pada computer tidak bersifat persistent karena berada pada memori utama dan akan menghilang seiring ditutupnya program. Persistent juga bukan berarti data akan selamanya ada. Ketika data sudah tidak lagi relevan maka data tersebut akan dibuang atau diarsipkan. b) Shared, artinya basis data dapat mempunyai banyak kegunaan dan banyak user. Basis data menyediakan memori yang umum untuk beragam fungsi dalam suatu organisasi. Kecuali jika dua users mencoba untuk merubah suatu bagian yang sama pada basis data pada saat yang bersamaan, mereka dapat langsung melakukannya tanpa harus menunggu yang lain. c) Interrelated, artinya data tersimpan dalam unit yang terpisah-pisah, tapi dapat dihubungkan untuk menyediakan data yang dibutuhkan. 2.1.3 Sistem Basis Data Menurut Date (2000, p5), pada dasarnya sistem basis data adalah sistem penyimpanan yang telah terkomputerisasi yang secara keseluruhan bertujuan untuk menyimpan informasi dan memungkinkan penggunanya mengambil dan mengubah informasi tersebut pada saat yang dibutuhkan. Komponen-komponen penting dalam sistem basis data yaitu :

10 1. Data Data dalam basis data dapat merupakan data yang single user (hanya satu pengguna yang beroperasi pada basis data) atau multi user, dimana satu atau lebih user beroperasi secara bersama-sama ke dalam basis data. Sehingga data dalam basis data terutama untuk sistem yang besar, harus terintegrasi dan dapat dipakai secara bersamaan. 2. Perangkat Keras (Hardware) Untuk manajemen basis data hanya dibutuhkan mesin standard, namun yang harus diperhatikan adalah kapasitas penyimpanan karena basis data akan membutuhkan kapasitas yang besar. 3. Perangkat Lunak (Software) Piranti lunak untuk sistem basis data disebut DBMS (Database Management System). 4. Pengguna (User) Pengguna yang terlibat dalam komponen DBMS yaitu : a) Database Administrator Bertanggung jawab untuk mengatur manajemen sumber daya data yang meliputi perencanaan basis data, pengembangan dan pemeliharaan standardnya, aturan dan prosedur, dan rancangan basis data konseptual atau logikal. b) Programmer Programmer adalah seseorang atau sekelompok orang yang menjadi tenaga ahli komputer yang berfungsi untuk

11 mengembangkan program-program aplikasi yang diperlukan dalam DBMS. c) End-user (Pengguna Akhir) Yang termasuk dalam kategori pengguna akhir adalah pemilik sistem, para manajer, operator dan sebagainya yang terlibat langsung dalam penggunaan sistem basis data. 2.2 Database Management System (DBMS) Definisi Database Management System (DBMS) menurut Whitten (2004, p554) adalah perangkat lunak khusus yang digunakan untuk membuat, mengakses, mengendalikan, dan mengelola sebuah basis data. Menurut Connolly dan Begg (2005, p16), Database Management System (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, me-maintain, dan mengontrol akses ke basis data. Fasilitas-fasilitas yang pada umumnya disediakan oleh DBMS adalah sebagai berikut (Connolly dan Begg, 2005, p16-17) : a) Pendefinisian basis data menggunakan Data Definition Language (DDL). b) Insert, update, delete dan mengambil data dari basis data yang biasanya menggunakan Data Manipulation Language (DML). c) Penyediaan akses yang terkontrol ke basis data seperti :

12 Sistem keamanan (security system), mencegah pengguna yang tidak berhak mengakses basis data. Sistem integritas (integrity system), memelihara konsistensi data yang disimpan. Sistem kontrol akses yang bersamaan (concurrency control system), mengijinkan akses basis data secara bersamaan. Sistem kontrol perbaikan (recovery control system), mengembalikan basis data ke kondisi konsisten sebelumnya setelah terjadi kegagalan perangkat keras atau perangkat lunak. Katalog pengguna (user-accessible catalog), berisi deskripsi data dalam basis data. 2.2.1 Keuntungan dari DBMS Menurut Connolly dan Begg (2005, p26), keuntungan dari DBMS meliputi : a) Mengontrol duplikasi data. b) Konsistensi data. c) Informasi lebih dari jumlah data yang sama. d) Penggunaan data secara bersamaan. e) Meningkatkan integritas data. f) Meningkatkan keamanan.

13 g) Pelaksanaan standardisasi. h) Skala ekonomi tertentu. i) Skala ekonomi. j) Keseimbangan antara persyaratan yang saling bertentangan. k) Meningkatkan aksesibilitas data dan responsibilitas data. l) Meningkatkan produktivitas. m) Meningkatkan pemeliharaan melalui data yang bebas. n) Meningkatkan konkurensi. o) Meningkatkan backup dan recovery service. 2.2.2 Kerugian dari DBMS Menurut Connolly dan Begg (2005, p29), kerugian dari DBMS meliputi : a) Kompleksitas. b) Memerlukan disk space dan memory yang tidak sedikit. c) Harga dari DBMS yang pada umumnya cukup mahal. d) Biaya hardware tambahan. e) Biaya konversi. f) Performa. g) Dampak yang lebih hebat jika terjadi kegagalan.

14 2.2.3 Structured Query Language (SQL) Menurut Connolly dan Begg (2005, p113), Structured Query Language (SQL) merupakan sebuah contoh dari transform-oriented language, atau sebuah bahasa yang didesain untuk menggunakan relasi untuk mentransformasikan inputs ke output yang dibutuhkan. Sebagai sebuah bahasa, standar ISO SQL memiliki dua komponen utama yaitu : Data Definition Language (DDL) Data Manipulation Language (DML) 2.2.4 Data Definition Language (DDL) Menurut Connolly dan Begg (2005, p40), Data Definition Language (DDL) adalah sebuah bahasa yang memungkinkan DBA atau user untuk mendeskripsikan dan memberi nama entitas, atribut, dan hubungan yang dibutuhkan untuk aplikasi, termasuk batasan-batasan keamanan dan integritasnya. Hasil kompilasi dari Data Definition Language (DDL) adalah seperangkat tabel yang disimpan dalam file spesial yang dinamakan katalog sistem. Katalog sistem ini mengintegrasikan meta-data, data yang menggambarkan objek dalam basis data dan membuatnya menjadi lebih mudah untuk diakses. Statement standar DDL yang utama pada umumnya adalah sebagai berikut (Connolly dan Begg, 2005, p168) :

15 a) CREATE SCHEMA b) CREATE DOMAIN c) CREATE TABLE d) CREATE VIEW e) ALTER DOMAIN f) ALTER TABLE g) DROP SCHEMA h) DROP DOMAIN i) DROP TABLE j) DROP VIEW 2.2.5 Data Manipulation Language (DML) Menurut Connolly dan Begg (2005, p40), Data Manipulation Language (DML) adalah sebuah bahasa yang menyediakan seperangkat operasi untuk mendukung operasi dasar manipulasi data pada data dalam basis data. Operasi manipulasi data biasanya mencakup berikut ini : a) Memasukkan data baru ke dalam basis data (insert). b) Memodifikasi data yang ada di dalam basis data (update). c) Mengambil data yang disimpan di dalam basis data (select). d) Menghapus data yang terdapat di dalam basis data (delete). yaitu : Data Manipulation Language (DML) dapat dibedakan menjadi dua tipe,

16 a) Procedural DML Procedural DML adalah sebuah bahasa yang memungkinkan user untuk memberitahukan kepada sistem akan data yang dibutuhkan dan bagaimana tepatnya data tersebut diambil. Procedural DML tertanam dalam bahasa pemrograman tingkat tinggi dimana menyediakan fasilitas untuk iterasi dan menangani navigasi logika. b) Non-procedural DML Non-procedural DML adalah sebuah bahasa yang memungkinkan user untuk menyampaikan data apa yang diperlukan tanpa perlu menyampaikan bagaimana data tersebut diambil. Pada umumnya, non-procedural DML lebih mudah untuk dipelajari dan digunakan daripada procedural DML. 2.2.6 Fourth Generation Language (4 th GL) Menurut Connolly dan Begg (2005, p42), dibandingkan dengan 3 rd GL yang procedural, 4 th GL adalah non-procedural yaitu pengguna lebih ditekankan pada pendefinisian apa yang akan dikerjakan, daripada bagaimana mengerjakannya. Contoh 4 th GL meliputi : a) Forms generators Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa

17 yang akan disajikan, komponen warna pada layar dan karakteristik lainnya. b) Report generators Membuat laporan yang datanya diambil dari basis data. Memungkinkan pengguna untuk mengambil data yang diperlukan untuk laporan. Lebih menekankan kepada rancangan output, yaitu bagaimana suatu laporan akan disajikan. c) Graphic generators Digunakan untuk mengambil data dari basis data, dan menampilkannya dalam bentuk grafik, seperti bar chart, pie chart, dan lain-lain. d) Application generators Fasilitas untuk menghasilkan program yang berhubungan dengan data, menentukan bagaimana menampilkan fungsi-fungsi. 2.3 Database System Development Lifecycle Siklus hidup pengembangan sistem basis data atau dikenal juga dengan database system development lifecycle (DSDLC) merupakan suatu pendekatan terstruktur untuk mengembangkan sistem basis data. Karena sistem basis data merupakan komponen yang penting dalam sistem informasi suatu perusahaan besar, siklus hidup pengembangan sistem basis data berkaitan erat dengan siklus hidup sistem informasi. (Connolly dan Begg, 2005, p282-p283)

18 Adalah penting untuk mengetahui bahwa tahapan siklus hidup pengembangan sistem basis data tidaklah harus berurutan, tetapi melibatkan sejumlah pengulangan tahapan sebelumnya melalui feed-back loops. Berikut ini akan ditunjukkan tahapan database system development lifecycle (DSDLC) pada gambar di bawah ini : Gambar 2.1 Tahap-tahap database system development lifecycle. (Connolly dan Begg, 2005, p284)

19 2.3.1 Database Planning (Perencanaan Basis Data) Database planning (perencanaan basis data) merupakan aktivitasaktivitas manajemen yang memungkinkan tahap-tahap dalam database system development lifecycle direalisasikan seefisien dan seefektif mungkin (Connolly dan Begg, 2005, p285). Perencanaan basis data harus diintegrasikan dengan keseluruhan sistem informasi suatu organisasi. Ada tiga persoalan pokok yang terlibat dalam perumusan suatu strategi sistem informasi : a) Identifikasi rencana, sasaran dan tujuan perusahaan dengan penetuan kebutuhan sistem informasi. b) Evaluasi sistem infromasi yang sedang berjalan untuk menentukan kelebihan dan kekurangan yang ada. c) Penilaian terhadap peluang IT (Information Technology) apakah mampu menghasilkan keuntungan yang kompetitif. Tahapan dalam perencanaan basis data juga harus menjelaskan : a) Mission statement dari proyek basis data. Mission statement ini menjelaskan tujuan utama aplikasi basis data, juga membantu menjelaskan tujuan proyek basis data, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly dan Begg, 2005, p286). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basis data ini maka diharapkan dapat lebih memfokuskan pekerjaan pada tahap selanjutnya.

20 b) Mission objectives. Selain merumuskan tujuan dari sebuah proyek basis data, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basis data tersebut. Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basis data, dengan asumsi jika basis data mendukung mission objective, maka mission statement juga akan sesuai (Connolly dan Begg, 2005, p286). Di dalam perencanaan basis data juga meliputi perkembangan standar yang akan menentukan bagaimana suatu data akan dikumpulkan, bagaimana format yang harus ditetapkan, lalu dokumentasi apa saja yang akan dibutuhkan, serta bagaimana desain dan implementasi harus dikerjakan nantinya. 2.3.2 System Definition (Pendefinisian Sistem) System definition (pendefinisian sistem) menjelaskan bidang dan batasan aplikasi basis data serta pandangan pengguna (user view) secara umum (Connolly dan Begg, 2005, p286). Hal ini sangat penting dilakukan dalam suatu proses perancangan basis data agar dapat melakukan proses identifikasi mengenai batasan sistem yang akan dirancang, serta bagaimana sistem tersebut akan berhubungan dengan bagian sistem informasi pada organisasi yang lain. Selain itu batasan sistem sebaiknya tidak hanya sesuai dengan bidang dan batasan aplikasi serta pandangan pengguna yang telah ada saja pada saat ini, namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.

21 Pandangan pengguna sangat diperlukan untuk mengidentifikasi informasi-informasi yang dibutuhkan oleh pengguna (user). Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan dan transaksi yang akan dijalankan terhadap data itu (Connolly dan Begg, 2005, p287). 2.3.3 Requirements Collection and Analysis (Pengumpulan Kebutuhan dan Analisis) Pada tahap ini dilakukan proses pengumpulan dan analisa informasi mengenai bagian organisasi yang harus didukung oleh aplikasi basis data, dan penggunaan informasi ini berguna untuk mengidentifikasi persyaratan pengguna terhadap sistem yang baru (Connolly dan Begg, 2005, p288). Tahap ini meliputi pengumpulan dan analisis informasi mengenai bagian perusahaan yang harus dilayani oleh basis data. Ada tiga pendekatan utama untuk pengaturan kebutuhan aplikasi basis data dengan multiple user views, yakni : a) Pendekatan centralized Kebutuhan-kebutuhan untuk setiap user view digabung dalam suatu kumpulan kebutuhan tunggal untuk aplikasi basis data baru.

22 b) Pendekatan view intergration Kebutuhan-kebutuhan untuk setiap user view digunakan untuk membangun sebuah model data yang terpisah untuk merepresentasikan pengguna itu sendiri. Hasil dari model data akan digabung pada tahap perancangan basis data. c) Kombinasi antara centralized dan view integration. Suatu proses resmi dalam menggunakan teknik-teknik seperti wawancara atau kuesioner untuk mengumpulkan fakta-fakta tentang sistem dan kebutuhan-kebutuhannya dinamakan dengan teknik fact-finding (Connolly dan Begg, 2005, p314). Ada lima kegiatan yang dapat dipakai dalam teknik ini, yaitu : 1) Memeriksa dokumentasi Pemahaman terhadap jalannya sistem akan cepat diperoleh dengan memeriksa dokumen-dokumen, formulir, laporan, dan berkas yang terkait dengan sistem yang sedang berjalan pada perusahaan. Dengan pemeriksaan ini diharapkan dapat mengetahui data-data apa saja yang akan disimpan di dalam basis data (Connolly dan Begg, 2005, p317). 2) Wawancara Wawancara bertujuan untuk mengumpulkan fakta-fakta, memeriksa kebenaran fakta yang ada dan mengklarifikasinya, menimbulkan antusiasme, melibatkan pengguna akhir,

23 mengidentifikasi kebutuhan-kebutuhan, dan mengumpulkan ideide dan pendapat (Connolly dan Begg, 2005, p317). Teknik ini memerlukan kemampuan komunikasi yang baik untuk menghadapi pengguna yang memiliki nilai, prioritas, pendapat, motivasi, dan kepribadian yang berbeda-beda. 3) Observasi Pengamatan ini memungkinkan untuk ikut serta atau mengamati seseorang melakukan kegiatan untuk mempelajari sistem. Salah satu faktor pengamatan dapat berhasil adalah dengan mencari informasi sebanyak mungkin tentang aktivitas yang akan diamati serta orang yang melakukan aktivitas tersebut (Connolly dan Begg, 2005, p319). 4) Penelitian Selain melakukan penelitian yang berasal dari dalam organisasi itu sendiri, dapat juga dilakukan pengumpulan informasi yang berasal dari luar organisasi tersebut. Beberapa contoh sumber informasi tersebut antara lain jurnal komputer, buku-buku referensi, dan internet. Sumber informasi tersebut juga dapat digunakan untuk memecahkan masalah serupa (Connolly dan Begg, 2005, p319). 5) Kuesioner Teknik lain yang dapat digunakan untuk mengumpulkan informasi yang dibutuhkan adalah dengan menggunakan

24 kuesioner. Kuesioner adalah suatu dokumen dengan tujuan khusus yang memungkinkan fakta-fakta dikumpulkan dari banyak orang sambil menjaga kontrol terhadap tanggapan yang diberikan (Connolly dan Begg, 2005, p320). 2.3.4 Database Design (Perancangan Basis Data) Perancangan basis data merupakan proses menciptakan perancangan untuk basis data yang akan mendukung operasi dan tujuan perusahaan (Connolly dan Begg, 2005, p291). Terdapat dua pendekatan dalam perancangan basis data (Connolly dan Begg, 2005, p291), yaitu : a) Bottom-up Pendekatan ini dimulai dari tingkat paling dasar dari atribut (yakni properti dari entity dan hubungan relasional) dimana melalui analisis gabungan antara atribut-atribut, dikelompokkan ke dalam relasi-relasi yang merepresentasikan tipe-tipe entity dan hubungan antara entity. Pendekatan ini lebih cocok untuk perancangan basis data yang sederhana dengan jumlah atribut yang relatif kecil. b) Top-down Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan relasional dan entity tingkat tinggi.

25 Perancangan basis data terdiri dari tiga tahap utama (Connolly dan Begg, 2005, p293), yaitu : 1. Conceptual Database Desain (Perancangan Basis Data Konseptual) Perancangan basis data konseptual adalah proses membangun suatu model informasi yang digunakan oleh perusahaan atau organisasi yang tidak tergantung dari pertimbangan fisik (Connolly dan Begg, 2005, p293). 2. Logical Database Design (Perancangan Basis Data Logikal) Perancangan basis data logikal adalah proses pembuatan suatu model informasi yang digunakan pada perusahaan berdasarkan pada model data yang spesifik, tetapi tidak tergantung dari Database Management System (DBMS) yang khusus dan pertimbangan fisik lain (Connolly dan Begg, 2005, p294). 3. Physical Database Design (Perancangan Basis Data Fisikal) Perancangan basis data fisikal adalah suatu proses untuk menghasilkan gambaran dari implementasi basis data pada tempat penyimpanan, menjelaskan dasar dari relasi, organisasi file dan indeks yang digunakan untuk efisiensi data dan menghubungkan beberapa integrity constraints dan tindakan keamanan (Connolly dan Begg, 2005, p294)

26 2.3.5 DBMS Selection (Pemilihan DBMS) Tahapan ini bertujuan untuk memilih DBMS yang tepat untuk mendukung aplikasi basis data, dimana dibutuhkan tambahan beberapa software dan hardware. Berikut ini adalah tahapan utama untuk memilih basis data, yaitu : 1. Define terms of reference of study, cakupan penelitian mengenai pemilihan DBMS menyatakan tujuan dan ruang lingkup penelitian serta tugas-tugas yang harus dilakukan, meliputi deskripsi kriteria (berdasarkan spesifikasi kebutuhan pengguna) untuk mengevaluasi produk DBMS, daftar DBMS yang tersedia dan batasan-batasan serta jadwal waktu untuk penelitiannya. 2. Shortlist two or three products, kriteria-kriteria yang dianggap kritis untuk keberhasilan implementasi yang dapat digunakan untuk evaluasi daftar DBMS yang tersedia. 3. Evaluate products, ada banyak fitur yang dapat digunakan untuk mengevaluasi sebuah produk DBMS, semua bobot nilai dari fitur-fitur tersebut dijumlahkan untuk mendapatkan nilai sebuah produk DBMS tertentu yang akan dibandingkan dengan nilai produk DBMS lainnya. Produk DBMS yang dipilih adalah produk dengan nilai tertinggi. 4. Recommend selection and produce report, tahap akhir dari pemilihan DBMS adalah untuk mendokumentasikan proses dan

untuk menyediakan laporan dan rekomendasi mengenai produk DBMS tertentu. 27 2.3.6 Application Design (Perancangan Aplikasi) Merupakan perancangan user interface dan program aplikasi yang menggunakan dan memproses basis data. Ada dua aspek penting dalam perancangan aplikasi, yakni : a) Transaction Design (Perancangan Transaksi) Transaksi merupakan sebuah aksi, atau serangkaian aksi yang dilakukan oleh seorang pengguna atau program aplikasi yang mengakses atau mengubah isi dari basis data. Tujuan dari perancangan transaksi adalah untuk menetapkan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basis data, yang termasuk : Data yang digunakan dalam transaksi. Karateristik fungsional dari transaksi. Output dari transaksi. Kepentingan pengguna. Nilai yang diharapkan dari pemakaian. Perancangan ini harus dilakukan lebih awal dalam proses perancangan untuk memastikan bahwa basis data yang

diimplementasikan mampu mendukung semua transaksi yang dibutuhkan. Ada tiga jenis transaksi, yaitu : 28 Retrieval transactions, digunakan untuk mendapatkan kembali data untuk ditampilkan di layar atau dalam laporan. Update transactions, digunakan untuk menambah data baru, menghapus data lama, atau memodifikasi data yang ada di dalam basis data. Mixed Transactions, melibatkan retrieval (pemanggilan) dan update (perubahan) data atau kombinasi antara keduanya. b) User Interface Design (Perancangan antarmuka) Sebelum mengimplementasikan suatu form atau laporan, ada perlunya merancang tampilan terlebih dahulu. 2.3.7 Prototyping Merupakan pembuatan suatu model kerja dari aplikasi basis data (Connolly dan Begg, 2005, p304). Suatu prototype adalah model yang bekerja yang tidak mempunyai semua fitur-fitur yang diperlukan atau menyediakan semua fungsionalitas dari sistem terakhir. Tujuan utama dari pengembangan suatu aplikasi basis data prototype adalah memungkinkan pengguna menggunakan prototype tersebut untuk menentukan fitur-fitur dari sistem yang

29 bekerja dengan baik, dan jika mungkin mengusulkan peningkatan atau bahkan fitur-fitur baru pada aplikasi basis data. Ada dua strategi prototyping yang umum digunakan, yaitu : 1) Requirement prototyping, menggunakan suatu prototype untuk menentukan kebutuhan-kebutuhan dari aplikasi basis data yang diusulkan dan ketika kebutuhan tersebut telah lengkap, prototype tersebut disingkirkan. 2) Evolutionary prototyping, digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak dibuang tetapi dengan perkembangan yang lebih jauh menjadi aplikasi basis data yang digunakan. 2.3.8 Implementation (Implementasi) Implementasi merupakan realisasi fisik dari rancangan basis data dan rancangan aplikasi (Connolly dan Begg, 2005, p304). Implementasi basis data dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih, atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsionalitas yang sama dengan saat menyembunyikan pernyataan low-level DDL. Kemudian bagian dari program aplikasi adalah transaksi basis data, yang diimplementasikan dengan menggunakan Data Manipulation Language (DML), yang biasanya sudah terdapat dalam bahasa pemrograman.

30 2.3.9 Data Conversion and Loading Merupakan pemindahan data yang ada ke dalam basis data baru dan mengubah aplikasi yang ada untuk beroperasi pada basis data yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data baru menimpa sistem yang lama. 2.3.10 Testing Merupakan proses pengeksekusian program aplikasi dengan maksud pencarian kesalahan-kesalahan. Sebelum ditunjukkan secara langsung, aplikasi basis data yang baru dikembangkan seharusnya diuji sepenuhnya. Beberapa keuntungan melakukan testing : Menemukan error pada aplikasi dan mungkin juga error pada struktur basis data. Testing mendemonstrasikan apakah basis data dan aplikasi dapat berjalan sesuai dengan kebutuhan performa dan spesifikasi yang diinginkan atau tidak. 2.3.11 Operational Maintenance (Perawatan Operasional) Merupakan proses pengawasan dan pertahanan sistem berikut instalasi. Pada langkah sebelumnya, aplikasi basis data telah diimplementasikan dan diuji sepenuhnya. Sekarang sistem memasuki langkah perawatan, yang melibatkan aktivitas-aktivitas berikut :

31 a) Mengawasi kinerja sistem. b) Mempertahankan dan meng-upgrade aplikasi basis data (ketika dibutuhkan). 2.4 Entity Relationship (ER) Modelling ER Modelling merupakan suatu pendekatan top-down dalam perancangan basis data yang dimulai dengan mengidentifikasi data penting yang disebut entitas (entities) dan relasi/hubungan (relationship) antara data tersebut harus direpresentasikan dalam model (Connolly dan Begg, 2005, p342). 2.4.1 Entity Type Entity type adalah sekumpulan objek yang memiliki properti yang sama, yang didefinisikan oleh perusahaan sebagai keberadaan yang independen (Connolly dan Begg, 2005, p343). Setiap object yang unik dari sebuah entity type dapat disebut sebagai sebuah entity occurrence (Connolly dan Begg, 2005, p345). Entity type dapat diklasifikasikan sebagai strong (kuat) atau weak (lemah) sebagai berikut : a) Strong entity type merupakan suatu entity type yang keberadaannya tidak tergantung kepada entity type yang lain. b) Weak entity type merupakan suatu entity type yang keberadaannya tergantung kepada entity type yang lain.

32 Nama Entity Staff Cabang Gambar 2.2 Representasi diagram entity type Staff dan Cabang 2.4.2 Relationship Type Relationship type adalah sekumpulan entity yang mempunyai hubungan dan memiliki arti (Connolly dan Begg, 2005, p346). Nama Relationship Staff Memiliki Cabang Gambar 2.3 Representasi diagram Cabang memiliki Staff relationship type

33 2.4.2.1 Degree of Relationship Type Degree of relationship type merupakan jumlah entity type yang ikut serta dalam sebuah relationship (Connolly dan Begg, 2005, p347). Beberapa degree of relationship type adalah : a) Binary relationship merupakan hubungan yang terjadi di antara dua entity type. PrivateOwner memiliki PropertyForRent PrivateOwner POwns PropertyForRent Gambar 2.4 Contoh binary relationship b) Ternary relationship merupakan hubungan yang terjada di antara tiga entity type. Staff meregistrasi seorang client pada sebuah branch Staff Register Branch Client Gambar 2.5 Contoh ternary relationship c) Quaternary relationship merupakan hubungan yang terjadi antara empat entity type.

34 Buyer Solicitor Register Seorang solicitor mengurus sebuah bid mewakili seorang buyer dan didukung oleh sebuah financial instution Financial Institution Bid Gambar 2.6 Contoh quaternary relationship 2.4.2.2 Recursive Relationship Recursive relationship merupakan sebuah relationship type dimana entity type yang sama ikut berpartisipasi lebih dari sekali dengan peran yang berbeda (Connolly dan Begg, 2005, p349). Staff [Supervisor] mengawasi (supervises) staff lainnya [Supervisee] Peran Supervises Peran Supervisor Supervisee Staff Gambar 2.7 Contoh recursive relationship

35 2.4.3 Attributes Atribut adalah sebuah properti dari suatu entity type atau relationship type (Connolly dan Begg, 2005, p350). Attribute domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau lebih attributes. Atribut dapat diklasifikasikan sebagai : a) Simple and Composite Attribute Simple attribute adalah sebuah atribut yang tersusun dari sebuah komponen dengan keberadaan yang independen. Simple attribute tidak dapat dipecah lagi menjadi atribut yang lebih kecil, biasanya disebut dengan atomic attribute. Composite attribute adalah attribute yang tersusun dari banyak komponen, dimana setiap komponennya memiliki keberadaan yang independen. Composite attribute dapat dipecah lagi menjadi komponen-komponen idependen yang lebih kecil. b) Single-Valued and Multi-Valued Attributes Single-valued attribute merupakan suatu atribut yang memiliki sebuah nilai untuk setiap keberadaan sebuah entity type. Multi-valued attribute merupakan suatu atribut yang memiliki banyak nilai untuk setiap keberadaan sebuah entity type. c) Derived Attributes Derived attribute merupakan suatu atribut yang merepresentasikan suatu nilai yang bisa didapat dari nilai sebuah

atau kumpulan attribute yang berhubungan, tetapi tidak harus dalam entity type yang sama. 36 2.4.4 Keys Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly dan Begg, 2005, p352). Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas (Connolly dan Begg, 2005, p353). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly dan Begg, 2005, p353). Pada sebuah tipe entitas biasanya terdapat lebih dari satu candidate key yang salah satunya harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut, jumlah minimal atribut yang diperlukan, dan keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih menjadi primary key, atau biasa disebut dengan secondary key (Whitten, 2004, p298). Foreign key adalah sebuah primary key pada sebuah entitas yang digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship (Whitten, 2004, p301). 2.4.5 Structural Constraints Multiplicity merupakan jumlah kemunculan yang mungkin dari sebuah entity type yang mungkin berhubungan dengan kemunculan tunggal dari sebuah

37 entity type-entity type yang berhubungan melalui relasi tertentu (Connolly dan Begg, 2005, p356). Beberapa jenis relasi berdasarkan multiplicity yang dimiliki, yaitu : 1. Relasi one-to-one (1:1) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal satu. Gambar 2.8 Notasi relasi one-to-one 2. Relasi one-to-many (1:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-banyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal satu. Gambar 2.9 Notasi relasi one-to-many

38 3. Relasi many-to-many (*:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyak-banyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut. Gambar 2.10 Notasi relasi many-to-many 2.4.6 Crow s Foot Data Model Dari beberapa pilihan yang tesedia untuk menggambarkan cardinality, notasi crow s foot merupakan yang paling diminati. Crow s foot menunjukkan baik cardinality minimum dan maksimum dalam suatu format grafik yang jelas. Simbol multiplicity-nya intuitif dan mudah dimengerti oleh pembaca non-teknis. Notasi crow s foot sebaiknya digunakan dalam seluruh diagram model data konseptual yang akan ditinjau oleh pengguna bisnis. Notasi ini juga cocok untuk digunakan dalam model desain basis data fisikal (Stewart, 2008). Pada pengerjaan penulisan ini akan digunakan model data Crow s Foot pada Entity Relationship Diagram yang akan dibuat.

39 Gambar 2.11 Contoh Crow s foot data model Berikut merupakan representasi cardinality pada Crow s Foot data model : Gambar 2.12 Cardinality pada Crow s foot data model 2.5 Perancangan Basis Data Menurut Connolly dan Begg (2005, p438), metodologi perancangan basis data merupakan pendekatan terstruktur yang menggunakan bantuan prosedur, teknik, alat-alat, dan dokumentasi untuk mendukung dan memfasilitasi proses perancangan basis data. Metodologi perancangan basis data terbagi atas tiga tahap perancangan, yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. Meskipun langkah-langkah dalam metodologi digambarkan secara proses yang

40 berurutan, perlu ditekankan bahwa tidak berarti metodologi tersebut harus dibuat secara berurutan. Seringkali pengetahuan yang didapat pada suatu tahap mempengaruhi keputusan yang telah diambil di tahap sebelumnya. 2.5.1 Perancangan Konseptual (Conceptual Design) Conceptual database design adalah proses membangun model informasi yang digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly dan Begg, 2005, p439). Pertimbangan fisik yang dimaksud meliputi DBMS yang akan digunakan, program aplikasi, bahasa pemrograman, platform perangkat keras, performa, dan pertimbangan fisik lainnya. Langkah-langkah dalam metodologi conceptual database design adalah : Langkah 1 Membangun Model Data Konseptual Bertujuan untuk memecah rancangan menjadi tugas-tugas yang dapat diatur dengan memeriksa sudut pandang yang berbeda dari pengguna di dalam organisasi (Connolly dan Begg, 2005, p442). Hasil dari langkah ini berupa pembuatan satu atau lebih local conceptual data model yang merupakan penggambaran yang tepat dan lengkap dari suatu organisasi dilihat dari para pengguna yang berbeda. Tugas-tugas yang dilakukan pada langkah ini terdiri dari : Langkah 1.1 Mengidentifikasi entity types Entity type dapat dikenali dengan mengidentifikasikan kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek

besar seperti orang, tempat, benda atau konsep. Alternatif lain adalah dengan mencari objek yang keberadaannya bebas. 41 Langkah 1.2 Mengidentifikasi relationship type Bertujuan untuk mengidentifikasi relationship yang penting yang ada antara entity types yang telah diidentifikasi sebelumnya. Relationship type diidentifikasikan dengan mencari kata kerja atau suatu kata yang berhubungan dengan kata kerja. Langkah 1.3 Mengidentifikasi dan menghubungkan attributes dengan entity atau relationship types Tujuannya adalah untuk menghubungkan atribut dengan entity dan relationship types yang tepat. Dalam tahap ini juga dilakukan identifikasi composite attributes, single-valued/multi-valued attributes, dan derived attributes. Langkah 1.4 Menentukan attribute domains Menentukan domain atribut dalam model data konseptual. Domain adalah sekumpulan nilai-nilai dari satu atau lebih atribut yang menggambarkan nilainya. Sebagai contoh nilai yang mungkin untuk atribut jenis kelamin dari entitas karyawan adalah L atau W.

42 Langkah 1.5 Menentukan candidate, primary, dan alternate key attribute Tujuannya untuk mengidentifikasi candidate key untuk tiap-tiap tipe entitas dan jika ada lebih dari satu candidate key maka pilih satu untuk menjadi primary key dan sisanya dapat dijadikan alternate key. Langkah 1.6 Mempertimbangkan penggunaan enchance modelling concepts (langkah opsional) Langkah ini bertujuan untuk menentukan penggunaan specialization, generalization, aggregation, dan composition. Specialization merupakan suatu proses memaksimalkan perbedaan-perbedaan antara anggota-anggota sebuah entitas dengan cara mengidentifikasi karakteristik yang membedakan entitas tersebut (Connolly dan Begg, 2005, p374). Generalization merupakan suatu proses meminimalkan perbedaan-perbedaan antara entitas-entitas dengan cara mengidentifikasi sifat umum pada entitas-entitas tersebut (Connolly dan Begg, 2005, p374). Aggregation menggambarkan relationship has-a atau is-partof antara tipe entitas dimana yang satunya mewakili whole dan yang satunya lagi mewakili part (Connolly dan Begg, 2005, p383).

43 Composition digunakan untuk merepresentasikan penggabungan antara tipe-tipe entitas yang memiliki kepemilikan yang kuat dan hubungan yang penting antara whole dan part. Langkah 1.7 Memeriksa model akan adanya redudansi Bertujuan memeriksa conceptual model untuk menghindari adanya redudansi atau pengulangan data dalam model. Ada dua kegiatan yang dapat dilakukan pada tahap ini : a) Memeriksa kembali one-to-one relationship (1:1) Kemungkinan ada lebih dari satu entitas yang menggambarkan objek yang sama dalam organisasi. Oleh karena itu, entitasentitas tersebut harus digabungkan. b) Menghilangkan relasi yang redundan Suatu relationship menjadi redundan jika informasi yang sama dihasilkan melalui relationship yang lainnya. Untuk meminimalkan data model maka relationship yang redundan harus dihilangkan. c) Mempertimbangkan dimensi waktu Dimensi waktu dalam relationships penting saat mengukur adanya redudansi. Yang dimaksud disini adalah hubungan antar entitas yang mungkin saja terjadi pada waktu yang berbeda.

44 Langkah 1.8 Memvalidasi model konseptual terhadap user transactions Memastikan model konseptual telah mendukung transaksitransaksi yang dibutuhkan. Tahap ini dapat dilakukan dengan dua cara, yaitu : a) Mendeskripsikan transaksi Dengan pendekatan ini berarti akan diperiksa semua informasi (entitas, relationship, dan atribut) yang dibutuhkan oleh setiap transaksi apakah telah disediakan dalam model, dengan mendokumentasikan setiap kebutuhan transaksi. b) Menggunakan transaction pathways Pendekatan ini untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada ER diagram. Langkah 1.9 Review model data konseptual dengan user Mengadakan review model data konseptual dengan pengguna sistem untuk memastikan model data tersebut secara tepat menggambarkan transaksi dan kebutuhan data secara nyata dalam perusahaan.

45 2.5.2 Perancangan Logikal (Logical Design) Desain basis data logikal adalah proses membangun model informasi yang digunakan organisasi berdasarkan model data tertentu, tetapi tidak tergantung dari Database Management System (DBMS) dan pertimbangan fisik lainnya (Connolly dan Begg, 2005, p439). Langkah-langkah dalam metodologi logical database design yaitu : Langkah 2 Membangun dan validasi logical data model Tujuannya adalah untuk membangun sebuah logical data model dari sebuah conceptual data model yang mewakili pandangan tertentu dari organisasi dan kemudian memvalidasi model ini untuk memastikan bahwa strukturnya benar (dengan menggunakan teknik normalisasi) dan untuk memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan. Kegiatan yang dilakukan pada langkah ini meliputi : Langkah 2.1 Membentuk relasi untuk logical data model Bertujuan untuk menyaring conceptual data model sehingga fitur-fitur yang tidak sesuai dengan model relasional dihilangkan. Langkah tersebut antara lain dilakukan terhadap : 1) Strong entity types Untuk semua entitas dengan jenis kuat, buatlah sebuah relationship yang memiliki semua atribut sederhana yang dimilikinya. Untuk composite attribute, hanya sertakan atribut pokoknya saja.

46 2) Weak entity types Untuk setiap entitas dengan jenis lemah, buatlah sebuah relationship yang memiliki semua atribut sederhana yang dimilikinya. Primary key dari entitas ini belum dapat ditentukan sampai relationship-nya dengan entitas kuat ditentukan. 3) One-to-many (1:*) binary relationship types Pada relationship jenis ini, entitas pada one side kita anggap sebagai entitas induk sedangkan entitas pada many side dianggap sebagai entitas anak. Untuk merepresentasikan hubungan ini, kita kirimkan primary key dari entitas induk sebagai foreign key pada entitas anak. 4) One-to-one (1:1) binary relationship types Relasi 1:1 lebih sulit ditentukan hubungannya karena cardinality dan participation constraints juga akan menentukan dalam mengidentifikasi entitas induk dan anak dalam relationship ini. i. Mandatory participation pada kedua sisi Pada kasus ini, kita harus menggabungkan kedua entitas yang memiliki relationship jenis ini dan memilih salah satu dari kedua primary key sebagai primary key yang baru.

47 ii. Mandatory participation pada satu sisi Pada kasus ini, kita bisa mengidentifikasikan entitas yang berada pada sisi optional participation sebagai entitas induk, sedangkan yang berada pada sisi mandatory participation sebagai entitas anak. Seperti pada langkah sebelumnya, kita kirimkan primary key dari entitas induk sebagai foreign key pada entitas anak. iii. Optional participation pada kedua sisi Pada kasus ini, pemilihan induk dan anak bisa berubah-ubah. Untuk bisa menentukan, maka kita harus mencari sisi optional participation mana yang lebih mendekati sebagai mandatory participation. Pemecahan untuk relasi ini sangat tergantung dengan kondisi data yang ada. 5) One-to-one (1:1) recursive relationship Untuk pemecahan hubungan ini, dapat digunakan cara yang sama dengan yang telah diterapkan pada 1:1 relationship. 6) Superclass/subclass relationship Untuk setiap superclass/subclass relationship dalam data model konseptual, kita mengidentifikasikan entitas superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam

48 merepresentasikan relationship sebagai salah satu atau lebih relationships. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointness dan participation constraint pada superclass/subclass relationship apakah subclass terlihat dalam distinct relatonship dan jumlah participant dalam superclass/subclass relationship. 7) Many-to-many (*:*) binary relationship types Dengan memecah relationship yang mengandung many-tomany (*:*) untuk mengidentifikasikan sebuah entitas tengah (intermediate entity) sehingga relationship ini digantikan dengan dua buah one-to-many (1:*) relationship, dengan entitas tengah berada di antara dua buah entitas yang lama. 8) Complex relationship types Complex relationship types dihilangkan dengan memecah relationship tersebut untuk mengidentifikasikan entitas tengah (intermediate entity). Kemudian complex relationship ini akan digantikan dengan beberapa one-to-many (1:*) binary relationship. 9) Multi-valued attributes Multi-valued attributes dapat dihilangkan dengan memecah atribut tersebut untuk mengidentifikasikan sebuah entitas. Setelah itu, kirimkan primary key pada entitas induk sebagai foreign key pada entitas anak.

49 Langkah 2.2 Validasi relasi dengan meggunakan normalisasi Normalisasi merupakan suatu teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan, sesuai dengan kebutuhan data dari suatu perusahaan (Connolly dan Begg, 2005, p388). Tujuan dari normalisasi adalah untuk meminimalkan redudansi data dan update anomalies, menciptakan representasi data, hubungan antar data dan constraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi yang ada. Pada dasarnya, proses normalisasi dilakukan untuk meminimalkan redudansi data dan update anomalies. Menurut Connolly dan Begg (2005, p391), update anomalies dapat dibagi menjadi tiga jenis yaitu : a) Insert anomaly merupakan kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity constraint. b) Delete anomaly merupakan kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan data lain dari tabel tersebut. c) Modification anomaly merupakan kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali.

50 Tiga tingkatan normalisasi yang dijadikan acuan penulisan skripsi ini yaitu : 1) First Normal Form (1NF) Suatu relasi dikatakan 1NF jika titik temu tiap baris dan kolom pada relasi tersebut mengandung satu dan hanya satu nilai (Connolly dan Begg, 2005, p403). 2) Second Normal Form (2NF) Relasi dikatakan 2NF jika relasi tersebut berada pada 1NF dan setiap atribut yang bukan primary key bergantung penuh (fully functionally dependent) terhadap primary key (Connolly dan Begg, 2005, p407). Functional dependency terjadi jika A dan B adalah atribut dari sebuah relasi, B dikatakan functionally dependent terhadap A (A B), jika setiap nilai dari A diasosiasikan dengan tepat satu nilai dari B. Full functional dependency terjadi jika A dan B merupakan atribut dari suatu relasi, B dikatakan full functional dependent terhadap A jika B functionally dependent terhadap A, tetapi bukan merupakan subset dari A. 3) Third normal form (3NF) Relasi dikatakan 3NF jika relasi tersebut dalam bentuk 1NF dan 2NF, dan tidak ada atribut bukan primary key bergantung secara transitif (transitively dependent) terhadap primary key (Connolly dan Begg, 2005, p409). Transitive

51 dependency merupakan sebuah kondisi dimana A, B, dan C merupakan atribut dari relasi yang jika A B dan B C maka C disebut bergantung secara transitif terhadap A melalui B (Connolly dan Begg, 2005, p397). Langkah 2.3 Validasi relasi terhadap user transactions Memastikan relasi dalam model data logikal telah mendukung transaksi yang diperlukan. Pada tahap ini, akan dilakukan pengecekan terhadap relasi yang sudah terbentuk sebelumnya, apakah sudah dapat memproses transaksi tersebut dan pastikan tidak ada kesalahan pada saat membuat relasi. Langkah 2.4 Menentukan integrity constraint Integrity constraint adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten (Connolly dan Begg, 2005, p474). Berikut merupakan tipe dari integrity constraints : a) Required data ( Data yang diperlukan ) Beberapa atribut harus selalu berisi nilai yang benar, tidak dapat bernilai null. b) Attribute domain constraint Setiap atribut memiliki domain, yaitu himpunan nilai yang dibolehkan (Connolly dan Begg, 2005, p475).

52 c) Multiplicity Multiplicity merepresentasikan batasan jumlah yang ada antara data yang ada di basis data. d) Entity integrity Primary key dari sebuah entitas tidak boleh bernilai null. e) Referential integrity Jika sebuah foreign key memiliki nilai, maka nilai tersebut harus menunjuk ke sebuah baris yang ada pada relasi parent. f) General constraint Kegiatan update entitas dibatasi oleh peraturan atau kebijakan organisasi yang mengatur transaksi yang diwakilkan oleh update yang dilakukan. Langkah 2.5 Meninjau kembali local logical data model dengan user Memastikan bahwa logical data model dan dokumentasi pendukung yang menggambarkan model merupakan perwakilan yang benar dari pandangan pengguna.

53 Langkah 2.6 Menggabungkan logical data model menjadi global model (langkah opsional) Menggabungkan local logical data models menjadi satu global logical data model yang merepresentasikan seluruh user views dari basis data. Langkah ini hanya perlu dilakukan apabila saat desain dilakukan dengan user views yang terpisah berdasarkan masing-masing user. Langkah 2.7 Memeriksa untuk perkembangan mendatang Bertujuan untuk menentukan apakah akan ada perubahan yang signifikan pada masa mendatang dan memperkirakan apakah logical data model yang sekarang dapat mengakomodasi perubahan tersebut. 2.5.3 Perancangan Fisikal (Physical Design) Perancangan basis data fisikal merupakan proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mendapatkan akses data yang efisien, serta setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan (Connolly dan Begg, 2005, p294).

54 Langkah 3 Menterjemahkan Logical Data Model untuk DBMS Sasaran Langkah ini bertujuan untuk menghasilkan skema basis data relasional bagi global logical data model yang dapat diimplementasikan pada DBMS sasaran. Langkah 3.1 Membuat base relations Memutuskan bagaimana merepresentasikan relasi-relasi yang telah diidentifikasikan pada logical data model pada DBMS yang akan dipakai. Langkah 3.2 Merancang representasi dari data yang diperoleh Memutuskan bagaimana merepresentasikan derived data yang ada dalam logical data model pada DBMS yang akan dipakai. Langkah 3.3 Merancang general constraints digunakan. Merancang batasan-batasan umum untuk DBMS yang akan Langkah 4 Merancang file organizations dan indexes Menentukan organisasi file optimal untuk menyimpan relasi dasar dan indeks yang diperlukan untuk mencapai performa yang dapat diterima, yaitu cara dimana relasi dan entitas akan dilaksanakan di secondary storage.

55 Langkah 4.1 Analisis transaksi Memahami fungsi-fungsi dari transaksi yang akan dijalankan pada basis data dan menganalisis transaksi yang penting. Dalam menganalisis transaksi, kita mencoba mengidentifikasikan kriteria performa, seperti : Transaksi yang akan berjalan secara terus-menerus dan yang akan mempengaruhi secara signifikan pada performa. Transaksi yang penting bagi operasi bisnis. Waktu selama sehari/seminggu ketika akan terjadi permintaan yang tinggi dibuat dalam basis data (disebut peak load). Langkah 4.2 Memilih file organizations Tujuan langkah ini adalah menetukan organisasi file yang efisien untuk tiap-tiap relasi dasar jika diperbolehkan oleh DBMS yang akan digunakan. Beberapa tipe organisasi file adalah : Heap Hash ISAM B + -Tree Cluster

56 Langkah 4.3 Memilih index Memutuskan apakah dengan menambahkan index akan meningkatkan performa dari sistem. Langkah 4.4 Memperkirakan disk space yang diperlukan Memperkirakan jumlah disk space yang diperlukan basis data. Estimasi pemakaian disk tergantung pada DBMS dan perangkat keras yang digunakan untuk mendukung basis data. Langkah 5 Merancang user views Merancang view pengguna yang telah diidentifikasi selama pengumpulan persyaratan dan tahap analisis dari database system development lifecycle. Langkah 6 Merancang mekanisme keamanan Merancang mekanisme keamanan untuk basis data yang ditentukan user selama tahap requirements dan collections pada database systems development lifecycle. Langkah 7 Mempertimbangkan pengenalan redudansi terkontrol Menentukan apakah dengan adanya redudansi yang terkontrol dengan melonggarkan aturan normalisasi akan meningkatkan kinerja sistem. Misalnya,