BAB 2 LANDASAN TEORI
2.1. Teori-Teori Umum 2.1.1. Data Mcleod dan Schell (2007, p9). Data adalah kumpulan-kumpulan fakta dan gambaran yang secara umum tidak digunakan karena ukuran yang besar dan belum diolah. Connolly dan Begg (2010, p20). Data adalah komponen yang paling penting dalam DBMS, berasal dari sudut pandang end-user. Data bertindak sebagai jembatan yang menghubungkan antara mesin dan pengguna. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan data adalah sekumpulan fakta dalam ukuran yang besar dan belum diolah yang berfungsi sebagai jembatan penghubung antara mesin dan manusia.
2.1.2. Sistem Obrien (2005, p22). Sistem adalah sekelompok elemen yang saling berhubungan atau berinteraksi hingga membentuk suatu kesatuan. Sistem memiliki tiga komponen atau fungsi dasar yang berinteraksi: •
Input, meliputi pengambilan dan perakitan elemen yang memiliki sistem untuk diproses.
•
Processing, meliputi proses transformasi yang mengubah dari input dan output.
•
Output, meliputi pengiriman elemen yang dihasilkan dari proses transformasi ke tujuan utama. Hanif Al Fatta (2007, p3). Sistem adalah kumpulan dari bagian-bagian
yang bekerjasama untuk mencapai tujuan yang sama serta objek-objek yang saling berelasi dan berinteraksi antara hubungan objek yang dapat dilihat sebagai kesatuan yang dirancang untuk mencapai tujuan. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan sistem adalah kumpulan elemen-elemen yang memiliki objek-objek yang saling berelasi yang terdapat input, processing dan output yang dirancang untuk mencapai tujuan. 7
8 2.1.3. Informasi Obrien (2005, p38). Informasi adalah data yang telah diubah menjadi konteks yang berarti dan berguna bagai pemakai. Rainer,Turban dan Potter (2007, p5). Informasi adalah data yang telah diorganisir sehingga memiliki makna dan nilai kepada penggunanya. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan informasi adalah data yang diorganisir menjadi konteks dan berguna bagi pengguna.
2.1.4. Sistem Informasi Obrien (2005, p5). Sistem informasi adalah kombinasi teratur apapun dari orang-orang, hardware, software, jaringan komunikasi dan sumber daya data yang mengumpulkan, mengubah dan menyebarkan sistem informasi dalam suatu organisasi. Satzinger (2010, p6-7). Sistem informasi adalah kumpulan komponenkomponen yang saling berkaitan yang mengumpulkan, memproses, menyimpan dan menyediakan sebagai keluaran informasi yang dibutuhkan untuk dapat menyelesaikan tugas-tugas bisnis. Berdasarkan definsi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan sistem informasi adalah kumpulan komponen-komponen yang memproses, menyimpan dan menyediakan informasi untuk menyelesaikan tugastugas dalam suatu organisasi dan bisnis.
2.1.5. The-Three Level ANSI-SPARC Architecture Menurut Connolly dan Begg (2005 : 34) bagian dari three-level architecture terdiri dari external, conceptual dan internal level. Cara user melihat suatu data disebut bagian external, cara DBMS dan sistem melihat suatu data disebut sebagai internal level, dimana data disimpan menggunakan sebuah struktur data dan file organization. Conceptual level ini menjelaskan data apa saja yang disimpan didalam database dan bagaimana hubungan antar datanya.
9
Gambar 2.1 Arsitektur Three Level ANSI-SPARC
Tujuan utama dari three-level architecture ini sebenarnya adalah untuk memisahkan setiap hak akses user terhadap database dari keadaan database yang sebenarnya. Ada beberapa alasan yang mendasari hal tersebut : 1.
Setiap user harus bisa mengakses setiap data yang ada, tetapi akan berbeda sudutpandangnya mengenai suatu data. Dan setiap user pun bisa mengubah sudut pandangnyamengenai data, tetapi hal ini tidak akan berpengaruh terhadap user lainnya.
2. Setiap user tidak bisa langsung mengubah detail data pada database. Dengan kata lain interaksi user harus bersifat independent dari database. 3.
Database administrator harus bisa mengubah struktur database tanpa harus merubah user’s view.
4.
DBA seharusnya bisa merubah struktur konseptual dari database tanpa mempengaruhi semua user.
5.
Internal struktur dari database seharusnya tidak berpengaruh terhadap berubahnya alat penyimpanan.
10 2.1.6. Database Life Cycle Menurut Connolly dan Begg (2010, p314). Database Life Cycle merupakan suatu metodologi perancangan database yang digunakan dalam penulisan metodologi tahapan database application life cycle dapat dilihat dari gambar dibawah ini : Database Planning Database
planning
merupakan
tahapan
lanjutan
dari
perancangan database design. Database planning ialah suatu tahapan-tahapan yang dirancang dari suatu database yang dapat direalisasikan seefisien dan seefektif. ada 3 (tiga) hal utama yang dapat digunakan dalam merancang sistem informasi yaitu: 1. Mengidentifikasikan rencana dan menetapkan sasaran (goal) sesuai dengan kebutuhan sistem informasi 2. Mengevaluasi sistem informasi yang berjalan sekarang untuk mengetahui kelebihan dan kekurangan. 3. Mempertimbangkan kebutuhan IT yang dapat meningkatkan keuntungan kompetitif. Definisi Sistem Mendiskripsikan ruang lingkup batasan dari ruang lingkup dan batasan dari
aplikasi databse dan
user
view. User view
mendefinisikan apa yang dibutuhkan dalam aplikasi database yang berhubungan dengan data dan menampilkan transaksi dalam data. Requirement Collection and Analysis Proses pengumpulan dan analisis dari informasi tentang organisasi, yang akan dibantu dengan aplikasi database, dan informasi tersebut digunakan mengidentifikasi kebutuhan pengguna atau user mengenai sistem yang baru.
11 Database Design Proses perancangan pada database yang membantu operasional perusahaan dan target tujuaanya. Terdapat 3 tahapan, conceptual, logical, dan physical. •
Conceptual Dalam conceptual design membuat model data secara conceptual dari perusahaan yang bersangkutan. Datadata tersebut merupakan informasi-informasi mengenai perusahaan. Data yang dikembangkan dengan representasi secara conceptual
yang
mencakup
identifikasi
entity,
relationship, dan atribut yang sangat penting dalam perancangan basis data. •
Logical Dalam
logical
design,
data
diperoleh
dalam
conceptual design maka diubah dalam bentuk logical design, data yang ada akan akan dipengaruhi oleh model data yang menjadi tujuan basis data (database). Dilakukan
untuk
menerjemahkan
representasi
conceptual ke dalam bentuk struktur logic dalam database. Logical data model merupakan sumber informasi dalam merancang physical database. •
Physical Dalam physical design dilakukan untuk struktur logic secara fisik diimplemetasikan ke dalam tujuan database management system (DBMS), para perancang harus membuat keputusan mengenai basis data (database) dapat diimplementasikan dalam perusahaan. Oleh karena itu, physical database design harus disesuaikan
dengan
database
management
system
(DBMS). Terhadap hubungan antara physical database
12 design untuk meningkatkan kinerja basis data akan dapat mempengaruhi logical database. Pemilihan DBMS Pemilihan DBMS dilakukan untuk memilih sebuah DBMS yang tepat untuk mendukung aplikasi database. Desain Aplikasi Proses merancang user interface dan progam aplikasi yang menggunakan dan memproses database. Prototyping Proses pembuatan model kerja sementara untuk aplikasi database. Umumnya sebuah prototype merupakan sebuah model kerja yang tidak memiliki semua fitur atau memberikan semua fungsi dari sistem. Implementasi Realisasi fisik dari database dan desain aplikasi. Implementasi database dapat dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih. Data Conversion and Loading Pemindahan beberapa data yang sudah ada ke dalam database baru dan mengubah aplikasi yang sudah ke dalam database baru dan mengubah aplikasi yang sudah ada untuk dapat dijalankan pada database yang baru.
13 Testing Proses untuk menjalankan progam aplikasi dengan maksud menemukan dan mencari kesalahan-kesalahan. Sebelum digunakan, aplikasi database yang baru seharusnya melalui tahap uji coba.
Gambar 2.2 Database Life Cycle
2.1.7. Database Management System (DBMS) Connolly dan Begg (2010, p16). Database Management System (DBMS) adalah sistem perangkat lunak yang dapat memungkinkan pengguna untuk pendefinisian, membuat, memelihara dan mengawasi akses ke dalam database.
14 2.1.8. Basis Data Connolly dan Begg (2010, p65). Basis data adalah suatu kumpulan logika data yang berhubungan dan deskripsi dari data tersebut yang dirancang untuk kebutuhan informasi dan organisasi. Whitten dan Bentley (2007, p548). Basis data adalah kumpulankumpulan file yang saling terkait. Basis data tidak hanya merupakan kumpulan file tetapi setiap record pada setiap file harus memperbolehkan hubungan-hubungan untuk dapat menyimpan file lain. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan basis data adalah sekumpulan file-file yang terkait dan dirancang untuk menghasilkan record yang terkait dibutuhkan dalam rancangan informasi dan organisasi.
2.1.9. Database Immon (2005, p493). Database adalah sekumpulan data yang saling berhubungan yang disimpan berdasarkan skema. Sebuah database dapat melanyani single atau multiple applications. Chendramata (2009, p106). Database adalah sebuah rancang yang dapat diperuntukan sebagai media untuk menyimpan data transaksi yang dapat dihasilkan pada sebuah proses bisnis. Database minimal terdiri dari file yang cukup untuk untuk dimanipulasi oleh komputer sedemikan rupa. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan database adalah sebuah perangkat lunak yang dirancang sebagai media yang digunakan untuk menyimpan data yang terdiri dari satu atau lebih tabel yang saling berelasi.
2.1.10.
Analisis Sistem Satzinger (2010, p4). Analisis sistem adalah proses pemahaman dan penentuan yang secara rinci apa saja yang harus dicapai oleh sistem informasi. Obrien (2005, p29). Analisis sistem adalah sekelompok komponenkomponen yang saling berhubungan dan saling bekerja untuk mencapai suatu tujuan dengan cara menerima input dan output dalam proses perubahan dalam organisasi.
15 Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan analisis sistem adalah suatu pemahan da penentuan yang dilakukan secara rinci dengan cara menerima input dan output dalam proses perubahan organisasi. 2.1.11. Perancangan Sistem Satzinger (2010, p4). Perancangan sistem adalah proses penentuan secara rinci bagaimana banyak komponen dari sistem informasi harus diimplementasi secara fisik. Tahapan-tahapan perancangan sistem merupakan teknis yang dapat menspesifikan hal-hal berikut: •
Output, input dan antar muka pengguna sistem.
•
Hardware, software, basis data, telekomunikasi, personil dan prosedur.
•
Bagaimana komponen-komponen ini terintegrasi.
2.1.12 Analisis dan Perancangan Sistem 2.1.12.1 Konsep Model ERD • Relationship Connolly (2010,p374), Relationship adalah kumpulan yang keterhubungan yang mempunyai arti (meaningful associations) antara tipe entitas yang ada.
Gambar 2. 3 Relationship Branch has Staff
16 • Structural Constraints Batasan utama pada relationship disebut multiplicity, yaitu jumlah (atau range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relationship. Relationship yang paling umum adalah binary relationship. Macammacam binary relationship yaitu : One –to – one (1..1)
Gambar 2.4 ER Diagram of Staff and Branch Entities and general constraint (Connolly, Database Systems, p382) One –To-Many (1..*)
Gambar 2.5 ER Diagram of Staff and PropertyForRent Entities and general constraint (Connolly, Database Systems, p388)
17 Attributes Menurut
Connolly
(2010,
p379).
Attributes
merupakan sifat-sifat (property) dari sebuah entitas atau tipe relationship. Attribute Domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Macam-macam atribut : • Simple Attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama Atomic Attribute. • Composite Attribute, yaitu atribut yang terdiri dari beberapa komponen, dimana masingmasing komponen memiliki keberadaan yang independen. Misalkan atribut Address dapat terdiri dari Street, City, Post Code. • Single-valued Attribute, yaitu atribut yang mempunyai
nilai
tunggal
untuk
setiap
kejadian. Misalnya entitas Branch memiliki satu nilai untuk atribut branchNo padasetiap kejadian. • Multi-valued Attribute, yaitu atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misal entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian. • Derived Attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya dan tidak harus berasal dari satu entitas.
18 Keys • Candidate Key, yaitu jumlah minimal atribut-atribut yang dapat mengidentifikasi setiap kejadian atau record secara unik. • Primary Key, yaitu Candidate key yang dipilih untuk mengidentifikasikan setiap kejadian atau record dari suatu entitas secara unik. • Composite Key, yaitu Candidate key yang terdiri dari dua atau lebih atribut.
Gambar 2.6 ER Diagram of Staff and Branch Entities and their Attributes (Connolly, Database Systems, p382)
2.1.12.2 Normalisasi Menurut Connolly (2010, p416). Tujuan utama dalam pengembangan model data logikal pada sistem basis relasional adalah untuk menciptakan representasi akurat suatu data, keterhubungannya dan batasan-batasannya.Untuk mencapai tujuan ini, maka harus ditetapkan/diidentifikasi sekumpulan relasi. Empat bentuk normal yang biasa digunakan yaitu, first normal form (1NF), second normalform (2NF) dan third normal form (3NF) dan Boyce–Codd normal form (BCNF).Terdapat bentuk fourth normal form (4NF) dan fifth normal form (5NF) untuk situasi yang jarang terjadi.
19 Berdasarkan pada functional dependencies antar atribut dalam relasi. Sebuah relasi dapat dinormalisasi kedalam bentuk tertentu untuk mengatasi kemungkinan terjadinya pengulangan dari update yang tidak baik. Normalisasi adalah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifat-sifat (properties) yang diinginkan, memenuhi kebutuhan data pada enterprise. •
Data Redundacy
Menurut Connolly (2010, p418) tujuan utama dari desain basis data relasional adalah untuk mengelompokkan atributatribut ke dalam relasi-relasi sehingga meminimalisasi redundansi data dan mengurangi penggunaan tempat penyimpanan yang dibutuhkan oleh sebuah relasi dasar. Masalah-masalah yang terkait dengan redundansi. Dapat dijelaskan dengan membandingkan relasi Staff dan Branch dengan relasi StaffBranch. Relasi StaffBranch memiliki data redundan, yaitu detail dari branch dituliskan berulang-ulang untuk setiap staff. Sebaliknya, informasi mengenai branch muncul hanya satu kali pada relasi Branch dan hanya branchNo saja yang diulang dalam relasi Staff, untuk merepresentasikan dimana setiap staff tersebut bekerja.
Gambar 2.7 Contoh Data Redundancy (Connolly, Database Systems, p419)
20 Update anomalies diklasifikasikan menjadi beberapa kelompok antara lain : A. Insertion Anomalies Terdapat dua tipe utama insertion anomalies,dapat diilustrasikan dengan menggunakan staffBranch Relation pada tabel 2.2(Connoly and Begg,2010,p419) Untuk memasukan rincian anggota baru dari staff ke dalam relasi staffBranch ,harus memasukan juga detail dari cabang dimana staff akan berada. Untuk memasukan rincian cabang baru yang pada saat itu belum mempunyai anggota dari staff di dalam relasi staffBranch,perlu untuk memasukan null ke atribut staff, seperti StaffNo, namun StaffNo adalah primary key dari relasi satffBranch,memasukan null untuk melanggar entity integrity dan tidak diperbolehkan
B. Delete Anomalies Jika menghapus sebuah basis dari relasi StaffBranch yang merepresentasikan anggota lama dari staff yang berlokasi pada sebuah cabang, rincian mengenai cabang tersebut juga akan hilang dari database. (Connolly and Begg, 2010, p419)
C. Update Anomalies Menurut Connolly (2010, p419) relasi yang mengandung informasi yang redundan dapat diakibatkan oleh update anomalies. Beberapa tipe dari update anomalies, diantaranya Insertion, Deletion, dan Modification.
D. Modification Anomalies Jika ingin mengubah nilai dari salah satu atribut pada cabang tertentu di dalam relasi StaffBranch.Sebagai contoh : alamat dari cabang yang bernomor B003,update harus dilakukan pada semua baris yang berlokasi pada cabang tersebut.(Connolly and Begg, 2010, p420)
21 E. Functional Dependencies Ketergantungan fungsi (Functional Dependencies) adalah pembatas antara dua set atribut dari database. (Elmasri and Navathe, 2004, p304). Functional dependencies dibagi menjadi 3 yaitu full functional dependency, partial dependency, transitive dependency.
Full Functional dependency Full Functional dependency menunjukan jika A dan B adalah atribut dari sebuah relasi ,B merupakan Full Functional dependent pada A,tetapi tidak pada setiap bagian dari A.(Connolly and Begg, 2010, p423) Full Functional dependency dapat ditunjukan sebagai berikut : StaffNo -----> branchNo
Partial dependency Partial dependency jika terdapat beberapa atribut yang bisa dihilangkan dari A dan meskipun dependency masih dimiliki.(Connolly and Begg, 2010, p423) StaffNo,sNameBranchNo Contoh diatas bukan merupakan full function dependency, karena BranchNo juga functionally dependency pada subset dari (StaffNo,sName) yaitu StaffNo
Transitive dependency Transitive dependency merupakan sebuah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi seperti AB dan BC,maka C adalah Transitive dependent pada A melalui B. (Connolly and Begg,2010,p424) StaffNosName,Position,Salary,BranchNo,bAddress BranchNobAddress Transitive dependency BranchNobAddress terjadi pada StaffNo melalui BranchNo
22 F. Unnormalized Form (UNF) Menurut Connolly and Begg, (2010, p430), tabel yang berisi satu atau lebih grup yang berulang.Pada tahap ini mentransfer data dari sumber menjadi format tabel dengan baris dan kolom.
Client
cName
No CR76
Property
pAddress
RentStart RentFinish Rent
No John
PG4
Kay
Owne rNo
6 Lawrence 1-Jul-07
31-Aug-08 350
CO40
St,Glasglow PG16
oName
5
Tina Murphy
Novar 1-Sep-08
1-Sep-09
450
CO93
Dr,Glasglo
Tony Shaw
w CR56
Aline
PG4
Stewart
6 Lawrence 1-Sep-06
10-Jun-07
350
CO40
St,Glasglow PG36
PG16
2
Tina Murphy
Manor 10-June-
Rd,
07
Glasglow
1-Nov-
1-Dec-08
375
CO93
Tony Shaw
10-Aug-10 450
CO93
5 Novar Dr, 09 Glasglow
Tabel 2.1 ClientRental Unnormalized Table (Sumber : Connolly and Begg,2010,p432)
Berdasarkan gambar diatas struktur dari repeating group adalah sebagai berikut : RepeatingGroup= (PropertyNo,pAddress,RentStart,RentFinish,Rent,OwnerNo,oName)
Tony Shaw
23 G. First Normal Form (1NF) Menurut Elmasri and Navathe, (2004, p315), 1NF didefinisikan untuk melarang atribut bernilai ganda, komposit atribut, dan kombinasi keduanya. 1NF menyatakan bahwa domain dari atribut harus dan hanya mencakup nilai atomic (tidak terpisahkan) dan nilai-nilai atribut dalam tuple harus nilai tunggal dari domain atribut tersebut. Dengan kata lain 1NF melarang “hubungan dalam hubungan”. Nilai-nilai atribut yang hanya diijinkan oleh 1NF adalah nilai atomic tunggal.
ClientNo
CName
CR76
John Kay
CR56
Aline Stewart
Tabel 2.2 1NF Client (Sumber : Connolly and Begg, 2010, p433)
Client
cName
No CR76
PropertyN pAddress
RentStart
RentFinish
Rent
o John
PG4
Kay
Owner No
6
Lawrence 1-Jul-07
31-Aug-08
350
CO40
St,Glasglow PG16
5
Aline
PG4
Stewart
6
Novar 1-Sep-08
1-Sep-09
450
CO93
Lawrence 1-Sep-06
10-Jun-07
350
CO40
PG16
5
Tina Murphy
2 Manor Rd, 10-JuneGlasglow
Tony Shaw
St,Glasglow PG36
Tina Murphy
Dr,Glasglow CR56
oName
1-Dec-08
375
CO93
Shaw
07
Novar 1-Nov-09
Tony
10-Aug-10
Dr,Glasglow
Tabel 2.3 1NF PropertyRentalOwner (Sumber : Connolly and Begg,2010,p433)
450
CO93
Tony Shaw
24
Hasil dari relasi 1NF adalah sebagai berikut :
Client(ClientNo,cName)
PropertyRentalOwner(ClientNo,PropertyNo,pAddress,RentStart, RentFinish,Rent,OwnerNo,oName)
H. Second Normal Form (2NF) Menurut Elmasri and Navathe, (2004, p318), 2NF didasarkan pada konsep full function dependency. Ketergantungan fungsional X→Y akan full functional dependency jika menghapus atribut A dari X menyebabkan ketergantungan tersebut menjadi tidak ada. Berarti untuk setiap atribut A bagian dari X secara fungsional tidak menentukan Y. Sebuah ketergantungan fungsional akan partial dependency jika beberapa atribut A bagian dari X dapat dihilangkan dan ketergantungan tetap terjaga. Untuk hubungan dimana Primary Key mengandung beberapa atribut, tidak ada atribut non-key yang boleh bergantung secara fungsional pada bagian Primary Key.
ClientNo
CName
CR76
John Kay
CR56
Aline Stewart
Tabel 2.4 2NF Client (Sumber : Connolly and Begg,2010,p435)
25 ClientNo
PropertyNo
RentStart
RentFinish
CR76
PG4
1-Jul-07
31-Aug-08
CR76
PG16
1-Sep-08
1-Sep-09
CR56
PG4
1-Sep-06
10-Jun-07
CR56
PG36
10-June-07
1-Dec-08
CR56
PG16
1-Nov-09
10-Aug-10
Tabel 2.5 2NF Rental (Sumber : Connolly and Begg,2010,p435)
PropertyNo
pAddress
PG4
6
Rent
Lawrence 350
OwnerNo
oName
CO40
Tina
St,Glasglow PG16
5
Novar 450
Murphy CO93 Tony Shaw
Dr,Glasglow PG36
2 Manor Rd, 375
CO93
Glasglow
Tony Shaw
Tabel 2.6 2NF PropertyOwner (Sumber : Connolly and Begg,2010,p435)
Relasi yang didapat adalah sebagai berikut : Client (ClientNo,cName) Rental (ClientNo,PropertyNo,RentStart,RentFinish) PropertyOwner (PropertyNo,pAddress,Rent,OwnerNo,oName)
I. Third Normal Form Menurut Elmasri and Navathe, (2004, p319), 3NF didasarkan pada konsep transitive dependency. Ketergantungan fungsional X→Y dalam
26 skema relasi R akan transitive dependency jika ada satu set atribut Z yang bukan candidate key ataupun subset dari key pada R, dan kedua X →Z dan Z→Y tetap bertahan. Relasi tidak boleh memiliki atribut nonkey yang bergantung secara fungsional pada atribut nonkey lainnya. Tidak boleh ada transitive dependency dari atribut nonkey pada primary key
PropertyNo
pAddres
PG4
6
Rent
Lawrence 350
OwnerNo CO40
St,Glasglow PG16
5
Novar 450
CO93
Dr,Glasglow PG36
2
Manor Rd, 375
CO93
Glasglow
Tabel 2.7 3NF PropertyForRent (Sumber : Connolly and Begg,2010,p436)
OwnerNo
Oname
CO40
Tina Murphy
CO93
Tony Shaw
CO93
Tony Shaw
Tabel 2.8 3NF Owner (Sumber : Connolly and Begg,2010,p436)
Hasil dari relasi 3NF adalah sebagai berikut : Client (ClientNo,cName) Rental (ClientNo,PropertyNo,RentStart,RentFinish) PropertyForRent (PropertyNo,pAddress,Rent,OwnerNo,oName) Owner (OwnerNo,oName)
27 2.1.13. Perancangan Basis Data 2.1.13.1. Perancangan Database Konseptual Menurut Connolly (2010, p467). Suatu proses pembentukan model dari informasi yang digunakan dalam enterprise, independen dari keseluruhan aspek fisik. Model data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan user. Model data konseptual merupakan sumber informasi untuk fase desain logikal. Adapun langkah-langkahnya yaitu : •
Identifikasi tipe entitas Untuk mengidentifikasikan entitas utama yang dibutuhkan oleh
view.
Mendefinisikan
objek
utama dimana
user
mempunyai ketertarikan dengan objek tersebut. Objek ini adalah tipe entitas untuk model. Salah satu metode untuk mengidentifikasi entitas adalah dengan menguji spesifikasi kebutuhan dari user. Dari spesifikasi ini kita mengidentifikasikan kata benda dan ungkapan kata benda (noun phrases) yang disebutkan. Kita juga dapat melihat objek utama seperti orang, tempat atau konsep dari ketertarikan diluar kata benda lainnya yang merupakan kualitas dari objek lain. • Identifikasi tipe relationship Tujuannya untuk mengidentifikasikan relationship penting yang ada antara tipe entitas yang telah diidentifikasikan. Kita dapat menggunakan grammar dari spesifikasi kebutuhan tersebut untuk mengidentifikasi relationship. Relationship dinyatakan oleh kata kerja/ verb atau ekspresi verbal. Secara langsung relationship tersebut adalah binary, dengan kata lain relationship tersebut berada antara dua tipe entitas.
28 • Identifikasi dan Hubungkan Atribut dengan Entitas atau Tipe Hubungan Tujuannya untuk menghubungkan atribut dengan entitas atau tipe relationship yang sesuai dan mendokumentasikan detail dari setiap atribut. Atribut-atribut bisa diidentifikasi dengan kata benda atau ungkapan kata benda (noun phrases). Seperti property, kualitas, identifier atau karakteristik dari satu entitas atau hubungan. • Tetapkan domain atribut Tujuannya untuk menetapkan domain atribut dalam model data konseptual lokal dan mendokumentasikan setiap detail dari domain. Domain merupakan sekumpulan (pool) nilai-nilai dari satu atau lebih atribut yang menggambarkan nilainya. • Tetapkan Atribut Primary dan Candidate key Untuk mengidentifikasikan candidate key untuk setiap entitas dan jika terdapat lebih dari satu candidate key, maka pilih satu sebagai primary key. • Periksa Model Untuk Pengurangan Dalam langkah ini kita menguji model data konseptual lokal dengan tujuan spesifik untuk mengidentifikasikan apakah ada redundancy dalam data dan memindahkan data yang telah ada. Dua aktifitas dalam langkah ini adalah: • Menguji ulang relationship 1-1 (one-to-one). • Menghilangkan relationship yang redundan. Dari 2 tahapan di atas, maka dapat disimpulkan bahwa tidak ada redudansi data yang terjadi. • Review Model Data Konseptual Lokal Tujuannya untuk me-review model data konseptual lokal dengan user untuk memastikan model tersebut adalah
29 representasi sebenarnya dari view. Model data konseptual ini termasuk ER diagram dan dokumentasi pendukung yang mendeskripsikan model data. Bila ada kejanggalan (anomali) dalam model data. Maka harus dibuat perubahan yang sesuai yang mungkin membutuhkan pengulangan langkah-langkah sebelumnya.
Gambar 2.8 Perancangan basis data konseptual (Sumber : Connolly and Begg,2010,p480)
2.1.13.2. Perancangan Database Logikal Menurut Connolly (2010, p490). Suatu proses pembentukan model dari informasi yang digunakan dalam enterprise berdasarkan
30 model data tertentu (misal : relasional), tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logical, Adapun langkah-langkahnya yaitu : • Menghilangkan fitur yang tidak sesuai dengan model relasional • Menghilangkan hubungan many to many (*..*) Pada ERD Konseptual terjadi hubungan entitas yang *..*. Hubungan ini harus dihilangkan dengan menambah entitas baru. • Menghilangkan atribut yang multi-valued Pada bagian identifikasi atribut ada beberapa entitas yang mempunyai atribut yang multi-valued. Hal ini harus dihilangkan dengan memisahkan atribut yang multi-valued dari entitasnya. Biasanya multi-valued berupa atribut telepon. • Menurunkan relasi untuk Model Data Logikal Tahapan ini membentuk relasi dari model data logikal untuk merepresentasikan relasi antar entitas dengan atribut yang telah didefinisikan.. Untuk mendapatkan relasi dari data model yang ada, makan digunakan cara-cara berikut ini : 1. Strong entity types; 2. Weak entity types; 3. One-to-many (1:*) binary relationship types; 4. One-to-one (1:1) recursive relationship types; 5. One-to-one (1:1) binary relationship types; 6. Superclass/subclass relationship types; 7. Many-to-many (*:*) binary relationship types; 8. Complex relationship types
31 • Memvalidasi relasi dengan normalisasi Untuk merancang basis data yang baik, biasa dilakukan normalisasi. Normalisasi merupakan sebuah teknik untuk menghasilkan set relasi dengan property yang diinginkan dan memberikan data sesuai dengan kebutuhan enterprise. UNF : Dalam proses normalisasi UNF kita menampilkan semua field atau atribut yang ada dalam suatu form yang ingin kita normalisasi. 1NF : Sebuah relasi berada dalam 1NF jika relasi tersebut tidak berisi atribut yang berulang (repeating group) field
hasil
perhitungan
dihilangkan
dan
sudah
mempunyai primary key. 2NF : Sebuah relasi berada dalam 2NF jika relasi tersebut dalam 1NF dan untuk setiap atribut non-key bergantung fungsional penuh kepada primary key. Jadi pada 2NF kita akan menghilangkan ketergantungan sebagian / partial : ketergantungan field-field tertentu hanya kepada salah satu key yang composite. 3NF : Sebuah relasi berada dalam 3NF bila relasi tersebut dalam 1NF dan 2NF dan tidak ada atribut non-key yang tergantung fungsional kepada atribut non-key yang lainnya (transitive dependency).
32 • Memeriksa Integrity Constraints Integrity constraints adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten.
Gambar 2.9 Perancangan basis data logikal (Sumber : Connoly dan Begg, 2010, p516)
2.1.13.3. Perancangan Database Fisikal Menurut
Connolly
(2010,
p522).
Suatu
proses
yang
menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu. Adapun langkah-langkahnya yaitu :
33 Merancang relasi dasar Dalam merancang relasi dasar digunakan DBDL (Database Design Language) untuk mendeskripsikan definisi relasi. Untuk setiap relasi diberikan deskripsi yang meliputi nama relasi, atribut, primary key, alternate key, foreign key, atribut yang merupakan hasil perhitungan, referential integrity, domain dan apakah atribut boleh NULL. Menganalisis transaksi Tujuan dari langkah
ini adalah untuk
memahami
fungsionalitas dari transaksi yang akan berjalan pada basis data dan untuk menganalisis transaksi yang penting. Memilih Index Tujuan dari langkah ini adalah untuk menentukan apakah penambahan index akan meningkatkan kinerja dari sistem. Pada DBMS MySQL primary key didefinisikan ke dalam Index Clustered. Merancang User View Tujuan dari langkah ini adalah untuk melihat sudut pandang pengguna terhadap tabel dan field yang ada di dalam database. Merancang mekanisme keamanan Tujuan dari langkah ini adalah untuk merancang mekanisme keamanan pada basis data seperti yang telah dispesifikasikan oleh user. Mekanisme keamanan tersebut adalah pembatasan hak akses guna menjaga keamanan data. Selain itu perlu juga diperhatikan keamanan DBMS dan sistem operasinya.
34 Memperkirakan kebutuhan disk Tujuan dari langkah ini adalah untuk menghitung kapasitas penyimpanan yang dibutuhkan oleh basis data. Hal yang harus diperhatikan adalah seberapa besar ruang penyimpanan yang tersedia saat ini. Penyimpanan yang tersedia saat ini akan menentukan besarnya kapasitas penyimpanan yang dibutuhkan sekarang dan lima tahun mendatang.
Gambar 2.10 Contoh perancangan basis data physical base relation
35 (Sumber : Connoly dan Begg, 2010, p526)
2.1.14. Data Flow Diagram (DFD) Menurut Whitten (2004, p326), Data Flow Diagram (DFD) adalah sebuah alat untuk melakukan penggambaran dari suatu aliran data melalui sistem yang bekerja maupun pengolahan yang dilakukan oleh sistem tersebut. Simbol maupun tanda yang akan digunakan dalam pembuatan DFD diantaranya : a. Process adalah kerja yang dilakukan pada atau sebagai respons terhadap aliran data masuk atau kondisi. b. Data flow menunjukkan input data ke proses atau output data (atau informasi) dari proses. Data flow juga digunakan untuk menunjukkan pembuatan, pembacaan, penghapusan atau pembaruan data dalam file atau database. c. External Agent mendefinisikan orang, unit organisasi, sistem, atau organisasi luar yang berinteraksi dengan sistem. Data store adalah penyimpanan data yang akan digunakan untuk penyimpaan data selanjutnya.
2.1.15. Flowchart Flowchart
atau
bagan
alur
merupakan
metode
untuk
menggambarkan tahap-tahap penyelesaian masalah (prosedur) beserta aliran data dengan simbol-simbol standar yang mudah dipahami. Tujuan utama penggunaan Flowchart adalah untuk menyederhanakan rangkaian proses atau prosedur untuk memudahkan pemahaman pengguna terhadap informasi tersebut.
36 Simbol
Nama
Keterangan
Terminator
Untuk menandai awal atau akhir dari suatu flowchart
Data I/O
Menandai masuk
data
yang
(input)
atau
keluar (output) Process
Pemrosesan data yang terkomputerisasi
Manual Operation
Menandai operasi manual (tidak terkomputerisasi)
Connector (Flow
Penghubung dari satu
Direction)
simbol ke simbol lainnya juga berfungsi sebagai penanda aliran data
Decision
Menandai perlunya dilakukan pengambilan keputusan
On-Page Reference
Konektor yang digunakan untuk menghubungkan pada halaman yang sama
Off-Page Reference
Konektor yang digunakan untuk menghubungkan pada halaman yang berbeda
Database
Menandai tempat penyimpanan basis data
37 Document
Menandai dokumen atau laporan
Multi-Document
Menandai rangkap dokumen atau laporan
Offline Data
Menandai arsip data manual
Gambar 2.11 Simbol Flowchart
2.1.16. Software Architecture Satzinger (2010, p344). Software architecture terbagi menjadi dua jenis yaitu: •
Client: Sebuah proses, modul, objek atau komputer yang meminta layanan dari satu atau lebih server.
•
Server: Sebuah proses, modul, objek atau komputer yang dapat menyediakan layanan melalui jaringan. o Three layer architecture server architecture: Merupakan arsitektur client/server membagi aplikasi ke dalam data layer, business logic layer dan view layer. Data layer : Bagian dari tiga lapis arsitektur yang dapat saling berinteraksi dengan database. Business logic: Bagian dari tiga arsitektur layer yang saling berisi dengan progam-progam yang dapat dilakukan implementasi aturan bisnis dan aplikasi.
38 View layer: Bagian dari tiga arsitektur layer yang berisi user interface.
2.1.17. Deployment Environment Satzinger (2010, p291). Deployment environment adalah suatu perangkat keras, sistem perangkat lunak dan lingkungan jaringan dimana sistem akan beroperasi. Pada bagian ini, menggambarkan lingkungan penyebaran umum secara detail, dan bagian yang selanjutnya akan dapat melakukan eksplorasi pola desain terkait dan arsitektur untuk aplikasi perangkat lunak. Dari sisi perangkat keras terdiri dari: •
Single computer architecture Merupakan arsitektur yang dapat menggunakan satu sistem
komputer untuk mengeksekusi semua aplikasi perangkat lunak. •
Multi-tier Architecture Arsitektur yang mendistribusikan aplikasi yang berhubungan
dengan perangkat lunak di beberapa sistem komputer. Multi-tier architecture dibagi menjadi dua jenis: o Clustered architecture Sekelompok komputer yang sama dalam berbagi beban processing dan bertindak sebagai sistem komputer yang tunggal yang besar. o Multi computer Komputer yang berbeda, yang dapat berbagi beban pengolahan melalui spesialisasi fungsi. •
Centralized Architecture Merupakan arsitektur yang menempatkan semua sumber daya
komputasi di lokasi kontrol.
39 •
Distributed Architecture Merupakan arsitektur yang menyebarkan sumber daya
komputasi di beberapa komputer yang terhubung oleh jaringan komputer.
Gambar 2.12 Contoh single-computer, clustered and Multi-computer Sumber Gambar ()
2.1. Teori-Teori Khusus 2.2.1. Pembelian Sofjan Assauri (2008, p223). Pembelian adalah salah satu fungsi yang penting dalam berhasilnya operasi dalam suatu perusahaan. Fungsi ini dibebani tanggung jawab untuk mendapatkan kuantitas dan kualitas bahan-bahan yang tersedia. Pada waktu dibutuhkan dengan harga yang sesuai dengan harga yang dapat berlaku, pengawasan perlu dilakukan terhadap pelaksanaan fungsi ini, karena pembelian menyangkut investasi dana dalam persediaan. Mulyadi (2007, p711). Pembelian adalah aktivas dalam proses pembelian barang sebagai berikut: o Permintaan pembelian
40 o Pemilihan pemasok o Penempatan order o Penerimaan barang o Pencatatan transaksi Permintaan merupakan contoh pekerjaan yang ditunjukan untuk memicu bagian pembelian melakukan pengadaan barang sesuai dengan spesifikasi dan jadwal sebagaimana yang dibutuhkan oleh pemakai barang. Berdasarkan definisi-definisi yang dijabarkan oleh para ahli, maka dapat disimpulkan pembelian adalah merupakan suatu tanggung jawab untuk mendapatkan kuantitas dan kualitas barang yang sesuai dengan spesifikasi yang dibutuhkan oleh pemakai barang.
2.2.2. Penjualan Kotler (2006, p457). Penjualan adalah proses dimana kebutuhan pembeli dan kebutuhan penjual dipenuhi, melalui antara pertukaran informasi dan kepentingan.
2.2.3. Persediaan Sofjan (2008, p237). Persediaan adalah sejumlah bahan-bahan, parts yang disediakan dan bahan-bahan dalam proses yang terdapat dalam perusahaan untuk proses produksi, produk yang disediakan untuk memenuhi permintaan dari dalam komponen atau langganan setiap waktu.
2.2.4. Problem Solving Mcleod (2007, p161). Problem solving memiliki elemen-elemen, sebagai berikut: o Desired state Suatu keadaan dimana sistem dapat memenuhi tujuan pembuatan, dan juga keadaan dimana sistem memenuhi kebutuhan para manajer. o Current state Keadaan sistem yang sedang berjalan, dan informasi apa saja yang sudah dicapai oleh sistem. Apabila terjadi perbedaan antara desired state dan current state maka akan timbul masalah dan harus diselesaikan.
41 o Solution criterion Perbedaan antara desired state dan current state merupakan kriteria yang menuntun sistem dari current state menuju desired state.
2.2.5. SQL Server Ross Mistry and Stacia Misner (2010, p3). SQL Server adalah sesuatu kumpulan komponen yang bisa diimplementasikan baik secara terpisah dan dapat tergabung. Dapat membentuk sebuah platform data yang berguna untuk melakukan penyimpan data yang memiliki enchanment.
2.2.6. Visual Basic Net Koh Sen gupta,Goh, Peh (2007, p2). Visual basic adalah suatu bahasa arsitektur yang sepenuhnya berorientasi obyek, berbeda secara konversional dan aplikasi ini terdiri dari beberapa. Sub program yang ditulis dalam bahasa campuran seperti VB.NET dan C# atau 47 bahasa apapun yang mendukung NET.FIREWORK.
2.2.7. Pengambilan Keputusan Menurut Kotler dan Keller (2009, p207). Pengambilan keputusan adalah suatu produk atau service dapat membantu dalam pemasaran ataupun perusahaan untuk mengerti perilaku konsumen dan menjelaskan perilaku konsumen dalam menentukan pembelian
Gambar 2.13 Five stage Model of the Consumer Buying Process Sumber Gambar (Kotler dan Keller 2009)
