Pages

Sabtu, 12 Januari 2013

Pembuatan Model Data dan Design Database



1.             Proses Design Database
Database adalah sekumpulan data yang saling berhubungan. Database yang baik adalah database yang dapat memberikan informasi bagi penggunanya. Untuk memberikan informasi sesuai dengan kehendak pengguna maka diperlukan pendesaian database.

Database Design

  • ER Model digunakan dalam fase desain basis data konseptual.
  • ER model digunakan untuk mengembangkan inisial dari desain basisdata.
  • Proses desain basisdata dibagi menjadi 6 tahap, yaitu:
    1. Analisa Kebutuhan
    2. Desain Konseptual Basisdata
    3. Desain Logika basisdata
    4. Skema Perbaikan
    5. Desain Fisik Basisdata
    6. Desain Keamanan

Analisa Kebutuhan

  • Bagaimana memahami cara data disimpan dalam basisdata
  • Aplikasi yang harus dibangun
  • Operasi apa yang sering digunakan
  • Yang dapat dilakukan pada tahap ini:
    1. Diskusi kelompok user
    2. Melakukan studi terhadap lingkungan operasi dan kemungkinan perubahan yang dilakukan
    3. Analisa terhadap dokumentasi dari aplikasi yang sudah ada

Desain Konseptual Basis Data

  • Informasi dikumpulkan pada bagian analisis kebutuhan
  • Mengembangkan deskripsi dari data yang telah dikumpulkam dan disimpan dalam basisdata, meliputi: entity, relasi dan batasan integritasnya.
  • Skema basisdata dalam ER model dapat dipresentasikan dalam bentuk ER Diagram

Desain Logika

  • Mengubah desain basis konseptual basisdata kedalam skema basisdata dalam model data yang dipilih oleh DBMS.
  • Mengubah ER Diagram ke dalam skema basisdata relasional

Desain Skema Perbaikan

  • Mengidentifikasi persoalan yang akan muncul
  • Menormalisasi dengan restrukturisasi ulang untuk memastikan beberapa properti yang dikehendaki

Desain Fisik Basis Data

  • Pemberian indeks pada beberapa tabel
  • Pengelompokan beberapa tabel

Desain Keamanan

Menidentifikasi kumpulan user yang berbeda dengan peranannya masing-masing.
2. Diagram Hubungan Entitas (ERD)
Diagram Hubungan Entitas atau entity relation 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.
ERD untuk memodelkan struktur data dan hubungan antar data, untuk menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada tiga simbol yang digunakan, yaitu :
  1. Entiti
Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain (Fathansyah, 1999: 30). Simbol dari entiti ini biasanya digambarkan dengan persegi panjang.
  1. Atribut
Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips.
  1. Hubungan / Relasi
Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Relasi dapat digambarkan sebagai berikut :
Relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dalam satu basis data yaitu (Abdul Kadir, 2002: 48) :
1). Satu ke satu (One to one)
Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B.
2). Satu ke banyak (One to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A.
3). Banyak ke banyak (Many to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.
Description: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkDnCmqFQAM0GXyFaJTnamxxIKOWhBwtEkF92bkhMXtP0IiIMl9KutZFebjItJ0k5UyZ5rFtRT7ZNM2wag-C8R0F_gPYxLJLawhyEyW3leYF4dgteUu0kAfvf6v3k9rDzYeaygFBqUYy8/s400/673px-ER_Diagram_MMORPG.png


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

http://octoberplan.wordpress.com/2012/11/15/proses-desain-database/

0 komentar:

Posting Komentar