1 BAB 2 LANDASAN TEORI Database system pada dasarnya

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.
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.
Atributmerupakan 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
relasimemiliki empat atribut, maka kita bisa menyebut relasi tersebut memiliki degree
four. Jumlah dari tuple disebut dengan cardinality.
2
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 Database Lifecycle
Database lifecyle merupakan tahapan dalam merancang suatu database
system (Connoly, 2010, p311). Siklus hidup database digambarkan seperti berikut
ini:
3
Gambar 2. 2 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.
3. Requirements Collection and Analysis
4
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.1.1.1 Database Design
Menurut Connolly dan Begg (2005, p285), perencanaan basis data
adalah kegiatan manajemen yang merencanakan tahapan-tahapan siklus
hidup dari suatu aplikasi basis data agar dapat diwujudkan seefisien dan
seefektif mungkin. Dengan menggunakan metodologi :
5
•
Mission statement dari proyek basis data. Mission statement
mendefinisikan tujuan utama dari aplikasi basis data, membantu
menjelaskan tujuan proyek basis data, dan menyediakan maksud
yang lebih jelas untuk mencapai efektifitas dan efesiensi dalam
pembuatan aplikasi basis data yang diinginkan (Connolly dan Begg,
2005, p286).
•
Mission objectives. Selain merumuskan tujuan dari sebuah proyek
basis data, harus diperhatikan juga mengenai tugas apa saja yang
harus didukung oleh basis data tersebut. Setiap mission objective
akan menjelaskan tugas tertentu yang harus didukung oleh basis
data, dengan asumsi jika basis data mendukung mission objective,
maka mission statement juga akan tercapai (Connolly dan Begg,
2005, p286).
2.1.1.2 System Definiton
Menurut Connolly dan Begg (2005, p286), definisi sistem adalah
mendeskripsikan ruang lingkup dan batasan dari aplikasi basis data dan
sudut pandang pengguna (user view) yang utama. User view
mendefinisikan kebutuhan suatu aplikasi basis data dari perspektif
aturan kerja khusus (seperti Manajer atau Supervisor) atau area aplikasi
perusahaan (seperti marketing, personalia, atau stock control). Suatu
aplikasi basis data dapat memiliki satu atau lebih user view. Identifikasi
user view merupakan aspek yang penting dalam membuat aplikasi basis
6
data karena dapat membantu memastikan bahwa tidak ada pengguna
utama dari suatu basis data yang terlupakan ketika pembuatan aplikasi
baru yang dibutuhkan. User view juga membantu dalam pengembangan
aplikasi basis data yang kompleks dengan cara membagi permintaanpermintaan kedalam bagian-bagian yang lebih sederhana (Connolly dan
Begg, 2005, p287).
2.1.1.3 Requirements Collection and Analysis
Menurut Connolly dan Begg (2005, p288), dalam tahap ini
dilakukan suatu proses pengumpulan dan analisis informasi mengenai
bagian organisasi yang akan didukung oleh sistem basis data, dan
menggunakan informasi tersebut untuk mengidentifikasi kebutuhan
pengguna akan sistem yang baru.
Ada beberapa teknik untuk
mengumpulkan informasi, salah satunya adalah fact-finding techniques.
Menurut Connolly dan Begg (2005, p317), teknik fact-finding adalah
suatu proses resmi dalam menggunakan teknik-teknik seperti wawancara
atau kuesioner untuk mengumpulkan fakta-fakta tentang sistem dan
kebutuhan-kebutuhannya. Ada lima kegiatan yang dipakai dalam teknik
ini, yaitu memeriksa dokumentasi, wawancara, mengamati operasional
perusahaan, penelitian, dan kuesioner.
a. Memeriksa Dokumentasi
Menurut Connolly dan Begg (2005, p317), memeriksa dokumentasi
dapat berguna apabila digunakan untuk menemukan beberapa kebutuhan
7
dari basis data. Dokumentasi juga dapat membantu untuk meningkatkan
informasi mengenai perusahaan yang dihubungkan dengan masalah yang
ada. Apabila masalah yang dihadapi berhubungan dengan sistem yang
sedang berjalan, maka seharusnya dokumentasi berhubungan dengan
sistem tersebut. Pemahaman terhadap jalannnya sistem akan cepat
diperoleh dengan memeriksa dokumen, formulir, laporan, dan file yang
berhubungan dengan sistem yang sedang berjalan.
b. Wawancara
Menurut Connolly dan Begg (2005, p317), wawancara bertujuan
untuk
mengumpulkan
fakta
yang ada
dan
mengklarifikasinya,
membangkitkan semangat, melibatkan pengguna akhir, mengidentifikasi
kebutuhan-kebutuhan, dan mengumpulkan ide-ide.
c. Mengamati Operasional Perusahaan
Menurut Connolly dan Begg (2005, p319), teknik ini memungkinkan
pengamat untuk ikut serta atau mengamati seseorang melakukan
kegiatan untuk mempelajari sistam. Faktor pengamatan dapat berhasil
dengan mencari informasi sebanyak mungkin tentang kegiatan yang
akan diamati serta orang yang melakukan kegiatan tersebut.
d. Penelitian
Menurut Connolly dan Begg (2005, p319), jurnal komputer, bukubuku referensi, dan internet merupakan sumber informasi yang baik
yang menyediakan informasi bagaimana orang lain memecahkan
masalah yang serupa.
8
e. Kuesioner
Menurut Connolly dan Begg (2005, p320), kuesioner adalah suatu
dokumen dengan tujuan khusus yang memungkinkan fakta-fakta
dikumpulkan dari banyak orang sambil menjaga kontrol terhadap
tanggapan yang diberikan.
2.1.1.4 Database Design
2.1.1.4.1 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, 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. Tahaptahap 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. MempertimbangkanPenggunaanEnhanced Modeling Concept
7. Memeriksa redudansi pada model.
9
8. Memvalidasi conceptual data model terhadap transaksi pengguna.
9. Meninjau kembali conceptual data model dengan pengguna.
Gambar 2. 3 Contoh ConceptualDataModel
2.1.1.4.2 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 integrityconstraits.
10
5. Meninjau kembali logical data model dengan pengguna.
6. Menggabungkanlogical data model dengan model global.
7. Memeriksa perkembangan data di masa yang akan datang.
Permintaan
Barang
NoBarang {PK}
NamaBarang
0..* Stok
Memiliki
NoPermintaan {PK}
TanggalPermintaan
0..* JumlahPermintaan
0..*
1..*
Menyetujui
0..*
1..1
Membuat
GeneralServicesStaff
1..1
Adalah
Menyiapkan
1..1
Menghubungi
1..1
1..1
WarehouseStaff
Adalah
Karyawan
NoKaryawan {PK}
NamaKaryawan
Telepon
Alamat
Posisi
Gambar 2. 4 Contoh Logical Data Model
2.1.1.4.3 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.
11
2.
Merancang kendala umum.
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.1.5 DBMS Selection
Menurut Connolly dan Begg (2005, p295), pemilihan DBMS
disesuaikan untuk mendukung sistem basis data. Adapun dalam
pemilihan DBMS sebaiknya mencakup (Connolly dan Begg, 2005,
p297):
1. Mendefnisikan syarat-syarat referensi studi.
Menentukan sasaran, batasan, dan tugas yang harus dilakukan.
2. Mendaftar dua atau tiga jenis barang.
Membuat daftar barang-barang, misalnya pencatatan terhadap asal
barang, harga barang, serta bagaimana mendapatkannya.
3. Mengevaluasi barang.
Barang-barang yang ada dalam daftar diteliti lebih lanjut untuk
mengetahui kelebihan dan kekurangan barang tersebut.
12
4. Merekomendasikan pilihan dan membuat laporan.
Merupakan
langkah
terakhir
dari
seleksi
DBMS,
yaitu
mendokumentasikan proses dan untuk menyediakan pernyataan
mengenai kesimpulan dan rekomendasi terhadap salah satu produk
DBMS.
2.1.1.5.1
Komponen DBMS
Menurut Connolly dan Begg (2005, p18), ada lima
komponen utama dalam suatu lingkungan Sistem Manejemen Basis
Data, yaitu sebagai berikut :
1. Perangkat Keras (Hardware)
Piranti keras sangat dibutuhkan untuk menjalankan aplikasi dan
DBMS. Piranti keras dapat berupa sebuah komputer, sebuah
mainframe, ataupun sebuah jaringan antar komputer, yang nantinya
disesuaikan dengan kebutuhan organisasi dan DBMS yang digunakan.
2. Perangkat Lunak (Software)
Merupakan komponen perangkat lunak yang terdiri dari DBMS dan
program-program aplikasi, termasuk sistem operasi dan dan perangkat
lunak jaringan apabila dalam penggunaannya menggunakan jaringan
komputer.
13
3. Data
Merupakan komponen yang terpenting dari suatu DBMS dilihat dari
sudut
pandang
pengguna.
Data
memegang
peranan
sebagai
penghubung antara komponen mesin dengan manusia dalam
lingkungan DBMS.
4. Prosedur
Merupakan instruksi dan aturan yang diterapkan untuk mendesain dan
menggunakan basis data.
5. Manusia
Merupakan komponen yang terlibat dalam sistem yang terdiri atas
application programmer, end users, dan database administrator.
2.1.1.5.2
Kelebihan dan Kekurangan DBMS
Menurut Connolly dan Begg (2005, p26), kelebihan DBMS
yaitu antara lain :
1. Kontrol terhadap redudansi data.
2. Konsistensi data.
3. Lebih banyak informasi dari jumlah yang sama.
4. Banyaknya data.
5. Sharing data.
6. Meningkatkan integritas data.
7. Meningkatkan keamanan.
8. Standarisasi.
14
9. Lebih ekonomis.
10. Menyeimbangkan kebutuhan yang bertentangan.
11. Meningkatkan akses dan respon data.
12. Meningkatkan produktivitas.
13. Meningkatkan pemeliharaan melalui indepedensi data.
14. Meningkatkan konkurensi data.
15. Meningkatkan pelayanan bakcup dan recovery.
Kekurangan DBMS yaitu antara lain :
1. Kompleksitas.
2. Ukuran.
3. Biaya DBMS.
4. Biaya tambahan perangkat keras.
5. Biaya konversi.
6. Performa.
7. Dampak kegagalan yang lebih tinggi.
2.1.1.6
Prototipe
Prototipe pada dasarnya adalah sebuah desain output dari sebuah
aplikasi, di mana output itu sendiri adalah yang akan merepresentasikan informasi
ke system user. 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.
15
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
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.1.2
Data Flow Diagram
Menurut McGraw-Hill (2004, p357), DFD adalah aliran data antara sistem
dengan lingkungannya, atau diantara dua proses didalam sistem. Aliran data yang
direpresentasikan adalah suatu input kedalam proses atau output data dari suatu
proses. Aliran data juga merepresentasikan pembuatan, pembacaan, penghapusan
dan pengubahan data pada suatu file atau basis data.
2.1.2.1 Perancangan DFD
Dalam pembuatan DFD, terdapat levelisasi yang bertujuan untuk
menghindari aliran data yang rumit. Levelisasi dimulai dari dengan
16
tingkatan tertinggi dan kemudian diuraikan ke dalam bentuk yang lebih
rinci. Tingkatan tersebut terdiri dari :
1. Diagram konteks (Context Data Flow Diagram)
Diagram konteks merupakan sebuah model proses yang digunakan
untuk mendokumentasikan ruang lingkup dari sebuah sistem.
2. Diagram nol (Level-0 Diagram)
level-0 diagram merupakan diagram aliran data yang menggambarkan
sebuah major processes, data flow, dan data stores dari sebuah sistem
yang berada pada tingkatan tertinggi untuk detailnya.
2.1.3
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.
17
2.
Ternary yaitu jumlah entity yang terlibat ada tiga buah.
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
domainconcept 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. 5 Contoh Strong dan WeakEntity
Telah disebutkan sebelumnya, degree of relationship types yang paling
umum yaitu binary relationship. Secara umum, binary relationship dibagi
18
menjadi tiga berdasarkan kendala integritasnya, yaitu one to one, one to many,
dan many to many. Berikut penjelasan ketiganya:
1.
One to One (1:1) Relationship
Gambar 2. 6 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. 7 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. 8 Contoh Many to Many (*:*) Relationship
19
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,
entitysubclass akan mewarisi semua atribut entitysuperclass, 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).
Generalisasi sendiri adalah proses meminimalisir perbedaan antar entity
dengan mengidentifikasi karakteristik yang sama (Connolly, 2010, p403).
20
Sedangkan spesialisasi adalah proses memperbanyak perbedaan antar entity
(Connolly, 2010, p402).
Gambar 2. 9 Contoh Generalisasi/Spesialisasi
Gambar 2. 10 Contoh EntityRelationship
2.1.3.1
Keys
Menurut Connolly dan Begg (2005, p352), candidate keys
adalah set atribut minimal yang secara unik mengidentifikasikan setiap
kejadian dari sebuah tipe entitas. Primary key adalah candidate key
yang dipilih untuk secara unik mengidentifikasi setiap occurrence dari
tipe entitas. Composite key adalah candidate key yang terdiri dari dua
atau lebih atribut.
21
2.1.3.2
Relational Database Keys
Menurut Coronel, Morris, dan Rob (2010, p96) Relational
database keys ada 5 macam yaitu :
• Superkey
Sebuah
atribut
(atau
kombinasi
atribut)
yang
secara
unik
mengidentifikasi setiap baris dalam sebuah tabel.
• Candidate key
Sebuah superkey (tereduksi) minimal. Sebuah superkey yang tidak
berisi subset dari atribut itu sendiri yaitu superkey.
• Primary key
Key kandidat yang dipilih untuk secara unik mengidentifikasi semua
nilai atribut lain dalam baris yang diberikan
• secondary key
Digunakan secara ketat untuk tujuan pengambilan data.
• Foreign key
Sebuah atribut (atau kombinasi atribut) dalam satu meja yang nilainya
baik harus sesuai dengan primary key dalam tabel lain atau menjadi
null.
2.1.3
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
22
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 selanjutnya disebut Unnormalized Form (UNF).
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
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
23
T02
U02
User2
10-02-2012
P0002
Product02
3
T03
U03
User3
10-02-2012
P0002
Product02
4
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. 11 Contoh FunctionalDependency
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
24
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 dependencydaritabel
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. 12 FunctionalDependency 1NF Tabel Request
Gambar diatas merupakan bentuk functional dependency dari tabel 2.2. A
dan E merupakan primary key. Atribut F hanya bergantung kepada atribut E
yang merupakan sebagian atribut primary key. Dengan kata lain, F merupakan
25
partial dependency yang harus dihilangkan untuk memenuhi syarat bentuk
2NF. Begitu juga dengan atribut D dan B.
Gambar 2. 13 Functional Dependency 2NF Tabel Request
3.
3NF
Pada tahap ini akan dilakukan penghilangan transitive dependencydaritabel
2NF, di mana transitive dependency adalah atribut non-primary 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.
26
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. 14 FunctionalDependency 3NF Tabel Request
2.2
Penjualan
Menurut Mulyadi (2001, p204), kegiatan penjualan terdiri dari penjualan
barang atau jasa baik secara kredit maupun tunai. Penjualan menurut cara
bayarnya dapat dibedakan sebagai berikut :
1. Penjualan tunai adalah penjualan yang dilaksanakan oleh perusahaan dengan
cara mewajibkan pembeli dengan melakukan pembayaran harga barang
terlebih dahulu sebelum barang diserahkan kepada pembeli.
2. Penjualan kredit adalah penjualan yang dilakukan dengan cara memenuhi
pesanan dari pelanggan dengan mengirimkan barang atau menyerahkan jasa
dan untuk jangka waktu tertentu perusahaan memiliki piutang kepada
pelanggannya.
2.3
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
27
HTML standart dapat ditulis seperti biasa sementara konten dinamis dihasilkan
oleh scripting language. PHP adalah bahasa scriptingopen 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:
Gambar 2. 15 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.