BAB 2 LANDASAN TEORI 2.1 Teori Dasar Sistem Basis Data 2.1.1

BAB 2
LANDASAN TEORI
2.1
Teori Dasar Sistem Basis Data
2.1.1
Data
Menurut Everest (1986, p3), data adalah “fakta” yang dipresentasikan
dengan nilai berupa angka, karakter string, atau symbol yang memiliki arti
dalam beberapa konteks.
Menurut Turban (2005, p38), data merupakan kumpulan fakta atau
deskripsi dasar dari sesuatu, kejadian, aktifitas, dan transaksi, yang diambil,
dicatat, disimpan dan dikelompokkan, tetapi tidak diatur untuk menyatakan
suatu arti tertentu.
Menurut Whitten (2004, p27, p553), data adalah fakta mentah mengenai
orang, tempat, kejadian, dan apapun yang penting bagi perusahaan. Dimana
setiap fakta sebenarnya, jika berdiri sendiri, relatif tidak memiliki arti. Data
merupakan sebuah sumber daya yang harus dikendalikan dan dikelola.
Jadi, dapat disimpulkan bahwa data adalah fakta yang dipresentasikan
dengan nilai mengenai sesuatu, kejadian, aktifitas, dan transaksi yang perlu
dikontrol dan dikelola sehingga dapat berguna bagi suatu pihak/organisasi.
7
8
2.1.2
Basis Data
Menurut Turban (2005, p37), basis data merupakan kumpulan file, tabel,
relations, dan lain-lain yang saling berhubungan, yang menyimpan data dan
asosiasi-asosiasi diantaranya.
Menurut Whitten (2004, p548), basis data adalah koleksi dari file yang
saling berhubungan.
Menurut Connolly dan Begg (2005, p15), basis data adalah sekumpulan
data yang saling berhubungan dimana dirancang untuk mencapai informasi
yang diperlukan dalam suatu organisasi. Artinya basis data adalah tempat
penyimpanan data yang besar dimana bisa digunakan secara simultan atau
secara bersamaan oleh banyak departemen dan pemakai lainnya (user). Di
dalam basis data semua item data diintegrasikan untuk menghindarkan
duplikasi data (redudancy). Basis data tidak hanya mengandung data
operasional organisasi, tetapi juga deskripsi dari data tersebut (meta-data).
Sehingga dapat disimpulkan bahwa basis data merupakan suatu
kumpulan data yang saling berhubungan antara satu dengan yang lainnya, yang
dapat digunakan secara simultan atau secara bersamaan oleh banyak user, dan
item data pada basis data diintegrasikan untuk menghindarkan duplikasi data.
2.1.2.1 Karakteristik Basis Data
Menurut Mannino (2004, p4), basis data memiliki beberapa
karakteristik, yaitu :
9
a) Persistent, artinya data berada pada tempat penyimpanan yang stabil
seperti pada magnetic disk. Variabel pada computer tidak bersifat
persistent karena berada pada memori utama dan akan menghilang
seiring ditutupnya program. Persistent juga bukan berarti data akan
selamanya ada. Ketika data sudah tidak lagi relevan maka data
tersebut akan dibuang atau diarsipkan.
b) Shared, artinya basis data dapat mempunyai banyak kegunaan dan
banyak user. Basis data menyediakan memori yang umum untuk
beragam fungsi dalam suatu organisasi. Kecuali jika dua users
mencoba untuk merubah suatu bagian yang sama pada basis data
pada saat yang bersamaan, mereka dapat langsung melakukannya
tanpa harus menunggu yang lain.
c) Interrelated, artinya data tersimpan dalam unit yang terpisah-pisah,
tapi dapat dihubungkan untuk menyediakan data yang dibutuhkan.
2.1.3
Sistem Basis Data
Menurut Date (2000, p5), pada dasarnya sistem basis data adalah sistem
penyimpanan yang telah terkomputerisasi yang secara keseluruhan bertujuan
untuk menyimpan informasi dan memungkinkan penggunanya mengambil dan
mengubah informasi tersebut pada saat yang dibutuhkan.
Komponen-komponen penting dalam sistem basis data yaitu :
10
1. Data
Data dalam basis data dapat merupakan data yang single user (hanya satu
pengguna yang beroperasi pada basis data) atau multi user, dimana satu
atau lebih user beroperasi secara bersama-sama ke dalam basis data.
Sehingga data dalam basis data terutama untuk sistem yang besar, harus
terintegrasi dan dapat dipakai secara bersamaan.
2. Perangkat Keras (Hardware)
Untuk manajemen basis data hanya dibutuhkan mesin standard, namun
yang harus diperhatikan adalah kapasitas penyimpanan karena basis data
akan membutuhkan kapasitas yang besar.
3. Perangkat Lunak (Software)
Piranti lunak untuk sistem basis data disebut DBMS (Database
Management System).
4. Pengguna (User)
Pengguna yang terlibat dalam komponen DBMS yaitu :
a) Database Administrator
Bertanggung jawab untuk mengatur manajemen sumber daya data
yang meliputi perencanaan basis data, pengembangan dan
pemeliharaan standardnya, aturan dan prosedur, dan rancangan
basis data konseptual atau logikal.
b) Programmer
Programmer adalah seseorang atau sekelompok orang yang
menjadi
tenaga
ahli
komputer
yang
berfungsi
untuk
11
mengembangkan program-program aplikasi yang diperlukan dalam
DBMS.
c) End-user (Pengguna Akhir)
Yang termasuk dalam kategori pengguna akhir adalah pemilik
sistem, para manajer, operator dan sebagainya yang terlibat
langsung dalam penggunaan sistem basis data.
2.2
Database Management System (DBMS)
Definisi Database Management System (DBMS) menurut Whitten
(2004, p554) adalah perangkat lunak khusus yang digunakan untuk membuat,
mengakses, mengendalikan, dan mengelola sebuah basis data.
Menurut Connolly dan Begg (2005, p16), Database Management
System (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna
untuk mendefinisikan, membuat, me-maintain, dan mengontrol akses ke basis
data.
Fasilitas-fasilitas yang pada umumnya disediakan oleh DBMS adalah
sebagai berikut (Connolly dan Begg, 2005, p16-17) :
a) Pendefinisian basis data menggunakan Data Definition Language
(DDL).
b) Insert, update, delete dan mengambil data dari basis data yang
biasanya menggunakan Data Manipulation Language (DML).
c) Penyediaan akses yang terkontrol ke basis data seperti :
12
•
Sistem keamanan (security system), mencegah pengguna
yang tidak berhak mengakses basis data.
•
Sistem integritas (integrity system), memelihara konsistensi
data yang disimpan.
•
Sistem kontrol akses yang bersamaan (concurrency control
system), mengijinkan akses basis data secara bersamaan.
•
Sistem kontrol perbaikan (recovery control system),
mengembalikan basis data ke kondisi konsisten sebelumnya
setelah terjadi kegagalan perangkat keras atau perangkat
lunak.
•
Katalog pengguna (user-accessible catalog), berisi deskripsi
data dalam basis data.
2.2.1
Keuntungan dari DBMS
Menurut Connolly dan Begg (2005, p26), keuntungan dari DBMS
meliputi :
a) Mengontrol duplikasi data.
b) Konsistensi data.
c) Informasi lebih dari jumlah data yang sama.
d) Penggunaan data secara bersamaan.
e) Meningkatkan integritas data.
f) Meningkatkan keamanan.
13
g) Pelaksanaan standardisasi.
h) Skala ekonomi tertentu.
i) Skala ekonomi.
j) Keseimbangan antara persyaratan yang saling bertentangan.
k) Meningkatkan aksesibilitas data dan responsibilitas data.
l) Meningkatkan produktivitas.
m) Meningkatkan pemeliharaan melalui data yang bebas.
n) Meningkatkan konkurensi.
o) Meningkatkan backup dan recovery service.
2.2.2
Kerugian dari DBMS
Menurut Connolly dan Begg (2005, p29), kerugian dari DBMS
meliputi :
a) Kompleksitas.
b) Memerlukan disk space dan memory yang tidak sedikit.
c) Harga dari DBMS yang pada umumnya cukup mahal.
d) Biaya hardware tambahan.
e) Biaya konversi.
f) Performa.
g) Dampak yang lebih hebat jika terjadi kegagalan.
14
2.2.3
Structured Query Language (SQL)
Menurut Connolly dan Begg (2005, p113), Structured Query Language
(SQL) merupakan sebuah contoh dari transform-oriented language, atau sebuah
bahasa yang didesain untuk menggunakan relasi untuk mentransformasikan
inputs ke output yang dibutuhkan. Sebagai sebuah bahasa, standar ISO SQL
memiliki dua komponen utama yaitu :
2.2.4
•
Data Definition Language (DDL)
•
Data Manipulation Language (DML)
Data Definition Language (DDL)
Menurut Connolly dan Begg (2005, p40), Data Definition Language
(DDL) adalah sebuah bahasa yang memungkinkan DBA atau user untuk
mendeskripsikan dan memberi nama entitas, atribut, dan hubungan yang
dibutuhkan
untuk
aplikasi,
termasuk
batasan-batasan
keamanan
dan
integritasnya.
Hasil kompilasi dari Data Definition Language (DDL) adalah
seperangkat tabel yang disimpan dalam file spesial yang dinamakan katalog
sistem.
Katalog
sistem
ini
mengintegrasikan
meta-data,
data
yang
menggambarkan objek dalam basis data dan membuatnya menjadi lebih mudah
untuk diakses.
Statement standar DDL yang utama pada umumnya adalah sebagai
berikut (Connolly dan Begg, 2005, p168) :
15
a) CREATE SCHEMA
b) CREATE DOMAIN
c) CREATE TABLE
d) CREATE VIEW
e) ALTER DOMAIN
f) ALTER TABLE
g) DROP SCHEMA
h) DROP DOMAIN
i) DROP TABLE
j) DROP VIEW
2.2.5
Data Manipulation Language (DML)
Menurut Connolly dan Begg (2005, p40), Data Manipulation Language
(DML) adalah sebuah bahasa yang menyediakan seperangkat operasi untuk
mendukung operasi dasar manipulasi data pada data dalam basis data.
Operasi manipulasi data biasanya mencakup berikut ini :
a) Memasukkan data baru ke dalam basis data (insert).
b) Memodifikasi data yang ada di dalam basis data (update).
c) Mengambil data yang disimpan di dalam basis data (select).
d) Menghapus data yang terdapat di dalam basis data (delete).
Data Manipulation Language (DML) dapat dibedakan menjadi dua tipe,
yaitu :
16
a) Procedural DML
Procedural DML adalah sebuah bahasa yang memungkinkan
user untuk memberitahukan kepada sistem akan data yang
dibutuhkan dan bagaimana tepatnya data tersebut diambil.
Procedural DML tertanam dalam bahasa pemrograman tingkat
tinggi dimana menyediakan fasilitas untuk iterasi dan menangani
navigasi logika.
b) Non-procedural DML
Non-procedural
DML
adalah
sebuah
bahasa
yang
memungkinkan user untuk menyampaikan data apa yang
diperlukan tanpa perlu menyampaikan bagaimana data tersebut
diambil. Pada umumnya, non-procedural DML lebih mudah
untuk dipelajari dan digunakan daripada procedural DML.
2.2.6
Fourth Generation Language (4th GL)
Menurut Connolly dan Begg (2005, p42), dibandingkan dengan 3rd GL
yang procedural, 4th GL adalah non-procedural yaitu pengguna lebih
ditekankan pada pendefinisian apa yang akan dikerjakan, daripada bagaimana
mengerjakannya. Contoh 4th GL meliputi :
a) Forms generators
Merupakan fasilitas interaktif untuk membuat form input data
dan tampilannya. Mendefinisikan desain tampilan, informasi apa
17
yang akan disajikan, komponen warna pada layar dan
karakteristik lainnya.
b) Report generators
Membuat laporan yang datanya diambil dari basis data.
Memungkinkan
pengguna
untuk
mengambil
data
yang
diperlukan untuk laporan. Lebih menekankan kepada rancangan
output, yaitu bagaimana suatu laporan akan disajikan.
c) Graphic generators
Digunakan untuk mengambil data dari basis data, dan
menampilkannya dalam bentuk grafik, seperti bar chart, pie
chart, dan lain-lain.
d) Application generators
Fasilitas untuk menghasilkan program yang berhubungan
dengan data, menentukan bagaimana menampilkan fungsi-fungsi.
2.3
Database System Development Lifecycle
Siklus hidup pengembangan sistem basis data atau dikenal juga dengan
database system development lifecycle (DSDLC) merupakan suatu pendekatan
terstruktur untuk mengembangkan sistem basis data. Karena sistem basis data
merupakan komponen yang penting dalam sistem informasi suatu perusahaan
besar, siklus hidup pengembangan sistem basis data berkaitan erat dengan
siklus hidup sistem informasi. (Connolly dan Begg, 2005, p282-p283)
18
Adalah penting untuk mengetahui bahwa tahapan siklus hidup
pengembangan sistem basis data tidaklah harus berurutan, tetapi melibatkan
sejumlah pengulangan tahapan sebelumnya melalui feed-back loops.
Berikut ini akan ditunjukkan tahapan database system development
lifecycle (DSDLC) pada gambar di bawah ini :
Gambar 2.1 Tahap-tahap database system development lifecycle.
(Connolly dan Begg, 2005, p284)
19
2.3.1
Database Planning (Perencanaan Basis Data)
Database planning (perencanaan basis data) merupakan aktivitasaktivitas manajemen yang memungkinkan tahap-tahap dalam database system
development lifecycle direalisasikan seefisien dan seefektif mungkin (Connolly
dan Begg, 2005, p285). Perencanaan basis data harus diintegrasikan dengan
keseluruhan sistem informasi suatu organisasi. Ada tiga persoalan pokok yang
terlibat dalam perumusan suatu strategi sistem informasi :
a) Identifikasi rencana, sasaran dan tujuan perusahaan dengan
penetuan kebutuhan sistem informasi.
b) Evaluasi
sistem infromasi
yang
sedang
berjalan
untuk
menentukan kelebihan dan kekurangan yang ada.
c) Penilaian terhadap peluang IT (Information Technology) apakah
mampu menghasilkan keuntungan yang kompetitif.
Tahapan dalam perencanaan basis data juga harus menjelaskan :
a) Mission statement dari proyek basis data. Mission statement ini
menjelaskan tujuan utama aplikasi basis data, juga membantu
menjelaskan tujuan proyek basis data, dan menyediakan maksud
yang lebih jelas dalam pembuatan aplikasi basis data secara
efektif dan efisien (Connolly dan Begg, 2005, p286). Dengan
merumuskan apa sebenarnya yang menjadi tujuan dari proyek
basis data ini maka diharapkan dapat lebih memfokuskan
pekerjaan pada tahap selanjutnya.
20
b) Mission objectives. Selain merumuskan tujuan dari sebuah
proyek basis data, harus diperhatikan juga mengenai tugas apa
saja yang harus didukung oleh basis data tersebut. Setiap mission
objective akan menjelaskan tugas tertentu yang harus didukung
oleh basis data, dengan asumsi jika basis data mendukung
mission objective, maka mission statement juga akan sesuai
(Connolly dan Begg, 2005, p286).
Di dalam perencanaan basis data juga meliputi perkembangan standar
yang akan menentukan bagaimana suatu data akan dikumpulkan, bagaimana
format yang harus ditetapkan, lalu dokumentasi apa saja yang akan dibutuhkan,
serta bagaimana desain dan implementasi harus dikerjakan nantinya.
2.3.2
System Definition (Pendefinisian Sistem)
System definition (pendefinisian sistem) menjelaskan bidang dan
batasan aplikasi basis data serta pandangan pengguna (user view) secara umum
(Connolly dan Begg, 2005, p286). Hal ini sangat penting dilakukan dalam suatu
proses perancangan basis data agar dapat melakukan proses identifikasi
mengenai batasan sistem yang akan dirancang, serta bagaimana sistem tersebut
akan berhubungan dengan bagian sistem informasi pada organisasi yang lain.
Selain itu batasan sistem sebaiknya tidak hanya sesuai dengan bidang dan
batasan aplikasi serta pandangan pengguna yang telah ada saja pada saat ini,
namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.
21
Pandangan pengguna sangat diperlukan untuk mengidentifikasi
informasi-informasi yang dibutuhkan oleh pengguna (user). Pandangan
pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari
sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari
sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau
pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan
dan transaksi yang akan dijalankan terhadap data itu (Connolly dan Begg, 2005,
p287).
2.3.3
Requirements Collection and Analysis (Pengumpulan Kebutuhan dan
Analisis)
Pada tahap ini dilakukan proses pengumpulan dan analisa informasi
mengenai bagian organisasi yang harus didukung oleh aplikasi basis data, dan
penggunaan informasi ini berguna untuk mengidentifikasi persyaratan
pengguna terhadap sistem yang baru (Connolly dan Begg, 2005, p288).
Tahap ini meliputi pengumpulan dan analisis informasi mengenai
bagian perusahaan yang harus dilayani oleh basis data. Ada tiga pendekatan
utama untuk pengaturan kebutuhan aplikasi basis data dengan multiple user
views, yakni :
a) Pendekatan centralized
Kebutuhan-kebutuhan untuk setiap user view digabung dalam
suatu kumpulan kebutuhan tunggal untuk aplikasi basis data
baru.
22
b) Pendekatan view intergration
Kebutuhan-kebutuhan untuk setiap user view digunakan untuk
membangun
sebuah
model
data
yang
terpisah
untuk
merepresentasikan pengguna itu sendiri. Hasil dari model data
akan digabung pada tahap perancangan basis data.
c) Kombinasi antara centralized dan view integration.
Suatu proses resmi dalam menggunakan teknik-teknik seperti
wawancara atau kuesioner untuk mengumpulkan fakta-fakta tentang sistem dan
kebutuhan-kebutuhannya dinamakan dengan teknik fact-finding (Connolly dan
Begg, 2005, p314). Ada lima kegiatan yang dapat dipakai dalam teknik ini,
yaitu :
1) Memeriksa dokumentasi
Pemahaman terhadap jalannya sistem akan cepat diperoleh
dengan memeriksa dokumen-dokumen, formulir, laporan, dan
berkas yang terkait dengan sistem yang sedang berjalan pada
perusahaan.
Dengan
pemeriksaan
ini
diharapkan
dapat
mengetahui data-data apa saja yang akan disimpan di dalam
basis data (Connolly dan Begg, 2005, p317).
2) Wawancara
Wawancara
bertujuan
untuk
mengumpulkan
fakta-fakta,
memeriksa kebenaran fakta yang ada dan mengklarifikasinya,
menimbulkan
antusiasme,
melibatkan
pengguna
akhir,
23
mengidentifikasi kebutuhan-kebutuhan, dan mengumpulkan ideide dan pendapat (Connolly dan Begg, 2005, p317). Teknik ini
memerlukan
kemampuan
komunikasi
yang
baik
untuk
menghadapi pengguna yang memiliki nilai, prioritas, pendapat,
motivasi, dan kepribadian yang berbeda-beda.
3) Observasi
Pengamatan ini memungkinkan untuk ikut serta atau mengamati
seseorang melakukan kegiatan untuk mempelajari sistem. Salah
satu faktor pengamatan dapat berhasil adalah dengan mencari
informasi sebanyak mungkin tentang aktivitas yang akan diamati
serta orang yang melakukan aktivitas tersebut (Connolly dan
Begg, 2005, p319).
4) Penelitian
Selain melakukan penelitian yang berasal dari dalam organisasi
itu sendiri, dapat juga dilakukan pengumpulan informasi yang
berasal dari luar organisasi tersebut. Beberapa contoh sumber
informasi tersebut antara lain jurnal komputer, buku-buku
referensi, dan internet. Sumber informasi tersebut juga dapat
digunakan untuk memecahkan masalah serupa (Connolly dan
Begg, 2005, p319).
5) Kuesioner
Teknik lain yang dapat digunakan untuk mengumpulkan
informasi yang dibutuhkan adalah dengan menggunakan
24
kuesioner. Kuesioner adalah suatu dokumen dengan tujuan
khusus yang memungkinkan fakta-fakta dikumpulkan dari
banyak orang sambil menjaga kontrol terhadap tanggapan yang
diberikan (Connolly dan Begg, 2005, p320).
2.3.4
Database Design (Perancangan Basis Data)
Perancangan basis data merupakan proses menciptakan perancangan
untuk basis data yang akan mendukung operasi dan tujuan perusahaan
(Connolly dan Begg, 2005, p291).
Terdapat dua pendekatan dalam perancangan basis data (Connolly dan
Begg, 2005, p291), yaitu :
a) Bottom-up
Pendekatan ini dimulai dari tingkat paling dasar dari atribut
(yakni properti dari entity dan hubungan relasional) dimana
melalui analisis gabungan antara atribut-atribut, dikelompokkan
ke dalam relasi-relasi yang merepresentasikan tipe-tipe entity
dan hubungan antara entity. Pendekatan ini lebih cocok untuk
perancangan basis data yang sederhana dengan jumlah atribut
yang relatif kecil.
b) Top-down
Pendekatan ini dimulai dari pengembangan model data yang
terdiri dari beberapa hubungan relasional dan entity tingkat
tinggi.
25
Perancangan basis data terdiri dari tiga tahap utama (Connolly dan Begg,
2005, p293), yaitu :
1. Conceptual Database Desain (Perancangan Basis Data
Konseptual)
Perancangan basis data konseptual adalah proses membangun
suatu model informasi yang digunakan oleh perusahaan atau
organisasi yang tidak tergantung dari pertimbangan fisik
(Connolly dan Begg, 2005, p293).
2. Logical Database Design (Perancangan Basis Data Logikal)
Perancangan basis data logikal adalah proses pembuatan suatu
model informasi yang digunakan pada perusahaan berdasarkan
pada model data yang spesifik, tetapi tidak tergantung dari
Database Management System (DBMS) yang khusus dan
pertimbangan fisik lain (Connolly dan Begg, 2005, p294).
3. Physical Database Design (Perancangan Basis Data Fisikal)
Perancangan basis data fisikal adalah suatu proses untuk
menghasilkan gambaran dari implementasi basis data pada
tempat penyimpanan, menjelaskan dasar dari relasi, organisasi
file dan indeks yang digunakan untuk efisiensi data dan
menghubungkan beberapa integrity constraints dan tindakan
keamanan (Connolly dan Begg, 2005, p294)
26
2.3.5
DBMS Selection (Pemilihan DBMS)
Tahapan ini bertujuan untuk memilih DBMS yang tepat untuk
mendukung aplikasi basis data, dimana dibutuhkan tambahan beberapa
software dan hardware. Berikut ini adalah tahapan utama untuk memilih basis
data, yaitu :
1. Define terms of reference of study, cakupan penelitian mengenai
pemilihan DBMS menyatakan tujuan dan ruang lingkup
penelitian serta tugas-tugas yang harus dilakukan, meliputi
deskripsi kriteria (berdasarkan spesifikasi kebutuhan pengguna)
untuk mengevaluasi produk DBMS, daftar DBMS yang tersedia
dan batasan-batasan serta jadwal waktu untuk penelitiannya.
2. Shortlist two or three products, kriteria-kriteria yang dianggap
kritis untuk keberhasilan implementasi yang dapat digunakan
untuk evaluasi daftar DBMS yang tersedia.
3. Evaluate products, ada banyak fitur yang dapat digunakan untuk
mengevaluasi sebuah produk DBMS, semua bobot nilai dari
fitur-fitur tersebut dijumlahkan untuk mendapatkan nilai sebuah
produk DBMS tertentu yang akan dibandingkan dengan nilai
produk DBMS lainnya. Produk DBMS yang dipilih adalah
produk dengan nilai tertinggi.
4. Recommend selection and produce report, tahap akhir dari
pemilihan DBMS adalah untuk mendokumentasikan proses dan
27
untuk menyediakan laporan dan rekomendasi mengenai produk
DBMS tertentu.
2.3.6
Application Design (Perancangan Aplikasi)
Merupakan perancangan user interface dan program aplikasi yang
menggunakan dan memproses basis data. Ada dua aspek penting dalam
perancangan aplikasi, yakni :
a) Transaction Design (Perancangan Transaksi)
Transaksi merupakan sebuah aksi, atau serangkaian aksi yang
dilakukan oleh seorang pengguna atau program aplikasi yang
mengakses atau mengubah isi dari basis data. Tujuan
dari
perancangan
dan
transaksi
adalah
untuk
menetapkan
mendokumentasikan karakteristik tingkat tinggi dari transaksi
yang dibutuhkan pada basis data, yang termasuk :
•
Data yang digunakan dalam transaksi.
•
Karateristik fungsional dari transaksi.
•
Output dari transaksi.
•
Kepentingan pengguna.
•
Nilai yang diharapkan dari pemakaian.
Perancangan ini harus dilakukan lebih awal dalam proses
perancangan untuk memastikan bahwa basis data yang
28
diimplementasikan mampu mendukung semua transaksi yang
dibutuhkan. Ada tiga jenis transaksi, yaitu :
•
Retrieval transactions, digunakan untuk mendapatkan
kembali data untuk ditampilkan di layar atau dalam
laporan.
•
Update transactions, digunakan untuk menambah data
baru, menghapus data lama, atau memodifikasi data yang
ada di dalam basis data.
•
Mixed Transactions, melibatkan retrieval (pemanggilan)
dan update (perubahan) data atau kombinasi antara
keduanya.
b) User Interface Design (Perancangan antarmuka)
Sebelum mengimplementasikan suatu form atau laporan, ada
perlunya merancang tampilan terlebih dahulu.
2.3.7
Prototyping
Merupakan pembuatan suatu model kerja dari aplikasi basis data
(Connolly dan Begg, 2005, p304). Suatu prototype adalah model yang bekerja
yang tidak mempunyai semua fitur-fitur yang diperlukan atau menyediakan
semua fungsionalitas dari sistem terakhir. Tujuan utama dari pengembangan
suatu aplikasi basis data prototype adalah memungkinkan pengguna
menggunakan prototype tersebut untuk menentukan fitur-fitur dari sistem yang
29
bekerja dengan baik, dan jika mungkin mengusulkan peningkatan atau bahkan
fitur-fitur baru pada aplikasi basis data.
Ada dua strategi prototyping yang umum digunakan, yaitu :
1) Requirement prototyping, menggunakan suatu prototype untuk
menentukan kebutuhan-kebutuhan dari aplikasi basis data yang
diusulkan dan ketika kebutuhan tersebut telah lengkap, prototype
tersebut disingkirkan.
2) Evolutionary prototyping, digunakan untuk tujuan yang sama,
perbedaan yang penting adalah bahwa prototype tidak dibuang
tetapi dengan perkembangan yang lebih jauh menjadi aplikasi
basis data yang digunakan.
2.3.8
Implementation (Implementasi)
Implementasi merupakan realisasi fisik dari rancangan basis data dan
rancangan aplikasi (Connolly dan Begg, 2005, p304). Implementasi basis data
dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS
yang dipilih, atau dengan menggunakan Graphical User Interface (GUI), yang
menyediakan fungsionalitas yang sama dengan saat menyembunyikan
pernyataan low-level DDL.
Kemudian bagian dari program aplikasi adalah transaksi basis data,
yang diimplementasikan dengan menggunakan Data Manipulation Language
(DML), yang biasanya sudah terdapat dalam bahasa pemrograman.
30
2.3.9
Data Conversion and Loading
Merupakan pemindahan data yang ada ke dalam basis data baru dan
mengubah aplikasi yang ada untuk beroperasi pada basis data yang baru.
Langkah ini diperlukan hanya ketika suatu sistem basis data baru menimpa
sistem yang lama.
2.3.10 Testing
Merupakan proses pengeksekusian program aplikasi dengan maksud
pencarian kesalahan-kesalahan. Sebelum ditunjukkan secara langsung, aplikasi
basis data yang baru dikembangkan seharusnya diuji sepenuhnya.
Beberapa keuntungan melakukan testing :
•
Menemukan error pada aplikasi dan mungkin juga error pada
struktur basis data.
•
Testing mendemonstrasikan apakah basis data dan aplikasi dapat
berjalan sesuai dengan kebutuhan performa dan spesifikasi yang
diinginkan atau tidak.
2.3.11 Operational Maintenance (Perawatan Operasional)
Merupakan proses pengawasan dan pertahanan sistem berikut instalasi.
Pada langkah sebelumnya, aplikasi basis data telah diimplementasikan dan diuji
sepenuhnya. Sekarang sistem memasuki langkah perawatan, yang melibatkan
aktivitas-aktivitas berikut :
31
a) Mengawasi kinerja sistem.
b) Mempertahankan dan meng-upgrade aplikasi basis data (ketika
dibutuhkan).
2.4
Entity Relationship (ER) Modelling
ER
Modelling
merupakan
suatu
pendekatan
top-down
dalam
perancangan basis data yang dimulai dengan mengidentifikasi data penting
yang disebut entitas (entities) dan relasi/hubungan (relationship) antara data
tersebut harus direpresentasikan dalam model (Connolly dan Begg, 2005, p342).
2.4.1
Entity Type
Entity type adalah sekumpulan objek yang memiliki properti yang sama,
yang didefinisikan oleh perusahaan sebagai keberadaan yang independen
(Connolly dan Begg, 2005, p343).
Setiap object yang unik dari sebuah entity type dapat disebut sebagai
sebuah entity occurrence (Connolly dan Begg, 2005, p345).
Entity type dapat diklasifikasikan sebagai strong (kuat) atau weak
(lemah) sebagai berikut :
a) Strong
entity
type
merupakan
suatu
entity
type
yang
keberadaannya tidak tergantung kepada entity type yang lain.
b) Weak
entity
type
merupakan
suatu
entity
type
keberadaannya tergantung kepada entity type yang lain.
yang
32
Nama Entity
Staff
Cabang
Gambar 2.2 Representasi diagram entity type Staff dan Cabang
2.4.2
Relationship Type
Relationship type adalah sekumpulan entity yang mempunyai hubungan
dan memiliki arti (Connolly dan Begg, 2005, p346).
Nama Relationship
Staff
Å Memiliki
Cabang
Gambar 2.3 Representasi diagram ‘Cabang memiliki Staff’
relationship type
33
2.4.2.1 Degree of Relationship Type
Degree of relationship type merupakan jumlah entity type yang ikut
serta dalam sebuah relationship (Connolly dan Begg, 2005, p347). Beberapa
degree of relationship type adalah :
a) Binary relationship merupakan hubungan yang terjadi di antara
dua entity type.
‘PrivateOwner memiliki PropertyForRent’
PrivateOwner
POwns Æ
PropertyForRent
Gambar 2.4 Contoh binary relationship
b) Ternary relationship merupakan hubungan yang terjada di antara
tiga entity type.
‘Staff meregistrasi seorang client pada
sebuah branch’
Staff
Register
Branch
Client
Gambar 2.5 Contoh ternary relationship
c) Quaternary relationship merupakan hubungan yang terjadi
antara empat entity type.
34
‘Seorang solicitor mengurus
sebuah bid mewakili seorang buyer
dan didukung oleh sebuah
financial instution’
Solicitor
Financial
Institution
Register
Buyer
Bid
Gambar 2.6 Contoh quaternary relationship
2.4.2.2 Recursive Relationship
Recursive relationship merupakan sebuah relationship type dimana
entity type yang sama ikut berpartisipasi lebih dari sekali dengan peran yang
berbeda (Connolly dan Begg, 2005, p349).
‘Staff [Supervisor] mengawasi
(supervises) staff lainnya
[Supervisee]’
Peran
Å Supervises
Supervisor
Peran
Supervisee
Staff
Gambar 2.7 Contoh recursive relationship
35
2.4.3
Attributes
Atribut adalah sebuah properti dari suatu entity type atau relationship
type (Connolly dan Begg, 2005, p350). Attribute domain adalah sekumpulan
nilai yang diperbolehkan untuk satu atau lebih attributes.
Atribut dapat diklasifikasikan sebagai :
a) Simple and Composite Attribute
Simple attribute adalah sebuah atribut yang tersusun dari sebuah
komponen dengan keberadaan yang independen. Simple
attribute tidak dapat dipecah lagi menjadi atribut yang lebih
kecil, biasanya disebut dengan atomic attribute.
Composite attribute adalah attribute yang tersusun dari banyak
komponen, dimana setiap komponennya memiliki keberadaan
yang independen. Composite attribute dapat dipecah lagi
menjadi komponen-komponen idependen yang lebih kecil.
b) Single-Valued and Multi-Valued Attributes
Single-valued attribute merupakan suatu atribut yang memiliki
sebuah nilai untuk setiap keberadaan sebuah entity type.
Multi-valued attribute merupakan suatu atribut yang memiliki
banyak nilai untuk setiap keberadaan sebuah entity type.
c) Derived Attributes
Derived
attribute
merupakan
suatu
atribut
yang
merepresentasikan suatu nilai yang bisa didapat dari nilai sebuah
36
atau kumpulan attribute yang berhubungan, tetapi tidak harus
dalam entity type yang sama.
2.4.4
Keys
Candidate key adalah himpunan atribut yang minimal yang secara unik
mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly dan
Begg, 2005, p352). Primary key adalah candidate key yang terpilih untuk
mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas
(Connolly dan Begg, 2005, p353). Composite key adalah sebuah candidate key
yang terdiri atas dua atau lebih atribut (Connolly dan Begg, 2005, p353). Pada
sebuah tipe entitas biasanya terdapat lebih dari satu candidate key yang salah
satunya harus dipilih untuk menjadi primary key. Pemilihan primary key
didasarkan pada panjang atribut, jumlah minimal atribut yang diperlukan, dan
keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih
menjadi primary key, atau biasa disebut dengan secondary key (Whitten, 2004,
p298). Foreign key adalah sebuah primary key
pada sebuah entitas yang
digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship
(Whitten, 2004, p301).
2.4.5
Structural Constraints
Multiplicity merupakan jumlah kemunculan yang mungkin dari sebuah
entity type yang mungkin berhubungan dengan kemunculan tunggal dari sebuah
37
entity type-entity type yang berhubungan melalui relasi tertentu (Connolly dan
Begg, 2005, p356).
Beberapa jenis relasi berdasarkan multiplicity yang dimiliki, yaitu :
1. Relasi one-to-one (1:1)
Hubungan yang terjadi diantara dua entitas yang saling terlibat
adalah satu-satu dan dapat pula member entitas yang satu ada
yang tidak berhubungan dengan member dari entitas yang
berelasi dengannya dan entitas tersebut juga berelasi maksimal
satu.
Gambar 2.8 Notasi relasi one-to-one
2. Relasi one-to-many (1:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat
adalah satu-banyak. Dimana sebuah member dari entitas dapat
berhubungan dengan satu atau banyak member dari entitas yang
lain dan member dari entitas yang lainnya berhubungan (bisa
dari 0) sampai maksimal satu.
Gambar 2.9 Notasi relasi one-to-many
38
3. Relasi many-to-many (*:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat
adalah banyak-banyak. Member dari sebuah entitas dapat
berelasi dengan entitas yang lain dengan maksimal multiplicity
banyak (*) dan sebaliknya dengan relasi entitas yang
berhubungan tersebut.
Gambar 2.10 Notasi relasi many-to-many
2.4.6
Crow’s Foot Data Model
Dari beberapa pilihan yang tesedia untuk menggambarkan cardinality,
notasi crow’s foot merupakan yang paling diminati. Crow’s foot menunjukkan
baik cardinality minimum dan maksimum dalam suatu format grafik yang jelas.
Simbol multiplicity-nya intuitif dan mudah dimengerti oleh pembaca non-teknis.
Notasi crow’s foot sebaiknya digunakan dalam seluruh diagram model data
konseptual yang akan ditinjau oleh pengguna bisnis. Notasi ini juga cocok
untuk digunakan dalam model desain basis data fisikal (Stewart, 2008).
Pada pengerjaan penulisan ini akan digunakan model data Crow’s Foot
pada Entity Relationship Diagram yang akan dibuat.
39
Gambar 2.11 Contoh Crow’s foot data model
Berikut merupakan representasi cardinality pada Crow’s Foot data
model :
Gambar 2.12 Cardinality pada Crow’s foot data model
2.5
Perancangan Basis Data
Menurut Connolly dan Begg (2005, p438), metodologi perancangan
basis data merupakan pendekatan terstruktur yang menggunakan bantuan
prosedur,
teknik,
alat-alat,
dan
dokumentasi
untuk
mendukung
dan
memfasilitasi proses perancangan basis data.
Metodologi perancangan basis data terbagi atas tiga tahap perancangan,
yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal.
Meskipun langkah-langkah dalam metodologi digambarkan secara proses yang
40
berurutan, perlu ditekankan bahwa tidak berarti metodologi tersebut harus
dibuat secara berurutan. Seringkali pengetahuan yang didapat pada suatu tahap
mempengaruhi keputusan yang telah diambil di tahap sebelumnya.
2.5.1
Perancangan Konseptual (Conceptual Design)
Conceptual database design adalah proses membangun model informasi
yang digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly dan
Begg, 2005, p439). Pertimbangan fisik yang dimaksud meliputi DBMS yang
akan digunakan, program aplikasi, bahasa pemrograman, platform perangkat
keras, performa, dan pertimbangan fisik lainnya.
Langkah-langkah dalam metodologi conceptual database design
adalah :
Langkah 1
Membangun Model Data Konseptual
Bertujuan untuk memecah rancangan menjadi tugas-tugas yang dapat
diatur dengan memeriksa sudut pandang yang berbeda dari pengguna di dalam
organisasi (Connolly dan Begg, 2005, p442). Hasil dari langkah ini berupa
pembuatan satu atau lebih local conceptual data model yang merupakan
penggambaran yang tepat dan lengkap dari suatu organisasi dilihat dari para
pengguna yang berbeda. Tugas-tugas yang dilakukan pada langkah ini terdiri
dari :
Langkah 1.1 Mengidentifikasi entity types
Entity type dapat dikenali dengan mengidentifikasikan kata
benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek
41
besar seperti orang, tempat, benda atau konsep. Alternatif lain adalah
dengan mencari objek yang keberadaannya bebas.
Langkah 1.2 Mengidentifikasi relationship type
Bertujuan untuk mengidentifikasi relationship yang penting
yang ada antara entity types yang telah diidentifikasi sebelumnya.
Relationship type diidentifikasikan dengan mencari kata kerja atau suatu
kata yang berhubungan dengan kata kerja.
Langkah 1.3 Mengidentifikasi
dan
menghubungkan
attributes
dengan entity atau relationship types
Tujuannya adalah untuk menghubungkan atribut dengan entity
dan relationship types yang tepat. Dalam tahap ini juga dilakukan
identifikasi composite attributes, single-valued/multi-valued attributes,
dan derived attributes.
Langkah 1.4 Menentukan attribute domains
Menentukan domain atribut dalam model data konseptual.
Domain adalah sekumpulan nilai-nilai dari satu atau lebih atribut yang
menggambarkan nilainya. Sebagai contoh nilai yang mungkin untuk
atribut jenis kelamin dari entitas karyawan adalah ‘L’ atau ‘W’.
42
Langkah 1.5 Menentukan candidate, primary, dan alternate key
attribute
Tujuannya untuk mengidentifikasi candidate key untuk tiap-tiap
tipe entitas dan jika ada lebih dari satu candidate key maka pilih satu
untuk menjadi primary key dan sisanya dapat dijadikan alternate key.
Langkah 1.6 Mempertimbangkan penggunaan enchance modelling
concepts (langkah opsional)
Langkah
ini
bertujuan
untuk
menentukan
penggunaan
specialization, generalization, aggregation, dan composition.
Specialization
merupakan
suatu
proses
memaksimalkan
perbedaan-perbedaan antara anggota-anggota sebuah entitas dengan
cara mengidentifikasi karakteristik yang membedakan entitas tersebut
(Connolly dan Begg, 2005, p374).
Generalization
merupakan
suatu
proses
meminimalkan
perbedaan-perbedaan antara entitas-entitas dengan cara mengidentifikasi
sifat umum pada entitas-entitas tersebut (Connolly dan Begg, 2005,
p374).
Aggregation menggambarkan relationship ‘has-a’ atau ‘is-partof’ antara tipe entitas dimana yang satunya mewakili ‘whole’ dan yang
satunya lagi mewakili ‘part’ (Connolly dan Begg, 2005, p383).
43
Composition digunakan untuk merepresentasikan penggabungan
antara tipe-tipe entitas yang memiliki kepemilikan yang kuat dan
hubungan yang penting antara ‘whole’ dan ’part’.
Langkah 1.7 Memeriksa model akan adanya redudansi
Bertujuan memeriksa conceptual model untuk menghindari
adanya redudansi atau pengulangan data dalam model. Ada dua
kegiatan yang dapat dilakukan pada tahap ini :
a) Memeriksa kembali one-to-one relationship (1:1)
Kemungkinan ada lebih dari satu entitas yang menggambarkan
objek yang sama dalam organisasi. Oleh karena itu, entitasentitas tersebut harus digabungkan.
b) Menghilangkan relasi yang redundan
Suatu relationship menjadi redundan jika informasi yang sama
dihasilkan
melalui
relationship
yang
lainnya.
Untuk
meminimalkan data model maka relationship yang redundan
harus dihilangkan.
c) Mempertimbangkan dimensi waktu
Dimensi waktu dalam relationships penting saat mengukur
adanya redudansi. Yang dimaksud disini adalah hubungan antar
entitas yang mungkin saja terjadi pada waktu yang berbeda.
44
Langkah 1.8 Memvalidasi
model
konseptual
terhadap
user
transactions
Memastikan model konseptual telah mendukung transaksitransaksi yang dibutuhkan. Tahap ini dapat dilakukan dengan dua cara,
yaitu :
a) Mendeskripsikan transaksi
Dengan pendekatan ini berarti akan diperiksa semua informasi
(entitas, relationship, dan atribut) yang dibutuhkan oleh setiap
transaksi apakah telah disediakan dalam model, dengan
mendokumentasikan setiap kebutuhan transaksi.
b) Menggunakan transaction pathways
Pendekatan ini untuk validasi model data terhadap transaksi
yang dibutuhkan termasuk representasi diagram jalur yang
digunakan oleh setiap transaksi langsung pada ER diagram.
Langkah 1.9 Review model data konseptual dengan user
Mengadakan review model data konseptual dengan pengguna
sistem
untuk
memastikan
model
data
tersebut
secara
tepat
menggambarkan transaksi dan kebutuhan data secara nyata dalam
perusahaan.
45
2.5.2
Perancangan Logikal (Logical Design)
Desain basis data logikal adalah proses membangun model informasi
yang digunakan organisasi berdasarkan model data tertentu, tetapi tidak
tergantung dari Database Management System (DBMS) dan pertimbangan fisik
lainnya (Connolly dan Begg, 2005, p439). Langkah-langkah dalam metodologi
logical database design yaitu :
Langkah 2
Membangun dan validasi logical data model
Tujuannya adalah untuk membangun sebuah logical data model dari
sebuah conceptual data model yang mewakili pandangan tertentu dari
organisasi dan kemudian memvalidasi model ini untuk memastikan bahwa
strukturnya benar (dengan menggunakan teknik normalisasi) dan untuk
memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan.
Kegiatan yang dilakukan pada langkah ini meliputi :
Langkah 2.1 Membentuk relasi untuk logical data model
Bertujuan untuk menyaring conceptual data model sehingga
fitur-fitur yang tidak sesuai dengan model relasional dihilangkan.
Langkah tersebut antara lain dilakukan terhadap :
1) Strong entity types
Untuk semua entitas dengan jenis kuat, buatlah sebuah
relationship yang memiliki semua atribut sederhana yang
dimilikinya. Untuk composite attribute, hanya sertakan
atribut pokoknya saja.
46
2) Weak entity types
Untuk setiap entitas dengan jenis lemah, buatlah sebuah
relationship yang memiliki semua atribut sederhana yang
dimilikinya. Primary key dari entitas ini belum dapat
ditentukan sampai relationship-nya dengan entitas kuat
ditentukan.
3) One-to-many (1:*) binary relationship types
Pada relationship jenis ini, entitas pada ‘one side’ kita
anggap sebagai entitas induk sedangkan entitas pada ‘many
side’
dianggap
sebagai
entitas
anak.
Untuk
merepresentasikan hubungan ini, kita kirimkan primary key
dari entitas induk sebagai foreign key pada entitas anak. 4) One-to-one (1:1) binary relationship types
Relasi 1:1 lebih sulit ditentukan hubungannya karena
cardinality
dan
participation
constraints
juga
akan
menentukan dalam mengidentifikasi entitas induk dan anak
dalam relationship ini.
i.
Mandatory participation pada kedua sisi
Pada kasus ini, kita harus menggabungkan kedua
entitas yang memiliki relationship jenis ini dan
memilih salah satu dari kedua primary key sebagai
primary key yang baru.
47
ii.
Mandatory participation pada satu sisi
Pada kasus ini, kita bisa mengidentifikasikan entitas
yang berada pada sisi optional participation sebagai
entitas induk, sedangkan yang berada pada sisi
mandatory participation sebagai entitas anak. Seperti
pada langkah sebelumnya, kita kirimkan primary key
dari entitas induk sebagai foreign key pada entitas
anak.
iii.
Optional participation pada kedua sisi
Pada kasus ini, pemilihan induk dan anak bisa
berubah-ubah. Untuk bisa menentukan, maka kita
harus mencari sisi optional participation mana yang
lebih mendekati sebagai mandatory participation.
Pemecahan untuk relasi ini sangat tergantung dengan
kondisi data yang ada.
5) One-to-one (1:1) recursive relationship
Untuk pemecahan hubungan ini, dapat digunakan cara yang
sama dengan yang telah diterapkan pada 1:1 relationship.
6) Superclass/subclass relationship
Untuk setiap superclass/subclass relationship dalam data
model
konseptual,
kita
mengidentifikasikan
entitas
superclass sebagai entitas parent dan entitas subclass
sebagai entitas child. Terdapat banyak pilihan dalam
48
merepresentasikan relationship sebagai salah satu atau lebih
relationships. Pilihan yang paling sesuai tergantung dari
sejumlah faktor seperti disjointness dan participation
constraint pada superclass/subclass relationship apakah
subclass terlihat dalam distinct relatonship dan jumlah
participant dalam superclass/subclass relationship.
7) Many-to-many (*:*) binary relationship types
Dengan memecah relationship yang mengandung many-tomany (*:*) untuk mengidentifikasikan sebuah entitas tengah
(intermediate entity) sehingga relationship ini digantikan
dengan dua buah one-to-many (1:*) relationship, dengan
entitas tengah berada di antara dua buah entitas yang lama.
8) Complex relationship types
Complex relationship types dihilangkan dengan memecah
relationship tersebut untuk mengidentifikasikan entitas
tengah (intermediate entity). Kemudian complex relationship
ini akan digantikan dengan beberapa one-to-many (1:*)
binary relationship.
9) Multi-valued attributes
Multi-valued attributes dapat dihilangkan dengan memecah
atribut tersebut untuk mengidentifikasikan sebuah entitas.
Setelah itu, kirimkan primary key pada entitas induk sebagai
foreign key pada entitas anak.
49
Langkah 2.2 Validasi relasi dengan meggunakan normalisasi
Normalisasi merupakan suatu teknik untuk menghasilkan
sekumpulan relasi dengan properti yang diinginkan, sesuai dengan
kebutuhan data dari suatu perusahaan (Connolly dan Begg, 2005, p388).
Tujuan dari normalisasi adalah untuk meminimalkan redudansi
data dan update anomalies, menciptakan representasi data, hubungan
antar data dan constraint yang akurat, serta meningkatkan stabilitas.
Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi
dengan benar atas relasi yang ada. Pada dasarnya, proses normalisasi
dilakukan untuk meminimalkan redudansi data dan update anomalies.
Menurut Connolly dan Begg (2005, p391), update anomalies
dapat dibagi menjadi tiga jenis yaitu :
a) Insert anomaly merupakan kejanggalan yang terjadi terhadap
sebuah table pada saat dilakukan penambahan suatu record,
yaitu berupa pelanggaran terhadap integrity constraint.
b) Delete anomaly merupakan kejanggalan yang terjadi terhadap
suatu tabel pada saat dilakukan penghapusan suatu record,
penghapusan bermaksud untuk menghapus suatu data tertentu
tetapi menyebabkan kehilangan data lain dari tabel tersebut.
c) Modification anomaly merupakan kejanggalan yang terjadi
terhadap suatu tabel pada saat dilakukan pengubahan suatu
record, pengubahan terhadap suatu nilai tertentu harus dilakukan
lebih dari sekali.
50
Tiga tingkatan normalisasi yang dijadikan acuan penulisan
skripsi ini yaitu :
1) First Normal Form (1NF)
Suatu relasi dikatakan 1NF jika titik temu tiap baris dan
kolom pada relasi tersebut mengandung satu dan hanya satu
nilai (Connolly dan Begg, 2005, p403).
2) Second Normal Form (2NF)
Relasi dikatakan 2NF jika relasi tersebut berada pada 1NF
dan setiap atribut yang bukan primary key bergantung penuh
(fully
functionally
dependent)
terhadap
primary
key
(Connolly dan Begg, 2005, p407). Functional dependency
terjadi jika A dan B adalah atribut dari sebuah relasi , B
dikatakan functionally dependent terhadap A (A Æ B), jika
setiap nilai dari A diasosiasikan dengan tepat satu nilai dari
B. Full functional dependency terjadi jika A dan B
merupakan atribut dari suatu relasi, B dikatakan full
functional dependent terhadap A jika B functionally
dependent terhadap A, tetapi bukan merupakan subset dari A.
3) Third normal form (3NF)
Relasi dikatakan 3NF jika relasi tersebut dalam bentuk 1NF
dan 2NF, dan tidak ada atribut bukan primary key
bergantung secara transitif (transitively dependent) terhadap
primary key (Connolly dan Begg, 2005, p409). Transitive
51
dependency merupakan sebuah kondisi dimana A, B, dan C
merupakan atribut dari relasi yang jika AÆB dan BÆC
maka C disebut bergantung secara transitif terhadap A
melalui B (Connolly dan Begg, 2005, p397).
Langkah 2.3 Validasi relasi terhadap user transactions
Memastikan relasi dalam model data logikal telah mendukung
transaksi yang diperlukan. Pada tahap ini, akan dilakukan pengecekan
terhadap relasi yang sudah terbentuk sebelumnya, apakah sudah dapat
memproses transaksi tersebut dan pastikan tidak ada kesalahan pada saat
membuat relasi.
Langkah 2.4 Menentukan integrity constraint
Integrity
constraint
adalah
batasan-batasan
yang
harus
ditentukan untuk melindungi basis data agar tetap konsisten (Connolly
dan Begg, 2005, p474). Berikut merupakan tipe dari integrity
constraints :
a) Required data ( Data yang diperlukan )
Beberapa atribut harus selalu berisi nilai yang benar, tidak
dapat bernilai null.
b) Attribute domain constraint
Setiap atribut memiliki domain, yaitu himpunan nilai yang
dibolehkan (Connolly dan Begg, 2005, p475).
52
c) Multiplicity
Multiplicity merepresentasikan batasan jumlah yang ada
antara data yang ada di basis data.
d) Entity integrity
Primary key dari sebuah entitas tidak boleh bernilai null.
e) Referential integrity
Jika sebuah foreign key memiliki nilai, maka nilai tersebut
harus menunjuk ke sebuah baris yang ada pada relasi
‘parent’.
f) General constraint
Kegiatan update entitas dibatasi oleh peraturan atau
kebijakan
organisasi
yang
mengatur
transaksi
yang
diwakilkan oleh update yang dilakukan.
Langkah 2.5 Meninjau kembali local logical data model dengan
user
Memastikan bahwa logical data model dan dokumentasi
pendukung yang menggambarkan model merupakan perwakilan yang
benar dari pandangan pengguna.
53
Langkah 2.6 Menggabungkan logical data model menjadi global
model (langkah opsional)
Menggabungkan local logical data models menjadi satu global
logical data model yang merepresentasikan seluruh user views dari
basis data. Langkah ini hanya perlu dilakukan apabila saat desain
dilakukan dengan user views yang terpisah berdasarkan masing-masing
user.
Langkah 2.7 Memeriksa untuk perkembangan mendatang
Bertujuan untuk menentukan apakah akan ada perubahan yang
signifikan pada masa mendatang dan memperkirakan apakah logical
data model yang sekarang dapat mengakomodasi perubahan tersebut.
2.5.3
Perancangan Fisikal (Physical Design)
Perancangan basis data fisikal merupakan proses memproduksi sebuah
deskripsi dari implementasi basis data dalam secondary storage, yang
menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk
mendapatkan akses data yang efisien, serta setiap integrity constraint yang
saling berhubungan dan juga pengukuran keamanan (Connolly dan Begg, 2005,
p294).
54
Langkah 3
Menterjemahkan Logical Data Model untuk DBMS Sasaran
Langkah ini bertujuan untuk menghasilkan skema basis data relasional
bagi global logical data model yang dapat diimplementasikan pada DBMS
sasaran.
Langkah 3.1 Membuat base relations
Memutuskan bagaimana merepresentasikan relasi-relasi yang
telah diidentifikasikan pada logical data model pada DBMS yang akan
dipakai.
Langkah 3.2 Merancang representasi dari data yang diperoleh
Memutuskan bagaimana merepresentasikan derived data yang
ada dalam logical data model pada DBMS yang akan dipakai.
Langkah 3.3 Merancang general constraints
Merancang
batasan-batasan umum untuk DBMS yang akan
digunakan.
Langkah 4
Merancang file organizations dan indexes
Menentukan organisasi file optimal untuk menyimpan relasi dasar dan
indeks yang diperlukan untuk mencapai performa yang dapat diterima, yaitu
cara dimana relasi dan entitas akan dilaksanakan di secondary storage.
55
Langkah 4.1 Analisis transaksi
Memahami fungsi-fungsi dari transaksi yang akan dijalankan
pada basis data dan menganalisis transaksi yang penting. Dalam
menganalisis transaksi, kita mencoba mengidentifikasikan kriteria
performa, seperti :
•
Transaksi yang akan berjalan secara terus-menerus dan
yang akan mempengaruhi secara signifikan pada
performa.
•
Transaksi yang penting bagi operasi bisnis.
•
Waktu selama sehari/seminggu ketika akan terjadi
permintaan yang tinggi dibuat dalam basis data (disebut
peak load).
Langkah 4.2 Memilih file organizations
Tujuan langkah ini adalah menetukan organisasi file yang efisien
untuk tiap-tiap relasi dasar jika diperbolehkan oleh DBMS yang akan
digunakan. Beberapa tipe organisasi file adalah :
•
Heap
•
Hash
•
ISAM
•
B+-Tree
•
Cluster
56
Langkah 4.3 Memilih index
Memutuskan
apakah
dengan
menambahkan
index
akan
meningkatkan performa dari sistem.
Langkah 4.4 Memperkirakan disk space yang diperlukan
Memperkirakan jumlah disk space yang diperlukan basis data.
Estimasi pemakaian disk tergantung pada DBMS dan perangkat keras
yang digunakan untuk mendukung basis data.
Langkah 5
Merancang user views
Merancang
view
pengguna
yang
telah
diidentifikasi
selama
pengumpulan persyaratan dan tahap analisis dari database system development
lifecycle.
Langkah 6
Merancang mekanisme keamanan
Merancang mekanisme keamanan untuk basis data yang ditentukan user
selama tahap requirements dan collections pada database systems development
lifecycle.
Langkah 7
Mempertimbangkan pengenalan redudansi terkontrol
Menentukan apakah dengan adanya redudansi yang terkontrol dengan
melonggarkan aturan normalisasi akan meningkatkan kinerja sistem. Misalnya,
57
mempertimbangkan duplikasi atribut atau join relasi bersama. Dokumentasi
adanya redudansi.
Langkah 8
Mengawasi dan melakukan setting terhadap sistem operasi
Mengawasi sistem operasi dan meningkatkan kinerja sistem dalam
membenarkan keputusan perancangan yang kurang tepat atau dalam mengatasi
kemungkinan adanya perubahan.
2.6
Document Flowchart
Document flowchart digunakan untuk merepresentasikan elemenelemen dari dari suatu sistem manual dalam gambar, contohnya meliputi :
catatan akutansi, departemen yang terlibat dalam proses, dan aktivitas yang
dilakukan pada departemen tersebut (Hall, 2008, p61).
Document flowchart adalah bagan yang menggambarkan aliran
dokumen dalam suatu sistem informasi. Berikut ini adalah simbol-simbol
standar dengan maknanya masing-masing untuk melukiskan document
flowchart suatu sistem (Mulyadi, 2001, p64) :
58
Table 2.1 Simbol document flowcchart
Simbo
ol
N
Nama
Pen
njelasan
Dookumen
Simbol ini digunakan
d
u
untuk
mengggambarkan seemua
jenis dokuumen, yang merupakann formulir yang
digunakan untuk mereekam data terjadinya suatu
transaksi. Nama
N
dokum
men dicantuumkan di teengah
simbol
Dokkumen dan
Simbol inni digunakaan untuk menggambaarkan
tembbusannya
dokumen asli
a
dan tem
mbusannya. Nomor lembar
dokumen diicantumkan di sudut kannan atas.
Berbagai
Simbol inni digunakaan untuk menggambaarkan
dookumen
berbagai jennis dokumenn yang digabbungkan berrsama
di dalam saatu paket. Nama
N
dokum
men dituliskaan di
dalam massing-masing simbol dann nomor lembar
dokumen dicantumkan
d
di sudut kaanan atas simbol
dokumen yaang bersangkutan
Pennghubung
Simbol pennghubung untuk
u
memuungkinkan aliran
a
padaa halaman
dokumen berhenti
b
di suatu lokassi pada halaaman
yanng sama
tertentu dann kembali berjalan
b
di lokasi lain pada
(oon-page
connnector)
halaman yaang sama.
59
Akhir arus
Akhir arus dokumen dan mengarahkan pembaca ke
dokumen
simbol penghubung halaman yang sama yang
bernomor seperti yang tercantum di dalam simbol
tersebut.
Awal arus
Awal arus dokumen yang berasal dari simbol
dokumen
penghubung halaman yang sama, yang bernomor
seperti yang tercantum di dalam simbol tersebut.
Penghubung
Jika untuk menggambarkan bagan alir suatu sistem
pada halaman
diperlukan lebih dari satu halaman, simbol ini harus
yang berbeda
digunakan
(off-page
connector)
untuk
menunjukkan
kemana
dan
bagaimana bagan alir terkait satu dengan lainnya.
Nomor
yang
tercantum
di
dalam
simbol
penghubung menunjukkan bagaimana bagan alir
yang tercantum pada halaman tertentu terkait
dengan bagan alir yang tercantum pada halaman
yang lain.
Kegiatan
Simbol ini digunakan untuk menggambarkan
manual
kegiatan manual, seperti: menerima order dari
pembeli,
mengisi
formulir,
membandingkan,
memeriksa dan berbagai jenis kegiatan klerikal
yang
lain.
Uraian
singkat
dicantumkan di dalam simbol ini.
kegiatan
manual
60
Arsip
Simbol ini digunakan untuk menunjukkan tempat
sementara
penyimpanan dokumen, seperti almari arsip dan
kotak arsip. Terdapat dua tipe arsip dokumen: arsip
sementara dan arsip permanen. Arsip sementara
adalah
tempat
penyimpanan
dokumen
yang
dokumennya akan diambil kembali dari arsip
tersebut di masa yang akan datang untuk keperluan
pengolahan lebih lanjut terhadap dokumen tersebut.
Untuk menunjukkan urutan pengarsipan dokumen
digunakan simbol berikut ini:
A = menurut abjad
N = menurut nomor urut
T = kronologis, menurut tanggal
Arsip
Simbol ini digunakan untuk menggambarkan arsip
permanen
permanen yang merupakan tempat penyimpanan
dokumen yang tidak akan diproses lagi dalam
sistem yang bersangkutan.
Keputusan
Simbol ini menggambarkan keputusan yang harus
dibuat dalam proses pengolahan data. Keputusan
yang dibuat ditulis di dalam simbol.
Garis alir
Simbol ini menggambarkan arah proses pengolahan
(flowline)
data. Anak panah tidak digambarkan jika arus
dokumen mengarah ke bawah dan ke kanan. Jika
61
arus dokumen mengalir ke atas atau ke kiri, anak
panah perlu dicantumkan.
Mulai/berakhir Simbol ini untuk menggambarkan awal dan akhir
(terminal)
2.7
suatu sistem.
Data Flow Diagram (DFD)
Menurut Whitten (2004, p344), Data Flow Diagram adalah sebuah alat
pemodelan yang digunakan untuk menggambarkan aliran data pada suatu
sistem dan pekerjaan atau proses yang dilakukan oleh sistem. Sinonim dari data
flow diagram adalah bubble chart, transformation graph, dan process model.
Decomposition diagram, juga dikenal dengan hierarchy chart, adalah
alat
yang
digunakan
untuk
menggambarkan
dekomposisi
sistem.
Decomposition diagram pada dasarnya adalah alat perencanaan untuk model
proses yang lebih detail, yang disebut diagram aliran data. Context diagram
adalah model proses yang menggambarkan hubungan dari sistem ke dunia
bisnis dan dunia luar, termasuk sistem informasi yang lainnya.
Notasi simbol pada data flow diagram pada umumnya terbagi menjadi
dua notasi, yaitu : Yourdon/DeMarco DFD dan Gane&Sarson DFD. Berikut
merupakan simbol-simbol yang terdapat pada Data Flow Diagram :
a. Proses
Proses adalah proses atau pekerjaan yang dilakukan oleh sistem
sebagai respon terhadap aliran data masuk atau kondisi. Proses
menggambarkan bagian dari sistem yang mengolah masukan
62
menjadi keluaran. Proses digambarkan dengan sebuah lingkaran
pada
notasi
Yourdon/DeMarco
DFD,
sedangkan
proses
digambarkan dengan sebuah sistem persegi panjang bersudut
tumpul pada notasi Gane&Sarson DFD.
Gambar 2.13 Simbol proses
b. Aliran data
Aliran menggambarkan perpindahan informasi (input dan
output), ke dan dari proses tersebut. Aliran digambarkan dengan
sebuah tanda panah. Awal panah menggambarkan asal data
sedangkan arah panah menggambarkan tujuan.
Gambar 2.14 Simbol aliran data
c. Penyimpanan data (Data store)
Data store adalah penyimpanan data yang ditujukan untuk
penggunaan selanjutnya. Sinonimnya adalah file dan database.
Data store digambarkan dengan sebuah kotak dengan ujung
terbuka.
Gambar 2.15 Simbol penyimpanan data
63
d. Agen eksternal
Agen eksternal adalah orang, unit organisasi, atau organisasi luar
yang berinteraksi dengan sistem. Disebut juga entitas eksternal.
Agen eksternal digambarkan dengan sebuah persegi empat.
Gambar 2.16 Simbol agen eksternal
2.8
State Transition Diagram (STD)
State transition diagram (STD) adalah suatu alat yang digunakan untuk
menggambarkan urutan dan variasi dari layar yang dapat terjadi selama suatu
sesi pengguna (Whitten, 2004, p673). Notasi yang digunakan dalam STD
adalah :
•
Kotak digunakan untuk menggambarkan layar tampilan.
•
Anak panah menggambarkan aliran dari kontrol dan kejadian
yang memicu layar menjadi aktif atau menerima focus.
Suatu STD dapat menjadi cukup besar, terutama ketika semua input,
output, help, dan layar-layar lainnya dimasukkan ke dalam diagram. Maka dari
itu, umumnya diagram dipisah menjadi beberapa diagram yang lebih sederhana
dan lebih mudah dibaca (Whitten, 2004, p674).
64
2.9
Teori Khusus
2.9.1
Defisini Penjualan
Menurut Mulyadi (2001, p204), kegiatan penjualan terdiri dari
penjualan barang atau jasa baik secara kredit maupun tunai. Penjualan menurut
cara bayarnya dapat dibedakan sebagai berikut :
1) Penjualan tunai adalah penjualan yang dilaksanakan oleh perusahaan
dengan cara mewajibkan pembeli dengan melakukan pembayaran
harga barang terlebih dahulu sebelum barang diserahkan kepada
pembeli.
2) Penjualan kredit adalah penjualan yang dilakukan dengan cara
memenuhi pesanan dari pelanggan dengan mengirimkan barang atau
menyerahkan jasa dan untuk jangka waktu tertentu perusahaan
memiliki piutang kepada pelanggannya.
2.9.2
Defisini Pembelian
Menurut Mulyadi (2001, p299), sistem pembelian digunakan dalam
perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan.
Transaksi pembelian digolongkan menjadi dua yaitu pembelian lokal dan impor.
Pembelian lokal adalah pembelian dari pemasok dalam negeri sedangkan
pembelian impor adalah pembelian dari pemasok luar negeri.
65
2.9.3
Definisi Persediaan
Menurut Mulyadi (2001, p553), sistem persediaan bertujuan untuk
mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini
berkaitan erat dengan sistem pembelian, sistem retur pembelian, dan sistem
akutansi biaya produksi. Dalam perusahaan manufaktur, persediaan terdiri dari :
persediaan produk jadi, persediaan produk dalam proses, persediaan barang,
persediaan bahan penolong, persediaan bahan habis pakai pabrik, dan
persediaan suku cadang.