Merancang Arsitektur Basis Data

Merancang Arsitektur Basis Data

MERANCANG ARSITEKTUR BASIS DATA

A. Sistem Basis Data

Tingkat atau level abstraksi database dibagi menjadi tiga bagian yaitu :

1.     Level fisik ( physical level )

2.    Konseptual ( conceptual level )

3.    Level pandangan ( view level )

Basis data adalah kumpulan data yang saling berelasi. Data sendiri merupakan fakta mengenai obyek, orang, dan lain-lain. Data dinyatakan dengan nilai (angka,deretan karakter, atau symbol). Basis data dapat didefinisikn dalam berbagai sudut pandang seperti berikut:

Himpunan kelompok data yang saling berhubungan yang diorganisasikan sedemikian rupa sehingga kelak dapat dimanfaatkan dengan cepat dan mudah.

Kumpulan data yang saling berhubungan yang disimpan secara bersama sedemikian rupa tanpa pengulangan (redundancy) yang tidak perlu, untuk memenuhi kebutuhan.

Kumpulan file/table/arsip yang saling berhubungan yang disimpan dalam media penyimpanan elektronik.

Basis data bertujuan untuk mengatur data sehingga diperoleh kemudahan, ketepatan, dan kecepatan dalam pengambilan kembali. Untuk mencapai tujuan, syarat sebuah basis data yang baik adalah sebagai berikut;

Tujuan adanya redundansi dan inkonsistensi data

Redudansi terjadi jika suatu informasi disimpan di beberapa tempat. Misalnya, ada data mahasiswa yang memuat NIM, nama, alamat, dan atribut lainnya, sementara kita punya data lain tentang data KHS mahasiswa yang isinya yang terdapat NIM, nama, mata kuliah, dan nilai.

2.       Kesulitan Pengaksesan Data

Basis data memiliki fasilitas untuk melakuakan pencarian informasi dengan menggunakan Query taupun dari tool untik melihat tabelnya. Dengan fasilitas ini. Kita bias secara langsung melihat data dari software DBMS-nya. Selain itu, baiss data bias dihubungkan dengan program aplikasi sehingga memudahkan pengguna dalam mengakses informasi. Misalnya program aplikasi untuk kasir yang terhubung dengan basis data . pengguna cukup mengguna fasilitas pencarian ataupun laporan. Yang tersedia pada program aplikasi untuk mendapatkan informasi stok, laporan penjualan, dan lain-lain.

3.    Multiple User

Basis data memungkinkan pengguna data bersama-sama oleh banyak pengguna pada saat yang bersamaan atau pada saat yang berbeda. Dengan meletakkan basis data pada bagian server yang bisa diakses kesemua pengguna dari banyak klient, kita sudah menyediakan akses kesemua pengguna dari computer klient ke sumber informasi yaitu basis data.

B. Normalisasi Database

Normalisasi adalah proses pengorganisasian data dalam database. Ini termasuk menciptakan Daftar Tabel dan menjalin hubungan antara Daftar Tabel tersebut sesuai aturan yang dirancang baik untuk melindungi data dan membuat database yang lebih fleksibel dengan menghilangkan redundansi dan ketergantungan yang tidak konsisten.

Ada beberapa aturan untuk database normalisasi. Setiap aturan yang disebut "bentuk normal." Jika aturan pertama diamati, database dikatakan dalam "pertama bentuk normal." Jika aturan pertama tiga diamati, database dianggap berada di "ketiga bentuk normal." Meskipun tingkat lain dari normalisasi mungkin, bentuk normal ketiga dianggap tingkat tertinggi yang diperlukan untuk sebagian besar aplikasi.

Seperti dengan banyak peraturan formal dan spesifikasi, skenario dunia nyata tidak selalu memungkinkan untuk kepatuhan sempurna. Secara umum, normalisasi memerlukan Daftar Tabel tambahan dan beberapa pelanggan menemukan ini rumit. Jika Anda memutuskan untuk melanggar salah satu aturan pertama tiga normalisasi, pastikan bahwa aplikasi Anda mengantisipasi setiap masalah yang bisa terjadi, seperti data yang berlebihan dan tidak konsisten dependensi.

Bentuk Normal pertama

Menghilangkan kelompok-kelompok yang berulang dalam Daftar Tabel individu.

Membuat Daftar Tabel terpisah untuk masing-masing set data terkait.

Mengidentifikasi setiap rangkaian data terkait dengan bukti kunci primer.

Jangan gunakan beberapa bidang dalam sebuah Daftar Tabel tunggal untuk menyimpan data yang sama. Misalnya, untuk melacak item persediaan yang mungkin datang dari dua sumber yang mungkin, catatan persediaan yang mungkin berisi bidang untuk Vendor kode 1 dan 2 kode Vendor.

Apa yang terjadi ketika Anda menambahkan vendor ketiga? Menambahkan sebuah field bukanlah jawabannya; itu memerlukan modifikasi program dan tabel atak dan tidak lancar mengakomodasi jumlah vendor yang dinamis. Sebaliknya, tempat semua informasi vendor didalam table yang terpisah yang disebut vendor, kemudian link persediaan untuk vendor dengan item nomor bukti kunci, atau vendor untuk persediaan dengan vendor kode bukti kunci.

Kedua bentuk Normal

Buat Daftar Tabel terpisah untuk set nilai-nilai yang berlaku tomultiple records.

Berhubungan Daftar Tabel ini dengan foreign key.

Catatan tidak boleh bergantung pada apa pun selain bukti kunci primer table (senyawa bukti kunci, jika perlu). Sebagai contoh, mempertimbangkan alamat penyuratan pelanggan dalam sistem akuntansi. alamat penyuratan diperlukan oleh Daftar Tabel pelanggan, tetapi juga oleh pesanan, pengiriman, faktur, Piutang, dan koleksi Daftar Tabel. Daripada menyimpan alamat penyuratan nasabah sebagai entri terpisah dalam masing-masing Daftar Tabel, menyimpannya di satu tempat, atau tabel atak pelanggan alamat penyuratan table yang terpisah.

Bentuk Normal ketiga

Menghilangkan bidang yang tidak bergantung pada bukti kunci.

Nilai-nilai dalam catatan yang bukan merupakan bagian dari bukti kunci catatan yang tidak termasuk dalam Daftar Tabel. Secara umum, setiap saat isi sekelompok bidang mungkin berlaku untuk lebih dari satu catatan data dalam Daftar Tabel, mempertimbangkan menempatkan bidang tersebut didalam table yang terpisah.

Sebagai contoh, dalam Daftar Tabel rekruitmen karyawan, calon Universitas nama dan alamat penyuratan dapat disertakan. Tetapi Anda perlu daftar lengkap dari Universitas untuk kelompok surat. Jika informasi Universitas disimpan dalam Daftar Tabel kandidat, ada cara untuk Daftar Universitas dengan kandidat saat ini tidak ada. Buat Daftar Tabel perguruan tinggi dengan terpisah dan menghubungkannya ke tabel atak calon dengan Universitas kode bukti kunci.

PENGECUALIAN: Mengikuti bentuk ketiga normal, sementara secara teoritis diinginkan, tidak selalu praktis. Jika Anda memiliki Daftar Tabel pelanggan dan Anda ingin menghilangkan semua dependensi interfield mungkin, Anda harus membuat Daftar Tabel terpisah untuk kota-kota, kode ZIP, perwakilan penjualan, pelanggan kelas, dan faktor lainnya yang dapat digandakan dalam beberapa catatan. Dalam teori, normalisasi bernilai mengerucutkan. Namun, banyak Daftar Tabel kecil dapat menurunkan kinerja atau melebihi buka file dan kapasitas kehabisan memori.

Mungkin lebih layak untuk menerapkan bentuk normal ketiga hanya untuk data yang sering berubah. Jika tetap tergantung beberapa bidang, desain aplikasi Anda untuk meminta user untuk memverifikasi semua bidang terkait ketika salah satu berubah.

Bentuk-bentuk normalisasi  

Keempat bentuk normal, juga disebut Boyce Codd Normal formulir (BCNF), dan bentuk normal kelima ada, tapi jarang dianggap dalam desain praktis. Mengabaikan aturan-aturan ini mungkin mengakibatkan desain database kurang sempurna, tetapi seharusnya tidak mempengaruhi fungsi.

VnPrese3 � " a �� P� '> 

2.    Immediate update (update yang segera)

Di teknik ini, database akan diupdate oleh beberapa transaksi sebelum transaksi mencapai titik point

UNDO/ REDO Recovery based on immediate update in a single-user

     Jika kegagalan terjadi, transaksi yang aktif pada saat terjadi kegagalan menyimpan beberapa perubahan pada database. Efek dari semua operasi ini harus dibuka (UNDONE).

    SHADOW PAGING

  Skema recovery ini tidak membutuhkan penggunaan log pada single-user. Pada multiuser,sebuah log mungkin dibutuhkan untuk metode kontrol konkurensi.

Dan itulah yang dapat saya sampaikan,semoga bermanfaat bagi anda yang mendengar persentasi saya. Sekian dan terima kasih