Makalah ini membahas sistem manajemen basis data. Ia menjelaskan pendekatan basis data yang menyimpan semua data perusahaan secara tersentralisasi untuk menghindari redundansi data dan memudahkan akses serta pembaruan informasi. Sistem manajemen basis data berperan mengelola akses pengguna berdasarkan hak aksesnya untuk menjaga kerahasiaan data. Makalah ini juga membahas bahasa yang digunakan untuk mendefinisikan, memanipulasi, dan men
TUGAS SIM, LISANIAH AMINI LISA'ILINA, YANANTO MIHADI PUTRA, SISTEM MANAJEMEN BASIS DATA, 2018
1. Sistem Manajemen Basis Data
Disusun untuk memenuhi tugas mata kuliah “Sistem Informasi Manajemen”
Dosen pengampu : Yananto Mihadi Putra, SE, M.Si
Oleh :
Lisaniah Amini Lisa’Ilina (43217110150)
S1 AKUNTANSI
FAKULTAS EKONOMI DAN BISNIS
UNIVERSITAS MERCU BUANA
2018
2. Latar Belakang
Sistem manajemen basis data mengorganisasikan volume data dalam jumlah besar yang
digunakan oleh perusahaan dalam transaksi-transaksinya sehari-hari. Data harus
diorganisasikan sehingga para manajer dapat menemukan data tertentu dengan mudah dan
cepat untuk mengambil keputusan. Perusahaan memecah keseluruhan koleksi data menjadi
sekumpulan tabel data yang saling berhubungan, kumpulan-kumpulan kecil data yang saling
terhubung ini akan mengurangi pengulangan data sehingga pada akhirnya konsistensi dan
akurasi data makan meningkat.
Dewasa ini sebagian besar perusahaan menggunakan basis data yang mengikuti suatu
struktur relasional. Dua alasan penting di balik penggunaan struktur ini adalah bahwa struktur
basis data relasional mudah untuk digunakan dan hubungan di antara tabel di dalam struktur
bersifat implisit. Kemudahan penggunaan telah memberanikan banyak manajer untuk menjadi
pengguna langsung dan sumber basis data.
Meningkatnya arti penting basis data sebagai sumber daya yang mendukung
pengambilan keputusan telah mengharuskan para manajer mempelajari lebih jauh perancangan
penggunaan basis data. Dalam makalah ini penulis akan mencoba memaparkan mengenai
bagaimana sistem manajemen basis data.
Yang menjadi penyebab utama dari masalah-masalah manajemen data penting dalam tiga
bidang:
penyimpanan data (data storage),
pembaruan data (data updaring), dan
kekinian informasi (currency of information).
Penyimpanan Data
Dalam lingkungan file datar, hal ini tidak mungkin terjadi. Untuk memenuhi
kebutuhan data khusus dari pengguna, organisasi harus mengeluarkan biaya untuk
prosedur pengumpulan majemuk dan untuk prosedur penyimpanan majemuk. Beberapa
data yg umum digunakan bias diduplikasi lusinan kali, ratusan kali, atau bahkan ribuan
kali, sehingga biaya penyimpanan datanya menjadi sangat tinggi.
Pembaruan Data
Organisasi memiliki banyak sekali data yg disimpan dalam file induk dan file
referensi yg memerlukan pembauran berkala agar mencerminkan perubahan
operasional dan ekonomi. Jadi para pengguna sistem informasi memiliki file yg
3. terpisah, setiap perubahan harus dilakukan secara terpisah untuk setiap pengguna. Ini
tentunya akan menambah biaya manajemen data secara signifikan.
Kekinian Informasi
Kebalikan dari masalah pembauran data majemuk adalah masalah gagalnya
memperbarui semua file penggunaan yg di pengaruhi oleh perubahan data tertentu. Jika
pesan pembauran ini tidak disebarkan dengan benar, sebagian pengguna mungkin tidak
mencatat perubahan tersebut, dan kemudian akan melakukan pekerjaan dan mengambil
keputusan berdasarkan data yg sudah usang.
Ketergantungan Tugas Data
Masalah lainnya dengan pendekatan file datar adalah ketidakmampuan pengguna
untuk mendapatkan informasi tambahan ketika kebutuhannya berubah.Masalah ini
disebut ketergantungan tugas-data .
Pendekatan Basis Data
Figur 9-2 (a) menyajikan ulasan sederhana tentang pendekatan basis data dengan
pengguna dan keperluanm data yg sama seperti dalam Figur 9-1.Perubahan paling jelas
dari model file datar adalah pengelompokkan data menjjadi sebuah basis data umum yg
dapat digunakan secara bersama oleh semua pengguna sistem informasi.
Penyelesaian Masalah File Datar
Penggunaan data secara bersama-sama (tidak adanya kepemilikan data) merupakan
konsep utama dari pendekatan basis data. Masalah –masalah ini akan di atasi.
Gambar 9-2(a) Konsep Database
Tidak ada redundasi data. Setiap elemen data disimpan hanya sekali sehingga
menghilangkan redundansi data dan mengurangi biaya penyimpanan data.
Program 1
A, B, C, X, Y,
L, M
Program 2
Program 3
Transaksi Pemakai 1
Transaksi Pemakai 2
Transaksi Pemakai 3
4. Satu kali pembauran data. Karena setiap elemen data hanya terdapat pada satu tempat,
dibutuhkan hanya satu kali pembauran data. Ini tentu mengurangi waktu dan biaya
untuk menjaga kekinian data.
Nilai kekinian data. Perubahan terhadap basis data yg dilakukan oleh seorang
pengguna akan berlaku bagi semua pengguna.
Interdependensi tugas-data. Pengguna memilik akses sepenuhnya ke data yg ada di
perusahaan. Kebutuhan informasi seorang pengguna bisa meluas diluar wilayah
langsung pekerjaannya, namun kebutuhan ini dapat dengan segera dipenuhi dengan
pendekata file datar. Para pengguna hanya dibatasi oleh keterbatasan data yg di
sediakan oleh organisasi dan legitimasi yg diperlukan untuk mengakses data tersebut
Pengendalian Akses Basis Data
Pendekatan basis data menempatkan semua informasi dalam satu keranjang. Oleh
sebab itu, keranjang ini perlu di jaga dengan baik. Contoh dalam Figur 9-2 (a) tidak
memiliki ketentuan untuk mengendalikan akses ke basis data. Asumsikan Data X itu
merupakan informasi yang sensitif dan rahasia dan hanya Pemakai 3 yang diberi
otorisasi untuk mengaksesnya. Bagaimana organisasi dapat mencegah pemakai lain
untuk mendapatkan akses yang tidak sah terhadap informasi tersebut?
Gambar 9-2(b) Konsep Database
Sistem Manajemen Basis Data
Yang berada diantara program pengguna dan basis data fisik adalah sistem
manajemen basis data (database management system-DBMS). Tujuan DBMS adalah
untuk menyediakan pengendalian akses terhadap basis data. DBMS merupakan sistem
peranti lunak khusus yg di program untuk mengetahui elemen data mana yg bias diakses
oleh pengguna. Program pengguna mengirimkan permintaan data kepada DBMS, yg
mengesahkan dan mengotorisasi akses ke basis data, sesuai dengan tingkat otoritas
Program 1
D
B
M
S
Program 2
Program 3
Transaksi Pemakai 1
Transaksi Pemakai 2
Transaksi Pemakai 3
A, B, C,
X, Y, L, M
5. pengguna. Jika pengguna meminta data yg dia tidak punya otoritasnya, permintaan itu
akan ditolak. Jadi, prosedur untuk menetapkan otoritas pengguna sistem informasi di
dalam sebuah organisasi merupakan masalh pengendalian penting yg harus
diperhatikan oleh seorang akuntan.
Tiga Model Konseptual
Pendekatan basis data yg paling umum digunakan oleh sistem informasi bisnis
adalah model hierarkis (hierarchical model), model jaringan (network model), dan
model relasional (relational model). Karena kemiripan konseptual tertentu, basis data
hierarkis dan jaringan disebut model navigasional (navigational model) atau terstruktur
(structured model). Cara data di atur dalam sistem basis data awal ini mendorong para
pengguna untuk menjelajahi di antara elemen-elemen data dengan menggunakan jalur-
jalur yg sudah terstruktur.Model relasional jauh lebih fleksibel karena memung-kinkan
para pemakainya menciptakan jalur yang baru dan unik melalui database untuk
memecahkan masalah-masalah bisnis yang lebih luas cakupannya.
Elemen Lingkungan Basis Data
Gambar 9-3 menampilkan rincian lingkungan database dalam empat elemen utama:
pemakai, DBMS, administrator database, dan database fisik.
Pengguna
Pengguna mengakses basis data dalam dua cara. Pertama, akses tersebut dapat
dicapai melalui program-program pengguna yg disiapkan oleh professional sistem.
Program-program pengguna mengirim permintaan akses data (panggilan) ke DBMS,
yg mengesahkan permintaan tersebut dan mengambil data untuk diproses. Dengan cara
akses seperti ini, kehadiran DBMS menjadi transparan bagi para pengguna. Metode
kedua untuk akses basis data adalah melalui permintaan langsung, yg tidak memerlukan
program-program formal dari pengguna.
Sistem Manajemen Basis Data
DBMS menyediakan lingkungan yg terkendali untuk membantu (atau mencegah)
pengguna mengakses basis data dan untuk secara efisien mengelola sumber daya data.
Gambar 9-3. Elemen-elemen Konsep Database
6. Setiap model DBMS mencapai tujuan ini dengan cara yg berbeda, tetapi ada
beberapa ciri yg umum, di antaranya:
1. Pengembangan program. DBMS berisi perangkat lunak pengembangan aplikasi.
2. Backup dan pemulihan. Selama pemrosesan, DBMS secara periodik membuat file-
file backup untuk database fisik.
3. Penggunaan database untuk pelaporan. Fitur ini mencatat data statistik tentang
data-data yang sedang digunakan, dan siapa yang menggunakannya.
4. Akses database. Fitur yang paling penting dari DBMS adalah mengizinkan pe-
makai yang memiliki otorisasi untuk mengakses database. Gambar 9-3 menun-
jukkan tiga modul perangkat lunak, antara lain:bahasa definisi data (DDL-data
definition language), bahasa manipulasi data (DML-data manipulation language)
dan bahasa query (QL-query language).
Bahasa Definisi Data
Bahasa Definisi Data (DDL-Data Definition Language) adalah sebuah
bahasa program yang digunakan untuk mendefinisikan database fisik ke
DBMS. Terdapat tiga tingkat, disebut sudut pandang (view), dalam definisi
ini: sudut pandang internal, sudut pandang konseptual (skema), dan sudut
Aplikasi
Pengguna
Proses
Pengembangan
Sistem
Program
Pengguna
Program
Pengguna
Program
Pengguna
Program
Pengguna
Database
Fisik
Sistem
operassi
H0st
Bahasa Difinisi
Data (DDL)
Bahasa
Manipulasi
Data (DML)
Bahasa Query
Administrator
Database
Transaksi
Transaksi
Transaksi
Transaksi
DBMS
PerimintaanSistem
7. pandang pemakai (subskema).
Tampilan Internal. Tampilan internal (internal view)menyajikan
pengaturan record secara fisik dalam basis data. lni merupakan penyajian
tingkat paling rendah, di mana satu langkah dipindahkan dari database fisik.
Sudut pandang internal ini menjelaskan struktur record, hubungan di antara
mereka, dan pengaturan fisik serta urutan record dalam satu file.
Tampilan Konseptual (Skema). Tampilan konseptual atau skema
menyajikan basis data secara logika dan secara abstrak, bukan bagaimana
database itu secara fisik disimpan. Sudut pandang ini memungkinkan prog-
ram-program pemakai untuk memanggil data tanpa mengetahui atau tanpa
perlu menspesifikasi bagaimana data-data itu diatur atau kapan mereka di-
simpan dalam database fisik.
Tampilan Pengguna (Subskema). Tampilan Pengguna(user
view)mendefinisikan bagaimana seorang pemakai tertentu melihat
database. lni adalah bagian dari database di mana seorang pemakai
individual memiliki oto-risasi untuk mengaksesnya.
Operasi DBMS. Untuk mengilustrasikan peran dari tampilan ini, lihat
urutan peristiwa yang biasanya terjadi dalam mengakses melalui DBMS.
Penjelasan berikut ini sifatnya hipotesis teknis tertentu dihilangkan.
1. Program pengguna mengirimkan permintaan (memanggil) data yang
terdapat dalam DBMS. Panggilan ini tertulis dalam bahasa manipulasi data
khusus (akan dibahas nanti) yang melekat dalam program pengguna
tersebut.
2. DBMS menganalisis permintaan itu dengan mencocokkan elemn – elemen
data yang dipanggil dengan tampilan pengguna dan tampilan konseptual.
Jika permintaan data itu cocok, akan diotorisasi dan langkah pemrosesan
maju ke Langkah 3. Jika tidak cocok dengan tampilan ini, akses data itu
ditolak.
3. DBMS menetukan parameter – parameter struktur data dari tampilan
internal dan mengirimkannya ke system operasiyang melakukan
pengambilan data actual. Parameter struktur data tersebut mendeskripsikan
organisasi dan metode akses (Access method) yaitu program utilitas system
operassi, untuk mengambil data yang diminta.
8. 4. Dengan menggunakan mettode akses yang tepat, system operasi
berinteraksi dengan peralatan penyimpanan disket untuk mengambil data
dari basis data fisik.
5. Sistem operasi kemudian menyimpan data itu dalam memori utama di atas
penyangga (buffer area) yang dikelola oleh DBMS.
6. DBMS mentransferr data tersebut ke lokasi kerja pengguna yang terdapat
dalam memori utama. Pada saat ini, program pengguna bebass mengakses
dan memanipulasi data.
7. Ketika pemrosesan selesai. Langkah 4, 5 dan 6, dibalik untuk menyimpan
kembali data yang sudah diproses ke basis data.
Bahasa Manipulasi Data
Bahasa manipulasii data (data manipulation language-DML) adalah
bahasa pemrograman kepemilikan (proprietary) yang digunakan oleh DBMS
tertentu untuk mengambil, memproses, dan menyimpan data. Keseluruhan
program data dapat ditulisdalam DML atau dengan cara lain, perrintah
perintah dari DML terpilih dapat disisipkan ke dalam program – program
yang tertulis dengan ahasa universal, seperti PL/1 COBOL, dan FORTRAN.
Penyisipan perrintah – perintah DML memungkinkan program – program
standar yang pada awalnya ditulis untuk lingkunga file datar, diubah dengan
mudah ke lingkungan basis data. Penggunaan progam – program bahasa
standar juga membuat organisasi tidak bergantung pada pemasok tertentu.
Jika organisasi itu memutuskan untuk mengganti pemasoknya ke pemasok
lain yang DML-nya berbeda, organisasi itu tidak perlu menulis ulang semua
program pengguna. Dengan mengganti perintah – perintah DML yang lama
dengan perinta baru, program – program pengguna dapat dimodofikasi agar
berfungsi di lingkungan yang baru.
Bahasa Permintaan Data
Kemampuan query DBMS memungkinkan pengguna akhir dan
pemrogram professional untuk mengakses data dalam basis data secara
langsung tanpa memerrlukan program konvesional. Bahasa permintaan
terstruktur (structured query language-SQL, diucapkan sequel) dari IBM
telah menjadi bahasa query standar untuk DBMS mainframe dan
mikrokomuter. SQL merupakan bahsa generasi ke empat dan bahasa non
9. procedural dengan banyak perintah yang memungkinkan pengguna untuk
memasukkan , mengambil dan memodifikasi data dengan mudah. Peirntah
SELECT merupakan alat yang sangat berguna untuk mengambil data.
Contoh dalam figure 9-5 menggambarkan penggunaan perintah SELECT
untuk menghasilkan laporan pengguna dari basis data yang disebut
perseidaan.
SQL merupakan alat pemrosesan data yang efisien. Walaupun bukan
bahasa Inggris yang alami, SQL hanya memerlukan sedikit latihan mengenai
konsep computer dan lebih sedikit pemrograman daripada bahasa – bahasa
lainnya. Bahkan, banyak system query basis data tidak memerlukan
pengettahuan SQL sama sekali. Para pengguna memilih data secara visual
dengan “menunjuk dan mengklik” atribut yang diinginkan. Kemudian, alat
penghubung visual pengguna menghasilkan perintah – perintah SQL yang
diperlukan secara otomatis. Fitur ini menempatkan pelaporan khusus (ad
hoc) dan kapabilitas perosesan data berada di tangan pengguna/manajer.
Dengan mengurangi ketergantungan terhadap pemrograman professional,
para manajer dapat mengatasi masalah yang tiba – tiba muncul.
Administrator Basis Data
Lihat figur 9-3 dan perhatikan posisi administrati dari administrator basis data
(database administrator-DBA). Posisi inti tidak ada dala lingkungan file datar. DBA
bertanggung jawab untuk mengelola sumber daya basis data. Penggunaan basis data
secara bersama – sama oleh banyak pengguna memerlukan koordinasi, peraturan, dan
petunjuk untuk melindungi integritas basis data.
Diorganisasi besar, fungsi DBA mungkin terdiri atas seluruh anggota departemen
personalia teknik yang berada di bawah tanggung jawab seorang administrator basis
data. Di organisasi yang lebih kecil, ttanggung jawab DBA terletak di tangan seseorang
yang berada dalam kelompok layanan komputer. Tugas – tugas seorang DBA meliputi
wilayah berikut ini : perencanaan basis data, desain basis data, implementasi basis data,
operasi dan pemeliharaan basis data, serta perubahan da pertumbuhan basis data. Tabel
9-1 menyajikan perincian tugas –tugas spesifik yang ada dalam wilayah – wilayah
pekerjaan tersebut.
Tabel 9-1 Fungsi – fungsi Administrator Basis Data
Perencanaan Basis Data : Implementasi :
10. Mengembangkan strategi basis data
organisasi
Mendefinisikan lingkungan basis
data
Mendefinisikan persyaratan dana
Mengembangkan kamus data
Menentukan kebijakan akses
Mengimplementasikan proposal
pengendali keamanan
Menentukan prosedur pengujian
Menetapkan standar pemrograman
Desain : Operasi dan Pemeliharaan :
Basis data logis (skema)
Tampilan pengguna eksternal
(subskema)
Pengendali basis data
Mengevaluas kinerja basis data
Menyusun ulang basis data sesuai
dengan kebutuhan pengguna
Meninjau kembali standard an prosedur
Perubahan dan Pertumbuhan :
Merencanakan perubahan dan
pertumbuhan
Mengevaluasi teknologi baru
Interaksi Organisasional Dari DBA
Figur 9-6 menunjukkan beberapa antarmuka organisasi dari DBA. Secara
khusus, yang penting dilihat disisi adalah relasi antara DBA, pengguna akhir,
dan para professional system di organisasi. Lihat figure 9-3 selama
mempelajari relasi ini
Gambar 9-6 Interaksi Organisasi dari Administrasi Database
Manajemen
Pemakai Akhir Administrator Basis
Data
Database
Kegiatan
Operasi
Profesional
Sistem
11. Ketika kebutuhan informasi meningkat para pengguna mengirimkan
perrmintaan formal untuk aplikasi komputer kepada para rofesional system
(pemrogram) organisasi. Permintaan ini ditangani melalui prosedur
pengembangan system formal, yang menghasilkan aplikasi terrprogram.
Figue 9-3 menunjukkan relasi ini ketika garis dari kotak pengguna mengalir
ke DBA, yang mengevaluasinya untuk menentukan kebutuhan basis data
pengguna. Setelah relasi ini terbentuk, DBA memberikan otoritas akses
kepada pengguna dengan memprogram tampilan pengguna (subskema).
Relasi ini ditunjukkan ketika garis – gariss antara pengguna dan DBA, dan
antara DBA dan modul DDL berada di kotak DBMS. Dengan tetap menjaga
otoritas akses terpisah dari pengembangan system (pemrograman aplikasi),
organisasi tersebut lebih mampu mengendalikan dan melindungi basis
datanya. Usaha yang dilakukan secara sengaja atau tidak sengaja untuk
mengakses tanpa otoritas yang sah kemungkinan besar akan ditemukan jika
kedua kelompok ini bekerja secara independen. Rasionalisasi untuk
pemisahan pekerjaan ini dijelaskan Bab 15.
Kamus Data
Fungsi penting lainnya dari DBA adalah penciptaan dan pemeliharaan
kamus data (data dictionary). Kamus data menjelaskan setiap elemen data
yang terdapat dala basis data. Fungsi ini memungkinkan semua pengguna (dan
pemrogram) untuk berrbagi tampilan yg sama terhadap sumber daya data
sehinggga sangat membantu dalam menganalisis kebutuhan pengguna.
Basis Data Fisik
Elemen keempat dari pendekatan basis data yang ditampilaan dalam figur 9-3
adalah basis data fisik . Pendekatan ini merupakan tingkat terendah daari basis data.
Basis data fisik tersusun dar titik – titik magnetis pada disket magnetis. Tingkat basis
data lainnya (tampilan pengguna, tampilan konseptual, dan tampilan internal)
merupakan representasi abstrak dari tingka fisik.
Ditingkat fisik, basis data merrupakan kumpulan record dan file. Basis data
relasional didasarkan pada struktur file berurutan berindeks. Struktur ini ditampilkan
dalam figur 9-7, menggunakan sebuah indeks ang berhubungan dengan organisasi file
berurutan . Struktur ini memfasilitasi akses langsung ke record individual dan
pemrosesan batch untuk seluruh file. Indeks ganda dapat digunakan untuk menciptakan
referensi silang, yang disebut daftar terbalik , yang semakin meningkatkan fleksibilitas
13. Dibagian ini akan dibahas konsep – konsep dasar, terminology, dan teknik yang
umum pada sistem basis data relasional. Blok ini kemudian akan digunakan dalam bab
ini untuk mendesain basis data kecil mulai dari awal.
Gambar 9-8. Tabel Relasional yang Diberi Nama Pelanggan
Entitas, Pemunculan dan Atribut
Entitas adalah segala sesuatu yang digunakan oleh organisasi untuk
mengangkap data. Entitas bias bersifat fisik, seperti persediaan, pelanggan,
atau karyawan. Entitas juga bias bersifat konseptual, seperti penjualan (ke
pelanggan), piutang usaha atau utang usaha. Desainer sistem
mengidentifikasi entitas dan menyiapkan model seperti yang ditunjukkan
dalam figure 9-10. Model data ini adalah cetak biru untuk menciptakan basis
data fisik.
Gambar 9-9. Fungsi Aljabar Relasional – Terbatas, Proyek dan Gabungan
No. Pelanggan
(Kunci)
Nama Alamat Saldo Saat Ini
1875 J. Smith 18 Elm St. 1820,00
1876 G. Adams 21 First St. 2400,00
1943 J. Hobbs 165 High St. 549,87
2345 Y. Martin 321 Barclay 5256,76
. . . .
. . . .
. . . .
5678 T. Stem 432 Main St. 643,67
Artibut
Nama Tabel = Pelanggan
Tuples
(records)
(a) Terbatas (a) Proyek
(c) Gabungan
14. Representasi grafis yang digunakan untuk
mencerrminkan model ini disebut diagram relasi entitas (entity relationship
ER). Dalam ketentuan umumnya, setiap entitas dalam model data diberikan
nama dalam bentuk kata benda tunggal. Seperti pelanggan, bukan pelanggan
– pelanggan. Istilah pemunculan (occurance) digunakan untuk
mendeskripsikan jumlah contoh atau record yang berkaitan dengan enttas
tertentu. Misalnya, jika organisasi memiliki karyawan, entitas karyawan
disebut terdiri atas 100 pemunculan. Atribut (attribute) adalah elemen data
yang mendefinisikan entitas. Misalnya, entitas karyawan bias didefinisikan
dengan serangkaian atribut berrikut ini : Nama, Alamat, Keterampilan, Lama
Bekerja, dan Upah per Jam. Setiap pemunculan dalam entitas karyawab
terdiri atas jenis atribut yang sama, namun nilai setiap atribut akan berbeda
antarpemunculan. Karena atribut merupakan karakteristik yang logis dan
relevan dari suatu entitas, entitas tersebut bersifat unik untuk satu entitas
tertentu. Dengan kata lain, atribut yang sama tidak boleh digunakan untuk
mendefinisikan dua entitas yang berbeda.
Asosiaasi dan Kardinalitas
Garis berlabel yang menghubungkan dua entitas dalam model data
mendeskripsikan sifat asosiasi (association) di antara mereka. Asosiasi ini
ditunjukkan dengan kata kerja seperti kirim, minta, atau terima. Kardinalitas
(cardinality) adalah derajat asosiasi di antara duua entitas. Sederhananya,
kardinalitas mendeskripsikan jumlah pemunculan yang mungkin terrjadi
dalam satu tabel yang berkaitan dengan pemunculan tunggal dalam tabel
terkait. Empat bentuk dasar kardinalitas yang meungkin terjadi adalah : nol
atau satu (0,1), satu dan hanya satu (1,1), nol atau banyak (0,M), dan satu
atau banyak (1,M). Semua ini digabungkan untuk menunjukkan asosiasi logis
antarentitas. Figur 9-11 menampilkan beberapa contoh asosiasi entitas.
Satu ke Nol atau Satu (1:0,1). Asumsikan bahwa suatu perusahaan memiliki
1000 karyawan namun hanya 100 dari mereka yang merupakan staf
pembelian. Asumsikan juga bahwa setiap tenaga penjual diberi tanggung
jawab sebuah mobil
X1 Y1
X2 Y2
X3 Y1
X1 Y1 Z1
X2 Y2 Z2
X3 Y1 Z1
Y1 Z1
Y2 Z2
Y3 Z3
15. Perusahaan. Contoh 1 menunjukkan bahwa untuk setiap pemunculan (record)
dalam entitas karyawan ada kemungkinan nol atau satu pemunculan dalam
entitas mobil perusahaan.
Pendifinisian kardinalitas dari asosiasi entitas akan membantu untuk melihat
satu pemunculan (record) dari satu entitas dan untuk melihat entitas lainnya.
Berapa jumlah maksimal dan minimal dari record yang dapat berasosiasi
dengan satu record yang telah anda pilih? Dengan memacu pada entitas
karyawan dan melihat entitas mobil perusahaan ada dua kemungkinan
asosiasi. Jika record karyawan yang dipilih adalah tenaga penjual, maka ia
diberi tanggung jawab atas satu mobil perusahaan. Oleh sebab itu, record
karyawan hanya berasosiasi dengan satu record dalam entitas mobil
perusahaan. Akan tetapi, jika record karyawan yang dipilih bukan seorang
tenaga penjual, maka ia diberi tanggung jawab nol mobil perusahaan. Record
dalam hal ini berasosiasi dalam dengan record nol mobil perusahaan. Jadi,
kardinalitas minimal adalah nol dan maksimalnya adalah satu. Satu lingkaran
dan garis tipis yang memotong garis yang menghubungkan dua entitas
mencerminkan tingkat kardinalitasnya. Perhatikan bahwa dari perspektif
entitas karyawan, kardinalitas ditunjukkan pada ujung garis asosiasi mobil
perusahaan. Sekarang pilih record mobil perusahaan dan lihat kembali entitas
karyawan. Karena setiap mobil perusahaan diserahkan ke hanya satu
karyawan, nilai minimal dan maksimal dari record yang terkait adalah satu.
Dua garis pendek yang berpotongan pada ujung garis asosiasi karyawan
menunjukkan kardinalitas ini.
Satu ke satu (1:1). Contoh 2 mengilustrasikan situasi dimana setiap record
dalam satu entitas selalu berasosiasi dengan satu (dan hanya satu) record
dalam entitas yang berasosiasi. Dalam hal ini setiap komputer laptop
perusahaan diserahkan hanya kepada satu manajer dan setiap manajer hanya
diserahi satu komputer. Dua garis pendek yang memotong garis yang
menghubungkan pada kedua ujungnya mencerminkan kardinalitas ini.
Satu ke nol atau banyak (1:0,M). Hubungan antara entitas pelanggan dan
pesanan penjualan ditunjukkan dalam contoh 3. Perhatikan bahwa jumlah
minimal record pesanan penjualan per record pelanggan adalah nol dan
jumlah maksimalnya adalah banyak. Ini karena dalam periode tertentu (tahun
atau bulan) yang berkaitan dengan entitas pesanan penjualan, pelanggan
16. tertentu mungkin tidak membeli apa pun (nol record pesanan penjualan) atau
membeli beberapa kali (banyak record). Akan tetapi, dari perspektif entitas
pesanan penjuala, setiap record berasosiasi dengan satu dan hanya satu
pelanggan. Simbol kaki burung gagak (yang digunakan sebagai nama notasi
ini) mencerminkan banyak kardinalitas.
Satu ke banyak (1:M). Contoh 4 menunjukkan situasi, dimana setiap item
persediaan dipasok oleh satu (dan hanya satu) pemasok, dan setiap pemasok
satu atau berbagai item persediaan ke perusahaan. Asosiasi ini yang secara
teknis merupakan satu dan hanya satuke satu atau banyak, disederhanakan
menjadi satu ke banyak.
Banyak ke banyak (M:M). Untuk mengilustrasikan asosiasi banyak ke
banyak, lihat kembali hubungan antara pemasok dan persediaan dalam
contoh 5. Akan tetapi, sekarang perusahaan memiliki kebijakan untuk
membeli jenis persediaan yang sama dari beberapa pemasok. Pihak
manajemen bisa melakukan hal ini untuk memastikan bahwa mereka
mendapatkan harga yang terbaik atau untuk mencegah ketergantungan pada
satu pemasok. Dengan kebijakan ini, setiap record pemasok berasosiasi
dengan satu atau banyak record pemasok. Asosiasi ini (satu atau banyak ke
satu atau banyak) disederhanakan menjadi banyak ke banyak.
Contoh 4 dan 5 menunjukkan bagaimana kardinalitas menyajikan peraturan
bisnis dalam organisasi. Desainer basis data harus memperoleh pemahaman
menyeluruh mengenai cara perusahaan, klien, dan pengguna tertentu
melakukan bisinis agar dapat mendesain model data dengan bai. Jika model
data salah, maka tabel basis data yang dihasilkan juga akan salah. Contoh 4
dan 5 sama-sama valid namun pilihannya berbeda, dan memerlukan desain
basis data yang berbeda pula.
Tabel Basis Data Fisik
Tabel basis data fisik dibentuk dari model data, dimana setiap entitas dalam
model ditransformasikan ke tabel fisik yang terpisah. Di bagian atas setiap
tabel terdapat atribut yang membentuk kolom. Bagian yang berpotongan
dengan kolom untuk membentuk baris dari tabel disebut tuple. Sebuah tuple,
yang didefinisikan oleh good ketika pertama kali memperkenalkannya,
berhubungan dengan record dalam sistem file datar. Berdasarkan konvensi
ini, kita akan menggunakan istilah record atau pemunculan dan bukan tuple.
17. Tabel yang didesain dengan baik memiliki empat karakteristik berikut ini:
1. Nilai dari minimal satu atribut dalam setiap pemunculan (baris) harus
bersifat unik. Atribut ini adalah kunci utama. Atribut lainnya dalam baris
ini tidak perlu bersifat unik.
2. Tabel harus sesuai dengan peraturan normalisasi. Ini berarti bahwa tabel
harus bebas dari kelompok yang berulang, ketergantungan parsial dan
ketergantungan transitif. Normalisasi akan dibahas lebih terperinci nanti
dalam bab ini.
3. Semua nilai atribut dalam kolom manapun harus memiliki kelas yang
sama.
4. Setiap kolom dalam suatu tabel harus diberi nama yang unik. Akan tetapi,
tabel yang berbeda dapat berisi kolom dengan nama yang sama.
Hubungan Antara Tabel – tabel Tradisional
Tabel-tabel yang berhubungan secara logis harus terhubung secara fisik
untuk mencapai asosiasi yang dideskripsikan dalam model data. Hal ini bisa
dicapai dengan melekatkan kunci primer dari satu tabel dengan tabel yang
terkait sebagai kunci luar. Penggunaan kunci luar diilustrasikan dlam figur 9-
12. Misalnya, kunci primer untuk tabel pelanggan (nomor pelanggan)
dilekatkan sebagai kunci luar dalam tabel faktur penjualan dan tabel
penerimaan kas. Dengan cara yang sama, kunci primer dalam tabel faktur
penjualan (nomor faktur) merupakan kunci luar dalam tabel item lini.
Perhatikan bahwa tabel item lini menggunakan kunci primer gabungan yang
terdiri atas dua field-nomor faktur dan nomor item. Kedua field dibutuhkan
untuk mengidentifikasi setiap record yang terdapat dalam tabel secara unik,
tetapi hanya bagian nomor faktur dari kunci itu yang menjadi penghubung
logis dengan tabel faktur penjualan.
DBMS membuat hubungan fisik diantara record yang terdapat dalam
tabel-tabel berkaitan dengan mencari tabel-tabel yang dispesifikasi untuk
record-record yang nilainya diketahui. Misalnya, jika seorang pengguna
menginginkan semua faktur untuk pelanggan 1875, sistem tersebut akan
mencari tabel faktur penjualan untuk record dengan nilai kunci luar 1875.
Kita lihat dari figur 9-12 bahwa hanya ada satu pemunculan nomor faktur
1921. Untuk mendapatkan perincian item lini dari faktur ini pencarian
dilakukan pada tabel item lini untuk record yang memiliki nilai kunci luar
18. 1921. Ada dua record yang ditemukan. Sifat asosiasi antara dua tabel
menentukan metode yang digunakan untuk menetapkan kunci-kunci luar.
Metode ini akan dijelaskan nanti dalam bab ini.
Gambar 9.10. Kaitan diantara Tabel-tabel Relasional
Tampilan Pengguna
Tampilan pengguna telah didefinisikan sebelumnya sebagai serangkaian
data yang dilihat oleh pengguna tertentu. Contoh dari tampilan pengguna
adalah layar komputer, untuk memasukkan atau melihat data, laporan
manajemen, atau dokumen sumber seperti faktur. Tampilan bisa bersifat
digital atau fisik, namun semuanya berasal dari tabel basis data. Tampila
sederhana bisa dibuat dari satu tabel, sedangkan tampilan yang lebih rumit
akan memerlukan beberapa tabel. Selain itu, satu tabel mungkin dapat
mengontribusikan data ke berbagai tampilan yang berbeda-beda.
Nama Pel.
(kunci)
Nama Alamat
Saldo
Saat ini
1875 J. Smith 18 Elm St. 1820,00
1876 G. Adams 21 First St. 2400,00
1943 J. Hobbs 165 Higth St. 549,87
2345 Y. Martin 321 Barcclay 5256,76
- - - -
- - - -
- - - -
5678 T.Stem 432 Main ST. 643,67
No.
Faktur
No.
Pelanggan
Jumlah
$
Tanggal
Pengiriman
- - - -
- - - -
1921 1875 800,00 2 / 10 / 98
- - - -
- - - -
- - - -
No. Peng.
(kunci)
No
Pelanggan
Jumlah
Diterima
Tanggal
Diterima
- - - -
1362 1875 800,00 2 / 30 / 98
- - - -
- - - -
No.
Faktur
No Item Kuantitas
Harga
Perunit
Total
1918 8312 1 84,50 84,50
1912 9215 10 45,00 450,00
1921 3914 1 350,00 350,00
Pelanggan
Kunci
Item Garis
Faktur
Penjualan
Penerimaan Kas
Kunci Asing yang
ditanamkan
Kunci Asing yang
ditanamkan
Kunci Asing yang
ditanamkan
19. Proses Normalisasi Data
Proses normalisasi data mencakup pemahaman tentang kebutuhan informasi
pengguna dan peraturan bisnis organisasi. Proses ini dimulai dengan pemerolehan
tampilan (laporan output, dokumen, dan layar input) yang dibutuhkan oelh pengguna.
Gambar ini dapat disiapkan dengan menggunakan MS Word, program grafis, atau
cukup dengan kertas dan pensil. Pada saat ini gambar tersebut hanya merupakan
representasi grafis dari gambar fisik yang nantinya akan dimiliki oleh pengguna ketika
proyek itu sudah selesai.
Pentingnya Normalisasi Data
Tabel-tabel basis data yang dirancang dengan benar memiliki peran
penting bagi keberhaailan operasional DBMS. Tabel-tabel yang dirancang
dengan buruk dapat menimbulkan masalah-masalah pemrosesan yang
membatasi, atau bahkan menolak, akses pengguna ke informasi yang
diperlukan.
Normalisasi data merupakan proses yang meningkatkan desain basis
data yang efektif dengan mengelompokkan atribut-atribut data kedalam
ntitas yang sesuai dengan kondisi-kondisi tertentu. Terdapat beberapa tingkat
normalisasi.Biasanya,perancang basis data bisnis menormalisasikan tabel-
tabel ketingkat bentuk normal ketiga (third normal form-3NF).
Tabel-tabel yang dibentuk dari model yang belum dinormlisasi bisa
memiliki tiga jenis masalah yang disebut anomali (anomaly): anomali
pembaruan, anomali penyisipan , dan anomali pengahapusan. Salah satu atau
beberapa anomali ini akan terdapat dalam tabel-tabel yang dinormalisasikan
pada tingkat yang lebih rendah seperti bentuk normal pertama (first normal
form -1NF) dan bentuk normal kedua (second normal form -2NF), tetapi
tabel-tabel dalam 3NF bebas dari anomali.
Untuk menunjukan dampak dari ketiga anomali ini, dengan pengaruh
penerapan prosedur normalisasi, tampilan pengguna harus diperlakukan
sama dengan tabel tabel fisik dengan record dan nilai atribut.
Anomali Basis Data
Meskipun tampilan pengguna bias ditarik dari tabel 3NF tunggal, tampilan
yang rumit biasanya memerlukan lebih dari satu tabel. Misalnya, tabel 3NF
tunggal tidak bisa menghasilkan Laporan Status Persediaan dalam Figur 9-
20. 113. Tabel yang tidak dinormalisasi dalam figur 9-14 bisa menghasilkan
pandangan ini, namun akan mengandung anomali yang dideskripsikan.
Anomali Pembaruan. Anomali Pembaruan (update anomaly) dihasilkan dari
redundasi data (data yang berlebihan) dalam tabel yang tidak dinormalisasi.
Untuk menggambarkannya, perhatikan bahawa Pemasok nomor 22
menyediakan ketiga item persediaan (suku cadang nomor 1,2,3) yang
ditunjukkan dalam figure 9-21. Atribut – atribut data yang berkaitan dengan
pemasok nomor 22 (nama, alamat, dan nomor telepon) diulang dalam setiap
record, unutk setiap item persediaan yang disediakan oleh pemasok nomor
22. Setiap perubahan dalam nama, alamat, atau nomor telepon harus
dilakukan untuk setiap record dalam tabel tersebut. Dalam contoh ini, berarti
tiga pembaruan data yang berbeda. Untuk lebih memahami implikasi
anomali pembaruan ini, pertimbangan sebuah situasi yang lebih realistis di
mana pemasok memasok 10.000 persediaan yang berbeda. Setiap pembaruan
untuk sebuah atribut harus dibuat 10.000 kali.
Anomali Sisipan. Untuk meunjukkan dampak anomali penyisipan (insertion
anomaly), asumsikan bahwa seorang pemasok telah memasuki pasar.
Perusahaan belum membeli persediaan dari pemasok itu, tapi ingin
melakukannya di masa yang akan dating. Untuk sementara, perusahaan ingin
memasukkan pemasok itu ke dalam basis data. Iini tidak mungkin Karena
kunci primer untuk tabel persediaan adalah Nmor Suku Cadang. Karena
pemasok belum memasok persediaan untuk organisasi, data pemasok itu
tidak dapat ditambahkan ke tabel.
Anomali Penghapusan. Anomali Penghapusan (deletion anomaly)
melibatkan penghapusan yang tidak disengaja atas data dalam tabel. Untuk
mengilustrasikannya, asumsikan pemasok nomor 27 hanya memasok satu
item untuk perusahaan: Suku cadang nomor 1. Jika perusahaan
menghentikan penggunaan item terseebut dan menghapusnya dari tabel, data
yang berkaitan dengan pemasok nomor 27 juga akan terrhapus. Walaupun
mungkin perusahaan ingin mempertahankan informasi pemasok tersebut di
masa yang akan datang, desain tabel saat ini tidak memungkinkannya
melakukan hal itu.
Adanya anomali penghapusan ini tidak terlalu jelas, namun berpotensi
menimbulkan masalah yang lebih serius daripada anomali pembaruan data
21. dan anomali penyisipan. Desain basis data yang cacat, yang menghalangi
penyisipan record atau mensyaratkan pengguna untuk melakukan pembaruan
yang berlebihan dengan cepat meminta perhatian. Namun demikian, anomali
penghapusan dapat tidak terdeteksi, dan penggunaannya mungkin tidak sadar
akan hilangnya data – data penting sampai akhirnya sudah terlambat. Basis
data yang strukturnya buruk dapat mengakibatkan hilangnya catatan
akuntansi penting secara tidak sengaja, dan hancurnya jejak audit. Oleh
karena itu, desain tabel basis data membawa implikasi control internal yang
harus diketahui oleh para akuntan.
Peraturan Normalisasi Data
Proses normalisasi yang emeriksa ketergantungan penyebab anmali secara
formal disebut kelompok berulang, ketergantungan dan keterrgantungan
transitif yang disajikan dalam lampiran babini. Disini, pendekatan intuitif
digunakan untuk menormalisasikan data. Dengan kata lain eliminasi ketiga
anomali ini melibatkan sebuah proses yang secara sistematis memecah tabel
– tabel kompleks menjadi tabel – tabel yang lebih kecil yang memenuhi dua
kondisi :
a. Semua atribut nonkunci dalam tabel itu bergantung pada kunci primer
b. Seua atribut nonkunci tidak bergantung pada atribut nonkunci lainnya.
Dengan kata lain, tabel 3NF adalah tabel yang kunci primernya
mendefinisikan setiap atribut dalam tabel secara utuh dan unik. Selain itu,
tidak ada atribut tabel yang didefinisikan oleh atribut lainnya selain kunci
primer. Namun demikian, jika satu atau lebih atribut melanggar kondisi –
kondisi ini, atribut tersebut harus digantikan dan ditempatkan dalam sebuah
tabel terpisah dan ditetapkan satu kunci yang tepat.
Membelah Tabel – tabel Yang Tidak Dinormalisasi
Pada saat memeriksa figure 9-14, terlihat bahwa tidak semua atribut data
berhubungan secara lois dengan kunci primer Nomor suku cadang.
Kenyataannya, ada dua rangkaian data yang berbeda dalam tabel ini : data
mengenai persediaan dan data mengenai pemasok. Atribut non kunci dari
nama, alamat, dan nomor telepon, tidak bergantung pada (tidak didefinisikan
oleh) Nomor Suku cadang. Sebaliknya, atribut – atribut ini bergantugn pada
atribut nonkunci nomor pemasok. Solusinya adalah dengan memindahkan
data pemasok dari tabel persediaan dan menempatkannya dalam sebuah tabel
22. berpisah, yang diberi nama pemasok. Figur 9-15 menunjukkan dua tabel
3NF,persediaan dan pemasok bersama dengan tabel ketiga yang disebut suku
cadang/pemasok, yang menghubungkan kedua tabel tersebut. Teknik
penghubung ini akan dijelaskan kemudian.
Menormalisasikan tabel – tabel akan menghilangkan ketiga anomali terseut.
Pertama, anomali pembaruan data dipecahkan karena data mengenai setiap
pemasok ditempatkan hanya pada satu lokasi-tabel pemasok. Setiap
perubahan data tentang pemasok individual hanya dibuat satu kali, tanpa
melihat jumlah item yang dipasoknya. Kedua, anomali penyisipan
dipecahkan, karena pemasok – pemask baru bisa ditambahkan ke tabel
pemasok, bahkan jika merkkea saat ini tidak memasok persediaan
untukperusahaan. MIsalya, pemasok nomor 30 di dalam tabel itu tidak
memasok satu pun persediaan dari basis data tidak akan menghapus secara
tidak sengaja data pemasok, Karena data tersebut ditemaptkan secara
independen dalam tabel – tabel yang berbeda.
Menghubungkan Tabel – tabel yang Dinormalisasi
Ketika tabel yang tidak dinormalisasikan dipecah menjadi tabel 3NF ganda,
tabel – tabel harus dihubungkan sehingga data yang termuat di dalamnya
dapat dikaitkan dan diakses oleh pengguna sistem. Tingkat asosiasi antara
tabel – tabel yang dihasilkan (yaitu 1:1, 1:M, atay M:M) menentukan bentuk
hubungannya. Tiga aturan penetapan kunci untuk menghubungkan tabel
dibahas dibawah ini.
Memasukkan Kunci Asosiasi 1:1. Ketika asosiasi 1:1 yang sejati terjadi
antara tabel, salah satu (atau kedua) kunci primer dapat dilekatkan sebagai
kunci luar di tabel terkait. Di sisi lain, ketika nilai kardanilitasnya yang lebih
rendah adalah nol (1:0:1) struktur tabel yang lebih efisien dapat dicapai
dengan menempatkan kunci primer tabel satu sisi (1:) pada tabel nol atau satu
(:0,1) sebagai kunci luar. Dengan menggunakan contoh mobil
karyawan/perusahaan dalam figure 9-11,pentingya penetapan kunci ini dapat
terlihat lebih nyata. Sebagai ilustrasinya, balikkan peraturan tersebut dengan
menempatkan kunci primer Mobil perusahaan (sisi 0) ke tabel karyawan (sisi
1). Karena kebanyakan karyawan tidak ditugasi dengan mobil perusahaan,
maka kebanyakan kunci luar di tabel karyawan akan memiliki nilai nol
(kososng). Meskipun pendekatan ini bisa dilaksanakan, ada beberapa
23. maslaah teknis yang mungkin terjadi selama pencarian tabel. Penerapan
peraturan penugasan kunci yang tepat akan mengatasi masalah ini karena
semua catatan mobil perusahaan pasti ditugaskan ke karyawan dan tidak ada
nolai nol yang akan muncul.
Memasukkan asosiasi 1:M. Ketika asosiasi 1:M (atu 1:0:M) terjadi , kunci
primer di sisi 1 dilekatkan ke tabel di sisi M. Untuk menunjukkan logika dari
peraturan penugasan kunci ini, pertimbangakan kedua laternatif peraturan
bisnis untuk pembelian persediaan dari pemasok.
Peraturan bisnis 1 : Setiap pemasok memasok perusahaan dengan tiga
(atau kurang) item persediaan yang berbeda namun setiap item hanya
diapsok oleh satu pemasok.
Peraturan bisnis yang tampaknya tidak realistis ini, namunmemungkinkan
secara teknis, mendeskripsikan asosiasi 1:M (1:1,3) batas atas antara tabel
persediaan dan tabel pemasok.
Untuk menerapkan peraturan ini, para perancang perlu memodofikasi struktur
tabel persediaan untuk memasukkan nomor pemasok seperti yang ilustrasikan
dalam figure 9-16. Dengan pendekatan ini, setiap record dalam tabel
persediaan akan berisi nilai dari field kunci pemasok yang memasok item
tersebut. Sebaliknya, figure 9-17 menunjukkan bahwa struktur tabel mungkin
kelihatan seakan – akan perancangnya membalikkan aturan penetapan kunci
dengan menanamkan kunci nomor suku cadang dalam tabel pemaok.
Perhatikan bahwa tabel pemasok sekarang berisis tiga field nomor suku
cadang, masing – masing berhubungan dengan record dalam tabel persediaan.
Hanya enghubung dengan nomor suku cadang 1,2 dan 3 yang ditampilkan.
Walaupun teknik ini melanggar peraturan penetapan kunci, struktur tabel ini
juga bisa digunakan. Struktur ini bisa digunakan karena batas atas dari sisi
“banyak” (mary) asosiasi tersebut diketahui dan sangat kecil (terbatas hingga
tiga). Bagaimana bentuk struktur ini jika kita mengasumsikan peraturan bisnis
yang lebih realistis seperti dibawah ini?
Peraturan Bisnis 2 : Setiap pemasok menyediakan sejumlah persediaan
ke perusahaan, tetapi setiap item disedaiakn hanya oleh satu pemasok.
Peaturan ini merupakan asosiasi 1:M yang sejati, di mana batas atas dari sisi
“banyak” asosiasi itu tidak terkait. Dengan kata lain, pemasok mungkin hanya
memasok satu item persediaan atau sepuluh ribu item. Berapa banyak field
24. yang harus kita tambahkan ke struktur tabel pemasok agar dapat, melihat
logika yang mendasari peraturan penetapan kunci 1:M. Struktur dalam figure
9-16 dapat tetap digunakan di bawah peraturan bisnis ini, sementara teknik
yang di ilustrasikan dalam figur 9-17 tidak.
Memasukkan Asosiasi M:M. Untuk menyajikan asosiasi M:M antara tabel,
kita perlu membuat tabel penghubung. Tabel penghubung memiliki junci
gabungan (komposit) yang terdiri atas kunci primer dari dua tabel yang
berhubungan. Sekarang, lihatlah asosiasi dalam figure 9-15. Tabel – tabel ini
mengilustrasikan asosiasi M:M yang dideskripsikan dengan peraturan bisnis
berikut ini :
Peraturan Bisnis M:M : Setiap pemasok menyediakan sejumlah
persediaan ke perusahaan, dan setiap item dapat dipasok oleh satu atau
beberapa pemasok.
Akuntan dan Normalisasi Data
Normalisasi basis data merupakan sebuah masalah teknis yang biasanya
menjadi tanggung jawab seorang ahli atau professional sistem. Namun
demikian normalisasi basis data memiliki implikasi untuk pengendalian
internal yang menjadi perhatiaan akuntan juga. Walaupun kebanyakan
akluntan tidak akan bertanggung jawab untuk menormalisasikan basis data
organisasi, mereka harus memahami prosesnya dan mampu menentukan
apakah table itu dinormalisasikan dengan benar atau tidak.
Mendesain Basis Data Relasional
Bagian ini membahas langkah-langkah yang terkait dalam pembuatan basis data
relasional. Bagian awal biasanya mencakup banyak pekerjaan yang mengidentifikasi secara
terperinci elemen-elemen utama dari sistem yang dikembangkan. Dengan latar belakang ini,
ada 6 tahap utama dalam desain basis data.
1. Mengidentifikasi entitas
2. Membuat model data yang menunjukkan asosiasi entitas
3. Menambah kunci primer dan atribut ke model
4. Menormalisasi model data dan menambah kunci luar
5. Membuat basis data fisik
6. Menyiapkan tampilan pengguna.
25. Mengidentifikasi Entitas
Desain basis data dimulai dengan mengidentifikasi entitas organisasi dan membuat
model data yang menunjukkan hubungannya. Hal ini mencakup analisis peraturan
bisnis dan kebutuhan informasi dari semua pengguna. Fitur-fitur kunci yang berisi
petunjuk entitas dalam sistem yang baru diusulkan adalah sebagai berikut:
1. Agen pembelian meninjau kembali laporan status persediaan untuk melihat item-
item yang perlu dipesan kembali.
2. Agen memilih pemasok dan menyiapkan pesanan pembeliia online.
3. Agen mencetak salinan pesanan pembelian dan mengirimnya ke pemasok
4. Pemasok mengirim persediaan keperusahaan. Pada saat persediaan tiba, stap bagiaan
penerimaan memeriksa persediaan dan menyiapkan laporan penerimaan online.
Sistem computer secara otomatis memperbarui record persediaan.
Entitas yang field harus memenuhi 2 kondisi berikut ini:
Kondisi 1: enttas tersebut harus terdiri atas dua atau lebih pemunculan
Kondisi 2: entitas tersebut harus mengkontribusikan menimal 1 atribut yang tidak
disediakan oleh entitas lain.
Setiap kandidat harus diuji dengan masing-masing kondisi tersebut untuk
menghilangkan entitas yang salah.
Agen Pembelian kita perlu menentukan data apa mengenai agen tersebut yang unik
perihal perannya dalam kebutuhan penempatan pesanan. Perhatikan bahwa kita tidak
mengacu pada data mengenai pesanan, namun data mengenai agen. Karena kita tidak
memiliki infirmasi pada deskrpsi singkat sistem ini, kita akan mengasumsikan bahwa
tidak ada data khusus yang dimasukkan. Oleh sebab iti, kandidat agen pembelian bukan
merupakan entitas yang akan dimodel.
Staf Penerimaan. Argumen yang sebelumya dapat diterapakan bagi entitas staf
penerimaan. Dapat diasumsukan bahwa tidak ada data khusus mengenai staf ini yang
perlu ditangkap sehingga memerlukan table khusus.
Persediaan. Entitas oersediaan memenuhi kedua kondisi tersebut. Kita bisa secara logis
mengasumsikan bahwa atribut yang mendefinisikan entita persediaan tidak tersedia
pada table-tabel yang lain. Entitas persediaab adalah entitas sejati yang perlu domodel.
Pemasok deskripsinya menyatakan bhawa banyak pemasok memasok persediaan,
sehingga entitas pemasok memenuhi kondisi pertama. Entitas pemasok akan termasuk
dalam model data.
26. Laporan Status Persediaan. Laporan status persediaan adalah tampilan pengguna
yang diperoleh dari entitas persediaan dan pemasok. Meskipun berisi pemunculan
ganda ini bukanlah entitas karena tidak memenuhi kondidi 2. Akan tetpai, tampilan ini
akan dianalisi dengan hati-hati untuk memastikan bahwa semua atribut yang
dibutuhkan untuk hal ini termasuk dalam entitas yang sudah ada.
Pesanan Pembelian. Pesanan pembeliaan langsung berhubungan dengan transaksi
pembeliian. Semua transaksi adalah peristiwa yang unik yang harus ditangkap dalam
basis data. Meskipun beberapa data pesana pembelian berkaitan dengan entitas yang
ada dalam model ini, atribut-atribut lain yang khusus untuk peristiwa pembelian akan
memerlukan satu atau beberoa entitas. Oleh sebab itu, tampilan ini perlu dimodel.
Laporan Penerimaan. Status laporan penerimaan mirip dengan pesanan pembelian.
Ini dibutuhkan untuk menangkap data transaksi khusu yang memerlukan entitas
tambahan dan harus dimodel.
Membuat Model Data Yang Menunjukkan Asosiasi Entitas
Asosiasi menunjukkan peraturan bisnis. Kadang-kadang peraturan tersebut nyata
dan sama untuk semua organisasi. Agar basis data dapat berfunngsi denagn baik,
rancang sistem perlu memahami peraturan bisnis organisasi seta kebutuhan khusus dari
pengguna individual. Peraturab bisnis yang mendasarinya dijelaskan dibawah ini :
1. Ada asosiasi 0,M:M antara entitas pembeliaan dan persediaan. Ini berarti bahwa
setiap item persediaan bisa dipesan beberapa kali dalam periode bisnis tertentu.
Pesanan pembelian yang sudah ditutup pada periode sebelumnya tentu sudah
dipindahkan ketabel arsip, yang tidak ditunjukkan dalam contoh ini.
2. Ada asosiasi M:M antara entitas persediaan dan pemasok ini berarti bahwa satu atau
beberapa pemasok menyediakan masing-masing item persediaan, dan setiap
pemasok menyedikan satu atau beberapa item persediaan.
3. Ada asosiasi 1:0,M antara entitas pemasok dan pesana pembelian. Ini berarti bahwa
dalam periode saat ini,setiap pemasok dapat menerima nol atau banyak pesanan
pembelian, namun setiap pesaan hanya kesatu pemasok.
4. Ada asosiasi 1:1 antara entitas pembelian dan laporan penerimaan. Satu record
laporan penerimaan mencerminkan tanda terima barangv tertentu dari satu record
pesanan pembelian. Pesanan pembelian ganda tidak digabungkan dalam satu laporan
penerimaan.
27. 5. Asosiasi antara entitas lapora penerimaan dan persediaan adalah 0,M:M. ini berarti
bahwa dalam periode tertentu, setiap item persediaan dapat diterima beberapa kali
atau tidak sama sekali.
Asosiasi banyak kebanyak ( M:M dan 0,M:M ) dalam model data perlu diatasi sebelum
basis data fisik dibuat. Kita akan mengatasi masalah ini pada proses normalisasi.
Menambahkan Kunci Primer dan Atribut ke Model
Menambah Kunci Primer. Analis harus memilih kunci primer yang secara logis
mendefinisikan atribut non kunci dan secara unik mengidentifikasi setiap kemunculan
dalam entitas. Dengan mendesain secara hati-hati kode blok, kode kelompok, kode
alfabetis dank ode memonik, kunci primer juga dapat memberikan informasi yang
berguna mengenai sifat alami dari suatu entitas.
Menambahkan Atribut. Atribut entitas diperoleh dan dimodel dari tampilan
pengguna. Atribut yang ditetapkan untuk setiap entitas diperoleh dari tampilan
pengguna pada pesanan pembelian dan laporan penerimaan dan laporan status
persediaan yang telah dinormalisasi sebelumnya.
Menormalisasi Model Data dan Menambahkan Kunci Luar
Masalah normalisasi yang perlu diatasi adalah sebagai berikut:
1. Data kelompok yang berulang-ulang dalam pesanan pembelian. Ini berarti
bahwa ketika pesanan pembelian tertentu berisi lebih dari satu item, maka nilai
ganda akan perlu ditangkap untukl atribut ini. Untuk mengatasi masalah ini data
kelompok yang berulang-ulang dipindahkan ke entitas perincian item pesanan
pembelian.
2. Data kelompoj yang berulang-ulang dalam laporamn penerimaan. atribut
nomor suku cadang, jumlah yang diterima, dank ode kondisi adalah kelompok yang
berulang-ulang dalam entitas laporan penerimaan dan dipindahkan ke entitas baru
yang disebut perincian item laporan penerimaan.
3. Ketergantungan transitif. Entitas pesanan pembelian dan laporan penerimaan
berisi atrbut yang redundan dengan data yang ada dalam entitas persediaan dan
pemasok. Redundansi ini terjadi karena ketergantungan transitif dalam entitas
pesaanan pembelian dan laporan penerimaan
Membuat Basis Data Fisik
Setiap record dalam tabel perincian item laporan penerimaan menyajikan item
individual dalam laporan penerimaan. tabel perincian item pesanan pembelian
28. menggunakan kunci primer komposit dari nomor pesana pembelian dan nomor suku
cadang untuk secara unki mengidentifikasi atribut jumlah pesanan.
Langkah selanjutnya adalah membuat tabel-tabel fisik dan mengisinya dengan
data. Hal ini mencakup langkah yang harus direncanakan dan dilaksanakan dengan hati-
nati, dan bisa menghabiskan waktu beberapa bulan dalanm instalasi yang besar.
Program-program yang perlu citulis untuk mentransfer data organisasi yang saat ini
disimpan dalam file datar atau basis data warisan kedalam tabel relasional yang baru.
Data yang saat ini disimpan dalam dokumen kertas akan perlu dimasukkan kedalam
tabel basis data secara manual. Setelah ini dilakukan, tampilan pengguna dapat dibuat.
Menyiapkan Tampilan Pengguna
Tabel yang dinormalisasi harus cukup lengkap agar dapat mendukung tampilan
dari semua pengguna sistem. Tampilan laporan penerimaan, pesanan pembelian, dan
laporan status persediaan dibuat dengan cara ini juga. Sebagai ilustrasinya dibawah ini
:
Perintah SELECT mengidentifikasi semua atribut yang terdapat dalam tampilan
tersebut. Ketika atribut yang sama muncul pada lebihdari satu tabel (misalnya,
nomor-suku-cabang), namatabel sumber juga harus disebutkan.
Perintah FROM mengidentifikasi tabel-tabel yang digunakan untuk membuat
tampilan tersebut.
Perintah WHERE menunjukkan bagaimana baris-baris dalam tabel persediaan, tabel
suku cabang – pemasok, dan tabel pemasok dicocokkan untuk membuat tampilan
tersebut. Dalam hal ini, tiga tabel digabungkan secara aljabar berdasarkan kunci
primer nomor – suku cadang dan nomor – pemasok.
Ekspresi ganda dapat dikaitkan dengan operator AND , OR, dan NOT. Dalam contoh
ini, ekspresi terakhir menggunakan AND untuk membatasi record yang akan dipilih
dengan ekspresi logis jumlah – yang – dimiliki ≤ titik pemesanan kembali.
Perintah SPL akan disimpan dalam program penggunaan yang disebut query. Untuk
melihat laporan status persediaan, agen pembelian menjalankan program query. Setiap
kali hal ini dilakukan, query membangun t ampilan baru dengan data terbaru dari tabel
persediaan dan pemasok. Dengan menyediakan permintaan dari masing-masing
pengguna, bukannya mengizinkan akses ke tabel-tabel yang mendasari, pengguna
dibatasi hanya ke data yang diberi otorisasi.
Basis Data dalam Lingkungan Terdistribusi
29. BAB 1 memperkenalkan konsep pemrosesan data terdistribusi (distributed data
processing – DDP) sebagai sebuah alternatif untuk pendekatan tersentralisasi. Kebanyakan
organisasi modern menggunakan bentuk pemrosesan distributive dan jejaring untuk
memproses transaksi. Satu hal penting yang harus dipertimbangkan dalam merencanakan
sebuah sistem terdistribusi adalah lokasi basis data organisasi. Basis data terdistribusi memiliki
dua kategori : basis data terpartisi dan tereplikasi.
Basis Data Tersentralisasi
Berdasarkan pendekatan basis data tersentralisasi ( centralized data base),
pengguna dari jarak jauh mengirim permintaan melalui terminal untuk data yang
terdapat disitus central, yang memproses permintaan dan mengirimkan data kembali
kepengguna. Situs central melakukan fungsi manager file yang melayani kebutuhan
data dari para pengguna jarak jauh.
Ada tiga keunggulan utama dari pendekatan basis data yang akan disajikan :
pengurangan biaya penyimpanan data, pengapusan prosedur pembaruan ganda,
danpembentukan kekinian data (file data perusahaan dengan tepat mencerminkan
dampak dari transaksinya).
Kekinian Data Dalam Lingkungan DDP
Selama pemrosesan data, saldo akun melewati keadaan inkonsistensi
sementara (temporary inconsistency) dimana nilainya dinyatakan secara
tidak benar. Hal ini terjadi selama pelaksanaan setiap transaski akuntansi.
Dalam lingkungan DDP, inkonsistensi sementara seperti itu dapat
menghasilkan kerusakan permanen pada basis data.
Pengunci Basis Data
Untuk mendapatkan kekinian data, akses bersamaan ke elemen-elemen
data individual dengan banyak situs perlu dicegah. Pemecahan masalah ini
adalah dengan menggunakan pengunci basis data (basis data lockout), yaitu
sebuah pengendali peranti lunak yang mencegah banyak akses secara
bersamaan ke data.
Basis Data Terdistribusi
Basis data terdistribusi dapat didistribusikan dengan menggunakan tenik partisi
atau replikasi (tiruan).
30. Basis Data Terpartisi
Pendekatan basis data terpartisi membagi basis data sentral dalam segmen
atau partsisi yang didistribusikan ke para pengguna utama. Keunggulan
pendekatan ini adalah :
Pengendalian penggunaan ditingkatkan karena data disimpan dalam situs-
situs lokal.
Waktu tanggal pemrosesan transaksi diperbaiki dengan memungkinkan
akses local ke data dan mengurami volume data yang harus ditransmisi
diantara situs.
Basis data terpartisi dapat mengurangi potensi kehancuran. Dengan
menetapkan dibeberapa situs, hilangnya sebuah situs tidak akan
menghapus semua data yang diproses oleh organisasi.
Pada situasi dimana para pengguna dari situs yang berbeda menggunakan
data yang sama, masalah yang berkaitan dengan pendekatan sentralisasi juga
bisa terjadi. Permintaan data dari situs-situs lainnya sekarang harus dikelola
menurut pengguna utamanya.
Fenomena jalan buntu. Dalam sebuah lingkungan terdistribusi, mungkin
terjadi banyak situs akan saling mengunci, sehingga saling mencegah untuk
memproses transaksinya. Jalan buntu (deadlock) terjadi karena ada sifat
saling mengecualikan terhadap data, dan transaksi berada dalam status
“menunggu” sampai semua kunci dipindahkan. Hal ini menyebabkan
transaksi tidak diproses secara lengkap dan merusak basis data. Jalan buntu
merupakan kondisi permanen yang harus dipecahkan oleh peranti lunak
khusus yang menganalisis setiap kondisi jalan buntu untuk menentukan
solusi terbaik. Karena hal ini dapat memengaruhi pemrosesan transaksi,
akuntan harus mengetahui masalah-masalah yang berkaitan dengan resolusi
jalan buntu.
Resolusi jalan buntu. Pemecahan masalah jalan buntu biasanya akan
mengorbankan satu atau dua transaksi. Transaksi-transaksi tersebut harus
dihentikan untuk menyelesaikan pemrosesa transaksi lainnya dalam jalan
buntu tersebut. Transaksi yang diselamatkan terlebih dahulu harus diulang
kembali. Dalam transaksi yang diselamatkan terlebih dahulu, peranti lunak
resolusi jalan buntu berusaha untuk meminimalkan total biaya untuk
31. memecahkan jalan buntu tersebut. Walaupun untuk mengotomatisasikannya
tidak mudah, beberapa faktor yang dapat mempengaruhi keputusan ini adalah
:
1. Sumber daya yang baru-baru ini di investasikan dalam transaksi tersebut.
Hal ini dapat diukur dalam jumlah pembaruan transaksi yang telah
dilakukan dan yang harus diulang jika transaksi tersebut dihapuskan.
2. Tahap penyelesaian transaksi. Secara umum, peranti lunak untuk resolusi
jalan buntu akan mencegah penghapusan transaksi yang mendekati
selesai.
3. Jumlah jalan buntu yang berkaitan dengan transaksi. Karena menghapus
transaksi akan memecahkan semua keterlibatan jalan buntu peranti lunak
itu harus berusaha untuk menghilangkan transaksi yang menjadi bagian
lebih dari satu jalan buntu.
Basis Data Tereplikasi
Basis data tereplikasi (replicated data base) efektif untuk perusahaan yang
tingkat penggunaan bersama untuk data-datanya tinggi, tetapi tidak ada
pengguna utamajastifikasi utama untuk basis data tereplikasi adalah untuk
mendukung permintaan data yang hanya untuk dibaca (read-only queries).
Karena data direplikasi untuk setiap situs, akses data untuk tujuan permintaan
data dapat dilakukan, selain itu penguncian dan penundaan karena lalu lintas
jaringan dapat diminimalkan.
Karena setiap situs hanya memproses transaksi local, atribut data bersama
yang ditiru disetiap situs akan diperbarui oleh transaksi yang berbeda
sehingga pada titik waktu tertentu, akan memiliki nilai berbeda dan unik.
Pengendali Bersamaan
Pengendali bersamaan adalah hadirnya data yang lengkap dan akurat di
semua situs. Para perancang sistem harus menggunakan metode-metode
untuk memastikan bahwa transaksi yang diproses disetiap situs secara akurat
dicerminkan dalam basis data disitus-situs lainnya. Metode yang bisa
digunakan untuk pengendali bersamaan adalah membuat urutan transaksi
dengan time-stamping (pemberiancap waktu). Bagian kedua dari proses
pengendali adalah member stempel waktu untuk setiap transaksi. Sebuah jam
32. digunaka untuk menjaga semua situs, sebagian dengan wilayah waktu yang
berbeda, dengan waktu logika yang sama.
Basis Data Terdistribusi dan Akuntan
Keputusan untuk mendistribusikan basis data adalah keputusan yang
harus dipikirkan dnegan baik. Ada banytak masalah dan pertukaran yang
harus dipertimbangkan. Sebagian pertanyaan paling dasar antara lain :
Apakah data harus diorganisasikan secara terpusat atau terdistribusi?
Jika yang diinginkan adalah distribusi data, basis data harus direplikasi
atau dipartisi?
Jika direplikasi, basis data harus direplikasi seluruhnya tau sebagian saja
yang direplikasikan?
Jika basis data akan dipartisi, bagaimana segmen-segmen data hrus
dialokasikan di antara situs?
33. DAFTAR PUSTAKA
Putra, Yananto Mihadi. (2018). Sistem Manajemen Basis Data. Modul Kuliah Sistem Informasi
Manajemen. FEB - Universitas Mercu Buana: Jakarta.
http://kumpulanmakalahsim.blogspot.com/2014/05/sistem-manajemen-basis-data.html
