BAB 4 PERANCANGAN SISTEM BASIS DATA

Transkripsi

1 BAB 4 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 78

2 79 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 Gambaran Sistem User Management Apporval System (UMAS) 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 81 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) 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 Gambar 4.4 Cross Functional Flowchart pada UMAS (Bagian 1) 82

6 Gambar 4.5 Cross Functional Flowchart pada UMAS (Bagian 2) 83

7 84 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 85 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 mengapprove 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 di-reject atau diapprove 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 86 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 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 87 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 Mengidentifikasikan Tipe Entiti Berikut ini merupakan tabel yang menjelaskan entiti-entiti yang digunakan dalam perancangan, antara lain: NAMA KETERANGAN ALIAS KEMUNCULAN ENTITAS Ms_Admin Merupakan entitas yang memberikan Admin Setiap departemen dikepalai oleh seorang informasi yang admin

11 88 NAMA KETERANGAN ALIAS KEMUNCULAN ENTITAS Ms_Departeme n berhubungan dengan admin Merupakan entitas yang mendeskripsikan Departemen Setiap bahagian yang terdapat di JWC dikelompokkan berdasarkan departemen yang departemen terdapat di JWC Ms_Aplikasi Merupakan entitas Aplikasi Setiap departemen memiliki yang beberapa aplikasi mendeskripsikan aplikasi yang terdapat di setiap departemen Ms_Modul Merupakan entitas Modul Setiap aplikasi terdiri dari yang beberapa modul mendeskripsikan modul yang terdapat di setiap aplikasi Ms_User Merupakan entitas User Setiap aplikasi diakses oleh yang memberikan user yang berada di

12 89 NAMA KETERANGAN ALIAS KEMUNCULAN ENTITAS informasi berhubungan yang departemen yang sama dengan aplikasi yang dengan user yang diaksesnya Ms_Jenis_User mengakses aplikasi di JWC Merupakan entitas yang memberikan Jenis User User dikelompokkan ke dalam beberapa jenis user informasi yang berhubungan dengan jenis jenis user yang mengakses aplikasi di JWC Ms_Hak_Akses Merupakan entitas Hak Akses Setiap user memiliki hak yang akses terhadap modul mendeskripsikan modul atau aplikasi yang hak akses yang ada dimiliki oleh tiap user Tr_Log Merupakan entitas yang memberikan Log Setiap transaksi yang dilakukan oleh user akan

13 90 NAMA KETERANGAN ALIAS KEMUNCULAN ENTITAS informasi mengenai proses melalui proses pengapprove-an terlebih dahulu peng-approve-an oleh admin daftar yang transaksi dilakukan oleh user Tr_Pnambahan Merupakan entitas Penambahan Penambahan user baru _User yang memberikan User informasi mengenai penambahan user baru Tr_Permintaan_ Merupakan entitas Permintaan Permintaan hak akses oleh HA yang memberikan Hak Akses user informasi mengenai permintaan hak akses oleh user Tabel 4.1 Kamus Data Entitas

14 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 Menggunakan Entity Relationship (ER) Diagram Berikut ini ERD konseptual yang memuat nama entitas beserta dengan hubungannya (relationship) adalah sebagai berikut :

15 92 Gambar 4.6 Entity Relationship (ER) Diagram Konseptual 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 93 mencantumkan tipe-tipe relasi yang terdapat pada perancangan basis data. Nama Entiti Multiplicity Relasi Nama Entiti Multiplicity Ms_Admin 1..1 Mengepalai Ms_Departemen Menangani Ms_Modul 1..* 1..1 Menangani Ms_Aplikasi 1..* 1..1 Menangani Ms_User 1..* 1..1 Menyetujui Tr_Log 0..* 1..1 Melakukan Tr_Penambahan_U 0..* ser 1..1 Menyetujui Tr_Permintaan_HA 0..* Ms_Departeme 1..1 Memiliki Ms_Modul 1..* n 1..1 Memiliki Ms_Aplikasi 1..* 1..1 Mempunyai Ms_User 1..* 1..1 Meliputi Tr_Pnambahan_Us 0..* er Ms_Modul 1..* Mempunyai Ms_Aplikasi Terdapat Ms_Hak_Akses 0..* 1..* Meliputi Tr_Log 0..* 1..* Meliputi Tr_Permintaan_HA 0..* Ms_Aplikasi 1..1 Terdapat Ms_Hak_Akses 0..* 1..* Meliputi Tr_Log 0..*

17 94 Nama Entiti Multiplicity Relasi Nama Entiti Multiplicity 1..* Meliputi Tr_Permintaan_HA 0..* Ms_User 1..* Terdiri dari Ms_Jenis_User Memiliki Ms_Hak_Akses 0..* 1..* Melakukan Tr_Log 0..* 1..1 Terdiri dari Tr_Pnambahan_Us 1..1 er 1..1 Melakukan Tr_Permintaan_HA 0..* Tabel 4.2 Pembatasan Multiplicity 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 Ms_Admin Admin_Id Kode Admin Char (5) Null Multi Value Nama_Admin Nama Admin Varchar(50) Pass_Admin Password Varchar(50) Admin Tanggal_Regist Tanggal Datetime

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

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

20 97 Entitas Atribut Deskripsi Tipe dan Panjang Data er Null Multi Value Ms_Hak_Aks Hak_Akses_Id Kode hak akses Int (5) es Modul_Id Kode modul Char (5) Aplikasi_Id Kode aplikasi Char (6) Values Aksi (terdiri Varchar (6) dari insert, update, delete) Is_Approval Status yang Varchar (3) menandakan suatu transaksi perlu mendapat tindakan approval atau tidak. User_Id Kode user Varchar(10) Tr_Log Form_Log_Id Kode formulir Int (5) transaksi log User_Id Kode user Varchar(10) Modul_Id Kode modul Char (5) Admin_Id Kode Admin Char (5) Jenis_Aksi Jenis aksi yang Varchar (6)

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

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

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

24 101 Entitas Atribut Deskripsi Tipe dan Panjang Data val terjadinya proses pengapprove-an permintaan hak akses oleh admin Null Multi Value Alasan_Reject Alasan kenapa Text Yes me-reject suatu permintaan Is_Approval Status yang Varchar(3) Yes diberikan terhadap suatu permintaan apakah perlu mendapat tindakan approval atau tidak. Tabel 4.3 Identifikasi Atribut dan Asosiasi Atribut Suatu Entiti

25 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 Ms_Departemen Ms_Modul Admin_Id Nama_Admin Pass_Admin Tanggal_Reg Status_Admin Departemen_Id Nama_Departemen Admin_Id Modul_Id Nama_Modul 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 ) Maksimum 10 karakter Maksimum 50 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Terdiri dari 5 karakter Maksimum 50 karakter

26 103 Entiti Atribut Domain Aplikasi_Id Terdiri dari 6 karakter, di mana 2 karakter pertama berupa huruf A dan p dan 4 karakter terakhir berupa angka Departemen_Id Admin_Id Maksimum 10 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama berupa huruf dan 3 karakter terakhir berupa angka Status_Modul Maksimum 8 karakter Ms_Aplikasi Aplikasi_Id Nama_Aplikasi Departemen_Id Admin_Id (berupa aktif atau nonaktif ) 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 104 Entiti Atribut Domain berupa huruf dan 3 karakter terakhir berupa angka Status_Aplikasi Maksimum 8 karakter Ms_User Ms_Jenis_User User_Id Nama_User Pass_User Status_User Jenis_User_Id Tanggal_Register Departemen_Id Admin_Id Jenis_User_Id Nama_Jenis_User (berupa aktif atau nonaktif ) 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 Maksimum 5 karakter Maksimum 20 karakter Ms_Hak_Akses Hak_Akses_Id Berupa angka, maksimum 10 digit

28 105 Entiti Atribut Domain Modul_Id Aplikasi_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 Values Maksimum 6 karakter (berupa insert atau update atau delete ) Is_Approval Maksimum 3 karakter(berupa yes atau no ) Tr_Log User_Id Form_Log_Id User_Id Modul_Id Admin_Id Jenis_Aksi Maksimum 10 karakter 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 106 Entiti Atribut Domain (berupa insert atau update atau delete ) SQL_Cmd Tanggal_Trans Status_Trans Berupa text yyyy-mm-dd dan hh:mm:ss Maksimum 8 karakter (berupa aktif atau nonaktif Tanggal_Approval Aplikasi_Id 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 Tr_Pnambahan_User Alasan_Reject SQL_Cmd_Revisi Form_Penambahan_Id User_Id Nama_User Pass_User Admin_Id Berupa text Berupa text Berupa angka, maksimum 5 digit Maksimum 10 karakter Maksimum 50 karakter Maksimum 50 karakter Terdiri dari 5 karakter, di mana 2 karakter pertama

30 107 Entiti Atribut Domain berupa huruf dan 3 karakter terakhir berupa angka Tr_Permintaan_HA Departemen_Id Tanggal_Transaksi Form_PermintaanHA_Id User_Id Modul_Id Aplikasi_Id Values Status_Transaksi Admin_Id Maksimum 10 karakter yyyy-mm-dd dan hh:mm:ss Berupa angka, maksimum 5 digit 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 108 Entiti Atribut Domain terakhir berupa angka Tanggal_Transaksi Tanggal_Approval Alasan_Reject Is_Approval 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 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 Ms_Modul Ms_Aplikasi Departemen_Id Admin_Id Modul_Id Aplikasi_Id Departemen_Id Admin_Id Aplikasi_Id Departemen_Id Departemen_Id Modul_Id Aplikasi_Id

32 109 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 Tr_Log Tr_Pnambahan_User Tr_Permintaan_HA Hak_Akses_Id Aplikasi_Id User_Id Modul_Id Form_Log_Id User_Id Modul_Id Admin_Id Form_Penambahan_Id User_Id Admin_Id Departemen_Id Form_PermintaanHA_Id User_Id Modul_Id Aplikasi_Id Hak_Akses_Id Form_Log_Id Form_Penambaha n_id Form_Permintaan HA_Id

33 110 Entity Candidate Key Primary Key Admin_Id Tabel 4.5 Identifikasi Candidate dan Primary Key Gambar 4.7 Entity Relationship (ER) Diagram dengan Primary Key

34 Validasi Model Konseptual Data Lokal Terhadap Transaksi User 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) 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 Meng-update atau men-delete detail sebuah hak akses user 7. Meng-update atau men-delete detail sebuah jenis user 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 vember 2007

36 Gambar 4.8 ER Diagram Konseptual dengan Primary Key dan Transaction Pathway 113

37 114 Gambar 4.9 ER Diagram Konseptual Perancangan Basis Data Logikal Menghilangkan Fitur Tidak Kompatibel Memperbaiki model data konseptual lokal untuk menghilangkan fitur-fitur yang tidak kompatibel dengan model relasional.

38 Menghilangkan Many-to-many (*:*) Binary Relationship Types Bila dalam model konseptual masih terdapat hubungan many-tomany (*:*) 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) Keterangan : a. Kondisi Awal b. Kondisi Akhir

39 116 Hubungan Tr_Permintaan_HA dengan Ms_Aplikasi (a) (b) Keterangan : a. Kondisi Awal b. Kondisi Akhir Hubungan Tr_Permintaan_HA dengan Ms_Modul (a) (b) Keterangan : a. Kondisi Awal b. Kondisi Akhir

40 Menentukan Relasi Untuk Model Data Logikal Global 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) Primary Key User_Id

41 118 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 Weak Entity Types Untuk setiap weak entity di dalam model data, buat sebuah relasi yang memasukkan semua atribut sederhana pada entitas tersebut.

42 119 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) 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 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, Ms_User (User_Id, Admin_Id, Pass_Admin, Tanggal_Reg, Nama_User, Pass_User, Status_Admin) Status_User, Tanggal_Register, Primary Key Admin_Id 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, Ms_Aplikasi (Aplikasi_Id, Nama_Admin, Pass_Admin, Nama_Aplikasi, Admin_Id, Tanggal_Reg, Status_Admin) Primary Key Admin_Id Departemen_Id, Status_Aplikasi) Primary Key Aplikasi_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id)

44 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, Ms_Modul (Modul_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id Foreign Key Admin_Id references Nama_Modul, Aplikasi_Id, Status_Modul) Departemen_Id, Admin_Id, Ms_Admin (Admin_Id) Primary Key Modul_Id 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_Departemen (Departemen_Id, Ms_Aplikasi (Aplikasi_Id, Nama_Departemen, Admin_Id) Nama_Aplikasi, Departemen_Id, Primary Key Departemen_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id) Admin_Id, Status_Aplikasi) Primary Key Aplikasi_Id Foreign Key Departemen_Id references Ms_Departemen

45 122 (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_Departemen (Departemen_Id, Ms_User (User_Id, Nama_User, Nama_Departemen, Admin_Id) Primary Key Departemen_Id Pass_User, Status_User, Departemen_Id, Tanggal_Register, Foreign Key Admin_Id references Ms_Admin (Admin_Id) Jenis_User_Id, Admin_Id) Primary Key User_Id Foreign Key Departemen_Id references Ms_Departemen (Departemen_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_Aplikasi (Aplikasi_Id, Ms_Modul (Modul_Id, Nama_Aplikasi, Departemen_Id, Nama_Modul, Aplikasi_Id, Admin_Id, Status_Aplikasi) Primary Key Aplikasi_Id Departemen_Id, Status_Modul) Admin_Id,

46 123 Foreign Key Departemen_Id Primary Key Modul_Id references Ms_Departemen Foreign Key Aplikasi_Id (Departemen_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) references (Aplikasi_Id) Ms_Aplikasi 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, Ms_Hak_Akses (Hak_Akses_Id, Nama_Modul, Departemen_Id, Status_Modul) Primary Key Modul_Id Aplikasi_Id, Admin_Id, Aplikasi_Id, Values, Modul_Id, User_Id, Is_Approval) Primary Key Hak_Akses_Id Foreign Key Modul_Id references Foreign Key Aplikasi_Id references Ms_Modul (Modul_Id) Ms_Aplikasi (Aplikasi_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id)

47 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_Aplikasi (Aplikasi_Id, Ms_Hak_Akses (Hak_Akses_Id, Nama_Aplikasi, Departemen_Id, Values, User_Id, Aplikasi_Id, Admin_Id, Status_Aplikasi) Primary Key Aplikasi_Id Foreign Key Departemen_Id Is_Approval, Modul_Id) Primary Key Hak_Akses_Id Foreign Key Aplikasi_Id references Ms_Departemen references Ms_Aplikasi (Departemen_Id) (Aplikasi_Id) Foreign Key Admin_Id references Ms_Admin (Admin_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, Ms_User (User_Id, Nama_User, Nama_Jenis_User) Primary Key Jenis_User_Id Pass_User, Status_User, Jenis_User_Id, Tanggal_Register, Departemen_Id, Admin_Id) Primary Key User_Id

48 125 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, Ms_Modul (Modul_Id, Nama_Admin, Pass_Admin, Nama_Modul, Admin_Id, Tanggal_Reg, Status_Admin) Primary Key Admin_Id Status_Modul, Aplikasi_Id,) Departemen_Id, Primary Key Modul_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, Ms_Hak_Akses (Hak_Akses_Id, Pass_User, Status_User, Tanggal_Register, Departemen_Id, Values, Is_Approval, User_Id, Aplikasi_Id, Admin_Id)

49 126 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 Ms_Admin Nama_Admin, (Admin_Id, Pass_Admin, Tr_Permintaan_HA (Form_PermintaanHA_Id, Values, Tanggal_Reg, Status_Admin) Primary Key Admin_Id Status_Transaksi, Tanggal_Transaksi, Tanggal_Approval, Admin_Id, Is_Approval, User_Id, Modul_Id, Aplikasi_Id, Alasan_Reject) Primary Key Form_PermintaanHA_Id Foreign Key Admin_Id references Ms_Admin(Admin_Id)

50 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, Tr_Permintaan_HA Pass_User, Tanggal_Register, (Form_PermintaanHA_Id, User_Id, Status_User, Departemen_Id, Values, Status_Transaksi, Jenis_User_Id, Admin_Id) Primary Key User_Id 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, Tr_Log (Form_Log_Id, Pass_User, Tanggal_Register, Jenis_Aksi, SQL_Cmd, User_Id, Status_User, Departemen_Id, Status_Trans, Tanggal_Trans,

51 128 Jenis_User_Id, Admin_Id) Primary Key User_Id Tanggal_Approval, Aplikasi_Id, Modul_Id, Admin_Id, Alasan_Reject, SQL_Cmd_Revisi) Primary Key Form_Log_Id 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 Ms_Admin (Admin_Id, Tr_Log (Form_Log_Id, Nama_Admin, Pass_Admin, Jenis_Aksi, SQL_Cmd, Admin_Id, Tanggal_Reg, Status_Admin) Primary Key Admin_Id Status_Trans, Tanggal_Approval, Modul_Id, Tanggal_Trans, User_Id, Aplikasi_Id, Alasan_Reject, SQL_Cmd_Revisi) Primary Key Form_Log_Id Foreign Key Admin_Id references Ms_Admin(Admin_Id)

52 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 Ms_Admin Nama_Admin, (Admin_Id, Pass_Admin, Tr_Pnambahan_User (Form_Pnambahan_Id, Admin_Id, Tanggal_Reg, Status_Admin) Primary Key Admin_Id Nama_User, Tanggal_Transaksi, Departemen_Id ) Primary Form_Pnambahan_Id Pass_User, User_Id, Key Foreign Key Admin_Id references Ms_Admin(Admin_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 Ms_Departemen (Departemen_Id, Tr_Pnambahan_User Nama_Departemen, Admin_Id) (Form_Pnambahan_Id, Primary Key Departemen_Id Nama_User, Pass_User, Departemen_Id, Tanggal_Transaksi,

53 130 User_Id, Admin_Id) Primary Key Form_Pnambahan_Id Foreign Key Departemen_Id references Ms_Departemen(Departemen_Id) 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 Nama_Admin, (Admin_Id, Pass_Admin, Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Tanggal_Reg, Status_Admin) Primary Key Admin_Id Primary Key Departemen_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id)

54 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 Ms_User (User_Id, Nama_User, Tr_Pnambahan_User Pass_User, Status_User, (Form_Pnambahan_Id, User_Id, Tanggal_Register, Departemen_Id, Nama_User, Pass_User, Admin_Id, Jenis_User_Id, Admin_Id) Primary Key User_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id) Departemen_Id, Tanggal_Transaksi) Primary Form_Penambahan_Id Key Foreign Key Jenis_User_Id Foreign Key User_Id references references (Jenis_User_Id) Ms_Jenis_User Ms_User (User_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) 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 Relasi Ms_Modul dengan Tr_Log Ms_Modul (Modul_Id, Nama_Modul, Status_Modul, Aplikasi_Id, Departemen_Id, Admin_Id) Primary Key Modul_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) Primary Key Form_Log_Id 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) Primary Key Aplikasi_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) Primary Key Form_Log_Id Foreign Key Modul_Id references Ms_Modul (Modul_Id) Ms_Modul(Modul_Id) Primary Key Modul_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

56 Relasi Ms_Modul dengan Tr_Permintaan_HA Ms_Modul (Modul_Id, Nama_Modul, Status_Modul, Tr_Permintaan_HA (Form_PermintaanHA_Id, Values, Aplikasi_Id, Departemen_Id, Admin_Id) Tanggal_Transaksi, Status_Transaksi, Primary Key Modul_Id Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject, Is_Approval) Primary Key Form_PermintaanHA_Id 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, Tr_Permintaan_HA (Form_PermintaanHA_Id, Values, Status_Aplikasi, Departemen_Id, Admin_Id) Tanggal_Transaksi, Status_Transaksi, Primary Key Aplikasi_Id Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id, Admin_Id, Alasan_Reject, Is_Approval) Primary Key Form_PermintaanHA_Id Foreign Key Modul_Id references Ms_Modul (Modul_Id) Ms_Modul(Modul_Id) Primary Key Modul_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

57 134 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 Foreign Key Admin_Id references Ms_Modul (Modul_Id, Nama_Modul, Aplikasi_Id, Departemen_Id, Admin_Id, Ms_Admin (Admin_Id) Ms_Aplikasi Nama_Aplikasi, (Aplikasi_Id, Departemen_Id, Status_Modul) Primary Key Modul_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Admin_Id, Status_Aplikasi) Primary Key Aplikasi_Id Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Ms_User (User_Id, Nama_User, Ms_Jenis_User (Jenis_User_Id, Pass_User, Tanggal_Register, Status_User, Departemen_Id, Nama_Jenis_User) Primary Key Jenis_User_Id Jenis_User_Id, Admin_Id) Primary Key User_Id Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Foreign Key Jenis_User_Id references

58 135 Ms_Jenis_User (Jenis_User_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Ms_Hak_Akses (Hak_Akses_Id, Tr_Log (Form_Log_Id, User_Id, Aplikasi_Id, Values, User_Id, Modul_Id, Admin_Id, Jenis_Aksi, Is_Approval, Modul_Id) Primary Key Hak_Akses_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id) SQL_Cmd, Status_Trans, Aplikasi_Id, SQL_Cmd_Revisi)) Tanggal_Trans, Tanggal_Approval, Alasan_Reject, Foreign Key User_Id references Ms_User (User_Id) Foreign Key Modul_Id references Ms_Modul (Modul_Id) Primary Key Form_Log_Id Foreign Key User_Id references Ms_User (User_Id) Foreign Key Modul_Id references Ms_Modul (Modul_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id) Tr_Pnambahan_User Tr_Permintaan_HA (Form_Pnambahan_Id, User_Id, (Form_PermintaanHA_Id, User_Id, Nama_User, Pass_User, Admin_Id, Modul_Id, Aplikasi_Id, Values, Departemen_Id, Tanggal_Transaksi) Status_Transaksi, Admin_Id, Primary Key Form_Penambahan_Id Tanggal_Transaksi, Tanggal_Approval,

59 136 Foreign Key User_Id references Ms_User (User_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Alasan_Reject, Is_Approval) Primary Key Form_PermintaanHA_Id Foreign Key User_Id references Ms_User (User_Id) Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id) Foreign Key Modul_Id references Ms_Modul (Modul_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id) Tabel 4.6 Dokumentasi Relasi dan Atribut Foreign Key Validasi Model dengan rmalisasi 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 137 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 + Tanggal_Trans + User_Id + Admin_Id + Aplikasi_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan Reject + SQL_Cmd_Revisi 2 NF Tr_Header_Log + Tanggal_Trans + User_Id + Admin_Id Tr_Detail_Log + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi Ms_Modul + Aplikasi_Id 3 NF Tr_Header_Log + Tanggal_Trans + User_Id + Admin_Id Tr_Detail_Log + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi

61 138 Ms_Modul + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul Ms_User + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User + Nama_Jenis_User Ms_Aplikasi + Nama_Aplikasi + Departemen_Id + Admin_Id + Status_Aplikasi Ms_Departemen + Nama_Departemen + Admin_Id Ms_Admin + 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 + Tanggal_Transaksi + Nama_User + Pass_User + Departemen_Id + Admin_Id 2 NF Tr_HPnambahan_User + Tanggal_Transaksi Tr_DPnambahan_User Ms_User + Nama_User + Pass_User+ Departemen_Id + Admin_Id

62 139 3 NF Tr_HPnambahan_User + Tanggal_Transaksi Tr_DPnambahan_User Ms_User + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User + Nama_Jenis_User Ms_Department + Nama_Departemen + Admin_Id Ms_Admin + 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 + User_Id + Admin_Id + Tanggal_Transaksi + Aplikasi_Id + Values + Status_Transaksi + Tanggal_Approval 2 NF Tr_HPermintaan_HA + User_Id + Admin_Id Tr_DPermintaan_HA + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi Ms_Modul + Departemen_Id

63 140 3 NF Tr_HPermintaan_HA + User_Id + Admin_Id Tr_DPermintaan_HA + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi Ms_Modul + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul Ms_Aplikasi + Nama_Aplikasi + Departemen_Id + Status_Aplikasi + Admin_Id Ms_Department + Nama_Departemen + Admin_Id Ms_Admin + Nama_Admin + Pass_Admin + Tanggal_Reg Ms_User + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User + Nama_Jenis_User Ms_Hak_Akses + User_Id + Modul_Id + Aplikasi_Id + Values + Is_Approval Berikut ini adalah gambar ERD logikal dengan Primary Key dan Foreign Key-nya.

64 141 Gambar 4.10 ERD Logikal dengan Primary Key dan Foreign Key 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 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) 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 6. Meng-update atau men-delete detail sebuah hak akses user

66 Meng-update atau men-delete detail sebuah jenis user 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 vember 2007

67 144 Setelah melakukan pengecekan sekali lagi, penulis memastikan bahwa semua relasi sudah benar dan dapat memenuhi semua transaksi yang dibutuhkan user Mendefinisikan Kendala Integrity Terdapat lima tipe dari kendala integrity antara lain: 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 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 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 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 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) Primary Key Admin_Id 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) Primary Key User_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id) Foreign Key Jenis_User_Id references Ms_Jenis_User (Jenis_User_Id) Foreign Key Departemen_Id references Ms_Departemen (Departemen_Id) Ms_Hak_Akses (Hak_Akses_Id, Values, Is_Approval, Aplikasi_Id, Modul_Id,

69 146 User_Id) Primary Key Hak_Akses_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) Primary Key Modul_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) Primary Key Aplikasi_Id Foreign Key Admin_Id references Ms_Admin (Admin_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) Tr_Detail_Log (Form_Log_Id, Modul_Id, Jenis_Aksi, SQL_Cmd, Status_Trans,

70 147 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 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 Menerjemahkan Model Logikal dalam DBMS Bertujuan untuk membuat suatu skema basis data relasional dari model data logikal yang dapat diimplementasikan ke DBMS yang dituju Pemilihan DBMS Berikut ini karakteristik DBMS MySQL yang digunakan dalam desain fisikal ini. MySQL Tipe DBMS Transactional relational database server

72 149 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 untuk Windows versi 2000 ke atas. Membutuhkan software updated phpmyadmin to 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 terenkripsi. Scalability & Limits Dapat menangani jumlah records lebih dari 50 juta dan jumlah tabel 60 ribu Graphical user interface Dapat menggunakan software sebagai

73 150 antarmuka grafis dengan user, sehingga memudahkan penggunaannya. Tabel 4.8 Karakteristik MySQL 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 151 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, Admin_Id AdminId 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, length 50

75 152 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, Admin_Id AdminId 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, FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION );

76 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, Admin_Id AdminId 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, FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION );

77 DBDL untuk Ms_User Domain UserId: variable length character string, length 10 Domain NamaUser: variable length character string, length 50 Domain PasswordUser: variable length character string, length 50 Domain StatusUser: variable length character string, length 8 Domain JenisUserId: variable length character string, length 5 Domain TanggalRegister: variable date, format datetime Domain DepartemenId: variable length character string, length 5 Domain AdminId: fixed length character string, length 5 Ms_User ( User_Id UserId NOT NULL, Nama_User NamaUser NOT NULL, Pass_User PasswordUser NOT NULL, Status_User StatusUser NOT NULL, Jenis_User_Id JenisUserId NOT NULL, Tanggal_Register TanggalRegister NOT NULL, Departemen_Id DepartemenId NOT NULL, Admin_Id AdminId NOT NULL,

78 155 PRIMARY KEY (User_Id), FOREIGN KEY (Jenis _User_Id) REFERENCES Ms_Jenis_User (Jenis_User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION ); 6. DBDL untuk Ms_Jenis_User Domain JenisUserId: variable length character string, length 5 Domain NamaJenisUser: variable length character string, length 20 Ms_Jenis_User ( Jenis_User_Id JenisUserId NOT NULL, Nama_Jenis_User NamaJenisUser NOT NULL, PRIMARY KEY (Jenis_User_Id) );

79 DBDL untuk Ms_Hak_Akses Domain HakAksesId: integer, in the range Domain ModulId: fixed length character string, length 5 Domain AplikasiId: fixed length character string, length 6 Domain Values: variable length character string, length 6 Domain IsApproval: variable length character string, length 3 Domain UserId: variable length character string, length 10 Ms_Hak_Akses ( Hak_Akses_Id HakAksesId NOT NULL, Modul_Id ModulId NOT NULL, Aplikasi_Id AplikasiId NOT NULL, Values Values NOT NULL, Is_Approval IsApproval NOT NULL, User_Id UserId NOT NULL, PRIMARY KEY (Hak_Akses_ Id ), FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION,

80 157 FOREIGN KEY (Aplikasi_Id) REFERENCES Ms_Aplikasi (Aplikasi_Id) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION ); 8. DBDL untuk Tr_Header_Log Domain FormLogId: integer, in the range Domain UserId: variable length character string, length 10 Domain TanggalTrans: variable date, format datetime Domain AdminId: fixed length character string, length 5 Tr_Header_Log ( Form_Log_Id FormLogId NOT NULL, User_Id UserId NOT NULL, Tanggal_Trans TanggalTrans NOT NULL, Admin_Id AdminId NOT NULL, PRIMARY KEY (Form_Log_Id), FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION

81 158 ); 9. DBDL untuk Tr_Detail_Log Domain FormLogId: integer, in the range Domain ModulId: fixed length character string, length 5 Domain JenisAksi: variable length character string, length 6 Domain SqlCmd: TEXT Domain StatusTrans: variable length character string, length 7 Domain TanggalApprove: variable date, format datetime Domain SqlCmdRevisi: Domain AlasanReject: TEXT TEXT Tr_Detail_Log ( Form_Log_Id FormLogId NOT NULL, Modul_Id ModulId NOT NULL, Jenis_Aksi JenisAksi NOT NULL, Sql_Cmd SqlCmd NOT NULL, Status_Trans StatusTrans NOT NULL, Tanggal_Approve TanggalApprove NOT NULL, Sql_Cmd_Revisi SqlCmdRevisi NOT NULL, Alasan_Reject AlasanReject NOT NULL, PRIMARY KEY (Form_Log_Id),

82 159 FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION ); 10. DBDL untuk Tr_Hpnambahan_User Domain FormPnambahanId: integer, in the range Domain TanggalTrans: variable date, format datetime Tr_Hpnambahan_User ( Form_Pnambahan_Id FormPnambahanId NOT NULL, Tanggal_Trans TanggalTrans NOT NULL, PRIMARY KEY (Form_Pnambahan_Id) ); 11. DBDL untuk Tr_Dpnambahan_User Domain FormPnambahanId: integer, in the range Domain UserId: variable length character string, length 10 Domain NamaUser: variable length character string, length 50 Tr_Dpnambahan_User ( Form_Pnambahan_Id FormPnambahanId NOT NULL, User_Id UserId NOT NULL,

83 160 PRIMARY KEY (Form_Pnambahan_Id ), FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION ); 12. DBDL untuk Tr_HPermintaan_HA Domain FormPermintaanHAId: integer, in the range Domain UserId: variable length character string, length 10 Domain AdminId: fixed length character string, length 5 Tr_HPermintaan_HA ( Form_PermintaanHA_Id FormPermintaanHAId NOT NULL, User_Id UserId NOT NULL, Admin_Id AdminId NOT NULL, PRIMARY KEY (Form_PermintaanHA_Id ), FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION );

84 DBDL untuk Tr_DPermintaan_HA Domain FormPermintaanHAId: integer, in the range Domain ModulId fixed length character string, length 5 Domain Value variable length character string, length 6 Domain StatusTrans variable length character string, length 7 Domain TanggalApprove Domain TanggalTrans Domain AlasanReject variable date, format datetime variable date, format datetime TEXT Domain IsApproval variable length character Tr_DPermintaan_HA ( string, length 3 Form_PermintaanHA_Id FormPermintaanHAId NOT NULL, Modul_Id ModulId NOT NULL, Values Values NOT NULL, Status_Trans StatusTrans NOT NULL, Tanggal_Approve TanggalApprove NOT NULL, Tanggal_Trans TanggalTrans NOT NULL, Alasan_Reject AlasanReject NOT NULL, Is_Approval IsApproval NOT NULL, PRIMARY KEY (Form_PermintaanHA_Id ),

85 162 FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION ); Perancangan Constraints Langkah ini bertujuan untuk merancang constraint untuk sasaran dalam DBMS. Berikut ini merupakan perancangan constraints yang terdapat dalam suatu entiti, antara lain: 1. Constraint untuk Ms_Admin CREATE TABLE Ms_Admin ( Admin_Id CHAR (5) Nama_Admin VARCHAR (50) Pass_Admin VARCHAR (50) Tanggal_Register DATETIME Status_Admin VARCHAR (8) CONSTRAINT PK Ms_Admin PRIMARY KEY (Admin_Id) ) 2. Constraint untuk Ms_Departemen CREATE TABLE Ms_Departemen ( Departemen_Id VARCHAR (5) Nama_Departemen VARCHAR (50) Admin_Id CHAR (5)

86 163 CONSTRAINT PK Ms_Departemen PRIMARY KEY (Departemen_Id) CONSTRAINT FK Ms_Departemen FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 3. Constraint untuk Ms_Modul CREATE TABLE Ms_Modul ( Modul_Id CHAR (5) Nama_Modul VARCHAR (50) Aplikasi_Id CHAR (6) Departemen_Id VARCHAR (5) Admin_Id CHAR (5) Status_Modul VARCHAR (8) CONSTRAINT PK Ms_Modul PRIMARY KEY (Modul_Id) CONSTRAINT FK Ms_Modul FOREIGN KEY (Aplikasi_Id) REFERENCES Ms_Aplikasi (Aplikasi_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_Modul FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION,

87 164 CONSTRAINT FK Ms_Modul FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 4. Constraint untuk Ms_Aplikasi CREATE TABLE Ms_Aplikasi ( Aplikasi_Id CHAR (6) Nama_Aplikasi VARCHAR (50) Departemen_Id VARCHAR (5) Admin_Id CHAR (5) Status_Aplikasi VARCHAR (8) CONSTRAINT PK Ms_Aplikasi PRIMARY KEY (Aplikasi_Id) CONSTRAINT FK Ms_Aplikasi FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_Aplikasi FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION )

88 Constraint untuk Ms_User CREATE TABLE Ms_User ( User_Id VARCHAR (10) Nama_User VARCHAR (50) Pass_User VARCHAR (50) Status_User VARCHAR (8) Jenis_User_Id VARCHAR (5) Tanggal_Register DATETIME Departemen_Id VARCHAR (5) Admin_Id CHAR (5) CONSTRAINT PK Ms_User PRIMARY KEY (User_Id) CONSTRAINT FK Ms_User FOREIGN KEY (Jenis_User_Id) REFERENCES Ms_Jenis_User (Jenis_User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_User FOREIGN KEY (Departemen_Id) REFERENCES Ms_Departemen (Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_User FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION )

89 Constraint untuk Ms_Jenis_User CREATE TABLE Ms_Jenis_User ( Jenis_User_Id VARCHAR (5) Nama_Jenis_User VARCHAR (20) CONSTRAINT PK Ms_Jenis_User PRIMARY KEY (Jenis_User_Id) ) 7. Constraint untuk Ms_Hak_Akses CREATE TABLE Ms_Hak_Akses ( Hak_Akses_Id INT (5) Modul_Id CHAR (5) Aplikasi_Id CHAR (6) Values VARCHAR (6) CONSTRAINT PK Ms_Hak_Akses PRIMARY KEY (Hak_Akses_Id) CONSTRAINT FK Ms_Hak_Akses FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_Hak_Akses FOREIGN KEY (Aplikasi_Id) REFERENCES Ms_Aplikasi (Aplikasi_Id) ON UPDATE CASCADE ON DELETE NO ACTION )

90 Constraint untuk Tr_Header_Log CREATE TABLE Tr_Header_Log ( Form_Log_Id INT (5) User_Id VARCHAR (10) Tanggal_Trans DATETIME Admin_Id CHAR (5) CONSTRAINT PK Tr_Header_Log PRIMARY KEY (Form_Log_Id) CONSTRAINT FK Tr_Header_Log FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Tr_Header_Log FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 9. Constraint untuk Tr_Detail_Log CREATE TABLE Tr_Detail_Log ( Form_Log_Id INT (5) Modul_Id CHAR (5) Jenis_Aksi VARCHAR (6) Sql_Cmd TEXT Status_Trans VARCHAR (7) Tanggal_Approve DATETIME

91 168 Sql_Cmd_Revisi TEXT Alasan_Reject TEXT CONSTRAINT PK Tr_Detail_Log PRIMARY KEY (Form_Log_Id) CONSTRAINT FK Tr_Detail_Log FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 10. Constraint untuk Tr_Hpnambahan_User CREATE TABLE Tr_Hpnambahan_User ( Form_Pnambahan_Id INT (5) Tanggal_Trans DATETIME CONSTRAINT PK Tr_Hpnambahan_User PRIMARY KEY (Form_Pnambahan_Id) ) 11. Constraint untuk Tr_Dpnambahan_User CREATE TABLE Tr_Dpnambahan_User ( Form_Pnambahan_Id INT (5) User_Id VARCHAR (10) Nama_User VARCHAR (50) CONSTRAINT PK Tr_Dpnambahan_User PRIMARY KEY (Form_Pnambahan_Id)

92 169 CONSTRAINT FK Tr_Dpnambahan_User FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 12. Constraint untuk Tr_Hpermintaan_HA CREATE TABLE Tr_Hpermintaan_HA ( Form_PermintaanHA_Id INT (5) User_Id VARCHAR (10) Admin_Id CHAR (5) CONSTRAINT PK Tr_Hpermintaan_HA PRIMARY KEY (Form_PermintaanHA_Id) CONSTRAINT FK Tr_Hpermintaan_HA FOREIGN KEY (User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Tr_Hpermintaan_HA FOREIGN KEY (Admin_Id) REFERENCES Ms_Admin (Admin_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) 13. Constraint untuk Tr_Dpermintaan_HA CREATE TABLE Tr_Dpermintaan_HA ( Form_PermintaanHA_Id INT (5) Modul_Id CHAR (5)

93 170 Values VARCHAR (6) Status_Trans VARCHAR (7) Tanggal_Approve DATETIME Tanggal_Trans DATETIME Alasan_Reject TE XT Is_Approval VARCHAR (3) CONSTRAINT PK Tr_Dpermintaan_HA PRIMARY KEY (Form_PermintaanHA_Id) CONSTRAINT FK Tr_Dpermintaan_HA FOREIGN KEY (Modul_Id) REFERENCES Ms_Modul (Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION ) Representasi Fisikal Langkah ini bertujuan untuk menentukan organisasi file optimal untuk menyimpan relasi relasi dasar beserta indeks indeksnya yang diperlukan untuk mencapai performa yang dapat diterima, yaitu sebuah cara dimana relasi relasi dan baris- baris akan disimpan pada secondary storage Analisis Transaksi Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari transaksi yang akan berjalan pada basis data untuk menganalisa

94 171 transaksi yang penting. Transaksi transaksi yang terjadi adalah sebagai berikut: Data Entry A. Memasukkan detail dari admin baru (seperti detail admin bernama Susan) B. Memasukkan detail dari user baru (seperti detail user bernama Gunawan) C. Memasukkan detail dari departemen baru (seperti detail departemen Back Office) D. Memasukkan detail dari aplikasi baru (seperti detail aplikasi VOIP Binus) E. Memasukkan detail dari modul baru (seperti detail modul User Online pada aplikasi VOIP Binus) F. Memasukkan detail dari hak akses user baru (seperti detail hak akses pada modul User Online di aplikasi VOIP Binus pada user Gunawan) G. Memasukkan detail dari jenis user baru (seperti detail jenis user Manager) Data Update atau Deletion H. Meng-update atau men-delete detail seorang admin I. Meng-update atau men-delete detail seorang user J. Meng-update atau men-delete detail sebuah departemen K. Meng-update atau men-delete detail sebuah aplikasi

95 172 L. Meng-update atau men-delete detail sebuah modul M. Meng-update atau men-delete detail sebuah hak akses user N. Meng-update atau men-delete detail sebuah jenis user Data Queries O. Tampilkan detail user yang berada di departemen Lecturer P. Tampilkan detail hak akses berdasarkan kode aplikasi Ap001 Q. Tampilkan detail modul yang terdapat di aplikasi Ap002 R. Tampilkan admin id yang berada di departemen Lecturer S. Tampilkan detail penambahan user berdasarkan kode departemen Lecturer T. Tampilkan detail aplikasi yang berada di departemen Lecturer U. Tampilkan daftar permintaan hak akses yang dilakukan oleh user Us0001 V. Tampilkan daftar permintaan hak akses selama sebulan terhadap aplikasi Ap001 W. Tampilkan daftar transaksi log yang dilakukan oleh user Us0001 X. Tampilkan daftar transaksi log selama sebulan terhadap aplikasi Ap001 Y. Tampilkan user berdasarkan jenis user Mhs Z. Tampilkan daftar admin yang memiliki status aktif AA. Tampilkan daftar hak akses yang memiliki is_approval Yes BB. Tampilkan daftar transaksi permintaan hak akses yang dilakukan pada tanggal 23 vember 2007

96 173 Analisis Transaksi untuk Transaksi A D Transaksi/Relasi (A) (B) (C) (D) I R U D I R U D I R U D I R U D Ms_Admin x Ms_Departemen x Ms_Modul Ms_Aplikasi x Ms_User x Ms_Jenis_User Ms_Hak_Akses Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User x Tr_DPnambahan_User x Tr_HPermintaan_HA Tr_DPermintaan_HA I = Insert, R = Read, U = Update, D = Delete Tabel 4.9 Cross-referencing transactions and relations (A) (D) Analisis Transaksi untuk Transaksi E H Transaksi/Relasi (E) (F) (G) (H) I R U D I R U D I R U D I R U D Ms_Admin x x Ms_Departemen x

97 174 Ms_Modul x x Ms_Aplikasi Ms_User x x Ms_Jenis_User x Ms_Hak_Akses x Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA Tr_DPermintaan_HA x x I = Insert, R = Read, U = Update, D = Delete Tabel 4.10 Cross-referencing transactions and relations (E) (H) Analisis Transaksi untuk Transaksi I L Transaksi/Relasi Ms_Admin (I) (J) (K) (L) I R U D I R U D I R U D I R U D Ms_Departemen x x Ms_Modul x x x x x Ms_Aplikasi x x x Ms_User x x x Ms_Jenis_User

98 175 Ms_Hak_Akses x x x Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA Tr_DPermintaan_HA I = Insert, R = Read, U = Update, D = Delete Tabel 4.11 Cross-referencing transactions and relations (I) (L) Analisis Transaksi untuk Transaksi M P Transaksi/Relasi Ms_Admin (M) (N) (O) (P) I R U D I R U D I R U D I R U D Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User x Ms_Jenis_User x x Ms_Hak_Akses x x x Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User

99 176 Tr_DPnambahan_User Tr_HPermintaan_HA Tr_DPermintaan_HA I = Insert, R = Read, U = Update, D = Delete Tabel 4.12 Cross-referencing transactions and relations (M) (P) Analisis Transaksi untuk Transaksi Q T Transaksi/Relasi Ms_Admin Ms_Departemen Ms_Modul Ms_Aplikasi (Q) (R) (S) (T) I R U D I R U D I R U D I R U D x x x x Ms_User Ms_Jenis_User Ms_Hak_Akses Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User x x Tr_HPermintaan_HA Tr_DPermintaan_HA I = Insert, R = Read, U = Update, D = Delete Tabel 4.13 Cross-referencing transactions and relations (Q) (T)

100 177 Analisis Transaksi untuk Transaksi U X Transaksi/Relasi Ms_Admin (U) (V) (W) (X) I R U D I R U D I R U D I R U D Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User Ms_Jenis_User Ms_Hak_Akses Tr_Header_Log x x Tr_Detail_Log x x Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA x x Tr_DPermintaan_HA x x I = Insert, R = Read, U = Update, D = Delete Tabel 4.14 Cross-referencing transactions and relations (U) (X) Analisis Transaksi untuk Transaksi Y BB Transaksi/Relasi Ms_Admin (Y) (Z) (AA) (BB) I R U D I R U D I R U D I R U D x Ms_Departemen

101 178 Ms_Modul Ms_Aplikasi Ms_User x Ms_Jenis_User Ms_Hak_Akses x Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA Tr_DPermintaan_HA x x I = Insert, R = Read, U = Update, D = Delete Tabel 4.15 Cross-referencing transactions and relations (Y) (BB) Pemilihan Organisasi File Tahap ini bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Ada beberapa jenis organisasi file, yaitu: 1. Heap (unordered) 2. Hash 3. Indexed Sequential Access Method 4. B-Tree 5. Clusters

102 179 Karena DBMS yang digunakan dalam sistem yang akan dibuat adalah MySQL, maka organisasi file yang digunakan adalah MyISAM. MyISAM menggunakan logika B-Tree, yang hampir sama dengan B + - Tree, hanya saja pencarian kata kunci hanya terjadi sekali pada indeks Pembuatan Indeks Setiap Entiti Tujuan dari langkah ini adalah untuk meningkatkan performa dari sistem. Berikut ini adalah indeks yang digunakan: 1. Ms_Admin CREATE UNIQUE INDEX Admin_Id ON Ms_Admin (Admin_Id); 2. Ms_Departemen CREATE UNIQUE INDEX Departemen_Id ON Ms_Departemen (Departemen_Id); 3. Ms_Modul CREATE UNIQUE INDEX Modul_Id ON Ms_Modul (Modul_Id); 4. Ms_Aplikasi CREATE UNIQUE INDEX Aplikasi_Id ON Ms_Aplikasi (Aplikasi_Id); 5. Ms_User CREATE UNIQUE INDEX User_Id ON Ms_User (User_Id);

103 Ms_Jenis_User CREATE UNIQUE INDEX Jenis_User_Id ON Ms_Jenis_User (Jenis_User_Id); 7. Ms_Hak_Akses CREATE UNIQUE INDEX Hak_Akses_Id ON Ms_Hak_Akses (Hak_Akses_Id); 8. Tr_Header_Log CREATE UNIQUE INDEX Form_Log_Id Tr_Header_Log (Form_Log_Id); 9. Tr_Detail_Log CREATE UNIQUE INDEX Form_Log_Id ON Tr_Detail_Log (Form_Log_Id); 10. Tr_Hpnambahan_User CREATE UNIQUE INDEX Form_Pnambahan_Id ON Tr_Hpnambahan_User (Form_Pnambahan_Id); 11. Tr_Dpnambahan_User CREATE UNIQUE INDEX Form_Pnambahan_Id ON Tr_Dpnambahan_User (Form_Pnambahan_Id); 12. Tr_Hpermintaan_HA CREATE UNIQUE INDEX Form_PermintaanHA_Id ON Tr_Hpermintaan_HA (Form_PermintaanHA_Id); 13. Tr_Dpermintaan_HA CREATE UNIQUE INDEX Form_PermintaanHA_Id ON Tr_Dpermintaan_HA (Form_PermintaanHA_Id);

104 Sintaks SQL - Data Manipulation Language Tahap ini dilakukan untuk memanggil data data yang terkandung dalam database. Adapun sintaks SQL yang digunakan sebagai berikut: 1. Sintaks untuk menampilkan data transaksi approval SELECT a.nama_user, c.jenis_aksi, d.nama_modul, e.nama_aplikasi, c.sql_cmd, b.tanggal_trans, b.form_log_id, c.alasan_reject, a.departemen_id,f.nama_admin, b.user_id FROM ms_user a, tr_header_log b, tr_detail_log c, ms_modul d, ms_aplikasi e, ms_admin f WHERE b.user_id = a.user_id and b.form_log_id = c.form_log_id and c.modul_id=d.modul_id and d.aplikasi_id = e.aplikasi_id and f.admin_id = b.admin_id and c.status_trans = 'Pending' order by b.form_log_id 2. Sintaks untuk menampilkan data transaksi permintaan hak akses SELECT a.nama_user, a.user_id, e.nama_aplikasi, e.aplikasi_id, d.nama_modul, d.modul_id, c.values, b.admin_id, b.form_permintaanha_id, c.tanggal_trans, a.departemen_id, f.nama_admin FROM ms_user a, tr_hpermintaan_ha b, tr_dpermintaan_ha c, ms_modul d, ms_aplikasi e, ms_admin f WHERE a.user_id=b.user_id and d.modul_id=c.modul_id and e.aplikasi_id=d.aplikasi_id and f.admin_id=b.admin_id and b.form_permintaanha_id=c.form_permintaanha_id and c.status_trans = 'Pending' order by b.form_permintaanha_id

105 Sintaks untuk menampilkan data laporan transaksi approval SELECT a.nama_user, c.jenis_aksi, d.nama_modul, e.nama_aplikasi, c.sql_cmd, b.tanggal_trans, c.status_trans, c.tanggal_approve, b.form_log_id, c.sql_cmd_revisi, c.alasan_reject, a.departemen_id, b.admin_id FROM ms_user a, tr_header_log b, tr_detail_log c, ms_modul d, ms_aplikasi e WHERE b.user_id = a.user_id and b.form_log_id = c.form_log_id and c.modul_id =d.modul_id and d.aplikasi_id = e.aplikasi_id and c.status_trans not like 'Pending' order by c.tanggal_approve 4. Sintaks untuk menampilkan data laporan permintaan hak akses SELECT a.nama_user, b.user_id, e.nama_aplikasi, d.nama_modul, c.values,c.tanggal_trans, c.status_trans, c.tanggal_approve, c.form_permintaanha_id, c.alasan_reject, c.is_approval, a.departemen_id, b.admin_id FROM ms_user a, tr_hpermintaan_ha b, tr_dpermintaan_ha c, ms_modul d, ms_aplikasi e WHERE b.user_id=a.user_id and b.form_permintaanha_id = c.form_permintaanha_id and c.modul_id =d.modul_id and d.aplikasi_id=e.aplikasi_id and c.status_trans not like 'Pending' order by c.tanggal_approve

106 Sintaks untuk menampilkan data hak akses user SELECT h.hak_akses_id, u.nama_user, m.nama_modul, k.nama_aplikasi, h.values, h.is_approval, h.user_id, h.modul_id, h.aplikasi_id,u.departemen_id FROM ms_user u, ms_hak_akses h, ms_modul m, ms_aplikasi k WHERE m.modul_id=h.modul_id and k.aplikasi_id=h.aplikasi_id and u.user_id=h.user_id and status_modul='aktif' order by h.hak_akses_id 6. Sintaks untuk menampilkan data aplikasi SELECT a.aplikasi_id, a.nama_aplikasi, a.departemen_id, a.admin_id, ad.nama_admin FROM ms_aplikasi a, ms_admin ad WHERE a.admin_id=ad.admin_id and status_aplikasi='aktif' order by a.aplikasi_id 7. Sintaks untuk menampilkan data modul SELECT m.modul_id, m.nama_modul, m.aplikasi_id, a.nama_aplikasi, m.departemen_id, m.admin_id FROM ms_modul m, ms_aplikasi a WHERE m.aplikasi_id=a.aplikasi_id and status_modul='aktif' order by m.modul_id

107 Sintaks untuk menampilkan data user SELECT u.user_id, u.nama_user, u.pass_user, u.jenis_user_id, ju.nama_jenis_user, u.tanggal_register, u.departemen_id, u.admin_id, ad.nama_admin FROM ms_user u, ms_jenis_user ju, ms_admin ad WHERE ad.admin_id=u.admin_id and ju.jenis_user_id=u.jenis_user_id and u.status_user='aktif' order by u.user_id 9. Sintaks untuk menampilkan data admin SELECT admin_id, nama_admin, tanggal_register FROM ms_admin WHERE status_admin='aktif' and admin_id not like (SELECT admin_id FROM ms_departemen WHERE departemen_id='all') order by admin_id 10. Sintaks untuk menampilkan data departemen SELECT departemen_id, nama_departemen, admin_id FROM ms_departemen WHERE departemen_id not like 'ALL' order by departemen_id 11. Sintaks untuk menampilkan data jenis user SELECT * FROM ms_jenis_user order by jenis_user_id 12. Sintaks untuk menampilkan data histori user SELECT u.user_id, u.nama_user, ju.nama_jenis_user, u.tanggal_register, d.nama_departemen, a.nama_admin FROM ms_user u, ms_admin a, ms_jenis_user ju, ms_departemen d

108 185 WHERE d.departemen_id=u.departemen_id and ju.jenis_user_id=u.jenis_user_id and a.admin_id=u.admin_id and u.status_user='nonaktif' order by u.user_id 13. Sintaks untuk menampilkan data histori aplikasi SELECT a.aplikasi_id, a.nama_aplikasi, d.nama_departemen, ad.nama_admin FROM ms_aplikasi a, ms_departemen d, ms_admin ad WHERE a.departemen_id=d.departemen_id and ad.admin_id=a.admin_id and a.status_aplikasi='nonaktif' order by a.aplikasi_id 14. Sintaks untuk menampilkan data histori modul SELECT m.modul_id, m.nama_modul, a.nama_aplikasi,d.nama_departemen, ad.nama_admin FROM ms_aplikasi a, ms_departemen d, ms_admin ad, ms_modul m WHERE d.departemen_id=m.departemen_id and ad.admin_id=m.admin_id and m.aplikasi_id=a.aplikasi_id and m.status_modul='nonaktif' order by m.modul_id Estimasi Disk Space Langkah ini bertujuan untuk memperkirakan kebutuhan disk space yang akan diperlukan oleh database. Estimasi kebutuhan ini dilakukan dengan menghitung besar kapasitas disk yang terpakai untuk

109 186 setiap tabel atau entiti dengan atribut atribut yang ada didalamnya serta tipe data yang digunakan, antara lain: 1. Tabel Ms_Admin Tabel / Entiti Atribut Deskripsi Tipe Ukuran (Byte) Data Ms_Admin Admin_Id Kode Admin Char 5 Nama_Admin Nama Admin Varchar 51 Pass_Admin Password Admin Varchar 51 Tanggal_Register Status_Admin Tanggal pendaftaran Admin Status Admin (aktif atau nonaktif) Datetime 8 Varchar 9 JUMLAH 124 Kapasitas awal Tabel Ms_Admin (9 record) = 9 * 124 = 1116 bytes Diperkirakan dalam satu tahun terjadi penambahan 0 record baru = 0 * 124 = 0 bytes Dalam 1 tahun pertumbuhan tabel adalah = = 1116 bytes Tabel 4.16 Perkiraan kebutuhan disk space pada tabel Ms_Admin 2. Tabel Ms_Departemen Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Ms_Departemen Departemen_Id Kode departemen Varchar 6 Nama_Departemen Nama departemen Varchar 51 Admin_Id Kode Admin Char 5

110 187 JUMLAH 62 Kapasitas awal Tabel Ms_Departemen (8 record) = 8 * 62 = 496 bytes Diperkirakan dalam satu tahun terjadi penambahan 0 record baru = 0 * 121 = 0 bytes Dalam 1 tahun pertumbuhan tabel adalah = = 496 bytes Tabel 4.17 Perkiraan kebutuhan disk space pada tabel Ms_Departemen 3. Tabel Ms_Modul Tabel / Entiti Atribut Deskripsi Tipe Ukuran (Byte) Data Ms_Modul Modul_Id Kode modul Char 5 Nama_Modul Nama modul Varchar 51 Aplikasi_Id Kode aplikasi Char 6 Departemen_Id Kode departemen Varchar 6 Admin_Id Kode Admin Char 5 Status_Modul Status modul (aktif atau nonaktif) Varchar 9 JUMLAH 82 Kapasitas awal Tabel Ms_Modul (128 record) = 128 * 82 = bytes Diperkirakan dalam satu tahun terjadi penambahan 50 record baru = 50 * 82 = 4100 bytes Dalam 1 tahun pertumbuhan tabel adalah = bytes Tabel 4.18 Perkiraan kebutuhan disk space pada tabel Ms_Modul

111 Tabel Ms_Aplikasi Tabel / Entiti Atribut Deskripsi Tipe Ukuran (Byte) Data Ms_Aplikasi Aplikasi_Id Kode aplikasi Char 6 Nama_Aplikasi Nama aplikasi Varchar 51 Departemen_Id Kode departemen Varchar 6 Admin_Id Kode Admin Char 5 Status_Aplikasi Status aplikasi (aktif atau nonaktif) Varchar 9 JUMLAH 77 Kapasitas awal Tabel Ms_Aplikasi (18 record) = 18 * 77 = 1386 bytes Diperkirakan dalam satu tahun terjadi penambahan 5 record baru = 5 * 77 = 385 bytes Dalam 1 tahun pertumbuhan tabel adalah = 1771 bytes Tabel 4.19 Perkiraan kebutuhan disk space pada tabel Ms_Aplikasi 5. Tabel Ms_User Tabel / Entiti Atribut Deskripsi Tipe Ukuran (Byte) Data Ms_User User_Id Kode user Varchar 11 Nama_User Nama user Varchar 51 Pass_User Password user Varchar 51 Status_User Status user (aktif atau nonaktif) Varchar 9 Jenis_User_Id Kode jenis user Varchar 6 Tanggal_Register Tanggal Datetime 8

112 189 pendaftaran user Departemen_Id Kode departemen Varchar 6 Admin_Id Kode Admin Char 5 JUMLAH 147 Kapasitas awal Tabel Ms_User (90 record) = 90 * 147 = bytes Diperkirakan dalam satu tahun terjadi penambahan 20 record baru = 20 * 147 = 2940 bytes Dalam 1 tahun pertumbuhan tabel adalah = bytes Tabel 4.20 Perkiraan kebutuhan disk space pada tabel Ms_User 6. Tabel Ms_Jenis_User Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Ms_Jenis_User Jenis_User_Id Kode jenis user Varchar 6 Nama_Jenis_User Nama jenis user Varchar 21 JUMLAH 27 Kapasitas awal Tabel Ms_Jenis_User (3 record) = 3 * 27 = 81 bytes Diperkirakan dalam satu tahun terjadi penambahan 0 record baru = 0 * 27 = 0 bytes Dalam 1 tahun pertumbuhan tabel adalah = 81 bytes Tabel 4.21 Perkiraan kebutuhan disk space pada tabel Ms_Jenis_User 7. Tabel Ms_Hak_Akses Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Ms_Hak_Akses Hak_Akses_Id Kode hak akses Int 4 Modul_Id Nama modul Char 5

113 190 Aplikasi_Id Kode Aplikasi Char 6 Values Is_Approval Aksi (terdiri dari insert, update, delete) Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak Varchar 7 Varchar 4 User_Id Kode user Varchar 11 JUMLAH 37 Kapasitas awal Tabel Ms_Hak_Akses (500 record) = 500 * 37 = bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru = 100 * 37 = 3700 bytes Dalam 1 tahun pertumbuhan tabel adalah = bytes Tabel 4.22 Perkiraan kebutuhan disk space pada tabel Ms_Hak_Akses 8. Tabel Tr_Header_Log Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_Header_Log Form_Log_Id Kode formulir Int 4 transaksi log User_Id Kode user Varchar 11 Tanggal_Trans Tanggal terjadinya transaksi log Datetime 8

114 191 Admin_Id Kode Admin Char 5 JUMLAH 28 Kapasitas awal Tabel Tr_Header_Log (0 record) = 0 * 28 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru = 100 * 28 = 2800 bytes Dalam 1 tahun pertumbuhan tabel adalah = 2800 bytes Tabel 4.23 Perkiraan kebutuhan disk space pada tabel Tr_Header_Log 9. Tabel Tr_Detail_Log Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_Detail_Log Form_Log_Id Kode formulir Int 4 transaksi log Modul_Id Nama modul Char 5 Jenis_Aksi Sql_cmd Status_Trans Jenis aksi yang dilakukan oleh user terhadap aplikasi yang diaksesnya Jenis aksi yang ditulis dalam sintaks SQL secara lengkap Status transaksi (aktif atau nonaktif) Varchar 7 Text 102 Varchar 8 Tanggal_Approve Tanggal terjadinya Datetime 8

115 192 Sql_Cmd_Revisi Alasan_Reject proses pengapprove-an daftar transaksi oleh Admin Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak Alasan yang menjelaskan kenapa suatu transaksi di-reject Text 102 Text 102 JUMLAH 338 Kapasitas awal Tabel Tr_Detail_Log (0 record) = 0 * 338 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru=100*338 = bytes Dalam 1 tahun pertumbuhan tabel adalah = bytes Tabel 4.24 Perkiraan kebutuhan disk space pada tabel Tr_Detail_Log

116 Tabel Tr_HPnambahan_User Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_HPnambahan_User Form_Pnambahan_Id Kode formulir transaksi penambahan user Int 4 Tanggal_Trans Tanggal terjadinya transaksi penambahan user Datetime 8 JUMLAH 12 Kapasitas awal Tabel Tr_HPnambahan_User (0 record) = 0 * 12 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 20 record baru = 20 * 12 = 240 bytes Dalam 1 tahun pertumbuhan tabel adalah = 240 bytes Tabel 4.25 Perkiraan kebutuhan disk space pada tabel Tr_HPnambahan_User 11. Tabel Tr_DPnambahan_User Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_DPnambahan_User Form_Pnambahan_Id Kode formulir transaksi penambahan user Int 4

117 194 User_Id Kode user Varchar 11 Nama_User Nama user Varchar 51 JUMLAH 66 Kapasitas awal Tabel Tr_DPnambahan_User (0 record) = 0 * 66 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 20 record baru = 20 * 66 = 1320 bytes Dalam 1 tahun pertumbuhan tabel adalah = 1320 bytes Tabel 4.26 Perkiraan kebutuhan disk space pada tabel Tr_DPnambahan_User 12. Tabel Tr_HPermintaan_HA Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_HPermintaan_HA Form_PermintaanHA_Id Kode formulir Int 4 transaksi permintaan hak akses User_Id Kode user Varchar 11 Admin_Id Kode Admin Char 5 JUMLAH 20 Kapasitas awal Tabel Tr_HPermintaan_HA (0 record) = 0 * 20 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru = 100 * 20 = 2000 bytes Dalam 1 tahun pertumbuhan tabel adalah = 2000 bytes Tabel 4.27 Perkiraan kebutuhan disk space pada tabel Tr_HPermintaan_HA

118 Tabel Tr_DPermintaan_HA Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte) Tr_DPermintaan_HA Form_PermintaanHA_Id Kode formulir Int 4 transaksi permintaan hak akses Modul_Id Kode modul Char 5 Values Status_Trans Tanggal_Approve Tanggal_Trans Aksi (terdiri dari insert, update, delete) Status transaksi (aktif atau nonaktif) Tanggal terjadinya proses pengapprove-an permintaan hak akses oleh Admin Tanggal terjadinya transaksi Varchar 7 Varchar 8 Datetime 8 Datetime 8

119 196 Alasan_Reject Is_Approval permintaan hak akses Alasan yang menjelaskan kenapa suatu transaksi direject Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak Text 102 Varchar 4 JUMLAH 146 Kapasitas awal Tabel Tr_DPermintaan_HA (0 record) = 0 * 146 = 0 bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru=100*146 = bytes Dalam 1 tahun pertumbuhan tabel adalah = bytes Tabel 4.28 Perkiraan kebutuhan disk space pada tabel Tr_DPermintaan_HA

120 197 Tabel /Entiti Berikut perkiraan kebutuhan disk space untuk semua tabel : Kapasitas Awal (bytes) Pertumbuhan setiap tahun (bytes) Kapasitas yang diperlukan 1 tahun pertama (bytes) Ms_Admin Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User Ms_Jenis_User Ms_Hak_Akses Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA Tr_DPermintaan_HA Total disk space awal yang dibutuhkan bytes atau 45,305 Kilobytes Pertumbuhan setiap tahun sebesar bytes atau 65,885 Kilobytes Total disk space yang dibutuhkan pada tahun pertama sebesar bytes atau 111,19 Kilobytes Total disk space yang dibutuhkan untuk 5 tahun pertama = 45,305 + ( 5 * 65,885 ) = 374,73 Kilobytes Tabel 4.29 Perkiraan kebutuhan disk space untuk semua tabel

121 Merancang Mekanisme Keamanan Langkah ini bertujuan untuk mendesain ukuran keamanan untuk basis data sebagaimana telah ditentukan oleh user. Ada dua tipe di dalam sistem keamanan basis data ini, yaitu: 1. Keamanan sistem, yaitu untuk menangani akses dan penggunaan basis data pada tingkat sistem. Implementasinya adalah dengan menggunakan id dan password. 2. Keamanan data, yaitu untuk menangani akses dan penggunaan objek objek basis data dan aksi aksi yang bisa dilakukan user terhadap objek objek tersebut. Implementasinya adalah dengan mekanisme authorization, yaitu mekanisme yang membatasi hak hak akses admin terhadap tabel tabel di database seperti terlihat di bawah ini. Pada dasarnya hak akses admin tergantung apa yang diberikan oleh superadmin kepada admin. Transaksi Superadmin Admin I R U D I R U D Ms_Admin x x x x Ms_Departemen x x x x Ms_Modul x x x x x x x x Ms_Aplikasi x x x x x x x x Ms_User x x x x x x x x

122 199 Ms_Jenis_User x x x x Ms_Hak_Akses x x x x x x x x Tr_Header_Log x x x x x x x x Tr_Detail_Log x x x x x x x x Tr_HPnambahan_User x x x x x x x x Tr_DPnambahan_User x x x x x x x x Tr_HPermintaan_HA x x x x x x x x Tr_DPermintaan_HA x x x x x x x x I = Insert, R = Read, U = Update, D = Delete Tabel 4.30 Perancangan Mekanisme Keamanan Sintaks untuk implementasi authorization-nya adalah sebagai berikut: Ms_Admin GRANT ALL PRIVILEGES ON Ms_Admin TO Superadmin; Ms_Departemen GRANT ALL PRIVILEGES ON Ms_Departemen TO Superadmin; Ms_Modul GRANT ALL PRIVILEGES ON Ms_Modul TO Superadmin; GRANT ALL PRIVILEGES ON Ms_Modul TO Admin;

123 200 Ms_Aplikasi GRANT ALL PRIVILEGES ON Ms_Aplikasi TO Superadmin; GRANT ALL PRIVILEGES ON Ms_Aplikasi TO Admin; Ms_User GRANT ALL PRIVILEGES ON Ms_User TO Superadmin; GRANT ALL PRIVILEGES ON Ms_User TO Admin; Ms_Jenis_User GRANT ALL PRIVILEGES ON Ms_Jenis_User TO Superadmin; Ms_Hak_Akses GRANT ALL PRIVILEGES ON Ms_Hak_Akses TO Superadmin; GRANT ALL PRIVILEGES ON Ms_Hak_Akses TO Admin; Tr_Header_Log GRANT ALL PRIVILEGES ON Tr_Header_Log TO Superadmin; GRANT ALL PRIVILEGES ON Tr_Header_Log TO Admin; Tr_Detail_Log GRANT ALL PRIVILEGES ON Tr_Detail_Log TO Superadmin; GRANT ALL PRIVILEGES ON Tr_Detail_Log TO Admin;

124 201 Tr_HPnambahan_User GRANT ALL PRIVILEGES ON Tr_HPnambahan_User TO Superadmin; GRANT ALL PRIVILEGES ON Tr_HPnambahan_User TO Admin; Tr_DPnambahan_User GRANT ALL PRIVILEGES ON Tr_DPnambahan_User TO Superadmin; GRANT ALL PRIVILEGES ON Tr_DPnambahan_User TO Admin; Tr_HPermintaan_HA GRANT ALL PRIVILEGES ON Tr_HPermintaan_HA TO Superadmin; GRANT ALL PRIVILEGES ON Tr_HPermintaan_HA TO Admin; Tr_DPermintaan_HA GRANT ALL PRIVILEGES ON Tr_HPermintaan_HA TO Superadmin; GRANT ALL PRIVILEGES ON Tr_HPermintaan_HA TO Superadmin;

125 Perancangan Aplikasi Untuk merancang aplikasi yang diinginkan, diperlukan beberapa langkah yang harus dilakukan, diantaranya adalah melakukan perancangan layar, perancangan program, dan menggambar serta menjelaskan State Transition Diagram (STD) Perancangan Struktur Menu Perancangan Struktur Menu dapat dilihat pada gambar berikut.

126 Gambar 4.11 Perancangan Struktur Menu 203

127 State Transition Diagram (STD) State Transition Diagram (STD) merupakan suatu diagram yang menjelaskan tentang alur dari aksi dan reaksi. Penulis menggunakan diagram STD ini untuk memberikan gambaran tentang reaksi yang akan diberikan oleh sistem yang penulis rancang ketika menerima aksi dari pengguna. Berikut adalah STD yang merupakan gambaran tentang alur dari aplikasi jika dijalankan: Gambar 4.12 STD Login Gambar 4.13 STD Menu Home SuperAdmin

128 205 Gambar 4.14 STD Menu Home Admin Gambar 4.15 STD Menu Daftar Approval

129 206 Gambar 4.16 STD Menu User Gambar 4.17 STD Menu Aplikasi

130 207 Gambar 4.18 STD Menu Modul Gambar 4.19 STD Menu Hak Akses