BAB 2 LANDASAN TEORI. database system, seperti yang diungkapkan Leitheiser dan March (1996).

Transkripsi

1 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

2 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 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

3 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 UserID Username TransDate ProductID ProductName Qty T01 U01 User P0001 Product01 1 P0004 Product04 2 T02 U02 User P0002 Product02 3 T03 U03 User P0002 Product02 4 P0003 Product03 1 T04 U02 User P0003 Product03 6 anomali data: Dalam tabel tersebut ada kemungkinan terjadi tiga macam 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.

4 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 User P0001 Product01 1 T01 U01 User P0004 Product04 2 T02 U02 User P0002 Product02 3 T03 U03 User P0002 Product02 4

5 11 T03 U03 User P0003 Product03 1 T04 U02 User 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

6 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

7 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.

8 14 A E G A D B B E C F Keterangan: A: TransID D:TransDate G: Qty B: UserID E: ProductID C: Username F: ProductName Gambar 2. 5 Functional Dependency 3NF Tabel Request 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.

9 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

10 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

11 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).

12 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 Contoh Generalisasi/Spesialisasi Gambar Contoh Entity Relationship 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,

13 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 Contoh Conceptual Data Model

14 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 Contoh Logical Data Model

15 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 Database Lifecycle Database lifecyle merupakan tahapan dalam merancang suatu database system (Connoly, 2010, p311). Siklus hidup database digambarkan seperti berikut ini:

16 22 1. Database Planning Gambar Database Lifecycle (Connolly, p314) 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.

17 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 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

18 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

19 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.

20 26 Gambar Contoh Conceptual Model untuk Halaman Web 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:

21 27 HomePage UNIQUE Stationary: LIST-OF Barang.Nama: STRING Request: LIST-OF Request: Permintaan.No: STRING Request Stationary: Permintaan.No: STRING Permintaan.Tanggal: DATE Permintaan.Jumlah: Integer Stationary Barang.No: STRING Barang.Nama: STRING Stok: Integer Update: Update Stationary : STRING Insert: Insert Stationary : STRING Insert Barang.No: Barang.Nama: Stok: STRING STRING Integer Update Barang.No: Barang.Nama: Stok: STRING STRING Integer Gambar Contoh Representasi Grafis Logical Web Pages Schemas 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:

22 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 aspek dinamis, sistem database atau menyediakan antarmuka untuk 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.

23 29 Gambar 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.

24 30 Gambar 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 Kelebihan Kekurangan Client Side Distribusi proses cepat karena proses langsung terjadi pada browser Umpan balik bagi pengguna menjadi cepat karena sedikitnya komunikasi dengan server Aplikasi bergantung kepada browser dimana aplikasi dieksekusi Source code dapat dilihat dengan mudah dari browser Server Side Keamanan source code terjamin Aplikasi tidak bergantung kepada browser dimana aplikasi dieksekusi Sulit dalam melakukan implementasinya Tidak memiliki kontrol langsung atas antarmuka pengguna

25 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

26 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:

27 33 Gambar 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.