2.1 Pendekatan Basis Data 2.1.1 Data
Menurut Conolly (2005,p19), Data adalah komponen yang paling penting dalam DBMS, berasal dari sudut pandang end-user. Data bertindak sebagai jembatan yang menghubungkan antara mesin dengan pengguna.
Menurut James A. O’Brien, 2003, p13, Data adalah fakta-fakta atau observasi yang mentah, biasanya mengenai kejadian / transaksi bisnis.
Menurut Jeffery L. Whitten (2004, p23), Data adalah fakta mentah mengenai orang, tempat, kejadian, dan hal-hal penting dalam organisasi.
Jadi arti data adalah fakta-fakta mengenai segala sesuatu yang dapat diolah untuk menghasilkan informasi yang akan dipakai dalam melakukan transaksi-transaksi di perusahaan / organisasi.
2.1.2 Database
Menurut Jeffery L. Whitten (2004, p518), Database adalah kumpulan file yang saling terkait.
Menurut Conolly (2005,p14), Database adalah sekumpulan data yang terhubung secara logical, dan deskripsi dari data tersebut, yang dapat
digunakan oleh banyak user, dan dibentuk untuk dapat menghasilkan informasi yang dibutuhkan oleh organisasi.
Menurut James A. O’Brien (2003,p145), Database adalah sebuah kumpulan yang terintegrasi dari elemen data yang terhubung secara
logical. Elemen data mendeskripsikan entitas dan hubungan antar entitas. Menurut McLeod (2001, p16), Database adalah suatu koleksi data komputer yang terintegrasi, diorganisasikan, dan disimpan dengan suatu cara yang memudahkan pengambilan kembali.
Menurut Hoffer (2002, p4), database adalah kumpulan data yang terorganisir dan sercara logika berkaitan. Terorganisir maksudnya data distrukturkan sehingga mudah untuk disimpan, dimanipulasi, dan diperoleh oleh pengguna. Berkaitan maksudnya adalah data menggambarkan daerah asal (domain) kepentingan tertentu bagi kelompok pengguna dan pengguna dapat menggunakan data untuk menjawab pertanyaan seputar domain itu.
Menurut Turban (2003, p16), database merupakan kumpulan file
atau record yang terorganisir yang menyimpan data berserta hubungan diantara data tersebut.
Jadi, database adalah kumpulan data atau koleksi file atau record
yang menyimpan data yang berhubungan dan terstruktur sehingga mudah untuk disimpan, diperoleh kembali, dimanipulasi dan dapat memenuhi kebutuhan informasi dari suatu organisasi.
2.1.3 Database Management Sistem
Menurut Connolly (2002, p16), Database Management System
(DBMS) adalah sebuah sistem piranti lunak yang memperbolehkan pengguna untuk menggambarkan / mendefinisikan, membuat, menjaga / memelihara, dan mengontrol akses ke basisdata.
Menurut Jeffery L. Whitten (2004, p520), Database Management System (DBMS) adalah perangkat lunak khusus yang digunakan untuk membuat, mengontrol, dan mengelola sebuah database.
Menurut Date (2000, p43), DBMS merupakan piranti lunak yang menangani seluruh akses terhadap basis data.
Jadi, DBMS adalah suatu sistem piranti lunak yang menyediakan fasilitas yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, mengendalikan, dan menangani /mengontrol seluruh akses terhadap database.
2.1.4 Model Entity Relasional
Menurut Connolly dan Begg (2002, p330), Pemodelan ER merupakan pendekatan top-down terhadap perancangan basis data yang dimulai dengan mengidentifikasikan data penting yang disebut entity dan
relationship antara data yang harus ditampilkan dalam model.
Jadi, model entity relasional adalah suatu tahapan dalam perancangan basisdata yang menggambarkan (memodelkan) hubungan antara satu entity dengan entity lainnya.
2.1.5 Model Relational
Menurut Conolly (2005, p74), Database model relational adalah kumpulan dari relations yang telah mengalami proses normalisasi dan memiliki nama relation yang berbeda.
Menurut Elmasri (2000, p196), model relasional merepresentasikan database sebagai kumpulan relasi. Dimana relasi itu kita bayangkan sebagai sebuah tabel yang berisi kumpulan data yang terhubung.
Jadi, model relasional adalah kumpulan dari relasi berbeda yang mengalami proses normalisasi.
2.1.6 Metodologi siklus hidup aplikasi database (Database Application Lifecycle)
Menurut Connolly (2005, p283), sistem basis data merupakan komponen dasar dari organisasi yang lebih besar dengan sistem informasi yang lebih luas.
Hal yang penting untuk diakui adalah bahwa tahapan dalam
database application lifecycle tidak sepenuhnya harus berurutan, tetapi melibatkan beberapa jumlah repetisi dari tahapan sebelumnya melalui perulangan feedback. Misalnya, masalah yang ditemui selama perancangan basis data (database design) dapat mengharuskan tambahan kebutuhan pengumpulan dan analisis (requirement collection and analysis).
Untuk sistem basis data yang kecil, dengan jumlah pengguna yang sedikit, lifecycle tidak membutuhkan yang benar-benar kompleks. Bagaimanapun, ketika merancang sebuah sistem basis data menengah ke atas dengan sepuluh sampai ribuan pengguna, menggunakan ratusan query
dan program aplikasi, lifecycle dapat menjadi luar biasa kompleks.
Tahapan database application lifecycle dapat dilihat pada gambar dibawah ini :
Gambar 2.1. Tahapan database application lifecycle(Connolly, 2005, p284)
Prototyping (optional) Implementation
Data conversion and loading Operational maintance testing Database design Database Planning System Definition Requirement collection and analysis DBMS selection (optional) Application design Conceptual Database Design
Logical Database Design
2.1.6.1 Perencanaan Basis Data
Perencanaan Basis Data (Database planning) merupakan aktivitas manajemen yang memperkenankan tahapan database application lifecycle
direlasikan seefisien dan seefektif mungkin. Perencanaan basis data harus diintegrasikan dengan semua strategi sistem informasi organisasi. Ada tiga isu pokok yang terlibat dalam perumusan strategi sistem informasi, diantaranya :
- Identifikasi rencana dan tujuan perusahaan, kemudian menentukan kebutuhan sistem informasi.
- Evaluasi sistem informasi yang ada untuk menentukan kelebihan dan kelemahan yang ada.
- Penafsiran kesempatan teknologi informasi yang dapat menghasilkan kekuatan kompetitif.
Langkah penting pertama dalam perencanaan basis data adalah mendefinisikan dengan jelas mission statement untuk proyek basis data.
Mission statement mendefinisikan tujuan dari aplikasi basis data. Mission statement membantu untuk menjelaskan tujuan dari proyek basis data dan memberi garis yang jelas terhadap pembuatan aplikasi basis data yang dibutuhkan secara efisien dan efektif. Biasanya direktur atau pemilik perusahaan yang menegaskan mission statement.
Setelah mission statement didefinisikan, maka langkah selanjutnya adalah menetapkan mission objectives. Setiap mission objective akan
menetapkan tugas khusus yang harus didukung oleh basis data. Jika basis data mendukung mission objective, maka mission statement akan didapat.
Dengan kata lain, mission statement bisa didapatkan dengan melakukan wawancara dengan direktur atau pegawai lainnya yang berhubungan dengan hal-hal seperti: apa tujuan perusahaan, kenapa perusahaan membutuhkan basis data, bagaimana basis data dapat menyelesaikan masalah perusahaan, dan sebagainya. Sedangkan mission objective dapat diperoleh dengan mengajukan pertanyaan seperti : apa pekerjaannya, tugas apa yang dilakukan setiap hari, leporan apa yang dihasilkan, pelayanan apa yang diberikan perusahaan terhadap pelanggan, dan sebagainya. (Connolly, 2005, pp285-286)
2.1.6.2 System Definiton
System definition mendeskripsikan jangkauan dan batasan dari aplikasi basis data dan pendangan para pengguna.
User views menentukan apa yang dibutuhkan oleh aplikasi basis data untuk jabatan tertentu seperti, manajer atau supervisor atau bidang aplikasi perusahaan seperti, pemasaran, personalia, atau kontrol persediaan.
Sebelum merancang aplikasi basis data, diperlukan identifikasi terhadap batasan dari sistem dan bagaimana antar mukanya dengan bagian lain dari sistem informasi organisasi. Sistem yang dibuat, diusahakan agar
tidak hanya mencakup pengguna dan aplikasi yang sekarang, tetapi juga pengguna dan aplikasi untuk masa yang akan datang.
Aplikasi basis data dapat memiliki satu atau lebih User views.
User views menentukan apa yang dibutuhkan oleh aplikasi basis data dari perspektif peranan pekerjaan tertentu (seperti manajer atau supervisor) dan area aplikasi perusahaan (seperti pemasaran, personalia, atau kontrol persediaan). Mengidentifikasi pandangan pengguna tersebut merupakan aspek penting dalam mengembangkan aplikasi basis data karena dapat membantu meyakinkan bahwa tidak ada pengguna utama yang terlupakan ketika sedang mengembangkan kebutuhan untuk aplikasi baru. User views
juga membantu dalam pengembangan aplikai basis data yang kompleks. (Connolly, 2005, pp286-287)
2.1.6.3 Analisis dan pengumpulan kebutuhan
Analisis dan pengumpulan kebutuhan (requirement collection and analysis) adalah proses mengumpulkan dan menganalisis informasi tentang bagian dari organisasi yang akan didukung oleh aplikasi basis data dan menggunakan informasi untuk mengidentifikasi kebutuhan pengguna dalam sistem yang baru.
Pada tahap ini ada beberapa teknik yang digunakan untuk mengumpulkan data yang dinamakan fact-finding techniques. Teknik-teknik yang digunakan antara lain: mempelajari dokumen, wawancara, pengamatan terhadap kegiatan perusahaan, penelitian, dan kuisioner.
Hal penting lainnya yang tekait dengan tahap ini adalah memutuskan bagaimana menghadapi situasi dimana terdapat lebih dari satu pandangan pengguna untuk aplikasi basis data. Ada tiga pendekatan utama untuk mengatasi situasi tersebut, yaitu:
- Centralized approach
Kebutuhan-kebutuhan untuk setiap pandangan pengguna digabungkan menjadi satu perangkat kebutuhan untuk aplikasi basis data yang baru.
- View integration approach
Kebutuhan-kebutuhan untuk setiap pandangan pengguna digunakan untuk membangun model data terpisah yang akan merepresentasikan pendangan pengguna tersebut. Hasil dari model data kemudian digabungkan pada tahap perancangan basis data.
- Combination of both approaches
Merupakan kombinasi dari centralized approach dan view integration approach. (Connolly, 2005, pp288-291)
2.1.6.4 Perancangan Basis data (Database Design)
Perancangan basis data adalah proses membuat rancangan basis data yang akan mendukung misi dan sasaran perusahaan untuk sistem basis data yang dibutuhkan. Ada dua pendekatan utama pada perancangan basis data, yaitu :
- Bottom-up approach
Pendekatan ini dimulai dari tingkat paling dasar yaitu atribut (property dari entitas dan hubungan relasional) dimana melalui analisis gabungan antara atribut-atribut, dikelompokkan ke dalam relasi-relasi yang merepresentasikan tipe-tipe entitas dan hubungan entitas. Pendekatan ini biasanya digunakan ketika akan merancang basis data yang sederhana dengan atribut dalam jumlah yang sedikit.
- Top-down approach
Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan relasional dan entitas tingkat tinggi. Pendekatan ini biasanya digunakan ketika akan merancang basis data yang kompleks dengan jumlah atribut yang banyak.
Perancangan basis data dibagi menjadi tiga tahapan utama, yaitu :
- Conceptual database design (perancangan basis data
konseptual)
Proses membangun sebuah model data dari informasi yang diperoleh dari sebuah organisasi, tetapi bebas dari semua pertimbangan fisik.
- Logical database design (perancangan basis data logikal) Proses membangun sebuah model dari informasi yang diperoleh dari sebuah organisasi berdasarkan model data khusus, tetapi bebas dari hal yang berkaitan dengan DBMS dan pertimbangan fisik lainnya.
- Physical database design (perancangan basis data fisikal)
Merupakan proses pembuatan deskripsi dari suatu implementasi basis data pada media penyimpanan (Connolly, 2005, pp291-295). Adapun beberapa hal yang dikerjakan pada tahap fisikal ini adalah :
• Menerjemahkan model data logical global untuk target DBMS
• Mendesain representasi fisikal
• Mendesain user view
• Mendesain mekanisme keamanan
• Mempertimbangkan penggunaan redudansi yang terkontrol
2.1.6.5 DBMS Selection (Pemilihan DBMS)
Menurut Connolly (2005, p295), DBMS selection (Pemilihan DBMS) adalah proses memilih DBMS yang sesuai untuk mendukung aplikasi basis data.
Jika belum terdapat DBMS, bagian daur hidup (lifecycle) yang digunakan untuk membuat sebuah seleksi adalah antara tahapan
conceptual database design dan logical database design.
Tujuan dari pemilihan DBMS adalah untuk mencukupi kebutuhan sekarang maupun kebutuhan masa yang akan datang pada perusahaan, membuat keseimbangan biaya termasuk pembelian produk aplikasi basis data, biaya yang berhubungan dengan perubahan dan pelatihan pegawai.
Tahap-tahap pemilihan DBMS :
- Menentukan istilah referensi pembelajaran
Istilah referensi untuk pemilihan DBMS yang sudah ditetapkan, penetapan objektif dan ruang lingkup pembelajaran serta tugas-tugas yang harus dilakukan. Dokumen ini juga termasuk deskripsi kriteria yang digunakan untuk mengevaluasi produk DBMS, daftar-daftar produk yang mungkin dipakai, semua batasan yang diperlukan, dan skala waktu untuk studi.
- Membuat daftar pendek dua atau tiga produk
Kriteria yang dipertimbangkan untuk menjadi kritis agar implementasi dapat berjalan lancar dan dapat digunakan untuk
membuat daftar persiapan evaluasi untuk produk DBMS. Sebagai contoh, keputusan untuk memasukkan produk DBMS mungkin tergantung pada anggaran yang tersedia, tingkat dukungan vendor, kesesuaian dengan piranti lunak lainnya, dan apakah produk dapat berjalan pada perangkat keras lainnya. Informasi-informasi tambahan lainnya dapat diperoleh dengan menghubungi pengguna yang menyediakan rincian spesifik tentang seberapa baik dukungan
vendor, bagaimana produk dapat mendukung program aplikasi tertentu, dan apakah suatu perangkat keras tertentu lebih bermasalah daripada perangkat keras yang lainnya.
- Mengevaluasi produk
Ada berbagai fitur yang dapat digunakan untuk mengevaluasi DBMS. Untuk tujuan evaluasi, fitur-fitur tersebut 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 definisi data, definisi fisik, pengaksesan, penanganan transaksi, kegunaan, pengembangan, dan fitur-fitur lainnya.
Definisi data meliputi pemberian primary key, sepesifikasi
foreign key, keberadaan tipe data, perluasan tipe data, spesifikasi
domain, Kontrol integritas, mekanisme view, kamus data, dan kebebasan data.
Definisi fisik meliputi keberadaan struktur file, pemeliharaan struktur file, pengurangan organisasi ulang, pemberian index, variable panjang field/record, kompresi data, enkripsi secara rutin, kebutuhan memori, dan kebutuhan penyimpanan.
Pengaksesan meliputi query language, compliant, interface dari 3GLs, multi-user, security (keamanan), access control (kontrol akses). Authorization mechanism (mekanisme otorisasi).
Penanganan transaksi meliputi backup dan recovery routines, strategi resolusi deadlock, kemajuan model transaksi,
parallel query processing.
Kegunaan meliputi performance measuring, tuning, fasilitas load/unload, user usage monitoring , database administration support.
Pengembangan meliputi 4GL/5GL tools, CASE tools, kemampuan windows, prosedur penyimpanan, triggers, rules, web development tools.
Fitur-fitur lainnya meliputi upgradability, stabilitas vendor,
user base, training dan user support, dokumentasi, sistem operasi, biaya, online help, penggunaan standar, scalability, mendukung untuk analytical tools, interoperability dengan DBMS dari sistem lain, integrasi jaringan, replication utilities, kemampuan distribusi,
kemampuan berorientasi objek, arsitektur, penampilan, transaction throughput, pengguna dalam jumlah maksimum, dan dukungan XML.
Langkah akhir dari pemilihan DBMS adalah mendokumentasi proses-proses yang terjadi dan menyediakan pernyataan untuk merekomendasikan prosuk DBMS yang terpilih. (Connolly, 2005, pp295-299)
2.1.6.6 Application design
Menurut Connolly (2005, p299), perancangan aplikasi (application design) adalah perancangan antarmuka pengguna dan program aplikasi yang menggunakan dan memproses basis data.
Perancangan basis data dan perancangan aplikasi adalah aktivitas yang dilakukan bersamaan dalam database application lifecycle. Dalam kasus yang sebenarnya, tidak mungkin dapat menyelesaikan perancangan aplikasi sebelum perancangan basis data selesai.
Ada dua aspek penting dalam perancangan aplikasi, yaitu : - Transaction design (Perancangan transaksi)
Transaksi merupakan satu atau serangkaian transaksi yang dilakukan oleh pengguna atau program aplikasi yang mengakses atau mengubah isi dari basis data.
Tujuan dari perancangan transaksi adalah menetapkan dan mendokumentasikan karakteristik tingkat tinggi dan transaksi yang dibutuhkan pada basis data, diantaranya :
1. Data yang digunakan dalam transaksi 2. Karakteristik fungsional dari transaksi 3. Keluaran (output) dari transaksi 4. Kepentingan pengguna
5. Nilai yang diharapkan dari pengguna
Perancangan ini dilakukan lebih awal dalam proses perancangan untuk memastikan bahwa basis data yang diimplementasikan mempu mendukung semua transaksi yang dibutuhkan.
Ada tiga jenis transaksi: a. Retrieval transaction
Digunakan untuk mendapatkan kembali data untuk ditampilkan dalam laporan.
b. Update transaction
Digunakan untuk menambah data, menghapus data lama, atau mengubah data yang sudah adal dalam basis data.
c. Mixed transaction
Merupakan kombinasi antara Retrieval transaction dan Update transaction.
- User interface design (Perancangan antarmuka)
Sebelum mengimplementasikan sebuah form atau laporan, perlu dirancang tampilannya terlebih dahulu. Ada beberapa pedoman dalam perancangan pelaporan, yaitu :
1. Pemberian judul yang berarti 2. Instruksi yang dapat dipahami
3. Pengelompokan secara logical dan pengurutan field
4. Tampilan form/report secara visual 5. Nama field yang familiar
6. Pemakaian istilah dan singkatan yang konsisten 7. Penggunaan warna secara konsisten
8. Ruang yang tersedia dan cakupan untuk field pemasukkan data 9. Perpindahan kursor yang tepat
10. Perbaikkan kesalahan untuk karakter individual maupun untuk
field secara keseluruhan
11. Pesan kesalahan untuk nilai yang tidak dapat diterima 12. Field pilihan ditandai dengan jelas
13. Pesan penjelasan untuk field
2.1.6.7 Prototyping
Menurut Connolly (2005, pp303-304), prototyping adalah membuat model kerja dari aplikasi basis data.
Model kerja memungkinkan perancang atau pengguna untuk mengevaluasi hasil akhir sistem, baik dari segi sistem maupun fungsi yang dimiliki sistem.
Tujuan utama dari pengembangan prototype aplikasi basis data adalah untuk memungkinkan pengguna memakai prototype tersebut dalam mengidentifikasi kelebihan atau kekurangan sistem, dan memungkinkan perancang untuk memperbaiki atau melengkapi fitur-fitur aplikasi basis data yang baru.
Ada dua strategi prototyping yang umum digunakan, yaitu : - Requirement prototyping
Menggunakan prototype untuk menetapkan tujuan dari aplikasi basis data dan ketika tujuan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang.
- Evolutionary prototyping
Digunakan untuk tujuan yang sama. Perbedaannya adalah
prototype yang sudah dipakai tidak dibuang, tetapi dikembangkan lebih jauh menjadi aplikasi basis data yang baru. (Connolly, 2005, pp303-304)
2.1.6.8 Implementation
Menurut Connolly (2005, p304), implementation (implementasi) adalah realisasi fisik dari basis data dan rancangan aplikasi.
Implementasi basis data dapat dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau graphical user interface (GUI). Pernyataan GUI digunakan untuk membuat struktur basis data dan file basis data kosong.
User view lainnya juga diimplementasikan dalam tahapan ini. Program aplikasi diimplementasikan dengan menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL). Bagian dari program aplikasi ini adalah transaksi basis data, dimana diimplementasikan dengan menggunakan Data Manipulation language (DML) dari DBMS sasaran, yang mungkin disimpan dalam sekumpulan bahasa pemrograman seperti visual basic, Delphi, C, C++ atau Pascal.
2.1.6.9 Data Conversion and Loading
Menurut Connolly (2005, p305), data conversion and loading
adalah memindahkan data yang sudah ada ke dalam basis data yang baru dan mengubah aplikasi yang sudah ada untuk dijalankan pada basis data yang baru.
Tahapan ini diperlukan ketika sistem basis data yang baru akan menggantikan sistem basis data yang lama. Pada masa sekarang, DBMS umumnya memiliki fungsi untuk memasukkan file ke dalam basis data
yang baru. Fungsi ini memungkinkan pengembang untuk mengkonversi dan menggunakan program aplikasi yang lama dalam sistem yang baru.
2.1.6.10 Testing
Menurut Connolly (2005, p305), testing adalah proses menjalankan program aplikasi dengan tujuan menemukan kesalahan-kesalahan yang mungkin ada pada program aplikasi tersebut.
Sebelum digunakan, aplikasi basis data yang baru dikembangkan harus diuji secara menyeluruh terlebih dahulu. Di dalam merancang basis data, pemakai yang menggunakan sistem baru seharusnya terlibat dalam proses testing. Salah satu cara menguji sistem adalah dengan menguji basis data pada perangkat keras yang berbeda. Namun, hal ini sering tidak dilakukan karena jika data asli yang digunakan, maka diperlukan back up untuk mengantisipasi kesalahan. Selelah testing selesai, aplikasi siap digunakan dan diserahkan kepada pengguna.
2.1.6.11 Operational Maintenance
Menurut Connolly (2005, p306), operational maintenance
(pemeliharaan operasional) adalah proses pemantauan dan pemeliharaan sistem setelah instalasi dilakukan.
Pada tahap sebelumnya sistem telah diimplementasikan dan diuji. Sekarang sistem memasuki tahap perawatan, yang melibatkan aktivitas sebagai berikut :
- Mengawasi kinerja dari sistem.
Jika kinerjanya mengalami penurunan di bawah level yang dapat diterima, maka basis data perlu diperbaiki.
- Memelihara dan meng-upgrade basis data (bila diperlukan)
Ketika basis data sepenuhnya bekerja, perlu dipastikan bahwa kinerjanya berada pada level yang dapat diterima oleh pengguna. Sebuah DBMS biasanya menyediakan berbagai kegunaan untuk membantu administrasi basis data termasuk kegunaan untuk melakukan pengisian data dan pemantauan sistem sehingga memungkinkan sistem pemantauan memberikan informasi tentang pemakaian basis data dan strategi eksekusi
query.
2.1.7 Tahap-tahap Perancangan Basis Data
Sebuah metodologi perancangan adalah suatu pendekatan terstruktur yang menggunakan prosedur, teknik, alat, dan bantuan dokumentasi untuk mendukung dan memfasilitasi proses perancangan (Connoly 2005, p438).
Dalam penyajian metodologi perancangan basis data, proses perancangan terbagi menjadi 3 tahap utama; konseptual, logikal, dan fisikal. (Connoly 2005, p439).
2.1.7.1 Perancangan Konseptual
Langkah 1 Membangun Model Data Konseptual
Perancangan konseptual basis data adalah proses konstruksi sebuah model dari data yang digunakan dalam perusahaan, yang tidak bergantung pada seluruh perkiraan fisikal. (Connolly 2005, p439).
Tahap perancangan basis data konseptual diawali dengan pembuatan sebuah model data konseptual perusahaan, yang secara keseluruhan tidak bergantung pada detail-detail implementasi; seperti DBMS target, program-program aplikasi, bahasa-bahasa pemrograman,
platform perangkat keras, masalah-masalah perfomansi, dan perkiraan-perkiraan fisikal lainnya.
Model data konseptual didukung oleh dokumentasi, termasuk di dalamnya diagram ER dan sebuah kamus data, yang dihasilkan melalui pengembangan dari model itu. Tahap ini memiliki langkah-langkah terperinci sebagai berikut :
Langkah 1.1 Identifikasi tipe entitas
Langkah pertama dalam pembangunan model data konseptual adalah mendefinisikan objek-objek utama yang dibutuhkan pengguna. Objek-objek ini adalah tipe-tipe entitas untuk model tersebut. Sebuah cara
dalam pengidentifikasian entitas adalah dengan memeriksa spesifikasi dari kebutuhan-kebutuhan pengguna.
Gambar 2.2. Kamus data entitas yang mendeskripsikan entitas untuk
view DreamHome(Connolly, 2005, p444)
Langkah 1.2 Identifikasi tipe relasi
Setelah entitas diidentifikasi, langkah berikutnya adalah mengidentifikasi seluruh relasi yang berada di antara entitas-entitas ini.
Gambar 2.3. Diagram potongan ER yang pertama yang menunjukkan entitas dan tipe relasi untuk Staff user views dari DreamHome (Connolly, 2005, p446)
Gambar 2.4. Kamus data relasi yang mendeskripsikan relasi untuk
view DreamHome(Connolly, 2005, p447)
Staff BusinessOwner PropertyForR ent Client Lease Preference PrivateOwner Supervisor Registers Supervisee Manages Views Holds States Associated With 0..1 1..* 0..100 0..1 0..1 0..10 1..1 0..* 0..* 0..* 0..* 0..* 1..1 1..1 1..1 1..* 0..1 1..1 POwns BOwns Supervises
Langkah 1.3 Identifikasi dan menghubungkan atribut dengan entitas atau tipe relasi
Langkah selanjutnya adalah mengidentifikasi tipe-tipe fakta tentang entitas dan relasi yang telah dipilih untuk ditunjukkan dalam basis data.
Gambar 2.5. Kamus data atribut yang mendeskripsikan atribut untuk
view DreamHome(Connolly, 2005, p450)
Langkah 1.4 Menentukan domain atribut
Sasaran dalam langkah ini adalah menentukan domain untuk seluruh atribut dalam model. Sebuah domain adalah suatu kelompok nilai dari satu atau lebih atribut yang diambil nilainya.
Langkah 1.5 Menentukan atribut-atribut candidate key, primary key, dan alternate key.
Langkah ini menitikberatkan dalam pengidentifikasian candidate key untuk sebuah entitas dan pemilihan primary key. Sebuah candidate key adalah seperangkat atribut dari suatu entitas yang secara unik mengidentifikasi setiap kemunculan dari entitas tersebut. Candidate key
dapat diidentifikasikan lebih dari satu, namun primary key harus diidentifikasikan hanya sebuah; sementara candidate key yang tersisa disebut alternate key.
Langkah 1.6 Mempertimbangkan penggunaan dari konsep enhanced modeling (bersifat opsional).
Mempertimbangkan penggunaan konsep-konsep seperti spesialisasi / generalisasi, agregasi, atau komposisi dalam melanjutkan pengembangan model ER.
Langkah 1.7 Mengecek model terhadap redundansi.
Dalam langkah ini, dilakukan pemeriksaan model data konseptual lokal dengan sasaran obyektif dari pengidentifikasian dan penghilangan terhadap keberadaan redundansi. Dua aktivitas dalam langkah ini adalah:
1. Memeriksa kembali relasi one-to-one (1:1) 2. Menghilangkan relasi yang redundan.
Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna Sasaran dari langkah ini adalah mengecek model yang sudah ada untuk memastikan model itu mendukung transaksi yang dibutuhkan. Dilakukan 2 aktivitas sebagai berikut:
1. Pendeskripsian transaksi 2. Penggunaan jalur transaksi.
Langkah 1.9 Meninjau kembali model data konseptual dengan pengguna
Sasaran dalam langkah ini adalah meninjau kembali model data konseptual terhadap pengguna untuk memastikan bahwa mereka mempertimbangkan model tersebut menjadi gambaran yang tepat dari kebutuhan data perusahaan.
Model data konseptual divalidasikan untuk memastikan bahwa model data tersebut mendukung transaksi-transaksi yang dibutuhkan. Dua kemungkinan yang muncul untuk memastikan bahwa model data konseptual mendukung hal itu adalah:
1. Pengecekan bahwa semua informasi (entitas, relasi, dan atribut) yang dibutuhkan oleh setiap transaksi disediakan oleh model dengan pendokumentasian suatu deskripsi dari setiap kebutuhan transaksi.
2. Penyajian cara dalam diagram diperoleh dari setiap transaksi secara langsung pada diagram ER.
Gambar 2.6. Contoh Diagram ER Konseptual (Connolly, 2005, p452)
2.1.7.2 Perancangan Logikal
Langkah 2 Membangun dan Memvalidasi Model Data Logikal
Perancangan logikal basis data adalah proses konstruksi sebuah model dari data yang digunakan dalam perusahaan berdasarkan pada suatu model data yang spesifik, namun tidak bergantung pada suatu DBMS tertentu dan perkiraan-perkiraan fisikal lainnya (Connoly 2005, p439). BusinessOwner ownerNo Staff staffNo PropertyForRent propertyNo Client clientNo viewDate comment Lease leaseNo PrivateOwner ownerNo BOwns Manages Views Holds States Registers AssociatedWith POwns Supervise Supervisee 0..1 0..1 1..* 1..* 1..1 0..* 0..* 1..1 1..1 1..1 0..* 0..* 1..1 Supervisor 0..1 0..10 0..100 Preference
Tahap perancangan basis data logikal memetakan model konseptual kepada suatu model logikal yang dipengaruhi oleh model data untuk target basis data (misalnya, model relasi). Model data logikal adalah suatu sumber informasi untuk tahap perancangan fisikal, menyediakan perancang fisikal basis data dengan sebuah perangkat untuk pembuatan
tradeoff yang sangat penting untuk rancangan basis data yang efisien. Sebuah model data logikal memiliki diagram ER, skema relasi, dan mendukung dokumentasi seperti kamus data, yang dihasilkan pada keseluruhan pengembangan model.
Pada tahap ini, sasaran utamanya adalah meterjemahkan model data konseptual yang dibuat pada tahap pertama menjadi sebuah model data logikal dari kebutuhan data pada perusahaan. Sasaran ini tercapai melalui aktivitas-aktivitas terperinci yang tertera sebagai berikut:
Langkah 2.1 Membangun Memperoleh relasi-relasi untuk model data logikal.
Sasaran dari langkah ini adalah membuat relasi untuk model data logikal untuk menggambarkan entitas, relasi, dan atribut yang telah diidentifikasi. Komposisi dari setiap relasi dideskripsikan dengan menggunakan Database Definition Language (DBDL) untuk basis data relasional.
Langkah 2.2 Validasi relasi dengan normalisasi
Normalisasi adalah suatu teknik dalam memproduksi seperangkat relasi dengan sifat-sifat yang diinginkan, memberikan data yang dibutuhkan dari suatu perusahaan (Connoly 2005, pp388).
Aturan Normalisasi:
• Unnormalized Form (UNF)
Pada bentuk tidak normal (unnormalized form—UNF), tabel masih mengandung satu atau lebih kelompok pengulangan
(repeating groups). Tabel UNF ini dibuat dengan
mentransformasi data dari sumber informasi ke dalam tabel berbentuk baris dan kolom.
• First Normal Form (1NF)
Pada bentuk normal pertama (first normal form—1NF), suatu relasi di mana pada setiap sel (perpotongan dari baris dan kolom) memuat satu dan hanya satu nilai, setiap sel mengandung nilai atomic (atau single value).
• Second Normal Form (2NF)
Pada bentuk normal kedua (second normal form—2NF), suatu relasi telah melalui bentuk normal pertama dan setiap atribut bukan primary key (PK) tergantung fungsional penuh terhadap PK.
• Third Normal Form (3NF)
Pada bentuk normal ketiga (third normal form—3NF), suatu relasi telah melalui bentuk normal pertama dan kedua, serta tidak ada atribut bukan PK tergantung fungsional terhadap atribut bukan PK yang lain.
Langkah 2.3 relasi terhadap transaksi pengguna
Sasaran dalam langkah ini adalah memvalidasi model data logikal untuk memastikan bahwa model tersebut mendukung transaksi yang dibutuhkan, dengan detail pada spesifikasi kebutuhan pengguna.
Langkah 2.4 Memeriksa batasan integritas
Batasan integritas adalah batasan yang ditentukan dengan tujuan untuk melindungi basis data menjadi tidak lengkap, tidak akurat, atau tidak konsisten. Batasan-batasan tersebut meliputi required data, attribute domain constraint, entity integrity, referential integrity, serta enterprise constraint.
Langkah 2.5 Meninjau kembali model data logikal dengan pengguna Sasaran dalam langkah ini adalah meninjau kembali model data logikal dengan pengguna untuk memastikan bahwa mereka mempertimbangkan model tersebut untuk menjadi gambaran yang benar dari kebutuhan data perusahaan.
Langkah 2.6 Menggabungkan model data logikal ke dalam model global
Langkah ini hanya diperlukan untuk perancangan dari suatu basis data dengan banyak pandangan pengguna yang telah diatur dengan pendekatan integrasi pandangan. Untuk memfasilitasi deskripsi dari proses penggabungan, digunakan persyaratan model data logikal lokal dan model data logikal global. Sebuah model data logikal lokal menggambarkan satu atau lebih namun tidak seluruh pandangan pengguna dari suatu basis data sementara model data logikal global menggambarkan keseluruhan pandangan pengguna dari basis data.
Langkah 2.7 Memeriksa pertumbuhan masa depan
Sasaran dari langkah ini adalah menentukan apakah ada perubahan-perubahan signifikan dalam perkiraan masa depan dan mengakses apakah model data logikal dapat mengakomodasi perubahan-perubahan ini. Perancangan basis data logikal menyimpulkan dengan pertimbangan apakah model data logikal mampu diperluas untuk mendukung perkembangan masa yang akan datang.
Pada tahap ini, normalisasi dilakukan untuk mengidentifikasi seperangkat relasi yang sesuai, yang mendukung kebutuhan data dalam perusahaan. Sifat-sifat dari relasi yang sesuai tersebut adalah sebagai berikut:
• Jumlah atribut yang diminimalkan diperlukan untuk mendukung kebutuhan data perusahaan
• Atribut dengan sebuah relasi yang mendekati logikal ditemukan pada relasi yang sama
• Redundansi yang minimal dengan setiap atribut digambarkan hanya sekali dengan pengecualian atribut yang merupakan seluruh atau sebagian foreign key, yang mana esensial untuk penggabungan relasi yang terkait.
Gambar 2.7. Contoh Diagram ER Logikal (Connolly, 2005, p489) Manager staffNo {PK, FK} Staff staffNo {PK} supervisorStaffNo{FK} branchNo {FK} Branch branchNo {PK} mgrStaffNo {FK} Telephone telNo {PK} branchNo {FK} Registration clientNo {PK, FK} branchNo {FK} staffNo {FK} Client clientNo {PK} Lease leaseNo {PK} clientNo {FK} propertyNo {FK} clientNo {PK, FK} propertyNo {PK, FK} Viewing leaseNo {PK} clientNo {FK} propertyNo {FK} PropertyForRent PrivateOwner ownerNo {PK} BusinessOwner ownerNo {PK} Advert propertyNo {PK, FK} newspaperName {PK, FK} dateAdvert {PK} Newspaper newspaperName {PK} 1.. 1 0.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 1.. 1 0.. 1 0.. 1 0.. 1 1.. 3 0.. 10 1.. 1 0.. * 1.. * 1.. 1 1.. 1 1.. * 0.. * 1.. * 0.. * 1.. * 1.. * 0.. * 0.. * 0.. * Manages Provides Registers Requests Takes Supervises Processes Agrees Holds LeasedBy Placedln Displays BOwns POwns Is a Has Offers 0.. 100 0.. 1 Oversees
2.1.7.3 Perancangan Fisikal
Perancangan fisikal basis data adalah proses produksi sebuah deskripsi implementasi dari basis data pada tempat penyimpanan kedua; menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data, dan batasan integritas yang diasosiasikan dan ukuran keamanan. (Connolly, 2005, p439)
Rancangan dari relasi dasar dapat dikerjakan hanya jika perancang benar-benar mengetahui fasilitas-fasilitas yang ditawarkan dengan DBMS target.
Metodologi perancangan fisikal basis data memiliki langkah-langkah sebagai berikut :
Langkah 3 Menterjemahkan model data logikal terhadap DBMS yang telah ditentukan
Secara umum langkah ini memiliki sasaran untuk menghasilkan suatu skema basis data relasional dari model data logikal yang dapat diimplementasikan dalam DBMS target.
Langkah 3.1 Mendesain relasi dasar
Sasaran dari langkah ini adalah menetukan bagaimana menggambarkan relasi dasar diidentifikasikan pada model data logikal dalam DBMS target. Pada awal langkah ini, informasi tentang relasi yang dihasilkan selama perancangan basis data logikal disusun dan diolah.
Informasi penting dapat diambil dari kamus data dan definisi dari relasi dapat dideskripsikan dengan Database Design Language (DBDL). Untuk setiap informasi yang diidentifikasi dalam model data logikal, sebuah definisi terdiri dari:
• Nama relasi
• Daftar atribut-atribut sederhana dalam kelompok
• Primary key yang tepat, alternate key, dan foreign key
• Batasan integritas referensial untuk setiap foreign key yang diidentifikasi
Langkah 3.2 Mendesain representasi dari data yang diperoleh.
Sasaran dari langkah ini adalah menentukan bagaimana menggambarkan data yang diperoleh pada model data logikal dalam DBMS target.
Atribut yang nilainya dapat ditemukan dengan pemeriksaan nilai dari atribut lain dikenal sebagai atribut yang diperoleh atau diperhitungkan.
Langkah 3.3 Mendesain batasan umum
Sasaran dari langkah ini adalah merancang batasan umum untuk DBMS target.
Dalam langkah ini, dirancang sejumlah batasan umum: data yang dibutuhkan, batasan domain, entitas dan integritas referensial.
Langkah 4 Mendesain organisasi file dan indeks
Secara umum memiliki sasaran menentukan organisasi file optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima
Langkah 4.1 Menganalisis transaksi
Sasaran dari langkah ini adalah memahami fungsionalitas dari transaksi yang akan dijalankan pada basis data dan menganalisis transaksi-transaksi penting
Dalam langkah ini dilakukan aktivitas-aktivitas berikut:
1. Memetakan seluruh jalur transaksi pada relasi
2. Menentukan relasi mana yang paling sering diakses oleh transaksi
3. Menganalisis penggunaan data dari transaksi yang dipilih yang mempengaruhi relasi ini.
Langkah 4.2 Memilih organisasi file
Salah satu sasaran utama dari perancangan basis data fisikal adalah menyimpan dan mengakses data dengan cara yang efisien.
Sasaran dalam langkah ini adalah memilih sebuah organisasi file
optimal untuk setiap relasi, jika DBMS target memperbolehkan itu. Dalam banyak kasus, sebuah DBMS relasional dapat memberi sedikit atau tak ada sama sekali pilihan dalam pemilihan organisasi file, kendati beberapa dapat ditetapkan sebagai indeks yang dispesifikasikan.
Langkah 4.3 Memilih indeks
Sasaran dari langkah ini adalah menentukan apakah penambahan indeks akan meningkatkan perfomansi dari sistem.
Sebuah pendekatan dalam pemilihan organisasi file yang tepat untuk suatu relasi adalah dengan menjaga tuple yang tidak diinginkan dan membuat banyak indeks secondary sesuai kebutuhan.
Langkah 4.4 Mengestimasi kebutuhan kapasitas disk
Sasaran utama dari langkah ini adalah memperkirakan jumlah disk space yang akan dibutuhkan untuk mendukung implementasi basis data pada secondary storage.
Secara umum, perkiraan didasarkan pada ukuran dari setiap tuple
Langkah 5 Mendesain user views
Secara umum memiliki sasaran merancang user views yang telah diidentifikasikan pada tahap pengumpulan kebutuhan dan analisis pada daur hidup pengembangan basis data.
Langkah 6 Mendesain mekanisme keamanan
Secara umum memiliki sasaran merancang mekanisme pengamanan untuk basis data yang ditetapkan oleh pengguna selama tahap kebutuhan dan pengumpulan dari daur hidup pengembangan basis data.
Langkah 7 Mempertimbangkan penggunaan redundansi terkontrol Menentukan apakah penggunaan redundansi secara terkontrol akan dapat meningkatkan performansi sistem.
Langkah 8 Memonitor dan memasang sistem operasional
Mengawasi sistem operasional dan meningkatkan performansi sistem untuk memperbaiki rancangan-rancangan yang kurang sesuai atau sebagai refleksi adanya perubahan kebutuhan.
Tahap perancangan basis data fisikal mendukung perancang dalam pembuatan keputusan mengenai bagaimana basis data akan diimplementasikan. Oleh karena itu, rancangan fisikal disesuaikan pada DBMS yang spesifik. Ada umpan balik antara rancangan fisikal dan
logikal, karena keputusan yang diambil selama rancangan fisikal untuk peningkatan performansi dapat mempengaruhi model data logikal.
2.1.8 E-R Modelling
Salah satu aspek yang paling sulit pada perancangan basis data adalah fakta bahwa perancang, programmer, dan pengguna akhir memandang data dan kegunaan dari data tersebut dari sudut pandang yang berbeda. Namun, sebelum mendapatkan pemahaman umum mengenai bagaiman cara perusahaan beroperasi, rancangan yang dihasilkan akan gagal untuk memenuhi kebutuhan pengguna. Untuk mendapatkan pemahaman yang tepat mengenai data dan bagaimana data itu digunakan dalam perusahaan, maka diperlukan sebuah model komunikasi yang non -teknikal dan tidak ambigu. Model entity-relationship adalah salah satu contohnya.
Model entity-relationship merupakan salah satu model yang dapat memastikan pemahaman yang tepat terhadap data dan bagaimana penggunaannya di dalam suatu organisasi. Model ini dimulai dengan identifikasi entitas dan hubungan antar data yang harus direpresentasikan di dalam model, kemudian ditambahkan atribut dan setiap constraint pada entitas, relasi, dan atributnya. (Connoly, 2005, p342)
2.1.8.1 Tipe Entiti
Tipe entitas adalah sekumpulan objek dengan properti yang sama, yang didefinisikan oleh perusahaan dan keberadaannya tidak tergantung.
Konsep dasar dari Entity Relationship model adalah tipe entitas yang merepresentasikan kumpulan objek pada dunia nyata dengan sifat yang sama. Sebuah tipe entitas memiliki keberadaan yang bebas dan bisa menjadi objek dengan keberadaan fisik (entitas pegawai, rumah, dan pelanggan) atau menjadi objek dengan keberadaan konseptual (entitas inspeksi, penjualan, dan pembelian). Perancang yang berbeda mungkin akan mengidentifikasi entitas yang berbeda.
Gambar 2.8. Entity-Relationship (ER) Diagram dari Branch view DreamHome(Connolly, 2005, p344)
Sekelompok entitas yang sejenis dan berada dalam ruang lingkup yang sama akan membentuk sebuah himpunan entitas (entity
occurence). Entity occurance adalah objek atau tipe entitas yang dapat diidentifikasi secara unik.
Gambar 2.9. Representasi diagram dari tipe entitas staff dan branch (Connolly, 2005, p345)
Tipe entitas dapat diklasifikasikan menjadi:
• Tipe entitas kuat, yaitu tipe entitas yang keberadaannya tidak bergantung pada tipe entitas lainnya. Karakteristiknya adalah setiap kejadian entitasnya secara unik mampu diidentifikasikan dengan menggunakan atribut primary key pada entitasnya.
• Tipe entitas lemah, yaitu Tipe entitas yang keberadaannya bergantung pada tipe entitas lainnya. Karakteristiknya adalah setiap kejadian entitasnya tidak bias diidentifikasikan secara unik hanya dengan menggunakan atribut yang bergantung pada entitasnya.
2.1.8.2 Tipe Relasi
Tipe relasiadalah gabungan yang mempunyai arti diantara tipe-tipe entitas. Setiap tipe relationship diberikan nama sesuai dengan fungsinya.
Relationship Occurance adalah suatu gabungan yang dapat diidentifikasi secara unik, meliputi suatu kejadian dari dari setiap tipe entitas yang berpartisipasi.
Gambar 2.10. Jaringan semantik yang menunjukkan hubungan individual dari tipe relasi Has(Connolly, 2005, p346)
Gambar 2.11. Representasi diagram tipe relasi Branch has Staff (Connolly, 2005, p347 )
Biasanya sebuah relationship dinamakan dengan menggunakan kata kerja, seperti Membeli, atau dengan frase singkat yang meliputi kata kerja, seperti Dibelioleh. Tanda panah diletakkan di samping nama relationship
yang mengidentifikasikan arah bagi pembaca untuk mengartikan nama dari suatu relationship. Kumpulan semua relasi di antara entitas-entitas yang terdapat pada himpunan entitas membentuk himpunan relasi.
• Derajat dari Tipe Relationship
Derajat dari tipe relationship adalah jumlah tipe entitas yang ikut serta dalam sebuah relationship. Entitas yang berkaitan dalam suatu relationship dikenal sebagai participant dalam relationship dan jumlah participant dalam relationship disebut sebagai derajat dari
relationship.
Complex relationship types adalah jumlah tipe entitas yang ikut serta dalam sebuah relationship (Connolly, 2005, p445).
Derajat dari tipe relationship dibagi menjadi tiga, yaitu :
• binary
Gambar 2.12. Contoh suatu relasi binary yang disebut POwn (Connolly, 2005, p348)
• ternary
relationship yang memiliki derajat tiga
Gambar 2.13. Contoh suatu relasi ternary yang disebut Registers (Connolly, 2005, p348)
• quartenary
relationship yang memiliki derajat empat
Gambar 2.14. Contoh suatu relasi quarternary yang disebut
Arranged (Connolly, 2005, p349)
• Recursive Relationship
Recursive Relationship adalah sebuah tipe relationship dimana tipe entitas yang sama ikut serta lebih dari sekali dengan peran yang berbeda. (Connolly, 2005, p337). Relationship dapat diberikan nama peran untuk menentukan fungsi dari setiap entitas yang terlibat dalam relationship tersebut. Nama peran juga dapat diberikan jika dua buah entitas dihubungkan melalui lebih dari satu relationship.
Gambar 2.15. Contoh suatu relasi rekursive yang disebut Supervised (Connolly, 2005, p349)
2.1.8.3 Atribut
Atribut adalah sifat dari sebuah entitas atau sebuah tipe relationship. Atribut menampung nilai yang menjelaskan setiap entity occurance dan menggambarkan bagian utama dari data yang disimpan dalam basis data.
Atribut domain adalah sekumpulan nilai yang diperbolehkan bagi satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai yang dimiliki sebuah atributdan sama dengan konsep domain pada model relasional. Atribut dapat diklasifikasikan menjadi:
• Simple attribute
Atribut yang terdiri dari komponen tunggal dimana komponen tersebut tidak dapat dipisahkan lagi. Simple attribute kadang disebut juga dengan atomic attributes.
• Composite attribute
Atribut yang terdiri dari beberapa komponen, dan keberadaan setiap komponen bebas. Beberapa atribut dapat dipisahkan menjadi komponen yang lebih kecil dengan keberadaan yang bebas.
• Single-valued attribute
Atribut yang memiliki nilai tunggal untuk masing-masing kejadian dari entitas. Kebanyakan/mayoritas dari atribut merupakan Single-valued attribute.
• Multi-valued attribute
Atribut yang memiliki banyak nilai untuk masing-masing kejadian dari entitas. Beberapa atribut memiliki nilai untuk setiap entity occurance. Multi-valued attribute dapat memiliki jumlah dengan batas atas maupun dengan batas bawah.
• Derived attribute
Atribut yang nilai-nilainya diperoleh atau diturunkan dari atribut lain yang berhubungan. Dalam beberapa kasus, nilai dari sebuah atribut diturunkan terhadap entity occurance dari tipe entitas yang sama. Derived attribute juga mungkin berhubungan dengan kumpulan atribut dari tipe-tipe entitas yang berbeda.
2.1.8.4 Kunci (Key)
Candidate key adalah kunci yang secara unik mengenali setiap kejadian di dalam tipe entitas. Sebuah candidate key tidak boleh NULL. Sebuah entitas boleh memiliki lebih dari satu candidate key. Composite key adalah sebuah candidate key yang memiliki dua atau lebih atribut.
Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik sebuah occurance dari setiap entitas. Biasanya terdapat lebih dari satu candidate key yang harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut, jumlah minimal atribut yang dibutuhkan, dan memenuhi syarat unik. Candidate key yang tidak terpilih menjadi primary key dinamakan
alternate key.
Foreign key adalah sebuah primary key pada sebuah entitas yang digunakan pada entitas lain untuk mengidentifikasi sebuah relationship.
Gambar 2.16. ERD dari etitas dan atribut Staff dan Branch (Connolly, 2005, p354)
2.1.8.5 Structural Constraints
Batasan-batasan yang menggambarkan pembatasan pada
relationship seperti yang ada pada real world harus diterapkan pada tipe entitas yang ikut serta dalam sebuah relationship. Tipe utama dari batasan hubungan di dalam suatu relationship disebut multiplicity (Connolly, 2005, p356).
Multiplicity adalah jumlah occurance yang mungkin terjadi pada sebuah tipe entitas yang berhubungan ke sebuah occurance dari sebuah tipe entitas lain dari suatu relationship.
Derajat yang biasa digunakan dalam suatu relationship adalah binary relationship, yang terdiri atas :
• Hubungan one to one (1 : 1)
Setiap relationship menggambarkan hubungan antara sebuah
entity occurance pada entitas yang satu dengan entity occurance
pada entitas lainnya yang ikut serta dalam relationship tersebut. Hubungan 1: 1 dapat terjadi bila setiap entitas pada himpunan entitas A berhubungan paling banyak satu entitas dengan satu entitas pada himpunan entitas B. Dan sebaliknya, setiap entitas pada himpunan entitas B berhubungan paling banyak satu entitas dengan satu entitas pada himpunan entitas A.
Gambar 2.17. Jaringan semantik pada Staff manage Branch dengan tipe relasi 1:1 (Connolly, 2005, p357)
Gambar 2.18. Multiplicity pada Staff manages Branch dengan tipe relasi 1:1 (Connolly, 2005, p358)
• Hubungan one to many (1 : *)
Setiap relationship menggambarkan hubungan antara sebuah
entity occurance pada entitas yang satu dengan satu atau lebih
entity occurance pada entitas lainnya yang ikut serta dalam relationship tersebut. Berarti setiap entitas pada pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B. Namun, setiap entitas pada himpunan entitas B hanya dapat berhubungan dengan paling banyak satu entitas pada himpunan entitas A.
Gambar 2.19. Jaringan semantik pada Staff overseas PropertyForRent
Gambar 2.20. Multiplicity pada Staff overseas PropertyForRent
dengan tipe relasi 1:* (Connolly, 2005, p359)
• Hubungan many to many (* : *)
Setiap relationship menggambarkan hubungan antara satu atau lebih entity occurance pada entitas yang satu dengan satu atau lebih entity occurance pada entitas lainnya yang ikut serta dalam relationship tersebut. Berarti setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, dan sebaliknya, setiap entitas pada himpunan entitas B dapat berhubungan dengan banyak entitas pada himpunan entitas A.
Gambar 2.21. jaringan semantik pada Newspaper advertises PropertyForRent dengan tipe relasi *:* (Connolly, 2005, p360)
Gambar 2.22. Multiplicity pada Newspapaper advertise PropertyForRent dengan tipe relasi 1:* (Connolly, 2005, p360)
2.1.9 State Transition Diagram
State Transition Diagram (STD) adalah suatu tools permodelan yang menggambarkan sifat ketergantungan pada suatu waktu dari suatu sistem. Adapun simbol yang digunakan adalah :
state / keadaan
perubahan state / keadaan
Untuk melengkapi suatu STD diperlukan dua hal lagi , yaitu
condition (kondisi), merupakan sebuah sinyal yang menyebabkan perubahan terhadap state dari suatu state satu ke state yang berikutnya dan
action (aksi), adalah yang hal dilakukan sistem bila terjadi perubahan
state atau merupakan suatu reaksi terhadap kondisi.
2.1.10 Perancangan User Interface
Interaksi manusia dengan komputer adalah suatu ilmu yang berhubungan dengan perancangan, evaluasi, serta implementasi sistem komputer interaktif yang akan digunakan oleh manusia. Dalam merancang antarmuka pemakai ( user interface ) perlu menggunkan delapan aturan emas ( 8 goldenrule ) yang terdiri atas :
Aplikasi yang dirancang harus konsisten, baik dalam tampilan, susunan menu, teks ataupun pewarnaan.
Memungkinkan frequentuser menggunakan shortcut.
Aplikasi yang dirancang sebaiknya mempunyai fasilitas shortcut (jalan singkat) bagi user untuk lebih leluasa menjelajahi aplikasi.
Memberikan umpan balik (feedback) yang informatif.
Sebuah aplikasi harus dapat memberikan pelayan navigasi ataupun informasi mengenai tujuan dari sebuah link, sehingga dapat mengurangi kesalahan yang mungkin dilakukan oleh user.
Merancang dialog untuk menghasilkan keadaan akhir.
Aksi – aksi yang ada seharusnya diorganisasikan dengan baik untuk mempunyai suatu awal, pertengahan, dan tahap akhir, seperti sebuah cerita pendek yang bagus. Dengan adanya umpan balik yang informatif pada tahap akhir, suatu form akan memberitahukan user
sehingga mereka dapat mengetahui kapan mereka dapat berpindah ke
form berikutnya.
Memberikan pencegahan kesalahan dan penanganan kesalahan yang sederhana.
Jika terjadi suatu kesalahan, maka aplikasi mampu memberikan petunjuk sederhana yang praktis dalam menanganinya. Misalnya disediakannya fasilitas help menu.
Aplikasi harus menyediakan fasilitas bagi user untuk kembali ke menu sebelumnya dengan mudah.
Mendukung internal focusofcontrol.
Memberikan user hak untuk memutuskan apa yang diperlukan dan kemudian sistem menyediakan informasi yang dibutuhkan.
Mengurangi beban ingatan jangka panjang.
Aplikasi harus memudahkan user dalam mengingat hal – hal penting. Misalnya saja dengan mengkombinasikan kode – kode, maka kode tersebut diusahakan mudah diingat dengan kemampuan berpikir manusia,yaitu dengan cara kode jangan terlalu panjang.
2.2 Pendekatan Web Database
Web database berasal dari 2 kata, yaitu web dan database. Web
(disebut juga world wide web, www atau W3) adalah ruang informasi di internet tempat dokumen dokumen hypermedia disimpan dan dapat diambil melalui suatu skema alamat yang unik. (McLeod, 2001, jilid 1,p75). Sedangkan database, seperti yang telah dijelaskan pada 2.2 diatas adalah kumpulan data yang saling terkait secara logikal.
Menurut Eaglestone (2001, p31), web database adalah suatu sistem yang membawa kemampuan dari database teknologi database dan web. Web database system dilihat dari 2 sudut pandang : bagaimana menggunakan DBMS dalam mengelola dan meningkatkan performa aplikasi web dan bagaimana koneksi ke web bisa mengelola database system.
Web aplikasi adalah web yang secara umum mempertimbangkan mekanisme dalam menyimpan dan menyediakan akses ke dokumen.
Internet dan web dapat memperluas kemampuan database system
dalam 2 bagian :
1. Akses yang luas : dengan menyambungkan sistem ke internet, maka populasi user dapat bertambah.
2. Banyak pelayanan : Internet dapat mehubungkan dan menggabungkan
database system yang berbeda untuk menyediakan layanan baru.
Jadi, web database adalah suatu sistem baru yang menggabungkan kemampuan dari database ke dalam web.
