Ebook Audit SI CHPTR 8 (Id)

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.
com
BAB 8
Struktur Data dan CAATT
untuk Ekstraksi Data
TUJUAN PEMBELAJARAN
Setelah mempelajari bab ini, Anda harus:
• Memahami komponen struktur data dan bagaimana komponen tersebut digunakan untuk
mencapai operasi pemrosesan data.
• Memahami struktur yang digunakan dalam sistem file datar, termasuk struktur sekuensial,
indeks, hashing, dan penunjuk.
• Memahami struktur database relasional dan prinsip normalisasi.
• Memahami fitur, kelebihan, dan kekurangan pendekatan modul audit tertanam untuk
ekstraksi data.
• Mengetahui kemampuan dan fitur utama perangkat lunak audit umum.
• Menjadi akrab dengan fitur-fitur ACL yang lebih umum digunakan.
T bab ini membahas struktur data dan penggunaan CAATT untuk ekstraksi
dan analisis data. Bab ini dibuka dengan tinjauan struktur data, yang
merupakan susunan fisik dan logis data dalam file dan database. File datar,
database navigasi, dan struktur database relasional diperiksa. Banyak
perhatian diberikan pada database relasional, karena ini adalah struktur
data yang paling umum digunakan oleh organisasi bisnis modern.
Cakupannya mencakup konsep relasional, terminologi, teknik penautan
tabel, normalisasi basis data, dan prosedur desain basis data.
Memahami bagaimana data diatur dan diakses adalah inti dari penggunaan CAATT
ekstraksi data. Auditor memanfaatkan alat-alat ini secara ekstensif dalam mengumpulkan
data akuntansi untuk menguji pengendalian aplikasi dan dalam melakukan pengujian
substantif. Pada bab sebelumnya kita mempelajari bagaimana CAATT digunakan untuk
menguji kontrol aplikasi secara langsung. Alat ekstraksi data yang dibahas dalam bab ini
digunakan untuk menganalisis data yang diproses oleh suatu aplikasi, bukan aplikasi itu
sendiri. Dengan menganalisis data yang diambil dari file komputer, auditor dapat
membuat kesimpulan tentang keberadaan dan fungsionalitas pengendalian dalam
aplikasi yang memproses data.
327
Hak Cipta 2011 Cengage Learning, Inc. Semua Hak Dilindungi Undang-undang. Tidak boleh disalin, dipindai, atau diduplikasi, seluruhnya atau sebagian.
328 Bab 8:Struktur Data dan CAATT untuk Ekstraksi Data
Kegunaan penting lainnya dari perangkat lunak ekstraksi data adalah dalam melakukan
pengujian substantif. Sebagian besar pengujian audit terjadi pada fase pengujian substantif
audit. Prosedur-prosedur ini disebuttes substantifkarena digunakan untuk, namun tidak
terbatas pada, hal-hal berikut:
• Menentukan nilai persediaan yang benar.

• Menentukan keakuratan pembayaran di muka dan akrual.
• Konfirmasi piutang dengan pelanggan.
• Mencari kewajiban yang tidak tercatat.
CAATT untuk perangkat lunak ekstraksi data terbagi dalam dua kategori
umum: modul audit tertanam dan perangkat lunak audit umum. Bab ini
menjelaskan fitur, kelebihan, dan kekurangan pendekatan modul audit tertanam
(EAM). Ini kemudian menguraikan fungsi-fungsi khas dan penggunaan
perangkat lunak audit umum (GAS). Bab ini ditutup dengan tinjauan fitur utama
ACL (bahasa perintah audit), produk unggulan di pasar GAS.
STRUKTUR DATA
Struktur datamemiliki dua komponen mendasar: organisasi dan metode akses. Organisasimengacu
pada cara catatan disusun secara fisik pada perangkat penyimpanan sekunder. Ini mungkin salah
satunyasekuensialatauacak. Catatan dalam file berurutan disimpan di lokasi yang berdekatan yang
menempati area ruang disk tertentu. Catatan dalam file acak disimpan tanpa memperhatikan
hubungan fisiknya dengan catatan lain dari file yang sama. File acak mungkin memiliki catatan yang
didistribusikan ke seluruh disk. Itumetode aksesadalah teknik yang digunakan untuk menemukan
catatan dan menavigasi database atau file. Meskipun ada beberapa teknik khusus yang digunakan,
secara umum, teknik tersebut dapat diklasifikasikan menjadi metode akses langsung atau akses
sekuensial.
Karena tidak ada satu struktur pun yang terbaik untuk semua tugas pemrosesan, struktur berbeda
digunakan untuk menyimpan berbagai jenis data akuntansi. Oleh karena itu, pemilihan suatu struktur
melibatkan trade-off antara fitur-fitur yang diinginkan. Kriteria yang mempengaruhi pemilihan struktur data
tercantum pada Tabel 8.1.
Pada bagian berikut, kami memeriksa beberapa struktur data. Ini dibagi antara sistem file datar
dan database. Dalam praktiknya, organisasi dapat menggunakan salah satu pendekatan ini dalam
berbagai kombinasi untuk menyimpan data akuntansi mereka.
TABEL 8.1
Operasi Pemrosesan File
1. Ambil catatan dari file berdasarkan kunci utamanya.
2. Masukkan catatan ke dalam file.
3. Perbarui catatan dalam file.
4. Membaca file catatan secara lengkap.
5. Temukan catatan berikutnya dalam file tersebut.
6. Pindai file untuk mencari catatan dengan kunci sekunder umum.
7. Hapus catatan dari file.
Struktur data 329
Struktur File Datar
Ingat dari Bab 4 bahwa model file datar menggambarkan lingkungan di mana file data individual tidak
terintegrasi dengan file lain. Pengguna akhir di lingkungan ini memiliki file datanya sendiri, bukan
membaginya dengan pengguna lain. Pemrosesan data dengan demikian dilakukan oleh aplikasi yang
berdiri sendiri dan bukan sistem yang terintegrasi. Pendekatan file datar adalah model tampilan
tunggal yang menjadi ciri sistem lama. File data disusun, diformat, dan diatur agar sesuai dengan
kebutuhan spesifik pemilik atau pengguna utama. Namun, penataan seperti itu dapat menghilangkan
atau merusak atribut data yang penting bagi pengguna lain, sehingga menghambat keberhasilan
integrasi sistem di seluruh organisasi.
Struktur Berurutan
Gambar 8.1 mengilustrasikanstruktur berurutan, yang biasanya disebutmetode akses
berurutan. Dalam pengaturan ini, misalnya, record dengan nilai kunci 1875 ditempatkan di
ruang penyimpanan fisik segera setelah record dengan nilai kunci 1874. Dengan demikian,
semua record dalam file terletak di ruang penyimpanan yang berdekatan dalam urutan tertentu
(menaik atau menurun). diatur oleh kunci utama mereka.
File sekuensial sederhana dan mudah diproses. Aplikasi dimulai di awal file dan
memproses setiap record secara berurutan. Dari operasi pemrosesan file pada Tabel 8.1,
pendekatan ini efisien untuk Operasi 4 dan 5, yang masing-masing membaca seluruh file dan
menemukan catatan berikutnya dalam file. Selain itu, ketika sebagian besar file (mungkin 20
persen atau lebih) akan diproses dalam satu operasi, struktur sekuensial efisien untuk
memperbarui catatan (Operasi 3 pada Tabel 8.1). Contohnya adalah pemrosesan penggajian,
dimana 100 persen catatan karyawan pada file penggajian diproses setiap periode penggajian.
Namun, ketika hanya sebagian kecil dari file (atau satu catatan) yang sedang diproses,
pendekatan ini tidak efisien. Struktur sekuensial bukanlah pilihan praktis untuk operasi lainnya
yang tercantum pada Tabel 8.1. Misalnya, mengambil satu record (Operasi 1) dari file berurutan
memerlukan pembacaan semua record yang mendahului record yang diinginkan. Rata-rata, ini
berarti membaca separuh file setiap kali satu rekaman diambil. Metode akses sekuensial tidak
mengizinkan pengaksesan rekaman secara langsung. File yang memerlukan operasi akses
langsung memerlukan struktur data yang berbeda. Struktur data berikut menjawab kebutuhan
ini.
GAMBAR 8.1 Penyimpanan Berurutan dan Metode Akses
Catatan Dibaca Secara Berurutan
Kunci Kunci Kunci

Data yang lain Data yang lain Data yang lain
1874 1875 1876
Kunci Berurutan (dalam

hal ini, urutan menaik)
Struktur Terindeks
Sebuahstruktur yang diindeksDinamakan demikian karena, selain file data aktual,
terdapat indeks terpisah yang merupakan file alamat rekaman. Indeks ini berisi nilai
numerik lokasi penyimpanan disk fisik (silinder, permukaan, dan blok rekaman) untuk
setiap rekaman dalam file data terkait. File data itu sendiri dapat disusun secara berurutan
atau acak. Gambar 8.2 menyajikan contoh file acak yang diindeks.
Catatan dalam sebuahfile acak yang diindekstersebar ke seluruh disk tanpa
memperhatikan kedekatan fisiknya dengan catatan terkait lainnya. Faktanya, catatan milik file
yang sama mungkin berada di disk yang berbeda. Lokasi fisik suatu catatan tidak penting
selama perangkat lunak sistem operasi dapat menemukannya saat diperlukan. Lokasi ini
dicapai dengan mencari indeks untuk nilai kunci yang diinginkan, membaca lokasi penyimpanan
(alamat) yang sesuai, dan kemudian memindahkan kepala baca-tulis disk ke lokasi alamat.
Ketika catatan baru ditambahkan ke file, perangkat lunak manajemen data memilih lokasi disk
yang kosong, menyimpan catatan, dan menambahkan alamat baru ke indeks.
Organisasi fisik indeks itu sendiri dapat berupa berurutan (berdasarkan nilai kunci) atau
acak. Indeks acak lebih mudah dipelihara, dalam hal penambahan catatan, karena catatan kunci
baru hanya ditambahkan ke akhir indeks tanpa memperhatikan urutannya. Indeks dalam
urutan berurutan lebih sulit dipertahankan karena kunci rekaman baru harus disisipkan di
antara kunci yang sudah ada. Salah satu keuntungan dari indeks sekuensial adalah dapat dicari
dengan cepat. Karena susunannya yang logis, algoritma dapat digunakan untuk mempercepat
pencarian melalui indeks untuk menemukan nilai kunci. Keuntungan ini menjadi sangat penting
untuk file data besar dengan indeks besar yang sesuai.
GAMBAR 8.2 Struktur File Acak Terindeks
Perangkat Penyimpanan Disk Fisik
Indeks
Nilai Kunci Catatan

1876
Alamat
Silinder, permukaan,
1876 2219
catatan #
1956 97, 14, 128

2130
2219 102, 03, 200
5521 06, 10, 501 1956
1124 125, 02, 16
1872 200, 12, 350 1124
2130 04, 06, 87
Struktur data 331
Keuntungan utama dari file acak yang diindeks adalah dalam operasi yang melibatkan
pemrosesan catatan individual (Operasi 1, 2, 3, dan 6 pada Tabel 8.1). Keuntungan lainnya
adalah penggunaan penyimpanan disk yang efisien. Arsip dapat ditempatkan dimanapun
terdapat ruang tanpa memperhatikan lokasi penyimpanan yang berdekatan. Namun, file acak
bukanlah struktur yang efisien untuk operasi yang melibatkan pemrosesan sebagian besar file.
Banyak waktu akses mungkin diperlukan untuk mengakses seluruh file rekaman yang tersebar
secara acak ke seluruh perangkat penyimpanan. File sekuensial lebih efisien untuk tujuan ini.
ItuMetode akses Penyimpanan Virtual (VSAM)struktur digunakan untuk file yang sangat besar yang
memerlukan pemrosesan batch rutin dan pemrosesan rekaman individual tingkat sedang. Misalnya, file
pelanggan dari perusahaan utilitas publik akan diproses dalam mode batch untuk tujuan penagihan dan
diakses langsung sebagai respons terhadap pertanyaan pelanggan individual. Karena organisasinya yang
berurutan, struktur VSAM dapat dicari secara berurutan untuk pemrosesan batch yang efisien. Gambar 8.3
mengilustrasikan bagaimana VSAM menggunakan indeks untuk memungkinkan pemrosesan akses langsung.
Struktur VSAM digunakan untuk file yang sering menempati beberapa silinder penyimpanan
yang berdekatan pada disk. Untuk menemukan lokasi rekaman tertentu, file VSAM menggunakan
sejumlah indeks yang menggambarkan secara ringkas isi setiap silinder. Misalnya, pada Gambar 8.3,
kita mencari record dengan nilai kunci 2546. Metode akses pertama-tama menuju ke indeks file
keseluruhan, yang hanya berisi nilai kunci tertinggi untuk setiap silinder dalam file, dan menentukan
bahwa Record 2546 adalah di suatu tempat di Silinder 99. Pemindaian cepat indeks permukaan untuk
Silinder 99 mengungkapkan bahwa catatannya ada di Permukaan 3 Silinder 99. Indeks VSAM tidak
memberikan alamat fisik yang tepat untuk satu
GAMBAR 8.3 VSAM Digunakan untuk Akses Langsung
VSAM – Metode Akses Penyimpanan Virtual
Mencari Kunci 2546
Indeks Silinder Indeks Permukaan

Silinder 99
Kunci silinder Kunci Permukaan

Jangkauan Nomor Jangkauan Nomor
Cari Jalur 99
1100 97 2300 0 di Permukaan 3 dari
Silinder 99
2200 98 2400 1
secara berurutan. Kami
3300 99 2500 2 tidak memiliki

alamat tertentu
4400 100 2600 3 Catatan (kunci) 2546.
2700 4
9999 120
catatan. Namun, mereka mengidentifikasi jalur disk tempat rekaman tersebut berada. Langkah terakhir adalah
mencari track yang teridentifikasi secara berurutan untuk menemukan record dengan nilai kunci 2546.
Struktur VSAM cukup efektif untuk Operasi 1 dan 3 pada Tabel 8.1. Karena VSAM harus membaca
beberapa indeks dan mencari trek secara berurutan, waktu akses rata-rata untuk satu catatan lebih
lambat dibandingkan struktur berurutan yang diindeks atau acak yang diindeks. Kecepatan akses
langsung dikorbankan untuk mencapai kinerja yang sangat efisien dalam Operasi 4, 5, dan 6.
Kerugian terbesar dari struktur VSAM adalah ia tidak melakukan operasi penyisipan
catatan (Operasi 2) secara efisien. Karena file VSAM diatur secara berurutan, memasukkan
catatan baru ke dalam file memerlukan relokasi fisik semua catatan yang terletak di luar titik
penyisipan. Oleh karena itu, indeks yang menggambarkan pengaturan fisik ini juga harus
diperbarui pada setiap penyisipan. Hal ini sangat memakan waktu dan mengganggu
operasional. Salah satu metode untuk mengatasi masalah ini adalah dengan menyimpan
catatan baru di area overflow yang secara fisik terpisah dari catatan data lain dalam file.
Gambar 8.4 menunjukkan bagaimana hal ini dilakukan.
File VSAM memiliki tiga komponen fisik: indeks, area penyimpanan data utama, dan
area overflow. Daripada menyisipkan rekaman baru langsung ke area utama, perangkat
lunak manajemen data menempatkannya di lokasi yang dipilih secara acak di area luapan.
Kemudian mencatat alamat lokasi di bidang khusus (disebut apenunjuk) di area utama.
Nantinya, saat mencari record, indeks mengarahkan metode akses ke lokasi track tempat
record tersebutsebaiknyatinggal. Penunjuk di lokasi itu mengungkapkan catatan itu
sebenarnyalokasinya di daerah luapan. Dengan demikian, mengakses suatu catatan
mungkin melibatkan pencarian indeks, pencarian jalur di area data utama, dan akhirnya
GAMBAR 8.4 Memasukkan Catatan ke dalam File VSAM
Kunci 223 Kunci 224 Kunci 225
Kunci 235 Kunci 238 Kunci 239 Meluap

Daerah
D
Di dalam
mantan
Kunci 240 Kunci 241
Kunci 237
PriSaya
AreA
Kunci 269 Kunci 270
Masukkan Record Baru dengan Nilai Kunci = 237
Struktur data 333
mencari daerah luapan. Hal ini memperlambat waktu akses data untuk akses langsung dan
pemrosesan batch.
Secara berkala, file VSAM harus ditata ulang dengan mengintegrasikan catatan overflow ke
dalam area utama dan kemudian merekonstruksi indeks. Proses ini melibatkan waktu, biaya, dan
gangguan terhadap operasi. Oleh karena itu, ketika suatu file sangat fluktuatif (catatan sering
ditambahkan atau dihapus), beban pemeliharaan yang terkait dengan pendekatan VSAM cenderung
menjadikannya tidak praktis. Namun, untuk file besar dan stabil yang memerlukan akses langsung
dan pemrosesan batch, struktur VSAM adalah pilihan yang populer.
Struktur Hashing
Astruktur hashingmenggunakan algoritma yang mengubah kunci utama suatu catatan secara
langsung menjadi alamat penyimpanan. Hashing menghilangkan kebutuhan akan indeks terpisah.
Dengan menghitung alamat, daripada membacanya dari indeks, catatan dapat diambil dengan lebih
cepat. Gambar 8.5 mengilustrasikan pendekatan hashing.
Contoh ini mengasumsikan file inventaris dengan 100.000 item inventaris. Algoritma membagi
nomor inventaris (kunci utama) menjadi bilangan prima. Ingatlah bahwa bilangan prima adalah
bilangan yang hanya dapat dibagi oleh dirinya sendiri dan 1 tanpa meninggalkan nilai sisa. Oleh
karena itu, perhitungannya akan selalu menghasilkan suatu nilai yang dapat diterjemahkan ke dalam
lokasi penyimpanan. Oleh karena itu, sisa 6.27215705 menjadi Silinder 272, Permukaan 15, dan Nomor
Catatan 705. Struktur hashing menggunakan organisasi file acak karena proses penghitungan sisa
dan mengubahnya menjadi lokasi penyimpanan menghasilkan alamat catatan yang tersebar luas.
GAMBAR 8.5
hashing
Teknik dengan
Penunjuk ke
Pindahkan
Tabrakan
Catatan
15943
Nilai Kunci yang Dicari

– 15943
an
ak
br
Ta
hashing
uk
nj
Teknik
nu
Pe
Perdana #/ Kunci
= 99997/15943 = 6,27215705
Catatan yang Direlokasi
Residu Diterjemahkan menjadi:
Silinder 272 Rekam dengan Alamat Hash yang
Permukaan 15 Sama seperti 15943
Rekam #705
Keuntungan utama dari hashing adalah kecepatan akses. Menghitung alamat record lebih cepat
dibandingkan mencarinya melalui indeks. Struktur ini cocok untuk aplikasi yang memerlukan akses
cepat ke catatan individual dalam melakukan Operasi 1, 2, 3, dan 6 pada Tabel 8.1.
Struktur hashing memiliki dua kelemahan signifikan. Pertama, teknik ini tidak menggunakan
ruang penyimpanan secara efisien. Lokasi penyimpanan yang dipilih untuk suatu record adalah fungsi
matematika dari nilai kunci primernya. Algoritme tidak akan pernah memilih beberapa lokasi disk
karena lokasi tersebut tidak sesuai dengan nilai kunci yang sah. Sebanyak sepertiga dari paket disk
mungkin terbuang sia-sia.
Kerugian kedua adalah kebalikan dari kerugian pertama. Kunci rekaman yang berbeda mungkin
menghasilkan sisa yang sama (atau serupa), yang diterjemahkan ke dalam alamat yang sama. Ini
disebut a tabrakankarena dua catatan tidak dapat disimpan di lokasi yang sama. Salah satu solusi
untuk masalah ini adalah dengan memilih secara acak lokasi untuk rekaman kedua dan menempatkan
penunjuk ke sana dari lokasi pertama (yang dihitung). Teknik ini diwakili oleh panah gelap pada
Gambar 8.5.
Masalah tabrakan memperlambat akses ke catatan. Menemukan lokasi rekaman yang
dipindahkan dengan cara ini melibatkan penghitungan alamat teoretisnya terlebih dahulu, mencari
lokasi tersebut, dan kemudian menentukan alamat sebenarnya dari penunjuk yang terdapat dalam
rekaman di lokasi tersebut. Hal ini mempunyai implikasi tambahan untuk Operasi 7 pada Tabel 8.1—
menghapus record dari file. Jika record pertama dihapus dari file, penunjuk ke record kedua
(tabrakan) juga akan terhapus dan alamat record kedua akan hilang. Hal ini dapat diatasi dengan dua
cara: (1) Setelah menghapus rekaman pertama, rekaman tabrakan dapat dipindahkan secara fisik ke
alamat terhitungnya, yang sekarang kosong; atau (2) Catatan pertama ditandai “dihapus” tetapi
dibiarkan di tempatnya untuk mempertahankan penunjuk ke catatan tabrakan.
Struktur Penunjuk
Gambar 8.6 menyajikanstruktur penunjuk, yang dalam contoh ini digunakan untuk
membuat a file daftar tertaut. Pendekatan ini menyimpan dalam bidang satu catatan
alamat (penunjuk) dari catatan terkait. Catatan dalam jenis file ini tersebar di seluruh disk
tanpa memperhatikan kedekatan fisiknya dengan catatan terkait lainnya. Pointer
menyediakan koneksi antar record. Dalam contoh ini, Record 124 menunjuk ke lokasi
Record 125, Record 125 menunjuk ke 126, dan seterusnya. Catatan terakhir dalam daftar
berisi penanda akhir file.
Pointer juga dapat digunakan untuk menghubungkan catatan antar file. Gambar 8.7
menunjukkan catatan piutang dengan tiga petunjuk. Penunjuk pertama menghubungkan data AR ke
data AR berikutnya dalam file AR. Petunjuk kedua dan ketiga masing-masing menghubungkan catatan
AR ke catatan faktur penjualan dan catatan pengiriman uang. Dengan mengakses catatan piutang
(misalnya, Pelanggan 4456), kami dapat menemukan semua faktur penjualan dan pengiriman uang
yang berkaitan dengan rekening tersebut. Catatan-catatan ini kemudian dapat ditampilkan pada layar
komputer atau dicetak untuk ditinjau. Catatan transaksi berikutnya (penjualan atau penerimaan kas)
yang akan diproses akan ditambahkan ke akhir daftar tertaut yang sesuai. Alamat catatan kemudian
akan disimpan dalam catatan sebelumnya untuk memberikan akses di masa depan.
Jenis Pointer.Gambar 8.8 menunjukkan tiga jenis penunjuk: alamat fisik, alamat relatif, dan
penunjuk kunci logis. Apenunjuk alamat fisikberisi lokasi penyimpanan disk sebenarnya
(silinder, permukaan, dan nomor rekaman) yang diperlukan oleh pengontrol disk. Alamat fisik
ini memungkinkan sistem untuk mengakses catatan secara langsung tanpa memperoleh
informasi lebih lanjut. Metode ini memiliki keuntungan dalam hal kecepatan, karena tidak perlu
dimanipulasi lebih lanjut untuk menentukan lokasi rekaman. Namun, ini juga memiliki dua
kelemahan: Pertama, jika catatan terkait dipindahkan dari satu lokasi disk ke lokasi lain,
penunjuknya harus diubah. Ini adalah masalah ketika disk diatur ulang secara berkala atau
Struktur data 335
GAMBAR 8.6
File Daftar Tertaut
Rekor Pertama dalam Daftar
124 Data
Penunjuk untuk Merekam 125 Rekor Terakhir dalam Daftar
E
128 Data HAI
F
126 Data
127 Data
125 Data
GAMBAR 8.7 Pointer di dalam dan di antara File
Akun
Rekor Sebelumnya 4456 Data Rekam Berikutnya
Piutang
Mengajukan
Penunjuk ke Catatan Saran Pengiriman Uang Penunjuk ke Rekaman Berikutnya
Penunjuk ke Catatan Faktur Penjualan
Penjualan
Faktur Penjualan Pertama Faktur Penjualan Berikutnya Faktur Penjualan Berikutnya
EOF
Faktur
untuk Pelanggan 4456 untuk Pelanggan 4456 untuk Pelanggan 4456
Mengajukan
Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya
Pengiriman uang
Saran Pengiriman Uang Berikutnya Saran Pengiriman Uang Berikutnya
EOF
Saran Pengiriman Uang Pertama

untuk Pelanggan 4456 untuk Pelanggan 4456
Nasihat
untuk Pelanggan 4456
Mengajukan
Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya
GAMBAR 8.8 Jenis Pointer
Penunjuk Alamat Fisik
CYL 121
Rekam 1 Permukaan05 Rekam 1
Catatan 750
Alamat fisik
Penunjuk Alamat Relatif
135 Rekor pertama
•
•
•
Konversi
Rekam 135 Sekuensial
Rutin
Mengajukan
Penunjuk ke 135
Rekam dalam File ••
Rekor Terakhir
Penunjuk Kunci Logis
Kunci hashing Catatan

9631 Algoritma 9631
disalin. Kedua, petunjuk fisik tidak memiliki hubungan logis dengan catatan yang mereka identifikasi. Jika
sebuah pointer hilang atau hancur dan tidak dapat dipulihkan, rekaman yang direferensikannya juga akan
hilang.
Apenunjuk alamat relatifberisi posisi relatif suatu record dalam file. Misalnya,
penunjuk dapat menentukan catatan ke-135 dalam file. Ini harus dimanipulasi lebih lanjut
untuk mengubahnya menjadi alamat fisik sebenarnya. Perangkat lunak konversi
menghitung ini dengan menggunakan alamat fisik awal file, panjang setiap catatan dalam
file, dan alamat relatif dari catatan yang dicari.
Apenunjuk kunci logisberisi kunci utama dari catatan terkait. Nilai kunci ini
kemudian diubah menjadi alamat fisik rekaman dengan algoritma hashing.
Struktur Basis Data Hirarki dan Jaringan

Model basis data hierarki dan jaringan awal menggunakan banyak teknik file datar sebelumnya
serta struktur basis data kepemilikan baru. Perbedaan utama antara kedua pendekatan ini
adalah tingkat integrasi proses dan berbagi data yang dapat dicapai. File datar dua dimensi ada
sebagai struktur data independen yang tidak terhubung secara logis atau fisik ke file lain. Model
database dirancang untuk mendukung sistem file datar yang sudah ada, sekaligus
memungkinkan organisasi untuk beralih ke tingkat integrasi data yang baru.
Struktur data 337
Dengan menyediakan hubungan antara file yang terkait secara logis, dimensi ketiga (kedalaman)
ditambahkan untuk melayani kebutuhan banyak pengguna dengan lebih baik. Misalnya, Gambar 8.7
mengilustrasikan penggunaan pointer antar file dalam contoh struktur database hierarki sederhana. Contoh
struktur database jaringan yang kompleks diilustrasikan pada Gambar 8.9.
Gambar 8.9 mengilustrasikan hubungan banyak ke banyak antara file inventaris dan file vendor.
Setiap vendor memasok banyak item inventaris dan setiap item dipasok oleh lebih dari satu vendor.
Perhatikan bahwa setiap catatan inventaris dan vendor hanya ada satu kali, namun ada catatan tautan
terpisah untuk setiap item yang disuplai oleh vendor dan untuk setiap pemasok item inventaris
tertentu. Susunan petunjuk ini memungkinkan kita menemukan semua vendor dari item inventaris
tertentu dan semua inventaris yang dipasok oleh masing-masing vendor.
File tautan juga mungkin berisi data akuntansi. Misalnya, file tautan pada Gambar 8.9
menunjukkan bahwa harga untuk Nomor Inventaris 1356 dari Vendor Nomor 1 ($10) tidak sama
dengan harga yang dibebankan oleh Vendor Nomor 3 ($12). Demikian pula, waktu pengiriman (waktu
tunggu hari) dan diskon yang ditawarkan (syarat) berbeda. Karakteristik transaksi seperti ini dapat
bervariasi antar vendor dan bahkan antar item berbeda dari vendor yang sama. Data yang unik untuk
asosiasi item-vendor disimpan dalam rekaman file tautan unik, seperti yang ditunjukkan dalam
gambar.
GAMBAR 8.9 File Tautan dalam Hubungan Banyak-ke-Banyak
File Inventaris
Menemukan # Menemukan # Menemukan #
1356 1730 2512
Tautan Vendor Tautan Vendor
Tautan Inventaris Tautan Inventaris
Tautan Inventaris
Inventaris/Vendor
Tautan Berkas
hari- hari-
Unik Unik Unik Memimpin Ketentuan Biaya Memimpin Ketentuan Biaya Unik
Data Data Data Waktu 2/10/20 10 Waktu 15/2/30 12 Data
5 3
Tautan Inventaris Tautan Inventaris Tautan Vendor
Tautan Vendor Tautan Vendor
Tautan Inventaris
Penjual #1 Penjual #2 Penjual #3
Tautan Vendor
File Penjual
GAMBAR 8.10 File Sekuensial Terindeks
Indeks Jumlah Kosong Meja Karyawan Indeks Pendapatan YTD
Kunci Catatan Em Keahlian YTD Kunci

Nilai Alamat Nomor
Nama Alamat Kode Pendapatan Nilai Alamat
101 1 101 L.Smith 15 Jalan Utama. 891 15000 20.000 3

102 2 102 S.Buell 107 Puncak Bukit 379 10.000 19000 4
103 3 103 T.Bukit 40 Jalan Barclay. 891 20.000 18000 5
104 4 104 M.Hijau 251 Jalan Ule. 209 19000 15000 1
105 5 105 H.Litt 423 Jalan Rauch. 772 18000 10.000 2
Struktur, Konsep, dan Terminologi Basis Data Relasional
Bagian berikut ini membahas prinsip-prinsip yang mendasari model database relasional dan teknik,
aturan, dan prosedur untuk membuat tabel relasional. Anda juga akan melihat bagaimana tabel
ditautkan ke tabel lain untuk memungkinkan representasi data yang kompleks.
Basis data relasional didasarkan padafile sekuensial yang diindeksstruktur. Struktur ini,
diilustrasikan pada Gambar 8.10, menggunakan indeks bersama dengan organisasi file
berurutan. Ini memfasilitasi akses langsung ke catatan individual dan pemrosesan batch
seluruh file. Beberapa indeks dapat digunakan untuk membuat referensi silang, yang disebut
daftar terbalik,yang memungkinkan akses lebih fleksibel ke data. Dua indeks ditunjukkan pada
Gambar 8.10. Satu berisi nomor karyawan (kunci utama) untuk menemukan lokasi catatan
dalam file secara unik. Indeks kedua berisi alamat catatan yang disusun berdasarkan
pendapatan tahun ini. Menggunakan bidang tidak unik ini sebagai kunci sekunder
memungkinkan semua catatan karyawan dilihat dalam urutan menaik atau menurun menurut
penghasilan. Sebagai alternatif, catatan individual dengan saldo penghasilan yang dipilih dapat
ditampilkan. Indeks dapat dibuat untuk setiap atribut dalam file, sehingga data dapat dilihat
dari berbagai perspektif.
Teori Basis Data Relasional

EF Codd awalnya mengusulkan prinsip model relasional pada akhir tahun 1960an.1
Model formal didasarkan pada aljabar relasional dan teori himpunan, yang memberikan landasan
teoritis untuk sebagian besar operasi manipulasi data yang digunakan. Oleh karena itu, suatu sistem
dikatakan relasional jika:
1.Mewakili data dalam bentuk tabel dua dimensi.

2.Mendukung fungsi aljabar relasional membatasi, memproyeksikan, dan menggabungkan.
Ketiga fungsi aljabar tersebut dijelaskan di bawah ini:
Membatasi: Mengekstrak baris tertentu dari tabel tertentu. Operasi ini, diilustrasikan pada
Gambar 8.11(a), membuat tabel virtual (yang tidak ada secara fisik) yang merupakan subset
dari tabel asli.
Proyek: Mengekstrak atribut (kolom) tertentu dari tabel untuk membuat tabel virtual. Hal
ini disajikan pada Gambar 8.11(b).
1 Lihat “Mendefinisikan Data” di bagian Indeks pada fitur Bantuan online ACL untuk penjelasan rinci
tentang proses ini.
Struktur data 339
GAMBAR 8.11 Fungsi Aljabar Relasional Membatasi, Memproyeksikan, dan Menggabungkan
(a) Batasi (b) Proyek
(c) Bergabung
X1 Y1 Y1 Z1 X1 Y1 Z1
X2 Y2 Y2 Z2 X2 Y2 Z2
X3 Y1 Y3 Z3 X3 Y1 Z1
Bergabung: Membangun tabel fisik baru dari dua tabel yang terdiri dari semua pasangan baris yang
digabungkan, dari setiap tabel, seperti yang ditunjukkan pada Gambar 8.11(c).
Meskipun pembatasan, proyek, dan penggabungan bukanlah rangkaian fungsi relasional yang lengkap, namun merupakan
bagian berguna yang memenuhi sebagian besar kebutuhan informasi bisnis.
Konsep Basis Data Relasional
Pada bagian ini, kami meninjau konsep dasar, terminologi, dan teknik yang umum pada sistem
database relasional. Blok penyusun ini kemudian digunakan di bagian selanjutnya dalam bab ini untuk
merancang database kecil dari awal.
Entitas, Kejadian, dan Atribut

Sebuahkesatuanadalah segala sesuatu yang ingin diambil datanya oleh organisasi. Entitas
mungkin bersifat fisik, seperti inventaris, pelanggan, atau karyawan. Mereka mungkin juga
bersifat konseptual, seperti penjualan (kepada pelanggan), piutang (AR), atau hutang (AP).
Perancang sistem mengidentifikasi entitas dan menyiapkan modelnya seperti yang disajikan
pada Gambar 8.12. Inimodel dataadalah cetak biru untuk akhirnya menciptakan database fisik.
Representasi grafis yang digunakan untuk menggambarkan model disebutdiagram hubungan
entitas (ER).. Sesuai konvensi, setiap entitas dalam model data diberi nama dalam bentuk kata
benda tunggal, seperti “Pelanggan” dan bukan “Pelanggan”. Syaratkejadiandigunakan untuk
menggambarkan jumlah contoh atau catatan yang berkaitan dengan entitas tertentu. Misalnya,
jika suatu organisasi memiliki 100 karyawan, maka disebut entitas Karyawan
GAMBAR 8.12
Membeli
Pelanggan Produk
Penggunaan Model Data
sebuah Entitas
Hubungan
Diagram
Mengirim
Pembayaran
terdiri dari 100 kejadian.Atributadalah elemen data yang mendefinisikan suatu entitas.
Misalnya, entitas Karyawan dapat ditentukan oleh sebagian kumpulan atribut berikut: Nama,
Alamat, Keterampilan Kerja, Masa Kerja, dan Tarif Gaji Per Jam. Setiap kejadian di entitas
Karyawan terdiri dari jenis atribut yang sama, namun nilai setiap atribut akan bervariasi antar
kejadian. Karena atribut adalah karakteristik logis dan relevan dari suatu entitas, maka atribut
tersebut bersifat unik. Dengan kata lain, atribut yang sama tidak boleh digunakan untuk
mendefinisikan dua entitas yang berbeda.
Asosiasi dan Kardinalitas

Garis berlabel yang menghubungkan dua entitas dalam model data menggambarkan sifat dari
asosiasidiantara mereka. Asosiasi ini diwakili dengan kata kerja, seperti mengirimkan, meminta,
atau menerima.Kardinalitasadalah tingkat hubungan antara dua entitas. Secara sederhana,
kardinalitas menggambarkan jumlah kemungkinan kemunculan dalam satu tabel yang
dikaitkan dengan satu kejadian dalam tabel terkait. Ada empat bentuk dasar kardinalitas yang
mungkin: nol atau satu (0,1), satu dan hanya satu (1,1), nol atau banyak (0,M), dan satu atau
banyak (1,M). Ini digabungkan untuk mewakili asosiasi logis antar entitas. Nilai kardinalitas atas
di setiap ujung garis asosiasi menentukan asosiasi tersebut. Misalnya, kardinalitas (0,1) di satu
ujung dan kardinalitas (1,M) di ujung lainnya merupakan asosiasi (1:M). Gambar 8.13
menyajikan beberapa contoh asosiasi entitas, yang akan dibahas selanjutnya.
Contoh 1 (1:1).Asumsikan sebuah perusahaan memiliki 1.000 karyawan tetapi hanya 100 di antaranya yang
merupakan staf penjualan. Asumsikan juga bahwa setiap tenaga penjualan diberi mobil perusahaan, namun staf
nonpenjualan tidak. Contoh 1 pada Gambar 8.13 menunjukkan bahwa untuk setiap kejadian (record) pada entitas
Employee, kemungkinan terjadinya nol atau satu kejadian pada entitas Company Car.
Saat menentukan nilai kardinalitas dalam suatu asosiasi entitas, pilih satu kejadian
(catatan) dari satu entitas dan jawab pertanyaan berikut: Berapa jumlah minimum dan
maksimum catatan yang dapat dikaitkan dengan catatan tunggal yang telah dipilih? Misalnya,
memilih rekaman entitas Karyawan dan melihat entitas Mobil Perusahaan, kita melihat dua
kemungkinan nilai. Jika catatan Karyawan yang dipilih adalah milik seorang tenaga penjualan,
maka dia akan diberi satu (dan hanya satu) mobil perusahaan. Oleh karena itu, catatan
Karyawan khusus ini hanya dikaitkan dengan satu catatan di entitas Mobil Perusahaan. Namun,
jika catatan Karyawan yang dipilih adalah bukan tenaga penjualan, maka individu tersebut tidak
akan diberi (nol) mobil. Catatan Karyawan dalam hal ini dikaitkan dengan nol catatan Mobil
Perusahaan. Jadi, kardinalitas minimumnya adalah
Struktur data 341
GAMBAR 8.13
Ditugaskan
Karyawan Mobil perusahaan Contoh 1
Contoh Entitas
Asosiasi
Disediakan
Pengelola laptop Contoh 2
Tempat
Pelanggan Order penjualan Contoh 3
Persediaan
Penjual Inventaris Contoh 4
Persediaan
Penjual Inventaris Contoh 5
nol dan kardinalitas maksimumnya adalah satu. Lingkaran dan garis pendek yang memotong
garis yang menghubungkan kedua entitas menggambarkan derajat kardinalitas ini. Perhatikan
bahwa dari perspektif entitas Karyawan, kardinalitas ditunjukkan pada akhir Mobil Perusahaan
pada garis asosiasi. Sekarang pilih catatan Mobil Perusahaan dan lihat kembali entitas
Karyawan. Karena setiap mobil perusahaan ditugaskan hanya kepada satu karyawan, jumlah
minimum dan maksimum catatan terkait adalah satu. Dua garis pendek yang berpotongan di
ujung garis asosiasi Karyawan menandakan kardinalitas ini.
Contoh 2 (1:1).Contoh 2 mengilustrasikan situasi di mana setiap record dalam satu entitas selalu
dikaitkan dengan satu (dan hanya satu) record dalam entitas terkait. Dalam hal ini, setiap komputer
laptop perusahaan ditugaskan hanya kepada satu manajer, dan setiap manajer hanya ditugaskan
pada satu komputer. Dua garis pendek yang memotong garis penghubung di kedua ujungnya
menggambarkan kardinalitas ini.
Contoh 3 (1:M).Contoh 3 menyajikan hubungan antara entitas Pelanggan dan Pesanan Penjualan.
Perhatikan bahwa jumlah minimum catatan Pesanan Penjualan per catatan Pelanggan adalah nol dan
maksimum adalah banyak. Hal ini karena dalam periode tertentu (satu tahun atau bulan) yang terkait
dengan entitas Pesanan Penjualan, pelanggan tertentu mungkin tidak membeli apa pun (tidak ada
catatan Pesanan Penjualan) atau membeli beberapa kali (banyak catatan). Namun, dari perspektif
entitas Pesanan Penjualan, setiap catatan dikaitkan dengan satu dan hanya satu pelanggan. Simbol
kaki gagak (yang memberi nama pada bentuk notasi ini) menggambarkan banyak kardinalitas di
ujung Pesanan Penjualan dari garis asosiasi.
Contoh 4 (1:M).Contoh 4 mewakili situasi di mana setiap item inventaris tertentu

dipasok oleh satu dan hanya satu Vendor, dan setiap Vendor memasok satu atau banyak
item inventaris berbeda ke perusahaan. Bandingkan asosiasi (1:M) ini dengan Contoh 5
berikutnya.
Contoh 5 (M:M).Untuk mengilustrasikan hubungan banyak ke banyak, kita sekali lagi menggunakan
hubungan Vendor dan Persediaan pada Contoh 5. Namun kali ini, perusahaan mempunyai kebijakan untuk
membeli jenis persediaan yang sama dari beberapa pemasok. Manajemen dapat memilih untuk melakukan
hal ini untuk memastikan bahwa mereka mendapatkan harga terbaik atau menghindari ketergantungan
pada satu pemasok. Berdasarkan kebijakan tersebut, setiap catatan Vendor dikaitkan dengan satu atau
beberapa catatan Inventaris, dan setiap catatan Inventaris dikaitkan dengan satu atau banyak Vendor.
Contoh 4 dan 5 menunjukkan bagaimana kardinalitas mencerminkan aturan bisnis yang berlaku dalam
suatu organisasi. Perancang basis data harus memperoleh pemahaman menyeluruh tentang bagaimana
perusahaan klien dan pengguna tertentu menjalankan bisnis untuk merancang model data dengan benar.
Jika model datanya salah maka tabel database yang dihasilkan juga akan salah. Contoh 4 dan 5 keduanya
valid namun merupakan pilihan yang berbeda dan, seperti yang akan kita lihat, memerlukan desain database
yang berbeda.
Notasi Kardinalitas Alternatif.Teknik notasi kardinalitas yang ditunjukkan pada Gambar 8.13
disebut “kaki gagak”. Cara alternatifnya adalah dengan menuliskan nilai kardinalitas pada setiap
ujung garis asosiasi yang menghubungkan kedua entitas. Beberapa perancang basis data
secara eksplisit menunjukkan nilai kardinalitas atas dan bawah. Beberapa memilih versi
singkatan yang hanya mencatat kardinalitas atas. Untuk tugas pekerjaan rumah, instruktur
Anda akan memberi tahu Anda metode pilihan yang akan digunakan.
Tabel Database Fisik

Tabel database fisik dibuat dari model data dengan setiap entitas dalam model diubah menjadi
tabel fisik terpisah. Di bagian atas setiap tabel terdapat atribut yang membentuk kolom. Kolom-
kolom yang berpotongan membentuk baris-baris tabel adalah tupel. Sebuah tupel, yang Codd
berikan definisi tepat ketika pertama kali memperkenalkannya, kira-kira berhubungan dengan
catatan dalam sistem file datar. Sesuai dengan konvensi, kami akan menggunakan istilah
tersebutcatatanataukejadiandaripada tupel.
Tabel yang dirancang dengan baik memiliki empat karakteristik berikut:
1.Nilai minimal satu atribut pada setiap kemunculan (baris) harus unik. Atribut ini
adalahkunci utama. Nilai atribut lain (bukan kunci) pada baris tidak perlu
unik.
2.Semua nilai atribut di kolom mana pun harus dari kelas yang sama.
3.Setiap kolom dalam tabel tertentu harus diberi nama secara unik. Namun, tabel yang berbeda
mungkin berisi kolom dengan nama yang sama.
4.Tabel harus sesuai dengan aturan normalisasi. Artinya, mereka harus bebas dari
ketergantungan struktural termasuk kelompok berulang, ketergantungan parsial, dan
ketergantungan transitif (lihat lampiran bab ini untuk pembahasan selengkapnya).
Keterkaitan antar Tabel Relasional

Tabel yang terkait secara logis perlu dihubungkan secara fisik untuk mencapai asosiasi yang
dijelaskan dalam model data. Menggunakankunci asingmencapai hal ini, seperti yang
diilustrasikan pada Gambar 8.14. Dalam contoh ini, kunci asing tertanam dalam tabel terkait.
Misalnya, kunci utama tabel Pelanggan (CUST NUM) tertanam sebagai kunci asing di tabel
Faktur Penjualan dan Penerimaan Kas. Demikian pula, kunci utama dalam tabel Faktur
Penjualan (INVOICE NUM) adalah kunci asing yang tertanam dalam tabel Item Baris.
Struktur data 343
Perhatikan bahwa tabel Item Baris menggunakan kunci utama gabungan yang terdiri dari NUM
INVOICE dan NUM ITEM. Kedua bidang diperlukan untuk mengidentifikasi setiap catatan dalam
tabel secara unik, namun hanya bagian nomor faktur dari kunci yang menyediakan link logis ke
tabel Faktur Penjualan. Kunci asing tidak selalu tertanam seperti pada Gambar 8.14. Sifat
hubungan antara tabel terkait menentukan metode yang digunakan untuk menetapkan kunci
asing. Metode-metode ini akan dibahas kemudian.
Dengan adanya kunci asing, program komputer dapat ditulis untuk menavigasi tabel-tabel
database dan menyediakan data yang dibutuhkan pengguna untuk mendukung tugas sehari-
hari dan tanggung jawab pengambilan keputusan. Misalnya, jika pengguna menginginkan
semua faktur untuk Pelanggan 1875, program akan mencari tabel Faktur Penjualan untuk
catatan dengan nilai kunci asing 1875. Kita melihat dari Gambar 8.14 bahwa hanya ada satu
kejadian seperti itu—nomor faktur 1921. Untuk memperoleh rincian item baris untuk faktur ini,
program mencari tabel Item Baris untuk catatan dengan nilai kunci asing 1921, dan dua catatan
diambil.
GAMBAR 8.14 Keterkaitan antar Tabel Relasional
Kunci Asing Tersemat
Pelanggan
Bea Cukai
Nama Alamat Saat ini
Nomor (Kunci) Keseimbangan
Faktur
1875 J.Smith 18 Jalan Elm. 1820.00 Nomor
Bea Cukai
$ Jumlah S Tanggal pinggul
Nomor
(Kunci)
1876 G.Adams 21 Jalan Pertama. 2400,00 Penjualan
• • • •
Faktur
1943 J.Hobbs 165 Jalan Tinggi. 549.87
• • • •
2345 Y.Martin 321 Barclay 5256.76
1921 1875 800,00 2/10/09
• • • •
• • • •
• • • •
• • • •
• • • •
• • • •
432 Utama
5678 T.Batang 643.67
St.
KUNCI
Item baris Penerimaan Tunai
Faktur Barang
Jumlah
Satuan Diperpanjang Mengampuni Bea Cukai Jumlah Tanggal
Nomor Nomor Harga Harga Nomor (Kunci) Nomor Diterima Diterima

1918 8312 1 84,50 84,50 • • • •
• • • • • 1362 1875 800,00 30/2/09

1921 9215 10 45.00 450,00
• • • •
1921 3914 1 350,00 350,00
• • • •
• • • • •
• • • • •
Tampilan Pengguna
Atampilan penggunaadalah kumpulan data yang dilihat pengguna tertentu. Contoh tampilan pengguna
adalah layar komputer untuk memasukkan atau melihat data, laporan manajemen, atau dokumen sumber
seperti faktur. Tampilan mungkin digital atau fisik (kertas), namun dalam semua kasus, tampilan tersebut
berasal dari tabel database yang mendasarinya. Tampilan sederhana dapat dibuat dari satu tabel, sedangkan
tampilan yang lebih kompleks mungkin memerlukan beberapa tabel. Selain itu, satu tabel dapat
menyumbangkan data ke banyak tampilan berbeda.
Sebuah organisasi besar akan memiliki ribuan tampilan pengguna yang didukung oleh ribuan tabel
individual. Tugas mengidentifikasi semua tampilan dan menerjemahkannya ke dalam tabel yang
dinormalisasi merupakan tanggung jawab penting perancang database yang memiliki implikasi pengendalian
internal. Permasalahan dan teknik yang berkaitan dengan tugas ini diperiksa selanjutnya.
Anomali, Ketergantungan Struktural, dan Normalisasi Data
Bagian ini membahas mengapa tabel database perlu dinormalisasi. Dengan kata lain, mengapa
database organisasi perlu membentuk jaringan tabel normalisasi yang rumit dan dihubungkan
bersama seperti yang diilustrasikan pada Gambar 8.14? Mengapa kita tidak menggabungkan
pandangan satu pengguna (atau beberapa pengguna) ke dalam satu tabel umum yang dapat
memenuhi semua kebutuhan data?
Anomali Basis Data

Jawaban atas pertanyaan di atas adalah bahwa tabel yang dinormalisasi secara tidak tepat dapat
menyebabkan masalah pemrosesan DBMS yang membatasi, atau bahkan menolak, akses pengguna
ke informasi yang mereka perlukan. Tabel tersebut menunjukkan gejala operasional negatif yang
disebutanomali. Secara khusus, ini adalah anomali pembaruan, anomali penyisipan, dan anomali
penghapusan. Satu atau lebih anomali ini akan ada pada tabel yang tidak dinormalisasi atau
dinormalisasi pada tingkat rendah, sepertibentuk normal pertama (1NF)ataubentuk normal kedua
(2NF). Agar bebas dari anomali, tabel harus dinormalisasi kebentuk normal ketiga (3NF)tingkat.
Kami akan mendemonstrasikan dampak negatif anomali dengan tampilan pengguna pada Gambar
8.15. Laporan status inventaris ini akan digunakan untuk memberikan informasi kepada agen pembelian
GAMBAR 8.15 Pabrikan Ajax Co.

Laporan Status Inventaris
Status Persediaan
Laporan
Bagian Kuantitas Susun ulang Pemasok
Nomor Keterangan
Titik Nomor
Nama Alamat Telepon
Di Tangan
1 Mengurung 100 150 22 Sup Ozment 123 Jalan Utama 555-7895

24 Buell Co. 2 Kepala lebar 555-3436
27 Sup B&R Mal Westgate 555-7845
2 Paking 440 450 22 Sup Ozment 123 Jalan Utama 555-7895
28 Harris Manuf 24 Jalan Linden. 555-3316
3 Penjepit 10 10 22 Sup Ozment 123 Jalan Utama 555-7895

• • • • • • • •
• • • • • • • •
• • • • • • • •
Struktur data 345
tentang persediaan barang yang akan dipesan dan berbagai pemasok (vendor) barang tersebut. Jika tampilan
ini dihasilkan dari satu tabel, tampilannya akan serupa dengan yang disajikan pada Gambar 8.16. Meskipun
tabel seperti itu memang dapat menyimpan data untuk menghasilkan tampilan, tabel tersebut akan
memperlihatkan anomali yang disebutkan di atas.
Perbarui Anomali.Itumemperbarui anomalihasil dari redundansi data dalam tabel yang

tidak dinormalisasi. Sebagai ilustrasi, perhatikan bahwa Pemasok Nomor 22 menyediakan
masing-masing dari tiga item inventaris (BAGIAN NUM 1, 2, dan 3) yang ditunjukkan pada
Gambar 8.16. Atribut data Pemasok Nomor 22 (NAMA, ALAMAT, dan NOMOR TELE) diulangi di
setiap pencatatan setiap barang inventaris yang disediakan Pemasok Nomor 22. Setiap
perubahan nama, alamat, atau nomor telepon pemasok harus dilakukan pada setiap catatan di
tabel ini. Dalam contoh ini, ini berarti tiga pembaruan berbeda. Untuk lebih memahami
implikasi anomali pembaruan, pertimbangkan situasi yang lebih realistis ketika vendor
memasok 10.000 item inventaris berbeda. Setiap pembaruan pada suatu atribut harus
dilakukan 10.000 kali.
Anomali Penyisipan.Untuk menunjukkan dampak darianomali penyisipan, asumsikan

vendor baru telah memasuki pasar. Organisasi belum membeli dari vendor, namun
mungkin ingin melakukannya di masa mendatang. Sementara itu, organisasi ingin
menambahkan vendor ke database. Namun hal ini tidak mungkin dilakukan, karena kunci
utama untuk tabel Inventaris adalah PART NUM. Karena vendor tidak memasok item
inventaris apa pun kepada organisasi, data pemasok tidak dapat ditambahkan ke tabel.
Anomali Penghapusan.Ituanomali penghapusanmelibatkan penghapusan data yang tidak

disengaja dari tabel. Sebagai ilustrasi, asumsikan bahwa Pemasok Nomor 27 hanya menyediakan satu
item kepada perusahaan: Nomor Bagian 1. Jika organisasi menghentikan item inventaris ini dan
menghapusnya dari tabel, data yang berkaitan dengan Pemasok Nomor 27 juga akan dihapus.
Meskipun perusahaan mungkin ingin menyimpan informasi pemasok untuk digunakan di masa
mendatang, desain tabel saat ini mencegahnya melakukan hal tersebut.
Kehadiran anomali penghapusan tidak terlalu mencolok, namun berpotensi lebih serius dibandingkan
anomali pembaruan dan penyisipan. Desain database yang cacat yang mencegah penyisipan catatan atau
mengharuskan pengguna untuk melakukan pembaruan berlebihan menarik perhatian
GAMBAR 8.16 Tabel Database Tidak Dinormalisasi
Tabel Inventaris
Ribut Att yang tidak penting

Utama
Kunci
Bagian Kuantitas Susun ulang Pemasok Tele

Keterangan Nama Alamat
Nomor Di Tangan Titik Nomor Nomor
1 Mengurung 100 150 22 Sup Ozment 123 Jalan Utama 555-7895

1 Mengurung 100 150 24 Buell Co. 2 Kepala lebar 555-3436
1 Mengurung 100 150 27 Sup B&R Mal Westgate 555-7845
2 Paking 440 450 22 Sup Ozment 123 Jalan Utama 555-7895
2 Paking 440 450 24 Buell Co. 2 Kepala lebar 555-3436
2 Paking 440 450 28 Harris Manuf 24 Jalan Linden. 555-3316
3 Penjepit 10 10 22 Sup Ozment 123 Jalan Utama 555-7895
3 Penjepit 10 10 24 Buell Co. 2 Kepala lebar 555-3436
3 Penjepit 10 10 28 Harris Manuf 24 Jalan Linden. 555-3316
dengan cepat. Namun, anomali penghapusan mungkin tidak terdeteksi, sehingga pengguna tidak
menyadari hilangnya data penting hingga semuanya terlambat. Hal ini dapat mengakibatkan
hilangnya catatan akuntansi penting yang tidak disengaja dan rusaknya jejak audit. Oleh karena itu,
desain tabel bukan hanya masalah efisiensi operasional; hal ini membawa signifikansi pengendalian
internal yang perlu diakui oleh akuntan.
Tabel Normalisasi
Anomali database yang dijelaskan di atas adalah gejala masalah struktural dalam tabel yang
disebut dependensi. Secara khusus, ini dikenal sebagaikelompok yang berulang,
ketergantungan parsial, Danketergantungan transitif. Proses normalisasi melibatkan
identifikasi dan penghapusan ketergantungan struktural dari tabel yang ditinjau. (Untuk
penjelasan lengkap mengenai proses ini, harap tinjau lampiran bab ini.) Tabel yang dihasilkan
kemudian akan memenuhi dua kondisi di bawah ini:
1.Semua atribut bukan kunci (data) dalam tabel bergantung pada (ditentukan oleh) kunci utama.
2.Semua atribut bukan kunci tidak bergantung pada atribut bukan kunci lainnya.
Dengan kata lain, tabel 3NF adalah tabel yang kunci utama suatu tabel secara keseluruhan
dan unik mendefinisikan setiap atribut dalam tabel. Selain itu, tidak ada atribut tabel yang
ditentukan oleh atribut selain kunci utama. Jika ada atribut yang melanggar ketentuan ini,
atribut tersebut harus dihapus dan ditempatkan di tabel terpisah dan diberi kunci yang
sesuai.
Setelah memeriksa Gambar 8.16, kita melihat bahwa kunci utama PART NUM tidak secara unik
mendefinisikan atribut nonkey dari SUPPLIER NUMBER, NAME, ADDRESS, dan TELE NUM. Sebaliknya,
setiap nilai kunci utama yang unik dikaitkan dengan beberapa nilai (grup berulang) untuk atribut
bukan kunci tersebut. Untuk mengatasi ketergantungan struktural ini, data grup yang berulang harus
dihapus dari tabel Inventaris dan ditempatkan di tabel terpisah, yang akan kita sebut Pemasok.
Gambar 8.17 menunjukkan dua tabel 3NF, Inventaris dan Pemasok, serta tabel ketiga yang disebut
Part/Supplier, yang menghubungkan keduanya. Teknik menghubungkan ini akan dijelaskan nanti.
Normalisasi tabel telah menghilangkan ketiga anomali tersebut. Pertama, anomali

pembaruan teratasi karena data tentang setiap pemasok hanya ada di satu lokasi—tabel
Pemasok. Setiap perubahan pada data tentang masing-masing vendor hanya dilakukan satu
kali, berapa pun jumlah item yang dipasoknya. Kedua, anomali penyisipan tidak lagi ada karena
vendor baru dapat ditambahkan ke tabel Pemasok meskipun mereka saat ini tidak memasok
inventaris ke organisasi. Misalnya, Pemasok Nomor 30 pada tabel tidak menyediakan item
inventaris apa pun. Akhirnya, anomali penghapusan dihilangkan. Keputusan untuk menghapus
item inventaris dari database tidak akan mengakibatkan penghapusan data pemasok secara
tidak sengaja karena data tersebut berada secara independen di tabel yang berbeda.
Menghubungkan Tabel yang Dinormalisasi
Ketika tabel yang tidak dinormalisasi dipecah menjadi beberapa tabel 3NF, tabel tersebut perlu dihubungkan
bersama melalui kunci asing sehingga data di dalamnya dapat dikaitkan dan dapat diakses oleh pengguna.
Derajat keterkaitan (kardinalitas gabungan) antara tabel-tabel yang dihasilkan (yaitu, 1:1, 1:M, atau M:M)
menentukan bagaimana tautan tersebut terjadi. Aturan penetapan kunci untuk menghubungkan tabel akan
dibahas selanjutnya.
Kunci dalam Asosiasi 1:1.Jika terdapat hubungan 1:1 yang sebenarnya antar tabel, salah satu (atau kedua-
duanya) kunci utama dapat disematkan sebagai kunci asing dalam tabel terkait. Sebaliknya, ketika nilai
kardinalitas yang lebih rendah adalah nol (1:0,1) struktur tabel yang lebih efisien akan digunakan.
Struktur data 347
GAMBAR 8.17 Tabel Database yang Dinormalisasi
hal
Bagian Bergalah Susun ulang

Keterangan
Nomor Di Tangan Titik
Inventaris
Meja
1 Mengurung 100 150 (3NF)
Bagian/Pemasok
Tabel Tautan(3NF)
2 Paking 440 450
Bagian Pemasok
Nomor Nomor 3 Penjepit 10 10
1 22
1 24
1 27 hal
2 22 Pemasok Tele
Nama Alamat
Nomor Nomor Pemasok
2 24
Meja
22 Sup Ozment 123 Jalan Utama 555-7895
2 28 (3NF)
3 22
3 24 27 Sup B&R Mal Westgate 555-7845
3 28 28 Harris Manuf 24 Jalan Linden. 555-3316
30 Bagian Unggul 82 Jalan Pusat. 555-2213
masa depan dapat dicapai dengan menempatkan kunci utama tabel satu sisi (1:) di tabel nol-atau-satu (:0,1)
sebagai kunci asing. Dengan menggunakan contoh Mobil Karyawan/Perusahaan pada Gambar 8.13, kita
melihat pentingnya aturan penetapan kunci ini. Sebagai ilustrasi, bayangkan membalikkan aturan dengan
menempatkan kunci utama tabel Mobil Perusahaan (sisi 0) ke dalam tabel Karyawan (sisi 1). Karena sebagian
besar karyawan tidak ditugaskan pada mobil perusahaan, sebagian besar kunci asing dalam tabel Karyawan
akan memiliki nilai null (kosong). Meskipun pendekatan ini berhasil, pendekatan ini dapat menyebabkan
beberapa masalah teknis selama pencarian tabel. Menerapkan aturan penetapan kunci dengan benar akan
memecahkan masalah ini karena semua catatan Mobil Perusahaan akan memiliki karyawan yang ditugaskan
dan tidak akan ada nilai nol yang terjadi.
Kunci dalam Asosiasi 1:M.Jika terdapat asosiasi 1:M (atau 1:0,M), kunci utama dari sisi
1 tertanam dalam tabel sisi M. Untuk menunjukkan logika di balik aturan penetapan kunci
ini, pertimbangkan dua aturan bisnis alternatif untuk membeli inventaris dari pemasok.
Aturan Bisnis 1. Setiap vendor menyuplai perusahaan dengan tiga (atau kurang) item inventaris yang
berbeda, namun setiap item dipasok hanya oleh satu vendor.
Aturan bisnis yang tidak realistis namun secara teknis mungkin ini menggambarkan
hubungan batas atas 1:M (1:1,3) antara tabel Pemasok dan Inventaris.
Untuk menerapkan aturan ini, perancang perlu memodifikasi struktur tabel Inventaris
untuk memasukkan NOMOR PEMASOK seperti yang diilustrasikan pada Gambar 8.18. Dalam
pendekatan ini, setiap catatan dalam tabel Inventaris sekarang akan berisi nilai bidang kunci
dari vendor yang memasok barang tersebut. Sebaliknya, Gambar 8.19 menunjukkan seperti apa
struktur tabel jika perancang membalikkan aturan penetapan kunci dengan menyematkan
kunci PART NUM di tabel Pemasok. Perhatikan bahwa tabel Pemasok sekarang berisi tiga
bidang nomor bagian yang masing-masing tertaut ke catatan terkait dalam tabel Inventaris.
Hanya tautan ke nomor bagian 1, 2, dan 3 yang ditampilkan. Meskipun teknik ini melanggar
aturan penetapan kunci, teknik ini akan berhasil. Namun hal ini terjadi hanya karena batas atas
dari banyak sisi asosiasi diketahui dan sangat kecil (yaitu, dibatasi pada tiga). Bagaimana
tampilan struktur tabel ini jika kita mengasumsikan aturan bisnis berikut yang lebih realistis?
Aturan Bisnis 2. Setiap vendor menyuplai sejumlah item inventaris ke perusahaan, namun
setiap item dipasok hanya oleh satu vendor.
Ini adalah asosiasi 1:M yang sebenarnya dimana batas atas dari banyak sisi asosiasi tidak
dibatasi. Misalnya, vendor dapat memasok satu item inventaris atau 10.000 item. Berapa
banyak field yang harus kita tambahkan ke struktur tabel Pemasok untuk mengakomodasi
semua kemungkinan tautan ke tabel Inventaris? Di sini kita dapat melihat logika di balik aturan
penetapan kunci 1:M. Struktur pada Gambar 8.18 masih berfungsi berdasarkan aturan bisnis
ini, sedangkan teknik yang diilustrasikan pada Gambar 8.19 tidak.
Kunci dalam Asosiasi M:M.Untuk mewakili asosiasi M:M antar tabel, tabel tautan perlu
dibuat. Tabel tautan memiliki kunci gabungan (komposit) yang terdiri dari kunci utama dari dua
tabel terkait. Sekarang mari kita kembali ke hubungan tabel yang digambarkan dalam
GAMBAR 8.18 (PK) Tabel Inventaris (FK)
Menerapkan 1:M Bagian Bergalah Susun ulang Pemasok "Banyak"

Keterangan
Penugasan Kunci Nomor Di Tangan Titik Nomor Samping
Aturan
1 Mengurung 100 150 22
2 Paking 440 450 28
3 Penjepit 10 10 28
(PK) Tabel Pemasok
Pemasok Tele
Nomor
Nama Alamat
Nomor
"1"
Samping
22 Sup Ozment 123 Jalan Utama 555-7895
Struktur data 349
GAMBAR 8.19 Membalikkan Aturan Penetapan Kunci 1:M
(PK) Tabel Inventaris
Bagian
Keterangan
Bergalah Susun ulang "Banyak"
Nomor Di Tangan Titik Samping
1 Mengurung 100 150
2 Paking 440 450
3 Penjepit 10 10
(PK) Tabel Pemasok (FK) (FK) (FK)
Pemasok Tele Bagian Bagian Bagian

Nama Alamat
Nomor Nomor Nomor Nomor Nomor
22 Sup Ozment 123 Jalan Utama 555-7895 1 9 7 "1"

Samping
24 Buell Co. 2 Kepala lebar 555-3436 4 8 6
28 Harris Manuf 24 Jalan Linden. 555-3316 5 2 3
Gambar 8.17. Tabel berikut mengilustrasikan asosiasi M:M yang dijelaskan oleh aturan bisnis
berikut:
Aturan Bisnis 3. Setiap vendor menyuplai perusahaan dengan sejumlah item inventaris berapa pun, dan
setiap item dapat dipasok oleh sejumlah vendor berapa pun.
Aturan bisnis ini terlihat dengan memeriksa isi Laporan Status Inventaris (tampilan pengguna) pada
Gambar 8.15. Setiap nomor komponen yang ditampilkan memiliki beberapa pemasok, dan setiap
pemasok dapat memasok beberapa item. Misalnya Ozment Supply menyediakan item 1, 2, dan 3.
Harris Manufacturing juga menyediakan item 2 dan 3.
Asosiasi M:M antar tabel memerlukan pembuatan tabel tautan terpisah karena
memasukkan kunci asing ke dalam tabel mana pun tidak dimungkinkan. Logika dalam contoh
1:M sebelumnya yang mencegah kita menyematkan kunci utama dari banyak tabel sisi dari
asosiasi tak terbatas ke dalam tabel di satu sisi juga berlaku di sini. Tidak ada tabel yang dapat
menyumbangkan kunci asing yang tertanam ke tabel lainnya karena keduanya berada di
banyak pihak dalam asosiasi. Oleh karena itu, solusinya adalah dengan membuat tabel link baru
yang berisi field kunci dari dua tabel lainnya.
Tabel link yang disebut Part/Supplier pada Gambar 8.17 adalah tabel kunci asing. Ini
berisi kunci utama untuk catatan dalam tabel Inventaris (NOMOR BAGIAN) dan tabel
Pemasok terkait (NOMOR PEMASOK). Melalui tabel link, setiap item inventaris dapat
ditautkan ke pemasok item yang sesuai, dan setiap pemasok dapat ditautkan
barang inventaris yang disuplainya. Misalnya, dengan mencari tabel Inventaris untuk PART
NUM 1, kita melihat bahwa Pemasok 22, 24, dan 27 menyediakan item ini. Mencari dalam arah
yang berlawanan, PEMASOK NOMOR 28 menyediakan bagian 2 dan 3. Catatan terpisah dalam
tabel tautan mewakili setiap kejadian unik dari asosiasi pemasok/persediaan. Misalnya, jika
Pemasok 24 menyediakan 500 item inventaris berbeda, maka tabel tautan akan berisi 500
catatan untuk menggambarkan asosiasi ini.
Auditor dan Normalisasi Data

Normalisasi basis data adalah masalah teknis yang biasanya menjadi tanggung jawab para
profesional sistem. Namun hal ini mempunyai implikasi terhadap pengendalian internal sehingga
menjadi perhatian auditor juga. Misalnya, anomali pembaruan dapat menghasilkan nilai basis data
yang bertentangan dan usang, anomali penyisipan dapat mengakibatkan transaksi tidak tercatat dan
jejak audit tidak lengkap, dan anomali penghapusan dapat menyebabkan hilangnya catatan akuntansi
dan kehancuran jejak audit. Meskipun sebagian besar auditor tidak bertanggung jawab untuk
melakukan normalisasi database organisasi, mereka harus memiliki pemahaman tentang proses
tersebut dan dapat menentukan apakah suatu tabel telah dinormalisasi dengan benar.
Selain itu, auditor perlu mengetahui bagaimana data disusun sebelum dia dapat mengekstrak
data dari tabel untuk melakukan prosedur audit. Seperti yang telah kita lihat, pandangan pengguna
terhadap data seringkali sangat berbeda dari struktur penyimpanannya. Misalnya, tugas audit untuk
mengambil data yang berkaitan dengan tampilan pengguna yang kompleks seperti pesanan
pembelian akan melibatkan identifikasi dan akses beberapa tabel terkait. Hubungan kompleks ini
diilustrasikan secara lebih rinci pada bagian berikut saat kita memeriksa langkah-langkah yang terlibat
dalam pembuatan sebagian database relasional perusahaan.
MERANCANG DATABASE RELASI

Perancangan basis data merupakan komponen dari proses pengembangan sistem yang jauh lebih besar yang
melibatkan analisis ekstensif terhadap kebutuhan pengguna, yang merupakan topik pada Bab 5. Oleh karena itu, titik
awal kita adalah titik awal yang biasanya mengikuti pekerjaan pendahuluan yang telah mengidentifikasi secara rinci
elemen-elemen kunci dari pengembangan sistem. sistem yang sedang dikembangkan. Dengan latar belakang ini,
fokusnya adalah pada enam fase desain database berikut, yang secara kolektif dikenal sebagaimelihat pemodelan:
1.Identifikasi entitas.
2.Buatlah model data yang menunjukkan asosiasi entitas.
3.Tambahkan kunci utama dan atribut ke model.
4.Normalisasikan model data dan tambahkan kunci asing.
5.Membangun database fisik.
6.Siapkan tampilan pengguna.
Identifikasi Entitas
Pemodelan tampilan dimulai dengan mengidentifikasi entitas utama dari fungsi bisnis yang dimaksud.
Ingatlah bahwa entitas adalah hal-hal yang ingin diambil datanya oleh organisasi. Untuk
mendemonstrasikan identifikasi entitas, kami akan menganalisis fitur utama sistem pembelian yang
disederhanakan berikut ini:
1.Agen pembelian meninjau laporan status inventaris (Gambar 8.15) untuk item yang
perlu dipesan ulang.
2.Agen memilih pemasok dan menyiapkan pesanan pembelian online.
Merancang Database Relasional 351
3.Agen mencetak salinan pesanan pembelian (Gambar 8.20a) dan mengirimkannya ke pemasok.
4.Pemasok mengirimkan inventaris ke perusahaan. Setibanya barang tersebut, petugas
penerima memeriksa inventaris dan menyiapkan laporan penerimaan online (Gambar
8.20b). Sistem komputer secara otomatis memperbarui catatan inventaris.
Entitas direpresentasikan sebagai kata benda dalam deskripsi sistem. Sejumlah calon entitas dapat
diidentifikasi pada uraian sebelumnya: Agen Pembelian, Petugas Penerima, Inventaris, Pemasok,
Laporan Status Inventaris, Pesanan Pembelian, dan Laporan Penerimaan. Tidak semua kandidat ini
merupakan entitas sejati yang perlu dimodelkan dalam database. Untuk lulus sebagai entitas yang
valid, dua syarat harus dipenuhi:
Kondisi 1. Suatu entitas harus terdiri dari dua kejadian atau lebih.
Kondisi 2. Suatu entitas harus menyumbangkan setidaknya satu atribut yang tidak disediakan
melalui entitas lain.
Kita perlu menguji kondisi ini untuk setiap kandidat untuk menghilangkan entitas palsu.
Agen pembelian.Dengan asumsi bahwa organisasi hanya memiliki satu agen pembelian, maka
calon Agen Pembelian gagal dalam Kondisi 1. Namun, jika ada lebih dari satu agen, Kondisi 1
terpenuhi tetapi Kondisi 2 mungkin menjadi masalah. Jika kita berasumsi bahwa tabel Karyawan
sudah ada sebagai bagian dari sumber daya manusia atau sistem penggajian, maka data dasar
tentang agen sebagai karyawan diambil dalam tabel tersebut. Kita perlu menentukan data apa saja
tentang agen yang unik dalam perannya dalam melakukan pemesanan yang perlu diambil. Perhatikan
bahwa kami tidak mengacu pada data tentang pesanan, tetapi data tentang
GAMBAR
A) B)
PO Menerima Laporan
Pesanan Pembelian Menerima Laporan
Nomor Nomor
nama pemasok Tanggal PO Pembawa BOL

Diterima Nomor Kode Nomor
Alamat Pemasok
Kargo nama pemasok
Prabayar Mengumpulkan
Nomor Telp. Nomor Telp.
Alamat Pemasok
Memesan Tanggal Pemasok Ketentuan
Tanggal Diperlukan Nomor
// //
Bagian Memesan Satuan Diperpanjang Bagian Kuantitas Kondisi
Nomor Keterangan Kuantitas Biaya Biaya Nomor Keterangan Diterima Kode
Total biaya
agen. Karena kami tidak memiliki informasi mengenai hal ini dalam uraian singkat kami tentang sistem, kami
berasumsi tidak ada data khusus agen yang diambil. Oleh karena itu, calon Agen Pembelian bukanlah suatu
entitas yang akan dimodelkan.
Petugas Penerimaan.Argumen sebelumnya berlaku juga untuk entitas Penerimaan Panitera. Kami akan
berasumsi bahwa tidak ada data khusus petugas yang perlu diambil yang memerlukan tabel khusus.
Inventaris.Entitas Inventaris memenuhi kedua kondisi tersebut. Gambaran tersebut menunjukkan

bahwa organisasi mempunyai banyak item inventaris; jadi entitas ini akan berisi banyak kejadian.
Selain itu, secara logis kita dapat berasumsi bahwa atribut yang mendefinisikan entitas Inventaris
tidak disediakan melalui tabel lain. Oleh karena itu, entitas Inventaris adalah entitas sebenarnya yang
perlu dimodelkan.
Pemasok.Deskripsinya menyatakan bahwa banyak vendor memasok inventaris; karenanya entitas Pemasok
memenuhi kondisi pertama. Kami juga dapat berasumsi bahwa data tersebut memenuhi kondisi kedua
karena tidak ada entitas lain yang secara logis menyediakan data pemasok. Oleh karena itu, entitas Pemasok
akan dimasukkan dalam model data.
Laporan Status Inventaris.Laporan Status Inventaris adalah tampilan pengguna yang berasal dari
entitas Inventaris dan Pemasok (lihat Gambar 8.17). Meskipun berisi beberapa kejadian, ini bukan
suatu entitas karena tidak memenuhi Kondisi 2. Tampilan tersebut seluruhnya berasal dari entitas
yang sudah ada dan tidak memberikan data tambahan yang memerlukan entitas terpisah. Namun,
tampilan tersebut akan dianalisis secara cermat untuk memastikan bahwa semua atribut yang
diperlukan disertakan dalam entitas yang ada.
Pesanan Pembelian.Entitas Pesanan Pembelian memenuhi kedua kondisi tersebut. Banyak pesanan
pembelian akan diproses dalam satu periode; dengan demikian entitas akan mengalami banyak kejadian.
Meskipun beberapa data pesanan pembelian dapat berasal dari entitas lain (Inventaris dan Pemasok) dalam
model, beberapa atribut unik pada peristiwa pembelian seperti tanggal pemesanan dan kuantitas pesanan
akan memerlukan entitas terpisah yang perlu dimodelkan.
Menerima Laporan.Laporan Penerimaan memenuhi kedua kondisi tersebut. Banyak peristiwa penerimaan
akan berlangsung pada periode tersebut; dengan demikian entitas Penerimaan Laporan akan memiliki
banyak kejadian. Entitas Laporan Penerimaan akan berisi atribut seperti tanggal diterima dan jumlah yang
diterima yang bersifat unik untuk entitas ini dan karenanya tidak disediakan oleh entitas lain dalam model.
Pada titik ini pencarian kami telah mengungkapkan empat entitas: Inventaris, Pemasok, Pesanan
Pembelian, dan Laporan Penerimaan. Ini akan digunakan untuk membangun model data dan, pada
akhirnya, tabel database fisik.
Buat Model Data yang Menampilkan Asosiasi Entitas
Langkah selanjutnya dalam pemodelan tampilan adalah menentukan hubungan antar entitas
dan mendokumentasikannya dengan diagram ER. Ingatlah bahwa asosiasi mewakili aturan
bisnis. Terkadang peraturannya jelas dan sama untuk semua organisasi. Misalnya, hubungan
normal antara entitas Pelanggan dan entitas Pesanan Penjualan adalah 1:M (atau 1:0,M).
Artinya, satu pelanggan dapat melakukan banyak pesanan selama satu periode penjualan.
Pengaitannya tidak akan pernah menjadi 1:1. Ini berarti bahwa organisasi membatasi setiap
pelanggan pada satu penjualan, dan hal ini tidak logis.
Terkadang hubungan antar entitas tidak terlihat karena aturan yang berbeda mungkin berlaku di
organisasi yang berbeda. Untuk mengulangi poin penting yang telah dibuat sebelumnya, the
aturan bisnis organisasi berdampak langsung pada struktur tabel database. Jika database
ingin berfungsi dengan baik, perancangnya perlu memahami aturan bisnis organisasi
serta kebutuhan spesifik masing-masing pengguna. Gambar 8.21 mengilustrasikan
asosiasi entitas dalam contoh kita. Aturan bisnis yang mendasarinya dijelaskan
selanjutnya.
1.Terdapat hubungan 0,M:M antara entitas Pesanan Pembelian dan Inventaris. Artinya, setiap
item persediaan mungkin telah dipesan berkali-kali atau tidak pernah dipesan dalam
periode bisnis saat ini. Jelasnya, setiap item inventaris pasti pernah dibeli setidaknya sekali
di masa lalu, jadi mengapa kita menunjukkan kardinalitas 0,M untuk entitas Pesanan
Pembelian? Kita harus ingat bahwa entitas transaksi, seperti penjualan dan pembelian,
dikaitkan dengan jangka waktu tertentu. Kami berasumsi bahwa tabel Pesanan Pembelian
untuk sistem ini akan berisi catatan pembelian yang dilakukan pada periode berjalan saja.
Pesanan pembelian yang ditutup pada periode sebelumnya akan dihapus ke tabel arsip,
yang tidak ditampilkan dalam contoh kita.
2.Terdapat hubungan M:M antara entitas Inventaris dan Pemasok. Ini berarti satu atau
lebih vendor memasok setiap item inventaris, dan masing-masing vendor memasok
satu atau lebih item inventaris.
3.Terdapat hubungan 1:0,M antara Pemasok dan entitas Pesanan Pembelian. Artinya pada
periode berjalan, setiap pemasok mungkin menerima nol atau banyak pesanan pembelian,
namun setiap pesanan hanya ditujukan ke satu pemasok.
4.Terdapat hubungan 1:1 antara entitas Pesanan Pembelian dan Laporan Penerimaan. Catatan
laporan penerimaan tunggal mencerminkan penerimaan barang yang ditentukan pada catatan
pesanan pembelian tunggal. Beberapa pesanan pembelian tidak digabungkan dalam satu
laporan penerimaan.
5.Hubungan antara entitas Laporan Penerimaan dan Inventaris adalah 0,M:M. Hal ini menandakan
bahwa dalam periode tersebut, setiap item persediaan mungkin telah diterima
GAMBAR 8.21
Pembaruan Mengandung
Inventaris
Model data
Menampilkan Entitas
Asosiasi
Persediaan
Dikirim ke
Pemasok
Berhubungan dengan
Menerima Laporan Pesanan Pembelian
berkali-kali atau tidak pernah. Selain itu, setiap laporan penerimaan dikaitkan dengan setidaknya satu
dan mungkin banyak item inventaris.
Asosiasi banyak-ke-banyak (M:M dan 0,M:M) dalam model data perlu diselesaikan sebelum
database fisik dapat dibuat. Kita tahu dari diskusi sebelumnya bahwa asosiasi ini menandakan
adanya entitas yang hilang yang diperlukan untuk menghubungkannya. Kami akan
menyelesaikan masalah ini selama proses normalisasi.
Tambahkan Kunci Utama dan Atribut ke Model
Tambahkan Kunci Utama.Langkah selanjutnya dalam proses ini adalah menetapkan kunci utama
ke entitas dalam model. Analis harus memilih kunci utama yang secara logis mendefinisikan atribut
bukan kunci dan secara unik mengidentifikasi setiap kejadian dalam entitas. Terkadang hal ini dapat
dicapai dengan menggunakan kode berurutan sederhana seperti Nomor Faktur, Nomor Cek, atau
nomor Pesanan Pembelian. Namun, kode sekuensial tidak selalu merupakan kunci yang efisien atau
efektif. Melalui desain yang cermat terhadap kode blok, kode grup, kode alfabet, dan kode mnemonik,
kunci primer juga dapat memberikan informasi berguna tentang sifat entitas. Teknik-teknik ini
dibahas secara rinci di Bab 6. Gambar 8.22 menyajikan empat entitas dalam model dengan kunci
utama yang ditetapkan.
Tambahkan Atribut.Setiap atribut dalam suatu entitas harus muncul secara langsung atau tidak langsung (nilai
terhitung) dalam satu atau beberapa tampilan pengguna. Oleh karena itu, atribut entitas awalnya diturunkan dan
dimodelkan dari tampilan pengguna. Dengan kata lain, jika data yang disimpan tidak digunakan dalam dokumen,
laporan, atau penghitungan yang dilaporkan dengan cara tertentu, maka data tersebut tidak ada gunanya dan tidak
boleh menjadi bagian dari database. Atribut yang ditetapkan untuk masing-masing entitas pada Gambar 8.23
berasal dari tampilan pengguna pada Pesanan Pembelian dan Laporan Penerimaan yang diilustrasikan pada Gambar
8.20 dan dari Laporan Status Inventaris yang sebelumnya kami normalkan.
GAMBAR 8.22
Inventaris
Pembaruan Mengandung
Nomor Bagian
Model data
Menampilkan Utama
Kunci
Persediaan
Pemasok
Dikirim ke
Nomor Pemasok

Berhubungan dengan
Nomor Perwakilan Rek nomor PO
GAMBAR 8.23
Inventaris
Nomor Bagian
Model data Mengandung
Pembaruan
Menampilkan Kunci Keterangan
Kuantitas di Tangan
dan Atribut
Titik Pemesanan Ulang
Biaya Satuan
Persediaan
Pemasok
Nomor Pemasok Dikirim ke
nama pemasok
Alamat Pemasok
Nomor Telp Pemasok

nomor PO Nomor Bagian
Tanggal Diterima Keterangan
Kode Operator Tanggal pemesanan
Nomor Bill of Lading Berhubungan dengan Pengiriman yang Diminta

Prabayar Tanggal
Mengumpulkan jumlah pesanan

nama pemasok Biaya Satuan
Alamat Pemasok nama pemasok
Nomor Telp Pemasok Alamat Pemasok
Nomor Bagian Nomor Telp Pemasok
Keterangan
Jumlah Diterima
Kode Kondisi
Normalisasikan Model Data dan Tambahkan Kunci Asing
Gambar 8.24 menyajikan model data yang dinormalisasi. Permasalahan normalisasi yang memerlukan
penyelesaian diuraikan pada bagian berikut:
1. Pengulangan Data Grup di Pesanan Pembelian.Atribut Nomor Bagian, Deskripsi,

Jumlah Pesanan, dan Biaya Satuan merupakan data grup berulang. Artinya, jika
pesanan pembelian tertentu berisi lebih dari satu item (seringkali), maka
beberapa nilai perlu diambil untuk atribut ini. Untuk mengatasi hal ini, data grup
berulang ini telah dihapus ke entitas Detail Item PO baru. Entitas baru diberi
kunci utama yang merupakan gabungan Nomor Bagian dan Nomor PO.
Pembuatan entitas baru juga menyelesaikan hubungan M:M antara entitas
Pesanan Pembelian dan Inventaris dengan menyediakan tautan.
2. Pengulangan Data Kelompok dalam Penerimaan Laporan.Atribut Nomor Bagian, Kuantitas
Diterima, dan Kode Kondisi merupakan grup berulang dalam entitas Laporan Penerimaan dan
dipindahkan ke entitas baru yang disebut Detail Item Laporan Rek. KOMPOSIT
GAMBAR 8.24
Inventaris
Pembaruan Berkaitan dengan
Nomor Bagian
Data yang Dinormalisasi
Model Keterangan
Kuantitas di Tangan
Titik Pemesanan Ulang
Biaya Satuan
Dipasok oleh
Laporan Rek Inventaris- Detil Barang PO

Detil Barang Tautan Pemasok Nomor Bagian
Nomor Perwakilan Rek Nomor Bagian nomor PO
Nomor Bagian Nomor Pemasok jumlah pesanan
Jumlah Diterima
(TIDAK ADA DATA)
Kode Kondisi
Persediaan
Pemasok
Mengandung Mengandung
Nomor Pemasok Dikirim ke
nama pemasok
Alamat Pemasok
Nomor Telp Pemasok

nomor PO [FK] Berhubungan dengan Nomor Pemasok [FK]
Tanggal Diterima Tanggal pemesanan
Kode Operator Pengiriman yang Diminta

Nomor Bill of Lading Tanggal
Prabayar
Mengumpulkan
KUNCI yang terdiri dari NOMOR BAGIAN dan NOMOR REPT REKAM telah ditetapkan. Seperti pada
contoh sebelumnya, pembuatan entitas baru ini juga menyelesaikan hubungan M:M antara
Laporan Penerimaan dan Inventaris.
3. Ketergantungan Transitif.Entitas Pesanan Pembelian dan Laporan Penerimaan
berisi atribut yang berlebihan dengan data di entitas Inventaris dan Pemasok.
Redundansi ini terjadi karena ketergantungan transitif (lihat Lampiran bab ini)
dalam entitas Pesanan Pembelian dan Laporan Penerimaan dan dihilangkan.
Bangun Database Fisik

Gambar 8.25 mengilustrasikan struktur tabel 3NF untuk database. Kunci utama dan kunci asing
yang menghubungkan tabel diwakili oleh garis putus-putus. Poin-poin berikut ini patut
dijabarkan.
GAMBAR 8.25 9 10 12
Kuantitas
Dinormalisasi Inventaris Bagian Satuan
Nomor Des. di Tangan Biaya
Tabel
Kunci Gabungan
11
Barang PO Bagian PO Memesan
Detil Nomor Nomor Kuantitas
1 5 6
Pembelian PO Pemasok Memesan Diminta
Memesan Nomor Nomor Tanggal Tanggal pengiriman
Menerima Rek Rep PO Tanggal Pembawa Daftar muatan Pra-

Laporan Nomor Nomor Diterima Kode Nomor Dibayar Mengumpulkan
Kunci Gabungan
Rek Rep Rek Rep Bagian Kuantitas Kondisi

Detil Barang Nomor Nomor Diterima Kode
Kunci Gabungan
Inventaris/
Pemasok
Pemasok
Bagian
Nomor Nomor
Tautan
7 2 3 4 8
Pemasok Pemasok Pemasok Pemasok Pemasok
Nomor Nama Alamat Nomor Telp Ketentuan
Tampilan Pengguna—Pesanan Pembelian
Pesanan Pembelian 1PO 39763

nama pemasok
2
Alamat Pemasok
3
Nomor Telp.
4
Memesan Tanggal Pemasok Ketentuan
Tanggal Diperlukan Nomor

8
5 //
6 //
7
Bagian Memesan Satuan Diperpanjang
Nomor Keterangan Kuantitas Biaya Biaya
9 10 11 12
9 10 11 12
Bidang Terhitung
9 10 11 12
9 10 11 12
Dihitung
9 10 11 12 Bidang
Total biaya ( )
Setiap catatan dalam tabel Detail Item Laporan Rek mewakili item individual pada laporan
penerimaan. Tabel tersebut memiliki kunci gabungan yang terdiri dari REC REPT NUMBER dan
PART NUMBER. Kunci komposit ini diperlukan untuk secara unik mengidentifikasi atribut
Kuantitas yang Diterima dan Kondisi dari setiap rekaman detail item. Bagian REC REPT NUMBER
dari kunci menyediakan tautan ke tabel Laporan Penerimaan yang berisi data umum tentang
peristiwa penerimaan. Bagian NOMOR BAGIAN dari kunci digunakan untuk mengakses tabel
Inventaris untuk memfasilitasi pembaruan bidang Kuantitas yang Ada dari bidang Kuantitas
yang Diterima pada catatan Detail Item.
Tabel Detail Item PO menggunakan kunci utama komposit PO NUMBER dan PART NUMBER
untuk mengidentifikasi atribut Kuantitas Pesanan secara unik. Komponen PO NUMBER dari
kunci komposit menyediakan tautan ke tabel Pesanan Pembelian. Elemen PART NUMBER dari
kunci adalah tautan ke tabel Inventaris tempat data Deskripsi dan Biaya Unit berada.
Langkah selanjutnya adalah membuat tabel fisik dan mengisinya dengan data. Ini adalah
langkah rumit yang harus direncanakan dan dilaksanakan dengan hati-hati dan mungkin memakan
waktu berbulan-bulan dalam instalasi besar. Program perlu ditulis untuk mentransfer data organisasi
yang saat ini disimpan dalam file datar atau database lama ke tabel relasional baru. Data yang saat ini
disimpan pada dokumen kertas mungkin perlu dimasukkan ke dalam tabel database secara manual.
Setelah ini selesai, tampilan pengguna fisik dapat dihasilkan.
Siapkan Tampilan Pengguna
Tabel yang dinormalisasi harus cukup kaya untuk mendukung pandangan semua pengguna sistem yang
dimodelkan. Misalnya, PO pada Gambar 8.25, yang bisa menjadi layar entri data untuk petugas pembelian,
telah dibangun dari atribut-atribut yang terletak di beberapa tabel. Untuk mengilustrasikan hubungan
tersebut, bidang dalam tampilan pengguna direferensikan silang melalui angka yang dilingkari ke atribut
dalam tabel pendukung. Ingatlah bahwa tabel ini juga dapat memberikan data untuk banyak tampilan lain
yang tidak ditampilkan di sini, seperti laporan penerimaan, daftar daftar permintaan pembelian, laporan
status inventaris, dan laporan aktivitas pembelian vendor.
Fungsi query dari DBMS relasional memungkinkan perancang sistem dengan mudah membuat
tampilan pengguna dari tabel. Perancang hanya memberitahu DBMS tabel mana yang akan digunakan, kunci
utama dan asingnya, dan atribut yang harus dipilih dari setiap tabel. DBMS yang lebih lama mengharuskan
perancang untuk menentukan parameter tampilan secara langsung di SQL. Sistem yang lebih baru
melakukan ini secara visual. Perancang cukup menunjuk dan mengklik tabel dan atributnya. Dari representasi
visual ini, DBMS menghasilkan perintah SQL untuk query guna menghasilkan tampilan.
Tampilan Laporan Penerimaan, Pesanan Pembelian, dan Laporan Status Inventaris semuanya akan
dibuat dengan cara ini. Sebagai ilustrasi, perintah SQL yang diperlukan untuk menghasilkan laporan status
inventaris yang diilustrasikan pada Gambar 8.15 diberikan di bagian berikut.
PILIH inventaris.nomor bagian, deskripsi, jumlah yang ada, titik pemesanan ulang,
EOQ, nomor bagian pemasok.nomor bagian, nomor pemasok.pemasok, nomor
pemasok.pemasok, nama, alamat, nomor telepon , DARI inventaris, pemasok suku
cadang, pemasok
DIMANA inventaris.part-num pemasok suku cadang.nomor bagian DAN pemasok suku cadang.
nomor pemasok pemasok.nomor pemasok DAN jumlah yang tersedia titik pemesanan ulang.
• Perintah SELECT mengidentifikasi semua atribut yang akan dimuat dalam

tampilan. Jika atribut yang sama muncul di lebih dari satu tabel (misalnya, PART-
NUM), nama tabel sumber juga harus ditentukan.
• Perintah FROM mengidentifikasi tabel yang digunakan dalam membuat tampilan.
• Perintah WHERE menentukan bagaimana baris dalam tabel Inventaris, Pemasok Bagian,
dan Pemasok harus dicocokkan untuk membuat tampilan. Dalam hal ini, ketiga tabel
digabungkan secara aljabar pada kunci utama PART-NUM dan SUPPLIER-NUMBER.
Modul Audit Tertanam 359
• Beberapa ekspresi dapat dihubungkan dengan operator AND, OR, dan NOT. Dalam contoh ini,
ekspresi terakhir menggunakan AND untuk membatasi rekaman yang akan dipilih dengan
ekspresi logika titik pemesanan ulang quant-on-hand. Hanya rekaman yang kuantitasnya telah
turun hingga atau di bawah titik pemesanan ulang yang akan dipilih untuk dilihat.
Pengguna tidak akan melihat ribuan item inventaris lain yang tersedia dalam
jumlah memadai.
Perintah SQL ini akan disimpan dalam program pengguna yang disebut query. Untuk melihat laporan
Status Inventaris, agen pembelian menjalankan program kueri. Setiap kali hal ini dilakukan, kueri akan
membuat tampilan baru dengan data terkini dari tabel Inventaris dan Vendor. Dengan memberikan
permintaan pribadi kepada pengguna, daripada mengizinkan akses ke tabel dasar yang
mendasarinya, pengguna dibatasi hanya pada data yang diotorisasi.
Program laporan digunakan untuk membuat tampilan menarik secara visual dan mudah
digunakan. Judul kolom dapat ditambahkan, kolom dijumlahkan, dan rata-rata dihitung untuk
menghasilkan laporan hardcopy atau layar komputer yang menyerupai laporan pengguna asli pada
Gambar 8.15. Program laporan dapat menyembunyikan data yang tidak diperlukan dari tampilan,
seperti bidang duplikat dan nilai kunci dalam tabel tautan Inventaris/Vendor. Kunci ini diperlukan
untuk membuat tampilan, namun tidak diperlukan dalam laporan sebenarnya.
Integrasi Tampilan Global
Proses pemodelan tampilan yang dijelaskan sebelumnya hanya berkaitan dengan satu fungsi
bisnis, yaitu sistem pembelian—dan tabel serta tampilan yang dihasilkan hanya merupakan
subskema dari keseluruhan skema database. Namun, perusahaan modern memerlukan ratusan
atau ribuan tampilan dan tabel terkait. Menggabungkan kebutuhan data semua pengguna ke
dalam satu skema atau tampilan seluruh perusahaan disebutlihat integrasi. Ini adalah tugas
yang berat ketika membuat seluruh database dari awal. Untuk memfasilitasi tugas ini, sistem
Enterprise Resource Planning (ERP) modern (dibahas dalam Bab 11) dilengkapi dengan skema
inti, tabel yang dinormalisasi, dan templat tampilan. Basis data praktik terbaik ini berasal dari
model ekonomi yang mengidentifikasi kesamaan antara kebutuhan data berbagai organisasi.
Misalnya, semua organisasi yang menjual produk ke pelanggan akan memerlukan tabel
Inventaris, tabel Pelanggan, tabel Pemasok, dan lain sebagainya. Banyak atribut dan kunci
dalam tabel ini juga umum untuk semua organisasi. Bekerja dari database inti ERP, proses
pemodelan tampilan menjadi salah satu konfigurasi atau penyesuaian tampilan yang telah
ditentukan sebelumnya untuk mengakomodasi kebutuhan pengguna tertentu. Namun vendor
ERP tidak dapat mengantisipasi kebutuhan informasi semua pengguna terlebih dahulu. Oleh
karena itu, tabel baru dan atribut baru mungkin perlu ditambahkan ke skema inti. Meskipun
mengkonfigurasi database inti dengan cara ini jauh lebih efisien dibandingkan bekerja dari
awal, tujuannya tetap sama. Perancang basis data harus menghasilkan sekumpulan tabel
terintegrasi yang bebas dari anomali pembaruan, penyisipan, dan penghapusan serta cukup
kaya untuk melayani kebutuhan semua pengguna.
MODUL AUDIT TERTANAM

Tujuan darimodul audit tertanam (EAM), juga dikenal sebagaiaudit berkelanjutan, adalah untuk
mengidentifikasi transaksi penting saat sedang diproses dan mengekstrak salinannya secara real
time. EAM adalah modul yang diprogram secara khusus yang tertanam dalam aplikasi host untuk
menangkap jenis transaksi yang telah ditentukan untuk analisis selanjutnya. Pendekatan ini
diilustrasikan pada Gambar 8.26.
GAMBAR 8.26
Produksi
Audit Tertanam Transaksi
Teknik Modul
Produksi
Auditor menetapkan ambang
Aplikasi
batas materialitas untuk Produksi
mencatat transaksi.
EAM File Induk
Auditor meninjau file audit dan

menyiapkan daftar transaksi
Produksi
material untuk digunakan
Keluaran
tes substantif. Berkas Audit
Hasil produksi
pergi ke pengguna.
Transaksi
Daftar
Saat transaksi yang dipilih sedang diproses oleh aplikasi host, salinan transaksi disimpan
dalam file audit untuk ditinjau selanjutnya. Pendekatan EAM memungkinkan transaksi yang
dipilih untuk ditangkap sepanjang periode audit. Transaksi yang tercatat tersedia bagi auditor
secara real-time, pada akhir periode, atau kapan saja selama periode berjalan, sehingga secara
signifikan mengurangi jumlah pekerjaan yang harus dilakukan auditor untuk mengidentifikasi
transaksi signifikan untuk pengujian substantif.
Untuk memulai pengambilan data, auditor menentukan kepada EAM parameter dan ambang batas
materialitas dari transaksi yang ditetapkan untuk diambil. Sebagai contoh, mari kita asumsikan bahwa
auditor menetapkan ambang batas materialitas sebesar $50.000 untuk transaksi yang diproses oleh sistem
pemrosesan pesanan penjualan. Transaksi yang sama dengan atau lebih besar dari $50.000 akan disalin ke
file audit. Dari rangkaian transaksi ini, auditor dapat memilih subset yang akan digunakan untuk pengujian
substantif. Transaksi yang berada di bawah ambang batas ini akan diabaikan oleh EAM.
Meskipun pada dasarnya merupakan teknik pengujian substantif, EAM juga dapat digunakan
untuk memantau pengendalian secara berkelanjutan seperti yang disyaratkan oleh SAS 109. Misalnya,
transaksi yang dipilih oleh EAM dapat ditinjau untuk otorisasi yang tepat, kelengkapan dan keakuratan
pemrosesan, dan posting yang benar ke akun.
Kekurangan EAM
Pendekatan EAM memiliki dua kelemahan signifikan. Yang pertama berkaitan dengan efisiensi
operasional dan yang kedua berkaitan dengan integritas EAM.
Efisiensi operasional
Dari sudut pandang pengguna, EAM menurunkan kinerja operasional. Kehadiran modul
audit dalam aplikasi host dapat menimbulkan overhead yang signifikan, terutama ketika
jumlah pengujian ekstensif. Salah satu pendekatan untuk meringankan beban ini dari
Perangkat Lunak Audit Umum 361
sistemnya adalah merancang modul yang dapat dihidupkan dan dimatikan oleh auditor. Tentu saja,
hal ini akan mengurangi efektivitas EAM sebagai alat audit yang berkelanjutan.
Memverifikasi Integritas EAM

Pendekatan EAM mungkin bukan teknik audit yang layak dalam lingkungan dengan tingkat
pemeliharaan program yang tinggi. Ketika aplikasi host sering mengalami perubahan, EAM
yang tertanam di dalam host juga akan sering memerlukan modifikasi. Kekhawatiran integritas
yang diangkat sebelumnya mengenai pemeliharaan aplikasi juga berlaku untuk EAM. Integritas
EAM secara langsung mempengaruhi kualitas proses audit. Oleh karena itu auditor harus
mengevaluasi integritas EAM. Evaluasi ini dilakukan dengan cara yang sama seperti menguji
kontrol aplikasi host.
PERANGKAT LUNAK AUDIT UMUM

Perangkat lunak audit umum (GAS)adalah CAATT yang paling banyak digunakan untuk audit IS. GAS
memungkinkan auditor untuk mengakses file data yang dikodekan secara elektronik dan melakukan
berbagai operasi pada isinya. Beberapa kegunaan GAS yang lebih umum meliputi:
• Memposisikan dan menyeimbangkan seluruh file atau item data yang dipilih
• Memilih dan melaporkan data rinci yang terkandung dalam file
• Memilih sampel statistik bertingkat dari file data
• Memformat hasil tes menjadi laporan
• Mencetak konfirmasi dalam kata-kata standar atau khusus
• Menyaring data dan secara selektif memasukkan atau mengecualikan item
• Membandingkan beberapa file dan mengidentifikasi perbedaan apa pun
• Menghitung ulang bidang data
Popularitas GAS yang meluas disebabkan oleh empat faktor: (1) Bahasa GAS mudah digunakan dan
memerlukan sedikit latar belakang komputer dari pihak auditor; (2) banyak produk GAS yang dapat
digunakan pada sistem mainframe dan PC; (3) auditor dapat melakukan pengujiannya secara
independen terhadap staf layanan komputer klien; dan (4) GAS dapat digunakan untuk mengaudit
data yang disimpan di sebagian besar struktur dan format file.
Menggunakan GAS untuk Mengakses Struktur Sederhana
Mendapatkan akses ke struktur file datar adalah proses yang relatif sederhana, seperti
diilustrasikan pada Gambar 8.27. Dalam contoh ini, file inventaris dibaca langsung oleh
GAS, yang mengekstrak informasi penting yang diperlukan untuk audit, termasuk
kuantitas yang ada, nilai dolar, dan lokasi gudang setiap item inventaris. Tugas auditor
adalah memverifikasi keberadaan dan nilai persediaan dengan melakukan penghitungan
fisik atas sampel yang mewakili persediaan yang ada. Jadi, berdasarkan ambang batas
materialitas yang diberikan oleh auditor, GAS memilih catatan sampel dan menyiapkan
laporan yang berisi informasi yang diperlukan.
Menggunakan GAS untuk Mengakses Struktur Kompleks
Mendapatkan akses ke struktur yang kompleks, seperti file hash atau bentuk file acak lainnya,
dapat menimbulkan masalah bagi auditor. Tidak semua produk GAS di pasaran mampu
mengakses semua jenis struktur file. Jika CAATT yang dimaksud tidak mampu menangani
GAMBAR 8.27 Struktur File Sederhana

(File Datar)
Menggunakan GAS untuk
Akses File Sederhana

Struktur Produksi
File Inventaris
Auditor menentukan kriteria pemilihan

(ambang batas materialitas) dan bidang-
bidang utama yang akan dipilih
diambil oleh GAS.
GAS
GAS mengekstrak data yang dipilih oleh
auditor dan menghasilkan daftar item
inventaris yang akan dibuat
dihitung sebagai bagian
dari pengujian substantif.
Transaksi
Daftar
GAMBAR 8.28 Struktur File yang Kompleks
DBMS
Menggunakan GAS untuk Kegunaan
Akses Kompleks Program Basis data
Struktur Berkas 1 Auditor menentukan database

mana yang akan dicatat
salin ke file datar. 2 Sistem manajemen basis data
menghasilkan file datar dari
sebagian basis data.
File Datar
4 GAS mengambil yang dipilih

catatan dari file datar.
GAS
3 Auditor menentukan
kriteria seleksi yang
digunakan oleh GAS.
Transaksi
Daftar
struktur yang kompleks, auditor mungkin perlu meminta profesional sistem untuk menulis program
khusus yang akan menyalin catatan dari struktur sebenarnya ke struktur sekuensial file datar untuk
memudahkan pengambilan. Gambar 8.28 mengilustrasikan pendekatan ini.
Kebanyakan DBMS mempunyai fitur utilitas yang dapat digunakan untuk memformat ulang
struktur kompleks menjadi file datar yang sesuai untuk tujuan ini. Untuk mengilustrasikan proses
perataan file, perhatikan struktur database kompleks yang disajikan pada Gambar 8.29. Struktur
database menggunakan pointer untuk mengintegrasikan tiga file terkait—Pelanggan, Faktur
Penjualan, dan Item Baris—dalam susunan hierarki. Mengekstraksi bukti audit dari struktur
kompleksitas ini menggunakan GAS mungkin sulit, bahkan tidak mungkin. Versi file datar yang lebih
sederhana dari struktur ini diilustrasikan pada Gambar 8.30. File datar tunggal menyajikan tiga jenis
rekaman sebagai struktur berurutan yang dapat diakses dengan mudah oleh GAS.
Perangkat Lunak ACL 363
GAMBAR 8.29 Struktur Basis Data yang Kompleks
Saat ini
Pelanggan # Nama Alamat Keseimbangan Petunjuk
Pelanggan
Rekor Sebelumnya 1875 J.Smith 18 Jalan Elm. 1820 Rekam Berikutnya
Mengajukan
Untuk Mencatat Kepala dalam
Daftar Penerimaan Kas
Untuk Mencatat Kepala dalam Daftar Faktur Penjualan
Mengirimkan
Faktur # $ Jumlah Tanggal Petunjuk

Faktur penjualan
1921 800 12/10/04 Selanjutnya Faktur untuk Pelanggan #1875 Faktur Terakhir untuk Pelanggan #1875
Mengajukan
Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya
Satuan Diperpanjang Satuan Diperpanjang
Barang # Jumlah Harga Harga penunjuk Barang # Jumlah Harga Harga penunjuk
Item baris Terakhir

83581 10 45.00 450,00 1325 1 350,00 350,00 Catatan Catatan Item Baris untuk Faktur Lain
Mengajukan
Penunjuk ke Rekaman Berikutnya
Masalah Audit Terkait Pembuatan Flat File

Auditor terkadang harus mengandalkan personel layanan komputer untuk menghasilkan file
datar dari struktur file yang kompleks. Ada risiko integritas data akan terganggu oleh prosedur
yang digunakan untuk membuat file datar. Misalnya, jika tujuan auditor adalah untuk
mengonfirmasi piutang usaha, akun-akun penipuan tertentu dalam struktur kompleks mungkin
sengaja dihilangkan dari salinan file datar yang dibuat. Oleh karena itu, sampel konfirmasi yang
diambil dari flat file mungkin tidak dapat diandalkan. Auditor yang ahli dalam bahasa
pemrograman dapat menghindari potensi jebakan ini dengan menulis rutinitas ekstraksi data
mereka sendiri.
PERANGKAT LUNAK ACL
Di masa lalu, kantor akuntan publik mengembangkan versi GAS yang dipatenkan, yang mereka
gunakan dalam audit klien mereka. Baru-baru ini, perusahaan perangkat lunak telah melayani pasar
ini. Diantara mereka,ACL(bahasa perintah audit) adalah pemimpin dalam industri. ACL dirancang
sebagai meta-bahasa bagi auditor untuk mengakses data yang disimpan dalam berbagai format
digital dan mengujinya secara komprehensif. Faktanya, banyak masalah yang terkait dengan
pengaksesan struktur data yang kompleks telah diselesaikan oleh antarmuka Open Database
Connectivity (ODBC) ACL.
Sisa bab ini menyoroti fitur-fitur ACL yang lebih umum digunakan. Dalam
bab-bab selanjutnya, fitur-fitur ini dan lainnya ditunjukkan dalam konteks
prosedur audit tertentu, dan setiap bab berisi beberapa tugas yang dirancang
untuk memberikan siswa pengalaman ACL langsung. CD yang menyertai buku
teks ini berisi perangkat lunak ACL edisi pendidikan, buku petunjuk, dan contoh
file data. Tugas yang digunakan dalam buku ini memanfaatkan sumber-sumber
ini.
GAMBAR 8.30 Struktur File Datar
Versi Datar dari

1875 J.Smith 18 Jalan Elm. 1820
File Kompleks
Struktur 1921 800 12/10/04
83561 10 45.00 450,00
1326 1 350,00 350,00
Selanjutnya Faktur untuk Pelanggan #1875

Data Penjualan
untuk Pelanggan Item Baris untuk Faktur
#1875
Faktur Terakhir untuk Pelanggan #1875
Item Baris Terakhir
Catatan Pelanggan Berikutnya
Faktur Penjualan untuk Pelanggan Berikutnya
Item baris
Item baris
Item Baris Terakhir
Catatan Pelanggan Terakhir
Faktur Penjualan untuk Pelanggan Terakhir
Item baris
Item Baris Terakhir
Definisi Data
Kami telah menetapkan bahwa sistem klien dapat menyimpan data menggunakan
sejumlah flatfile atau struktur database, termasuk file sekuensial, file VSAM, daftar tertaut,
dan tabel relasional. Salah satu kekuatan ACL adalah kemampuannya membaca data yang
disimpan dalam sebagian besar format. ACL menggunakandefinisi datafitur untuk tujuan
ini. Untuk membuat definisi data, auditor perlu mengetahui lokasi fisik file sumber dan
tata letak struktur lapangannya. File kecil dapat diimpor melalui file teks atau spreadsheet.
File yang sangat besar mungkin perlu diakses langsung dari komputer mainframe. Jika hal
ini terjadi, auditor harus mendapatkan hak akses ke direktori tempat file berada. Namun,
jika memungkinkan, salinan file tersebut harus disimpan dalam direktori pengujian
terpisah atau diunduh ke PC auditor. Langkah ini biasanya memerlukan bantuan
profesional sistem. Auditor harus memastikan bahwa dia mendapatkan versi yang benar
file, lengkap, dan dokumentasi struktur file masih utuh. Pada titik ini, auditor
siap untuk mendefinisikan file ke ACL. Gambar 8.31 mengilustrasikan layar
definisi data ACL.
Layar definisi data memungkinkan auditor untuk menentukan karakteristik penting dari file
sumber, termasuk panjang catatan secara keseluruhan, nama yang diberikan untuk setiap
bidang, jenis data (yaitu numerik atau karakter) yang terdapat dalam setiap bidang, serta titik
awal dan panjangnya. dari setiap bidang dalam file. Definisi ini disimpan dalam tabel dengan
nama yang diberikan oleh auditor. Karena file pada Gambar 8.31 berisi data inventaris, maka
tabel tersebut harus diberi nama INVENTARISuntuk contoh ini. Setelah definisi data selesai,
akses selanjutnya ke tabel dapat dilakukan hanya dengan memilihINVENTARISdari folder tabel
ACL di bawah menu manajer proyek. ACL secara otomatis mengambil file dan menampilkannya
di layar sesuai dengan definisi datanya. Misalnya, Gambar 8.32 mengilustrasikan tampilan file
Inventaris setelahINVENTARISASI.fildefinisi dibuat. Seperti yang akan kita lihat, pandangan
terhadap data ini dapat diubah sesuai kebutuhan auditor.
Gambar
SUMBER: © 2011 ACL Services Ltd.
Menyesuaikan Tampilan
Tampilan hanyalah cara melihat data dalam file; auditor jarang perlu menggunakan semua data yang
terdapat dalam sebuah file. ACL memungkinkan auditor untuk menyesuaikan tampilan asli yang dibuat
selama definisi data menjadi tampilan yang lebih memenuhi kebutuhan auditnya. Auditor dapat membuat
dan memformat ulang tampilan baru tanpa mengubah atau menghapus data dalam file yang mendasarinya.
Hanya penyajian data yang terpengaruh. Misalnya, file inventaris pada Gambar 8.32 berisi sejumlah bidang
yang tidak relevan dengan audit. Selain itu, data penting yang menjadi perhatian auditor tidak disusun dalam
bidang yang berdekatan. Sebaliknya, data tersebut diselingi dengan data yang tidak relevan, sehingga
membuat peninjauan terhadap data penting menjadi sulit. Auditor dapat dengan mudah menghapus dan/
atau mengatur ulang data untuk memfasilitasi penggunaan yang efektif. Gambar 8.33 menyajikan tampilan
data inventaris yang ditata ulang dan berfokus pada elemen data penting.
Gambar
Gambar
Memfilter Data
ACL memberikan opsi canggih untuk memfilter data yang mendukung berbagai pengujian audit.Filter
adalah ekspresi yang mencari rekaman yang memenuhi kriteria filter. ACLpembangun ekspresi
memungkinkan auditor untuk menggunakan operator logis seperti AND, OR, , , NOT dan lainnya
untuk menentukan dan menguji kondisi dengan kompleksitas apa pun dan untuk memproses hanya
catatan yang cocok dengan kondisi tertentu. Misalnya, auditor dapat mencari file inventaris untuk
catatan dengan kuantitas negatif atau nol. Layar pembuat ekspresi dan filter yang diperlukan untuk
pengujian ini diilustrasikan pada Gambar 8.34.
Ketika auditor menjalankan prosedur filter ini, ACL menghasilkan tampilan baru dari file
inventaris (Gambar 8.35) yang berisi empat catatan dengan tingkat kuantitas yang ada di tangan nol
atau negatif. Contoh ini menunjukkan bagaimana auditor menggunakan ACL untuk mencari anomali
dan kondisi yang tidak biasa dalam file akuntansi yang berisi ribuan catatan yang tidak dapat ditinjau
dengan memindai isinya secara visual.
GAMBAR 8.34
Ekspresi
Pembangun
SUMBER: Atas perkenan ACL Services Ltd.
Gambar
Stratifikasi Data
Fitur stratifikasi ACL memungkinkan auditor melihat distribusi catatan yang termasuk dalam strata
tertentu. Data dapat dikelompokkan berdasarkan bidang numerik apa pun seperti harga jual, biaya
unit, jumlah terjual, dan sebagainya. Data dirangkum dan diklasifikasikan berdasarkan strata, yang
ukurannya bisa sama (disebutinterval) atau ukurannya bervariasi (disebutbebas). Gambar 8.36
mengilustrasikan hasil stratifikasi tabel persediaan pada bidang unit-cost. Dalam contoh ini, nilai
persediaan juga dihitung untuk setiap interval.
Laporan bertingkat yang disajikan pada Gambar 8.36 menunjukkan data biaya unit yang dialokasikan
dalam 10 interval dari $6,87 hingga $381,20. Auditor dapat memilih untuk mengubah ukuran dan jumlah
interval atau hanya memeriksa sebagian dari file. Misalnya, dua strata pertama menunjukkan bahwa
keduanya mengandung jumlah item yang tidak proporsional. Auditor dapat memperoleh gambaran yang
lebih jelas mengenai struktur biaya persediaan dengan meningkatkan jumlah interval atau dengan
mengurangi batas atas kisaran menjadi $71.
Analisis statistik
ACL menawarkan banyak metode pengambilan sampel untuk analisis statistik. Dua yang paling sering
digunakan adalahpengambilan sampel rekamanDanpengambilan sampel unit moneter (MUS). Setiap
metode memungkinkan pengambilan sampel secara acak dan interval. Pilihan metode akan bergantung pada
strategi auditor dan komposisi berkas yang diaudit. Di satu sisi, ketika catatan dalam suatu file didistribusikan
secara merata ke seluruh strata, auditor mungkin menginginkan sampel yang tidak bias dan dengan
demikian akan memilih pendekatan sampel catatan. Dengan menggunakan inventaris sebagai ilustrasi,
setiap catatan, berapa pun jumlah dolar di bidang nilai inventaris, memiliki peluang yang sama untuk
dimasukkan ke dalam sampel. Di sisi lain, jika file tersebut sangat miring dengan item-item bernilai besar,
auditor dapat memilih MUS, yang akan menghasilkan sampel yang mencakup semua jumlah dolar yang lebih
besar.
GAMBAR 8.36
Tabel Inventaris
Berstrata pada Unit
Biaya
RINGKASAN
Bab ini dimulai dengan tinjauan struktur data, yang menentukan (1) bagaimana catatan disusun
dalam file fisik atau database dan (2) metode akses yang digunakan untuk menavigasi file.
Sejumlah struktur data dasar diperiksa, termasuk sekuensial, terindeks, hashing, dan pointer.
Bab ini juga mengulas model data relasional secara rinci. Cakupan mencakup konsep relasional,
terminologi, teknik penautan tabel, normalisasi basis data, dan prosedur desain basis data. Bab
ini kemudian berfokus pada penggunaan CAATT untuk ekstraksi dan analisis data. Ekstraksi
data dapat dilakukan dengan modul audit tertanam dan perangkat lunak audit umum.
Perangkat lunak ini mendukung dua jenis pengujian audit yang (1) memungkinkan auditor
membuat kesimpulan tentang efektivitas pengendalian penerapan, dan (2) menyediakan akses
ke data yang diperlukan untuk pengujian substantif. Bab ini menjelaskan fitur, kelebihan, dan
kekurangan pendekatan modul audit tertanam (EAM). Bagian ini kemudian menguraikan
fungsi-fungsi umum dan penggunaan perangkat lunak audit umum (GAS). Bab ini ditutup
dengan tinjauan fitur ACL yang lebih umum digunakan, produk GAS komersial terkemuka.
Lampiran
NORMALISASI TABEL DALAM DATABASE RELASI

Anomali database (dijelaskan dalam bab ini) adalah gejala masalah struktural dalam tabel yang
disebut dependensi. Secara khusus, hal ini dikenal sebagai grup berulang, ketergantungan
parsial, dan ketergantungan transitif. Proses normalisasi melibatkan identifikasi dan
penghapusan dependensi ini secara sistematis dari tabel yang ditinjau. Gambar 8.37 secara
grafis mengilustrasikan perkembangan tabel yang tidak dinormalisasi menuju 3NF seiring
dengan diselesaikannya setiap jenis ketergantungan. Tabel di 3NF akan bebas dari anomali dan
memenuhi dua kondisi:
1.Semua atribut bukan kunci akan bergantung sepenuhnya dan unik pada (didefinisikan oleh)
kunci utama.
2.Tak satu pun dari atribut bukan kunci akan bergantung pada (didefinisikan oleh) atribut bukan kunci
lainnya.
GAMBAR 8.37
Tampilan Pengguna
Langkah-langkah di
Normalisasi
Proses
Mewakili Tampilan dengan Tabel
Tunggal
Tabel Tidak Dinormalisasi
Hapus Grup Berulang
Tabel Bentuk Normal Pertama (1NF)
Hapus Ketergantungan Parsial
Tabel Bentuk Normal Kedua (2NF)
Hapus Ketergantungan Transitif
Tabel Bentuk Normal Ketiga (3NF)
371
Rancang Tampilan Pengguna
Seperti yang diilustrasikan pada Gambar 8.37, proses dimulai dengan tampilan pengguna seperti laporan
keluaran, dokumen sumber, atau layar masukan. Gambar dari pandangan pengguna dapat disiapkan
menggunakan pengolah kata, paket grafis, atau hanya pensil dan kertas. Pada titik ini, tampilan hanyalah
representasi gambar dari sekumpulan data yang nantinya akan dimiliki pengguna ketika proyek selesai.
Untuk mendemonstrasikan proses normalisasi, kami akan menggunakan faktur penjualan pelanggan dan
contoh data yang disajikan pada Gambar 8.38. Masalah mendasarnya di sini adalah, bisakah kita menyimpan
semua data yang diperlukan untuk tampilan ini dalam satu tabel yang memenuhi dua kondisi yang
disebutkan sebelumnya?
Mewakili Tampilan sebagai Tabel Tunggal
Langkah selanjutnya adalah merepresentasikan tampilan sebagai satu tabel yang berisi semua
atribut tampilan. Gambar 8.39 menyajikan struktur tabel tunggal yang berisi data sampel dari
Gambar 8.38. Karena tabel berisi faktur pelanggan, nomor faktur (INVOICE NUM) akan
berfungsi sebagai kunci utama logis. Perhatikan atribut Ex Price dan Total Due berwarna abu-
abu pada Gambar 8.39. Nilai atribut ini dapat disimpan atau dihitung. Karena Ex Price
merupakan hasil perkalian dari dua atribut lainnya (Kuantitas 3 Harga Satuan) dan Total Due
adalah jumlah seluruh nilai Ex Price, keduanya dapat dihitung dari atribut tersimpan yang
sudah ada dibandingkan menyimpannya secara langsung di tabel database. Oleh karena itu,
untuk menyederhanakan contoh ini, kita asumsikan bahwa sistem akan menghitung atribut-
atribut ini dan atribut-atribut tersebut akan diabaikan dari analisis lebih lanjut.
GAMBAR 8.38
Tampilan Pengguna
FAKTUR PENJUALAN
Nomor Faktur: 16459
Tanggal Pemesanan: 22/09/2009
Tanggal Pengiriman: 27/09/2009
Dikirim Melalui: UPS

Nomor pelanggan:1765
Nama Pelanggan:Rekan ABC Alamat

jalan:132 Jalan Elm. Kota:Betlehem
Negara:PA
Nomor telepon:610-555-6721
Nomor Produksi Keterangan Kuantitas Harga satuan Mantan. Harga
r234 Pemotong baut 2 $42,50 $85,00
m456 Penarik gigi 1 $16,50 $16,50
W62 Tukang las listrik 1 $485,00 $485,00
Total Jatuh Tempo $586,50
Lampiran: Normalisasi Tabel dalam Database Relasional 373
GAMBAR 8.39 Tabel Tidak Normal yang Mendukung Tampilan Pengguna
hal Struktur Tabel Tunggal untuk Faktur Penjualan
Faktur Memesan spd spd Total Jalan Tele Melecut Satuan

Kota St
Bea Cukai Bea Cukai Mantan
Keterangan Jumlah
Nomor Tanggal Tanggal Melalui Jatuh tempo Nomor Nama Alamat Nomor Nomor Harga Harga
16459 22/09/09 27/09/09 UPS 586,50 1765 Asosiasi ABC 132 Jalan Elm Betlehem PA 610-555-6721 r234 Pemotong baut 2 42.50 85.00
16459 22/09/09 27/09/09 UPS 586,50 1765 Asosiasi ABC 132 Jalan Elm Betlehem PA 610-555-6721 m456 Penarik gigi 1 16.50 16.50
16459 22/09/09 27/09/09 UPS 586,50 1765 Asosiasi ABC 132 Jalan Elm Betlehem PA 610-555-6721 W62 tukang las listrik 1 485.00 485.00
Data yang Berlebihan Data Grup Berulang
Sekarang kita memiliki tabel dasar untuk dikerjakan, beberapa langkah selanjutnya dalam proses
normalisasi melibatkan identifikasi dan, jika perlu, menghilangkan ketergantungan struktural yang
ada. Jika ada ketergantungan, perbaikannya akan melibatkan pemisahan struktur tabel tunggal asli
menjadi dua atau lebih tabel 3NF yang lebih kecil dan independen. Masing-masing ketergantungan
struktural dan teknik untuk mengidentifikasi dan menghilangkannya diuraikan di bagian berikut.
MenghapusGrup BerulangData
Langkah pertama dalam mengoreksi ketergantungan struktural adalah menentukan apakah

tabel yang ditinjau berisi grup berulang. Kelompok berulangData adalah keberadaan beberapa
nilai untuk atribut tertentu dalam catatan tertentu. Misalnya, faktur penjualan pada Gambar
8.38 berisi beberapa nilai untuk atribut PROD NUM, DESCRIPTION, QUANTITY, DAN UNIT PRICE
(kita mengabaikan EX PRICE). Grup berulang ini mewakili rincian transaksi faktur. Kami melihat
data grup berulang di banyak tampilan pengguna bisnis, seperti pesanan pembelian, laporan
penerimaan, bill of lading, dan sebagainya. Teori basis data relasional melarang pembuatan
tabel di mana satu catatan (baris dalam tabel) mewakili beberapa nilai untuk suatu atribut
(kolom dalam tabel). Oleh karena itu, untuk merepresentasikan nilai grup yang berulang dalam
satu tabel, diperlukan beberapa baris seperti yang diilustrasikan pada Gambar 8.39. Perhatikan
bahwa atribut faktur, yang umum untuk setiap kemunculan data grup berulang, juga akan
direpresentasikan beberapa kali. Misalnya, Tanggal Pemesanan, Tanggal Pengiriman, Nama
Pelanggan, Alamat Pelanggan, dan sebagainya, dicatat bersama dengan setiap kemunculan
unik Nomor Produk, Deskripsi, Kuantitas, dan Harga Satuan. Untuk menghindari redundansi
data seperti itu, data grup yang berulang perlu dikeluarkan dari tabel dan ditempatkan dalam
tabel terpisah. Gambar 8.40 menunjukkan tabel yang dihasilkan. Salah satunya disebut Tabel
Faktur Penjualan, dengan NUM INVOICE sebagai kunci utama. Tabel kedua berisi rincian
transaksi faktur dan disebut Tabel Item Baris.
Perhatikan bahwa kunci utama Tabel Item Baris adalah akunci kompositterdiri dari dua atribut:
Nomor Faktur dan Nomor Prod. Perlu diingat bahwa tabel ini akan berisi detail transaksi untuk contoh
faktur kami serta detail transaksi untuk faktur untuk semua pelanggan. Teori basis data relasional
mensyaratkan bahwa kunci utama suatu tabel secara unik mengidentifikasi setiap catatan yang
disimpan dalam tabel. PROD NUM sendiri tidak dapat melakukan ini sejak saat itu
GAMBAR 8.40 Struktur Tabel Tunggal untuk Faktur Penjualan
Tabel yang Dihasilkan

Faktur Memesan spd spd Jalan Tele Melecut Satuan
Kota St
Bea Cukai Bea Cukai
Keterangan Jumlah
setelah Menghapus Nomor Tanggal Tanggal Melalui Nomor Nama Alamat Nomor Nomor Harga
Grup Berulang
Data dan
Bidang Terhitung
Tabel Faktur Penjualan

hal
Faktur Memesan spd spd Jalan Tele
Kota St
Bea Cukai Bea Cukai
Nomor Tanggal Tanggal Melalui Nomor Nama Alamat Nomor
hal Tabel Item Baris
Faktur Melecut Satuan

Keterangan Jumlah
Nomor Nomor Harga
produk tertentu, seperti r234 (pemotong baut), mungkin telah dijual ke banyak pelanggan lain
yang transaksinya juga ada di tabel. Namun, dengan menggabungkan NUM PROD dengan NUM
INVOICE, kita dapat mendefinisikan setiap transaksi secara unik karena tabel tidak akan pernah
memuat dua kemunculan nomor faktur dan nomor produk yang sama secara bersamaan.
Hapus Ketergantungan Parsial
Selanjutnya kita periksa untuk melihat apakah tabel yang dihasilkan mengandung ketergantungan
parsial. Ketergantungan parsialHaiterjadi ketika satu atau lebih atribut bukan kunci bergantung pada
(didefinisikan oleh) hanya sebagian dari kunci utama, bukan seluruh kunci. Hal ini hanya dapat terjadi
pada tabel yang memiliki kunci utama komposit (dua atau lebih atribut). Karena Tabel Faktur
Penjualan memiliki kunci utama atribut tunggal, kita dapat mengabaikannya pada langkah analisis ini.
Tabel ini sudah ada di 2NF. Namun, Tabel Item Baris perlu diperiksa lebih lanjut. Gambar 8.41
mengilustrasikan ketergantungan parsial di dalamnya.
Pada Tabel Item Baris, NUM INVOICE dan NUM PROD bersama-sama menentukan atribut
kuantitas terjual (Kuantitas). Namun jika kita berasumsi bahwa harga yang dikenakan untuk r234
adalah sama untuk semua pelanggan, maka atribut Harga Satuan berlaku umum untuk semua
transaksi yang melibatkan produk r234. Demikian pula, atribut Description umum untuk semua
transaksi tersebut. Kedua atribut ini tidak bergantung pada komponen Nomor Faktur dari kunci
komposit. Sebaliknya, mereka ditentukan oleh Prod Num dan, oleh karena itu, hanya sebagian, bukan
seluruhnya, bergantung pada kunci utama.
Kita mengatasinya dengan membagi tabel menjadi dua, seperti diilustrasikan pada Gambar 8.41.
Tabel Item Baris yang dihasilkan kini tersisa dengan satu atribut bukan kunci Qunty. Data deskripsi
produk dan harga satuan ditempatkan di tabel baru yang disebut Inventaris. Perhatikan bahwa tabel
Inventaris berisi atribut tambahan yang tidak berkaitan dengan tampilan pengguna ini. Tabel
inventaris tipikal mungkin berisi atribut seperti titik pemesanan ulang, jumlah yang tersedia, kode
pemasok, lokasi gudang, dan banyak lagi. Ini menunjukkan bagaimana satu tabel dapat digunakan
untuk mendukung banyak tampilan pengguna yang berbeda dan mengingatkan kita bahwa contoh
normalisasi ini hanya berkaitan dengan sebagian kecil dari keseluruhan database. Kami akan kembali
ke masalah ini nanti.
GAMBAR 8.41 Tabel yang Dihasilkan setelah Menghapus Ketergantungan Parsial
hal
Tabel Item Baris
Faktur Melecut Satuan

Keterangan Jumlah
Nomor Nomor Harga
Ketergantungan Parsial
hal
Faktur Melecut
Jumlah
hal
Nomor Nomor
Tabel Inventaris
Tabel Item Baris Melecut Satuan
Keterangan
Nomor Harga
Data lain yang bukan bagian dari tampilan pengguna ini
Pada titik ini, kedua tabel pada Gambar 8.41 berada dalam 3NF. Kunci utama Tabel Item
Baris (INVOICE NUM PROD NUM) sepenuhnya mendefinisikan atribut QUNTY. Demikian pula,
dalam Tabel Inventaris, atribut Deskripsi dan Harga Satuan seluruhnya ditentukan oleh kunci
utama PROD NUM.
Hapus Ketergantungan Transitif
Langkah terakhir dalam menyelesaikan ketergantungan struktural adalah menghilangkan ketergantungan

transitif. Ketergantungan transitifHaiterjadi pada tabel yang atribut bukan kuncinya bergantung pada atribut
bukan kunci lainnya dan tidak bergantung pada kunci utama tabel. Contohnya diilustrasikan pada Tabel
Faktur Penjualan pada Gambar 8.42. Kunci utama NUM INVOICE secara unik dan lengkap mendefinisikan
peristiwa ekonomi yang diwakili oleh atribut Tanggal Pemesanan, Tanggal Pengiriman, dan Pengiriman Via.
Namun kuncinya tidak secara unik mendefinisikan atribut pelanggan. Atribut Nama Cust, Alamat Jalan, dan
sebagainya, mendefinisikan suatu entitas (Pelanggan) yang independen terhadap transaksi spesifik yang
dicatat oleh catatan faktur tertentu. Misalnya, asumsikan bahwa selama periode tersebut perusahaan telah
menjual kepada pelanggan tertentu pada sepuluh kesempatan berbeda. Hal ini akan menghasilkan sepuluh
catatan faktur berbeda yang disimpan dalam tabel. Dengan menggunakan struktur tabel saat ini, masing-
masing catatan faktur ini akan menangkap data unik yang terkait dengan masing-masing transaksi beserta
data pelanggan yang umum untuk sepuluh transaksi. Oleh karena itu, kunci utama tidak secara unik
mendefinisikan atribut pelanggan dalam tabel. Memang benar, mereka tidak bergantung pada hal tersebut.
Kami mengatasi ketergantungan transitif ini dengan memisahkan data pelanggan dan
menempatkannya dalam tabel baru yang disebut Pelanggan. Kunci logis untuk tabel ini adalah CUST NUM,
yang merupakan atribut bukan kunci dalam tabel sebelumnya yang menjadi tempat bergantungnya atribut
pelanggan bukan kunci lainnya. Dengan teratasinya ketergantungan ini, Tabel Faktur Penjualan yang direvisi
dan Tabel Pelanggan baru berada dalam 3NF.
Menghubungkan Tabel yang Dinormalisasi
Pada titik ini, struktur tabel tunggal yang asli telah direduksi menjadi empat tabel yang dinormalisasi namun
independen yang disajikan pada Gambar 8.43. Tabel tersebut berisi data sampel yang digunakan dalam
struktur tabel tunggal asli yang disajikan pada Gambar 8.39. Perhatikan bagaimana datanya
GAMBAR 8.42 hal Tabel Faktur Penjualan
Tabel yang Dihasilkan Faktur Memesan spd spd Jalan Tele

Kota St
Bea Cukai Bea Cukai
Nomor Tanggal Tanggal Melalui Nomor Nama Alamat Nomor

setelah Menghapus
Transitif
Ketergantungan
Ketergantungan Transitif
Tabel Faktur Penjualan

Meja Pelanggan
hal hal
Jalan Tele
Faktur spd spd Kota St
Bea Cukai Bea Cukai
Memesan
Nomor Nama Alamat Nomor
Nomor Tanggal Tanggal Melalui
GAMBAR 8.43 Keterkaitan Antar Tabel yang Dinormalisasi
hal Meja Pelanggan
Jalan
Kota St
Bea Cukai Bea Cukai
Nomor Telp
Nomor Nama Alamat
1
hal Tabel Faktur Penjualan FK M 1765 Asosiasi ABC 132 Jalan Elm Betlehem PA 610-555-6721
1 Cu lainnya stomer Re kabel

Faktur Memesan spd spd Bea Cukai
Nomor Tanggal Tanggal Melalui Nomor
16459 22/09/07 27/09/07 UPS 1765
Inv lainnya Hai

es Rek Hai
rds
hal Tabel Inventaris

M 1 Melecut Satuan
Nomor
Keterangan
Harga Lainnya Data
hal
r234 Pemotong baut 42.50
FK Tabel Item Baris FK
m456 Penarik gigi 16.50
Faktur Melecut W62 tukang las listrik 485.00

Jumlah
M
Nomor Nomor
16459 r234 2 HAI

ada Penemu y Rekam S
16459 m456 1
16459 W62 1
Li lainnya Ne-Item R ekabel
redundansi dalam struktur tabel tunggal asli telah dihilangkan dari struktur lebih efisien yang
direpresentasikan di sini. Namun, untuk bekerja sama, tabel-tabel ini perlu dihubungkan
melalui kunci asing. Hal ini memerlukan terlebih dahulu penentuan kardinalitas (derajat
asosiasi) antara tabel-tabel dan kemudian penetapan kunci asing.
Tentukan Kardinalitas
Dalam contoh kita, kardinalitas antara keempat tabel adalah satu-ke-banyak (1:M), seperti yang
dijelaskan di bawah.
1.Setiap pelanggan (Tabel Pelanggan) dapat dikaitkan dengan satu atau banyak peristiwa penjualan (Tabel
Faktur Penjualan), namun setiap faktur ditujukan untuk satu pelanggan.
2.Setiap catatan Faktur Penjualan dikaitkan dengan satu atau lebih catatan Item Baris, namun setiap
Item Baris dikaitkan dengan hanya satu Faktur Penjualan.
3.Setiap catatan Inventaris dikaitkan dengan satu atau lebih Item Baris (produk tertentu telah
terjual berkali-kali ke banyak pelanggan) namun setiap catatan Item Baris hanya mewakili
satu item inventaris.
Tetapkan Kunci Asing

Aturan penetapan kunci asing dijelaskan secara rinci dalam bab ini. Saat menghubungkan dalam relasi
1:M seperti digambarkan pada Gambar 8.43, aturannya adalah mengambil kunci utama dari tabel di
sisi 1 relasi dan menanamkannya sebagai kunci asing di tabel sisi M. Perhatikan bahwa dalam
hubungan antara Tabel Item Baris, Tabel Faktur, dan Tabel Inventaris, hal ini sudah terjadi karena
kunci komposit Tabel Item Baris. Tabel Faktur Penjualan, bagaimanapun, perlu dimodifikasi untuk
memasukkan CUST NUM sebagai FOREIGN KEY, yang menghubungkannya ke Tabel Pelanggan.
Menghasilkan Tampilan Pengguna dari Tabel yang Dinormalisasi
Setelah tabel-tabel ini dibuat dalam DBMS, tabel-tabel tersebut akan diisi dengan data dari
beberapa sumber. Misalnya, layanan pelanggan akan menambahkan data pelanggan ke Tabel
Pelanggan, kontrol inventaris akan memasukkan nilai produk ke dalam Tabel Inventaris, dan
tabel Faktur Penjualan dan Item Baris akan diisi oleh data transaksi penjualan dari proses
Pesanan Penjualan. Langkah-langkah berikut menjelaskan bagaimana proses batch dapat
menghasilkan faktur sebenarnya.
1.Sebuah program komputer membaca Tabel Faktur Penjualan. Kami berasumsi bahwa catatan
pertama yang dibaca adalah nomor faktur 16459 (catatan sampel kami). Atribut rekaman
disimpan dalam memori.
2.Program kemudian membaca kunci asing CUST NUM dan mencari Tabel Pelanggan
untuk catatan dengan nilai kunci utama 1765. Atribut catatan pelanggan kemudian
disimpan dalam memori.
3.Program komputer kemudian membaca NUM INVOICE kunci utama dan mencari Tabel Item
Baris untuk semua kemunculan catatan yang Komponen NUM INVOICE kunci utama
memiliki nilai 16459. Program ini menemukan tiga catatan tersebut dan menyimpannya
dalam memori.
4.Program selanjutnya membaca Komponen PROD NUM dari tiga catatan Item Baris dan satu
per satu mencari File Inventaris untuk setiap kejadian. Atribut DESCRIPTION dan UNIT
PRICE dari setiap record yang terletak disimpan dalam memori.
5.Program kemudian menghitung Atribut EX PRICE untuk setiap item dan menjumlahkannya
untuk mendapatkan Atribut TOTAL DUE.
6.Pada titik ini, semua atribut yang diperlukan untuk menghasilkan tampilan pengguna asli ada di
memori. Mereka diformat dan dikirim untuk dicetak.
7.Komputer kemudian mengosongkan memori, membaca catatan berikutnya dari Tabel Faktur, dan
mengulangi langkah di atas hingga semua faktur telah diproses.
ISTILAH UTAMA
metode akses penunjuk kunci logis

ACL kejadian pengambilan sampel unit
anomali moneter (MUS).
kardinalitas organisasi
kunci komposit ketergantungan parsial
model data struktur penunjuk
struktur data alamat fisik
anomali penghapusan kunci utama
pembuat ekspresi modul audit pengambilan sampel rekaman
tertanam (EAM). grup berulang

Saring penunjuk alamat relatif
kunci asing bentuk normal struktur sekuensial bentuk
pertama (1NF). normal kedua (2NF).
struktur hashing perangkat lunak ketergantungan transitif
audit umum (GAS). bentuk normal ketiga (3NF).
file acak yang diindeks memperbarui anomali
struktur indeks file tampilan pengguna
sekuensial yang diindeks lihat integrasi

anomali penyisipan melihat pemodelan
daftar terbalik metode akses penyimpanan virtual (VSAM)
PERTANYAAN TINJAUAN
1. Apa saja dua komponen dasar struktur data? 11. Apa yang dimaksud dengan modul audit tertanam?
12. Jelaskan apa itu GAS dan mengapa GAS begitu populer
2. Apa saja kriteria yang mempengaruhi di kalangan kantor akuntan publik besar. Membahas
pemilihan struktur data? isu independensi terkait GAS.
3. Apa kelebihan dan kekurangan menggunakan 13. Diskusikan dan berikan contoh jenis-jenis
struktur data sekuensial? Berikan masing-masing perkumpulan berikut: (1:0,1), (1:1), (1:M), dan
contohnya. (M:M).
4. Apa kelebihan dan kekurangan 14. Bedakan antara asosiasi dan kardinalitas.
menggunakan struktur file acak terindeks? 15. Jelaskan cara kerja tabel penghubung terpisah dalam
Struktur file sekuensial yang diindeks? asosiasi banyak ke banyak.
5. Apa saja tiga komponen fisik file VSAM? 16. Apa empat karakteristik tabel database
Jelaskan bagaimana catatan dicari melalui relasional yang dirancang dengan baik?
komponen-komponen ini. 17. Apa yang dimaksud dengan fitur relasional membatasi, memproyeksikan, dan
6. Apa itu penunjuk? Diskusikan tiga jenis pointer menggabungkan?
yang umum digunakan dan manfaat relatifnya. 18. Bagaimana syarat bentuk normal ketiga
7. Apa saja keterbatasan model database (3NF)?
hierarki? 19. Jelaskan bagaimana perintah SELECT dan WHERE
8. Diskusikan dan berikan contoh asosiasi rekaman satu- membantu pengguna untuk melihat data yang
ke-satu, satu-ke-banyak, dan banyak-ke-banyak. diperlukan dari beberapa file database (tabel).
9. Mengapa model basis data hierarki dianggap 20. Apa yang dimaksud dengan model data?
sebagai basis data navigasi? 21. Bagaimana database yang dirancang dengan buruk dapat mengakibatkan
10. Jelaskan cara kerja file penghubung terpisah dalam hilangnya catatan penting secara tidak sengaja?
model jaringan. 22. Apa yang dimaksud dengan tampilan pengguna?
23. Apakah tampilan pengguna selalu memerlukan banyak tabel untuk 25. Dapatkah dua entitas berbeda memiliki atribut penentu yang
mendukungnya? Menjelaskan. sama? Menjelaskan.
24. Apa dua syarat yang harus dipenuhi oleh entitas yang sah?
PERTANYAAN DISKUSI
1. Jelaskan cara kerja struktur hashing dan mengapa struktur ini lebih 12. Jelaskan cara menghubungkan tabel dalam asosiasi 1:1.
cepat dibandingkan menggunakan indeks. Berikan contoh. Jika Mengapa hal ini mungkin berbeda dalam pengaitan 1:0,1?
jauh lebih cepat, mengapa tidak digunakan secara eksklusif? 13. Diskusikan implikasi akuntansi anomali pembaruan,
2. Jelaskan cara kerja modul audit tertanam dan mengapa penyisipan, dan penghapusan yang terkait dengan tabel
auditor dapat memilih untuk tidak menggunakannya. yang dinormalisasi secara tidak tepat.
3. Jelaskan istilah tersebutmodel data navigasi. 14. Berikan tiga contoh yang menggambarkan bagaimana kardinalitas
Bandingkan model hierarki dan model jaringan. mencerminkan aturan bisnis yang mendasari suatu organisasi.
4. Jelaskan tiga jenis anomali yang berhubungan 15. Jelaskan tiga jenis penunjuk berikut: penunjuk
dengan tabel database yang belum alamat fisik, penunjuk alamat relatif, dan
dinormalisasi. penunjuk kunci logis.
5. Bandingkan modul audit tertanam dengan perangkat 16. Jelaskan mengapa teknologi GAS populer di kalangan sebagian
lunak audit umum. besar auditor.
6. Jelaskan aplikasi akuntansi tertentu yang 17. Jelaskan risiko yang terkait dengan penggunaan GAS untuk
dapat menggunakan file VSAM. mengakses struktur file yang kompleks.
7. Jelaskan mengapa auditor harus memahami 18. Jelaskan tujuan fitur definisi file input ACL.
prinsip normalisasi data.
8. Apa perbedaan tampilan pengguna dengan tabel database? 19. Asumsikan bahwa seorang auditor sedang mereview suatu
9. Jelaskan apa yang dimaksud dengan istilah tersebutbentuk normal ketiga(3NF) berkas yang berisi dua puluh lima bidang data, hanya lima
artinya. bidang data yang relevan dengan tujuan auditor. Jelaskan
10. Mengapa tabel tautan terpisah diperlukan ketika bagaimana ACL dapat membantu dalam situasi ini.
asosiasi M:M keluar di antara tabel terkait? 20. Jelaskan tujuan kemampuan filter ACL.
11. Dalam lingkungan database relasional, catatan 21. Membedakan antara pengambilan sampel catatan dan
akuntansi tertentu (misalnya, jurnal, buku besar pengambilan sampel unit moneter (MUS).
pembantu, dan akun buku besar peristiwa) mungkin
tidak ada. Bagaimana ini mungkin?
SOAL PILIHAN GANDA

1. CIA 1186 III-33 C. berkas kumpulan.
Dalam sistem inventaris pada sistem manajemen D. berkas acak.

basis data, satu catatan yang disimpan berisi nomor 3. Sebaiknya menggunakan struktur file berurutan
bagian, nama bagian, warna bagian, dan berat ketika
bagian. Item individual ini disebut A. catatan dimasukkan secara rutin.
A. bidang. B. sebagian besar file akan diproses dalam
B. file yang disimpan. satu operasi.
C. byte. C. catatan perlu dipindai menggunakan kunci
D. kejadian. sekunder.
2. CIA 586 III-31 D. catatan tunggal perlu diambil.
Penggunaan pointer dapat menghemat waktu saat 4. Pernyataan manakah yang dimaksudbukanbenar?
memperbarui a A. Struktur file berurutan sesuai untuk

A. file induk. catatan penggajian.
B. sistem manajemen basis data. B. Keuntungan dari indeks sekuensial adalah
dapat dicari dengan cepat.
C. Metode akses sekuensial indeks melakukan C. itu tetap tidak berubah ketika disk
operasi penyisipan catatan secara efisien. diatur ulang.
D. Keuntungan utama dari struktur hashing D. semua hal di atas adalah keuntungan dari
adalah kecepatan akses. penunjuk alamat fisik.
5. Pernyataan berikut ini yang manakahbukanBENAR? 11. Pointer digunakan
A. File acak yang diindeks tersebar ke seluruh A. untuk menghubungkan catatan dalam file.
perangkat penyimpanan tanpa memperhatikan B. untuk menghubungkan catatan antar file.
kedekatan fisik dengan catatan terkait. C. untuk mengidentifikasi catatan yang disimpan dalam overflow.
B. File acak yang diindeks menggunakan ruang penyimpanan disk D. semua yang di atas.
secara efisien. 12. Dalam model hierarki,
C. File acak yang diindeks efisien saat A. hubungan antara catatan terkait bersifat implisit.
memproses sebagian besar file B. cara mengakses data adalah dengan mengikuti jalur data yang
sekaligus. telah ditentukan.
D. File acak yang diindeks mudah dipelihara dalam C. catatan pemilik (induk) hanya dapat memiliki satu
hal penambahan catatan. catatan anggota (anak).
6. Pernyataan yang manabukanbenar? Metode akses D. catatan anggota (anak) mungkin memiliki lebih dari satu
sekuensial yang diindeks pemilik (orang tua).
A. digunakan untuk file yang sangat besar yang memerlukan 13. Dalam model jaringan,
akses langsung dan pemrosesan batch. A. ada satu jalur yang telah ditentukan sebelumnya ke catatan
B. dapat menggunakan area luapan untuk catatan. tertentu.
C. memberikan alamat fisik yang tepat untuk setiap B. hubungan banyak-ke-banyak didukung dalam
catatan. jaringan sederhana.
D. cocok untuk file yang memerlukan sedikit C. manajemen dapat melacak dan melaporkan informasi
penyisipan atau penghapusan. berdasarkan satu kriteria saja.
7. Pernyataan manakah yang benar tentang struktur hashing? D. file tautan digunakan untuk menghubungkan catatan dalam file
A. Alamat yang sama dapat dihitung untuk dua yang berbeda.
catatan. 14. Istilah manakah yang dimaksudbukanterkait dengan model

B. Ruang penyimpanan digunakan secara efisien. database relasional?
C. Catatan tidak dapat diakses dengan cepat. A. tupel
D. Diperlukan indeks terpisah. B. atribut
8. Dalam struktur hashing, C. tabrakan
A. dua catatan dapat disimpan di alamat yang D. hubungan
sama. 15. Dalam model basis data relasional,
B. pointer digunakan untuk menunjukkan lokasi semua A. hubungan bersifat eksplisit.
catatan. B. pengguna merasakan bahwa file ditautkan
C. pointer digunakan untuk menunjukkan lokasi suatu menggunakan pointer.
record dengan alamat yang sama dengan record C. data direpresentasikan dalam tabel dua
lainnya. dimensi.
D. semua lokasi pada disk digunakan untuk penyimpanan D. data direpresentasikan sebagai struktur pohon.
rekaman. 16. Dalam model database relasional, semua pernyataan
9. Pointer dapat digunakan untuk semua hal berikut, berikut ini benar, kecuali
kecuali A. data disajikan kepada pengguna sebagai tabel.
A. untuk menemukan alamat subskema B. data dapat diekstraksi dari baris tertentu
rekaman. dari tabel tertentu.
B. untuk menemukan alamat fisik catatan. C. tabel baru dapat dibuat dengan menggabungkan dua tabel.
C. untuk menemukan alamat relatif dari catatan tersebut. D. hanya hubungan satu-ke-banyak yang dapat
D. untuk menemukan kunci logis dari catatan. didukung.
10. Keuntungan dari penunjuk alamat fisik adalah 17. Dalam database relasional,
A. itu menunjuk langsung ke lokasi penyimpanan disk yang A. pandangan pengguna terhadap database fisik
sebenarnya. sama dengan database fisik.
B. itu mudah dipulihkan jika hilang secara tidak B. pengguna merasa bahwa mereka memanipulasi
sengaja. satu tabel.
C. tabel virtual ada dalam bentuk baris dan B. adalah nama yang diberikan kepada salah satu dari tiga anomali
kolom tabel yang disimpan di disk. yang dihasilkan dari tabel database yang tidak dinormalisasi.
D. bahasa pemrograman (COBOL) digunakan untuk C. hanya bisa ada di tabel dengan kunci primer
membuat tampilan pengguna terhadap database. komposit.
18. Anomali pembaruan pada database yang tidak dinormalisasi D. tidak bisa ada di tabel yang dinormalisasi pada
A. terjadi karena redundansi data. level 2NF.
B. mempersulit penambahan catatan ke database. e. tidak ada satu pun di atas.
C. dapat mengakibatkan hilangnya data penting. 24. Ketergantungan parsial
D. sering mengakibatkan penyisipan catatan yang berlebihan. A. adalah hasil dari permintaan pengguna secara bersamaan
19. Masalah paling serius dengan database yang tidak untuk data yang sama dalam lingkungan database
dinormalisasi adalah yang dipartisi.
A. memperbarui anomali. B. adalah nama yang diberikan kepada salah satu dari tiga
B. anomali penyisipan. anomali yang dihasilkan dari tabel database yang tidak
C. anomali penghapusan. dinormalisasi.
D. bukan dari salah satu di atas. C. hanya bisa ada di tabel dengan kunci primer
20. Anomali penghapusan pada database yang tidak dinormalisasi komposit.
A. mudah dideteksi oleh pengguna. D. mungkin ada di tabel yang dinormalisasi pada
B. dapat mengakibatkan hilangnya data penting. level 2NF.
C. mempersulit penambahan catatan ke database. e. tidak ada satu pun di atas.
D. mengharuskan pengguna untuk melakukan pembaruan berlebihan. 25. Pengulangan data kelompok
21. Atribut data yang izin aksesnya dimiliki oleh A. adalah bentuk redundansi data yang umum terjadi pada
pengguna tertentu ditentukan oleh database yang direplikasi dalam lingkungan database
A. tampilan sistem operasi. terdistribusi.
B. tampilan desain sistem. B. adalah nama yang diberikan kepada salah satu dari tiga anomali
C. skema basis data. yang dihasilkan dari tabel database yang tidak dinormalisasi.
D. tampilan pengguna. C. hanya bisa ada di tabel dengan kunci primer
e. program aplikasi. komposit.
22. Entitas basis data D. tidak bisa ada di tabel yang dinormalisasi pada
A. mungkin berisi nol atau banyak kemunculan. level 2NF.
B. direpresentasikan sebagai kata kerja dalam diagram ER. e. tidak ada satu pun di atas.
C. dapat mewakili aset fisik dan fenomena 26. Model database yang paling mungkin digunakan dalam
tidak berwujud. pengembangan sistem modern (bukan legacy) adalah a.
D. sering kali ditentukan oleh atribut umum yang juga hierarkis.
mendefinisikan entitas lain. B. tersusun.
e. unik untuk tampilan pengguna tertentu. C. relasional.
23. Ketergantungan transitif D. jaringan.
A. adalah kondisi database yang diselesaikan melalui e. navigasi.
perangkat lunak pemantauan khusus.
MASALAH
1. Metode Akses A. Ambil catatan dari file berdasarkan nilai kunci
Untuk setiap operasi pemrosesan file berikut, tunjukkan utamanya.
apakah file sekuensial, file acak terindeks, metode akses B. Perbarui catatan dalam file.
sekuensial terindeks (VSAM), hashing, atau struktur penunjuk C. Baca file catatan lengkap.
berfungsi paling baik. Anda dapat memilih sebanyak yang D. Temukan catatan berikutnya dalam sebuah file.
Anda inginkan untuk setiap langkah. Tunjukkan juga mana e. Masukkan catatan ke dalam file.
yang kinerjanya paling tidak optimal. F. Hapus catatan dari file.

G. Pindai file untuk mencari rekaman dengan kunci sekunder.
2. Organisasi File berapa rata-rata jumlah record yang harus dicari?

Untuk situasi berikut, tunjukkan jenis organisasi file
yang paling sesuai. Jelaskan pilihan Anda.
A. Sebuah perusahaan utilitas lokal memiliki 80.000 pelanggan
INDEKS PERMUKAAN
perumahan dan 10.000 pelanggan komersial. Tagihan
INDEKS SILINDER SILINDER
bulanan bervariasi sepanjang bulan, sehingga penerimaan
kas cukup seragam sepanjang bulan. Untuk 99 persen dari
Kunci Silinder Kunci Permukaan
seluruh rekening, satu cek per bulan diterima. Tanda
Jangkauan Nomor Jangkauan Nomor
terima ini dicatat dalam file batch, dan catatan akun
pelanggan diperbarui setiap dua minggu. Pada bulan- 2.000 44 12.250 0
bulan biasa, permintaan pelanggan diterima sekitar dua 4.000 45 12.500 1
puluh per hari.
6.000 46 12.750 2
B. Agen kartu kredit nasional memiliki 12 juta rekening
pelanggan. Rata-rata, 30 juta pembelian dan 700.000 8.000 47 13.000 3
kwitansi pembayaran diproses setiap hari. Selain itu, 10.000 48 13.250 4
hotline dukungan pelanggan memberikan informasi
12.000 49 13.500 5
kepada sekitar 150.000 pemegang kartu kredit dan
30.000 pedagang per hari. 14.000 50 14.750 6
C. Sistem reservasi maskapai penerbangan mengasumsikan 16.000 51 15.000 7
bahwa pelancong mengetahui kota keberangkatan. Sejak
18.000 52
saat itu, tarif dan waktu penerbangan diperiksa
berdasarkan tujuannya. Setelah penerbangan 20.000 53
diidentifikasi dapat diterima oleh pelancong,
ketersediaannya diperiksa dan, jika perlu, kursi dipesan.
Volume transaksi melebihi satu setengah juta per hari. 5. Algoritma Hashing
D. Sebuah sistem perpustakaan menyimpan lebih dari 2 juta Pemrogram sistem menggunakan algoritma hashing
buku dan memiliki 30.000 pelanggan. Setiap pengunjung untuk menentukan alamat penyimpanan. Struktur
diperbolehkan membaca lima buku. Rata-rata, ada 1,3 hashingnya adalah 9.997/kunci. Nomor yang dihasilkan
eksemplar setiap judul di perpustakaan. Lebih dari 3.000 kemudian digunakan untuk menemukan catatan. Dua
buku diperiksa setiap hari, dengan jumlah pengembalian digit pertama setelah koma melambangkan nomor
yang kira-kira sama setiap hari. Check-out akan segera silinder, sedangkan dua digit kedua melambangkan
diposting, begitu pula pengembalian buku yang sudah nomor permukaan. Digit kelima, keenam, dan ketujuh
lewat jatuh tempo oleh pelanggan yang ingin membayar setelah koma mewakili nomor rekor. Algoritme ini
denda. menghasilkan alamat unik sebanyak 99 persen. Apa yang
terjadi pada sisa waktu ketika hasil algoritma tidak unik?
3. Bahasa Kueri Terstruktur Jelaskan secara detail proses penyimpanan ketika Key=3
Wakil presiden bidang keuangan telah memperhatikan penuaan diproses terlebih dahulu, Key=2307 di kemudian hari, dan
piutang usaha bahwa jumlah piutang yang telah jatuh tempo jauh segera setelahnya Key=39.
lebih tinggi dari yang diperkirakan. Dia ingin menyelidiki masalah
ini. Untuk melakukannya, ia memerlukan laporan rekening yang 6. Normalisasi Data
telah jatuh tempo yang berisi atribut-atribut yang ditunjukkan Di halaman berikutnya adalah tabel data perpustakaan. Normalisasikan
pada paruh atas tabel Soal 3 di halaman berikutnya. Setengah data ini ke dalam bentuk normal ketiga, persiapkan untuk digunakan
bagian bawah tabel berisi kolom data dan file yang relevan dalam dalam lingkungan database relasional. Komputer perpustakaan
sistem database relasional. Lebih lanjut, dia ingin memperingatkan diprogram untuk menghitung tanggal jatuh tempo 14 hari setelah
tenaga penjualan jika ada pelanggan yang tidak membayar tanggal check-out. Dokumentasikan langkah-langkah yang diperlukan
tagihan mereka tepat waktu. Dengan menggunakan perintah SQL untuk menormalkan data serupa dengan prosedur yang ditemukan
yang diberikan dalam bab ini, tulis kode yang diperlukan untuk dalam bab ini. Tambahkan kunci asing dan tunjukkan bagaimana
menghasilkan laporan rekening yang telah jatuh tempo lebih dari database terkait.
$5.000 dan jatuh tempo lebih dari 30 hari. Setiap pelanggan
memiliki tenaga penjualan yang ditugaskan.
7. Normalisasi Data
Pada halaman 388 terdapat tabel data praktik dokter hewan.
4. Metode Akses Penyimpanan Virtual Normalisasikan data ini ke dalam bentuk normal ketiga,
Dengan menggunakan indeks yang disediakan, jelaskan, langkah demi persiapkan untuk digunakan dalam lingkungan database
langkah, bagaimana Kunci 12987 akan ditemukan menggunakan metode akses relasional. Tunjukkan kunci utama dan kunci asing yang tertanam
penyimpanan virtual. Setelah permukaan pada silinder ditemukan, dalam tabel.
Masalah 3: Bahasa Kueri Terstruktur
Atribut Laporan
Nama Penjual, Kantor Cabang Penjual, Nomor Pelanggan, Nama Pelanggan, Jumlah Tunggakan, Tanggal Pembelian Terakhir,
Barang Dikirim?, Jumlah Pesanan Penjualan Terakhir, Jumlah Pembayaran Terakhir, Tanggal Pembayaran Terakhir
FILE TERSEDIA:
Tabel Tenaga Penjual Meja Pelanggan Tabel Pesanan Penjualan
Nama Penjual Nomor pelanggan Nomor Pesanan Penjualan
Nomor Penjual Nama Pelanggan Nomor pelanggan
Tarif Komisi Alamat Pelanggan 1 Tanggal pemesanan
Pangkat Alamat Pelanggan 2 Jumlah
Cabang Nomor Penjual Tanggal pengiriman
Tanggal menyewa Nomor Pesanan Penjualan Terakhir
Pembelian Tahun ke Tanggal
Saldo rekening
Saldo Tertunggak
Jumlah Pembayaran Terakhir
Tanggal Pembayaran Terakhir
Masalah 6: Normalisasi Data
Murid Murid Murid Nomor Buku

PENGENAL Pertama Terakhir Buku Panggilan Buku Tanggal Jatuh tempo
Nomor Nama Nama Keluar TIDAK Judul Keluar Tanggal
678-98-4567 Amy Tukang roti 3 hf351.j6 Longsoran salju 02-09-04 16-09-04
678-98-4567 Amy Tukang roti 4 hf878.k3 Tornado 02-09-04 16-09-04
244-23-2348 Ramesh Memisahkan 1 i835.123 Politik 02-09-04 16-09-04
398-34-8793 Yakobus Talley 3 k987.d98 Olahraga 02-09-04 16-09-04
398-34-8793 Yakobus Talley 4 d879.39 Hak Hukum 02-09-04 16-09-04
678-98-4567 Amy Tukang roti 4 hal987.t87 Gempa bumi 03-09-04 17-09-04
244-23-2348 Ramesh Memisahkan 1 q875.i76 Pahlawan Masa Lalu 03-09-04 17-09-04
8. Normalisasi Data faktur ke file audit untuk proses konfirmasi

Siapkan tabel dasar, dalam bentuk normal ketiga, yang diperlukan untuk piutang. Anda segera khawatir bahwa akun
menghasilkan tampilan pengguna pada halaman 389. piutang usaha mungkin terlalu dilebih-lebihkan
pada tahun ini dan tahun-tahun sebelumnya di
9. Normalisasi Data mana EAM ini digunakan.
Siapkan tabel dasar, dalam bentuk normal ketiga, yang diperlukan untuk
menghasilkan tampilan pengguna pada halaman 389. Diperlukan:
Jelaskan mengapa Anda khawatir karena semua faktur “materi”
10. Identifikasi Paparan dan Rencana Aksi merupakan kandidat untuk konfirmasi oleh pelanggan. Buat garis
Sebagai manajer tim audit eksternal, Anda menyadari besar rencana untuk menentukan apakah piutang usaha dilebih-
bahwa modul audit tertanam hanya menulis “materi” lebihkan.
11. Perangkat Lunak Audit Umum
Mengenakan biaya
CMA 1290 4-Y7
9.00
9.00
15.00
25.00
20.00
15.00
25.00
17.00
Departemen audit internal Perusahaan Manufaktur Sachem
sedang mempertimbangkan untuk membeli perangkat lunak
komputer yang akan membantu proses audit. Sistem kendali
Keterangan
Kandang – sedang
Kandang – sedang
Pembersihan Telinga
Melayani
keuangan dan manufaktur Sachem sepenuhnya otomatis
Pemeriksaan Darah II
Tembakan Rabies
Tembakan Rabies
pada komputer mainframe besar. Melinda Robinson, direktur
Celupan Kutu
Celupan Kutu
audit internal, percaya bahwa Sachem harus memperoleh
perangkat lunak audit komputer untuk membantu audit
keuangan dan prosedur yang dilakukan departemennya. Jenis
Melayani
paket perangkat lunak yang dipertimbangkan Robinson
Kode
238
148
337
238
500
500
148
368
dijelaskan di bawah ini.
• Paket perangkat lunak audit umum yang membantu
Keterangan
Jenis anjing Golden Retriever

pekerjaan audit dasar, seperti pengambilan data
Anjing-campuran
langsung dari file komputer berukuran besar.
Satwa
Departemen akan meninjau informasi ini menggunakan
Dalmasi
Dalmasi
Dalmasi
Dalmasi
teknik investigasi audit konvensional. Lebih khusus lagi,
departemen dapat melakukan pemilihan kriteria,
pengambilan sampel, perhitungan dasar untuk analisis
Kode
kuantitatif, penanganan catatan, analisis grafis, dan
Satwa
hari
hari
hari
hari
MX
GR
GR
GR
pencetakan keluaran (konfirmasi).
• Paket fasilitas pengujian terintegrasi yang menggunakan,
memantau, dan mengendalikan data pengujian dummy
01/04/05
01/04/05
01/04/05
01/09/05
01/09/05
24/01/05
02/01/05
02/02/05
Tanggal
melalui program yang ada dan memeriksa keberadaan dan

kecukupan pengendalian entri data program dan
pengendalian pemrosesan.
• Paket diagram alur kendali yang menyediakan presentasi
Houston, Texas
Houston, Texas
Houston, Texas
Houston, Texas
Houston, Texas
Houston, Texas
Houston, Texas
Alamat 2
grafis dari aliran data informasi melalui suatu sistem,
Sproley, TX
yang menunjukkan dengan tepat kekuatan dan
kelemahan kendali.
• Paket simulasi dan pemodelan program (paralel) yang
menggunakan data aktual untuk melakukan proses
Alamat 1
sistematis yang sama dengan menggunakan program logika

23 Jalan Elm
23 Jalan Elm
23 Jalan Elm
8 Jalan Oak
8 Jalan Oak
8 Jalan Oak
8 Jalan Oak
komputer berbeda yang dikembangkan oleh auditor. Paket Jalan Udara 3
ini juga dapat digunakan untuk mencari jawaban atas

permasalahan audit yang sulit (melibatkan banyak
Pemilik
perbandingan dan perhitungan) dalam batas kepercayaan

Nama
Pertama
George
Elaine
Elaine
Elaine
yang dapat diterima secara statistik.

Toni
Toni
Toni
Toni
Diperlukan:
Pemilik
Nama
Caciolo
Caciolo
Caciolo
Caciolo
Penyihir
Penyihir
Penyihir
A. Tanpa memperhatikan perangkat lunak audit komputer

Terakhir
Jetson
tertentu, jelaskan kepada auditor internal keuntungan umum

menggunakan perangkat lunak audit komputer untuk
membantu audit.
PENGENAL
Pemilik
penyihir
penyihir
penyihir
Nama Nomor
Cacil
Cacil
Cacil
Cacil
B. Jelaskan tujuan audit yang difasilitasi dan langkah-langkah prosedural

Jetsl
yang harus diikuti oleh auditor internal untuk menggunakan a(n)
Saya. paket perangkat lunak audit umum.

Sabar
Astro
ii. paket fasilitas pengujian terpadu.

Pesolek
Pesolek
Pesolek
Liugi
Luigi
Luigi
Luigi
aku aku aku. paket diagram alur kontrol.

iv. paket simulasi dan pemodelan program (paralel).
PENGENAL
Nomor
Sabar
417
417
417
632
632
632
632
168
TAMPILAN PENGGUNA
Susun ulang Satuan Yang Mulia
Bagian# Keterangan QOH Titik EOQ Biaya Yang # Nama Yang Mulia Alamat Telp
132 Baut 100 50 1000 1,50 987 ABC Co. 654 Jalan Elm 555 5498
143 Baut 59 10 100 1.75 987 ABC Co. 654 Jalan Elm 555 5498
760 Kacang 80 20 500 2.00 742 XYZ Co. 510 Pukulan 555 8921
982 Paku 100 50 800 1,00 987 ABC Co. 654 Jalan Elm 555 5498
TAMPILAN PENGGUNA
Susun ulang Satuan Yang Mulia
Bagian# Keterangan QOH Titik EOQ Biaya Yang # Nama Yang Mulia Alamat Telp
132 Baut 100 50 1000 1,50 987 ABC Co. 654 Jalan Elm 555 5498
1.55 750 RST Co. 3415 Jalan ke-8 555 3421
1.45 742 XYZ Co. 510 Pukulan 555 8921
982 Paku 100 50 800 1,00 987 ABC Co. 654 Jalan Elm 555 5498
1.10 742 XYZ Co. 510 Pukulan 555 8921
1,00 549 LMN Co. 18 Jalan Oak. 555 9987
12. Identifikasi Paparan dan Rencana Aksi 14. Normalisasi Data—Pesanan Pembelian
Dua tahun lalu sebuah perusahaan audit eksternal Acme Plywood Company menggunakan pesanan pembelian yang
mengawasi pemrograman modul audit tertanam ditunjukkan pada diagram untuk Soal 14.
untuk Perusahaan Peralatan Kantor Previts. Selama Aturan bisnis puncak:
proses audit tahun ini, auditor eksternal meminta agar
1.Setiap vendor mungkin memasok banyak item; suatu barang
log transaksi seluruh transaksi disalin ke file audit.
dipasok hanya oleh satu vendor.
Auditor eksternal melihat kesenjangan besar dalam
2.Pesanan pembelian mungkin mencantumkan banyak item; suatu item
tanggal dan waktu transaksi disalin ke file audit. Ketika
mungkin terdaftar di banyak pesanan pembelian.
mereka menanyakan hal ini, mereka diberitahu bahwa
peningkatan pemrosesan transaksi telah membebani 3.Seorang karyawan dapat menyelesaikan beberapa pesanan
sistem mainframe dan bahwa operator sering kali pembelian, namun hanya satu karyawan yang dapat mengisi
harus mematikan EAM agar pemrosesan transaksi PO individu.
penting dapat dilakukan tepat waktu. Selain itu, Siapkan tabel dasar 3FN yang diperlukan untuk menghasilkan pesanan
banyak pemeliharaan telah dilakukan selama setahun pembelian ini.
terakhir pada program aplikasi.
15. Tautan Tabel
Diperlukan: Selesaikan masalah ini sesuai teks dalam diagram
Uraikan potensi eksposur dan tentukan tindakan yang untuk Soal 15.
harus diambil oleh auditor eksternal untuk
melanjutkan. 16. Mendefinisikan Entitas dan Pemodelan Data—
Penggajian
13. Normalisasi Data Karyawan di Perusahaan Manufaktur Sagerod
Siapkan tabel dasar 3NF yang diperlukan untuk menghasilkan tampilan mencatat jam kerja mereka pada kartu waktu kertas
laporan penjualan seperti yang ditunjukkan pada diagram untuk Soal 13. yang dimasukkan ke dalam mesin jam waktu di awal
Soal 13: Normalisasi Data
Laporan penjualan
Nomor pelanggan:19321
Nama Pelanggan :Jon Smith
Alamat :520 Jalan Utama, Kota
Nomor Faktur Tanggal Jumlah Faktur Bagian Nomor Kuantitas Harga satuan Harga Ext
12390 11/11/09 $850 2 5 $20 $100
1 10 50 500
3 25 10 250
12912 21/11/09 $300 4 10 $30 $300
Jumlah Pelanggan: $1.150
*** ********************** *
Nomor pelanggan :19322

Nama Pelanggan :Maria Smith
Alamat :2289 Elm St., Kota
Nomor Faktur Tanggal Jumlah Faktur Bagian Nomor Kuantitas Harga satuan Harga Ext
12421 13/11/09 $1.000 6 10 $20 $200
1 2 50 100
5 7 100 700
12901 20/11/09 $500 4 10 $30 $300

2 10 20 200
Jumlah Pelanggan: $1.500
*** ********************** *
Pelanggan Berikutnya
Pelanggan Berikutnya
dan akhir setiap shift. Pada hari Jumat, supervisor mengumpulkan Petugas menyiapkan ringkasan penggajian, yang dikirimkan
kartu absensi, meninjau dan menandatanganinya, dan bersama gaji ke petugas pengeluaran kas. Petugas meninjau
mengirimkannya ke petugas penggajian. Petugas menghitung gaji gajiringkasan, memperbarui jurnal pengeluaran kas untuk
setiap karyawan dan memperbarui file pendapatan karyawan. Hal mencatat total penggajian, dan menyiapkan cek untuk total
ini melibatkan penambahan catatan baru untuk setiap karyawan penggajian, yang disimpan ke dalam akun penggajian
dalam periode pembayaran yang mencerminkan gaji kotor imprest. Petugas kemudian menandatangani gaji dan
karyawan, pengurangan pajak, dan pemotongan lainnya untuk membagikannya kepada karyawan.
periode tersebut. Petugas kemudian menyiapkan gaji untuk setiap
karyawan dan mencatatnya dalam daftar cek. Daftar cek dan gaji Diperlukan:
terkait mencerminkan pendapatan bersih setiap karyawan untuk Asumsikan bahwa sistem manual ini akan diotomatisasi
periode tersebut. Berdasarkan catatan tersebut, menggunakan sistem database relasional. Lakukan tugas berikut.
Soal 14: Normalisasi Data
Pesanan Pembelian
Acme Kayu Lapis Co. PO#
1234 Jalan Barat. Tanggal: __/__/__
Di suatu tempat, OH 00000
Penjual: __________________________________________________
________________________________________________________________
______________________________________
Pengiriman Via: __________________ Silakan mengacu pada nomor PO ini pada semua korespondensi.
Disiapkan oleh: _______________________________________________
Barang # Keterangan Kuantitas Biaya Perpanjangan
Anda mungkin perlu membuat asumsi tentang bagaimana dikembalikan ke pemasok dan diganti dengan produk
aktivitas otomatis tertentu akan dilakukan. yang lebih sukses. Perwakilan penjualan menyiapkan
A. Cantumkan semua calon entitas dalam prosedur yang dijelaskan. salinan daftar permintaan pembelian dan bertemu
B. Identifikasi entitas yang valid dan jelaskan mengapa entitas dengan manajer pembelian di masing-masing lokasi
yang ditolak tidak boleh dimodelkan. toko. Bersama-sama, perwakilan penjualan dan
C. Buat model data dari proses yang menunjukkan manajer pembelian membuat pesanan pembelian
asosiasi entitas. yang menjelaskan produk, kuantitas, dan tanggal
pengiriman.
17. Mendefinisikan Entitas dan Pemodelan Data
2.Pada tanggal pengiriman yang diinginkan, Toko Kelontong
—Prosedur Pembelian Safe Buy menerima barang dari pemasok. Barang yang
Aturan bisnis yang membentuk sistem pembelian untuk diterima diturunkan dari truk pengantar dan disimpan di
jaringan Toko Kelontong Safe Buy serupa di semua lokasi rak dan dipajang oleh karyawan paruh waktu.
toko. Manajer pembelian di setiap lokasi bertanggung jawab
3.Personel bongkar muat membuat laporan penerimaan.
untuk memilih pemasok lokalnya. Jika manajer membutuhkan
Setiap hari ringkasan laporan penerimaan disiapkan dan
suatu produk, dia memilih pemasok. Setiap toko mengikuti
dikirim ke manajer pembelian untuk ditinjau.
langkah-langkah yang dijelaskan di sini.
4.Pemasok kemudian menyerahkan faktur kepada petugas
1.Fungsi pembelian dimulai dengan perwakilan penjualan dari departemen AP, yang membuat catatan faktur. Petugas
pemasok secara berkala mengamati rak dan pajangan di setiap merekonsiliasi faktur dengan laporan penerimaan dan
lokasi dan mengenali kebutuhan untuk mengisi kembali pesanan pembelian dan kemudian menciptakan kewajiban
persediaan. Persediaan menurun karena penjualan langsung pembayaran yang harus dibayar di masa depan,
ke pelanggan atau karena pembusukan barang yang mudah tergantung pada ketentuan perdagangan.
rusak. Selain itu, perwakilan penjualan pemasok meninjau 5.Pada tanggal jatuh tempo, cek secara otomatis
laporan keusangan yang disiapkan oleh manajer pembelian. disiapkan dan dikirim ke pemasok, dan
Laporan-laporan ini mengidentifikasi produk-produk yang pembayarannya dicatat dalam daftar cek. Pada
perputarannya lambat dan ketinggalan jaman yang dianggap akhir setiap hari, ringkasan pembayaran dikirim ke
tidak dapat dijual di lokasi tertentu. Produk-produk ini manajer pembelian untuk ditinjau.
Soal 15: Penautan Tabel
Beberapa tabel terkait dengan kunci utama (PK) ditunjukkan di bawah ini. Tempatkan kunci asing dalam tabel untuk
menghubungkannya sesuai dengan asosiasi yang ditunjukkan (misalnya, 1:M dan M:M). Buat tabel baru yang mungkin
diperlukan.
Pelanggan Pramuniaga
Meja Meja
(PK) (PK)
Pelanggan Pramuniaga
Nomor Nomor
1 1 1
Penerimaan Tunai Order penjualan Inventaris
Meja M MMeja M Meja
(PK) (PK) (PK)

Rek Tunai Faktur M 1 Bagian
Tidak Nomor Nomor
Pemasok
Meja M
(PK)
Penjual
Nomor
Diperlukan: aset tetap dan untuk memilih vendor. Lemari es, lemari
Asumsikan bahwa sistem manual yang dijelaskan akan es, mobil pengantaran, dan rak toko adalah contoh
diotomatisasi menggunakan sistem database relasional. Lakukan pembelian aset tetap. Setelah kebutuhan diidentifikasi,
tugas berikut. Anda mungkin perlu membuat asumsi tentang setiap toko mengikuti prosedur yang dijelaskan
bagaimana aktivitas otomatis tertentu akan dilakukan. selanjutnya.
A. Cantumkan semua calon entitas dalam prosedur yang dijelaskan. Manajer membuat pesanan pembelian, yang dikirim ke
B. Identifikasi entitas yang valid dan jelaskan mengapa entitas pemasok. Pemasok menyerahkan aset kepada petugas
yang ditolak tidak boleh dimodelkan. penerima, yang menyiapkan laporan penerimaan. Setiap
C. Buat model data dari proses yang menunjukkan minggu petugas departemen aset tetap meninjau ringkasan
asosiasi entitas. laporan penerimaan aset tetap dan membuat catatan
D. Buat model yang diatribusikan sepenuhnya dengan menambahkan inventaris aset tetap untuk setiap penerimaan. Petugas aset
kunci utama, kunci asing, dan atribut data. Normalisasikan tetap memelihara catatan inventaris dan jadwal penyusutan.
modelnya. Vendor kemudian menyerahkan faktur ke petugas
departemen AP, yang membuat catatan faktur. Petugas
18. Mendefinisikan Entitas dan Pemodelan Data— merekonsiliasi faktur dengan laporan penerimaan dan
Prosedur Aset Tetap pesanan pembelian dan kemudian menciptakan kewajiban
Aturan bisnis yang membentuk prosedur aset tetap pembayaran yang harus dibayar di masa depan, tergantung
untuk jaringan Toko Kelontong Safe Buy serupa di pada ketentuan perdagangan. Pada tanggal jatuh tempo, cek
semua lokasi toko. Manajer toko di setiap lokasi secara otomatis disiapkan dan dikirim ke vendor, dan
bertanggung jawab untuk mengidentifikasi kebutuhan pembayarannya dicatat dalam daftar cek. Pada akhir
setiap hari, ringkasan pembayaran dikirim ke manajer AP salinan bill of lading. BOL dan slip pengepakan dikirim
untuk ditinjau. bersama produk ke pengangkut. Petugas kemudian
mengajukan pelepasan stok di departemen.
Diperlukan:
Asumsikan bahwa sistem manual yang dijelaskan akan Prosedur Penerimaan Kas
diotomatisasi menggunakan sistem database relasional. Ruang surat memiliki lima karyawan yang membuka surat
Lakukan tugas berikut. Anda mungkin perlu membuat dan menyortir cek dari bagian pengiriman uang. Saran
asumsi tentang bagaimana aktivitas otomatis tertentu pengiriman uang dikirim ke departemen akuntansi di
akan dilakukan. mana petugas akuntansi memperbarui buku besar
A. Cantumkan semua calon entitas dalam prosedur yang dijelaskan. pembantu pelanggan untuk mencerminkan pengurangan
B. Identifikasi entitas yang valid dan jelaskan mengapa entitas piutang. Pada akhir hari, petugas menyiapkan laporan
yang ditolak tidak boleh dimodelkan. keuangan dan mengirimkannya ke departemen buku
C. Buat model data dari proses yang menunjukkan besar untuk diposting.
asosiasi entitas. Petugas ruang surat mengirimkan cek ke departemen
D. Buat model yang diatribusikan sepenuhnya dengan menambahkan penerimaan kas, di mana petugas mengesahkan setiap cek
kunci utama, kunci asing, dan atribut data. Normalisasikan dengan tulisan “Hanya Untuk Deposit”. Selanjutnya petugas
modelnya. mencatat penerimaan kas pada jurnal penerimaan kas.
Terakhir, petugas menyiapkan slip setoran dan
19. Mendefinisikan Entitas dan Pemodelan Data—Prosedur
mengirimkannya beserta ceknya ke bank.
Pesanan Penjualan
Diperlukan:
Prosedur Penjualan Asumsikan bahwa sistem manual yang dijelaskan akan
Perusahaan Importir Teh Teratai Pelanggan melakukan diotomatisasi menggunakan sistem database relasional.
pemesanan dengan perwakilan penjualan melalui telepon atau Lakukan tugas berikut. Anda mungkin perlu membuat
faks. Karyawan departemen penjualan kemudian menyalin asumsi tentang bagaimana aktivitas otomatis tertentu
pesanan pelanggan ke dalam format pesanan penjualan standar akan dilakukan.
dan menghasilkan dokumen-dokumen berikut: tiga salinan A. Cantumkan semua calon entitas dalam prosedur yang dijelaskan.
pesanan penjualan, dokumen pelepasan stok, pemberitahuan B. Identifikasi entitas yang valid dan jelaskan mengapa entitas
pengiriman, dan slip pengepakan. Departemen akuntansi yang ditolak tidak boleh dimodelkan.
menerima salinan pesanan penjualan, gudang menerima C. Buat model data dari proses yang menunjukkan
pelepasan stok dan salinan pesanan penjualan, dan departemen asosiasi entitas.
pengiriman menerima pemberitahuan pengiriman dan slip D. Buat model yang diatribusikan sepenuhnya dengan menambahkan
pengepakan. Petugas penjualan mengarsipkan salinan pesanan kunci utama, kunci asing, dan atribut data. Normalisasikan
penjualan ke departemen. modelnya.
Setelah menerima pesanan penjualan, petugas
departemen akuntansi menyiapkan faktur pelanggan dengan 20. Mendefinisikan Entitas dan Pemodelan Data
menambahkan harga ke pesanan penjualan, yang —Aturan Bisnis
diperolehnya dari daftar harga resmi. Dia kemudian Berdasarkan aturan bisnis berikut, buatlah diagram ER
mengirimkan faktur ke pelanggan. Dengan menggunakan sehingga setiap aturan diambil untuk database. Anggaplah
data dari pesanan penjualan, petugas kemudian mencatat setiap aturan harus diperlakukan secara individual. Buatlah
penjualan tersebut di jurnal penjualan dan di buku besar diagram ER untuk setiap aturan.
pembantu AR. Pada akhir hari, petugas menyiapkan voucher A. Perusahaan penjualan eceran menyiapkan pesanan penjualan untuk
jurnal penjualan, yang dikirim ke departemen buku besar pembelian pelanggannya. Seorang pelanggan dapat melakukan
untuk diposting ke akun penjualan dan kontrol AR. banyak pembelian, namun pesanan penjualan ditulis untuk satu
Gudang menerima salinan pesanan penjualan dan pelanggan.
dokumen pengeluaran stok. Seorang karyawan gudang B. Perusahaan penjualan ritel memesan inventaris
mengambil produk dan mengirimkannya ke departemen menggunakan pesanan pembelian. Suatu item inventaris
pengiriman bersama dengan dokumen pengeluaran stok. dapat dipesan berkali-kali, dan pesanan pembelian dapat
Petugas gudang kemudian memperbarui catatan inventaris dibuat untuk lebih dari satu item inventaris.
untuk mencerminkan pengurangan persediaan yang ada. C. Perusahaan yang menjual mobil antik menyiapkan pesanan penjualan
Pada akhir hari, petugas menyiapkan ringkasan akun untuk setiap mobil yang terjual. Persediaan untuk perusahaan ini
persediaan dalam bentuk cetak dan mengirimkannya ke terdiri dari mobil unik, dan hanya satu dari mobil tersebut yang
departemen buku besar untuk diposting ke akun boleh dicantumkan dalam pesanan penjualan.
pengendalian persediaan dan harga pokok penjualan. D. Sebuah toko kelontong mengidentifikasi pelanggan yang
Setelah menerima dokumen pengeluaran stok dari kembali melalui kartu plastik yang dipindai petugas pada saat
gudang, petugas pengiriman menyiapkan keduanya setiap pembelian. Tujuan dari kartu ini adalah untuk melacak
inventaris dan untuk memelihara database pelanggan masalah di masa lalu dengan pemasok mereka. Di sisi lain,
dan pembelian mereka. Jelasnya, pelanggan dapat perusahaan ini menghadapi masalah kelebihan persediaan,
membeli barang dalam jumlah tidak terbatas dari toko kehabisan stok, dan ketidaksesuaian dengan catatan
kelontong. Item unik hanya berdasarkan kode UPC, persediaan.
dan setiap kode UPC dapat dikaitkan dengan banyak
Siklus Pendapatan
pelanggan berbeda.
Menjadi anggota D&F Music Club melibatkan menelepon
e. Toko persewaan video secara unik mengidentifikasi setiap item
nomor bebas pulsa dan berbicara dengan perwakilan
inventarisnya sehingga pelanggan dapat menyewa film dan
penjualan, yang membuat akun pelanggan baru. Catatan
mengembalikan film tersebut melalui drop box, dan toko
akun pelanggan berisi nama, alamat, nomor telepon,
dapat mengidentifikasi salinan film mana yang disewa dan
pesanan sebelumnya yang dia buat dengan perusahaan,
dikembalikan. Pelanggan diperbolehkan menyewa hingga
dan nomor akun pelanggan unik yang ditetapkan secara
enam film sekaligus, namun salinan film hanya dapat disewa
berurutan.
oleh satu pelanggan dalam satu waktu.
Pelanggan melakukan pemesanan melalui telepon dengan
21. Kasus Komprehensif perwakilan penjualan, yang menyiapkan catatan pesanan penjualan.
(Disiapkan oleh Katie Daley dan Gail Freeston, Universitas John, di departemen penagihan, meninjau pesanan penjualan,
Lehigh) menambahkan harga dan biaya pengiriman, dan mencetak salinan
D&F adalah distributor CD dan kaset yang menawarkan (faktur) yang dikirimkan ke pelanggan. John kemudian menambahkan
keuntungan seperti harga diskon dan penawaran perkenalan catatan ke jurnal penjualan untuk mencatat penjualan.
sepuluh CD atau kaset seharga satu sen (tidak termasuk biaya Chris, seorang pegawai gudang, memverifikasi informasi
pengiriman dan penanganan). Target pelanggan utamanya adalah pada pesanan penjualan, mengambil barang, mencetak slip
mahasiswa; strategi pemasaran utamanya adalah penawaran pengepakan, dan memperbarui buku besar pembantu
terus-menerus kepada anggota klub. Pesaing utama perusahaan inventaris. Chris menyiapkan bill of lading untuk pengangkut.
dalam industri ini adalah BMG dan Columbia House; keduanya Barang kemudian dikirim.
menawarkan promosi serupa. Sandy di AR memperbarui akun pelanggan dan akun
D&F dimulai pada tahun 1993 dengan kantor di Harrisburg, kontrol buku besar. Ketika pelanggan melakukan pembayaran
Pennsylvania, awalnya menargetkan mahasiswa di daerah secara rekening, mereka mengirimkan saran pengiriman
sekitarnya. Perusahaan menyadari adanya permintaan yang tinggi uang (yang dilampirkan pada faktur) dan cek dengan nomor
terhadap merchandise musik dengan potongan harga dan rekening mereka di atasnya. Scott, petugas ruang surat,
kemudahan pengiriman surat di universitas. Setelah tahun kedua, membuka semua kwitansi tunai. Dia memisahkan cek dan
dengan peningkatan pesanan pelanggan yang konstan, D&F saran pengiriman uang dan menyiapkan daftar pengiriman
pindah ke Philadelphia, yang lokasinya dekat dengan lebih banyak uang, yang, bersama dengan cek, dikirim ke departemen
perguruan tinggi dan universitas. Langkah ini berdampak positif penerimaan kas.
pada laba bersih dan permintaan, mendukung keputusan untuk Laura, petugas penerimaan kas, merekonsiliasi cek
melanjutkan pertumbuhan perusahaan. D&F baru-baru ini dengan pengiriman uang, memperbarui rekening pelanggan
memperluas fasilitasnya untuk dapat memenuhi permintaan yang dan buku besar, dan kemudian menyetorkan cek tersebut ke
lebih tinggi atas layanannya. Basis pelanggannya berkisar dari bank. Dia mengirimkan slip setoran ke Sandy di departemen
wilayah yang dekat dengan Universitas Villanova hingga Boston akuntansi.
College. Pada tahun 2007, terdapat 103 karyawan. Penjualan kotor Setelah menerima tanda terima bank, Sandy
tahun sebelumnya adalah $125 juta. mengarsipkannya dan memperbarui jurnal penerimaan kas
untuk mencatat jumlah yang disetor. Setelah menerima CD
Pangsa pasar D&F sedang meningkat, namun belum atau kaset yang dipesan, pelanggan memiliki masa uji coba
sebanding dengan besarnya BMG dan Columbia House. selama 15 hari. Jika pada akhir jangka waktu itu dia
Namun, tujuan perusahaan untuk tahun-tahun mendatang mengirimkan pembayaran, maka dianggap barang telah
termasuk menjadikan dirinya sebagai pemain industri melalui diterima. Sebaliknya, jika pelanggan tidak puas dengan
peningkatan kepuasan dan loyalitas pelanggan. D&F juga produk karena alasan apa pun, dia dapat mengembalikannya
mempertimbangkan pemasangan sistem pemrosesan ke D&F Music Club tanpa biaya. Namun untuk mengembalikan
informasi baru. Sistem ini akan merekayasa ulang fungsi CD atau kaset tersebut, pelanggan harus menghubungi
bisnis mereka saat ini dengan mengurangi celah dalam perusahaan untuk mendapatkan nomor otorisasi. Ketika
masalah pengendalian internal mereka. barang tiba, Chris menyiapkan catatan pengembalian dan
D&F menerima CD dan kaset dari berbagai pemasok grosir dan memperbarui buku besar pembantu inventaris. Salinan cetak
jaringan toko musik, yang berjumlah 32 pemasok di seluruh negeri. catatan pengembalian dikirim ke John dan Sandy. John
Kantor tersebut mempunyai gudang sendiri, menyimpan barang meninjau catatan pengembalian dan memperbarui jurnal
dagangannya sendiri, dan bertanggung jawab untuk mengisi kembali penjualan. Sandy mengkredit rekening pelanggan dan
persediaan. D&F tidak memiliki dampak yang substansial memperbarui buku besar untuk membalikkan transaksi.
Siklus Pengeluaran Pada tanggal jatuh tempo, Evan, petugas pengeluaran

Sistem pembelian dan sistem pengeluaran tunai kas, menutup catatan AP, memotong cek, dan
terdiri dari siklus pengeluaran D&F Music Club. Tiga mengirimkannya ke pemasok. Dia kemudian memperbarui
departemen dalam sistem pembelian adalah gudang, daftar cek dan buku besar.
pembelian, dan akuntansi. Fungsi pembelian dimulai
Diperlukan:
di gudang, yang menyimpan persediaan CD dan kaset.
Asumsikan bahwa sistem manual yang dijelaskan akan
Jim, manajer gudang, membandingkan catatan
diotomatisasi menggunakan sistem database relasional. Lakukan
inventaris dengan berbagai perkiraan permintaan
tugas berikut. Anda mungkin perlu membuat asumsi tentang
setiap minggu, yang disediakan oleh tim analis riset
bagaimana aktivitas otomatis tertentu akan dilakukan.
pasar, untuk menentukan pesanan yang perlu dibuat.
A. Cantumkan semua calon entitas dalam prosedur yang dijelaskan.
Pada akhir minggu, Jim menyiapkan catatan daftar
B. Identifikasi entitas yang valid dan jelaskan mengapa entitas
permintaan pembelian.
yang ditolak tidak boleh dimodelkan.
Sara, petugas pembelian, meninjau daftar
C. Buat model data dari proses yang menunjukkan
permintaan pembelian, memilih pemasok, dan
asosiasi entitas.
menyiapkan pesanan pembelian. Salinan pesanan
D. Buat model yang diatribusikan sepenuhnya dengan menambahkan
pembelian dikirim ke pemasok dan bagian akuntansi.
kunci utama, kunci asing, dan atribut data. Normalisasikan
Ketika kiriman tiba, Chris, petugas gudang, yang bekerja
modelnya.
dari salinan buta pesanan pembelian, menghitung dan
e. Siapkan diagram aliran data sistem yang menunjukkan
memeriksa barang apakah ada kerusakan. Dia kemudian
penyimpanan data.
menyiapkan laporan penerimaan dan memperbarui catatan
inventaris.
Setelah menerima faktur pemasok, Diana, petugas 22. Latihan ACL—Ikhtisar ACL
akuntansi, membandingkannya dengan pesanan pembelian dan Muat edisi pelajar ACL ke
laporan penerimaan masing-masing. Jika faktur akurat, Diana komputer Anda dan unduh
membuat catatan AP, menetapkan tanggal jatuh tempo Panduan Memulai ACL (ACLSstart.pdf). Baca
pembayaran, dan memperbarui akun buku besar. manualnya dan selesaikan latihannya.

Ebook Audit SI CHPTR 8 (Id)

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ebook Audit SI CHPTR 8 (Id)

Diunggah oleh

Hak Cipta:

Format Tersedia

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

• Menentukan nilai persediaan yang benar.

Struktur File Datar

GAMBAR 8.1 Penyimpanan Berurutan dan Metode Akses

Catatan Dibaca Secara Berurutan

Kunci Kunci Kunci

Kunci Berurutan (dalam

GAMBAR 8.2 Struktur File Acak Terindeks

Perangkat Penyimpanan Disk Fisik

Nilai Kunci Catatan

1956 97, 14, 128

5521 06, 10, 501 1956

1124 125, 02, 16

1872 200, 12, 350 1124

2130 04, 06, 87

GAMBAR 8.3 VSAM Digunakan untuk Akses Langsung

VSAM – Metode Akses Penyimpanan Virtual

Mencari Kunci 2546

Indeks Silinder Indeks Permukaan

Kunci silinder Kunci Permukaan

3300 99 2500 2 tidak memiliki

GAMBAR 8.4 Memasukkan Catatan ke dalam File VSAM

Kunci 223 Kunci 224 Kunci 225

Kunci 226 Kunci 228 Kunci 229

Kunci 231 Kunci 233 Kunci 234

Kunci 235 Kunci 238 Kunci 239 Meluap

Kunci 269 Kunci 270

Masukkan Record Baru dengan Nilai Kunci = 237

Nilai Kunci yang Dicari

File Daftar Tertaut

Rekor Pertama dalam Daftar

Penunjuk untuk Merekam 125 Rekor Terakhir dalam Daftar

GAMBAR 8.7 Pointer di dalam dan di antara File

Penunjuk ke Catatan Saran Pengiriman Uang Penunjuk ke Rekaman Berikutnya

Penunjuk ke Catatan Faktur Penjualan

Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya

Saran Pengiriman Uang Pertama

Penunjuk ke Rekaman Berikutnya Penunjuk ke Rekaman Berikutnya

GAMBAR 8.8 Jenis Pointer

Penunjuk Alamat Fisik

Penunjuk Alamat Relatif

135 Rekor pertama

Penunjuk Kunci Logis

Kunci hashing Catatan

Struktur Basis Data Hirarki dan Jaringan

GAMBAR 8.9 File Tautan dalam Hubungan Banyak-ke-Banyak

Menemukan # Menemukan # Menemukan #

1356 1730 2512

Tautan Vendor Tautan Vendor

Tautan Inventaris Tautan Inventaris

Tautan Inventaris Tautan Inventaris Tautan Vendor

Tautan Vendor Tautan Vendor

Penjual #1 Penjual #2 Penjual #3

GAMBAR 8.10 File Sekuensial Terindeks

Indeks Jumlah Kosong Meja Karyawan Indeks Pendapatan YTD

Kunci Catatan Em Keahlian YTD Kunci

101 1 101 L.Smith 15 Jalan Utama. 891 15000 20.000 3

Struktur, Konsep, dan Terminologi Basis Data Relasional

Teori Basis Data Relasional

1.Mewakili data dalam bentuk tabel dua dimensi.

Ketiga fungsi aljabar tersebut dijelaskan di bawah ini:

GAMBAR 8.11 Fungsi Aljabar Relasional Membatasi, Memproyeksikan, dan Menggabungkan

(a) Batasi (b) Proyek