8
Bab 2 Landasan Teori
2.1 Teori – Teori Umum 2.1.1 Teori – Teori Database Menurut Elmasri (2000, p4), data adalah fakta yang dapat direkam dan memiliki arti yang implisit. Menurut Whitten (2004, p27), data adalah fakta mentah mengenai orang, tempat, kejadian, dan benda yang penting bagi sebuah organisasi. Menurut Elmasri (2000, p4), database adalah kumpulan data yang berhubungan. DBMS adalah kumpulan program yang memungkinkan user untuk membuat dan menjaga sebuah database. Menurut Whitten (2004, p548), database adalah kumpulan file yang saling berhubungan. Menurut Connolly dan Begg (2002, p14), “A shared collection of logically related data, and a description of this data, designed to meet the information needs of an organization”. Yang dapat diartikan database adalah suatu kumpulan data komputer yang terintegrasi secara logic, dan deskripsi dari data ini, dirancang untuk memenuhi kebutuhan informasi sebuah organisasi. Database juga didefinisikan oleh McLeod (2001, p258) sebagai suatu koleksi data komputer yang terintegrasi, diorganisasikan dan disimpan dengan suatu cara yang memudahkan pengambilan data kembali.
9 2.1.2 Siklus Hidup Aplikasi Database
Gambar 2.1 Siklus Aplikasi Database 2.1.2.1 Perencanaan Database (Database Planning) Database planning atau perancangan basisdata adalah merencanakan bagaimana tahap-tahap dari lifecycle dapat direalisasikan dengan cara yang paling efisien dan efektif.
10 Perencanaan basis data harus terintegrasi dengan strategi sistem informasi. (Connolly, 2002, p273) 1. Identifikasi rencana dan tujuan perusahaan dengan penentuan sistem informasi yang diperlukan. 2. Evaluasi sistem informasi sekarang digunakan untuk menentukan kelemahan dan kekuatannya. 3. Penilaian tentang ruang IT yang mungkin menghasilkan keuntungan yang kompetitif. Perencanaan database juga harus meliputi pengembangan standar
pengumpulan
dokumentasi
yang
data,
bagaimana
diperlukan,
penetapan
bagaimana
format,
desain
dan
implementasi diproses. 2.1.2.2 Pendefinisian Sistem (System Definition) Pada system definition (definisi sistem) mendeskripsikan batasan dan cakupan dari aplikasi basis data dan user view. User view disini adalah kebutuhan aplikasi yang diperlukan, dilihat dari posisi kerja (seperti manager atau supervisor) atau dilihat dari departemen dalam enterprise (seperti produksi, penjualan, operasional). 2.1.2.3 Pengumpulan
dan
Analisa
Kebutuhan
(Requirement
Collection and Analysis) Proses pengumpulan dan analisa kebutuhan mengenai bagian dari organisasi yang akan mendukung aplikasi basis data
11 dan menggunakan informasi ini untuk mengidentifikasikan kebutuhan user pada sistem baru. Pada bagian ini dilakukan pengumpulan dan analisa informasi mengenai bagian-bagian dari enterprise yang akan menggunakan atau terkait dengan basis data yang akan dibuat. Untuk itu digunakan teknik yang disebut dengan fact-finding techniques. Terdapat lima teknik fact-finding yang umum digunakan: (Connolly,2002,p305) 1. Mengevaluasi dokumen 2. Interview 3. Mengobservasi jalannya kegiatan kerja pada perusahaan 4. Research 5. Questioner 2.1.2.4 Database Design Database design adalah proses membuat sebuah desain untuk sebuah basis data yang mendukung kegiatan operasional suatu enterprise (Connolly, 2002, p279). Pada bagian ini dibagi menjadi tiga tahap yaitu konseptual, logikal dan fisikal. 2.1.2.5 Pemilihan DBMS (DBMS Selection) Pemilihan
DBMS
(Database
Management
System)
dilakukan untuk memilih DBMS yang cocok atau sesuai dengan aplikasi basis data. Berikut ini adalah langkah-langkah utama
12 dalam memilih DBMS (Connolly,2002,p284): Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan. 1. Membuat perbandingan mengenai dua atau tiga produk DBMS. 2. Mengevaluasi produk-produk DBMS tersebut. 3. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut. Secara khusus DBMS menyediakan fasilitas-fasilitas seperti: 1. Mengijinkan user untuk menentukan basis data, biasanya melalui
Data
Definition
Language
(DDL).
DDL
mengijinkan user untuk menspesifikasikan tipe data dan struktur dan batasan-batasan data yang bisa disimpan di basis data. 2. Mengijinkan user untuk insert, update, delete dan retrieve data dari basis data, biasanya melalui Data Manipulation Language (DML). 3. DBMS menyediakan akses kontrol ke basis data. Sebagai contohnya DBMS menyediakan : a. Security system, dimana mencegah user otorisasi untuk mengakses basis data. b. Integrity system, dimana menangani konsistensi penyimpanan data. c. Concurrency control system, dimana mengijinkan basis data untuk diakses secara share.
13 d. Recovery control system, dimana basis data bisa di restore pada saat terjadi kesalahan pada hardware ataupun software. e. User-accesible catalog, dimana berisi deskripsi data di dalam basis data. 2.1.2.6 Rancangan Aplikasi (Application Design ) Rancangan dari user interface dan program aplikasi yang digunakan dan memproses basis data (Connolly, 2002, p287). Menerapkan aplikasi yang telah didesain untuk mendapat respon dari user terhadap rancangan interface. Dimana rancangan aplikasinya termasuk uraian program dan interface. Desain database dan aplikasi merupakan aktivitas paralel yang meliputi dua hal penting yaitu : Transaction design dan User interface design. 2.1.2.7 Prototyping Tujuan utama prototype adalah mengizinkan para pemakai untuk menggunakan prototype itu untuk mengetes apakah fiturfitur pada sistem telah bekerja sesuai dengan spesifikasi pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pemakai dan pengembang sistem dan mengevaluasi kelayakan desain sistem tertentu. Ada dua cara strategi untuk membuat prototype yaitu requirements (Connolly,
prototyping 2002,p291).
dan
evolutionary
prototyping
Untuk
requirements
prototyping
14 digunakan prototype untuk menentukan kebutuhan suatu aplikasi basis data yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototype tersebut tidak digunakan lagi. Prototype evolusioner tidaklah dibuang tetapi dikembangkan lebih lanjut sehingga menjadi aplikasi basis data tersebut. 2.1.2.8 Implementasi Implementasi merupakan perwujudan fisik dari basis data dan
desain
aplikasi
(Connolly,
2002,
p292).
Setelah
menyelesaikan tahap desain (dengan atau tanpa prototype), kini kita berada pada tahap implementasi basis data dan program aplikasi. 2.1.2.9 Loading dan Konversi Data (Data Conversion and Loading) Pemindahan data yang ada ke dalam basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru (Connolly, 2002, p293). Tahapan ini dibutuhkan ketika sistem baru menggantikan sistem yang lama. 2.1.2.10 Testing Testing adalah suatu proses melaksanakan program aplikasi dengan tujuan menemukan kesalahan (Connolly, 2002, p293). Dalam melakukan testing, para pemakai sistem yang baru harus dilibatkan untuk menguji proses aplikasi dan basis data tersebut. Situasi yang ideal untuk pengujian sistem adalah mempunyai suatu tes basis data pada suatu sistem perangkat keras yang
15 terpisah, tetapi ini sering tidak tersedia. Jika data rill diharapkan untuk digunakan, maka adalah penting untuk mempunyai backup. Setelah pengujian diselesaikan, maka sistem aplikasi dan basis data ini telah siap untuk digunakan. 2.1.2.11 Operasi Pemeliharaan (Operational Maintenance) Setelah melalui tahap-tahap sebelumnya maka sistem sekarang telah pada tahap pemeliharaan (maintenance), yang melibatkan aktivitas yang berikut (Connolly,2002,p293): a. Monitoring performance dari sistem, jika performance jatuh dibawah suatu tingkatan yang bisa diterima, penyetelan
atau
reorganisasi
basis
data
mungkin
diperlukan. b. Maintaning dan meningkatkan mutu aplikasi basis data ( ketika diperlukan). Kebutuhan baru disatukan ke dalam aplikasi basis data dengan mengikuti langkah-langkah sebelumnya yang terdapat dalam database lifecycle. Ketika aplikasi basis data sedang beroperasi, perlu dilakukan monitoring secara dekat untuk memastikan bahwa performance dalam tingkatan yang bisa diterima. Proses monitoring akan terus berlanjut sepanjang seluruh hidup suatu aplikasi basis data tersebut dan pada waktu tertentu boleh melakukan reorganisasi basis data untuk mencukupi kebutuhan dari sistem. Perubahan ini menyediakan informasi pada evolusi sistem dan sumber daya yang pada masa depan mungkin
16 diperlukan.
Hal
ini
memungkinkan
DBA
(Database
Administrator) untuk terlibat dalam perencanaan kapasitas dan untuk
memberitahu
staff
senior
siaga
untuk
melakukan
penyesuaian rencana. Jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau untuk membeli tools tambahan, jika tersedia. 2.1.3 Entity Relationship Diagram 2.1.3.1 Entity Type Entity type adalah sekelompok objek-objek dengan property yang sama, yang diidentifikasikan dengan keberadaan yang independent diperusahaan (Connolly,2002,p331). Sebuah entity type mempunyai keberadaan yang tidak terikat dan dapat menjadi objek dengan keberadaan fisik atau objek dengan keberadaan konseptual. Entity occurrence adalah objek dari sebuah entity type yang diidentifikasikan dengan unik (Connolly, 2002, p332). Pada buku Connoly digunakan pengertian entity type dan entity occurrence tetapi kita disini menggunakan pengertian yang umum yaitu “entity”. 2.1.3.2 Relationship Relationship type adalah sebuah kumpulan yang memiliki arti antara entity type (Connoly, 2002,p334). Relationship occurrence adalah suatu kumpulan objek yang diidentifikasikan dengan unik, yang termasuk satu kejadian dari tiap - tiap tipe entity yang ada. Pada buku Connolly digunakan pengertian
17 relationship type atau relationship occurrence tetapi kita disini menggunakan pengertian yang umum yaitu “relationship”. 2.1.3.3 Attribute Attribute adalah sebuah property dari sebuah entiti atau tipe relasi (Connolly,2002,p338). No.
Gambar
1
2
Keterangan
Arti
Kotak persegi
Mewakili
panjang.
entiti (entity).
Garis
Menghubungk an atribut dengan atribut dari entiti dengan relationship
Tabel 2.1 Tabel Komponen ERD
No. 1
Keterangan
Gambar
One-toManage
One(1:1) Staff
Suatu entity occurrence saling berhubungan
Branch
1..1
0..1
18 dengan entity occurence tunggal yang lain 2
One-toMany(1:*) Satu entity
Overses staff
occurrence
0..1
0...*
Property for rent
saling berhubungan dengan banyak entity occurrence. 3
Many-toMany(*:*) Banyak instance
Advertises News paper
0..*
saling berhubungan dengan banyak instance. Tabel 2.2 Entity Relationship
1..*
Property for rent
19 2.1.4 Relational Key Menurut Connolly (2002, p78), key terdiri dari : 2.1.4.1 Superkey Superkey adalah sebuah atribut atau set dari atribut yang secara unik mengidentifikasikan sebuah tuple dalam relasi. 2.1.4.2 Candidate Key Candidate key adalah sebuah superkey yang tidak memiliki subset adalah sebuah superkey dalam relasi. 2.1.4.3 Composite Key Composite key adalah key yang memiliki lebih dari satu atribut. 2.1.4.4 Primary Key Primary key adalah candidate key yang dipilih untuk mengidentifikasikan tuple secara unik dalam relasi. 2.1.4.5 Foreign Key Foreign key adalah sebuah atribut atau set dari atributatribut dalam satu relasi yang cocok dengan candidate key dari beberapa (kemungkinan sama) relasi. 2.1.5 Normalisasi Menurut Connolly (2002, p376), “A technique for producing a set of relations with desirable properties, given the data requirements of an enterprise”. Yang dapat diartikan normalisasi adalah sebuah teknik untuk membuat sebuah set relasi dengan properti yang diinginkan, dengan kebutuhan data perusahaan.
20 Tahap awal kegiatan normalisasi adalah mengidentifikasi dan mengumpulkan semua atribut yang diperlukan. Atribut-atribut tersebut berasal dari form-form masukan maupun keluaran yang digunakan oleh bagian-bagian yang ada dalam suatu organisasi dimana basis data tersebut dikembangkan. Semua atribut tersebut disusun dalam sebuah matriks elemen data, atau menggunakan kamus data. Sebuah kamus data menjelaskan atribut-atribut elemen data yang terdapat dalam suatu form atau entity. Setiap kamus data mewakili suatu
form entiti, bagaimana
menyusun kamus data serta notasi-notasi yang digunakan dapat dibaca pada buku. A. Ketergantungan Fungsional (functional dependency) Menjelaskan hubungan antar atribut yang ada dalam sebuah tabel atau relasi R. Sebuah atribut B tergantung secara fungsional terhadap A apabila setiap nilai B memiliki asosiasi atau pasangan tepat dengan satu nilai dari A, atau dengan kata lain atribut A menentukan atribut B, dan digambarkan dengan notasi A Æ B. Ketergantungan fungsional merupakan sebuah konsep penting dalam normalisasi. B. Anomali Pemutakhiran (Update Anomaly) Anomali pemutakhiran (update anomaly) adalah suatu operasi pemutakhiran tabel dan hasil yang diperoleh tidak sebagaimana yang diharapkan. Anomali ini terjadi akibat tabel yang belum memenuhi aturan bentuk normal (normal form) tertentu. Operasi pemutakhiran suatu tabel yang dimaksud adalah
21 operasi-operasi yang mengubah status basis data, yaitu INSERT, UPDATE, dan DELETE. C. Dekomposisi (Decomposition) Tabel – tabel yang memiliki anomali disebabkan adanya redundansi yang tidak minimal (tidak terkendali) dan disebabkan oleh rancangan tabel yang buruk, dan untuk mengatasinya adalah melalui dekomposisi (decomposition). Dekomposisi adalah mengurai sebuah tabel R yang tidak memenuhi bentuk normal tertentu dan berakibat anomali, dijadikan beberapa tabel R1 dan R2 dengan jumlah atribut yang lebih kecil. Sejumlah atribut menjadi
elemen
dari
tabel
dekomposisi
lainnya
R2.
Pengelompokkan sejumlah atribut menjadi elemen suatu tabel menggunakan konsep ketergantungan fungsional (functional dependency). D. Menjaga ketergantungan (Dependency Preserving) Satu hal lain yang harus dipenuhi dalam perancangan yang baik adalah menjaga ketergantungan (dependency preserving) yaitu tabel-tabel yang diperoleh dari hasil dekomposisi semestinya merupakan tabel yang mandiri (independent projection). Apabila dilakukan operasi pengubahan (update) pada suatu tabel cukup dilakukan terhadap tabel yang bersangkutan tanpa harus melibatkan tabel lainnya, kecuali pengubahan atribut primary key. 2.1.5.1 Tahapan - Tahapan Dalam Normalisasi
22 Tahap dalam normalisasi dimulai dari sebuah tabel dalam kategori tidak normal (Unnormalize Form) secara bertahap diubah ke bentuk normal pertama (first normal form atau 1NF), kemudian dari tabel dalam bentuk 1NF diubah lagi menjadi bentuk normal kedua (second normal form atau 2NF), selanjutnya diubah ke dalam bentuk normal ketiga (third normal form atau 3NF). (Connolly, 2002, p386). 2.1.5.1.1 Bentuk Tidak Normal (Unnormal Form- UNF) Sebuah tabel dikatakan dalam bentuk tidak normal (Unnormal Form - UNF) apabila terdapat satu atau lebih atribut yang menampung banyak nilai atau informasi berulang (repeating group). 2.1.5.1.2 Bentuk Normal Pertama (First Normal Form – 1NF) Sedangkan sebuah tabel dikatakan berada dalam bentuk normal pertama (1NF) apabila semua atribut tabel bersangkutan bernilai tunggal atau atomic. Untuk mengubah tabel yang semula dalam bentuk UNF menjadi 1NF adalah dengan cara menghilangkan unsur perulangan (repeating). 2.1.5.1.3 Bentuk Normal Kedua (Second Normal Form – 2NF) Sebuah tabel telah mencapai tingkat normal kedua (2NF) jika semua atribut bukan key ( non key attribute) tabel bersangkutan tergantung sepenuhnya pada primary key. Bentuk ketergantungan tersebut disebut sebagai
23 ketergantungan sepenuhnya (full functional dependency) terhadap primary key. Dan bila sebuah tabel terdapat atribut bukan key (minimal satu) tergantung hanya pada sebagian
atribut
primary
key
dinamakan
partial
dependency. Jadi yang memenuhi bentuk 2NF adalah apabila sudah tidak ada ketergantungan parsial, dimana seluruh field hanya tergantung pada sebagian field primary key. 2.1.5.1.4 Bentuk Normal Ketiga (Third Normal Form – 3NF) Sebuah tabel dikatakan telah memenuhi bentuk normal ketiga apabila tabel yang bersangkutan telah memenuhi bentuk normal kedua (2NF), serta atribut bukan kunci tidak memiliki unsure ketergantungan transitif (transitive dependency) terhadap primary key. Suatu ketergantungan transitif didefiniskan sebagai suatu hubungan ketergantungan fungsional tidak langsung terhadap superkey primary key. 2.1.6 General Database Requirement analysis Pada tahap ini seorang database designer mulai mengumpulkan data dari organisasi tersebut untuk menentukan apa saja yang dibutuhkan oleh organisasi tersebut dalam membentuk database yang bagus. Input
: User requirement organisasi
Output
: Deskripsi keperluan sistem dan organisasi
24 Tujuan
: Membuat deskripsi database organisasi yang melayani / mendukung dan menjadi kebutuhan sistem yang baru.
2.1.7 Data Analysis (Conceptual database design) Langkah awal dalam desain konseptual database adalah dengan membuat model data secara konseptual dari perusahaan yang bersangkutan. Data tersebut merupakan informasi-informasi mengenai perusahaan. Dalam menentukan model data secara konseptual, data yang digunakan tidak termasuk dalam sasaran DBMS, program aplikasi, bahasa pemrograman, dan masalah dalam pembuatan basis data. Dalam desain konseptual database data yang ada dikembangkan dengan representasi secara konseptual yang mencakup mengidentifikasi entiti, relasi dan atribut yang sangat penting dalam perancangan basis data tersebut. Input
: Deskripsi keperluan sistem dan organisasi
Output
: Data model konseptual
Tujuan
: Membuat deskripsi awal data tentang sesuatu (tema) dalam organisasi
2.1.8 Data Design ( Logical Database design) Dalam logical database design, model data yang telah diperoleh dalam desain konseptual database diubah dalam bentuk logikal model dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basis data (database). Hal ini dilakukan untuk menerjemahkan representasi konseptual ke dalam bentuk struktur logic dalam database. Data model logikal merupakan suatu informasi dalam merancang database fisikal.
25 Logical database design memberikan sarana yang membantu para perancang dalam merancang database fisikal. Input
: Data model konseptual
Output
: Data model logikal
Tujuan
: Membuat model data yang menggunakan struktur yang digunakan oleh DBMS yang akan dipakai.
2.1.9 Physical Database Design Physical database design dilakukan untuk memutuskan struktur logic secara fisik diimplementasikan kedalam tujuan Database Management System (DBMS), para perancang juga harus membuat keputusan mengenai bagaimana basis data (database) tersebut dapat diimplementasikan / diterapkan dalam perusahaan. Oleh karena itu, physical database design harus disesuaikan dengan DBMS yang spesifik. Terdapat
hubungan
antara
physical
database
design
untuk
meningkatkan kinerja dari basis data tersebut dapat mempengaruhi data model logikal. Input
: Data model logikal
Output
: Data model fisikal
Tujuan
: Membuat database secara fisik
2.1.10 Alat Bantu Perancangan 2.1.10.1 DFD (Data Flow Diagram) Menurut McLeod (2004, p171), data flow diagram (DFD) adalah sebuah representasi grafik dari sistem yang menggunakan
26 empat bentuk simbol untuk mengilustrasikan bagaimana aliran data sepanjang proses interkoneksi. Simbol-simbol tersebut merepresentasikan : •
Elemen lingkungan dimana sistem berantarmuka Elemen lingkungan berada di luar batasan sistem. Elemenelemen ini menyediakan data input dan menerima data output bagi sistem. Pada DFD tidak ada perbedaan antara data dan informasi. Semua yang mengalir dianggap data. Nama terminator sering digunakan untuk mendeskripsikan elemen-elemen lingkungan, karena mereka menandai titik dimana sistem berakhir. Sebuah terminator dilambangkan dengan sebuah persegi dan diberi label dengan nama dari elemen lingkungan. Terminator dapat berupa : o Orang, seperti manajer, yang menerima laporan dari sistem. o Organisasi, seperti departemen lain dalam satu perusahaan atau perusahaan lain. o Sistem lain dimana sistem kita berantarmuka.
•
Proses Proses merupakan sesuatu yang merubah input menjadi output. Proses dapat diilustrasikan dengan lingkaran atau persegi panjang dengan sudut melingkar (rounded rectangle). Setiap simbol proses ditandai dengan label.
27 Teknik memberi label yang paling umum adalah dengan menggunakan kata kerja dan objek, akan tetapi bisa juga digunakan nama daru sistem atau program komputer. •
Aliran data (Data flow) Aliran data berisi sebuah grup dari elemen data yang secara logikal berhubungan (berkisar dari sebuah data elemen sampai satu atau lebih file) yang berjalan dari satu titik atau proses ke titik atau proses yang lain. Simbol panah digunakan untuk mengilustrasikan aliran dan dapat digambarkan dengan garis lurus atau melengkung. Aliran data dapat dipecah ketika data yang sama berjalan ke beberapa tujuan pada sistem. Aliran data dapat juga menjadi satu ketika beberapa aliran data yang identik berjalan meuju satu lokasi. Terkadang desain sistem disebut two-way flow (aliran dua arah). Hal ini bisa diilustrasikan dengan sebuah panah berkepala dua atau dengan dua buah panah. Sebuah aliran data harus mengikutsertakan proses, bisa antara entiti eksternal dan proses, penyimpanan data dan proses dan antara dua atau lebih proses.
•
Penyimpanan data (Data storage) Ketika data perlu ditahan untuk berbagai alasan, sebuah penyimpanan data diperlukan. Penyimpanan data bisa
28 diilustrasikan dengan sebuah set garis paralel, sebuah persegi yang terbuka di belakang atau dengan sebuah oval. Proses
pembuatan
DFD
merupakan
proses
pengidentifikasian proses, menghubungkan mereka dengan aliran data, mengidentifikasikan terminator yang menyediakan input dan menerima output, dan menambah penyimpanan data ketika diperlukan. Menurut Whitten (2004, p344), Data Flow Diagram (DFD) merupakan sebuah tool yang menggambarkan aliran data pada sebuah sistem dan pengerjaan atau pemrosesan yang dilakukan oleh sistem. Pada data flow diagram (DFD) terdapat tiga buah simbol dan satu koneksi, antara lain : •
Persegi panjang dengan sudut melingkar (rounded rectangle) yang merepresentasikan proses atau pekerjaan yang harus diselesaikan.
•
Persegi (square) yang merepresentasikan agen-agen eksternal (batasan dari sistem).
•
Kotak dengan ujung terbuka (open ended box) yang merepresentasikan
penyimpanan
data
(data
store),
terkadang disebut file atau database. Penyimpanan data (data store) ini berkoresponden kepada semua instan dari sebuah entiti tunggal pada data model.
29 •
Panah yang merepresentasikan aliran data (data flow), atau input dan output, menuju dan dari proses. Komponen
Deskripsi Proses
Agen Eksternal
Data Store
Data Flow Tabel 2.3 Komponen DFD 2.1.10.2 STD(State Transition Diagram) Menurut Whitten (2004, p673), State Transition Diagram (STD)
merupakan
sebuah
tool
yang
digunakan
untuk
menggambarkan urutan dan variasi layer yang dapat terjadi ketika sesi user. Perancangan grafik antarmuka bisa diumpamakan sebagai peta jalan. Setiap layar dianalogikan sebagai kota. Tidak semua jalan
melalui
semua
kota.
Persegi
digunakan
untuk
merepresentasikan layar tampilan, panah merepresentasikan aliran kontrol dan pemicu kejadian yang menyebabkan layar menjadi aktif atau menerima focus. Persegi mendeskripsikan hanya yang dapat muncul selama dialog. Arah dari panah mengindikasikan urutan dari munculnya layar. Panah yang terpisah, masing-masing dengan label yang berbeda, digambar untuk setiap arah karena
30 pemicu aksi aliran kontrol asal yang berbeda dan aliran kontrol menuju layar yang disediakan. State Transition Diagram (STD) bisa menjadi besar, terutama ketika input, output, help dan layar lain ditambahkan ke diagram. Maka dari itu, umum jika diagram dipartisi menjadi diagram-diagram yang lebih sederhana dan mudah dibaca.
Komponen
Deskripsi Display Screen
Flow of Control dan Triggering Event Tabel 2.4 Komponen STD 2.1.11 Definisi Web Database Menurut Eaglestone (2001, p38), web database adalah sistem yang menggabungkan teknologi database dengan teknologi web. Dimana database merupakan sekumpulan data dengan berbagai tipe data yang disimpan dalam komputer dan digunakan secara efisien tanpa adanya duplikasi oleh aplikasi yang relevan. Sedangkan teknologi web menyediakan jalan untuk menyimpan dan mengakses informasi dan menjalankan program komputer yang dihubungkan dengan internet. 2.1.12 Siklus Hidup Sistem Web Database
31
The Organization
Requirements Analysis
Description of the Organization and System Requirements
Conceptual Web Database Design Data Analysis
Web Data Analysis
Conceptual Data Model
Conceptual Web Data Model
Logical Database Design
Logical Web Data Design
Logical Data Model
Logical Web Data Model
Physical Web Database Design Physical Database Design
Physical Web Data Design
Physical Web Data Model
Gambar 2.2 Web Database Design
32 Menurut Eaglestone (2001,p264), tahapan dalam metode desain sistem web database : 2.1.12.1 Requirement Analysis Pada
tahap
ini
seorang
database
designer
mulai
mengumpulkan data dari organisasi tersebut untuk menentukan apa saja yang dibutuhkan oleh organisasi tersebut dalam membentuk database yang bagus. Input
: User requirement organisasi
Output : Deskripsi keperluan sistem dan organisasi Tujuan :Membuat deskripsi database organisasi yang melayani / mendukung dan menjadi kebutuhan sistem yang baru. 2.1.12.2 Data Analysis (Conceptual Database Design) Data organisasi yang terbentuk akan dianalisis dan dideskripsikan sesuai tema yang akan direpresentasikan oleh database. Input
: Deskripsi keperluan sistem dan organisasi
Output : Data model konseptual Tujuan : Membuat deskripsi awal data tentang sesuatu (tema) dalam organisasi 2.1.12.3 Web Data Analysis Pada tahap ini data dari tahap requirements analysis akan dianalisa dan dideskripsikan berdasarkan data model konseptual yang telah dibuat.
33 Input
: Deskripsi keperluan sistem dan organisasi dan data model konseptual
Output : Data model konseptual web Tujuan :Membuat model informasi konseptual yang akan ditampilkan pada web pages, sebagaimana informasi tersebut ditampilkan di database. 2.1.12.4 Logical Database Design Proses ini menentukan model database yang bagaimana yang digunakan untuk menggambarkan data model konseptual tadi Input
: Data model konseptual
Output : Data model logikal Tujuan : Membuat model data yang menggunakan struktur yang digunakan oleh DBMS yang akan dipakai. 2.1.12.5 Logical Web Database Design Proses ini menentukan struktur data pada web page yang sebenarnya, termasuk hubungan dengan data / bagian data itu sendiri yang ada di web pages berlainan. Input
: Data model konseptual web dan logical database design
Output : Data model logikal web Tujuan : Membuat struktur data yang bisa dipakai dalam web database
34 2.1.12.6 Physical Database Design Proses ini menentukan bagaimana struktur logic dari data tersebut di dalam database dan bagaimana model data logikal dapat diimplementasikan dimana tampilan dan penggunaan sumber daya komputer dapat diterima. Input
: Data model logikal
Output : Data model fisikal Tujuan : Membuat database secara fisik 2.1.12.7 Physical Web Data Design Proses ini merancang dan menentukan bagaimana web page akan diimplementasikan dan dihubungkan ke sistem database. Input
: Data model logikal web
Output : Data model fisikal web Tujuan : Menampilkan data dalam web page dengan baik Tahapan dari analisa Web Data adalah: a. Web Data Extraction Tujuannya adalah untuk menentukan bagian dari model konseptual dari database yang berhubungan dengan aplikasi web database b. Web Data Connectivity analysis Tujuannya adalah untuk menganalisa deskripsi aplikasi web database dalam mengidentifikasi access points ke dalam sistem, dan petunjuk langkah-langkah di dalam web pages.
35 2.2 Teori Pendukung 2.2.1 Database Operasional Menurut Whitten (2004, p554), database operasional adalah sebuah database yang mendukung operasi dan transaksi harian untuk sebuah sistem informasi. 2.2.2 Shipping “Shipping is the transport of cargo between seaports by ships, typically large steel vessels powered by diesel engines or steam turbine plants”. Yang artinya adalah pengangkutan cargo antar pelabuhan laut dengan menggunakan kapal, seperti vessel baja besar yang dimotori mesin diesel atau turbin uap (http://encyclopedia.laborlawtalk.com/Shipping). 2.2.3 Tugboat “A tugboat, or tug, is a motor ship used to manoeuvre, primarily by towing, other vessels (see shipping) in harbours, over the open sea or through rivers and canals. They are also used to tow barges, disabled ships, or other equipment”. Yang artinya adalah kapal motor yang digunakan untuk manuver , terutama dengan menggandeng, vessel lain di pelabuhan, melalui laut terbuka atau melalui sungai dan kanal. Mereka juga menggunakannya untuk menggandeng barge (perahu), kapal yang rusak, atau perlengkapan lain. (Http://encyclopedia.laborlawtalk.com/Tugboat). Tugboat terdiri dari 3 kategori dasar yaitu o Tugboat standard dengan model bow yang menggandeng muatannya pada hawser (tali baja panjang atau fiber halus)
36 o Notch tug yang bisa diamankan di sebuah notch pada buritan dari sebuah barge yang didesain secara khusus, secara efektif membuat kombinasi kapal. Akan tetapi konfigurasi ini berbahaya untuk digunakan dengan barge dengan pemberat (tidak ada cargo) atau pada kepala atau mengikuti laut. Maka dari itu, notch tug biasa dibuat dengan kerekan untuk digunakan pada kondisi seperti itu, maka dari itu menggunakan kategori pertama pada kondisi tertentu. o Integral unit atau integrated unit termasuk dengan vessel yang didesain khusus yang terkunci bersama dengan metode yang kaku dan kuat seperti disertifikasi oleh orang yang berwenang (perkumpulan klasifikasi) seperti American Bureau of Shipping, Lloyd's register, atau yang lainnya. Kombinasi ini tetap bersatu pada setiap kondisi laut dan tugboat biasanya memiliki desain perawatan yang buruk untuk navigasi tanpa barge mereka terhubung. Vessel pada kategori ini secara legal dipertimbangkan sebagai
kapal
daripada
tugboat
dan
barge,
dan
harus
menunjukkan lampu navigasi dengan kapal yang dibutuhkannya ketimbang dengan tugboat dan barge yang dibutuhkan dan vessel yang digandeng. 2.2.4 Barge “A barge is a flat-bottomed boat, built mainly for river and canal transport of heavy goods”. Yang artinya adalah kapal dengan dasar rata, dibangun terutama untuk transport barang berat di sungai dan kanal.
37 Kebanyakan barge tidak dapat bergerak sendiri dan harus digerakkan menggunakan tugboat atau kapal gandeng mendorong mereka. Barge atau kanal (digandeng oleh hewan pada jalur gandeng dekat) dibatasi oleh jalur kereta api pada revolusi industri awal, akan tetapi dikalahkan oleh tunggangan dengan nilai lebih sehubungan dengan kecepatan yang lebih tinggi, biaya yang lebih rendah, dan rute yang lebih fleksibel. Barge tetap digunakan dewasa ini untuk barang dengan nilai rendah, dimana pengangkutan
barang
menggunakan
barge
lebih
rendah.
(Http://encyclopedia.laborlawtalk.com/Barge). Beberapa macam tipe dari barge : •
Barracks barge (living quarters)
•
Dry bulk cargo barge ( rock, grain, etc)
•
Liquid cargo barge( Air bersih, Minyak yang sudah jadi)
•
Railcar barge ( Dengan trek dan menggunakan fasilitas bongkar muat seperti barge slip)
•
Royal barge (ceremonial)
•
Lighter
2.2.5 Shipload “Shipload is the amount of cargo that can be held by a boat or ship or a freight car”; "he imported wine by the boatload" yang artinya adalah jumlah cargo yang dapat ditampung oleh perahu atau kapal atau mobil muat. (http://dictionary.laborlawtalk.com/shipload).
