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 ini, yaitu: Dosen, User, KesediaanMengajarJadwal, KesediaanMengajarMatakuliah, Kelas, Pemberitahuan, Jurusan, HistoryMengajarDosen, MataKuliah, dan Jadwal. 89

90 Tabel 4.1 Tabel Identifikasi Entitas Nama Entitas Deskripsi Alias Kejadian Dosen Istilah umum untuk Dosen Setiap dosen orang yang bertugas terdaftar sebagai mengajar di pengguna. universitas. Setiap mengajar dosen 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 dalam menggunakan aplikasi.

91 Nama Entitas Deskripsi Alias Kejadian KesediaanMengajar- Informasi mengenai Kesediaan- Kesediaan mengajar Matkul kesediaan mengajar Mengajar- mata kuliah diisi dosen pada mata Matakuliah oleh setiap dosen. kuliah tertentu. KesediaanMengajar- Informasi kesediaan Kesediaan- Kesediaan mengajar Jadwal mengajar dosen Mengajar- jadwal diisi oleh pada hari dan shift tertentu. Jadwal setiap dosen. Pemberitahuan Pemberitahuan yang Pemberitahuan Setiap pengguna akan diberikan dapat menerima dan kepada pengguna. mengirimkan Jurusan Informasi mengenai pemberitahuan. Jurusan Setiap dosen jurusan. memiliki jurusan tertentu. HistoryMengajar- Informasi mengenai HistoryMengajar Setiap dosen Dosen mata kuliah yang Dosen memiliki history sudah pernah diajar mengajar. oleh dosen yang bersangkutan.

92 Nama Entitas Deskripsi Alias Kejadian MataKuliah Informasi mengenai mata kuliah yang tersedia. Matakuliah Setiap dosen mengajar satu atau lebih mata kuliah. 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 dosen jadwal dosen. mengajar memiliki satu jadwal 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 Antar Entitas Nama Entitas Multiplicity Dosen 1..1 Mengisi Kesediaan 1..* 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 Data & Length NULL Multi Valued integer Tidak Tidak Pemberitahuan KdPemberitahuan Kode pemberitahuan JenisPemberitahuan Jenis pem- varchar Tidak Tidak beritahuan (50) Pemberitahuan Isi dari pem- varchar Tidak Tidak beritahuan (500) Tanggal Pemberitahuan Tanggal pemberitahuan dikirimkan datetime Tidak Tidak

96 Status Status pem- varchar Tidak Tidak beritahuan (10) (diterima atau ditolak) Tabel 4.4 Entitas Jadwal Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Jadwal KdJadwal Kode jadwal integer Tidak Tidak integer Tidak Tidak Hari Hari pelaksanaan Shift Shift pe- integer Tidak Tidak laksanaan Periode Periode char Tidak Tidak (tahun (20) ajaran) Semester Semester varchar Tidak Tidak (ganjil genap) atau (10) SemesterBerjalan Menandakan semester integer Tidak Tidak

97 yang sedang berlangsung NoRuang Nomor varchar Tidak Tidak ruangan yang (10) tersedia NamaKampus Nama varchar Tidak Tidak kampus (50) Tabel 4.5 Entitas User Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued User Username Username char (5) Tidak Tidak pengguna yang ada JenisUser Jenis varchar Tidak Tidak pengguna (10) yang ada Password Password varchar Tidak Tidak pengguna (50)

98 Tabel 4.6 Entitas MataKuliah Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued MataKuliah KdMataKuliah Kode mata char (5) Tidak Tidak kuliah NamaMataKuliah Nama mata varchar Tidak Tidak kuliah (50) SKSTeori Jumlah SKS integer Tidak Tidak teori kuliah mata SKSPraktikum bersangkutan Jumlah SKS praktikum integer Tidak Tidak mata kuliah bersangkutan NamaKelompok Nama varchar Tidak Tidak kelompok (100) mata kuliah (rumpun mata kuliah)

99 PenanggungJawab Nama pe- varchar Tidak Tidak nanggung (100) jawab kelompok mata kuliah bersangkutan Tabel 4.7 Entitas Kelas Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Kelas KdKelas Kode kelas char (5) Tidak Tidak JumlahMahasiswa Jumlah mahasiswa setiap kelas integer Tidak Tidak Tabel 4.8 Entitas Jurusan Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Jurusan KdJurusan Kode jurusan char (5) Tidak Tidak NamaJurusan Nama varchar Tidak Tidak

100 jurusan (100) NamaFakultas Nama varchar Tidak Tidak fakultas (100) Tabel 4.9 Entitas Dosen Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Dosen KdDosen Kode dosen char (5) Tidak Tidak NamaDosen Nama dosen varchar (100) Tidak Tidak AlamatDosen Alamat varchar Tidak Tidak dosen (100) TeleponRumah Telepon varchar Tidak Tidak rumah dosen (20) bersangkutan LineTelepon Line telepon varchar Ya Tidak rumah dosen (10) bersangkutan (apabila ada) HPDosen Nomor varchar Tidak Ya handphone (50)

101 dosen EmailDosen Email dosen varchar (50) Tidak Ya Status Status dosen varchar Tidak Tidak (aktif cuti) atau (10) SKSMengajar Jumlah SKS mengajar integer Tidak Tidak yang telah disetujui oleh dosen NamaJabatan Nama varchar Tidak Tidak jabatan (50) Tabel 4.10 Entitas KesediaanMengajarMatkul Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Kesediaan KdKesediaan Kode integer Tidak Tidak Mengajar MengajarMatkul kesediaan MataKuliah mengajar matakuliah

102 dosen Periode Periode varchar Tidak Tidak (tahun (10) ajaran) Semester Semester varchar Tidak Tidak (ganjil genap) atau (10) SemesterBerjalan Menandakan semester yang sedang berlangsung integer Tidak Tidak Tabel 4.11 Entitas KesediaanMengajarJadwal Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued Kesediaan KdKesediaan Kode integer Tidak Tidak Mengajar MengajarJadwal kesediaan Jadwal mengajar jadwal dosen Hari Hari pe- varchar Tidak Tidak laksanaan (10)

103 Shift Shift pe- integer Tidak Tidak laksanaan Periode Periode char Tidak Tidak (tahun (10) ajaran) Semester Semester varchar Tidak Tidak (ganjil genap) atau (10) SemesterBerjalan Menandakan semester yang sedang berlangsung integer Tidak Tidak Tabel 4.12 Entitas HistoryMengajarDosen Nama Entitas Atribut Deskripsi Tipe Data & Length NULL Multi Valued History KdHistory Kode history char (5) Tidak Tidak Mengajar JumlahSKS Jumlah SKS integer Tidak Tidak Dosen Mengajar mengajar dosen dalam satu semester

104 Periode Periode char Tidak Tidak (tahun (10) ajaran) Semester Semester varchar Tidak Tidak (ganjil genap) atau (10) SemesterBerjalan Menandakan semester yang sedang berlangsung integer Tidak Tidak 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 Atribut Domain Pemberitahuan 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 Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi Tabel 4.13 Tabel Domain Atribut untuk Entitas Jadwal Nama Entitas Atribut Domain Jadwal KdJadwal Terdiri dari 5 karakter yang diisi dengan huruf atau angka Hari Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi Shift Periode Berupa integer Terdiri dari 10 karakter, yang diisi dengan huruf atau angka Semester Terdiri dari 10 karakter, yang

106 diisi dengan huruf atau angka SemesterBerjalan NoRuang Berupa integer Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi NamaKampus Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi Tabel 4.14 Tabel Domain Atribut untuk Entitas User Nama Entitas Atribut Domain User Username Terdiri dari 5 karakter, yang diisi dengan huruf atau angka JenisUser Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi 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 Atribut Domain MataKuliah KdMataKuliah Terdiri dari 5 karakter, yang diisi dengan huruf pertama berupa huruf, kemudian sisanya berupa angka 0-9 NamaMataKuliah Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi SKSTeori SKSPraktikum NamaKelompok Berupa integer Berupa integer Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi PenanggungJawab Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi

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 Atribut Domain Jurusan KdJurusan Terdiri dari 5 karakter, dua karakter pertama diisi dengan huruf, kemudian sisanya berupa angka 0-9 NamaJurusan Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi NamaFakultas Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi

109 Tabel 4.18 Tabel Domain Atribut untuk Entitas Dosen Nama Entitas Atribut Domain Dosen KdDosen Terdiri dari 5 karakter, karakter pertama diisi dengan huruf, kemudian sisanya berupa angka 0-9 NamaDosen Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi AlamatDosen Berupa varian karakter dengan panjang maksimal 100, yang diisi dengan huruf atau angka dan sudah termasuk spasi TeleponRumah Berupa varian karakter dengan panjang maksimal 20, yang diisi dengan huruf atau angka dan sudah termasuk spasi LineTelepon Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi

110 HPDosen Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi EmailDosen Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi Status Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi SKSMengajar NamaJabatan Berupa integer Berupa varian karakter dengan panjang maksimal 50, yang diisi dengan huruf atau angka dan sudah termasuk spasi Tabel 4.19 Tabel Domain Atribut untuk Entitas KesediaanMengajarMatkul Nama Entitas Atribut Domain KesediaanMengajar- Matkul KdKesediaan MengajarMatkul Berupa integer

111 Periode Terdiri dari 10 karakter, yang diisi dengan huruf atau angka Semester Terdiri dari 10 karakter, yang diisi dengan huruf atau angka SemesterBerjalan Berupa integer Tabel 4.20 Tabel Domain Atribut untuk Entitas KesediaanMengajarJadwal Nama Entitas Atribut Domain KesediaanMengajarJadwal KdKesediaan MengajarJadwal Hari Shift Periode Semester SemesterBerjalan Berupa integer Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi Berupa integer Terdiri dari 10 karakter, yang diisi dengan huruf atau angka Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi Berupa integer

112 Tabel 4.21 Tabel Domain Atribut untuk Entitas HistoryMengajarDosen Nama Entitas Atribut Domain HistoryMengajarDosen KdHistory Berupa integer JumlahSKSMengajar Periode Berupa integer Terdiri dari 10 karakter, yang diisi dengan huruf atau angka Semester Berupa varian karakter dengan panjang maksimal 10, yang diisi dengan huruf atau angka dan sudah termasuk spasi 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 Jadwal -KdPemberitahuan -Pemberitahuan -KdJadwal -Hari KdPemberitahuan KdJadwal User -Username Username

113 MataKuliah -Password -KdMataKuliah -NamaMataKuliah KdMataKuliah Kelas -KdKelas KdKelas Dosen Jurusan KesediaanMengajar Matkul KesediaanMengajar Jadwal HistoryMengajarDosen -KdDosen -NamaDosen -KdJurusan -NamaJurusan -KdKesediaan- MengajarMatKul -KdKesediaan- MengajarJadwal -KdHistory -JumlahSKSMengajar KdDosen KdJurusan 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 tanpa kehadiran entitas dimana mereka bergantung. Table 4.24 Tabel Weak Entity Type Dosen Weak Entity EmailDosen (EmailDosen, KdDosen, Num)

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 HistoryMengajarDosen

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 KesediaanMengajarMatkul h. Hubungan MataKuliah dengan HistoryMengajarDosen MataKuliah sebagai entitas parent, dan HistoryMengajarDosen sebagai entitas child, 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 HistoryMengajarDosen 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 Username KdJabatan NamaDosen AlamatDosen TeleponRumah LineTelepon SKSMengajar Status 1NF fd1 (Primary Key) fd2 (Transitive Dependency) fd3 (Transitive Dependency) fd4 (Transitive Dependency) 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 KesediaanMengajarMatkul 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 + #Username + #KdJenisPemberitahuan + #KdStatus + Pemberitahuan + TanggalPemberitahuan JenisPemberitahuan = @KdJenisPemberitahuan + JenisPemberitahuan Status = @KdStatus + Status

139 HistoryMengajarDosen 1NF HistoryMengajarDosen = @KdHistory + #KdDosen + #KdMataKuliah + Periode + Semester + SemesterBerjalan + JumlahSKSMengajar Dalam relasi HistoryMengajarDosen sudah tidak terdapat repeating groups sehingga relasi sudah berada dalam kondisi 1NF. 2NF Dalam relasi HistoryMengajarDosen 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 Status PK KdJenisPemberitahuan JenisPemberitahuan PK JenisUser KdJenisUser PK KdStatus Status PK KesediaanMengajarJadwal KdKesediaanMengajarJadwal FK1 KdDosen FK2 KdPeriode Shift Hari PK Pemberitahuan KdPemberitahuan FK1 KdJenisPemberitahuan FK2 KdStatus FK3 Username Pemberitahuan TanggalPemberitahuan PK FK1 JenisUser User Username KdJenisUser Password PK PK KesediaanMengajarMatkul KdKesediaanMengajarMatkul FK1 KdDosen FK2 KdMataKuliah FK3 KdPeriode Periode KdPeriode Semester TahunAjaran SemesterBerjalan PK FK1 PK PK FK1 Jurusan KdJurusan KdFakultas NamaJurusan Fakultas KdFakultas NamaFakultas Tempat NoRuang KdKampus PK Dosen KdDosen FK1 KdJurusan FK2 Username FK3 KdJabatan NamaDosen AlamatDosen TeleponRumah LineTelepon Status SKSMengajar PK HistoryMengajarDosen KdHistory FK1 KdDosen FK2 KdMataKuliah FK3 KdPeriode JumlahSKSMengajar PK Jadwal KdJadwal FK1 KdDosen FK2 KdMataKuliah FK3 KdKelas FK4 KdPeriode FK5 NoRuang Hari Shift PK FK1 PK FK1 EmailDosen EmailDosen KdDosen Num HPDosen HPDosen KdDosen Num PK FK1 MataKuliah KdMataKuliah PK KdKelompok NamaMataKuliah SKSTeori SKSPraktikum Jabatan KdJabatan NamaJabatan PK FK1 PK KelompokMatkul KdKelompok NamaKelompok PenanggungJawab DetailMatkulKelas PK,FK1 KdKelas PK,FK2 KdMataKuliah Kelas KdKelas KdJurusan JumlahMahasiswa Kampus PK KdKampus 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 JenisPemberitahuan (KdJenisPemberitahuan) ON UPDATE CASCADE ON DELETE NO ACTION

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 : fixed length character string, length 5 Format : [D][0-9][0-9][0-9][0-9] Domain NamaDosen : variable length character string, length 100 Domain AlamatDosen : variable length character string, length 100 Domain TeleponRumah : variable length character string, length 20 Domain Line-Telepon : variable length character string, length 10 Domain SKSMengajar Domain Status : integer : variable length character string, length 10 Dosen ( KdDosen KdJurusan Username NamaDosen AlamatDosen TeleponRumah LineTelepon SKSMengajar NULL,

153 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 CASCADE, Foreign Key (KdJabatan) References Jabatan(KdJabatan) ON UPDATE CASCADE ON DELETE NO ACTION, ); 2. User Domain Username : fixed length character string, length 5 Domain Password : variable length character string, length 50 KdJenisUser : fixed length character string, length 5, Format : [J][U][0-9][0-9][0-9] User ( Username Password KdJenisUser Primary Key (Username),

154 Foreign Key (KdJenisUser) References JenisUser(KdJenisUser) ON UPDATE CASCADE ON DELETE NO ACTION ); 3. EmailDosen Domain EmailDosen : variable length character string, length 30 Domain KdDosen : fixed length character string, length 5, Format : [D][0-9][0-9][0-9][0-9] EmailDosen ( EmailDosen KdDosen Num Primary Key (EmailDosen), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION ); 4. HPDosen Domain HPDosen : variable length character string, length 20 Domain KdDosen : fixed length character string,

155 length 50, Format : [D][0-9][0-9][0-9][0-9] HPDosen ( HPDosen KdDosen Num Primary Key (HPDosen), Foreign Key (KdDosen) References Dosen(KdDosen) ON UPDATE CASCADE ON DELETE NO ACTION ); 5. Jabatan Domain KdJabatan : fixed length character string, length 5 Domain NamaJabatan : variable length character string, length 100, Format : [JA] [0-9][0-9][0-9] Jabatan ( KdJabatan NamaJabatan Primary Key (KdJabatan) );

156 6. Fakultas Domain KdFakultas : fixed length character string, length 5 Domain NamaFakultas : variable length character string, length 100, Fakultas ( KdFakultas NamaFakultas Primary Key (KdFakultas) ); 7. Jurusan Domain KdJurusan : fixed length character string, length 5 Domain KdFakultas : fixed length character string, length 5 Domain NamaJurusan : variable length character string, length 100, Jurusan ( KdJurusan KdFakultas NamaJurusan Primary Key (KdJurusan),

157 Foreign Key (KdFakultas) References Fakultas(KdFakultas) ON UPDATE CASCADE ON DELETE NO ACTION ); 8. Kampus Domain KdKampus : fixed length character string, length 5 Domain NamaKampus : variable length character string, length 50, Kampus ( KdKampus NamaKampus Primary Key (KdKampus) ); 9. Tempat Domain NoRuang : variable length character string, length 10, Domain KdKampus : fixed length character string, length 5 Tempat ( NoRuang KdKampus

158 Primary Key (NoRuang), Foreign Key (KdKampus) References Kampus(KdKampus) ON UPDATE CASCADE ON DELETE NO ACTION ); 10. Kelas Domain KdKelas : fixed length character string, length 5 Domain KdJurusan : fixed length character string, length 5, Domain JumlahMahasiswa : integer Kelas ( KdKelas KdJurusan JumlahMahasiswa Primary Key (KdKelas) Foreign Key (KdJurusan) References Jurusan(KdJurusan) ON UPDATE CASCADE ON DELETE NO ACTION ); 11. Periode Domain KdPeriode : fixed length character string, length 5

159 Domain Periode : variable length character string, length 20, Domain Semester : variable length character string, length 20, Domain Semester Berjalan : integer Periode ( KdPeriode Periode Semester Semester Berjalan Primary Key (KdKelas) ); 12. MataKuliah Domain KdMataKuliah : fixed length character string, length 5 Domain KdKelompok : fixed length character string, length 5 Domain NamaMataKuliah : fixed length character string, length 50 Domain SKSTeori Domain SKSPraktikum : integer : integer MataKuliah (

160 KdMataKuliah KdKelompok NamaMataKuliah SKSTeori SKSPraktikum Primary Key (KdMataKuliah), Foreign Key (KdKelompok) References KelompokMatkul(KdKelompok) ON UPDATE CASCADE ON DELETE NO ACTION ); 13. JenisUser Domain KdJenisUser : fixed length character string, length 5 Domain JenisUser : variable length character string, length 10 JenisUser ( KdJenisUser JenisUser Primary Key (KdJenisUser) ); 14. KelompokMatkul Domain KdKelompok : fixed length character string,

161 length 5 Domain NamaKelompok : fixed length character string, length 5 Domain PenanggungJawab : variable length character string, length 50 KelompokMatkul ( KdKelompok NamaKelompok PenanggungJawab Primary Key (KdKelompok) ); 15. JenisPemberitahuan Domain KdJenisPemberitahuan : fixed length character string, length 5 Domain JenisPemberitahuan : variable length character string, length 50 JenisPemberitahuan ( KdJenisPemberitahuan JenisPemberitahuan Primary Key (KdKelompok) );

162 16. Status Domain KdStatus : fixed length character string, length 5 Domain Status : variable length character string, length 20 Kelas ( KdStatus Status Primary Key (KdStatus) ); 17. KesediaanMengajarJadwal Domain KdKesediaanMengajarJadwal : integer Domain KdDosen : fixed length character string, length 5 Format : [D][0-9][0-9][0-9][0-9] Domain KdPeriode : fixed length character string, length 5 Domain Hari Domain Shift : integer : integer DetailKesediaanMengajarJadwal ( KdKesediaanMengajarJadwal KdDosen

163 KdPeriode Hari Shift 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 : fixed length character string, length 5 Format : [D][0-9][0-9][0-9][0-9] Domain KdMataKuliah : fixed length character string, length 5 Format : [D][0-9][0-9][0-9][0-9] Domain KdPeriode : fixed length character string, length 5 KesediaanMengajarMatkul ( KdKesediaanMengajarMatkul KdDosen

164 KdMataKuliah KdPeriode 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 Domain KdDosen : integer : fixed length character string, length 5 Domain KdJenisPemberitahuan : fixed length character string, length 5 Domain KdPemberitahuan : fixed length character string, length 5 Domain Pemberitahuan : variable length character string, length 500 Domain TanggalPemberitahuan : datetime Pemberitahuan (

165 KdPemberitahuan KdDosen KdJenisPemberitahuan KdStatus Pemberitahuan TanggalPemberitahuan 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 : fixed length character string, length 5 Domain KdKelas : fixed length character string, length 5 DetailMatkulKelas( KdMataKuliah

166 KdKelas 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 Domain KdDosen : integer : fixed length character string, length 5 Domain KdMataKuliah : fixed length character string, length 5 Domain KdKelas : fixed length character string, length 5 Domain NoRuang : variable length character string, length 10 Domain KdPeriode : fixed length character string, length 5 Domain Hari : variable length character string, length 10 Domain Shift : integer

167 Jadwal ( KdJadwal KdDosen KdMataKuliah KdKelas NoRuang KdPeriode Hari Shift 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 Domain KdDosen : integer : fixed length character string, length 5 Domain KdMataKuliah : fixed length character string, length 5 Domain KdPeriode : fixed length character string, length 5 Domain JumlahSKSMengajar : integer 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, );

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 menganalisis transaksi-transaksi tersebut digunakan 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) (b) (c) (d) Relasi I R U D I R U D I R U D I R U D Dosen X X X X User X X EmailDosen X X X X HPDosen X X X X Jabatan X X Fakultas X X Jurusan X X Kampus Tempat Kelas Periode MataKuliah X X X X X

174 JenisUser KelompokMatkul X X JenisPemberitahuan Status Kesediaan- MengajarJadwal Kesediaan- MengajarMatkul pemberitahuan DetailMatkulKelas Jadwal HistoryMengajarDosen Tabel 4.27 Analisis Transaksi II Transaksi (e) (f) (g) (h) Relasi I 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

175 Fakultas Jurusan Kampus X Tempat X Kelas X Periode X MataKuliah X X X JenisUser KelompokMatkul JenisPemberitahuan X Status X X Jadwal KesediaanMengajar- KesediaanMengajar- X Matkul Pemberitahuan X DetailMatkulKelas Jadwal X HistoryMengajarDosen X

176 Tabel 4.28 Analisis Transaksi III Transaksi (i) (j) (k) (l) Relasi I R U D I R U D I R U D I R U D Dosen User EmailDosen HPDosen Jabatan Fakultas X X X X X X X Jurusan X X X X X Kampus Tempat Kelas Periode MataKuliah JenisUser KelompokMatkul JenisPemberitahuan Status KesediaanMengajar Jadwal

177 KesediaanMengajar Matkul Pemberitahuan DetailMatkulKelas Jadwal HistoryMengajarDosen Tabel 4.29 Analisis Transaksi IV Transaksi (m) (n) Relasi I R U D I R U D Dosen X X User EmailDosen HPDosen Jabatan Fakultas Jurusan Kampus X X Tempat X X Kelas X X Periode X X

178 MataKuliah X X JenisUser KelompokMatkul X X JenisPemberitahuan Status KesediaanMengajar- X X Jadwal KesediaanMengajar- X X Matkul Pemberitahuan DetailMatkulKelas Jadwal X X X X 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 Tipe data Ukuran KdKesediaanMengajarJadwal Integer 4 KdDosen Char 5 KdPeriode Char 5 Hari Integer 4 Shift Integer 4 Kapasitas 1 record dari tabel KesediaanMengajarJadwal

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 Kapasitas 1 record dari tabel KesediaanMengajarMatkul adalah 19 byte. Diperkirakan jumlah record awal adalah 1200, dan dalam 1 tahun terjadi penambahan 200 record. Dalam satu tahun kebutuhan tabel ini adalah 1400*19 = 26600 byte. Tabel 4.47 Estimasi Kapasitas DetailMatkulKelas Fields Tipe data Ukuran KdMataKuliah Char 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 HistoryMengajarDosen adalah 24 byte. Diperkirakan jumlah record awal adalah 1000, dan dalam 1 tahun terjadi penambahan 200 record. Dalam satu tahun kebutuhan tabel ini adalah 1200*24 = 28800 byte. Tabel 4.50 Estimasi Kapasitas Pemberitahuan Fields Tipe data Ukuran KdPemberitahuan Integer 4 KdJenisPemberitahuan 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 KdJenisPemberitahuan 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 yang No Tabel dibutuhkan dalam satu 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. KesediaanMengajarJadwal 55000 17. KesediaanMengajarMatkul 26600 18. DetailMatkulKelas 5500

192 19. Jadwal 107500 20. HistoryMengajarDosen 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 Admin Relasi I 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 KesediaanMengajarJadwal 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 HistoryMengajarDosen 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

Gambar 4.20 STD Layar Menu Admin 198

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 Server Client Processor 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 LAN Kabel UTP Kabel UTP Hardware Pendukung - Modem 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 Server Client Sistem Operasi Microsoft Windows Server 2003 Microsoft Windows XP Professional SP2 DBMS MYSQL -

213 Web Server APACHE - Web Browser Microsoft Internet - Explorer 7 FireFox Software Pendukung Adobe Flex Builder - 4.5 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 menarik Total 30 90 Pendapat Mengenai Tampilan Aplikasi 7% 10% 23% Sangat Menarik Menarik Tidak Menarik 60% Sangat Tidak Menarik

215 2. Apakah aplikasi yang kami buat mudah untuk digunakan? Tabel 4.57 Kemudahan penggunaan aplikasi Jawaban Bobot Responden Bobot * Responden Sangat mudah 4 15 60 Mudah 3 9 27 Sulit 2 5 10 Sangat Sulit 1 1 1 Total 30 98 Kemudahan Penggunaan Aplikasi 17% 3% 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 Bobot Responden Bobot * Responden Sangat mudah 4 13 52

216 Mudah 3 11 33 Sulit 2 5 10 Sangat Sulit 1 1 1 Total 30 96 Tingkat Kemudahan Saat Penggunaan Kembali 17% 3% 43% Sangat Mudah 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 Bobot Responden Bobot * Responden Sangat cepat 4 9 36 Cepat 3 10 30 Biasa saja 2 9 18 Lambat 1 2 2 Total 30 86

217 Kecepatan Aplikasi Saat Dijalankan di Browser 7% 30% 30% Sangat Mudah 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 Bobot Responden Bobot * Responden Sangat membantu 4 15 60 Membantu 3 9 27 Biasa saja 2 4 8 Tidak membantu 1 2 2 Total 30 97

218 Membantu Pengaturan Jadwal 7% 13% 50% Sangat Membantu Membantu 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 Bobot Responden Bobot * Responden Sangat membantu 4 15 60 Membantu 3 10 30 Biasa saja 2 4 8 Tidak membantu 1 1 1 Total 30 99

219 Fitur-Fitur yang Disediakan 13% 3% 51% Sangat Membantu 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)