LAPORAN TUGAS AKHIR PERANCANGAN SISTEM BASIS DATA JADWAL RENCANA STUDI DAN KARTU RENCANA STUDI PADA PERGURUAN TINGGI RAHARJA

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