Pembuatan Model Data
dan Design Database
1.
Proses Design Database
Dalam perancangan/mendesain
sebuah database agar menjadi database yang handal dan tangguh, ada beberapa
langkah yang perlu dilakukan. Langkah-langkah tersebut diantaranya :
1. Analisis
Persyaratan
Langkah pertama dalam
mendesain sebuah aplikasi database adalah memahami dan mengetahui data yang
harus disimpan dalam database, aplikasi apa yang harus dibangun diatasnya, dan
jenis operasi apa yang lebih banyak digunakan dan subyek untuk melakukan
persyaratan yang ada, atau dengan kata lain, kita harus tau apa yang diinginkan
pengguna database tersebut.
2. Desain Database Konseptual
Informasi dikumpulkan pada
saat analisis persyaratan digunakan untuk mengembangkan deskripsi data tingkat
tinggi yang harus disimpan dalam database bersama batasan yang telah diketahui
untuk menetapkan penyimanan data tersebut.. Dalam langkah inilah entitas,
atribut dan batasanya yang terlibat dalam desain aplikasi database ditentukan.
Langkah ini sering dilakukan dengan model ER
Diagram.
3. Desain Database Logika
Dalam langkah ini adalah
menentukan/memilih DBMS yang akan digunakan untuk mengimplementasikan desain
database dan mengubah konsep desain database menjadi sebuah skema database
dalam model data dari DBMS terpilih. Dalam langkah ini merupakan proses
perubahan dari skema ER Diagram menjadi skema Database Relasional (RDBMS)
4. Perbaikan Skema
Menganalisis sekumpulan relasi
dalam skema database relasional (RDBMS) untuk mengidentifikasi permasalahan
yang muncul dan memperbaikinya
5. Desain Database Fisik
Pada langkah ini dilakukan
pertimbangan-pertimbangan beban kerja umum yang diharapkan dapat didukung oleh
database yang kita gunakan dan memperbaiki desain database di masa mendatang
untuk memastikan terpenuhinya kriteria performa yang diinginkan. Langkah ini
mencakup pembuatan indeks pada beberapa tabel dan mengelompokan beberapa tabel
atau bahkan melibatkan desain ulang substansial terhadap beberapa bagian skema
database yang didapat dari langkah pertama desai database.
6. Desain Aplikasi dan Keamanan
Setiap proyek perangkat lunak
yang melibatkan sebuah DBMS harus mempertimbangkan aspek aplikasi yang berada
di luar database itu sendiri. Dalam hal ini kita harus
mengidentifikasi entitas (ex; pengguna, grup-grup pengguna dan bagian-bagian
lain) dan proses-proses yang terlibat dalam aplikasi. Kita harus menggambarkan
peran setiap entitas dalam setiap proses yang akan direfleksikan pada beberapa
tugas aplikasi, sebagai bagian dari aliran kerja lengkap untuk tugas tersebut.
Selanjutnya adalah fase
implementasi, kita harus mengkodekan tiap tugas ke dalam sebuah bahasa aplikasi
(ex: java), menggunakan DBMS untuk mengakses data.
2. Diagram Hubungan Entitas
Diagram Hubungan
Entitas atau entity relationship
diagram merupakan model data berupa notasi grafis dalam pemodelan data konseptual yang menggambarkan hubungan antara
penyimpan. Model data sendiri merupakan sekumpulan cara, peralatan untuk
mendeskripsikan data-data yang hubungannya satu sama lain, semantiknya, serta
batasan konsistensi. Model data terdiri dari model hubungan entitas dan model
relasional. Diagram hubungan entitas ditemukan oleh Peter Chen dalam buku Entity Relational
Model-Toward a Unified of Data.
Chen mencoba merumuskan dasar-dasar model dan setelah itu dikembangkan dan dimodifikai
oleh Chen dan banyak pakar lainnya. Pada saat itu diagram hubungan entitas
dibuat sebagai bagian dari perangkat lunak yang juga merupakan modifikasi khusus, karena
tidak ada bentuk tunggal dan standar dari diagram hubungan entitas.
3.
Model Data REA
Adalah model
bagaimana sebuah sistem akuntansi dapat kembali direkayasa untuk usia komputer.
REA awalnya diusulkan pada tahun 1982 oleh William E. McCarthy sebagai model akuntansi
umum, dan berisi konsep sumber daya, peristiwa dan agen.
REA adalah
model yang populer dalam sistem informasi pengajaran akuntansi (AIS). Tapi ini
jarang terjadi pada praktik bisnis-perusahaan tidak dapat dengan mudah
membongkar sistem warisan mereka untuk memenuhi tuntutan radikal REA's.
Model REA
menghilangkan objek akuntansi banyak yang tidak diperlukan dalam usia komputer.
Yang paling terlihat dari ini adalah debit dan kredit-double-entry pembukuan
menghilang dalam sistem REA. Banyak buku besar umum juga menghilang, setidaknya
sebagai obyek persisten, - misalnya, piutang atau hutang. Komputer dapat
menghasilkan account tersebut secara real time menggunakan catatan sumber
dokumen.
REA
memperlakukan sistem akuntansi sebagai representasi virtual bisnis yang
sebenarnya. Dengan kata lain, itu menciptakan objek komputer yang langsung
mewakili benda nyata dunia bisnis. Dalam istilah ilmu komputer, REA adalah
suatu ontologi. Objek nyata termasuk dalam model REA adalah:
* Barang, jasa
atau uang, yaitu, SUMBER DAYA
* Transaksi
bisnis atau perjanjian yang mempengaruhi sumber daya, yaitu, KEJADIAN
* Orang atau
badan-badan manusia lain (perusahaan lain, dll), yaitu, AGEN
Ini kontras
objek dengan istilah akuntansi konvensional seperti aktiva atau kewajiban, yang
kurang langsung terkait dengan objek dunia nyata. Sebagai contoh, aset
akuntansi konvensional seperti goodwill tidak sumber REA.
Ada model REA
terpisah untuk setiap proses bisnis di perusahaan. Sebuah proses bisnis secara
kasar sesuai dengan departemen fungsional, atau fungsi dalam rantai nilai
Michael Porter. Contoh dari proses bisnis akan penjualan, pembelian, konversi
atau manufaktur, sumber daya manusia, dan pendanaan.
Di jantung
masing-masing model REA biasanya ada sepasang peristiwa, dihubungkan oleh
hubungan pertukaran, biasanya disebut sebagai hubungan "dualitas".
Salah satu peristiwa biasanya merupakan sumber daya yang diberikan atau hilang,
sementara yang lain merupakan sumber daya yang diterima atau diperoleh. Sebagai
contoh, dalam proses penjualan, satu peristiwa akan "penjualan"-di
mana barang diberikan up-dan yang lain akan "penerimaan kas", dimana
kas diterima. Kedua peristiwa yang terkait, yaitu sebuah penerimaan kas terjadi
dalam pertukaran untuk penjualan, dan sebaliknya. Hubungan dualitas dapat lebih
kompleks, misalnya, dalam proses manufaktur, maka akan melibatkan lebih dari
dua peristiwa (lihat Dunn et al [2004] untuk contoh.).
REA sistem
biasanya dimodelkan sebagai database relasional, meskipun hal ini tidak wajib.
Desain biasanya menggunakan diagram entitas-hubungan. Filosofi dari REA mengacu
pada gagasan Pola Desain dapat digunakan kembali, meskipun pola REA digunakan
untuk menggambarkan database daripada program berorientasi objek, dan sangat
berbeda dari 23 pola kanonik dalam buku pola desain asli oleh Gamma et al.
(Yang tidak mengherankan karena Gamma et al. Pola benar-benar penerapan pola
untuk berkeliling kekurangan dalam C + + bukan dari pola desain per se).
Penelitian di REA menekankan pola (misalnya, Hruby et al. 2006). Berikut adalah
contoh pola REA dasar :
Pola ini
diperluas untuk mencakup komitmen (janji untuk terlibat dalam transaksi,
misalnya, seorang sales order), kebijakan, dan konstruksi. Dunn et al. (2004)
memberikan gambaran yang baik pada tingkat sarjana (untuk jurusan akuntansi),
sementara Hruby et al. (2006) adalah sebuah referensi canggih untuk ilmuwan
komputer.
REA pengaruh
berkelanjutan terhadap standar electronic commerce ebXML, dengan W. McCarthy
secara aktif terlibat dalam komite standar. Standar XBRL GL bersaing namun
adalah bertentangan dengan konsep REA, karena erat meniru double-entry
pembukuan.
4. Proses Membangun Data REA dalam Siklus Transaksi
Membangun diagram REA untuk
siklus transaksi tertentu terdiri dari empat langkah berikut :
1. Identifikasi pasangan kegiatan pertukaran ekonomi yang
mewakili hubungan dualitas dasar memberi untuk menerima, dalam siklus tersebut.
2. Identifikasi sumber daya yang dipengaruhi oleh setiap
kegiatan pertukaran ekonomi dan para pelaku yang terlibat dalam kegiatan
tersebut.
3. Analisis setiap kegiatan pertukaran ekonomi untuk
menetapkan apakah kegiatan tersebut harus dipecah menjadi suatu kombinasi dari
satu atau lebih kegiatan komitmen dan kegiatan pertukaran ekonomi. Apabila
perlu, ganti kegiatan pertukaran ekonomi aslinya dengan rangkaian kegiatan komitmen
dan pertukaran ekonomi yang dihasilkan dari pemecahan kegiatan tadi.
4. Tetapkan kardinalitas setiap hubungan.
Tidak ada komentar:
Posting Komentar