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.
