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.