BAB 2 LANDASAN TEORI. menghasilkan gejala masalah lain. Cause effect analysis menyebabkan pemahaman

Transkripsi

1 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

2 9 Gambar 2.1 Database System Development Lifecycle (Sumber : Connoly dan Begg, 2010, p314) Database Planning Database planning merupakan kegiatan pengaturan yang memungkinkan tahapan tahapan database system development lifecycle direalisasikan seefektif dan seefisien mungkin System Definition System definition menggambarkan ruang lingkup dan batasan dari database system dan user view utama.

3 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) 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 Database Design Database design merupakan proses membuat rancangan yang akan mendukung pernyataan misi dan tujuan misi suatu perusahaan untuk database system yang diperlukan DBMS Selection (Optional) system. Memilih sebuah DBMS yang cocok untuk mendukung database Application Design Application design merancang user interface dan aplikasi program yang digunakan dan memproses database Prototyping (Optional) Prototyping adalah membangun sebuah model kerja dari database system. Tujuan utama dari mengembangkan prototype database system

4 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 Implementation Implementation adalah realisasi fisikal dari database dan rancangan aplikasi. stock control) 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) Testing Testing merupakan proses menjalankan database system dengan tujuan untuk menemukan error 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)

5 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) Entity Relationship (ER) Modelling Entity - Relationship (ER) Modelling merupakan pendekatan top down untuk model perancangan database yang dimulai dengan

6 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

7 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.

8 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

9 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.

10 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.

11 18 Gambar 2.2 Entity Relationship (ER) diagram (Sumber : Connoly dan Begg, 2010, p373) 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

12 Navathe, 2004, p313) Update anomalies diklasifikasikan menjadi insertion, deletion, dan modification anomalies. 19 Tabel 2.2 StaffBranch Relation (Sumber : Connoly dan Begg, 2010, p419) staffno staffname position salary branchno baddress SL21 John White Manager B Derr Rd, London SG37 Ann Beech Assistant B Main St, Glasgow SG14 David Ford Supervisor B Main St, Glasgow SA9 Mary Howe Assistant 9000 B Argyll St, Aberdeen SG5 Susan Brand Manager B Main St, Glasgow SL41 Julie Lee Assistant 9000 B 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.

13 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

14 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)

15 22 client No CR76 CR56 cname John Kay Aline Stewart Tabel 2.3 ClientRental Unnormalized Table (Sumber : Connoly dan Begg, 2010, p432) property No paddress rentstart rentfinish rent owner No oname PG4 6 Lawrence 1-Jul Aug CO40 Tina St, Glasglow Murphy PG16 5 Novar Dr, 1-Sep-08 1-Sep CO93 Tony Glasglow Shaw PG4 6 Lawrence 1-Sep June- 350 CO40 Tina St, Glasglow 07 Murphy PG36 2 Manor Rd, 10-Oct- 1-Dec CO93 Tony Glasglow 07 Shaw PG16 5 Novar Dr, 1-Nov- 10-Aug CO93 Tony Glasglow 09 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 cname CR76 John Kay CR56 Aline Stewart

16 Tabel 2.5 1NF PropertyRentalOwner (Sumber : Connoly dan Begg, 2010, p433) client No property No paddress rentstart rentfinish rent owner No oname CR76 PG4 6 Lawrence St, Glasglow 1-Jul Aug CO40 Tina Murphy CR76 PG16 5 Novar Dr, Glasglow 1-Sep-08 1-Sep CO93 Tony Shaw CR56 PG4 6 Lawrence St, Glasglow 1-Sep June CO40 Tina Murphy CR56 PG36 2 Manor Rd, Glasglow 10-Oct Dec CO93 Tony Shaw CR56 PG16 5 Novar Dr, Glasglow 1-Nov Aug CO93 Tony Shaw Hasil dari relasi 1NF adalah sebagai berikut : Client (clientno, cname) PropertyRentalOwner (clientno, propertyno, paddress, rentstart, H. Second Normal Form (2NF) rentfinish, rent, ownerno, oname) 2NF didasarkan pada konsep full functional dependency. 23 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.

17 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 propertyno rentstart rentfinish CR76 PG4 1-Jul Aug-08 CR76 PG16 1-Sep-08 1-Sep-09 CR56 PG4 1-Sep June-07 CR56 PG36 10-Oct-07 1-Dec-08 CR56 PG16 1-Nov Aug-10 Tabel 2.8 2NF PropertyOwner (Sumber : Connoly dan Begg, 2010, p435) propertyno paddress rent ownerno oname PG4 6 Lawrence St, 350 CO40 Tina Glasglow Murphy PG16 5 Novar Dr, 450 CO93 Tony Shaw Glasglow PG36 2 Manor Rd, 375 CO93 Tony Shaw Glasglow 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 pada konsep transitive dependency. Ketergantungan fungsional X 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.

18 (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 paddress rent ownerno PG4 6 Lawrence St, 350 CO40 Glasglow PG16 5 Novar Dr, 450 CO93 Glasglow PG36 2 Manor Rd, 375 CO93 Glasglow Tabel NF 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) Perancangan Basis Data Konseptual Proses membangun data model yang digunakan dalam suatu perusahaan. (Connolly dan Begg, 2010, p322)

19 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.

20 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.

21 28 Supervises Supervisee 0..1 Staff staffno 1..1 Registers BusinessOwner 0..1 ownerno 0..1 Managees BOwns POwns 1..* 1..* AssociatedWith PropertyForRent propertyno Views 0..* 0..* viewdate comment 0..* Client clientno Holds States 0..1 PrivateOwner 0..* Lease 0..* 1..1 Preference ownerno leaseno Gambar 2.3 Perancangan basis data konseptual (Sumber : Connoly dan Begg, 2010, p480) 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

22 29 dan mampu mendukung transaksi yang dibutuhkan. Perancangan basis data konseptual terdiri dari langkah langkah berikut ini : Langkah 2 : Membangun model data logikal 2.1 Menurunkan hubungan untuk model data logikal Bertujuan membuat hubungan model data logikal untuk merepresentasikan entitas, hubungan, dan atribut 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.2 Memvalidasi hubungan dengan menggunakan normalisasi Bertujuan untuk memvalidasi hubungan di dalam model data logikal dengan menggunakan normalisasi. 2.3 Memvalidasi hubungan terhadap transaksi pengguna Bertujuan untuk memastikan hubungan di dalam model data logikal mendukung transaksi yang dibutuhkan.

23 Memeriksa 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.5 Meninjau 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.6 Menggabungkan 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.7 Memeriksa 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.

24 31 Gambar 2.4 Perancangan basis data logikal (Sumber : Connoly dan Begg, 2010, p516)

25 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.1 Merancang base relation Bertujuan untuk memutuskan bagaimana merepresentasikan hubungan dasar yang diidentifikasi pada model data logikal dalam sasaran DBMS.

26 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 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)

27 Merancang 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.3 Merancang 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.1 Analisis transaksi Bertujuan untuk memahami fungsi dari transaksi yang akan dijalankan di database dan untuk menganalisis transaksi penting. 4.2 Memilih file organizations Bertujuan untuk menentukan file organization yang efisien untuk setiap base relation.

28 Memilih indexes Bertujuan untuk menentukan apakah penambahan indeks akan meningkatkan performa sistem. 4.4 Memperhitungkan 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)

29 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.

30 Menurut Eaglestone dan Ridley (2001,p264), web database design digambarkan sebagai berikut : 37 Gambar 2.6 Diagram web database lifecycle (Sumber : Eaglestone dan Ridley, 2001, p290) 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

31 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

32 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

33 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)

34 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

35 42 Gambar 2.9 Logical Web Page Schema Untuk Rawat Jalan (Sumber : Eaglestone dan Ridley, 2001, p317)

36 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.

37 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.

38 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.

39 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

40 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