1
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 view n
Conceptual view
Physical view Gambar 4.1 : Pandangan terhadap basis data 1. Application Programmer Logical File / User View 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 datadata mahasiswa tersebut disimpan dalam basis 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. Global Logical Data (Conseptual View) 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.
2
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. Physical View 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 Nama Alamat asal Alamat lokal
: 1998111000 : Agus Junior : Jalan Mawar 1 Semarang : Jalan Menur 10 Yogyakarta
3
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.
Data
Track ke:
0 1 2 3 4 5 6 7 (parity bit) 8
1 0 0 0 0 0 0 0 1 1
9 0 0 0 1 0 0 0 1 0
9 0 0 0 1 0 0 0 1 0
8 0 0 0 1 0 0 0 0 1
Rec #1 1 0 0 0 0 0 0 0 1 1
ARAH PUTARAN HEAD Æ IRG … ... P N S … ... 1 0 0 … ... 0 1 1 … ... 1 0 0 … ... 0 0 1 … ... 0 1 0 … ... 0 1 0 … ... 0 1 1 … ... 0 0 1 … ... 0 0 0 …
IRG
Rec #N … … … … … … … … … …
IRG
Gambar 4.2:Contoh penyimpanan record mahasiswa dalam magnetic tape 4.1. Independensi Data (Data Independency) 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
4
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)
5
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 Urutan kode o
6
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
7
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|
8
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.
9
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).
10
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 02050001 Rita 02050002 Rina 02050003 Rini
Alamat Jl. Mawar no. 1 Yogyakarta Jl. Melati no. 2 Yogyakarta Jl. Menur no. 3 Yogyakarta
Relasi KRS NIM 02050001 02050001 02050002 02050002 02050003 02050003
Kode_Mata_Kuliah MK-11001 MK-12002 MK-11001 MK-13003 MK-11001 MK-12002
Tahun_Semester 200220031 200220032 200320041 200320041 200220031 200220032
Relasi KHS NIM 02050001 02050001 02050002 02050002 02050003 02050003
Kode_Mata_Kuliah MK-11001 MK-12002 MK-11001 MK-13003 MK-11001 MK-12002
Tahun_Semester 200220031 200220032 200320041 200320041 200220031 200220032
Nilai A B B B A C
