BAB 2 LANDASAN TEORI

Transkripsi

1 6 BAB 2 LANDASAN TEORI 2.1 Data dan Informasi Pengertian Data dan Informasi Menurut Elmasri dan Navathe (1994, p2), data merupakan fakta-fakta yang telah diketahui untuk dapat disimpan dan yang mempunyai arti yang mutlak atau selengkapnya. Pengertian data, informasi, dan sistem informasi menurut Turban E. et al (2003, p15), data adalah fakta-fakta yang belum diolah atau gambaran-gambaran lebih lanjut dari benda-benda, kejadian-kejadian, kegiatan-kegiatan, dan transaksi-transaksi yang ditangkap, direkam, disimpan dan diklasifikasikan, tetapi tidak disusun untuk menyampaikan arti khusus lainnya. Informasi adalah sebuah kumpulan dari fakta-fakta (data) yang disusun di dalam beberapa cara, jadi kumpulan fakta tersebut bisa berarti bagi penerimanya. Sistem Informasi adalah sebuah sistem yang mengumpulkan, mengolah, menyimpan, menganalisa, dan menyebarkan informasi untuk sebuah tujuan tertentu Karakteristik Informasi Dalam lingkup suatu sistem informasi, informasi mempunyai beberapa karakteristik. Menurut Romney dan Steinbart (2000, p13), karakteristik informasi yang berguna adalah sebagai berikut:

2 7 1. Relevan Informasi dikatakan relevan apabila informasi itu mengurangi ketidakpastian, meningkatkan kemampuan pembuat keputusan untuk membuat prediksi, atau konfirmasi, atau membenarkan dugaan mereka sebelumnya. 2. Dapat dipercaya Informasi dapat dipercaya jika informasi tersebut bebas dari kesalahan dan secara akurat mewakili events atau aktivitas dari organisasi. 3. Lengkap Informasi yang lengkap yaitu informasi yang tidak mengurangi aspek penting dari event atau aktivitas yang mendasari pengukuran informasi tersebut. 4. Tepat waktu Informasi dikatakan tepat waktu apabila informasi itu tersedia tepat waktu sehingga memungkinkan pembuat keputusan untuk membuat keputusan. 5. Dapat dimengerti Informasi dapat dimengerti jika informasi tersebut dipresentasikan dalam format yang benar dan mudah dipahami. 6. Dapat diuji Informasi dapat diuji jika ada dua orang yang mempunyai pengalaman bekerja secara terpisah, tapi masing masing menghasilkan informasi yang sama.

3 8 2.2 Basis Data Menurut Connolly dan Begg (2002, p14), basis data merupakan kumpulan hubungan yang masuk akal dari data atau deskripsi data yang dapat digunakan bersama dan dibuat untuk memperoleh informasi yang dibutuhkan oleh perusahaan. Secara logika, hubungan antar data terdiri dari entitas-entitas, atribut, dan relationship dari informasi organisasi atau perusahaan. Pengertian basis data menurut Date (1990, p10), adalah suatu koleksi atau kumpulan data yang persisten digunakan oleh sistem aplikasi dari suatu perusahaan. Yang dimaksud dengan persisten adalah data yang berbeda satu dengan yang lainnya dan biasanya merupakan data yang bersifat sementara. Sedangkan pengertian basis data menurut Jogiyanto (1990, p13), basis data merupakan kumpulan dari data yang saling berhubungan satu dengan yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk memanipulasinya. Dalam praktek, penggunaan istilah basis data menurut Elmasri dan Navathe (1994, p2), lebih dibatasi pada arti implisit yang khusus, yaitu: 1. Basis data merupakan penyajian suatu aspek dari dunia nyata. 2. Basis data merupakan kumpulan data dari berbagai sumber yang secara logika mempunyai arti implisit. Sehingga data yang terkumpul secara acak dan tanpa mempunyai arti, tidak dapat disebut basis data. 3. Basis data perlu dirancang, dibangun, dan data dikumpulkan untuk suatu tujuan. Basis data dapat digunakan oleh beberapa pemakai dan beberapa aplikasi yang sesuai dengan kepentingan pemakai.

4 9 Dari batasan tersebut, dapat dikatakan bahwa basis data mempunyai berbagai sumber data dalam pengumpulan data bervariasi derajat interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan oleh beberapa pemakai untuk berbagai kepentingan. Menurut Connolly dan Begg (2002, p16), DBMS (Database Management System) adalah sistem software yang memungkinkan atau mengijinkan pengguna untuk mendefinisikan, membuat, memelihara basis data, dan menyediakan akses kontrol kepada basis data. Sedangkan menurut Elmasri dan Navathe (1994, p2), sebuah DBMS merupakan sebuah kumpulan dari program-program yang memungkinkan atau mengijinkan pengguna untuk menciptakan dan memelihara sebuah basis data. Oleh sebab itu, suatu DBMS adalah sebuah sistem generalpurpose software (software bertujuan umum) yang memudahkan proses-proses penentuan, pembangunan, dan pelaksanaan manipulasi data pada banyak basis data untuk berbagai macam aplikasi. Menurut Connolly dan Begg (2002, p18), komponen-komponen dari DBMS: 1. Data Data pada sebuah sistem basis data baik itu sistem single-user maupun sistem multi-user harus terintegrasi (terhubung) dan dapat digunakan bersama. 2. Hardware Terdiri dari:

5 10 a. Penyimpanan permanen (magnetic disk atau hard disk), perangkat I/O (contohnya : disk drives), Device Controller, I/O Channels, dan lainnya. b. Hardware processor dan main memory, digunakan untuk mendukung saat eksekusi sistem software basis data. 3. Software DBMS, sistem operasi (seperti Microsoft Windows atau Linux), network software (jika diperlukan) dan program aplikasi pendukung lainnya. 4. Users a. Application Programmers, bertanggung jawab untuk membuat aplikasi basis data dengan menggunakan bahasa pemrograman yang ada, seperti: C++, Java, dan lainnya. b. End Users, siapapun yang berinteraksi dengan sistem secara online melalui workstation atau terminal. c. DA (Data Administrator), seseorang yang berwenang untuk membuat keputusan stategis dan kebijakan mengenai data yang ada, DBA (Database Administrator), menyediakan dukungan teknis untuk implementasi keputusan tersebut, dan bertanggungjawab atas keseluruhan kontrol sistem pada tingkatan teknis. Keuntungan DBMS menurut Connolly dan Begg (2002, p25): 1. Penggunaan data bersama (sharing of data) 2. Mengurangi kerangkapan data

6 11 3. Menghindari ketidakkonsistenan data 4. Integritas data terpelihara 5. Keamanan terjamin 6. Penyimpanan data dalam jumlah yang besar 7. Penetapan standarisasi 8. Meningkatkan produktivitas 9. Layanan Back up dan Recovery semakin baik Kerugian DBMS menurut Connolly dan Begg (2002, p29): 1. Rumit Karena penetapan fungsi dari DBMS yang baik, menyebabkan DBMS menjadi software yang cukup rumit. Seluruh user harus mengetahui fungsifungsi yang ada dengan baik, sehingga dapat memperoleh manfaatnya. 2. Ukuran Kerumitan dan banyaknya fungsi yang ada menyebabkan DBMS memerlukan banyak software pendukung yang mengakibatkan penambahan tempat penyimpanan dan memori. 3. Biaya DBMS 4. Biaya tambahan hardware 5. Biaya konversi

7 12 6. Penampilan (performance) Pada dasarnya DBMS dibuat untuk menyediakan banyak aplikasi, akibatnya mungkin beberapa aplikasi akan berjalan tidak seperti biasanya. 7. Dampak yang tinggi dari kegagalan Karena sistem yang terpusat, jika seluruh pengguna dan aplikasi terakses dari DBMS maka kerusakan pada bagian manapun dari sistem, akan menyebabkan operasi terhenti. 2.3 Perkembangan Basis Data Pada awalnya, perusahaan-perusahaan yang ada masih menggunakan sistem operasional secara manual, yaitu semua proses penyimpanan barang, transaksi-transaksi pembelian, penjualan, dan lain-lain masih dicatat secara langsung dan untuk data penyimpanan barang masih ditempatkan pada sistem pembukuan saja. Namun pada saat sekarang ini, semua proses-proses tersebut sudah dilakukan menggunakan sistem komputerisasi, seperti sistem basis data untuk menyimpan data-data, aplikasi-aplikasi yang dibuat dan terhubung dengan basis data untuk melakukan transaksi-transkasi yang dilakukan suatu perusahaan, dan lain sebagainya. Basis data pada saat sekarang ini sudah merupakan suatu bagian penting bagi perusahaan untuk memenuhi kebutuhan penyimpanan data. Basis data juga sudah mengalami beberapa perkembangan yang sangat penting dengan menggunakan aplikasi-aplikasi yang dibuat dari masing-masing perusahaan. Aplikasi basis data adalah program sederhana yang berinteraksi dengan basis

8 13 data pada nilai tertentu dalam eksekusinya. Kita juga menggunakan istilah sistem basis data untuk memasukkan koleksi dari program-program aplikasi yang berinteraksi dengan basis data. 2.4 Entity-Relationship Menurut Connolly dan Begg (2002, p330), salah satu bagian yang sulit dalam perancangan basis data adalah suatu fakta bahwa para perancang, pembuat-pembuat program, dan end-user cenderung untuk melihat data dan menggunakannya dengan cara-cara yang berbeda. Kecuali kalau kita memperleh sebuah pemahaman sama yang mencerminkan bagaimana suatu perusahaan beroperasi, suatu perancangan yang kita hasilkan akan gagal untuk memenuhi kebutuhan-kebutuhan user. Untuk meyakinkan bahwa kita mendapat sebuah pemahaman yang tepat dari suatu data dan bagaimana data tersebut digunakan oleh suatu perusahaan, kita harus mempunyai sebuah model untuk membuat komunikasi yang non teknikal dan tidak bersifat ambigu. Entity-Relationship (ER) adalah salah satu contohnya. Pemodelan ER adalah sebuah pendekatan top-down untuk perancangan basis data yang dimulai dengan mengidentifikasi suatu data penting yang disebut entitas-entitas dan relationships diantara suatu data yang harus direpresentasikan dalam suatu model. Lalu kita menambah perincian-perincian lagi seperti suatu informasi yang ingin kita ambil tentang suatu entitas-entitas dan relationships yang disebut atribut-atribut dan batasan-batasan yang lain pada suatu entitasentitas, relationships, dan atribut-atribut.

9 14 Berikut ini adalah notasi Entity-Relationship Modelling menurut Connolly dan Begg (2002, p ): Entity Name A Relate to B Relationship Name Gambar 2.1 Notasi Entity-Relationship Modelling Pengertian Multiplicity menurut Connolly dan Begg (2002, p350) adalah sejumlah kemungkinan kejadian-kejadian dari sebuah tipe entitas di dalam sebuah hubungan n-nary ketika nilai-nilai yang lain (n-1) ditentukan. Multiplicity biasanya terdiri dari dua batasan terpisah, yaitu: a. Cardinality: Mendeskripsikan jumlah maksimum dari kemungkinan kejadian-kejadian yang saling berhubungan untuk sebuah partisipasi entitas dalam proses penentuan tipe relationship. b. Participation: Menentukan apakah semua kejadian-kejadian entitas akan ikut berpartisipasi dalam sebuah relationship atau hanya beberapa saja yang ikut berpartisipasi.

10 15 Jenis-jenis multiplicity menurut Connolly dan Begg (2002, p345) adalah: 1. One-to-One (1 : 1) Relationships Group 1 Relate to Group 2 A B r1 r2 C D Gambar 2.2 One-to-One Relationships Pada gambar 2.2, kita bisa melihat bahwa A hanya terhubung One-to-One (1 : 1) dengan C, dan B hanya terhubung One-to-One (1 : 1) dengan D. Jadi dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to Group 1 Group Multiplicity Gambar 2.3 Notasi One-to-One Relationships

11 16 2. One-to-Many (1 : *) Relationships Group 1 Relate to Group 2 A B C r1 r2 r3 D E F Gambar 2.4 One-to-Many Relationships Pada gambar 2.4, kita bisa melihat bahwa B terhubung One-to-Many (1 : *) dengan D dan E. Jadi dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to Group 1 Group * Multiplicity Gambar 2.5 Notasi One-to-Many Relationships

12 17 3. Many-to-Many (* : *)Relationships Group 1 Relate to Group 2 A B C r1 r2 r3 r4 D E F G Gambar 2.6 Many-to-Many Relationships Pada gambar 2.6, kita bisa melihat bahwa A terhubung One-to-Many (1 : *) dengan D dan E. Sedangkan E terhubung One-to-Many (1 : *) dengan A dan B. Jadi dari entitas Group 1 (value-nya A dari gambar di atas) dan Group 2 (value-nya E dari gambar di atas) terhubung Many-to-Many (* : *). Dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to Group 1 Group 2 0..* 1..* Multiplicity Gambar 2.7 Notasi Many-to-Many Relationships

13 Daur Hidup Database (Database Lifecycle) Menurut Connolly dan Begg (2002, p271), sistem basis data adalah komponen penting dari suatu sistem informasi sebuah perusahaan atau organisasi yang besar. Aplikasi daur hidup basis data adalah pengumpulan pewarisan dengan daur hidup dari sistem informasi. Sebagai contoh, masalah yang dihadapi selama perancangan basis data mengharuskan penambahan koleksi dan analisis kebutuhan. Untuk aplikasi basis data yang kecil, dengan jumlah pengguna yang sedikit, tidak dibutuhkan daur hidup yang kompleks. Bagaimanapun, saat merancang aplikasi basis data menengah sampai yang besar dengan sepuluh sampai seribu pengguna, menggunakan ratusan dari query dan aplikasi program, daur hidup dapat menjadi kompleks sekali. Berikut ini adalah gambar tahapan-tahapan aplikasi daur hidup basis data menurut Connolly dan Begg (2002, p272):

14 19 Database planning System definition Requirements collection and analysis DBMS selection (optional) Database design Conceptual database design Logical database design Application design Physical database design Prototyping (optional) Implementation Data conversion and loading Testing Operational maintenance Gambar 2.8 Tahapan Aplikasi Daur Hidup Basis Data

15 20 Menurut Connolly dan Begg (2002, p273), berikut ini adalah tahapantahapan dari aplikasi daur hidup basis data beserta aktivitas-aktivitas utama yang dilakukan oleh setiap tahapnya: Database Planning Merencanakan bagaimana tahapan-tahapan daur hidup basis data dapat direalisasikan dengan efisien dan efektif. Tahap perencanaan basis data juga harus menjelaskan : Mission statement dari proyek basis data. Mission statement ini menjelaskan tujuan utama aplikasi basis data, juga membantu menjelaskan tujuan proyek basis data, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly, 2002, p274). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basis data ini diharapkan dapat lebih memfokuskan pekerjaan pada tahap selanjutnya. Mission objectives. Selain merumuskan tujuan dari sebuah proyek basis data, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basis data tersebut. Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basis data, dengan asumsi jika basis data mendukung mission objectives, maka mission statementnya juga akan sesuai (Connolly, 2002, p274).

16 System Definition Menspesifikasikan jangkauan dan batasan-batasan dari aplikasi basis data, pengguna basis data, dan area-area aplikasi. Pandangan pengguna (user view) sangat diperlukan untuk mengidentifikasi informasi-informasi yang dibutuhkan oleh user. Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan dan transaksi yang akan dijalankan terhadap data itu (Connolly, 2002, p275) Requirements Collection and Analysis Mengkoleksi dan menganalisis kebutuhan pengguna dan area-area aplikasi. Dalam menganalisi kebutuhan digunakan teknik yang disebut fact finding techniques. Terdapat lima teknik fact finding yang umum digunakan (Connolly, 2002, p305) : 1. Mengevaluasi dokumen 2. Interview 3. Mengobservasi jalannya kegiatan kerja pada perusahaan 4. Research riil 5. Quesioner

17 Database Design Menurut Connolly dan Begg (2002, p279), Database design (perancangan basis data) adalah proses pembuatan sebuah perancangan untuk suatu basis data yang akan mendukung operasi dan tujuan suatu perusahaan. Proses perancangan basis data menurut Connolly dan Begg (2002, p419), terdiri dari tiga tahap utama, yang pertama yaitu, perancangan konseptual basis data adalah proses untuk membuat sebuah model informasi yang digunakan dalam suatu perusahaan, serta bebas dari semua pertimbangan fisik. Yang kedua yaitu, perancangan logikal basis data adalah proses untuk membuat sebuah model informasi yang digunakan dalam suatu perusahaan, berdasarkan suatu data model spesifik, namun bebas dari DBMS tertentu dan pertimbangan fisik lainnya. Dan yang ketiga yaitu, perancangan fisikal basis data adalah proses untuk menghasilkan sebuah gambaran dari pengimplementasian basis data pada secondary storage, menggambarkan hubungan dasarnya, pengaturan file, pengindeksan yang digunakan untuk memenuhi akses data yang efisien, batasan integritas terkait lainnya, dan pengukuran keamanan. Berikut ini merupakan langkah-langkah metodologi dari perancangan basis data, menurut Connolly dan Begg (2002, p420): Perancangan Konseptual Basis Data Merupakan proses membangun model informasi yang digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly, 2002, p419). Pertimbangan fisik yang dimaksud meliputi DBMS yang akan digunakan, program aplikasi, bahasa pemrograman, platform

18 23 perangkat keras, unjuk kerja, dan pertimbangan fisik lainnya. Fungsi dari tahap ini adalah untuk membuat representasi konseptual dari basis data, termasuk identifikasi entity-entity yang penting, relationship, atribut Membuat Model Data Konseptual Lokal untuk Setiap Bagian Tujuan dari Perancangan Basis Data Konseptual (2002, p419), adalah untuk memproses pembuatan suatu model informasi yang digunakan didalam suatu organisasi dimana model tersebut tidak tergantung pada perangkat keras lainnya. Berikut ini adalah langkah-langkah dalam membuat model data konseptual lokal : Mengidentifikasi Tipe Entitas Dalam membangun suatu model data konseptual lokal maka perlu mendefinisikan objek utama dimana user memang membutuhkannya. Salah satu metode untuk mengidentifikasi tipe entitas yang utama adalah dengan mengidentifikasi kata benda atau frase kata benda yang telah disebutkan oleh user. Sebagai contoh: no staff, nama staff, no property, alamat property, rumah kontrakan, banyaknya kamar. Anda juga dapat melihat objek seperti orang, tempat, hobby, tidak termasuk kata benda yang mendefinisikan kualitas dari objek lain. Sebagai contoh, Anda dapat mengelompokkan no staff dan nama staff

19 24 dengan sebuah objek atau entitas yang disebut Staff dan mengelompokkan no property, alamat property, rumah kontrakan, dan banyaknya kamar menjadi suatu entitas yang disebut PropertyForRent Mengidentifikasi Tipe Relasi Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang penting antara berbagai tipe entitas yang telah diidentifikasikan. Biasanya, relasi diidentifikasi dengan menggunakan kata kerja atau frase kata kerja. Sebagai contohnya adalah: Staff Manages PropertyForRent. PrivateOwner Owns PropertyForRent. PropertyForRent Associated With Lease. Relasi yang paling umum adalah relasi binary, artinya relasi antar entitas yang persis antara dua entitas saja. Bagaimanapun, Anda harus memperhatikan relasi yang kompleks yang melibatkan lebih dari dua entitas dan relasi rekursif yang hanya melibatkan satu entitas. Adapun langkah-langkah dalam mengidentifikasi tipe relasi adalah sebagai berikut:

20 25 Gunakan Entity Relationship (ER) Diagram. Hal yang sering terjadi adalah Anda akan lebih cepat mengerti suatu perancangan basis data yang tervisualisasikan dibandingkan dengan perancangan basis data yang dituliskan dalam bentuk tekstual. Anda dapat menggunakan Entity-Relationship (ER) Diagram untuk mempresentasikan entitas dan bagaimana relasi antar entitas. Anda disarankan menggunakan Entity- Relationship (ER) Diagram untuk membantu Anda membuat gambaran besar dari perancangan basis data yang sedang Anda kembangkan. Tentukan pembatas multiplicity dari tipe relasi. Setelah Anda mempunyai relasi antara entitas maka langkah berikutnya adalah Anda dapat menentukan multiplicity setiap relasi. Jika memang ada suatu nilai yang spesifik dari suatu multiplicity maka akan lebih baik apabila didokumentasikan. Memeriksa Fan dan Chasm Traps. Setelah Anda mendefinisikan relasi yang dibutuhkan antar entitas maka langkah berikutnya adalah Anda dapat memeriksa fan dan chasm traps. Memeriksa setiap entitas yang mempunyai relasi minimal satu.

21 26 Pada saat Anda membuat Entity Relationship (ER) Diagram, pastikan bahwa setiap entitas mempunyai minimal satu relasi dengan entitas yang lain. Jika memang ada entitas yang sudah mempunyai minimal satu relasi dengan entitas yang lain maka langkah berikutnya adalah perhatikan kamus datanya. Apabila memang sudah mempunyai relasi semua, maka berarti Anda telah membuat setiap entitas mempunyai relasi Mengidentifikasi dan Mengasosiasikan Atribut Suatu Entitas atau Tipe Relasi Tujuan dari langkah ini adalah untuk mengidentifikasi dan mengasosiasikan atribut dari entitas atau tipe relasi. Simple / Composite Attributes Perlu diperhatikan apakah suatu atribut tersebut itu simple atau composite. Single / Multi-valued Attributes Diperhatikan apakah atribut mempunyai satu atau lebih nilai. Derived Attributes Diperhatikan atribut yang nilainya tergantung dengan nilai atribut yang lain

22 Menentukan Domain Atribut Tujuan dari langkah ini adalah untuk menentukan domain dari atribut yang ada didalam model data konseptual lokal. Sebagai contoh antara lain: Atribut dari No Staff terdiri dari sembilan karakter tipe string dimana satu karakter utama merupakan huruf, sedangkan delapan karakter sisanya berupa angka. Nilai yang mungkin untuk atribut jenis kelamin adalah L atau P. Ini merupakan domain dari atribut yang menggunakan karakter tunggal Menentukan Candidate Key dan Primary Key Tujuan dari langkah ini adalah untuk mengidentifikasi kandidat key dari setiap tipe entitas. Jika terdapat lebih dari satu candidate key, pilihlah salah satunya untuk menjadi primary key. Pada saat Anda memilih suatu primary key di antara banyak candidate key, gunakan petunjuk berikut ini untuk membantu menyeleksi: Merupakan candidate key dengan jumlah set paling sedikit. Merupakan candidate key yang nilainya jarang sekali berubah.

23 28 Merupakan candidate key dengan jumlah karakter paling sedikit. Merupakan candidate key dengan jumlah paling sedikit dari nilai maksimumnya (untuk tipe atribut dengan tipe numerik). Merupakan candidate key yang paling mudah digunakan dari sudut pandang pengguna. Beberapa jenis keys yang biasa digunakan, menurut Connolly dan Begg (2002, p340), antara lain: 1. Candidate key candidate key yaitu himpunan atribut minimal yang secara unik mengidentifikasikan tiap-tiap keberadaan suatu tipe entitas. 2. Primary key Primary key yaitu candidate key yang dipilih secara unik untuk mengidentifikasikan tiap-tiap keberadaan suatu tipe entitas. 3. Foreign key Foreign key yaitu himpunan atribut dalam suatu relasi yang cocok dengan candidate key dari beberapa relasi. 4. Alternate key Alternate key yaitu candidate key yang tidak terpilih menjadi primary key.

24 Menggunakan Enhanced Modeling Concepts (langkah optional) Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization, generalization, aggregation, dan composition. Specialization merupakan suatu proses memaksimalkan perbedaan-perbedaan antara anggotaanggota sebuah entitas dengan cara mengidentifikasi karakteristik yang membeakan entitas tersebut (Connolly, 2002, p362). Generalization merupakan suatu proses meminimalkan perbedaan-perbedaan antara entitas-entitas dengan cara mengidentifikasi sifat umum entitas (Connolly, 2002, p363). Aggregation menggambarkan relationship has-a atau is-part-of antara tipe entitas dimana yang satunya mewakili whole (seluruhnya) dan yang satunya lagi mewakili part (bagian) (Connolly, 2002, p371). Jika Anda menggunakan pendekatan specialization maka Anda akan memperhatikan perbedaan yang terlihat secara maksimal antara entitas satu atau banyak subclass dari entitas superclasses. Jika Anda menggunakan pendekatan generalization maka Anda akan

25 30 mengidentifikasi persamaan antara entitas yang ada untuk membentuk superclass Memeriksa Redundansi Tujuan dari langkah ini adalah untuk memeriksa apakah ada redundansi dalam model basis data. Pada langkah ini, Anda akan menguji data model konseptual lokal dengan melihat secara spesifik, apabila ada redundansi maka dapat dihilangkan dengan dua langkah berikut: Menguji kembali hubungan one-to-one. Menghilangkan relasi redundansi Validasi Model Konseptual Lokal dengan Transaksi User Bertujuan untuk memastikan local conceptual data model mendukung transaksi yang dibutuhkan oleh pandangan pengguna (Connolly, 2002, p435). Dua pendekatan untuk memastikan local conceptual data model mendukung kebutuhan transaksi.

26 31 1) Menggambarkan transaksi (describing the transaction) Memeriksa semua informasi (entitas, relationship, dan atributnya) yang dibutuhkan setiap transaksi yang disediakan oleh model (Connolly, 2002, p435). 2) Menggunakan transaction pathways Memvalidasi data model terhadap kebutuhan transaksi dengan menggambar diagram yang mewakili pathway yang diambil oleh setiap transaksi secara langsung pada E-R diagram (Connolly, 2002, p435) Melihat Kembali Data Model Konseptual Lokal dengan Pengguna Tujuan dari langkah ini adalah untuk melihat kembali model data konseptual lokal bersama user untuk memastikan bahwa model yang ada sudah sesuai dengan yang diminta. Hasil akhir dari perancangan basis data konseptual adalah proses pembuatan suatu model dari informasi yang akan digunakan di dalam suatu organisasi, yang independensinya tidak tergantung dengan apapun.

27 Perancangan Logikal Basis Data untuk Model Relasional Merupakan proses dalam membangun suatu model informasi yang digunakan didalam perusahaan, proses tersebut tidak tergantung oleh suatu DBMS dan pertimbangan fisikal tertentu, tetapi berdasarkan pada model data spesifik yang diperlukan.. Dalam logical database design, model data yang telah diperoleh dalam conceptual database design diubah dalam bentuk logical model dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basis data. (contoh: relational model). Hal ini dilakukan untuk menterjemahkan presentasi konseptual ke dalam bentuk struktur logic dalam basis data. Logical data model merupakan sumber informasi dalam merancang physical database. Logical database design memberikan sarana yang membantu para perancang dalam merancang fisikal database Membuat dan Memvalidasi Model Data Logikal Lokal untuk Setiap Bagian Adapun tujuan dari langkah membuat dan memvalidasi model data logikal lokal untuk setiap bagian adalah untuk membangun suatu model data logikal lokal dari suatu model data konseptual lokal yang merepresentasikan perusahaan kemudian memvalidasi model ini untuk memastikan strukturnya benar, dan memastikan bahwa model tersebut mendukung transaksi yang diminta.

28 Menghilangkan Bagian yang Tidak Sesuai dengan Model Relasi (langkah optional) Tujuan dari langkah ini adalah untuk memperbaiki model data konseptual lokal dengan menghilangkan fitur yang tidak cocok dengan model relasi. Bagian yang akan dibahas pada langkah ini antara lain : 1. Menghilangkan many- to-many (*:*) tipe relasi binary. Dengan memecah relationship yang mengandung many-to-many (*:*) untuk mengidentifikasikan sebuah entitas tengah (intermediate entity) sehingga relationship ini digantikan dengan dua buah one-tomany (1:*) relationship, dengan entitas tengah berada di antara dua buah entitas yang lama. 2. Menghilangkan many-to-many (*:*) tipe relasi recursive. Jika recursive relationship ada pada conceptual data model, relationship tersebut harus dipecah untuk mengidentifikasikan sebuah entitas tengah dengan cara menganggap entitas yang terlibat pada relationship ini merupakan dua buah entitas dengan jenis relationship many-to-many (*:*) binary sehingga penyelesaiannya sama dengan penyelesaian pada relationship many-tomany (*:*) binary.

29 34 3. Menghilangkan tipe relasi kompleks. Dihilangkan dengan memecah relationship ini untuk mengidentifikasikan entitas tengah (intermediate entity). Kemudian complex relationship ini akan digantikan dengan beberapa one-to-many (1:*) binary relationship. 4. Menghilangkan atribut-atribut multi-valued. Cara menghilangkannya adalah dengan memecah atribut ini untuk mengidentifikasikan sebuah entitas Membuat Relasi untuk Model Data Logikal Lokal Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk model data logikal lokal yang merepresentasikan suatu entitas, relasinya, dan juga atribut yang telah diidentifikasi. Anda dapat mendeskripsikan bagaimana relasi dapat diturunkan dari struktur model data antara lain: 1. Tipe Entitas Kuat. 2. Tipe Entitas Lemah. 3. One-to-many (1:*) tipe relasi binary. 4. One-to-one (1:1) tipe relasi binary. 5. One-to-one (1:1) tipe relasi recursive. 6. Tipe relasi superclass / subclass. 7. Many-to-many tipe relasi binary.

30 35 8. Tipe relasi kompleks. 9. Atribut-atribut multi-valued Memvalidasi Relasi Menggunakan Normalisasi Menurut Connolly dan Begg (2002, p376), normalisasi adalah sebuah teknik untuk menghasilkan sebuah kumpulan dari relasi-relasi dengan atribut-atribut yang diinginkan, yang berdasarkan kebutuhan-kebutuhan data sebuah perusahaan. Tahapan normalisasi menurut Connolly dan Begg (2002, p386), adalah sebagai berikut: 1. Unnormalized (UNF), sebuah tabel yang berisi satu atau lebih grup yang berulang. Yang dimaksud grup yang berulang itu adalah atribut-atribut yang multivalued. 2. Normalisasi pertama (1NF), menghilangkan perulangan. Sebuah relasi dimana setiap baris dan kolom hanya berisi satu nilai saja. Bentuk Normal pertama ini, dicapai apabila setiap nilai atribut adalah tunggal. Kondisi ini dapat diperoleh dengan melakukan eliminasi terhadap terjadinya data ganda (repeating groups). Pada kondisi normal pertama ini kemungkinan masih terjadi adanya data rangkap.

31 36 3. Normalisasi kedua (2NF), bentuk ini mempunyai syarat yaitu data harus memenuhi kriteria 1NF dan setiap data barang yang bukan key harus bergantung secara fungsional pada primary key-nya. Bentuk normal kedua adalah berdasarkan konsep ketergantungan fungsional penuh (full functional dependency). Full functional dependency dinyatakan jika A dan B adalah atribut dari suatu relasi, B adalah fungsional ketergantungan penuh (fully functional dependency) pada A jika B adalah secara fungsional bergantung pada A, tetapi bukan merupakan himpunan bagian dari A. Bentuk normal kedua menciptakan sebuah relasi pada bentuk normal pertama dan semua atribut yang bukan primary key adalah fungsional tergantung penuh pada primary key. 4. Normalisasi ketiga (3NF), sebuah relasi dalam bentuk normal pertama dan kedua serta setiap atribut bukan key yang bergantung secara transitif kepada bukan key juga. Bentuk normal ketiga adalah berdasarkan pada konsep peralihan ketergantungan (transitive dependency). Transitive dependency adalah sebuah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi bahwa jika A B dan B C, maka C adalah transitive dependent pada A melewati B (menyatakan

32 37 bahwa A bukan functional dependent pada B atau C). Pada bentuk normal ketiga, sebuah relasi pada bentuk normal pertama dan kedua serta dimana tidak ada atribut non-primary key secara transitif bergantung (transitively dependent) pada primary key. 5. Normalisasi Boyce-Codd (Boyce-Codd Normal Form / BCNF), suatu relasi dinyatakan BCNF, jika dan hanya jika setiap determinannya adalah sebuah candidate key. Untuk menguji apakah suatu relasi sudah dalam BCNF, dilakukan identifikasi semua determinan dan memastikan bahwa determinan tersebut adalah candidate key. Determinan adalah sebuah atribut, atau kumpulan atribut, dimana beberapa atribut yang lain masih bergantung secara fungsional penuh (fully functionally dependent). Perbedaan antara 3NF dan BCNF dalam hal functional dependency. A B, 3NF mengijinkan ketergantungan ini dalam sebuah relasi jika B adalah atribut primary key dan A bukan candidate key. Sedangkan dalam BCNF ketergantungan ini tetap ada di dalam sebuah relasi, dimana A harus sebuah candidate key. 6. Normalisasi keempat (4NF), sebuah relasi dalam BCNF dan tidak mengandung ketergantungan multivalued nontrivial (nontrivial multi-valued

33 38 dependencies). Bentuk normal keempat merupakan bentuk yang lebih kuat dari BCNF dimana 4NF mencegah relasi dari nontrivial multi-valued dependency dan data redundancy. Normalisasi dari BCNF ke 4NF meliputi pemindahan multi-valued dependency dari relasi dengan menempatkan atribut dalam sebuah relasi baru bersama dengan determinan. Multi-valued dependency menggambarkan ketergantungan antara atribut-atribut dalam suatu relasi. 7. Normalisasi kelima (5NF), sebuah relasi yang tidak mempunyai ketergantungan gabungan (join dependency). Join dependency menggambarkan sebuah tipe ketergantungan. Sebagai contoh, untuk sebuah relasi R dengan subset-subset atribut dari R yang dimisalkan dengan A, B,..., Z, sebuah relasi R menunjukkan join dependency, jika dan hanya jika, setiap nilai dari R sama dengan gabungan dari proyeksi-proyeksinya pada A, B,..., Z. Adapun anomali atau penyimpangan di dalam melakukan perubahan terhadap data yang ada pada suatu tabel. Ada 3 anomali atau penyimpangan menurut Connolly dan Begg (2002, p377), yaitu:

34 39 1. Insertion Anomalies a. Penyimpangan yang terjadi ketika ingin memasukkan suatu data baru yang bersifat foreign key maka harus memasukkan detil dari data tersebut secara berulang apabila ada data yang sama. Tujuannya untuk mencegah terjadinya ketidakkonsistenan data. b. Penyimpangan yang terjadi ketika ingin memasukkan suatu data baru yang bersifat foreign key, tetapi primary key dari data tersebut belum bisa dimasukkan karena alasan tertentu. Ini melanggar aturan dari integrity constraints, yaitu entity integrity (dalam sebuah relasi, atribut primary key tidak boleh bersifat null) 2. Deletion Anomalies Penyimpangan yang terjadi apabila ingin menghapus suatu data di mana data tersebut merupakan foreign key dari tabel gabungan dan tidak ada duplikasi dari foreign key tersebut, maka detil dari foreign key tersebut akan bebar-benar hilang dari basis data.

35 40 3. Modification Anomalies Penyimpangan yang terjadi apabila ingin mengubah suatu detil data foreign key pada tabel gabungan maka harus mengubah detil data foreign key pada setiap baris lainnya sesuai dengan data foreign key yang diubah Memvalidasi Relasi dengan Transaksi User Tujuan dari langkah ini adalah untuk memastikan bahwa relasi didalam model data logikal lokal mendukung transaksi yang diminta user. Pada langkah ini, Anda akan memeriksa bahwa relasi yang dibuat di langkah sebelumnya juga mendukung transaksi ini, dan juga pastikan bahwa tidak ada kesalahan dalam relasi yang telah dibuat Memeriksa Integritas Basis Data Tujuan dari langkah ini adalah untuk mendefinisikan ruang lingkup integritas yang diperlihatkan kepada user. Dalam hal ini ada lima tipe dari ruang lingkup integritas, antara lain :

36 41 1. Data yang diminta. Beberapa atribut harus selalu berisi nilai yang benar (valid), tidak dapat bernilai null. Constraint ini harus diidentifikasikan pada saat mendokumentasikan atribut-atribut pada kamus data (langkah 1.3). 2. Domain pembatas atribut. Setiap atribut memiliki domain, yaitu himpunan nilai yang dibolehkan (Connolly, 2002, p457). Constraint ini harus diidentifikasikan pada saat pemilihan attribute domain untuk data model (langkah 1.4). 3. Integritas entitas. Primary key dari sebuah entitas tidak boleh bernilai null. Constraint ini harus dipertimbangkan pada saat penentuan primary key bagi setiap tipe entitas (langkah 1.5). 4. Integritas referensi. Jika suatu foreign key memiliki nilai, maka nilai tersebut harus menunjuk ke sebuah baris yang ada pada relasi parent. 5. Pembatas Enterprise. Kegiatan update entitas dibatasi oleh peraturan atau kebijakan organisasi yang mengatur transaksi yang diwakilkan oleh update yang dilakukan.

37 Melihat Kembali Model Data Lokal dengan User Tujuan dari langkah ini adalah untuk memastikan model data logikal lokal dan membuat dokumentasi yang mendeskripsikan model tersebut sebagai representasi yang sesuai dengan keadaan sebenarnya Membangun dan Memvalidasi Model Data Logikal Global Tujuan dari langkah ini adalah untuk mengkombinasikan suatu model data logikal lokal individual ke dalam suatu model data logikal global yang menggambarkan suatu perusahaan Menggabungkan Model Data Logikal Lokal Menjadi Model Global Tujuan dari langkah ini adalah untuk menggabungkan suatu model data logikal lokal ke dalam suatu model data logikal global dari suatu perusahaan. Beberapa tugas dari pendekatan ini adalah sebagai berikut: 1. Memeriksa ulang nama dan isi dari suatu entitas / relasi dan candidate key. 2. Memeriksa ulang nama dan isi dari relasi / foreign key. 3. Menggabungkan entitas / relasi dari model data lokal. 4. Memasukkan (tanpa penggabungan) entitas / relasi unik pada setiap model data lokal.

38 43 5. Menggabungkan relasi / foreign key dari model data lokal. 6. Memasukkan (tanpa penggabungan) relasi / foreign key unik pada setiap model data lokal. 7. Memeriksa untuk entitas, relasi, foreign key yang hilang. 8. Memeriksa foreign key. 9. Memeriksa batasan integritas. 10. Menggambar diagram Entity-Relationship global. 11. Update dokumentasi Memvalidasi Model Data Logikal Global Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat dari model data logikal global dengan menggunakan teknik dari normalisasi dan juga memastikan bahwa relasi yang dibuat mendukung transaksi Memeriksa Kemungkinan Adanya Pengembangan Dimasa Mendatang Tujuan dari langkah ini adalah untuk menentukan bagian mana yang kelihatannya akan berubah ke masa depannya dan juga memperhatikan supaya model data logikal global dapat mengakomodasi perubahan tersebut.

39 Melihat Kembali Model Data Logikal Global dengan User Tujuan dari langkah ini adalah untuk memastikan bahwa model data logikal global itu memang merepresentasikan perusahaan yang ada. Hasil akhir dari perancangan basis data logikal adalah merancang suatu model informasi berdasarkan spesifik model yang ada (seperti model relasional), tetapi tidak tergantung terhadap suatu DBMS dan perangkat keras lainnya Hubungan Antara Logikal Data Model dan Data Flow Diagram Suatu Logical Data Model merefleksikan struktur dari penyimpanan data dalam suatu perusahaan. Sebuah Data Flow Diagram (DFD) menunjukkan aliran data suatu perusahaan dan disimpan didalam penyimpanan data. Semua atribut seharusnya berada didalam suatu tipe entitas. Jika mereka memang ditangani di dalam perusahaan, kemungkinan akan dilihat mengalir di sekitar perusahaan sebagai aliran data. Ada aturan yang mengontrol antara dua teknik tersebut, antara lain : Setiap penyimpanan seharusnya merepresentasikan suatu tipe entitas.

40 45 Atribut dalam aliran data seharusnya merupakan bagian dari tipe entitas Perancangan Fisikal Basis Data untuk Basis Data Relasional Proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien ke data, dan setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan (security). Pada tahapan ini memungkinkan perancang database untuk membuat keputusan mengenai bagaimana database akan diimplementasikan. Oleh karena itu, Physical database design harus disesuaikan Menterjemahkan Model Data Logikal Global untuk DBMS yang Digunakan Tujuan dari langkah ini adalah untuk membuat suatu skema basis data relasional dari model data logika global yang dapat diimplementasikan ke DBMS yang dipakai Merancang Basis Relasional Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan relasional dasar yang diidentifikasi dalam model data logikal global pada DBMS yang dipakai. Untuk memulai proses perancangan basis

41 46 data fisik, pertama-tama Anda dapat mengumpulkan dan mengasimilasikan suatu informasi tentang relasional yang dirancang selama perancangan basis data logikal. Informasi yang diperlukan bisa berasal dari kamus data dan definisi dari relasional yang didefinisikan menggunakan Database Design Language (DBDL). Untuk setiap relasional yang diidentifikasi pada model data logikal global, kita dapat mendefinisikan salah satu sebagai berikut: Nama dari relasi yang ada. Suatu daftar untuk atribut yang sederhana. Primary key, alternatif key, dan foreign key. Suatu daftar dari atribut turunan dan bagaimana mereka dihasilkan. Batasan integrasi untuk setiap foreign key yang diidentifikasi. Dari kamus data dari setiap atributnya dapat diketahui: Domain atribut tersebut yang terdiri dari tipe data, panjang dan berbagai keterangan atribut tersebut. Suatu nilai default optional untuk atribut. Apakah atribut bisa diisi nilai NULL.

42 Merancang Representasi Data Turunan Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan suatu data turunan pada model data logikal global pada DBMS yang dipakai. Atribut yang nilainya didapatkan dengan mengevaluasi atribut lain dikenal sebagai atribut turunan atau kalkulasi. Sebagai contoh: Jumlah staff yang bekerja di kantor cabang tertentu. Total gaji bulanan yang dibayarkan ke seluruh staff. Jumlah property yang ditangani oleh seorang staff Merancang Batasan Aplikasi Tujuan dari langkah ini adalah untuk merancang batasan aplikasi untuk DBMS yang dipakai. Perancangan batasan tersebut sekali lagi tergantung dari DBMS yang digunakan, fasilitas yang dipunyai oleh sistem dibandingkan dengan DBMS yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai aturan standard SQL, beberapa batasan dapat diterapkan Merancang Representasi Fisikal Tujuan dari langkah ini adalah untuk menentukan organisasi file yang paling optimal untuk menyimpan relasional

43 48 dasar dan indeks yang diminta untuk performansi yang optimal yang mana relasi dan data yang ada disimpan dalam penyimpanan sekunder. Ada tiga faktor untuk mengukur efisiensi penyimpanan data yaitu: Transaction throughput: jumlah transaksi yang dapat diproses pada rentang waktu yang diberikan (Connolly, 2002, p484). Response Time: waktu yang diperlukan untuk menyelesaikan sebuah transaksi (Connolly, 2002, p484). Disk storage: besarnya ukuran penyimpanan untuk menyimpan basis data (Connolly, 2002, p484) Menganalisis Transaksi Tujuan dari langkah ini adalah untuk mengerti fungsi dari suatu transaksi yang mana yang akan dijalankan pada basis data dan untuk menganalisis transaksi yang penting. Untuk membuat perancangan basis data fisikal efektif maka perlu mempunyai pengetahuan mengenai transaksi atau query yang akan dijalankan didalam basis data. Ini termasuk informasi yang kuantitatif dan kualitatif. Dalam menganalisa transaksi, Anda dapat mengidentifikasi performansi sebagai berikut:

44 49 Transaksi yang sering digunakan dan akan berdampak besar terhadap performansi. Transaksi yang merupakan transaksi bisnis kritis. Peak load yaitu durasi waktu dalam harian atau mingguan yang akan mendapatkan banyak permintaan pada basis data (Connolly, 2002, p486) Memilih Organisasi File Tujuan dari langkah ini adalah untuk menentukan organisasi file yang efektif untuk setiap relasi dasar. Dalam banyak kasus yang ada, suatu DBMS yang relasional akan memberikan sedikit bahkan tanpa pilihan dalam memilih organisasi file, walaupun beberapa akan mempunyai indeks yang spesifik. Bagaimanapun, berikut ini beberapa organisasi file yang ada adalah sebagai berikut: Heap. Hash. Indexed Sequential Access Method (ISAM). B + -tree. Clusters.

45 Memilih Indeks Tujuan dari langkah ini adalah untuk menentukan penambahan indeks yang akan meningkatkan performansi dari suatu sistem. Biasanya pemilihan atribut untuk pengindeksan adalah sebagai berikut: Suatu atribut yang digunakan paling sering untuk operasi penggabungan, yang akan membuat penggabungan tersebut lebih efektif Suatu atribut yang digunakan paling banyak untuk mengakses suatu record di dalam relasi yang ada. Ada tiga jenis indeks yaitu: Primary index Pengindeksan dilakukan pada kolom kunci (key field), yang diurutkan terlebih dahulu secara sekuensial. Clustering index Pengindeksan dilakukan pada kolom bukan kunci (non-key field), yang sudah diurutkan terlebih dahulu secara sekuensial. Kolom bukan kunci itu disebut juga dengan clustering attribute (Connolly, 2002, p1155).

46 51 Secondary index Pengindeksan yang dilakukan pada kolom yang tidak terurut di dalam file data (Connolly, 2002, p1155) Mengestimasi Kapasitas Disk yang Dibutuhkan Tujuan dari langkah ini adalah untuk mengestimasi ukuran kapasitas disk yang diperlukan untuk basis data Merancang Tampilan Layar untuk User Tujuan dari langkah ini adalah untuk merancang tampilan layar untuk user yang diidentifikasi selama pengumpulan informasi dan analisis dari siklus hidup aplikasi basis data Merancang Ukuran Keamanan Tujuan dari langkah ini adalah untuk merancang ukuran keamanan untuk basis data yang telah dispesifikasi oleh user. Hasil akhir dari perancangan fisik basis data adalah suatu proses yang mendeskripsikan suatu implementasi dari suatu basis data pada penyimpanan sekunder. Ini mendeskripsikan suatu relasi dasar dan struktur penyimpanan dan metodologi pengaksesan yang efisien selama batasan integritas dan ukuran keamanan.

47 Mempertimbangkan Pengenalan Pengontrolan Redundancy Untuk menentukan apakah pengenalan pengontrolan redundancy dengan mengendurkan aturan normalisasi akan meningkatkan unjuk kerja sistem Memantau Operasional Sistem Bertujuan untuk memantau operasional sistem dan meningkatkan unjuk kerja sistem untuk memperbaiki keputusan desain yang tidak sesuai atau menggambarkan kebutuhankebutuhan Pemilihan DBMS(optional) Menentukan DBMS mana yang dapat digunakan sesuai dengan aplikasi yang ditentukan. Ini dilakukan setelah dilakukannya perancangan konseptual. Karena suatu organisasi memerlukan perluasan atau perubahan pada sistem yang sedang berjalan, maka akan menjadi hal yang perlu untuk mengevaluasi produk-produk DBMS yang baru. Tujuannya untuk memilih sebuah sistem yang sesuai dengan kebutuhan perusahaan saat ini maupun di masa yang akan datang, yang seimbang dengan biaya-biaya yang dikeluarkan termasuk dalam pembelian produk DBMS, perangkat lunak maupun perangkat keras tambahan yang dibutuhkan untuk mendukung sistem basis data, dan biaya-biaya lain yang berhubungan dengan perubahan dan pelatihan pegawai. Tahapan utama dalam memilih DBMS antara lain:

48 53 1) Mendefinisikan syarat-syarat sebagai referensi Dibuat dengan menyatakan tujuan dan ruang lingkup pembelajaran, tugas-tugas yang akan dikerjakan, penjelasan kriteria (berdasarkan spesifikasi kebutuhan pengguna) yang akan digunakan dalam mengevaluasi produk-produk DBMS, daftar produk-produk yang dimungkinkan, semua batasan-batasan dan skala waktu yang dibutuhkan untuk pembelajaran. 2) Daftar singkat dua atau tiga produk Kriteria yang dianggap penting dalam keberhasilan implementasi dapat digunakan untuk membuat daftar produk-produk DBMS dalam evaluasi, seperti dana yang tersedia, tingkat dukungan vendor, kecocokan dengan perangkat lunak lainnya, dan apakah produk hanya berjalan pada perangkat keras tertentu. 3) Evaluasi produk Fitur-fitur yang digunakan dalam evaluasi produk-produk DBMS dikelompokkan menjadi definisi data, definisi fisik, kemampuan akses, penanganan keperluan-keperluan, pengembangan, dan fitur-fitur lainnya.

49 54 4) Merekomendasikan pilihan dan memproduksi laporan Langkah terakhir dari pemilihan DBMS adalah mendokumentasikan prosesnya dan membuat pernyataan dalam penemuan dan rekomendasi atas produk DBMS tertentu Application Design Langkah ini melakukan perancangan layar atau tampilan untuk user. Dalam merancang user interface dan program aplikasi, langkah ini menggunakan proses basis data yang mengacu pada petunjuk perancangan user interface seperti pemilihan judul, penulisan instruksi-instruksi menggunakan format yang standard sehingga mudah dipahami, pemakaian warna yang konsisten, dan sebagainya. Desain aplikasi dibagi menjadi dua aspek, yaitu : Desain transaksi Transaksi diartikan sebagai sebuah atau serangkaian aksi, yang dilakukan oleh seorang user atau program aplikasi, yang mengakses atau mengubah isi dari basis data (Connoly and Begg, 2002, p551). Terdapat tiga tipe utama transaksi : - Retrieval Transaction, contohnya tampilan detil data properti (data ditampilkan dalam bentuk angka). - Update Transaction, contohnya operasi untuk memasukkan detil data properti baru ke dalam basis data.

50 55 - Mixed Transaction, contohnya operasi untuk mencari detil data properti, menampilkannya dan kemudian mengupdate nilainya. Panduan Desain Antarmuka Pengguna Prototyping (optional) Pada langkah ini kita mengizinkan perancang dan user untuk memvisualisasikan dan mengevaluasi gambaran sistem secara menyeluruh. Seperti yang kita ketahui, tujuan utama dalam mengembangkan suatu aplikasi basis data prototype adalah untuk mengizinkan para pemakai menggunakan prototype, sehingga pemakai dapat mengidentifikasi fitur sistem, apakah sistem sudah bekerja dengan baik atau belum. Jika memungkinkan, pemakai dapat memberikan saran untuk mengadakan perbaikan atau bahkan menambahkan fitur baru dalam aplikasi basis data tersebut. Keuntungan prototype adalah relatif murah dan proses pembuatannya yang cepat Implementation Implementasi adalah sebuah langkah dimana mengrealisasikan fisikal dari database dan desain aplikasi. Setelah menyelesaikan langkah desain maka dilakukan implementasi database dan aplikasi dari program yang dibuat. Untuk melakukan implementasi database maka digunakan Data Definition Language (DDL).

51 Data Conversion and Loading Memindahkan data dari sistem yang lama ke sistem yang baru. Langkah ini dibutuhkan hanya pada waktu sistem basis data yang lama digantikan dengan sistem basis data yang baru (Connolly, 2002, p293).. Suatu DBMS mempunyai kegunaan memasukkan file ke dalam basis data yang baru, kemudian secara otomatis mengubah data tersebut ke dalam format yang diperlukan oleh file basis data yang baru. Jika dapat diterapkan, pengembang dapat mengubah dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru Testing Aplikasi basis data yang telah dibuat maka akan dilakukan pengecekan untuk mencari error yang tedapat pada aplikasi yang dibuat. Dalam melakukan testing, tidak hanya pembuat program tetapi pengguna juga ikut serta dalam melakukan testing tersebut Operational Maintenance Aplikasi basis data diimplementasikan secara penuh. Sistem tersebut ditinjau dan dirawat secara terus menerus. Saat dibutuhkan, maka permintaan-permintaan baru akan dimasukkan ke dalam aplikasi basis data melalui tahap-tahap daur hidup sebelumnya.