BAB 2 LANDASAN TEORI
2.1 Cause Effect Analysis Cause effect analysis adalah sebuah teknik dimana masalah dipelajari untuk mengetahui penyebab dan akibat dari permasalah tersebut. Permasalahan harus dianalisis penyebab dan akibatnya sampai waktu penyebab dan akibat tidak menghasilkan gejala masalah lain. Cause effect analysis menyebabkan pemahaman yang benar mengenai masalah dan dapat mengarah pada solusi yang tidak begitu jelas, tetapi lebih kreatif dan berharga. (Whitten dan Bentley, 2007, p180) 2.2 Database System Development Lifecycle Ketika software yang dikembangkan database system maka lifecycle yang digunakan adalah database system development lifecycle (DSDLC). Sebuah database system merupakan komponen fundamental dari organisasi yang besar dengan sistem informasi yang luas, database system development lifecycle terkait dengan lifecycle dari information system. Perlu diingat bahwa tahapan dalam database system development lifecycle tidak harus berurutan, namun juga dapat melibatkan beberapa pengulangan ke tahapan sebelumnya melalui feedback loops. Untuk database system, dengan user yang sedikit, lifecycle tidak perlu kompleks. Ketika mendesain sebuah database system yang sedang atau besar dengan sepuluh sampai ribuan user menggunakan ratusan query dan program aplikasi, lifecycle dapat menjadi sangat kompleks. (Connoly dan Begg, 2010, p312) 8
9
Gambar 2.1 Database System Development Lifecycle (Sumber : Connoly dan Begg, 2010, p314) 2.2.1
Database Planning Database
planning
merupakan
kegiatan
pengaturan
yang
memungkinkan tahapan – tahapan database system development lifecycle direalisasikan seefektif dan seefisien mungkin. 2.2.2
System Definition System definition menggambarkan ruang lingkup dan batasan dari database system dan user view utama.
10 User view mendefinisikan apa yang dibutuhkan oleh database system dari sudut pandang peranan pekerjaan tertentu (seperti Manager atau Supervisor) atau area aplikasi perusahaan (seperti marketing, personnel, atau stock control). 2.2.3
Requirement Collection and Analysis Requirement collection and analysis merupakan proses mengumpulkan dan menganalisis informasi mengenai bagian organisasi yang didukung oleh database system, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan untuk sistem yang baru.
2.2.4
Database Design Database design merupakan proses membuat rancangan yang akan mendukung pernyataan misi dan tujuan misi suatu perusahaan untuk database system yang diperlukan.
2.2.5
DBMS Selection (Optional) Memilih sebuah DBMS yang cocok untuk mendukung database system.
2.2.6
Application Design Application design merancang user interface dan aplikasi program yang digunakan dan memproses database.
2.2.7
Prototyping (Optional) Prototyping adalah membangun sebuah model kerja dari database system. Tujuan utama dari mengembangkan prototype database system
11 adalah untuk memungkinkan pengguna menggunakan prototype untuk mengidentifikasi fitur yang bekerja pada sistem bekerja dengan baik atau tidak, dan apabila memungkinkan untuk menyarankan perbaikan atau bahkan fitur baru untuk database system. 2.2.8
Implementation Implementation adalah realisasi fisikal dari database dan rancangan aplikasi. stock control).
2.2.9
Data Convertion and Loading Memindahkan data yang ada ke dalam database yang baru dan mengubah aplikasi yang ada untuk dijalankan pada database yang baru. stock control).
2.2.10 Testing Testing merupakan proses menjalankan database system dengan tujuan untuk menemukan error. 2.2.11 Operational Maintenance Operational
maintenance
merupakan
proses
mengawasi
dan
memelihara database system diikuti dengan instalasi. 2.3 Perancangan Basis Data Database adalah koleksi bersama dari data yang terkait secara logis dan deskripsi dari data tersebut, yang dirancang untuk memenuhi kebutuhan informasi suatu organisasi. (Connolly dan Begg, 2010, p65)
12 Perancangan database adalah proses menciptakan desain untuk sebuah database yang akan mendukung operasi dan tujuan dari suatu perusahaan. Dua pendekatan utama untuk perancangan database, yaitu bottom – up dan top – down. (Connolly dan Begg, 2010, p320) • Pendekatan Bottom – Up Pendekatan bottom – up dimulai dari tingkat dasar atribut, yang melalui hubungan analisis antar atribut, yang dikelompokkan ke dalam hubungan yang mewakili tipe entitas dan hubungan antar entitas. Pendekatan bottom – up tepat untuk rancangan database sederhana dengan jumlah atribut yang relatif kecil. Namun, pendekatan ini menjadi sulit ketika diterapkan pada perancangan database yang lebih kompleks. • Pendekatan Top - Down Strategi yang tepat untuk perancangan database yang lebih kompleks adalah dengan menggunakan pendekatan top – down. Pendekatan top – down diilustrasikan menggunakan konsep Entity Relationship Model dimulai dengan mengidentifikasi entitas dan hubungan antar entitas.
Perancangan database terdiri dari tiga tahap utama, yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. (Connolly and Beg, 2010, p322) 2.3.1
Entity – Relationship (ER) Modelling Entity - Relationship (ER) Modelling merupakan pendekatan top – down
untuk
model
perancangan
database
yang
dimulai
dengan
13 mengidentifikasi data penting yang disebut entitas dan hubungan diantara data yang harus direpresentasikan di dalam model. Kemudian menambahkan lebih banyak detail, seperti informasi yang terus diinginkan mengenai entitas dan hubungan yang disebut atribut dan setiap constraint pada entitas, hubungan, dan atribut. (Connolly dan Begg, 2010, p371) A. Tipe Entitas Tipe entitas adalah kumpulan objek dengan sifat yang sama, dimana mereka diidentifikasi oleh perusahaan yang mempunyai keberadaan yang mandiri. Tipe entitas merepresentasikan kumpulan objek di dalam dunia nyata dengan sifat yang sama, objek dengan physical existence (nyata) dan objek dengan conceptual existence (abstrak). (Connolly dan Begg, 2010, p372) Tabel 2.1 Contoh physical existence dan conceptual existence Physical Existence Pasien Karyawan Dokter Obat Conceptual Existence Rawat Jalan Penjualan Rawat Inap Rekam Medik B. Tipe Hubungan Tipe hubungan adalah suatu set asosiasi yang bermakna diantara tipe entitas. (Connolly dan Begg, 2010, p374) •
Derajat Tipe Hubungan (Degree of Relationship Type) Tingkat hubungan menunjukkan jumlah jenis entitas yang terlibat dalam suatu hubungan. Oleh karena itu, derajat tipe
14 hubungan menentukan jumlah dari tipe entitas yang terlibat dalam relationship. Hubungan dari derajat dua (degree two) disebut binary. Binary
relationship
menunjukkan
dua
tipe
entitas
yang
berpartisipasi. Hubungan dari derajat tiga (degree three) disebut ternary. Ternary relationship menunjukkan tiga tipe entitas yang berpartisipasi. Hubungan dari derajat empat (degree four) disebut quaternary. Quaternary relationship menunjukkan empat tipe entitas yang berpartisipasi. •
Hubungan Rekursif (Recursive Relationship) Tipe hubungan yang merupakan tipe entitas yang sama yang berpartisipasi dalam lebih dari satu kali peran yang berbeda.
C. Atribut Atribut adalah property dari sebuah entitas atau tipe hubungan. Domain adalah setiap atribut yang terkait dengan sekumpulan nilai. Atribut dapat diklasifikasikan sebagai berikut : •
Simple dan Composite Attributes Simple atribut adalah atribut yang tersusun dari komponen tunggal. Misalnya : nama pasien rumah sakit. Composite atribut adalah atribut yang tersusun dari banyak komponen. Misalnya : alamat pasien rumah sakit.
15 •
Single – Valued Attributes dan Multi – Valued Attributes Single – valued atribut adalah atribut yang memiliki nilai tunggal untuk setiap kejadian sebuah tipe entitas. Misalnya : nomor rekam medik pasien rumah sakit. Multi – valued atribut adalah atribut yang memiliki banyak nilai untuk setiap kejadian sebuah tipe entitas. Misalnya : nomor telepon pasien rumah sakit
•
Derived Attributes Derived atribut adalah atribut yang merepresentasikan nilai yang diturunkan dari nilai atribut yang terkait atau satu set atribut, tidak perlu dalam tipe entitas yang sama. Misalnya: subtotal pembayaran layanan rumah sakit.
D. Keys •
Candidate key adalah set atribut minimal yang diidentifikasi secara unik dari masing – masing kejadian tipe entitas.
•
Primary key adalah candidate key yang terpilih.
•
Alternate key adalah candidate key yang terdiri dari dua atau lebih atribut yang tidak terpilih. (Connolly dan Begg, 2010, p381)
E. Tipe Entitas Strong dan Weak •
Strong entity type Jenis entitas yang tidak tergantung pada keberadaan beberapa jenis entitas lainnya. Jenis entitas disebut sebagai strong entity type jika keberadaannya tidak bergantung pada keberadaan entitas jenis
16 lain. Strong entity type terkadang disebut sebagai parent, owner, atau dominant entities (Connolly dan Begg, 2010, p383) •
Weak entity type Jenis entitas yang keberadaannya tergantung pada beberapa tipe entitas lainnya. Weak entity type bergantung pada keberadaan entitas jenis lain. Karakteristik dari weak entity type adalah bahwa setiap kemunculan entitas tidak dapat diidentifikasi secara unik hanya dengan menggunakan atribut yang terkait dengan jenis entitas. Weak entity type terkadang disebut sebagai child, dependent, or subordinate entities. (Connolly dan Begg, 2010, p384)
F. Structural Constraint Tipe hubungan biasanya mempunyai constraint tertentu yang membatasi kemungkinan kombinasi dari entitas yang mungkin berpartisipasi dalam sekumpulan hubungan yang terkait. (Elmasri and Navathe, 2000, p56) Tipe
utama
dari
constraint
dalam
relationship
disebut
multiplicity. Multiplicity adalah jumlah kemungkinan terjadinya suatu tipe entitas yang mungkin berhubungan dengan kejadian tunggal dari sebuah tipe entitas terkait melalui hubungan tertentu. (Connolly dan Begg, 2010, p385) •
One – to – one (1:1) Relationship Pada atribut dari one – to – one (1:1) relationship dapat pindah ke salah satu tipe entitas yang berpartisipasi.
17 •
One – to – many (1:*) Relationship Pada tipe hubungan 1:*, hubungan atribut hanya dapat pindah ke tipe entitas pada bagian – * dari sebuah hubungan.
•
Many – to – many (*:*) Relationship Untuk tipe hubungan *:*, beberapa atribut dapat ditentukan oleh kombinasi dari entitas yang berpartisipasi dalam hubungan instance, bukan oleh satu entitas saja. Atribut tersebut harus ditentukan sebagai hubungan atribut.
G. Masalah pada Model ER Ada masalah yang mungkin muncul ketika membuat model ER, masalah ini disebut sebagai connection traps, dan biasanya muncul karena salah menafsirkan arti dari hubungan tertentu. Connection traps dibagi menjadi dua tipe utama, yaitu fan traps dan chasm traps. •
Fan traps Model yang merepresentasikan sebuah hubungan antara tipe entitas tetapi langkah yang memastikan suatu kejadian tertentu tidak jelas.
•
Chasm traps Model yang merepresentasikan sebuah hubungan antara tipe entitas tetapi tidak ada jalan yang menunjukkan keberadaan kejadian pada entitas tersebut.
18
Gambar 2.2 Entity Relationship (ER) diagram (Sumber : Connoly dan Begg, 2010, p373) 2.3.2
Normalisasi Normalisasi data dapat dilihat sebagai sebuah proses menganalisis skema relasi yang diberikan berdasarkan ketergantungan fungsi (functional dependencies) dan primary key untuk meminimalkan perulangan dari property / atribut dan meminimalkan update anomalies. (Elmasri and
19 Navathe, 2004, p313) Update anomalies diklasifikasikan menjadi insertion, deletion, dan modification anomalies. Tabel 2.2 StaffBranch Relation (Sumber : Connoly dan Begg, 2010, p419) staffNo SL21 SG37 SG14 SA9 SG5 SL41
staffName John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee
position Manager Assistant Supervisor Assistant Manager Assistant
salary 30000 12000 18000 9000 24000 9000
branchNo B005 B003 B003 B007 B003 B005
bAddress 22 Derr Rd, London 163 Main St, Glasgow 163 Main St, Glasgow 16 Argyll St, Aberdeen 163 Main St, Glasgow 22 Derr Rd, London
A. Insertion Anomalies Terdapat
dua
tipe
utama
insertion
anomalies,
dapat
diilustrasikan dengan menggunakan StaffBranch Relation pada tabel 2.2. (Connoly dan Begg, 2010, p419) •
Untuk memasukkan rincian anggota baru dari staf ke dalam relasi StaffBranch, harus memasukan juga detail dari cabang dimana staf akan berada
•
Untuk memasukkan rincian cabang baru yang pada saat itu belum mempunyai anggota dari staf di dalam relasi StaffBranch, perlu untuk memasukkan null ke atribut staf, seperti staffNo. Namun staffNo adalah primary key dari relasi StaffBranch,memasukkan null untuk melanggar entity integrity dan tidak diperbolehkan.
20 B. Delete Anomalies Jika menghapus sebuah baris dari relasi StaffBranch yang merepresentasikan anggota lama dari staf yang berlokasi pada sebuah cabang, rincian mengenai cabang tersebut juga akan hilang dari database. (Connoly dan Begg, 2010, p419) C. Modification Anomalies Jika ingin mengubah nilai dari salah satu atribut pada cabang tertentu di dalam relasi StaffBranch. Sebagai contoh, alamat dari cabang yang bernomor B003, update harus dilakukan pada semua baris yang berlokasi pada cabang tersebut. (Connoly dan Begg, 2010, p420) D. Functional Dependencies Ketergantungan fungsi (Functional Dependencies) adalah pembatas antara dua set atribut dari database. (Elmasri and Navathe, 2004, p304) Functional dependencies dibagi menjadi 3, yaitu full functional dependency, partial dependency, transitive dependency. •
Full functional dependency Full functional dependency menunjukkan jika A dan B adalah atribut dari sebuah relasi, B merupakan full functionally dependent pada A, tetapi tidak pada setiap bagian dari A. (Connoly dan Begg, 2010, p423) Full functional dependency dapat ditunjukkan sebagai berikut : staffNo
branchNo
21 •
Partial dependency Partial dependency jika terdapat beberapa atribut yang bisa dihilangkan dari A dan meskipun dependency masih dimiliki. (Connoly dan Begg, 2010, p423) staffNo, sName
branchNo
Contoh diatas bukan merupakan full functional dependency, karena branchNo juga functionally dependency pada subset dari (staffNo, sName) yaitu staffNo. •
Transitive dependency Transitive dependency merupakan sebuah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi seperti A
B dan B
C, maka
C adalah transitive dependent pada A melalui B. (Connoly dan Begg, 2010, p424) staffNo branchNo
sName, Position, salary, branchNo, bAddress bAddress
Transitive dependency branchNo
bAddress terjadi pada staffNo
melalui branchNo. E. Unnormalized Form (UNF) Tabel yang berisi satu atau lebih grup yang berulang. Pada tahap ini mentransfer data dari sumber menjadi format tabel dengan baris dan kolom. (Connolly dan Begg, 2010, p430)
22 Tabel 2.3 ClientRental Unnormalized Table (Sumber : Connoly dan Begg, 2010, p432) client No CR76
cName John Kay
property No PG4 PG16
CR56
Aline Stewart
PG4 PG36 PG16
pAddress
rentStart
rentFinish
6 Lawrence St, Glasglow 5 Novar Dr, Glasglow 6 Lawrence St, Glasglow 2 Manor Rd, Glasglow 5 Novar Dr, Glasglow
1-Jul-07
31-Aug-08 350
owner No CO40
1-Sep-08
1-Sep-09
450
CO93
1-Sep-06
10-June07 1-Dec-08
350
CO40
375
CO93
10-Aug-10 450
CO93
10-Oct07 1-Nov09
rent
oName Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw
Berdasarkan gambar diatas struktur dari repeating group adalah sebagai berikut : Repeating Group = (propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName) F. First Normal Form (1NF) 1NF didefinisikan untuk melarang atribut bernilai ganda, komposit atribut, dan kombinasi keduanya. 1NF menyatakan bahwa domain dari atribut harus dan hanya mencakup nilai atomic (tidak terpisahkan) dan nilai – nilai atribut dalam tuple harus nilai tunggal dari domain atribut tersebut. Dengan kata lain, 1NF melarang “hubungan dalam hubungan”. Nilai – nilai atribut yang hanya diijinkan oleh 1NF adalah nilai atomic tunggal. (Elmasri and Navathe, 2004, p315) Tabel 2.4 1NF Client (Sumber : Connoly dan Begg, 2010, p433) clienNo CR76 CR56
cName John Kay Aline Stewart
23 Tabel 2.5 1NF PropertyRentalOwner (Sumber : Connoly dan Begg, 2010, p433) client No CR76
property No PG4
CR76
PG16
CR56
PG4
CR56
PG36
CR56
PG16
pAddress
rentStart
rentFinish
6 Lawrence St, Glasglow 5 Novar Dr, Glasglow 6 Lawrence St, Glasglow 2 Manor Rd, Glasglow 5 Novar Dr, Glasglow
1-Jul-07
31-Aug-08 350
owner No CO40
1-Sep-08
1-Sep-09
450
CO93
1-Sep-06
10-June07 1-Dec-08
350
CO40
375
CO93
10-Aug-10 450
CO93
10-Oct07 1-Nov09
rent
oName Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw
Hasil dari relasi 1NF adalah sebagai berikut : Client (clientNo, cName) PropertyRentalOwner (clientNo, propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName) H. Second Normal Form (2NF) 2NF didasarkan pada konsep full functional dependency. Ketergantungan fungsional X
Y akan full functional dependency jika
menghapus atribut A dari X menyebabkan ketergantungan tersebut menjadi tidak ada. Berarti untuk setiap atribut A bagian dari X secara fungsional tidak menentukan Y. Sebuah ketergantungan fungsional akan partial dependency jika beberapa atribut A bagian dari X dapat dihilangkan dan ketergantungan tetap terjaga. (Elmasri and Navathe, 2004, p318) Untuk hubungan dimana primary key mengandung beberapa atribut, tidak ada atribut nonkey yang boleh bergantung secara fungsional pada bagian primary key.
24 Tabel 2.6 2NF Client (Sumber : Connoly dan Begg, 2010, p435) clienNo CR76 CR56
cName John Kay Aline Stewart
Tabel 2.7 2NF Rental (Sumber : Connoly dan Begg, 2010, p435) clientNo CR76 CR76 CR56 CR56 CR56
propertyNo PG4 PG16 PG4 PG36 PG16
rentStart 1-Jul-07 1-Sep-08 1-Sep-06 10-Oct-07 1-Nov-09
rentFinish 31-Aug-08 1-Sep-09 10-June-07 1-Dec-08 10-Aug-10
Tabel 2.8 2NF PropertyOwner (Sumber : Connoly dan Begg, 2010, p435) propertyNo PG4 PG16 PG36
pAddress 6 Lawrence Glasglow 5 Novar Glasglow 2 Manor Glasglow
rent St, 350
ownerNo CO40
Dr, 450
CO93
oName Tina Murphy Tony Shaw
Rd, 375
CO93
Tony Shaw
Relasi yang didapat adalah sebagai berikut : Client (clientNo, cName) Rental (clientNo, propertyNo, rentStart, rentFinish) PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName) I. Third Normal Form (3NF) 3NF
didasarkan
Ketergantungan fungsional X
pada
konsep
transitive
dependency.
Y dalam skema relasi R akan transitive
dependency jika ada satu set atribut Z yang bukan candidate key ataupun subset dari key pada R, dan kedua X
Z dan Z
Y tetap bertahan.
25 (Elmasri and Navathe, 2004, p319) Relasi tidak boleh memiliki atribut nonkey yang bergantung secara fungsional pada atribut nonkey lainnya. Tidak boleh ada transitive dependency dari atribut nonkey pada primary key. Tabel 2.9 3NF PropertyForRent (Sumber : Connoly dan Begg, 2010, p436) propertyNo PG4 PG16 PG36
pAddress 6 Lawrence Glasglow 5 Novar Glasglow 2 Manor Glasglow
rent St, 350
ownerNo CO40
Dr, 450
CO93
Rd, 375
CO93
Tabel 2.10 3NF Owner (Sumber : Connoly dan Begg, 2010, p436) ownerNo CO40 CO93 CO93
oName Tina Murphy Tony Shaw Tony Shaw
Hasil dari relasi 3NF adalah sebagai berikut : Client (clientNo, cName) Rental (clientNo, propertyNo, rentStart, rentFinish) PropertyForRent (propertyNo, pAddress, rent, ownerNo, oName) Owner (ownerNo, oName) 2.3.3
Perancangan Basis Data Konseptual Proses membangun data model yang digunakan dalam suatu perusahaan. (Connolly dan Begg, 2010, p322)
26 Tujuan dari perancangan basis data konseptual adalah untuk membangun model data konseptual dari data yang dibutuhkan oleh perusahaan. Perancangan basis data konseptual terdiri dari langkah – langkah berikut ini : Langkah 1 : Membangun model data konseptual 1.1 Mengidentifikasi tipe entitas Tipe entitas dapat diketahui dengan mengidentifikasi kata benda, mencari objek utama seperti orang (people), tempat (place), atau konsep yang menarik (concept of interest). Tahapan ini bertujuan untuk mengidentifikasi tipe entitas yang dibutuhkan sesuai dengan spesifikasi kebutuhan pengguna. 1.2 Mengidentifikasi tipe hubungan Bertujuan untuk mengidentifikasi hubungan (relationship) penting yang ada diantara tipe entitas. Tipe hubungan dapat diindikasikan dengan kata kerja atau ekspresi verbal (verbal expression). 1.3 Mengidentifikasi dan menghubungkan atribut dengan entitas atau tipe hubungan Bertujuan untuk menghubungkan atribut dengan entitas dan tipe hubungan yang sesuai. Atribut dapat diklasifikasikan sebagai simple / composite, single – valued / multi – valued, atau derived. 1.4 Menentukan domain atribut Bertujuan menentukan domain untuk atribut dalam model data konseptual. Domain atribut adalah himpunan nilai yang diijinkan untuk satu atau lebih atribut.
27 1.5 Menentukan atribut candidate, primary dan alternate key Bertujuan untuk mengidentifikasi candidate key(s) untuk setiap tipe entitas dan, jika ada lebih dari satu candidate key, pilih satu untuk menjadi primary key dan yang lainnya sebagai alternate keys. 1.6 Mempertimbangkan penggunaan enhanced modelling concepts (optional step) Bertujuan untuk mempertimbangkan penggunaan dari enhanced modelling concepts, seperti specialization/generalization, aggregation, dan composition. 1.7 Memeriksa model terhadap redundancy Bertujuan untuk mengecek adanya redundancy pada sebuah model. 1.8 Memvalidasikan
model
data
konseptual
terhadap
transaksi
pengguna Bertujuan untuk memastikan model data konseptual mendukung transaksi yang dibutuhkan. Dua kemungkinan pendekatan untuk memastikan model data konseptual mendukung transaksi yang dibutuhkan : a. Mendeskripsikan transaksi b. Menggunakan jalur transaksi 1.9 Meninjau model data konseptual dengan pengguna Bertujuan mengecek ulang model data konseptual dengan pengguna untuk memastikan apa yang mereka pikirkan menjadi representasi nyata dari data yang dibutuhkan oleh pengguna.
28 Supervises
0..10 Supervisee
0..1
Registers
Staff
1..1
staffNo
0..1 BusinessOwner ownerNo
Managees
0..1 BOwns
0..100 1..*
0..*
Views PropertyForRent
0..*
Client
0..*
propertyNo
clientNo
1..* 1..1
1..1 viewDate comment
AssociatedWith
POwns
1..1 Holds
States
0..1 0..*
PrivateOwner ownerNo
0..*
Lease
1..1
Preference
leaseNo
Gambar 2.3 Perancangan basis data konseptual (Sumber : Connoly dan Begg, 2010, p480) 2.3.4
Perancangan Basis Data Logikal Proses membangun data model yang digunakan dalam suatu perusahaan berdasarkan pada model data yang spesifik tetapi tidak bergantung pada suatu DBMS tertentu dan pertimbangan fisik lainnya. (Connolly dan Begg, 2010, p322) Tujuan
dari
perancangan
basis
data
logikal
adalah
untuk
menerjemahkan model data konseptual ke dalam model data logikal kemudian memvalidasi model tersebut untuk mengecek struktur yang benar
29 dan mampu mendukung transaksi yang dibutuhkan. Perancangan basis data konseptual terdiri dari langkah – langkah berikut ini : Langkah 2 : Membangun model data logikal 2.1Menurunkan hubungan untuk model data logikal Bertujuan
membuat
merepresentasikan
entitas,
hubungan
model
hubungan,
dan
data atribut
logikal
untuk
yang
telah
diidentifikasi. Menjelaskan bagaimana hubungan dapat diturunkan dari struktur model yang ada sekarang, antara lain : a. Tipe strong entity b. Tipe weak entity c. One – to – many (1:*) binary relationship types d. One – to – one (1:1) binary relationship types e. One – to – one (1:1) recursive relationship types f. Superclass / subclass relationship types g. Many – to – many (*:*) binary relationship types h. Complex relationship types i. Multi – valued attributes 2.2Memvalidasi hubungan dengan menggunakan normalisasi Bertujuan untuk memvalidasi hubungan di dalam model data logikal dengan menggunakan normalisasi. 2.3Memvalidasi hubungan terhadap transaksi pengguna Bertujuan untuk memastikan hubungan di dalam model data logikal mendukung transaksi yang dibutuhkan.
30 2.4Memeriksa integrity constraints Bertujuan
untuk
memeriksa
apakah
integrity
constraints
direpresentasikan di dalam model data logikal. Berikut ini jenis integrity constraints : a. Data yang dibutuhkan b. Attribute domain constraints c. Multiplicity d. Entity integrity e. Referential integrity f. General constraint 2.5Meninjau model data logikal dengan pengguna Bertujuan untuk memeriksa kembali model data logikal dengan pengguna untuk memastikan model yang mereka pertimbangkan menjadi representasi nyata dari data yang dibutuhkan oleh pengguna. 2.6Menggabungkan model data logikal ke dalam model data global (optional step) Bertujuan untuk menggabungkan model data logikal lokal ke dalam satu model data logikal global yang merepresentasikan semua pandangan pengguna database. 2.7Memeriksa pertumbuhan yang akan datang Bertujuan untuk menentukan apakah ada kemungkinan perubahan yang signifikan di masa mendatang dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan.
31
Gambar 2.4 Perancangan basis data logikal (Sumber : Connoly dan Begg, 2010, p516)
32 2.3.5
Perancangan Basis Data Fisikal Proses menghasilkan deskripsi dari implementasi database pada penyimpanan sekunder, menggambarkan hubungan dasar, file organisasi, dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data, dan setiap kendala integritas terkait dan tindakan keamanan. (Connolly dan Begg, 2010, p322) Langkah dari metodologi perancangan basis data fisikal adalah sebagai berikut : Langkah 3 : Menerjemahkan model data logikal untuk sasaran DBMS Ada tiga aktifitas dari langkah 3 ini, seperti : •
Merancang base relation
•
Merancang representasi dari data turunan (derived data)
•
Merancang general constraint
3.1Merancang base relation Bertujuan
untuk
memutuskan
bagaimana
merepresentasikan
hubungan dasar yang diidentifikasi pada model data logikal dalam sasaran DBMS.
33 Domain PropertyNumber: variable length character string, length 3 Domain Street:
variable length character string, length 25
Domain City:
variable length character string, length 15
Domain Postcode :
variable length character string, length 8
Domain PropertyType:
single character, must be one of ‘B’, ‘C’, ‘D’, ‘E’, ‘F’, ‘H’, ‘M’, ‘S’
Domain PropertyRooms:
integer, in range 1 – 15
Domain PropertyRent:
monetary value, in the range 0.00 – 9999.99
Domain OwnerNumber:
variable length character string, length 5
Domain StaffNumber:
variable length character string, length 5
Domain BranchNumber:
variable length character string, length 4
PropertyForRent( propertyNo
PropertyNumber
NOT NULL,
street
Street
NOT NULL,
city
City
NOT NULL,
postcode
Postcode,
type
PropertyType
NOT NULL DEFAULT ‘F’,
rooms
PropertyRooms
NOT NULL DEFAULT 4,
rent
PropertyRent
NOT NULL DEFAULT 600,
ownerNo
OwnerNumber
NOT NULL,
staffNo
StaffNumber,
branchNo
BranchNumber
NOT NULL,
PRIMARY KEY (propertyNo), FOREIGN KEY (staffNo) REFERENCES Staff (staffNo) ON UPDATE CASCADE ON DELETE SET NULL, FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerfNo) and BusinessOwner(ownerNo) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (branchNo) REFERENCES Branch (branchNo) ON UPDATE CASCADE ON DELETE NO ACTION); Gambar 2.5 Contoh perancangan basis data fisikal base relation (Sumber : Connoly dan Begg, 2010, p526)
34 3.2Merancang representasi dari data turunan (derived data) Bertujuan untuk memutuskan bagaimana merepresentasikan setiap derived data yang diperoleh mewakili model data logikal dalam DBMS yang akan digunakan. 3.3Merancang general constraint Merancang constraint tergantung pada pilihan DBMS, beberapa sistem menyediakan fasilitas lebih daripada yang lain dalam mendefinisikan general constraint.
Langkah 4 : Merancang file organizations dan indexes Aktifitas yang ada pada langkah 4 adalah sebagai berikut : •
Analisis transaksi
•
Memilih file organizations
•
Memilih indexes
•
Memperhitungkan kebutuhan disk space
4.1Analisis transaksi Bertujuan untuk memahami fungsi dari transaksi yang akan dijalankan di database dan untuk menganalisis transaksi penting. 4.2Memilih file organizations Bertujuan untuk menentukan file organization yang efisien untuk setiap base relation.
35 4.3Memilih indexes Bertujuan untuk menentukan apakah penambahan indeks akan meningkatkan performa sistem. 4.4Memperhitungkan kebutuhan disk space Bertujuan untuk menentukan jumlah dari disk space yang dibutuhkan untuk mendukung implementasi database dalam secondary storage.
Langkah 5 : Merancang user views Bertujuan untuk merancang user views yang telah diidentifikasi selama pengumpulan kebutuhan dan dalam tahap analisis dari database system development lifecycle.
Langkah 6 : Merancang security mechanisms Bertujuan merancang mekanisme keamanan untuk database yang dispesifikasikan oleh pengguna selama tahap requirement and collection dari database system development lifecycle. 2.4 Perancangan Web Database Web adalah sebuah aplikasi internet. Web menyediakan sebuah cara yang mudah untuk mengakses informasi dan menjalankan program – program yang disimpan pada komputer yang dihubungkan oleh internet. (Eaglestone dan Ridley, 2001, p24)
36 Web database system adalah sistem dimana teknologi web dan database digunakan secara bersamaan. Web Database system menyediakan akses yang lebih luas ke dalam sistem database dan meningkatkan kegunaan web. (Eaglestone dan Ridley , 2001, p38) Metode web database design merupakan sebuah rangkaian pada model – model yang menggambarkan penyimpanan data dalam halaman – halaman web, dengan tambahan untuk data pada database. (Eaglestone dan Ridley, 2001, p263) Sebagai basis data, struktur pada sebuah basis data web dapat mewakili level – level berbeda pada abstraksi, bersamaan dengan model konseptual, logikal, dan fisikal pada sistem basis data konvensional: a. Conceptual Web Data Model Conceptual web data model harus memperlihatkan struktur dari informasi yang digambarkan oleh halaman – halaman web. b. Logical Web Data Model Logical web data model harus memperlihatkan bagaimana struktur – struktur konseptual digambarkan dalam halaman web. c. Physical Web Data Model Physical web data model harus memperlihatkan bagaimana model logikal pada halaman – halaman web diimplementasikan.
37 Menurut
Eaglestone
dan
Ridley
(2001,p264),
web
database
design
digambarkan sebagai berikut :
Gambar 2.6 Diagram web database lifecycle (Sumber : Eaglestone dan Ridley, 2001, p290) 2.4.1
Web Data Analysis Menurut Eaglestone dan Ridley (2001, p284), web data analysis mendapatkan sebuah conceptual data model untuk digambarkan dengan halaman web. Input untuk proses ini adalah decription of the organization and system requirements dan conceptual data model. Tujuan dari web data analysis adalah sebagai berikut : 1. Membuat peta antara informasi yang memperkenalkan halaman – halaman web dan yang disimpan dalam basis data
38 2. Pengecekan validasi pada basis data 3. Model konseptual pada halaman – halaman web memberikan sebuah basis untuk membuktikan detail design dan implementasi pada halaman – halaman web adalah benar 4. Menjelang
masalah
perancangan,
hindari technical complexities,
seperti perancangan dan implementasi
Gambar 2.7 Web data analysis (Sumber : Eaglestone dan Ridley, 2001, p290)
A. Web Data Extraction Menurut Eaglestone dan Ridley (2001, p289), Tujuan yang pertama dari dua tahapan web data analysis adalah untuk menetapkan
39 bagian model konseptual pada database yang berhubungan dengan aplikasi web database. Aturan kelengkapan yang harus diaplikasikan adalah : •
Kelengkapan atribut entitas
•
Kelengkapan identifikasi entitas
•
Kelengkapan referential
B. Web Database ER Model Menurut Eaglestone dan Ridley (2001, p285), sebuah web database mendukung aplikasi – aplikasi database melalui interaksi lewat halaman web. Ketika merancang isi data dari halaman web sangat penting untuk menunjukan sebuah halaman web berbeda dengan sebuah tabel relasi. Maka dari itu, fitur – fitur baru harus diikutsertakan dalam sebuah model konseptual pada halaman-halaman web. Khususnya, ada dua aspek pada halaman – halaman web yang memerlukan perluasan untuk model ER : •
Hypermedia links Hypermedia
dibuat
oleh
halaman
web
dengan
tegas
menyediakan arah jalan navigasi antara entitas yang berhubungan. •
Web application - specific concepts Halaman – halaman itu sendiri mewakili konsep – konsep yang sangat penting untuk user. Dalam kasus lain, konsep – konsep yang tidak cocok untuk abstraction dalam model konseptual database
40 masih harus diwakili dalam model konseptual untuk halaman web. Digambarkan dengan bentuk oval, yang disebut kotak konsep (concept boxes). C. Web Database Connectivity Analysis Menurut Eaglestone dan Ridley (2001, p293), tugas web database connectivity analysis adalah untuk menganalisis penjelasan aplikasi basis data web agar mengenali akses point sampai sistem, dan arah jalur navigasi antara dan dengan halaman web.
Gambar 2.8 Conceptual (ER) model hypermedia (Sumber : Eaglestone dan Ridley, 2001, p287)
41 2.4.2
Perancangan Web Data Logikal Menurut Eaglestone dan Ridley (2001, p310), membahas proses dimana struktur – struktur data dari halaman web ditentukan. Proses mengambil input web conceptual model dan menetapkan sebuah skema untuk tiap halaman web. A. Logical Web Page Schema Menurut Eaglestone dan Ridley (2001, p310), halaman web menyediakan akses ke sumber web dengan menampilkan informasi, serta mengijinkan user berinteraksi dengan halaman. Halaman web dapat rumit, baik yang ditampilkan maupun proses yang berkaitan. Karakteristik pada halaman – halaman web memerlukan beberapa ciri tambahan yang dimasukan ke bahasa skema logikal konvensional. Khususnya kita harus dapat menetapkan : •
Struktur – struktur pada halaman unik
•
Struktur – struktur umum ke banyak halaman
•
Links
•
Struktur – struktur data kompleks
42
Gambar 2.9 Logical Web Page Schema Untuk Rawat Jalan (Sumber : Eaglestone dan Ridley, 2001, p317)
43 2.4.3
Perancangan Web Data Fisikal Perancangan web data fisikal adalah desain bagaimana halaman web yang akan diimplementasikan terhubung ke database. Menurut Eaglestone dan Ridley (2001, p328), perancangan basis data fisikal adalah fase dalam proses perancangan dimana perancang memutuskan bagaimana basis data disimpan. Sebuah DBMS biasanya akan mendukung sejumlah alternatif representasi fisikal pada struktur data logikal dan perancang harus memilih yang paling tepat. Untuk itu perancang mengerti keuntungan dan hukuman yang terhubung dengan tiap alternatif. Tujuan perancang adalah untuk memilih representasi fisikal untuk tiap struktur logikal seperti database yang memiliki properti sebagai berikut : a. Data boleh diakses dengan kecepatan yang pantas b. Database tidak dapat digunakan terlalu sering pada komputer penyimpanan c. “The database is reasonably resilient to catastrophes”. Selalu ada kemungkinan untuk memperbaiki kerusakan sistem database, dan jika bagian pada sistem gagal masih mungkin untuk remainder (sisa) di “limp”. Keputusan perancangan
fisikal
harus
berdasarkan
pada
pengetahuan sebagai berikut : a. Perancangan basis data fisikal Perancang harus mengetahui struktur mana yang termasuk dalam basis data. Faktanya ini dapat ditentukan bahwa perancangan logikal harus diganti sebagai favour certain applications.
44 b. Quantities dan volatility pada data Perancang harus mengetahui jumlah data yang mungkin terjadi pada tiap tabel atau kelas, frekuensi dimana semuanya akan dirubah, dan biaya dimana tiap tabel atau kelas akan berkembang. Pengetahuan ini juga perlu untuk memilih struktur – struktur file yang paling tepat dan akses metode – metode. c. Cara penggunaan data Idealnya, perancang harus mengetahui setiap aplikasi basis data : -
Frekuensi aplikasi akan digunakan
-
Kedudukannya dibandingkan dengan aplikasi yang lain untuk mengetahui kepentingan yang relatif
-
Waktu terlama yang dapat diterima untuk menjalankan aplikasi
d. Transaction properties Juga untuk setiap transaksi dimana dapat terjadi selama aplikasi, perancang harus mengetahui : -
Sejumlah waktu transaksi dihasilkan ketika aplikasi dijalankan
-
Tabel - tabel dan kolom – kolom, atau kelas – kelas, diakses oleh transaksi, dan tipe akses, contohnya retrieval, update, delete atau insert
-
W aktu terlama yang dapat diterima untuk menjalankan transaksi
e. Biaya yang dikelompokan sesuai penyimpanan dan pengaksesan data, diberikan tiap representasi yang ada pada relasi – relasi atau kelas – kelas.
45 Aplikasi web dapat dibangun dalam client server architecture. Client/server
system adalah
solusi
komputasi
terdistribusi
dimana
representasi, logika presentasi, logika aplikasi, manipulasi data, dan lapisan data yang didistribusikan antara PC klien dengan satu atau lebih server. (Whitten dan Bentley, 2007, p487) Menurut Whitten dan Bentley (2007, p489), sistem distributed data client/server merupakan solusi dimana data dan lapisan manipulasi data ditempatkan pada server, dan logika aplikasi, logika presentasi, dan presentasi ditempatkan pada klien. Ini disebut juga komputasi two-tiered client/server. Penting untuk memahami perbedaan antara sistem file server dan sistem distributed data client/server. Keduanya menyimpan database nya pada server. Tapi hanya sistem client/server yang menjalankan semua perintah manipulasi data pada server. Dalam sistem file server, perintah manipulasi data harus diimplementasikan pada klien. Distributed data client/server menawarkan beberapa keunggulan dibandingkan file server : a. Terdapat lebih sedikit trafik jaringan karena hanya permintaan database dan catatan database yang dibutuhkan dipindahkan ke dan dari workstation klien. b. Integritas database lebih mudah dalam perawatan. Hanya catatan yang digunakan oleh klien yang biasanya harus dikunci. Klien lain secara bersamaan dapat bekerja pada catatan lain dalam tabel atau database yang sama.
46 Potensial kerugian untuk two-tiered client/server adalah bahwa logika aplikasi harus digandakan dan dirawat pada semua klien, mungkin ratusan atau ribuan. Perancang harus merencanakan upgrade versi dan menyediakan kontrol untuk memastikan bahwa setiap klien menjalankan versi terbaru dari logika bisnis, serta menghasilkan bahwa perangkat lunak lain di PC tidak mengganggu logika bisnis.
Gambar 2.10 Two Tier Client Server Architecture Sebuah distributed data dan application client/server system merupakan solusi di mana (1) data dan lapisan manipulasi data ditempatkan di server mereka sendiri, (2) logika aplikasi ditempatkan di server sendiri, dan (3) hanya presentasi logika dan presentasi ditempatkan pada klien. Ini juga disebut three-tiered or n-tiered client/server computing. Solusi three-tiered atau n-tiered client/server menggunakan server database yang sama seperti pada pendekatan two-tiered. Selain itu, sistem
47 three-tiered memperkenalkan aplikasi server atau transaksi server. Dengan memindahkan logika aplikasi ke servernya sendiri sehingga logika tersebut hanya perlu dirawat di server. Dalam sistem three-tiered, klien mengeksekusi sedikit dari komponen sistem secara keseluruhan. Hanya user interface dan beberapa aplikasi yang relatif stabil atau aplikasi logika personal yang perlu dijalankan pada klien. Ini menyederhanakan konfigurasi klien dan manajemen. Kelemahan terbesar dari three-tiered client/server adalah kompleksitas dalam desain dan pengembangan. Aspek tersulit dari desain aplikasi three-tiered client/server adalah partisi.
Gambar 2.11 Three Tier Client Server Architecture
