BAB IV REKAYASA ULANG BASISDATA Pada Bab 4 ini dibuat rancangan untuk sistem baru yang dinamakan Facis. Facis ini merupakan hasil rekayasa ulang dari sistem lama (Simak). Hasil rekayasa ulang meliputi program, data dan dokumentasi. Namun pada tesis ini akan dibahas hanya pada sisi basisdatanya saja.
Data merupakan suatu informasi yang sangat penting untuk sebuah sistem, salah satunya karena terkait dengan pengambilan keputusan. Di dalam sebuah sistem, data biasanya disimpan dalam bentuk tertentu. Seperti yang telah dijelaskan di bab sebelumnya, untuk Simak, data disimpan dalam bentuk file (DBF File) dan diolah dengan program. Data yang ada di Simak tidak dimasukkan ke dalam lingkungan DMBS tertentu, seperti MySQL atau Oracle, serta ditemukan beberapa “smells” yang berpengaruh pada performansi dan kualitas data yang ada di Simak.
Berdasarkan Simak ini dirancang sebuah sistem baru yaitu Facis yang diharapkan akan memberikan peningkatan fungsionalitas tertentu melalui restrukturisasi data yang ada di Simak tersebut. Basisdata yang digunakan di Facis akan mengikuti kaidah basisdata relasional dan dimasukkan ke dalam lingkungan DBMS MySQL. Dengan tidak menghilangkan fitur utama yang ada di Simak serta adanya peningkatan fungsionalitas, semua data yang ada di Simak dikonversi (data convertion) dan dimasukkan (data migration) ke dalam Basisdata baru yang telah dibuat. Sebelum dilakukan rekayasa ulang basisdata Simak ini, ada beberapa batasan yang jelas seperti yang telah dikemukakan di Bab 1.
IV.1 Restrukturisasi Berdasarkan Hasil Deteksi Smell Dari hasil deteksi smell Simak di Bab 3 terdapat beberapa smell yang akan diperbaiki berdasarkan kategori database smell.
45
IV.1.1 Data Redundan Berdasarkan analisa struktur data Simak, Beberapa kolom yang berisikan informasi dari tabel tertentu muncul di tabel yang lain seperti yang digambarkan di tabel 3.2. Hal ini memungkinkan untuk terjadinya data yang redundan. Langkah-langkah restrukturisasi untuk data redundan adalah: 1. Analisa kolom; yaitu melakukan memeriksa kolom yang diidentifikasi sebagai data redundan dengan melihat kebergantungan fungsional (functional dependency) dari tiap-tiap kolom yang sesuai. 2. Hapus kolom; yaitu menghilangkan kolom redundan yang tidak ada kebergantungan fungsional terhadap kolom indeks (primary key) yang ada di tabel tersebut. 3. Buat tabel baru; yaitu jika kolom tersebut sama sekali belum memiliki kolom indeks yang sesuai di tabel manapun, maka buat tabel baru sehingga kolom memiliki kebergantungan fungsional yang independen. Berikut ini adalah restrukturisasi yang dilakukan di Simak berdasarkan Tabel III-2 Kasus Data Redundan 1: Tabel IV-1 Kasus data redundan 1
No Kolom/Informasi Tabel Frekuensi 1 NAMA Mhs_XXX, 3 TRANSKRIP_XXX, KHS_XXX Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA muncul di tiga tabel yaitu MHS, TRANSKRIP dan KHS. Berdasarkan deskripsi yang dijelaskan di Tabel III-1, kolom NAMA ini merupakan bagian dari atribut Mahasiswa, sehingga kebergantungan fungsional kolom ini hanya dengan kolom NIM yang merupakan kolom indeks dari tabel MHS. Tabel MHS merupakan entitas dari objek Mahasiswa, sedangkan tabel TRANSKRIP dan KHS merupakan tabel transaksi antar beberapa entitas. MHS NIM
NAMA
KHS NIM
NAMA
NIPPA
NAMAPA
46
MK1
.....
TRANSKRIP NIM
NAMA
TPT_LAHIR
TGL_LAHIR
MK1
.....
2. Dari hasil analisa di atas maka kolom NAMA ini akan dihapus dari tabel TRANSKRIP dan KHS. Sehingga tabel akhir MHS, TRANSKRIP dan KHS sementara menjadi: MHS NIM
NAMA
KHS NIM
NIPPA
NAMAPA
MK1
.....
TRANSKRIP NIM
TPT_LAHIR
TGL_LAHIR
MK1
.....
Kasus Data Redundan 2: Tabel IV-2 Kasus data redundan 2
No Kolom/Informasi Tabel Frekuensi 1 NAMA, Dosen_D3, 2 NAMAPA KHS_XXX Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA atau NAMAPA muncul di dua tabel yaitu DOSEN_D3 dan KHS. Berdasarkan deskripsi yang dijelaskan di Tabel III-1, kolom NAMA atau NAMAPA ini merupakan bagian dari atribut DOSEN, sehingga kebergantungan fungsional kolom ini hanya dengan kolom NIP yang merupakan kolom indeks dari tabel DOSEN_D3. Tabel DOSEN_D3 merupakan entitas dari objek Dosen, sedangkan tabel KHS merupakan tabel transaksi antar beberapa entitas. DOSEN NIP
NAMA
JUR
KHS NIM
NAMA
NIPPA
NAMAPA
47
MK1
.....
2. Dari hasil analisa di atas maka kolom NAMA ini akan dihapus dari tabel TRANSKRIP dan KHS. 3. Karena Dosen memiliki relasi dengan Mahasiswa yaitu satu Dosen dapat membimbing n mahasiswa, maka kolom NIPPA di tabel KHS sebaiknya berada di tabel Mahasiswa, sehingga kolom NIPPA akan dipindahkan ke tabel Mahasiswa.
Gambar IV-1 Relasi Dosen dengan Mahasiswa
Sehingga tabel akhir sementara dari tabel Dosen dan KHS adalah: DOSEN NIP
NAMA
JUR
MK1
KMK1
KHS NIM
NMK1
.....
Kasus Data Redundan 3: Tabel IV-3 Kasus data redundan 3 No
Kolom/Informasi
Tabel
Frekuensi
1
NAMA_MK
MK_XXX
2
NMKX
KHS_XXX
Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA_MK atau NMK muncul di dua tabel yaitu tabel MK dan KHS. Berdasarkan deskripsi yang dijelaskan di Tabel III-1, kolom NAMA_MK atau NMK ini merupakan bagian dari atribut Matakuliah, sehingga kebergantungan fungsional kolom ini hanya dengan kolom KODE_KOM yang merupakan kolom indeks dari tabel MK. Tabel MK merupakan entitas dari objek Matakuliah, sedangkan tabel KHS merupakan tabel transaksi antar beberapa entitas. F = {KODE_KOMÆKODE_MK, NAMA_MK, SKS, Semester, Prasyarat} MK KODE_KOM
KODE_MK
NAMA_MK
48
SKS
SEMESTER
PRASYARAT
KHS NIM
MK1
KMK1
NMK1
.....
Dengan demikian kolom NMK akan dihapus dari tabel KHS, sehingga tabel KHS sementara akan menjadi: KHS NIM
MK1
KMK1
SKS1
.....
2. Berdasarkan analisa pada tabel MK, diidentifikasi kemungkinan akan terjadi kolom yang kosong (null) yaitu pada kolom PRASYARAT. Kolom Prasyarat ini berisikan informasi mengenai matakuliah prasyarat yang harus dipenuhi oleh mahasiswa sebelum mengambil matakuliah tersebut. Namun tidak semua matakuliah memiliki prasyarat, dan satu matakuliah bisa memiliki lebih dari satu prasyarat.
Gambar IV-2 Relasi Matakuliah dengan MKPrasyarat
Dengan demikian tabel MK akan direstrukturisasi dengan meletakkan kolom Prasyarat pada tabel yang terpisah. F = {KODE_KOMÆKODE_MK, NAMA_MK, SKS, Semester} MK KODE_KOM
KODE_MK
NAMA_MK
SKS
SEMESTER
MKPrasyarat KODE_KOM
PRASYARAT
IV.1.2 Tabel yang memiliki terlalu banyak kolom Dengan memperhatikan kolom-kolom yang ada di tabel KRS, KHS dan TRANSKRIP, terlihat ada beberapa kolom yang sebenarnya bergantung kepada kolom tertentu saja sehingga menyebabkan kolom tersebut harus berada pada tabel yang sesuai.
49
Langkah-langkah restrukturisasi untuk tabel tang memilik terlalu banyak kolom ini adalah: 1. Analisa tabel; yaitu periksa tabel apakah benar-benar memiliki kolom yang tidak sesuai dengan tempatnya sehingga memiliki terlalu banyak kolom. 2. Analisa kolom; yaitu memeriksa kolom-kolom yang tidak sesuai berada di tabel tersebut berdasarkan kebergantungan fungsional yang dimilikinya. 3. Hapus/pindahkan kolom; yaitu hapus atau pindahkan kolom yang diidentifikasi tidak memiliki kebergantungan fungsional di tabel tersebut, dan letakkan kolom-kolom itu ke tabel lain yang sesuai atau memiliki kebergantungan fungsional yang lebih tepat. 4. Buat tabel baru; yaitu jika kolom tersebut sama sekali belum memiliki kolom indeks yang sesuai di tabel manapun, maka buat tabel baru sehingga kolom memiliki kebergantungan fungsional yang independen.
Berdasarkan deskripsi yang telah diberikan di Tabel III-3 maka proses restrukturisasi dapat dibagi dengan 3 kasus, yaitu: 1. Kasus Tabel KRS 2. Kasus Tabel KHS 3. Kasus Tabel TRANSKRIP
Kasus tabel KRS Berdasarkan hasil analisa dan restrukturisasi sebelumnya, diperoleh tabel KRS sebagai berikut: KRS NIM
MK1
MK2
MK3
.....
MK16
Langkah-langkah restrukturisasi: 1. Pada Simak jumlah matakuliah yang diambil oleh satu mahasiswa dalam satu semester diasumsikan paling banyak 16 matakuliah, sehingga jumlah kolom matakuliah di tabel KRS menjadi sebanyak 16 kolom. Hal ini tidak mengikuti kaidah basisdata relasional dan akan menemui kesulitan dan pengaksesan data tersebut. Sesuai dengan kaidah basisdata relasional dan
50
aturan perkuliahan, maka 1 mahasiswa dapat mengambilkan beberapa (n) matakuliah, seperti yang digambarkan dengan ERD di bawah ini:
Gambar IV-3 Relasi Mahasiswa dengan Matakuliah
sehingga kolom matakuliah pada tabel KRS hanya cukup 1 (satu) saja yang diwakili oleh KODE_KOM sebagai kolom indeks tabel Matakuliah. F = {KODE_KOMÆKODE_MK, NAMA_MK, SKS, Semester, Prasyarat} KRS NIM
KODE_KOM
2. Tabel KRS di Simak dibagi dalam beberapa file tabel sesuai tahun akademik, semester dan jurusan, dengan demikian tahun akademik, semester dan jurusan akan dijadikan kolom di dalam tabel KRS, sehingga tabel KRS sementara akan menjadi: KRS TahunAkademik
Semester
Jurusan
NIM
KODE_KOM
namun trade-off dari itu adalah akan terjadi penambahan jumlah baris yang signifikan pada tiap-tiap semester. Hal ini dapat diatasi dengan menambahkan kolom indeks yang akan dilakukan pada subbab berikutnya.
Kasus tabel KHS Berdasarkan hasil restrukturisasi sebelumnya, diperoleh tabel KHS sebagai berikut: KHS NIM
MK1
KMK1
NMK1
SKS1
NA1
.....
Langkah-langkah restrukturisasi: 1. Untuk relasi Mahasiswa dengan Matakuliah pada saat pengambilan matakuliah, ada 2 (dua) kolom yang dijadikan indeks yaitu MK dan KMK. MK adalah kode komputer dari tiap-tiap matakuliah yang dulunya digunakan untuk kode pada saat scanning KHS dengan OMR. Sedangkan KMK merupakan kode tiap-tiap matakuliah. Di Facis ini akan tetap 51
digunakan kode komputer sebagai kolom indeks dari tabel matakuliah, sedangkan kolom kode matakuliah dan kolom matakuliah lainnya akan tetap bergantung pada kolom indeks tersebut. F = {KODE_KOMÆKODE_MK, NAMA_MK, SKS, Semester, Prasyarat} Dengan demikian kolom KMK, NMK, dan SKS akan dihapus dari tabel KHS. 2. Jumlah kolom matakuliah di tabel KHS ini dibuat dengan langsung menentukan jumlah matakuliah yang diambil oleh mahasiswa dalam satu semester, dalam hal ini ada 16 matakuliah. Dengan demikian dengan kaidah basisdata relasional, maka di Facis akan dibuat hubungan di relasi KHS cukup dengan satu Kode_Kom saja, namun trade-off dari itu adalah akan terjadi penambahan jumlah baris yang signifikan pada tiap-tiap semester. Hal ini dapat diatasi dengan menambahkan kolom indeks yang akan dilakukan pada subbab berikutnya. 3. JUMSKS, IP, JMK dapat dihilangkan, karena informasi-informasi ini akan diletakkan di tabel terpisah yaitu tabel statusKRS. StatusKRS TahunAkademik
Semester
NIM
JumlahSKS
4. NA dapat dipindahkan ke tabel baru sebagai tabel referensi. NilaiHuruf NilaiHuruf
NilaiAngka
5. Pada Simak dilakukan pembagian tabel dalam beberapa file berdasarkan tahun akademik, semester dan jurusan, hal ini tidak akan dilakukan di Facis sehingga data tahun akademik, semester dan jurusan menjadi kolom di tabel tersebut. Tabel akhir sementara yang diperoleh untuk KHS adalah sebagai berikut: KHS TahunAkademik
Semester
Jurusan
NIM
KODE_KOM
NH
JUMNK
Kasus tabel TRANSKRIP Berdasarkan hasil restrukturisasi sebelumnya, diperoleh tabel Transkrip sebagai berikut:
52
TRANSKRIP NIM
TPT_LAHIR
TGL_LAHIR
MK1
NH1
MK2
NH2
.....
Langkah-langkah restrukturisasi: 1. Kolom
TPT_LAHIR dan TGL_LAHIR yang terdapat di tabel
TRANSKRIP akan dipindahkan ke tabel MHS, karena kedua kolom ini merupakan bagian dari entitas Mahasiswa yang memiliki kebergantungan fungsional terhadap kolom NIM yang ada di tabel MHS, sehingga cukup kolom NIM saja yang ada di tabel Transkrip sebagai foreign key ke tabel MHS. F = {NIMÆTPT_LAHIR, TGL_LAHIR} MHS NIM
NIPPA
NAMA
TPT_LAHIR
TGL_LAHIR
TRANSKRIP NIM
MK1
NH1
MK2
NH2
.....
2. Merujuk ke deskripsi tabel Transkrip, yaitu data yang berisikan kumpulan nilai-nilai akademik mahasiswa selama studi serta seluruh informasi mengenai kelulusannya yang diterbitkan dalam bentuk laporan atau dokumen. Dikarenakan data nilai-nilai mahasiswa tersebut telah ada di tabel KHS, maka tabel Transkrip cukup merujuk ke tabel KHS untuk mengambil data nilai-nilai mahasiswa tersebut, sehingga kolom-kolom yang ada di tabel Transkrip cukup berisikan informasi mengenai TanggalYudisium, JudulTA, Predikat, NomorIjazah, TanggalLulus dan BidangIlmu yang telah ada sebelumnya di tabel Transkrip. Dengan demikian tabel Transkrip sementara akan menjadi: TRANSKRIP NIM
TGLYUDIS
JUDULTA
PREDIKAT
NOIJAZAH
TGLLULUS
BIDILMU
STRATA
IV.1.3 Tabel yang memiliki terlalu banyak baris Berdasarkan hasil restrukturisasi sebelumnya, maka terdapat trade-off yang muncul akibat dari restrukturisasi tabel yang memiliki terlalu banyak kolom yaitu terjadi kemungkinan penambahan baris yang signifikan pada tiap-tiap tabelnya. 53
Secara sederhana Tabel IV-4 di bawah ini menunjukkan seberapa besar penambahan baris pada tiap-tiap tabel pada kurun waktu tertentu. Tabel IV-4 Hasil deteksi banyak baris
No
Nama Tabel
Jumlah kolom
1
KRS
5
2
KHS
7
3
TRANSKRIP
8
Prediksi Penambahan ± 3x80x10 = 2400 baris / semester ± 3x80x10 = 2400 baris / semester ± 3x80 = 240 baris / tahun
Kemungkinan terjadi banyak baris Ya Ya Tidak
Di dalam DBMS MySQL yang akan digunakan nanti memang memiliki kehandalan yaitu dapat menyimpan baris yang sangat besar dalam satu tabel, namun dalam pengaksesan data di tabel tersebut akan menjadi lebih lambat. Untuk itu maka tabel-tabel tersebut akan direstrukturisasi sehingga masalah tabel yang memiliki terlalu banyak baris dapat diatasi. Adapun langkah-langkah yang dilakukan untuk restrukturisasi tabel yang memiliki terlalu banyak baris yaitu: 1. Berdasarkan tabel 4.4 di atas dapat diidentifikasi tabel yang kemungkinan memiliki baris yang terlalu banyak yaitu KRS, KHS dan TRANSKRIP. 2. Berdasarkan analisa yang dilakukan di ketiga tabel tersebut, diperoleh atribut-atribut yang dapat dijadikan sebagai kolom indeks yaitu TahunAkademik, Semester dan Jurusan. KRS TahunAkademik
Semester
Jurusan
NIM
Semester
Jurusan
NIM
KODE_KOM
KHS TahunAkademik
KODE_KOM
NH
JUMNK
IV.2 Restrukturisasi Berdasarkan Kebutuhan Fungsional dan Non Fungsional Berdasarkan kebutuhan fungsional dan non fungsional yang terdapat di bab sebelumnya, maka akan dilakukan restrukturisasi terhadap tabel-tabel yang telah
54
terbentuk di subbab sebelumnya. Berikut ini adalah struktur data yang sementara telah terbentuk hasil restrukturisasi yang dilakukan sebelumnya. Tabel Dosen DOSEN NIP
JUR
NAMA
Tabel Matakuliah (MK) MK KODE_KOM
KODE_MK
NAMA_MK
SKS
SEMESTER
Tabel Matakuliah Prasyarat(MKPrasyarat) MKPrasyarat KODE_KOM
PRASYARAT
Tabel Mahasiswa (MHS) MHS NIM
NIPPA
NAMA
TPT_LAHIR
TGL_LAHIR
TahunMasuk
Tabel KRS KRS TahunAkademik
Semester
Jurusan
NIM
Semester
Jurusan
NIM
JUDULTA
PREDIKAT
Semester
NIM
KODE_KOM
Tabel KHS KHS TahunAkademik
KODE_KOM
NH
JUMNK
Tabel TRANSKRIP TRANSKRIP NIM
TGLYUDIS
NOIJAZAH
Tabel Status KRS StatusKRS TahunAkademik
JumlahSKS
55
TGLLULUS
BIDILMU
STRATA
Tabel IP Semester Mahasiswa KHSKumulatif TahunAkademik
Semester
NIM
IPSemester
SKSDepan
Tabel NilaiHuruf NilaiHuruf NilaiHuruf
NilaiAngka
IV.2.1 Restrukturisasi Berdasarkan Kebutuhan Fungsional Secara umum tidak ada penambahan fitur di dalam Facis restrukturisasi berdasarkan kebutuhan fungsional tidak begitu banyak, hanya saja karena Facis ini akan dikembangkan secara online dan peran tiap-tiap role lebih diaktifkan, sehingga kebutuhan fungsional dengan kode FCS02 yaitu Pembimbing Akademik dapat melakukan persetujuan KRS yang dilakukan Mahasiswa secara online. Tabel KRS ini juga menangani untuk KPRS. Dengan demikian akan ditambahkan kolom StatusAmbil di tabel KRS dan penambahan kolom Status dan DisetujuiPA di tabel persetujuan oleh Pembimbing Akademik (StatusKRS). KRS TahunAkademik
Semester
Jurusan
NIM
KODE_KOM
Semester
Jurusan
NIM
JumlahSKS
StatusAmbil
StatusKRS TahunAkademik
Status
DisetujuiPA
Keterangan: -
Kolom JumlahSKS di tabel StatusKRS akan berisikan informasi mengenai jumlah SKS yang diambil Mahasiswa di tahun akademik dan semester tersebut.
-
Kolom Status di tabel StatusKRS akan berisikan informasi mengenai status KRS atau KPRS
-
Kolom DisetujuiPA bernilai boolean yang berisikan konfirmasi persetujuan Dosen PA.
56
IV.2.2 Restrukturisasi Berdasarkan Kebutuhan Non Fungsional Berdasarkan peningkatan kebutuhan non fungsional, maka tahapan restrukturisasi selanjutnya dapat dilakukan sesuai dengan kebutuhan fungsional yang memungkinkan perlu dilakukan restrukturisasi data. 1. Sistem yang berbasiskan web (web based) (FCS07). Berdasarkan kebutuhan non fungsional ini maka Facis memerlukan autentikasi terhadap setiap role yang akan mengakses sistem, dengan demikian setiap role akan diberikan UserName dan Password sebagai kolom autentikasinya yang akan diletakkan dalam satu tabel terpisah, namun tetap ada foreign key yang akan merujuk ke tiap-tiap tabel role. User UserName
Password
RoleID
Role RoleID
NamaRole
DOSEN NIP
JUR
UserName
NAMA
MHS NIM
UserName
NIPPA
NAMA
TPT_LAHIR
TGL_LAHIR
2. Kemungkinan Facis ini akan dikembangkan ke tingkat universitas (FCS11). Berdasarkan kebutuhan non fungsional ini, maka akan perlu penambahan informasi mengenai Fakultas dan Jurusan serta Operator tiap-tiap jurusan. Dengan demikian perlu dibuat tabel Fakultas, Jurusan dan Operator, sehingga pada tabel-tabel yang sudah ada yang memiliki kolom Jurusan akan merujuk pada tabel Jurusan dengan menggunakan foreign key. Kemudian akan ditambahkan kolom tahun masuk mahasiswa di tabel MHS sebagai informasi terhadap angkatan tahun masuk mahasiswa per jurusan. Fakultas KodeFakultas
NamaFakultas
57
Jurusan KodeJurusan
KodeFakultas
NamaJurusan
Strata
MHS NIM
UserName
NIPPA
NAMA
TPT_LAHIR
TGL_LAHIR
TahunMasuk
Keterangan: -
Kolom Strata yang ada di tabel Jurusan akan berisikan informasi mengenai jenjang pendidikan yang ada di jurusan itu (D1, D3, S1), sehingga kolom Strata yang ada di tabel TRANSKRIP akan dihapus. Hal ini dilakukan karena Strata dianggap merupakan bagian dari atribut dari jurusan sehingga lebih tepat berada di entitas jurusan.
TRANSKRIP NIM
TGLYUDIS
JUDULTA
PREDIKAT
NOIJAZAH
TGLLULUS
BIDILMU
DOSEN NIP
KodeJurusan
UserName
NAMA
MK KODE_KOM
KODE_MK
KodeJurusan
NAMA_MK
SKS
SEMESTER
MHS NIM
KodeJurusan
UserName
NIPPA
NAMA
TPT_LAHIR
TGL_LAHIR
TahunMasuk
Kolom Jurusan pada tabel KRS dan KHS akan dihapus. Hal ini dilakukan karena kolom jurusan dapat dirujuk melalui tabel mahasiswa saja. KRS TahunAkademik
Semester
NIM
Semester
NIM
KODE_KOM
StatusAmbil
KHS TahunAkademik
KODE_KOM
NH
Operator OperatorID
KodeJurusan
UserName
58
NamaOperator
JUMNK
IV.3 Evaluasi Hasil Restrukturisasi Data Setelah restrukturisasi data dilakukan, maka akan dilakukan diperlukan perubahan terhadap penamaan (redefinition) tabel dan kolom sehingga dapat menambah kemudahan membaca dan kejelasan maknanya. Berikut ini adalah tabel-tabel yang telah terbentuk hasil restrukturisasi data di Simak serta perubahan nama tabel dan kolomnya. 1. Tabel Dosen Dosen_D3
NIP
UserName
KodeJurusan
Dosen
NIP
UserName
NAMA
KodeJurusan
NamaDosen
2. Tabel Mahasiswa MHS
NIM
KodeJurusan
Mahasiswa
NIM
UserName
UserName
KodeJurusan
NIPPA
NIP
NAMA
TPT_LAHIR
TGL_LAHIR
NamaMahasiswa
TempatLahir
UserName
NamaOperator
TahunMasuk
TanggalLahir
TahunMasuk
3. Tabel Operator Operator
OperatorID
KodeJurusan
4. Tabel Matakuliah MK
KODE_KOM
MataKuliah
KodeKomputer
KODE_MK
KodeJurusan
KodeMataKuliah
KodeJurusan
5. Tabel Matakuliah Prasyarat MKPrasyarat
KODE_KOM
MKPrasyarat
KodeKomputer
PRASYARAT Prasyarat
6. Tabel Fakultas Fakultas
KodeFakultas
NamaFakultas
59
NAMA_MK
SKS
SEMESTER
NamaMataKuliah
SKS
SemesterKe
7. Tabel Jurusan KodeJurusan
Jurusan
KodeFakultas
NamaJurusan
Strata
8. Tabel KRS KRS
TahunAkademik
Semester
NIM
KODE_KOM
StatusAmbil
KRS
TahunAkademik
Semester
NIM
KodeKomputer
StatusAmbil
9. Tabel StatusKRS StatusKRS
TahunAkademik
Semester
NIM
JumlahSKS
Status
DisetujuiPA
10. Tabel KHS KHS
TahunAkademik
Semester
NIM
KODE_KOM
KHS
TahunAkademik
Semester
NIM
KodeKomputer
NH
JUMNK
NilaiHuruf
NilaiKumulatif
11. Tabel KHSKumulatif TahunAkademik
KHSKumulatif
Semester
NIM
IPSemester
SKSDepan
12. Tabel Transkrip TRANSKRIP
NIM
TGLYUDIS
JUDULTA
Transkrip
NIM
TanggalYudisium
JudulTA
PREDIKAT
Predikat
13. Tabel NilaiHuruf NilaiHuruf
NilaiHuruf
NilaiAngka
14. Tabel User User
UserName
Password
RoleID
60
NOIJAZAH
TGLLULUS
NomorIjazah
TanggalLulus
BIDILMU
BidangIlmu
15. Tabel Role Role
RoleID
NamaRole
Keterangan: - Kolom pertama menunjukkan nama fisik tabel . - Baris pertama pada tiap-tiap tabel menunjukkan hasil restrukturisasi yang telah dilakukan sebelum melakukan redefinisi nama. - Baris kedua pada tiap-tiap tabel menunjukkan tabel hasil restrukturisasi setelah melakukan redefinisi nama.
IV.4 Diagram Konseptual Berdasarkan hasil restrukturisasi data sesuai hasil deteksi database smell dan kebutuhan fungsional dan non fungsional di atas maka dapat digambarkan diagram lojiknya dalam bentuk diagram konseptual pada Lampiran C.
Diagram konseptual tersebut menggambarkan hubungan secara lojik dari beberapa entitas. Entitas-entitas tersebut dapat berhubungan dengan tiga jenis hubungan, yaitu: 1. relationship (referensi), yaitu hubungan one-to-many (1-n) 2. association link (asosiatif), yaitu hubungan many-to-many (n-n).
Di dalam diagram konseptual tersebut terlihat hanya terdapat satu jenis hubungan asosiatif yaitu hubungan asosiatif antara entitas Mahasiswa dan entitas Matakuliah yang terbungkus dalam satu tabel KRS. Dalam satu semester satu mahasiswa dapat mengambil satu atau lebih matakuliah, dan sebaliknya satu matakuliah dapat diambil oleh satu atau lebih mahasiswa. Sedangkan hubungan antar entitas lainnya hanya memiliki hubungan sebagai referensi saja.
IV.5 Diagram Fisik Diagram fisik dari Facis yang terbentuk dari hasil restrukturisasi dapat dilihat di Lampiran D. Diagram fisik ini menunjukkan bentuk fisik yang dirancang untuk
61
Facis setelah diagram konseptual Facis terbentuk. Adapun penamaan tabel didasarkan dengan penamaan entitas, kemudian penamaan kolom didasarkan penamaan atribut tabel, dan penentuan tipe data dan ukuran kolom didasarkan terhadap hasil analisa deskripsi kolom dan identifikasi kamus data pada elemenelemen
tiap-tiap kolom sehingga diperoleh hasil seperti yang terlihat pada
diagram fisik Facis. Tabel IV-5 di bawah ini merupakan contoh identifikasi tipe data ukuran kolom pada salah satu entitas di Facis. Tabel IV-5 Contoh identifikasi tipe data dan ukuran kolom tabel Nama Tabel Dosen
Nama Kolom NIP NamaDosen
Deskripsi Nomor Induk Pegawai, dengan jumlah karakter 9 Nama Dosen
62
Kamus Data {“0-9”} {“Aa-Zz, 0-9”}
Tipe Data Numerical
Ukuran Kolom 9
AlphaNumerical
50
