BAB 2

LANDASAN TEORI

2.1 Pendekatan Basis Data

2.1.1 Data

Menurut Conolly (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 James A. O’Brien, 2003, p13, Data adalah fakta-fakta

atau observasi yang mentah, biasanya mengenai kejadian / transaksi

bisnis.

Menurut Jeffery L. Whitten (2004, p23), Data adalah fakta mentah

mengenai orang, tempat, kejadian, dan hal-hal penting dalam organisasi.

Jadi arti data adalah fakta-fakta mengenai segala sesuatu yang

dapat diolah untuk menghasilkan informasi yang akan dipakai dalam

melakukan transaksi-transaksi di perusahaan / organisasi.

2.1.2 Database

Menurut Jeffery L. Whitten (2004, p518), Database adalah

kumpulan file yang saling terkait.

Menurut Conolly (2005,p14), Database adalah sekumpulan data

yang terhubung secara logical, dan deskripsi dari data tersebut, yang dapat

  8

digunakan oleh banyak user, dan dibentuk untuk dapat menghasilkan

informasi yang dibutuhkan oleh organisasi.

Menurut James A. O’Brien (2003,p145), Database adalah sebuah

kumpulan yang terintegrasi dari elemen data yang terhubung secara

logical. Elemen data mendeskripsikan entitas dan hubungan antar entitas.

Menurut McLeod (2001, p16), Database adalah suatu koleksi data

komputer yang terintegrasi, diorganisasikan, dan disimpan dengan suatu

cara yang memudahkan pengambilan kembali.

Menurut Hoffer (2002, p4), database adalah kumpulan data yang

terorganisir dan sercara logika berkaitan. Terorganisir maksudnya data

distrukturkan sehingga mudah untuk disimpan, dimanipulasi, dan

diperoleh oleh pengguna. Berkaitan maksudnya adalah data

menggambarkan daerah asal (domain) kepentingan tertentu bagi

kelompok pengguna dan pengguna dapat menggunakan data untuk

menjawab pertanyaan seputar domain itu.

Menurut Turban (2003, p16), database merupakan kumpulan file

atau record yang terorganisir yang menyimpan data berserta hubungan

diantara data tersebut.

Jadi, database adalah kumpulan data atau koleksi file atau record

yang menyimpan data yang berhubungan dan terstruktur sehingga mudah

untuk disimpan, diperoleh kembali, dimanipulasi dan dapat memenuhi

kebutuhan informasi dari suatu organisasi.

  9

2.1.3 Database Management Sistem

Menurut Connolly (2002, p16), Database Management System

(DBMS) adalah sebuah sistem piranti lunak yang memperbolehkan

pengguna untuk menggambarkan / mendefinisikan, membuat, menjaga /

memelihara, dan mengontrol akses ke basisdata.

Menurut Jeffery L. Whitten (2004, p520), Database Management

System (DBMS) adalah perangkat lunak khusus yang digunakan untuk

membuat, mengontrol, dan mengelola sebuah database.

Menurut Date (2000, p43), DBMS merupakan piranti lunak yang

menangani seluruh akses terhadap basis data.

Jadi, DBMS adalah suatu sistem piranti lunak yang menyediakan

fasilitas yang memungkinkan pengguna untuk mendefinisikan, membuat,

memelihara, mengendalikan, dan menangani /mengontrol seluruh akses

terhadap database.

2.1.4 Model Entity Relasional

Menurut Connolly dan Begg (2002, p330), Pemodelan ER

merupakan pendekatan top-down terhadap perancangan basis data yang

dimulai dengan mengidentifikasikan data penting yang disebut entity dan

relationship antara data yang harus ditampilkan dalam model.

Jadi, model entity relasional adalah suatu tahapan dalam

perancangan basisdata yang menggambarkan (memodelkan) hubungan

antara satu entity dengan entity lainnya.

  10

2.1.5 Model Relational

Menurut Conolly (2005, p74), Database model relational adalah

kumpulan dari relations yang telah mengalami proses normalisasi dan

memiliki nama relation yang berbeda.

Menurut Elmasri (2000, p196), model relasional

merepresentasikan database sebagai kumpulan relasi. Dimana relasi itu

kita bayangkan sebagai sebuah tabel yang berisi kumpulan data yang

terhubung.

Jadi, model relasional adalah kumpulan dari relasi berbeda yang

mengalami proses normalisasi.

2.1.6 Metodologi siklus hidup aplikasi database (Database Application

Lifecycle)

Menurut Connolly (2005, p283), sistem basis data merupakan

komponen dasar dari organisasi yang lebih besar dengan sistem informasi

yang lebih luas.

Hal yang penting untuk diakui adalah bahwa tahapan dalam

database application lifecycle tidak sepenuhnya harus berurutan, tetapi

melibatkan beberapa jumlah repetisi dari tahapan sebelumnya melalui

perulangan feedback. Misalnya, masalah yang ditemui selama

perancangan basis data (database design) dapat mengharuskan tambahan

kebutuhan pengumpulan dan analisis (requirement collection and

analysis).

  11

Untuk sistem basis data yang kecil, dengan jumlah pengguna yang

sedikit, lifecycle tidak membutuhkan yang benar-benar kompleks.

Bagaimanapun, ketika merancang sebuah sistem basis data menengah ke

atas dengan sepuluh sampai ribuan pengguna, menggunakan ratusan query

dan program aplikasi, lifecycle dapat menjadi luar biasa kompleks.

Tahapan database application lifecycle dapat dilihat pada gambar

dibawah ini :

Gambar 2.1. Tahapan database application lifecycle (Connolly, 2005, p284)

Prototyping (optional) Implementation

Data conversion and loading

Operational maintance

testing

Database design

Database Planning

System Definition

Requirement collection and analysis

DBMS selection (optional)

Application design

Conceptual Database Design

Logical Database Design

Physical Database Design

  12

2.1.6.1 Perencanaan Basis Data

Perencanaan Basis Data (Database planning) merupakan aktivitas

manajemen yang memperkenankan tahapan database application lifecycle

direlasikan seefisien dan seefektif mungkin. Perencanaan basis data harus

diintegrasikan dengan semua strategi sistem informasi organisasi. Ada

tiga isu pokok yang terlibat dalam perumusan strategi sistem informasi,

diantaranya :

- Identifikasi rencana dan tujuan perusahaan, kemudian

menentukan kebutuhan sistem informasi.

- Evaluasi sistem informasi yang ada untuk menentukan

kelebihan dan kelemahan yang ada.

- Penafsiran kesempatan teknologi informasi yang dapat

menghasilkan kekuatan kompetitif.

Langkah penting pertama dalam perencanaan basis data adalah

mendefinisikan dengan jelas mission statement untuk proyek basis data.

Mission statement mendefinisikan tujuan dari aplikasi basis data. Mission

statement membantu untuk menjelaskan tujuan dari proyek basis data dan

memberi garis yang jelas terhadap pembuatan aplikasi basis data yang

dibutuhkan secara efisien dan efektif. Biasanya direktur atau pemilik

perusahaan yang menegaskan mission statement.

Setelah mission statement didefinisikan, maka langkah selanjutnya

adalah menetapkan mission objectives. Setiap mission objective akan

  13

menetapkan tugas khusus yang harus didukung oleh basis data. Jika basis

data mendukung mission objective, maka mission statement akan didapat.

Dengan kata lain, mission statement bisa didapatkan dengan

melakukan wawancara dengan direktur atau pegawai lainnya yang

berhubungan dengan hal-hal seperti: apa tujuan perusahaan, kenapa

perusahaan membutuhkan basis data, bagaimana basis data dapat

menyelesaikan masalah perusahaan, dan sebagainya. Sedangkan mission

objective dapat diperoleh dengan mengajukan pertanyaan seperti : apa

pekerjaannya, tugas apa yang dilakukan setiap hari, leporan apa yang

dihasilkan, pelayanan apa yang diberikan perusahaan terhadap pelanggan,

dan sebagainya. (Connolly, 2005, pp285-286)

2.1.6.2 System Definiton

System definition mendeskripsikan jangkauan dan batasan dari

aplikasi basis data dan pendangan para pengguna.

User views menentukan apa yang dibutuhkan oleh aplikasi basis

data untuk jabatan tertentu seperti, manajer atau supervisor atau bidang

aplikasi perusahaan seperti, pemasaran, personalia, atau kontrol

persediaan.

Sebelum merancang aplikasi basis data, diperlukan identifikasi

terhadap batasan dari sistem dan bagaimana antar mukanya dengan bagian

lain dari sistem informasi organisasi. Sistem yang dibuat, diusahakan agar

  14

tidak hanya mencakup pengguna dan aplikasi yang sekarang, tetapi juga

pengguna dan aplikasi untuk masa yang akan datang.

Aplikasi basis data dapat memiliki satu atau lebih User views.

User views menentukan apa yang dibutuhkan oleh aplikasi basis data dari

perspektif peranan pekerjaan tertentu (seperti manajer atau supervisor)

dan area aplikasi perusahaan (seperti pemasaran, personalia, atau kontrol

persediaan). Mengidentifikasi pandangan pengguna tersebut merupakan

aspek penting dalam mengembangkan aplikasi basis data karena dapat

membantu meyakinkan bahwa tidak ada pengguna utama yang terlupakan

ketika sedang mengembangkan kebutuhan untuk aplikasi baru. User views

juga membantu dalam pengembangan aplikai basis data yang kompleks.

(Connolly, 2005, pp286-287)

2.1.6.3 Analisis dan pengumpulan kebutuhan

Analisis dan pengumpulan kebutuhan (requirement collection and

analysis) adalah proses mengumpulkan dan menganalisis informasi

tentang bagian dari organisasi yang akan didukung oleh aplikasi basis data

dan menggunakan informasi untuk mengidentifikasi kebutuhan pengguna

dalam sistem yang baru.

Pada tahap ini ada beberapa teknik yang digunakan untuk

mengumpulkan data yang dinamakan fact-finding techniques. Teknik-

teknik yang digunakan antara lain: mempelajari dokumen, wawancara,

pengamatan terhadap kegiatan perusahaan, penelitian, dan kuisioner.

  15

Hal penting lainnya yang tekait dengan tahap ini adalah

memutuskan bagaimana menghadapi situasi dimana terdapat lebih dari

satu pandangan pengguna untuk aplikasi basis data. Ada tiga pendekatan

utama untuk mengatasi situasi tersebut, yaitu:

- Centralized approach

Kebutuhan-kebutuhan untuk setiap pandangan pengguna

digabungkan menjadi satu perangkat kebutuhan untuk aplikasi

basis data yang baru.

- View integration approach

Kebutuhan-kebutuhan untuk setiap pandangan pengguna

digunakan untuk membangun model data terpisah yang akan

merepresentasikan pendangan pengguna tersebut. Hasil dari

model data kemudian digabungkan pada tahap perancangan

basis data.

- Combination of both approaches

Merupakan kombinasi dari centralized approach dan view

integration approach. (Connolly, 2005, pp288-291)

2.1.6.4 Perancangan Basis data (Database Design)

Perancangan basis data adalah proses membuat rancangan basis

data yang akan mendukung misi dan sasaran perusahaan untuk sistem

basis data yang dibutuhkan. Ada dua pendekatan utama pada perancangan

basis data, yaitu :

  16

- Bottom-up approach

Pendekatan ini dimulai dari tingkat paling dasar yaitu atribut

(property dari entitas dan hubungan relasional) dimana melalui

analisis gabungan antara atribut-atribut, dikelompokkan ke dalam

relasi-relasi yang merepresentasikan tipe-tipe entitas dan hubungan

entitas. Pendekatan ini biasanya digunakan ketika akan merancang

basis data yang sederhana dengan atribut dalam jumlah yang sedikit.

- Top-down approach

Pendekatan ini dimulai dari pengembangan model data yang

terdiri dari beberapa hubungan relasional dan entitas tingkat tinggi.

Pendekatan ini biasanya digunakan ketika akan merancang basis data

yang kompleks dengan jumlah atribut yang banyak.

Perancangan basis data dibagi menjadi tiga tahapan utama, yaitu :

- Conceptual database design (perancangan basis data

konseptual)

Proses membangun sebuah model data dari informasi

yang diperoleh dari sebuah organisasi, tetapi bebas dari semua

pertimbangan fisik.

  17

- Logical database design (perancangan basis data logikal)

Proses membangun sebuah model dari informasi yang

diperoleh dari sebuah organisasi berdasarkan model data

khusus, tetapi bebas dari hal yang berkaitan dengan DBMS dan

pertimbangan fisik lainnya.

- Physical database design (perancangan basis data fisikal)

Merupakan proses pembuatan deskripsi dari suatu

implementasi basis data pada media penyimpanan (Connolly,

2005, pp291-295). Adapun beberapa hal yang dikerjakan pada

tahap fisikal ini adalah :

• Menerjemahkan model data logical global untuk target

DBMS

• Mendesain representasi fisikal

• Mendesain user view

• Mendesain mekanisme keamanan

• Mempertimbangkan penggunaan redudansi yang

terkontrol

• Mengawasi dan mengurus sistem operasional

  18

2.1.6.5 DBMS Selection (Pemilihan DBMS)

Menurut Connolly (2005, p295), DBMS selection (Pemilihan

DBMS) adalah proses memilih DBMS yang sesuai untuk mendukung

aplikasi basis data.

Jika belum terdapat DBMS, bagian daur hidup (lifecycle) yang

digunakan untuk membuat sebuah seleksi adalah antara tahapan

conceptual database design dan logical database design.

Tujuan dari pemilihan DBMS adalah untuk mencukupi kebutuhan

sekarang maupun kebutuhan masa yang akan datang pada perusahaan,

membuat keseimbangan biaya termasuk pembelian produk aplikasi basis

data, biaya yang berhubungan dengan perubahan dan pelatihan pegawai.

Tahap-tahap pemilihan DBMS :

- Menentukan istilah referensi pembelajaran

Istilah referensi untuk pemilihan DBMS yang sudah

ditetapkan, penetapan objektif dan ruang lingkup pembelajaran

serta tugas-tugas yang harus dilakukan. Dokumen ini juga

termasuk deskripsi kriteria yang digunakan untuk mengevaluasi

produk DBMS, daftar-daftar produk yang mungkin dipakai, semua

batasan yang diperlukan, dan skala waktu untuk studi.

- Membuat daftar pendek dua atau tiga produk

Kriteria yang dipertimbangkan untuk menjadi kritis agar

implementasi dapat berjalan lancar dan dapat digunakan untuk

  19

membuat daftar persiapan evaluasi untuk produk DBMS. Sebagai

contoh, keputusan untuk memasukkan produk DBMS mungkin

tergantung pada anggaran yang tersedia, tingkat dukungan vendor,

kesesuaian dengan piranti lunak lainnya, dan apakah produk dapat

berjalan pada perangkat keras lainnya. Informasi-informasi

tambahan lainnya dapat diperoleh dengan menghubungi pengguna

yang menyediakan rincian spesifik tentang seberapa baik dukungan

vendor, bagaimana produk dapat mendukung program aplikasi

tertentu, dan apakah suatu perangkat keras tertentu lebih

bermasalah daripada perangkat keras yang lainnya.

- Mengevaluasi produk

Ada berbagai fitur yang dapat digunakan untuk

mengevaluasi DBMS. Untuk tujuan evaluasi, fitur-fitur tersebut

dapat dinilai sebagai kelompok (sebagai contoh, definisi data) atau

perorangan (sebagai contoh, ketersediaan tipe data). Fitur-fitur

yang memungkinkan untuk evaluasi produk DBMS dikelompokkan

berdasarkan definisi data, definisi fisik, pengaksesan, penanganan

transaksi, kegunaan, pengembangan, dan fitur-fitur lainnya.

Definisi data meliputi pemberian primary key, sepesifikasi

foreign key, keberadaan tipe data, perluasan tipe data, spesifikasi

domain, Kontrol integritas, mekanisme view, kamus data, dan

kebebasan data.

  20

Definisi fisik meliputi keberadaan struktur file,

pemeliharaan struktur file, pengurangan organisasi ulang,

pemberian index, variable panjang field/record, kompresi data,

enkripsi secara rutin, kebutuhan memori, dan kebutuhan

penyimpanan.

Pengaksesan meliputi query language, compliant, interface

dari 3GLs, multi-user, security (keamanan), access control (kontrol

akses). Authorization mechanism (mekanisme otorisasi).

Penanganan transaksi meliputi backup dan recovery

routines, strategi resolusi deadlock, kemajuan model transaksi,

parallel query processing.

Kegunaan meliputi performance measuring, tuning,

fasilitas load/unload, user usage monitoring , database

administration support.

Pengembangan meliputi 4GL/5GL tools, CASE tools,

kemampuan windows, prosedur penyimpanan, triggers, rules, web

development tools.

Fitur-fitur lainnya meliputi upgradability, stabilitas vendor,

user base, training dan user support, dokumentasi, sistem operasi,

biaya, online help, penggunaan standar, scalability, mendukung

untuk analytical tools, interoperability dengan DBMS dari sistem

lain, integrasi jaringan, replication utilities, kemampuan distribusi,

portability, kebutuhan perangkat keras, dukungan jaringan,

  21

kemampuan berorientasi objek, arsitektur, penampilan, transaction

throughput, pengguna dalam jumlah maksimum, dan dukungan

XML.

Langkah akhir dari pemilihan DBMS adalah

mendokumentasi proses-proses yang terjadi dan menyediakan

pernyataan untuk merekomendasikan prosuk DBMS yang terpilih.

(Connolly, 2005, pp295-299)

2.1.6.6 Application design

Menurut Connolly (2005, p299), perancangan aplikasi

(application design) adalah perancangan antarmuka pengguna dan

program aplikasi yang menggunakan dan memproses basis data.

Perancangan basis data dan perancangan aplikasi adalah aktivitas

yang dilakukan bersamaan dalam database application lifecycle. Dalam

kasus yang sebenarnya, tidak mungkin dapat menyelesaikan perancangan

aplikasi sebelum perancangan basis data selesai.

Ada dua aspek penting dalam perancangan aplikasi, yaitu :

- Transaction design (Perancangan transaksi)

Transaksi merupakan satu atau serangkaian transaksi yang

dilakukan oleh pengguna atau program aplikasi yang mengakses atau

mengubah isi dari basis data.

  22

Tujuan dari perancangan transaksi adalah menetapkan dan

mendokumentasikan karakteristik tingkat tinggi dan transaksi yang

dibutuhkan pada basis data, diantaranya :

1. Data yang digunakan dalam transaksi

2. Karakteristik fungsional dari transaksi

3. Keluaran (output) dari transaksi

4. Kepentingan pengguna

5. Nilai yang diharapkan dari pengguna

Perancangan ini dilakukan lebih awal dalam proses

perancangan untuk memastikan bahwa basis data yang

diimplementasikan mempu mendukung semua transaksi yang

dibutuhkan.

Ada tiga jenis transaksi:

a. Retrieval transaction

Digunakan untuk mendapatkan kembali data untuk ditampilkan

dalam laporan.

b. Update transaction

Digunakan untuk menambah data, menghapus data lama, atau

mengubah data yang sudah adal dalam basis data.

c. Mixed transaction

Merupakan kombinasi antara Retrieval transaction dan Update

transaction.

  23

- User interface design (Perancangan antarmuka)

Sebelum mengimplementasikan sebuah form atau laporan,

perlu dirancang tampilannya terlebih dahulu. Ada beberapa pedoman

dalam perancangan pelaporan, yaitu :

1. Pemberian judul yang berarti

2. Instruksi yang dapat dipahami

3. Pengelompokan secara logical dan pengurutan field

4. Tampilan form/report secara visual

5. Nama field yang familiar

6. Pemakaian istilah dan singkatan yang konsisten

7. Penggunaan warna secara konsisten

8. Ruang yang tersedia dan cakupan untuk field pemasukkan data

9. Perpindahan kursor yang tepat

10. Perbaikkan kesalahan untuk karakter individual maupun untuk

field secara keseluruhan

11. Pesan kesalahan untuk nilai yang tidak dapat diterima

12. Field pilihan ditandai dengan jelas

13. Pesan penjelasan untuk field

14. Penanda akhir

  24

2.1.6.7 Prototyping

Menurut Connolly (2005, pp303-304), prototyping adalah

membuat model kerja dari aplikasi basis data.

Model kerja memungkinkan perancang atau pengguna untuk

mengevaluasi hasil akhir sistem, baik dari segi sistem maupun fungsi yang

dimiliki sistem.

Tujuan utama dari pengembangan prototype aplikasi basis data

adalah untuk memungkinkan pengguna memakai prototype tersebut dalam

mengidentifikasi kelebihan atau kekurangan sistem, dan memungkinkan

perancang untuk memperbaiki atau melengkapi fitur-fitur aplikasi basis

data yang baru.

Ada dua strategi prototyping yang umum digunakan, yaitu :

- Requirement prototyping

Menggunakan prototype untuk menetapkan tujuan dari

aplikasi basis data dan ketika tujuan sudah terpenuhi, prototype tidak

digunakan lagi atau dibuang.

- Evolutionary prototyping

Digunakan untuk tujuan yang sama. Perbedaannya adalah

prototype yang sudah dipakai tidak dibuang, tetapi dikembangkan

lebih jauh menjadi aplikasi basis data yang baru. (Connolly, 2005,

pp303-304)

  25

2.1.6.8 Implementation

Menurut Connolly (2005, p304), implementation (implementasi)

adalah realisasi fisik dari basis data dan rancangan aplikasi.

Implementasi basis data dapat dicapai dengan menggunakan Data

Definition Language (DDL) dari DBMS yang dipilih atau graphical user

interface (GUI). Pernyataan GUI digunakan untuk membuat struktur basis

data dan file basis data kosong.

User view lainnya juga diimplementasikan dalam tahapan ini.

Program aplikasi diimplementasikan dengan menggunakan bahasa

generasi ketiga atau keempat (3GL atau 4GL). Bagian dari program

aplikasi ini adalah transaksi basis data, dimana diimplementasikan dengan

menggunakan Data Manipulation language (DML) dari DBMS sasaran,

yang mungkin disimpan dalam sekumpulan bahasa pemrograman seperti

visual basic, Delphi, C, C++ atau Pascal.

2.1.6.9 Data Conversion and Loading

Menurut Connolly (2005, p305), data conversion and loading

adalah memindahkan data yang sudah ada ke dalam basis data yang baru

dan mengubah aplikasi yang sudah ada untuk dijalankan pada basis data

yang baru.

Tahapan ini diperlukan ketika sistem basis data yang baru akan

menggantikan sistem basis data yang lama. Pada masa sekarang, DBMS

umumnya memiliki fungsi untuk memasukkan file ke dalam basis data

  26

yang baru. Fungsi ini memungkinkan pengembang untuk mengkonversi

dan menggunakan program aplikasi yang lama dalam sistem yang baru.

2.1.6.10 Testing

Menurut Connolly (2005, p305), testing adalah proses

menjalankan program aplikasi dengan tujuan menemukan kesalahan-

kesalahan yang mungkin ada pada program aplikasi tersebut.

Sebelum digunakan, aplikasi basis data yang baru

dikembangkan harus diuji secara menyeluruh terlebih dahulu. Di

dalam merancang basis data, pemakai yang menggunakan sistem baru

seharusnya terlibat dalam proses testing. Salah satu cara menguji

sistem adalah dengan menguji basis data pada perangkat keras yang

berbeda. Namun, hal ini sering tidak dilakukan karena jika data asli

yang digunakan, maka diperlukan back up untuk mengantisipasi

kesalahan. Selelah testing selesai, aplikasi siap digunakan dan

diserahkan kepada pengguna.

2.1.6.11 Operational Maintenance

Menurut Connolly (2005, p306), operational maintenance

(pemeliharaan operasional) adalah proses pemantauan dan

pemeliharaan sistem setelah instalasi dilakukan.

  27

Pada tahap sebelumnya sistem telah diimplementasikan dan

diuji. Sekarang sistem memasuki tahap perawatan, yang melibatkan

aktivitas sebagai berikut :

- Mengawasi kinerja dari sistem.

Jika kinerjanya mengalami penurunan di bawah level yang

dapat diterima, maka basis data perlu diperbaiki.

- Memelihara dan meng-upgrade basis data (bila diperlukan)

Ketika basis data sepenuhnya bekerja, perlu dipastikan

bahwa kinerjanya berada pada level yang dapat diterima oleh

pengguna. Sebuah DBMS biasanya menyediakan berbagai

kegunaan untuk membantu administrasi basis data termasuk

kegunaan untuk melakukan pengisian data dan pemantauan sistem

sehingga memungkinkan sistem pemantauan memberikan

informasi tentang pemakaian basis data dan strategi eksekusi

query.

2.1.7 Tahap-tahap Perancangan Basis Data

Sebuah metodologi perancangan adalah suatu pendekatan

terstruktur yang menggunakan prosedur, teknik, alat, dan bantuan

dokumentasi untuk mendukung dan memfasilitasi proses perancangan

(Connoly 2005, p438).

  28

Dalam penyajian metodologi perancangan basis data, proses

perancangan terbagi menjadi 3 tahap utama; konseptual, logikal, dan

fisikal. (Connoly 2005, p439).

2.1.7.1 Perancangan Konseptual

Langkah 1 Membangun Model Data Konseptual

Perancangan konseptual basis data adalah proses konstruksi

sebuah model dari data yang digunakan dalam perusahaan, yang tidak

bergantung pada seluruh perkiraan fisikal. (Connolly 2005, p439).

Tahap perancangan basis data konseptual diawali dengan

pembuatan sebuah model data konseptual perusahaan, yang secara

keseluruhan tidak bergantung pada detail-detail implementasi; seperti

DBMS target, program-program aplikasi, bahasa-bahasa pemrograman,

platform perangkat keras, masalah-masalah perfomansi, dan perkiraan-

perkiraan fisikal lainnya.

Model data konseptual didukung oleh dokumentasi, termasuk di

dalamnya diagram ER dan sebuah kamus data, yang dihasilkan melalui

pengembangan dari model itu. Tahap ini memiliki langkah-langkah

terperinci sebagai berikut :

Langkah 1.1 Identifikasi tipe entitas

Langkah pertama dalam pembangunan model data konseptual

adalah mendefinisikan objek-objek utama yang dibutuhkan pengguna.

Objek-objek ini adalah tipe-tipe entitas untuk model tersebut. Sebuah cara

  29

dalam pengidentifikasian entitas adalah dengan memeriksa spesifikasi dari

kebutuhan-kebutuhan pengguna.

Gambar 2.2. Kamus data entitas yang mendeskripsikan entitas untuk view DreamHome (Connolly, 2005, p444)

Langkah 1.2 Identifikasi tipe relasi

Setelah entitas diidentifikasi, langkah berikutnya adalah

mengidentifikasi seluruh relasi yang berada di antara entitas-entitas ini.

  30

 

Gambar 2.3. Diagram potongan ER yang pertama yang menunjukkan entitas dan tipe relasi untuk Staff user views dari DreamHome (Connolly, 2005, p446)

 

Gambar 2.4. Kamus data relasi yang mendeskripsikan relasi untuk view DreamHome (Connolly, 2005, p447)

Staff BusinessOwner

PropertyForRent

Client 

Lease PreferencePrivateOwner 

Supervisor

Registers    Supervisee

Manages

Views

Holds  StatesAssociated With

0..1 

1..*0..100

0..1

0..10..10

1..1

0..* 

0..*0..*

0..* 0..*

1..1  1..1 

1..1 

1..*

0..1 

1..1

POwns

BOwns

Supervises 

  31

Langkah 1.3 Identifikasi dan menghubungkan atribut dengan entitas

atau tipe relasi

Langkah selanjutnya adalah mengidentifikasi tipe-tipe fakta

tentang entitas dan relasi yang telah dipilih untuk ditunjukkan dalam basis

data.

 

Gambar 2.5. Kamus data atribut yang mendeskripsikan atribut untuk view DreamHome (Connolly, 2005, p450)

Langkah 1.4 Menentukan domain atribut

Sasaran dalam langkah ini adalah menentukan domain untuk

seluruh atribut dalam model. Sebuah domain adalah suatu kelompok nilai

dari satu atau lebih atribut yang diambil nilainya.

Langkah 1.5 Menentukan atribut-atribut candidate key, primary key,

dan alternate key.

  32

Langkah ini menitikberatkan dalam pengidentifikasian candidate

key untuk sebuah entitas dan pemilihan primary key. Sebuah candidate

key adalah seperangkat atribut dari suatu entitas yang secara unik

mengidentifikasi setiap kemunculan dari entitas tersebut. Candidate key

dapat diidentifikasikan lebih dari satu, namun primary key harus

diidentifikasikan hanya sebuah; sementara candidate key yang tersisa

disebut alternate key.

Langkah 1.6 Mempertimbangkan penggunaan dari konsep enhanced

modeling (bersifat opsional).

Mempertimbangkan penggunaan konsep-konsep seperti

spesialisasi / generalisasi, agregasi, atau komposisi dalam melanjutkan

pengembangan model ER.

Langkah 1.7 Mengecek model terhadap redundansi.

Dalam langkah ini, dilakukan pemeriksaan model data konseptual

lokal dengan sasaran obyektif dari pengidentifikasian dan penghilangan

terhadap keberadaan redundansi. Dua aktivitas dalam langkah ini adalah:

1. Memeriksa kembali relasi one-to-one (1:1)

2. Menghilangkan relasi yang redundan.

  33

Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna

Sasaran dari langkah ini adalah mengecek model yang sudah ada

untuk memastikan model itu mendukung transaksi yang dibutuhkan.

Dilakukan 2 aktivitas sebagai berikut:

1. Pendeskripsian transaksi

2. Penggunaan jalur transaksi.

Langkah 1.9 Meninjau kembali model data konseptual dengan

pengguna

Sasaran dalam langkah ini adalah meninjau kembali model data

konseptual terhadap pengguna untuk memastikan bahwa mereka

mempertimbangkan model tersebut menjadi gambaran yang tepat dari

kebutuhan data perusahaan.

Model data konseptual divalidasikan untuk memastikan bahwa

model data tersebut mendukung transaksi-transaksi yang dibutuhkan. Dua

kemungkinan yang muncul untuk memastikan bahwa model data

konseptual mendukung hal itu adalah:

1. Pengecekan bahwa semua informasi (entitas, relasi, dan atribut)

yang dibutuhkan oleh setiap transaksi disediakan oleh model

dengan pendokumentasian suatu deskripsi dari setiap kebutuhan

transaksi.

  34

2. Penyajian cara dalam diagram diperoleh dari setiap transaksi

secara langsung pada diagram ER.

Gambar 2.6. Contoh Diagram ER Konseptual (Connolly, 2005, p452)

2.1.7.2 Perancangan Logikal

Langkah 2 Membangun dan Memvalidasi Model Data Logikal

Perancangan logikal basis data adalah proses konstruksi sebuah

model dari data yang digunakan dalam perusahaan berdasarkan pada suatu

model data yang spesifik, namun tidak bergantung pada suatu DBMS

tertentu dan perkiraan-perkiraan fisikal lainnya (Connoly 2005, p439).

BusinessOwner 

ownerNo 

Staff

staffNo

PropertyForRent

propertyNo

Client

clientNo

viewDate comment

Lease

leaseNo

PrivateOwner 

ownerNo 

BOwns Manages

Views

Holds  States

Registers 

AssociatedWithPOwns 

Supervise

Supervisee

0..1 

0..1 

1..*

1..*

1..1

0..* 0..* 

1..1

1..11..1 

0..* 

0..* 

1..1

Supervisor0..1 

0..10

0..100

Preference

  35

Tahap perancangan basis data logikal memetakan model

konseptual kepada suatu model logikal yang dipengaruhi oleh model data

untuk target basis data (misalnya, model relasi). Model data logikal adalah

suatu sumber informasi untuk tahap perancangan fisikal, menyediakan

perancang fisikal basis data dengan sebuah perangkat untuk pembuatan

tradeoff yang sangat penting untuk rancangan basis data yang efisien.

Sebuah model data logikal memiliki diagram ER, skema relasi,

dan mendukung dokumentasi seperti kamus data, yang dihasilkan pada

keseluruhan pengembangan model.

Pada tahap ini, sasaran utamanya adalah meterjemahkan model

data konseptual yang dibuat pada tahap pertama menjadi sebuah model

data logikal dari kebutuhan data pada perusahaan. Sasaran ini tercapai

melalui aktivitas-aktivitas terperinci yang tertera sebagai berikut:

Langkah 2.1 Membangun Memperoleh relasi-relasi untuk model

data logikal.

Sasaran dari langkah ini adalah membuat relasi untuk model data

logikal untuk menggambarkan entitas, relasi, dan atribut yang telah

diidentifikasi. Komposisi dari setiap relasi dideskripsikan dengan

menggunakan Database Definition Language (DBDL) untuk basis data

relasional.

  36

Langkah 2.2 Validasi relasi dengan normalisasi

Normalisasi adalah suatu teknik dalam memproduksi seperangkat

relasi dengan sifat-sifat yang diinginkan, memberikan data yang

dibutuhkan dari suatu perusahaan (Connoly 2005, pp388).

Aturan Normalisasi:

• Unnormalized Form (UNF)

Pada bentuk tidak normal (unnormalized form—UNF),

tabel masih mengandung satu atau lebih kelompok pengulangan

(repeating groups). Tabel UNF ini dibuat dengan

mentransformasi data dari sumber informasi ke dalam tabel

berbentuk baris dan kolom.

• First Normal Form (1NF)

Pada bentuk normal pertama (first normal form—1NF),

suatu relasi di mana pada setiap sel (perpotongan dari baris dan

kolom) memuat satu dan hanya satu nilai, setiap sel

mengandung nilai atomic (atau single value).

• Second Normal Form (2NF)

Pada bentuk normal kedua (second normal form—2NF),

suatu relasi telah melalui bentuk normal pertama dan setiap

atribut bukan primary key (PK) tergantung fungsional penuh

terhadap PK.

  37

• Third Normal Form (3NF)

Pada bentuk normal ketiga (third normal form—3NF),

suatu relasi telah melalui bentuk normal pertama dan kedua,

serta tidak ada atribut bukan PK tergantung fungsional terhadap

atribut bukan PK yang lain.

 

Langkah 2.3 relasi terhadap transaksi pengguna

Sasaran dalam langkah ini adalah memvalidasi model data logikal

untuk memastikan bahwa model tersebut mendukung transaksi yang

dibutuhkan, dengan detail pada spesifikasi kebutuhan pengguna.

Langkah 2.4 Memeriksa batasan integritas

Batasan integritas adalah batasan yang ditentukan dengan tujuan

untuk melindungi basis data menjadi tidak lengkap, tidak akurat, atau

tidak konsisten. Batasan-batasan tersebut meliputi required data, attribute

domain constraint, entity integrity, referential integrity, serta enterprise

constraint.

Langkah 2.5 Meninjau kembali model data logikal dengan pengguna

Sasaran dalam langkah ini adalah meninjau kembali model data

logikal dengan pengguna untuk memastikan bahwa mereka

mempertimbangkan model tersebut untuk menjadi gambaran yang benar

dari kebutuhan data perusahaan.

  38

Langkah 2.6 Menggabungkan model data logikal ke dalam model

global

Langkah ini hanya diperlukan untuk perancangan dari suatu basis

data dengan banyak pandangan pengguna yang telah diatur dengan

pendekatan integrasi pandangan. Untuk memfasilitasi deskripsi dari

proses penggabungan, digunakan persyaratan model data logikal lokal dan

model data logikal global. Sebuah model data logikal lokal

menggambarkan satu atau lebih namun tidak seluruh pandangan pengguna

dari suatu basis data sementara model data logikal global menggambarkan

keseluruhan pandangan pengguna dari basis data.

Langkah 2.7 Memeriksa pertumbuhan masa depan

Sasaran dari langkah ini adalah menentukan apakah ada

perubahan-perubahan signifikan dalam perkiraan masa depan dan

mengakses apakah model data logikal dapat mengakomodasi perubahan-

perubahan ini. Perancangan basis data logikal menyimpulkan dengan

pertimbangan apakah model data logikal mampu diperluas untuk

mendukung perkembangan masa yang akan datang.

Pada tahap ini, normalisasi dilakukan untuk mengidentifikasi

seperangkat relasi yang sesuai, yang mendukung kebutuhan data dalam

perusahaan. Sifat-sifat dari relasi yang sesuai tersebut adalah sebagai

berikut:

  39

• Jumlah atribut yang diminimalkan diperlukan untuk

mendukung kebutuhan data perusahaan

• Atribut dengan sebuah relasi yang mendekati logikal ditemukan

pada relasi yang sama

• Redundansi yang minimal dengan setiap atribut digambarkan

hanya sekali dengan pengecualian atribut yang merupakan

seluruh atau sebagian foreign key, yang mana esensial untuk

penggabungan relasi yang terkait.

  40

Gambar 2.7. Contoh Diagram ER Logikal (Connolly, 2005, p489)

Manager

staffNo {PK, FK}

Staff 

staffNo {PK} supervisorStaffNo{FK} branchNo {FK} 

Branch 

branchNo {PK} mgrStaffNo {FK} 

Telephone

telNo {PK}branchNo {FK} 

Registration

clientNo {PK, FK}branchNo {FK} staffNo {FK}

Client

clientNo {PK}

Lease

leaseNo {PK} clientNo {FK} propertyNo {FK}

clientNo {PK, FK} propertyNo {PK, FK} 

Viewing 

leaseNo {PK}clientNo {FK} propertyNo {FK} 

PropertyForRent

PrivateOwner

ownerNo {PK}

BusinessOwner

ownerNo {PK}

Advert

propertyNo {PK, FK}newspaperName {PK, FK} dateAdvert {PK} 

Newspaper

newspaperName {PK}

1.. 1

0.. 1

1.. 1 1.. 11.. 1

1.. 1

1.. 1

1.. 11.. 1

1.. 1 1.. 1

1.. 1

1.. 1

0.. 1 

0.. 1 0.. 1

1.. 3

0.. 10 

1.. 1

0.. * 1.. *

1.. 1

1.. 1

1.. *

0.. * 

1.. *

0.. * 

1.. * 1.. *

0.. * 

0.. *  0.. * 

Manages

Provides

Registers 

Requests 

Takes 

Supervises 

Processes

Agrees

Holds 

LeasedBy 

Placedln 

Displays

BOwnsPOwns

Is a

Has

Offers

0.. 100

0.. 1 

Oversees 

  41

2.1.7.3 Perancangan Fisikal

Perancangan fisikal basis data adalah proses produksi sebuah

deskripsi implementasi dari basis data pada tempat penyimpanan kedua;

menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan

untuk mencapai akses yang efisien terhadap data, dan batasan integritas

yang diasosiasikan dan ukuran keamanan. (Connolly, 2005, p439)

Rancangan dari relasi dasar dapat dikerjakan hanya jika perancang

benar-benar mengetahui fasilitas-fasilitas yang ditawarkan dengan DBMS

target.

Metodologi perancangan fisikal basis data memiliki langkah-

langkah sebagai berikut :

Langkah 3 Menterjemahkan model data logikal terhadap DBMS

yang telah ditentukan

Secara umum langkah ini memiliki sasaran untuk menghasilkan

suatu skema basis data relasional dari model data logikal yang dapat

diimplementasikan dalam DBMS target.

Langkah 3.1 Mendesain relasi dasar

Sasaran dari langkah ini adalah menetukan bagaimana

menggambarkan relasi dasar diidentifikasikan pada model data logikal

dalam DBMS target. Pada awal langkah ini, informasi tentang relasi yang

dihasilkan selama perancangan basis data logikal disusun dan diolah.

  42

Informasi penting dapat diambil dari kamus data dan definisi dari

relasi dapat dideskripsikan dengan Database Design Language (DBDL).

Untuk setiap informasi yang diidentifikasi dalam model data logikal,

sebuah definisi terdiri dari:

• Nama relasi

• Daftar atribut-atribut sederhana dalam kelompok

• Primary key yang tepat, alternate key, dan foreign key

• Batasan integritas referensial untuk setiap foreign key yang

diidentifikasi

Langkah 3.2 Mendesain representasi dari data yang diperoleh.

Sasaran dari langkah ini adalah menentukan bagaimana

menggambarkan data yang diperoleh pada model data logikal dalam

DBMS target.

Atribut yang nilainya dapat ditemukan dengan pemeriksaan nilai

dari atribut lain dikenal sebagai atribut yang diperoleh atau

diperhitungkan.

Langkah 3.3 Mendesain batasan umum

Sasaran dari langkah ini adalah merancang batasan umum untuk

DBMS target.

  43

Dalam langkah ini, dirancang sejumlah batasan umum: data yang

dibutuhkan, batasan domain, entitas dan integritas referensial.

Langkah 4 Mendesain organisasi file dan indeks

Secara umum memiliki sasaran menentukan organisasi file optimal

untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk

mencapai performansi yang dapat diterima

Langkah 4.1 Menganalisis transaksi

Sasaran dari langkah ini adalah memahami fungsionalitas dari

transaksi yang akan dijalankan pada basis data dan menganalisis

transaksi-transaksi penting

Dalam langkah ini dilakukan aktivitas-aktivitas berikut:

1. Memetakan seluruh jalur transaksi pada relasi

2. Menentukan relasi mana yang paling sering diakses oleh

transaksi

3. Menganalisis penggunaan data dari transaksi yang dipilih yang

mempengaruhi relasi ini.

Langkah 4.2 Memilih organisasi file

Salah satu sasaran utama dari perancangan basis data fisikal adalah

menyimpan dan mengakses data dengan cara yang efisien.

  44

Sasaran dalam langkah ini adalah memilih sebuah organisasi file

optimal untuk setiap relasi, jika DBMS target memperbolehkan itu. Dalam

banyak kasus, sebuah DBMS relasional dapat memberi sedikit atau tak

ada sama sekali pilihan dalam pemilihan organisasi file, kendati beberapa

dapat ditetapkan sebagai indeks yang dispesifikasikan.

Langkah 4.3 Memilih indeks

Sasaran dari langkah ini adalah menentukan apakah penambahan

indeks akan meningkatkan perfomansi dari sistem.

Sebuah pendekatan dalam pemilihan organisasi file yang tepat

untuk suatu relasi adalah dengan menjaga tuple yang tidak diinginkan dan

membuat banyak indeks secondary sesuai kebutuhan.

Langkah 4.4 Mengestimasi kebutuhan kapasitas disk

Sasaran utama dari langkah ini adalah memperkirakan jumlah disk

space yang akan dibutuhkan untuk mendukung implementasi basis data

pada secondary storage.

Secara umum, perkiraan didasarkan pada ukuran dari setiap tuple

dan jumlah tuple dalam relasi.

  45

Langkah 5 Mendesain user views

Secara umum memiliki sasaran merancang user views yang telah

diidentifikasikan pada tahap pengumpulan kebutuhan dan analisis pada

daur hidup pengembangan basis data.

Langkah 6 Mendesain mekanisme keamanan

Secara umum memiliki sasaran merancang mekanisme

pengamanan untuk basis data yang ditetapkan oleh pengguna selama

tahap kebutuhan dan pengumpulan dari daur hidup pengembangan basis

data.

Langkah 7 Mempertimbangkan penggunaan redundansi terkontrol

Menentukan apakah penggunaan redundansi secara terkontrol akan

dapat meningkatkan performansi sistem.

Langkah 8 Memonitor dan memasang sistem operasional

Mengawasi sistem operasional dan meningkatkan performansi

sistem untuk memperbaiki rancangan-rancangan yang kurang sesuai atau

sebagai refleksi adanya perubahan kebutuhan.

Tahap perancangan basis data fisikal mendukung perancang dalam

pembuatan keputusan mengenai bagaimana basis data akan

diimplementasikan. Oleh karena itu, rancangan fisikal disesuaikan pada

DBMS yang spesifik. Ada umpan balik antara rancangan fisikal dan

  46

logikal, karena keputusan yang diambil selama rancangan fisikal untuk

peningkatan performansi dapat mempengaruhi model data logikal.

2.1.8 E-R Modelling

Salah satu aspek yang paling sulit pada perancangan basis data

adalah fakta bahwa perancang, programmer, dan pengguna akhir

memandang data dan kegunaan dari data tersebut dari sudut pandang yang

berbeda. Namun, sebelum mendapatkan pemahaman umum mengenai

bagaiman cara perusahaan beroperasi, rancangan yang dihasilkan akan

gagal untuk memenuhi kebutuhan pengguna. Untuk mendapatkan

pemahaman yang tepat mengenai data dan bagaimana data itu digunakan

dalam perusahaan, maka diperlukan sebuah model komunikasi yang non-

teknikal dan tidak ambigu. Model entity-relationship adalah salah satu

contohnya.

Model entity-relationship merupakan salah satu model yang

dapat memastikan pemahaman yang tepat terhadap data dan bagaimana

penggunaannya di dalam suatu organisasi. Model ini dimulai dengan

identifikasi entitas dan hubungan antar data yang harus direpresentasikan

di dalam model, kemudian ditambahkan atribut dan setiap constraint pada

entitas, relasi, dan atributnya. (Connoly, 2005, p342)

  47

2.1.8.1 Tipe Entiti

Tipe entitas adalah sekumpulan objek dengan properti yang sama,

yang didefinisikan oleh perusahaan dan keberadaannya tidak tergantung.

Konsep dasar dari Entity Relationship model adalah tipe entitas

yang merepresentasikan kumpulan objek pada dunia nyata dengan sifat

yang sama. Sebuah tipe entitas memiliki keberadaan yang bebas dan bisa

menjadi objek dengan keberadaan fisik (entitas pegawai, rumah, dan

pelanggan) atau menjadi objek dengan keberadaan konseptual (entitas

inspeksi, penjualan, dan pembelian). Perancang yang berbeda mungkin

akan mengidentifikasi entitas yang berbeda.

  48

Gambar 2.8. Entity-Relationship (ER) Diagram dari Branch view DreamHome (Connolly, 2005, p344)

Sekelompok entitas yang sejenis dan berada dalam ruang

lingkup yang sama akan membentuk sebuah himpunan entitas (entity

  49

occurence). Entity occurance adalah objek atau tipe entitas yang dapat

diidentifikasi secara unik.

Gambar 2.9. Representasi diagram dari tipe entitas staff dan branch

(Connolly, 2005, p345)

Tipe entitas dapat diklasifikasikan menjadi:

• Tipe entitas kuat, yaitu tipe entitas yang keberadaannya tidak

bergantung pada tipe entitas lainnya. Karakteristiknya adalah

setiap kejadian entitasnya secara unik mampu diidentifikasikan

dengan menggunakan atribut primary key pada entitasnya.

• Tipe entitas lemah, yaitu Tipe entitas yang keberadaannya

bergantung pada tipe entitas lainnya. Karakteristiknya adalah

setiap kejadian entitasnya tidak bias diidentifikasikan secara unik

hanya dengan menggunakan atribut yang bergantung pada

entitasnya.

  50

2.1.8.2 Tipe Relasi

Tipe relasi adalah gabungan yang mempunyai arti diantara tipe-tipe

entitas. Setiap tipe relationship diberikan nama sesuai dengan fungsinya.

Relationship Occurance adalah suatu gabungan yang dapat diidentifikasi

secara unik, meliputi suatu kejadian dari dari setiap tipe entitas yang

berpartisipasi.

Gambar 2.10. Jaringan semantik yang menunjukkan hubungan individual dari tipe relasi Has (Connolly, 2005, p346)

Gambar 2.11. Representasi diagram tipe relasi Branch has Staff (Connolly, 2005, p347 )

  51

Biasanya sebuah relationship dinamakan dengan menggunakan kata kerja,

seperti Membeli, atau dengan frase singkat yang meliputi kata kerja,

seperti Dibelioleh. Tanda panah diletakkan di samping nama relationship

yang mengidentifikasikan arah bagi pembaca untuk mengartikan nama

dari suatu relationship. Kumpulan semua relasi di antara entitas-entitas

yang terdapat pada himpunan entitas membentuk himpunan relasi.

• Derajat dari Tipe Relationship

Derajat dari tipe relationship adalah jumlah tipe entitas yang

ikut serta dalam sebuah relationship. Entitas yang berkaitan dalam

suatu relationship dikenal sebagai participant dalam relationship dan

jumlah participant dalam relationship disebut sebagai derajat dari

relationship.

Complex relationship types adalah jumlah tipe entitas yang

ikut serta dalam sebuah relationship (Connolly, 2005, p445).

Derajat dari tipe relationship dibagi menjadi tiga, yaitu :

• binary

relationship yang memiliki derajat dua

  52

Gambar 2.12. Contoh suatu relasi binary yang disebut POwn (Connolly, 2005, p348)

• ternary

relationship yang memiliki derajat tiga

Gambar 2.13. Contoh suatu relasi ternary yang disebut Registers

(Connolly, 2005, p348)

  53

• quartenary 

relationship yang memiliki derajat empat

Gambar 2.14. Contoh suatu relasi quarternary yang disebut Arranged (Connolly, 2005, p349)

• Recursive Relationship

Recursive Relationship adalah sebuah tipe relationship dimana

tipe entitas yang sama ikut serta lebih dari sekali dengan peran

yang berbeda. (Connolly, 2005, p337). Relationship dapat

diberikan nama peran untuk menentukan fungsi dari setiap entitas

yang terlibat dalam relationship tersebut. Nama peran juga dapat

diberikan jika dua buah entitas dihubungkan melalui lebih dari

satu relationship.

  54

Gambar 2.15. Contoh suatu relasi rekursive yang disebut Supervised (Connolly, 2005, p349) 

2.1.8.3 Atribut

Atribut adalah sifat dari sebuah entitas atau sebuah tipe

relationship. Atribut menampung nilai yang menjelaskan setiap entity

occurance dan menggambarkan bagian utama dari data yang disimpan

dalam basis data.

Atribut domain adalah sekumpulan nilai yang diperbolehkan bagi

satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah

nilai disebut domain. Domain mendefinisikan nilai-nilai yang dimiliki

sebuah atributdan sama dengan konsep domain pada model relasional.

Atribut dapat diklasifikasikan menjadi:

• Simple attribute

Atribut yang terdiri dari komponen tunggal dimana komponen

tersebut tidak dapat dipisahkan lagi. Simple attribute kadang

disebut juga dengan atomic attributes.

  55

• Composite attribute

Atribut yang terdiri dari beberapa komponen, dan keberadaan

setiap komponen bebas. Beberapa atribut dapat dipisahkan

menjadi komponen yang lebih kecil dengan keberadaan yang

bebas.

• Single-valued attribute

Atribut yang memiliki nilai tunggal untuk masing-masing

kejadian dari entitas. Kebanyakan/mayoritas dari atribut

merupakan Single-valued attribute.

• Multi-valued attribute

Atribut yang memiliki banyak nilai untuk masing-masing kejadian

dari entitas. Beberapa atribut memiliki nilai untuk setiap entity

occurance. Multi-valued attribute dapat memiliki jumlah dengan

batas atas maupun dengan batas bawah.

• Derived attribute

Atribut yang nilai-nilainya diperoleh atau diturunkan dari atribut

lain yang berhubungan. Dalam beberapa kasus, nilai dari sebuah

atribut diturunkan terhadap entity occurance dari tipe entitas yang

sama. Derived attribute juga mungkin berhubungan dengan

kumpulan atribut dari tipe-tipe entitas yang berbeda.

  56

2.1.8.4 Kunci (Key)

Candidate key adalah kunci yang secara unik mengenali setiap

kejadian di dalam tipe entitas. Sebuah candidate key tidak boleh NULL.

Sebuah entitas boleh memiliki lebih dari satu candidate key. Composite

key adalah sebuah candidate key yang memiliki dua atau lebih atribut.

Primary key adalah candidate key yang terpilih untuk

mengidentifikasikan secara unik sebuah occurance dari setiap entitas.

Biasanya terdapat lebih dari satu candidate key yang harus dipilih untuk

menjadi primary key. Pemilihan primary key didasarkan pada panjang

atribut, jumlah minimal atribut yang dibutuhkan, dan memenuhi syarat

unik. Candidate key yang tidak terpilih menjadi primary key dinamakan

alternate key.

Foreign key adalah sebuah primary key pada sebuah entitas yang

digunakan pada entitas lain untuk mengidentifikasi sebuah relationship.

  57

Gambar 2.16. ERD dari etitas dan atribut Staff dan Branch (Connolly, 2005, p354)

2.1.8.5 Structural Constraints

Batasan-batasan yang menggambarkan pembatasan pada

relationship seperti yang ada pada real world harus diterapkan pada tipe

entitas yang ikut serta dalam sebuah relationship. Tipe utama dari batasan

hubungan di dalam suatu relationship disebut multiplicity (Connolly,

2005, p356).

Multiplicity adalah jumlah occurance yang mungkin terjadi pada

sebuah tipe entitas yang berhubungan ke sebuah occurance dari sebuah

tipe entitas lain dari suatu relationship.

Derajat yang biasa digunakan dalam suatu relationship adalah

binary relationship, yang terdiri atas :

  58

• Hubungan one to one (1 : 1)

Setiap relationship menggambarkan hubungan antara sebuah

entity occurance pada entitas yang satu dengan entity occurance

pada entitas lainnya yang ikut serta dalam relationship tersebut.

Hubungan 1: 1 dapat terjadi bila setiap entitas pada himpunan

entitas A berhubungan paling banyak satu entitas dengan satu

entitas pada himpunan entitas B. Dan sebaliknya, setiap entitas

pada himpunan entitas B berhubungan paling banyak satu entitas

dengan satu entitas pada himpunan entitas A.

Gambar 2.17. Jaringan semantik pada Staff manage Branch dengan tipe relasi 1:1 (Connolly, 2005, p357)

  59

Gambar 2.18. Multiplicity pada Staff manages Branch dengan tipe relasi 1:1 (Connolly, 2005, p358)

• Hubungan one to many (1 : *)

Setiap relationship menggambarkan hubungan antara sebuah

entity occurance pada entitas yang satu dengan satu atau lebih

entity occurance pada entitas lainnya yang ikut serta dalam

relationship tersebut. Berarti setiap entitas pada pada himpunan

entitas A dapat berhubungan dengan banyak entitas pada

himpunan entitas B. Namun, setiap entitas pada himpunan entitas

B hanya dapat berhubungan dengan paling banyak satu entitas

pada himpunan entitas A.

Gambar 2.19. Jaringan semantik pada Staff overseas PropertyForRent dengan tipe relasi 1:* (Connolly, 2005, p358)

  60

Gambar 2.20. Multiplicity pada Staff overseas PropertyForRent dengan tipe relasi 1:* (Connolly, 2005, p359)

• Hubungan many to many (* : *)

Setiap relationship menggambarkan hubungan antara satu atau

lebih entity occurance pada entitas yang satu dengan satu atau

lebih entity occurance pada entitas lainnya yang ikut serta dalam

relationship tersebut. Berarti setiap entitas pada himpunan entitas

A dapat berhubungan dengan banyak entitas pada himpunan

entitas B, dan sebaliknya, setiap entitas pada himpunan entitas B

dapat berhubungan dengan banyak entitas pada himpunan entitas

A.

  61

Gambar 2.21. jaringan semantik pada Newspaper advertises PropertyForRent dengan tipe relasi *:* (Connolly, 2005, p360)

Gambar 2.22. Multiplicity pada Newspapaper advertise PropertyForRent dengan tipe relasi 1:* (Connolly, 2005, p360)

  62

2.1.9 State Transition Diagram

State Transition Diagram (STD) adalah suatu tools permodelan yang

menggambarkan sifat ketergantungan pada suatu waktu dari suatu sistem.

Adapun simbol yang digunakan adalah :

state / keadaan

perubahan state / keadaan

Untuk melengkapi suatu STD diperlukan dua hal lagi , yaitu

condition (kondisi), merupakan sebuah sinyal yang menyebabkan

perubahan terhadap state dari suatu state satu ke state yang berikutnya dan

action (aksi), adalah yang hal dilakukan sistem bila terjadi perubahan

state atau merupakan suatu reaksi terhadap kondisi.

2.1.10 Perancangan User Interface

Interaksi manusia dengan komputer adalah suatu ilmu yang

berhubungan dengan perancangan, evaluasi, serta implementasi sistem

komputer interaktif yang akan digunakan oleh manusia. Dalam merancang

antarmuka pemakai ( user interface ) perlu menggunkan delapan aturan

emas ( 8 golden rule ) yang terdiri atas :

Berusaha konsisten.

  63

Aplikasi yang dirancang harus konsisten, baik dalam tampilan,

susunan menu, teks ataupun pewarnaan.

Memungkinkan frequent user menggunakan shortcut.

Aplikasi yang dirancang sebaiknya mempunyai fasilitas shortcut (jalan

singkat) bagi user untuk lebih leluasa menjelajahi aplikasi.

Memberikan umpan balik (feedback) yang informatif.

Sebuah aplikasi harus dapat memberikan pelayan navigasi ataupun

informasi mengenai tujuan dari sebuah link, sehingga dapat

mengurangi kesalahan yang mungkin dilakukan oleh user.

Merancang dialog untuk menghasilkan keadaan akhir.

Aksi – aksi yang ada seharusnya diorganisasikan dengan baik untuk

mempunyai suatu awal, pertengahan, dan tahap akhir, seperti sebuah

cerita pendek yang bagus. Dengan adanya umpan balik yang

informatif pada tahap akhir, suatu form akan memberitahukan user

sehingga mereka dapat mengetahui kapan mereka dapat berpindah ke

form berikutnya.

Memberikan pencegahan kesalahan dan penanganan kesalahan yang

sederhana.

Jika terjadi suatu kesalahan, maka aplikasi mampu memberikan

petunjuk sederhana yang praktis dalam menanganinya. Misalnya

disediakannya fasilitas help menu.

Memungkinkan pembalikan aksi ( undo yang mudah ).

  64

Aplikasi harus menyediakan fasilitas bagi user untuk kembali ke menu

sebelumnya dengan mudah.

Mendukung internal focus of control.

Memberikan user hak untuk memutuskan apa yang diperlukan dan

kemudian sistem menyediakan informasi yang dibutuhkan.

Mengurangi beban ingatan jangka panjang.

Aplikasi harus memudahkan user dalam mengingat hal – hal penting.

Misalnya saja dengan mengkombinasikan kode – kode, maka kode

tersebut diusahakan mudah diingat dengan kemampuan berpikir

manusia,yaitu dengan cara kode jangan terlalu panjang.

2.2 Pendekatan Web Database

Web database berasal dari 2 kata, yaitu web dan database. Web

(disebut juga world wide web, www atau W3) adalah ruang informasi di

internet tempat dokumen dokumen hypermedia disimpan dan dapat diambil

melalui suatu skema alamat yang unik. (McLeod, 2001, jilid 1,p75).

Sedangkan database, seperti yang telah dijelaskan pada 2.2 diatas adalah

kumpulan data yang saling terkait secara logikal.

Menurut Eaglestone (2001, p31), web database adalah suatu sistem

yang membawa kemampuan dari database teknologi database dan web. Web

database system dilihat dari 2 sudut pandang : bagaimana menggunakan

DBMS dalam mengelola dan meningkatkan performa aplikasi web dan

bagaimana koneksi ke web bisa mengelola database system.

  65

Web aplikasi adalah web yang secara umum mempertimbangkan

mekanisme dalam menyimpan dan menyediakan akses ke dokumen.

Internet dan web dapat memperluas kemampuan database system

dalam 2 bagian :

1. Akses yang luas : dengan menyambungkan sistem ke internet, maka

populasi user dapat bertambah.

2. Banyak pelayanan : Internet dapat mehubungkan dan menggabungkan

database system yang berbeda untuk menyediakan layanan baru.

Jadi, web database adalah suatu sistem baru yang menggabungkan

kemampuan dari database ke dalam web.