BAB IV REKAYASA ULANG BASISDATA

(1)

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.

(2)

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, KHS_XXX

3

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

(3)

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 ...

No Kolom/Informasi Tabel Frekuensi

1 NAMA, NAMAPA

Dosen_D3, KHS_XXX

2

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

(4)

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

KHS

NIM MK1 KMK1 NMK1 ...

No Kolom/Informasi Tabel Frekuensi 1 NAMA_MK

NMKX

MK_XXX KHS_XXX

2

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

(5)

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.

(6)

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

(7)

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 ...

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

(8)

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:

(9)

TRANSKRIP

NIM TPT_LAHIR TGL_LAHIR MK1 NH1 MK2 NH2 ...

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.

(10)

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 Kemungkinan terjadi banyak baris 1 KRS 5 ± 3x80x10 = 2400 baris / semester Ya 2 KHS 7 ± 3x80x10 = 2400 baris / semester Ya 3 TRANSKRIP 8 ± 3x80 = 240 baris / tahun 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 KODE_KOM

KHS

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

(11)

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 KHS KHS

TahunAkademik Semester Jurusan NIM KODE_KOM NH JUMNK

Tabel TRANSKRIP TRANSKRIP

NIM TGLYUDIS JUDULTA PREDIKAT NOIJAZAH TGLLULUS BIDILMU STRATA

Tabel Status KRS StatusKRS

(12)

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 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.

(13)

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

(14)

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 KODE_KOM StatusAmbil

KHS

TahunAkademik Semester NIM KODE_KOM NH JUMNK

Operator

(15)

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 Ko eJurusan d 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

(16)

7. Tabel Jurusan

Jurusan KodeJurusan KodeFakul s ta 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 NH JUMNK

KHS TahunAkademik Semester NIM KodeKomputer NilaiHuruf NilaiKumulatif

11. Tabel KHSKumulatif

KHSKumulatif 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

(17)

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

(18)

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 elemen-elemen 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 Nama Kolom Deskripsi Kamus Data

Tipe Data Ukuran Kolom NIP Nomor Induk Pegawai,

dengan jumlah karakter 9

{“0-9”} Numerical 9 Dosen

NamaDosen Nama Dosen {“Aa-Zz, 0-9”}