7
TINJAUAN PUSTAKA
Pada bab tinjauan pustaka akan dibahas secara ringkas mengenai teori yang berkaitan dengan basis data, teori yang terkait tema penelitian, serta hasil penelitian atau produk sebelumnya.
2.1 Teori yang Berkaitan dengan Basis Data
Dalam tinjauan pustaka yang berhubungan dengan basis data akan diuriakan secara ringkas antara lain: data, informasi, tabel, basis data (database), sistem manajemen basis data, Database Management System (DBMS), komponen DBMS, keuntungan dan kerugian DBMS, fungsi DBMS, bahasa basis data (Database Language), data definition language (DDL), data manipulation language (DML), pemodelan relasi entitas (Entity-Relationship Modelling), normalisasi (Normalization), daur hidup basis data (Database Life Cycle), dan lain-lain.
2.1.1 Pengertian Data
Menurut Indrajani (2011:2), data adalah fakta atau observasi mentah yang biasanya mengenai fenomena fisik atau transaksi bisnis.
Menurut William dan Sawyer (2007:25), data terdiri dari fakta-fakta dan gambar mentahan yang akan di proses menjadi informasi.
Menurut Jonathan Lukas (2006:39), Data adalah kenyataan atau fakta penting yang tercatat atau terekam yang dapat diproses oleh komputer atau manusia dan memiliki arti yang bermacam-macam.
Sedangkan Menurut Kamus Bahasa Indonesia (2008:1580), data adalah kenyataan yang ada dan berfungsi sebagai sumber bahan untuk menyusun suatu pendapat.
2.1.2 Pengertian Informasi
Menurut William dan Sawyer (2007:25), informasi adalah data yang telah dirangkum atau dimanipulasi dalam bentuk lain untuk pengambilan keputusan.
Menurut R. Kelly Rainer dan Casey G. Cagielski (2011:10), Informasi mengacu pada data yang telah terorganisasi sehingga data tersebut memiliki makna dan nilai kepada penerima data tersebut.
2.1.3 Pengertian Tabel
Menurut Kamus Bahasa Indonesia (2008:1580), Pengertian Tabel adalah daftar yang berisi ikhtisar sejumlah data informasi, biasanya berupa kata-kata dan bilangan yg tersusun secara tersistem, urut ke bawah pada lajur dan deret tertentu dengan garis pembatas sehingga dapat dengan mudah disimak.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Suatu relasi adalah tabel dengan kolom dan baris.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Sebuah atribut adalah kolom dari suatu relasi. Dalam model relasional, relasi digunakan untuk menyimpan informasi tentang objek yang akan direpresentasikan dalam basis data. Suatu relasi direpresentasikan sebagai tabel dua dimensi dimana baris tabel tersebut sesuai dengan catatan individu dan kolom tabel sesuai dengan atribut. Atribut dapat muncul dalam urutan keberapapun dan akan tetap memiliki relasi yang sama. karena menyampaikan makna yang sama, Sebuah atribut adalah kolom yang bernama relasi.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Sebuah domain adalah himpunan nilai diperbolehkan untuk satu atau lebih atribut.
Menurut Thomas Connolly dan Carolyn Begg (2005:73), Tuple adalah baris dari suatu relasi. Unsur-unsur relasi adalah baris atau tuple dalam tabel. Dalam relasi Cabang, setiap baris berisi empat nilai, satu untuk setiap atribut. Tuple dapat muncul dalam urutan apapun dan relasi akan tetap relasi yang sama, dan karenanya menyampaikan makna yang sama.
2.1.4 Pengertian Basis Data
Menurut Gerald V.Post (2005:2), basis data adalah kumpulan data yang disimpan dalam format standar, yang dirancang untuk digunakan bersama oleh beberapa pengguna.
Menurut Indrajani (2011:2), basis data adalah kumpulan data yang berelasi secara logis dan deskripsi data tersebut, yang dirancang untuk memenuhi informasi yang dibutuhkan oleh suatu organisasi.
Sedangkan menurut William dan Sawyer (2007:464), basis data adalah kumpulan data yang saling berelasi, yang diatur secara logis, yang dirancang dan dibangun untuk tujuan khusus. sebuah teknologi untuk mengumpulkan banyak fakta yang memungkinkan anda memotong, membuang, dan menggabungkan serta memasang data dengan beragam cara.
2.1.5 Database Management System (DBMS)
Menurut Gerald V.Post (2005:2), DBMS adalah perangkat lunak yang mendefinisikan basis data, menyimpan data, mendukung bahasa query, menghasilkan laporan, dan menciptakan entri data pada layar.
Menurut Thomas Connolly dan Carolyn Begg (2005:16), DBMS adalah Sebuah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke basis data.
Beberapa fasilitas yang disediakan DBMS:
1. Data Definition Language (DDL), memungkinkan pengguna untuk
menentukan jenis, struktur data dan masalah pada data yang akan disimpan dalam basis data.
2. Data Manipulation Language (DML), memungkinkan pengguna untuk menambahkan, memperbaharui, menghapus, dan memperoleh data dari basis data.
3. Query Languange Memiliki repositori pusat untuk semua data dan mendeskripsikan data yang memungkinkan DML menyediakan fasilitas umum untuk penyelidikan data.
2.1.5.1 Komponen DBMS
Menurut Thomas Connolly dan Carolyn Begg (2005:18–21), DBMS dibagi menjadi 5 Komponen yaitu:
Gambar 2.1 Komponen DBMS 1. Perangkat keras (Hardware)
DBMS dan aplikasi membutuhkan hardware untuk menjalankannya.
Hardware meliputi komputer pribadi (personal computer),
mainframe, dan jaringan komputer. Beberapa DBMS hanya dapat berjalan pada hardware atau operating system tertentu, dan yang lainnya dapat berjalan pada berbagai hardware atau operating system. Amount of memory and disk space diperlukan untuk menjalankan DBMS.
2. Perangkat lunak (Software)
Komponen perangkat lunak (software) terdiri dari DBMS dan program aplikasi beserta sistem operasinya, termasuk perangkat lunak jaringan (network software) jika DBMS sedang digunakan melalui sebuah jaringan tertentu.
3. Data
Data adalah komponen penting dalam DBMS. Data bertindak sebagai penghubung antara komponen mesin dan manusia. Basis data berisi data operasional dan metadata.
4. Prosedur (Procedure)
Prosedur mengacu pada instruksi dan aturan yang mengatur desain dan penggunaan basis data. Pengguna sistem dan staf yang mengatur basis data memerlukan dokumentasi prosedur tentang cara menggunakan atau menjalankan sistem. Beberapa instruksi tentang cara penggunaan basis data adalah:
a. Masuk ke DBMS,
b. Menggunakan fasilitas DBMS tertentu atau program aplikasi, c. Memulai dan menghentikan DBMS,
d. Membuat backup dari basis data,
e. Menangani hardware atau software yang rusak,
f. Mengubah struktur tabel, mengatur basis data di beberapa disk, meningkatkan kinerja atau menyimpan arsip data ke penyimpanan sekunder.
5. Pengguna (People)
Komponen terkahir adalah pengguna yang terlibat dengan sistem. Menurut Thomas Connolly dan Carolyn Begg (2005:21–24), Kita dapat mengidentifikasi empat jenis pengguna yang berpartisipasi dalam lingkungan DBMS yaitu:
a. Pengelola data dan basis data (Data and Database Administrator) Data dan database administrator memiliki peran dalam pengelolaan dan pengendalian DBMS dan data. Data Administrator (DA) bertanggung jawab atas pengelolaan sumber daya data yang termasuk dalam perencanaan basis data, pengembangan dan pemeliharaan, kebijakan dan prosedur, dan desain basis data konseptual atau logikal.
Database Administrator (DBA) bertanggung jawab untuk fisikal basis data, termasuk desain fisikal basis data dan implementasi, keamanan dan integritas kontrol, pemeliharaan sistem operasional, dan memastikan kinerja yang memuaskan dari aplikasi untuk pengguna.
b. Desainer basis data (Database Designer)
Dalam proyek desain basis data yang besar, kita dapat membedakan antara dua jenis desainer yaitu desainer basis data logikal dan desainer basis data fisikal. Perancang basis data logikal berkaitan dengan mengidentifikasi data (entitas dan atribut), relasi antara data, dan kendala pada data yang akan disimpan dalam basis data.
Sedangkan bagian desain basis data fisikal sangat tergantung pada target DBMS, dan mungkin ada lebih dari satu cara untuk
menerapkan mekanismenya. Akibatnya, desainer basis data fisikal harus sepenuhnya menyadari fungsi dari target DBMS dan harus memahami kelebihan dan kekurangan dari setiap alternatif untuk implementasi tertentu. Perancang basis data fisikal harus mampu memilih strategi penyimpanan data yang memperhitungkan penggunaan.
c. Pembangun aplikasi (Application Developer)
Setelah basis data dilaksanakan, program aplikasi yang menyediakan fungsi untuk end-user yang harus diimplimentasikan. Ini merupakan tanggung jawab pengembang aplikasi. Biasanya, pengembang aplikasi bekerja dari spesifikasi yang dihasilkan oleh sistem analis. Setiap program berisi pernyataan yang meminta DBMS untuk melakukan beberapa operasi pada basis data. Ini termasuk mengambil data, insert, update, dan delete data.
d. Pengguna akhir (End-User)
Para end-users adalah client untuk basis data yang telah dirancang dan diimplementasikan, dan sedang dipertahankan untuk melayani kebutuhan informasi mereka. End-User dapat diklasifikasikan menurut cara mereka menggunakan sistem:
i. Pengguna awam (Naïve users) biasanya menyadari DBMS. Mereka mengakses basis data melalui program aplikasi yang buat khusus dalam suatu operasi yang sesederhana mungkin. Mereka menggunakan operasi basis data dengan memasukkan perintah sederhana atau dengan memilih dari menu. Ini menandakan bahwa mereka tidak perlu tahu apa-apa tentang basis data atau DBMS. Sebagai contoh, asisten kasir di supermarket lokal menggunakan barcode reader untuk mengetahui harga suatu item. selanjutnya, ada program aplikasi yang membaca barcode, melihat harga dari item dalam basis data, mengurangi jumlah basis data
yang berisi jumlah item di stok, dan menampilkan harga di kasir.
ii. Pengguna hebat (Sophisticated users) Adalah seseorang yang terbiasa dengan struktur basis data dan fasilitas yang ditawarkan oleh DBMS. sophisticated users dapat menggunakan query bahasa tingkat tinggi seperti SQL untuk melakukan operasi yang diperlukan. Beberapa sophisticated users bahkan dapat menulis program aplikasi untuk mereka gunakan sendiri.
2.1.5.2 Keuntungan dan Kerugian Dalam Menggunakan DBMS Menurut Thomas Connolly dan Carolyn Begg (2005:26–30), ada beberapa keuntungan dan kerugian dalam menggunakan DBMS yaitu:
1. Keuntungan
a. Pengendalian redudansi data (Control of data redudancy)
pendekatan basis data berusaha untuk menghilangkan redundansi dengan cara mengintegrasikan file tersebut sehingga beberapa salinan data yang sama tidak disimpan. Namun pendekatan basis data tidak menghilangkan redundansi sepenuhnya, hanya mengendalikan jumlah redudansi yang ada di basis data. Contohnya, Jika suatu saat dibutuhkan duplikat data untuk suatu proses relasi (relationship) atau di saat yang lain dibutuhkan duplikat data untuk meningkatkan kinerja sistem.
b. Konsistensi data (Data consistency)
Dengan menghilangkan atau mengontrol redundansi, kita mengurangi risiko terjadinya tidak konsistennya data.
c. Informasi lebih lanjut dari jumlah data yang sama (More information from the same amount of data)
Dengan integrasi data operasional, dimungkinkan bagi organisasi untuk memperoleh informasi tambahan dari data yang sama.
d. Berbagi data (Sharing of data)
Biasanya sharing of data digunakan oleh pengguna atau departemen yang memiliki file. Di sisi lain, basis data seluruh organisasi dapat dibagi (share) oleh semua pengguna yang berwenang. Dengan cara ini, bila banyak pengguna maka lebih banyak sharing of data. Aplikasi ini juga dapat mengandalkan fungsi yang disediakan oleh DBMS, seperti definisi data, manipulasi, concurrency dan recovery control, daripada harus menyediakan fungsi-fungsi ersebut sendiri.
e. Peningkatan integritas data (Improved data integrity)
Integritas basis data mengacu pada validitas dan konsistensi data yang tersimpan. Integritas biasanya dinyatakan dalam berbagai hal masalah yaitu, konsistensi bahwa aturan basis data tidak diperbolehkan untuk dilanggar.
f. Peningkatan keamanan (Improved security)
Keamanan basis data adalah perlindungan basis data dari pengguna yang tidak berwenang. Tanpa langkah-langkah keamanan yang sesuai, integrasi membuat data lebih rentan dibandingkan dengan sistem berbasis file. Namun, integrasi memungkinkan DBA untuk mendefinisikannya, dan DBMS Ini memungkinkan untuk mengambil nama pengguna dan password untuk mengidentifikasi orang-orang yang berwenang untuk menggunakan basis data. Akses pengguna yang berwenang diperbolehkan pada system basis data dapat dibatasi oleh jenis operasi (pengambilan data, insert, update, dan delete)
g. Penegakan standar (Enforcement of standards)
Integrasi memungkinkan DBA untuk mendefinisikan dan menegakkan standar yang diperlukan. Hal Ini termasuk dalam departemen, standar organisasi nasional atau internasional untuk hal-hal seperti format data yang digunakan untuk memfasilitasi pertukaran data antara sistem, konvensi penamaan, standar dokumentasi, prosedur update, dan aturan akses data.
h. Skala ekonomi (Economy of scale)
Menggabungkan semua data operasional organisasi ke dalam satu basis data, dan menciptakan satu set aplikasi yang bekerja pada salah satu sumber data, dapat menghasilkan penghematan biaya. Dalam kasus ini, anggaran yang biasanya akan dialokasikan untuk masing-masing departemen untuk pengembangan dan pemeliharaan sistem berbasis file yang dapat dikombinasikan, mungkin mengakibatkan total biaya yang lebih rendah. Anggaran yang dikombinasikan dapat digunakan untuk membeli konfigurasi sistem yang lebih sesuai dengan kebutuhan organisasi.
i. Neraca persyaratan yang saling bertentangan (Balance of Conflicting requirements)
Biasanya sistem berbasis file dibuat untuk aplikasi tertentu seperti pemfakturan, sehingga kinerjanya sangat baik. Namun, DBMS dibuat lebih umum untuk dapat menangani beberapa aplikasi secara bersamaan pada satu aplikasi saja. Akibatnya beberapa aplikasi yang berjalan kinerjanya tidak secepat sebelumnya.
j. Peningkatan aksesibilitas data dan responsifitas (Improved Data accessibility and responsiveness)
sebagai hasil integrasi, data yang melintasi batas-batas departemen diakses secara langsung ke End-user. Ini memberikan sebuah sistem dengan fungsionalitas yang memiliki banyak potensi, misalnya digunakan untuk menyediakan layanan yang lebih baik kepada End-user atau klien organisasi. Banyak DBMS menyediakan bahasa query atau penulis laporan yang memungkinkan pengguna untuk mengajukan pertanyaan adhoc dan memperoleh informasi yang diperlukan di terminal mereka.
k. Peningkatan produktivitas (Increased Productivity)
DBMS menyediakan banyak fungsi standar yang biasanya programmer harus menulis dalam aplikasi yang berbasis file. Pada tingkat dasar, DBMS menyediakan semua rutinitas penanganan berkas tingkat rendah dalam program aplikasi. Penyediaan fungsi
ini memungkinkan programmer untuk berkonsentrasi pada fungsi tertentu yang diperlukan oleh pengguna tanpa harus khawatir tentang rincian pelaksanaan tingkat rendah. Banyak DBMS juga menyediakan lingkungan generasi keempat yang terdiri dari suatu alat untuk menyederhanakan pengembangan aplikasi basis data. Hal ini menyebabkan peningkatan produktivitas programmer dan mengurangi waktu pengembangan (dengan penghematan biaya yang terkait)
l. Peningkatan pemeliharaan melalui data independence (Improved Maintenance through data independence)
Dalam sistem berbasis file, deskripsi data dan logika untuk mengakses data yang dibangun ke dalam setiap program aplikasi, membuat program tergantung pada data. Sebuah perubahan pada struktur data, atau perubahan dengan cara data disimpan pada disk, dapat memerlukan perubahan substansial program yang dipengaruhi oleh perubahan. Sebaliknya, DBMS memisahkan deskripsi data dari aplikasi, sehingga membuat aplikasi kebal terhadap perubahan dalam deskripsi data.
m. Peningkatan konkurensi (Increased concurrency)
Dalam beberapa sistem berbasis file, jika dua atau lebih pengguna yang diizinkan untuk mengakses file yang sama secara bersamaan, memungkinkan akses akan mengganggu satu sama lain, sehingga akan terjadi hilangnya informasi atau bahkan hilangnya integritas. Banyak DBMS yang mengelola akses basis data secara bersamaan dan memastikan masalah tersebut tidak terjadi.
n. Peningkatan layanan backup dan recovery (Improved backup and recovery services)
Banyak sistem berbasis file yang menempatkan tanggung jawab pada pengguna untuk memberikan langkah-langkah supaya melindungi data dari kegagalan ke sistem komputer atau program aplikasi. Dalam hal kegagalan, cadangan recovery dari pekerjaan yang telah di backup dimasukkan kembali. Sebaliknya, DBMS
modern menyediakan fasilitas untuk meminimalkan jumlah pengolahan data yang hilang.
2. Kerugian
a. Kompleksitas (Complexity)
Penyediaan fungsi dari DBMS yang baik diharapkan akan membuat DBMS menjadi perangkat lunak yang sangat komplek. Database designers and developers, the data and database administrator, dan end-user harus memahami fungsi ini untuk mengambil keuntungan. Kegagalan untuk memahami sistem dapat menyebabkan desain yang buruk, yang dapat memiliki konsekuensi serius bagi suatu organisasi.
b. Ukuran (Size)
Kompleksitas dan besarnya fungsionalitas membuat DBMS menjadi bagian yang sangat besar sebagai software yang menempati banyak ruang disk dan membutuhkan memori yang besar untuk menjalankan DBMS secara efisien.
c. Biaya DBMS (Cost of DBMS)
Biaya DBMS bervariasi, tergantung pada lingkungan dan fungsi yang disediakan. Misalnya, DBMS single-user untuk komputer pribadi hanya US $100. Namun, mainframe multi-user DBMS yang melayani ratusan pengguna bisa sangat mahal yaitu sekitar US $100.000 atau bahkan US $1.000.000. Ada juga tambahan biaya untuk pemeliharaan setiap tahunnya.
d. Biaya hardware tambahan (Additional hardware cost)
Penyimpanan disk untuk DBMS dan basis data mungkin memerlukan pembelian ruang penyimpanan tambahan. Selanjutnya, untuk mencapai kinerja yang diinginkan, maka perlu untuk membeli mesin yang lebih besar, bahkan mungkin sebuah mesin yang khusus untuk menjalankan DBMS.
e. Biaya konversi (Cost of conversion)
Dalam beberapa situasi, biaya tambahan untuk DBMS dan hardware bisa tidak sebanding dengan biaya konversi aplikasi yang
sudah ada untuk dijalankan pada DBMS dan hardware yang baru. Biaya ini termasuk biaya pelatihan staff untuk menggunakan sistem yang baru, dan memungkinkan untuk memperkerjakan staff ahli untuk membantu konversi dan menjalankan sistem. Biaya merupakan satu alasan utama mengapa beberapa organisasi merasa terikat dengan sistem mereka saat ini dan tidak dapat beralih ke teknologi basis data yang lebih modern.
f. Kinerja (Performance)
Biasanya sistem berbasis file dibuat untuk suatu aplikasi tertentu seperti pemfakturan, sehingga kinerjanya sangat baik. Namun, DBMS dibuat lebih umum sehingga dapat menangani beberapa aplikasi secara bersamaan daripada satu aplikasi saja yang berjalan. Akibatnya beberapa aplikasi yang berjalan kinerjanya tidak secepat sebelumnya.
g. Dampak kegagalan (Higher impact of a failure)
Karena semua pengguna dan aplikasi bergantung pada ketersediaan DBMS, kegagalan pada komponen-komponen tertentu dapat mengakibatkan operasi berhenti.
2.1.5.3 Fungsi DBMS
Menurut Thomas Connolly dan Carolyn Begg (2005:48–52), ada beberapa fungsi DBMS, yaitu:
1. Penyimpanan, pengambilan, dan memperbarui data (Data storage, retrieval, and update)
DBMS harus melengkapi pengguna dengan kemampuan untuk menyimpan, mengambil, dan data dalam basis data.
2. Katalog yang dapat diakses pengguna (a user – accessible catalog) DBMS harus memiliki katalog di mana deskripsi item data disimpan dan dapat diakses oleh pengguna.
3. Transaksi pendukung (Transaction support)
DBMS harus memberikan suatu mekanisme yang memastikan bahwa semua pembaruan yang dibuat sesuai dengan transaksi yang diberikan atau tidak satupun dari mereka yang membuat.
4. Layanan pengendalian concurrency (Concurrency control services) DBMS harus menyediakan mekanisme untuk memastikan bahwa basis data diperbarui dengan benar ketika beberapa pengguna memperbarui basis data secara bersamaan.
5. Layanan perbaikan (Recovery Services)
DBMS harus memberikan suatu cara untuk memulihkan basis data dengan cara apapun jika basis data sedang mengalami kerusakan. 6. Layanan otoritas (Authorization services)
DBMS harus menyediakan mekanisme untuk memastikan bahwa hanya pengguna resmi yang dapat mengakses basis data.
7. Mendukung komunikasi data (Support for data communication) DBMS harus mampu berintegrasi dengan komunikasi perangkat lunak. 8. Layanan integritas (Integrity services)
DBMS harus menyediakan sarana untuk memastikan bahwa data dalam basis data dan perubahan data mengikuti aturan-aturan tertentu.
9. Layanan independensi data (Services to promote data independence) DBMS harus mencakup fasilitas untuk mendukung kemandirian program dari struktur yang sebenarnya dari basis data.
10. Layanan utilitas (Utility services)
DBMS harus menyediakan satu set layanan utilitas. 2.1.6 Bahasa Basis Data (Database Language)
Menurut Thomas Connolly dan Carolyn Begg (2005:39–41), Sebuah sub-bahasa data terdiri dari dua bagian: Data Definition Language (DDL) dan Data Manipulation Language (DML) DDL digunakan untuk menentukan skema basis data dan DML digunakan untuk kedua membaca dan memperbarui basis data. Bahasa ini disebut sub-bahasa data karena mereka tidak termasuk konstruksi untuk semua komputasi kebutuhan seperti bersyarat atau pernyataan berulang, yang disediakan oleh bahasa pemrograman tingkat tinggi.
2.1.6.1 Data Definition Language (DDL)
Menurut Thomas Connolly dan Carolyn Begg (2005:40), DDL adalah sebuah bahasa yang memungkinkan DBA atau pengguna untuk
mendeskripsikan dan menamai entitas, atribut, dan relasi yang dibutuhkan untuk aplikasi, bersama dengan integritas terkait dan kendala keamanan. DDL digunakan untuk mendefinisikan skema atau memodifikasi yang sudah ada. Hal ini tidak dapat digunakan untuk memanipulasi data.
Hasil penyusunan laporan DDL adalah satu set tabel yang disimpan dalam khusus file kolektif disebut sistem katalog. Sistem katalog mengintegrasikan metadata, yaitu data yang menggambarkan objek dalam basis data dan membuatnya lebih mudah bagi objek yang akan diakses atau dimanipulasi. Metadata berisi definisi catatan, item data, dan benda-benda lain yang menarik bagi pengguna atau diwajibkan oleh DBMS. 2.1.6.2 Data Manipulation Language (DML)
Menurut Thomas Connolly dan Carolyn Begg (2005:40–42), DML adalah sebuah bahasa yang menyediakan seperangkat operasi untuk mendukung operasi manipulasi data dasar pada data yang dimiliki dalam basis data. Operasi manipulasi data biasanya meliputi berikut ini:
1. Penyisipan data baru ke dalam basis data. 2. Modifikasi data yang disimpan dalam basis data. 3. Pengambilan data yang terdapat dalam basis data. 4. Penghapusan data dari basis data.
DML dibagi menjadi 2 jenis, yaitu procedural dan non-procedural. Procedural DML adalah Sebuah bahasa yang memungkinkan pengguna untuk memberitahu sistem data apa yang dibutuhkan dan bagaimana cara untuk mendapatkan data. Sedangkan non-procedural DML adalah Sebuah bahasa yang memungkinkan pengguna untuk menyatakan apa yang dibutuhkan data daripada memikirkan bagaimana data tersebut harus didapatkan.
Fungsi utama dari DBMS adalah untuk mendukung manipulasi data, di mana pengguna dapat membuat laporan yang akan menyebabkan manipulasi data tersebut terjadi. Manipulasi data berlaku untuk tingkat eksternal, konseptual, dan internal. Namun, di tingkat internal yang kita
harus mendefinisikan prosedur tingkat rendah yang agak rumit yang memungkinkan akses data yang efisien. Sebaliknya, di tingkat yang lebih tinggi, penekanan ditempatkan pada kemudahan penggunaan dan usaha diarahkan untuk memberikan interaksi pengguna yang efisien dengan sistem. Bagian dari DML yang melibatkan pengambilan data disebut bahasa query. Sebuah bahasa query dapat didefinisikan sebagai tingkat tinggi dengan tujuan khusus, bahasa yang digunakan untuk memenuhi permintaan beragam untuk pengambilan data dalam basis data.
2.1.7 Integrity Enhancement Feature
Menurut Thomas Connolly dan Carolyn Begg (2005:164–168) ada lima jenis integrity constraint yaitu:
1. Required Data
Beberapa kolom harus berisi nilai yang valid dan tidak diperbolehkan mengandung null. null berbeda dari kosong atau nol, karena digunakan untuk merepresentasikan data yang tidak tersedia, atau tidak berlaku . Sebagai contoh, setiap anggota staf harus memiliki posisi pekerjaan yang terkait (misalnya, Manager, Asisten, dan sebagainya). Standar ISO menyediakan kolom specifier NOT NULL di CREATE dan ALTER TABLE untuk menyediakan tipe constraint. The ISO default adalah NULL. Sebagai contoh, untuk menentukan bahwa posisi kolom dari tabel staf tidak dapat null, kita mendefinisikan kolom sebagai:
Position VARCHAR (10) NOT NULL 2. Domain Constraints
Setiap kolom memiliki domain. Misalnya, jenis kelamin anggota staf adalah 'M' atau 'F', sehingga domain kolom jenis kelamin dari tabel staf adalah karakter tunggal yang terdiri dari 'M' atau 'F'. Standar ISO menyediakan dua mekanisme untuk menentukan domain dalam CREATE dan ALTER TABLE. Yang pertama adalah CHECK, yang memungkinkan constraint didefinisikan pada kolom atau seluruh tabel. Format CHECK adalah:
Dalam kolom constraint, CHECK dapat referensi hanya kolom yang ditetapkan. Dengan demikian, untuk memastikan bahwa kolom jenis kelamin hanya dapat ditetapkan sebagai 'M' atau 'F', kita bisa mendefinisikan kolom sebagai:
CHAR seks NOT NULL CHECK (IN seks ('M', 'F'))
Namun, standar ISO memungkinkan domain harus didefinisikan secara lebih eksplisit menggunakan CREATE DOMAIN:
CREATE DOMAIN DomainName [AS] dataType [DEFAULT defaultOption]
[CHECK (searchCondition)] 3. Entity Integrity
Primary key dari tabel harus unik, memiliki nilai non-null di setiap baris. Sebagai contoh, setiap baris dari tabel PropertyForRent memiliki nilai yang unik untuk jumlah properti propertyNo, properti yang unik mengidentifikasi di setiap baris. Standar ISO mendukung integritas entitas PRIMARY KEY di CREATE dan ALTER TABLE. Sebagai contoh, untuk menentukan primary key dari tabel PropertyForRent, yaitu:
PRIMARY KEY(propertyNo)
Untuk menentukan gabungan primary key, kita menentukan beberapa nama kolom dalam PRIMARY KEY, dipisahkan dengan tanda koma. Sebagai contoh, untuk menentukan primary key dari tabel Viewing, yang terdiri dari kolom clientNo dan propertyNo, yaitu:
PRIMARY KEY(clientNo, propertyNo)
PRIMARY KEY ditentukan hanya sekali di setiap tabel. Namun, masih mungkin untuk memastikan keunikan untuk setiap tombol alternatif dalam tabel menggunakan kata kunci UNIQUE. Setiap kolom yang terdapat UNIQUE juga harus dinyatakan sebagai NOT NULL. Mungkin ada banyak UNIQUE di setiap tabel yang diperlukan. SQL untuk menolak setiap operasi INSERT atau UPDATE yang mencoba untuk menciptakan nilai duplikat dalam setiap candidate key (yaitu, primary key atau alternate key). Misalnya, dengan tabel Viewing kita bisa juga menulis:
clientNo VARCHAR(5) NOT NULL,
4. Referential Integrity
Foreign key adalah kolom, atau set kolom, yang menghubungkan setiap baris dalam tabel anak yang berisi foreign key ke baris dari tabel induk yang mengandung nilai candidate key yang cocok. Referential integrity berarti, jika foreign key mengandung nilai,maka nilai tersebut harus mengacu pada nilai yang ada pada baris yang berlaku dalam tabel induk. Sebagai contoh, jumlah cabang kolom branchNo dalam tabel PropertyForRent menghubungkan properti untuk baris dalam tabel Branch di mana properti ditugaskan. Jika nomor cabang tidak null, maka harus berisi nilai yang valid dari branchNo di kolom tabel Branch, atau properti ditugaskan untuk kantor cabang yang tidak valid. Standar ISO mendukung definisi foreign key dengan klausa FOREIGN KEY di CREATE dan ALTER TABLE. Sebagai contoh, untuk menentukan forign key branchNo dari tabel PropertyForRent, yaitu :
FOREIGN KEY(branchNo) REFERENCES Branch
SQL menolak setiap operasi INSERT atau UPDATE yang mencoba untuk menciptakan nilai foreign key dalam tabel anak tanpa nilai candidate key yang cocok dalam tabel induk. SQL diperlukan untuk setiap operasi UPDATE atau DELETE yang mencoba untuk memperbarui atau menghapus nilai candidate key dalam tabel induk yang memiliki beberapa baris yang cocok di tabel anak tergantung pada tindakan referensial ditentukan menggunakan ON UPDATE dan ON DELETE dari FOREIGN KEY. Ketika pengguna mencoba untuk menghapus baris dari tabel induk, dan ada satu baris atau lebih cocok di tabel anak, SQL mendukung empat pilihan mengenai tindakan yang harus diambil: a. CASCADE: Menghapus baris dari tabel induk dan secara otomatis
menghapus baris dalam tabel anak yang sesuai. Karena ini baris dihapus mungkin sendiri memiliki candidate key yang digunakan sebagai foreign key dalam tabel lain, aturan foreign key untuk tabel adalah trigger, dan juga secara cascading.
b. SET NULL: Menghapus baris dari tabel induk dan menetapkan nilai foreign key dalam tabel anak ke NULL. Ini hanya berlaku jika kolom foreign key tidak memiliki kualifikasi NOT NULL yang ditentukan.
c. SET DEFAULT: Menghapus baris dari tabel induk dan mengatur setiap komponen foreign key dalam tabel anak dengan nilai default yang ditentukan. Ini hanya berlaku jika kolom foreign key memiliki nilai DEFAULT yang ditentukan.
d. NO ACTION: Menolak operasi telah terhapus dari tabel induk. Ini adalah pengaturan default jika ON DELETE aturan dihilangkan.
FOREIGN KEY (staffNo) REFERENCES Staff ON DELETE SET NULL FOREIGN KEY (ownerNo) REFERENCES PrivateOwner ON UPDATE CASCADE
5. General Constraint
Memperbaharui tabel dapat dibatasi oleh aturan dari perusahaan yang mengatur transaksi dunia nyata yang diwakili oleh pembaharuan. Sebagai contoh, DreamHome mungkin memiliki aturan yang mencegah anggota staf dari mengelola lebih dari 100 properti pada waktu yang sama. Standar ISO memungkinkan kendala umum yang akan ditentukan menggunakan CHECK dan UNIQUE dari CREATE dan ALTER TABLE dan CREATE ASSERTION. Kita telah membahas CHECK dan klausa UNIQUE di awal bagian ini. CREATE ASSERTION merupakan kendala integritas yang tidak terkait langsung dengan definisi tabel. Format pernyataan itu adalah:
CREATE ASSERTION AssertionName CHECK (searchCondition)
2.1.8 Pemodelan Relasi Entitas (Entity-Relatioship Modelling)
Menurut Thomas Connolly dan Carolyn Begg (2005:342), Pemodelan relasi entitas (Entity-Relatioship Modelling) adalah pendekatan top-down untuk merancang basis data yang dimulai dengan mengidentifikasi data penting yang disebut entitas dan relasi antara data yang harus direpresentasikan dalam model. Kemudian menambahkan rincian seperti informasi mengenai entitas dan relasi yang disebut atribut. Dan setiap kendala pada entitas, relasi, dan atribut. Pemodelan ER adalah teknik penting untuk setiap perancang basis data untuk menguasai dan membentuk dasar dari metodologi yang disajikan.
2.1.8.1 Entity Types
Menurut Thomas Connolly dan Carolyn Begg (2005:343), Entity types adalah sekelompok objek dengan sifat yang sama, yang diidentifikasi oleh perusahaan seperti memiliki eksistensi independen.
Menurut Thomas Connolly dan Carolyn Begg (2005:345), Entity occurrence adalah Sebuah objek yang unik yang bisa diidentifikasikan dari suatu entity.
Secara umum, Tipa entitas dapat diklasifikasikan menjadi : 1. Strong Entity Type
Menurut Thomas Connolly dan Carolyn Begg (2005:354), Strong Entity Type adalah Sebuah tipe entitas yang keberadaannya tidak tergantung pada beberapa tipe entitas lainnya. Sebuah tipe entitas disebut kuat jika keberadaannya tidak tergantung pada keberadaan tipe entitas lain. 2. Weak Entity Type
Menurut Thomas Connolly dan Carolyn Begg (2005:355), Weak entity type adalah Sebuah tipe entitas yang keberadaannya tergantung pada beberapa tipe entitas lainnya. Jenis weak entity kadang-kadang disebut sebagai anak, ketergantungan, atau entitas bawahan dan jenis strong entity sebagai orangtua, pemilik, atau badan yang dominan.
2.1.8.2 Relationship Types
Menurut Thomas Connolly dan Carolyn Begg (2005:346), Relationship types adalah sekumpulan relasi antar entitas yang memiliki arti. Dan Setiap jenis relasi yang terjadi diberi nama yang menggambarkan fungsi. Relationship Occurance adalah suatu relasi unik antara satu atau lebih entitas yang teridentifikasi dalam tipe entitas.
2.1.8.3 Atribute
Menurut Thomas Connolly dan Carolyn Begg (2005:350), Attribute adalah sebuah properti dari suatu entitas atau tipe relasi. Sedangkan attribute domain adalah himpunan nilai-nilai yang di ijinkan untuk satu atau lebih atribut.
Attribute dapat diklasifikasikan sebagai berikut, yaitu: 1. Simple attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), simple attribute adalah sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan yang independen.
2. Composite attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), composite attribute adalah sebuah atribut yang terdiri dari beberapa komponen, masing-masing dengan keberadaan yang independen.
3. Single-valued attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), Single-valued attribute adalah sebuah atribut yang memegang nilai tunggal untuk setiap kejadian dari suatu tipe entitas.
4. Multi-valued attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Multi-valued attribute adalah sebuah atribut yang memegang beberapa nilai untuk setiap kejadian dari suatu entity.
5. Derived attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Derived attribute adalah sebuah atribut yang mewakili nilai yang diturunkan dari nilai atribut terkait atau himpunan atribut, belum tentu dalam jenis entitas yang sama.
2.1.8.4 Kunci (Keys) 1. Candidate Key
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Candidate Key adalah sejumlah kecil atribut unik dari entitas yang mengidentifikasikan setiap kejadian dari suatu tipe entitas.
2. Primary Key
Menurut Thomas Connolly dan Carolyn Begg (2005:353), Primary key adalah candidate key yang dipilih karena unik untuk mengidentifikasi setiap kejadian dari suatu tipe entitas.
3. Composite Key
Menurut Thomas Connolly dan Carolyn Begg (2005:353), Composite key adalah candidate key yang terdiri dari dua atau lebih atribut. 4. Alternate Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Alternate Key adalah
Candidate Key yang tidak terpilih menjadi primary key. 5. Forign Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Foreign key adalah Sebuah atribut atau sekumpulan atribut dalam satu relasi yang sama dengan candidate key beberapa relasi lainnya.
6. Super Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Super key adalah Sebuah atribut atau sekumpulan atribut, yang secara unik mengidentifikasi tuple dalam relasi.
2.1.8.5 Structural Constraint
Berikut ini merupakan kendala yang dapat terjadi di dalam sebuah relas, yaitu sebagai berikut:
1. Multiplicity
Menurut Thomas Connolly dan Carolyn Begg (2005:356), Multiciplity adalah kejadian dari suatu entity yang mungkin berelasi dengan kejadian dari tipe entitas terkait melalui relasi tertentu. Kami menguji tiga jenis relasi menggunakan kendala integritas berikut :
a. One-to-One (1:1) Relationship b. One-to-Many (1:*) Relationships c. Many-to-Many (*:*) Relationships 2. Multiplicity for Complex Relationships
Menurut Thomas Connolly dan Carolyn Begg (2005:361), Multiplicity for Complex Relationships adalah kejadian dari tipe entitas dalam relasi ketika yang lain (n-1) nilainya tetap.
a. Cardinality
Menurut Thomas Connolly dan Carolyn Begg (2005:363), Cardinality menjelaskan mengenai jumlah relasi maksimum yang memungkinkan terjadinya entitas yang berpartisipasi dalam tipe relasi tertentu.
b. Participant
Menurut Thomas Connolly dan Carolyn Begg (2005:363), Participant menentukan apakah semua atau hanya beberapa entitas saja yang berpartisipasi dalam suatu relasi.
2.1.9 Entity Relationship Diagram (ERD)
Menurut Thomas Connolly dan Carolyn Begg (2005:343), konsep dasar model Entity-Relationship, yaitu entitas, relasi, dan atribut. Dalam setiap bagian menggambarkan bagaimana konsep-konsep dasar ER diwakili dan digambarkan dalam diagram ER menggunakan UML.
Menurut Indrajani (2011:18), Entity Relational (ER) Modeling adalah sebuah pendekatan top-down dalam perancangan basis data yang dimulai dengan mengidentifikasikan data-data terpenting yang disebut dengan entitas dan hubungan antara entitas-entitas tersebut yang digambarkan dalam suatu model. 2.1.10 Normalisasi (Normalization)
Menurut Thomas Connolly dan Carolyn Begg (2005:388), Normalisasi adalah Sebuah teknik untuk menghasilkan himpunan relasi dengan properti yang diinginkan, yang sesuai dengan kebutuhan data dari suatu perusahaan.
Menurut Thomas Connolly dan Carolyn Begg (2005:403), Unormalized Form (UNF) adalah sebuah tabel yang berisi satu atau lebih kelompok berulang. Berikut ini merupakan tahap tingkatan normalisasi:
1. First Normal Form (1NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:403), First Normal Form (1NF) adalah Sebuah relasi dimana setiap baris dan kolom berisi satu dan hanya satu nilai, tidak ada perhitungan. Sebuah relasi akan berada dalam bentuk 1NF jika repeating group sudah hilang. Ada dua pendekatan
untuk menghilangkan repeating group pada tabel yang tidak normal (unnormalized table), yaitu:
a. Dengan memasukkan data yang sesuai kedalam kolom yang kosong dari basis yang mengandung kata yang berulang.
b. Dengan menempatkan data yang berulang bersama salinan dari atribut kunci pada relasi yang terpisah.
2. Second Normal Form (2NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:407), Second Normal Form (2NF) adalah suatu relasi yang ada dalam Bentuk Normal Pertama dan setiap atribut bukan non-primer-key sepenuhnya fungsionalitas tergantung pada primary key.
c. Third Normal Form (3NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:409), Third Normal Form (3NF) adalah suatu relasi yang ada di Bentuk Normal Pertama dan Kedua dan di mana tidak ada atribut non-primer-key transitif bergantung pada primary key.
Menurut Thomas Connolly dan Carolyn Begg (2005:409), Third Normal Form (3NF) adalah suatu relasi yang ada di Bentuk Normal Pertama dan Kedua dan di mana tidak ada atribut non-primer-key transitif bergantung pada primary key.
d. Boyce Codd Normal Form (BCNF)
Menurut Thomas Connolly dan Carolyn Begg (2005:419), Boyce Codd Normal Form (BCNF) adalah suatu relasi yang ada pada BCNF, jika, setiap determinan adalah kunci kandidat.
e. Fourth Normal Form (4NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:430), Fourth Normal Form (4NF) adalah sebuah relasi yang ada pada bentuk normal Boyce-Codd dan tidak mengandung ketergantungan banyak nilai.
f. Fifth Normal Form (5NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:431), Fifth Normal Form (5NF) adalah sebuah relasi yang tidak ketergantungan yang bergabung.
2.1.11 Database Application Lifecycle (DBLC)
Menurut Thomas Connolly dan Carolyn Begg (2005:284), Dalam merancang aplikasi sistem basis data diperlukan tahapan-tahapan terstruktur yang harus diikuti, tahapan-tahapan tersebut dinamakan lifecycle aplikasi basis data. Tahapan-tahapan dari lifecycle aplikasi basis data adalah sebagai berikut:
Tabel 2.1 Penjelasan Database System Development Lifecycle (DBLC) Perencanaan basis data
(database planning)
Perencanaan bagaimana tahapan lifecycle dapat direalisasikan secara efisien dan efektif.
Definisi sistem (system definition)
Menentukan ruang lingkup dan batas-batas dari sistem basis data, termasuk pandangan utama pengguna, dan area aplikasi.
Analisis dan pengumpulan kebutuhan (requirements collection and analysis)
Pengumpulan dan analisis persyaratan untuk sistem basis data baru.
Perancangan basis data (database design)
Perancangan konseptual, logikal, dan fisikal dari basis data.
Seleksi DBMS (DBMS selection) (optional)
Memilih DBMS yang cocok untuk sistem basis data.
Perancangan aplikasi (application design)
Merancang user interface dan program aplikasi yang menggunakan dan memproses basis data.
Prototipe (prototyping) (optional)
Membangun model kerja dari sistem basis data, yang memungkinkan para desainer atau pengguna untuk memvisualisasikan dan mengevaluasi bagaimana sistem akhir akan terlihat dan berfungsi.
Implementasi (implementation)
Membuat definisi basis data fisik dan program aplikasi.
Konversi data dan loading (data conversion and loading)
Mengambil data dari sistem lama ke sistem baru dan jika memungkinkan, mengubah aplikasi yang ada untuk dijalankan pada basis data baru .
Pengujian (testing)
Sistem basis data diuji untuk kesalahan dan divalidasi terhadap persyaratan yang ditentukan oleh pengguna .
Operasi pemeliharaan (operational maintenance)
Sistem basis data sepenuhnya dilaksanakan lalu sistem ini terus dipantau dan dipelihara. Bila perlu, persyaratan baru dimasukkan ke dalam sistem basis data melalui tahap sebelumnya dari lifecycle .
2.1.12 Relasi Kunci (Relational Keys) 1. Candidate key
Set minimal attribut yang unik mendefinisikan setiap kejadian pada suatu entity. (Thomas Connolly dan Carolyn Begg, 2005:352)
2. Primary key
Kandidat kunci unik yang dipilih untuk mengidentifikasikan setiap kejadian dari suatu entity. (Thomas Connolly dan Carolyn Begg, 2005:353)
3. Composite key
Kandidat kunci yang terdiri dari dua atau lebih attribut (Thomas Connolly dan Carolyn Begg, 2005:353)
2.1.13 Strong and Weak Entity Types
Menurut Thomas Connolly dan Carolyn Begg (2005:354), Tipe entitas adalah sekelompok objek dengan sifat yang sama, yang di identifikasi oleh perusahaan yang independen keberadaannya.
Ada 2 jenis tipe entitas, yaitu:
1. Tipe entitas kuat (Strong entity types)
Sebuah tipe entitas yang keberadaannya tidak tergantung pada beberapa tipe entitas lainnya. (Thomas Connolly dan Carolyn Begg, 2005:354).
2. Tipe entitas lemah (Weak entity types)
Sebuah tipe entitas yang keberadaannya tergantung pada beberapa tipe entitas lainnya. (Thomas Connolly dan Carolyn Begg, 2005:355).
2.1.14 Perencanaan Basis Data (Database Planning)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:285), perencanaan basis data adalah aktivitas pengelolaan yang memungkinkan tahapan dari siklus hidup basis data (Database Lifecycle) untuk direalisasikan seefisien dan seefektif mungkin. Perencanaan basis data harus terintegrasi dengan keseluruhan system informasi. Ada dua hal utama dalam merumuskan strategi sistem informasi, yaitu:
1. Identifikasi rencana dan tujuan perusahaan dengan Kebutuhan sistem informasi perusahaan berikutnya.
2. Evaluasi sistem informasi saat ini untuk menentukan kekuatan dan kelemahan yang ada saat ini.
Melakukan penilaian Teknologi Informasi yang mungkin memiliki peluang untuk menghasilkan keunggulan yang kompetitif.
2.1.15 Definisi Sistem (System Definition)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:286), definisi sistem menjelaskan mengenai ruang lingkup dan batasan dari aplikasi basis data dan pandangan pengguna lain. Sebelum mencoba untuk merancang sebuah sistem basis data, hal penting yang harus dilakukan adalah
mengidentifikasi batasan-batasan dari sistem yang sedang diselidiki. Hal ini sangat penting dilakukan dalam proses perancangan basis data agar lebih terfokus pada sistem yang akan dibuat.
2.1.15.1 Tampilan Pengguna (User Views)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:287), tampilan pengguna Mendefinisikan apa yang dibutuhkan dari sistem basis data dari perspektif peran maupun pekerjaan tertentu (seperti Manager atau Supervisor) atau bidang aplikasi enterprise (seperti pemasaran, personalia, atau stok kontrol). Sebuah sistem basis data dapat memiliki satu atau lebih pandangan pengguna. Mengidentifikasi pandangan pengguna merupakan aspek penting pengembangan sistem basis data karena membantu untuk memastikan bahwa tidak ada pengguna utama basis data dilupakan ketika mengembangkan persyaratan untuk sistem basis data baru.
2.1.16 Pengumpulan dan Analisis Kebutuhan
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:287), Pengumpulan dan Analisis Kebutuhan adalah Proses mengumpulkan dan menganalisis informasi tentang bagian dari organisasi yang akan didukung oleh sistem basis data, dan menggunakan informasi ini untuk mengidentifikasi persyaratan untuk sistem baru.
Tahap ini melibatkan pengumpulan dan analisis informasi mengenai bagian dari perusahaan yang akan dilayani oleh basis data. Ada banyak teknik untuk mengumpulkan informasi ini yang disebut teknik pencarian fakta. Informasi yang dikumpulkan meliputi :
1. deskripsi data yang digunakan atau yang dihasilkan.
2. rincian tentang bagaimana data akan digunakan atau dihasilkan. 3. persyaratan tambahan untuk sistem basis data baru.
Kegiatan penting lainnya yang terkait dengan tahap ini adalah memutuskan bagaimana menangani situasi jika lebih dari satu tampilan pengguna untuk sistem basis data. Ada tiga pendekatan utama untuk mengelola persyaratan sistem basis data dengan beberapa tampilan pengguna, yaitu :
1. pendekatan terpusat (the centralized approach)
kebutuhan untuk aplikasi basis data. Umumnya pendekatan ini dipakai jika basis datanya tidak terlalu kompleks.
2. pendekatan integrasi pandangan (the view integration approach)
Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun sebuah model yang terpisah yang mepresentasikan tiap pandangan pemakai tersebut. Hasil dari data-data model tersebut kemudian digabung dalam rancangan basis data.
3. kombinasi kedua pendekatan tersebut (a combination of both approaches) 2.1.17 Perancangan Basis Data (Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:291), Perancangan basis data adalah proses menciptakan desain yang akan mendukung pernyataan dan tujuan misi perusahaan untuk sistem basis data yang diperlukan.
Pada bagian ini akan membahas mengenai gambaran dari pendekatan utama untuk desain basis data. Selain itu juga mendiskusikan tujuan dan penggunaan pemodelan data dalam desain basis data. tiga tahapan desain basis data yaitu desain konseptual, logikal, dan fisikal.
Pendekatan dalam perancangan basis data, antara lain : 1. Bottom-Up
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:291), bottom-up dimulai pada tingkat dasar atribut (yaitu, sifat entitas dan relasi), yang melalui analisis relasi antara atribut, dikelompokkan ke dalam relasi yang mewakili jenis entitas dan relasi antar entitas.
2. Top-Down
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292), Top-Down merupakan Sebuah strategi yang lebih tepat untuk desain basis data yang. Pendekatan ini dimulai dengan pengembangan model data yang berisi entitas dan relasi tingkat tinggi dan kemudian menerapkan perbaikan top-down untuk mengidentifikasi entitas tingkat rendah, relasi, dan atribut yang terkait. Pendekatan top-down diilustrasikan menggunakan konsep
Entity-Relationship (ER) model, dimulai dengan identifikasi entitas dan relasi antara entitas, yang menarik bagi organisasi.
3. Inside-Out
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292), Pendekatan inside-out berkaitan dengan pendekatan bottom-up tetapi berbeda, dengan terlebih dahulu mengidentifikasi satu set entitas utama dan kemudian menyebar keluar untuk mempertimbangkan entitas lain, relasi, dan atribut yang berelasi dengan yang pertama kali diidentifikasi.
4. Mixed Strategy
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292), Pendekatan strategi campuran menggunakan kedua pendekatan bottom-up dan top-down untuk berbagai bagian dari model sebelum akhirnya menggabungkan semua bagian bersama-sama.
2.1.17.1 Perancangan Basis Data Konseptual (Conceptual Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:293), Perancangan basis data konseptual adalah proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan, independen dari semua pertimbangan fisikal.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:442), Tujuan perancangan basis data konseptual adalah untuk membangun sebuah model data konseptual dari persyaratan data dari perusahaan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:440–459), Langkah-langkah dalam membangun model data konseptual adalah sebagai berikut :
1. Membangun model data konseptual
a. Langkah 1.1 : Mengdentifikasi tipe entitas b. Langkah 1.2 : Mengidentifikasi tipe relasi
c. Langkah 1.3 : Mengidentifikasi dan mengasosiasikan atribut dengan entitas atau relasi jenis
d. Langkah 1.4 : Menentukan domain atribut
e. Langkah 1.5 : Menentukan candidate, primary, and alternate key attributes
f. Langkah 1.6 : Mempertimbangkan penggunaan konsep model yang disempurnakan (langkah opsional)
g. Langkah 1.7 : Memeriksa model untuk redundansi
h. Langkah 1.8 : Validasi model konseptual terhadap transaksi pengguna
i. Langkah 1.9 : Ulasan model data konseptual dengan pengguna
Berikut adalah penjelasan dari langkah-langkah diatas. 1. Langkah 1 : Membangun model data konseptual
membangun model data konseptual sesuai dengan kebutuhan data pada perusahaan, Tahap pertama dalam perancangan basis data konseptual adalah membangun satu atau lebih model data konseptual yang sesuai dengan kebutuhan data dari perusahaan. (Thomas Connolly dan Carolyn Begg, 2005:442–443)
Tahapan-tahapan yang dilakukan pada langkah pertama adalah : 1. Langkah 1.1 : Mengidentifikasi tipe entitas
Mendefinisikan objek-objek utama user. Objek-objek ini merupakan tipe-tipe entitas untuk model tersebut. Salah satu metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan user dengan mengidentifikasi kata benda. Contohnya adalah staff number, staff name, property number, property room dan sebagainya. (Thomas Connolly dan Carolyn Begg, 2005:443–444)
2. Langkah 1.2 : Mengidentifikasi tipe relasi
Setelah mengidentifikasi tipe entitas, langkah selanjutnya yaitu mengidentifikasikan semua relasi-relasi penting yang ada diantara tipe entitas yang telah diidentifikasikan. Setelah
mengidentifikasikan relasi, langkah selanjutnya yaitu menentukan multiplicity dari setiap relasi. Batasan multiply digunakan untuk memeriksa dan memelihara kualitas data. (Thomas Connolly dan Carolyn Begg, 2005:445–447)
3. Langkah 1.3 : Mengidentifikasi dan menghubungkan atribut dengan tipe entitas atau relationship
Langkah berikutnya yaitu mengidentifikasi atribut-atribut yang terdapat dalam suatu entitas. Biasanya berupa kata benda atau frasa kata benda dari spesifikasi kebutuhan user. Ada 3 jenis atribut, yaitu : Simple atau composite attributes, single atau multi-value attributes, derived attributes. (Thomas Connolly dan Carolyn Begg, 2005:447–450)
4. Langkah 1.4 : Menentukan domain atribut
Tahap ini bertujuan untuk menentukan domain atribut di model data konseptual lokal. Domain merupakan kumpulan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Sebuah model data yang baik menentukan domain untuk setiap atribut dan termasuk sekumpulan nilai-nilai yang diperbolehkan untuk atribut juga ukuran dan format dari atribut. (Thomas Connolly dan Carolyn Begg, 2005:450-451)
5. Langkah 1.5 : Menentukan atribut candidate key, primary key, dan alternate key
Candidate key adalah kunci yang unik atau tidak mungkin sama atau berbeda dengan yang lain, dapat dipakai untuk mengidentifikasi satu baris dalam tipe entitas. Primary key adalah candidate key yang dipilih sebagai kunci primer untuk mengidentifikasikan setiap entitas. Langkah ini bertujuan untuk mengidentifikasi candidate key untuk setiap tipe entitas, jika terdapat lebih dari satu candidate key kemudian pilih salah satunya menjadi primary key. Alternate key merupakan candidate key yang tidak dipilih menjadi primary key. (Thomas Connolly dan Carolyn Begg, 2005:451–452)
6. Langkah 1.6 : Mempertimbangkan penggunaan enhanced modeling concepts (optional step)
Mempertimbangkan penggunaan enhanced modeling concepts seperti specialization atau generalization, aggregation, dan composition. Jika memilih pendekatan specialization, usahakan untuk memperhatikan perbedaan antara entitas dengan mendefinisikan satu atau lebih subclass dari sebuah entitas superclass. Jika memilih menggunakan pendekatan generalization, usahakan untuk mengidentifikasikan fitur-fitur umum antara entitas untuk mendefinisikan generalisasi entitas superclass. Pendekatan aggregation digunakan untuk mempresentasikan relasi “mempunyai sesuatu” atau “bagian dari” relasi antara tipe-tipe entitas, dimana yang satu mempresentasikan “keseluruhan” dan yang lain sebagai “bagiannya”. Pendekatan composition digunakan untuk mempresentasikan sebuah asosiasi antara tipe-tipe entitas dimana terdapat kepemilikan yang kuat dan relasi antara “keseluruhan” dan “bagiannya”. (Thomas Connolly dan Carolyn Begg 2005:453–481)
7. Langkah 1.7 : Cek model untuk redudansi
Tahap ini bertujuan untuk memeriksa model data konseptual lokal, apakah masih ada redudansi pada model. Dua aktivitas pada tahap ini, yaitu :
i. Memeriksa kembali relasi one-to-one (1 :1)
Saat identifikasi entitas, mungkin saja kita menemukan dua entitas yang merepresentasikan objek yang sama pada perusahaan. Untuk kejadian ini kedua entitas tersebut harus digabungkan. Jika primary key berbeda, pilih salah satu untuk menjadi primary key dan biarkan yang lain menjadi alternate key.
ii. Menghilangkan relasi yang redundan
Data model yang baik sangat diharapkan untuk tidak memiliki relasi yang redudan. Suatu relasi dikatakan
redudansi jika terdapat informasi yang sama yang diperbolehkan oleh relasi lain.
iii. Mempertimbangkan dimensi waktu Dimensi waktu dalam relasi sangat penting dalam menentukan redudansi. (Thomas Connolly dan Carolyn Begg, 2005:453–456) 8. Langkah 1.8 : Validasi model konseptual lokal dengan transaksi
user
Tahap ini bertujuan untuk memastikan bahwa model konseptual mendukung kebutuhan transaksi yang diperlukan bagi view. Dua pendekatan untuk memastikan model data konseptual mendukung kebutuhan transaksi, yaitu:
i. Mendeskripsikan transaksi
Memeriksa apakah semua informasi (entitas, relasi, dan atributnya) yang dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan sebuah deskripsi dari setiap kebutuhan transaksi.
ii. Menggunakan jalur transaksi
Memvalidasi model data terhadap kebutuhan transaksi yang melibatkan diagram yang merepresentasikan jalur setiap transaksi dalam diagram ER. (Thomas Connolly dan Carolyn Begg, 2005:456–458)
9. Langkah 1.9 : Meninjau kembali model data konseptual lokal dengan user Pada langkah ini, user akan meninjau ulang model data konseptual. Jika terjadi anomali pada model data, maka harus dilakukan perubahan yang mungkin memerlukan pengulangan langkah-langkah sebelumnya. Proses ini akan terus diulang sampai model data benar-benar menjadi representasi aktual dari perusahaan. (Thomas Connolly dan Carolyn Begg, 2005:458) 2.1.17.2 Perancangan Basis Data Logikal (Logical Database Design) Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:294), Perancangan basis data logikal adalah proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan
berdasarkan pada model data yang spesifik, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:442), Tujuan perancangan basis data logikal adalah untuk menerjemahkan model data konseptual menjadi model data logikal dan kemudian untuk memvalidasi model ini untuk memeriksa bahwa itu secara struktural benar dan mampu mendukung transaksi yang diperlukan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:462–493) Langkah-langkah dalam membangun model data logikal adalah sebagai berikut:
2. Langkah 2 : Membangun model data logikal
a. Langkah 2.1 : Menurunkan relasi untuk model data logikal b. Langkah 2.2 : Validasi relasi dengan menggunakan
normalisasi
c. Langkah 2.3 : Validasi relasi terhadap transaksi pengguna d. Langkah 2.4 : Memeriksa kendala integritas
e. Langkah 2.5 : Meninjau kembali model data logikal dengan pengguna
f. Langkah 2.6 : Menggabungkan model data logikal ke dalam model global (optional step)
g. Langkah 2.7 : Memeriksa perkembangan di masa depan Berikut adalah penjelasan dari langkah-langkah diatas.
a. Langkah 2.1 : Menurunkan relasi untuk model data logikal Tahap ini bertujuan untuk membuat relasi untuk model data logikal untuk merepresentasikan entitas, relasi dan atribut yang telah diidentifikasikan. Cara–cara yang dapat dilakukan untuk mendapatkan relasi dari data model yang ada adalah tipe entitas kuat, tipe entitas lemah, tipe relasi binary one-to-many (1:*), tipe relasi binary one-to-one (1:1), relasi rekursif one-to-one(1:1), tipe relasi superclass / subclass, tipe relasi binary many-to-many (*:*),
tipe relasi kompleks, atribut multi-valued. (Thomas Connolly dan Carolyn Begg, 2005:463–472)
b. Langkah 2.2 : Validasi relasi menggunakan normalisasi
Normalisasi digunakan untuk memastikan relasi dan atribut yang mendukung kebutuhan dari perusahaan. Juga redudansi data yang minimal pada relasi untuk menghindari masalah yang mungkin terjadi. Proses normalisasi terdiri dari UNF, 1NF, 2NF, 3NF. (Thomas Connolly dan Carolyn Begg, 2005:473–474)
c. Langkah 2.3 : Validasi relasi terhadap transaksi pengguna.
Tujuan pada tahap ini yaitu untuk memvalidasi model data logikal untuk memastikan bahwa model data mendukung kebutuhan transaksi yang telah tercantum didalam spesifikasi kebutuhan user. Validasi transaksi seperti ini sudah dilakukan pada tahap 1.8, namun kembali dilakukan untuk memeriksa relasi-relasi yang telah dibuat pada langkah sebelumnya juga mendukung transaksi ini. Juga untuk memastikan tidak terdapat kesalahan dalam pembuatan relasi-relasi. (Thomas Connolly dan Carolyn Begg, 2005:474)
d. Langkah 2.4 : Memeriksa kendala integritas.
Kendala integritas adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten (Thomas Connolly dan Carolyn Begg, 2005:474–478)
Tipe integrity constraint, yaitu : i. required data
ii. attribute domain constraints iii. multiplicity
iv. entity integrity v. referential integrity vi. general constraints
e. Langkah 2.5 : Meninjau Kembali model data logikal dengan pengguna
Tahapan ini Untuk meninjau model data logikal dengan pengguna dan untuk memastikan bahwa mereka mempertimbangkan model data yang terbentuk merupakan representasi data perusahaan tersebut. (Thomas Connolly dan Carolyn Begg, 2005:478–479) f. Langkah 2.6 : Menggabungkan model data logikal ke dalam
model global (optional step)
Tahapan ini bertujuan untuk menggabungkan model data logical local ke dalam data model single global logical yang mewakili semua user views dari basis data. Aktivitas dalam tahap ini, yaitu:
i. Menggabungkan model data logikal lokal ke dalam model global,
ii. Validasi model data logikal global,
iii. Meninjau kembali model data logikal global dengan user (Thomas Connolly dan Carolyn Begg, 2005:479–590). g. Langkah 2.7 : Memeriksa perkembangan di masa depan
Tujuan dari tahap ini adalah untuk menentukan apakah ada perubahan yang signifikan di masa depan dan untuk memperkirakan apakah model data logikal bisa mengakomodasi perubahan tersebut. (Thomas Connolly dan Carolyn Begg, 2005:490)
2.1.17.3 Perancangan Basis Data Fisikal (Physical Database Design) Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:294), Perancangan basis data fisikal adalah proses dalam menghasilkan deskripsi implementasi basis data pada secondary storage, hal ini menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data, setiap kendala integritas yang terkait dan tahap – tahap keamanan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:496–517), Langkah-langkah dalam membangun model data logikal adalah sebagai berikut :
3. Langkah 3 : Menerjemahkan model data logikal global
untuk sasaran DBMS
a. Langkah 3.1 : Merancang relasi dasar
b. Langkah 3.2 : Merancang representasi dari derived data c. Langkah 3.3 : Merancang kendala umum
4. Langkah 4 : Merancang organisasi file dan indeks a. Langkah 4.1 : Menganalisa transaksi
b. Langkah 4.2 : Memilih organisasi file c. Langkah 4.3 : Memilih indeks
d. Langkah 4.4 : Memperkirakan kebutuhan ruang disk 5. Langkah 5 : Mendesain user view
6. Langkah 6 : Mendesain mekanisme keamanan
7. Langkah 7 : Mempertimbangkan petunjuk controlled
redundancy
8. Langkah 8 : Memonitor dan memperbaiki sistem
operasional
Berikut adalah penjelasan dari langkah-langkah diatas.
3. Langkah 3 : Menerjemahkan model data logikal global untuk sasaran DBMS
Langkah ini bertujuan untuk menghasilkan skema basis data relational dari model data logikal yang dapat diimplementasikan pada DBMS pilihan. Bagian pertama dari proses ini melibatkan perbandingan informasi yang dikumpulkan selama perancangan basis data logikal. Sedangkan bagian kedua dari proses ini menggunakan informasi tersebut untuk menghasilkan desain relasi dasar. (Thomas Connolly dan Carolyn Begg, 2005:497–498)
a. Langkah 3.1 : Merancang relasi dasar
Menentukan bagaimana mempresentasikan relasi dasar dalam model data logikal ke dalam DBMS.
(Thomas Connolly dan Carolyn Begg, 2005:498–499) b. Langkah 3.2: Merancang representasi dari derived data
Menentukan bagaimana mempresentasikan beberapa derived data yang terdapat dalam model data logikal ke dalam DBMS. (Thomas Connolly dan Carolyn Begg, 2005:499–501)
c. Langkah 3.3 : Merancang kendala umum
Perubahan terhadap data dapat dibatasi oleh general constraint yang mengatur transaksi dalam “dunia nyata”. Perancangan batasan ini tergantung pada pemilihan DBMS yang akan digunakan. Beberapa DBMS menyediakan fasilitas ini, namun ada juga yang tidak menyediakannya, sehingga untuk menentukan batasan harus dilakukan pada program aplikasi. (Thomas Connolly dan Carolyn Begg, 2005:501)
4. Langkah 4 : Merancang organisasi file dan indeks
Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai hasil yang baik, yaitu dengan cara dimana relasi dan basis data akan dipegang di tempat penyimpanan akhir sekunder. (Thomas Connolly dan Carolyn Begg, 2005:501–502)
a. Langkah 4.1 : Menganalisa transaksi
Analisa transaksi berfungsi untuk memahami fungsi dari transaksi yang akan dijalankan pada basis data dan untuk menganalisa transaksi yang penting. (Thomas Connolly dan Carolyn Begg, 2005:502–506)
b. Langkah 4.2 : Memilih organisasi file
Bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Ada lima tipe organisasi file, yaitu heap, hash, indexed sequential office access method (ISAM), b-tree, dan clusters. (Thomas Connolly dan Carolyn Begg, 2005:506–508) c. Langkah 4.3 : Memilih indeks
Menentukan apakah dengan menambahkan indeks akan meningkatkan kinerja dari sistem.
