Pembuatan Model Data dan Desain Database

Seperti kebanyakan perusahaan pada umumnya, sebuah perusahaan harus berubah ke pendekatan database untuk menyimpan data akuntansinya. Di dalam pembahasan ini, Akan diperlihatkan bagaimana cara mendesain dan mendokumentasikan database relasional untuk suatu sistem informasi akuntansi. Akan diperlihatkan bahwa masih ada banyak hal untuk dipelajari selain hanya mempelajari sintaksis tentang bagaimana menggunakan suatu DBMS tertentu. Membangun database yang akurat membutuhkan banyak perencanaan yang hati-hati dan desain, bahkan sebelum perancang data base duduk di depan komputer.

data-model-er1Pembahasan berikut ini memusatkan perhatian pada pembuatan model data, yang merupakan salah satu aspek desain database yang harus dipahami para akuntan. Pembahasan ini akan memperkenalkan model akuntansi REA(Resourse Event Agent) dan diagram E-R, serta menunjukkan bagaimana mempergunakan alat-alat ini untuk membangun sebuah model data SIA.

Kemudian, Pembahasan berikutnya akan mendeskripsikan bagaimana mengimplementasikan hasil model data dalam database relasional. Ingatlah selalu bahwa walaupun diskusi memusatkan perhatian pada database relasional, prinsip-prinsipnya tetap dapat diterapkan pada jenis database apa pun.

datamodel-urlPembahasan menyeluruh tentang Pembuatan Model Data dan Desain Database meliputi:

Proses Desain Database.

Gambar DD-1Gambar-5-0001-a

Gambar DD-1 memperlihatkan enam langkah dasar dalam mendesain database.

Tahap pertama terdiri dari perencanaan awal untuk menetapkan kebutuhan dan kelayakan pengembangan sistem baru. Tahap ini mencakup penilaian awal mengenai proposal kelayakan teknologi dan ekonomi.

Tahap kedua mencakup identifikasi kebutuhan informasi para pemakai, menetapkan lingkup sistem baru yang diajukan, serta menggunakan informasi yang berkaitan dengan perkiraan jumlah pemakai dan volume transaksi, untuk membantu Anda membuat keputusan awal mengenai persyaratan hardware dan software.

Tahap ketiga mencakup pengembangan berbagai skema berbeda untuk sistem yang baru, pada tingkat konseptual, eksternal, dan internal.

Tahap keempat mencakup penerjemahan skema tingkat internal ke struktur database sesungguhnya, yang akan diimplementasikan ke dalam sistem yang baru tersebut. lni juga merupakan tahap pengembangan aplikasi baru.

Tahap kelima, (implementasi) mencakup seluruh aktivitas yang berhubungan dengan mentransfer data dari sistem sebelumnya ke database SIA yang baru, menguji sistem yang baru, dan melatih para pegawai mengenai cara penggunaarmya.

Tahap keenam, atau tahap terakhir berkaitan dengan penggunaan dan pemeliharaan sistem yang baru. Tahap ini mencakup pengawasan yang hati-hati atas kinerja sistem baru dan kepuasan pemakai, untuk menetapkan kebutuhan untuk meningkatkan dan memodifikasi sistem.

Oleh sebab itu, perubahan dalam strategi dan praktik bisnis atau perkembangan baru yang signifikan dalam teknologi informasi, akan memprakarsai penyelidikan atas kelayakan pengembangan suatu sistem baru. Jadi, seluruh proses di atas akan diulang kembali (lihatlah anak panah yang kembali ke tahap perencanaan).

Peran Akuntan dalam Proses Desain Database.

Para akuntan dapat dan seharusnya berpartisipasi dalam seluruh tahapan proses desain database, walaupun tingkat keterlibatan mereka dalam setiap tahap akan bervariasi.

Accountant-aPada tahap perencanaan, akuntan menyediakan informasi yang digunakan untuk mengevaluasi kelayakan proyek yang diajukan, dan juga terlibat dalam membuat keputusan mengenai hal tersebut.

Di dalam analisis mengenai persyaratan dan tahap desain, akuntan berpartisipasi dalam mengidentifikasi kebutuhan informasi pemakai, mengembangkan skema logis, mendesain kamus data (data dictionary), serta menentukan pengendalian.

accountabtAkuntan dengan keahlian SIA yang baik dapat berpartisipasi dalam tahap pengkodean (coding).

Selama tahap implementasi, akuntan dapat membantu menguji keakuratan database yang baru tersebut dan program aplikasi yang akan menggunakan data tersebut.

Terakhir, akuntan menggunakan sistem database untuk memproses transaksi, dan kadang-kadang bahkan membantu mengelolanya.

Peran Akuntan dalam Proses Pembuatan Model Data.

accountabtAkuntan dapat menyumbangkan nilai yang besar bagi organisasi mereka dengan cara bertanggung jawab atas pembuatan model data. Pembuatan model data (data modeling) adalah proses menyusun database, agar database tersebut benar-benar mewakili seluruh aspek organisasi, termasuk interaksi organisasi dengan lingkungan eksternal.

Gambar DD-1

Gambar-5-0001-aSeperti yang diperlihatkan dalam Gambar DD-1, pembuatan model data terjadi baik selama tahap analisis persyaratan maupun pada tahap desain.

Dua alat penting yang dapat dipergunakan oleh akuntan untuk memungkinkan keterlibatan dalam pembuatan model data adalah diagram E-R dan model data REA.

Diagram Hubungan Entitas (Entity Relationship Diagram)

Diagram hubungan-entitas (entity-relationship) merupakan suatu teknik grafis yang menggambarkan skema database. Disebut sebagai diagram E-R karena diagram tersebut menunjukkan berbagai entitas yang dimodelkan, serta hubungan antar-entitas tersebut. Entitas (entity) adalah segala sesuatu yang informasinya ingin dikumpulkan dan disimpan oleh organisasi. Di dalam diagram E-R, entitas muncul dalam bentuk persegi panjang, sedangkan hubungan antar-entitas diwakili oleh bentuk wajik.

ERD-imagesSebagai contoh, diagram E-R di bagian atas Gambar DD-2 memperlihatkan bahwa sehagian besar organisasi mengumpulkan dan memelihara informasi mengenai transaksi bisnisnya seperti pesanan pelanggan, penjualan, serta penerimaan tunai/kas. Diagram di bagian bawah gambar tersebut memperlihatkan bahwa diagram E-R dapat dibuat untuk tujuan apa pun, seperti untuk membuat model komponen-komponen yang penting dalam olah raga.

Diagram E-R tidak hanya menunjukkan isi dari suatu database, tetapi juga secara grafis merupakan model suatu organisasi. Jadi, diagram E-R dapat dipergunakan tidak hanya untuk mendesain database, tetapi juga untuk mendokumentasikan dan memaharni database yang telah ada, serta untuk mengubah secara total proses bisnis. pembahasan ini akan memusatkan perhatian pada cara penggunaan diagram E-R untuk mendesain database, serta untuk memahami isi database yang telah ada.

Gambar DD-2

Gambar-5-0002-aSeperti yang diperlihatkan di dalam Gambar DD-2, diagram E-R dapat terdiri dari berbagai jenis entitas dan hubungan antar-entitas. Oleh sebab itu, langkah yang penting dalam mendesain database termasuk pula proses memutuskan entitas mana yang perlu dibuat modelnya. Model data REA(Resource Event Agent) dipergunakan tuntuk mengambil keputusan mengenai hal semacam ini.

Pola Dasar REA (Basic REA Template)

Model data REA menetapkan pola dasar tentang bagaimana ketiga jenis entitas (sumber daya, kegiatan, dan pelaku) seharusnya berhubungan satu sama lain. Gambar DD-4 menyajikan pola dasar ini.

Setiap entitas kegiatan dihubungkan ke sebuah entitas sumber daya. Kegiatan, seperti penjualan barang dagangan, yang mengubah jumlah suatu sumber daya dihubungkan ke sumber daya itu sendiri melalui hubungan yang disebut dengan hubungan arus barang (stock flow relationship).

Kegiatan lainnya, seperti menerima pesanan pelanggan, yang mewakili komitmen di masa mendatang, dihubungkan ke sumber daya melalui hubungan cadangan (reserve relationship). Setiap entitas kegiatan juga dihubungkan dengan dua entitas pelaku. Pelaku internal adalah pegawai yang bertanggung jawab atas sumber daya yang dipengaruhi oleh kegiatan tersebut; pelaku eksternal adalah pihak luar dalam transaksi tersebut.

Gambar DD-4
Gambar-5-0004-aa

Model Data REA.

Model data REA (Resource Event Agent)secara khusus dipergunakan dalam desain database SIA sebagai alat pembuatan model konseptual yang fokus pada aspek semantik bisnis yang mendasari aktivitas rantai nilai suatu organisasi.

Gambar DD-3

Gambar-5-0003-aModel data REA(Resource Event Agent) memberikan petunjuk dalam desain database dengan cara mengidentifikasi entitas apa yang seharusnya dimasukkan ke dalam database SIA, dan dengan cara menentukan bagaimana membuat struktur antar entitas dalam database tersebut.

Jenis-jenis Entitas dalam REA.

Model data REA(Resource Event Agent) mengklasifikasi entitas ke dalam tiga kategori, yaitu: sumber daya (resource) yang didapat dan dipergunakan organisasi, kegiatan (event) atau aktivitas bisnis yang dilakukan organisasi, dan pelaku (agent) yang terlibat dalam kegiatan tersebut. Gambar DD-3 memberikan contoh mengenai ketiga entitas ini.

Gambar DD-3

Gambar-5-0003-aSumber daya (resource) adalah hal-hal yang memiliki nilai ekonomi bagi organisasi. Di dalam Gambar DD-3, kas dan persediaan adalah entitas sumber dayanya. Mesin dan perlengkapan, pasokan, gudang, pabrik, dan tanah adalah contoh-contoh sumber daya organisasional umum lainnya.

Kegiatan (event) adalah berbagai aktivitas bisnis yang informasinya ingin dikumpulkan perusahaan untuk tujuan perencanaan dan pengendalian. Terdapat dua entitas kegiatan dalam Gambar DD-3: penjualan dan tanda terima kas.

Pelaku (agent) adalah entitas jenis ketiga dalam model REA. Pelaku adalah orang-orang dan organisasi yang terlibat dalam kegiatan yang informasinya ingin didapatkan untuk tujuan perencanaan, pengendalian, dan evaluasi.

Gambar DD-3 berisi dua jenis entitas pelaku, yaitu: pegawai (staf penjualan dan kasir) serta pelanggan. Pemasok (atau penyedia barang/vendor) adalah jenis-jenis pelaku lainnya yang akan muncul dalam diagram REA untuk siklus pengeluaran (expenditure).

Peran Model Data REA dalam Rantai Nilai Organisasi.

Model data REA membantu orang mendesain database yang mendukung manajemen kegiatan rantai nilai organisasi. Oleh sebab itu, sebagian besar kegiatan dalam model data REA termasuk dalam satu dari dua kategori, yaitu: pertukaran ekonomi dan komitmen.

economic-exchange-urlPertukaran ekonomi (economic exchange) adalah kegiatan rantai nilai yang secara langsung mempengaruhi jumlah sumber daya. Sebagai contoh, kegiatan penjualan akan menurunkan jumlah persediaan, dan kegiatan penerimaan kas akan meningkatkan jumlah kas.

commitment-urlKomitmen mewakili janji untuk melakukan pertukaran ekonomi di masa mendatang. Sebagai contoh, pesanan pelanggan adalah komitmen yang mengarah pada penjualan di masa mendatang. Sering kali komitmen semacam ini merupakan awal yang dibutuhkan untuk adanya pertukaran ekonomi selanjutnya.

Manajemen juga perlu melacak komitmen untuk tujuan perencanaan. Sebagai contoh, perusahaan manufaktur sering kali menggunakan, informasi dari pesanan pelanggan untuk merencanakan produksi.

REA dan Kegiatan Pertukaran Ekonomi.

Gambar DD-3Gambar-5-0003-a

Gambar DD-4 juga memperlihatkan bahwa setiap kegiatan pertukaran ekonomi (economic exchange) dihubungkan dalam hubungan dualitas memberi-untuk-menerima (give-to-get) dengan kegiatan pertukaran ekonomi lainnya.

Gambar DD-4

Gambar-5-0004-aaHubungan-hubungan dualitas ekonomi ini mencerminkan prinsip dasar bisnis, yaitu organisasi umumnya terlibat dalam aktivitas yang mempergunakan sumber daya hanya jika ada harapan untuk memperoleh sumber daya lain sebagai gantinya. Contohnya, dalam kegiatan penjualan, yang membutuhkan penyerahan (penurunan) persediaan, dihubungkan dengan kegiatan penerimaan kas, yang membutuhkan pendapatan (peningkatan) jumlah kas.

Gambar DD-5

Gambar-5-0005-aaBahkan, Gambar DD-5 memperlihatkan bahwa setiap siklus akuntansi dapat dideskripisikan berdasarkan hubungan dualitas memberi-dan-menerima semacam ini.

Gambar DD-3 hingga DD-5 memperlihatkan bahwa model data REA dapat ditunjukkan dengan menggunakan diagram E-R.

Membangun Diagram REA untuk satu Siklus Transaksi.

Gambar DD-6Gambar-5-0006-aa

Gambar DD-6 memperlihatkan diagram REA yang dibuat untuk siklus pendapatan (revenue cycle). Pembahasan ini menjelaskan bagaimana membangun diagram semacam itu. Ingatlah selalu bahwa Gambar DD-6 hanya merupakan model dari salah satu rangkaian dari seluruh aktivitas bisnis perusahaan.

Perancang Database hanya perlu meningkatkan model dasar ini untuk mendesain SIA perusahaan secara keseluruhan. Akan tetapi, perancang database juga harus membangun model yang hampir sama untuk siklus transaksi lainnya, dan kemudian mengintegrasikan diagram-diagram terpisah tersebut ke dalam sebuah model pada tingkat perusahaan.

fourstepsMembangun diagram REA untuk siklus transaksi tertentu terdiri dari empat langkah berikut:

  1. Langkah-1: Identifikasi pasangan kegiatan pertukaran ekonomi yang mewakili hubungan dualitas dasar memberi-untuk-menerima, dalam siklus tersebut.
  2. Langkah-2: Identifikasi sumber daya yang dipengaruhi oleh setiap kegiatan pertukaran ekonomi dan para pelaku yang terlibat dalam kegiatan tersebut.
  3. Langkah-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. Langkah-4: Tetapkan kardinalitas (cardinalities) setiap hubungan.

Langkah 1: Identifikasi Kegiatan Pertukaran Ekonomi dalam Membangun Diagram REA untuk satu Siklus Transaksi.

Gambar DD-4Gambar-5-0004-aa
Gambar DD-4 memperlihatkan bahwa pola dasar REA terdiri dari sepasang kegiatan, satu kegiatan meningkatkan beberapa sumber daya, dan kegiatan satunya menurunkan beberapa sumber daya. Pertukaran ekonomi dasar dalam siklus pendapatan melibatkan penjualan barang dagangan atau pelayanan, serta serangkaian penerimaan kas sebagai pembayaran dalam penjualan tersebut.

Jadi, Perancang database mulai menggambar diagram REA untuk siklus pendapatan perusahaan dengan membuat entitas kegiatan penjualan dan penerimaan kas dalam bentuk persegi panjang, dan hubungan dualitas ekonomi antara mereka, dalam bentuk wajik.

dtbase-designer-urlSelama menggambar diagram REA untuk suatu siklus transaksi, sangatlah berguna untuk membagi kertas yang digunakan untuk menggambar ke dalam tiga kolom, satu kolom untuk setiap jenis entitas. Pergunakan kolom kiri untuk sumber daya, kolom tengah untuk kegiatan, dan kolom kanan untuk pelaku.

Kemudahan untuk membaca diagram dapat ditingkatkan apabila entitas kegiatan digambar dari atas ke bawah, sesuai dengan urutan kejadiannya. Jadi, perancang database mulai membuat Gambar DD-6 dengan memperlihatkan entitas penjualan di atas entitas kegiatan tanda terima kas, di dalam kolom tengah kertasnya.
Gambar DD-6Gambar-5-0006-aa

Langkah 2: Identifikasi Sumber Daya dan Pelaku dalam Membangun Diagram REA untuk satu Siklus Transaksi.

Ketika kegiatan yang menjadi pusat perhatian telah ditentukan, sumber daya yang dipengaruhi oleh kegiatan tersebut perlu diidentifikasi. Melanjutkan contoh sebelumnya, Perancang database mengamati bahwa kegiatan penjualan dapat diterjemahkan menjadi pemberian persediaan kepada pelanggan, dan bahwa kegiatan penerimaan kas dapat diterjemahkan sebagai menerima kas dari pelanggan. Oleh sebab itu, perancang database menambahkan entitas persediaan dan kas di dalam kolom sumber daya, serta menggambar hubungan arus barang antara kedua entitas tersebut dan kegiatan yang mempengaruhi keduanya.

AR-urlBagaimana dengan piutang? Piutang tidak dimodelkan sebagai entitas terpisah karena piutang bukanlah objek yang independen. Sebaliknya, piutang hanya mewakili perbedaan waktu antara dua kegiatan, yaitu: penjualan dan penerimaan kas. Piutang hanya mewakili penjualan yang pembayarannya belum diterima dari pelanggan. Konsekuensinya, apabila data mengenai penjualan dan penagihan kas telah disimpan di dalam database, seluruh informasi yang dibutuhkan untuk menghitung piutang dapat diambil dari informasi yang disimpan mengenai kedua kegiatan tersebut.

Setelah menentukan sumber daya yang dipengaruhi oleh setiap kegiatan, langkah selanjutnya yang perlu dilakukan adalah mengidentifikasi pelaku yang terlibat dalam kegiatan-kegiatan tersebut. Paling tidak selalu terdapat satu pelaku internal (pegawai) dan, di sebagian besar kondisi, seorang pelaku eksternal (pelanggan atau penyedia barang/vendor) yang terlibat dalam setiap kegiatan. Di dalam kasus siklus pendapatan PERUSAHAAN, pelanggan dan staf penjualan terlibat daiam kegiatan penjualan. Jadi, Perancang database memasukkan tiga entitas pelaku dalam diagram REA siklus pendapatan PERUSAHAAN, yaitu: staf penjualan, pelanggan, dan kasir. Perancang database kemudian menambahkan hubungan untuk mengindikasikan pelaku mana yang terlibat dalam suatu kegiatan. Demi menghindari kekacauan, perancang database tidak menggambar berulang-ulang entitas pelanggan.

Gambar DD-6Gambar-5-0006-aa
Merupakan hal yang penting untuk dipahami bahwa pelaku dalam model data REA mewakili fungsi, bukan mewakili orang tertentu. Jadi, di dalam Gambar DD-6, Perancang database membuat model entitas staf penjualan dan pelanggan, sebagai entitas terpisah. Akan tetapi, mungkin saja bahwa orang yang sama melakukan kedua peran entitas tersebut. Contohnya, di dalam penjualan tunai, staf penjualan juga dapat bertindak sebagai kasir dan menagih pembayaran dari pelanggan. Akan tetapi, dalam diagram REA akan tetap dimasukkan dua pelaku sebagai model situasi ini.

Akhirnya, Perancang database mempertimbangkan apakah perancang database perlu menambahkan hubungan lain antar-entitas. Model REA mensyaratkan bahwa setiap kegiatan dihubungkan paling tidak ke satu sumber daya, dan paling tidak dua pelaku. Informasi semacam ini memerlukan tambahan informasi dari wawancara dengan pihak manajemen, untuk mengidentifikasi kemungkinan hubungan lainnya. Contohnya, apabila organisasi mmgarahkan seorang pelanggan ke staf penjualan tertentu untuk menyediakan pelayanan yang sama, maka hubungan langsung antara kedua entitas tersebut (staf penjualan dan pelanggan) akan ditambahkan dalam diagram. Perancang database memutuskan bahwa perancang database tidak perlu memasukkan hubungan semacam ini untuk PERUSAHAAN. Pada tahap ini, diagram REA Perancang database untuk siklus pendapatan PERUSAHAAN akan tampak seperti Gambar DD-3.
Gambar DD-3Gambar-5-0003-a

Langkah 3: Masukkan Kegiatan Komitmen dalam Membangun Diagram REA untuk satu Siklus Transaksi.

Langkah ketiga dalam menggambar diagram REA adalah menganalisis kegiatan pertukaran ekonomi untuk menetapkan apakah kegiatan tersebut dapat dipecah menjadi sebuah kombinasi dari satu atau lebih kegiatan komitmen dan pertukaran.
Gambar DD-3Gambar-5-0003-a
Walaupun Gambar DD-3 secara akurat memodelkan penjualan PERUSAHAAN ke pelanggan yang datang ke toko, Perancang database tahu bahwa PERUSAHAAN juga menerima pesanan dari pelanggan dalam tiga cara, yaitu: melalui Internet, telepon, dan surat.

Merupakan hal yang penting bagi PERUSAHAAN untuk secara akurat memperbarui informasi mengenai pesanan-pesanan ini agar manajemen mengetahui kapan saatnya memesan kembali berbagai barang persediaan. Selain itu, merupakan hal yang penting pula untuk diketahui pesanan mana yang telah dikirim dan kapan waktu pengirimannya. Oleh sebab itu,

Perancang database mernutuskan untuk mengganti kegiatan pertukaran ekonomi tunggal yang diwakilkan sebagai penjualan dalam Gambar DD-3, dengan kombinasi kegiatan komitmen, yang disebutnya sebagai pesanan pelanggan, dan dengan kegiatan pertukaran ekonomi yang tetap disebutnya sebagai penjualan.

Perancang database memutuskan bahwa kegiatan penjualan dapat dipergunakan untuk mewakili baik penjualan dengan pengiriman maupun yang terjadi di toko, karena. PERUSAHAAN mengumpulkan informasi yang hampir sama mengenai kedua jenis penjualan tersebut. Perbedaan utama antara kedua kegiatan tersebut adalah penjualan yang terjadi di toko tidak memiliki nomor dokumen pengiriman.

Akan tetapi, Perancang database rnemutuskan untuk tidak memecah kegiatan pertukaran penerimaan kas. Satu-satunya hal yang perlu dilacak PERUSAHAAN adalah penerimaan pembayaran yang sesungguhnya, walaupun untuk pembayaran pelanggan diterima pada saat penjualan, seperti yang umumnya terjadi untuk penjualan di toko, atau penjualan melalui surat.

Akan tetapi, bagaimana dengan penagihan pada pelanggan? Perancang database tidak membuat model penagihan sebagai sebuah kegiatan, karena ini bukanlah merupakan kegiatan pertukaran ekonomi maupun komitmen. Mencetak faktur penjualan dan mengirimkannya ke pelanggan tidak meningkatkan atau mengurangi jumlah sumber daya.

Penagihan juga tidak mewakili komitmen organisasi untuk melaksanakan pertukaran ekonomi di masa mendatang. Kewajiban pelanggan untuk membayar organisasi penjual bukan muncul dari aktivitas penagihan, tetapi dari pengiriman barang dagangan. Aktivitas penagihan hanyalah sebuah kegiatan pemrosesan informasi yang hanya mengambil informasi dari database mengenai pesanan pelanggan dan kegiatan penjualan yang telah terjadi.

Organisasi membangun database untuk mengumpulkan, memproses, dan menyimpan informasi mengenai aktivitas rantai nilai mereka. Aktivitas proses informasi seperti ini tidak merubah isi database, dan karenanya, tidak dimodelkan sebagai kegiatan dalam diagram REA. Konsekuensinya, aktivitas pencetakan dan pengiriman faktur penjualan tidak perlu muncul dalam diagram REA siklus pendapatan organisasi.

Langkah 4: Menetapkan Kardinalitas (Cardinalities) Hubungan dalam Membangun Diagram REA untuk satu Siklus Transaksi.

Langkah terakhir dalam menggambar diagram REA untuk satu siklus transaksi adalah menambahkan informasi mengenai sifat hubungan antar-entitas.

Pembahasan ini, mengadopsi notasi Batini untuk mewakili informasi kardinalitas. Jadi, pasangan huruf dan angka dalam tanda kurung yang terdapat di setiap entitas Gambar DD-6, mewakili kardinalitas minimum dan maksimumnya, sesuai dengan keterlibatan entitas dalam hubungan tersebut. Sayangnya, tidak ada standar universal untuk mewakili informasi mengenai kardinalitas dalam diagram REA.
Gambar DD-6Gambar-5-0006-aa

Pengertian Kardinalitas dalam REA.

Apa Kardinalitas itu? Entitas yang mewakili kelas atau rangkaian objek. Contohnya, entitas pelanggan mewakili seluruh pelanggan organisasi, sedangkan entitas penjualan mewakili seluruh transaksi penjualan yang terjadi selama periode fiskal yang berjalan. Setiap individu pelanggan atau transaksi penjualan mewakili sebuah perumpamaan khusus entitas pelanggan dan penjualan.

cardinality-urlKardinalitas menunjukkan bagaimana perumpamaan dalam satu entitas dapat dihubungkan ke perumpamaan tertentu dalam entitas lainnya. Contohnya, kardinalitas menunjukkan berapa banyak transaksi penjualan yang dapat dihubungkan ke setiap individu pelanggan, dan sebaliknya, berapa banyak pelanggan yang dapat dihubungkan ke setiap transaksi penjualan.

Di dalam database relasional, setiap entitas adalah tabel, dan setiap perumpamaan adalah baris dalam tabel tersebut. Oleh sebab itu, di dalam database relasional, kardinalitas menunjukkan berapa banyak baris di dalam satu tabel yang dapat dihubungkan ke setiap baris di dalam tabel lainnya.

Kardinalitas Minimun dalam REA

Gambar DD-6Gambar-5-0006-aa
GambarDD-6 menyajikan kardinalitas sebagai pasangan nomor di setiap entitas.

Nomor pertama adalah kardinalitas minimum. Ini menunjukkan apakah sebuah baris dalam tabel harus dihubungkan dengan paling tidak satu baris di dalam tabel yang letaknwa berseberangan dalam hubungan tersebut. Kardinalitas minimum nol (0) memiliki arti bahwa sebuah baris baru dapat ditambahkan di tabel tersebut tanpa harus dihubungkan dengan baris tertentu dalam tabel yang letaknya berseberangan dalam hubungan tersebut.

Contohnya, di dalam Gambar DD-6, kardinalitas minimum 0 yang terletak di dekat entitas pelanggan dalam hubungan pelanggan-penjualan, menunjukkan bahwa informasi tentang pelanggan baru (prospektif) dapat ditambahkan ke tabel pelanggan tanpa harus dihubungkan ke suatu transaksi penjualan.

minimumSebaliknya, kardinalitas minimum satu (1) memiliki arti bahwa setiap baris dalam suatu tabel harus dihubungkan ke paling tidak satu baris dalam tabel lainnya di hubungan tersebut. Contohnya, di dalam Gambar DD-6, kardinalitas minimum yang terletak di dekat entitas penjualan dalam hubungan pelanggan-penjualan, menunjukkan bahwa informasi mengenai transaksi penjualan baru dapat ditambahkan hanya apabila terhubung dengan sebuah baris dalam tabel pelanggan.

Kardinalitas Maksimun dalam REA

Nomor kedua dalam setiap pasangan kardinalitas adalah kardinalitas maksimum. Hal ini menunjukkan apakah suatu baris dalam tabel dapat dihubungkan ke lebih dari satu baris dalam tabel lainnya.

maximum-urlKardinalitas maksimum 1 memiliki arti bahwa setiap baris di dalam tabel dapat dihubungkan ke paling banyak hanya satu baris dalam tabel lainnya. Perhatikan hubungan pelanggan-penjualan yang ditunjukkan di Gambar DD-6, yang memiliki kardinalitas maksimum 1 di entitas penjualannya.

Hal ini berarti setiap transaksi penjualan dapat dihubungkan hanya ke satu pelanggan tertentu saja. Sebaliknya, perhatikan bahwa kardinalitas maksimum di dekat entitas pelanggan adalah N (yang mewakili arti banyak/many). Hal ini berarti setiap baris dalam tabel pelanggan dapat (tetapi bisa tidak perlu) dihubungkan ke lebih dari satu baris tabel penjualan.
Gambar DD-6Gambar-5-0006-aa

Jenis Hubungan dalam antar entitas.

Tiga jenis hubungan. Terdapat kemungkinan tiga jenis dasar hubungan antar-entitas, tergantung dari kardinalitas maksimum yang berhubungan dengan setiap entitas.cardinality-url

  1. Hubungan satu-ke-satu (one-to-one relationship) (1:1) terjadi saat kardinalitas maksimum untuk setiap entitas dalam hubungannya adalah 1 (lihat Gambar DD-7, Panel A).
  2. Hubungan satu-ke-banyak (one-to-many relationship) (1:N) terjadi saat kardinalitas maksimum dari suatu entitas dalam hubungan adalah 1 dan kardinalitas maksimum entitas lainnya dalam hubungan tersebut adalah N (lihat Gambar DD-7, Panel B dan C).
  3. Hubungan banyak-ke-banyak (many-to-many relationship) (M:N) terjadi saat kardinalitas maksimum kedua entitas dalam suatu hubungan adalah N (Gambar DD-7, Panel D).

Gambar DD-7Gambar-5-0007-aa-dd-7

 

Hal yang memungkinkan terjadinya hubungan 1:N (satu ke banyak).

Gambar DD=7, Panel B dan Gambar DD-7, Panel C menunjukkan dua cara kemungkinan terjadinya hubungan satu-ke-banyak (1:N). Gambar DD-7, Panel B memperlihatkan bahwa setiap kegiatan penjualan dapat dihubungkan dengan banyak kegiatan penerimaan kas.

Gambar DD-7Gambar-5-0007-aa
Hal ini menunjukkan bahwa pelanggan dapat melakukan pembayaran secara cicilan, walaupun bukan merupakan syaratnya. Akan tetapi, Gambar DD-7, Panel B juga memperlihatkan bahwa setiap kegiatan penerimaan kas dihubungkan dengan paling banyak satu kegiatan penjualan. Hal ini menunjukkan bahwa pelanggan harus membayar setiap transaksi penjualan secara terpisah; mereka tidak bisa membuat rekening saldo untuk suatu periode.

Sebaliknya, Gambar DD-7, Panel C memperlihatkan bahwa setiap kegiatan penjualan dapat dihubungkan dengan paling banyak satu kegiatan penerimaan kas. Hal ini menunjukkan bahwa pelanggan tidak dapat membayar secara cicilan. Gambar DD-7, Panel C juga memperlihatkan bahwa setiap kegiatan penerimaan kas dapat dihubungkan dengan berbagai kegiatan penjualan yang berbeda.

Hal ini menunjukkan adanya kebijakan yang mengizinkan pelanggan membuat beberapa pembelian selama suatu periode waktu (contoh: dalam satu bulan), dan kemudian membayar lunas pembelian mereka dengan satu kali pembayaran.mandatory-reltshp-url

Hal yang memungkinkan terjadinya hubungan M:N (banyak ke banyak).

Gambar DD-7, Panel D menunjukkan hubungan banyak-ke-banyak (M:N) antara kegiatan penjualan dan penerimaan kas:

many2manySetiap kegiatan penjualan dapat dihubungkan dengan satu atau lebih kegiatan penerimaan kas, dan setiap kegiatan penerimaan kas dapat dihubungkan dengan satu atau lebih kegiatan penjualan.

Hal ini mencerminkan situasi organisasi yang dapat melakukan beberapa penjualan tunai, penjualan yang memungkinkan pelanggan membayar secara cicilan, dan penjualan yang memungkinkan pelanggan membayar lebih dari satu pembelian dengan satu kali pengiriman uang.
Gambar DD-7Gambar-5-0007-aa

Aturan untuk Menspesifikasi Kardinalitas.

Pendesain database tidak menentukan sendiri kardinalitas. Sebaliknya, kardinalitas mencerminkan fakta mengenai organisasi yang dibuat modelnya dan juga praktik bisnis organisasi tersebut.

Informasi ini diperoleh dalam tahap definisi persyaratan dari proses desain database. Jadi, Perancang database harus dengan jelas memahami bagaimana perusahaan melakukan aktivitas-aktivitas bisnisnya untuk memastikan bahwa Gambar DD-6 sudah benar untuk kondisi PERUSAHAAN.

Akan tetapi, beberapa prinsip umum tertentu dapat memberikan titik awal untuk mulai membangun model data REA bagi organisasi jenis apa pun.
Gambar DD-6Gambar-5-0006-aa

Aturan Kardinalitas untuk Hubungan Pelaku-Kegiatan (Agent-Event Relationship)

Perhatikan bahwa di dalam Gambar DD-6 kardinalitas minimum dan maksimum yang berhubungan dengan entitas kegiatan dalam setiap hubungan pelaku-kegiatan adalah satu (1).

Gambar-5-0006-aaGambar DD=6.
Kondisi ini hampir selalu dapat ditemui di mana saja. Kardinalitas minimum yang berhubungan dengan entitas kegiatan bernilai 1 karena harus ada beberapa pelaku yang terlibat dalam kegiatan terscbut.

Contohnya, suatu kegiatan penjualan harus dihubungkan dengan seorang pelanggan. Kardinalitas maksimum juga biasanya bernilai 1, karena organisasi ingin agar ada seorang pelaku tertentu yang bertanggung jawab atas kegiatan tersebut.

Melanjutkan contoh sebelumnya, sebuah penjualan dilakukan oleh beberapa pelanggan yang dapat diidentifikasi, yang diharapkan membayar untuk penjualan tersebut. Dengan cara yang hampir sama, kardinalitas maksimum entitas kegiatan dalam hubungan dengan pelaku internal (contoh untuk kegiatan penjualan, seorang staf penjualan) juga biasanya bernilai 1, untuk memberikan kredit ke pegawai terkait.

Prinsip Umum Kardinalitas dalam hubungan Pelaku-Kegiatan

Terdapat pula prinsip umum tentang kardinalitas yang berhubungan dengan entitas pelaku dalam hubungan pelaku-kegiatan. Perhatikan bahwa dalam Gambar DD-6, kardinalitas yang berhubungan dengan setiap pelaku dalam hubungan pelaku-kegiatan seluruhnya memiliki nilai minimum nol (0) dan maksimum N. Kombinasi ini juga umum dalam hubungan tersebut.
Gambar DD-6Gambar-5-0006-aa

Kardinalitas maksimum yang berhubungan dengan entitas pelaku internal dalam hubungan pelaku-kegiatan juga hampir selalu N, karena organisasi berharap pegawai mereka akan terlibat dalam berbagai kegiatan. Kardinalitasnya juga akan N untuk pelaku eksternal, karena organisasi sering kali terlibat dalam transaksi berulang-ulang dengan pemasok dan pelanggan yang sama.

Alasan Kardinalitas minimum Entitas Pelaku (Pelaku-Kegiatan) bernilai 0(nol)

Terdapat dua alasan mengapa kardinalitas minimum yang berhubungan dengan entitas pelaku di hubungan pelaku-kegiatan biasanya bernilai nol (0).

zero-card-urlPertama, organisasi ingin dapat menambah informasi mengenai pelanggan dan pemasok potensial, walaupun para pelaku tersebut mungkin saja tidak (belum) terlibat dalam transaksi bisnis apa pun.

Kedua, entitas kegiatan sesuai dengan file transaksi, sedangkan entitas pelaku sesuai dengan file utama (master file). Pada akhir tahun fiskal, isi tabel kegiatan biasanya akan diarsipkan dan tahun fiskal yang baru akan mulai dengan baris kosong dalam berbagai tabel kegiatan.

Sebaliknya, informasi mengenai pelaku bersifat permanen dan dibawa terus dari satu periode fiskal ke periode berikutnya. Oleh sebab itu, pada awal periode fiskal baru, pelanggan dapat tidak dihubungkan dengan kegiatan penjualan yang baru berjalan.

Asumsi Perancang Database untuk setiap hubungan Pelaku-Kegiatan.

Perancang database memulai dengan asumsi bahwa setiap hubungan pelaku-kegiatan dapat dimodelkan sesuai dengan pola berikut:

Kegiatan (l,l)-(0,N) Pelaku. Perancang database kemudian mewawancarai Manajemen untuk menetapkan apakah perancang database perlu memodifikasi asumsi tersebut atau tidak.

Setelah perancang database mengetahui bahwa tidak ada pengecualian dalam praktik umum ini, perancang database membiarkan kardinalitas tersebut sebagaimana adanya, seperti yang diperlihatkan dalam Gambar DD-6.
Gambar DD-6Gambar-5-0006-aa

Aturan Kardinalitas untuk Hubungan Sumber Daya-Kegiatan

Gambar-5-0006-aaGambar DD-6
Perhatikan bahwa dalam Gambar DD-6 kardinalitas minimum dan maksimum yang berhubungan dengan setiap sumber daya di hubungan sumber daya-kegiatan, bernilai nol (0) dan N. Hal ini umum untuk sebagian besar organisasi dan sumber daya. Alasannya sama dengan yang diberikan sebelumnya ketika menjelaskan kardinalitas minimum dan maksimum umum, yang berhubungan dengan pelaku dalam hubungan pelaku-kegiatan.

Satu pengecualian pada aturan umum ini adalah kardinalitas maksimum yang berhubungan dengan sumber daya persediaan kadang kala bernilai satu (1). Gambar DD-6 mencerminkan fakta bahwa PERUSAHAAN menjual barang dagangan yang diproduksi secara masal. Bagi setiap barang yang diterimanya, PERUSAHAAN harus mengetahui jumlah yang dimiliki dan jumlah yang tersedia untuk dijual.

Perusahaan tersebut juga harus mengetahui jumlah setiap barang yang dibeli atau dijual. Akan tetapi, PERUSAHAAN tidak mencoba untuk melacak barang tertentu yang secara fisik termasuk dalam sebuah transaksi.

Konsekuensinya, setiap baris dalam tabel persediaan di Gambar DD-6 mewakili jenis barang. Bagi PERUSAHAAN, kunci utama (primary key) adalah nomor barangnya. Organisasi lain mungkin akan menyebut kunci utama sebagai nomor bagian atau nomor SKU. Hal yang penting untuk dipahami adalah bahwa setiap baris dalam tabel persediaan PERUSAHAAN dapat dihubungkan dengan berbagai baris berbeda dalam tabel penjualan.

Akan tetapi, kadang kala organisasi melacak barang persediaan tertentu secara fisik. Contoh kondisi ini adalah berkaitan dengan karya seni asli, kendaraan bermotor, atau rumah. Bagi barang dagangan semacam ini, setiap baris dalam tabel persediaan akan mewakili lukisan atau rumah tertentu, dan akan diidentifikasi dengan kunci utama yang menjadi sejenis ID dengan nomor seri. Dalam kasus semacam ini, suatu baris dalam tabel persediaan dapat dihubungkan dengan paling banyak satu transaksi penjualan dan karenanya, akan memiliki kardinalitas maksimum 1, bukan N.

Prinsip Umum Kardinalitas Minimum entitas kegiatan dalam hubungan Sumber daya-Kegiatan.

Sekarang perhatikan kardinalitas yang berhubungan dengan entitas kegiatan dalam hubungan sumber daya-kegiatan.

Gambar-5-0006-aaGambar DD-6 mencerminkan prinsip umum bahwa kardinalitas minimum yang berhubungan dengan entitas kegiatan dalam hubungan sumber daya-kegiatan biasanya bernilai l.

Contohnya, setiap kegiatan penjualan harus memasukkan paling tidak satu baris dalam tabel persediaan (agar penjualan terjadi, PERUSAHAAN harus menjual sesuatu). Dengan cara yang hampir sama, setiap pembayaran yang diterima dari seorang pelanggan harus disimpan ke dalam akun kas.

Satu-satunya pengecualian dalam aturan umum ini muncul apabila sebuah kegiatan berpotensi dihubungkan dengan lebih dari satu entitas sumber daya. Bayangkan sebuah bisnis perbaikan mobil. Beberapa pelayanan, seperti pergantian ban, bisa jadi tidak melibatkan penjualan suku cadang apa pun; sementara pelayanan lainnya, seperti perbaikan rem; melibatkan baik tenaga kerja dan suku cadang. Jadi, kegiatan penjualan untuk bisnis perbaikan mobil seperti ini dapat dihubungkan ke sebuah entitas persediaan, atau ke sebuah entitas pelayanan perbaikan, atau dihubungkan pada kedua jenis sumber daya tersebut.

Konsekuensinya, kardinalitas minimum untuk kegiatan penjualan tersebut adalah 0 dalam hubungan¬-hubungan tersebut. (Catatan: Dalam situasi tertentu yang jarang terjadi, sebuah kegiatan dapat dihubungkan ke salah satu dari beberapa entitas pelaku khusus. Dalam kasus semacam ini, kardinalitas minimum yang berhubungan lagi dengan entitas kegiatan terkait akan bernilai 0, bukan seperti normalnya, yaitu 1).

Prinsip Umum Kardinalitas Maksimum entitas kegiatan dalam hubungan Sumber daya-Kegiatan.

Akan tetapi, tidak ada prinsip umum berkaitan dengan kardinalitas maksimum yang berhubungan dengan entitas kegiatan dalam hubungan sumber daya-kegiatan. Sebagai gantinya, kardinalitas maksimum untuk sebuah kegiatan tergantung pada sifat sumber daya yang dipengaruhi oleh kegiatan tersebut dan oleh kebijakan bisnis organisasinya.

Gambar-5-0006-aa-dd-6Contohnya, Gambar DD-6 memperlihatkan bahwa setiap kegiatan penerimaan kas dapat dihubungkan ke paling banyak satu akun kas. Hal ini menunjukkan bahwa PERUSAHAAN mengikuti praktik bisnis yang baik dan menyimpan seluruh pembayaran pelanggan dalam akun yang umum dipergunakan. (Manajemen dapat saja’ kadang-kadang mentransfer kelebihan uang ke akun khusus investasi.)

Sebaliknya, Gambar DD-6 memperlihatkan bahwa setiap pesanan pelanggan dan kegiatan penjualan dapat dihubungkan dengan beberapa baris dalam tabel persediaan; karena PERUSAHAAN mengizinkan, bahkan mendorong, para pelanggannya untuk memesan dan membeli berbagai jenis produk yang sesuai keinginan mereka. Contohnya, sebuah transaksi penjualan dapat memasukkan baik sebuah monitor 21 inci dan printer dengan kualitas mencetak foto. Konsekuensinya, di dalam Gambar DD-6, kardinalitas maksimum baik untuk pesanan pelanggan dan entitas penjualan dalam hubungannya dengan tabel persediaan, adalah N.

Aturan Kardinalitas untuk Hubungan Kegiatan-kegiatan (Event-event Relationship)

Gambar DD-7Gambar-5-0007-aa-dd-7
Gambar DD-7 memperlihatkan adanya kemungkinan hampir semua jenis pasangan kardinalitas untuk setiap entitas kegiatan dalam hubungan kegiatan-kegiatan. Praktik bisnis dan kebijakan organisasi harus dipahami untuk memutuskan kemungkinan mana yang benar.

Perancang database telah mempelajari bahwa PERUSAHAAN memperpanjang kredit ke para pelanggannya dan mengirimkan laporan bulanan ke mereka yang mendaftar semua pembelian yang belum dibayar. Perancang database juga telah mempelajari bahwa banyak pelanggan yang mengirim PERUSAHAAN satu cek untuk membayar seluruh pembelian mereka dalam suatu periode waktu tertentu.

Jadi, satu kegiatan penerimaan kas dapat dihubungkan dengan banyak kegiatan penjualan. PERUSAHAAN juga mengizinkan para pelanggannya membayar secara cicilan untuk pembelian dalam jumlah besar; jadi suatu kegiatan penjualan dapat dihubungkan dengan lebih dari satu kegiatan penerimaan kas. Inilah alasan mengapa Perancang database membuat model hubungan antara kegiatan penjualan dan penerimaan kas sebagai hubungan banyak-ke-banyak (many-to-many).many2many

PERUSAHAAN mengirim setiap pesanan pelanggan secara terpisah, dan menunggu hingga seluruh barang terdapat dalam persediaan sebelum memenuhi suatu pesanan. Oleh sebab itu, Perancang database membuat model hubungan antara pesanan pelanggan dengan kegiatan penjualan sebagai hubungan satu-ke-satu (one-to-one).one2one-images

Prinsip Umum Pembuatan Model untuk hubungan Kegiatan-Kegiatan.

sampleERSatu-satunya prinsip umum pembuatan model yang dapat diaplikasikan dalam hubungan kegiatan-kegiatan adalah bahwa untuk dua kegiatan yang bersifat sementara, kardinalitas minimum untuk kegiatan pertama adalah 0, karena pada saat kejadiannya, kegiatan lainnya belum terjadi. Sering kali, tetapi tidak selalu, kardinalitas minimum untuk kegiatan kedua adalah 1, menunjukkan bahwa kegiatan pertama harus terjadi terlebih dahulu.

Contohnya, bagi perusahaan yang menjual baik melalui katalog ataupun melalui Website, pesanan pelanggan (kegiatan 1) mendahului pengiriman ke pelanggan (kegiatan 2). Akan tetapi, kadang kala kedua kegiatan tersebut tidak perlu terjadi. Contohnya, PERUSAHAAN menerima pesanan dari pelanggan korporatnya sebelum mengirim barang dagangan mereka. Akan tetapi, penjualan di dalam toko bagi para pelanggan yang langsung datang ke toko tidak dimulai dengan suatu kegiatan pesanan apa pun.

Konsekuensinya, dalam Gambar DD-6, kardinalitas minimum yang berhubungan dengan kegiatan kedua (penjualan) dalam hubungan pesanan pelanggan-penjualan juga bernilai 0.

Gambar-5-0006-aa-dd-6Gambar DD-6.
Gambar DD-6 memperlihatkan bagaimana diagram REA Perancang database untuk siklus pendapatan PERUSAHAAN setelah adanya penambahan informasi mengenai kardinalitas hubungan. Langkah berikuhnya adalah mengimplementasikan model ini dalam database relasional.

Mengimplementasikan Diagram REA dalam Database Relasional.

reaKetika diagram REA telah selesai dibangun, diagram ini dapat dipergunakan untuk mendesain database reiasional yang terstruktur baik. Bahkan, membuat suatu rangkaian tabel berdasarkan diagram REA secara otomatis akan menghasilkan database relasional yang terstruktur baik, tanpa adanya masalah anomali pembaruan (update), penyisipan data (nsert), dan penghapusan (delete).

Mengimplementasikan diagram REA ke dalam database relasional melibatkan proses tiga tahap, yaitu:

  1. Membuat sebuah tabel untuk setiap entitas berbeda dan untuk setiap hubungan banyak-ke-banyak (many-to-many).
  2. Memberikan atribut ke tabel yang tepat.
  3. Menggunakan kunci luar (foreign key) untuk mengimplementasikan hubungan satu¬ke-satu (one-to-one) dan hubungan satu-ke-banyak (one-to-many).

Langkah 1: Membuat Tabel untuk Setiap Entitas dan Hubungan M:N

Database yang didesain dengan tepat memiliki sebuah tabel untuk setiap entitas yang berbeda, dan untuk setiap hubungan banyak-ke-banyak (many-to-many) dalam diagram REA.

Dalam kasus siklus pendapatan PERUSAHAAN yang diperlihatkan di Gambar DD-6, terdapat tujuh entitas berbeda, yaitu: persediaan, kas,, pesanan pelanggan, penjualan, penerimaan kas, pegawai, dan pelanggan. Walaupun diagram REA tersebut berisi entitas terpisah untuk staf penjualan dan kasir, hanya satu tabel, yaitu pegawai, yang diperlukan karena PERUSAHAAN perlu mengetahui informasi yang identik mengenai staf penjualan dan kasirnya, seperti nama, tanggal lahir, tanggal dipekerjakan, dan tingkat gaji.
Gambar DD-6Gambar-5-0006-aa-dd-6

Gambar DD-6 juga menunjukkan tiga hubungan M:N (pesanan pelanggan-persediaan, penjualan-persediaan, dan penjualan-penerimaan kas). Oleh sebab itu, 10 tabel akan dibuat untuk mengimplementasikan diagram REA yang diperlihatkan dalam Gambar DD-6-satu tabel untuk tiap ketujuh entitas dan satu tabel untuk setiap ketiga hubungan M:N.

Merupakan langkah yang baik untuk memberikan nama yang sama seperti entitas yang diwakili untuk setiap tabel. Akan tetapi, tabel yang menunjukkan hubungan M:N sering kali diberi judul dengan cara memberi tanda hubung di antara kedua nama entitas yang dihubungkannya. Jadi, sehubungan dengan Gambar kita akan membuat tabel pesanan pelanggan-persediaan, penjualan-persediaan, dan penjualan-penerimaan kas, untuk semua hubungan M:N tersebut.
Tabel DD-1gbr-table-5-100011-a

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(1)

Langkah berikutnya adalah menetapkan atribut mana yang seharusnya dimasukkan ke
dalam setiap tabel. Selama proses pembuatan model data, pemakai dan manajemen akan mengidentifikasi fakta-fakta yang ingin mereka kumpulkan.

gbr-table-5-100011-aTabel DD-1 mendaftar fakta–fakta yang diketahui Perancang database penting untuk database siklus pendapatan PERUSAHAAN yang sedang didesainnya.gbr-table-5-100012-a-dd-8

Gambar DD-8
Tabel-tabel yang Dibuat untuk Mengimplementasikan Diagram REA dalam Gambar DD-6Gambar-5-0006-aa-dd-6

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(2)

Gambar DD-8.gbr-table-5-100012-a-dd-8
Menetapkan Kunci Utama (primary key) Setiap tabel di dalam database relasional harus memiliki sebuah kunci utama, yang terdiri dari sebuah atribut, atau kombinasi dari beberapa atribut, yang secara unik mengidentifikasi setiap baris dalam tabel tersebut.

Perusahaan sering kali membuat pengidentifikasi numeris untuk sumber daya, kegiatan dan pelaku tertentu. Pengidentifikasi numeris ini merupakan kandidat yang baik untuk menjadi kunci utama. Contohnya, PERUSAHAAN dapat mempergunakan nomor faktur penjualan sebagai kunci utama tabel penjualan, dan nomor pelanggan sebagai kunci utama dalam tabel pelanggan.

Umumnya, kunci utama dalam suatu tabel yang mewakili sebuah entitas merupakan atribut tunggal. Akan tetapi, kunci utama untuk tabel hubungan M:N selalu terdiri dari dua atribut yang mewakili kunci utama dari setiap entitas yang dihubungkan dalam hubungan tersebut.

Contohnya, kunci utama tabel penjualan-persediaan terdiri dari baik nomor faktur penjualan (yang merupakan kunci utama dalam entitas penjuatan) dan nomor barang (yang merupakan kunci utama dalam entitas persediaan). Kunci utama dengan atribut lebih dari satu semacam ini disebut sebagai kunci yang saling berhubungan (concatenated key).

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(3)

Menetapkan atribut lain ke tabel yang tepat. Atribut tambahan selain kunci utama dimasukkan dalam setiap tabel untuk memenuhi persyaratan pemrosesan transaksi dan kebutuhan informasi manajemen.
Gambar DD-8gbr-table-5-100012-a-dd-8

Gambar DD-8 memperlihatkan atribut-atribut yang ditetapkan Perancang database keberbagai tabel yang dibuatnya untuk mengimplementasikan diagram REA siklus pendapatan PERUSAHAAN. Beberapa atribut tersebut, seperti tanggal dan jumlah tiap penjualan, merupakan informasi penting untuk memproses transaksi secara akurat dan lengkap.

Atribut-atribut tersebut juga penting untuk pembuatan laporan keuangan dan manajerial. Atribut lainnya disimpan karena mereka memfasilitasi manajemen yang efektif atas sumber daya, kegiatan, dan pelaku perusahaan. Contohnya. Manajemen dapat menggunakan data mengenai waktu saat terjadinya transaksi penjualan untuk mendesain jadwal kerja staf.

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(4)

Atribut Non-Kunci (nonkey atribute) dalam Tabel Hubungm M:N Mari kita pelajari penempatan atribut yang bukan berupa kunci dalam setiap inbel M:N, untuk melihat alasan mengapa mereka harus disimpan dalam tabel-tabel. tersebut.

atribute-urlPertama-tama bayangkanlah tabel penjualan-penerimaan kas. Ingatlah kembali bahwa PERUSAHAAN mengizinkan para pelanggannya untuk membuat beberapa pembelian secara kredit, dan untuk rnelakukan pembayaran secara cicilan atas sisa utang mereka. Jadi, satu pembayaran dari pelanggan mungkin perlu diaplikasikan ke beberapa faktur penjualan berbeda (transaksi penjualan).

Oleh sebab itu, atribut “jumlah yang dibebankan” tidak dahat ditempatkan dalam tabel penerimaan kas karena hal ini akan menimbulkan nilai lebih dari satu, yang akhirnya akan melanggar persyaratan dasar database relasional yaitu setiap atribut dalam setiap baris harus bernilai tunggal (yaitu, persyaratan bahwa setiap tabel haruslah berupa flat file). Atribut “jumlah yang dibebankan” juga tidak dapat ditempatkan dalam tabel penjualan, karena kemungkinan pembayaran secara cicilan menimbulkan situasi kemungkinan adanya nilai ganda suatu atribut. Atribut “jumlah yang dibebankan” merupakan fakta mengenai pembayaran pelanggan dan transaksi penjualan. Oleh sebab itu, termasuk dalam tabel M:N yang menghubungkan dua kegiatan tersebut.

Sekarang pelajari tabel penjualan-persediaan. Setiap baris dalam tabel ini berisi informasi mengenai suatu barang dalam faktur penjualan. Walaupun banyak pelanggan PERUSAHAAN yang hanya membeli satu jenis produk dari berbagai jenis produk yang dijual PERUSAHAAN, beberapa penjualan ke beberapa pelanggan melibatkan jumlah yang besar.

Konsekuensinya, PERUSAHAAN harus mencatat jumlah yang dijual untuk setiap harang. Akan tetapi, setiap kegiatan penjualan dapat melibatkan lebih dari satu barang persediaan. Jadi, atribut “jumlah yang dijual” dapat memiliki beberapa nilai dalam satu :aktur penjualan. Sebagai tambahan, PERUSAHAAN melacak persediaan melalui jenis barangnya, bukan melalui identifikasi tertentu.

Oleh sebab itu, suatu barang, seperti monitor 21 inci dengan Merek X, dapat dijual dalam beberapa transaksi penjualan. Konsekuensinya, “jumlah yang dijual” tidak dapat dipergunakan sebagai atribut dalam tabel persediaan, karena dapat memiliki beberapa nilai. Oleh sebab itu, dengan pertimbangan bahwa atribut “jumlah yang dijual” dapat diaplikasikan ke suatu barang yang termasuk dalam transaksi penjualan tertentu, maka atribut ini termasuk dalam tabel hubungan M:N yang menghubungkan kedua tabel tersebut.

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(5)

Data harga
Di dalam Gambar DD-8, perhatikan bahwa informasi mengenai harga disimpan sebagai atribut baik dalam tabel persediaan, maupun tabel penjualan-persediaan. Tabel persediaan menyimpan daftar harga yang disarankan untuk setiap barang. Harga tersebut umumnya tidak berubah dalam suatu periode fiskal. Tabel penjualan-persediaan menyimpan harga penjualan yang sebenarnya, yang dapat berbeda-beda selama masa berjalan periode fiskal, sebagai hasil dari adanya promosi penjualan.
Gambar DD-8gbr-table-5-100012-a-dd-8

Langkah 2: Menetapkan Atribut untuk Setiap Tabel(6)

Data kumulatif
Gambar DD-8.gbr-table-5-100012-a-dd-8
Gambar DD-8 juga memasukkan beberapa atribut, seperti “jumlah yang dimiliki” dalam tabel persediaan dan “saldo rekening” dalam tabel pelanggan, yang mewakili data kumulatif.

Secara teoritis, tidaklah penting untuk menyimpan atribut-atribut tersebut secara terpisah dalam database, karena sistem tersebut dapat menghitungnya apabila diperlukan. Contohnya, informasi mengenai jumlah yang dijual untuk setiap barang, disimpan dalam tabel penjualan-persediaan. Informasi mengenai jumlah yang dibeli akan disimpan dalam tabel yang hampir sama untuk menghubungkan pembelian dan persediaan.

Dalam rangka menetapkan jumlah yang dimiliki, SIA dapat langsung menghitung perbedaan antara jumlah yang dijual dengan jumlah yang dibeli. Dengan cara yang hampir sama, tabel penerimaan kas dan pembayaran kas berisi informasi mengenai arus masuk dan keluar kas. SIA dapat menghitung perbedaan tersebut untuk menampilkan saldo terakhir dalam akun kas.

Akan tetapi, menyimpan secara eksplisit jumlah total dan saldo dapat meningkatkan waktu respons atas permintaan informasi, yang menjelaskan alasan mengapa Gambar DD-8 memperlihatkan beberapa atribut ringkasan semacam ini untuk tabel-tabel yang sesuai. Akan tetapi, hal ini seharusnya dilakukan hanya bila DBMS memiliki kemampuan untuk secara otomatis memperbarui nilai ringkasan ini ketika suatu kegiatan baru terjadi; jika tidak, nilai ringkasan tersebut biasanya tidak benar.

Langkah 3: Menggunakan Kunci Luar (Foreign Key) untuk Mengimplementasikan Hubungan 1:1 dan 1:N…(1)

many2manyHubungan M: N harus diimplementasikan sebagai tabel-tabel terpisah untuk membuatnya menjadi database relasional yang terstruktur baik, walaupun hubungan 1:1 dan 1:N juga dapat diimplementasikan sebagai tabel-tabel terpisah, biasanya lebih efisien apabila mengimplementasikan mereka dengan menggunakan kunci luar.

1-1-urlIngatlah bahwa kunci luar adalah atribut suatu entitas yang sebenarnya juga merupakan kunci utama dari entitas lain. Contohnya, atribut “nomor pelanggan” dapat muncul baik dalam tabel pelanggan maupun penjualan. Atribut itu dapat menjadi kunci utama dalam tabel pelanggan, tetapi merupakan kunci luar dalam tabel penjualan.

Langkah 3: Menggunakan Kunci Luar (Foreign Key) untuk Mengimplementasikan Hubungan 1:1 dan 1:N…(2)

Hubungan Satu-ke-Satu (one-to-one relationships) Di dalam database relasional, hubungan satu-ke-satu antara entitas dapat diimplementasikan dengan memasukkan kunci utama suatu entitas sebagai kunci luar dalam tabel yang mewakili entitas satunya. Demi mendesain database yang terstruktur baik, pilihan tabel mana yang akan dipergunakan tmtuk menempatkan kunci luar merupakan pilihan individual. Analisis yang dilaksanakan dengan hati-hati atas kardinalitas minimum hubungan tersebut dapat memberikan saran pendekatan mana yang tampaknya lebih efisien.Gambar-5-0007-aa-dd-7

Gambar DD-7.
Lihatlah hubungan l:l antara penjualan dan pembayaran pelanggan yang ditunjukkan dalam Gambar DD-7, Panel A. Kardinalitas minimum untuk kegiatan penjualan adalah 0, menunjukkan adanya penjualan secara kredit, sedangkan kardinalitas minimum untuk kegiatan penerimaan kas adalah 1, menunjukkan bahwa pembayaran dari pelanggan hanya terjadi setelah adanya penjualan (contoh tidak ada pembayaran di muka).

Pada kasus ini, memasukkan nomor faktur penjualan (kunci utama dalam kegiatan penjualan) sebagai kunci luar dalam kegiatan penerimaan kas, mungkin lebih efisien karena nantinya hanya satu tabel itu saja yang perlu diakses dan diperbarui untuk memproses data mengenai tiap pembayaran dari pelanggan. Selanjutnya, untuk hubungan 1:1 antara dua kegiatan yang berurutan, memasukkan kunci utama dari suatu kegiatan yang pertama kali terjadi sebagai kunci luar dalam kegiatan yang terakhir terjadi, dapat meningkatkan pengendalian internal.

Langkah 3: Menggunakan Kunci Luar (Foreign Key) untuk Mengimplementasikan Hubungan 1:1 dan 1:N…(3)

Hubungan Satu-ke-Banyak (one-to-many) Sebagaimana dengan hubungan l:l, hubungan 1:N juga dapat diimplementasikan dalam database relasional dengan menggunakan kunci luar.

gbr-table-5-100012-a-dd-8Dalam rangka melakukan hal ini, tempatkan kunci utama dari suatu entitas yang memiiiki kardinalitas maksimum N sebagai kunci luar dalam entitas yang memiliki kardinalitas maksimum 1. Contohmya, dalam Gambar DD-8, kunci utama tabel staf penjualan dan pelanggan dimasukkan sebagai kunci luar dalam tabel penjualan. Dengan cara yang hampir sama, kunci utama dalam tabel kas, pelanggan, dan kasir dimasukkan sebagai kunci luar dalam tabel penerimaan kas.
Gambar DD-7.Gambar-5-0007-aa-dd-7

Apabila kita akan membuat tabel untuk Gambar DD-7, Panel B, atribut “nomor faktur penjualan” akan muncul sebagai kunci luar dalam tabel penerimaan kas. Akan tetapi, apabila kami akan membuat tabel untuk Gambar DD-7, Panel C, atribut “nomor pengiriman uang” akan muncul sebagai kunci luar dalam tabel penjualan.

Kemungkinan pengecualian atas peraturan umum untuk mengimplementasikan hubungan 1:N ini dapat terjadi apabila hubungan tersebut terdiri dari dua entitas kegiatan yang berurutan, dan kegiatan yang biasanya terjadinya pertama kali juga merupakan kegiatan yang dapat terjadi beberapa kali dalam hubungan tersebut. Pada kasus ini, mengimplementasikan hubungan tersebut sebagai tabel terpisah dapat meningkatkan pengendalian internal.

Pemeriksaan Kelengkapan (Completeness Check)…(1)

Untuk mengimplementasikan model data REA dari siklus pendapatan PERUSAHAAN yang ditunjukkan pada Gambar DD-6, Perancang database telah membuat serangkaian tabel seperti yang ditampilkan pada Gambar DD-8.
Gambar DD-8.gbr-table-5-100012-a-dd-8
Akan tetapi, ketika meninjau daftar fakta (Tabel DD-1) yang disimpan dalam database, Perancang database melihat bahwa perancang database perlu menentukan tabel database untuk fakta-fakta yang berhubungan dengan kunjungan penjualan (sales call). Perancang database ingat bahwa Manajemen ingin mulai mengumpulkan informasi tambahan mengenai kinerja staf penjualan luar, yang kerjanya mengunjungi pelanggan korporat.
Tabel DD-1.gbr-table-5-100011-a

Secara khusus, mereka ingin tahu berapa banyak pelanggan yang didatangi oleh setiap tenaga penjual setiap hari, produk apa yang didemonstrasikan oleh tenaga penjual tersebut, dan hasil dari kunjungan tersebut. Perancang database menyadari bahwa perancang database harus memodifikasi model dari REA yang ada dan mungkin membuat tabel tambahan untuk menampung hal-hal tersebut.

Pemeriksaan Kelengkapan (Completeness Check)…(2)

Perancang database membuat suatu entitas kegiatan, yang disebutnya “mengunjungi pelanggan (call on custorner).” Perancang database menghubungkannya dengan entitas tenaga penjual dan pelanggan untuk menunjukkan hubungan pelaku-kegiatan (agent-event relationship) yang relevan.phone_cartoon

Setiap kunjungan penjualan (sales call) mencakup satu tenaga penjual yang berbicara dengan satu pelanggan. Selama satu tahun, setiap tenaga penjual akan melakukan banyak kunjungan penjualan dan setiap pelanggan mungkin akan mendapatkan lebih dari satu kali kunjungan. Oleh sebab itu,

Perancang database menetapkan model hubungan pelaku-kegiatan sebagai 1:N, dengan kardinalitas minimum dan maksimum yang sama untuk setiap entitas seperti yang digunakan dalam hubungan pelaku-kegiatan (agent-event relationship) yang mencakup kegiatan pesanan pelanggan.

Pemeriksaan Kelengkapan (Completeness Check)…(3)

Selama kunjungan penjualan, seorang tenaga penjual biasanya membicarakan dan mendemonstrasikan lebih dari satu produk. Sama juga halnya, suatu produk dapat didemonstrasikan dalam berbagai kunjungan penjualan. Oleh sebab itu, Perancang database menetapkan model hubungan mengunjungi pelanggan-persediaan sebagai M:N, dengan kardinalitas minimum dan maksimum yang sama dengan yang digunakan dalam hubungan pesanan pelanggan-persediaan (customer order-inventory relationship).

Jika kunjungan penjualan berhasil, pelanggan akan memesan produk PERUSAHAAN. Namun demikian, tidak setiap kunjungan akan menghasilkan pesanan. Beberapa pelanggan mungkin tidak langsung memesan setelah kunjungan pertama, melainkan setelah beberapa kali kunjungan. Untuk tujuan evaluasi kinerja, Manajemen meminta Perancang database menganggap pesanan tersebut sebagai hasil dari kunjungan penjualan yang, paling terakhir.

Lebih lanjut, menurut Manajemen, ada beberapa pelanggan korporat yang memesan setelah menerima katalog produk PERUSAHAAN atau setelah mengunjungi Website PERUSAHAAN. Oleh sebab itu, Perancang database menetapkan model hubungan mengunjungi pelanggan-pesanan pelanggan sebagai 1:1, dengan kardinalitas minimum 0 untuk setiap kegiatan.
Gambar DD-9.Gambar-5-0008-aa-dd-9

Gambar DD-9 menunjukkan revisi dari diagram REA yang dibuat oleh Perancang database, dan Gambar DD-10 menunjukkan isi dari dua tabel baru yang dibuat oleh Perancang database. Perancang database juga memodifikasi tabel pesanan pelanggan pada Gambar DD-8 untuk memasukkan atribut “nonor kunjungan” sebagai kunci luar yang menghubungkan kegiatan tersebut dengan kegiatan mengunjungi pelanggan.

Gambar DD-10.Gambar-5-0009-a-1a-dd-10

Pemeriksaan Kelengkapan (Completeness Check)…(4)

Bukanlah hal yang aneh jika Perancang database memodifikasi diagram REA agar dapat menampung fakta tambahan. Bahkan, sering kali berguna untuk membuat tabel bahkan sebelum menyelesaikan diagram REA, dan kemudian memodifikasi diagram agar mencakup entitas tambahan dan hubungan yang ada dalam proses penempatan atribut dalam tabel.
Gambar DD-8.gbr-table-5-100012-a-dd-8

Gambar DD-9.Gambar-5-0008-aa-dd-9

Pada tahap ini, Perancang database telah hampir menyelesaikan desain database siklus pendapatan PERUSAHAAN. Menurutnya, Gambar DD-8, DD-9, dan DD-10 telah memenuhi persyaratan dasar untuk mendesain database relasional yang terstruktur dengan baik. Persyaratan dasar tersebut adalah:

  1. Setiap tabel memiliki kunci utama.
  2. Atribut non-kunci lainnya dalam setiap tabel merupakan fakta mengenai sesuatu yang ditugaskan oleh kunci utama, atau merupakan kunci luar yang digunakan untuk menghubungkan tabel tersebut dengan tabel lainnya.
  3. Setiap atribut dalam setiap tabel bernilai tunggal yaitu: setiap tabel adalah flat-file atau ‘file datar’).

Gambar DD-10.Gambar-5-0009-a-1a-dd-10
Perhatikan bahwa rangkaian tabel pada Gambar DD-8 dan DD-10 merupakan hasil yang alami dari penggunaan model data REA. Oleh sebab itu, rangkaian tersebut tidak hanya memenuhi persyaratan database yang tepat, tetapi juga menunjukkan semantik/ hubungan dasar mengenai bagaimana PERUSAHAAN nelaksanakan aktivitas bisnis siklus pendapatan.

Memadukan Diagram REA Antar-Siklus……(1).

Seperti yang telah disebutkan, untuk mendesain SIA yang dapat berfungsi untuk PERUSAHAAN, Perancang database harus mengembangkan diagram REA untuk siklus tambahan dan kemudian memadukan diagram-diagram tersebut.
Gambar DD-11.Gambar-5-0009-a-2a-dd-11

Gambar DD-11 menunjukkan diagram REA yang pertama perancang database kembangkan untuk siklus pengeluaran PERUSAHAAN. Diagram ini hanya mencakup kegiatan pertukaran ekonomi (bandingkan dengan Gambar DD-3).
Gambar DD-3Gambar-5-0003-a-dd-3

Perancang database kemudian menggabungkan diagram siklus pendapatan dan pengeluaran agar Manajemen mendapat gambaran umum tingkat tinggi mengenai hal-hal yang akan dimasukkan dalam SIA mereka. Gambar DD-12 menampilkan hasil perpaduan diagram REA.

Memadukan Diagram REA Antar-Siklus……(2).

Perancang database memadukan dua diagram REA individual dengam menyatukan entitas yang sama. Jadi, Gambar DD-12 hanya mencakup satu entitas persediaan dan satu entitas kas. Perancang database kemudian memeriksa kelengkapan Gambar DD-12 dengan menguji apakah diagram tersebut memenuhi dua peraturan berikut ini:

  1. Setiap entitas sumber daya harus berhubungan dengan dua kegiatan arus stok: salah satunya menambah sumber daya dan yang lainnya menguranginya.
  2. Setiap kegiatan pertukaran ekonomi yang menambah sumber daya harus berhubungan dengan kegiatan pertukaran ekonomi yang mengurangi sumber daya, hal tersebut disebut prinsip dualitas ekonomi.

Gambar DD-12.Gambar-5-0010-aa-dd-12
Gambar DD-12 memenuhi kedua peraturan tersebut. Sumber-daya persediaan berhubungan dengan kegiatan pembelian (yang menambahnya) dan dengan kegiatan penjualan (yang menguranginya). Sama halnya, sumber daya kas berhubungan dengan kegiatan penambahan, penerimaan kas, dan kegiatan pengurangan, pembayaran kas.

Sebagai tambahan, pembelian yang merupakan kegiatan penambahan ekonomi, berhubungan dengan pembayaran kas yang merupakan kegiatan pengurangan ekonomi. Sama juga dengan, penjualan yang merupakan kegiatan pengurangan ekonomi yang menurunkan sumber daya persediaan, berhubungan dengan penerimaan kas yang merupakan kegiatan peningkatan ekonomi yang menaikkan sumber daya kas.

Menggunakan Diagram REA……(1).

Sejauh ini, telah ditunjukkan bagaimana cara menggunakan model data REA untuk mengarahkan desain SIA. Dalam proses tersebut, dikembangkan diagram REA untuk PERUSAHAAN. Bagian ini, membahas bagaimana diagram REA dapat juga digunakan untuk mendokumentasikan praktik bisnis dan mengarahkan pencarian informasi dari database.

Dokumentasi Praktik Bisnis
Diagram REA secara khusus berguna untuk mendokumentasikan SIA tingkat lanjut yang menggunakan database, karena kardinalitas dalam diagram REA menyediakan informasi mengenai praktik bisnis organisasi dan pola pertukaran ekonominya.
Gambar DD-12.
Gambar-5-0010-aa-dd-12Contohnya, Gambar DD-12 menunjukkan bahwa PERUSAHAAN memperpanjang kredit ke pelanggan dan memperbolehkan mereka untuk membayar secara mencicil. Diagram tersebut juga menunjukkan bahwa PERUSAHAAN menjual barang yang diproduksi secara masa1.

Untuk menginterpretasikan secara tepat makna dari kardinalitas pada diagram REA, perlu dipahami dengan baik mengenai hal yang diwakili dari kemunculan setiap entitas. Hal ini biasanya mudah untuk entitas pelaku dan kegiatan. Setiap kemunculan entitas pelaku mewakili orang atau organisasi tertentu.

Sama halnya dengan kemunculan entitas kegiatan yang mewakili transaksi atau aktivitas bisnis tertentu. Contohnya, setiap kemunculan kegiatan penjualan mewakili transaksi penjualan tertentu.

Menggunakan Diagram REA……(2).

Akan tetapi, pemahaman mengenai hal yang diwakili oleh kemunculan sumber daya, kadang-kadang lebih sulit. Misalnya mengenai persediaan. Kemunculan dari entitas ini dapat mewakili satu objek fisik tertentu atau sekelompok objek, bergantung pada sifat persediaan tersebut.
Gambar DD-8.gbr-table-5-100012-a-dd-8
Dalam kasus seperti ini, perlu diuji atribut yang berasosiasi dengan entitas tersebut guna menentukan apa yang diwakilinya. Contohnya: Gambar DD-8 menunjukkan bahwa entitas persediaan mencakup atribut “kuantitas yang dimiliki,” yang berarti bahwa setiap baris pada tabel persediaan mewakili suatu jenis persediaan, bukan sebuah objek individual.

Jadi, satu baris dalam tabel persediaan PERUSAHAAN dapat menyimpan data mengenai merek monitor 21 inci tertentu, sedangkan baris yang lain dapat menyimpan data mengenai model DVD tertentu. PERUSAHAAN ingin mengetahui berapa banyak dari produk tersebut yang masih dimiliki, sehingga atribut “jumlah yang dimiliki” akan ditemukan pada tabel persediaan.

Sebaliknya, jika hubungan-persediaan-penjualan dibuat menjadi l:N, maka organisasi tersebut pasti menjual produk yang unik sehingga menggunakan data nomor seri individual. Dalam hal ini, tabel persediaan tidak akan memasukkan atribut “kuantitas yang dimiliki” karena hanya ada satu barang untuk setiap jenis.

Menggunakan Diagram REA……(3).

Pembahasan sebelumnya menunjukkan bahwa setiap organisasi akan memiliki diagram REA tertentu, sehingga hubungan kardinalitas juga bersifat unik karena praktik bisnis berbeda antar-perusahaan.

cardinalities1Contohny-a: jika PERUSAHAAN sering melakukan pengiriman parsial (tidak penuh), maka hubungan pesanan pelanggan-penjualan mungkin akan dimodel mejadi 1:N. Jika PERUSAHAAN juga sering menggabungkan beberapa pesanan dari satu pelanggan ke dalam satu pengiriman besar, maka hubungannya akan dibuat model menjadi M:N.

Dalam kenyataannya, perbedaan dalam praktik bisnis cenderung menghasilkan pembuatan model berbagai entitas yang berbeda. Contohnya, jika hanya menjual kepada pelanggan yang berkunjung ke toko dan tidak menerima pesanan pelanggan, maka PERUSAHAAN tidak memerlukan kegiatan komitmen pesanan pelanggan.

Menggunakan Diagram REA……(4).

Kardinalitas dalam diagram REA juga menyediakan informasi mengenai pengendalian bisnis. Contohnya, setiap baris pada entitas kas mewakili akun tertentu. Jadi, satu baris menyimpan data mengenai rekening giro PERUSAHAAN, satu baris mengenai akun pembayaran gaji, baris yang lain mengenai akun investasi pasar uang, dan seterusnya. Gambar DD-12 menunjukkan model hubungan kas-penerimaan kas sebagai 1:N.
Gambar DD-12.Gambar-5-0010-aa-dd-12
Hal ini mencerminkan praktik pengendalian yang baik mengenai penyimpanan semua pembayaran pelanggan ke dalam rekening giro utama dari perusahaan.

Meskipun perkembangan diagram REA untuk siklus pendapatan PERUSAHAAN tampaknya cukup langsung pada sasaran dan intuitif, pembuatan model data dapat menjadi proses yang kompleks dan berulang-ulang. Satu tantangan yang umum terjadi ketika pemakainya menggunakan terminologi (istilah) yang berbeda-beda.

Pengambilan Informasi dari SIA,,,,(1).

gbr-table-5-100012-a-dd-8Diagram REA yang lengkap juga berfungsi sebagai petunjuk yang berguna untuk meminta informasi dari database SIA. Lihat Gambar DD-8, DD-9, dan DD-10, yang menunjukkan SIA database Perancang database yang dikembangkan untuk siklus pendapatan PERUSAHAAN dengan menggunakan model data REA.

Gambar-5-0008-aa-dd-9Jika dilihat sekilas, akan tampak bahwa sejumlah elemen yang ada pada SIA tradisional, seperti jurnal, buku besar, dan informasi mengenai piutang, dihilangkan. Dalam kenyataannya, informasi tersebut ada, tetapi disimpan dalam format yang berbeda.Gambar-5-0009-a-1a-dd-10

Pengambilan Informasi dari SIA,,,,(2).

journal-ledger-urlMenghasilkan Jurnal dan Buku Besar Permintaan data (queries) dapat digunakan untuk menghasilkan jurnal dan buku besar dari database relasional yang dibuat dengan menggunakan model REA. Informasi biasanya ditemukan dalam jurnal yang disimpan dalam tabel-tabel yang digunakan untuk mencatat data mengenai kegiatan.

Contohnya, jurnal penjualan dapat dihasilkan dengan cara menulis permintaan (query) yang menampilkan entri (entry) yang sesuai dalam tabel penjualan selama periode tertentu. Permintaan dapat ditulis untuk menampilkan setiap entri dalam tabel penjualan, menghasilkan daftar semua kegiatan penjualan, baik yang penjualan secara kredit maupun secara tunai.

Akan tetapi, secara tradisional, jurnal penjualan digunakan untuk mencatat semua penjualan secara kredit. Oleh sebab itu, permintaan untuk menghasilkan jurnal penjualan secara kredit akan harus mencakup tabel penerimaan penjualan dan tunai (kas). Logika dari permintaan akan rnencakup pembatasan hasil sehingga hanya menampilkan penjualan yang tidak berhubungan dengan kegiatan pembayaran pelanggan yang terjadi pada hari yang sama dengan penjualan.

Proses yang sama dapat diikuti untuk menghasilkan jurnal kegiatan seperti pembelian atau pernbayaran.

Pengambilan Informasi dari SIA,,,,(3).

Informasi yang secara tradisional berada pada buku besar, biasanya disimpan pada database relasional dalam kombinasi tabel sumber daya dan kegiatan. Contohnya adalah salah satu jenis buku pembantu yang paling umum: buku pembantu piutang usaha.

Jadi, piutang tidak perlu disimpan secara eksplisit dalam database. Melainkan, jumlah total piutang dapat diperoleh dengan cara menghitung jumlah total penjualan dari pembayaran pelanggan yang belum diterirna.

Tabel DD-2 mendeskripsikan beberapa cara untuk melakukan hal ini, bergantung pnda hubungan antara kegiatan penjualan dan tanda terima kas/uang tunai.Gambar-5-0002-a-dd-2

Pengambilan Informasi dari SIA,,,,(4).

Gambar-5-0002-a-dd-2Logika permintaan dalam Tabel DD-2 menunjukkan jumlah total piutang. Untuk mendapatkan saldo akun untuk setiap pelanggan, logika permintaan harus diperluas ke tabel pelanggan dan mencakup perintah yang sesuai (misalnya “group by” dalam SQL) untuk melakukan perhitungan secara terpisah untuk setiap pelanggan. Hasil dari permintaan seperti ini akan berupa tabel dengan baris untuk setiap pelanggan dan kolom yang menunjukkan saldo pelanggan yang belum dibayar. Permintaan yang lain dapat ditulis untuk menjumlah saldo akun dalam tabel ini, sehingga total piutang dapat dihitung. Prosedur yang sama dapat digunakan untuk memperoleh konsep akuntansi lainnya, seperti piutang, yang mewakili ketidakseimbangan antara dua kegiatan.

Akan tetapi, ingatlah bahwa prosedur untuk menghitung piutang, yang dideskripsikan pada paragraf sebelumnya, tidak harus diikuti setiap kali informasi ini diinginkan. Melainkan, permintaan tersebut hanya perlu ditulis sekali dan setelah diuji keakuratannya, dapat disimpan untuk penggunaan selanjutnya. Bahkan, karena informasi-mengenai ketidakseimbangan intra-kegiatan temporal, seperti piutang dan utang, sangat sering dibutuhkan, kompromi implementasi cenderung dibuat agar saldo akun tidak akan disimpan sebagai atribut yang dihitung dalam tabel yang sesuai.

gbr-table-5-100012-a-dd-8Contohnya, tabel pelanggan yang ditampilkan pada Gambar DD-8 memiliki kolom yang menyimpan saldo akun pelanggan. Hal ini menyederhanakan logika permintaan data yang diperlukan untuk mengetahui piutang, karena hanya tabel pelanggan yang perlu diakses. Untuk menampilkan jumlah utang seorang pelanggan, kita perlu menulis permintaan yang menampilkan baris tertentu dalam tabel pelanggan. Untuk menghitung jumlah total piutang, kita perlu menjumlah kolom saldo akun.

Mengapa Para Pemakai Perlu Berpartisipasi dalam Pembuatan Model Data?

Pembuatan model data bukanlah tugas yang mudah, seperti yang dialami oleh Hewlett-Packard ketika mulai mendesain database baru untuk fungsi akuntansi dan keuangannya. Masalah utamanya adalah istilah yang sama dapat memiliki arti yang berbeda bagi orang yang berbeda. Misalnya, akuntansi menggunakan istilah pesanan (order) untuk mengacu pada jumlah dolar total dari pesanan dalam setiap periode waktu, sedangkan departemen penjualan menggunakan istilah tersebut untuk mengacu pada pesanan pelanggan individual.

Bahkan, kebingungan ini juga muncul dalam fungsi akuntansi dan keuangan. Contohnya kelompok yang melaporkan menggunakan istilah produk untuk mengacu pada barang yang saat itu dijual ke pelanggan. Jadi, kunci utama untuk entitas ini adalah nomor produk. Sebaliknya, kelompok yang membuat peramalan menggunakan istilah produk untuk mengacu pada barang yang masih dalam tahap perencanaan dan belum memiliki nomor produk.

hp-urlUntuk mengatasi masalah ini, Hewlett-Packard meminta berbagai kelompok pemakai untuk secara aktif berpartisipasi dalam proses pembuatan model data. Langkah pertama adalah meyakinkan semua pemakai mengenai perlunya dan keuntungan pembuatan model data untuk fungsi mereka. Selanjutnya, perlu untuk mendefinisikan secara hati-hati mengenai cakupan usaha pembuatan model,

Hewlett-Packard merasakan bahwa waktu yang diinvestasikan dalam tahap awal ini sangat bermanfaat, karena memfasilitasi aktivitas, memperjelas definisi dan mengembangkan daftar atribut yang terjadi pada proses selanjutnya.

Aktivitas selanjutnya merupakan pekerjaan pengulangan yang mencakup banyak revisi. Dokumentasi merupakan hal yang penting dalam proses ini. Setiap anggota tim pemodel dan kelompok pemakai memiliki kopi dari daftar yang diusulkan, yang mempermudah untuk mengetahui inkonsistensi dalam pendefinisian.

Hewlett-Packard mengakui kontribusi yang signifikan dari pendekatan pembuatan model data terhadap kesuksesan keseluruhan proyek. Pembuatan model data membuat para peserta pertama-tama berkonsentrasi pada pemahaman karakteristik bisnis yang penting dalam sistem yang baru, sehingga tidak langsung terhenti dalam penentuan isi tabel relasional.

Hal ini membantu mereka untuk mengidentifikasi dan mengatasi pandangan yang berbeda sejak awal proses, dan membuka jalan ke penerimaan sistem yang dihasilkan. Namun demikian, langkah utamanya adalah melibatkan kelompok pemakai untuk berpartisipasi secara aktif dalam proses pembuatan model data. Jika tidak, model data yang dihasilkan tidak akan akurat atau diterima secara luas.
Sumber: Diadaptasi dari C.Rzndall Byers dan Lysa Beltz, Financial Data modeling at . Hewlett-Packard,” Journal of System Management (january1994) 28-33.

Pengambilan Informasi dari SIA……(5).

Menyediakan Informasi Laporan Keuangan Lainnya. Diagram REA dapat mengarahkan penulisan permintaan untuk menghasilkan informasi lain yang akan dimasukkan dalam laporan keuangan.financial-report-url

Permintaan tabel tunggal dapat menghasilkan banyak jenis laporan keuangan. Contohnya, penjumlahan kolom dalam tabel penjualan akan menghasilkan penjualan untuk periode saat ini.

Akan tetapi, informasi lainnya, misalnya piutang, mungkin perlu meminta beberapa tabel. Dengan membaca dan memahami secara tepat apa yang dinyatakan dalam diagram REA mengenai bagaimana data disimpan, penting untuk mengetahui bagaimana menulis permintaan seperti itu.

Pengambilan Informasi dari SIA……(6).

Menyiapkan Laporan Manajerial. Keuntungan utama dari model data REA adalah perpaduan antara data non-keuangan dan keuangan dalam SIA dan membuat kedua jenis data tersebut mudah diakses oleh manajemen. Contohnya, satu atribut dalam tabel penjualan pada Gambar DD-8 adalah waktu terjadinya penjualan.

gbr-table-5-100012-a-dd-8Manajemen dapat menggunakan data ini untuk mengetahui aktivitas penjualan selama waktu tertentu dalam sehari guna merencanakan kebutuhan staf secara lebih baik. Tabel persediaan penjualan juga mencakup atribut non-keuangan yang berguna: Apakah pembelian tersebut merupakan pembelian ulang atau penggantian (replacement) atau pembelian pertama kali atas suatu produk? Manajemen mungkin dapat menggunakan data ini untuk meningkatkan usaha pemasarannya.

Mereka dapat mengidentifikasikan jenis produk baru yang laris menjadi pengganti dari alat yang tua, dan kemudian mengembangkan iklan tertentu yang akan dikirim ke pelanggan yang telah membeli jenis barang yang tua tetapi belum menggantinya dengan model yang lebih baru.

Pengambilan Informasi dari SIA……(7).

gbr-table-5-100012-a-dd-8Sebagai tambahan, database siklus pendapatan PERUSAHAAN yang ditunjukkan pada Gambar DD-8, DD-9, dan DD-10 juga dapat diperluas dengan mudah guna memadukan data dari sumber eksternal.

Gambar-5-0008-aa-dd-9Contohnya, untuk memperbaiki evaluasi status kredit pelanggan, Manajemen dapat memutuskan untuk mengumpulkan informasi dari lembaga rating kredit (credit rating agency), seperti Dun &- Bradstreet.

Gambar-5-0009-a-1a-dd-10Informasi ini dapat ditambahkan ke database dengan membuat kolom tambahan pada tabel pelanggan untuk menyimpan rating kredit pelanggan. Proses yang sama dapat digunakan untuk menyimpan informasi mengenai pemasok yang dapat digunakan dalam proses seleksi vendor.cust-credit-report-index