Teks tersebut membahas konsep manajemen basis data dan perbandingannya dengan pendekatan file datar tradisional. Secara ringkas, pendekatan basis data memiliki keunggulan karena menghilangkan redundansi data, mempermudah proses pembaruan, dan memungkinkan berbagai aplikasi untuk mengakses data secara bersama.

1. Tugas Sistem Informasi Manajemen : Sistem Manajemen Basis Data
Nama : Feliks Stevanus
NIM : 43218110078
Abstrak
Konsep manajemen Basis Data merupakan pengembangan dari konsep Flat File dalam suatu
aktifitas perancangan program/aplikasi. Konsep Flat file mulai ditinggalkan karena konsep flat file
tesebut menimbulkan beberapa kendala pada saat program antarmuka pemrosesan
berbantukan komputer ini digunakan
Pendahuluan
Dalam perkembangan pemanfaatan teknologi informasi, pemanfaatan sistem database
berkembangan menjadi suatu konsep penglolaan data base yang tersistematis yang dikenal
dengan istilah Data Base Management System (DBMS). Pemanfaatan database diharapkan
mempermudah pekerjaan dengan multiple data, namun disisi lain penerapan database
memerlukan tingkat keamanan dan persiapan awal dengan sumber daya yang cukup baik.
Bahkan dengan mekanisme DBMS-pun besaran nilai investasi awal yang tinggi juga tidak dapat
dihindari. Hal inilah yang menjadi kendala bagi para manajemen perusahaan untuk membuat
sistem database dalam manajemen data perusahaan.
Disisi lain DBMS memiliki keunggulan berupa kemudahan dalam implentasi proses kerja,
efesiensi berbagai sumber daya dalam jangka panjang baik dari sisi pembiayaan maupun sumber
daya manusia.
Literatur Teori
Mengapa Konsep Basis Data?
Aktifitas pemrosesan berbantukan komputer pada dasarnya melibatkan dua komponen: data dan
instruksi (program). Sehingga untuk mendukung kebutuhan tersebut, diperlukan perancangan
untuk mengkolaburasikan data dan instruksi (program).

2. Secara konseptual, ada dua metode untuk merancang antarmuka antara program instruksi dan
data:
- File-berorientasi pengolahan: A data spesifik yang telah dibuat untuk setiap aplikasi
- Pengolahan data berorientasi: Buat satu repositori data untuk mendukung berbagai aplikasi.
Awal mula proses perancangan tersebut, pendekatan yang digunakan adalah pendekatan file
datar (flat data). Namun pendekatan ini memiliki beberapa kekurangan. Kekurangan file
berorientasi berlebihan termasuk pengolahan data dan program dan beragam format untuk
menyimpan data yang berlebihan.
Konsep manajemen Basis Data merupakan pengembangan dari konsep Flat File dalam suatu
aktifitas perancangan program/aplikasi. Konsep Flat file mulai ditinggalkan karena konsep flat file
tesebut menimbulkan beberapa kendala pada saat program antarmuka pemrosesan berbantukan
komputer ini digunakan.
Gambaran Umum File Datar Versus Pendekatan Basis Data
Gambar berikut memperlihatkan pendekatan flat file dalam manajemen data. Dalam lingkungan
ini, pemakai memiliki file-file data mereka. Kepemilikan eksklusif terhadap data ini merllpakan
konsekuensi alami dari dua masalah yang berkaitan dengan era sistem-warisan (legacy-system
era). Sebagai berikut:
▪ Masalah pertama adalah kultur bisnis yang menimbulkan hambatan di antara unit-unit
organisasi, yang menghalangi integrasi data secara luar dalam suatu entitas.
▪ Masalah kedua berasal dari keterbatasan teknologi manajemen flat file yang mensyaratkan file
data harus distrukturkan untuk kepentingan unik pemakainya. Jadi, data sama, tetapi
digunakan dengan cara yang agak berbeda oleh para pe-makai yang berbeda, harus distruktur
ulang dan diproduksi ulang secara fisik di dalam file-file yang berbeda.

3. Untuk lebih jelasnya, file-file itu berisi gambar-gambar yang secara konseptual dilambangkan
dengan huruf-huruf. Setiap huruf menunjukkan satu atribut data (field), satu record, atau isi
seluruh file. Perhatikan juga bahwa data elemen B terdapat dalam semua file pemakai. Ini disebut
dengan pemborosan data (data redundancy), yang menjadi penyebab utama dari masalah-
masalah manajemen data penting dalam tiga bidang:
▪ penyimpanan data (data storage),
▪ pembaruan data (data updating), dan
▪ kekinian informasi (currency of information).
Di dalam setiap bidang ini, dan dalam masalah keempat, ketergantungan tugas-data (task-
data dependency), yang tidak langsung berkaitan dengan pem-borosan data, dijelaskan di bawah
ini.

4. Gambar 9-1. Manajemen Data Flat File
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 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
Program 1
X, B, YProgram 1
Transaksi Pemakai 1
Transaksi Pemakai 3
Transaksi Pemakai 2
Program 1 L, B, M
A, B, C

5. 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.
• 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.
Program 1
Program 2
Transaksi Pemakai 1
Transaksi Pemakai 3
Transaksi Pemakai 2
Program 3
A, B, C, X, Y,
L, M

6. • 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
pengguna. Jika pengguna meminta data yg dia tidak punya otoritasnya, permintaan itu
Program 1
Program 3
Transaksi Pemakai 2 A, B, C,
X, Y, L, M
D
B
M
S
Transaksi Pemakai 3
Transaksi Pemakai 1
Program 2

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

8. Gambar 9-3. Elemen-elemen Konsep Database
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 Query
Bahasa
Manipulasi
Data (DML)
Bahasa Difinisi
Data (DDL)
Proses
Pengembangan
Sistem
Program
Pengguna
Program
Pengguna
Program
Pengguna
Program
Pengguna
Aplikasi
Transaksi
Transaksi
Transaksi
Transaksi
PerimintaanSistemPengguna
Database
Fisik
Sistem
operassi
H0st
DBMS
Administrator
Database

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

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

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

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

13. 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
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
Profesional
Sistem
Administrator Basis
Data
Database
Pemakai Akhir
Kegiatan
Operasi
Manajemen

14. 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 akses data. Dua indeks
ditunjukkan dalam figure 9-7. Satu indeks berisi nomor pegawai (kunci primer) untuk
record yang ditempatkan secara unik dalam file. Indeks kedua berisi alamat record yang
diatur menurut penghasilan hingga sekarang. Dengan menggunakan field yang tidak unik
sebagai sekunder semua record karyawan dapat dilihat dengan urutan menaik atau
menurun, sesuai dengan jumlah penghasilannya. Selain itu, record individual dengan saldo
pendapatan yang dpilih dapat ditampilkan. Indeks dapat diciptakan untuk setiap atribut
dalam file sehingga memungkinkan data dapat dilihat dari banyak perspektif.

15. Model Basis Data Relasional
E.F Codd pertama kali mengajukan prinsip – prinsip model reasional di akhir tahun 1960-an.
Model formal ini didasarkan pada aljabar relasional dan serangkaian teori, yang menjadi basis
teoritis bagi sebagian besar operasi manipulasi data yang digunakan.
Dari pandangan yang murni, system relasional yang penuh adalah yang sesuai dengan 12
peraturan yang disebutkan oleh Codd. Akan tetapi, untuk tujuan praktis, tidak semua peraturan
Codd sama pentingnya. Beberapa bersifat kritis, beberapa tidak. Oleh sebab itu, ahli teori lainnya
mengusulkan persyaratan yang tidak terlalu kaku untuk menilai relasional suatu system. Sistem
disebut relasional jika :
1. Menyajikan data dalam bentuk tabel dua dimensi seperti basis data yang disebut pelanggan
pada figure 9-8.
2. Mendukung fungsi – fungsi aljabar relasional yaitu batasi (restric), proyeksikan (project), dan
gabungan (join).
Fungsi – fungsi tersebut dijelaskan di bawah ini :
Batasi : Ekstraksikan baris yang ditentukan dari tabel tertentu. Operasi ini, yang diustasikan
dalam figure 9-9 (a), menciptakan tabel virtual (yang tidak ada secara fisik) yang merupakan
bagian dari tabel aslinya.
Proyeksikan : Ekstraksikan atribut (kolom) tertentu dari tabel untuk menciptakan tabel virtual.
Ini ditunjukkan dalam figur 9-9 (b).
Gabungkan : Bangun satu tabel fisik yang baru dari dua tabel yang terdiri atas semua pasangan
baris, dari setiap tabel. Lihat figure 9-9 ©.
Meskipun batasi, proyeksikan, dan gabungkan bukan merupakan serangkaian fungsi yang lengkap,
ini adalah subrangkaian yang mencukupi untuk kebanyakan kebutuhan informasi bisnis.
Konsep Basis Data Relasional
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.

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

17. Gambar 9-9. Fungsi Aljabar Relasional – Terbatas, Proyek dan Gabungan
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.
X1 Y1
X2 Y2
X3 Y1
(a) Terbatas (a) Proyek
(c) Gabungan
Y1 Z1
Y2 Z2
Y3 Z3
X1 Y1 Z1
X2 Y2 Z2
X3 Y1 Z1

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

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

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

21. 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 1921. Ada dua record yang ditemukan. Sifat

22. 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
Kunci Asing yang
ditanamkan
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

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

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

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

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

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

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

29. 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.
Mengidentifikasi Entitas

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

31. Pemasok deskripsinya menyatakan bhawa banyak pemasok memasok persediaan,
sehingga entitas pemasok memenuhi kondisi pertama. Entitas pemasok akan termasuk
dalam model data.
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.

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

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

34. • 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
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,

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

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

37. 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 digunaka untuk
menjaga semua situs, sebagian dengan wilayah waktu yang berbeda, dengan
waktu logika yang sama.

38. 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?
Pembahasan
DBMS merupakan hal yang sangat membantu dalam efisiensi pekerjaan. Konsep manajemen
Basis Data merupakan pengembangan dari konsep Flat File dalam suatu aktifitas perancangan
program/aplikasi. Konsep Flat file mulai ditinggalkan karena konsep flat file tesebut
menimbulkan beberapa kendala pada saat program antarmuka pemprosesan berbentukan
komputer ini digunakan yang terpecahkan dengan adanya DBMS.
DBMS (Database Management System) berfungsi sebagai perangkat yang berguna untuk
mengorganisasi sumber daya data perusahaan, berikut keuntungan dengan adanya Basis data
yang dapat digunakan secara bersama:
a) Proses akses data lebih mudah dan cepat
b) Menghemat ruang penyimpanan data
c) Membantu menjaga keamanan data
d) Mencegah dan menghilangkan duplikasi dan inskonsistensi data
e) Menangani data dalam jumlah yang besar
Menurut saya paling tepat digunakan untuk perusahaan besar yang memiliki kumpulan data
yang besar. Dengan data yang besar, DBMS akan sangat bermanfaat dalam penyimpanan,
penyortiran, serta pengelelolaan data-data tersebut.
Perusahaan tempat dimana saya bekerja adalah perusahaan pengelola gedung, untuk

39. pemanfaatan DMBS sendiri yaitu terletak pada database stok gudang keperluan gedung, yang
memuat data-data barang yang diperlukan dalam pemeliharaan gedung
Data jumlah persediaan digunakan untuk mengatur sirkulasi persediaan barang yang berada
distok gudang, jika ada jumlah yang mendekati habis, maka akan diajukan permintaan untuk
barang tersebut.
Implementasi DBMS yang diterapkan di tempat saya bekerja sangat memberikan pengaruh yang
positif terhadap kinerja perusahaan. Dengan adanya DBMS, Pengumpulan data dan rekap stok
gudang menjadi lebih cepat.
Kesimpulan
DBMS merupakan hal yang sangat membantu dalam efisiensi pekerjaan. Konsep manajemen
Basis Data merupakan pengembangan dari konsep Flat File dalam suatu aktifitas perancangan
program/aplikasi. Konsep Flat file mulai ditinggalkan karena konsep flat file tesebut
menimbulkan beberapa kendala pada saat program antarmuka pemprosesan berbentukan
komputer ini digunakan yang terpecahkan dengan adanya DBMS.
DBMS (Database Management System) berfungsi sebagai perangkat yang berguna untuk
mengorganisasi sumber daya data perusahaan, berikut keuntungan dengan adanya Basis data
yang dapat digunakan secara bersama:
a) Proses akses data lebih mudah dan cepat
b) Menghemat ruang penyimpanan data
c) Membantu menjaga keamanan data
d) Mencegah dan menghilangkan duplikasi dan inskonsistensi data
e) Menangani data dalam jumlah yang besar
Implementasi DBMS yang diterapkan di tempat saya bekerja sangat memberikan pengaruh yang
positif terhadap kinerja perusahaan. Dengan adanya DBMS, Pengumpulan data dan rekap stok
gudang menjadi lebih cepat.

40. Daftar Pustaka
Putra, Y. M., (2018). Penggunaan Teknologi Informasi Pada E-Business. Modul Kuliah Sistem Informasi
Manajemen. FEB-Universitas Mercu Buana: Jakarta
Arijanto, A., Hikmah, D., & Nashar, Muhammad. (2015). Sistem Informasi Manajemen. Jakarta:
Universitas Mercu Buana. Yogyakarta: Sibuku Media
McLeod, R., & Schell, G. P. (2007). Management Information Systems. USA: Pearson/Prentice Hall.
Laudon, K. C., & Laudon, J. P. (2016). Management Information System. Pearson Education India.
Laudon, K. C., & Laudon, J. P. (2018). Management Information Systems: Managing The Digital Firm.
Pearson.
‘O'Brien, J. A., & Marakas, G. M. (2006). Management Information Systems (Vol. 6). McGraw-Hill Irwin.
O'Brien, J. A., & Marakas, G. M. (2005). Introduction to Information Systems (Vol. 13). New York City,
USA: McGraw-Hill/Irwin.