BAB 2 LANDASAN TEORI Database
system
pada
dasarnya
adalah
sistem
pencatatan
terkomputerisasi di mana sistem tersebut ditujukan untuk menyimpan informasi dan mengizinkan pengguna untuk menerima dan mengubah informasi sesuai permintaan (Date, 2000, p5). Informasi yang disimpan dapat berupa apa saja yang dibutuhkan untuk membantu proses bisnis dari individu atau organisasi. Peningkatan kinerja database pun sangat bergantung kepada interaksi dengan database system, seperti yang diungkapkan Leitheiser dan March (1996). Sedangkan database sendiri adalah sekumpulan data yang terhubung secara logika beserta deskripsinya. Database didesain untuk memenuhi kebutuhan informasi dari sebuah organisasi (Connolly, 2010, p65). Terhubung secara logika di sini maksudnya adalah sebuah database mewakili entity, atribut dan logic relation di antara tiap entity. Data-data di dalam database memiliki struktur relasi yang dinamakan relational data structure. Struktur relasi ini terdiri dari relasi, atribut, domain, tuple, degree, dan cardinality. Relasi diartikan sebagai sebuah tabel dengan kolom dan baris. Atribut merupakan nama kolom dari relasi tersebut dan domain merupakan suatu set nilai yang diperbolehkan untuk satu atau lebih atribut. Nama baris dari suatu relasi disebut dengan tuple. Degree merupakan jumlah dari atribut. Misalkan dalam suatu relasi memiliki empat atribut, maka kita bisa menyebut relasi tersebut memiliki degree four. Jumlah dari tuple disebut dengan cardinality.
7
8
Contoh :
Gambar 2. 1 Contoh Hubungan Atribut, Relasi, Degree, dan Tuple Koleksi dari relasi yang telah ternomalisasi dengan nama relasi yang berbeda disebut dengan relational database. Relational database terdiri dari relasi yang tepat terstruktur. Ketepatan struktur ini dikenal dengan normalisasi. 2.1
Database Design 2.1.1
Normalisasi Normalisasi adalah teknik untuk membuat kumpulan relasi dengan properti yang diinginkan berdasarkan persyaratan data dari suatu perusahaan (Connolly, 2010, p416). Proses dari normalisasi adalah metode formal yang mengidentifikasi relasi berdasarkan primary key, candidate key, dan functional dependency di mana functional dependency itu sendiri menjelaskan tentang hubungan antara dua atribut di dalam sebuah relasi. Proses normalisasi dimulai dari memindahkan data dari sumber data. Misalnya, entry form ke dalam bentuk tabel yang
9 selanjutnya disebut Unnormalized Form (UNF). Menurut Kung dan Case (2004), normalisasi dilakukan untuk mencegah terjadinya anomali data yang mungkin terjadi selama memanipulasi relasi dalam relational database. Anomali data yang mungkin terjadi dibagi menjadi tiga, yaitu: anomali pada saat insert, delete dan update (modifikasi) data. Sebagai contoh, terdapat data sebagai berikut: Tabel 2. 1 Tabel Request (UNF) TransID T01
UserID U01
Username User1
TransDate 10-01-2012
T02 T03
U02 U03
User2 User3
10-02-2012 10-02-2012
T04
U02
User2
10-03-2012
ProductID P0001 P0004 P0002 P0002 P0003 P0003
ProductName Product01 Product04 Product02 Product02 Product03 Product03
Qty 1 2 3 4 1 6
Dalam tabel tersebut ada kemungkinan terjadi tiga macam anomali data: 1. Anomali insert Anomali insert terjadi saat proses memasukkan data baru. Dalam tabel 2.1, anomali insert terjadi saat memasukkan produk baru, jika tidak diketahui TransID dari produk yang dimasukkan maka akan terjadi kerancuan data. 2. Anomali delete Anomali delete terjadi saat proses menghapus data. Dalam tabel 2.1, anomali delete terjadi saat menghapus baris yang berisi TransID. Misalnya menghapus baris dengan TransID T01, maka ProductID P00004 di baris kedua akan kehilangan informasi ID transaksinya.
10
3. Anomali update Anomali update terjadi saat proses memodifikasi data. Dalam tabel 2.1, anomali update terjadi saat mengganti nama produk, maka nama produk harus diganti pada semua transaksi. Jika nama produk tidak
diganti
pada
semua
transaksi,
maka
akan
terjadi
ketidakkonsistenan data. Anomali data tersebut harus dinormalisasi dalam beberapa tahap. Adapun normalisasi sendiri memiliki lima tahap yaitu 1NF, 2NF, 3NF, BCNF, 4NF, dan 5NF. Namun pada praktiknya normalisasi dilakukan hanya sampai pada tahap 3NF, BCNF, atau paling jauh sampai pada tahap 4NF. Adapun penjelasan mengenai tahap normalisasi adalah sebagai berikut: 1. 1NF Untuk menghasilkan bentuk 1NF, akan dilakukan identifikasi dan penghilangan repeating groups dari tabel UNF. Berikut adalah contoh bentuk 1NF dari tabel UNF 2.1: Tabel 2. 2 Tabel Request (1NF) TransID
UserID
Username
TransDate
ProductID
ProductName
Qty
T01
U01
User1
10-01-2012
P0001
Product01
1
T01
U01
User1
10-01-2012
P0004
Product04
2
T02
U02
User2
10-02-2012
P0002
Product02
3
T03
U03
User3
10-02-2012
P0002
Product02
4
11 T03
U03
User3
10-02-2012
P0003
Product03
1
T04
U02
User2
10-03-2012
P0003
Product03
6
Pada bentuk 1NF ini, functional dependency dari setiap atribut dipaparkan untuk dihilangkan pada tahap selanjutnya. Functional dependency menjelaskan tentang hubungan antara dua atribut di dalam sebuah relasi. Contoh:
Gambar 2. 2 Contoh Functional Dependency A disebut dengan determinant dan B disebut dengan dependent. Gambar di atas menunjukan functional dependency antar atribut A dan B. Setiap nilai B bergantung atau ditentukan oleh tepat satu nilai A (Connolly, 2010, p421). Ada tiga jenis functional dependency yaitu: 1. Fully Functional Dependency Sebuah atribut dapat dikatakan fully functional dependency jika atribut tersebut bergantung pada seluruh atribut primary key. Pengindikasian jika A dan B merupakan atribut dalam suatu relasi. B bergantung penuh secara fungsional pada A jika penghapusan atribut dari A menghasilkan ketidaktergantungan. 2. Partial Functional Dependency
12 Sebuah atribut dapat dikatakan partial funstional dependency jika atribut tersebut bergantung pada sebagian atribut primary key. B
bergantung
sebagian
secara
fungsional
pada
A
jika
penghapusan atribut dari A masih menghasilkan ketergantungan. 3. Transitive Functional Dependency Kondisi di mana A, B, dan C merupakan atribut dalam suatu relasi. A → B dan B → C, maka C bergantung secara transitif pada A melalui B. 2. 2NF Pada tahap ini akan dilakukan penghilangan partial dependency dari tabel 1NF, di mana partial dependency itu sendiri adalah atribut non-primary key yang bergantung kepada sebagian atribut primary key. Berikut adalah contoh perubahan dari bentuk 1NF ke 2NF:
Gambar 2. 3 Functional Dependency 1NF Tabel Request Gambar diatas merupakan bentuk functional dependency dari tabel 2.2. A dan E merupakan primary key. Atribut F hanya
13 bergantung kepada atribut E yang merupakan sebagian atribut primary key. Dengan kata lain, F merupakan partial dependency yang harus dihilangkan untuk memenuhi syarat bentuk 2NF. Begitu juga dengan atribut D dan B.
Gambar 2. 4 Functional Dependency 2NF Tabel Request 3.
3NF Pada tahap ini akan dilakukan penghilangan transitive dependency dari tabel 2NF, di mana transitive dependency adalah atribut nonprimary key yang bergantung kepada atribut non-primary key lain. Berikut ini adalah contoh perubahan dari bentuk 2NF menjadi 3NF: Atribut C bergantung kepada B, sementara atribut B merupakan atribut non-primary key, maka atribut B merupakan transitive dependency yang harus dihilangkan untuk memenuhi syarat bentuk 3NF.
14
A
E
G
A
D
B
B
C
E
F
Keterangan: A: TransID B: UserID C: Username
D:TransDate G: Qty E: ProductID F: ProductName
Gambar 2. 5 Functional Dependency 3NF Tabel Request 2.1.2
Entity Relationship Entity type adalah kelompok objek dengan properti yang sama yang diidentifikasikan oleh perusahaan yang memiliki independent existence (Connolly, 2010, p372). Entity type merupakan konsep dasar dari ER model yang umum digunakan untuk data model, menurut Lee dan Ling (2003). Sedangkan yang dimaksud dengan relationship types adalah suatu set hubungan di antara satu atau lebih entity type (Connolly, 2010, p374). Setiap tipe hubungan ditunjukan dengan garis penghubung entity type dan diberikan label nama dari relationship. Normalnya relationship ini diberi nama menggunakan kata kerja. Degree of relationship types mengidentifikasikan jumlah entity yang berpartisipasi dalam relasi. Beberapa degree of relationship types diantaranya, yaitu: 1.
Binary yaitu jumlah entity yang terlibat ada dua buah.
2.
Ternary yaitu jumlah entity yang terlibat ada tiga buah.
15 3.
Quartenary yaitu jumlah entity yang terlibat ada empat buah.
Atribut merupakan properti dari suatu entity type atau relationship. Sedangkan yang dimaksud dengan attribute domain yaitu nilai yang diperbolehkan untuk satu atau lebih atribut (Connolly, 2010, p350). Setiap atribut dihubungkan oleh suatu set nilai yang disebut dengan domain. Domain tersebut menetapkan nilai potensi yang mungkin atribut tersebut pegang dan sama dengan domain concept pada relational model. Entity type diklasifikasikan ke dalam dua kelompok, yaitu: 1.
Strong Entity Tipe entity yang tidak bergantung dengan tipe entity lainnya (parent, owner or dominant entities).
2.
Weak Entity Tipe entity yang bergantung dengan tipe entity lainnya (child, dependent or subordinate emtities).
Gambar 2. 6 Contoh Strong dan Weak Entity Telah disebutkan sebelumnya, degree of relationship types yang paling umum yaitu binary relationship. Secara umum, binary relationship dibagi menjadi tiga berdasarkan kendala integritasnya, yaitu
16 one to one, one to many, dan many to many. Berikut penjelasan ketiganya: 1.
One to One (1:1) Relationship
Gambar 2. 7 Contoh One to One (1:1) Relationship Relasi ini menggambarkan bahwa tepat satu atribut pada entity A berpasangan tepat satu atribut pada entity B. Seperti yang disebutkan pada contoh, bahwa setiap satu general services staff akan menghubungi tepat satu warehouse staff. 2.
One to Many (1:*) Relationship
Gambar 2. 8 Contoh One to Many (1:*) Relationship Relasi ini menggambarkan bahwa satu atribut pada entity A berpasangan pada banyak jumlah atribut pada entity B. Seperti yang disebutkan pada contoh, bahwa pegawai dapat tidak membuat hingga membuat banyak transaksi permintaan. 3.
Many to Many (*:*) Relationship
Gambar 2. 9 Contoh Many to Many (*:*) Relationship
17 Relasi ini menggambarkan bahwa lebih dari satu atau lebih dari nol atribut pada entity A berpasangan pada banyak jumlah atribut pada entity B. Seperti yang disebutkan pada contoh, bahwa transaksi memiliki paling tidak satu atau banyak barang di dalamnya. Dalam perancangan hubungan antar entity, dimungkinkan adanya konsep spesialisasi/generalisasi. Konsep ini berhubungan dengan entity type spesial yang dikenal sebagai superclass dan subclass, juga berhubungan dengan proses pewarisan atribut. Yang dimaksud dengan superclass adalah entity type yang mengandung satu atau lebih subgrouping. Sedangkan subclass adalah subgrouping yang merupakan bagian dari superclass (Connolly, 2010, p400). Hubungan antara superclass dan subclass adalah One to One (1:1) Relationship. Sebagai contoh, entity Pegawai merupakan superclass yang memiliki subclass, yaitu: GeneralServicesStaff dan WarehouseStaff. Sehubungan dengan pewarisan atribut, entity subclass akan mewarisi semua atribut entity superclass, namun subclass bisa saja memiliki atribut tambahan. Dalam pewarisan atribut antara superclass dan subclass terdapat tipe hierarki, diantaranya hierarki generalisasi (Pegawai generalisasi WarehouseStaff), hierarki spesialisasi (WarehouseStaff spesialisasi Pegawai), dan hierarki IS-A (WarehouseStaff adalah bagian dari Pegawai).
18 Generalisasi sendiri adalah proses meminimalisir perbedaan antar entity dengan mengidentifikasi karakteristik yang sama (Connolly, 2010, p403). Sedangkan spesialisasi adalah proses memperbanyak perbedaan antar entity (Connolly, 2010, p402).
Gambar 2. 10 Contoh Generalisasi/Spesialisasi
Gambar 2. 11 Contoh Entity Relationship 2.1.3
Conceptual Database Design Conceptual database design adalah proses dari membangun sebuah model data yang digunakan di perusahaan dan bebas dari detail implementasi seperti Database Management System (DBMS), program aplikasi, bahasa pemrograman, platform hardware, masalah performa,
19 dan pertimbangan fisikal lainnya (Connolly, 2010, p467). Menurut Lawson, et al. (2012) DBMS merupakan standar penyimpanan data atau informasi dan dapat mengatur serta memelihara struktur dari data yang disimpan. Tahap-tahap yang dilakukan dalam conceptual database design yaitu: 1. Mengidentifikasi tipe entity. 2. Mengidentifikasi tipe relasi. 3. Mengidentifikasi dan menghubungkan atribut-atribut dengan entity atau relation types. 4. Menentukan atribut domain. 5. Menentukan candidate, primary, dan alternate key. 6. Mempertimbangkan Penggunaan Enhanced Modeling Concept 7. Memeriksa redudansi pada model. 8. Memvalidasi conceptual data model terhadap transaksi pengguna. 9. Meninjau kembali conceptual data model dengan pengguna.
Gambar 2. 12 Contoh Conceptual Data Model
20 2.1.4
Logical Database Design Logical database design adalah proses dari membangun sebuah model data yang digunakan di perusahaan berdasarkan specific data model yang tidak bergantung kepada DBMS, program aplikasi, bahasa pemrograman, platform perangkat keras, masalah performa, dan pertimbangan fisikal lainnya (Connolly, 2010, p467). Tahap-tahap yang dilakukan dalam logical database design yaitu: 1. Menurunkan relasi-relasi dari conceptual database design. 2. Memvalidasi relasi menggunakan normalisasi. 3. Memvalidasi relasi terhadap transaksi pengguna. 4. Memeriksa integrity constraits. 5. Meninjau kembali logical data model dengan pengguna. 6. Menggabungkan logical data model dengan model global. 7. Memeriksa perkembangan data di masa yang akan datang.
Gambar 2. 13 Contoh Logical Data Model
21 2.1.5
Physical Database Design Physical database design adalah proses menghasilkan deskripsi implementasi database pada penyimpanan sekunder (Connolly, 2010, p467). Tahap ini menggambarkan relasi dasar organisasi file dan indeksindeks untuk mencapai akses ke data dan beberapa kendala integritas serta keamanan data. Tahap-tahap yang dilakukan dalam physical database design yaitu: 1.
Menerjemahkan logical data model ke DBMS sasaran: -
Merancang relasi dasar.
-
Merancang representasi dari data turunan.
-
Merancang kendala umum.
2. Merancang organisasi file dan indeks-indeks: - Menganalisis transaksi. -
Memilih organisasi file.
-
Memilih indeks-indeks.
-
Mengestimasi kebutuhan ruang penyimpanan.
3. Merancang user views. 4. Mempertimbangkan pengenalan redundansi yang terkontrol. 5. Memantau dan menyesuaikan sistem operasi. 2.1.6 Database Lifecycle Database lifecyle merupakan tahapan dalam merancang suatu database system (Connoly, 2010, p311). Siklus hidup database digambarkan seperti berikut ini:
22
Gambar 2. 14 Database Lifecycle (Connolly, p314) 1.
Database Planning Suatu kegiatan pengelolaan yang dilakukan agar tiap tahap dalam daur pembuatan dapat dijalankan secara efisien dan efektif.
2.
System Definition Menjelaskan tentang cakupan dan batasan dari aplikasi database dan menggambarkan kebutuhan user akan aplikasi database secara umum.
23
3.
Requirements Collection and Analysis Proses mengumpulkan dan menganalisis informasi tentang bagian dari organisasi yang nantinya akan didukung oleh aplikasi database
dan
kemudian
menggunakan
informasi
ini
untuk
mengetahui kebutuhan pengguna terhadap sistem yang baru. 4.
Database Design Perancangan dibagi menjadi tiga tahap yaitu conceptual, logical, dan physical.
5.
DBMS Selection Memilih DBMS yang tepat untuk mendukung aplikasi database.
6.
Application Design Proses mendesain user interface dan membuat program aplikasi yang digunakan untuk mengakses database.
7.
Prototipe Membuat suatu model dari aplikasi database, yang digunakan agar pengembang dan pengguna bisa mengevaluasi bagaimana sistem nantinya akan berjalan dan juga melihat tampilannya.
2.2
Web Database Design 2.2.1
Web Data Analysis Web data analysis adalah proses yang menghasilkan sebuah conceptual model dari data yang akan diwakilkan dalam halaman web (Eaglestone, 2001, p284). Input dari tahap data analysis adalah deskripsi
24 dari organisasi dan system requirements, serta conceptual model (ER) untuk database yang merupakan hasil dari tahap data analysis di perancangan database. Bentuk conceptual model untuk halaman web mirip dengan ER untuk database namun pada conceptual model untuk halaman web hanya entity yang berhubungan dengan aplikasi yang dipakai. Terdapat dua aspek tambahan yang juga membedakan conceptual model untuk database dan conceptual model untuk halaman web, yaitu hypermedia links dan web application-specific concepts. Hypermedia links berfungsi sebagai navigasi di dalam dan antar halaman web. Aspek ini dipresentasikan menggunakan garis relationship yang memiliki arah. Web application-specific concepts menampilkan konsep yang tidak sesuai dengan ER model untuk database tetapi tetap harus ditampilkan di conceptual model untuk halaman web dan dipresentasikan menggunakan bentuk oval yang disebut concept boxes. Dalam web data analysis terdapat dua tahapan, yaitu web data extraction dan web data connectivity analysis. 1.
Web Data Extraction Pada tahap ini pengembang harus mencari kesesuaian dari setiap candidate entity, atribut dan relationship dari conceptual model untuk database dengan deskripsi tentang
25 halaman web. Jika ditemukan kesesuaian maka dimasukkan ke dalam conceptual model untuk halaman web. 2.
Web Data Connectivity Analysis Pada tahap ini dilakukan analisis deskripsi aplikasi web, untuk mengidentifikasi jalur akses ke sistem dan jalur navigasi di dalam dan antara halaman web.
Sebagai contoh akan digunakan conceptual model dari contoh gambar 2.12 dan deskripsi kebutuhan halaman web sebagai berikut: Sebuah perusahaan berencana membuat sebuah aplikasi online untuk
mengelola permintaan barang dari pegawai.
Aplikasi tersebut akan diorganisir seperti berikut: -
Halaman Home berisi tautan ke halaman yang berisi daftar barang dan permintaan dari pegawai.
-
Halaman Stationary berisi daftar barang dan tautan ke halaman untuk update barang dan input barang yang baru.
-
Halaman Request berisi daftar permintaan dari pegawai dan tautan ke halaman Stationary. Dalam setiap permintaan terdapat daftar barang yang dipesan.
26
Gambar 2. 15 Contoh Conceptual Model untuk Halaman Web 2.2.2
Logical Web Data Design Pada logical web data design pengembang mendefinisikan struktur data dari halaman web termasuk tautan antara bagian-bagian dalam halaman web dan tautan ke halaman web lain (Eaglestone, 2001, p265). Pengembang merinci data konten dari halaman web sebagai logical web page schemas. Skema ini merinci struktur dari data yang ditampilkan dan/atau dimasukkan melalui tiap halaman web. Berikut ini adalah contoh bentuk dari logical web page scemas dari conceptual model contoh 2.13:
27
HomePage UNIQUE Stationary: LIST-OF Barang.Nama: STRING Request: LIST-OF Request:
Permintaan.No: STRING
Stationary Barang.No: STRING Barang.Nama: STRING Stok: Integer Update: “Update Stationary” : STRING
Request Permintaan.No: Stationary: Permintaan.Tanggal: Permintaan.Jumlah:
STRING DATE Integer
Insert: “Insert Stationary” : STRING
Insert Barang.No: Barang.Nama: Stok:
STRING STRING Integer
Update Barang.No: Barang.Nama: Stok:
STRING STRING Integer
Gambar 2. 16 Contoh Representasi Grafis Logical Web Pages Schemas 2.2.3 Physical Web Data Design Dalam tahap ini ditentukan pilihan teknis tentang bagaimana komponen database dihubungkan ke halaman web dan bagaimana halaman web tersebut akan dibuat (Eaglestone, 2001, p265). Aplikasi berbasis web harus dibangun berdasarkan web architecture. Web architecture sendiri memiliki dua bagian, yaitu:
28 1.
Sistem Client Sistem client dijalankan pada browser. Sistem ini menampilkan halaman web yang menyajikan antarmuka database untuk pengguna.
2.
Sistem Server Sistem ini menyimpan dokumen web, script, beserta programnya. Dokumen web adalah versi mark up dari halaman web yang ditampilkan. Script pada sistem ini berhubungan dengan aspek dinamis, seperti penerimaan, manipulasi, dan memperbaharui data di database. Sedangkan program
mengimplementasikan
database
atau
menyediakan
aspek
dinamis,
antarmuka
untuk
sistem sistem
database, misalnya CGI script. Menurut Urbanowicz (2001), client-server arsitektur berguna untuk menyediakan infrastruktur organisasi yang fleksibel dan kuat tergantung kepada bagaimana arsitektur tersebut dirancang. Berikut ini akan dijabarkan macam client-server arsitektur yang umum digunakan: -
Two-tier Architecture Two-tier architecture secara garis besar dideskripsikan sebagai arsitektur yang hanya terbagi menjadi dua lapis tugas utama (two-tier), yaitu client sebagai first tier dan server sebagai second tier.
29
Gambar 2. 17 Two-tier Architecture -
Three-tier Architecture Three-tier architecture sering juga disebut dengan multitier arsitektur. Arsitektur ini memiliki tiga lapis tugas utama yang berpusat pada middle-tier.
30
Gambar 2. 18 Three-tier Architecture Client-server sendiri memiliki kelebihan dan kekurangan masingmasing. Berikut ini adalah tabel kelebihan dan kekurangan kedua sistem:
Tabel 2. 3 Tabel Kelebihan dan Kekurangan Client-Side Server Client Side
Kelebihan
Kekurangan
Server Side
Distribusi proses cepat karena proses langsung terjadi pada browser
Keamanan source code terjamin
Umpan balik bagi pengguna menjadi cepat karena sedikitnya komunikasi dengan server
Aplikasi tidak bergantung kepada browser dimana aplikasi dieksekusi
Aplikasi bergantung kepada browser dimana aplikasi dieksekusi
Sulit dalam melakukan implementasinya
Source code dapat dilihat dengan mudah dari browser
Tidak memiliki kontrol langsung atas antarmuka pengguna
31
Kekurangan
dan
kelebihan
tersebut
bisa
menjadi
bahan
pertimbangan untuk memilih sistem proses yang sesuai dengan rancangan web database yang telah dibuat. 2.3
Prototipe Prototipe pada dasarnya adalah sebuah desain output dari sebuah aplikasi, di mana output itu sendiri adalah yang akan merepresentasikan informasi ke system user. Prototipe dapat berupa tiruan sederhana yang dihasilkan oleh komputer dengan data sembarang atau dihasilkan dari prorotipe database seperti Microsoft Access (Whitten, 2004, p584). Isi dari prototipe tidak mencakup keseluruhan fungsi dari versi akhir sistem atau aplikasi. Selain itu, prototipe hanya mengandung fitur-fitur utama dari sistem dan tidak mengandung fitur-fitur pendukung seperti fitur keamanan yang akan ada di versi akhir sistem. Tujuan utama pembuatan prototipe adalah memperkenankan pengguna untuk mencoba menggunakan prototipe (Connolly, 2010, p333). Hal tersebut dilakukan, diantaranya agar pengguna dapat: 1.
Mengidentifikasi fitur – fitur yang ada dalam sistem.
2.
Menyarankan perbaikan atau bahkan fitur baru untuk sistem.
Dengan demikian user requirements menjadi jelas, bagi pengguna maupun pengembang. Selain itu sistem juga dapat dievaluasi kelayakannya. Terdapat dua tipe strategi pembuatan prototipe. Requirements prototyping akan
dibuang
setelah
berhasil
merepresentasikan
sistem
yang
akan
32 diimplementasi. Evolutionary prototyping bertujuan sama dengan requirements prototyping, hanya saja prototipe tidak akan dibuang melainkan akan dikembangkan lebih lanjut untuk menjadi sistem yang bekerja penuh. 2.4
PHP PHP adalah bahasa scripting bertipe server-side, lintas platform dan HTML embedded (Cullen, 2002). PHP memungkinkan pengembang untuk menempatkan elemen-elemen program dalam teks HTML. Dengan metode ini HTML standart dapat ditulis seperti biasa sementara konten dinamis dihasilkan oleh scripting language. PHP adalah bahasa scripting open source yang memang didesain khusus untuk membuat aplikasi web dinamis. Pada awalnya PHP merupakan singkatan dari Personal Home Page namun kemudian kini berganti menjadi PHP: Hypertext Preprocessor. PHP dapat menjalankan hampir semua tugas yang dapat dikerjakan oleh bahasa pemrograman seperti Active Server Pages (ASP), ColdFusion, Java Server Pages (JSP). Dengan kata lain PHP merupakan teknologi yang menyerupai ASP, JSP dan ColdFusion. File PHP memiliki tag khusus dan dapat dibuat menggunakan text editor apapun. Berikut adalah contoh script sederhana dari PHP:
33
Gambar 2. 19 Contoh Script PHP Menurut Zeev Suraski dalam artikel yang dibuat oleh Sharon Machlis (2002), PHP memiliki satu kekurangan. Kapabilitas PHP dalam pemrograman berbasis objek jika dibandingkan dengan Java misalnya, masih tidak sebaik Java. Hal ini membuat PHP sulit untuk digunakan dalam membuat aplikasi yang sangat besar skalanya.
