BAB 4 PERANCANGAN DAN IMPLEMENTASI. 1. Perancangan database konseptual (conceptual database design)

BAB 4 PERANCANGAN DAN IMPLEMENTASI

4.1

Perancangan Database Perancangan yang dilakukan pada Binus University dibagi menjadi tiga tahapan, yaitu : 1. Perancangan database konseptual (conceptual database design). 2. Perancangan database logikal (logical database design). 3. Peracangan database fisikal (physical database design). 4.1.1 Perancangan Database Konseptual Perancangan database konseptual adalah proses membangun model informasi yang digunakan oleh suatu perusahaan. Tahapan perancangan konseptual ini terdiri dari 7 langkah, yaitu: 4.1.1.1 Identifikasi Tipe Entitas Langkah awal untuk membangun model data konseptual adalah mengidentifikasi tipe-tipe entitas utama yang dibutuhkan oleh pengguna. Berdasarkan analisis spesifikasi kebutuhan pengguna, didapatkan beberapa entitas yang terlibat dalam ruang lingkup

perancangan

aplikasi

KesediaanMengajarJadwal, Kelas,

Pemberitahuan,

MataKuliah, dan Jadwal.

89

ini,

yaitu:

Dosen,

User,

KesediaanMengajarMatakuliah, Jurusan,

HistoryMengajarDosen,

90

Tabel 4.1 Tabel Identifikasi Entitas Nama Entitas

Deskripsi

Alias

Dosen

Istilah umum untuk Dosen

Setiap

orang yang bertugas

terdaftar

mengajar

pengguna.

di

universitas.

Kejadian dosen sebagai

Setiap

dosen

mengajar

pada

jurusan tertentu. Setiap mengisi

dosen kesediaan

mengajar. Setiap memilki

dosen jadwal

mengajar tertentu. Setiap memiliki

dosen history

mengajar dosen. User

Istilah orang yang User

User dimiliki oleh

mempunyai

setiap dosen.

wewenang menggunakan aplikasi.

dalam

91

Nama Entitas

Deskripsi

Alias

Kejadian

KesediaanMengajar- Informasi mengenai Kesediaan-

Kesediaan mengajar

Matkul

mata

kesediaan mengajar Mengajardosen

mata Matakuliah

pada

kuliah

diisi

oleh setiap dosen.

kuliah tertentu. KesediaanMengajar- Informasi kesediaan Kesediaan-

Kesediaan mengajar

Jadwal

jadwal

mengajar

dosen Mengajar-

pada hari dan shift Jadwal

diisi

oleh

setiap dosen.

tertentu. Pemberitahuan

Pemberitahuan yang Pemberitahuan

Setiap

akan

dapat menerima dan

diberikan

kepada pengguna.

pengguna

mengirimkan pemberitahuan.

Jurusan

Informasi mengenai Jurusan

Setiap

jurusan.

memiliki

dosen jurusan

tertentu. HistoryMengajar-

Informasi mengenai HistoryMengajar

Setiap

Dosen

mata kuliah yang Dosen

memiliki

sudah pernah diajar

mengajar.

oleh

dosen

bersangkutan.

yang

dosen history

92

Nama Entitas

Deskripsi

Alias

Kejadian

MataKuliah

Informasi mengenai Matakuliah

Setiap

mata kuliah yang

mengajar satu atau

tersedia.

lebih mata kuliah.

dosen

Setiap mata kuliah memiliki satu jadwal atau lebih. Kelas

Informasi mengenai Kelas

Setiap mata kuliah

kelas yang tersedia.

diajarkan pada satu kelas atau lebih.

Jadwal

Informasi mengenai Jadwal

Setiap

jadwal

memiliki satu jadwal

mengajar

dosen.

dosen

atau lebih.

4.1.1.2 Mengidetifikasi Tipe Relasi Tujuan dari tahap ini adalah untuk menentukan hubungan yang terjadi antara tipe-tipe entitas yang telah diidentifikasi. Berdasarkan entitas-entitas yang telah diidentifikasi, didapatkan hubungan antar entitas sebagai berikut: 1. Dosen mengisi KesediaanMengajarMatkul 2. Dosen mengisi KesediaanMengajarJadwal 3. Dosen memiliki Jadwal 4. Dosen memiliki User

93

5. Dosen memiliki HistoryMengajarDosen 6. Jurusan memiliki Dosen 7. User menerima Pemberitahuan 8. MataKuliah memiliki Jadwal 9. MataKuliah memiliki KesediaanMengajarMatkul 10. MataKuliah memiliki HistoryMengajarDosen 11. MataKuliah memiliki Kelas

Tabel 4.2 Mengidentifikasi Tipe Relasi Nama Entitas

Multiplicity

Hubungan

Nama Entitas

Multiplicity

Kesediaan

1..*

Antar Entitas Dosen

1..1

Mengisi

Mengajar Matakuliah Dosen

1..1

Mengisi

Kesediaan

1..*

MengajarJadwal Dosen

1..1

Memiliki

Jadwal

0..*

Dosen

1..1

Memiliki

User

1..1

Dosen

1..1

Memiliki

History

0..*

MengajarDosen Jurusan

1..1

Memiliki

Dosen

1..*

94

User

1..1

Menerima

Pemberitahuan

0..*

MataKuliah

1..1

Memiliki

Jadwal

1..*

MataKuliah

1..*

Memiliki

Kelas

0..*

MataKuliah

1..1

Memiliki

Kesediaan

1..*

Mengajar Matakuliah MataKuliah

1..1

Memiliki

History

1..*

MengajarDosen

Gambar 4.1 Entity Relationship Diagram Konseptual Awal

95

4.1.1.3 Mengindentifikasi Tipe, Menggabungkan Atribut dan Mengindentifikasi Atribut Domain Tujuan dari tahapan ini adalah mengindentifiksi dan menggabungkan atribut yang dibutuhkan entitas atau relasi serta mengidentifikasi batasan nilai yang valid bagi atribut tersebut. Tabel 4.3 Entitas Pemberitahuan Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Pemberitahuan

KdPemberitahuan

Kode

pem- integer

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

beritahuan

JenisPemberitahuan

Jenis

pem- varchar

beritahuan

(50)

Isi dari pem-

varchar

beritahuan

(500)

Tanggal

Tanggal

datetime

Pemberitahuan

pem-

Pemberitahuan

beritahuan dikirimkan

96

Status

Status pem- varchar beritahuan

Tidak

Tidak

(10)

(diterima atau ditolak)

Tabel 4.4 Entitas Jadwal Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Jadwal

KdJadwal

Kode jadwal

integer

Tidak

Tidak

Hari

Hari

pe- integer

Tidak

Tidak

pe- integer

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

laksanaan Shift

Shift laksanaan

Periode

Periode

char

(tahun

(20)

ajaran) Semester

Semester (ganjil

varchar atau (10)

genap) SemesterBerjalan

Menandakan semester

integer

97

yang sedang berlangsung NoRuang

Nomor

varchar

Tidak

Tidak

Tidak

Tidak

ruangan yang (10) tersedia NamaKampus

Nama

varchar

kampus

(50)

Tabel 4.5 Entitas User Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length User

Username

Username

char (5)

Tidak

Tidak

Jenis

varchar

Tidak

Tidak

pengguna

(10)

Tidak

Tidak

pengguna yang ada JenisUser

yang ada Password

Password

varchar

pengguna

(50)

98

Tabel 4.6 Entitas MataKuliah Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length MataKuliah

KdMataKuliah

Kode

mata char (5)

Tidak

Tidak

mata varchar

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

kuliah NamaMataKuliah

Nama kuliah

SKSTeori

(50)

Jumlah SKS integer teori

mata

kuliah

ber-

sangkutan SKSPraktikum

Jumlah SKS integer praktikum mata

kuliah

bersangkutan NamaKelompok

Nama

varchar

kelompok

(100)

mata

kuliah

(rumpun mata kuliah)

99

PenanggungJawab

Nama

pe- varchar

nanggung

Tidak

Tidak

(100)

jawab kelompok mata

kuliah

bersangkutan

Tabel 4.7 Entitas Kelas Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Kelas

KdKelas

Kode kelas

char (5)

Tidak

Tidak

JumlahMahasiswa

Jumlah

integer

Tidak

Tidak

mahasiswa setiap kelas

Tabel 4.8 Entitas Jurusan Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Jurusan

KdJurusan

Kode jurusan

char (5)

Tidak

Tidak

NamaJurusan

Nama

varchar

Tidak

Tidak

100

NamaFakultas

jurusan

(100)

Nama

varchar

fakultas

(100)

Tidak

Tidak

Tabel 4.9 Entitas Dosen Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Dosen

KdDosen

Kode dosen

char (5)

Tidak

Tidak

NamaDosen

Nama dosen

varchar

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Ya

Tidak

Tidak

Ya

(100) AlamatDosen

TeleponRumah

Alamat

varchar

dosen

(100)

Telepon

varchar

rumah dosen (20) bersangkutan LineTelepon

Line telepon varchar rumah dosen (10) bersangkutan (apabila ada)

HPDosen

Nomor

varchar

handphone

(50)

101

dosen EmailDosen

Email dosen

varchar

Tidak

Ya

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

(50) Status

Status dosen varchar (aktif

atau (10)

cuti) SKSMengajar

Jumlah SKS integer mengajar yang

telah

disetujui oleh dosen NamaJabatan

Nama

varchar

jabatan

(50)

Tabel 4.10 Entitas KesediaanMengajarMatkul Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Kesediaan

KdKesediaan

Kode

Mengajar

MengajarMatkul

kesediaan

MataKuliah

mengajar matakuliah

integer

Tidak

Tidak

102

dosen Periode

Periode

varchar

(tahun

(10)

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

ajaran) Semester

Semester (ganjil

varchar atau (10)


Menanda-

integer

kan semester yang sedang berlangsung

Tabel 4.11 Entitas KesediaanMengajarJadwal Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length Kesediaan

KdKesediaan

Kode

Mengajar

MengajarJadwal

kesediaan

Jadwal

integer

Tidak

Tidak

pe- varchar

Tidak

Tidak

mengajar jadwal dosen Hari

Hari laksanaan

(10)

103

Shift

Shift

pe- integer

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

laksanaan Periode

Periode

char

(tahun

(10)

ajaran) Semester

Semester (ganjil

varchar atau (10)


Menanda-

integer


Tabel 4.12 Entitas HistoryMengajarDosen Nama Entitas

Atribut

Deskripsi

Tipe

NULL

Data &

Multi Valued

Length History

KdHistory

Kode history

Mengajar

JumlahSKS

Jumlah SKS integer

Dosen

Mengajar

mengajar dosen dalam satu semester

char (5)

Tidak

Tidak

Tidak

Tidak

104

Periode

Periode

char

(tahun

(10)

Tidak

Tidak

Tidak

Tidak

Tidak

Tidak

ajaran) Semester

Semester (ganjil

varchar atau (10)


Menanda-

integer


4.1.1.4 Menentukan Domain Atribut Tujuan dari tahap ini adalah untuk menentukan domain untuk tiap atribut pada model data konseptual. Tabel 4.12 Tabel Domain Atribut untuk Entitas Pemberitahuan Nama Entitas Pemberitahuan

Atribut

Domain

KdPemberitahuan

Berupa Integer

JenisPemberitahuan

Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi

Pemberitahuan

Berupa varian karakter dengan

105

panjang maksimal 500, yang diisi dengan huruf atau angka dan sudah termasuk spasi TanggalPemberitahuan

Tanggal pemberitahuan berupa [dd/mm/yyyy]

Status


Tabel 4.13 Tabel Domain Atribut untuk Entitas Jadwal Nama Entitas Jadwal

Atribut KdJadwal

Domain Terdiri dari 5 karakter yang diisi dengan huruf atau angka

Hari


Shift

Berupa integer

Periode

Terdiri dari 10 karakter, yang diisi dengan huruf atau angka

Semester

Terdiri dari 10 karakter, yang

106

diisi dengan huruf atau angka SemesterBerjalan

Berupa integer

NoRuang


NamaKampus


Tabel 4.14 Tabel Domain Atribut untuk Entitas User Nama Entitas User

Atribut Username

Domain Terdiri dari 5 karakter, yang diisi dengan huruf atau angka

JenisUser


Password

Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan

107

sudah termasuk spasi

Tabel 4.15 Tabel Domain Atribut untuk Entitas MataKuliah Nama Entitas MataKuliah

Atribut KdMataKuliah

Domain Terdiri dari 5 karakter, yang diisi dengan

huruf pertama

berupa huruf, kemudian sisanya berupa angka 0-9 NamaMataKuliah


SKSTeori

Berupa integer

SKSPraktikum

Berupa integer

NamaKelompok


PenanggungJawab


108

Tabel 4.16 Tabel Domain Atribut untuk Entitas Kelas Nama Entitas

Atribut

Domain

Kelas

NamaKelas

Berupa variant karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi

JumlahMahasiswa

Berupa integer

Tabel 4.17 Tabel Domain Atribut untuk Entitas Jurusan Nama Entitas Jurusan

Atribut KdJurusan

Domain Terdiri dari 5 karakter, dua karakter pertama diisi dengan huruf, kemudian sisanya berupa angka 0-9

NamaJurusan


NamaFakultas


109

Tabel 4.18 Tabel Domain Atribut untuk Entitas Dosen Nama Entitas Dosen

Atribut KdDosen

Domain Terdiri dari 5 karakter, karakter pertama

diisi

dengan

huruf,

kemudian sisanya berupa angka 0-9 NamaDosen


AlamatDosen


TeleponRumah


LineTelepon


110

HPDosen


EmailDosen


Status


SKSMengajar

Berupa integer

NamaJabatan


Tabel 4.19 Tabel Domain Atribut untuk Entitas KesediaanMengajarMatkul

Nama Entitas

Atribut

Domain

KesediaanMengajar-

KdKesediaan

Berupa integer

Matkul

MengajarMatkul

111

Periode


Semester


SemesterBerjalan

Berupa integer

Tabel 4.20 Tabel Domain Atribut untuk Entitas KesediaanMengajarJadwal Nama Entitas

Atribut

KesediaanMengajarJadwal KdKesediaan

Domain Berupa integer

MengajarJadwal Hari


Shift

Berupa integer

Periode


Semester


SemesterBerjalan

Berupa integer

112

Tabel 4.21 Tabel Domain Atribut untuk Entitas HistoryMengajarDosen Nama Entitas

Atribut

HistoryMengajarDosen

Domain

KdHistory

Berupa integer

JumlahSKSMengajar

Berupa integer

Periode


Semester


SemesterBerjalan

Berupa integer

4.1.1.5 Mengindentifikasi Atribut Candidate Key dan Primary Key Tahap ini bertujuan untuk menentukan candidate key dan primary key pada field-field tabel. Tabel 4.22 Tabel Candidate Key dan Primary Key untuk Tiap-Tiap Entitas Nama Entitas

Candidate Key

Primary Key

Pemberitahuan

-KdPemberitahuan

KdPemberitahuan

-Pemberitahuan Jadwal

-KdJadwal

KdJadwal

-Hari User

-Username

Username

113

-Password MataKuliah

-KdMataKuliah

KdMataKuliah

-NamaMataKuliah Kelas

-KdKelas

KdKelas

Dosen

-KdDosen

KdDosen

-NamaDosen Jurusan

-KdJurusan

KdJurusan

-NamaJurusan KesediaanMengajar

-KdKesediaan-

Matkul

MengajarMatKul

KesediaanMengajar

-KdKesediaan-

Jadwal

MengajarJadwal


-KdHistory -JumlahSKSMengajar

KdKesediaanMengajarMatkul

KdKesediaanMengajarJadwal

KdHistory

114

Gambar 4.2 Entity Relationship Diagram konseptual dengan Primary Key

4.1.1.6 Mempertimbangkan

Penggunaan

Konsep

Enchanced

Modelling Tujuan dari tahap ini adalah untuk mempertimbangkan konsep

enchanced

modelling,

seperti

spesialisasi

atau

generalisasi, agregasi, dan komposisi.

4.1.1.7 Memeriksa Model terhadap Redudansi Tujuan dari tahap ini adalah memeriksa ada atau tidaknya redudansi dalam model yang telah kita bangun. Pada tahap ini terdapat 2 langkah yang dilakukan, yaitu: 1. Memeriksa kembali hubungan one-to-one (1:1)

115

Pada tahap ini dilakukan pemeriksaan pada entitas agar tidak mewakili objek yang sama, jika terdapat entitas yang mewakili objek yang sama, maka kedua entitas tersebut dapat digabung menjadi satu. Dalam pengidentifikasian entitas diatas, tidak terdapat hubungan one-to-one (1:1). 2. Menghapus relasi yang redudansi Pada tahap ini dilakukan pemeriksaan agar tidak terdapat redudansi. Sebuah relasi dikatakan redudan jika ada informasi yang bisa didapatkan melalui relasi yang berbeda. Tidak terdapat relasi yang redudansi dalam model ERD konseptual awal yang sudah dicantumkan.

4.1.1.8 Memvalidasikan Model Konseptual Lokal terhadap Transaksi Pengguna Tujuan dari tahap ini adalah untuk memastikan bahwa model konseptual lokal yang dibuat dapat mendukung transaksi yang dibutuhkan oleh pengguna. Terdapat 2 pendekatan yang digunakan dalam langkah ini, yaitu: 1. Mendeskripsikan transaksi Pada

pendekatan

ini,

diperiksa

apakah

semua

informasi (entitas, hubungan antar entitas dan atributnya) yang dibutuhkan oleh setiap transaksi, tersedia oleh model, dengan mendokumentasikan deskripsi dari setiap kebutuhan

116

transaksi. Transaksi-transaksi yang telah diidentifikasi dan harus didukung oleh model konseptual lokal adalah sebagai berikut: a. Melakukan entry, pengubahan, dan penghapusan data mata kuliah. b. Melakukan pencarian mata kuliah berdasarkan kode, nama, dan kelompok mata kuliah yang didatakan. c. Melakukan entry dan pengubahan data dosen. d. Melakukan pencarian terhadap nama dan kode dosen yang didatakan. e. Melakukan entry dan memposting pemberitahuan kepada pengguna melalui e-mail. f. Melakukan pencarian history mengajar dosen berdasarkan kode dosen, nama dosen, dan mata kuliah. g. Melakukan pengisian kesediaan mengajar dan kesediaan mata kuliah yg diajar oleh dosen. h. Mencetak report jadwal mengajar dosen. i. Melakukan entry dan pengubahan data fakultas. j. Melakukan entry dan pengubahan data jurusan. k. Melakukan pencarian terhadap nama dan kode fakultas yang didatakan. l. Melakukan pencarian terhadap nama dan kode jurusan yang didatakan.

117

m. Melakukan

pencocokan

kesediaan

mengajar

dan

kualifikasi mengajar dosen dengan jadwal yang sudah ada. n. Melakukan entry dan mengubah data jadwal mengajar yang belum terisi dengan kesediaan mengajar dari dosen yang diisi sendiri sesuai dengan persetujuan dosen. Dari transaksi-transaksi tersebut, semua informasi yang dibutuhkan telah tersedia dalam model konseptual. 2. Menggunakan jalur-jalur transaksi Pendekatan

kedua

memvalidasikan

model

data

terhadap transaksi yang dibutuhkan dalam merepresentasikan jalur yang diambil oleh setiap transaksi secara langsung pada Entity Relationship Diagram pada digram di bawah ini

118

Gambar 4.3 Entity Relationship Diagram Konseptual dengan Jalur-Jalur Transaksi

4.1.2

Perancangan Database Logikal Perancangan database logikal adalah proses membangun model informasi yang digunakan oleh suatu perusahaan berdasarkan spesifik dan model data, tetapi perancangan ini dapat berdiri sendiri dari DBMS tertentu dan pertimbangan fisik lainnya. Langkah-langkah dalam perancangan basis data logikal, yaitu: 4.1.2.1

Menghilangkan

Fitur-Fitur

yang

Tidak

Kompatibel

dengan Model Relasional Tujuan dari tahapan ini adalah untuk menyempurnakan model data konseptual lokal dengan menghilangkan fitur yang

119

tidak kompatibel dengan model relasional. Terdapat 4 hal yang harus diperhatikan dalam tahap ini, yaitu: 1. Menghilangkan tipe hubungan many-to-many (*:*) Dalam model data konseptual lokal yang telah dibangun terdapat entitas yang memiliki tipe hubungan binari many-to-many (*:*) yang harus dihilangkan, yaitu: a.

Hubungan binari many-to-many (*:*) antara MataKuliah dengan Kelas Hubungan many-to-many (*:*) ini hilang setelah diantara kedua entitas tersebut diselipkan sebuah entitas baru yang berisis detail dari entitas MataKuliah dan Kelas, yaitu DetailMatakuliahKelas.

Gambar 4.4 Penghilangan hubungan binari many-tomany antara MataKuliah dengan Kelas

120

2. Menghilangkan tipe hubungan rekursif many-to-many (*:*) Dalam model data konseptual lokal yang telah dibangun, tidak terdapat tipe relasi rekursif many-to-many (*:*). 3. Menghilangkan tipe hubungan kompleks Dalam model data konseptual lokal yang telah dibangun, tidak terdapat tipe relasi kompleks. 4. Menghilangkan atribut multi-valued Dalam model data konseptual lokal yang telah dibangun, terdapat atribut yang multi-valued, yaitu: a. Atribut multi-valued EmailDosen pada entitas Dosen Atribut EmailDosen ini bersifat multi-valued karena diasumsikan bahwa seorang dosen mungkin memiliki lebih dari satu e-mail. Penghilangan atribut multi-valued EmailDosen pada entitas Dosen dilakukan dengan memisahkan atribut EmailDosen dari Dosen pada sebuah entitas baru, yaitu EmailDosen.

121

Gambar

4.5

Penghilangan

atribut

Multi-valued

EmailDosen pada entitas Dosen

b. Atribut multi-valued HPDosen pada entitas Dosen Atribut HPDosen ini bersifat multi-valued karena diasumsikan bahwa seorang dosen mungkin memiliki lebih dari satu handphone. Penghilangan atribut multi-valued HPDosen pada entitas Dosen dilakukan dengan memisahkan atribut HPDosen dari Dosen pada sebuah entitas baru, yaitu HPDosen.

122

Gambar 4.6. Penghilangan atribut Multi-valued HPDosen pada entitas MsDosen

4.1.2.2 Memperoleh Relasi Untuk Model Data Logikal Tujuan dari tahap ini adalah untuk membuat relasi untuk model data logikal yang digunkan untuk menampilkan entitas, relasi, dan atribut yang telah diindetifikasi pada tahap konseptual. 1. Strong Entity Types Strong entity types adalah entitas yang mandiri, yang keberadaanya tidak bergantung pada keberadaan entitas yang lainnya. Instansiasi entitas kuat selalu memiliki karakteristik yang unik disebut sebagai identifier (sebuah atribut tunggal atau gabungan atribut-atribut yang secara unik dapat digunakan untuk membedakannya dari entitas kuat yang lain).

123

Tabel 4.23 Tabel Strong Entity Types Strong Entity Dosen

(KdDosen,

NamaDosen,

AlamatDosen,

TeleponRumah, LineTelepon, HPDosen, EmailDosen, Status, SKSMengajar, NamaJabatan) Primary Key (KdDosen) Pemberitahuan (KdPemberitahuan, JenisPemberitahuan, Pemberitahuan, TanggalPemberitahuan, status) Primary Key (KdPemberitahuan) User (Username, JenisUser, Password) Primary Key (Username) Jurusan (KdJurusan, NamaJurusan, NamaFakultas) Primary Key (KdJurusan) HistoryMengajarDosen

(KdHistory,

JumlahSKSMengajar, periode, semester) Primary Key (KdHsitory) MataKuliah

(KdMataKuliah,

NamaMataKuliah,

SKSTeori,

SKSPraktikum,

NamaKelompok,

PenanggungJawab) Primary Key (KdMataKuliah) Kelas (KdKelas, JumlahMahasiswa)

124

Primary Key (KdKelas) Jadwal

(KdJadwal,

Kelas,

Hari,

Shift,

Periode,

Semester, SemesterBerjalan, NoRuang, NamaKampus) Primary Key (KdJadwal) KesediaanMengajarJadwal (KdKesedianMengajarJadwal,

Hari,

Shift,

Periode,

Semester, SemesterBerjalan) Primary Key(KdKesediaanMengajarJadwal) KesediaanMengajarMatkul (KdKesediaanMengajarMatkul,

Periode,

Semester,

SemesterBerjalan) Primary Key (KdKesediaanMengajarMatkul)

2. Weak Entity Types Weak entity types adalah entitas yang keberadaanya sangat bergantung pada keberadaan entitas yang lainnya. Weak entity tidak memiliki arti apa-apa dan tidak dikehendaki

kehadirannya

dalam

diagram

ER

kehadiran entitas dimana mereka bergantung. Table 4.24 Tabel Weak Entity Type Dosen Weak Entity EmailDosen (EmailDosen, KdDosen, Num)

tanpa

125

Primary Key (EmailDosen) HPDosen (HPDosen, KdDosen, Num) Primary Key (HPDosen) DetailMatakuliahKelas (KdKelas, KdMataKuliah) Primary Key (KdKelas, KdMataKuliah)

3.

One-to-many (1:*) Binari Relationship Types Untuk setiap hubungan binari one-to-many (1:*), entitas pada ‘satu sisi’ dari hubungan entitas ditunjuk sebagai entitas parent dan entitas pada ‘banyak sisi’ disebut entitas child. Dalam tahap ini diletakkan salinan atribut primary key dari entitas parent ke dalam relasi yang menunjukan entitas child, sebgai foreign key. Hubungan binari one-to-many (1:*) yang terdapat pada model data yang telah ditemukan, yaitu: a. Hubungan Dosen dengan KesediaanMengajarMatkul. Dosen

sebagai

entitas

parent,

dan

KesediaanMengajarMatkul sebagai entitas child, maka primary key pada Dosen, yaitu KdDosen akan diletakkan pada entitas KesediaanMengajarMatkul sebagai foreign key.

126

Gambar

4.7

Hubungan

binari

one-to-many

antara

Dosen

dengan

KesediaanMengajarMatkul

b. Hubungan Dosen dengan KesediaanMengajarJadwal Dosen

sebagai

entitas

parent,

dan

KesediaanMengajarJadwal sebagai entitas child, maka primary key pada Dosen, yaitu KdDosen akan diletakkan pada entitas KesediaanMengajarJadwal sebagai foreign key.

Gambar 4.8 Hubungan binari one-to-many antara Dosen dengan KesediaanMengajarJadwal

127

c. Hubungan Dosen dengan Jadwal Dosen sebagai entitas parent, dan Jadwal sebagai entitas child, maka primary key pada Dosen, yaitu KdDosen akan diletakkan pada entitas Jadwal sebagai foreign key.

Gambar 4.9 Hubungan binari one-to-many antara Dosen dengan Jadwal

d. Hubungan Dosen dengan HistoryMengajarDosen Dosen sebagai entitas parent, dan HistoryMengajarDosen sebagai entitas child, maka primary key pada Dosen, yaitu KdDosen

akan

diletakkan

pada

entitas

HistoryMengajarDosen sebagai foreign key.

Gambar

4.10

Hubungan


binari

one-to-many

antara

Dosen

dengan

128

e. Hubungan Jurusan dengan Dosen Jurusan sebagai entitas parent, dan Dosen sebagai entitas child, maka primary key pada Jurusan, yaitu KdJurusan akan diletakkan pada entitas Dosen sebagai foreign key.

Gambar 4.11 Hubungan binari one-to-many antara Jurusan dengan Dosen

f. Hubungan MataKuliah dengan Jadwal MataKuliah sebagai entitas parent, dan Jadwal sebagai entitas child, maka primary key pada MataKuliah, yaitu KdMataKuliah akan diletakkan pada entitas Jadwal sebagai foreign key.

Gambar 4.12 Hubungan binari one-to-many antara MataKuliah dengan Jadwal

129

g. Hubungan MataKuliah dengan KesediaanMengajarMatkul MataKuliah

sebagai

entitas

parent,

dan

KesediaanMengajarMatkul sebagai entitas child, maka primary key pada MataKuliah, yaitu KdMataKuliah akan diletakkan pada entitas KesediaanMengajarMatkul sebagai foreign key.

Gambar

4.13

Hubungan

binari

one-to-many

antara

MataKuliah

dengan


h. Hubungan MataKuliah dengan HistoryMengajarDosen MataKuliah

sebagai


entitas sebagai

entitas

parent, child,

dan maka

primary key pada MataKuliah, yaitu KdMataKuliah akan diletakkan pada entitas Dosen sebagai foreign key.

130

Gambar

4.14

Hubungan

binari

one-to-many

antara

MataKuliah

dengan


4.

Tipe Hubungan Binari Many-to-many (*:*) Untuk setiap hubungan binari many-to-many, dibuat sebuah relasi untuk menunjukan hubungan dan memasuka atribut yang merupakan hubungan dari hubungan itu. Salinan atribut primary key dari entitas yang berpatisipasi dalam hubungan tersebut diletakkan dalam relasi yang baru sebagai foreign key. Foreign key ini juga akan menjadi primary key dalam relasi yang baru. Hubungan binari many-to-many (*:*) yang terdapat pada model data yang telah ditemukan, yaitu: a. Hubungan MataKuliah dengan Kelas Primary

key

dari

MataKuliah

dan

Kelas

yaitu:

KdMataKuliah dan KdKelas akan diletakkan pada DetailMatakuliahKelas sebagai foreign key, sekaligus primary key.

131

Gambar 4.15 Hubungan binari many-to-many antara MataKuliah dengan Kelas

5. Atribut Multi-valued Untuk setiap atribut multi-valued dalam suatu entitas, dibuat sebuah relasi baru untuk merepresentasikan atribut multi-valued dan memasukan primary key dari entitas tersebut dalam relasi yang baru sebagai foreign key. Hubungam binari atribut multi-valued yang terdapat pada model data yang telah ditemukan, yaitu: a. Hubungan Dosen dengan EmailDosen Primary Key dari Dosen, yaitu KdDosen akan diletakkan pada EmailDosen sebgai foreign key.

132

Gambar 4.16 Hubungan atribut multi-valued Dosen dengan EmailDosen

b. Hubungan Dosen dengan HPDosen Primary Key dari Dosen, yaitu KdDosen akan diletakkan pada HPDosen sebagai Foreign Key.

Gambar 4.17 Hubungan atribut multi-valued Dosen dengan HPDosen

4.1.2.3 Validasi Relasi Dengan Normalisasi Pada tahap ini akan dilakukan normalisasi untuk memvalidasikan relasi dalam model data logikal lokal. Tujuan utama dari normalisasi adalah meminimalisasi redudansi data dan mengurangi penggunaan tempat penyimpanan yang dibutuhkan untuk sebuah relasi dasar. Langkah-langkah normalisasi adalah sebagai berikut:

133

-

First Normal Form ( 1NF ) Pada bentuk normal pertama (First Normal Form – 1NF) ini, akan

diidentifikasikan

dan

dihilangkan

data

berulang

(repeating groups). -

Second Normal Form ( 2NF ) Pada bentuk normal kedua (Second Normal Form – 2NF) ini, akan dihilangkan partial dependency pada primary key.

-

Third Normal Form ( 3NF ) Pada bentuk normal ketiga (Third Normal Form – 3NF) ini, akan dihilangkan transitive dependency pada primary key. Langkah-langkah normalisasi yang dilakukan pada setiap

relasi dapat dilihat pada tabel berikut ini. Dosen KdDosen KdJurusan

fd1 (Primary Key) fd2 (Transitive Dependency) fd3 (Transitive Dependency)

Username

fd4 (Transitive Dependency)

KdJabatan NamaDosen AlamatDosen TeleponRumah LineTelepon SKSMengajar Status

1NF Dosen = @KdDosen + #KdJurusan + #Username + NamaJabatan + NamaDosen + AlamatDosen + TeleponRumah + LineTelepon + SKSMengajar + Status

134

Dalam relasi Dosen sudah tidak terdapat repeating group sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi Dosen sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF Dosen = @KdDosen + #KdJurusan + #Username + #KdJabatan + NamaDosen + AlamatDosen + TeleponRumah + LineTelepon + SKSMengajar + Status Jurusan = @KdJurusan + #Kdfakultas + NamaJurusan Fakultas = @KdFakultas + NamaFakultas User = @Username + Password + #KdJenisUser JenisUser = @KdJenisUser + JenisUser Jabatan = @KdJabatan + NamaJabatan

HPDosen

1NF HPDosen = @HPDosen + #KdDosen Dalam relasi HPDosen sudah tidak terdapat repeating groups sehingga relasi sudah berada dalam kondisi 1NF.

135

2NF Dalam relasi HPDosen sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF HPDosen = @HPDosen + #KdDosen Dalam relasi HPDosen sudah tidak terdapat ketergantungan transitif sehingga relasi sudah berada dalam kondisi 3NF.

EmailDosen

1NF EmailDosen = @EmailDosen + #KdDosen Dalam relasi EmailDosen sudah tidak terdapat repeating groups sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi EmailDosen sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF EmailDosen = @EmailDosen + #KdDosen Dalam relasi EmailDosen sudah tidak terdapat ketergantungan transitif sehingga relasi sudah berada dalam kondisi 3NF.

136


1NF KesediaanMengajarMatkul = @KdKesediaanMengajarMatkul + #KdDosen + #KdMataKuliah +

Periode + Semester +

SemesterBerjalan Dalam relasi KesediaanMengajarMatkul sudah tidak terdapat repeating group sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi KesediaanMengajarMatkul sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF KesediaanMengajarMatkul = @KdKesediaanMengajarMatkul + #KdDosen + #KdMataKuliah + #KdPeriode MataKuliah = @KdMataKuliah

+

#KdKelompok

+

NamaMataKuliah

+

SKSTeori + SKSPraktikum KelompokMatkul = @KdKelompok + NamaKelompok + PenanggungJawab Periode = @KdPeriode + Periode +Semester + SemesterBerjalan

137

KesediaanMengajarJadwal

1NF KesediaanMengajarJadwal = @KdKesediaanMengajarJadwal + #KdDosen

+

Hari

+

Shift

+

Periode

+

Semester

+

SemesterBerjalan Dalam relasi KesediaanMengajarJadwal sudah tidak terdapat repeating group sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi KesediaanMengajarJadwal sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF KesediaanMengajarJadwal = @KdKesediaanMengajarJadwal + #KdDosen + #KdPeriode + Hari + Shift Periode = @KdPeriode + Periode + Semester Dalam relasi KesediaanMengajarJadwal sudah tidak terdapat ketergantungan transitif sehingga relasi sudah berada dalam kondisi 3NF.

138

Pemberitahuan

1NF Pemberitahuan

=

@KdPemberitahuan

+

#Username

+

JenisPemberitahuan + Pemberitahuan + TanggalPemberitahuan + Status Dalam relasi Pemberitahuan sudah tidak terdapat repeating group sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi Pemberitahuan sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF Pemberitahuan

=

@KdPemberitahuan

#KdJenisPemberitahuan

+

#KdStatus

+

+

#Username

+

Pemberitahuan

+

TanggalPemberitahuan JenisPemberitahuan

=

JenisPemberitahuan Status = @KdStatus + Status

@KdJenisPemberitahuan

+

139


1NF HistoryMengajarDosen

= @KdHistory + #KdDosen +

#KdMataKuliah + Periode + Semester +

SemesterBerjalan +

JumlahSKSMengajar Dalam relasi


sudah

tidak

terdapat

repeating groups sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi


sudah

tidak

terdapat

ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF HistoryMengajarDosen

= @KdHistory + #KdDosen +

#KdPeriode + #KdMataKuliah + JumlahSKSMengajar Periode = @KdPeriode + Periode + Semester + SemesterBerjalan

140

Kelas

1NF Kelas = @KdKelas + #KdJurusan + JumlahMahasiswa Dalam relasi Kelas sudah tidak terdapat repeating groups sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi Kelas sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF Kelas = @KdKelas + #KdJurusan + JumlahMahasiswa Dalam relasi Kelas sudah tidak terdapat ketergantungan transitif sehingga relasi sudah berada dalam kondisi 3NF.

Jadwal

141

1NF Jadwal = @KdJadwal + #KdDosen + #KdMataKuliah + #KdKelas

+

Hari

+

Shift

+

Periode

+

Semester

+

SemesterBerjalan + NoRuang + Kampus Dalam relasi Jadwal sudah tidak terdapat repeating group sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi Jadwal sudah tidak terdapat ketergantungan parsial sehingga relasi sudah berada dalam kondisi 2NF. 3NF Jadwal = @KdJadwal + #KdDosen + #KdMataKuliah + #KdKelas + #KdPeriode + #NoRuang + Hari + Shift Periode = @KdPeriode + Periode + Semester Tempat = @NoRuang + #KdKampus Kampus = @KdKampus + NamaKampus

Dari hasil memvalidasi relasi dengan normalisasi tersebut, didapatkanlah Entity Relationship Diagram Lokal Logikal.

142 JenisPemberitahuan PK

Status

KdJenisPemberitahuan

PK

KdStatus

JenisUser JenisPemberitahuan

PK

Status

KdJenisUser JenisUser

KesediaanMengajarJadwal Pemberitahuan PK


FK1 FK2

KdDosen KdPeriode Shift Hari

PK

KdPemberitahuan

FK1 FK2 FK3

KdJenisPemberitahuan KdStatus Username Pemberitahuan TanggalPemberitahuan

User PK

Username

FK1

KdJenisUser Password

KesediaanMengajarMatkul PK FK1 FK2 FK3

EmailDosen


Dosen

KdDosen KdMataKuliah KdPeriode

PK

KdDosen

FK1 FK2 FK3

KdJurusan Username KdJabatan NamaDosen AlamatDosen TeleponRumah LineTelepon Status SKSMengajar

PK

EmailDosen

FK1

KdDosen Num

Jabatan PK

KdJabatan NamaJabatan

HPDosen PK

HPDosen

FK1

KdDosen Num

KelompokMatkul PK

KdKelompok NamaKelompok PenanggungJawab

Jurusan PK

KdJurusan

Periode PK

KdPeriode

FK1

Semester TahunAjaran SemesterBerjalan

KdFakultas NamaJurusan

Fakultas PK

DetailMatkulKelas

MataKuliah HistoryMengajarDosen PK FK1 FK2 FK3

PK

KdMataKuliah

FK1

KdKelompok NamaMataKuliah SKSTeori SKSPraktikum

PK,FK1 PK,FK2

KdHistory KdDosen KdMataKuliah KdPeriode JumlahSKSMengajar

KdFakultas

Kelas

NamaFakultas Jadwal

Tempat PK

NoRuang

FK1

KdKampus

PK

KdKampus

KdKelas KdMataKuliah

PK

KdJadwal

FK1 FK2 FK3 FK4 FK5

KdDosen KdMataKuliah KdKelas KdPeriode NoRuang Hari Shift

PK

KdKelas

FK1

KdJurusan JumlahMahasiswa

Kampus

NamaKampus

Gambar 4.18 Entity Relationship Diagram Lokal Logikal

4.1.2.4 Memvalidasi Relasi terhadap Transaksi Pengguna Tujuan dari langkah ini adalah memvalidasi model data logikal lokal. Hal tersebut dilakukan untuk menjamin bahwa model tersebut mendukung seluruh transaksi yang dibutuhkan oleh pengguna. Beberapa transaksi yang telah diidentifikasi dan

143

harus didukung oleh model data logikal lokal adalah sebagai berikut: a. Melakukan entry, pengubahan dan penghapusan data mata kuliah. b. Melakukan pencarian mata kuliah berdasarkan kode, nama dan kelompok mata kuliah yang didatakan. c. Melakukan entry dan pengubahan data dosen. d. Melakukan pencarian terhadap nama dan kode dosen yang didatakan. e. Melakukan entry dan memposting pemberitahuan kepada pengguna melalui e-mail. f. Melakukan pencarian history mengajar dosen berdasarkan kode dosen, nama dosen, dan mata kuliah. g. Melakukan pengisian kesediaan mengajar dan kesediaan mata kuliah yg akan diajarkan oleh dosen.. h. Mencetak report jadwal mengajar dosen. i. Melakukan entry dan pengubahan data fakultas j. Melakukan entry dan pengubahan data jurusan k. Melakukan pencarian terhadap nama dan kode fakultas yang didatakan. l. Melakukan pencarian terhadap nama dan kode jurusan yang didatakan.

144

m. Melakukan pencocokan kesediaan mengajar dan kualifikasi mengajar dosen dengan jadwal yang sudah ada. n. Melakukan entry dan meng-update data jadwal mengajar yang belum terisi dengan kesediaan mengajar dari dosen yang diisi sendiri sesuai dengan persetujuan dosen. Transaksi-transaksi tersebut telah didukung oleh model data lokal logikal yang didapatkan.

4.1.2.5 Menentukan Batasan Integritas Tujuan pada tahap ini adalah untuk menentukan kendala integritas pada tampilan sehingga dapat melindungi database dari keadaan yang tidak konsisten. Ada 5 macam batas integritas, yaitu: 1. Data yang dibutuhkan Atribut harus mempunyai nilai yang valid atau dengan kata lain, atribut tersebut tidak boleh null. Batasan ini telah diidentifikasikan dalam perancangan konseptual pada langkah 3 (Lihat Tabel Atribut untuk Tiap-Tiap Entitas atau Hubungan Antar Entitas). 2. Batasan domain atribut Setiap atribut mempunyai sebuah domain, yaitu satu set nilai yang legal. Batasan ini telah diidentifikasi dalam perancangan

145

konseptual pada langkah 4 (Lihat Tabel Domain Atribut untuk Tiap-Tiap Entitas). 3. Integritas entitas Primary key dari suatu entitas tidak boleh null. Batasan ini telah diidentifikasi dalam perancangan konseptual pada langkah 5 (Lihat Tabel Candidate Key dan Primary Key untuk Tiap-Tiap Entitas). 4. Integritas referensial Integritas referensial berarti bahwa jika sebuah foreign key memiliki sebuah nilai, maka nilai tersebut harus merujuk ke tuple yang ada pada relasi parent. Pertama-tama perlu diperhatikan apakah nilai null diijinkan dalam sebuah foreign key. Selanjutnya baru ditentukan cara menjamin adanya integritas referensial dengan menentukan kondisi suatu foreign key dimasukkan, diubah atau dihapus. Integritas referensial pada model data lokal logikal ini dapat dilihat pada tabel di bawah ini.

146

Tabel 4.25 Integritas Referensial Jenis Pemberitahuan (KdJenisPemberitahuan, JenisPemberitahuan) Primary Key (KdJenisPemberitahuan) JenisUser (KdJenisUser, JenisUser) Primary Key (KdJenisUser) Status (KdStatus, Status) Primary Key (KdStatus) KesediaanMengajarJadwal

(KdKesediaanMengajarJadwal,

KdDosen,

KdPeriode, Shift, Hari) Primary Key (KdKesediaanMengajarJadwal) Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION Pemberitahuan (KdPemberitahuan, Username, KdJenisPemberitahuan, KdStatus, Pemberitahuan, TanggalPemberitahuan) Primary Key (KdPemberitahuan) Foreign Key (Username) References User(Username) ON UPDATE CASCADE ON DELETE NO ACTION Foreign

Key

(KdJenisPemberitahuan)

References

(KdJenisPemberitahuan) ON UPDATE CASCADE ON DELETE NO ACTION

JenisPemberitahuan

147

Foreign Key (KdStatus) References Status(KdStatus) ON UPDATE CASCADE ON DELETE NO ACTION User (Username, KdJenisUser, Password) Primary Key (Username) Foreign Key (KdJenisUser) References JenisUser(KdJenisUser) ON UPDATE CASCADE ON DELETE NO ACTION Jurusan (KdJurusan, KdFakultas, NamaJurusan) Primary Key (KdJurusan) Foreign Key (KdFakultas) References Fakultas (KdFakultas) ON UPDATE CASCADE ON DELETE NO ACTION Dosen (KdDosen, KdJurusan, Username, KdJabatan, NamaDosen, AlamatDosen, TeleponRumah, LineTelepon, SKSMengajar, Status) Primary Key (KdDosen) Foreign Key (KdJurusan) References Jurusan (KdJurusan) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (Username) References User (Username) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdJabatan) References Jabatan(KdJabatan) EmailDosen (EmailDosen, KdDosen, Num) Primary Key (EmailDosen) Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION

148

HPDosen (HPDosen, KdDosen, Num) Primary Key (HPDosen) Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION Jabatan (KdJabatan, NamaJabatan) Primary Key (KdJabatan) KelompokMatkul (KdKelompok, NamaKelompok, PenanggungJawab) Primary Key (KdKelompok) Periode (KdPeriode, Semester, Semester Berjalan, TahunAjaran) Primary Key (KdPeriode) Fakultas (KdFakultas, NamaFakultas) Primary Key (KdFakultas) HistoryMengajarDosen (KdHistory, KdDosen, KdMataKuliah, KdPeriode, JumlahSksMengajar) Primary Key (KdHistory) Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdMataKuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION MataKuliah

(KdMataKuliah,

KdKelompok,

NamaMataKuliah,

SKSTeori,

149

SKSPraktikum) Primary Key (KdMataKuliah) Foreign Key (KdKelompok) References KelompokMatkul(KdKelompok) ON UPDATE CASCADE ON DELETE NO ACTION Kelas (KdKelas, KdJurusan, JumlahMahasiswa) Primary Key (KdKelas) Foreign Key (KdJurusan) References Jurusan(KdJurusan) ON UPDATE CASCADE ON DELETE NO ACTION DetailMatkulKelas (KdKelas, KdMataKuliah) Primary Key (KdKelas, KdMataKuliah) Foreign Key (KdMataKuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdKelas), References Kelas(KdKelas) ON UPDATE CASCADE ON DELETE NO ACTION Tempat (NoRuang, KdKampus, Ruang) Primary Key (NoRuang) Foreign Key (KdKampus) References Kampus(KdKampus) ON UPDATE CASCADE ON DELETE NO ACTION Jadwal (KdJadwal, KdTempat, KdDosen, KdMataKuliah, KdKelas, KdPeriode, Hari, Shift) Primary Key (KdJadwal) Foreign Key (KdTempat) References Tempat(KdTempat)

150

ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdMatakuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdKelas), References Kelas(KdKelas) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION Kampus (KdKampus, NamaKampus) Primary Key (KdKampus)

4.1.3 Perancangan Database Fisikal Perancangan database fisikal adalah proses pembuatan deskripsi dari implementasi database pada tempat penyimpanan kedua (secondary storage). Proses ini mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan untuk memperoleh akses yang efisien terhadap data dan batasan integritas yang berhubungan serta ukuran keamanan lainnya. Tahapan perancangan database fisikal mengijinkan perancang untuk

membuat

keputusan

atas

bagaimana

database

akan

diimplementasikan. Oleh karena itu desain fisikal dihubungkan pada DBMS yang spesifik.

151

Langkah-langkah dalam perancangan database fisikal adalah sebagai berikut: 4.1.3.1 Menerjemahkan Model Data Logikal Global Sesuai Dengan DBMS Yang Digunakan Langkah ini bertujuan untuk menghasilkan skema basis data relasional

dari

model

data

logikal

global

yang

dapat

diimplementasikan ke dalam DBMS yang akan digunakan. Langkah ini terdiri dari 3 aktivitas, yaitu: 4.1.3.1.1 Merancang Base Relation (Relasi Dasar) Tujuan dari aktivitas ini adalah untuk menentukan bagaimana

merepresentasikan

relasi

dasar

yang

diidentifikasi pada model data logikal global dalam DBMS yang digunakan. Untuk merepresentasikan desain dari relasi dasar ini, digunakan bentuk perluasan dari Database Definition Language (DDL) untuk menentukan domain, default value, dan indikator null. 1. Dosen Domain KdDosen

: fixed length character string, length 5 Format : [D][0-9][0-9][0-9][0-9]

Domain KdJurusan

: fixed length character string, length 5

152

Domain Username


Domain NamaDosen

: variable length character string, length 100

Domain AlamatDosen


Domain TeleponRumah


Domain Line-Telepon


Domain SKSMengajar

: integer

Domain Status


Dosen (

KdDosen

NOT NULL,

KdJurusan

NOT NULL,

Username

NOT NULL,

NamaDosen

NOT NULL,

AlamatDosen

NOT NULL,

TeleponRumah

NOT NULL,

LineTelepon

NULL,

SKSMengajar

NOT NULL,

153

Status

NOT NULL,

Primary Key (KdDosen), Foreign Key (KdJurusan) References Jurusan(KdJurusan) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (Username) References User(Username) ON UPDATE CASCADE ON DELETE CASCADE, Foreign Key (KdJabatan) References Jabatan(KdJabatan) ON UPDATE CASCADE ON DELETE NO ACTION, );

2. User Domain Username


Domain Password


KdJenisUser

: fixed length character string, length 5, Format : [J][U][0-9][0-9][0-9]

User ( Username

NOT NULL,

Password

NOT NULL,

KdJenisUser

NOT NULL,

Primary Key (Username),

154

Foreign Key (KdJenisUser) References JenisUser(KdJenisUser) ON UPDATE CASCADE ON DELETE NO ACTION );

3. EmailDosen Domain EmailDosen


Domain KdDosen

: fixed length character string, length 5, Format : [D][0-9][0-9][0-9][0-9]

EmailDosen ( EmailDosen

NOT NULL,

KdDosen

NOT NULL,

Num

NOT NULL,

Primary Key (EmailDosen), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION );

4. HPDosen Domain HPDosen


Domain KdDosen

: fixed length character string,

155

length 50, Format : [D][0-9][0-9][0-9][0-9] HPDosen ( HPDosen

NOT NULL,

KdDosen

NOT NULL,

Num

NOT NULL,

Primary Key (HPDosen), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION );

5. Jabatan Domain KdJabatan


Domain NamaJabatan

: variable length character string, length 100, Format : [JA] [0-9][0-9][0-9]

Jabatan ( KdJabatan

NOT NULL,

NamaJabatan

NOT NULL,

Primary Key (KdJabatan) );

156

6. Fakultas Domain KdFakultas


Domain NamaFakultas

: variable length character string, length 100,

Fakultas ( KdFakultas

NOT NULL,

NamaFakultas

NOT NULL,

Primary Key (KdFakultas) );

7. Jurusan Domain KdJurusan


Domain KdFakultas


Domain NamaJurusan


Jurusan ( KdJurusan

NOT NULL,

KdFakultas

NOT NULL,

NamaJurusan

NOT NULL,

Primary Key (KdJurusan),

157

Foreign Key (KdFakultas) References Fakultas(KdFakultas) ON UPDATE CASCADE ON DELETE NO ACTION );

8. Kampus Domain KdKampus


Domain NamaKampus


Kampus ( KdKampus

NOT NULL,

NamaKampus

NOT NULL,

Primary Key (KdKampus) );

9. Tempat Domain NoRuang


Domain KdKampus


Tempat (

NoRuang

NOT NULL,

KdKampus

NOT NULL,

158

Primary Key (NoRuang), Foreign Key (KdKampus) References Kampus(KdKampus) ON UPDATE CASCADE ON DELETE NO ACTION );

10. Kelas Domain KdKelas


Domain KdJurusan

: fixed length character string, length 5,

Domain JumlahMahasiswa

: integer

Kelas ( KdKelas

NOT NULL,

KdJurusan

NOT NULL,

JumlahMahasiswa

NOT NULL,

Primary Key (KdKelas) Foreign Key (KdJurusan) References Jurusan(KdJurusan) ON UPDATE CASCADE ON DELETE NO ACTION );

11. Periode Domain KdPeriode


159

Domain Periode


Domain Semester


Domain Semester Berjalan

: integer

Periode ( KdPeriode

NOT NULL,

Periode

NOT NULL,

Semester

NOT NULL,

Semester Berjalan

NOT NULL,

Primary Key (KdKelas) );

12. MataKuliah Domain KdMataKuliah


Domain KdKelompok


Domain NamaMataKuliah


Domain SKSTeori

: integer

Domain SKSPraktikum

: integer

MataKuliah (

160

KdMataKuliah

NOT NULL,

KdKelompok

NOT NULL,

NamaMataKuliah

NOT NULL,

SKSTeori

NOT NULL,

SKSPraktikum

NOT NULL,

Primary Key (KdMataKuliah), Foreign Key (KdKelompok) References KelompokMatkul(KdKelompok) ON UPDATE CASCADE ON DELETE NO ACTION );

13. JenisUser Domain KdJenisUser


Domain JenisUser


JenisUser ( KdJenisUser

NOT NULL,

JenisUser

NOT NULL,

Primary Key (KdJenisUser) );

14. KelompokMatkul Domain KdKelompok

: fixed length character string,

161

length 5 Domain NamaKelompok


Domain PenanggungJawab


KelompokMatkul ( KdKelompok

NOT NULL,

NamaKelompok

NOT NULL,

PenanggungJawab

NOT NULL,

Primary Key (KdKelompok) );

15. JenisPemberitahuan Domain KdJenisPemberitahuan


Domain JenisPemberitahuan


JenisPemberitahuan ( KdJenisPemberitahuan

NOT NULL,

JenisPemberitahuan

NOT NULL,

Primary Key (KdKelompok) );

162

16. Status Domain KdStatus


Domain Status


Kelas ( KdStatus

NOT NULL,

Status

NOT NULL,

Primary Key (KdStatus) );

17. KesediaanMengajarJadwal Domain KdKesediaanMengajarJadwal : integer Domain KdDosen


Domain KdPeriode


Domain Hari

: integer

Domain Shift

: integer

DetailKesediaanMengajarJadwal (


NOT NULL,

KdDosen

NOT NULL,

163

KdPeriode

NOT NULL,

Hari

NOT NULL,

Shift

NOT NULL,

Primary Key (KdKesediaanMengajarJadwal), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE UPDATE CASCADE Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE UPDATE CASCADE );

18. KesediaanMengajarMatkul Domain KdKesediaanMengajarMatkul : integer Domain KdDosen


Domain KdMataKuliah


Domain KdPeriode


KesediaanMengajarMatkul (


NOT NULL,

KdDosen

NOT NULL,

164

KdMataKuliah

NOT NULL,

KdPeriode

NOT NULL,

Primary Key (KdKesediaanMengajar), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdMataKuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION );

19. Pemberitahuan Domain KdPemberitahuan

: integer

Domain KdDosen


Domain KdJenisPemberitahuan


Domain KdPemberitahuan


Domain Pemberitahuan


Domain TanggalPemberitahuan Pemberitahuan (

: datetime

165

KdPemberitahuan

NOT NULL,

KdDosen

NOT NULL,


NOT NULL,

KdStatus

NOT NULL,

Pemberitahuan

NOT NULL,

TanggalPemberitahuan

NOT NULL,

Primary Key (KdPemberitahuan), Foreign Key (Username) References User(Username) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign

Key

(KdJenisPemberitahuan)

References

JenisPemberitahuan(KdJenisPemberitahuan) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdStatus) References Status(KdStatus) ON UPDATE CASCADE ON DELETE NO ACTION );

20. DetailMatkulKelas Domain KdMataKuliah


Domain KdKelas


DetailMatkulKelas( KdMataKuliah

NOT NULL,

166

KdKelas

NOT NULL,

Primary Key (KdMataKuliah, KdKelas), Foreign Key (KdMatakuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdKelas) References Kelas(KdKelas) ON UPDATE CASCADE ON DELETE NO ACTION );

21. Jadwal Domain KdJadwal

: integer

Domain KdDosen


Domain KdMataKuliah


Domain KdKelas


Domain NoRuang


Domain KdPeriode


Domain Hari


Domain Shift

: integer

167

Jadwal ( KdJadwal

NOT NULL,

KdDosen

NOT NULL,

KdMataKuliah

NOT NULL,

KdKelas

NOT NULL,

NoRuang

NOT NULL,

KdPeriode

NOT NULL,

Hari

NOT NULL,

Shift

NOT NULL,

Primary Key (KdJadwal), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdMataKuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdKelas) References Kelas(KdKelas) ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key (NoRuang) References Tempat(NoRuang) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION, );

168

22. HistoryMengajarDosen Domain KdHistory

: integer

Domain KdDosen


Domain KdMataKuliah


Domain KdPeriode


Domain JumlahSKSMengajar

: integer

HistoryMengajarDosen ( KdHistory

NOT NULL,

KdDosen

NOT NULL,

KdMataKuliah

NOT NULL,

KdPeriode

NOT NULL,

JumlahSKSMengajar

NOT NULL,

Primary Key (KdHistory), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdMataKuliah) References MataKuliah(KdMataKuliah) ON UPDATE CASCADE ON DELETE NO ACTION, Foreign Key (KdPeriode) References Periode(KdPeriode) ON UPDATE CASCADE ON DELETE NO ACTION, );

169

4.1.3.1.2 Merancang Representasi Dari Data Turunan Langkah

ini

dilakukan

untuk

menentukan

bagaimana merepresentasikan data turunan yang ada pada model data logikal global dalam DBMS yang akan digunakan. Dalam model data logikal yang ada tidak terdapat data turunan.

4.1.3.1.3 Merancang Batasan Perusahaan Tujuan dari langkah ini adalah untuk merancang batasan perusahaan pada DBMS yang akan digunakan. a. Format KdJenisUser harus sesuai dengan ketentuan ‘JUXXX’. CONSTRAINT cekKdJenisUser CHECK (KdJenisUser like 'JU[0-9][0-9][0-9]') b.

Format KdStatus harus sesuai dengan ketentuan ‘STXXX’. CONSTRAINT cekKdStatus CHECK (KdStatus like 'ST[0-9][0-9][0-9]')

c.

Format KdJabatan harus sesuai dengan ketentuan ‘JAXXX’. CONSTRAINT cekKdJabatan CHECK (KdJabatan like 'JA[0-9][0-9][0-9]')

170

d.

Format KdKelompok harus sesuai dengan ketentuan ‘KMXXX’. CONSTRAINT cekKdKelompok CHECK (KdKelompok like 'KM[0-9][0-9][0-9]')

e.

Panjang string KdKelas harus lima kakakter. CONSTRAINT cekKdKelas CHECK (len(KdKelas)=5)

f.

Format KdKampus harus sesuai dengan ketentuan ‘KPXXX’. CONSTRAINT cekKdKampus CHECK (KdKampus like 'KP[0-9][0-9][0-9]')

g.

Format KdFakultas harus sesuai dengan ketentuan ‘FKXXX’. CONSTRAINT cekKdFakultas CHECK (KdFakultas like 'FK[0-9][0-9][0-9]')

h.

Format KdJurusan harus sesuai dengan ketentuan ‘JSXXX’. CONSTRAINT cekKdJurusan CHECK (KdJurusan like 'JS[0-9][0-9][0-9]')

i.

Format KdDosen harus sesuai dengan ketentuan ‘DXXXX’. CONSTRAINT cekKdDosen CHECK (KdDosen like 'D[0-9][0-9][0-9][0-9]')

171

j.

Format KdJenisPemberitahuan harus sesuai dengan ketentuan ‘KJXXX’. CONSTRAINT cekKdJenisPemberitahuan CHECK (KdJenisPemberitahuan like 'KJ[0-9] [0-9][0-9]')

4.1.3.2 Merancang Representasi Fisikal Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks-indeks yang dibutuhkan untuk mencapai performa yang diharapkan, dengan cara sebagaimana relasi dan tuple disimpan dalam tempat penyimpanan kedua. Langkah ini terbagi menjadi 4 aktivitas, yaitu: 4.1.3.2.1

Menganalisis Transaksi Analisis

transaksi

bertujuan

untuk

memahami

fungsionalitas transaksi yang akan berjalan pada database dan juga untuk menganalisa transaksi-transaksi yang penting. Untuk

mempermudah

tersebut

digunakan

menganalisis

transaksi-transaksi

transaction/relation

cross-reference

matrix (matriks referensi silang transaksi/relasi). Transaksi yang dianalisis adalah sebagai berikut : a. Melakukan entry, pengubahan dan penghapusan data mata kuliah.

172

b. Melakukan pencarian mata kuliah berdasarkan kode, nama, dan kelompok mata kuliah yang didatakan. c. Melakukan entry dan pengubahan data dosen. d. Melakukan pencarian terhadap nama dan kode dosen yang didatakan. e. Melakukan entry dan memposting pemberitahuan kepada pengguna melalui e-mail. f. Melakukan pencarian history mengajar dosen berdasarkan kode dosen, nama dosen, dan mata kuliah. g. Melakukan pengisian kesediaan mengajar dan kesediaan mata kuliah yg diajar oleh dosen. h. Mencetak report jadwal mengajar dosen. i. Melakukan entry dan pengubahan data fakultas j. Melakukan entry dan pengubahan data jurusan k. Melakukan pencarian terhadap nama dan kode fakultas yang didatakan. l. Melakukan pencarian terhadap nama dan kode jurusan yang didatakan. m. Melakukan

pencocokan

kesediaan

mengajar

dan

kualifikasi mengajar dosen dengan jadwal yang sudah ada. n. Melakukan entry dan meng-update data jadwal mengajar yang belum terisi dengan kesediaan mengajar dari dosen yang diisi sendiri sesuai dengan persetujuan dosen.

173

Untuk mempermudah menganalisis transaksi-transaksi tersebut digunakan matriks referensi silang transaksi/relasi. Matriks referensi silang transaksi/relasi dapat dilihat pada Matriks Referensi Silang Transaksi/Relasi di bawah ini.

Matriks Referensi Silang Transaksi/Relasi Tabel 4.26 Analisis Transaksi I Transaksi (a)

Relasi

I

(b)

(c)

R U D I R U D I R U D I R U D

Dosen

X X X

X

X

X

EmailDosen

X X X

X

HPDosen

X X X

X

Jabatan

X

X

Fakultas

X

X

Jurusan

X

X

User

Kampus Tempat Kelas Periode MataKuliah

(d)

X X X X

X

174

JenisUser KelompokMatkul

X

X

JenisPemberitahuan Status KesediaanMengajarJadwal KesediaanMengajarMatkul pemberitahuan DetailMatkulKelas Jadwal HistoryMengajarDosen

Tabel 4.27 Analisis Transaksi II Transaksi (e)

Relasi

(g)

(h)

R U D I R U D I R U D I R U D

Dosen

X

X

X

X

User

X

X

X

X

EmailDosen

X

HPDosen Jabatan

I

(f)

175

Fakultas Jurusan Kampus

X

Tempat

X

Kelas

X

Periode

X

MataKuliah

X

X

X

JenisUser KelompokMatkul JenisPemberitahuan

X

Status

X

KesediaanMengajar-

X

Jadwal KesediaanMengajar-

X

Matkul Pemberitahuan

X

DetailMatkulKelas Jadwal HistoryMengajarDosen

X X

176

Tabel 4.28 Analisis Transaksi III Transaksi (i)

Relasi

I

(j)

R U D I

(k)

(l)

R U D I R U D I

R U D

X

X

Dosen User EmailDosen HPDosen Jabatan Fakultas Jurusan Kampus Tempat Kelas Periode MataKuliah JenisUser KelompokMatkul JenisPemberitahuan Status KesediaanMengajar Jadwal

X X X X

X X X X

X

X

177

KesediaanMengajar Matkul Pemberitahuan DetailMatkulKelas Jadwal HistoryMengajarDosen

Tabel 4.29 Analisis Transaksi IV Transaksi (m)

Relasi Dosen

I

(n)

R U D I R U D X

X

Kampus

X

X

Tempat

X

X

Kelas

X

X

Periode

X

X

User EmailDosen HPDosen Jabatan Fakultas Jurusan

178

MataKuliah

X

X

X

X

X

X

X

X

X X

X X

JenisUser KelompokMatkul JenisPemberitahuan Status KesediaanMengajarJadwal KesediaanMengajarMatkul Pemberitahuan DetailMatkulKelas Jadwal HistoryMengajarDosen Keterangan : I = Insert; R = Read; U = Update; D = Delete

4.1.3.2.2

Memilih Organisasi File Aktivitas ini bertujuan untuk menentukan organisasi file agar dapat menyimpan data secara efisien. DBMS yang digunakan dalam aplikasi ini adalah MySQL. Oleh karena itu, organisasi file yang digunakan disesuaikan dengan organisasi file yang digunakan DBMS tersebut.

179

4.1.3.2.3

Memilih Indeks Tujuan dari aktivitas ini adalah menentukan apakah penambahan indeks akan meningkatkan performa dari sistem. Dalam perancangan aplikasi ini, tidak dipertimbangkan untuk menggunakan indeks karena jumlah data dari tiap-tiap tabel tidak terlalu besar.

4.1.3.2.4 Memperkirakan Kebutuhan Media Penyimpanan Tujuan dari aktivitas ini adalah memperkirakan kapasitas penyimpanan yang akan dibutuhkan oleh basis data. Perkiraan kapasitas penyimpanan untuk setiap tabel dapat dilihat di Estimasi Kapasitas untuk Setiap Tabel.

Estimasi Kapasitas untuk Setiap Tabel Tabel 4.30 Estimasi Kapasitas Dosen Fields

Tipe data

Ukuran

KdDosen

Char

5

KdJurusan

Char

5

Username

Char

5

KdJabatan

Char

5

NamaDosen

Varchar

50

AlamatDosen

Varchar

100

180

TeleponRumah

Varchar

20

LineTelepon

Varchar

10

SKSMengajar

Int

4

Status

Varchar

10

Kapasitas 1 record dari tabel Dosen adalah 214 byte. Diperkirakan jumlah record awal adalah 200, dan dalam 1 tahun terjadi penambahan 20 record. Dalam satu tahun kebutuhan tabel ini adalah 220*214 = 47080 byte.

Tabel 4.31 Estimasi Kapasitas User Fields

Tipe data

Ukuran

Username

Char

5

KdJenisUser

Char

5

Password

Varchar

50

Kapasitas 1 record dari tabel User adalah 60 byte. Diperkirakan jumlah record awal adalah 200, dan dalam 1 tahun terjadi penambahan 20 record. Dalam satu tahun kebutuhan tabel ini adalah 220*60 = 13200 byte.

181

Tabel 4.32 Estimasi Kapasitas EmailDosen Fields

Tipe data

Ukuran

EmailDosen

Varchar

30

KdDosen

Char

5

Kapasitas 1 record dari tabel EmailDosen adalah 35 byte. Diperkirakan jumlah record awal adalah 600, dan dalam 1 tahun terjadi penambahan 60 record. Dalam satu tahun kebutuhan tabel ini adalah 660*35 = 23100 byte.

Tabel 4.33 Estimasi Kapasitas HPDosen Fields

Tipe data

Ukuran

HPDosen

Varchar

20

KdDosen

Char

5

Kapasitas 1 record dari tabel HPDosen adalah 25 byte. Diperkirakan jumlah record awal adalah 400, dan dalam 1 tahun terjadi penambahan 40 record. Dalam satu tahun kebutuhan tabel ini adalah 440*25 = 11000 byte.

Tabel 4.34 Estimasi Kapasitas Jabatan Fields

Tipe data

Ukuran

KdJabatan

Char

5

NamaJabatan

Varchar

100

182

Kapasitas 1 record dari tabel Jabatan adalah 105 byte. Diperkirakan jumlah record awal adalah 6, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 6*105 = 630 byte.

Tabel 4.35 Estimasi Kapasitas Fakultas Fields

Tipe data

Ukuran

KdFakultas

Char

5

NamaFakultas

Varchar

100

Kapasitas 1 record dari tabel Fakultas adalah 105 byte. Diperkirakan jumlah record awal adalah 10, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 10*105 = 1050 byte.

Tabel 4.36 Estimasi Kapasitas Jurusan Fields

Tipe data

Ukuran

KdJurusan

Char

5

NamaJurusan

Varchar

100

Kapasitas 1 record dari tabel Jurusan adalah 105 byte. Diperkirakan jumlah record awal adalah 20, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 20*105 = 2100 byte.

183

Tabel 4.37 Estimasi Kapasitas Kampus Fields

Tipe data

Ukuran

KdKampus

Char

5

NamaKampus

Varchar

50

Kapasitas 1 record dari tabel Kampus adalah 55 byte. Diperkirakan jumlah record awal adalah 3, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 3*55 = 165 byte.

Tabel 4.38 Estimasi Kapasitas Tempat Fields

Tipe data

Ukuran

NoRuang

Varchar

10

KdKampus

Char

5

Kapasitas 1 record dari tabel Tempat adalah 15 byte. Diperkirakan jumlah record awal adalah 200, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 200*15 = 3000 byte.

Tabel 4.39 Estimasi Kapasitas Kelas Fields

Tipe data

Ukuran

KdKelas

Char

5

KdJurusan

Char

5

184

JumlahMahasiswa

Integer

4

Kapasitas 1 record dari tabel Kelas adalah 14 byte. Diperkirakan jumlah record awal adalah 200, dan dalam 1 tahun terjadi penambahan 20 record. Dalam satu tahun kebutuhan tabel ini adalah 220*14 = 3080 byte.

Tabel 4.40 Estimasi Kapasitas Periode Fields

Tipe data

Ukuran

KdPeriode

Char

5

Periode

Varchar

20

Semester

Varchar

20

SemesterBerjalan

Integer

4

Kapasitas 1 record dari tabel Periode adalah 49 byte. Diperkirakan jumlah record awal adalah 15, dan dalam 1 tahun terjadi penambahan 3 record. Dalam satu tahun kebutuhan tabel ini adalah 18*49 = 882 byte.

Tabel 4.41 Estimasi Kapasitas MataKuliah Fields

Tipe data

Ukuran

KdMataKuliah

Char

5

KdKelompok

Char

5

NamaMataKuliah

Varchar

50

185

SKSTeori

Integer

4

SKSPraktikum

Integer

4

Kapasitas 1 record dari tabel MataKuliah adalah 68 byte. Diperkirakan jumlah record awal adalah 300, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 300*68 = 17400 byte.

Tabel 4.42 Estimasi Kapasitas JenisUser Fields

Tipe data

Ukuran

KdJenisUser

Char

5

JenisUser

Varchar

10

Kapasitas 1 record dari tabel JenisUser adalah 15 byte. Diperkirakan jumlah record awal adalah 2, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 2*15 = 30 byte.

Tabel 4.43 Estimasi Kapasitas KelompokMatkul Fields

Tipe data

Ukuran

KdKelompok

Char

5

NamaKelompok

Varchar

20

PenanggungJawab

Varchar

50

186

Kapasitas 1 record dari tabel KelompokMatkul adalah 75 byte. Diperkirakan jumlah record awal adalah 50, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 50*75 = 3750 byte.

Tabel 4.44 Estimasi Kapasitas Status Fields

Tipe data

Ukuran

KdStatus

Char

5

Status

Varchar

20

Kapasitas 1 record dari tabel Status adalah 25 byte. Diperkirakan jumlah record awal adalah 2, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 2*25 = 50 byte.

Tabel 4.45 Estimasi Kapasitas KesediaanMengajarJadwal Fields

Ukuran

KdKesediaanMengajarJadwal Integer

4

KdDosen

Char

5

KdPeriode

Char

5

Hari

Integer

4

Shift

Integer

4

Kapasitas

Tipe data

1

record

dari

tabel


187

adalah 22 byte. Diperkirakan jumlah record awal adalah 2000, dan dalam 1 tahun terjadi penambahan 500 record. Dalam satu tahun kebutuhan tabel ini adalah 2500*22 = 55000 byte.

Tabel 4.46 Estimasi Kapasitas KesediaanMengajarMatkul Fields

Tipe data

Ukuran

KdKesediaanMengajarMatkul Integer

4

KdDosen

Char

5

KdMataKuliah

Char

5

KdPeriode

Char

5

tabel


Kapasitas

1

record

dari


Tabel 4.47 Estimasi Kapasitas DetailMatkulKelas Fields KdMataKuliah

Tipe data Char

Ukuran 5

188

KdKelas

Char

5

Kapasitas 1 record dari tabel DetailMatkulKelas adalah 10 byte. Diperkirakan jumlah record awal adalah 500, dan dalam 1 tahun terjadi penambahan 50 record. Dalam satu tahun kebutuhan tabel ini adalah 550*10 = 5500 byte.

Tabel 4.48 Estimasi Kapasitas Jadwal Fields

Tipe data

Ukuran

KdJadwal

Char

5

KdDosen

Char

5

KdMataKuliah

Char

5

KdKelas

Char

5

KdPeriode

Char

5

NoRuang

Varchar

10

Hari

Integer

4

Shift

Integer

4

Kapasitas 1 record dari tabel Jadwal adalah 43 byte. Diperkirakan jumlah record awal adalah 2000, dan dalam 1 tahun terjadi penambahan 500 record. Dalam satu tahun kebutuhan tabel ini adalah 2500*43 = 107500 byte.

189

Tabel 4.49 Estimasi Kapasitas HistoryMengajarDosen Fields

Tipe data

Ukuran

KdHistory

Char

5

KdDosen

Char

5

KdMataKuliah

Char

5

KdPeriode

Char

5

JumlahSKSMengajar

Integer

4

Kapasitas

1

record

dari

tabel



Tabel 4.50 Estimasi Kapasitas Pemberitahuan Fields

Tipe data

Ukuran

KdPemberitahuan

Integer

4


Char

5

KdStatus

Char

5

Username

Char

5

Pemberitahuan

Varchar

500

TanggalPemberitahuan

Datetime

8

190

Kapasitas 1 record dari tabel Pemberitahuan adalah 527 byte. Diperkirakan jumlah record awal adalah 1000, dan dalam 1 tahun terjadi penambahan 200 record. Dalam satu tahun kebutuhan tabel ini adalah 1200*527 = 632400 byte.

Tabel 4.51 Estimasi Kapasitas JenisPemberitahuan Fields

Tipe data

Ukuran


Char

5

JenisPemberitahuan

Char

50

Kapasitas 1 record dari tabel JenisPemberitahuan adalah 55 byte. Diperkirakan jumlah record awal adalah 10, dan dalam 1 tahun tidak terjadi penambahan. Dalam satu tahun kebutuhan tabel ini adalah 10*55 = 550 byte. Dari perkiraan kapasitas penyimpanan untuk setiap tabel, didapatkan perkiraan kebutuhan media penyimpanan secara keseluruhan. Tabel perkiraan kebutuhan media penyimpanan keseluruhan dapat dilihat di Tabel Estimasi Kebutuhan Media Penyimpanan.

191

Tabel 4.52 Estimasi Kebutuhan Media Penyimpanan Kapasitas No

Tabel

dibutuhkan tahun (byte)

1.

Dosen

47080

2.

User

13200

3.

EmailDosen

23100

4.

HPDosen

11000

5.

Jabatan

630

6.

Fakultas

1050

7.

Jurusan

2100

8.

Kampus

165

9.

Tempat

3000

10.

Kelas

3080

11.

Periode

882

12.

MataKuliah

17400

13.

JenisUser

30

14.

KelompokMatkul

3750

15.

Status

50

16.


55000

17.


26600

18.

DetailMatkulKelas

5500

yang dalam

satu

192

19.

Jadwal

107500

20.


28800

21.

Pemberitahuan

632400

22.

JenisPemberitahuan

550

Total kapasitas yang dibutuhkan untuk 1 tahun adalah: 899487 byte = 899,49 Kbyte = 0,899 Mbyte. Dari perincian perkiraan tersebut didapatkan informasi bahwa kebutuhan kapasitas penyimpanan dalam basis data untuk tahun pertama adalah 0,899 Mbyte. Hasil perkiraan ini termasuk dalam nilai jangkauan yang kecil, sehingga perkiraan kapasitas untuk tahun selanjutnya tidak terlalu dibutuhkan.

4.1.3.3 Merancang Mekanisme Keamanan Sebuah database merepresentasikan sumber daya yang penting bagi perusahaan. Oleh karena itu, keamanan dari sumber daya ini merupakan hal yang harus diutamakan. Ada dua tipe keamanan database, yaitu keamanan sistem dan keamanan data. Keamanan sistem mengatur pengaksesan dan penggunaan database pada tingkatan sistem. Setiap pengguna harus mengisi username dan password sebelum masuk ke halaman utama dari aplikasi ini. Dengan demikian, pengguna yang tidak berkepentingan atau tidak memiliki password tidak dapat masuk dan mengakses isi database.

193

Tipe keamanan yang terakhir adalah keamanan data, yang mengatur pengaksesan dan penggunaan objek-objek basis data (seperti relasi dan view) serta aksi yang dapat lakukan terhadap objek-objek basis data itu, misalnya aksi pemilihan, pengisian, pengubahan dan penghapusan data. Untuk membatasi hak akses pengguna terhadap relasi yang ada maka ditentukan hak akses untuk setiap pengguna, yang direpresentasikan dalam matriks referensi silang antara pengguna dengan relasi. Matriks referensi silang ini dapat dilihat di Matriks Referensi Silang Antara pengguna dengan Relasi.

Tabel 4.53 Matriks Referensi Silang Antara User dengan Relasi Pengguna Dosen

Relasi

I

Admin

R U D I

R U D

Dosen

X X

X X X X

User

X

X X X X

EmailDosen

X X X

X X X X

HPDosen

X X X

X X X X

Jabatan

X

X X X X

Fakultas

X

X X X X

Jurusan

X

X X X X

194

Kampus

X

X X X X

Tempat

X

X X X X

Kelas

X

X X X X

Periode

X

X X X X

MataKuliah

X

X X X X

JenisUser

X

X X X X

KelompokMatkul

X

X X X X

JenisPemberitahuan

X

X X X X

Status

X

X X X X


X X X X X X X X

KesediaanMengajarMatkul X X X X X X X X Pemberitahuan

X X

X X X X

DetailMatkulKelas

X

X X X X

Jadwal

X X

X X X X


X

X X X X

Sedangkan untuk perancangan mekanisme keamanannya adalah sebagai berikut: Authorization user Dosen: GRANT SELECT, UPDATE ON Dosen TO Dosen GRANT SELECT ON User TO Dosen GRANT SELECT, UPDATE ON EmailDosen TO Dosen

195

GRANT SELECT, UPDATE ON HPDosen TO Dosen GRANT SELECT ON Jabatan TO Dosen GRANT SELECT ON Fakultas TO Dosen GRANT SELECT ON Jurusan TO Dosen GRANT SELECT ON Kampus TO Dosen GRANT SELECT ON Tempat TO Dosen GRANT SELECT ON Kelas TO Dosen GRANT SELECT ON Periode TO Dosen GRANT SELECT ON MataKuliah TO Dosen GRANT SELECT ON JenisPemberitahuan TO Dosen GRANT ALL PREVILEGES ON KesediaanMengajarJadwal TO Dosen GRANT ALL PREVILEGES ON KesediaanMengajarMatkul TO Dosen GRANT SELECT, INSERT ON Pemberitahuan TO Dosen GRANT SELECT, UPDATE ON Jadwal TO Dosen GRANT SELECT ON HistoryMengajarDosen TO Dosen

Authorization user Admin: GRANT ALL PREVILEGES ON Dosen TO Admin GRANT ALL PREVILEGES ON User TO Admin GRANT ALL PREVILEGES ON EmailDosen TO Admin GRANT ALL PREVILEGES ON HPDosen TO Admin GRANT ALL PREVILEGES ON Jabatan TO Admin GRANT ALL PREVILEGES ON Fakultas TO Admin

196

GRANT ALL PREVILEGES ON Jurusan TO Admin GRANT ALL PREVILEGES ON Kampus TO Admin GRANT ALL PREVILEGES ON Tempat TO Admin GRANT ALL PREVILEGES ON Kelas TO Admin GRANT ALL PREVILEGES ON Periode TO Admin GRANT ALL PREVILEGES ON MataKuliah TO Admin GRANT ALL PREVILEGES ON JenisUser TO Admin GRANT ALL PREVILEGES ON KelompokMatkul TO Admin GRANT ALL PREVILEGES ON JenisPemberitahuan TO Admin GRANT ALL PREVILEGES ON Status TO Admin GRANT ALL PREVILEGES ON KesediaanMengajarJadwal TO Admin GRANT ALL PREVILEGES ON KesediaanMengajarMatkul TO Admin GRANT ALL PREVILEGES ON Pemberitahuan TO Admin GRANT ALL PREVILEGES ON DetailMatkulKelas TO Admin GRANT ALL PREVILEGES ON Jadwal TO Admin GRANT ALL PREVILEGES ON HistoryMengajarDosen TO Admin

4.2

State Transition Diagram State Transition Diagram dirancang untuk menggambarkan urutan dan variasi yang dapat terjadi dalam sesi pengguna. Berikut ini adalah State Transition Diagram dari sistem aplikasi yang dirancang:

197

1. State Transition Diagram Layar Menu Utama

Gambar 4.19 STD Layar Menu UtamaState Transition Diagram Layar Menu Admin

198

Gambar 4.20 STD Layar Menu Admin

199

2.

State Transition Diagram Layar Lencturer Admin

Gambar 4.21 STD Layar Menu Lecturer Admin

200

3.

State Transition Diagram Layar Schedule Admin

Gambar 4.22 STD Layar Menu Schedule Admin

201

4.

State Transition Diagram Layar Subject Admin

Gambar 4.23 STD Layar Subject Admin

202

5.

State Transition Diagram Layar Department Admin

Gambar 4.24 STD Layar Department Admin

203

6.

State Transition Diagram Layar User Admin

Gambar 4.25 STD Layar User Admin

204

7.

State Transition Diagram Layar Notification Admin

Gambar 4.26 STD Layar Notification Admin

205

8.

State Transition Diagram Layar Menu Dosen

Gambar 4.27 STD Layar Menu Dosen

206

9.

State Transition Diagram Layar Profile Dosen

Gambar 4.28 STD Layar Profile Dosen

207

10.

State Transition Diagram Layar Schedule Dosen

Gambar 4.29 STD Layar Schedule Dosen

208

11.

State Transition Diagram Layar Notification Dosen

Gambar 4.30 STD Layar Notification Dosen

4.3

Perancangan Aplikasi 4.3.1

Perancangan Struktur Menu Struktur menu pada aplikasi ini dirancang untuk 2 jenis user, yaitu admin dan dosen. Berikut ini adalah rancangan struktur menu dari aplikasi:

209

1. Struktur menu admin

Gambar 4.30 Stuktur Menu Admin

210

2. Struktur menu dosen

Gambar 4.31 Struktur Menu Dosen

211

4.3.2 Perancangan Layar Pada tahapan ini akan dirancang rancangan tampilan layar (user interface) dari keseluruhan aplikasi. Rancangan layar dapat dilihat di bagian Perancangan Layar (Lampiran L1)

4.4

Implementasi dan Evaluasi 4.4.1 Implementasi Proses pengimplementasian aplikasi ini akan melibatkan pihak sekretaris jurusan IT di Binus University, Sebagai pihak yang menangani atau mengatur jadwal mengajar dosen di Binus University. Proses pengimplementasian yang melibatkan sekretaris jurusan antara lain: proses web hosting, konversi, dan loading data. Pada proses konversi dan loading data, database akan dirancang tersendiri sesuai dengan kebutuhan aplikasi. Namun sumber data pada database tersebut sebagian besar berasal dari database Binus. Untuk menjalankan aplikasi berbasis web ini diperlukan satu komputer yang bertindak sebagai server. Sedangkan untuk user, dibutuhkan seperangkat komputer untuk mengakses aplikasi ini, yang bertindak sebagai client. 4.4.1.1

Spesifikasi Perangkat Keras Spesifikasi perangkat keras yang dibutuhkan untuk pengimplementasian program aplikasi ini adalah sebagai berikut :

212

Tabel 4.54 Spesifikasi Perangkat Keras Perangkat Keras Processor

Server

Client

Intel Xeon processor 5600

Intel Pentium IV 3.0GHz

series Memory

2 GB FDDR2

2 GB FDDR2

Harddisk

320 GB SATA II

80 GB SATA II

Monitor

CRT/LCD 17”

CRT/LCD 17”

Printer

-

EPSON Stylus T11

Keyboar dan Mouse

Logitech

Logitech

CD ROM Drive

Samsung

Samsung

Switch

Link-Sys

Link-Sys

Kabel UTP

Kabel UTP

-

Modem

Kabel LAN Hardware Pendukung

4.4.1.2 Spesifikasi Perangkat Lunak Spesifikasi perangkat lunak yang dibutuhkan untuk pengimplementasian program aplikasi ini adalah sebagai berikut : Tabel 4.55 Spesifikasi Perangkat Lunak Perangakt Lunak Sistem Operasi

DBMS

Server

Client

Microsoft Windows Server

Microsoft Windows XP

2003

Professional SP2

MYSQL

-

213

Web Server

APACHE

Web Browser

Microsoft Internet

-

Explorer 7 FireFox

Software Pendukung

4.5

Adobe Flex Builder

-

Evaluasi Evaluasi yang didapatkan dari perbandingan antara sistem yang lama dengan sistem baru yang akan di implementasikan, yaitu : 1. Proses-proses manual pada sistem yang lama dapat dihilangkan dan digantikan

dengan

menggunakan

sistem

aplikasi

secara

terkomputerisasi. 2. Sistem yang baru lebih efektif dan efisien dalam melakukan sebagian besar tugas perusahaan. 3. Database mampu menangani kebutuhan perusahaan dengan baik. 4. Aplikasi cukup mudah digunakan dengan tampilan yang cukup menarik. 4.5.1 Evaluasi Dari Segi Pengguna Hasil dari evaluasi pengguna yang diukur berdasarkan pada lima faktor manusia terukur yaitu:

214

1. Bagaimana pendapat Anda mengenai tampilan aplikasi kami? Tabel 4.56 Pendapat mengenai tampilan aplikasi Jawaban

Bobot

Responden Bobot * Responden

Sangat menarik

4

7

28

Menarik

3

18

54

Tidak menarik

2

3

6

Sangat tidak

1

2

2

30

90

menarik Total

Pendapat Mengenai Tampilan Aplikasi 7% 10%

23% Sangat Menarik Menarik Tidak Menarik Sangat Tidak Menarik

60%

215

2. Apakah aplikasi yang kami buat mudah untuk digunakan? Tabel 4.57 Kemudahan penggunaan aplikasi Jawaban

Bobot


Sangat mudah

4

15

60

Mudah

3

9

27

Sulit

2

5

10

Sangat Sulit

1

1

1

30

98

Total

Kemudahan Penggunaan Aplikasi 3% 17%

47%

Sangat Mudah Mudah Sulit Sangat Sulit

33%

3. Jika di lain waktu anda mengunjungi kembali situs ini, seberapa mudah Anda menggunakan kembali situs ini? Tabel 4.58 Tingkat Kemudahan Saat Penggunaan Kembali Jawaban Sangat mudah

Bobot 4

Responden Bobot * Responden 13

52

216

Mudah

3

11

33

Sulit

2

5

10

Sangat Sulit

1

1

1

30

96

Total

Tingkat Kemudahan Saat Penggunaan Kembali 3% 17% Sangat Mudah

43%

Mudah Sulit Sangat Sulit

37%

4. Bagaimana kecepatan aplikasi kami ketika jalan di browser anda? Tabel 4.59 Kecepatan aplikasi saat dijalankan di browser Jawaban


Sangat cepat

4

9

36

Cepat

3

10

30

Biasa saja

2

9

18

Lambat

1

2

2

30

86

Total

Bobot

217

Kecepatan Aplikasi Saat Dijalankan di Browser 7% 30% Sangat Mudah

30%

Cepat Biasa Saja Lambat

33%

5. Apakah aplikasi yang kami buat ini membantu dalam sistem pengaturan jadwal mengajar dosen daripada sistem sebelumnya? Tabel 4.60 Membantu pengaturan jadwal Jawaban


Sangat membantu

4

15

60

Membantu

3

9

27

Biasa saja

2

4

8

Tidak membantu

1

2

2

30

97

Total

Bobot

218

Membantu Pengaturan Jadwal 7% 13% Sangat Membantu Membantu

50%

Biasa Saja Tidak Membantu

30%

6. Apakah fitur-fitur yang disediakan di aplikasi yang kami buat ini membantu anda dalam mengisi jadwal kesediaan mengajar, kesediaan mengajar mata kuliah, dan juga berkomunikasi dengan bagian pengaturan jadwal mengajar Anda? Tabel 4.61 Fitur-fitur yang disediakan Jawaban


Sangat membantu

4

15

60

Membantu

3

10

30

Biasa saja

2

4

8

Tidak membantu

1

1

1

30

99

Total

Bobot

219

Fitur-Fitur yang Disediakan 3% 13% Sangat Membantu

51%

Membantu Biasa Saja Tidak Membantu

33%

4.6

Panduan Pengoperasian Aplikasi Panduan pengoperasian program aplikasi berupa tampilan layar aplikasi dan penjelasan mengenai fungsi form aplikasi secara rinci. Penduan pengoperasian ini dapat dilihat di Panduan Pengoperasian Program Aplikasi (L22)

BAB 4 PERANCANGAN DAN IMPLEMENTASI. 1. Perancangan database konseptual (conceptual database design)

Recommend Documents