7 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.
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 komponen- komponen 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 tugas-tugas 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.
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.
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.
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. Data-data 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
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.
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.
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 kumpulan-kumpulan 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 komponen-komponen yang saling berhubungan dan saling bekerja untuk mencapai suatu tujuan dengan cara menerima input dan output dalam proses perubahan dalam organisasi.
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.
• 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. Macam-macam 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
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 masing-masing 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.
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.
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 atribut-atribut 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)
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)
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,sName
BranchNo
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)
StaffNo
sName,Position,Salary,BranchNo,bAddress BranchNo
bAddress
Transitive dependency BranchNo
bAddress terjadi pada StaffNo melalui BranchNo
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 No
cName Property No
pAddress RentStart RentFinish Rent Owne rNo oName CR76 John Kay PG4 PG16 6 Lawrence St,Glasglow 5 Novar Dr,Glasglo w 1-Jul-07 1-Sep-08 31-Aug-08 1-Sep-09 350 450 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG4 PG36 PG16 6 Lawrence St,Glasglow 2 Manor Rd, Glasglow 5 Novar Dr, Glasglow 1-Sep-06 10-June-07 1-Nov-09 10-Jun-07 1-Dec-08 10-Aug-10 350 375 450 CO40 CO93 CO93 Tina Murphy Tony Shaw Tony Shaw
Tabel 2.1 ClientRental Unnormalized Table (Sumber : Connolly and Begg,2010,p432)
Berdasarkan gambar diatas struktur dari repeating group adalah sebagai berikut :
RepeatingGroup=
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 CR56 John Kay Aline Stewart Tabel 2.2 1NF Client
(Sumber : Connolly and Begg, 2010, p433)
Client No
cName PropertyN o
pAddress RentStart RentFinish Rent Owner No oName CR76 John Kay PG4 PG16 6 Lawrence St,Glasglow 5 Novar Dr,Glasglow 1-Jul-07 1-Sep-08 31-Aug-08 1-Sep-09 350 450 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG4 PG36 PG16 6 Lawrence St,Glasglow 2 Manor Rd, Glasglow 5 Novar Dr,Glasglow 1-Sep-06 10-June-07 1-Nov-09 10-Jun-07 1-Dec-08 10-Aug-10 350 375 450 CO40 CO93 CO93 Tina Murphy Tony Shaw Tony Shaw Tabel 2.3 1NF PropertyRentalOwner (Sumber : Connolly and Begg,2010,p433)
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 CR56 John Kay Aline Stewart Tabel 2.4 2NF Client
ClientNo PropertyNo RentStart RentFinish CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 1-Jul-07 1-Sep-08 1-Sep-06 10-June-07 1-Nov-09 31-Aug-08 1-Sep-09 10-Jun-07 1-Dec-08 10-Aug-10 Tabel 2.5 2NF Rental
(Sumber : Connolly and Begg,2010,p435)
PropertyNo pAddress Rent OwnerNo oName PG4 PG16 PG36 6 Lawrence St,Glasglow 5 Novar Dr,Glasglow 2 Manor Rd, Glasglow 350 450 375 CO40 CO93 CO93 Tina Murphy Tony Shaw 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
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 Rent OwnerNo
PG4 PG16 PG36 6 Lawrence St,Glasglow 5 Novar Dr,Glasglow 2 Manor Rd, Glasglow 350 450 375 CO40 CO93 CO93 Tabel 2.7 3NF PropertyForRent (Sumber : Connolly and Begg,2010,p436)
OwnerNo Oname CO40 CO93 CO93 Tina Murphy Tony Shaw 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)
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.
• 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
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
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
• 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).
• 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 :
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.
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.
(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.
Simbol Nama Keterangan
Terminator Untuk menandai awal atau akhir dari suatu flowchart
Data I/O Menandai data yang
masuk (input) atau keluar (output)
Process Pemrosesan data yang terkomputerisasi
Manual Operation Menandai operasi manual (tidak terkomputerisasi) Connector (Flow
Direction)
Penghubung dari satu 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
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.
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.
• 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 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.
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
