BAB 2. Landasan Teori. Penggunaan basisdata yang tradisioanal adalah File-Based System. Setiap

Transkripsi

1 BAB 2 Landasan Teori 2.1 Pendekatan BasisData Penggunaan basisdata yang tradisioanal adalah File-Based System. Setiap program yang menggunakan File-Based System akan mendefinisikan dan mengontrol masing-masing data program itu sendiri. Tetapi aplikasi File-Based System mempunyai banyak kelemahan,contohnya : Data terpisah-pisah Data yang terisolasi pada file berbeda mengakibatkan semakin sulitnya pengaksesan terhadap data tersebut. Duplikasi data Karena setiap programmer membuat file dan aplikasi dalam jangka waktu yang lama, variasi file memiliki format yang berbeda dan kemungkinan program tersebut ditulis oleh bahasa program yang berbeda-beda. Oleh Karena itu, kemungkianan informasi yang sama dapat berbeda pada beberapa file Ketergantungan Data Struktur fisik dari file data dan record didefinisikan pada kode aplikasi. Hal ini mengakibatkan pengubahan dari struktur yang telah ada menjadi sulit dilakukan. Format data yang tidak kompatibel Karena struktur file tersimpan pada program aplikasi, struktur tersebut menjadi tergantung pada bahasa pemrograman yang digunakan. Fixed query File-Based System menawarkan system yang lebih baik, tetapi seiring dengan perkembangan akan muncul permintaan-permintaan query baru. Hal ini 8

2 9 membutuhkan pembuatan program tambahan untuk menjalankan query tersebut. Hal ini membutuhka waktu yang lama dan tamahan biaya sehingga dapat menurunkan efektifitas dari system. Dengan adanya kekurangan dari File-Based System, maka dibuatlah sisem basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan Database Management System (DBMS) Pengertian BasisData Menurut Gerard V. Post (2005,p2) basisdata adalah koleksi penyimpanan data berdasarkan standar format yang dirancang agar bisa digunakan bersama-sama oleh user yang berbeda-beda. Menurut Ramakrishman (3005, p4) basisdata adalah koleksi data, yang bertipikal penjelasan aktivitas dari satu atau lebih relasi organisasi. Menurut Atzeni, dkk (2003, p2) basisdata adalah koleksi data, yang digunakan untk merepresentasikan informasi yang menarik ke dalam sistem informasi. Maka dari itu, kami menyimpulkan bahwa basisdata adalah koleksi data yang bertipikal aktivitas dari satu atau lebih relasi organisasi yang dirancang agar bisa digunakan bersama-sama dan disimpan untuk kepentingan organisasi atau perusahaan Database Management System (DBMS) DBMS (Basisdata Management System) menurut Hofer (2005, p7) adalah sistem yang digunakan untuk membuat, merawat dan menyediakan control akses untuk

3 10 pengguna basisdata. DBMS menyediakan metode sistematik untuk pembuatan, updating, penyimpanan dan penerimaan data pada basisdata. DBMS juga menyediakan fasilitas untuk mengontrol akses data, menguatkan integritas data, mengatur control konkurensi, dan menyimpan basisdata. DBMS menurut Gererd V. Post ( 2005, p2) adalah yang menjelaskan basisdata, penyimpanan data, mendukung bahasa query, memproduksi laporan, dan membuat layer data entry. DBMS menurut Atzeni dkk (2003, p3) adalah sistem piranti lunak yang memungkinkan untuk mengatur koleksi data yang banyak, berbagi dan persisten serta untuk memastikan reliabilitas dan privacy mereka. Seperti produk yang lainnya, DBMS harus efisien dan efektif. Basisdata adalah koleksi data yang diatur oleh DBMS. DBMS menurut Connolly (2005, p17) adalah suatu sistem piranti lunak yang memungkinkan user untk mendefinisikan, membuat, merawat, dan mengontrol akses ke dalam basisdata Data Definition Language (DDL) Definisi dari Data Definition Language menurut Connolly (2005, p40) adalah suatu bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk mendeskripsikan nama dari suatu entity, atribut, dan relationship data yang diminta oleh aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya.

4 Database Manipulation Language (DML) DML menurut Gerard V. Post (2005, p146) adalah sebuah rangkaian dari perintah-perintah yang digunakan untuk mengakses data. Contohnya Command Insert, Delete, dan Update. DML menurut Connolly (2005, p40) adalah suatu bahasa yang memberikan fasilitas pengoperasian data yang ada di dalam basis data. Pengoperasian data yang akan dimanipulasi biasanya meliputi: 1. Penambahan data baru ke dalam basisdata. 2. Modifikasi data yang disimpan ke dalam basisdata. 3. Pengambilan data yang terdapat di dalam basisdata. Sedangkan definisi Procedural DML menurut Connolly (2005, p41) adalah suatu bahasa yang memperbolehkan user untuk mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana mendapatkan data tersebut secara persis GL Fourth-Generalazatin Languages atau 4 th GLs menurut Connolly (2005,p42) adalah generasi bahasa tingkat empat. Tidak ada konsensus tentang apa itu 4 th GLs, ditunjukkan untuk bahasa pemrograman yang sederhana suatu operasi yang membutuhkan banyak baris dalam bahasa generasi tingkat tiga (3th GLs), seperti COBOL, biasanya membutuhkan hanya baris 4 th GLs. Dibandingkan dengan 3 th GLs, yang membutuhkan produser,pada 4 th GLs tidak diperlukan lagi dan pengguna bisa menentukan apa saja yang harus dilakukan. 4 th GLs diharapkan dapat memudahkan penggunanya pada tingkat komponen yang lebih tinggi seperti tools generasi ke-4. Para pengguna tidak mengharapkan untuk

5 12 mendefinisikan langkah suatu program untuk melaksanakan suatu tugas, tetapi lebih mendefinisikan parameter untuk tools yang mana untuk menciptakan suatu program aplikasi. 4 th GLs diyakini dapat mengembangkan produktivitas dalam batasan jenis masalah yang bisa diatasi oelh 4 th GLs: - Presentasi bahasa, seperti query language and report generator - Bahasa khusus, seperti spreadsheets dan basisdata language - Aplikasi generator yang dapat mendefinikan, menyisipkan, memperbaharui, dan membuka kembali data dari suatu basis data untuk membuat aplikasi Database Life Cycle Sistem informasi berbasis computer terdiri dari sebuah database, piranti lunak database, piranti lunak aplikasi, perangkat keras komputer dan pemakanian perseorangan dan perkembangan sistem. Komponen terpenting dari sistem informasi adalah database. Pemakian dan perkembangan dari database harus memenuhi kebutuhan tersebar dari perusahaan. Tingkat dari information system lifecycle atau software development lifecycle (SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan pembuatan prototype, implementasi, konversi dan operasi pemeliharaan. Tingkatan dari database application lifecycle memiliki bentuk yang tidak kaku, tetapi mengikuti bentuk dari bentuk semula yaitu feedback loops. Untuk aplikasi database kecil, dengan jumlah pemakai yang kecil, siklus hidup yang diperlukan tidak terlalu kompleks. Meskipun begitu, ketika merancang database aplikasi menengah ke atas dengan jumlah pemakai dari 10 hingga 1000, menggunakan ratusan query dan program aplikasi, sisklus hidup dapat menjadi komplek.

6 13 Gambar 2.1 Tingkatan dari Database System Development Lifecycle ( Sumber : Connolly dan Begg, 2005, p284 ) Database Planning Adalah aktifitas manajemen yang memungkinkan setiap tahapan dalam Database System Development Lifecycle untuk direalisasikan seefisien dan seefektif mungkin. Database Planning seharusnya diintegrasikan dengan

7 14 keseluruhan strategi Information System dari organisasi. Ada 3 persoalan utama dalam menyusun strategi IS, antara lain : 1. Identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara subsequent dari kebutuhan sistem informasi. 2. Mengevaluasi sistem informasi yang ada untuk mendefinisikan kekuatan dan kelemahan. 3. Penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing Sistem Definition Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi basisdata dan user view utama. User view mendeskripsikan apa yang dibutuhkan dari sebuah basisdata dari sudut pandang peran pekerja (seperti manager atau supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau kontrol stok) Requirements Collection and Analysis Suatu proses yang mengumpulkan dan menganalisis informasi mengenai bagian dari organisasi yang didukung oleh aplikasi basisdata dan penggunaan informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru. Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang dinamakan teknik fact-finding. Menurut Connolly dan Begg ( 2005, p317), terdapat lima teknik fact - finding yang umum digunakan:

8 15 Mengevaluasi dokumentasi. Interview. Observasi. Research. Questioner Database Design Menurut Connolly dan Begg ( 2005, p291 ), Database design adalah suatu proses yang membuat suatu rancangan untuk basisdata yang akan mendukung kegiatan operasional dan tujuan dari perusahaan. Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical 1. Conceptual database design Pada tahap konseptual ini bertujuan untuk membuat representasi konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut. Pada tahap ini dibagi menjadi beberapa langkah, yaitu: Langkah 1. Membangun conceptual data model Langkah 1.1 Langkah 1.2 Identifikasikan Tipe Entitas Identifikasikan Tipe Relationship Langkah 1.3 Identifikasikan dan Asosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship Langkah 1.4 Langkah 1.5 Menentukan Domain Atribut Penentuan Atribut Candidate key, Primary Key, dan Alternate Key

9 16 Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Langkah 1.7 Langkah 1.8 Langkah 1.9 Memeriksa model dari redundancy Validasi Model Konseptual dengan user transaction Meninjau local conceptual data model dengan pengguna 2. Logical database design Pada tahap ini memetakan model konseptual ke model logikal yang dipengaruhi oleh model data yang menjadi tujuan dari basisdata. Dalam perancangan model logikal, model data yang telah diperoleh dalam basisdata konseptual diubah dalam bentuk dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basisdata (contoh : relational model). Hal ini dilakukan untuk menerjemahkan representasi konseptual kedalam bentuk struktur logik dalam basisdata. Model data logikal merupakan sumber informasi dalam merancang basisdata fisikal. Perancangan basisdata logikal memberikan sarana yang membantu para perancang dalam merancang basisdata fisikal. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 2. Membangun dan memvalidasi logical data model Langkah 2.1 Langkah 2.2 Langkah 2.3 Langkah 2.4 Langkah 2.5 Menentukan Relasi Relasi untuk Model Data Logikal Validasi Model dengan Normalisasi Memvalidasi Relasi dengan User Transaction Mendefinisikan Kendala Integrity Me-review logical data model dengan User

10 17 Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global Model (optional) Langkah 2.7 Memeriksa untuk perkembangan lebih lanjut 3. Physical database design Tahap physical datanbase design memungkinkan perancang basisdata untuk membuat keputusan mengenai bagaimana basisdata akan diimplementasikan. Oleh karena itu, physical databse design harus disesuaikan dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Langkah 3.1 Langkah 3.2 Langkah 3.3 Merancang relasi relasi dasar Merancang representasi untuk data Turunan Merancang general constraint Langkah 4. Merancang file organization dan indexes Langkah 4.1 Langkah 4.2 Langkah 4.3 Langkah 4.4 Menganalisa transaksi Memilih organisasi file Memillih index index Memperkirakan kebutuhan disk space Langkah 5. Merancang user view Langkah 6. Merancang mekanisme keamanan Langkah 7. Mempertimbangkan pengenalan redudancy control Langkah 8. Mengawasi dan mengendalikan sistem operasional

11 DBMS Selection Pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basisdata. Menurut Connolly dan Begg ( 2005, p295 ), berikut ini adalah langkah langkah dalam memilih DBMS : 1. Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan 2. Membuat perbandingan mengenai 2 atau 3 produk DBMS 3. Mengevaluasi produk-produk DBMS tersebut 4. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut. Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut : 1. Mengijinkan pengguna untuk menentukan basisdata, biasanya melalui Data Definition Language (DDL). DDL mengijinkan pengguna untuk menspesifikasikan tipe data, struktur dan batasan-batasan data yang bisa disimpan di basisdata. 2. Mengijikan pengguna untuk insert, update, delete atau retrive data dari basisdata, biasanya melalui Data Manipulation Language(DML). 3. DBMS menyediakan akses kontrol ke basisdata. Sebagai contohnya DBMS menyediakan : a. Security system, dimana mencegah autorisasi pengguna untuk mengakses basisdata. b. Integrity system, dimana menangani konsistensi penyimpanan data. c. Concurrency control system, dimana mengijinkan basisdata untuk diakses secara share.

12 19 d. Recovery control system, dimana basisdata bisa di-restore pada saat terjadi kesalahan pada hardware maupun software. e. User-accesable catalog, dimana berisi deskripsi data dalam basisdata Application Design Menurut Connolly dan Begg ( 2005, p299 ), Rancangan aplikasi adalah rancangan dari user interface dan program aplikasi yang digunakan dan memproses basisdata. Dalam kebanyakan kasus tidak mungkin dapat menyelesaikan aplication design sebelum menyelesaikan database design itu sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada banyak aliran infomasi anatar application design dan database design Prototyping (Optional) Pada kondisi tertentu kita dapat memilih apakah akan membuat prototype atau langsung mengimplementasikan basisdata. Suatu prototype adalah suatu model aplikasi basisdata yang mempunyai semua corak yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama prototype itu untuk menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem tersebut. Menurut Connolly dan Begg ( 2005, p303 ), ada dua cara strategi membuat prototype yaitu requirements prototyping dan evolutioner prototyping. Untuk requirements prototyping digunakan prototype untuk menentukan

13 20 kebutuhan suatu aplikasi basisdata yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototype tersebut tidak lagi digunakan. Protype evolutioner digunakan untuk tujuan yang sama, perbedaannya adalah bahwa prototype tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi aplikasi basisdata tersebut Implementasi Menurut Connolly dan Begg ( 2005, p304 ), implementasi merupakan perwujudan fisik dari basisdata dan desain aplikasi. Setelah menyelesaikan tahap desain (dengan atau tanpa prototype), selanjutnya pada tahap implementasi basisdata dan program aplikasi. Implementasi basisdata dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang telah dipilih atau dengan menggunakan Graphical User Interface (GUI), masing - masing meyediakan fungsi ketika menyembunyikan pernyataan (statement) DDL yang low - level. Pernyataan DDL digunakan untuk menciptakan struktur basisdata dan mengosongkan file yang terdapat dalam basisdata tersebut. User view juga diterapkan dalam langkah implementasi. Program aplikasi diterapkan dengan menggunakan bahasa generasi keempat atau ketiga (4GL atau 3GL). Bagian dari program aplikasi ini adalah transaksi basisdata yang diterapkan menggunakan Data Manipulation Language (DML). Transaksi basisdata juga dapat dibuat dalam bahasa pemrograman seperti Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada, atau Pascal. Juga dapat diterapkan komponen lain dari desain aplikasi seperti layar menu, format masukan data, dan laporan.

14 21 Pengendalian keamanan dan integritas untuk aplikasi juga diimplementasikan. Sebagian dari kendali ini telah diterapkan dengan menggunakan DDL, tetapi yang lain mungkin perlu digambarkan diluar DDL. Sebagai contoh, kegunaan yang disediakan DBMS atau kendali sistem operasi Data Convertion dan Loading Menurut Connolly dan Begg ( 2005, p305 ), pemindahan data yang ada ke basisdata yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basisdata yang baru Testing Menurut Connolly dan Begg ( 2005, p305 ), Testing adalah suatu proses yang melaksanakan proses aplikasi dengan tujuan menemukan kesalahan. Dalam melakukan testing, para pengguna baru harus dilibatkan untuk menguji proses aplikasi dan basisdata tersebut. Situasi yang ideal untuk pengujian sistem adalah mempunyai suatu tes basisdata pada suatu sistem perangakat keras, tetapi ini sering tidak tersedia. Jika data real yang diharapkan untuk digunakan, maka adalah penting untuk mempunyai backup. Setelah pengujian diselesaikan, maka sistem aplikasi dan basisdata ini telah siap digunakan Operational Maintenance Menurut Connolly dan Begg ( 2005, p306 ), setelah melalui tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang melibatkan aktivitas berikut :

15 22 1. Monitoring performance dari sistem. Jika performansi berada disuatu tingkatan yang bisa diterima, penyetelan atau menyusun kembali basisdata mungkin diperlukan. 2. Memelihara dan meningkatkan mutu aplikasi basisdata. Kebutuhan baru disatukan kedalam aplikasi basisdata dengan mengikuti langkah langkah sebelumnya yang terdapat dalam database lifecycle. Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat diterima. Monitoring proses akan terus berlanjut sepanjang seluruh hidup suatu aplikasi basisdata tersebut dan pada waktu tertentu boleh melakukan menyusun kembali basisdata untuk mencukupi kebutuhan dari sistem. Perubahan ini meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika tersedia Tahap-Tahap Perancangan BasisData Dalam merancang suatu basisdata melalui beberapa tahapan, sebagai berikut : Perancanagan Basisdata Konseptual Perancanagan Basisdata Logikal

16 23 Perancanagan Basisdata Fisikal Perancangan Basisdata Konseptual Menurut Connolly dan Begg ( 2005, p439 ), perancangan konseptual basisdata adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basisdata, yang meliputi identifikasi dari entitas - entitas, relationship - relationship, dan atribut - atribut yang penting. Menurut Connolly dan Begg ( 2005, p443 ), langkah - langkah perancangan konseptual basisdata yaitu : Langkah 1. Membangun Conceptual Data Model Menurut Connolly dan Begg ( 2005, p442 ), tujuannya adalah untuk membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type, atribut - atribut, domain domain atribut, primary key, alternate key, dan integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 : Langkah 1.1 Identifikasikan Tipe Entitas Menurut Connolly dan Begg ( 2005, p443 ), tujuannya adalah mengidentifikasikan tipe tipe entitas utama yang dibutuhkan oleh view. Langkah 1.2 Identifikasikan Tipe Relationship Menurut Connolly dan Begg ( 2005, p445 ), tujuannya adalah mengidentifikasikan relationship relationship penting yang ada diantara tipe tipe entitas yang telah diidentifikasi.

17 24 Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship Menurut Connolly dan Begg ( 2005, p447 ), tujuannya adalah untuk menghubungkan atribut atribut dengan entitas atau relationship type yang sesuai. Langkah 1.4 Menentukan Domain Atribut Menurut Connolly dan Begg ( 2005, p450 ), tujuannya adalah untuk menentukan domain domain untuk atribut atribut dalam local conceptual data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Domain merupakan fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama. Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate Key Menurut Connolly dan Begg ( 2005, p451 ), tujuannya adalah untuk mengidentifikasikan candidate candidate key untuk tiap tipe entitas dan, jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan primary key. Menurut Connolly dan Begg ( 2005, p451 ), ketika memilih primary key diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu : - Candidate key dengan kumpulan atribut yang minimal - Candidate key yang nilainya jarang berubah

18 25 - Candidate key dengan karakter karakter yang paling sedikit (untuk yang memiliki textual attributes) - Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki numerical attributes) - Candidate key yang paling mudah digunakan dari sudut pandang user Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Menurut Connolly dan Begg ( 2005, p453 ), tujuannya adalah untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization / generalization, aggregation, dan composition. Langkah 1.7 Memeriksa model dari redundancy Menurut Connolly dan Begg ( 2005, p453 ), tujuannya adalah untuk memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam langkah ini adalah : memeriksa kembali one-to-one relationship dan menghilangkan redundant relationships. Langkah 1.8 Validasi Model Konseptual dengan User Transaction Menurut Connolly dan Begg ( 2005, p456 ), tujuannya adalah untuk menjamin bahwa model konseptual mendukung transaksi transaksi yang dibutuhkan oleh view. Langkah 1.9 Meninjau local conceptual data model dengan pengguna Menurut Connolly dan Begg ( 2005, p458 ), tujuannya adalah untuk meninjau local conceptual data model dengan user untuk menjamin bahwa model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan oleh perusahaan.

19 26 Supervises Supervisor {Optional} Staff Registers staffno {PK} name fname lname position sex DOB Manages PropertyForRent Views 0.. * Client Owns * propertyno {PK} address street city postcode type rooms rent * 0.. * viewdate comment clientno {PK} name fname lname telno Holds States Owner 0.. * Lease 0.. * Preference PrivateOwner ownerno {PK} address telno {Mandatory, Or} AssociatedWith BusinessOwner leaseno {PK} paymentmethod depositpaid rentstart rentfinish /deposit /duration preftype maxrent name fname lname bname btype contactname Gambar 2.2 ERD Conseptual ( Sumber : Connolly dan Begg, 2005, p464 ) Perancangan Basisdata Logikal Menurut Connolly dan Begg ( 2005, p439 ), perancangan logikal basisdata adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada

20 27 particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basisdata yang meliputi perancangan relasi relasi. Menurut Connolly dan Begg ( 2005, p462 ), langkah langkah perancangan basisdata logikal yaitu : Langkah 2. Membangun dan memvalidasi logical data model Menurut Connolly dan Begg ( 2005, p462 ), tujuannya adalah menerjemahkan logical data model dan kemudian untuk memvalidasi model tersebut untuk memeriksa model tersebut benar secara struktural dan memiliki kemampuan untuk mendukung transaksi transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah langkah berikut : Langkah 2.1 Menentukan Relasi Relasi untuk Model Data Logikal Menurut Connolly dan Begg ( 2005, p463 ), tujuannya adalah menciptakan relasi relasi untuk model data logikal untuk merepresentasikan entitas entitas, relationship relationship, dan atribut atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual : Strong Entity Type dan Weak Entity Type Menurut Connolly dan Begg ( 2005, p354 ), strong entity type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type adalah tiap entity occurrence dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering juga disebut parent atau owner atau dominant entities.

21 28 Menurut Connolly dan Begg ( 2005, p355 ), weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child, dependent, atau subordinate entities. One-to-many (1:*) binary relationship types Menurut Connolly dan Begg ( 2005, p465 ), untuk tiap 1:* binary relationship, entitas pada one side dari relationship dianggap sebagai entitas parent dan entitas pada many side dianggap sebagai entitas child. Untuk merepresentasikan relationship ini, pasangkan salinan primary key dari entitas parent ke dalam relation yang merepresentasikan entitas child, untuk berlaku sebagai foreign key. One-to-one (1:1) binary relationsip types Menurut Connolly dan Begg ( 2005, p465 ), penciptaan relasi - relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasikan entitas - entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik untuk merepresentasikan relationship dengan menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana

22 29 menciptakan relasi relasi untuk merepresentasikan participation constraint berikut : - Mandatory participation pada 2 sisi dari 1:1 relationship - Mandatory participation pada 1 sisi dari 1:1 relationship - Optional participation pada 2 sisi dari 1:1 relationship Mandatory participation pada 2 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005, p466 ), pada kasus ini, kita harus menggabungkan entitas entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key. Mandatory participation pada 1 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005, p466 ), pada kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1 relationship menggunakan participation constraint. Entitas yang mempunyai optional participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key ke relasi child.

23 30 Optional participation pada 2 sisi dari 1:1 relationship Menurut Connolly dan Begg ( 2005, p467 ), kita dapat memilih primary key mana yang dipilih tergantung dari kasus yang ada. One-to-one (1:1) recursive relationship Menurut Connolly dan Begg ( 2005, p467 ), untuk 1:1 recursive relationship, kita mengikuti aturan untuk participation seperti yang diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan mandatory participation pada 2 sisi, representasikan recursive relationship sebagai relasi tunggal dengan 2 salinan primary key. Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus diubah namanya untuk menandakan relationship yang direpresentasikan. Untuk 1:1 recursive relationship dengan mandatory participation pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan 2 salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key. Untuk 1:1 recursive relationship dengan optional participation pada 2 sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas. Superclass/subclass relationship types Menurut Connolly dan Begg ( 2005, p467 ),untuk tiap superclass atau subclass relationship dalam data model konseptual, kita

24 31 mengidentifikasikan entitas superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam merepresentasikan relationship sebagai salah satu atau lebih relasi relasi. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointnese dan participation constraint pada superclass / subclass relationship apakah subclass subclass terlibat dalam distinct relationship dan jumlah participant participant dalam superclass / subclass relationship. Many-to-many (*:*) binary relationship types Menurut Connolly dan Begg ( 2005, p469 ), untuk tiap *:* binary relationship menciptakan relasi untuk merepresentasikan relationship dan meliputi atribut atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam relationship kedalam relasi baru. Untuk berlaku sebagai foreign key. Complex relationship types Menutur Connolly dan Begg ( 2005, p470 ), untuk setiap complex relationship menciptakan sebuah relasi untuk merepresentasikan relationship dan termasuk semua atribut yang merupakan bagian dari relationship tersebut. Kita menyalin salinan primary key dari entitas yang berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key.

25 32 Multi-valued attributes Menurut Connolly dan Begg ( 2005, p471 ), menciptakan relasi yang merepresentasikan atribut atribut multi-valued dan menyalin salinan primary key dari entitas owner kedalam relasi baru untuk menjadi foreign key. Langkah 2.2 Validasi Model dengan Normalisasi Menurut Connolly dan Begg ( 2005, p473 ), tujuannya adalah untuk memvalidasi relasi relasi dalam model data konseptual menggunakan teknik normalisasi. Menurut Connolly dan Begg ( 2005, p388 ), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi relasi dengan properti properti yang diinginkan, sesuai dengan kebutuhan data data yang diberikan oleh perusahaan. Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data (perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update anomaly). Menurut Connolly dan Begg ( 2005, p391 ), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity

26 33 constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data. Menurut Connolly dan Begg ( 2005, p401 ), proses normalisasi meliputi langkah langkah utama berikut : - First Normal Form ( 1NF ), yang menghilangkan repeating groups - Second Normal Form ( 2NF ), yang menghilangkan partial dependency dalam primary key - Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies dalam primary key - Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly anomaly yang tersisa dari functional dependencies Langkah 2.3 Mendefinisikan Kendala Integrity Menurut Connolly dan Begg ( 2005, p474 ), tujuannya adalah memeriksa integrity constraint yang direpresentasikan dalam model data logical. Integrity constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity, dan general constraint.

27 34 Data yang dibutuhkan Menurut Connolly dan Begg ( 2005, p475 ), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null. Attribute domain constraint Menurut Connolly dan Begg ( 2005, p475 ), tiap atribut mempunyai domain, yaitu kumpulan nilai nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu M atau F, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari M; atau F. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data. Multiplicity Menurut Connolly dan Begg ( 2005, p475 ), multiplicity merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basisdata. Entity integrity Menurut Connolly dan Begg ( 2005, p475 ), primary key dari entitas tidak boleh bernilai null. Batasan ini harus betul betul dipertimbangkan ketika kita mengidentifikasikan primary key untuk tiap tipe entitas. Referential integrity Menurut Connolly dan Begg ( 2005, p475 ), foreign key menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent yang meliputi nilai candidate key yang sesuai. Referential integrity berarti

28 35 bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent. Menurut Connolly dan Begg ( 2005, p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple pada relasi parent, yaitu : - NO ACTION Mencegah penghapusan dari relasi parent jika terdapat tuple tuple child yang ditunjuk. - CASCADE Ketika tuple parent dihapus, secara otomatis juga dihapus tuple tuple child yang ditunjuk - SET NULL Ketika tuple parent dihapus, nilai foreign key dalam semua tuple tuple child yang berhubungan secara otomastis diubah menjadi null. - SET DEFAULT Ketika tuple parent dihapus, nilai foreign key dalam semua tuple tuple child yang berhubungan secara otomatis diubah menjadi nilai default-nya. - NO CHECK Ketika tuple parent dihapus, tidak melakukan apa apa untuk menjamin referential integrity tetap terjaga.

29 36 General constraints Pengubahan pengubahan pada entitas entitas mungkin diatur oleh batasan batasan yang memerintah transaksi real world yang direpresentasikan oleh pengubahan tersebut Langkah 2.4 Menggabungkan Logical Data Model ke dalam Global Model (optional) Menurut Connolly dan Begg ( 2005, p479 ), tujuannya adalah untuk merepresentasikan semua user views dari basisdata. Langkah 2.5 Memeriksa untuk perkembangan lebih lanjut Menurut Connolly dan Begg ( 2005, p490 ), tujuannya adalah menentukan apakah terdapat perubahan signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.

30 37 Gambar 2.3 ERD Logical ( Sumber : Connolly dan Begg, 2005, p489 ) Perancangan Basisdata Fisikal Menurut Connolly dan Begg ( 2005, p439 ), perancangan fisik basisdata adalah proses membuat deskripsi dari implementasi basisdata pada secondary storage, mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk mendapatkan akses efisien pada data dan semua integrity

31 38 constraint yang berhubungan dan security measures. Tujuannya adalah untuk memutuskan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih. Menurut Connolly dan Begg ( 2005, p496 ), langkah langkah perancangan fisik basisdata meliputi : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Menurut Connolly dan Begg ( 2005, p497 ), tujuannya adalah untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 : Langkah 3.1 Merancang relasi relasi dasar Menurut Connolly dan Begg ( 2005, p498 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan relasi relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari : - Nama relasi - Daftar atribut atribut sederhana dalam golongan golongan - Primary key dan alternate key dan foreign key jika ada - Referential integrity contraints untuk semua foreign keys yang diidentifikasikan Menurut Connolly dan Begg ( 2005, p498 ), sedangkan dari data dictionary, dari tiap tiap atribut kita juga mempunyai :

32 39 - Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain - Nilai default optional untuk atribut - Apakah atribut dapat mempunyai nilai nulls - Apakah atribut tersebut derived, maka harus dikomputasi Langkah 3.2 Merancang Representasi untuk Data Turunan Menurut Connolly dan Begg ( 2005, p499 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai nilai dari atribut atribut lainnya disebut derived atau calculated attribute. Langkah 3.3 Merancang General Constraint Menurut Connolly dan Begg ( 2005, p501 ), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih. Langkah 4. Merancang file organization dan indexes Menurut Connolly dan Begg ( 2005, p501 ), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi relasi dasar dan indeks indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage. Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu :

33 40 - Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak. - Response time adalah waktu yang diperlukan untuk menyelesaikan satu transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling, communication delay. - Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan file file basisdata. Para perancang sistem biasanya ingin meminimalkan disk storage yang digunakan. Langkah 4.1 Menganalisa Transaksi Menurut Connolly dan Begg ( 2005, p502 ), tujuannya adalah untuk mengerti fungsi dari transaksi yang akan diterapkan pada basisdata dan untuk menganalisa transaksi transaksi yang penting. Langkah 5. Merancang mekanisme keamanan Menurut Connolly dan Begg ( 2006, p516 ), tujuannya adalah untuk merancang mekanisme keamanan untuk basisdata seperti yang ditentukan oleh user pada waktu tahap pengumpulan kebutuhan kebutuhan dari system development lifecycle. Mekanisme kemanan yang dirancang dalam basisdata yaitu mekanisme keamanan sistem dan mekanisme keamanan data.

34 41 Langkah 6. Mempertimbangkan pengenalan redudancy control Menurut Connolly dan Begg ( 2006, p519 ), tujuannya adalah untuk menentukan apakah pengenalan redundancy yang dikontrol dengan aturan aturan normalisasi akan meningkatkan performansi sistem. Langkah 7. Mengawasi dan mengendalikan sistem operasional Menurut Connolly dan Begg ( 2006, p532 ), tujuannya adalah untuk mengawasi sistem operasional dan meningkatkan performansi dari sistem untuk memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan perubahan kebutuhan ER Modeling Terdapat beberpa konsep Model ER yang berupa : Entity Type Menurut Connolly dan Begg ( 2005, p343) entity type adalah kelompok objek dengan properties yang sama, yang didefinisikan unutk perusahaan selama mempunyai keadaan yang independent. Entity type memepuyai kedaan yang independent dan dapat berupa objek-objek dengan keberadaan fisik atau objekobjek denga keberadaan konseptual Entity Occurrence Menurut Connolly dan Begg (2005, p346) relationship occurrence adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1 occurrance dari tiap participating entity type

35 Atribut Menurut Connolly dan Begg (2005, p350) atribut adalah property dari entitas atau relationship type. Atribut domain adalah sekumpulan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan menjadi a. Simple Atribut yaitu yang terdiri dari satu komponen tunggal dengan keberadaan yang idependen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi b. Composite Atibut yaitu atribut yang terdiri dari beberpa komponen, dimana masing-masing komponen memilki keberdaan yang independen c. Single-valued Atribut yaitu atribut yang mempuyai nilai tunggal untuk setiap kejadian d. Multi-valued Atribut yaitu atribut yang mempuyai beberpa nilai untuk setiap kejadian e. Derived Atribut yaitu atribut yang memilki nilai yang dihasilakan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas Key Menurut Connolly dan Begg ( 2005, p352 ), candidate key adalah sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap occurrence dari entity type. Menurut Connolly dan Begg ( 2005, p353 ), primary key adalah key yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari entity type.

36 43 Menurut Connolly dan Begg ( 2005, p353 ), composite key adalah candidate key yang terdiri dari dua atau lebih atribut. Gambar 2.4 ER Diagram Structural constraint Tipe utama dari constraint dari relationship disebut multiplicity. Multiplicity adalah jumlah dari kejadian kejadian yang mungkin dari sebuah tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus. Tiga jenis relationship yang digunakan mengikuti enterprise constraint : Hubungan one-to-one (1:1) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan

37 44 member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal 1. Contoh : satu produk hanya memiliki satu bonus dan bonus hanya dimiliki oleh satu produk. Diasumsikan hanya produk tertentu saja yang mempunyai bonus dan bonusnya hanya satu. Produk 1..1 has 1..1 Bonus Gambar 2.5 Hubungan one-to-one (1:1) Hubungan one-to-many (1:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satubanyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal 1. Contoh : seorang kepala sekolah dapat memiliki 1 hingga banyak guru, tetapi seorang guru hanya memiliki satu dan hanya satu kepala sekolah has 1..* KepalaSekolah Guru Gambar 2.6 Hubungan one-to-many (1:*)

38 45 Hubungan many-to-many (*:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyakbanyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut. Contoh : Pembeli dapat memilih 0 hingga banyak produk yang ingin dibeli, tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk. Pembeli 0..* Order 0..* OrderedBy Produk Gambar 2.7 Hubungan many-to-many (*:*) Normalisasi Tujuan uatama dalam pengembangan model data logical pada sistem database relational adlah menciptakan representasi akurat suatu data, relationship anatar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka harus ditetapkan sekumpulan relasi Pengetian Normalisasi Menurut Connolly dan Begg ( 2005, p401 ), normalisasi adalah teknik formal untuk menganalisa relasi berdasarkan pada primary key (atau candidate key) dan functional dependencies.

39 Tahapan- tahapan Normalisasi Normalisasi memiliki Empat bentuk normal yang biasa digunakan yaitu : first normal form, second normal form dan third normal form dan beyce-codd normal form UNF (Un-Normal Form) Menurut Connolly dan Begg ( 2005, p402 ), proses normalisasi dimulai dari bentuk UNF (Un-Normal Form), yaitu tabel yang masih mengandung repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom NF (First Normal Form) Menurut Connolly dan Begg ( 2005, p403 ), pada bentuk normal pertama ( First Normal Form 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau sekumpulan atribut dalam tabel yang memiliki multiple values untuk single occurrence dari atribut key yang terpilih untuk tabel tersebut NF (second Normal Form) Menurut Connolly dan Begg ( 2005, p407 ), sebuah tabel disebut berada pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah 1NF telah berada pada 2NF maka tentukan PK dan funtional dependency.

40 NF (Third Normal Form) Menurut Connolly dan Begg ( 2005, p408 ), sebuah tabel disebut berada pada bentuk normal ketiga jika dan hanya jika tidak ada atribut bukan primary key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada 3NF jika dan hanya jika tidak mengandung transitive dependency BCNF(Boyce-Codd Normal Form) Menurut Connolly dan Begg ( 2005, p419 ), suatu relasi dianggap sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk normal BCNF maka harus dilakukan analisa atas functional dependency dari sebuah tabel Tools Yang Digunakan Untuk menyelesaikan suatu masalah dengan cara mendekomposisi system ke dalam komponen yang lebih kecil dengan tujuan untuk mempelajari bagaimana komponen-komponen tersebut bekerja dan saling berinteraksi maka kita memerlukan tool-tool yang dapat mencerminkan proses. Adapun beberapa tool yaitu : Data Flow Diagram Menurut Hall ( 2001, p69 ), DFD yang juga disebut dengan Diagram Arus Data, adalah diagram yang menyajikan rangkaian simbol - simbol untuk mencerminkan proses, sumber-sumber data, arus data, dan entitas dalam sebuah sistem pada tingkatan rinci yang berbeda.

41 48 DFD pertama kali diperkenalkan sebagai modeling tools Tom Demarco ( 1978 ), Gane dan Sarson ( 1979 ) dengan menggunakan pendekatan metode analisis sistem terstrukstur (structured system analysis method). DFD juga dapat digunakan untuk merepresentasikan suatu sistem yang otomatis maupun manual dengan menggunakan gambar yang berbentuk jaringan grafik. Tingkatan Diagram Pada DFD : 1 Diagram Konteks Merupakan level tertinggi pada DFD yang menggambarkan seluruh output atau input ke sistem Memberikan gambaran tentang keseluruhan sistem Terminal yang memberikan masukan kepada sistem disebut source, sedangkan yang menerima keluaran dari sistem disebut sink Hanya ada satu proses didalam diagram konteks Tidak boleh ada proses penyimpanan data (data store) 2. Diagram Nol Memperlihatkan proses penyimpanan data (data store) yang digunakan Untuk proses yang tidak rinci lagi pada level selanjutnya, tambahkan tanda * pada akhir nomor proses Keseimbangan antara input dan output pada diagram nol dan diagram konteks harus terpelihara

42 49 Simbol-simbol dalam DFD adalah : Tabel 2.1 Tabel Simbol DFD External entity atau terminal Proses Penyimpanan data atau data storage Aliran data atau Data Flow State Transition Diagram (STD) Menurut Pressman ( 2001, p302 ), State Transition Diagram merupakan suatu diagram yang menggambarkan bagaimana state dihubungkan dengan state yang lain pada satu waktu. State Transition Diagram menunjukkan bagaimana sistem bekerja sebagai akibat dari kejadian eksternal. Untuk melakukan hal itu, State Transition Diagram menampilkan model yang bermacam-macam dari tindakan sebuah sistem dan dibuat dari state ke state. Komponen dasar dari State Transition Diagram adalah :

43 50 1. : menyatakan state atau kondisi dari suatu sistem. State terdiri dari dua macam, yaitu initial state / state awal dan final state / state akhir. Final state dapat terdiri atas beberapa state, tetapi initial state tidak boleh lebih dari satu. 2. : menyatakan perubahan kondisi dari suatu sistem. Digambarkan untuk menghubungkan keadaan sistem yang berkaitan. 3. Kondisi dan Aksi Kondisi : menyatakan suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh suatu sistem. Misalnya : suatu sinyal / data. Aksi : menyatakan sesuatu yang dilakukan oleh sistem apabila terjadi perubahan state / merupakan suatu reaksi terhadap kondisi. Aksi akan menghasilkan output, message display pada monitor dan menghasilkan kalkulasi Bagan Alir Dokumen (Document FlowChart) Document FlowChart digunakan untuk menggambarkan bagan alir dokumen suatu sistem. Berikut adalah simbol simbol standar beserta keterangannya untuk mengambarkan bagan alir dokumen : Tabel 2.2 Tabel Simbol Document FlowChart Lambang Keterangan Dokumen. Simbol ini digunakan untuk menggambarkan semua jenis dokumen, yang merupakan formulir yang diunakan untuk merekam data terjadinya suatu transaksi