BAB IV
INTEGRASI RANCANGAN BASIS DATA UNTUK SIM
4.1. Pandangan Terhadap Basis Data
Pandangan terhadap basis data sering disebut arsitektur basis data atau abstraksi basis data. Suatu basis data dapat dipandang dari dua sudut pandang, yaitu:
o Sudut pandang pemakai
Pemakai basis data dapat diartikan sebagai orang-orang yang akan mengakses/menggunakan basis data, baik secara bersamaan maupun secara individu dalam lingkup sistem.
o Sudut pandang perancang
Perancang adalah mereka yang berperan sebagai perancang dan pengelola basis data. Perancang dapat memiliki dua jenis pandangan yang berbeda, yaitu secara konseptual dan secara fisis.
Hubungan di antara ketiga pandangan terhadap basis data tersebut dapat digambarkan sebagaimana ditunjukkan oleh Gambar 4.1.
User view 1 User view 2 User viewn
Conceptual view
Physical view
…
Gambar 4.1 : Pandangan terhadap basis data 1
1..AApppplliiccaattiioonnPPrrooggrraammmmeerrLLooggiiccaallFFiillee//UUsseerrVViieeww
Application programmer logical file atau user view atau external view, merupakan pandangan para pemakai basis data dimana masing-masing dapat memiliki cara pandang yang berbeda tergantung pada macam data apa saja yang tersedia atau dapat diakses oleh pemakai.
Dengan demikian, para pemakai tidak perlu tahu bagaimana sebenarnya data-data mahasiswa tersebut disimpan dalam basis data-data. Application programmer logical file dapat ditunjukkan menggunakan schema dan subschema. Sedangkan nilai-nilai rinci data/nilai aktual data dalam setiap relasi dapat ditunjukkan menggunakan instance schema.
2
2..GGlloobbaallLLooggiiccaallDDaattaa((CCoonnsseeppttuuaallVViieeww))
Global logical data atau conseptual view, merupakan pandangan perancang basis data yang berkaitan dengan data-data apa saja yang perlu disimpan dan penjelasan mengenai hubungan antara data yang satu dan yang lainya.
Global logical data 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 dan program aplikasi pada seluruh sub sistem yang digunakan dalam sistem. Sehingga, perancang perlu menginventarisasi seluruh kebutuhan informasi dan data untuk seluruh pemakai.
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-data yang terkait dengan obyek mahasiswa bagi pemakai pada 3 subsistem yang berbeda adalah sebagai berikut:
Subsistem akademik: Relasi Mahasiswa: |NIM|Nama_Mahasiswa|Alamat|Tempat_Lahir|Tanggal_Lahir|Agama| Subsistem perpustakaan: Relasi Anggota: No_Anggota|Nama_Aggota|Alamat|Tgl_Masuk_Anggota| Subsistem keuangan: Relasi Pembayaran: |NIM|Nama_Mahasiswa|Tanggal_Bayar|Jumlah_Bayar|Jenis_Beaya| 3 3..PPhhyyssiiccaallVViieeww
Physical view atau internal level, merupakan implementasi conceptual view, yaitu pandangan perancang yang berkaitan dengan teknik penyimpanan basis data dalam data storage yang digunakan. Pandangan ini berorientasi pada mesin (machine oriented), yaitu berkaitan dengan organisasi berkas basis data, yang meliputi:
o metoda pengalamatan dalam media penyimpan sekunder (addressing)
o metoda akses data (access method)
Data-data dalam struktur data pada subsistem akademik di atas, selanjutnya akan diimplementasikan ke dalam data storage berupa magnetic tape yang memiliki 9 track.
Contoh nilai rinci data:
NIM : 1998111000
Nama : Agus Junior
Alamat asal : Jalan Mawar 1 Semarang
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
Jika data disimpan tanpa metode blocking, dengan menggunakan even parity check, maka dapat digambarkan seperti ditunjukkan oleh Gambar 4.2.
ARAH PUTARAN HEAD Æ
Rec #1 IRG … IRG Rec #N IRG
1 9 9 8 1 ... P N S … … 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 … … Da ta (parity bit) 8 1 0 0 1 1 ... 0 0 0 … …
Gambar 4.2:Contoh penyimpanan record mahasiswa dalam magnetic tape 4
4..11.. IInnddeeppeennddeennssiiDDaattaa((DDaattaaIInnddeeppeennddeennccyy))
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 disebut ketidakbergantungan data atau kebebasan data atau independensi data (data independence).
Independensi data (data Independence) adalah ketidaktergantungan/kebebasan data dalam basis data, yang mempunyai 2 dimensi yaitu:
o Independensi data secara fisik (physical data independence) o Independensi data 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.
Independensi data akan memberikan jaminan fleksibilitas basis data, yaitu: 1. Media dan metode akses data dari fisik media penyimpan basis data dapat
mengalami perubahan tanpa harus mengubah conceptual view
2. Kebutuhan data-data oleh para pemakai basis data dapat mengalami
perubahan tanpa harus mengubah conceptual view
3. Pemakai tidak perlu tahu kerumitan/kompleksitas perancangan dan
teknis penyimpanan basis data dalam data storage 4.2. Integrasi Perancangan Basis Data
Pada saat perancangan basis data, perancang harus memposisikan dirinya pada conceptual view. Level ini merupakan gabungan dari beberapa user view. Hal ini berarti bahwa perancangan basis data hanya bisa dilakukan setelah mengetahui seluruh kebutuhan para pemakai di dalam sistem.
Untuk hal ini, maka perancangan basis data dapat dilakukan dengan mengikuti langkah sebagai berikut:
1. Langkah analisis kebutuhan, meliputi;
a. Analisis kebutuhan batasan/ruang lingkup sistem b. Analisis kebutuhan model bisnis
c. Analisis keterkaitan antar unit fungsional dalam sistem d. Analisis kebutuhan data dan informasi dalam sistem
e. Analisis kemungkinan perubahan situasi/kondisi/kebijakan yang
terkait dengan kebutuhan data dan informasi dalam sistem 2. Langkah perancangan, meliputi;
a. Perancangan tahap awal, meliputi:
1). Pengelompokan data berdasarkan entitas/obyek data 2). Standarisasi nama-nama atribut
3). Standarisasi penggunaan kode data pada atribut 4). Perancangan struktur relasi database awal 5). Normalisasi struktur relasi database awal
6). Penentuan PK, FK dan kerelasian antar struktur relasi hasil
normalisasi
b. Perancangan tahap lanjutan, meliputi: 1). Standarisasi data, yaitu:
a). Standarisasi nama-nama atribut
b). Standarisasi atribut dan penggunaan kode data yang digunakan antar unit fungsional dalam sistem
2). Pengkodean nilai-nilai data yang digunakan secara berulang pada
record, yaitu:
a). Untuk nilai-nilai data yang mutlak tidak akan mengalami
perubahan di kemudian hari, maka nilai-nilai data perlu dikodekan. Hal ini bertujuan untuk efisiensi penggunaan memori dan menjaga konsistensi data.
Misal:
o Data Jenis_Kelamin disimpan sebagai L (untuk
mengkodekan nilai data jenis kelamin Laki-laki) dan P (untuk mengkodekan nilai data jenis kelamin Perempuan)
o Data Status_Menikah disimpan sebagai M (untuk mengkodekan nilai data status Menikah) dan B (untuk mengkodekan nilai data status Belum Menikah)
o Data Status_Aktif disimpan sebagai A (untuk mengkodekan
nilai data status Aktif) dan T (untuk mengkodekan nilai data status Tidak Aktif)
b). Untuk nilai-nilai data yang memiliki kemungkinan mengalami
perubahan di kemudian hari, maka nilai-nilai data perlu dikodekan dan kemudian dirancang relasi referensi. Hal ini bertujuan untuk:
o Efisiensi penggunaan memori
o Menjaga konsistensi data
o Minimalisasi kerangkapan data
o Kemudahan pemeliharaan data
Misal:
o Data Agama dapat disimpan ke dalam kode-kode data
agama, yaitu:
o I (untuk menyatakan agama Islam)
o K (untuk menyatakan agama Kristen-Katholik)
o P (untuk menyatakan agama Kristen-Protestan)
o H (untuk menyatakan agama Hindu)
o B (untuk menyatakan agama Budha)
o Kemudian dirancang sebuah relasi referensi, yaitu
relasi AGAMA
o Data Kelompok_Mata_Kuliah dapat disimpan ke dalam
kode-kode kelompok mata kuliah, yaitu:
o W (untuk menyatakan kelompok mata kuliah Wajib)
o M (untuk menyatakan kelompok mata kuliah Wajib
Minat)
o P (untuk menyatakan kelompok mata kuliah Pilihan).
o Kemudian dirancang sebuah relasi referensi, yaitu
relasi KELOMPOK_MATA_KULIAH.
o Data Alamat dapat disimpan ke dalam kode-kode data
alamat sehingga menjadi sebagai berikut:
o Alamat (untuk menyimpan nilai data nama jalan dan
nomor rumah atau nama dusun dan desa)
o Kode_Kecamatan (untuk mengkodekan nilai data
Kecamatan)
o Kode_Kabupaten (untuk mengkodekan nilai data
Kabupaten)
o Kode_Propinsi (untuk mengkodekan nilai data
Propinsi)
o Kemudian dirancang 3 (tiga) buah relasi referensi,
yaitu relasi KECAMATAN, KABUPATEN, dan PROPINSI.
c). Untuk kode data berupa kode blok, maka nilai-nilai kode data dalam kode blok perlu dipisahkan, dan kemudian dirancang relasi referensi. Hal ini bertujuan untuk kemudahan pemeliharaan apabila terjadi perubahan pada:
o Format kode
o Perubahan lainnya pada kode blok Misal:
o Data NIM mahasiswa yang memiliki 4 (empat) komponen
dengan format Angkatan-Jenjang-Prodi-NomorUrut, disimpan ke dalam 4 (empat) buah atribut, yaitu:
o Angkatan
o Jenjang
o Prodi
o NomorUrut
o Kemudian dirancang 3 buah relasi referensi, yaitu
ANGKATAN, JENJANG, dan PRODI
o Data NIK dosen yang memiliki 4 komponen dengan format
NomorUrut-BulanTahunLahir-KelompokDosen, disimpan ke dalam 2 (dua) buah atribut, yaitu:
o NomorUrut
o KelompokDosen
o Sedangkan komponen BulanTahunLahir dapat diperoleh
dari atribut Tanggal_Lahir_Dosen
o Kemudian dirancang 1 (satu) buah relasi referensi, yaitu
KELOMPOK_DOSEN. 3). Perancangan keamanan data, yaitu:
a). Keamanan data dari kemungkinan terjadinya kehilangan,
kerusakan, kegagalan, atau permasalahan lainnya pada fisik memori, serta mekanisme backup dan restore data secara tersistem maupun manual.
b). Keamanan data dari kemungkinan akses secara illegal,
pembatasan kewenangan akses, dan permasalahan lainnya pada akses data.
3. Langkah pengujian, meliputi:
a. Pengujian kelengkapan data dalam rancangan struktur relasi
database. Pengujian dilakukan dengan cara mengecek kembali semua formulir isian data, dan semua keluaran/laporan maupun informasi yang harus ditampilkan di monitor yang digunakan/diperlukan oleh semua pemakai, dalam semua level manajemen, dalam semua unit fungsional dalam sistem
b. Pengujian kerangkapan data dalam rancangan struktur relasi
database. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur relasi database menggunakan semua kemungkinan nilai data
c. Pengujian kemungkinan terjadinya inkonsistensi data dalam
rancangan struktur relasi database. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur relasi database menggunakan semua kemungkinan nilai data
d. Pengujian untuk penggunaan bersama oleh para pemakai/aplikasi
dalam unit fungsional lain dalam sistem. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur relasi database dari semua sudut pandang unit fungsional dalam sistem
e. Pengujian fleksibilitas rancangan struktur relasi database untuk
perubahan nilai-nilai data di kemudian hari. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur relasi database berdasarkan kemungkinan terjadinya perubahan nilai-nilai
data dan kemudahan perubahan rancangan struktur relasi database sesuai perubahan tersebut
f. Pengujian fleksibilitas rancangan struktur relasi database untuk
kebutuhan-kebutuhan pemakai/aplikasi baru. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur relasi database berdasarkan kemungkinan terjadinya penambahan kebutuhan baru dan kemudahan perubahan rancangan struktur relasi database sesuai perubahan tersebut
4. Langkah implementasi, meliputi:
a. Pemilihan DBMS yang sesuai dengan kebutuhan dan kemampuan
institusi, dengan mempertimbangkan kemudahan untuk melakukan perubahan, pengembangan, dan migrasi data di masa mendatang; b. Pendefinisian rancangan struktur relasi database
c. Pengisian data dalam rancangan struktur relasi database, dapat
menggunakan program aplikasi, query, atau fasilitas lain yang tersedia dalam DBMS
d. Penggunaan database, dapat menggunakan program aplikasi, query,
atau fasilitas lain yang tersedia dalam DBMS e. Dokumentasi rancangan struktur relasi database f. Pemeliharaan database
Contoh:
Kebutuhan data-data yang terkait dengan obyek mahasiswa bagi pemakai pada subsistem Akademik, Perpustakaan, dan Keuangan dalam contoh di atas:
Subsistem akademik: Relasi Mahasiswa: |NIM|Nama_Mahasiswa|Alamat|Tempat_Lahir|Tanggal_Lahir|Agama| Subsistem perpustakaan: Relasi Anggota: No_Anggota|Nama_Aggota|Alamat|Tgl_Masuk_Anggota| Subsistem keuangan: Relasi Pembayaran: |NIM|Nama_Mahasiswa|Tanggal_Bayar|Jumlah_Bayar|Jenis_Beaya| Jika diintegrasikan, maka ketiga relasi tersebut akan menjadi sebagai berikut:
Relasi Mahasiswa: |NIM|Nama_Mahasiswa|Alamat|Tempat_Lahir|Tanggal_Lahir|Agama| Relasi Anggota: No_Anggota|NIM|Tgl_Masuk_Anggota| Relasi Pembayaran: |NIM|Tanggal_Bayar|Jumlah_Bayar|Jenis_Beaya|
Penting:
Agar rancangan memenuhi batasan-batasan dalam definisi basis data, maka basis data harus dirancang dalam sebuah lingkup sistem (bukan hanya pada suatu subsistem tertentu). Dengan demikian, dalam sebuah organisasi, maka lingkup sistem mencakup:
o Seluruh subsistem dalam organisasi o Seluruh pemakai dalam organisasi
o Seluruh level manajemen dalam organisasi yang
o Terintegrasi o CBIS
Contoh:
Basis data untuk Sistem Informasi di Perguruan Tinggi (SIPT) dapat terdiri atas sub sistem-sub sistem berikut:
o Sub Sistem Informasi Akademik (SIAKAD)
o Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN)
o Sub Sistem Informasi Keuangan (SIKEUANGAN)
o Sub Sistem Informasi Kepegawaian (SIPEGAWAI)
o Sub Sistem Informasi Penggajian (SIGAJI)
o Sub Sistem Informasi Inventaris (SIINVENTARIS)
o Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN)
o Sub Sistem Informasi Kerjasama dan Humas (SIKEHUMAS)
o Sub Sistem Informasi Penelitian (SIPENELITIAN)
o Sub Sistem Informasi Pengabdian Kepada Masyarakat (SIPENGABDIAN)
o Lainnya sesuai kebutuhan institusi
Khusus untuk SIAKAD, dapat terdiri atas serangkaian proses kegiatan yang merupakan sub sistem dari SIAKAD, meliputi:
o Penerimaan Mahasiswa Baru (SIPENMARU)
o Herregisterasi (SIHEREGISTERASI)
o Perwalian mahasiswa (SIWALI)
o Pra-KRS, KRS, dan perubahan KRS (SIKRS)
o Perkuliahan (SIKULIAH)
o Praktikum (SIPRAKTIKUM)
o KP (SIKP)
o KKN (SIKKN)
o Tugas Akhir (SITA)
o Yudisium (SIYUDISIUM)
o Wisuda (SIWISUDA)
o Alumni (SIALUMNI)
Sehingga, saat merancang struktur relasi MAHASISWA misalnya, maka rancangan struktur relasi MAHASISWA tersebut harus dapat digunakan oleh semua pemakai, dalam semua level, dalam semua sub sistem dalam SIPT tersebut, serta dirancang agar fleksibel terhadap berbagai kemungkinan perubahan kebutuhan yang dapat terjadi di masa mendatang.
4.3. Schema, Subschema, dan Instance Schema
Schema dan subschema digunakan oleh perancang basis data pada conceptual view. Schema dan subschema menjadi acuan pada saat perancangan struktur relasi. Suatu schema digunakan pada lingkup sistem (basis data), sedangkan subschema digunakan pada lingkup aplikasi tertentu. Jadi sebuah schema merupakan gabungan beberapa subschema.
Notasi schema atau subschema dapat dituliskan dengan format sebagai berikut: 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 kesatuan maupun referensial), maka batasan-batasan nilai elemen data pada atribut, FK, maupun PK dapat diberikan/dituliskan dalam notasi schema/subschema. Batasan tersebut dapat berupa:
o nilai dasar (default value) o batasan nilai (range)
o batasan tidak boleh kosong (not null)
Secara konsep, selain sifat unik pada atribut yang dipilih sebagai PK, terdapat 2 macam constraint yang terkait dengan pemilihan kunci relasi, yaitu:
o Entity integrity o Referential integrity
Entity integrity mensyaratkan bahwa nilai-nilai elemen data/entri pada PK tidak boleh null. Batasan ini dapat diset secara langsung menggunakan DBMS, sehingga seringkali batasan not null pada atribut PK tidak perlu dituliskan dalam schema (atau subschema).
Beberapa nilai elemen data/entri pada atribut dalam relasi seringkali juga tidak boleh null. Batasan not null pada atribut tidak harus selalu dituliskan dalam schema (atau subschema).
Referential integrity mensyaratkan bahwa nilai-nilai elemen data/entri pada PK PK yang diacu oleh FK tidak boleh null. Tidak semua DBMS memberikan fasilitas untuk mendefinisikan batasan ini. Dengan demikian, maka batasan not null pada atribut harus dituliskan dalam schema (atau subschema).
Contoh:
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))
Instance schema menunjukkan nilai aktual elemen data/entri dalam setiap relasi. Instance schema diperlukan untuk menunjukkan nilai data sesungguhnya yang ada di dalam schema (atau subschema).
Contoh:
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
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 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
