BAB 4 RANCANGAN SISTEM YANG DIUSULKAN. Prosedur prosedur yang diusulkan adalah sebagai berikut : 1. Prosedur Permintaan Pengadaan Aset TI

(1)

BAB 4

RANCANGAN SISTEM YANG DIUSULKAN

4.1 Usulan Prosedur Yang Baru

Prosedur – prosedur yang diusulkan adalah sebagai berikut : 1. Prosedur Permintaan Pengadaan Aset TI

a. Staf mengajukan aset TI yang diperlukan dalam bentuk Purchase

Requisition (PR).

b. kemudian PR diperiksa dan disetujui oleh Vice President (VP) / General

Manager (GM) unit yang mengajukan pengadaan aset TI.

2. Prosedur Persetujuan Pendanaan Aset TI

a. PR yang diterima oleh Bagian Anggaran (Corporate Budget) diperiksa ketersediaan anggarannya atas aset tersebut pada tahun berjalan.

b. VP / GM Bagian Anggaran akan menyetujui PR yang diajukan bila aset tersebut dianggarkan.

c. Kemudian PR yang telah disetujui bagian anggaran diserahkan pada Bagian Keuangan (Finance) untuk diperiksa kesediaan dana yang diperlukan.

d. VP / GM Bagian Keuangan akan menyetujui PR yang diajukan bila dana untuk aset yang diajukan tersedia.

e. PR yang telah disetujui oleh ketiga pihak tersebut diatas diserahkan pada Bagian Pengadaan (Replenishment).

(2)

3. Prosedur Pemesanan Asset TI

a. Bagian Pengadaan (Replenishment) membuat Purchase Order (PO). b. PO dibuat 5 rangkap yang dikirim :

1) Asli ke Vendor 2) Copy 1 ke Purchaser

3) Copy 2 ke Bagian Akuntansi 4) Copy 3 ke Bagian Keuangan 5) Copy 4 ke Bagian Inventory

c. PO yang diterima didata dan dikelola dalam sistem yang diusulkan.

4. Prosedur Penerimaan Aset TI

a. Vendor mengirimkan Delivery Order (DO) beserta asset TI yang dipesan sesuai PO kepada Bagian Pengadaan (Replenishment).

b. Bagian Pengadaan mengirimkan aset TI tersebut pada unit yang mengajukan.

c. DO tersebut diduplikasi menjadi 5 rangkap yang dikirim : 1) Asli ke Vendor digunakan saat penagihan

2) Copy 1 ke Purchaser

3) Copy 2 ke Bagian Akuntansi 4) Copy 3 ke Bagian Keuangan 5) Copy 4 ke Bagian Inventory

(3)

5. Prosedur Pendataan Aset

a. DO yang diterima didata dan dikelola dalam sistem yang diusulkan. b. Setiap aset TI yang diterima diberikan Asset Number sebagai identitas

aset perusahaan.

c. Deskripsi detail setiap aset TI didata ke dalam sistem yang diusulkan sesuai dengan Asset Number yang diberikan.

d. Sistem secara otomatis memberikan peringatan dini kepada pengguna atas waktu kadaluarsa aset TI.

6. Prosedur Pelaporan Aset TI

a. Laporan Aset TI dibuat secara berkala setiap tahunnya baik secara detail maupun secara umum (summary).

b. Laporan berisi informasi aset TI yang sedang digunakan (current) maupun yang sudah tidak digunakan (historical).

c. Laporan Aset TI yang berisi nilai dan kuantitas aset ditujukan untuk Bagian Keuangan.

d. Bagian Pengadaan (Replenishment) dapat melihat laporan aset TI secara detail maupun umum.

e. Setiap Vice President (VP) / General Manager (GM) dapat melihat laporan aset TI pada unit yang dipimpinnya.

f. Setiap user yang memiliki hak akses dapat melakukan pencarian (searching) aset TI baik informasi aset TI yang sedang digunakan (current) maupun yang sudah tidak digunakan (historical) .

(4)

4.2 Diagram Aliran Data

4.2.1 Diagram Hubungan (Context Diagram)

Siste m IT Asse t Manage me nt Vendor Finance Re pl e nishme nt VP / GM IT As se t Re p o r t r e qu e st by VP / G M F ina n c ia l I T As se t Re po r t PO D u p lica te P O DO Dupl ic a te DO Re que st Re sul t by VP / G M r e qu e st by F in a n c e Re que st R e sul t by F in a n c e r e q u e st by Re pl e n is hm e n t Re qu e st Re su lt by r e pl e n is hm e n t R e pl e n is hm e n t IT Asse t Re po r t Staff PR C orporate Budge t P R l ist f o r c h e c ki ng bud g e t A p p r o val P R li st b y C o rp o r a te B u d g et PR S ta tu s A ll o f A p p r ov al PR lis t PR L is t fo r V P / GM A p p r ov al P R L is t b y V P /G M A p p r ov al P R li st b y F in a n c e PR lis t f o r ch ec k in g f in a n c ia l

Gambar 4.1 Context Diagram Sistem yang diusulkan

(5)

4.2.2 Diagram Nol Vendor D upl ic a te P O DO O rdering 3 Replenishment PO As et PO form Receiving 4 D u p lic a te D O Managing 5 DO file DO form Reporting 7 report form Finance F ina nc ia l I T A sse t R e p o r t VP / GM IT A sse t R e p o r t Login 6 valid username & password permit us er na m e & pa ss w o r d us er na m e & pa ss w o r d us er na m e & pa ss w o r d Replenishment IT Asset Report As e t Approving 2 Requesting 1 Approval PR PR Staff Request Approval by VP / GM Approval by Corporate Budget Approval by Finance Corporate Budget

(6)

4.2.3 Diagram Rinci Staff Re que st C olle ct Re que st 1.1 Make PR 1.2 Re que st C olle ction Re ple nishme nt Finance C orporate Budget PR VP / GM Approve by VP / GM 2.1 Approve Budge t 2.2 Approval PR for Budget Approve Finance 2.3 Approval Approval Approval PR by VP / GM Approval Approval PR

(7)

Vendor Dupl ic a te P O

Make Dupl icate PO 3.1 Re pl e nishme nt PO PO form As e t Manage PO to database 3.2 Dupl i cate PO

Gambar 4.4 Diagram Rinci Proses Ordering

Vendor DO Re plenishment Make Duplicate DO 4.2 Receive DO 4.1 Du p li c a te D O 5.1 DO file PO files As e t Check DO 5.2 Manage DO as Asset Asset data Valid DO received DO

(8)

Reple nishment Make Ge neral Report 7.2 report form Finance Financial IT Asse t Report VP / GM IT Asse t Report

C heck use rname & password

6.1 valid use rname & password

permit

use rname & password use rname & password username & password Re ple nishment IT Asse t Report As e t

Make Unit Report 7.3 Make Finacial Report 7.4 C he ck status 7.1 status

Gambar 4.6 Diagram Rinci Proses Login dan Reporting

4.3 Perancangan Basisdata

Perancangan basisdata dilakukan sesuai dengan kebutuhan informasi PT. GIA, difokuskan pada perancangan basisdata yang meliputi tiga tahap, antara lain:

• Perancangan basisdata konseptual • Perancangan basisdata logikal • Perancangan basisdata fisikal

4.3.1 Perancangan Basisdata Konseptual

Pada tahapan perancangan basisdata konseptual ini, perancangan basisdata dipusatkan pada pemrosesan suatu model dari informasi yang akan digunakan dalam suatu organisasi.

(9)

Langkah 1. Membangun Model Data Konseptual

Berikut ini adalah langkah – langkah didalam merancang basisdata konseptual, antara lain :

4.3.1.1 Mengidentifikasi tipe entiti

Hasil identifikasi entiti diperoleh dari hasil wawancara dari pihak terkait yang tertuang dalam ruang lingkup dan objek – objek yang terlibat pada sistem yang sedang berjalan serta sistem yang diusulkan.

Entiti – entiti yang didapat dari ruang lingkup adalah: • Staf menjadi entiti Employee

• Unit menjadi entiti Unit • Pengguna menjadi entiti User

• Purchase Requisition menjadi entiti Purchase Requisition • Purchase Order menjadi entiti Purchase Order

• Vendor menjadi entiti Vendor

• Delivery Order menjadi entiti Delivery Order • Aset yang sedang digunakan menjadi entiti Asset

• Aset yang sudah tidak digunakan lagi menjadi entiti History Entiti – entiti yang didapat dari Diagram Aliran Data sistem yang sedang berjalan adalah:

• Staf menjadi entiti Employee • Vendor menjadi entiti Vendor

• Replenishment, VP / GM, Corporate Budget, Finance menjadi entiti User

(10)

Entiti – entiti yang didapat dari Diagram Aliran Data sistem yang diusulkan adalah:

• Staf menjadi entiti Employee • Vendor menjadi entiti Vendor

• Replenishment, VP / GM, Corporate Budget, Finance menjadi entiti User

Berikut entiti – entiti yang terbentuk dari hasil identifikasi di atas: Tabel 4.1 Tabel Identifikasi tipe entiti

Entity Name Description Aliases Occurence

Unit Menjelaskan unit – unit yang ada pada PT. GIA

Bidang Setiap unit pada PT. GIA

User Menjelaskan orang yang

menggunakan sistem ini

Pengguna Setiap orang yang mempunyai hak akses menggunakan sistem ini Employee Menjelaskan staf yang

bekerja pada PT.GIA

Staf Setiap orang yang

menggunakan aset TI Vendor Menjelaskan orang,

kelompok, atau perusahaan yang menyediakan barang

Penyedia Setiap vendor

menyediakan barang (aset) ke PT. GIA

Delivery Order

Menjelaskan informasi tentang barang (aset) yang dikirimkan ke PT.GIA

Daftar kirim barang

Setiap barang (aset) yang dikirim ke PT.GIA dicatat dalam Delivery Order Purchase

Order

Menjelaskan informasi tentang barang (aset) yang dipesan oleh PT.GIA

Daftar pesan barang

Setiap barang (aset) yang dipesan oleh PT.GIA dicatat dalam Purchase Order

Asset Menjelaskan informasi

tentang barang (aset) yang

Barang Setiap barang (aset) yang digunakan pada PT. GIA

(11)

digunakan pada PT. GIA

History Menjelaskan kegiatan – kegiatan yang terjadi pada tiap barang (aset)

Sejarah Setiap barang (aset) yang digunakan dan pernah digunakan pada PT. GIA Purchase

Requisition

Menjelaskan informasi tentang barang (aset) yang dipesan oleh staf

Daftar Permintaan

Setiap barang (aset) yang dipesan oleh staf dicatat

dalam Purchase Requesition

4.3.1.2 Mengidentifikasi tipe relasi

Hasil identifikasi tipe relasi yang telah kami rancang ditampilkan dalam tabel berikut ini:

Tabel 4.2 Tabel identifikasi tipe relasi

Entity Name Multiplicity Relationship Entity Name Multiplicity

0..1 Leads Unit 0..*

Unit

1..1 Has Employee 1..*

1..1 Makes Delivery Order 1..*

Vendor

1..1 Receives Purchase Order 1..* Delivery Order 1..1 Consist of Asset 1..* Purchase Order 1..1 Has Delivery Order 1..*

Asset 0..1 Save in History 1..1

1..* Request Purchase Requisition 1..* 1..* Uses Asset 0..* Employee 1..1 Becomes User 0..* Purchase Requisition

(12)

Berikut ini merupakan gambaran relasi dari entiti – entiti yang ada: UNIT VENDOR EMPLOYEE USER PURCHASE ORDER HISTORY ASSET DELIVERY ORDER Leads Has Uses Is Approv ed be Becomes Makes Receiv es Consist of Sav e as 0..* 1..1 1..* 0..* 1..1 1..1 1..* 1..* 0..* 1..1 1..* 1..* 1..1 1..1 1..* 0..1 1..1 Has 1..1 1..* PURCHASE REQUISITION Request 1..* 1..* 1..1

(13)

4.3.1.3 Mengidentifikasi dan mengasosiasikan atribut – atribut dengan entiti atau tipe-tipe relasi

Atribut –atribut dari entiti diatas disajikan dalam tabel – tabel sebagai berikut:

Tabel 4.3 Tabel identifikasi dan asosiasi atribut – atribut dengan entiti atau tipe – tipe relasi

Entity Name

Atributes Description Data

Type

Length Nulls Multi- valued

Unit_Code Secara unik mengidentifikasi

unit

Char 5 No No

Desc Penjelasan kode unit Varchar 50 Yes No

Unit

UpUnit_Code Tingkatan diatas unit Char 5 Yes No

User_ID Secara unik

mengidentifikasikan user

Char 5 No No

User_Name Nama user Varchar 50 No No

Password Kata kunci yang digunakan

oleh pengguna untuk mengakses sistem

Varchar 35 No No

Status Keterangan hak akses user

dalam sistem

Varchar 10 No No

Last_Login Keterangan waktu terakhir login

Datetime 8 No No User

Emp_ID Staf yang bertindak sebagai

pengguna sistem

Char 5 No No

Emp_ID Secara unik

mengindentifikasikan staf (employee)

Char 6 No No

Emp_Name Nama Staf (employee) Varchar 50 No No

Sex Jenis Kelamin Char 1 No No

Place_of_Birth Tempat Lahir Varchar 25 Yes No

Employee

(14)

Address Alamat Staf (employee) Varchar 100 No No

Phone Telepon Staf(employee) Varchar 15 Yes Yes

Email Alamat Staf (employee) Varchar 30 No Yes

Unit_Code Unit dimana user berada Char 5 No No

Vendor_ID Secara unik mengidentifikasi

vendor

Char 5 No No

Vendor_Name Nama vendor Varchar 100 No No

Address Alamat vendor Varchar 100 No No

Phone_No Telepon vendor Varchar 15 No Yes

Fax No.fax vendor Varchar 15 Yes No

Email Alamat email vendor Varchar 30 No Yes

Contact_Person Nama personal dari vendor yang dapat dihubungi

Varchar 50 No No Vendor

Contact_Person_ Phone

No.Telp personal dari vendor yang dapat dihubungi

Varchar 15 No No

DO_No Secara unik mengidentifikasi

delivery order

Char 15 No No

Date_of_Issued Tanggal DO dibuat Date 8 No No

Vendor_ID Menyatakan sebagai pihak

yang mengirim DO

Char 5 No No

Vendor_Name Nama pihak yang mengirim

DO

Varchar 100 No No

Ship_to Menyatakan tempat barang

akan dikirimkan

Varchar 100 No No Ref.

PPB/PPJ_No

Menyatakan No PPB/PPJ Varchar 50 No No

Ref. Contract_No Menyatakan No Contrak yang dibuat

Varchar 25 No No

Item_Code Mengidentifikasi item / aset Char 15 No No

Item_Description Keterangan item / aset Varchar 100 No No

Quantity Menyatakan banyaknya aset Int 4 No No

Unit Satuan asset Varchar 10 No No

Delivery Order

(15)

le

Note Keterangan lain Varchar 50 Yes No

PO_No Menyatakan kesesuaian daftar

pesanan

Char 10 No No

Emp_ID Staf yang menerima DO dari

vendor

Char 5 No No

Emp_Name Nama staf yang menerima

DO dari vendor

Varchar 50 No No

PO_No Secara unik mengidentifikasi

Purchase order

Char 10 No No

Date_Of_Issued Tanggal PO dibuat Date 8 No No

Vendor_ID Menyatakan sebagai pihak

yang menerima PO

Char 5 No No

Vendor_Name Nama pihak yang menerima

PO

Varchar 100 No No

Ship_to Menyatakan tempat aset akan

dikirimkan

Varchar 100 No No

Ref.PPB/PPJ_No Menyatakan No PPB/PPJ Varchar 50 No No

Quantity Menyatakan banyaknya aset Int 4 No No

Unit Satuan aset Varchar 10 No No

Unit_Price Harga aset Numeric 15 No No

Total_Price Menyatakan banyaknya aset

dikalikan harga aset

Numeric 15 No No

Note Keterangan lain Varchar 50 Yes No

Total Menyatakan harga total

terhadap semua aset yang terdaftar dalam PO

Numeric 15 No No

Disc Potongan Harga Int 4 No No

Nett Harga total setelah dikurangi

potongan harga

Numeric 15 No No Purchase

Order

(16)

atas Nett

Emp_ID Staf yang bertanggung jawab

atas PO yang dibuat

Char 5 No No

Emp_Name Nama staf yang bertanggung

atas PO yang dibuat

Varchar 100 No No

Asset_No Secara unik mengidentifikasi

aset

Char 15 No No

Asset _Name Nama aset Varchar 50 No No

Brand Merk aset Varchar 20 No No

Type Tipe aset Varchar 20 No No

Serial_No No.seri aset Char 10 Yes No

DO_No Nomor DO suatu aset Char 10 No No

Date_of_Issued Tanggal kedatangan aset Datetime 8 No No

Price Harga aset Numeric 15 No No

Currency Mata uang yang digunakan Char 3 No No

Time_Usage Lama pemakaian aset Int 4 No No

Unit_Code Unit dimana aset berada Char 5 No No

Status Keterangan kepemilikan aset Varchar 20 No No

Asset

Emp_ID Staf yang menggunakan aset Char 5 Yes No

History_ID Secara unik mengidentifikasi sejarah (history) aset

Char 15 No No

Asset_No Secara unik mengidentifikasi

aset

Char 15 No No

Asset_Name Nama aset Varchar 50 No No

Brand Merk aset Varchar 20 No No

Type Tipe aset Varchar 20 No No

Serial_No No.seri aset Keterangan

kepemilikan aset

Char 10 Yes No

History

(17)

Date_Of_Issued Tanggal kedatangan aset Date 8 No No

Price Harga asset Numeric 15 No No

Currency Mata uang yang digunakan Char 3 No No

Time_Usage Lama waktu pemakaian aset Int 4 No No

Unit_Code Unit dimana aset berada Char 5 No No

Status Keterangan kepemilikan aset Varchar 20 No No

Emp_ID Staf yang menggunakan aset Char 5 Yes No

Expired_Date Tanggal kadaluarsa aset Date 8 Yes No

Expired_Desc Keterangan kadaluarsa aset Varchar 50 Yes No

Historical_Status Status keberadaan aset Varchar 20 No No

PR_No Secara unik mengidentifikasi

purchase requisition

Char 10 No No

Date_Of_Issued Tanggal PR dibuat Date 8 No No

Item_Material_ Code

Mengidentifikasi item / aset Char 15 No No

Unit_Price Harga satuan item / aset Numeric 15 No No

Quantity Jumlah item / aset Int 4 No No

Total Menyatakan banyaknya aset

dikalikan harga aset

Numeric 50 No No

Item_Note Keterangan lain Varchar 50 Yes No

Grand_Total Menyatakan harga total

terhadap semua aset yang terdaftar dalam PR

Numeric 15 No No Purchase

Requisitio n

(18)

4.3.1.4 Menentukan candidate, primary, dan alternate key

Berikut merupakan tabel yang menjelaskan candidate key dan primary key dari setiap entiti :

Tabel 4.4 Tabel penjelasan candidate key dan primary key dari setiap entiti

Name Candidate key Primary key Alternate key

Unit Unit_Code, UpUnit_Code Unit_Code UpUnit_Code

User User_ID, Emp_ID User_ID Emp_ID

Employee Emp_ID Emp_ID

Vendor Vendor_ID Vendor_ID

Delivery Order DO_No DO_No

Purchase Order

PO_No PO_No

Asset Asset_No, Item_Code, Serial_No Asset_No Item_Code, Serial_No

History History_ID, Asset_No, Serial_No

History_ID Asset_No, Serial_No Purchase

Requisition

(19)

Berikut ini adalah ER diagram dengan penambahan primary key: Leads Has Uses Is Approv ed be Becomes Makes Receiv es Consist of Sav e as 0..* 1..1 1..* 0..* 1..1 1..1 1..* 1..* 0..* 1..1 1..* 1..* 1..1 1..1 1..* 0..1 1..1 Has 1..1 1..* Request 1..* 1..* UNIT Unit_Code EMPLOYEE Employee_ID PURCHASE REQUISITION PR_No PURCHASE ORDER DO_No VENDOR Vendor_ID USER User_ID DELIVERY ORDER DO_No ASSET Asset_No HISTORY History_ID 1..1

(20)

4.3.1.5 Mempertimbangkan Penggunaan Konsep Model Enhanced

Hasil pertimbangan penggunaan konsep model enhanced yang telah kami rancang ditampilkan dalam ER Diagram berikut ini:

VENDOR Vendor_ID EMPLOYEE Emp_ID USER User_ID PURCHASE ORDER DO_No HISTORY History_ID ASSET Asset_No DELIVERY ORDER DO_No Has Uses Becomes Makes Consist of Sav e as 1..* 1..1 0..* 1..1 1..* 0..* 1..1 1..* 1..* 1..1 1..1 1..* 0..1 1..1 Has 1..1 1..* UNIT Unit_Code Leads 0..* 1..1 {Optional} UP_UNIT Is Approv ed be Requests 1..* 1..* PURCHASE REQUISITION PR_No Receiv es 1..* 1..1

Gambar 4.9 Perbaikan ER Diagram dengan penambahan konsep model

Enhaced

4.3.1.6 Validasi Model Konseptual Terhadap Transaksi Pengguna

Untuk memvalidasi model konseptual terhadap transaksi pengguna dapat digunakan transaction pathways. Gambar berikut merepresentasikan jalan (pathway) dari tiap transaksi secara langsung :

(21)

UNIT Unit_Code VENDOR Vendor_ID EMPLOYEE Emp_ID USER User_ID PURCHASE ORDER DO_No HISTORY History_ID ASSET Asset_No DELIVERY ORDER DO_No Leads Has Uses Becomes Makes receiv es Consist of Sav e as UP_UNIT {Optional} (a) (b) (c) (e) (d) (f) (g) (h) (i) (j ) Has Is Approv ed be Requests PURCHASE REQUISITION PR_No (k) (l)

Gambar 4.10 Penggunaan Pathways untuk mengecek model konseptual yang mendukung transaksi pengguna.

Berikut penjelasan transaksi dari ER Diagram diatas : (a). List semua unit yang dibawahi oleh UplevelUnit (b). List semua employee yang berada pada unit tertentu (c). Employee memesan Purchase Requisition

(d). Purchase Requisition disetujui menjadi Purchase Order (e). Purchase Order dikirimkan ke vendor

(f). Mengecek kesesuaian data pada Delivery Order dengan Purchase Order (g). Menerima Delivery Order yang dikirim Vendor

(h). Mendata aset yang sesuai dengan Delivery Order yang diterima (i). Employee menggunakan data aset

(22)

(j). List employee yang berstatus sebagai user (k). Menyimpan aset sebagai data history (l). Employee membuat Purchase Order

4.3.2 Perancangan Basisdata Logikal

Pada tahap ini dijelaskan langkah-langkah dalam membangun basisdata logical untuk model relational.

Langkah 2. Membangun dan memvalidasi data model logikal 4.3.2.1 Menurunkan (derive) relasi untuk model data logikal

Berikut ini dijelaskan bagaimana relasi diturunkan dari struktur yang ditampilkan dalam model data :

(1) Many-to-many (*:*) binary relationship types

Pada hubungan many-to-many dapat diuraikan dan diganti dengan dua

buah relasi dan satu buah entiti baru. • Hubungan antara Employee dan Asset

Employee (Emp_ID, Emp_Name, Sex, Place_of _Birth, Date_of _Birth, Address, Phone, Email, Unit_Code)

Primary Key Emp_ID Foreign Key Unit_Code ref erences Unit_Code(Unit)

Asset (Asset_No, Asset_Name, Desc, Brand, Ty pe, Item_Code, Item_Description, Serial_No, Vendor_ID, DO_No, Date_Of _Issued, Price, Currency , Time_Usage, Unit_Code, Status, Emp_ID)

Primary Key Asset_No

Foreign Key Vendor_ID ref erences Vendor_ID(Vendor) Foreign Key DO_No ref erences DO_No(DO) Foreign Key Unit_Code ref erences Unit_Code(Unit) Foreign Key Emp_ID ref erences Emp_ID(Employ ee)

Using (Emp_ID, Asset_No, DateComment, Comment) Primary Key Emp_ID, Asset_No

Foreign Key Emp_ID ref erences Emp_ID(Employ ee) Foreign Key Asset_No ref erences Asset_No(Asset)

Gambar 4.11 Hubungan many-to-many Employee terhadap Asset menghasilkan Entiti

(23)

• Hubungan antara Purchase Requisition dan Purchase Order

Purchase Order (PO_No, Date_Of _Issued, Vendor_ID, Vendor_Name, Ship_to, Ref .PPB/PPJ_No, Item_Code,

Item_Description, Quantity , Unit, Unit_Price, Total_Price, Note, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Primary Key PO_No

Foreign Key Vendor_ID ref erences Vendor_ID (Vendor) Foreign Key Emp_ID ref erences Emp_ID (Employ ee) Purchase Requisition (PR_No, Date_Of _Issued,

Item_Material_Code, Item_Description, Unit_Price, Quantity , Total, Item_Note, Grand_Total, Emp_ID) Primary Key PR_No

Foreign Key Emp_ID ref erences Employ ee (Emp_ID)

Approving (PR_No, PO_No, Date_Approv ed, Status) Primary Key PR_No, PO_No

Foreign Key PR_No ref erences PR_No (Purchase_Requisition_Header) Foreign Key PO_No ref erences PO_No (Purchase_Order_Header)

Gambar 4.12 Hubungan many-to-many Purchase Requisition terhadap Purchase Order menghasilkan Entiti Approving

(2) Multi-valued attributes

Pada entity yang didalamnya terdapat multi-valued attributes, kita dapat membuat satu entiti baru yang dihubungkan dengan relasi baru untuk merepresentasikan multi-value attributes. Berikut ini ditampilkan hasil identifikasi pada rancangan basisdata logikal :

• Atribut Phone pada entiti Employee

Em ployee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address, Email, Unit_Code)

Prim ary Key Emp_ID

Em p_Phone (Phone_No, Emp_ID) Prim ary Key Phone_No

Foreign Key Emp_ID references Emp_ID (Employee) Post Em p_ID into Em p_Phone

(24)

• Atribut Email pada entity Empoyee

Em ployee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address, Unit_Code)

Em p_Em ail (Email, Emp_ID) Prim ary Key Email

Foreign Key Emp_ID references Emp_ID (Employee) Post Em p_ID into Em p_Em ail

Gambar 4.14 Pemecahan entiti Employee dengan menambah entiti Emp_Email

• Atribut Phone_No pada entiti Vendor

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Email, Contact_Person, Contact_Person_Phone)

Prim ary Key Vendor_ID

Vendor_Phone (Phone_No, Vendor_ID) Prim ary Key Phone_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Post Vendor _ID into Vendor _Phone

Gambar 4.15 Pemecahan entiti Vendor dengan menambah entiti Vendor_Phone

• Atribut Email pada entiti Vendor

Post Vendor_ID into Vendor_Email

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person, Contact_Person_Phone) Primary Key Vendor_ID

Vendor_Email (Email, Vendor_ID) Primary Key Email

Foreign Key Vendor_ID ref erences Vendor_ID (Vendor)

Gambar 4.16 Pemecahan entiti Vendor dengan menambah entiti Vendor_Email

(3) one – to – one (1:1) binary relationship types

Pada hasil identifikasi pada rancangan basisdata logical dalam sistem terdapat tipe relasi one-to-one (1:1) yang menghasilkan relasi baru melalui salah satu participation constraint yaitu Mandatory participation on one side

of a 1:1 relationship yang artinya entiti yang mempunyai optional participation dalam relasi di desain sebagai parent entity dan entiti yang

(25)

mempunyai mandatory participation dalam relasi di desain sebagai child

entity. Berikut ini merupakan hasil identifikasinya :

• Hubungan antara entiti Asset (Parent) dan History (Child)

Asset (Asset_No, Asset_Name, Brand, Type, Item_Code,

Item_Description, Serial_No, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID )

Foreign Key DO_No references DO_No (Delivery Order) Foreign Key Unit_Code references Unit_Code (Unit) Foreign Key Emp_ID refernces Emp_ID (Employee)

History (History_ID, Asset_No, Asset_Name, Brand, type, Item_Code,

Item_Description, Serial_No, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID, Expired_Date, Expired_Description, Historical_Status)

Prim ary Key History_ID

Foreign Key Asset_No references Asset_ID (Asset) Foreign Key DO_No references DO_No (Delivery Order) Foreign Key Unit_Code references Unit_Code (Unit) Foreign Key Emp_ID refernces Emp_ID (Employee)

Untuk relasi 1:1 dengan Mandatory Participation pada sisi Asset , kirimkan Asset_ID pada History untuk model relasi Save as

Gambar 4.17 Hubungan one-to-one pada Entiti Asset dan History menggunakan

Mandatory participation on one side of a 1:1 relationship

(4) one – to – many (1:*) binary relationship types

Untuk setiap relasi binary 1:*, entiti pada “sisi one” pada relasi di desain sebagai entiti parent dan entity pada “sisi many’ di desain sebagai entiti child. Berikut ini ditampilkan hasil identifikasi pada rancangan basisdata logical :

• Hubungan antara entiti Vendor dengan Delivery Order

Vendor (Vendor_ID, Vendor_Name, Address, Phone_No, Fax, Email, Contact_Person, Contact_Person_Phone)

Prim ary Key Vendor_ID

Delivery Order (DO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref .PPB/PPJ_No, Ref.Contract_No, Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, PO_No, Emp_ID, Emp_Name) Prim ary Key DO_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Foreign Key PO_No ref erences PO_No (Purchase Order) Foreign Key Emp_ID ref erences Emp_ID (Employee) Post Vendor_ID kedalam Delivery Order untuk model 1:* relasi Makes

Gambar 4.18 Hubungan one-to-many (1:*) pada entiti Vendor (Parent) dan Delivery

(26)

• Hubungan antara entiti Vendor dengan Purchase Order

Vendor (Vendor_ID, Vendor_Name, Address, Phone_No, Fax,

Email, Contact_Person, Contact_Person_Phone)

Primary Key Vendor_ID

Post Vendor_ID kedalam Purchase Order untuk model 1:* relasi Is Receives

Purchase Order (PO_No, Date_Of _Issued, Vendor_ID, Vendor_Name,

Ship_to, Ref .PPB/PPJ_No, Item_Code, Item_Description, Quantity , Unit, Unit_Price, Total_Price, Note, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Foreign Key Vendor_ID ref erences Vendor_ID (Vendor) Foreign Key Emp_ID ref erences Emp_ID (Employ ee)

Gambar 4.19 Hubungan one-to-many (1:*) pada entiti Vendor (Parent) dan Purchase

Order (Child)

• Hubungan antara entiti Delivery Order dengan Asset

Asset (Asset_No, Asset_Name, Brand, Ty pe, DO_No, Date_Of _Issued,

Item_Code, Item_Description, Serial_No, Price, Currency , Time_Usage, Unit_Code, Status, Emp_ID )

Foreign Key DO_No ref erences DO_No (Deliv ery Order) Foreign Key Unit_Code ref erences Unit_Code (Unit) Foreign Key Emp_ID ref ernces Emp_ID (Employ ee)

Post DO_No kedalam Asset untuk model 1:* relasi Is Consist_Of

Delivery Order (DO_No, Date_Of _Issued, Vendor_ID, Vendor_Name,

Ship_to, Ref .PPB/PPJ_No, Ref .Contract_No, Item_Code, Item_Description, Quantity , Unit, Deliv ery _Schedule, Note, PO_No, Emp_ID, Emp_Name)

Primary Key DO_No

Foreign Key Vendor_ID ref erences Vendor_ID (Vendor) Foreign Key PO_No ref erences PO_No (Purchase Order) Foreign Key Emp_ID ref erences Emp_ID (Employ ee)

Gambar 4.20 Hubungan one-to-many (1:*) pada entiti Delivery Order (Parent) dan

Asset (Child)

• Hubungan antara entiti Unit dengan Employee

Unit (Unit_Code, Desc,UpUnit) Primary Key Unit_Code

Foreign Key UpUnit references Unit_Code (Up_Unit)

Em ployee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address,Phone, Email, Unit_Code) Prim ary Key Emp_ID

Foreign Key Unit_Code references Unit_Code (Unit)

Post Unit_Code kedalam Em ployee untuk model 1:* relasi Has

Gambar 4.21 Hubungan one-to-many (1:*) pada entiti Unit (Parent) dan Employee (Child)

(27)

• Hubungan antara entiti Employee dengan Purchase Order

Em ployee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address,Phone, Email, Unit_Code)

Purchase Order (PO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref.PPB/PPJ_No, Item_Code, Item_Description, Quantity, Unit, Unit_Price, Total_Price, Note, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Prim ary Key PO_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Foreign Key Emp_ID references Emp_ID (Employee) Post Em p_ID kedalam Purchase Order untuk model 1:* relasi Makes

Gambar 4.22 Hubungan one-to-many (1:*) pada entiti Employee (Parent) dan Purchase

Order (Child)

• Hubungan antara entiti Purchase Order dengan Delivery Order

Purchase Order (PO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref.PPB/PPJ_No, Item_Code, Item_Description, Quantity, Unit, Unit_Price, Total_Price, Note, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Prim ary Key PO_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Foreign Key Emp_ID references Emp_ID (Employee)

Delivery Order (DO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref.PPB/PPJ_No, Ref.Contract_No, Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, PO_No, Emp_ID, Emp_Name) Prim ary Key DO_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Foreign Key PO_No references PO_No (Purchase Order) Foreign Key Emp_ID references Emp_ID (Employee) Post PO_No kedalam Delivery Order untuk model 1:* relasi Has

Gambar 4.23 Hubungan one-to-many (1:*) pada entiti Purchase Order (Parent) dan

Delivery Order (Child)

• Hubungan antara entity Employee dengan Purchase Requisition

Employee (Emp_ID, Emp_Name, Sex, Place_Of _Birth,

Date_Of _Birth, Address,Phone, Email, Unit_Code)

Primary Key Emp_ID

Foreign Key Unit_Code ref erences Unit_Code (Unit)

Purchase Requisition (PR_No, Date_Of _Issued,

Item_Material_Code, Item_Description, Unit_Price, Quantity , Total, Item_Note, Grand_Total, Emp_ID)

Primary Key PR_No

Foreign Key Emp_ID ref erences Employ ee (Emp_ID)

Post Emp_ID kedalam Purchase Requisition untuk model 1:* relasi requests

Gambar 4.24 Hubungan one-to-many (1:*) pada entiti Employee (Parent) dan Purchase

(28)

• Hubungan antara entiti Employee dengan User

User (User_ID, User_Name, Password, Status, Last_Login, Emp_ID) Primary Key User_ID

Foreign Key Emp_ID

Foreign Key Emp_ID ref erences Employ ee (Emp_ID) Employee (Emp_ID, Emp_Name, Sex, Place_Of _Birth,

Date_Of _Birth, Address,Phone, Email, Unit_Code) Primary Key Emp_ID

Foreign Key Unit_Code ref erences Unit_Code (Unit)

Post Emp_ID kedalam User untuk model 1:* relasi becomes

Gambar 4.25 Hubungan one-to-many(1:*) pada Entiti Employee (Parent) dan User (Child)

(5) Strong entity types

Berikut ini merupakan Strong Entity pada rancangan basisdata logikal : Tabel 4.5 Strong Entity pada rancangan basisdata logikal

Unit (Unit_Code, Desc, UpUnit_Code) Primary Key Unit_Code

Foreign Key UpUnit_Code references Unit_Code (Unit)

Foreign Key Emp_ID references Emp_ID (Employee)

Employee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address, Unit_Code)

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person, Contact_Person_Phone)

Delivery Order (DO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref. PPB/PPJ_No, Ref. Contract_No, Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, PO_No, Emp_ID, Emp_Name)

(29)

Foreign Key PO_No references PO_No (Purchase_Order) Foreign Key Emp_ID references Emp_ID (Employee)

Purchase Order (PO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to,

Ref.PPB/PPJ_No, Item_Code, Item_Description, Quantity, Unit, Unit_Price, Total_Price, Note, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Purchase Requisition (PR_No, Date_Of_Issued, Item_Material_Code, Item_Description, Unit_Price, Quantity, Total, Item_Note, Grand_Total, Emp_ID)

Foreign Key Emp_ID references Employee (Emp_ID)

Asset (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Item_Code, Item_Description, Serial_No, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID )

Foreign Key DO_No references DO_No (Delivery_Order) Foreign Key Unit_Code references Unit_Code (Unit) Foreign Key Emp_ID refernces Emp_ID (Employee)

History (History_ID, Asset_No, Asset_Name, Brand, type, Item_Code, Item_Description, Serial_No, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID, Expired_Date, Expired_Description, Historical_Status) Primary Key History_ID

Foreign Key Asset_No references Asset_No (Asset) Foreign Key DO_No references DO_No (Delivery_Order) Foreign Key Unit_Code references Unit_Code (Unit) Foreign Key Emp_ID refernces Emp_ID (Employee)

(30)

(6) Weak entity types

Berikut ini merupakan weak entity pada rancangan basisdata logikal : Tabel 4.6 Weak Entity pada rancangan basisdata logikal

Emp_Phone (Phone_No, Emp_ID) Primary Key Phone_No

Foreign Key Emp_ID references Emp_ID (Employee) Emp_Email (Email, Emp_ID)

Primary Key Email

Foreign Key Emp_ID references Emp_ID (Empoyee) Vendor_Phone (Phone_No, Vendor_ID)

Primary Key Phone_No

Foreign Key Vendor_ID references Vendor_ID (Vendor) Vendor_Email (Email, Vendor_ID)

Foreign Key Vendor_ID references Vendor_ID (Vendor) Approving (PR_No, PO_No, Date_Approved, Status) Primary Key PR_No, PO_No

Foreign Key PR_No references PR_No(Purchase_Requisition_Header) Foreign Key PO_No references PO_No (Purchase_Order_Header) Using (Emp_ID, Asset_No, DateComment, Comment)

Primary Key Emp_ID, Asset_No

Foreign Key Emp_ID references Emp_ID(Employee) Foreign Key Asset_No references Asset_No(Asset)

(31)

4.3.2.2 Validasi Relasi dengan menggunakan Normalisasi Proses normalisasi meliputi langkah berikut ini :

• First Normal Form ( 1NF )

Pada bentuk normal pertama (First Normal Form – 1NF) ini, kita akan mengidentifikasi dan menghilangkan data berulang (repeating groups).

• Second Normal Form ( 2NF )

Pada bentuk normal kedua (Second Normal Form – 2NF) ini, kita akan menghilangkan partial dependency pada primary key.

• Third Normal Form ( 3NF )

Pada bentuk normal ketiga (Third Normal Form – 3NF) ini, kita akan menghilangkan transitive dependency pada primary key.

Berikut ini merupakan langkah-langkah normalisasi yang dilakukan : 1. Vendor

Unnormlized Form ( UNF ) : Tabel Vendor telah dalam UNF karena

mentransformasi data dari sumber informasi ke dalam tabel berbentuk baris dan kolom.

First Normal Form ( 1NF ) : Tabel Vendor telah dalam 1NF karena tidak

mengandung data berulang (repeating groups).

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person, Contact_Person_Phone)

(32)

Second Normal Form ( 2NF ) : Tabel Vendor telah dalam 2NF karena tidak

mengandung partial dependency.

V endor_ID V endor_Name A ddress Fax Contact_Person Contact_Person_Phone

f d1

f d2

(Primary Key)

(Transitive Dependency)

f d3 (Candidate Key)

fd1 Vendor_ID → Vendor_Name, Address, Fax, Contact_Person (Primary Key) fd2 Contact_Person → Contact_PersonPhone (Transitive Dependency) fd3 Vendor_ID, Contact_Person → Vendor_Name, Address, Fax

(Candidate Key) Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person, Contact_Person_Phone)

Third Normal Form ( 3NF ) :

Relasi baru yang terbentuk :

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person) Contact_Person (Contact_Person, Contact_Person_Phone)

2. Delivery Order

Unnormlized Form ( UNF ) : Tabel Delivery Order telah dalam UNF karena

(33)

First Normal Form ( 1NF ) : Kita hilangkan data berulang (repeating groups)

dengan memasukkan data Delivery Order yang sesuai kedalam tiap baris.

Delivery_Order (DO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref. PPB/PPJ_No, Ref. Contract_No, {Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note}, PO_No, Emp_ID, Emp_Name)

Hasil 1NF :

Delivery_Order_Header (DO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref. PPB/PPJ_No, Ref. Contract_No, PO_No, Emp_ID, Emp_Name)

Delivery_Order_Detail (Item_Code, Item_Description, Quantity, Unit,

Delivery_Schedule, Note, DO_No)

Second Normal Form ( 2NF ) : Tabel Delivery_Order_Header dan

Delivery_Order_Detail telah dalam 2NF karena tidak mengandung partial

dependency.

DO_No Date_Of _Issued Vendor_ID Vendor_Name Ship_to Ref . PPB/PPJ_No Ref . Contract_No

Item_Code Item_Description Quantity Unit Deliv ery _Schedule Note

PO_No Emp_ID Emp_Name

(Primary Key ) f d1 f d2 (Transitiv e Dependency ) DO_No f d3 (Transitiv e Dependency ) (Primary Key ) f d4

fd1 DO_No → Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Ref.Contract_No, PO_No, Emp_ID (Primary Key)

(34)

fd2 Vendor_ID → Vendor_Name (Transitive Dependency) fd3 Emp_ID → Emp_Name (Transitive Dependency)

fd4 Item_Code → Item_Description, Quantity, Unit, Delivery_Schedule, Note, DO_No (Primary Key)

Delivery_Order_Header :

fd1 DO_No → Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Ref.Contract_No, PO_No, Emp_ID (Primary Key)

fd2 Vendor_ID → Vendor_Name (Transitive Dependency) fd3 Emp_ID → Emp_Name (Transitive Dependency)

Delivery_Order_Detail :

fd4 Item_Code → Item_Description, Quantity, Unit, Delivery_Schedule, Note, DO_No (Primary Key)

Delivery_Order_Header (DO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Ref.Contract_No, PO_No, Emp_ID)

Delivery_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, DO_No)

Vendor (Vendor_ID, Vendor_Name) Employee (Emp_ID, Emp_Name)

(35)

3. Purchase Order

Unnormlized Form ( UNF ) : Tabel Purchase Order telah dalam UNF karena

dengan memasukkan data Purchase Order yang sesuai ke dalam tiap baris.

Purchase Order (PO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref.PPB/PPJ_No, {Item_Code, Item_Description, Quantity, Unit, Unit_Price, Total_Price, Note}, Total, Disc, Nett, PPN/VAT_10%, Emp_ID, Emp_Name)

Hasil 1NF :

Purchase_Order_Header (PO_No, Date_Of_Issued, Vendor_ID, Vendor_Name, Ship_to, Ref. PPB/PPJ_No, Emp_ID, Emp_Name)

Purchase_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Unit_Price, Note, PO_No)

Second Normal Form ( 2NF ) : Tabel Purchase_Order_Header dan

Purchase_Order_Detail telah dalam 2NF karena tidak mengandung partial

(36)

PO_No Date_Of _Issued Vendor_ID Vendor_Name Ship_to Ref . PPB/PPJ_No

Item_Code Item_Description Quantity Unit Unit_Price Note

Emp_ID Emp_Name (Primary Key ) f d1 f d2 (Transitiv e Dependency ) PO_No f d3 (Transitiv e Dependency ) (Primary Key ) f d4

fd1 PO_No → Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Emp_ID (Primary Key)

fd2 Vendor_ID → Vendor_Name (Transitive Dependency) fd3 Emp_ID → Emp_Name (Transitive Dependency)

fd4 Item_Code → Item_Description, Quantity, Unit, Unit_Price, Note, PO_No (Primary Key)

Purchase_Order_Header :

fd1 PO_No → Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No,

Emp_ID (Primary Key)

fd2 Vendor_ID → Vendor_Name (Transitive Dependency) fd3 Emp_ID → Emp_Name (Transitive Dependency)

Purchase_Order_Detail :

fd4 Item_Code → Item_Description, Quantity, Unit, Unit_Price, Note, PO_No (Primary Key)

(37)

Purchase_Order_Header (PO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Emp_ID)

Purchase_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Unit_Price, Note, PO_No)

Vendor (Vendor_ID, Vendor_Name) Employee (Emp_ID, Emp_Name)

4. Purchase Requisition

Unnormlized Form ( UNF ) : Tabel Purchase Requisition telah dalam UNF

karena mentransformasi data dari sumber informasi ke dalam tabel berbentuk baris dan kolom.

dengan memasukkan data Purchase Requisition yang sesuai ke dalam tiap baris. Purchase_Requisition (PR_No, Date_Of_Issued, {Item_Material_Code, Item_Description, Unit_Price, Quantity, Total, Item_Note}, Grand_Total, Emp_ID)

Hasil 1NF :

Purchase_Requisition_Header (PR_No, Date_Of_Issued, Emp_ID)

Purchase_Requisition_Detail (Item_Material_Code, Item_Description, Unit_Price, Quantity, Item_Note, PR_No)

(38)

Second Normal Form ( 2NF ) : Tabel Purchase Requisition telah dalam 2NF

karena tidak mengandung partial dependency.

PR_No Date_Of _Issued

Item_Material_Code Item_Description Unit_Price Quantity Item_Note Emp_ID (Primary Key ) f d1 PR_No (Primary Key ) f d2

fd1 PR_No → Date_Of_Issued, Emp_ID (Primary Key) fd2 Item_Material_Code → Item_Description, Unit_Price, Quantity, Item_Note, PR_No (Primary Key)

Third Normal Form ( 3NF ) : Tabel Purchase Requisition telah dalam 3NF

(39)

5. Asset

Unnormlized Form ( UNF ) : Tabel Asset telah dalam UNF karena

dengan memasukkan data Asset yang sesuai ke dalam tiap baris.

Asset (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, {Item_Code, Item_Description, Serial_No}, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID )

Hasil 1NF :

Asset_Header (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID)

Asset_Detail (Item_Code, Item_Description, Serial_No, Asset_No)

Second Normal Form ( 2NF ) : Tabel Asset_Header dan Asset_Detail telah

dalam 2NF karena tidak mengandung partial dependency.

Asset_No Asset_Name Brand Ty pe DO_No Date_Of_{_Issued} Price

Item_Code Item_Description Serial_No

Currency Time_Usage Unit_Code

(Primary Key ) f d1 (Primary Key ) f d2 Emp_ID Status Asset_No

(40)

fd1 Asset_No → Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID (Primary Key) fd2 Item_Code → Item_Description, Serial_No, Asset_No (Primary Key)

Third Normal Form ( 3NF ) : Tabel Asset_Header dan Asset_Detail telah dalam

3NF karena tidak mengandung transitive dependency.

6. History

Unnormlized Form ( UNF ) : Tabel History telah dalam UNF karena

dengan memasukkan data History yang sesuai ke dalam tiap baris.

History (History_ID, Asset_No, Asset_Name, Brand, Type, {Item_Code, Item_Description, Serial_No}, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID, Expired_Date, Expired_Description, Historical_Status)

Hasil 1NF :

History_Header (History_ID, Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID, Expired_Date, Expired_Description, Historical_Status)

(41)

History_Detail (Item_Code, Item_Description, Serial_No, History_ID)

Second Normal Form ( 2NF ) : Tabel History_Header dan History_Detail telah

dalam 2NF karena tidak mengandung partial dependency.

Asset_No Asset_Name Brand Ty pe DO_No Date_Of _Issued Price

Item_Code Item_Description Serial_No

Currency Time_Usage Unit_Code

(Primary Key ) f d1 (Primary Key ) f d3 Emp_ID Status

History _ID Expired

_Date Expired_De scription Historical_ Status History _ID ( Transitiv e Dependency ) f d2

fd1 History_ID → Asset_No, Expired_Date, Expired_Description, Historical_Status (Primary Key)

fd2 Asset_No → Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID (Transitive Dependency) fd3 Item_Code → Item_Description, Serial_No, History_ID (Primary Key)

History_Header

fd1 History_ID → Asset_No, Expired_Date, Expired_Description, Historical_Status (Primary Key)

fd2 Asset_No → Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID (Transitive Dependency) History_Detail

(42)

History_Header (History_ID, Expired_Date, Expired_Description, Historical_Status, Asset_No)

History_Detail (Item_Code, Item_Description, Serial_No, History_ID)

Asset_Header (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID)

4.3.2.3 Validasi dengan Transaksi Pengguna

Berikut ini adalah hasil normalisasi yang digambarkan menggunakan

pathway yang ditujukan untuk meyakinkan bahwa relasi dalam logikal data

model mendukung transaksi yang dibutuhkan oleh pengguna.

UNIT Unit_Code VENDOR Vendor_ID EMPLOYEE Emp_ID USER User_ID PURCHASE_ ORDER_ HEADER PO_No Leads Has Becomes Makes receiv es Consist of Sav e as UP_UNIT {Optional, AND} (a) (b) (c) (e) (d) (f) _(g) (h) (j ) Has Is made by Requests PURCHASE_ REQUISITION_ HEADER PR_No (k) (i) PURCHASE_ REQUISITION_ DETAIL Item_Material _Code PURCHASE_ ORDER_ DETAIL Item_Code DELIVERY_ ORDER_ HEADER DO_No DELIVERY_ ORDER_ DETAIL Item_Code ASSET_ DETAIL Item_Code ASSET_ HEADER Asset_No HISTORY_ DETAIL Item_Code HISTORY_ HEADER History_ID APPROVING PR_No PO_No USING Emp_ID Asset_No Approv es Takes Has Has Has Has Has EMP_PHONE Phone_No EMP_EMAIL Email VENDOR_PHONE Phone_No VENDOR_EMAIL Email Has Has Has Has Has Makes (l) (m) (n) (q) (r) (s) (t) (u) (v) (w ) (x) CONTACT PERSON Contact_Person (o) (p) Has

Gambar 4.26 Diagram ER Model setelah dinormalisasi dengan menggunakan

(43)

Berikut penjelasan transaksi dari ER Diagram diatas : a. Mendata semua unit yang dibawahi oleh UpUnit

b. Mendata semua employee yang berada pada unit tertentu c. Mendata email milik employee

d. Mendata No. Telp milik employee

e. Mendata employee yang berstatus sebagai user f. Employee memesan Purchase Requisition

g. Purchase Requisition disetujui menjadi Purchase Order

h. Membuat Purchase order sesuai dengan purchase requisition melalui proses Approving

i. Employee membuat purchase order

j. Mendata Employee yang menggunakan aset

k. Mendata aset yang digunakan oleh employee tertentu

l. Mendata Purchase requisition detail sesuai dengan purchase requisition header

m. Mendata Purchase order detail sesuai dengan purchase order header n. Mendata email milik vendor

o. Mendata No. Telp milik vendor

p. Mendata nama orang yang bisa dihubungi dari pihak vendor (Contact Person) q. Vendor menerima purchase order

r. Mendata Delivery order sesuai dengan purchase order s. Vendor membuat delivery order

t. Mendata aset sesuai dengan delivery order

(44)

v. Mendata aset detail sesuai dengan aset header w. Aset disimpan menjadi data history aset

x. Mendata history aset detail sesuai dengan history aset header

4.3.2.4 Memeriksa Kendala – Kendala Integritas (Integrity Constraints) Langkah ini bertujuan untuk mencegah basisdata dari ketidak-konsistenan. Kendala integritas dibagi enam bentuk dasar, yaitu :

1. Required data, beberapa atribut harus selalu mengandung nilai yang valid, dengan kata lain atribut tidak boleh mengandung nilai null. Kendala integritas ini telah dilakukan pada saat dokumentasi atribut.

2. Attribute domain constraint, setiap atribut mempunyai domain sendriri, yaitu sekumpulan nilai yang sah untuk setiap atribut. Kendala integritas ini telah dilakukan pada saat penentuan nilai yang akan dimasukkan dari tipe dan panjang dari suatu atribut.

3. Multiplicity, Kendala integritas ini menampilkan batasan yang ditempatkan pada hubungan antar data dalam database. Kendala integritas ini telah dilakukan pada saat dokumentasi atribut.

4. Entity integrity, suatu primary key dari sebuah entity tidak boleh mengandung nilai null. Setiap tuple harus memiliki suatu primary key. Kendala integritas ini telah dilakukan pada saat memilih primary key untuk setiap entiti.

5. Referential integrity, sebuah foreign key menghubungkan setiap tuple didalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai candidate

(45)

6. General constraint, merubah (meng-update) entiti dapat dikendalikan oleh kendala seperti dalam transaksi “real world”.

Adapun referential integrity constraint dapat dilihat pada tabel sebagai berikut : Tabel 4.7 Tabel referential integrity constraint

Unit (Unit_Code, Desc, UpUnit_Code) Primary Key Unit_Code

Foreign Key UpUnit_Code references Unit_Code (UpUnit)

ON UPDATE CASCADE ON DELETE SET NULL UpUnit (Unit_Code, Desc)

Primary Key Unit_Code

ON UPDATE CASCADE ON DELETE CASCADE Employee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address, Unit_Code)

ON UPDATE CASCADE ON DELETE CASCADE Emp_Phone (Phone_No, Emp_ID)

ON UPDATE CASCADE ON DELETE CASCADE Emp_Email (Email, Emp_ID)

Foreign Key Emp_ID references Emp_ID (Empoyee)

ON UPDATE CASCADE ON DELETE CASCADE Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person)

(46)

Foreign Key Contact_Person references Contact_Person (Contact_Person)

ON UPDATE CASCADE ON DELETE CASCADE Vendor_Phone (Phone_No, Vendor_ID)

Foreign Key Vendor_ID references Vendor_ID (Vendor)

ON UPDATE CASCADE ON DELETE CASCADE Vendor_Email (Email, Vendor_ID)

ON UPDATE CASCADE ON DELETE CASCADE Contact_Person (Contact_Person, Contact_Person_Phone)

Primary Key Contact_person

Delivery_Order_Header (DO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref. PPB/PPJ_No, Ref. Contract_No, PO_No, Emp_ID)

ON UPDATE CASCADE ON DELETE NO CHECK Foreign Key PO_No references PO_No (Purchase_Order_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key Emp_ID references Emp_ID (Employee)

ON UPDATE CASCADE ON DELETE NO CHECK Delivery_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, DO_No)

Primary Key Item_Code

Foreign Key DO_No references DO_No (Delivery_Order_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Purchase_Order_Header (PO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Emp_ID)

(47)

ON UPDATE CASCADE ON DELETE NO CHECK Foreign Key Emp_ID references Emp_ID (Employee)

ON UPDATE CASCADE ON DELETE NO CHECK Purchase_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Unit_Price, Total_Price, Note, PO_No)

Foreign Key PO_No references PO_No (Purchase_Order_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Purchase_Requisition_Header (PR_No, Date_Of_Issued, Emp_ID)

Foreign Key Emp_ID references Employee (Emp_ID)

ON UPDATE CASCADE ON DELETE NO CHECK Purchase_Requisition_Detail (Item_Material_Code, Item_Description, Unit_Price, Quantity, Item_Note, PR_No)

Primary Key Item_Material_Code

Foreign Key PR_No references Purchase_Requisition_Header (PR_No)

ON UPDATE CASCADE ON DELETE NO ACTION Asset_Header (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID )

ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key Unit_Code references Unit_Code (Unit)

ON UPDATE CASCADE ON DELETE NO CHECK Foreign Key Emp_ID refernces Emp_ID (Employee)

ON UPDATE CASCADE ON DELETE NO CHECK Asset_Detail (Item_Code, Item_Description, Serial_No, Asset_No)

Foreign Key Asset_No references Asset_No (Asset_Header)

ON UPDATE CASCADE ON DELETE NO ACTION History_Header (History_ID, Expired_Date, Expired_Description, Historical_Status,

(48)

Asset_No)

Primary Key History_ID

ON UPDATE CASCADE ON DELETE NO ACTION History_Detail (Item_Code, Item_Description, Serial_No, History_ID)

Foreign Key History_ID references History_ID (History_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Approving (PR_No, PO_No, Date_Approved, Status)

Primary Key PR_No, PO_No

Foreign Key PR_No references PR_No(Purchase_Requisition_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Foreign Key PO_No references PO_No (Purchase_Order_Header)

ON UPDATE CASCADE ON DELETE NO ACTION Using (Emp_ID, Asset_No, DateComment, Comment)

Foreign Key Emp_ID references Emp_ID(Employee)

ON UPDATE CASCADE ON DELETE NO CHECK Foreign Key Asset_No references Asset_No(Asset_Header)

ON UPDATE CASCADE ON DELETE NO ACTION

Dan dengan General Constraint sebagai berikut :

CONSTRAINT EmployeeNotRequestPRTooMuch CHECK ( NOT EXIST ( SELECT Emp_ID

FROM Purchase_Requisition_Header GROUP BY Emp_ID

HAVING COUNT(*) > 10 ) )

(49)

Adapun General Constraint di atas dimaksudkan untuk membatasi jumlah pengajuan aset oleh employee.

4.3.2.5 Validasi Model Data Logikal dengan Model Global

Langkah ini bertujuan untuk penggabungan model data logikal individual ke dalam model data logikal global. Secara keseluruhan relasi model data logikal global dapat dilihat pada tabel berikut :

Table 4.8 Relasi yang merepresentasikan model data logikal global Unit (Unit_Code, Desc, UpUnit_Code)

Foreign Key UpUnit_Code references Unit_Code (Unit) UpUnit (Unit_Code, Desc)

Employee (Emp_ID, Emp_Name, Sex, Place_Of_Birth, Date_Of_Birth, Address, Unit_Code)

Foreign Key Unit_Code references Unit_Code (Unit) Emp_Phone (Phone_No, Emp_ID)

Foreign Key Emp_ID references Emp_ID (Employee) Emp_Email (Email, Emp_ID)

Foreign Key Emp_ID references Emp_ID (Empoyee)

Vendor (Vendor_ID, Vendor_Name, Address, Fax, Contact_Person) Primary Key Vendor_ID

(50)

Foreign Key Contact_Person references Contact_Person (Contact_Person) Vendor_Phone (Phone_No, Vendor_ID)

Foreign Key Vendor_ID references Vendor_ID (Vendor) Vendor_Email (Email, Vendor_ID)

Foreign Key Vendor_ID references Vendor_ID (Vendor) Contact_Person (Contact_Person, Contact_Person_Phone) Primary Key Contact_person

Delivery_Order_Header (DO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref.

PPB/PPJ_No, Ref. Contract_No, PO_No, Emp_ID) Primary Key DO_No

Foreign Key PO_No references PO_No (Purchase_Order_Header) Foreign Key Emp_ID references Emp_ID (Employee)

Delivery_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Delivery_Schedule, Note, DO_No)

Purchase_Order_Header (PO_No, Date_Of_Issued, Vendor_ID, Ship_to, Ref.PPB/PPJ_No, Emp_ID)

Purchase_Order_Detail (Item_Code, Item_Description, Quantity, Unit, Unit_Price, Note, PO_No)

Foreign Key PO_No references PO_No (Purchase_Order_Header) Purchase_Requisition_Header (PR_No, Date_Of_Issued, Emp_ID) Primary Key PR_No

(51)

Purchase_Requisition_Detail (Item_Material_Code, Item_Description, Unit_Price, Quantity, Item_Note, PR_No)

Primary Key Item_Material_Code

Foreign Key PR_No references Purchase_Requisition_Header (PR_No)

Asset_Header (Asset_No, Asset_Name, Brand, Type, DO_No, Date_Of_Issued, Price, Currency, Time_Usage, Unit_Code, Status, Emp_ID )

Foreign Key DO_No references DO_No (Delivery_Order_Header) Foreign Key Unit_Code references Unit_Code (Unit)

Foreign Key Emp_ID refernces Emp_ID (Employee)

Asset_Detail (Item_Code, Item_Description, Serial_No, Asset_No) Primary Key Item_Code

History_Header (History_ID, Expired_Date, Expired_Description, Historical_Status, Asset_No)

Primary Key History_ID

History_Detail (Item_Code, Item_Description, Serial_No, History_ID) Primary Key Item_Code

Foreign Key History_ID references History_ID (History_Header) Approving (PR_No, PO_No, Date_Approved, Status)

Primary Key PR_No, PO_No

Foreign Key PR_No references PR_No(Purchase_Requisition_header) Foreign Key PO_No references PO_No (Purchase_Order_header) Using (Emp_ID, Asset_No, DateComment, Comment)

Foreign Key Emp_ID references Emp_ID(Employee) Foreign Key Asset_No references Asset_No(Asset_Header)

(52)

4.3.2.6 Diagram ER untuk menggambarkan Relasi Global

Diagram ER pada langkah ini digunakan untuk menggambarkan model data logikal global yang diperoleh pada langkah sebelumnya. Adapun diagram ER yang digambarkan dengan menyatakan semua entiti secara keseluruhan beserta atribut key-nya (primary key dan foreign key). Jelasnya ER relasi global dapat dilihat pada gambar sebagai berikut :

(53)

4.3.3 Perancangan Basisdata Fisikal

Tahapan ini merupakan proses untuk menghasilkan sebuah deskripsi dari implementasi basisdata pada media penyimpanan kedua, dimana mendeskripsikan base relation, organisasi file, dan pengindekan yang digunakan untuk mendukung efisiensi dari akses data, dan integrity constraint beserta

security measures. Adapun secara jelasnya langkah – langkah yang dilakukan

dalam tahapan ini dapat dilihat sebagai berikut : 4.3.3.1 Merancang Relasi Dasar ( Base Relation )

Langkah ini bertujuan untuk memutuskan bagaimana merepresentasikan

base relation yang diidentifikasikan pada model data logikal global ke dalam

sasaran DBMS. Adapun hasil dari pada langkah ini adalah sebagai berikut : • Unit

Domain Unit_Code : variable length character string, length 5 Domain Desc : variable length character string, length 50 Domain UpUnit_Code : variable length character string, length 5 Unit (

Unit_Code NOT NULL,

Desc NOT NULL,

UpUnit_Code,

Primary Key (Unit_Code);

Foreign Key UpUnit references Unit_Code (Unit)

ON UPDATE CASCADE ON DELETE SET NULL )

• UpUnit

Domain Unit_Code : variable length character string, length 5 Domain Desc : variable length character string, length 50