MAKALAH MATA KULIAH SISTEM

INFORMASI AKUNTANSI 2
(Chapter 4: Database Relasional)

Disusun Oleh Kelompok II :

M. Efwin Yudha A. 023164604
I Gedhe Gita Adhi P. 023164558
Dian Mulia Sari 023164564
Anggi Adhitya P. 023164615
Meysza Monzana 023164611
Novita Sariwijaya 023164619
Dwiky Krisyunianto 023001708075

FAKULTAS EKONOMI DAN BISNIS

UNIVERSITAS TRISAKTI
 DAFTAR ISI

Pendahuluan……………………………………………………..…………………………………..3

File Versus Database……………………………………………………………………………..3

Menggunakan Gudang Data untuk Business Inteligence…………………………...............4

Keunggulan Sistem Database…………………………………………………………………...4

Pentingnya Data yang Baik………………………………………………………………………5

Sistem Database………………………………………………………………………..…………...6

Tampilan Logis dan Fisik atas Data…………………………………………………………….6

Skema……………………………………………………………………………………………...7

Kamus Data……………………………………………………………………………………….8

Bahasa DMS………………………………………………………………………………………8

Database Relasional………………………………………………………………………………..9

Tipe-Tipe Atribut…………………………………………………………………………………..9

Membuat Database Relasional untuk S&S, Inc……………………………………………...10

Persyaratan Dasar Database Relasional……………………………………………………..13

Dua Pendekatan untuk Desain Database…………………………………………...............15

Membuat Query Database Relasional………………………………………………………..16

Sistem Database dan Masa Depan Akuntansi……………………………………………….24

Daftar Pustaka

2
 Chapter 4

Database Relasional

File versus Database

• Field: informasi mengenai atribut-atribut dari pelanggan (nama, alamat)

• Catatan (record): semua field yang berisi data mengenai satu entitas (satu pelanggan)
• File: seperangkat catatan (record) yang saling terkait (file pelanggan)
• Database: seperangkat koordinasi beberapa file terpusat yang saling berhubungan
yang disimpan dengan sedikit mungkin kelebihan data

• Sistem Manajemen Database (Database Management System): Program yang

mengelola dan mengendalikan data serta menghubungkan data dan program-program
aplikasi yang menggunakan data yang disimpan dalam database
• Sistem Database: Database, DBMS, dan program-program aplikasi yang mengakses
database melalui DBMS
• Administrator Database: seseorang yang bertanggung jawab untuk
mengkoordinasikan, mengendalikan dan mengelola database

3
Database dikembangkan untuk menempatkan poliferasi (pengembangbiakan) file induk.
Pengembangbiakan ini menimbulkan permasalahan seperti penyimpanan data yang sama
dalam dua atau lebih file induk. Hal tersebut menimbulkan kesulitan untuk mengintegrasikan
dan memperbarui data serta mendapatkan tampilan luas suatu organisasi data. Kejadian ini
juga menimbulkan permasalahan karena data dalam beberapa file yang berbeda berubah.

Menggunakan Gudang Data untuk Business Intelligence

• Gudang Data (Data Warehouse): Database yang sangat besar berisi data yang
mendetail dan diringkas selama beberapa tahun yang digunakan untuk analisis, bukan
pemrosesan transaksi.
• Business intelligence: menganalisis data dalam jumlah yang besar untuk pembuatan
keputusan strategis.

Ada 2 (dua) teknik yang digunakan:

✓ Pemrosesan Analitikal Online (OnLine Analytical Processing-OLAP):

menggunakan beberapa query untuk menyelidiki hipotesis hubungan antardata.
✓ Penggalian Data (Data Mining): menggunakan analisis statistik yang canggih
untuk “menemukan” hubungan yang tidak dihipotesiskan dalam data.

Pengendalian yang sesuai dibutuhkan untuk mendapatkan keuntungan yang signifikan atas
pemanfaatan gudang data. Pengendalian validasi data dibutuhkan untuk memastikan bahwa
input atas gudang data lebih akurat, sementara memverifikasi keakuratan data (scrubbing
data) seringkali menjadi tahapan dalam pembuatan gudang data yang paling memakan
waktu dan mahal.

Keunggulan Sistem Database

Database memberi organisasi keuntungan-keuntungan berikut ini:

4
 • Integrasi Data: beberapa file induk digabungkan ke dalam “kelompok-kelompok” data
besar atas yang diakses oleh banyak program aplikasi. Contohnya, file induk
penggajian, personel, dan keterampilan kerja.
• Pembagian Data: Data yang terintegrasi lebih mudah dibagi dengan pengguna yang
sah. Dataase dapat dengan mudah dicari untuk memperoleh informasi mendetail
yang mendasari laporan.
• Meminimalkan kelebihan dan inkonsistensi data: item-item data biasanya hanya
disimpan sekali dan menghindari adanya duplikasi data.
• Independensi data: Database relasional menjamin independensi antara data dan
program, data tidak bergantung pada program yang meng-akses-nya, karena
struktur data-nya dirancang berdasarkan kebutuhan informasi, bukan berdasarkan
struktur program. Sebaliknya program juga tidak bergantung pada data, sehingga
walaupun struktur data diubah, program tidak perlu berubah.
• Analisis system fungsional: Pada sistem database, hubungan seperti hubungan
antara biaya penjualan dan kampanye promosi, dapat secara eksplisit
diidentifikasikan dan digunakan dalam mempersiapkan laporan-manajemen.

Pentingnya Data yang Baik

Data memiliki arti yang sangat penting bagi kelangsungan suatu perusahaan. Perusahaan
membutuhkan penyusunan data baik agar dapat membantu para pengusaha maupun
manajernya dalam mengambil sebuah keputusan. Data yang baik dapat disusun dalam
sebuah database (basis data). Database memiliki arti penting dalam perusahaan agar dapat
mengumpulkan, mengorganisir dan menganalisa data bisnis perusahaan. Sebaliknya, data
yang tidak benar pada database dapat mengarahkan kepada keputusan yang buruk,
kebingungan dan pengguna yang marah. Database dianggap sangat penting, karena
beberapa fungsinya yang meliputi:

1. Sebagai komponen utama atau penting dalam sistem informasi, karena merupakan
dasar dalam menyediakan informasi.
2. Menentukan kualitas informasi yaitu cepat, akurat, dan relevan, sehingga infromasi
yang disajikan tidak basi. Informasi dapat dikatakan bernilai bila manfaatnya lebih
efektif dibandingkan dengan biaya mendapatkanya.
3. Mengatasi kerangkapan data (redundancy data).
4. Menghindari terjadinya inkonsistensi data.
5. Mengatasi kesulitan dalam mengakses data.
6. Menyusun format yang standar dari sebuah data.

5
Sistem Database

1. Tampilan Logis dan Tampilan Fisik atas Data ( Logical and Physical View of Data)
Dalam system database, secara konsep terdapat 2 kategori bagaimana cara melihat
sebuah database yaitu Logical View dan Physical View. Dua tampilan tersebut berasal dari
bagaimana setiap pihak yang berkepentingan terhadap database memiliki kebutuhan atau
tujuan tertentu atas system database tersebut. Tampilan Logis (Logical View) adalah
bagaimana setiap orang melihat secara konseptual melihat, mengelola, dan memahami
hubungan antar komponen data. Tampilan fisik adalah bagaimana data secara fisik dikelola
dan secara fisik disimpan. Untuk mempermudah bagaimana memahami perbedaan antara
Logical View dan Physical View, berikut beberapa contoh ilustrasi:
a. Logical View
i. Seorang manager penjualan melihat semua informasi penjualan di dalam sebuat table.
ii. Seorang programmer diminta untuk menyusun laporan mengenai produk mana yang
paling banyak dijual, maka ia secara logis akan melihat bahwa data penjualan dapat
diperoleh dari table Penjualan, sedangkan referensi nama produk dan harganya
dapat diperoleh dari table Persediaan, maka ia harus membuat query untuk menari
informasi dari kedua table tersebut.
b. Physical View
i. Seorang database administrator menyimpan database pada storage/hardisk dengan
kecepatan tertentu untuk meningkatkan kinerja system.
ii. Untuk meningkatkan ketersediaan (availabity) seorang database administrator akan
menyimpan database pada dua storage yang berbeda (redundant storage).

Database Management System (DBMS) memungkinkan pengguna mengakses,

memahami, mengelola, menarik data (query) tanpa referensi bagaimana dan dimana data
disimpan secara fisik.

6
 Gambar 1. Fungsi DBMS Mendukung Bagaimana Tampilan Logis Data

2. Skema

Skema adalah deskripsi elemen-elemen data dalam database, hubungan diantara

mereka, dan model logika untuk mengelola dan menjelaskan data. Terdapat 3 level skema
yaitu konseptual, eksternal, dan internal.

a. Skema Konseptual (Conceptual-level Schema)

Tampilan secara luas, menggambarkan keseluruhan database, daftar semua elemen
data, dan hubungan/relasi diantara mereka.
b. Skema Level Eksternal (External-level Schema)
Tampilan individual pengguna terhadap bagian-bagian dalam database, masing-masing
mengacu pada sebuah subskema(subschema).
c. Skema Level Internal (Internal-Level Schema)
Tampilan level rendah database, menjelaskan bagaimana data disimpan dan diakses,
termasuk record layout, definisi, alamat, dan indeks.
DBMS menerjemahkan permintaan pengguna atau program (diekspresikan dalam
istilah nama logis, dan relasi) ke dalam alamat dan indeks yang dibutuhkan untuk
mengakses data secara fisik.

7
3. Kamus Data
Kamus data (data dictionary) berisi informasi mengenai database dimana setiap elemen
yang disimpan dalam data base terdapat catatan dalam kamus yang menjelaskannya.
DBMS menimpan kamus data yang inputnya termasuk elemen baru atau pun yang terhapus
serta mengubah elemen data, penjelasan, ataupun penggunaannya. Outputnya termasuk
laporan untuk pemrogram, desainer, dan pengguna seperti:
1. Program atau laporan yang menggunakan item data
2. Sinonim untuk elemen data dalam file
3. Elemen data yang digunakan oleh pengguna
Laporan-laporan ini digunakan dalam pendokumentasian system, desain, dan implementasi
database, serta sebagai bagian dari jejak audit. Contoh kamus data dapat dilihat di table 4-1.

4. Bahasa DBMS
DBMS memiliki beberapa bahasa:
a) Data Definition Language (DDL): membangun kamus data, membuat database,
menjelaskan tampilan logis setiap pengguna dan memerinccatatan atau hambatan
keamanan field.

8
 b) Data Manipulation Language (DML): mengubah isi database, termasuk membuat,
memperbaharui, menyisipkan, dan menghapus elemen data.
c) Data Query Language (DQL): bahasa level tinggi, seperti bahasa inggris yang
berisi perintah kuat dan mudah digunakan, yang memungkinkan pengguna untuk
mengambil, menyortir, memesan, serta menunjukan data.
Penulis Laporan (Report Writer) menyederhanakan pembuatan laporan. Pengguna
menentukan elemen-elemen data yang ingin dicetak, kemudian penulis laporan mencari
database, mengekstrak elemen data, dan mencetaknya dalam format yang ditentukan oleh
pengguna. DQL dan penulis laporan tersedia unntuk pengguna. DDL dan DML sebaiknya
dibatasi untuk otorisasi administrator dan pemrogram.

Database Relasional
DBMS digolongkan berdasarkan model data (data model) logis atau representasi abstrak
konten database. Model data rasional (rational data model) merepresentasikan skema level
konseptual dan eksternal (Tabel 4-2). Data benar-benar disimpan dalam table tetapi dengan
cara yang dijelaskan dalam skema level internal.
Setiap baris dalam table disebut tuple (atau couple) yang berisi data komponen spesifik
dalam database. Misalnya data mengenai item persediaan tertentu seperti deskripsi, warna,
dan harga atau baris dalam table data pelanggan tertentu yang memuat data atribut
pelanggan seperti nama dan alamat.

Tipe-Tipe Atribut
Atribut dapat dibedakan menjadi dua tipe yaitu:
1. Kunci Utama (Primary Key): atribut database atau kombinasi atribut yang secara
khusus mengidentifikasikan suatu baris tertentudalam sebuat table. Kunci utama
dalam table 4-2 adalah nomor komponen yang secara khusus mengidentifikasikan
setiap komponen barang yang dijual S&S. Biasanya kunci utama adalam atribut
tunggal.
Kuni Asing (Foreign Key): atribut dalam table yang juga merupakan kunci utama dalam
table lain dan digunakan untuk menghubungkan dua table.

9
Membuat Desain Database Relasional Untuk S&S, INC

Dalam sistem akuntansi manual, S&S akan mengambil informasi penjualan pada faktur
penjualan pracetak yang memberikan tampilan logis dan fisik data yang dikumpulkan.
Penyimpanan fisik data faktur penjualan adalah sederhana; Salinan faktur disimpan dalam
lemari file.

Menyimpan data yang sama dalam komputer lebih kompleks. Anggaplah S&S ingin
menyimpan faktur penjualan secara elektronik yang diberi nomor 101 s.d. 105. Pada
beberapa faktur, pelanggan membeli lebih dari satu komponen. Mari kita melihat dampak
beberapa cara untuk menyimpan informasi ini.

1. Menyimpan Semua Data dalam Satu Tabel yang Seragam

S&S dapat menyimpan data penjualan dalam satu tabel, seperti yang diilustrasikan
dalam tabel 4-3. Pendekatan ini memiliki dua kerugian. Pertama ia menyimpan
banyak kelebihan data. Oleh Karena ketiga barang persediaan terjual, data faktur dan
pelanggan dicatat tiga kali. Demikian juga, deskripsi persediaan dan unit harga
diulangi setiap kali barang terjual. Oleh Karena volume penjualan pada toko eceran
tinggi, beberapa kelebihan membuat pemeliharaan membutuhkan banyak waktu dan
rentan akan kesalahan (eror)
Kedua, beberapa masalah akan terjadi ketika data faktur yang disimpan tipe tipe tabel ini.
Masalah pertama disebut anomaly pembaruan (update anomaly), Karena nilai data tidak
diperbarui dengan benar. Mengubah alamat pelanggan melibatkan pencarian keseluruhan
tabel dan mengubah setiap kejadian dengan alamat pelanggan. Bahkan,

10
 melupakan satu baris akan menimbulkan inkonsistensi, Karena berbagai alamat akan
tersedia untuk satu pelanggan. Tindakan tersebut dapat menghasilkan penduplikasian
surat yang tidak dibutuhkan dan kesalahan-kesalahan lain. TABEL 4-3

Anomali sisipan (insert anomaly) yang terjadi dalam contoh kita dikarenakan tidak
adanya cara untuk menyimpan informasi mengenai pelanggan prospektif hingga
mereka membuat pembayaran. Jika data pelanggan prospektif dimasukkan sebelum
pembelian dibuat, kolom faktur penjualan akan menjadi kosong. Padahal, faktur
penjualan adalah kunci utama untuk tabel 4-3 dan tidak boleh kosong, karena secara
khusus akan mengidentifikasi catatan
Anomali penghapusan (delete anomaly) terjadi ketika menghapus baris yang tidak
memiliki konsekuensi yang tidak keinginkan. Contohnya, jika alamat pelanggan
disimpan dalam tabel penjualan, kemudian menghapus baris ketika hanya ada
penjualan ke pelanggan yang disimpan, akan menyebabkan hilangnya semua
informasi untuk pelanggan tersebut.
2. Memvariasikan Jumlah Kolom
Alternative untuk tabel 4-3 adalah dengan mencatat faktur penjualan dan data pelanggan
sekali dan menambahkan kolom tambahan untuk mencatat setiap item yang terjual. Tabel
4-4 mengilustrasikan pendekatan ini. Meskipun dapat mengurangi kelebihan data dan
mengelimniasi beberapa anomaly yang terkait dengan tabel 4-3, alternative ini memiliki
beberapa kelemahan. S&S akan memutuskan seberapa banyak jumlah item yang
meninggalkan ruang untuk setiap baris (contohnya seberapa banyak kolom yang
diletakkan dalam tabel; catatlah pada tabel 4-4 bahwa untuk menyimpan setiap item
tambahan membutuhkan lima kolom tambahan – Item, Kuantitas, Deskripsi, Unit Harga,
dan Jumlah Total). Jika ruang yang ditinggalkan empat item (20 kolom), bagaimana data
pengenai penjualan melibatkan delapan item (40 kolom) akan

11
 disimpan? Jika ruang yang ditinggalkan untuk delapan barang, akan menghemat
ruang yang kosong, begitu juga dengan kasus untuk faktur penjualan 103 dan 104
TABEL 4-4

Faktur Columns unit extended

Penjualan item # Quantity Description item #2 quantity2
2-3 price amount
#

101 Same 8 10 2 Television 499 998 50 1

102 columns 10 1 television 499 499 20 3
103 as in 50 2 microwave 449 898
104 Tabel 4-3 40 1 range 789 789
105 above 10 3 television 499 1497 20 1

3. Solusi : Seperangkat Tabel. Permasalahan penyimpanan dalam tabel 4-3 dan 4-4
diselesaikan menggunakan database relational. Seperangkat tabel dalam tabel 4-5
mempresentasikan database relational yang terstruktur dengan baik
TABEL 4-5

12
Persyaratan Dasar Database Relasional

Kita sekarang akan melihat pedoman yang digunakan untuk mengembangkan database
relational tersetruktur dengan tepat.

1. Setiap kolom dalam baris harus dinilai tunggal

Dalam database relational, hanya ada satu nilai per sel. Pada saat S&S, setiap
penjualan dapat melibatkan lebih dari satu item. Pada faktur 102, pelanggan membeli
televise, freezer dan kulkas. Jika item # adalah atribut pada tabel penjualan, akan
diambil tiga nilai (nomor 10,20, dan 30). Untuk menyelesaikan permasalahan ini, tabel
penjualannpersediaan dibuat yang mendaftar setiap barang yang dibeli pada faktur.
Lini ketiga dalam tabel penjualan persediaan dalam tabel 4-5 menunjukkan faktur 102
dan barang nomor 10(televisi). Lini keempat menunjukkan faktur 102 dan barang 20
(freezer) lini kelima menunjukkan faktur 102 dan barang 30(kulkas). Tabel ini
mengulangi jumlah faktur sesering yang dibutuhkan untuk menunjukkan semua
barang yang dibeli pada faktur penjualan.
2. Kunci utama tidak bisa nol
Kunci utama tidak bias secara khusus mengidentifikasi baris dalam tabel jika nilainya
nol (kosong). Kunci utama tidak nol memastikan bahwa setiap baris dalam tabel
menampilkan sesuatu dan dapat diidentifikasi. Ini mengacu pada aturan integritas
entitas. Dalam tabel penjualan persediaan pada tabel 4-5, tidak ada field tunggal yang
secara khusus mengidentifikasi setiap baris. Meski demikian, dua kolom pertama,
secara Bersama-sama, melakukan identifikasi setiap baris secara khusus dan
membuat kunci utama.
3. Kunci asing, jika bukan nol, harus memiliki nilai yang sesuai dengan nilai kunci utama
pada tabel lainnya

13
 Kunci asing menghubungkan baris pada satu tabel dengan baris pada tabel lain.
Pada tabel 4-5, pelanggan # dapat menghubungkan setiap transaksi penjualan
dengan pelanggan yang terlibat dalam kejadian hanya jika tabel penjuaan pelanggan
# sesuai dengan angka actual pelanggan pada tabel Pelanggan. Batasan ini yang
disebut aturan integritas referensial, memastikan konsistensi database kunci asing
dapat berisi nilai nol. Contohnya, ketika pelanggan membayar secara tunai,
pelanggan # dalam tabel penjualan dapat menjadi kosong
4. Semua atribut nonkunci dalam tabel harus menjelaskan karakteristik objek yang
diidentifikasi berdasarkan kunci utama
Sebagian besar tabel berisi atribut lain sebagai tambahan kunci utama dana sing.
Dalam tabel pelanggan di tabel 4-5 pelanggan # adalah kunci utama, dan nama
pelanggan, alamat, kota dan negara bagian adalah fakta penting yang menjelaskan
pelanggan.

Keempat kendala ini menghasilkan database yang tersetruktur dengan baik

(dinormalisasi yaitu datanya konsisten dan kelebihan data yang diminimalkan dan
dikendalikan. Pada tabel 4-5, terdapat tabel untuk setiap entitas yang menghindari
permasalahan anomaly seperti yang didiskusikan sebelumnya serta meminimalkan
kelebihan. Kelebihan tersebut tidak daieliminasi seperti komponen tertentu, misalnya
Faktur Penjualan #, tampak lebih dari satu tabel ketika mereka merupakan kunci
asing. Aturan integritas referensial memastikan bahwa tidak ada permasalahan
anomali pembaruan dengan kunci asing.
Ketika data tentang objek kepentingan disimpan dalam tabel database yang terpisah,
akan mudah untuk menambahkan data baru dengan menambahkan baris lain ke
tabel. Contohnya, menambahkan pelanggan baru adalah yang sederhana seperti
menambahkan baris baru ke tabel Pelanggan. Jadi, tabel yang digambarkan dalam
tabel 4-5 bebas dari anomaly sisipan.
Database relasional juga menyederhanakan penghapusan data. Menghapus faktur
penjualan 105, satu-satunya penjualan ke pelanggan 153, tidak menghapus semua
data mengenai pelanggan, karena disimpan dalam tabel Pelanggan. Tindakan ini
menghindari anomali penghapusan.
Keuntungsn lain dari skema yang ditunjukkan dalam tabel 4-5 adalah penggunaan
ruang secara efisien. Tabel penjualan-persediaan berisi baris setiap komponen yang
terjual dalam setiap faktur. Tidak ada baris yang kosong, semua data penjualan
dicatat. Sebaliknya, skema dalam tabel 4-4 menghasilkan ruang yang tidak terpakai

14
Dua Pendekatan Untuk Desain Database

Terdapat dua cara dasar untuk mendesain database relasional yang terstruktur dengan baik,
Salah satunya dinamakan normalisasi, yang dimulai dengan asumsi bahwa semua data pada
awalnya disimpan dalam satu tabel besar. Pendekatan ini kemudian diikuti dengan serangkaian
peraturan untuk memisah-misahkan tabel awal tadi menjadi serangkaian tabel yang
dinormalisasi. Tujuannya adalah menghasilkan serangkaian tabel yang dapat dikategorikan
sebagai bentuk normal ketiga (third normal form-3NF), karena tabel-tabel seperti ini bebas dari
masalah anomali pembaruan, penyisipan, serta penghapusan.

15
Normalisasi adalah Teknik atau pendekatan yang digunakan dalam membangun disain
database relasional melalui himpunan data dengan tingkat ketergantungan fungsional dan
keterkaitan yang tinggi sehingga menghasilkan struktur tabel yang normal.

Tujuan normalisasi:

• Minimalisasi redundansi (pengulangan data)

• Memudahkan identifikasi entitas

• Mencegah terjadinya anomali

Cara alternatif untuk mendesain database relasional yang terstruktur dengan baik adalah
dengan menggunakan pembuatan model data semantik. Dalam pendekatan ini, desainer
database menggunakan pengetahuan mereka mengenai bagaimana proses bisnis biasanya
berlangsung dan mengenai kebutuhan informasi yang berhubungan dengan proses
transaksi, untuk membuat gambar grafis mengenai hal-ha1 yang seharusnya dimasukkan
dalam database yang didesainnya. Gambar yang dihasilkan kemudian dapat langsung
digunakan untuk membuat serangkaian tabel relasional yang termasuk dalam kategori 3NF.

Pembuatan model data semantik memiliki dua kelebihan utama daripada membangun
database hanya dengan mengikuti peraturan-peraturan proses normalisasi. Pertama, cara
ini memfasilitasi desain yang efisien atas database proses transaksi, karena cara ini
mempergunakan pengetahuan desainer sistem mengenai proses dan kegiatan bisnis.
Kedua, cara ini memfasilitasi komunikasi dengan para calon pemakai sistem tersebut,
karena model grafis yang dihasilkan secara eksplisit mewakili informasi mengenai proses
bisnis dan kebijakan organisasi. Komunikasi semacam ini sangat penting untuk memastikan
bahwa sistem yang dihasilkan sesuai dengan kebutuhan para pemakai yang sebenarnya.
Tulisan berikutnya akan memperkenalkan dua alat untuk membuat model data semantik
yang dapat digunakan oleh akuntan dan profesional sistem bisnis dalam mendesain
database proses transaksi, yaitu yang dinamakan diagram hubungan-entitas (entity
-relationship-E-R) dan model data REA.

Membuat Query Database Relasional

Untuk mengambil data yang disimpan, pengguna akan menanyai database. Bagian dari bab
ini menunjukkan bagaimana untuk menanyai database menggunakan Microsoft Access. Jika
anda ingin mengikuti berdasarkan membuat pertanyaan yang diilustrasikan dalam bagian ini,
unduh S&S In Chapter Database dari situs teks. Ketika anda membuka database dan
memilih pita “Create”, pita dalam bagian atas Tabel 4-6 akan terlihat. Ada dua cara untuk
menanyai database: membuat pertanyaan (query) dalam tampilan Desain (tombol “Query

16
Design”) atau menggunakan wizard (tombol “Query Wizard”). Opsi-opsi tersebut di-outline
dengan warna hitam pada bagian atas Tabel 4-6. Tampilan Desain digunakan dalam semua
contoh yang ditunjukkan. Mengeklik tombol “Query Design” memunculkan jendela Show
Table yang ditunjukkan pada Tabel 4-6. Pengguna dapat memilih tabel yang diperlukan
untuk menghasilkan informasi yang diinginkan; jika lebih banyak tabel dibandingkan yang
seharusnya dipilih, query mungkin tidak akan berjalan dengan semestinya.

17
QUERY 1

Query 1 menjawab dua pertanyaan : Berapa nomor faktur yang dibuat untuk semua
penjualan yang dibuat untuk D.Ainge dan siapa tenaga penjual untuk setiap penjualan?

Table Penjualan dan Pelanggan berisi tiga komponen yang diperlukan untuk
menjawab pertanyaan ini : Faktur Penjualan #, Tenaga Penjual dan Nama Pelanggan, Klik
tombol “Query Design” dan pilih table Penjualan dan Pelanggan dengan mengklik ganda
pada nama mereka atau mengkiktunggal pada nama mereka dan mengklik tombol Add.
Garis antara dua table menghubungkan field Pelanggan # (kunci utama table Pelanggan dan
kunci asing table penjualan). Klik pada close untuk menutup jendela show table.

Untuk menambahkan data pada bagian bawah layar, klik dua kali pada Faktur
Penjualan #, Tenaga Penjual, dan Pelanggan atau tarik dan letakkan mereka ked ala baris
field. Access secara tmatis mengecek ktak dalam garis Shw, sehingga item-item akan
ditunjukan ketika query dijalankan.

Oleh karena kita hanya menginginkan penjuan ke D,Ainge , masukkan penjualan ke dalam garis
criteria untuk kolom Nama Pelanggan . Access akan secara otomatis meletakkan tanda Tanya di
antara criteria. Jalankan query dengan mengklik pada tanda merah!(tanda seru) pada pita Query
Tool Design . Jawaban query tidak secara otomatis memiliki judul “Penjualan Ainge”. Untuk
memberikan query sebuah nama, simpanlah dengan memilih File dari menu access, kemudian
Save As , dan masukkan “Penjualan Ainge” dalam baris pertama jendela Save As , pastikan
bahwa kotak pilihan bject diset untuk “Query”, dan kemudian klik OK.

18
19
QUERY 2

Query 2 menjawab pertanyaan ini: Berapa banyak televisi yang terjual bulan oktober?.
Table Penjualan , Persediaan dan Penjualan-Persediaan berisi tiga item yang dibutuhkan untuk
menjawab pertanyaan ini : Tanggal, Deskripsi Persediaan, dan Kuantitas. Klik pada tombol query
design dalam pita create serta memilih tiga table dan tiga field. oleh karena kita menginginkan
kuantitas televisi yang terjual pada bulan oktober, tambahkan criteria between #10/1/2018# and
#10/31/2018 ke field Tanggal dan Televisi ke field Deskripsi.

Untuk merinci criteria, access menggunakan peratr seperti “And” “Or”dan “Between”.
Oleh karena kita hanya mencari total televise pada bulan oktober maka kita perlu
menunjukkan Tanggal atau Deskripsi. Jangan mencentang kotak “shw” pada klm Tanggal
dan Deskripsi. Untuk membuat total penjualan, klik tombol “total” dalam bagian show/hide
pada pita query tl design. Klik pada garis ttal di klm kuantitas, kik pada imbl panah-bawah,
dan pilih jumlah (sum) dari menu turun-kebawah yang nampak. Dua field sisa dalam garis
ttal aka nada sebagai grup by.

20
QUERY 3

Query 3 menjawab pertanyaan ini: Siapa nama dan di mana alamat pelanggan yang
membeli televisi pada bulan Oktober?

Query ini memerlukan beberapa field berikut: Tanggal (untuk memilih penjualan pada bulan
Oktober), Dekripsi (untuk memilih televisi), serta Nama Pelanggan, Jalan, Kota. dan Negara
Bagian (informasi yang diminta). Keempat tabel ini digunakan karena tabeI Penjualan-
Persediaan digunakan untuk memindahkan antara tabel Penjualan dan Persediaan. Query
ini mengunakan kriteria yang sarna pada Query 2. Data Tanggal dan Deskripsi tidak perlu
ditampilkan, sehingga kotak dalam baris Show tidak dicentang. Menjalankan query
menghasilkan jawaban yang ditunjukkan dalam tabel 4-10

QUERY 4

Query 4 menjawab pertanyaan ini: Berapa nomor aktur penjualan, tanggal, dan total faktur
untuk penjualan bulan oktober, yang diatur dalam urutan berdasarkan jumlah total ?

Dikarenakan database tidak berisi kolom Total faktur, maka total faktur dihitung dengan
mengalikan unit harga berdasarkan kuantitas untuk setiap penjualan.

21
Query 4 memerlukan tabel penjualan (Tanggal, Faktur penjualan), Tabel penjualan persediaan
(Kuantitas), dan tabel Persediaan (Unit Harga). Namun, beberapa field tidak akan tampak dalam
kolom pada jendela select query. Seperti yang ditunjukkan dalam pada 4-11, tiga kolom
ditampilkan: Faktur penjualan, tanggal dan Total Faktur, yang akan kita hitung. Pada field lainnya,
Kuantitas dan Unit Harga, digunakan dalam perhitungan total faktur.

Untuk menghitung Total Faktur, ketiklah “Total Faktur”: dalam sel kosong pertama Field, klik
kanan dalam sel, dan pilih Build dari menu pop up yang tampak. Jendela expresion Builder
(lihat tabel 4-12) akan muncul, tempat formula untuk menghitung Total Faktur dimasukkan
dengan mengetik “Sum()”. Antara tanda kurung, klik tanda + di depan dalam folder S&S In
Chapter Database pada kotak Expresion Elements. Kemudian klik tanda pada tanda + di
folder Tabel yang akan memunculkan empat tabel database. Klik pada table Penjualan-
Persedian, dan field pada tabel Penjualan-Persediaan muncul. Klik dua kali pada Kuantitas
untuk meletakkan field ini pada expression. Catatlah bahwa pada Tabel 4-12 expression
menunjukkan nama tabel dan nama field, yang dipisahkan dengan tanda seru. Untuk
mengalikan Kuantitas berdasarkan Unit Harga, ketiklah * (simbol perkalian) kemudian pilih
tabel Persediaan dan field Unit Harga. Formulanya sekarang lengkap, dan layar akan
tampak seperti yang ditunjukkan. Untuk memasukkan expression ke dalam jendela select
question, Klik OK.

22
Untuk melengkapi Query 4, klik pada tombol Total pada pita Query Tools Design. Klik pada
panah di bawah baris Total pada kolom Total Faktur, dan pilihlah Expression dari menu pop
up. Tindakan tersebut memberitahu Access untuk menghitung expression untuk semua item
dengan angka dan tanggal faktur penjualan. Pada kolom yang sama, klik lah pada panah di
bawah pada baris sort, dan pilihlah Descending sehingga jawaban ditunjukkan dalam Total
Faktur. Pada bagian kriteria dalam kolom Tanggal, gunakan operator “Between” untuk
memerinci bulan Oktober. Menjalankan Query 4 menghasilkan jawaban dalam Tabel 4-11.

QUERY 5

Query 5 akan menjawab pertanyaan berikut ini : Berapakah total penjualan berdasarkan
tenaga penjual?

Pertanyaan ini sama dengan Query 4, kecuali jika kita menjumlah faktur berdasarkan tenaga
penjual, bukan berdasarkan nomor faktur. Kita juga tidak membatasi query untuk bulan
Oktober. Query dan jawaban lengkap ditunjukkan dalam Tabel 4-13

23
Sistem Database Dan Masa Depan Akuntansi

Sistem database memiliki potensi untuk mengganti pelaporan secara eksternal. Waktu dan
usaha yang dapat dipertimbangkan baru-baru ini diinvestasikan dalam mendefinisikan
bagaimana perusahaan dapat meringkas dan melaporkan informasi akuntansi ke pengguna
eksternal.

Di masa depan, perusahaan dapat membuat salinan database keuangan perusahaan yang
tersedia untuk pengguna eksternal laporan keuangan tradisional. Pengguna akan bebas
untuk menganalisis data mentah kapan pun mereka cocok.

Keuntungan signifikan dari sistem database adalah kemampuan dalam membuat query ad
hoc untk menyediakan informasi yang dibutuhkan pada pembuatan keputusan. Bahasa dari
database relasional yang kuat dan mudah untuk digunakan dapat menemukan serta
mempersiapkan kebutuhan informasi manajemen kapan pun mereka menginginkannya.

DBMS relasioanal dapat menampung berbagai pandangan fenomena mendasar yang sama.
DBMS relasional juga dapat mengintegrasikan data keuangan dan operasional. Selain itu
DBMS memiliki potensi untuk meningkatkan penggunaan dan nilai informasi akuntansi.

Para akuntan harus memahami sistem informasi sehingga dapat membantu mereka
mendesain dan menggunakan SIA di masa depan.

24
 DAFTAR PUSTAKA

Romney, Marshall B. & Paul John Steinbart. 2016. Sistem Informasi Akuntansi: Edisi 13.
Jakarta: Salemba Empat.

http://dahtaoe.blogspot.co.id/2016/10/sistem-informasi-akuntansi-database.html
diakses pada 10 September 2017.

http://dianayun30207013.blogspot.co.id/2011/01/pengertian-sistem-manajemen-basis-
data.html diakses pada 10 September 2017.

https://imammagribi.wordpress.com/2011/09/29/database/ diakses pada 10 September

2017.

25