E-R Diagram 1

Modul seri 5 & 6 : SIA

DATA MODELING & DATA BASES DESIGN

Disusun oleh :

Syahril Djaddang,SE.,Ak.,M.Si

PROGRAM KULIAH SABUT MINGGU FAKULTAS EKONOMI

UNIVERSITAS MERCU BUANA

JAKARTA

2008

1

Tujuan Instruksional Khusus

Agar mahasiswa dapat menjelaskan :

1. Menggunakan REA sebagai alat design data base

2. Menggunakan E-R diagram

3. Membangun seperangkat table data base dari suatu model REA

4. Membaca E-R diagram dan mengkaitkannya dengan kegiatan usaha.

Materi bahasan:

1. REA (Resource-Event-Agent) Data Model

2. Entity Relationalship (ER) Diagrams

3. Mengembangkan REA diagram

4. Implementasi diagram REA ke data base relational

5. Menggunakan diagram REA

6. Mengintegrasikan diagram REA atas seluruh siklus.

Daftar Pustaka:

1. Marshall B. Romney and Paul John Steinbart, Accounting Information System,8 Edition

2. Buku-buku, System Informasi Akuntansi yang terkait.

Pusat Pengembangan Bahan Ajar - UMB Syahril Djaddang SE.Ak.M.Si SISTEM INFORMASI AKUNTANSI 2

2

MODEL DATA DAN RANCANGAN DATA BASE

I. Model data REA

Data modeling adalah proses pendefinisian dari sebuah database sehingga mewakili

semua aspek dalam organisasi, termasuk interaksi dengan pihak luar.

Model data REA adalah perangkat modeling konseptual yang khususnya didesain untuk

menyediakan struktur untuk mendesain data base dan sistem informasi akuntansi. Model data

REA menyediakan struktur dengan 2 cara :

Mengidentifikasi apakah kesatuan-kesatuan harus dimasukkan dalam data base

AIS.

Dengan penjabaran bagaimana membuat struktur hubungan diantara kesatuan-

kesatuan dalam data base.

Jenis-Jenis Kesatuan

1. Sumber daya

Didefinisikan sebagai hal yang mempunyai nilai ekonomis dalam organisasi, contoh : kas,

inventori, perlengkapan, peralatan dan tanah.

2. Kejadian/Transaksi

Berbagai kegiatan bisnis, yang manajemen lakukan untuk mengumpulkan informasi untuk

perencanaan dan pengawasan. Beberapa transaksi secara langsung mempengaruhi

kuantitas dari sumber-sumber daya. Sebagai contoh : kegiatan penjualan menurunkan

kuantitas inventaris dan kegiatan pengumpulan uang kas meningkatkan sejumlah besar

kas.

3. Agen

Adalah orang-orang dan organisasi yang berpartisipasi dalam setiap kejadian dan kepada

merekalah informasi dibutuhkan untuk perencanaan, pengawasan dan pengevaluasian.

II. Entity-Relationship Diagrams (E-R Diagram)


3

Adalah satu metode untuk menggambarkan sebuah data base dalam bentuk skema.

Disebut E-R diagram karena menunjukkan berbagai model kesatuan dan hubungan penting

diantara mereka. Di dalam sebuah diagram karena menunjukkan berbagai model kesatuan dan

hubungan penting diantara mereka. Di dalam sebuah diagram E-R, kesatuan muncul dalam

bentuk segiempat dan hubungan antara kesatuan-kesatuan digambarkan dalam bentuk

diamond, seperti gambar yang tertera di bawah, yaitu sebuah diagram E-R dari bagian siklus

pendapatan S&S untuk menyederhanakan gambar tersebut kita hanya memasukkan dua

transaksi, yaitu penjualan merchandise untuk pelanggan dan kumpulan uang kas dari

pelanggan.

Resources Evens Agens

III. Mengembangkan Diagram REA

Pengembangan diagram REA untuk siklus transaksi yang spesifik terdiri dari tiga tahap :

1. Mengidentifikasikan setiap kejadian atau transaksi yang mempengaruhi perubahan

dasar ekonomi dalam siklusnya.

2. Mengidentifikasi sumber daya yang mempengaruhi setiap kejadian atau transaksi

beserta agen-agen yang terlibat.

3. Menentukan pokok utama untuk setiap hubungan kerjasama.

Tahap 1 : mengidentifikasikan peristiwa perubahan ekonomi


Inventory Line Items

Sales Partyto

Sales person

Madeto Customer

Receivedfrom

Madeto

Cashier

Cash collectionIncerases

Cash

Receivedby

4

Dasar REA terdiri dari dua peristiwa, yang satu meningkatkan sumber daya yang lainnya

menurunkan sumber daya. Perubahan dasar ekonomi pada siklus pendapatan berhubungan

dengan penjualan barang atau jasa dan penerimaan pembayaran kas dari penjualan.

Gambaran sebuah diagram REA untuk setiap siklus individu, biasanya dengan membagi

kertas kerja menjadi 3 kolom untuk setiap pekerjaan.

1. Kolom kiri untuk sumber daya

2. Kolom tengah untuk peristiwa/transaksi

3. Kolom agen untuk agen

Adalah sangat penting untuk menentukan apakah masih ada peristiwa binis lainnya dalam

siklus tersebut atau tidak.

Tahap 2 : mengidentifikasikan sumber daya dan agen-agen

Satu dan peristiwa penting dapat dispesifikasi, sumber daya yang dipengaruhi oleh

peristiwa tersebut dapat didefinisikan.

Bagaimana dengan Account Receivable ? Ini tidak termasuk dalam peristiwa penting

tersebut, karena account receivable tidak terdapat dalam definisi model data REA. Account

Receivable adalah objek yang tidak bebas, tetapi penyajiannya sederhana pada waktu berbeda

antara dua peristiwa. Yaitu penjualan dan pengumpulan kas. Konsekuensinya, jika data tentang

penjualan dan pengumpulan kas disimpan dalam data base, maka tidak perlu menyimpan

informasi secara berlebihan tentang account receivable.

Tahap 3 : Mengidentifikasi jabatan (cardinalitas)

Jabatan mengidentifikasikan hubungan beberapa kejadian dalam suatu perusahaan

yang dapat dihubungkan dengan kejadian pada perusahaan lain. Beberapa perusahaan dapat

mengimplementasikan kejadian tersebut dalam sebuah table. Pada kenyataannya jabatan

dapat menyediakan informasi tentang bagaimana baris-baris dalam table dari hubungan yang

lain dapat dihubungkan dengan tiap-tiap baris dalam table tersebut, jabatan seringkali

diekspresikan menjadi 2 yaitu jabatan minimum dan jabatan maksium.

Tipe-tipe kerjasama

Menurut maksimum jabatan, ada tiga jenis kerjasama yaitu :

1. A one-to-one relationship atau hubungan antara satuan, jika jabatan maksimum tiap

perusahaan hanya ada satu.


5

A. One-to-one (1:1) Relationship

(0,1) (1,1)

B. One-to-Many (1:N) Relationship Between Sales and Cash Collection

(0,N) (1,1)

B. One-to-Many (1:N) Relationship Between Cash Collection and Sales

(0,1) (1,N)

A. Many-to-Many (M:N) Relationship

(0,N) (1,N)

2. A one-to-many relationship atau hubungan satuan dengan besaran jika jabatan maksimum

dalam suatu perusahaan hanya ada satu dan jabatan maksimum perusahaan lain hanya

ada sebanyak N.

3. A-many-to-many relationship atau hubungan antara besaran, jika jabatan maksimum di

kedua perusahaan sebanyak N.

IV. Penerapan diagram REA dalam data Base Relational

Tahap 1 : Membuat table untuk setiap satuan dan hubungan antara besaran

Tahap 2 : Mengidentifikasi atribut-atribut untuk setiap tabel :

a. Kunci utama. Perusahaan seringkali membuat identifikator numeric (berupa angka)

yang merupakan sumber khusus identifikasi yang unik, kejadian-kejadian dan agen-

agen, identifikator numeric ini merupakan kandidat yang baik sebagai kunci utama.

Sebagai contoh, S&S dapat menggunakan nomor invoice sebagai kunci utama pada

tabel penjualan dan jumlah konsumen sebagai kunci utama pada tabel konsumen.

b. Atribut-atribut lain. Seperti tanggal dan jumlah dari masing-masing penjualan,

diperlukan untuk melengkapi dan mengakuratkan proses transaksi dan produksi

pada pengukuran keuangan dan laporan manajerial. Atribut lain disimpan karena


Sales Pays for

Cash Collactions

Sales Pays for

Cash Collactions

Sales Pays for

Cash Collactions

Sales Pays for

Cash Collactions

6

mereka memberikan fasilitas pada manajemen secara efektif terhadap suatu sumber

organisasi, kejadian dan agen-agen.

c. Data harga. Harga disimpan sebagai tabel pada tabel invetaris.

d. Data komulatif. Jumlah yang tersedia dalam neraca rekening kas tidak perlu dicatat

karena keseluruhan dalam database, karena system dapat menghitung mereka

kapanpun diperlukan.

Tahap 3 : Penerapan hubungan antara satuan dan hubungan satuan dengan besaran.

V. Penggunaan diagram REA

Dokumentasi

Diagram REA kegunaanya sangat khusus sekali misalnya dalam dokumentasi

pembuatan database SIA. Diagram REA memberikan dua tipe yang penting dalam informasi

mengenai data base SIA yang tidak digambarkan di dokumentasi lainnya, yaitu informasi

tentang hubungan antara data dan informasi tentang pelatihan bisnis organisasi.

Diagram REA dengan jelas menggambarkan hubungan antara bermacam-macam data

yang disimpan di dalam data base akuntansi. Berbeda dengan flowchart yang hanya

memperlihatkan bagaimana membuat dan menggambarkan karakteristik utama file, seperti

bagaimana file diatur dan dicatat. Seperti halnya data flow diagram menggambarkan

kandungan atau isi dari masing-masing file dalam sebuah system, tetapi tidak secara jelas

memperlihatkan bagimana file-file itu berhubungan satu dengan lainnya.

Informasi tentang pelatihan bisnis

Mengartikan dengan benar apa yang menjadi utama dalam diagram REA maksudnya

harus mengartikan dengan benar peristiwa apa dalam keseluruhan yang mewakili. Ini selalu

mudah baik bagi agen maupun bagi transaksi secara keseluruhan. Setiap peristiwa dari agen

sebuah entitas mewakili orang yang khusus atau organisasi. Sama seperti, setiap peristiwa dari

kejadian sebuah entitas mewakili aktivitas bisnis yang khusus atau transaksi. Contoh, setiap

peristiwa penjualan mewakili transaksi penjualan yang khusus.

Informasi Tentang Isi Data Base

Diagram REA menggambarkan hubungan antara berbagai data yang disimpan dalam

data base akuntansi, sebaliknya flowchart hanya menunjukkan file yang ada dan

menggambarkan karakter dasar mereka, sebagaimana mereka dikumpulkan dan disimpan.


7

(1,N)

(1,1)

(0,N)

(0,N)

(0,N)

(1,N)

(1,1)(1,N)(1,1)(1,N)

Diagram data flowchart (DFD) menunjukkan isi dari tiap file dalam system, tapi tidak

menunjukkan bagaimana file-file itu berhubungan satu dan lainnya.

Hubungan dalam diagram REA menyediakan informasi yang berguna tentang keadaan

perusahaan dan kebijakan yang dianutnya. Contohnya menyediakan kredit untuk pelanggannya

dan juga mengijinkan mereka untuk melakukan pembayaran secara berkala. Ini juga

mengindikasikan bahwa perusahaan telah menjual barang dalam jumlah yang besar.

Resources Evens Agens

Tabel nama Contents (primary key, foreign keys, other atributes)

Inventory Item #, description, cost, price

Sales Invoice #, salesperson #, customer #, data, amount, time

Salesparson Employee #, name, date hired, salary

Cashier Employee #, name, date hired, salary

Castomer Customer #, name, street, city, state, credit limit

Cash Account #, type, location

Cash collaction Remittance #, customer #, cashier #, account #, data, amount

Sales-Inventory Invoice #, Item #, Quality sold, replacement, age

Sales-cash collections Invoice #, remittance #, amount

Dengan mengetahui tiap-tiap apa yang didapat dari sumber data bagaimanapun, dapat

kadang-kadang lebih sulit, ingat bahwa informasi tentang atribut-atribut yang disimpan dengan

tiap tujuan hubungannya kadang-kadang termasuk dalam diagram REA. Hal ini dapat

digunakan untuk menerjemahkan tujuan dari sumber itu. Dalam Figure 6.7 daftar dari atribut


Inventory Line Items

Sales Partyto

Sales person

Madeto Customer

Receivedfrom

Madeto

Cashier

Cash CollectionIncerases

Inventory

Receivedby

(0,N) (1,N)

(1,1)

8

inventory yang termasuk kuantitasnya. Ini menggambarkan bahwa tiap baris dari inventory

mewakili salah satu macamnya tidak dalam obyek individual.

Baris baris tersebut dapat menyimpan data tentang item yang spesifik, contohnya VCD

Player, dan baris lainnya dapat menyimpan data tentang item spesifik lainnya S&S akan

mengetahui berapa banyak tiap produk ini akan di tangan, konsekuensinya, kuantitas atribut di

tangan akan ditemukan di dalam catatan inventory.

Sekarang kita kaji hubungan antara penjualan dan inventory. Hubungan ini disebut garis

item dan menunjukkan fakta bahwa penjualan melingkupi satu atau lebih barang persediaan,

tiap-tiap mana muncul sebagai garis item terpisah pada Sales in Voice. Kuantitas penjualan

menunjukkan bahwa pelanggan dapat membeli lebih dari satu barang. Figure 6.7 menunjukkan

bahwa 2 pihak (penjual dan pembeli) harus berpartisipasi dalam peristiwa penjualan.

Lihat hubungan antara kas dan pengumpulan kas. Tiap baris dalam satuan kas

menunjukkan akun yang spesifik, yang mana satu baris menyimpan data tentang kas

pemeriksaan reguler S&S, yang lainnya tentang payroll, yang lainnya lagi tentang akan

investasi pasar uang dan seterusnya. Figure 6.7 menggambarkan hubungan antara kas dan

pengumpulan kas sebagai kesatuan, semua pengumpulan kas didepositokan ke akun yang

sama.

Akhirnya pokok dari diagram REA menyediakan informasi tentang kontrol suatu bisnis.

Contohnya dalam Figure 6.7, pokok minimum terhubungkan dengan event penjualan dalam

penjualan pelanggan adalah satu. Ini berarti bahwa transaksi penjualan tidak dapat dicatat

kecuali identitas dari pelanggan juga ikut dicatat.

Spesifikasi Organisasi tentang Diagram REA

Meskipun perkembangan dari diagram REA untuk siklus pendapatan S&S kelihatannya

sudah tegas dan intuitif, model dan dapat menjadi suatu proses yang kompleks. Biasanya

diagram REA adalah unik untuk suatu organisasi. Contohnya S&S tidak menerima pesanan dari

pelanggan. Maksudnya, pelanggan hanya dapat membeli barang-barang yang sudah

ditentukan sebelumnya. Konsekuensinya siklus pendapatan S&S hanya melengkapi 2 item

dasar : Penjualan dan pengumpulan kas, sebaliknya perusahaan pesanan lewat surat

menerima pesanan pelanggan, mengambil barangnya di gudang dan melakukan pengapalan

pesanan itu pada pelanggannya. Untuk itu diagram REA untuk siklus pendapatan dari

perusahaan tersebut melingkupi hal-hal : terima pesanan, mengisi peranan, menghapalkan

pesanan dan mengumpulkan kas. Untuk lebihnya perusahaan retail seperti S&S hanya punya


9

satu inventory, diagram REA untuk perusahaan manufaktur melingkupi kesatuan terpisah untuk

material dan finished goods inventory. Akhirnya karena S&S menjual barang dengan jumlah

besar, model diagram REAnya menunjukkan hubungan antara penjualan dan invetory.

Sebaliknya dengan REA untuk penjualan barang seni langka akan menggambarkan hubungan

antara penjualan dan pengumpulan kas.

Memidahkan Informasi dari SIA

Diagram REA yang lengkap juga menunjukkan panduan berguna dalam menggunakan

data base SIA. Awalnya menunjukkan nomor-nomor dari elemen-elemen yang ditemukan

dalam SIA tradisional seperti jurnal, ledger dan informasi tentang klaim, contohnya kun

receivables. Sebenarnya semua informasi itu disajikan, tapi disimpan di format yang berbeda.

Informasi biasanya ditemukan dalam jurnal yang disimpan dalam tabel untuk

menyimpan data tentang transaksi. Contohnya jurnal penjualan dapat diproduksi dengan

menampilkan masuknya yang diperlukan dalam tabel penjualan. Ini akan menghasilkan daftar

dari semua peristiwa penjualan, yaitu tunai dan kredit, proses serupa dapat dilakukan untuk

memproduksi pengumpulan kas, pembelian atau jurnal pengeluaran kas.

Bentuk informasi secara tradisional biasanya berisi ledger disimpan dalam data base

kombinasi antara sumber dan tabel peristiwa. Pada figure 6.7 tidak menunjukkan tabel eksplisit

yang disebut akun receivable.


10

Kesimpulan

Data modeling adalah proses pendefinisan dari sebuah data base yang mewakili aspek

organisasi model data REA adalah perangkat modeling konseptual yang tugasnya mendisaign

data base dan system informasi.

Model data REA menggambarkan pola dasar bagaimana unsur dalam ketiga kesatuan

(sumber daya, kejadian dan agen) dapat saling berhubungan satu sama lain.

Entity-Relationship Diagrams adalah satu metode untuk menggambarkan sebuah data

base dalam bentuk skema FR menunjukkan model-model kesatuan dan hubungan penting

diantara mereka.

Pengembangan diagram REA dijabarkan dalam 3 tahap yaitu mengidentifikasi peristiwa

perubahan ekonomi, mengidentifikasi sumber daya dan penentuan pokok utama dalam setiap

kerjasama.

Diagram REA menggambarkan hubungan antara berbagai data yang disimpan dalam

data base akuntan, sebaliknya flowcharts, hanya menunjukkan file yang ada dan

menggambarkan karakters dasar mereka, sebagaimana mereka dikumpulkan dan disimpan.

Hubungan dalam diagram REA menyediakan informasi yang berguna tentang keadaan

perusahaan dan kebijakan yang dianutnya.


11

DATA BASE DESIGN

Six Stage of Data Base Design and Operation


Planning Operation and Maintenance

ImplementationRequirments Analysis

Design Coding

12

I S I

Desain Database

Ashton telah belajar melalui seminarnya bahwa desain dan sistem database terdiri dari

enam tahap. Enam tahap tersebut bersifat pengulangan (repatitive). Pada akhirnya akan

ditetapkan waktu selama tahap operasi pengendalian bilan diperlukan untuk perancangan

kembali database. Pada suatu pertimbangan, proses keseluruhan dimulai dengan penelitian

rencana untuk menentukan kelayakan pengguna sistem database. Sekarang kita menguji apa

yang terjadi selama perancangan dari masing-masing tahap database.

1. Perencanaan

Tahap pertama dalam desain database terdiri dari perencanaan awal untuk menentukan

kebutuhan atas kelayakan pengembangan/penggunaan sistem baru. Tujuannya adalah untuk

menentukan apakah sistem yang diajukan memiliki kelayakan yang baik secara teknologi

maupun secara ekonomi. Jika demikian, selanjutnya proyek akan dilanjutkan pada tahap

selanjutnya :

2. Definisi kebutuhan

Definisi kebutuhan melibatkan pemahaman mengenai ruang lingkup dari sistem

database yang diajukan, penentuan kebutuhan hardware (perangkat keras) dan software

(perangkat lunak) secara umum, dan identifikasi kebutuhan pemakai informasi. Ruang lingkup

proyek dijelaskan dalam konsultasi yang berhubungan dengan manajemen dan merefleksikan

kebutuhan informasi organisasi, tujuan strategik. Bila ruang lingkup sistem telah dijelaskan,

informasi mengenai faktor-faktor seperti jumlah pemakai dan volume transaksi digunakan untuk

menentukan kebutuhan sistem baru bagi hardware dan software umum. Data digunakan untuk

penjajakan pandangan individu pada tahap pendahuluan (skema tahap eksternal) yang

merefleksikan kebutuhan pemrosesan transaksi dan kebutuhan pengambilan keputusan.

Desain database harus ditempatkan kedalam sejumlah tujuan. Kelamahannya adalah

database ini tidak selalu memaksimalkan setiap tujuan, seperti halnya pada semua area desain

sistem, dan sistem trade off yang dibutuhkan. Contoh efektivitas biaya mungkin memerlukan

unsur fleksibilitas dan daya akses. Tugas kunci perancang database selanjutnya adalah

mencoba menghasilkan keseimbangan yang memungkinkan diantara beberapa tujuan.

Prosedur pengendalian

- Pla perlindungan virus untuk softwarea


13

- Memperbaharui pengendalian yang sedang berjalan

- Mengamankan arsip perpustakaan dan menyebabkan akses phisic dan arsip data.

- Pemakaian yang tepat label arsip dan menulis mekanisme perlindungan.

Prosedur audit : pemeriksaan sistem

- Periksa dokumentasi untuk fungsi operasi data perpustakaan

- Periksa akses logis kebijakan dan prosedur

- Menguji rencana perbaikan kerusakan

- Mendiskusikan arsip data prosedur pengendalian dengan manager dan operator sistem

informasi.

Prosedur audit : pengujian pengendalian

- Mengamati pemakaian prosedur untuk pengendalian perubahan arsip

- Menyamakan jumlah arsip utama dengan memisahkan jumlah pemeliharaan

pengendalian

- Mengamati dan merevaluasi arsip prosedur pelaksanaan oleh personil operasional.

- Mengamati dan mengevaluasi operasional arsip perpustakaan.

Pengendalian kompensasi

- Pengendalian yang kuat dari pemakai

- Pengendalian yang kuat dari proses

- Pengendalian effective pengamanan komputer

Perangkat Lunak Komputer

Nomor program komputer disebut Computer Audit Software (AS)/Generalized Audit

Software (GAS) yaitu program komputer berdasarkan spesifikasi auditor program penghasilan

yang menampilkan fungsi audit lihat figure II.2 tentang pemakaian CAS oleh pemerintah AS.

Copy Figure II.2

Tujuan utama CAS untuk menolong auditor dalam memeriksa dan memperoleh

informasi arsip komputer lihat table II.7 fungsi umum perangkat lunak komputer audit.

Copy Figure II.4

Figure II.4 memperlihatkan pemakaian CAS pertama auditor tetapkan objek audit, pelajari

berkasnya yang akan yang akan diaudit, mendesain laporan audit dan bagaimana cara

menghitungnya lalu dimasukkan kesistem lewat program data entry oleh CAS dibuat program


14

audit yang akan hasilkan sumber arsip yang digunakan untuk dibuat laporan audit. Contoh

permintaan perangkat lunak audit.

Copy Figure II.5

Pada figure II.5 contoh tampilan pencatatan untuk sistem piutang. Permintaan CAS

diobjektifkan dengan:

1. Beri perhitungan saldo sekarang setiap catatan pelanggan utama melihat saldo sebelumnya

dan melakukan pencocokan transaksi.

2. Menjumlah saldo sekarang, penjualan kredit, pungutan kas, jumlah catatan kredit

3. Tampilkan check yang diperbaiki dalam pilih fields tiap arsip untuk mengkonfirmasi

kenyataan prosedur data yang diperbaiki

4. Periksa arsip transaksi untuk mencatat yang tidak cocok dengan catatan utama

5. Siapkan akun daftar umur piutang dan analisa akun dengan saldo sekarang untuk tahu

kelebihan batas kredit

6. Pilih contoh akun untuk konfirmasi

7. Analisa pungutan CAS dan catatan kredit yang berikut untuk mencoba data pelanggar yang

tidak menanggapi permintaan konfirmasi.

Copy Figure II.6

Figure II.6 menampilkan rangkaian operasi yang dipakai untuk mencapai 6 objektive yang

pertama. RUN 1 menyingkat 4 sumber arsip jadi urutan no akun dan gabungkan jadi master

kombinasi dan arsip transaksi. Pada RUN 2 tampil fungsi:

3. Desain

3.1 Desain Logis

Tahap ketiga dalam desain database adalah desain logis, melibatkan penyelesaian

skema tahap eksternal dan penafsiran mengenai kebutuhan data dari pemakai (user) yang

berbeda dan program aplikasi kedalam skema tahap konseptual. Disini memberikan suatu

kemudahan untuk menciptakan rancangan konseptual melalui pengklasifikasiannya kedalam

bidang-bidang fungsi fungsi utama. Disini dapat dilakukan dengan indentifikasi “kelompok” atau

“cluster” file-file dan program yang merupakan hubungan tertutup satu sama lain dalam bentuk

pemrosesan dan pemanfaatannya.

Sebagai tambahan untuk menspesifikasikan hubungan yang ada diantara unsur-unsur

data, desain logis juga melibatkan perancangan baik pada aspek kunci primer dan sekunder.


15

Kunci primer adalah untuk setiap catatan yang jelas, contoh jumlah konsumen untuk file

konsumen dan jumlah invoice/faktur untuk file invoice. Indentifikasi kunci sekunder tidak

sederhana seperti dijelaskan pada bab 4, kunci sekunder akan dipilih secara akurat karena

penggunaannya mempengaruhi efisiensi pemrosesan database dan pemanggilan informasi.

Kamus data juga dikembangkan selama tahap desain logis. Sebagai tambahan pengawasan

akses untuk pelaksanaan yang dianjurkan harus sesuai dengan spesifikasi database.

3.2. Desain Fisik

Desain fisik, terdiri dari penanganan desain konseptual dan pengalihan (konversi)

kedalam struktur penyimpangan fisik. Pertama, rancangan / skema tahap konseptual diartikan

kedalam suatu rancangan tahap internal. Kedua, kamus data akan terbentuk. Ketiga, data

secara fisik akan disimpan dan diakses. Disini melibatkan keputusan tentang hal-hal seperti

penggunaan pointer dan indeks untuk hubungan pencatatan.

4. Pengkodean

Tahap keempat dari proses desain database terdiri dari terjemahan skema fisik kedalam

struktur database aktual yang akan berada pada sistem akhir.

5. Implementasi

a. Implementasi terdiri dari semua aktivitas yang diasosiasikan dengan mendapatkan

sistem database baru yang bekerja.

b. Mencoba sistem baru.

c. Mengirim data dari file yang ada kedtabase baru.

d. Melatih karyawan bagaimana menggunakan sistem yang baru.

6. Pelaksanaan dan Operasional

Dua tahap proses desain database terakhir adalah pelaksanaan dan operasional. Tahap

pelaksanaan terdiri dari semua kegiatan yang berhubungan dengan sistem penerapan

database baru. Beberapa aspek disini mencakup pentransferan data dari file-file yang ada ke

database baru, pengembangan program aplikasi baru, dan modifikasi sitem yang ada, latihan

pemakai: “bagaimana menggunakan sistem baru”. Tahap operasional mencakup semua

kegiatan yang berhubungan dengan penerapan dan pengendalian sistem baru.


16

Desain Data Base Objektif

1. Kelengkapan

Data base harus berisikan semua data yang diperlukan (dan hubungan antara data) oleh

bermacam-macam pemakai. Seharusnya ada integrasi yang baik dan koordinasi dari semua

pemakai dan penyedia data. Data yang berada didalam database harus direkam ke kamus

data.

2. Hubungan

Hanya data yang berhubungan dan berguna yang diambil dan disimpan.

3. Kemudahan

Penyimpanan data dapat diakses oleh seluruh pemakai resmi tepat waktu.

4. Up to date

Penyimpanan data harus selalu pasti dan selalu baru.

5. Fleksibel

Data base harus selalu fleksibel karena bervariasinya pemakai agar dapat memuaskan

keperluan informasi.

6. Efisiensi

Penyimpanan data harus diselesaikan seefisien mungkin, menggunakan sejumlah sumber-

sumber yang diperlukan. Pembaharuan database, pencarian informasi, dan pemeliharaan

waktu harus diperkecil.

7. Biaya efektif

Data harus disimpan agar keuntungan sistem didapatkan pada biaya yang rendah.

8. Integrasi

Database harus bebas dari eror dan kerusakan.

9. Keamanan

Data base harus dilindungi dari kehilangan, kehancuran, dan akses tidak dikenal. Cadangan

dan prosedur pemulihan harus ditempat agar database dapat dibangun kembali jika perlu.

Kesimpulan

Akuntansi biasanya dilibatkan pada semua tahap proses desain database kecuali desain

fisik. Dalam tahap perencanaan, memberikan beberapa informasi yang digunakan menilai

kelayakan proyek yang diajukan dan turut serta dalam indentifikasi mengenai kebutuhan

informasi, pengembangan rancangan dan kamus data dan spesifikasi kontrol. Selama tahap

pelaksanaan, akuntan dilibatkan dalam pengujian keakuratan database baru dan program


17

aplikasi yang akan dijadikan data. Terakhir, akuntan menggunakan sistem database untuk

memproses transaksi dan seringkali membantu mengembangkannya.


E-R Diagram 1

Documents

Transcript of E-R Diagram 1