BAB 2 LANDASAN TEORI 2.1 Teori-teori Dasar atau Umum 2.1.1
advertisement
BAB 2 LANDASAN TEORI 2.1 Teori-teori Dasar atau Umum 2.1.1 Perbedaaan File Based System dengan Sistem Basis Data Pada saat ini aplikasi basisdata sudah digunakan di kehidupan sehari-hari, seperti pembelian di supermarket, pembelian dengan kartu kredit, pemesanan hotel melalui biro perjalanan, penggunaan pada perpustakaan, penggunaan internet, dll. Penggunaan basisdata yang tradisional adalah File-Based System. Menurut Thomas M. Connolly (2002, p7) pengertian dari File-Based System adalah kumpulan program aplikasi yang menyajikan service kepada pemakai seperti pembuatan laporan. Setiap program akan mendefinisikan dan mengontrol masing-masing data program itu sendiri. Tetapi aplikasi File-Based System mempunyai banyak kelemahan, contohnya : Data yang 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, kemungkinan informasi yang sama dapat berada pada beberapa file. 7 Ketergantungan data Seperti yang telah disebutkan di atas, 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/proliferation of application programs. Dibandingkan dengan sistem manual, file-based system menawarkan sistem yang lebih baik, tetapi seiring dengan perkembangan akan muncul permintaan-permintaan query baru. Hal ini membutuhkan pembuatan program tambahan untuk dapat menjalankan query tersebut. Hal ini membutuhkan waktu dan biaya tambahan sehingga dapat menurunkan efektifitas dari sistem. Dengan adanya kekurangan dari File-Based System, maka dibuatlah sistem basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan Database Management System (DBMS). 2.1.2 Pengertian Database Pengertian database menurut Thomas M. Connolly (2002, p14) adalah kumpulan data yang saling berhubungan secara logical, dan keterangan mengenai data itu, yang dibuat untuk menemukan informasi yang dibutuhkan 8 oleh sebuah organisasi. Database yang tunggal dapat digunakan oleh berbagai pengguna atau bagian dalam waktu yang bersamaan. Menurut C. J. Date (2000, p10) database adalah kumpulan data persistent yang digunakan oleh sistem aplikasi dari perusahaan tertentu. Persistent maksudnya adalah sekali data telah diterima oleh DBMS untuk dimasukkan ke dalam database, data tersebut hanya bisa dihapus dari database dengan menggunakan permintaan eksplisit ke DBMS. Sistem Basisdata adalah sistem penyimpanan rekaman atau record yang terkomputerisasi di mana tujuan sebenarnya adalah menyimpan informasi dan membuat informasi tersebut selalu tersedia pada saat dibutuhkan 2.1.3 Database Management System (DBMS) DBMS adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke database. Fasilitas-fasilitas yang disediakan DBMS : • Memungkinkan pengguna mendefinisikan database biasanya melalui DDL (Data Definition Language). DDL memungkinkan pengguna untuk menentukan tipe dan struktur data yang akan disimpan pada database. • Memungkinkan pengguna untuk memasukkan, meng-update, menghapus, dan mengambil data dari database biasanya melalui DML (Data Manipulation Language). • Menyediakan akses terkontrol ke database. Contohnya : 9 Sistem sekuriti, mencegah pengguna yang tidak memiliki hak untuk mengakses database. Sistem integrity, memelihara konsistensi dari data yang disimpan Concurrency control system, memungkinkan akses bersama database Recovery control system, mengembalikan database ke keadaan sebelumnya yang masih konsisten ketika terjadi kerusakan perangkat keras atau perangkat lunak. User-accessible catalog, berisi deskripsi dari data pada database. Keuntungan dari DBMS : Mengontrol duplikasi data Database dapat mengurangi duplikasi data yang terjadi pada File-Based System. Tetapi tidak semua duplikasi data dapat dihilangkan, melainkan hanya dapat dikontrol. Hal ini dikarenakan terkadang duplikasi data tetap dibutuhkan untuk meningkatkan perfoma. Data konsisten Dengan menghilangkan atau mengontrol duplikasi data akan mengurangi resiko ketidakkonsistenan dari data yang mungkin terjadi. Data yang sama memiliki lebih banyak informasi Dengan adanya integrasi data operasional maka memungkinkan bagi sebuah organisasi mendapatkan informasi tambahan dari data yang sama. Penggunaan data bersama-sama Biasanya file dimiliki oleh seseorang atau departemen yang menggunakannya. Sebaliknya database dimiliki oleh organisasi secara keseluruhan dan dapat di-share kepada pengguna yang memiliki hak. 10 Integritas data telah dikembangkan Integritas data memiliki arti dari konsisten dan keabsahan dari data yang disimpan. Integritas biasanya menegaskan arti dari constraint, yang merupakan aturan yang tidak dapat di langgar oleh pemakai database. Keamanan telah dikembangkan Keamanan database akan melindungi database dari pemakai yang tidak memiliki hak. Hal ini biasanya dilakukan dengan adanya nama pemakai dan password untuk mengidentifikasikan hak yang dimiliki oleh setiap pemakai. Memiliki standar yang jelas Integrasi memungkinkan Database Administrator (DBA) untuk mendefinisikan dan memberikan standar yang dibutuhkan, seperti format data untuk mendukung pertukaran data antar sistem, aturan penamaan, standar dokumentasi, prosedur update, dan cara atau hak pengaksesan. Ekonomis Dengan menggabungkan semua data operasional organisasi ke dalam satu database dan membuat beberapa aplikasi yang bekerja dengan menggunakan satu sumber data, ini dapat menghemat pengeluaran. Jadi dana yang di keluarkan akan labih kecil dari dana tiap bagian pada file based system bila digabungkan. Konflik kebutuhan dapat diseimbangkan Setiap pengguna atau departemen mempunyai suatu kebutuhan masingmasing, di mana kebutuhan tersebut dapat menimbulkan konflik dengan pengguna atau departemen yang lain. Dengan database berada di bawah 11 kendali dari DBA, maka DBA dapat membuat keputusan mengenai perancangan dan penggunaan operational dari database yang menyediakan penggunaan sumber daya database terbaik bagi organisasi. Meningkatkan kemampuan akses dan respon data Sebagai hasil integrasi, data umum dapat diakses secara langsung oleh pemakai. Hal ini menyediakan sistem yang memiliki lebih banyak fungsi. Meningkatkan produktifitas DBMS menyediakan banyak fungsi standar yang biasanya harus dibuat oleh seorang programmer pada aplikasi berbasis file. Pada tingkat dasar DBMS menyediakan semua rutin low level untuk menangani file yang biasanya ada pada program aplikasi. Kegunaan dari fungsi ini adalah membuat seorang programmer dapat memusatkan perhatiannya hanya pada fungsi yang spesifik yang dibutuhkan oleh pengguna, tanpa perlu memikirkan detil dari implementasi low level-nya. Mempermudah perawatan dengan menghilangkan ketergantungan data Dalam file-based system deskripsi dari data dan logika untuk pengaksesan data dibuat untuk tiap aplikasi, sehingga program sangat tergantung terhadap data. Sebuah perubahan terhadap struktur data tersebut, sebagai contoh variabel alamat yang sebelumnya dgn panjang 40 karakter ingin diubah menjadi 41 karakter, ini memerlukan perubahan yang banyak pada program yang terpengaruh efek dari perubahan tersebut. Sedangkan pada DBMS deskripsi data dan aplikasi terpisah, dengan cara demikian membuat aplikasi tidak terpengaruh terhadap perubahan dari deskripsi data. 12 Meningkatkan concurrency Pada file-based system, jika dua atau lebih pengguna yang mengakses file yang sama secara bersamaan, akses itu bisa saling mempengaruhi, dan bahkan bisa membuat hilangnya informasi. Sedang DBMS dapat mengelola akses data secara bersamaan. Meningkatkan kemampuan backup dan perbaikan Pada file-based system, pengguna sendiri yang bertanggung jawab untuk melindungi data dari kegagalan sistem komputer atau program aplikasi. Hal tersebut membutuhkan kerja tambahan di mana pengguna harus melakukan backup data, dan apabila backup tersebut hilang, pengguna harus mengulang kembali peng-input-an data. Kebalikannya, DBMS modern menyediakan fasilitas untuk mengurangi jumlah proses yang harus dilakukan ketika terjadi kegagalan sistem tersebut. Kekurangan dari DBMS : Kompleksitas Fungsionalitas yang diharapkan dari DBMS membuat DBMS menjadi software yang sangat kompleks. Pengguna DBMS harus memahami dengan baik setiap fungsi dari DBMS untuk mendapatkan keuntungan maksimum dari DBMS tersebut. Ketidakpahaman atas sistem dapat menyebabkan pengambilan keputusan perancangan yang buruk akan dampak serius pada organisasi. mengakibatkan 13 Ukuran Kompleksitas dan fungsionalitas yang baik membuat DBMS menjadi sebuah software yang berukuran sangat besar dan membutuhkan disk space yang sangat besar serta jumlah memory yang besar agar dapat dijalankan seefisien mungkin. Harga DBMS Harga DBMS sangat bervariasi tergantung dari lingkungan dan fungsi yang disediakan termasuk biaya pemeliharaan. Biaya perangkat keras tambahan Kebutuhan disk storage untuk DBMS dan database menyebabkan kemungkinan untuk membeli storage tambahan. Selain itu, untuk mendapatkan perfoma yang diinginkan, dibutuhkan perangkat keras yang cepat dan baik tetapi mahal. Biaya konversi Pada beberapa situasi, biaya yang dibutuhkan untuk mengubah aplikasi agar dapat berjalan pada DBMS yang baru dapat jauh lebih mahal dari biaya perangkat keras tambahan. Biaya tersebut juga termasuk biaya pelatihan pegawai untuk menggunakan sistem yang baru, dan mungkin juga biaya pegawai spesialis untuk membantu konversi dan pelaksanaan sistem. Perfoma Biasanya file-based system ditulis untuk aplikasi khusus yang mengakibatkan perfoma secara umum sangat baik. Akan tetapi DBMS dibuat secara umum untuk dapat menjalankan berbagai aplikasi yang 14 mengakibatkan beberapa aplikasi berjalan lebih lambat dari yang seharusnya. Dampak yang besar akibat kegagalan Pemusatan sumber daya menambah kerawanan pada sistem. Karena semua pemakai dan aplikasi tergantung pada DBMS, kegagalan pada satu bagian dapat mengakibatkan sistem terhenti. 2.1.4 Database Language Data sublanguage terdiri dari dua bagian yaitu Data Definition Language (DDL) dan Data Manipulation Language (DML). DDL digunakan secara spesifik untuk skema database, dan DML digunakan untuk membaca dan memperbarui database. Bahasa ini disebut sebagai data sublanguage karena tidak memasukkan bentuk pengulangan dan kondisional yang disediakan oleh bahasa pemrograman tingkat tinggi. Banyak DBMS mempunyai fasilitas untuk memasukkan sublanguage ke dalam bahasa pemrograman tingkat tinggi seperti COBOL, Fortran, Pascal, C, C++, Java, Visual Basic, dll. 2.1.4.1 Data Definition Language (DDL) DDL adalah sebuah bahasa yang membolehkan DBA atau pemakai untuk menggambarkan dan menamai sebuah entity, attribute, dan relationship yang dibutuhkan oleh aplikasi, bersama dengan suatu associated integrity dan security constraint. Hasil dari kompilasi statement DDL adalah himpunan tabel yang tersimpan pada kumpulan file tertentu yang disebut sebagai system catalog. System catalog 15 berintegrasi dengan meta-data, di mana data tersebut menjelaskan obyek-obyek di dalam database dan mempermudah pengaksesan serta manipulasi objek. Meta-data berisi definisi dari record, data item, dan obyek-obyek lainnya yang dibutuhkan oleh DBMS. DBMS biasanya memeriksa system catalog sebelum data aktual diakses pada database. Data dictionary dan data directory biasanya digunakan untuk menggambarkan system catalog, meskipun data dictionary biasanya lebih banyak digunakan pada sistem perangkat lunak umum dibandingkan dengan DBMS. 2.1.4.2 Data Manipulation Language (DML) DML adalah sebuah bahasa yang menyediakan sejumlah operasi yang mendukung proses manipulasi data dasar yang ada pada database. Proses manipulasi data yang biasanya digunakan : • Memasukkan data baru ke dalam database. • Memodifikasi data yang tersimpan dalam database. • Mengambil data yang terdapat dalam database. • Menghapus data dari database. Oleh karena itu, salah satu fungsi utama DBMS adalah mendukung DML yang dapat digunakan oleh pemakai untuk membangun statement agar manipulasi data dapat terjadi. Manipulasi data berlangsung pada internal, conceptual, dan external level. Bagian dari DML yang melibatkan pengambilan data disebut query language. 16 DML dibedakan menurut cara pengambilan data, yaitu procedural dan nonprocedural. Perbedaan utama antara kedua DML bahwa procedural menjelaskan bagaimana cara mendapatkan hasilnya sedangkan non-procedural menjelaskan hasil apa yang akan didapatkan. 2.1.5 Database Application Lifecycle Sistem informasi adalah sumber yang dapat mengumpulkan, mengelola, mengatur, dan membagi segala informasi untuk organisasi. Menurut Connolly (2002, p270) sejak tahun 1970, sistem database telah menggantikan penggunaan file-based system sebagai bagian sistem informasi dari perusahaan. Oleh karena itu, banyak organisasi mendirikan bagian yang berfungsi khusus sebagai data administration (DB) dan database administration (DBA), yang bertanggung jawab untuk mengelola dan mengatur data perusahaan dan database perusahaan. Sistem informasi berbasis komputer terdiri dari sebuah database, piranti lunak database, piranti lunak aplikasi, perangkat keras komputer, dan pemakaian perseorangan dan perkembangan sistem. Komponen terpenting dari sistem informasi adalah database. Pemakaian dan perkembangan dari database harus memenuhi kebutuhan terbesar dari perusahaan. Sistem Basisdata adalah penerapan database ke dalam sistem informasi Tingkatan dari information systems lifecycle atau software development lifecycle (SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan, pembuatan prototype, implementasi, testing, konversi, dan operasi pemeliharaan. 17 Tingkatan dari database application lifecycle memiliki bentuk yang tidak kaku, tetapi mengikuti bentuk dari bentuk semula yaitu feed back 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, siklus hidup dapat menjadi sangat kompleks. 18 Database planning System definition Requirements collection and analysis Database design Conceptual database design DBMS selection Application design Logical database design Physical database design Implementation Prototyping Data conversion and loading Testing Operational maintenance Gambar 2.1 Database Application Lifecycle 19 Langkah-langkah dalam siklus hidup database aplikasi : • Database planning, adalah merencanakan bagaimana setiap langkah dapat dijalankan seefisien dan seefektif mungkin. • System definition, adalah menspesifikasi ruang lingkup dan batasan dari aplikasi database, pemakai, dan area aplikasi. • Requirement collection and analysis, adalah analisa dan pengumpulan kebutuhan-kebutuhan dari pemakai dan area aplikasi. • Database design, adalah perancangan conceptual, logical, dan physical dari database. • DBMS selection, adalah memilih DBMS yang cocok untuk aplikasi database. • Application design, adalah merancang antarmuka pemakai dan program apikasi yang menggunakan dan memproses database. • Prototyping, adalah membuat sebuah model kerja dari aplikasi database yang membolehkan perancang atau pemakai untuk memvisualisasikan dan mengevaluasi bagaimana sistem yang dibuat akan berjalan. • Implementation, adalah membuat definisi external, conceptual, dan internal database dan aplikasi program. • Data conversion and loading, adalah memasukkan data dari sistem lama ke sistem baru. • Testing, adalah aplikasi database akan diuji untuk mendapatkan kesalahan dan divalidasi dengan kebutuhan yang dispesifikasi pemakai. 20 • Operational maintenance, adalah aplikasi database telah diimplementasikan sepenuhnya. Sistem tersebut akan diawasi dan dirawat berkala. Ketika dibutuhkan, kebutuhan baru dapat ditambahkan ke dalam aplikasi database melalui langkah-langkah siklus hidup. 2.1.6 Normalisasi Normalisasi adalah sebuah teknik untuk menghasilkan sebuah relasi dengan properti yang diinginkan sesuai dengan kebutuhan data dari suatu perusahaan. Menurut Connolly (2002, p376) proses normalisasi pertama kali dikembangkan oleh E. F. Cood. Normalisasi seringkali dilakukan dengan cara menjalankan serangkaian tes pada relasi untuk menentukan apakah itu dapat memenuhi kebutuhan sesuai dengan bentuk normal. Proses normalisasi merupakan metoda yang mengidentifikasi relasi berdasarkan primary key atau candidate key dan ketergantungan fungsional di antara atribut-atributnya. Proses ini juga berguna untuk menghindari anomaly update. Anomaly update bisa terjadi karena adanya duplikasi data. Urutan proses dari normalisasi berdasarkan urutannya : • Unnormalized Form (UNF) Ini merupakan sebuah tabel yang masih memiliki satu atau lebih kumpulan data yang berulang. • First Normal Form (1NF) Pada tahap ini data yang berada dalam setiap kolom dan baris dibuat bernilai tunggal. Ini dilakukan dengan cara menghilangkan grup data yang 21 berulang dengan memasukkan data yang cocok pada kolom yang kosong dari baris yang memiliki data berulang tersebut. • Second Normal Form (2NF) Tahap ini berdasarkan pada konsep full functional dependency. Full functional dependency mengidentifikasi bahwa jika A dan B adalah atribut dari sebuah relasi, B memiliki full functional dependency terhadap A jika B memiliki ketergantungan fungsional terhadap A, tapi tidak pada subset dari A. Jadi definisi dari 2NF adalah relasi yang 1NF dan setiap atribut yang bukan primary key memiliki full functional dependency terhadap primary key. • Third Normal Form (3NF) Ini adalah relasi yang sudah dalam bentuk 1NF dan 2NF, dan dimana tidak ada atribut yang bukan primary key memiliki transitive dependency terhadap primary key. • Boyce-Codd Normal Form(BCNF) Suatu relasi dikatakan BCNF jika dan hanya jika, setiap determinan adalah candidate key. Untuk menentukan apakah suatu relasi adalah BCNF, kita menentukannya dengan mengidentifikasi semua determinan dan memastikan semua itu adalah candidate key. • Fourth Normal Form(4NF) Sebuah relasi dikatakan 4NF saat relasi tersebut dalam BCNF dan tidak lagi memiliki non-trivial Multi Valued Dependencies(MVD). MVD sendiri 22 adalah dependensi antara atribut-atribut dalam relasi meskipun relasi tersebut telah BCNF sehingga menyebabkan redundansi data. • Fifth Normal Form(5NF) 5NF atau juga disebut Project-Join Normal Form(PJNF) adalah sebuah relasi yang tidak lagi memiliki join dependency. 2.1.7 Perancangan Database Metodologi desain adalah pendekatan terstruktur yang menggunakan prosedur, teknik, tool, dan bantuan dokumentasi untuk mendukung dan memfasilitasi proses perancangan. Metodologi desain terdiri dari beberapa fase berisi langkah-langkah yang membantu perancang menentukan teknik yang cocok untuk digunakan pada setiap langkah, serta membantu perancang untuk merencanakan, mengelola, mengontrol, dan mengevaluasi proyek pengembangan database. Perancangan database terbagi menjadi perancangan konseptual, perancangan logikal, dan perancangan fisikal. 2.1.7.1 Perancangan Konseptual Perancangan konseptual adalah proses membangun model informasi yang digunakan oleh perusahaan, dan terlepas dari segala pertimbangan fisik seperti program aplikasi, bahasa pemrograman yang digunakan, platform perangkat keras, dll. Tahap-tahap perancangan konseptual : 23 o Membangun model data konseptual lokal untuk setiap view Bertujuan untuk membangun model data konseptual lokal dari perusahaan untuk setiap view tertentu. Selama analisa, sejumlah view pemakai mungkin telah diidentifikasi dan tergantung dari jumlah bagian yang saling overlap di antara view tersebut, beberapa view pemakai mungkin harus digabungkan untuk membentuk collective view. Tugas-tugas yang termasuk dalam langkah ini adalah : • Mengidentifikasi entity type Tahap ini bertujuan untuk mengidentifikasi entity type utama dari view. Salah satu metode yang digunakan untuk mengidentifikasi entity adalah dengan memeriksa spesifikasi kebutuhan pemakai. Dari spesifikasi ini, perancang mengidentifikasi kata benda atau frase benda seperti nomor staff, nama staff. Metode alternatif untuk mengidentifikasi entity adalah dengan mencari obyek yang keberadaannya tidak bergantung pada obyek lain. Sebagai contoh staff adalah entity meskipun nama, tanggal lahir, dan posisi mereka tidak diketahui. • Mengidentifikasi relationship type Tahap ini bertujuan untuk mengidentifikasi relationship penting yang terdapat di antara entity type yang telah diidentifikasi. Salah satu metode yang digunakan adalah dengan menggunakan spesifikasi kebutuhan pemakai di mana biasanya relationship diindikasikan dengan kata benda atau ekspresi verbal. 24 • Mengidentifikasi dan menghubungkan atribut dengan entity atau relationship type Tahap ini bertujuan untuk menghubungkan atribut dengan entity atau relationship type yang sesuai. • Menentukan domain atribut Tahap ini bertujuan untuk menentukan domain untuk setiap atribut pada model data konseptual lokal. Domain atribut adalah himpunan dari nilai yang diizinkan untuk satu atau lebih atribut. • Menentukan atribut candidate dan primary key Tahap ini bertujuan untuk mengidentifikasi candidate key untuk setiap entity type dan jika terdapat lebih dari satu candidate key maka dipilih satu untuk menjadi primary key. • Mempertimbangkan penggunaan enhanced modeling concept Tahap ini bertujuan untuk mempertimbangkan penggunaan enhanced modeling concept seperti specialization/generalization, aggregation, dan composition. • Mengecek model dari redundancy Tahap ini bertujuan untuk mengecek redundancy yang mungkin terdapat pada model untuk kemudian dihilangkan dari model tersebut. • Memvalidasi model konseptual lokal terhadap transaksi pemakai Tahap ini bertujuan untuk memastikan bahwa model konseptual lokal mendukung transaksi yang dibutuhkan oleh view. 25 • Meninjau ulang model konseptual lokal bersama dengan pemakai Untuk meninjau model data konseptual lokal bersama dengan pemakai untuk memastikan bahwa model tersebut sungguhsungguh merupakan representasi dari view. 2.1.7.2 Perancangan logikal Perancangan logikal adalah proses membangun model informasi yang digunakan perusahaan berdasarkan pada model data khusus, tetapi terlepas dari DBMS dan pertimbangan fisik tertentu. Tahap-tahap perancangan logikal : o Membuat dan memvalidasi model data logikal lokal untuk setiap view Tahap ini bertujuan untuk membangun model data logikal lokal dari model data konseptual yang menggambarkan view tertentu dari perusahaan dan kemudian divalidasi untuk memastikan model tersebut mendukung transaksi yang diperlukan. Langkah-langkah pada tahap ini adalah : • Menghilangkan fitur yang tidak sesuai dengan relational model (optional) Langkah ini bertujuan untuk memperbaiki model data konseptual lokal dengan menghilangkan fitur yang tidak sesuai dengan relational model. Akan tetapi, model data mungkin berisi beberapa struktur yang tidak dapat dimodelkan dengan mudah oleh DBMS konvensional, sehingga pada tahap ini struktur 26 tersebut diubah menjadi bentuk yang lebih mudah dikelola oleh sistem. Secara lengkap tahap ini bertujuan untuk : - menghilangkan many-to-many (*:*) binary relationship type - menghilangkan many-to-many (*:*) recursive relationship type - menghilangkan complex relationship type - menghilangkan atribut multi-valued • Membuat relasi untuk model data logikal lokal Langkah ini bertujuan membuat relasi model data logikal lokal untuk menggambarkan entity, relationship, dan atribut yang telah diidentifikasi. Komposisi dari setiap relasi digambarkan dengan Database Definition Language (DBDL) untuk setiap relasi database lalu primary key dan alternate/foreign key dari relasi diidentifikasikan. Perancang harus menggambarkan bagaimana struktur-struktur dibawah ini dipresentasikan pada model data. - Strong entity type - Weak entity type - One-to-many (1:*) binary relationship type - One-to-one (1:1) binary relationship type a. mandatory participation pada kedua sisi b. mandatory participation pada salah satu sisi c. optional participation pada kedua sisi - One-to-one (1:1) recursive relationship 27 - Superclass/subclass relationship type - Many-to-many (*:*) binary relationship type - Complex relationship type - Atribut multi-valued • Memvalidasi relasi menggunakan normalisasi Langkah ini bertujuan untuk memvalidasi relasi pada model data logikal lokal menggunakan teknik normalisasi. • Memvalidasi relasi terhadap transaksi pemakai Langkah ini bertujuan untuk memastikan bahwa relasi pada model data logikal lokal mendukung transaksi yang dibutuhkan oleh view • Mendefinisikan integrity constraint Langkah ini bertujuan untuk mendefinisikan integrity constraint yang diberikan oleh view. Integrity constraint adalah constraint yang harus diperhatikan untuk menjaga database agar tetap konsisten. Ada lima jenis integrity constraint : - Data yang dibutuhkan - Attribute domain constraint - Entity integrity - Referential integrity - Enterprise constraint 28 • Meninjau ulang model data logikal lokal bersama dengan pemakai Langkah ini bertujuan untuk memastikan bahwa model data logikal lokal dan dokumen pendukung yang menggambarkan model tersebut sungguh-sungguh merupakan gambaran sebenarnya dari view. o Membuat dan memvalidasi model data logikal global Jika aplikasi database hanya memiliki satu view, maka perancangan dapat langsung dilanjutkan ke tahap perancangan fisikal. Akan tetapi, jika aplikasi database memiliki lebih dari satu view maka langkah selanjutnya adalah membangun dan memvalidasi model data logikal global. Langkah-langkah pada tahap ini adalah : • Menggabungkan model data logikal lokal menjadi model global Langkah ini bertujuan untuk menggabungkan model data logikal lokal menjadi sebuah model data logikal global dari sebuah perusahaan. Pendekatan yang digunakan pada langkah ini mengacu pada karya tulis oleh Batini dan Lanzerini (1986), Biskup dan Convent (1986), Spaccapietra et al. (1992), dan Bouguettaya et al.(1998), dengan tahap-tahap : - Meninjau ulang nama dan isi dari entiti/relasi dan candidate key masing-masing. - Meninjau ulang nama dan isi dari relationship/foreign key. - Menggabungkan entiti/relasi dari model data lokal. 29 - Memasukkan (tanpa menggabungkan) entity/relasi yang unik ke setiap model data lokal. - Menggabungkan relationship/foreign key dari model data lokal. - Memasukkan (tanpa menggabungkan) relationship/foreign key yang unik ke setiap model data lokal. - Mengecek apakah ada entity/relasi dan relationship/foreign key yang hilang. - Mengecek foreign key. - Mengecek integrity constraint. - Menggambar diagram ER/relasi. - Meng-update dokumentasi. • Memvalidasi model data logikal global Langkah ini bertujuan untuk memvalidasi relasi yang dibuat dari model data logikal global menggunakan teknik normalisasi dan untuk memastikan relasi tersebut mendukung transaksi yang dibutuhkan. • Mengecek perkembangan di masa depan Langkah ini bertujuan untuk menentukan apakah terdapat perubahan penting yang akan terjadi di masa depan dan untuk memastikan bahwa model data mengakomodasi perubahan tersebut. logikal global dapat 30 • Meninjau ulang model data logikal global bersama dengan pemakai Langkah ini bertujuan untuk memastikan bahwa model data logikal global merupakan gambaran sebenarnya dari perusahaan. 2.1.7.3 Perancangan Fisikal Perancangan fisikal database adalah proses pembuatan deskripsi dari implementasi database ke dalam media penyimpanan, dimana deskripsi itu menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mendapatkan akses yang efisien terhadap data dan integrity constraint, dan tingkat keamanan. Langkah dari perancangan fisikal database adalah : o Menterjemahkan model data logikal global ke dalam DBMS yang dipilih Tujuan utama dari langkah ini adalah membuat skema relational database dari model data logikal global yang dapat diimplementasikan pada DBMS yang dipilih. Bagian pertama dari proses ini adalah mengumpulkan informasi yang di dapat selama perancangan logikal database dan dokumentasi kamus data. Dan bagian kedua dari proses ini adalah menggunakan informasi tadi untuk membuat rancangan dari relasi dasar. Proses ini memerlukan pengetahuan yang dalam mengenai fungsionalitas yang ditawarkan oleh DBMS yang akan digunakan. 31 • Merancang relasi dasar Tujuan utama dari bagian ini adalah memutuskan bagaimana merepresentasikan relasi dasar yang telah diidentifikasi pada model data logikal global pada DBMS. Yang dilakukan pertama kali adalah mengumpulkan dan memahami informasi mengenai relasi yang telah dihasilkan dari perancangan database logikal. Informasi yang diperlukan dapat diperoleh dari kamus data dan definisi dari relasi yang digambarkan menggunakan Database Design Language (DBDL). • Merancang representasi dari derived data Tujuan utama dari bagian ini adalah memutuskan bagaimana merepresentasikan semua derived data yang terdapat pada model data logikal global pada DBMS. Derived data adalah atribut yang nilainya didapat dari memeriksa nilai dari atribut-atribut lain. Contohnya adalah jumlah gaji bulanan adari seluruh pekerja. Terkadang atribut derived tidak muncul dalam model data logikal, tetapi ada dalam kamus data. • Merancang enterprise constraint Tujuan utama langkah ini adalah merancang enterprise constraint bagi DM Tujuan utama dari bagian ini adalah memutuskan bagaimana merepresentasikan relasi dasar yang telah di identifikasi pada model data logikal global pada DBMS yang akan digunakan. Pengubahan terhadap relasi sangat tergantung pada 32 peraturan-peraturan organisasi menurut transaksi yang terjadi yang akan dijelaskan oleh pengubahan itu. Pembuatan enterprise constraint tergantung terhadap DBMS yang dipilih, beberapa sistem menyediakan fasilitas yang lebih daripada yang lain untuk menjelaskan enterprise constraint. o Merancang Representasi fisikal Pada langkah ini ditentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mendapatkan performa yang dapat diterima. Ada beberapa faktor untuk menghitung tingkat efisiensi dari database yaitu : Transaction throughput. Ini adalah jumlah dari transaksi yang dapat diproses dalam jangka waktu tertentu. Response time. Ini adalah waktu yang dibutuhkan untuk menyelesaikan sebuah transaksi. Disk storage. Ini adalah jumlah dari kapasitas disk yang dibutuhkan untuk menyimpan database. Langkah-langkah pada tahap ini adalah : • Menganalisa transaksi Pada saat ini, diperlukan untuk mengerti fungsi dari transaksi yang akan dijalankan oleh database dan untuk menganalisa transaksi-transaksi yang penting. Untuk menghasilkan perancangan database fisikal yang efektif, penting untuk 33 mengetahui transaksi atau query yang akan dijalankan pada database. Ini termasuk kualitatif dan kuantitatif dari informasi. Pada penganalisaan transaksi, dicoba untuk mengidentifikasi beberapa kriteria seperti transaksi yang berjalan secara berulangulang dan memiliki dampak yang berarti, transaksi yang penting bagi operasi bisnis dan sebagainya. Informasi ini digunakan untuk menentukan bagian dari database yang mungkin menyebabkan masalah bagi perfoma. • Memilih organisasi file Tahapan ini digunakan untuk menentukan organisasi file yang efisien bagi tiap relasi dasar. • Memilih indeks Pada bagian ini ditentukan apakah dengan menambah indeks akan meningkatkan perfoma dari sistem. • Memperkirakan kebutuhan kapasitas disk Pada tahap ini diperkirakan jumlah dari kapasitas disk yang dibutuhkan oleh database yang dibuat. o Merancang view pemakai Pada tahapan ini, tujuan utama adalah merancang view pengguna yang telah didapat selama pengumpulan kebutuhan dan tahap analisa dari daur hidup aplikasi database relasional. 34 o Merancang mekanisme keamanan Di bagian ini, dirancang tingkat keamanan dari database yang telah ditentukan oleh pengguna. Hal ini diperlukan, karena database mempresentasikan data perusahaan yang penting sehingga keamanannya menjadi sangat penting. Secara umum DBMS menyediakan dua tipe keamanan, yaitu keamanan sistem dan keamanan data. Keamanan sistem meliputi akses dan penggunaan dari database pada tingkat sistem seperti nama pemakai dan password. Keamanan data meliputi akses dan penggunaan dari obyek database (seperti relasi dan view) dan aksi yang dilakukan pemakai terhadap obyek. o Mempertimbangkan pengontrolan redundancy Tahap ini bertujuan untuk menentukan apakah penggunaan redundancy pada lingkungan terkontrol dengan mengurangi normalisasi dapat meningkatkan perfoma dari sistem. o Memonitor dan mengatur sistem operasional Tahap ini bertujuan untuk mengawasi sistem operasional dan perfoma dari sistem untuk memperbaiki keputusan desain yang kurang tepat atau penggambaran perubahan kebutuhan. 35 2.2 Teori-teori Khusus yang Berhubungan dengan Topik yang Dibahas 2.2.1 UML 2.2.1.1 Use Case Sebuah bagian penting dari Unified modelling language (UML) adalah fasilitas yang memungkinkan kita untuk menggambar sebuah diagram, yaitu diagram use-case. Use case digunakan selama tahap analisis dalam sebuah proyek untuk mengidentifikasikan dan membagi fungsi dari sistem. Diagram ini membagi-bagi sistem menjadi actor dan use cases. Actors mewakili peran-peran yang dapat dikerjakan oleh user di dalam sistem. User-user ini dapat berupa manusia, bagian hardware komputer atau bahkan software sistem yang lain. Salah satu kriteria adalah mereka harus berada di luar bagian dari use case sebuah sistem. Mereka harus menyediakan masukan (inputan) ke dalam system dan mereka akan mendapatkan keluaran (output) dari sistem tersebut. Use case menjelaskan tentang cara kerja dari sistem setelah mendapat inputan dari actor. Cara kerja ini dijelaskan secara rinci. Use case menjelaskan tentang hal-hal seperti, masukan dari seorang actor dan bagaimana keluaran yang diterima oleh actor lain, dan cara kerja yang dapat merubah suatu masukan menjadi keluaran. Use case merupakan suatu diagram yang sangat berguna bagi pihak analis saat mengelompokkan fungsi-fungsi dari sistem. Hubungan-hubungan antara cases dan diagram-diagram yang berhubungan dapat membantu pihak analis untuk membuat struktur dari sebuah sistem. Tetapi use cases bukanlah sebuah alat desain, mereka tidak digunakan untuk memspesifikasikan sebuah software 36 atau mereka tidak melibatkan sebuah keberadaan kelas-kelas dan obyek-obyek. Use case merupakan sebuah deskripsi tentang sebuah sistem yang secara murni terpisah dari tahap desain sebuah software. Gambar 2.2 Use Case Diagram 2.2.1.2 Sequence diagram Sequence diagram berisi informasi yang sama dengan collaboration diagram, tetapi menekankan pada alur sekuensial sebuah pesan daripada hubungan antara obyek-obyek. UML sequence diagram menggambarkan alur dari logika di dalam sistem secara visual, sehingga memungkinkan kita untuk menyimpan dan mengvalidasi logika kita. Sequence diagram juga digunakan secara umum untuk keperluan analisis dan desain. 37 Gambar 2.3 Sequence Diagram 2.2.1.3 Class diagram UML class diagrams adalah sebuah alat analisis dan desain yang beorientasi obyek. Class diagrams memperlihatkan kelas-kelas yang ada pada sistem, hubungan-hubungan yang ada (termasuk inheritance, aggregation, dan association), dan operasi-operasi serta atribut-atribut dari kelas. Class diagrams digunakan untuk sebuah variasi tujuan yang luas, termasuk kedua modeling conceptual atau domain dan desain model secara detil. Model class di dalam UML adalah sebuah artifak utama yang diciptakan untuk menggambarkan struktur logika dari sebuah sistem pada software. Model class mengambil data-data dan cara kerja dari obyek-obyek di dalam domain model. Class adalah sebuah entity logika dasar pada UML. Class model menjelaskan data dan cara kerja dari sebuah unit yang terstruktur. Class adalah 38 sebuah template atau model yang merupakan dasar terciptanya obyek-obyek selama run-time. Ketika kita mengembangkan sebuah model logical seperti struktur hirarki di dalam UML, kita secara langsung berhubungan dengan class. Gambar 2.4 Class Diagram 2.2.2 ERD Entity Relationship modelling banyak digunakan untuk menampilkan model konseptual khususnya berhubungan dengan desain database. Entity dan relationship diwakilkan dalam bentuk diagram, di ER diagram: - Kotak mewakili type entity. - Diamond dan hubungan garis mewakilkan type dari relationship yang ada diantara mereka. 39 - Nomor yang ada di persegi yang berada pada akhir garis relationship menunjukkan nomor minimum atau maksimum dari entity yang bisa digunakan. Di sebut cardinality relationship. Untuk menentukan cardinality dari relationship diperlukan beberapa petunjuk. Jika entity X dan Y berhubungan maka kita harus menganggap X dihubungkan dengan Y dan Y dihubungkan dengan X. Berikut type relationship yang diidentifikasikan: • one-to-one (1:1) Relationship Staff Manages Branch Multiplicity dari relationship Staff Manages Branch (1:1) • one-to-many (1 : *) Relationship dari Staff Oversees PropertyForRent 40 Multiplicity dari relationship Staff Oversees PropertyForRent • many-to-many (* : *) Relationship Newspaper Advertises PropertyForRent Multiplicity dari relationship Newspaper Advertises PropertyForRent (*:*)