Upload
trandung
View
215
Download
0
Embed Size (px)
Citation preview
5
BAB 2
LANDASAN TEORI
2.1 Teori - Teori Umum
2.1.1 Basis Data
Pengertian basis data menurut Connoly dan Begg (2002, p14), basis data
adalah penggunaan bersama dari data yang terhubung secara logik dan deskripsi dari
data, yang dirancang untuk keperluan informasi dari suatu perusahaan.
Database merupakan kumpulan file-file yang saling berelasi, relasi tersebut
biasa ditujukan dengan kunci dari setiap file yang ada. Kegunaan dari database:
1. Menghilangkan data yang berulang (redundancy)
2. Akses data yang terbatas.
3. Meningkatkan keamanan.
4. Multiple User.
5. Independensi data (kebebasan data).
2.1.2 Database Management System (DBMS)
Database Management System (DBMS) adalah suatu sistem perangkat lunak
yang memungkinkan user untuk mendefinisikan, membuat, dan mengatur basis data
dan juga menyediakan suatu kontrol akses ke database (Connolly, 2002, p16).
DBMS berinteraksi dengan program aplikasi user dan basis data. DBMS
menyediakan fungsi-fungsi sebagai berikut :
6
1. DBMS mengizinkan aplikasi mendefinisikan struktur dari basis data dengan
pernyataan SQL. Pernyataan SQL yang mendefinisikan atau mengubah struktur
ini disebut dengan Data Definition Language (DDL).
2. DBMS mengizinkan aplikasi memanipulasi informasi yang disimpan didalam
basis data dengan pernyataan SQL. Pernyataan SQL yang memanipulasi
informasi ini disebut dengan Data Manipulation Language (DML).
2.1.2.1 Komponen - Komponen DBMS
DBMS memiliki lima komponen penting (Connolly, 2002, p18-20) yaitu:
1. Hardware ( perangkat keras )
Dalam menjalankan aplikasi dan DBMS diperlukan perangkat keras yang dapat
berupa a single personal computer, single mainframe, komputer jaringan berupa
server.
2. Software ( perangkat lunak )
Komponen perangkat lunak meliputi DBMS software dan aplikasi program
berserta sistem operasi (OS), termasuk perangkat lunak tentang jaringan bila
DBMS digunakan dalam jaringan berupa LAN.
3. Data
Data merupakan komponen terpenting dalam DBMS khususnya sudut pandang
dari end user mengenai data.
4. Prosedur
Prosedur merupakan panduan dan instruksi dalam membuat desain dan
menggunakan basis data. Prosedur didalam basis data dapat berupa : login di
dalam basis data, penggunaan sebagian fasilitas DBMS, cara menjalankan dan
7
menghentikan DBMS, mebuat backup database, memeriksa hardware dan
software yang sedang berjalan, mengubah struktur basis data, meningkatkan
kinerja atau mebuat arsip data pada secondary storage.
5. Manusia.
Komponen terakhir yaitu manusia yang terlibat dalam sistem tersebut.
2.1.2.2 Keuntungan dan Kerugian DBMS
Menurut McLeod (2001, p269), keuntungan DBMS adalah sebagai berikut:
1. Mengurangi pengulangan data.
Jumlah total file akan berkurang dengan menghapus file-file duplikat atau dengan
menghapus data yang sama di beberapa file.
2. Mencapai idependensi data.
Spesifikasi data disimpan dalam skema daripada dalam tiap program aplikasi.
Perubahaan dapat dibuat pada struktur data tanpa mengurangi program yang
mengakses data.
3. Mengintegrasikan data dari beberapa file.
Ketika file dibentuk, DBMS menyediakan kaitan logis, organisasi fisik tidak lagi
menjadi kendala.
4. Mengambil data dan informasi secara cepat.
Hubungan-hubungan logis dan DML serta query language memungkinkan
pemakai mengambil data dalam hitungan detik atau menit, yang sebelumnya
memerlukan beberapa jam atau hari.
8
5. Meningkatkan keamanan.
Baik DBMS mainframe maupun komputer mikro dapat menyertakan beberapa
tingkatan keamanan seperti kata sandi (password), directory pemakai, dan bahasa
sandi (encryption). Data yang dikelola oleh DBMS juga lebih aman daripada data
lain dalam perusahaan.
Sedangkan, kerugian dari DBMS adalah sebagai berikut :
1. Menggunakan perangkat lunak yang mahal.
DBMS mainframe masih sangat mahal. DBMS berbasis komputer mikro,
walaupun biayanya hanya beberapa ratus dolar, namun menggambarkan
pengeluaran yang besar bagi organisasi kecil.
2. Memakai konfigurasi perangkat keras yang besar.
DBMS memerlukan kapastias penyimpanan primer dan sekunder yang lebih besar
daripada yang diperlukan oleh program aplikasi lain.
3. Meperkerjakan dan mempertahankan staff DBA.
DBMS memerlukan pengetahuan khusus agar dapat memanfaatkan
kemampuannya secara penuh. Pengetahuan khusus ini dimiliki oleh para pengelola
database (DBA) secara baik.
2.1.3 Entity – Relationship Diagram
Menurut Jeffrey A. Hoffer, Marry R, Prescott dan Fred R. McFadden (2002,
p142), entity relationship modeling adalah perwakilan detil dan logikal dari data untuk
sebuah organisasi atau area bisnis.
Dalam mendesain basis data, hal yang paling penting adalah dengan
menggunakan Entity Relationship (ER). Karena tanpa ER, bisa dipastikan proses
9
pembuatan basis data berjalan lama dan tidak teratur. Selain itu yang perlu
diperhatikan adalah membuat relasi-relasi yang benar diantara tabel. Proses desain
basis data cukup menghasilkan waktu yang lama jika basis datanya besar.
Pendokumentasian desain basis data mutlak harus dilakukan dengan baik, agar mudah
didalam pengembangan dan perbaikan nantinya.
Pendokumentasian desain juga harus dilakukan dengan baik agar mudah di
dalam pengembangan dan perbaikan nantinya.
2.1.3.1 Entity
Konsep dasar dari Model ER adalah Entity, yaitu kumpulan dari objek-
objek dengan sifat (properti) yang sama, yang diidentifikasi oleh enterprise
mempunyai eksistensi yang independen. Keberadaannya dapat berupa fisik
maupun abstrak.
Nama Entiti
Staff Branch
Gambar 2.1 Contoh Tipe Entiti (Connolly and Begg, p333)
2.1.3.2 Attributes
Merupakan sifat-sifat (properti) dari sebuah entity atau type relationship.
Contohnya: sebuah entity Staff digambarkan oleh atribut staffNo, name, position
dan salary.
10
Attribute domain adalah himpunan nilai yang diperbolehkan untuk satu
atau lebih atribut. Macam-macam atribut:
1. Simple Attribute
Atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang
independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal
juga dengan nama Atomic Attribute.
2. Composite Attribute
Atribut yang terdiri dari beberapa komponen, dimana masing-masing komponen
memiliki keberadaan yang independen. Misalkan atribut Address dapat terdiri
dari Street, City, PostCode.
3. Single-valued Attribute
Atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entitas
Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian.
4. Multi-valued Attribute
Atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misal entitas
Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian.
5. Derived Attribute
Atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut
lainnya, dan tidak harus berasal dari satu entitas.
2.1.3.3 Relationship Type
Relationship types adalah kumpulan keterhubungan yang mempunyai arti
(meaningful associations) antara tipe entitas yang ada.
11
Relationship occurrence yaitu keterhubungan yang diidentifikasi secara
unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.
Derajat relationship yaitu jumlah entitas yang berpartisipasi dalam suatu
relationship. Derajat relationship terdiri dari :
1. Binary Relationship
Keterhubungan antar dua tipe entitas. Contoh binary relationship antara Staff
dengan Branch yang disebut Has.
Staff BranchHas
RelationshipName
‘Branch has Staff’
Gambar 2.2 Contoh Binary Relationship (Connolly and Begg, p335)
2. Ternary Relationship
Keterhubungan antar tiga tipe entitas. Contoh Ternary Relationship yang
dinamakan Registers. Relasi ini melibatkan tiga tipe entity yaitu Staff, Branch
dan Client. Relationship ini menggambarkan Staff mendaftarkan Client pada
Branch.
12
Staff
C lient
BranchRegister
‘S taff registers a c lient at a Branch’
Gambar 2.3 Contoh Ternary Relationship (Connolly and Begg,p336)
3. Quaternary Relationship
Keterhubungan antar empat tipe entitas. Contoh Quaternary Relationship yang
dinamakan Arranges. Relasi ini melibatkan 4 entity yaitu Buyer, Solicitor,
Financial Intstuttion dan Bid. Relasi ini menggambarkan Buyer, diberi masukan
oleh Solicitor, dan didukung oleh Financial Institution, melakukan penawaran
(Bid).
Buyer Arranges
Solicitor
Bid
FinancialInstitution
‘A Solicitor arranges a Bid onbehalf of a Buyer supported by a
Financial Institution’
Gambar 2.4 Contoh Quaternary Relationship (Connolly and Begg,p337)
4. Recursive Relationship
Keterhubungan antar satu tipe entitas, dimana tipe entitas tersebut berpartisipasi
lebih dari satu kali dengan peran yang berbeda. Relationship dapat diberikan
13
role names untuk meng-identifikasikan keterkaitan tipe entitas dalam
relationship. Contoh entitas Staff yang berperan menjadi Supervisor dan Staff
yang di-Supervisor-i.
Staff
Role Name
Role Name
Supervises
Supervisee
Supervisor
Gambar 2.5 Contoh Recursive Relationship (Connolly and Begg,p337)
2.1.3.4 Key
Menurut David M. Kroenke (2002, p124), key adalah sebuah field yang
digunakan untuk mengidentifikasi sebuah record.
Candidate key yaitu sebuah atribut satu atau lebih yang secara unik
mengidentifikasi sebuah baris. Atribut ini mempunyai nilai yang unik pada
hampir tiap barisnya. Fungsi dari candidate key adalah sebagai calon primary
key.
Primary key yaitu candidate key yang dipilih untuk mengidentifikasikan
setiap kejadian/record dari suatu entitas secara unik pada hamper tiap barisnya.
Promary key harus merupakan field yang benar-benar unik.
Composite key yaitu candidate key yang terdiri dari dua atau lebih atribut.
Pada kondisi tertentu, suatu atribut tidak dapat digunakan untuk mengidentifikasi
14
baris secara unik dan membutuhkan kolom lain untuk digunakan sebagai primary
key.
Alternate key adalah candidate key yang tidak dipilih sebagai primary key.
Foreign key adalah jika sebuah primary key terhubung ke tabel lain dan
fungsinya sebagai penghubung antar tabel.
2.1.4 Data Definition Language
Merupakan bagian dari sistem manajemen basis data, dipakai untuk
mendefinisikan dan mengatur semua atribut dan properti dari sebuah basis data.
DDL digunakan untuk mendefinisikan basis data, tabel, view.
1. Create Table
Pernyataan create table digunakan untuk membuat tabel dengan
mengidentifikasikan tipe data untuk tiap kolom.
Bentuk umum:
CREATE TABLE Table_Name
( Column_Name DataType [NULL | NOTNULL]
(, Column_Name DataType [NULL | NOTNULL]
2. Alter Table
Pernyataan alter table digunakan untuk menambah atau membuang kolom dan
konstrain.
Bentuk umum:
ALTER TABLE Table_Name
[ADD Column_Name DataType [NULL | NOTNULL] ]
[DROP Column_Name DataType [RESTRICT | CASCADE] ]
15
[ADD Constrain_Name]
[DROP Constrain_Name [RESTRICT \ CASCADE] ]
3. Drop Table
Pernyataan drop table digunakan untuk menghapus tabel berserata semua data
yang terkait didalamnya.
Bentuk umum:
DROP TABLE Table_Name
4. Create Index
Pernyataan create index digunakan untuk membuat indeks pada tabel.
Bentuk umum:
CREATE [UNIQUE] INDEX Index_Name
ON Table_Name
( Column_Name [, Column_Name]… )
5. Drop Index
Pernyataan drop index digunakan untuk menghapus indeks yang telah dibuat.
Bentuk umum:
DROP INDEX Index_Name
2.1.5 Data Manipulation Language
Data Manipulation (DML) dipakai untuk menampilkan, menambah,
mengubah, dan menghapus data didalam obyek-obyek yang didefinisikan oleh DDL.
Operasi manipulasi data yang biasanya digunakan adalah sebagai berikut:
16
1. Select
Pernyataan select digunakan untuk menampilkan sebagian atau seluruh dari suatu
tabel dan menampilkan kombinasi isi dari beberapa tabel.
Bentuk umum:
SELECT Fields
FROM Table_Name
WHERE Condition
2. Update
Pernyataan update digunakan untuk mengubah isi satu atau beberapa atribut dari
suatu tabel.
Bentuk umum:
UPDATE Table_Name
SET Column1 = Value1, Column2 = Value2, …
WHERE Condition
3. Insert
Pernyataan insert digunakan untuk menambah satu atau beberapa baris nilai baru ke
dalam suatu tabel.
Bentuk umum:
INSERT Table_Name ( Column list ) VALUES ( Value list )
4. Delete
Pernyataan delete digunakan untuk menghapus sebagian atau seluruh isi dari suatu
tabel.
Bentuk umum:
DELETE FROM Table_Name
17
WHERE Condition
2.1.6 Normalisasi
Normalisasi adalah sebuah teknik untuk menghasilkan relasi atau hubungan
dengan properti-properti yang diinginkan, yang memberikan kebutuhan data dari
suatu perusahaan Suatu desain database harus memenuhi kondisi untuk tidak
mengandung anomali, yaitu suatu kejanggalan dari penempatan atribut tertentu dari
suatu obyek data. Untuk membedakan satu record dengan yang lainnya maka perlu
dipilih atribut atau kombinasi atribut sebagai kunci primer (primary key) (Connolly,
2002, p376).
Tujuan pembuatan normalisasi adalah:
1. Membuat seminim mungkin terjadinya data rangkap
2. Menghindarkan adanya data yang tidak konsisten terutama bila terjadi
penambahan, penghapusan data sebagai akibat adanya data rangkap
3. Menjamin bahwa identitas tabel secara tunggal sebagai determinan semua
atribut.
2.1.6.1 Bentuk Normal Pertama (First Normal Form / 1st NF )
Aturan normalisasi pertama (1st NF) menurut Connolly dan Begg
(2002,p388), dapat dikatakan bahwa sebuah relasi dimana setiap baris dan
kolom hanya berisi satu nilai.
Suatu data dikatakan unormalized (UNF), jika didalamnya mengandung
kelompok yang berulang (repeating group), sehingga untuk membentuk
normalisasi pertama repeating group harus dihilangkan. Nilai dari setiap atribut
18
adalah tunggal. Kondisi ini dapat diperoleh dengan melakukan eliminasi
terjadinya data ganda (repeating group). Namun pada kondisi pertama ini
kemungkinan masih terjadi adanya data rangkap.
2.1.6.2 Bentuk Normal Kedua (Second Normal Form / 2nd NF )
Aturan normalisasi kedua (2nd NF) menurut Connolly dan Begg
(2002,p392), dapat dikatakan bahwa sebuah relasi dalam bentuk normal pertama
dan setiap atribut bukan primary key yang tergantung secara fungsional kepada
primary key.
Pengujian bentuk normal kedua dapat dihasilkan dengan melihat
apakah ada atribut bukan primary key yang merupakan fungsi dari sebagian
primary key (partial dependency).
2.1.6.3 Bentuk Normal Ketiga (Third Normal Form / 3rd NF)
Aturan normalisasi ketiga (3rd NF) menurut Connolly dan Begg (2002,
p394) adalah sebuah relasi dalam bentuk normal pertama dan kedua dan setiap
atribut yang bukan primary key yang bergantung secara transitif kepada primary
key.
Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah
terdapat atribut yang bukan key tergantung fungsional terhadap atribut bukan key
lainnya (disebut ketergantungan transitif atau transitive dependence). Dengan
cara yang sama, maka setiap ketergantungan transitif dipisahkan. 3rd NF sudah
cukup baik dalam arti anomali (data yang berulang) yang dikandungnya sudah
sedemikian minimum.
19
2.1.7 Data Application Lifecycle
Tahapan penerapan lifecycle dalam metodologi perancangan basis data menurut
Connolly dan Begg (2002, p270), Database Systems A Practical sebagai berikut :
20
Database Planning
Physical Database Design
DBMS Selection (optional) Aplication Design
Logical Database Design
Operation Maintenance
Conceptual Database Design
Testing
Data Conversion and Loading
System Definition
Implementation
Requirement Collection and Analysis
Prototyping(optional)
Database Design
Gambar 2.6 Tahapan dari Application Database Lifecycle (Connolly and Begg,p272)
21
2.1.7.1 Database Planning
Menurut Connoly dan Begg (2002, pp273-274), perencanaan basis data
(database planning) merupakan aktivitas manajemen yang mengizinkan
tingkatan dari aplikasi basis data untuk direalisasikan se-efisien mungkin dan se-
efektif mungkin. Database planning harus diintegrasikan dengan keseluruhan
strategi sistem informasi dari perusahaan. Ada 3 hal penting dalam menyusun
sebuah strategi sistem informasi, yaitu :
1. Identifikasi dari tujuan dan rencana perusahaan dengan penentuan kebutuhan
sistem informasi berikutnya.
2. Evaluasi dari sistem informasi saat ini untuk menentukan kelebihan dan
kelemahan yang ada saat ini.
3 Penilaian dari kesempatan - kesempatan TI yang mungkin menghasilkan
keuntungan kompetitif.
Langkah penting dari tahap ini adalah mendefinisikan secara jelas tentang
pernyataan misi untuk proyek basis data. Pernyataan tersebut mendefinisikan
tujuan utama dari aplikasi basis data. Bila pernyataan tersebut selesai maka
langkah selanjutnya adalah mengidentifikasikan sasarannya. Pernyataan dan
sasaran ini perlu didukung oleh informasi- informasi tambahan yang menentukan
pekerjaan apa saja yang harus diselesaikan, sumber-sumber yang
mendukungnya, dan biaya yang harus dikerluarkan.
22
2.1.7.2 System Definition
Menurut Connolly dan Begg ( 2002, p274 ) definisi sistem (system
definition) adalah memaparkan jangkauan dari aplikasi basis data dan
pandangan-pandangan utama para pemakai. Sebelum mendesain suatu aplikasi
basis data penting untuk terlebih dahulu mengidentifikasikan batasan–batasan
dari sistem yang sedang diteliti, kaitannya dengan sistem informasi di
perusahaan. Perlu dipikirkan untuk kebutuhan yang akan dating selain dari
keadaan saat ini.
Pandangan pemakai yang merupakan aspek penting dari pengembangan
aplikasi basis data karena membantu untuk memastikan bahwa tidak ada
pemakai utama basis data yang terlupa ketika pengembangan aplikasi baru
tersebut.
2.1.7.3 Requirement Collection and Analysis
Menurut Connolly and Begg (2002, p276), analisis data dan
pengumpulan kebutuhan (requirement collection and analysis) adalah proses
pengumpulan dan analisis informasi tentang bagian dari perusahaan yang akan
didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk
mengidentifikasi kebutuhan pemakai terhadap sistem baru.
Informasi yang dikumpulkan termasuk:
1. Penjabaran dari data yang digunakan,
2. Detail mengenai bagaimana data digunakan,
3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru.
23
Informasi ini kemudian dianalisis untuk mengidentifikasi kebutuhan yang
dimasukkan untuk aplikasi basis data tersebut. Ada tiga macam pendekatan
untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai
pandangan pemakai, yaitu :
1. Pendekatan centralized
Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set kebutuhan
untuk aplikasi basis data. Umumnya pendekatan ini dipakai jika basis datanya
tidak terlalu kompleks
2. Pendekatan view integration
Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun sebuah
model data yang terpisah yang merepresentasikan tiap pandangan pemakai
tersebut. Hasil dari data-data model tersebut kemudian disatukan di bagian basis
data.
3. Kombinasi keduanya.
2.1.7.4 Application Design
Menurut Connolly dan Begg (2002, p287-288), perancangan aplikasi
adalah merancang antarmuka pemakai (user interface) dan program aplikasi,
yang akan memproses basis data.
Dalam perancangan aplikasi harus memastikan semua pernyataan
fungsional dari spesifikasi kebutuhan pemakai (user requirement specification)
yang menyangkut perancangan aplikasi program yang mengakses basis data dan
merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap isi
basis data (retrieve , update dan kegiatan keduanya). Artinya bagaimana fungsi
24
yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai (user
interface) yang tepat. Antarmuka yang dirancang harus memberikan informasi
yang dibutuhkan dengan cara untuk menciptakan ‘user friendly’. Kebanyakan
antarmuka pemakai yang diabaikan akan niscaya membuat masalah.
2.1.7.5 DBMS Selection
Menurut Connolly dan Begg (2002,p284), pemilihan DBMS yang sesuai
untuk mendukung aplikasi basis data yang mencakup :
1. Mendefinisikan syarat-syarat referensi studi
Menentukan sasaran, batasan masalah dan tugas yang harus dilakukan.
2. Mendaftar 2 atau 3 jenis barang
Membuat daftar barang-barang, misalkan dari mana barang ini didapat,
berapa biayanya serta bagaimana bila ingin mendapatkannya.
3. Mengevaluasi barang
Barang - barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui
kelebihan dan kekurangan barang tersebut.
4. Merekomendasikan pilihan dan membuat laporan
Merupakan langkah terakhir dari DBMS yaitu mendokumentasikan proses
dan untuk menyediakan pernyataan mengenai kesimpulan dan
rekomendasi terhadap salah satu produk DBMS.
25
2.1.7.6 Database Design
Menurut Connolly dan Begg (2002, p279), perancangan basis data (
database design ) merupakan proses pembuatan suatu desain untuk sebuah basis
data yang akan mendukung operasional dan sasaran suatu perusahaan.
Ada 2 pendekatan untuk mendesain sebuah basis data, yaitu :
1. Pendekatan bottom-up
Yang dimulai pada tingkat awal dari atribut (yaitu properti dari entiti dan
relationship) yang mana melalui analisis dari asosiasi antar atribut,
dikelompokkan menjadi hubungan yang merepresentasikan jenis-jenis entitas
dan hubungan antar entitas. Pendekatan ini cocok untuk mendesain basis data
yang simple dengan jumlah atribut yang tidak banyak.
2. Pendekatan top-down
Digunakan pada basis data yang lebih kompleks, yang dimulai dengan
pengembangan dari model data yang mengandung beberapa entitas dan
hubungan tingkat tinggi dan kemudian memakai perbaikan top down berturut –
turut untuk mengidentifikasi entitas, hubungan dan atribut berkaitan tingkat
rendah. Pendekatan ini biasanya digambarkan melalui ER (entity relationship).
Pada tahap ini ada bagian yang disebut data modeling yang digunakan untuk
membantu pemahaman dari data dan untuk memudahkan komunikasi tentang
kebutuhan informasi. Dengan dibuatnya model data dapat membantu memahami:
1. Pandangan tiap pemakai mengenai data.
2. Kealamian data itu sendiri, kebebasan representasi fisiknya
3. Kegunaan dari data berdasarkan pandangan pemakai.
26
Kriteria untuk model data, yaitu :
1. Structural validity
Konsistensi dengan cara yang didefinisikan perusahaan dan menyusun informasi.
2. Simplicity
Kemudahan untuk pemahaman baik bagi yang professional di bidang sistem
informasi maupun pemakai yang nonteknis.
3. Expressibility
Kemampuan untuk membedakan antara data yang berbeda, dan hubungan antar
data.
4. Nonredundancy
Pembuangan informasi yang tak ada hubungannya khususnya. Representasi dari
tiap potongan informasi tepatnya hanya sekali.
5. Shareability
Tidak spesifik untuk aplikasi dan teknologi khusus apapun dan dengan demikian
dapat digunakan oleh banyak orang.
6. Extensibility
Kemampuan mengembangkan untuk mendukung kebutuhan baru dengan efek
minimal bagi pemakai yang ada.
7. Integrity
Konsistensi terhadap cara yang digunakan perusahaan dan mengatur informasi.
8. Diagrammatic representation
Kemampuan untuk mereprensentasikan sebuah model menggunakan notasi
diagram yang dapat dipahami dengan mudah.
27
Menurut Connolly dan Begg (2002, p419-437) Database design dibagi
dalam tiga tahapan yaitu conceptual database design, logikal database design,
dan physical database design.
2.1.7.7 Prototyping
Prototyping adalah membuat model kerja dari aplikasi basis data, yang
membolehkan perancang atau user untuk mengevaluasi hasil akhir sistem, baik
dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan utama dari
mengembangkan suatu prototype adalah mengijinkan user untuk menggunakan
prototype guna mengidentifikasikan corak sistem apakah bekerja dengan baik
dan jika mungkin meningkatkan corak baru kepada aplikasi database. Dengan
cara ini, kebutuhan dari pemakai dan pengembang sistem dalam mengevaluasi
kelayakan design sistem akan semakin jelas sehingga kelebihan atau kekurangan
sistem dapat ditangani dengan baik.
Strategi prototyping yang umum digunakan sekarang ada dua,yaitu
requirement dan evolutionary prototyping. Requirement prototyping adalah
menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basis
data dan ketika kebutuhna sudah terpenuhi, prototype tidak digunakan lagi atau
dibuang. Sedangkan evolutionary prototype menggunakan tujuan yang sama,
tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya
dikembangkan menjadi aplikasi basis data yang lengkap.
28
2.1.7.8 Implementation
Implementation merupakan realisasi secara fisik dari database dan desain
aplikasi (Connolly, 2002, p292). Pada tahap penyelesaian desain (dimana dapat
melibatkan pembuatan prototype atau tidak), kini kita dapat menerapkan basis
data dan program aplikasi yang telah kita buat. Implementasi basis data
menggunakan DDL yang kita pilih dalam melakukuan pemilihan DBMS atau
dengan menggunakan Graphical User Interface (GUI), yang menyediakan
fungsional yang sama dengan pernyataan DDL yang low level. Pernyataan DDL
digunakan untuk menciptakan struktur basis data dan mengosongkan file yang
terdapat dalam basis data tersebut. Pandangan pemakai lainnya juga
diimplementasikan dalam tahapan ini. Data Manipulation Language (DML)
digunakan untuk mengimplementasikan transaksi basis data di dalam bagian
aplikasi program dari sasaran DBMS,mungkin termasuk host programming
language seperti, Visual basic, Delphi, C, C++, Java, COBOL, Ada atau Pascal.
2.1.7.9 Data Conversion and Loading
Menurut Connolly (2002, p293), Data conversion and loading adalah
mencakup pengambilan data dari sistem lama untuk dipindahkan ke dalam
sistem yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data
baru sedang menggantikan ssitem yang lama. Sekarang, DBMS yang memiliki
kegunaan yang dapat mengisi file yang ada ke dalam sistem yang baru telah
dianggap umum, kegunaan yang ada umumnya memerlukan spesifikasi sumber
file dan target basis data yang baru. Ketika conversion dan loading dibutuhkan,
29
prosesnya harus direncanakan untuk memastikan kelancaran transaksi untuk
keseluruhan operasi.
2.1.7.10 Testing
Testing adalah suatu proses melaksanakan program aplikasi dengan
tujuan menemukan kesalahan (Connolly, 2002, p293). Sebelum diterapkan dalam
suatu sistem, basis data harus dilakukan testing terlebih dahulu. Hal ini dicapai
dengan penggunaan secara hati-hati untuk merencanakan suatu test dan data
yang realistis sedemikian sehingga keseluruhan proses pengujian sesuai dengan
metode dan dilaksanakan sesuai aturan yang ada.
2.1.7.11 Operation Maintenance
Operational maintenance adalah proses memantau dan memelihara
sistem setelah di-install (Connolly, 2002, p293-294). Pada tahapan sebelumnya,
basis data benar-benar diuji dan diimplementasikan. Sekarang sistem beralih ke
tahapan pemeliharaan. Yang termasuk aktifitas dari tahapan ini adalah sebagai
berikut:
1. Memantau kinerja dari sistem.Jika kinerjanya menurun dibawah level yang
dapat diterima, mungkin basis data perlu diorganisasi
2. Pemeliharaan dan upgrade aplikasi basis data-nya (jika diperlukan)
Ketika basis data sepenunya bekerja, pemantauan harus memastikan
kinerjanya dapat berada dalam tingkat yang diterima. Sebuah DBMS biasanya
menyediakan berbagai kegunaan (utilities) untuk membantu administrasi basis
data termasuk kegunaan untuk mengisi data ke dalam basis data dan untuk
30
memantau sistem. Kegunaan ini memperbolehkan sistem pemantauan untuk
memberikan informasi seperti tentang pemakaian basis data dan strategi eksekusi
query. Database administrasi dapat menggunakan informasi ini untuk
memperbaiki sistem agar dapat memberikan kinerja yang lebih baik.
2.1.8 Conceptual, Logikal, and Physical Database Design
2.1.8.1 Conceptual Database Design
Hal yang pertama dilakukan dalam membuat conceptual design adalah
dengan membuat model sata secara konseptual dari perusahaan yang
bersangkutan. Conceptual database design seluruhnya independent dari
implementasi seperti target DBMS software, program aplikasi, bahasa
pemograman, atau physical consideration lainnya. Data tersebut merupakan
informasi-informasi mengenai perusahaan. Dalam conceptual database design,
data yang ada dikembangkan dengan representasi secara konseptual yang
mencakup mengidenifikasi entity, relationship, dan atribut yang sangat penting
dalam perancangan bisnis tersebut.
Langkah-langkah untuk membuat data model lokal yang konseptual
untuk setiap user view dapat digambarkan sebagai berikut :
1. Identifikasikan tipe-tipe entity
Tujuannya adalah untuk mengidentifikasi dan membuat kelas-kelas dari obyek
yang ada berikut penjelasannya serta menentukan entitas utama yang dibutuhkan.
Salah satu metode untuk mengidentifikasi entity adalah dengan menguji
spesifikasi kebutuhan dari user. Dari spesifikasi ini dapat mengidentifikasikan
noun dan nouns phrases yang disebutkan. Selain itu juga dapat melihat objek
31
utama seperti orang, tempat atau konsep dari ketertarikan diluar noun lainnya
yang merupakan kualitas dari objek lain.
Misalkan :
• Staff, yang menggambarkan tingkatan staff yang ada.
• PropertyForRent, menggambarkan semua properti yang disewakan.
2. Identifikasikan tipe-tipe relationship
Tujuannya adalah untuk mengidentifikasi hubungan-hubungan yang ada antara
entitas yang telah diidentifikasikan. Dalam mengidentifikasi tipe relasi yang ada
dengan menggunakan Entity Relationship Diagram (ERD), mencari batasan dari
tipe relationship, memeriksa fan dan chasm traps, memeriksa masing-masing
entity ikut serta setidaknya dalam satu relationship, dan dokumentasikan tipe
relationship.
Misalkan :
• Staff Manages PropertyForRent, yaitu entitas staff mengatur entitas properti.
• PropertyForRent AssociatedWith Lease, yaitu entitas properti yang
disewakan bekerjasama dengan entitas leasing.
3. Identifikasi dan hubungkan atribut-atribut dengan tipe entity atau
relationship
Tujuannya adalah untuk mengidentifikasikan dan menghubungkan atribut-tribut
yang berkaitan dengan entitas atau tipe relationship yang telah sesuai.
4. Tetapkan domain atribut
Tujuannya adalah untuk menetapkan domain untuk tiap-tiap atribut dalam model
data konseptual local dan mendokumentasikan setiap detail dari domain. Suatu
32
domain adalah suatu kelompok nilai yang dari mana satu atau lebih atribut
mengambil nilainya.
Misalkan :
• Domain atribut untuk nilai staffNo yang valid harus huruf dan 3 digit
berikutnya berupa angka yang berkisar antara 1-999
• Nilai yang mungkin untuk atribut gender dari entity staff misalnya huruf M
untuk mewakilkan Man, dan huruf F untuk mewakilkan Female
5. Tetapkan atribut Primary dan Candidate key
Tujuannya adalah untuk menentukan candidate key dan primary key dari
kumpulan atribut-atribut yang telah ditentukan pada tiap entitas. Candidate key
adalah satu atau lebih atribut dari suatu entitas yang dapat dijadikan primary key.
Primary key adalah satu atribut dari suatu entitas yang dipakai sebagai ciri yang
paling unik dari entitas tersebut.
6. Mempertimbangkan kegunaan dari konsep Enhanced Modeling (optional)
Tujuannya adalah untuk mengembangkan ER model dengan menggunakan
konsep enhanced modeling, seperti spesialisasi, generalisasi, penggabungan
(aggregation), komposisi (composition).
7. Periksa model untuk redudansi
Tujuannya adalah untuk memeriksa konsep model data apakah masih
mengandung data maupun entitas serta atribut yang berulang atau tidak. Hal
pertama yang dilakukan adalah memeriksa kembali hubungan-hubungan yang
ada apabila terdapat suatu hubungan yang mirip.
8. Validasi model konseptual lokal terhadap transaksi user
33
Tujuannya untuk memastikan model konseptual lokal mendukung transaksi yang
dibutuhkan oleh view. Diuji dua pendekatan untuk memastikan model data
konseptual lokal mendukung transaksi yang dibutuhkan, dengan cara:
• Mendeskripsikan transaksi-transaksi
Memeriksa seluruh informasi (entitas, relationship, dan atribut) yang
dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan
mendokumentasikan setiap kebutuhan transaksi.
• Mengunakan jalur-jalur transaksi
Untuk validasi model data terhadap transaksi yang dibutuhkan termasuk
representasi diagram jalur yang digunakan oleh setiap transaksi langsung
pada ER diagram.
9. Review model data konseptual dengan user
Tujuannya untuk mengkaji ulang model data konseptual lokal dengan user untuk
memastikan model tersebut adalah representasi sebenarnya dari view. Model data
konseptual ini termasuk ER diagram dan dokumentasi pendukung yang
mendeskripsikan model data. Bila ada kejanggalan (anomali) dalam model data,
maka harus dibuat perubahan yang sesuai yang mungkin membutuhkan
pengulangan langkah-langkah sebelumnya.
2.1.8.2 Logikal Database Design
Logikal design merupakan proses pembuatan model data dengan
menggunakan informasi yang diperoleh dari perusahaan serta berdasarkan pada
model data spesifik. Model data yang telah diperoleh dalam conceptual database
34
design diubah dalam bentuk logikal model dimana data yang ada dipengaruhi
oleh model data yang menjadi tujuan database.
Hal ini dilakukan untuk menerjemahkan representasi konseptual ke dalam
bentuk struktur logic dalam database yang akan dijadikan sumber informasi
dalam merancang physical database design serta memberikan sarana yang
membantu para perancang database dalam merancang physical database.
Hasil akhir dari logikal database design ini berupa sebuah kamus data
yang berisi atribut-atribut beserta key-nya (primary key, alternate key, dan
foreign key) dan ERD keseluruhan dengan atribut key-nya.
Langkah-langkah untuk membuat logikal database design dapat
digambarkan sebagai berikut :
1. Membuat dan memvalidasikan data model lokal yang logikal untuk setiap
view
Aktivitas pada logical database design langkah pertama adalah membangun
pandangan (view) tertentu dari perusahaan dan kemudian mengesahkan model ini
untuk memastikan strukturnya telah benar atau menggunakan teknik normalisasi.
• Pindahkan fitur-fitur yang tidak kompatibel dengan model relational
(langkah optional)
• Ambil hubungan untuk data model lokal yang logikal
• Validasikan hubungan menggunakan normalisasi
• Validasikan hubungan terhadap transaksi user
• Tentukan batasan integrity
• Tinjau kembali model data logikal lokal dengan user
35
2. Membuat dan memvalidasikan model data logikal global
Aktivitas pada logical database design langkah kedua adalah untuk
mengkombinasikan model data logikal lokal individual ke dalam sebuah model
data logikal global tunggal yang menggambarkan perusahaan.
• Gabungkan model data logikal lokal menjadi model global
• Validasikan model data logikal global
• Periksa untuk pengembangan mendatang
• Tinjau kembali model data logikal global dengan user
2.1.8.3 Physical Design
Physical design merupakan proses pembuatan deskripsi dari suatu
impelmentasi basis data pada secondary storge. Hal ini mendeskripsikan base
relation, organisasi file, dan indeks yang digunakan untuk mencapai efisiensi
akses kedalam data, dan associated integrity constraints yang lainnya dan
security measures. Physical database design merupakan fase ketiga dan terakhir
dalam desain database. Tujuan utama dari physical databse design adalah untuk
mendeskripsikan bagaimana desainer bermaksud untuk mengimplementasikan
secara fisik dari logikal database design.
Langkah-langkah dalam pembuatan physical databse design adalah
sebagai berikut :
1. Terjemahkan model data logikal global target DBMS
• Desain hubungan dasar
• Desain representasi dari data yang dihasilkan
36
• Desain batasan-batasan perusahaan
2. Desain reprensentasi fisikal
• Analisa transaksi-transaksi
• Pilih organisasi file
• Pilih indeks-indeks
• Perkirakan kebutuhan tempat penyimpanan
3. Desain user view
4. Desain mekanisme keamanan
5. Pertimbangkan pengenalan dari redundansi terkontrol
6. Awasi dan atur sistem operasional
2.1.9 Document Flowchart
Menurut Romney Steinbart (2003, p165) Document Flowchart mengilustrasikan
aliran dari dokumen-dokumen dan informasi diantara area-area tanggung jawab
didalam sebuah organisasi.
Menurut Mulyadi (2001, p66) bagan alir dokumen (Document Flowchart) adalah
bagan yang menggambarkan aliran dokumen dalam suatu sistem informasi.
Berikut simbol-simbol yang digunakan dengan maknanya masing-masing
(Mulyadi,2001,p60-63)
• Dokumen
Simbol imi digunakan untuk menggambarkan semua jenis dokumen, yang merupakan
formulir yang digunakan untuk merekam data terjadinya suatu transaksi. Nama
dokumen dicantumkan di tengah simbol.
37
Simbol :
Contoh :
• Dokumen dan tembusannya
Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor
lembar dokumen dicantumkan di sudut kanan atas.
Simbol :
Contoh:
• Kegiatan Manual
Simbol ini digunakan untuk menggambarkan kegiatan manual, seperti menerima order
dari pembeli, mengisi formulir. Uraian singkat kegiatan manual dicantumkan di dalam
simbol ini.
Simbol :
Contoh:
38
• Catatan
Simbol ini digunakan untuk menggambarkan catatan yang digunakan untuk mencatat
data yang direkam sebelumnya di dalam dokumen atau formulir. Nama catatan
dicantumkan di dalam simbol ini
Simbol :
Contoh:
• Penghubung pada halaman yang sama (on page connector)
Dalam menggambarkan diagram alir, arus dokumen dibuat mengalir dari atas ke
bawah dan dari kiri ke kanan. Karena keterbatasan ruang halaman kertas untuk
menggambar, maka diperlukan simbol penghubung untuk memungkinkna aliran
dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi
lain pada halaman yang sama. Dengan memperhatikan nomor yang tercantum di dalam
simbol penghubung pada halaman yang sama, dapat diketahui aliran dokumen dalam
sistem yang digambarkan dalam bagan alir.
Simbol :
• Arsip permanen
Simbol ini digunakan untuk menggambarkan arsip permanen yang merupakan tempat
penyimpanan dokumen yang tidak akan diproses lagi dalam sistem yang bersangkutan.
39
Untuk menunjukkan urutan pengarsipan dokumen digunakan simbol sebagai berikut
ini :
A = menurut abjad
N = menurut nomor urut
T = kronologis, menurut tanggal
Simbol :
Contoh :
N
• Keying (typing, verifying)
Simbol ini digunakan untuk menggambarkan pemasukkan data ke dalam komputer
melalui online terminal
Simbol :
Contoh :
• Keputusan
Simbol ini digunakan untuk menggambarkan keputusan yang harus dibuat dalam
proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol.
Simbol :
40
Contoh :
• Garis Alir (flowline)
Simbol ini menggambarkan arah proses pengolahan data.
Simbol :
• Mulai / berakhir (terminal)
Simbol ini menggambarkan awal dan akhir suatu sistem
Simbol :
Contoh :
2.1.10 State Transition Diagram
State Transition Diagram (STD) adalah sebuah modeling tool yang
menggambarkan ketergantungan waktu pada sistem real time dan human interface
pada sistem online.
Notasi yang paling penting dari STD adalah :
1. State
Merupakan kumpulan keadaan atau atribut-atribut yang mencirikan benda atau
orang pada waktu, keadaan dan kondisi tertentu.
41
Notasi State
2. Transition (Perubahan) State
Perubahan state ditandakan dengan tanda panah.
Kondisi
Aksi
Ada 2 hal yang perlu ditambahkan untuk melengkapi STD, yaitu :
1. Kondisi adalah keadaan lingkungan luar yang dapat dideteksi oleh sistem
dan menyebabkan perubahan state. Kondisi dapat berupa sinyal,
interrupt dan lainnya
2. Aksi adalah apa yang dilakukan sistem jika ada perubahan state. Aksi dapat
menghasilkan keluaran, tampilan pesan pada layar pengguna, membuat
kalkulasi, dan lainnya.
2.2 Teori - Teori Khusus
2.2.1 Pembelian
Menurut Mulyadi (2001, p301), pembelian adalah suatu usaha yang
digunakan oleh perusahaan untuk pengadaan barang yang diperlukan oleh
perusahaan.
Menurut Mulyadi (2001, p301), fungsi yang terkait dengan pembelian
adalah:
42
1. Fungsi Gudang
Dalam sistem pembelian, fungsi gudang bertanggung jawab untuk mengajukan
permintaan pembeluian sesuai dengan posisi persediaan yang ada di gudang dan
untuk menyimpan barang yang telah diterima oleh bagian penerimaan. Untuk
barang-barang yang langsung pakai, permintaan pembelian diajukan oleh
pemakai barang.
2. Fungsi Pembelian
Dalam sistem pembelian, fungsi pembelian bertanggung jawab untuk
memperoleh informasi mengenai harga barang, menentukan pemasok yang
dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada
pemasok yang dipilih.
3. Fungsi Penerimaan
Fungsi penerimaan bertanggung jawab untuk melakukan pemeriksaan terhadap
jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan
dapat atau tidaknya barang tersebut diterima oleh perusahaan. Selain itu juga
bertanggung jawab untuk menerima barang dari pembeli yang berasal dari
transaksi retur penjualan.
4. Fungsi Akuntansi
Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat
ulang dan fungsi pencatat persediaan. Dalam sistem akuntansi pembelian,fungsi
pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam
register bukti kas keluar dan puntuk menyelenggarakan arsip dokumen sumber.
Dalam sistem akuntansi pembelian, fungsi pencatat persediaan bertanggung
43
jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu
persediaan.
2.2.2 Persediaan
Persediaan pada perusahaan dagang disebut persediaan barang dagangan
atau kadang-kadang disingkat persediaan, yang terdiri atas barang-barang yang
disediakan untuk dijual kepada padra konsumen selama periode normal kegiatan
perusahaan.
Beberapa istilah inventori yang sering digunakan menurut Sugiono
adalah
1. Stok Card (Kartu Stok)
Stok Card adalah catatan stok harian dimana masukan berupa jumlah barang
dengan sistem pembelian merupakan penambahan terhadap stok barang
sedangkan dari sistem penjualan merupakan pengurangan. Setiap hari catatan
stok perlu diperbaharui, meski secara sistem dapat dilakukan kapan saja. Jadi bila
terjadi transaksi, stok card perlu dibuat.
2. Stok Opname
Stok Opname adalah pemeriksaan stok fisik yang tersedia (di gudang) dan
membandingkannya dengan stok yang tercantum (pada komputer). Biasanya
dilakukan pada periode tertentu misalnya sebulan sekali, 6 bulan sekali bahkan
ada yang setahun sekali. Pemeriksaan ini tergantung pada banyaknya jenis
barang. Bila terlalu banyak maka bisa memerlukan waktu yang cukup lama. Di
sebuah swalayan besar bisa membutuhkan waktu 1 hari hingga mereka terpaksa
mnutup outletnya selama stock opname berlangsung. Berdasarkan hasil
44
perbandingan stok fisik denagn stok yang tercatat, apabila terdapat selisih antara
stok fisik dengan stok yang tercatat maka akan dilakukan adjustment stok,
dimana jika terdapat kekurangan pada stok fisik, maka kekurangan akan menjadi
biaya. Setelah pencatatan rampung semuanya, sistem stok berperan kembali
untuk memperbaharui catatan stok akhir pada tabel barang.
3. Adjustment Stok
Setelah dilakukan stock opname, bila ada barang yang rusak, hilang dan
sebagainya, maka akan dilakukan penyesuaian terhadap stok fisik yang tercatat.