6 BAB 2 LANDASAN TEORI 2.1 Pendekatan Sistem Basis

BAB 2
LANDASAN TEORI
2.1 Pendekatan Sistem Basis-Data
2.1.1
Pengertian Sistem Basis-Data
Menurut Connolly (2005, p15), “database is a shared collection of
logically related data, and a description of this data, designed to meet the
information needs of an organization”, dapat diartikan: basis-data adalah
sekumpulan data yang saling berhubungan secara logika dan sebuah deskripsi
dari data ini, yang dirancang untuk memenuhi kebutuhan informasi dari
sebuah organisasi.
Menurut C. J. Date (2000, p5), “A database system is basically a
computerized record-keeping system; i.e., it is a computerized system whose
overall purpose is to store information and to allow users to retrieve and
update that information on demand”, dapat diartikan: sistem basis-data pada
dasarnya merupakan suatu sistem penyimpanan dokumen terkomputerisasi,
yaitu: sistem terkomputerisasi yang secara keseluruhan bertujuan untuk
menyimpan informasi dan mengijinkan pengguna untuk mendapatkan
kembali dan mengubah (update) informasi tersebut sesuai permintaan.
Menurut Mc. V. Mannino (2001, p7), “Database is language and
graphical tools to define entities, relationships, integrity constraints, and
authorization rights”, dapat diartikan: basis-data adalah bahasa dan alat
6
7
grafikal untuk mendefinisikan entities, relasi, batasan integritas, dan hak
autorisasi.
Dari pengertian-pengertian tersebut, dapat disimpulkan bahwa sistem
basis-data adalah sebuah sistem yang menyimpan sekumpulan data dimana
entities di dalamnya saling berelasi sehingga memudahkan pengguna dalam
mengakses data sesuai dengan permintaan pengguna.
2.1.2
Database Management System (DBMS)
2.1.2.1 Pengertian Database Management System (DBMS)
Menurut Connolly (2005, p16), “DBMS is a software system that
enables users to define, create, maintain, and control access to the
database”, dapat diartikan: DBMS adalah sebuah sistem software yang
memungkinkan pengguna untuk mendefinisikan, membuat, memelihara
dan mengontrol akses ke basis-data.
2.1.2.2 Komponen DBMS
Menurut Connolly (2005, p18-21), terdapat lima komponen utama
dalam lingkungan DBMS, yaitu:
1. Hardware
DBMS dan aplikasi membutuhkan hardware untuk berjalan.
Hardware tersebut dapat berupa, mulai dari single personal computer,
hingga single mainframe, hingga satu jaringan komputer. Hardware
yang dibutuhkan tergantung pada kebutuhan organisasi dan DBMS
yang digunakan.
8
2. Software
Komponen software terdiri dari software DBMS itu sendiri
dan program aplikasi, beserta sistem operasi, termasuk software
jaringan jika DBMS digunakan dalam jaringan. Khususnya, program
aplikasi ditulis dalam third-generation language (3GL), seperti ‘C’,
C++, Java, Visual Basic, COBOL, Fortran, Ada atau Pascal, atau
menggunakan fourth-generation (4GL), seperti SQL, ditempelkan
(embedded) dalam third-generation language.
3. Data
Data mungkin merupakan komponen paling penting dalam
lingkungan DBMS, tentunya dari sudut pandang pengguna akhir.
Data berperan sebagai jembatan antara komponen mesin dan
komponen manusia. Basis-data meliputi data operasional dan
metadata, “data mengenai data”.
4. Prosedur
Prosedur mengarah pada instruksi dan aturan yang mengatur
rancangan dan kegunaan dari basis-data. Pengguna sistem dan
pegawai
yang
mengelola
basis-data
membutuhkan
prosedur
terdokumentasi mengenai bagaimana cara menggunakan atau
menjalankan sistem. Prosedur tersebut mungkin terdiri dari instruksi
mengenai bagaimana cara:
•
Log on ke DBMS
•
Menggunakan fasilitas DBMS yang khusus atau program aplikasi
9
•
Memulai dan menghentikan DBMS
•
Membuat salinan backup dari basis-data
•
Menangani kegagalan hardware atau software
•
Mengubah struktur tabel, menata ulang basis-data melewati
multiple disks, meningkatkan performansi atau mengarsip data ke
penyimpanan sekunder
5. Orang
Komponen terakhir adalah orang-orang yang terlibat dengan
sistem.
2.1.2.3 Keuntungan dan Kerugian DBMS
Keuntungan dari DBMS, antara lain:
1. Kontrol terhadap redundansi data
2. Konsistensi data
3. Informasi lebih dari jumlah data yang sama
4. Penggunaan data bersama
5. Meningkatnya integritas data
6. Meningkatnya keamanan
7. Penerapan standar
8. Penghematan biaya
9. Keseimbangan dalam konflik kebutuhan
10. Meningkatkan aksebilitas dan respon data
11. Meningkatkan produktivitas
12. Memperbaiki pemeliharaan melalui kebebasan data
10
13. Meningkatkan pengaksesan data bersamaan
14. Meningkatkan layanan backup dan recovery
Kerugian dari DBMS, antara lain:
1. Kompleksitas
2. Ukuran
3. Biaya DBMS
4. Biaya hardware tambahan
5. Biaya konversi
6. Performansi
7. Dampak kegagalan yang lebih besar
2.1.2.4 Fungsi DBMS
Fungsi DBMS menurut Connolly (2005, p48) adalah sebagai
berikut:
1. Penyimpanan, pengambilan dan pengubahan data
2. Katalog yang dapat diakses pengguna
3. Pendukung transaksi
4. Layanan pengontrolan akses data yang bersamaan
5. Layanan recovery
6. Layanan hak akses
7. Pendukung untuk komunikasi data
8. Layanan integritas
9. Layanan untuk meningkatkan kebebasan data
10. Layanan utilitas (kegunaan)
11
2.1.3
Database Language
Menurut Connolly (2005, p39-40), sub bahasa data terdiri dari 2
bagian, yaitu: Data Definition Language (DDL) dan Data Manipulation
Language (DML). DDL digunakan untuk spesifikasi skema basis-data dan
DML digunakan untuk membaca dan mengubah basis-data.
2.1.3.1 Data Definition Language (DDL)
Menurut Connolly (2005, p40), “DDL is a language that allows
the DBA or user to describe and name the entities, attributes, and
relationships required for the application, together with any associated
integrity and security constraints”, dapat diartikan: DDL adalah suatu
bahasa yang memungkinkan DBA (Database Administrator) atau
pengguna untuk mendeskripsikan dan menyebutkan entity, atribut dan
relasi yang dibutuhkan oleh aplikasi, bersama integritas terkait dan
batasan keamanan.
2.1.3.2 Data Manipulation Language (DML)
DML menurut Gerald V. Post (2005, p146) adalah sebuah
rangkaian dari perintah-perintah yang digunakan untuk mengakses data.
Contohnya Perintah Insert, Delete, dan Update.
Menurut Connolly (2005, p40), “DML
is a language that
provides a set of operations to support the basic data manipulation
operations on the data held in the database”, dapat diartikan: DML
adalah suatu bahasa yang menyediakan sekumpulan operasi untuk
12
mendukung operasi manipulasi data dasar pada data yang disimpan dalam
basis-data.
Operasi manipulasi data biasanya meliputi:
•
Pemasukan data baru ke dalam basis-data
•
Modifikasi data yang disimpan dalam basis-data
•
Pengambilan data yang tersimpan dalam basis-data
•
Penghapusan data dari basis-data
2.1.3.3 Fourth-Generation Languages (4GL)
Suatu operasi yang membutuhkan ratusan baris dalam bahasa
generasi tingkat tiga (3GL), seperti COBOL, umumnya membutuhkan
jauh lebih sedikit baris dalam 4GL.
Dibandingkan dengan 3GL, yang prosedural, 4GL nonprosedural: pengguna mendefinisikan “apa” yang harus dilakukan, bukan
“bagaimana”. 4GL diharapkan dapat banyak bergantung pada komponenkomponen yang tingkatannya jauh lebih tinggi yang dikenal sebagai tools
generasi ke-4. Para pengguna tidak mendefinisikan langkah yang
dibutuhkan program untuk melaksanakan suatu tugas, tetapi lebih ke arah
mendefinsikan parameter untuk tools yang menggunakan parameter
tersebut untuk menciptakan suatu program aplikasi. 4GL meliputi:
•
Bahasa presentasi, seperti query language and report generator
•
Bahasa khusus, seperti spreadsheets dan database language
13
•
Generator aplikasi yang mendefinisikan, memasukkan, mengubah,
dan mengambil kembali data dari basis-data untuk membangun
aplikasi.
2.1.4
Database Life Cycle
Daur hidup sistem basis-data dapat dilihat pada bagan sebagai
berikut:
Gambar 2.1 Daur Hidup Sistem Basis-Data
14
2.1.4.1 Database Planning
Menurut Connolly (2005, p285), database planning adalah
kegiatan manajemen yang mengizinkan tahap-tahap pada siklus hidup
aplikasi basis-data untuk diwujudkan seefisien dan seefektif mungkin.
Langkah penting pertama dalam database planning ini adalah
mendefinisikan mission statement bagi proyek basis-data. Mission
statement mendefinisikan tujuan utama dari aplikasi basis-data. Mission
statement membantu dalam menjelaskan tujuan proyek basis-data dan
menyediakan alur yang jelas dalam pembuatan aplikasi basis-data yang
efisien dan efektif. Setelah mission statement didefinisikan, kegiatan
selanjutnya adalah mengidentifikasikan mission objectives. Tiap mission
objective harus mengidentifikasikan tugas tertentu yang harus didukung
oleh basis-data.
2.1.4.2 System Definition
Menurut
Connolly
(2005,
p286),
system
definition
mendeskripsikan ruang lingkup dari aplikasi basis-data dan user view
utama.
Sebelum merancang aplikasi basis-data, penting untuk terlebih
dahulu mengidentifikasikan batas sistem yang diinvestigasi dan
bagaimana sistem tersebut berinteraksi dengan bagian lain dari sistem
informasi organisasi.
15
2.1.4.3 Requirements Collection and Analysis
Menurut Connolly (2005, p288), requirements collection and
analysis adalah proses mengumpulkan dan menganalisis informasi
mengenai bagian dari organisasi yang akan didukung oleh aplikasi basisdata, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan
pengguna dari sistem baru.
Informasi yang dikumpulkan untuk setiap user view (yaitu,
peranan kerja atau area aplikasi perusahaan) meliputi:
1. Deskripsi dari data yang digunakan atau dibangun
2. Rincian mengenai bagaimana data digunakan atau dibangun
3. Beberapa kebutuhan tambahan lain untuk aplikasi basis-data yang
baru
Terdapat 3 pendekatan untuk mengelola kebutuhan aplikasi basisdata dengan banyak user views, yaitu:
a. Pendekatan centralized
Kebutuhan
untuk
setiap
user
view
digabung
dalam
sekumpulan kebutuhan untuk aplikasi basis-data yang baru.
b. Pendekatan view integration
Kebutuhan
untuk
setiap
user
view
digunakan
untuk
membangun model data terpisah untuk merepresentasikan user view
tersebut. Hasil dari model data digabung belakangan pada tahapan
perancangan basis-data.
c. Kombinasi dari kedua pendekatan di atas
16
2.1.4.4 Database Design
Menurut Connolly (2005, p291), database design adalah proses
menghasilkan rancangan basis-data yang mendukung tujuan dan operasi
perusahaan.
Proses perancangan ini dibagi menjadi 3 tahap, yaitu:
1. Perancangan basis-data konseptual
Menurut Connolly (2005, p439), perancangan basis-data
konseptual adalah proses membangun suatu model dari informasi
yang digunakan dalam sebuah perusahaan, terbebas dari segala
pertimbangan fisikal.
2. Perancangan basis-data logikal
Menurut Connolly (2005, p439), perancangan basis-data
logikal adalah proses membangun suatu model dari informasi yang
digunakan dalam sebuah perusahaan berdasarkan sebuah model data
yang spesifik tetapi terbebas dari DBMS tertentu dan pertimbangan
fisikal lainnya.
3. Perancangan basis-data fisikal
Menurut Connolly (2005, p439), perancangan basis-data
fisikal
adalah
proses
menghasilkan
sebuah
deskripsi
dari
implementasi basis-data pada media penyimpanan sekunder yang
mendeskripsikan relasi dasar, organisasi file, dan indeks yang
digunakan untuk mengakses data secara efisien, dan setiap batasan
integritas terkait dan ukuran-ukuran keamanan.
17
2.1.4.5 DBMS Selection
Menurut Connolly (2005, p295), DBMS selection adalah
pemilihan DBMS yang sesuai untuk mendukung aplikasi basis-data.
2.1.4.6 Application Design
Menurut Connolly (2005, p299), application design adalah
merancang user interface dan program aplikasi yang menggunakan dan
memproses basis-data.
2.1.4.7 Prototyping (Optional)
Menurut Connolly (2005, p303), prototyping adalah membangun
sebuah working model dari aplikasi basis-data.
Tujuan
utama
prototyping
adalah
mengijinkan
pengguna
menggunakan prototype untuk mengidentifikasi fitur-fitur pada sistem
yang bekerja dengan baik, atau kurang lengkap, dan jika mungkin,
menyarankan peningkatan atau bahkan fitur baru pada aplikasi basis-data.
2.1.4.8 Implementation
Menurut
Connolly
(2005,
p304),
implementation
adalah
perwujudan fisikal dari rancangan basis-data dan aplikasi.
2.1.4.9 Data Conversion and Loading
Menurut Connolly (2005, p305), data conversion and loading
adalah memindahkan data yang ada ke dalam basis-data baru dan
18
mengkonversi aplikasi yang ada untuk dijalankan pada basis-data yang
baru.
2.1.4.10
Testing
Menurut
Connolly
(2005,
p305),
testing
adalah
proses
mengeksekusi program aplikasi dengan tujuan menemukan errors.
2.1.4.11
Operational Maintainance
Menurut Connolly (2005, p306), operational maintenance
merupakan
proses
mengawasi
dan
memelihara
sistem
setelah
penginstalasian.
2.1.5
Tahap-Tahap Perancangan Basis-Data
2.1.5.1 Perancangan Basis-Data Konseptual
Langkah 1:
Membangun Model Data Konseptual
Tujuan dari langkah ini adalah untuk membangun suatu model
data konseptual dari kebutuhan data perusahaan.
Langkah 1.1
: Mengidentifikasikan tipe entity
Langkah 1.2
: Mengidentifikasikan tipe relasi
Langkah 1.3
: Mengidentifikasikan
dan
mengasosiasikan
atribut
dengan entity atau tipe relasi
Langkah 1.4
: Menentukan domain atribut
Langkah 1.5
: Menentukan atribut candidate, primary dan alternate
key
19
Langkah 1.6
: Mempertimbangkan penggunaan konsep enhanced
modelling (langkah opsional)
Langkah 1.7
: Memeriksa redundansi
Langkah 1.8
: Memvalidasi model konseptual dengan transaksi
pengguna
Langkah 1.9
: Me-review model data konseptual dengan pengguna.
Berikut ini adalah detil mengenai langkah-langkah yang telah
disebutkan di atas.
Langkah 1.1
: Mengidentifikasikan tipe entity
Langkah pertama dalam membangun suatu model data konseptual
lokal adalah mendefinisikan objek utama yang terkait dengan pengguna.
Salah satu metode untuk mengidentifikasi entities adalah dengan
memeriksa spesifikasi kebutuhan pengguna dan mengidentifikasi kata
benda atau frase kata benda yang disebutkan oleh pengguna (sebagai
contoh: staff number, property number, property address, rent, number of
rooms).
Entities yang teridentifikasi didokumentasi dalam kamus data.
Berikut ini merupakan contoh dari potongan kamus data yang
mendokumentasikan entity staff.
Nama Entity
Staff
Deskripsi
Menjelaskan tentang
setiap karyawan yang
bekerja di
DreamHome.
Alias
Karyawan
Occurrence
Tiap karyawan
bekerja pada
salah satu cabang.
20
Langkah 1.2
: Mengidentifikasi tipe relasi
Tujuan dari langkah ini adalah untuk mengidentifikasi relasi
penting yang ada antara tipe-tipe entity. Biasanya, relasi diidentifikasi
dengan kata kerja atau frase kata kerja.
Sebagai contoh:
•
Staff Manages PropertyForRent
•
PrivateOwner Owns PropertyForRent
•
PropertyForRent AssociatedWith Lease
Relasi yang paling umum adalah relasi biner. Artinya relasi antar
entity yang persis antara dua entity saja. Harus diperhatikan juga relasi
kompleks yang melibatkan lebih dari dua entity dan relasi rekursif yang
hanya melibatkan satu entity saja.
Adapun langkah-langkah dalam mengidentifikasi tipe relasi
adalah sebagai berikut:
•
Menggunakan diagram Entity-Relationship (ER)
Seringkali, akan lebih mudah memvisualisasi sebuah sistem
yang
kompleks
daripada
menguraikan
spesifikasi
kebutuhan
pengguna dengan menggunakan teks yang panjang. Diagram EntityRealtionship (ER) dapat digunakan untuk merepresentasikan entity
dan bagaimana relasi antar entity.
21
•
Menentukan batasan multiplicity dari tipe relasi
Langkah berikutnya adalah menentukan multiplicity setiap
relasi. Jika memang ada suatu nilai yang spesifik dari suatu
multiplicity maka lebih baik didokumentasikan juga.
•
Memeriksa fan dan chasm traps
Langkah berikutnya adalah memeriksa fan dan chasm traps.
Yang dimaksud dengan fan traps adalah suatu model yang
merepresentasikan suatu relasi antara entity, tetapi alur relasinya
memperlihatkan ambiguitas (kerancuan).
Sedangkan chasm traps
adalah suatu model di mana ada hubungan antara entity yang satu
dengan entity yang lain, tetapi tidak ada relasi antara kedua entity
tersebut.
•
Mendokumentasikan tipe relasi
Berikut ini merupakan contoh potongan dari kamus data yang
mendokumentasikan relasi Staff user views of DreamHome.
Nama
Entity
Staff
Property
ForRent
Langkah 1.3
Multiplicity
Relasi
Multiplicity
0..1
Manages
0..100
0..1
1..1
Supervises
AssociatedWith
0..10
0..*
Nama
Entity
Property
ForRent
Staff
Lease
: Mengidentifikasikan dan mengasosiasikan atribut
pada entity atau tipe relasi
Tujuan dari langkah ini adalah untuk mengasosiasikan atribut
yang sesuai pada entity atau tipe relasi.
22
•
Simple/composite attributes
Penting untuk diperhatikan apakah suatu atribut adalah simple
atau composite. Composite attributes adalah atribut yang dibangun
dari simple attributes. Sebagai contoh, atribut alamat bisa saja dibuat
simple dan menyimpan beberapa detail dari alamat sebagai suatu nilai.
Contoh: Dumbarton Road, Glasgow, G116YG. Namun, atribut alamat
dapat juga merepresentasikan sebuah composite attribute,
yang
terdiri dari beberapa detil yang mempunyai nilai terpisah dalam
atribut jalan (“115 Dumbarton Road”), kota (“Glasgow”), dan
kodepos (“G116YG”). Atribut alamat dapat dijadikan simple attribute
atau composite attribute tergantung dengan kebutuhan pengguna.
Jika pengguna tidak membutuhkan detil dari atribut alamat seperti
nama jalan, kota, kodepos dan sebaginya, maka sebaiknya atribut
alamat tersebut tetap dibuat sebagai simple attribute. Sedangkan jika
pengguna membutuhkan detil dari atribut alamat seperti nama jalan,
kota, kodepos, dan sebagainya, maka sebaiknya atribut alamat
tersebut dibuat sebagai composite attribute.
•
Single/multi-valued attributes
Suatu atribut juga dapat mempunyai satu atau lebih nilai.
Contoh: atribut noTelepon. Seseorang bisa saja mempunyai nomor
telepon lebih dari satu, apabila memang demikian, maka dapat disebut
multi-valued
attribute.
Tetapi
apabila
atribut
mempunyai suatu nilai maka disebut single attribute.
tesebut
hanya
23
•
Derived Attributes
Derived Attribute adalah atribut yang tergantung dengan nilai
atribut yang lain. Sebagai contoh:
a. Umur dari seorang pegawai
b. Banyaknya properti yang dipegang oleh pegawai
Langkah 1.4
: Menentukan domain atribut
Tujuan dari langkah ini adalah untuk menentukan domain dari
atribut dalam model data konseptual lokal. Sebagai contoh:
•
Domain atribut dari staffNo terdiri dari lima karakter tipe string
dimana dua karakter utama merupakan huruf, sedangkan tiga karakter
sisa berupa angka.
•
Nilai yang mungkin untuk atribut sex adalah ‘M’ atau ‘F’. Ini
merupakan domain dari atribut yang menggunakan karakter tunggal.
Langkah 1.5
: Menentukan
atribut
candidate,
primary
dan
alternate key
Tujuan dari langkah ini adalah untuk mengidentifikasikan
candidate key untuk setiap tipe entity, dan jika terdapat lebih dari satu
candidate key, pilihlah salah satunya untuk menjadi primary key dan yang
lainnya sebagai alternate keys. Berikut ini merupakan petunjuk-petunjuk
yang dapat digunakan untuk membantu penyeleksian primary key di
antara banyak candidate key.
24
•
candidate key dengan jumlah set atribut paling sedikit
•
candidate key yang nilainya jarang sekali berubah
•
candidate key dengan jumlah karakter paling sedikit (untuk atribut
tekstual)
•
candidate key dengan nilai nilai maksimum terkecil (untuk atribut
numerik)
•
candidate key yang paling mudah digunakan dari sudut pandang
pengguna
Langkah 1.6
: Mempertimbangkan penggunaan konsep enhanced
modelling (langkah opsional)
Tujuan dari langkah ini adalah untuk mempertimbangkan
penggunaan
konsep
enhanced
modelling,
seperti
specialization/
generalization, aggregation, dan composition. Jika digunakan pendekatan
specialization, maka akan diperhatikan perbedaan antara entities dengan
mendefinisikan satu atau banyak subclasses dari entity superclass. Jika
digunakan
pendekatan
generalization,
maka
akan
diidentifikasi
persamaan antara entities untuk membentuk entity superclass.
Langkah 1.7
: Memeriksa redudansi
Tujuan dari langkah ini adalah untuk memeriksa apakah terdapat
redudansi dalam model. Pada langkah ini, data model konseptual lokal
diperiksa dengan tujuan spesifik dari pengidentifikasian apakah terdapat
25
redundansi dan menghilangkannya jika ada. Tiga kegiatan dalam langkah
ini adalah:
•
memeriksa kembali relasi one-to-one (1:1)
•
menghilangkan relasi redundan
•
mempertimbangkan dimensi waktu
Langkah 1.8
: Memvalidasi model konseptual dengan transaksi
pengguna
Tujuan dari langkah ini adalah untuk memastikan bahwa model
konseptual mendukung transaksi yang dibutuhkan. Dua pendekatan yang
dapat digunakan:
•
mendeskripsikan transaksi
•
menggunakan alur transaksi
Langkah 1.9
: Me-review model data konseptual dengan pengguna
Tujuan dari langkah ini adalah untuk me-review model data
konseptual dengan pengguna untuk memastikan bahwa model yang ada
merupakan representasi yang “benar” dari kebutuhan data perusahaan.
26
Gambar 2.2 Contoh Model Data Konseptual
2.1.5.2 Perancangan Basis-Data Logikal
Langkah 2:
Membangun dan Memvalidasi Model Data Logikal
Tujuan dari langkah ini adalah untuk menerjemahkan model data
konseptual ke dalam model data logikal dan kemudian memvalidasi
model ini untuk mengecek bahwa strukturnya benar dan mampu
mendukung transaksi yang dibutuhkan.
Langkah 2.1
: Menurunkan tabel untuk model data logikal
27
Langkah 2.2
: Memvalidasi tabel menggunakan normalisasi
Langkah 2.3
: Memvalidasi tabel terhadap transaksi pengguna
Langkah 2.4
: Memeriksa batasan integritas
Langkah 2.5
: Me-review model data logikal lokal dengan pengguna
Langkah 2.6
: Menggabungkan model data logikal ke dalam model
global (langkah opsional)
Langkah 2.7
: Memeriksa untuk pertumbuhan masa yang akan datang.
Berikut ini adalah detil mengenai langkah-langkah yang telah
disebutkan di atas.
Langkah 2.1
: Menurunkan tabel untuk model data logikal
Tujuan dari langkah ini adalah membuat tabel untuk model data
logikal yang merepresentasikan entities, relasi, dan atribut yang telah
diidentifikasi.
Dilakukan pendeskripsian bagaimana relasi diturunkan untuk
strukur-struktur berikut ini yang mungkin muncul dalam model data
konseptual:
•
tipe entity kuat (strong entity types)
Tipe entity kuat adalah tipe entity yang kemunculannya tidak
dipengaruhi oleh tipe entity lain.
•
tipe entity lemah (weak entity types)
Tipe entity lemah adalah tipe entity yang kemunculannya
dipengaruhi oleh tipe entity lain.
28
Primary key dari tiap tipe entity lemah diturunkan sebagian
atau sepenuhnya dari pemilik entity sehingga pengidentifikasian
primary key dari tipe entity lemah tidak dapat dilakukan sampai
semua tabel dengan pemilik entity dipetakan.
•
tipe relasi biner one-to-many (1:*)
Untuk setiap relasi biner 1:*, entity “sisi one” dari relasi
dijadikan sebagai parent entity (entity induk) dan entity “sisi many”
dijadikan sebagai child entity (entity anak). Untuk merepresentasikan
relasi ini, atribut primary key dari entity induk disalin ke tabel yang
mewakili entity anak, sebagai foreign key.
•
tipe relasi biner one-to-one (1:1)
Adapun relasi 1:1 yang terlibat berdasarkan batasan
partisipasinya yaitu:
a. Partisipasi mandatory pada kedua sisi dari relasi 1:1
Pada relasi jenis ini, entity yang terkait digabungkan
menjadi satu tabel dan primary key yang baru dipilih dari salah
satu entity asli sedangkan yang lainnya (jika ada) menjadi
alternate key.
b. Partisipasi mandatory pada satu sisi dari relasi 1:1
Pada relasi jenis ini, entity induk dan anak dapat
diidentifikasi. Entity yang memiliki partisipasi opsional adalah
entity
induk
sedangkan
entity yang
memiliki partisipasi
mandatory adalah entity anak. Untuk merepresentasikan relasi ini,
29
atribut primary key dari entity induk disalin ke tabel yang
mewakili entity anak, sebagai foreign key.
c. Partisipasi opsional pada kedua sisi dari relasi 1:1
Pada relasi jenis ini, penentuan entity induk dan anak tidak
pasti karena kedua sisi bersifat opsional. Dari dua entity pada
relasi ditentukan mana yang lebih bersifat mandatory dan entity
tersebut yang dijadikan entity anak. Untuk merepresentasikan
relasi ini, atribut primary key dari entity induk disalin ke tabel
yang mewakili entity anak, sebagai foreign key.
•
tipe relasi rekursif one-to-one (1:1);
Untuk relasi rekursif 1:1, aturan untuk partisipasi mengikuti
aturan yang dijabarkan pada relasi 1:1 di atas. Namun, pada kasus ini
entity pada kedua sisi adalah sama. Untuk relasi rekursif 1:1 dengan
partisipasi
mandatory
pada
kedua
sisi,
relasi
rekursif
direpresentasikan sebagai satu tabel dengan dua salinan primary key.
Seperti sebelumnya, satu salinan primary key sebagai foreign key dan
harus diganti namanya untuk mengidentifikasikan relasi yang
diwakilinya.
Untuk relasi rekursif 1:1 dengan partisipasi mandatory hanya
pada satu sisi, terdapat dua pilihan, yaitu membuat satu tabel dengan
dua salinan primary key seperti yang dideskripsikan di atas, atau
membuat tabel baru yang mewakili relasi itu. Tabel yang baru hanya
memiliki dua atribut, kedua salinan primary key. Seperti sebelumnya,
30
satu salinan primary key sebagai foreign key dan harus diganti
namanya untuk mengidentifikasikan tujuannya pada masing-masing
tabel.
Untuk relasi rekursif 1:1 dengan partisipasi optional pada
kedua sisi, dibuat tabel baru seperti yang dideskripsikan di atas.
•
tipe relasi superclass/ subclass
Untuk setiap relasi superclass/ subclass pada model data
konseptual, superclass entity diidentifikasikan sebagai entity induk
dan subclass entity sebagai entity anak.
•
tipe relasi biner many-to-many (*:*)
Untuk setiap relasi biner *:*, sebuah tabel dibuat untuk
merepresentasikan relasi tersebut dan meliputi semua atribut yang
merupakan bagian dari relasi. Satu salinan primary key dari entity
yang terlibat dalam relasi ditempatkan pada tabel baru, sebagai
foreign key. Satu atau dua dari foreign key ini juga akan membentuk
primary key pada tabel baru, kemungkinan merupakan kombinasi dari
satu atau lebih atribut dari relasi.
•
tipe relasi kompleks
Untuk setiap relasi kompleks, sebuah tabel dibuat untuk
merepresentasikan relasi tersebut dan meliputi semua atribut yang
merupakan bagian dari relasi. Satu salinan primary key dari entity
yang terlibat dalam relasi ditempatkan pada tabel baru, sebagai
foreign key. Semua foreign key yang merepresentasikan relasi many
31
secara umum akan membentuk primary key pada tabel baru,
kemungkinan merupakan kombinasi dari satu atau lebih atribut dari
relasi.
•
atribut multi-valued
Untuk setiap atribut multi-valued dalam sebuah entity, sebuah
tabel dibuat untuk merepresentasikan atribut multi-valued dan
meliputi primary key tiap entity pada tabel baru, sebagai foreign key.
Kecuali atribut multi-valued itu sendiri merupakan alternate key dari
entity, primary key dari tabel baru merupakan kombinasi dari atribut
multi-valued dan primary key dari entity.
Langkah 2.2
: Memvalidasi tabel menggunakan normalisasi
Tujuan dari langkah ini adalah untuk memvalidasi tabel dalam
model data logikal lokal menggunakan normalisasi.
Proses normalisasi dibahas lebih detil pada bagian 2.1.7.
Langkah 2.3
: Memvalidasi tabel terhadap transaksi pengguna
Tujuan dari langkah ini adalah untuk memastikan bahwa tabel
dalam model data logikal lokal mendukung transaksi yang dibutuhkan.
Validasi transaksi seperti ini sudah dilakukan pada langkah 1.8,
namun dilakukan kembali untuk memeriksa tabel-tabel yang dibuat pada
langkah sebelumnya juga mendukung transaksi dan memastikan bahwa
tidak ada error dalam tabel yang telah dibuat.
32
Langkah 2.4
: Memeriksa batasan integritas
Tujuan dari langkah ini adalah untuk memeriksa batasan-batasan
integritas yang direpresentasikan dalam model data logikal. Batasan
integritas adalah batasan-batasan yang diharapkan dapat melindungi
basis-data dari incomplete, inaccurate, atau inconsistent.
Berikut ini merupakan tipe-tipe batasan integritas yang harus
dipertimbangkan:
1. Required data
Beberapa atribut harus selalu mengandung sebuah nilai yang
valid (tidak null).
2. Attribute domain constraints
Setiap atribut harus mempunyai sebuah domain, dengan kata
lain, satu set nilai yang legal.
3. Multiplicity
Multiplicity merepresentasikan batasan-batasan yang berada di
dalam relasi antara data dalam basis-data.
4. Entity integrity
Primary key dari sebuah entity tidak mengandung null.
5. Referential integrity
Foreign key adalah sebuah atau beberapa key yang
menghubungkan setiap baris pada tabel anak yang mengandung
foreign key ke baris pada tabel induk yang mengandung nilai
candidate key yang sama. Referential integrity berarti bahwa jika
33
foreign key mengandung sebuah nilai maka nilai tersebut harus ada
pada sebuah baris di tabel induk.
6. General constraints
Merupakan aturan tambahan yang dibuat oleh pengguna atau
seorang database administrator pada basis-data tersebut.
Langkah 2.5
: Me-review
model
data
logikal
lokal
dengan
pengguna
Tujuan dari langkah ini adalah untuk memastikan bahwa model
data logikal merupakan representasi yang benar dari kebutuhan data
perusahaan.
Langkah 2.6
: Menggabungkan model data logikal ke dalam
model global (langkah opsional)
Tujuan dari langkah ini adalah untuk menggabungkan modelmodel data logikal lokal ke dalam sebuah model data logikal global yang
merepresentasikan pandangan semua pengguna dari sebuah basis-data.
Langkah 2.6.1
: Menggabungkan model data logikal lokal ke dalam
model global
Langkah 2.6.2
: Memvalidasi model data logikal global
Langkah 2.6.3
: Me-review model data logikal global dengan pengguna
Berikut ini adalah detil mengenai langkah-langkah yang telah
disebutkan di atas.
34
Langkah 2.6.1
: Menggabungkan model data logikal lokal ke
dalam model global
Tujuan dari langkah ini adalah untuk menggabungkan model data
logikal lokal ke dalam sebuah model data logikal global.
Beberapa tugas dari pendekatan ini adalah sebagai berikut:
•
Me-review nama dan isi dari entities/ relasi dan candidate key-nya
•
Me-review nama dan isi dari relasi/ foreign keys
•
Menggabungkan entities/ relasi dari model-model data lokal
•
Memasukkan (tanpa menggabungkan) entities/ relasi unik pada setiap
model data lokal
•
Menggabungkan relasi/ foreign keys dari model-model data lokal
•
Memasukkan (tanpa menggabungkan) relasi/ foreign keys unik pada
setiap model data
•
Memeriksa untuk entities/ relasi dan relasi/ foreign keys yang hilang
•
Memeriksa foreign keys
•
Memeriksa batasan integritas
•
Menggambar diagram ER/ relasi global
•
Mengubah dokumentasi
Langkah 2.6.2
: Memvalidasi model data logikal global
Tujuan dari langkah ini adalah untuk memvalidasi tabel yang
dibuat dari model data logikal global dengan menggunakan teknik
35
normalisasi dan memastikan bahwa tabel yang dibuat mendukung
transaksi yang dibutuhkan, jika perlu.
Langkah 2.6.3
: Me-review model data logikal global dengan
pengguna
Tujuan dari langkah ini adalah untuk memastikan bahwa model
data logikal global merupakan representasi yang benar dari kebutuhan
data perusahaan.
Langkah 2.7
: Memeriksa untuk pertumbuhan masa yang akan
datang
Tujuan dari langkah ini adalah untuk menentukan apakah ada
perubahan yang berarti di masa yang akan datang dan untuk menilai
apakah model data logikal dapat mengakomodasi perubahaan tersebut.
Perancangan model data logikal harus dapat diperluas sehingga
dapat mendukung kebutuhan-kebutuhan baru di masa mendatang dengan
dampak yang minimal terhadap pengguna yang telah ada.
36
Gambar 2.3 Contoh ERD Logikal pada Kasus DreamHome
2.1.5.3 Perancangan Basis-Data Fisikal
Langkah 3:
Menerjemahkan Model Data Logikal untuk DBMS
Pilihan
37
Tujuan dari langkah ini adalah untuk menghasilkan skema basisdata relasional dari model data logikal yang dapat diimplementasikan
pada DBMS pilihan.
Bagian pertama dari proses ini memerlukan perbandingan
informasi yang dikumpulkan selama perancangan basis-data logikal dan
didokumentasikan dalam kamus data. Bagian kedua dari proses ini
menggunakan informasi tersebut untuk menghasilkan desain tabel dasar.
Proses ini membutuhkan pengetahuan yang mendalam mengenai
fungsionalitas yang ditawarkan oleh DBMS pilihan.
Langkah 3.1
: Merancang tabel dasar
Langkah 3.2
: Merancang representasi dari data turunan (derived
data)
Langkah 3.3
: Merancang batasan umum (general constraints)
Berikut ini adalah detil mengenai langkah-langkah yang telah
disebutkan di atas.
Langkah 3.1
: Merancang tabel dasar
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan tabel dasar yang telah diidentifikasikan dalam model
data logikal pada DBMS pilihan.
Untuk memulai proses perancangan fisikal, yang pertama
dilakukan adalah mengumpulkan dan mengasimilasikan informasi
mengenai tabel-tabel yang dihasilkan selama perancangan basis-data
logikal. Informasi yang diperlukan bisa diperoleh dari kamus data dan
38
definisi dari tabel-tabel yang dideskripsikan menggunakan Database
Design Language (DBDL). Untuk setiap tabel yang diidentifikasi pada
model data logikal, definisi yang dimiliki terdiri dari:
•
nama tabel
•
daftar atribut simple
•
primary key, alternative keys (AK), dan foreign keys (FK)
•
batasan integrasi untuk setiap foreign keys yang diidentifikasi
Dari kamus data, untuk setiap atributnya dapat diketahui:
•
domain atribut tersebut yang terdiri dari tipe data, panjang dan
berbagai keterangan atribut tersebut
•
suatu nilai default opsional untuk atribut tersebut
•
apakah atribut tersebut dapat diisi nilai null
•
apakah atribut tersebut hasil turunan (derived) dan jika ya, bagaimana
perhitungannya
Langkah 3.2
: Merancang representasi dari data turunan (derived
data)
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan semua data turunan dalam model data logikal pada
DBMS pilihan.
39
Atribut yang nilainya didapatkan dengan mengevaluasi nilai dari
atribut lain dikenal sebagai derived atau calculated attributes (atribut
turunan). Sebagai contoh:
•
banyaknya pegawai yang bekerja pada cabang tertentu
•
total gaji bulanan seluruh pegawai
•
banyaknya properti yang ditangani oleh seorang pegawai
Langkah 3.3: Merancang batasan umum (general constraints)
Tujuan dari langkah ini adalah merancang batasan umum untuk
DBMS pilihan.
Perancangan batasan tergantung pada pilihan DBMS; beberapa
sistem menyediakan lebih banyak fasilitas untuk mendefinisikan batasan
umum dibandingkan sistem yang lain. Seperti pada langkah sebelumnya,
jika sistem tersebut mempunyai aturan yang sesuai standar SQL,
beberapa batasan dapat diimplementasikan dengan mudah.
Langkah 4:
Tujuan
Merancang Organisasi File dan Indeks
dari
langkah
ini
adalah
untuk
menentukan
pengorganisasian file yang optimal untuk menyimpan relasi-relasi dasar
dan indeks-indeks yang diperlukan untuk mencapai performansi yang
diinginkan, yaitu cara penyimpanan tabel-tabel dan baris-baris (tuples)
pada media penyimpanan sekunder.
Langkah 4.1
: Menganalisis transaksi
40
Langkah 4.2
: Memilih organisasi file
Langkah 4.3
: Memilih indeks
Langkah 4.4
: Memperkirakan kebutuhan disk space
Berikut ini adalah detil mengenai langkah-langkah yang telah
disebutkan di atas.
Langkah 4.1
: Menganalisis transaksi
Tujuan dari langkah ini adalah untuk memahami fungsi dari
transaksi-transaksi yang akan dijalankan pada basis-data dan untuk
menganalisis transaksi-transaksi yang penting. Proses yang dilakukan
untuk menganalisis transaksi yaitu:
1. Memetakan semua alur transaksi ke tabel
Pada tahap ini, sebuah transaction/ relation cross-reference
matrix dibuat. Matrix ini menunjukkan transaksi-transaksi yang
dibutuhkan dan tabel-tabel yang diakses.
2. Menentukan tabel mana yang paling sering diakses oleh transaksi
3. Menganalisis penggunaan data dari transaksi yang terpilih yang
melibatkan tabel yang paling sering diakses tersebut
Langkah 4.2
: Memilih organisasi file
Tujuan dari langkah ini adalah untuk menentukan organisasi file
yang efisien untuk setiap relasi dasar.
Dalam banyak kasus, suatu relational DBMS hanya memberikan
sedikit bahkan tidak ada pilihan untuk memilih organisasi file, walaupun
41
beberapa mungkin dibangun saat indeks dispesifikasikan. Berikut ini
beberapa organisasi file:
•
Heap
•
Hash
•
Indexed Sequential Access Method (ISAM)
•
B*-tree
•
Clusters
Langkah 4.3
: Memilih indeks
Tujuan dari langkah ini adalah untuk menentukan apakah
penambahan indeks akan meningkatkan performansi sistem.
Pemilihan atribut untuk mengurutkan atau mengelompokkan baris
sebagai:
•
atribut yang paling sering digunakan untuk operasi penggabungan
(join operations), sehingga membuat operasi penggabungan menjadi
lebih efisien, atau
•
suatu atribut yang digunakan paling banyak untuk mengakses suatu
record di dalam relasi yang ada.
Langkah 4.4
: Memperkirakan kebutuhan disk space
Tujuan dari langkah ini adalah untuk memperkirakan ukuran disk
space yang dibutuhkan oleh basis-data.
42
Langkah 5:
Merancang User Views
Tujuan dari langkah ini adalah untuk merancang user views yang
diidentifikasi selama tahap pengumpulan kebutuhan dan analisis dari
siklus pengembangan sistem basis-data.
Langkah 6:
Merancang Mekanisme Keamanan
Tujuan dari langkah ini adalah untuk merancang mekanisme
untuk basis-data seperti yang dispesifikasikan oleh pengguna selama
tahap pengumpulan kebutuhan dari siklus pengembangan sistem basisdata.
Basis-data merepresentasikan resource dari perusahaan yang
essensial, maka dari itu keamanan dari resource ini sangatlah penting.
Beberapa isu keamanan basis-data yang perlu diperhatikan antara
lain:
1. Pencurian data (Theft and Fraud)
2. Kehilangan kerahasiaan suatu data (Loss of Confindentially)
3. Kehilangan hak pribadi (Loss of Privacy)
4. Kehilangan integritas (Loss Integrity)
5. Kehilangan ketersediaan data (Loss of Avaliability)
2.1.6
ER Modeling
2.1.6.1 Tipe Entity
Menurut Connolly (2005, p343), “Entity type is a group of objects
with the same properties, which are identify by the enterprise as having
43
an independent existence”, dapat diartikan: tipe entity adalah sekumpulan
objek yang memiliki properties yang sama yang diidentifikasikan oleh
perusahaan memiliki keberadaan yang independen.
Representasi diagramatik dari tipe entity terlihat pada Gambar 2.4.
Gambar 2.4 Representasi Diagramatik dari Tipe Entity
2.1.6.2 Tipe Relasi
Menurut Connolly (2005, p346), ”relationship type is a set of
meaningful associations among entity types”, dapat diartikan: tipe relasi
adalah sekumpulan asosiasi yang berarti di antara tipe-tipe entity.
Representasi diagramatik dari tipe relasi terlihat pada Gambar 2.5.
Gambar 2.5 Representasi Diagramatik dari Tipe Relasi
44
2.1.6.3 Atribut
Menurut Connolly (2005, p350), “Attribute is a property of an
entity or a relationship type”, dapat diartikan: atribut adalah property dari
sebuah entity atau tipe relasi.
Atribut terdiri dari:
1. Simple Attributes dan Composite Attributes
Simple attribute adalah atribut yang terdiri dari komponen
tunggal dengan keberadaan independen. Simple attribute kadang
disebut juga atribut atomik.
Composite attribute adalah atribut yang terdiri dari banyak
komponen, masing-masing dengan keberadaan independen.
2. Single-Valued Attributes dan Multi-Valued Attributes
Single-valued attribute adalah atribut yang memiliki nilai
tunggal untuk masing-masing kejadian dari sebuah tipe entity.
Multi-valued attribute adalah atribut yang memiliki banyak
nilai untuk masing-masing kejadian dari sebuah entity.
3. Derived Attributes
Derived attribute adalah atribut yang merepresentasikan
sebuah nilai yang diturunkan dari nilai sebuah atau sekumpulan
atribut yang berhubungan. Atribut tersebut tidak harus pada tipe entity
yang sama.
45
2.1.6.4 Key
1. Candidate Key
Menurut Connolly (2005, p352), “candidate key is the
minimal set of attributes that uniquely identifies each occurrence of
an entity type”, dapat diartikan: candidate key adalah sekumpulan
minimal atribut yang secara unik mengidentifikasi setiap kejadian
dari sebuah tipe entity.
2. Primary Key (PK)
Menurut Connolly (2005, p353), “primary key is the
candidate key that is selected to uniquely identify each occurrence of
an entity type”, dapat diartikan: primary key adalah candidate key
yang dipilih untuk mengidentifikasikan secara unik setiap kejadian
dari sebuah tipe entity.
3. Composite Key
Menurut Connolly (2005, p353), “composite key is a
cancidate key that consists of two or more attributes”, dapat diartikan:
composite key adalah candidate key yang terdiri dari dua atau lebih
atribut.
Representasi diagramatik dari tipe entity beserta atribut dan
primary key terlihat pada Gambar 2.6.
46
Gambar 2.6 Representasi Diagramatik Tipe Entity Beserta
Atribut dan PK
2.1.6.5 Structural Constraints (Batasan Struktural)
Menurut Connolly (2005, p356), tipe utama dari batasan pada
relasi disebut multiplicity.
Multiplicity adalah jumlah (jangkauan) dari kejadian yang
mungkin pada sebuah tipe entity yang terhubung ke suatu kejadian
tunggal pada tipe entity lain melalui sebuah relasi khusus.
Hubungan biner secara umum dibedakan menjadi:
1. Relasi One to One (1:1)
Relasi antar entity One to One (1:1) terjadi bila tiap anggota
dari entity A hanya boleh berpasangan dengan satu anggota dari entity
B, dan tiap anggota dari entity B hanya boleh berpasangan dengan
satu anggota dari entity A.
47
2. Relasi One to Many (1:*)
Relasi antar entity One to Many (1:*) terjadi bila tiap anggota
dari entity A hanya boleh berpasangan dengan satu anggota dari entity
B, dan entity B boleh berpasangan dengan satu atau lebih anggota dari
entity A.
3. Relasi Many to Many (*:*)
Relasi antar entity Many to Many (*:*) terjadi bila tiap
anggota dari entity A boleh berpasangan dengan satu atau lebih
anggota dari entity B, dan tiap anggota dari entity B boleh
berpasangan dengan satu atau lebih anggota dari entity A.
2.1.7
Normalisasi
2.1.7.1 Pengertian Normalisasi
Menurut Connolly (2005, p388), “normalization is a technique for
producing a set of relation with desirable properties, given the data
requirements of an enterprise”, dapat diartikan sebagai normalisasi
adalah teknik untuk menghasilkan sekumpulan tabel dengan properties
yang diinginkan, sesuai dengan kebutuhan data dari perusahaan.
Normalisasi sering dilakukan sebagai rangkaian dari pengujian pada
suatu tabel untuk menentukan apakah tabel tersebut benar atau melanggar
persyaratan dari bentuk normal yang ditentukan.
48
2.1.7.2 Tahap-Tahap Normalisasi
2.1.7.2.1 Unnormalized Form (UNF)
Menurut Connolly (2005, p403), “unnormalized form
(UNF) is a table that contains one or more repeating groups”,
dapat diartikan sebagai UNF adalah sebuah tabel yang berisikan
satu atau lebih kumpulan data yang berulang.
2.1.7.2.2 First Normal Form (1NF)
Menurut Connolly (2005, p403), “first normal form (1NF)
is a relation in which the intersection of each row and column
contains one and only one value”, dapat diartikan sebagai 1NF
adalah sebuah tabel di mana setiap irisan antara baris dan kolom
berisikan satu dan hanya satu nilai.
Proses normalisasi dimulai dengan memindahkan data dari
sumber (sebagai contoh, formulir pengisian data standar) ke
dalam format tabel dengan baris dan kolom. Pada format ini, tabel
dalam UNF dan disebut sebagai table tidak ternormalisasi. Untuk
mengubah tabel tidak ternormalisasi ke dalam 1NF perlu
mengidentifikasi dan menghilangkan repeating groups dalam
tabel. Repeating groups adalah sebuah atribut atau sekelompok
atribut, dalam sebuah tabel yang muncul dengan banyak nilai
untuk sebuah kejadian dari atribut kunci yang ditunjuk pada tabel
tersebut. Dalam konteks ini, kata “kunci” ditujukan untuk atribut
49
yang mengidentifikasi setiap baris secara unik dalam tabel tidak
ternormalisasi.
Terdapat
dua
pendekatan
umum
untuk
menghilangkan repeating groups dari tabel tidak ternormalisasi:
1. Masukkan data yang sesuai ke dalam kolom yang kosong
pada baris yang berisikan data berulang
2. Meletakkan data berulang bersama dengan salinan atribut
kunci, ke dalam relasi terpisah
2.1.7.2.3 Second Normal Form (2NF)
Menurut Connolly (2005, p407), “second normal form
(2NF) is a relation that is in first normal form and every nonprimary-key attribute is fully functionally dependent on the
primary key”, diartikan sebagai 2NF adalah sebuah tabel dalam
1NF dan setiap atribut non-primary key bergantung secara penuh
pada primary key.
Normalisasi dari tabel 1NF ke 2NF dilakukan dengan cara
menghilangkan atribut yang bergantung secara fungsional dengan
meletakkan atribut tersebut ke dalam tabel yang baru bersama
dengan salinan dari determinannya.
2.1.7.2.4 Third Normal Form (3NF)
Menurut Connolly (2005, p409), “third normal form
(3NF) is a relation that is in first and second normal form, and in
which no non-primary key attribute is transitively dependent on
50
the primary key”, dapat diartikan sebagai 3NF adalah sebuah tabel
dalam 1NF dan 2NF, dan tidak ada atribut non-primary key yang
bergantung secara transitif terhadap primary key.
Ketergantungan transitif adalah keadaan di mana suatu
atribut non-primary key bergantung pada atribut non-primary key.
Normalisasi dari 2NF ke 3NF dilakukan dengan cara
meletakkan atribut yang bergantung secara transitif ke dalam
sebuah
relasi
yang
baru
bersama
dengan
salinan
dari
determinannya.
2.2 Teori Pembelian, Penjualan dan Persediaan
2.2.1
Teori Pembelian
Menurut Mulyadi (2001, p299), pembelian didefinisikan sebagai
suatu usaha yang digunakan dalam perusahaan untuk pengadaan barang yang
diperlukan oleh perusahaan.
Transaksi
pembelian
menurut
Mulyadi
(2001,
p299), dapat
digolongkan menjadi dua, yaitu:
•
Pembelian lokal, yaitu pembelian dari pemasok dalam negeri.
•
Pembelian impor, yaitu pembelian dari luar negeri.
Fungsi yang terkait dalam sistem pembelian (Mulyadi, 2001, p299)
adalah:
1. Fungsi gudang, bertanggung jawab untuk mengajukan permintaan
pembelian sesuai dengan posisi persediaan yang ada di gudang.
51
2. Fungsi pembelian, bertanggung jawab untuk mengeluarkan order
pembelian kepada pemasok.
3. Fungsi penerimaan, bertanggung jawab untuk menerima barang yang
dikirim dari pemasok dan melakukan pemeriksaan guna menentukan
layak tidaknya barang untuk diterima.
4. Fungsi akuntansi, fungsi yang terkait dalam hal ini adalah fungsi pencatat
utang dan fungsi pencatat persediaan.
Jaringan prosedur yang membentuk sistem pembelian (Mulyadi, 2001,
p301) adalah sebagai berikut:
1. Prosedur permintaan pembelian
Fungsi gudang mengajukan permintaan pembelian dalam formulir surat
permintaan pembelian kepada fungsi pembelian.
2. Prosedur order pembelian
Fungsi pembelian mengirim surat order pembelian kepada pemasok dan
memberitahukan kepada unit-unit lain (misalnya fungsi penerimaan,
fungsi yang meminta barang, fungsi pencatat utang) mengenai order
pembelian yang sudah dikeluarkan.
3. Prosedur penerimaan barang
Fungsi penerimaan melakukan pemeriksaan terhadap barang yang
diterima dari pemasok dan kemudian membuat laporan penerimaan
barang.
52
4. Prosedur pencatat uang
Fungsi akuntansi memerika dokumen-dokumen yang berhubungan
dengan pembelian dan menyelenggarakan utang.
5. Prosedur distribusi pembelian
Prosedur ini meliputi distribusi rekening yang didebit dari transaksi
pembelian untuk kepentingan pembuatan laporan manajemen.
Dokumen-dokumen yang digunakan dalam sistem pembelian adalah
sebagai berikut:
1. Surat permintaan pembelian
Merupakan formulir yang diisi oleh pemakai atau fungsi gudang untuk
meminta dilakukannya pembelian barang dengan jenis, mutu dan jumlah
yang sesuai dengan surat tersebut.
2. Surat permintaan penawaran harga
Dokumen yang digunakan untuk meminta penawaran harga bagi barang
yang pengadaannya tidak bersifat repetitif, yang menyangkut jumlah
rupiah pembelian yang besar.
3. Surat order pembelian
Merupakan dokumen yang digunakan untuk memesan barang kepada
pemasok yang telah dipilih.
4. Laporan penerimaan barang
Dokumen ini dibuat oleh fungsi penerimaan barang untuk menunjukkan
bahwa barang yang diterima dari pemasok telah memenuhi mutu dan
kuantitas seperti yang telah dicantumkan dalam surat order.
53
5. Laporan pembayaran
Merupakan dokumen yang menunjukkan besarnya pembayaran yang
dilakukan dan juga detil pembayaran yang dilakukan.
2.2.2
Teori Penjualan
Menurut Romney dan Steinbart (2002, p517), penjualan merupakan
suatu set rekursif dari kegiatan bistis dan operasi pemrosesan informasi
terkait yang dihubungkan dengan penyediaan barang dan pelayanan
pelanggan serta penerimaan pembayaran dari penjualan tersebut.
Fungsi yang terkait dalam sistem penjualan (Mulyadi, 2001, p211)
adalah:
1. Fungsi penjualan, bertanggung jawab untuk menerima order, mengedit
order, meminta otorisasi kredit, menentukan tanggal pengiriman dan
bertanggung jawab atas transaksi penjualan.
2. Fungsi gudang, bertanggung jawab untuk menyimpan dan menyiapkan
barang yang dipesan menyerahkan barang ke fungsi pengiriman.
3. Fungsi pengiriman, bertanggung jawab menyerahkan barang kepada
pelanggan berdasarkan surat jalan yang diterimanya dari fungsi penjualan.
4. Fungsi penagihan, bertanggung jawab membuat dan mengirimkan faktur
penjualan kepada pelanggan, serta menyiapkan kopian faktur bagi
kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi.
5. Fungsi akuntansi, bertanggung jawab mencatat piutang yang timbul dari
transaksi penjualan dan membuat laporan penjualan.
54
Jaringan prosedur yang membentuk sistem penjualan (Mulyadi, 2001,
p219) adalah sebagai berikut:
1. Prosedur order penjualan
Fungsi penjualan menerima order dari pembeli dan menambahkan
informasi penting pada surat order. Fungsi penjualan kemudian membuat
surat jalan dan mengirimkannya kepada berbagai fungsi yang lain untuk
memungkinkan fungsi tersebut memberikan kontribusi dalam melayani
order dan pembeli.
2. Prosedur pengiriman
Fungsi pengiriman mengirimkan barang kepada pembeli sesuai dengan
informasi yang tercantum dalam surat jalan
3. Prosedur penagihan
Fungsi penagihan membuat faktur penjualan dan mengirimkannya kepada
pembeli. Dalam metode tertentu faktur penjualan dibuat oleh fungsi
penjualan sebagai tembusan pada waktu bagian ini membuat surat jalan.
4. Prosedur pencatatan piutang
Fungsi akuntansi mencatat tembusan faktur penjualan ke dalam kartu
piutang atau dalam metode pencatatan tertentu mengarsipkan dokumen
tembusan menurut abjad yang berfungsi sebagai catatan piutang.
5. Prosedur distribusi penjualan
Fungsi akuntansi mendistribusikan data penjualan menurut informasi
yang diperlukan oleh manajemen.
55
Dokumen-dokumen
yang
digunakan
dalam
sistem
penjualan
(Mulyadi, 2001, p214) meliputi:
1. Surat jalan dan tembusannya
2. Faktur dan tembusannya
3. Rekapitulasi harga pokok penjualan
4. Bukti memorial
2.2.3
Teori Persediaan
Menurut Rangkuti (1998, p2), persediaan merupakan sejumlah bahanbahan, bagian-bagian yang disediakan dan bahan-bahan dalam proses yang
terdapat dalam perusahaan untuk proses produksi, serta barang-barang jadi
atau produk yang disediakan untuk memenuhi permintaan dari konsumen
atau langganan setiap waktu. Dengan kata lain persediaan merupakan salah
satu unsur yang paling aktif dalam operasi perusahaan yang secara terus
menerus diperoleh, diubah, yang kemudian dijual kembali.
Jenis-jenis persediaan menurut fungsinya:
1. Batch Stock / Lot Size Inventory
Persediaan yang diadakan karena kita membeli atau membuat bahanbahan atau barang-barang dalam jumlah yang lebih besar dari jumlah
yang dibutuhkan saat itu.
2. Fluctuation Stock
Persediaan yang diadakan untuk menghadapi fluktuasi permintaan
konsumen yang tidak dapat diramalkan.
56
3. Anticipation Stock
Persediaan yang diadakan untuk menghadapi fluktuasi permintaan yang
dapat diramalkan, berdasarkan pola musiman yang terdapat dalam satu
tahun dan untuk menghadapi penggunaan atau penjualan atau permintaan
yang meningkat.
2.3 Data Flow Diagram (DFD)
Menurut Whitten (2004, p344), “data flow diagram (DFD) is a tool that
depicts the flow of data through a system and the work or processing performed by
that system”, dapat diartikan: DFD adalah sebuah alat yang menggambarkan aliran
data melalui sistem dan pekerjaan atau pemrosesan yang dijalankan oleh sistem
tersebut. Sinonimnya adalah bubble chart, transformation graph dan process model.
Terdapat empat komponen dalam DFD, yaitu:
1. External Agents
Menurut Whitten (2004, p363), “external agents define a person, an
organization unit, another system, or another organization that lies outside the
scope of the project but that interacts with the system being studied”, dapat
diartikan: external agents mendefinisikan orang, unit organisasi, sistem lain, atau
organisasi lain, yang berada di luar lingkup proyek itu tetapi berinteraksi dengan
sistem yang sedang dipelajari.
Menurut Whitten (2004, p365), ada beberapa bentuk external agents,
yaitu:
57
a. Bentuk Gane and Sarson (digunakan dalam skripsi ini)
External
Agent
b. Bentuk DeMarco/ Yourdon
External
Agent
2. Process
Menurut Whitten (2004, p347), “process is work performed on, or in
response to, incoming data flows or conditions”, dapat diartikan: process adalah
pekerjaan yang dilakukan pada atau sebagai respon terhadap, aliran data masuk
atau kondisi.
Menurut Whitten (2004, p347), ada beberapa bentuk process, yaitu:
a. Bentuk Gane and Sarson (digunakan dalam skripsi ini)
Nama
process
b. Bentuk DeMarco/ Yourdon
Nama
process
58
c. Bentuk SSADM/ IDEF0
Nama
process
3. Data Stores
Menurut Whitten (2004, p366), “data store is an “inventory” of data”,
dapat diartikan: data stores adalah tempat penyimpanan data. Sinonimnya antara
lain file dan basis-data.
Menurut Whitten (2004, p366), ada beberapa bentuk data stores, yaitu:
a. Bentuk Gane and Sarson (digunakan dalam skripsi ini)
Data store
b. Bentuk DeMarco/ Yourdon
Data store
4. Data Flows
Menurut Whitten (2004, p357), “data flow represents an input of data to
a process or the output of data (or informaton) from a process”, dapat diartikan:
data flow merepresentasikan input data ke proses atau output data (informasi)
dari proses.
Bentuk data flow:
Nama aliran data
59
Jenis-jenis DFD adalah sebagai berikut:
1. Level 0 (Diagram Context)
Level ini terdapat sebuah proses yang berada pada posisi pusat.
2. Level 1 (Diagram 0)
Level ini merupakan sebuah proses yang terdapat pada level 0 yang
dipecah menjadi beberapa proses lainnya.
3. Level 2 (Diagram Rinci)
Level ini merupakan diagram yang merincikan diagram dari level 1.
Tanda ‘*’ digunakan hanya bila proses tersebut tidak dapat dirincikan
lagi. Contoh: 2.0* artinya proses level rendah yang tidak dapat dirincikan lagi.
Penomoran yang dilakukan berdasarkan urutan proses.
2.4 PHP, MySQL, dan Macromedia Dreamweaver MX
2.4.1
PHP
PHP sebagai bahasa pemrograman web cukup banyak digemari, salah
satunya karena memberikan solusi sangat murah (gratis digunakan ). Gratis
dalam arti bebas menggunakan software tersebut tanpa harus membayar
lisensi pemegang hak ciptanya Teguh Wahyono (2005, p8).
Sejarah perkembangan PHP antara lain M. Syafii(2005, h1):
•
PHP/FI
Pertama kali PHP dibuat dan diperkenalkan oleh Rasmus Lerdorf
pada tahun 1995 menggunakan nama PHP/FI. Generasi awal PHP/FI
dibuat dari Perl yang waktu itu digubnakan untuk kebutuhan pribadi saja.
Pada awalnya, PHP/FI merupakan bagian dari Personal Home Page
60
Tools. Namun, karena kebutuhan penggunaan web yang semakin
kompleks, maka dikembangkan PHP/FII dengan menggunakan bahasa C.
Rasmus menulis sejumlah besar fungsi untuk pengaksesan ke dalam
basis-data. Penulisan ini juga bertujuan membangun halaman web
menjadi dinamis.
PHP/FI merupakan akronim dari Personal Home Page/ Forms
Interpreter. Pada awal penyusunan PHP/FI hanay mempunyai fungsi
dasar dari PHP yang ada sekarang ini. Jadi, dengan kata lain, pondasi
PHP sekarang ini adalah PHP/FI. Karena ketika pertama dibuat
menggunakan Perl, maka PHP/FI juga mempunyai susunan dan karakter
pemrograman yang sama dengannya.
Pada tahun 1997, dikeluarkan PHP/FI versi 2.0. fungsi-fungsi
pada PHP/FI ditulis dengan menggunakan bahasa C. karena telah
memiliki fungsi khusus untuk mengakses basis-data, maka pada tahun
yang samaterdapat kurang lebih 50.000 domain menggunakan PHP/FI
sebagai bahasa pemrograman website, atau sekitar 1% dari total domain
yang ada pada waktu itu. Booming PHP/FI tersebut membuat semakin
banyak orang yang tertarik untuk berpartisipasi mengembangkan PHP/FI.
Berkat kerja sama dan kontribusi mereka, PHP versi 3.0 pun dikeluarkan
walau kala itu masih dalam tahap alpha.
•
PHP 3
PHP 3 merupakan generasi baru hasil pengembangan PHP/FI.
Banyak developer yang terlibat di dalamnya. Tak heran jika PHP 3
dianggap sebagai tonggak awal bagi terciptanya PHP versi sekarang ini.
61
Secara resmi, peluncur PHP 3.0 ialah Andi Gutmans dan Zeev Suraski
pada tahun 1997. Mereka mengeluarkan PHP 3.0 karena melihat
kelemahan dari PHP/FI yang digunakan dalam aplikasi e-commerce.
Kemudian, mereka menulis ulang dengan masih mengacu pada PHP/FI.
Setelah PHP 3.0 dikeluarkan, mereka menyarankan untuk menghentikan
proyek PHP/FI karena PHP 3.0 masih lebih baik.
Alasan untuk mengembangkan PHP, merupakan akronim dari
Hypertext Preprocessor, dan memfokuskan diri pada PHP 3.0 adalah
pengembangan versi ini secara meluas dalam mendukung berbagai jenis
basis-data, protocol dan API. Dengan dukungan yang semakin besar dari
berbagai pihak yang menyumbangkan berbagai modul, maka pada tahun
1998, 10 % dari seluruh webserver yang ada kala itu telah menginstalasi
PHP versi 3.0.
•
PHP 4
PHP versi 4 diluncurkan untuk menangani kelemahan PHP 3.0
yaitu penggunaan fungsi yang begitu kompleks. Kurangnya efisien waktu
dan kinerja yang buruk diperbaiki dan ditulis ulang dari inti PHP 3.
Dengan penambahan fitur baru seperti session, output buffering dan
pemrograman berbasis web. Selain itu, inti perbedaan mereka terletak
pada penggunaan Zend Engine. Zend Engine merupakan inti dari PHP.
Sebagai bagian dari inti PHP, secara fungsional bertugas
menangani input, menerjemahkan dan mengeksekusinya. Ia juga berperan
menerjemahkan fungsi.
62
•
PHP 5
PHP versi 5 muncul menangani kelemahan-kelemahan yang
terletak pada versi sebelumnya. PHP versi 5 dapat membuat file swf dan
applet java. Secara resmi, PHP versi 5 diluncurkan pada Desember 2005.
Fokus utamanya adalah mengoptimalkan penggunaan PHP untuk OOP
(Object Oriented Programming).
2.4.2
MySQL
MySQL adalah DBMS yang pada awalnya adalah miniSQL yang
dikembangkan oleh MySQL AB (Perusahaan IT Swedia) sejak tahun 1979 di
bawah komando Michael Widenius Monty. MySQL 1.0 dikeluarkan pada
Mei 1996 secara terbatas untuk kalangan sendiri. Baru dilepas ke publik pada
Oktober 1996 setelah muncul versi 3 Teguh Wahyono (2005,p10).
Versi awal MySQL hanya berjalan di atas Linux dan Solaris. Setelah
versi 3.22, MySQL mulai berjalan di berbagai platform termasuk Windows.
Sejak tahun 2000, MySQL muncul sebagai produk open source sejati
menggunakan lisensi GPL (General Public License). MySQL merupakan
salah satu basis-data terbesar yang digunakan dalam pemgolahan data di
dunia. Hal ini terbukti digunakannya MySQL oleh beberapa perusahaan
besar dan institusi besar dunia seperti NASA(USA), Yahoo!Finance,
Aizawa(Japanese Security) dan lain-lain.
Menurut Nugroho (2004, p29), MySQL adalah sebuah program
pembuat database yang bersifat open source, yang artinya siapa saja boleh
menggunakannya dan tidak akan dicekal. MySQL juga merupakan program
63
pengakses database yang bersifat jaringan sehingga dapat digunakan untuk
aplikasi multi users (banyak pengguna). Kelebihan lainnya dari MySQL
adalah bahasa query standar yang dimiliki SQL (Stucture Query Language).
MySQL
mendukung
berbagai
tipe
data
yang
antara
lain
dikelompokkan dalam tipe data numerik, tanggal, waktu dan string. Pada
Tabel 2.1 disebutkan beberapa tipe data yang digunakan dalam skripsi ini
beserta dengan kebutuhan penyimpanannya.
Tabel 2.1 Tipe Data dan Kebutuhan Penyimpanannya
Tipe Data
TINYINT(1)
TINYINT
SMALLINT
INTEGER
DATE
CHAR(M)
VARCHAR(M)
2.4.3
Kebutuhan Penyimpanan
1 bit
1 byte
2 bytes
4 bytes
3 bytes
M × 1 byte
(panjang string × 1 byte) + 1 byte
Macromedia Dreamweaver MX
Macromedia Dreamweaver MX adalah sebuah HTML editor
profesional untuk mengdesain secara visual dan mengelola situs web maupun
halaman web. Dreamweaver membuatnya jadi lebih mudah dengan
menyediakan tools yang sangat berguna dalam meningkatkan kemampuan
dan pengalaman membuat web.
Dreamweaver juga mengikutsertakan banyak tools untuk kode-kode
dalam hal web beserta fasilitas-fasilitasnya antara lain: referensi HTML, CSS,
64
JavaScript debugger dan code editor yang mengijinkan pengeditan kode
JavaScript XML dan dokumen teks lain secara langsung dalam Dreamweaver.