BAB 2 LANDASAN TEORI

BAB 2
LANDASAN TEORI
2.1
2.1.1
Teori Umum
Pengertian Data
Menurut Connolly dan Begg (2005, p19), data adalah komponen yang
paling penting dalam DBMS, berasal dari sudut pandang end-user. Data
bertindak sebagai jembatan yang menghubungkan antara mesin dengan
pengguna.
Menurut Turban (2005, p38), data adalah deskripsi dasar tentang
sesuatu, kejadian, kegiatan dan transaksi yang ditangkap, direkam, disimpan,
dan diklasifikasikan, namun tidak terorganisir untuk menyampaikan arti
khusus.
Menurut Inmon (2005, p493), data adalah rekaman dari fakta, konsep,
ataupun instruksi pada sebuah media penyimpanan untuk komunikasi,
pengambilan, maupun pemrosesan dari pengertian otomatis dan presentasi dari
informasi yang dapat dimengerti oleh manusia.
7 8 2.1.2
Pengertian Basis Data
Menurut Connolly dan Begg (2005, p15), basis data adalah sekumpulan
data yang terhubung secara logikal, dan deskripsi dari data tersebut
menghasilkan informasi yang dibutuhkan oleh organisasi.
Menurut Inmon (2002, p388), basis data adalah sekumpulan data yang
saling berhubungan dan disimpan (biasanya telah terkontrol dan memiliki
redundansi yang terbatas) berdasarkan suatu skema.
2.1.3
Database Languages
1. Data Definition Language (DDL)
Menurut Connolly dan Begg (2005, p40), Data Definition
Language (DDL) adalah suatu bahasa yang memungkinkan Database
Administrator (DBA) atau pengguna untuk mendeskripsikan nama dari
entitas-entitas, atribut dan relasi yang dibutuhkan untuk aplikasi, termasuk
integritas dan keamanan datanya.
Hasil dari kompilasi perintah DDL adalah kumpulan tabel yang
disimpan dalam file khusus yang disebut kamus data (Data Dictionary).
Menurut Connolly dan Begg (2005, p169), beberapa tahapan dari DDL,
yaitu:
a. Create Table
Untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap
kolom.
b. Alter Table
Untuk menambah atau membuat kolom dan constraint.
9 c. Drop Table
Untuk membuang atau menghapus tabel beserta semua data yang ada di
dalamnya.
d. Create Index
Untuk membuat index pada suatu tabel.
e. Drop Index
Untuk membuang atau menghapus index yang dibuat sebelumnya.
2. Data Manipulation Language (DML)
Menurut Connolly (2005, p40), Data Manipulation Language
(DML) adalah suatu bahasa yang menyediakan fasilitas pengoperasian
dasar manipulasi data pada data yang ada dalam basis data.
Pengoperasian data yang dimanipulasi antara lain :
1. Penyisipan data baru ke dalam basis data (insertion).
2. Modifikasi data yang disimpan dalam basis data (modify).
3. Pemanggilan data yang terdapat dalam basis data (retrieve).
4. Penghapusan data dari basis data (delete).
Menurut Connolly (2005, p41), kita dapat membedakan DML
menjadi dua tipe yang berbeda, yaitu :
a. Procedural DML
Procedural DML adalah suatu bahasa yang memungkinkan pengguna
(umumnya programmer) untuk memberi instruksi ke sistem mengenai
data apa yang dibutuhkan dan bagaimana cara pemanggilannya.
Artinya, pengguna harus menjelaskan operasi pengaksesan data yang
10 akan digunakan dengan menggunakan prosedur yang ada untuk
mendapatkan informasi yang dibutuhkan.
b. Non-Procedural DML
Non-Procedural DML adalah bahasa yang memungkinkan pengguna
untuk menentukan data apa yang dibutuhkan dengan menyebutkan
spesifikasinya tanpa menspesifikasi bagaimana cara mendapatkannya.
2.1.4
Database System Development Lifecycle (SDLC)
Menurut Connolly dan Begg (2005, p283), sistem basis data adalah
komponen dasar dari organisasi yang besar dengan sistem informasi yang luas.
Hal penting yang perlu diperhatikan dalam Database Application Lifecycle
adalah bahwa tingkatanya tidak sepenuhnya berurutan (sequential). Dimana
ada beberapa tingkatan yang berulang dengan alur-balik (feedback loop)
misalnya, masalah ditemukan pada tingkatan perancangan basis data yang
membutuhkan tambahan kumpulan kebutuhan dan analisis.
Database Application Lifecycle merupakan tahapan dalam merancang
suatu sistem basis data. Database Application Lifecycle digambarkan seperti
bagan berikut :
11 Database Planning
System Definition
Requirement collection
and analysis
Database design
DBMS selection
(optional)
Conceptual
database design
Application design
Logical database
design
Physical database
design
Prototyping
(optional)
Implementation
Data conversion
and loading
Testing
Operational
maintenance
Gambar 2.1 Database Application Lifecycle
12 Menurut Connolly dan Begg (2005, p285), berikut ini adalah
keterangan dari Database Application Lifecycle data diatas :
2.1.4.1 Database Planning
Menurut Connolly dan Begg (2005, p285), Database Planning adalah
aktivitas manajemen yang memungkinkan tahapan dari siklus hidup
pengembangan aplikasi basis data untuk dapat realisasikan seefisien dan
seefektif mungkin. Ada tiga persoalan pokok yang berkaitan dengan perumusan
strategi sistem informasi, antara lain :
1. Mengenali rencana dan tujuan perusahaan, kemudian menentukan
kebutuhan sistem informasi.
2. Mengevaluasi sistem informasi yang sedang berjalan untuk menentukan
kekuatan dan kelemahan.
3. Penilaian dari kesempatan teknologi informasi yang menghasilkan
kekuatan kompetitif.
2.1.4.2 System Definition
Menurut Connolly dan Begg (2005, p286), System Definition adalah
proses menspesifikasikan ruang lingkup dan batasan dari aplikasi basis data dan
user view utama. Sebelum mencoba merancang suatu aplikasi basis data,
diperlukan untuk mengenali batasan sistem dan bagaimana antarmuka dengan
bagian sistem informasi lainnya dalam organisasi.
13 2.1.4.3 Requirement Collection And Analysis
Menurut Connolly dan Begg (2005, p288), Requirement Collection and
Analisis adalah proses mengumpulkan dan menganalisa informasi yang
mendukung aplikasi basis data dan menggunakan informasi ini untuk
mengidentifikasi kebutuhan pengguna pada sistem yang baru. Fact-finding
adalah cara untuk mendapatkan informasi. Menurut Connolly dan Begg (2005,
p317), ada beberapa teknik Fact-finding :
1. Mengevaluasi dokumen.
2. Wawancara.
3. Mengamati jalannya kegiatan kerja pada perusahaan.
4. Penelitian.
5. Kuesioner.
2.1.4.4 Database Design
Menurut Connolly dan Begg (2005, p291), Database Design adalah
proses dari pembuatan sebuah rancangan yang mendukung visi dan misi
perusahaan yang dibutuhkan untuk sebuah sistem basis data. Perancangan basis
data dibagi menjadi tiga tahapan utama yaitu conceptual database design,
logical database design, dan physical database design.
14 2.1.4.4.1 Perancangan Basis Data Konseptual
Tujuan dari perancangan konseptual basis data menurut Connolly
and Begg (2005, p442) adalah untuk memproses pembentukan suatu model
yang berasal dari informasi yang digunakan dalam suatu perusahaan, yang
tidak tergantung pada segala pertimbangan fisikal.
Langkah-langkah dalam pembuatan model basis data konseptual adalah:
Langkah 1 : Membangun Model Data Konseptual
Tujuan dari langkah ini adalah untuk membangun model data
konseptual terhadap kebutuhan data suatu perusahaan.
Langkah 1.1 : Mengidentifikasi tipe entitas
Tujuan dari langkah ini adalah untuk mengidentifikasi entitas utama
yang diminta oleh user.
Langkah pertama yang diperlukan dalam membangun suatu lokal
konseptual data model adalah untuk mendefinisikan objek utama atau entitas
dimana user memang membutuhkannya. Salah satu metode untuk
mengidentifikasi tipe entitas yang utama adalah dengan mengidentifikasi
kata benda atau frase kata benda yang telah disebutkan oleh user.
Setelah tipe entitas diidentifikasi, dilakukan pemberian nama yang
berarti dan jelas kepada user. Mencatat nama dan deskripsi entitas dalam
kamus data. Apabila dimungkinkan, mendokumentasikan jumlah occurences
yang diharapkan dari tiap entitas. Jika entitas dikenal dengan nama yang
berbeda, nama tersebut menunjuk kepada sinonim atau alias yang dicatat
dalam kamus data.
15 Gambar 2.2 Contoh kamus data entity yang mendeskripsikan entity untuk
stafuser view dreamhome
Langkah 1.2 : Mengidentifikasi tipe relasi
Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang
penting antara berbagai tipe entitas yang telah diidentifikasikan. Biasanya
relasi diidentifikasi dengan menggunakan kata kerja atau frase kata kerja.
Relasi yang paling umum adalah relasi binary. Yang artinya relasi
antar entitas yang persis antara dua entitas saja. Bagaimanapun, relasi
kompleks yang melibatkan lebih dari dua entitas dan relasi rekursif yang
hanya melibatkan satu entitas harus diperhatikan.
Adapun langkah-langkah dalam mengidentifikasi tipe relasi sebagai
berikut :
a.
Menggunakan Entity-Relationship (ER) Diagram
Hal yang sering terjadi adalah user akan lebih cepat mengerti suatu
perancangan basis data dengan cara divisualisasikan dibanding dengan
perancangan basis data yang dituliskan dalam bentuk tekstual. Dalam hal ini,
ERD digunakan untuk merepresentasikan entitas dan bagaimana relasi antar
16 entitas. Oleh karena itu, sangat disarankan menggunakan ERD untuk
membantu dalam pembuatan gambaran umum dari perancangan basis data
yang sedang dikembangkan.
b. Menentukan multiplicity constraint dari tipe relasi
Setelah mendapat relasi antar entitas, maka langkah berikutnya adalah
menentukan multiplicity setiap relasi. Jika memang ada suatu nilai yang
spesifik
dari
suatu
multiplicity
maka
akan
lebih
baik
apabila
didokumentasikan.
Multiplicity constraints digunakan untuk mengecek dan memelihara
kualitas data. Constraints ini menyatakan entity ocurrences yang dapat
dimasukkan ketika database di-update untuk menentukan apakah pengupdate-an tersebut melanggar aturan enterprise atau tidak. Suatu model yang
menyertakan
multiplicity
constraints
secara
eksplisit
lebih
merepresentasikan relasi semantik dan menghasilkan representasi yang lebih
baik untuk kebutuhan data enterprise.
c.
Mengecek Fan Traps dan Chasm Traps
Setelah relasi yang dibutuhkan antar entitas didefinisikan, maka langkah
berikutnya adalah mencek fan traps dan chasm traps. Definisi dari fan traps
adalah suatu model yang merepresentasikan suatu relasi antar entitas. Tetapi
alur relasinya memperlihatkan ambiguitas. Chasm traps adalah suatu model
dimana terdapat hubungan antar entitas yang satu dengan yang lain, tetapi
tidak ada relasi antar kedua entitas yang utama.
17 d. Mengecek setiap entitas mempunyai minimal sebuah relasi
Pada pembuatan ERD, pastikan setiap entitas mempunyai minimal satu
relasi dengan entitas yang lain. Jika memang setiap entitas sudah memiliki
minimal satu relasi dengan entitas yang lain, maka langkah berikutnya
adalah memperhatikan kamus data.
e.
Mendokumentasikan tipe relasi
Setelah tipe relasi diidentifikasi, langkah selanjutnya adalah memberi
nama yang mempunyai makna dan jelas kepada user. Selain itu, juga merecord deskripsi relasi dan multiplicity constraints pada kamus data.
Gambar 2.3 Contoh kamus data Relationship yang mendeskripsikan
relationship untuk staf user view dreamhome
Langkah 1.3 : Mengidentifikasi atribut pada tiap entitas
Tujuan dari langkah ini adalah untuk mengidentifikasi dan
mengasosiasikan atribut yang sesuai dengan tipe entitas atau tipe relasi.
Atribut dapat dibagi menjadi 3 yaitu :
a.
Simple atau Composite Atribut
Salah satu hal yang penting adalah perlunya memperhatikan apakah
suatu atribut tertentu adalah simple atau composite. Composite atribut adalah
18 atribut yang dibangun dari simple atribut. Sebagai contoh, atribut alamat bisa
saja dibuat simple dan menyimpan beberapa detail dari alamat sebagai suatu
nilai.
Contohnya,
‘115
Dumbarton
Road,
Glasgow,
G11
6YG’.
Bagaimanapun juga, atribut alamat dapat pula merepresentasikan sebuah
composite atribut, yang dibuat dari simple atribut dan terdiri dari beberapa
detail alamat yang mempunyai nilai terpisah pada atribut street (‘115
Dumbarton Road’), city (‘Glasgow’), dan postcode (‘G11 6YG’). Atribut
alamat dapat dijadikan simple atribut atau composite atribut tergantung
dengan kebutuhan user.
Apabila user tidak membutuhkan pengaksesan komponen terhadap
atribut alamat secara terpisah, seperti street, city, dan postcode, maka
sebaiknya atribut alamat itu dibuat sebagai simple atribut. Sedangkan,
apabila user membutuhkan pengaksesan terhadap komponen atribut alamat
secara individual, maka sebaiknya atribut alamat tersebut dibuat sebagai
composite atribut.
b. Single atau Multi-valued Atribut
Suatu atribut, selain dapat menjadi single atau composite, dapat pula
mempunyai satu atau lebih nilai, sebagai contohnya yaitu atribut nomor
telepon. Seseorang bisa saja mempunyai nomor telepon lebih dari satu,
keadaan seperti itu dapat disebut multi-valued atribut. Tetapi apabila atribut
tertentu hanya mempunyai satu nilai maka disebut single atribut.
19 c.
Derived Atribut
Derived atribut adalah atribut yang nilainya tergantung dengan nilai
atribut yang lain. Contoh, umur seorang staff, banyaknya properti yang
dikelola oleh seorang staff, dan pinjaman deposit yang dihitung dua kali
pada pinjaman bulanannya.
Langkah 1.4 : Menentukan domain atribut
Tujuan dari langkah ini adalah untuk menentukan domain dari atribut
yang ada di dalam model data konseptual lokal.
Contoh :
¾ Domain atribut dari nomor staff (staffNo) terdiri dari lima karakter
string dimana dua karakter awal berupa huruf, sedangkan tiga karakter
berikutnya berupa angka yang berkisar dari 1-999.
¾ Nilai yang mungkin untuk atribut sex adalah ‘M’ atau ‘F’. Domain dari
atribut ini adalah karakter string tunggal yang berisi nilai ‘M’ atau ‘F’.
Langkah 1.5 : Mengidentifikasi candidate key dan primary key tiap
atribut
Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key
dari setiap tipe entitas, dan jika memang terdapat lebih dari satu candidate
key, pilihlah salah satunya untuk menjadi primary key, dan yang lainnya
sebagai alternate key.
Pada saat memilih primary key diantara candidate key, gunakanlah
petunjuk berikut untuk membantu pemilihan :
¾ Merupakan candidate key dengan jumlah set atribut paling sedikit.
¾ Merupakan candidate key yang nilainya jarang sekali berubah.
20 ¾ Merupakan candidate key dengan jumlah karakter paling sedikit.
¾ Merupakan candidate key dengan nilai maksimalnya yang terkecil.
¾ Merupakan candidate key yang paling mudah digunakan dari sudut
pandang user.
Langkah 1.6 : Mempertimbangkan penggunaan konsep pemodelan
enhanced (langkah optional)
Tujuan
penggunaan
dari
langkah
konsep
ini
enhanced
adalah
untuk
modeling,
mempertimbangkan
seperti
specialization,
generalization, aggregation dan composition.
Langkah 1.7 : Mengecek model dari redundansi
Tujuan dari langkah ini adalah untuk mengecek apakah ada
redundansi
dalam
model
basis
data.
Adapun
langkah
untuk
menghilangkannya yaitu :
a. Menguji kembali relasi one-to-one (1:1);
b. Menghilangkan relasi redundansi;
c. Mempertimbangkan dimensi waktu.
Langkah 1.8 : Memvalidasi model konseptual lokal terhadap transaksi
user
Tujuan dari langkah ini adalah untuk memastikan bahwa model
konseptual lokal mendukung transaksi yang diperlukan oleh user. Pengujian
dilakukan dengan dua pendekatan yang mungkin untuk memastikan model
data konseptual mendukung transaksi yang diperlukan:
a. Mendeskripsikan transaksi;
b. Menggunakan jalur transaksi.
21 Langkah 1.9 : Me-review model data konseptual terhadap kebutuhan
user
Tujuan dari langkah ini adalah untuk me-review model data
konseptual lokal bersama user guna memastikan bahwa model yang ada
sudah merupakan representasi yang ‘benar’ dari kebutuhan data enterprise.
Sebelum mengakhiri langkah 1, perlu me-review model data
konseptual dengan user. Model data konseptual meliputi ER diagram dan
dokumentasi yang mendukung penggambaran model data. Jika terdapat
anomaly dalam model data, perlu dilakukan perubahan yang sesuai, yang
mungkin membutuhkan perulangan langkah sebelumnya. Proses ini
berlangsung terus sampai user siap untuk ‘sign off’’ model menjadi
representasi yang ‘benar’ sebagai bagian dari enterprise yang dimodelkan.
Hasil akhir dari perancangan basis data konseptual adalah
memproses pembuatan suatu model dari informasi yang akan digunakan di
dalam suatu organisasi, yang independensinya tidak tergantung pada apapun.
22 Gambar 2.4 Contoh ERD Konseptual (Connolly and Begg 2005, p457)
2.1.4.4.2 Perancangan Basis Data Logikal
Menurut Connolly and Begg (2005,p439), perancangan basis data
logikal
adalah proses membangun sebuah model data spesifik, tetapi
terlepas dari DBMS tertentu dan pertimbangan fisikal lainnya.
Menurut Connolly dan Begg (2005,p462), langkah-langkah dalam
perancangan basis data logikal adalah sebagai berikut :
23 Langkah 2 : Membangun dan Memvalidasi Model Data Logikal untuk
Setiap View
Tujuan dari langkah ini adalah untuk menerjemahkan model data
konseptual kedalam model data logikal dan kemudian memvalidasi model
tersebut untuk mengecek apakah secara struktur benar dan mendukung
transaksi yang dibutuhkan.
Langkah 2.1 : Menentukan relasi untuk model data logikal
Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk
model data logikal yang merepresentasikan suatu entitas, relasi dan juga
atribut yang telah diidentifikasi. Adapun pendeskripsian bagaimana relasi
dapat diturunkan dari struktur di bawah ini yang terjadi dalam model data
konseptual antara lain:
1.
Tipe entitas kuat (Strong Entity Type)
2.
Tipe entitas lemah (Weak Entity Type )
3.
Tipe relasi binary one-to-many (1:*)
4.
Tipe relasi binary one-to-one (1:1)
5.
Tipe relasi rekursif one-to-one (1:1)
6.
Tipe relasi superclass atau subclass
7.
Tipe relasi binary many-to-many
8.
Tipe relasi kompleks
9.
Atribut multi-valued
24 Langkah 2.2 : Memvalidasi relasi dengan menggunakan normalisasi
Tujuan dari langkah ini adalah untuk memvalidasi relasi model data
logikal dengan menggunakan teknik normalisasi. Tujuan dari normalisasi
adalah:
a.
Meminimalkan jumlah atribut yang perlu untuk mendukung kebutuhan
data dari suatu perusahaan.
b.
Atribut dengan relasi logikal yang dekat (digambarkan sebagai
functional dependency) yang ditemukan dalam relasi yang sama.
c.
Meminimalkan redundansi dengan tiap atribut direpresentasikan hanya
sekali dengan pengecualian atribut yang membentuk semua atau
sebagian foreign key yang penting untuk berpartisipasi dalam relasi yang
terhubung.
Langkah 2.3 : Memvalidasi relasi terhadap transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa relasi di
dalam model data logikal mendukung transaksi yang dibutuhkan, seperti
detail dalam spesifikasi kebutuhan user. Pada langkah ini, dilakukan
pengecekan bahwa relasi yang dibuat pada langkah sebelumnya juga
mendukung transaksi ini, dan karena itu dipastikan juga bahwa tidak ada
error dalam relasi yang telah dibuat.
Langkah 2.4 : Mengecek batasan integritas
Tujuan dari langkah ini adalah untuk mengecek batasan integritas
yang direpresentasikan dalam model data logikal. Batasan integritas
merupakan batasan yang diharapkan dapat menjaga basis data agar tidak
25 menjadi tidak lengkap (incomplete), tidak akurat (inaccurate), atau tidak
konsisten (inconsistent).
Dibawah ini terdapat enam tipe batasan integritas, antara lain :
a.
Data yang dibutuhkan;
b.
Batasan domain atribut;
c.
Multiplicity;
d.
Integritas entitas;
e.
Integritas referensial;
f.
Batasan umum.
Langkah 2.5 : Me-review model data logikal terhadap kebutuhan user
Tujuan dari langkah ini adalah untuk me-review model data logikal
dengan user untuk memastikan bahwa model tersebut sesuai dengan
representasi yang benar dari kebutuhan data perusahaan. Apabila user
merasa tidak puas dengan model tersebut maka dilakukan pengulangan
kembali langkah-langkah sebelumnya jika diperlukan.
Langkah 2.6 : Menggabungkan model data logikal kedalam model
global (langkah optional)
Tujuan dari langkah ini adalah untuk menggabungkan suatu model
data logikal lokal kedalam satu model data logikal global yang
merepresentasikan semua sudut pandang user terhadap basis data.
Pada langkah ini, hanya penting untuk rancangan basis data dengan
multiple user yang dikelola menggunakan pendekatan sudut pandang
integrasi. Untuk memfasilitasi gambaran proses penggabungan, digunakan
model data logikal lokal dan model data logikal global. Model data logikal
26 lokal merepresentasikan satu atau lebih tetapi tidak semua sudut pandang
user
terhadap basis data. Sedangkan
model
data
logikal
global
merepresentasikan semua sudut pandang user terhadap basis data. Dalam
langkah ini, dilakukan penggabungan dua atau lebih model data logikal lokal
kedalam satu model data logikal global. Aktivitas penggabungan tersebut
meliputi :
Langkah 2.6.1 : Penggabungan model data logikal lokal kedalam model
global
Tujuan dari langkah ini adalah untuk menggabungkan model data
logikal lokal kedalam satu model data logikal global. Beberapa tugas dari
pendekatan ini adalah sebagai berikut :
1.
Review nama dan isi dari suatu entitas atau relasi dan candidate key-nya.
2.
Me-review nama dan isi dari suatu relasi atau foreign key.
3.
Menggabungkan entitas atau relasi dari model data lokal.
4.
Memasukkan (tanpa penggabungan) entitas atau relasi yang unik untuk
setiap model data lokal.
5.
Menggabungkan relasi atau foreign key dari model data lokal.
6.
Memasukkan (tanpa penggabungan) relasi atau foreign key yang unik
untuk setiap model data lokal.
7.
Mengecek entitas atau relasi dan relasi atau foreign key yang hilang.
8.
Mengecek foreign key.
9.
Mengecek batasan integritas.
10. Menggambar ER global atau diagram relasi.
11. Meng-update dokumentasi. 27 Langkah 2.6.2 : Memvalidasi model data logikal global
Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat
dari model data logikal global dengan menggunakan teknik normalisasi dan
juga memastikan bahwa relasi yang dibuat mendukung transaksi yang
dibutuhkan, jika perlu.
Langkah 2.6.3 : Me-review model data logikal global dengan user
Tujuan dari langkah ini adalah untuk me-review model data logikal
global dengan user untuk memastikan bahwa model yang dibuat tersebut
merupakan representasi yang benar terhadap kebutuhan data perusahaan.
Langkah 2.7 : Mengecek kemungkinan pengembangan di masa depan
Tujuan dari langkah ini adalah untuk menentukan bagian mana yang
kelihatannya akan berubah ke masa depannya dan juga memperhatikan
supaya model data logikal dapat mengakomodasi perubahan tersebut.
Hasil akhir dari perancangan basis data logikal adalah merancang
suatu model informasi berdasarkan spesifik model yang ada (seperti model
relasional), tetapi tidak tergantung terhadap suatu DBMS dan perangkat
keras lainnya. Basis data logikal merancang suatu map untuk setiap lokal
konseptual data. Jika terdapat lebih dari satu pandangan user, maka model
data logikal lokal akan dikombinasikan menjadi suatu model data logikal
global yang merepresentasikan semua pandangan user dari suatu perusahaan.
28 Gambar 2.5 Contoh ERD Logikal (Connolly and Begg 2005, p489)
29 2.1.4.4.3 Perancangan Basis Data Fisikal
Menurut Connolly and begg (2005, p294), perancangan basis data
fisikal adalah suatu proses untuk mendeskripsikan pengimplementasian dari
suatu
basis
data
pada
media
penyimpanan
secondary,
dengan
mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan
untuk mencapai keefisienan dalam mengakses data, dan batasan integritas,
serta pengukuran keamanan apapun yang berhubungan.
Langkah 3 : Menerjemahkan Model Data Logikal sesuai DBMS yang
Dituju
Tujuan dari langkah ini adalah untuk membuat suatu skema basis
data relasional dari model data logikal yang dapat diimplementasikan ke
DBMS yang dituju.
Langkah 3.1 : Merancang relasi dasar
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan relasi dasar yang diidentifikasi dalam model data logikal
pada DBMS yang dituju.
Untuk memulai proses perancangan basis data fisikal, pertama-tama
dapat dilakukan dengan menyatukan dan mengasimilasikan informasi
mengenai relasi yang dirancang selama perancangan basis data logikal.
Informasi yang diperlukan dapat berasal dari kamus data dan definisi relasi
yang didefinisikan menggunakan Database Design Language (DDL). Untuk
setiap relasi yang diidentifikasi pada model data logikal, dapat didefinisikan
berisi :
30 a.
Nama relasi;
b.
Daftar simple atribut dalam tanda kurung;
c.
Primary key (PK), alternate key (AK), dan foreign key (FK);
d.
Batasan
integritas
referensial
untuk
setiap
foreign
key
yang
diidentifikasi;
e.
Dari kamus data, dari setiap atributnya dapat diketahui;
f.
Domain atribut tersebut yang terdiri dari tipe data, panjang, dan
berbagai constraint pada domain tersebut;
g.
Suatu optional nilai default untuk atribut;
h.
Apakah atribut dapat diisi dengan nilai null;
i.
Apakah atribut dapat diturunkan dan jika demikian bagaimana
perhitungannya.
Gambar 2.6 Contoh DBDL untuk relasi PropertyForRent
(Connolly and Begg 2005, p499)
31 Langkah 3.2 : Merancang representasi data turunan (derived data)
Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan suatu data turunan yang terdapat pada model data logikal
pada DBMS yang dituju.
Atribut yang nilainya didapatkan dengan mengevaluasi atribut lain
dikenal sebagai atribut turunan atau atrribut kalkulasi. Sebagai contoh :
a.
Jumlah staf yang bekerja pada suatu cabang (branch).
b.
Total gaji bulanan untuk semua staf.
c.
Jumlah properti yang di-handle oleh anggota staf.
Gambar 2.7 Contoh Relasi PropertyForRent dan staff dengan atribut
turunan noOfProperties (Connolly and Begg 2005,p500)
32 Langkah 3.3 : Merancang general constraint
Tujuan dari langkah ini adalah untuk merancang kendala umum
untuk DBMS yang dituju. Meng-update suatu relasi yang mungkin dibatasi
oleh batasan integritas yang mengatur transaksi ‘real world’ yang
direpresentasikan oleh peng-update-an tersebut. Perancangan batasan
tersebut sekali lagi tergantung pada DBMS yang dipilih. Beberapa sistem
menyediakan
fasilitas-fasilitas
dibandingkan
yang
lainnya
untuk
mendefinisikan kendala umum. Seperti langkah sebelumnya, jika sistem
tersebut mempunyai aturan sesuai aturan standar SQL, beberapa batasan
dapat diterapkan.
CONSTRAINT StaffNotHandlingTooMuch
CHECK (NOT EXISTS (SELECT staffNo
FROM PropertyForRent
GROUP BY staffNo
HAVING COUNT(*) > 100))
Langkah 4 : Merancang Organisasi File dan Indeks
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk
mencapai kinerja yang diharapkan. Karena itu, cara dimana relasi dan tuples
yang ada akan disimpan pada penyimpanan secondary.
Langkah 4.1 : Menganalisis transaksi
Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari
suatu transaksi dimana akan dijalankan pada basis data untuk menganalisis
transaksi yang penting.
33 Gambar 2.8 Contoh Analisis Transaksi Pada Relasi
(Connolly and Begg 2005, p504)
Langkah 4.2 : Memilih organisasi file
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
efisien untuk setiap relasi dasar. Beberapa organisasi file efisien untuk bulk
loading data kedalam basis data tetapi setelah itu tidak efisien. Dengan kata
lain, kita ingin menggunakan struktur penyimpanan yang efisien untuk
mengeset basis data dan kemudian mengubahnya untuk penggunaan
operasional normal.
Karena itu, tujuan dari langkah ini adalah untuk memilih organisasi
file
yang
optimal
untuk
tiap
relasi,
jika
DBMS
yang
dituju
memperbolehkannya. Dalam banyak kasus yang ada, suatu relasional DBMS
akan memberikan sedikit bahkan tanpa pilihan dalam memilih organisasi
file, walaupun beberapa akan mempunyai indeks yang spesifik.
34 Beberapa macam organisasi file yang ada adalah sebagai berikut :
a.
Heap
b.
Hash
c.
Indexed Sequential Office Access Method (ISAM)
d.
B*-three
e.
Clusters.
Jika DBMS yang dituju tidak memperbolehkan adanya pemilihan
organisasi file, maka langkah ini dapat dihilangkan.
Langkah 4.3 : Memilih indeks
Tujuan dari langkah ini adalah untuk menentukan apakah dengan
adanya penambahan indeks akan meningkatkan kinerja dari suatu sistem.
Salah satu pendekatan untuk memilih organisasi file yang sesuai
untuk relasi yaitu menjaga agar tuple tidak berurutan dan membuat indeks
secondary sebanyak mungkin. Pendekatan lainnya yaitu untuk mengurutkan
tuple dalam relasi dengan menspesifikasi primary atau clustering indeks.
Dalam kasus ini, biasanya pemilihan suatu atribut untuk pengurutan atau
clustering pada tuple adalah sebagai berikut :
a.
Suatu atribut yang digunakan paling sering untuk operasi penggabungan
(join), yang akan membuat operasi penggabungan itu lebih efisien.
b.
Suatu atribut yang digunakan paling sering untuk mengakses suatu tuple
didalam relasi yang ada.
Apabila pengurutan atribut yang dipilih adalah kunci dari relasi,
indeks tersebut akan menjadi primary index. Sedangkan jika pengurutan
atribut yang dipilih bukan merupakan kunci dari relasi, indeks tersebut akan
35 menjadi clustering index. Setiap relasi hanya dapat mempunyai primary
index atau clustering index.
Langkah 4.4 : Mengestimasi kapasitas penyimpanan
Tujuan dari langkah ini adalah untuk mengestimasi jumlah kapasitas
disk yang akan dibutuhkan oleh basis data dalam mendukung implementasi
basis data pada penyimpanan secondary.
Seperti pada langkah sebelumnya, mengestimasi penggunaan disk
sangat bergantung pada DBMS yang dituju dan perangkat lunak yang
digunakan untuk mendukung basis data. Secara umum estimasi tersebut
dilakukan berdasarkan ukuran tiap tuple dan jumlah tuple dalam relasi.
Langkah 5 : Merancang Tampilan untuk User
Tujuan dari langkah ini adalah untuk merancang tampilan user yang
diidentifikasi selama tahap pengumpulan dan analisis kebutuhan pada Siklus
Hidup Pengembangan Sistem Basis Data.
Langkah 6 : Merancang Mekanisme Keamanan
Tujuan dari langkah ini adalah untuk merancang mekanisme
keamanan untuk basis data seperti yang telah dispesifikasikan user selama
tahap
analisis
dan
pengumpulan
kebutuhan
pada
Siklus
Hidup
Pengembangan Sistem Basis Data.
Selama tahap analisis dan pengumpulan kebutuhan pada Siklus
Hidup Pengembangan Sistem Basis Data, kebutuhan keamanan yang
spesifik harus didokumentasikan dalam spesifikasi kebutuhan sistem.
Sasaran dari tahap ini adalah untuk memutuskan bagaimana kebutuhan
keamanan ini akan direalisasikan. Beberapa sistem menawarkan fasilitas
36 keamanan yang berbeda dari sistem yang lainnya. Sekali lagi, perancang
basis data harus hati-hati terhadap fasilitas yang ditawarkan oleh DBMS
yang dituju. Relasional DBMS biasanya menyediakan dua macam
keamanan basis data antara lain :
a.
Keamanan sistem
b.
Keamanan data
Keamanan sistem menutupi pengaksesan dan penggunaan basis
data pada tingkat sistem, seperti username dan password. Sedangkan
keamanan data menutupi pengaksesan dan penggunaan objek basis data
(seperti relasi dan views) dan tindakan dimana user dapat memperoleh
objek tersebut.
Definisi dari keamanan basis data adalah suatu mekanisme yang
memproteksi basis data dari suatu kejadian baik yang disengaja maupun
tidak. Suatu basis data merupakan sumber dari perusahaan yang essential
yang perlu dilindungi dengan menggunakan suatu kontrol yang memadai.
Beberapa issue keamanan yang perlu diperhatikan :
a. Pencurian data (Theft and Fraud)
b. Kehilangan kerahasiaan data (Loss of Confidentially)
c. Kehilangan hak pribadi (Loss of Privacy)
d. Kehilangan integritas (Loss of integrity)
e. Kehilangan ketersediaan data (Loss of availability)
Hasil akhir perancangan fisikal basis data adalah suatu proses yang
mendeskripsikan suatu implementasi dari suatu basis data pada media
penyimpanan. Hal ini mendeskripsikan suatu relational dan struktur
37 penyimpanan dan metodologi pengaksesan data oleh user yang efisien,
selama batasan integritas dan pengukuran keamanan.
2.1.4.5 Pemilihan DBMS
Menurut Connoly dan Begg (2005, p288), DBMS Selection (optional)
adalah meyeleksi DBMS yang sesuai untuk mendukung aplikasi basis data.
Pemilihan DBMS dilakukan antara tahapan logical database design dan
conceptual database design. Tujuan dari pemilihan DBMS adalah untuk
kecukupan sekarang dan kebutuhan masa mendatang pada perusahaan,
membuat keseimbangan biaya termasuk pembelian produk DBMS, piranti
lunak atau perangkat keras lainnya untuk mendukung aplikasi basis data, biaya
yang berhubungan dengan perubahan dan pelatihan pegawai. Pendekatan
sederhana dalam pemilihan DBMS adalah memeriksa keistimewaan DBMS
dalam memenuhi kebutuhan. Dalam memilih produk DBMS baru, ini adalah
kesempatan untuk memastikan bahwa proses pemilihan sudah direncanakan
dan hasil yang diberikan sistem benar-benar bermanfaat bagi perusahan.
2.1.4.6 Perancangan Aplikasi
Menurut Connoly dan Begg (2005, p299), Applicattion Design adalah
perancangan antarmuka pengguna dan program aplikasi yang menggunakan
dan memproses sistem basis data. Perancangan basis data dan perancangan
aplikasi adalah aktivitas yang dilakukan secara bersamaan pada database
application lifecycle. Dalam kasus sebenarnya, tidak mungkin dapat
menyelesaikan perancangan aplikasi sebelum perancangan basis data selesai.
38 Dalam perancangan aplikasi harus memastikan semua pernyataan
fungsional dari spesifikasi kebutuhan pemakai (user requirement specification)
yang menyangkut perancangan aplikasi program yang mengakseskan basis data
dan merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap
isi basis data. Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan
merancang antarmuka pemakai yang tepat. Antarmuka dirancang harus
memberikan informasi yang dibutuhkan dengan cara menciptakan ‘userfriendly’.
2.1.4.7 Prototyping (Optional)
Menurut Connoly dan Begg (2005, p304), Prototyping adalah
pembuatan model kerja dari sistem basis data, yang mengizinkan perancangan
maupun pengguna untuk mengevaluasi hasil akhir sistem. Tujuan dari
pengembangan prototype aplikasi basis data adalah memungkinkan pengguna
menggunakan prototype untuk mengidentifikasi kelebihan atau kekurangan
sistem dan memungkinkan perancang untuk memperbaiki atau melengkapi
kelebihan dari aplikasi basis data baru.
Ada dua strategi prototyping yang umum digunakan yaitu requirement
prototyping dan evolutionary prototyping. Requirement prototyping yaitu
menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basis
data dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau
dibuang. Sedangkan evolutionary prototype menggunakan tujuan yang sama,
tetapi perbedaannya adalah prototype tetap digunakan.
39 2.1.4.8 Implementation
Menurut Connoly dan Begg (2005, p304), Implementation adalah
realisasi secara fisik dari basis data dan rancangan aplikasi. Implementasi basis
data dicapai menggunakan Data Definition Language (DDL) dari DBMS yang
terpilih atau Graphical User Interface (GUI).
2.1.4.9 Data Convertion and Loading
Menurut Connoly dan Begg (2005, p305), Data Convertion and
Loading adalah proses mengirim data dari sistem yang lama ke sistem yang
baru dan jika mungkin, mengkonversikan aplikasi yang ada untuk dijalankan
pada sistem basis data yang baru.
Tahap ini dibutuhkan ketika sistem basis data menggantikan sistem
yang lama. Pada masa sekarang, umumnya DBMS memiliki kegunaan untuk
memasukkan file ke dalam basis data baru. Biasanya membutuhkan spesifikasi
dari sumber file dan sasaran basis datanya. Kegunaan ini memungkinkan
pengembangan untuk mengkonversikan dan menggunakan aplikasi program
lama untuk digunakan oleh sistem baru. Ketika conversion and loading
dibutuhkan prosesnya harus direncanakan untuk memastikan kelancaran
transaksi dari keseluruhan operasi.
2.1.4.10 Testing
Menurut Connoly dan Begg (2005, p305), Testing adalah proses
mengeksekusi program dengan tujuan mencari kesalahan (error). Sebelum
digunakan, aplikasi basis data yang baru dikembangkan harus diuji secara
menyeluruh. Untuk mencapainya harus hati-hati dalam menggunakan
40 perancangan strategi uji dan menggunakan data asli untuk proses pengujian.
Didalam definisi ini tidak menggunakan pandangan yang biasa, testing adalah
proses demonstrasi tanpa kesalahan. Dalam kenyataan testing tidak luput dari
kesalahan, maka pengujian akan menemukan kesalahan pada program aplikasi
dan mungkin struktur basis datanya.
Di dalam merancang basis data, pemakai menggunakan sistem baru
seharusnya terlibat didalam proses testing. Situasi yang ideal untuk melakukan
uji sistem adalah menguji basis data pada perangkat keras yang berbeda, tetapi
hal ini sering tidak dilakukan. Jika data yang asli digunakan, perlu backup
untuk mengantisipasi kesalahan.
2.1.4.11 Operational Maintenance
Menurut Connoly dan Begg (2005, p306), Operational Maintance
adalah proses memonitor dan menjaga sistem setelah dilakukan instalasi. Yang
termasuk aktivitas dari tahapan pemeliharaan adalah sebagai berikut :
a. Memantau kinerja dari sistem. Jika kinerjanya menurun dibawah level yang
dapat diterima, mungkin basis data perlu diperbaiki.
b. Memelihara dan meng-upgrade sistem basis datanya (jika diperlukan).
2.1.5 Entity-Relationship Modelling (ER Modelling)
Model Entity-Relationship merupakan salah satu model yang dapat
memastikan
pemahaman
yang
tepat
terhadap
data
dan
bagaimana
penggunaannya di dalam suatu organisasi (Connolly, 2005, p342). Model ini
dimulai dengan identifikasi entitas dan relationship antar data yang harus
41 direpresentasikan di dalam model, dan kemudian ditambahkan atribut dan
setiap constraint pada entitas, relationship, dan atributnya.
Simbol – simbol ERD :
1. Entitas
Entitas adalah suatu objek yang dapat diidentifikasi dalam lingkungan
pemakai.
Simbol yang digunakan adalah :
2. Relasi
Relasi menunjukkan adanya hubungan di antara sejumlah entitas yang
berbeda.
Simbol yang digunakan adalah :
3. Garis
Garis sebagai penghubung antara relasi dengan entitas, relasi dan entitas
dengan atribut.
Simbol yang digunakan adalah :
4. Atribut
Atribut berfungsi mendeskripsikan karakter entitas (atribut yang berfungsi
sebagai key diberi garis bawah).
Simbol yang digunakan adalah :
42 Beberapa konsep dasar dalam model E-R yaitu :
2.1.5.1 Tipe Entitas
Tipe entitas adalah sekumpulan objek yang memiliki properti yang
sama, yang diidentifikasikan ke dalam organisasi karena keberadaannya yang
bebas (independent existance) (Connolly, 2005, p343). Sedangkan entity
occurance adalah sebuah objek dari suatu tipe entitas yang dapat
diidentifikasikan secara unik (Connolly, 2005, p345).
Keberadaan objek-objeknya secara fisik atau nyata (physical existance)
seperti entitas pegawai, rumah, dan pelanggan, atau secara konseptual atau
abstrak (conceptual existance) seperti entitas penjualan, pembelian, dan
peminjaman.
Setiap tipe entitas dilambangkan dengan sebuah persegi panjang yang
diberi nama dari entitas tersebut. Nama tipe entitas biasanya adalah kata benda
tunggal. Huruf pertama dari setiap kata pada nama tipe entitas ditulis dengan
huruf besar.
Gambar 2.9 Contoh Tipe Entitas (Connolly and Begg, 2005, p345)
43 Tipe entitas dapat diklasifikasikan menjadi:
a. Tipe Entitas Kuat, yaitu tipe entitas yang keberadaannya tidak tergantung
pada tipe entitas lainnya (Connolly, 2005, p354).
b. Tipe Entitas Lemah, yaitu tipe entitas yang keberadaannya bergantung pada
tipe entitas lainnya (Connolly, 2005, p355).
Gambar 2.10 Contoh Representasi Diagram Tipe Entitas Kuat dan Entitas
Lemah (Connolly and Begg 2005, p355)
2.1.5.2 Tipe Relasi
Tipe relasi adalah sekumpulan hubungan antar tipe entitas yang memiliki
arti (Connolly, 2005, p346). Sekumpulan relationship occurrence adalah sebuah
hubungan yang dapat diidentifikasikan secara unik, yang meliputi sebuah kejadian
(occurrence) dari setiap tipe entitas di dalam relasi (Connolly, 2005, p346).
Tipe relasi digambarkan dengan sebuah garis yang menghubungkan
entitas-entitas yang saling berhubungan. Garis tersebut diberi nama sesuai dengan
nama hubungannya dan diberi tanda panah satu arah disamping nama
hubungannya.
44 Biasanya sebuah relasi dinamakan dengan menggunakan kata kerja, seperti
Mengatur, atau dengan sebuah frame singkat yang meliputi sebuah kata kerja,
seperti DisewaOleh, sedangkan tanda panah ditempatkan di bawah nama relasi
yang mengindikasikan arah bagi pembaca untuk mengartikan nama dari suatu
relasi. Huruf pertama dari setiap kata pada suatu relasi ditulis dengan huruf besar.
Gambar 2.11 Contoh Representasi Diagram dari Tipe Relasi
(Connolly and Begg 2005,p347)
Tipe-tipe relasi yaitu :
a. One-to-one Relationship
Gambar di bawah ini menggambarkan relationship one-to-one antara entitas
Staff dan entitas Branch, dimana satu orang staff hanya mengontrol satu
cabang dan satu cabang hanya dikontrol oleh satu orang staff.
Gambar 2.12 Contoh Semantic Net Menunjukkan Dua Occurence dari
Relasi Pegawai Mengatur Cabang (Connolly and Begg 2005, p357)
45 b. One-to-many Relationship
Gambar berikut ini menggambarkan relationship one-to-many yang sering
terjadi antara entitas Staff dengan entitas Properti, dimana dalam relasi ini
seorang staff memungkinkan untuk mengurus
(oversees) lebih dari satu
properti, sedangkan satu properti hanya dapat diurus oleh satu staff.
Gambar 2.13 Contoh Semantic Net Menunjukkan tiga occurrence dari relasi
Pegawai Melihat Rumah Sewa (Sumber : Connolly and Begg 2005, p358)
c. Many-to-many Relationship
Gambar di bawah ini menggambarkan relationship many-to-many yang terjadi
diantara entitas Newspaper dengan entitas Property, dimana satu property
dapat dipasarkan (advertise) pada lebih dari satu koran, begitu juga satu buah
koran dapat memasarkan lebih dari satu property.
46 Gambar 2.14 Contoh Semantic net menunjukkan empat occurence dari relasi
Koran Mengiklankan RumahSewa (Sumber : Connolly and Begg 2005, p360)
2.1.5.3 Tipe Atribut
Adapun tipe-tipe atribut sebagai berikut:
a. Single valued attribute
Atribut yang hanya memiliki sebuah nilai untuk setiap occurrence dari
sebuah entitas (Connolly, 2005, p351).
b. Multi valued attribute
Atribut yang memiliki banyak nilai untuk setiap occurrence dari sebuah
entitas (Connolly, 2005, p352).
c. Derived attribute
Atribut yang nilai-nilainya diperoleh dari pengolahan atau diturunkan dari
atribut lain yang berhubungan (Connolly, 2005, p352).
47 2.1.5.4 Keys
Candidate key adalah himpunan atribut minimal yang secara unik
mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly, 2005,
352).
Composite key adalah sebuah candidate key yang terdiri atas dua atau
lebih atribut (Connolly, 2005, p353).
Primary key adalah candidate key yang terpilih untuk
mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas
(Connolly, 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 (Connolly, 2005, p79).
Foreign key adalah sebuah primary key pada sebuah entitas yang
digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship
(Connolly, 2005, p79).
48 Gambar 2.15 Representasi Diagram Entitas Pegawai dan Cabang Beserta
Atribut dan Primary Key-nya (Connolly and Begg 2005, p354)
2.1.6
Normalisasi
Menurut Connolly dan Begg (2005, p388), Normalisasi adalah sebuah
teknik untuk menghasilkan kumpulan relasi atau hubungan dengan propertiproperti yang diinginkan, yang memberikan kebutuhan data dari suatu
perusahaan. Karakteristik dari kumpulan relasi yang cocok harus meliputi :
1. Meminimalisasi jumlah atribut yang dibutuhkan untuk mendukung
kebutuhan data perusahaan.
2. Atribut dengan relasi logikal yang berdekatan ditemukan pada relasi yang
sama.
3. Meminimalisasi redudansi dengan setiap atribut direpresentasikan hanya
sekali dengan pengecualian untuk atribut yang membentuk semua atau
sebagian dari foreign key.
49 2.1.6.1 Bentuk Normal Pertama (First Normal Form / 1NF)
Unnormalized form (UNF), sebuah tabel yang berisi satu atau lebih
kelompok yang berulang (repeating group). Yang dimaksud kelompok
yang berulang itu adalah atribut-atribut yang multivalued.
Normalisasi
pertama (1NF), menghilangkan perulangan. Sebuah relasi dimana setiap
baris dan kolom berisi satu nilai saja. Bentuk normal pertama ini, dicapai
apabila setiap nilai atribut adalah tunggal. Kondisi ini dapat diperoleh
dengan melakukan eliminasi terhadap terjadinya data ganda (repeating
groups). Pada kondisi normal pertama ini kemungkinan masih terjadi
adanya data rangkap.
2.1.6.2 Bentuk Normal Kedua (Second Normal Form / 2NF)
Menurut Connolly dan Begg (2005, p407) aturan normalisasi kedua
(2NF) dapat dikatakan bahwa sebuah relasi dalam bentuk 1NF dan setiap
atribut bukan primary key. Normalisasi dari 1NF ke 2NF melibatkan
penghapusan ketergantungan parsial.
2.1.6.3 Bentuk Normal Ketiga (Third Normal Form / 3NF)
Menurut Connolly dan Begg (2005, 409), aturan normalisasi ketiga
(3NF) adalah sebuah relasi dalam bentuk 1NF dan 2NF dimana tidak ada
ketergantungan transitif antara atribut non-primary key dengan primary
key.
50 2.1.6.4 Bentuk Normal Boyce-Codd (Boyce-CoddNormal Form/ BCNF)
Menurut Connolly dan Begg (2005, p419) aturan normalisasi boycecodd (BCNF) adalah sebuah relasi jika dan hanya jika setiap determinan adalah
candidate key.
2.1.7
Data Flow Diagram (DFD)
Menurut McLeod (2001,p401), Data Flow Diagram (DFD) adalah
representasi grafis dari sistem yang menggunakan sejumlah simbol-simbol
untuk mengilustrasikan bagaimana aliran data melewati proses-proses yang
saling berhubungan.
2.1.7.1 Simbol dalam DFD
Gambar aliran data sebagai modeling tool dengan menggunakan
pendekatan metode analisis sistem terstruktur. DFD dapat digunakan untuk
mempresentasikan suatu sistem yang otomatis maupun manual dengan DFD
menggunakan simbol :
1) Entitas Eksternal (Terminal)
Entitas yang berada diluar sistem , yang memberikan data kepada sistem
(source) atau yang menerima informasi dari sistem (sink). Entitas eksternal
tidak termasuk dalam sistem.
Simbol yang digunakan :
51 2) Proses
Menggambarkan apa yang dilakukan oleh sistem. Proses berfungsi untuk
mentransformasikan suatu atau beberapa data masukkan menjadi satu atau
beberapa data keluaran sesuai dengan spesifikasi yang digunakan. Setiap
proses memliki satu atau beberapa data masukkan serta menghasilkan satu
atau beberapa data keluaran. Proses sering juga disebut bubble.
Simbol yang digunakan :
3) Data Flow
Menggambarkan aliran data dari suatu entitas ke entitas lainnya. Tanda
panah menggambarkan aliran data yang terjadi bisa antara dua proses yang
berurutan, dari data store ke process atau sebaliknya dari process ke sink.
Simbol yang digunakan :
4) Data Store
Data store berfungsi untuk sebagai tempat penyimpanan data. Yaitu proses
dapat mengambil data atau memberikan data ke data store.
Simbol yang digunakan :
52 2.1.7.2 Tingkatan pada DFD
Dalam Data Flow Diagram memiliki beberapa tingkatan. Tingkatan ini
untuk menjelaskan diagram-diagram agar terlihat lebih jelas dan rinci.
Tingkatan-tingkatan dalam DFD dijelaskan dibawah ini:
1. Diagram Konteks
Menggambarkan seluruh input ke atau output ke sistem. Diagram konteks
ini merupakan level tertinggi dari DFD.
Gambar 2.16 Contoh Diagram Konteks
53 2. Diagram Nol
Menggambarkan proses-proses penting yang ada pada sistem yang
dianalisis dan yang akan dibuat.
Gambar 2.17 Contoh Diagram Nol
54 3.
Diagram Rinci
Menggambarkan proses-proses yang lebih rinci dari diagram nol mengenai
sistem yang dianalisis dan yang akan dirancang.
Gambar 2.18 Contoh Diagram Rinci
55 2.1.8
Microsoft SQL Server 2008
Menurut Ross Mistry (2009), SQL SERVER 2008 adalah platform
database organisasi terpercaya yang menyediakan keunggulan kompetitif
dengan memungkinkan pengguna untuk mendapatkan hasil yang lebih cepat
dan dengan demikian membuat keputusan bisnis yang lebih baik.
2.1.9
Microsoft Visual Basic
Microsoft Visual Basic merupakan sebuah bahasa pemrograman yang
menawarkan Integrated Development Environment (IDE) visual untuk
membuat program perangkat lunak berbasis sistem operasi Microsoft Windows
dengan menggunakan model pemrograman (COM), Visual Basic merupakan
turunan bahasa pemrograman BASIC dan menawarkan pengembangan
perangkat lunak komputer berbasis grafik dengan cepat. Beberapa bahasa skrip
seperti Visual Basic for Applications (VBA) dan Visual Basic Scripting
Edition (VBScript), mirip seperti halnya Visual Basic, tetapi cara kerjanya
yang berbeda. Para programmer dapat membangun aplikasi dengan
menggunakan komponen-komponen yang disediakan oleh Microsoft Visual
Basic Program-program yang ditulis dengan Visual Basic juga dapat
menggunakan Windows API, tapi membutuhkan deklarasi fungsi luar
tambahan. Dalam pemrograman untuk bisnis, Visual Basic memiliki pangsa
pasar yang sangat luas.
Menurut Burrows (2000, p7), Visual Basic (VB) adalah sebuah
program yang didesain khusus untuk memfasilitasi kebutuhan programmer
dalam pengembangan sebuah program baru. Visual Basic menyediakan dua hal
56 untuk digunakan oleh programmer, yaitu programming tools yang digunakan
oleh programmer untuk menentukan komponen-komponen didalam program
yang sedang dibuat, dan programming language yang memungkinkan
programmer untuk membuat perintah-perintah untuk dikerjakan oleh program
yang sedang dibuat.
2.2
Teori Khusus
Dalam teori khusus, kami membahas semua hal yang berhubungan
dengan topik skripsi yang meliputi pengertian logistik dan pengertian pengadaan
yang akan dijelaskan secara ringkas seperti di bawah ini.
2.2.1 Pengertian Logistik
Logistik telah dikenal di kalangan masyarakat luas baik dalam
lingkungan masyarakat luas baik dalam lingkungan lembaga-lembaga maupun
instansi, yang biasanya menggunakan istilah-istilah yang berbeda, misalnya :
a. Biro Material
b. Biro Pembekalan
c. Biro Pemeliharaan
d. Biro Pengadaan
Pengertian logistik menurut H. Subagya M. Suganda pada hakekatnya
mencakup tiga pengetahuan dasar, yaitu :
1. Luas ruang lingkup (scope) yang mencakup segi-segi khusus tertentu
adminstrasi militer.
57 2. Kedudukannya disamping sejajar dengan ilmu strategi dan ilmu taktik,
logistik juga merupakan kegiatan utama ketiga dari seni militer (the third
major branch of the military art).
3. Arti asalnya, pandai dalam mengadakan atau merumuskan perkiraanperkiraan. (Suganda, Manajemen Logistik, 1988 : 8)
Maka dapat ditarik kesimpulan, bahwa logistik merupakan suatu ilmu
pengetahuan atau seni serta proses mengenai perencaanaan dan penentuan
kebutuhan, pengadaan, penyimpanan, penyaluran dan pemeliharaan serta
penghapusan material-material atau alat-alat.
2.2.2
Pengertian Pengadaan
Menurut Keputusan Presiden No. 80 tahun 2003, BAB 1, pasal 1,
Pengadaan barang pemerintah adalah kegiatan pengadaan barang yang dibiayai
dengan APBN/APBD baik yang dilaksanakan sendiri oleh pengguna barang
atau pihak lain.