LAPORAN KERJA PRAKTEK

LAPORAN TUGAS AKHIR
PERANCANGAN SISTEM BASIS DATA JADWAL
RENCANA STUDI DAN KARTU RENCANA STUDI PADA
PERGURUAN TINGGI RAHARJA
Oleh :
Nama
: Alam Yudi Aryanto
Nim
: 2003-81-268
JURUSAN TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
UNIVERSITAS INDONUSA ESA UNGGUL
JAKARTA
2008
PERANCANGAN SISTEM BASIS DATA JADWAL RENCANA
STUDI DAN KARTU RENCANA STUDI PADA PERGURUAN
TINGGI RAHARJA
Tugas Akhir
Diajukan untuk memenuhi Persyaratan kurikulum Sarjana
Strata-1 Pada Jurusan Teknik Informatika Fakultas Ilmu
Komputer Universitas Indonusa Esa Unggul
Oleh :
Nama
Nim
: Alam Yudi Aryanto
: 2003-81-268
JURUSAN TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
UNIVERSITAS INDONUSA ESA UNGGUL
JAKARTA
2008
PENGESAHAN TUGAS AKHIR
Nama
: Alam Yudi Aryanto
NIM
: 2003-81-268
Jurusan
: Teknik Informatika
Fakultas
: Ilmu Komputer
Judul Tugas Akhir
: Perancangan Sistem Basis Data Jadwal Rencana
Studi dan Kartu Rencana Studi pada Perguruan
Tinggi Raharja
Tugas akhir tersebut diatas telah disetujui dan diterima sebagai salah satu syarat
untuk memperoleh gelar Sarjana Teknik, Jenjang Pendidikan Strata-1 Program
Studi Teknik Informatika.
Jakarta, September 2008
Disetujui oleh,
Drs. Bambang Mulyatno, M.Kom
Ir. I Joko Dewanto, MM
Pembimbing Materi
Pembimbing Tulisan
Mengetahui,
Ir. Munawar, MMSI, MCom
Ir. I. Joko Dewanto, MM
Dekan Fakultas Ilmu Komputer
Ketua Jurusan
iii
LEMBAR PENGESAHAN PENGUJI SIDANG
Nama
: Alam Yudi Aryanto
NIM
: 2003-81-268
Jurusan
: Teknik Informatika
Fakultas
: Ilmu Komputer
Judul Tugas Akhir
: Perancangan Sistem Basis Data Jadwal Rencana
Studi dan Kartu Rencana Studi pada Perguruan
Tinggi Raharja
Laporan Tugas Akhir ini telah dinyatakan LULUS oleh
Penguji Materi Program Studi Strata 1 Ilmu Komputer
Jurusan Teknik Informatika
Universitas Indonusa Esa Unggul
Jakarta, September 2008
Disetujui oleh
Penguji I
: Ir. Joko Dewanto, M.M
Penguji II
: Ir. Budi Tjahjono, M Kom
Penguji III
: Ari Pambudi, S.kom, M.Kom
Mengetahui,
Ir. Joko Dewanto,M.M
Koordinator Tugas Akhir
iv
UNIVERSITAS INDONUSA ESA UNGGUL
FAKULTAS ILMU KOMPUTER
PROGRAM STUDI TEKNIK INFORMATIKA
PERNYATAAN
Seluruh materi laporan Tugas Akhir ini adalah benar adanya dan
sepenuhnya dapat dipertanggungjawabkan kebenarannya oleh penulis.
Jakarta,
September 2008
( Alam Yudi Aryanto )
v
KATA PENGANTAR
Puji syukur penulis panjatkan ke hadirat Tuhan Yang Maha
Esa karena telah memberikan berkat rahmat dan hidayahNya
penyusunan laporan tugas akhir ini dapat penulis selesaikan dengan
baik.
Laporan tugas akhir ini berjudul “Perancangan Sistem Basis
Data Jadwal Rencana Studi dan Kartu Rencana Studi pada
Perguruan Tinggi Raharja” yang dibuat guna memenuhi persyaratan
mencapai Sarjana S1 di Jurusan Teknik Informatika Universitas
Indonusa Esa Unggul.
Pada kesempatan kali ini penulis ingin menyampaikan
ucapan terima kasih kepada :
1.
Bapak Ir. Munawar, MMSI, M.Com,. selaku Dekan Fakultas
Ilmu Komputer.
2.
Bapak Ir. I Joko Dewanto, MM., selaku
Ketua Jurusan
Teknik Informatika Universitas Indonusa Esa Unggul serta
pembimbing tulisan.
3.
Bapak Bambang Mulyatno, SE, MKom., selaku pembimbing
materi tugas akhir yang telah banyak membantu penulis
dalam penyelesaian tugas akhir dalam bidang materi.
4.
Bapak Henderi, S.Kom, M.Kom,. Ibu Euis Siti Nur Aisyah,
S.Kom,. yang telah membantu penelitian pada Perguruan
Tinggi Raharja.
5.
Mas Budi, yang telah menuntun saya dalam penyusunan
aplikasi ASP.NET.
vi
6.
Kedua Orang tua serta kakak – kakakku
yang telah
memberikan bantuan dan motivasi baik secara moril
maupun non moril kepada penulis.
7.
Teman-teman angkatan 2003 FASILKOM .
Penulis mohon maaf apabila terdapat kesalahan dalam
penyusunan laporan Tugas Akhir
ini. Semoga laporan ini
bermanfaat bagi para pembacanya. Amin.
Jakarta, 2008
(Alam Yudi Aryanto)
vii
DAFTAR ISI
Halaman Judul
Halaman Judul Kedua
Lembaran Pengesahan ........................................................................... iii
Lembar Pengesahan Penguji Sidang ..................................................... iv
Lembar Pernyataan ................................................................................ v
Kata Pengantar …………………………………………………………….... vi
Daftar Isi ………………….……………………………………..…...…....... viii
Daftar Tabel …………….…………………………………………..…......... xii
Daftar Gambar ......………………………………………...…………........ xvii
Daftar Lampiran ..................................................................................... xx
Abstrak ................................................................................................ xxi
BAB I:
BAB II:
PENDAHULUAN
1.1
Latar Belakang ……………….…………………….... 1
1.2
Perumusan Masalah ............................................... 2
1.3
Ruang Lingkup......................................................... 2
1.4
Tujuan dan Manfaat Penulisan ………..…….…….. 3
1.5
Metodologi Penelitian………………….....……..…... 4
1.6
Sistematika Penulisan ………………….....………... 5
LANDASAN TEORI
2.1
Teori Perancangan Sistem ...................................... 6
2.1.1 Pengertian Perancangan Sistem .................. 6
2.2
Teori Database ........................................................ 6
2.2.1 Pengertian Database..................................... 6
2.2.2 Data Definition language (DDL) .................. 7
2.2.3 Data Manipulation Language (DML)............. 7
viii
2.2.4 Data Control Language (DCL) ...................... 8
2.2.5 Normalisasi ................................................... 8
2.2.6 Siklus Hidup Aplikasi Database .................. 11
2.2.7 Desain
Konseptual,
Logical,
Fisikal
Database.................................................... 13
2.3
Microsoft .NET ...................................................... 25
2.3.1 Mengenal .NET Framework ....................... 27
2.3.2 Mengenal ASP.NET ................................... 29
2.3.3 Anatomi Aplikasi ASP.NET ........................ 31
2.4
Tori Internet ........................................................... 32
2.4.1 Internet........................................................ 32
2.4.2 WWW (World Wide Web) ........................... 33
2.4.3 URL (Uniform Resource Locator) ............... 33
2.4.4 HTML (HiperText Markup Language) ........ 33
2.4.5 Pengertian Hosting ..................................... 34
2.4.5.1 Shared Hosting ............................ 34
2.4.5.2 Dedicated Server ......................... 35
2.4.5.3 Colocation Server ........................ 35
2.4.5.4 Leased Line ................................. 35
2.5
Teori Umum .......................................................... 36
2.5.1 Pengertian Perguruan Tinggi ............... .. 36
2.5.2 Pengertian Penjadwalan ......................... 36
BAB III :
Analisis Sistem
3.1
Gambaran Umum Perguruan Tinggi Raharja........ 37
3.1.1 Sejarah
Singkat
Perguruan
Tinggi
Raharja........................................................ 37
3.1.2 Visi dan Misi ............................................... 39
3.1.3 Struktur Organisasi ..................................... 41
ix
3.1.4 Prosedur Sistem JRS dan KRS................... 42
3.1.5 Analisis Masalah ........................................ 43
3.1.6 Solusi Masalah ........................................... 43
BAB IV :
Perancangan Sistem Basis Data
4.1
Perancangan Sistem Basis Data …………………... 45
4.2
Database Planning ………………………………….. 45
4.2.1
Mission
Statement
Sistem
Basis
Data
Akademik…………….………………………. 45
4.2.2
Mission
Objective
Sistem
Basis
Data
Akademik ……………..……………………... 46
4.3 System Definition ……………….…………………….. 46
4.4 Requirements collection and Analysis ……………... 47
4.4.1
Spesifikasi Kebutuhan User …………….… 48
4.4.2
Spesifikasi Kebutuhan Sistem ……………. 50
4.5 Perancangan Sistem Basis Data………………….… 51
4.5.1
Perancangan Basis Data Konseptual …… 51
4.5.1.1 Identifikasi Entitas ……………….. 52
4.5.1.2 Identifikasi Tipe Relational ….….. 54
4.5.1.3 Identifikasi Atribut ………..…….… 57
4.5.1.4 Identifikasi Candidate and primary
key ............................................... 67
4.5.1.5 Mempertimbangkan
Penggunaan
Model Enhanced ……………….… 69
4.5.1.6 Validasi Transaksi ….………….… 70
4.5.2
Perancangan Basis Data Logikal …………. 72
4.5.2.1 Menghilangkan
Fitur
yang
tidak
Kompatibel ……………………….. 72
x
4.5.2.2 Menentukan
Model
Logikal
Data
Lokal ……………………………… 73
4.5.2.3 Mendefinisikan
Kendala
Integrity
……………………………………… 84
4.5.2.4 Data Model Lokal Logikal ……… 107
4.5.3
Perancangan Basis Data Fisikal ………… 108
4.5.3.1 Perancangan Relasional Basis Data
…………………………………….. 108
4.5.3.2 Analisis Transaksi …………….…128
4.5.3.3 Estimasi
Kapasitas
Penyimpanan
yang Dibutuhkan ……….………..132
4.6 Seleksi DBMS …………………………………..….… 143
BAB V :
KESIMPULAN DAN SARAN
5.1 Kesimpulan ……………………...………....…………. 147
5.2 Saran ……………………………………………..….… 147
DAFTAR PUSTAKA
LAMPIRAN
xi
DAFTAR TABEL
Tabel 3.1
Jurusan / Program Studi di STMIK-RAHARJA ...
39
Tabel 4.1
User view Basis Data …………………………….
47
Tabel 4.2
Identifikasi Entitas ………………………………..
52
Tabel 4.3
Identifikasi Tipe Relasional ………………………
56
Tabel 4.4
Identifikasi Atribut jenis_mk ……………………..
57
Tabel 4.5
Identifikasi Atribut jurusan ……………………….
57
Tabel 4.6
Identifikasi Atribut klmpk_mk ……………………
57
Tabel 4.7
Identifikasi Atribut tb_prasyarat …………………
58
Tabel 4.8
Identifikasi Atribut tb_ajar ………………………..
58
Tabel 4.9
Identifikasi Atribut tb_dosen …………………….
59
Tabel 4.10
Identifikasi Atribut tb_jadwal …………………….
60
Tabel 4.11
Identifikasi Atribut tb_kelas ………………………
61
Tabel 4.12
Identifikasi Atribut tb_konsentrasi ………………
62
Tabel 4.13
Identifikasi Atribut tb_krs …………………………
62
Tabel 4.14
Identifikasi Atribut tb_kurikulum …………………
63
Tabel 4.15
Identifikasi Atribut tb_mhs ……………………….
63
Tabel 4.16
Identifikasi Atribut tb_nilai ……………………….
65
Tabel 4.17
Identifikasi Atribut tb_ruang ……………………..
65
Tabel 4.18
Identifikasi Atribut tb_status …………………….
66
Tabel 4.19
Identifikasi Atribut tb_login_mhs ………………..
66
xii Tabel 4.20
Identifikasi Atribut tb_login_dosen ………………
66
Tabel 4.21
Identifikasi Atribut tb_buka_mk ………………….
66
Tabel 4.22
Identifikasi Kandidat dan Primary Key ………….
67
Tabel 4.23
Required Data jenis_mk …………………………
85
Tabel 4.24
Required Data jurusan ……………………………
85
Tabel 4.25
Required Data klmpk_mk ………………………..
85
Tabel 4.26
Required Data tb_prasyarat ……………………..
86
Tabel 4.27
Required Data tb_ajar ……………………………
86
Tabel 4.28
Required Data tb_dosen …………………………
87
Tabel 4.29
Required Data tb_jadwal …………………………
88
Tabel 4.30
Required Data tb_kelas ………………………….
89
Tabel 4.31
Required Data tb_konsentrasi …………………..
89
Tabel 4.32
Required Data tb_krs …………………………….
90
Tabel 4.33
Required Data tb_kurikulum …………………….
90
Tabel 4.34
Required Data tb_mhs ……………………………
91
Tabel 4.35
Required Data tb_nilai ……………………………
92
Tabel 4.36
Required Data tb_ruang ………………………….
93
Tabel 4.37
Required Data tb_status …………………………
93
Tabel 4.38
Required Data tb_buka_mk …………………….
94
Tabel 4.39
Required Data tb_login_mhs ……………………
94
Tabel 4.40
Required Data tb_login_dosen …………………
94
Tabel 4.41
Entitas Integrity ……………………………………
95
xiii Tabel 4.42
Referential Integrity pada entitas tb_mhs ke
jurusan………………………………………………
Tabel 4.43
Referential Integrity pada entitas tb_konsentrasi
ke jurusan ………………………………………….
Tabel 4.44
104
Referential Integrity pada entitas tb_buka_mk
ke tb_kurikulum ……………………………………
xiv 103
Referential Integrity pada entitas tb_kelas ke
tb_buka_mk ………………………………………
Tabel 4.52
102
Referential Integrity pada entitas tb_jadwal ke
tb_kelas ……………………………………………
Tabel 4.51
102
Referential Integrity pada entitas tb_jadwal ke
tb_ruang ……………………………………………
Tabel 4.50
101
Referential Integrity pada entitas tb_jadwal ke
tb_dosen ………………………………………….
Tabel 4.49
100
Referential Integrity pada entitas tb_ajar ke
tb_dosen ………………………………………….
Tabel 4.48
100
Referential Integrity pada entitas tb_dosen ke
tb_status …………………………………………...
Tabel 4.47
99
Referential Integrity pada entitas tb_kurikulum
ke tb_konsentrasi …………………………………
Tabel 4.46
98
Referential Integrity pada entitas tb_kurikulum
ke jurusan ………………………………………….
Tabel 4.45
98
104
Tabel 4.53
Referential Integrity pada entitas tb_nilai ke
tb_krs………………………………………………
Tabel 4.54
Referential Integrity pada entitas tb_krs ke
tb_mhs………………………………………………
Tabel 4.55
105
106
Referential Integrity pada entitas tb_krs ke
tb_jadwal …………………………………………..
106
Tabel 4.56
Representasi Fisikal ………………………………
129
Tabel 4.57
Estimasi Kapasitas Penyimpanan jenis_mk …...
133
Tabel 4.58
Estimasi Kapasitas Penyimpanan jurusan ……..
133
Tabel 4.59
Estimasi Kapasitas Penyimpanan klmpk_mk ….
133
Tabel 4.60
Estimasi Kapasitas Penyimpanan tb_ajar ……..
134
Tabel 4.61
Estimasi Kapasitas Penyimpanan tb_dosen ….
135
Tabel 4.62
Estimasi Kapasitas Penyimpanan tb_jadwal ….
136
Tabel 4.63
Estimasi Kapasitas Penyimpanan tb_kelas ……
137
Tabel 4.64
Estimasi Kapasitas Penyimpanan
tb_konsentrasi…………………………………….
137
Tabel 4.65
Estimasi Kapasitas Penyimpanan tb_krs ………
138
Tabel 4.66
Estimasi Kapasitas Penyimpanan
tb_kurikulum……………………………………….
139
Tabel 4.67
Estimasi Kapasitas Penyimpanan tb_mhs …….
140
Tabel 4.68
Estimasi Kapasitas Penyimpanan tb_nilai …….
141
Tabel 4.69
Estimasi Kapasitas Penyimpanan tb_ruang …...
142
xv Tabel 4.70
Estimasi Kapasitas Penyimpanan tb_status …...
Tabel 4.71
Estimasi Kapasitas Penyimpanan
Tabel 4.72
tb_buka_mk………………………………………..
143
Perbandingan DBMS …………………………….
144
xvi 142
DAFTAR GAMBAR
Gambar 2.1
Siklus Hidup Aplikasi Database .........................
12
Gambar 2.2
Platform Microsoft.NET ......................................
26
Gambar 2.3
.NET Framework ................................................
28
Gambar 2.4
Aplikasi ASP.NET ..............................................
32
Gambar 4.1
System Definition …………………………………
47
Gambar 4.2
Entity Relationship Diagram ……………………..
55
Gambar 4.3
Model Enhanced …………………………………. 69
Gambar 4.4
Validasi Transaksi ………………………………...
71
Gambar 4.5
Relasi Many-to-Many ……………………………..
72
Gambar 4.6
Pemecahan Relasi Many-to-Many ……………...
73
Gambar 4.7
Binary Relationship jurusan dengan tb_mhs …
76
Gambar 4.8
Binary Relationship tb_krs dengan tb_nilai ……
77
Gambar 4.9
Binary Relationship tb_jurusan dengan
tb_konsentrasi …………………………………….
77
Gambar 4.10
Binary Relationship tb_jurusan ke tb dosen …..
78
Gambar 4.11
Binary Relationship tb_status ke tb_dosen ……
78
Gambar 4.12
Binary Relationship tb_dosen ke tb_ajar ………
79
Gambar 4.13
Binary Relationship tb_dosen ke tb_jadwal …...
80
Gambar 4.14
Binary Relationship tb_jadwal ke tb_kelas …….
80
Gambar 4.15
Binary Relationship tb_krs ke tb_jadwal ……….
81
xvii Gambar 4.16
Binary Relationship tb_konsentrasi ke
tb_kurikulum ……………………………………….
Gambar 4.17
82
Binary Relationship tb_jurusan ke
tb_kurikulum……………………………………….
82
Gambar 4.18
Binary Relationship Many to many (*:*) ………..
84
Gambar 4.19
Referential Integrity pada entitas tb_mhs ke
jurusan ……………………………………………..
Gambar 4.20
Referential Integrity pada tb_konsentrasi ke
jurusan ……………………………………………..
Gambar 4.21
101
Referential Integrity pada entitas tb_jadwal ke
tb_ruang …………………………………………..
xviii 101
Referential Integrity pada entitas tb_jadwal ke
tb_dosen …………………………………………..
Gambar 4.26
100
Referential Integrity pada entitas tb_ajar ke
tb_dosen …………………………………………..
Gambar 4.25
99
Referential Integrity pada entitas tb_dosen ke
tb_status …………………………………………...
Gambar 4.24
99
Referential Integrity pada entitas tb_kurikulum
ke tb_konsentrasi …………………………………
Gambar 4.23
98
Referential Integrity pada tb_kurikulum ke
jurusan ……………………………………………..
Gambar 4.22
97
102
Gambar 4.27
Referential Integrity pada entitas tb_jadwal ke
tb_kelas ……………………………………………
Gambar 4.28
Referential Integrity pada entitas tb_kelas ke
tb_buka_mk ………………………………………..
Gambar 4.29
Gambar 4.33
105
Referential Integrity pada entitas tb_krs ke
tb_jadwal …………………………………………..
106
Model Lokal Logikal ………………………………
107
xix 105
Referential Integrity pada entitas tb_krs ke
tb_mhs ……………………………………………..
Gambar 4.32
104
Referential Integrity pada entitas tb_nilai ke
tb_krs ……………………………………………….
Gambar 4.31
103
Referential Integrity pada entitas tb_buka_mk
ke tb_kurikulum ……………………………………
Gambar 4.30
103
DAFTAR LAMPIRAN
Lampiran 1
Prototype
Lampiran 2
Surat Jawaban Penelitian
xx ABSTRAK
Perguruan tinggi merupakan salah satu jenis dari berbagai
bidang pendidikan yang ada. Berbagai macam siklus informasi
bergulir setiap harinya. Sistem informasi menjadi sangat penting
untuk dapat menangani perpindahan informasi yang cepat.
Salah satu siklus informasi yang ada dalam perguruan
tinggi adalah proses pembuatan JRS (Jadwal Rencana Studi) dan
Registrasi KRS (Kartu Rencana Studi). Proses pembuatan JRS pada
Perguruan TInggi Raharja membutuhkan waktu 1 sampai 2 bulan,
hal tersebut dikarenakan pertukaran informasi antara Kajur, Dosen,
dan RPU (Registrasi Perkuliahan dan Ujian) masih dilakukan secara
manual. Sedangkan untuk registrasi KRS (Kartu Renvcana Studi),
mahasiswa harus melakukan registrasi sebanyak tiga kali, untuk
mendapatkan KST-Final (Kartu Studi Tetap – Final).
Berdasarkan hal tersebut maka diperlukan perancanagn
sistem basis data Jadwal Rencana Studi dan Kartu Rencana Studi
untuk
di
olah
menjadi
informasi
yang
dapat
mempercepat
pertukarannya.
Kata kunci : Sistem Basis Data, Jadwal Rencana Studi, Kartu
Rencana Studi, Registrasi Perkuliahan dan Ujian, Kartu Studi Tetap
Final.
xxi BAB I
PENDAHULUAN
1.1
Latar Belakang
Perguruan tinggi merupakan salah satu jenis dari berbagai
bidang pendidikan yang ada. Berbagai macam siklus informasi baik
seputar kampus, mahasiswa, dosen maupun lingkungan seputar bergulir
setiap harinya. Sistem informasi menjadi hal yang sangat penting demi
menunjang kelancaran proses belajar mengajar khususnya bagi suatu
perguruan tinggi.
Salah satu siklus informasi yang ada dalam perguruan tinggi
adalah proses penjadwalan dan registrasi KRS (Kartu Rencana Studi).
Proses KRS adalah istilah yang diperuntukkan bagi proses registrasi
mata kuliah yang harus dilakukan oleh mahasiswa. Dalam proses KRS
ini mahasiswa harus memilih mata kuliah yang harus diambilnya, beserta
kelas dan jadwalnya berdasarkan daftar mata kuliah dengan jadwal dan
kelas yang dibuka. Pemilihan dan penyusunan mata kuliah yang dipilih
beserta jadwal dan kelasnya ini tidak bisa lepas dari proses penjadwalan
yang dilakukan oleh pihak akademik sebelumnya.
Sistem penjadwalan yang diterapkan pada perguruan tinggi
Raharja adalah JRS (Jadwal Rencana Studi), pada pelaksanaannya
proses pembuatan JRS menimbulkan kesulitan, seperti waktu yang
diperlukan untuk pembuatan JRS relatif lama yaitu sekitar 1-2 bulan.
Lamanya proses pembuatan JRS tesebut karena masih dilakukan secara
manual. Begitu pula dengan proses transakasi KRS yang diterapkan oleh
perguruan
mahasiswa
tinggi
yang
Raharja
ingin
menimbulkan
melakukan
kesulitan
transaksi
terutama
KRS.
Salah
bagi
satu
penyebabnya adalah kapasitas kelas yang tersedia sangat terbatas dan
lebih sedikit jumlahnya jika dibandingkan dengan jumlah mahasiswa
yang melakukan transaksi KRS ini. Hal ini menyebabkan mahasiswa
seringkali
harus
berebutan
dengan
1
mahasiswa
lainnya
untuk
2
mendapatkan matakuliah dengan jadwal dan kelas yang diinginkan.
Tidak semua mata kuliah yang diambil itu sesuai dengan pilihannya
semula karena mahasiswa harus menyesuaikan jadwal matakuliah
pilihannya dengan jadwal dan kapasitas kelas yang tersisa, yang terus
berubah-ubah. Tentu saja hal ini membuat proses transaksi KRS menjadi
suatu hal yang menyulitkan mahasiswa.
Berdasarkan permasalahan tersebut, maka pada laporan tugas
akhir ini akan dirancang sistem basis data JRS (Jadwal Rencana Studi)
dan KRS (Kartu Rencana Studi) pada Perguruan Tinggi Raharja.
1.2
Perumusan Masalah
Berdasar latar belakang masalah, dan untuk memenuhi studi
penerapan sistem basis data, maka perumusan masalah yang diangkat
adalah :
1.
Bagaimana merancang sistem basis data yang dibutuhkan
untuk sistem akademik dengan mengunakan pemodelan
relasional basis data ?
2.
Bagaimana merancang aplikasi yang dapat mengolah data dari
sistem basis data dengan menggunakan bahasa pemrograman
ASP.Net dan basis data SQL Server 2000.
1.3
Ruang Lingkup
Ruang lingkup dalam penulisan tugas akhir ini adalah :
1.
Analisis dilakukan pada bagian Registrasi Perkuliahan dan Ujian
(RPU) Perguruan Tinggi Raharja.
2.
Hanya membahas sistem penjadwalan kuliah (JRS) dan sistem
pengisian kartu rencana studi (KRS).
3.
Prototype yang dirancang adalah sistem JRS dan KRS berbasis
web, dengan menggunakan ASP.Net.
3
1.4
Tujuan dan Manfaat
1.
Tujuan
Tujuan yang ingin dicapai dalam tugas akhir ini adalah
sebagai berikut :
•
Memberikan gambaran dalam perancangan sistem basis
data JRS dan KRS menggunakan daur hidup basis data
“Connolly”.
•
Menghasilkan prototype JRS dan KRS berbasis web.
•
Menghasilkan dokumentasi prototype perancangan sistem
basis data JRS dan KRS.
2.
Manfaat
Sedangkan manfaat yang ingin dicapai dalam tugas
akhir ini adalah sebagai berikut :
•
Menyusun JRS (Jadwal Rencana Studi) yang dapat
disimpan,
ditulis,
dibaca,
dikelola
oleh
pihak
RPU
(Registrasi Perkuliahan dan Ujian).
•
JRS (Jadwal Rencana Studi) menghasilkan KRS (Kartu
Rencana Studi) yang dapat diakses oleh mahasiswa.
•
Menghasilkan laporan peserta kelas, laporan jadwal
mengajar dosen, laporan nilai mahasiswa dan pemakaian
ruangan.
1.5
Metodologi Penelitian
Metode yang digunakan dalam penulisan tugas akhir ini
menggunakan beberapa metode penulisan antara lain :
1.
Metode Pengumpulan Data
a.
Metode Studi Kepustakaan
Mempelajari teori – teori literatur dari buku atau internet
yang berhubungan dengan objek penelitian sebagai bahan
dasar dalam penulisan.
4
b.
Metode Observasi
Mengadakan pengamatan pada proses registrasi KRS di
Perguruan Tinggi Raharja.
c.
Metode Wawancara
Mengadakan tanya jawab secara langsung dengan pihak –
pihak yang terkait dan berkepentingan secara langsung
dengan sistem KRS guna mendapatkan data yang akurat.
2.
Metode Analisis
Meliputi perancangan Flowchart sebagai representasi grafik
penggambaran
proses
yang
berjalan,
studi
kelayakan
pereancangan.
3.
Metode Database Life Cycle
Metode Database Life Cycle, yang diajukan oleh Connolly
(2002). Digunakan untuk perancangan Sistem Basis Data atau
database, yang melalui tahapan-tahapan berikut ini :
a.
Perencanaan database
b.
Mendefinisikan sistem
c.
Pengumpulan dan penganalisaan kebutuhan
d.
Merancang database
e.
Memilih DBMS
f.
Prototype
5
1.6
Sistematika Penulisan
Untuk mempermudah dalam penulisan tugas akhir ini, maka
dapat disusun sistematika penulisan secara garis besar sebagai berikut :
BAB I
PENDAHULUAN
Pada Bab ini berisi latar belakang, perumusan
masalah, ruang lingkup, tujuan dan manfaat, metodologi
penelitian, dan sistematika penulisan
BAB II
LANDASAN TEORI
Pada bab ini dipaparkan teori yang dipakai dalam
menganalisis sistem yang sedang berjalan.
BAB III ANALISIS SISTEM
Pada bab ini berisi riwayat universitas, struktur
organisasi dan pembagian divisi tugas dalam universitas, sistem
akademik yang sedang berjalan, permasalahan yang dihadapi,
usulan pemecahan masalah.
BAB IV PERANCANGAN DAN IMPLEMENTASI SISTEM
Pada bab ini berisi perancangan kebutuhan sistem,
perancangan database, relasi tabel, perancangan masukan,
perancangan keluaran.
BAB V
PENUTUP
Pada bab ini berisi simpulan dari inti penelitian yang
dilakukan dan hasil penelitian yang didapatkan, serta saran
yang dapat dijadikan sebagai bahan pertimbangan untuk
pengembangannya lebih lanjut.
BAB II
LANDASAN TEORI
2.1
Teori Perancangan
2.1.1 Pengertian Perancangan Sistem
Perancangan
sistem
adalah
penggambaran,
perencanaan, dan pembuatan sketsa atau pengaturan dari
beberapa elemen terpisah ke dalam satu kesatuan yang utuh
Menurut Mcleod (2001, p192) mengemukakan bahwa
perancangan sistem adalah penentuan proses dan data yang
diperlukan oleh sistem baru jadi sistem itu berbasis komputer
sehingga sistem dapat menyertakan spesifikasi jenis peralatan
yang digunakan
2.2
Teori Database
2.2.1 Pengertian Database
Menurut Bambang Hariyanto (p4, 2004), basisdata
adalah kumpulan data ( Elementer ) yang secara logic berkaitan
dalam merepresentasikan fenomena/fakta secara terstruktur
dalam domain tertentu untuk mendukung aplikasi pada sistem
tertentu.
Basisdata
mendeskripsikan
state
rganisasi/perusahaan/sistem. Saat satu kejadian muncul didunia
nyata mengubah state organisasi/perusahaan/sistem maka satu
perubahan pun harus dilakukan terhadap data yang disimpan di
basisdata.
Connolly (2002, p14) menjelaskan, database adalah
suatu kumpulan logical data yang terhubung satu sama lain dan
deskripsi dari data yang dirancang sebagai informasi yang
dibutuhkan oleh organisasi.
C.J Date (1999, p5), suatu sistem database adalah
suatu sistem yang pada dasarnya menyimpan record – record
6
7
didalam suatu file yang dilakukan secara komputerisasi yang
tujuannya
secara
keseluruhan
adalah
untuk
memelihara
informasi dan untuk membuat informasi tersebut tersedia
berdasarkan permintaan.
2.2.2 Data Definition Language (DDL)
Definisi dari Data Definition Language (DDL) menurut
Connolly (2002, p40), yaitu merupakan suatu bahasa yang
memperbolehkan Data Administrator (DBA) atau user untuk
mendeskripsikan nama dari suatu entity, atribut, dan relasi data
yang diminta oleh aplikasi, bersamaan dengan integritas data
dan batasan keamanan datanya.
Dijelaskan juga oleh Bambang Hariyanto ( 2004, p110
), DDL berfungsi untuk menspesifikasikan skema atau struktur
basisdata. Hasil dari pernyataan DDL adalah himpunan definisi
data yang disimpan dikamus data (data dictionary atau data
directory) secara khusus. Hasil kumpulan definisi adalah
himpunan
instruksi
yang
menspesifikasikan
rincian
implementasi skema basis data tidak tampak dari pemakai.
2.2.3 Data Manipulation Language (DML)
Definisi dari Data Manipulation Language (DML)
menurut Connolly (2002, p41) adalah suatu bahasa yang
memberikan fasilitas pengoperasian data yang ada didalam
database.
Pengoperasian data yang akan dimanipulasi biasanya
meliputi :
1.
Perubahan data baru kedalam database.
2.
Modifikasi data yang disimpan kedalam database.
3.
Pengembalian data yang terdapat didalam database.
4.
Penghapusan data dari database.
8
Bambang Hariyanto (2004, p110) menjelaskan bahwa
DML berisi sekumpulan operasi manipulasi data di basisdata.
DML disebut bahasa query ( meminta Informasi ) ke basis data
karena komponen paling kompleks adalah opeerasi query. DML
sesungguhnya tidak cuma berisi query, tapi juga berupa
perintah INSERT, UPDATE dan DELETE namun bagian query
adalah yang paling pokok atau kompleks.
Query adalah pernyataan untuk meminta informasi
sebagai bagian DML untuk pengambnilan informasi. Istilah
query language tidak benar bila disinonimkan dengan DML
dimana query adalah bagian dari manipulation.
2.2.4 Data Control Language (DCL)
Menurut Bambang Hariyanto (2004, p113), DCL
merupakan subbahasa untuk mengendalikan struktur internal
basisdata. DCL digunakan untuk menyesuaikan sistem agar
efisien. DCL sangat bergantung vendor.
2.2.5 Normalisasi
Menurut Connolly (2002, p376), normalisasi adalah
suatu teknik untuk menghasilkan sebuah relasi dengan property
yang dibutuhkan dan memberikan kebutuhan data dari sebuah
perusahaan.
Tujuan dari normalisasi adalah sebagai berikut :
a.
Menghilangkan
kumpulan
updating,
delete
dan
relasi
dari
dependency
inserting,
yang
tidak
diharapkan.
b.
Mengurangi kebutuhan restrukturisasi kumpulan relasi
meningkatkan life spam program aplikasi.
c.
Membuat model relational lebih informative.
9
Dijelaskan oleh Bambang Hariyanto (2004, p69),
normalisasi adalah pemrosesan relasi-relasi menjadi bentuk
normal lebih tinggi. Dengan demikian tujuan proses normalisasi
adalah mengkonversi relasi menjadi bentuk normal lebih tinggi.
Kriteria
kebergantungan
dalam
proses
fungsional
(
normalisasi
functional
adalah
dependency
),
kebergantungan banyak nilai dan kebergantungan join ( join
dependency ). Ketiga tipe kebergantungan tersebut digunakan
untuk menilai relasi-relasi yang dihasilkan dari konversi diagram
ER menjadi kumpulan relasi – relasi. Proses normalisasi
membentuk relasi – relasi bentuk normal menggunakan
dekomposisi yang memecah relasi menjadi relasi – relasi
berbentuk normal lebih tinggi. Namun kita belum tentu perlu
bentuk normal tertinggi.
Berikut adalah Proses normalisasi :
1.
Bentuk normal pertama (1NF)
Bentuk
normal
pertama
adalah
ekivalen
dengan definisi model relasional. Relasi adalah bentuk
normal pertama (1NF) jika semua nilai atributnya
sederhana (bukan komposit).
2.
Bentuk normal kedua (2NF)
Sedangkan ketentuan bentuk normal kedua
adalah :
a.
harus telah berbentuk normal pertama (1NF).
b.
Semua atribut bukan utama harus bergantung
fungsional penuh pada kunci relasi.
Pada bentuk normal kedua (2NF), relasi harus
tidak menyimpan fakta – fakta mengenai bagian kunci
10
relasi.
Bentuk
normal
kedua
menghilangkan
kebergantungan parsial. Bentuk normal kedua pun
masih memiliki anomali – anomali yang secara praktis
tidak dapat diterima. Kita harus mengusahakan relasi –
relasi di basisdata berada minimal dalam bentuk
normal ketiga.
3.
Bentuk normal ketiga (3NF)
Ketentuan bentuk normal ketiga adalah
a.
Harus telah berbentuk normal kedua (2NF).
b.
Relasi
tidak
boleh
memuat
kebergantungan
fungsional diantara atribut – atribut bukan utama.
Bentuk
normal
ketiga
menghilangkan
kebergantungan transitif. Mulanya bentuk normal
ketiga dipikir sebagai bentuku normal puncak/paling
akhir. Namun, kemudian dapat ditemukan bentuk
normal lebih kuat yaitu bentuk normal Boyce-Codd.
4.
Bentuk normal Boyce-Codd (BCNF – Boyce Codd
Normal Form )
Ketentuan BCNF :
a.
Masing – masing atribut utama bergantung
fungsional penuh pada masing – masing kunci
dimana kunci tersebut bukan bagiannya.
b.
Atau dengan kalimat lain : Relasi adalah BCNF
(yaitu optimal) jika setiap determinan atribut –
atribut relasi adalah kunci relasi.
11
Relasi adalah optimal (BCNF) jika kapanpun fakta –
fakta disimpan mengenai beberapa atribut maka atribut – atribut
ini merupakan satu kunci relasi.
BCNF dapat memiliki lebih dari satu kunci. Properti
penting BCNF adalah relasi tidak memiliki informasi yang
redundan.
2.2.6 Siklus Hidup Aplikasi Database
Dalam
perancangan
database
kita
juga
haris
memperhatikan tentang siklus hidup aplikasi database. Suatu
sistem database seperti didefinisika oleh Connolly (2002, p271)
disebutkan bahwa merupakan suatu dasar bagi komponen dari
organisasi dengan sistem informasi yang besar.
Sangatlah penting untuk diperhatikan bahwa struktur
dari siklus hidup aplikasi database tidaklah harus benar – benar
sekuensial, tetapi terlibat dalam suatu perulangan dari bagan –
bagan yang sebelumnya melalui umpan balik. Sebagai contoh,
masalah yang dihadapi selama perancangan database adalah
masih diperlukannya analisis dan pengumpulan data tambahan.
Untuk aplikasi database kecil dengan jumlah pengguna
yang
sedikit,
siklus
hidup
tidaklah
sangat
komplek.
Bagaimanapun juga, ketika perancangan sedang dilakukan
pada suatu aplikasi database ukuran sedang dengan jumlah
pengguna
antara
sepuluh
dengan
ribuan
user,
dengan
menggunakan ratusan queries dan program aplikasi, siklus
hidup akan menjadi komplek.
Gambar 2.1 dibawah ini
merupakan siklus hidup aplikasi database :
12
Database Planning
System Definition
Requirement collection &
Analysis
Database Design
Conceptual
Database Design
DBMS Selection
(Optimal)
Application
Design
Logical Database
Design
Physical
Database Design
Prototyping
(Optional)
Implementation
Data Conversion &
Loading
Testing
Operational
Maintenance
Gambar 2.1. Siklus Hidup Aplikasi Database
(Sumber : Connolly, 2002, p272)
13
1.
Database Planning
Merencanakan bagaimana tahapan-tahapan
dari daur hidup (life Cycle) dapat direalisasikan secara
efektif dan efisien
2.
System Definition
Menspesifikasikan ruang lingkup dan batasan
dari aplikasi database, pengguna dan area aplikasi.
3.
Requirements Collection and Analysis
Mengumpulkan dan menganalisis kebutuhan
dari pemakai dan area aplikasi.
4.
Database design
Desain database komseptual, logikal dan
fisikal.
5.
DBMS Selection
Memilih DBMS yang cocok untuk aplikasi
database.
2.2.7 Desain Konseptual, Logical, Fisikal Database
Urutan metodologi yang ada menurut Connolly (2002,
p420) antara lain :
1.
Desain Konseptual Database
Tujuan dari design konseptual database menurut
Connolly
pembuatan
digunakan
(2002,
suatu
di
independensinya
p281)
adalah
model
dari
dalam
tidak
untuk
informasi
memproses
yang
suatu
organisasi,
tergantung
dengan
akan
yang
apapun.
Langkah-langkah dalam pembuatan model konseptual
database adalah :
14
Langkah 1 : Membangun model data konseptual local
untuk setiap bagian.
Langkah 1.1 : Mengidentifikasi tipe entity
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi entity utama yang diminta oleh user.
Langkah
pertama
yang
diperlukan
dalam
membangun suatu lokal konseptual data model adalah
untuk mengidentifikasi objek utama atau entity dimana user
memang membutuhkannya. Salah satu metode untuk
mengidentifikasi tipe entity yang utama adalah dengan
mengidentifikasi kata benda atau frase kata benda yang
telah disebutkan user.
Langkah 1.2 : Mengidentifikasi tipe Relasi
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi relasi yang penting antara berbagai tipe
entity
yang
telah
diidentifikasikan.
Biasanya
relasi
diidentifikasi dengan menggunakan kata kerja atau frase
kata kerja
Adapun langkah-langkah dalam mengidentifikasi
tipe relasi adalah sebagai berikut :
1.
Gunakan Entity Relationship Diagram (ERD)
Hal yang sering terjadi adalah pengguna akan
lebih cepat mengerti suatu perancangan database
dengan
cara
visualisasi
di
banding
dengan
perancangan database yang dituliskan dalam bentuk
tekstual.
Dalam
hal
ini,
ERD
digunakan
untuk
mempresentasikan entity dan bagaimana relasi antar
entity.
15
2.
Tentukan Pembatas Multiplicity dari Tipe Relasi.
Setelah mendapat relasi antar entity, maka
langkah berikutnya adalah menentukan multiplicity
setiap relasi, jika memang ada suatu nilai yang spesifik
dari suatu multiplicity maka akan lebih baik apabila di
dokumentasikan.
3.
Mencek Fan dan Chasm Traps
Setelah relasi yang dibutuhkan antar entity
didefinisikan, maka langkah berikutnya adalah mencek
fan dan chasm traps.
Definisi fan traps adalah suatu model yang
mempresentasikan suatu relasi antar entity, tetapi alur
relasinya memperlihatkan ambiguitas.
Definisi chasm traps adalah suatu model
dimana terdapat hubungan antar entity yang satu
dengan yang lain, tetapi tidak ada relasi kedua entity
yang utama.
4.
Setiap entity mempunyai sebuah relasi
Pada pembuatan ERD, pastikan setiap entity
mempunyai minimal satu relasi dengan entity lain, jika
memang setiap entity sudah memiliki satu relasi
dengan entity yang lain, maka langkah berikutnya
adalah memperhatikan kamus data.
Langkah 1.3 : Mengidentifikasi dan mengasosiasikan
atribut suatu entity atau tipe relasi.
16
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi dan mengasosiasikan atribut dari entity
atau tipe relasi.
Simple atau Composite Atribut
Perlu diperhatikan apakah suatu atribut tertentu itu
simple atau composite. Composite atribut adalah atribut
yang membangun dari simple atribut. Sebagai contoh,
atribut alamat bisa saja dibuat simple dan menyimpan
beberapa detail dari alamat sebagai suatu nilai, contoh: Jln.
Jendral Sudirman 25, Jakarta, 12345. bagaimanapun juga
atribut alamat dapat merepresentasikan sebuah composite
atribut, yang terdiri dari beberapa detail yang mempunyai
nilai terpisah dalam atribut nama jalan(“Jln. Jendral
Sudirman 25”), Kota(“Jakarta”), dan Kodepos(“12345”).
Atribut alamat dapat dijadikan simple atribut atau composite
atribut tergantung dengan kebutuhan user.
Single atau Multi Value Atribut
Suatu atribut juga dapat mempunyai satu atau
lebih nilai, contoh : atribut nomor telepon, seseorang bisa
saja mempunyai nomor telepon lebih dari satu keadaan
seperti itu dapat disebut multi value atribut, tetapi apabila
atribut tertentu hanya mempunyai satu nilai maka disebut
single atribut.
Derived Atribut
Derived atribut
adalah
atribut
yang nilainya
tergantung dengan nilai atribut yang lain. Contoh : umur
seorang staff, banyaknya property yang di manage oleh
seorang staff.
17
Langkah 1.4 : Mengidentifikasikan Domain Atribut
Tujuan dari langkah ini adalah untuk menentukan
domain dari atribut yang ada di dalam local konseptual data
model. Contoh :
1.
Atribut dari nomor staff terdiri dari 5 karakter string
dimana 2 karakter utama merupakan huruf, sedangkan
3. karakter sisa berupa angka.
2.
Nilai yang mungkin untuk atribut sex adalah M atau F.
ini merupakan domain dari atribut yang menggunakan
karakter tunggal.
Langkah 1.5 : Mengidentifikasikan Candidate dan
Primary Key
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasikan candidate key dari setiap entity, dan
jika memang terdapat lebih dari satu candidate key, pilihlah
salah satunya untuk menjadi primary key. Pada saat
pemilihan primary key diantara banyak candidate key
gunakan petunjuk berikut untuk membantu seleksi :
1.
Merupakan candidate key dengan jumlah set paling
sedikit
2.
Merupakan candidate key yang nilainya jarang sekali
berubah
3.
Merupakan candidate key dengan jumlah karakter
paling sedikit
4.
Merupakan candidate key paling sedikit dari nilai
maksimalnya (untuk tipe atribut dengan tipe numeric)
5.
Merupakan
candidate
key
yang
digunakan dari sudut pandang user.
paling
mudah
18
Langkah 1.6 : Menggunakan Enhanced Modeling
Konsep (langkah optimal)
Tujuan
dari
mempertimbangkan
langkah
penggunaan
ini
adalah
enhanced
untuk
modelling
concepts seperti specialization, generalization, aggregation,
dan compotion
Jika pendekatan user merupakan specialization,
maka perhatian perbedaan yang dilihat secara maksimal
antara satu entity atau banyak subclass dan superclass
entity. Jika anda menggunakan pendekatan generalization,
maka anda akan mengidentifikasikan persamaan antara
entity yang ada untuk membentuk superclass.
Langkah 1.7 : Validasi Model Konseptual Lokal dengan
Transaksi User
Tujuan dari langkah ini adalah untuk memastikan
bahwa model konseptual local mendukung permintaan
transaksi oleh user. Pengujian dilakukan dengan dua
kemungkinan pendekatan yang mendukung permintaan
transaksi.
1.
Deskripsi transaksi
2.
Gunakan alur transaksi
Langkah 1.8 : Mereview Model Konseptual data local
dengan user
Tujuan dari langkah ini adalah untuk mereview
model
konseptual
data
local
bersama
user
guna
memastikan bahwa model yang ada sudah sesuai dengan
yang diminta
Hasil akhir dari perancangan konseptual database
adalah memproses pembuatan suatu model dari informasi
19
yang akan digunakan didalam suatu organisasi yang
independensi tidak tergantung pada apapun.
2.
Desain Logical Database
Adapun tujuan dari model logical data menurut
Connolly
(2002,
p281)
adalah
untuk
memproses
pembuatan suatu model informasi yang digunakan didalam
suatu organisasi berdasarkan model data yang spesifik,
tetapi tidak tergantung pada suatu DBMS dan perangkat
keras lainnya.
Langkah 2 : Membuat dan Memvalidasi Model Logikal
Data Untuk Setiap Bagian
Tujuan dari langkah ini adalah untuk membangun
suatu model logikal data lokal dari suatu model konseptual
data local
kemudian
yang mempresentasikan perusahaan dan
memvalidasi
model
ini
untuk
memastikan
strukturnya benar dan bahwa model tersebut mendukung
transaksi yang diminta
Langkah 2.1 : Menghilangkan Bagian yang Tidak
Sesuai dengan Model Relasi (Langkah Optional)
Tujuan dari langkah ini adalah untuk memperbaiki
model konseptual lokal data dengan menghilagkan featurefeature yang tidak kompatibel dengan model relasi. Bagian
yang akan dibahas pada langkah ini antara lain :
1.
Menghilangkan Many-to-Many ( * . * )
tipe relasi
binary.
2.
Menghilangkan Many-to-Many ( * . * ) tipe relasi
rekursif.
3.
Menghilangkan tipe relasi komplek.
20
4.
Menghilangkan multi value atribut.
Langkah 2.2 : Menganalisis relasi untuk membuat
logical data local
Tujuan dari langkah ini adalah untuk membuat
suatu
relasi
untuk
model
logical
data
local
yang
mempresentasikan suatu entity, relasinya dan juga atribut
yang
telah
diidentifikasi.
Adapun
pendeskripsian
bagaimana relasi dapat diturunkan dari struktur data model
yang ada sekarang, antara lain :
1.
Tipe entity kuat.
2.
Tipe entity lemah.
3.
One-to-Many ( 1 . * ) tipe relasi binary.
4.
One-to-One ( 1 . 1) tipe relasi binary.
5.
One-to-One ( 1 . 1) tipe relasi rekursif.
6.
Superclass atau subclass tipe relasi.
7.
Many-to-Many tipe relasi binary.
8.
Tipe relasi komplek.
9.
Atribut multi value.
Langkah 2.3 : Memvalidasi relasi dengan normalisasi
Tujuan dari langkah ini adalah untuk memvalidasi
relasi dalam model logical data local dengan menggunakan
teknik dari normalisasi. Tujuan dari normalisasi adalah
sebagai berikut :
1.
Menghilangkan
updating,
dan
kumpulan
delete
relasi
dari
dependensi
inserting,
yang
tidak
diharapkan
2.
Mengurangi kebutuhan restrukturisasi kumpulan relasi
dan meningkatkan file spam program aplikasi
3.
Membuat model relasional lebih informatife
21
Langkah 2.4 : Memvalidasi relasi dengan transaksi user
Tujuan dari langkah ini adalah untuk memastikan
bahwa relasi didalam model logical data local mendukung
transaksi yang diminta user. Pada langkah ini pengecekan
bahwa relasi yang dibuat langkah sebelumnya juga
mendukung transaksi ini benar dan pastikan juga bahwa
tidak ada error dalam relasi yang telah dibuat.
Langkah 2.5 : Mengecek integritas database
Tujuan
dari
langkah
ini
adalah
untuk
mendefinisikan ruang lingkup integritas yang diperlihatkan
kepada user. Dalam hal ini ada 3 tipe ruang lingkup
integritas, antara lain :
1.
Data yang diminta.
2.
Domain pembatas atribut.
3.
Integritas entity.
Yang
mendefisikan
suatu
entity
mempunyai
integritas ialah tidak adanya primary key yang kosong (null)
suatu
primary
key
merupakan
suatu
atribut
yang
mendefinisikan bahwa setiap record atau tuple itu unik satu
sama lain
1.
Integritas referensi
Jika terdapat suatu foreign key dalam suatu relasi,
maka nilainya harus sesuai dengan nilai candidate key
suatu record dimana foreign key tersebut ada atau
sepenuhnya kosong (null)
2.
Pembatas enterprise
22
Merupakan aturan tambahan yang dibuat oleh user
atau seorang database administrator dari database
tersebut
Langkah 2.6 : Mereview model logical data local
dengan user
Tujuan dari langkah ini adalah untuk membuat
dokumentasi yang mendeskripsikan model logical data
local sebagai representasi yang sesuai dengan keadaan
sebenarnya.
Langkah 3 : Membangun dan validasi global logical
data model
Menggabungkan individual logical data model
yang mempresentasikan suatu perusahaan.
Langkah 3.1 : Menggabungkan local logical data model
menjadi model global
Menggabungkan
individual
local
logical
data
model Menjadi single global logical data model yang
mempresentasikan suatu perusahaan.
Langkah 3.2 : Validasi global logical data model
Menvalidasi relasi yang diciptakan dari global
logical data model menggunakan teknik normalisasi dan
memastikan mereka mendukung transaksi yang dibutuhkan
jika diperlukan.
Langkah 3.3 : Memeriksa untuk pertumbuhan akan
datang
23
Menentukan
apakah
disana
ada
perubahan
signifikan seperti dalam masa depan yang dapat ditebak
dan menaksirkan apakah global logical data model dapat
mengakomondasi perubahan ini.
Langkah 3.4 : Review global logical data model dengan
pengguna
Memastikan bahwa global logical data model
adalah suatu kebenaran representasikan dari perusahaan.
3.
Design Fisikal Database
Perancangan fisikal basis data adalah proses
menghasilkan suatu deskripsi mengenai implementasi
basis data pada secondary storage, dia menggambarkan
dasar
relasi,
file
organisasi,
dan
indek-indek
yang
digunakan untuk mencapai efisiensi akses terhadap data,
dan semua integritas constrain dan pengukuran keamanan.
Langkah 4 : Menterjemahkan global logical data model
untuk sasaran DBMS
Menghasilkan skema relasi basis data dari global
logical data model yang dapat diimplementasikan dalam
sasaran DBMS.
Langkah 4.1 : Merancang relasi dasar
Memilih bagaimana mempresentasikan relasi data
diidentifikasikan dalam global logical data dalam sasaran
DBMS.
Langkah
4.2
:
memperoleh data
Merancang
representasi
untuk
24
Memilih bagaimana mempresentasikan data apa
saja yang diperoleh dalam global logical data model dalam
sasaran DBMS.
Langkah 4.3 : Perancangan costrain perusahaan
Perancangan constrains suatu perusahaan untuk
sasaran DBMS.
Langkah 5 : Perancangan representasi fisikal
Memastikan
file
organisasi
secara
optimal
menyimpan relasi dasar dan indek-indek yang dibutuhkan
untuk mencapai performa yang dapat diterima, itu adalah
cara dalam yang mana relasi dan tuples akan dipegang
pada secondary storage.
Langkah 5.1 : Analisis transaksi
Mengerti mengenai fungsional suatu transaksi
yang akan jalan pada basis data dan menganalisis
transaksi penting.
Langkah 5.2 : Memilih file organisasi
Memastikan suatu efisiensi file organisasi untuk
setiap relasi dasar.
Langkah 5.3 : Memilih indeks
Memastikan apakah penambahan indeks akan
memperbaiki performa suatu sistem.
Langkah
5.4
dibutuhkan
:
Memperkirakan
disk
space
yang
25
Memperkirakan jumlah disk space yang akan
dibutuhkan dalam basis data.
Langkah 6 : Perancangan user views
Merancang user views yang diidentifikasi selama
pengumpulan kebutuhan dan tahapan analisis suatu
aplikasi daur hidup basis data.
Langkah 7 : Perancangan tingkat keamanan
Perancangan tingkat keamanan untuk basis data
sebagai sfesifikasi oleh pengguna.
Langkah 8 : Mempertimbangkan pengenalan mengenai
pengontrolan Perulangan
Memastikan apakah memperkenalkan perulangan
dalam suatu pengontrolan dengan relaxing aturan-aturan
normalisasi akan memperbaiki performa suatu sistem.
Langkah 9 : Memonitor dan menjalankan sistem
operasional
Memonitor sistem operasional dan memperbaiki
performa suatu sistem untuk membenarkan perancangan
yang
tidak
dapat
atau
menggambarkan
perubahan
kebutuhan.
2.3
Microsoft .NET
Berdasarkan
sumber
http://www.mikroskil.ac.id/~andri/vb1-01.pdf
(
diakses 18-08-
2008 jam 9:00). Platform Microsoft .NET merupakan model
untuk development dimana platform dan aplikasi bisa dibuat dan
dijalankan tanpa bergantung pada alat ( device ) yang dipakai.
26
Komponen ini memungkinkan beberapa aplikasi bekerjasama,
di harddisk user, network lokal, komputer remote atau di
internet.
Dengan menggunakan Extensible Markup Language
(XML) yang sudah menjadi standar industri IT, platform .NET
memungkinkan seorang developer untuk membuat aplikasi
Windows dan Web menggunakan bahasa pemrograman yang
mendukung .NET dan aplikasi tersebut akan bisa digunakan
oleh semua (aplikasi) client yang mendukung penggunaan
.NET.
Gambar 2.2 Platform Microsoft .NET
Platform .NET terdiri dari lima komponen utama dalam
tiga lapisan (layer) :
1.
Lapisan terbawah adalah sistem operasi, yang merupakan
sistem operasi Windows 32bit, termasuk Windows XP,
Windows 2003, Windows 2000, Windows ME, dan
Windows CE.
27
2.
Lapisan kedua terdiri dari tiga produk :
a.
.NET Enterprise Server, dipakai untuk mengurangi
waktu yang dibutuhkan untuk membuat sistem bisnis
berskala besar seperti SQL Server, Aplication Center,
BizTalk Server, Commerce Server, dan lain-lain.
b.
.NET Building Block Services, merupakan distributed
programmable service yang tersedia secara online dan
ofline. Service bisa dijalankan dikomputer stand alone
ataupun diakses mengunakan internet. .NET Building
Block Services bisa digunakan dari platform apa saja
yang mendukung SOAP.
c.
.NET Framework, merupakan pusat dari platform .NET.
termasuk didalamnya adalah Common Language
Runtime (CLR) dan framework dari class yang bisa
digunakan oleh semua bahasa .NET. karenanya,
semua bahasa .NET akan menggunakan file runtime
yang sama, dalam arti bahwa tidak diperlukan runtime
library khusus untuk Visual Basic karena .NET runtime
file akan terinstal secara otomatis di versi-versi Widows
selanjutnya.
3.
Dilapisan teratas dari arsitektur .NET adalah Visual Studio
.NET
yang
memungkinkan
pembuatan
Web Sevice,
aplikasi Web dan aplikasi Windows secara cepat.
2.3.1
Mengenal .NET Framework
Definis .NET Framework secar formal adalah platform
yang memungkinkan kita untuk membangun aplikasi dan
library yang disebut dengan ”managed Aplications”. . NET
Framework menyediakan compiler dan tools agar kita dapat
membangun, debug, dan mengeksekusi managed aplications.
Kita dapat memilih bahasa visual basic, C++, C#, VBScript,
28
ataupun J# dalam membangun aplikasi dalam lingkungan
.NET.
Gambar 2.3 .NET Framework
Jadi, .NET adalah platform yang memberikan kita
segala sesuatu yang diperlukan untuk membangun dan
menjalankan Managed Application yang berjalan di Windows.
Managed Application adalah eksekusi dari aplikasi
tersebut diatur oleh .NET Framework yang menyediakan
lingkungan runtime yang terkendali dan menyediakan sangat
banyak variasi service
seperti Loading (memuat) aplikasi,
mengatur memori, dan monitoring sekuritas dan integritas ketika
aplikasi dijalankan sehingga aplikasi lebih mudah dipelihara dan
di-debug.
.NET Framework menyediakan tools seperti compilers,
debuggers, programming languages dan execution engine
29
(yang disebut dengan CLR – Common Language Runtime),
developers tools, dan library-library lainnya.
2.3.2
Mengenal ASP.NET
Berdasarkan
sumber
(http://www.mti.ugm.ac.id/~ridi/self/VWD-How-To-MICPress.pdf.
diakses 18-08-2008 jam 9:10). ASP.NET
yang mungkin
sudah
tak
asing
programmer.
Teknologi pengganti
diperkenalkan
pada
dengan
kisaran
sebuah
lagi
tahun
teknologi
ditelinga
ASP yang
2000-an
web
telah
bersamaan
.NET framework, menjadi salah satu standar
pengembangan
web
dinamis
yang
berskala
enterprise.
ASP.NET dapat didefinisikan sebagai platform teknologi yang
didesain
untuk
ASP.NET
mengembangkan
memungkinkan
aplikasi
berbasis
penggunanya
web.
untuk
mengembangkan aplikasi web yang dinamis, data-driven, dan
berbagai kemungkinan aplikasi lain yang berjalan di atas
sebuah web server. ASP.NET berdiri sebagai platform teknologi
yang secara langsung berkait dengan bahasa pemograman
berorientasi objek (seperti
C#),
framework
pengembangan
terkelola berbasis komponen (.NET), dan sebuah perangkat
bantu yang meningkatkan produktifitas pengembangan (seperti
Visual Web Developer).
ASP.NET bekerja dengan model pemograman yang
sedikit berbeda dengan ASP klasik ataupun PHP. ASP.NET
bekerja dengan suatu runtime eksekusi yang dikenal dengan
CLR (Common Language Runtime). CLR adalah suatu
lingkungan eksekusi terkelola
(managed) yang merupakan
bagian dari teknologi .NET framework. Linkungan terkelola
atau
lebih
dikenal
Arsitektur lingkungan
dengan
terkelola
“managed
environment”.
memberikan
berbagai
30
keuntungan
pada
teknologi
pengembangan
web
ini
diantaranya :
1.
Performa yang lebih baik, kode ASP.NET dikompilasi
oleh CLR. Hal ini yang membedakan teknologi web
ASP.NET dengan teknologi script web seperti ASP.
CLR
lebih
baik
beberapa
dari
sisi performa
optimalisasi
performa
karena
melalui
memiliki
just-in-time
execution, caching, hingga native optimazation. Konsepnya
tidaklah terlalu rumit, trik dibelakang ini adalah teknologi
ASP.NET yang dikompilasi sebanyak dua kali. Pada
kompilasi
pertama
(Miscrosoft
taingkat
kode
Intermediate
diubah menjadi
Language),
menengah yang
bersifat
kode
sebuah
platform
MSIL
bahasa
agnostics,
berikutnya kode MSIL diubah menjadi kode natif, hal
yang menarik
JIT tidak mengubah semua kode MSIL
menjadi kode natif melainkan hanya
kode yang hendak
dieksekusi saja, inilah yang dikenal dengan just-in-time,
pada eksekusi selanjutanya engine tidak perlu melakukan
kompilasi karena masih terdapat pada cache.
2.
Fleksibilitas,
ASP.NET
dapat
menggunakan
semua
pustaka .NET Base Class Library, sebagai tambahan
pengguna juga dapat memiliki kebebasan untuk memilih
bahasa pemograman yang digunakan seperti VB atau C#.
3.
Setting dan Konfigurasi, ASP.NET menggunakan XML
dalam pengaturan setting dan konfigurasi aplikasi web.
Walaupun
terkesan
esensial yang dapat
sepele, banyak
informasi yang
disimpan dan memudahkan kita
dalam melakukan distribusi serta konfigurasi web.
4.
Keamanan,
ASP.NET
yang
menggunakan
pustaka
keamanan yang sama dengan .NET framework dapoat
secara fleksibel dikombinasikan dengan menggunakan
31
schema berbasis xml yang dapat dibuat sesuai dengan
kebutuhan.
2.3.3
Anatomi Aplikasi ASP.NET
Berdasarkan sumber Berbeda
berbasis
executable
(.exe),
dengan
aplikasi
web
berbasis
aplikasi
ASP.NET pada umumnya terdiri dari satu atau lebih halaman
web dinamis. Pengguna aplikasi web dapat masuk melalui link
yang
berbeda,
dengan
cara
yang
berbeda,
hingga
menggunakan perangkat yang berbeda.
Setiap halaman pada aplikasi web berbasis ASP.NET
menggunakan konsep sharing common resources , tentu saja
hal ini hanya berlaku pada halaman halaman web yang
terdapat dalam satu aplikasi web. Bagi pakai sumber daya ini
diatur oleh suatu mekanisme domain yang dikenal dengan
application domain.
Application
domain
adalah
suatu
area
yang
terisolasi yang memisahkan pemetaan sumber daya dari
aplikasi yang satu dengan aplikasi yang lain. Konsep ini
memungkinkan bahwa satu web aplikasi yang satu dengan
yang lain saling terisolasi dan aman apabila terjadi kesalahan
fatal antara satu web aplikasi dengan web aplikasi yang
lain.
Setiap
konfigurasinya
aplikasi
web memiliki
sendiri. Dalam
sesi,
lingkungan
cache,
dan
pemograman
asp.net pada umumnya sebuah aplikasi web memiliki satu
direktori khusus pada web server yang dikenal dengan
Virtual Directory. Gambar 1.1 menggambarkan aplikasi web
dalam sebuah web server.
32
Gambar 2.4 Aplikasi ASP.NET
Sebuah aplikasi ASP.NET berada dalam sebuah
application domain dan sebuah virtual directory,
tetapidalam
sebuah virtual directory dapat dimungkinkan terdapat lebih
dari satu aplikasi ASP.NET. Padakeadaan ini maka aplikasi
ASP.NET akan bekerja dalam sebuah application domain,
walaupun ini adalahsatu
hal
yang
harus
dihindari
tetapi
secara implisit keadaan ini dapat diatasi melalui konfigurasi
per-aplikasi atau pemisahan application domain pada setiap
web aplikasi.
2.4
Teori Internet
2.4.1 Internet
Menurut Connolly & Begg (2002, 944), internet adalah
sekumpulan jaringan komputer terpisah diseluruh dunia ini yang
terkoneksi satu sama lain, dimana semuanya menggunakan
aturan komunikasi khusus yang dikenal sebagai Transmission
Control Protocol / Internet Protocol
(TCP/IP). Protokol inilah
yang memungkinkan transmisi data dilakukan antara hampir
33
semua tipe komputer dan sistem transmisi yang meliputi kabel,
jalur telepon (Telephone Line), atau satelite.
2.4.2 WWW (World Wide Web)
Menurut Connolly & Begg (2002, p948), WWW adalah
sistem berbasiskan Hypermedia yang menyediakan sarana
mencari informasi di internet dengan cara yang tidak sekuensial
menggunakan hiperlinks, yang biasanya mendukung GUI
(Graphical User Interface). WWW ini merupakan layanan yang
paling popular dan telah mencakup hamper semua layanan
internet lainnya, seperti web base chat, dan web base email.
WWW menggunakan protocol transfer HTTP (HiperTeks
Transfer Protocol).
2.4.3 URL (Uniform Resource Locator)
URL adalah suatu string yang terdiri dari karakter –
karakter alphanumeric yang merepresentasikan lokasi atau
alamat sumber yang ada pada internet. Serta menjelaskan
bagaiman sumber tersebut bias diakses (Connolly & Beg, 2002,
p952).
2.4.4 HTML (HiperText Markup Language)
HTML
adalah
sebuah
markup
language
untuk
mengidentifikasikan elemen – elemen dari suatu halaman web
sehingga browser dapat menampilkan halaman web tersebut
pada computer (Deitel, 2001, p260).
Di dalam HTML , teks ditandai dengan elemen yang
dinamakan dengan tag, yang terdiri dari keyword yang diapit
oleh sepasang tanda “<” dan “>”. Tag dalam HTML tidak bersifat
case sensitive artinya penulisan tag dengan huruf besar
ataupun kecil tidak berpengaruh pada proses eksekusi.
34
Pembuatan file HTML memerlukan sebuah text editor
yang disebut dengan Notepad yang terdapat didalam windows.
Semua file HTML harus berekstensi .htm atau .html sehingga
file – file tersebut bias dieksekusi dan ditampilkan di halaman
web.
2.4.5
Pengertian Hosting
Hosting
adalah
jasa
layanan
internet
yang
menyediakan sumber daya server-server untuk disewakan
sehingga memungkinkan organisasi atau individu menempatkan
informasi di internet berupa HTTP, FTP, EMAIL atau DNS
Server Hosting terdiri dari gabungan server-server atau sebuah
server yang terhubung dengan jaringan internet berkecepatan
tinggi.
Ada beberapa jenis layanan Hosting yaitu shared
Hosting, VPS atau Virtual Dedicated Server, dedicated server,
collocation
server.
(Sumber
http://www.balinter.net/news_78_Istilah_Dan_Pengertian_Intern
et.html diakses tanggal 07 Mei 2008 jam 11.52 ).
2.4.5.1 Shared Hosting
Shared Hosting adalah menggunakan server Hosting
bersama sama dengan pengguna lain satu server dipergunakan
oleh lebih dari satu nama domain. VPS, Virtual Private Server,
atau juga dikenal sebagai Virtual Dedicated Server merupakan
proses virtualisasi dari lingkungan software sistem operasi yang
dipergunakan oleh server. Karena lingkungan ini merupakan
lingkungan
virtual,
hal
tersebut
memungkinkan
untuk
menginstall sistem operasi yang dapat berjalan diatas sistem
operasi
lain.
(
Sumber
35
http://www.balinter.net/news_78_Istilah_Dan_Pengertian_Intern
et.html diakses tanggal 07 Mei 2008 jam 11.52 ).
2.4.5.2 Dedicated Server
Dedicated Server adalah penggunaan server yang
dikhususkan untuk aplikasi yang lebih besar dan tidak bisa
dioperasikan dalam shared Hosting atau virtual dedicated
server. Dalam hal ini, penyediaan server ditanggung oleh
perusahaan Hosting yang biasanya bekerja sama dengan
vendor.
(
Sumber
http://www.balinter.net/news_78_Istilah_Dan_Pengertian_Intern
et.html diakses tanggal 07 Mei 2008 jam 11.52 ).
2.4.5.3 Colocation Server
Colocation Server adalah layanan penyewaan tempat
untuk meletakkan server yang dipergunakan untuk Hosting.
Server disediakan oleh pelanggan yang biasanya bekerja sama
dengan
vendor.
(
Sumber
http://www.balinter.net/news_78_Istilah_Dan_Pengertian_Intern
et.html diakses tanggal 07 Mei 2008 jam 11.52 ).
2.4.5.4 Leased Line
Secara harfiah dapat diartikan sebagai kabel yang
disewa. Kabel ini dimanfaatkan sebagai media koneksi jaringan.
Salah satu cara untuk penyewaan ini bisa dilakukan melalui PT.
Telkom yang telah menggelar kabelnya melalui sarana telepon.
Cara ini merupakan salah saru cara yang cukup efektif daripada
menggelar kabel sendiri, terutama untuk jarak sekian kilometer.
(Sumber
http://www.total.or.id/info.php?kk=Leased%20line
diakses tanggal 07 Mei 2008 jam 12.14 )
36
2.5
Teori Umum
2.5.1 Pengertian Perguruan Tinggi
Perguruan
tinggi
adalah
satuan
pendidikan
penyelenggara pendidikan tinggi. Peserta didik perguruan tinggi
disebut mahasiswa, sedangkan tenaga pendidik perguruan
tinggi disebut dosen.
Di
Indonesia,
perguruan
tinggi
dapat
berbentuk
akademi, politeknik, sekolah tinggi, institute, dan universitas.
Perguruan
tinggi
dapat
menyelenggarakan
pendidikan
akademik, profesi, dan vokasi dengan program pendidikan
diploma (D1, D2, D3, D4), sarjana (S1), magister (S2), doktor
(S3), dan spesialis.
Universitas, institut, dan sekolah tinggi yang memiliki
program doktor berhak memberikan gelar doktor kehormatan
(doktor honoris causa) kepada setiap individu yang layak
memperoleh penghargaan berkenaan dengan jasa-jasa yang
luar
biasa
dalam
bidang
ilmu
pengetahuan,
teknologi,
kemasyarakatan, keagamaan, kebudayaan, atau seni. Sebutan
guru besar atau profesor hanya dipergunakan selama yang
bersangkutan masih aktif bekerja sebagai pendidik di perguruan
tinggi. (Sumber : http://id.wikipedia.org/wiki/Perguruan_tinggi
access 3 Mei 2008 jam 12.30 ).
2.5.2 Pengertian Penjadwalan
Penjadwalan
kuliah
adalah
pengaturan
perencanaan
perkuliahan yang meliputi matakuliah, dosen, waktu, dan tempat
pada perguruan tinggi (sumber primer).
BAB III
ANALISIS SISTEM
3.1
Gambaran Umum Perguruan Tinggi Raharja
3.1.1
Sejarah Singkat Perguruan Tinggi Raharja
Pada saat ini perguruan tinggi Raharja terdiri dari dua institusi
pendidikan antara lain AMIK Raharja Informatika dan STMIK Raharja.
Adapun Sejarah berdirinya Perguruan Tinggi Raharja diawali oleh
sebuah lembaga kursus komputer, yang diresmikan pada tanggal 03
Januari 1994 dengan nama Lembaga Pendidikan dan Pelatihan
Komputer (LPPK) Raharja oleh Walikota Tangerang, Drs. Djakaria
Machmud.
Pada
waktu
itu,
lembaga
inilah
yang
mempelopori
penggunaan operating system Windows dan aplikasinya di wilayah
Tangerang dan sekitarnya, hal tersebut mendapat respon positif dan
jumlah peminatnya pun meningkat pesat seiring dengan kerjasama yang
dilakukan oleh lembaga ini dengan Sekolah Lanjutan Tingkat Atas yang
ada di Tangerang.
Pada tanggal 24 Maret 1999, karena banyaknya peminat dan
pesatnya pertumbuhan, berkembang menjadi Akademi Manajemen
Informatika dan Komputer (AMIK) Raharja Informatika. Diresmikan
melalui Surat Keputusan Menteri Pendidikan dan Kebudayaan Republik
Indonesia Nomor: 56/D/O/1999, dengan menyelenggarakan jurusan
Manajemen Informatika.
Pada Tahun 2000, AMIK Raharja Informatika menambah
jurusan Teknik Informatika (TI) dan Komputerisasi Akuntansi (KA). Pada
tanggal 02 Februari 2000 berdasarkan Surat Keputusan Koordinator
Koordinasi
Perguruan
3024/004/KL/1999,
Tinggi
AMIK
Swasta
Raharja
Wilayah
Informatika
IV
Nomor
secara
:
resmi
menyelenggarakan program Diploma I (DI) dengan memberikan gelar
Ahli Pratama, Program Diploma II (DII) dengan memberikan gelar Ahli
37
38
Muda dan Diploma III (DIII) dengan memberikan gelar Ahli Madya,
kepada lulusannya.
Kepercayaan dan dorongan dari berbagai pihak kepada
Yayasan Nirwana Nusantara, sebagai penyelenggara pendidikan untuk
segera meningkatkan status dan mutu prestasi kualitas lulusannya.
Hingga terwujudlah Sekolah Tinggi Manajemen & Ilmu Komputer
(STMIK) Raharja, melalui Surat Keputusan Menteri Pendidikan Nasional
Nomor: 74/D/O/2001, tanggal 13 Juli 2001. STMIK Raharja menjadi
perguruan tinggi komputer yang memiliki program studi terlengkap di
propinsi
Banten,
dan
telah
diakui
pengalamannya
dalam
menyelenggarakan sistem pendidikan teknologi informasi dan komputer.
Perkembangannya pun tidak berhenti sampai disini, AMIK Raharja
Informatika mendapatkan status akreditasi-B untuk jurusan Manajemen
Informatika berdasarkan Surat Keputusan Badan Akreditasi NasionalPerguruan Tinggi (BAN-PT) Nomor: 003/BAN-PT/AK-1/DPL/III/IV/2002
pada tanggal 05 April 2002.
Tabel 3.1. Jurusan / Program Studi di STMIK Raharja
No
Jurusan / Program Studi
Jenjang
Mulai
Beroperasi
1.
Sistem Informasi (SI)
•
Management
Information
S1
2001
System
•
Business Information System
S1
2001
•
E-Commerce
S1
2001
Computer Accountancy
S1
2001
•
2.
Teknik Informatika (TI)
•
Multimedia
S1
2001
•
Software Engineering
S1
2001
•
Expert System
S1
2001
39
•
3.
Computer Graphic Animation
S1
2001
Sistem Komputer
•
Computer System
S1
2001
•
Computer Telecommunication
S1
2001
•
Computer Automation
S1
2001
3.1.2
Visi dan Misi
`
Visi Raharja adalah menjadi perguruan tinggi swasta yang
secara
berkesinambungan
meningkatkan
kualitas
pendidikan,
memberikan pelayanan dalam menciptakan sumber daya manusia yang
tangguh, memiliki daya saing yang tinggi dalam era globalisasi terutama
yang terkait dan ditunjang oleh berbagai bentuk penerapan dibidang
teknmologi informasi dan komputer. Menjadikan pribadi Raharja sebagai
sumber daya manusia terampil dan ahli, mampu bersaing dalam dunia
bisnis dan non bisnis, menghasilkan tenaga intelektual dan profesional,
serta mampu berkembagn dalam cakrawala yang lebih luas. Dalam
rangka mencapai visi yang digariskan, Raharja senantiasa akan
berupaya untuk melaksanakan misinya sebagai berikut :
a.
menyelenggarakan program – program studi yang menunjang
pengembangan dan penerapan teknologi informasi dalam
berbagai bidang ilmu.
b.
Menyediakan sarana dan lingkungan yang kondusif bagi
pelaksanaan kegiatan belajar mengajar yang efektif dan efisien,
sehingga terbentuk lulusan – lulusan yang bermoral, terampil,
dan kreatif.
c.
Menjaga keterkaitan dan relevasi seluruh kegiatan akademis
dengan kebutuhan pembangunan sosial ekonomi dan industri
Indonesia, serta mengantisipasi semakin maraknya globalisasi
kehidupan masyarakat.
40
d.
Melangsungkan kerjasama dengan berbagai pihak, baik dari
dalam maupun luar negeri, sehingga ilmu dan teknologi yang
diberikan selalu mutakhir serta dapat diterapkan secara berhasil
guna dan tepat guna.
Visi dan misi tersebut diatas, dipahami dan didekati dengan
kesadaran komitmen pada kualitas yang menjadi target dalam
manajemen, dan sistem pendidikan diperguruan tinggi Raharja.
Kualitas sebagai suatu dimensi yang merupakan bagian dari apa
yang disebut ”Total Quality Management”. Konsep berpikir kualitas
terdiri dari : Performance (Kinerja), Feature (Fasilitas), Durability
(Daya Tahan), Reliability (Kehandalan), Conformance (Kesesuaian),
Aesthetic (Keindahan), dan Easy to be Repaired (Kemudahan
Perbaikan). Ketujuh elemen itu merupakan perhatian utama
manajemen dan sistem pendidikan di Perguruan Tinggi Raharja
yang dituangkan dalam ISO 9001:2000 (Sistem Manajemen Mutu
Raharja).
41
3.1.3
Struktur Organisasi
Gambar 3.1. Struktur Organisasi STMIK-Raharja
42
3.1.4
Prosedur Sistem JRS dan KRS
Prosedur sistem penjadwalan yang di terapkan pada STMIK-
Raharja dapat dijelaskan sebagai berikut :
1.
Mengidentifikasikan mata kuliah yang akan dibuka untuk
seluruh jurusan yang dikeluarkan oleh setiap kajur, yaitu
berdasarkan kurikulum.
2.
Mengidentifikasikan calon peserta pada setiap mata kuliah yang
datanya dikeluarkan oleh Registrasi Perkuliahan dan Ujian (
RPU ). Dilihat dari mahasiswa yang belum mengambil atau
tidak lulus dari matakuliah yang dibuka, disesuaikan dengan
semester, jurusan dan shift kuliah.
3.
Menghitung perkiraan jumlah kelas yang akan dibuka untuk
setiap mata kuliah.
4.
Penyusunan Jadwal Rencana Kuliah ( JRS ), disesuaikan
dengan melihat dosen yang diambil didapat dari pengisian
formulir kesediaan mengajar.
Sedangkan untuk prosedur sistem KRS (Kartu Rencana Studi),
dapat dijelaskan sebagai berikut :
1.
Mahasiswa mengisi KRS sementara sesuai dengan JRS yang
diterima.
2.
LKM ( Layanan Keuangan Mahasiswa ) memberikan Kartu
Rencana Studi sementara yang sudah divalidasi setelah
mahasiswa melakukan registrasi (KRS-Valid) ke bagian LRM
(Layanan Registrasi Mahasiswa). Kemudian LRM mengentri
mata kuliah yang akan diambil oleh mahasiswa sesuai dengan
KRS-Valid ke dalam program dan menghasilkan KST (Kartu
Studi Tetap) yang didistribusikan ke mahasiswa. Proses ini juga
menghasilkan Laporan Peserta Kelas dan Laporan Quota Kelas
yang didistribusikan ke Kajur dan ADO (Asisten Direktur
Operasional).
43
3.
Dari Laporan Peserta Kelas dan Laporan Quota Kelas, Kajur
mengeluarkan JRS Revisi yang diberikan kepada bagian LRM
untuk di input kembali. Setelah itu dibuka jadwal batal tambah,
dimana mahasiswa yang akan merevisi rencana studinya
memberikan KST kepada bagian LRM untuk di input dan di
proses lagi yang kemudian menghasilkan KSTF (Kartu Studi
Tetap Final). KSTF dibuat dalam dua rangkap yang akan
didistribusikan ke mahasiswa dan diarsip oleh bagian LRM.
3.1.5
Analisis Masalah
Berdasarkan sistem berjalan yang terdapat pada STMIK-
Raharja, maka dapat dilakukan analisa masalah terhadap penyusunan
Jadwal Rencana Studi (JRS) dan registreasi Kartu Rencana Studi (KRS),
yaitu sebagai berikut :
1.
Dalam pembuatan JRS waktu yang diperlukan cukup lama,
yaitu 1 – 2 bulan.
2.
Mahasiswa harus melakukan registrasi KRS (Kartu Rencana
Studi) sebanyak tiga kali, yaitu pengisisan KRS sementara,
pengambilan KST (Kartu Studi Tetap), serta proses batal
tambah yang menghasilkan KST-Final.
3.
Untuk membuat laporan peserta kelas dan quota kelas harus
menuggu KRS-Valid di entry oleh bagian LRM (Layanan
Registrasi Mahasiswa).
4.
Mahasiswa dapat mengetahui status kelas, setelah RPU
(Registrasi Perkuliahan da Ujian) mengeluarkan JRS-Revisi.
3.1.6
Solusi Masalah
Pada bab selanjutnya, akan dibahas tentang solusi dari
masalah yang dihadapi pada proses penjadwalan dan registrasi KRS di
STMIK-Raharja. Berikut adalah garis besar dari solusi yang akan
dibahas pada bab selanjutnya :
44
1.
Merancang sistem basis data yang dapat menampung dan
menyusun data – data yang dibutuhkan dalam proses
penjadwalan dan KRS.
2.
Merancang aplikasi berbasis web sebagai sarana pembuatan
jadwal dan registrasi KRS.
3.
Membuat laporan peserta kelas, nilai mahasiswa, jadwal
mengajar dosen dan pemakaian ruangan.
BAB IV
PERANCANGAN SISTEM BASIS DATA
4.1
Perancangan Sistem Basis Data
Perancangan sistem basis data merupakan penggambaran,
perencanaan, dan pmbuatan sketsa atau pengaturan dari beberapa
elemen terpisah kedalam satu kesatuan yang utuh. Dalam hal ini akan
dirancang sistem basis data yang akan diterapkan pada aplikasi JRS
(Jadwal Rencana Studi) dan KRS (Kartu Rencana Studi) pada STMIK
Raharja. Perancangan tersebut difokuskan pada perancangan basis data
yang meliiputi tahap antara lain :
1.
Database Planning
2.
Sistem Definition
3.
Requirement Collection
4.
Database Design meliputi :
5.
a.
Perancangan basis data konseptual.
b.
Perancangan basis data logikal.
c.
Perancangan basis data fisikal.
Pemilihan DBMS
Tahapan – tahapan dari perancangan basis data tersebut akan
dijelaskan lebih detail sebagai berikut :
4.2 Database Planning
4.2.1
Mission Statement Sistem Basis Data Akademik
Seperti diketahui sebelumnya, bahwa proses pembuatan JRS
dan KRS yang dilakukan RPU memiliki beberapa kendala. Hal tersebut
dapat mengganggu tujuan yang terdapat dalam visi dan misi Perguruan
Tinggi Raharja.
Sehingga misi dari system basis data akademik Perguruan
Tinggi Raharja adalah untuk melakukan pengelolaan data, digunakan
45
46
untuk mendukung kegiatan akademik, seperti memberikan kemudahan
dalam pertukaran informasi antara RPU, dosen, dan kajur dalam
pembuatan JRS, juga memberikan fasilitas kepada mahasiswa untuk
melakukan registrasi KRS.
4.2.2
Mission Objective Sistem Basis Data Akademik
Mission Objective dari aplikasi basis data akademik harus
mampu mengIdentifikasi
tugas utama dari masing – masing bagian
yang harus didukung oleh sistem database.
Berdasarkan hasil wawancara dengan pihak akademik, terdapat
beberapa data yang terkait dengan proses pembuatan JRS dan KRS.
Hal tersebut membutuhkan sistem database untuk pengolahannya.
Kemampuan yang di tawarkan dari sistem basis data tersebut adalah
sebagai berikut :
•
Untuk mengelola data dosen, ruangan, mata kuliah, fakultas,
mahasiswa, nilai, jadwal, dan staff terkait.
•
Untuk menjalankan proses pencarian dari dosen, ruangan, mata
kuliah, fakultas, mahasiswa, nilai, dan jadwal.
•
Untuk mengetahui status dari pemakaian ruangan, status mata
kuliah masing – masing kelas, dan status keaktifan mahasiswa.
•
Untuk menghasilkan laporan dari daftar peserta kelas dan
dosen aktif.
4.3 System Definition
Pada tahap ini dilakukan teknik pencarian fakta dengan
wawancara dan pengumpulan data pada pihak terkait. Sehingga akan
didapatkan ruang lingkup dan batasan untuk mendefinisikan sistem dari
aplikasi basis data akademik. Berikut adalah sistem boundary untuk
aplikasi basis data akademik :
47
KETUA
Aplikasi
JRS
OPERASI
KEUANGAN
Aplikasi
KRS
Gambar 4.1 System Definition
4.4 Requirements Collection and Analysis
Selama tahap ini dilakukan pengumpulan lebih jauh mengenai
user view dengan cara membuat suatu spesifikasi kebutuhan user dan
spesifikasi sistem.
•
Spesifikasi kebutuhan user dibuat untuk mendeskripsikan detil
dari data dalam basis data dan bagaimana data tersebut
digunakan.
•
Spesifikasi sistem mendeskripsikan beragam fitur yang dapat
dimasukkan kedalam aplikasi basis data yang baru.
Tabel 4.1 User View Basis Data
Data
Access
LRM
Type
MHS
PU
KAJUR
Asisten
Direktur
Maintain
X
Query
X
48
Report
Ruang
X
Maintain
X
Query
X
Report
Kurikulum
Dosen
Jadwal
Maintain
X
Query
X
Report
X
Maintain
X
Query
X
Report
X
Maintain
X
Query
X
X
Report
KRS
Nilai
4.4.1
X
X
Maintain
X
Query
X
Report
X
Maintain
X
Query
X
Report
X
Spesifikasi Kebutuhan User (User Requirement Specification)
1.
Kebutuhan Data (Data Requirement)
a.
Data mahasiswa
Kebutuhan dari :
•
Dibutuhkan oleh kajur untuk mengetahui
mahasiswa aktif sehingga dapat diperkirakan
jumlah peserta kelas.
b.
Data kurikulum
Kebutuhan dari :
49
•
Dibutuhkan oleh kajur untuk mengetahui
matakuliah yang akan dibuka pada tiap
semester.
c.
Data jurusan atau program studi
Kebutuhan dari :
•
Dibutuhkan oleh kajur untuk menentukan
pembukaan konsentrasi baru di tiap jurusan.
d.
Data dosen
Kebutuhan dari :
•
Dibutuhkan oleh kajur untuk mengetahui
dosen aktif dan kesediaan hari mengajar.
e.
Data ruang
Kebutuhan dari :
•
Dibutukan oleh PU untuk menentukan jadwal
pemakaian ruangan.
2.
Kebutuhan transaksi (TransAction Requirement)
a.
Data entri
•
Input data mahasiswa.
•
Input data dosen.
•
Input data kurikulum.
•
Input data kesediaan mengajar dosen
•
Input data jurusan
•
Input data nilai
•
Input data ruang
•
Input jadwal
•
Input KRS
•
Input kelas
50
b.
c.
4.4.2
Data update
•
Update data kelas
•
Update data kurikulum
•
Update data mahasiswa
•
Update data dosen
•
Update jadwal
•
Update KRS
Data queries
Spesifikasi
•
Tampilkan total peserta kelas
•
Tampilkan matakuliah yang dibuka
•
Tampilkan jadwal
•
Tampilkan KRS mahasiswa
•
Tampilkan nilai mahasiswa.
Kebutuhan
Sistem
(Sistem
Requirement
Spesification)
1.
2.
Initial Database Size
•
Ada 3 fakultas dengan 11 jurusan.
•
Ada sekitar 1500 mahasiswa.
•
Ada sekitar 660 matakuliah.
•
Ada sekitar 9 kelas dan 3 laboratorium.
•
Ada sekitar 220 dosen
Database Growth
•
Ada sekitar 1500 mahasiswa aktif yang melakukan
registrasi KRS setiap semester.
•
Ada sekitar 220 dosen yang mengisi form
kesediaan mengajar setiap semesternya.
51
•
Ada
sekitar
800
calon
mahasiswa
menjadi
mahasiswa setiap semesternya.
•
Ada sekitar 210 jadwal yang dibuat setiap
semesternya.
3.
Security
•
Setiap dosen diberikan hak akses terhadap basis
data dengan cara verifikasi login melalui aplikasi
sistem.
•
Setiap mahasiswa diberikan hak akses terhadap
basis data dengan cara verifikasi login melalui
aplikasi sistem.
4.5 Perancangan Sistem Basis Data
4.5.1
Perancangan Basis Data Konseptual
Perancangan database konseptual menurut Thomas Connolly
dan Carolyn Begg (2002,p419), adalah proses pembuatan model dari
informasi yang digunakan di perusahaan, tidak tergantung pada semua
pertimbangan fisik yang ada. Tahap dalam perancangan database
konseptual meliiputi :
Langkah 1.
Identifikasi
Entitas
Langkah 2.
Identifikasi
Relationship
Langkah 3.
Identifikasi
Atribut
Langkah 4.
Menentukan Primary key
Langkah 5.
Mempertimbangkan
enhanced
Langkah 6.
Validasi transaksi
pengguanaan
model
52
4.5.1.1 Identifikasi Entitas
Pada langkah ini akan membahas Identifikasi dan mendeskripsikan
entitas – entitas yang ada, entitas – entitas tersebut meliputi :
Tabel 4.2 Identifikasi Entitas
Entity Name
Description
Mahasiswa
Entitas
yang
Aliases
occurrence
tb_mhs
Data
memberikan
mahasiswa
informasi
disimpan
tentang
entitas ini
pada
mahasiswa
Dosen
Entitas
yang
tb_dosen
Data
dosen
memberikan
disimpan
informasi
entitas ini.
pada
tentang dosen
Ruang
Data
ruangan
Tb_ruang
yang tersedia
Semua
data
ruangan
disimpan
pada
enitas ini
Kurikulum
Data kurikulum
Tb_kurikulum
kurikulum baru
disimpan
pada
entitas ini
Jurusan
Data jurusan
Tb_jurusan
Jurusan
tiap
dari
fakultas
disimpan
pada
entitas ini
Nilai
Data
mahasiswa
nilai
Tb_nilai
Data nilai dari
masing
masing
–
53
mahasiswa
disimpan
pada
entitas ini.
Kelas
Data kelas
Tb_kelas
Data kelas yang
dibuka
dari
masing
–
masing
matakuliah
disimpan
pada
entitas ini
Jadwal
Data jadwal
Tb_jadwal
Inputan
jadwal
disimpan
pada
entitas ini.
Jenis
Informasi
dari
matakuliah
jenis matakuliah
Jenis_mk
Berisi informasi
dari
jenis
matakuliah
Kelompok
Data
matakuliah
pengelompokan
dari
matakuliah
matakuliah
yang ada
yang tersedia
Konsentrasi
dari
Data
Klmpk_mk
Tb_konsentrasi
Berisi informasi
kelompok
Informasi
konsentrasi tiap
mengenai
jurusan
peminatan dari
tiap jurusan
Tb_status
Data
dosen
status
Tb_status
pada
perguruan tinggi
Dosen memiliki
status
yang
terdapat
pada
tabel ini
Master
sedia
Data kesediaan
Tb_ajar
Inputan
54
mengajar
waktu mengajar
kesediaan
dosen
mengajar dosen
disimpan
pada
entity ini
Tb_login_mhs
Menyimpan
Tb_login_mhs
Inputan
login
password
mahasiswa
mahasiswa
akan di validasi
pada entity ini
Tb_login_dosen
Menyimpan
Tb_login_dosen
Inputan
login
password
dosen akan di
dosen
validasi
pada
entiry ini
Buka
mata
kuliah
Membuka
Tb_bukaMk
Tabel ini akan
matakuliah
mengacu pada
berdasarkan
tabel kurikulum
semester
berdasarkan
semester
prasyarat
Daftar prasyarat
Tb_prasyarat
dari matakuliah
Table ini akan
mengacu pada
table kurikulum
Master KRS
Daftar
Tb_krs
Table
ini
matakuliah
mengacu pada
yang
table jadwal
diambil
oleh mahasiswa
4.5.1.2 Identifikasikan Tipe Relasional
Tujuan dari tahapan ini adalah untuk menentukan hubungan –
hubungan penting yang ada antara jenis entitas yang telah di Identifikasi
kan.
55
1.
Menentukan ER Diagram.
Gambar 4.2 Entity Relationship Diagram 56
2.
Menentukan pembatas multiplicity dari tipe relasional.
Tabel 4.3 Identifikasi Tipe Relasional
Entity child
Multiplicity
Relationship
Entity parent
Multiplicity
Tb_login_mhs
1..1
Diakses
Tb_mhs
1..N
Tb_mhs
1..N
Terdaftar di
Tb_jurusan
1..1
Tb_krs
1..1
Diakses
Tb_mhs
1..N
Tb_kurikulum
1..N
Dimiliki
Tb_jurusan
1..1
Tb_konsentrasi
1..N
Dimiliki
Tb_jurusan
1..1
Tb_dosen
1..N
Terdaftar
Tb_jurusan
1..1
Tb_login_dsn
1..1
Diakses
Tb_dosen
1..N
Tb_dosen
1..N
Memiliki
Tb_status
1..1
Tb_ajar
1..N
Diisi
Tb_dosen
1..1
Tb_kurikulum
1..N
Memiliki
Tb_jmk
1..1
Tb_kurikulum
1..N
Memiliki
Tb_kmk
1..1
Tb_kurikulum
1..N
Memiliki
Tb_konsentrasi
1..1
Tb_buka_mk
1..1
Membuka
Tb_kurikulum
0..1
Tb_kelas
1..N
Membuka
Tb_buka_mk
1..1
Tb_jadwal
1..1
Menjadwalkan
Tb_kelas
1..1
1..1
Memiliki
Tb_krs
rincian
Tb_jadwal
1..N
Tb_jadwal
1..N
Mempunyai
Tb_dosen
1..1
Tb_jadwal
1..1
Memakai
Tb_ruang
1..N
Tb_nilai
1..N
Memiliki
Tb_krs
1..1
Tb_prasyarat
1..N
Dimiliki
Tb_kurikulum
0..1
57
4.5.1.3 Identifikasi Atribut
Tujuan dari tahapan ini adalah untuk mengIdentifikasi
kan
dan mengasosiasikan atribut dari entitas atau tipe relasi.
Tabel 4.4 Identifikasi Atribut jenis_mk
Nama Entitas
Jenis_mk
Atribut
id_jmk
Jenis_mk
LastUpdate
Keterangan
Kode
jenis
matakuliah
Type
Not Null
varchar (1)
yes
Jenis
Varchar
matakuliah
(30)
Terakhir
update
Datetime
No
No
Tabel 4.5 Identifikasi Atribut jurusan
Nama Entitas
Jurusan
Atribut
Kd_jurusan
jurusan
Jenjang
LastUpdate
Keterangan
Kode
jurusan
Type
Not Null
Varchar (5)
yes
Nama
Varchar
jurusan
(40)
Jenjang
Char (2)
no
Datetime
no
Terakhir
update
no
Tabel 4.6 Identifikasi Atribut klmpk_mk
Nama Entitas
Atribut
Keterangan
Type
Not Null
varchar (3)
yes
Varchar
no
Kode
Klmpk_mk
Id_kmk
kelompok
matakuliah
Klmpk_mk
Nama
58
kelompok
(30)
matakuliah
Table 4.7 Identifikasi Atribut tb_prasyarat
Nama Entitas
Tb_prasyarat
Atribut
Kd_mk
Kd_prasyarat
Keterangan
Type
Kode
varchar
matakuliah
(5)
Kode
Varchar
prasyarat
(5)
Not Null
yes
yes
Tabel 4.8 Identifikasi Atribut tb_ajar
Nama
Atribut
Keterangan
Type
Not Null
Integer
yes
Integer
yes
Date
no
Entitas
Kode
Tb_ajar
Id_ajar
kesediaan
mengajar
NID
Thn_akademik
Nomor induk
dosen
Tahun
akademik
Smstr
Semester
hari
Hari
varchar
(6)
Varchar
(10)
no
no
59
Tabel 4.9 Identifikasi Atribut tb_dosen
Nama
Atribut
Keterangan
Type
Nomor induk
Varchar
dosen
(10)
Not Null
Entitas
Tb_dosen
NID
Kd_jurusan
kd_status
Kode jurusan
Kode
status
dosen
Varchar
(5)
Varchar
(3)
Varchar
Nm_dosen
Nama dosen
Gelar
Gelar dosen
Tmp_lahir
Tempat lahir
Tgl_lahir
Tanggal lahir
Date
Jenis
Varchar
kelamin
(1)
Jenis_klmn
(30)
Varchar
(15)
Varchar
(20)
Varchar
yes
yes
yes
no
no
no
no
no
Agama
Agama
Alamat
Alamat
Kab
Kabupaten
Kota
Kotamadya
Kd_pos
Kode pos
varchar(5)
no
Phone1
No telepon
Varchar
no
(15)
Varchar
(50)
Varchar
(20)
Varchar
(20)
no
no
no
no
60
(13)
Phone2
No telepon
email
Alamat email
Jabatan
Keahlian
pendidikan
Varchar
(13)
Varchar
(30)
Jabatan
Varchar
dosen
(20)
Keahlian
Varchar
dosen
(20)
Pendidikan
Varchar
dosen
(2)
no
no
no
no
no
Tabel 4.10 Identifikasi Atribut tb_jadwal
Nama
Atribut
Keterangan
Type
Not Null
Id_jadwal
Kode jadwal
Integer
yes
Id_kelas
Kode kelas
Integer
yes
Ruang
Ruangan
Entitas
Tb_jadwal
NID
Kd_mk
Thn_akademik
Varchar
(4)
Nomor induk
Varchar
dosen
(10)
Kode
Varchar
matakuliah
(5)
Tahun
Varchar
akademik
(4)
Smstr
Semester
Jam_1
Jam masuk
Varchar
(6)
Datetime
yes
yes
yes
no
no
no
61
Jam_2
Jem keluar
Hari
Hari
Kapasitas
Kapasitas
Integer
no
Terisi
Terisi
Integer
no
Status
Status
Datetime
Varchar
(10)
Varchar
(10)
no
no
No
Kode
Id_buka matakuliah
Integer
yes
yang dibuka
Tabel 4.11 Identifikasi Atribut tb_kelas
Nama
Atribut
Keterangan
Type
Not Null
Id_kelas
Kode kelas
Integer
yes
Kode
Varchar
matakuliah
(5)
Entitas
Tb_kelas
Kd_mk
Id_buka Kelas
Thn_akademik
Smstr Kode
buka
matakuliah
Kelas
Integer
Varchar
(1)
Tahun
Varchar
akademik
(4)
Semester
Varchar
(6)
yes
yes
no
No
No
62
Tabel 4.12 Identifikasi Atribut tb_konsentrasi
Nama
Atribut
Keterangan
Type
Not Null
varchar(4)
yes
Entitas
Tb_konsentr
asi
Kd_konsen
Kode
konsentrasi
Kd_jurusan
Kode jurusan
Konsentrasi
Konsentrasi
Varchar
(5)
Varchar
(40)
yes
No
Tabel 4.13 Identifikasi Atribut tb_krs
Nama
Atribut
Keterangan
Type
Not Null
Id_krs
Kode krs
Integer
yes
Entitas
Tb_krs
Nomor
NIM
induk
mahasiswa
Varchar
(9)
yes
Id_jadwal
Kode jadwal
Integer
Yes
Id_kelas
Kode kelas
Integer
Yes
Id_buka
Kode
Integer
Yes
Kode
Varchar
matakuliah
(5)
Nomor
Varchar
induk dosen
(10)
Kd_mk
NID
Yes
yes
63
Tabel 4.14 Identifikasi Atribut tb_kurikulum
Nama Entitas
Tb_kurikulum
Atribut
Kd_mk
Id_jmk
Keterangan
Type
Kode
Varchar
matakuliah
(4)
Kode
jenis
matakuliah
Kode
Id_kmk
kelompok
matakuliah
Kd_jurusan
Kd_konsen
Thn_krklm
Nm_mk
varchar(1)
Varchar
(3)
Kode
Varchar
jurusan
(5)
Kode
konsentrasi
varchar(4)
Tahun
Varchar
kurikulum
(4)
Nama
Varchar
matakuliah
(40)
Sks
Satuan kredit
Smstr
Semester
prasyarat
Prasyarat
Varchar
(1)
Varchar
(6)
Varchar
(40)
Not Null
yes
yes
yes
yes
yes
no
no
no
no
no
Tabel 4.15 Identifikasi Atribut tb_mhs
Nama
Atribut
Keterangan
Type
Nomor induk
Varchar
mahasiwa
(9)
Not Null
Entitas
Tb_mhs
NIM
yes
64
Kd_jurusan
Nm_mhs
Tg_msk
Angkatan
Thn_krklm
Kode jurusan
varchar(5)
Nama
Varchar
mahasiswa
(30)
Tanggal
masuk
Angkatan
Tahun
kurikulum
Datetime
Varchar
(4)
Datetime
Varchar
Tmp_lahir
Tempat lahir
Tgl_lahir
Tanggal lahir
datetime
Jenis
Varchar
kelamin
(1)
Jenis_klmn
(30)
Varchar
yes
no
no
no
no
no
no
no
Agama
Agama
Alamat
Alamat
Kab
Kabupaten
Kota
Kotamadya
Kd_pos
Kode pos
varchar(5)
no
Bts_studi
Batas studi
Datetime
no
shift
Shift kuliah
(15)
Varchar
(40)
Varchar
(20)
Varchar
(20)
Varchar
(10)
no
no
no
no
no
65
Tabel 4.16 Identifikasi Atribut tb_nilai
Nama
Atribut
Keterangan
Type
Not Null
Id_krs
Kode nilai
Integer
yes
Nomor induk
Varchar
mahasiswa
(9)
Kode
Varchar
matakuliah
(5)
Id_jadwal Kode jadwal
Int
Yes
Id_buka Kode buka
Int
Yes
Id_kelas Kode kelas
Int
Yes
Nomor induk
Varchar
dosen
(10)
N_tugas
Nilai tugas
Float
no
N_uts
Nilai uts
Float
no
N_uas
Nilai uas
Float
no
N_total
Total nilai
Float
no
N_angka Nilai angka
Float
no
Entitas
Tb_nilai
NIM
Kd_mk
NID yes
yes
Yes
Tabel 4.17 Identifikasi Atribut tb_ruang
Nama
Atribut
Keterangan
Type
Not Null
Ruang
Ruangan
Lantai
Lantai
Varchar (2
no
Kapasitas
Kapasitas
Integer
no
Entitas
Tb_ruang
Varchar
(4)
yes
66
Tabel 4.18 Identifikasi Atribut tb_status
Nama
Atribut
Keterangan
Type
Kode
varchar
Not Null
Entitas
Tb_status
Kd_status
status
status
dosen
(3)
Status dosen
Varchar
(30)
yes
no
Tabel 4.19 Identifikasi Atribut tb_login_mhs
Nama
Atribut
Keterangan
Type
Not Null
varchar(9)
yes
Entitas
Tb_login_mh
s
NIM
Pswd
Nomor induk
mahasiswa
password
Varchar
(10)
yes
Tabel 4.20 Identifikasi Atribut tb_login_dosen
Nama
Atribut
Keterangan
Type
Nomor induk
Varchar
dosen
(10)
Not Null
Entitas
Tb_login_do
sen
NID
pswd
Password
Varchar
(10)
yes
Yes
Tabel 4.21 Identifikasi Atribut tb_buka_mk
Nama
Atribut
Keterangan
Type
Not Null
Integer
yes
Entitas
Tb_buka_mk
Id_buka
Kode
buka
matakuliah
67
Kode
Varchar
matakuliah
(5)
Thn_akade
Tahun
Varchar
mik akademik
(4)
Smstr Semester
Varchar 6
Kd_mk
Yes
No
no
4.5.1.4 Identifikasi Candidate and Primary key
Tujuan dari tahap ini adalah untuk mengIdentifikasi
kan
kandidat key dan primary key.
Tabel 4.22 Identifikasi Kandidat dan Primary key
Entity Name
Candidate key
Primary key
Jenis_mk
Id_jmk
Id_jmk
Jurusan
Kd_jurusan
Kd_jurusan
Klmpk_mk
Id_kmk
Id_kmk
Tb_ajar
Id_ajar, NID
Id_ajar, NID
Tb_dosen
NID
NID
Tb_jadwal
Id_kelas,
Tb_kelas
id_buka,
Id_kelas,
id_buka,
kd_mk, id_jadwal, NID
kd_mk, id_jadwal, NID
Id_kelas,
Id_kelas,
id_buka,
kd_mk
kd_mk
Tb_konsentrasi
Kd_konsen
Kd_konsen
Tb_krs
id_krs,
id_kelas,
id_jadwal,
id_buka,
id_krs,
id_kelas,
id_buka,
id_jadwal,
id_buka,
kd_mk, NIM, NID
kd_mk, NIM, NID
Tb_kurikulum
Kd_mk
Kd_mk
Tb_mhs
NIM
NIM
68
Tb_nilai
NIM, kd_mk
NIM, kd_mk
Tb_ruang
Ruang
Ruang
Tb_status
Kd_status
Kd_status
Tb_buka_mk
Id_buka, kd_mk
Id_buka, kd_mk
Tb_login_mhs
NIM, pswd
NIM, pswd
Tb_login_dosen
NID, pswd
NID, pswd
Tb_prasyarat
Kd_mk, kd_prasyarat
Kd_mk, kd_prasyarat
69
4.5.1.5 Mempertimbangkan Pengunaan Model Enhanced
Gambar 4.3 Model Enhanced
70
4.5.1.6 Validasi Transaksi
Tahapan ini bertujuan untuk memastikan model konseptual lokal
untuk mendukung transaksi yang dibutuhkan oleh transaksi pemakai.
Dalam hal ini digunakan jalur arah transaksi yang digambarkan dalam
diagram ER untuk memeriksa model konseptual lokal agar mendukung
transaksi. Adapun transaksi – transaksi yang ada adalah sebagai berikut
:
(a) Menjelaskan dosen mempunyai suatu status.
(b) Menjelaskan dosen mengisi kesediaan hari mengajar.
(c) Menjelaskan dosen terdaftar di suatu jurusan.
(d) Mahasiswa mengambil satu jurusan.
(e) KRS mempuyai rincian nilai.
(f)
Mahasiswa melakukan registrasi KRS.
(g) Jurusan mempunyai beberapa kurikulum.
(h) Mata
kuliah
pada
kurikulum
mempunyai
beberapa
konsentrasi.
(i)
Jurusan mempunyai beberapa konsentrasi.
(j)
Dosen
mengajar
sesuai
dengan
jadwal
yang
telah
ditentukan.
(k) Jadwal yang akan ditentukan menggunakan ruangan yang
tersedia.
(l)
Jadwal menjadwalkan kelas yang dibuka.
(m) Matakuliah yang dibuka dibagi dalam beberapa kelas.
(n) Kurikulum
dibuka
berdasarkan
semester
akademik pada tabel buka matakuliah.
(o) KRS di isi berdasarkan jadwal yang diambil.
(p) Mahasiswa login dengan NIM dan password.
(q) Dosen login dengan NID dan password.
(r) Matakuliah mempunyai prasyarat.
dan
tahun
71
Gambar 4.4 Validasi Transaksi
72
4.5.2
Perancangan Basis Data Logikal
Perancangan basis data logikal menurut Thomas Connolly dan
Carolyn Begg (2002, p441) adalah proses pembuatan model dari
informasi yang digunakan diperusahaan berdasarkan pada suatu model
data spesifik, tetapi tidak tergantung pada suatu DBMS tertentu dan
semua pertimbangan fisik yang ada. Tahap – tahap dalam perancangan
database logikal meliputi :
1.
Menghilangkan fitur yang tidak kompatibel.
2.
Menentukan model logikal data lokal.
3.
Mendefinisikan kendala Integrity.
4.
Memvalidasi model logikal lokal dengan model global.
4.5.2.1 Menghilangkan Fitur yang Tidak Kompatibel
Karena pada sistem database ini terdapat fitur yang
tidak kompatibel, yaitu adanya hubungan yang many to many,
maka dilakukan penghilangan fitur yang tidak kompatibel.
•
Membuang relasi many to many (*.*)
Relationship antara tb_jadwal dengan tb_bukaMk dapat
dilihat pada gambar dibawah ini :
Tb_jadwal
1..*
1..*
menjadwalkan
Tb_bukaMk
Gambar 4.5 Relasi Many-to-Many
Untuk mengatasi hubungan many to many antara entitas
tb_jadwal dengan entitas tb_bukaMk, maka dibuat sebuah
entitas baru yang diberi nama tb_kelas. Yang hasilnya
dapat dilihat pada gambar dibawah ini :
73
Tb_jadwal
1..1
1..*
menjadwalkan
Tb_kelas
1..*
membuka
1..1
Tb_bukaMk
Gambar 4.6 Pemecahan Relasi Many-to-Many
4.5.2.2 Menentukan Model Logikal Data Lokal
Berikut ini adalah Model Logikal Data Lokal, yang terdiri dari :
1.
Strong Entitas types
Berikut ini adalah Strong Entitas Types :
Tb_mhs (NIM, kd_jurusan, nm_mhs, tgl_masuk, angkatan,
thn_kurikulum, tmp_lahir, tgl_lahir, jenis_klmn,
agama,
alamat, kab, kota, kd_pos, batas_studi, shift)
Primary key NIM
Foreign key kd_jurusan
Tb_dosen (NID, kd_jurusan, kd_status, nm_dosen, gelar,
tmp_lahir, tgl_lahir, jenis_klmn, agama, alamat, kab, kota,
kd_pos,
phone1,
phone2,
email,
pendidikan)
Primary key NID
Foreign key kd_jurusan, kd_status
jabatan,
keahlian,
74
Tb_kurikulum
kd_konsen,
(kd_mk,
id_jmk,
thn_kurikulum,
id_kmk,
nm_mk,
kd_jurusan,
sks,
semester,
prasyarat)
Primary key kd_mk
Foreign key id_jmk, id_kmk
Tb_jurusan (kd_jurusan, jurusan, jenjang)
Primary key kd_jurusan
Tb_konsentrasi (kd_konsen, kd_jurusan, konsen)
Primary key kd_konsen
Foreign key kd_jurusan
Tb_krs (id_krs, NIM, id_jadwal, id_buka, id_kelas, kd_mk,
NID)
Primary key id_krs, NIM, id_jadwal, id_buka, id_kelas,
kd_mk, NID
Foreign key NIM, id_jadwal, id_buka, id_kelas, kd_mk, NID
Tb_nilai (id_krs, id_jadwal, id_buka, id_kelas, NIM, kd_mk,
thn_akademik, smstr, n_tugas, n_uts, n_uas, n_total,
n_angka)
Primary key id_krs, NIM
Foreign key id_krs, id_jadwal, id_buka, id_kelas, NIM
kd_mk
Tb_jadwal
(id_jadwal,
id_kelas,
ruang,
NID,
kd_mk,
thn_akademik, smstr, jam_1, jam_2, hari, kapasitas, terisi,
status)
Primary key id_jadwal, id_kelas, NID, id_buka, kd_mk
75
Foreign key id_kelas, ruang, NID, kd_mk, id_buka
Tb_kelas (id_kelas, kd_mk, kelas, thn_akademik)
Primary key id_kelas
Foreign key kd_mk
Tb_ruang (ruang, lantai, kapasitas)
Primary key ruang
Tb_ajar (id_ajar, NID, thn_akademik, smstr, hari)
Primary key id_ajar, NID
Foreign key NID
2.
Weak Entitas Types
Berikut ini adalah Weak Entitas Types :
Tb_status (kd_status, status)
Primary key kd_status
Tb_prasyarat (kd_prasyarat, kd_mk)
Primary key kd_prasyarat, kd_mk
Foreign key kd_mk
Jenis_mk (id_jmk, jenis_mk)
Primary key id_jmk
Klmpk_mk (id_kmk, klmpk_mk)
Primary key id_kmk
76
3.
One to Many (1:*) Binary Relationship Types
One to Many (1:*) Binary Relationship Types antara jurusan
dengan tb_mhs dapat dilihat pada gambar dibawah ini :
Post jurusan ke tb_mhs
Tb_jurusan (kd_jurusan,
kd_fakultas, jurusan,
jenjang)
Primary key kd_jurusan
Foreign key kd_fakultas
Tb_mhs (NIM, kd_jurusan,
kd_fakultas, id_daftspp,
nm_mhs, tgl_masuk,
angkatan, thn_kurikulum,
tmp_lahir, tgl_lahir, jenis_klmn,
agama, alamat, kab, kota,
kd_pos, batas_studi, shift)
Primary key NIM
Foreign key kd_jurusan,
kd_fakultasm id_daftspp
Gambar 4.7 Binary Relationship jurusan dengan tb_mhs
77
One to Many (1:*) Binary Relationship Types antara tb_KRS
dengan tb_nilai dapat dilihat pada gambar dibawah ini :
Post tb_krs ke tb_nilai
Tb_krs (id_krs, NIM, id_jadwal,
Tb_nilai
id_buka,
id_buka, id_kelas, NIM,
id_kelas,
kd_mk,
thn_akademik,
NID)
Primary
(id_krs,
key
id_krs,
NIM,
id_jadwal, id_buka, id_kelas,
kd_mk, NID
smstr,
id_jadwal,
kd_mk,
n_tugas,
n_uts, n_uas, n_total, n_angka)
Primary key id_krs, NIM
Foreign
key
id_krs,
id_jadwal,
id_buka, id_kelas, NIM kd_mk
Foreign key NIM, id_jadwal,
id_buka, id_kelas, kd_mk, NID
Gambar 4.8 Binary Relationship tb_krs dengan tb_nilai
One to Many (1:*) Binary Relationship Types antara jurusan
dengan tb_konsentrasi dapat dilihat pada gambar dibawah ini :
Post tb_jurusan ke tb_konsentrasi
Tb_jurusan (kd_jurusan,
kd_fakultas,
jurusan,
jenjang)
Tb_konsentrasi
(kd_konsen, kd_jurusan,
konsen)
Primary key kd_jurusan
Primary key kd_konsen
Foreign key kd_fakultas
Foreign key kd_jurusan
Gambar 4.9 Binary Relationship tb_jurusan dengan tb_konsentrasi
78
One to Many (1:*) Binary Relationship Types antara tb_jurusan
dengan tb_dosen dapat dilihat pada gambar dibawah ini :
Post tb_jurusan ke tb_dosen
Tb_jurusan (kd_jurusan,
jurusan)
Tb_dosen (NID, kd_jurusan,
kd_status, nm_dosen, gelar,
tmp_lahir,
tgl_lahir,
jenis_klmn, agama, alamat,
kab, kota, kd_pos, phone1,
phone2,
email,
jabatan,
keahlian, pendidikan)
Primary key kd_jurusan
Primary key NID
Foreign key
kd_status
kd_jurusan,
Gambar 4.10 Binary Relationship tb_jurusan ke tb dosen
One to Many (1:*) Binary Relationship Types antara tb_status
dengan tb_dosen dapat dilihat pada gambar dibawah ini :
Post tb_status ke tb_dosen
Tb_status
(kd_status,
status)
Primary key kd_status
Tb_dosen (NID, kd_jurusan,
kd_status, nm_dosen, gelar,
tmp_lahir,
tgl_lahir,
jenis_klmn, agama, alamat,
kab, kota, kd_pos, phone1,
phone2,
email,
jabatan,
keahlian, pendidikan)
Primary key NID
Foreign key
kd_status
kd_jurusan,
Gambar 4.11 Binary Relationship tb_status ke tb_dosen
79
One to Many (1:*) Binary Relationship Types antara tb_dosen
dengan tb_ajar dapat dilihat pada gambar dibawah ini :
Post tb_dosen ke tb_ajar
Tb_dosen (NID, kd_jurusan,
kd_status, nm_dosen, gelar,
tmp_lahir,
tgl_lahir,
jenis_klmn, agama, alamat,
kab, kota, kd_pos, phone1,
phone2,
email,
jabatan,
keahlian, pendidikan)
Tb_ajar
(id_ajar,
thn_akademik,
smstr,
hari)
Primary key id_ajar, NID
Primary key NID
Foreign key NID
Foreign key
kd_status
NID,
kd_jurusan,
Gambar 4.12 Binary Relationship tb_dosen ke tb_ajar
80
One to Many (1:*) Binary Relationship Types antara tb_dosen
dengan tb_jadwal dapat dilihat pada gambar di bawah ini :
Post tb_dosen ke tb_jadwal
Tb_dosen (NID, kd_jurusan,
kd_status, nm_dosen, gelar,
tmp_lahir,
tgl_lahir,
jenis_klmn, agama, alamat,
kab, kota, kd_pos, phone1,
phone2,
email,
jabatan,
keahlian, pendidikan)
Tb_jadwal
(id_jadwal,
id_kelas,
ruang,
NID,
kd_mk,
thn_akademik,
smstr, jam_1, jam_2, hari,
kapasitas, terisi, status)
Primary key NID
Foreign key id_kelas, ruang,
NID, kd_mk, id_buka
Foreign key
kd_status
Primary key id_jadwal
kd_jurusan,
Gambar 4.13 Binary Relationship tb_dosen ke tb_jadwal
One to Many (1:*) Binary Relationship Types antara tb_jadwal
dengan tb_kelas dapat dilihat pada gambar dibawah ini :
Post tb_jadwal ke tb_kelas
Tb_jadwal
(id_jadwal,
id_kelas,
ruang,
NID,
kd_mk,
thn_akademik,
smstr, jam_1, jam_2, hari,
kapasitas, terisi, status)
Primary key id_jadwal
Tb_kelas (id_kelas, kd_mk,
kelas, thn_akademik)
Primary key id_kelas
Foreign key kd_mk
Foreign key id_kelas, ruang,
NID, kd_mk, id_buka
Gambar 4.14 Binary Relationship tb_jadwal ke tb_kelas
81
One to Many (1:*) Binary
Relationship Types antara tb_krs
dengan tb_jadwal dapat dilihat pada gambar dibawah ini :
Post tb_krs ke tb_jadwal
Tb_krs (id_krs, NIM, id_jadwal,
Tb_jadwal
id_buka, id_kelas, kd_mk, NID)
id_kelas,
ruang,
Primary
kd_mk,
thn_akademik,
key
id_jadwal,
id_krs,
id_buka,
NIM,
id_kelas,
kd_mk, NID
Foreign
key
(id_jadwal,
NID,
smstr, jam_1, jam_2, hari,
kapasitas, terisi, status)
NIM,
id_jadwal,
id_buka, id_kelas, kd_mk, NID
Primary
id_kelas,
key
id_jadwal,
NID,
id_buka,
kd_mk
Foreign key id_kelas, ruang,
NID, kd_mk, id_buka
Gambar 4.15 Binary Relationship tb_krs ke tb_jadwal
82
One to Many (1:*) Binary
Relationship Types antara
tb_konsentrasi dengan tb_kurikulum dapat dilihat pada gambar
dibawah ini :
Post tb_konsentrasi ke tb_kurikulum
Tb_konsentrasi
(kd_konsen,
Tb_kurikulum (kd_mk, id_jmk, id_kmk,
kd_jurusan, kd_konsen, thn_kurikulum,
kd_jurusan, konsen)
nm_mk, sks, semester, prasyarat)
Primary key kd_konsen
Primary key kd_mk
Foreign key kd_jurusan
Foreign key id_jmk, id_kmk
Gambar 4.16 Binary Relationship tb_konsentrasi ke tb_kurikulum
One to Many (1:*) Binary Relationship Types antara tb_jurusan
dengan tb_kurikulum dapat dilihat pada gambar dibawah ini :
Post tb_jurusan ke tb_kurikulum
Tb_jurusan
(kd_jurusan,
kd_fakultas, jurusan, jenjang)
Tb_kurikulum (kd_mk, id_jmk, id_kmk,
kd_jurusan, kd_konsen, thn_kurikulum,
nm_mk, sks, semester, prasyarat)
Primary key kd_jurusan
Primary key kd_mk
Foreign key kd_fakultas
Foreign key id_jmk, id_kmk
Gambar 4.17 Binary Relationship tb_jurusan ke tb_kurikulum
83
4.
Superclass / Subclass Relationship Types
Karena
pada
mempunyai
tb_kurikulum
tahap
4.5.1.5.
“mandatory
maka
terdapat
Or”,
yaitu
dilakukan
entitas
pada
pemisahan
yang
entitas
dengan
menggunakan Option 3 – Mandatory, disjoint ( Thomas
Connoly
dan
Carolyn
Begg
(2002,p451)).
Sehingga
diperoleh :
Jenis_mk (id_jmk, jenis_mk)
Primary key id_jmk
Klmpk_mk (id_kmk, klmpk_mk)
Primary key id_kmk
5.
Many – to – Many (*.*) Binary Relationship Types
Karena pada tahap 4.5.2.1. terdapat Many-to-Many Binary
Relationship
Types antara entitas tb_jadwal dengan
tb_kurikulum, maka dibuatlah suatu entitas baru dengan
nama tb_kelas, sehingga diperoleh hasil seperti pada
gambar dibawah ini :
84
Tb_jadwal
(id_jadwal,
id_kelas,
Tb_bukaMk (id_buka,
ruang, NID, kd_mk, thn_akademik,
kd_mk, thn_akademik, semester)
smstr, jam_1, jam_2, hari, kapasitas,
terisi, status)
Primary key id_buka, kd_mk
Primary key id_jadwal
Foreign key id_jmk, id_kmk
Foreign key id_kelas, ruang, NID,
kd_mk, id_buka
Tb_kelas (id_kelas, id_buka, kd_mk,
kelas, thn_akademik)
Primary
kd_mk
key
id_kelas,
id_buka,
Foreign key kd_mk, id_buka
Gambar 4.18 Binary Relationship Many to many (*:*)
4.5.2.3 Mendefinisikan Kendala Integrity
Berikut ini adalah definisi dari kendala Integrity :
1.
Required Data
Berikut ini adalah Required Data masing – masing entitas :
85
Tabel 4.23 Required Data jenis_mk
Nama
Atribut
Keterangan
Type
Entitas
Jenis_m
k
Kode
Id_jmk
jenis
mata kuliah
Informasi
Jenis_mk
jenis
mata
kuliah
varchar (1)
Varchar
(20)
Not
Multy
Null
Valued
yes
No No no
Tabel 4.24 Required Data jurusan
Nama
Atribut
Keterangan
Type
Entitas
Jurusan
Kd_jurusan
Kode jurusan
Informasi
jurusan
jurusan yang
ada
Jenjang
Jenjang yang
ditawarkan
Varchar (5)
Varchar
(30)
varchar(2)
Not
Multy
Null
Valued
yes
No No no
no
No Tabel 4.25 Required Data klmpk_mk
Nama
Atribut
Keterangan
Type
Entitas
Klmpk_
mk
Not
Multy
Null
Valued
No Kode
Id_kmk
kelompok
varchar (3)
yes
mata kuliah
Informasi
Klmpk_mk
kelompok
mata kuliah
Varchar
(30)
No no
86
Table 4.26 Required Data tb_prasyarat
Nama
Atribut
Keterangan
Type
Entitas
Tb_pras
yarat
Kd_prasyara
Kode
Kd_mk
Multy
Null
Valued
No Kode
prasyarat
t
Not
matakuliah
varchar (5)
Yes
Varchar (5)
Yes
No Tabel 4.27 Required Data tb_ajar
Nama
Atribut
Keterangan
Type
Entitas
Tb_ajar
Not
Multy
Null
Valued
No Kode
Id_ajar
kesediaan
Integer
yes
Integer
yes
hari mengajar
NID
Nomor induk
dosen
No Tahun
Thn_akdmk
No akademik
kesediaan
Varchar (4)
no
Varchar (6)
no
hari mengajar
smstr
hari
semester
Hari
dipilih
yang
Varchar
(10)
no
No No 87
Tabel 4.28 Required Data tb_dosen
Nama
Atribut
Keterangan
Type
Entitas
Tb_dose
n
NID
Kd_jurusan
kd_status
Nm_dosen
Nomor
Null
Valued
yes
Varchar (5)
yes
Kode status
Varchar (3)
yes
Nama
Varchar
dosen
(30)
induk dosen
Kode
jurusan
Gelar
Tmp_lahir
Tempat lahir
Jenis_klmn
Multy
Integer
Gelar
Tgl_lahir
Not
Tanggal
lahir
Jenis
kelamin
Agama
Agama
Alamat
Alamat
Kab
Kabupaten
Kota
Kota
Kd_pos
Kode pos
Phone1
Telepon
Varchar
(10)
Varchar
(20)
no
no
no
Date
no
Varchar (1)
no
Varchar (9)
no
Varchar
(30)
Varchar
(20)
Varchar
(20)
Char (5)
Varchar
(13)
no
no
no
no
no
No No No No No No No No No No No No No No 88
Phone2
Telepon
email
e-mail
Jabatan
Jabatan
Keahlian
Keahlian
pendidikan
pendidikan
Varchar
(13)
Varchar
(25)
Varchar
(20)
Varchar
(20)
Char (2)
no
no
no
no
No No No No no
No Not
Multy
Null
Valued
Tabel 4.29 Required Data tb_jadwal
Nama
Atribut
Keterangan
Type
Entitas
Tb_jadw
al
Id_jadwal
Kode jadwal
Integer
yes
No Id_kelas
Kode kelas
Char (20)
yes
No Int
Yes
Char (20)
yes
Integer
yes
Char (4)
yes
Id_buka Ruang
NID
Kd_mk
Kode
buka
MK
Ruang yang
dipakai
Nomor
induk dosen
Kode mata
kuliah
Thn_akademi
Tahun
k
akademik
Smstr
Jam_1
No
No No No No Date
no
Semester
Char (1)
no
No Jam masuk
Time
no
No 89
No Jam_2
Jam keluar
Hari
Hari
Kapasitas
Kapasitas
Integer
no
No Terisi
Terisi
Integer
no
No Status
Status
Enum
No
No Time
Varchar
(10)
no
no
No Tabel 4.30 Required Data tb_kelas
Nama
Atribut
Keterangan
Type
Entitas
Tb_kelas
Id_kelas
Kd_mk
Id_buka Kelas
Thn_akademik
Kode kelas
Integer
Kode
Varchar
matakuliah
(5)
Kode
buka
matakuliah
Kelas
Integer
Varchar
(1)
Tahun
Varchar
akademik
(4)
Not
Multy
Null
valued
yes
No
yes
yes
no
no
No
No
No
No
Tabel 4.31 Required Data tb_konsentrasi
Nama
Atribut
Keterangan
Type
Entitas
Tb_kons
entrasi
Kd_konsen
Kode
konsentrasi
Not
Multy
Null
Valued
Char (4)
yes
No Kd_jurusan
Kode jurusan
Char (3)
yes
No konsentrasi
Konsentrasi
Varchar(30)
no
No 90
Tabel 4.32 Required Data tb_krs
Nama
Atribut
Keterangan
Type
Not
Multy
Null
valued
Integer
yes
No
Varchar (9)
yes
Entitas
Tb_krs
Id_krs
Kode krs
Nomor induk
NIM
mahasiswa
No
Id_jadwal
Kode jadwal
Integer
Yes
No
Id_kelas
Kode kelas
Integer
Yes
No
Id_buka
Kode
Integer
Yes
No
Varchar (5)
Yes
Kd_mk
NID
Kode
matakuliah
Nomor Indeuk
Varchar
Dosen
(10)
yes
No
No
Tabel 4.33 Required Data tb_kurikulum
Nama
Atribut
Keterangan
Type
Entitas
Tb_kurik
ulum
Kd_mk
Id_jmk
Kode
matakuliah
Kode
jenis
matakuliah
Not
Multy
Null
valued
Varchar (4)
yes
varchar(1)
yes
Kode
Id_kmk
kelompok
No
No
No
Varchar (3)
yes
Varchar (5)
yes
varchar(4)
yes
matakuliah
Kd_jurusan
Kd_konsen
Kode jurusan
Kode
konsentrasi
No
No
91
Thn_krklm
Tahun
kurikulum
Varchar (4)
no
No
Nama
Varchar
matakuliah
(40)
Sks
Satuan kredit
Varchar (1)
no
No
Smstr
Semester
Varchar (6)
no
No
prasyarat
Prasyarat
Nm_mk
Varchar
(40)
no
no
No
no
Tabel 4.34 Required Data tb_mhs
Nama
Atribut
Keterangan
Type
Entitas
Tb_mhs
Not
Multy
Null
valued
Nomor
NIM
induk
No
Varchar (9)
yes
varchar(5)
yes
Integer
yes
mahasiwa
Kd_jurusan
Id_daftspp
Nm_mhs
Tg_msk
Angkatan
Thn_krklm
Tmp_lahir
Kode
jurusan
Kode daftar
spp
Nama
Varchar
mahasiswa
(30)
Tanggal
masuk
Angkatan
Tahun
kurikulum
Tempat lahir
no
Datetime
no
Varchar (4)
no
Datetime
no
Varchar
(30)
no
No
No
No
No
No
No
No
92
Tgl_lahir
Jenis_klmn
Tanggal
lahir
Jenis
kelamin
datetime
no
Varchar (1)
no
Varchar
No
No
No
Agama
Agama
Alamat
Alamat
Kab
Kabupaten
Kota
Kotamadya
Kd_pos
Kode pos
varchar(5)
no
No
Bts_studi
Batas studi
Datetime
no
No
shift
Shift kuliah
(15)
Varchar
(40)
Varchar
(20)
Varchar
(20)
Varchar
(10)
no
no
no
no
no
No
No
No
no
Tabel 4.35 Required Data tb_nilai
Nama
Atribut
Keterangan
Type
Entitas
Tb_nilai
Not
Multy
Null
valued
Id_krs Kode KRS
Int
Yes
No
Id_jadwal Kode jadwal
int
Yes
No
Id_buka Kode buka
Int
Yes
No
Id_kelas Kode kelas
Int
Yes
No
Nomor induk
Varchar
dosen
(10)
Nomor induk
Varchar (9)
NID Yes
No
No
NIM
yes
93
mahasiswa
Kd_mk
Thn_akdmk
Kode
matakuliah
Tahun
akademik
Varchar (5)
yes
Varchar (4)
no
No
No
Smstr
Semester
Varchar (6)
no
No
N_tugas
Nilai tugas
Float
no
No
N_uts
Nilai uts
Float
no
No
N_uas
Nilai uas
Float
no
No
N_total
Total nilai
Float
no
No
N_angka Nilai angka
Float
No
no
Not
Multy
Null
Valued
Tabel 4.36 Required Data tb_ruang
Nama
Atribut
Keterangan
Type
Entitas
Tb_ruang
Ruang
Ruangan
Varchar (4)
yes
No Lantai
Lantai
varchar(2)
no
No Kapasitas
kapasitas
Integer
no
No Not
Multy
Null
Valued
yes
No Tabel 4.37 Required Data tb_status
Nama
Atribut
Keterangan
Type
Entitas
Tb_status
kd_status
Kode status
status
Status
Varchar (3)
Varchar
(30)
no
No 94
Tabel 4.38 Required Data tb_buka_mk
Nama
Atribut
Keterangan
Type
Entitas
Tb_buka
_mk
Id_buka
Kd_mk
Thn_akade
Kode
buka
matakuliah
Kode
matakuliah
Tahun
mik akademik
Smstr Semester
Not
Multy
Null
valued
No
Integer
yes
Varchar (5)
Yes
Varchar (4)
No
Varchar (6)
no
No
Not
Multy
Null
valued
No
No
Tabel 4.39 Required data tb_login_mhs
Nama
Atribut
Keterangan
Type
Entitas
Tb_login_
mhs
NIM
Pswd
Nomor induk
mahasiswa
password
varchar(9)
Varchar
(10)
yes
yes
No
no
Tabel 4.40 Required data tb_login_dosen
Nama
Atribut
Keterangan
Type
Entitas
Tb_login_
dosen
NID
Pswd
Nomor induk
Dosen
Password
varchar(10)
Varchar
(10)
Not
Multy
Null
valued
yes
yes
No
no
95
2.
Entitas Integrity
Berikut ini adalah prrimary key dari tiap entitas :
Tabel 4.41 Entitas Integrity
Entity Name
Tb_mhs
Primary Key
NIM
Description
Data Type
Not
Multi
& Length
Null
valued
Nomor
Varchar
Yes
No
induk
(10)
Varchar (5)
Yes
No
Nomor
Varchar
Yes
No
induk dosen
(10)
Kode
varchar (5)
Yes
No
mahasiswa
Tb_jurusan
Kd_jurusan
Kode
jurusan
Tb_dosen
Tb_konsentr
NID
Kd_konsen
asi
konsentrasi
Tb_status
Kd_status
Kode status
Varchar (3)
Yes
No
Tb_ajar
Id_ajar
Kode
Integer
Yes
No
Nomor
Varchar
Yes
No
Induk
(10)
Varchar (5)
Yes
No
Kode Jenis
Varchar
Yes
No
matakuliah
(1)
Kode
Varchar (3)
Yes
No
kesediaan
hari
mengajar
NID
Dosen
Tb_kurikulu
Kd_mk
m
Jenis_mk
Klmpk_mk
Kode
matakuliah
Id_jmk
Id_kmk
kelompok
96
matakuliah
Tb_nilai
Id_krs
Kode KRS
Integer,
Yes
No
NIM
Nomor
Varchar (9)
Yes
No
Induk
Mahasiswa
Tb_kelas
Id_kelas
Kode kelas
Integer
Yes
No
Id_buka
Kode buka
Integer
Yes
No
Kd_mk
Kode
Varchar (5)
Yes
no
matakuliah
Tb_ruang
Ruang
Ruangan
Varchar (3)
Yes
No
Tb_jadwal
id_jadwal
Kode
Integer
Yes
No
Jadwal
id_kelas
Kode Kelas
Integer
Yes
No
id_buka
Kode buka
Integer
Yes
No
kd_mk
Kode
Varchar (5)
Yes
No
Nomor
Varchar
Yes
No
Induk
(10)
Matakuliah
NID
Dosen
Tb_krs
id_krs
Kode krs
Integer
Yes
No
id_jadwal
Kode
Integer
Yes
No
Jadwal
id_kelas
Kode kelas
Integer
Yes
No
id_buka
Kode buka
Integer
Yes
No
kd_mk
Kode
Varchar (5)
Yes
No
Varchar (9)
Yes
No
matakuliah
NIM
Nomor
induk
mahasiswa
97
NID
Nomor
Varchar
Induk
(10)
Yes
No
Dosen
Tb_buka_mk
Id_buka,
Kode buka
Integer,
Yes
No
kd_mk
Kode
varchar (5)
Yes
No
Varchar (9)
Yes
No
Varchar
Yes
No
Yes
No
Yes
No
matakuliah
Tb_login_mh
NIM
Nomor
s
Induk
Mahasiswa
Psswd
password
(10)
Tb_login_do
NID
sen
Nomor
Varchar
Induk
(10)
Dosen
Psswd
password
Varchar
(10)
3.
Referensial Integrity
Menentukan Action (Insert child, Delete child, Update child,
insert parent, Delete parent, Update parent PK) dari tiap –
tiap entitas.
a.
Referential Integrity pada entitas tb_mhs menuju
jurusan
Tb_mhs
Jurusan
action Gambar 4.19 Referential Integrity pada entitas tb_mhs ke jurusan
98
Table 4.42 Referential Integrity pada entitas tb_mhs ke jurusan
Insert child NIM tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect b.
Referential Integrity pada entitas tb_konsentrasi
menuju jurusan
Tb_konsentrasi
jurusan
action Gambar 4.20 Referential Integrity pada tb_konsentrasi ke jurusan
Table 4.43 Referential Integrity pada entitas tb_konsentrasi ke jurusan
Insert child Kd_konsen tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect 99
c.
Referential Integrity pada entitas tb_kurikulum menuju
jurusan
Tb_kurikulum
Jurusan
action Gambar 4.21 Referential Integrity pada tb_kurikulum ke jurusan
Table 4.44 Referential Integrity pada entitas tb_kurikulum ke jurusan
Insert child Kd_mk tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect d.
Referential Integrity pada entitas tb_kurikulum menuju
tb_konsentrasi
Tb_kurikulum
Tb_konsentrasi
action Gambar 4.22 Referential Integrity pada entitas tb_kurikulum ke
tb_konsentrasi
100
Table 4.45 Referential Integrity pada entitas tb_kurikulumke
tb_konsentrasi
Insert child Kd_konsen tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect e.
Referential Integrity pada entitas tb_dosen menuju
tb_status
Tb_dosen
Tb_status
action Gambar 4.23 Referential Integrity pada entitas tb_dosen ke tb_status
Table 4.46 Referential Integrity pada entitas tb_dosen ke tb_status
Insert child NID tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect 101
f.
Referential Integrity pada entitas tb_ajar menuju
tb_dosen
Tb_ajar
Tb_dosen
action Gambar 4.24 Referential Integrity pada entitas tb_ajar ke tb_dosen
Table 4.47 Referential Integrity pada entitas tb_ajar ke tb_dosen
Insert child Id_ajar tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect g.
Referential Integrity pada entitas tb_jadwal menuju
tb_dosen
Tb_jadwal
Tb_dosen
action Gambar 4.25 Referential Integrity pada entitas tb_jadwal ke tb_dosen
102
Table 4.48 Referential Integrity pada entitas tb_jadwal ke tb_dosen
Insert child Id_jadwal tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect h.
Referential Integrity pada entitas tb_jadwal menuju
tb_ruang
Tb_jadwal
Tb_ruang
action Gambar 4.26 Referential Integrity pada entitas tb_jadwal ke tb_ruang
Table 4.49 Referential Integrity pada entitas tb_jadwal ke tb_ruang
Insert child Id_jadwal tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect 103
i.
Referential Integrity pada entitas tb_jadwal menuju
tb_kelas
Tb_jadwal
Tb_kelas
action Gambar 4.27 Referential Integrity pada entitas tb_jadwal ke tb_kelas
Table 4.50 Referential Integrity pada entitas tb_jadwal ke tb_kelas
Insert child Id_jadwal tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect j.
Referential Integrity pada entitas tb_kelas menuju
tb_buka_mk
Tb_kelas
Tb_buka_mk
action Gambar 4.28 Referential Integrity pada entitas tb_kelas ke tb_buka_mk
104
Table 4.51 Referential Integrity pada entitas tb_kelas ke tb_buka_mk
Insert child Id_kelas tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect k.
Referential Integrity pada entitas tb_buka_mk menuju
tb_kurikulum
Tb_buka_mk
Tb_kurikulum
action Gambar 4.29 Referential Integrity pada entitas tb_buka_mk ke
tb_kurikulum
Table 4.52 Referential Integrity pada entitas tb_buka_mk ke tb_kurikulum
Insert child Id_buka tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect 105
l.
Referential Integrity pada entitas tb_nilai menuju tb_krs
Tb_nilai
Tb_krs
action Gambar 4.30 Referential Integrity pada entitas tb_nilai ke tb_krs
Table 4.53 Referential Integrity pada entitas tb_nilai ke tb_krs
Insert child Id_nilai tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect m. Referential Integrity pada entitas tb_krs menuju tb_mhs
Tb_krs
Tb_mhs
action Gambar 4.31 Referential Integrity pada entitas tb_krs ke tb_mhs
106
Table 4.54 Referential Integrity pada entitas tb_krs ke tb_mhs
Insert child Id_krs tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect n.
Referential Integrity pada entitas tb_krs menuju
tb_jadwal
Tb_krs
Tb_jadwal
action Gambar 4.32 Referential Integrity pada entitas tb_krs ke tb_jadwal
Table 4.55 Referential Integrity pada entitas tb_krs ke tb_jadwal
Insert child Id_krs tidak boleh null Delete child No effect Update child No effect Delete parent No effect Update parent No effect 107
4.5.2.4 Data Model Lokal Logikal
Gambar 4.33 Model Lokal Logikal
108
4.5.3
Perancangan Basis Data Fisikal
Perancangan basis data fisik merupakan proses pembuatan
deskripsi dari suatu implementasi basis data pada secondary storage.
Beberapa langkah penting dalam merancanga basis data secara fisik
adalah :
1.
Perancangan Relasional Basis Data
2.
Analisis Transaksi
3.
Mengestimasi Kapasitas yang dibutuhkan
4.5.3.1 Perancangan Relasional Basis Data
Tujuan dari tahap ini adalah untuk mengIdentifikasi
kan
relasional basis data dalam model data logikal global yang digunakan
dalam DBMS yang menggunakan DBDL (Database Design Language).
DBDL yang digunakan adalah sebagai berikut :
DBDL jenis_mk
CREATE TABEL [jenis_mk] (
[id_jmk] [varchar] (1) COLLATE Latin1_General_CI_AS NOT
NULL ,
[jenis_mk] [varchar] (20) COLLATE Latin1_General_CI_AS
NULL ,
[LastUpdate] [datetime] NULL ,
CONSTRAINT [PK__jenis_mk__15502E78] PRIMARY KEY
CLUSTERED
(
[id_jmk]
) ON [PRIMARY]
) ON [PRIMARY]
GO
109
DBDL jurusan
CREATE TABLE [jurusan] (
[kd_jurusan] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
[jurusan] [varchar] (30) COLLATE Latin1_General_CI_AS NULL
,
[jenjang] [varchar] (2) COLLATE Latin1_General_CI_AS NULL ,
[LastUpdate] [datetime] NULL ,
CONSTRAINT [PK__jurusan__0BC6C43E] PRIMARY KEY
CLUSTERED
(
[kd_jurusan]
) ON [PRIMARY]
) ON [PRIMARY]
GO
DBDL klmpk_mk
CREATE TABEL [klmpk_mk] (
[id_kmk] [varchar] (3) COLLATE Latin1_General_CI_AS NOT
NULL ,
[klmpk_mk] [varchar] (50) COLLATE Latin1_General_CI_AS
NULL ,
[LastUpdate] [datetime] NULL ,
CONSTRAINT [PK__klmpk_mk__173876EA] PRIMARY KEY
CLUSTERED
(
[id_kmk]
) ON [PRIMARY]
110
) ON [PRIMARY]
GO
DBDL tb_prasyarat
CREATE TABLE [tb_prasyarat] (
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_prasyarat] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
[indeks_minimal] [varchar] (1) COLLATE Latin1_General_CI_AS
NULL ,
CONSTRAINT [PK_tb_prasyarat] PRIMARY KEY CLUSTERED
(
[kd_mk],
[kd_prasyarat]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_prasyarat_tb_kurikulum] FOREIGN KEY
(
[kd_mk]
) REFERENCES [tb_kurikulum] (
[kd_mk]
)
) ON [PRIMARY]
GO
111
DBDL tb_ajar
CREATE TABEL [tb_ajar] (
[id_ajar] [int] NOT NULL ,
[NID] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[thn_akademik] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[smstr] [varchar] (1) COLLATE Latin1_General_CI_AS NULL ,
[hari] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
CONSTRAINT [PK__tb_ajar__1920BF5C] PRIMARY KEY
CLUSTERED
(
[id_ajar],
[NID]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_ajar_tb_dosen] FOREIGN KEY
(
[NID]
) REFERENCES [tb_dosen] (
[NID]
)
) ON [PRIMARY]
GO
DBDL tb_buka_mk
CREATE TABEL [tb_buka_mk] (
[id_buka] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
112
NULL ,
[thn_akademik] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[semester] [varchar] (6) COLLATE Latin1_General_CI_AS
NULL ,
CONSTRAINT [PK__tb_buka_mk__023D5A04] PRIMARY KEY
CLUSTERED
(
[id_buka],
[kd_mk]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_buka_mk_tb_kurikulum] FOREIGN KEY
(
[kd_mk]
) REFERENCES [tb_kurikulum] (
[kd_mk]
)
) ON [PRIMARY]
GO
DBDL tb_dosen
CREATE TABEL [tb_dosen] (
[NID] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[nm_dosen] [varchar] (30) COLLATE Latin1_General_CI_AS
NULL ,
[gelar] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
[tmp_lahir] [varchar] (30) COLLATE Latin1_General_CI_AS
NULL ,
113
[tgl_lahir] [datetime] NULL ,
[jenis_klmn] [varchar] (9) COLLATE Latin1_General_CI_AS
NULL ,
[agama] [varchar] (15) COLLATE Latin1_General_CI_AS NULL
,
[alamat] [varchar] (50) COLLATE Latin1_General_CI_AS NULL
,
[kab] [varchar] (30) COLLATE Latin1_General_CI_AS NULL ,
[kota] [varchar] (30) COLLATE Latin1_General_CI_AS NULL ,
[kd_pos] [varchar] (5) COLLATE Latin1_General_CI_AS NULL ,
[phone1] [varchar] (13) COLLATE Latin1_General_CI_AS NULL
,
[phone2] [varchar] (13) COLLATE Latin1_General_CI_AS NULL
,
[email] [varchar] (25) COLLATE Latin1_General_CI_AS NULL ,
[jabatan] [varchar] (20) COLLATE Latin1_General_CI_AS NULL
,
[keahlian] [varchar] (20) COLLATE Latin1_General_CI_AS
NULL ,
[pendidikan] [varchar] (2) COLLATE Latin1_General_CI_AS
NULL ,
[kd_status] [varchar] (3) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_fakultas] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
CONSTRAINT [PK__tb_dosen__0DAF0CB0] PRIMARY KEY
CLUSTERED
(
[NID]
) ON [PRIMARY] ,
114
CONSTRAINT [FK_tb_dosen_fakultas] FOREIGN KEY
(
[kd_fakultas]
) REFERENCES [fakultas] (
[kd_fakultas]
),
CONSTRAINT [FK_tb_dosen_tb_status] FOREIGN KEY
(
[kd_status]
) REFERENCES [tb_status] (
[kd_status]
)
) ON [PRIMARY]
GO
DBDL tb_jadwal
CREATE TABEL [tb_jadwal] (
[id_jadwal] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_kelas] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[ruang] [varchar] (4) COLLATE Latin1_General_CI_AS NOT
NULL ,
[NID] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[thn_akademik] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL CONSTRAINT [DF_tb_jadwal_thn_akademik] DEFAULT (0),
[smstr] [varchar] (6) COLLATE Latin1_General_CI_AS NULL ,
115
[jam_1] [datetime] NULL CONSTRAINT
[DF__tb_jadwal__jam_1__4F7CD00D] DEFAULT ('00:00'),
[jam_2] [datetime] NULL CONSTRAINT
[DF__tb_jadwal__jam_2__5070F446] DEFAULT ('00:00'),
[hari] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
[kapasitas] [int] NULL ,
[terisi] [int] NULL ,
[status] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
[id_buka] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
CONSTRAINT [PK__tb_jadwal__4E88ABD4] PRIMARY KEY
CLUSTERED
(
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_jadwal_tb_dosen] FOREIGN KEY
(
[NID]
) REFERENCES [tb_dosen] (
[NID]
),
CONSTRAINT [FK_tb_jadwal_tb_kelas] FOREIGN KEY
(
[id_kelas],
[id_buka],
116
[kd_mk]
) REFERENCES [tb_kelas] (
[id_kelas],
[id_buka],
[kd_mk]
),
CONSTRAINT [FK_tb_jadwal_tb_ruang] FOREIGN KEY
(
[ruang]
) REFERENCES [tb_ruang] (
[ruang]
)
) ON [PRIMARY] GO
DBDL tb_kelas
CREATE TABEL [tb_kelas] (
[id_kelas] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_buka] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kelas] [char] (2) COLLATE Latin1_General_CI_AS NULL ,
[thn_akademik] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
CONSTRAINT [PK__tb_kelas__7A9C383C] PRIMARY KEY
CLUSTERED
(
[id_kelas],
117
[id_buka],
[kd_mk]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_kelas_tb_buka_mk] FOREIGN KEY
(
[id_buka],
[kd_mk]
) REFERENCES [tb_buka_mk] (
[id_buka],
[kd_mk]
)
) ON [PRIMARY]
GO
DBDL tb_konsentrasi
CREATE TABEL [tb_konsentrasi] (
[kd_konsen] [varchar] (4) COLLATE Latin1_General_CI_AS
NOT NULL ,
[kd_jurusan] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
[konsen] [varchar] (40) COLLATE Latin1_General_CI_AS NULL
,
[LastUpdate] [datetime] NULL ,
CONSTRAINT [PK__tb_konsentrasi__117F9D94] PRIMARY
KEY CLUSTERED
(
[kd_konsen]
118
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_konsentrasi_jurusan] FOREIGN KEY
(
[kd_jurusan]
) REFERENCES [jurusan] (
[kd_jurusan]
)
) ON [PRIMARY]
GO
DBDL tb_krs
CREATE TABLE [tb_krs] (
[id_krs] [int] NOT NULL ,
[NIM] [varchar] (9) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_jadwal] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_kelas] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_buka] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[semester] [varchar] (6) COLLATE Latin1_General_CI_AS
NULL ,
[thn_akademik] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
119
[b_sks] [decimal](18, 0) NULL ,
CONSTRAINT [PK__tb_krs__7C8480AE] PRIMARY KEY
CLUSTERED
(
[id_krs],
[NIM],
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_krs_tb_jadwal] FOREIGN KEY
(
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk]
) REFERENCES [tb_jadwal] (
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk]
),
CONSTRAINT [FK_tb_krs_tb_mhs] FOREIGN KEY
(
[NIM]
) REFERENCES [tb_mhs] (
[NIM]
)
) ON [PRIMARY]
120
GO
DBDL tb_kurikulum
CREATE TABEL [tb_kurikulum] (
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_jmk] [varchar] (1) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_kmk] [varchar] (3) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_jurusan] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
[kd_konsen] [varchar] (4) COLLATE Latin1_General_CI_AS
NOT NULL ,
[thn_kurikulum] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[nm_mk] [varchar] (30) COLLATE Latin1_General_CI_AS NULL
,
[sks] [varchar] (3) COLLATE Latin1_General_CI_AS NULL ,
[semester] [varchar] (6) COLLATE Latin1_General_CI_AS
NULL ,
[prasyarat] [varchar] (20) COLLATE Latin1_General_CI_AS
NULL ,
CONSTRAINT [PK__tb_kurikulum__1367E606] PRIMARY KEY
CLUSTERED
(
[kd_mk]
) ON [PRIMARY] ,
121
CONSTRAINT [FK_tb_kurikulum_jenis_mk] FOREIGN KEY
(
[id_jmk]
) REFERENCES [jenis_mk] (
[id_jmk]
),
CONSTRAINT [FK_tb_kurikulum_jurusan] FOREIGN KEY
(
[kd_jurusan]
) REFERENCES [jurusan] (
[kd_jurusan]
),
CONSTRAINT [FK_tb_kurikulum_klmpk_mk] FOREIGN KEY
(
[id_kmk]
) REFERENCES [klmpk_mk] (
[id_kmk]
),
CONSTRAINT [FK_tb_kurikulum_tb_konsentrasi] FOREIGN
KEY
(
[kd_konsen]
) REFERENCES [tb_konsentrasi] (
[kd_konsen]
)
) ON [PRIMARY] GO
DBDL tb_login_dosen
CREATE TABEL [tb_login_dosen] (
122
[psswd] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[NID] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
PRIMARY KEY CLUSTERED
(
[psswd],
[NID]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_login_dosen_tb_dosen] FOREIGN KEY
(
[NID]
) REFERENCES [tb_dosen] (
[NID]
)
) ON [PRIMARY]
GO
DBDL tb_login_mhs
CREATE TABEL [tb_login_mhs] (
[psswd] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[NIM] [varchar] (9) COLLATE Latin1_General_CI_AS NOT
NULL ,
[LastUpdate] [datetime] NULL ,
PRIMARY KEY CLUSTERED
(
[psswd],
[NIM]
123
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_login_mhs_tb_mhs] FOREIGN KEY
(
[NIM]
) REFERENCES [tb_mhs] (
[NIM]
)
) ON [PRIMARY]
GO
DBDL tb_mhs
CREATE TABEL [tb_mhs] (
[NIM] [varchar] (9) COLLATE Latin1_General_CI_AS NOT
NULL ,
[nm_mhs] [varchar] (30) COLLATE Latin1_General_CI_AS
NULL ,
[tgl_masuk] [datetime] NULL ,
[angkatan] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[thn_kurikulum] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[tmpt_lahir] [varchar] (30) COLLATE Latin1_General_CI_AS
NULL ,
[tgl_lhr] [datetime] NULL ,
[jenis_klmn] [varchar] (9) COLLATE Latin1_General_CI_AS
NULL ,
[agama] [varchar] (15) COLLATE Latin1_General_CI_AS NULL
,
[alamat] [varchar] (50) COLLATE Latin1_General_CI_AS NULL
124
,
[kab] [varchar] (30) COLLATE Latin1_General_CI_AS NULL ,
[kota] [varchar] (30) COLLATE Latin1_General_CI_AS NULL ,
[kd_pos] [varchar] (5) COLLATE Latin1_General_CI_AS NULL ,
[batas_studi] [varchar] (4) COLLATE Latin1_General_CI_AS
NULL ,
[shift] [varchar] (10) COLLATE Latin1_General_CI_AS NULL ,
[id_daftspp] [int] NOT NULL ,
[kd_fakultas] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
[kd_jurusan] [varchar] (5) COLLATE Latin1_General_CI_AS
NOT NULL ,
CONSTRAINT [PK__tb_mhs__07F6335A] PRIMARY KEY
CLUSTERED
(
[NIM]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_mhs_daft_spp] FOREIGN KEY
(
[id_daftspp]
) REFERENCES [daft_spp] (
[id_daftspp]
),
CONSTRAINT [FK_tb_mhs_fakultas] FOREIGN KEY
(
[kd_fakultas]
) REFERENCES [fakultas] (
[kd_fakultas]
),
CONSTRAINT [FK_tb_mhs_jurusan] FOREIGN KEY
125
(
[kd_jurusan]
) REFERENCES [jurusan] (
[kd_jurusan]
)
) ON [PRIMARY]
GO
DBDL tb_nilai
CREATE TABLE [tb_nilai] (
[id_krs] [int] NOT NULL ,
[id_jadwal] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_buka] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[id_kelas] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[NID] [varchar] (10) COLLATE Latin1_General_CI_AS NOT
NULL ,
[NIM] [varchar] (9) COLLATE Latin1_General_CI_AS NOT
NULL ,
[kd_mk] [varchar] (5) COLLATE Latin1_General_CI_AS NOT
NULL ,
[n_tugas] [float] NULL ,
[n_uts] [float] NULL ,
[n_uas] [float] NULL ,
[n_total] [float] NULL ,
[n_huruf] [char] (1) COLLATE Latin1_General_CI_AS NULL ,
[n_angka] [float] NULL ,
126
CONSTRAINT [PK_tb_nilai] PRIMARY KEY CLUSTERED
(
[NIM],
[id_krs]
) ON [PRIMARY] ,
CONSTRAINT [FK_tb_nilai_tb_krs] FOREIGN KEY
(
[id_krs],
[NIM],
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk],
[NID]
) REFERENCES [tb_krs] (
[id_krs],
[NIM],
[id_jadwal],
[id_kelas],
[id_buka],
[kd_mk],
[NID]
)
) ON [PRIMARY]
GO
alter table [dbo].[tb_nilai] nocheck constraint [FK_tb_nilai_tb_krs]
GO
127
DBDL tb_ruang
CREATE TABEL [tb_ruang] (
[ruang] [varchar] (4) COLLATE Latin1_General_CI_AS NOT
NULL ,
[lantai] [varchar] (2) COLLATE Latin1_General_CI_AS NULL ,
[kapasitas] [varchar] (2) COLLATE Latin1_General_CI_AS
NULL ,
CONSTRAINT [PK__tb_ruang__76CBA758] PRIMARY KEY
CLUSTERED
(
[ruang]
) ON [PRIMARY]
) ON [PRIMARY]
GO
DBDL tb_status
CREATE TABEL [tb_status] (
[kd_status] [varchar] (3) COLLATE Latin1_General_CI_AS NOT
NULL ,
[status] [varchar] (40) COLLATE Latin1_General_CI_AS NULL ,
[LastUpdate] [datetime] NULL ,
CONSTRAINT [PK__tb_status__0F975522] PRIMARY KEY
CLUSTERED
(
[kd_status]
) ON [PRIMARY]
) ON [PRIMARY]
GO
128
4.5.3.2 Analisis Transaksi
Tujuan dari langkah ini adalah untuk mengerti fungsionalitas
dari setiap transaksi yang akan berjalan pada database dan menganalisa
transaksi yang penting. Transaksi – transaksi yang terjadi adalah sebagai
berikut :
(A) Memasukkan dan mengubah data mahasiswa
(B) Memasukkan dan mengubah data dosen
(C) Memasukkan dan mengubah data kurikulum
(D) Memasukkan dan mengubah data jurusan
(E) Memasukkan dan mengubah jadwal
(F) Membuat kartu rencana studi
(G) Membuka matakuliah
(H) Membuat kelas
(I)
Membuat laporan nilai
(J) Memasukkan dan mengubah kesediaan mengajar
129
Tabel 4.56 Representasi Fisikal
Transaksi
Relasi
Tb_mhs
A
B
I
R
U
x
x
x
D
Tb_Dosen
C
I
R
U
x
x
x
D
I
R
U
D
Tb_ajar
x
Tb_status
x
Jurusan
x
x
x
Tb_Konsentrasi
x
Tb_Kurikulum
x
Jenis_mk
x
Klmpk_mk
x
x
Tb_buka_mk
Tb_kelas
Tb_jadwal
Tb_krs
Tb_ruang
Tb_nilai
Transaksi
Relasi
D
I
R
E
U
D
I
R
U
D
I
R
x
Tb_mhs
Tb_Dosen
F
x
U
D
130
Tb_ajar
Tb_status
Jurusan
x
x
x
Tb_Konsentrasi
x
Tb_Kurikulum
Jenis_mk
Klmpk_mk
Tb_buka_mk
x
Tb_kelas
x
Tb_jadwal
x
x
Tb_nilai
x
x
Tb_krs
Tb_ruang
x
x
x
x
131
Transaksi
Relasi
G
I
R
H
U
D
I
R
I
U
D
I
R
x
Tb_mhs
Tb_Dosen
Tb_ajar
Tb_status
Jurusan
Tb_Konsentrasi
x
x
Tb_Kurikulum
x
x
Jenis_mk
Klmpk_mk
Tb_buka_mk
x
x
x
x
x
x
Tb_kelas
x
x
x
Tb_jadwal
Tb_krs
Tb_ruang
x
Tb_nilai
Transaksi
Relasi
J
I
R
U
Tb_mhs
x
Tb_Dosen
Tb_ajar
x
x
x
D
U
D
132
Tb_status
Jurusan
Tb_Konsentrasi
Tb_Kurikulum
Jenis_mk
Klmpk_mk
Tb_buka_mk
Tb_kelas
Tb_jadwal
Tb_krs
Tb_ruang
Tb_nilai
4.5.3.3 Estimasi Kapasitas Penyimpanan yang Dibutuhkan
Tujuan dari langkah ini adalah untuk menghitung kapasitas
penyimpanan yang dibutuhkan oleh basis data. Perkiraaan kapasitas
setiap tabel adalah sebagai berikut :
133
Tabel 4.57 Estimasi Kapasitas Penyimpanan jenis_mk
Field
Type
Ukuran
Id_jmk
varchar (1)
1 Jenis_mk
Varchar (20)
20 Kapasitas dari tabel jenis_mk adalah 21 byte Tabel 4.58 Estimasi Kapasitas Penyimpanan jurusan
Atribut
Type
Ukuran
Kd_jurusan
Varchar (5)
5 Varchar
30 Jurusan
(30)
Jenjang
varchar(2)
2 Kd_fakultas
Varchar (5)
5 Kapasitas dari tabel jurusan adalah 42 byte Tabel 4.59 Estimasi Kapasitas Penyimpanan klmpk_mk
Atribut
Type
Ukuran
Id_kmk
varchar (3)
3
Klmpk_mk
Varchar (30)
30
Kapasitas dari tabel klmpk_mk adalah 33
byte
134
Tabel 4.60 Estimasi Kapasitas Penyimpanan tb_ajar
Atribut
Type
Ukuran
Id_ajar
Integer
4
NID
varchar
10
Thn_akdmk
Varchar (4)
4
smstr
Varchar (6)
6
hari
Varchar
(10)
10
Kapasitas dari tabel tb_ajar adalah 34 byte
Diperkirakan
setiap
semester
penambahan data oleh 90 dosen.
Pertumbuhan dalam satu tahun
2 * 90 * 34 = 6120 byte
terjadi
135
Tabel 4.61 Estimasi Kapasitas Penyimpanan tb_dosen
Atribut
Type
Ukuran NID
Varchar
10 Kd_fakultas
Varchar (5)
5 kd_status
Varchar (3)
3 Nm_dosen
Varchar (30)
30 Gelar
Varchar (10)
10 Tmp_lahir
Varchar (20)
20 Tgl_lahir
Datetime
8 Jenis_klmn
Varchar (9)
9 Agama
Varchar (9)
9 Alamat
Varchar (30)
30 Kab
Varchar (20)
20 Kota
Varchar (20)
20 Kd_pos
Char (5)
5 Phone1
Varchar (13)
13 Phone2
Varchar (13)
13 email
Varchar (25)
25 Jabatan
Varchar (20)
20 Keahlian
Varchar (20)
20 pendidikan
varchar(2)
2 Kapasitas dari tabel tb_dosen adalah 136
272 byte Diperkirakan setiap semester terjadi penambahan 10 dosen. Pertumbuhan dalam satu tahun 10 * 2 * 272 = 5440 byte Tabel 4.62 Estimasi Kapasitas Penyimpanan tb_jadwal
Atribut
Type
Ukuran
Id_jadwal
Integer
4 Id_kelas
Integer
4 Ruang
varchar
4 NID
Integer
4 Kd_mk
Varchar
5 Thn_akademik
Varchar
4 Smstr
Varchar
6 Jam_1
Datetime
8 Jam_2
Datetime
8 Varchar
10 Hari
(10)
Kapasitas
Integer
4 Terisi
Integer
4 Status
Varchar
10 Kapasitas dari tabel tb_jadwal adalah 75 137
byte Diperkirakan setiap semester terjadi penginputan jadwal sebanyak 80 record. Pertumbuhan dalam satu tahun 80 * 2 * 75 = 12000 byte Tabel 4.63 Estimasi Kapasitas Penyimpanan tb_kelas
Atribut
Type
Ukuran
Id_kelas
Integer
4
Kd_mk
Varchar (5)
5
Id_buka Integer
4
Kelas
Varchar (1)
1
Thn_akademik
Varchar (4)
4
Kapasitas dari tabel tb_kelas adalah 18 byte.
Tabel 4.64 Estimasi Kapasitas Penyimpanan tb_konsentrasi
Atribut
Type
Ukuran
Kd_konsen
varchar(4)
4 Kd_jurusan
varchar(5)
5 konsentrasi
Varchar (30)
30 Kapasitas dari tabel tb_konsentrasi adalan 39 byte Tabel 4.65 Estimasi Kapasitas Penyimpanan tb_krs
Atribut
Type
Ukuran
138
Id_krs
Integer
4
NIM
Varchar
9
Id_jadwal
Integer
4
Ruang
Varchar (4)
4
Id_kelas
Integer
4
Id_buka
Integer
4
Kd_mk
Varchar (5)
5
Thn_akademik
Varchar (4)
4
Smstr
Varchar (6)
6
Kapasitas dari tabel tb_krs adalah 44 byte
Diperkirakan setiap semester terjadi registrasi
krs dari 1500 mahasiswa
Pertumbuhan dalam satu tahun
1500 * 2 * 44 = 132000 byte
139
Tabel 4.66 Estimasi Kapasitas Penyimpanan tb_kurikulum
Atribut
Type
Ukuran
Kd_mk
Varchar (4)
4
Id_jmk
varchar(1)
1
Id_kmk
Varchar (3)
3
Kd_jurusan
Varchar (5)
5
Kd_konsen
varchar(4)
4
Thn_krklm
Varchar (4)
4
Nm_mk
Varchar (40)
40
Sks
Varchar (1)
1
Smstr
Varchar (6)
6
Kapasitas dari tabel tb_kurikulum adalah 88
byte
140
Tabel 4.67 Estimasi Kapasitas Penyimpanan tb_mhs
Atribut
Type
NIM
Varchar (9)
9
Kd_jurusan
varchar(5)
5
Id_daftspp
Integer
4
Nm_mhs
Varchar (30)
30
Tg_msk
Datetime
8
Angkatan
Varchar (4)
4
Thn_krklm
Varchar
4
Tmp_lahir
Varchar (30)
30
Tgl_lahir
datetime
8
Jenis_klmn
Varchar (9)
9
Agama
Varchar (15)
15
Alamat
Varchar (40)
40
Kab
Varchar (20)
20
Kota
Varchar (20)
20
Kd_pos
varchar(5)
5
Bts_studi
Datetime
8
shift
Varchar (10)
10
Kapasitas dari tabel tb_mhs adalah 229 byte
Diperkirakan
dalam
satu
penambahan
mahasiswa
tahun
terjadi
sebanyak
1000
record.
Pertumbuhan dalam satu tahun
141
1000 * 229 = 229000 byte
Tabel 4.68 Estimasi Kapasitas Penyimpanan tb_nilai
Atribut
Type
Ukuran
Id_nilai
Integer
4
NIM
Varchar (9)
9
Kd_mk
Varchar (5)
5
Thn_akdmk
Varchar (4)
4
Smstr
Varchar (6)
6
N_tugas
Float
8
N_uts
Float
8
N_uas
Float
8
N_total
Varchar (1)
1
N_angka
Float
8
NxS
Float
8
Kapasitas dari tb_nilai adalah 69 byte.
Diperkirakan
penginputan
setiap
nilai
dari
semester
1500
dengan 5 matakuliah
Pertumbuhan dalam satu tahun
1500 * 2 * 5 * 69 = 2070000 byte
terjadi
mahasiswa
142
Tabel 4.69 Estimasi Kapasitas Penyimpanan tb_ruang
Atribut
Type
Ukuran
Ruang
Varchar (4)
4 Lantai
varchar(2)
2 kapasitas
Integer
4 Kapasitas dari tb_ruang adalah 10 byte Tabel 4.70 Estimasi Kapasitas Penyimpanan tb_status
Atribut
Type
Ukuran
Kd_status
Varchar (3)
3 status
Varchar (30)
30 Kapasitas dari tb_status adalah 33 byte Tabel 4.71 Estimasi Kapasitas Penyimpanan tb_buka_mk
Atribut
Type
Ukuran
Id_buka
Integer
4
Varchar
5
Kd_mk
Thn_akademik Smstr (5)
Varchar
4
(4)
Varchar
6
(6)
Kapasitas dari tb_buka_mk adalah 19 byte
143
4.6 Seleksi DBMS
Pertimbangan dalam pemilihan DBMS dipengaruhi oleh faktor :
•
Kemudahan dalam menggunakan (ease of use)
DBMS
sebaiknya
mudah
dipergunakan
oleh
penggunanya.
•
Kehandalan (Reliability)
DBMS sebaiknya mampu mengamankan data apabila
terjadi kegagalan piranti lunak atau keras, serta
memiliki kinerja yang baik dalam penanganan transaksi
penyimpanan data.
•
Biaya (Cost)
Biaya dari DBMS sebaiknya tidak melebihi anggaran
yang diperkirakan oleh perusahaan.
•
Keamanan (security)
DBMS sebaiknya memiliki mekanisme kontrolterhadap
akses data oleh user dan DBMS dapat membedakan
atau mengenali berbagai tingkat pengguna dari yang
tidak memiliki hak akses hingga yang memiliki hak
administrasi penuh.
•
Kompatibel
DBMS sebaiknya dapat bekerja dengan komponen
piranti keras dan piranti lunak.
•
Stabilitas Vendor (vendor stability)
Sebaiknya memiliki vendor yang memang mempunyai
kredibiltas bagus di bidang DBMS dan vendor tersebut
memberikan dukungan yang baik tehadap pemakai
produk.
•
Kemudahan dalam pengembangan (Development)
DBMS
sebaiknya
mudah
disesuaikan
pengembangan – pengembangan lebih lanjut.
untuk
144
•
Kebutuhan sistem (sistem requirement)
DBMS yang akan dipilih harus sesuai dengan sistem
requirement yang telah ditetapkan user.
Berikut ini adalah perbandingan dalam pemilihan DBMS.
Tabel 4.72 Perbandingan DBMS
DBMS
Keterangan
SQL Server 2000
1.
Kemudahan
DBMS lebih familiar di karyawan.
2.
Kehandalan
DBMS mampu mengamankan data apabila
terjadi kegagalan piranti lunak. Mendukung
relationship
3.
Biaya
Biaya yang dikeluarkan oleh perusahaan
sesuai dengan budget.
4.
Keamanan
DBMS memiliki mekanisme kontrol terhadap
akses data, dapat mengenali berbagai tingkat
pengguna sesuai dengan hak akses yang
diberikan
5.
Kompatibel
DBMS kompatibel dengan aplikasi
berbasis
ASP yang akan dibuat karena masih dalam
satu
vendor
dengan
operating
sistem
windows.
6.
Stabilitas
Vendor
Vendor
memberikan
dukungan
terhadap
145
pemakai product
7.
Kemudahan
DBMS
Pengembangan
melakukan pengembangan.
Kebutuhan
DBMS sesuai dengan Sistem Requirement
sistem
yang ditetapkan user
1.
Kemudahan
DBMS lebih familiar di karyawan
2.
Kehandalan
DBMS belum mampu mengamankan data
8.
mudah
disesuaikan,
ketika
akan
Mysql 4
apabila terjadi kegagalan piranti lunak, dan
belum mendukung relationship
3.
Biaya
Gratis
4.
Keamanan
DBMS memiliki mekanisme kontrol terhadap
akses data, dapat mengenali berbagai tingkat
pengguna sesuai dengan hak akses yang
diberikan
5.
Kompatibel
DBMS agak sulit dalam koneksi dengan
aplikasi berbasis ASP yang akan dibuat.
6.
7.
8
Stabilitas
Vendor
memberikan
dukungan
terhadap
Vendor
pemakai product
Kemudahan
DBMS sulit melakukan konversi data, ketika
Pengembangan
akan melakukan pengembangan.
Kebutuhan
DBMS sesuai dengan Sistem Requirement
146
sistem
yang ditetapkan user
Dari perbandingan diatas, maka DBMS yang dipilih untuk
mendukung aplikasi penjadwalan dan KRS online pada perguruan tinggi
Raharja adalah Ms. SQL Server.
BAB V
KESIMPULAN DAN SARAN
5.1
Kesimpulan
Simpulan yang dapat diambil dari hasil evaluasi pada tugas
akhir ini adalah :
1.
Sistem basis data ini dapat mempercepat RPU dalam
menyusun Jadwal kuliah.
2.
Sistem basis data ini mempercepat proses registrasi KRS
yang dilakukan oleh mahasiswa.
3.
Sistem basis data ini dapat menghasilkan laporan perserta
kelas, quota kelas, pemakaian ruangan, jadwal mengajar
dosen, dan nilai.
5.2
Saran
Saran yang dapat dijadikan bahan pertimbangan untuk
pengembangan laporan ini lebih lanjut antara lain :
1.
Perancangan sistem basis data ini perlu di integrasikan
dengan sistem keuangan.
2.
Sistem basis data ini dapat di lengkapi dengan sistem
berbasis sms dengan sms gateway.
3.
Perancangan sistem basis data ini perlu dilengkapi dengan
kemampuan menghasilkan laporan kesediaan mengajar
dosen dalam satu tahun.
147 DAFTAR PUSTAKA
Anonimous,
Pengertian
perguruan
tinggi
http://id.wikipedia.org/wiki/Perguruan_tinggi diakses 3
Mei 2008 jam 12.30.
_________,
Pengertian
Internet
http://www.balinter.net/news_78_Istilah_Dan_Pengertia
n_Internet.html diakses 07 Mei 2008 jam 11.52.
_________,
Pengertian
Leased
Line
http://www.total.or.id/info.php?kk=Leased%20line
diakses 07 Mei 2008 jam 12.14.
_________,
Pengertian
Microsoft
http://www.mikroskil.ac.id/~andri/vb1-01.pdf
18 Agustus 2008 jam 9:00.
.NET
diakses
_________,
Pengertian
ASP.NET
http://www.mti.ugm.ac.id/~ridi/self/VWD-How-ToMICPress.pdf diakses 18 Agustus 2008 jam 9:00.
Connoly, Thomas and Begg. Carolyn, Database System: A.
Prctical Approach to Design, Implementation, and
Management, Third Edition, Addison Wesley Publishing
Company, Inc., 2002.
Date, CJ. An Introduction to Database System. Seventh
Edition. Addison Wesley Longman Inc, United States of
America : 2002.
Hariyanto, Bambang. Sistem Manajemen Basis Data,
Pemodelan, Perancangan dan terapannya.Penerbit
Informatika Bandung, Bandung :2004.
Mcleod, Jr, R. Terjemahan Hendra Teguh. Sistem Informasi
Manajemen. Jilid 1, New Jersey. Edisii Ketujuh.
Penerbit PT. Prehalinndo, Jakarta :2001.
LAMPIRAN Prototype 1.
Login Admin 2.
Master Ruangan 3.
Entry Jadwal 4.
Entry Jadwal bagian 2 5.
Kesediaan Mengajar Dosen 6.
Data Nilai Mahasiswa 7.
Data Pemakaian Ruangan 8.
Laporan Pemakaian Ruangan 9.
Data Peserta Kelas 10. Laporan Peserta Kelas 11. Data Jadwal Dosen 12. Laporan Jadwal Dosen 13. Data Nilai Mahasiswa 14. Laporan Nilai Mahasiswa 15. Login Dosen 16. Entry Nilai 17. Jadwal Mengajar Dosen 18. Entry Kesediaan Mengajar 19. Login Mahasiswa 20. Lihat Nilai Mahasiswa 21. Registrasi KRS