Model Database Hierarkis
Awal sistem
manajemen database (DBMS) berdasarkan pada model data hirarkis. Hal ini menjadi populer karena menggunakan pendekatan untuk representasi data lebih atau kurang tepat, hal
ini juga mencerminkan banyak aspek dalam hubungan suatu organisasi yang hirarkis. Selain itu, merupakan alat pengolahan data yang efisien untuk masalah yang sangat
terstruktur.
Model
hirarkis menyajikan pandangan terbatas hubungan data. Berdasarkan dalil bahwa
semua
hubungan bisnis yang hirarkis (atau dapat
direpresentasikan seperti itu), model ini tidak selalu mencerminkan realitas. Aturan berikut mengatur model hirarkis yang mengungkapkan kendala operasi:
1.
Sebuah catatan
orang tua mungkin memiliki satu atau lebih catatan anak.
2.
Tidak ada catatan
anak yang
memiliki lebih dari satu orang tua.
Model Database
Jaringan
Model
jaringan adalah variasi dari model hierarkis. Fitur utama yang membedakan antara keduanya adalah bahwa model jaringan memungkinkan catatan anak untuk memiliki
beberapa orang tua. Aturan kepemilikan fleksibel dalam memungkinkan hubungan yang
kompleks untuk diwakili.
Struktur
Data
Struktur data memungkinkan catatan untuk ditempatkan, disimpan, dan diambil dan memungkinkan pergerakan dari satu catatan ke yang lain.
Struktur data memungkinkan catatan untuk ditempatkan, disimpan, dan diambil dan memungkinkan pergerakan dari satu catatan ke yang lain.
- Struktur
Data Model Hierarkis, pengguna sistem ini menggunakan program pertanyaan untuk
mengambil semua data yang berkaitan dengan faktur penjualan tertentu dengan
metode akses langsung indeks hirarkis yang mengambil kunci utama kemudian
dimasukkan oleh pengguna melalui program pertanyaan dan membandingkannya dengan
indeks, setelah itu langsung mengakses catatan pelanggan.
- Struktur
Data Model Jaringan, model jaringan adalah database navigasi yang menciptakan
hubungan eksplisit antara catatan. Model
jaringan mendukung beberapa jalur untuk catatan tertentu.
Gambaran
Flat-file
Banyak yang disebut legacy system yang
ditandai dengan pendekatan flat-file pada data manajemen. Dalam hal ini,
pengguna memiliki data mereka sendiri. kepemilikan data ini menimbulkan dua
masalah, yaitu masalah bisnis yang membangun hambatan antara unit organisasi
yang menghambat entitas data. Masalah kedua berasal dari keterbatasan dalam
teknologi manajemen yang memerlukan data yang disusun untuk kebutuhan khusus
bagi pengguna. Dengan demikian, data yang sama akan digunakan dalam cara yang
sedikit berbeda oleh pengguna yang berbeda.
Masalah lain pada pendekatan flat-file adalah ketidakmampuan pengguna
untuk mendapatkan informasi tambahan. Masalah ini disebut ketergantungan
task-data.
Sistem Manajemen
Database
Sistem ini menyediakan lingkungan yang
terkendali untuk mencegah akses pengguna pada database dan secara efisien
mengelola sumber daya data. Setiap model ini memiliki tujuan :
Pengembangan program, sistem manajemen ini berisi perangkat lunak pengembangan program.
Backup dan pemulihan.
Laporan penggunaan database.
Akses database (pemberian izin bagi pengguna yang berwenang).
Pengembangan program, sistem manajemen ini berisi perangkat lunak pengembangan program.
Backup dan pemulihan.
Laporan penggunaan database.
Akses database (pemberian izin bagi pengguna yang berwenang).
Berikut ini
adalah 3 modul software yang memfasilitasinya : Data Definition Language (DDL), Data Manipulation Language, The Query Language.
Database
Administrator
Database ini bertanggung
jawab untuk mengelola sumber daya database. Dalam organisasi yang besar, fungsi
database ini terdiri dari seluruh departemen tenaga teknis dibawah database
administrator. Dalam organisasi yang lebih kecil, seseorang dalam kelompok
pelayanan komputer mungkin bertanggung jawab pada database ini. Tugas database
administrator antara lain : Database planning, Database design, Database
implementation, Database operation and maintance dan Database change.
Database Fisik
Database fisik merupakan unsur terendah
dari database. Database fisik merupakan kumpulan dari catatan dan file. Ada dua
macam database fisik yaitu database relasional yang didasarkan pada
struktur file indeks berurutan. Dan yang kedua yaitu beberapa indeks dapat digunakan untuk membuat referensi
silang
atau disebut daftar terbalik.
Model database relasional ditemukan oleh
E.F CODD pada akhir tahun 1960an. Sistem dikatakan relasional jika: (1) Merupakan data dalam bentuk dua dimensi tabel seperti tabel database yang disebut
Pelanggan,
(2) Mendukung fungsi aljabar relasional membatasi, berproyek,
dan bergabung.
Entitas merupakan segala sesuatu yang
diharapkan organisasi dalam memperoleh data. Entitas bisa berbentuk fisik
seperti persediaan, konsumen atau karyawan, tapi bisa juga berbentuk konseptual
seperti penjualan, piutang dagang dan utang dagang. Kemudian istilah kejadian digunakan untuk menggambarkan jumlah kasus atau catatan yang berhubungan dengan entitas tertentu. Dan atribut adalah elemen data yang
mendefinisikan suatu entitas.
Asosiasi sifat dalam
model data digambarkan oleh garis berlabel yang menghubungkan dua entitas.
Asosiasi ini ditunjukkan oleh kata kerja seperti meminta dan menerima. Dan Kardinalitas adalah derajat hubungan antara dua entitas.
Tabel Database
Fisik
Tabel
database fisik yang dibangun dari model data yang berubah dengan masing-masing entitas menjadi tabel database fisik yang terpisah. Tabel database fisik
yang dirancang dengan baik memiliki empat karakteristik
berikut:
(1) Nilai dari setidaknya satu atribut di setiap kejadian
(baris) harus unik,
(2) Semua nilai atribut dalam setiap kolom harus dari kelas
yang sama,
(3) Setiap kolom dalam tabel yang diberikan harus bernama
secara unik,
(4) Tabel harus sesuai dengan aturan normalisasi.
Kaitan antara Tabel Relasional
Tabel
dihubungkan
dengan melekatkan kunci utama dalam tabel terkait
sebagai kunci asing. Dengan kunci asing, sebuah program komputer dapat dibuat untuk menyediakan data yang dibutuhkan pengguna.
Anomali, Struktur
Ketergantungan dan Data Normalisasi
Tabel harus
sesuai dengan aturan normalisasi, yaitu bebas dari ketergantungan struktural
atau anomali.
Ada 3 jenis anomali yaitu: update anomali (hasil dari
redundansi data dalam tabel yang tidak dinormalisasi), penyisipan
anomali (menunjukkan efek dari penyisipan anomali), dan penghapusan anomali (penghapusan data dari tabel). Untuk bebas dari
anomali, tabel harus dinormalisasi. Proses
normalisasi melibatkan, mengidentifikasi dan menghapus dependensi struktur dari tabel dalam
peninjauan.
tabel yang dihasilkan kemudian akan memenuhi dua kondisi
di bawah ini:
(1) Semua nonkey (data)
atribut dalam tabel tergantung pada (ditentukan oleh) kunci utama. (2) Atribut Semua nonkey independen terhadap atribut nonkey
lainnya.
Merancang Relasional Database
Bagian ini membahas
langkah-langkah yang terlibat dalam menciptakan sebuah database relasional. Adapun enam
langkahnya yang disebut model tampilan yaitu:
1.
Mengidentifikasi
entitas
Entitas direpresentasikan
sebagai kata benda
misalnya inventory, supplier, laporan. Untuk lulus sebagai
entitas yang valid, dua syarat yang harus dipenuhi:
Kondisi 1. Suatu entitas harus
terdiri dari dua atau lebih kejadian.
Kondisi 2. Suatu entitas harus berkontribusi setidaknya satu atribut
yang tidak disediakan melalui entitas lain.
2.
Membangun sebuah
model data yang menunjukkan asosiasi entitas
Langkah berikutnya adalah menentukan asosiasi antara entitas dan
mendokumentasikannya dengan diagram ER. Misalnya, asosiasi normal antara entitas Pelanggan dan entitas Penjualan adalah 1: M (atau
1: 0, M). Ini menandakan bahwa satu pelanggan dapat menempatkan banyak pesanan
selama
periode penjualan. Asosiasi
tidak akan pernah 1: 1. Ini berarti
bahwa organisasi membatasi setiap pelanggan
untuk penjualan tunggal yang tidak logis.
3.
Menambahkan kunci utama dan atribut untuk model
Analis harus memilih kunci
utama yang logis yang
mendefinisikan atribut nonkey dan mengidentifikasi setiap
kejadian dalam entitas. Kadang-kadang hal ini dapat dicapai dengan menggunakan
sekuensial sederhana
yaitu dengan memberi kode seperti Nomor Faktur atau Nomer Order Pembelian.
4.
Menormalkan model data
dan menambahkan kunci asing
Masalah-masalah normalisasi
yang dibutuhkan diuraikan dalam bagian berikut: (1) Mengulangi
Data group di Order Pembelian. Atribut Nomer, Deskripsi, Order, Jumlah Order dan Satuan Biaya mengulangi data grup. Untuk mengatasi ini, data kelompok
mengulangi tersebut dipindahkan ke PO Barang entitas baru. Entitas baru (kunci asing) adalah gabungan dari Komponen Jumlah dan Nomor PO. (2) Mengulangi Data Group di Menerima Laporan. (3) Transitif Dependensi,
Order Pembelian dan Laporan Penerimaan
Entitas berisi atribut yang berlebihan dengan data dalam Inventarisasi dan Supplier.
5.
Membangun database
fisik
Langkah
selanjutnya adalah membuat tabel fisik dan mengisi mereka dengan data. Ini
merupakan langkah yang harus direncanakan dan dilaksanakan hati-hati serta
membutuhkan waktu berbulan-bulan. Program harus ditulis untuk mentransfer data organisasi
saat ini
kemudian disimpan dalam flat file atau database warisan ke tabel relasional yang baru.
6.
Siapkan tampilan pengguna.
Langkah terakhir adalah membuat tampilan pengguna dari tabel. Perancang hanya memberitahu DBMS mengenai tabel
yang digunakan, kunci primer dan asing mereka, dan atribut yang dipilih
dari setiap tabel. DBMS membutuhkan desainer untuk menentukan tampilan
parameter langsung di SQL. Sistem melakukan ini secara visual, desainer hanya mengklik point, tabel dan atribut. Dari representasi visual ini, permintaan tersebut menghasilkan SQL
yang kemudian menghasilkan tampilan.
Pandangan
Integrasi Global
Proses dapat di lihat dari pemodelan sebelumnya yang telah dijelaskan tergolong hanya ada satu bisnis, sistem, tabel dan tampilan
yang dihasilkan hanya merupakan subschema dari skema database secara
keseluruhan.
Kombinasi kebutuhan data semua pengguna ke dalam skema tunggal
atau tampilan perusahaan disebut pandangan integrasi.
Database dalam Lingkungan Distribusi
Sebagian besar organisasi modern menggunakan
pemrosesan terdistribusi dan jaringan untuk memproses transaksi mereka. Hal
yang harus diperhatikan dalam perencanaan sistem terdistribusi adalah lokasi
database organisasi. dalam mengatasi masalah ini, perencana memiliki dua
pilihan dasar: database terpusat, atau mereka
didistribusikan. Melalui
pendekatan database terpusat, pengguna mengirim permintaan data melalui
terminal ke pusat situs, yang memproses permintaan dan mengirimkan data kembali
ke pengguna. Sedangkan database
terdistribusi dapat didistribusikan baik menggunakan teknik dipartisi atau
direplikasi.
Pendekatan database dipartisi membagi
database pusat menjadi segmen atau partisi yang distribusikan untuk pengguna
utama mereka. Keuntungan dari pendekatan ini adalah: (1) Menyimpan data di situs lokal
meningkatkan kontrol pengguna, (2) memungkinkan akses lokal ke data dan
mengurangi volume data yang harus ditransmisikan antara situasi, (3)
meningkatkan waktu respon proses transaksi, (4) database dipartisi dapat
mengurangi potensi bencana.
Deadlock
Fenomena Deadlock dalam lingkungan
terdistribusi adalah keadaan beberapa situs mengunci keluar satu sama lain,
sehingga mencegah pengolahan dari setiap transaksinya. Hal ini menyebabkan
kebuntuan yaitu kondisi permanen yang harus diselesaikan oleh perangkat lunak
khusus yang menganalisis setiap kondisi deadlock untuk menentukan solusi
terbaik.
Deadlock resolusi yaitu menyelesaikan
kebuntuan dengan melibatkan, mengorbankan satu atau lebih transaksi. beberapa
faktor yang mempengaruhi keputusan ini adalah sebagai berikut: (1) Sumber daya
saat ini diinvestasikan dalam transaksi. (2) tahap transaksi ini merupakan
suatu penyelesaian, (3) jumlah kebuntuan terkait dengan transaksi. Sedangkan
dalam beberapa organisasi, seluruh database direplikasi di setiap situs. Database
direplikasi efektif dalam perusahaan di mana berbagi data memiliki tingkat yang
tinggi tetapi tidak ada pengguna utama.
Replikasi
Database
Pembenaran utama untuk database
direplikasi adalah untuk mendukung permintaan hanya baca. Dengan data
yang direplikasi
di setiap situs, akses data untuk tujuan permintaan diminimalkan. Masalah muncul ketika situs lokal juga harus memperbarui database
direplikasi
dengan transaksi.
Database
Konkurensi
Database konkurensi adalah adanya data
yang lengkap dan akurat di semua situs terpencil.
Sebuah metode yang umum digunakan untuk kontrol
konkurensi adalah cerita bersambung transaksi. Ini melibatkan pelabelan setiap
transaksi oleh dua kriteria: (1) kelompok perangkat lunak transaksi khusus
dimasukkan ke dalam kelas untuk mengidentifikasi potensial konflik esensial,
(2) label waktu setiap transaksi.
Distribusi
Database dan Akuntan
Keputusan
untuk mendistribusikan database adalah salah satu yang harus dimasukkan ke
dalam berpikir. Beberapa pertanyaan yang paling mendasar yang harus ditangani
adalah:
Harus data organisasi terpusat atau didistribusikan? Jika distribusi data yang diinginkan, harus database direplikasi atau dipartisi? Jika direplikasi, harus database secara total direplikasi atau sebagian direplikasi? Jika database yang akan dipartisi, bagaimana seharusnya segmen data yang dialokasikan di antara situs? Pilihan yang terlibat dalam setiap pertanyaan ini mempengaruhi kemampuan organisasi untuk mempertahankan Database tegrity. Pelestarian jejak audit dan keakuratan catatan akuntansi merupakan perhatian utama.
Harus data organisasi terpusat atau didistribusikan? Jika distribusi data yang diinginkan, harus database direplikasi atau dipartisi? Jika direplikasi, harus database secara total direplikasi atau sebagian direplikasi? Jika database yang akan dipartisi, bagaimana seharusnya segmen data yang dialokasikan di antara situs? Pilihan yang terlibat dalam setiap pertanyaan ini mempengaruhi kemampuan organisasi untuk mempertahankan Database tegrity. Pelestarian jejak audit dan keakuratan catatan akuntansi merupakan perhatian utama.
Sumber:
Accounting Information System_James A Hall
Tidak ada komentar:
Posting Komentar