BAB IV REKAYASA ULANG BASISDATA

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, TRANSKRIP_XXX, _XXX 3 Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA muncul di tiga tabel yaitu MHS, TRANSKRIP dan. 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 merupakan tabel transaksi antar beberapa entitas. MHS NIM NAMA NIM NAMA NIPPA NAMAPA MK1... 46

TRANSKRIP NIM NAMA TPT_LAHIR TGL_LAHIR MK1... 2. Dari hasil analisa di atas maka kolom NAMA ini akan dihapus dari tabel TRANSKRIP dan. Sehingga tabel akhir MHS, TRANSKRIP dan sementara menjadi: MHS NIM NAMA 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, NAMAPA Dosen_D3, _XXX 2 Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA atau NAMAPA muncul di dua tabel yaitu DOSEN_D3 dan. 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 merupakan tabel transaksi antar beberapa entitas. DOSEN NIP NAMA JUR NIM NAMA NIPPA NAMAPA MK1... 47

2. Dari hasil analisa di atas maka kolom NAMA ini akan dihapus dari tabel TRANSKRIP dan. 3. Karena Dosen memiliki relasi dengan Mahasiswa yaitu satu Dosen dapat membimbing n mahasiswa, maka kolom NIPPA di tabel 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 adalah: DOSEN NIP NAMA JUR NIM MK1 KMK1 NMK1... Kasus Data Redundan 3: Tabel IV-3 Kasus data redundan 3 No Kolom/Informasi Tabel Frekuensi 1 NAMA_MK NMKX MK_XXX _XXX 2 Langkah-langkah restrukturisasi tabel: 1. Kolom NAMA_MK atau NMK muncul di dua tabel yaitu tabel MK dan. 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 merupakan tabel transaksi antar beberapa entitas. F = {KODE_KOM KODE_MK, NAMA_MK, SKS, Semester, Prasyarat} MK KODE_KOM KODE_MK NAMA_MK SKS SEMESTER PRASYARAT 48

NIM MK1 KMK1 NMK1... Dengan demikian kolom NMK akan dihapus dari tabel, sehingga tabel sementara akan menjadi: 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, 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 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 Berdasarkan hasil restrukturisasi sebelumnya, diperoleh tabel sebagai berikut: 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 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. 2. Jumlah kolom matakuliah di tabel 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 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 adalah sebagai berikut: 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, maka tabel Transkrip cukup merujuk ke tabel 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 Prediksi Penambahan 1 KRS 5 ± 3x80x10 = 2400 baris / semester 2 7 ± 3x80x10 = 2400 baris / semester 3 TRANSKRIP 8 ± 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, 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 KODE_KOM TahunAkademik Semester Jurusan NIM 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 KODE_KOM Tabel TahunAkademik Semester Jurusan NIM KODE_KOM NH JUMNK Tabel TRANSKRIP TRANSKRIP NIM TGLYUDIS JUDULTA PREDIKAT NOIJAZAH TGLLULUS BIDILMU STRATA Tabel Status KRS StatusKRS TahunAkademik Semester NIM JumlahSKS 55

Tabel IP Semester Mahasiswa Kumulatif 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 StatusAmbil StatusKRS TahunAkademik Semester Jurusan NIM JumlahSKS 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 akan dihapus. Hal ini dilakukan karena kolom jurusan dapat dirujuk melalui tabel mahasiswa saja. KRS TahunAkademik Semester NIM KODE_KOM StatusAmbil TahunAkademik Semester NIM KODE_KOM NH JUMNK Operator OperatorID KodeJurusan UserName NamaOperator 58

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 NAMA Dosen NIP UserName KodeJurusan NamaDosen 2. Tabel Mahasiswa MHS NIM KodeJurusan UserName NIPPA NAMA TPT_LAHIR TGL_LAHIR TahunMasuk Mahasiswa NIM UserName KodeJurusan NIP NamaMahasiswa TempatLahir TanggalLahir TahunMasuk 3. Tabel Operator Operator OperatorID KodeJurusan UserName NamaOperator 4. Tabel Matakuliah MK KODE_KOM KODE_MK KodeJurusan NAMA_MK SKS SEMESTER MataKuliah KodeKomputer KodeMataKuliah KodeJurusan NamaMataKuliah SKS SemesterKe 5. Tabel Matakuliah Prasyarat MKPrasyarat KODE_KOM PRASYARAT MKPrasyarat KodeKomputer Prasyarat 6. Tabel Fakultas Fakultas KodeFakultas NamaFakultas 59

7. Tabel Jurusan Jurusan KodeJurusan 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 TahunAkademik Semester NIM KODE_KOM NH JUMNK TahunAkademik Semester NIM KodeKomputer NilaiHuruf NilaiKumulatif 11. Tabel Kumulatif Kumulatif TahunAkademik Semester NIM IPSemester SKSDepan 12. Tabel Transkrip TRANSKRIP NIM TGLYUDIS JUDULTA PREDIKAT NOIJAZAH TGLLULUS BIDILMU Transkrip NIM TanggalYudisium JudulTA Predikat NomorIjazah TanggalLulus BidangIlmu 13. Tabel NilaiHuruf NilaiHuruf NilaiHuruf NilaiAngka 14. Tabel User User UserName Password RoleID 60

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. Nama Tabel Dosen Tabel IV-5 Contoh identifikasi tipe data dan ukuran kolom tabel Nama Deskripsi Kamus Tipe Data Ukuran Kolom Data Kolom NIP Nomor Induk Pegawai, { 0-9 } Numerical 9 dengan jumlah karakter 9 NamaDosen Nama Dosen { Aa-Zz, AlphaNumerical 50 0-9 } 62