konsep basis data - dewapurnama · pdf filedapat menjelaskan pengertian basis ... yang...
Post on 23-Feb-2018
226 Views
Preview:
TRANSCRIPT
Konsep Basis Data
oleh: edhy sutanta
Teknik Informatika Jenjang S-1
Fakultas Teknologi Industri ISTA Yogyakarta
GARIS - GARIS BESAR PROGRAM PENGAJARAN (GBPP)
Nama Mata Kuliah : Konsep Basis Data
Kode Mata Kuliah : TIFS 2301
Jurusan / Fakultas : Teknik Informatika / Fakultas Teknologi Industri
Jenjang Studi : Sarjana
SKS : 3 (Tiga)
Waktu pertemuan : 150 Menit (Total : 150 menit x 14 pertemuan = 2.100 menit )
Deskripsi singkat : Perkuliahan diselenggarakan dalam 14 kali tatap muka selama satu semester. Perkuliahan diawali dengan
menjelaskan pentingnya mempelajari konsep basis data, materi, referensi, tata cara perkuliahan, tugas, serta
penilaian akhir. Materi kuliah ini meliputi Pendahuluan; Pengertian Basis Data Dan Sistem Basis Data; Tujuan Dan
Keuntungan Basis Data; Kekangan Dalam Basis Data; Pandangan Terhadap Basis Data; Model Data; Entity
Relationhip Model / Er_M; Hierarchycal Model; Semantic Model; Network Model; Relational Data Base Model;
Schema Dan Subschema; Studi Kasus Perancangan Basis Data; Pengembangan Sistem Basis Data. Ujian Tengah Semester dan Ujian Akhir Semester dilakukan secara terjadwal. Tugas kuliah akan diberikan baik
secara individu maupun kelompok guna mengevaluasi pemahaman mahasiswa terhadap materi yang dibahas.
Tujuan Instruksional Umum :
Setelah mengikuti mata kuliah ini mahasiswa mampu menjelaskan dan menerapkan konsep pengarsipan data
secara basis data untuk keperluan perancangan basis data dalam rangka pengembangan sistem pengolahan data
berbasis komputer dan Sistem Informasi Manajemen.
No Tujuan Instruksional Khusus Pokok Bahasan Sub Pokok Bahasan Estimasi Waktu Pustaka 1 Setelah mengikuti kuliah ini mahasiswa
dapat menjelaskan perbedaan data dan informasi, konsep pengolahan data, alasan pentingnya basis data, pengetahuan yang relevan
Pendahuluan 1. Pengantar: kaitan mata kuliah basis data 1 dan kurikulum secara keseluruhan, materi, referensi, tatacara perkuliahan, tugas, evaluasi akhir
2. Data & informasi 3. Pentingnya memahami konsep basis data 4. Pengetahuan yang harus dipahami
30 1-14
2 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan pengertian basis data dan sistem basis data, dan aspek terkait dengan pengertian tersebut
Pengertian Basis Data Dan Sistem Basis Data
1. Pengertian basis data 2. Pengertian sistem basis data 3. Hirarkhi data 4. Perkembangan konsep basis data 5. Peranan basis data dalam sim
150 1-14
3 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan tujuan dan keuntungan basis data
Tujuan Dan Keuntungan Basis Data
1. Tujuan primer basis data 2. Tujuan sekunder basis data 3. Keuntungan basis data
120 1-14
4 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan kekangan dalam basis data
Kekangan Dalam Basis Data
1. Kerangkapan data 2. Inkonsistensi data 3. Data terisolasi 4. Keamanan data 5. Integritas data
300 1-14
5 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan pandangan terhadap basis data
Pandangan Terhadap Basis Data
1. Macam pandangan terhadap basis data 2. Level pandangan terhadap basis data 3. Interface antar pandangan terhadap basis data 4. Independensi data (data independency)
200 1-14
6 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan model data
Model Data 1. Definisi model data 2. Macam model data 3. Perangkat lunak yang tersedia
50 1-14
7 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan Entity Relationhip Model / Er_M
Entity Relationhip Model / Er_M
1. Komponen ER_Model 2. Entitas 3. Atribut 4. Kerelasian antar entitas 5. Menggambar ER_D
200 1-14
8 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan hierarchycal model
Hierarchycal Model 1. Model data hierarchycal model 2. Menggambar hierarchycal model
100 1-14
9 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan semantic model
Semantic Model 1. Model data semantic model 2. Menggambar hierarchycal model
50 1-14
10 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan network model
Network Model 1. Model data network model 2. Menggambar network model
50 1-14
11 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan Relational Data Base Model
Relational Data Base Model
1. Terminologi 2. Karakteristik basis data model relasional 3. Komponen relasi 4. Kunci relasi 5. Ketergantungan data 6. Kerelasian antar relasi 7. Penyimpangan dalam pengolahan 8. Teknik normalisasi
450 1-14
12 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan schema dan subschema
Schema Dan Subschema 1. Definisi schema dan subschema 2. Schema, subschema, model data, dan diagram kerelasian
antar relasi 3. Notasi relasi, schema, dan subschema 4. Instance schema
150 1-14
13 Setelah mengikuti kuliah ini mahasiswa dapat merancang basis data untuk subsistem pengolahan data
Studi Kasus Perancangan Basis Data
1. Teknik dan langkah perancangan basis data 2. Contoh rancangan basis data
150 1-14
14 Setelah mengikuti kuliah ini mahasiswa dapat menjelaskan aspek-aspek pengembangan sistem basis data
Pengembangan Sistem Basis Data
1. Tujuan pengembangan sistem basis data 2. Langkah pengembangan sistem basis data 3. Analisis kelayakan pengembangan sistem basis data 4. Perhitungan manfaat aplikasi sistem basis data secara
kuantitatif 5. Analisis beaya manfaat dari alternatif desain sistem basis
data 6. Kelemahan pendekatan sistem basis data
100 1-14
TOTAL WAKTU YANG DIPERLUKAN :
2100 menit (= 14 x 150 )
DAFTAR PUSTAKA 1. Atre, S., 1980, Database : Structured Techniques For Design, Performance And
Management With Case Study, Canada, John Wiley & Sons, Inc. 2. Austing, R.H., 1988, File Organization And Acces, USA, DC Heat & Co. 3. Courtney, J.F. Jr. and Paradice, D.B., 1988, Database Systems For Management,
1st edition, USA, Times Mirror / Mosby College Publishing 4. Date, C.J., 1995, An Introduction To Database Systems, Adisson Wesley
Publishing, Co., Inc. 5. Elmasri, R. and Navathe, S., 1994, Fundamental Of Databases System, 2nd
edition, Redwood City, The Benjamin Cummings Publishing, Co., Inc. 6. Harbon, T.R., 1988, File Systems, USA, Prentice Hall, Inc. 7. Korth, H.F. and Silberschatz, A., 1986, Database Systems Concept, USA,
Mc.Graw-Hill International, Co. 8. Kroenke, D.M., 1983, Database Processing: Fundamental, Design,
Implementations, 2nd edition, Chicago, Science Research Associates, Inc. 9. Kruglinski, D., 1986, Data Base Managament Systems, USA, Mc.Graw-Hill
International, Co. 10. Lomis, E.S., 1989, Data Management And File Structures, USA, Prentice Hall,
Inc. 11. Martin, J., 1975, Computer Database Organizations, parth I, New Jersey,
Prentice-Hall, Inc. 12. Martin, J., 1976, Computer Database Organizations, parth II, New Jersey,
Prentice-Hall, Inc. 13. Parsaye, K., Chignell, M., Khoshafian, S., Wong, H., 1989, Intelligent
Databases, Nanada, Jhon Wiley & Sons, Inc. 14. Stamper, D., 1990, Database Design And Management An Applied Approach,
International edition, Singapore, Mc.Graw-Hill International, Co. 15. Tharp, A.L., 1988, File Organization And Processing, Singapore, John Wiley &
Sons, Inc. 16. Ulman, J.D., 1982, Principles Of Database System, Rockville, Computer Press,
Inc. 17. Wiederhold, G., 1988, Database Design, 2nd edition, Singapore, Mc.Graw-Hill
International, Co.
1
BBAABB II PPEENNDDAAHHUULLUUAANN
11..11.. PPeerrkkeemmbbaannggaann KKoonnsseepp BBaassiiss DDaattaa
Pengetahuan tentang konsep basis data muncul dan mulai berkembang seiring dengan
adanya kebutuhan pengolahan data untuk memenuhi kebutuhan informasi.
Perkembangan konsep basis data dapat dibedakan dalam 5 tahapan, yaitu :
1. Tahap I (awal tahun 1960-an)
2. Tahap II (akhir tahun 1960-an)
3. Tahap III (awal tahun 1970-an)
4. Tahap IV (mulai tahun 1980-an)
5. Tahap V (mulai tahun 1990-an)
1. Tahap I (awal tahun 1960-an) Perkembangan teknologi komputer yang ditemukan pada sekitar tahun 1945, telah
melahirkan pandangan dan pengetahuan baru tentang konsep penyimpanan data dalam
basis data, yang sebelumnya banyak menggunakan cara-cara manual. Konsep-konsep
tentang basis data yang berkembang pada masa itu dikenal sebagai konsep basis data
Tahap I. Ciri konsep basis data pada Tahap I ini adalah data-data diolah berdasarkan
prinsip berkas (file processing) pada lingkungan komputer mainframe.
2. Tahap II (akhir tahun 1960-an) Pada akhir tahun 1960-an terjadi kemajuan dan perubahan yang mencolok dalam
konsep basis data dan selanjutnya konsep-konsep tentang basis data pada masa
tersebut disebut sebagai konsep basis data Tahap II. Konsep basis data pada tahap
kedua telah mengubah dan memperbaiki metoda penyimpanan dalam basis data. Ciri
utama konsep basis data pada Tahap II ini adalah konsep sistem basis data (Data Base
Systems / DBS), konsep sistem manajemen basis data data (Data Base Management
Systems / DBMS), layanan informasi secara online dan layanan informasi berbasis teks.
2
3. Tahap III (awal tahun 1970-an) Perkembangan metoda penyimpanan data dalam basis data yang lebih baik terjadi pada
awal tahun 1970-an. Perangkat keras penyimpanan yang digunakan saat itu telah
semakin baik. Kondisi demikian telah mempengaruhi pandangan dan pengetahuan
tentang konsep basis data yang semakin baik pula. Selanjutnya, konsep-konsep basis
data saat itu disebut sebagai konsep basis data tahap ketiga. Ciri utama konsep basis
data pada Tahap III ini adalah kemunculan aplikasi-aplikasi basis data berbasis sistem
pakar (Expert Systems / ES) dalam sistem pendukung keputusan (Decission Support
Systems / DSS), serta pemrograman berorientasi obyek (Object oeriented Programming
/ OOP).
4. Tahap IV ( mulai tahun 1980-an) Perkembangan yang sangat cepat pada teknologi komputer dan penyimpanan data
sejak tahun 1980-an telah mempengaruhi pandangan dan pengetahuan dalam konsep
basis data. Hal ini mengakibatkan munculnya perubahan-perubahan pandangan dan
pengetahuan baru tentang konsep basis data. Konsep-konsep basis data pada masa
tersebut dikenal sebagai konsep basis data tahap keempat. Ciri utama konsep basis
data pada Tahap IV ini adalah sistem berbasis hypertext yang memungkinkan
penampilan informasi berdasarkan suatu kata kunci pencarian yang dapat dilakukan
secara acak.
5. Tahap V (mulai tahun 1990-an) Perkembangan konsep basis data pada tahun 1990-an telah berkembang ke arah
aplikasi-aplikasi basis data untuk sistem kecerdasaan buatan (Artificial Intelligent / AI),
basis data untuk aplikasi-aplikasi multimedia yang melibatkan data teks, suara, gambar,
dan animasi, aplikasi basis data berorientasi obyek (Object Oriented Data Base /
OODB), serta aplikasi-aplikasi basis data secara online (online data base) untuk jaringan
komputer global / internet. Aplikasi konsep basis data kabur (fuzzy) juga mewarnai
konsep basis data pada masa ini.
3
11..22.. AApplliikkaassii BBaassiiss DDaattaa
Saat ini, aplikasi basis data telah mencakup seluruh kehidupan manusia. Beberapa
contoh aplikasi basis data dalam dunia nyata adalah:
1. Industri manufaktur: produksi, persediaan, pemesanan
2. Manajemen rumah sakit: registerasi, rekam medis, perawatan
3. Manajemen perpustakaan: seluruh transaksi
4. Perhotelan: seluruh transaksi
5. Perbankan: melayani seluruh transaksi
6. Perguruan tinggi: mahasiswa, keuangan, akuntansi, lulusan
7. Penerbangan: reservasi, jadwal penerbangan
8. Penjualan: pelanggan, produk, penjualan, pemasaran
9. Personalia: rekaman karyawan, gaji, pajak
10. Dan lain-lain
11..33.. DDaattaa ddaann IInnffoorrmmaassii
Data dapat didefinisikan sebagai bahan keterangan tentang kejadian-kejadian nyata
atau fakta-fakta yang dirumuskan dalam sekelompok lambang tertentu yang tidak acak
yang menunjukkan jumlah, tindakan, atau hal. Data dapat berupa catatan-catatan dalam
kertas, buku, atau tersimpan sebagai file dalam basis data. Data akan menjadi bahan
dalam suatu proses pengolahan data. Oleh karenanya, suatu data belum dapat
berbicara banyak sebelum diolah lebih lanjut. Contoh data adalah catatan identitas
pegawai, catatan transaksi pembelian, catatan transaksi penjualan, dan lain-lain.
Informasi merupakan hasil pengolahan data sehingga menjadi bentuk yang penting bagi
penerimanya dan mempunyai kegunaan sebagai dasar dalam pengambilan keputusan
yang dapat dirasakan akibatnya secara langsung saat itu juga atau secara tidak
langsung pada saat mendatang. Untuk memperoleh informasi, diperlukan adanya data
yang akan diolah dan unit pengolah. Contoh informasi adalah daftar pegawai
berdasarkan departemen, daftar pegawai berdasarkan golongan, rekapitulasi transaksi
pembelian pada akhir bulan, rekapitulasi transaksi penjualan pada akhir bulan, dan lain-
lain.
4
Transformasi data menjadi informasi dapat digambarkan sebagaimana ditunjukkan oleh
Gambar 1.1. Dalam gambar tersebut, input adalah data (dalam basis data) yang akan
diolah oleh unit pengolah, dan output adalah informasi sebagai hasil pengolahan data
yang telah diinputkan tersebut. Suatu unit penyimpan (memori sekunder) diperlukan
sebagai alat simpanan data, pengolah, maupun informasi.
Input Unit Pengolah Output
Unit Penyimpan
Gambar 1.1: Transformasi data menjadi informasi
Informasi yang diperoleh dari pengolahan data dapat dinilai berdasarkan sifatnya. Sifat
informasi yang menentukan nilai informasi, adalah:
1. Kemudahan dalam memperoleh
2. Sifat luas dan kelengkapannya
3. Ketelitian (accuracy)
4. Kecocokan dengan pengguna (relevance)
5. Ketepatan waktu
6. Kejelasan (clarity)
7. Fleksibilitas / keluwesannya
8. Dapat dibuktikan
9. Tidak ada prasangka
10. Dapat diukur
Informasi diperlukan oleh para pemakai (manajemen) pada seluruh level manajemen
dalam seluruh fungsi organisatoris. Informasi tersebut dapat mempunyai beberapa
fungsi, antara lain:
1. Menambah pengetahuan
Adanya informasi akan menambah pengetahuan bagi penerimanya yang dapat
digunakan sebagai bahan pertimbangan yang mendukung proses pengambilan
keputusan.
5
2. Mengurangi ketidakpastian
Adanya informasi akan mengurangi ketidakpastian karena apa yang akan terjadi
dapat diketahui sebelumnya, sehingga menghindari keraguan pada saat
pengambilan keputusan.
3. Mengurangi resiko kegagalan
Adanya informasi akan resiko kegagalan karena apa yang akan terjadi dapat
diantisipasi dengan baik, sehingga kemungkinan terjadinya kegagalan akan dapat
dikurangi dengan pengambilan keputusan yang tepat.
4. Mengurangi keanekaragaman / variasi yang tidak diperlukan
Adanya informasi akan mengurangi keanekaragaman yang tidak diperlukan, karena
keputusan yang diambil lebih terarah.
5. Memberi standar, aturan-aturan, ukuran-ukuran, dan keputusan-keputusan yang
menentukan pencapaian sasaran dan tujuan
Adanya informasi akan memberikan standar, aturan, ukuran, dan keputusan yang
lebih terarah untuk mencapai sasaran dan tujuan yang telah ditetapkan secara lebih
baik berdasar informasi yang diperoleh.
Pengelompokan fungsi organisatoris pada setiap organisasi tidak pernah seragam.
Namun demikian, pada umumnya fungsi-fungsi dalam suatu organisasi meliputi:
1. Produksi, meliputi kegiatan produksi, produk keteknikan, dan lain-lain.
2. Pemasaran, meliputi kegiatan riset pasar, periklanan, promosi, penjualan, dan lain-
lain.
3. Logistik, meliputi kegiatan pembelian, persediaan, distribusi, dan lain-lain.
4. Keuangan dan akuntansi, meliputi kegiatan pembelanjaan, akuntansi keuangan,
akuntansi biaya, penganggaran, dan lain-lain.
Kebutuhan informasi pada setiap fungsi operasi dalam manajemen dan pada setiap
level manajemen akan berbeda-beda. Kebutuhan informasi tersebut tergantung pada
tiga macam faktor, yaitu:
1. Fungsi operasional
2. Kegiatan manajemen
3. Pembuatan keputusan
6
Perbedaan kebutuhan informasi terletak pada isi dan ciri informasi yang dibutuhkan. Isi
informasi untuk setiap fungsi operasional tergantung pada fungsi masing-masing, misal
isi informasi untuk fungsi pemasaran adalah berbeda dengan isi informasi untuk fungsi
personalia. Sedangkan ciri informasi bergantung pada tingkat kegiatan manajemen yang
mempengaruhi pembuatan keputusan. Informasi untuk kegiatan manajemen tingkat atas
berbeda dengan informasi yang dibutuhkan untuk kegiatan manajemen tingkat
menengah dan bawah. Manajemen tingkat atas memerlukan informasi yang tersaring
dan tidak terinci.
11..44.. SSiisstteemm IInnffoorrmmaassii MMaannaajjeemmeenn ddaann BBaassiiss DDaattaa
Sistem Informasi Manajemen / SIM dapat didefinisikan sebagai sekumpulan subsistem
yang saling berhubungan, berkumpul bersama-sama dan membentuk satu kesatuan,
saling berinteraksi dan bekerjasama antara bagian satu dengan yang lainnya dengan
cara-cara tertentu untuk melakukan fungsi pengolahan data, menerima masukan (input)
berupa data-data, kemudian mengolahnya (processing), dan menghasilkan keluaran
(output) berupa informasi sebagai dasar bagi pengambilan keputusan yang berguna dan
mempunyai nilai nyata yang dapat dirasakan akibatnya baik pada saat itu juga maupun
di masa mendatang, mendukung kegiatan operasional, manajerial, dan strategis
organisasi, dengan memanfaatkan berbagai sumber daya yang ada dan tersedia bagi
fungsi tersebut guna mencapai tujuan.
Berdasarkan komponen fisik penyusunnya, SIM terdiri atas komponen berikut:
1. Perangkat keras (hardware)
Perangkat keras dalam SIM meliputi piranti-piranti yang digunakan oleh sistem
komputer untuk masukan dan keluaran (input / output device), memory, modem,
pengolah (processor), dan peripheral lain
2. Perangkat lunak (software)
Perangkat lunak dalam Sistem Informasi Manajemen adalah berupa program-
program komputer yang meliputi sistem operasi (Operating System / OS), bahasa
pemrograman (Programming Language), dan program-program aplikasi (Application)
3. Berkas basis data (file)
7
Berkas merupakan sekumpulan data dalam basis data yang disimpan dengan cara-
cara tertentu sehingga dapat digunakan kembali dengan mudah dan cepat.
4. Prosedur (procedure)
Prosedur meliputi prosedur pengoperasian untuk SIM, manual, dan dokumen-
dokumen yang memuat aturan-aturan yang berhubungan dengan sistem informasi
dan lainnya.
5. Manusia (brainware)
Manusia yang terlibat dalam suatu SIM meliputi operator, programmer, system
analyst, manajer sistem informasi, manajer pada tingkat operasional, manajer pada
tingkat manajerial, manajer pada tingkat strategis, teknisi, administrator basis data (
Data Base Administrator / DBA), serta individu lain yang terlibat di dalamnya.
Basis data merupakan bagian penting dalam sebuah SIM. Basis data dalam SIM dapat
mempunyai peranan sebagai berikut:
1. Basis data sebagai komponen penyusun SIM
Basis data merupakan salah satu komponen terpenting dalam sebuah SIM. Sebagai
komponen penyusun SIM, maka keberadaan basis data dalam SIM mutlak harus
ada. Suatu SIM tidak akan berfungsi, bahkan tidaka akan terwujud tanpa melibatkan
basis data.
Hubungan antara SIM dan basis data di dalam SIM merupakan hubugan antara
sistem dan subsistem. Dalam hal ini SIM adalah sebagai sistem karena mempunyai
ruang lingkup yang lebih luas dan lebih kompleks, sedangkan basis data menjadi
sub sistem karena menjadi bagian SIM. Basis data akan menjadi bahan baku bagi
SIM.
2. Basis data sebagai infrastruktur SIM
Basis data dan sistem manajemen basis data (Data Base Management Systems /
DBMS) menyediakan suatu sarana infrastruktur kepada organisasi-organisasi sistem
informasi yang dibangun. Organisasi sistem informasi yang dimaksud adalah sistem
pengolahan transaksi (Transaction Processing Systems / TPS), sistem informasi
manajemen (Management Information Systems / MIS), sistem pendukung keputusan
(Decission Support Systems / DSS), otomatisasi perkantoran (Office Automatitation
/ OA), serta sistem informasi eksekutif (Executive Information Systems / EIS).
3. Basis data sebagai sumber informasi bagi SIM
8
Basis data mempunyai peran penting dalam SIM, yaitu sebagai sumber penyedia
informasi utama untuk memenuhi kebutuhan-kebutuhan informasi seluruh pemakai
atau infoomasi bagi para pengambil keputusan. Dengan adanya keterkaitan antara
data dan informasi, maka basis data berperan sebagai data dalam sistem
pengolahan data. DBMS berperan melakukan manajemen basis data sehingga
diperoleh bentuk yang penting berupa informasi yang dapat digunakan sebagai
dasar pengambilan keputusan-keputusan manajemen.
Keputusan manajemen ditetapkan oleh para manajer pada seluruh level
manajemen untuk seluruh kegiatan dalam seluruh subsistem fungsional yang ada.
Terdapat tiga kategori keputusan yang ada dalam sebuah organisasi, yaitu
perencanaan dan pengendalian operasional, perencanaan dan pengendalian taktis,
dan perencanaan strategis. Masing-masing kategori keputusan tersebut memerlukan
kebutuhan informasi yang berbeda-beda.
Para manajer level operasional, akan menggunakan sebagian besar waktunya untuk
menetapkan keputusan-keputusan yang berhubungan dengan kegiatan operasional.
Informasi yang diperlukan cenderung dapat diperoleh dari sumber-sumber internal
organisasi dengan definisi yang jelas, terinci, mempunyai lingkup yang sempit, serta
frekuensi pemakaian yang sangat sering.
Para manajer level menengah, basis data berfungsi sebagai sumber informasi untuk
pengambilan keputusan-keputusan untuk perencanaan taktis dan pengendalian
manajemen sebagai kontrol terhadap organisasi. Pada level ini informasi diperoleh
dan dihasilkan dengan cara peringkasan dan abstraksi data-data transaksi pada
level operasional. Informasi pengendalian manajemen diperlukan untuk mengukur
prestasi, memutuskan tindakan pengendalian, merumuskan aturan keputusan baru
untuk diterpkan orang-orang pada level operasional, serta mengalokasikan sumber
daya yang tersedia. Proses pengendalian memerlukan informasi yang berkaitan
dengan perencanaan (standar, yang diharapkan, yang dianggarkan, dan
sebagainya); perbedaan pelaksanaan terhadap rencana; alasan penyebab
terjadinya perbedaan; serta analisis keputusan atau arah tindakan yang mungkin.
Beberapa informasi eksternal sangat mungkin tersedia dalam basis data, seperti
indeks harga, suku bunga, pajak, dan lainnya.
Dukungan basis data bagi perencanaan strategis bisa jadi tidak dapat selengkap
dua level sebelumnya. Namun demikian, basis data yang ada dalam SIM dapat
memberikan bantuan dan dukungan yang cukup bagi proses perencanaan strategis.
9
Beberapa contoh dukungan yang bisa diberikan pada level inia dalah evaluasi
kemampuan yang didasarkan atas data internal yang ditimbulkan oleh transaksi-
transaksi; proyeksi kemampuan mendatang yang dikembangkan melalui data
lampau; serta data tentang kompetitor / pesaing yang direkam dalam basis data.
Informasi-informasi bagi perencanaan strategis berisikan fakta keras dan lebih
banyak didasarkan atas penilaian. Masuknya desas-desus, fakta, dugaan, perkiraan
dan sebagainya yang meresap ke dalam penilaian prospek, pasar, industri, ekonomi,
politik, keamanan, dan sebagainya merupakan alasan kesulitan pengkodean secara
efisien untuk mendukung keputusan pada level strategis ini.
Pada akhirnya tim pengembangan SIM harus mampu merancang basis data yang
cukup lengkap secara benar agar mampu memberikan dukungan maksimal terhadap
ketiga macam kebutuhan tersebut di atas.
4. Basis data sebagai sarana mencapai efisiensi SIM
Basis data dirancang dan dibangun dengan orientasi kebutuhan informasi bagi
seluruh pemakai dalam sistem. Selain lengkap, basis data harus dirancang agar
mudah digunakan, diakses dengan cepat, dapat digunakan dengan berbagai macam
cara, oleh banyak pemakai baik secara terpisah maupun bersama-sama,
kerangkapan data minimal, serta menjaga integritas data di dalamnya.
Pengembangan basis data memang mahal, tetapi mulai saat tertentu penggunaan
basis data akan memberikan banyak manfaat yang mempuyai nilai ekonomis.
Penggunaan basis data akan memberikan banyak manfaat yang tidak mungkin
diperoleh sebelumnya, utamanya dalam hal penggunaan waktu, kertas kerja,
personalia, serta beaya-beaya. Dengan demikian, pada akhirnya efisiensi SIM akan
diperoleh berkat basis data yang disusun dengan baik dan benar.
5. Basis data sebagai sarana mencapai efektifitas SIM
Basis data akan memberikan dukungan bagi tercapainya efektifitas SIM, karena
data-data yang disimpan sebagai file-file basis data hanya memuat data yang benar.
Perangkat lunak pengelolaan basis data yang digunakan juga harus melewati proses
uji yang panjang sehingga memberikan jaminan proses dapat dilakukan dengan
benar, jaminan akurasi data, serta kehandalan sistem secara keseluruhan. Dengan
demikian, basis data dan DBMS yang ada di dalam SIM akan memberikan dukungan
yang besar terhadap efektifitas SIM.
10
11..55.. PPeennggeelloollaa SSiisstteemm IInnffoorrmmaassii
Pada masa awal penggunaan komputer, banyak perusahaan yang membentuk unit
organisasi tersendiri yang terdiri dari para spesialis yang bertanggung jawab untuk
menerapkan sistem. Namun kecenderungan yang terjadi saat ini adalah bagian
pengolah data merupakan kesatuan organisasi utama tersendiri.
Spesialis informasi (information specialist) menggambarkan pegawai perusahaan yang
bertanggung jawab penuh untuk mengembangkan dan memelihara sistem informasi
berbasis komputer (Computer Based Information Systems / CBIS). Spesialis informasi
digolongkan menjadi lima macam, yaitu:
1. Analis sistem, adalah pakar dalam mendefinisikan masalah dan menyiapkan
dokumentasi tertulis mengenai cara komputer membantu pemecahan masalah.
Analis sistem bekerja sama dengan pemakai mengembangkan sistem baru dan
memperbaiki sistem yang ada sekarang.
2. Pengelola basis data (Data Base Administrator / DBA), bekerja sama dengan
pamakai dan analis sistem menciptakan basis data yang berisi data yang diperlukan
untuk menghasilkan informasi bagi pemakai. Selanjutnya, pengelola basis data
mengelola basis data sebagai sumber daya penting bagi perusahaan.
3. Spesialis jaringan (network specialist), adalah orang yang ahli dalam bidang
komputer dan telekomunikasi. Spesialis jaringan bekerja sama dengan analis sistem
dan pemakai membentuk jaringan komunikasi data yang menyatukan berbagai
sumber daya komputer yang tersebar.
4. Pemrogram (programmer), bekerja dengan menggunakan dokumentasi yang
disiapkan oleh analis sistem untuk membuat kode program dalam bahasa tertentu
untuk memproses data masukan yang tersedia menjadi keluaran berupa informasi
bagi para pemakai.
5. Operator, mengoperasikan peralatan komputer berskala besar (misal: main frame,
mini), memantau layar komputer, mengganti ukuran kertas di printer, mengelola
perpustakaan disk storage, dan lain - lain.
11
11..66.. PPeennttiinnggnnyyaa MMeemmaahhaammii KKoonnsseepp BBaassiiss DDaattaa
Data dalam organisasi dianggap sebagai sumber daya dasar yang penting. Bagi semua
organisasi tugas utama yang harus dilakukan adalah mengumpulkannya dan
menggunakannya untuk kebutuhan bisnis. Bentuk umum menyimpan data berubah dari
buku besar ke berkas komputer. Saat organisasi berkembang, kesulitan untuk
mengelola data dengan volume yang besar menjadi meningkat. Hal ini menuntut
perlunya DBMS untuk melakukan fungsi-fungsi pengelolaan data dan menjadikannya
tersedia bagi pemakai. Secara umum, kelebihan pemanfaatan sistem basis data
dibanding sistem tradisional adalah bersifat kompak, tidak menjemukan, cepat, akurat,
mutakhir.
Tanpa mengabaikan komponen lainnya, keberhasilan sebuah SIM sangat bergantung
pada basis data yang digunakan. Basis data yang lengkap, akurat, mudah digunakan,
dan efisien akan meningkatkan kualitas SIM. Adalah penting untuk menyusun basis data
yang baik dan benar, agar mampu memenuhi semua / sebagian besar kebutuhan
informasi bagi para pemakai dan pengambil keputusan.
Bekal yang sangat berharga akan diperoleh bagi para mahasiswa atau siapapun yang
akan terjun dan berkecimpung dalam dunia pengolahan data, SIM, dan basis data,
apabila mampu memahami aspek teori dan konsep basis data. Mempelajari teori dan
konsep akan memberikan dasar, memberikan arah berpikir, bersikap dan bertindak
secara obyektif dalam menghadapi perkembangan dan kemajuan ilmu pengetahun dan
teknologi. Pemahaman yang kuat tentang konsep basis data akan menghindari
kerancuan, kebingungan, dalam menerima teknologi baru yang berkembang pesat dan
semakin cepat. Mempelajari teori dan konsep basis data akan memberikan kerangka
kerja dan berpikir sehingga mampu menyederhanakan suatu persoalan kompleks
menuju penyelesaian yang efektif dan efisien. Ini jauh lebih bermanfaat, karena akan
membantu dalam menyusun pengalaman lampau dan meringkasnya untuk kepentingan
yang akan muncul dan harus dihadapi pada saat ini dan mendatang. Pemahaman yang
komprehensif tentang konsep basis data ini akan memerlukan dukungan pemahaman
tentang beberapa hal, antara lain:
12
1. Aplikasi basis data
2. Bahasa SQL
3. Manajemen basis data
4. Manajemen dan bisnis
5. Software basis data
6. Hardware / teknologi informasi
Materi tentang aspek-aspek pendukung tersebut dapat dijumpai dalam buku-buku yang
telah banyak beredar saat ini.
1
BBAABB IIII PPEENNGGEERRTTIIAANN BBAASSIISS DDAATTAA DDAANN SSIISSTTEEMM BBAASSIISS DDAATTAA
22..11.. PPeennggeerrttiiaann BBaassiiss DDaattaa
Sebagaimana ketika kita mempelajari bidang-bidang ilmu yang lain, ada satu hal penting
yang perlu diketahui sebelum seseorang melangkah belajar lebih jauh, yaitu terlebih
dahulu perlu mengetahui dengan jelas tentang arti dan batasan obyek yang ditinjau.
Pemahaman arti dan batasan tersebut akan memberikan dasar yang mempermudah
ketika mempelajari bagian-bagian yang lebih lanjut.
Dalam beberapa literatur, basis data telah didefinisikan dengan cara yang berbeda-
beda. Salah satu definisi cukup lengkap dan baik tentang istilah basis data adalah
pengertian yang diberikan oleh James Martin (1975) yaitu sebagai berikut :
“A database may be defined as a collection of interrelated data stored together
without harmful or unnecessary redundancy to serve one or more applications in
an optimal fashion; the data are stored so that they are independent of programs
with use the data; a common and controlled approach its used in adding new
data and in modifying and retrieving existing data within the database”.
Dengan memahami pengertian di atas, maka istilah basis data dapat dipahami
sebagai suatu kumpulan data terhubung (interrelated data) yang disimpan secara
bersama-sama pada suatu media, tanpa mengatap satu sama lain atau tidak perlu
suatu kerangkapan data (kalaupun ada maka kerangkapan data tersebut harus
seminimal mungkin dan terkontrol (controlled redundancy)), data disimpan dengan cara-
cara tertentu sehingga mudah untuk digunakan / atau ditampilkan kembali; data dapat
digunakan oleh satu atau lebih program-program aplikasi secara optimal; data disimpan
tanpa mengalami ketergantungan dengan program yang akan menggunakannya; data
disimpan sedemikian rupa sehingga proses penambahan, pengambilan dan modifikasi
data dapat dilakukan dengan mudah dan terkontrol.
Berdasarkan pengertian tersebut, maka suatu basis data mempunyai beberapa kriteria
penting yang harus dipenuhi, yaitu :
2
1. Berorientasi pada data (data oriented) dan bukan berorientasi pada program
(program oriented) yang akan menggunakannya.
Untuk memenuhi kriteria ini, maka basis data harus disimpan secara terpisah
dengan program aplikasinya. Umumnya, paket-paket aplikasi pengelolaan basis
data (Data Base Management Systems / DBMS) yang tersedia telah dirancang
sedemikian rupa sehingga basis data akan disimpan sebagai sekumpulan file
yang terpisah dengan program yang mengaksesnya.
2. Data dapat digunakan oleh pemakai yang berbeda-beda atau beberapa program
aplikasi tanpa perlu mengubah basis data.
Data-data yang tersimpan dalam basis data akan digunakan oleh pemakai, yaitu
individu-individu yang berbeda, sesuai dengan area kerjanya masing-masing.
Sebagai contoh, pada suatu universitas, pemakai dapat terdiri atas karyawan
yang bekerja di bagian akademik, karyawan di bagian keuangan, karyawan di
bagian perpustakaan, karyawan di bagian kepegawaian, karyawan di bagian
kemahasiswaan, dan lainnya.
Pemakai basis data juga dapat berupa program-program aplikasi yang berbeda.
Program-program aplikasi tersebut akan menjadi bagian atau subsistem-
subsistem yang ada dalam lingkup sistem yang lebih besar. Sebagai contoh,
pada suatu universitas, program aplikasi yang megakses basis data dapat
berupa subsistem akademik, subsistem keuangan, subsistem perpustakaan,
subsistem kepegawaian, subsistem kemahasiswaan, subsistem inventaris, dan
lainnya.
3. Data dalam basis data dapat berkembang dengan mudah baik volume
maupun strukturnya
Data-data di dalam basis data akan mengalami perkembangan dari waktu ke
waktu. Dalam sebuah universitas misalnya, data-data mahasiswa akan selalu
bertambah setiap awal tahun akademik karena penambahan mahasiswa baru
(juga mengalami pengurangan karena ada mahasiswa yang lulus), data
pengambilan mata kuliah akan bertambah setiap awal semester, data perolehan
nilai mahasiswa akan bertambah setiap akhir semester, dan lainnya.
Struktur basis data juga dapat mengalami perubahan seiring dengan kebutuhan
subsistem-subsistem pengolahan data yang baru. Misal, ketika diinginkan untuk
mengembangkan subsistem pengolahan data praktikum di laboratorium, maka
3
data-data yang baru bisa ditambahkan tanpa mengubah struktur basis data yang
telah ada dengan tetap menjaga hubungan antar datanya.
4. Data yang ada dapat memenuhi kebutuhan sistem-sistem baru secara mudah
Ketika terjadi penambahan / perubahan kebutuhan sistem yang baru, maka data-
data dalam basis data harus dapat memenuhinya. Data-data yang telah
tersimpan sebagai basis data, harus tetap dapat digunakan tanpa perlu
mengubahnya. Hal ini dapat terjadi hanya jika basis data dirancang sedemikian
rupa sehingga ketika muncul kebutuhan-kebutuhan baru, data yang telah
tersimpan tetap dapat digunakan tanpa harus dirubah. Dan data-data baru dapat
dtambahkan dengan tetap saling berhubungan.
5. Data dapat digunakan dengan cara yang berbeda-beda.
Akses terhadap data-data dalam basis data dapat dilakukan dengan cara-cara
yang berbeda. Data dalam basis data dapat diakses menggunakan program
aplikasi, menggunakan instruksi-instruksi yang bersifat interaktif, menggunakan
bahasa query, dan lainnya.
6. Kerangkapan data (data redundancy) minimal
Kerangkapan data merupakan permasalahan kritis dalam basis data. Data-data
dalam basis data semestinya tidak perlu disimpan secara berulang.
Kerangkapan data akan mengakibatkan permasalahan yang menyulitkan ketika
dilakukan pengolahan data di kemudian hari.
Keenam kriteria tersebut telah membedakan secara nyata antara pengorganisasian data
secara basis data (database processing) dan pengelolaan data dalam file tradisional (file
processing), yaitu:
1. Hanya dapat digunakan oleh satu program aplikasi
2. Berhubungan dengan suatu persoalan tertentu untuk sistem yang direncanakan
3. Perkembangan data hanya mungkin terjadi pada volume data saja
4. Hanya dapat digunakan dengan satu cara tertentu saja
5. Kerangkapan data terlalu sering muncul
4
22..22.. PPeennggeerrttiiaann SSiisstteemm BBaassiiss DDaattaa
Istilah sistem basis data tentu saja berbeda dengan istilah basis data. Sistem baiss data
merupakan lingkup yang lebih luas dari pada basis data. Sistem basis data merupakan
sekumpulan basis data dalam suatu sistem yang mungkin tidak ada hubungan satu
sama lain, tetapi secara keseluruhan mempunyai hubungan sebagai sebuah sistem
dengan didukung oleh komponen lainnya.
Dalam keseharian, sering terjadi kerancuan makna antara istilah basis data dan sistem
basis data, dan semestinya perlu dibedakan. Sistem basis data dapat didefinisikan
sebagai sekumpulan susbsistem yang terdiri atas basis data dengan para pemakai yang
menggunakan basis data secara bersama-sama, personal-personal yang merancang
dan mengelola basis data, teknik-teknik untuk merancang dan mengelola basis data,
serta sistem komputer untuk mendukungnya. Dari pengertian tersebut dapat
disimpulkan bahwa sistem basis data mempunyai beberapa elemen penting yaitu:
1. Basis data sebagai inti dari sistem basis data
2. Perangkat lunak (software) untuk perancangan dan pengelolaan basis data
3. Perangkat keras (hardware) sebagai pendukung operasi pengolahan data
4. Manusia (brainware) yang mempunyai peran penting dalam sistem tersebut,
yaitu: sebagai pemakai atau para spesialis informasi yang mempunyai fungsi
sebagai perancang atau pengelola
Perangkat lunak untuk pengelolaan basis data merupakan perangkat lunak yang
umumnya mempunyai dua fungsi utama, yaitu untuk mendefinisikan data dalam basis
data dan untuk mengakses / pengelolaan data dalam basis data tersebut. Perangkat
lunak yang termasuk dalam kriteria ini adalah paket-paket aplikasi basis data baik yang
bekerja di bawah sistem operasi DOS, maupun yang berbasis visual di lingkungan
sistem operasi windows. Contoh perangkat lunak ini adalah dBase III++, Foxbase,
Foxpro, Visual Dbase, Visual Foxpro, Delphi, Ms Access, MySQL dan masih banyak
lagi.
Secara lebih luas, perangkat lunak dapat dikategorikan dalam tiga bagian, yaitu:
1. Perangkat lunak sistem operasi (Operating System / OS), yaitu program yang ditulis
untuk mengendalikan dan mengkoordinasi kegiatan dari perangkat keras sistem
5
komputer. Contoh perangkat lunak sistem operasi adalah MS DOS, PC DOS,
Windows, Unix, Linux.
2. Perangkat lunak bahasa (language software), yaitu program yang digunakan untuk
menterjemahkan instruksi - instruksi yang ditulis dalam bahasa pemrograman ke
dalam bahasa mesin supaya dapat dimengerti oleh komputer. Contoh perangkat
lunak bahasa adalah ……..
3. Perangkat lunak aplikasi (application software), yaitu program yang ditulis dan
diterjemahkan oleh language software untuk menyelesaikan suatu aplikasi tertentu.
Perangkat keras pendukung operasi pengolahan data yang utama adalah sistem
komputer yang mempunyai komponen sebagai berikut:
1. Perangkat keras masukan, terdiri atas:
⇒ alat input langsung
⇒ alat input tidak langsung
Contoh perangkat keras masukan adalah: keyboard, teleprinter terminal, financial
transaction terminal, Point of Sale (POS), Visual Display Terminal (VDT), pointing
device, mouse, touch screen, ligth pen, digitizer graphics tablet, scanner,
Magnetic Ink Character Recognition (MICR) Reader untuk transaksi cek, Optical
Data Reader untuk membaca dokumen tulisan tangan, censor, voice recognizer
atau speech recognizer, dan lain - lain
2. Perangkat keras keluaran, terdiri atas:
⇒ hard copy device
⇒ softcopy device
⇒ drive device
Contoh perangkat keras keluaran hard copy device adalah: printer, plotter,
Computer Output of Microfilm (COM)
Contoh alat keluaran softcopy device adalah: video display, flat panel display,
plasma display, Electro Luminescent (EL) display, Speaker
Contoh alat keluaran drive device adalah: disk drive, CD drive, dan lainnya
3. Perangkat keras unit pengolah/(Central Processing Unit/CPU), terdiri atas:
⇒ Aritmetic and Logic Unit/ALU
⇒ control unit
⇒ main memory (RAM & ROM)
6
4. Perangkat keras simpanan luar, bisa terdiri atas: Direct Acces Storage
Device/DASD/piranti akses langsung, Sequential Acces Storage Device
(SASD)/piranti akses serial, Magnetic disk, Optical disk, dan lain - lain
Gambar 2.1 menunjukkan komponen perangkat keras teknologi komputer dalam sistem
basis data.
Unit Penyimpan Data
Unit Masukan
Unit Penyimpan Sekunder
Unit Pengolah - Main Memory - ALU - Control Unit
Unit Keluaran
Gambar 2.1: Komponen perangkat keras sistem komputer
Manusia (brainware) mempunyai peran penting dalam sistem basis data, yaitu:
sebagai pemakai atau para spesialis informasi yang mempunyai fungsi sebagai
perancang atau pengelola. Manusia yang terlibat dalam suatu basis data meliputi
operator, programmer, system analyst, manajer sistem informasi, manajer pada
tingkat operasional, manajer pada tingkat manajerial, manajer pada tingkat strategis,
teknisi, serta individu lain yang terlibat di dalamnya.
22..33.. HHiirraarrkkhhii DDaattaa
Berdasarkan tingkat kompleksitas nilai data, tingkatan data dapat disusun dalam
sebuah hirarkhi, mulai dari yang aling sederhana hingga paling komplek. Susunan /
hirarkhi data hingga tersusun suatu sistem basis data dapat ditunjukkan sebagaimana
Gambar 2.2.
7
Sistem Basis Data
Basis Data
File
Record
Data item
Byte
Bit
Agregat Data
Gambar 2.2: Hirarki data hingga tersusun suatu basis data
1. Basis data, merupakan sekumpulan dari bermacam-macam tipe record yang
memiliki hubungan antar record dan rinci data terhadap obyek tertentu
2. Berkas / file, merupakan sekumpulan record sejenis secara relasi yang tersimpan
dalam media penyimpan sekunder.
3. Record, merupakan sekumpulan field / atribut / data item yang saling berhubungan
terhadap obyek tertentu.
⇒ Fixed length record, semua field dalam record memiliki ukuran yang tetap
(Contoh implementasi: linked list dengan array)
⇒ Variable length record, field-field dalam record dapat memiliki ukuran
berbeda (metode penandaan yang digunakan adalah: end of record marker,
indikator panjang, dan tabel posisi record)
4. Field / atribut / data item, merupakan unit terkecil yang disebut data, yaitu
sekumpulan byte yang mempunyai makna
⇒ Fixed length field, memiliki ukuran yang tetap (harus disediakan ukuran
terbesar yang mungkin diperlukan, tetapi mudah dalam pemrograman)
8
⇒ Variable length field, field-field dalam record dapat memiliki ukuran berbeda
(hemat, pemerograman menjadi rumit)
5. Byte, adalah bagian terkecil yang dialamatkan dalam memori. Byte merupakan
sekumpulan bit yang secara konvensional terdiri atas kombinasi delapan bit yang
menyatakan sebuah karakter dalam memori (1 byte = 1 karakter).
6. Bit, adalah sistem biner yang terdiri atas dua macam nilai, yaitu 0 dan 1. Sistem
biner merupakan dasar yang dapat digunakan untuk komunikasi antara manusia dan
mesin (komputer) yang merupakan serangkaian komponen elektronik dan hanya
dapat membedakan dua macam keadaan, yaitu ada tegangan dan tidak ada
tegangan yang masuk ke rangkaian tersebut.
1
BBAABB IIIIII.. TTUUJJUUAANN DDAANN KKEEUUNNTTUUNNGGAANN BBAASSIISS DDAATTAA
Sebagaimana usaha-usaha pada bidang yang lainnya, perancangan dan
penyusunan basis data juga mempunyai tujuan. Dalam beberapa literatur, tujuan
basis data telah dirincikan dengan cara yang berbeda-beda, namun demikian
pada prinsipnya hampir sama. Perbedaan tersebut terlihat pada kedalaman
rincian. Dengan demikian, rincian tujuan basis data bisa jadi akan berlainan
dalam literatur yang satu dengan lainnya.
James Martin (1975) membedakan tujuan basis data menjadi dua kelompok,
yaitu tujuan primer dan tujuan sekunder. Tujuan primer dimaksudkan sebagai
tujuan utama yang ingin dicapai dalam usaha perancangan dan pengembangan
basis data. Sedangkan tujuan sekunder merupakan tujuan tambahan yang
dimaksudkan untuk mencapai tujuan primer. Pembahasan pada bagian berikut
ini akan meninjau tentang rincian pada tujuan primer dan tujuan sekunder
tersebut.
33..11.. TTuujjuuaann PPrriimmeerr BBaassiiss DDaattaa
Tujuan primer atau tujuan utama basis data dapat dirincikan menjadi 14 item,
yaitu sebagai berikut :
1. Data-data dalam basis data dapat digunakan oleh banyak pemakai
Tujuan ini diartikan bahwa data-data yang disimpan dalam basis data harus
mempunyai kemampuan yang cukup luas dalam perwujudan kerelasian di
antara item-item data dari banyak file data, sehingga pemakai yang berbeda-
beda atau program-program aplikasi yang berbeda dapat menggunakan
basis data yang sama dengan cara yang berbeda-beda.
Pemakaian basis data sering kali tidak terbatas pada seorang pemakai saja,
atau di suatu lokasi saja, atau oleh sebuah sistem / aplikasi saja. Misalnya,
data pegawai dalam kelompok data kepegawaian misalnya, dapat digunakan
oleh banyak pemakai, dari sejumlah departemen dalam perusahaan atau
2
oleh banyak subsistem (misal subsistem penggajian, subsistem akuntansi,
subsistem inventori, dan sebagainya).
2. Menjaga investasi intelektual
Tujuan ini diartikan bahwa program-program aplikasi dan struktur data logik
yang telah ada pada saat ini tidak perlu dibuat / dikerjakan kembali ketika
terjadi perubahan-perubahan pada basis data. Berbagai kebutuhan baru
dapat dipenuhi dari data yang telah tersedia saat ini. Kalaupun diperlukan
maka data-data baru dapat diintegrasikan dengan mudah dengan data yang
tersedia, sehingga investasi intelektual yang dicurahkan sebelumnya akan
tetap terjaga.
3. Penekanan biaya
Penekanan biaya yang dimaksud di sini adalah berkaitan dengan tiga hal,
yaitu biaya penyimpanan, biaya penggunaan data, dan tingginya biaya ketika
membuat perubahan-perubahan basis data.
Penekanan biaya penyimpanan dimungkinkan karena kerangkapan data
dalam basis data dapat dihindarkan, selain itu perkembangan teknologi
komputer dan informasi telah mendukung bagi penerapan organisasi dan
penyimpanan data secara praktis dan efisien. Selain itu, saat ini telah
tersedia berbagai macam media penyimpanan data yang mempunyai
kapasitas semakin besar dengan harga yang semakin murah.
4. Menghilangkan proliferasi
Konsep basis data adalah menyediakan basis data untuk memenuhi semua
kebutuhan para pemakai pada semua level manajemen dan pada semua
fungsi organisatoris. Konsep ini memungkinkan pengembangan dapat terjadi
pada struktur, volume basis data, dan subsistem pengolahan data dengan
tetap mempertahankan integrasi antar subsistem. Pengembangan subsistem
baru dilakukan dengan tetap mengacu pada basis data yang sama, sehingga
akan menghindarkan terjadinya pengembangan sistem ganda.
5. Unjuk kerja (performance)
Kebutuhan-kebutuhan informasi akan terpenuhi dengan cepat, tepat, mudah,
dan akurat bersumber pada data-data dalam basis data. Hal ini akan
meningkatkan kinerja setiap personal yang terlibat di dalamnya, karena
sebagian besar waktunya dapat dimanfaatkan secar efektif untuk memikirkan
hal-hal yang bersifat manajerial, bukan lagi pada bagaimana memperoleh
3
data dan menampilkan informasi yang dibutuhkan. Dampak yang terjadi
adalah peningkatan unjuk kerja sistem secara keseluruhan.
6. Kejelasan (clarity)
Kejelasan basis data khususnya bagi para pemakai sangat penting. Setiap
pemakai harus dapat mengetahui dengan jelas tentang data apa saja yang
tersedia dan dapat diakses olehnya. Hal ini dapat dipenuhi karena sistem
pengelolaan basis data (Data Base Management Systems / DBMS) (juga
sistem operasi dan program aplikasi) memungkinkan untuk mengatur
batasan kewenangan akses basis data bagi setiap pemakai di dalam sistem.
7. Kemudahan pemakaian
Tujuan ini dimaksudkan bahwa para pemakai dapat mengakses data-data
dalam basis data dengan cara-cara yang mudah menggunakan program
aplikasi maupun sistem pengelolaan basis data (Data Base Management
Systems / DBMS). Pemakai tidak perlu memeikirkan tentang kerumitan yang
terjadi dalam teknis penyimpanan data dalam media penyimpanan data yag
digunakan.
8. Fleksibilitas penggunaan (flexibility)
Fleksibilitas cara mengakses data dari dalam basis data diperlukan dalam
rangka meningkatkan efisiensi dan efektifitas unjuk kerja basis data. Data-
data dalam basis data dapat diakses dengan cara menggunakan program
aplikasi atau menggunakan cara-cara interaktif menggunakan fasilitas-fasiltas
yang disediakan oleh sistem pengelolaan basis data (Data Base
Management Systems / DBMS), menggunakan bahasa query dan report
generator.
9. Kebutuhan data yang tidak terantisipasi dapat dipenuhi dengan cepat
Selain untuk memenuhi tujuan fleksibilitas penggunaan, bahasa query dapat
digunakan untuk mengatasi permasalahan kebutuhan informasi yang
mendadak yang harus dipenuhi secara cepat, tetapi belum tersedia program
aplikasinya. Bahasa query mampu mengambil data secara langsung dengan
hahasa yang familiar dan mudah digunakan
10. Perubahan yang mudah
Tujuan ini dimaksudkan bahwa basis data dapat berubah tanpa
mempengaruhi cara-cara untuk menggunakan data. Perubahan basis data
dapat terjadi karena perubahan aturan dalam sistem, perubahan realita
4
lapangan yang mempengaruhi basis data, perubahan di luar kebiasaan, atau
mungkin perubahan-perubahan lain yang tidak dapat diantisipasi. Sebagai
contoh, jumlah dan nama propinsi di negara Indonesia, pada mulanya
sebanyak 27, tetapi di luar dugaan ternyata jumlah propinsi tersebut telah
bertambah menjadi 32. Kejadian semacam ini, sebenarnya tidak akan
menimbulkan masalah seandainya basis data dikembangkan dengan benar
sesuai dengan batasan definisi dalam basis data.
11. Akurasi (accuracy) dan konsistensi (consistency)
Akurasi data di dalam basis data merupakan aspek penting yang berkaitan
dengan penerapan pengendalian dalam sistem secara keseluruhan.
Pengendalian terhadap akurasi data dalam basis data dapat dilakukan sejak
proses penangkapan data hingga menampilkan informasi dan distribusi.
Sedangkan konsistensi data dalam basis data dapat umumnya dapat terjaga
apabila basis data terbebas dari kerangkapan data dan disediakan sistem
pengendalian.
Tujuan ini dimaksudkan bahwa sistem harus menyediakan sarana
pengendalian untuk menghindari terjadinya berbagai versi data akibat
kerangkapan data dan beberapa pemakai mengubah data pada saat yang
berbeda. Hal ini dimungkinkan karena basis data terbebas dari kerangkapan
data, sehingga perubahan data tidak perlu dilakukan secara berulang-ulang
pada banyak tempat.
12. Privasi (privacy)
Data-data dalam basis data merupakan sumber informasi yang bersifat
sangat penting dan rahasia. Oleh karena itu, data-data tersebut harus dijaga
dari berbagai hal yang kemungkinan dapat mengacaukan atau merusak data.
Privasi dimaksudkan sebagai pembatasan kewenangan akses data dalam
basis data untuk mencegah dan melindungi basis data dari penggunaan oleh
orang-orang yang tidak berwenang / berhak dan pengubahan yang tidak
dikehendaki.
13. Keamanan (security)
Keamanan basis data merupakan suatu mekanisme sistem untuk mencegah
dan melindungi basis data kehilangan akibat kerusakan pada fisik media
penyimpan, kebakaran, banjir, badai, huru-hara, dan lain-lain. Sistem
keamanan basis data dapat dilakukan secara fisik maupun prosedural.
5
14. Ketersediaan (availability)
Kebutuhan informasi dari para pemakai umumnya dapat terjadi secara rutin
atau secara tiba-tiba. Sistem aplikasi untuk basis data seharusnya dirancang
agar mampu mengantisipasi kebutuhan-kebutuhan tersebut semaksimal
mungkin. Namun yang lebih penting adalah kelengkapan data dalam basis
data dan kemudahan akses data dari dalam basis data. Sehingga data-data
dalam basis data akan selalu siap diakses setiap saat, dengan cara yang
berbeda-beda.
33..22.. TTuujjuuaann SSeekkuunnddeerr BBaassiiss DDaattaa
1. Kebebasan data secara fisik (physical data independency)
Teknis penyimpanan basis data dalam media penyimpan sekunder dapat
berubah akibat kemunculan teknologi baru atau karena pertimbangan
efisiensi dan efektifitas akses data. Perubahan media penyimpan data akan
mengakibatkan perubahan metode penyimpanan dan metode akses data.
Tujuan ini dimaksudkan bahwa perubahan teknis penyimpanan data tidak
perlu menuliskan program aplikasi kembali dan tidak mengakibatkan
perubahan schema basis data.
2. Kebebasan data secara logika (logical data independency)
Tujuan ini diamseudkan bahwa perubahan kebutuhan data dan informasi dari
para pemakai dapat terjadi dengan mudah tanpa harus mengubah program
aplikasi dan schema basis data.
3. Pengendalian atau minimalisasi kerangkapan (data redundancy)
Kerangkapan data merupakan pangkal dari sebagian besar permasalahan
yang muncul dalam pengolahan data. Oleh karena itu, kerangkapan data
harus dihindari dalam basis data. Namun demikian, karena alasan teknis,
seringkali kerangkapan data terpaksa masih diperlukan. Jika demikian, maka
yang dapat dilakukan adalah meminimalkan kerangkapan tersebut.
4. Kecepatan akses
Kecepatan akses merupakan faktor penting dalam basis data. Efisiensi akses
data dari media penyimpan sangat bergantung pada metode penyimpanan
dan metode akses data dalam berkas. Metode penyimpanan dan metode
6
akses bergantung pada media penyimpan yang digunakan. Kesesuaian
kebutuhan akses data dan media yang digunakan merupakan faktor penentu
kecepatan akses.
5. Kecepatan pencarian
Kecapatan akses data dari dalam basis data sangta ditentuakn oleh
kecepatan proses pencarian data. Pemilihan metode akses yang tepat akan
menjadi sangat penting untuk diperhatikan oleh para perancang basis data.
6. Standarisasi data
Jika data tersebar dalam beberapa file dalam format yang tidak standar,
maka ini akan menyulitkan dalam menulis program aplikasi untuk mengambil
dan menyimpan data. Untuk kepentingan ini, maka standarisasi data menjadi
faktor penting. Data-data dalam basis data harus dibuat dalam format yang
standar. Lebih jauh, standarisasi data juga harus dilakukan hingga penulisan
nilai-nilai rinci data yang disimpan. Setiap susbsistem pengoalahn data dalam
organisasi harus bersepakat untuk menggunakan definisi dan format data.
7. Tersedianya kamus data
Kamus data (Data Dictionary / DD) menunjukkan definisi struktur data dalam
basis data. Kamus data diperlukan sebagai sarana untuk standarisasi data,
acuan pengembangan program aplikasi, dan sekaligus sebagai dokumentasi
sistem yang diperlukan pada saat pemeliharaan basis data.
8. Antarmuka pemrogram tingkat tinggi
Antarmuka (interface) yang bersifat user friendly merupakan aspek penting
untuk mencapai tujuan ini. Dalam aplikasi, perancang harus menyediakan
suatu rancangan dialog tampilan monitor yang mudah dioperasikan dan
selalu memberikan umpan balik (feed back) bagi para pemakainya. Fungsi
bantuan (help) yang bersifat online di dalam program aplikasi juga
memberikan bantuan yang berartibagi para pemakai untuk dapat mengakses
data dalam basis data. Tujuan ini dimaksudkan bahwa basis data harus
menyediakan antarmuka yang sederhana bagi para pemrogram aplikasi.
Penekanan pada kebutuhan daya maksimal data, dan harus dibebaskan dari
layout dan pengalamatan data dalam fisik media penyimpan yang komplek.
9. Bahasa end-user
Pemanfaatan teknologi komputer untuk pengelolaan basis data telah
mengubah perilaku para pemakai yang mengarah pada peran
7
mengembangkan sebagian atau keseluruhan bagian pekerjaan
pengembangan sistem pengolahan data. Kondisi ini lebih dikenal sebagai
end user computing. Dengan demikian, basis data harus mengijinkan para
pemakai untuk menggunakan bahasa end user (query dan report generator)
sebagai sarana yang cepat dan memudahkan para pemakai dalam
mengembangkan program aplikasinya sesuai kebutuhannya sendiri.
Berdasarkan tingkat pengetahuan tentang kompuiter, para pemakai akhir
dapat dikelompokkan menjadi empat, yaitu:
a. Pemakai akhir tingkat menu (menu level end users), yaitu para
pemakai yang tidak mampu menciptakan perangkat lunak mereka
sendiri, tetapi dapat berkomunikasi dengan paket perangkat lunak jadi
(prewritten software), misal Lotus, dbase, Wordperfect, dll.
b. Pemakai akhir tingkat perintah (command level end users), yaitu para
pemakai akhir yang mampu menggunakan bahasa perintah dari paket
perangkat lunak jadi untuk operasi aritmatika dan logika pada data
yang tidak mungkin dilakukan melalui menu.
c. Pemrogram pemakai akhir (end use programmers), yaitu pemakai
akhir yang mampu mengembangkan program - program aplikasi
mereka sendiri sesuai dengan kerbutuhannya.
d. Personil pendukung keputusan (functional support personnel), yaitu
para spesialis informasi dalam arti sesungguhnya yang mempunyai
dedikasi pada area pemakai tertentu dan melapor pada manajer
fungsional mereka.
10. Pengendalian integritas (integrity)
Basis data berisi file-file yang saling berhubungan. Permasalahan utamanya
adalah bagaimana hubungan antar file itu terjadi. Meskipun secara logika kita
mengetahui bahwa file A berkaitan dengan file B, namun secara teknis maka
harus ada kunci yang menghubungkan kedua file tersebut. Dalam kaitan ini
maka diperlukan adanya suatu batasan integritas yang menjamin bahwa
hubungan di antara kedua file tersebut dapat dipastikan kebenarannya.
11. Kecepatan pemulihan kembali dari kerusakan (fast recovery from failuries)
Kerusakan media fisik penyimpan basis data merupakan suatu kondisi yang
perlu diantisipasi. Pembuatan basis data cadangan (back up) merupakan
salah satu cara efektif yang perlu dilakukan secara rutin dan tersistem. Data
8
cadangan tersebut dapat digunakan untuk pemulihan kembali (recovery)
seandainya kerusakan benar-benar terjadi.
12. Kemampuan perubahan untuk penyesuaian (tuning)
Perubahan basis data merupakan kejadian yang tidak dapat dihindari.
Permasalahannya adalah bagaimana perubahan tersebut dapat dilakukan
dengan mudah untuk menyesuaikan dengan keadaan yang baru. Rancangan
basis data yang benar memungkinkan untuk penyesuaian dengan cepat dan
mudah.
13. Perancangan dan pengawasan alat-alat
Alat yang dimaksud di sini adalah alat-alat bantu yang digunakan pada saat
perancangan dan implementasi basis data. Dokumentasi keseluruhan tahap
pengembangan dan operasional sistem merupakan sarana efektif yang
diperlukan dalam rangka mencapai tujuan ini. Tujuan ini mengandung arti
bahwa basis data harus mengijinkan perancang dan pengelola basis data
(Data Base Adinistrator / DBA) untuk merencanakan dan mengoptimalkan
unjuk kerja berbagai alat bantu yang digunakan.
14. Pengorganisasian kembali atau migrasi data dapat dilakukan secara otomatis
Dengan alasan-alasan tertentu, data-data dalam basis data dapat
dipindahkan dari suatu media ke media lain. Proses migrasi data ini
semestinya dapat dilakukan secara otomatis menggunakan layanan yang
disediakan oleh DBMS dan sistem operasi komputer. Migrasi data harus
dijamin tidak mengakibatkan kehilangan atau kerusakan data selama proses
tersebut dilaksanakan.
33..33.. KKeeuunnttuunnggaann BBaassiiss DDaattaa
Penyusunan satu basis data digunakan untuk mengatasi permasalahan-
permasalahan pada saat pengolahan data. Basis data yang dikembangkan
dengan benar, sesuai dengan baasan / kaidah basis data akan memberikan
beberapa keuntungan, yaitu:
1. Kerangkapan data dapat diminimalkan
Jika file-file basis data dalam program aplikasi diciptakan oleh perancang
yang berbeda pada waktu yang berselang cukup lama, maka beberapa
9
bagian data akan mengalami kerangkapan. Pengembangan basis data yang
sesuai dengan definisi basis data di muka akan menghindari terjadinya
kerangkapan data.
2. Inkonsistensi data dapat dihindari
Basis data yang terbebas dari kerangkapan data akan terhindar dari
munculnya data-data yang tidak konsistens. 3. Data dalam basis data dapat digunakan secara bersama (multiuser)
Dalam rangka meningkatkan unjuk kerja sistem dan untuk memperoleh
respons waktu yang cepat, beberapa sistem mengijinkan banyak pemakai
untuk dapat meng-update data secara simultan. Salah satu alasan mengapa
basis data dibangun karena nantinya data tersebut akan digunakan oleh
banyak pemakai, baik secara bersamaan maupun dalam waktu yang
berbeda, atau akan diakses oleh program-program aplikasi yang berbeda.
Semua ini memungkinkan terjadi jika data-data yang diolah tidak tergantung
dan menyatu dengan program tetapi terlepas dalam sebuah kelompok data.
4. Standarisasi data dapat dilakukan
Definisi file basis data di dalam kamus data memungkinkan untuk
menerapkan standarisasi data dalam basis data.
5. Pembatasan untuk keamanan data dapat diterapkan
Data-data dalam basis data dapat diatur sehingga hanya pemakai tertentu
yang menpunyai wewenang saja yang dapat untuk mengaksesnya.
6. Integritas data dapat terpelihara
Integritas berhubungan dengan unjuk kerja sistem agar dapat melakukan
kendali/kontrol pada semua bagian sistem sehingga sistem selalu beroperasi
dalam pengendalian penuh. Masalah integritas berhubungan dengan
pengendalian sistem yang dirancang dengan seksama agar sistem tersebut
dapat beroperasi sesuai batasan dan aturan yang ditetapkan.
7. Perbedaan kebutuhan data dapat diseimbangkan
Setiap pemakai dalam sistem akan memiliki kebutuhan yang berbeda-beda.
Pengembangan basis data yang benar akan mampu menyeimbangkan
perbedaan-perbedaan kebutuhan tersebut, karena secara konseptual akan
menggunakan basis data yang sama.
1
BBAABB IIVV.. KKEEKKAANNGGAANN DDAALLAAMM BBAASSIISS DDAATTAA
Dalam perancangan dan penyusunan basis data dikenal adanya beberapa kekangan
atau aturan yang harus ditaati / dipatuhi dalam file-file basis data. Kekangan tersebut
diperlukan untuk memenuhi batasan / kriteria sebagaimana definisi yang diberikan
terhadap istilah basis data. Kekangan tersebut berhubungan dengan aspek-aspek
penting dalam basis data, yaitu sebagai berikut:
1. Kerangkapan data
2. Inkonsistensi data
3. Data terisolasi
4. Keamanan data
5. Integritas data
44..11.. KKeerraannggkkaappaann DDaattaa ((DDaattaa RReedduunnddaannccyy))
Kerangkapan data (data redundancy), adalah munculnya data-data yang secara
berlimpah/berulang kali pada file basis data yang semestinya tidak diperlukan.
Umumnya, kerangkapan data dalam basis data terjadi akibat penyusunan basis data
untuk aplikasi - aplikasi tidak memperhatikan kriteria sebuah basis data. Kerangkapan
data juga dapa terjadi akibat penyusunan basis data dilakukan oleh perancang yang
berbeda dalam selang waktu yang cukup lama.
Kerangkapan data dalam basis data perlu dihindari (paling tidak harus diminimalkan)
karena beberapa alasan, yaitu:
1. Pemborosan media penyimpanan basis data
2. Biaya penyimpanan yang semakin besar
3. Kesulitan / inefisiensi dalam pengolahan data
4. Pemborosan waktu dalam pengolahan data
5. Semakin besar kemungkinan muncul data tidak konsisten
Kejadian kerangkapan data dapat terjadi pada dua kemungkinan, yaitu:
2
1. Kerangkapan data dalam satu file
2. Kerangkapan data dalam beberapa file
44..11..11.. KKeerraannggkkaappaann DDaattaa DDaallaamm SSaattuu FFiillee
Kerangkapan data dalam 1 file terjadi jika muncul kerangkapan nilai-nilai rinci data data
dalam 1 file tersebut. Suatu contoh tentang kerangkapan data dalam satu file
ditunjukkan oleh file Karyawan dalam Tabel 4.1. Dalam contoh tersebut, kerangkapan
data terjadi pada kolom Gaji_Pokok, yaitu untuk setiap karyawan yang mempunyai
Gol_Gaji tertentu yang sama, maka harus dicatat kembali tentang Gaji_Pokok dengan
nilai yang sama, sehingga data Gaji_Pokok akan disimpan secara berulang.
Sebagai contoh, Rini dengan NIK K003, mempunyai Gol_Gaji yang sama dengan Rita
dengan NIK K001. Sekalipun diketahui dan dapat dipastikan, bahwa Gaji_Pokok untuk
semua karyawan yang memiliki Gol_Gaji IIIA adalah sama, yaitu 500.000, tetapi dalam
file Karyawan tersebut, keterangan besarnya Gaji_Pokok tersebut harus selalu disimpan
kembali setiap dijumpai Gol_Gaji karyawan IIIA. Jika cacah karyawan yang memiliki
Gol_Gaji yang sama semakin banyak, maka semakin banyak pula terjadi terjadi
kerangkapan data dalam file Karyawan tersebut.
Tabel 4.1: File Karyawan
NIK Nama_Karyawan Alamat Gol_Gaji Gaji_Pokok K001 Rita Yogyakarta IIIA 500.000 K002 Rina Semarang IVA 750.000 K003 Rini Jakarta IIIA 500.000 K004 Rani Yogyakarta IIIB 550.000 K005 Rika Surabaya IVA 750.000
Kerangkapan data sebagaimana file Karyawan harus dihindari dalam perancangan
basis data. Untuk menghindari kerangkapan data dalam file Karyawan tersebut dapat
dilakukan dengan cara mengubah struktur file , yaitu memecah file Karyawan menjadi 2
buah file baru, yaitu Karyawan_1 dan Golongan. File Karyawan_1 digunakan untuk
mencatat nilai-nilai data yang berhubungan dengan identitas setiap karyawan,
3
sedangkan file Golongan digunakan untuk mencatat besarnya Gaji_Pokok untuk setiap
Gol_Gaji yang mungkin dimiliki oleh karyawan.
Pemecahan file ini harus tetap memenuhi definisi basis data, yaitu data-data harus tetap
berhubungan. Dengan demikian, agar kedua file baru yang terbentuk tersebut dapat
tetap saling berhubungan, maka diperlukan kolom yang dapat menghubungkan antara
keduanya (kolom ini disebut sebagai kunci penghubung), yaitu Gol_Gaji dalam file
Karyawan. Selanjutnya, jika diperlukan keterangan mengenai besarnya Gaji_Pokok
seorang karyawan, maka dapat diketahui dengan cara mencari nilai dalam kolom
Gaji_Pokok dalam file Golongan sesuai dengan Gol_Gaji yang ada dalam file
Karyawan_1. Hasil pemecahan tersebut ditunjukkan oleh Tabel 4.2 dan Tabel 4.3.
Tabel 4.2: File Karyawan_1
NIK Nama_Karyawan Alamat Gol_Gaji K001 Rita Yogyakarta IIIA K002 Rina Semarang IVA K003 Rini Jakarta IIIA K004 Rani Yogyakarta IIIB K005 Rika Surabaya IVA
Tabel 4.3: File Golongan
Gol_Gaji Gaji_Pokok IA 100.000 IB 150.000 IC 200.000 ID 250.000 IIA 300.000 IIB 350.000 IIC 400.000 IID 450.000 IIIA 500.000 IIIB 550.000 IIIC 600.000 IIID 650.000 IVA 750.000 IVB 800.000 IVC 850.000 IVD 900.000
Contoh lain, tentang kerangkapan data dalam satu file adalah terjadi dalam file
Mahasiswa dalam Tabel 4.4. Kerangkapan data dalam file Mahasiswa terjadi pada
4
kolom Nama_Mahasiswa dan Nama_Mata_Kuliah. Nama mahasiswa dalam kolom
Nama_Mahasiswa mengalami kerangkapan, karena setiap kali mahasiswa dengan NIM
tertentu mengikuti mata kuliah yang berbeda, maka namanya harus disimpan kembali
dalam kolom Nama_Mahasiswa. Misalnya, Rita dengan NIM 02050001, namanya harus
dicatat sebanyak 3 kali, karena ia mengikuti tiga mata kuliah, yaitu MK001, MK002, dan
MK003. Nama Rina dengan NIM 02050002 harus dicatat sebanyak 4 kali, karena ia
mengikuti 4 mata kuliah yang berbeda. Sedangkan Rini, Rani, dan Rika, masing-masing
namanya harus disimpan sebanyak 2 kali, karena mengikuti 2 mata kuliah.
Kerangkapan yang lain, adalah terjadi pada kolom Nama_Mata_Kuliah. Setiap kali ada
mahasiswa yang mengikuti mata kuliah dengan kode tertentu, maka harus disimpan
kembali data nama mata kuliah. Sebagai contoh, Rita, Rina, Rini, Rani, dan Rika,
masing-masing mengikuti mata kuliah dengan kode MK001, maka nama mata kuliah
dengan kode tersebut, yaitu Pemrograman 1 harus disimpan sebanyak 5 kali. Nama
mata kuliah MK002 juga harus disimpan sebanyak 5 kali, karena diikuti oleh 5
mahasiswa tersebut. Nama mata kuliah Pemrograman III disimpan sebanyak 2 kali,
karena ada 2 mahasiswa yang mengikuti mata kuliah tersebut. Nama mata kuliah
Pemrograman IV disimpan sebanyak 1 kali, karena kebetulan hanya 1 mahasiswa yang
mengikuti mata kuliah tersebut.
Tabel 4.4: File Mahasiswa
NIM Nama_Mahasiswa Kode_Mata_Kuliah Nama_Mata_Kuliah 02050001 Rita MK001 Pemrograman I 02050001 Rita MK002 Pemrograman II 02050001 Rita MK003 Pemrograman III 02050002 Rina MK001 Pemrograman I 02050002 Rina MK002 Pemrograman II 02050002 Rina MK003 Pemrograman III 02050002 Rina MK004 Pemrograman IV 02050003 Rini MK001 Pemrograman I 02050003 Rini MK002 Pemrograman II 02050004 Rani MK001 Pemrograman I 02050004 Rani MK002 Pemrograman II 02050005 Rika MK001 Pemrograman I 02050005 Rika MK002 Pemrograman II
Sebagaimana contoh sebelumnya, kerangkapan data dalam file Mahasiswa juga dapat
diatasi dengan cara memecah file tersebut. File baru yang terbentuk adalah
5
Mahasiswa_1, Mata_Kuliah, dan KRS. File Mahasiswa_1 digunakan untuk mencatat
identitas setiap mahasiswa, file Mata_Kuliah digunakan untuk mencatat identitas setiap
mata kuliah, dan file KRS digunakan untuk mencatat data mahasiswa dan mata kuliah
yang diikutinya. Agar tidak terjadi kerangkapan data kembali dalam file KRS, maka file
KRS hanya mencatat NIM mahasiswa yang mengikuit mata kuliah dan dan
Kode_Mata_Kuliah yang diikutinya.
Untuk tetap menjaga hubungan antar data dalam ketiga file baru yang terbentuk
tersebut, maka dapat menggunakan penghubung, yaitu kolom NIM dan kolom
Kode_Mata_Kuliah dalam file KRS. Sebagai contoh, untuk mengetahui nama
mahasiswa dengan NIM 01050001 dapat dicari dalam file Mahasiswa_1, untuk
mengetahui nama mata kuliah dengan kode MK 001 dapat dicari dala file Mata_Kuliah.
Sedangkan untuk mengetahui nama mahasiswa dengan NIM 01050002 dan nama mata
kuliah dengan kode mata kuliah MK002 dalam file KRS, maka dapat diakses dengan
cara melacaknya ke dalam file Mahasiswa dan file Mata_Kuliah. File-file baru yang
terbentuk tersebut ditunjukkan oleh Tabel 4.5, Tabel 4.6, dan Tabel 4.7.
Tabel 4.5: File Mahasiswa_1
NIM Nama_Mahasiswa 02050001 Rita 02050002 Rina 02050003 Rini 02050004 Rani 02050005 Rika
Tabel 4.6: File Mata_Kuliah
Kode_Mata_Kuliah Nama_Mata_Kuliah MK001 Pemrograman I MK002 Pemrograman II MK003 Pemrograman III MK004 Pemrograman IV
6
Tabel 4.7: File KRS
NIM Kode_Mata_Kuliah 02050001 MK001 02050001 MK002 02050001 MK003 02050002 MK001 02050002 MK002 02050002 MK003 02050002 MK004 02050003 MK001 02050003 MK002 02050004 MK001 02050004 MK002 02050005 MK001 02050005 MK002
Berdasarkan dua contoh kerangkapan data dalam 1 file tersebut, maka dapat
disimpulkan, bahwa:
1. Kerangkapan data dalam 1 file dapat diatasi dengan cara memecah file tersebut,
menjadi file-file baru yang mempunyai struktur lebih sederhana
2. Banyaknya file baru yang terbentuk adalah bergantung pada banyaknya
kerangkapan data yang terjadi. Dalam file Karyawan terjadi 1 kerangkapan data,
yaitu pada kolom Gaji_Pokok, sehingga file Karyawan dipecah menjadi 2 file
baru, yaitu Karyawan_1 dan Golongan. Sedangkan dalam file Mahasiswa, terjadi
kerangkapan sebanyak 2 kali, yaitu pada kolom Nama_Mahasiswa, kolom
Nama_Mata_Kuliah, sehingga file Mahasiswa dipecah menjadi 3 file baru, yaitu
Mahasiswa_1, Mata_Kuliah, dan KRS.
44..11..22.. KKeerraannggkkaappaann DDaattaa DDaallaamm BBeebbeerraappaa FFiillee
Kerangkapan data dalam beberapa file terjadi jika muncul nama-nama kolom yang sama
dalam beberapa file. Hal ini dikecualikan untuk kolom yang digunakan sebagai kunci
penghubung antar data dalam file untuk memenuhi definisi basis data. Sebagai contoh,
file Mahasiswa yang ditunjukkan oleh Tabel 4.8 dan file Minat_Mahasiswa yang
ditunjukkan oleh Tabel 4.9. menunjukkan terjadinya kerangkapan data dalam 2 file.
Dalam contoh tersebut, kerangkapan data terjadi pada kolom Nama_Mahasiswa (dalam
7
file Minat_Mahasiswa), karena sebenarnya data Nama_Mahasiswa telah disimpan
dalam file Mahasiswa.
Tabel 4.8: File Mahasiswa
NIM Nama_Mahasiswa 02050001 Rita 02050002 Rina 02050003 Rini 02050004 Rani 02050005 Rika
Tabel 4.9: File Minat_Mahasiswa
NIM Nama_Mahasiswa Minat 02050001 Rita Pemrograman 02050002 Rina Jaringan 02050003 Rini Web 02050004 Rani Basis Data 02050005 Rika Multimedia
Kerangkapan data dalam beberapa file dapat diatasi dengan cara menghapus kolom
yang rangkap. Dalam contoh di sini, maka kolom yang rangkap adalah
Nama_Mahasiswa di dalam file Minat_Mahasiswa. Dengan demikian, maka kolom
tersebut harus dihapus / dihilangkan dari file Minat_Mahasiswa, sehingga hasil
penghapusan tersebut akan menjadi file baru sebagaimana ditunjukkan oleh Tabel 4.10,
yaitu diberi nama file Minat_Mahasiswa_1.
Tabel 4.10: File Minat_Mahasiswa_1
NIM Minat 02050001 Pemrograman 02050002 Jaringan 02050003 Web 02050004 Basis Data 02050005 Multimedia
Berdasarkan contoh tersebut, maka kerangkapan data dalam beberapa file dapat diatasi
dengan cara menghapus kolom yang rangkap. Penghapusan tersebut dilakukan sesuai
dengan kelompok datanya. (Catatan: kolom Nama_Mahasiswa merupakan kelompok
data Mahasiswa yang harus disimpan dalam file Mahasiswa, bukan termasuk kelompok
data Minat_Mahasiswa, sehingga tidak perlu disimpan dalam file Minat_Mahasiswa_1).
8
44..22.. DDaattaa TTiiddaakk KKoonnssiisstteenn ((DDaattaa IInnccoonnssiisstteennccyy))
Data tidak konsisten (data inconsistency) adalah munculnya data yang tidak konsisten
pada medan / kolom yang sama dalam satu atau beberapa file data yang dihubungkan /
direlasikan. Data tidak konsisten dapat terjadi diakibatkan oleh:
1. Proses pemasukan data (data entry) yang tidak benar
2. Proses pembaharuan data (update) yang tidak benar
3. Pengendalian sistem yang tidak baik / terkontrol
Sekalipun demikian, penyebab utama munculnya data tidak konsisten adalah akibat
munculnya kerangkapan data dalam file. Oleh karena itu, contoh data tidak konsisten
dapat diberikan dalam file yang mengalami kerangkapan data. Basis data harus
terbebas dari data tidak konsisten karena akan mengakibatkan kesalahan fatal pada
informasi yang dihasilkan dari pengolahan data dalam basis data karena tidak sesuai
dengan fakta yang ada. Sebagaimana dalam kerangkapan data, kejadian data tidak
konsisten juga dapat terjadi pada dua kemungkinan, yaitu:
1. Kerangkapan data dalam satu file
2. Kerangkapan data dalam beberapa file
44..22..11.. DDaattaa TTiiddaakk KKoonnssiisstteenn DDaallaamm SSaattuu FFiillee
Data tidak konsisten dalam 1 file, terjadi jika kemunculan data tidak konsisten terjadi
pada 1 file (yang mengalami kerangkapan data). Dengan sedikit perubahan nilai rinci
data, maka file Karyawan dalam Tabel 4.1 akan diubah menjadi seperti ditunjukkan
pada Tabel 4.11. File Karyawan dalam Tabel 4.11 mengandung data tidak konsisten
pada nilai Gaji_Pokok. Gaji pokok karyawan bernama Rina dengan NIK K002
mempunyai gaji pokok 700.000, sedangkan karyawan bernama Rika dengan NIK K005
mempunyai gaji pokok 750.000, padahal keduanya mempunyai golongan gaji yang
sama yaitu IVA. Kejadian ini menunjukkan adanya data tidak konsisten dalam file
Karyawan. Inkonsistensi data tersebut bisa terjadi, mungkin akibat kesalahan data entry,
kesalahan proses update, atau pengendalian sistem yang tidak baik. Permasalahannya
9
adalah, sebenarnya berapa nilai yang benar untuk golongan gaji IVA tersebut. Hal ini
hanya bisa diketahui setelah dilacak dan kemudian disesuaikan dengan fakta / kondisi
yang sesungguhnya di dalam sistem (dalam hal ini yang benar adalah 750.000).
Inkonsistensi data tersebut akan mengakibatkan kesalahan informasi pada hasil
pengolahan data, misal:
1. Kesalahan pada saat mencetak struk daftar perolehan gaji karyawan
2. Kesalahan jumlah total pengeluaran uang yang dikeluarkan untuk gaji karyawan
Tabel 4.11: File Karyawan (dimodifikasi dari Tabel 4.1)
NIK Nama_Karyawan Alamat Gol_Gaji Gaji_Pokok K001 Rita Yogyakarta IIIA 500.000 K002 Rina Semarang IVA 700.000 K003 Rini Jakarta IIIA 500.000 K004 Rani Yogyakarta IIIB 550.000 K005 Rika Surabaya IVA 750.000
Inkonsistensi data dalam 1 file dapat dihindari dengan cara yang sama sebagaimana
permasalahan kerangkapan data dalam 1 file, yaitu dengan memecah file menjadi file-
file baru yang lebih sederhana dan tetap saling berhubungan. Dalam contoh ini, maka
file-file baru hasil pemecahan yang diperoleh adalah sama dengan contoh kerangkapan
dalam 1 file di atas, yaitu file Karyawan_1 dan Golongan sebagaimana ditunjukkan oleh
Tabel 4.2. dan Tabel 4.3.
Contoh inkonsistensi data dalam 1 file yang lain adalah ditunjukkan oleh Tabel 4.12
(modifikasi Tabel 4.4). Dalam Tabel 4.12, inkonsistensi terjadi pada nama mata kuliah
dengan kode mata kuliah MK001 yang diikuti oleh Rina dengan 02050002 (baris data
ke-4). Dalam baris data tersebut, nama mata kuliah yang tersimpan adalah
Pemrograman II (yang benar adalah Pemrograman I), sedangkan dalam baris-baris
data yang lain, nama mata kuliah untuk kode tersebut adalah Pemrograman I.
Selain itu, inkonsistensi data juga terjadi pada baris data ke-7, yaitu nama mahasiswa
yang tersimpan adalah Rini. Padahal untuk NIM 02050002 yang benar adalah Rina.
10
Tabel 4.12: File Mahasiswa (dimodifikasi dari Tabel 4.4)
NIM Nama_Mahasiswa Kode_Mata_Kuliah Nama_Mata_Kuliah 02050001 Rita MK001 Pemrograman I 02050001 Rita MK002 Pemrograman II 02050001 Rita MK003 Pemrograman III 02050002 Rina MK001 Pemrograman II 02050002 Rina MK002 Pemrograman II 02050002 Rina MK003 Pemrograman III 02050002 Rini MK004 Pemrograman IV 02050003 Rini MK001 Pemrograman I 02050003 Rini MK002 Pemrograman II 02050004 Rani MK001 Pemrograman I 02050004 Rani MK002 Pemrograman II 02050005 Rika MK001 Pemrograman I 02050005 Rika MK002 Pemrograman II
Sebagaimana contoh sebelumnya, inkonsistensi data nama mata kuliah dan nama
mahasiswa tersebut bisa terjadi, mungkin akibat kesalahan data entry, kesalahan proses
update, atau pengendalian sistem yang tidak baik. Permasalahannya adalah,
sebenarnya apa nilai yang benar untuk kode mata kuliah MK001 dan nama mahasiswa
untuk NIM 02050002 tersebut. Hal ini hanya bisa diketahui setelah dilacak dan
kemudian disesuaikan dengan fakta / kondisi yang sesungguhnya di dalam sistem
(dalam hal ini yang benar adalah Pemrograman I dan Rina).
Inkonsistensi data tersebut akan mengakibatkan kesalahan informasi pada hasil
pengolahan data, misal kesalahan pada saat mencetak KRS mahasiswa. Cara
mengatasi inkonsistensi data nama mahasiswa dan nama mata kuliah tersebut dapat
dilakukan dengan cara merancang file secara benar sesuai definisi basis data, yaitu
mencegah terjadinya kerangkapan data dengan cara memecah file tersebut menjadi 3
file baru, yaitu file Mahassiwa_1, Mata_Kuliah, dan KRS sebagaimana ditunjukkan oleh
Tabel 4.5, Tabel 4.6., dan Tabel 4.7.
44..22..22.. DDaattaa TTiiddaakk KKoonnssiisstteenn DDaallaamm BBeebbeerraappaa FFiillee
Data tidak konsisten dalam beberapa file juga diakibatkan oleh rancangan struktur file
yang mengalami kerangkapan data dalam beberapa file. Dengan melakukan sedikit
modifikasi file Minat_Mahasiswa dalam Tabel 4.9, file Mahasiswa dalam Tabel 4.8 dan
11
file Minat_Mahasiswa dalam Tabel 4.9. akan digunakan kembali untuk contoh di sini.
Untuk mudahnya, file Mahasiswa akan dituliskan kembali dalam Tabel 4.13. dan File
Minat_Mahasiswa dalam Tabel 4.9 dimodifikasi menjadi seperti ditunjukkan oleh Tabel
4.14.
Tabel 4.13: File Mahasiswa
NIM Nama_Mahasiswa 02050001 Rita 02050002 Rina 02050003 Rini 02050004 Rani 02050005 Rika
Tabel 4.14: File Minat_Mahasiswa
NIM Nama_Mahasiswa Minat 02050001 Rita Pemrograman 02050002 Rina Jaringan 02050003 Rina Web 02050004 Rani Basis Data 02050005 Rika Multimedia
Dalam Tabel 4.14, terlihat bahwa nama mahasiswa dengan NIM 02050003 adalah
tersimpan sebagai Rina, padahal di dalam file Mahasiswa dalam Tabel 4.13 tersimpan
sebagai Rini (fakta yang benar adalah bernama Rini). Inkonsistensi ini akan
mengakibatka kesalahan informasi hasil pengolahan data dari file Minat_Mahasiswa
dalam Tabel 4.14, misal kesalahan pada saat mencetak daftar minat mahasiswa, yaitu
Rina akan memiliki 2 minat (Jaringan dan Web), sedangkan nama Rini justru tidak
pernah tampil sama sekali.
Data tidak konsisten dalam beberapa file dapat diatasi sebagaimana mengatasi
kerangkapan data dalam beberapa file, yaitu dengan cara menghapus kolom data yang
rangkap sesuai dengan kelompok datanya. Hasil yang diperoleh adalah file
Minat_Mahasiswa_1 sebagaimana ditunjukkan oleh Tabel 4.10.
Berdasarkan contoh-contoh data tidak konsisten dalam Tabel 4.11 dan Tabel 4.12,
maka kejadian inkonsistensi data dalam file basis data umumnya akan sangat sulit
diketahui. Oleh karena itu inkonsistensi data harus diantisipasi sejak dini, dimulai sejak
12
perancangan struktur file dalam basis data, yaitu dengan cara merancang struktur file
yang terbebas dari kerangkapan data.
44..33.. DDaattaa TTeerriissoollaassii
Data terisolasi disebabkan oleh pemakaian beberapa file basis data dimana program
aplikasi tidak dapat mengakses data-data dari file tertentu, kecuali bila program aplikasi
diubah / ditambah, sehingga seolah-olah ada file yang terpisah / terisolasi terhadap file
yang lain dalam basis data. Data terisolasi harus dihindari karena akan mengakibatkan
tidak lengkapnya informasi yang dihasilkan dari pengolahan data dalam basis data.
Sedangkan kita tahu bahwa nilai informasi sangat ditentukan oleh sifat luas dan
kelengkapannya (lihat Bab I tentang nilai informasi). Dengan demikian, data terisolasi
akan mengakibatkan informasi hasil pengolahan data-data dalam basis data menjadi
tidak ada nilainya, karena tidak lengkap.
Data terisolasi dapat terjadi akibat:
1. Tidak adanya kemungkinan untuk menghubungkan antar data dalam file
2. Tidak adanya standarisasi data (berkaitan dengan domain / format data, meliputi
tipe dan ukuran data)
Untuk memberikan contoh data terisolasi, di sini akan menggunakan contoh file
Mahasiswa dalam Tabel 4.13, file Minat_Mahasiswa_1 dalam Tabel 4.10, dan sebuah
file baru bernama Pembimbing_Minat. Jika file Mahasiswa dituliskan kembali menjadi
Tabel 4.15, file Minat_Mahasiswa_1 dituliskan kembali menjadi Tabel 4.16, dan file
Pembimbing_Minat mempunyai struktur seperti ditunjukkan oleh Tabel 4.17.
Seandainya diperlukan informasi mengenai siapa pembimbing minat mahasiswa
bernama Rita dengan NIM 02050001 yeng mempunyai minat Pemrograman, maka file-
file tersebut tidak dapat memenuhi kebutuhan tersebut. Hal ini karena tidak adanya
hubungan antara file Pembimbing_Minat dengan file Mahasiswa dan file
Minat_Mahasiswa_1.
13
Tabel 4.15: File Mahasiswa
NIM Nama_Mahasiswa 02050001 Rita 02050002 Rina 02050003 Rini 02050004 Rani 02050005 Rika
Tabel 4.16: File Minat_Mahasiswa_1
NIM Minat 02050001 Pemrograman 02050002 Jaringan 02050003 Web 02050004 Basis Data 02050005 Multimedia
Tabel 4.17: File Pembimbing_Minat
Kode_Pembimbing nama_Pembimbing P001 Dani P002 Dina P003 Dino P004 Dion P005 Doni
Untuk mengatasinya, maka perlu dirancang sebuah file baru yang berfungsi untuk
menghubungkan antara data minat dengan data pembimbing. Sebagai contoh, akan
digunakan file Membimbing sebagaimana ditunjukkan oleh Tabel 4.18.
Tabel 4.18: File Membimbing
Kode_Pembimbing Minat P001 Pemrograman P002 Jaringan P003 Web P004 Basis Data P005 Multimedia
Cara pertama seperti ini baik dilakukan apabila ada kemungkinan bahwa seorang
pembimbing dapat membimbing lebih dari 1 minat, sehingga penambahan file
Membimbing akan terhindar dari kerangkapan data Nama_Pembimbing.
14
Cara lain juga dapat dilakukan untuk mengatasi hal ini, yaitu dengan memodifikasi file
Pembimbing_Minat dalam Tabel 4.17, menjadi file Pembimbing_Minat_1 sebagaimana
ditunjukkan oleh Tabel 4.19. Modifikasi yang dilakukan adalah menambahkan kolom
Minat yang berfungsi untuk menghubungkan antara data-data dalam file
Pembimbing_Minat dengan data-data dalam file Minat_Mahasiswa_1.
Tabel 4.19: File Pembimbing_Minat
Kode_Pembimbing Nama_Pembimbing Minat P001 Dani Pemrograman P002 Dina Jaringan P003 Dino Web P004 Dion Basis Data P005 Doni Multimedia
Cara kedua seperti ini baik dilakukan apabila tidak ada kemungkinan bahwa seorang
pembimbing dapat membimbing lebih dari 1 minat, sehingga penambahan kolom Minat
dalam file Pembimbing_Minat akan lebih efisien dalam hal penggunaan media
penyimpan.
Cara ketiga juga dapat dilakukan untuk mengatasi permasalahn data terisolasi. Jika
macam minat yang ada dalam mahasiswa dapat bermacam-macam, satu mahasiswa
dapat memiliki lebih dari satu minat, bisa muncul minat-minat baru, macam minat dapat
berubah-ubah, maka cara pertama dan cara kedua masih akan menimbulkan
permasalahan. Ketika ukuran nilai rinci data minat bisa sangat panjang, maka data
minat akan lebih efisien jika dikodekan. Jika cara ini dilakukan, maka dengan tetap
menggunakan file Mahasiswa dalam Tabel 4.15 yang dituliskan kembali sebagai Tabel
4.20, penyelesaian dengan cara ketiga ini akan menghasilkan tambahan file baru yaitu
Minat seperti ditunjukkan oleh Tabel 4.21, Tabel 4.22, Tabel 4.23, dan Tabel 4.24.
Tabel 4.20: File Mahasiswa
NIM Nama_Mahasiswa 02050001 Rita 02050002 Rina 02050003 Rini 02050004 Rani 02050005 Rika
15
Tabel 4.21: File Minat
Kode_Minat Minat M001 Pemrograman M002 Jaringan M003 Web M004 Basis Data M005 Multimedia
Tabel 4.22: File Minat_Mahasiswa (dimodifikasi dari Tabel 4.16)
NIM Kode_Minat 02050001 M001 02050002 M002 02050003 M003 02050004 M004 02050005 M005
Tabel 4.23: File Pembimbing_Minat
Kode_Pembimbing Nama_Pembimbing P001 Dani P002 Dina P003 Dino P004 Dion P005 Doni
Tabel 4.24: File Membimbing (dimodifikasi dari Tabel 4.18)
Kode_Pembimbing Kode_Minat P001 M001 P002 M002 P003 M003 P004 M004 P005 M005
Dalam hal data terisolasi muncul akibat domain / format data yang tidak standar, maka
permasalahan ni hanya dapat diselesaikan dengan cara merubah / menyesuaikan
format data dalam file basis data sehingga data-data di dalamnya dapat saling
dihubungkan. Sebagai contoh, jika kolom NIM dalam file Mahasiswa didefinisikan
sebagai numerik dan kolom NIM dalam file Minat_Mahasiswa didefinisikan sebagai
karakter, berarti NIM dalam dua file tersebbut mempunyain domain yang berbeda.
Perbedaan domain data ini mengakibatkan data-data dalam file Mahasiswa dan data-
data dalam file Minat_Mahasiswa tidak dapat dihubungkan. Perbedaan domain hanya
16
bisa diatasi dengan cara mengubah domain dalam definisi struktur file, sehingga data
terisolasi akan terhindari.
Berdasarkan contoh-contoh di atas, maka data terisolasi dapat diatasi dengan cara:
1. Menambahkan file baru bertipe transaksi yang berfungsi sebagai penghubung
antar data dalam file-file lain yang telah ada
2. Menambahkan kolom yang berfungsi sebagai penghubung dengan file-file lain
yang telah ada
3. Menyesuaikan domain kolom yang berfungsi untukmenghubungkan antar file
44..44.. KKeeaammaannaann DDaattaa ((DDaattaa SSeeccuurriittyy))
Keamanan data (data security) merupakan aspek kritis dalam basis data. Prinsip dasar
dari keamanan data dalam basis data adalah bahwa data-data dalam basis data
merupakan sumber informasi yang bersifat sangat penting dan rahasia. Oleh karena itu,
data-data tersebut harus dijaga dari berbagai hal yang kemungkinan dapat
mengacaukan atau merusak data
Aspek keamanan basis data meliputi:
1. Recovery, adalah suatu proses menggunakan / mengambil kembali basis data
dari media penyimpanan cadangan untuk mengembalikan data pada kondisi
yang benar karena terjadi kerusakan / kehilangan data akibat kerusakan media
penyimpan, program aplikasi, OS, basis data, hardware, dll.
2. Integrity, berkaitan dengan unjuk kerja sistem untuk dapat menjaga data-data
dalam basis data agar selalu berada dalam berada dalam kondisi yang benar
(tipe dan ukuran datanya), up to date (sesuai dengan kondisi aktual), konsisten,
dan selalu tersedia (current).
3. Concurency, berkaitan dengan mekanisme pengendalian basis data saat
digunakan oleh beberapa pemakai secara bersamaan agar terhindar dari
kesalahan-kesalahan akibat beberapa transaksi berbeda yang dilakukan secara
bersamaan.
4. Privacy, yaitu dimaksudkan sebagai pembatasan kewenangan akses data dalam
basis data untuk mencegah dan melindungi basis data dari penggunaan oleh
17
orang-orang yang tidak berwenang / berhak dan pengubahan yang tidak
dikehendaki.
5. Security, adalah suatu mekanisme sistem untuk mencegah dan melindungi basis
data kehilangan akibat kerusakan pada fisik media penyimpan, kebakaran,
banjir, badai, huru-hara, dll.
44..55.. IInntteeggrriittaass DDaattaa ((DDaattaa IInntteeggiittyy))
Integritas data (data Integity) berhubungan dengan kinerja sistem agar dapat melakukan
kendali / kontrol pada semua bagian sistem. Integritas dimaksudkan sebagai suatu
sarana untuk meyakinkan bahwa dat-data yang tersimpan dalam basis data selalu
berada dalam kondisi yang benar (tipe dan ukuran datanya), up to date (sesuai dengan
kondisi aktual), konsisten, dan selalu tersedia (current). Hal ini merupakan aspek kritis
dalam manajemen basis data.
Salah satu cara terbaik untuk menjaga integritas data adalah meyakinkan bahwa nilai-
nilai data adalah benar sejak masuk pertama kali. Hal ini dapat ditempuh dengan
beberapa metode, misalnya mengeset secara seksama prosedur penangkapan data
(data capture) yang dilakukan secara manual, atau dengan membuat modul dalam
program aplikasi untuk mengecek validitas / keabsahan nilai data pada saat dimasukkan
ke dalam mesin (data entry). Integritas data dalam basis data, berhubungan dengan dua
aspek, yaitu:
1. Integritas domain (domain integrity)
2. Key constraints, berkaitan dengan dua hal, yaitu integritas entitas (entity
integrity) pada kunci primer relasi dan integritas referensial (referential integrity)
pada kunci penghubung relasi.
BBAABB VV.. PPAANNDDAANNGGAANN TTEERRHHAADDAAPP BBAASSIISS DDAATTAA
55..11.. MMaaccaamm PPaannddaannggaann TTeerrhhaaddaapp BBaassiiss DDaattaa
Suatu basis data dapat dipandang dari dua sudut pandang, yaitu sudut pandang
pemakai dan sudut pandang perancang. Pemakai basis data dapat diartikan
sebagai orang-orang yang akan mengakses / menggunakan basis data, baik
secara bersamaan maupun secara individu dalam lingkup sistem. Sedangkan
perancang adalah mereka yang berperan sebagai perancang dan pengelola
basis data. Seorang perancang dapat memiliki dua jenis pandangan yang
berbeda, yaitu secara konseptual dan secara fisis.
Ketiga macam pandangan tersebut menunjukkan level pandangan terhadap
suatu basis data. Pandangan terhadap basis data sering pula disebut sebagai
arsitektur basis data atau abstraksi basis data. Hubungan di antara ketiga level
pandangan terhadap basis data tersebut di aats dapat digambarkan
sebagaimana ditunjukkan oleh Gambar 5.1.
User view 1 User view 2 User view n
Conceptual view
Physical view
…
Gambar 5.1 : Pandangan terhadap basis data
55..22.. LLeevveell PPaannddaannggaann TTeerrhhaaddaapp BBaassiiss DDaattaa
55..22..11.. AApppplliiccaattiioonn PPrrooggrraammmmeerr LLooggiiccaall FFiillee // UUsseerr VViieeww
Application programmer logical file atau user view sering disebut juga sebagai
level eksternal, merupakan pandangan para pemakai basis data dimana masing-
masing pemakai basis data dapat memiliki cara pandang yang berbeda
tergantung pada macam data apa saja yang tersedia atau dapat diakses oleh
pemakai.
Dalam suatu universitas misalnya, pemakai dapat terdiri atas pemakai atau
program aplikasi pada subsistem akademik, subsistem perpustakaan, subsistem
keuangan, subsistem kepegawaian, subsistem kemahasiswaan, subsistem
inventaris, dan lainnya. Pemakai pada subsitem akademik mungkin akan
memerlukan keterangan yang sangat lengkap mengenai identitas setiap
mahasiswa. Keterangan yang termuat dan perlu disimpan sebagai basis data
bagi pemakai pada subsistem akademik ini dapat terdiri atas nomor induk
mahasiswa, nama, alamat asal, alamat lokal, tempat lahir, tanggal lahir, sekolah
asal, tahun lulus di SLTA, agama, status, nama orang tua / wali, pekerjaan orang
tua / wali, dan lainnya. Selanjutnya pemakai pada subsistem akademik juga
memerlukan keterangan mengenai pengambilan mata kuliah setiap mahasiswa,
perolehan nilai mahasiwa, serta dosen pengasuh mata kuliah.
Sedangkan pemakai pada subsistem perpustakaan, mungkin memerlukan
identitas mengenai nomor induk mahasiswa, nama, alamat lokal, dan tanggal
mulai menjadi anggota, khusus untuk mahasiswa yang menjadi anggota
perpustakaan saja. Selanjutnya pemakai di perpustakaan juga memerlukan
keterangan mengenai transaksi peminjaman dan pengembalian buku di
perpustakaan.
Pemakai lain, yaitu pada subsistem keuangan, mungkin hanya memerlukan
keterangan mengenai nomor induk mahasiswa, dan nama saja. Selanjutnya data
tersebut diperlukan untuk mencatat transaksi pembayaran uang kuliah
mahasiswa.
Perbedaan kebutuhan tersebut data tersebut akan mengakibatkan perbedaan
pandangan terhadap basis data. Pemakai pada subsistem akademik akan
mempunyai pandangan bahwa basis data mahasiswa meliputi semua keterangan
yang dapat diakses olehnya. Pemakai pada subsistem perpustakaan mempunyai
pandangan yang berbeda, yaitu hanya memuat data yang dibutuhkan pada
subsistem perpustakaan. Sedangkan pemakai pada subsistem keuangan akan
mempunyai pandangan yang lain lagi, yaitu basis data hanya memuat nomor
induk dan nama mahasiswa saja.
Dengan demikian, para pemakai tidak perlu tahu bagaimana sebenarnya data-
data mahasiswa tersebut disimpan dalam basis data. Application programmer
logical file dapat ditunjukkan menggunakan schema dan subschema basis data.
Sedangkan nilai-nilai rinci data / nilai aktual data dalam setiap file dapat
ditunjukkan menggunakan instance schema.
55..22..22.. GGlloobbaall LLooggiiccaall DDaattaa ((CCoonnsseeppttuuaall VViieeww))
Global logical data atau conseptual view atau sering juga disebut sebagai level
konseptual, merupakan suatu pandangan perancang basis data yang berkaitan
dengan data-data apa saja yang perlu disimpan dalam basis data dan penjelasan
mengenai hubungan antara data yang satu dan yang lainya.
Level konseptual merupakan level yang lebih rendah daripada level eksternal.
Dalam suatu universitas misalnya, dalam level konseptual ini, perancang perlu
untuk mengetahui macam data apa saja yang diperlukan oleh setiap pemakai
atau program aplikasi pada seluruh sub sistem yang digunakan dalam
universtias. Kaitannya dengan data mahasiswa, maka perancang perlu
menginventarisasi kebutuhan data mahasiswa seluruh pemakai. Berdasarkan
hasil inventarisasi kebutuhan data tersebut, selanjutnya perancang harus
merancang basis data yang mampu memenuhi seluruh kebutuhan pemakai yang
berbeda-beda tersebut dalam bentuk yang optimal. Basis data mahasiswa yang
dirancang harus memenuhi kriteria pengolahan data secara basis data (data
base processing), sebagaimana arti dan batasan yang tercantum dalam definisi
basis data. Global logical data dapat ditunjukkan menggunakan definisi struktur
basis data menggunakan bahasa deskripsi data (Data Definition Language /
DDL).
Contoh kebutuhan data mahasiswa bagi pemakai pada subsistem akademik,
subsistem perpustakaan, dan subsistem keuangan di atas, maka seorang
perancang dapat merancang struktur data yang diperlukan yang nantinya akan
disimpan sebagai basis data serta hubungan antar data tersebut. Secara logika,
maka kebutuhan data para pemakai tersebut akan dapat dipenuhi dari struktur
data yang meliputi:
1. Data Mahasiswa, memuat nomor induk mahasiswa, nama, alamat asal, kode
pos asal, alamat lokal, tempat lahir, tanggal lahir, sekolah asal, tahun lulus di
SLTA, agama, status, nama orang tua / wali, pekerjaan orang tua / wali
2. Data Mata Kuliah, memuat kode mata kuliah, nama mata kuliah, semester,
sks
3. Data Dosen, memuat NIK, nama dosen, alamat, pendidikan, golongan, status
4. Data transaksi pengambilan Mata Kuliah, memuat nomor induk mahasiswa,
kode mata kuliah, semester pengambilan
5. Data transaksi perolehan Nilai Mata Kuliah, memuat nomor induk mahasiswa,
kode mata kuliah, semester pengambilan, nilai yang diperoleh
6. Data Anggota Perpustakaan, memuat nomor mahasiswa, nomor anggota
perpustakaan, tanggal mulai menjadi anggota
7. Data Buku, memuat kode buku, judul, pengarang, penerbit, tahun terbit
8. Data transaksi peminjaman buku, memuat nomor peminjaman, nomor
anggota perpustakaan, kode buku, tanggal peminjaman, tanggal seharusnya
dikembalikan
9. Data transaksi pengembalian buku, memuat nomor peminjaman, tanggal
pengembalian buku
10. Data uang kuliah, memuat jenis uang kuliah, besar uang kuliah
11. Data transaksi pembayaran mahasiswa, memuat nomor transaksi, nomor
mahasiswa, tanggal pembayaran, jenis uang kuliah, jumlah uang yang
dibayarkan
Setiap struktur data tersebut, selanjutnya dapat digunakan untuk merancang
struktur file di dalam basis data, yaitu terdiri atas 11 file yaitu:
File Mahasiswa: | NIM | Nama | Alm_asal | Kode_pos | alm_lokal | Tpt_lahir | Tgl_lahir | Sekolah_asal | Th_lulus | Agama | Status | Nama_or tu | Pek_ortu |
File Mata Kuliah: | Kode_mk | Nama_mk | Smt | Sks |
File Dosen: | NIK | Nama_dosen | Alm | Pend | Gol | Status
File KRS: | NIM | Kode_mk | Th_smt |
File KHS: | NIM | Kode_mk | Th_smt | Nilai |
File Anggota: | NIM | No_anggota | Tgl_ anggota |
File Buku: | Kode_buku | Judul | Pengarang | Penerbit | Th_terbit |
File Pinjam: | No_pinjam | No_anggota | Kode_buku | Tgl_pinjam | Tgl_kbl |
File Kembali: | No_pinjam | Tgl_buku_kbl |
File Uang_Kuliah: | Jenis_uang_kuliah | Besar_uang_kuliah |
File Pembayaran: | NIM | Tgl_bayar | Jenis_uang _kuliah | Jml_bayar |
Setiap struktur data tersebut, selanjutnya perlu diisi dengan data yang
sesungguhnya sesuai dengan kondisi real di lapangan dan kemudian disimpan
dalam fisik media penyimpan basis data yang digunakan. Contoh ini
menunjukkan, bahwa pandangan terhadap basis data pada level eksternal
sangat jauh berbeda dengan pandangan terhadap basis data pada level
konseptual.
55..22..33.. PPhhyyssiiccaall VViieeww
Physical view atau sering pula disebut sebagai level internal, merupakan bentuk
implementasi conceptual view, yaitu suatu pandangan perancang yang berkaitan
dengan permasalahan teknik penyimpanan data-data dalam basis data ke dalam
fisik media penyimpanan data yang digunakan. Pandangan ini bersifat sangat
teknis dan lebih berorientasi pada mesin (machine oriented), yaitu berkaitan
dengan organisasi berkas basis data (meliputi metoda penyimpanan dan metoda
akses data) dan media penyimpan sekunder (storage device)
Data-data dalam struktur data untuk sub sistem akademik di atas, selanjutnya
akan diimplementasikan ke dalam fisik media penyimpan yang digunakan.
Terdapat banyak pilihan media penyimpan yang dapat digunakan sebagai media
penyimpan data-data dalam basis data. Sebagai contoh, jika data-data dalam
struktur data Mahasiswa akan disimpan dalam media penyimpan bertipe
sekuensial berupa magnetic tape yang memiliki 9 track. Jika data disimpan tanpa
metode blocking, dengan menggunakan paritas genap. Dengan contoh isian nilai
rinci data sebagai berikut:
Nomor induk mahasiswa : 1998111000
(4 digit pertama mengkodekan tahun masuk,
1 digit berikutnya mengkodekan jenjang studi,
1 digit berikutnya mengkodekan jurusan, dan
4 digit terakhir mengkodekan nomor urutan)
Nama : Agus Junior
Alamat asal : Jalan Mawar 1 Semarang
Alamat lokal : Jalan Menur 10 Yogyakarta
Kode pos asal : 55555
Tempat lahir : Semarang
Tanggal lahir : 01-01-1980
Sekolah asal : SMA Negeri 1 Semarang
Tahun lulus di SLTA : 1998
Agama : Islam (dikodekan sebagai I)
Status : Menikah (dikodekan sebagai M)
Nama orang tua / wali : Agus Senior
Pekerjaan orang tua / wali: PNS
Maka penyimpanan contoh 1 record data dalam struktur data Mahasiswa
tersebut dapat digambarkan seperti ditunjukkan oleh Gambar 5.2.
Arah head Record #1 Record #2 ... Record #N 1 9 9 8 1 ... P N S IRG …
Track ke: 0 0 0 0 0 0 ... 1 0 0 … 1 0 0 0 0 0 ... 0 1 1 … 2 0 0 0 0 0 ... 1 0 0 … 3 0 1 1 1 0 ... 0 0 1 … 4 0 0 0 0 0 ... 0 1 0 … 5 0 0 0 0 0 ... 0 1 0 … 6 0 0 0 0 0 ... 0 1 1 … 7 1 1 1 0 1 ... 0 0 1 …
Dat
a
bit paritas: 8 1 0 0 1 1 ... 0 0 0 …
Gambar 5.2:Contoh penyimpanan record mahasiswa dalam magnetic tape
55..33.. IInntteerrffaaccee AAnnttaarr PPaannddaannggaann TTeerrhhaaddaapp BBaassiiss DDaattaa
Interface menyediakan layanan yang lengkap untuk lapisan yang lebih tinggi,
sehingga setiap lapisan akan bergantung pada lapisan di bawahnya. Interface akan
mengisolasi setiap perubahan yang terjadi pada lapisan lainnya. Operating System /
OS yang digunakan oleh sistem komputer yang mendukung basis data akan
menjamin perubahan tersebut.
Interface antara pemakai dan basis data dapat digambarkan sebagaimana
ditunjukkan oleh Gambar 5.3.
Kebutuhan data pemakai
Model eksternal / User view Acces method
DBMS
Model internal / Physical model Access method
OS Access method
Database
Interface 1
Interface 2
Interface 3
Gambar 5.3: Interface antara user dan database
Keterangan untuk masing-masing interface adalah sebagai berikut:
Interface 1: Kebutuhan data dari para pemakai akan memerlukan sistem pengelolaan
basis data (Data Base Management Systems / DBMS) untuk
mendeskripsikan kebutuhan tersebut, serta kondisi kewenangan dan
keamanan data. Berdasarkan model eksternal akan diketahui tentang
data tersebut dalam fisik media penyimpan. Berdasarkan deskripsi fisik
tersebut akan diketahui model internal dari metode akses yang
digunakan.
Interface 2: DBMS akan menentukan model internal yaitu metode akses yang akan
diimplementasikan secara berbeda-beda.
Interface 3: Metode akses dalam model internal bersama-sama OS akan mengakses
record dari fisik media penyimpan sekunder
Untuk menjamin agar pemisahan setiap lapisan tetap terjaga, maka OS perlu
menyembunyikan kompleksitas struktur rinci lapisan lebih rendah dari lapisan di
atasnya. Hal ini dapat dilakukan jika fungsi-fungsi pada lapisan di bawahnya
cukup handal dan efisien. Ketidakbergantungan dari deskripsi dan organisasi
antar lapisan sering disebut ketidakbergantungan data atau kebebasan data atau
independensi data (data independence).
55..44.. IInnddeeppeennddeennssii DDaattaa ((DDaattaa IInnddeeppeennddeennccyy))
Independensi data (data Independence) diartikan sebagai ketidaktergantungan /
kebebasan data dalam basis data. Independensi data dalam basis data
mempunyai dua dimensi yaitu secara fisik (physical data independence) dan
secara logik (logical data independence).
Independensi data secara fisik, dimaksudkan bahwa teknik dan cara-cara
penyimpanan dan pengaksesan data dalam fisik media penyimpan dapat
mengalami perubahan tanpa harus mengubah deskripsi logik basis data (Global
logical data /conseptual l view) yang digunakan dalam schema basis data.
Independensi data secara logik, dimaksdukan bahwa kebutuhan-kebutuhan data
para pemakai dapat mengalami perubahan tanpa harus mengubah pandangan
logik pemakai terhadap basis data atau deskripsi logik basis data (Global logical
data / conseptua l view) yang digunakan dalam schema basis data.
Berdasarkan keterangan di atas, maka independensi data akan memberikan
jaminan berupa fleksibilitas basis data, yaitu:
1. Media dan metode akses data dari fisik media penyimpan basis data
dapat mengalami perubahan tanpa harus mengubah pandangan
konseptual
2. Kebutuhan data-data oleh para pemakai basis data dapat mengalami
perubahan tanpa harus mengubah pandangan konseptual
3. Pemakai tidak perlu tahu kerumitan / kompleksitas yang terjadi berkaitan
dengan perancangan dan teknis penyimpanan basis data dalam media
penyimpan data yang digunakan
1
BBAABB VVII.. MMOODDEELL DDAATTAA
66..11.. DDeeffiinniissii MMooddeell DDaattaa
Dalam pandangan terhadap basis data, terdapat tiga level abstraksi data, yaitu
pandangan para pemakai, pandangan konseptual dan pandangan fisikal oleh seorang
perancang basis data. Para pemakai basis data umumnya adalah orang-orang yang
awam terhadap konsep dan teknologi yang digunakan dalam basis data.
Permasalahannya adalah pada saat merancang, seorang perancang perlu mengetahui
kebutuhan data dan informasi yang diinginkan oleh para pemakai. Dalam hal ini, maka
seorang perancang basis data / analis sistem harus selalu berkomunikasi dengan para
pemakai basis data. Untuk mengkomunikasikan rancangan basis data dan sistem yang
akan dikembangkan tersebut, diperlukan suatu cara yang mudah dipahami secara logika
oleh para pemakai basis data.
Para pemakai tidak perlu tahu kompleksitas dan kerumitan dalam teknis penyimpanan
data dalam media penyimpan. Pemakai juga tidak akan memperhatikan bagaimana data
disimpan dalam media penyimpan secara fisik. Untuk kepentingan ini, maka diperlukan
apa yang disebut sebagai model data. Model data merupakan suatu cara untuk
menjelaskan tentang data-data yang tersimpan dalam basis data dan bagaimana
hubungan antar data tersebut untuk para pemakai (user) secara logik.
66..22.. MMaaccaamm MMooddeell DDaattaa
Secara garis besar, model data dapat dikelompokkkan dalam 3 macam, yaitu:
1. Object based data model, model ini terdiri atas:
a. Entity relationship model
b. Semantic model
c. Binary model
2. Record based data model, model ini terdiri atas:
a. Hierarchycal model
2
b. Network model
c. Relational model
3. Physical based data model, model ini terdiri atas:
a. Unifying model
b. Frame memory
1. Object based data model Object based data model merupakan himpunan data dan prosedur / relasi yang
menjelaskan hubungan logik antar data dalam suatu basis data berdasarkan pada
obyek datanya.
Entity relationship model merupakan suatu model untuk menjelaskan hubungan antar
data dalam basis data berdasarkan suatu persepsi bahwa real world terdiri dari obyek-
obyek dasar yang mempunyai hubungan / kerelasian antar obyek-obyek dasar tersebut
yang dilukiskan dengan menggunakan simbol-simbol grafis tertentu. Semantic model
hampir sama dengan entity relationship model perbedaaannya adalah kerelasian antar
obyek dasar tidak dinyatakan dengan simbol tetapi secara semantik, yaitu
menggunakan kata-kata (semantic).
2. Record based data model
Model ini mendasarkan pada record / rekaman untuk menjelaskan kepada para pemakai
tentang hubungan logik antar data dalam basis data.
Hierarchycal model sering pula disebut sebagi tree structure, menjelaskan kepada
pemakai tentang hubungan logik antar data dalam basis data dalam bentuk hubungan
bertingkat. Elemen-elemen penyusunnya disebut sebagai node yang pada
kenyataannya dapat berupa rinci data, agregat data, atau record. Level paling tinggi
dalam suatu hirarki harus hanya terdapat satu node, dan disebut sebagai root. Suatu
node pada level yang lebih rendah hanya diijinkan mempunyai satu relasi dengan node
pada tingkat yang lebih tinggi, yang disebut sebagai parent. Sedangkan kebalikannya,
parent dapat mempunyai lebih dari satu child, yaitu node-node yang mempunyai level
lebih rendah dan dihubungkandengan parent. Suatu node yang tidak mempunyai child
disebut sebagai leaves. Jadi pada hierarchycal model tidak ada child yang mempunyai
lebih dari satu parent.
3
Network model sering pula disebut sebagai plex structure. Seperti halnya dengan
hierarchycal model, network model dapat dideskripsikan ke dalam struktur hubungan
bertingkat yang tersusun atas node-node. Dalam network model sebuah child dapat
mempunyai lebih dari satu parent. Hal ini yang membedakan antara hierarchycal model
dan network model. Teknik leveling pada netwok model dilakukan dengan cara yang
sama dengan hierarchycal model.
Relational model menjelaskan kepada pemakai tentang hubungan logik antar data
dalam basis data dengan merepresentasikannya ke dalam bentuk tabel-tabel yang
terdiri atas sejumlah baris yang menunjukkan record dan kolom yang menunjukkan
atribut tertentu. Relational model merupakan salah satu model yang banyak digunakan
dalam pemodelan dan perancangan basis data. Hal ini karena konsep dan terminologi
yang digunakan dalam model ini hampir sama dengan kondisi sesungguhnya yang
dihadapi oleh para pemakai, sehingga memudahkan para pemakai dalam
memahaminya. Perangkat lunak pengelolaan basis data yang tersedia di pasaran pun
banyak yang dikembangkan berdasarkan model ini.
3. Physical based data model
Model ini mendasarkan pada teknis penyimpanan record / rekaman dalam basis data.
Model ini jarang digunakan untuk memodelkan data kepada para pemakai karena
kerumitan dan kompleksitas yang tinggi sehingga justru akan menyulitkan para pemakai.
66..33.. PPeerraannggkkaatt LLuunnaakk YYaanngg TTeerrsseeddiiaa
Beberapa paket perangkat lunak pengelolaan basis data yang dikembangkan
berdasarkan model berdasarkan record (record based data model), antara lain adalah
sebagai berikut:
1. Hierarchycal model
a. IBM’s Information Systems (IMS)
b. Intel’s Sytem 2000
c. Informic’s Mark IV
2. Network model
4
a. Cullinet’s IDMS
b. CA-IDMS / DB
c. Cincom’s Total
d. Honeywell’s IDS / II
e. UNIVAC’s DMS 1100
f. DECSYSTEM-10
g. DECSYSTEM-20
h. DBTG
i. CODASYL
3. Relational model
a. Prototype:
⇒ System-R oleh IBM
⇒ INGRES oleh Universitas of California (UCLA)
⇒ MACAIMS
⇒ ADMINS oleh SMcIntosh
b. Paket komersial:
⇒ DB2 dari IBM
⇒ Rdb / VMS dari Digital Equipment Corporation
⇒ IBM’s Query by Example / IBM QBE
⇒ Tymshare’s MAGNUM
⇒ MULTICS
⇒ National CSS’s NOMAD
⇒ CODASYL DDL
⇒ Oracle dari Oracle Corporation
⇒ Informix dari Informic Corporation
⇒ Ingres dari ASK Group Inc.
⇒ Sybase dari Sybase Inc.
⇒ R:Base 5000 dari Microrim Corporation
Paket-paket perangkat lunak sistem pengelolaan basis data (Data Base
Management Systems / DBMS) yang baru dan banyak tersedia pada saat
hingga saat ini sebagian besar juga dikembangkan berdasarkan model
relational, misal:
5
1). dBase III+ dari Ashton Tate
2). DBase IV dari Ashton Tate
3). Visual dBase dari Borland International
4). Foxbase
5). Foxpro dari Microsoft Corporation
6). Visual Foxpro dari Microsoft Corporation
7). Microsoft SQL dari Microsoft Corporation
8). Dan lain-lain
Catatan:
Nama CODASYL diambil dari Conference On Data Systmes Language, yaitu sebuah
organisasi kumpulan pabrik komputer yang bertugas untuk merancang,
mengembangkan, dan merekomendasikan teknik dan bahasa untuk sistem pengolahan
data, analisis, implementasi, dan operasi dan membuat spesifikasi yang standar.
Hasilnya secara berturut-turut adalah:
1). COBOL (Common Business Language)
2). DBTG (Data Base Task Group)
3). DDLC (Data Description Language Commite)
4). DBLTG (Data Base Language Task Group)
5). CODASYL COBOL
Sedangkan ACM (Asociation for Computing Machinery) secara khusus bertugas
mengembangkan perangkat lunak untuk deskripsi file dan translasi.
BBAABB VVIIII.. EENNTTIITTYY RREELLAATTIIOONNSSHHIIPP MMOODDEELL // EERR__MM
Entity Relationship Model / ER_M merupakan suatu model data yang dikembangkan
berdasarkan obyek. ER_M digunakan untuk menjelaskan hubungan antar data dalam
basis data kepada pemakai secara logik. ER_M didasarkan pada suatu persepsi bahwa
real world terdiri atas obyek-obyek dasar yang mempunyai hubungan / kerelasian antar
obyek-obyek dasar tersebut. ER_M digambarkan dalam bentuk diagram yang disebut
diagram ER (ER_Diagram / ER_D) dengan menggunakan simbol-simbol grafis tertentu.
ER_M mudah relatif dipahami, bahkan oleh para pemakai yang awam. Bagi perancang
basis data, ER_D berguna untuk memodelkan sistem yang nantinya akan dikembangkan
basis datanya. Model ini juga membantu perancang basis data pada saat melakukan
analisis dan perancangan basis data karena model ini dapat menunjukkan macam data
yang dibutuhkan dan kerelasian antar data di dalamnya. Bagi pemakai, model ini sangat
membantu dalam hal pemahaman model sistem dan rancangan basis data yang akan
dikembangkan oleh perancang basis data.
77..11.. KKoommppoonneenn EERR__DD
Sebuah diagram ER / ER_D tersusun atas tiga komponen, yaitu entitas, atribut dan
kerelasian antar entitas. Secara garis besar, entitas merupakan obyek dasar yang terlibat
dalam sistem. Atribut berperan sebagai penjelas entitas, dan kerelasian menunjukkan
hubungan yang terjadi di antara dua entitas.
77..11..11.. EEnnttiittaass ((EEnnttiittyy))
1. Entitas Entitas menunjukkan obyek-obyek dasar yang terkait di dalam sistem. Obyek dasar dapat
berupa orang, benda, atau hal yang keterangannya perlu disimpan di dalam basis data.
Untuk menggambarkan entitas dilakukan dengan mengikuti aturan sebagai berikut:
1. Entitas dinyatakan dengan simbol persegi panjang
2. Nama entitas dituliskan di dalam simbol persegi panjang
3. Nama entitas berupa: kata benda, tunggal
4. Nama entitas sedapat mungkin menggunakan nama yang mudah dipahami dan
dapat menyatakan maknanya dengan jelas
Seringkali nama entitas dapat tersusun atas lebih dari satu kata. Untuk memenuhi aturan
penggambaran tersebut di atas, maka sering digunakan tanda _ (garis bawah / hypen /
under score) yang dimaksudkan untuk menyatakan bahwa beberapa kata tersebut
dianggap sebagai kata tunggal. Misal:
1. Untuk menyatakan nama entitas mata kuliah akan lebih baik dinamakan sebagai
Mata_Kuliah bukan Mata atau Kuliah, karena akan lebih mudah dipahami dan
bisa jadi dengan menggunakan nama Mata atau Kuliah akan mempunyai
perbedaan interpretasi bagi pemakai.
2. Untuk menyatakan nama entitas program studi akan lebih baik dinamakan
sebagai Program_Studi bukan Program atau Studi, karena akan lebih mudah
dipahami dan bisa jadi dengan menggunakan Program atau Studi akan
mempunyai perbedaan interpretasi bagi pemakai.
3. Untuk menyatakan nama entitas karyawan tetap akan lebih baik dinamakan
sebagai Karyawan_Tetap bukan Karyawan atau Tetap, karena untuk
membedakan dengan karyawan tidak tetap, nama entitas Tetap juga sulit
dipahami. Sedangkan nama entitas Karyawan_Tidak_Tetap lebih mudah
dipahami dari pada menggunakan nama Karyawan saja, karena tidak dapat
membedakan dengan karyawan tetap, demikian juga nama entitas Tidak atau
Tetap atau Tidak_Tetap saja menjadi kurang bermakna .
Dalam kasus yang lain, seringkali nama entitas yang panjang justru menyulitkan, pemakai
akan lebih memahami dengan nama yang lebih singkat. Misal:
1. Untuk menyatakan nama entitas orang tua / wali mahasiswa akan lebih baik
dinamakan sebagai Wali_Mahasiswa bukan Orang_Tua_Wali_Mahasiswa,
karena sudah cukup jelas untuk dipahami.
2. Untuk menyatakan nama entitas kabupaten / kodya / Dati II asal mahasiswa
akan lebih baik dinamakan sebagai Kabupaten_Mahasiswa bukan
Kabupaten_Kodya_Dati2_Asal_Mahasiswa, karena sudah cukup jelas untuk
dipahami.
3. Untuk menyatakan nama entitas propinsi / Dati I asal mahasiswa akan lebih baik
dinamakan sebagai Propinsi_Mahasiswa bukan
Propinsi_Dati1_Asal_Mahasiswa, karena sudah cukup jelas untuk dipahami.
Sekalipun tidak dianjurkan, singkatan juga dapat digunakan sebagai nama entitas. Misal:
1. Untuk menyatakan nama entitas orang tua / wali mahasiswa dapat
menggunakan nama Ortu_Mahasiswa, dimana Ortu dimaksudkan sebagai Orang
tua. Singkatan ini telah lazim digunakan, sehingga cukup mudah untuk tetap dapat
dipahami.
2. Untuk menyatakan nama entitas program studi dapat menggunakan nama
Prodi, dimana Prodi dimaksudkan sebagai Program Studi. Singkatan ini telah
lazim digunakan, sehingga cukup mudah untuk tetap dapat dipahami.
3. Untuk menyatakan nama entitas mahasiswa dapat menggunakan nama Mhs,
dimana Mhs dimaksudkan sebagai Mahasiswa. Singkatan ini telah lazim
digunakan, sehingga cukup mudah untuk tetap dapat dipahami.
Penentuan entitas dalam suatu sistem perlu dilakukan dengan cermat dan hati-hati. Tidak
semua orang, benda atau hal dapat disebut entitas. Hanya orang, benda, dan hal yang
terkait dengan sistem dan keterangannya perlu disimpan dalam basis data saja yang
dapat disebut entitas.
Selain itu, ketelitian sangat menentukan apakah sesuatu hal (khususnya) akan menjadi
sebuah entitas atau tidak. Sebagai contoh, keterangan mengenai kabupaten, sekalipun
hanya menerangkan bagian alamat seseorang, tetapi sebenarnya kabupaten merupakan
obyek dasar. Demikian juga untuk propinsi, agama, pekerjaan orang tua mahasiswa, dan
lainnya. Hal ini karena nilai-nilai data pada kabupaten, propinsi, agama, pekerjaan orang
tua mahasiswa tidak pasti (dapat berubah). Tetapi keterangan mengenai jenis kelamin
seseorang bukan merupakan sebuah entitas, karena nilainya telah pasti dan tidak akan
pernah berubah. Golongan darah seseorang, sekalipun merupakan suatu hal, tetapi
sebagimana jenis kelamin, nilai-nilai data dalam golongan darah sudah pasti, yaitu A, B,
AB, dan 0, sehingga bukan merupakan suatu entitas.
Sebagai contoh, dalam suatu subsistem pengolahan data akademik, entitas yang terlibat
dalam subsistem tersebut dapat meliputi orang-orang sebagaimana ditunjukkan oleh
Gambar 7.1, entitas berupa benda seperti ditunjukkan oleh Gambar 7,2, dan entitas
berupa hal-hal seperti ditunjukkan oleh Gambar 7.3.
Obyek Dasar Simbol Entitas
Mahasiswa Mahasiswa
Dosen Dosen
Wali Mahasiswa / Orang Tua Wali_Mahasiswa
Gambar 7.1: Contoh-contoh entitas berupa orang
Obyek Dasar Simbol Entitas
Ruang Ruang
Gambar 7.2: Contoh-contoh entitas berupa benda
Obyek Dasar Simbol Entitas
Mata Kuliah Mata_Kuliah
Angkatan Angkatan
Jenjang Studi Jenjang_Studi
Program Studi Program_Studi
Jurusan Jurusan
Fakultas Fakultas
Golongan Golongan
Mata kuliah Mata_Kuliah
Nilai Nilai
Ruang Ruang
Waktu Waktu
Kabupaten / Kodya Kabupaten
Propinsi Propinsi
Agama Agama
Pekerjaan Orang Tua Pekerjaan
Gambar 7.3: Contoh-contoh entitas berupa hal
Entitas-entitas yang terlibat dalam suatu subsistem / sistem bisa jadi akan berbeda-
beda untuk setiap organisasi. Contoh entitas dalam subsistem akademik pada Gambar
7.1, Gambar 7.2, dan Gambar 7.3, bisa jadi akan berbeda untuk perguruan tinggi
lainnya. Sebagai contoh, jika perguruan tinggi tersebut hanya menyelenggarakan
pendidikan dalam sebuah fakultas saja (Sekolah Tinggi misalnya), maka tentu saja tidak
ada entitas fakultas. Atau jika perguruan tinggi tersebut hanya menyelenggarakan
sebuah Program Studi saja, maka tidak perlu entitas Program Studi. Atau jika perguruan
tinggi tersebut hanya mempunyai sebuah Jurusan saja, maka tidak perlu entitas
Jurusan. Atau jika perguruan tinggi tersebut hanya menyelenggarakan sebuah Jenjang
Studi saja, maka tidak perlu entitas Jenjang Studi.
2. Isian entitas Isian entitas menyatakan sebuah kemungkinan pada entitas. Contoh isian entitas:
⇒ Mahasiswa dengan NIM 02050001
⇒ Mahasiswa bernama Rita
⇒ Mata kuliah dengan kode mata kuiah MK001
⇒ Mata kuliah dengan nama Pemrograman I
⇒ Alamat mahasiswa Jl. Pangeran Diponegoro 100
⇒ Dosen bernama Agus
⇒ Golongan gaji IIIA
3. Himpunan entitas Himpunan entitas menyatakan sekumpulan entitas dengan struktur / sifat yang sama.
Contoh himpunan entitas:
⇒ Sejumlah mahasiswa jenjang sarjana
⇒ Sejumlah mahasiswa jenjang diploma
⇒ Semua mahasiswa
⇒ Sejumlah mata kuliah wajib
⇒ Sejumlah mata kuliah konsentrasi
⇒ Sejumlah mata kuliah pilihan
⇒ Semua mata kuliah
⇒ Sejumlah karyawan tetap
⇒ Sejumlah karyawan tidak tetap
⇒ Semua karyawan
4. Entitas reguler Entitas reguler disebut juga entitas dominan, merupakan entitas yang keberadaannya
tidak bergantung pada entitas yang lain. Contoh entitas reguler:
⇒ Mahasiswa
⇒ Mata_Kuliah
⇒ Karyawan
⇒ Kabupaten
⇒ Propinsi
⇒ Pekerjaan
⇒ Agama
5. Entitas dependen Entitas dependen disebut juga entitas tak bebas / independen atau entitas lemah (weak
entity) atau entitas subordinat, merupakan entitas yang keberadaannya bergantung
pada entitas yang lain. Artinya entitas dependen dapat muncul jika ada entitas lain
sebagai acuannya (entitas reguler). Contoh entitas dependen:
⇒ Mahasiswa_Jenjang_Sarjana, bergantung pada entitas Mahasiswa
⇒ Mahasiswa_Jenjang_Diploma, bergantung pada entitas Mahasiswa
⇒ Mata_Kuliah_Wajib, bergantung pada entitas Mata_Kuliah
⇒ Mata_Kuliah_Konsentrasi, bergantung pada entitas Mata_Kuliah
⇒ Mata_Kuliah_Pilihan, bergantung pada entitas Mata_Kuliah
⇒ Karyawan_Tetap, bergantung pada entitas Karyawan
⇒ Karyawan_Tidak_Tetap, bergantung pada entitas Karyawan
⇒ Wali_Mahasiswa, bergantung pada entitas Mahasiswa
Untuk menggambarkan entitas dependen digunakan simbol dua persegi panjang
(dobel). Dalam contoh di atas, maka nama setiap entitas tersebut dituliskan dalam dua
persegi panjang (lihat contoh entitas Dosen_Wali dan Wali_Mahasiswa sebelumnya).
6. Entitas super type dan entitas sub type
Sebuah entitas bisa jadi mempunyai hubungan antar entitas dengan sifat bahwa salah
suatu entitas merupakan bagian dari entitas yang lainnya. Entitas super type
merupakan entitas yang mempunyai tingkatan lebih tinggi, yaitu membawahi atau
mempunyai entitas bagain yang lebih rendah. Sedangkan entitas sub type merupakan
entitas yang lebih rendah, yaitu entitas yang menjadi entitas bagian entitas lain.
Sebagai contoh, entitas Karyawan_Tetap dan Karyawan_Tidak_Tetap merupakan
bagian dari entitas Karyawan. Entitas Karyawan disebut sebagai entitas super type
(super type entity), sedangkan entitas Karyawan_Tetap dan Karyawan_Tidak_Tetap
disebut sebagai entitas sub type (sub type entity), terhadap entitas Karyawan. Untuk
menyatakan entitas super type dan sub type, ditunjukkan oleh Gambar 7.4.
Karyawan
Karyawan_Tetap Karyawan_Tidak_Tetap
Gambar 7.4: Entitas super type dan sub type
77..11..22.. AAttrriibbuutt ((AAttttrriibbuuttee))
Atribut sering pula disebut sebagai properti (property), merupakan keterangan-
keterangan yang terkait pada sebuah entitas yang perlu disimpan sebagai basis data.
Aribut berfungsi sebagai penjelas sebuah entitas.
Untuk menggambarkan atribut dilakukan dengan mengikuti aturan sebagai berikut:
1. Atribut dinyatakan dengan simbol ellips
2. Nama atribut dituliskan di dalam simbol ellips
3. Nama atribut berupa: kata benda, tunggal
4. Nama atribut sedapat mungkin menggunakan nama yang mudah dipahami dan
dapat menyatakan maknanya dengan jelas
5. Atribut dihubungkan dengan entitas yang bersesuaian dengan menggunakan
sebuah garis (seyogyanya menggunakan garis lurus, namun dalam kondisi yang
tidak memungkinkan dapat tidak menggunakan garis lurus)
Sebagaimana dapat terjadi dalam entitas, penamaan atribut diusahakan agar mudah
dipahami (khususnya oleh para pemakai). Nama-nama yang digunakan sebagai atribut
juga harus jelas menunjukkan maknanya. Jika perlu, penggunaan tanda _ (garis bawah
/ underscore / hypen), atau penggunaan singkatan juga diijinkan sepanjang lebih mudah
dipahami.
Contoh-contoh atribut untuk setiap entitas dalam contoh subsistem pengolahan data
akademik dalam Gambar 7.1, Gambar 7.2, dan adalah ditampilkan pada Tabel 7.1.
Tabel 7.1: Contoh-contoh atribut
Simbol Entitas Atribut Mahasiswa Kode_Angkatan, Kode_Program_Studi, Kode_Jenjang_Studi, Nomor,
Nama_Mahasiswa, Tanggal_Lahir, Alamat_Lokal, Kode_Agama, Status
Dosen NIK, Nama_Dosen, Tanggal_Lahir, Alamat_Lokal, Kode_Golongan, Kode_Agama, Tanggal_SK, Nomor_SK, No_Telepon, Status
Mata Kuliah Kode_Mata_Kuliah, Nama_Mata_Kuliah, Sks, Smt, Status Angkatan Kode_Angkatan, Tahun_Angkatan Jenjang Studi Kode_Jenjang_Studi, Nama_Jenjang_Studi Program Studi Kode_Prodi, Nama_Prodi, Tanggal_SK, Nomor_SK, Status,
Kode_Jurusan, Sks_Program_Studi Jurusan Kode_Jurusan, Nama_Jurusan, Tanggal_SK, Nomor_SK,
Kode_Fakultas Fakultas Kode_Fakultas, Nama_Fakultas,Tanggal_SK, No_SK Golongan Kode_Golongan, Nama_Golongan, Gaji_Pokok Nilai Nilai, Mutu, Keterangan Ruang Kode_Ruang, Kapasitas Waktu Kode_Waktu, Hari, Jam_Mulai, Status Wali_Mahasiswa Kode_Angkatan, Kode_Jenjang_Studi, Kode_Jurusan, Nomor,
Nama_Wali, Alamat_Asal, Kode_Pekerjaan, Kode_Kabupaten Kabupaten Kode_Kabupaten, Nama_Kabupaten, Kode_Propinsi Propinsi Kode_Propinsi, Nama_Propinsi Agama Kode_Agama, Nama_Agama Pekerjaan Kode_Pekerjaan, Nama_Pekerjaan
Sebagai contoh, penggambaran atribut pada entitas Mahasiswa ditunjukkan oleh
Gambar 7.5.
Mahasiswa
Kode_Angkatan
Kode_Program_Studi
Kode_Jenjang_Studi
Kode_Jurusan
Nomor
Nama_Mahasiswa
Tanggal_lahir
Alamat_Lokal
Kode_Agama
Status
Gambar 7.5: Contoh atribut pada entitas Mahasiswa
Atribut pada sebuah entitas dapat diklasifikasikan dalam dua kelompok, yaitu:
1. Atribut sederhana (simple attribute), yaitu jika atribut berisi sebuah komponen
nilai / elementer. Contoh atribut sederhana dan nilai atribut dalam entitas
Mahasiswa adalah:
⇒ Kode_Angkatan : 2002 (angkatan tahun 2002)
⇒ Kode_Program_Studi : 01(program studi Teknik Informatika)
⇒ Kode_Jenjang_Studi : 08 (jenjang studi sarjana)
⇒ Kode_Jurusan : 01 (jurusan Teknik Informatika)
⇒ Nomor : 1000 (nomor 2002)
⇒ Kode_Agama : I (agama Islam)
⇒ Status : B (status biasa)
2. Atribut komposit (composite attribute), yaitu jika atribut berisi lebih dari sebuah
komponen nilai. Contoh atribut komposit dan nilai atribut dalam entitas
Mahasiswa adalah:
⇒ Nama_Mahasiswa : Mawar Menur Melati
Terdiri atas komponen nilai,
Nama depan = Mawar
Nama tengah = Menur
Nama akhir = Melati
⇒ Tanggal_Lahir : 01-01-1980
Terdiri atas komponen nilai,
Tanggal = 01
Bulan = 01
Tahun = 1980
⇒ Alamat_Lokal : Jl. Mawar 100, Yogyakarta, 5000
Terdiri atas komponen nilai,
Nama jalan = Mawar
Nomor rumah = 100
Kota = Yogyakarta
Kode pos = 5000
Catatan:
Atribut nama dapat dianggap atribut sederhana atau atribut komposit, tergantung nilai
datanya. Jika hanya memuat satu kata, maka teramsuk atribut sederhana. Tetapi jika
memuat lebih dari satu kata, maka termasuk atribut komposit. Nama-nama di Indonesia
tidak selalu mempunyai 3 komponen nama (depan, tengah, dan akhir).
77..11..33.. KKeerreellaassiiaann AAnnttaarr EEnnttiittaass ((RReellaattiioonnsshhiipp))
Kerelasian antar entitas mendefinisikan hubungan antar dua buah entitas. Kerelasian
adalah kejadian atau transaksi yang terjadi di antara dua buah entitas yang
keterangannya perlu disimpan dalam basis data. Kejadian atau transaksi yang tidak
perlu disimpan dalam basis data (sekalipun benar-benar terjadi) bukan termasuk
kerelasian.
Aturan penggambaran kerelasian antar entitas adalah sebagai berikut:
1. Kerelasian dinyatakan dengan simbol belah ketupat
2. Nama kerelasian dituliskan di dalam simbol belah ketupat
3. Kerelasian menghubungkan dua entitas
4. Nama kerelasian berupa: kata kerja aktif (diawali dengan awalan me), tunggal
5. Nama kerelasian sedapat mungkin menggunakan nama yang mudah dipahami
dan dapat menyatakan maknanya dengan jelas
77..11..33..11 JJeenniiss KKeerreellaassiiaann AAnnttaarr EEnnttiittaass ((RReellaattiioonnsshhiipp))
Kerelasian antar entitas dapat dikelompokkan dalam tiga jenis, yaitu:
1. Kerelasian jenis 1-ke-1 / satu ke satu (one to one)
Kerelasian jenis ini terjadi jika kejadian atau transaksi di antara dua entitas yang
berhubungan hanya memungkinkan terjadi sebuah kejadian atau transaksi pada
kedua entitas. Secara lebih teknis, jika nilai yang digunakan sebagai penghubung
pada entitas pertama hanya dimungkinkan muncul satu kali saja pada entitas kedua
yang saling berhubungan.
Sebagai contoh, satu orang mahasiswa (atribut-atributnya tersimpan dalam entitas
Mahasiswa) hanya dimungkinkan mempunyai satu orang wali mahasiswa (atribut-
atributnya tersimpan dalam entitas Wali_Mahasiswa). Dengan demikian, atribut
Angkatan, Kode_Jenjang_Studi, Kode_Jurusan, Nomor dalam entitas Mahasiswa
hanya dimungkinkan muncul sekali saja di dalam entitas Wali_Mahasiswa. Jelasnya
setiap mahasiswa hanya dimungkinkan mempunyai seorang wali mahasiswa.
2. Kerelasian jenis n-ke-1 / banyak ke satu (many to one) atau 1-ke-n / satu ke banyak
(one to many)
Kerelasian jenis ini terjadi jika kejadian atau transaksi di antara dua entitas yang
berhubungan hanya memungkinkan terjadi satu kali dalam entitas pertama dan
dapat terjadi lebih dari satu kali kejadian atau transaksi pada entitas kedua. Secara
lebih teknis, jika nilai yang digunakan sebagai penghubung pada entitas pertama
dimungkinkan muncul lebih dari satu kali pada entitas kedua yang berhubungan.
Sebagai contoh, lebih dari satu mahasiswa (atribut-atributnya tersimpan dalam
entitas Mahasiswa) dapat memilih hanya satu buah program studi (atribut-
atributnya tersimpan dalam entitas Program_Studi). Kondisi seperti ini disebut jenis
kerelasian n-ke-1.
Tetapi sebaliknya, satu buah program studi (atribut-atributnya tersimpan dalam
entitas Program_Studi) dapat dipilih oleh lebih dari satu mahasiswa (atribut-
atributnya tersimpan dalam entitas Mahasiswa). Dengan demikian, atribut
Kode_Jenjang_Studi dalam entitas Mahasiswa hanya dimungkinkan muncul sekali
saja di dalam entitas Program_Studi, tetapi sebuah Kode_Program_studi di dalam
entitas Program_studi dapat muncul lebih dari satu kali dalam entitas mahasiswa.
Jelasnya setiap mahasiswa hanya dimungkinkan memilih sebuah program studi,
sebaliknya sebuah program studi dapat dipilih oleh lebih dari satu orang mahasiswa.
Kondisi seperti ini disebut jenis kerelasian 1-ke-n.
3. Kerelasian jenis n-ke-n / banyak ke banyak (many to many)
Kerelasian jenis ini terjadi jika kejadian atau transaksi di antara dua entitas yang
berhubungan memungkinkan terjadi lebih dari satu kali dalam entitas pertama dan
entitas kedua. Secara lebih teknis, jika nilai yang digunakan sebagai penghubung
pada entitas pertama dimungkinkan muncul lebih dari satu kali, baik pada entitas
pertama maupun pada entitas kedua yang saling berhubungan.
Sebagai contoh, lebih dari satu mahasiswa (atribut-atributnya tersimpan dalam
entitas Mahasiswa) dapat memilih lebih dari satu mata kuliah (atribut-atributnya
tersimpan dalam entitas Mata_Kuliah). Kondisi seperti ini disebut jenis kerelasian n-ke-n.
Suatu kerelasian antara dua buah entitas akan merepresentasikan suatu kunci
penghubung atau file transaksi. Jenis kerelasian 1-ke-1 dan n-ke-n, umumnya
memerlukan file transaksi, sedangkan jenis kerelasian 1-ke-n umumnya memerlukan
atribut sebagai kunci penghubung.
Jenis kerelasian sangat bergantung pada aturan bisnis (business rule) yang digunakan
pada sistem / organisasi. Untuk dua entitas yang sama, pada subsistem yang sama,
tetapi pada organisasi yang berbeda, bisa menghasilkan jenis kerelasian yang berbeda.
Sebagai contoh, kerelasian antara entitas Dokter dan entitas Pasien dalam sebuah pusat
layanan kesehatan. Jenis kerelasian tersebut bisa jadi termasuk jenis 1-ke-n, yaitu jika
pusat layanan kesehatan tersebut berada di lokasi daerah terpencil yang mana hanya
tersedia seorang dokter saja, sedangkan pasiennya bisa lebih dari satu orang.
Tetapi jenis kerelasian tersebut bisa berubah menjadi n-ke-n, yaitu jika pusat layanan
kesehatan tersebut berada di lokasi perkotaan, dimana dalam pusat layanan kesehatan
tersedia lebih dari seorang dokter yang dapat memeriksa seorang pasien secara
bersamaan atau gabungan (misal, proses operasi penyakit yang diderita pasien akan
melibatkan banyak dokter sekaligus). Tetapi tetap saja, seorang dokter akan dapat
melayani banyak pasien.
Jenis kerelasian tidak dibatasi oleh lokasi geografis. Tempat kejadian / transaksi tidak
berpengaruh terhadap jenis kerelasian. Kejadian / transaksi di antara dua entitas dapat
terjadi pada tempat yang saling berjauhan, asalkan masih berada dalam lingkup sebuah
sistem. Transaksi penarikan uang di mesin ATM misalnya, seorang nasabah (entitas
Nasabah) yang memiliki rekening tabungan (entitas Tabungan) di kota Jakarta, dapat
menarik uangnya dari kota Yogyakarta.
Jenis kerelasian juga tidak dibatasi oleh waktu. Waktu kejadian / transaksi tidak
berpengaruh terhadap jenis kerelasian. Kejadian / transaksi di antara dua entitas dapat
terjadi pada selang rentang waktu yang sangat lama, asalkan masih berada dalam
lingkup sebuah sistem. Berkaitan dengan kejadian / transaksi pemeriksaan oleh Dokter (entitas Dokter) di pusat layanan kesehatan misalnya, seorang pasien (entitas Pasien)
selama hidupnya mungkin hanya memeriksakan dirinya sebanyak dua kali ke Dokter.
Jenis kerelasian juga tidak dibatasi kasus per kasus. Sebuah kemungkinan kejadian /
transaksi tidak berpengaruh terhadap jenis kerelasian secara umum. Kejadian / transaksi
di antara dua entitas ditentukan oleh kemungkinan umum yang dapat terjadi, asalkan
masih berada dalam lingkup sebuah sistem. Berkaitan dengan kejadian / transaksi
pemeriksaan oleh Dokter (entitas Dokter) di pusat layanan kesehatan misalnya, seorang
pasien (entitas Pasien) mungkin hanya memeriksakan dirinya sebanyak satu kali ke
Dokter, tetapi pasien lain bisa lebih dari satu kali. Jadi secara umum, pasien dapat
memeriksakan lebih dari satu kali. Dengan demikian, jenis kerelasiannya dapat termasuk
jenis 1-ke-n atau n-ke-n, bukan 1-ke-1 (tergantung ukuran pusat layanan kesehatan).
Untuk memberikan contoh kerelasian antar entitas yang lebih lengkap, dalam contoh
subsistem pengolahan data akademik di atas, maka kerelasian-kerelasian yang mungkin
adalah sebagai berikut:
1. Mahasiswa mengikuti Mata_Kuliah dicatat dalam KRS dengan keterangan yang
perlu disimpan dalam basis data / atribut meliputi:
⇒ Kode_Angkatan
⇒ Kode_Jenjang_Studi
⇒ Kode_Program_Studi
⇒ Nomor
⇒ Kode_Mata_Kuliah
⇒ Tahun_Semester
2. Mahasiswa mengikuti Mata_Kuliah memperoleh Nilai dicatat dalam KHS
dengan keterangan yang perlu disimpan dalam basis data / atribut meliputi:
⇒ Kode_Angkatan
⇒ Kode_Jenjang_Studi
⇒ Kode_Program_Studi
⇒ Nomor
⇒ Kode_Mata_Kuliah
⇒ Tahun_Semester
⇒ Nilai
3. Dosen mengajar Mata_Kuliah dicatat dalam Dosen_Mengajar dengan
keterangan yang perlu disimpan dalam basis data / atribut:
⇒ NIK
⇒ Kode_Mata_Kuliah
⇒ Tahun_Semester
⇒ Status
4. Dosen mengajar Mata_Kuliah menggunakan Ruang dicatat dalam Jadwal
dengan keterangan yang perlu disimpan dalam basis data / atribut meliputi:
⇒ Kode_Mata_Kuliah
⇒ Kode_Ruang
⇒ Tahun_Semester
⇒ Kode_Waktu
5. Mahasiswa mempunyai Angkatan memerlukan atribut penghubung
Kode_Angkatan dalam entitas Mahasiswa
6. Mahasiswa memilih Program_Studi memerlukan atribut penghubung
Kode_Program_Studi dalam entitas Mahasiswa
7. Mahasiswa memilih Jenjang_Studi memerlukan atribut penghubung
Kode_Jenjang_Studi dalam entitas Mahasiswa
8. Mahasiswa menganut Agama memerlukan atribut penghubung Kode_Agama
dalam entitas Mahasiswa
9. Mahasiswa mempunyai Dosen_Wali dicatat dalam Dosen_Wali dengan
keterangan yang perlu disimpan dalam basis data / atribut meliputi:
⇒ Kode_Angkatan
⇒ Kode_Jenjang_Studi
⇒ Kode_Program_Studi
⇒ Nomor
⇒ NIK
10. Mahasiswa mempunyai Wali_Mahasiswa dicatat dalam Wali_Mahasiswa
dengan keterangan yang perlu disimpan dalam basis data / atribut meliputi:
⇒ Kode_Angkatan
⇒ Kode_Jenjang_Studi
⇒ Kode_Program_Studi
⇒ Nomor
⇒ Nama_Wali
⇒ Alamat_Asal
⇒ Kode_Pekerjaan
⇒ Kode_Kabupaten
11. Jurusan membawahi Program_Studi memerlukan atribut penghubung
Kode_Jurusan dalam entitas Program_Studi
12. Fakultas membawahi Jurusan memerlukan atribut penghubung Kode_Fakultas
dalam entitas Jurusan
13. Dosen mempunyai Golongan memerlukan atribut penghubung Kode_Golongan
dalam entitas Dosen
14. Dosen menganut Agama memerlukan atribut penghubung Kode_Agama dalam
entitas Dosen
15. Wali mempunyai Pekerjaan memerlukan atribut penghubung Kode_Pekerjaan
dalam entitas Wali_Mahasiswa
16. Wali menempati Kabupaten memerlukan atribut penghubung Kode_Kabupaten
dalam entitas Wali_Mahasiswa
17. Kabupaten menempati Propinsi memerlukan atribut penghubung Kode_Propinsi
dalam entitas Kabupaten
Catatan: Jenis kerelasian seperti contoh di atas dapat berubah tergantung pada aturan bisnis yang
diterapkan pada perguruan tinggi yang bersangkutan.
Hal penting lain yang perlu diperhatikan di dalam ER_M, adalah adanya kejadian-kejadian
/ transaksi-transaksi yang sekalipun benar-benar terjadi tetapi keterangannya tidak perlu
disimpan dalam basis data. Kejadian / transaksi seperti ini tidak termasuk sebagai
kerelasian antar entitas. Contoh-contoh kejadian / transaksi di antara dua entitas yang
tidak termasuk sebagai kerelasian antar entitas adalah sebagai berikut:
1. Mahasiswa memilih mata kuliah yang akan diikutinya sebelum akhirnya ia
menentukan mata kuliah pilihannnya dan kemudian mengisikannya ke dalam
blangko KRS. Kejadian memilih tersebut tidak termasuk sebagai kerelasian antar
entitas, tetapi hasil akhir mata kuliah yang benar-benar akan diikutinya dan
dicantumkan dalam KRS itulah yang termasuk kerelasian antar entitas.
2. Mahasiswa menanyakan daftar mata kuliah yang ditawarkan pada Program Studi
untuk semester tertentu. Kejadian menanyakan tersebut bukan termasuk
kerelasian antar entitas.
3. Mahasiswa menuliskan daftar mata kuliah dalam blangko KRS. Kejadian
menuliskan tersebut bukan termasuk kerelasian antar entitas.
4. Mahasiswa meminta tanda tangan Dosen wali dalam blangko KRS. Kejadian
meminta tersebut bukan termasuk kerelasian antar entitas.
5. Dosen menanyakan daftar mata kuliah yang diikuti oleh mahasiswa. Kejadian
menanyakan tersebut bukan termasuk kerelasian antar entitas.
6. Dosen menyarankan mata kuliah yang akan diikuti oleh mahasiswa. Kejadian
menyarankan tersebut bukan termasuk kerelasian antar entitas.
7. Dosen memasuki ruang kelas untuk mengajar mata kuliah. Kejadian memasuki
ruang kelas tersebut bukan termasuk kerelasian antar entitas.
8. Dosen menjelaskan materi suatu mata kuliah di kelas. Kejadian menjelaskan
tersebut bukan termasuk kerelasian antar entitas.
Tentu saja masih sangat banyak kejadian / transaksi lain yang dapat terjadi di antara
entitas. Permasalahannya, kejadian / transaksi tersebut merupakan kejadian / transaksi
yang tidak perlu disimpan dalam basis data, sehingga tidak termasuk kerelasian antar
entitas.
77..11..33..22 SSiimmbbooll KKeerreellaassiiaann AAnnttaarr EEnnttiittaass
Sebagaimana dijelaskan sebelumnya, ER_M ditunjukkan menggunakan sebuah diagram
yang disebut diagram ER (ER_Diagram / ER_D). Sekalipun bukan menjadi sebuah
permasalahan, dalam beberapa referensi, terdapat perbedaan dalam hal penggunaan
simbol kerelasian antar entitas. Untuk menggambarkan kerelasian antar entitas, dapat
digunakan salah satu dari pilihan simbol berikut:
1. Pilihan 1 Jenis kerelasian Simbol yang digunakan
1-ke-1 :
1-ke-n :
n-ke-1 :
n-ke-n :
Gambar 7.6: Simbol kerelasian antar entitas (pilihan 1)
2. Pilihan 2 Jenis kerelasian Simbol yang digunakan
1-ke-1 : 1 1
1-ke-n : 1 n
n-ke-1 : n 1
n-ke-n : n n
Gambar 7.7: Simbol kerelasian antar entitas (pilihan 2)
3. Pilihan 3 Jenis kerelasian Simbol yang digunakan
1-ke-1 :
1-ke-n :
n-ke-1 :
n-ke-n :
Gambar 7.8: Simbol kerelasian antar entitas (pilihan 3)
Saat menggambarkan ER_D, kita dapat menggunakan salah satu dari pilihan di atas
sesuai keinginan kita, yang penting penggunaan simbol tersebut dilakukan seacar
konsisten. Artinya, kalau kita menggunakan simbol kelompok pilihan 1, maka untuk
seluruh bagian dalam ER_D harus menggunakan simbol dalam Pilihan 1 tersebut. Jika
menggunakan simbol dalam pilihan 2, maka semua bagian ER_D harus menggunakan
simbol dalam pilihan 2. Demikian juga jika yang digunakan adalah pilihan 3, maka
seluruh bagian ER_D harus menggunakan simbol dalam pilihan 3.
Sebagai contoh untuk menunjukkan hubungan antar entitas Mahasiswa dan entitas
Mata_Kuliah dengan nama kerelasian mengikuti, dengan jenis n-ke-n, maka dapat
digambarkan sebagaimana ditunjukkan oleh Gambar 7.9 (dalam pilihan 1), Gambar 7.10
(dalam pilihan 2), dan Gambar 7.11 (dalam pilihan 3).
mengikuti Mata_Kuliah Mahasiswa
Gambar 7.9: Contoh kerelasian antara entitas Mahasiswa dan Mata_Kuliah (pilihan 1)
n n mengikuti Mata_Kuliah Mahasiswa
Gambar 7.10: Contoh kerelasian antara entitas Mahasiswa dan Mata_Kuliah (pilihan 2)
mengikuti Mata_Kuliah Mahasiswa
Gambar 7.11: Contoh kerelasian antara entitas Mahasiswa dan Mata_Kuliah (pilihan 3)
77..11..33..33 IInnssttaann KKeerreellaassiiaann BBeerrggaannddaa
Dalam kerelasian antara dua buah entitas, dimungkinkan terjadinya dua kerelasian
sekaligus di antara dua entitas tersebut. Kondisi kerelasian semacam ini disebut sebagai
instan kerelasian berganda. Contoh instan kerelasian berganda adalah kerelasian antara
entitas Anggota perpustakaan dan Buku. Anggota dapat meminjam Buku dari
perpustakaan, dan Anggota juga bisa mengembalikan Buku ke perpustakaan, dengan
jenis kerelasian n-ke-n. Instan kerelasian berganda antara entitas Anggota dan Buku
tersebut dapat digambarkan sebagaimana ditunjukkan oleh Gambar 7.12.
meminjam
Anggota Buku
mengembalikan
Gambar 7.12: Contoh instan kerelasian berganda
Dalam sebuah sistem, umumnya terdapat sejumlah kerelasian antara sejumlah entitas.
77..11..33..44 KKeerreellaassiiaann RReekkuurrssiiff
Kerelasian rekursif, terjadi jika sebuah entitas mempunyai kerelasian dengan entitas
dirinya sendiri. Sebagai contoh, dalam entitas Mata_Kuliah, bisa jadi sebuah mata kuliah
dapat diikuti oleh mahasiswa apabila mahasiswa tersebut telah mengikuti mata kuliah lain
yang menjadi prasyarat bagi mata kuliah tersebut. Atau sebuah mata kuliah mempunyai
prasyarat mata kuliah lain, misal mata kuliah Pemrograman II dapat diikuti oleh
Mahasiswa jika sudah mengikuti mata kuliah Pemrograman I.
Kondisi semacam ini disebut sebagai kerelasian rekursif, dengan jenis kerelasian 1-ke-n.
Kerelasian rekursif entitas Mata_kuliah tersebut dapat digambarkan sebagaimana
ditunjukkan oleh Gambar 7.13.
Mata_Kuliah mensyaratkan
Gambar 7.13: Contoh kerelasian rekursif
77..11..33..55 KKeerreellaassiiaann AAssoossiiaattiiff
Kerelasian asosiatif, terjadi jika kerelasian di antara dua buah entitas mengandung
beberapa informasi. Sebagai contoh, hubungan antara entitas Pelanggan dan Barang
dapat menunjukkan kerelasian asosiatif jika ada kebijakan dari penjual, bahwa bagi para
Pelanggan yang membeli Barang pada masa diskon akan diberikan khusus. Jika
Pelanggan tersebut membeli barang pada tanggal tertentu dalam masa diskon, maka
pelanggan tersebut akan memperoleh diskon. Dengan demikian, kerelasian membeli di
antara entitas Pelanggan dan entitas Barang akan mengandung informasi lain, yaitu
Tanggal_Beli dan Diskon, yang kemudian diberi nama Pembeli.
Kondisi semacam ini disebut sebagai kerelasian asosiatif, dengan jenis kerelasian 1-ke-n.
Kerelasian asosiatif antara entitas Pelanggan dan Barang tersebut dapat digambarkan
sebagaimana ditunjukkan oleh Gambar 7.14.
membeli Barang Pelanggan
Dapat digambarkan
menjadi
Pembeli Barang Pelanggan
Gambar 7.14: Contoh kerelasian asosiatif
77..22.. MMeennggggaammbbaarr EERR__DD
Untuk menggambarkan ER_D secara lengkap, maka dapat dilakukan dengan mengikuti
serangkaian langkah sebagai berikut:
1. Identifikasikan setiap entitas yang terlibat
2. Identifikasikan setiap atribut pada setiap entitas
3. Identifikasikan setiap kerelasian berikut jenisnya yang terjadi di antara entitas
4. Gambarkan simbol-simbol entitas, atribut, dan kerelasian antar entitas sedemikian
sehingga simbol kerelasian dapat digambarkan dengan jelas / tidak saling
bertabrakan
5. Cek ER_D yang terbentuk, dalam hal:
a. Kelengkapan entitas
b. Kelengkapan atribut
c. Kelengkapan kerelasian antar entitas
d. Jenis kerelasian antar entitas
Untuk subsistem yang sederhana, seluruh rangkaian langkah tersebut akan menghasilkan
sebuah diagram yang sangat lengkap, memuat komponen entitas, atribut, dan kerelasian
antar entitas. Permasalahan menggambar ER_D mungkin akan dijumpai, ketika sistem
mempunyai sejumlah entitas, atribut, dan kerelasian yang sangat banyak, dan kerelasian
kerelasian antar entitas sangat komplek, sehingga sangat kesulitan jika digambarkan
secara keseluruhan. Diagram yang terbentuk mungkin menjadi sangat komplek dan
ruwet, sehingga menjadi sulit untuk dipahami. Jika demikian, maka ada tiga pilihan yang
dapat digunakan, yaitu:
1. Cara 1: Gambarkan ER_D yang hanya memuat komponen entitas dan kerelasian antar
entitas saja. Selanjutnya rincian atribut pada setiap entitas dapat ditampilkan
secara terpisah, yang disusun dalam bentuk naratif atau tabel. Cara ini paling
banyak digunakan, karena mengurangi kompleksitas ER_D.
2. Cara 2: Gambarkan ER_D secara terpisah-pisah bagian demi bagian atau sepotong demi
sepotong, dimana masing-masing bagian / potongan memuat komponen entitas,
atribut, dan kerelasian antar entitas untuk suatu bagain yang lebih kecil. Misal,
dalam subsistem pengolahan data akademik, dapat terdiri atas bagian / potongan
ER_D untuk kelompok Mahasiswa, Dosen, dan Mata_Kuliah. Setiap bagian
tersebut memuat entitas, atribut, dan kerelasian yang terkait saja. Cara ini relatif
jarang digunakan, tetapi dalam beberapa kesempatan justru akan lebih
memudahkan pemahamaan.
3. Cara 2: Gabungkan cara 1 dan cara 2 sekaligus, sesuai dengan kondisi ER_D yang akan
digambarkan. Jika cara ini yang dipilih, maka kelompokkan setiap entitas ke dalam
bagian-bagian / potongan-potongan paling baik. Gambarkan ER_D setiap bagian /
potongan tersebut yang hanya memuat komponen entitas dan kerelasian antar
entitas saja. Selanjutnya setiap bagain / potongan dilengkapi dengan keterangan
atau tabel yang memuat rincian atribut yang sesuai. Cara ini sering digunakan,
karena umumnya model sistem yang akan dikembangkan basis datanya
merupakan sistem yang sangat komplek.
77..33.. CCoonnttoohh EERR__DD
Karena keterbatasan media, maka contoh ER_D yang akan diberikan di sini dimaksudkan
sebagai sarana untuk memperjelas langkah / prosedur penggambaran ER_D saja. Bukan
menunjukkan contoh yang baku dan lengkap. Contoh ER_D ini hanya merupakan bagian
/ potongan yang sangat kecil dari sebuah ER_D yang besar / lengkap, dan tentu saja
sangat komplek.
Contoh yang diberikan dalam Gambar 7.15, merupakan contoh untuk subsistem
pengolahan data akademik yang telah banyak disingggung dalam pembahasan
sebelumnya. ER_D dalam contoh ini akan digambarkan menggunakan pilihan cara 3
(gabungan), yaitu ER_D hanya memuat komponen entitas dan kerelasian antar entitas
pada bagian Mahasiswa. Atribut-atribut akan dituliskan secara terpisah. Harapannya,
contoh ER_D ini dapat dilengkapi dan dikembangkan sendiri oleh Pembaca hingga
menjadi sebuah ER_D yang lengkap.
Langkah menggambar ER_D: 1. Identifikasikan setiap entitas yang terlibat
Entitas yang terkait dengan subsistem pengolahan data akademik antara lain adalah
ditunjukkan oleh Tabel 7.2.
Tabel 7.2: Daftar Entitas
No Nama Entitas
1. Mahasiswa 2. Dosen 3. Mata Kuliah 4. Angkatan 5. Jenjang Studi 6. Program Studi 7. Jurusan 8. Fakultas 9. Golongan 10. Nilai 11. Ruang 12. Waktu 13. Wali_Mahasiswa 14. Kabupaten 15. Propinsi 16. Agama 17. Pekerjaan
2. Identifikasikan setiap atribut pada setiap entitas Macam atribut yang diperlukan untuk masing-masing entitas dalam subsistem
pengolahan data akademik antara laian adalah ditunjukkan oleh Tabel 7. 3.
Tabel 7.3: Daftar atribut pada setiap entitas
Entitas Atribut yang diperlukan Mahasiswa Kode_Angkatan, Kode_Program_Studi, Kode_Jenjang_Studi, Nomor,
Nama_Mahasiswa, Tanggal_Lahir, Alamat_Lokal, Kode_Agama, Status
Dosen NIK, Nama_Dosen, Tanggal_Lahir, Alamat_Lokal, Kode_Golongan, Kode_Agama, Tanggal_SK, Nomor_SK, No_Telepon, Status
Mata Kuliah Kode_Mata_Kuliah, Nama_Mata_Kuliah, Sks, Smt, Status Angkatan Kode_Angkatan, Tahun_Angkatan Jenjang Studi Kode_Jenjang_Studi, Nama_Jenjang_Studi Program Studi Kode_Prodi, Nama_Prodi, Tanggal_SK, Nomor_SK, Status,
Kode_Jurusan, Sks_Program_Studi Jurusan Kode_Jurusan, Nama_Jurusan, Tanggal_SK, Nomor_SK,
Kode_Fakultas Fakultas Kode_Fakultas, Nama_Fakultas,Tanggal_SK, No_SK Golongan Kode_Golongan, Nama_Golongan, Gaji_Pokok Nilai Nilai, Mutu, Keterangan Ruang Kode_Ruang, Kapasitas Waktu Kode_Waktu, Hari, Jam_Mulai, Status Wali_Mahasiswa Kode_Angkatan, Kode_Jenjang_Studi, Kode_Jurusan, Nomor,
Nama_Wali, Alamat_Asal, Kode_Pekerjaan, Kode_Kabupaten Kabupaten Kode_Kabupaten, Nama_Kabupaten, Kode_Propinsi Propinsi Kode_Propinsi, Nama_Propinsi Agama Kode_Agama, Nama_Agama Pekerjaan Kode_Pekerjaan, Nama_Pekerjaan
3. Identifikasikan setiap kerelasian yang mungkin terjadi di antara entitas Kerelasian antar entitas yang mungkin terjadi dalam subsistem pengolahan data
akademik ditunjukkan oleh Tabel 7.4.
Tabel 7.4: Daftar kerelasian antar entitas
Entitas yang berhubungan Entitas I Entitas II
Nama Kerelasian
Jenis Kerelasian
Representasi
Mahasiswa Mata_Kuliah mengikuti n-ke-n File KRS: Kode_Angkatan, Kode_Jenjang_Studi, Kode_Program_Studi, Nomor, Kode_Mata_Kuliah, Tahun_Semester
Mahasiswa mengikuti Mata_Kuliah
Nilai memperoleh 1-ke-1 File KHS: Kode_Angkatan, Kode_Jenjang_Studi, Kode_Program_Studi, Nomor, Kode_Mata_Kuliah, Tahun_Semester, Nilai
Dosen Mata_Kuliah mengajar 1-ke-n File Dosen_Mengajar: NIK, Kode_Mata_Kuliah,
Tahun_Semester, Status Dosen mengajar Mata_Kuliah
Ruang menggunakan 1-ke-n File Jadwal: Kode_Mata_Kuliah, Kode_Ruang, Tahun_semester, Kode_Waktu
Mahasiswa Angkatan mempunyai n-ke-1 Penghubung: Kode_Angkatan dalam entitas Mahasiswa
Mahasiswa Program_Studi memilih n-ke-1 Penghubung: Kode_Program_Studi dalam entitas Mahasiswa
Mahasiswa Jenjang_Studi memilih n-ke-1 Penghubung: Kode_Jenjang_Studi dalam entitas Mahasiswa
Mahasiswa Agama menganut Penghubung: Kode_Agama dalam entitas Mahasiswa
Mahasiswa Dosen_Wali mempunyai n-ke-1 File Dosen_wali: Kode_Angkatan, Kode_Jenjang_Studi, Kode_Program_Studi, Nomor, NIK
Mahasiswa Wali_Mahasiswa mempunyai 1-ke-1 File Wali_Mahassiwa: Kode_Angkatan, Kode_Jenjang_Studi, Kode_Program_Studi, Nomor, Nama_Wali, Alamat_Asal, Kode_Pekerjaan, Kode_Kabupaten
Jurusan Program_Studi membawahi 1-ke-n Penghubung: Kode_Jurusan dalam entitas Program_Studi
Fakultas Jurusan membawahi 1-ke-n Penghubung: Kode_Fakultas dalam entitas Jurusan
Dosen Golongan mempunyai n-ke-1 Penghubung: Kode_Golongan dalam entitas Dosen
Dosen Agama menganut n-ke-1 Penghubung: Kode_Agama dalam entitas Dosen
Wali Pekerjaan mempunyai n-ke-1 Penghubung: Kode_Pekerjaan dalam entitas Wali_Mahasiswa
Wali Kabupaten menempati n-ke-1 Penghubung: Kode_Kabupaten dalam entitas Wali_Mahasiswa
Kabupaten Propinsi menempati n-ke-1 Penghubung: Kode_Propinsi dalam entitas Kabupaten
4. Gambarkan ER_D Hasil ER_D untuk contoh subsistem pengolahan data akademik ditunjukkan oleh Gambar
7. 16.
Gambar 7.16: Contoh ER_D
5. Cek ER_D ER_D pada Gambar 7.16 telah memuat seluruh, entitas dan kerelasian yang
tercantum dalam Tabel 7.3 dan Tabel 7.4. Sedangkan rincian atribut yang diperlukan
untuk masing-masing adalah ditunjukkan oleh Tabel 7.3 (pada kolom Atribut yang
diperlukan).
77..44.. KKeelleebbiihhaann ddaann KKeelleemmaahhaann EERR__DD
Jika dapat diterapkan dengan benar / tepat, maka penggunaan ER_D dalam pemodelan
data akan memberikan keuntungan, bagi perancang maupun pemakai antara lain:
Menganut
Menempati
Mata_Kuliah Mengikuti
Dosen
Golongan
Mempunyai
Mengajar
MahasiswAngkatan
Jenjang Studi
Program Studi
Jurusan
Fakultas
Mempunyai
Mempunyai
Mempunyai
Membawah
Membawah
Wali_Mahasiswa
Pekerjaan
Mempunyai
Mempunyai Agama
Menganut
Menempati
Kabupaten
Propinsi
Menempati
Nilai
Memperol
Waktu Menempati Menggunaka
Ruang
1. Memudahkan perancang dalam hal menganalisis sistem yang akan dikembangkan
2. Memudahkan perancang saat merancang basis data
3. Rancangan basis data yang dikembangkan berdasarkan ER_D umumnya telah
berada dalam bentuk optimal
4. Dalam banyak kesempatan, penggunaan simbol-simbol grafis (termasuk ER_D)
akan lebih mudah dipahami oleh para pemakai dibandingkan bentuk naratif
5. Dengan menggunakan ER_D, pemakai umumnya akan mudah memahami sistem
dan basis data yang dirancang oleh perancang
Kelemahan ER_D antara lain adalah:
1. Kebutuhan media yang sangat luas
2. Seringkali ER_D tampil sangat ruwet
1
BBAABB VVIIIIII.. SSEEMMAANNTTIICC MMOODDEELL
Semantic model merupakan suatu model data yang dikembangkan berdasarkan obyek.
Semantic model digunakan untuk menjelaskan hubungan antar data dalam basis data
kepada pemakai secara logik. Semantic model didasarkan pada suatu persepsi bahwa
real world terdiri atas obyek-obyek dasar yang mempunyai hubungan / kerelasian antar
obyek-obyek dasar tersebut. Semantic model digambarkan dalam bentuk diagram yang
disebut diagram Semantic (Semantic_Diagram).
Semantic model hampir sama dengan entity relationship model perbedaaannya adalah
kerelasian antar obyek dasar tidak dinyatakan dengan simbol tetapi secara semantik,
yaitu menggunakan kata-kata (semantic).
88..11.. KKoommppoonneenn DDiiaaggrraamm SSeemmaannttiicc
Sebagaimana dalam ER_D, diagram semantic tersusun atas tiga komponen, yaitu entitas,
atribut dan kerelasian antar entitas. Perbedaannya adalah dalam hal penggunaan simbol,
terutama kerelasian antar entitas.
88..11..11.. EEnnttiittaass ((EEnnttiittyy))
1. Entitas Entitas adalah obyek-obyek dasar yang terkait di dalam sistem, dapat berupa orang,
benda, atau hal yang keterangannya perlu disimpan di dalam basis data. Dalam diagram
semantic, entitas digambarkan dengan aturan sebagai berikut:
1. Entitas dinyatakan dengan simbol persegi panjang atau ellips
2. Nama entitas dituliskan di dalam simbol persegi panjang
3. Nama entitas berupa : kata benda, tunggal
4. Nama entitas sedapat mungkin menggunakan nama yang mudah dipahami dan
dapat menyatakan maknanya dengan jelas
2
Penggunaan tanda garis bawah (hypen / underscore), pemedekan, dan singkatan juga
lazim digunakan untuk memberikan nama entitas sebagimana dalam ER_D. Gambar 8.1
menunjukkan contoh-contoh entitas dalam semantic model:
Obyek Dasar Simbol Entitas (Pilihan 1)
Simbol Entitas (Pilihan 2)
Mahasiswa Mahasiswa atau
Dosen Dosen atau
Ruang Ruang atau
Propinsi Propinsi atau
Agama Agama atau
Mahasiswa
Dosen
Ruang
Propinsi
Agama
Gambar 8.1 : Contoh-contoh entitas
Konsep isian entitas, himpunan entitas, entitas reguler, entitas dependen, entitas super
type dan entitas sub type yang dikenal dalam model ER, juga berlaku dalam semantic
model.
88..11..22.. AAttrriibbuutt ((AAttttrriibbuuttee))
Dalam semantic model, atribut atau properti (property) merupakan keterangan-keterangan
yang terkait pada sebuah entitas yang perlu disimpan sebagai basis data digambarkan
dengan aturan sebagai berikut:
1. Atribut dinyatakan dengan simbol ellips
2. Nama atribut dituliskan di dalam simbol ellips
3. Nama atribut berupa : kata benda, tunggal
4. Nama atribut sedapat mungkin menggunakan nama yang mudah dipahami dan
dapat menyatakan maknanya dengan jelas
3
5. Atribut dihubungkan dengan entitas yang bersesuaian dengan menggunakan
sebuah garis (seyogyanya menggunakan garis lurus, namun dalam kondisi yang
tidak memungkinkan dapat tidak menggunakan garis lurus)
Sebagai contoh, atribut pada entitas Mahasiswa ditunjukkan oleh Gambar 8.2 atau
Gambar 8.3.
Mahasiswa
Kode_Angkatan
Kode_Program_Studi
Kode_Jenjang_Studi
Kode_Jurusan
Nomor
Nama_Mahasiswa
Tanggal_lahir
Alamat_Lokal
Kode_Agama
Status
Gambar 8.2: Contoh atribut pada entitas Mahasiswa (pilihan simbol 1)
Kode_Angkatan
Kode_Program_Studi
Kode_Jenjang_Studi
Kode_Jurusan
Nomor
Nama_Mahasiswa
Tanggal_lahir
Alamat_Lokal
Kode_Agama
Status
Mahasiswa
Gambar 8.3: Contoh atribut pada entitas Mahasiswa (pilihan simbol 2)
Konsep atribut sederhana (simple attribute) dan atribut komposit (composite attribute)
yang dikenal dalam model ER juga tetap berlaku pada semantic model.
4
88..11..33.. KKeerreellaassiiaann AAnnttaarr EEnnttiittaass ((RReellaattiioonnsshhiipp))
Kerelasian antar entitas yang menyatakan kejadian atau transaksi yang terjadi di antara
dua buah entitas yang keterangannya perlu disimpan dalam basis data, dalam semantic
model digambarkan dengan aturan sebagai berikut:
1. Kerelasian dinyatakan dengan simbol garis dengan sebuah mata panah
2. Nama kerelasian dituliskan di samping garis kerelasian
3. Kerelasian menghubungkan dua entitas
4. Nama kerelasian berupa : kata kerja aktif (diawali dengan awalan me), tunggal
5. Nama kerelasian sedapat mungkin menggunakan nama yang mudah dipahami
dan dapat menyatakan maknanya dengan jelas
Kerelasian antar entitas dalam semantic model, juga dikelompokkan dalam tiga jenis,
yaitu:
1. Kerelasian jenis 1-ke-1 / satu ke satu (one to one)
2. Kerelasian jenis n-ke-1 / banyak ke satu (many to one) atau 1-ke-n / satu ke banyak
(one to many)
3. Kerelasian jenis n-ke-n / banyak ke banyak (many to many)
Sebagai contoh, Gambar 8.4 menunjukkan kerelasian antara entitas Mahasiswa dan
Mata_Kuliah dalam semantic model untuk pilihan simbol 1 (menggunakan persegi
panjang) dan Gambar 8.5 untuk pilihan simbol 2 (menggunakan ellips).
Mata_Kuliah Mahasiswa mengikuti
Gambar 8.4: Contoh kerelasian antara entitas Mahasiswa dan Mata_Kuliah (pilihan 1)
mengikuti Mata_Kuliah Mahasiswa
Gambar 8.5: Contoh kerelasian antara entitas Mahasiswa dan Mata_Kuliah (pilihan 2)
Konsep tentang kkeerreellaassiiaann rreekkuurrssiiff ddaann keerreellaassiiaann aassoossiiaattiiff yyaanngg ddiikkeennaall ddaallaamm mmooddeell
EERR,, jjuuggaa ddaappaatt ddiigguunnaakkaann ddii ddaallaammsseemmaannttiicc mmooddeell..
5
88..22.. MMeennggggaammbbaarr DDiiaaggrraamm SSeemmaannttiicc
Untuk menggambarkan Diagram Semantic (Semantic diagram) secara lengkap, dapat
dilakukan dengan langkah sebagai berikut:
1. Identifikasikan setiap entitas yang terlibat
2. Identifikasikan setiap atribut pada setiap entitas
3. Identifikasikan setiap kerelasian berikut jenisnya yang terjadi di antara entitas
4. Gambarkan simbol-simbol entitas, atribut, dan kerelasian antar entitas sedemikian
sehingga simbol kerelasian dapat digambarkan dengan jelas / tidak saling
bertabrakan
5. Cek diagram semantic yang terbentuk, dalam hal:
a. Kelengkapan entitas
b. Kelengkapan atribut
c. Kelengkapan kerelasian antar entitas
d. Jenis kerelasian antar entitas
88..33.. CCoonnttoohh DDiiaaggrraamm SSeemmaannttiicc
Dengan tanpa melibatkan komponen atribut pada setiap entitas, maka Gambar 8.6
menunjukkan contoh diagram semantic untuk subsistem pengolahan data akademik
sebagaimana contoh dalam ER_D sebelumnya.
6
Ruang Waktu
mempunyai
memb
awah
i
meng
anut
memp
unya
i me
ngaja
r
memb
awah
i
meng
anut
memp
unya
i
memp
unya
i
menempati
mengikuti
menggunakan
menempati
Gambar 8.6: Contoh diagram semantic
88..44.. KKeelleebbiihhaann ddaann KKeelleemmaahhaann DDiiaaggrraamm SSeemmaannttiicc
Jika dapat diterapkan dengan benar / tepat, maka penggunaan diagram semantic dalam
pemodelan data akan memberikan keuntungan yang sama dengan ER_D, baik bagi
perancang maupun pemakai. Kelemahan diagram semantic antara lain adalah:
1. Kebutuhan media yang sangat luas
2. Seringkali semantic tampil sangat ruwet
3. Tidak dapat menunjukkan jenis kerelasian antar entitas
Mahasiswa Angkatan
Jenjang Studi
Program Studi
mempunyai
memilih
memilih
memperoleh
Mata_Kuliah
Nilai
Dosen
Wali_Mahasiswa
Agama Jurusan
Golongan Pekerjaan
Kabupaten Propinsi
Fakultas
1
BBAABB IIXX.. HHIIEERRAARRCCHHYYCCAALL MMOODDEELL
Model hirarkhi (hierarchycal model) merupakan salah satu model data yang didasarkan
pada record (Record Based Data Model / RBDM). Model ini digunakan untuk
menjelaskan kepada pemakai tentang hubungan logik antar data dalam basis data
dalam bentuk hubungan bertingkat.
Hierarchycal model sering pula disebut sebagai struktur pohon (tree structure) atau
pohon saja (tree), karena bentuknya dapat dianalogikan sebagai sebuah pohon terbalik,
yaitu terdiri atas bagian akar, batang, dahan, ranting, dan daun. Elemen-elemen pohon
dalam model data hirarkhi disebut sebagai node. Node pada kenyataannya dapat
berupa rinci data, agregat data, atau record. Level paling tinggi dalam suatu hirarki
harus hanya terdapat satu node, dan disebut sebagai root. Suatu node pada level yang
lebih rendah hanya diijinkan mempunyai satu relasi dengan node pada tingkat yang
lebih tinggi, yang disebut sebagai parent. Sedangkan kebalikannya, parent dapat
mempunyai lebih dari satu child, yaitu node-node yang mempunyai level lebih rendah
dan dihubungkandengan parent. Suatu node yang tidak mempunyai child disebut
sebagai leaves. Jadi pada hierarchycal model tidak ada child yang mempunyai lebih dari
satu parent. Struktur pohon dapat digambarkan seperti ditunjukkan pada Gambar 9.1.
A
D B C
E F
Gambar 9.1. Struktur model hirarkhi
G K L H I J
PO Q SRM N
2
Dalam Gambar 9.1, yang disebut node adalah A, B, C, dst hingga S. Root dalam pohon
tersebut adalah A. Leaves terdiri atas node E, G, I, K, L, M, N, O, P, Q, R, dan S. Node
B adalah parent terhadap node E, F, dan G, sebaliknya node E, F, dan G adalah child
terhadap node B. Node F adalah parent terhadap node M dan N, sebaliknya, M dan N
adalah child terhadap node F, dan seterusnya.
Terdapat tiga kemungkinan struktur pohon yang dapat dibentuk, yaitu:
1. Pohon tidak setimbang (unbalanced tree), yaitu jika node-node dalam pohon
mempunyai jumlah cabang yang berbeda-beda
2. Pohon setimbang (balanced tree), yaitu jika setiap node seluruh level (kecuali
leaves) mempunyai jumlah cabang yang sama
3. Pohon biner (binary tree), yaitu jika setiap node pada seluruh level dalam pohon
(kecuali leaves) mempunyai dua cabang
Gambar 9.1 menunjukkan contoh struktur pohon tidak setimbang, sedangkan pohon
setimbang ditunjukkan oleh Gambar 9.2, dan pohon biner ditunjukkan oleh Gambar 9.3.
Gambar 9.2: Struktur pohon setimbang dalam model hirarkhi
A
B C D
E G F L K MIH J
A
B C
D E F G
Gambar 9.3: Struktur pohon setimbang dalam model hirarkhi
3
Model hirarkhi digunakan untuk menggambarkan jenis kerelasian 1-ke-n dalam
hubungan antar data. Berikut diberikan contoh model hirarkhi untuk menggambarkan
hubungan antar data dalam sebuah universitas. Sebuah universitas dapat terdiri atas
beberapa fakultas, fakultas dalam universitas dapat memiliki beberapa jurusan, dan
sebuah jurusan dapat memiliki beberapa program studi (prodi). Hubungan antara
universitas dan fakultas, fakultas dan jurusan, jurusan dan prodi merupakan hubungan
jenis 1-ke-n. Dengan demikian, hubungan tersebut dapat digambarkan sebagai sebuah
pohon. Universitas menempati root, fakultas sebagai child terhadap universitas
sekaligus parent terhadap jurusan, jurusan sebagai child terhadap fakultas dan
sekaligus parent terhadap prodi, dan prodi sebagai child terhadap jurusan dan sekaligus
menempati posisi leaves. Hubungan ini digambarkan pada Gambar 9.4.
Universitas A
Fakultas B Fakultas C Fakultas D Fakultas E Fakultas F
Jurusan G Jurusan H Jurusan I
Prodi G Prodi H Prodi I
Gambar 9.4. Contoh model hirarkhi (contoh 1)
Model hirarkhi pada Gambar 9.4 sebenarnya adalah menunjukkan hubungan antar
sekumpulan record fakultas, jurusan, dan prodi. Setiap record tersebut tersusun atas
atribut-atribut yang bersesuaian. Hubungan antar record tersebut dapat ditunjukkan
sebagai diagram schema seperti ditunjukkan pada Gambar 9.5.
4
Fakultas Kode_Fakultas Nama_Fakultas Tanggal_SK No_SK
Jurusan Kode_Jurusan Nama_Jurusan Tanggal_SK No_SK Kode_Fakultas
Prodi Kode_Prodi Nama_Prodi Tanggal_SK Nomor_SK Status Kode_Jurusan Sks_Prodi
Gambar 9.5. Diagram schema kerelasian antar record (contoh 2)
Berikut diberikan contoh kedua tentang hirarkhi model untuk menggambarkan hubungan
antar data dalam sebuah perusahaan. Sebuah perusahaan memiliki beberapa
departemen. Setiap departemen memiliki beberapa divisi. Dan setiap divisi dapat
memiliki beberapa sub divisi. Hubungan antara data departemen, divisi, dan subdivisi
tersebut dapat digambarkan sebagai hubungan bertingkat dalam model hirarkhi, yaitu
ditunjukkan pada Gamabr 9.6.
Perusahaan A
Departemen B
Divisi E Divisi F Divisi G
Sub Divisi H
Departemen C Departemen D
Sub Divisi I Sub Divisi J
Gambar 9.6. Contoh model hirarkhi (contoh 2)
Model hirarkhi pada Gambar 9.6 sebenarnya adalah menunjukkan hubungan antar
sekumpulan record departemen, divisi, dan sub divisi. Setiap record tersebut tersusun
5
atas atribut-atribut yang bersesuaian. Hubungan antar record tersebut dapat ditunjukkan
sebagai diagram schema seperti ditunjukkan pada Gambar 9.7.
Departemen Kode_Departemen Nama_Departemen Manajer
Divisi Kode_Divisi Nama_Divisi Kepala_Divisi Kode_Departemen
Sub_Divisi Kode_Sub_Divisi Nama_Sub_Divisi Kepala_Sub_Divisi Kode_Divisi
Gambar 9.7. Diagram schema kerelasian antar record (contoh 2)
Masih banyak sebenarnya contoh-contoh hubungan antar data yang dapat digambarkan
dengan model hirarkhi. Petunjuk praktis untuk mencari contoh hubungan yang dapat
digambarkan dalam model ini adalah dengan mencari hubungan antar data yang
memiliki jenis kerelasian 1-ke-n.
Secara teknis, model hirarkhi akan diimplementasikan sebagai virtual record yang
memuat data dan pointer penunjuk ke alamat fisik dalam media penyimpan.
Pemeliharaan data dalam model hirarkhi memerlukan metoda yang fleksibel untuk dapat
mengubah dan memperbaharui record dalam basis data. Setiap proses pengubahan
akan dilakukan dengan cara menghapus data versi sebelumnya dan menyisipkan data
versi baru (hasil pengubahan). Proses penyisipan dan penghapusan akan bergantung
pada bagaimana cara yang digunakan pada pointer untuk menyusun virtual record.
Umumnya pointer untuk model hirarkhi ini memuat dua informasi, yaitu:
1. Alamat pertama blok yang digunakan untuk record data
2. Nilai atribut kunci record selanjutnya
Model hirarkhi memiliki fleksibilitas yang rendah, utamanya berkaitan dengan
pemeliharaan basis data. Tetapi model ini memiliki unjuk kerja yang sangat baik
berkaitan dengan akses data dari basis data yang tersimpan dalam berkas.
1
BBAABB XX.. NNEETTWWOORRKK MMOODDEELL
Model jaringan (network model) sering pula disebut sebagai plex structure. Seperti
halnya dengan hierarchycal model, model jaringan merupakan salah satu model data
yang didasarkan pada record (Record Based Data Model / RBDM). Model jaringan
dapat dideskripsikan ke dalam struktur hubungan bertingkat yang tersusun atas
komponen berupa node-node. Teknik leveling dan penyebutan node pada model
jaringan sama dengan teknik dan penyebutan dalam model hirarkhi.
Berbeda dengan model hirarkhi yang hanya menggunakan sebuah pointer, model
jaringan menambahkan sebuah pointer untuk meningkatkan fleksibilitas model hirarkhi.
Artinya model jaringan menggunakan dua buah pointer, satu digunakan untuk
menghubungkan dengan record sebelumnya (previous = P), dan yang lain digunakan
untuk menghubungkan dengan record selanjutnya (next = N). Secara umum, model
jaringan memuat sekumpulan node yang memungkinkan dihubungkan dengan node
lainnya. Akibatnya, dalam model jaringan sebuah node child dapat mempunyai lebih dari
satu parent. Hal ini yang membedakan antara model hirarkhi dan model jaringan.
Sebagai contoh yang dapat digunakan untuk menunjukkan model jaringan adalah
hubungan antara mahasiswa dan mata kuliah. Banyak (lebih dari satu) mahasiwa dapat
mengikuti banyak (lebih dari satu) mata kuliah, sehingga hubungan tersebut termasuk
jenis kerelasian n-ke-n. Hubungan tersebut dapat ditunjukkan seperti ditampilkan pada
Gambar 10.1.
Mahasiswa A Mahasiswa B Mahasiswa C
Matakuliah 1 Matakuliah 2 Matakuliah 3
Gambar 10.1. Contoh model jaringan
2
Kerelasian antara data mahasiswa dan mata kuliah yang diikuti pada Gambar 10.1
dapat digambarkan dalam skema kerelasian seperti ditampilkan pada Gambar 10.2.
Mahasiswa NIM Nama_Mahasiswa Tanggal_Lahir Alamat_Lokal Status KRS NIM Kode_Mata_Kuliah Tahun_Smt Mata_Kuliah Kode_Mata_Kuliah Nama_Mata_Kuliah Sks Smt Status
Gambar 10.2: Skema kerelasian antara data Mahasiswa dan Mata_Kuliah
Implementasi teknis penyimpanan data model jaringan adalah menggunakan struktur
data linked list. Hubungan antara data mahasiswa dan mata kuliah - mata kuliah yang
diikuti tersebut diorganisasikan dengan cara menghubungkannya menggunakan pointer
P dan N. Gambaran model jaringan yang menunjukkan hubungan antara data
mahasiswa A dan mata kuliah 1, 2, dan 3 yang diikutinya dapat ditunjukkan
sebagaimana ditampilkan pada Gambar 10.3.
N
N
N
P
P
P
Mata Kuliah 1
Mata Kuliah 3
Mata Kuliah 2
Mahasiswa A
Gambar 10.3: Penggunaan pointer Next dan Previous untuk menghubungkan
antara data mahasiswa A dan mata kuliah yang diikutinya dalam model jaringan
3
Jika Gambar 10.3 ditambah dengan data mahasiswa C dan mata kuliah yang diikutinya,
maka hasilnya ditampilkan pada Gambar 10.4.
NA
NA
NA
PA
PA
PA
NC
PC
NC
Mata Kuliah 1
Mata Kuliah 3
Mata Kuliah 2
Mahasiswa A Mahasiswa C
PC
Gambar 10.4: Penggunaan pointer Next dan Previous untuk menghubungkan antara data mahasiswa A dan C dan mata kuliah yang diikutinya dalam model jaringan
Tentu saja Gambar 10.4 masih perlu ditambah dengan mahasiswa C yang mengikuti
mata kuliah 1, 2, dan 3. Dan kenyataannya, jumlah mahasiswa pada suatu universitas
jumlahnya bisa mencapai ribuan orang, dan jumlah mata kuliah yang diikuti juga bisa
mencapai ratusan. Tentu tidak mungkin untuk dapat menggambarkannya secara
keseluruhan.
1
BBAABB XXII.. RREELLAATTIIOONNAALL DDAATTAA BBAASSEE MMOODDEELL // RRDDBBMM
Model basis data relasional (Relatinoa l Data Base Model / RDBM) sering juga
disebut sebagai model relasional atau basis data relasional atau sering ditulis
sebagai RDBM saja. Model basis data ini mulai diperkenalkan pertama kali oleh
E.F. Codd pada tahun 1970. Model basis data menunjukan / suatu cara /
mekanisme yang digunakan untuk mengelola / mengorganisasi data secara fisik
dalam memori sekunder yang akan berdampak pula pada bagaimana kita
mengelompokkan dan membentuk keseluruhan data yang terkait dalam sistem
yang sedang ditinjau.
Sampai saat ini model basis data RDBM masih merupakan salah satu model
yang paling banyak diterapkan / digunakan. Tentu saja ada model-model basis
data yang lain, seperti model basis data hirarki dan model basis data jaringan
(network). Hal ini karena konsep dan terminologi yang digunakan dalam model ini
hampir sama dengan kondisi sesungguhnya yang dihadapi oleh para pemakai,
sehingga memudahkan para pemakai dalam memahaminya. Perangkat lunak
pengelolaan basis data yang tersedia di pasaran pun banyak yang
dikembangkan berdasarkan model ini.
Sebagai salah satu model data, RDBM menjelaskan kepada pemakai tentang
hubungan logik antar data dalam basis data dengan merepresentasikannya ke
dalam bentuk relasi-relasi berupa tabel mendatar (flat file) yang terdiri atas
sejumlah baris yang menunjukkan record dan kolom yang menunjukkan atribut
tertentu. Relasi dirancang sedemikian rupa sehingga dapat menghilangkan
kerangkapan data yang tidak berguna. Dalam sebuah basis data, kerelasian
antar relasi satu dengan yang lainnya ditunjukkan menggunakan Foreign Key /
FK atau relasi bertipe transaksi.
Penggunaan model data RDBM dalam perancangan basis data, memerlukan
pemahaman konsep lanjutan, yaitu yang dikenal sebagai konsep normalisasi.
2
Untuk dapat menerapkan konsep normalisasi tersebut diperlukan pemahaman
yang baik tentang konsep-konsep berikut:
1. Definisi basis data,
2. Kekangan dalam basis data,
3. Terminologi RDBM,
4. Kunci relasi,
5. Kerelasian antar relasi,
6. Ketergantungan antar nilai rinci data,
7. Karakteristik relasi,
8. Penyimpangan dalam modifikasi, dan
9. Bentuk-bentuk normal
1111..11.. TTeerrmmiinnoollooggii RRDDBBMM
Sebagai sebuah model data, RDBM memiliki terminologi tersendiri / khusus yang
berbeda dengan model lainnya, yaitu berkaitan dengan penggunaan istilah-istilah
yang bersifat khusus dalam model RDBM. Istilah-istilah dalam terminologi RDBM
ini perlu dipahami secara benar sebelum seseorang menggunakan paket-paket
DBMS. Hal ini diperlukan untuk menghindari terjadinya kerancuan saat
menggunakan paket DBMS, karena masing-masing DBMS bisa jadi memiliki
terminologi tersendiri, sekalipun tetap didasarkan pada konsep dasar yang sama.
Sebagai contoh, dalam MS-Access ketika kita merancang sebuah struktur tabel /
relasi, maka hasilnya disebut sebagai basis data (berekstensi .MDB). Padahal
secara konsep, bahwa yang disebut basis data adalah sekumpulan data
terhubung yang berarti memuat banyak tabel / relasi yang saling berkerelasian,
bukan hanya sebuah tabel / relasi. Kumpulan data terhubung tersebut berada
dalam lingkup sebuah sistem / organisasi secara keseluruhan, bukan hanya
kumpulan data dalam sebuah subsistem saja. Dalam MS-Access juga dikenal
adanya secondary key, padahal secara konsep tidak dikenal istilah tersebut.
Masih dalam MS-Access, terdapat pilihan apakah kita mau mendefinisikan
primary key / PK atau tidak atau ingin dibuat otomatis (generate) oleh MS-Access
dengan nama atribut ID. Padahal secara konsep, PK harus ada dalam setiap
3
relasi untuk menjamin bahwa setiap record dalam relasi dapat diakses berdasar
kunci yang unik, yaitu nilai dalam atribut yang digunakan sebagai PK.
Beberapa istilah yang disepakati dalam RDBM, antara lain ditunjukkan pada
Tabel 11.1.
Tabel 11.1: Istilah-istilah dalam terminologi RDBM
Istilah formal Istilah non formal
Keterangan
Elemen data (data element), rinci data (data item), entri (entry)
Atribut (attribute)
Kolom, medan data, medan, field
Sekelompok rinci data yang mempunyai arti. Atribut memiliki tipe, ukuran, dan domain yang sama
Record / tuple Baris / rekaman Sekumpulan atribut yang mempunyai hubungan terhadap obyek tertentu
Relasi (relation)
Tabel Sekumpulan record yang sejenis secara relasi
Derajat (degree)
Aritas (arity) Jumlah atribut dalam sebuah relasi
Kardinalitas (cardinality) Jumlah record dalam sebuah relasi Kerelasian (relationship) Hubungan antar relasi Unary relation Relasi yang tersusun oleh satu atribut Binary relation Relasi yang tersusun oleh dua atribut Ternary relation Relasi yang tersusun oleh tiga atribut n-ary relation Relasi yang tersusun oleh n atribut Key Satu atau gabungan atribut bersifat unik yang
digunakan untuk mengidentifikasi setiap record dalam relasi
Candidate Key / CK Satu atau gabungan minimal atribut bersifat unik yang dapat digunakan untuk mengidentifikasi setiap record dalam relasi
Primary Key / PK Bagian dari CK yang dipilih / digunakan sebagai kunci utama dalam relasi
Alternate Key / AK Bagian dari CK yang tidak dipilih / digunakan sebagai kunci utama dalam relasi
Foreign Key / FK
Kunci tamu / kunci asing
Satu atau gabungan sembarang atribut yang menjadi PK dalam relasi lain yang mempunyai hubungan secara logik
4
Domain Himpunan nilai yang memenuhi syarat Schema Deskripsi hubungan logik secara global,
termasuk di dalamnya nama dan deskripsi tipe dan ukuran atribut dan hubungan logik antar relasi basis data dalam lingkup sebuah sistem
Subschema Deskripsi hubungan logik secara terpisah, termasuk di dalamnya nama dan deskripsi tipe dan ukuran atribut dan hubungan logik antar relasi basis data dalam lingkup sebuah sub sistem aplikasi basis data
Untuk memberikan pemahaman yang lebih jelas tentang beberapa istilah dalam
terminologi RDBM tersebut, akan diberikan sebuah contoh relasi dengan nama
Mata_Kuliah sebagaimana ditunjukkan pada Tabel 11.2.
Tabel 11.2: Relasi Mata_Kuliah
Kode_Mata_Kuliah Nama_Mata_Kuliah Sks Smt Status MK-1001 Pemrograman I 2 1 W MK-2002 Pemrograman II 2 2 W MK-3003 Pemrograman III 2 3 W MK-4004 Pemrograman IV 2 4 W MK-5005 Pemrograman V 2 5 W
MK-1001P Praktikum Pemrograman I 1 1 W MK-2002P Praktikum Pemrograman II 1 2 W MK-3003P Praktikum Pemrograman III 1 3 W MK-4004P Praktikum Pemrograman IV 1 4 W MK-5005P Praktikum Pemrograman V 1 5 W MK-5006 Pemrograman Visual 2 6 W MK-7007 Pemrograman Berorientasi Obyek 2 7 W MK-8008 Pemrograman Internet 3 8 P
Dalam contoh Tabel 11.2, maka yang disebut,
Atribut : Kode_Mata_Kuliah, Nama_Mata_Kuliah, Sks, Smt, Status
Record :
Record #1 : MK-1001, Pemrograman I, 2, 1, W
Record #2 : MK-2002, Pemrograman II, 2, 1, W
Record #3 : MK-3003, Pemrograman III, 2, 1, W
Record #4 : MK-4004, Pemrograman IV, 2, 1, W
Record #5 : MK-5005, Pemrograman V, 2, 1, W
Record #6 : MK-1001P, Praktikum Pemrograman I, 2, 1, W
Record #7 : MK-2002P, Praktikum Pemrograman III, 2, 1, W
5
Record #8 : MK-3003P, Praktikum Pemrograman III, 2, 1, W
Record #9 : MK-404P, Praktikum Pemrograman IV, 2, 1, W
Record #10: MK-5005P, Praktikum Pemrograman V, 2, 1, W
Record #11: MK-6006, Pemrograman Visual, 2, 6, W
Record #12: MK-7007, Pemrograman berorientasi Obyek, 2, 7, W
Record #13: MK-8008, Pemrograman Internet, 3, 8, P
Relasi : Mata_Kuliah
Derajat : 5 (=5-ary)
Kardinalitas : 13
Candidate Key / CK : Kode_Mata_Kuliah dan Nama_Mata_Kuliah
Primary Key : Kode_Mata_Kuliah
Alternate Key : Nama_Mata_Kuliah
Foreign Key / FK: -
Domain :
Pada atribut Kode_Mata_Kuliah: MK-1001, MK-2002, MK-3003, MK-4004,
MK-5005, MK-1001P, MK-2002P, MK-3003P, MK-4004P, MK-
5005P, MK-6006, MK-7007, MK-8008
Pada atribut Nama_Mata_Kuliah: Pemrograman I, Pemrograman II,
Pemrograman III, Pemrograman IV, Praktikum Pemrograman I,
Praktikum Pemrograman II, Praktikum Pemrograman III,
Praktikum Pemrograman IV, Praktikum Pemrograman V,
Pemrograman Visual, Pemrograman Berorientasi Obyek,
Pemrograman Internet
Pada atribut Sks : 1, 2, 3
Pada atribut Smt : 1, 2, 3, 4, 5, 6,7,8
Pada atribut Status : W, P
Schema : (Char[8], Char[50], Num[1], Num[1], Char[1])
Subschema : (Char[8], Char[50], Num[1], Num[1], Char[1])
Catatan:
⇒ Char[8] dimaksudkan bahwa nilai-nilai elemen data dalam atribut Kode_Mata
Kuliah adalah berupa data bertipe Character dengan ukuran panjang
maksimal 8 character
6
⇒ Char[50] dimaksudkan bahwa nilai-nilai elemen data dalam atribut
Nama_Mata Kuliah adalah berupa data bertipe Character dengan ukuran
panjang maksimal 50 character. Angka 50 merupakan nilai perkiraan yang
diperoleh dengan asumsi merupakan ukuran maksimal, tidak ada nama mata
kuliah yang panjangnya melebihi 50 character
⇒ Num[1] dimaksudkan bahwa nilai-nilai elemen data dalam atribut Sks dan
Smt adalah berupa data bertipe Numeric dengan ukuran panjang 1 digit
⇒ Char[1] dimaksudkan bahwa nilai-nilai elemen data dalam atribut Status
adalah berupa data bertipe Character dengan ukuran 1 character, dimana W
digunakan sebagai kode untuk menyatakan status mata kuliah Wajib dan P
untuk menyatakan status mata kuliah Pilihan
⇒ Dalam paket-paket DBMS yang tersedia di pasaran, tipe dan ukuran data
yang disediakan mungkin sekali berbeda dengan contoh di atas, sehingga
kita perlu menyesuaikan
1111..22.. KKaarraakktteerriissttiikk RReellaassii
Relasi dalam model data RDBM mempunyai beberapa karakteristik yang harus
dipenuhi. Karakteristik yang dimaksud adalah sebagai berikut:
1. Semua elemen data / entri pada suatu record dan atribut tertentu harus
mempunyai nilai tunggal (single value), bukan suatu larik atau grup
perulangan dan harus berupa nilai yang tidak dapat dibagi lagi (atomic value)
2. Semua elemen data / entri pada suatu atribut tertentu dalam sebuah relasi
harus mempunyai tipe dan ukuran yang sama
3. Masing-masing atribut dalam sebuah relasi mempunyai nama yang unik
(sekalipun tidak disarankan, nama-nama atribut pada relasi yang berbeda
diijinkan memiliki nama-nama atribut yang sama dengan nama atribut dalam
relasi lain)
4. Pada sebuah relasi tidak ada dua record data yang identik
Karakteristik dalam relasi sangat penting, karena akan menjadi dasar bagi
penyusunan struktur relasi yang akan digunakan sebelum penyimpanan data
dapat dilakukan.
7
Dalam karakteristik relasi yang pertama, istilah single value dimaksudkan bahwa
nilai-nilai aktual elemen data dalam sebuah relasi harus merupakan nilai yang
bersifat tunggal, bukan merupakan grup perulangan. Untuk memudahkan dalam
membedakan di antara keduanya, akan diberikan sebuah contoh relasi yang
memuat grup perulangan (non single value), yaitu relasi Mahasiswa yang
ditunjukkan pada Tabel 11.3.
Tabel 11.3: Relasi Mahasiswa
NIM Nama_Mahasiwa Kode_MK_1 Sks_1 Kode_MK_2 Sks_2
02050001 Rita MK-001 2 MK-002 2 02050002 Rina MK-001 2 MK-003 2 02050003 Rini MK-007 2 MK-008 3
non single value
Dalam Tabel 11.3, grup elemen data Kode_MK_2 dan Sks_2 merupakan grup
perulangan dari grup elemen data Kode_MK_1 dan Sks_1. Nilai-nilai elemen
data pada atribut Kode_MK_2 dan Sks_2 mempunyai tipe dan ukuran yang sama
dengan nilai-nilai elemen data pada atribut Kode_MK_1 dan Sks_1, misal Char[8]
untuk Kode_Mk dan Num[1] untuk Sks.
Grup perulangan seperti Tabel 11.3. tidak diijinkan terjadi / muncul dalam
rancangan sebuah relasi. Alasan utamanya adalah akan mengakibatkan
kesulitan dalam pengolahan data selanjutnya. Alasan lain adalah ada
kemungkinan grup elemen data tersebut harus diulang-ulang hingga jumlah yang
sangat besar, sedangkan kemungkinan besar tidak semuanya akan terisi.
Mahasiswa sebuah universitas, dapat terdiri atas mahasiwa yang mengikuti
pendidikan jenjang sarjana dan jenjang Diploma III. Mahasiwa jenjang Sarjana
misalnya, harus menyelesaikan minimal 60 mata kuliah untuk dapat dinyatakan
lulus, maka grup perulangan tersebut harus diulang sebanyak 60 kali. Padahal
bagi mahasiswa Diploma III, mungkin hanya membutuhkan sekitar 30 mata
kuliah saja, berarti ada 30 grup perulangan (=60 kolom) yang sia-sia.
8
Permasalahannya adalah bagaimana mengatasi hal tersebut agar dapat
memenuhi karakteristik basis data model RDBM. Untuk contoh kasus dalam
Tabel 11.3, maka relasi tersebut perlu diubah menjadi relasi baru dengan struktur
seperti ditampilkan pada Tabel 11.4, yang diberi nama Mahasiswa_1. Dalam
relasi Mahasiswa_1, maka grup perulangan sudah tidak terjadi / muncul lagi.
Tabel 11.4: Relasi Mahasiswa_1
NIM Nama_Mahasiwa Kode_MK Sks
02050001 Rita MK-001 2 02050001 Rita MK-002 2 02050002 Rina MK-001 2 02050002 Rina MK-003 2 02050003 Rini MK-007 2 02050003 Rini MK-008 3
Tetapi relasi dalam Tabel 11.4, ternyata masih memiliki permasalahan, yaitu
terjadi kerangkapan data dalam relasi Mahsiswa_1. Setiap kali ingin dicatat mata
kuliah yang diikuti oleh mahasiswa, harus selalu dituliskan kembali nama
mahasiswanya. Dalam contoh ini, nama Rita, Rina, dan Rini masing-masing
harus dicatat dua kali. Begitu juga pada Sks, setiap kali ingin dicatat nama mata
kuliah, harus selalu dicatat Sksnya. Cara mengatasi kerangkapan data seperti ini
telah dibahas secara lebih rinci dalam Bab IV tentang Kekangan Dalam Basis
Data.
Dalam catatan manual, kartu rencana studi mahasiswa / KRS misalnya, kejadian
tersebut sering terjadi. Hal ini mengindikasikan bahwa struktur tabel dalam
catatan manual tidak bisa serta merta digunakan sebagai struktur tabel / relasi
yang akan disimpan sebagai basis data. Perancang harus mencermati tentang
karakteristik yang harus dipenuhi dalam sebuah relasi.
Istilah atomic value dalam karakteristik pertama dimaksudkan bahwa nilai-nilai
elemen data / entri harus berupa nilai yang tidak dapat dibagi lagi (istilah atomic
berasal dari kata atom yang berarti tidak dapat dibagi lagi). Sebagai contoh untuk
memperjelas istilah atomic value, akan diberikan contoh relasi berikutnya yang
diberi nama relasi Pegawai sebagaimana ditunjukkan pada Tabel 11.5.
9
Tabel 11.5: Relasi Pegawai
NIK Nama_Pegawai Tempat_Tanggal_Lahir
K001 Rita Yogyakarta, 1-1-1981 K002 Rina Semarang, 2-2-1982 K003 Rini Surakarta, 3-3-1983
non atomic value
Dalam Tabel 11.5, terdapat atribut yang memiliki nilai non atomic, yaitu
Tempat_Tanggal_Lahir. Tempat_Tanggal_Lahir disebut non atomic karena
sebenarnya atribut tersebut masih dapat dibagi lagi dan memuat bagian nilai
yang lebih kecil, yaitu Tempat_Lahir danTanggal Lahir. Untuk mengatasi kejadian
ini, maka Tabel 11.5 harus diubah menjadi relasi baru, misal diberi nama
Pegawai_1 sebagaimana ditunjukkan pada Tabel 11.6.
Tabel 11.6: Relasi Pegawai_1
NIK Nama_Pegawai Tempat_Lahir Tanggal_Lahir
K001 Rita Yogyakarta 1-1-1981 K002 Rina Semarang 2-2-1982 K003 Rini Surakarta 3-3-1983
Dalam catatan buku secara manual, Buku Induk Pegawai misalnya, kejadian
tersebut sering terjadi. Hal ini juga mengindikasikan bahwa struktur tabel dalam
catatan manual tidak bisa serta merta digunakan sebagai struktur tabel / relasi
yang akan disimpan sebagai basis data. Harus dicermati tentang karakteristik
relasi yang harus dipenuhi dalam sebuah relasi.
Selanjutnya, dalam karakteristik kedua dinyatakan bahwa semua elemen data /
entri pada suatu atribut tertentu dalam sebuah relasi harus mempunyai tipe dan
ukuran yang sama. Karakteristik ini secara implisit telah terpenuhi pada saat
perancang mendefinisikan struktur relasi dalam kamus data (Data Dictionary /
DD) yang akan digunakan sebagai format penyimpanan data dalam berkas.
Sebagai contoh, seluruh elemen data / entri dalam atribut NIK pada relasi
Pegawai (Tabel 11.6) akan mempunyai tipe dan ukuran yang sama, misal
10
didefinisikan sebagai character dengan panjang 4. Atribut selanjutnya,
Nama_Pegawai dapat didefinisikan sebagai character dengan panjang 25, dan
Alamat dapat didefinisikan sebagai character dengan panjang 50.
Karakteristik ketiga berkaitan dengan penamaan atribut dalam relasi. Masing-
masing atribut dalam sebuah relasi harus mempunyai nama yang unik (berbeda).
Hal ini untuk menjamin bahwa setiap elemen data / entri dalam relasi akan dapat
diakses. Sekalipun tidak akan menimbulkan permasalahan sebaiknya definisi
nama-nama atribut dalam sebuah relasi dibedakan dengan nama-nama atribut
dalam relasi lain. Misal, untuk memudahkan membedakan nama mahasiswa
dalam relasi Mahasiswa dan nama mata kuliah dalam relasi Mata_Kuliah, maka
akan lebih baik jika nama mahasiswa dinyatakan sebagai Nama_Mahasiswa,
sedangkan nama mata kuliah menggunakan Nama_Mata_Kuliah. Jika sama-
sama menggunakan atribut Nama (dalam relasi Mahasiswa dan Mata_Kuliah),
maka bisa jadi akan menimbulkan kerancuan.
Dalam karakteristik keempat, pada sebuah relasi tidak ada dua record data yang
identik. Ketidak-identikan ini akan terpenuhi dengan adanya kunci yang
membedakan setiap record. Karakteristik ini diperlukan untuk memberikan
jaminan bahwa setiap record dalam relasi akan dapat diakses berdasarkan nilai
kunci yang unik. Sebagai contoh, relasi Pegawai pada Tabel 11.6, setiap record
tidak ada yang identik, karena dibedakan oleh NIK. NIK akan selalu berbeda
untuk setiap Pegawai.
1111..33.. KKoommppoonneenn RReellaassii
Setiap relasi dalam RDBM selalu tersusun atas dua komponen, yaitu:
1. Intensi (intension), yaitu menunjukan definisi struktur penamaan (naming
structure) pada relasi dan batasan integritas (integrity contraint) yang meliputi
batasan integritas kesatuan (entity integrity) pada kunci primer (Primary Key /
PK) dan batasan integritas referensial (referential integrity) padakunci
penghubung (Foreign Key / FK). Intensi dapat ditunjukkan menggunakan
schema atau subschema yang digunakan dalam basis data. Intensi
11
cenderung bersifat stabil / tetap, artinya struktur penamaan sebuah relasi
sangat kecil mengalami perubahan.
2. Ekstensi (extension), yaitu menunjukkan nilai-nilai aktual elemen data / entri
yang tersimpan dalam berkas pada suatu saat tertentu. Ekstensi cenderung
tidak stabil / berubah, karena nilai-nilai elemen data / entri akan selalu
ditambah, diperbaharui, atau dihapus.
1111..44.. KKuunnccii RReellaassii
Kunci relasi diperlukan dalam rangka untuk pengaksesan data dari dalam relasi
atau untuk menyusun kerelasian antar relasi. Kunci relasi merupakan satu atau
gabungan atribut yang bersifat unik yang dapat digunakan untuk mengidentifikasi
/ membedakan setiap record dalam relasi. Dengan demikian, kunci relasi harus
bersifat unik, artinya nilai-nilai elemen data / entri dalam atribut yang digunakan
sebagai kunci relasi tidak boleh ada yang sama untuk seluruh record dalam
relasi.
Berdasarkan jumlah atribut penyusunnya, kunci relasi dapat diklasifikasikan
dalam dua jenis, yaitu:
1. Kunci sederhana (simple key), yaitu kunci relasi yang tersusun atas sebuah
atribut. Kunci sederhana terjadi apabila sifat unik telah dapat terpenuhi
dengan menggunakan sebuah atribut saja. Sebagai contoh, dalam relasi
Pegawai_1 (Tabel 11.6) NIP merupakan kunci sederhana, dalam relasi
Mahasiswa_1 (tabel 11.4) NIM merupakan kunci sederhana. NIP dan NIM
tersebut telah memenuhi sifat unik, sehingga dapat digunakan sebagai kunci
relasi
2. Kunci komposit (composite key), yaitu kunci yang tersusun atas gabungan
atribut. Hal ini terjadi jika untuk mencapai sifat unik, tidak dapat dipenuhi oleh
sebuah atribut, tetapi harus menggabungkan lebih dari satu / beberapa
atribut
Berdasarkan macamnya, kunci relasi terdiri atas:
12
1. Kunci kandidat (Candidate Key / CK), yaitu satu atau gabungan minimal
atribut yang bersifat unik yang dapat digunakan untuk mengidentifikasi /
membedakan setiap record dalam relasi. Dalam setiap relasi minimal
mempunyai sebuah kunci kandidat.
2. Kunci primer (Primary Key / PK), yaitu bagian / salah satu dari CK yang dipilih
/ digunakan sebagai kunci utama untuk mengidentifikasi / membedakan
setiap record dalam relasi. Dalam setiap relasi harus mempunyai PK dan
jumlahnya hanya satu buah. PK harus unik dan tidak boleh null.
3. Kunci alternatif (Alternate Key / AK), yaitu bagian dari CK yang tidak dipilih /
digunakan sebagai PK. Dalam setiap relasi tidak harus mempunyai PK. Hal
ini bergantung pada jumlah CK yang ada. Jika jumlah dalam sebuah relasi
lebih dari satu, maka salah satu akan digunakan sebagai PK dan satu
yanglainnya menjadi AK. Tetapi apabila sebuah relasi hanya memiliki sebuah
CK, maka ia akan digunakan sebagai PK dan tidak ada lagi AK.
4. Kunci penghubung atau sering pula disebut sebagai kunci tamu atau kunci
asing (Foreign Key / FK), yaitu satu atau gabungan sembarang atribut yang
menjadi PK dalam relasi lain yang mempunyai hubungan secara logik. FK
tidak harus dimiliki dalam sebuah relasi. Jika FK muncul dalam sebuah relasi,
maka FK tersebut akan menunjukkan adanya kerelasian antar relasi dalam
basis data. Dalam kerelasian antar relasi tersebut, relasi yang mengacu /
mereferensi pada relasi lain disebut sebagai relasi anak, sedangkan relasi
yang menjadi acuan / referensi disebut sebagai relasi induk. FK dan PK
umumnya mempunyai tipe dan ukuran data yang sama.
Jika A, B, C, E, F, dan G menyatakan nama-nama atribut dalam sebuah relasi,
A,B,C, dan D bersifat unik, maka jika A, B, C, dan D adalah CK, jika A dipilih
sebagai PK, maka B, C, dan D disebut AK, dan E, F, dan G adalah atribut
pelengkap / non CK.
Untuk memperjelas pemahaman setiap kunci relasi tersebut akan diberikan
contoh-contoh relasi, yaitu Mahasiswa, Mata_Kuliah, Nilai, KRS, dan KHS yang
secara berturut-turut ditampilkan pada Tabel 11.7, Tabel 11.8, Tabel 11.9, Tabel
11.10, dan Tabel 11.11.
13
Tabel 11.7: Relasi Mahasiswa
NIM Nama_Mahasiwa Alamat
02050001 Rita Jl. Mawar no. 1 Yogyakarta 02050002 Rina Jl. Melati no. 2 Yogyakarta 02050003 Rini Jl. Menur no. 3 Yogyakarta
Tabel 11.8. Relasi Mata_Kuliah
Kode_Mata_Kuliah Nama_Mata_Kuliah Sks Smt Status MK-11001 Pemrograman I 2 1 W MK-12002 Pemrograman II 2 2 W MK-13003 Pemrograman III 2 3 W
Tabel 11.9: Relasi Nilai
Nilai_Huruf Mutu Predikat
A 4 Sangat Baik B 3 Baik C 2 Cukup D 1 Kurang E 0 Gagal
Tabel 11.10: Relasi KRS
NIM Kode_Mata_Kuliah Tahun_Semester
02050001 MK-11001 200220031 02050001 MK-12002 200220032 02050002 MK-11001 200320041 02050002 MK-13003 200320041 02050003 MK-11001 200220031 02050003 MK-12002 200220032
Tabel 11.11: Relasi KHS
NIM Kode_Mata_Kuliah Tahun_Semester Nilai_Huruf
02050001 MK-11001 200220031 A 02050001 MK-12002 200220032 B 02050002 MK-11001 200320041 B 02050002 MK-13003 200320041 B 02050003 MK-11001 200220031 A 02050003 MK-12002 200220032 C
Berdasarkan contoh-contoh relasi dalam Tabel 11.7 hingga Tabel 11.11, maka
dapat ditentukan kunci-kunci relasinya, yaitu sebagai berikut:
1. Relasi Mahasiswa
14
⇒ CK : NIM (kunci sederhana / simple key)
⇒ PK : NIM (kunci sederhana / simple key)
⇒ AK : tidak ada
⇒ FK : tidak ada
Catatan:
⇒ Dalam relasi Mahasiswa satu-satunya atribut yang bersifat unik
adalah NIM, sehingga menjadi CK
⇒ Karena hanya ada satu CK, maka CK tersebut digunakan sebagai PK
dan tidak ada AK
⇒ Dalam relasi Mahasiswa tidak ada sebuah atribut atau gabungan
atribut yang digunakan sebagai PK dalam relasi lainnya, sehingga
tidak ada FK
2. Mata_Kuliah
⇒ CK : Kode_Mata_Kuliah, Nama_Mata_Kuliah
⇒ PK : Kode_Mata_Kuliah (kunci sederhana / simple key)
⇒ AK : Nama_Mata_Kuliah (kunci sederhana / simple key)
⇒ FK : tidak ada
Catatan:
⇒ Dalam relasi Mata_Kuliah atribut yang bersifat unik adalah
Kode_Mata_Kuliah dan Nama_mata_Kuliah, sehingga menjadi CK
⇒ Karena ada dua CK, maka salah satu dipilih sebagai PK, yaitu
Kode_Mata_Kuliah
⇒ Bagian dari CK yang tidak digunakan sebagai PK adalah
Nama_Mata_Kuliah, sehingga menjadi AK
⇒ Dalam relasi Mahasiswa tidak ada sebuah atribut atau gabungan
atribut yang digunakan sebagai PK dalam relasi lainnya, sehingga
tidak ada FK
3. Nilai
⇒ CK : Nilai_Huruf, Mutu, Predikat (kunci sederhana / simple key)
⇒ PK : Nilai_Huruf (kunci sederhana / simple key)
⇒ AK : Mutu, Predikat (kunci sederhana / simple key)
⇒ FK : tidak ada
Catatan:
15
⇒ Dalam relasi Nilai terdapat tiga atribut yang bersifat unik adalah
Nilai_Huruf, Mutu, dan Predikat, sehingga ketiganya menjadi CK
⇒ Karena ada tiga CK, maka salah satu dipilih sebagai PK, yaitu
Nilai_Huruf
⇒ Bagian dari CK yang tidak digunakan sebagai PK adalah Mutu dan
Predikat, sehingga keduanya menjadi AK
⇒ Dalam relasi Nilai tidak ada sebuah atribut atau gabungan atribut
yang digunakan sebagai PK dalam relasi lainnya, sehingga tidak ada
FK
4. KRS
⇒ CK : NIM+Kode_Mata_Kuliah+Tahun_Semester (kunci komposit /
composite key)
⇒ PK : NIM+Kode_Mata_Kuliah+Tahun_Semester (kunci komposit /
composite key)
⇒ AK : tidak ada
⇒ FK : NIM mereferensi ke relasi Mahasiswa dan Kode_Mata_Kuliah
mereferensi ke Mata_Kuliah
Catatan:
⇒ Dalam relasi KRS tidak ada satupun atribut yang bersifat unik, kecuali
berupa gabungan atribut NIM+Kode_Mata_Kuliah+Tahun_Semester,
sehingga menjadi CK
⇒ Karena hanya ada satu CK, maka CK tersebut digunakan sebagai PK
dan tidak ada AK
⇒ Relasi KRS memuat atribut NIM, padahal NIM digunakan sebagai PK
dalam relasi Mahasiswa, sehingga menjadi FK. Nilai-nilai elemen data
pada atribut NIM dalam relasi KRS mengacu pada NIM dalam relasi
Mahasiswa. Dengan demikian relasi Mahasiswa menjadi induk
terhadap relasi KRS atau KRS menjadi relasi anak terhadap relasi
Mahasiswa
⇒ Relasi KRS memuat atribut Kode_Mata_Kuliah, padahal
Kode_Mata_Kuliah digunakan sebagai PK dalam relasi Mata_Kuliah,
sehingga menjadi FK. Nilai-nilai elemen data pada atribut
Kode_Mata_Kuliah dalam relasi KRS mengacu pada
16
Kode_Mata_Kuliah dalam relasi Mata_Kuliah. Dengan demikian relasi
Mata_Kuliah menjadi induk terhadap relasi KRS atau KRS menjadi
relasi anak terhadap relasi Mata_Kuliah
5. KHS
⇒ CK : NIM+Kode_Mata_Kuliah+Tahun_Semester (kunci komposit /
composite key)
⇒ PK : NIM+Kode_Mata_Kuliah+Tahun_Semester (kunci komposit /
composite key)
⇒ AK : tidak ada
⇒ FK : NIM+Kode_Mata_Kuliah+Tahun_Semester mereferensi ke KRS
dan Nilai_Huruf mereferensi ke relasi Nilai
Catatan:
⇒ Dalam relasi KRS tidak ada satupun atribut yang bersifat unik, kecuali
berupa gabungan atribut NIM+Kode_Mata_Kuliah+Tahun_Semester,
sehingga menjadi CK
⇒ Karena hanya ada satu CK, maka CK tersebut digunakan sebagai PK
dan tidak ada AK
⇒ Relasi KHS memuat atribut
NIM+Kode_Mata_Kuliah+Tahun_Semester yang digunakan sebagai
PK dalam relasi KRS, sehingga menjadi FK. Nilai-nilai elemen data
pada atribut NIM+Kode_Mata_Kuliah+Tahun_Semester dalam relasi
KHS mengacu pada NIM+Kode_Mata_Kuliah+Tahun_Semester
dalam relasi KRS. Dengan demikian relasi KRS menjadi induk
terhadap relasi KHS atau KHS menjadi relasi anak terhadap relasi
KRS
⇒ Relasi KHS memuat atribut Nilai_huruf yang digunakan sebagai PK
dalam relasi Nilai, sehingga menjadi FK. Nilai-nilai elemen data pada
atribut Nilai_Huruf dalam relasi KHS mengacu pada Nilai_Huruf dalam
relasi Nlai. Dengan demikian relasi Nilai menjadi induk terhadap relasi
KHS atau KHS menjadi relasi anak terhadap relasi Nilai
⇒ Keberadaan relasi KHS adalah bergantung pada relasi KRS, artinya
data-data perolehan nilai mahasiswa hanya akan mungkin terjadi
apabila ia telah tercatat mengikuti mata kuliah dalam relasi KRS.
17
Dengan demikian, relasi KHS mereferensi ke KRS (bukan
mereferensi ke relasi Mahasiwa dan Mata_Kuliah) dan Nilai
1111..55.. AAttuurraann--aattuurraann ((RRuulleess)) KKuunnccii RReellaassii
Aturan-aturan (rules) kunci relasi utamanya berkaitan dengan dua batasan
integritas, yaitu integritas kesatuan / integritas entitas (entity integrity) dan
integritas referensial (referential integrity).
1. Integritas kesatuan / integritas entitas (entity integrity) Aturan ini memberikan batasan bahwa secara kesatuan nilai-nilai elemen data /
entri pada atribut yang dipilih / digunakan sebagai PK tidak boleh null. Untuk data
bertipe character, maka untuk setiap record yang ada dalam relasi tidak boleh
ada elemen data / entri dengan panjang character nol atau kosong (=spasi).
Untuk data bertipe numerik, maka untuk setiap record yang ada dalam relasi
tidak boleh ada elemen data / entri dengan nilai 0 (=nol). Aturan ini akan
memberikan jaminan bahwa setiap record dalam relasi akan dapat diakses
berdasarkan nilai PK yang unik dan tidak pernah kosong.
Sebagai contoh, nilai-nilai elemen data / entri pada atribut NIM dalam relasi
Mahasiswa (Tabel 11.7), Kode_Mata_Kuliah dalam relasi Mata_Kuliah (Tabel
11.8), Nilai_Huruf dalam relasi Nilai (Tabel 11.9), gabungan atribut
NIM+Kode_Mata_Kuliah+Tahun_Semester dalam relasi KRS (Tabel 11.10),
serta gabungan atribut NIM+Kode_Mata_Kuliah+Tahun_Semester dalam relasi
KHS (Tabel 11.11) secara kesatuan tidak boleh ada yang bernilai null.
2. Integritas referensial (referential integrity) Aturan ini membatasi bahwa di dalam kerelasian antar dua atau lebih relasi
dalam basis data yang dihubungkan dengan suatu kunci penghubung (foreign
key / FK), maka hubungan antar relasi tersebut harus menjamin bahwa setiap
nilai elemen data / entri pada FK dalam relasi anak harus ada record dengan nilai
elemen data / entri yang sama pada relasi yang dihubungkan.
18
Sebagai contoh, relasi KRS memuat FK, yaitu atribut NIM dan atribut
Kode_Mata_Kuliah. Sesuai dengan aturan integritas referential, maka setiap nilai
elemen data / entri NIM dalam relasi KRS harus muncul nilai elemen data / entri
dengan nilai yang sama dalam relasi Mahasiswa. Begitu juga halnya dengan
setiap nilai elemen data / entri Kode_Mata_Kuliah dalam relasi KRS harus
muncul nilai elemen data / entri dengan nilai yang sama dalam relasi
Mata_Kuliah.
Dalam relasi KHS, terdapat dua FK, yaitu
NIM+Kode_Mata_Kuliah+Tahun_Semester dan Nilai_Huruf. Dengan demikian,
maka setiap nilai elemen data / entri gabunagn
NIM+Kode_Mata_Kuliah+Tahun_Semester dalam relasi KHS harus muncul nilai
elemen data / entri dengan nilai yang sama dalam relasi KRS. Begitu juga halnya
dengan setiap nilai elemen data / entri Nilai_Huruf dalam relasi KHS harus
muncul nilai elemen data / entri dengan nilai yang sama dalam relasi Nilai.
Secara lebih umum, nilai-nilai elemen data / entri yang diacu oleh FK harus eksis
dalam relasi induknya. NIM mahasiswa yang ada dalam relasi KRS harus eksis
dalam relasi Mahasiswa dan Kode_Mata_Kuliah yang ada dalam relasi KRS
harus eksis dalam relasi Mata_Kuliah. Artinya Mahasiswa yang mengambil mata
kuliah benar-benar ada adalam relasi mahasiswa dan mata kuliah yang diikuti
mahasiswa benar-benar ada dalam relasi Mata_Kuliah. Jika tidak, berarti
integritas referensial tidak terpenuhi.
1111..66.. KKeerreellaassiiaann AAnnttaarr RReellaassii ((RReellaattiioonnsshhiipp))
Istilah kerelasian berbeda dengan istilah relasi. Relasi adalah menyatakan
sebuah tabel dalam basis data, sedangkan kerelasian menyatakan hubungan
antar relasi dalam basis data. Kerelasian antar relasi dapat ditunjukkan oleh FK
atau relasi-relasi bertipe transaksi yang digunakan dalam basis data. Kerelasian
antar relasi dapat ditunjukkan menggunakan sebuah diagram yang disebut
Diagram Kerelasian Antar Relasi. Cara lain juga dapat dilakukan, yaitu dengan
menggunakan subschema atau schema basis data.
19
Secara konsep, jenis-jenis kerelasian antar relasi dalam RDBM sama dengan
jenis-jenis kerelasian antar entitas dalam ER_M. Kerelasian tersebut
menunjukkan hubungan antar data dalam basis data.
1. Kerelasian satu ke satu / 1-ke-1 (one to one relationship / 1-to-1)
Jenis kerelasian 1-ke-1 terjadi jika setiap nilai pada suatu relasi hanya
mengimplikasikan sebuah nilai pada relasi lain yang direlasikan secara logik.
Jenis kerelasian jenis ini jarang dijumpai dalam rancangan basis data.
2. Kerelasian satu ke banyak / 1-ke-n (one to many relationship / 1-to-n)
Jenis kerelasian 1-ke-n terjadi jika setiap nilai pada suatu relasi
mengimplikasikan banyak (lebih dari satu) nilai pada relasi lain yang
direlasikan secara logik.
3. Kerelasian banyak ke satu banyak / n-ke-1 (many to one relationship / n-to-1)
Jenis kerelasian n-ke-1 terjadi jika banyak (lebih dari satu) nilai pada suatu
relasi mengimplikasikan hanya satu nilai pada relasi lain yang direlasikan
secara logik.
4. Kerelasian banyak ke banyak / n-ke-n (many to many relationship / n-ton)
Jenis kerelasian n-ke-n terjadi jika banyak (lebih dari satu) nilai pada suatu
relasi mengimplikasikan banyak (lebih dari satu) nilai pada relasi lain yang
direlasikan secara logik.
Sebagaimana dalam ER_M, jenis kerelasian antar relasi ni tidak dibatasi oleh
waktu dan tempat. Jenis kerelasian tersebut ditentukan oleh kemungkinan-
kemungkinan yang terjadi pada nilai-nilai aktual elemen data / entri dalam relasi.
Aturan bisnis yang digunakan pada suatu sistem akan menentukan kemungkinan
tersebut. Untuk menggambarkan diagram kerelasian antar relasi dapat dilakukan
dengan cara sebagai berikut:
1. Tuliskan setiap relasi dan atribut pada setiap relasi dalam bentuk tabel
satu kolom, dimana kepala tabel memuat nama relasi dan isi tabel
memuat nama-nama atributnya
2. Tentukan PK dan FK (jika ada) dalam setiap relasi. Berikan tanda bintang
(*) pada atribut yang berfungsi sebagai PK dan dua bintang (**) pada
20
atribut yang berfungsi sebagai FK. Bilamana atribut FK sekaligus
berfungsi sebagai PK maka cukup ditandai dengan satu tanda bintang (*)
3. Gambarkan kerelasian antar relasi dengan cara menghubungkan setiap
FK dengan atribut yang sesuai pada relasi induknya dengan tanda garis
4. Gambarkan jenis kerelasian antar entitas dengan menggunakan tanda
panah ganda untuk jenis banyak dan sebuah mata panah untuk jenis satu
Untuk lebih jelasnya, berikut diberikan contoh menggambar diagram kerelasian
antar relasi untuk relasi-relasi dalam Tabel 11.7, Tabel 11.8, Tabel 11.9, Tabel
11.10, dan Tabel 11.11. Langkah-langkahnya secara berurutan ditampilkan pada
Gambar 11.1, Gambar 11.2, Gambar 11.3, dan Gambar 11.4.
Langkah 1:
Mahasiswa NIM Nama_Mahasiwa Alamat
Mata_Kuliah Kode_Mata_Kuliah Nama_Mata_Kuliah Sks Smt Status
Nilai
Niai_Huruf Mutu Predikat
KRS
NIM Kode_Mata_Kuliah Tahun_Semester
KHS
NIM Kode_Mata_Kuliah Tahun_Semester Nilai_Huruf
Gambar 11.1: Menuliskan relasi dan atribut dalam bentuk tabel (Langkah 1)
21
Langkah 2:
Mahasiswa NIM * Nama_Mahasiwa Alamat
Mata_Kuliah
Kode_Mata_Kuliah * Nama_Mata_Kuliah Sks Smt Status
Nilai
Niai_Huruf * Mutu Predikat
KRS
NIM * Kode_Mata_Kuliah * Tahun_Semester *
KHS
NIM * Kode_Mata_Kuliah * Tahun_Semester * Nilai_Huruf **
Gambar 11.2: Menentukan dan menandai PK dan FK (Langkah 2)
Catatan:
⇒ Dalam relasi KRS, NIM dan Kode_Mata_Kuliah berfungsi sebagai PK
dan sekaligus sebagai FK, sehingga tanda yang digunakan adalah
satu bintang
⇒ Dalam relasi KHS, NIM+Kode_Mata_Kuliah+Tahun_Semester
berfungsi sebagai PK dan sekaligus sebagai FK, sehingga tanda yang
digunakan adalah satu bintang
⇒ Dalam relasi KHS, Nilai_Huruf berfungsi sebagai FK, sehingga tanda
yang digunakan adalah dua bintang
22
Langkah 3:
NIM * Nama_Mahasiwa Alamat
Niai_Huruf * Mutu Predikat
NIM * Kode_Mata_Kuliah * Tahun_Semester *
Kode_Mata_Kuliah * Nama_Mata_Kuliah Sks Smt Status
NIM * Kode_Mata_Kuliah * Tahun_Semester * Nilai_Huruf **
Mahasiswa
Mata Kuliah
KRS
KRS
KRS
Gambar 11.3: Menghubungkan antar relasi (Langkah 3)
Langkah 4:
NIM * Nama_Mahasiwa Alamat
Niai_Huruf * Mutu Predikat
NIM * Kode_Mata_Kuliah * Tahun_Semester *
Kode_Mata_Kuliah * Nama_Mata_Kuliah Sks Smt Status
NIM * Kode_Mata_Kuliah * Tahun_Semester * Nilai_Huruf **
Mahasiswa
Mata Kuliah
KRS
KRS
Nilai
Gambar 11.4: Menggambarkan jenis kerelasian antar relasi (Langkah 4)
23
Berdasarkan urutan langkah tersebut, maka diagram kerelasian antar relasi
antara relasi Mahassiwa, Mata_Kuliah, Nilai, KRS, dan KHS adalah ditunjukkan
pada hasil langkah terakhir, yaitu Gambar 11.4.
1111..77.. BBeebbeerraappaa DDeeffiinniissii RReellaassii ((RReellaattiioonn))
Beberapa definisi yang berkaitan dengan penyebutan sebuah relasi antara lain
adalah:
1. Relasi tak gayut Istilah relasi tak gayut digunakan untuk penyebutan sebuah relasi yang
berasal dari entitas reguler / dominan. Ciri relasi tak gayut adalah tidak
memiliki FK di dalamnya. Sebagai contohnya adalah relasi Mahasiswa (Tabel
11.7), Mata_Kuliah (Tabel 11.8), dan relasi Nilai (Tabel 11.9)
2. Relasi asosiatif Istilah relasi asosiatif digunakan untuk menyatakan sebuah relasi yang
mempunyai jenis kerelasian n-ke-n. Ciri relasi asosistif adalah memiliki lebih
dari 1 FK. Sebagai contohnya adalah relasi KRS (Tabel 11.10)
3. Relasi karakteristik Istilah relasi karakteristik digunakan untuk menyatakan sebuah relasi yang
berasal dari entitas dependen / tak gayut / tak bebas. Ciri relasi karakteristik
umumnya mempunyai jenis kerelasian n-ke-1 terhadap relasi yang menjadi
induknya. Sebagai contohnya adalah relasi KRS (Tabel 11.4) terhadap Nilai
(Tabel 11.9)
4. Subrelasi Istilah subrelasi digunakan untuk menyatakan sebuah relasi yang berasal dari
sub type entity. Saat akhir perancangan, subrelasi biasanya digabungkan
dengan super relasi. Sebagai contoh, relasi Mahasiswa (Tabel 11.7) dapat
memuat record mahasiswa baik jenjang sarjana maupun Diploma III. Dalam
ER_M mahasiswa jenjang sarjana dan mahasiswa jenjang Diploma III
merupakan subtype entitty terhadap supertype entity mahasiswa.
24
1111..88.. PPeennyyiimmppaannggaann--PPeennyyiimmppaannggaann DDaallaamm MMooddiiffiikkaassii ((AAnnoommaalllliieess))
Penyimpangan-penyimpangan (anomalies) yang harus dihindari dalam modifikasi
data meliputi:
1. Penyimpangan penghapusan (delete aomally) Penyimpangan penghapusan (delete aomally) adalah suatu proses
penghapusan suatu nilai rinci data yang mengakibatkan hilangnya informasi
rinci data lain yang tidak mempunyai kerelasian secara logik
Sebagai contoh, jika diketahui sebuah relasi bernama Siswa, yang digunakan
untuk mencatat data siswa peserta kursus bahasa pada sebuah lembaga
pelatihan bahasa, sebagaimana ditunjukkan pada Tabel 11.12.
Tabel 11.12: Relasi Siswa
NIS Nama_Siswa Jenis_Kursus Instruktur Periode
1001 Dian Bahasa Inggris Nita Januari 1998 1002 Dina Bahasa Jepang Nina April 1998 1003 Dani Bahasa Mandarin Nani Juli 1998 1004 Doni Bahasa Inggris Noni Januari 1998 1005 Dino Bahasa Jepang Nina April 1998 1006 Dion Bahasa Inggris Noni Januari 1998
Penyimpangan:
Karena Dani telah selesai mengikuti kursus Bahasa Mandarin 5 tahun yang
lalu dan data tersebut tidak akan digunakan lagi, maka recordnya akan
dihapus. Secara kebetulan peserta kursus Bahasa Mandarin periode Juli
1998 hanya seorang saja. Akibatnya, seluruh rinci data dalam record tersebut
akan hilang dari basis data, termasuk informasi tentang instruktur bernama
Nani dan periode kursus Juli 1998 juga akan ikut hilang. Padahal semula
hanya diinginkan untuk menghapus nilai rinci data Dani saja. Kejadian ini
harus dihindarkan dalam basis data.
2. Penyimpangan penyisipan (insert anomally) Penyimpangan penyisipan (insert anomally) adalah suatu proses
menyisipkan suatu nilai rinci data yang mengakibatkan perlunya penyisipan
pada nilai rinci data lain yang tidak mempunyai kerelasian secara logik
25
Penyimpangan:
Dengan tetap menggunakan contoh relasi dalam Tabel 11.12, maka jika ada
seorang instruktur baru yang masuk ke lembaga pelatihan tersebut, tetapi
belum pernah mengajar sama sekali, maka penambahan data instruktur
tersebut tidak dapat dilakukan selama belum pernah mengajar. Kejadian ini
juga merupakan penyimpangan yang harus dihindari dari dalam basis data.
3. Penyimpangan pembaharuan (update anomally) Penyimpangan pembaharuan (update anomally), adalah suatu proses
mengubah suatu nilai rinci data yang mengakibatkan perlunya pengubahan
pada nilai rinci data lain yang tidak mempunyai kerelasian secara logik
Penyimpangan:
Untuk memberikan contoh penyimpangan pembaharuan akan digunakan
relasi baru bernama Karyawan seperti dalam Tabel 11.13.
Tabel 11.13: Relasi Karyawan
NIK Nama_Karyawan Golongan_Gaji Gaji_Pokok
01001 Feri IIIA 600000 01002 Fira IIIB 650000 01003 Fina IIIA 600000 01004 Fita IVA 800000 01005 Fani IIIB 650000
Penyimpangan:
Dalam relasi Karyawan, apabila ternyata terjadi perubahan Gaji_Pokok
karyawan, misal kenaikan untuk Golongan_Gaji IIIA adalah menjadi 625.000,
maka nilai rinci data Gaji_Pokok harus di-update. Dalam contoh di atas
perubahan harus dilakukan sebanyak dua kali. Jika jumlah karyawan yang
memiliki Golongan_Gaji IIIA cukup banyak, maka update harus dilakukan
secara berulang kali sebanyak karyawan yang memiliki Golongan_Gaji IIIA.
Jika perubahan tidak dilakukan secara menyeluruh atau ada yang
terlewatkan maka akan timbul inkonsistensi data. Kejadian seperti ini harus
dihindari dari dalam basis data.
26
Penyimpangan tersebut merupakan efek samping yang tidak diharapkan dalam
relasi / basis data. Penyimpangan-penyimpangan (anomallies) dalam modifikasi
dapat terjadi akibat munculnya kerangkapan data (data redundancy) dalam
sebuah relasi.
1111..99.. KKeetteerrggaannttuunnggaann DDaattaa ((DDaattaa DDeeppeennddeennccyy))
Penyimpangan yang terjadi dalam modifikasi selain akibat kerangkapan data,
juga terjadi karena pada kenyataannya suatu nilai rinci data dalam relasi dapat
memiliki ketergantungan terhadap nilai rinci data yang lain, selama rinci data-rinci
data dalam struktur tidak tergantung secara logik. Ketergantungan antar rinci
data menjabarkan hubungan antara atribut-atribut dalam hal bagaimana suatu
nilai menentukan nilai yang lain.
Kondisi ini memerlukan upaya / keharusan untuk menghilangkan permasalahan-
permasalahan akibat ketergantungan data. Ketergantungan data memungkinkan
untuk melakukan dekomposisi / pemecahan data yang sesuai ke dalam bentuk
yang efisien. Permasalahan-permasalahan yang muncul dalam struktur relasi
tersebut dapat ditemukan dengan cara mengetes / menguji ketergantungan relatif
nilai-nilai rinci data terhadap PK.
Pada umumnya, yang paling baik dilakukan adalah jika struktur relasi dirancang
sedemikian rupa sehingga atribut-atribut non kunci hanya bergantung pada
atribut PK dan tidak memiliki ketergantungan pada aribut lainnya.
Ketergantungan data terdiri atas:
1. Ketergantungan fungsional (Functionally Dependence / FD) FD akan muncul dalam suatu relasi jika nilai rinci data pada suatu atribut
menentukan / mengimplikasikan nilai rinci data pada atribut lain. Dalam
kalimat yang lain, sebuah atribut (=Y) dikatakan berketergantungan secara
fungsional terhadap atribut lain (=X) jika:
⇒ Setiap nilai X berkaitan dengan sebuah nilai pada Y
27
⇒ Untuk setiap record yang memiliki sembarang nilai X, selalu berhubungan
dengan nilai Y yang sama
FD dapat dinyatakan dengan notasi:
FD: R.X →R.Y
Keterangan:
FD : Functionally Dependence
R : nama relasi
X : atribut penentu (determines), yaitu CK
Y : atribut yang bergantung (dependent)
Suatu petunjuk praktis untuk menentukan FD dalam sebuah relasi adalah
dengan cara mencari CK, dan kemudian dikaitkan dengan atribut-atribut lain
dalam relasi yang sama. Untuk membantu mempermudah pemahaman
tentang FD, akan diberikan contoh relasi bernama Tour sebagaimana
ditampilkan pada Tabel 11.14.
Tabel 11.14: Relasi Tour
No_Anggota Nama-
Anggota
Alamat_Lokal Tujuan Beaya Tanggal
3246 Erna Jl. Mawar 10 Bali 500000 1-1-2002
5498 Erni Jl. Menur 20 Lombok 750000 2-2-2002
8730 Irna Jl. Melati 5 Surabaya 300000 3-3-2002
6593 Arni Jl. Mawar 20 Bali 550000 2-2-2002
Dalam relasi Tour, maka FD dapat dituliskan sebagai berikut:
FD: R.X →R.Y
FD: (Tour.No_Anggota, Tour.Tujuan, Tour.Tanggal)
→(Tour.Nama_Anggota, Tour.Alamat_Lokal, Tour.Beaya)
28
Dalam contoh FD tersebut, Nama_Anggota dan Alamat_Lokal peserta tour
adalah bergantung pada No_Anggota. Sedangkan Beaya tour bergantung
pada Tujuan dan tanggal Perjalanan.
2. Ketergantungan fungsional penuh (Full Functionally Dependency / FFD) Suatu atribut dikatakan FFD pada suatu kombinasi atribut jika FD pada suatu
atribut dan tidak FD pada bagian lain dari kombinasi atribut. Yang dimaksud
dengan bagian lain dari suatu kombinasi atribut di sini adalah kombinasi
atribut selain set FD dan set kosong. Dalam kalimat yang lain, suatu atribut Y
mempunyai ketergantungan fungsional penuh terhadap atribut X jika:
⇒ Y functionally dependency terhadap X
⇒ Y tidak functionally dependency terhadap bagian tertentu dari X
Ketergantungan fungsional penuh (Full Functionally Dependency / FFD)
dinyatakan dengan notasi:
FFD: R.X →R.Y
Keterangan:
FFD : Full Functionally Dependency
R : nama relasi
X : atribut penentu (determines), yaitu CK
Y : atribut yang bergantung (dependent)
Dengan tetap menggunakan contoh relasi Tour pada Tabel 11.14, maka FFD
dalam relasi tersebut dapat dituliskan sebagai berikut:
FFD: R.X →R.Y
FFD: (Tour.Tujuan, Tour.Tanggal) →(Tour.Beaya)
FFD: (Tour.No_Anggota) →(Tour.Nama_Anggota, Tour.Alamat_Lokal)
Dalam contoh tersebut, beaya tour menuju tujuan tertentu hanya bergantung
sepenuhnya pada tujuan dan tanggal tour, dan tidak bergantung pada siapa
yang melakukan tour. Sedangkan Nama_Anggota dan Alamat_Lokal hanya
bergantung sepenuhnya pada No_Anggota.
29
3. Ketergantungan transitif (Transitive Dependency / TDF) TDF muncul dalam relasi jika suatu nilai pada atribut pertama menentukan
nilai pada atribut kedua yang bukan CK, dan nilai pada atribut kedua
menentukan nilai pada atribut ketiga. Jadi TDF akan terjadi jika nilai pada
suatu atribut bergantung pada dua atribut sekaligus.
Dalam kalimat yang lain, suatu atribut Z dikatakan mengalami
ketergantungan transitif (Transitive Dependency / TDF) terhadap X, jika:
⇒ Y functionally dependency terhadap X
⇒ Z functionally dependency terhadap Y
Ketergantungan transitif (Trancitive Dependency / TDF) dinyatakan dengan
notasi:
TDF: R.X →R.Y→R.Z
Keterangan:
TDF : Trancitive Dependency
R : nama relasi
X : atribut penentu (determines)
Y : atribut yang bergantung (dependent) terhadap X dan sekaligus
penentu terhadap Z
Z : atribut yang bergantung (dependent) terhadap Y
Untuk menunjukkan TDF, contoh relasi Karyawan pada Tabel 11.13 akan
sedikit dimodifikasi menjadi seperti Tabel 11.15.
Tabel 11.15: Relasi Karyawan
NIK Nama_Karyawan Golongan_Gaji Gaji_Pokok
01001 Feri IIIA 600000 01002 Fira IIIB 650000 01003 Fina IIIA 600000 01004 Fita IVA 800000 01005 Fani IIIB 650000
Dalam relasi karyawan, maka TDF dapat dituliskan sebagai berikut:
30
TDF: R.X →R.Y→R.Z
TDF: (Karyawan.NIK) →(Karyawan.Golongan_Gaji)
→(Karyawan.Gaji_Pokok)
Dalam contoh TDF tersebut, Golongan_Gaji FD pada NIK, dan Gaji_Pokok
FD pada Golongan_Gaji. NIK berperan sebagai X, Golongan_Gaji sebagai Y,
dan Gaji_Pokok sebagai Z. Jadi nilai-nilai rinci data pada atribut Gaji_Pokok
(=Z) bergantung pada Golongan_Gaji
4. Ketergantungan total (Total Dependency / TD) Atribut Y dikatakan mengalami ketergantungan total (Total Dependency /
TD), jika:
⇒ Y functionally dependency terhadap X
⇒ X functionally dependency terhadap Y
Ketergantungan total (Total Dependency / TD) dinyatakan dengan notasi:
TD: R.X ↔R.Y
Keterangan:
TD : Total Dependency
R : nama relasi
X : atribut penentu (determines), sekaligus bergantung pada Y
Y : atribut yang bergantung (dependent) sekaligus penentu pada X
Untuk memberikan contoh TD, relasi Karyawan dalam Tabel 11.15 akan
tetap digunakan. Dalam relasi Karyawan, TD dapat dituliskan sebagai berikut:
TD: R.X ↔R.Y
TD: (Karyawan.Golongan_Gaji) ↔ (Karyawan.Gaji_Pokok)
Selain ditampilkan menggunakan notasi seperti di atas, FD, FFD, TDF, dan TD
dapat ditampilkan dengan bentuk yang lain, yaitu menggunakan diagram
ketergantungan data. Dalam bentuk ini terdapat dua cara yang dapat dipilih, cara
31
pertama (cara 1) adalah digambarkan secara horisontal, sedangkan cara kedua
(cara 2) digambarkan secara secara vertikal. Keduanya sama saja, dan kita bisa
menggunakan salah satu tanpa menimbulkan permasalahan. Langkah
menggambar diagram ketergantungan data dengan cara 1 adalah sebagai
berikut:
1. Tempatkan setiap atribut yang menjadi penentu pada sebuah garis
horisontal yang berupa titik-titik sebagai penghubung
2. Identifikasikan setiap atribut yang bergantung pada atribut penentu
tersebut
3. Gambarkan hal tersebut dengan menggunakan panah ke bawah
4. Identifikasikan dan gambarkan ketergantungan data
Diagram ketergantungan data untuk relasi Tour (Tabel 11.14) ditampilkan pada
Gambar 11.5 atau Gambar 11.6. Diagram ketergantungan data untuk relasi
Karyawan (Tabel 11.15) ditampilkan pada Gambar 11.7 atau Gambar 11.8.
Dalam Gambar 11.5, atribut-atribut No-Anggota dan Tanggal+Tujuan
ditempatkan pada posisi segaris di bagian atas. Hal ini dimaksudkan bahwa
atribut-atribut tersebut merupakan atribut penentu dalam relasi. Sedangkan
atribut Nama_Anggota dan Alamat_Lokal ditempatkan di bawahnya karena
merupakan atribut-atribut yang bengantung. Untuk menyatakan bahwa
Nama_Anggota dan Alamat_Lokal bergantung pada No_Anggota, maka
dihubungkan menggunakan garis panah. Sedangkan atribut Beaya bergantung
pada atribut Tanggal+Tujuan, sehingga dihubungkan menggunakan dua garis
panah. Dengan analogi yang sama, Gambar 11.6 menunjukkan diagramn
ketergantungan data dengan cara lain, yaitu secara vertikal.
No_Anggota ………..………… Tanggal +Tujuan
Nama_Anggota Alamat_Lokal Beaya
Gambar 11.5. Diagram ketergantungan data dalam relasi Tour (cara 1)
32
No Anggota
Tanggal
Tujuan
Nama Anggota
Alamat Lokal
Beaya
Gambar 11.6. Diagram ketergantungan data dalam relasi Tour (cara 2)
NIK ………..……………. Golongan_Gaji
Nama_Karyawan Gaji_Pokok
Gambar 11.7. Diagram ketergantungan data dalam relasi Karyawan (cara 1)
NIK
Golongan Gaji
Nama_Karyawan
Gaji Pokok
Gambar 11.8. Diagram ketergantungan data dalam relasi Karyawan (cara 2)
1111..1100.. NNoorrmmaalliissaassii ((NNoorrmmaalliizzaattiioonn))
1111..1100..11.. DDeeffiinniissii NNoorrmmaalliissaassii
Perancangan basis data akan menghasilkan sekumpulan relasi baru yang harus
tetap saling berkerelasian dalam lingkup sebuah sistem / organisasi. Untuk
memenuhi batasan dalam definisi basis data, maka setiap relasi perlu diuji untuk
33
menentukan apakah setiap relasi yang akan digunakan telah optimal. Pengujian
tersebut dilakukan berdasarkan kriteria bentuk-bentuk normal. Jika relasi belum
optimal, maka perlu dilakukan proses normalisasi. Perwujudan normalisasi
adalah dekomposisi relasi menjadi relasi-relasi baru yang lebih sederhana.
Normalisasi diartikan sebagai suatu teknik yang menstrukturkan / memecah /
mendekomposisi data dalam cara-cara tertentu untuk mencegah timbulnya
permasalahan pengolahan data dalam basis data. Permasalahan yang dimaksud
adalah berkaitan dengan penyimpangan-penyimpangan (anomallies) yang terjadi
akibat adanya kerangkapan data dalam relasi dan inefisiensi pengolahan.
Proses normalisasi akan menghasilkan relasi yang optimal, yaitu:
1. Memiliki struktur record yang konsisten secara logik
2. Memiliki struktur record yang mudah untuk dimengerti
3. Memiliki struktur record yang sederhana dalam pemeliharaan
4. Memiliki struktur record yang mudah untuk ditampilkan kembali untuk
memenuhi kebutuhan pemakai
5. Minimalisasi kerangkapan data guna meningkatkan kinerja sistem
Bentuk-bentuk normal first norm form / 1NF, second norm form / 2NF, dan third
norm form / 3NF dikemukakan oleh E.F. Codd. Sedangkan bentuk normal Boyce-
Codd norm form / BCNF dikemukakan oleh R.F. Boyce dan E.F. Codd. Bentuk
normal BCNF, forth norm form / 4NF, dan fifth norm form / 5NF dapat terjadi
pada relasi-relasi yang menggunakan PK berupa composite key. Dan
selanjutnya, bentuk Domain Key Norm Form / DKNF dan Restriction Union Norm
Form / RUNF dapat terjadi pada relasi-relasi yang bersifat sangat spesifik,
sehingga tidak semua relasi memungkinkan untuk mencapai level ini.
Umumnya rancangan relasi dalam basis data telah optimal jika memenuhi kriteria
bentuk 3NF. Level normalisasi ditentukan berdasarkan kriteria bentuk normal,
bukan banyaknya langkah menstrukturkan / dekomposisi / pemecahan sebuah
relasi.
34
1111..1100..22.. LLeevveell NNoorrmmaalliissaassii
Teori normalisasi dibangun menurut konsep level normalisasi. Level normalisasi
atau sering disebut sebagai bentuk normal suatu relasi dijelaskan berdasarkan
kriteria tertentu pada bentuk normal. Bentuk normal yang dikenal hingga saat ini
meliputi bentuk 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF, dan RUNF. Secara
berturut-turut masing-masing level normal tersebut akan dibahas berikut ini,
dimulai dari bentuk tidak normal.
1. Relasi bentuk tidak normal (Un Normalized Form / UNF) Relasi-relasi yang dirancang tanpa mengindahkan batasan dalam definisi basis
data dan karakteristik RDBM akan menghasilkan relasi UNF. Bentuk ini harus
dihindari dalam perancangan relasi dalam basis data. Relasi UNF mempunyai
kriteria sebagai berikut:
a. Jika relasi mempunyai bentuk non flat file (terjadi akibat data disimpan sesuai
dengan kedatangannya, sehingga tidak memiliki struktur yang sama /
tertentu, terjadi duplikasi atau tidak lengkap)
b. Jika relasi memuat set atribut berulang (non single value)
c. Jika relasi memuat atribut non atomic value
2. Relasi bentuk normal pertama (first norm form / 1NF) Relasi disebut sebagai 1NF jika memenuhi kriteria sebagai berikut:
a. Jika seluruh atribut dalam relasi bernilai atomik (atomic value)
b. Jika seluruh atribut dalam relasi bernilai tunggal (single value)
c. Jika relasi tidak memuat set atribut berulang
d. Jika semua record mempunyai sejumlah atribut yang sama
Permasalahan dalam 1NF adalah sebagai berikut:
a. Tidak dapat menyisipkan informasi parsial
b. Terhapusnya informasi ketika menhapus sebuah record
c. Pembaharuan atribut non kunci mengakibatkan sejumlah record harus
diperbaharui
35
Untuk mengubah relasi UNF menjadi bentuk 1NF, dapat dilakukan dengan cara
sebagai berikut:
a. Melengkapi nilai-nilai dalam atribut
b. Mengubah struktur relasi
3. Bentuk normal kedua (second norm form / 2NF) Relasi disebut sebagai 2NF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria 1 NF
b. Jika semua atribut non kunci FD pada PK
Permasalahan dalam 2NF adalah sebagai berikut:
a. Kerangkapan data (data redundancy)
b. Pembaharuan yang tidak benar dapat menimbulkan inkonsistensi data
(data inconsistency)
c. Proses pembaharuan data tidak efisien
d. Penyimpangan / permasalahan pada saat penyisipan, penghapusan dan
pembaharuan
Kriteria tersebut mengindikasikan bahwa di antara atribut dalam 2NF masih
mungkin mengalami TDF. Selain itu, relasi 2NF menuntut telah didefinisikan
atribut PK dalam relasi.
Untuk mengubah relasi 1NF menjadi bentuk 2NF, dapat dilakukan dengan
mengubah struktur relasi dengan cara:
a. Identifikasikan FD relasi 1NF (jika perlu gambarkan diagram
ketergantungan datanya)
b. Berdasarkan informasi tersebut, dekomposisi relasi 1NF menjadi relasi-
relasi baru sesuai FD-nya. Jika menggunakan diagram, maka simpul-
simpul yang berada pada puncak diagram ketergantungan data bertindak
sebagai PK pada relasi baru
4. Bentuk normal ketiga (third norm form / 3NF) Suatu relasi disebut sebagai 3NF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria 2NF
36
b. Jika setiap atribut non kunci tidak TDF (nontransitive dependeny)
terhadap PK
Permasalahan dalam 3NF adalah keberadaan penentu yang tidak merupakan
bagian dari PK menghasilkan duplikasi rinci data pada atribut yang berfungsi
sebagai FK (duplikasi berbeda dengan kerangkapan data).
Untuk mengubah relasi 2NF menjadi bentuk 3NF, dapat dilakukan dengan
mengubah struktur relasi dengan cara:
a. Identifikasikan TDF relasi 2NF (jika perlu gambarkan diagram
ketergantungan datanya)
b. Berdasarkan informasi tersebut, dekomposisi relasi 2NF menjadi relasi-
relasi baru sesuai TDF-nya. Jika menggunakan diagram, maka simpul-
simpul yang berada pada puncak diagram ketergantungan data bertindak
sebagai PK pada relasi baru
Misal:
Terhadap relasi R dengan sifat sebagai berikut:
a. R=(A,B,C) dengan PK = A
b. FD: R.B →R.C
Maka relasi R perlu didekomposisi menjadi relasi-relasi R1 dan R2, yaitu:
a. R1 = (B,C)
b. R2 = (A, B), FK: B references R1
5. Bentuk normal Boyce-Cood (Boyce-Codd norm form / BCNF) Bentuk normal BCNF dikemukankan oleh R.F. Boyce dan E.F. Codd. Suatu
relasi disebut sebagai BCNF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria 3NF
b. Jika semua atribut penentu (determinan) merupakan CK
6. Bentuk normal keempat (forth norm form / 4NF) Relasi disebut sebagai 4NF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria BCNF
37
b. Jika setiap atribut di dalamnya tidak mengalami ketergantungan pada
banyak nilai. Atau dengan kalimat lain, bahwa semua atribut yang
mengalami ketergantungan pada banyak nilai adalah bergantung secara
fungsional (functionally dependency)
7. Bentuk normal kelima (fifth norm form / 5NF) Suatu relasi disebut sebagai 5NF, jika kerelasian antar data dalam relasi tersebut
tidak dapat direkonstruksi dari struktur relasi yang memuat atribut yang lebih
sedikit.
8. Bentuk normal kunci domain (domain key norm form / DKNF) Suatu relasi disebut sebagai 5NF, jika setiap batasan dapat disimpulkan secara
sederhana dengan mengetahui sekumpulan nama atribut dan domainnya selama
menggunakan sekumpuan atribut pada kuncinya. Bentuk DKNF ini dikemukakan
oleh R Fagin pada tahun 1981 dan bersifat sangat spesifik, artinya tidak semua
relasi dapat mencapai level ini.
1111..1100..33.. CCoonnttoohh PPrroosseess NNoorrmmaalliissaassii
Untuk membantu pemahaman tentang bentuki dan proses normalisasi berikut
diberikan tiga contoh relasi dalam bentuk tidak normal dan kemudian secara
bertahap diubah hingga menjadi optimal dalam bentuk 3NF. Contoh-contoh relasi
yang digunakan sengaja dibuat sederhana untuk memfokuskan pemahaman
pada bentuk dan proses normalisasi, bukan difokuskan pada kelengkapan data
sesuai kondisi real di lapangan.
Contoh pertama menggunakan relasi sumber Supllier, yang digunakan untuk
mencatat data supplier dan pengiriman barang dari suppplier. Contoh kedua
menggunakan relasi sumber KRS, yang digunakan untuk mencatat data
mahasiswa dan mata kuliah yang diikutinya. Secara berturut-turut relasi sumber
hingga hasil akhir yang diperoleh untuk dua contoh tersebut ditampilkan dalam
Tabel 11.16 hingga Tabel 11.28.
38
Contoh 1: Tabel 11.16: Relasi Supplier dalam bentuk UNF
Kode_Supplier Status Kota Kode_Barang Jumlah_Barang S01 10 Jakarta B01 100
B02 150 B03 200
S02 20 Surabaya B02 250 B04 200
S03 30 Yogyakarta B05 150 B06 100
Catatan:
Relasi Supplier pada Tabel 11.16 termasuk UNF karena dicatat sesuai
kedatangan data dan tidak memenuhi kriteria flat file.
Tabel 11.17: Relasi Supplier_1 dalam bentuk 1NF
Kode_Supplier Status Kota Kode_Barang Jumlah_Barang S01 10 Jakarta B01 100 S01 10 Jakarta B02 150 S01 10 Jakarta B03 200 S02 20 Surabaya B02 250 S02 20 Surabaya B04 200 S03 30 Yogyakarta B05 150 S03 30 Yogyakarta B06 100
Catatan:
Relasi Supplier_1 pada Tabel 11.17 merupakan hasil modifikasi relasi Supplier
pada Tabel 11.16 dengan cara melengkapi nilai-nilai rinci data dalam relasi guna
memenuhi kriteria bentuk 1NF. Sebagai pelengkap, Gambar 11.9 menunjukkan
diagram ketergantungan data dalam relasi Supplier_1.
Kode Supplier
Kode Barang
Status
Jumlah Barang
Kota
Gambar 11.9: Ketergantungan data dalam relasi Supplier_1
Permasalahan yang muncul dalam relasi Supplier_1 dalam bentuk 1NF adalah
sebagai berikut:
39
a. Tidak dapat menyisipkan informasi parsial, misal ada supplier baru yang
datang dan belum pernah mensupplai barang sama sekali, maka supplier
baru tersebut tidak dapat dientrikan dalam relasi (mengakibatkan non flat file)
b. Terhapusnya informasi ketika menghapus sebuah record, misal supplier
dengn Kode_Supplier S02 tidak pernah mensupplai barang lagi, maka record
tentang supplier dengan Kode_Supplier S02 tersebut akan dihapus dari
relasi. Akibatnya kita akan kehilangan seluruh informasi tentang barang yang
pernah dikirim oleh supplier dengan Kode_Supplier S02
c. Pembaharuan atribut non kunci mengakibatkan sejumlah record harus
diperbaharui, misal alamat supplier dengan kode S01 pindah ke Bandung,
maka seluruh record dengan Kode_Supplier S01 harus diubah. Jika terlewat
atau tidak dilakukan, maka akan mengakibatkan munculnya data yang tidak
konsisten
Tabel 11.18: Relasi Supplier_2 dalam bentuk 2NF
Kode_Supplier Status Kota S1 10 Jakarta S2 20 Surabaya S3 30 Yogyakarta
Tabel 11.19: Relasi Barang
Kode_Supplier Kode_Barang Jumlah_Barang S1 P1 100 S1 P1 95 S2 P2 75 S2 P2 70 S3 P3 60 S3 P3 50
Catatan:
Relasi Supplier_1 dalam bentuk 1NF pada Tabel 11.17 dipecah menjadi dua
relasi baru menjadi bentuk 2NF yang diberi nama Supplier_2 pada Tabel 11.18
dan relasi Barang pada Tabel 11.19. Atribut Kode_Supplier dalam relasi Barang,
diperlukan sebagai FK yang mereferensi ke relasi Supplier_2, agar relasi-relasi
baru yang terbentuk tetap saling berhubungan. Pemecahan relasi tersebut
dilakukan berdasarkan ketergantungan data yang terjadi dalam relasi Supplier_1
40
seperti ditampilkan pada Gambar 11.9. Relasi Supplier_2 telah memenuhi kriteria
relasi bentuk 2NF, tetapi atribut-atribut di dalamnya masih mengalami TDF.
Permasalahan dalam 2NF adalah sebagai berikut:
a. Kerangkapan data masih terjadi pada atribut yang mengalami TDF, yaitu
pada atribut Status (kerangkapan dalam satu relasi)
b. Pembaharuan yang tidak benar dapat menimbulkan inkonsistensi data
c. Proses pembaharuan data tidak efisien
d. Penyimpangan / permasalahan pada saat penyisipan, penghapusan dan
pembaharuan
Tabel 11.20: Relasi Supplier_3 dalam bentuk 3NF
Kode_Supplier Status S1 10 S2 20 S3 30
Tabel 11.21: Relasi Kota
Status Kota 10 Jakarta 20 Surabaya 30 Yogyakarta
Catatan:
Relasi Supplier_3 pada Tabel 11.20 dan relasi Kota pada Tabel 11.21
merupakan hasil pemecahan relasi Supplier_2 yang mengalami ketergantungan
transitif pada atribut-atribut Kode_Supplier, Status, dan Kota.
Hasil akhir dari proses normalisasi dalam contoh 1 ini adalah tiga buah relasi
baru, yaitu Supplier_3, Kota, dan Status. Diagram kerelasian antar ketiga relasi
tersebut ditampilkan pada Gambar 11.10
41
Gambar 11.10: Diagram kerelasian antar relasi hasil normalisasi (contoh 1)
Contoh 2:
Tabel 11.22: Relasi KRS dalam bentuk UNF
NIM Nama_ Mahasiswa
Kode_ MK_1
Sks_1 Tahun_Smt_1
Kode_ MK_2
Sks_2 Tahun_Smt_2
001 Koko MK01 2 20021 MK02 2 20022 002 Kiki MK01 2 20021 MK02 2 20022 003 Kiko MK01 2 20031 MK03 2 20032 004 Koki MK01 2 20031 MK04 2 20032
Catatan:
Relasi KRS berada dalam bentuk UNF karena memuat set atribut berulang, yaitu
Kode mata kuliah, tahun semester, dan Sks. Selanjutnya, hasil proses
normalisasi bentuk 1NF diberi nama relasi KRS_1 dan ditampilkan pada Tabel
11.23. Proses yang dilakukan adalah mengubah struktur relasi, dimana set
atribut berulang diubah susunannya dari horisontal menjadi vertikal.
Tabel 11.23: Relasi KRS_1 dalam bentuk 1NF
NIM Nama_Mahasiswa Kode_MK Sks Tahun_Smt 001 Koko MK01 2 20021 001 Koko MK02 2 20022 002 Kiki MK01 2 20021 002 Kiki MK02 2 20022 003 Kiko MK01 2 20031 003 Kiko MK03 2 20032 004 Koki MK01 2 20031 004 Koki MK04 2 20032
Kode_Supplier * Status **
Supplier_3
Kode_Supplier * Kode_Barang * Jumlah_Barang
Barang Kota
Status * Kota
42
Diagram ketergantungan data untuk relasi KRS_1 ditampilkan pada Gambar
11.11.
Tahun_Smt
Nama_Mahasiswa
Sks
NIM
Kode_MK
Gambar 11.11: Diagram ketergantungan data pada relasi KRS
Relasi KRS_1 pada Tabel 11.23, selanjutnya dipecah menghasilkan dua relasi
baru, yaitu KRS_2 dan Mahasiswa yang ditampilkan pada Tabel 11.24 dan Tabel
11.25.
Tabel 11.24: Relasi KRS_2 dalam bentuk 2NF
NIM Kode_MK Sks Tahun_Smt001 MK01 2 20021 001 MK02 2 20022 002 MK01 2 20021 002 MK02 2 20022 003 MK01 2 20031 003 MK03 2 20032 004 MK01 2 20031 004 MK04 2 20032
Tabel 11.25: Relasi Mahasiswa
NIM Nama_Mahasiswa001 Koko 002 Kiki 003 Kiko 004 Koki
Catatan:
Relasi KRS_2 pada Tabel 11.24 masih mengalami ketergantungan transitif, yaitu
Nim, Kode_MK, dan Sks, sehingga perlu dipecah kembali. Hasilnya adalah dua
relasi baru, yaitu relasi KRS_3 yang ditampilkan pada Tabel 11.26 dan relasi
Mata_Kuliah yang ditampilkan pada Tabel 11.27.
43
Tabel 11.26: Relasi KRS_3 dalam bentuk 3NF
NIM Kode_MK Tahun_Smt001 MK01 20021 001 MK02 20022 002 MK01 20021 002 MK02 20022 003 MK01 20031 003 MK03 20032 004 MK01 20031 004 MK04 20032
Tabel 11.27: Relasi Mata_Kuliah
Kode_MK SksMK01 2 MK02 2 MK03 2 MK04 2
Hasil akhir dari proses normalisasi dalam contoh 2 ini adalah tiga buah relasi
baru, yaitu KRS_3, Mahasiswa, dan Mata_Kuliah. Diagram kerelasian antar
ketiga relasi tersebut ditampilkan pada Gambar 11.12.
Gambar 11.12: Diagram kerelasian antar relasi hasil normalisasi (contoh 2)
NIM * Kode_MK * Tahun_Smt *
KRS_3
NIM * Nama_Mahasiswa
Mahasiswa Mata_Kuliah
Kode_MK * Sks
44
1111..1100..44.. EEffeekk NNoorrmmaalliissaassii
Sebagaimana terjadi pada hampir semua usaha pemecahan permasalahan,
(tidak hanya terbatas pada basis data) akan menimbulkan efek samping yang
negatif. Pada kenyataannya, penerapan normalisasi juga mengakibatkakn efek
samping yang tidak diharapkan, yaitu:
1. Proses dekomposisi relasi akan mengakibatkan munculnya duplikasi rinci
data pada atribut kunci penghubung (foreign key)
2. Dekomposisi relasi membuka kemungkinan tidak terpenuhinya integritas
referensial (referential integrity) dalam basis data
3. Dekomposisi relasi akan menghasilkan semakin banyak jumlah relasi baru,
sehingga mengakibatkan inefisiensi proses menampilkan kembali data-data
dari dalam basis data
4. Adanya batasan penerapan pada beberapa DBMS untuk ukuran komputer
pribadi / PC, berkaitan dengan batas maksimal relasi yang dapat dibuka
secara bersamaan
1
BBAABB XXIIII.. SSCCHHEEMMAA DDAANN SSUUBBSSCCHHEEMMAA
1122..11.. DDeeffiinniissii SScchheemmaa ddaann SSuubbsscchheemmaa
Jika fungsi basis data hanya untuk menyimpan data saja, maka akan sederhana.
Kenyataanya, kerelasian antar data yang disimpan dalam basis data sangatlah
komleks. Suatu schema dan subschema diperlukan untuk menggambarkan /
mendeskripsikan hubungan logik antar data dalam basis data.
Schema memberikan deskripsi hubungan logik antar data dalam basis data
secara lengkap, termasuk di dalamnya nama dan deskripsi dari semua atribut,
record, dan batasan nilai untuk semua aplikasi yang menggunakan basis data
tersebut. Sedangkan subschema merupakan deskripsi terpisah dari atribut,
record, dan batasan nilai yang akan digunakan oleh sebuah program aplikasi.
Dengan demikian, dari sebuah schema dapat diturunkan ke dalam beberapa
subschema. Suatu schema menunjukkan pandangan konseptual seorang
perancang, sedangkan subschema menunjukkan pandangan seorang application
programer terhadap data yang digunakannya.
1122..22.. SScchheemmaa,, SSuubbsscchheemmaa,, MMooddeell DDaattaa,, ddaann DDiiaaggrraamm KKeerreellaassiiaann AAnnttaarr RReellaassii
Schema, subschema, data model, dan diagram kerelasian antar relasi sama-
sama digunakan untuk menunjukkan hubungan logik antar data dalam basis
data. Sekalipun demikian, terdapat perbedaan di antara keempatnya.
Schema dan subschema lebih banyak digunakan untuk para perancang basis
data, pada level konseptual. Schema dan subschema akan dijadikan acuan pada
saat perancangan struktur-struktur relasi yang akan dikembangkan. Suatau
schema digunakan pada lingkup sistem / organisasi secara keseluruhan (basis
2
data). Sedangkan subschema digunakan pada lingkup aplikasi tertentu. Jadi
sebuah schema merupakan hasil gabungan beberapa subschema.
Model data digunakan sebagai sarana untuk mengkomunikasikan rancangan
basis data yang lebih ditujukan kepada para pemakai basis data. Model data
dapat terdiri atas beberapa model (lihat pembahasan pada BAB VI). Sedangkan
diagram kerelasian antar relasi merupakan diagram yang menunjukkan
hubungan antar data dalam basis data, yang secara khusus digunakan pada
model relasional / RDBM. Diagram kerelasian antar relasi tersusun atas relasi,
atribut dalam setiap relasi, dan kerelasian yang terjadi di antara relasi-relasi.
Diagram tersebut memuat seluruh relasi yang digunakan, bisa dalam lingkup
sistem secara keseluruhan atau hanya dalam lingkup aplikasi tertentu saja.
1122..33.. NNoottaassii RReellaassii,, SScchheemmaa,, ddaann SSuubbsscchheemmaa
1. Notasi relasi Sebuah relasi dalam model relasional / RDBM direpresentasikan sebagai sebuah
tabel. Sebuah relasi yang ditampilkan dalam bentuk tabel memuat beberapa
keterangan, yaitu:
1. Nama relasi
2. Kunci-kunci relasi (tidak selalu dituliskan)
3. Kunci-kunci indeks (tidak selalu dituliskan)
4. Sejumlah record (elemen data / entri yang disusun dalam bentuk baris-
baris data)
5. Nama-nama atribut
Representasi relasi dalam bentuk tabel tersebut relatif mudah dipahami,
khususnya oleh para pemakai.
Namun, seringkali bentuk tersebut menjadi terlalu banyak memerlukan tempat
untuk menampilkannya, sehingga diperlukan cara yang lebih ringkas untuk
menampilkan relasi tersebut. Dan seringkali batasan nilai pada setiap atribut
justru lebih diperlukan daripada nilai-nilai elemen data / entri yang
sesungguhnya, baik oleh pemakai maupun perancang (khususnya untuk
3
kebutuhan perancangan struktur relasi pada tahap selanjutnya). Dengan alasan-
alasan itu, maka relasi-relasi dalam basis data dapat dituliskan dalam bentuk
yang lain, yaitu menggunakan notasi relasi. Dan pada umumnya, untuk
menyatakan atribut PK dalam relasi ditandai dengan tanda # (Ingat: dalam
diagram kerelasian antar relasi PK ditandai dengan tanda *). Notasi relasi dapat
dituliskan dengan format sebagai berikut:
R_namarelasi : (namaatribut1#, namaatribut2, namaatribut3, .., namaatributn)
Keterangan:
R : menyatakan sebuah relasi
namarelasi : menyatakan nama relasi
namaatribut1,.. n : menyatakan nama-nama aribut yang dituliskan
secara
berurutan dari kiri ke kanan
# : menyatakan PK dalam relasi
Notasi relasi tersebut perlu dilengkapi dengan batasan untuk domain pada setiap
atribut, yaitu dinyatakan dengan format sebagai berikut:
Domain_namarelasi : (tipe[ukuran]1, tipe[ukuran]2, tipe[ukuran]3 .., tipe[ukuran]n)
Keterangan:
Domain : menyatakan batasan nilai sebuah relasi
namarelasi : menyatakan nama relasi
tipe[ukuran]1, ..n : menyatakan batasan domain pada setiap atribut
yang dituliskan secara berurutan dari kiri ke kanan
sesuai urutan nama atribut dalam relasi
Jadi sebuah relasi dalam bentuk tabel dapat dinyatakan dalam bentuk notasi
relasi dan batasan domainnya.
Berikut diberikan contoh sebuah relasi Mata_Kuliah yang ditampilkan dalam
bentuk tabel, dan kemudian dituliskan notasi relasinya. Relasi Mata_Kuliah
memuat lima buah atribut, yaitu :
4
⇒ Kode_Mata_Kuliah dengan tipe data character (sekalipun berisi
angka-angka) dengan ukuran 8 character
⇒ Nama_Mata_Kuliah dengan tipe data character dengan ukuran 50
character
⇒ SKS dengan tipe numeric (berisi angka) dengan ukuran 1 digit
⇒ Semester dengan tipe numeric (berisi angka) dengan ukuran 1 digit
⇒ Status dengan tipe character (berisi charcter) dengan ukuran 1
character
Relasi Mata_Kuliah menggunakan Kode_Mata_Kuliah sebagai PK. Selanjutnya
relasi Mahasiswa dalam contoh tersebut ditampilkan pada Tabel 12.1
Tabel 12.1: Relasi Mata_Kuliah
Kode_Mata_Kuliah Nama_Mata_Kuliah SKS Semester Status MK-1001 Pemrograman I 2 1 W MK-2002 Pemrograman II 2 2 W MK-3003 Pemrograman III 2 3 W
Relasi Mata_Kuliah dalam Tabel 12.1, selanjutnya dapat dituliskan dalam notasi
relasi sebagai berikut:
R_Mata_Kuliah : (Kode_Mata_Kuliah#, Nama_Mata_Kuliah, SKS, Semester,
Status)
Domain_Mata_Kuliah : (Char[8], char[50], num[1], num[1], char[1])
2. Notasi schema dan subschema Penyebutan schema dan subschema hanya berbeda pada lingkupnya saja. Jika
data dan kerelasian yang digambarkan berada pada lingkup sistem / organisasi
secara keseluruhan, maka disebut schema. Tetapi jika data dan kerelasian yang
digambarkan berada pada lingkup sebuah aplikasi saja / subsistem, maka
disebut subschema. Penulisan notasi untuk schema dan subschema dilakukan
dengan cara / format yang sama.
Notasi schema atau subschema dapat dituliskan dengan format sebagai berikut:
5
namarelasi_schema : (namaatribut1 tipe[ukuran]1, namaatribut2 tipe[ukuran]2,
...., namaatributn tipe[ukuran]n, foreign key (namaatributfk)
references namarelasiinduk, primary key (namaatributpk))
Keterangan:
namarelasi : menyatakan nama relasi
schema : menyatakan schema (bisa juga subschema)
namaatribut1, .. n : menyatakan nama-nama atribut dalam relasi yang
dituliskan secara berurutan dari kiri ke kanan
tipe[ukuran]1, ..n : menyatakan batasan domain pada setiap atribut
yang dituliskan secara berurutan dari kiri ke kanan
sesuai urutan nama atribut dalam relasi
foreign key : menyatakan foreign key
namaatributFK : menyatakan nama atribut yang digunakan sebagai FK
untuk menghubungkan dengan relasi induknya
references : menyatakan mereferensi ke
namarelasiinduk : menyatakan nama relasi induk yang direferensi
primary Key : menyatakan primary key
namaatributPK : menyatakan nama atribut yang digunakan sebagai PK
dalam relasi
Untuk menjaga integritas data (baik secara kesatun maupun referensial), maka
batasn-batasan nilai elemen data pada atribut, FK, maupun PK dapat diberikan /
dituliskan dalam notasi schema / subschema. Batasan tersebut dapat berupa
nilai dasar (default value), batasan nilai (range), atau batasan tidak boleh kosong
(not null).
Secara konsep nilai-nilai elemen data / entri pada PK dan pada PK yang diacu
oleh FK tidak boleh null. Dengan demikian, maka dapat dberikan batasan not
null. Namun demikian, integritas kesatuan telah diset secara langsung oleh
DBMS, sehingga batasan not null pada atribut PK tidak perlu dituliskan lagi.
Untuk memberikan jaminan relasi flat file, maka nilai-nilai elemen data / entri
pada atribut-atribut dalam relasi sebenarnya juga tidak boleh null. Hal ini ternyata
lebih mudah dilakukan melalui program aplikasi yang digunakan. Dengan
6
demikian, maka batasan not null untuk setiap atribut juga tidak harus selalu
dituliskan.
Untuk memberikan contoh penulisan schema (bisa juga disebut subschema),
contoh relasi Mata_Kuliah pada Tabel 12.1 akan digunakan kembali dan
ditambahkan tiga relasi baru, yaitu Mahasiswa pada Tabel 12.2 dan relasi KRS
padaTabel 12.3, dan relasi KHS pada Tabel 12.4. Schema (bisa juga disebut
subschema) untuk ketiga relasi tersebut dapat dituliskan sebagai berikut:
Mata_Kuliah_Schema: (Kode_Mata_Kuliah Char[8], Nama_Mata_Kuliah Char[50], SKS Num[1], Semester Num[1], Status Char[1], Primary Key (Kode_Mata_Kuliah))
Mahasiswa_Schema: (NIM[8], Nama Char[50], Alamat Char[50], Primary Key
(NIM)) KRS_Schema : (NIM[8], Kode_Mata_Kuliah Char[8], Tahun_Semester Char[5],
Foreign Key (NIM) references Mahasiswa not null, foreign Key(Kode_Mata_Kuliah) references Mata_Kuliah not null, Primary Key (NIM, Kode_Mata_Kuliah, Tahun_Semester))
KHS_Schema : (NIM[8], Kode_Mata_Kuliah Char[8], Tahun_Semester Char[5],
Nilai Char[1], Foreign Key(NIM, Kode_Mata_Kuliah, Tahun_Semester) references KRS not null, Primary Key (NIM, Kode_Mata_Kuliah, Tahun_Semester))
Tabel 12.2: Relasi Mahasiswa
NIM Nama_Mahasiswa Alamat
02050001 Rita Jl. Mawar no. 1 Yogyakarta 02050002 Rina Jl. Melati no. 2 Yogyakarta 02050003 Rini Jl. Menur no. 3 Yogyakarta
Tabel 12.3. Relasi KRS
NIM Kode_Mata_Kuliah Tahun_Semester 02050001 MK-11001 200220031 02050001 MK-12002 200220032 02050002 MK-11001 200320041 02050002 MK-13003 200320041 02050003 MK-11001 200220031 02050003 MK-12002 200220032
7
Tabel 12.4. Relasi KHS NIM Kode_Mata_Kuliah Tahun_Semester Nilai 02050001 MK-11001 200220031 A 02050001 MK-12002 200220032 B 02050002 MK-11001 200320041 B 02050002 MK-13003 200320041 B 02050003 MK-11001 200220031 A 02050003 MK-12002 200220032 C
1122..44.. IInnssttaannccee SScchheemmaa
Instance schema menunjukkan isian nilai-nilai aktual elemen data / entri dalam
setiap relasi. Instance schema diperlukan untuk menunjukkan nilai data
sesungguhnya yang ada di dalam schema (atau subschema). Pasangan-
pasangan keterangan yang sering digunakan untuk menjelaskan basis data
dapat dipilih salah satu dari pasangan berikut:
1. Diagram ER atau semantic, struktur relasi, diagram kerelasian antar relasi
2. Relasi, struktur relasi, diagram kerelasian antar relasi
3. Notasi relasi dan batasan domain relasi, schema / subschema, instance
schema
Dalam hal basis data dijelaskan menggunakan pasangan keterangan dalam
pilihan ketiga seperti di atas, maka instance schema menjadi diperlukan.
Instance schema sebenarnya adalah sama dengan relasi yang
direpresentasikan dalam bentuk tabel. Dengan demikian, instance schema
Mata_Kuliah, Mahasiswa, KRS, dan KHS yang dituliskan dalam schema pada
contoh di atas, tampilannya adalah persis sama dengan apa yang ditampilkan
dalam Tabel 12.1, Tabel 12.2, tabel 12.3, dan Tabel 12.4. Sehingga, di sini tidak
perlu dituliskan kembali.
1
BBAABB XXIIIIII.. SSTTUUDDII KKAASSUUSS :: RRAANNCCAANNGGAANN BBAASSIISS DDAATTAA
1133..11.. TTeekknniikk ddaann LLaannggkkaahh PPeerraannccaannggaann BBaassiiss DDaattaa
Perancangan basis data merupakan bagian dari kegiatan besar dalam rangka
pengembangan Sistem Informasi Manajemen / SIM, khususnya pada tahap
perancangan. SIM tersusun atas sekumpulan subsistem pengolahan data.
Seiring dengan perkembangan teknologi informasi dan komputer yang sangat
cepat, maka SIM (di dalamnya memuat subsistem-subsistem pengolahan data)
telah berubah dari metoda manual atau elektromekanikal menjadi sistem
informasi berbasis komputer (Computer Based Information Systems / CBIS)
yang modern. Pembahasan secara lebih terinci mengenai konsep SIM, konsep
CBIS, perancangan SIM, serta teknik analisis dan desain SIM dapat dijumpai
dalam buku Sistem Informasi Manajemen yang telah lebih dahulu muncul oleh
penulis dan penerbit yang sama.
Perancangan basis data dilakukan dengan menentukan kebutuhan file - file
dalam basis data berdasarkan model sistem. Model sistem tersebut ditunjukkan
oleh Diagram Aliran Data / DAD (Data Flow Diagram / DFD) sistem baru yang
telah dibuat pada tahap sebelumnya. Selanjutnya, parameter-parameter file
dalam basis data perlu ditentukan. Setelah kebutuhan - kebutuhan file - file
tersebut diketahui, maka dilakukan pendefinisian struktur file basis data. Struktur
file basis data tergantung dari data yang masuk dan hasil keluaran yang
diinginkan. Dari analisis arus data yang masuk dan hasil keluaran, maka suatu
file dapat didefinisikan strukturnya. Dan selanjutnya perlu dikaji kerelasian antar
file dalam basis data. Hubungan antar file dalam basis data dikendalikan oleh
suatu kunci penghubung (foreign key).
Perancangan basis data dapat dilakukan menggunakan teknik Entity
Relationship atau teknik normalisasi (dalam model basis data relasional).
Perancangan dengan teknik Entity Relationship akan menghasilkan sebuah
diagram yang disebut Entity Relationship Diagram / ER_D. Sedangkan teknik
2
normalisasi diterapkan dalam perancangan basis data dalam model basis data
relasional.
Langkah yang dilakukan untuk perancangan basis data adalah sebagai berikut:
1. Menentukan kebutuhan file basis data untuk sistem baru,
File yang dibutuhkan ditunjukkan dalam DAD, yaitu pada simbol data store.
Field - field yang diperlukan dapat dilihat dari struktur data pada kamus data
yang menjelaskan arus data yang mengarah ke data store
2. Menentukan parameter file basis data
Parameter file basis data meliputi tipe file, nama atribut, tipe dan ukuran,
serta kunci relasi
3. Normalisasi file basis data
Langkah ini dimaksudkan untuk pengujian pada setiap file dengan harapan
dapat menghindari permasalahan-permasalahan yang mungkin terjadi.
4. Optimalisasi file basis data
Optimalisasi file basis data diperlukan dengan tujuan memperoleh unjuk kerja
basis data yang efisien (misal penggunaan kode, penentuan tipe dan ukuran
atribut, dll)
Proses perancangan basis data harus selalu didasarkan pada batasan dan
persyaratan yang harus dipenuhi sesuai konsep basis data. Sekalipun sistem
yang dikembangkan hanya sebagian dari SIM, tetapi proses perancangan basis
data harus didasarkan pada sistem / organisasi secara menyeluruh, bukan
didasarkan pada aplikasi tertentu yang akan dikembangkan saja. Hal ini sangat
penting diperhatikan, karena perancangan basis data harus dilakukan pada
level konseptual (dalam abstraksi basis data) yang memungkinkan digunakan
untuk seluruh bagian dalam SIM, untuk jangka waktu yang lama, dan untuk
semua level manajemen.
Jika perancangan basis data hanya didasarkan pada suatu aplikasi tertentu
saja, maka berbagai batasan dalam konsep basis data tidak akan dapat
terpenuhi, kerangkapan data akan sering terjadi, tidak dapat diakses oleh
banyak pemakai, dan tidak dapat memenuhi kebutuhan-kebutuhan baru.
3
1133..22.. CCoonnttoohh RRaannccaannggaann BBaassiiss DDaattaa
Sekalipun tidak mungkin untuk dapat merancang basis data yang mampu
memenuhi kebutuhan pada sebuah organissi secara tepat tanpa melakukan
proses analis yang mendalam, berikut ini akan ditampilkan dua contoh
rancangan basis data sebatas dalam lingkup sebuah subsistem. Contoh
rancangan basis data yang diberikan masih sebatas pada kebutuhan dasar
yang bersifat minimal, sangat umum, dan vital. Kebutuhan lain yang lebih
kompleks akan sangat tergantung pada hasil analisis sistem yang dilakukan
pada tahapan analisis sistem.
Contoh di sini diberikan dengan maksud sekedar memberikan gambaran
rancangan minimal yang dapat dikembangkan lebih lanjut sesuai sistem yang
sesungguhnya. Dan contoh yang diberikan di sini tentu saja tidak dapat
diadobsi begitu saja pada organisasi pemakai, sebelum dilakukan penyesuaian
terlebih dahulu.
1133..22..11.. SSuubbssiisstteemm PPeennggoollaahhaann DDaattaa AAkkaaddeemmiikk
Rancangan basis data pada susbsistem akademik ini sebatas digunakan pada
aktivitas dasar dalam kegiatan akademik, yang meliputi:
1. Kegiatan perencanaan studi mahasiwa
2. Kegiatan perkuliahan
3. Perolehan nilai mahasiswa
Sekalipun sangat dekat dan memiliki keterkaitan langsung, kegiatan-kegiatan
lain seperti penerimaan mahasiswa baru, heregisterasi, pembatasan jumlah
SKS yang diambil, pengendalian materi dan tatap muka dosen di kelas, tugas
kuliah, rincian kegiatan praktikum, rincian kegiatan kerja praktek, rincian
kegiatan Kuliah Kerja Nyata, rincian kegiatan penyelesaian Tugas Akhir, rincian
pembayaran beaya studi, kegiatan kemahasiswaan, pendidikan SLTA, dan
banyak kebutuhan yang lainnya belum diakomodasi dalam rancangan ini.
4
Sekali lagi bahwa contoh rancangan basis data yang ditampilkan berikut ini
masih sangat mendasar dan minim dibandingkan dengan kebutuhan yang
sesungguhnya. Rancangan basis data yang sesungguhnya tentu saja hanya
dapat dilakukan setelah melalui proses analisis yang sangat lama dan cermat.
Contoh rancangan yang ditampilkan tidak dilakukan secara terperinci dan
mengikuti langkah perancangan basis data, namun merupakan hasil akhir yang
mempertimbangkan setiap langkah dalam perancangan basis data seperti telah
dituliskan di atas. Sekalipun demikian, ide-ide pemikiran yang menjadi
pertimbangan yang berkaitan dengan rancangan file basis data dalam contoh ini
bisa digunakan sebagai contoh bahwa perancangan basis data perlu
mempertimbangkan berbagai kemungkinan yang sangat mungkin terjadi.
Misal, NIM mahasiswa umumnya tersusun atas kode-kode tertentu, misal
angkatan, jenjang studi, jurusan / program studi, nomor urut. Program studi
berada dalam suatu Jurusan, dan Jurusan berada di bawah Fakultas, padahal
fakultas, Jurusan, dan program studi sangat mungkin mengalami perubahan
(bertambah, ganti, atau berkurang). Dengan demikian, pencermatan terhadap
NIM mahasiswa harus memikirkan kemungkinan-kemungkinan yang
berhubungan dengan program studi, jurusan, dan fakultas. Jenjang pendidikan
yang diselenggarakan juga sangat mungkin berubah, misal penambahan
jenjang studi baru.
Pertimbangan lain misalnya, alamat asal mahasiswa perlu dicatat untuk
kepentingan mengatahui daerah asal yang potensial. Pencatatan alamat asal
perlu memikirkan tentang kabupaten dan propinsi asal mahasiswa. Akhir-akhir
ini, ternyata jumlah propinsi di Indonesia telah mengalami perubahan.
Perubahan propinsi berakibat pada perubahan kabupaten / kodya. Kabupaten /
kodya yang dahulu masuk sebagai bagian propinsi tertentu sekarang telah
berubah menjadi bagian propinsi lain, karena perubahan propinsi. Demikian,
juga haknya dengan kurikulum dan status mata kuliah dalam kurikulum yang
terus mengalami perubahan. Dan masih banyak kemungkinan lain yang dapat
terjadi. Ide-ide sederhana dan mendasar yang muncul dalam contoh rancangan
5
inilah yang diharapkan dapat ditangkap oleh Pembaca saat akan melakukan
perancangan basis data. Penentuan tipe dan ukuran atribut juga perlu
diperhatikan.
Struktur File Untuk Subsistem Pengolahan Data Akademik
Tabel 14.1: Relasi Mahasiswa_Master Tipe : Master PK : Angkatan+Jenjang_Studi+Jurusan+Nomor No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Nama_Mahasiswa Char 100 7 Tanggal_Masuk Date 8 Pendidikan Char 2 9 Agama Char 1 10 Alamat_Lokal Char 50 11 Alamat_Asal Char 50 12 Kabupaten Char 2 13 Status_Mahasiswa Char 1
Tabel 14.2: Relasi Angkatan_Master Tipe : Master PK : Angkatan
No Nama field Tipe Ukuran 1 Angkatan Num 4 2 Tahun_Angkatan Num 9 3 Semester_Angkatan Num 1
Tabel 14.3: Jenjang_Studi_Master Tipe : Master PK : Jenjang_Studi
No Nama field Tipe Ukuran 1 Jenjang_Studi Char 1 2 Nama_Jenjang_Studi Char 12 3 Jenis Char 1
6
Tabel 14.4: Relasi Program_Studi_Master Tipe : Master PK : Jurusan
No Nama field Tipe Ukuran1 Program_Studi Char 2 2 Nama_Program_Studi Char 50 3 Tanggal_Berdiri Date 4 Tanggal_SK Date 5 No_SK Char 50 6 Status_Program_Studi Char 1 7 Jurusan Char 2
Tabel 14.5: Relasi Jurusan_Master Tipe : Master PK : Jurusan
No Nama field Tipe Ukuran1 Jurusan Char 2 2 Nama_Jurusan Char 20 3 Tanggal_Berdiri Date 4 Tanggal_SK Date 5 No_SK Char 50 6 Status_Program_Studi Char 1 7 Fakultas Char 1
Tabel 14.6: Relasi Fakultas_Master Tipe : Master PK : Fakultas
No Nama field Tipe Ukuran1 Fakultas Char 2 2 Nama_Fakultas Char 20 3 Tanggal_Berdiri Date 4 Tanggal_SK Date 5 No_SK Char 50
Tabel 14.7: Relasi Program_Master Tipe : Master PK : Program
No Nama field Tipe Ukuran1 Program Char 2 2 Nama_Program Char 20
7
Tabel 14.8: Relasi Pendidikan_Master Tipe : Master PK : Pendidikan
No Nama field Tipe Ukuran1 Pendidikan Char 2 2 Nama_Pendidikan Char 20
Tabel 14.9: Relasi Agama_Master Tipe : Master PK : Agama
No Nama field Tipe Ukuran1 Agama Char 1 2 Nama_Agama Char 20
Tabel 14.10: Relasi Kabupaten_Master Tipe : Master PK : Kabupaten
No Nama field Tipe Ukuran1 Kabupaten Char 2 2 Nama_Kabupaten Char 50 3 Propinsi Char 2
Tabel 14.11: Relasi Propinsi_Master Tipe : Master PK : Propinsi
No Nama field Tipe Ukuran1 Propinsi Char 2 2 Nama_Propinsi Char 50
Tabel 14.12: Relasi Status_Program_Studi_Master Tipe : Master PK : Status_Program_Studi
No Nama field Tipe Ukuran1 Status_Program_Studi Char 1 2 Nama_Status_Program_Studi Char 50
Tabel 14.13: Relasi Bidang_Master Tipe : Master PK : Bidang
No Nama field Tipe Ukuran 1 Bidang Char 2 2 Nama_Bidang Char 50
8
Tabel 14.14: Relasi Dosen_Tetap_Master Tipe : Master PK : Kode_Dosen
No Nama field Tipe Ukuran1 Kode_Dosen Char 8 2 NIK_NIP Char 8 3 Nama_Dosen Char 100 4 Tanggal_Masuk Date 5 Pendidikan Char 2 6 Bidang Char 2 7 Agama Char 1 8 Alamat_Dosen Char 50 9 Kode_Pos Char 5 10 Kabupaten Char 2 11 Agama Char 1 12 Golongan Char 1 13 Jabatan_Akademik Char 1 14 Telepon Char 12 15 Telepon_HP Char 20
Tabel 14.15: Relasi Golongan_Master Tipe : Master PK : Golongan
No Nama field Tipe Ukuran 1 Golongan Char 1 2 Nama_Golongan Char 50 3 Gaji_Pokok Num 7
Tabel 14.16: Relasi Jabatan_Akademik_Master Tipe : Master PK : Jabatan_Akademik
No Nama field Tipe Ukuran1 Jabatan_Akademik Char 1 2 Nama_Jabatan_Akademik Char 50 3 Angka_Kredit Num 4
9
Tabel 14.17: Relasi Dosen_Tidak_Tetap_Master Tipe : Master PK : Kode_Dosen
No Nama field Tipe Ukuran1 Kode_Dosen Char 8 2 NIP_NIK Char 20 3 Nama_Dosen Char 100 4 Alamat_Dosen Char 50 5 Kode_Pos Char 5 6 Pendidikan Char 2 7 Bidang Char 2 8 Instansi_Asal Char 50 9 Agama Char 1 10 Kabupaten Char 2 11 Golongan Char 1 12 Jabatan_Akademik Char 1 13 Telepon Char 12 14 Telepon_HP Char 20
Tabel 14.18: Relasi Kurikulum_Master Tipe : Master PK : Kurikulum
No Nama field Tipe Ukuran 1 Kurikulum Char 4 2 Tanggal_SK_Kurikulum Date 3 Nomor_SK_Kurikulum Char 50 4 SKS_Wajib Num 3 5 SKS_Minat Num 2 6 SKS_Pilihan Num 2 7 SKS_Total_Minimal Num 3
Tabel 14.19: Relasi Mata_Kuliah_Master Tipe : Master PK : Kode_Mata_Kuliah
No Nama field Tipe Ukuran 1 Kode_Mata_Kuliah Char 8 2 Nama_Mata_Kuliah Char 50 3 SKS Num 1 4 Semester Num 1 5 Kelompok_Mata_Kuliah Char 1 6 Status_Mata_Kuliah Char 1 7 Jenis_Mata_Kuliah Char 1 8 Kurikulum Char 4
10
Tabel 14.20: Relasi Kelompok_Mata_Kuliah_Master Tipe : Master PK : Kelompok_Mata_Kuliah
No Nama field Tipe Ukuran1 Kelompok_Mata_Kuliah Char 1 2 Nama_Kelompok_Mata_Kuliah Char 50
Tabel 14.21: Relasi Status_Mata_Kuliah_Master Tipe : Master PK : Status_Mata_Kuliah
No Nama field Tipe Ukuran1 Status_Mata_Kuliah Char 1 2 Nama_Status_Mata_Kuliah Char 50
Tabel 14.22: Relasi Jenis_Mata_Kuliah_Master Tipe : Master PK : Jenis_Mata_Kuliah
No Nama field Tipe Ukuran1 Jenis_Mata_Kuliah Char 1 2 Nama_Jenis_Mata_Kuliah Char 20 3 Jam_Per_SKS Num 3
Tabel 14.23: Relasi Nilai_Master Tipe : Master PK : Nilai
No Nama field Tipe Ukuran 1 Nilai Char 1 2 Mutu Num 1 3 Predikat Char 15
Tabel 14.24: Relasi Ruang_Master Tipe : Master PK : Ruang
No Nama field Tipe Ukuran 1 Ruang Char 3 2 Kapasitas Num 3 3 Lokasi_Ruang Char 50
11
Tabel 14.25: Relasi Waktu_Master Tipe : Master PK : Waktu
No Nama field Tipe Ukuran 1 Waktu Char 3 2 Hari Char 6 3 Jam_Mulai Time 6
Tabel 14.26: Relasi KRS_Transaksi Tipe : Transaksi PK : Angkatan+Jenjang_Studi+Jurusan+Nomor+Kode_Mata_Kuliah
+Tahun_Semester No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Kode_Mata_Kuliah Char 8 7 Tahun_Semester Char 5
Tabel 14.27: Relasi KHS_Transaksi Tipe : Transaksi PK : Angkatan+Jenjang_Studi+Jurusan+Nomor+Kode_Mata_Kuliah
+Tahun_Semester No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Kode_Mata_Kuliah Char 8 7 Tahun_Semester Char 5 8 Nilai Char 1
Tabel 14.28: Dosen_Mengajar_Transaksi Tipe : Transaksi PK : Kode_Dosen+Kode_Mata_Kuliah+Tahun_Semester
No Nama field Tipe Ukuran 1 Kode_Dosen Char 8 2 Kode_Mata_Kuliah Char 8 3 Tahun_Semester Char 5 4 Status_Mengajar Char 1
12
Tabel 14.29: Relasi Jadwal_Transaksi Tipe : Transaksi PK : Kode_Mata_Kuliah+Tahun_Semester+Kode_Dosen
No Nama field Tipe Ukuran 1 Kode_Mata_Kuliah Char 8 2 Tahun_Semester Char 5 3 Kode_Dosen Char 8 4 Program Char 1 5 Kode_Ruang Char 3 6 Kelas Char 1 7 Kode_Waktu Char 3
Tabel 14.30: Relasi Wali_Orang_Tua_Master Tipe : Master PK : Angkatan+Jenjang_Studi+Jurusan+Nomor No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Nama_Wali Char 100 7 Pendidikan Char 2 8 Pekerjaan Char 2 9 Alamat_Wali Char 50 10 Kode_Pos Char 5 11 Kabupaten Char 2 12 Telepon Char 12 13 Telepon_HP Char 20 14 Penghasilan Num 9
Tabel 14.31: Relasi Pekerjaan_Master Tipe : Master PK : Pekerjaan
No Nama field Tipe Ukuran 1 Pekerjaan Char 2 2 Nama_Pekerjaan Char 50
13
Tabel 14.32: Relasi Wali_Dosen_Akademik_Transaksi Tipe : Transaksi PK : Angkatan+ Jenjang_Studi+ Program_Studi+ Program+ Nomor+
Tahun_Semester No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Tahun_Semester Char 5 7 Kode_Dosen Char 8
Tabel 14.33: Relasi Ketua_Program_Studi_Transaksi Tipe : Transaksi PK : Program_Studi+Tanggal_SK
No Nama field Tipe Ukuran1 Program_Studi Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_Ketua_Program_Studi Char 50
Tabel 14.34: Relasi Sekretaris_Program_Studi_Transaksi Tipe : Transaksi PK : Program_Studi+Tanggal_SK
No Nama field Tipe Ukuran 1 Program_Studi Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_Sekretaris Char 50
Tabel 14.35: Relasi Ketua_Jurusan_Transaksi Tipe : Transaksi PK : Jurusan+Tanggal_SK
No Nama field Tipe Ukuran 1 Jurusan Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_Ketua_Jurusan Char 50
14
Tabel 14.36: Relasi Sekretaris_Jurusan_Transaksi Tipe : Transaksi PK : Jurusan+Tanggal_SK
No Nama field Tipe Ukuran 1 Jurusan Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_Sekretaris Char 50
Tabel 14.37: Relasi Dekan_Transaksi Tipe : Transaksi PK : Fakultas+Tanggal_SK
No Nama field Tipe Ukuran 1 Fakultas Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_Dekan Char 50
Tabel 14.38: Relasi Pembantu_Dekan_1_Transaksi Tipe : Transaksi PK : Fakultas+Tanggal_SK
No Nama field Tipe Ukuran 1 Fakultas Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_PD_1 Char 50
Tabel 14.39: Relasi Pembantu_Dekan_2_Transaksi Tipe : Transaksi PK : Fakultas+Tanggal_SK
No Nama field Tipe Ukuran 1 Fakultas Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_PD_2 Char 50
15
Tabel 14.40: Relasi Pembantu_Dekan_3_Transaksi Tipe : Transaksi PK : Fakultas+Tanggal_SK
No Nama field Tipe Ukuran 1 Fakultas Char 2 2 Kode_Dosen Char 8 3 Tanggal_SK Date 4 Tanggal_Batas_SK Date 5 No_SK_PD_3 Char 50
Tabel 14.41: Relasi Pembantu_Rektor_1_Transaksi Tipe : Transaksi PK : Tanggal_SK
No Nama field Tipe Ukuran 1 Kode_Dosen Char 8 2 Tanggal_SK Date 3 Tanggal_Batas_SK Date 4 No_SK_Purek_1 Char 50
Tabel 14.42: Relasi Pembantu_Rektor_2_Transaksi Tipe : Transaksi PK : Tanggal_SK
No Nama field Tipe Ukuran 1 Kode_Dosen Char 8 2 Tanggal_SK Date 3 Tanggal_Batas_SK Date 4 No_SK_Purek_2 Char 50
Tabel 14.43: Relasi Pembantu_Rektor_3_Transaksi Tipe : Transaksi PK : Tanggal_SK
No Nama field Tipe Ukuran 1 Kode_Dosen Char 8 2 Tanggal_SK Date 3 Tanggal_Batas_SK Date 4 No_SK_Purek_3 Char 50
Tabel 14.44: Relasi Rektor_Transaksi Tipe : Transaksi PK : Tanggal_SK
No Nama field Tipe Ukuran 1 Kode_Dosen Char 8 2 Tanggal_SK Date 3 Tanggal_Batas_SK Date 4 No_SK_Rektor Char 50
16
Tabel 14.45: Relasi Alumni_Master Tipe : Master PK : Angkatan+Jenjang_Studi+Jurusan+Nomor No Nama field Tipe Ukuran
1 Angkatan Num 4 2 Jenjang_Studi Char 1 3 Program_Studi Char 2 4 Program Char 1 5 Nomor Num 4 6 Tanggal_Yudisium Date 7 Tanggal_Wisuda Date 8 IPK Num 2:2 9 Judul_TA Char 200
1133..22..22.. SSuubbssiisstteemm PPeennggoollaahhaann DDaattaa IInnvveennttoorrii
Contoh kedua tentang rancangan basis data yang diberikan berikut adalah
untuk subsistem pengolahan data inventori. Rancangan ini khusus untuk
menangani stok barang di gudang. Stok barang dipengaruhi oleh barang masuk
karena pembelian (bukan produksi sendiri) dan barang keluar karena penjualan.
Tabel 14.46: Relasi Barang_Master Tipe : Master PK : Kode_Barang
No Nama field Tipe Ukuran 1 Kode_Barang Char 8 2 Nama_Barang Char 50 3 Tipe Char 2 4 Jenis Char 2 5 Ukuran Char 20 6 Satuan Char 2 7 Bahan Char 100 8 Merk Char 20
Tabel 14.47: Relasi Tipe_Master Tipe : Master PK : Tipe
No Nama field Tipe Ukuran 1 Tipe Char 2 2 Keterangan_Tipe Char 20
17
Tabel 14.48: Relasi Jenis_Master Tipe : Master PK : Jenis
No Nama field Tipe Ukuran 1 Jenis Char 2 2 Keterangan_Jenis Char 20
Tabel 14.49: Relasi Satuan_Master Tipe : Master PK : Satuan
No Nama field Tipe Ukuran 1 Satuan Char 2 2 Keterangan_Satuan Char 20
Tabel 14.50: Relasi Harga_Barang_Transaksi Tipe : Transaksi PK : Kode_Barang+Tanggal_Harga
No Nama field Tipe Ukuran 1 Kode_Barang Char 8 2 Harga_Barang Num 9 3 Tanggal_Harga Date
Tabel 14.51: Relasi Stok_Barang_Transaksi Tipe : Transaksi PK : Kode_Barang+Tanggal_Stok
No Nama field Tipe Ukuran1 Kode_Barang Char 8 2 Jumlah_Stok_Barang Num 9 3 Tanggal_Stok Date
Tabel 14.52: Relasi Pembelian_Transaksi Tipe : Transaksi PK : No_Pembelian
No Nama field Tipe Ukuran1 No_Pembelian Char 12 2 No_Nota_Pembelian Char 20 3 Tanggal_Pembelian Date 4 Kode_Supplier Char 8 5 Total_Harga_Pembelian Num 12 6 Total_Diskon_Pembelian Num 12
18
Tabel 14.53: Relasi Item_Pembelian_Transaksi Tipe : Transaksi PK : No_Pembelian No Nama field Tipe Ukuran
1 No_Pembelian Char 12 2 Kode_Barang Char 8 3 Jumlah_Barang Num 3 4 Harga_Satuan_Pembelian Num 12
Tabel 14.54: Relasi Return_Pembelian_Transaksi Tipe : Transaksi PK : No_Pembelian No Nama field Tipe Ukuran
1 No_Pembelian Char 12 2 Kode_Barang Char 8 3 Jumlah_Return_Pembelian Num 3 4 Harga_Satuan_Pembelian Num 12 5 Keterangan Memo
Tabel 14.55: Relasi Penjualan_Transaksi Tipe : Transaksi PK : No_Penjualan
No Nama field Tipe Ukuran1 No_Penjualan Char 12 2 No_Nota_Penjualan Char 20 3 Tanggal_Penjualan Date 4 Kode_Pelanggan Char 8 5 Total_Harga_Penjualan Num 12 6 Total_Diskon_Penjualan Num 12
Tabel 14.56: Relasi Item_Penjualan_Transaksi Tipe : Transaksi PK : No_Penjualan+ Kode_Barang No Nama field Tipe Ukuran
1 No_Penjualan Char 12 2 Kode_Barang Char 8 3 Jumlah_Barang_Penjualan Num 3 4 Harga_Satuan_Penjualan Num 12
19
Tabel 14.57: Relasi Return_Penjualan_Transaksi Tipe : Transaksi PK : No_Penjualan+ Kode_Barang
No Nama field Tipe Ukuran1 No_Penjualan Char 12 2 Kode_Barang Char 8 3 Jumlah_Return_Penjualan Num 3 4 Harga_Satuan_Penjualan Num 12 5 Keterangan Memo
Tabel 14.58: Relasi Barang_Rusak_Transaksi Tipe : Transaksi PK : No_Rusak
No Nama field Tipe Ukuran1 No_Rusak Char 12 2 Kode_Barang Char 8 3 Tanggal_Rusak Date 4 Jumlah_Rusak Num 3 5 Keterangan Memo
Tabel 14.59: Relasi Barang_Hilang_Transaksi Tipe : Transaksi PK : No_Hilang
No Nama field Tipe Ukuran1 No_Hilang Char 12 2 Kode_Barang Char 8 3 Tanggal_Hilang Date 4 Jumlah_Hilang Num 3 5 Keterangan Memo
Tabel 14.60: Relasi Supplier_Master Tipe : Master PK : Kode_Supplier
No Nama field Tipe Ukuran1 Kode_Supplier Char 8 2 Nama_Supplier Char 05 3 Alamat_Supplier Char 100 4 Telepon_ Supplier Char 12 5 Telepon_HP_ Supplier Char 20 6 Contact_Person Char 50 7 Keterangan Memo
20
Tabel 14.61: Relasi Pelanggan_Master Tipe : Master PK : Kode_Pelanggan
No Nama field Tipe Ukuran1 Kode_Pelanggan Char 8 2 Nama_Pelanggan Char 05 3 Alamat_Pelanggan Char 100 4 Telepon_Pelanggan Char 12 5 Telepon_HP_Pelanggan Char 20 6 Contact_Person Char 50 7 Keterangan Memo
BBAABB XXIIVV..
PPEENNGGEEMMBBAANNGGAANN SSIISSTTEEMM BBAASSIISS DDAATTAA
1144..11.. TTuujjuuaann PPeennggeemmbbaannggaann SSiisstteemm BBaassiiss DDaattaa
Tujuan pengembangan sistem basis data berhubungan dengan masalah-masalah yang
timbul dalam file basis data. Tujuan sistem basis data meliputi:
1. Penyediaan sarana akses yang fleksibel
2. Pemeliharaan integritas data
3. Proteksi data dari kerusakan dan penggunaan yang ilegal
4. Penyediaan sarana untuk penggunaan bersama (hare)
5. Penyediaan sarana keralasian antar data (interelated data)
6. Minimalisasi kerangkapan data (data redudancy)
7. Menghilangkan ketergantungan data pada program-program aplikasi (data
independence)
8. Menstandarkan definisi-definisi rinci data (data item)
9. Meningkatkan produktivitas personal sistem informasi
1144..22.. LLaannggkkaahh PPeennggeemmbbaannggaann SSiisstteemm BBaassiiss DDaattaa
Proyek pengembangan sistem basis data bukan hanya sekedar menyusun file-file yang
diperlukan untuk disimpan sebagai basis data, tetapi juga termasuk di dalamnya
mengatur bagaimana agar basis data tersebut dapat dimanfaatkan secara optimal oleh
pemakai untuk memenuhi kebutuhan datanya. Jadi proyek pengembangan sistem basis
data meliputi pengembangan file basis data, perangkat lunak (software), perangkat
keras (hardware), dan menyiapkan personal-personal yang akan terlibat dalam
penggunaan sistem basis data agar dapat memanfaatkannya dengan baik dan benar.
Adapun tahapan-tahapan utama dalam proyek pengembangan sistem basis data dapat
terdiri atas tiga atau lima tahap.
1144..22..11.. PPeennggeemmbbaannggaann SSiisstteemm BBaassiiss DDaattaa yyaanngg TTeerrddiirrii 33 TTaahhaappaann
Pengembangan sistem basis data yang terdiri dari 3 tahapan adalah sebagai berikut:
1. Analisis
2. Desain / Perancangan
3. Implementasi
Tahapan analisis, meliputi beberapa langkah, yaitu:
1. Menentukan masalah utama dan lingkup sistem
2. Mengumpulkan fakta yang berhubungan dengan masalah
3. Menganalisa fakta-fakta
4. Menentukan alternatif pemecahan yang mungkin
5. Memilih alternatif pemecahan masalah
6. Pembuatan studi kelayakan
7. Laporan ke manajemen
Tahapan perancangan, meliputi beberapa langkah yaitu:
1. Review kebutuhan
2. Desain umum
3. Desain terinci, meliputi:
a. Desain input
b. Desain proses
c. Desain output
d. Desain basis data
e. Desain dialog
4. Laporan ke manajemen
Implementasi, meliputi beberapa langkah yaitu:
1. Review desain
2. Penjadwalan tugas pengembangan
3. Coding program
4. Testing program, meliputi:
a. Testing modul
b. Testing menyeluruh
5. Pelatihan petugas
6. Konversi sistem
7. Laporan ke manajemen
1144..22..22.. PPeennggeemmbbaannggaann SSiisstteemm BBaassiiss DDaattaa yyaanngg TTeerrddiirrii 55 TTaahhaappaann
Pengembangan sistem basis data yang terdiri dari 5 tahapan adalah sebagai berikut:
1. Perencanaan
2. Analisis
3. Desain / Perancangan
4. Implementasi
5. Penggunaan / review / evaluasi
Perencanaan merupakan tahap paling awal yang memberikan pedoman dalam
melakukan langkah selanjutnya. Tahap perencanaan meliputi kegiatan sebagai berikut:
1. Mengenali masalah
2. Menentukan masalah
3. Menentukan tujuan
4. Mengenali kendala
5. Studi kelayakan
6. Laporan ke manajemen
Analisis sistem (systems analysis) merupakan tahap setelah perencanaan sebelum
perancangan. Analisis sistem sangat menentukan keberhasilan pengembangan sistem
basis data, karena kesalahan dalam tahap ini akan mempengaruhi langkah
pengembangan selanjutnya. Bagan alir sistem akan digambarkan dalam tahap ini
sebagai alat komunikasi antara analis sistem dan pemakai, serta personil yang terlibat di
dalam tim. Tahap analisis sistem meliputi kegiatan sebagai berikut:
1. Menentukan kebutuhan informasi
2. Menentukan kriteria kinerja sistem
3. Laporan ke manajemen
Tahap setelah analisis sistem adalah perancangan sistem (systems design), yaitu
bagaimana membentuk sistem baru yang diinginkan. Tahap perancangan berupaya
menentukan dan menggambarkan bagaimana suatu sistem akan dapat menyelesaikan
suatu permasalahan. Tahap perancangan sistem merupakan tahap pemasukan ide atau
gagasan guna memenuhi tujuan pengembangan sistem basis data sebagai persiapan
untuk rancang bangun implementasi.
Perancangan sistem dapat diartikan sebagai ;
1. Tahap setelah analisis sistem
2. Pendefinisian kebutuhan fungsional
3. Persiapan untuk rancang bangun implementasi
4. Menggambarkan bagaimana suatu sistem akan dibentuk
5. Penggambaran, perencanaan, dan pembuatan sketsa atau pengaturan dari
beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh dan berfungsi
6. Tahap yang menyangkut konfigurasi komponen perangkat lunak dan perangkat
keras sistem
Perancangan sistem meliputi kegiatan sebagai berikut:
1. Menyiapkan desain terinci
2. Identifikasi konfigurasi perangkat keras & perangkat lunak
3. Evaluasi konfigurasi sistem alternatif
4. Memilih konfigurasi perangkat keras & perangkat lunak terbaik
5. Laporan ke manajemen
Tahap perancangan sistem dapat dikelompokkan dalam dua bagian, yaitu:
1. Perancangan sistem secara umum (general systems design) atau desain konseptual
(conceptual design) atau perancangan logika (logical design)
2. Perancangan sistem secara terinci (detailed systems design) atau perancangan
sistem secara fisik (phisical systems design) perancangan internal (internal design)
Implementasi sistem merupakan tahap untuk merealisasikan hasil desain / perancangan
sistem yang telah dilakukan sebelumnya ke dalam bentuk yang sebenarnya.
Implementasi sistem meliputi kegiatan sebagai berikut:
1. Menyiapkan perangkat keras
2. Menyiapkan perangkat lunak
3. Menyiapkan basis data
4. Menyiapkan fasilitas fisik
5. Melatih pemakai
6. Laporan ke manajemen
Penggunaan / review / evaluasi merupakan tahap terakhir dalam pengembangan sistem
basis data, yaitu berupa penggunaan / operasi hasil implementasi sistem. Penggunaan /
review / evaluasi sistem meliputi kegiatan sebagai berikut:
1. Operasional sistem
2. Evaluasi sistem
3. Memelihara sistem
4. Mempertahankan kinerja sistem
5. Meningkatkan kinerja sistem
6. Laporan ke manajemen
1144..33.. AAnnaalliissiiss KKeellaayyaakkaann PPeennggeemmbbaannggaann BBaassiiss DDaattaa
Pendekatan umum yang dapat dilakukan pada analisis kelayakan pengembangan
sistem basis data (perangkat keras / lunak baru atau pengganti) adalah:
1. Kelayakan teknis (technical feasibility)
Evaluasi kelayakan teknis menilai apakah pengembangan sistem basis data dapat
dikerjakan dengan teknologi yang tersedia pada organisasi, ataukah perlu
pengadaan baru. Dan jika perlu pengadaan baru apakah dapat diperoleh dengan
mudah dan cepat.
2. Kelayakan operasional (Operational Feasibility)
Evaluasi kelayakan operasional menilai apakah pengembangan sistem basis data
akan dapat dikerjakan / berhasil dan apakah sistem sedang atau telah dipakai.
3. Kelayakan ekonomis (Economic Feasibility)
Evaluasi kelayakan ekonomis menilai apakah manfaat pengembangan sistem basis
data melebihi biaya-biaya yang harus dikeluarkan dan apakah sistem mampu
memberikan penambahan manfaat. Perlu diperhatikan bahwa manfaat suatu sistem
basis data dapat berupa manfaat yang tangible dan manfaat yang intangible.
4. Kelayakan hukum (Law Feasibility)
Evaluasi kelayakan hukum menilai apakah sistem basis data layak dioperasikan
tanpa bertentangan dengan batasan hukum yang berlaku. Hal ini penting, karena
ada kalanya aturan-aturan atau teknologi yang digunakan dalam sistem basis data
pengadaaanya memerlukan pertimbangan hukum terlebih dahulu.
5. Kelayakan jadwal (Schedule Feasibility)
Evaluasi kelayakan jadwal menilai apakah sistem basis data dapat dioperasikan
dalam batasan waktu tertentu yang ditetapkan.
1144..44.. PPeenngghhiittuunnggaann MMaannffaaaatt AApplliikkaassii SSiisstteemm BBaassiiss DDaattaa SSeeccaarraa KKuuaannttiittaattiiff
Nilai sistem basis data dapat bersifat ekonomis dan non ekonomis. Manfaat ekonomis
adalah manfaat yang menyebabkan perbaikan dalam penghasilan atau memperkecil
biaya. Sedangkan manfaat non ekonomis adalah berhubungan dengan mutu hidup
manusia. Manfaat nonekonomis cenderung lebih sulit untuk diukur karena sangat sulit
untuk memperkirakan seberapa besar angka manfaat yang berhasil diperoleh dari
penerapan sistem basis data.
Dua pendekatan metoda dapat membantu dalam penghitungan ini, yaitu melalui:
1. Metoda perkiraan langsung atas nilai aplikasi sistem basis data
2. Metoda biaya kurang dari atau lebih dari angka tertentu yang ditetapkan sebelumnya
Dalam kenyataannya, metoda biaya kurang dari atau lebih dari angka tertentu yang
ditetapkan mampu memberikan hasil yang lebih baik daripada metoda pertama. Hal ini
dikarenakan perkiraan angkanya cenderung lebih akurat. Sedangkan dalam metoda
pertama cenderung sembarangan karena setiap individu yang menilai tidak mempunyai
dasar yang sama yaitu tergantung dari pengalaman masing-masing pada masa lampau.
1144..55.. AAnnaalliissiiss BBiiaayyaa MMaannffaaaatt ddaarrii AAlltteerrnnaattiiff DDeessaaiinn SSiisstteemm BBaassiiss DDaattaa
Analisis biaya / manfaat dari alternatif desain suatu sistem basis data pada umumnya
dilakukan atas dasar suatu kompromi. Kompromi yang dimaksud meliputi pilihan desain
yang harus dilakukan, dan ukuran dalam analisis biaya manfaat yang harus
disampaikan kepada pimpinan / manajemen untuk pembuatan keputusan. Beberapa
masalah yang berhubungan dengan pemilihan desain sistem basis data adalah sebagai
berikut:
1. Waktu tanggapan
Waktu tanggapan adalah waktu yang diperlukan bagi sistem basis data untuk
menanggapi kebutuhan-kebutuhan informasi bagi para pemakai. Kebutuhan-
kebutuhan yang dimaksud adalah meliputi kebutuhan pengolahan transaksi,
peremajaan basis data, dan pencarian dan penampilan kembali data yang
diperlukan.
2. Perincian tampilan
Kompromi dalam perincian tampilan meliputi penyajian berupa:
⇒ Laporan tercetak di kertas atau di layar terminal
⇒ Laporan terperinci atau ringkasan
⇒ Laporan yang memuat analisis mendalam untuk memperoleh perincian atau
laporan teragregasi
3. Mutu data
Pada umumnya pemakai akan lebih mementingkan mutu data yang disajikan
daripada kuantitasnya. Hal ini sebenarnya cenderung merupakan kompromi saja.
1144..66.. KKeelleemmaahhaann PPeennddeekkaattaann SSiisstteemm BBaassiiss DDaattaa
Sebagaimana teknologi lain, teknologi sistem basis data memerlukan biaya mahal dan
mempunyai kelemahan. Organisasi pemakai mungkin akan mengalami kesulitan jika
penyelesaian permasalahan menggunakan pendekatan sistem basis data.
Sekalipun terjadi kecenderungan bahwa harga perangkat keras teknologi basis data
(menggunakan komputer) semakin murah, namun masih diperlukan perangkat keras
tambahan terutama untuk meningkatkan kinerja sistem. Berbagai biaya tambahan juga
diperlukan karena pemrograman basis data lebih kompleks. Para pemrogram harus
dilatih untuk menggunakan aplikasi dengan baik. Analis sistem harus dilatih agar
menguasai teknik-teknik desain basis data dengan benar. Rancangan sistem yang
lengkap harus disiapkan, basis data dan program-program aplikasi harus dipesan,
didesain, atau dikonversi.
Semuanya ini memerlukan biaya yang cukup besar. Namun tentu saja juga akan
memberikan manfaat. Ketika aplikasi dikonversikan ke sistem basis data, biaya mulai
menurun karena sebagian besar atau seluruh data yang diperlukan telah siap dan
tersedia dalam basis data. Aplikasi sederhana dapat diatasi dengan menggunakan
bahasa query atau report generator, yang memerlukan waktu jauh lebih singkat.
top related