A. Proses Desain Database
Buat para Database designer atau Database Administrator (DBA) mendesain database adalah hal yang sudah biasa dilakukan, namun bagaimana buat kita-kita yang baru saja mempelajari database, atau belum pernah sama sekali mendesain database?
Maka disini saya ingin sharing bagaimana langkah-langkah yang baik dan benar untuk mendesain sebuah database:
- Analisis Persyaratan: Langkah pertama dalam mendesain sebuah aplikasi database adalah memahami dan mengetahui data yang harus disimpan di dalam database, aplikasi apa yang harus dibangun diatasnya, dan jenis operasi apa yang lebih banyak digunakan, dan subjek untuk melakukan persyaratan yang ada. Dengan kata lain, kita harus tahu apa yang diinginkan pengguna database tersebut. Biasanya ini adalah sebuah proses informal yang melibatkan partisipasi kelompok pengguna, studi tentang lingkungan pegoprasian saat ini dan bagaimana perkiraan perubahan lingkungan tersebut, analisis dokumen yang ada dalam suatu aplikasi yang diharapkan akan diganti atau dilengkapi oleh database, dan seterusnya. Banyak metodologi yang diusulkan untuk menyusun dan menampilkan informasi yang dikumpulkan pada langkah tersebut. Beberapa alat otomatis pun telah dikembangkan untuk mendukung proses ini.
- Desain Database Konseptual: Informasi dikumpulkan pada saat analisis persyaratan digunakan untuk mengembangkan deskripsi data tingkat tinggi yang harus disimpan dalam database, bersama dengan batasan yang telah diketahui untuk menetapkan penyimpanan data tersebut. Langkah ini sering dilakukan dengan menggunkan model ER. Model ER adalah salah satu dari model data tingkat tinggi, atau semantik, yang digunakan dalam desain database. Tujuannya adalah menciptakan gambaran sederhana tentang data yang mirip dengan pemikiran pengguna dan pengembang mengenai data tersebut (orang dan proses yang dinyatakan dalam data tersebut). Hal tersebut menfasilitasi diskusi di antara orang-orang yang terlibat dalam proses desain, bahkan mereka yang tidak mempunyai latar belakang teknis. Pada saat yang sama, desain awal harus akurat untuk membantu ketapatan translasi ke dalam sebuah model data yang didukung oleh sistem database komersial (yang dalam prakteknya berarti model relasional).
- Desain Database Logika: Kita harus memilih sebuah DBMS untuk mengimplementasikan desain database kita, dan mengubah konsep desain database menjadi sebuah skema database dalam model data dari DBMS terpilih. Kitah hanya akan memperhatikan DBMS relasional, dan dengan demikian tugas desain logika adalah mengubah skema ER menjadi skema database relasional.
- Perbaikan Skema: Langkah keempat dalam desain dataase adalah analisis sekumpulan relasi dalam skema database relasional untuk mengidentifikasi permasalahan yang muncul, dan memperbaikinya. Berbeda dengan alaisis persyaratan dan langkah-langkah desain konseptual, yang secara esensial bersifat subjektif, perbaikan skema dapat dipandu oleh beberapa teori yang kuat dan bagus. Langkah keempat ini, para akademis IT lebih sering disebut dengan Normalisasi.
- Desain Database Fisik: pada langkah ini, kita juga mempertimbagkan beban kerja umum yang diharapkan dapat didukung oleh datagbase kita dan memperbaiki deswain database di masa mendatang untuk memastikan terpenuhinya kriteria performa yang diinginkan. Langkah ini hanya mencakup pembuatan indeks pada beberapa tabe dan mengelompokkan beberapa tabel, atau bahkan melibatkan desain ulang yang substansial terhadap beberapa bagian skema database yang didapat dari langkah pertama desain database.
- Desain Aplikasi dan Keamanan: Semua proyek perangkat lunak yang melibatkan sebuah DBMS harus mempertimbangkan aspek aplikasi yang berada di luar database itu sendiri. Metodologi desain seperti UML mencoba menekankan desain perangkat lunak dan siklus pengembangan yang lengkap. Secara singkat, kita harus bisa mengidentifikasi entitas (contohnya 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. Untuk tiap peran, kita harus bisa mengidentifikasi bagian database yang harus bisa diakses dan yang tidak bisa diakses, dan kitah harus bisa menganmbil langkah untuk memastikan bahwa aturan akses terseut dilakukan. DBMS memberikan beberapa mekanisme untuk membantu langkah tersebut.
Demikianlah langkah-langkah desain database yang harus kita lakukan jika kita ingin membangun sebuah database yang baik dan benar. Secara realistis, meskipun kita mulai dari proses 6 langkah diatas, sebuah desain database yang lengkap mungkin akan memerlukan sebuah fase tuning (penyesuaian) sesudah itu sampai desain tersebut memuaskan.
B. Diagram Hubungan Entitas (Entity Relationship)
Desain database juga termasuk ER ( Entity-model hubungan ) diagram. Diagram ER diagram yang membantu untuk merancang database dalam cara yang efisien.
Atribut dalam diagram ER biasanya dimodelkan sebagai oval dengan nama atribut, terkait dengan entitas atau hubungan yang berisi atribut.
Dalam model relasional langkah terakhir secara umum dapat dibagi menjadi dua langkah lebih lanjut, bahwa untuk menentukan pengelompokan informasi dalam sistem, umumnya menentukan apa benda dasar tentang mana informasi disimpan, dan kemudian menentukan hubungan antara kelompok-kelompok informasi, atau benda. Langkah ini tidak diperlukan dengan Obyek database .
-Model ER = kumpulan konsep dari entitas, atribut, relationship serta konstrain lainnya yg menggambar kan struktur basis data dan transaksi pada basis data
-Relationship = Hubungan yang terjadi antara satu entitas atau lebih.
Contoh, relationship mengambil yang menggambarkan mahasiswa yang mengambil matakuliah.
C.Model data area (relationship ,even ,agen)
Pengertian Resource Event Agent (REA)
sumber daya, Acara, Agen (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.
-Relationship = Hubungan yang terjadi antara satu entitas atau lebih.
Contoh, relationship mengambil yang menggambarkan mahasiswa yang mengambil matakuliah.
C.Model data area (relationship ,even ,agen)
Pengertian Resource Event Agent (REA)
sumber daya, Acara, Agen (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.
D. Struktur dari E-R Diagram secara umum ialah terdiri dari:
• Entitas merupakan objek utama yang informasi akan disimpan, biasanya berupa kata benda, ex; Mahasiswa, Dosen, Nasabah, Mata Kuliah, Ruangan, dan lain-lain. Objek dapat berupa benda nyata maupun abstrak.
• Atribut merupakan deskripsi dari objek yang bersangkutan.
• Relationship merupakan suatu hubungan yang terjalin antara dua entitas yang ada.
Dibawah ini adalah sebuah contoh ERD :
Keterangan :
• Nomor Account dan sisa uang merupakan suatu atribut yang mendeskripsikan entitas account.
• Nasabah sebagai entitas dideskripsikan oleh atribut nama dan alamat.
• Account dan nasabah sebagai entitas memiliki relasi yang dihubungkan oleh cust_acc yang memiliki atribut tanggal transaksi suatu nasabah terhadap accountnya.
• Entitas merupakan objek utama yang informasi akan disimpan, biasanya berupa kata benda, ex; Mahasiswa, Dosen, Nasabah, Mata Kuliah, Ruangan, dan lain-lain. Objek dapat berupa benda nyata maupun abstrak.
• Atribut merupakan deskripsi dari objek yang bersangkutan.
• Relationship merupakan suatu hubungan yang terjalin antara dua entitas yang ada.
Dibawah ini adalah sebuah contoh ERD :
Keterangan :
• Nomor Account dan sisa uang merupakan suatu atribut yang mendeskripsikan entitas account.
• Nasabah sebagai entitas dideskripsikan oleh atribut nama dan alamat.
• Account dan nasabah sebagai entitas memiliki relasi yang dihubungkan oleh cust_acc yang memiliki atribut tanggal transaksi suatu nasabah terhadap accountnya.
E. Contoh kasus database REA
model REA adalah suatu alat pemodelan konseptual yang khusus dirancang untukmelengkapi struktur dalam perancangan database SIA. Dalam model REA ditentukan:
entity apa yang harus disertakan dalam database SIA dan bagaimana susunan
relationship antara entity dalam database SIA.
Tipe entity dalam model REA dibedakan dalam tiga kategori, yaitu: Resources,
Events, dan Agents. Resources didefinisikan sebagai sesuatu yang memiliki nilai
ekonomis bagi organisasi tersebut. Contoh resources adalah kas, inventaris, peralatan,
persediaan, gudang, pabrik, dan tanah. Events menunjukkan aktivitas-aktivitas bisnis,
dimana manajemen ingin mengumpulkan informasi untuk tujuan perencanaan atau
pengawasan. Sebagai contoh, aktivitas penjualan akan mengurangi persediaan dan
aktivitas penerimaan kas akan menambah jumlah kas. SIA harus dirancang untuk
memperoleh dan menyimpan informasi aktivitas tersebut. Sedangkan Agents adalah
orang dan organisasi yang berpartisipasi dalam aktivitas dan kepada siapa informasi
diserahkan untuk tujuan perencanaan, pengawasan, dan pengevaluasian. Contoh agent
adalah pengawai, pelanggan, dan pemasok.
Model REA dapat dilihat pada Gambar 8. Setiap entity event dihubungkan dengan
entity resources yang berpengaruh secara langsung atau tidak langsung. Setiap entity
event juga dihubungkan dengan dua entity agent. Internal agent adalah pegawai yang
bertanggung jawab pada resources yang terlibat dalam event. Sedangkan external
agent adalah pihak luar yang berhubungan dengan transaksi. menunjukkanevent yang mengubah jumlah resource dihubungkan dengan relationship give-to-get ke
event lain yang juga mengubah jumlah resources. Relationship give-to-get
mencerminkan prinsip dasar bisnis, dimana organisasi yang menggunakan resources
dalam aktivitas diharapkan dapat mengubah resource yang lain
Contoh kasus proses pembuatan database pencatatan keuangan sebuah depertemenstore dengan menggunakan R.E.A
