BAB 2 TINJAUAN PUSTAKA 2.1 Teori umum Teori umum merupakan hubungan fakta dengan fakta lainnya yang bersifat umum misalnya definisi istilah-istilah umum pada topik basis data seperti DBMS, DBLC, data, system, normalisasi dan teknik pencarian data. Teori-teori ini berhubungan dengan topik dan teori pendukung dalam poembangunan aplikasi. 2.1.1 Data Menurut Connoly dan Begg (2010:70), data adalah komponen yang penting didalam lingkungan Database Management System (DBMS) yang dilihat dari sudut pandang end-user. Data bertindak sebagai jembatan antara komponen mesin dan komponen manusia. Menurut Whitten dan Bentley (2007:21), Data adalah fakta mentah tentang orang, tempat, kejadian, dan benda yang penting didalam sebuah organisasi. 2.1.2 Basis Data Menurut Connoly dan Begg. (2010:65), Basis data adalah sekumpulan data yang saling berhubungan yang secara logis dan deskripsinya, yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi 2.1.3 Database Management System (DBMS) Menurut Connoly dan Begg (2010:66) Database Management System(DBMS) adalah sebuah sistem perangkat lunak yang membolehkan pengguna untuk melakukan pendefinisian, pembuatan, pemeliharaan, dan mengontrol akses ke dalam basis data. Sederhananya DBMS adalah aplikasi yang digunakan untuk interaksi antara aplikasi pengguna dengan basis data. Ada beberapa fasilitas yang disediakan oleh DBMS, yaitu 1) Data Definition Language (DDL) DDL merupakan fasilitas yang digunakan pengguna untuk
5
6
mendefinisikan basis data, menspesifikasikan tipe data, struktur dan constraints pada data yang akan disimpan ke dalam basis data. 2) Data Manipulation Language (DML) DML
merupakan
fasilitas
yang
digunakan
pengguna
untuk
memanipulasi data seperti memasukan, menghapus, mengubah, dan mengambil data pada basis data. DML mempunyai penyimpanan data dan deskripsi data yang memperbolehkan DML untuk menyajikan fasilitas permintaan data yang disebut bahasa query. Bahasa query yang biasa digunakan disebut structured query language (SQL). 2.1.3.1 Keuntungan dan Kerugian DBMS Menurut Connoly dan Begg (2010:77), ada beberapa keuntungan penggunaan DBMS yaitu: 1) Kontrol terhadap pengulangan data 2) Data lebih konsisten 3) Dapat memperoleh informasi yang lebih dari jumlah data yang sama 4) Sharing data 5) Meningkatkan integritas data 6) Meningkatkan keamanan 7) Pengukuhan Standard 8) Economy of scale 9) Balance of conflicting requirements 10) Meningkatkan aksesbilitas data and responsiveness 11) Meningkatkan produktivitas 12) Improved maintenance through data independence 13) Increased concurrency 14) Meningkatkan kemampuan backup dan pemulihan data Selain keuntungan, menurut Connoly dan Begg (2010:80) DBMS juga memiliki kerugian, yaitu 1) Complexity 2) Size 3) Biaya DBMS 4) tambahan biaya hardware 5) Cost of conversion
7
6) kinerja 7) Risiko yang lebih tinggi 2.1.3.2 Komponen DBMS Menurut Connoly dan Begg (2010:68) DBMS memiliki 5 komponen besar pada lingkungan DBMS, yaitu 1) Hardware DBMS
dan
aplikasinya
keras(hardware)
untuk
akan berjalan.
membutuhkan Perangkat
perangkat
keras
dapat
berbentuk suatu personal computer, mainframe tunggal, sampai jaringan komputer. Perangkat keras tertentu akan bergantung pada kebutuhan organisasi beserta DBMS yang dipakai. 2) Software Komponen perangkat lunak (software) terdiri dari perangkat lunak DBMS sendiri dan program aplikasi beserta dengan sistem operasi, beserta perangkat lunak jaringan jika DBMS diakses melalui jaringan. 3) Data Data merupakan komponen paling penting dari DBMS melalui sudut pandang end-user.
Basis
data
mengandung data
operasional dan metadata yaitu ‘data mengenai data’. Struktur basis data disebut schema. 4) Procedures Prosedur adalah instruksi dan aturan yang mengendalikan perancangan dan penggunaan basis data. User dari sistem dan staff yang mengelola basis data membutuhkan prosedur yang terdokumentasi mengenai bagaimana cara menggunakan atau menjalankan sistem. 5) People Komponen terakhir adalah orang-orang yang berhubungan dengan sistem. 2.1.4 Siklus Hidup Basis Data (DBLC ) Menurut Connoly dan Begg (2010:313), sistem basis data adalah komponen dasar dari sistem informasi keseluruhan organisasi siklus hidup
8
pengembangan sistem basis data yang terikat erat pada siklus sistem informasi. Tahap-tahap database system development lifecycle tidak harus sekuensial, tetapi dapat mengulang beberapa tahap sebelumnya melalui feedback loops.
Gambar 2.1 Diagram Siklus Hidup Basis Data (Sumber: Connoly, 2010:314)
9
2.1.4.1 Database Planning Menurut Connoly dan Begg (2010:313), Perencanaan basis data (Database Planning) adalah aktivitas manajemen yang memungkinkan tahap-tahap DBLC untuk diwujudkan dengan efektif dan efisien. Perencanaan basis data harus diintegrasikan dengan strategi sistem informasi keseluruhan organisasi. Ada 3 persoalan utama dalam merumuskan strategi sistem informasi, antara lain: • Identifikasi rencana dan tujuan organisasi dengan penentuan kebutuhan sistem informasi berikut. • Evaluasi sistem informasi mutakhir untuk menentukan kekuatan dan kelemahan sistem informasi mutakhir. • Penilaian peluang teknik informatika yang mungkin dapat menghasilkan keunggulan kompetitif. Langkah pertama yang penting dalam perencanaan basis data adalah dengan mendefinisikan mission statement untuk sistem basis data. Mission statement mendefinisikan tujuan utama sistem basis data. Langkah kedua adalah dengan mendefine mission objective. tiap mission objective harus mengidentifikasi suatu tugas spesifik yang harus didukung sistem basis data. Perencanaan basis data juga harus memasukan pengembangan standar yang mengatur bagaimana data dikumpulkan, bagaimana cara menspesifikasi format, dokumentasi apa yang dibutuhkan, dan bagaimana alur perancangan dan implementasi. 2.1.4.2 System Definition Menurut Connoly dan Begg (2010:316) Definisi sistem (System Definition) mendeskripsikan lingkup dan batasan aplikasi basis data dan user view utama. Sebelum merancang sistem basis data, harus dilakukan pengidentifikasian batasan sistem yang akan diinvestigasi dan bagaimana sistem tersebut berantarmuka dengan bagian lain sistem informasi organisasi.
10
User view mendefinisikan apa yang dibutuhkan dari sistem basis data dari sudut pandang sebuah peran kerja(seperti manajer atau supervisor) atau area aplikasi organisasi(seperti marketing, personil, atau pengaturan saham). Sistem basis data mungkin memiliki satu atau lebih user view. Mengidentifikasi
user
view
adalah
aspek
penting
dalam
mengembangkan sistem basis data karena dapat memastikan bahwa tidak ada user utama yang dilupakan dalam mengembangkan kebutuhan untuk sistem basis data baru. 2.1.4.3 Requirement Collection and Analysis Menurut Connoly dan Begg (2010:316) Pengumpulan dan analisa kebutuhan (Requirement Collection and Analysis) adalah proses mengumpulkan dan menganalisa informasi mengenai bagian organisasi yang didukung oleh sistem basis data, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan untuk sistem baru. Informasi dikumpulkan untuk tiap user view utama (yaitu, peran kerja atau area aplikasi organisasi), antara lain: • Deskripsi data yang akan dipakai atau dibuat. • Detail bagaimana data akan dipakai atau dibuat. • Kebutuhan tambahan apapun untuk sistem basis data baru. Informasi
tersebut
kemudian
akan
dianalisa
untuk
mengidentifikasi kebutuhan sistem basis data baru. Kebutuhankebutuhannya akan dikumpulkan pada sebuah dokumen bernama requirements specifications untuk sistem basis data baru. Jumlah data yang dikumpulkan tergantung oleh sifat masalah dan kebijakan organisasi. Informasi yang dikumpulkan pada tahap ini akan tidak terstruktur dengan baik dan mungkin mengandung permintaan tak resmi. Informasi tersebut harus diubah menjadi bentuk yang terstruktur
dengan
menggunakan
requirements
specification
techniques, misalnya: Teknik Structured Analysis and Design (SAD), Data Flow Diagrams (DFD), dan grafik Hierarchical Input Process Output (HIPO) yang didukung oleh dokumentasi.
11
Mengidentifikasi fungsionalitas yang dibutuhkan oleh sistem basis data adalah aktivitas penting, karena sistem dengan fungsionalitas tak lengkap akan mengganggu user sedangkan sistem dengan kebanyakan fungsionalitas akan membuat sistem sulit dipelajari oleh user. Ada 3 pendekatan utama untuk mengelola kebutuhan sistem basis data dengan banyak user view, antara lain: a) Pendekatan terpusat (centralized).
Gambar 2.2 pendekatan terpusat (Centralized) (Sumber: Connoly, 2010:319) Kebutuhan untuk setiap user view digabung menjadi kumpulan kebutuhan tunggal untuk sistem basis data baru. Data model yang mewakili semua user view dibuat pada tahap perancangan basis data. Pendekatan ini dipilih jika ada tumpang tindih kebutuhan yang signifikan dan sistem basis data tidak terlalu rumit.
12
b) Pendekatan view integration
Gambar 2.3 pendekatan view integration (Sumber: Connoly, 2010:320) Kebutuhan untuk setiap user view dipisah sebagai daftar berbeda. Data model yang mewakili tiap user view dibuat dan digabung pada tahap perancangan basis data. Pendekatan ini dipilih jika ada perbedaan signifikan antara user view dan sistem basis data cukup rumit. Untuk beberapa sistem basis data yang rumit dapat digunakan pendekatan yang merupakan kombinasi pendekatan terpusat dan view integration untuk mengelola banyak user view. Contohnya, kebutuhan 2 atau lebih user view bisa digabung dengan pendekatan terpusat menjadi data model logikal dan kemudian digabung dengan data model logikal lain dengan pendekatan view integration. Pada situasi ini, tiap data model logikal mewakili kebutuhan 2 atau lebih user view dan data model logikal terakhir mewakili kebutuhan semua user view di sistem basis data. 2.1.4.4 Database Design Menurut Connoly dan Begg (2010:320), Perancangan basis data (Database Design) merupakan sebuah proses pembuatan
13
sebuah rancangan yang akan mendukung pernyataan dan tujuan misi organisasi yang diperlukan dari sebuah sistem basis data. Perancangan basis data memiliki dua buah pendekatan, yaitu: 1. Bottom-up Pendekatan dimulai pada level fundamental dari atribut-atribut (yaitu, property dari entitas dan hubungan-hubungannya), yang kemudian
melalui
analisis
dari
asosiasi
antar
atribut,
dikelompokkan dalam relasi-relasi yang menunjukkan tipe dari entitas dan hubungan antar entitas. 2. Top-down Pendekatan ini diawali dengan pengembangan model data yang mengandung beberapa entitas tingkat tinggi dan relasinya untuk kemudian mengaplikasikan successive top-down refinements untuk mengidentifikasikan entitas tingkat bawah, relasinya, dan atribut-atribut
yang
terasosiasi.
Pendekatan
Top-down
diilustrasikan dengan menggunakan konsep model diagram relasi entitas (Entity-Relationship (ER) Model), dimulai dengan identifikasi dari entitas dan hubungan antar entitas, yang dianggap berhubungan dengan organisasi. Perancangan basis data terdiri dari tiga tahap utama, yaitu: 1. Perancangan Basis Data Konseptual (Conceptual Database design) Menurut Connoly dan Begg (2010: 322), perancangan basis data konseptual merupakan proses pembangunan sebuah model dari data yang digunakan pada sebuah enterprise, tidak tergantung pada segala pertimbangan fisik. Berdasarkan Connoly dan Begg (2010:470), Langkah-langkah dalam pembuatan desain basis data konseptual adalah: Langkah 1:
Membangun model data konseptual Langkah pertama dalam perancangan basis data konseptual adalah untuk membangun satu (atau lebih) model data konseptual dari data yang diperlukah
oleh
organisasi.
Model
data
konseptual juga didukung oleh dokumentasi,
14
meliputi ERD dan kamus data, yang dihasilkan sepanjang pengembangan model. Langkah 1.1: Identifikasi tipe entitas Merupakan langkah pertama dalam pembangunan model
data
konseptual.
Bertujuan
untuk
mengindentifikasi tipe entitas yang diperlukan dan mendefinisikan objek-objek utama yang dibutuhkan oleh user. Objek-objek ini merupakan tipe entitas untuk model data. Langkah 1.2: Identifikasi tipe relasi Setelah
menentukan
tipe
entitas,
langkah
berikutnya adalah untuk mengidentifikasi semua relasi penting yang terdapat antar entitas. Saat mengidentifikasi
sebuah
entitas,
salah
satu
metode yang digunakan adalah untuk mencari kata kerja atau ekspresi verbal dari spesifikasi kebutuhan
user.
PropertyForRent,
Contoh:
Staff
Manages
PrivateOwner
Owns
PropertyForRent, PropertyForRent Associated With Lease. Langkah 1.3: Mengidentifikasi dan mengasosiasikan attributatribut dengan entitas atau tipe hubungan. Bertujuan untuk mengasosiasikan atribut-atribut dengan entitas atau tipe relasi yang tepat. Terdapat tiga jenis atribut yaitu: a. Simple/composite attributes b. Single/multi-valued attributes c. Derived attributes Langkah 1.4: Menentukan domain atribut Tujuan dari langkah ini adalah untuk menentukan domain dari seluruh atribut yang terdapat dalam model data konseptual. Sebuah domain adalah kumpulan nilai-nilai dimana satu atau lebih atribut mengambil nilainya
15
. Sebuah model data yang telah dikembangkan secara utuh menspesifikasikan domain dari setiap atribut dan mencakup: a. Kumpulan nilai yang diizinkan bagi atribut b. Format dan ukuran dari atribut Langkah 1.5: Menentukan atribut candidate, primary, dan alternate key Langkah
ini
memiliki
tujuan
untuk
mengidentifikasi sebuah candidate key(s) untuk sebuah entitas dan kemudian memilih salah satunya sebagai primary key, jika terdapat lebih dari satu candidate key, yang tidak terpilih sebagai primary key disebut sebagai alternate key. Dalam pemilihan candidate key sebagai primary key, dapat digunakan pedoman: a. Candidate key yang memiliki kumpulan atribut yang minimal; b. Kecil kemungkinan perubahan nilai dari candidate key yang akan dipilih; c. Candidate key dengan jumlah teks terkecil (jika bertipe teks); d. Candidate key dengan nilai numeric maksimal terkecil (jika bertipe numeric); e. Candidate key yang paling mudah digunakan menurut pandangan user. Langkah 1.6: Mempertimbangkan
penggunaan
enhanced
modeling concept (langkah optional) Bertujuan untuk mempertimbangkan penggunaan enhanced
modeling
concept,
seperti
specialization/generalization, aggregation, dan composition dalam kelanjutan pengembangan ERD. Jika memilih pendekatan specialization, perlu digaris
bawahin
perbedaan-perbedaan
antar
16
entitas dengan mendefinisikan satu atau lebih subclasses dari sebuah entitas superclass. Jika menggunakan pendekatan generalization, dilakukan pengidentifikasian
common features
antar entitas untuk mengidentifikasikan sebuah entitas generalzing superclass. Selain itu juga dapat menggunakan aggregation untuk merepresentasikan sebuah relasi ‘memiliki’ atau ‘bagian dari’ antar tipe entitas, dimana salah satu
merepresentasikan
‘seluruh’
dan
yang
lainnya ‘bagian’. Dan
juga
(sebuah
dapat tipe
menggunakan
aggregation
composition
khusus)
untuk
merepresentasikan sebuah asosiasi antar tipe entitas dimana terdapat sebuah kepemilikan yang kuat dan waktu hidup yang bersinggungan antar ‘seluruh’ dan ‘bagian’ Langkah 1.7: Memeriksa model untuk redundansi Pada langkah ini, dilakukan pengamatan model data konseptual dengan tujuan spesifik untuk mengidentifikasi apakah terdapat redundansi dan menghilangkannya jika memang ditemukan. Tiga aktivitas dari bagian ini adalah: a. Mengamati ulang relasi one-to-one (1:1) Pada identifikasi entitas, dapat ditemukan dua entitas yang merepresentasikan sebuah objek yang sama dalam organisasi. Jika kedua entitas memiliki primary key yang berbeda, pilihlah salah satu untuk menjadi primary key dan biarkan yang lain untuk menjadi alternate key. b. Menghilangkan relasi yang redundan Sebuah relasi dapat dikatakan redundan jika informasi yang sama dapat diperoleh melalui relasi lain. Dikarenakan dilakukan pengembangan
17
sebuah model data minimal dan relasi redundan tidak dibutuhkan sehingga harus dihilangkan. c. Mempertimbangkan dimensi waktu Sebuah dimensi waktu dari relasi merupakan hal penting saat memeriksa redundansi. Contohnya, saat dicoba pengujian sebuah situasi dimana dibuat model relasi dari entitas pria, wanita, dan anak. Jelas terdapat dua hubungan antara pria dan anak: satu melalui relasi langsung ayah dan yang lainnya melalui relasi menikah dengan ibu. Langkah 1.8: Validasi
model
data
konseptual
terhadap
transaksi user Setelah memiliki sebuah model data konseptual yang merepresentasikan kebutuhan data dari sebuah organisasi. Tujuan dari langkah ini adalah untuk memastikan bahwa model data konseptual mendukung transaksi yang diperlukan oleh user. Menggunakan model data konseptual, dapat dicoba melakukan operasi secara manual. Jika dapat diselesaikan transaksi dengan cara ini, telah dilakukan
pemeriksaan
bahwa
model
data
konseptual telah mendukung transaksi yang diperlukan. Namun, jika transaksi tidak dapat diselesaikan secara manual pasti terdapat sebuah masalah
dalam
model
data
yang
harus
diselesaikan. Pada kasus ini, mungkin telah dilewatkan sebuah entitas, sebuah relasi, ataupun sebuah atribut dari model data. Terdapat dua pendekatan
untuk
memastikan
model
konseptual mendukung transaksi yaitu: a. Mendeskripsikan transaksi b. Menggunakan lajur transaksi
data
18
Langkah 1.9: Review conceptual data model with user. Bertujuan untuk mengkaji ulang model data konseptual dengan user untuk memastikan bahwa user menganggap model data konseptual sebagai gambaran ‘nyata’ dari kebutuhan data organisasi. Model data konseptual melingkupi ERD dan dokumentasi yang mendukung deskripsi dari model data. Jika terdapat kejanggalan pada model data, harus dilakukan perubahan
yang tepat,
dapat memerlukan pengulangan dari langkahlangkah sebelumnya. Proses ini terus diulang hingga user menganggap model data sebagai gambaran ‘nyata’ dari kebutuhan data organisasi. 2. Perancangan Basis Data Logikal (Logical Database Design) Menurut Connoly dan Begg (2010:323), perancangan basis data logikal adalah proses konstruksi sebuah model data yang digunakan pada enterprise berdasarkan sebuah model data yang spesifik, tetapi terlepas dari DBMS tertentu dan pertimbangan fisik lainnya Model data konseptual yang diciptakan pada tahap sebelumnya dikembangkan dan dipetakan pada model data logikal. Model data logikal didasarkan kepada tujuan model data untuk basis data yang digunakan. Sepanjang proses pengembangan sebuah model data logikal, model diuji kembali dan divalidasikan dengan kebutuhan user. Pada umumnya digunakan teknik normalisasi (Normalization) untuk memeriksa kebenaran dari sebuah model data logikal. Connoly dan Begg (2010:490) menuliskan langkah langkah pembuatan model data logikal, yaitu: Langkah 2:
Membangun dan melakukan validasi model data logikal Bertujuan untuk melakukan translasi dari model data konseptual menjadi model data logikal dan untuk kemudian melakukan validasi model ini
19
untuk memeriksa apakah model sudah terstruktur secara tepat dan dapat mendukung transaksi yang dibutuhkan. Langkah 2.1: Menurunkan relasi untuk model data logikal Pada langkah ini, diturunkan relasi untuk model data logikal guna merepresentasikan entitas, relasi dan atribut-atribut. Sebuah relasi yang memiliki sebuah entitas dengan entitas lain direpresentasikan primary
menggunakan
key/foreign
mendeskripsikan
key.
Dan
bagaimana
mekanisme juga
untuk
relasi
akan
diturunkan untuk struktur berikut yang dapat terjadi pada sebuah model data konseptual: 1. Strong entity types; 2. Weak entity types; 3. One-to-many (1:*) binary relationship types; 4. One-to-one (1:1) binary relationship types; 5. One-to-one (1:1) recursive relationship types; 6. Superclass/subclass relationship types; 7. Many-to-many (*:*) binary relationship types; 8. Complex relationship types; 9. Multi-valued attributes. Langkah 2.2: Validasi relasi menggunakan normalisasi Pada langkah sebelumnya, telah diturunkan sebuah kumpulan relasi yang menggambarkan model data konseptual. Pada langkah ini, dilakukan
pengvalidasian
pengumpulan
dari
atribut di setiap relasi menggunakan aturan normalisasi. Tujuan dari normalisasi adalah untuk memastikan
bahwa kumpulan dari relasi
memiliki jumlah yang minimal namun memiliki atribut yang cukup untuk mendukung data yang dibutuhkan organisasi. Proses normalisasi terdiri dari:
20
1. Unnormalized form (UNF) 2. First normal form (1NF) 3. Second normal form (2NF) 4. Third normal form (3NF) Sangat dianjurkan untuk melakukan proses normalisasi hingga third normal form untuk mencegah terdapatnya data yang redundan. Langkah 2.3: Validasi relasi terhadap transaksi user Tujuan dari langkah ini adalah untuk melakukan validasi model data logikal untuk memastikan model
telah
mendukung
transaksi
yang
dibutuhkan. Menggunakan model data logikal, dapat dicoba untuk melakukan operasi secara manual. Jika dapat menyelesaikan transaksi dengan
cara
ini,
maka
telah
dilakukan
pemeriksaan bahwa model data logikal telah mendukung transaksi yang diperlukan. Namun, jika transaksi tidak dapat diselesaikan secara manual pasti terdapat sebuah masalah dalam model data yang harus diselesaikan. Pada kasus ini, besar kemungkinan kesalahan terjadi saat pembuatan relasi dan harus kembali memeriksa daerah dari model data yang diakses transaksi untuk
mengidentifikasi
dan
menyelesaikan
masalah ini. Langkah 2.4: Memeriksa batasan integritas Sebuah batasan integritas adalah sebuah batasan yang ingin diterapkan dengan maksud untuk melindungi basis data dari sebuah kejadian dimana basis data menjadi tidak lengkap, tidak akurat,
atau
tidak
konsisten.
Langkah
ini
bertujuan untuk memeriksa batasan integritas yang digambarkan pada model data logikal.
21
Terdapat tipe-tipe batasan integritas yang harus dipertimbangkan, yakni: a. Data yang dibutuhkan; b. Batasan domain atribut; c. Kelipatan (Multiplicity); d. Integritas dari entitas; e. Integritas dari referensi; f. Batasan umum. Langkah 2.5: Mengkaji ulang model data logikal dengan user Memiliki tujuan untuk melakukan kajian ulang dari model data logikal dengan user untuk memastikan bahwa user menganggap model data logikal
sebagai
representasi
‘nyata’
dari
kebutuhan data organisasi. Langkah 2.6: Menggabungkan model data logikal menjadi model global (langkah opsional) Bertujuan untuk menggabungkan model data logikal lokal menjadi sebuah model data logikal global
yang
merepresentasikan
pandangan
seluruh user terhadap sebuah basis data. Langkah 2.7: Memeriksa pertumbuhan masa depan Perancangan model data logikal diakhiri dengan pertimbangan apakah model data logikal sanggup dikembangkan untuk mendukung kemungkinan perkembangan di masa depan. Langkah ini bertujuan untuk menentukan apakah akan ada perubahan yang signifikan di masa depan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan-perubahan tersebut. 3. Perancangan Basis Data Fisikal (Physical Database Design) Menurut Connoly dan Begg (2010:324), perancangan basis data fisikal merupakan sebuah proses produksi sebuah deskripsi dari implementasi sebuah basis data pada tempat penyimpanan sekunder; Perancangan basis data fisikal mendeskripsikan
22
hubungan dasar , organisasi file, dan index yang digunakan untuk mencapai akses yang efisien kepada data, dan batasan integritas yang terasosiasi serta langkah-langkah keamanan. Dalam mengembangkan perancangan basis data fisikal, hal pertama yang harus dilakukan adalah identifikasi target DBMS. Karena itu, perancangan fisik disesuaikan untuk sistem DBMS tertentu. Menurut Connoly dan Begg (2010:523), langkah-langkah dalam perancangan basis data fisikal adalah: Langkah 3:
Menerjemahkan model data logikal pada DBMS tujuan Kegiatan pertama dari perancangan basis data fisikal melibatkan penerjemahan dari model data logikal menjadi sebuah bentuk yang dapat diimplementasikan kepada relational DBMS yang dituju. Bagian pertama dari proses ini mencakup mengumpulkan informasi yang diperoleh dari perancangan basis data logikal dan dokumentasi dari kamus data serta informasi yang didapat dari pengumpulan kebutuhan dan tahap analisa dan dokumentasi yang terdapat pada spesifikasi sistem. Bagian kedua menggunakan informasi pada bagian pertama untuk merancang relasi dasar.
Langkah 3.1: Merancang relasi dasar Untuk memulai proses perancangan fisikal, pertama harus mengumpulkan dan mengasimilasi informasi tentang relasi yang dihasilkan pada tahap perancangan basis data logikal. Informasi dapat diperoleh dari kamus data dan definisi relasi yang dideskripsikan oleh database design language (DDL). Langkah 3.2: Merancang representasi dari data turunan
23
Memiliki tujuan untuk memutuskan bagaimana data turunan yang terdapat pada model data logikal akan direpresentasikan pada DBMS tujuan. Atribut turunan adalah atribut yang nilainya dapat ditemukan dengan mengamati nilai dari atribut lain. Berikut adalah contoh atribut turunan: 1. Jumlah pekerja pada cabang tertentu 2. Jumlah gaji dari seluruh pekerja 3. Jumlah properti yang ditangani oleh seorang pekerja Langkah 3.3: Merancang batasan umum Bertujuan untuk merancang batasan umum yang akan diterapkan pada DBMS tujuan. Rancangan dari batasan umum pada umumnya dianjurkan untuk didokumentasi. Dan juga dokumentasikan alasan dari pendakatan yang dipilih. Langkah 4:
Merancang organisasi file dan indeks Bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks-indeks yang diperlukan untuk mencapai performa yang dapat diterima, yaitu, sebuah jalan dimana relasi-relasi dan tuples akan disimpan pada tempat penyimpanan sekunder
Langkah 4.1: Analisa transaksi Analisa transaksi bertujuan untuk memahami fungsionalitas dari transaksi-transaksi yang akan dijalankan pada basis data dan untuk menganalisa transaksi yang penting. Pada tahap analisa transaksi, dilakukan pengidentifikasian kriteria performa, seperti: 1. Transaksi yang paling sering berjalan dan memiliki dampak besar pada performa;
24
2. Transaksi yang sangat penting bagi operasi bisnis; 3. Waktu dalam hari atau minggu dimana akan terjadi permintaan tinggi pada basis data (peak load) Langkah 4.2: Choose file organizations Bertujuan untuk menentukan sebuah organisasi file yang efisien bagi setiap relasi dasar. Berikut adalah
beberapa
contoh
organisasi
file
berdasarkan tipe file: 1. Heap 2. Hash 3. Indexed Sequential Access Method (ISAM) 4. B+ -tree 5. Clusters. Langkah 4.3: Memilih indeks Bertujuan
untuk
menambahkan
menentukan
indeks
akan
apakah
meningkatkan
performa dari sistem. Langkah 4.4: Memperkirakan disc space yang dibutuhkan Dapat
merupakan
sebuah
kebutuhan
implementasi basis data fisikal untuk dapat ditangani oleh konfigurasi perangkat keras yang digunakan.
Bertujuan
untuk
memperkirakan
jumlah disc space yang akan dibutuhkan oleh basis data. Langkah 5:
Merancang tampilan user Bertujuan untuk merancang tampilan user yang sudah diidentifikasikan pada tahap pengumpulan kebutuhan dan tahap analisa dari DBLC.
Langkah 6:
Merancang mekanisme keamanan Sebuah
basis
data
menggambarkan
sebuah
resource organisasi yang sangat penting sehingga keamanan dari resource ini sangatlah penting.
25
Perancangan mekanisme keamanan bertujuan untuk merancang sebuah mekanisme keamanan untuk basis data seperti yang telah diminta oleh user pada saat tahap pengumpulan
kebutuhan
dan
umumnya
DBLC.
DBMS
relasional
menyediakan dua jenis keamanan database: 1. Keamanan sistem Mencakup penggunaan dan akses dari basis data pada tingkat sistem, seperti username dan password. 2. Keamanan data Mencakup penggunaan dan akses dari objek basis data (seperti relasi dan tampilan) dan aksi yang dapat dilakukan user terhadapnya. 2.1.4.5 DBMS Selection Menurut Connoly dan Begg (2010:325), Pemilihan DBMS (DBMS selection) adalah proses pemilihan DBMS yang paling tepat untuk mendukung sistem basis data.
Gambar 2.4 Arsitektur Data Modeling dan ANSI-SPARC (Sumber: Connoly, 2010:325)
26
Langkah-langkah utama memilih DBMS: 1.
Tentukan kerangka acuan (Terms of reference) dari penelitian. Kerangka acuan untuk seleksi DBMS ditetapkan, menyebutkan tujuan dan lingkup studi, dan tugas yang perlu dilakukan. Dokumen ini juga mengandung deskripsi kriteria untuk mengevaluasi produk DBMS, daftar pendahuluan semua produk yang mungkin dan semua batasan dan skala waktu penelitian.
2.
Shortlist dua atau tiga produk. Kriteria yang dianggap paling penting dalam implementasi dapat digunakan untuk menghasilkan daftar pendahuluan produk
DBMS
untuk
evaluasi.
Setelah
penelitian
fungsionalitas dan fitur yang dimiliki produk DBMS sebuah shortlist yang terdiri dari dua atau tiga produk dapat dihasilkan sehingga dapat dilihat fitur-fitur dan fungsionalitas DBMS dengan menggunakan internet. 3.
Evaluasi Produk Ada bermacam-macam fitur yang bisa digunakan untuk mengevaluasi produk DBMS. Untuk penelitian, fitur-fitur tersebut bisa dinilai sebagai kelompok atau dinilai secara individu.
4.
Rekomendasikan Pilihan dan Hasilkan Laporan Langkah
terakhir
pemilihan
DBMS
adalah
untuk
mendokumentasikan proses dan menyediakan pernyataan mengenai penemuan dan rekomendasi untuk suatu produk DBMS. 2.1.4.6 Application Design Menurut Connoly dan Begg (2010:329), Merancang aplikasi (application design) adalah perancangan antarmuka user dan program aplikasi yang menggunakan dan memproses basis data. Dilakukan pemeriksaan bahwa semua fungsionalitas di spesifikasi kebutuhan user ada di rancangan aplikasi sistem basis data. Hal ini dilakukan dengan merancang program aplikasi yang
27
mengakses basis data dan merancang transaksinya. Selain merancang transaksi juga harus dirancang antarmuka user yang tepat. 2.1.4.7 Transaction Design Menurut Connoly dan Begg (2010:324), transaksi adalah tindakan atau serangkaian tindakan yang dilakukan oleh seorang user atau program aplikasi, yang mengakses atau mengubah isi basis data. Tujuan perancangan transaksi adalah untuk mendefinisikan dan mendokumentasikan karakteristik tingkat tinggi transaksi yang dibutuhkan basis data, antara lain: data yang akan dipakai oleh transaksi karakteristik fungsional transaksi hasil transaksi kepentingan bagi user laju penggunaan yang diharapkan. Ada 3 tipe transaksi: transaksi retrieval, transaksi update, dan transaksi campuran: 1. Transaksi retrieval digunakan untuk mengembalikan data untuk ditampilkan pada laporan. 2. Transaksi update digunakan untuk memasukan record baru, menghapus record lama, atau memodifikasi record yang sudah ada di basis data. 3. Transaksi Campuran menggabungkan transaksi retrieval dan update. 2.1.4.8 User Interface Design Guidelines Sebelum merancang antarmuka terdapat beberapa pedoman yang dapat digunakan, diantaranya sebagai berikut: 1.
Judul bermakna Informasi yang diberikan oleh judul harus jelas dan secara tidak ambigu mengidentifikasi tujuan form/report.
2.
Instruksi yang dapat dipahami Penggunaan istilah-istilah yang dikenal luas untuk memberikan instruksi ke user. Instruksinya harus singkat, dan help screen
28
harus ditampilkan jika informasi tambahan dibutuhkan. Instruksi harus ditulis dengan gaya tatabahasa yang konsisten dengan format standar. 3.
Pengelompokan logis dan pengurutan field Field yang berhubungan harus diposisikan bersama dalam form/report. Pengurutan field harus logikal dan konsisten
4.
Susunan form/report yang enak dilihat Form/report harus menyediakan antarmuka yang menarik untuk user. Form/report harus kelihatan seimbang dengan field atau kumpulan field diposisikan dengan seimbang dalam form/report. Penampilan bentuk hardcopy harus konsisten dengan yang softcopy.
5.
Label field yang dikenal Field label harus mudah dikenal.
6.
Penggunaan singkatan dan terminologi yang konsisten Penggunaan singkatan dan terminologi dengan konsisten.
7.
Penggunaan warna yang konsisten Warna dapat digunakan untuk meningkatkan tampilan form/report dan untuk menyoroti field dan pesan-pesan yang penting. Pengunaan warna harus konsisten dan bermakna.
8.
Spasi dan batasan yang tampak untuk field pengisian data User harus dapat menyadari jumlah spasi yang ada untuk tiap field. Hal ini memungkinkan user untuk memikirkan format data yang cocok.
9.
Gerakan kursor yang tak menyusahkan User harus dapat dengan mudah mengidentifikasi operasi yang dibutuhkan untuk menggerakan kursor dalam form/report.
10. Koreksi error untuk karakter individu dan seluruh field User harus bisa dengan mudah mengidentifikasi operasi yang dibutuhkan untuk membuat perubahan pada nilai field. 11. Pesan error untuk nilai yang tak boleh dimasukan Jika seorang user ingin memasukan data yang salah pada field, pesan error harus ditampilkan. Pesannya harus memberitahu
29
user mengenai kegalatan dan mengindikasikan nilai yang boleh dimasukan. 12. Field yang opsional harus diberi tanda Field yang opsional harus ditandai untuk user. Field yang opsional harus ditempatkan setelah field yang wajib diisi. 13. Pesan yang menjelaskan untuk field Ketika user menempatkan kursor pada field, informasi mengenai field harus muncul pada posisi biasa. 14. Tanda selesai Setelah user selesai mengisi field harus disertai tanda yang memberitahu selesainya pengisian data. Proses penyelesaian tidak boleh otomatis agar user mendapat kesempatan untuk mengulas data yang baru dimasukan. 2.1.4.9 Prototyping Menurut Connoly dan Begg (2010:333), Prototyping adalah membuat model basis data yang dapat digunakan tetapi tidak memiliki fitur yang lengkap. Tujuan utama mengembangkan purwarupa sistem basis data adalah untuk memungkinkan user yang menggunakan prototype untuk mengidentifikasi fitur yang bekerja dengan baik, atau buruk, dan jika mungkin menyarankan fitur baru pada sistem basis data. Ada 2 strategi prototyping yang sering digunakan sekarang yaitu Requirements Prototyping dan Evolutionary Prototyping. Requirements
Prototyping
menggunakan
prototype
untuk
menentukan kebutuhan basis data dan setelah kebutuhan lengkap, prototype akan dibuang. Evolutionary Prototyping, digunakan untuk hal yang sama, perbedaannya adalah prototype tidak dibuang tetapi dikembangkan menjadi basis data yang final. 2.1.4.10 Implementation Menurut Connoly dan Begg (2010:333), Implementasi adalah realisasi fisik basis data dan rancangan aplikasi. Setelah penyelesaian tahap perancangan, basis data dan program aplikasi dapat diimplementasi. Implementasi basis data digunakan dengan menggunakan DDL (Data Definition Language) dan implementasi
30
aplikasi digunakan dengan menggunakan bahasa pemrograman generasi 3 dan 4. 2.1.4.11 Data Conversion and Loading Menurut Connoly dan Begg (2010:334), Konversi data dan muatan (data conversion and loading) adalah memindahkan data yang sudah ada ke basis data yang baru dan mengubah aplikasi yang sudah ada untuk menjalankan basis data yang baru. Hal ini hanya dilakukan jika mengganti sistem yang lama. 2.1.4.12 Testing Menurut Connoly dan Begg (2010:334), testing adalah proses menjalankan sistem basis data dengan tujuan menemukan error. Sebelum dijalankan, sistem basis data harus sudah diuji secara menyeluruh. Hal ini dicapai dengan menggunakan strategi pengujian dan data realistis supaya seluruh proses diuji dengan metodis dan teliti. Pengujian juga harus mencakup kegunaan sistem basis data. Secara ideal, evaluasi harus dijalankan untuk menguji kegunaan sistem basis data. Contoh kriteria yang bisa digunakan untuk menguji adalah sebagai berikut (Sommerville:2002): • Learnability: Berapa lama sebelum user bisa menjadi produktif dengan sistem. • Performance: Sebaik mana sistem mengikuti kegiatan kerja user. • Robustness: Setahan mana sistem terhadap user error. • Recoverability: Sebaik mana sistem bisa pulih dari user error. • Adaptability: Seterikat mana sistem terhadap suatu model kerja. 2.1.4.13 Operational Maintenance Menurut
Connoly
dan
Begg
(2010:335),
pengelolaan
operasional (operational maintenance) adalah proses memonitor dan mengelola sistem basis data setelah instalasi. Tahap pengelolaan terbagi menjadi dua aktivitas, antara lain: 1. Mengawasi jalannya sistem. Jika performa menurun sampai tingkat yang tak dapat diterima, maka mungkin butuh tuning atau reorganisasi basis data
31
2. Mengelola
dan
meningkatkan
sistem
basis
data(jika
dibutuhkan). Kebutuhan baru digabungkan pada sistem basis data melalui tahap-tahap sebelumnya. 2.1.5 Entity Relationship Model Menurut Connoly dan Begg (2010:371), model relasi entity (entity relationship model) adalah pendekatan desain basis data secara top-down yang dimulai dengan mengidentifikasi data yang disebut dengan entitas dan relasi antar data yang direpresentasikan dalam bentuk model. 2.1.5.1 Entity Type Menurut Connoly dan Begg (2010:372), tipe entitas (entity type) adalah kumpulan objek-objek yang memiliki sifat yang sama, yang diidentifikasi oleh organisasi dengan memiliki eksistensi yang tidak memiliki ketergantungan. Entity type dapat dikelompokkan menjadi 2 yaitu: 1) Strong Entity Strong Entity adalah tipe entitas yang entitasnya tidak bergantung dengan entitas lainnya 2) Weak Entity Weak Entity adalah tipe entitas yang entitasnya bergantung pada beberapa entitas lainnya. 2.1.5.2 Relationship Type Menurut Connoly dan Begg (2010:374),
tipe relasi
(relationship type) adalah kumpulan relasi yang memiliki makna antar entitas. Setiap tipe relasi memiliki nama yang menjelaskan fungsinya.
32
Gambar 2.5 Contoh Relationship type (Sumber: Connoly, 2010:376) Relationship occurance adalah suatu hubungan yang dapat diidentifikasi secara unik meliputi satu kejadian dari masingmasing entitas. 2.1.5.3 Attribute Menurut Connoly dan Begg (2010:379), atribut adalah properti dari sebuah entitas atau relasi. Menurut Whitten dan Bentley (2007:272) atribut adalah deskripsi properti atau karateristik dari sebuah entitas Menurut Connoly dan Begg (2010:379), atribut domain adalah banyaknya nilai yang diijinkan untuk satu atau lebih atribut. Domain dapat diartikan sebagai jumlah yang dapat diisi oleh atribut. Atribut dapat dibagi menjadi 5, yaitu 1. Simple Attribute adalah atribut yang terdari dari satu komponen yang independen. Atribut sederhana tidak dapat dibagi lagi menjadi komponen yang lebih kecil. Contohnya atribut sederhana ada pada atribut position dan salary pada entitas Staff. Terkadang disebut juga dengan atomic attributes. 2. Composite Attribute adalah atribut yang terdari dari banyak komponen yang tiap atributnya tidak saling bergantung. Sebagai contoh, atribut address pada entitas Branch dengan nilai (163 Main St, Glasgow, G11 9QX) bisa dibagi menjadi atribut street
33
(163 Main St), atribut city (Glasgow), dan atribut postcode (G11 9QX) 3. Single-Valued Attribute adalah atribut yang memiliki nilai tunggal untuk tiap kejadian dari sebuah entitas. 4. Multi-Valued Attribute adalah atribut yang memiliki beberapa nilai untuk tiap kejadian dari sebuah entitas. Sebagai contoh, pada entitas Branch bisa memiliki beberapa nilai untuk atribut telno. 5. Derived Attribute adalah atribut yang direpresentasikan dari sebuah nilai yang turun dari nilai atribut yang terkait atau kumpulan atribut. Sebagai contoh, nilai dari atribut duration pada entitas lease berasal dari hasil perhitungan rentstart dan rentfinish. 2.1.5.4 Keys 1 Super Key Menurut Connoly dan Begg (2010:150), super key adalah sebuah atribut atau sekumpulan atribut yang mengidentifikasi suatu tuple secara unik dalam sebuah relasi. 2 Candidate Key Menurut Connoly dan Begg (2010:381), candidate key adalah kumpulan atribut yang dikenal secara unik pada entitas. 3 Primary Key Menurut Connoly dan Begg (2010:381), primary key adalah candidate key yang dipilih untuk mengidentifikasi secara unik suatu entitas 4 Composite Key Menurut Connoly dan Begg (2010:382), composite key adalah candidate key yang terdiri dari dua atau lebih atribut. 5 Foreign Key Menurut Connoly dan Begg (2010:151), foreign key adalah sebuah atribut atau kumpulan atribut yang dalam satu relasi cocok dengan candidate key dari beberapa relasi
34
6 Alternate Key Menurut Connoly dan Begg (2010:151), alternate key adalah candidate key yang tidak terpilih menjadi primary key. 2.1.5.5 Structural Constraints Menurut Connoly dan Begg (2010:385), constrains seharusnya merefleksikan batasan pada sebuah relationship yang sesuai dengan dunia nyata. Hal utama dari constraints pada relationship disebut multiplicity. Menurut Connoly dan Begg (2010:385), multiplicity adalah jumlah (atau jarak) dari kemungkinan suatu kejadian yang berhubungan dengan kejadian tunggal dari jenis entity yang terkait melalui suatu hubungan tertentu. Pada umumnya derajat(degree) pada relationship disebut biner. Ada 3 tipe relationship pada biner yaitu 1) One-to-one relationship (1..1)
Gambar 2.6 one-to-one relationship (Sumber: Connoly, 2010:386) Tiap anggota entitas Staff hanya bisa berhubungan dengan satu anggota dari entitas Branch. Sebaliknya tiap anggota dari entitas Branch hanya bisa berhubungan dengan satu anggota dari entitas Staff.
35
Berikut contoh ERD relasi one-to-one :
Gambar 2.7 ER Diagram one-to-one relationship (Sumber: Connoly, 2010:386) 2) One-to-many relationship
Gambar 2.8 one-to-many relationship (Sumber: Connoly, 2010:387) Tiap anggota entitas Staff bisa berhubungan dengan lebih dari satu anggota entitas PropertyForRent. Sebaliknya setiap anggota entitas PropertyForRent hanya bisa berhubungan dengan satu anggota entitas Staff Berikut contoh ERD relasi one-to-many :
Gambar 2.9 ER Diagram one-to-one relationship (Sumber: Connoly, 2010:388)
36
3) Many-to-many relationship
Gambar 2.10 many-to-many relationship (Sumber: Connoly, 2010:388) tiap anggota entitas NewsPaper bisa berhubungan dengan lebih dari satu anggota entitas PropertyForRent. Sebaliknya, tiap anggota entitas PropertyForRent juga bisa berhubungan dengan lebih dari dari anggota entitas NewsPaper. Berikut contoh ERD relasi many-to-many :
Gambar 2.11 many-to-many relationship (Sumber: Connoly, 2010:389) 2.1.7 Fact Finding Menurut Connolly dan Begg (2010:341), pencarian fakta (fact finding) adalah proses formal menggunakan teknik seperti wawancara dan kuesioner untuk mengumpulkan fakta tentang sistem, persyaratan, dan preferensi. fact finding sangat penting pada tahap-tahap awal siklus hidup basis data.
37
Teknik pencarian fakta yang paling sering digunakan adalah: 1) Pemeriksaan Dokumentasi (Examining Documentation) Pemeriksaan dokumentasi bisa berguna jika ingin mendapat pencerahan mengapa kebutuhan untuk Sistem Basis Data muncul. Dokumentasi juga dapat memberikan informasi mengenai bagian organisasi
yang
terpengaruh
dengan
masalah
tersebut.
Jika
masalahnya berhubungan dengan sistem yang sedang digunakan, seharusnya tersedia dokumentasi yang berhubungan dengan sistem itu. Setelah memeriksa dokumen, form, laporan,
dan file
yang
berhubungan, dengan cepat akan mendapatkan pemahaman mengenai sistem. 2) Wawancara (Interviewing) Wawancara adalah salah satu Teknik pencarian fakta yang amat sering digunakan dan juga sangat berguna. Tujuan untuk melakukan wawancara
bisa
bermacam-macam
misalnya
mencari
fakta,
membuktikan fakta, mengklarifikasi fakta, membangkitkan semangat, membuat
end
user
terlibat,
identifikasi
requirement,
dan
mengumpulkan ide dan opini. Ada dua tipe wawancara yaitu Terstruktur dan tak terstruktur. 1. Wawancara tak terstruktur dilakukan dengan hanya memikirkan tujuan
utama
dan
tidak
memikirkan
pertanyaan
khusus.
Pewawancara bergantung pada orang yang diwawancarai untuk menyediakan kerangka dan arah wawancara. 2. Wawancara
terstruktur
dilakukan
dengan
terlebih
dahulu
menyiapkan sekumpulan pertanyaan yang akan ditanyakan pada orang yang ingin diwawancarai. Pewawancara dapat menanyakan tambahan pertanyaan jika jawaban orang yang diwawancarai butuh klarifikasi atau ekspansi. Kelebihan dari Wawancara adalah: • Memungkinkan orang yang diwawancarai untuk merespon dengan bebas terhadap pertanyaan. • Memungkinkan orang yang diwawancarai untuk merasa sebagai bagian dari proyek.
38
• Memungkinkan pewawancara untuk menindaklanjuti komentar yang menarik dari orang yang diwawancarai. • Memungkinkan pewawancara untuk menyesuaikan atau mengubah kata pada pertanyaan saat wawancara. • Memungkinkan pewawancara untuk mengamati bahasa tubuh orang yang diwawancarai. Kekurangan dari wawancara adalah: • Sangat memakan waktu dan biaya, sehingga mungkin tidak praktis. • Kesuksesan sangat bergantung pada keterampilan komunikasi pewawancara. • Kesuksesan juga bisa bergantung pada kerelaan orang yang diwawancarai untuk menjawab pertanyaan wawancara dengan benar. 3) Pengamatan Organisasi (Observing the Enterprise in Operation) Pengamatan adalah salah satu teknik pencarian fakta paling efektif untuk mengerti sebuah sistem. Melalui teknik ini, pengamat dapat berpartisipasi, atau mengamati, seseorang melakukan kegiatan agar dapat mempelajari sistem dengan lebih langsung. Teknik ini dapat digunakan untuk membuktikan fakta yang dikumpulkan melalui teknik lain atau jika beberapa aspek sistem tak dapat diterangkan dengan jelas oleh end user. Keuntungan dari pengamatan organisasi adalah: • Memungkinkan pemeriksaan keabsahan fakta dan data yang sudah dikumpulkan. • Pengamat dapat melihat secara langsung apa yang sedang dilakukan. • Pengamat juga dapat mengambil data yang menggambarkan lingkungan fisik tugas dengan biaya rendah. • Pengamat dapat melakukan pengukuran kerja Kerugian dari pengamatan organisasi adalah: • Pekerja dapat secara sadar atau tak sadar berperilaku berbeda jika sedang diamati.
39
• Pengamat bisa saja tak melihat pengerjaan tugas yang tingkat kesusahan dan kebanyakannya biasa dialami saat periode waktu tersebut. • Beberapa tugas bisa saja tak selalu dilakukan dengan cara yang dipakai saat diamati • Bisa saja tidak praktis. 4) Penelitian (Research) Salah satu teknik fact finding yang berguna adalah research. Jurnal perdagangan komputer, buku referensi, dan internet (termasuk user group dan bulletin boards) adalah sumber informasi saat melakukan research Keuntungan dari menggunakan penelitian adalah: • Dapat menghemat waktu jika sudah ada solusi. • Peneliti dapat melihat bagaimana orang lain sudah menyelesaikan masalah serupa atau sudah memenuhi persyaratan yang sama. • Dapat membuat peneliti up to date dengan pengembangan saat ini Kekurangan dari menggunakan penelitian adalah: • Butuh akses ke sumber informasi yang tepat. • Kemungkinan tidak membantu menyelesaikan masalah. 5) Kuisioner (Questionnaires) Teknik pencarian fakta yang lain adalah dengan melakukan survei melalui Kuisioner. Kuisioner adalah dokumen dengan tujuan khusus untuk memungkinkan pengumpulan fakta dari sejumlah besar orang sambil mempertahankan kendali tanggapannya. Ada dua tipe pertanyaan yang dapat ditanyakan di dalam kuisioner, yaitu free format dan fixed format. Pertanyaan free format memberikan responden kebebasan yang lebih besar dalam menjawab pertanyaan. Pertanyaan ditanyakan dan responden menulis jawaban di spasi yang disediakan setelah pertanyaan. Pertanyaan fixed format membutuhkan tanggapan spesifik dari responden. Pada setiap pertanyaan responden harus memilih dari jawaban yang disediakan. Keuntungan dari Kuisioner adalah
40
• Responden dapat menjawab dan mengembalikan kuisioner tanpa batasan waktu. • Merupakan cara untuk mengumpulkan data dari banyak orang dengan biaya yang rendah. • Responden yang menyediakan fakta sebagai tanggapan dapat dirahasiakan identitasnya. • Tanggapan dapat ditabulasikan dan dianalisa dengan cepat. Kelemahan dari kuisioner adalah • Jumlah responden bisa rendah, kemungkinan hanya 5-10%. • Kuisioner bisa dikembalikan dengan keadaan tidak lengkap. • Tak ada kesempatan untuk menyesuaikan pertanyaan yang disalahtafsirkan. • Tak dapat mengamati dan menganalisa bahasa tubuh responden. 2.1.8 Normalisasi Menurut Connolly dan Begg (2010:416), Normalisasi adalah teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan sesuai dengan kebutuhan data suatu perusahaan. Tujuan utama melakukan normalisasi adalah untuk mengidentifikasi kumpulan relasi yang mendukung kebutuhan data suatu perusahaan. UNF Sebuah tabel yang mengandung satu atau lebih pengulangan. 1NF Sebuah relasi dimana titik pertemuan dari setiap kolom dan baris hanya mengandung satu nilai. 2NF Sebuah relasi yang berdasarkan pada 1NF dan setiap atribut nonprimary-key berfungsi secara utuh dan bergantung pada primary-key. 3NF Sebuah relasi yang memiliki dasar 1NF dan 2NF dimana atribut nonprimary-key bergantung transitif pada primary-key. 4NF Fourth Normal Form adalah relation yang dalam Boyce-Codd normal form tidak mengandung multi-valued dependency yang tidak trivial. Multi-Valued Dependency mewakili dependency antar atribut
41
(misalnya A,B, dan C) dalam relation sehingga untuk tiap nilai A ada kumpulan nilai untuk B dan kumpulan nilai untuk C. Tetapi, kumpulan nilai B dan C tidak berhubungan satu sama lain. 5NF Fifth Normal Form adalah relation yang tak memiliki join dependency. Join dependency adalah sejenis dependency. Contohnya, untuk relation R dengan subset atribut R ditandakan sebagai A,B,…,Z, relayion R memenuhi join dependency jika dan hanya jika setiap nilai legal R adalah sama dengan join proyeksinya pada A,B,…,Z. 2.2 Teori khusus Teori khusus merupakan suatu hubungan fakta dengan fakta lainnya yang bersifat secara lebih sempit daripada teori umum seperti Data Flow Diagram (DFD), State Transition Diagram (STD), Internet dan programming tools yang digunakan. Teori-teori ini berhubungan dengan topik dan teori pendukung dalam pembangunan aplikasi. 2.2.1 Freight Forwarding Menurut Nickels dan McHugh (2010:419), Freight Forwarder adalah sebuah organisasi yang menyatukan banyak pengiriman kecil untuk membuat satu pengiriman tunggal yang besar dan bisa dikirimkan ke tujuan akhir dengan biaya paling rendah. 2.2.2 Flowchart Menurut Deitel (2010:89), Flowchart adalah representasi grafis sebuah algoritma atau sebagian algoritma.
2.2.3 Diagram Konteks Menurut Satzinger, Jackson, dan Burd (2009:87), diagram konteks adalah diagram untuk mendeskripsikan ruang lingkup sistem dengan dipandang dari segi aliran keluar masuk informasi di dalam sistem. 2.2.4 Diagram Aliran Data Menurut Satzinger, Jackson, dan Burd (2009:206), DFD (Data Flow Diagram) adalah model sistem grafis yang menunjukan semua kebutuhan utama untuk sistem informasi dalam satu diagram yaitu input dan output, proses-proses, dan penyimpanan data.
42
2.2.5 Internet Menurut pendapat Williams dan Sawyer (2007:17), Internet adalah jaringan komputer di seluruh dunia yang menghubungkan ratusan bahkan ribuan jaringan yang lebih kecil, misalnya jaringan pendidikan, komersial, nirlaba dan militer, bahkan jaringan individual. 2.2.6 World Wide Web Menurut pendapat Williams dan Sawyer (2007:17), World Wide Web adalah komponen internet yang berupa multimedia. 2.2.7 Web Menurut
pendapat
Williams
dan
Sawyer
(2007:17),
Web
didefinisikan sebagai sistem koneksi antar komputer internet (disebut server) yang mendukung dokumen-dokumen berformat multimedia. 2.2.8 Web Server Menurut pendapat Williams dan Sawyer (2007: 60), Web Server atau host computer adalah komputer pusat penyedia data atau layanan yang diminta. 2.2.9 Web Database Menurut pendapat Williams dan Sawyer (2007:430), Web Database adalah basis data yang memuat teks yang dihubungkan ke dokumen lain. 2.2.10 Browser Menurut pendapat Williams dan Sawyer (2007:64), browser adalah perangkat lunak yang memungkinkan user untuk mencari dan mengakses beragam komponen web. 2.2.11 Protocol (TCP/IP dan HTTP) Menurut pendapat Williams dan Sawyer (2007:62), Protokol adalah sekumpulan aturan komunikasi yang harus diikuti oleh setiap komputer untuk mengirimkan data secara elektronik. Berdasarkan pendapat Williams dan Sawyer (2007:62), TCP/IP (Transmission Control Protocol/Internet Protocol)adalah protokol yang memungkinkan semua komputer menggunakan data yang ditransmisikan melalui internet. Berdasarkan pendapat Williams dan Sawye (2007:66), Hypertext
Transfer
Protocol)
adalah
aturan
memungkinkan browser tersambung ke web server.
HTTP (
komunikasi
yang
43
2.2.12 MySQL Menurut pendapat dari Suprianto (2008:1), MySQL adalah server basis data yang paling sering digunakan dalam pemrograman PHP. MySQL berfungsi menyimpan data dalam basis data dan memanipulasi data-data yang diperlukan. Menurut Gareth Downes-Powell dkk. (2003), MySQL adalah server berbasis data SQL. 2.2.13 PHP Menurut pendapat dari Suprianto (2008:1), PHP merupakan kependekan dari Hypertext Preprocessor. PHP tergolong sebagai perangkat lunak open source yang diatur dalam aturan general purpose license (GPL). PHP tergolong bahasa pemrograman berbasis server. PHP berfungsi sebagai mesin penerjemah saat halaman HTML yang mengandung script PHP dikirim ke server. Menurut Gareth Downes-Powell dkk. (2003), PHP adalah alat untuk membuat halaman web dinamis. Kehadiran dari PHP tak akan begitu terlihat bagi end user. PHP mudah untuk dipelajari dan diimplementasi. 2.2.14 Apache Server Menurut pendapat dari Suprianto (2008:1), Apache Server merupakan web server yang digunakan oleh PHP dan berfungsi untuk menampilkan hasil proses script PHP ke komputer browser dalam bentuk tag HTML. 2.2.15 PHPmyAdmin Menurut pendapat dari Suprianto (2008:1), PHPmyAdmin adalah kakas untuk pengelolaan basis data yang berbasis web. 2.2.16 Dreamweaver Menurut pendapat Mcfarland (2004) Dreamweaver adalah alat lengkap untuk membuat dan mengelola suatu website. Dreamweaver bekerja dengan teknologi web seperti HTML, XHTML, CSS, dan JavaScript. 2.2.17 Photostop Menurut Dayley (2010:3), Photoshop adalah sebuah aplikasi untuk menyunting gambar digital. 2.2.18 HTML Menurut pendapat Williams dan Sawyer (2007:549), HTML adalah tipe bahasa pemformatan yang menambahkan perintah dalam dokumen
44
teks standar ASCII untuk memberikan tampilan teks dan grafis dua dimensi yang terintegrasi. 2.2.19 Javascript Menurut Williams dan Tollett (2006:106), Javascript adalah script atau urutan pemrograman yang dapat membuat tindakan tertentu terjadi. 2.2.20 CSS CSS (Cascading Style Sheet) menurut Williams dan Tollett (2006:256), adalah bagaimana cara implementasi style sheet. Secara spesifik dalam urutan hirarki apa, bermacam-macam style diterapkan pada halaman web atau pada sekumpulan halaman web. 2.2.21 State Transition Diagram Berdasarkan tulisan Whitten dan Bentley (2007:635), State Transition Diagram adalah alat yang digunakan untuk menggambarkan sekuensi dan variasi layar(screen) yang dapat terjadi saat user session. 2.3 Penelitian Terkait Berikut beberapa penelitian yang digunakan digunakan dalam penyusunan skripsi ini : 1. Judul penelitian
: Provable Protection against Web Application
Vulnerabilities Related to Session Data Dependencies Tanggal diterbitkan : Jan.-Feb. 2008 Penulis
: Desmet, L ; Leuven Katholieke Univ ; Verbaeten,
P. ; Joosen W. ; Piessens, F. penerbit
: IEEE Computer Society
Berdasarkan penelitian Desmet, Verbaeten, Joosen, dan Piessens (2008,50-64), Web application sudah dipakai secara luas dan keakuratan fungsi aplikasi tersebut sangat penting untuk banyak bisnis. Misalnya banyak perusahaan sudah menginkorporasikan e-commerce dalam model bisnisnya untuk meningkatkan laba. 2. Judul penelitian
: MySQL keeps costs down
Tanggal diterbitkan : 25 Nov. 2003 Penulis
: nick langley
penerbit
: computer weekly
Berdasarkan penelitian Langley (2008), MySQL adalah DBMS favorit banyak perusahaan Web 2.0 dan juga masih populer dengan pengembang PHP dan Ruby. MySQL merupakan DBMS yang open source.
45
Lebih dari 40% pengembang perangkat lunak yang diwawancarai oleh Evans Data Corporation pada tahun 2006 berkata bahwa data corporation menggunakan MySQL walaupun juga ada yang tidak menggunakan sebagai platform basis data utama. DBMS MySQL merupakan DBMS pilihan untuk perusahaan Web 2.0 seperti Google, YouTube, Facebook dan Wikipedia, tetapi juga sering digunakan oleh perusahaan telekomunikasi, yang menunjukan dengan kebutuhan uptime 99.9 %-nya bahwa MySQL juga telah dipercaya oleh banyak perusahaan besar, bukan hanya oleh perusahaan kecil atau hobbyist. 3. Judul penelitian
: Techies and non-techies alike can build dynamic web
sites with ease Tanggal diterbitkan : Wed, 04 Aug 2004 Penulis
: O'Reilly
penerbit
: O'Reilly Media, Inc.
Berdasarkan penelitian M2 Presswire (2004), PHP adalah bahasa pemrograman yang paling populer untuk membuat situs web dinamis. Alasan paling utama untuk popularitas ini adalah karena PHP memudahkan pengembangan halaman web yang lebih berguna, cepat dan mengesankan untuk perancang non teknis sekalipun. Setelah popularitasnya berkembang, fitur umum PHP telah meningkat menjadi makin mutakhir. Sekarang PHP 5 telah membanggakan fitur lanjutan seperti kemampuan object oriented dan dukungan untuk XML dan web services yang akan berguna bagi perancang web profesional sementara masih menjadi user-friendly untuk perancang web yang kurang mengerti istilah teknis.
