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

permintaan 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, buku-

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

tahap yang dilakukan dalam conceptual database design yaitu:

1. Mengidentifikasi tipe entity.

2. Mengidentifikasi tipe relasi.

3. Mengidentifikasi dan menghubungkan atribut-atribut dengan entity atau

relation types.

4. Menentukan atribut domain.

5. Menentukan candidate, primary, dan alternate key.

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

1..1

0..*Menyetujui

Barang

NoBarang {PK}

NamaBarang

Stok

Permintaan

NoPermintaan {PK}

TanggalPermintaan

JumlahPermintaan

Karyawan

NoKaryawan {PK}

NamaKaryawan

Telepon

Alamat

Posisi

GeneralServicesStaff

WarehouseStaff

Membuat

Menghubungi

1..1

1..1

Menyiapkan

0..*

1..1

Memiliki

1..* 0..*

1..1

0..*

Adalah

Adalah

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

indeks 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

- Merancang kendala umum.

2. Merancang organisasi file dan indeks-indeks:

- Menganalisis transaksi.

- Memilih organisasi file.

- Memilih indeks-indeks.

- Mengestimasi kebutuhan ruang penyimpanan.

3. Merancang user views.

4. Mempertimbangkan pengenalan redundansi yang terkontrol.

5. Memantau dan menyesuaikan sistem operasi.

2.1.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 UserID Username TransDate ProductID ProductName Qty T01 U01 User1 10-01-2012 P0001 Product01 1 P0004 Product04 2 T02 U02 User2 10-02-2012 P0002 Product02 3 T03 U03 User3 10-02-2012 P0002 Product02 4 P0003 Product03 1 T04 U02 User2 10-03-2012 P0003 Product03 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

BD

A E G

Keterangan:

A: TransID D:TransDate G: Qty

B: UserID E: ProductID

C: Username F: ProductName

A

FE

CB

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.