7
BAB 2
LANDASAN TEORI
2.1 Teori-teori Umum
2.1.1 Pengertian Data
Data adalah fakta-fakta atau deskripsi dari sesuatu, peristiwa,
aktivitas, dan transaksi yang ditangkap, direkam, disimpan, dan
dikelompokkan, tetapi belum tersusun sehingga memiliki suatu makna.
(Turban, 2003, p15)
Menurut Hoffer, Prescott, dan McFadden (2005, p5), data adalah
representasi dari objek- objek dan kejadian yang disimpan yang memiliki
makna dan kepentingan di dalam lingkungan user.
2.1.2 Pengertian Basis Data
Menurut Connolly dan Begg(2005, p15), basis data merupakan
kumpulan data logikal yang saling berhubungan, dan deskripsi dari sebuah
data, dibuat untuk memenuhi kebutuhan informasi dalam sebuah organisasi.
Basis data menjadi suatu bagian penting dari perusahaan untuk
menyimpan informasi-informasi yang diinginkan perusahaan tersebut.
Menurut W.H. Inmon (2002, p388), basis data adalah koleksi data
yang saling berkaitan sesuai dengan skemanya, basis data juga dapat
melayani satu atau banyak aplikasi.
8
2.1.3.1 Perancangan Basis Data
Menurut Connolly dan Begg (2005, p437), langkah-langkah dalam
perancangan basis data diantaranya :
2.1.3.1 Perancangan basis data konseptual
Perancangan basis data konseptual adalah proses
membangun sebuah model data yang digunakan di dalam
perusahaan, bebas dari segala pertimbangan fisik.(Connolly dan
Begg, 2005, p439)
Tahap-tahap dalam perancangan basis data konseptual
diantaranya (Connolly dan Begg, 2005, p442) :
Langkah 1 : Membangun model data konseptual
Tujuannya adalah untuk membangun model data konseptual dari
kebutuhan data dalam perusahaan. Tahapan-tahapan dari
membangun model data konseptual diantaranya :
Mengidentifikasikan tipe entitas
Tujuannya untuk mengidentifikasikan tipe entitas yang
dibutuhkan.
Gambar 2.1 Kamus Data Entity
(Connolly dan Begg, 2005, p444)
9
Mengidentifikasikan tipe relasi
Tujuannya untuk mengidentifikasikan relasi yang
penting yang ada diantara tipe-tipe entitas.
Gambar 2.2 Kamus Data Relationship
(Connolly dan Begg, 2005, p447)
Mengidentifikasikan dan mengasosiasikan atribut dengan entitas atau tipe relasi
Tujuannya untuk mengasosiasikan atribut dengan tipe-
tipe entitas atau relasi yang tepat.
Menentukan domain atribut
Tujuannya untuk menentukan domain dari atribut di
dalam model data konseptual lokal.
Menentukan atribut-atribut candidate, primary, dan alternate key
Tujuannya untuk mengidentifikasikan candidate key dari
setiap tipe entitas dan jika ada lebih dari 1 candidate key,
salah satu akan terpilih menjadi primary key dan yang lain
menjadi alternate key.
10
Primary key adalah candidate key yang dipilih untuk
secara unik mengidentifikasikan suatu tipe entitas.(Connolly
dan Begg, 2005, p451)
Candidate key adalah kumpulan minimal dari atribut
yang secara unik mengidentifikasikan setiap tipe
entitas.(Connolly dan Begg, 2005, p451)
Untuk memilih sebuah primary key dari antara candidate
key yang ada maka sebaiknya menggunakan tahapan-tahapan
di bawah ini :
• Candidate key dengan satu set atribut yang paling sedikit.
• Candidate key yang paling sedikit mempunyai nilai yang
sering berubah.
• Candidate key yang memiliki karakter yang paling sedikit.
• Candidate key dengan nilai maksimum yang paling kecil.
• Candidate key yang paling mudah digunakan dari sudut
pandang user.
1.6 Mempertimbangkan penggunaan konsep enhanced modeling
(optional)
Tujuannya untuk mempertimbangkan penggunaan
konsep enhanced modeling seperti spesialisasi/generalisasi,
agregasi, dan komposisi.
1.7 Memeriksa model untuk redundansi
Tujuannya untuk memeriksa adanya redundansi di
11
dalam model.
Dua aktivitas yang ada di dalam tahapan ini adalah :
• Memeriksa kembali one-to-one(1:1) relationship
Dalam mengidentifikasikan entitas kita mungkin telah
mengidentifikasikan dua entitas yang merepresentasikan
objek yang sama di perusahaan.
• Menghapus relationship yang berlebihan
Sebuah relationship disebut berlebihan atau redundant
bila informasi yang sama dapat diperoleh melalui
relationship yang lain.
1.8 Memvalidasi model konseptual dengan transaksi user
Tujuannya untuk memastikan model konseptual
mendukung kebutuhan transaksi.
Ada dua pendekatan yang dapat memastikan bahwa
model data konseptual mendukung kebutuhan transaksi :
• Menjelaskan transaksi tersebut
Memeriksa semua informasi yang ada (entity, relationship,
dan semua atribut) yang dibutuhkan oleh setiap transaksi
yang disediakan oleh model, dengan mendokumentasikan
sebuah deskripsi setiap kebutuhan transaksi.
• Menggunakan jalur transaksi
Pendekatan kedua ini untuk memvalidasikan model data
dengan transaksi yang dibutuhkan.
12
1.9 Mengkaji ulang model data konseptual dengan user
Tujuannya untuk mengkaji ulang model data konseptual
dengan user untuk memastikan bahwa mereka akan
mempertimbangkan model tersebut menjadi perwakilan yang
sebenarnya dari kebutuhan data dalam perusahaan.
2.1.3.2 Perancangan basis data logikal
Perancangan basis data logikal adalah proses membangun
sebuah model dari data yang digunakan oleh perusahaan yang
berdasar pada data model yang spesifik, tetapi tidak terikat pada
DBMS tertentu dan pertimbangan fisikal lainnya.(Connolly dan
Begg, 2005, p439)
Langkah 2 : Membangun dan memvalidasi model data logikal
Tujuannya untuk menerjemahkan model data konseptual
menjadi model data logikal dan kemudian untuk memvalidasi
model ini untuk memeriksa bahwa model tersebut benar secara
struktural dan dapat digunakan untuk mendukung transaksi yang
dibutuhkan. Tahapan-tahapan dari membangun model data logikal
diantaranya :
2.1 Menciptakan relasi untuk model data logikal
Tujuannya untuk menciptakan hubungan atau relasi untuk
model data logikal untuk mewakili entitas-entitas, hubungan-
hubungan, dan atribut-atribut yang sudah diidentifikasi.
13
Pendeskripsian bagaimana relasi dapat diturunkan dari
struktur data model yang ada, antara lain :
- tipe strong entity
- tipe weak entity
- tipe relasi binary one-to-many (1:*)
- tipe relasi binary one-to-one (1:1)
Terdiri dari :
1. mandatory participation on both sides of 1:1
relationship
2. mandatory participation on one side of 1:1 relationship
3. optional participation on both sides of 1:1 relationship
- tipe relasi rekursif one-to-one (1:1)
- tipe relasi superclass/subclass
- tipe relasi binary many-to-many
- tipe relasi kompleks
- attribut multi-value
2.2 Memvalidasi hubungan menggunakan normalisasi
Tujuannya untuk memvalidasi hubungan di dalam
model data logikal menggunakan normalisasi.
Tahapan dari normalisasi antara lain :
• First Normal Form (1NF), menghilangkan grup yang
berulang.
14
• Second Normal Forn (2NF), menghilangkan partial
dependencies atau ketergantungan parsial pada
primary key.
• Third Normal Form (3NF), menghilangkan transitive
dependencies atau ketergantungan transitif pada
primary key.
2.3 Memvalidasi hubungan dengan transaksi user
Tujuannya untuk memastikan bahwa hubungan di dalam
model data logikal mendukung kebutuhan transaksi (biasanya
penggambaran dalam bentuk view).
2.4 Memeriksa integrity constraint
Tujuannya untuk memeriksa integrity constraint yang
diwakili di dalam data model logikal.
Beberapa tipe dari integrity constraint adalah sebagai
berikut :
• Required data
Beberapa atribut harus selalu berisi data yang resmi
sehingga atribut tersebut tidak diperbolehkan berupa
null.
• Attribute domain constraint
Setiap atribut mempunyai domain yang merupakan
sekumpulan nilai yang sah.
15
• Multiplicity
Multiplicity mewakili constraint yang ditempatkan
pada hubungan diantara data di dalam basis data.
• Entity integrity
Primary key di dalam sebuah entitas tidak dapat
menerima null.
• Referential integrity
Jika foreign key berisi nilai maka nilai tersebut harus
menunjuk kepada tuple yang ada
• General constraint
Update pada entitas akan dikontrol oleh constraint
yang menentukan transaksi yang “real world” dimana
diwakili oleh update itu sendiri.
• Document all integrity constraint
Mendokumentasikan semua integrity constraint di
dalam kamus data untuk pertimbangan selama desain
fisikal.
2.5 Mengkaji ulang model data logikal dengan user
Tujuannya untuk meninjau ulang model data logikal
dengan user untuk memastikan bahwa mereka
mempertimbangkan model tersebut untuk menjadi
representasi nyata dari kebutuhan data di dalam sebuah
perusahaan.
16
2.6 Menggabungkan data model logikal menjadi model global
(optional)
Tujuannya untuk menggabungkan model data logikal
menjadi model data global single yang mewakili semua user
view dari basis data.
2.7 Memeriksa pertumbuhan lebih lanjut
Tujuannya untuk menentukan apakah ada perubahan
yang signifikan untuk masa depan yang sudah dapat diduga
sebelumnya dan menilai apakah model data logikal dapat
mengakomodasi perubahan ini.
2.1.3.3 Perancangan basis data fisikal
Perancangan basis data fisikal adalah proses memproduksi
sebuah deskripsi dari implementasi dari basis data pada secondary
storage, yang juga akan mendeskripsikan dasar dari suatu relasi,
organisasi file, dan index yang digunakan untuk mencapai akses
efisien menuju ke data dan beberapa batasan-batasan integritas
serta ukuran keamanan.(Connolly dan Begg, 2005, p496)
Langkah 3 : Menerjemahkan model data logikal ke dalam
target DBMS
Tujuannya untuk memproduksi skema relasi basis data dari
model data logikal yang dapat diimplementasikan di dalam target
DBMS.
3.1 Mendesain relasi dasar
17
Tujuan dari langkah ini adalah untuk memutuskan
bagaimana merepresentasikan relasi dasar yang
diidentifikasikan di dalam model data logikal ke dalam target
DBMS.
Untuk setiap relasi yang diidentifikasi pada model data
logikal global, definisinya terdiri dari:
• Nama relasi
• Suatu list untuk atribut yang sederhana
• Primary key, alternate key, dan foreign key
• Suatu daftar dari atribut turunan dan bagaimana
pembuatannya.
• Batasan integrasi untuk setiap foreign key yang
diidentifikasi.
Dari kamus data, dari setiap atributnya dapat diketahui :
• Domain atribut tersebut, yang terdiri dari tipe data,
panjang, dan berbagai batasan dalam domain.
• Sebuah optional nilai default untuk atribut.
• Atribut boleh bernilai null.
• Atribut diperoleh dan bagaimana atribut tersebut
dikomputerisasi.
18
3.2 Merancang representasi dari data turunan
Tujuannya adalah untuk memutuskan bagaimana untuk
merepresentasikan berbagai data turunan pada model data
logikal di dalam DBMS.
3.3 Merancang batasan general
Tujuannya adalah untuk merancang batasan general
untuk DBMS yang digunakan.
Langkah 4 : Merancang organisasi file dan index
Tujuannya untuk menentukan organisasi file yang optimal
untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk
mencapai performance yang dapat diterima, dimana setiap relasi
dan tuple akan disimpan di dalam penyimpanan kedua (secondary
storage).
4.1 Menganalisis transaksi
Tujuannya adalah untuk memahami fungsionalitas dari
transaksi tersebut yang akan berjalan di dalam basis data dan
untuk menganalisis transaksi yang penting.
Dalam menganalisa transaksi, dapat diidentifikasi
kriteria performansi sebagai berikut :
• Transaksi yang sering digunakan dan akan berdampak
besar terhadap keseluruhan performance.
• Transaksi yang merupakan operasi bisnis yang bersifat
kritis.
19
• Durasi waktu dalam hari/minggu dimana akan ada
permintaan yang tinggi pada basis data (peak load).
Untuk fokus ke dalam area yang mungkin akan
bermasalah, maka salah satu cara untuk memprosesnya antara
lain :
• Petakan semua jalur transaksi ke relasi
• Menentukan relasi mana yang lebih sering diakses oleh
transaksi tersebut.
• Menganalisis penggunaan data dari transaksi yang dipilih
dimana transaksi tersebut terlibat dengan relasi yang
dimaksud.
4.2 Memilih organisasi file
Tujuannya untuk menentukan organisasi file yang efektif
untuk setiap relasi dasar. Beberapa tipe organisasi file adalah
sebagai berikut :
• Heap
• Hash
• Indexed Sequential Office Access Method (ISAM)
• B+-tree
• Cluster
4.3 Memilih index
Tujuannya untuk menentukan apakah dengan menambah
indeks akan meningkatkan performa sistem. Biasanya,
20
pemilihan atribut untuk ordering atau clustering tuple adalah
sebagai berikut :
• Sebuah atribut yang dipake paling sering untuk operasi
gabungan, hal ini akan membuat operasi penggabungan
menjadi lebih efisien.
• Sebuah atribut yang digunakan lebih sering untuk
mengakses tuple di dalam relasi yang ada.
4.4 Memperkirakan kapasitas disk yang dibutuhkan
Tujuannya untuk memperkirakan kira-kira berapa besar
kapasitas disk yang akan dibutuhkan oleh basis data.
Langkah 5 : Merancang user views
Tujuannya adalah untuk merancang user view yang
diidentifikasikan selama tahap pengumpulan dan analisa
kebutuhan dari sistem siklus pengembangan basis data.
Langkah 6 : Merancang mekanisme keamanan
Tujuannya adalah untuk merancang mekanisme keamanan
untuk basis data yang dispesifikasikan berdasarkan user selama
tahapan requirements and collection pada siklus pengembangan
sistem basis data.
2.1.4 Siklus Pengembangan Sistem Basis Data
Menurut Connolly dan Begg(2005, p283), sistem basis data
merupakan komponen pokok dalam sistem informasi dari organisasi yang
21
besar, siklus pengembangan basis data tak terpisahkan dengan siklus sistem
informasi.
Aktivitas-aktivitas yang ada dalam siklus pengembangan basis data
diantaranya :
• Database Planning
Merencanakan bagaimana bagian-bagian dalam siklus dapat
direalisasikan dengan efektif dan efisien.
• System Definition
Menspesifikasikan jangkauan dan batasan dari sistem basis data, meliputi
major user views, user itu sendiri, dan area aplikasi.
• Requirements Collection and Analysis
Mengumpulkan dan menganalisis kebutuhan untuk sistem basis data baru.
• Database Design
Merancang desain konseptual, logikal, dan fisikal dari basis data.
• DBMS Selection (optional)
Memilih DBMS yang sesuai dengan sistem basis data.
• Application Design
Merancang antarmuka user dan program aplikasi yang menggunakan dan
memproses basis data.
• Prototyping (optional)
Membangun model kerja dari sistem basis data dimana mengizinkan
perancang atau user untuk memvisualisasikan dan mengevaluasi
bagaimana sistem akhir akan terlihat dan berfungsi.
22
• Implementation
Menciptakan definisi basis data fisikal dan program aplikasi.
• Data Conversion and Loading
Memuat data dari sistem lama ke sistem baru dan, jika memungkinkan,
mengubah beberapa aplikasi yang sudah ada untuk dijalankan pada basis
data baru.
• Testing
Sistem basis data diuji terhadap kesalahan-kesalahan dan memvalidasi
dengan kebutuhan yang diinginkan user.
• Operational and Maintenance
Sistem basis data diimplementasikan secara penuh. Sistem ini diawasi
dan dipelihara secara terus menerus. Jika diperlukan, kebutuhan baru
akan dimasukkan ke dalam sistem basis data melalui tahapan siklus
sebelumnya.
Berikut ini adalah siklus hidup aplikasi basis data :
23
Gambar 2.3 Siklus Hidup Aplikasi Basis Data
(Connolly dan Begg, 2005, p284)
24
2.1.5 Database Management System (DBMS)
Menurut Connolly dan Begg (2005, p16), DBMS adalah sebuah
sistem perangkat lunak yang memungkinkan user untuk mendefinisikan,
menciptakan, memelihara, dan mengontrol akses terhadap sistem basis data.
Menurut Gerald V. Post (2005, p2), DBMS adalah perangkat lunak
yang mendefinisikan basis data, penyimpanan data, mendukung bahasa
query, menghasilkan laporan, dan membuat layar untuk memasukkan data.
Komponen-komponen DBMS diantaranya :
• Hardware
DBMS dan aplikasi membutuhkan hardware untuk berjalan.
• Software
Komponen software terdiri dari perangkat lunak DBMS itu sendiri dan
program aplikasi, bersama dengan sistem operasi, meliputi perangkat
lunak jaringan jika DBMS digunakan dalam jaringan.
• Data
Data boleh jadi merupakan komponen yang paling penting dalam
lingkungan DBMS.
• Procedure
Prosedur mengacu pada instruksi dan aturan yang menentukan desain dan
kegunaan dari basis data.
• People
Komponen akhir ialah orang yang terlibat dengan sistem.
25
Gambar 2.4 Komponen-komponen dalam lingkungan DBMS
(Connolly dan Begg, 2005, p19)
2.1.5.1 Fungsi DBMS
Menurut Connolly dan Begg (2005, p48), fungsi-fungsi
dari DBMS diantaranya :
1. Data storage, retrieval, and update
Sebuah DBMS harus melengkapi user dengan kemampuan
untuk menyimpan, mendapatkan kembali, dan membaharui
data dalam basis data.
2. A user-accessible catalog
Sebuah DBMS harus dilengkapi dengan sebuah katalog yang
mendeskripsikan data item yang tersimpan dan yang dapat
diakses user.
3. Transaction support
Sebuah DBMS harus dilengkapi sebuah mekanisme yang akan
menjamin baik seluruh update yang berhubungan dengan
sebuah transaksi yang dapat dilakukan atau yang tidak
dilakukan.
26
4. Concurrency control services
Sebuah DBMS harus dilengkapi sebuah mekanisme untuk
memastikan basis data terupdate secara benar ketika banyak
user melakukan update secara bersamaan.
5. Recovery services
Sebuah DBMS harus dilengkapi sebuah mekanisme untuk
memperbaiki basis data saat basis data mengalami kerusakan.
6. Authorization services
Sebuah DBMS harus dilengkapi sebuah mekanisme untuk
memastikan bahwa hanya user yang mempunyai wewenang
yang dapat mengakses basis data.
7. Support for data communication
Sebuah DBMS harus dapat berintegrasi dengan software
komunikasi.
8. Integrity services
Sebuah DBMS harus dilengkapi dengan sebuah cara untuk
memastikan bahwa data dalam basis data dan perubahan
terhadap data mengikuti aturan-aturan tertentu.
9. Services to promote data independence
Sebuah DBMS harus mencakup fasilitas untuk mendukung
ketidaktergantungan program dari struktur aktual dari basis
data.
10. Utility services
Sebuah DBMS harus menyediakan sebuah set untuk layanan
27
kegunaan.
2.1.5.2 Keuntungan DBMS
Keuntungan dari DBMS antara lain :
1. Kontrol terhadap redundansi data
2. Data yang konsisten
3. Semakin banyak informasi yang didapat dari data yang sama
4. Data yang dibagikan (shared data)
5. Menambah integritas data
6. Menambah keamanan data
7. Penetapan standarisasi
8. Menyeimbangkan konflik kebutuhan
9. Memperbaiki pengaksesan data dan hasilnya
10. Menambah produktivitas
11. Memperbaiki pemeliharaan data melalui data independence
2.1.5.3 Kerugian DBMS
Kerugian dari DBMS antara lain :
1. Kompleksitas
2. Size / ukuran
3. Biaya dari suatu DBMS
4. Biaya penambahan perangkat keras
28
2.1.5.4 Fasilitas-fasilitas DBMS
Menurut Connolly dan Begg (2005, p16), fasilitas-fasilitas
dalam DBMS adalah sebagai berikut :
o Memberikan izin kepada user untuk mendefinisikan basis data,
biasanya melalui Data Definition Language (DDL). DDL
memperbolehkan user untuk menspesifikasi tipe-tipe, struktur dan
constraint dari data yang akan disimpan di dalam basis data.
o Memperbolehkan user untuk menambah data, mengubah data,
menghapus data, dan menemukan data dari basis data, biasanya
melalui Data Manipulation Languange (DML). Query Language
merupakan fasilitas yang mempunyai tempat penyimpanan untuk
semua data dan deskripsi data. Bahasa query yang paling umum
digunakan adalah Structured Query Language (SQL).
o Selain itu juga menyediakan akses kontrol ke basis data, yang
antara lain terdiri dari :
- Sistem Keamanan (Security System)
Untuk mencegah user yang tidak berwenang untuk mengakses
basis data.
- Sistem Integrasi (Integrity System)
Untuk menjaga konsistensi data.
- Sistem Control (Concurrency Control System)
Mengijinkan banyak user untuk mengakses basis data.
- Sistem Kontrol Pengembalian (Recovery Control System)
29
Untuk memperbaiki data jika sebelumnya terjadi kerusakan
pada software maupun hardware.
- Katalog yang dapat diakses user (User Accessible Catalog)
Berisi deskripsi dari sebuah data di dalam basis data.
2.1.5.5 Data Definition Language (DDL)
Definisi dari Data Definition Language menurut Connolly
dan Begg (2005, p40) adalah suatu bahasa yang memperbolehkan
Database Administrator (DBA) atau user untuk mendefinisikan
entitas, atribut, dan relationship yang dibutuhkan oleh suatu aplikasi,
bersama dengan beberapa integritas yang berhubungan dan security
constraint.
2.1.5.6 Data Manipulation Language (DML)
Definisi dari Data Manipulation Language menurut
Connolly dan Begg (2005, p40) adalah suatu bahasa yang
menyediakan satu set operasi yang digunakan untuk mendukung
operasi manipulasi data dasar yang ada di dalam basis data.
Operasi dari manipulasi data biasanya meliputi :
1. Menambahkan data baru di dalam basis data
2. Memodifikasi data yang tersimpan di dalam basis data
3. Memanggil data yang terdapat di dalam basis data
4. Penghapusan data dari basis data
30
Ada 2 tipe dari DML yaitu :
1. Procedural DML
Suatu bahasa yang mengijinkan user untuk memberitahukan
kepada sistem data apa saja yang dibutuhkan dan bagaimana
cara yang tepat untuk memanggil data tersebut.
2. Non Procedural DML
Suatu bahasa yang mengijinkan user untuk menentukan data apa
saja yang dibutuhkan daripada bagaimana data tersebut
dikembalikan.
2.1.6 Entity Relationship Diagram (ERD)
2.1.6.1 Pengertian ERD
Menurut Hoffer, Prescott, dan McFadden (2005, p93),
ERD (Entity Relationship Diagram) adalah representasi grafis
dari entity-relationship model. Entity Relationship Model (E-R
Model) adalah representasi logikal dari data untuk sebuah
organisasi atau untuk sebuah area bisnis.
Menurut Whitten (2004, p295), ERD adalah model data
yang menggunakan beberapa notasi untuk menggambarkan data
dalam hubungan antar entity dan relationship yang digambarkan
oleh data tersebut.
Menurut Rob, Coronel (2002, p815), ERD adalah diagram
yang menggambarkan entity, atribut, dan relasi dalam ERM
(Entity Relational Model)
31
2.1.6.2 Komponen ERD
1. Entitas (Entity)
Menurut Rob, Coronel (2002, p814), entitas adalah
sesuatu yang digunakan untuk tempat penyimpanan data
biasanya data-data tersebut berupa orang, tempat, objek,
kejadian atau konsep.
Strong Entity adalah entitas yang keberadaannya tidak
bergantung pada entitas lain.
Gambar 2.5 Simbol Strong Entity
Weak Entity adalah entitas yang keberadaannya bergantung
pada entitas lain.
Gambar 2.6 Simbol Weak Entity
Composite Entity adalah entitas yang dihasilkan dari
relationship many to many.
Entity
Entity
CLASS STUDENT Enrolls in
32
Gambar 2.7 Contoh Composite Entity
2. Relasi (Relationship)
Menurut Rob,Coronel (2002, p124), relasi adalah
asosiasi hubungan antara entitas. Entitas yang berhubungan
dalam relasi disebut participants.
Konektivitas antar relasi, antara lain:
a. Relasi 1:1
Gambar 2.8 Contoh Relasi 1:1
b. Relasi 1:M
teaches
Gambar 2.9 Contoh Relasi 1:M
User Password has
STUDENT Stu_Num Stu_Name
Is found in
Is written in
ENROLL Stu_Num (FK) Class_ID (FK) Enroll Grade
CLASS Class_ID Class_Time Room_Code CRS_Code
Lecturer Class
33
c. Relasi M:M
Gambar 2.10 Contoh Relasi M:M
Relationship Participants terdiri dari 2 jenis, antara lain:
a. Optional
Entitas yang ada tidak memerlukan occurrence yang
sama di dalam entitas yang berhubungan. Ditunjukkan
dengan menggambar sebuah lingkaran kecil di salah
satu sisi dari entitas optional di dalam ERD.
Gambar 2.11 Contoh Optional Relationship
b. Mandatory
Entitas memerlukan occurrence yang sama di dalam
entitas yang saling berhubungan. Jika tidak ada simbol
optional yang ditunjukkan di dalam ERD, maka itu
adalah mandatory.
PROFESSOR CLASS teaches
Student Class takes
34
Gambar 2.12 Contoh Mandatory Relationship
Derajat relasi ada 3 yaitu :
a. Unary
Merupakan single entitas, bersifat rekursif, dan terjadi
pada entitas yang sama.
Gambar 2.13 Contoh Unary Relationship
b. Binary
Merupakan 2 entitas yang saling berhubungan.
Gambar 2.14 Contoh Binary Relationship
c. Ternary
Merupakan 3 entitas yang saling berhubungan.
PROFESSOR CLASS teaches
COURSE generates CLASS
COURSE requires
35
Gambar 2.15 Contoh Ternary Relationship
3. Atribut (Attribute)
Menurut Rob & Coronel (2002, p808), atribut adalah
karakter dari sebuah entitas atau objek. Atribut memiliki nama
dan tipe data.
a. Simple Attribute
Menurut Rob,Coronel (2005,p121), Simple Attribute
adalah atribut yang tidak dapat dibagi lagi.
Contohnya umur, jenis kelamin.
Gambar 2.16 Simbol Atribut
Contributor Recipient
Fund
Receives from
Is distributed in
Contributes to
CFR
STUDENT Stu_Name Stu_Initial Stu_Email
36
b. Composite Attribute
Menurut Rob,Coronel (2002,p121), Composite Attribute
adalah atribut yang dapat dibagi menjadi atribut tambahan.
Contohnya atribut Alamat dapat dibagi menjadi jalan, kota,
propinsi, dan kode pos.
c. Single-valued Attribute
Menurut Rob,Coronel (2002,p121), Single-valued
Attribute adalah atribut yang hanya dapat memiliki 1 nilai.
Contohnya 1 orang hanya dapat memiliki 1 nomor KTP.
d. Multi-valued Attribute
Menurut Rob,Coronel (2002,p121), Multi-valued Attribute
adalah atribut yang dapat memiliki banyak nilai.
Contohnya seseorang dapat memiliki banyak nomor
telepon (HP, kantor, rumah).
e. Derived Attribute
Menurut Rob,Coronel (2002,p123), Derived Attribute
tidak butuh disimpan secara fisikal di dalam database.
Derived Attribute adalah atribut yang memiliki nilai yang
merupakan nilai turunan dari atribut lainnya. Contohnya
atribut EMP_AGE bisa didapatkan dari atribut lain yaitu
dari tanggal sekarang dikurangi dengan nilai EMP_DOB
kemudian dibagi dengan 365 hari.
37
2.1.6.3 Contoh ERD
EMPLOYEE
EMP_NUMEMP_LNAMEEMP_FNAMEEMP_INITIALEMP_E_MAIL
PROFESSOR
EMP_NUM (FK)EMP_SPECIALITYEMP_RANKDEPT_CODE (FK)
SCHOOL
SCHOOL_CODESCHOOL_NAMEEMP_NUM (FK)
DEPARTMENT
DEPT_CODEDEPT_NAMESCHOOL_CODE (FK)EMP_NUM (FK)
COURSE
CRS_CODECRS_TITLECRS_DESCRIPTIONCRS_CREDITSDEPT_CODE (FK)
CLASS
CLASS_CODECLASS_TIMEEMP_NUM (FK)ROOM_CODE (FK)CRS_CODE (FK)
ROOM
ROOM_CODEROOM_TYPEBLDG_CODE (FK)
BUILDING
BLDG_CODEBLDG_LOCATION
ENROLL
CLASS_CODE (FK)STU_NUM (FK)ENROLL_DATEENROLL_GRADE
STUDENT
STU_NUMSTU_LNAMESTU_FNAMESTU_INITIALSTU_E_MAILEMP_NUM (FK)DEPT_CODE (FK)
is a
is dean of
chairs
employshas
teaches
offers
generates
is used for
contains
advises
is written in
is found in
operates
Gambar 2.17 Contoh ERD
(Rob,Coronel, 2002, p159)
2.1.7 Data Flow Diagram (DFD)
Menurut Whitten (2004, p344), Data Flow Diagram adalah model
proses yang digunakan untuk menggambarkan aliran data yang melalui
sebuah sistem dan proses yang ditampilkan oleh sistem tersebut.
Ada 3 buah simbol dan 1 buah koneksi di dalam DFD :
- Sebuah bujur sangkar yang dibulatkan yang mewakili proses atau
pekerjaan yang sudah diselesaikan
38
- Sebuah persegi yang mewakili perantara eksternal-batas dari sebuah
sistem.
- Sebuah kotak yang terbuka mewakili penyimpanan data, yang kadang-
kadang disebut juga arsip atau basis data.
- Anak panah mewakili aliran data, atau input dan output, ke dan dari
proses.
2.1.7.1 Proses
Menurut Whitten (2004, p347), proses adalah pekerjaan
yang sedang berjalan, atau respon pada sebuah aliran data atau
kondisi yang akan datang. Sinonimnya adalah perubahan bentuk
atau transformasi.
Gambar 2.18 Simbol-Simbol dari proses
(Whitten, 2004, p 347)
2.1.7.2 Aliran Data atau Data Flow
Menurut Whitten (2004, p357), aliran data atau data flow
adalah sebuah aliran data mewakili sebuah input data ke dalam
proses atau output data (atau informasi) dari sebuah proses. Aliran
data ini juga digunakan untuk mewakili kreasi, pembacaan,
penghapusan, atau memperbaharui data di dalam sebuah arsip
atau basis data.
39
Gambar 2.19 Simbol dari data flow
(Whitten, 2004, p357)
2.1.7.3 External Agent
Menurut Whitten (2004, p363), external agent adalah
orang, unit organisasi, sistem, atau organisasi yang berinteraksi
dengan sebuah sistem.
Gambar 2.20 Simbol-Simbol dari external agent
(Whitten, 2004, p365)
2.1.7.4 Data Store
Data store adalah sebuah penyimpanan data-data. Data
store menyimpan data yang akan digunakan untuk masa
mendatang.
Gambar 2.21 Simbol-Simbol dari data store
(Whitten, 2004, p366 )
40
2.1.7.5 Contoh DFD
Gambar 2.22 Contoh DFD
(Whitten, 2004, p346)
2.1.7.6 Context DFD
Model proses yang digunakan untuk mendokumentasikan
ruang lingkup dari sebuah sistem. Disebut juga model
environmental. Sistem context DFD dibuat untuk membangun
inisialisasi ruang lingkup proyek.
41
Gambar 2.23 Contoh Context DFD
(Whitten, 2004, p373)
2.1.8 State Transition Diagram (STD)
2.1.8.1 Pengertian STD
Menurut Booch, Jacobson, dan Rumbaugh (2005,
p199/602), state transition diagram digunakan untuk
menunjukkan keadaan/state dari suatu kelas atau konteks, kondisi
atau keadaan yang menyebabkan peralihan dari suatu state ke
state yang lain, dan aksi yang mengakibatkan perubahan state.
State transition diagram digunakan untuk menyatakan sifat
dinamis dari sistem. Dua elemen pokok state transition diagram
adalah state dan state transition.
42
2.1.8.2 Komponen STD
1. State
State dari suatu objek menggambarkan hasil kumulatif
dari perilaku objek itu sendiri. (Booch, Jacobson, dan
Rumbaugh, 2005, p200)
2. State Transition
Event merupakan kejadian yang dapat menyebabkan
state sistem berubah. Perubahan state ini disebut state
transition. Setiap state transition menghubungkan dua state.
(Booch, Jacobson, dan Rumbaugh, 2005, p201)
Gambar 2.24 Simbol STD
Event [guard] / action
State Icon name actions
State Transition
Start
Stop
43
2.1.8.3 Contoh STD
Gambar 2.25 Contoh STD
( Booch, Jacobson, dan Rumbaugh, 2005, p203)
2.2 Teori – teori Pendukung
2.2.1 Information Technology Infrastructure Library (ITIL)
2.2.1.1 Pengertian ITIL
Menurut Cartlidge (2007, p8), Information Technology
Infrastructure Library (ITIL) adalah sebuah kerangka kerja atau
konsep yang menggambarkan praktek terbaik dalam manajemen
layanan teknologi informasi (IT). Information Technology
Idle
Daytime
Nighttime
Define Climate
Terminate Climate Sunset /
Light::off()
Sunrise / Light::on()
Temperature drop or rise / adjustTemperature()
Temperature drop or rise / adjustTemperature()
Terminate Climate
44
Infrastructure Library (ITIL) menyediakan sebuah kerangka kerja
untuk pengelolaan IT dan berfokus pada pengembangan dan
pengukuran yang terus menerus terhadap kualitas dari layanan IT
yang diberikan baik terhadap bisnis atau pelanggan. Fokus dari
ITIL sendiri ialah memberikan kontribusi dan keuntungan dalam
menjalankan teknik-teknik dan proses-proses pada organisasi.
Menurut Addy (2007, pXXXVIII), Information Technology
Infrastructure Library (ITIL) merupakan kumpulan dari petunjuk-
petunjuk yang dikembangkan oleh United Kingdom’s Office of
Government Commerce (OGC). Petunjuk-petunjuk ini, yang
diterbitkan ke dalam rangkaian buku menggambarkan proses-
proses yang terintegrasi, yang menyediakan pendekatan praktek
terbaik untuk mengelola layanan IT.
2.2.1.2 Sejarah ITIL
Menurut Addy (2007, pXXXVIII), Information Technology
Infrastructure Library (ITIL) pertama kali muncul pada akhir
tahun 80an. Central Computer and Telecommunication Agency
(CCTA) yang merupakan bagian dari departemen pemerintahan
Inggris, dengan biaya IT sebesar 8 miliar pound, mendapatkan
tekanan besar untuk dapat mengurangi biaya tersebut secara
signifikan. CCTA memutuskan efisiensi besar merupakan salah
satu cara potensial untuk mengurangi biaya tersebut. Akhirnya
mereka menciptakan sebuah lingkungan yang berfokus pada proses
45
dan efisiensi untuk pengembangan sebuah kerangka kerja yang
saat ini dikenal sebagai Information Technology Infrastructure
Library (ITIL).
Pada tahun 90an banyak perusahaan besar dan agen
pemerintahan di Eropa mulai mengadopsi kerangka kerja ITIL ini
sebagai dasar dalam operasional IT. ITIL mulai menyebar secara
luas dan dengan cepat menjadi standar de facto untuk manajemen
layanan IT.
Pada tahun 2001, kerangka kerja ITIL versi 2 diperkenalkan.
Revisi baru ini telah diperbarui dengan definisi dan terminology
yang lebih modern terutama dalam pengembangan Service
Delivery dan Service Support yang signifikan sehingga menjadi
ringkas dan dapat digunakan.
2.2.1.3 Tujuan ITIL
Tujuan Information Technology Infrastructure Library (ITIL)
adalah untuk menyediakan petunjuk untuk praktek terbaik dalam
manajemen layanan teknologi informasi. Ini mencakup pilihan
yang dapat diadopsi dan diadaptasi oleh organisasi berdasarkan
kebutuhan bisnisnya, keadaan, dan kedewasaan dari penyedia
layanan. (Sumber: Anonim1)
46
2.2.1.4 Keuntungan ITIL
Menurut Cartlidge (2007, p8), beberapa keuntungan dari
ITIL, antara lain:
- Meningkatkan kepuasan pengguna dan pelanggan terhadap
layanan IT
- Memperbaiki ketersediaan layanan, yang berpengaruh secara
langsung dalam meningkatkan keuntungan dan pendapatan
bisnis.
- Menghemat keuangan, dari pengurangan kerja, kehilangan
waktu
- Memperbaiki manajemen sumber daya dan kegunaan
- Memperbaiki pembuatan keputusan dan mengoptimalkan
resiko
- Memperbaiki waktu terhadap pasar untuk produk baru dan
layanan
2.2.1.5 Bagian-bagian ITIL
Dalam ITIL versi 2, bagian-bagian ITIL dikelompokkan
kedalam tujuh area, diantaranya:
- Service Delivery
Service Delivery berfokus pada layanan apa dalam bisnis yang
diperlukan provider dalam rangka untuk menyediakan dukungan
yang cukup kepada pelanggan. Service Delivery didalamnya
meliputi:
47
- Capacity Management
- Financial Management for IT Services
- Availability Management
- Service Level Management
- IT Continuity Management
- Customer Relationship Management
- Service Support
Service Support berfokus pada memastikan bahwa pelanggan
mempunyai akses untuk mendapatkan layanan yang tepat untuk
mendukung proses bisnis. Service Support didalamnya meliputi:
- Incident Management
- Problem Management
- Configuration Management
- Change Management
- Release Management
- Service Desk
- ICT Infrastructure Management
ICT Infrastructure Management meliputi proses-proses yang
ada dalam Service Delivery dan Service Support dimana lebih
berfokus pada isu teknikal.
- Security Management
Security Management berfokus pada pengelolaan keamanan
dalam manajamen layanan IT.
48
- Application Management
Application Management mempertimbangkan isu-isu dalam
pengelolaan aplikasi, mulai dari tahap produksi hingga
pengimplementasian aplikasi.
- Planning to implement Service Management
Planning to implement Service Management berfokus pada
perencanaan terhadap produk (software/hardware) apa yang
akan digunakan untuk mendukung kebutuhan layanan dalam
bisnis
- Project Management
Project Management berfokus pada bagaimana
memperkenalkan proses baru atau meningkatkan proses yang
sudah ada untuk mengantarkan atau mendukung layanan IT.
Gambar 2.26 Bagian-bagian dalam ITIL
(Sumber: Anonim4)
49
2.2.2 Change Management
2.2.2.1 Pengertian Change Management
Menurut Addy (2007, p186), Change Management
merupakan proses yang memungkinkan organisasi dalam
mengimplementasikan proses yang efektif dan efisien untuk
mengidentifikasikan, merencanakan, dan mengelola perubahan
terhadap infrastrukturnya. Change Management juga menyediakan
kepada pengguna, kemampuan untuk mengidentifikasi dan
mengurangi resiko terhadap perubahan tersebut sehingga
perubahan tersebut dapat diimplementasikan dengan kepercayaan.
Menurut Cartlidge (2007, p25), Change Management
merupakan proses yang memastikan bahwa perubahan-perubahan
yang ada dicatat, dievaluasi, disahkan, diprioritaskan, direncanakan,
diuji, diimplementasikan, didokumentasikan dan ditinjau dalam
cara yang terkontrol. Change management mengurangi kesalahan
pada perubahan layanan dan lebih cepat, lebih akurat dalam
implementasi perubahan, dan memberikan keuntungan lebih dalam
bisnis.
2.2.2.2 Tujuan Change Management
Menurut OGC (2007, p80), tujuan dari proses change
management adalah untuk memastikan bahwa:
- Metode dan prosedur yang baku telah digunakan untuk
penanganan yang tepat dan efisien terhadap semua perubahan
50
- Semua perubahan terhadap service assets dan configuration
items telah tersimpan dalam sistem configuration management
- Resiko bisnis secara keseluruhan telah dioptimalkan
2.2.2.3 Sasaran Change Management
Menurut OGC (2007, p80), sasaran dari proses change
management, antara lain:
- Memberi reaksi terhadap perubahan kebutuhan bisnis
pelanggan dengan meminimalkan nilai dan mengurangi insiden,
gangguan, dan pekerjaan berulang
- Memberi reaksi terhadap permintaan bisnis dan IT kepada
perubahan yang akan mensejajarkan layanan dengan kebutuhan
bisnis.
2.2.2.4 Langkah-langkah Change Management
Proses change management terdiri dari lima langkah:
a. Menyaring Requests for Change (RFCs)
Requests for changes perlu untuk ditinjau oleh tim
manajemen. Beberapa permintaan yang sederhana dapat
dikerjakan dengan mudah. Beberapa permintaan dapat berupa
duplikasi dari usaha. Jadi langkah pertama dari change
management adalah meninjau setiap permintaan perubahan dan
menyakinkan hanya perubahan yang berguna dan realistis yang
akan menjadi fokus sumber IT.
51
b. Memperkirakan dampak dari perubahan
Setelah kita memiliki daftar permintaan perubahan, kita
harus memperkirakan dan menilai keuntungan untuk perusahaan,
terutama berdasarkan pada strategi bisnis dari organisasi.
Prioritaskan perubahan sesuai dengan strategi dan kemudian
untuk memberikan gambaran yang penuh juga memperkirakan
dampak, biaya, dan keuntungan untuk setiap perubahan.
c. Mengesahkan perubahan
Karena kepentingan user turut serta dalam proses, maka
gunakan keahlian mereka dalam mengevaluasi dampak dari
perubahan. Change Advisory Board (CAB) harus memberikan
pengetahuan/wawasan kepada change manager sebelum
perubahan itu disetujui dan dijadwalkan. Sebuah forward
schedule of changes (FSC) harus dibuat setelah perubahan
disetujui.
d. Meninjau perubahan
Setelah perubahan telah dilakukan dan diimplementasikan,
tinjauan yang jujur dan terbuka akan menyampaikan apakah
perubahan berjalan baik atau tidak baik. Ini akan membawa
proses change management untuk perbaikan dengan segera.
e. Menutup RFC
Akhirnya user yang menyampaikan RFC mempunyai
kesempatan untuk meninjau dan menerima hasil dari perubahan.
52
Setelah user menerima perubahan ini, maka Request for Change
(RFC) akan ditutup. (Sumber: Anonim3)
Gambar 2.27 Gambaran umum proses Change Management (OGC, 2007, p82)
2.2.2.5 Keuntungan Change Management
Beberapa keuntungan dari change management adalah:
a. Penjajaran layanan IT yang lebih baik untuk kebutuhan bisnis
b. Meningkatkan penglihatan dan komunikasi terhadap perubahan
pada bisnis dan staf service support.
c. Memperbaiki penaksiran resiko
d. Mengurangi dampak perubahan yang merugikan atas kualitas
layanan dan atas SLA (service level agreement).
53
e. Meningkatkan problem dan availability management melalui
penggunaan informasi valuable management berhubungan
dengan perubahan. (Sumber: Anonim4)
2.2.2.6 Persoalan-persoalan umum dalam Change Management
Menurut Addy (2007, p187), persoalan-persoalan umum
yang berhubungan dengan change management, diantaranya:
- Efek samping yang tidak terduga dari perubahan
- Perubahan yang gagal
- Kegagalan dalam mengimplementasikan rencana back-out
- Pengertian yang tidak cukup terhadap resiko berkaitan dengan
perubahan
- Perubahan yang tidak terencana / terkontrol
- Konsultasi yang tidak cukup selama fase perencanaan
- Komunikasi yang lemah dalam perubahan dan akibatnya
- Kebutuhan resource yang berlawanan
- Pertentangan antara perubahan yang diajukan/direncanakan
- Perubahan yang meluas
2.2.2.7 Request for Change (RFC)
Request for Change merupakan sebuah formulir yang
digunakan untuk mencatat detail dari permintaan atas perubahan
dan dikirim sebagai masukkan untuk change management oleh
pemohon perubahan (change requestor). (Sumber: Anonim1)
54
2.2.2.8 Forward Schedule of Change (FSC)
Forward Schedule of Change merupakan sebuah jadwal
yang berisi detail dari semua perubahan yang akan dilakukan.
(Sumber: Anonim1)
2.2.2.9 Change Advisory Board (CAB)
Menurut OGC (2007, p184), Change Advisory Board
merupakan grup yang beranggotakan orang-orang yang
membantu change manager dalam penaksiran, memberikan
prioritas, dan merencanakan perubahan. Grup ini biasanya terdiri
dari perwakilan dari area dalam provider layanan IT, perwakilan
dari bisnis, dan pihak ketiga seperti supplier.
2.2.3 Komparasi Change Management
2.2.3.1 Pengertian Change Management
Menurut Peters A.H. (2006, p3), change management
memiliki tiga definisi utama yaitu :
• Tugas change management, yang mengacu kepada tugas
mengendalikan perubahan yang direncanakan dan mengatur
tata caranya.
• Sebuah area praktis profesional di mana banyak konsultan
internasional menyatakan ketertarikan mengambil spesialisasi
dalam mengendalikan perubahan untuk kepentingan pasien.
55
• Suatu badan ilmu, dimana change management terdiri dari
model-model, metode-metode dan teknik-teknik, peralatan,
keterampilan dan bentuk ilmu-ilmu lainnya yang terlibat
dalam praktik penerapan perubahan.
2.2.3.2 Tujuan Change Management
Menurut Peters A.H. (2006, p3), change management
bertujuan :
• Untuk meningkatkan performansi bisnis
• Mengendalikan perubahan dari sisi manusia
2.2.3.3 Langkah-langkah Change Management
Menurut Peters A.H. (2006, p3), change management terdiri
dari empat langkah, yaitu :
a. Penetapan keadaan perubahan
Perubahan dalam sebuah organisasi tidak terjadi dalam
keadaan vakum. Jika tidak terjadi sesuatu yang mengganggu
jalannya organisasi, perubahan berjalan secara lambat.
Membangun rasa terdesak akan perlunya perubahan
merupakan poin penting untuk membuat sebuah organisasi
sadar akan perlunya dilakukan perubahan. Staf dari berbagai
level dalam organisasi perlu menyadari kekuatan dari
pengendalian perubahan, dan menumbuhkan motivasi untuk
56
menjalankan perubahan yang akan mempengaruhi lingkungan
kerja mereka.
b. Membangun suatu pedoman persatuan yang kuat
Perubahan besar sulit untuk dikerjakan, oleh karena itu
diperlukan kekuatan penuh untuk menopang proses
perubahan. Dengan persatuan yang kokoh dan kekuatan
penuh, perubahan besar dapat dilakukan dengan lebih
mudah.
c. Merumuskan visi dan strategi perubahan
Merumuskan strategi untuk change management adalah
merencanakan metode dan teknik yang akan digunakan
dalam perubahan, serta mengatur langkah-langkah
perubahan. Visi diperlukan karena visi merupakan
jembatan antara keadaan sekarang dan keadaan di masa
depan.
d. Melaksanakan perubahan
Melaksanakan perubahan sesuai dengan strategi dan visi
perubahan. Dalam hal pelaksanaan perubahan komunikasi
menjadi salah satu faktor penting agar perubahan dapat
dilaksanakan dengan baik. Semakin baik komunikasi
dilakukan semakin baik perubahan yang dihasilkan.
57
2.2.3.4 Keuntungan Change Management
Beberapa keuntungan dari dilakukannya change
management adalah :
a. Meningkatkan performansi bisnis
b. Mengendalikan perubahan sehingga perubahan dilakukan
dengan resiko yang minimum dan efektif.
2.2.4 PHP
PHP merupakan bahasa scripting dari sisi server yang dirancang
untuk web. (Luke, 2001, p2). Kode PHP dapat disisipkan pada halaman
HTML. Kode tersebut akan dijalankan setiap kali halaman diakses. Semula
PHP merupakan singkatan dari Personal Home Page. Akan tetapi
kemudian diubah dengan istilah perulangan GNU (GNU = Gnu’s Not
Unix) sehingga menjadi PHP Hypertext Preprocessor.
PHP ditulis oleh Rasmus Leodorf pada tahun 1994. Kemudian PHP
diadopsi oleh banyak orang-orang yang berbakat dan kemudian mengalami
penyempurnaan dalam tiga kali penulisan ulang. Pada Januari 2001, PHP
digunakan oleh hampir lima juta domain web, dan populasi penggunaan
PHP terus bertambah seiring berjalannya waktu. Menurut situs
http://php.net/usage.php, diperkirakan sampai periode Juli 2007 terdapat 20
juta lebih domain web yang menggunakan PHP.
58
Kelebihan-kelebihan PHP menurut Yudhi Purwanto (2001, p3),
yaitu :
a. PHP mudah dibuat dan cepat dijalankan. PHP dapat berjalan dalam web
server dan sistem operasi yang berbeda.
b. PHP diterbitkan secara gratis. Source kode PHP dapat di-download
tanpa perlu mengeluarkan uang.
c. PHP merupakan produk open source yang ditulis dengan menggunakan
bahasa C. Penambahan fungsi baru didapatkan dengan melakukan
pengembangan pada source code.
2.2.5 MySQL
MySQL merupakan suatu Relational Database Management System
(RDBMS) yang cepat dan kuat. (Luke, 2001, p3). MySQL memungkinkan
secara efisien menyimpan, mencari, mengurutkan dan mendapatkan data.
MySQL menggunakan Structured Query Language (SQL) sebagai standar
query basisdata.
Kelebihan-kelebihan MySQL menurut Indrajit (2002, p5), yaitu :
a. Tidak membutuhkan ruang harddisk yang besar untuk aplikasinya
b. Standards supported. MySQL mendukung level masukan ANSI SQL-
92 dan ODBC level 0-2 standar SQL.
c. Language support. Database server MySQL dapat menampilkan pesan
error dalam banyak bahasa.
59
d. Large table. MySQL menyimpan masing-masing tabel dalam database
seperti file, terpisah dalam direktori database. Ukuran maksimum tabel
berkisar antara 4GB.
e. Kecepatan, kekuatan dan kemudahan untuk digunakan. MySQL lebih
cepat tiga atau empat kali dari database komersial lain. MySQL sangat
mudah untuk dikendalikan dan tidak membutuhkan database
administrator terlatih untuk menginstalnya.
f. Cost advantage. MySQL adalah database relasional yang open source
sehingga dapat digunakan secara gratis.