9
2.1. Teori Umum
Basis Data (Database) sekarang merupakan bagian dari kehidupan kita sehari-hari yang biasanya tidak kita sadari penggunaannya. Basis data dapat diartikan sebagai koleksi dari data yang berhubungan sementara sistem manajemen basis data (Database Management System / DBM S) merupakan perangkat lunak (software) yang mengatur dan mengontrol akses ke basis data. Aplikasi basis data merupakan program yang berinteraksi dengan basis data pada beberapa titik dalam eksekusinya. Istilah sistem basis data untuk memasukkan koleksi program aplikasi yang berinteraksi dengan basis data.
Dalam sistem basis data, data diwakili dalam bentuk tabel-tabel yang saling berhubungan satu sama lain berdasarkan nilai dari atribut tertentu yang sama. Data yang saling berhubungan inilah yang merupakan inti dari basis data relasional. Dalam basis data relasional, data didistribusikan ke dalam banyak tabel, namun antara satu tabel dengan tabel lainnya memilki keterkaitan yang unik, sehingga memungkinkan data dalam tabel tersebut disatukan kembali dan ditampilkan sebagai satu kesatuan informasi yang dibutuhkan oleh pengguna basis data tersebut.
2.1.1. Pengertian Basis Data
M enurut Connolly (2005, p15), basis data adalah sebuah koleksi logikal data yang saling terhubng satu sama lain dan gambaran dari data tersebut dirancang untuk menemukan kebutuhan informasi pada suatu organisasi / perusahaan. Sedangkan menurut Date (1999,p5), suatu sistem basis data merupakan suatu sistem yang pada dasarnya menyimpan record – record di dalam suatu sistem yang dilakukan secara komputerisasi di mana tujuannya ialah membentuk suatu kumpulan data yang terhubung dan DBM S / Sistem M anajemen Basis Data menjadi program yang mengatur dan mengontrol akses ke basis data tersebut serta memelihara informasi dan menjadikan informasi tersebut tersedia berdasarkan permintaan.
M enurut Ramakrishnan (2003, p4), basis data adalah koleksi data, secara tipikal menggambarkan aktivitas-aktivitas dari satu atau lebih organisasi yang terkait. Pakar lain, Jeffery L. Whitten (2004, p548), mengatakan bahwa basis data merupakan kumpulan dari file-file yang saling berhubungan dimana setiap baris pada suatu basis data juga harus saling terhubung dengan baris pada file lain.
M enurut Fathansyah (1999, p5), pemanfaatan basis data dapat dilakukan untuk memenuhi sejumlah tujuan seperti:
• Kecepatan dan kemudahan (speed) • Efisiensi ruang penyimpanan (space) • Keakuratan (accurancy)
• Ketersediaan (availability) • Kelengkapan (completeness) • Keamanan (security)
• Kebersamaan pemakai (sharability)
Intinya, basis data merupakan lemari berkas kabinet elektronik yang dapat menyediakan inti dari informasi umum dalam sebuah program.
2.1.2. Pengertian Sistem Manajemen Basis Data
M enurut Connolly (2005, p16), sistem manajemen basis data adalah sistem software yang memungkinkan pemakai (user) untuk mendefinisikan, membuat, memelihara, dan mengendalikan akses ke basis data. Sedangkan menurut Ramakrishnan (2003, p4), sistem manajemen basis data adalah software yang dirancang untuk mendukung dalam pemeliharaan dan pemanfaatan koleksi data dalam jumlah besar.
Pakar lain, Silberschatz (2002, p1), mengatakan bahwa sistem manajemen basis data adalah kumpulan data yang saling berhubungan dan kumpulan program untuk mengakses data-data tersebut. Kumpulan data biasanya merujuk kepada basis data, mengandung informasi yang relevan dengan perusahaan.
Tujuan utama DBM S adalah untuk menyediakan dan memperoleh informasi basis data yang nyaman (convenient) dan efisien. Sistem basis data dirancang untuk mengatur sejumlah besar informasi, manajemen
data termasuk menjelaskan struktur untuk penyimpanan informasi dan menyediakan mekanisme untuk manipulasi informasi.
2.1.3. Komponen dari Lingkungan DBMS
Gambar 2.1 Komponen Lingkungan DBMS
M enurut Connolly (2005, pp18-21), terdapat lima komponen utama dalam lingkungan DBM S, yaitu :
1. Perangkat Keras (Hardware), terdiri dari :
• Penyimpanan secondary (Magnetic Disk), I/O Device (contoh: Disk Drive), Device Controller, I/O Channels, dan lain-lain
• Hardware processor dan main memory, digunakan untuk
mendukung saat eksekusi system software database
2. Perangkat Lunak (Software), terdiri dari : DBM S, sistem operasi, software jaringan dan program aplikasi.
3. Data, digunakan oleh organisasi dan digambarkan dalam bentuk skema.
4. Prosedur adalah instruksi dan aturan yang harus diterapkan untuk mengatur perancangan dan penggunaan basis data dan DBM S. Pengguna sistem tersebut dan karyawan yang mengelola basis data
memerlukan dokumentasi prosedur dan bagaimana sistem itu dijalankan. Prosedur tersebut meliputi :
• M asuk ke dalam DBM S
• M enggunakan fasilitas DBM S atau aplikasi program • M emulai dan menghentikan DBM S
• M embuat backup dan recovery basis data
• M enangani kesalahan perangkat keras dan perangkat lunak
5. Orang adalah komponen yang terkait dengan sistem. Orang dibagi menjadi 4, yaitu:
• Data and Database Administrator
Data Administrator bertanggung jawab terhadap manajemen dari sumber data (data resource) termasuk perencanaan (planning), pengembangan (development) dan pemeliharaan (maintenance) basis data dari standard, kebijakan (policy), prosedur (procedure) dan perancangan basis data konseptual dan logikal.
Database Administrator bertanggung jawab untuk merealisasikan basis data secara fisik, termasuk perancangan basis data fisikal dan implementasi (implementation), security dan integrity control, memelihara sistem operasional (operational system) dan memastikan satisfactory performance dari aplikasi yang dibuat untuk user.
Pada proyek perancangan basis data, Database Designer dapat dibedakan menjadi 2, yaitu Logical Database Designer yang bertanggung jawab untuk mengenali data (yaitu: entity dan atribut), hubungan (relationship) antar data dan constraint pada data yang akan disimpan di dalam basis data. Dan Physical Database Designer yang bertanggung jawab untuk menentukan bagaimana perancangan basis data logikal dapat diwujudkan secara fisik.
• Application Developers
Bertanggung jawab untuk mengimplementasikan program aplikasi yang dapat menyediakan fungsionalitas yang dibutuhkan oleh End-Users.
• End-Users
End-Users adalah ‘klien’ dari basis data yang dirancang, diimplementasi dan dipelihara untuk memenuhi kebutuhan informasi dari End-Users. End-Users sendiri dapat dibedakan menjadi 2, yaitu : Naïve User dan Sophisticated User.
2.1.4. Keuntungan dan Kerugian DBMS
M enurut Connolly (2005, pp26-30), sistem manajemen basis data memiliki keuntungan sekaligus kerugian.
Keuntungan DBM S :
Pendekatan basis data mencoba menghapus redudansi dengan menggabungkan file-file sehingga salinan data yang sama tidak disimpan.
2. Konsisten (Data consistency)
Basis data membantu menghilangkan atau mengatur redudansi. Hal ini akan mengurangi terjadinya data yang tidak konsisten antar tabel yang satu dengan yang lain ataupun antar basis data..
3. Informasi lebih dari jumlah data yang sama (More information from the same amount of data)
Dengan integrasi data operasional, hal ini akan memungkinkan perusahaan untuk mendapatkan tambahan informasi dari data yang sama.
4. Pembagian data (Data sharing)
Basis data dimiliki oleh seluruh organisasi dan dapat dibagi oleh semua user yang memiliki hak akses. Dengan demikian, banyak user akan dapat membagi banyak data.
5. Perbaikan integritas data (Improved data integrity)
Database integrity menunjuk pada keabsahan dan konsistensi dari data yang disimpan.
6. Perbaikan keamanan (Improved security)
Database security adalah pelindung basis data dari user yang tidak memiliki hak akses. Tanpa keamanan yang tepat, integrasi hanya akan membuat data menjadi lebih mudah diserang.
7. Enforcement of standards
Integrasi membolehkan DBA untuk menentukan dan menyelenggarakan standard yang diperlukan.
8. Skala ekonomi (Economy of Scale)
Dengan menggabungkan data operasional suatu perusahaan ke dalam satu basis data, dan membuat sebuah kumpulan aplikasi yang berkerja pada satu sumber data, akan dapat menghemat pengeluaran suatu perusahaan.
9. Penyeimbangan terhadap conflicting requirement (Balance of conflicting requirements)
Setiap user atau departemen memiliki kebutuhan yang berbeda akan data. Karena basis data berada di bawah control DBSA, maka DBA dapat membuat keputusan tentang perancangan dan operasional dari suatu basis data.
10.Perbaikan akses data dan responsibilitas (Improved data accessibility and responsiveness)
Sebagai hasil dari integrasi, data yang melewati batas departemen dapat diakses oleh end-user. Hal ini akan menghasilkan sebuah sistem dengan fungsionalitas yang tinggi.
11.Peningkatan produktivitas (Increase productivity)
DBM S menyediakan banyak fungsi standar yang dapat memudahkan programmer. DBM S juga menyediakan sebuah lingkungan fourth-generation yang memudahkan programmer dalam mengembangkan
aplikasi basis data. Fungsi-fungsi ini akan meningkatkan produktivitas programmer dan mengurangi waktu yang digunakan untuk pengembangan.
12.Perbaikan maintenance melalui data independence (Improved maintenance through data independence)
DBM S memisahkan deskripsi mengenai data dengan aplikasi. Hal ini akan membuat aplikasi bebas untuk berubah dalam data description. Hal inilah yang disebut dengan data independence.
13.Peningkatan concurrency (Increase concurrency)
DBM S akan mengatur akses basis data secara bersamaan dan memastikan agar tidak terjadi kehilangan informasi atau integritas. 14.Perbaikan pelayanan backup dan recovery (Improves backup and
recovery services)
DBM S menyediakan fasilitas yang dapat mengurangi proses yang akan mengalami kegagalan.
Kerugian DBM S : 1. Kompleksitas (Complexity)
Ketentuan-ketentuan dari fungsionalitas yang kita harapkan dari sebuah DBM S yang baik membuat DBM S menjadi sebuah bagian dari software yang sangat rumit.
2. Ukuran (Size)
Kompleksitas dan luasnya fungsionalitas yang dimiliki DBM S membuat DBM S menjadi sebuah bagian software yang besar, yang
menempati banyak megabyte dari disk space dan membutuhkan ukuran memori yang besar untuk dapat berjalan dengan efisien.
3. Biaya DBM S (Cost of DBMSs)
Biaya DBM S berubah-ubah secara signifikan, tergantung pada lingkungan dan fungsionalitas yang disediakan.
4. Biaya perangkat keras tambahan (Additional hardware costs)
Kebutuhan akan tempat penyimpanan untuk DBM S dan basis data mengharuskan untuk membeli tempat penyimpanan tambahan. Selanjutnya untuk mencapai kinerja yang dibutuhkan, diperlukan untuk membeli alat yang lebih besar, bahkan sebuah alat khusus yang ditujukan untuk menjalankan DBM S.
5. Biaya konversi (Cost of conversion)
Dalam beberapa situasi, biaya DBM S dan hardware tambahan tidak bisa dibandingkan dengan biaya konversi aplikasi yang sudah ada untuk dijalankan pada DBM S dan hardware yang baru. Biaya ini termasuk biaya pelatihan staff untuk dapat menggunakan sistem yang baru, dan biaya memperkerjakan specialist staff untuk membantu dalam konversi dan menjalankan sistem. Hal inilah yang menyebabkan mengapa beberapa organisasi merasa terikat dengan sistem yang sudah ada dan tidak ingin pindah ke teknologi basis data yang lebih modern.
Pada umumnya, sebuah sistem berbasis file hanya ‘ditulis’ untuk aplikasi tertentu, seperti invoicing. Sebagai hasilnya, sistem tersebut memiliki performance yang baik. Sedangkan DBM S ‘ditulis’ untuk memenuhi banyak aplikasi. Hal ini mengakibatkan beberapa aplikasi tidak dapat berjalan secepat biasanya.
7. Dampak dari kegagalan lebih besar (Higher impact of failure)
Sumber yang terpusat meningkatkan kemungkinan sistem untuk mudah terkena serangan. Karena semua user dan aplikasi bergantung pada ketersediaan DBM S, Kegagalan beberapa komponen dapat menghentikan operasi.
2.1.5. Database Languages
M enurut Connolly (2005, pp39-42), sebuah data sublanguage terdiri dari dua bagian, yaitu :
1. Data Definition Language (DDL)
Sebuah bahasa (language) yang membolehkan DBA atau user untuk menggambarkan dan memberi nama entity, atribut, dan hubungan (relationship) yang dibutuhkan aplikasi, bersama dengan associated integrity dan security constraints.
Hasil kumpulan dari statement DDL adalah satu kumpulan tabel yang menyimpan file khusus secara bersama dinamakan sistem katalog. Sistem katalog yang mengintegrasikan meta data.
M eta data adalah data yang menggambarkan objek dalam basis data dan membuatnya lebih mudah untuk diakses dan dimanipulasi. M eta data berisi definisi dari record, data item, objek lain yang menjadi minat ke para pemakai atau diperlukan oleh DBM S. DBM S secara normal berkonsultasi kepada sistem katalog sebelum data yang aktual diakses dalam basis data.
2. Data Manipulation Language (DML)
Sebuah bahasa (language) yang menyediakan satu set operasi yang digunakan untuk mendukung operasi manipulasi pada data yang disimpan di dalam basis data.
Operasi manipulasi pada data meliputi : • M enambahkan data baru ke dalam basis data
• M emodifikasi data yang tersimpan dalam basis data • M emperoleh kembali data yang terdapat dalam basis data • M enghapus data dari basis data
DM L dibedakan oleh perolehan bentuk dasar pencarian mereka, kita dapat membedakan dalam 2 jenis DML yaitu :
• Procedural DML
Suatu bahasa yang memungkinkan pengguna untuk memberi instruksi ke sistem mengenai data yang dibutuhkan dan cara pemanggilannya. Artinya, pengguna harus menjelaskan operasi pengaksesan data yang akan digunakan dengan menggunakan
prosedur yang ada untuk mendapatkan informasi yang dibutuhkan.
• Non-procedural DML
Suatu bahasa yang memungkinkan pengguna untuk menentukan data yang dibutuhkan dengan menyebutkan spesifikasinya tanpa men-spesifikasikan bagaimana cara mendapatkannya.
2.1.6. Fungsi DBMS
M enurut Codd (1982), terdapat 8 fungsi yang seharusnya disediakan oleh DBM S. Dan Connolly (2005, pp48-52) menambahkan 2 fungsi yang diharapkan ada. Fungsi-fungsi tersebut adalah
1. Tempat penyimpanan, penerimaan, dan pembaharuan data
Sebuah DBM S harus melengkapi user dengan kemampuan untuk menyimpan, mendapatkan kembali, dan memperbaharui data di dalam database.
2. Sebuah katalog yang user-accessible
Sebuah DBM S harus dilengkapi dengan sebuah catalog yang di dalamnya berisi deskripsi dari item data yang disimpan dan dapat diakses oleh user.
3. M endukung transaksi
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme yang akan menjamin bahwa semua update yang cocok dengan transaksi yang diberikan dibuat atau tidak dibuat sama sekali.
4. M endukung kendali concurrency
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme untuk memastikan bahwa basis data diperbaharui secara benar pada saat banyak pemakai melakukan proses update secara bersamaan.
5. Recovery service
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme untuk mengembalikan (recovering) basis data pada saat basis data mengalami kerusakan.
6. Authorization service
Sebuah DBM S harus dilengkapi dengan sebuah mekanisme yang menjamin bahwa hanya user yang memiliki hak akses yang dapat mengakses basis data.
7. M endukung komunikasi antar data
Sebuah DBM S harus dapat terintegrasi dengan software komunikasi. 8. Integrity service
Sebuah DBM S harus dilengkapi dengan arti (means) untuk memastikan data di dalam basis data dan perubahan pada data mengikuti aturan tertentu.
9. Data independent service
Sebuah DBM S harus termasuk fasilitas untuk mendukung program yang independen dari struktur sebenarnya dari basis data.
10. Utility services
2.1.7. Relational Model
Relational model dibuat berdasarkan konsep matematika dari
sebuah relasi, yang secara fisik ditampilkan sebagai tabel.
2.1.7.1. Relational Data Structure
M enurut Connolly (2005, pp72-74), terdapat beberapa istilah, yaitu :
• Relasi (Relation) adalah tabel dengan kolom dan baris • Atribut (Attribute) adalah nama kolom dari sebuah relasi
• Domain adalah kumpulan nilai yang diperbolehkan untuk
satu atau lebih atribut
• Tuple adalah baris dari sebuah relasi
• Derajat (Degree) sebuah relasi adalah banyaknya atribut yang terkandung di dalam sebuah relasi
• Cardinality sebuah relasi adalah banyaknya tuple yang
terkandung di dalam sebuah relasi
• Relational Database sebuah koleksi dari relasi yang
ternomalisasi dengan nama relasi yang berbeda
2.1.7.2. Database Relations
M enurut Connolly (2005, p76), database relational dibagi 2:
• Relation Schema
Sebuah relasi bernama yang ditetapkan oleh kumpulan atribut dan nama domain berpasangan.
• Relational Database Schema
Kumpulan dari relation schema, setiap relation schema memiliki nama yang berbeda.
2.1.7.3. Relational Key
Seperti yang dijelaskan sebelumnya, tidak ada tuple yang sama dalam sebuah relasi. Sehingga kita perlu untuk mengenali satu atau lebih atribut (disebut relational key) yang secara unik mengenali setiap tuple dalam sebuah relasi.
M enurut Connolly (2005, pp78-79), relational key dibagi menjadi 4 :
1. Superkey
Sebuah atribut atau kumpulan atribut, yang secara unik menegaskan sebuah tuple dalam sebuah relasi.
2. Candidate Key
Sebuah superkey dimana tidak ada proper subset yang menjadi superkey di dalam relasi.
3. Primary Key
Candidate key yang dipilih untuk menegaskan secara unik sebuah tuple dalam sebuah relasi.
4. Foreign Key
Sebuah atribut atau kumpulan atribut, dalam sebuah relasi yang cocok dengan candidate key dari beberapa relasi (kemungkinan sama).
2.1.7.4. Integrity Constraints
Sebelum menjelaskan lebih jauh mengenai integrity constraint, ada baiknya kita mengerti mengenai konsep null. M enurut Connolly (2005, 81), null menampilkan sebuah nilai untuk sebuah atribut yang tidak diketahui atau tidak dapat diterapkan untuk tuple ini.
M enurut Connolly (2005, pp82-83), terdapat 2 aturan utama dalam relational model, yaitu :
1. Entity Integrity
Dalam relasi dasar, tidak ada atribut dari primary key yang bernilai null.
2. Referential Integrity
Jika sebuah foreign key ada di dalam sebuah relasi, nilai foreign key harus sesuai dengan nilai candidate key dari beberapa tuple di dalam relasi asal atau nilai foreign key harus bernilai null.
M enurut Connolly (2005, p83), ada 2 tipe integrity constraint yaitu :
1. General Constraints
Aturan tambahan yang ditetapkan oleh user atau DBA dari sebuah basis data yang menentukan atau memaksa beberapa aspek dari sebuah perusahaan.
2. Multiplicity
Untuk multiplicity, akan dijelaskan pada bagian 2.1.10.6
2.1.8. Database System Development Lifecycle
Untuk merancang aplikasi sistem basis data, tahapan-tahapan terstruktur yang harus diikuti dinamakan dengan Siklus Pengembangan Sistem Basis Data (Database System Development Lifecycle). Perlu diingat bahwa tahapan dalam DSDL tidak harus berurutan, namun juga melibatkan beberapa pengulangan ke tahapan sebelumnya melalui putaran balik (feedback loops). Tahapan-tahapan tersebut terlihat pada gambar 2.1 (Connolly, 2005, p284).
Gambar 2.2 Database System Development Lifecycle
2.1.8.1. Perencanaan Basis Data (Database Planning)
Perencanaan basis data merupakan perencanaan bagaimana tahapan-tahapan dalam lifecycle dapat direalisasikan seefektif dan seefisien mungkin. Perencanaan basis data harus terintegrasi dengan keseluruhan strategi sistem informasi dari organisasi.
Terdapat 3 hal pokok yang berkaitan dengan strategi sistem informasi, yaitu :
1. Identifikasi rencana dan sasaran (goals) dari enterprise termasuk mengenai sistem informasi yang dibutuhkan. 2. Evaluasi sistem informasi yang ada untuk menetapkan
kelebihan dan kekurangan yang dimiliki.
3. Penaksiran kesempatan IT yang mungkin memberikan keuntungan kompetitif.
M etodologi untuk mengatasi hal tersebut diatas yaitu :
• Database Planning – Mission Statement
Mission statement untuk proyek basis data mendefinisikan tujuan utama dari aplikasi basis data. Mission statement membantu menjelaskan kegunaan dari proyek basis data dan menyediakan alur yang lebih jelas untuk mencapai efektifitas dan efisiensi penciptaan dari suatu aplikasi basis data yang diinginkan.
• Database Planning – Mission Objectives
Ketika mission statement telah didefinisikan, maka mission objectives didefinisikan. Setiap tujuan (objective) harus mengidentifikasikan tugas khusus yang harus didukung oleh basis data. Dapat juga disertai dengan beberapa informasi tambahan yang menspesifikasikan
pekerjaan yang harus diselesaikan, sumber daya yang digunakan dan biaya untuk membayar kesemuanya itu.
2.1.8.2. Pendefinisian Sistem (System Definition)
System Definition menjelaskan batasan-batasan dan cakupan dari aplikasi basis data dan sudut pandang pemakai yang utama. Sudut pandang pemakai mendefinisikan apa yang diwajibkan dari suatu aplikasi basis data dari perspektif aturan kerja khusus atau area aplikasi perusahaan. Sudut pandang pemakai diperlukan untuk memastikan bahwa tidak ada pemakai utama dari suatu basis data yang terlupakan ketika pembuatan aplikasi baru yang dibutuhkan dan membantu dalam pengembangan aplikasi basis data yang rumit atau komplek juga memungkinkan permintaan-permintaan dipecah ke dalam bagian-bagian yang lebih simpel.
2.1.8.3. Pengumpulan dan Analisa Kebutuhan (Requirement Collection and Analysis)
Analisis dan pengumpulan kebutuhan merupakan suatu proses pengumpulan dan analisis informasi mengenai bagian organisasi yang didukung oleh aplikasi basis data, dan menggunakan informasi tersebut untuk identifikasi kebutuhan
pemakai akan sistem yang baru. Informasi yang dikumpulkan untuk setiap user view utama meliputi :
• Deskripsi data yang digunakan atau dihasilkan.
• Detail mengenai bagaimana data digunakan atau dihasilkan.
• Beberapa kebutuhan tambahan untuk aplikasi basis data yang baru.
Informasi dianalisis untuk identifikasi kebutuhan agar disertakan dalam aplikasi basis data yang baru. Aktivitas penting lainnya ialah menentukan bagaimana caranya mengatur aplikasi basis data dengan multiple user view, yaitu : • Pendekatan Terpusat (Centralized approach)
Kebutuhan untuk setiap user view digabungkan menjadi sekumpulan kebutuhan. Sebuah global data model dibuat berdasarkan atas penggabungan kebutuhan (dimana menampilkan seluruh user view).
• Pendekatan Integrasi View (View integration approach) Kebutuhan untuk setiap user view digunakan untuk membangun model data terpisah untuk merepresentasikan user view tersebut. Hasil dari model data tersebut nantinya digabungkan dalam tahapan desain basis data.
M odel-model yang menampilkan user view tunggal disebut local data model, dan tersusun atas
diagram-diagram dan dokumentasi yang secara formal menggambarkan kebutuhan dari user view khusus terhadap basis data. Kemudian local data model digabungkan untuk menghasilkan global data model, yang menampilkan seluruh user view untuk basis data.
• Kombinasi keduanya (Combination of both approaches)
2.1.8.4. Perancangan Basis Data (Database Design)
Perancangan basis data merupakan suatu proses pembuatan sebuah rancangan basis data yang akan mendukung tujuan dan operasi suatu perusahaan. Tujuan utamanya adalah :
• M enampilkan data dan relationship antar data yang dibutuhkan oleh seluruh area aplikasi utama dan user group.
• M enyediakan model data yang mendukung segala transaksi yang diperlukan pada data.
• M enspesifikasikan rancangan minimal yang yang secara tepat disusun untuk memenuhi kebutuhan performa yang ditetapkan pada sistem (misal : waktu respon).
Pendekatan dalam desain basis data :
Diawali dengan pembentukan model data yang berisi beberapa entitas high-level dan relationship, yang kemudian menggunakan pendekatan top-down secara berturut-turut untuk mengindentifikasikan entitas lower level, relationship dan atribut lainnya.
• Bottom-up
Dimulai dari atribut dasar (yaitu, sifat-sifat entitas dan relationship), dengan analisis dari penggabungan antar atribut, yang dikelompokan kedalam suatu relasi yang menampilkan tipe dari entitas dan relationship antar entitas.
• Inside-out
Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda dengan identifikasi awal entitas utama dan kemudian menyebar ke entitas, relationship, dan atribut terkait lainnya yang lebih dulu diidentifikasi.
• Mixed
M enggunakan pendekatan bottom-up dan top-down untuk bagian yang berbeda sebelum pada akhirnya digabungkan.
M enurut Connolly (2005, pp293-295), terdapat 3 fase dalam perancangan basis data, yaitu :
• Perancangan Basis Data Konseptual (Conceptual Database Design)
Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan, independen dari keseluruhan aspek fisik. M odel data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan pemakai. M odel data konseptual merupakan sumber informasi untuk tahap perancangan logikal.
• Perancangan Basis Data Logikal (Logical Database Design)
Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan berdasarkan model data tertentu (misal : relasional), tetapi independen terhadap DBM S tertentu dan aspek fisik lainnya. M odel data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal.
• Perancangan Basis Data Fisikal (Physical Database Design)
Suatu proses yang menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder. Perancanga ini menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakan juga, desain fisikal merupakan tahap perancangan terakhir menuju sistem DBM S tertentu.
2.1.8.5. Pemilihan DBMS (DBMS Selection)
Pemilihan DBM S yang tepat untuk mendukung aplikasi basis data. Dapat dilakukan kapanpun sebelum menuju perancangan logikal asalkan terdapat cukup informasi mengenai kebutuhan sistem. Tahap-tahap utama untuk memilih DBM S :
• M endefinisikan terminologi studi referensi. • M endaftarkan dua atau tiga produk.
• Evaluasi produk.
• Rekomendasi pilihan dan laporan produk.
2.1.8.6. Perancangan Aplikasi (Application Design)
Perancangan aplikasi adalah perancangan user interface dan program aplikasi yang menggunakan dan memproses basis data. Perancangan basis data dan aplikasi merupakan aktivitas paralel yang meliputi dua aktivitas penting, yaitu :
1. Perancangan Transaksi (Transaction Design)
Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan oleh user tunggal atau program aplikasi, yang mengakses atau mengubah isi dari basis data. Kegunaan dari desain transaksi adalah untuk menetapkan dan menerangkan karakteristik high-level dari suatu transaksi
yang dibutuhkan pada basis data. Terdapat tiga tipe transaksi, yaitu :
• Retrieval Transaction, digunakan untuk pemanggilan
(retrieve) data untuk ditampilkan di layar atau menghasilkan suatu laporan.
• Update Transaction, digunakan untuk menambahkan
record baru, menghapus record lama, atau memodifikasi record yang sudah ada didalam basis data.
• Mixed Transaction, meliputi pemanggilan dan
perubahan data.
2. Perancangan Tampilan Pemakai (User Interface Design) Beberapa aturan pokok dalam perancangan user interface :
• Meaningful title, diusahakan pemberian nama suatu
form cukup jelas menerangkan kegunaan dari suatu form/report.
• Comprehensible instructions, penggunaan terminologi
yang familiar untuk menyampaikan instruksi ke user dan jika informasi tambahan dibutuhkan, maka harus disediakan helpscreen.
• Logical grouping and sequencing of fields, field yang saling berhubungan ditempatkan pada form/report yang sama. Urutan field harus logis dan konsisten.
• Visually appealing layout of the form/report, tampilan form/report harus menarik, dan sesuai dengan hardcopy agar konsisten.
• Familiar field labels, penggunaan label yang familiar.
• Consistent terminology and abbreviation, terminologi
dan singkatan yang digunakan harus konsisten. • Consistent use of color
• Visible space and boundaries for data-entry fields,
jumlah tempat yang disediakan untuk data entry harus diketahui oleh user.
• Convinient cursor movement, user dapat dengan
mudah menjalankan operasi yang diinginkan dengan menggerakkan kursor pada form/report.
• Error correction for individual characters and entire fields, user dapat dengan mudah menjalankan operasi yang diinginkan dan melakukan perubahan terhadap nilai field.
• Error messages for unacceptable values.
• Optional fields marked clearly.
• Explanatory messages for fields, ketika user
meletakkan kursor pada suatu field, maka keterangan mengenai field tersebut harus dapat dilihat.
2.1.8.7. Protoyping
Prototyping adalah pembuatan model kerja suatu aplikasi basis data. Tujuan utama dari pembuatan prototyping: • Untuk mengidentifikasi feature dari sistem apakah
berjalan dengan baik atau tidak.
• Untuk memberikan perbaikan-perbaikan atau penambahan feature baru.
• Untuk klarifikasi kebutuhan customer.
• Untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari desain sistem khusus.
Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu:
• Requirements prototyping, menggunakan prototype untuk
menentukan kebutuhan dari aplikasi basis data yang diinginkan dan ketika kebutuhan itu terpenuhi maka prototype akan dibuang.
• Evolutionary prototyping, digunakan untuk tujuan yang
sama. Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan lanjutan menjadi aplikasi basis data yang digunakan.
2.1.8.8. Implementasi (Implementation)
Implementasi merupakan realisasi fisik dari basis data dan perancangan aplikasi. Implementasi basis data dicapai dengan menggunakan :
• DDL untuk membuat skema basis data dan file basis data kosong.
• DDL untuk membuat user view yang diinginkan.
M enggunakan 3GL dan 4GL untuk membuat program aplikasi. Transaksi basis data juga turut disertakan dengan menggunakan DM L, atau ditambahkan pada bahasa pemrograman.
2.1.8.9. Konversi Data dan Pemuatan (Data Conversion and Loading)
Pemindahan data yang ada ke dalam basis data baru dan merubah (conversion) aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBM S biasanya memiliki utilitas yang memanggil ulang file yang sudah ada ke dalam basis data baru. Dapat juga merubah (conversion) dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru.
2.1.8.10. Pengujian (Testing)
Testing adalah suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan dengan menggunakan strategi tes yang direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan software. Dengan adanya pengujian, maka kesalahan yang terjadi dapat segera diketahui dan diperbaiki sebelum diimplementasikan secara sempurna.
2.1.8.11. Pemeliharaan Operasional (Operational Maintenance) Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi :
• Pengawasan performa sistem, jika performa menurun, sehingga memerlukan perbaikan atau pengaturan ulang basis data.
• Pemeliharaan dan pembaharuan aplikasi basis data (jika dibutuhkan).
• Penggabungan kebutuhan baru ke dalam aplikasi basis data.
2.1.9. Data Administration and Database Administration
M enurut Connolly (2005, p309), terdapat data administration dan database administration yang bertanggung jawab untuk mengatur dan
mengawasi aktivitas yang berhubungan dengan data dan basis data perusahaan.
Data administration adalah pengaturan sumber data, dimana termasuk database planning, pengembangan dan pemeliharaan standard, policy dan prosedur serta perancangan basis data konseptual dan logikal.
Database administration adalah pengaturan dari realisasi fisik suatu sistem basis data, dimana termasuk perancangan basis data fisikal, implementation, pengaturan keamanan dan integrity control, mengawasi performa sistem, dan mengatur kembali basis data.
2.1.10. Entity-Relationship Modeling
ER (Entity Relationship) data model didasarkan pada persepsi dunia nyata yang terdiri dari kumpulan objek dasar, yang disebut entiti dan hubungan antara objek-objek ini.
2.1.10.1. Jenis Entiti (Entity Type)
Tipe entity merupakan konsep dasar dari suatu model ER. M enurut Connolly (2005, p343), Entity type adalah kumpulan dari objek dengan properti yang sama, yang dikenali oleh perusahaan dan mempunyai keberadaan yang independen. Keberadaan entity type dapat berupa fisik atau ‘nyata’ dan konseptual atau abstrak. Sedangkan Entity
occurrence adalah pengenalan objek yang unik dari sebuah entity type.
Gambar 2.3 Jenis Entiti
2.1.10.2. Jenis Relasi (Relationship Types)
M enurut Connolly (2005, p347), Relationship type adalah kumpulan hubungan yang mempunyai arti antara entity type. Sementara Relationship occurrence merupakan hubungan yang dikenali secara unik, yang meliputi keberadaan dari setiap entity type yang berpartisipasi.
M enurut Connolly (2005, pp347-348), Degree of Relationship Type adalah jumlah entity type yang berpartisipasi dalam sebuah relationship. Degree of Relationship Type terdiri dari :
Gambar 2.4 Binary Relationship
• Ternary Relationship : Hubungan antara tiga entity type.
Gambar 2.5 Ternary Relationship
• Quaternary Relationship : Hubungan antara empat entity
type.
M enurut Connolly (2005, pp349), recursive relationship adalah hubungan antara satu entity type dimana entity type tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. Disebut juga Unary Relationship.
Gambar 2.7 Recursive Relationship
2.1.10.3. Atribut (Attribute)
M enurut Connolly (2005, pp350-354), Atribut adalah properti dari sebuah entity atau relationship type. Contohnya : sebuah entity karyawan digambarkan oleh kdKary, nmKary, almtKary dan jabatan.
M acam-macam Atribut :
• Attribute Domain
himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.
Atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi.
• Composite Attribute
Atribut yang terdiri dari beberapa komponen dimana masing-masing komponen memiliki keberadaan yang independen. M isalkan atribut alamat dapat terdiri dari jalan, kota dan kode pos.
• Single-value Attribute
Atribut yang mempunyai nilai tunggal untuk setiap kejadian. M isalnya entity pemesanan memiliki satu nilai untuk attribut noPesan pada setiap kejadian.
• Multi-value Attribute
Atribut yang mempunyai beberapa nilai untuk setiap kejadian. M isalnya entity Karyawan memiliki beberapa nilai untuk attribut noTelp pada setiap kejadian.
• Derived Attribute
Atribut yang menampilkan nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entity type yang sama.
2.1.10.4. Key
Kita harus memiliki cara untuk menspesifikasikan bagaimana entity di dalam kumpulan entity dapat dibedakan. M aka, nilai dari atribut sebuah entity harus sedemikian rupa agar dapat mengidentifikasi entity secara unik. Sebuah key memberikan kemudahan untuk mengidentifikasi kumpulan atribut yang mencukupi untuk dapat membedakan entity yang satu dengan yang lain. Key juga membantu mengenali relationship secara unik serta membedakan relationship antara yang satu dengan yang lainnya.
M enurut Connolly (2005, pp352-353),Key terbagi atas:
• Candidate Key
Candidate Key didefinisikan sebagai jumlah minimal dari atribut-atribut yang secara unik mengenali setiap kejadian dari sebuah entity type.
• Primary Key
Primary Key didefinisikan sebagai candidate key yang
dipilih secara unik untuk mengenali setiap kejadian dari sebuah entity type.
• Composite Key
Composite Key didefinisikan sebagai candidate key yang terdiri atas dua atau lebih atribut.
2.1.10.5. Strong and Weak Entity
M enurut Connolly (2005, pp354-355), Strong entity type adalah entity type yang keberadaannya tidak tergantung pada jenis entity lainnya. Sedangkan weak entity type adalah jenis entity yang keberadaannya tergantung pada jenis entity lainnya. Strong entity type disebut juga parent, owner atau dominant entity sedangkan weak entity type disebut child, dependent atau subordinate entity.
2.1.10.6. Structural Constraints
M enurut Connolly (2005, p356), multiplicity adalah jumlah (atau jarak) kejadian yang mungkin terjadi dari sebuah entity type yang terhubung dengan entity type yang lain melalui sebuah relationship tertentu. Seperti yang dijelaskan sebelumnya, derajat (degree) yang sering digunakan untuk sebuah relationship adalah binary. Dan menurut Connolly (2005, pp357-362), binary dibagi menjadi 3 :
• One-to-One (1:1) Relationships
Gambar 2.8 One-to-One (1:1) Relationships
Gambar 2.9 One-to-Many (1:*) Relationships
• Many-to-Many (*:*) Relationships
Gambar 2.10 Many-to-Many (*:*) Relationships
2.1.10.7. Cardinality and Participation Constraints
M enurut Connolly (2005, pp362-363), multiplicity sebenarnya terdiri dari 2 constraint yang berbeda, yaitu :
Cardinality dan Participation Constraint. Cardinality
menggambarkan jumlah maksimal dari hubungan yang mungkin terjadi untuk setiap entiti yang berpartisipasi. Sedangkan participation menentukan apakah semua atau hanya beberapa entiti yang berpartisipasi dalam sebuah relasi.
2.1.11. Normalisasi (Normalization)
Gambar 2.11 Normalisasi
2.1.11.1. Pengertian Normalisasi
M enurut Connolly (2005, p388), Normalisasi adalah sebuah teknik untuk menghasilkan sebuah kumpulan relasi dengan property yang diinginkan, memberikan kebutuhan data dari sebuah perusahaan.
2.1.11.2. Functional Dependencies
Sebuah konsep penting yang berhubungan dengan normalisasi adalah functional dependency yang menjelaskan hubungan antar atribut-atribut (M aier, 1983).
M enurut Connolly (2005, pp393-399), karakteristik dari sebuah functional dependency dibagi 3 :
M enjelaskan relationship antara atribut-atribut dalam sebuah relasi. Sebagai contoh, jika A dan B adalah atribut dari relasi R, maka B secara fungsional tergantung pada A (digambarkan A→ B), jika setiap nilai dari A terhubung secara tepat dengan satu nilai dari B (A dan B dapat terdiri dari satu atau lebih atribut).
2. Full Functional Dependency
M enunjukkan bahwa jika A dan B adalah atribut dari sebuah relasi, maka B bergantung secara fungsional dengan A jika B bergantung pada A namun bukan pada proper subset dari A.
3. Transitive Dependency
Suatu kondisi dimana A, B dan C adalah atribut dari suatu relasi sehingga jika A→B dan B→C, maka C bergantung secara transitif pada A melalui B.
2.1.11.3. Proses Normalisasi
1. Unnormalized Form (UNF)
M enurut Connolly (2005, p403), UNF adalah sebuah tabel yang terdiri dari satu atau lebih repeating group.
M enurut Connolly (2005, p403), 1NF adalah sebuah relasi dimana titik potong dari setiap baris dan kolom terdiri dari satu dan hanya satu nilai.
3. Second Normal Form (2NF)
M enurut Connolly (2005, p407), 2NF adalah sebuah relasi yang terdapat dalam 1NF dan setiap atribut non-primary key tergantung secara fungsional pada primary key.
4. Third Normal Form (3NF)
M enurut Connolly (2005, pp408-409), 3NF adalah sebuah relasi yang terdapat dalam 1NF dan 2NF dimana atribut non-primary key tergantung secara transitif pada primary key.
2.1.12. Advanced Normalization
1. Boyce-Codd Normal Form (BCNF)
M enurut Connolly (2005, 419), BCNF adalah sebuah relasi di dalam BCNF, jika dan hanya jika setiap determinant adalah candidate key. 2. Fourth Normal Form (4NF)
M enurut Connolly (2005, p430), 4NF adalah sebuah relasi di dalam
Boyce-Codd normal form dan tidak terdapat ketergantungan
nontrivial yang multi-valued. 3. Fifth Normal Form (5NF)
M enurut Connolly (2005, p431), 5NF adalah Sebuah relasi yang tidak memiliki join dependency.
2.1.13. Perancangan Basis Data Konseptual (Conceptual Database Design) Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan, independen dari keseluruhan aspek fisik. M odel data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan pemakai. M odel data konseptual merupakan sumber informasi untuk tahap perancangan logikal.
Langkah-langkah untuk perancangan basis data konseptual : 1. M embangun model data konseptual
Bertujuan untuk membangun model data konseptual dari kebutuhan data suatu perusahaan.
a. M engenali tipe entity
Bertujuan untuk mengenali tipe entity yang dibutuhkan. b. M engenali tipe relationship
Bertujuan untuk mengenali relationship penting yang ada di antara tipe entity
c. M engenali dan menghubungkan atribut dengan entity atau tipe relationship
Bertujuan untuk menggabungkan atribut-atribut dengan entity atau tipe relationship yang sesuai.
Bertujuan untuk menentukan domain untuk atribut di dalam model data konseptual lokal.
e. M enentukan atribut candidate, primary, dan alternate key
Bertujuan untuk mengenali candidate key untuk setiap tipe entity dan, jika ada lebih dari satu candidate key, maka harus memilih salah satu sebagai primary key dan yang lainnya sebagai alternate key.
f. M empertimbangkan penggunaan enhanced modeling concept (optional)
Bertujuan untuk mempertimbangkan penggunaan enhanced modeling concept, seperti specialization/generalization, aggregation dan composition.
g. M emeriksa model untuk redudansi
Bertujuan untuk memeriksa kehadiran dari redundancy di dalam model.
h. M emvalidasi model konseptual terhadap transaksi user
Bertujuan untuk memastikan bahwa model konseptual mendukung transaksi yang dibutuhkan.
i. M elihat kembali model data konseptual dengan user
Bertujuan untuk melihat kembali model data konseptual dengan user untuk memastikan bahwa mereka mempertimbangkan model untuk menjadi tampilan sesungguhnya dari kebutuhan data sebuah perusahaan.
2.1.14. Perancangan Basis Data Logikal (Logical Database Design)
Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan berdasarkan model data tertentu (misal : relasional), tetapi independen terhadap DBM S tertentu dan aspek fisik lainnya. M odel data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal.
Langkah-langkah untuk perancangan basis data logikal : a M embangun dan memvalidasi model data logikal
Bertujuan untuk mewujudkan model data konseptual ke dalam model data logikal dan memvalidasi model untuk memeriksa apakah sudah benar secara struktur dan mendukung transaksi yang dibutuhkan.
b. M endapatkan relasi untuk data model logikal
Bertujuan untuk membuat relasi untuk model data logikal yang menampilkan entity, relationship, dan atribut yang sudah dikenali.
c. M emvalidasi relasi menggunakan normalisasi
Bertujuan untuk memvalidasi relasi pada model data logikal menggunakan normalisasi.
d. M emvalidasi relasi terhadap transaksi user
Bertujuan untuk memastikan relasi pada model data logikal mendukung transaksi yang dibutuhkan.
Bertujuan untuk memeriksa integrity constraint yang ditampilkan pada model data logikal.
f. M elihat kembali model data logika dengan user
Bertujuan untuk melihat kembali model data logikal dengan user untuk memastikan bahwa mereka menyadari model yang menjadi representasi yang sebenarnya dari kebutuhan data sebuah perusahaan.
g. M enggabungkan model data logikal ke dalam model global (optional)
Bertujuan untuk menggabungkan model data logikal ke dalam sebuah model data logikal global yang menampilkan semua user view dari sebuah basis data.
h. M emeriksa untuk pertumbuhan di masa depan
Bertujuan untuk menentukan apakah ada perubahan yang terjadi secara signifikan dan untuk menilai apakah model data logikal dapat menampung perubahan tersebut.
2.1.15. Perancangan Basis Data Fisikal (Physical Database Design)
Perancangan basis data fisikal merupakan suatu proses yang menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder serta menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat
dikatakan, desain fisikal juga merupakan cara pembuatan menuju sistem DBM S tertentu.
Langkah-langkah untuk perancangan basis data fisikal : a. M ewujudkan model data logical untuk target DBM S
Bertujuan untuk menghasilkan skema relasional basis data dari model data logikal yang dapat diterapkan pada target DBMS. b. M erancang relasi dasar
Bertujuan untuk memutuskan bagaimana menampilkan relasi dasar yang dikenali di model data logikal di dalam target DBMS. c. M erancang tampilan dari derived data
Bertujuan untuk memutuskan bagaimana menampilkan setiap data yang didapat di model data logikal di dalam target DBMS.
d. M erancang general constraint
Bertujuan untuk merancang general constraint untuk target DBMS.
e. M erancang file dan index organisasi
Bertujuan untuk menentukan file organisasi yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mendapatkan kinerja yang dapat diterima. Caranya dengan menyimpan relasi dan tuple di dalam tempat penyimpanan secondary.
Bertujuan untuk memahami fungsionalitas dari transaksi yang akan dijalankan pada basis data dan untuk menganalisa transaksi penting.
g. M emilih file organisasi
Bertujuan untuk menentukan file organisasi yang efisien untuk setiap relasi dasar.
h. M emilih indeks
Bertujuan untuk menentukan apakah dengan menambahkan indeks akan meningkatkan kinerja dari sistem.
i. M emperkirakan kebutuhan ruang disk
Bertujuan untuk memperkirakan jumlah dari disk yang dibutuhkan untuk basis data.
j. M erancang user views
Bertujuan untuk merancang user view yang dikenali selama
requirement collection dan menganalisa database system
development lifecycle.
k. M erancang mekanisme keamanan
Bertujuan untuk merancang mekanisme keamanan untuk basis data seperti yang ditetapkan user selama requirement dan collection dari database system development lifecycle.
l. M empertimbangkan pengenalan kontrol redudansi m. M emantau dan memperbaiki sistem operasional
2.1.16. Delapan Aturan Emas Perancangan User Interface 1. Konsisten
Tampilan pola design aplikasi sebaiknya sama untuk setiap halaman sehingga tidak membuat user bingung.
2. Shortcuts
M emberikan fungsi shortcut agar pemakai yang sering menggunakan dapat menggunakan aplikasi lebih cepat dan mudah.
3. Umpan balik yang informative
M emberikan petunjuk kegunaan setiap icon maupun tombol. 4. Adanya penutupan (keadaan akhir)
Tersedianya aksi untuk menutup aplikasi. 5. Pencegahan kesalahan
Diberikan konfirmasi untuk setiap aksi penting yang akan dilakukan user (misalnya proses delete) sehingga kesalahan bisa dicegah.
6. Pembalikan aksi
M enyediakan tombol untuk membatalkan aksi yang telah dilakukan. 7. Pusat kendali internal (Internal Locus of Control)
User diberikan kendali untuk menentukan langkah yang diinginkan. 8. Ingatan jangka pendek dikurangi
Icon / tombol yang digunakan sebaiknya menggunakan gambar yang umum, agar tidak menambah beban ingatan bagi user.
2.1.17. Data Flow Diagram
DFD merupakan suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari sistem, di mana data disimpan, proses apa yang menghasilkan data tersebut dan interaksi apa yang terdapat antara data yang tersimpan dan proses yang dikenakan pada data tersebut.
DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada maupun sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik di mana data tersebut mengalir atau di mana data tersebut akan disimpan.
Gambar 2.12 Data Flow Diagram (sumber : www.ilkom.unsri.ac.id)
DFD terdiri dari 3 bagian, yaitu : 1. Diagram Konteks (Context Diagram)
Diagram konteks adalah diagram yang terdiri dari suatu proses dan menggambarkan ruang lingkup suatu sistem. Diagram konteks merupakan level tertinggi dari DFD yang menggambarkan seluruh input ke sistem atau output dari sistem dimana memberi gambaran tentang keseluruhan sistem. Sistem dibatasi oleh boundary (dapat digambarkan dengan garis putus). Dalam diagram konteks hanya ada satu proses. Tidak boleh ada store dalam diagram konteks.
2. Diagram Nol (Zero Diagram)
Diagram nol adalah diagram yang menggambarkan proses dari data flow diagram. Diagram nol memberikan pandangan secara menyeluruh mengenai sistem yang ditangani, menunjukkan tentang fungsi-fungsi utama atau proses yang ada, aliran data, dan eksternal entity. Pada level ini sudah dimungkinkan adanya data store yang digunakan. Untuk proses yang tidak dirinci lagi pada level selanjutnya, symbol "*" atau "P (functional primitive) dapat ditambahkan pada akhir nomor proses. Keseimbangan input dan output (balancing) antara diagram 0 dengan diagram konteks harus terpelihara.
Tujuan dari diagram nol adalah untuk “memerinci” sebuah sistem menjadi “proses-proses” yang harus dilakukan ‘orang dalam.’ Atau jika dibuat dalam kalimat adalah : “Apa saja proses yang harus
dilakukan agar mencapai sistem tersebut ?.” Jadi, diagram ini adalah kelanjutan dari diagram konteks, yang “memperbanyak lingkaran,” sedangkan untuk (jumlah dan isi) terminator serta (jumlah dan isi) data flow dari dan ke terminator tersebut harus tetap.
3. Diagram Rinci (DFD Levelled)
DFD levelled menggambarkan sistem sebagai jaringan kerja antara fungsi yang berhubungan satu sama lain dengan aliran dan penyimpanan data, model ini hanya memodelkan sistem dari sudut pandang fungsi.
Dalam DFD levelled akan terjadi penurunan level dimana dalam penurunan level yang lebih rendah harus mampu merepresentasikan proses tersebut ke dalam spesifikasi proses yang jelas. Jadi dalam DFD levelled bisa dimulai dari DFD level 0 kemudian turun ke DFD level 1 dan seterusnya. Setiap penurunan hanya dilakukan bila perlu. Aliran data yang masuk dan keluar pada suatu proses di level x harus berhubungan dengan aliran data yang masuk dan keluar pada level x+1 yang mendefinisikan proses pada level x tersebut. Proses yang tidak dapat diturunkan/dirinci lagi dikatakan primitif secara fungsional dan disebut sebagai proses primitif.
2.2. Teori Khusus
2.2.1. Service Oriented Database Architecture (S ODA)
SODA (Service Oriented Database Architecture) adalah suatu implementasi dari konsep pendistribusian dari basis data menggunakan suatu servis yang dapat melakukan proses penambahan, pengubahan dan penghapusan data secara dinamis. Basis data SODA menggunakan konsep arsitektur informasi yang memudahkan fungsi-fungsi bisnis untuk saling berhubungan, misalnya untuk pertukaran informasi oleh departemen lain yang berkepentingan ataupun antar kantor cabang.
2.2.1.1. Arsitektur SODA
Arsitektur SODA dapat dibagi menjadi 6 bagian: • SODA Client
M erupakan coding (aplikasi) yang membuat koneksi pada salah satu service yang ada dalam sistem SODA, misalnya SODA Broker Service atau SODA Operator Service. • SODA Broker Service
SODA Broker Service menangani semua request data yang datang dan mendistribusikan subrequest tersebut ke dalam SODA Operator Service. SODA Broker Service juga menyimpan skema basis data global yang membentuk keseluruhan skem dari basis data tersebut. Selain itu,
SODA Broker Service juga yang menangani eksekusi dari SODA query.
• SODA Operator Service
Services inilah yang mengatur proses pertukaran data, dari dan ke basis data. Pertukaran data dilakukan dengan proses pipelining. Service proses ini terbagi menjadi 3 yakni: – Data Service
– Operator Service – Storage Service • Data Sources
M erupakan basis data yang digunakan.
2.2.1.2. Layer pada S ODA
Gambar 2.13 Layer S ODA
Layer pertama berisi semua semua raw data sources. Setiap data source diakses paling sedikit oleh satu SODA Data Operator Service di layer kedua.
Layer kedua berisi semua SODA Data Operator Service. Layer ini mengubah data yang disimpan dalam basis data menjadi format WRS SODA, serta membentuk interface antara data source dengan SODA Operator Service untuk dapat memanipulasi data. Sebuah SODA Data Operator Service hanya dapat terhubung dengan satu data source, yang akan membaca keseluruhan tabel beserta isinya.
Layer ketiga berisi semua SODA Operator Service kecuali Data dan Storage yang dapat menerapkan manipulasi data. SODA Operator Service dapat menukar data satu sama lain dengan menggunakan mekanisme notifikasi.
Hasil dari pertukaran data tersebut akan selalu disimpan pada SODA Storage Service yang berada pada layer keempat.
Lalu pada layer berikutnya terdapat SODA Broker Service yang menangani exception handling messages. SODA Broker Service ini menjadi middleware antara SODA client dan SODA Storage Service, serta mengatur eksekusi quesry dan bereaksi pada error.
SODA Client ditempatkan pada layer teratas sehingga dapat memasukkan query, sementara hasilnya selalu disimpan pada SODA Storage Service.
2.2.1.3. Communication Cycle
a. SODA client memasukkan query ke dalam SODA Broker Service.
b. SODA Broker Service menganalisa query dan memberi tugas kepada SODA Operator Service termasuk Data Operator dan Storage Operator Service.
c. Semua SODA operator Service segera bekerja begitu menerima data. SODA Data Operator Service segera mengirim data.
d. Data disimpan dalam SODA Storage Operator Service sampai data diambil oleh SODA client.
2.2.1.4. Mekanisme Dasar SODA
Berikut ini contoh dari mekanisme dasar SODA : • Client akan mengirimkan suatu query ke SODA Broker
Service. Di dalam SODA Broker Service, akan dilakukan pengecekan terhadap query tersebut. Pertama dilakukan pengecekan sintaksis, jika terjadi kesalahan, maka query akan ditolak oleh Broker. Selanjutnya dilakukan pengecekan tabel dan atribut dari query yang dikirim dengan Global Database Schema. Jika terjadi kesalahan, misalnya ada atribut atau tabel yang tidak sesuai, maka query tidak dapat dijalankan karena data tidak sesuai.
Gambar 2.14 Client - Broker
• SODA akan membuat suatu execution tree untuk menentukan urutan pengerjaan dari operasi-operasi query yang masuk. Setiap operasi akan ditangani oleh minimal satu SODA Operator Service. Jika ada SODA Operator service yang hilang, maka pengerjaan/eksekusi query akan dihentikan di sini.
Gambar 2.15 Broker - SODA
• Setelah Execution Tree terbentuk, maka setiap SODA Operator Services akan menerima Subrequest yang merupakan bagiannya. Jadi setiap Operator akan mengerjakan bagiannya sendiri. Tapi tidak menutup kemungkinan bahwa setiap operator saling berhubungan untuk mengerjakan suatu request.
Gambar 2.16 Broker - Operator
• Setelah semua request selesai dikerjakan oleh Broker Service, hasil kerjanya akan disimpan di root node, sehingga ketika client meminta hasilnya, client tinggal mengambil dari root node.
Gambar 2.17 Client – Operator
2.2.1.5. Kelebihan SODA
• SODA dapat melakukan proses pengiriman data dalam bentuk messaging secara dinamis
• SODA terintegrasi dengan database itu sendiri sehingga proses keamanan dan integrasi data menjadi lebih terjamin
• SODA memiliki web service sehingga SODA dapat menjadi HOST dan tidak memerlukan tools lain.
2.2.1.6. SOAP (Simple Object Access Protocol)
SOAP merupakan protokol yang dispesifikasikan untuk pertukaran struktur informasi menggunakan web service dalam jaringan komputer. Protokol ini bergantung pada XM L sebagai format dari pesannya dan juga pada protokol layer aplikasi lain.
Komunikasi antara 6 bagian berbeda dalam arsitektur SODA menggunakan pesan SOAP:
Gambar 2.18 Komunikasi - SOAP
• M engunakan SOAP melalui HTTP membuat komunikasi melalui proxy dan firewall lebih mudah dibandingkan dengan teknologi eksekusi remote.
• SOAP dapat digunakan dengan protokol transport berbeda, meskipun standar yang digunakan adalah HTTP.
• SOAP dapat digunakan di berbagai platform, simple dan extensible.
Kekurangan SOAP :
• Hanya dapat menggunakan format XM L, sehingga proses pengiriman lebih lambat
• Ketika menggunakan HTTP sebagai protokol transport, hanya satu client yang dapat menggunakan service ini.
2.2.2. Distributed DBMS
2.2.2.1. Konsep Arsitektur Distributed Database
Distributed database merupakan koleksi data – data yang saling berhubungan ( dan deskripsi dari data – data tersebut ) dan tersebar secara fisik melalui jaringan komputer.
Distributed DBM S (DataBase Management System) adalah software system yang mengatur pendistribusian basis data dan membuat sistem terdistribusi yang jelas kepada user. DDBM S ini merupakan satu kesatuan
basis data logic yang tersebar dalam fragment pada masing – masing komputer yang terpisah, namun dikendalikan oleh suatu DBM S yang sama. Setiap komputer dapat secara independent mengatur basis datanya sendiri, dan juga memungkinkan untuk mengakses basis data pada komputer lain dengan otonomi tertentu.
Karakteristik DDBM S :
Kumpulan data – data yang tersebar dan terhubung secara logical
Data – data terbagi – bagi ke dalam fragment – fragment
Fragment – fragment dapat di replikasi
Fragment di alokasikan ke bagian – bagian alin
Semua bagian – bagian terhubung dengan jaringan.
Data pada setiap site dikendalikan oleh DBM S
Setiap DBM S pasti memiliki minimal satu aplikasi global
Distributed Processing merupakan centralized database yang bisa diakses melalui jaringan komputer. M emiliki sebuah pusat database dan semua site mengaksesnya melalui jaringan. Sedangkan Parallel DBM S (Tambahan ) merupakan DBM S yang dijalankan pada berbagai processor
yang di design untuk dapat mengakses beberapa basis data secara bersamaan untuk meningkatkan performa.
2.2.2.2. Keuntungan dan Kerugian DDBMS Keuntungan :
Reflects Organizational Structure
Karena tersebar di seluruh bagian dari organisasi, DDBM S dapat dengan lebih jelas menggambarkan keadaan dari sebuah organisasi.
Improved shareability and local autonomy
Dengan adanya database di setiap bagian, maka setiap lokal basis data dapat mengakses basis datanya sendiri secara penuh(local autonomy). Namun tidak menutup kemungkinan untuk pusat mengakses basis data pada bagian tertentu. (shareability)
Improved Availability
Pada centralized DBM S, ketika satu komputer pusat terjadi gangguan pada DBM Snya, maka seluruh bagian dari DBM S akan terhenti. Tetapi pada distributed DBM S ini, kerusakan pada satu site tidak berpengaruh pada site – site yang lain. Walaupun kerusakan terjadi di pusat, namun proses untuk perbaikannya akan menjadi lebih mudah.
Karena data tersimpan di beberapa site, maka tingkat kepercayaan pada suatu data akan meningkat, jika data tersebut memang benar ada di beberapa site. M isalnya di site A, seorang customer memiliki sebuah aset mobil sebagai jaminan kredit, begitu pula di site B, maka berarti customer tersebut data – datanya benar.
Improved Performance
Karena data tersimpan di tempat yang terdekat dengan bagian yang sering mengakses data tersebut, maka proses pengaksesan basis data tentu akan lebih cepat.
Modular growth
Semakin lama, database semakin berkembang, namun belum tentu perkembangan basis data di semua site sama. Jadi dengan DDBM S, pertumbuhan berbeda – beda di setiap bagian / site dapat dilakukan.
Kerugian:
Complexity
Proses untuk mendistribusikannya memerlukan pertimbangan dalam hal performance, reliability dan availability. Hal ini memerlukan perancangan yang lebih kompleks dibandingkan dengan centralized basis data.
Karena lebih kompleks, maka maintenance terhadap DDBM S akan memakan lebih banyak biaya.
Security
Pengontrolan terhadap akses basis data lebih sulit, karena selain harus mengamankan jaringan komputer yang ada, basis data di semua site juga harus aman.
Integrity control more difficult
Database integrity merujuk kepada validitas dan konsistensi dari data yang disimpan. Antara basis data yang satu dengan yang lain harus memiliki data yang sesuai, terutama antara data yang tersebar dengan data pusat. Itu sebabnya proses pengintegrasian menjadi lebih sulit sebab harus punya memiliki contraint khusus yang didefinisikan untuk seluruh basis data.
Lack of standards
Tidak adanya standar khusus yang mengatur tentang DDBM S, juga tidak ada metodologi khusus yang membantu user mengubah centralized DBM S ke distributed DBM S.
Lack of experience
Teknologi ini masih terbatas dan lebih jarang digunakan dibandingkan dengan centralized DBM S.
Perancangan basis data harus memperhitungkan fragmentasi data, alokasi fragment – fragment ke site – site tertentu dan replikasi data. Hal ini membuat proses perancangan basis data menjadi lebih sulit dan kompleks.
2.2.2.3. Fungsi dari DDBMS
DDBM S yang baik memiliki fungsi berikut ini :
M eningkatkan communication services untuk menyediakan akses data ke lokal dan memungkinkan untuk proses transfer query dan data melalui jaringan.
M emperluas sistem katalog untuk menyimpan detail dari distribusi data.
Dapat melakukan query secara terdistribusi, termasuk query optimization dan remote data access.
M emperluas security control untuk membuat autorisasi terhadap akses basis data.
M emperluas concurrency control untuk menjamin konsistensi data terdistribusi
M eningkatkan fungsi recovery service untuk kasus – kasus dimana terjadi kegagalan di salah satu site basis data.
2.2.2.4. Arsitektur Umum
Global conceptual schema
merupakan deskripsi keseluruhan dari distributed database yang akan dibuat. Pertama – tama dibuat tidak seperti akan didistribusikan. Level ini disetarakan dengan conceptual level seperti ANSI-SPARC architecture, mengandung definisi dari entity, relationship, constraint, security dan integrity.
Fragmentation dan alokasi schema
M erupakan deskripsi bagaimana data – data tersebut dibagi – bagi secara logical.
Local schema
M erupakan perancangan skema di masing - masing bagian basis data.
2.2.2.5. Komponen Arsitektur DDBMS
Terdiri dari 4 macam :
Local DBMS Component
DBM S yang dibutuhkan untuk mengatur data di lokal
Data communications Component
DC component memungkinkan semua site saling
berhubungan.
M enyimpan informasi dari keseluruhan proses yang terjadi, komunikasi yang terjadi, dan data apa saja yang melewati jaringan.
Distributed DBMS Component
M engontrol keseluruhan basis data yang tersebar di berbagai tempat.
2.2.2.6. Alokasi Data
Ada 4 tipe alokasi data, yaitu :
Centralized
Basis data tersimpan di satu pusat, dimana akan menyebabkan komunikasi data antar jaringan tinggi yang dapat mengakibatkan terhentinya seluruh proses ketika pusat mengalami kerusakan.
Fragmented ( partitioned )
Setiap basis data tertentu disimpan di masing – masing sitenya. M isalnya data customer di tempatkan di site A, data karyawan di site B. Jika salah satu site mengalami kerusakan, maka hanya data tersebut yang rusak, data di site lain masih tetap ada.
Complete Replication
M enempatkan complete copy di semua site basis data, sehingga reliability dan availability menjadi maksimal. Di
sini semua data di semua tempat memiliki data yang sama. Jika salah satu tempat terjadi kerusakan, bisa langsung diperbaiki.
Selective Replication
Gabungan dari complete replication dan fragmented, dimana data yang disimpan di semua tempat bukan merupakan data yang sama, melainkan data dari tempat itu sendiri. M isalnya data customer di site A adalah semua data customer yang berada di A, sedangkan di site B juga terdapat data customernya sendiri. Fungsi basis data pusat pada alokasi data tipe ini ialah untuk mengkoordinir setiap basus data sitenya. Alokasi data ini paling banyak digunakan karena fleksibilitasnya.
2.2.3. Service Broker
2.2.3.1. Pengertian Service Broker
SQL Service Broker (SSB) merupakan sebuah teknologi baru yang memungkinkan proses internal maupun ekternal untuk mengirim, memproses dan menerima pesan. SSB ini dibangun pertama kali dalam mesin SQL Server 2005 yang memungkinkan proses pengiriman pesan terjadi dalam server maupun antar server. Proses messaging ini dapat dicapai dengan menggunakan extension T-SQL. Jadi dalam
