BAB 2
LANDASAN TEORI
2.1 Pengertian Basisdata
Menurut Turban (2003,p16), basisdata merupakan kumpulan file atau record yang terorganisir yang menyimpan data beserta hubungan diantara data-data tersebut.
Menurut Hoffer (2002,p4), basisdata adalah kumpulan data yang terorganisir yang secara logika berkaitan. Terorganisir maksudnya data di strukturkan sehingga mudah untuk disimpan, dimanipulasi dan diperoleh oleh pengguna. Berkaitan maksudnya data menggambarkan daerah asal (domain) kepentingan tertentu bagi kelompok pengguna dan pengguna dapat menggunakan data untuk menjawab pertanyaan seputar domain itu.
Menurut Maslakowski & Butcher (2000,p10-11), basisdata adalah rantaian dari file terstruktur dalam sebuah komputer yang terorganisasi secara efisien. File-file ini dapat menyimpan banyak sekali informasi yang dapat dimanipulasi dan dipanggil ketika diperlukan.
Menurut Ramakrishnan & Gehrke (2003,p4), basisdata adalah kumpulan data yang menjelaskan satu atau lebih relasi dari sebuah organisasi.
Menurut Connolly dan Begg (2005, p15), basisdata adalah sekumpulan data yang saling berhubungan dimana dirancang untuk mencapai informasi yang diperlukan dalam suatu organisasi. Artinya basisdata adalah tempat penyimpanan data yang besar dimana bisa digunakan secara simultan atau secara bersamaan oleh banyak departemen dan pemakai lainnya (user). Di dalam basisdata semua item data diintegrasikan untuk menghindarkan duplikasi data. Basisdata tidak hanya mengandung data operasional organisasi, tetapi juga deskripsi dari data tersebut.
2.1.1 Pengertian Sistem Basisdata
Date (2000,p5) mengemukakan bahwa sistem basisdata pada dasarnya merupakan sistem penyimpanan record yang terkomputerisasi. Dengan kata lain, sistem basisdata merupakan sistem komputerisasi yang bertujuan untuk menyimpan informasi dan memungkinkan pemakai untuk mengambil kembali dan memperbaharui informasi tersebut sesuai dengan keinginan dan permintaan.
Sistem basisdata mempunyai tiga komponen utama, yaitu : hardware (perangkat keras), software (perangkat lunak), dan user (pengguna). Hardware
(perangkat keras) pada sistem basisdata terdiri dari secondary storage device (perangkat penyimpanan sekunder), I/O devices (perangkat input output), database machines (mesin basisdata). Software (perangkat lunak) secara umum berfungsi membantu pengguna basisdata untuk melakukan operasi terhadap data. User (pengguna) merupakan orang yang menggunakan sistem basisdata.
2.1.2 Database Management Sistem ( DBMS )
Menurut Silberchatz, Korth, dan Sudarshan (2006,p1) Database Management System (DBMS) adalah kumpulan data yang saling berhubungan dan sekumpulan program untuk mengakses data tersebut. Kumpulan data ini biasanya menunjuk ke basisdata yang berisi informasi perusahaan.
Menurut Elmasri & Navathe (2000,p5), Database Management System (DBMS) adalah sekumpulan program yang mengizinkan pengguna untuk membuat dan memelihara basisdata.
Menurut Connolly dan Begg (2005, p16), sistem manajemen basisdata (Database Management System) disingkat menjadi DBMS adalah sistem perangkat lunak yang dapat memungkinkan pemakai untuk mendefinisikan, membuat, dan memelihara database dan menyediakan kontrol akses untuk database tersebut. DBMS berinteraksi dengan program aplikasi pemakai dan basisdata.
DBMS memiliki fasilitas sebagai berikut :
a. Data Definition Language (DDL) : memungkinkan pemakai untuk membuat spesifikasi tipe data, mendefinisikan basisdata, struktur data dan constraint data untuk disimpan dalam basisdata.
b. Data Manipulation Language (DML) : memperbolehkan pemakai untuk memasukkan, memperbaharui, menghapus, dan mengirim atau mengambil data dari basisdata.
c. DBMS menyediakan controlled access ke basisdata, misalnya :
Security system, mencegah adanya akses ke basisdata oleh pengguna yang tidak memiliki otoritas.
1) Integrity system, memelihara konsistensi data yang disimpan dalam basisdata.
2) Concurrency control system, memungkinkan akses secara bersama-sama pada basisdata.
3) Recovery control system, mengembalikan basisdata ke kondisi sebelumnya yang konsisten.
4) User-accessible catalog, berisikan deskripsi dari data di dalam basisdata.
Menurut Kadir (2000, p17), DBMS diartikan sebagai suatu program komputer yang digunakan untuk memasukan, mengubah, menghapus, memanipulasi, dan memperoleh data dan informasi dengan praktis dan efisien.
Menurut Ramakrishnan dan Gehrke (2003, p4), DBMS adalah piranti lunak yang dirancang untuk membantu dalam memelihara dan memanfaatkan kumpulan data dalam jumlah besar, dan kebutuhan untuk sistem maupun pemakaiannya yang berkembang dengan cepat.
Menurut Gerald V. Post (2005, p2), DBMS adalah piranti lunak yang mendefinisikan sebuah basisdata, menyimpan data, mendukung bahasa query, membuat laporan dan menciptakan layar masukan data.
2.1.2.1 Komponen Database Management Sistem (DBMS)
Menurut Connolly dan Begg (2005, p18), ada lima komponen utama dari DBMS, yaitu hardware, software, data, prosedur dan sumber daya manusia (SDM).
a. Hardware (Perangkat Keras)
Suatu DBMS dan aplikasinya menggunakan hardware untuk menjalankan aplikasinya. Hardware dapat disusun dari suatu komputer tunggal, suatu mainframe tunggal, suatu jaringan komputer.
b. Software (Piranti Lunak)
Komponen Piranti Lunak meliputi software DBMS dan program aplikasi beserta sistem operasi (OS), termasuk piranti lunak tentang jaringan, bila DBMS digunakan dalam jaringan seperti LAN.
c. Data
Data merupakan komponen terpenting dalam DBMS khususnya sudut pandang dari end user mengenai data. Data pada sebuah basisdata baik single-user sistem maupun multi-user sistem harus terintegrasi dan dapat digunakan bersama.
d. Prosedur
Prosedur berupa instruksi dan aturan-aturan yang membuat rancangan dan menggunakan basisdata. Pengguna sistem dan staff yang mengatur kebutuhan basisdata di dokumentasikan dalam prosedur yang berupa petunjuk penggunaan sistem atau petunjuk menjalankan sistem. Instruksi tersebut misalnya bagaimana untuk:
a) Log on ke DBMS.
b) Menggunakan sebagian fasilitas DBMS atau program aplikasi. c) Start dan stop DBMS.
d) Membuat duplikat basisdata.
e) Menangani kesalahan pada hardware atau software.
f) Mengubah struktur suatu table dan meningkatkan tampilan. e. Sumber Daya Manusia (SDM)
Komponen terakhir adalah manusia yang terlibat langsung dengan sistem tersebut. Manusia dibedakan menjadi tiga, yaitu:
a) Application Programmers, bertanggung jawab untuk membuat aplikasi basisdata dengan menggunakan bahasa pemrograman yang ada, seperti : C++, Java, Visual Basic dan lain sebagainya.
b) End Users, siapapun yang menggunakan aplikasi.
c) DA (Data Administrator), seorang yang berwenang untuk membuat keputusan strategis dan kebijakan mengenai data yang ada, DBA (Database Administrator), menyediakan dukungan teknis untuk mengimplementasikan keputusan tersebut, dan bertanggung jawab atas keseluruhan kontrol sistem pada tingkat teknis.
2.1.2.2 Fungsi DBMS
Menurut Connolly dan Begg (2005, p48), ada beberapa fungsi dari DBMS adalah sebagai berikut:
1. Data Storage, Retrieval, and Update
Sebuah DBMS harus melengkapi/menyediakan untuk pengguna dengan kemampuan penyimpanan, penelusuran kembali, dan mengubah data dalam basisdata.
2. User-accessible catalog
Sebuah DBMS harus menyediakan catalog yang mendeskripsikan lokasi penyimpanan data dalam basisdata.
3. Transaction Support
DBMS harus menyediakan sebuah mekanisme yang akan menjamin semua kegiatan update yang berhubungan dengan transaksi maupun tidak.
4. Concurrency Control Services
DBMS harus menyediakan sebuah mekanisme untuk menjamin bahwa basisdata ter-update dengan benar ketika seorang pengguna meng-update basisdata, dan pada saat beberapa pengguna meng-update basisdata pada waktu yang bersamaan.
5. Recovery Services
DBMS harus menyediakan sebuah mekanisme untuk memperbaiki basisdata yang rusak karena suatu kejadian.
6. Authorization Services
DBMS harus menyediakan sebuah mekanisme untuk menjamin bahwa hanya pengguna yang diberi otoritas yang dapat mengakses basisdata. 7. Support for Data Communication
DBMS harus mampu berintegrasi dengan software komunikasi. 8. Integrity Services
DBMS harus menyediakan sebuah cara untuk menjamin bahwa data dalam basisdata dan perubahan data, keduanya mengikuti aturan-aturan yang tepat.
9. Services to Promote Data Independence
DBMS harus meliputi fasilitas-fasilitas yang mendukung program-program independensi dari struktur basisdata aktual.
10.Utility Services
DBMS seharusnya menyediakan sekumpulan utility services agar basisdata dapat di administrasi secara efektif.
2.1.2.3 Keuntungan dan Kerugian DBMS
DBMS memungkinkan untuk menciptakan basisdata dalam penyimpanan akses langsung ke komputer, memelihara isinya dan menyediakan isi tersebut bagi pemakai tanpa pemrograman khusus yang mahal. Akan tetapi, sebelum kita memutuskan untuk menggunakan DBMS atau tidak, keuntungan dan kerugiannya harus dipertimbangkan.
Menurut McLeod (2004, p152), keuntungan DBMS adalah sebagai berikut: a) Mengurangi pengulangan data.
Dalam suatu DBMS tidak ada duplikasi data. b) Independensi data.
Spesifikasi data disimpan dalam skema daripada dalam tiap program aplikasi sehingga perubahan dapat dibuat pada struktur data tanpa mempengaruhi data yang lain.
c) Mengintegrasikan data dari beberapa file.
Adanya gabungan data yang terkumpul dalam suatu file. d) Pengambilan data dan informasinya cepat.
Hubungan logis dan DML serta query language memungkinkan pengguna untuk mengambil data dalam hitungan detik atau menit.
e) Meningkatkan keamanan.
Baik DBMS mainframe maupun komputer mikro dapat menyertakan beberapa lapisan keamanan seperti kata sandi (password), direktori pemakai, dan bahasa sandi (encryption). Data yang disimpan dan dikelola dalam DBMS juga lebih aman daripada data lain dalam perusahaan.
Sedangkan kerugian DBMS adalah sebagai berikut : a) Piranti lunak yang mahal
DBMS mainframe masih sangat mahal. b) Konfigurasi perangkat keras yang besar
DBMS memerlukan kapasitas penyimpanan primer dan sekunder yang lebih besar.
c) Mempekerjakan dan mempertahankan staff DBA (Database Administrator)
DBMS memerlukan pengetahuan yang khusus agar dapat memanfaatkan kemampuannya secara penuh.
2.2 Database Languages
2.2.1 Data Definition Language (DDL)
Data Definition Language (DDL) merupakan sebuah bahasa yang memungkinkan Database Administrator (DBA) maupun pengguna untuk menggambarkan dan menamai entity, atribut, dan hubungan yang dibutuhkan pada aplikasi bersamaan dengan beberapa associated integrity dan batasan keamanan
(Connolly, 2005, p40). Hasil dari kompilasi perintah DDL adalah kumpulan tabel yang disimpan dalam file khusus yang disebut Kamus Data (Data Dictionary).
Menurut McLeod (2001, p387), kamus data adalah suatu penjelasan tertulis mengenai data yang berada di dalam basisdata. Kamus data ini dimaksudkan untuk melengkapi pembuatan model proses yang menggunakan diagram alir data (Data Flow Diagram).
Beberapa statement DDL (Connolly, 2005, p169) : 1. Create Table
Untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom.
2. Alter Table
Untuk menambah atau membuang kolom dan constraint. 3. Drop Table
Untuk membuang atau menghapus tabel beserta semua data yang terkait di dalamnya.
4. Create Index
Untuk membuat indeks pada suatu tabel. 5. Drop Index
2.2.2 Data Manipulation Language (DML)
Menurut Connolly (2005, p40), DML (Data Manipulation Language) adalah suatu bahasa yang menyediakan kumpulan operasi yang akan diinginkan untuk mendukung operasi manipulasi data utama pada data yang diperoleh dalam basisdata. Menyediakan operasi dasar manipulasi data pada data yang ada dalam basisdata yaitu:
a) Penyisipan data baru ke dalam basisdata (insertion).
b) Mengubah atau modifikasi data yang disimpan di dalam basisdata (modify).
c) Pemanggilan data yang ada dalam basisdata (retrieve). d) Menghapus data dari basisdata (delete).
Menurut Connolly (2005, p41), kita dapat membedakan DML menjadi 2 tipe yang berbeda yaitu :
a. Procedural DML
Procedural DML adalah suatu bahasa yang memungkinkan pengguna (umumnya programmer) untuk memberi instruksi ke sistem mengenai data apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). Artinya pengguna harus menjelaskan operasi pengaksesan data yang akan digunakan dengan menggunakan prosedur yang ada untuk mendapatkan informasi yang dibutuhkan.
b. Non-Procedural DML
Non-Procedural DML adalah bahasa yang memungkinkan pengguna untuk menentukan data apa yang dibutuhkan dengan menyebutkan spesifikasinya tanpa menspesifikasikan bagaimana cara mendapatkannya.
2.2.3 Fourth Generation Languages
Menurut Connoly (2005, p42), Fourth-Generation Languages (4GLs) adalah bahasa pemrograman non-procedural yang lebih sederhana dibandingkan bahasa pemrograman generasi ke tiga (3GL).Beberapa jenis 4GLs (Connoly, 2005, p42) :
a. Forms Generators
Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa yang akan disajikan, komponen warna pada layar dan karakteristik lainnya.
b. Report Generators
Membuat laporan (report) yang datanya diambil dari database. Memungkinkan user untuk mengambil data yang diperlukan untuk laporan. Lebih menekankan pada rancangan output, yaitu bagaimana suatu laporan akan disajikan.
c. Graphic Generators
Digunakan untuk mengambil data dari basisdata, dan menampilkannya dalam bentuk grafik seperti bar, chart, pie chart, line chart dan lain-lain.
d. Application Generators
Fasilitas untuk menghasilkan program yang berhubungan dengan data, menentukan bagaimana menampilkan fungsi-fungsi.
2.3 Siklus Hidup Aplikasi Basisdata (Database System Development Lifecycle) Untuk merancang aplikasi sistem basisdata diperlukan beberapa tahapan terstruktur yang harus diikuti dan dinamakan dengan Siklus Hidup Aplikasi Basisdata (Database System Development Lifecycle) atau disingkat dengan SDLC. Dikarenakan sistem basisdata adalah komponen dasar dalam sistem informasi organisasi yang lebih besar dan luas, daur hidup aplikasi basisdata berkembang terhubung dengan daur hidup sistem informasi.
Adalah penting untuk mengetahui bahwa tahapan daur hidup sistem informasi tidaklah harus berurutan, tetapi melibatkan beberapa jumlah pengulangan tahap sebelumnya melalui feed-back loops.
Berikut ini akan ditunjukkan tahapan daur hidup aplikasi basisdata pada gambar di bawah ini :
Gambar 2.1 Tahap - Tahap Siklus Hidup Aplikasi Basisdata (Sumber : Connolly, 2005, p284)
2.3.1 Perencanaan Basisdata ( Database Planning )
Perencanaan Basisdata (Database Planning) merupakan aktivitas-aktivitas manajemen yang memungkinkan tahap-tahap dalam aplikasi basisdata direalisasikan
seefisien dan seefektif mungkin (Connolly, 2005, p285). Perencanaan basisdata harus diintegrasikan dengan keseluruhan sistem informasi suatu organisasi. Ada 3 (tiga) persoalan pokok yang terlibat dalam perumusan suatu strategi sistem informasi :
a. Identifikasi rencana, sasaran (goals) dan tujuan perusahaan dengan penentuan kebutuhan sistem informasi.
b. Evaluasi sistem informasi yang sedang berjalan untuk menentukan kelebihan dan kekurangan yang ada.
c. Penilaian terhadap peluang IT apakah mampu menghasilkan keuntungan yang kompetitif.
Tahapan dalam perencanaan basisdata juga harus menjelaskan :
a. Mission statement dari proyek basisdata. Mission statement ini menjelaskan tujuan utama aplikasi basisdata, juga membantu menjelaskan tujuan proyek basisdata, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basisdata secara efektif dan efisien (Connolly, 2005, p286). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basisdata ini maka diharapkan dapat lebih memfokuskan pekerjaan pada tahap selanjutnya.
b. Mission objectives. Selain merumuskan tujuan dari sebuah proyek basisdata, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basisdata tersebut. Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basisdata, dengan asumsi jika basisdata mendukung mission objective, maka mission statement nya juga akan sesuai (Connolly, 2005, p286).
Di dalam perencanaan basisdata 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 Pendefinisian Sistem (System Definition)
Pendefinisian sistem (system definition) menjelaskan bidang dan batasan aplikasi basisdata serta pandangan pengguna (user view) secara umum (Connolly, 2005, p286). Hal ini sangat penting dilakukan dalam suatu proses perancangan basisdata 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 basisdata serta pandangan pengguna yang telah ada saja pada saat ini, namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.
Pandangan pengguna sangat diperlukan untuk mengidentifikasi informasi-informasi yang dibutuhkan oleh pengguna (user). Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basisdata 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, 2005, p287).
2.3.3 Pengumpulan Kebutuhan dan Analisis (Requirements Collection and Analysis)
Pada tahap ini dilakukan proses pengumpulan dan analisa informasi mengenai bagian organisasi yang harus didukung oleh aplikasi basisdata, dan penggunaan informasi ini berguna untuk mengidentifikasi persyaratan pengguna terhadap sistem yang baru (Connolly, 2005, p288).
Tahap ini meliputi pengumpulan dan analisis informasi mengenai bagian perusahaan yang harus dilayani oleh basisdata. Ada 3 (tiga) pendekatan utama untuk pengaturan kebutuhan aplikasi basisdata dengan multiple user views, yakni:
a. Pendekatan centralized
Kebutuhan-kebutuhan untuk setiap user view digabung dalam suatu kumpulan kebutuhan tunggal untuk aplikasi basisdata baru.
b. Pendekatan view integration
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 basisdata.
c. Kombinasi antara centralized dan view integration
Ada banyak cara untuk mengumpulkan informasi pada 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, 2005, p314).
2.3.4 Perancangan Basisdata (Database Design)
Perancangan basisdata merupakan proses menciptakan perancangan untuk basisdata yang akan mendukung operasi dan tujuan perusahaan (Connolly, 2005, p291). Terdapat 2 (dua) pendekatan dalam perancangan basisdata (Connolly, 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 basisdata 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.
Perancangan basisdata terdiri dari 3 tahap utama (Connolly, 2005, p293), yaitu : 1. Perancangan Basisdata Konseptual (Conceptual Database Design)
Perancangan Basisdata Konseptual adalah proses membangun suatu model informasi yang digunakan oleh perusahaan atau organisasi yang tidak tergantung dari pertimbangan fisik (Connolly, 2005, p293).
2. Perancangan Basisdata Logikal (Logical Database Design)
Logical database design 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, 2005, p294). 3. Perancangan Basisdata Fisikal (Physical Database Design)
Physical database design adalah suatu proses untuk menghasilkan gambaran dari implementasi basisdata 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, 2005, p294).
2.3.5 Pemilihan DBMS (DBMS Selection)
Merupakan pemilihan dari suatu DBMS yang tepat untuk mendukung aplikasi basisdata (Connolly, 2005, p295).
Tahap-tahap pemilihan DBMS :
a. Menentukan istilah referensi studi
Istilah referensi studi untuk pemilihan DBMS sudah ditetapkan, penetapan objektif dan ruang lingkup studi, dan tugas-tugas yang harus dilakukan. Dokumen ini juga termasuk deskripsi kriteria yang digunakan untuk mengevaluasi produk DBMS, daftar-daftar produk yang mungkin dipakai, dan semua constraints yang perlu dan skala waktu untuk studi b. Membuat daftar sementara 2 ( dua ) atau 3 ( tiga ) produk
Kriteria yang dipertimbangkan untuk menjadi kritis agar implementasi dapat berjalan lancar dapat digunakan untuk membuat daftar awal persiapan produk DBMS untuk evaluasi. Sebagai contoh, keputusan untuk mengikutsertakan produk DBMS mungkin tergantung pada
anggaran yang tersedia, tingkat dukungan vendor, kesesuaian dengan software lain, dan apakah produk dapat berjalan pada hardware tertentu. Informasi-informasi tambahan lainnya mengenai produk DBMS dapat diperoleh dengan menghubungi pengguna yang menyediakan rincian spesifik tentang seberapa baik dukungan vendor, bagaimana produk dapat mendukung aplikasi tertentu, dan apakah hardware platform tertentu lebih bermasalah dari yang lain. World Wide Web (www) adalah sumber informasi terbaik yang dapat digunakan untuk mengidentifikasi kandidat DBMS yang potensial.
c. Mengevaluasi produk
Ada berbagai fitur yang dapat digunakan untuk mengevaluasi produk DBMS. Sebagai tujuan dari evaluasi, fitur-fitur ini dapat dinilai sebagai kelompok (sebagai contoh, definisi data) atau perorangan (sebagai contoh, ketersediaan tipe data). Fitur-fitur yang memungkinkan untuk evaluasi produk DBMS dikelompokkan berdasarkan data definition (defenisi data), physical definition (defenisi fisik), accessibility (pengaksesan), transaction handling (penanganan transaksi), utilities (kegunaan), development (pengembangan), dan fitur-fitur lainnya.
Data definition meliputi pemberian primary key, spesifikasi foreign key, keberadaan tipe data, perluasan tipe data, spesifikasi domain, kontrol integritas, mekanisme view, kamus data, kebebasan data.
Physical definition meliputi keberadaan struktur file, pemeliharaan struktur file, mengurangi reorganisasi, pemberian indeks, variabel
panjang fields/records, kompresi data, encryption routines, kebutuhan memori, kebutuhan penyimpanan.
Accessibility meliputi query language, compliant, interface ke 3GLs, multi-user, security: access controls (kontrol akses) dan authorization mechanism (mekanisme otorisasi).
Transaction handling meliputi backup dan recovery routines, strategi resolusi deadlock, kemajuan model transaksi, parallel query processing. Utilities meliputi performance measuring, tuning, fasilitas load/unload, user usage monitoring, database administration support.
Development meliputi 4GL/5GL tools, CASE tools, kemampuan windows, prosedur penyimpanan, triggers, rules, web development tools. Fitur-fitur lainnya meliputi upgradibility, stabilitas vendor, user base, training dan user support, dokumentasi, sistem operasi, biaya, online help, pengunaan standard, skalabilitas, mendukung untuk analytical tools, interoperabilitas dengan DBMS lain sistem lain.
d. Merekomendasikan pilihan dan memproduksi laporan
Langkah terakhir dari pemilihan DBMS adalah mendokumentasikan prosesnya dan membuat pernyataan dalam penemuan dan rekomendasi atas produk DBMS tertentu (Connolly, 2005, p299).
2.3.6 Perancangan Aplikasi (Application Design)
Merupakan perancangan user interface dan program aplikasi yang menggunakan dan memproses basisdata. Ada 2 (dua) aspek penting dalam perancangan aplikasi, yakni:
a) Perancangan Transaksi (Transaction Design)
Transaksi merupakan sebuah aksi, atau serangkaian aksi yang dilakukan oleh seorang pengguna atau program aplikasi yang mengakses atau mengubah isi dari basisdata. Tujuan dari perancangan transaksi adalah untuk menetapkan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basisdata, yang termasuk :
1) Data yang digunakan dalam transaksi. 2) Karakteristik fungsional dari transaksi. 3) Keluaran (output) dari transaksi. 4) Kepentingan pengguna.
5) Nilai yang diharapkan dari pemakaian.
Perancangan ini harus dilakukan lebih awal dalam proses perancangan untuk memastikan bahwa basisdata yang diimplementasikan mampu mendukung semua transaksi yang dibutuhkan. Ada 3 (tiga) jenis transaksi, yaitu :
1) Retrieval transactions, digunakan untuk mendapatkan kembali data untuk ditampilkan di layar atau dalam laporan.
2) Update transactions, digunakan untuk menambah data, menghapus data lama, atau memodifikasi data yang ada dalam basisdata.
3) Mixed Transactions, melibatkan retrieval (pemanggilan) dan update (perubahan) data atau kombinasi antara keduanya.
b) Perancangan Antarmuka (User Interface Design)
Sebelum mengimplementasikan suatu form atau laporan, ada perlunya merancang tampilan (layout) terlebih dahulu. Berikut pedoman yang berguna dalam perancangan laporan :
1) Judul yang berarti, diusahakan pemberian nama suatu form cukup jelas menerangkan kegunaan dari suatu form atau laporan. Informasi yang disampaikan sebuah judul harus jelas dan terhindar dari ambigu. 2) Instruksi yang dapat dipahami, menggunakan terminologi yang lazim
dalam menyampaikan instruksi kepada pengguna. Instruksi harus diuraikan dengan singkat dan jelas, dan ketika membutuhkan informasi lebih lanjut, layar bantuan harus tersedia. Instruksi harus ditulis dengan tata bahasa yang baku dengan menggunakan pola standar.
3) Pengelompokan logis dan pengurutan field, field yang berhubungan harus ditempatkan secara bersama dalam suatu form/laporan. Pengurutan field harus logis dan konsisten.
4) Tampilan permohonan layout form/laporan secara visual, form/laporan harus menarik perhatian bagi pengguna. Hindari area form yang kosong terlalu banyak atau field yang berlebihan.
5) Nama field yang lazim, agar tidak menimbulkan kebingungan bagi pengguna.
6) Terminologi dan singkatan yang digunakan harus konsisten. 7) Penggunaan warna secara konsisten dan berarti.
8) Ruang yang tampak dan batasan untuk field pemasukan data, seorang pengguna harus secara visual menyadari jumlah ruang yang tersedia untuk setiap field.
9) Pergerakan kursor yang baik, seorang pengguna harus dengan mudah mengenal operasi yang dibutuhkan untuk menggerakkan kursor di seluruh form/laporan.
10)Perbaikan kesalahan untuk karakter individual dan field secara keseluruhan.
11)Pesan kesalahan untuk nilai yang tidak dapat diterima sistem. 12)Field-field yang bersifat pilihan harus ditandai dengan jelas. 13)Pesan-pesan untuk field yang bersifat menjelaskan.
Ketika suatu pengguna menempatkan kursor pada suatu field, informasi tentang field tersebut seharusnya muncul dalam suatu posisi yang teratur pada layar.
14)Tanda penyelesaian
Indikator yang menjelaskan bahwa suatu proses telah selesai dilaksanakan. Begitu juga ketika proses pengisian dalam field pada suatu form lengkap.
2.3.7 Prototipe ( Prototyping )
Merupakan pembuatan suatu model kerja dari aplikasi basisdata. Suatu prototipe 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 basisdata prototipe adalah memungkinkan pengguna
menggunakan prototipe tersebut untuk menentukan fitur-fitur dari sistem yang bekerja dengan baik, dan jika mungkin mengusulkan peningkatan atau bahkan fitur-fitur baru pada aplikasi basisdata.
Ada 2 (dua) strategi prototyping pada zaman sekarang:
a) Requirements Prototyping, menggunakan suatu prototipe untuk menentukan kebutuhan-kebutuhan dari aplikasi basisdata yang diusulkan dan suatu waktu kebutuhan-kebutuhan tersebut lengkap, prototipe dibuang.
b) Evolutionary Prototyping, digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototipe tidak dibuang tetapi dengan perkembangan yang lebih jauh menjadi aplikasi basisdata yang digunakan.
2.3.8 Implementasi (Implementation)
Merupakan realisasi fisik dari perancangan basisdata dan aplikasi. Pada penyelesaian tingkat-tingkat perancangan (dimana mungkin atau tidak melibatkan prototyping), sekarang kita dalam posisi mengimplementasikan basisdata dan program aplikasi. Implementasi basisdata dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau graphical user interface (GUI), dimana menyediakan fungsionalitas yang sama ketika menyembunyikan pernyataan DDL tingkat-rendah. Pernyataan DDL tersebut digunakan untuk membuat struktur basisdata dan file basisdata kosong. Program aplikasi diimplementasikan dengan menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL).
Bagian dari program aplikasi ini adalah transaksi basisdata, dimana diimplementasikan dengan menggunakan Data Manipulation Language (DML) dari DBMS sasaran, yang mungkin disimpan dalam sekumpulan bahasa pemrograman, seperti Visual Basic. Juga mengimplementasikan komponen-komponen lainnya dari perancangan aplikasi seperti layar menu, form pemasukan data, dan laporan.
2.3.9 Perubahan dan Pengambilan Data (Data Conversion and Loading)
Merupakan pemindahan data yang ada ke dalam basisdata baru dan mengubah aplikasi yang ada untuk beroperasi pada basisdata yang baru. Langkah ini diperlukan hanya ketika suatu sistem basisdata baru menimpa sistem yang lama.
2.3.10 Pengetesan (Testing)
Merupakan proses pengeksekusian program aplikasi dengan maksud pencarian kesalahan-kesalahan. Sebelum ditunjukkan secara langsung, aplikasi basisdata yang baru dikembangkan seharusnya diuji sepenuhnya.
2.3.11 Perawatan Operasional (Operational Maintenance)
Merupakan proses pengawasan dan pertahanan sistem berikut instalasi. Pada langkah sebelumnya, aplikasi basisdata telah diimplementasikan dan diuji sepenuhnya. Sekarang sistem memasuki langkah perawatan, yang melibatkan aktivitas-aktivitas berikut :
a) Mengawasi kinerja sistem.
2.4 Tahap – Tahap Perancangan Basisdata
Dalam merancang suatu basisdata melalui beberapa tahapan, sebagai berikut : 1) Perancangan Basisdata Konseptual
2) Perancangan Basisdata Logikal 3) Perancangan Basisdata Fisikal
2.4.1 Perancangan Basisdata Konseptual
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan konseptual basisdata adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basisdata, yang meliputi identifikasi dari entitas - entitas, relationship -relationship, dan atribut - atribut yang penting.
Menurut Connolly dan Begg ( 2005 , p443 ), langkah - langkah perancangan konseptual basisdata yaitu :
Langkah 1. Membangun conceptual data model
Menurut Connolly dan Begg ( 2005 , p442 ), tujuannya adalah untuk
membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type, atribut - atribut, domain – domain atribut, primary key, alternate key, dan integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 :
Langkah 1.1 Identifikasikan Tipe Entitas
Menurut Connolly dan Begg (2005, p443), tujuannya adalah mengidentifikasikan tipe – tipe entitas utama yang dibutuhkan oleh view.
Langkah 1.2 Identifikasikan Tipe Relationship
Menurut Connolly dan Begg (2005 ,p445), tujuannya adalah mengidentifikasikan relationship – relationship penting yang ada diantara tipe – tipe entitas yang telah diidentifikasi.
Langkah 1.3 Identifikasikan dan Asosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship
Menurut Connolly dan Begg (2005 ,p447), tujuannya adalah untuk menghubungkan atribut – atribut dengan entitas atau relationship type yang sesuai.
Langkah 1.4 Menentukan Domain Atribut
Menurut Connolly dan Begg (2005 , p450), tujuannya adalah untuk menentukan domain – domain untuk atribut – atribut dalam local conceptual data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Domain merupakan fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama.
Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate Key
Menurut Connolly dan Begg ( 2005 , p451 ), tujuannya adalah untuk mengidentifikasikan candidate – candidate key untuk tiap tipe entitas dan jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan primary key.
Menurut Connolly dan Begg (2005 , p451), ketika memilih primary key
diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu :
- Candidate key dengan kumpulan atribut yang minimal - Candidate key yang nilainya jarang berubah
- Candidate key dengan karakter – karakter yang paling sedikit (untuk yang memiliki textual attributes)
- Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki numerical attributes)
- Candidate key yang paling mudah digunakan dari sudut pandang user Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional)
Menurut Connolly dan Begg (2005 , p453), tujuannya adalah untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization / generalization, aggregation, dan composition.
Langkah 1.7 Validasi Model Konseptual dengan User Transaction Menurut Connolly dan Begg (2005 , p456), tujuannya adalah untuk menjamin bahwa model konseptual mendukung transaksi – transaksi yang dibutuhkan oleh view.
2.4.2 Perancangan Basisdata Logikal
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan logikal basisdata adalah suatu proses pembangunan model data yang digunakan dalam perusahaan
berdasar atas model data yang spesifik, tetapi tidak bergantung pada particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basisdata yang meliputi perancangan relasi – relasi.
Menurut Connolly dan Begg ( 2005 , p462 ), langkah – langkah perancangan basisdata logikal yaitu :
Langkah 2. Membangun dan memvalidasi logical data model
Menurut Connolly dan Begg ( 2005 , p462 ), tujuannya adalah menerjemahkan logical data model dan kemudian untuk memvalidasi model tersebut untuk memeriksa model tersebut benar secara struktural dan memiliki kemampuan untuk mendukung transaksi – transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah – langkah berikut :
Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal
Menurut Connolly dan Begg ( 2005 , p463 ), tujuannya adalah menciptakan relasi – relasi untuk model data logikal untuk merepresentasikan entitas – entitas, relationship – relationship, dan atribut – atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual :
● Strong Entity Type dan Weak Entity Type
Menurut Connolly dan Begg (2005 , p354), strong entity type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type adalah tiap entity occurrence dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering juga disebut parent atau owner atau dominant entities.
Menurut Connolly dan Begg (2005 , p355), weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child, dependent, atau subordinate entities.
● One-to-many (1:*) binary relationship types
Menurut Connolly dan Begg (2005 , p465), untuk tiap 1:* binary relationship, entitas pada ‘one side’ dari relationship dianggap sebagai entitas parent dan entitas pada ‘many side’ dianggap sebagai entitas child. Untuk merepresentasikan relationship ini, pasangkan salinan primary key dari entitas parent ke dalam relation yang merepresentasikan entitas child, untuk berlaku sebagai foreign key.
● One-to-one (1:1) binary relationsip types
Menurut Connolly dan Begg (2005 , p465), penciptaan relasi – relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasikan entitas – entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik untuk merepresentasikan relationship dengan menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana menciptakan relasi – relasi untuk merepresentasikan participation constraint berikut :
- Mandatory participation pada 2 sisi dari 1:1 relationship - Mandatory participation pada 1 sisi dari 1:1 relationship - Optional participation pada 2 sisi dari 1:1 relationship
● Mandatory participation pada 2 sisi dari 1:1 relationship
Menurut Connolly dan Begg (2005 , p466), pada kasus ini, kita harus menggabungkan entitas – entitas yang terlibat kedalam satu relasi dan memilih
salah satu dari primary key dari entitas – entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key. ● Mandatory participation pada 1 sisi dari 1:1 relationship
Menurut Connolly dan Begg (2005 , p466), pada kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1 relationship
menggunakan participation constraint. Entitas yang mempunyai optional participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key ke relasi child.
● Optional participation pada 2 sisi dari 1:1 relationship
Menurut Connolly dan Begg ( 2005 , p467 ), kita dapat memilih primary key mana yang dipilih tergantung dari kasus yang ada.
● One-to-one (1:1) recursive relationship
Menurut Connolly dan Begg (2005 , p467), untuk 1:1 recursive relationship, kita mengikuti aturan untuk participation seperti yang diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan mandatory participation pada 2 sisi, representasikan recursive relationship sebagai relasi tunggal dengan 2 salinan primary
key. Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus diubah namanya untuk menandakan relationship yang direpresentasikan.
Untuk 1:1 recursive relationship dengan mandatory participation pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan 2 salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key.
Untuk 1:1 recursive relationship dengan optional participation pada 2 sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas. ● Superclass /subclass relationship types
Menurut Connolly dan Begg (2005 , p467),untuk tiap superclass / subclass relationship dalam data model konseptual, kita mengidentifikasikan entitas superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam merepresentasikan relationship sebagai salah satu atau lebih relasi – relasi. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointnese dan participation constraint pada superclass / subclass relationship apakah subclass – subclass terlibat dalam distinct relationship dan jumlah participant – participant dalam superclass / subclass relationship.
● Many-to-many (*:*) binary relationship types
Menurut Connolly dan Begg ( 2005 , p469 ), untuk tiap * : * binary relationship menciptakan relasi untuk merepresentasikan relationship dan meliputi atribut – atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam relationship kedalam relasi baru. Untuk berlaku sebagai foreign key.
● Complex relationship types
Menutur Connolly dan Begg ( 2005 , p470 ), untuk setiap complex relationship menciptakan sebuah relasi untuk merepresentasikan relationship dan termasuk semua atribut yang merupakan bagian dari relationship tersebut. Kita menyalin salinan primary key dari entitas yang berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key.
● Multi-valued attributes
Menurut Connolly dan Begg ( 2005 , p471 ), menciptakan relasi yang merepresentasikan atribut – atribut multi-valued dan menyalin salinan primary
key dari entitas owner kedalam relasi baru untuk menjadi foreign key. Langkah 2.2 Validasi Model dengan Normalisasi
Menurut Connolly dan Begg (2005 , p473), tujuannya adalah untuk memvalidasi relasi – relasi dalam model data konseptual menggunakan teknik normalisasi.
Menurut Connolly dan Begg (2005 , p388), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi – relasi dengan properti – properti yang diinginkan, sesuai dengan kebutuhan data – data yang diberikan oleh perusahaan.
Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data
(perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi – relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update anomaly).
Menurut Connolly dan Begg ( 2005 , p391 ), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification / update anomaly. Insert anomaly
adalah kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data. Menurut Connolly dan Begg ( 2005 , p401 ), proses normalisasi meliputi langkah – langkah utama berikut :
- First Normal Form ( 1NF ), yang menghilangkan repeating groups
- Second Normal Form ( 2NF ), yang menghilangkan partial dependency dalam primary key
- Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies dalam primary key
Langkah 2.3 Mendefinisikan Kendala Integrity
Menurut Connolly dan Begg ( 2005 , p474 ), tujuannya adalah memeriksa integrity constraint yang direpresentasikan dalam model data logikal. Integrity constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity, dan general constraint.
● Data yang dibutuhkan
Menurut Connolly dan Begg ( 2005 , p475 ), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null.
● Attribute domain constraint
Menurut Connolly dan Begg ( 2005 , p475 ), tiap atribut mempunyai domain, yaitu kumpulan nilai – nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu ‘M’ atau ‘F’, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari ‘M; atau ‘F’. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data.
● Multiplicity
Menurut Connolly dan Begg ( 2005 , p475 ), multiplicity merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basisdata.
● Entity integrity
Menurut Connolly dan Begg ( 2005 , p475 ), primary key dari entitas tidak boleh bernilai null. Batasan ini harus betul – betul dipertimbangkan ketika kita mengidentifikasikan primary key untuk tiap tipe entitas.
● Referential integrity
Menurut Connolly dan Begg ( 2005 , p475 ), foreign key menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent yang meliputi nilai candidate key yang sesuai. Referential integrity berarti bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent. Menurut Connolly dan Begg ( 2005 , p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple pada relasi parent, yaitu :
- NO ACTION
Mencegah penghapusan dari relasi parent jika terdapat tuple – tuple child yang ditunjuk.
- CASCADE
Ketika tuple parent dihapus, secara otomatis juga dihapus tuple – tuple child yang ditunjuk
- SET NULL
Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang berhubungan secara otomastis diubah menjadi null.
- SET DEFAULT
Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang berhubungan secara otomatis diubah menjadi nilai default-nya.
- NO CHECK
Ketika tuple parent dihapus, tidak melakukan apa – apa untuk menjamin referential integrity tetap terjaga.
● General constraints
Pengubahan – pengubahan pada entitas – entitas mungkin diatur oleh batasan – batasan yang memerintah transaksi ’real world’ yang direpresentasikan oleh pengubahan tersebut
Langkah 2.4 Me-review Logical Data Model dengan User
Menurut Connolly dan Begg ( 2005 , p478 ), tujuannya adalah untuk menjamin bahwa pengguna mempertimbangkan model data logikal menjadi representasi yang sebenarnya dari kebutuhan data perusahaan.
Langkah 2.5 Menggabungkan Logical Data Model ke dalam Global Model (optional) Menurut Connolly dan Begg ( 2005 , p479 ), tujuannya adalah untuk merepresentasikan semua user views dari basisdata.
Langkah 2.6 Memeriksa untuk perkembangan lebih lanjut
Menurut Connolly dan Begg ( 2005 , p490 ), tujuannya adalah menentukan apakah terdapat perubahan signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.
2.4.3 Perancangan Basisdata Fisikal
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan fisik basisdata adalah proses membuat deskripsi dari implementasi basisdata pada secondary storage,
mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk
mendapatkan akses efisien pada data dan semua integrity constraint yang berhubungan dan security measures. Tujuannya adalah untuk memutuskan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih.
Menurut Connolly dan Begg ( 2005 , p496 ), langkah – langkah perancangan fisik basisdata meliputi :
Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih
Menurut Connolly dan Begg ( 2005 , p497 ), tujuannya adalah untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 :
Langkah 3.1 Merancang relasi – relasi dasar
Menurut Connolly dan Begg ( 2005 , p498 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan relasi – relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari :
- Nama relasi
- Daftar atribut – atribut sederhana dalam golongan – golongan - Primary key dan alternate key dan foreign key jika ada
- Referential integrity contraints untuk semua foreign keys yang diidentifikasikan Menurut Connolly dan Begg ( 2005 , p498 ), sedangkan dari data dictionary, dari tiap – tiap atribut kita juga mempunyai :
- Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain - Nilai default optional untuk atribut
- Apakah atribut dapat mempunyai nilai nulls
- Apakah atribut tersebut derived, maka harus dikomputasi Langkah 3.2 Merancang Representasi untuk Data Turunan
Menurut Connolly dan Begg ( 2005 , p499 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai – nilai dari atribut – atribut lainnya disebut derived atau calculated attribute.
Langkah 3.3 Merancang General Constraint
Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih.
Langkah 4. Merancang file organization dan indexes
Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi – relasi dasar dan indeks – indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage.
Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu : - Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak.
- Response time adalah waktu yang diperlukan untuk menyelesaikan satu transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin
meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling,
communication delay.
- Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan file – file basisdata. Para perancang sistem biasanya ingin meminimalkan disk storage yang digunakan.
Langkah 4.1 Menganalisa Transaksi
Menurut Connolly dan Begg ( 2005 , p502 ), tujuannya adalah untuk mengerti fungsi dari transaksi yang akan diterapkan pada basisdata dan untuk menganalisa transaksi – transaksi yang penting.
Langkah 4.2 Memilih Organisasi file
Menurut Connolly dan Begg ( 2005 , p506 ), tujuannya adalah untuk menentukan organisasi file yang efisien untuk tiap relasi dasar.
Langkah 4.3 Memilih index – index
Menurut Connolly dan Begg ( 2005 , p508 ), tujuannya adalah untuk mempertimbangkan apakah dengan menambahkan index akan meningkatkan
Langkah 4.4 Memperkirakan kebutuhan disk space
Menurut Connolly dan Begg ( 2005 , p514 ), untuk memperkirakan jumlah disk space yang dibutuhkan oleh basisdata. Untuk menyimpan data dan semua index – index nonclustered dasar dalam tabel yang tidak mempunyai clustered index maka kita dapat menggunakan beberapa langkah berikut :
1. Menghitung space yang digunakan untuk menyimpan data
2. Menghitung space yang digunakan untuk menyimpan tiap index – index nonclustered dasar.
3. Menjumlahkan nilai – nilai yang dikalkulasikan. Langkah 5. Merancang user view
Menurut Connolly dan Begg ( 2005 , p515 ), tujuannya adalah untuk merancang user view yang diidentifikasikan selama pengumpulan kebutuhan – kebutuhan dan tahap analisis dari system development lifecycle.
Langkah 6. Merancang mekanisme keamanan
Menurut Connolly dan Begg ( 2005 , p516 ), tujuannya adalah untuk merancang mekanisme keamanan untuk basisdata seperti yang ditentukan oleh user pada waktu tahap pengumpulan kebutuhan – kebutuhan dari system development lifecycle. Mekanisme kemanan yang dirancang dalam basisdata yaitu mekanisme keamanan sistem dan mekanisme keamanan data.
2.5 Entity – Relationship Modelling ( E-R Modelling ) 2.5.1 Entity Type
Entity type adalah sekumpulan objek yang memiliki properti yang sama yang diidentifikasi dalam perusahaan serta keberadaannya independen (Connolly, 2005,
p343). Setiap objek yang diidentifikasikan secara unik disebut entity occurence (Connolly, 2005, p333).
Gambar 2.2 Representasi Diagram Dari Entity Type Staff dan Branch (Sumber : Connolly, 2005, p345)
2.5.2 Relationship Type
Relationship Type adalah sekumpulan entity yang mempunyai hubungan dan memiliki arti (Connolly, 2005, p346).
Gambar 2.3 Representasi Diagram Dari Entity Branch Has Staff Relationship Type (Sumber : Connolly, 2005, p347)
2.5.3 Attributes
Menurut Connolly (2005, p350), atribut adalah properti dari sebuah entity atau relationship type. Sedangkan attribute domain adalah sekumpulan nilai yang dibolehkan untuk satu atau lebih atribut.
Atribut dapat diklasifikasikan sebagai: 1. Simple dan Composite Attribute
Simple attribute adalah sebuah atribut yang disusun oleh sebuah komponen tunggal dengan keberadaan yang independen. Simple attribute tidak dapat dipecah menjadi komponen yang lebih kecil lagi (Connolly, 2005, p351). Sebagai contoh simple atributte ialah atribut position dan salary pada entity Staff. Sedangkan Composite attribute adalah sebuah atribut yang disusun oleh banyak komponen yang independen. Atribut ini bisa dipecah menjadi atribut yang lebih kecil. Contohnya atribut address dalam entity Branch dengan nilai (163 Main St, Blasgow, G11 9QX) dapat dipecah menjadi street (163 Main St), city (Glasgow), dan postcode (G11 9QX).
2. Single-valued dan Multi-Valued Attribute
Single-valued attribute adalah sebuh atribut yang mempunyai nilai tunggal untuk setiap kejadian dalam sebuah entity (Connolly, 2005, p351). Contohnya pada entity Branch mempunyai nilai tunggal pada masing-masing atribut branchNo. Multi-valued attribute adalah sebuah attribut yang mempunyai nilai lebih dari satu untuk setiap kejadian pada entity (Connolly, 2005, p353). Contoh setiap atribut pada entity Branch dapat mempunyai telNo lebih dari satu (Misalnya cabang dengan branchNo B003 mempunyai telNo 2178 dan 0141-339-4439).
3. Derived Attributes
Derived attribute adalah atribut yang merepresentasikan sebuah nilai yang bisa diperoleh dari nilai dari atribut yang berkaitan (Connolly, 2005, p352).
2.5.4 Keys
Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly, 2005, p352). Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas (Connolly, 2005, p353). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, 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).
Gambar 2.4 Representasi Diagram dari Entity Branch Beserta Atribut-Atributnya (Sumber : Connolly, 2005, p354)
2.5.5 Structural constraint
Tipe utama dari constraint dari relationship disebut multiplicity. Multiplicity adalah jumlah dari kejadian – kejadian yang mungkin dari sebuah tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus. Tiga jenis relationship yang digunakan mengikuti enterprise constraint :
• Hubungan 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 1.
Contoh : satu produk hanya memiliki satu bonus dan bonus hanya dimiliki oleh satu produk. Diasumsikan hanya produk tertentu saja yang mempunyai bonus dan bonusnya hanya satu.
• Hubungan 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 1.
Contoh : seorang kepala sekolah dapat memiliki 1 hingga banyak guru, tetapi seorang guru hanya memiliki satu dan hanya satu kepala sekolah.
• Hubungan 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. Contoh : Pembeli dapat memilih 0 hingga banyak produk yang ingin dibeli,
tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk.
2.6 Normalisasi
Menurut Connolly (2005, p388), normalisasi adalah sebuah teknik untuk menghasilkan relasi dengan properti-properti yang diinginkan, memberikan kebutuhan data dari sebuah perusahaan. Tujuan normalisasi adalah terjaminnya struktur yang konsisten, kerangkapan yang minimal, dan stabilitas struktur data yang maksimal. Manfaat normalisasi adalah sebagai berikut :
1. Meminimalkan jumlah kapasitas penyimpanan yang diperlukan untuk menyimpan data.
3. Meminimalkan kemungkinan update dan delete anomally. 4. Memaksimalkan stabilitas dari struktur data.
Proses normalisasi tabel yang digunakan menjadi tiga tahap sehingga dikenal bentuk-bentuk tabel normal sesuai dengan tahapan normalisasi yang telah dilakukan yaitu bentuk normal pertama, kedua, dan ketiga :
1. First Normal Form (1NF)
Menurut Connolly (2005, p403), First Normal Form adalah relasi dimana pertemuan antar setiap baris dan kolom terdiri 1 (satu) dan hanya 1 (satu) nilai. Bentuk normal pertama diicapai bila tiap nilai atribut adalah tunggal. Kondisi ini dapat diperolah dengan melakukan eliminasi terjadinya data ganda (repeating groups). Pada kondisi normal pertama ini kemungkinan masih terjadi adanya data rangkap.
2. Second Normal Form (2NF)
Menurut Connolly (2005, p407), Second normal form (2NF) adalah merupakan sebuah relasi dalam 1NF dan setiap atribut non-primary key bersifat Full Function Dependency pada primary key dari relasi tersebut. Dalam normalisasi kedua ini, atribut yang tergantung pada sebagian dari suatu composite key sebuah tabel dipindahkan ke sebuah tabel yang terpisah.
3. Third Normal Form (3NF)
Menurut Connolly (2005, p409), Third normal form (3NF) adalah sebuah relasi yang memenuhi normal pertama dan normal kedua dimana tidak
terdapat atribut non primary key yang bersifat transitively dependent dari primary key-nya.
Dalam normalisasi ketiga ini, atribut yang tidak memberikan kontribusi terhadap penjelasan karakteristik primary key, akan dipindahkan ke sebuah tabel yang terpisah. Keuntungan dari tabel relasional dalam 3NF adalah menghilangkan data yang berulang-ulang dengan tujuan menghemat tempat dan mengurangi keanehan manipulasi.
2.7 Data Flow Diagram (DFD)
Pengertian dari DFD adalah teknik grafis yang menggambarkan aliran data melalui sebuah sistem dan merubah data yang bergerak dari input ke output. DFD dapat juga disebut dengan Bubble chart, Data Flow Graph (Roger, 2001, p309).
Tingkatan pada DFD : a. Diagram konteks
Menggambarkan seluruh input ke atau output ke sistem. Diagram konteks ini merupakan level tertinggi dari DFD.
b. Diagram nol
Merupakan rincian dari diagram konteks dan memperlihatkan data store yang digunakan.
c. Diagram rinci
Simbol – simbol dalam DFD :
Tabel 2.1 Simbol – Simbol dalam DFD
Eksternal Entity (Terminal)
Proses Penyimpanan Data (Data Store) Aliran Data (Data Flow) Keuntungan pengunaan DFD :
1. Proses dalam DFD dapat beroperasi secara paralel. Maksudnya beberapa proses dapat bekerja secara bersamaan sesuai dengan cara kerja bisnis. 2. DFD menunjukkan aliran data yang melalui sistem. Panahnya mewakili
arah dimana data tersebut mengalir. Perulangan dan percabangan biasanya tidak diperlihatkan. Flowchart menunjukkan tahap-tahap dari proses atau operasi dalam algoritma/program.
3. DFD menunjukkan proses yang memiliki perbedaan waktu yang dramatis. Misalnya suatu DFD tunggal mungkin akan memasukkan proses yang terjadi perjam, perhari, perminggu, pertahun, dan sesuai permintaan.
2.8 State Transition Diagram (STD)
State Transition Diagram merupakan suatu diagram yang menggambarkan bagaimana state dihubungkan dengan state yang lain pada satu waktu. State Transition Diagram menunjukkan bagaimana sistem bekerja sebagai akibat dari kejadian eksternal. Untuk melakukan hal itu, State Transition Diagram menampilkan model yang bermacam-macam dari tindakan sebuah sistem dan dibuat dari state ke state.
Komponen dasar dari State Transition Diagram adalah :
1.
Menyatakan state atau kondisi dari suatu sistem. State terdiri dari dua macam, yaitu initial state / state awal dan final state / state akhir. Final state dapat terdiri atas beberapa state, tetapi initial state tidak boleh lebih dari satu.
2.
Menyatakan perubahan kondisi dari suatu sistem. Digambarkan untuk menghubungkan keadaan sistem yang berkaitan.
3. Kondisi dan Aksi
Kondisi : menyatakan suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh suatu sistem. Misalnya : suatu sinyal / data.
Aksi : menyatakan sesuatu yang dilakukan oleh sistem apabila terjadi perubahan state / merupakan suatu reaksi terhadap kondisi. Aksi akan menghasilkan output, message display pada monitor dan menghasilkan kalkulasi.
2.9 Teori-Teori Khusus 2.9.1 Teori Penjualan 2.9.1.1 Pengertian Penjualan
Menurut Mulyadi ( 2001, p202 ) penjualan terdiri dari transaksi penjualan barang atau jasa baik secara kredit maupun tunai.
a) Penjualan Tunai
Menurut Mulyadi ( 2001,p202 ), penjualan tunai dilakukan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran harga terlebih dahulu sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan tunai kemudian dicatat oleh perusahaan.
b) Penjualan Kredit
Menurut Mulyadi ( 2001,p203 ), penjualan kredit adalah penjualan yang pembayarannya dilakukan beberapa waktu kemudian setelah pembeli menerima barang yang dipesannya. Pembayaran biasanya dilakukan dalam jangka waktu yang telah disepakati oleh kedua belah pihak. Menurut Mulyadi, penjualan kredit dilaksanakan oleh perusahaan dengan cara mengirimkan barang sesuai dengan
pesanan yang diterima dari pembeli dan untuk jangka waktu tertentu perusahaan.menagih kepada pembeli tersebut.
2.9.2 Teori Pembelian 2.9.2.1 Pengertian Pembelian
Menurut Render (2001, h414), pembelian adalah perolehan barang dan jasa. Secara umum definisi pembelian adalah suatu usaha pengadaan barang atau jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual kembali.
2.9.2.2 Tujuan Pembelian
Tujuan pembelian menurut Render (2001, h414), tujuan dari kegiatan pembelian adalah :
a) Membantu identifikasi produk dan jasa yang dapat diperoleh secara eksternal. b) Mengembangkan, mengevaluasi, dan menentukan pemasok, harga dan
pengiriman yang terbaik bagi barang dan jasa tersebut.
Jenis transaksi dalam pembelian dibedakan menjadi dua, yaitu :
a) Pembelian tunai adalah proses pembayaran yang dilakukan secara langsung pada saat barang diterima.
b) Pembelian kredit adalah proses pembayaran yang tidak dilakukan langsung pada saat barang diterima, tetapi pembayaran dilakukan selang beberapa waktu setelah barang diterima sesuai dengan perjanjian kedua belah pihak.
Hal-hal yang harus diperhatikan dalam proses pembelian adalah : a) Kualitas
b) Harga
c) Waktu proses
2.9.2.3 Fungsi – Fungsi yang Terkait Dengan Pembelian
Pengawasan perlu dilakukan terhadap pelaksanaan proses pembelian ini, karena pembelian menyangkut investasi dana dalam persediaan dan kelancaran arus barang ke dalam perusahaan. Menurut Mulyadi (2001, h299-300) fungsi yang terkait dalam sistem pembelian adalah sebagai berikut :
a) Fungsi Gudang
Bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan.
b) Fungsi Pembelian
Bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih.
c) Fungsi Penerimaan
Bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas bahan yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan.
d) Fungsi Akuntansi
Bertanggung jawab dalam pencatatan transaksi pembelian yang menjadi hutang sebagai dokumen bukti kas keluar.
Menurut Mulyadi (2001, h301-303), jaringan prosedur yang membentuk sistem pembelian adalah sebagai berikut :
1) Prosedur Permintaan Pembelian
Dalam prosedur ini fungsi gudang mengajukan permintaan pembelian dalam formulir surat permintaan pembelian kepada fungsi pembelian.
2) Prosedur Permintaan Penawaran Harga dan Pemilihan Pemasok
Fungsi pembelian mengirimkan surat permintaan penawaran harga kepada pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain untuk memungkinkan pemilihan pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan.
3) Prosedur Order Pembelian
Fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit lain dalam perusahaan mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.
4) Prosedur Penerimaan Barang
Dalam prosedur ini fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas, dan mutu bahan yang diterima dari pemasok, kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut.
