Anda di halaman 1dari 27

Data Structures and CAATTs for Data Extraction

Tugas Mata Kuliah


Auditing EDP

Oleh :
Anisa Tus Saidah 150810301008
Alifiera Putri Afifah 150810301028
Diah Wahyuni 150810301131
Putri Qutsiyah Sari 150810301155

Program Studi S1 Akuntansi


Fakultas Ekonomi dan Bisnis
Universitas Jember
2018
PENDAHULUAN

Makalah ini membahas tentang struktur data yang mana ini berguna bagi
auditor khususnya dalam rangka meneliti lebih lanjut lagi apakah struktur data yang
dimiliki oleh suatu perusahaan memang mencerminkan data yang sebenarnya atau
justru dimodifikasi sedemikian rupa sehingga kecurangan sekecil apa pun bisa
disembunyikan. Di bab ini juga membahas mengenai CAATTs untuk perangkat lunak
ekstraksi data serta menjelaskan mengenai fitur, keunggulan, dan ketidaksesuaian
pendekatan modul audit tersemat (EAM) yang mana menguraikan fungsi khas dan
penggunaan perangkat lunak audit umum. Untuk struktur datanya sendiri memiliki dua
komponen dasar sebagai acuan dalam data yang dimiliki perusahaan.

PEMBAHASAN

STRUKTUR DATA
Struktur data memiliki dua komponen dasar: organisasi dan metode akses.
Organisasi mengacu pada cara catatan yang diatur secara fisik pada perangkat
penyimpanan sekunder. Sedangkan metode akses mengacu pada teknik yang
digunakan untuk mencari catatan dan menavigasi melalui database atau file.
Sementara beberapa teknik khusus digunakan secara umum, mereka dapat
diklasifikasikan sebagai akses langsung atau metode akses berurutan.
Dalam pengoperasian pengolahan File terdiri dari :
1. Ambil catatan dari file berdasarkan kunci primernya.
2. Masukkan catatan ke dalam file
3. Perbarui rekaman dalam file.
4. Baca file catatan lengkap
5. Temukan catatan selanjutnya dalam file
6. Pindai file untuk catatan dengan kunci sekunder umum
7. Hapus catatan dari file

Struktur File Datar


Dari Bab 4 mengenai model flat-file menggambarkan lingkungan di mana file
data individual tidak terintegrasi dengan file lain. Pengguna akhir di lingkungan ini
memiliki file data mereka daripada membagikannya dengan pengguna lain.
Pengolahan data demikian per dibentuk oleh aplikasi mandiri daripada sistem

2
terintegrasi. Pendekatan flat-file adalah model tampilan tunggal yang menjadi ciri
sistem warisan. File data terstruktur, format ted, dan diatur agar sesuai dengan
kebutuhan spesifik dari pemilik atau pengguna utama. Penataan demikian,
bagaimanapun, dapat menghilangkan atau merusak atribut data yang penting bagi
pengguna lain, sehingga mencegah integrasi sistem yang sukses di seluruh organisasi
 Struktur Berurutan
Struktur sekuensial, yang biasanya disebut metode akses sekuensial. Sekuensial
sederhana dan mudah untuk diproses. Aplikasi dimulai di awal file dan memproses
setiap catatan secara berurutan. Contoh dari ini adalah proses penggajian, di mana
100 persen catatan karyawan pada file penggajian diproses setiap periode penggajian.
Namun, ketika hanya sebagian kecil dari file (atau saya catatan tunggal) sedang
diproses, pendekatan ini tidak efisien.
 Struktur Terindeks
Struktur yang diindeks dinamakan demikian karena di samping file data aktual,
terdapat indeks terpisah yang merupakan file catatan alamat. Indeks ini berisi nilai
numerik dari lokasi penyimpanan disk fisik (silinder, permukaan, dan blok rekaman)
untuk setiap catatan dalam file data terkait. File data itu sendiri dapat diatur secara
berurutan atau secara acak. Rekaman dalam file acak yang diindeks akan tersebar di
seluruh disk tanpa memperhatikan kedekatan fisiknya dengan rekaman terkait lainnya.
Bahkan, catatan milik file yang sama dapat berada pada disk yang berbeda. Lokasi
fisik catatan tidak penting selama perangkat lunak sistem operasi dapat
menemukannya saat diperlukan. Lokasi ini diakomodasi dengan mencari indeks untuk
nilai kunci yang diinginkan, membaca lokasi penyimpanan yang sesuai (alamat), dan
kemudian memindahkan kepala baca-tulis disk ke lokasi alamat. Ketika catatan baru
ditambahkan ke file, perangkat lunak manajemen data memilih lokasi disk kosong,
menyimpan catatan, dan menambahkan alamat baru ke indeks.
Organisasi fisik dari indeks itu sendiri mungkin berurutan (berdasarkan nilai
kunci) atau acak. Indeks acak lebih mudah untuk dipelihara, dalam hal penambahan
catatan, karena catatan kunci baru hanya ditambahkan ke akhir indeks tanpa
memperhatikan Indeks mereka secara berurutan lebih sulit untuk dipertahankan
karena kunci rekaman baru harus disisipkan di antara yang ada. kunci. Salah satu
keuntungan dari indeks sekuensial adalah bahwa ia dapat dicari dengan cepat. Karena
pengaturannya 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.

3
Struktur akses Virtual Storage (VSAM) digunakan untuk file yang sangat besar
yang memerlukan pemrosesan batch rutin dan tingkat moderat dari proses rekaman
individual. Sebagai contoh, file pelanggan dari perusahaan utilitas publik akan diproses
dalam mode batch untuk tujuan penagihan dan langsung diakses sebagai tanggapan
terhadap permintaan pelanggan individu. Karena organisasi sekuensial, struktur VSAM
dapat dicari secara berurutan untuk pemrosesan batch yang efisien.
 Struktur Hashing
Struktur hashing menggunakan algoritme yang mengubah kunci primer dari rekaman
secara langsung menjadi alamat penyimpanan. Hashing menghilangkan kebutuhan
akan indeks terpisah. Dengan menghitung alamat, daripada membacanya darii indeks,
catatan dapat diambil lebih cepat. Contohnya adalah dengan mengasumsikan file
inventaris dengan 100.000 item inventaris. Algoritma membagi jumlah persediaan
(kunci primer) menjadi bilangan prima. Ingat bahwa bilangan prima adalah yang dapat
dibagi hanya dengan sendirinya dan saya tanpa meninggalkan nilai sisa. Oleh karena
itu, perhitungan akan selalu menghasilkan nilai yang dapat diterjemahkan ke dalam
lokasi penyimpanan. Oleh karena itu, residual 6.27215705 menjadi Cylinder 272,
Surface 15, dan Record number 705. Struktur hashing menggunakan organisasi file
acak karena proses menghitung residu dan mengubahnya menjadi lokasi
penyimpanan menghasilkan alamat rekaman yang tersebar luas.
Keuntungan utama hashing adalah kecepatan akses. Menghitung alamat
rekaman lebih cepat daripada mencarinya melalui indeks. Struktur ini cocok untuk
aplikasi yang membutuhkan akses cepat ke catatan individu dalam melakukan Operasi
1, 2, 3, dan 6. Struktur hashing memiliki dua kerugian yang signifikan. Pertama, teknik
ini tidak menggunakan ruang penyimpanan secara efisien. Lokasi penyimpanan yang
dipilih untuk suatu catatan adalah fungsi matematis dari nilai kunci primernya.
Algoritme tidak akan pernah memilih beberapa lokasi disk karena mereka tidak sesuai
dengan nilai kunci yang sah. Sebanyak sepertiga dari paket disk mungkin terbuang.
Kerugian kedua adalah kebalikan dari yang pertama. Kunci rekaman yang berbeda
dapat menghasilkan residu yang sama (atau serupa), yang diterjemahkan ke dalam
alamat yang sama. Ini disebut tabrakan karena dua catatan tidak dapat disimpan di
lokasi yang sama. Salah satu solusi untuk masalah ini adalah secara acak memilih
lokasi untuk rekaman kedua dan menempatkan pointer ke itu dari lokasi pertama (yang
dihitung).
 Pointer Structures

4
Pendekatan ini menyimpan dalam bidang satu catatan alamat (pointer) dari catatan
terkait. Catatan dalam jenis file ini tersebar di seluruh disk tanpa memperhatikan
kedekatan fisik mereka dengan catatan terkait lainnya. Pointer menyediakan koneksi
antar record. Dalam contoh ini, Rekam 124 poin ke lokasi Rekam 125, Rekam 125 poin
ke 126, dan seterusnya. Catatan terakhir dalam daftar berisi penanda.
 Struktur Database Hirarkis dan Jaringan
Pada awal ini menggunakan teknik flat-file sebelumnya serta struktur database
kepemilikan baru. Perbedaan utama antara kedua pendekatan tersebut adalah tingkat
integrasi proses dan pembagian 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,
sementara memungkinkan organisasi untuk pindah ke tingkat baru integrasi data.
Dengan menyediakan hubungan antara file-file yang terkait secara logis, dimensi
ketiga (kedalaman) ditambahkan untuk melayani kebutuhan banyak pengguna dengan
lebih baik.
Struktur Basis Data Relasional, Konsep, dan Terminologi
Bagian berikut memeriksa prinsip-prinsip yang mendasari model database relasional
dan teknik, aturan, dan prosedur untuk membuat tabel relasional. Anda juga akan
melihat bagaimana tabel dihubungkan ke tabel lain untuk memungkinkan representasi
data yang kompleks. Database relasional didasarkan pada struktur file berurutan di
indeks.
 Teori Relasional Database
E.F. Codd awalnya mengusulkan prinsip-prinsip model relasional pada akhir 1960-an.
Model formal memiliki fondasinya dalam aljabar relasional dan teori himpunan, yang
memberikan dasar teoritis untuk sebagian besar operasi manipulasi data yang
digunakan. Dengan demikian, suatu sistem bersifat relasional jika:
1). Mewakili data dalam bentuk tabel dua dimensi.
2). Mendukung fungsi aljabar relasional pembatasan, proyek, dan bergabung.
Ketiga fungsi aljabar dijelaskan di bawah ini:
Batasi: ekstrak baris yang ditentukan dari tabel yang ditentukan.
Proyek: ekstrak atribut tertentu (kolom) dari tabel untuk membuat tabel virtual.
Bergabung: buat tabel fisik baru dari dua tabel yang terdiri dari semua pasangan baris
yang bersambung, dari masing-masing tabel.

5
Meskipun membatasi, proyek, dan bergabung bukanlah fungsi relasional yang lengkap,
itu adalah bagian yang berguna yang memenuhi sebagian besar kebutuhan informasi
bisnis.

Konsep Database Relasional


Pada bagian ini, kami meninjau konsep dasar, terminology, dan teknik umum untuk
sistem database relasional.
 Entitas, Kejadian, dan Atribut
Entitas adalah sesuatu yang ingin organisasi ambil untuk menangkap data. Entitas
dapat berupa fisik, seperti persediaan, pelanggan, atau karyawan. Mereka mungkin
juga konseptual, seperti penjualan (kepada pelanggan), piutang dagang (AR), atau
hutang dagang (AP). Representasi grafis yang digunakan untuk menggambarkan
model disebut diagram entitas hubungan (ER). Sebagai masalah konvensi, setiap
entitas dalam model data dinamai dalam bentuk nomina tunggal, seperti “Pelanggan
dan bukan Pelanggan”. Istilah kejadian digunakan untuk menggambarkan jumlah
contoh atau catatan yang berhubungan dengan entitas tertentu. Sebagai contoh, jika
suatu organisasi memiliki 100 karyawan, entitas karyawan dikatakan terdiri dari 100
kejadian. Atribut adalah elemen data yang mendefinisikan entitas. Misalnya, entitas
pegawai dapat ditentukan oleh set atribut parsial berikut: Nama, Alamat, Kemampuan
Kerja, Masa Kerja, dan Tarif per Jam Bayar setiap kejadian dalam entitas karyawan
terdiri dari jenis atribut yang sama tetapi nilai dari masing-masing atribut akan
bervariasi di antara kejadian-kejadian karena atribut adalah karakteristik yang logis dan
relevan dari suatu entitas, mereka unik untuk itu. 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 hubungan di antara mereka. Asosiasi ini diwakili dengan kata kerja, seperti
kapal, permintaan, atau diterima. Kardinalitas adalah derajat hubungan antara dua
entitas. Secara sederhana menyatakan, kardinalitas menjelaskan jumlah kemungkinan
kejadian dalam satu tabel yang terkait dengan satu kejadian dalam tabel terkait. Empat
bentuk dasar kardinalitas adalah 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
merepresentasikan asosiasi logis antar entitas. Nilai dari contoh, kardinalitas (0,1)
pada satu ujung dan kardinalitas (1,M).

6
Contoh 1 (1,1). Asumsikan bahwa perusahaan memiliki 1.000 karyawan tetapi hanya
100 dari mereka adalah staf penjualan. Asumsikan juga bahwa setiap penjual diberi
nomor mobil perusahaan, tetapi staf non-penjualan tidak. Saat menentukan nilai
kardinalitas dalam asosiasi entitas, pilih satu kejadian (catatan) dari satu entitas dan
jawab pertanyaan berikut: berapa jumlah minimum dan maksimum catatan yang
mungkin terkait dengan satu catatan yang telah dipilih? Misalnya, memilih catatan
entitas karyawan dan melihat ke arah entitas perusahaan mobil, kita melihat dua
kemungkinan nilai. Jika catatan karyawan yang dipilih adalah dari seorang tenaga
penjualan, maka dia ditugaskan satu (dan hanya satu) mobil perusahaan. Catatan
karyawan tertentu ini, terkait dengan hanya satu catatan dalam entitas perusahaan
mobil. Namun, jika catatan karyawan yang dipilih adalah catatan seorang non-
penjualan, maka individu tersebut akan diberi no (nol) mobil. Catatan karyawan dalam
kasus ini dikaitkan dengan nol catatan perusahaan mobil. Jadi, kardinalitas minimum
nol dan kardinalitas maksimum adalah satu. Lingkaran dan garis pendek yang
memotong garis yang menghubungkan dua entitas menggambarkan tingkat
kardinalitas ini. Perhatikan bahwa dari perspektif entitas karyawan, kardinalitas
ditunjukkan pada akhir Perusahaan Mobil dari garis asosiasi. Sekarang pilih catatan
Perusahaan Mobil dan lihat kembali entitas karyawan karena setiap mobil perusahaan
ditugaskan hanya untuk satu karyawan, baik jumlah minimum dan maksimum dari
catatan terkait adalah satu. Dua garis berpotongan pendek di bagian akhir karyawan
dari garis asosiasi menandakan kardinalitas ini.
Contoh 2 (1:1). Contoh 2 mengilustrasikan situasi dimana setiap catatan dalam satu
entitas selalu dikaitkan dengan satu (dan hanya satu) catatan dalam entitas terkait.
Dalam hal ini setiap komputer laptop perusahaan ditugaskan hanya untuk satu
manajer, dan setiap manajer hanya diberi satu komputer. Dua garis pendek yang
memotong garis penghubung di kedua ujungnya menggambarkan kardinalitas ini.
Contoh 3 (1:M). Contoh 3 menyajikan hubungan antara pelanggan dan entitas order
penjualan. Perhatikan bahwa jumlah minimum catatan order penjualan per catatan
pelanggan adalah nol dan maksimumnya banyak. Hal ini karena dalam periode
tertentu (satu tahun atau bulan) yang terkait dengan entitas order penjualan,
pelanggan tertentu mungkin tidak membeli apa pun (nol catatan order penjualan) atau
membeli beberapa kali (banyak catatan). Namun, dari perspektif entitas order
penjualan, setiap catatan dikaitkan dengan satu dan hanya satu pelanggan. Simbol
kaki burung gagak (yang memberikan bentuk notasi ini namanya) menggambarkan
banyak kardinalitas pada akhir urutan penjualan dari garis asosiasi.

7
Contoh 4 (1:M). Contoh 4 mewakili suatu situasi dimana setiap item spesifik
persediaan dipasok oleh satu dan hanya satu Vendor, dan setiap Vendor memasok
satu atau banyak persediaan yang berbeda kepada perusahaan. Bandingkan
hubungan (1:M) ini dengan contoh 5 berikutnya.
Contoh 5 (M:M). Untuk mengilustrasikan asosiasi banyak-ke-banyak, kami kembali
menggunakan hubungan Vendor dan Inventaris dalam contoh 5. Kali ini,
bagaimanapun, perusahaan memiliki kebijakan untuk membeli jenis inventaris yang
sama dari beberapa pemasok. Manajemen dapat memilih untuk melakukan ini untuk
memastikan bahwa mereka mendapatkan harga terbaik atau menghindari
ketergantungan pada pemasok tunggal. Di bawah kebijakan tersebut, setiap catatan
Vendor terkait dengan satu atau banyak catatan Inventaris, dan setiap catatan
Inventaris terkait dengan satu atau banyak Vendor. Contoh 4 dan 5 menunjukkan
bagaimana kardinalitas mencerminkan aturan bisnis yang ada dalam suatu organisasi.
Perancang database harus mendapatkan pemahaman menyeluruh tentang bagaimana
klien-perusahaan dan pengguna tertentu melakukan bisnis untk mendesain model data
dengan tepat. Jika model data salah, tabel basis data yang dihasilkan juga akan salah.
Contoh 4 dan 5 keduanya sah, tetapi opsi yang berbeda dan, seperti yang akan kita
lihat, memerlukan desain basis data yang berbeda.
Pemberitahuan Kardinalitas Alternatif. Metode alternatif adalah menulis nilai-nilai
kardinalitas pada setiap ujung garis asosiasi yang menghubungkan kedua entitas,
beberapa perancang basis data secara eksplisit menunjukkan nilai-nilai kardinalitas
atas dan bawah. Beberapa memilih versi tulisan cepat yang hanya mencatat
kardinalitas atas. Untuk pekerjaan rumah, instruktur anda akan memberi tahu anda
tentang metode yang disukai untuk digunakan.

 Tabel Fisik Database


Tabel basis data fisik dibangun dari model data dengan setiap entitas dalam model
yang diubah menjadi tabel fisik terpisah. Di bagian atas setiap tabel adalah atribut yang
membentuk kolom. Memotong kolom untuk membentuk baris tabel adalah tuple.
Sebuah tuple, yang memberikan definisi yang tepat ketika pertama kali diperkenalkan,
mirip dengan catatan dalam sistem file datar. Sesuai dengan konvensi, kami akan
menggunakan istilah catatan atau kejadian daripada tupel. Tabel yang dirancang
dengan benar memiliki empat karakteristik berikut:
1. Nilai setidaknya satu atribut dalam setiap kejadian (baris) harus unik. Atribut ini
adalah kunci utama. Nilai atribut (non key) lainnya di baris tidak harus unik.
2. Semua nilai atribut dalam kolom apa pun harus dari kelas yang sama.

8
3. Setiap kolom dalam tabel tertentu harus diberi nama yang unik. Namun, tabel
yang berbeda dapat berisi kolom dengan nama yang sama.
4. Tabel harus sesuai dengan aturan normalisasi. Ini berarti mereka harus bebas
dari ketergantungan structural termasuk kelompok berulang, dependensi
parsial, dan dependensi transitif (lihat appendix bab ini untuk diskusi lengkap).

 Kaitan antara Tabel Relasional


Tabel yang terkait secara logis perlu terhubung secara fisik untuk mencapai asosiasi
yang dijelaskan dalam model data.
 Tampilan Pengguna
Tampilan pengguna adalah kumpulan data yang dilihat oleh pengguna tertentu. Contoh
pandangan pengguna adalah layar komputer untuk memasukkan atau melihat data,
laporan manajemen, atau dokumen sumber seperti faktur. Tampilan mungkin digital
atau fisik (kertas), tetapi dalam semua kasus, mereka berasal dari tabel database yang
mendasari. Pandangan sederhana dapat dibangun dari satu tabel, sementara
pandangan yang lebih kompleks mungkin memerlukan beberapa tabel. Selanjutnya,
satu tabel dapat menyumbangkan data ke banyak pandangan yang berbeda.
Organisasi besar akan memiliki ribuan tampilan pengguna yang didukung oleh ribuan
tabel individual. Tugas mengidentifikasi semua pandangan dan menerjemahkannya ke
dalam tabel yang dinormalisasi adalah tanggung jawab yang penting dari perancang
basis data yang memiliki implikasi kontrol internal. Masalah dan teknik yang terkait
dengan tugas ini diperiksa selanjutnya.

Anomali, Dependensi Struktural, dan Normalisasi Data


Bagian ini membahas mengapa tabel database yang perlu dinormalisasi.
 Anomali Database
Jawaban atas pertanyaan di atas adalah tabel yang dinormalisasi dengan tidak
semestinya dapat menyebabkan masalah pemrosesan DBMS yang membatasi, atau
bahkan menolak pengguna mengakses informasi yang mereka butuhkan. Satu atau
lebih dari anomali ini akan ada dalam tabel yang tidak dinormalisasi atau dinormalisasi
pada tingkat rendah, seperti bentuk normal pertama (INF) atau bentuk normal kedua
(2NF). Agar bebas dari anomali, tabel harus dinormalisasi ke tingkat normal ketiga
(3NF).

9
Perbarui Anomali. Anomali pembaruan hasil dari redundansi data dalam tabel yang
tidak dikenali. Untuk lebih menghargai implikasi dari anomali pembaruan,
pertimbangkan situasi yang lebih realistis.
Penyisipan Anomali. Untuk menunjukkan efek anomali penyisipan, asumsikan bahwa
vendor baru telah memasuki pasar dan organisasi belum membeli dari vendor tetapi
mungkin ingin melakukannya di masa depan.
Penghapusan Anomali. Penghapusan anomali melibatkan penghapusan data yang
tidak disengaja dari tabel. Kehadiran anomali penghapusan kurang mencolok, tetapi
berpotensi lebih serius daripada pembaruan dan penyisipan anomali.
 Normalisasi Tabel
Anomali database yang dijelaskan diatas adalah gejala masalah structural dalam tabel
yang disebut dependensi. Secara khusus ini dikenal sebagai kelompok berulang,
dependensi parsial, dan dependensi transitif. Proses normalisasi melibatkan identifikasi
dan penghapusan dependensi struktural dari tabel yang sedang dikaji. Tabel yang
dihasilkan kemudian akan memenuhi dua kondisi:
1. Semua atribut nonkunci (data) dalam tabel bergantung pada (ditentukan oleh)
kunci primer.
2. Semua atribut non-key tidak bergantung pada atribut non-key lainnya.
Dengan kata lain tabel 3NF adalah tabel di mana kunci utama dari tabel sepenuhnya
dan secara unik mendefinisikan setiap atribut dalam tabel.
 Menghubungkan Tabel Normalisasi
Ketika tabel yang tidak biasa dibagi menjadi beberapa tabel 3NF, tabel harus
dihubungkan bersama melalui kunci asing sehingga data di dalamnya dapat dikaitkan
dan dibuat dapat diakses oleh pengguna.
Kunci Dalam 1:1 Asosiasi. Di mana asosiasi 1:1 yang sebenarnya ada di antara tabel,
baik atau keduanya kunci primer dapat disematkan sebagai kunci asing dalam tabel
terkait.
Kunci di M:M Asosiasi. Untuk mewakili hubungan M: M antar tabel, tabel tautan harus
dibuat. Tabel tautan memiliki kunci gabungan (gabungan) yang terdiri dari kunci utama
dari dua tabel terkait.
 Auditor dan Sistem Normalisasi Data
Normalisasi database adalah masalah teknis yang biasanya menjadi tanggung jawab
para profesional. Subjeknya, bagaimanapun, memiliki implikasi untuk pengendalian
internal yang menjadi perhatian auditor juga. Misalnya, anomali pembaruan dapat
menghasilkan nilai database yang bertentangan dan usang, anomali penyisipan dapat

10
mengakibatkan transaksi yang tidak tercatat dan jalur yang tidak lengkap, dan anomali
penghapusan dapat menyebabkan hilangnya catatan akuntansi dan penghancuran
jejak audit. Meskipun sebagian besar auditor tidak akan bertanggung jawab untuk
normalisasi database organisasi, mereka harus memiliki pemahaman tentang proses
dan dapat menentukan apakah tabel dinormalisasi dengan benar. Selanjutnya, 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 penyimpanan mereka.
Misalnya, tugas audit untuk mengambil data yang berkaitan dengan pandangan
pengguna yang kompleks seperti pesanan pembelian akan melibatkan identifikasi dan
mengakses beberapa tabel terkait, hubungan yang rumit ini diilustrasikan secara lebih
rinci di bagian berikut saat kami memeriksa langkah-langkah yang terlibat dalam
pembuatan bagian dari database relasional perusahaan.

MERANCANG DATABASES RELASIONAL


Perancangan basis data adalah komponen dari proses pengembangan sistem yang
jauh lebih besar yang melibatkan analisis ekstensif terhadap kebutuhan pengguna,
yang merupakan topik Bab 5. Jadi, titik awal kami adalah salah satu yang secara
normal mengikuti pekerjaan pendahuluan yang cukup besar yang telah
mengidentifikasi secara rinci elemen kunci dari sistem yang sedang dikembangkan.
Dengan latar belakang ini, fokusnya adalah pada enam fase dari desain database,
yang secara kolektif dikenal sebagai pemodelan tampilan:
1. Identifikasi entitas.
2. Bangun model data yang menunjukkan asosiasi entitas
3. Tambahkan kunci utama dan atribut ke model.
4. Normalisasikan model data dan tambahkan kunci asing.
5. Bangun database fisik.
6. Siapkan pandangan pengguna.

Identifikasi Entitas
Modeling dimulai dengan mengidentifikasi entitas utama dari fungsi bisnis yang
dimaksud. Ingat bahwa entitas adalah hal-hal di mana organisasi ingin menangkap
data. Untuk menunjukkan identifikasi entitas. kami akan menganalisis fitur utama
berikut ini dengan sistem pembelian yang disederhanakan:

11
1. Agen pembelian meninjau laporan status persediaan untuk item yang perlu
diurutkan ulang.
2. Agen memilih pemasok dan membuat pesanan pembelian online.
3. Agen mencetak salinan pesanan pembelian dan mengirimkannya ke pemasok.
4. Pemasok mengirimkan persediaan ke perusahaan. Setelah kedatangannya,
juru tulis penerima memeriksa inventaris dan menyiapkan laporan penerimaan
online. Sistem komputer secara otomatis memperbarui catatan inventaris.
Entitas direpresentasikan sebagai kata benda dalam deskripsi sistem. Sejumlah entitas
kandidat dapat diidentifikasi dalam deskripsi sebelumnya: Agen Pembelian, Petugas
Penerimaan, Inventaris, Pemasok, Laporan Status Inventaris, Pesanan Pembelian,
dan Laporan Penerimaan. Tidak semua kandidat ini adalah entitas yang benar yang
perlu dimodelkan dalam database
Agen pembelian. Dengan asumsi bahwa organisasi hanya memiliki satu agen
pembelian, maka calon Agen Pembelian gagal Kondisi 1. 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 ditangkap dalam
tabel itu. Kita perlu menentukan data tentang agen yang unik untuk perannya dalam
penempatan pesanan yang perlu ditangkap. Perhatikan bahwa kami tidak mengacu
pada data tentang pesanan, tetapi data tentang agen. Karena kami tidak memiliki
informasi mengenai hal ini dalam uraian singkat kami tentang sistem, kami akan
menganggap tidak ada data khusus agen yang diambil. Oleh karena itu, kandidat Agen
Pembelian bukanlah entitas yang dimodelkan.
Menerima Petugas. Argumen sebelumnya juga berlaku untuk entitas Pegawai
Penerimaan. Kita akan berasumsi bahwa tidak ada data khusus petugas yang perlu
ditangkap yang memerlukan tabel khusus.
Inventaris. Entitas Inventaris memenuhi kedua kondisi tersebut. Deskripsi
menunjukkan bahwa organisasi menyimpan banyak item inventaris, sehingga entitas
ini akan berisi beberapa kejadian. Juga, kita dapat secara logis berasumsi bahwa
atribut yang mendefinisikan Inventaris entitas tidak disediakan melalui tabel lain.
Entitas Inventarisasi adalah entitas yang harus dimodelkan.
Pemasok. Deskripsi menyatakan bahwa beberapa vendor menyediakan persediaan;
maka entitas pemasok memenuhi syarat pertama. Kita juga dapat berasumsi bahwa ia
memenuhi kondisi kedua karena tidak ada entitas lain yang secara logis akan

12
menyediakan data pemasok. Entitas Pemasok, karena itu, akan dimasukkan dalam
model data.
Laporan Status Inventarisasi. Laporan Status Inventarisasi adalah tampilan pengguna
yang berasal dari entitas Inventarisasi dan Pemasok. Meskipun mengandung beberapa
kejadian, itu bukan entitas karena tidak memenuhi Kondisi 2. Pandangan ini berasal
sepenuhnya dari entitas yang ada dan tidak memberikan data tambahan yang
membutuhkan entitas yang terpisah. Akan tetapi, pandangan akan dianalisis secara
hati-hati untuk memastikan bahwa semua atribut yang diperlukan untuknya
dimasukkan dalam entitas yang ada.
Pesanan pembelian. Entitas pesanan pembelian memenuhi kedua kondisi. Banyak
pesanan pembelian akan diproses dalam suatu periode, sehingga entitas akan
memiliki banyak kejadian. Sementara beberapa data pesanan pembelian dapat berasal
dari entitas lain (inventory dan Supplier) dalam model, beberapa atribut yang unik
untuk acara pembelian seperti tanggal pesanan dan kuantitas pesanan akan
membutuhkan entitas terpisah yang perlu dimodelkan.
Menerima laporan. Laporan penerima memenuhi kedua kondisi. Banyak peristiwa
penerimaan akan berlangsung dalam periode tersebut, dengan demikian entitas
Laporan Penerimaan akan memiliki beberapa kejadian entitas. Laporan Penerimaan
akan berisi atribut seperti tanggal diterima dan kuantitas yang diterima yang unik untuk
entitas ini dan dengan demikian tidak dipagari oleh entitas lain dalam model. Pada titik
ini, pencarian kami telah mengungkapkan empat entitas: Inventarisasi, pemasok,
Pesanan pembelian, dan Laporan Penerimaan. Ini akan digunakan untuk membangun
model data dan, akhirnya, tabel database fisik.

Membangun Model Data Menampilkan Asosiasi Entitas


Langkah selanjutnya dalam pemodelan tampilan adalah untuk menentukan hubungan
antara entitas dan mendokumentasikannya dengan diagram ER. Ingat bahwa asosiasi
mewakili aturan bisnis. Terkadang aturannya jelas dan sama untuk semua organisasi.
Misalnya, hubungan normal antara entitas Pelanggan dan entitas urutan Penjualan
adalah 1:M (atau 1:0,M). Ini menandakan bahwa satu pelanggan dapat menempatkan
banyak pesanan selama periode penjualan. Asosiasi tidak akan pernah menjadi 1: 1.
Ini berarti bahwa organisasi membatasi setiap pelanggan untuk penjualan tunggal,
yang tidak masuk akal.
Kadang-kadang hubungan antara entitas tidak jelas karena aturan yang berbeda
mungkin berlaku di organisasi yang berbeda. Untuk menegaskan kembali poin penting

13
yang dibuat sebelumnya, aturan bisnis organisasi berdampak langsung terhadap
struktur database. Jika database berfungsi dengan baik, para perancangnya perlu
memahami aturan bisnis organisasi serta kebutuhan khusus dari pengguna individu.
Gambar 8.21 ilustrasi asosiasi entitas dalam contoh kita. Aturan bisnis yang
mendasarinya dijelaskan di bawah ini.
1. Ada hubungan 0,M:M antara pesanan Pembelian dan entitas Inventaris. Ini
berarti bahwa setiap item inventaris mungkin telah dipesan berkali-kali atau
tidak pernah dipesan dalam periode bisnis saat ini, jelas, setiap item inventaris
harus telah dibeli setidaknya sekali di masa lalu, jadi mengapa kita
menunjukkan 0,M kardinalitas untuk Pembelian entitas pesanan? Kita harus
ingat bahwa transaksi entitas, seperti penjualan dan pembelian, terkait dengan
kerangka waktu tertentu. Kami akan menganggap bahwa tabel Pesanan
Pembelian untuk sistem ini akan berisi catatan untuk pembelian yang dilakukan
dalam periode saat ini saja.
2. Ada asosiasi M:M antara entitas Inventarisasi dan Pemasok. Ini berarti bahwa
satu atau lebih vendor memasok setiap item persediaan, dan masing-masing
dari mereka mendukung satu atau lebih item inventaris.
3. Terdapat hubungan 1:0,M antara Pemasok dan entitas pesanan Pembelian. Ini
berarti bahwa dalam periode saat ini, masing-masing pemasok mungkin telah
menerima nol atau banyak pesanan pembelian, tetapi setiap pesanan hanya
pergi ke satu pemasok.
4. Ada hubungan 1:1 antara entitas Purchase Order dan Receiving Report. Satu
laporan penerimaan mencerminkan penerimaan barang yang ditentukan pada
catatan pesanan pembelian tunggal. Beberapa pesanan pembelian tidak
digabungkan pada satu laporan penerimaan.
5. Hubungan antara Laporan Penerimaan dan Entitas Inventori adalah 0,M:M. Ini
menandakan bahwa dalam periode tersebut, setiap item inventaris mungkin
telah diterima berkali-kali atau tidak pernah. Juga, setiap laporan penerimaan
dikaitkan dengan setidaknya satu dan mungkin banyak item inventaris.

Tambahkan Kunci Utama dan Atribut ke Model


Tambah Kunci Primer. Langkah berikutnya dalam proses ini adalah menetapkan kunci
primer ke entitas dalam model. Analis harus mencari kunci utama yang secara logis
mendefinisikan atribut non-key dan secara unik mengidentifikasi setiap kejadian dalam
entitas. Kadang-kadang ini dapat diselesaikan dengan menggunakan kode sekuensial

14
sederhana seperti Nomor Faktur, Nomor Cek, atau nomor pesanan Pembelian. Kode
berurutan, bagaimanapun, tidak selalu efektif atau efektif. Melalui desain blok kode
yang cermat, kode grup, kode alfabet, dan kode mnemonik, kunci primer juga dapat
memberikan informasi yang berguna tentang sifat entitas. Gambar 8.22 menyajikan
empat entitas dalam model dengan kunci primer yang ditugaskan.

Gambar 8.22

Tambahkan Atribut. Setiap atribut secara keseluruhan akan muncul secara langsung
atau tidak langsung (nilai kalibrasi) dalam satu atau lebih pandangan pengguna. Oleh
karena itu, atribut entitas, awalnya diturunkan dan dimodelkan dari pandangan
pengguna. Dengan kata lain, jika data yang disimpan tidak digunakan dalam laporan
dokumen, atau perhitungan yang dilaporkan dalam beberapa cara. maka itu tidak
berfungsi dan tidak boleh menjadi bagian dari database.

Normalisasikan Model Data dan Tambah Kunci Asing


Masalah normalisasi yang memerlukan resolusi diuraikan dalam bagian berikut:
1. Mengulangi Data Grup dalam urutan Pembelian. Atribut Part Number,
Description, Order Quantity, dan Unit Cost mengulang data grup. Ini berarti
bahwa ketika pesanan pembelian tertentu berisi lebih dari satu item (sebagian
besar waktu), kemudian beberapa nilai perlu diambil untuk atribut ini. Untuk
mengatasi ini, grup dala yang berulang ini dipindahkan ke entitas Item Detil Po
baru. Entitas baru diberi kunci utama yang merupakan gabungan dari Nomor
Bagian dan Nomor PO. Pembuatan keseluruhan baru juga menyelesaikan

15
hubungan M:M antara order Pembelian dan entitas Inventarisasi dengan
menyediakan tautan.
2. Mengulangi Data Grup dalam Laporan Penerimaan. Atribut Part Number,
Quantity Received, dan Kode Kondisi adalah grup yang berulang dalam entitas
Laporan Penerimaan dan telah dihapus ke entitas baru yang disebut Item
Rekam Detail Item. Sebuah COMPOSITE KUNCI terdiri dari BAGIAN NOMOR
dan REC REPT NUMBER telah ditetapkan. Seperti pada contoh sebelumnya,
membuat entitas baru ini juga menyelesaikan asosiasi M:M antara Receiving
Report dan Inventory.
3. Ketergantungan Transitif. The Purchase order dan Receiving Report entitas
berisi atribut yang berlebihan dengan data dalam entitas Inventarisasi dan
Pemasok. Redudansi ini terjadi karena dependensi transitif dalam entitas
Purchase Order and Receiving Report dan dijatuhkan.

Bangun Database Fisik


Kunci utama dan asing yang menghubungkan tabel diwakili oleh garis putus-putus.
Setiap catatan dalam tabel Detail Item Laporan Rek merepresentasikan setiap item
pada laporan penerimaan. Tabel memiliki kunci gabungan yang terdiri dari REC REPT
NUMBER dan PART NUMBER. Kunci gabungan ini diperlukan untuk mengidentifikasi
atribut Kuantitas dan Kondisi masing-masing dari setiap detail item secara unik. Bagian
REC REPT NUMBER dari kunci menyediakan tautan ke tabel Laporan Penerimaan
yang berisi data umum tentang peristiwa penerimaan. Bagian BAGIAN NOMOR kunci
digunakan untuk mengakses tabel Inventaris untuk memfasilitasi memperbarui bidang
Jumlah pada Tangan dari bidang Kuantitas yang Diterima dari catatan Item-Detil. The
PO Item Detail table menggunakan kunci primer gabungan dari PO NUMBER dan
BAGIAN NOMOR untuk mengidentifikasi atribut Quantity order secara unik. Komponen
PO NUMBER dari kunci komposit menyediakan tautan ke tabel pesanan Pembelian.
Elemen NOMOR KELOMPOK kunci adalah tautan ke tabel Inventaris tempat data
Uraian dan Biaya Unit berada. Langkah selanjutnya adalah membuat tabel fisik dan
mengisinya dengan data. Ini adalah langkah yang harus direncanakan dan
dilaksanakan dengan hati-hati dan mungkin membutuhkan waktu berbulan-bulan
dalam instalasi besar. Program perlu ditulis untuk mentransfer data organisasi yang
disimpan secara aman dalam file datar atau database warisan ke tabel relasional baru.
Data yang saat ini disimpan di dokumen kertas mungkin perlu dimasukkan ke dalam

16
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. Fungsi kueri dari DBMS relasional memungkinkan
perancang sistem untuk dengan mudah membuat tampilan pengguna dari tabel.
Perancang hanya memberi tahu DBMS tabel mana untuk digunakan, kunci utama dan
asing mereka, dan atribut untuk memilih dari masing-masing tabel. DBMSs lebih tua
mengharuskan perancang untuk menentukan parameter tampilan secara langsung di
SQL. Sistem yang lebih baru melakukan hal ini secara visual. Perancang hanya
menunjuk dan mengklik pada tabel dan atribut. Dari representasi visual ini, DBMS
menghasilkan perintah SQL untuk kueri untuk menghasilkan tampilan.
Program laporan digunakan untuk membuat tampilan menarik secara visual
dan mudah digunakan. Judul kolom dapat ditambahkan, bidang dijumlahkan, dan rata-
rata dihitung untuk menghasilkan salinan atau laporan layar komputer yang
menyerupai laporan pengguna asli. Program laporan dapat menekan data yang tidak
perlu dari tampilan, seperti bidang yang digandakan dan nilai kunci dalam tabel tautan
Inventori / Vendor. Kunci-kunci ini diperlukan untuk membangun tampilan, tetapi tidak
diperlukan dalam laporan yang sebenarnya.

Integrasi Tampilan Global


Proses pemodelan pandangan yang dijelaskan sebelumnya tergolong hanya satu
fungsi bisnis sistem pembelian dan tabel dan penayangan yang dihasilkan hanya
merupakan subschema dari keseluruhan skema basis data. Perusahaan modern,
bagaimanapun, akan membutuhkan ratusan atau ribuan tampilan dan tabel terkait.
Menggabungkan kebutuhan data semua pengguna ke dalam skema tunggal atau
tampilan seluruh perusahaan yang disebut integrasi tampilan. Ini adalah pekerjaan
yang menakutkan ketika membuat seluruh database dari awal. Untuk memfasilitasi
tugas ini, sistem Enterprise Resource Planning (ERP) modern dilengkapi dengan
skema inti, tabel dinormalkan, dan template tampilan. Database best-practices berasal
dari model ekonomi yang mengidentifikasi kesamaan di antara kebutuhan data dari
organisasi yang berbeda.

MODUL AUDIT DITEMUKAN

17
Tujuan dari modul audit tertanam (EAM), juga dikenal sebagai audit kontinyu, adalah
untuk mengidentifikasi transaksi penting ketika mereka sedang diproses dan
mengekstrak salinan dari mereka secara real time. EAM adalah modul yang diprogram
khusus yang tertanam dalam aplikasi host untuk menangkap jenis transaksi yang telah
ditentukan untuk analisis selanjutnya. Pendekatan ini diilustrasikan pada Gambar 8.
26.

Karena transaksi yang dipilih sedang diproses oleh aplikasi host, salinan
transaksi sedang disimpan dalam file audit untuk peninjauan berikutnya. Pendekatan
EAM memungkinkan transaksi yang dipilih untuk ditangkap selama periode audit.
Transaksi yang diambil tersedia untuk auditor secara realtime, pada akhir periode, atau
kapan saja selama periode tersebut, sehingga secara signifikan mengurangi jumlah
pekerjaan auditor harus dilakukan untuk mengidentifikasi transaksi signifikan untuk
pengujian substantive.
Untuk memulai penangkapan data, auditor menetapkan EAM parameter dan
ambang materialitas dari transaksi yang ditetapkan untuk ditangkap. Sebagai contoh,
mari kita asumsikan bahwa auditor menetapkan ambang batas materialitas $ 50.000
untuk transaksi yang diproses oleh sistem pemrosesan pesanan penjualan. Transaksi
yang sama atau lebih besar dari $ 50.000 akan disalin ke file audit. Dari serangkaian
transaksi ini, auditor dapat memilih subset yang akan digunakan untuk pengujian
substantif. Transaksi yang jatuh di bawah ambang batas ini akan diabaikan oleh EAM.
Meskipun terutama teknik pengujian substantif, EAM juga dapat digunakan
untuk memantau kontrol secara berkelanjutan seperti yang dipersyaratkan oleh SAS

18
109. Misalnya, transaksi yang dipilih oleh EAM dapat ditinjau untuk otorisasi yang
tepat. kelengkapan dan akurasi pemrosesan, dan posting yang benar ke akun.

Kekurangan EAMs
Pendekatan EAM memiliki dua kerugian yang signifikan. Yang pertama berkaitan
dengan efisiensi operasional dan sasaran berkaitan dengan integritas EAM.
 Efisiensi Operasional
Dari sudut pandang pengguna, EAM menurunkan kinerja operasional. Kehadiran
modul audit dalam aplikasi host dapat membuat overhead yang signifikan, terutama
ketika jumlah pengujian sangat luas. Salah satu pendekatan untuk membebaskan
burder ini dari sistem adalah merancang modul yang dapat diaktifkan dan
dinonaktifkan oleh auditor. Dengan demikian, tentu saja, mengurangi efektivitas EAM
sebagai alat audit yang sedang berjalan.
 Memverifikasi Integritas EAM
Pendekatan EAM mungkin bukan teknik audit yang layak di lingkungan dengan tingkat
pemeliharaan program yang tinggi. Ketika aplikasi host mengalami perubahan yang
sering, EAM yang tertanam dalam host juga akan membutuhkan modifikasi yang
sering. Masalah integritas yang dikemukakan sebelumnya mengenai pemeliharaan
aplikasi berlaku sama 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 SECARA 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 penggunaan
yang lebih umum untuk GAS meliputi:
 Memfokuskan dan menyeimbangkan seluruh file atau item data yang dipilih
 Memilih dan melaporkan data terperinci yang terdapat dalam file
 Memilih sampel statistik berstrata dari file data
 Memformat hasil pengujian ke dalam laporan
 Mencetak konfirmasi dalam susunan kata standar atau khusus
 Menyaring data dan secara selektif memasukkan atau mengecualikan item
 Membandingkan banyak file dan mengidentifikasi perbedaan apa pun
 Menghitung ulang bidang data

19
Popularitas GAS yang tersebar luas disebabkan oleh empat faktor: (1) bahasa GAS
mudah untuk menggunakan dan memerlukan sedikit latar belakang komputer pada
bagian auditor, (2) banyak produk GAS dapat digunakan pada sistem mainframe dan
PC, (3) auditor dapat melakukan tes mereka independen dari 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
yang diilustrasikan pada Gambar 8.27. Dalam contoh ini, file inventaris dibaca
langsung oleh GAS, yang mengekstrak informasi kunci yang diperlukan untuk audit,
termasuk kuantitas yang ada di tangan, dolar nilai, dan lokasi gudang dari setiap item
persediaan. Tugas auditor adalah untuk memverifikasi keberadaan dan nilai
persediaan dengan melakukan perhitungan fisik sampel yang representatif dari
persediaan di tangan. Dengan demikian, berdasarkan ambang materialitas yang
disediakan oleh auditor, GAS memilih catatan sampel dan menyiapkan laporan yang
berisi informasi yang diperlukan.

Gambar 8.27

Menggunakan GAS untuk Mengakses Struktur Kompleks


Mendapatkan akses ke struktur kompleks, seperti file hash atau bentuk file acak
lainnya, dapat menimbulkan masalah bagi auditor. Tidak semua produk GAS di pasar
dapat mengakses semua jenis struktur file. Jika CAATT yang bersangkutan tidak dapat
menangani struktur yang kompleks, auditor mungkin perlu mengajukan banding
kepada profesional sistem untuk menulis program khusus yang akan menyalin catatan
dari struktur aktual mereka ke struktur sekuensial file flat untuk pengambilan yang
mudah. Gambar 8.28 mengilustrasikan pendekatan ini.

20
Gambar 8.28

Kebanyakan DBMSs memiliki fitur utilitas yang dapat digunakan untuk


memformat ulang struktur yang rumit menjadi file datar yang sesuai untuk tujuan ini.
Untuk mengilustrasikan proses perataan file, perhatikan struktur basis data kompleks
yang disajikan pada Gambar 8.29. Struktur basis data menggunakan pointer untuk
mengintegrasikan tiga file terkait-Pelanggan, Faktur Penjualan, dan Item Baris-dalam
pengaturan hierarkis. Mengekstraksi bukti audit dari struktur kompleksitas ini
menggunakan GAS mungkin sulit, jika bukan tidak mungkin. Versi file datar yang lebih
sederhana dari struktur ini diilustrasikan pada Gambar 8.30. File datar tunggal
menyajikan tiga jenis catatan sebagai struktur sekuensial yang dapat dengan mudah
diakses oleh GAS.

21
Gambar 8.29

Masalah Audit Berkaitan dengan Pembuatan File Datar


Auditor kadang-kadang harus bergantung pada personel layanan komputer untuk
menghasilkan file datar dari struktur file yang kompleks. Ada risiko bahwa integritas
data akan dikompromikan oleh prosedur yang digunakan untuk membuat file datar.
Misalnya, jika tujuan auditor adalah untuk mengkonfirmasi piutang, akun curang
tertentu dalam struktur kompleks dapat dengan sengaja dihilangkan dari salinan file
datar yang dibuat.

PERANGKAT LUNAK ACL


Di masa lalu, kantor akuntan publik mengembangkan versi eksklusif GAS, yang
digunakan dalam audit klien mereka. Baru-baru ini, perusahaan perangkat lunak telah
melayani pasar ini. Di antara 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 untuk menguji mereka secara
komprehensif. Faktanya, banyak masalah yang terkait dengan pengaksesan struktur
data yang rumit telah diselesaikan oleh antarmuka Database Connectivity (ODBC) ACL
yang terbuka.

22
Gambar 8.30

Definisi Data
Kami telah menetapkan bahwa sistem klien dapat menyimpan data menggunakan
sejumlah file flat atau struktur database, termasuk file sekuensial, file VSAM, daftar
terkait, dan tabel relasional. Salah satu kekuatan ACL adalah kemampuan untuk
membaca data yang tersimpan dalam sebagian besar format. ACL menggunakan fitur
definisi data untuk tujuan ini. Untuk membuat definisi data, auditor perlu mengetahui
baik di mana file sumber secara fisik berada dan tata letak bidangnya. File kecil dapat
diimpor melalui file teks atau spreadsheet. File yang sangat besar mungkin perlu
diakses langsung dari komputer mainframe. Ketika ini terjadi, auditor harus
mendapatkan hak akses ke direktori tempat file berada. Sedapat mungkin,
bagaimanapun, salinan file harus disimpan dalam direktori uji terpisah atau diunduh ke
PC auditor. Langkah ini biasanya memerlukan bantuan dari para profesional sistem.
Auditor harus memastikan bahwa dia mengamankan versi yang benar dari file, yang
lengkap, dan bahwa dokumentasi struktur file masih utuh. Pada titik ini, auditor siap
untuk menentukan file ke ACL.

Menyesuaikan Tampilan

23
Pandangan hanyalah cara melihat data dalam file, auditor jarang perlu menggunakan
semua data yang terdapat dalam file. ACL memungkinkan auditor untuk menyesuaikan
tampilan asli yang dibuat selama definisi data ke definisi yang lebih baik 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.

Memfilter Data
ACL menyediakan opsi yang kuat untuk memfilter data yang mendukung berbagai tes
audit. Filter adalah ekspresi yang mencari rekaman yang memenuhi kriteria filter.
Pembuat ekspresi ACL memungkinkan auditor untuk menggunakan operator logika
seperti AND, OR, NOT, <, >, dan lainnya untuk menentukan dan menguji kondisi.
Sebagai contoh, auditor dapat mengarsipkan dan menginventarisir file untuk catatan
dengan kuantitas negatif atau nol di tangan. Layar ekspresi buildee dan filter yang
diperlukan untuk tes ini diilustrasikan pada Gambar 8.34.
Ketika auditor mengeksekusi prosedur filter ini, ACL menghasilkan pandangan
baru dari file persediaan (Gambar 8.35) yang berisi empat rekaman dengan tingkat
kuantitas-pada-tangan nol atau negatif. Contoh ini menunjukkan bagaimana auditor
menggunakan ACL untuk mencari anomali dan kondisi yang tidak biasa dalam file-file
akuntansi yang berisi ribuan catatan yang menentang tinjauan dengan memindai
secara visual isinya.

Gambar 8.34

24
Gambar 8.35

Data Stratifikasi
Fitur stratifikasi ACL memungkinkan auditor untuk melihat distribusi rekaman yang
termasuk dalam strata tertentu. Data dapat dikelompokkan pada bidang angka apa pun
seperti harga penjualan, biaya unit, kuantitas yang terjual, dan sebagainya. Data
diringkas dan diklasifikasikan berdasarkan strata, yang dapat memiliki ukuran yang
sama (disebut interval) atau bervariasi dalam ukuran (disebut bebas). Gambar 8.36
mengilustrasikan hasil dari stratifikasi tabel inventaris di bidang satuan biaya. Dalam
contoh ini, nilai persediaan juga dihitung untuk setiap interval. Auditor dapat memilih
untuk mengubah ukuran dan jumlah interval atau memeriksa hanya sebagian dari file.
Analisis Statistik
ACL menawarkan banyak metode sampling untuk analisis statistik. Dua yang paling
sering digunakan adalah sampling dan unit sampling moneter (MUS). Setiap metode
memungkinkan pengambilan sampel secara acak dan interval. Pilihan metode akan
bergantung pada strategi auditor dan komposisi file yang diaudit. Di satu sisi, ketika
catatan dalam file terdistribusi merata di seluruh strata, auditor mungkin menginginkan
sampel yang tidak bias dan dengan demikian akan memilih pendekatan sampel
rekaman. Menggunakan inventaris untuk mengilustrasikan, setiap catatan, terlepas
dari jumlah dolar dari bidang nilai inventaris, memiliki peluang yang sama untuk

25
dimasukkan dalam sampel. Di sisi lain, jika file tersebut sangat miring dengan item nilai
besar, auditor dapat memilih MUS, yang akan menghasilkan sampel yang mencakup
semua jumlah dolar yang lebih besar.

Gambar 8.36

KESIMPULAN

Struktur data memiliki dua komponen dasar yakni organisasi dan metode akses
dimana terdapat beberapa struktur seperti struktur file datar, struktur terindeks, struktur
hashing, serta struktur database hirarki. Di dalam struktur basis data relasional,
konsep, dan terminology pun terdapat beberapa hal yang dipaparkan seperti teori
relasional database yang mana teori ini memiliki tiga fungsi aljabar yaitu batasi, proyek,
dan bergabung sementara untuk konsep database regional sendiri terdiri dari entitas,
kejadian, atribut dan asosiasi dan kardinalitas. Untuk tabel fisik database sendiri fisik
dibangun dari model data dengan setiap entitas dalam model yang diubah menjadi
tabel fisik terpisah.
Tujuan dari modul audit ditemukan adalah untuk mengidentifikasi transaksi
penting ketika sedang dilakukan proses dan mengekstrak salinan dari mereka secara
real time. Setiap prosedur atau cara yang digunakan memiliki kelebihan dan
kekurangan termasuk modul audit ditemukan ini, namun yang jelas ini berguna bagi
auditor dalam mengungkapkan apakah ada sesuatu yang disembunyikan oleh
perusahaan atau murni benar-benar bersih. Adapula pembahasan mengenai
merancang database relasional ini berfokus pada enam hal yaitu identifikasi entitas,
bangun model data yg merupakan asosiasi entitas, tambah kunci utama dan atribut ke

26
model, normalisasi model data dan tambah kunci asing, serta membangun database
fisik.

REFERENSI

James A. Hall. 2011. Information Technology Auditing and Assurance. Third edition,
Cengage Learning

27