BAB 4 PERANCANGAN SISTEM BASIS DATA

(1)

78

PERANCANGAN SISTEM BASIS DATA

4.1 Gambaran Posisi UMAS

Gambar 4.1 Gambaran Posisi UMAS (1) Keterangan:

: Jika aplikasi tidak memerlukan approval : Jika aplikasi memerlukan approval

Jika transaksi pada suatu aplikasi tidak memerlukan approval dari admin, maka transaksi tersebut akan dikirim langsung ke database. Tetapi jika transaksi pada suatu aplikasi memerlukan approval dari admin, maka transaksi tersebut akan melalui proses di UMAS terlebih dahulu baru dikirim ke database. Transaksi yang

(2)

melalui proses di UMAS baru dikirim ke database akan digambarkan lebih jelas pada gambar berikut.

Gambar 4.2 Gambaran Posisi UMAS (2)

Transaksi yang terjadi di suatu aplikasi akan mengirimkan parameter SQL Command dari transaksi yang dilakukan, modul dan aplikasi id dari aplikasi tersebut, serta user id dari user yang melakukan transaksi ke UMAS. Sebelum UMAS mengirim data – data transaksi yang dilakukan, maka UMAS akan mengecek authentifikasi dari admin login. Setelah admin login sudah benar, maka dilakukan authorization, yaitu pengecekan terhadap hak akses admin yang login. Proses berikutnya adalah accounting, yaitu melakukan pendataan atas transaksi yang dilakukan. Setelah melakukan pendataan, maka dilakukan tindakan approval atau rejection atas transaksi yang dilakukan. Setelah semua proses tersebut dilakukan, maka transaksi yang di-approve ataupun yang di-reject akan dikirim ke database.

(3)

4.2 Gambaran Sistem User Management Apporval System (UMAS) 4.2.1 Data Flow Diagram (DFD)

Diagram Konteks

Tahapan DFD yang digunakan adalah tahapan Diagram Konteks Diagram konteks UMAS pada kampus JWC dapat dilihat pada gambar berikut:

Gambar 4.3 Diagram Konteks UMAS pada kampus JWC

Gambar 4.1 merupakan gambar diagram konteks UMAS pada kampus JWC. Diagram konteks UMAS terdiri dari satu sistem yaitu UMAS, dan eksternal entity yang berinteraksi dengan sistem tersebut yaitu entiti admin dan aplikasi. Informasi atau data dari DFD Diagram Konteks ini kami peroleh dari gambaran posisi umas seperti yang tergambar pada Gambar 4.1 dan Gambar 4.2.

Entiti admin dan aplikasi bertindak sebagai sumber sekaligus tujuan, karena entitas tersebut memberikan masukan ke sistem sekaligus menerima keluaran dari sistem.

(4)

Entiti admin memberikan masukan ke sistem berupa admin_id dan pass_admin. Sedangkan sistem memberikan keluaran berupa daftar transaksi yang perlu disetujui (proses peng-approve-an).

Entiti aplikasi memberikan masukan ke sistem berupa daftar transaksi yang dilakukan oleh user. Sedangkan sistem memberikan keluaran berupa daftar transaksi yang sudah melalui proses atau tahapan persetujuan (approval).

4.2.2 Cross Functional Flowchart

Cross Functional Flowchart UMAS pada kampus JWC terdiri dari satu proses yang berjalan di luar sistem berupa Transaksi_di_Luar_Sistem, dan tiga proses yang berjalan di dalam sistem, yaitu Transaksi_Log, Transaksi_Permintaan_Hak_Akses, dan Transaksi_Penambahan_User.

(5)

(6)

(7)

Sebelum proses pada Cross-Functional Flowchart UMAS dimulai, maka terlebih dahulu pemberitahuan kepada admin masing – masing departemen atas perubahan pada aplikasi agar dapat berdiskusi dengan UMAS. Pembuat program harus memberitahukan aplikasi id dan modul id yang dimiliki tiap departemen kepada admin masing – masing departemen. Selain itu, nama tabel dan nama field untuk menyimpan perintah SQL dari transaksi juga harus diberitahukan kepada admin masing – masing departemen, sehingga admin dapat dengan mudah menghubungkan aplikasi yang ditangani ke UMAS.

Cross-Functional Flowchart pada UMAS dimulai dari sebuah proses yang berjalan di luar sistem bernama Transaksi_di_Luar_Sistem. Proses ini diawali dengan pengaksesan aplikasi oleh entitas user. Setelah aplikasi diakses, user akan melakukan aksi (insert, update, delete) terhadap aplikasi tersebut. Kemudian, aplikasi akan mengirimkan aksi ke UMAS. Di UMAS, akan dilakukan pengecekan apakah aksi tersebut membutuhkan proses approval atau tidak. Apabila tidak dibutuhkan approval, maka aplikasi akan langsung menjalankan aksi dari user tersebut, namun apabila aksi memerlukan approval, maka UMAS akan menunggu approval dari admin yang mengepalai departemen tempat modul atau aplikasi yang bersangkutan berada.

Perlu diketahui, jika user akan melakukan aksi terhadap sebuah aplikasi, maka user tersebut harus memiliki hak akses atas aksi yang ingin dilakukannya. Misalnya, user A ingin meng-update aplikasi B, maka user tersebut harus memiliki hak akses update terhadap aplikasi B, namun jika user tidak memiliki hak akses update tersebut dan tetap ingin meng-update aplikasi

(8)

B, maka user A harus terlebih dahulu melakukan permintaan hak akses update ke aplikasi yang bersangkutan. Dari aplikasi, permintaan hak akses akan dikirim ke UMAS untuk menunggu tindakan approval dari admin.

Proses Transaksi_di_Luar_Sistem dilanjutkan oleh proses Transaksi_Log. Pertama sekali, admin akan melakukan login pada web UMAS. Kemudian UMAS akan melakukan pengecekan admin_id dan pass_admin yang dimasukkan oleh admin. Apabila admin_id dan pass_admin yang dimasukkan tidak sesuai dengan yang ada di database, maka admin harus mengulang kembali melakukan login dengan admin_id dan pass_admin yang benar. Jika admin sudah memasukkan admin_id dan pass_admin dengan benar, maka admin akan melanjutkan proses ke tahap pengecekan daftar approval transaksi – transaksi yang dilakukan oleh user.. Terhadap daftar – daftar approval tersebut, admin dapat melakukan dua pilihan aksi, yaitu meng-approve dan me-reject. Setelah admin melakukan salah satu dari kedua aksi tersebut, maka UMAS akan melakukan peng-update-an pada Transaksi_Log yang ada di database, dan kemudian akan mengirimkan pesan ke aplikasi yang bersangkutan untuk memberitahu apakah transaksi tersebut reject atau di-approve oleh admin.

Proses selanjutnya yaitu proses Transaksi_Permintaan_Hak_Akses. Pada proses ini, admin akan melakukan pengecekan daftar approval permintaan hak akses user. Setelah itu, admin akan melakukan aksi terhadap daftar – daftar approval tersebut. Kemudian UMAS akan meng-update Transaksi_Permintaan_Hak_Akses yang ada di database, serta mengirim pesan

(9)

ke aplikasi yang bersangkutan untuk memberitahu apakah transaksi permintaan hak akses tersebut di-reject atau di-approve oleh admin.

Proses terakhir pada Cross-Functional Flowchart UMAS adalah Transaksi_Penambahan_User. Transaksi ini dilakukan jika terdapat penambahan user baru di JWC. Admin akan melakukan pengisian data – data user baru tersebut, kemudian data akan dikirim ke UMAS untuk selanjutnya diperiksa atau dicek oleh UMAS. Apabila ditemukan kesalahan, maka akan tampil pesan kesalahan di web UMAS, dan kemudian admin akan memperbaiki data – data yang salah tersebut. Namun jika pengisian data sudah benar, maka UMAS akan meng-insert data – datanya ke dalam database.

4.3 Perancangan Basis Data

Perancangan basis data ini bertujuan supaya dapat membantu memecahkan permasalahan yang dihadapi oleh Kampus JWC. Perancangan basis data terdiri dari 3 (tiga) tahapan yang disesuaikan dengan kebutuhan informasi dari Kampus JWC. Adapun ketiga perancangan basis data tersebut adalah sebagai berikut : 1. Perancangan Basis Data Konseptual

2. Perancangan Basis Data Logikal 3. Perancangan Basis Data Fisikal

4.3.1 Perancangan Basis Data Konseptual

Proses membangun sebuah rancangan informasi yang digunakan dalam suatu perusahaan yang bebas dari pertimbangan fisikal. Perancangan ini melibatkan pembuatan suatu model data konseptual dari bagian perusahaan

(10)

dimana penulis tertarik pada pemodelan datanya. Model data dibuat dengan menggunakan informasi yang didokumentasikan dalam spesifikasi kebutuhan user. Perancangan basis data konseptual secara keseluruhan bebas dari rincian implementasi seperti software DBMS sasaran, program aplikasi, bahasa pemrograman, hardware platform, atau pertimbangan fisikal lainnya.

Langkah-langkah dalam perancangan basis data konseptual : 1. Mengidentifikasikan tipe entiti.

2. Mengidentifikasikan tipe relasional.

3. Mengidentifikasikan dan menghubungkan atribut dengan tipe entiti atau relasi.

4. Mengidentifikasikan domain atribut

5. Menentukan atribut candidate key dan primary key. 6. Validasi model konseptual terhadap transaksi user

4.3.1.1 Mengidentifikasikan Tipe Entiti

Berikut ini merupakan tabel yang menjelaskan entiti-entiti yang digunakan dalam perancangan, antara lain:

NAMA ENTITAS

KETERANGAN ALIAS KEMUNCULAN

Ms_Admin Merupakan entitas yang memberikan informasi yang

Admin Setiap departemen dikepalai oleh seorang admin

(11)

berhubungan dengan admin Ms_Departeme n Merupakan entitas yang mendeskripsikan departemen yang terdapat di JWC

Departemen Setiap bahagian yang terdapat di JWC dikelompokkan berdasarkan departemen

Ms_Aplikasi Merupakan entitas yang

mendeskripsikan

aplikasi yang terdapat di setiap departemen

Aplikasi Setiap departemen memiliki beberapa aplikasi

Ms_Modul Merupakan entitas yang

mendeskripsikan

modul yang terdapat di setiap aplikasi

Modul Setiap aplikasi terdiri dari beberapa modul

Ms_User Merupakan entitas yang memberikan

User Setiap aplikasi diakses oleh user yang berada di

(12)

informasi yang berhubungan

dengan user yang mengakses

aplikasi di JWC

departemen yang sama dengan aplikasi yang diaksesnya

Ms_Jenis_User Merupakan entitas yang memberikan informasi yang berhubungan

dengan jenis – jenis user yang mengakses

aplikasi di JWC

Jenis User User dikelompokkan ke dalam beberapa jenis user

Ms_Hak_Akses Merupakan entitas yang

mendeskripsikan hak akses yang dimiliki oleh tiap user

Hak Akses Setiap user memiliki hak akses terhadap modul – modul atau aplikasi yang ada

Tr_Log Merupakan entitas yang memberikan

Log Setiap transaksi yang

(13)

informasi mengenai proses peng-approve-an daftar transaksi yang dilakukan oleh user

melalui proses peng-approve-an terlebih dahulu oleh admin Tr_Pnambahan _User Merupakan entitas yang memberikan informasi mengenai penambahan user baru Penambahan User

Penambahan user baru

Tr_Permintaan_ HA Merupakan entitas yang memberikan informasi mengenai permintaan hak akses oleh user

Permintaan Hak Akses

Permintaan hak akses oleh user

(14)

4.3.1.2 Mengidentifikasikan Tipe Relational

Tujuan dari tahapan ini adalah untuk mengidentifikasikan hubungan antara entiti-entiti yang telah diidentifikasikan. Langkah-langkah dalam mengidentifikasikan tipe relasi :

1. Menggunakan Entity Relationship (ER) Diagram 2. Menentukan pembatas multiplicity dari tipe relasi

4.3.1.2.1 Menggunakan Entity Relationship (ER) Diagram

Berikut ini ERD konseptual yang memuat nama entitas beserta dengan hubungannya (relationship) adalah sebagai berikut :

(15)

Gambar 4.6 Entity Relationship (ER) Diagram Konseptual

4.3.1.2.2 Menentukan Pembatas Multiplicity dari Tipe Relasi

Setelah ditentukan Entity Relationship (ER) Diagram Konseptual, maka langkah selanjutnya adalah menentukan batas multiplicity (batasan tipe relasi) dari masing-masing entiti sesuai dengan relasinya dengan entiti yang lain. Tabel berikut ini

(16)

mencantumkan tipe-tipe relasi yang terdapat pada perancangan basis data.

Nama Entiti Multiplicity Relasi Nama Entiti Multiplicity

Ms_Admin 1..1 1..1 1..1 1..1 1..1 1..1 1..1 Mengepalai Menangani Menangani Menangani Menyetujui Melakukan Menyetujui Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User Tr_Log Tr_Penambahan_U ser Tr_Permintaan_HA 1..1 1..* 1..* 1..* 0..* 0..* 0..* Ms_Departeme n 1..1 1..1 1..1 1..1 Memiliki Memiliki Mempunyai Meliputi Ms_Modul Ms_Aplikasi Ms_User Tr_Pnambahan_Us er 1..* 1..* 1..* 0..* Ms_Modul 1..* 1..1 1..* 1..* Mempunyai Terdapat Meliputi Meliputi Ms_Aplikasi Ms_Hak_Akses Tr_Log Tr_Permintaan_HA 1..1 0..* 0..* 0..* Ms_Aplikasi 1..1 1..* Terdapat Meliputi Ms_Hak_Akses Tr_Log 0..* 0..*

(17)

Nama Entiti Multiplicity Relasi Nama Entiti Multiplicity 1..* Meliputi Tr_Permintaan_HA 0..* Ms_User 1..* 1..1 1..* 1..1 1..1 Terdiri dari Memiliki Melakukan Terdiri dari Melakukan Ms_Jenis_User Ms_Hak_Akses Tr_Log Tr_Pnambahan_Us er Tr_Permintaan_HA 1..1 0..* 0..* 1..1 0..* Tabel 4.2 Pembatasan Multiplicity

4.3.1.3 Mengidentifikasikan dan Menghubungkan Atribut dengan Tipe Entiti atau Relasi

Tujuan dari tahapan ini adalah untuk mengidentifikasikan dan menghubungkan atribut dengan tipe entiti atau hubungan. Berikut ini merupakan tabel setiap entiti beserta dengan atributnya masing-masing.

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value Ms_Admin Admin_Id Nama_Admin Pass_Admin Tanggal_Regist Kode Admin Nama Admin Password Admin Tanggal Char (5) Varchar(50) Varchar(50) Datetime No No No No No No No No

(18)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value er Status_Admin pendaftaran Admin Status Admin (aktif atau nonaktif) Varchar (8) No No Ms_Departem en Departemen_Id Nama_Departe men Admin_Id Kode departemen Nama departemen Kode Admin Varchar (5) Varchar(50) Char (5) No No Yes No No No Ms_Modul Modul_Id Nama_Modul Aplikasi_Id Departemen_Id Admin_Id Status_Modul Kode modul Nama modul Kode aplikasi Kode departemen Kode Admin Status modul (aktif atau nonaktif) Char (5) Varchar(50) Char (6) Varchar (5) Char (5) Varchar (8) No No No No No No No No No No No No Ms_Aplikasi Aplikasi_Id Nama_Aplikasi Kode aplikasi Nama aplikasi Char (6) Varchar(50) No No No No

(19)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value Departemen_Id Admin_Id Status_Aplikasi Kode departemen Kode Admin Status aplikasi (aktif atau nonaktif) Varchar (5) Char (5) Varchar (8) No No No No No No Ms_User User_Id Nama_User Pass_User Status_User Jenis_User_Id Tanggal_Regist er Departemen_Id Admin_Id Kode user Nama user Password user Status user (aktif atau nonaktif) Kode jenis user Tanggal pendaftaran user Kode departemen Kode Admin Varchar(10) Varchar(50) Varchar(50) Varchar (8) Varchar (5) Datetime Varchar (5) Char (5) No No No No No No No No No No No No No No No No Ms_Jenis_Use r Jenis_User_Id Nama_Jenis_Us

Kode jenis user Nama jenis user

Varchar (5) Varchar(20) No No No No

(20)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value er Ms_Hak_Aks es Hak_Akses_Id Modul_Id Aplikasi_Id Values Is_Approval User_Id

Kode hak akses Kode modul Kode aplikasi Aksi (terdiri dari insert, update, delete) Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak. Kode user Int (5) Char (5) Char (6) Varchar (6) Varchar (3) Varchar(10) No No No No No No No No No No No No Tr_Log Form_Log_Id User_Id Modul_Id Admin_Id Jenis_Aksi Kode formulir transaksi log Kode user Kode modul Kode Admin Jenis aksi yang

Int (5) Varchar(10) Char (5) Char (5) Varchar (6) No No No No No No No No No No

(21)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value SQL_Cmd Tanggal_Trans Status_Trans Tanggal_Appro val Aplikasi_Id Alasan Reject dilakukan oleh user terhadap aplikasi yang diaksesnya Jenis aksi yang ditulis dalam sintaks SQL secara lengkap Tanggal terjadinya transaksi log Status transaksi (aktif atau nonaktif) Tanggal terjadinya proses peng-approve-an daftar transaksi oleh admin Kode aplikasi Alasan kenapa Text Datetime Varchar (7) Datetime Char (6) Text Yes No No Yes No Yes No No No No No No

(22)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value SQL_Cmd_Rev isi me-reject suatu transaksi Sintaks SQL dari SQL_Cmd yang sudah diperbaiki Text Yes No Tr_Pnambaha n_User Form_Penamba han_Id User_Id Nama_User Pass_User Admin_Id Departemen_Id Tanggal_Transa ksi Kode formulir transaksi penambahan user Kode user Nama user Password user Kode Admin Kode departemen Tanggal terjadinya transaksi penambahan Int (5) Varchar(10) Varchar(50) Varchar(50) Char (5) Varchar (5) Datetime No No No No No No No No No No No No No No

(23)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value user Tr_Permintaa n_HA Form_Perminta anHA_Id User_Id Modul_Id Aplikasi_Id Values Status_Transaks i Admin_Id Tanggal_Transa ksi Tanggal_Appro Kode formulir transaksi permintaan hak akses Kode user Kode modul Kode aplikasi Aksi (terdiri dari insert, update, delete) Status transaksi (aktif atau nonaktif) Kode Admin Tanggal terjadinya transaksi permintaan hak akses Tanggal Int (5) Varchar(10) Char (5) Char (6) Varchar (6) Varchar (7) Char (5) Datetime Datetime No No No No No No No No Yes No No No No No No No No No

(24)

Entitas Atribut Deskripsi Tipe dan Panjang Data Null Multi Value val Alasan_Reject Is_Approval terjadinya proses peng-approve-an permintaan hak akses oleh admin Alasan kenapa me-reject suatu permintaan Status yang diberikan terhadap suatu permintaan apakah perlu mendapat tindakan approval atau tidak. Text Varchar(3) Yes Yes No No

(25)

4.3.1.4 Mengidentifikasikan Domain Atribut

Langkah selanjutnya adalah menentukan domain untuk tiap atribut untuk tiap entiti pada model konseptual. Berikut ini adalah tabel domain atribut :

Entiti Atribut Domain

Ms_Admin Admin_Id

Nama_Admin Pass_Admin Tanggal_Reg Status_Admin

Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Maksimum 50 karakter Maksimum 50 karakter yyyy-mm-dd dan hh:mm:ss Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”) Ms_Departemen Departemen_Id Nama_Departemen Admin_Id Maksimum 10 karakter Maksimum 50 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Ms_Modul Modul_Id

Nama_Modul

Terdiri dari 5 karakter Maksimum 50 karakter

(26)

Entiti Atribut Domain Aplikasi_Id

Departemen_Id Admin_Id

Status_Modul

Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf ’A’ dan ’p’ dan 4 karakter terakhir berupa angka

Maksimum 10 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”)

Ms_Aplikasi Aplikasi_Id

Nama_Aplikasi Departemen_Id Admin_Id

Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf ’A’ dan ’p’ dan 4 karakter terakhir berupa angka

Maksimum 50 karakter Maksimum 10 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama

(27)

Status_Aplikasi

berupa huruf dan 3 karakter terakhir berupa angka Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”) Ms_User User_Id Nama_User Pass_User Status_User Jenis_User_Id Tanggal_Register Departemen_Id Admin_Id Maksimum 10 karakter Maksimum 50 karakter Maksimum 50 karakter Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”)

Maksimum 5 karakter yyyy-mm-dd dan hh:mm:ss Maksimum 10 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Ms_Jenis_User Jenis_User_Id

Nama_Jenis_User

Maksimum 5 karakter Maksimum 20 karakter Ms_Hak_Akses Hak_Akses_Id Berupa angka, maksimum

(28)

Entiti Atribut Domain Modul_Id Aplikasi_Id Values Is_Approval User_Id

Terdiri dari 5 karakter Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf ’A’ dan ’p’ dan 4 karakter terakhir berupa angka

Maksimum 6 karakter (berupa “insert” atau “update” atau “delete”) Maksimum 3

karakter(berupa “yes” atau “no”) Maksimum 10 karakter Tr_Log Form_Log_Id User_Id Modul_Id Admin_Id Jenis_Aksi

Berupa angka, maksimum 5 digit

Maksimum 10 karakter Terdiri dari 5 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Maksimum 6 karakter

(29)

Entiti Atribut Domain SQL_Cmd Tanggal_Trans Status_Trans Tanggal_Approval Aplikasi_Id Alasan_Reject SQL_Cmd_Revisi (berupa ”insert”

atau”update” atau ”delete”) Berupa text

yyyy-mm-dd dan hh:mm:ss Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”

yyyy-mm-dd dan hh:mm:ss Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf ’A’ dan ’p’ dan 4 karakter terakhir berupa angka Berupa text Berupa text Tr_Pnambahan_User Form_Penambahan_Id User_Id Nama_User Pass_User Admin_Id

Maksimum 10 karakter Maksimum 50 karakter Maksimum 50 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama

(30)

Departemen_Id Tanggal_Transaksi

berupa huruf dan 3 karakter terakhir berupa angka Maksimum 10 karakter yyyy-mm-dd dan hh:mm:ss Tr_Permintaan_HA Form_PermintaanHA_Id User_Id Modul_Id Aplikasi_Id Values Status_Transaksi Admin_Id

Maksimum 10 karakter Terdiri dari 5 karakter Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf ’A’ dan ’p’ dan 4 karakter terakhir berupa angka

Maksimum 6 karakter (berupa ”insert” atau ”update” atau ”delete”) Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”)

Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter

(31)

Tanggal_Transaksi Tanggal_Approval Alasan_Reject Is_Approval

terakhir berupa angka yyyy-mm-dd dan hh:mm:ss yyyy-mm-dd dan hh:mm:ss Berupa text

Maksimum 3

karakter(berupa “yes” atau “no”)

Tabel 4.4 Identifikasi Domain Atribut

4.3.1.5 Menentukan Atribut Candidate Key dan Primary Key

Berikut ini merupakan penentuan atribut candidate dan primary key dari setiap entiti yang ada, antara lain :

Entity Candidate Key Primary Key

Ms_Admin Admin_Id Admin_Id

Ms_Departemen Departemen_Id Admin_Id Departemen_Id Ms_Modul Modul_Id Aplikasi_Id Departemen_Id Admin_Id Modul_Id Ms_Aplikasi Aplikasi_Id Departemen_Id Aplikasi_Id

(32)

Entity Candidate Key Primary Key Admin_Id Ms_User User_Id Departemen_Id Jenis_User_Id Admin_Id User_Id

Ms_Jenis_User Jenis_User_Id Jenis_User_Id

Ms_Hak_Akses Hak_Akses_Id Aplikasi_Id User_Id Modul_Id Hak_Akses_Id Tr_Log Form_Log_Id User_Id Modul_Id Admin_Id Form_Log_Id Tr_Pnambahan_User Form_Penambahan_Id User_Id Admin_Id Departemen_Id Form_Penambaha n_Id Tr_Permintaan_HA Form_PermintaanHA_Id User_Id Modul_Id Aplikasi_Id Form_Permintaan HA_Id

(33)

Entity Candidate Key Primary Key

Admin_Id

Tabel 4.5 Identifikasi Candidate dan Primary Key

(34)

4.3.1.6 Validasi Model Konseptual Data Lokal Terhadap Transaksi User 4.3.1.6.1 Data Entry

1. Memasukkan detail dari admin baru (seperti detail admin bernama Susan)

2. Memasukkan detail dari user baru (seperti detail user bernama Gunawan)

3. Memasukkan detail dari departemen baru (seperti detail departemen Back Office)

4. Memasukkan detail dari aplikasi baru (seperti detail aplikasi VOIP Binus)

5. Memasukkan detail dari modul baru (seperti detail modul User Online pada aplikasi VOIP Binus)

6. Memasukkan detail dari hak akses user baru (seperti detail hak akses pada modul User Online di aplikasi VOIP Binus pada user Gunawan)

7. Memasukkan detail dari jenis user baru (seperti detail jenis user Manager)

4.3.1.6.2 Data Update atau Deletion

1. Meng-update atau men-delete detail seorang admin 2. Meng-update atau men-delete detail seorang user 3. Meng-update atau men-delete detail sebuah departemen 4. Meng-update atau men-delete detail sebuah aplikasi 5. Meng-update atau men-delete detail sebuah modul

(35)

6. Meng-update atau men-delete detail sebuah hak akses user 7. Meng-update atau men-delete detail sebuah jenis user

4.3.1.6.3 Data Queries

(a) Tampilkan detail user yang berada di departemen Lecturer (b) Tampilkan detail hak akses berdasarkan kode aplikasi Ap001 (c) Tampilkan detail modul yang terdapat di aplikasi Ap002 (d) Tampilkan admin id yang berada di departemen Lecturer

(e) Tampilkan detail penambahan user berdasarkan kode departemen Lecturer

(f) Tampilkan detail aplikasi yang berada di departemen Lecturer (g) Tampilkan daftar permintaan hak akses yang dilakukan oleh user

Us0001

(h) Tampilkan daftar permintaan hak akses selama sebulan terhadap aplikasi Ap001

(i) Tampilkan daftar transaksi log yang dilakukan oleh user Us0001 (j) Tampilkan daftar transaksi log selama sebulan terhadap aplikasi

Ap001

(k) Tampilkan user berdasarkan jenis user Mhs

(l) Tampilkan daftar admin yang memiliki status “aktif”

(m) Tampilkan daftar hak akses yang memiliki is_approval “Yes”

(n) Tampilkan daftar transaksi permintaan hak akses yang dilakukan pada tanggal 23 November 2007

(36)

(37)

Gambar 4.9 ER Diagram Konseptual

4.3.2 Perancangan Basis Data Logikal

4.3.2.1 Menghilangkan Fitur Tidak Kompatibel

Memperbaiki model data konseptual lokal untuk menghilangkan fitur-fitur yang tidak kompatibel dengan model relasional.

(38)

4.3.2.1.1 Menghilangkan Many-to-many (*:*) Binary Relationship Types Bila dalam model konseptual masih terdapat hubungan many-to-many (*:*) binary relationship type, maka harus diubah menjadi hubungan one-to-many (1:*) dengan penambahan entiti baru.

• Hubungan Tr_Log dengan Ms_Modul

(a)

(b)

Keterangan : a. Kondisi Awal

b. Kondisi Akhir

• Hubungan Tr_Log dengan Ms_Aplikasi

(a)

(b)

(39)

• Hubungan Tr_Permintaan_HA dengan Ms_Aplikasi

(a)

(b)

b. Kondisi Akhir

• Hubungan Tr_Permintaan_HA dengan Ms_Modul

(a)

(b)

(40)

4.3.2.2 Menentukan Relasi Untuk Model Data Logikal Global 4.3.2.2.1 Strong Entity Types

Untuk setiap strong entity di dalam model data, buat sebuah relasi yang mengandung semua atribut sederhana entitas tersebut.

Ms_Admin (Admin_Id, Nama_Admin, Pass_Admin, Tanggal_Reg, Status_Admin)

Primary Key Admin_Id

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id

Ms_Modul (Modul_Id, Nama_Modul, Aplikasi_Id, Departemen_Id, Admin_Id, Status_Modul)

Primary Key Modul_Id

Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi, Departemen_Id, Admin_Id, Status_Aplikasi)

Primary Key Aplikasi_Id

Ms_User (User_Id, Nama_User, Pass_User, Status_User, Tanggal_Register, Departemen_Id, Jenis_User_Id, Admin_Id)

(41)

Ms_Jenis_User (Jenis_User_Id, Nama_Jenis_User) Primary Key Jenis_User_Id

Ms_Hak_Akses (Hak_Akses_Id, Aplikasi_Id, Values, User_Id, Is_Approval, Modul_Id)

Primary Key Hak_Akses_Id

Tr_Log (Form_Log_Id, User_Id, Modul_Id, Admin_Id, Jenis_Aksi, SQL_Cmd, Tanggal_Trans, Status_Trans, Tanggal_Approval, Aplikasi_Id, Alasan_Reject, SQL_Cmd_Revisi)

Primary Key Form_Log_Id

Tr_Pnambahan_User (Form_Pnambahan_Id, User_Id, Nama_User, Pass_User, Admin_Id, Departemen_Id, Tanggal_Transaksi)

Primary Key Form_Penambahan_Id

Tr_Permintaan_HA (Form_PermintaanHA_Id, User_Id, Modul_Id, Aplikasi_Id, Values, Status_Transaksi, Admin_Id, Tanggal_Transaksi, Tanggal_Approval, Alasan_Reject, Is_Approval)

Primary Key Form_PermintaanHA_Id

4.3.2.2.2 Weak Entity Types

Untuk setiap weak entity di dalam model data, buat sebuah relasi yang memasukkan semua atribut sederhana pada entitas tersebut.

(42)

Primary key weak entity merupakan turunan parsial atau keseluruhan dari setiap pemilik entitas dan oleh karena itu identifikasi primary key weak entity tidak bisa dibuat sampai semua relasi dengan pemilik entitas telah dipetakan.

Entiti Tr_Detail_Log Tr_Detail_Log( )

Primary Key Tidak ada (sekarang)

Entiti Ms_Modul Ms_Modul(Modul_Id) Primary Key Modul_Id

Entiti Tr_DPermintaan_HA Tr_DPermintaan_HA ( )

Primary Key Tidak ada (sekarang)

4.3.2.2.3 One-to-many (1:*) Binary Relationship Types

Untuk masing-masing one-to-many binary relationship types, ‘dalam satu sisi’ menjadi entiti induk dan entiti yang lain menjadi entiti anak. Untuk merepresentasikannya, pindahkan primary key dari entiti induk ke entiti anak sebagai foreign key.

(43)

1. Relasi antar Ms_Admin dengan Ms_User menghasilkan posting Admin_Id ke entiti Ms_User

Post Admin_Id ke Ms_User untuk model relasi 1 : * mengalami

Ms_Admin (Admin_Id, Nama_Admin,

Pass_Admin, Tanggal_Reg, Status_Admin)

Ms_User (User_Id, Admin_Id,

Nama_User, Pass_User, Status_User, Tanggal_Register,

Departemen_Id, Jenis_User_Id) Primary Key User_Id

Foreign Key Admin_Id references Ms_Admin (Admin_Id)

2. Relasi antar Ms_Admin dengan Ms_Aplikasi menghasilkan posting Admin_Id ke entiti Ms_Aplikasi

Post Admin_Id ke Ms_Aplikasi untuk model relasi 1 : * mengalami

Ms_Admin (Admin_Id, Nama_Admin, Pass_Admin, Tanggal_Reg, Status_Admin)

Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi, Admin_Id, Departemen_Id, Status_Aplikasi)

(44)

3. Relasi antar Ms_Departemen dengan Ms_Modul menghasilkan posting Departemen_Id ke entiti Ms_Modul

Post Departemen_Id ke Ms_Modul untuk model relasi 1 : * mengalami

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id

Ms_Modul (Modul_Id, Nama_Modul, Departemen_Id,

Aplikasi_Id, Admin_Id, Status_Modul)

Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id)

4. Relasi antar Ms_Departemen dengan Ms_Aplikasi menghasilkan posting Departemen_Id ke entiti Ms_Aplikasi

Post Departemen_Id ke Ms_Aplikasi untuk model relasi 1 : * mengalami

Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi, Departemen_Id, Admin_Id, Status_Aplikasi)

Foreign Key Departemen_Id references Ms_Departemen

(45)

(Departemen_Id)

5. Relasi antar Ms_Departemen dengan Ms_User menghasilkan posting Departemen_Id ke entiti Ms_User

Post Departemen_Id ke Ms_User untuk model relasi 1 : * mengalami

Ms_User (User_Id, Nama_User, Pass_User, Departemen_Id, Status_User, Tanggal_Register, Jenis_User_Id, Admin_Id)

Primary Key User_Id

6. Relasi antar Ms_Modul dengan Ms_Aplikasi menghasilkan posting Aplikasi_Id ke entiti Ms_Modul

Post Aplikasi_Id ke Ms_Modul untuk model relasi 1 : * mengalami

Ms_Modul (Modul_Id, Nama_Modul, Aplikasi_Id, Departemen_Id, Admin_Id, Status_Modul)

(46)

Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

7. Relasi antar Ms_Modul dengan Ms_Hak_Akses menghasilkan posting Modul_Id ke entiti Ms_Hak_Akses

Post Modul_Id ke Ms_Hak_Akses untuk model relasi 1 : * mengalami

Ms_Modul (Modul_Id, Nama_Modul, Aplikasi_Id, Departemen_Id, Admin_Id, Status_Modul)

Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

Ms_Hak_Akses (Hak_Akses_Id, Aplikasi_Id, Values, Modul_Id, User_Id, Is_Approval)

Primary Key Hak_Akses_Id Foreign Key Modul_Id references Ms_Modul (Modul_Id)

(47)

8. Relasi antar Ms_Aplikasi dengan Ms_Hak_Akses menghasilkan posting Aplikasi_Id ke entiti Ms_Hak_Akses

Post Aplikasi_Id ke Ms_Hak_Akses untuk model relasi 1 : * mengalami

Ms_Hak_Akses (Hak_Akses_Id, Values, User_Id, Aplikasi_Id, Is_Approval, Modul_Id)

Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

9. Relasi antar Ms_User dengan Ms_Jenis_User menghasilkan posting Jenis_User_Id ke entiti Ms_User

Post Jenis_User_Id ke Ms_User untuk model relasi 1 : * mengalami

Ms_Jenis_User (Jenis_User_Id, Nama_Jenis_User)

Primary Key Jenis_User_Id

Ms_User (User_Id, Nama_User,

Pass_User, Jenis_User_Id, Status_User, Tanggal_Register, Departemen_Id, Admin_Id)

(48)

Foreign Key Jenis_User_Id references Ms_Jenis_User (Jenis_User_Id)

10. Relasi antar Ms_Modul dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Ms_Modul

Post Admin_Id ke Ms_Modul untuk model relasi 1 : * mengalami

Ms_Admin (Admin_Id,

Nama_Admin, Pass_Admin, Tanggal_Reg, Status_Admin)

Ms_Modul (Modul_Id, Nama_Modul, Admin_Id, Status_Modul, Departemen_Id, Aplikasi_Id,)

Foreign Key Admin_Id references Ms_Admin(Admin_Id)

11. Relasi antar Ms_Hak_Akses dengan Ms_User menghasilkan posting User_Id ke entiti Ms_Hak_Akses

Post User_Id ke Ms_Hak_Akses untuk model relasi 1 : * mengalami

Ms_User (User_Id, Nama_User, Pass_User, Tanggal_Register, Status_User, Departemen_Id,

Ms_Hak_Akses (Hak_Akses_Id, Values, Is_Approval, User_Id , Aplikasi_Id, Admin_Id)

(49)

Jenis_User_Id, Admin_Id) Primary Key User_Id

Primary Key Hak_Akses_Id Foreign Key User_Id references Ms_User(User_Id)

12. Relasi antar Tr_Permintaan_HA dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Tr_Permintaan_HA

Post Admin_Id ke Tr_Permintaan_HA untuk model relasi 1 : * mengalami

Tr_Permintaan_HA

(Form_PermintaanHA_Id, Values, Status_Transaksi, Admin_Id, Tanggal_Transaksi,

Tanggal_Approval, Is_Approval, User_Id, Modul_Id, Aplikasi_Id, Alasan_Reject)

Primary Key Form_PermintaanHA_Id

(50)

13. Relasi antar Tr_Permintaan_HA dengan Ms_User menghasilkan posting User_Id ke entiti Tr_Permintaan_HA

Post User_Id ke Tr_Permintaan_HA untuk model relasi 1 : * mengalami

Ms_User (User_Id, Nama_User, Pass_User, Tanggal_Register, Status_User, Departemen_Id, Jenis_User_Id, Admin_Id)

(Form_PermintaanHA_Id, User_Id,

Values, Status_Transaksi, Tanggal_Transaksi,

Tanggal_Approval, Is_Approval, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject)

Primary Key Form_PermintaanHA_Id

Foreign Key User_Id references Ms_User(User_Id)

14. Relasi antar Tr_Log dengan Ms_User menghasilkan posting User_Id ke entiti Tr_Log

Post User_Id ke Tr_Log untuk model relasi 1 : * mengalami

Ms_User (User_Id, Nama_User, Pass_User, Tanggal_Register, Status_User, Departemen_Id,

Tr_Log (Form_Log_Id, Jenis_Aksi, SQL_Cmd, User_Id,

(51)

Tanggal_Approval, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject, SQL_Cmd_Revisi)

Foreign Key User_Id references Ms_User(User_Id)

15. Relasi antar Tr_Log dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Tr_Log

Post Admin_Id ke Tr_Log untuk model relasi 1 : * mengalami

Tr_Log (Form_Log_Id, Jenis_Aksi, SQL_Cmd, Admin_Id, Status_Trans, Tanggal_Trans, Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id, Alasan_Reject, SQL_Cmd_Revisi)

(52)

16. Relasi antar Tr_Pnambahan_User dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Tr_Pnambahan_User

Post Admin_Id ke Tr_Pnambahan_User untuk model relasi 1 : * mengalami

Tr_Pnambahan_User (Form_Pnambahan_Id, Admin_Id, Nama_User, Pass_User, Tanggal_Transaksi, User_Id, Departemen_Id ) Primary Key Form_Pnambahan_Id

17. Relasi antar Tr_Pnambahan_User dengan Ms_Departemen menghasilkan posting Departemen_Id ke entiti Tr_Pnambahan_User

Post Departemen_Id ke Tr_Pnambahan_User untuk model relasi 1 : * mengalami

Tr_Pnambahan_User (Form_Pnambahan_Id,

Nama_User, Departemen_Id, Pass_User, Tanggal_Transaksi,

(53)

User_Id, Admin_Id)

Primary Key Form_Pnambahan_Id

Foreign Key Departemen_Id references

Ms_Departemen(Departemen_Id)

4.3.2.2.4 One-to-one (1:1) Binary Relationship Types

Untuk masing-masing one-to-one binary relationship types, entiti yang satu dianggap sebagai induk bila memiliki optional participation, dan entiti lainnya dianggap sebagai anak bila memiliki mandatory participation. Kemudian primary key dari entiti induk diletakkan ke entiti anak sebagai foreign key.

1. Relasi antar Ms_Admin dengan Ms_Departemen menghasilkan posting Admin_Id ke entiti Ms_Departemen

Post Admin_Id ke Ms_Departemen untuk model relasi 1 : 1 mengalami

Ms_Admin (Admin_Id, Nama_Admin, Pass_Admin, Tanggal_Reg, Status_Admin)

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id)

(54)

2. Relasi antar Ms_User dengan Tr_Pnambahan_User menghasilkan posting User_Id ke entity Tr_Pnambahan_User

Post User_Id ke Tr_Pnambahan_User untuk model relasi 1 : 1 mengalami

Pass_User, Status_User, Tanggal_Register, Departemen_Id,

Foreign Key Jenis_User_Id references Ms_Jenis_User (Jenis_User_Id)

Tr_Pnambahan_User

(Form_Pnambahan_Id, User_Id, Nama_User, Pass_User, Admin_Id, Departemen_Id,

Tanggal_Transaksi)

Primary Key Form_Penambahan_Id

Foreign Key User_Id references Ms_User (User_Id)

4.3.2.2.5 Many-to-many (*:*) Binary Relationship Types

Untuk setiap hubungan many-to-many binary relationship types dibuat sebuah relasi yang merepresentasikan hubungan, termasuk semua atribut yang menjadi bagian dari hubungan tersebut.

(55)

1. Relasi Ms_Modul dengan Tr_Log Ms_Modul (Modul_Id, Nama_Modul, Status_Modul,

Aplikasi_Id, Departemen_Id, Admin_Id)

Tr_Log (Form_Log_Id, Jenis_Aksi, SQL_Cmd,

Tanggal_Trans, Status_Trans, Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject, SQL_Cmd_Revisi)

Tr_Detail_Log(Form_Log_Id, Modul_Id)

Primary Key Form_Log_Id, Modul_Id

Foreign Key Form_Log_Id references Tr_Log (Form_Log_Id)

Foreign Key Modul_Id references Ms_Modul (Modul_Id)

2. Relasi Ms_Aplikasi dengan Tr_Log Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi,

Status_Aplikasi, Departemen_Id, Admin_Id)

Tr_Log (Form_Log_Id, Jenis_Aksi, SQL_Cmd,

Tanggal_Trans, Status_Trans, Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject, SQL_Cmd_Revisi)

Foreign Key Modul_Id references Ms_Modul

(Modul_Id)

Ms_Modul(Modul_Id)

(56)

3. Relasi Ms_Modul dengan Tr_Permintaan_HA Ms_Modul (Modul_Id, Nama_Modul, Status_Modul,

Aplikasi_Id, Departemen_Id, Admin_Id)

Tr_Permintaan_HA (Form_PermintaanHA_Id, Values,

Tanggal_Transaksi, Status_Transaksi, Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id,

Admin_Id, Alasan_Reject, Is_Approval)

Tr_DPermintaan_HA (Form_PermintaanHA_Id, Modul_Id)

Primary Key Form_PermintaanHA_Id, Modul_Id

Foreign Key Form_PermintaanHA_Id references Tr_Permintaan_HA (Form_PermintaanHA_Id)

Foreign Key Modul_Id references Ms_Modul (Modul_Id)

4. Relasi Ms_Aplikasi dengan Tr_Permintaan_HA Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi,

Status_Aplikasi, Departemen_Id, Admin_Id)

Tr_Permintaan_HA (Form_PermintaanHA_Id, Values,

Tanggal_Transaksi, Status_Transaksi, Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id,

Admin_Id, Alasan_Reject, Is_Approval)

Foreign Key Modul_Id references Ms_Modul

(Modul_Id)

Ms_Modul(Modul_Id)

(57)

Ms_Admin (Admin_Id, Nama_Admin, Pass_Admin, Tanggal_Reg,

Status_Admin)

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id)

Ms_Modul (Modul_Id, Nama_Modul, Aplikasi_Id, Departemen_Id, Admin_Id, Status_Modul)

Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id)

Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id)

Pass_User, Status_User, Tanggal_Register, Departemen_Id,

Foreign Key Jenis_User_Id references

Ms_Jenis_User (Jenis_User_Id, Nama_Jenis_User)

(58)

Ms_Jenis_User (Jenis_User_Id)

Ms_Hak_Akses (Hak_Akses_Id, Aplikasi_Id, Values, User_Id, Is_Approval, Modul_Id)

Foreign Key Modul_Id references Ms_Modul (Modul_Id)

Tr_Log (Form_Log_Id, User_Id, Modul_Id, Admin_Id, Jenis_Aksi,

SQL_Cmd, Tanggal_Trans, Status_Trans, Tanggal_Approval, Aplikasi_Id, Alasan_Reject, SQL_Cmd_Revisi))

Tr_Pnambahan_User

(Form_Pnambahan_Id, User_Id, Nama_User, Pass_User, Admin_Id, Departemen_Id, Tanggal_Transaksi)

Primary Key Form_Penambahan_Id

(Form_PermintaanHA_Id, User_Id, Modul_Id, Aplikasi_Id, Values,

Status_Transaksi, Admin_Id, Tanggal_Transaksi, Tanggal_Approval,

(59)

Alasan_Reject, Is_Approval)

Primary Key Form_PermintaanHA_Id Foreign Key User_Id references Ms_User (User_Id)

Tabel 4.6 Dokumentasi Relasi dan Atribut Foreign Key

4.3.2.3 Validasi Model dengan Normalisasi

Proses normalisasi data dimaksudkan untuk menghilangkan redudansi semaksimal mungkin dan meningkatkan kemudahan operasi untuk mengubah, menghapus, dan memasukkan data pada suatu basis data. Pada waktu menghilangkan feature yang tidak kompatibel dengan model relasional, sebenarnya tabel sudah berada dalam bentuk normalisasi pertama (menghilangkan repeating group) yang dimana dilihat pada model data logikal lokal, tetapi untuk jelasnya akan dibuat normalisasi dari tahapan UNF, tahapan bentuk normal pertama, bentuk normal kedua yakni menghilangkan partial dependency dan membuat lebih dahulu bentuk normal ketiga yakni menghilangkan transitive dependency. Adapun langkah-langkah normalisasi yang dilakukan sebagai berikut:

(60)

Tr_Log (asumsi : setiap form hanya untuk satu tanggal, setiap modul dapat diakses oleh user yang berbeda)

UNF

Tr_Log = Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id + {Modul_Id + Aplikasi_id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi}

1 NF

Tr_Log = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id + @Modul_Id + Aplikasi_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan Reject + SQL_Cmd_Revisi

2 NF

Tr_Header_Log = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id

Tr_Detail_Log = @Form_Log_Id + @Modul_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi

Ms_Modul = @Modul_Id + Aplikasi_Id 3 NF

Tr_Header_Log = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id

Tr_Detail_Log = @Form_Log_Id + @Modul_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi

(61)

Ms_Modul = @Modul_Id + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul

Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id

Ms_Jenis_User = @Jenis_User_Id + Nama_Jenis_User

Ms_Aplikasi = @Aplikasi_Id + Nama_Aplikasi + Departemen_Id + Admin_Id + Status_Aplikasi

Ms_Departemen = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg + Status_Admin

Tr_Pnambahan_User (asumsi : setiap form hanya untuk satu tanggal) UNF

Tr_Pnambahan_User = Form_Pnambahan_Id + Tanggal_Transaksi + {User_Id + Nama_User + Pass_User + Departemen_Id + Admin_Id}

1 NF

Tr_Pnambahan_User = @Form_Pnambahan_Id + Tanggal_Transaksi + @User_Id + Nama_User + Pass_User + Departemen_Id + Admin_Id

2 NF

Tr_HPnambahan_User = @Form_Pnambahan_Id + Tanggal_Transaksi Tr_DPnambahan_User = @Form_Penambahan_Id + @User_Id

Ms_User = @User_Id + Nama_User + Pass_User+ Departemen_Id + Admin_Id

(62)

3 NF

Tr_HPnambahan_User = @Form_Penambahan_Id + Tanggal_Transaksi Tr_DPnambahan_User = @Form_Penambahan_Id + @User_Id

Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id

Ms_Department = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg

Tr_Permintaan_HA (asumsi : setiap form hanya berlaku untuk satu user) UNF

Tr_Permintaan_HA = Form_PermintaanHA_Id + User_Id + Admin_Id + {Tanggal_Transaksi + Modul_Id + Aplikasi_Id + Values + Status_Transaksi + Tanggal_Approval}

1NF

Tr_Permintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id + Tanggal_Transaksi + @Modul_Id + Aplikasi_Id + Values + Status_Transaksi + Tanggal_Approval

2 NF

Tr_HPermintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id Tr_DPermintaan_HA = @Form_PermintaanHA_Id + @Modul_Id + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi

(63)

3 NF

Tr_HPermintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id Tr_DPermintaan_HA = @Form_Permintaan_Id + @Modul_Id + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi

Ms_Modul = @Modul_Id + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul

Ms_Aplikasi = @Aplikasi_Id + Nama_Aplikasi + Departemen_Id + Status_Aplikasi + Admin_Id

Ms_Department = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id

Ms_Hak_Akses = @Hak_Akses_Id + User_Id + Modul_Id + Aplikasi_Id + Values + Is_Approval

Berikut ini adalah gambar ERD logikal dengan Primary Key dan Foreign Key-nya.

(64)

Gambar 4.10 ERD Logikal dengan Primary Key dan Foreign Key

4.3.2.4 Validasi Relasi terhadap Transaksi User

Semua transaksi user, seperti yang telah didefinisikan pada tahap konseptual, diperiksa kembali terhadap relasi yang ada untuk memastikan bahwa relasi sudah benar dan dapat memenuhi transaksi – transaksi yang dibutuhkan oleh user.

(65)

4.3.2.4.1 Data Entry

1. Memasukkan detail dari admin baru (seperti detail admin bernama Susan)

2. Memasukkan detail dari user baru (seperti detail user bernama Gunawan)

3. Memasukkan detail dari departemen baru (seperti detail departemen Back Office)

4. Memasukkan detail dari aplikasi baru (seperti detail aplikasi VOIP Binus)

5. Memasukkan detail dari modul baru (seperti detail modul User Online pada aplikasi VOIP Binus)

6. Memasukkan detail dari hak akses user baru (seperti detail hak akses pada modul User Online di aplikasi VOIP Binus pada user Gunawan)

7. Memasukkan detail dari jenis user baru (seperti detail jenis user Manager)

4.3.2.4.2 Data Update atau Deletion

1. Meng-update atau men-delete detail seorang admin 2. Meng-update atau men-delete detail seorang user 3. Meng-update atau men-delete detail sebuah departemen 4. Meng-update atau men-delete detail sebuah aplikasi 5. Meng-update atau men-delete detail sebuah modul

(66)

7. Meng-update atau men-delete detail sebuah jenis user

4.3.2.4.3 Data Queries

(a) Tampilkan detail user yang berada di departemen Lecturer (b) Tampilkan detail hak akses berdasarkan kode aplikasi Ap001 (c) Tampilkan detail modul yang terdapat di aplikasi Ap002 (d) Tampilkan admin id yang berada di departemen Lecturer

(e) Tampilkan detail penambahan user berdasarkan kode departemen Lecturer

(f) Tampilkan detail aplikasi yang berada di departemen Lecturer (g) Tampilkan daftar permintaan hak akses yang dilakukan oleh user

Us0001

(h) Tampilkan daftar permintaan hak akses selama sebulan terhadap aplikasi Ap001

(i) Tampilkan daftar transaksi log yang dilakukan oleh user Us0001 (j) Tampilkan daftar transaksi log selama sebulan terhadap aplikasi

Ap001

(k) Tampilkan user berdasarkan jenis user Mhs

(l) Tampilkan daftar admin yang memiliki status “aktif”

(m) Tampilkan daftar hak akses yang memiliki is_approval “Yes”

(n) Tampilkan daftar transaksi permintaan hak akses yang dilakukan pada tanggal 23 November 2007

(67)

Setelah melakukan pengecekan sekali lagi, penulis memastikan bahwa semua relasi sudah benar dan dapat memenuhi semua transaksi yang dibutuhkan user.

4.3.2.5 Mendefinisikan Kendala Integrity

Terdapat lima tipe dari kendala integrity antara lain: 4.3.2.5.1 Required Data

Beberapa atribut tertentu dari entiti atau relasi harus selalu mengandung nilai valid, dengan kata lain atribut tidak boleh mengandung nilai null. Constraint ini telah dilakukan pada saat kamus data atribut.

4.3.2.5.2 Attribute Domain Constraint

Setiap atribut mempunyai domain sendiri yaitu sekumpulan nilai yang sah untuk suatu atribut (tipe data dan panjang). Constraint ini telah ditentukan dalam tabel domain atribut.

4.3.2.5.3 Enterprise Constraint

Enterprise constraint yang dimaksudkan untuk memberi aturan atau batasan tambahan yang ditetapkan oleh user atau database administrator suatu database. Batasan yang diberikan hanya meliputi bahwa seorang admin hanya dapat menangani transaksi yang dilakukan oleh user yang berada di departemen yang sama dengannya. Tetapi tidak dibatasi berapa user yang ditangani oleh seorang admin.

(68)

4.3.2.5.4 Entiti Integrity

Entiti integrity dimaksudkan untuk mengecek primary key dari suatu entiti agar tidak boleh mengandung nilai null. Constraint ini telah ditentukan dalam kamus data atribut.

4.3.2.5.5 Referential Integrity

Referential integrity dimaksudkan untuk mengecek foreign key yang menghubungkan setiap tuple di dalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai primary key yang cocok.

Ms_Admin (Admin_Id, Nama_Admin, Pass_Admin, Tanggal_Reg, Status_Admin)

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id

Foreign Key Admin_Id references Ms_Admin (Admin_Id)

Ms_User (User_Id, Nama_User, Pass_User, Status_User, Tanggal_Register, Admin_Id, Jenis_User_Id, Departemen_Id)

Foreign Key Jenis_User_Id references Ms_Jenis_User (Jenis_User_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id)

(69)

User_Id)

Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id) Foreign Key Modul_Id references Ms_Modul (Modul_Id) Foreign Key User_Id references Ms_User (User_Id)

Ms_Modul (Modul_Id, Nama_Modul, Status_Modul, Admin_Id, Aplikasi_Id, Departemen_Id)

Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id)

Ms_Aplikasi (Aplikasi_Id, Nama_Aplikasi, Status_Aplikasi, Admin_Id, Departemen_Id)

Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Ms_Jenis_User (Jenis_User_Id, Nama_Jenis_User)

Primary Key Jenis_User_Id

Tr_Header_Log (Form_Log_Id, User_Id, Admin_Id, Tanggal_Transaksi) Primary Key Form_Log_Id

Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key User_Id references Ms_User (User_Id)

(70)

Tanggal_Approval, Alasan_Reject, SQL_Cmd_Revisi) Primary Key Form_Log_Id, Modul_Id

Foreign Key Form_Log_Id references Tr_Header_Log (Form_Log_Id) Foreign Key Modul_Id references Ms_Modul (Modul_Id)

Tr_HPnambahan_User (Form_Pnambahan_Id, Tanggal_Transaksi) Primary Key Form_Pnambahan_Id

Tr_DPnambahan_User (Form_Pnambahan_Id, User_Id) Primary Key Form_Pnambahan_Id, User_Id

Foreign Key Form_Pnambahan_Id references Tr_HPnambahan_User (Form_Pnambahan_Id)

Foreign Key User_Id references Ms_User (User_Id)

Tr_HPermintaan_HA (Form_PermintaanHA_Id, Admin_Id, User_Id) Primary Key Form_PermintaanHA_Id

Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key User_Id references Ms_User (User_Id)

Tr_DPermintaan_HA (Form_PermintaanHA_Id, Modul_Id, Values, Status_Transaksi, Tanggal_Approval, Tanggal_Trans, Alasan_Reject, Is_Approval)

Primary Key Form_PermintaanHA_Id, Modul_Id

Foreign Key Form_PermintaanHA_Id references Tr_DPermintaanHA (Form_PermintaanHA_Id)

Foreign Key Modul_Id references Ms_Modul (Modul_Id) Tabel 4.7 Referential Integrity

(71)

4.3.3 Perancangan Basis Data Fisikal

Proses menghasilkan sebuah deskripsi atau gambaran implementasi basis data pada media penyimpanan yang menggambarkan hubungan dasar, organisasi data, dan indeks – indeks yang memungkinkan pengaksesan data yang efisien. Pada umumnya, tujuan utama dari perancangan basis data fisikal adalah menjelaskan bagaimana kita bermaksud untuk mengimplementasikan perancangan basis data logikal secara fisik.

Pada perancangan basis data fisikal terdapat pembahasan perancangan Database Design Language (DBDL) untuk setiap entiti, perancangan constraint setiap entiti, analisis transaksi, pembuatan indeks, serta perancangan mekanisme keamanan data.

4.3.3.1 Menerjemahkan Model Logikal dalam DBMS

Bertujuan untuk membuat suatu skema basis data relasional dari model data logikal yang dapat diimplementasikan ke DBMS yang dituju.

4.3.3.1.1 Pemilihan DBMS

Berikut ini karakteristik DBMS MySQL 5.0.20 yang digunakan dalam desain fisikal ini.

MySQL 5.0.20

Tipe DBMS Transactional relational database server

(72)

Kebutuhan Piranti Keras Processor : Pentium 166 MHz (minimum)

Memori : 64 MB RAM (minimum) Hard disk Space: 145 MB (minimum), 380 MB (typical)

Kebutuhan Piranti Lunak Membutuhkan software Apache2Triad versi 1.5.4 untuk Windows versi 2000 ke atas.

Membutuhkan software updated phpMyAdmin to 2.7.0

Portability Dapat berjalan diatas berbagai macam OS.

Open Source Karena bersifat open source, maka tidak ada biaya license.

Multiuser Dapat digunakan oleh banyak user pada waktu yang bersamaan.

Security Mempunyai beberapa lapisan keamanan seperti level subnetmask, nama host, user permission, dan password ter-enkripsi.

Scalability & Limits Dapat menangani jumlah records lebih dari 50 juta dan jumlah tabel 60 ribu Graphical user interface Dapat menggunakan software sebagai

(73)

antarmuka grafis dengan user, sehingga memudahkan penggunaannya.

Tabel 4.8 Karakteristik MySQL 5.0.20

4.3.3.1.2 Merancang Relasi Dasar

Tujuan dari tahap ini adalah untuk merepresentasikan relasi dasar yang diidentifikasi pada model data logikal global ke dalam sasaran DBMS dengan menggunakan DBDL (Database Design Language). DBDL yang digunakan adalah sebagai berikut:

1. DBDL untuk Ms_Admin

Domain AdminId: fixed length character string, length 5 Domain NamaAdmin: variable length character string,

length 50

Domain PasswordAdmin: variable length character string, length 50

Domain TanggalRegister: variable date, format datetime

Domain StatusAdmin: variable length character string, length 8

Ms_Admin (

Admin_Id AdminId NOT NULL,

Nama_Admin NamaAdmin NOT NULL, Pass_Admin PasswordAdmin NOT NULL, Tanggal_Register TanggalRegister NOT NULL, Status_Admin StatusAdmin NOT NULL,

(74)

PRIMARY KEY (Admin_Id) );

2. DBDL untuk Ms_Departemen

Domain DepartemenId: variable length character string, length 5

Domain NamaDepartemen: variable length character string, length 50

Domain AdminId: fixed length character string, length 5

Ms_Departemen (

Departemen_Id DepartemenId NOT NULL, Nama_Departemen NamaDepartemen NOT NULL,

PRIMARY KEY (Departemen_Id),

FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION

);

3. DBDL untuk Ms_Modul

Domain ModulId: fixed length character string, length 5 Domain NamaModul: variable length character string,

(75)

Domain AplikasiId: fixed length character string, length 6 Domain DepartemenId: variable length character string,

length 5

Domain AdminId: fixed length character string, length 5 Domain StatusModul: variable length character string,

length 8 Ms_Modul (

Modul_Id ModulId NOT NULL,

Nama_Modul NamaModul NOT NULL, Aplikasi_Id AplikasiId NOT NULL, Departemen_Id DepartemenId NOT NULL,

Status_Modul StatusModul NOT NULL, PRIMARY KEY (Modul_Id),

FOREIGN KEY (Aplikasi_Id) REFERENCES Ms_Aplikasi (Aplikasi_Id) ON UPDATE CASCADE ON DELETE NO ACTION,

FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION,

(76)

4. DBDL untuk Ms_Aplikasi

Domain AplikasiId: fixed length character string, length 6 Domain NamaAplikasi: variable length character string,

length 50

Domain DepartemenId: variable length character string, length 5

Domain AdminId: fixed length character string, length 5 Domain StatusAplikasi: variable length character string,

length 8 Ms_Aplikasi (

Aplikasi_Id AplikasiId NOT NULL, Nama_Aplikasi NamaAplikasi NOT NULL, Departemen_Id DepartemenId NOT NULL,

Status_Aplikasi StatusAplikasi NOT NULL, PRIMARY KEY (Aplikasi_Id),

FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION,