6 BAB 2 LANDASAN TEORI Basis Data (Database) sekarang

BAB 2
LANDASAN TEORI
Basis Data (Database) sekarang merupakan bagian dari kehidupan kita seharihari yang biasanya tidak kita sadari penggunaannya. Basis data merupakan koleksi dari
data yang berhubungan dan Sistem Manajemen Basis Data (Database Management
System/DBMS) merupakan perangkat lunak (software) yang mengatur dan mengontrol
akses ke basis data. Aplikasi basis data merupakan program yang berinteraksi dengan
basis data pada beberapa point dalam eksekusinya. Kita juga menggunakan istilah sistem
basis data untuk memasukkan koleksi program aplikasi yang berinteraksi dengan basis
data.
2.1
Pengertian Basis Data
Menurut Connolly (2002, p14), Basis data adalah kumpulan data yang
berhubungan secara logical yang dibagi, dan mendeskripsikan data, didesain
untuk menemukan kebutuhan informasi pada suatu organisasi.
Ramakrishnan (2003, p4) menyatakan, Basis data adalah koleksi data,
secara tipikal menggambarkan aktivitas-aktivitas dari satu atau lebih organisasi
yang terkait.
Charles (1984, p5) mengemukakan, Basis data adalah koleksi dari
bermacam-macam file yang merepresentasikan sumber informasi lengkap,
biasanya untuk bisnis.
6
7
Hutchinson dan Sawyer (1996, p349) mengungkapkan, Basis data adalah
kumpulan data yang terintegrasi yang diorganisasikan sebagai byte, field, record
dan file.
Menurut Kamus Istilah Akuntansi (1999, p125), Basis data adalah tempat
penyimpanan data yang berkaitan yang dikelola secara bebas terpisah dari segala
program khusus atau aplikasi sistem informasi. Dapat menyediakan berbagai
macam sistem dalam organisasi. Intinya, merupakan lemari berkas kabinet
elektronik yang dapat menyediakan inti dari informasi umum dalam sebuah
program.
2.2
Pengertian DBMS
Menurut Connolly (2002, p16), Sistem Manajemen Basis Data adalah
sistem software yang memungkinkan pemakai (user) untuk mendefinisikan,
membuat, memelihara, dan mengontrol akses ke basis data.
Ramakrishnan (2003, p4) menyatakan, Sistem Manajemen Basis Data
adalah software yang didesain untuk mendukung dalam pemeliharaan dan
pemanfaatan koleksi data dalam jumlah besar.
Hutchinson
dan
Sawyer
(1996,
p349)
mengemukakan,
Sistem
Manajemen Basis Data adalah sistem komputer untuk mendefinisikan, membuat,
memanipulasi, memgontrol, mengatur dan menggunakan basis data.
Menurut Kamus Istilah Akuntansi (1999, p125), Sistem Manajemen
Basis Data adalah perangkat lunak yang dipakai untuk mengelola data dalam
basis data. Merupakan satu set program yang menyediakan penetapan,
pengawasan, dan pemasukan data.
8
Silberschatz (2002, p1) mengungkapkan, Sistem Manajemen Basis Data
adalah kumpulan data yang saling berhubungan dan kumpulan program untuk
mengakses data-data tersebut. Kumpulan data biasanya merujuk kepada basis
data, mengandung informasi
yang relevan dengan enterprise. Tujuan utama
DBMS adalah untuk menyediakan dan memperoleh informasi basis data yang
nyaman (convenient) dan efisien. Sistem basis data didesain untuk mengatur
sejumlah besar informasi, manajemen data termasuk menjelaskan struktur untuk
penyimpanan
informasi dan menyediakan mekanisme untuk manipulasi
informasi.
2.3
Komponen Lingkungan DBMS
Menurut Connolly (2002, pp18-20), ada lima komponen utama dalam
lingkungan DBMS, yaitu :
¾
Perangkap Keras (hardware), terdiri dari :
o
Penyimpanan secondary (magnetic disk), I/O device ex : disk
drives), device Controller, I/O Channels, dan lainnya.
o
Hardware processor dan main memory, digunakan untuk
mendukung saat eksekusi system software database.
¾
Perangkat Lunak, terdiri dari : DBMS, sistem operasi, software jaringan
dan program aplikasinya.
¾
Data, digunakan oleh organisasi dan data ini digambarkan dalam bentuk
skema.
¾
Prosedur adalah instruksi dan aturan yang harus diterapkan untuk
mendesain dan menggunakan basis data dan DBMS.
9
¾
Orang, terdiri dari :
o
Application Programmers, bertanggungjawab untuk membuat
aplikasi basis data dengan menggunakan bahasa pemrograman
yang ada.
o
End Users, siapapun yang berinteraksi dengan system secara
online melalui workstation/terminal.
o
DA (Data Administrator), seseorang yang berwenang untuk
membuat keputusan stategis dan kebijakan mengenai data yang
ada.
o
DBA (DataBase Administrator), menyediakan dukungan teknis
untuk implementasi keputusan tersebut, dan bertanggungjawab
atas keseluruhan kontrol system pada level teknis.
Hardware
Software
Mesin
Data
Prosedur
Jembatan
Orang
Manusia
Gambar 2.01 Komponen DBMS
2.4
Entity-Relationship Modeling
ER (Entity Relationship) data model didasarkan pada presepsi dunia
nyata yang terdiri dari kumpuln objek dasar , yang disebut entiti dan relationship
antara objek-objek ini.
10
2.4.1
Tipe Entity
Tipe entity merupakan konsep dasar dari suatu model ER. Menurut
Connolly (2002, p331), Tipe entity adalah kumpulan dari objek dengan property
yang sama, yang diidentifikasi oleh perusahaan mempunyai keberadaan yang
independen. Keberadaan tipe entity dapat berupa fisik atau ‘nyata’ dan
conceptual atau ‘abstrak’.
Entity occurrence adalah pengidentifikasian objek yang unik dari sebuah
tipe entity.
Nama Entity
Staff
Branch
Gambar 2.02 Contoh Tipe Entity
2.4.2
Tipe Relationship
Menurut Connolly (2002, p334), Tipe relationship adalah kumpulan
hubungan yang mempunyai arti antara tipe entity.
Relationship occurrence
adalah hubungan yang diidentifikasi secara unik, yang meliputi keberadaan dari
setiap tipe entity yang berpartisipasi.
11
Nama
Relationship
< Has
Staff
"Branch has staff"
Branch
Gambar 2.03 Contoh Tipe Relationship
2.4.3
Derajat Relationship
Menurut Connolly (2002, pp335-338), Derajat relationship adalah jumlah
tipe entity yang berpartisipasi dalam sebuah relationship. Derajat relationship
terdiri dari :
¾
Binary Relationship adalah relationship antara dua tipe entity.
¾
Ternary Relationship adalah relationship antara tiga tipe entity.
¾
Quaternary Relationship adalah relationship antara empat tipe entity.
¾
Unary
Relationship disebut juga
recursive
relationship, adalah
relationship antara satu tipe entity dimana tipe entity tersebut
berpartisipasi lebih dari satu kali dengan peran yang berbeda.
12
'Private owner owns property for rent'
POwns >
PrivateOwner
PropertyForRent
Binary Relationship
Staff
Branch
Register
'Staff register a
client at a branch'
Client
Ternary Relationship
Solicitor
Buyer
'Asolicitor arranges a
bid on behalf of buyer
supported by a financial
institution'
Financial
Institution
Arranges
Bid
Quaternary Relationship
Role name
'Staff (Supervisor)
supervises staff
(Supervisee)'
< Supervises
Supervisor
Role name
Supervisee
Staff
Unary Relationship
Gambar 2.04 Contoh Derajat Relationship
13
2.4.4
Attribute
Menurut Connolly (2002, pp338-340), Atribut adalah sifat atau property
dari sebuah tipe entity atau tipe relationship. Contohnya : sebuah entity karyawan
digambarkan oleh kdKary, nmKary, almtKary dan jabatan. Atribut domain
adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.
Macam-macam atribut :
¾
Simple Attribute disebut juga Atomic Attribute, yaitu atribut yang terdiri
dari satu komponen tunggal dengan keberadaan yang independen dan
tidak dapat dibagi menjadi bagian yang lebih kecil lagi.
¾
Composite Attribute yaitu atribut yang terdiri dari beberapa komponen
dimana
masing-masing
komponen
memiliki
keberadaan
yang
independen. Misalkan atribut alamat dapat terdiri dari jalan, kota dan
kode pos.
¾
Single-value Attribute yaitu atribut yang mempunyai nilai tunggal untuk
setiap kejadian. Misalnya entity pemesanan memiliki satu nilai untuk
attribut noPesan pada setiap kejadian.
¾
Multi-value Attribute yaitu atribut yang mempunyai beberapa nilai untuk
setiap kejadian. Misalnya entity Karyawan memiliki beberapa nilai untuk
attribut noTelp pada setiap kejadian.
¾
Derived Attribute yaitu atribut yang memiliki nilai yang dihasilkan dari
satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entity.
14
2.4.5
Key
Kita harus memiliki cara untuk menspesifikasikan bagaimana entity di
dalam kumpulan entity dapat dibedakan. Maka , nilai dari nilai atribut sebuah
entity harus sedemikian rupa agar dapat mengidentifikasi entity secara unik.
Sebuah key memberikan kemudahan untuk mengidentifikasi kumpulan atribut
yang mencukupi untuk dapat membedakan entity yang satu dengan yang lain.
Key juga membantu mengidentifikasi relationship secara unik dan membedakan
relationship antara yang satu dengan yang lainnya.
Menurut Connolly (2002, pp340-341), Key terbagi atas :
¾
Candidate Key adalah jumlah minimal atribut-atribut yang secara unik
mengidentifikasikan setiap kejadian pada tipe entity.
¾
Primary
Key
adalah
candidate
key
yang
terpilih
untuk
mengidentifikasikan setiap kejadian pada tipe entity secara unik.
¾
Composite Key adalah candidate key yang terdiri dari dua atau lebih
atribut.
2.4.6
Strong and Weak Entity Type
Menurut Connolly (2002, pp341-342), Strong entity type adalah tipe
entity yang keberadaannya tidak tergantung pada tipe entity lainnya. Sedangkan
weak entity type adalah tipe entity yang keberadaannya tergantung pada tipe
entity lainnya. Strong entity type disebut juga parent, owner dominant sedangkan
weak entity type disebut child, dependent dan subordinate.
15
Strong Entity
Client
Weak Entity
States >
clientNo {PK}
name
fName
lName
telNo
Preference
prefType
maxRent
Gambar 2.05 Contoh Strong dan Weak Tipe Entity
2.4.7
Structural Constraint
Batasan atau kendala utama pada relationship adalah multiplicity.
Menurut Connolly (2002, p344), Multiplicity adalah jumlah (atau jangkauan) dari
kejadian yang mungkin terjadi pada suatu entity yang terhubung ke satu kejadian
dari entity lain yang berhubungan melalui suatu relationship.
Menurut Connolly (2002, pp345-348), ada 3 tipe relationship binary yang
menggunakan batasan enterprise yaitu :
¾
Relasi satu-satu (1:1) yaitu relasi antara dua tipe entity dimana satu tipe
entity berelasi tepat satu atau nol dengan tipe entity lainnya.
¾
Relasi satu-banyak (1:*) yaitu relasi antara dua tipe entity dimana satu
tipe entity berelasi nol, satu atau banyak dengan tipe entity lainnya.
¾
Relasi banyak-banyak (*:*)yaitu relasi antara dua tipe entity dimana tipe
entitynya saling berelasi nol, satu atau banyak.
16
'A member of staff can
manage zero or one
branch'
'Each branch is managed
by one member of staff'
Manages >
Staff
staffNo
1..1
Branch
branchNo
0..1
Multiplicity
Relasi satu-satu (1:1)
'Each property for rent is
overseen by zero or one
member of staff'
'Each member of staff
overssen zero or more
properties for rent'
Oversees >
Staff
staffNo
0..1
PropertyForRent
propertyNo
0..*
Relasi satu-banyak (1:*)
'Each property for rent is
advertised in zero or more
newspapers'
Newspaper
'Each newspaper
advertises one or more
properties for rent'
PropertyForRent
Advertises >
newspaperName
0..*
1..*
propertyNo
Relasi banyak-banyak (*:*)
Gambar 2.06 Contoh Tipe-tipe relationship pada Binary
17
2.4.8
Multiplicity untuk relasi yang komplek
Menurut Connolly (2002, p349), Multiplicity untuk relasi yang kompleks
adalah jumlah (atau jangkauan) dari kejadian yang mungkin dari suatu entity
dalam n-ary relationship ketika nilai entity yang lain (n-1) diketahui.
Staff
Register
1..1
1..1
Branch
0..*
Client
Gambar 2.07 Contoh Multiplicity pada Relationship Ternary
Cara
alternatif
untuk
Arti
menggambarkan batasan multiplicity
0..1
Nol atau satu kejadian
1..1 (atau hanya 1)
Hanya satu kejadian
0..* (atau hanya *)
Nol atau banyak kejadian
1..*
Satu atau banyak kejadian
5..10
Minimum 5 dan maksimal 10 kejadian
0,3,6-8
Nol atau tiga atau enam, tujuh, atau delapan
kejadian
Tabel 2.01 Tabel Multiplicity
18
Multiplicity dibentuk dari 2 macam batasan pada relationship, yaitu :
¾
Cardinality, menjelaskan jumlah maksimal dari kejadian relationship
yang mungkin untuk entity yang berpartisipasi di dalam relationship
tersebut.
¾
Participation, menetapkan apakah seluruh atau sebagian entity yang
berpartisipasi dalam suatu relationship.
Cardinality
'One member of staff
manages one branch'
'One branch is managed by
one member of staff'
Manages >
Staff
staffNo
Branch
0..1 branchNo
1..1
'not All staff manage
branches'
(optional participation for
staff)
'All branches are managed'
(mandatory participation for
branch)
Participation
Gambar 2.08 Cardinality dan Participation
2.5
Database Application Lifecycle
Basis data merupakan komponen mendasar suatu sistem informasi,
dimana pengembangan atau pemakaiannya harus dilihat dari perspektif yang
19
lebih luas berdasarkan kebutuhan organisasi. Database Aplication Lifecycle
berdampingan dengan lifecycle dari sistem informasi.
Sistem
Informasi
merupakan
sumberdaya
yang
memungkinkan
pengumpulan (collection), pengaturan (management), pengawasan (control) dan
penyebaran (dissemination) informasi keseluruh organisasi.
Database Planning
System Definition
Requirem ent collection
and Analysis
Database Design
Conceptual Database
Design
DBMS Selection
Application Design
Logical Database
Design
Physical Database
Design
Prototyping
Im plem entation
Data conversion and
loading
Testing
Operational
M aintenance
Gambar 2.09 Tahapan dalam Database Application Lifecycle
20
2.5.1
Database Planning
Perencanaan basis data merupakan perencanaan bagaimana tahapantahapan dalam lifecycle dapat direalisasikan seefektif dan seefisien mungkin.
Perencanaan basis data harus terintegrasi dengan keseluruhan strategi sistem
informasi dari organisasi. Terdapat 3 hal pokok yang berkaitan dengan strategi
sistem informasi, yaitu :
¾
Identifikasi rencana dan sasaran (goals) dari enterprise termasuk
mengenai sistem informasi yang dibutuhkan.
¾
Evaluasi sistem informasi yang ada untuk menetapkan kelebihan dan
kekurangan yang dimiliki.
¾
Penaksiran kesempatan IT yang mungkin memberikan keuntungan
kompetitif.
Metodologi untuk mengatasi hal tersebut diatas yaitu :
¾
Database Planning – Mission Statement :
Mission statement untuk database project mendefinisikan tujuan
utama dari aplikasi database. Mengarahkan database project, biasanya
mendefinisikan perintah tugas (mission statement). Mission statement
membantu menjelaskan kegunaan dari database project dan menyediakan
alur yang lebih jelas untuk mencapai efektifitas dan efisiensi penciptaan
dari suatu aplikasi database yang diinginkan.
¾
Database Planning – Mission Objectives :
Ketika mission statement telah didefinisikan, maka mission
objectives
didefinisikan.
Setiap
objective
(tujuan)
harus
21
mengidentifikasikan tugas khusus yang harus didukung oleh database.
Dapat juga disertai dengan beberapa informasi tambahan yang
menspesifikasikan pekerjaan yang harus diselesaikan, sumberdaya yang
digunakan dan biaya untuk membayar kesemuanya itu.
2.5.2
System Definition
Definisi system adalah menjelaskan batasan-batasan dan cakupan dari
aplikasi basis data dan sudut pandang user atau pemakai yang utama. Sudut
pandang pemakai mendefinisikan apa yang diwajibkan dari suatu aplikasi basis
data dari perspektif aturan kerja khusus atau area aplikasi perusahaan. Sudut
pandang pemakai diperlukan untuk memastikan bahwa tidak ada pemakai utama
dari suatu basis data yang terlupakan ketika pembuatan aplikasi baru yang
dibutuhkan dan membantu dalam pengembangan aplikasi basis data yang rumit
atau komplek juga memungkinkan permintaan-permintaan dipecah ke dalam
bagian-bagian yang lebih simple.
2.5.3
Requirement Collection and Analysis
Analisis
dan
pengumpulan
kebutuhan
merupakan
suatu
proses
pengumpulan dan analisis informasi mengenai bagian organisasi yang didukung
oleh aplikasi basis data, dan menggunakan informasi tersebut untuk identifikasi
kebutuhan pemakai akan sistem yang baru. Informasi dikumpulkan untuk setiap
user view utama meliputi
:
¾
Deskripsi data yang digunakan atau dihasilkan
¾
Detail mengenai bagaimana data digunakan/dihasilkan
22
¾
Beberapa kebutuhan tambahan untuk aplikasi database yang baru
Informasi dianalisis untuk identifikasi kebutuhan agar disertakan dalam
aplikasi basis data yang baru. Aktifitas penting lainnya, adalah menentukan
bagaimana mengatur aplikasi basis data dengan multiple user view, yaitu :
¾
Pendekatan Terpusat (Centralized approach)
Kebutuhan untuk setiap user view digabungkan menjadi
sekumpulan kebutuhan. Sebuah global data model dibuat berdasarkan
atas penggabungan kebutuhan (dimana merepresentasikan seluruh user
view).
¾
Pendekatan Integrasi View (View integration approach)
Kebutuhan untuk setiap user view digunakan untuk membangun
model data terpisah untuk merepresentasikan user view tersebut. Hasil
dari model data tersebut nantinya digabungkan dalam tahapan desain
database.
Model model yang merepresentasikan user view tunggal disebut
local data model, dan tersusun atas diagram-diagram dan dokumentasi
yang secara formal menggambarkan kebutuhan dari user view khusus
terhadap database.
Kemudian local data model digabungkan untuk menghasilkan global data
model, yang merepresentasikan seluruh user view untuk database.
¾
Kombinasi keduanya (Combination of both approaches)
23
2.5.4
Database Design
Desain basis data merupakan suatu proses pembuatan sebuah desain basis
data yang akan mendukung tujuan dan operasi suatu perusahaan.
Tujuan
utamanya adalah:
¾
merepresentasikan data dan relationship antar data yang dibutuhkan oleh
seluruh area aplikasi utama dan user group.
¾
Menyediakan model data yang mendukung segala transaksi yang
diperlukan pada data.
¾
Menspesifikasikan desain minimal yang yang secara tepat disusun untuk
memenuhi kebutuhan performa yang ditetapkan pada sistem (misal :
waktu respon).
Pendekatan dalam desain basis data :
¾
Top-down
Diawali dengan pembentukan model data yang berisi beberapa
entitas high-level dan relationship, yang kemudian menggunakan
pendekatan top-down secara berturut-turut untuk mengindentifikasikan
entitas lower level, relationship dan atribut lainnya.
¾
Bottom-up
Dimulai dari atribut dasar (yaitu, sifat-sifat entitas dan
relationship), dengan analisis dari penggabungan antar atribut, yang
dikelompokan kedalam suatu relasi yang merepresentasikan tipe dari
entitas dan relationship antar entitas.
24
¾
Inside-out
Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda
dengan identifikasi awal entitas utama dan kemudian menyebar ke
entitas, relationship, dan atribut terkait lainnya yang lebih dulu
diidentifikasi.
¾
Mixed
Menggunakan pendekatan bottom-up dan top-down untuk bagian
yang berbeda sebelum pada akhirnya digabungkan.
Tiga fase desain basis data:
¾
Conceptual database design
Suatu proses pembentukan model dari informasi yang digunakan
dalam perusahaan, independen dari keseluruhan aspek fisik. Model data
dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan
pemakai. Model data konseptual merupakan sumber informasi untuk fase
desain logical.
¾
Logical database design
Suatu proses pembentukan model dari informasi yang digunakan
dalam perusahaan berdasarkan model data tertentu (misal : relasional),
tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya.
Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan
dipetakan kedalam model data logical.
25
¾
Physical database design
Suatu proses yang menghasilkan deskripsi implementasi basis
data pada penyimpanan sekunder. Menggambarkan struktur penyimpanan
dan metode akses yang digunakan untuk mencapai akses yang efisien
terhadap data. Dapat dikatakan juga, desain fisikal merupakan cara
pembuatan menuju sistem DBMS tertentu
2.5.5
DBMS Selection
Pemilihan DBMS yang tepat untuk mendukung aplikasi basis data. Dapat
dilakukan kapanpun sebelum menuju desain logical asalkan terdapat cukup
informasi mengenai kebutuhan sistem. Tahap-tahap utama untuk memilih
DBMS:
2.5.6
¾
Mendefinisikan terminologi studi referensi.
¾
Mendaftar dua atau tiga produk.
¾
Evaluasi produk.
¾
Rekomendasi pilihan dan laporan produk.
Application Design
Desain aplikasi adalah desain interface user dan program aplikasi yang
menggunakan dan memproses basis data. Desain basis data dan aplikasi
merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu
¾
:
Transaction design
Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan
oleh user tunggal atau program aplikasi, yang mengakses atau mengubah
26
isi dari basis data. Kegunaan dari desain transaksi adalah untuk
menetapkan dan keterangan karakteristik high-level dari suatu transaksi
yang dibutuhkan pada basis data.
Terdapat tiga tipe transaksi, yaitu :
o
retrieval transaction, digunakan untuk pemanggilan (retrieve)
data untuk ditampilkan di layar atau menghasilkan suatu laporan.
o
update transaction, digunakan untuk menambahkan record baru,
menghapus record lama, atau memodifikasi record yang sudah
ada didalam database.
o
¾
mixed transaction, meliputi pemanggilan dan perubahan data.
User interface design.
Beberapa aturan pokok dalam pembuatan user interface:
o
Meaningful title, diusahakan pemberian nama suatu form cukup
jelas menerangkan kegunaan dari suatu form/report.
o
Comprehensible
instrctions,
penggunaan
terminologi
yang
familiar untuk menyampaikan instruksi ke user dan jika informasi
tambahan dibutuhkan, maka harus disediakan helpscreen
o
Logical grouping and sequencing of fields, field yang saling
berhubungan ditempatkan pada form/report yang sama. Urutan
field harus logis dan konsisten.
o
Visually appealing layout of the form/report, tampilan form/report
harus menarik, dan sesuai dengan hardcopy agar konsisten.
o
Familiar field labels, penggunaan label yang familiar.
27
o
Consistent terminology and abbreviation, terminology dan
singkatan yang digunakan harus konsisten.
o
Consistent use of color.
o
Visible space and boundaries for data-entry fields, jumlah tempat
yang disediakan untuk data entry harus diketahui oleh user.
o
Convinient cursor movement, user dapat dengan mudah
menjalankan operasi yang diinginkan dengan menggerakkan
cursor pada form/report.
o
Error correction for individual characters and entire fields, user
dapat dengan mudah menjalankan operasi yang diinginkan dan
melakukan perubahan terhadap nilai field.
o
Error messages for unacceptable values.
o
Optional fields marked clearly.
o
Explanatory messages for fields, ketika user meletakkan cursor
pada suatu field, maka keterangan mengenai field tersebut harus
dapat dilihat.
o
Completion signal, indikator yang menjelaskan bahwa suatu
proses telah selesai dilaksanakan.
2.5.7
Prototyping
Prototyping adalah membuat model kerja suatu aplikasi basis data.
Tujuan utama dari pembuatan prototyping adalah:
¾
Untuk mengidentifikasi feature dari sistem yang berjalan dengan baik
atau tidak.
28
¾
Untuk memberikan perbaikan-perbaikan atau penambahan feature baru .
¾
Untuk klarifikasi kebutuhan pemakai.
¾
Untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari desain
sistem khusus.
Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu:
¾
Requirements prototyping, menggunakan prototype untuk menentukan
kebutuhan dari aplikasi basis data yang diinginkan dan ketika kebutuhan
itu terpenuhi maka prototype akan dibuang.
¾
Evolutionary
prototyping,
digunakan
untuk
tujuan
yang
sama.
Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan
lanjutan menjadi aplikasi basis data yang digunakan.
2.5.8
Implementation
Implementasi merupakan realisasi fisik dari basis data dan desain
aplikasi. Implementasi basis data dicapai dengan menggunakan :
¾
DDL untuk membuat skema basis data dan file basis data kosong.
¾
DDL untuk membuat user view yang diinginkan.
¾
3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi
basis data disertakan dengan menggunakan DML, atau ditambahkan pada
bahasa pemrograman.
29
2.5.9
Data Conversion and Loading
Pemindahan data yang ada kedalam basis data baru dan mengkonversikan
aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini
dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMS
biasanya memiliki utilitas yang memanggil ulang file yang sudah ada kedalam
basis data baru.
Dapat juga mengkoversi dan menggunakan program aplikasi dari sistem
yang lama untuk digunakan oleh sistem yang baru.
2.5.10 Testing
Testing adalah suatu proses eksekusi program aplikasi dengan tujuan
untuk menemukan kesalahan. Dengan menggunakan strategi tes yang
direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika
terjadi kesalahan software. Mendemostrasikan basis data dan program aplikasi
terlihat berjalan seperti yang diharapkan.
2.5.11 Operational Maintenance
Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi,
meliputi:
¾
Pengawasan performa sistem, jika performa menurun maka memerlukan
perbaikan atau pengaturan ulang basis data.
¾
Pemeliharaan dan pembaharuan aplikasi basis data (jika dibutuhkan).
¾
Penggabungan kebutuhan baru kedalam aplikasi basis data.
30
2.6
Normalisasi
2.6.1
Pengertian Normalisasi
Menurut Connoly (2002, p376), Normalisasi adalah suatu teknik untuk
menghasilkan sekumpulan relasi dengan sifat-sifat (properties) yang diinginkan,
memenuhi kebutuhan data pada perusahaan.
2.6.2
Data Redundancy
Tujuan utama dilakukan normalisasi adalah untuk meminimalisasi
redundansi data dan mengurangi penggunaan tempat penyimpanan yang
dibutuhkan untuh sebuah relasi dasar.
Redundansi data diakibatkan oleh Update Anomalies, yang terdiri dari
tiga tipe yaitu :
¾
Insertion Anomalies adalah keadaan dimana kita tidak dapat menyimpan
fakta atau transaksi yang terjadi di dalam perusahaan.
¾
Deletion Anomalies adalah kondisi bahwa fakta hilang dari basis data
disebabkan penghapusan file yang lain.
¾
Modification Anomalies adalah kondisi bahwa fakta hilang dari basis
data disebabkan perubahan pada file yang lain.
Untuk mengatasi anomalies ini dapat dilakukan decomposotion pada
relasi dasar. Terdapat dua sifat Decomposition yaitu
¾
:
Lossless-join
Memungkinkan kita menemukan suatu instance relasi dasar dari
instance koresponden dalam relasi yang lebih kecil.
31
¾
Dependency Preservation Properties
Memungkinkan kita untuk mengadakan batasan pada relasi dasar
dengan menyediakan beberapa batasan pada relasi yang lebih kecil.
2.6.3
Functional Dependency
Merupakan konsep inti yang terkait dengan normalisasi. Functional
Dependency, menjelaskan relationship antar atribut-atribut dalam relasi.
Functional Dependency merupakan sifat dari arti semantik suatu atribut dalam
sebuah relasi.
B is functionally
A
B
dependent on A
Gambar 2.10 Diagram Function Dependency
Determinant dari functional dependency mengacu kepada atribut atau
himpunan atribut disebelah kiri anak panah.
Karakteristik utama dari functional dependency yang digunakan dalam
normalisasi :
¾
Mempunyai relationship a 1:1 antar atribut di sebelah kiri dan kanan
dependency.
¾
Saling terkait (Hold for all time)
Misal : staffNo Æ sName dan sName Æ staffNo
¾
Nontrivial.
32
2.6.4
Proses Normalisasi
Proses Normalisasi adalah :
¾
Suatu teknik formal untuk menganalisis relasi berdasarkan primary key
dan functional dependencies antar atribut.
¾
Dieksekusi dalam beberapa langkah. Setiap langkah mengacu ke bentuk
normal tertentu, sesuai dengan sifat yang dimilikinya.
¾
Setelah normalisasi diproses, relasi menjadi secara bertahap lebih
terbatas/kuat bentuk formatnya dan juga mengurangi tindakan update
yang anomali.
Gambar 2.11 Tahapan Normalisasi
2.6.4.1 UNF (Unnormalized Form)
Merupakan suatu tabel yang berisikan satu atau lebih groups yang
berulang.
Untuk
membuat
tabel
unnormalized
yaitu
dengan
memindahkan data dari sumber informasi kedalam format tabel dengan
baris dan kolom. Jika ada atribut yang bernilai multivalue, maka relasi
tersebut dalam kondisi unnormalized.
33
2.6.4.2 1NF (First Normal Form)
1NF merupakan sebuah relasi dimana setiap irisan antara baris
dan kolom berisikan satu dan hanya satu nilai (tidak ada atribut yang
bernilai multivalue).
Cara merubah UNF ke 1NF adalah :
¾
Tunjuk satu atau sekumpulan atribut sebagai kunci untuk tabel
unnormalized.
¾
Identifikasikan groups yang berulang dalam tabel unnormalized
yang berulang untuk kunci atribut.
¾
Hapus group yang berulang dengan cara
o
:
Masukkan data yang semestinya kedalam kolom yang
kosong pada baris yang berisikan data yang berulang
(flattening the table), atau dengan cara
o
Menggantikan data yang ada dengan copy dari kunci
atribut yang sesungguhnya kedalam relasi terpisah.
2.6.4.3 2NF (Second Normal Form)
Berdasarkan pada konsep full functional dependency, yaitu A dan
B merupakan atribut dari sebuah relasi, B dikatakan fully dependent
terhadap A jika B functionally dependent pada A tetapi tidak pada proper
subset dari A.
2NF adalah sebuah relasi dalam 1NF dan setiap atribut nonprimary-key bersifat fully functionally dependent pada primary key.
34
Cara merubah 1NF ke 2NF adalah :
¾
Identifikasikan primary key untuk relasi 1NF.
¾
Identifikasikan functional dependencies dalam relasi.
¾
Jika terdapat partial dependencies terhadap primary key, maka
hapus dengan menempatkannya dalam relasi yang baru bersama
dengan salinan determinan-nya.
2.6.4.4 3NF (Third Normal Form)
Berdasarkan pada konsep transitive dependency, yaitu suatu
kondisi dimana A, B dan C merupakan atribut dari sebuah relasi, maka
jika A Æ B dan B Æ C, maka C transitively dependent pada A melalui
B. (Jika A tidak functionally dependent pada B atau C).
3NF adalah sebuah relasi dalam 1NF dan 2NF dan dimana tidak
terdapat atribut non-primary-key atribut yang bersifat transitively
dependent pada primary key.
Transitive dependency adalah jika suatu atribut dependent pada
satu atau lebih non-primary-key.
Cara merubah 2NF ke 3NF adalah :
¾
Identifikasikan primary key dalam relasi 2NF.
¾
Identifikasikan functional dependencies dalam relasi.
¾
Jika terdapat transitive dependencies terhadap primary key, hapus
dengan menempatkannya dalam relasi yang baru bersama dengan
salinan determinan-nya.
35
2.6.4.5 BCNF (Boyce-Codd Normal Form)
Berdasarkan pada functional dependencies yang dimasukan
kedalam
hitungan
bagaimanapun
seluruh
BCNF
juga
candidate
memiliki
key
dalam
suatu
batasan-batasan
relasi,
tambahan
disamakan dengan definisi umum dari 3NF. Suatu relasi dikatakan
BCNF, jika dan hanya jika setiap determinan merupakan candidate key.
Perbedaan antara 3NF dan BCNF yaitu untuk functional
dependency A → B, 3NF memungkinkan dependency ini dalam suatu
relasi jika
B adalah
atribut primary-key dan A bukan merupakan
candidate key. Sedangkan BCNF menetapkan dengan jelas bahwa untuk
dependency ini agar ditetapkan dalam relasi maka A harus merupakan
candidate key.
Setiap relasi dalam BCNF juga merupakan 3NF, tetapi relasi
dalam 3NF belum tentu termasuk kedalam BCNF.
Dalam BCNF kesalahan jarang sekali terjadi. Kesalahan dapat
terjadi pada relasi yang :
¾
Terdiri dari 2 atau lebih composite candidate key.
¾
Candate key overlap, sedikitnya satu atribut.
2.6.4.6 4NF (Fourth Normal Form)
Meskipun sebuah tabel telah mencapai normal BCNF, namun
masih mungkin terjadi kesulitan berkenaan dengan adanya informasi
berulang yang disebut sebagai multivalue.
36
Multi-valued Dependency adalah representasi ketergantungan
antara attribut (contoh : A, B dan C) dalam relasi, misalnya untuk setiap
nilai A ada sekumpulan nilai untuk B dan sekumpulan nilai untuk C.
Tetapi, kumpulan nilai B dan C independen satu sama lain.
4NF adalah relasi yang termasuk BCNF dan tidak mengandung
nontrivial ketergantungan nilai jamak.
2.6.4.7 5NF (Fifth Normal Form)
5NF disebut juga Project Join Normal Form (PJNF) karena
berkaitan dengan konsistensi antara tabel asal dengan tabel hasil
pengabungan, tabel proyeksi atau tabel dekomposisi.
Suatu relasi R berada dalam 5NF jika dan hanya setiap
ketergantungan gabungan (Join Dependency) pada relasi R diperoleh dari
kunci-kunci kandidat relasi R.
Ketergantungan gabungan (Join Dependency) merupakan bentuk
umum dari ketergantungan nilai jamak. Ketergantungan nilai jamak
(Multi_Valued
Dependency)
merupakan
bentuk
umum
dari
ketergantungan fungsional (Functional Dependency).
2.7
Perancangan Software Model Waterfall
Model Waterfall menyarankan pendekatan sistematic, sequential untuk
pengembangan software yang dimulai pada level sistem & perkembangan
melalui analysis, design, coding & support.
37
Model Waterfall memiliki aktivitas System Engineering and Modeling,
Software Requirement Analysis, Design, Code Generation, Testing dan Support.
System
Engineering dan
Modeling
Software
Requirement and
Analysis
Design
Code Generation
Testing
Support
Gambar 2.12 Model Waterfall
2.7.1
System Engineering and Modeling
Karena software selalu menjadi bagian dari sistem yang besar, pekerjaan
dimulai dengan membangun persyaratan untuk semua elemen sistem dan
kemudian mengalokasikan beberapa subset dari requirement ini ke dalam
software. Pandangan sistem ini sangat penting ketika software harus berinteraksi
dengan elemen lain seperti hardware, orang dan database. Langkah ini meliputi
pengumpulan requirement pada level sistem dengan sejumlah kecil design dan
analysis level atas.
2.7.2
Software Requirement Analysis
Proses pengumpulan requirement diintensifkan dan difokuskan spesifik
pada software. Untuk mengerti cara kerja program yang akan dibuat, analis harus
38
mengerti domain informasi untuk software. Requirement untuk kedua sistem dan
software didokumentasikan dan direview dengan customer.
2.7.3
Design
Desain software sebenarnya merupakan proses multistep yang fokus pada
4 atribut berbeda pada program : data struktur, arsitektur software, representasi
interface dan detail procedural. Proses desain mentranslasikan pengumpulan
requirement menjadi representasi software yang dapat menilai kualitas sebelum
coding dimulai.
2.7.4
Code Generation
Desain harus ditranslasikan ke dalam form machine-readable. Langkah
Code Generation melakukan tugas ini dan dapat dikerjakan secara mekanis.
2.7.5
Testing
Ketika code telah dibuat, testing program dimulai. Proses testing fokus
pada internal logikal software, memastikan bahwa semua statement telah diuji
coba, dan pada external fungsional, melakukan tes untuk mengatasi kesalahan
dan memastikan bahwa input terdefinisi akan menghasilkan hasil sebenarnya
yang sesuai dengan hasil yang dibutuhkan.
2.7.6
Support
39
Software pasti akan mengalami perubahan setelah diberikan kepada
customer. Dukungan software/ pemeliharaan menerapkan kembali setiap fase
sebelumnya ke dalam program yang sudah ada daripada ke program yang baru.
2.8 Penjualan
2.8.1
Pengertian Penjualan
Menurut Kamus Istilah Akuntansi (1999, p404), Penjualan adalah (1)
Penerimaan yang diperoleh dari pengiriman barang dagangan atau dari
penyerahan pelayanan dalam bursa sebagai bahan pertimbangan. Pertimbangan
ini dapat dalam bentuk tunai, peralatan kas, atau harta lainnya. Pendapatan dapat
diperoleh pada saat penjualan, karena terjadi pertukaran, harga jual dapat
ditetapkan, dan bebannya diketahui. (2) Dalam penjualan eceran, ada penurunan
harga sementara untuk menggerakkan persediaan dan meningkatkan kas.
2.8.2
Tipe-tipe Penjualan
Menurut Mulyadi (2001, p202), penjualan dapat dibagi menjadi dua tipe
berdasarkan cara pembayarannya, yaitu :
¾
Penjualan Tunai
Penjualan tunai adalah transaksi penjualan dimana barang atau
jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan
telah menerima uang atau pembayaran dari pembeli.
¾
Penjualan Kredit
Penjualan kredit adalah transaksi penjualan dimana jika pesanan
dari pembeli atau pelanggan telah dipenuhi dengan mengirim barang atau
40
penyerahan jasa, maka untuk jangka waktu tertentu perusahaan memiliki
piutang kepada pelanggannya.
2.9
Pembelian
2.9.1
Pengertian Pembelian
Pembelian adalah transaksi yang dilakukan perusahaan dalam rangka
pengadaan barang yang diperlukan oleh perusahaan baik yang digunakan sendiri
maupun yang akan dijual kembali.
2.9.2
Tipe-tipe Pembelian
Menurut Mulyadi (2001, p299), pembelian dapat dibagi menjadi dua tipe
berdasarkan pemasoknya, yaitu :
¾
Pembelian Lokal
Pembelian lokal adalah pembelian dari pemasok dalam negeri.
¾
Pembelian Impor
Pembelian impor adalah pembelian dari pemasok luar negeri.
2.10
Persediaan
Persediaan adalah barang yang dimiliki dengan tujuan untuk dijual
kembali atau diproses dan kemudian dijual. Menurut Prinsip Akuntansi
Indonesia, persediaan digunakan untuk menyatakan barang berwujud yang :
¾
Tersedia untuk dijual (barang dagang/barang jadi)
¾
Masih dalam proses produksi untuk diselesaikan, kemudian dijual
(barang dalam proses/pengolahan)
41
¾
Akan digunakan untuk produksi barang jadi yang akan dijual (bahan baku
dan bahan pembantu) dalam rangka kegiatan normal perusahaan
Menurut Kamus Istilah Akuntansi (1999, p251), Persediaan adalah
barang dagangan atau persediaan yang ada ditangan atau dalam perjalanan pada
suatu waktu tertentu. Yang termasuk dalam persediaan adalah : (1) barang dalam
transit yang fakturnya telah diterima dan (2) barang selain barang titipan.
Menurut Mulyadi (2001, p553), persediaan bisa berbeda tergantung jenis
usahanya. Dalam perusahaan manufaktur, persediaan terdiri dari :
¾
Persediaan produk jadi
¾
Persediaan produk dalam proses
¾
Persediaan bahan baku
¾
Persediaan bahan penolong
¾
Persediaan bahan habis pakai pabrik
¾
Persediaan suku cadang
Sedangkan dalam perusahaan dagang, persediaan hanya terdiri dari satu
golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli
untuk tujuan dijual kembali.