BAB 2 LANDASAN TEORI
2.1
Teori-Teori Umum Dalam penyusunan skripsi ini ada beberapa teori umum yang digunakan sebagai
landasan. Di bawah ini adalah pemaparan teori-teori tersebut.
2.1.1
Teori-Teori Database 2.1.1.1 Basis Data Menurut Connolly (2010, p65), basis data adalah suatu koleksi bersama data-data yang saling terkait secara logis, dan juga merupakan pendeskripsian dari data-data tersebut, yang dirancang untuk menyajikan informasi yang dibutuhkan oleh sebuah organisasi. Database juga dapat diartikan sebagai serangkaian program komputer yang mengendalikan pembuatan, pemeliharaan, dan pemanfaatan basis data sebagai sebuah organisasi (O’Brien, 2003, p5). Dalam basis data, terdapat tiga istilah penting, yakni entitas, atribut, dan relationship. Entitas adalah sebuah objek berbeda (bisa seseorang, tempat, sesuatu,
konsep,
ataupun
kejadian)
dalam
organisasi
yang
harus
direpresentasikan dalam basis data. Atribut adalah sebuah properti yang mendeskripsikan beberapa aspek dari objek yang ingin di-record. Relationship adalah asosiasi antar entitas (Connolly, 2010, p65).
8
2.1.1.2 Konsep Model ERD • Relationship Relationship adalah Kumpulan keterhubungan yang mempunyai arti (meaningful
associations)
antara
type
entitas
yang
ada
(Connolly,2010,p374).
Gambar 2. 1 Relationship Branch has Staff (Connolly, Database Systems, p375)
• Structural Constraints Batasan utama pada relationship disebut multiplicity, yaitu jumlah (atau range) darikejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitaslain yang berhubungan melalui suatu relationship. Relationship yang paling umum adalah binary relationship. Macam-macam binary relationship yaitu :
– one-to-one (1:1)
Gambar 2. 2 ER Diagram of Staff and Branch Entities and general constraint (Connolly, Database Systems, p382)
– one-to-many(1:*)
Gambar 2. 3 ER Diagram of Staff and PropertyForRent Entities and general constraint (Connolly, Database Systems, p388)
– many-to-many(*:*)
Gambar 2. 4 ER Diagram of Staff and PropertyForRent Entities and general constraint (Connolly, Database Systems, p389) • Attributes Menurut Connolly(2010,p379) attributes merupakan sifat-sifat (property) dari sebuah entitas atau tipe relationship. Attribute Domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebihatribut. Macammacam atribut : •
Simple Attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengankeberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecillagi. Dikenal juga dengan nama Atomic Attribute.
•
Composite Attribute, yaitu atribut yang terdiri dari beberapa komponen,
dimana
masing-masing
komponen
memiliki
keberadaan yang independen. Misalkan atributAddress dapat terdiri dari Street, City, PostCode.
•
Single-valued Attribute, yaitu atribut yang mempunyai nilai tunggal untuk setiapkejadian. Misalnya entitas Branch memiliki satu nilai untuk atribut branchNo padasetiap kejadian.
•
Multi-valued Attribute, yaitu atribut yang mempunyai beberapa nilai untuk setiapkejadian. Misal entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiapkejadian.
•
Derived Attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu ataubeberapa atribut lainnya dan tidak harus berasal dari satu entitas.
• Keys –
Candidate Key, yaitu jumlah minimal atribut-atribut yang dapat meng-identifikasikan setiap kejadian/record secara unik.
–
Primary
Key,
yaitu
Candidate
key
yang
dipilih
untuk
mengidentifikasikan setiapkejadian/record dari suatu entitas secara unik. –
Composite Key, yaitu Candidate key yang terdiri dari dua atau lebih atribut.
Gambar 2. 5ER Diagram of Staff and Branch Entities and their Attributes (Connolly, Database Systems, p382)
2.1.1.3 Normalisasi Menurut Connolly (2010, p416) tujuan utama dalam pengembangan model data logical pada sistem basis relasionaladalah untuk menciptakan representasi akurat suatu data, keterhubungannya dan batasan-batasannya.Untuk mencapai tujuan ini, maka harus ditetapkan/diidentifikasi sekumpulan relasi. Empat bentuk normal yang biasa digunakan yaitu, first normal form (1NF), second normalform (2NF) dan third normal form (3NF) dan Boyce–Codd normal form (BCNF).Terdapat bentuk fourth normal form (4NF) dan fifth normal form (5NF) untuk situasi yangjarang terjadi. Berdasarkan pada functional dependencies antar atribut dalam relasi. Sebuah relasi dapat dinormalisasi kedalam bentuk tertentu untuk mengatasi kemungkinanterjadinya pengulangan dari update yang tidak baik.Normalisasi adalah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifatsifat(properties) yang diinginkan, memenuhi kebutuhan data pada enterprise. 1. Data Redundacy
Menurut Connolly (2010, p418) tujuan utama dari desain basis data relasional adalah untuk mengelompokkan atribut-atribut ke dalam relasirelasi sehingga meminimalisasi redundansi data dan mengurangi penggunaan tempat penyimpanan yang dibutuhkan oleh sebuah relasi dasar.Masalahmasalah yang terkait dengan redundansi dapat dijelaskan dengan membandingkanrelasi Staff dan Branch dengan relasi StaffBranch.Relasi StaffBranch memiliki data redundan, yaitu detail dari branch dituliskan berulang-ulanguntuk setiap staff.Sebaliknya, informasi mengenai branch muncul hanya satu kali pada relasi Branch danhanya branchNo saja yang diulang dalam relasi Staff, untuk merepresentasikan dimana setiap staff tersebut bekerja.
Gambar 2. 6 Contoh Data Redundancy (Connolly, Database Systems, p419) 2. Update Anomalies Menurut Connolly (2010, p419) relasi yang mengandung informasi yang redundan dapat diakibatkan oleh update anomalies. Beberapa tipe dari update anomalies, diantaranya Insertion, Deletion, dan Modification. 3. Functional dependency
Menurut Connolly (2010, p420) merupakan konsep inti yang terkait dengan normalisasi.Functional dependency, menjelaskan relationship antar atributatribut dalam relasi.Misalkan, jika A dan B adalah atribut dari suatu relasi R, B dikatakan Functionally Dependent pada A (dinotasikan A --> B), jika setiap nilai A dihubungkan dengan tepat satu nilai B. ( A dan B masing-masing dapat terdiri atas satu atau lebih atribut). Functional dependency merupakan sifat dari arti semantik suatu atribut dalam sebuah relasi. Direpresentasikan dalam diagram :
Gambar 2. 7 Contoh Functional dependency (Connolly, Database Systems, p420) Determinant dari functional dependency mengacu kepada atribut atau himpunan atributdisebelah kiri anak panah.
Gambar 2. 8Contoh Functional dependency (Connolly, Database Systems, p419)
Aturan Functional Dependencies (Armstrong’s Axioms) : •
Reflectivity Jika B adalah bagian dari A, maka AB
•
Augmentation Jika AB, maka A,CB,C
•
Transitivity Jika AB dan BC, maka AC
•
Decomposition Jika AB,C, maka AB dan AC
•
Union Jika AB dan AC, maka AB,C
•
Composition Jika AB dan CD, maka A,CB,D
2.1.2
Teori Perancangan Basis Data 2.1.2.1 Pendekatan Perancangan Basis Data Menurut Connolly (2010, p321), database adalah kumpulan aplikasi yang berinteraksi dengan basis data. Terdapat berbagai pendekatan yang dapat digunakan dalam perancangan basis data, yaitu :
1.
Top-down
Pendekatan ini diawali dengan pembentukan model data yang berisi beberapa entitas high level dan relationship, kemudian entitas lower level, relationship, dan atribut lainnya akan didefinisikan secara berurut ke bawah. 2.
Bottom-up
Pendekatan ini diawali dengan atribut-atribut dasar, yang terdiri dari sifat entitas dan relationship, kemudian dilanjutkan dengan analisis dan penggabungan antar atribut yang dikelompokkan di dalam suatu relasi yang menggambarkan tipe dari entitas dan relationship antar entitas. 3.
Inside-out
Mirip dengan pendekatan bottom-up, namun identifikasi awal dimulai dengan entitas utama, kemudian menyebar ke identifikasi entitas, relationship, dan atribut lainnya yang masih terkait, yang sebelumnya telah diidentifikasi terlebih dahulu. 4.
Mixed
Menggunakan pendekatan bottom-up dan top-down untuk bagian yang berbeda, sesuai dengan kecocokan, dan kemudian digabungkan.
2.1.2.2 Tahapan Perancangan Basis Data Perancangan basis data terdiri dari tiga tahap utama, yaitu : 1. Perancangan basis data konseptual Pada tahap ini, model data dibuat dari sudut pandang dunia nyata dan terlepas dari pertimbangan fisik. Model desain hanya terdiri dari blok-blok dengan nama tabel dan relasi yang terjadi antar-tabel.
2. Perancangan basis data logikal Suatu proses pembentukan model dari informasi yang digunakan dalam enterprise berdasarkan model data tertentu ( misal : relasional), tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Sumber data berasal dari ERD Model pada perancangan basis data konseptual. 3. Perancangan basis data Fisikal Suatu
proses
yang
menghasilkan
deskripsi
implementasi
basis
data
padapenyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode aksesyang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakanjuga, desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu Menurut Connolly dan Begg (2010,p320), perancangan basis data merupakan suatu proses pembuatan sebuah desain database yang akan mendukung tujuan dan operasi suatu enterprise. Tujuan utamanya adalah : • Merepresentasikan data dan relationship antar data yang dibutuhkan oleh seluruh area aplikasi utama dan user group. • Menyediakan model data yang mendukung segala transaksi yang diperlukan pada data. • Menspesifikasikan desain minimal yang secara tepat disusun untuk memenuhi kebutuhan performa yang ditetapkan pada sistem (misal : waktu respon).
Contoh kasus : Kumpulan formulir-formulir penyewaan properti. Berikut dimasukkan ke dalam tabel : Tabel 2. 1 Contoh Tabel Kasus Untuk Penyewaan Properti No.Penyewa A
No.Properti B
PE001
PR01 PR03 PR01 PR04
PE002
Sewa/bulan G
Nama Penyewa C Andri Reni
Alamat Properti D JL.Kebon JL.Sawah JL.Kebon JL.Rawa
Tgl.Mulai E
Tgl.Akhir F
01/01/2009 01/01/2009 01/01/2008 01/01/2009
01/06/2009 01/12/2009 01/12/2008 01/06/2009
No.Pemilik H
Nama Pemilik I 500 PE01 Michael 1000 PE03 Roni PE01 500 Michael PE04 1500 Tobi Functional Dependencies yang terdapat pada relasi SewaProperti dari tabel kasus penyewaan properti : Fd1 No.Penyewa, No.Properti Tgl.Mulai, Tgl.Akhir (Primary Key) Fd2 No.Penyewa NamaPenyewa (Partial Dependency) Fd3 No.Properti AlamatProperti, Sewa/bulan, No.Pemilik, NamaPemilik (Partial Dependency) Fd4 No.Pemilik NamaPemilik (Transitive Dependency)
Gambar 2. 9 Analisis Functional dependency dari Penyewaan Properti Pada Segmen 1 / 1NF : •
A dan B adalah Primary Key.
•
Mencari relasi fully dependency, yaitu atribut non key yang tergantung kepada seluruh atribut primary key.
•
A,B E,F,G,H,I,C,D
Pada Segmen 2 / 2NF : •
Mencari relasi partial dependency, yaitu atribut non key yang tergantung kepada sebagian atribut primary key.
•
A,B E,F A dan B adalah Primary Key, sekaligus Foreign Key. Menjadi tabel SewaProperti. AC, A adalah Primary Key. Menjadi tabel Penyewa. B D,G,H ,I , B adalah Primary Key. Menjadi tabel Properti.
Pada Segmen 3 / 3NF : •
Mencari relasi transitive dependency, yaitu atribut non key yang tergantung kepada atribut bukan primary key.
•
A,B E,F A dan B adalah Primary Key, sekaligus Foreign Key. Menjadi tabel SewaProperti. AC, A adalah Primary Key. Menjadi tabel Penyewa. B D,G,H ; B adalah Primary Key. H adalah Foreign Key. Menjadi tabel Properti. HI ; H adalah Primary Key. Menjadi tabel pemilik.
Transaksi sistem yang dibutuhkan : a. Menampilkan data penyewa yang meliputi No.Penyewa dan Nama Penyewa. b. Menampilkan data pemilik yang meliputi No.Pemilik dan Nama Pemilik.
c. Menampilkan data SewaProperti berdasarkan Pemilik properti tertentu.
2.1.2.3 Perancangan Database Konseptual Suatu proses pembentukan model dari informasi yang digunakan dalam enterprise,independen dari keseluruhan aspek fisik. Model data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan user. Model data konseptual merupakan sumber informasi untuk fase desain logikal (Connolly 2010, p467). Adapun langkah-langkahnya yaitu : 1. Identifikasi tipe entitas Untuk mengidentifikasikan entitas utama yang dibutuhkan oleh view. Mendefinisikan objekutama dimana user mempunyai ketertarikan dengan objek tersebut. Objekini adalah tipe entitas untuk model. Salah satu metode untuk mengidentifikasi entitas adalah dengan menguji spesifikasi kebutuhan dari user. Dari spesifikasi ini kita mengidentifikasikan kata benda dan ungkapan kata benda(nous phrases) yang disebutkan. Kita juga dapat melihat objek utama seperti orang, tempat ataukonsep dari ketertarikan diluar kata benda lainnya yang merupakan kualitas dari objek lain. Berdasarkan contoh kasus di atas berikut adalah Tabel Kamus Tipe Entitas : Tabel 2. 2 Tabel Kamus Entitias Entitas Name
Description
Aliases
Occurance
Penyewa
Mendeskripsikan semua Penyewa
Pelanggan
Setiap penyewa dapat memiliki satu atau banyak SewaProperti
Properti
Mendeskripsikan semua properti
Rumah
-
Mendeskripsikan semua pemilik yang mempunyai properti
Pemilik
Pemilik
Setiap pemilik memiliki satu atau lebih bukti SewaProperti
2. Identifikasi tipe relationship Tujuannya untuk mengidentifikasikan relationship penting yang ada antara tipe entitas yang telahdiidentifikasikan. Kita dapat menggunakan grammar dari spesifikasi kebutuhan tersebut untuk mengidentifikasi relationship, biasanya relationship dinyatakan oleh kata kerja/verb atau ekspresi verbal. Secara langsung relationship tersebut adalah binary, dengan kata lain relationship tersebut berada antara dua type entitas. Berdasarkan contoh kasus di atas berikut adalah tabel kamus entitas relationships: Tabel 2. 3 Tabel Kamus Tipe Relasi Entitas Name Penyewa Pemilik
Multiplicity
Relationship
1..* 1..1
Memiliki Memiliki
Entitas Name Properti Properti
Multiplicity 1..* 1..*
3. Identifikasi dan Hubungkan Atribut dengan Entitas atau Tipe Hubungan Tujuannya untuk menghubungkan atribut dengan entitas atau tipe relationship yang sesuai dan mendokumentasikan detail dari setiap atribut. Atribut-atribut bisa diidentifikasi dengan kata benda atau ungkapan kata benda (nouns phrases) seperti property, kualitas, identifier atau karakteristik dari satu entitas atau hubungan.
Berdasarkan contoh kasus di atas berikut adalah Tabel Kamus Hubungan Atribut dengan Entitas : Tabel 2. 4 Tabel Kamus Hubungan Atribut Entitas Name Penyewa
Attributes
Description
No.Penyewa
Unik, mengidentifikasi setiap penyewa Nama Penyewa
NamaPenyewa No.Properti
Properti
Alamat Sewa/bulan No.Pemilik
Pemilik NamaPemilik
Unik, mengidentifikasi setiap properti Alamat properti Harga sewa per bulan Unik, mengidentifikasi setiap pemilik Nama Pemilik
Data type & length
Nulls
Multivalued
10 varchar
No
30 varchar
No
10 varchar
No
No
50 varchar 15 varchar
No No
No No
10 varchar
No
No
35 varchar
No
No
No No
4. Tetapkan domain atribut Tujuannya untuk menetapkan domain atribut dalam model data konseptual lokal dan mendokumentasikan setiap detail dari domain. Domain merupakan sekumpulan (pool) nilai-nilai darisatu atau lebih atribut yang menggambarkan nilainya. Berdasarkan contoh kasus di atas berikut adalah tabel domain atributnya : Tabel 2. 5 Domain Atribut Entitas name Penyewa Properti Pemilik
Attributes
Domain
No.Penyewa NamaPenyewa No.Properti Alamat Sewa/bulan No.Pemilik NamaPemilik
Di awali dengan PY
Di awali dengan PR Di awali dengan PE
5.
Tetapkan Atribut Primary dan Candidate key
Untuk mengidentifikasikan candidate key untuk setiap entitas dan jika terdapat lebih dari satucandidate key, maka pilih satu sebagai primary key. Berdasarkan contoh kasus di atas berikut adalah tabel atribut primary dan candidate key : Tabel 2. 6 Tabel Atribut Primary Key dan Candidate Key
Penyewa(No.Penyewa,NamaPenyewa) Candidate Key NamaPenyewa Primary Key No.Penyewa Alternate Key NamaPenyewa Properti (No.Properti, Alamat, Sewa/bulan) Candidate Key No.Properti Primary Key No.Properti Alternate Key Pemilik(No.Pemilik, NamaPemilik) Candidate Key No.Pemilik, NamaPemilik Primary Key No.Pemilik Alternate Key NamaPemilik
Gambar 2. 10 Gambar ER dengan Primary Key 6. Periksa Model Untuk Pengurangan Dalam langkah ini kita menguji model data konseptual lokal dengan tujuan spesifik untuk mengidentifikasikan apakah ada redundancy dalam data dan memindahkan data yang telah ada. Dua aktifitas dalam langkah ini adalah:
•
Menguji ulang relationship 1-1 (one-to-one)
Berdasarkan contoh kasus di atas hubungan relationship 1-1 tidak ditemukan selama proses analisis. •
Menghilangkan relationship yang redundan
Berdasarkan contoh kasus di atas tidak ada redundanrelationship yang terjadi. Dari 2 tahapan di atas, maka dapat disimpulkan bahwa tidak ada redudansi data yang terjadi. 7. Validasi Model Konseptual Lokal Terhadap Transaksi User Tujuannya untuk memastikan model konseptual lokal mendukung transaksi yang dibutuhkanoleh view. Diuji dua pendekatan untuk memastikan model data konseptual lokal mendukung transaksiyang dibutuhkan, dengan cara : Mendeskripsikan transaksi-transaksi Memeriksa seluruh informasi (entitas, relationship, dan atribut) yang dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan setiap kebutuhan transaksi. Berdasarkan contoh kasus di atas deskripsi transaksinya meliputi : a.
Menampilkan data penyewa yang meliputi No.Penyewa dan Nama Penyewa.
b.
Menampilkan data pemilik yang meliputi No.Pemilik dan Nama Pemilik.
c.
Menampilkan data Properti berdasarkan Pemilik properti tertentu.
Mengunakan jalur-jalur transaksi
Untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada ER diagram.
Gambar 2. 11 Gambar ER dengan Jalur Transaksi 8. Review Model Data Konseptual Lokal Dengan User Tujuannya untuk me-review model data konseptual lokal dengan user untuk memastikan modeltersebut adalah representasi sebenarnya dari view. Model data konseptual ini termasuk ER diagramdan dokumentasi pendukung yang mendeskripsikan model data. Bila ada kejanggalan(anomali) dalam model data, maka harus dibuat perubahan yang sesuai yang mungkin membutuhkan pengulangan langkah-langkah sebelumnya.
2.1.2.4 Perancangan Database Logikal Suatu proses pembentukan model dari informasi yang digunakan dalam enterprise berdasarkan model data tertentu ( misal : relasional), tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang
telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal (Connolly,2010, p490). Adapun langkah-langkahnya yaitu :
1. Menghilangkan fitur yang tidak sesuai dengan model relasional • Menghilangkan hubungan many to many (*..*) Pada ERD Konseptual terjadi hubungan entiti yang *..*. Hubungan ini harus dihilangkan dengan menambah entiti baru. Dari contoh kasus di atas terdapat hubungan many to many (*..*) yang terdapat pada penyewa dengan properti. Cara mengatasinya dengan menciptakan Entiti baru, yaitu SewaProperti. • Menghilangkan atribut yang multi-valued Pada bagian identifikasi atribut ada beberapa entiti yang mempunyai atribut yang multi-valued. Hal ini harus dihilangkan dengan memisahkan atribut yang multivalued dari entitinya. Biasanya multi-valued berupa atribut telepon. Pada contoh kasus di atas tidak terdapat multi-valued.
Gambar 2. 12 Gambar ER dengan menghilangkan fitur yang tidak sesuai
2. Menurunkan relasi untuk Model Data Logikal Tahapan ini membentuk relasi dari model data logikal untuk merepresentasikan relasi antar entiti dengan atribut yang telah didefinisikan. Untuk mendapatkan relasi dari data model yang ada, makan digunakan cara-cara berikut ini : 1. Strong entitas types; 2. Weak entitas types; 3. One-to-many (1:*) binary relationship types; 4. One-to-one (1:1) recursive relationship types; 5. One-to-one (1:1) binary relationship types; 6. Superclass/subclass relationship types; 7. Many-to-many (*:*) binary relationship types; 8. Complex relationship types; Dari contoh kasus di atas hanya terdapat 4 tahapan yang perlu diturunkan, yaitu: a. Strong Entitas
Pemilik(No.Pemilik, NamaPemilik) Primary Key No.Pemilik Properti(No.Properti, Alamat, Sewa/bulan) Primary Key No.Properti Penyewa(No.Penyewa, NamaPenyewa) Primary Key No.Penyewa b. Weak Entitas SewaProperti(No.Penyewa, No.Properti, TglMulaiSewa, TglAkhirSewa) Primary Key No.Penyewa, No.Properti
c. One to Many Relationship (1:*)
Masukkan No.Pemilik dalam Properti untuk model 1:* relasi memiliki Pemilik(No.Pemilik, NamaPemilik) Primary Key No.Pemilik
Properti(No.Properti,No.Pemilik, Alamat, Sewa/bulan) Primary Key No.Properti
d. Many to Many Relationship ( * : *) Penyewa(No.Penyewa, NamaPenyewa) Primary Key No.Penyewa
Properti(No.Properti, Sewa/bulan) Primary Key No.Properti
SewaProperti(No.Penyewa, No.Properti, TglMulaiSewa, TglAkhirSewa) Primary Key No.Penyewa, No.Properti Foreign Key No.Penyewa references Penyewa (No.Penyewa)
Alamat,
Gambar 2. 13 Menurunkan untuk Model Data Logikal
3. Memvalidasi relasi dengan normalisasi Untuk merancang basis data yang baik, biasa dilakukan normalisasi. Normalisasi merupakan sebuah teknik untuk menghasilkan set relasi dengan property yang desirable dan memberikan data sesuai dengan kebutuhan enterprise. Tujuan normalisasi yaitu: • mengidentifikasi hubungan antar atribut • mengkombinasikan atribut untuk membentuk relasi • mengkombinasikan relasi untuk membentuk database • menghindari anomali UNF Dalam proses normalisasi UNF kita menampilkan semua field atau atribut yang ada dalam suatu form yang ingin kita normalisasi.
Berdasarkan contoh kasus di atas UNF yang terjadi sebagai berikut SewaRumah
(No.Penyewa,
NamaPenyewa,{No.Properti,
AlamatProperti,
Tgl.MulaiSewa, Tgl.AkhirSewa, Sewa/bulan, No.Pemilik, NamaPemilik} ) 1NF Sebuah relasi berada dalam 1NF jika relasi tersebut tidak berisi atribut yang berulang (repeating group), field hasil perhitungan dihilangkan dan sudah mempunyai primary key. Berdasarkan contoh kasus di atas terjadi SewaRumah
(No.Penyewa,No.Properti,
NamaPenyewa,
AlamatProperti,
Tgl.MulaiSewa, Tgl.AkhirSewa, Sewa/bulan, No.Pemilik, NamaPemilik) 2NF Sebuah relasi berada dalam 2NF jika relasi tersebut dalam 1NF dan untuk setiap atribut non key bergantung fungsional penuh kepada primary key. Jadi pada 2NF kita akan menghilangkan ketergantungan sebagian / partial : ketergantungan field-field tertentu hanya kepada salah satu key yang composite. Berdasarkan contoh kasus di atas terjadi Penyewa (No.Penyewa, NamaPenyewa) SewaRumah (No.Penyewa,No.Properti, TglMulaiSewa, TglAkhirSewa) Properti_Pemilik(No.Properti, NamaPemilik)
AlamatProperti,
Sewa/bulan,
No.Pemilik,
3NF Sebuah relasi berada dalam 3NF bila relasi tersebut dalam 1NF dan 2NF dan tidak ada atribut non-key yang tergantung fungsional kepada atribut non-key yang lainnya (transitive dependency). Berdasarkan contoh kasus di atas terjadi Penyewa(No.Penyewa, NamaPenyewa) SewaRumah(No.Penyewa,No.Properti, TglMulaiSewa, TglAkhirSewa) Properti (No.Properti, AlamatProperti, Sewa/bulan, No.Pemilik) Pemilik(No.Pemilik, NamaPemilik)
Gambar 2. 14 Diagram Model Relasional
4. Memeriksa Integrity Constraints Integrity constraints adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten.
Tabel 2. 7 Tabel Integrity Constraints Pemilik(No.Pemilik, NamaPemilik) Primary Key No.Pemilik Penyewa (No.Penyewa, NamaPenyewa) Primary Key No.Penyewa Properti(No.Properti, No.Pemilik, AlamatProperti, Sewa/bulan) Primary Key No.Properti Foreign Key No.Pemilik referencesPemilik (No.Pemilik) ON UPDATE CASCADE ON DELETE NO ACTION SewaProperti(No.Properti, No.Penyewa, Tgl.MulaiSewa, Tgl.AkhirSewa) Primary Key No.Properti, No.Penyewa Foreign Key No.Properti referencesProperti (No.Properti) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key No.Penyewa referencesPenyewa (No.Penyewa) ON UPDATE CASCADE ON DELETE NO ACTION
5. Review Model Data Logikal Dengan User Review logical data model dengan pengguna dilakukan untuk memastikan bahwa model yang telah dibuat sudah benar atau sesuai dengan kebutuhan pengguna. Dari hasil review dengan pengguna, model data logikal yang dihasilkan sudah sesuai dengan kebutuhan yang ada. Sehingga, sudah dapat dilanjutkan ke tahap selanjutnya. 6. Memeriksa Untuk Pertumbuhan di Masa Depan Model data logikal yang dirancang sudah disesuaikan dengan kemungkinan yang mungkin terjadi di masa depan, kecuali jika terjadi perubahan pada kebutuhan pengguna.
2.1.2.4 Perancangan Database Fisikal Suatu proses yang menghasilkan deskripsi implementasi basis data padapenyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode aksesyang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu (Connolly, 2010, p522). Adapun langkah-langkahnya yaitu : 1.
Merancang relasi dasar
Dalam merancang relasi dasar digunakan DBDL (Database Design Language) untuk mendeskripsikan definisi relasi. Untuk setiap relasi diberikan deskripsi yang meliputi nama relasi, atribut, primary key, alternate key, foreign key, atribut yang merupakan hasil perhitungan, referential integrity, domain dan apakah atribut boleh NULL. Pada contoh kasus di atas berikut ini merupakan DBDL dari relasi yang ada : Pemilik Domain
No.Pemilik : variable length character string, length 10,diawali dengan PE Domain NamaPemilik : variable length character string, length 35 Pemilik( No.Pemilik Nomor Pemilik NamaPemilik Nama Pemilik Primary Key (No.Pemilik));
Penyewa Domain No.Penyewa
NOT NULL, NOT NULL,
: variable length character string, length 10,diawali dengan PY Domain NamaPenyewa : variable length character string, length 30
Penyewa( No.Penyewa Nomor Penyewa NamaPenyewa Nama Penyewa Primary Key (No.Penyewa));
NOT NULL, NOT NULL,
Properti Domain No.Properti : variable length character string, length 10,diawali dengan PR Domain Alamat : variable length character string, length 50 Domain Sewa/bulan : integer value Domain No.Pemilik : variable length character string, length 10,diawali dengan PE Properti ( No.Properti Nomor Properti NOT NULL, AlamatProperti Alamat Properti NOT NULL, Sewa/bulan Sewa per Bulan NOT NULL, No.Pemilik Nomor Pemilik NOT NULL, Primary Key (No.Properti), Foreign Key (No.Pemilik) references Pemilik (No.Pemilik) ON UPDATE CASCADE ON DELETE NO ACTION );
SewaProperti Domain No.Properti : variable length character string, length 10,diawali dengan PR Domain No.Penyewa : variable length character string, length 10,diawali dengan PY Domain Tgl.MulaiSewa : date/time Damain Tgl.AkhirSewa : date/time SewaProperti( No.Properti Nomor Properti NOT NULL, No.Penyewa Nomor Penyewa NOT NULL, Tgl.MulaiSewa Tanggal Mulai Sewa NOT NULL, Tgl.AkhirSewa Tanggal Akhir Sewa NOT NULL, Primary Key (No.Properti, No.Penyewa), Foreign Key (No.Properti) references Properti (No.Properti) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (No.Penyewa) references Penyewa (No.Penyewa) ON UPDATE CASCADE ON DELETE NO ACTION );
2.
Menganalisis transaksi
Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari transaksi yang akan berjalan pada basis data dan untuk menganalisis transaksi yang penting. Berdasarkan contoh kasus di atas deskripsi transaksinya meliputi : a.
Menampilkan dan mengubah data penyewa yang meliputi No.Penyewa dan Nama Penyewa.
b.
Menampilkan dan mengubah data pemilik yang meliputi No.Pemilik dan Nama Pemilik.
c.
Menampilkan data Properti berdasarkan Pemilik properti tertentu.
Gambar 2. 15 Validasi Transaksi
3.
Memilih Index
Tujuan dari langkah ini adalah untuk menentukan apakah penambahan index akan meningkatkan kinerja dari sistem.Index Clustered artinya . Index NonClusteredartinya. Pada DBMS MySQL primary key didefinisikan ke dalam Index Clustered
(sumber:
http://dev.mysql.com/doc/refman/5.0/en/innodb-index-
types.html). Dari contoh kasus di atas index yang akan digunakan adalah sebagai berikut : Tabel 2. 8 Tabel Index Tabel Pemilik Penyewa Properti SewaProperti
4.
Index
Clustered
NonClustered
PemilikInd PenyewaInd PropertiInd SewaPropertiInd
Merancang User View
Tujuan dari langkah ini adalah untuk melihat sudut pandang pengguna terhadap tabel dan field yang ada di dalam database. 5.
Merancang mekanisme keamanan
Tujuan dari langkah ini adalah untuk merancang mekanisme keamanan pada basis data seperti yang telah dispesifikasikan oleh user. Mekanisme keamanan tersebut adalah pembatasan hak akses guna menjaga keamanan data. Selain itu perlu juga diperhatikan keamanan DBMS dan sistem operasinya. 6.
Memperkirakan kebutuhan disk
Tujuan dari langkah ini adalah untuk menghitung kapasitas penyimpanan yang dibutuhkan oleh basis data. Hal yang harus diperhatikan adalah seberapa besar
ruang penyimpanan yang tersedia saat ini. Penyimpanan yang tersedia saat ini akan menentukan besarnya kapasitas penyimpanan yang dibutuhkan sekarang dan lima tahun mendatang. MySQL Storage Requirement (sumber : http://dev.mysql.com/doc/refman/5.0/ en/storage-requirements.html) : • VARCHAR(M), ukurannya M+1 bytes. • INT, INTEGER, ukurannya 4 bytes. • TEXT, ukurannya 65535 bytes . • DATE, ukurannya 3 bytes. • DATETIME, ukurannya 8 bytes. • NUMBER(M,D), ukurannya M+2 bytes jika D > 0, M+1 bytes jika D = 0, D+2 bytes jika M < D.
2.1.3
Teori Perancangan Web Database Menurut Eaglestone (2001, p38) “Web Database System are systems in which both Web and database technologies are used”. Dapat dikatakan web database system adalah sistem dimana dipadukannya teknologi web dan database. Menurut Eaglestone (2001, p262), perancangan Web Database mirip seperti konvensional database namun terdapat dua hal yang perlu ditambahkan : •
Web Page Design, hal ini meliputi : a. Web data representation
Menampilkan web data, mengambil dari database atau masukan dari user. b. Web data association Kumpulan web data, perancangan hubungan untuk petunjuk di dalam maupun di antara web pages. c. Web interface design Perancangan web pages features. • Perancangan koneksi antara Web Pages dan database, meliputi : a. Web database logical mapping Definisi mapping antara data displayed dalam web pages dan data stored dalam database. b. Web database physical mapping Implementasi mekanisme data yang dilakukan di antara web pages dan database. Kinerja cepat dan bebas kesalahan. Adapun skema perancangan web database :
Gambar 2. 16 Perancangan Web Database (Sumber : Eaglestone, 2001,p264) 2.1.3.1 Perancangan Konseptual Web Data Pada tahap ini berhubungan dengan web data analysis. Web data analysis mendefinisikan sebuah konseptual model dari informasi yang mewakili halaman web, serta informasi yang mewakili basis data. Data keluaran berupa ekstensi dari konseptual data model yang meliputi hypermedia link (hubungan antara halaman web), dan concept box (konsep web atau teknologi yang tidak dapat digambarkan dengan basis data) (Eaglestone,2001,p288-p289).
Dari contoh kasus di atas akan menghasilkan konseptual web data model seperti berikut ini :
Gambar 2. 17 Konseptual Web Data Model 2.1.3.2 Perancangan Logikal Web Data Pada tahap ini mendefinisikan struktur data dari halaman web yang sebenarnya, termasuk hubungan antara bagian-bagian dan ke halaman web lain. Data masukan berasal dari ERD yang telah normal dari logikal data model, dan ekstensi dari konseptual web data model. Data keluaran berupa Page Schema yaitu data item dari basis data yang akan mewakili di dalam halaman web. (Eaglestone,2001,p311). 2.1.3.3 Perancangan Fisikal Web Data Pada tahap ini menjelaskan bagaimana halaman webharus dilaksanakan dan terhubung ke database. Berhubungan juga dengan alat dan teknik yang dapat digunakan untuk membuat database dapat diakses melalui web.
Komponen database dapat diimplementasikan sebagai ekstensi dari server atau browser, atau mungkin eksternal ke web. Implementasi harus menganalisa dan memutuskan bagaimana untuk mengakses basis data dari client atau server dan di mana proses aplikasi.
Implementasi juga harus
mempertimbangkan web arsitektur (Eaglestone,2001, p348-359). a. Two-Tier Client Server Arsitektur Pada model ini aplikasi dibagi menjadi dua tier, yaitu First Tier dan Second Tier. • Layanan Presentasi (First Tier) Layanan presentasi atau logika antarmuka pengguna ditempatkan pada mesin client. Lapisan ini berfungsi untuk menangani interaksi user dengan aplikasi. • Layanan Data (Second Tier) Layanan data merupakan sebuah database server atau DBMS (Database Management Systems) yang menyediakan data bagi lapisan layanan client atau presentasi
Gambar 2. 18 Gambar Two-Tier Client Server b. Three-Tier Client Server Arsitektur Model three-tier merupakan langkah pengembangan dari Arsitektur two-tier. Model ini menambahkan komponen ketiga diantara aplikasi client dengan aplikasi server yang disebut middle tier. • Layanan Presentasi (First Tier) Sebagaimana dalam two-tier, layanan ini berfungsi untuk menangani semua interaksiuser dengan aplikasi. Namun demikian, layanan ini tidak langsung mengaksesdatabase server. • Layanan Bisnis (Middle Tier) Layanan bisnis atau biasa disebut dengan middle tier merupakan sebuah aplikasi yangmemberlakukan aturan-aturan bisnis, memproses data, dan mengelola transaksi.Logika yang semula ditempatkan pada client dipindahkan ke dalam komponenlapisan bisnis ini. • Layanan Data (Data Source Tier)
Layanan data merupakan sebuah DBMS yang mewakili satu atau lebih penyimpanandata. Lapisan ini menyediakan permintaan data bagi aplikasi client dengan melaluilapisan layanan bisnis.
Gambar 2. 19 Gambar Three-Tier Client Server
2.2
Teori-Teori Khusus
2.2.1
Teori-Teori Pemrograman Web 2.2.1.1 PHP : Hypertext Preprocessor PHP adalah bahasa server side scripting yang di desain secara spesifik untuk web. Di dalam page HTML, dapat dimasukkan kode PHP yang akan di eksekusi setiap waktu page dikunjungi. Kode PHP diinterpretasikan pada web server dan meng-generate HTML atau output lainnya yang akan dilihat oleh pengguna (Welling L. and Thomson L., 2001).
Sklar (2004, p4-6) dalam bukunya Learning PHP 5 memberikan pendapat mengenai keunggulan dari bahasa server-side scripting PHP ini yang adalah sebagai berikut : • PHP tidak berbayar • PHP bersifat open source • PHP bersifat cross-platform • PHP banyak digunakan • PHP menyembunyikan kompleksitasnya • PHP dibuat untuk pemrograman Web 2.2.1.2 CodeIgniter Dalam CodeIgniter User Guideversi 2.1.3, CodeIgniter dituliskan sebagai framework yang tidak membutuhkan banyak sumber daya dan diklaim sebagai framework PHP tercepat. Framework ini menggunakan pendekatan MVC (Model-View-Controller) di mana business logic dan presentation dipisahkan secara jelas sehingga desainer dan programmer dapat bekerja secara terpisah dalam pengembangan sebuah proyek.
Gambar 2. 20 Gambar Aliran Data CodeIgniter
2.2.1.3 JavaScript JavaScript digunakan pada jutaan halaman Web untuk meningkatkan desain, memvalidasi form, mendeteksi browser, membuat cookie dan banyak lagi. JavaScript menjadi bahasa scripting paling populer di Internet dan dapat bekerja pada semua browser umum. 2.2.1.4 MySQL Menurut Allen dan Honberger (2002, p220) dalam bukunya Mastering PHP 4.1 MySQL merupakan bahasa pemrograman open source yang paling banyak digunakan oleh para programmer, terutama pada Linux, karena query basis datanya yang handal dan jarang bermasalah. 2.2.1.5 jQuery jQuery adalah sebuah library untuk JavaScript yang ringan, cepat dan ringkas. jQuery menyederhanakan HTML document traversing, event handling, animation dan interaksi AJAX untuk rapid web development.
2.2.2
Teori Rekayasa Perangkat Lunak 2.2.2.1 Framework Menurut Jeffrey L.Whitten (2004,p653) Framework adalah sebuah subsistem dari kolaborasi objek yang menyediakan satu set layanan yang berhubungan. Developer menggunakan Oject Frameworks untuk memanfaatkan kemampuan penggunaan kembali dan untuk mengurangi waktu pembuatan.
2.2.2.2 Flowchart Flowchart atau bagan alur merupakan metode untuk menggambarkan tahap-tahap penyelesaian masalah (prosedur) beserta aliran data dengan simbolsimbol standar yang mudah dipahami. Tujuan utama penggunaan Flowchart adalah untuk menyederhanakan rangkaian proses atau prosedur untuk memudahkan
pemahaman
pengguna
terhadap
(Soeherman,2008,p133)
Gambar 2. 21 Simbol Input (Sumber : Dewobroto, 2005,p14)
Gambar 2. 22 Simbol Output (Sumber : Dewobroto, 2005,p14)
informasi
tersebut.
Gambar 2. 23 Simbol Process atau Lainnya (Sumber : Dewobroto, 2005,p14) 2.2.2.3 Work Flow Menurut Jeffrey L.Whitten (2004,p62)Work Flow adalah aliran transaksi melalui proses bisnis untuk memastikan pemeriksaan yang benar dan persetujuan diimplementasikan.
