|
BAB 2
LANDASAN TEORI
2.1 Teori – teori Dasar/Umum
2.1.1 Sistem
Konsep sistem mendasari seluruh proses bisnis serta pemahaman atas informasi
dan teknologi. Konsep sistem akan membantu unutk menjelaskan konsep lainnya atas
penggunaan teknologi, aplikasi, pengembangan, dan pengolahan.
Menurut Marakas (2008,p24) Sistem didefinisikan sebagai suatu set komponen
yang saling terkait dengan batasan yang jelasdan bekerja sama untuk mencapai tujuan
dengan menerima input
dan memproduksi output
dalam proses transformasi
yang
terorganisir. Menurut Sutarman (2009,p5) Sistem adalah kumpulan elemen yang saling
berhubungan dan berinteraksi dalam suatu kesatuan untuk menjalankan suatu proses
pencapaian suatu tujuan utama. Hal ini di pertegas oleh Eti Rochaety (2006,p2) yang
menjelaskan Sistem adalah setiap kesatuan secara konseptual atau fisik yang terdiri dari
bagian-bagian yang saling mempengaruhi. Jadi dapat disimpulkan sistem itu adalah
sekelompok elemen yang saling berhubungan dan membentuk kesatuan atau bisa juga
orang, mesin, dan metode yang dibutuhkan untuk menyelesaikan serangkaian fungsi.
2.1.2 Informasi
Informasi dan data saling berkaitan erat, dan dalam keseharian digunakan secara
bergantian. Informasi digunakan dibanyak perusahaan yang berfungsi sebagai sumber
pengetahuan bagi perusahaan dalam mengambil keputusan bisnis.
Menurut Laudon(2007,p381) informasi didefinisikan sebagai data yang diolah
menjadi bentuk yang dapat dimengerti dan berguna bagi manusia. Hal ini di pertegas
oleh Marakas (2008,p579) yang menyebutkan informasi didefinisikan sebagai data yang
ditempatkan dalam konteks yang bermaknadan berguna untuk pengguna akhir. Jadi
dapat disimpulkan informasi itu adalah hasil akhir dari sebuah proses pengolahan data
yang dapat digunakan pengetahuan yang dapat dimanfaatkan perusahaan dan banyak
orang.
2.1.3 Data
Sejarahnya data disebut sebagai fakta-fakta tentang objek dan peristiwa yang
dapat direkam dan disimpan paa media komputer.
|
|
Menurut Indrajani (2008,p48) data merupakan fakta mentah tentang orang,
tempat, kejadian, dan apapun yang penting bagi perusahaan yang harus dikontrol dan
dikelola untuk menghasilkan suatu informasi yang memiliki arti bagi perusahaan.
Menurut Laudon (2007,p375) data merupakan kumpulan fakta-fakta kasar yang
menunjukan kejadian yang terjadi dalam organisasi atau lingkungan fisik sebelum fakta
tersebut diolah dan ditata menjadi bentuk yang dipahami. Hal ini di pertegas oleh
Harlinda (2008,p372) yang menyebutkan data merupakan representasi fakta dunia yang
mewakili suatu objek seperti manusia, barang, peristiwa, konsep dan sebagainya yang
direkam dalam gambar ataupun kombinasinya. Jadi dapat disimpulkan data itu adalah,
kumpulan dari objek dan peristiwa yang akan dikontrol dan dikelola yang disimpan
untuk kemudian menjadi sebuah informasi.
2.1.4 Basis Data
Dalam dua dekade terakhir ini Basis Data banyak digunakan dan semakin
berkembang. Basis Data apat digunakan sebagai menyimpan, memanipulasi, dan
menerima data dari semua tipe bisnis seperti misalnya : perusahaan, bidan kesehatan,
pemerintahan, dan perpustakan.
Menurut O’Brien (2005,p696) Basis Data adalah kumpulan terpadu dari elemen
data logis yang saling berhubungan. Basis data mengonsolidasi banyak catatan yang
sebelumnya disimpan dalam file terpisah. Dipertegas oleh Fadil, Firdausy, & Hermawan
(2008,p70) Basis Data adalah sekumpulan file-file yang saling berelasi.Cahyono
(2009,p83) juga menegaskan bahwa Basis Data adalah satu komponen sistem informasi
yang mempunyai posisi yang sangat menentukan dalam menunjang keberhasilan suatu
sistem informasi. Jadi dapat disimpulkan Basis Data itu adalah koleksi dari data terkait
yang formatnya standart dan dirancang untuk bisa diakses beberapa pengguna.
2.1.5 Database Administrator
Dalam pengolahan Basis Data, tentu dibutuhkan tenaga kerja yang mempunyai
keterampilan dalam mengolah data-data tersebut.Itulah yang disebut dengan Database
Administrator.
Menurut Harlinda (2008,p377) Database Administrator
dapat disimpulkan sebagai
orang yang mempunyai kekuasaan sebagai pusat pengontrol terhadap seluruh
sistem
baik data maupun program. Kroenke (2006,p648) juga menjelaskan bahwa Database
Administrator
didefinisikan sebagai orang atau sekelompok yang merespon peraturan
dan prosedur untuk mengontrol dan melindungi basis data. Bertugas juga untuk
|
 mengolah data, melakukan perawatan terhadap Database. Jadi dapat disimpulkan
database administrator itu adalah seorang pakar yang bertanggung jawab untuk
memelihara standart untuk pengembangan, pemeliharaan, dan keamanan database
organisasi.
2.1.6 Database Management System
Menurut Connolly dan Begg (2010,p66), Database Management System
adalah
sistem software yang memungkinkan user
untuk, menjelaskan, membuat, memaintain,
dan mengontrol akses ke database.
DBMS menyediakan fasilitas seperti :
a. Memungkinkan para pengguna untuk mendefinisikan database, dengan Data
Definition Language
(DDL). DDL
memperbolehkan para penggunanya dalam
menentukan struktur jenis data, dan batasan data yang akan disimpan pada database.
b. Memungkinkan pengguna dapat memasukan, memperbaharui, menghapus, dan
memulihkan data dari database melalui DataManipulation Languange (DML).
c.
Menyediakan akses kendali dalam database seperti :
a.
Security System : sistem yang digunakan untuk mencegah orang
yang tidak memiliki hak akses data untuk mengakses data tersebut.
b.
Integrity System : sistem yang memelihara konsistennya suatu data.
c.
Concurrency Control System : sistem yang membagi akses kedalam
database.
d. Recovery Control : penyimpan database cadangan untuk
mengembalikan keadaan semula jika terjadi kerusakan.
e.
User-Accessible Catalog : isi deskripsi data yang ada dalam
database.
Menurut Hartmann dan Link (2012) dalam jurnalnya mengatakan
Database Management System dapat digunakan untuk mengelola koleksi
informasi secara bersamaan, dapat diandalkan, efektif, efisiensi.
2.1.7 Komponen DBMS
|
|
Gambar 2.1 Komponen DBMS.
(Connolly dan Begg (2010,p68 )
DBMS memiliki lima komponen penting yaitu :
1.
Hardware
Hardware dapat berupa PC, mainframe tunggal, dan jaringan antar komputer.
2.
Software
Komponen software
terdiri dari software DBMS
sendiri dan program aplikasi,
bersama dengan sistem operasi pada komputer dan perangkat jaringan jika
sebuah DBMS diakses melalui sebuah jaringan.
3.
Data
Komponen yang paling utama dalam sebuah DBMS
adalah data. Tanpa adanya
data, DBMS tidak akan dapat digunakan atau dimanfaatkan.
4.
Procedure
Merupakan sebuah instruksi yang mengatur desain dan pengunaan database.
Pengguna sistem yang mengelola
database membutuhkan prosedur yang
terdokumentasi tentang bagaimana cara menggunakan atau menjalankan sistem
tersebut. Seperti instruksi untuk :
a.
Masuk ke dalam DBMS.
b.
Menggunakan fasilitas DBMS.
c.
Memulai dan memastikan DBMS.
d.
Membuat data cadangan dari database.
e.
Menangani kegagalan hardware atau software.
f.
Mengubah struktur table data.
5.
User
Komponen akhir yang tentunya dibutuhkan adalah pengguna dari sistem yang
dibuat.Pengguna sistem yang menjadi komponen penggerak dari DBMS
yang
sudah disediakan.
2.1.7.1 Keuntungan penggunaan DBMS
Keuntungan DBMS adalah sebagai berikut :
1.
Kontrol atas redudansi.
2.
Konsistensi data.
3.
Informasi yang diperoleh dari data yang sama lebih banyak.
|
|
4.
Data dapat dibagikan.
5.
Meningkatkan integasi data.
6.
Meningkatkan keamanan data.
7.
Meningkatkan aksesbilitas dan respon data
8.
Meningkatkan produktivitas
9.
Meningkatkan layanan backup dan recovery
2.1.7.2 Kerugian DBMS
Kerugian DBMS adalah sebagai berikut :
1.
Kompleksitas
2.
Ukuran
3.
Biaya dari penggunaan DBMS
4.
Biaya konversi
5.
Kinerja
6.
Dampak yang tinggi dari kegagalan
2.1.7.3 Fungsi DBMS
DBMS sendiri juga memiliki fungsi – fungsi sebagai berikut :
a)
Data Storage, retrieval, dan update
Sebuah DBMS harus menyediakan kemampuan untuk menyimpan, penelusuran
kembali, dan mengubah data dalam basis data bagi pengguna.
b)
A user-accessible catalog
DBMS harus menyediakan katalog yang menjelaskan
lokasi penyimpanan data
dalam basis data.
c)
Transaction support
DBMS juga harus menyediakan mekanisme kegiatan update yang berhubungan
dengan transaksi.
d)
Concurrency control service
DBMS juga menyediakan mekanisme agar basis data diperbaharui dengan
benar ketika beberapa pengguna melakukan update basis data secara bersamaan.
e)
Recovery service
Menyediakan mekanisme untuk perbaikan basis data yang rusak jika terjadi
sebuah kesalahan atau hal yang tak terduga
f)
Authorization service
|
|
Menyediakan mekanisme yang menjamin hanya pengguna yang diberi
otoritas tertentu saja yang dapat mengakses basis data yang penting.
g)
Support for data communication
DBMS harus dapat terintegrasi dengan software
yang berhubungan dengan
komunikasi data.
h)
Integrity service
Menyediakan jaminan bahwa data dalam basis data, keduanya telah mengikuti
aturan yang benar.
i)
Service to promote data independence
DBMS meliputi fasilitas–fasilitas yang mendukung program independensi dari
struktur basis data yang aktual.
j)
Utility service
DBMS menyediakan utility service agar basis data dapat di administrasi dengan
baik.
2.1.8 Database Definition Language (DDL)
Menurut Connolly dan Begg (2010,p92), database definition language
merupakan bahasa yang memungkinkan DBA
atau user
untuk mendeskripsikan dan
memberi nama dari entitas, attribute dan relationships
yang diperlukan untuk aplikasi,
bersamaan dengan beberapa associated integrity dan securityconstraints.
2.1.9
Database Manipulation Language (DML)
Menurut Connolly dan Begg (2010,p92), database manipulation language
merupakan bahasa yang menyediakan satu set operasi untuk mendukung basic
data
manipulation operasi dalam data yang diadakan di database.
2.1.10 Database Planning
Menurut Connolly & Begg (2005,p299-p2301), perancangan aplikasi
(application design) adalah merancang antarmuka pemakai (user interface) dan
program aplikasi yang akan memproses basisdata. Ditinjau dari gambar 2.1 bahwa,
perancangan basisdata dan perancangan aplikasi adalah aktivitas bersamaan pada
database application lifecycle. Dalam kasus sebenemya, adalah tidak mungkin untuk
menyelesaikan perancangan aplikasi sebelum perancangan basisdata selesai.
|
|
Dalam perancangan aplikasi harus memastikan semua pertanyaan fungsional
dari spesifikasi kebutuhan pemakai (user requirement specification) yang menyangkut
perancangan aplikasi program yang mengakses basisdata dan merancang transaksi yaitu
cara akses ke basisdata dan perubahan terhadap isi basisdata (retireve, update dan
kegiatan keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan
merancang antarmuka pemakai (user interface) yang tepat. Antarmuka yang
dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan
'user-friendly'. Kebanyakan antarmuka pemakai yang diabaikan akan niscaya
membuat masalah. Bagaimanapun, antarmuka pemakai harus diakui sebagai komponen
dari sistem yang penting, dimana agar mudah dipelajari dan mudah digunakan,
sehingga pemakai akan cenderung memberdayagunakan informasi yang disajikan.
2.1.11 System Definition.
Spesifikasi dari lingkup dan batas dari database system, termasuk major user
view, user, dan area aplikasi. User view
mendefinisikan apa yang dibutuhkan dalam
aplikasi basis data yang berhubungan dengan data dan
menampilkan transaksi dalam
data.
Menurut Connoly dan Beg (2005,p286), definisi sistem (system
definition) adalah proses yang memaparkan jangkauan dan batasan dari aplikasi basis
data dan pandangan -
pandangan utama para pemakain. Sebelum mendesain
Suatu alokasi basis data penting untuk terlebih dahulu. mengidentifikasikan batasan -
batasan dari sistem yang sedang diteliti dan bagaimana kaitannya dengan bagian
lain sistem informasi perusahaan. Perlu dipikirkan untuk kebutuhan yang akan
datang selain dari keadaan saat ini. Dan tak lupa untuk mengidentifikasi pandangan
pemakai yang merupakan aspek penting dari pengembangan aplikasi basis data
yang merupakan aspek penting dari pengembangan aplikasi basis data karena
membantu untuk memastikan bahwa tidak ada pemakai utama basis data yang
terlupa ketika pengembangan aplikasi baru tersebut.
2.1.12 Requirements Collection and Analysis
Proses mengumpulkan dan analisis informasi tentang bagian dari organisasi
yang dapat didukung oleh aplikasi basis data, dan menggunakan informasi tersebut
|
|
untuk mengindetifikasi kebutuhan pengguna dari sistem baru. Banyak tehnik yang dapat
dilakukan untuk mengumpulkan informasi tersebut, disebut tehnik fact finding.
Menurut Connolly dan Begg (2005,p288-291), analisis dan pengumpulan
kebutuhan (requerment collection and analysis) adalah sebuah proses
pengumpulan dan analisis informasi tentang bagian dari perusahaan proses
pengumpulan dan analisis informasi tentang bagian dari perusahaan yang akan
didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk
mengidentifikasi kebutuhan pemakai terhadap sistem baru.
Informasi yang dikumpukan termasuk :
1. Penjabaran dari data yang digunakan,
2. Detail mengenai bagaimmana data digunakan,
3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru.
Informasi ini kemudian dianalisis untuk mengidentufikasikan kebutuhan yang
dimasukan untuk aplikasi basis data yang baru tersebut. Ada tiga macam pendekatan
untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai
pemakai, yaitu :
1. Pendekatan Centralized
Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set kebutuhan
untuk aplikasi basis data. Umunmya pendekatan ini dipakai jika basis datanya tidak
terlalu kompleks.
2. Pendekata View Integration
Kebutuhan untuk itap pandangan pemakai digunakan untuk membangun
sebuah model yang terpisah yang mempretasikan tiap pandangan pemakai
tersebut. Hasil data-data model tersebut kemudian di satukan dibagian desain basis
data
3. Kombinasi keduanya
2.1.13 Tahapan Perancangan Basis Data (Phases of Database Design)
|
|
Menurut Connolly dan Begg (2010, p322), tahapan setelah data modeling
di
dalam database design adalah selanjutnya diikuti olehtiga tahapan dalam merancang
basis data. Tahapan – tahapan tersebut antara lain adalah
Conceptual Database Design
Conceptual database design
merupakan suatu proses dalam membangun model
data yang digunakan di dalam perusahaan, dapat berdiri sendiri dari semua
pertimbangan fisikal. Hal ini diperkuat oleh pendapat Connolly dan Begg (2010, p470)
yang mengatakan bahwa perancangan konseptual merupakan proses membangun model
data yang digunakan oleh suatu perusahan, bebas dari segala pertimbangan –
pertimbangan.Langkah pertama dari perancangan basis data dinamakan sebagai
conceptual database design yang melibatkan pembentukan permodelan konseptual dari
bagian perusahaan yang memang menjadi fokus dari perancangan basis data.Menurut
Connolly dan Begg (2010, p323), perancangan konseptual merupakan implementasi
dari perangkat DBMS, program aplikasi, bahasa pemrograman, perangkat keras, serta
pertimbangan –
pertimbaSngan yang berbentuk fisik lainnya. Keseluruhan dari proses
pengembangan permodelan konseptual adalah model yang sudah dites dan divalidasi
berdasarkan kebutuhan pengguna sistem.
Menurut Connolly dan Begg (2010, p471-485), langkah –
langkah dalam
membangun model data konseptual yaitu :
Langkah 1 Membangun Model Data Konseptual
Langkah 1.1 Identifikasi tipe entitas
Langkah pertama dalam membangun model data konseptual lokal adalah
menentukan objek-
objek utama atau mengidentifikasikan entitas –
entitas yang
diperlukan oleh pengguna.Konsep utama di dalam perancangan model ER adalah
dengan menentukan tipe entitas yang merepresentasikan sekelompok objek “dunia
nyata” yang mempunyai properti yang sama. Diperkuat di dalam bukunya, Connolly
dan Begg (2010, p372) mengatakan tipe entitas adalah sekumpulan objek dengan
properti yang sama, dimana diidentifikasikan oleh perusahaan yang mempunyai
eksistensi independen.Contoh tipe entitas dapat dilihat pada gambar 2.9
|
 Gambar 2.1 Tipe Entitas
Sumber : Connolly dan Begg(2010, p374)
Langkah 1.2 Identifikasi hubungan (relationship)
Identifikasi hubungan (relationship) disini maksudnya adalah mengidentifikasi
hubungan –
hubungan (relationship) yang penting antara entitas –
entitas yang
ditemukan pada tahap sebelumnya. Entity -
Relationship Modelling digunakan untuk
menggambarkan entitas dan hubungannya. Dalam tahap ini juga ditentukan batasan
multiplicity dari relationship tersebut dan pengecekan adanya fan atau chasm traps
dalam model tersebut. Setelah itu baru dilakukan dokumentasi relationship.
a.
Fan Traps terjadi dimana model yang merepresentasikan suatu hubungan antar
entitas, tetapi alur relasinya memperlihatkan ambiguitas.
b.
Chasm Traps terjadidimana model menggambarkan keadaan dari hubungan
antara entitas yang satu dengan yang lainnya, tetapi tidak ada hubungan antara
kedua entias yang utama.
Setelah menentukan tipe entitas maka langkah selanjutnya adalah menentukan
tipe hiubungan antar entitas tersebut. Menurut Connolly dan Begg (2010, p374), tipe
hubungan yang dimaksud adalah sekumpulan asosiasi yang mempunyai makna antar
setiap jenis entitasnya. Contoh pendekatan view integration
dapat dilihat pada
gambar 2.10
Gambar 2.2 The view integration approach to managing multiple user views
|
|
Sumber : Connolly dan Begg(2010, p376)
Langkah 1.3 Identifikasi dan hubungkan atribut – atribut dengan tipe entitas atau
relasi (relationship)
Menghubungkan atribut –
atribut dengan entitas atau relationship yang tepat.
Mengidentifikasi simple/composite attributes, single valued/ multi-valued attributes,
dan derived attributes.
Tipe entitas dari properti khusus biasa disebut sebagai atribut. Menurut Connolly
dan Begg (2010, p379), atribut memegang nilai –
nilai yang mendeskripsikan kejadian
entitas dan merepresentasikan bagian utama dari data yang disimpan di dalam basis
data. Atribut sendiri merupakan properti dari tipe entitas atau hubungan. Tipe hubungan
yang menghubungkan beberapa entitas dapat mempunyai atribut yang sama dari tipe
entitas mereka sendiri. Setiap atribut yang berhubungan dengan sekumpulan nilai – nilai
disebut sebagai domain. Pernyataan ini diperkuat oleh Connolly dan Begg(2010, p379),
yang menyatakan bahwa sekumpulan dari nilai – nilai yang ada dari satu atau beberapa
atribut dikatakan sebagai domain atribut.
Menurut Connolly dan Begg (2010, p380), atribut sendiri dapat diklasifikasikan
menjadi tiga bagian yaitu
1.
Atribut sedehana dan atribut gabungan (Simple and composite
attribute)
-
Atribut sederhana (simple attribute) adalah atribut yang terdiri dari komponen
tunggal dengan keberadaan atribut yang independen. Atribut sederhana tidak
dapat dibagi lagi ke dalam komponen yang lebih kecil. Sebagai contoh : atribut
posisi dari entitas karyawan.
-
Atribut gabungan (Composite attribute)adalah atribut yang terdiri dari beberapa
komponen dengan keberadaan atribut yang independen. Beberapa atribut yang
merupakan atribut gabungandapat dibagi lagi ke dalam komponen yang lebih
kecil dengan eksistensi independen atribut itu sendiri.
Sebagai contoh : atribut alamat(Gang Keluarga, Jakarta Barat, 11480) dari
entitas pelanggan yang dapat dibagi lagi ke dalam komponen yang lebih kecil
yaitu atribut jalan untuk gang keluarga, atribut kota untuk jakarta barat dan
atribut kode pos untuk 11480.
|
|
2.
Atribut nilai tunggal dan atribut nilai ganda(Single-valued and multi-valued
attributes)
Atribut nilai tunggaladalahatribut yangmemegangnilai tunggaluntuk
setiapterjadinya suatuentitastipe.Sedangkan atribut nilai gandaadalah sebuah
atribut yang mempunyai nilai –
nilai ganda untuk setiap kejadian dari tipe
entitas.
3.
Atribut turunan (Derived attributes)
Atribut turunanadalah atribut yang merepresentasikan nilai yang didapat dari
nilai atribut yang berhubungan, tetapi tidak dalam kondisi yang sama untuk tipe
entitasnya. Contoh atribut turunan adalah umur yang didapat atau merupakan
turunan dari tanggal lahir, bulan, dan tahun.
Langkah 1.4 Menentukan domain atribut
Menentukan wilayah atribut dalam model konseptual. Yang dimaksud wilayah
adalah sekumpulan nilai – nilai dimana suatu atribut menggambarkan nilainya. Contoh
: nilai yang mungkin untuk atribut jenis kelamin dari entitas karyawan adalah ‘M’ atau
‘F’, wilayah dari atribut ini adalah single character string yang berisi nilai ‘M’ atau ‘F’.
Setelah itu, dilakukan dokumentasi domain atribut.
Langkah 1.5 Menentukan atribut candidate, primary, dan alternatekey
Mengidentifikasi candidate key untuk tiap – tiap entitas dan jika ada lebih dari
suatu candidate key , pilih salah satu untuk menjadi primary key, dan lainnya menjadi
alternate key.Diperkuat dengan pendapat Connolly dan Begg (2010, p381), yang
mengatakan bahwa kunci relasimerupakan sekumpulan atribut kecil yang secara unik
mengidentifikasikan setiap kejadian dari tipe entitas yang ada. Kunci relasidibagi
menjadi beberapa jenis yaitu :
-
Kunci kandidat (candidate key)
Suatu atribut atau sekumpulan atribut yang mengidentifikasikan secara unik
suatu kejadian spesifik dari suatu entitas.
-
Kunci primer (Primary key)
Suatu atribut atau sekumpulan atribut yang tidak hanya mengidentifikasikan
secara unik suatu kejadian spesifik, tetapi juga terpilih sebagai kunci primer.
-
Kunci altenatif (Alternative key)
|
|
Kunci kandidat yang tidak terpilih sebagai kunci primer
Langkah 1.6 Mempertimbangkan penggunaan enchanced modelling concept
(langkah opsional)
Mempertimbangkan penggunaan konsep permodelan, seperti specialization /
generalization, aggregation, dan composition.
a.
Specialization, adalah proses memaksimalkan perbedaan antara anggota entitas
dengan mengidentifikasikan karakteristik yang membedakan seluruh entitas.
b.
Generalization, adalah proses meminimalkan perbedaan antara entitas dengan
mengidentifikasikan karakteristik yang sama dari masing – masing entitas.
c.
Aggregation, adalah mempresentasikan hubungan ‘has -a’ atau ‘is-part-of’
antara tipe -
tipe entitas , dimana salah satu adalah sebagai ‘whole’ dan yang
lainnya sebagai ‘part’.
d.
Composition, adalah sebuah bentuk spesifik dari aggregation
yang
mempresentasikan penggabungan antara entitas dimana ada kepemilikan yang
kuat dan kesamaan lifetime antara ‘whole’ dan ‘part’.
Langkah 1.7 Memeriksa model akan adanya redudansi
Memerika keberadaan redudansi dalam model. Dilakukan pemeriksaan secara
spesifik terhadap hubungan one-to-one (1:1), menghilangkan hubungan (relationship)
yang redudan, dan mempertimbangkan penggunaan dimensi waktu.
Langkah 1.8 Validasi model data konseptual terhadap transaksi pengguna
Memastikan bahwa konseptual data telah mendukung transaksi yang
dibutuhkan. Hal ini dapat dilakukan dua cara yaitu :
a.
Mendeskripsikan transaksi secara detail, dengan pendekatan ini berarti akan
diperiksa semua informasi (entitas, relationship, dan atributte) yang dibutuhkan
oleh setiap transaksi apakah telah disediakan dalam model, dengan
mendokumentasikan setiap kebutuhan transaksi.
b.
Menggunakan jalur transaksi (transaction pathways), pendekatan ini digunakan
untuk validasi model data terhadap transaksi yang dibutuhkan termasuk
representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada
diagram ER.
|
 Setelah requirement collection dan analisis tahapan alur hidup sistem basis data
telah selesai dan sudah mendokumentasikan pemenuhan kebutuhan –
kebutuhan
pengguna yang nantinya digunakan untuk perancangan sistem basis data, maka hal
tersebut bisa dikatakan telah siap untuk merancang sistem basis data. Aspek yang sulit
dalam melakukan perancangan basis data adalah bagaimana seorang perancang data,
programmer
serta pengguna akhir bisa melihat data dan menggunakannya dengan
caranya sendiri. Kesulitan tersebut akan menimbulkan masalah dalam memenuhi
standar kebutuhan pengguna sistem.
Entity-Relationship
(ER) Model
merupakan solusi dari permasalahan yang
terjadi.Menurut Connolly dan Begg (2010, p371), Entity-Relationship Modeling adalah
pendekatan top-down di dalam perancangan basis data yang melakukan identifikasi data
–
data penting yang sering disebut sebagai entitas dan hubungan diantara data yang
harus direpresentasikan di dalam model. Setelah menentukan entitas dan hubungan
maka langkah selanjutnya adalah menambahkan informasi detail untuk entitas
dan hubungan tersebut yang disebut sebagai atribut dan konstrain di dalam
entitas, hubungan, dan atribut. Contoh Entity-Relationship Diagram
dapat dilihat
pada gambar 2.3
Gambar 2.3 An Entity-Relationship (ER) Diagram
Sumber : Connolly dan Begg(2010, p373)
|
 Langkah 1.9 Review model data konseptual dengan pengguna
Memeriksa model data konseptual dengan pengguna sistem untuk memastikan
bahwa model data tersebut secara tepat menggambarkan transaksi dan kebutuhan data
secara nyata dalam perusahaan.
Logical Database Design
Menurut Connolly dan Begg (2010, p323), permodelan data logikal berdasarkan
tujuan permodelan data untuk basis data, sebagai contoh : permodelan relasional (the
relational data model). Di dalam perancangan logikal terdapat teknik normalisasi untuk
mengetes akan kebenaran dari permodelan data logikal tersebut.Logical database design
merupakan proses membangun model data yang digunakan di dalam perusahaan
berdasarkan model data yang spesifik lanjutan dari tahap pertama conceptual database
design. Hal ini diperkuat oleh pernyataan Connolly dan Begg (2010, p490)yang
menyatakan bahwa
membangun model data logikal untuk mengartikan model data
konseptual ke dalam model data logikal dan memvalidasi model untuk mengecek secara
struktur basis data dengan benar serta mampu untuk mendukung transaksi yang
dibutuhkan.
Menurut Connolly dan Begg (2010, p490-p517), langkah
–
langkah dalam
membangun model data logikal adalah sebagai berikut :
Langkah 2 Membangun dan Memvalidasi Model Data Logikal
Langkah 2.1 Membuat relasi untuk model data logikal
Membuat relasi dari model data konseptual untuk merepresentasikan entitas,
relationship, dan atribut –
atribut yang telah teridentifikasi. Tabel dibawah ini
menunjukan bagaimana memetakan entitas, hubungan (relationship) dan atribut sebuah
relasi. Dokumentasikan relasi dan atribut foreign key dan juga dokumentasikan primary
key atau alternate key baru yang muncul dari hasil proses penurunan relasi.
Tabel 2.1 Pemetaan Entitas, Relationship, dan atribut sebuah Relasi
Sumber : Connolly dan Begg(2010, p500)
Entitas / Relationship / Atribut
Pemetaan Relasi
|
 Strong entity
Membuat relasi yang menyertakan semua
atribut simple
Weak entity
Membuat relasi yang menyertakan semua
atribut simple
(primary key
masih harus
ditentukan setelah relasi dengan tiap –
tiap entitas yang telah dipetakan)
1:* (one-to-many) binary relationship
Menyertakan primary key
entitas pada
sisi ‘one’ sebagai foregin key pada relasi
yang menggambarkan entitas ‘many’
juga disertakan pada entitas ‘ many’
1:1 (one-to-one) binary relationship
a) kewajiban partisipasi di dua sisi
b) kewajiban partisipasi di satu sisi
c) Pilihan partisipasi di dua sisi
Mengkombinasikan entitas –
entitas
menjadi satu relasi. Menyertakan
primary key
entitas pada sisi ‘optional’
pada relasi yang menggambarkan entitas
pada sisi ‘mandatory’. Berubah –
ubah
tergantung informasi lebih lanjut
mengenai partisipasi entitas.
Superclass / subclass relationship
Lihat tabel 2.3 pada halaman 42
*.* (many-to-many) binary relationship,
complex relationship
Membuat relasi untuk menggambarkan
relationship tersebut. sertakan duplikasi
primary keys
dari masing –
masing
owner ke dalam relasi baru untuk
berperan sebagai foreign key.
Multi-valued attribute
Membuat relasi untuk menggambarkan
atribut multi-valued
dan menyertakan
duplikat primary key
dari masing –
masing owner
entitas ke dalam relasi
baru untuk berperan sebagai foreign key
Penjelasan tabel 2.2 Pemetaan Entitas, Relationship, dan atribut sebuah Relasi adalah
sebagai berikut :
1. Tipe Entitas Kuat dan Tipe Entitas Lemah
Menurut Connolly dan Begg (2010, p334), tipe entitas diklasifikasikan menjadi
dua jenis yaitu : tipe entitas kuat dan tipe entitas lemah.
|
 a.
Tipe Entitas Kuat
Tipe entitas kuat adalah jenis entitasyang tidaktergantungpada beberapa
jenisentitaslainnya.
b.
Tipe Entitas Lemah
Tipe entitas lemah adalah jenis entitasyang tergantungpada beberapa
jenisentitaslainnya.
Contoh tipe entitas kuat dan tipe entitas lemah dapat dilihat pada gambar 2.12
Gambar 2.4 Strong and weak entity types
Sumber : Connolly dan Begg (2010, p384)
2.
Batasan struktural
Multiplicity adalah jumlah kejadian yang mungkin terjadi pada sebuah tipe entitas yang
berhubungan ke sebuah occurrence dari tipe entitas lain pada suatu relasi. Terdapat tiga
macam hubungan binary secara umum, seperti terlihat pada gambar 2.13
Gambar 2.5 Multiplicity
Sumber : Connolly dan Begg (2010 ,p387)
|
 a.
Derajat hubungan one - to - one (1:1)
Derajat hubungan (1:1) terjadi apabila tiap anggota suatu entitas hanya
boleh berpasangan dengan satu anggota dari entitas yang lain. Begitu juga
sebaliknya, anggota dari entitas lain hanya boleh mempunyai satu anggota dari
entitas tersebut.
Gambar 2.6 Multiplicity dengan tipe relasi 1:1
Sumber : Connolly danBegg(2010, p391)
b.
Derajat hubungan one – to – many (1:*)
Derajat hubungan (1:*) terjadi apabila tiap anggota suatu entitas memiliki lebih
dari satu anggota dari entitas yang lain. Begitu juga sebaliknya, anggota dari entitas
yang lain hanya boleh berpasangan dengan satu anggota dari entitas tersebut.
Gambar 2.7 Multiplicity dengan tipe relasi 1:*
Sumber : Connolly dan Begg(2010, p388)
c.
Derajat hubungan many-to-many (*:*)
Derajat hubungan (*:*) terjadi apabila tiap anggota suatu entitas memiliki lebih
dari satu anggota dari entitas yang lain dan juga entitas yang lain memiliki lebih dari
satu anggota dari entitas tersebut.
|
 Gambar 2.8Multiplicity dengan tipe relasi *:*
Sumber : Connolly dan Begg(2010, p389)
Tabel 2.2 Representasi dari superclass/sublcass relationship berdasarkan pada
partisipasi dan disjoint constraints
Sumber : Connolly dan Begg (2010, p496)
Batasan Partisipasi
Disjoint Constraint
Pemetaan Relasi
Mandatory
Nondisjoint {And}
Relasi tunggal (dengan
satu atau lebih
diskriminator untuk
membedakan tipe relasi)
Optional
Nondisjoint {And}
Dua relasi: satu relasi
untuk superclass
(dengan
satu atau lebih). Sublcass
(dengan satu atau lebih
diskriminator untuk
membedakan tipe relasi).
Mandatory
Disjoint {or}
Banyak relasi: satu relasi
untuk tiap –
tiap
kombinasi superclass /
subclass
Optional
Disjoint {or}
Banyak relasi: satu relasi
untuk superclass dan satu
untuk tiap subclass
Langkah 2.2 Validasi relasi menggunakan normalisasi
|
|
Validasi relasi pada model data logikal menggunakan teknik normalisasi. Tujuan
langkah ini adalah untuk memastikan tiap –
tiap relasi setidaknya berada dalam 3NF
(Third Normal Form).
Langkah 2.3 Validasi relasi terhadap transaksi pengguna
Memastikan bahwa relasi yang ada dalam model data logikal telah mendukung
transaksi - transaksi yang diperlukan.
Langkah 2.4 Memeriksa batasan – batasan integritas
Menentukan batasan –
batasan integritas (integrity constraint), dimana
mencakup pemeriksaan lengkap sebagai berikut :
a.
Data yang dibutuhkan
Beberapa atribut harus mempunyai nilai yang valid, atau dengan kata lain tidak
boleh null.
b.
Batasan domain atribut
Setiap atribut mempunyai domain, yaitu kumpulan dari nilai –
nilai yang
memenuhi persyaratan.
c.
Multiplicity
Merupakan batasan jumlah yang ditempatkan pada hubungan antar data di dalam
basis data.
d.
Integritas entitas (entity integrity)
Primary key dari sebuah entitas tidak boleh bernilai null.
e.
Referential Integrity
Sebuah foreign key menghubungkan setiap tuple pada relasi childs ke tuple pada
relasi parent candidate key yang merupakan nilai yang sama.
f.
Batasan umum
Batasan yang berasal dari persyaratan -
persyaratan bisnis perusahaan.
Kemudian dokumentasi semua batasan – batasan integritas (integrity constraint).
Langkah 2.5Meninjau kembalimodel data logikal dengan pengguna
|
|
Meninjau kembali model data logikal dengan pengguna untuk memastikan
bahwa pengguna menyetujui model data logikal yang merupakan representasi nyata
terhadap persyaratan data perusahaan
Langkah 2.6 Gabungan model data logikal menjadi model data global
Langkah 2.6.1 Gabungan model data logikal menjadi model data global
Metodologi perancangan logikal memudahkan perancangan basis data yang
sederhana maupun basis data kompleks. Untuk membuat basis data dengan multiple
user view, digunakan pendekatan integrasi view. Pada tahap ini, model data ini
digabungkan menjadi satu. Kegiatan –
kegiatan yang biasanya dilaksanakan dalam
langkah ini antara lain :
a.
Review nama dan isi entitas / lain dan candidate keys mereka
b.
Review nama dan isi dari relationship/foregin keys
c.
Menggabungkan entitas/relasi dari model data lokal
d.
Menyertakan (tanpa menggabungkan) entitas / relasi untuk dari masing – masing
model data lokal
e.
Menggabungkan relationship / foreign keys dari model data lokal
f.
Menyertakan (tanpa menggabungkan) relationship
/ foreign keys yang unik dari
masing – masing model data logikal
g.
Memeriksa adanya entitas / relasi dan relationship/foreign keys yang hilang
h.
Memeriksa foreign keys
i.
Memeriksa batasan integritas (integrity constraints)
j.
Menggambarkan diagram ER global
k.
Update dokumentasi
Langkah 2.6.2 Validasi data model logikal global
Validasikan relasi yang dibentuk dari model data logikal global menggunakan
teknik normalisasi dan memastikan mereka mendukung transaksi yang dibutuhkan.
Langkah 2.6.3 Review data model logikal global dengan users
|
 Memastikan bahwa data model logikal adalah representasi yang benar dari
perusahaan.
Langkah 2.7 Mengecek perkembangan di masa depan
Menentukan apakah akan ada perubahan penting yang dapat muncul yang
mungkin terjadi dimasa yang akan datang dan untuk menilai apakah model data logikal
dapat menyesuaikan diri dengan perubahan tersebut.
Physical Database Design
MenurutConnolly dan Begg (2010, p324), langkah terakhir dalam perancangan
basis data adalah physical database design yang mendeskripsikan bagaimana sebuah
basis data diimplementasikan. Tiga langkah perancangan basis data yang terdiri dari
perancangan konseptual, logikal dan fisikal termasuk ke dalam the three-level ANSI-
SPARC. Contoh gambar The three-level ANSI-SPARC dapat dilihat pada gambar 2.17
Gambar 2.9 The view integration approach
Sumber : Connolly dan Begg(2010, p325)
Connolly dan Begg (2010, p523) juga mengatakan secara rinci bahwaphysical
database designadalah sebuah proses menciptakan atau menghasilkan deskripsi dari
implementasi basis datadalam penyimpanan kedua; mendeskripsikan hubungan dasar,
dokumen perusahaan, dan indeks yang digunakan untuk memperoleh akes data yang
efisien, dan setiap konstrain integritas
yang terkait serta langkah –
langkah
keamanan.Connolly dan Begg (2010, p523-558) menguraikanlangkah –
langkah dalam
membangun model data fisikal sebagai berikut :
Langkah 3 Menerjemahkan Model Data Logikal untuk DBMS yang Ditargetkan
Langkah 3.1 Merancang relasi dasar
|
|
Menentukan bagaimana representasi relasi dasar yang telah diidentifikasi pada
model data logikal global, agar dapat diimplementasikan pada tujuan DBMS. Informasi
yang dibutuhkan dapat diperoleh dari kamus data dan definisi dari relasi dideskripsikan
menggunakan database design language (DBDL)
Langkah 3.2 Merancang representasi derived data
Menentukan bagaimana representasi data turunan yang ada pada model data
logikal global, agar dapat diimplementasikan pada DBMS tujuan. Atribut yang nilainya
didapatkan dari mengkaji nilai atribut lain dinamakan derives atau calculated attributes.
Contoh : jumlah karyawan yang bekerja pada suatu cabang perusahaan atau total gaji
semua karyawan. Untuk setiap derives attributes yang ada. Tanda “/” digunakan untuk
menandakan atribut tersebut adalah derives attribute.
Langkah 3.3 Merancang batasan – batasan umum (general constraint)
Merancang batasan – batasan umum untuk DBMS yang akan digunakan.
Langkah 4 Merancang Organisasi File dan Index
Langkah 4.1 Menganalisa transaksi
Memahami fungsionalitas transaksi yang dijalankan pada basis data dan
menganalisa transaksi – transaksi yang penting.
Langkah 4.2 Memilih organisasi file
Tujuan langkah ini adalah menentukan organsisasi file yang efisien untuk tiap –
tiap relasi dasar jika diperoleh DBMS yang akan digunakan.
Langkah 4.3 Memilih organisasi index
Tujuan langkah ini untuk menentukan apakah kegunaan index akan
meningkatkan kinerja sistem. ada tiga jenis index yaitu :
a.
Primary index, pengindeksan dilakukan pada kolom kunci (key field), yang
diurutkan terlebih dahulu secara sekuensial
b.
Clustering index, pengindeksan dilakukan pada kolom bukan kunci (non-key
field), yang sudah diurutkan terlebih dahulu secara sekuensial. Kolom bukan
kunci itu disebut juga dengan clustering attribute.
|
|
c.
Secondary index, pengindeksan dilakukan pada kolom yang tidak terurut
didalam file data.
Langkah 4.4 Memperkirakan kebutuhan kapasitas disk
Memperkirakan besarnya ruang disk (disk space) yang dibutuhkan untuk
mendukung implementasi basis data. estimasi pemakaian disk
tergantung pada DBMS
dan perangkat keras yang digunakan untuk mendukung basis data. Perkiraan ukuran
dapat dilakukan dengan mengukur besar data tiap baris dan jumlah baris pada setiap
relasi.
Langkah 5 Merancang sudut pandang pengguna
Merancang view pengguna yang telah diidentifikasi selama tahap pengumpulan
kebutuhan dan tahap analisa pada daur hidup pengembangan sistem basis data
relasional. (System development lifecycle)
Langkah 6 Merancang mekanisme keamanan
Merancang mekanisme kemanan untuk sistem basis data sesuai yang dibutuhkan
pengguna, ada dua macam keamanan sistem mencakup akses dan penggunaan basis data
pada level sistem seperti username
dan password. Keamanan bagi sistem basis data
sangat diperlukan karena basis data merupakan sumber daya perusahaan yang penting.
Langkah 7 Mempertimbangkan pengenalan dan pengendalian terhadap redudansi
Dalam langkah ini, digunakan untuk menentukan pengenalan redudansi dalam
hal pengendalian dengan aturan normalisasi yang akan meningkatkan performa sistem.
Langkah 8 Mengamati dan memasang sistem operasional
Langkah terakhir di dalam perancangan basis data fisikal adalah mengamati
sistem operasional dan meningkatkan performa sistem untuk membenarkan keputusan
perancangan yang pantas atau mencerminkan kebutuhan yang berubah – ubah.
2.1.14 DBMS Selection
Desain dari user interface dan program aplikasi yang digunakan dan proses
database. Langkah-langkah yang digunakan dalam memilih sebuah DBMS adalah
sebagai berikut:
|
 Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan
Membuat perbandingan mengenai dua atau tiga produk DBMS
Mengevaluasi produk-produk DBMS tersebut
Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi
produk DBMS tersebut.
Menurut Connolly & Begg (2005,p295–296), pemilihan DBMS yang sesuai untuk
mendukung aplikasi basisdata. Yang mencakup :
1. Mendefinisikan syarat-syarat referensi studi
Menentukan sasaran, batasan masalah, dan tugas yang harus dilakukan.
2. Mendaftar 2 atau 3 jenis barang
Membuat daftar barang - barang, misalkan dari mana barang ini didapat,
berapa biayanya serta bagaimana hila ingin mendapatkannya.
3. Mengevaluasi barang
Barang-barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui
kelebihan dan kekurangan barang tersebut.
4. Merekomendasikan pilihan dan membuat laporan
Merupakan langkah terakhir dari seleksi DBMS yaitu mendokumentasikan
proses dan untuk menyediakan pemyataan mengenai kesimpulan dan rekomendasi
terhadap salah satu produk DBMS.
2.1.15 Application Design
Proses merancang user interface atau antarmuka pengguna dan program aplikasi
yang menggunakan dan memproses basis data.
Menurut Connolly & Begg (2005,p299-230), perancangan aplikasi (application
design) adalah merancang antarmuka pemakai (user interface) dan program aplikasi
yang akan memproses basisdata. Perancangan basisdata dan perancangan aplikasi
adalah aktivitas bersamaan pada database application lifecycle.
|
 Dalam kasus sebenarnya, adalah tidak mungkin untuk menyelesaikan
perancangan aplikasi sebelum perancangan basisdata selesai. Dalam perancangan
aplikasi harus memastikan semua pertanyaan fungsional dari spesifikasi kebutuhan
pemakai (user requirement specification) yang menyangkut perancangan aplikasi
program yang mengakses basisdata dan merancang transaksi yaitu cara akses ke
basisdata dan perubahan terhadap isi basisdata (retireve, update dan kegiatan
keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan
merancang antarmuka pemakai (user interface) yang tepat. Antarmuka yang
dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan
'user-friendly'. Kebanyakan antarmuka pemakai yang diabaikan akan niscaya
membuat masalah. Bagaimanapun, antarmuka pemakai harus diakui sebagai komponen
dari sistem yang penting, dimana agar mudah dipelajari dan mudah digunakan,
sehingga pemakai akan cenderung memberdayagunakan informasi yang disajikan.
2.1.16 Prototyping
Membangun model kerja dari database system, yang memungkinkan designer
atau user untuk membayangkan dan mengevaluasi bagaimana sistem akhir akan
terlihat dan berfungsi. Umumnya sebuah prototype merupakan sebuah model kerja yang
tidak memiliki semua fitur atau memberikan semua fungsi dari sistem. Tujuan utama
dalam pengembangan prototype pada aplikasi basis data adalah untuk memungkinkan
pengguna menggunakan prototype
dan mengidentifikasi fitur-fitur sistem, baik yang
bekerja dengan baik maupun
yang kurang baik, serta memungkinkan pengguna untuk
dapat mengusulkan perkembangan beberapa fitur barn untuk aplikasi basis data . Dua
jenis prototype yang sering ditemukan adalah :
Requirement prototyping Penggunaan prototype untuk menunjukkan tujuan dari
pembuatan aplikasi basis data.
Evolutionary prototype
(pengembangan model) Digunakan untuk tujuan yang
sama, perbedaan terpentingnya adalah prototype
tidak dibuang, tetapi
dikembangkan selanjutnya menjadi aplikasi basis data yang bekerja.
Menurut Connolly & Begg (2005,p303–304), prototyping adalah membuat
model kerja dari aplikasi basisdata, yang membolehkan perancangan atau user untuk
mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki
sistem. Tujuan dari pengembangan prototype aplikasi basisdata adalah untuk
|
|
memungkiukan pemakai menggunakan prototype untuk mengidentifikasi keistimewaan
sistem atau kekurangannya, dan memungkiukan perancangan untuk memperbaiki atau
melengakapi keistimewaan (feature) dari aplikasi basisdata baru.
Ada dua strategi prototyping yang umum digunakan sekarang, yaitu
requirement prototyping dan evolutionary prototyping. Requirement prototyping adalah
menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basisdata
dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang
(discard). Sedangkan evalutionary prototyping menggunakan tujuan yang sama,
tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya
dikembangkan menjadi aplikasi basisdata yang bekerja.
2.1.17 Implementation
Membuat definisi physical database dan program aplikasi. Implementasi basis
data dapat dicapai dengan menggunakan Data DefinitionLanguage (DDL) dari DBMS
yang dipilih. Pernyataan DDL digunakan untuk membuat struktur basis data dan arsip
basis data kosong.
Implementation
adalah
realisasi
fisikal
dari
desain
basisdata
dan
desain aplikasi
(Connolly
& Begg,
2005,p304).
Dalam tahap
ini
juga
akan
diimplementasikan
komponen
lain
dari
aplikasi
basisdata
seperti
menu
·layar, pemasukan data,
security
dan kontrol
integritas.
2.1.18 Data Conversion and Loading
Loading
data dari sistem lama ke sistem baru dan dimana memungkinkan
penggabungan antar aplikasi yang sedang berjalan dalam database
yang baru. dan
mengubah aplikasi yang sudah ada untuk dapat dijalankan pada basis data yang baru.
Tahap ini hanya diperlukan ketika sebuah sistem basis data baru menggantikan sistem
yang lama.
Data Conversion and loading adalah suatu proses mentransfer data yang ada ke
dalam basisdata baru dan mengubah aplikasi yang ada untuk dijalankan dalam
basisdata baru (Connolly & Begg, 2005,p305). Tahap ini hanya dibutuhkan
ketika sistem basisdata baru menggantikan sistem yang lama
|
|
2.1.19 Testing
sistem database di coba apabila ada error dan memvalidasi terhadap spesifikasi
kebutuhan user.
Testing adalah suatu proses mengeksekusi program aplikasi dengan
tujuan untuk menemukan kesalahan (Connolly & Begg, 2005,p305–306). Jika
pengujian berhasil, maka dapat menampilkan error dari program aplikasi dan
struktur basisdata. Testing memperlihatkan bahwa basisdata dan program aplikasi
bekeija sesuai dengan spesifikasinya dan menampilkan kebutuhan - kebutuhan untuk
keija yang memuaskan.
2.1.20 Operational Maintenance
sistem database
sudah dijalankan secara penuh. Sistem secara
berkesinambungan dimonitor dan dikelola. Pada tahap sebelumnya, aplikasi basis data
telah diimplementasikan dan diuji. Setelah itu, sistem dapat memasuki tahap perawatan,
yang melibatkan aktivitas sebagai berikut:
-
Memantau hasil dari sistem, jika hasil masih kurang dari harapan yang diterima,
maka perbaikan basis data akan dibutuhkan
-
Memelihara dan melakukan upgrade pada aplikasi basis data (jika dibutuhkan)
-
Memasukkan kebutuhan baru ke dalam aplikasi basis data dapat dilakukan
melalui tahap dari daur hidup terlebih dahulu
Operational Maintenance adalah suatu proses memonitor dan memelihara sistem
berdasarkan instalasi (Connolly & Begg, 2005,p306–307). Tahapan ini terdiri dari
aktivitas- aktivitas berikut :
-
Memonitor untuk kerja sistem
-
Memelihara dan
memperbaharui
aplikasi
basisdata
(jika
diperlukan)
2.1.21 User Interface
|
|
User Interface
adalah merupakan
mekanisme komunikasi antara pengguna
(user) dengan sistem. Antarmuka pemakai (User Interface) dapat menerima informasi
dari pengguna (user) dan memberikan informasi kepada pengguna (user) untuk
membantu mengarahkan alur penelusuran masalah sampai ditemukan suatu solusi.
User interface menurut Satzinger, Jackson, dan Burd (2005,p442) adalah bagian dari
sistem informasi yang membutuhkan interaksi dari user untuk membuat input dan
output. Hal ini di pertegas oleh Menurut Mathiassen(2000,p152) user interface adalah
sebuah fasilitas bagi user untuk dapat berinteraksi dengan sistem. Kualitas dari user
interface umumnya disebut usability. Usability tergantung pada siapa user dan dalam
keadaan bagaimana sistem digunakan. Jadi dapat di simpulkan bahwa User Interface
adalah interaksi antara manusia dengan komputer yang saling memberikan informasi.
2.1.22 Normalisasi
Normalisasi adalah suatu teknik dimana digunakan untuk mengidentifikasikan
hubungan antara atribut dengan memberikan kebutuhan data yang diperlukan oleh suatu
perusahaan. Seperti yang disampaikan oleh Connolly dan Begg, (2010, p.416)
normalisasi merupakan sebuah teknik untuk memproduksi satu set hubungan dengan
sifat yang diinginkan, memberikan kebutuhan data pada perusahaan.
Proses Normalisasi antara lain :
• Suatu teknik formal untuk menganalisis relasi berdasarkan primary key dan fungsi
dependensi antar atribut yang ada.
• Dieksekusi dalam beberapa cara. Setiap cara mengacu ke bentuk normal tertentu,
sesuai dengan sifat yang dimilikinya.
• Setelah Normalisasi diproses, relasi akan secara bertahap lebih terbatas/kuat bentuk
formatnya dan juga mengurangi tindakan anomali pada setiap update.
|
 Gambar 2.10 Diagram ilustrasi dari hubungan antara bentuk normalisasi
Sumber : Connolly dan Begg (2010,p429)
Bentuk-bentuk normalisasi menurut Connolly dan Begg, (2010,p430-438)
antara lain:
1. Unnormalized Form (UNF)
Merupakan sebuah tabel awal yang belum ternormalisasi yang berisikan satu atau lebih
kumpulan data yang berulang. Untuk membuat tabel UNF yaitu dengan memindahkan
data dari sumber informasi yang di dapat ke dalam tabel dengan format baris dan
kolom, jika ada atribut yang mempunyai banyak nilai (multivalue) akan masuk ke
dalam bentuk UNF.
2. First Normal Form (1NF)
Bentuk normalisasi tahap pertama yang merupakan sebuah relasi dimana sebuah titik
pertemuan antara setiap baris dan kolom yang berisi satu dan hanya satu nilai.
3. Second Normal Form (2NF)
Tahapan kedua setelah 1NF terpenuhi yaitu 2NF dimana merupakan sebuah relasi yang
terdapat di dalam 1NF dan setiap atribut yang bukan primary key bergantung pada
primary key.
4. Third Normal Form (3NF)
Merupakan tahapan ketiga dalam normalisasi dimana sebuah relasi yang terdapat pada
bentuk normalisasi pertama dan kedua, yang mana atribut primary key
|
|
bergantung pada primary key.
Proses normalisasi meliputi langkah-langkah sebagai berikut :
a) Unnormalized Normal Form (UNF)
Ada tahap awal sebelum memulai 1NF yaitu unnormalized form (UNF). Pada bentuk
UNF ini merupakan tabel yang terdapat satu atau lebih grup yang berulang
(repeating groups).
b) First Normal Form (1NF)
Pada bentuk pertama ini merupakan sebuah hubungan dimana perpotongan setiap
baris dan kolom yang berisi satu dan hanya satu nilai. Sebelum mentransformasikan 11
tabel tidak normal
(UNF) ke bentuk normal pertama (1NF). terlebih dahulu
mengidentifikasi repeating groups yang terdapat pada tabel relasi. Kemudian
menghilangkan repeating groups untuk menghilangkan data rangkap.
c) Second Normal Form (2NF)
Pada bentuk normalisasi kedua ini yaitu 2NF merupakan relasi yang terdapat dalam
bentuk 1NF dan tiap atribut yang bukan primary key sifatnya bergantung penuh secara
fungsional pada primary key (full functional dependency)
d) Third Normal Form (3NF)
Untuk menjalankan bentuk ini, maka bentuk 1NF dan 2NF haruslah terpenuhi terlebih
dahulu. Dimana tidak ada atribut bukan primary key yang bergantung transitif terhadap
primary key. Bentuk normal ketiga ini lebih berdasarkan pada konsep peralihan
ketergantungan (transitive dependency). Transitive dependency adalah kondisi dimana
A, B, dan C adalah atribut dari sebuah relasi bahwa jika A
?B dan B?C, maka C
adalah transitive independent pada A melewati B (menyatakan bahwa A bukan
merupakan functional dependent pada B atau C).
e) Boyce-Codd Normal Form (BCNF)
Suatu relasi bisa dikatakan BCNF bila didalamnya berisi atribut yang berfungsi sebagai
candidate key salah satu dari candidate key tersebut menjadi primary key.
f) Fourth Normal Form (4NF)
|
 Bentuk normal 4NF terpenuhi dalam sebuah tabel jika telah memenuhi bentuk BCNF,
dan tabel tersebut tidak boleh memiliki lebih dari satu multivalued attribute.
g) Fifth Normal Form (5NF)
Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah lossless decomposition
menjadi tabel-tabel yang lebih kecil.
2.1.23 Entity Relationship Diagram (ERD)
Menurut Satzinger, Jackson, dan Burd (2010, p57), entity relationship diagram
merupakan suatu analisis struktur dan rekayasa informasi dari model data yang
diperlukan oleh sistem. Contoh ERD dapat dilihat pada gambar 2.18
Gambar 2.11 Entity Relationship Diagram
Penjelasan proses bisnis ERD gambar 2.18
1.
Entitas Pelanggan
Entitas pelanggan mempunyai atribut kode_pelanggan(primary key),
nama, alamat, no_telp yang menyatakan isi dari entitas pelanggan.
2.
Entitas Purchase Order
Entitas purchase_order mempunyai atribut kode_po (primary key),
kode_pelanggan(foreign_key), total, tanggal_po yang menyatakan isi dari entitas
purchase_order.
3.
Entitas Detail Puchase Order
Entitas detail purchase order terbentuk karena adanya hubungan atau
relationship many-to-many (*:*) antara entitas purchase_order
dengan barang.
|
|
Entitas detail purchase order berisi kode_po, kode_barang yang befungsi
sebagai primary dan foreign key dari entitas masing – masing
4.
Entitas Barang
Entitas barang mempunyai atribut kode_barang (primary key), nama
_barang, jenis, harga yang menyatakan isi dari entitas barang.
Proses bisnis yang terjadi dengan melihat alur ERD pada contoh gambar 2.18
adalah pelanggan yang datang ingin membeli barang akan dicatat semua ke dalam
purchase order oleh bagian kasir. Purchase order sendiri berarti dokumen yang
mencatat segala transaksi barang yang dibeli oleh pelanggan. Purchase Order yang
nantinya berisi daftar barang – barang akan mengambil data – data barangnya di dalam
sistem ke dalam tabel barang.
2.1.24 Pendekatan perancangan basis data
Menurut Connolly dan Begg (2010, p321), ada dua pendekatan untuk mendesain
sebuah basis data, yaitu :
1.
Pendekatan bottom – up
Dimulai pada tingkat awal dari atribut (yaitu, property dari entitas dan
relationship), melalui analisis dari asosiasi antar atribut, dikelompokkan menjadi
hubungan yang merepresentasikan jenis –
jenis entitas dan hubungan antar
entitas.Pendekatan ini sesuai untuk mendesain basis data yang sederhana dengan
jumlah atribut yang tidak banyak.
2.
Pendekatan top-down
Digunakan pada basis data yang lebih kompleks.dimulai dengan
pengembangan dari model data yang mengandung beberapa entitas dan
hubungan tingkat tinggi, kemudian menggunakan perbaikan top-down berturut –
turut untuk mengidentifikasikan entitas, hubungan dan atribut tingkat rendah.
Pendekatan ini biasanya digambarkan melalui Entity-Relationship (ER ).
2.1.25 Database System Development Life Cycle
Dalam merancang sebuah basis data diperlukan tahapan –
tahapan serta
kemampuan dalam menganalisis dan merancang sebuah basis data tersebut. Diperkuat
|
 oleh pendapat Connolly dan Begg (2006)
dalam jurnalnya yang mengatakan bahwa
dalam menentukan analisis dan perancangan basis data diperlukan kemampuan seorang
perancang basis data sebagai berikut :
Gambar 2.5 Tipe pengetahuan kemampuan analisis dan perancangan basis data
Sumber :Connolly dan Begg (2006, p46)
Menurut Connolly dan Begg (2010, p313), untuk merancang aplikasi sistem
basis data diperlukan tahapan – tahapan yang dinamakan dengan siklus hidup aplikasi
basis data (database system development lifecycle).Tahapan – tahapan
database system development life cycle adalah sebagai berikut :
1.
Database planning
2.
System definition
3.
Requirements collection and analysis
4.
Database design
-
Conceptual Database Design
|
|
-
Logical Database Design
-
Physical Database Design
5.
DBMS selection (optional)
-
Application Design
-
Prototyping (optional)
-
Implementation
-
Data conversion and loading
-
Testing
-
Operational maintenance
Contoh Database System Development Lifecycle dapat dilihat pada gambar 2.6
|
 Gambar 2.6The stages of database system development lifecycle
Sumber :Connolly dan Begg (2010, p314)
2.2 Teori Khusus
2.2.1 Penjualan
Menurut Reeve (2009,p255), penjualan adalah total biaya yang dibebankan
kepada customer untuk barang yang dijual termasuk penjualan tunai maupun penjualan
kredit.
|
|
Menurut Dave (2010) dalam jurnalnya mengatakan, menjadi seorang Sales
professional tidak ada hubungannya dengan berapa lama dia berada di bidang itu, latar
belakang pendidikan atau tingkat pengalaman.
2.2.2
Pembelian
Menurut Indrajani (2011,p71) , pembelian adalah suatu usaha yang digunakan
dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Secara
umum definisi pembelian adalah usaha pengadaan barang atau jasa dengan tujuan yang
akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual
kembali, baik dengan atau tanpa proses, dalam proses pembelian
yang ada, agar
kegiatan pembelian dapat dilakukan dengan benar. Fungsi pembelian bertanggung
jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang
dipilih dalam pengadaan barang, dan mengeluarkan pesanan pembelian kepada pemasok
yang dipilih.
Menurut
Hall (2008, p235), prosedur pembelian terdiri dari tugas –
tugas
yangmeliputi identifikasi kebutuhan inventory, penempatan order, penerimaan
inventory, dan pengenalan akan kewajiban atau liability.
Dokumen –
dokumen yang
terkait atau termasuk dalam prosedur sistem pembelian adalah sebagai berikut :
1.
Purchase requisition
Dokumen yang diperlukan untuk pembelian barang ketika barang
mencapai titik terendah di dalam persediaan gudang. Purchase Requisition
dibuat ketika terjadinya kondisi Re-Order Point (ROP).
2.
Purchase order
Dokumen purchase order disiapkan ketika adanya dokumen purchase
requisition.
Dokumen purchase order
disiapkan untuk melakukan pembelian
kepada supplier, tentu kepada supplier yang sudah termasuk di dalam daftar list
atau telah melewati sistem sort. Duplikat dari purchase order diberikan kepada
supplier, bagian keuangan untuk membuat account payable (AP), dan terakhir
diberikan kepada bagian gudang (inventory).
3.
Receive goods
|
|
Ketika barang yang dipesan dari suppliermasuk atau telah sampai ke
perusahaan, maka bagian gudang akan membuat receiving report
sebagai
laporan bahwa barang yang telah dipesan bagian pembelian telah sampai, barang
sesuai atau tidak dengan file purchase order, serta melaporkan kondisi barang.
4.
Supplier invoice
Supplier invoice atau tagihan supplier merupakan dokumen tagihan yang
diberikan dari supplier kepada bagian pembelian untuk ditanggung pembayaran
atas barang yang telah dibeli atau dipesan berdasarkan purchase order.
Dikutip dari jurnal (Sistem informasi pembelian, 2013) 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.
2.2.3
Persedian
Pengawasan dan pemeliharaan persediaan adalah masalah biasa dalam semua
organisasi di setiap faktor sektor ekonomi.
Yamit
(2005, p3) mengatakan bahwa
masalah persediaan tidak hanya terbatas pada perusahaan pencari keuntungan saja
tetapi juga dialami oleh organisasi sosial maupun perusahaan non profit oriented,
seperti persediaan dalam pabrik, agrobisnis, pedagang besar, pengecer, rumah sakit,
sekolah, hotel dan mesjid, rumah tangga, restoran, pemerintah dan lain sebagainya.
Istilah (terminologi) persediaan dapat digunakan dalam perbedaan seperti :
1.
Persediaan bahan baku di tangan (stock on hand)
2.
Daftar persediaan secara fisik
3.
Jumlah item di tangan
4.
Nilai persediaan barang
Menurut Mulyadi (2001,p553), sistem persediaan bertujuan untuk mencatat
mutasi tiap jenis persediaan yang disimpan digudang. Sistem ini berkaitan erat
dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur
pembelian, dan sistem akuntasi biaya produski. Dalam perusahaan manufaktur,
|
 persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses
persediaan bahan baku, persedian bahan penolong, persedian
bahan habis pakai
pabrik, persedian suku cadang. Dalam perusahaan dagang, persediaan hanya terdiri
dari satu golongan yaitu persediaan barang dagang yang merupakan barang yang
dibeli untuk tujuan dijual kembali. Sedangkan untuk metode pencatatan persedian
dibagi menjadi dua yaitu :
Metode mutasi persediaan
Setiap mutasi persediaan dicatat dalam kartu persediaan dicatat dalam kartu
persediaan.
Metode persediaan fisik
Hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan
mutasi berkurangnya persediaan karena pemakai tidak dicatat dalam kartu
persediaan.
Dikutip dari jurnal (Sistem informasi persedian, 2010), menjelaskan bahwa
persedian merupakan aser pengadaan barang di dalam sebuah bisnis, atau yang
sedang dalam proses untuk penjualan tertentu, atau dalm wujud material atau
pendukung untuk digunakan dalam proses produksi atau penyumbangan jasa
|
|
|