Anda di halaman 1dari 33

DATA STRUCTURES AND CAATTs FOR DATA EXTRACTION

TUGAS MATA KULIAH


AUDITING EDP
PENDAHULUAN

Bab ini akan menjelaskan penggunaan CAATT untuk ekstraksi dan analisi
data. CAATT sangat diperlukan auditor dalam menjalankan tugasnya. Dengan CAATT
ini dapat membantu auditor dalam mengumpulkan data akuntansi untuk menguji
pengendalian aplikasi dan dalam melakukan uji substantif. Berbeda dengan bab
sebelumnya, dibahas bagaimana CATT digunakan untuk menguji pengendalian
aplikasi secara langsung. Alat ekstraksi data yang akan dibahas pada bab ini
digunakan untuk menganalisis data yang diproses oleh sutau aplikasi, bukan untuk
menganalisis aplikasi itu sendiri. Dengan menganalisis daya yang ditelusuri dari file
komputer, auditor bisa menarik kesimpulan mengenai keberadaan dan fungsionalitas
pengendalian dalam aplikasi yang memproses data.

Penggunaan penting lainnya dari peranti lunak ekstraksi data adalah dalam
pelaksanaan uji substantif Kebanyakan pengujian audit terjadi dalam tahap pengujian
substantive dari audit. Prosedur-prosedur ini disebut uji substantive karena digunakan
untuk, namun tidak terbatas pada berikut ini:

1. Menetukan nilai yang tepat dari persediaan


2. Menentukan keakuratan dari prapembayarandan akrual
3. Mengonfirmasikan piutang usaha dengan pelanggan
4. Mencari kewajiban yang tidak tercatat

Dalam lingkungan TI, record dibutuhkan untuk melakukan uji semacam ini
disimpan dalam file computer dan basis data. Sebelum uji substantive dilaksanakan,
data perlu diekstraksi dari sistem host dan disajikan ke auditor dalam format yang
mudah digunakan.

Bab ini diawali dengan kajian struktur data. Struktur data merupakan susunan
data secara fisik dan logis dalam file dan basis data. Pemahaman mengenai cara
mengatur dan mengakses data merupakan hal penting dalam menggunakan alat
ekstraksi data. Peranti lunak ekstraksi data terdiri atas dua kategori umum, yaitu:

1. Modul audit melekat


2. Peranti lunak audit umum
Bagian kedua bab ini akan mendeskripsikan fitur, keunggulan , dan kerugian
dari pendekatan modul audit melekat (EAM). Bagian terakhir akan menjelaskan fungsi
dan penggunaan peranti lunak audit yang digeneralisasi (GAS). Selajutnya, akan
ditutup dengan kajian mengenai fitur-fitur utama dari bahasa perintah audit, produk
utama dalam pasar GAS.
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


Pendekatan flat-file adalah model tampilan tunggal yang menjadi ciri sistem
warisan. File data terstruktur, format ted, 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.
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
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.
 Relational Database Theory
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:
 Restrict: ekstrak baris yang ditentukan dari tabel yang ditentukan.
 Project: ekstrak atribut tertentu (kolom) dari tabel untuk membuat tabel virtual.
 Join: buat tabel fisik baru dari dua tabel yang terdiri dari semua pasangan
baris yang bersambung, dari masing-masing tabel.
Meskipun restrict, project, dan join 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).

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.

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.

 The Physical Database Tables


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.
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.

 User Views
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).
Update Anomaly
Anomali pembaruan hasil dari redundansi data dalam tabel yang tidak dikenali.
Untuk lebih menghargai implikasi dari anomali pembaruan, pertimbangkan situasi
yang lebih realistis.

Insertion Anomaly
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.

Deletion Anomaly
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
repeating groups, partial dependencies, dan transitive dependencies. 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 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:
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
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. Asosiasi
mewakili aturan bisnis. Terkadang aturannya jelas dan sama untuk semua organisasi.
Misalnya, hubungan normal antara entitas pelanggan dan entitas order penjualan
adalah 1:M. Ini menandakan bahwa satu pelanggan dapat menempatkan banyak
pesanan selama periode penjualan.
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. Aturan bisnis yang
mendasarinya dijelaskan di bawah ini.
1. Ada hubungan 0,M:M antara pesanan pembelian dan entitas Inventaris. Setiap
item inventaris mungkin telah dipesan berkali-kali atau tidak pernah dipesan
dalam periode bisnis saat ini. Setiap item inventaris harus telah dibeli setidaknya
sekali di masa lalu. Kita harus ingat bahwa transaksi entitas, seperti penjualan
dan pembelian, terkait dengan kerangka waktu tertentu. Pesanan pembelian
untuk sistem ini akan berisi catatan untuk pembelian yang dilakukan dalam
periode saat ini saja.
2. Ada asosiasi M:M antara entitas inventaris dan pemasok. 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 order pembelian dan laporan penerimaan. 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.
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. Terkadang hal ini dapat diselesaikan dengan menggunakan kode sederhana
seperti nomor faktur, nomor cek, atau nomor pesanan pembelian.
Tambahkan Atribut
Setiap atribut secara keseluruhan akan muncul secara langsung atau tidak
langsung dalam satu atau lebih pandangan pengguna. Oleh karena itu, atribut entitas,
awalnya 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, kemudian beberapa nilai perlu diambil untuk atribut ini. Untuk
mengatasi, grup data 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 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. 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.
Membangun 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. Pada Bagian Nomor kunci digunakan
untuk mengakses tabel inventaris. 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. 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 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 dan
atribut untuk memilih dari masing-masing tabel.
Program laporan digunakan untuk membuat tampilan menarik secara visual
dan mudah digunakan. 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 yang dijelaskan sebelumnya tergolong hanya satu fungsi


bisnis sistem pembelian dan tabel dan 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. Untuk memfasilitasi tugas ini, sistem
Enterprise Resource Planning (ERP) modern dilengkapi dengan skema inti, tabel
dinormalkan, dan tampilan template. Database best-practices berasal dari model
ekonomi yang mengidentifikasi kesamaan di antara kebutuhan data dari organisasi
yang berbeda.

EMBEDDED AUDIT MODULE (EAM)

Tujuan dari EAM, yang juga dikenal sebagai audit kontinyu, adalah untuk
mengidentifikasi transaksi penting ketika mereka sedang diproses dan mengekstrak
salinan secara real time. EAM adalah modul yang diprogram khusus yang tertanam
dalam aplikasi host untuk menangkap jenis transaksi yang telah ditentukan untuk
analisis selanjutnya.
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.
Untuk memulai penangkapan data, auditor menetapkan parameter EAM dan
ambang materialitas dari transaksi yang ditetapkan untuk ditangkap. Sebagai contoh,
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.

Kekurangan EAMs

Pendekatan EAM memiliki dua kekurangan yang signifikan. Yang pertama


berkaitan dengan efisiensi operasional dan yang kedua berkaitan dengan integritas
EAM.
1. 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 dengan merancang modul yang
dapat diaktifkan dan dinonaktifkan oleh auditor. Dengan demikian, tentu saja,
mengurangi efektivitas EAM sebagai alat audit yang sedang berjalan.
2. Memverifikasi Integritas EAM
Pendekatan EAM mungkin bukan teknik audit yang dapat dijalankan dalam
lingkunganyang memiliki tingkat pemeliharaan program tinggi.Ketika aplikasi
hostsering mengalami perubahan, EAM yang dilekatkan dalam hostakan sering
juga membutuhkan modifikasi. Integritas EAM secara langsung mempengaruhi
kualitas proses audit. Oleh karena itu, auditor harus mengevaluasi integritas EAM.
Evaluasi ini dilakukan dengan cara yang sama seperti ketika menguji
pengendalian aplikasi host.

PERANTI LUNAK AUDIT YANG DIGENERALISASI


Peranti lunak audit yang digeneralisasi (GAS) adalah CAATT yang paling
banyak digunakan untuk audit SI. GAS memungkinkan auditor mengakses secara
elektronik file data berkode dan melakukan berbagai operasi atas isinya. Beberapa
penggunaan GAS yang paling umum meliputi:
 Memfokuskan dan penyeimbangan seluruh file atau item data yang dipilih
 Pemilihan dan pelaporan data terperinci yang berada dalam berbagaifile
 Pemilihan sampel statistik yang distratifikasi dari berbagaifile data
 Pemformatan hasil pengujian ke dalam bentuk laporan
 Konfirmasi pencetakan dalam kata-kata yang terstandardisasi atau khusus
 Penyaringan data dan secara selektif memasukkan atau mengecualikan item
 Membandingkan beberapafile dan mengidentifikasi perbedaannya
 Perhitungan ulang berbagai field data

Popularitas GAS yang tersebar luas disebabkan oleh empat faktor: (1) bahasa
GAS mudah digunakan dan hanya membutuhkan sedikit latar belakang ilmu komputer
bagi auditor; (2) banyak produk GAS dapat digunakan pada sistem mainframe dan
PC; (3) auditor dapat melakukan pengujiantanpa melibatkan 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 mudah,
seperti yang diilustrasikan pada Figure 8.27. Dalam contoh ini, file persediaan dibaca
langsung oleh GAS, yang mengekstraksi informasi penting yang dibutuhkandalam
audit, termasuk kuantitas barang di gudang, nilai uang, dan lokasi gudang daritiap
barang persediaan. Tugas auditor adalah memverifikasi keberadaan dan nilai dari

persediaan dengan melakukan perhitungan fisik atas sampel yang


mewakilijumlahbarang di gudang. Kemudian, berdasarkan batas bawah materialitas
yang ditentukan auditor, GAS akan memilih beberaparecord sampel dan membuat
laporan yang berisi informasi yang dibutuhkan.

Menggunakan GAS untuk Mengakses Struktur Kompleks


Mendapatkan akses ke struktur kompleks, seperti filehashing atau bentuk file
acak lainnya, dapat menimbulkan masalah bagi auditor. Tidak semua produk GAS di
pasar dapat mengakses tiap jenis struktur file. Jika CAATT yang digunakan tidak
dapat menangani struktur yang kompleks, maka auditor mungkin harus menggunakan
ahli sistem untuk menulis sebuah program yang akan menyalin record dari struktur
sesungguhnya menjadi struktur flatdatar berurutan yang mudah ditarik. Figure
8.28mengilustrasikan pendekatan ini.

Kebanyakan fitur utilitas DBMS dapat digunakan untuk memformat ulang


struktur filekompleks menjadi file datar yang sesuai untuk tujuan ini. Untuk
mengilustrasikan proses pendataranfile, perhatikan struktur basis data kompleks yang
disajikan pada Figure 8.29. Struktur basis data menggunakan pointer untuk
mengintegrasikan tiga fileyang saling berkaitan-Pelanggan, Faktur Penjualan, dan
Keterangan Barang secara hierarkis. Mengekstraksi bukti audit dari struktur yang
kompleks ini menggunakan GAS, merupakan pekerjaan yang sulit, bahkan tidak
mungkin. Versi file datar yang lebih sederhana untuk struktur ini diilustrasikan pada
Figure 8.30. File datar tersebut mewakili tiga jenis record dalam bentuk struktur
berurutan yang dapat dengan mudah diakses oleh GAS.
Isu Audit yang Berkaitan dengan Pembuatan File Datar

Auditor kadang harus mengandalkan personel layanan komputer untuk


membuatfile datar dari struktur file yang kompleks. Terdapat risiko bahwa integritas
data akan berkurangkarena prosedur yang digunakan untuk membuat file datar.
Misalnya, jika tujuan auditor adalah mengonfirmasikan piutang usaha, rekening
penipuan tertentu dalam struktur kompleks mungkin sengaja dihilangkan dari salinan
file datar yang dibuat. Sampel konfirmasi yang berasal dari file datar tersebut
karenanya tidak dapat diandalkan. Auditor yang ahli dalam bahasa pemrograman
dapat menghindari potensi ini dengan cara menulis sendiri program ekstraksi datanya.

PERANGKAT LUNAK ACL


Di masa lalu, kantor akuntan publik mengembangkan versi eksklusif GAS,
yang digunakan dalam audit klien mereka. Baru-baru ini, perusahaan peranti lunak
telah melayani pasar ini. Di antaranya, ACL (Audit Command Language) adalah
pemimpin dalam industri, ACL dirancang sebagai meta-bahasa bagi auditor untuk
mengakses data yang disimpan dalam peralatan elektronik dan untuk mengujinya
secara komprehensif. Banyak masalah yang berkaitan dengan akses ke struktur data
yang kompleks telah dapat diatasimelalui antarmuka ACL yaitu, OpenData
BaseConnectivity(ODBC).

Definisi Data
Sistem klien dapat menyimpan data menggunakan sejumlah filedatar atau
struktur basisdata, termasuk fileberurutan, fileISAM, daftar yang terhubung, dan tabel
relasional. Salah satu kelebihan ACL adalah kemampuannya untuk membaca data
yang disimpan dalam hampir semua format. ACL menggunakan fitur definisi data
untuk tujuan ini. Untuk membuat definisi data, auditor perlu mengetahui lokasifisikfile
sumber dan tata letak strukturfield-nya. Fileyang 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 filedisimpan. Jika memungkinkan, satu salinan file harus disimpan
dalam direktori pengujian terpisah atau diunduh ke PC auditor. Langkah ini biasanya
membutuhkan bantuan dari ahli sistem. Auditor harus memastikan bahwa dia
menyimpan versi fileyang benar, lengkap, dan bahwa dokumentasi struktur filetetap
utuh. Pada titik ini, auditor siap untuk melakukan definisi data ke ACL.
Layar definisi data ACL memungkinkan auditor menentukan karakteristik
pebting file sumber, termasuk panjang record keseluruhan, nama yang diberikan ke
tiap field, jenis data (contohnya, numeris atau karakter) yang terdapat dalam tiap field,
serta titik awal dan panjang tiap field dalam file tersebut.
Menyesuaikan Tampilan
Tampilan hanyalah cara melihat data dalam file, auditor jarang menggunakan
semua data yang berada dalam file. ACL memungkinkan auditor untuk menyesuaikan
tampilan asli yang dihasilkan dari proses definisi data menjadi tampilan yang dapat
memenuhi kebutuhan auditnya dengan lebih baik. Auditor dapat membuat dan

memformat ulang tampilan baru tanpa mengubah atau menghapus data dalam
filedasarnya. Hanya cara penyajian data saja yang berubah.

Memfilter Data
ACL menyediakan pilihan yang canggih untuk menyaring data yang
mendukung berbagai uji audit. Filter adalah ekspresi yang mencari record yang sesuai
dengan kriteria penyaringannya. Expression builder dari ACL memungkinkan
auditormenggunakan operator logis seperti AND, OR, <, >, NOT dan lainnya untuk
menentukan serta menguji kondisi kompleks, dan hanya memproses record yang
sesuai kondisi yang telah ditentukan. Contohnya, auditor dapat mencari
dalamfilepersediaan untuk recordyang memiliki nilai jumlahdi gudang nol atau negatif.
Tampilan expression builder dan saringan yang diperlukan untuk pengujian ini
diilustrasikan pada Figure 8.34.

Ketika auditor menjalankan prosedur penyaringan ini, ACL menghasilkan


tampilan baru file persediaan (Figure 8.35) yang berisi empat record dengan nilai
jumlah barang di gudang nol atau negatif. Contoh ini menunjukkan cara auditor
menggunakan ACL untuk mencari anomali serta kondisi yang tidak wajar dalam file
akuntansi yang berisi ribuan record, yang umumnya akan mempersulit jika isinya
dipindai secara visual.
Menstratifikasi Data
Fitur stratifikasi ACL memungkinkan auditor untuk melihat distribusi record
yang masuk ke dalam strata yang telahditentukan. Data dapat distratifikasiuntuk
fieldnumeris apa pun seperti harga penjualan, biaya per unit, kuantitas dijual, dan lain-
lainnya. Data diringkas dan diklasifikasikan berdasarkan strata, yang dapat berupa
ukuran yang sama (interval) atau berupa ukuran yang berbeda (disebut free). Figure
8.36 mengilustrasikan hasil dari stratifikasi tabel persediaan dalam field biaya per unit.
Dalam contoh ini, nilai persediaan juga dihitung untuk tiap interval. Auditor dapat

memilih untuk mengubah ukuran dan jumlah interval atau hanya mempelajarisebagian
dari file.
Analisis Statistik
ACL menawarkan banyak metode pengambilan sampel untuk analisis statistik.
Dua metode yang paling sering digunakan adalahrecordsampling dan monetary unit
sampling (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 record dalam file terdistribusi merataantar strata, maka
auditor mungkin menginginkan sampel yang tidak bias,hingga memilih pendekatan
record sampling. Menggunakan tabel persediaansebagai ilustrasi, tiap record, berapa
pun nilai uangnyadalam field nilai persediaan, memiliki peluang yang sama untuk
dimasukkan dalam sampel. Di sisi lain, jika file tersebut cenderung condongke salah
satu sisi dengan nilai persediaan yang besar, auditor dapat memilih pendekatan MUS,
karena akan menghasilkan sampel yang memasukkan semua nilai persediaan yang
lebih besar.
KESIMPULAN

CAATs merupakan sbuah perangkat dalam menerapkan prosedur audit yang


mengharuskan auditor untuk mempertimbangkan teknik - teknik yang menggunakan
komputer sebagai suatu alat audit.CAATs ini berguna untuk mengurangi waktu audit
dalam analisis, pengujian dan pelaporan, sekaligus meningkatkan fleksibilitas dan
kecepatan apabila ada perubahan dalam prosedur audit dan juga
mempercepatproses review audit. Di dalam CAATs dikenal yang namanya data
stucture yang merupakan susunan data dalam sebuah file dan basis data berkaitan
dengan ekstraksi data. Di dalam sebuah data structure terdapat data stucture
component dan file - file structure. Kemudian file - file structure ini dibagi lagi kedalam
sequental structure, indexed structure, hashing structure, pointer structure yang
semuanya saling berkoordinasi untuk menjalankan prosedur audit dalam sebuah
teknologi bernama CAATs tersebut.
REFERENSI

Hall, James A. 2011. Information Technology Auditing and Assurance 3 rd Edition.


South-Western Cengage Learning, USA: PreMediaGlobal.

Hall, James A; dan Tommie Singleton. 2007. Audit Teknologi Informasi dan Assurance
Edisi 2 Buku 1. Jakarta Selatan: Salemba Empat.

Anda mungkin juga menyukai