8
BAB 2
LANDASAN TEORI
2.1 Pendekatan Basis data
2.1.1 Definisi Basis data
Menurut Connolly and Begg (2005, p15), “Database is a shared collection of
logically related data, and a description of this data, designed to meet the information
needs of an organization”, artinya Basis data merupakan kumpulan data yang
berhubungan secara logik, dan gambaran data tersebut dirancang untuk memenuhi
kebutuhan informasi suatu perusahaan.
Menurut W. H. Inmon (2002, p388), “Database is a collection of interrelated data
stored (often with controlled, limited redudancy) according to a schema, a database can
serve single or multiple applications”, yang artinya Basis data adalah koleksi data yang
saling berkaitan (Seringkali dengan dikontrol, dengan dibatasi redudansi) sesuai dengan
skemanya, Basis data dapat melayani satu atau banyak aplikasi.
Menurut C.J Date (1999,p5), Suatu sistem Basis data adalah suatu sistem yang
pada dasarnya menyimpan record – record di dalam suatu sistem yang dilakukan secara
komputerisasi yang tujuannya secara keseluruhan adalah untuk memelihara informasi
dan untuk membuat informasi tersebut tersedia berdasarkan permintaan.
Jadi, Basis data merupakan kumpulan data yang saling berhubungan secara logik
yang terdiri dari record – record di dalam suatu sistem yang dilakukan secara
komputerisasi yang tujuannya secara keseluruhan adalah untuk memelihara informasi
dan melayani satu atau lebih aplikasi untuk memenuhi kebutuhan informasi suatu
perusahaan.
9
2.1.2 Database Management System (DBMS)
Menurut Connoly dan Begg (2005, p16), Database Management System (DBMS)
merupakan suatu sistem piranti lunak yang membuat pemakain dapat mendefinisikan,
menciptakan, mengatur, dan mengontrol akses kedalam basis data.
DBMS menyediakan beberapa fasilitas fsfsebagai berikut :
Memperoleh user untuk mendefinisikan data, membuat spesifikasi tipe data, dan
constraint pada data yang akan disimpan dalam basis data. Biasanya menggunakan
Data Definition Language (DDL). Constraint adalah peraturan konsistensi nilai pada
basis data yang tidak dapat dilanggar.
Memperbolehkan user untuk menambah data, mengubah data, menghapus data, dan
mengambil data dari basis data. Biasanya menggunakan Data Manipulation language
(DML). Bahasa yang umum digunakan adalah Structured Query Language (SQL).
Menyediakan fungsi-fungsi yang mengontrol akses basis data:
a. Sistem keamanan (security system), mencegah user yang tidak berwenang agar
tidak mengakses ke basis data.
b. Sistem integritas (Integrity system),menjaga konsitensi data yang disimpan.
c. Sistem control (Concurency control), mengijinkan agar data dapat dipakai
bersama-sama oleh user lainnya.
d. Sistem kontol perbaikan (Recovery control system), memperbaiki atau
mengembalikan basis data ke kondisi sebelumnya jika terjadi kerusakan pada
perangkat kerasa dan perangkar lunak.
10
e. Catalog yang dapat diakses user (User- accessible catalog), catatan yang berisi
deskripsi data pada basis data.
Menurut Raghu Ramakrishnan dan Johannes Gehrke (2003, p4), DBMS adalah
piranti lunak yang dirancang untuk membantu dalam memelihara dan memanfaatkan
kumpulan data dalam jumlah besar, dan kebutuhan untuk system maupun pemakaiannya
yang berkembang dengan cepat.
Menurut Gerald V.Post (2005, p2), DBMS adalah piranti lunak yang
mendefinisikan sebuah basis data, menyimpan data, mendukung bahasa query, membuat
laporan dan menciptakan layer masuk data.
Menurut Connoly dan Begg (2005, p17), Database Application program adalah
suatu program komputer yang berinteraksi dengan database sesuai dengan permintaan
DBMS.
2.1.2.1 Komponen Database management System (DBMS)
Menurut Connoly dan Begg (2005, p18), Komponen Lingkungan DBMS antara
lain :
1. Perangkat Keras (hardware)
Perangkat keras berupa komputer tunggal personal, mainframe tunggal, hingga
jaringan komputer. Perangkat keras dapat tergantung pada kebutuhan perusahaan dan
DBMS yang digunakan.
2. Perangkat Lunak (software)
Program aplikasi yang digunakan biasanya adalah 3rd
GL (third generation
language), seperti C, C++, Java, Visual Basic, COBOL, Fortan, Ada, Pascal, atau
11
bahkan 4th
GL (fourth generation language) seperti SQL yang digabungkan pada 3rd
GL.
3. Data
Data merupakan komponen yang paling penting dari lingkungan DBMS. Data
berperan sebagai penghubung antara komponen mesin dengan komponen manusia.
4. Prosedur (procedure)
Prosedur mengandung intruksi dan peraturan yang mengatur rancangan dan kegunaan
basis data, seperti bagamana masuk kedalam DBMS, menjalankan dan menghentikan
DBMS, dan bagaimana membuat cadangan dari basis data.
5. Manusia (people)
Manusia merupakan komponen terakhir yang terlibat langsung dengan sitem,
termasuk didalamnya adalah Database Administrator (DBA), perancangan basis data,
pengembangan aplikasi dan pemakainan akhir.
2.1.2.2 Keuntungan Database management System (DBMS)
Menurut Connoly dan Begg (2005, p26), Keuntungan DBMS antara lain :
1. Kontrol redundansi data
2. Pendekatan basis data berusaha menghapus redundansi dengan menggabungkan file
sehingga data yang sama tidak akan disimpan kembali. Bagaimanapun, pendekatan
basis tidak menghapus rendudansi secara keseluruhan, tetapi mengontol jumlah
redundasi yang terdapat pada database. Pada waktu yang berbeda, beberapa data
yang diperlukan untuk meningkatkan performance.
3. Konsitensi data
12
Dengan menghapus atau mengontol redudansi, maka akan mengurangi resiko
ketidak konsistensian yang akan muncul. Jika sebuah data disimpan hanya satu kali
pada basis data, update apapun terhadap nilai data tersebut hanya dilakukan satu
kali dan nilai baru tersedia untuk user.
4. Semakin banyak informasi yang didapat dari data yang sama
Dengan integrasi dari data operasional, maka mungkinkan perusahaan untuk
menurunkan informasi tambahan dari data yang sama.
5. Data yang berbagi
File biasanya dimiliki oleh orang atau departemen yang menggunakannya. Disisi
lain, basis data adalah miliki keseluruhan organisasi dan dapat dibagi-bagi kepada
user yang berhak mengakses.
6. Meningkatkan integritas data
Integritas data merujuk pada fasilitas dan konsistensi data yang disimpan. Integritas
biasanya digambarkan dalam bentuk constraint, yang merupakan peraturan yang
konsitensi pada database yang tidak diijinkan untuk dilanggar.
7. Meningkatkan keamanan.
Keamanan basis data adalah perlindungan basis data dari user yang tidak memiliki
akses. Hal ini dapat dilakukan dengan cara membuat username dan password untuk
mengedifikasi user yang mempunyai hak akses ke basis data. Akses yang diberikan
kepada user dapat dibatasi oleh jenis operasi yaitu insert, update, delete, dan
retrieval data.
8. Menjalankan standar
13
Integrasi memungkinkan DBA mendefinisikan dan menjalankan standar yang
diperlukan. Standar ini dapat meliputi standar department, organisasi, nasional, atau
internasional untuk pemformatan data dalam memfasilitasi pertukaran data antara
sistem, aturan penamaan, standar dokumentasi, prosedur update dan aturan akses.
9. Meningkatkan maintance melalui independensi data
Pada sistem berbasis file, deskripsi data dan logika untuk mengakses data dibagun
kedalam setiap program aplikasi, membuat program bergantung pada data. Pada
DBMS, deskripsi data dan aplikasi dipisahkan sehingga membuat aplikasi terpisah
dari perubahan deskripsi data.ini diseput dengan independensi data.
10. Meningktkan concurrency
DBMS mengatur akses ke basis data dimana jika terjadi akses terhadap data secara
bersamaan, maka akses satu tidak akan menggangu akses lainnya sehingga tidak
terjadi kehilangan informasi.
2.1.2.3 Kerugian Database management System (DBMS)
Menurut Connuly dan Begg (2005, p29), Kerugian DBMS antara lain :
1. Kompleksitas
Perancangan dan pengembangan basis data, data dan database administrator, serta
user harus memahami keseluruhan fungsionalitas DBMS yang kompleks. Kegagalan
dalam memahami system dapat membawa keputusan rancangan yang buruk dimana
akan terdapat konsekuensi yang serius untuk perusahaan.
2. Ukuran (size)
14
Fungsionalitas yang kompleks menjadikan DBMS sebagai sebuah perangkat lunak
yang membutuhkan tempat penyimpanan yang sangat besar dan jumlah memori yang
besar yang menjalankan DBMS secara efisien.
3. Biaya DBMS
Biaya untuk suatu DBMS sangat bervariasi tergantung pada lingkungan dan
fungsionalitas yang diberikan.
4. Biaya perangkat keras tambahan
Kebutuhan tempat penyimpangan untuk DBMS dan basis data membutuhkan
pembelian tempat penyimpanan tambahan. Selain itu untuk mendapatkan
performance yang diinginkan, maka diperlukan untuk membeli mesin yang lebih
besar untuk menjalankan DBMS. Penambahan perangkat keras baru akan
menghasilkan pengeluaran biaya tamnbahan.
5. Biaya konversi
Biaya tambahan untuk melakukan konversi aplikasi yang telah ada agar berjalan pada
DBMS dan perangkat keras yang baru. Selain itu juga meliputi biaya tambahan untuk
pelatihan staff untuk menggunakan system baru dan mungkin memperkerjakan staff
ahli untuk membatu dalam melakukan konversi dan menjalankan system baru.
6. Performance
DBMS digunakan untuk memenuhi banyak permintaan aplikasi sehingga beberapa
aplikasi tidak berjalan sesuai yang seharusnya.
15
2.1.3 Data Definition Language (DDL)
Menurut Connoly dan Begg (2005, p40), Data Definition Language (DDL) adalah
suatu bahasa yang memungkinkan DBA (Database Admistrator) atau user untuk
mendeskripsikan dan memberi nama entity, atribut, dan relasi yang diperlukan aplikasi,
bersama dengan segala integritas dan batasan keamanan.
2.1.4 Data Manipulation Language (DML)
Menurut Connoly dan Begg (2005, p40), Data Manipulation Language adalah
sebuah bahasa yang menyediakan sekumpulan operasi untuk mendukung operasi
manipulasi data utama pada data didalam basis data.
Menurut Connoly dan Begg (2005, p41), Operasi manipulasi data antara lain:
a. Mengentri data baru kedalam basis data.
b. Modifikasi data yang disimpan dalam basis data.
c. Menampilkan kembali data didalam basis data.
d. Menghapus data dari basis data.
Menurut Connuly dan Begg (2005, p41), Terdapat dua tipe DML yaitu :
a. Procedural DML, yaitu sebuah bahasa yang memberikan fasilitas kepada user untuk
memberitahukan kepada system, data apa yang diperlukan dan bagaimana seharusnya
data tersebut diambil.
b. Non-procedural DML, yaitu sebuah bahasa yang memberikan fasilitas kepada user
untuk menyatakan data apa yang diperlukan daripada tentang bagaimana data tersebut
diambil.
16
2.1.5 Fourth-Generation Languages (4GL)
Menurut Connoly dan Begg (2005, p42), 4GL adalah bahasa pemprograman yang
tidak memiliki prosedur standar dimana user mendefinisikan apa yang harus
diselesaikan, bukan cara yang digunakan. User tidak mendefinisikan langkah-langkah
yang dibutuhkan program untuk mengerjakan sebuah tugas, tetapi mendefinisikan
parameter bagi tools yang akan digunakan untuk menghasilkan sebuah program aplikasi.
Menurut Connoly dan Begg (2005, p42), 4GL meliputi:
a. Presentation Language, seperti query languages dan report generators.
b. Speciality language, seperti spreadsheets dan sistem basis data languages.
c. Application generators yang mendefinisikan, meng-insert, meng-update, dan me-
retrieve data dari sistem basis data untuk membangun aplikasi.
d. Bahas-bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi.
Menurut Connoly dan Begg (2005, p42), Salah satu contoh 4th
GL adalah SQL
(Structured Query Language). Menurut Connoly dan Begg (2005, p113), SQL adalah
sebuah bahasa yang dirancang mengunakan relasi untuk mengubah input ke output yang
diinginkan. SQL memiliki dua komponen utama yaitu : Data Definition Language
(DDL) dan Data Manipulation Languange (DML).
2.1.6 Database System Development Life Cycle
Menurut Connoly dan Begg (2005, p282), Pengertian sistem informasi adalah
sumber-sumber mengenai koleksi, managemen, kontrol dan penyebaran informasi
perusahaan.
17
Menurut Connoly dan Begg (2005, p283), Sistem Basis data adalah komponen
dasar dari organisasi yang besar dengan sistem informasi yang luas. Hal penting yang
perlu di perhatikan 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.
Untuk aplikasi basis data yang kecil dengan pemakai yang sedikit maka lifecycle-
nya tidak terlalu kompleks. Sebaliknya, ketika merancang basis data yang sedang sampai
ke basis data yang besar dengan puluhan ribu pemakai, menggunakan ratusan query dan
program aplikasi maka lifecycle akan menjadi sangat kompleks.
18
Perencanaan Basisdata
Definisi Sistem
Analisis dan Pengumpulan Kebutuhan
Perancangan Basisdata
Konseptual
Perancangan Basisdata
Logikal
Perancangan Basisdata
Fisikal
Implementasi
Konversi Data dan Loading
Testing
Pemeliharaan
Operasional
Prototyping
(optional)
Pemilihan
DBMS
(optional)
Perancangan
Aplikasi
Perancangan
Basisdata
Gambar 2.1
Skema Tahapan Siklus Hidup Pengembangan Sistem Basisdata
(Sumber : Connolly and Begg, 2005, p284)
19
Menurut Connoly dan Begg (2005, p285), Berikut ini adalah keterangan dari tahap
Pengembagan aplikasi basis data diatas :
2.1.6.1 Perencanaan Basis Data
Menurut Connoly 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 isu pokok yang
berkaitan dengan perumusan strategi sistem informasi, antara lain :
a. Mengenali rencana dan tujuan perusahaan, kemudian menentukan kebutuhan sistem
informasi.
b. Mengevaluasi sistem informasi yang sedang berjalan untuk menentukan kekuatan dan
kelemahan.
c. Penilaian dari kesempatan teknologi informasi yang menghasilkan kekuatan
kompetitif.
2.1.6.2 Definisi Sistem
Menurut Connoly 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.
20
2.1.6.3 Analisis dan Pengumpulan Kebutuhan
Menurut Connoly dan Begg (2005, p288), Requirement Collection and Analisis
adalah proses mengumpulkan danmenganalisa informasi yang mendukung aplikasi basis
data dan menggunakan informasi ini untuk mengidentifikasi kebutuhan pengguna pada
system yang baru. Fact-findding adalah cara untuk mendapatkan informasi. Menurut
Connoly 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.6.4 Perancangan Basis Data
Menurut Connoly 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.
Dua pendekatan perancangan basis data :
a. Pendekatan bottom-up
Dimulai dari level atribut dasar dimana melalui analisis atribut yang berhubungan
yang dikelompokan kedalam relasi yang mempresentasikan tipe entity dan relasi antar
entity.
21
b. Pendekatan top-down
Dimulai dengan perkembangan model data yang mengandung beberapa entity level
tinggi dan relasi lalu turun untuk mengedifikasi entity level rendah, relasi dan atribut
yang berhubungan.
2.1.6.5 Pemilihan DBMS (Optional)
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/ 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. Alam 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.6.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
22
kasus sebenarnya, tidak mungkin dapat menyelesaikan perancangan aplikasi sebelum
perancangan basis data selesai. 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 bias terpenuhi dan
merancang antarmuka pemakai yang tepat. Antarmuka dirancang harus memberikan
informasi yang dibutuhkan dengan cara menciptakan “user-friendly”.
2.1.6.7 Prototyping (Optional)
Menurut Connoly dan Begg (2005, p304), Ptototyping adalah Pembuatan model
kerja dari system 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 system 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 daru 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.
23
2.1.6.8 Implementasi
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.6.9 Konversi Data dan Loading
Menurut Connoly dan Begg (2005, p305), Data Conversion 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.6.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 menvapainya harus
hati-hati dalam menggunakan perancangan strategi uji dan menggunakan data asli untuk
24
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.
Setelah testing selesai, system aplikasi siap digunakan dan diserahkan kepada pemakai.
2.1.6.11 Pemeliharaan Operasional
Menurut Connoly dan Begg (2005, p306), Operational Maintance adalah Proses
memonitor dan menjaga system 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 mengupgrade sistem basis datanya (jika diperlukan).
2.1.7 Metodologi Perancangan Basis data
Menurut Connoly dan Begg (2005, p438), Metodologi Desain adalah Sebuah
Pendekatan terstruktur yang menggunakan prosedur, teknik, tool, dan dokumentasi yang
mendukung dan memfasilitasi proses desain.
25
Menurut Connoly dan Begg (2005, p439), Dalam Metodologi desain, proses
desain dibagi kedalam tiga tahapan utama, yaitu:
2.1.7.1 Perancangan Basis data Konseptual
Tujuan dari perancangan konseptual basisdata menurut Connolly and Begg (2005,
p442) adalah untuk memproses pembuatan suatu model dari informasi yang akan
digunakan dalam suatu organisasi, yang tidak tergantung pada segala pertimbangan
fisikal. Langkah-langkah dalam pembuatan model Basis data kondeptual 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 entity
Tujuan dari langkah ini adalah untuk mengidentifikasi entity utama yang diminta
oleh user.
Langkah pertama yang diperlukan dalam membangun suatu lokal konseptual data
model adalah untuk mendefinisikan objek utama atau entity dimana user memang
membutuhkannya. Salah satu metode untuk mengidentifikasi tipe entity yang utama
adalah dengan mengidentifikasi kata benda atau frase kata benda yang telah disebutkan
oleh user.
Setelah tipe entity diidentifikasi, dilakukan pemberian nama yang berarti dan jelas
kepada user. Mencatat nama dan deskripsi entity dalam kamus data. Apabila
26
dimungkinkan, mendokumentasikan jumlah occurences yang diharapkan dari tiap entity.
Jika entity dikenal dengan nama yang berbeda, nama tersebut menunjuk kepada sinonim
atau alias, yang dicatat dalam kamus data.
Gambar 2.2 Contoh Kamus Data Entity Yang Mendeskripsikan Entity Untuk
Staff UserView DreamHome
Langkah 1.2 : Mengidentifikasi tipe relasi
Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang penting antara
berbagai tipe entity 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 entity
yang persis antara dua entity saja. Bagaimanapun, relasi kompleks yang melibatkan lebih
dari dua entity dan relasi rekursif yang hanya melibatkan satu entity 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
27
Basis data yang dituliskan dalam bentuk tekstual. Dalam hal ini, ERD digunakan
untuk merepresentasikan entity dan bagaimana relasi antar entity. Oleh karena itu,
sangat disarankan menggunakan ERD untuk membantu dalam pembuatan gambaran
umum dari perancangan Basis data yang sedang dikembangkan.
b. Menentukan multiplicity constraints dari tipe relasi
Setelah mendapat relasi antar entity, 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 peng-update-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 entity didefinisikan, maka langkah
berikutnya adalah mencek fan traps dan chasm traps.
Definisi dari fan traps adalah suatu model yang merepresentasikan suatu relasi
antar entity. Tetapi alur relasinya memperlihatkan ambiguitas.
Chasm traps adalah suatu model dimana terdapat hubungan antar entity yang
satu dengan yang lain, tetapi tidak ada relasi antar kedua entity yang utama.
d. Mengecek bahwa setiap entity mempunyai minimal sebuah relasi
Pada pembuatan ERD, pastikan setiap entity mempunyai minimal satu relasi
28
dengan entity yang lain. Jika memang setiap entity sudah memiliki minimal satu relasi
dengan entity 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 me-record deskripsi
relasi dan multiplicity constraints pada kamus data.
Gambar 2.3 Contoh Kamus Data Relationship Yang Mendeskripsikan
Relatioship Untuk Staff User View DreamHome
Langkah 1.3 : Mengidentifikasi dan mengasosiasikan atribut suatu tipe
entity atau tipe relasi.
Tujuan dari langkah ini adalah untuk mengidentifikasi dan mengasosiasikan
atribut yang sesuai dengan tipe entity atau tipe relasi.
a. Simple atau Composite Atribut
Salah satu hal yang penting adalah perlunya memperhatikan apakah suatu
atribut tertentu adalah simple atau composite. Composite atribut adalah atribut yang
dibangun dari simple atribut. Sebagai contoh, atribut alamat bisa saja dibuat simple
29
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.
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.
d. Mendokumentasikan atribut
30
Setelah atribut diidentifikasi, dilakukan pemberian nama yang berarti kepada
user. Kemudian mencatat beberapa informasi untuk tiap atribut antara lain :
a. Nama atribut dan deskripsinya;
b. Tipe data dan panjangnya;
c. Semua alias yang dikenal atribut;
d. Apakah atribut termasuk composite atau tidak. Jika termasuk simple atribut, maka
dibuat menjadi composite;
e. Apakah atribut termasuk multi-valued atau tidak;
f. Apakah atribut diturunkan atau tidak. Jika benar, bagaimana perhitungannya;
g. Semua nilai default untuk atribut.
Gambar 2.4 Contoh Kamus Data Atribut Yang Mendeskripsikan Atribut
Untuk Staff User View DreamHome
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 :
31
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, primary key dan alternate key
Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key dari setiap
tipe entity, 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 :
a. Merupakan candidate key dengan jumlah set atribut paling sedikit.
b. Merupakan candidate key yang nilainya jarang sekali berubah.
c. Merupakan candidate key dengan jumlah karakter paling sedikit.
d. Merupakan candidate key dengan nilai maksimalnya yang terkecil (untuk tipe atribut
dengan tipe numeric).
e. Merupakan candidate key yang paling mudah digunakan dari sudut pandang user.
Langkah 1.6 : Menggunakan konsep enhanced modeling (langkah optional)
Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan konsep
enhanced modeling, seperti specialization, generalization, aggregation dan composition
32
Jika kita menggunakan pendekatan specialization, maka perhatikan perbedaan
antara entity dengan mendefinisikan satu atau lebih subclass dari superclass entity. Jika
kita menggunakan pendekatan generalization, maka kita akan mengidentifikasikan fitur
umum antara entity yang ada untuk mendefinisikan generalisasi entity superclass. Untuk
aggregation digunakan representasi relasi „has-a‟ atau „is-part-of‟ antara tipe entity,
dimana salah satunya merepresentasikan „whole‟ dan lainnya „part‟. Sedangkan
pengguanan composition (tipe khusus aggregation) untuk merepresentasikan asosiasi
antara tipe entity dimana terdapat kepemilikan yang kuat dan coincidental lifetime antara
„whole‟ dan „part‟.
Langkah 1.7 : Mengecek model dari redundancy
Tujuan dari langkah ini adalah untuk mengecek apakah ada redundansi dalam
model Basis data.
Pada langkah ini, dilakukan pengujian model data konseptual lokal dengan
mengidentifikasi apakah terdapat redundansi dan menghilangkannya jika ada. 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 dengan transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa model konseptual lokal
mendukung transaksi yang diperlukan oleh user. Pengujian dilakukan dengan dua
33
pendekatan yang mungkin untuk memastikan model data konseptual mendukung
transaksi yang diperlukan:
a. Mendeskripsikan transaksi;
b. Menggunakan jalur transaksi.
Langkah 1.9 : Me-review model data konseptual dengan 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.
34
Gambar 2.5 Contoh ERD Konseptual (Sumber : Connolly and Begg 2005,p457)
2.1.7.2 Perancangan Basis data Logikal
Menurut Connolly and Begg (2005, p294), perancangan Basis data fisikal adalah
suatu proses pembuatan suatu model dari data yang digunakan di dalam suatu
perusahaan berdasarkan model data yang spesifik, tetapi tidak tergantung pada suatu
DBMS dan pertimbangan fisikal lainnya.
BusinessOwner
manager
▼
holds
▼
associatedWith
▼
states
▼
◄ views
registers ►
supervises
▼
Staff
StaffNo
Supervisor
PrivateOwner
Owner
ownerNo
Client
clientNo
PropertyForRent
propertyNo
Lease
leaseNo
Preference
viewDate
Comment
▲
owns
35
Langkah 2 : Membangun dan Menvalidasi Model Data Logikal
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 : Relasi turunan untuk model data logikal
Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk model data
logikal yang merepresentasikan suatu entity, relasinya dan juga atribut yang telah
diidentifikasi. Adapun pendeskripsian bagaimana relasi dapat diturunkan dari struktur
dibawah ini yang terjadi dalam model data konseptual antara lain:
a. Tipe entity kuat
b. Tipe entity lemah
c. tipe relasi binary one-to-many (1.*)
d. tipe relasi binary one-to-one (1.1)
e. tipe relasi rekursif one-to-one (1.1)
f. tipe relasi superclass atau subclass
g. tipe relasi binary many-to-many
h. Tipe relasi kompleks
i. Atribut multi-valued
Langkah 2.2 : Memvalidasi relasi dengan menggunakan normalisasi
Tujuan dari langkah ini adalah untuk menvalidasi relasi dalam model data logikal
dengan menggunakan teknik normalisasi. Tujuan dari normalisasi adalah :
36
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 redundancy 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 dengan 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 menjadi incomplete (tidak lengkap),
inaccurate (tidak akurat), atau inconsistent (tidak konsisten).
Dibawah ini terdapat enam tipe batasan integritas, antara lain :
a. Data yang dibutuhkan;
b. Batasan domain atribut;
37
c. Multiplicity;
d. Integritas entity;
e. Integritas referensial;
f. Batasan umum.
Langkah 2.5 : Me-review model data logikal dengan 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.
Hubungan antara Model Data Logikal dan Data Flow Diagram
Suatu model data logikal merefleksikan struktur dari penyimpanan data suatu
perusahaan. Data Flow Diagram (DFD) menunjukan aliran data suatu perusahaan dan
disimpan di dalam datastores. Semua atribut seharusnya berada di dalam suatu tipe
entity, jika memang atribut tersebut ditangani di dalam perusahaan dan kemungkinan
akan dilihat mengalir disekitar perusahaan sebagai aliran data. Ketika dua teknik
tersebut digunakan untuk memodelkan spesifikasi kebutuhan user, kita dapat
menggunakan salah satunya untuk mengecek kekonsistenan dan kelengkapan dari yang
lainnya. Terdapat aturan yang mengontrol relasi antara dua teknik tersebut, antara lain :
a. Setiap datastore harus merepresentasikan semua jumlah tipe entity;
b. Atribut dalam data flow harus merupakan bagian dari tipe entity.
38
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 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. Me-review nama dan isi dari suatu entity atau relasi dan candidate key-nya.
2. Me-review nama dan isi dari suatu relasi atau foreign key.
3. Menggabungkan entity atau relasi dari model data lokal.
4. Memasukkan (tanpa penggabungan) entity atau relasi yang unik untuk setiap model
39
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 entity 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.
Langkah 2.6.2 : Memvalidasi model data logikal global
Tujuan dari langkah ini adalah untuk menvalidasi 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
40
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.
41
Gambar 2.6 Contoh ERD Logikal (Sumber : Connolly and Begg 2005,p489)
42
2.1.7.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 (DBDL). Untuk setiap relasi yang diidentifikasi pada model data
logikal, dapat didefinisikan berisi :
a. Nama relasi;
b. Daftar simple atribut dalam tanda kurung;
c. Primary key(PK), alternate key (AK), dan foreign key (FK);
43
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.7 DBDL untuk relasi PropertyForRent (Sumber : Connolly and Begg
2005,p499)
44
Langkah 3.2 : Merancang representasi derived data (data turunan)
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 :
Jumlah staff yang bekerja pada suatu branch (cabang);
Total gaji bulanan untuk semua staff;
Jumlah properti yang di-handle oleh anggota staff.
Gambar 2.8 Relasi PropertyForRent dan Staff dengan atribut turunan
noOfProperties (Sumber : Connolly and Begg 2005,p500)
Langkah 3.3 : Merancang kendala umum
Tujuan dari langkah ini adalah untuk merancang kendala umum untuk DBMS yang
dituju.
45
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 yg 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.
Untuk membuat perancangan Basis data fisikal yang efektif perlu untuk
mempunyai pengetahuan mengenai transaksi atau query yang akan dijalankan di dalam
46
Basis data. Hal ini termasuk informasi kualitatif dan kuantitatif. Dalam menganalisis
transaksi, dapat diidentifikasikan kriteria kinerja sebagai berikut :
Transaksi yang sering digunakan, dan akan berdampak besar terhadap kinerja
keseluruhan;
Transaksi yang kritis untuk operasi bisnis;
Durasi waktu dalam harian atau mingguan yang akan mendapatkan banyak
permintaan pada Basis data (disebut peak load).
Gambar 2.9 Contoh Analisis Transaksi Pada Relasi (Sumber : Connolly and Begg
2005,p504)
47
Gambar 2.10 Contoh Penggunaan Transaksi (Sumber : Connolly and Begg
2005,p504)
Gambar 2.11 Contoh Form Analisis Transaksi (Sumber : Connolly and Begg
2005,p507)
48
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. Beberapa macam organisasi file yang ada adalah sebagai berikut :
Heap
Hash
Indexed Sequential Office Access Method (ISAM)
B*-three
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.
49
Salah satu pendekatan untuk memilih organisasi file yang sesuai untuk relasi yaitu
menjaga agar tuples tidak berurutan dan membuat indeks secondary sebanyak mungkin.
Pendekatan lainnya yaitu untuk mengurutkan tuples dalam relasi dengan menspesifikasi
primary atau clustering indeks. Dalam kasus ini, biasanya pemilihan suatu atribut untuk
pengurutan atau clustering pada tuples adalah sebagai berikut :
Suatu atribut yang digunakan paling sering untuk operasi join (penggabungan), yang
akan membuat operasi penggabungan itu lebih efisien, atau
Suatu atribut yang digunakan paling sering untuk mengakses suatu tuples 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 menjadi clustering index. Setiap relasi
hanya dapat mempunyai primary index atau clustering index.
Langkah 4.4 : Mengestimasi kapasitas disk yang dibutuhkan
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 hardware yang digunakan untuk mendukung
Basis data. Secara umum, estimasi tersebut dilakukan berdasarkan ukuran tiap tuple dan
jumlah tuples dalam relasi.
50
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 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 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 :
Keamanan sistem;
Keamanan data.
Keamanan sistem menutupi pengaksesan dan penggunaan Basis data pada tingkat
sistem, seperti user name dan password. Sedangkan, keamanan data menutupi
pengaksesan dan penggunaan objek Basis data (seperti relasi dan views) dan tindakan
dimana user dapat memperoleh objek tersebut.
51
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 denagan
menggunakan suatu kontrol yang memadai.
Beberapa issue keamanan yang perlu diperhatikan :
1. Pencurian data (Theft and Fraud)
2. Kehilangan kerahasiaan data (Loss of Confidentially)
3. Kehilangan hak pribadi (Loss of Privacy)
4. Kehilangan integritas (Loss of integrity)
5. 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 penyimpanan dan metodologi
pengaksesan data oleh user yang efisien, selama batasan integritas dan pengukuran
keamanan.
2.1.8 Entity-Relationship Modeling ( ER Modeling )
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 entiti dan
relationship antar data yang harus direpresentasikan di dalam model, dan kemudian
ditambahkan atribut dan setiap constraint pada entiti, relationship, dan
atributnya.Beberapa konsep dasar dalam model E-R yaitu:
52
2.1.8.1 Tipe entity
Tipe Entiti 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 entiti yang dapat diidentifikasikan secara unik (Connolly, 2005, p345).
Keberadaan objek-objeknya secara fisik / nyata (physical existance) seperti entiti
pegawai, rumah, dan pelanggan, atau secara konseptual / abstrak (conceptual existance)
seperti entiti penjualan, pembelian, dan peminjaman.
Setiap tipe entiti dilambangkan dengan sebuah persegi panjang yang diberi nama
dari entiti tersebut. Nama tipe entiti biasanya adalah kata benda tunggal. Huruf pertama
dari setiap kata pada nama tipe entiti ditulis dengan huruf besar.
Gambar 2.12 Representasi diagram dari tipe entiti Pegawai dan Cabang
(Sumber : Connolly and Begg 2005,p345)
Tipe Entiti dapat dilasifikasikan menjadi:
Tipe Entiti Kuat, yaitu tipe entiti yang keberadaannya tidak tergantung pada tipe entiti
lainnya (Connolly, 2005, p354)
Tipe Entiti Lemah, yaitu tipe entiti yang keberadaannya bergantung pada tipe entiti
lainnya (Connolly, 2005, p355)
Nama Entiti
Pegawai Cabang
53
Gambar 2.13 Representasi diagram tipe entiti kuat dan tipe entity lemah
(Sumber : Connolly and Begg 2005,p355)
2.1.8.2 Tipe Relationship
Tipe relationship adalah sekumpulan hubungan antar tipe entiti 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 entiti di dalam relationship (Connolly, 2005, p346)
Tipe relationship digambarkan dengan sebuah garis yang menghubungkan entiti-
entiti yang saling berhubungan. Garis tersebut diberi nama sesuai dengan nama
hubungannya dan diberi tanda panah satu arah disamping nama hubungannya.
Biasanya sebuah relationship 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 relationship yang
mengindikasikan arah bagi pembaca untuk mengartikan nama dari suatu relationship.
Huruf pertama dari setiap kata pada suatu relationship ditulis dengan huruf besar.
entiti kuat
Klien
noKlien {PK}
nama
namaDpn
namaBlkng
telp
entiti lemah
Pilihan
tipePilihan
brgSewaMax
Menyatakan
54
Gambar 2.14 Representasi diagram dari tipe relationship (Sumber : Connolly
and Begg 2005,p347)
2.1.8.2.1 Derajat dari Tipe Relationship
Derajat dari tipe relationship adalah jumlah tipe entiti yang ikut di dalam sebuah
relationship (Connolly, 2005, p347)
Complex relationship types adalah sebuah relationship antara tiga atau lebih tipe
entiti (Connolly, 2005, p348). Sebuah relationship yang memiliki derajat dua dinamakan
binary (Connolly, 2005, p348). Gambar 2.4 juga merepresentasikan diagram
relationship derajat dua. Sedangkan sebuah relationship derajat tiga dinamakan ternary,
dan jika sebuah relationship memiliki derajat empat dinamakan quarternary (Connolly,
2005, p348).
Lambang belah ketupat merepresentasikan relationship yang memiliki derajat
lebih dari dua. Nama dari relationship tersebut ditampilkan di dalam belah ketupat.
Panah yang biasanya terdapat di bawah nama relationship dihilangkan.
Pegawai Cabang Memiliki
Cabang memiliki pegawai
55
Gambar 2.15 Representasi diagram derajat tiga dari suatu tipe relationship
(Sumber : Connolly and Begg 2005,p348)
2.1.8.2.2 Recursive Relationship
Recursive relationship adalah sebuah tipe relationship dimana tipe entiti yang
sama ikut serta lebih dari sekali pada peran yang berbeda (Connolly, 2005, p349).
Relationship dapat diberikan nama peran untuk menentukan fungsi dari setiap
entiti yang terlibat dalam relationship tersebut.
Gambar 2.16 Representasi diagram recursive relationship beserta nama peran
(Sumber : Connolly and Begg 2005,p349)
Nama peran
Nama peran
Pegawai Orang yang
diawasi
Pengawas
Mengawasi
Pegawai Mendaftarkan
Klien
Cabang
Pegawai mendaftarkan klien pada sebuah cabang
56
2.1.8.3 Tipe Atribut
Adapun tipe-tipe atribut sebagai berikut:
a. Single valued attribute adalah atribut yang hanya memiliki sebuah nilai untuk setiap
occurrence dari sebuah entiti (Connolly, 2005, p351)
b. Multi valued attribute adalah atribut yang memiliki banyak nilai untuk setiap
occurrence dari sebuah entiti (Connolly, 2005, p352)
c. Derived attribute adalah atribut yang nilai-nilainya diperoleh dari pengolahan atau
diturunkan dari atribut lain yang berhubungan (Connolly, 2005, p352)
2.1.8.4 Keys
Candidate key adalah himpunan atribut yang minimal yang secara unik
mengidentifikasikan setiap occurrence dari sebuah tipe entiti (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 entiti (Connolly, 2005, p353). Pada sebuah tipe
entiti 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 entiti yang digunakan pada
entiti lainnya untuk mengidentifikasikan sebuah relationship (Connolly, 2005, p79).
57
Gambar 2.17 Representasi diagram entiti Pegawai dan Cabang beserta atribut
dan primary key-nya (Sumber : Connolly and Begg 2005,p354)
2.1.8.5 Strong and Weak Entity Types
Strong Entity Types, yaitu entity yang keberadaannya tidak bergantung pada entity
lain, sedangkan Weak Entity Types, adalah entity yang keberadaannya bergantung pada
entity lain. Strong Entity Types sering disebut dengan parent, owner dominant,
sedangkan Weak Entity Types disebut dengan child, dependent, subordinate.
2.1.8.6 Batasan Struktural (Struktural Constraints)
Batasan-batasan yang menggambarkan pembatasan pada relasi seperti yang ada
pada dunia nyata harus diterapkan pada tipe entiti yang ikut serta pada sebuah relasi.
Menurut Connolly (2005, p356) jenis utama dari batasan pada suatu relasi dinamakan
multiplicity.
Mengatur ►
Pegawai
noPeg {PK}
nama
jabatan
gaji
totalPeg
Cabang
noCab {PK}
alamat
jalan
kota
kodepos
telp {1-3}
multi-valued
attribute
derived
attribute
primary key
◄ Memiliki
composite
attribute ruang untuk
menulis
atribut
58
Menurut Connolly (2005, p356) multiplicity adalah jumlah occurrence yang
mungkin terjadi pada sebuah tipe entiti yang berhubungan ke sebuah occurrence dari
tipe entiti lain pada suatu relasi.
Derajat yang biasanya digunakan pada suatu relasi adalah relasi binary, yang
terdiri atas:
2.1.8.6.1 Relasi one-to-one (1:1)
Setiap relasi menggambarkan hubungan antara sebuah entiti occurrence pada entiti
yang satu dengan sebuah entiti occurrence pada entiti yang lainnya yang ikut serta
dalam relasi tersebut.
Gambar 2.18 Semantic net menunjukkan dua occurrence dari relasi Pegawai
Mengatur Cabang (Sumber : Connolly and Begg 2005,p357)
B003
B005
r1
r2
SG5
SG37
SG21
Mengatur tipe
relationship
Cabang tipe entiti
(noCab)
Pegawai tipe entiti
(noPeg)
59
Gambar 2.19 Multiplicity dari relasi one-to-one (1:1) (Sumber : Connolly and
Begg 2005,p358)
2.1.8.6.2 Relasi one-to-many (1:*)
Setiap relasi menggambarkan hubungan antara sebuah entiti occurrence pada entiti
yang satu dengan satu atau lebih entiti occurrence pada entiti yang lainnya yang ikut
serta dalam relasi tersebut.
Gambar 2.20 Semantic net menunjukkan tiga occurrence dari relasi Pegawai
Melihat RumahSewa (Sumber : Connolly and Begg 2005,p358)
SG5
SG37
SG9
PG21
PG36
PA14
PG4
r1
r2
r3
Melihat tipe
relationship
RumahSewa tipe entiti
(noRumah)
Pegawai tipe entiti
(noPeg)
1..1
Mengatur ►
0..1
Pegawai
noPeg
Cabang
noCab
setiap cabang diatur
oleh seorang
pegawai
Setiap pegawai dapat
mengatur nol atau satu
cabang
multiplicity
60
Gambar 2.21 Multiplicity dari relasi one-to-many (1:*) (Sumber : Connolly and
Begg 2005, p359)
2.1.8.6.3 Relasi many-to-many (*:*)
Setiap relasi menggambarkan hubungan antara satu atau lebih entiti occurrence
pada entiti yang satu dengan satu atau lebih entiti occurrence pada entiti yang lainnya
yang ikut serta dalam relasi tersebut.
PG21
PG36
PA14
PG4
Glasgow Daily
The News West
Aberdeen
Express
r1
r2
r3
r4
Mengiklankan
tipe relationship
RumahSewa tipe
entiti (noRumah)
Koran tipe entiti
(namaKoran)
RumahSewa
noRumah 0..1
Melihat ►
0..*
Pegawai
noPeg
setiap rumah sewa
dilihat nol atau satu
pegawai
Setiap pegawai dapat
melihat nol atau lebih
rumah sewa
multiplicity
61
Gambar 2.22 Semantic net menunjukkan empat occurrence dari relasi Koran
Mengiklankan RumahSewa (Sumber : Connolly and Begg 2005,
p360)
Gambar 2.23 Multiplicity dari relasi many-to-many (*:*) (Sumber : Connolly and
Begg 2005, p360)
2.1.8.7 Cardinality dan Participation Constraints
Multiplicity sebenarnya terdiri atas dua constraint yang berbeda, yaitu:
a. Cardinality
Menurut Connolly (2005, p363) Cardinality adalah nilai maksimum dari relasi
occurrence yang mungkin terjadi untuk sebuah entiti yang ikut serta pada suatu
relasi.
b. Participation
Mengiklankan ►
0..*
RumahSewa
noRumah 1..*
Koran
namaKoran
setiap rumah sewa
diiklankan pada nol atau
lebih koran
Setiap koran mengiklankan
satu atau lebih rumah
sewa
multiplicity
62
Menurut Connolly (2005, p363) Participation menentukan apakah semua atau
hanya beberapa entiti occurrence yang ikut serta dalam sebuah relasi. Participation
constraint dibagi menjadi:
Mandatory Participation
Menurut Connolly (2005, p363) mandatory participation melibatkan semua entiti
occurrence pada relasi tertentu.
Optional Participation
Menurut Connolly (2005, p363) optional participation melibatkan beberapa
entiti occurrence pada relasi tertentu.
Representasi diagram terhadap multiplicity sebagai cardinality dan participation
constraints dapat dilihat pada gambar 2.24.
63
Gambar 2.24 Multiplicity sebagai cardinality dan participation constraints pada
relasi one-to-one (1:1) Pegawai Mengatur Cabang (Sumber :
Connolly and Begg 2005, p363)
2.1.9 Normalisasi
2.1.9.1 Definisi Normalisasi
Menurut Connolly and Begg (2005, p388), “Normalization is a technique for
producing a set of relations with desirable properties, given the data requirements of an
enterprise”, artinya normalisasi merupakan suatu teknik untuk menghasilkan
sekumpulan hubungan dengan properti yang diinginkan, yang memberikan kebutuhan
1..1
Mengatur ►
0..1
Pegawai
noPeg
Cabang
noCab
sebuah cabang diatur
oleh seorang
pegawai
seorang pegawai
mengatur satu
cabang
‘semua cabang diatur
pegawai’ (mandatory
participation) pada
Cabang
‘tidak semua pegawai
mengatur cabang’
(optional participation)
pada Pegawai
Cardinality
Participation
64
data terhadap sebuah perusahaan.
Adapun, tujuan dari normalisasi adalah sebagai berikut :
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 redundancy dengan tiap atribut direpresentasikan hanya sekali dengan
pengecualian atribut yang membentuk semua atau sebagian foreign key yang penting
untuk berpartisipasi dalam relasi yang terhubung.
2.1.9.2 Tahap-tahap Normalisasi
Menurut Connoly dan Begg (2005, p388), Normalisasi adalah sebuah teknik
untuk menghasilkan sekumpulan relasi dengan property yang diinginkan, yang
akanmemberikan kebutuhan data bagi perusahaan. Relasi adalah sebuah table dengan
kolom dan baris.
Tahap – tahap normalisasi antara lain :
1. First Normal Form (1NF)
Sebelum memasuki tahap 1NF, status sebelum 1NF disebut dengan
Unormalized Form (UNF), yaitu sebuah table yang mengandung satu atau lebih
kelompok yang berulang.
65
First Normal Form adalah sebuah relasi dimana persimpangan dari setiap baris
dan kolom yang mengandung satu dan hanya satu nilai saja.
2. Second Normal Form (2NF)
Sebuah relasi dimana 1NF dan setiap atribut non-primary-key harus bergantung
secara fungsional pada primary key.
Primary key adalah kandidat yang terpilih untuk mengedentifikasi tuple secara
unik pada sebuah relasi. Sedangkan tuple adalah baris pada sebuah relasi.
Proses normalisasi 1NF ke 2NF melibatkan penghilangan partial dependencies.
Jika terdapat partial dependencies, maka atribut functionally dependent dari relasi
akan kehilangan dengan menepatkannya pada sebuah relasi baru bersama dengan
copy determinant mereka.
Full functional dependency adalah suatu keadaan dimana jika A dan B adalah
atribut, Bfull functionally dependent pada A jika B secara fungsional bergantung
pada A, tetapi bukan subset dari A.
3. Third Normal Form (3NF)
Sebuah relasi dimana bentuk 1NF dan 2NF, dimana tidak ada atribut yang
bukan primary key secara transitif bergantung pada primary key. Transitve
dependency adalah sebuah kondisi dimana A, B, dan C adalah atribut dari relasi
diamna AB dan BC, maka C adalah transitive dependency pada A melalui B.
66
2.1.10 Data Flow Diagram (DFD)
Menurut George dan William (1995, p41) DFD merupakan alat bantu untuk
mendokumentasikan perancangan logis sistem agar dapat memenuhi kebutuhan
pemakai.
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.
Simbol-simbol DFD yang digunakan untuk merepresentasikan:
1. Elemen lingkungan proses.
2. Proses.
3. Aliran data.
4. Penyimpanan data.
DFD dibagi 3 yaitu :
1. Diagram Hubungan
Menggambarkan hubungan sistem yang sedang dianalisis dengan eksternal entitynya.
2. Diagram Nol
Menggambarkan proses-proses penting yang ada pada sistem yang dianalisis dan
yang akan dibuat.
3. Diagram Rinci
Menggambarkan proses-proses yang lebih rinci mengenai sistem yang dianalisis dan
yang akan dirancang.
67
Simbol-simbol yang digunakan untuk menggambarkan DFD, yaitu:
De Marco dan Yourdon Gane dan Sarson
Process
Data Store
Source/Sink
Data Flow
Tabel 2.1 Perbandingan simbol diagram aliran data berdasarkan De Marco dan
Yourdon dengn Gane dan Sarson
Terdapat beberapa peraturan yang harus diiuti saat menggambar DFD (Jeffrey A.
Hoffer, 2000,p286)
1. Process
- Tidak ada Proses yang hanya mempunyi output. Jika sebuah objek hanya
mempunyai output maka itu adalah source.
- Tidak ada proses yang hanya mempunyai input. Jika sebuah objek hanya
mempunyai input, maka itu adalah sink.
- Sebuah proses dilabeli dengan sebuah kata kerja
2. Data Store
- Data tidak dapat bergerak dari sebuah data store menuju data store lainnya. Data
dapat bergerak melalui proses.
68
- Data tidak dapat bergerak secara langsung dari source menuju data store. Data
harus bergerak melalui proses dimana data diterima dari data source dan
menempatkan data ke data store.
3. Source/Sink
- Data tidak dapat bergerak langsung dari source menuju sink. Data harus melalui
proses.
- Sebuah source/sink harus dilabeli dengan kata benda.
4. Data Flow
- Sebuah data flow hanya mempunyai satu arah diantara symbol
- Sebuah cabangan pada data flow berarti beberapa data yang sama menuju dua atau
lebih proses yang berbeda.
- Sebuah penggabungan pada data flow berarti data yang sama muncul dari dua atau
lebih proses menuju sebuah lokasi yang sama.
- Sebuah data flow tidak boleh menuju proses yang sama dengan sumber prosesnya
(rekursif). Harus ada minimal satu proses yang menangani data flow,
menghasilkan data flow, dan mengembalikan data flow menuju proses awal.
- Sebuah data flow menuju data store berarti memperbaharui (update atau delete)
data.
- Sebuah data flow dari data store berarti mengambil atau menggunakan data.
- Sebuah data flow mempunyai label berupa kata kerja. Bisa lebih dari satu kata
kerja yang muncul pada sebuah panah data flow dengan syarat semua aliran/flows
pada satu panah bergerak sebagai satu paket.
69
2.1.11 State Transition Diagram (STD)
STD merupakan suatu alat untuk membuat model yang menggambarkan sifat
ketergantungan pada waktu dari suatu sistem real time dan interaksi manusia pada
sistem online. STD pada mulanya digunakan untuk menggambarkan sistem pada waktu
sesungguhnya (Kowal, 1998, p331). Sistem real time adalah suatu kondisi
pengoperasian dalam waktu yang bersamaan dengan relasi waktu yang teratur atau
sudah diprediksi dengan keadaan yang sesungguhnya.
Ada 2 cara kerja sistem, yaitu pasif dan aktif. Sistem yang pasif tidak melakukan
kontrol tehadap lingkungan, tetapi cenderung memberikan relasi atau menerima data
saja. Sistem yang aktif melakukan kontrol terhadap lingkungan. Sistem sanggup
menerima sumber data eksternal dengan cepat dan dalam waktu singkat memberikan
jawaban pada lingkungannya.
Notasi State Transition Diagram
Menurut Yourdon (1993, p260-261) komponen-komponen utama dari STD adalah
state (status) dan arrows (panah) yang mewakili perubahan-perubahan state.
1. Keadaan sistem (system state)
Digambarkan dengan sebuah kotak persegi panjang, merupakan kumpulan
keadaan atau atribut dari sebuah sistem yang mencirikan sesuatu pada waktu
tertentu dan keadaan tertentu. Keadaan dari sistem tersebut dapat berupa menunggu
pemakai memasukkan password, menunggu perintah selanjutnya, dan lain-lain.
70
Ada dua jenis state, yaitu state awal dan state akhir, namun bisa terdapat lebih dari
satu state akhir.
Notasinya :
2. Perubahan keadaan (change of state)
Digambarkan dengan tanda panah yang menghubungkan dua state yang
berkaitan.
Notasinya :
3. Kondisi dan Aksi (conditions and actions)
Komponen kondisi menyebabkan suatu perubahan keadaan, sedangkan aksi
merupakan suatu tanggapan yang dilakukan sistem pada saat terjadinya sistem.
Notasinya:
2.2 Teori - teori Khusus
2.2.1 Lelang
2.2.1.1 Pengertian Lelang
Menurut situs yang beralamat pada alamat berikut ini,
http://www.gknsgr.com/index.asp?info=detailnems&id=9&bln=April&thn=2007 lelang
adalah penjualan barang dimuka umum termasuk melalui media elektronik yang
dipimpin dan atau dilaksanakan dihadapan Pejabat lelang, dengan cara penawaran harga
semakin menurun, dan atau dengan penawaran harga secara tertulis yang didahului
dengan usaha mengumpulkan para peminat.
Kondisi
Aksi
71
2.2.1.2 Risalah Lelang
Dalam setiap pelaksanaan lelang dibuat suatu berita mengenai pelaksanaan lelang
yang disebut Risalah Lelang. Risalah Lelang dibuat oleh pejabat Lelang dan salinannya
diberikan kepada Penjual/pemohon lelang, serta pembeli. Fungsi Risalah Lelang:
1. Bagi Penjual/pemohon lelang, sebagai bukti telah melaksanakan penjualan sesuai
dengan prosedur lelang.
2. Bagi pembeli lelang, sebagai akta jual beli.
3. Bagi Administrasi Lelang, sebagai pertanggungjawaban dan pelaporan atas
pelaksanaan lelang.
2.2.1.3 Kebaikan Lelang
Kebaikan lelang meliputi:
1. Adil, Karena bersifat terbuka/transparan
2. Aman, karena lelang disaksikan/dipimpin dan dilaksanakan oleh Pejabat Lelang
selaku pejabat umum yang bersifat independen. Sistem lelang mengharuskan pejabat
lelang meneliti kebenaran formal subjek dan objek lelang.
3. Cepat dan Efisien, karena pelaksanaan lelang didahului dengan pengumuman
sehingga peserta lelang dapat berkumpul pada hari lelang dan dengan pembayaran
secara tunai.
4. Kepastian Hukum, karena atas pelaksanaan lelang, pejabat lelang membuat Berita
Acara Lelang yang disebut Risalah Lelang.
5. Kompetitif. Mewujudkan harga yang wajar karena pembentukan harga lelang pada
dasarnya menggunakan sistem penawaran yang bersifat terbuka dan transparan.
72
2.2.2 Pengadaan Barang
2.2.2.1 Pengertian Pengadaan Barang
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.
2.2.2.2 Prinsip – prinsip Pengadaan Barang
Menurut Keputusan Presiden No. 80 tahun 2003, BAB 1, pasal 3, Pengadaan
barang wajib menerapkan prinsip-prinsip :
1. Efisien
Pengadaan barang harus diusahaakn dengan menggunakan dana dan daya yang
terbatas untuk mencapai sasaran yang ditetapkan dalam waktu sesingkat-singkatnya
dan dapat dipertanggungjawabkan.
2. Efektif
Pengadaan barang harus sesuai dengan kebutuhan yang telah ditetapkan dan dapat
memberikan manfaat yang sebesar-besarnya sesuai dengan sasaran yang ditetapkan.
3. Terbuka dan Bersaing
Pengadaan barang harus terbuka bagi penyedia barang yang memenuhi persyaratan
dan dilakukan melalui persaingan yang sehat diantara penyedia barang yang setara
dan memenuhi syarat teretentu berdasarkan ketentuan dan prosedur yang jelas dan
transparan.
4. Transparan
73
Semua ketentuan dan informasi mengenai pengadaan barang, termasuk syarat teknis
administrasi pengadaan, tata cara evaluasi, hasil evaluasi, penetapan calon penyedia
barang, sifatnya terbuka bagi peserta penyedia barang yang berminat serta bagi
masyarakat luas pada umumnya.
5. Adil/Tidak Diskriminatif
Memberikan perlakuan yang sama bagi semua calon penyedia barang dan tidak
mengarah untuk member keuntungan kepada pihak tertentu dengan cara dan atau alas
an apapun.
6. Akuntable
Harus mencapai sasaran baik fisik, keuangan, maupun manfaat bagi kelancaran
pelaksanaan tugas umum pemerintahan dan pelayanan masyarakat sesuai dengan
prinsip-prinsip serta ketentuan yang berlaku dalam pengadaan barang.
2.2.2.3 Etika Pengadaan Barang
Menurut Keputusan Presiden No. 80 tahun 2003, BAB 1, pasal 5, pelaksanaan
pengadaan barang harus mematuhi etika sebagai berikut :
1. Melaksanakan tugas secara tertib, disertai rasa tanggung jawab untuk mencapai
sasaran kelancaran dan ketetapan tercapainya tujuan pengadaan barang.
2. Bekerja secara professional dan mandiri atas dasar kejujuran, serta menjaga
kerahasiaan dokumen pengadaan barang yang seharusnya dirahasiakan untuk
mencegah terjadinya penyimpangan dalam pengadaan barang.
3. Tidak saling mempengaruhi baik langsung maupun tidak langsung untuk mencegah
terjadinya persaingan tidak sehat.
74
4. Menerima dan bertanggungjawab atas segala keputusan yang ditetapkan sesuai
dengan kesepakatan para pihak.
5. Menghindari dan mencegah terjadinya pertentangan kepentingan para pihak yang
terkait langsung maupun tidak langsung dalam proses pengadaan barang.
6. Menghindari dan mencegah terjadinya pemborosan dan kebocoran keuangan Negara
dalam pengadaan barang.
7. Menghindari dan mencegah penyalahgunaan wewenang dan/atau kolusi dengan
tujuan untuk keuntungan pribadi, golongan atau pihak lain yang secara langsung atau
tidak langsung merugikan Negara.
8. Tidak menerima, tidak menawarkan atau menjanjikan untuk memberi atau menerima
hadiah, imbalan berupa apa saja kepada siapapun yang diketahui atau patut dapat
diduga berkaitan dengan pengadaan barang.
2.2.2.4 Dokumen – dokumen yang Digunakan
Dokumen-dokumen pengadaan terdiri dari :
1. Dokumen prakualifikasi / kualifikasi
Dokumen prakualifikasi sekurang-kurangnya memuat :
a. Pengumuman prakulaifikasi yang memuat : lingkup pekerjaan, persyaratan
peserta, waktu dan tempat pengambilan dan pemasukan dokumen prakualifikasi.
b. Tata cara penilaian yang meliputi penilaian aspek administrasi, permodalan,
tenaga kerja, peralatan, pengalaman dengan menggunakan metode system gugur
atau system nilai (scoring system).
75
2. Dokumen Lelang Umum
a. Undangan kepada penyedia barang yang mendaftar, sekurang-kurangnya memuat:
Tempat, tanggal, hari, dan waktu untuk memperoleh dokumen pemilihan
penyedia barang dan keterangan lainnya.
Tempat, tanggal, hari, dan waktu pemberian penjelasan mengenai dokumen
pemilihan penyedia barang dan keterangan lainnya.
Tempat, tanggal, hari, dan waktu penyampaian dokumen penawaran.
Alamat tujuan pengiriman dokumen.
Jadwal pelaksanaan pengadaan barang sampai dengan penetapan penyediaan
barang.
b. Instruksi kepada peserta pengadaan barang sekurang-kurangnya memuat :
Lingkup pekerjaan, sumber dana, persyaratan dan kualifikasi peserta pengadaan
barang, jumlah dokumen penawaran yang disampaikan, dan peninjauan lokasi
kerja.
Isi dokumen pemilihan penyedia barang, penjelasan isi dokumen pemilihan
penyediaan barang, dan perubahan isi dokumen pemilihan penyediaan barang.
Persyaratan bahasa yang digunakan dalam penawaran, penulisan harga
penawaran, mata uang penawaran dan cara pembayaran, masa berlaku
penawaran, surat jaminan penawaran, usulan penawaran alternatif oleh pesera
pengadaan barang, bentuk penawaran, dan penandatanganan surat penawaran
barang.
76
Cara penyampulan dan penandaan sampul penawaran, batas akhir waktu
penyampain penawaran, perlakuan terhadap penawaran yang terlambat, serta
larangan untuk perubahan dan penarikan penawaran yang telah masuk.
Prosedur pembukaan penawaran, kerahasiaan dan larangan, klarifikasi
dokumen penawaran, pemeriksaan kelenngkapan dokumen penawaran, koreksi
aritmatik, konversi ke dalam mata uang tunggal, sistem evaluasi penawaran
meliputi kriteria, formulasi dan tata cara evaluai, serta penilaian refernsi harga.
Penialaian kualifikasi dalam hal dilakukan pasca kualifikasi, krteria penetapan
pemenang pengadaaan barang, hak dan kewajiban pengguna barang untuk
menerima dan menolak salah satu atau semua penawaran, syarat
penandatanganan kontrak, dan surat jaminan pelaksanaan.
c. Syarat-syarat umum dan kontrak : maembuat batasan pengertian istilah yang
digunakan, hak, kewajiban, tanggung jawab termasuk tangung jawab pada
pekerjaan yang disubkontrakan, sangsi, penyelesaian perselisihan, dan peraturan
perundang-undangan yang berlaku, dalam pelaksanaan kontrak bagi para pihak.
d. Syarat-syarat khusus kontrak: merupakan bagian dokumen pemilihan penyediaan
barang yang memuat ketentuan-ketentuan yang lebih spesifik sebagaimana dirujuk
dalam pasal-pasal syarat-syarat umum kontrak, dan memuat perubahan,
penambahan atau penghapusan ketentuan dalam syarta-syarat umum kontrak, yang
sifatnya lebih mengikat dari syarat-syarat umu kontrak..
e. Daftar kuantitas dan harga : jenis dan uraian singkat pekerjaan yang akan
dilaksanakan atau barang yang akan dipasok, Negara asal barang, volume
77
pekerjaan, harga satuan barang yang akan ditawarkan, komponen produksi dalam
negeri, harga total pekerjaan/barang, biaya satuan angkutan( khusus untuk
pengadaan barang), Pajak Pertambahab Nilai (PPN) dan pajak lainnya.
f. Khusus untuk pengadan barang, harga barang dalam negeri dan barang impor
harus dipisahkan. Jika barang dalam negeri, harus dijelaskan apakah harga tersebut
merupakan harga eks pabrik, eks gudang, atau dilapangan, sedangkan untuk
barang impor, hanya dijelaskan apakah harga tersebut merupakan harga free on
board (FOB) atau cost insurance and freight(CIF).
g. Spesifikasi teknis dan gambar : tidak mengarah pada merk/produk tertentu kecuali
untuk suku cadang/ komponen produk tertentu, tidak menutip digunakannya
produk dalam negeri, semaksimal mungkin diupayakan menggunakan standar
nasional, metode pelaksanaan harus logis, jadual waktu pelaksanaan pekerjaan
harus sesuai dengan metode pelaksanaan, macam/jenis, kapaasitas, dan jumlah
peralatan minimal yang diperlukan dalam pelaksanaan pekerjaan, syarat-syarat
kualifikasi dan jumlah personil inti yang diperkerjakan, syarat-syarat material yang
dipergunakan dalam pelaksanaan pekerjaan, gambar-gambar kerja harus lengkap
dan jelas, dan criteria kinerja produk yang diinginkan harus jelas.
h. Bentuk surat penawaran : merupakan pernyataan resmi mengikuti pengadaan
barang, pernyataan bahwa penawaran dibuat sesuai dengan peraturan pengadaan
barang, harga total penawaran dalam angka dan huruf, masa berlaku penawaran,
lamanya waktu penyelesaian pekerjaan, nilai jaminan penawaran dalam angka dan
huruf, kesanggupan memenuhi persyaratan yang ditentukan, dilampiri dengan
78
daftar volume dan harga pekerjaan, dan ditandatangani oleh pimpinan/direktur
utama perusahaan atau yang dikuasakan di atas materai dan bertanggal.
i. Bentuk kontrak : memuat tanggal mulai berlakunya kontrak, nama dan alamat para
pihak, nama paket pekerjaan yang diperjanjikan, harga kontrak dalam angka dan
huruf, pernyataan bahwa kata dan ungkapan yang terdapat dalam syarat-syarat
umum/khusus kontrak telah ditafsirkan sama bagi para pihak, kesanggupan
penyedia barang yang ditunjuk untuk memperbaiki kerusakan pekerjaan atau
akibat pekerjaan, kesanggupan pengguna barang untuk membayar kepada
penyedia barang sesuai dengan jumlah harga kontrak, dan tanda tagan para pihak
di atas materai.
j. Bentuk surat jaminan penawaran : memuat nama dan alamat pengguna barang,
penyedia barang, dan pihak penjamin, nama paket pekerjaan yang dilelangkan,
besar jumlah jaminan penawaran dalam angka dan huruf, pernyataan pihak
penjamin bahwa jaminan penawaran dapat dicairkan dengan segera sesuai
ketentuan dalam jaminan penawaran, masa berlaku surat jaminan penawaran, batas
akhir waktu pengajuan, tuntutan pencairan surat jaminan penawaran oleh
pengguna barang kepada pihak penjamin, mengacu kepada Kitab UU Hukukm
Perdata, khusunya Pasal 1831 dan 1832, dan tanda tangan penjamin.
2.2.3 e-Procurement
Menurut Ashis K. Pani and Amit Agrahari (2007, p22), "Procurement
encompasses a range of activities such as information search, requisition request,
approval, purchase order, delivery receiving, and payment (operational activities), and
79
identifying sourcing opportunities, negotiation, and contract (strategic activities)
(Gebauer & Segev, 2001).”, artinya Pengadaan meliputi berbagai kegiatan seperti
pencarian informasi, permintaan daftar permintaan, persetujuan, pesanan pembelian,
pengiriman penerimaan, dan pembayaran (kegiatan operasional), dan mengidentifikasi
peluang-peluang sourcing, negosiasi, dan kontrak (kegiatan strategis) (Gebauer &
Segev, 2001).
Sedangkan e-procurement adalah “Electronic procurement (e-procurement), has
been defined as the use of Internet-based information and communication technologies
(ICTs) in order to carry out one or more transactional or strategic procurement
activities.”, artinya Elektronik pengadaan (e-procurement) telah didefinisikan sebagai
penggunaan internet berbasis teknologi informasi dan komunikasi (ICT) dalam rangka
untuk melaksanakan satu atau lebih transaksi atau kegiatan strategis pengadaan.
2.2.4 MySQL
Menurut Sidik (2003, pp1-2), MySOL merupakan software sistem manajemen
database (Database Management System - DBMS) yang sangat popular dikalangan
pemrograman web, terutama di lingkungan Linux dengan mengunakan script PHP,
maupun Perl. Software database ini telah tersedai juga dalam Platform system operasi
Windows.
Kepopuleran MySQL disebabkan karena kemudahannya untuk digunakan, cepat
secara kinerja query, dan mencukupi untuk kebutuhan database perusahaan-perusahaan
skala menengah-kecil.
80
Database MySQL tersedia secara bebas, dan dapat digunakan secara bebas oleh
semua orang. Database MySQL, merupakan database yang menjanjikan sebagai
alternative pilihan database yang dapat digunakan untuk sistem database yang dapat
digunakan untuk sistem database personal atau organisasi kita.
2.2.5 World Wide Web (WWW)
World Wide Web, merupakan dasar untuk membuat apliksai berbasis web atau
Web Based Application. World Wide Web merupakan salah satu dari sekian banyak
layanan yang disediakan oleh jaringan internet. Sebenarnya masih banyak fasilitas-
fasilitas yang disediakan oleh internet seerti E-mail, Telnet, FTP dan sebagainya.
Bahkan layanan-layanan tersebut hingga saat ini masih terus bertambah dan
berkembang.
Menurut Mannino (2003,p638) World Wide Web merupakan aplikasi yang paling
popular diantara aplikasi-aplikasi lainnya di internet. Dengan menggunakan WWW kita
dapat melakuka browsing halaman web yang terdapat di computer manapun yang
terhubung ke jaringan Internet. Standar yang menjadi dasar layanan WWW di Internet
adalah Hypertext. Transfer Protocol (HTTP). HTTP membentuk suatu Session anatara
browser dan web server. Selama terbentuk session browser dan web server akan saling
berinteraksi mengirim dan menerima file yang berisi halaman-halaman web. Tiap-tiap
halaman web memiliki alamat unik tertentu yang disebut sebagai Uniform Resource
Locator (URL). URL dibagi menjadi tiga bagian, bagian peratama menunjukan protocol
yang digunakan sebagai server, bagian kedua menunjukan alamat computer yang berada
di jaringan Internet yang berisi suatu file. Alamat computer ini akan diterjemahkan
81
kedalam alamat dengan format numericI yang biasa disebut sebagai IP address. Bagian
ketiga dari URL menujukkan direktori dan nama file halaman web yang berada di dalam
suatu computer pada jaringan Internet.
Contoh dari halaman URL adalah sebagai berikut
http://www.microsoft.com/product/default.html, http:// menunjukan bagian pertama dari
URL, www.microsoft.com menunjukkan bagian ketiga dari URL.
2.2.6 Professional Home Page (PHP)
Menurut Vaswani (2005, p7) PHP pada awalnya adalah kepanjangan dari Personal
Home Page, lalu berubah menjadi Professional Home Page sedangkan kiki nama
resminya adalah PHP Hypertext Prepocessor adalah bahas pemrograman yang
memungkinkan kita untuk membuat logika bisnis yang canggih kedalaam halaman
website static kita. PHP menjadi bahasa yang sangat cepat popular untuk data-driven
web applications karena PHP sangat luas dukungannya terhadap bermacam-macam
sistem database.
Biasanya PHP ditanam ke dalam dokumen HTML biasa dan akan diproses oleh
server ketika halaman web kita di-request oleh client melalui browser. Karena PHP
diproses di server maka kita tidak perlu khawatir apabila script kita nanti dilihat orang
lain. Script PHP tidak dapat dilihat dari client, karena PHP hanya akan menampilkan
HTML sebagai hasil dari proses request dari client yang dilakukan di server.
Fitur-fitur PHP antara lain adalah sebagai berikut:
1. Simplicity, PHP menggunakan syntax yang logis dan konsisten dan karena hal
tersebut bahasa tersebut menjadi lebih mudah dipahami
82
2. Portability, PHP dapat berjalan pada berbagai macam platform. Platform tersebut
diantaranya adalan UNIX, LINUX, Windows OS/2 dan Mac OS.
3. Speed, PHP dapat dijalankan lebih cepat dibandingkan bahasa-bahasa script sisi
server sejenis.
4. Open Source, penggunaan PHP tidak dipungut biaya secara komersial, karena PHP
dapat digunakan secara gratis.
5. Extensible, PHP mendukung proses perkembangan untuk aplikasi di masa depan.
6. Mendukung XML dan database, tidak perlu khawatir jika kita memiliki data dari
dokumen XML, karena PHP sudah mendukung penggunaan file XML dan
mendukung juga banyak database.