BAB 2 LANDASAN TEORI. yang digunakan oleh sistem aplikasi dari suatu perusahaan. saling berhubungan di mana dirancang untuk mencapai informasi yang

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Perancangan Database Menurut Date (2004, p11), database adalah sekumpulan data persisten yang digunakan oleh sistem aplikasi dari suatu perusahaan. Menurut Connolly (2010, p65), database adalah sekumpulan data yang saling berhubungan di mana dirancang untuk mencapai informasi yang diperlukan dalam suatu organisasi. Melalui definisi di atas, dapat disimpulkan bahwa database merupakan tempat penyimpanan data yang besar di mana bisa digunakan secara bersamaan oleh banyak organisasi dan pemakai lainnya (user) Entity Relationship Modeling (ER Modelling) ER Modelling adalah sebuah pendekatan top-down untuk merancang database yang dimulai dengan mengidentifikasi data yang penting yang disebut entitas dan relationship antar data harus dipresentasikan dalam model (Connolly, 2010, p371) Konsep Dasar ER Modelling Beberapa konsep dasar dalam model ER yaitu : 1. Entitas Menurut Connolly (2010, p372), entity type adalah sekumpulan objek yang memiliki property yang sama, yang diidentifikasikan di dalam organisasi karena keberadaannya yang bebas. 7

2 8 Sedangkan entity occurence menurut Connolly (2010, p373) adalah sebuah objek dari satu entity yang dapat diidentifikasikan secara unik. Setiap entity dilambangkan dengan sebuah persegi panjang yang diberi nama dari entity tersebut. Nama entity biasanya adalah kata benda tunggal. Gambar 2. 1 Representasi Diagram Dari Entity Product dan Category 2. Relationship Menurut Connolly (2010, p374), relationship type adalah hubungan antar entity yang memiliki arti. Sedangkan relationship occurrence adalah sebuah hubungan yang dapat diidentifikasikan secara unik, yang meliputi sebuah kejadian (occurrence) dari setiap entity di dalam relationship. Relationship digambarkan dengan sebuah garis yang menghubungkan entity yang saling berhubungan. Garis tersebut diberi nama sesuai dengan nama hubungannya dan diberi tanda panah satu arah di samping nama hubungannya.

3 9 Gambar 2. 2 Reprensentasi Diagram dari Relationship 3. Atribut Menurut Connolly (2010, p379), atribut adalah property sebuah entity atau relationship. Atribut dapat diklasifikasikan sebagai: a. Simple and Composite Attribute Menurut Connolly (2010, p379), simple attribute adalah atribut yang terdiri dari komponen tunggal dengan keberadaan yang bebas. Menurut Connolly (2010, p380), composite attribute adalah atribut yang terdiri dari beberapa komponen dan keberadaan komponen tersebut adalah bebas. b. Single Value and Multi Value Attribute Menurut Connolly (2010, p380), single value attribute adalah atribut yang hanya memiliki sebuah nilai untuk setiap tipe entity. Sebagian besar atribut merupakan single value. Menurut Connolly (2010, p380), multi value attribute merupakan atribut yang memiliki banyak nilai untuk setiap entity.

4 10 c. Derived Attribute Menurut Connolly (2010, p380), derived attribute merupakan sebuah atribut yang merepresentasikan sebuah nilai yang berasal dari nilai sebuah atribut yang berhubungan atau set atribut, dan tidak harus berada dalam tipe entity yang sama. 4. Key Candidate Key adalah sejumlah kecil atribut yang secara unik mengidentifikasikan setiap occurence dari sebuah entity (Connolly, 2010, p381). Primary Key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurence dari sebuah entity (Connolly, 2010, p381). Composite Key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, 2010, p382). Gambar 2. 3 Representasi Diagram Entity Product dan Category Beserta Atribut dan Primary Key

5 11 5. Batasan Struktural Batasan yang menggambarkan pembatasan pada relationship seperti yang ada pada real world harus diterapkan pada entity yang ikut serta pada sebuah relationship dinamakan multiplicity (Connolly, 2010, p385). Multiplicity merupakan sejumlah kejadian (occurrence) yang mungkin dari sebuah tipe entity yang berhubungan dengan suatu kejadian dari sebuah tipe entity yang berhubungan melalui relasi tertentu (Connolly, 2010, p385). Derajat yang umum pada suatu relationship adalah binary relationship, yang terdiri atas : a. One to one (1:1) relationship. b. One to many (1:*) relationship. c. Many to many (*:*) relationship. 6. Cardinality and Participation Constraints Menurut Connolly (2010, p390 - p391), multiplicity terdiri dari dua batasan yaitu cardinality dan participation. Cardinality menggambarkan jumlah maksimum relasi yang mungkin terjadi dari sebuah entity yang berpartisipasi dalam tipe relasi. One-to-one (1:1), one-to-many (1:*), manyto-many (*:*) merupakan cardinality dari relasi binary participation menentukan apakah semua atau hanya sebagian dari entity yang berpartisipasi dalam relasi.

6 12 Gambar 2. 4 Cardinality dan Participation antara Product dan Category Gambar 2. 5 Contoh ER Modelling

7 Functional Depedencies Menurut Elmasri (2010, p513), functional dependency adalah sebuah aturan atau batasan antara dua set attributes dari database. Menurut Connolly (2010, p421), functional depedency adalah property dari arti atau semantik dari attributes dalam suatu hubungan. Contoh : UNF : berisi data yang berulang-ulang A B C D E F G Gambar 2. 6 Functional Dependecies UNF Keterangan : 1. C bergantung secara penuh (fully) kepada A dan B. 2. D bergantung secara sebagian (partial) kepada B. 3. E bergantung kepada G yang bukan primary key (transitives). 4. F bergantung kepada G yang bukan primary key (transitives). 5. G bergantung secara sebagian (partial) kepada A. 1NF : atribut yang bergantung kepada seluruh atribut primary key

8 14 A* B* C D E F G Gambar 2. 7 Functional Dependecies 1NF Keterangan : 1. A* adalah primary key. 2. B* adalah primary key. 3. C bergantung kepada A dan B. 4. D bergantung secara sebagian (partial) kepada B. 5. E bergantung kepada G yang bukan primary key (transitives). 6. F bergantung kepada G yang bukan primary key (transitives). 7. G bergantung secara sebagian (partial) kepada A. 2NF : atribut yang bergantung kepada sebagian atribut primary key. A* B* C B* D A* E F G Gambar 2. 8 Functional Dependecies 2NF

9 15 Keterangan : 1. A* adalah primary key. 2. B* adalah primary key. 3. C bergantung kepada A dan B. 4. D bergantung kepada B. 5. E bergantung kepada G yang bukan primary key (transitives). 6. F bergantung kepada G yang bukan primary key (transitives). 7. G bergantung kepada A. 3NF : atribut yang bergantung kepada atribut yang bukan primary key. A* B* C B* D A* H H* E F G Gambar 2. 9 Functional Dependecies 3NF Keterangan : 1. A* adalah primary key. 2. B* adalah primary key.

10 16 3. C bergantung kepada A dan B. 4. D bergantung kepada B. 5. H bergantung kepada A. 6. H* adalah primary key. 7. E bergantung kepada H. 8. F bergantung kepada H. 9. G bergantung kepada H Normalisasi Menurut Connolly (2010, p416), normalisasi adalah suatu teknik untuk menghasilkan kumpulan relasi dengan properti yang diperlukan dan berguna untuk menyediakan kebutuhan data dari perusahaan. Langkah-langkah normalisasi menurut Connolly (2010, p430 - p436) dapat dijelaskan sebagai berikut: 1. Unnormalized Form (UNF) UNF merupakan suatu tabel yang berisikan satu atau lebih grup data yang berulang-ulang. UNF dilakukan dengan memindahkan data dari sumber informasi ke dalam format dengan baris dan kolom. Contoh : UNF : IdPesanan + { IdBarang + Kuantitas + NamaBarang } + Paket + Lokasi + HargaPengiriman Tabel 2. 1 Contoh UNF IdPesanan IdBarang Kuantitas NamaBarang Paket Lokasi HargaPengiriman KB01 2 Barang A 01 KB02 1 Barang B REG Jambi KB03 3 Barang C 02 KB02 1 Barang B KB03 2 Barang C OKE Bandung

11 17 2. First Normal Form (1NF) 1NF merupakan sebuah relasi di mana setiap irisan antar baris dan kolom berisikan satu dan hanya satu nilai saja. Cara mengubah dari bentuk UNF ke 1NF adalah sebagai berikut : a. Memilih satu atau sekumpulan atribut sebagai kunci untuk tabel unnormalized. b. Identifikasi grup yang berulang dalam tabel unnormalized yang berulang untuk kunci atribut. c. Hapus grup yang berulang dengan cara memasukkan data yang Contoh : semestinya ke dalam kolom yang kosong pada baris yang berisikan data yang berulang atau dengan cara menggantikan data yang ada dengan salinan dari kunci atribut yang sesungguhnya. 1NF : IdPesanan + IdBarang + Kuantitas + NamaBarang + Paket + Lokasi + HargaPengiriman Tabel 2. 2 Contoh 1NF IdPesanan IdBarang Kuantitas NamaBarang Paket Lokasi HargaPengiriman 01 KB01 2 Barang A REG Jambi KB02 1 Barang B REG Jambi KB03 3 Barang C REG Jambi KB02 1 Barang B OKE Bandung KB03 2 Barang C OKE Bandung Second Normal Form (2NF) 2NF berdasarkan pada konsep ketergantungan fungsional penuh yang mengindikasikan bahwa, jika X dan Y merupakan atribut dari sebuah relasi, Y dikatakan tergantung penuh terhadap X jika Y

12 18 tergantung secara fungsional kepada X tetapi tidak pada proper dari subset dari X. 2NF merupakan sebuah relasi dalam 1NF dan setiap atribut non primary key bersifat fully functional dependent pada primary key. Cara mengubah 1NF menjadi 2NF adalah sebagai berikut : a. Mengidentifikasi primary key untuk relasi 1NF. b. Mengidentifikasi functional dependency dalam relasi. c. Jika terdapat partial dependency terhadap primary key, maka hapus dengan menempatkan dalam relasi baru bersama dengan salinan determinannya. Contoh : 2NF : Pesanan = IdPesanan + IdBarang + Kuantitas Pengiriman = IdPesanan + Paket + Lokasi + HargaPengiriman Barang = IdBarang + NamaBarang Tabel 2. 3 Contoh 2NF Pesanan IdPesanan IdBarang Kuantitas 01 KB KB KB KB KB03 2 Tabel 2. 4 Contoh 2NF Pengiriman IdPesanan Paket Lokasi HargaPengiriman 01 REG Jambi OKE Bandung Tabel 2. 5 Contoh 2NF Barang IdBarang KB01 KB02 KB03 NamaBarang Barang A Barang B Barang C

13 19 4. Third Normal Form (3NF) 3NF adalah suatu relasi yang ada dalam 1NF dan 2NF di mana tidak terdapat atribut non primary key yang bersifat transitively dependent pada candidate key. Atribut yang tidak memberikan kontribusi terhadap penjelasan karakteristik primary key, akan dipindahkan ke sebuah tabel yang terpisah. Contoh : 3NF : Pesanan = IdPesanan + IdBarang + Kuantitas Pengiriman = IdPesanan + Paket + Lokasi + HargaPengiriman Barang = IdBarang + NamaBarang + HargaBarang Paket = IdPaket + Paket + Lokasi + HargaPengiriman Tabel 2. 6 Contoh 3NF Pesanan IdPesanan IdBarang Kuantitas 01 KB KB KB KB KB03 2 Tabel 2. 7 Contoh 3NF Pengiriman IdPesanan Paket Lokasi HargaPengiriman 01 REG Jambi OKE Bandung Tabel 2. 8 Contoh 3NF Barang IdBarang NamaBarang HargaBarang KB01 Barang A KB02 Barang B KB03 Barang C

14 20 Tabel 2. 9 Contoh 3NF Paket IdPaket Paket Lokasi HargaPengiriman 01 REG Jambi OKE Bandung OKE Jambi Database Lifecycle Sebagai suatu sistem database merupakan komponen dasar dari organisasi yang besar serta sistem informasi yang luas, database system development lifecycle terkait dengan lifecycle sistem informasi. Tahapan database system development lifecycle tidak harus berurutan, tetapi melibatkan beberapa pengulangan ke tahapan sebelumnya melalui umpan balik (Connolly, 2010, p313) Perancangan Conceptual Database Menurut Connolly (2010, p467), perancangan conceptual database adalah proses pembangunan data model yang digunakan perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi conceptual database, yang meliputi identifikasi dari entitas entitas, relationship - relationship, dan atribut atribut yang penting. Perancangan conceptual database terdiri dari sembilan tahap perancangan, yaitu (Connolly, 2010, p468) : A. Membangun model data konseptual 1. Identifikasi tipe entitas 2. Identifikasi tipe relasi 3. Identifikasi dan asosiasi atribut dengan entitas atau tipe relasi 4. Menentukan domain atribut

15 21 5. Identifikasi candidate dan primary key 6. Penggunaan enhanced modeling concept 7. Memeriksa redundansi 8. Validasi transaksi dengan transaksi user 9. Peninjauan model data konseptual dengan user Transaction PK TransactionId Payment PK PaymentId Transaction 1..* 1..1 User PK TransactionId PK Barang PK BarangId 1..* 0..* Transaction PK TransactionId Gambar Contoh Perancangan Conceptual Database Perancangan Logical Database Menurut Connolly (2010, p467), perancangan logical database adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari database yang meliputi perancangan relasi - relasi. Perancangan logical database terdiri dari tujuh tahap perancangan, yaitu (Connolly, 2010, p468): A. Membangun dan validasi model data logikal 1. Menentukan relasi-relasi untuk model data logikal 2. Validasi relasi dengan normalisasi

16 22 3. Validasi relasi terhadap transaksi user 4. Mengecek batas integritas 5. Meninjau ulang model data logikal dengan user 6. Menggabungkan model data logikal ke dalam model global 7. Mengecek untuk perkembangan yang akan datang Transaction PK TransactionId Payment PK PaymentId Transaction 1..* 1..1 User PK TransactionId PK Barang * DetailTransaction 1..* 1..1 Transaction PK BarangId PK TransactionId PK BarangId PK TransactionId Gambar Contoh Perancangan Logical Database Perancangan Physical Database Menurut Connolly (2010, p467), perancangan physical database adalah proses membuat deskripsi dari implementasi database pada secondary storage, mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk mendapatkan akses efisien pada data dan semua integrity constraint yang berhubungan dan security measures. Tujuannya adalah untuk memutuskan bagaimana struktur logikal diimplementasikan secara fisik dalam DBMS yang dipilih. Perancangan physical database terdiri dari empat tahap perancangan, yaitu (Connolly, 2010, p468 - p469): A. Menerjemahkan model data logical global untuk DBMS

17 23 1. Merancang relasi dasar 2. Merancang gambaran dari perolehan data 3. Merancang batas general B. Desain penyusunan dan pemberian index pada file 1. Analisis transaksi 2. Memilih organisasi file 3. Memilih indeks 4. Memperkirakan kebutuhan disk space C. Desain tampilan pengguna D. Desain mekanisme keamanan Contoh : Tabel Contoh Perancangan Physical Database CREATE TABLE Product ( ProductId Number (6,0) NOT NULL, SubCategory2Id Number (6,0) NOT NULL, ColorId Number (6,0) NOT NULL, ProductName Varchar (255) NOT NULL, ProductPrice Number (11,0) NOT NULL, ProductStock Number (11,0) NOT NULL, ProductSold Number (11,0) NOT NULL, ProductDescription Text, ProductPicture Varchar (255), ProductDate DateTime, ProductWeight Number (11,0), Constraint Product_PK Primary Key (ProductId), Constraint Product_FK Foreign Key (SubCategory2Id) References SubCategory2 (SubCategory2Id), Constraint Product_FK Foreign Key (ColorId) References Color (ColorId) );

18 Perancangan Web Database Menurut Eaglestone (2001, p262 - p263), design dari sistem web database memiliki tambahan dua pertimbangan dibandingkan dengan sistem database konvensional : 1. Desain halaman web terdiri dari : a. Menampilkan data web, yaitu penyajian data mengambil dari database atau input dari user. b. Asosiasi data web, yaitu desain link untuk navigasi di dalam dan di antara halaman web. c. Desain interface web, yaitu desain fitur halaman web termasuk penggunaan grafis, animasi, dll. 2. Desain hubungan antara halaman web dan database, terdiri dari : a. Pemetaan logikal web database, yaitu definisi logis dari pemetaan antara data yang ditampilkan dalam halaman web dan data yang tersimpan dalam database. b. Pemetaan fisikal web database, yaitu implementasi dari mekanisme di mana data bergerak antara halaman web dan database Perancangan Conceptual Web Database Analisis data web mendefinisikan model konseptual dari informasi halaman web, serta informasi yang mewakili database (Eaglestone, 2001, p265).

19 25 Admin 0..1 Checked_by 0..1 Taken_by 0..n Confirmation 0..n Product 1..1 ProductId SubCategory2Id ColorId ProductName ProductPrice ProductSold ProductPicture ProductStock ProductDescription ProductDate ProductWeight Taken_by 0..n 0..n Order 0..n Made_by ConfirmCode ReceiverName Address Phone CityId SubCityId TotalPayment Made_by TransactionId SubCityId ConfirmCode TransactionCode JneCode SenderName BankName Status 1..1 Customer Name Password Question Status Verif ProductPicture Gambar Contoh Perancangan Conceptual Web Database Keterangan : 1. Customer membuat order. 2. Product ditangani order. 3. Order ditangani admin. 4. Customer membuat confirmation. 5. Admin mengecek confirmation Perancangan Logical Web Database Desain logikal data web mendefinisikan struktur data dari halaman web yang sebenarnya, termasuk link yang ada di halaman itu dan link ke halaman lain (Eaglestone, 2001, p265).

20 26 Web page menyediakan akses ke sumber web dengan menampilkan informasi, dan memungkinkan pengguna untuk berinteraksi dengan halaman (Eaglestone, 2001, p310). Schema mirip dengan definisi tabel dalam database, atau definisi kelas dalam sebuah objek database (Eaglestone, 2001, p312). Schema didefinisikan untuk masing-masing sketsa halaman web. Nama field yang digunakan harus yang digunakan dalam skema database, sehingga untuk membangun pemetaan antara halaman web dan database (Eaglestone, 2001, p314). Contoh : 1. Admin Tabel Contoh Perancangan Logical Web Database pada Admin Field Name Name Password Question Status Verif Data Type 2. Customer Tabel Contoh Perancangan Logical Web Database pada Customer Field Name Name Password Question Status Verif Data Type

21 27 3. Product Tabel Contoh Perancangan Logical Web Database pada Product Field Name ProductId ColorId ProductName ProductPrice ProductStock ProductSold ProductPicture ProductDescription ProductDate ProductWeight Data Type DateTime 4. Order Tabel Contoh Perancangan Logical Web Database pada Order Field Name ConfirmCode CityId SubCityId ReceiverName Address Phone TotalPayment Data Type 5. Confirmation Tabel Contoh Perancangan Logical Web Database pada Confirmation Field Name TransactionId ConfirmationCode SubCityId TransactionDate JneCode SenderName BankName Status Data Type DateTime

22 Perancangan Physical Web Database Desain fisikal data web merancang bagaimana halaman - halaman web diimplementasikan dan dihubungkan ke sistem database (Eaglestone, 2001, p265). Contoh : xxx xxx x Rp x Rp xxx x Rp Update Checkout Total Price : Rp Gambar Contoh Perancangan Physical Web Database untuk My Cart Form Order : Nama Phone Address City SubCity Paket Captcha 25AB3ACD Submit Gambar Contoh Perancangan Physical Web Database untuk Form Order

23 29 User logika presentasi hanya dieksekusi di sini Client PC C/S Database stored here logika manipulasi data dieksekusi di sini Gambar Client/Server System: Distirbuted Data (Two Tiers) 1. Penyajian 2. Meminta untuk create, read, update, delete satu atau lebih record 3. Membaca permintaan baris dan kolom hanya dari tabel 4. Record dikunci sampai client melepas tabel 5. Menanggapi untuk mengembalikan permintaan baris dan kolom yang dibutuhkan 6. Mengembalikan aplikasi hanya beberapa data untuk di update 7. Update tabel 8. Membuka record Penjelasan : User memanipulasi database e-commerce melalui Client PC (Browser) langsung ke database server untuk mengakses informasi dan kemudian dari database server direspon kembali data yang diminta user melalui Client PC (Browser).

24 30 logika presentasi hanya dieksekusi di sini User logika aplikasi hanya dieksekusi di sini C/S Database stored here logika manipulasi data hanya dieksekusi di sini Gambar Client/Server System: Distirbuted Data and Application (Three Tiers) 1. Penyajian 2. Data dan permintaan pelayanan 3. Meminta untuk create, read, update, delete satu atau lebih record 4. Membaca permintaan baris dan kolom hanya dari tabel 5. Record dikunci sampai client melepas tabel 6. Menanggapi untuk permintaan manipulasi data 7. Informasi dan menanggapi pelayanan 8. Update tabel 9. Membuka record Penjelasan : User memanipulasi database e-commerce melalui Client PC (Browser), kemudian meminta data dan pelayanan melalui application server dan meminta untuk memanipulasi record melalui database server.

25 2.3 Flowchart Data yang diminta direspon kembali melalui application server dan merespon informasi dan pelayanan melalui Client PC (Browser). Flowchart adalah representasi grafis atau simbol dari sebuah proses. Setiap langkah dalam proses diwakili oleh simbol yang berbeda dan berisi penjelasan singkat tentang langkah proses. Simbol flowchart yang dihubungkan bersama dengan panah yang menunjukkan arah aliran proses. Simbol flowchart yang paling umum: Tabel Flowchart Nama Simbol Keterangan Terminator Sebuah flowchart bentuk oval menunjukkan awal atau akhir dari proses Process Sebuah flowchart bentuk persegi panjang yang menunjukkan langkah aliran normal proses Connector Kecil, diberi label, flowchart bentuk lingkaran digunakan untuk menunjukkan lonjakan aliran proses Data Sebuah genjang yang menunjukkan input data atau output (I/O) suatu proses Document Digunakan untuk menunjukkan dokumen atau laporan PHP (Hypertext Preprocessor) PHP (PHP: Hypertext Preprocessor) adalah bahasa scripting open source yang popular yang diintegrasikan ke HTML yang didukung banyak web server

26 32 termasuk Apache HTTP Server dan Internet Information Server Microsoft, dan disarankan dengan bahasa web scripting Linux (Connolly, 2010, p1043). 2.5 Codeigniter Codeigniter adalah framework PHP yang kuat dengan footprint yang sangat kecil, dibangun untuk coders PHP yang membutuhkan toolkit sederhana dan elegan untuk menciptakan fitur lengkap aplikasi web. 2.6 Cause-and-Effect Analysis Cause-and-Effect Analysis adalah sebuah teknik di mana masalah dipelajari untuk menentukan penyebab dan akibat (Whitten, 2004, p205). 2.7 E-commerce E-commerce adalah kegiatan bisnis yang berkaitan dengan konsumen (consumers), manufaktur (manufactures), service providers dan pedagang perantara (intermediaries) dengan menggunakan jaringan komputer (computer networks) yaitu internet (Harisno & Tri Pujadi, 2009, p67).