BAB 2 LANDASAN TEORI
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
8
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
9
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
10
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).
11
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 : Database Planning
System Definition
Requirement collection and analysis Database design Conceptual Database Design DBMS selection (optional)
Application design Logical Database Design
Physical Database Design
Prototyping (optional)
Implementation
Data conversion and loading
testing
Operational maintance
Gambar 2.1. Tahapan database application lifecycle (Connolly, 2005, p284)
12
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
13
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
14
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. Teknikteknik yang digunakan antara lain: mempelajari dokumen, wawancara, pengamatan terhadap kegiatan perusahaan, penelitian, dan kuisioner.
15
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 :
16
-
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.
17
-
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
•
Mengawasi dan mengurus sistem operasional
18
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
19
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.
20
Definisi pemeliharaan
fisik
meliputi
struktur
file,
keberadaan
pengurangan
struktur
file,
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 fasilitas
meliputi
load/unload,
user
performance usage
measuring,
monitoring
,
tuning, 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, portability, kebutuhan perangkat keras, dukungan jaringan,
21
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.
22
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 perancangan
ini
untuk
diimplementasikan
dilakukan
memastikan
mempu
lebih
awal
bahwa
mendukung
dalam
basis
semua
data
transaksi
proses yang 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.
23
-
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 14. Penanda akhir
24
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)
25
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
26
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 kesalahankesalahan 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
pemeliharaan sistem setelah instalasi dilakukan.
pemantauan
dan
27
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).
28
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 perkiraanperkiraan 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
29
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.
30
Supervises 0..1 Supervisor 0..10 BusinessOwner Supervisee
1..1
Staff
0..1
Registers
0..1 Manages
BOwns
0..*
0..100 1..* 1..*
PropertyForR ent
0..*
0..* 1..1
1..1 Associated With
POwns
Client
Views
Holds
1..1 States
0..1 0..* PrivateOwner
0..*
Lease
1..1 Preference
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)
31
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.
32
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.
33
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.
34
2.
Penyajian cara dalam diagram diperoleh dari setiap transaksi secara langsung pada diagram ER.
Supervisee 0..1 Supervisor 0..10
BusinessOwner ownerNo
Registers
Staff
Supervise
1..1
staffNo
0..1 Manages
BOwns
0..100
1..*
Views
PropertyForRent 1..*
0..* Client 0..*
propertyNo 1..1
clientNo
1..1
AssociatedWith
Holds
viewDate comment
POwns 0..1 PrivateOwner ownerNo
1..1 States
1..1 0..*
Lease
0..*
Preference
leaseNo
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).
35
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.
36
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.
37
•
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.
38
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 perubahanperubahan 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:
39
•
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.
40
1.. 1
Manager
Manages
staffNo {PK, FK}
Is a Supervises 0.. 1 0.. 10
0.. 1
Telephone
0.. 1
telNo {PK} branchNo {FK}
1.. 1
1.. 1 Has
Staff
1.. 1
1.. 3 Provides
Branch
staffNo {PK} supervisorStaffNo{FK} branchNo {FK}
branchNo {PK} mgrStaffNo {FK}
1.. 1
1.. 1
1.. 1 Registration
Processes
0.. * clientNo {PK, FK}
Registers 1.. *
branchNo {FK} staffNo {FK}
1.. 1 Oversees
Agrees 1.. 1 Holds
Requests
Client 0.. *
1.. 1
clientNo {PK}
1.. 1 0.. *
Lease
Viewing
leaseNo {PK} clientNo {FK} propertyNo {FK}
0.. *
Offers
clientNo {PK, FK} propertyNo {PK, FK}
1.. 1
1.. 1
Takes
0.. *
PropertyForRent
LeasedBy 0.. 100
1.. * Placedln
leaseNo {PK} clientNo {FK} propertyNo {FK}
1.. 1
1.. * POwns
0.. 1
PrivateOwner ownerNo {PK}
1.. * BOwns
Advert
0.. * propertyNo {PK, FK} newspaperName {PK, FK} dateAdvert {PK}
0.. 1
BusinessOwner
1.. * Displays
1.. 1
ownerNo {PK}
Newspaper newspaperName {PK}
Gambar 2.7. Contoh Diagram ER Logikal (Connolly, 2005, p489)
41
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 langkahlangkah 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.
42
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.
43
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.
44
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 dan jumlah tuple dalam relasi.
45
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
46
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 nonteknikal 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)
47
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.
48
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
49
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.
50
2.1.8.2 Tipe Relasi Tipe relasi adalah 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 )
51
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 relationship yang memiliki derajat dua
52
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)
53
• 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.
54
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.
55
•
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.
56
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.
57
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 :
58
•
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)
59
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 dengan tipe relasi 1:* (Connolly, 2005, p358)
60
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.
61
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
62
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 golden rule ) yang terdiri atas : Berusaha konsisten.
63
Aplikasi yang dirancang harus konsisten, baik dalam tampilan, susunan menu, teks ataupun pewarnaan.
Memungkinkan frequent user 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.
Memungkinkan pembalikan aksi ( undo yang mudah ).
64
Aplikasi harus menyediakan fasilitas bagi user untuk kembali ke menu sebelumnya dengan mudah.
Mendukung internal focus of control. 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.
65
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.
