|
5
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
|
|
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 akan membutuhkan perangkat
keras(hardware) untuk berjalan. 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. Kebutuhan-
kebutuhannya 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. Contoh: Staff Manages
PropertyForRent, PrivateOwner
Owns
PropertyForRent, PropertyForRent Associated
With Lease.
Langkah 1.3:
Mengidentifikasi dan mengasosiasikan attribut-
atribut 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
dapat menggunakan composition
(sebuah tipe aggregation
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 data
konseptual mendukung transaksi yaitu:
a. Mendeskripsikan transaksi
b. Menggunakan lajur transaksi
|
|
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 langkah-
langkah 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 menggunakan mekanisme
primary key/foreign key. Dan juga
untuk
mendeskripsikan bagaimana 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 menentukan apakah
menambahkan indeks akan 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 DBLC. DBMS relasional umumnya
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 masing-
masing 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 non-
primary-key berfungsi secara utuh dan bergantung pada primary-key.
3NF
Sebuah relasi yang memiliki dasar 1NF dan 2NF dimana atribut non-
primary-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), HTTP
(
Hypertext Transfer Protocol) adalah aturan komunikasi yang
memungkinkan browser tersambung ke web server.
|
|
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
:
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.
|