BAB 4 PERANCANGAN SISTEM BASIS DATA

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

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.

80 4.2

Gambaran Sistem User Management Apporval System (UMAS)

4.2.1

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

Gambar 4.3 Diagram Konteks UMAS pada kampus JWC

Gambar 4.1 merupakan gambar diagram konteks UMAS pada kampus JWC. Diagram konteks UMAS terdiri dari satu sistem yaitu UMAS, dan eksternal entity yang berinteraksi dengan sistem tersebut yaitu entiti admin dan aplikasi. Informasi atau data dari DFD Diagram Konteks ini kami peroleh dari gambaran posisi umas seperti yang tergambar pada Gambar 4.1 dan Gambar 4.2. Entiti admin dan aplikasi bertindak sebagai sumber sekaligus tujuan, karena entitas tersebut memberikan masukan ke sistem sekaligus menerima keluaran dari sistem.

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

4.2.2

Cross Functional Flowchart Cross Functional Flowchart UMAS pada kampus JWC terdiri dari satu proses yang berjalan di luar sistem berupa Transaksi_di_Luar_Sistem, dan tiga proses

yang

berjalan

di

dalam

sistem,

yaitu

Transaksi_Log,

Transaksi_Permintaan_Hak_Akses, dan Transaksi_Penambahan_User.

82

Gambar 4.4 Cross Functional Flowchart pada UMAS (Bagian 1)

83

Gambar 4.5 Cross Functional Flowchart pada UMAS (Bagian 2)

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

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

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

4.3.1

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

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

4.3.1.1

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 Admin

Setiap

yang memberikan

dikepalai

informasi

admin

yang

departemen oleh

seorang

88 NAMA

KETERANGAN

ALIAS

KEMUNCULAN

ENTITAS berhubungan dengan admin Ms_Departeme

Merupakan entitas Departemen

Setiap

n

yang

terdapat

mendeskripsikan

dikelompokkan berdasarkan

departemen

departemen

yang

bahagian di

yang JWC

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

89 NAMA

KETERANGAN

ALIAS

KEMUNCULAN

ENTITAS informasi

yang

departemen

berhubungan

dengan

dengan user yang

diaksesnya

yang

sama

aplikasi

yang

mengakses aplikasi di JWC Ms_Jenis_User

Merupakan entitas Jenis User

User

yang memberikan

dalam beberapa jenis user

informasi

dikelompokkan

ke

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

ada

akses

yang

dimiliki oleh tiap user Tr_Log

Merupakan entitas Log

Setiap

transaksi

yang

yang memberikan

dilakukan oleh user akan

90 NAMA

KETERANGAN

ALIAS

KEMUNCULAN

ENTITAS informasi

melalui

mengenai

proses

peng-approve-an daftar

transaksi

yang

dilakukan

proses

peng-

approve-an terlebih dahulu oleh admin

oleh user Tr_Pnambahan

Merupakan entitas Penambahan

_User

yang memberikan User

Penambahan user baru

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

91 4.3.1.2

Mengidentifikasikan Tipe Relational Tujuan dari tahapan ini adalah untuk mengidentifikasikan hubungan antara entiti-entiti yang telah diidentifikasikan. Langkah-langkah dalam mengidentifikasikan tipe relasi : 1. Menggunakan Entity Relationship (ER) Diagram 2. Menentukan pembatas multiplicity dari tipe relasi

4.3.1.2.1

Menggunakan Entity Relationship (ER) Diagram Berikut ini ERD konseptual yang memuat nama entitas beserta dengan hubungannya (relationship) adalah sebagai berikut :

92

Gambar 4.6 Entity Relationship (ER) Diagram Konseptual

4.3.1.2.2

Menentukan Pembatas Multiplicity dari Tipe Relasi Setelah

ditentukan

Entity

Relationship

(ER)

Diagram

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

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

Nama Entiti Ms_Admin

Multiplicity

Relasi

Nama Entiti

Multiplicity

1..1

Mengepalai

Ms_Departemen

1..1

1..1

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

Ms_Aplikasi

1..*

Mempunyai

Ms_Aplikasi

1..1

1..1

Terdapat

Ms_Hak_Akses

0..*

1..*

Meliputi

Tr_Log

0..*

1..*

Meliputi

Tr_Permintaan_HA

0..*

1..1

Terdapat

Ms_Hak_Akses

0..*

1..*

Meliputi

Tr_Log

0..*

94 Nama Entiti

Multiplicity

Relasi

Nama Entiti

Multiplicity

1..*

Meliputi

Tr_Permintaan_HA

0..*

1..*

Terdiri dari

Ms_Jenis_User

1..1

1..1

Memiliki

Ms_Hak_Akses

0..*

1..*

Melakukan

Tr_Log

0..*

1..1

Terdiri dari

Tr_Pnambahan_Us

1..1

Ms_User

er 1..1

Melakukan

Tr_Permintaan_HA

0..*

Tabel 4.2 Pembatasan Multiplicity

4.3.1.3

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

Entitas

Ms_Admin

Atribut

Deskripsi

Admin_Id

Kode Admin

Tipe dan Panjang Data Char (5)

Null

Multi Value

No

No

Nama_Admin

Nama Admin

Varchar(50)

No

No

Pass_Admin

Password

Varchar(50)

No

No

Datetime

No

No

Admin Tanggal_Regist

Tanggal

95 Entitas

Atribut

er

Deskripsi

Tipe dan Panjang Data

Null

Multi Value

Varchar (8)

No

No

Varchar (5)

No

No

Varchar(50)

No

No

pendaftaran Admin

Status_Admin

Status Admin (aktif atau nonaktif)

Ms_Departem

Departemen_Id

en

Ms_Modul

Kode departemen

Nama_Departe

Nama

men

departemen

Admin_Id

Kode Admin

Char (5)

Yes

No

Modul_Id

Kode modul

Char (5)

No

No

Nama_Modul

Nama modul

Varchar(50)

No

No

Aplikasi_Id

Kode aplikasi

Char (6)

No

No

Departemen_Id

Kode

Varchar (5)

No

No

departemen Admin_Id

Kode Admin

Char (5)

No

No

Status_Modul

Status modul

Varchar (8)

No

No

(aktif atau nonaktif) Ms_Aplikasi

Aplikasi_Id

Kode aplikasi

Char (6)

No

No

Nama_Aplikasi

Nama aplikasi

Varchar(50)

No

No

96 Entitas

Atribut

Departemen_Id

Deskripsi

Kode

Tipe dan Panjang Data Varchar (5)

Null

Multi Value

No

No

departemen Admin_Id

Kode Admin

Char (5)

No

No

Status_Aplikasi

Status aplikasi

Varchar (8)

No

No

(aktif atau nonaktif) Ms_User

User_Id

Kode user

Varchar(10)

No

No

Nama_User

Nama user

Varchar(50)

No

No

Pass_User

Password user

Varchar(50)

No

No

Varchar (8)

No

No

Status user Status_User

(aktif atau nonaktif)

Jenis_User_Id

Kode jenis user

Varchar (5)

No

No

Tanggal_Regist

Tanggal

Datetime

No

No

er

pendaftaran

Varchar (5)

No

No

Kode Admin

Char (5)

No

No

Ms_Jenis_Use Jenis_User_Id

Kode jenis user

Varchar (5)

No

No

r

Nama jenis user

Varchar(20)

No

No

user Departemen_Id

Kode departemen

Admin_Id

Nama_Jenis_Us

97 Entitas

Atribut

Deskripsi


Null

Multi Value

er Ms_Hak_Aks

Hak_Akses_Id

Kode hak akses

Int (5)

No

No

es

Modul_Id

Kode modul

Char (5)

No

No

Aplikasi_Id

Kode aplikasi

Char (6)

No

No

Values

Aksi (terdiri

Varchar (6)

No

No

Varchar (3)

No

No

dari insert, update, delete) Is_Approval

Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak.

Tr_Log

User_Id

Kode user

Varchar(10)

No

No

Form_Log_Id

Kode formulir

Int (5)

No

No

transaksi log User_Id

Kode user

Varchar(10)

No

No

Modul_Id

Kode modul

Char (5)

No

No

Admin_Id

Kode Admin

Char (5)

No

No

Jenis_Aksi

Jenis aksi yang

Varchar (6)

No

No

98 Entitas

Atribut

Deskripsi


Null

Multi Value

Text

Yes

No

Datetime

No

No

Varchar (7)

No

No

Datetime

Yes

No

dilakukan oleh user terhadap aplikasi yang diaksesnya SQL_Cmd

Jenis aksi yang ditulis dalam sintaks SQL secara lengkap

Tanggal_Trans

Tanggal terjadinya transaksi log

Status_Trans

Status transaksi (aktif atau nonaktif)

Tanggal_Appro

Tanggal

val

terjadinya proses pengapprove-an daftar transaksi oleh admin

Aplikasi_Id

Kode aplikasi

Char (6)

No

No

Alasan Reject

Alasan kenapa

Text

Yes

No

99 Entitas

Atribut

Deskripsi


Null

Multi Value

Text

Yes

No

Int (5)

No

No

me-reject suatu transaksi SQL_Cmd_Rev

Sintaks SQL

isi

dari SQL_Cmd yang sudah diperbaiki

Tr_Pnambaha

Form_Penamba

Kode formulir

n_User

han_Id

transaksi penambahan user

User_Id

Kode user

Varchar(10)

No

No

Nama_User

Nama user

Varchar(50)

No

No

Pass_User

Password user

Varchar(50)

No

No

Admin_Id

Kode Admin

Char (5)

No

No

Departemen_Id

Kode

Varchar (5)

No

No

Datetime

No

No

departemen Tanggal_Transa Tanggal ksi

terjadinya transaksi penambahan

100 Entitas

Atribut

Deskripsi


Null

Multi Value

Int (5)

No

No

user Tr_Permintaa

Form_Perminta

Kode formulir

n_HA

anHA_Id

transaksi permintaan hak akses

User_Id

Kode user

Varchar(10)

No

No

Modul_Id

Kode modul

Char (5)

No

No

Aplikasi_Id

Kode aplikasi

Char (6)

No

No

Values

Aksi (terdiri

Varchar (6)

No

No

Varchar (7)

No

No

Char (5)

No

No

Datetime

No

No

Datetime

Yes

No

dari insert, update, delete) Status_Transaks Status transaksi i

(aktif atau nonaktif)

Admin_Id

Kode Admin

Tanggal_Transa Tanggal ksi

terjadinya transaksi permintaan hak akses

Tanggal_Appro

Tanggal

101 Entitas

Atribut

val

Deskripsi


Null

Multi Value

Text

Yes

No

Varchar(3)

Yes

No

terjadinya proses pengapprove-an permintaan hak akses oleh admin

Alasan_Reject

Alasan kenapa me-reject suatu permintaan

Is_Approval

Status yang diberikan terhadap suatu permintaan apakah perlu mendapat tindakan approval atau tidak.

Tabel 4.3 Identifikasi Atribut dan Asosiasi Atribut Suatu Entiti

102 4.3.1.4

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

Ms_Admin

Atribut Admin_Id

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

Nama_Admin

Maksimum 50 karakter

Pass_Admin


Tanggal_Reg

yyyy-mm-dd dan hh:mm:ss

Status_Admin

Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”)

Ms_Departemen

Departemen_Id


Nama_Departemen


Admin_Id

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

Ms_Modul

Modul_Id

Terdiri dari 5 karakter

Nama_Modul


103 Entiti

Atribut Aplikasi_Id

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

Departemen_Id


Admin_Id


Status_Modul


Ms_Aplikasi

Aplikasi_Id

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

Nama_Aplikasi


Departemen_Id


Admin_Id

Terdiri dari 5 karakter, di mana 2 karakter pertama

104 Entiti

Atribut

Domain berupa huruf dan 3 karakter terakhir berupa angka

Status_Aplikasi


Ms_User

User_Id


Nama_User


Pass_User


Status_User


Jenis_User_Id

Maksimum 5 karakter

Tanggal_Register


Departemen_Id


Admin_Id


Ms_Jenis_User

Ms_Hak_Akses

Jenis_User_Id

Maksimum 5 karakter

Nama_Jenis_User


Hak_Akses_Id

Berupa angka, maksimum 10 digit

105 Entiti

Atribut

Domain

Modul_Id


Aplikasi_Id


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 6 karakter

106 Entiti

Atribut

Domain (berupa ”insert” atau”update” atau ”delete”)

SQL_Cmd

Berupa text

Tanggal_Trans


Status_Trans

Maksimum 8 karakter (berupa ”aktif” atau ”nonaktif”

Tanggal_Approval


Aplikasi_Id


Tr_Pnambahan_User

Alasan_Reject

Berupa text

SQL_Cmd_Revisi

Berupa text

Form_Penambahan_Id


User_Id


Nama_User


Pass_User


Admin_Id

Terdiri dari 5 karakter, di mana 2 karakter pertama

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

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

Status_Transaksi


Admin_Id

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

108 Entiti

Atribut

Domain terakhir berupa angka

Tanggal_Transaksi


Tanggal_Approval


Alasan_Reject

Berupa text

Is_Approval

Maksimum 3 karakter(berupa “yes” atau “no”)

Tabel 4.4 Identifikasi Domain Atribut

4.3.1.5

Menentukan Atribut Candidate Key dan Primary Key Berikut ini merupakan penentuan atribut candidate dan primary key dari setiap entiti yang ada, antara lain : Entity

Candidate Key

Primary Key

Ms_Admin

Admin_Id

Admin_Id

Ms_Departemen

Departemen_Id

Departemen_Id

Admin_Id Ms_Modul

Modul_Id

Modul_Id

Aplikasi_Id Departemen_Id Admin_Id Ms_Aplikasi

Aplikasi_Id Departemen_Id

Aplikasi_Id

109 Entity

Candidate Key

Primary Key

Admin_Id Ms_User

User_Id

User_Id

Departemen_Id Jenis_User_Id Admin_Id Ms_Jenis_User

Jenis_User_Id

Jenis_User_Id

Ms_Hak_Akses

Hak_Akses_Id

Hak_Akses_Id

Aplikasi_Id User_Id Modul_Id Tr_Log

Form_Log_Id

Form_Log_Id

User_Id Modul_Id Admin_Id Tr_Pnambahan_User

Form_Penambahan_Id

Form_Penambaha

User_Id

n_Id

Admin_Id Departemen_Id Tr_Permintaan_HA

Form_PermintaanHA_Id

Form_Permintaan

User_Id

HA_Id

Modul_Id Aplikasi_Id

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

111 4.3.1.6

Validasi Model Konseptual Data Lokal Terhadap Transaksi User

4.3.1.6.1

Data Entry 1. Memasukkan detail dari admin baru (seperti detail admin bernama Susan) 2. Memasukkan detail dari user baru (seperti detail user bernama Gunawan) 3. Memasukkan detail dari departemen baru (seperti detail departemen Back Office) 4. Memasukkan detail dari aplikasi baru (seperti detail aplikasi VOIP Binus) 5. Memasukkan detail dari modul baru (seperti detail modul User Online pada aplikasi VOIP Binus) 6. Memasukkan detail dari hak akses user baru (seperti detail hak akses pada modul User Online di aplikasi VOIP Binus pada user Gunawan) 7. Memasukkan detail dari jenis user baru (seperti detail jenis user Manager)

4.3.1.6.2

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

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

4.3.1.6.3

Data Queries (a) Tampilkan detail user yang berada di departemen Lecturer (b) Tampilkan detail hak akses berdasarkan kode aplikasi Ap001 (c) Tampilkan detail modul yang terdapat di aplikasi Ap002 (d) Tampilkan admin id yang berada di departemen Lecturer (e) Tampilkan detail penambahan user berdasarkan kode departemen Lecturer (f) Tampilkan detail aplikasi yang berada di departemen Lecturer (g) Tampilkan daftar permintaan hak akses yang dilakukan oleh user Us0001 (h) Tampilkan daftar permintaan hak akses selama sebulan terhadap aplikasi Ap001 (i) Tampilkan daftar transaksi log yang dilakukan oleh user Us0001 (j) Tampilkan daftar transaksi log selama sebulan terhadap aplikasi Ap001 (k) Tampilkan user berdasarkan jenis user Mhs (l) Tampilkan daftar admin yang memiliki status “aktif” (m) Tampilkan daftar hak akses yang memiliki is_approval “Yes” (n) Tampilkan daftar transaksi permintaan hak akses yang dilakukan pada tanggal 23 November 2007

113

Gambar 4.8 ER Diagram Konseptual dengan Primary Key dan Transaction Pathway

114

Gambar 4.9 ER Diagram Konseptual

4.3.2

Perancangan Basis Data Logikal

4.3.2.1

Menghilangkan Fitur Tidak Kompatibel Memperbaiki model data konseptual lokal untuk menghilangkan fitur-fitur yang tidak kompatibel dengan model relasional.

115 4.3.2.1.1

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 :


116 •

Hubungan Tr_Permintaan_HA dengan Ms_Aplikasi

(a)

(b)

Keterangan :


•

Hubungan Tr_Permintaan_HA dengan Ms_Modul

(a)

(b)

Keterangan :


117 4.3.2.2

Menentukan Relasi Untuk Model Data Logikal Global

4.3.2.2.1

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

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

Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id) Primary Key Departemen_Id

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

Ms_Aplikasi

(Aplikasi_Id,

Nama_Aplikasi,

Departemen_Id,

Admin_Id, Status_Aplikasi) Primary Key Aplikasi_Id

Ms_User

(User_Id,

Nama_User,

Pass_User,

Status_User,

Tanggal_Register, Departemen_Id, Jenis_User_Id, Admin_Id) Primary Key User_Id

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

4.3.2.2.2

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

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)

4.3.2.2.3

One-to-many (1:*) Binary Relationship Types Untuk masing-masing one-to-many binary relationship types, ‘dalam satu sisi’ menjadi entiti induk dan entiti yang lain menjadi entiti anak. Untuk merepresentasikannya, pindahkan primary key dari entiti induk ke entiti anak sebagai foreign key.

120 1. Relasi antar Ms_Admin dengan Ms_User menghasilkan posting Admin_Id ke entiti Ms_User Post Admin_Id ke Ms_User untuk model relasi 1 : * mengalami

Ms_Admin (Admin_Id, Nama_Admin,

Ms_User

Pass_Admin,

Nama_User,

Pass_User,

Status_Admin)

Status_User,

Tanggal_Register,

Primary Key Admin_Id

Departemen_Id, Jenis_User_Id)

Tanggal_Reg,

(User_Id,

Admin_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 Nama_Admin,

(Admin_Id, Pass_Admin,

Ms_Aplikasi

(Aplikasi_Id,

Nama_Aplikasi,

Admin_Id,

Tanggal_Reg, Status_Admin)

Departemen_Id, Status_Aplikasi)


Primary Key Aplikasi_Id Foreign Key Admin_Id references Ms_Admin (Admin_Id)

121 3. Relasi antar Ms_Departemen dengan Ms_Modul menghasilkan posting Departemen_Id ke entiti Ms_Modul Post Departemen_Id ke Ms_Modul untuk model relasi 1 : * mengalami

Ms_Departemen

(Departemen_Id,

Ms_Modul

(Modul_Id,

Nama_Departemen, Admin_Id)

Nama_Modul,

Primary Key Departemen_Id

Aplikasi_Id,

Foreign Key Admin_Id references

Status_Modul)

Ms_Admin (Admin_Id)

Primary Key Modul_Id Foreign

Key

references

Departemen_Id, Admin_Id,

Departemen_Id 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_Aplikasi,


Admin_Id, Status_Aplikasi)


Primary Key Aplikasi_Id

Ms_Admin (Admin_Id)

Foreign references

Key

Departemen_Id,


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,


Pass_User,


Status_User,


Jenis_User_Id, Admin_Id)

Ms_Admin (Admin_Id)

Primary Key User_Id Foreign

Departemen_Id,

Key

references

Tanggal_Register,


(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 Nama_Aplikasi,

(Aplikasi_Id, Departemen_Id,

Ms_Modul Nama_Modul,


Departemen_Id,


Status_Modul)

(Modul_Id, Aplikasi_Id, Admin_Id,

123 Foreign

Key

references


Primary Key Modul_Id Foreign

(Departemen_Id)

references


(Aplikasi_Id)

Key

Aplikasi_Id Ms_Aplikasi

Ms_Admin (Admin_Id)

7. Relasi antar Ms_Modul dengan Ms_Hak_Akses menghasilkan posting Modul_Id ke entiti Ms_Hak_Akses Post Modul_Id ke Ms_Hak_Akses untuk model relasi 1 : * mengalami

Ms_Modul

(Modul_Id,

Nama_Modul,

Aplikasi_Id,

Departemen_Id,

Admin_Id,

Ms_Hak_Akses Aplikasi_Id,

(Hak_Akses_Id,

Values,

Modul_Id,

User_Id, Is_Approval)

Status_Modul)

Primary Key Hak_Akses_Id

Primary Key Modul_Id

Foreign Key Modul_Id references

Foreign Key Aplikasi_Id references

Ms_Modul (Modul_Id)

Ms_Aplikasi (Aplikasi_Id) Foreign

Key

references


(Departemen_Id) Foreign Key Admin_Id references Ms_Admin (Admin_Id)

124 8. Relasi antar Ms_Aplikasi dengan Ms_Hak_Akses menghasilkan posting Aplikasi_Id ke entiti Ms_Hak_Akses Post Aplikasi_Id ke Ms_Hak_Akses untuk model relasi 1 : * mengalami

Ms_Aplikasi

(Aplikasi_Id,

Nama_Aplikasi,

Departemen_Id,

Ms_Hak_Akses Values,

(Hak_Akses_Id,

User_Id,

Aplikasi_Id,


Is_Approval, Modul_Id)



Foreign

Foreign

Key

references


(Departemen_Id)

Key

Aplikasi_Id

references

Ms_Aplikasi

(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)

Pass_User,

Primary Key Jenis_User_Id

Status_User,

Jenis_User_Id, Tanggal_Register,

Departemen_Id, Admin_Id) Primary Key User_Id

125 Foreign

Key

references

Jenis_User_Id 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_Modul,

Admin_Id,


Status_Modul,

Departemen_Id,


Aplikasi_Id,)

Nama_Admin,

Pass_Admin,

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 Pass_User, Status_User,

(User_Id,

Nama_User,

Tanggal_Register, Departemen_Id,

Ms_Hak_Akses

(Hak_Akses_Id,

Values, Is_Approval, User_Id , Aplikasi_Id, Admin_Id)

126 Jenis_User_Id, Admin_Id)


Primary Key User_Id

Foreign Key User_Id references Ms_User(User_Id)

12. Relasi antar Tr_Permintaan_HA dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Tr_Permintaan_HA Post Admin_Id ke Tr_Permintaan_HA untuk model relasi 1 : * mengalami



Tr_Permintaan_HA (Form_PermintaanHA_Id, Values,


Status_Transaksi,


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)

127 13. Relasi antar Tr_Permintaan_HA dengan Ms_User menghasilkan posting User_Id ke entiti Tr_Permintaan_HA Post User_Id ke Tr_Permintaan_HA untuk model relasi 1 : * mengalami


(User_Id,

Nama_User,


Tr_Permintaan_HA (Form_PermintaanHA_Id, User_Id, Values,

Status_Transaksi,


Tanggal_Transaksi,

Primary Key User_Id

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


(User_Id,

Nama_User,


Tr_Log

(Form_Log_Id,

Jenis_Aksi, SQL_Cmd, User_Id, Status_Trans,

Tanggal_Trans,

128 Jenis_User_Id, Admin_Id)

Tanggal_Approval,

Modul_Id,

Primary Key User_Id

Aplikasi_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



Tr_Log

(Form_Log_Id,

Jenis_Aksi, SQL_Cmd, Admin_Id,


Status_Trans,


Tanggal_Approval,

Tanggal_Trans,

Modul_Id,

User_Id, Aplikasi_Id,

Alasan_Reject, SQL_Cmd_Revisi) Primary Key Form_Log_Id Foreign Key Admin_Id references Ms_Admin(Admin_Id)

129 16. Relasi antar Tr_Pnambahan_User dengan Ms_Admin menghasilkan posting Admin_Id ke entiti Tr_Pnambahan_User Post Admin_Id ke Tr_Pnambahan_User untuk model relasi 1 : * mengalami

Ms_Admin

(Admin_Id,

Nama_Admin,

Tr_Pnambahan_User

Pass_Admin,

(Form_Pnambahan_Id, Admin_Id,


Nama_User,

Pass_User,


Tanggal_Transaksi,

User_Id,

Departemen_Id ) Primary

Key

Form_Pnambahan_Id Foreign Key Admin_Id references Ms_Admin(Admin_Id)

17. Relasi

antar

Tr_Pnambahan_User

menghasilkan

posting

dengan

Ms_Departemen

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


(Form_Pnambahan_Id,


Nama_User, Pass_User,

Departemen_Id, Tanggal_Transaksi,

130 User_Id, Admin_Id) Primary

Key

Form_Pnambahan_Id Foreign

Key

Departemen_Id

references Ms_Departemen(Departemen_Id)

4.3.2.2.4

One-to-one (1:1) Binary Relationship Types Untuk masing-masing one-to-one binary relationship types, entiti yang satu dianggap sebagai induk bila memiliki optional participation, dan entiti lainnya dianggap sebagai anak bila memiliki mandatory participation. Kemudian primary key dari entiti induk diletakkan ke entiti anak sebagai foreign key. 1. Relasi antar Ms_Admin dengan Ms_Departemen menghasilkan posting Admin_Id ke entiti Ms_Departemen

Post Admin_Id ke Ms_Departemen untuk model relasi 1 : 1 mengalami



Ms_Departemen (Departemen_Id, Nama_Departemen, Admin_Id)





131 2. Relasi antar Ms_User dengan Tr_Pnambahan_User menghasilkan posting User_Id ke entity Tr_Pnambahan_User Post User_Id ke Tr_Pnambahan_User untuk model relasi 1 : 1 mengalami

Ms_User

(User_Id,

Pass_User, Tanggal_Register,

Nama_User,

Tr_Pnambahan_User

Status_User,

(Form_Pnambahan_Id,

Departemen_Id,

Nama_User, Pass_User, Admin_Id,


Departemen_Id,

Primary Key User_Id

Tanggal_Transaksi)


Primary

Ms_Admin (Admin_Id)

Form_Penambahan_Id

Foreign

Key

references

Jenis_User_Id Ms_Jenis_User

User_Id,

Key

Foreign Key User_Id references Ms_User (User_Id)

(Jenis_User_Id) Foreign

Key

references


(Departemen_Id)

4.3.2.2.5

Many-to-many (*:*) Binary Relationship Types Untuk setiap hubungan many-to-many binary relationship types dibuat sebuah relasi yang merepresentasikan hubungan, termasuk semua atribut yang menjadi bagian dari hubungan tersebut.

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

Tr_Log

(Form_Log_Id,

Aplikasi_Id, Departemen_Id, Admin_Id)

Tanggal_Trans,


User_Id,

Jenis_Aksi,

Status_Trans,

Modul_Id,

SQL_Cmd,

Tanggal_Approval,

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,

Tr_Log

(Form_Log_Id,

Status_Aplikasi, Departemen_Id, Admin_Id)

Tanggal_Trans,


User_Id,

Jenis_Aksi,

Status_Trans,

Modul_Id,

SQL_Cmd,

Tanggal_Approval,

Aplikasi_Id,

Admin_Id,

Alasan_Reject, SQL_Cmd_Revisi) Primary Key Form_Log_Id Foreign

Key

(Modul_Id)

Ms_Modul(Modul_Id) Primary Key Modul_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

Modul_Id

references

Ms_Modul

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


Aplikasi_Id, Departemen_Id, Admin_Id)

Tanggal_Transaksi,


Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id,

Status_Transaksi,

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,


Status_Aplikasi, Departemen_Id, Admin_Id)

Tanggal_Transaksi,


Tanggal_Approval, User_Id, Modul_Id, Aplikasi_Id,

Status_Transaksi,

Admin_Id, Alasan_Reject, Is_Approval) Primary Key Form_PermintaanHA_Id Foreign

Key

(Modul_Id)

Ms_Modul(Modul_Id) Primary Key Modul_Id Foreign Key Aplikasi_Id references Ms_Aplikasi (Aplikasi_Id)

Modul_Id

references

Ms_Modul

134 Ms_Admin (Admin_Id, Nama_Admin,

Ms_Departemen (Departemen_Id,

Pass_Admin, Tanggal_Reg,


Status_Admin)




Ms_Modul

(Modul_Id,

Nama_Modul, Ms_Aplikasi

Aplikasi_Id, Departemen_Id, Admin_Id, Nama_Aplikasi,

(Aplikasi_Id, Departemen_Id,

Status_Modul)




Foreign Key Aplikasi_Id references Foreign Key Departemen_Id references Ms_Aplikasi (Aplikasi_Id)

Ms_Departemen (Departemen_Id)

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

Key

Admin_Id

Ms_Admin (Admin_Id)

references

Ms_Admin (Admin_Id) Ms_User

(User_Id,

Nama_User, Ms_Jenis_User

Pass_User, Tanggal_Register,

(Jenis_User_Id,

Status_User, Nama_Jenis_User) Departemen_Id, 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

135 Ms_Jenis_User (Jenis_User_Id) Foreign

Key

Admin_Id

references

Ms_Admin (Admin_Id) Ms_Hak_Akses Aplikasi_Id,

(Hak_Akses_Id, Tr_Log Values,

(Form_Log_Id,

User_Id, Modul_Id,

Admin_Id,

Is_Approval, Modul_Id)

SQL_Cmd,


Status_Trans,

Foreign

Key

User_Id

Tanggal_Approval,

Key

Modul_Id

Alasan_Reject,

SQL_Cmd_Revisi)) references Primary Key Form_Log_Id

Ms_User (User_Id) Foreign

Jenis_Aksi,

Tanggal_Trans,

Foreign Key Aplikasi_Id references Aplikasi_Id, Ms_Aplikasi (Aplikasi_Id)

User_Id,

Foreign

Key

User_Id

references

references Ms_User (User_Id)

Ms_Modul (Modul_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 (Form_Pnambahan_Id, Nama_User,

Pass_User,

Tr_Permintaan_HA User_Id, (Form_PermintaanHA_Id, Admin_Id, Modul_Id,

Aplikasi_Id,

User_Id, Values,

Departemen_Id, Tanggal_Transaksi)

Status_Transaksi,

Admin_Id,

Primary Key Form_Penambahan_Id

Tanggal_Transaksi, Tanggal_Approval,

136 Foreign

Key

User_Id

references Alasan_Reject, Is_Approval)

Ms_User (User_Id) Foreign

Key

Primary Key Form_PermintaanHA_Id

Admin_Id

references Foreign

Ms_Admin (Admin_Id)

Key

User_Id

references

Ms_User (User_Id)

Foreign Key Departemen_Id references Foreign Key Aplikasi_Id references Ms_Departemen (Departemen_Id)

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

4.3.2.3

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

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 = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id + @Modul_Id + Aplikasi_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan Reject + SQL_Cmd_Revisi 2 NF Tr_Header_Log = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id Tr_Detail_Log = @Form_Log_Id + @Modul_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi Ms_Modul = @Modul_Id + Aplikasi_Id 3 NF Tr_Header_Log = @Form_Log_Id + Tanggal_Trans + User_Id + Admin_Id Tr_Detail_Log = @Form_Log_Id + @Modul_Id + Jenis_Aksi + SQL_Cmd + Status_Trans + Tanggal_Approval + Alasan_Reject + SQL_Cmd_Revisi

138 Ms_Modul = @Modul_Id + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User = @Jenis_User_Id + Nama_Jenis_User Ms_Aplikasi = @Aplikasi_Id + Nama_Aplikasi + Departemen_Id + Admin_Id + Status_Aplikasi Ms_Departemen = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg + Status_Admin

Tr_Pnambahan_User (asumsi : setiap form hanya untuk satu tanggal) UNF Tr_Pnambahan_User = Form_Pnambahan_Id + Tanggal_Transaksi + {User_Id + Nama_User + Pass_User + Departemen_Id + Admin_Id} 1 NF Tr_Pnambahan_User = @Form_Pnambahan_Id + Tanggal_Transaksi + @User_Id + Nama_User + Pass_User + Departemen_Id + Admin_Id 2 NF Tr_HPnambahan_User = @Form_Pnambahan_Id + Tanggal_Transaksi Tr_DPnambahan_User = @Form_Penambahan_Id + @User_Id Ms_User = @User_Id + Nama_User + Pass_User+ Departemen_Id + Admin_Id

139 3 NF Tr_HPnambahan_User = @Form_Penambahan_Id + Tanggal_Transaksi Tr_DPnambahan_User = @Form_Penambahan_Id + @User_Id Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User = @Jenis_User_Id + Nama_Jenis_User Ms_Department = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg

Tr_Permintaan_HA (asumsi : setiap form hanya berlaku untuk satu user) UNF Tr_Permintaan_HA = Form_PermintaanHA_Id + User_Id + Admin_Id + {Tanggal_Transaksi

+

Modul_Id

+

Aplikasi_Id

+

Values

+

Status_Transaksi + Tanggal_Approval} 1NF Tr_Permintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id + Tanggal_Transaksi

+

@Modul_Id

+

Aplikasi_Id

+

Values

+

Status_Transaksi + Tanggal_Approval 2 NF Tr_HPermintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id Tr_DPermintaan_HA = @Form_PermintaanHA_Id + @Modul_Id + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi Ms_Modul = @Modul_Id + Departemen_Id

140 3 NF Tr_HPermintaan_HA = @Form_PermintaanHA_Id + User_Id + Admin_Id Tr_DPermintaan_HA = @Form_Permintaan_Id + @Modul_Id + Values + Status_Transaksi + Tanggal_Approval + Tanggal_Transaksi Ms_Modul = @Modul_Id + Nama_Modul + Aplikasi_Id + Departemen_Id + Admin_Id + Status_Modul Ms_Aplikasi = @Aplikasi_Id + Nama_Aplikasi + Departemen_Id

+

Status_Aplikasi + Admin_Id Ms_Department = @Departemen_Id + Nama_Departemen + Admin_Id Ms_Admin = @Admin_Id + Nama_Admin + Pass_Admin + Tanggal_Reg Ms_User = @User_Id + Nama_User + Pass_User + Status_User + Tanggal_Register + Departemen_Id + Admin_Id + Jenis_User_Id Ms_Jenis_User = @Jenis_User_Id + Nama_Jenis_User Ms_Hak_Akses = @Hak_Akses_Id + User_Id + Modul_Id + Aplikasi_Id + Values + Is_Approval

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

141

Gambar 4.10 ERD Logikal dengan Primary Key dan Foreign Key

4.3.2.4

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

142 4.3.2.4.1

Data Entry 1. Memasukkan detail dari admin baru (seperti detail admin bernama Susan) 2. Memasukkan detail dari user baru (seperti detail user bernama Gunawan) 3. Memasukkan detail dari departemen baru (seperti detail departemen Back Office) 4. Memasukkan detail dari aplikasi baru (seperti detail aplikasi VOIP Binus) 5. Memasukkan detail dari modul baru (seperti detail modul User Online pada aplikasi VOIP Binus) 6. Memasukkan detail dari hak akses user baru (seperti detail hak akses pada modul User Online di aplikasi VOIP Binus pada user Gunawan) 7. Memasukkan detail dari jenis user baru (seperti detail jenis user Manager)

4.3.2.4.2

Data Update atau Deletion 1. Meng-update atau men-delete detail seorang admin 2. Meng-update atau men-delete detail seorang user 3. Meng-update atau men-delete detail sebuah departemen 4. Meng-update atau men-delete detail sebuah aplikasi 5. Meng-update atau men-delete detail sebuah modul 6. Meng-update atau men-delete detail sebuah hak akses user

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

4.3.2.4.3

Data Queries (a) Tampilkan detail user yang berada di departemen Lecturer (b) Tampilkan detail hak akses berdasarkan kode aplikasi Ap001 (c) Tampilkan detail modul yang terdapat di aplikasi Ap002 (d) Tampilkan admin id yang berada di departemen Lecturer (e) Tampilkan detail penambahan user berdasarkan kode departemen Lecturer (f) Tampilkan detail aplikasi yang berada di departemen Lecturer (g) Tampilkan daftar permintaan hak akses yang dilakukan oleh user Us0001 (h) Tampilkan daftar permintaan hak akses selama sebulan terhadap aplikasi Ap001 (i) Tampilkan daftar transaksi log yang dilakukan oleh user Us0001 (j) Tampilkan daftar transaksi log selama sebulan terhadap aplikasi Ap001 (k) Tampilkan user berdasarkan jenis user Mhs (l) Tampilkan daftar admin yang memiliki status “aktif” (m) Tampilkan daftar hak akses yang memiliki is_approval “Yes” (n) Tampilkan daftar transaksi permintaan hak akses yang dilakukan pada tanggal 23 November 2007

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

4.3.2.5

Mendefinisikan Kendala Integrity Terdapat lima tipe dari kendala integrity antara lain:

4.3.2.5.1

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

4.3.2.5.2

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

4.3.2.5.3

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

145 4.3.2.5.4

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

4.3.2.5.5

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

Ms_Admin

(Admin_Id,

Nama_Admin,

Pass_Admin,

Tanggal_Reg,

Status_Admin) 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,

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,

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

(Form_PermintaanHA_Id,

Tanggal_Approval,

Modul_Id,

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

Values,

148 4.3.3

Perancangan Basis Data Fisikal Proses menghasilkan sebuah deskripsi atau gambaran implementasi basis data pada media penyimpanan yang menggambarkan hubungan dasar, organisasi data, dan indeks – indeks yang memungkinkan pengaksesan data yang efisien. Pada umumnya, tujuan utama dari perancangan basis data fisikal adalah menjelaskan bagaimana kita bermaksud untuk mengimplementasikan perancangan basis data logikal secara fisik. Pada perancangan basis data fisikal terdapat pembahasan perancangan Database Design Language (DBDL) untuk setiap entiti, perancangan constraint setiap entiti, analisis transaksi, pembuatan indeks, serta perancangan mekanisme keamanan data.

4.3.3.1

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

4.3.3.1.1

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

MySQL 5.0.20 Tipe DBMS

Transactional relational database server

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 1.5.4 untuk Windows versi 2000 ke atas. Membutuhkan software updated phpMyAdmin to 2.7.0

Portability

Dapat berjalan diatas berbagai macam OS.

Open Source

Karena bersifat open source, maka tidak ada biaya license.

Multiuser

Dapat digunakan oleh banyak user pada waktu yang bersamaan.

Security

Mempunyai beberapa lapisan keamanan seperti level subnetmask, nama host, user permission, dan password terenkripsi.

Scalability & Limits

Dapat menangani jumlah records lebih dari 50 juta dan jumlah tabel 60 ribu

Graphical user interface

Dapat menggunakan software sebagai

150 antarmuka grafis dengan user, sehingga memudahkan penggunaannya. Tabel 4.8 Karakteristik MySQL 5.0.20

4.3.3.1.2

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

fixed length character string, length 5

Domain NamaAdmin:

variable

length

character

string,

length

character

string,

length 50 Domain PasswordAdmin: variable length 50 Domain TanggalRegister: variable date, format datetime Domain StatusAdmin:

variable

length

character

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,

string,

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:


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:


Domain NamaModul:

variable length 50

length

character

string,

152 Domain AplikasiId:


Domain DepartemenId:

variable

length

character

string,

length 5 Domain AdminId:


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


153 4. DBDL untuk Ms_Aplikasi Domain AplikasiId:


Domain NamaAplikasi:

variable

length

character

string,

length

character

string,

length 50 Domain DepartemenId:

variable length 5

Domain AdminId:


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


KEY

(Admin_Id)

REFERENCES

Ms_Admin


154 5. DBDL untuk Ms_User Domain UserId:

variable

length

character

string,

length

character

string,

length

character

string,

length

character

string,

length

character

string,

length 10 Domain NamaUser:

variable length 50

Domain PasswordUser:

variable length 50

Domain StatusUser:

variable length 8

Domain JenisUserId:

variable length 5

Domain TanggalRegister: variable date, format datetime Domain DepartemenId:

variable

length

character

string,

length 5 Domain AdminId:


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,

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


KEY

(Admin_Id)

REFERENCES

Ms_Admin


6. DBDL untuk Ms_Jenis_User Domain JenisUserId:

variable

length

character

string,

length

character

string,

length 5 Domain NamaJenisUser:

variable length 20

Ms_Jenis_User ( Jenis_User_Id

JenisUserId

NOT NULL,

Nama_Jenis_User

NamaJenisUser

NOT NULL,

PRIMARY KEY (Jenis_User_Id) );

156 7. DBDL untuk Ms_Hak_Akses Domain HakAksesId:

integer, in the range 1-99999

Domain ModulId:


Domain AplikasiId:


Domain Values:

variable

length

character

string,

length

character

string,

length

character

string,

length 6 Domain IsApproval:

variable length 3

Domain UserId:

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

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:


Domain UserId:

variable

length

character

string,

length 10 Domain TanggalTrans:

variable date, format datetime

Domain AdminId:


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

158 );

9. DBDL untuk Tr_Detail_Log Domain FormLogId:


Domain ModulId:


Domain JenisAksi:

variable

length

character

string,

length

character

string,

length 6 Domain SqlCmd:

TEXT

Domain StatusTrans:

variable length 7

Domain TanggalApprove: variable date, format datetime Domain SqlCmdRevisi:

TEXT

Domain AlasanReject:

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

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:


Domain TanggalTrans:


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:


Domain UserId:


Domain NamaUser:


Tr_Dpnambahan_User ( Form_Pnambahan_Id FormPnambahanId

NOT NULL,

User_Id

NOT NULL,

UserId

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 1-99999 Domain UserId:


Domain AdminId:


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


161 13.

DBDL untuk Tr_DPermintaan_HA Domain FormPermintaanHAId: integer, in the range 1-99999 Domain ModulId


Domain Value

variable

length

character

string, length 6 Domain StatusTrans

variable

length

character

string, length 7 Domain TanggalApprove


Domain TanggalTrans


Domain AlasanReject

TEXT

Domain IsApproval

variable

length

character

string, length 3 Tr_DPermintaan_HA ( 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 ),

162 FOREIGN

KEY

(Modul_Id)

REFERENCES

Ms_Modul

(Modul_Id) ON UPDATE CASCADE ON DELETE NO ACTION );

4.3.3.1.3

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)

163 CONSTRAINT

PK

Ms_Departemen

PRIMARY

KEY

FK

Ms_Departemen

FOREIGN

KEY

(Departemen_Id) CONSTRAINT (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 (Departemen_Id)

FK

Ms_Modul REFERENCES

FOREIGN

KEY

Ms_Departemen

(Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION,

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

FK

Ms_Aplikasi

FOREIGN

KEY

(Aplikasi_Id) CONSTRAINT (Departemen_Id)

REFERENCES

Ms_Departemen

(Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT (Admin_Id)

FK

Ms_Aplikasi

FOREIGN



KEY

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

(Jenis_User_Id)

Ms_User

FOREIGN

REFERENCES

KEY

Ms_Jenis_User

(Jenis_User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT (Departemen_Id)

FK

Ms_User

FOREIGN

REFERENCES

KEY

Ms_Departemen

(Departemen_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT FK Ms_User FOREIGN KEY (Admin_Id) REFERENCES

Ms_Admin

(Admin_Id)

CASCADE ON DELETE NO ACTION )

ON

UPDATE

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

FK

Ms_Hak_Akses

FOREIGN

KEY

(Hak_Akses_Id) CONSTRAINT (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 )

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

FK

Tr_Header_Log

FOREIGN

KEY

(Form_Log_Id) CONSTRAINT

(User_Id) REFERENCES Ms_User (User_Id) ON UPDATE CASCADE ON DELETE NO ACTION, CONSTRAINT (Admin_Id)

FK

Tr_Header_Log

FOREIGN

KEY



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

168 Sql_Cmd_Revisi TEXT Alasan_Reject TEXT CONSTRAINT

PK

Tr_Detail_Log

PRIMARY

KEY

FK

Tr_Detail_Log

FOREIGN

KEY

(Form_Log_Id) CONSTRAINT (Modul_Id)



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)

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)



13. Constraint untuk Tr_Dpermintaan_HA CREATE TABLE Tr_Dpermintaan_HA ( Form_PermintaanHA_Id INT (5) Modul_Id CHAR (5)

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)



4.3.3.2

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.

4.3.3.2.1

Analisis Transaksi Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari transaksi yang akan berjalan pada basis data untuk menganalisa

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

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 November 2007

173 Analisis Transaksi untuk Transaksi A – D Transaksi/Relasi

(A) I

Ms_Admin

(B)

R U D I

(C)

R U D I

(D)

R U D I

R U D

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) I

R U D I

(F) R U D I

(G)

(H)

R U D I R U D

Ms_Admin

x

Ms_Departemen

x

x

174 Ms_Modul

x

x

Ms_Aplikasi

x

Ms_User

x

Ms_Jenis_User

x

Ms_Hak_Akses

x

Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User Tr_DPnambahan_User Tr_HPermintaan_HA

x

Tr_DPermintaan_HA

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

(I) I

(J)

R U D I

(K)

R U D I

(L)

R U D I

R U D

Ms_Admin Ms_Departemen

x

Ms_Modul

x

x

x

Ms_Aplikasi

x

x

x

Ms_User Ms_Jenis_User

x

x

x

x x

x

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

(M) I

(N)

R U D I

(O)

R U D I

R U D I

(P) R U D

Ms_Admin Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User

x

Ms_Jenis_User Ms_Hak_Akses Tr_Header_Log Tr_Detail_Log Tr_HPnambahan_User

x x

x

x x

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

(Q) I

R U D I

(R) R U D I

Ms_Admin

x

Ms_Departemen

x

Ms_Modul

(S) R U D I

(T) R U D

x

Ms_Aplikasi

x

Ms_User 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.13 Cross-referencing transactions and relations (Q) – (T)

177 Analisis Transaksi untuk Transaksi U – X Transaksi/Relasi

(U) I

R U D I

(V) R U D I

(W)

(X)

R U D I

R U D

Tr_Header_Log

x

x

Tr_Detail_Log

x

x

Ms_Admin Ms_Departemen Ms_Modul Ms_Aplikasi Ms_User Ms_Jenis_User Ms_Hak_Akses

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

(Y) I

Ms_Admin Ms_Departemen

R U D I

(Z) R U D I x

(AA)

(BB)

R U D I

R U D

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

x

Tr_DPermintaan_HA

x

I = Insert, R = Read, U = Update, D = Delete Tabel 4.15 Cross-referencing transactions and relations (Y) – (BB)

4.3.3.2.2

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

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.

4.3.3.2.3

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);

180 6. 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);

181 4.3.3.2.4

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,

b.form_permintaanha_id, f.nama_admin FROM

c.values,

c.tanggal_trans,

b.admin_id, a.departemen_id,

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 c.status_trans = 'Pending' order by b.form_permintaanha_id

and

182 3. 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,

d.nama_modul, c.tanggal_approve,

b.user_id,

e.nama_aplikasi,

c.values,c.Tanggal_Trans,

c.status_trans,

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

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

k.aplikasi_id=h.aplikasi_id

and

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

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

ms_departemen d

u,

ms_admin

a,

ms_jenis_user

ju,

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

4.3.3.2.5

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

186 setiap tabel atau entiti dengan atribut – atribut yang ada didalamnya serta tipe data yang digunakan, antara lain: 1. Tabel Ms_Admin Tabel / Entiti Ms_Admin

Atribut

Deskripsi

Admin_Id

Kode Admin

Tipe Data Char

Ukuran (Byte)

Nama_Admin

Nama Admin

Varchar

51

Pass_Admin

Password Admin

Varchar

51

Tanggal_Register

Tanggal

Datetime

8

Varchar

9

5

pendaftaran Admin Status_Admin

Status Admin (aktif atau nonaktif)

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 = 0 + 1116 = 1116 bytes Tabel 4.16 Perkiraan kebutuhan disk space pada tabel Ms_Admin

2. Tabel Ms_Departemen Tabel / Entiti

Atribut

Ms_Departemen Departemen_Id

Deskripsi

Tipe Data

Ukuran (Byte)

Kode departemen

Varchar

6

Nama_Departemen

Nama departemen

Varchar

51

Admin_Id

Kode Admin

Char

5

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 = 0 + 496 = 496 bytes Tabel 4.17 Perkiraan kebutuhan disk space pada tabel Ms_Departemen

3. Tabel Ms_Modul Tabel / Entiti Ms_Modul

Atribut

Deskripsi

Modul_Id

Kode modul

Tipe Data Char

Ukuran (Byte)

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

Varchar

9

5

atau nonaktif) JUMLAH

82

Kapasitas awal Tabel Ms_Modul (128 record) = 128 * 82 = 10496 bytes Diperkirakan dalam satu tahun terjadi penambahan 50 record baru = 50 * 82 = 4100 bytes Dalam 1 tahun pertumbuhan tabel adalah 10496 + 4100 = 14596 bytes Tabel 4.18 Perkiraan kebutuhan disk space pada tabel Ms_Modul

188 4. Tabel Ms_Aplikasi Tabel / Entiti Ms_Aplikasi

Atribut

Deskripsi

Aplikasi_Id

Kode aplikasi

Tipe Data Char

Ukuran (Byte)

Nama_Aplikasi

Nama aplikasi

Varchar

51

Departemen_Id

Kode departemen

Varchar

6

Admin_Id

Kode Admin

Char

5

Status_Aplikasi

Status aplikasi

Varchar

9

6

(aktif atau nonaktif) 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 1386 + 385 = 1771 bytes Tabel 4.19 Perkiraan kebutuhan disk space pada tabel Ms_Aplikasi

5. Tabel Ms_User Tabel / Entiti Ms_User

Atribut

Deskripsi

User_Id

Kode user

Tipe Data Varchar

Ukuran (Byte)

Nama_User

Nama user

Varchar

51

Pass_User

Password user

Varchar

51

Status_User

Status user (aktif

Varchar

9

11

atau nonaktif) Jenis_User_Id

Kode jenis user

Varchar

6

Tanggal_Register

Tanggal

Datetime

8

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 = 13230 bytes Diperkirakan dalam satu tahun terjadi penambahan 20 record baru = 20 * 147 = 2940 bytes Dalam 1 tahun pertumbuhan tabel adalah 13230 + 2940 = 16170 bytes Tabel 4.20 Perkiraan kebutuhan disk space pada tabel Ms_User

6. Tabel Ms_Jenis_User Tabel / Entiti

Atribut

Deskripsi

Ukuran (Byte)

Kode jenis user

Tipe Data Varchar

Ms_Jenis_User

Jenis_User_Id Nama_Jenis_User

Nama jenis user

Varchar

21

6

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 0 + 81 = 81 bytes Tabel 4.21 Perkiraan kebutuhan disk space pada tabel Ms_Jenis_User

7. Tabel Ms_Hak_Akses Tabel / Entiti

Atribut

Deskripsi

Ms_Hak_Akses Hak_Akses_Id

Kode hak akses

Tipe Data Int

Nama modul

Char

Modul_Id

Ukuran (Byte) 4 5

190 Aplikasi_Id

Kode Aplikasi

Char

6

Values

Aksi (terdiri dari

Varchar

7

Varchar

4

Varchar

11

insert, update, delete) Is_Approval

Status yang menandakan suatu transaksi perlu mendapat tindakan approval atau tidak

User_Id

Kode user JUMLAH

37

Kapasitas awal Tabel Ms_Hak_Akses (500 record) = 500 * 37 = 18500 bytes Diperkirakan dalam satu tahun terjadi penambahan 100 record baru = 100 * 37 = 3700 bytes Dalam 1 tahun pertumbuhan tabel adalah 3700 + 18500 = 22200 bytes Tabel 4.22 Perkiraan kebutuhan disk space pada tabel Ms_Hak_Akses

8. Tabel Tr_Header_Log Tabel / Entiti

Atribut

Deskripsi

Tr_Header_Log Form_Log_Id

Kode formulir

Tipe Data Int

Ukuran (Byte) 4

transaksi log User_Id

Kode user

Varchar

11

Tanggal_Trans

Tanggal terjadinya

Datetime

8

transaksi log

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 + 0 = 2800 bytes Tabel 4.23 Perkiraan kebutuhan disk space pada tabel Tr_Header_Log

9. Tabel Tr_Detail_Log Tabel / Entiti

Atribut

Deskripsi

Tr_Detail_Log

Form_Log_Id

Kode formulir

Tipe Data Int

Ukuran (Byte) 4

transaksi log Modul_Id

Nama modul

Char

5

Jenis_Aksi

Jenis aksi yang

Varchar

7

dilakukan oleh user terhadap aplikasi yang diaksesnya Sql_cmd

Jenis aksi yang

Text

102

ditulis dalam sintaks SQL secara lengkap Status_Trans

Status transaksi

Varchar

8

Datetime

8

(aktif atau nonaktif) Tanggal_Approve

Tanggal terjadinya

192 proses pengapprove-an daftar transaksi oleh Admin Sql_Cmd_Revisi

Status yang

Text

102

Text

102

menandakan suatu transaksi perlu mendapat tindakan approval atau tidak Alasan_Reject

Alasan yang menjelaskan kenapa suatu transaksi di-reject

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 = 33800 bytes Dalam 1 tahun pertumbuhan tabel adalah 33800 + 0 = 33800 bytes Tabel 4.24 Perkiraan kebutuhan disk space pada tabel Tr_Detail_Log

193 10. Tabel Tr_HPnambahan_User Tabel / Entiti

Atribut

Deskripsi

Tr_HPnambahan_User Form_Pnambahan_Id Kode formulir

Tipe Data Int

Ukuran (Byte) 4

transaksi penambahan user Tanggal_Trans

Tanggal

Datetime

8

terjadinya transaksi penambahan user 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 + 0 = 240 bytes Tabel 4.25 Perkiraan kebutuhan disk space pada tabel Tr_HPnambahan_User

11. Tabel Tr_DPnambahan_User Tabel / Entiti

Atribut

Deskripsi

Tr_DPnambahan_User Form_Pnambahan_Id Kode formulir transaksi penambahan user

Tipe Data Int

Ukuran (Byte) 4

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 + 0 = 1320 bytes Tabel 4.26 Perkiraan kebutuhan disk space pada tabel Tr_DPnambahan_User

12. Tabel Tr_HPermintaan_HA Tabel / Entiti Tr_HPermintaan_HA

Atribut

Deskripsi

Form_PermintaanHA_Id Kode formulir

Tipe Data Int

Ukuran (Byte) 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 + 0 = 2000 bytes Tabel 4.27 Perkiraan kebutuhan disk space pada tabel Tr_HPermintaan_HA

195 13. Tabel Tr_DPermintaan_HA Tabel / Entiti

Atribut

Deskripsi

Tr_DPermintaan_HA Form_PermintaanHA_Id Kode formulir

Tipe Data Int

Ukuran (Byte) 4

transaksi permintaan hak akses Modul_Id

Kode modul

Char

5

Values

Aksi (terdiri

Varchar

7

Varchar

8

Datetime

8

Datetime

8

dari insert, update, delete) Status_Trans

Status transaksi (aktif atau nonaktif)

Tanggal_Approve

Tanggal terjadinya proses pengapprove-an permintaan hak akses oleh Admin

Tanggal_Trans

Tanggal terjadinya transaksi

196 permintaan hak akses Alasan_Reject

Alasan yang

Text

102

menjelaskan kenapa suatu transaksi direject Is_Approval

Status yang

Varchar

4

menandakan suatu transaksi perlu mendapat tindakan approval atau tidak 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 = 14600 bytes Dalam 1 tahun pertumbuhan tabel adalah 0 + 14600 = 14600 bytes Tabel 4.28 Perkiraan kebutuhan disk space pada tabel Tr_DPermintaan_HA

197 Berikut perkiraan kebutuhan disk space untuk semua tabel : Tabel /Entiti

Kapasitas Awal (bytes)

Ms_Admin

1116

Pertumbuhan setiap tahun (bytes) 0

Kapasitas yang diperlukan 1 tahun pertama (bytes) 1116

Ms_Departemen

496

0

496

Ms_Modul

10496

4100

14596

Ms_Aplikasi

1386

385

1771

Ms_User

13230

2940

16170

Ms_Jenis_User

81

0

81

Ms_Hak_Akses

18500

3700

22200

Tr_Header_Log

0

2800

2800

Tr_Detail_Log

0

33800

33800

Tr_HPnambahan_User

0

240

240

Tr_DPnambahan_User

0

1320

1320

Tr_HPermintaan_HA

0

2000

2000

Tr_DPermintaan_HA

0

14600

14600

Total disk space awal yang dibutuhkan 45305 bytes atau 45,305 Kilobytes Pertumbuhan setiap tahun sebesar 65885 bytes atau 65,885 Kilobytes Total disk space yang dibutuhkan pada tahun pertama sebesar 111190 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

198 4.3.3.2.6

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

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;

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;

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;

202 4.4

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

4.4.1

Perancangan Struktur Menu Perancangan Struktur Menu dapat dilihat pada gambar berikut.

203

Gambar 4.11 Perancangan Struktur Menu

204 4.4.2

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

205

Gambar 4.14 STD Menu Home Admin

Gambar 4.15 STD Menu Daftar Approval

206

Gambar 4.16 STD Menu User

Gambar 4.17 STD Menu Aplikasi

207

Gambar 4.18 STD Menu Modul

Gambar 4.19 STD Menu Hak Akses

BAB 4 PERANCANGAN SISTEM BASIS DATA

Recommend Documents