PERENCANAAN BASIS DATA SISTEM INFORMASI PENJADWALAN SEKOLAH

Seminar Nasional Teknologi Informasi dan Multimedia 2015

ISSN : 2302-3805

STMIK AMIKOM Yogyakarta, 6-8 Februari 2015

PERENCANAAN BASIS DATA SISTEM INFORMASI PENJADWALAN SEKOLAH Ikmah1) 1)

Teknik Informatika STMIK AMIKOM Yogyakarta Jl Ring road Utara, Condongcatur, Sleman, Yogyakarta 55281 Email : [email protected])

Abstrak Penjadwalan menunjukkan apa yang harus dilakukan, kapan, oleh siapa dan peralatan apa yang harus digunakan. Penjadwalan yang baik akan memberikan dampak positif, yaitu rendahnya biaya operasi dan waktu pembuatan penjadwalan, yang akhirnya dapat meningkatkan kepuasan bagi anggota dalam organisasi. Kenyatannya sampai saat ini masih banyak sekolah yang menggunakan proses penjadwalan secara manual. Untuk itu perlu adanya media pengolah dan penyimpanan data yang baik untuk dapat menghasilkan penjadwalan secara lebih cepat dan akurat. Penggunaan basis data akan memudahkan pihak sekolah dalam mengolah data menjadi penjadwalan yang berkualitas. Penulis akan membahas perancangan basis data pada sistem informasi penjadwalan sekolah secara rinci untuk dapat membantu sekolah dalam melakukan proses penjadwalan.Peneliti berharap dengan adanya perancangan basis data penjadwalan sekolah ini dapat dikembangkan menjadi sebuah sistem aplikasi yang dapat mempermudah proses penjadwalan sekolah. Kata kunci: basis data, penjadwalan, sekolah 1. Pendahuluan Pembahasan basis data yang dilakukan pada perancangan basis data pada umumnya belum dibahas secara rinci. Dari hasil penelitian penulis, maka peneliti akan menjabarkan proses perancangan basis data secara terperinci mulai dari penentuan entitas, perancangan entity relationship diagram, relasi antar tabel dan struktur tabel beserta constraint pada kolom yang diperlukan. Dari hasil penelitian ini diharapkan dapat digunakan untuk pengembangan proses penjadwalan di sekolah terhadap peneliti selanjutnya. 2. Tinjauan Pustaka Istilah Penjadwalan dapat diartikan sebagai proses penentuan waktu mulai dan selesainya tugas[1]. Dari hasil penelitian yang penulis lakukan pada pemodelan data perancangan sistem informasi penjadwalan, tidak menginggung model data secara lebih terinci, seperti pada penelitian dengan Judul Analisis dan Perancangan Sistem Informasi Penjadwalan Guru di SMK YPE Sawunggalih Kutoarjo[3] dan penelitian dengan Judul Aplikasi Pengolahan Data

1.1-5

Penjadwalan Mengajar SMK Muhammadyah 1 Palembang Menggunakan Borland Delphi 7.0 [2] juga tidak membahas secara detail bagaimana pemodelan basis data. Dalam melakukan analisis basis data yang telah ada, penulis menggunakan beberapa kriteria untuk menilai basis data, yaitu dilihat dari hasil analisis kriteria kebenaran pada kasus tersebut terdapat pemilihan tipe data yang kurang tepat, seperti status nikah varchar(20), tipe data ini bisa diubah menjadi char(1) karena status nikah sudah ditetapkan berapa jenisnya, misalnya tentukan formatnya 1 untuk belum menikah, 2 untuk menikah[3]. Dilihat dari hasil analisis kriteria konsistensi pada kasus tersebut rancangan data kurang konsisten di beberapa field[3]. Dilihat dari hasil analisis kriteria relevansi pada kasus tersebut terdapat beberapa field yang kurang relevan untuk sistem informasi penjadwalan[3]. Dilihat dari hasil analisis kriteria kelengkapan pada kasus tersebut dilihat dari kelengkapan kebutuhan sistem yang dibutuhkan masih banyak laporan yang belum terdapat dalam sistem tersebut[3]. Dilihat dari hasil analisis kriteria minimalis pada kasus tersebut belum minimalis dilihat dari penentuan field yang digunakan[3]. Dilihat dari pemodelan data yang dilakukan dari kasus tersebut, masih perlu adanya revisi sehubungan dengan pemodelan data yang digunakan. Penggunaan fungsi dan constraint check belum ada pada rancangan kasus tersebut.Maka dari itu penulis mencoba mengembangkan dari kasus tersebut. 3. Pembahasan Kebutuhan fungsional yang ada di pemodelan data adalah sebuah aplikasi yang mampu memetakan plat mata pelajaran seorang guru dimana guru dapat mengajar lebih dari satu mata pelajaran, dari satu mata pelajaran yang kemungkinan benturan masih ada[3]. Dari beberapa review yang peneliti lakukan, maka peneliti mengambil kesimpulan bahwa dalam merancang basis data untuk sistem informasi penjadwalan harus dapat mengolah data sebagai berikut : (a) mengolah data guru, kelas, mata pelajaran, jurusan (b) menginputkan pembagian tugas berdasarkan SK yang sudah ditentukan (c) menampilkan jadwal per guru, per kelas dan perkelas serta jadwal keseluruhan Dari beberapa kesimpulan peneliti mengajukan rancangan basis data untuk sistem informasi penjadwalan mulai dari penentuan entitas, perancangan


ISSN : 2302-3805


entity relationship diagram, relasi antar tabel dan struktur tabel beserta constraint pada kolom yang diperlukan, seperti yang dapat dilihat di bawah ini dalah sebagai berikut : 1. Penentuan Entitas Entity sets adalah sekumpulan entity yang mempunyai tipe yang sama. Kesamaan tipe ini dapat dilihat dari atribut/property yang dimiliki oleh setiap entity[4]. Adapun pengetikan tabel, seperti tabel di bawah ini : Tabel 1.Tabel Entitas dan Atribut No Entitas Atribut 1 Guru NIP,Nama_guru,Tempat_lahir,Tangg al_lahir,Agama,Status_nikah,Alamat _rumah,Jenis_Kelamin,Telepon,Jenja ng_Pendidikan,Jurusan_Guru,Mulai_ Kerja,Status_pegawai,Tamat,Golong an,Pangkat,Jabatan,Status_Petugas,Pa ssword_user 2 Kelas Id_kelas, Nama_kelas 3 Jurusan Id_Jurusan, Nama_Jurusan 4 Mapel Id_mapel,Nama_mapel 5 Hari Nama_hari, Status, Urut 6 Jam Jamke, JamAwal, JamAkhir 7 Setting Jammaksimalsehari, Batasajar 1.1 Penentuan Primary Key dari Setiap Entitas Primary key adalah satu atau lebih atribut yang terpilih sebagai wakil dari suatu tabel apabila akan direlasikan dengan tabel yang lain[4]. Tabel 2.Tabel Primary Key No Entitas Atribut 1 Guru NIP 2 Kelas Id_kelas 3 Jurusan Id_Jurusan 4 Mata Pelajaran Id_mapel 5 Hari Nama_hari 6 Jam Jamke 1.2 Entity Relationship Diagram Membuat ERD awal untuk mendapatkan sebuah rancangan database yang minimal dapat mengakomodasi kebutuhan penyimpanan data terhadap sistem yang sedang kita tinjau. Setelah itu dapat dilakukan optimasi diagram E-R (final design) dengan mempertimbangkan anomaly-anomali dan aspek-aspek efisiensi, kinerja dan fleksibilitas[4]. Pada Gambar 1 adalah ERD Penjadwalan Sekolah I N

N

N

I

I

Gambar 1. Rancangan Entity Relationship Diagram dengan derajat kardinalitas Pada Gambar 1 menunjukkan hubungan antar entity yang telah dibuat. Setiap entity akan mempunyai

1.1-6

relational dan entity lainnya dengan derajat kardinalitas tertentu. Berikut adalah ini adalah gambar ERD setelah ditentukan derajat kardinalitasnya, sebagai berikut [3]: a. Entitas guru mempunyai hubungan 1 to N terhadap entitas mengajar, dikarenakan satu guru dapat mengajar lebih dari satu mata pelajaran. b. Entitas kelas mempunyai hubungan 1 to N terhadap Jadwal, dikarenakan satu kelas mempunyai satu jadwal, satu kelas tidak mempunyai jadwal lebih dari satu dalam satu waktu. c. Entitas mata pelajaran berelasi dengan entitas guru dimana satu mata pelajaran bisa diajarkan oleh lebih dari satu guru dan satu guru bisa mengajar banyak mata pelajaran, maka dari relasi tersebut muncul kardinalitas N to N. Untuk merelasikan dua entitas yang mempunyai kardinalitas N to N membutuhkan satu entitas lemah, sebagai contoh di database ini diberi nama entitas mengajar. d. Entitas jurusan mempunyai hubungan 1 to N terhadap entitas kelas karena satu jurusan dapat dimiliki banyak kelas. 1.3 Normalisasi Normalisasi merupakan cara pendekatan dalam membangun desain logika basis data relasional yang tidak secara langsung berkaitan dengan model data, tetapi dengan menerapkan sejumlah aturan dan kriteria standar untuk menghasilkan struktur tabel yang normal. [3]. 1.4 Relasi Antar Tabel Relationship set adalah sekumpulan relasi yang mempunyai tipe yang sama[4].

Gambar 2. Relasi Antar Tabel Gambar 2 menunjukan hasil dari pemodelan ERD yang berbentuk relasi antar tabel. Relasi ini terbentuk dari 9 buah tabel yang dibentuk dari seluruh entitas yang sudah dirancang[3]. 1.5 Struktur Tabel Struktur tabel disini akan merinci bagaimana bentuk tabel yang ada pada relasi, sebagai berikut : 1.Tabel Guru Tabel 2.Tabel Guru N Field Type Si Constraint o Data ze 1 NIP Char 25 Primary Key, Not null 2 Nama_ Varch 30 Not Null Guru ar 3 Tempat Varch 50 Not Null _lahir ar


ISSN : 2302-3805


4

Tangga l_lahir

Dateti me

8

5

Agama

Char

1

6

Status_ nikah Alamat _rumah Jenis_ Kelami n Telepo n Jenjang _Pendi dikan Jurusan _guru

Char

1

Varch ar Char

50 1

Not Null, only L/P

Char

12

Not Null

Char

1

Not Null, CHECK, only 1/2/3/4/5/6

Char

1

Mulai_ kerja Status_ Pegawa i Tamat

Dateti me Char

8

Not Null, CHECK, only 1/2/3/4/5/6/7/8/9/10 Not Null

1

Not Null, only 1/2/3

Dateti me Char

8

Not Null

1

Char

1

Char

1

Not Null, CHECK, only 1/2/3/4/5/6/7/8/9/10/11 Not Null, CHECK, only 1/2/3/4/5/6/7/8 Not Null, CHECK, only 1/2/3/4/5/6/7/8/9/10/11 Not Null, CHECK, only 1/0 Not Null

7 8

9 10

11

12 13

14 15

Golong an

16

Pangka t Jabatan

17

18

Not Null, CHECK, tahun lahir < tahun sekarang Not Null, CHECK, only 1/2/3/4/5/6 Not Null, CHECK, only 1/2/3/4 Not Null CHECK,

CHECK,

Status_ Char 1 petugas 19 Passwo Char 10 rd_petu gas Penjelasan untuk tabel 2 adalah sebagai berikut : a. Kolom NIP diberikan tipe char(25) karena seluruh NIP sudah ditetapkan dengan format 25 karakter untuk penghematan memori. b. Kolom Nama_Guru diberikan tipe data varchar(30) ,tempat_lahir varchar(50) dan alamat rumah varchar(50) karena nama guru tempat lahir,alamat rumah mempunyai jumlah karakter yang berbedabeda. c. Kolom tanggal lahir, mulai kerja, tamat menggunakan tipe data date time, karena untuk format tanggal. d. Kolom Agama, status_nikah, jenis kelamin, jurusan ,jenjang_pendidikan, status, pegawai, golongan, pangkat, jabatan, status_petugas diberikan tipe data Char(1) karena akternatif nilai batasannya sudah ditentukan, untuk penghematan memori.

1.1-7

e.

Kolom telepon diberikan tipe data char(12) karena jumlah nomor telepon sudah bisa diprediksi, dan saya tidak menggunakan tipe data integer karena telepon ini tidak untuk proses penjumlahan data. f. Kolom Password_user diberikan tipe data Char(10), kenapa bukan tipe data int , karena password bukan untuk penjumlahan maupun pengurangan. 2. Tabel Kelas Tabel 3.Tabel Kelas N Field Type Size Constraint o Data 1 8 Id_Kela Char Primary Key, Not s null 2 Id_Jurus Char 4 Foreign Key, Not an Null, update cascade, delete cascade 3 Nama_ Varch 30 Not Null Kelas ar Penjelasan untuk tabel 3 adalah sebagai berikut : 1. Kolom Id_kelas diberikan tipe data char(8), karena seluruh id ditetapkan dengan format 8 karakter. 2. Kolom Nama Kelas diberikan tipe data varchar(30), karena nama kelas yang diambil setiap siswa berbeda-beda.Pemberian jumlah karakter untuk lebih menghemat space database 3. Tabel Jurusan Tabel 4.Tabel Jurusan No Field Type Size Constraint Data 1 Id_Juru Char 4 Primary Key, Not san null 2 Nama_J Char 1 Not Null, CHECK, urusan only 1/2/3/4/5/6 Penjelasan untuk tabel 4 adalah sebagai berikut : 1. Kolom Id_Jurusan diberikan tipe data char(4), karena seluruh id jurusan ditetapkan dengan format 10 karakter 2. Kolom Nama_jurusan diberikan tipe data Char(1), karena nama jurusan alternative nilai batasannya sudah ditentukan, serta untuk penghematan memori. 4. Tabel Mata Pelajaran Tabel 5.Tabel Mata Pelajaran No Field Type Size Constraint Data 1 Id_Ma Char 8 Primary Key,Not pel null 2 Nama_ Varch 30 Not Null Mapel ar Penjelasan untuk tabel 5 adalah sebagai berikut : 1. Kolom Id_Mapel diberikan tipe data char(8), karena seluruh id maple ditetapkan dengan format 8 karakter


ISSN : 2302-3805


2.

Kolom Nama_Mapel diberikan tipe data varchar(30) untuk lebih menghemat memori 5. Tabel Mengajar Tabel 6.Tabel Mengajar No Field Type Siz Constraint Data e 1 Id_Me Char 8 Primary Key, Not ngajar null 2 NIP Char 25 Foreign Key, Not null, update cascade, delete no action 3 Id_Ma Char 8 Foreign Key, Not pel Null, update cascade, delete no action Penjelasan untuk tabel 6 adalah sebagai berikut : 1. Kolom Id_Mengajar diberikan tipe data Char(8) karena seluruh id mengajar ditetapkan dengan format 8 karakter. 6. Tabel Jam Tabel 7.Tabel Jam No Field Type Size Constraint Data 1 JamKe Char 1 Primary Key, Not null 2 JamA Char 1 Not Null, CHECK, wal only 1/2/3/4/5/6/7/8/9 3 JamAk Char 1 Not Null, CHECK, hir only 1/2/3/4/5/6/7/8/9 Penjelasan untuk tabel 7 adalah sebagai berikut : 1. Kolom JamKe, jamawal, jamakhir diberikan tipe data char(1) karena telah ditetapkan dengan format 1, kenapa tidak menggunakan tipe data integer karena jamke ini tidak digunakan untuk penjumlahan maupun pengurangan, serta untuk lebih menghemat space. 7. Tabel Hari Tabel 8.Tabel Hari No Field Type Size Constraint Data 1 Nama_ Char 1 Primary Key, Not hari null 2 Status Char 1 Not Null 3 Urut Char 1 Not Null Penjelasan untuk tabel 8 adalah sebagai berikut : 1. Kolom Nama_hari, status dan urut diberikan tipe data char(1) karena sudah ditentukan formatnya serta untuk menghemat memori. 8. Tabel Setting Tabel 9.Tabel Setting No Field Type Size Constraint Data 1 Jammaksimals Char 1 Not Null ehari 2 Batasajar Char 1 Not Null

1.1-8

Penjelasan untuk tabel 9 adalah sebagai berikut : 1. Kolom jammaksimalsehari dan batasajar bertipe char(1) karena hanya bisa menginputkan satu karakter saja, kenapa tidak menggunakan tipe data integer karena bukan untuk perhitungan angka, serta untuk penghematan memori.. 9. Tabel Jadwal Tabel 10.Tabel Jadwal No Field Type Si Constraint Data ze 1 Id_M Char 8 Foreign key, Not null, engaj update cascade, delete ar no action 2 Id_Ke Char 8 Foreign key,Not null, las update cascade, delete no action 3 Hari Char 1 Foreign key, Not null, update cascade, delete no action 4 Jam Char 1 Foreign key, Not null, update cascade, delete no action 5 Tahun Char 9 Not Null Ajara n 6 Seme Char 2 Not Null ster Penjelasan untuk tabel 10 adalah sebagai berikut : 1. Kolom Tahun Ajaran diberikan tipe data char(9), karena sudah di tentukan formatnya 9. 2. Kolom Semester diberikan tipe data char(1), karena sudah di tentukan formatnya, serta untuk lebih menghemat memori. 1.6 Kodefikasi Kodefikasi dapat dilakukan dengan membuat store procedure pada database. Seperti yang terlihat pada contoh dibawah ini adalah sebagai berikut : 1. Id_Kelas Keterangan : xxxx- KLS00001 a. Digit pertama diawali dengan huruf K meunjukkan bahwa K merupakan Kode kelas b. Digit terakhir menunjukkan nomer urut kode kelas 1.7 Pengecekan Constraint Definisi tabel yang dapat digunakan untuk menjaga integritas dari data disebut dengan constraint, dimana constraints akan mendefinisikan aturan terhadap suatu kolom dalam tabel[5]. Jika didefinisikan On Update Cascade, maka pengeditan tidak diijinkan dan ON delete No Action, maka penghapusan tidak diijinkan[4]. Jika terpaksa diinginkan pengubahan/penghapusan pada tabel induk yang sudah dirujuk dengan foreign key yang didefinisikan dengan On Update Cascade On Delete No Action, maka sebelum penghapusan/pengubahan, data terkait pada


ISSN : 2302-3805


tabel yang ada foreign keynya tersebut harus dihapus terlebih dahulu[4]. Berikut adalah pengetesan yang dilakukan pada database penjadwalan, sebagai berikut [3]: 1. Tabel Guru Pada gambar 3 pembuatan check constraint yang digunakan pada tabel guru berisi : (a) Tanggal lahir harus lebih kecil atau sama dengan dari tanggal saat ini (b) Agama yang berisi 1 untuk Islam, 2 untuk Kisten Proestan, 3 untuk Katolik, 4 untuk Hindu, 5 untuk Budha dan 6 untuk Kong Hu Chu (c) Status nikah hanya berisi 1 untuk belum menikah, 2 untuk menikah, 3 untuk janda dan 4 untuk duda (d) Jenis kelamin hanya berisi L untuk laki-laki dan P untuk perempuan (e) Jenjang_pendidikan berisi 1 untuk SMA/SMK, 2 untuk D1, 3 untuk D3, 4 untuk S1, 5 untuk S2, 6 untuk S3 (f) Jurusan_guru berisi 1 untuk Ekonomi, 2 untuk Administrasi, 3 untuk Olahraga, 4 untuk Bahasa, 5 untuk Komputer, 6 untuk Matematika, 7 untuk Agama, 8 untuk Sejarah, 9 untuk Manajemen dan 10 untuk Akuntansi (g) Status pegawai berisi 1 untuk PNS, 2 untuk guru tidak tetap/GTT, Y untuk guru tetap yayasan/GTY (h) Golongan berisi 1 untuk IIIa, 2 untuk IIIb, 3 untuk IIIc, 4 untuk IIId, 5 untuk VIa, 6 untuk IVb, 7 untuk IVc, 8 untuk IVd, 9 untuk IVe, 10 untuk Honor, 11 untuk Kontrak (i) Pangkat berisi 1 untuk Penata Muda, 2 untuk Penata Muda Tingkat 1, 3 untuk Penata, 4 untuk E untuk Penata Tingkat 1, 5 untuk Pembina, 6 untuk Pembina Tingkat 1, 7 untuk Pembina Utama, 8 untuk Pembina Utama Madya (j) Jabatan berisi 1 untuk Kepala Sekolah, 2 untuk Wakasek, 3 untuk Waka 1, 4 untuk Waka 2, 5 untuk Waka 3, 6 untuk Waka 4, 7 untuk Humas, 8 untuk Staff Waka Kurikulum, 9 untuk Pembina OSIS, 10 untuk Kaprog Pemasaran, 11 untuk Kaprog Perkantoran, 12 untuk Guru (k) Status petugas berisi 1 untuk Admin, 0 untuk Guru

Gambar 3.Pembuatan CHECK Constraint tabel guru Pada gambar 4 pengetesan dilakukan dengan menambahkan satu record pada tabel guru dan memasukkan data Agama 7 yang menyalahi persyaratan constraint, sebab di add constraint check tidak terdapat pilihan 7. Gambar 4.Pengetesan check constraint di tabel guru Hasil dari pengetesan tabel guru ternyata muncul pesan error yang berisi bahwa data yang dimasukkan. 2. Tabel Jurusan Pada gambar 12 penggunaan CHECK Constraint yang digunakan pada tabel jurusan yang berisi 1 untuk jurusan Administrasi, 2 untuk jurusan Perkantoran, 3 untuk jurusan Manajemen Pemasaran, 4 untuk Jurusan Teknik

1.1-9

Jaringan, 5 untuk jurusan Teknik Sepeda Motor, 6 untuk Busana Butik

Gambar 5.Pembuatan CHECK Constraint di tabel jurusan Pada gambar 6 pengetesan dilakukan dengan menambahkan satu record pada tabel jurusan dan memasukkan data nama jurusan 7 yang menyalahi persyaratan constraint, karena tidak terdapat pada pilihan.

Gambar 6.Pengetesan CHECK Conctraint tabel jurusan Hasil dari pengetesan tabel jurusan ternyata muncul pesan error yang berisi bahwa data yang dimasukkan tidak sesuai dengan constraint yang ditetapkan. 3. Tabel Kelas Pada Gambar 7 Constraint yang digunakan pada tabel kelas adalah saat terjadinya perubahan data pada kolom id kelas dan id_jurusan di tabel asal, maka data di tabel kelas akan selalu menyesuaikan dengan tabel jurusan sedangkan jika terjadi penghapusan data pada tabel jurusan maka tidak akan diizinkan.

Gambar 7.Data Awal Tabel Jurusan dan Tabel Kelas Pada Gambar 8 Pengetesan dilakukan dengan melakukan perubahan id jurusan JU01 menjadi JU07 dan Nama jurusannya menjadi 3

Gambar 8.Hasil Pengetesan Update Cascade Tabel Kelas Dari hasil pengetesan yang telah dilakukan pada id_jurusan pada tabel jurusan adalah terjadi perubahan data juga pada tabel kelas. Pada gambar 9 pengetesan dilakukan dengan menghapus data pada tabel jurusan yang dipakai pada tabel kelas adalah data dengan id JU07.

Gambar 9.Hasil Pengetesan Delete No Action Tabel Kelas Dari hasil pengetesan setelah dilakukan penghapusan data JU07, maka muncullah pesan yang menyatakan


ISSN : 2302-3805


bahwa data tersebut tidak dapat dihapus karena data terdaftar pada tabel kelas. 4. Tabel Mengajar Pada gambar 10 Constraint yang digunakan pada tabel mengajar adalah saat terjadinya perubahan data pada kolom id mapel di tabel asal, data di tabel mengajar ini akan selalu menyesuaikan dengan apa yang ada di tabel tersebut jika terjadi penghapusan data pada tabel asal maka tidak akan diizinkan.

Gambar 10.Data Awal Tabel Guru, Mapel dan Mengejar Pada gambar 11 dari hasil pengetesan dilakukan dengan perubahan id mapel MPB00001 pada tabel mapel menjadi MPB00005 dan nama mapel menjadi Fisika.

Gambar 11.Hasil Pengetesan Update Cascade Tabel Mengajar Dari hasil pengetesan setelah dilakukan perubahan id mapel pada tabel mapel adalah terjadinya perubahan data juga pada tabel mengajar. Maka pengetesan constraint update cascade sudah selesai. Pada gambar 12 pengetesan dilakukan dengan menghapus data pada tabel maple yang sedang dipakai pada tabel mengajar yaitu dengan id maple MPB0005.

Gambar 13.Pembuatan CHECK Constraint tabel jam Pada gambar 14 pengetesan dilakukan dengan menambahkan satu record pada tabel jam dan memasukkan data jam terakhir 0 yang menyalahi persyaratan constraint.

Gambar 14.Pengetesan CHECK Constraint tabel jam Hasil dari pengetesan tabel jam ternyata muncul pesan error yang berisi bahwa data yang dimasukkan tidak sesuai dengan constraint yang ditetapkan yaitu 1,2,3,4,5,6,7,8,9 6. Tabel Hari Pada gambar 15 penambahan check constraint yang digunakan pada tabel hari berisi : (a) Status yang berisi S untuk Senin, A untuk Selasa, R untuk Rabu, K untuk K, J untuk Jumat, U untuk Sabtu.

Gambar 15. Pembuatan CHECK Constraint Tabel Hari Pada gambar 16 pengetesan dilakukan dengan menambahkan satu record pada tabel hari dan memasukkan data hari adalah 7 yang menyalahi persyaratan constraint.

Gambar 16.Pengetesan CHECK Constraint tabel hari Hasil dari pengetesan tabel hari ternyata muncul pesan error yang berisi bahwa data yang dimasukkan tidak sesuai dengan constraint yang ditetapkan yaitu 1,2,3,4,5,6 sedangkan hari ke 7 tidak terdaftar. 4. Kesimpulan Dengan demikian dari hasil evaluasi yang dilakukan oleh penulis, maka dengan menggunakan pembatasan pada tipe data dan check constraint pada database sebelum membuat aplikasi, akan lebih aman daripada saat pembuatan aplikasi. Daftar Pustaka

Gambar 12.Hasil Pengetesan Delete No Action Tabel

[1] Herjanto, Eddy. Manajemen Operasi : Edisi Ketiga. Penerbit PT

Dari hasil pengetesan tabel setelah dilakukan penghapusan pada MPB0005 maka akan muncul pesan yang menunjukkan bahwa data tersebut tidak dapat dihapus karena terdaftar pada tabel mengajar. Maka pengetesan dari constraint delete no action sudah selesai dilakukan. 5. Tabel Jam Pada gambar 13 tentang pembuatan check constraint yang digunakan pada tabel jam berisi : (a) JamAwal yang berisi 1 untuk jam 06.50, 2 untuk 07.35, 3 untuk 08.20, 4 untuk 09.05,5 untuk 10.05,6 untuk 10.50, 7 untuk 11.35,8 untuk 12.40,9 untuk 13.50 (b) JamAkhir yang berisi 1 untuk jam 07.35, 2 untuk 08.20, 3 untuk 09.05, 4 untuk 09.50,5 untuk 10.50,6 untuk 11.35, 7 untuk 12.20,8 untuk 13.50,9 untuk 15.00.

1.11010

[2] H.Muhamad.2009. “Aplikasi Pengolahan Data Penjadwalan Mengajar SMK Muhammadiyah Palembang Menggunakan Program Borland Delphi 7.0”. In Skripsi. STMIK Palcom Tech Palembang [3] Ikmah, 2014. “Analisis dan Perancangan Sistem Informasi Penjadwalan Guru Di SMK YPE Sawunggalih Kutoarjo,” In Skripsi. STMIK AMIKOM Yogyakarta. [4] Kusrini, 2006. Strategi Perancangan dan Pengelolaan Basis Data. Yogyakarta. Penerbit ANDI. [5] Raharjo, Suwanto. “Constraint Basis Data Sebagai Fondasi Yang Kuat Dalam Pengembangan Sistem Informasi,” in Proc. Semnas Aplikasi Sains & Teknologi(SNAT) Periode III Yogyakarta, pp 61., November, 2012.

Biodata Penulis Ikmah, memperoleh gelar Sarjana Komputer (S.Kom), Jurusan Sistem Informasi STMIK AMIKOM Yogyakarta, lulus tahun 2014. Saat ini menjadi Mahasiswa Magister Teknik Informatika di STMIK AMIKOM Yogyakarta.

PERENCANAAN BASIS DATA SISTEM INFORMASI PENJADWALAN SEKOLAH

Recommend Documents