BAB 2
LANDASAN TEORI
2.1
Pengertian Data dan Informasi
Item
data
merupakan penjelasan
dasar
mengenai
segala
sesuatu,
peristiwa,
aktivitas, dan transaksi yang dicatat, diklasifikasikan, serta disimpan, tetapi tidak diatur
untuk
mengungkapkan makna
tertentu.
Basis
data
terdiri
dari
berbagai
item
data
yang
disimpan dan diatur untuk dapat ditarik kembali (Rainer, Turban, 2006, p52).
Informasi
merupakan data yeng
telah diatur sehingga
memiliki makna dan nilai
bagi
penerimanya. Penerima
informasi
akan
mengartikan
maksud
dari
informasi
dan
menarik kesimpulan serta berbagai implikasi dari data tersebut.
2.2
Pengertian Teknologi Informasi dan Sistem Informasi
Sistem Informasi adalah proses
menjalankan fungsi mengumpulkan, memproses,
menyimpan, menganalisis,
dan
menyebarkan
informasi
untuk
tujuan
tertentu;
kebanyakan sistem informasi dikomputerisasi, tetapi tidak
harus komputerisasi (Rainer,
Turban, 2006, p48).
Teknologi informasi adalah kumpulan sumber daya
informasi perusahaan, para
penggunanya, serta
manajemen
yang
menjalankannya; meliputi
infrastruktur
teknologi
informasi dan semua sistem informasi lainnya dalam perusahaan. Infrastruktur teknologi
informasi
meliputi
proses
integrasi,
operasi, dokumentasi, pemeliharaan, dan
manajemennya.(Rainer, Turban, 2006, p49).
9
|
10
2.3
Teori-Teori Basis Data
2.3.1
Definisi Basis Data
Basis data adalah merupakan kumpulan data yang berhubungan secara
logikal, dan keterangan
di
dalamnya,
yang
di
rancang
untuk
memenuhi
informasi
yang dibutuhkan dalam
suatu
organisasi (Begg, Connolly,
2005,
p15).
Basis data
merupakan
suatu
kesatuan,
penyimpanan data
yang
besar
yang
dapat
digunakan
secara bersamaan oleh banyak departemen dan pengguna.
Sedangkan menurut
Adi
Nugroho
(2008,
p1),
basis
data
merupakan
kumpulan/koleksi data-data
yang
terorganisasi
yang
disimpan
di
tempat
penyimpanan komputer
(biasanya
bersifat
permanen) dan
dirancang
serta
diorganisasikan sedemikian rupa
sehingga mudah
dicari,
diakses, dan
dimanipulasi
(diubah,
ditambahkan, serta
dihapus)
oleh
pengguna.
Data-data
tersebut
mungkin
berupa
teks, angka-angka,
maupun
grafik, dan dimasa
kini, pengertian
data(sesuai
yang diakomodasi oleh
Oracle
Corp.)
bisa
diperluas
menjadi
selain
tipe-tipe data
yang telah disebutkan-suara, gambar,
foto, serta
video. Orang-orang yang
mengatur
dan mengelola Basis data disebut DBA (Database Administrator).
2.3.2
Relational Model
Struktur data
relasional
mempunyai
istilah-istilah sebagai berikut
(Begg,
Connolly, 2005, p72):
a.
Relation, merupakan sebuah tabel yang berisi kolom dan baris
b.
Attribute, merupakan nama kolom suatu relasi
c.
Domain, merupakan kumpulan nilai-nilai yang bernilai valid pada atribut
tertentu
|
11
d.
Tuple, merupakan sebuah baris dari sebuah relasi
e.
Degree, merupakan jumlah atribut yang dikandung
f.
Cardinality, merupakan jumlah tuple dalam suatu relasi
g.
Relation Database, merupakan kumpulan dari tabel-tabel yang telah
melewati proses normalisasi dengan relasi yang unik
2.3.3
Relational Key
Tidak ada tuple yang
sama dalam suatu relasi. Maka dari itu,
harus mampu
mengidentifikasi
satu
atau
lebih
atribut
yang
secara
unik
mengidentifikasi
setiap
tuple dalam suatu relasi. Atribut-atribut tersebut disebut dengan suatu relational key
(Begg, Connolly, 2005, p78). Relational key terdiri dari :
a. Superkey, yang
merupakan suatu atribut, atau sekumpulan
atribut,
yang
mengidentifikasi tuple secara unik dalam suatu relasi.
b. Candidate key, merupakan superkey sedemikian sehingga tidak ada
bagian yang tepat dari superkey dalam relasi.
c. Primary
key,
merupakan
candidate
key
yang
dipilih
untuk
mengidentifikasi tuple yang unik dari relasi.
d. Foreign key,
merupakan sebuah atribut, atau
sekumpulan
atribut,
yang
ada
pada
suatu
relasi,
yang sama dengan candidate
key
dari
beberapa
relasi.
2.3.4
Database Management System (DBMS)
Menurut
Connolly
dan
Begg (Begg,
Connolly,
2005,
p16)
Database
Management System
(DBMS) adalah
merupakan
suatu perangkat
lunak yang
|
12
memungkinkan pengguna untuk mendefinisikan, membuat, merawat, dan melakukan
kontrol akses terhadap basis data.
DBMS mempunyai fasilitas sebagai berikut:
Memungkinkan pengguna untuk mendifinisikan Basis data, biasanya
melalui sebuah
Data
Definition
Language
(DDL).
DDL
memungkinkan pengguna untuk mengelompokkan tipe data, struktur,
dan batasan terhadap data yang akan disimpan dalam basis data
Dapat
memungkinkan pengguna untuk melakukan pemasukan
(insert), perubahan (update), penghapusan (delete), dan pengambilan
(retrieve)
data dari
basis
data, biasanya
melalui
Data
Manipulation
Language (DML). DML memungkinkan pengguna
untuk
melakukan
operasi query pada basis data
Menciptakan
akses kendali
ke basis data. Sebagai
contoh DBMS
menyediakan:
-
Sebuah sistem keamanan, yang dapat
mencegah pengguna
yang
tidak mempunyai wewenang untuk mengakses basis data.
-
Sebuah sistem integrasi, yang menjaga konsistensi data yang
tersimpan
-
Sebuah sistem kendali yang memungkinkan basis data untuk
diakses secara bersamaan.
-
Sebuah kendali
sistem recovery,
yang memungkinkan basis data
untuk mengembalikan basis
data ke kondisi konsisten
yang
|
13
sebelumnya jika terjadi kesalahan, termasuk kesalahan perangkat
keras dan perangkat lunak
-
Sebuah katalog yang dapat diakses oleh pengguna, yang
mengandung
penjelasan
dari
data
yang
terdapat
di
dalam
basis
data yang ada.
2.3.4.1
Komponen Database Management System (DBMS)
Menurut
Conolly
dan
Begg
(Begg,
Connolly, 2005,
p18),
DBMS
mempunyai
lima
komponen utama
:
hardware,
software,
data,
procedure,
dan
manusia (pengguna).
Hardware (Perangkat Keras)
DBMS
dan
aplikasi
membutuhkan perangkat
keras
untuk
menjalankan suatu
proses.
Hardware
dapat
dijangkau
dari
suatu
komputer
tunggal, ke
sebuah
mainframe
tunggal, pada
suatu
jaringan komputer.
Software (Piranti Lunak)
Komponen piranti
lunak yang
meliputi software
DBMS itu sendiri
dan
program-program aplikasi
beserta
Operating
System
(OS),
termasuk piranti
lunak jaringan, bila DBMS
digunakan pada suatu
jaringan LAN.
Data
Data
adalah
komponen yang
paling
penting
dalam
DBMS,
khususnya
dari
titik
sudut
pandang
pangguna akhir
yang
berhubungan dengan data.
|
14
Prosedur
Prosedur
dapat
berupa
instruksi
dan
aturan-aturan yang
mengatur
rancangan
dan
penggunaan basis
data. Pengguna dari
sistem
dan
pekerja
yang
mengatur
basis
data
membutuhkan dokumentasi
petunjuk
mengenai
bagaimana cara
mengoperasikan
sistem.
Instruksi tersebut dapat berupa cara untuk melakukan:
-
Log on ke dalam DBMS
-
Menggunakan fasilitas DBMS tertentu atau program aplikasi
-
Memulai (start) dan mengakhiri (stop) DBMS
-
Membuat backup duplikasi dari basis data
-
Menangani kesalahan pada perangkat keras (hardware) atau
perangkat lunak (software).
-
Mengubah
struktur
sebuah
tabel,
merancang
kembali
basis
data
melintasi banyak disk,
meningkatkan kemampuan, atau
mendapatkan data dari penyimpanan kedua/cadangan.
Manusia (person) atau Sumber Daya Manusia (SDM)
Manusia
yang terlibat
langsung dalan sistem dibagi
atas
4
bagian,
yaitu (Begg, Connolly, 2005, p22):
-
Data dan Database Administrators
Data
Administrator
(DA)
bertanggung jawab
terhadap
managemen
sumber
data
meliputi
perencanaan basis
data,
pengembangan dan
standar
pemeliharaan, prosedur
dan
kebijakan, dan desain konseptual logikal basis data.
|
15
Database Administrator (DBA) bertanggung jawab terhadap
pelaksanaan secara
fisik
dari
database,
seperti
desain
dan
implementasi fisik database, kendali kemanan dan integritas,
perawatan
sistem
operasional, dan
menjamin
kepuasan
pengguna
-
Database designer
Terdiri
dari
dua tipe
designer,
yaitu
logical
database
designer dan physical database designer . Logical database
designer
yaitu orang
yang
memperhatikan identifikasi data
(entities dan attribute), hubungan diantara data, dan batasan
dari data yang disimpan pada basis data. Physical database
designer adalah orang
yang menentukan bagaimana
logical
database designer dapat terlaksana secara fisik
-
Pengembang Aplikasi (Application Developer)
Yaitu orang yang bekerja untuk spesifikasi yang telah dibuat
oleh system analist
-
Pengguna Akhir (End-user)
Merupakan
siapa
saja
yang
menggunakan aplikasi
untuk
memperoleh informasi dari sebuah sistem basisdata
|
16
2.3.4.2
Fungsi dari DBMS
DBMS
menciptakan
beberapa
tipe
fungsi
dan
pelayanan
(Begg,
Connolly, 2005, p48). Diantaranya adalah :
Data Storage, Retrieval, and Update
Sebuah
DBMS
harus
mampu
melayani
pengguna dengan
kemampuan untuk menyimpan, menelusuri kembali, dan melakukan
pengubahan data dalam basis data.
Sebuah user-accessible catalog
Sebuah
DBMS
harus
menyediakan sebuah
catalog
yang
menjelaskan data
yang
disimpan
dan
yang
dapat
diakses
oleh
pengguna.
Transaction support
DBMS
harus
menyediakan sebuah
mekanisme
yang
menjamin
semua perubahan terhadap
suatu
transaksi
atau
tidak
akan
terjadi
perubahan sama sekali.
Concurrency Control Services
DBMS harus menyediakan sebuah mekanisme yang menjamin basis
data
berubah
dengan
benar
ketika
banyak
pengguna melakukan
perubahan pada basis data secara bersamaan.
Recovery services
Sebuah
DBMS
harus
menyediakan sebuah
mekanisme
untuk
melakukan recovery
terhadap
basis
data
ketika
basis
data
rusak
dengan cara apapun.
|
17
Authorization Service
Sebuah
DBMS
harus
menyediakan
mekanisme
untuk
memastikan
bahwa
hanya
pengguna
yang
mempunyai wewenang
yang
dapat
mengakses basis data.
Mendukung Komunikasi Data
Sebuah
DBMS
harus
mempunyai kemampuan
untuk
berintegrasi
dengan perangkat lunak komunikasi
Integrity services
DBMS
harus
mengidentifikasikan suatu cara
untuk menjamin data
yang terdapat di dalam basis data
beserta perubahannya mengikuti
aturan-aturan yang tepat.
Services to promote Data Independence
DBMS
harus
mengandung fasilitas untuk
mendukung
kemandirian
program dari struktur basis data aktual.
Utility service
DBMS
harus
menyediakan sekumpulan Utility services agar
basis
data dapat berjalan secara efektif.
2.3.5
Relational Database Management System (RDBMS)
Dalam
penelitian, digunakan perangkat
lunak
Oracle
Database
10g
yang
merupakan Relational
Database
Management
System
(RDBMS).
Penemu
konsep
Basis
Data
Relasional adalah
Peter
Chen,
sedangkan pencipta
RDBMS
adalah
DR.Ted Codd (Adi Nugroho, 2008, p4).
|
![]() 18
Basis data relasional adalah tipe basis data atau sistem manajemen basis data
yang
menyimpan data-data
dalam
bentuk
tabel,
terdiri
dari
baris-baris
data
dan
kolom-kolom data
dimana
data
pada
kolom
dan
baris
tertentu
terkadang
dapat
digunakan sebagai rujukan pencarian data yang
berkaitan di
tabel
yang
lain
(Adi
Nugroho, 2008, p4). Perhatikan gambar tabel 2.1.3.1 dibawah
NIM
Nama
5184025
5183027
5184088
5184099
Adi Nugroho
Ana Mariana
Esti Nugraheni
Eni Nugraheni
Tabel Mahasiswa
No_MK
Nama_MK
SKS
110011
130012
130013
Pascal
C
Basis
Data
3
3
3
Tabel Mata Kuliah
NIM
No_MK
Nilai
5184025
5184025
5184088
110011
130013
110011
A
A
C
Tabel Pengambilan Mata Kuliah
Gambar 2.1 Contoh Basis Data Relasional
Tabel
pertama
tertunjuk pada
gambar 2.1
memperlihatkan data-data tentang
mahasiswa tertentu, misalkan mahasiswa dengan NIM = 5184025 dengan nama Adi
Nugroho, NIM = 5183027 dengan nama ana Mariana, dan selanjutnya. Tabel kedua
|
19
memperlihatkan data-data tentang
mata kuliah, misalkan mata kuliah dengan
No_MK = 110011 bernama pascal dengan jumlah SKS sebanyak 3 dan No_MK =
110012
dengan SKS
sebesar
3
adalah
mata
kuliah
C.
Kemudian ketiga
tabel
memperlihatkan data-data mahasiswa
yang
mengambil
mata kuliah
tertentu beserta
nilainya masing-masing, misalnya Adi Nugroho (NIM = 5184025) yang
mengambil
mata kuliah
Pascal
(No_MK =
110011) dan
mendapatkan indeks
nilai
A
dan
Esti
Nugraheni
(NIM
=
5184088)
mengambil mata
kuliah Pascal (No_MK
=
110011)
sudah
mendapatkan nilai
C.
Kemudian
beberapa
mahasiswa,
dengan
nama
Ana
Mariana dan Eni Nugraheni (NIM = 5184099) ternyata tidak mengambil mata kuliah
apa-apa (mungkin yang bersangkutan sedang cuti).
Dalam basis data relasional, data-data disimpan dalam bentuk tabel (beberapa
pihak
menyebutnya sebagai
relasi)
dimana
baris-baris
pada
tabel
menyatakan
rekaman-rekaman (record)
dan
kolom-kolom menyatakan field-field
(atribut-atribut
pada rekaman). Untuk
memandu pencarian, basis data relasional
mencocokan data-
data
dari
salah
satu tabel
dengan data-data pada
tabel
lain dan
menghasilkan tabel
ketiga yang menggabungkan data-data dari kedua tabel
(Adi Nugroho, 2008, p5).
Basis
data
adalah
himpunan
dari
relasi-relasi. Secara
formal,
setiap
relasi
ditampilkan dalam bentuk tabel atau sering disebut sebagai tabel datar (flat files) dari
rekaman-rekaman (record). Selain
itu relasi sering
didefinisikan
sebagai
himpunan
rekaman-rekaman.
Dalam berkas-berkas basis
data, rekaman-rekaman
(record)
secara fisik tersimpan di
media
simpan tertentu sehingga ada hubungan atau relasi
antara satu dengan yang lain.
|
20
Setiap
nilai dalam atribut suatu rekaman
harus bernilai atomik, yang artinya
tidak
dapat
dibagi
lagi
menjadi
komponen-komponen dalam
kerangka
model
relasional sehingga atribut bernilai banyak tidak diizinkan.
RDBMS memiliki 3 aspek utama, yaitu :
Data ditampilkan
sebagai tabel-tabel
2 dimensi.
Tabel-tabel
memiliki
nomor-nomor yang spesifik bagi setiap
baris dan kolom dan suatu data
disimpan pada baris dan
kolom tertentu. Kolom-kolom memperlihatkan
atribut-atribut dan setiap baris mewakili data-data untuk suatu objek.
Operator untuk memanipulasi tabel-tabel. SQL (Structured Query
Language)
adalah
bahasa
basis
data
bertipe
relasional. Dalam
hampir
segala
hal
menyangkut
administrasi basis
data,
oracle
menggunakan
sintaks-sintaks
SQL.
Selain
itu,
suatu
pengembangan dari
bahasa
pemrograman nir-prosedural
SQL
yang
khas
Oracle,
yaitu
:
PL/SQL
(Programming Language / Structured Query Language), juga
dikembangkan Oracle Corp. Demi peningkatan kemampuan SQL baku
Referencial Integrity. Referencial Integrity merupakan
sarana
penghubung
utama
pada
suatu
basis
data
relasional
sehingga basis data
pada suatu tabel dapat berhubungan dengan data
yang berada pada tabel
lain, melalui penggunaan primary key dan foreign key
|
21
2.3.6
Database Language
Sebuah
sub
bahasa
data
dibagi
menjadi
dua
bagian
yaitu
:
Data
Definition
Language
(DML)
dan Data
Definition
Language
(DML).
DDL
digunakan untuk
menspesifikasikan skema
basisdata
dan
DML
digunakan
untuk
membaca
dan
mengubah basisdata (Begg, Connolly, 2005, p39).
2.3.6.1
The Data Definition Language
DDL
(Data
Definition
Language)
merupakan bahasa
yang
memungkinkan DBA (database administrator) atau user
untuk menjelaskan dan
memberi
nama
entitas,
atribut, dan
hubungan
yang
dibutuhkan
untuk
aplikasi,
bersama
dengan
beberapa
hubungan intergrasi
dan
batasan
keamanan (Begg,
Connolly, 2005, p40).
Contoh operasi yang dapat dilakukan oleh DDL adalah sebagai berikut
(Begg, Connolly, 2005, p168) :
a. Create Table
Digunakan untuk menciptakan tabel dengan melakukan definisi tipe
data pada masing-masing kolom.
b. Alter table
Digunakan untuk mengubah kolom yang ada dan mengubah batasan
pada suatu tabel,
c. Drop table
Digunakan
untuk
menghapus
tabel
yang
tidak
digunakan
beserta
semua data yang ada didalamnya.
d. Create Index
Digunakan untuk melakukan index dalam suatu tabel,
|
22
2.3.6
Database Language
Digunakan untuk menghapus index yang diciptakan sebelumnya.
f.
Create View
Digunakan untuk membuat sebuah virtual relation.
g. Drop View
Digunakan untuk menghapus view,
2.3.6.2
The Data Manipulation Language (DML)
DML merupakan sebuah bahasa yang menciptakan sekumpulan operasi
untuk
mendukung
operasi
manipulasi data dasar
pada data
yang
ada
didalam
basisdata.
DML (Data Manipulation Language) menyediakan operasi dasar dalam
basis data, diantaranya adalah :
a) Memasukkan data baru kedalam basisdata (insertion)
b)
Perubahan
terhadap
data
yang
disimpan
dalam
basisdata
(modification)
c) Pemanggilan data yang ada dari basisdata (retrieve)
d)
Menghapus data yang ada didalam basisdata (delete)
DML dapat dibedakan menjadi 2 tipe yang berbeda, diantaranya adalah
(Begg, Connolly, 2005, p41):
a. Procedural DMLs
Procedural language merupakan bahasa yang memperbolehkan
user untuk memberitahu sistem mengenai data apa yang dibutuhkan
dan bagaimana cara pemanggilannya (retrieve).
DML
memanggil
|
23
rekaman
(record),
dan
memprosesnya, berdasarkan
hasil
yang
diperoleh dari proses, memanggil rekaman lain yang harus diproses
secara cara yamg sama, dan lainnya.
b. Non-procedural DMLs
Merupakan
suatu
bahasa
yang
memperbolehkan pengguna
untuk
menyatakan data
apa
yang
dibutuhkan
tanpa
menspesifikasikan
bagaimana cara mendapatkan data tersebut.
2.3.6.3
Fourth-Generation Language
Fourth-Generation
Language
merupakan bahasa
non-procedural
dimana
pengguna
menentukan
apa
yang
akan
diselesaikan,
bukan
bagaimana
cara menyelesaikannya (Begg, Connolly, 2005, p42). Contoh 4 GL adalah SQL
dan QBE. Beberapa tipe 4 GL adalah sebagai berikut :
a. Forms Generator
Merupakan fasilitas
interaktif
menciptakan data
masukan
secara
cepat
dan
menampilkan
tampilan. Mendefinisikan desain tampilan
seperti apa,
informasi
apa
yang
akan
ditampilkan, definisi
warna
pada layar.
b. Report Generator
Merupakan suatu fasilitas yang digunakan untuk
membuat laporan
dari
data
yang
disimpan
dalam basisdata. Report
generator
lebih
mementingkan keluaran,
yaitu
bagaimana
suatu
laporan
akan
disajikan.
|
24
c. Graphic Generator
Merupakan fasilitas
yang
digunakan
untuk
mengambil
data
dari
basisdata. Memungkinkan pengguna
untuk
menampilkannya dalam
bentuk grafik seperti bar, chart, pie chart, line chart dan lain-lain.
d. Application generator
Merupakan
fasilitas
untuk
menghasilkan sebuah
program
yang
merupakan interface dari basisdata.
|
![]() 25
2.3.7
Siklus Hidup Aplikasi Basis Data (Database Application Lifecycle)
Sistem basis data
merupakan komponen dasar
dari
organisasi besar dengan
sistem
informasi
yang
luas.
Daur
hidup
aplikasi
basis data
berkembang terhubung
dengan daur hidup sistem informasi (Begg, Connolly, 2005, p283).
Berikut ini adalah siklus hidup aplikasi basisdata pada gambar berikut :
Gambar 2.2 Tahapan-Tahapan Siklus Hidup Aplikasi Basisdata
(Begg, Connolly, 2005, p284)
|
26
2.3.7.1
Perencanaan Database (Database Planning)
Database
Planning
adalah
aktivitas
manajemen yang
memungkinkan
tahapan-tahapan dari database system development lifecycle dapat direalisasikan
dengan
seefektif dan
seefisien mungkin. Database
planning
harus
di-
integrasikan/dihubungkan dengan
seluruh
strategi
sistem
informasi
(Begg,
Connolly, 2005, p285). Ada 3 hal yang terlibat dalam penyusunan strategi sistem
informasi :
-
Identifikasi terhadap rencana dan
sasaran usaha dengan rangkaian
keputusan dari kebutuhan sistem informasi
-
Evaluasi terhadap sistem informasi yang sedang berjalan untuk
mengetahui kekuatan dan kelemahannya
-
Penafsiran terhadap kesempatan teknologi informasi yang dapat
memberikan keuntungan yang kompetitif
2.3.7.2
System Definition
Pendefinisian sistem
(System
Definition)
menjelaskan
lingkup
dan
batasan
aplikasi
basis
data
dan
pandangan-pandangan utama
dari
para
user/pengguna (Begg,
Connolly,
2005,
p286).
Sebelum
memutuskan
untuk
mendesain sebuah sistem basisdata, penting
untuk
mengidentifikasi batasan dari
sistem
yang
sedang
diselidiki
dan
bagaimana tampilannya
dengan
bagian
lain
dari
sistem
informasi organisasi. Batasan sistem
sebaiknya tidak
hanya
sesuai
dengan bidang dan
batasan
aplikasi
basisdata
serta
pandangan pengguna
yang
telah
ada
saja
pada
saat
ini,
namun
harus
sesuai
juga
dengan
kebutuhan
pada
masa yang akan datang.
|
27
Pandangan
pengguna
(user
views)
menentukan
apa
yang
dibutuhkan
dari
sebuah
sistem
basisdata
dari
perspektif/pandangan suatu
jabatan
tertentu
(seperti
manager
atau
supervisor)
atau
area
aplikasi perusahaan (seperti
marketing, personnel, dan stock control).
2.3.7.3
Pengumpulan Kebutuhan dan Analisis (Requirement Collection and
Analysis)
Proses
pengumpulan kebutuhan
dan
analisis
merupakan
proses
pengumpulan dan
analisis
informasi
tentang
bagian
organisasi
yang
harus
didukung
oleh sistem
basisdata,
dan penggunaan
informasi
tersebut
berguna
untuk
mengidentifikasi persyaratan
pengguna
untuk
sistem
yang
baru
(Begg,
Connolly, 2005, p288).
Informasi yang dikumpulkan pada langkah ini termasuk:
-
Deskripsi dari data yang digunakan atau data yang di-generate
-
Detail mengenai bagaimana data digunakan atau di-generated
-
Kebutuhan-kebutuhan
tambahan apapun untuk sistem basis data
yang baru
2.3.7.4
Perancangan Basis Data (Database Design)
Perancangan
basisdata
merupakan proses
pembuatan suatu rancangan
yang
akan
mendukung
operasi dan
tujuan
perusahaan untuk kebutuhan
sistem
basisdata
(Begg,
Connolly,
2005,
p291).
Terdapat
2
pendekatan dalam
perancangan basisdata :
b. Bottom-up
Pendekatan bottom-up dimulai dari tingkat paling dasar dari
suatu
atribut (yaitu, properti dari entitas dan relasi) dimana
melalui
|
28
analisis
dari
hubungan
diantara
atribut,
dikelompokkan kedalam
relasi-relasi
yang
merepresentasikan tipe
entity
dan
hubungan-
hubungan diantara entity.
Pendekatan ini
cocok
untuk perancangan
sebuah basisdata sederhana, dengan jumlah atribut yang relatif
kecil. Namun pendekatan ini akan sulit diterapkan dalam rancangan
basis
data
yang
lebih
kompleks dengan
jumlah
atribut
yang
lebih
besar,
karena
akan
sulit
untuk
membangun
semua
ketergantungan
fungsional diantara atribut.
c. Top-down
Pendekatan ini dimulai dari pengembangan model data yang terdiri
dari beberapa
hubungan relasional dan
entity tingkat tinggi beserta
hubungan-hubungannya, kemudian
dilanjutkan
dengan
mengidentifikasi entitas-entitas
tingkat
rendah,
hubungan-
hubungannya,
serta
mengasosiasikan atribut-atribut
yang
berhubungan. Pendekatan
ini
merupakan strategi
yang lebih
cocok
untuk
membuat sebuah basisdata
yang
lebih kompleks. Pendekatan
ini biasanya digambarkan melalui ER (Entity Relationship)
Perancangan database
dibagi
menjadi
3
tahapan
yaitu,
conceptual
database design, logical database design, dan physical database design (Begg,
Connolly, 2005, p439).
2.3.7.5
Pemilihan DBMS
Merupakan suatu
proses
untuk
memilih
DBMS
yang
tepat
untuk
mendukung sistem dari basisdata (Begg, Connolly, 2005, p295). Tahapan utama
pemilihan DBMS adalah sebagai berikut :
|
29
a) Menentukan syarat-syarat referensi studi
Tahapan
ini
merupakan prasyarat dalam
menentukan
DBMS
yang
sudah
dijalankan,
mulai
dari
menentukan tujuan,
batasan
masalah,
dan tugas-tugas yang harus dilakukan.
b)
Mengurutkan dua atau tiga produk
Ini merupakan proses membuat daftar barang-barang seperti sumber
barang,
biaya yang diperlukan
lalu bagaimana cara untuk
mendapatkannya.
c) Mengevaluasi produk
Barang-barang akan
melalui proses penelitian pada
beberapa tahap
untuk
mengetahui
kelebihan
ataupun
kekurangan dari
barang
tersebut.
d)
Membuat laporan tentang pilihan yang direkomendasikan Merupakan
langkah yang berkaitan dengan proses dokumentasi dan
menciptakan pernyataan
mengenai penemuan dan
rekomendasi
terhadap suatu produk DBMS tertentu.
2.3.7.6
Perancangan Aplikasi
Perancangan
aplikasi
merupakan
suatu
proses
perancangan dari
user
interface
dan
program-program aplikasi
yang
menggunakan
dan
memproses
basisdata
(Begg,
Connolly,
2005,
p299).
Basis
data
dan
perancangan aplikasi
adalah
aktivitas
yang
paralel
dari
daur
hidup
sistem
basisdata. Maka
dari
itu,
pada
banyak
kasus
merupakan suatu
yang
tidak
mungkin
untuk
melengkapi
perancangan aplikasi jika perancangan basisdata belum selesai.
|
30
2.3.7.7
Prototyping
Prototyping
adalah
proses
membangun
sebuah
kerangka kerja
dari
sebuah aplikasi basisdata. Suatu prototype merupakan model
yang tidak
normal
dan
tidak
mempunyai
semua
fitur
yang
dibutuhkan
atau
menyediakan semua
fungsionalitas dari
sistem
terakhir.
Tujuan
utama
dari
pengembangan
sebuah
sistem
basisdata
prototype
adalah
memungkinkan pengguna
menggunakan
prototype
tersebut
untuk
mengidentifikasi
fitur-fitur
dari
sistem
yang
bekerja
baik,
atau
memadai, dan
jika
mungkin
menganjurkan peningkatan atau bahkan
fitur-fitur baru pada aplikasi basisdata (Begg, Connolly, 2005, p304).
Ada 2 strategi prototyping yang umum digunakan saat ini, yaitu :
a)
Requirement prototyping
Strategi
ini
menggunakan sebuah
prototype
untuk
menentukan
berbagai
kebutuhan
dari
sistem
basisdata
yang diusulkan.
Apabila
semua kebutuhan telah selesai ditentukan
maka
prototype
tersebut
tidak akan digunakan lagi.
b)
Evolutionary prototyping
Strategi
ini
digunakan untuk
tujuan
yang
sama,
perbedaan yang
penting
adalah
bahwa
prototype
tidak
dibuang tetapi
dengan
pengembangan lebih jauh menjadi sistem basisdata yang bekerja.
2.3.7.8
Implementasi (Implementation)
Implementasi merupakan realisasi fisik dari perancangan basisdata dan
perancangan
aplikasi
(Begg,
Connolly,
2005,
p304).
Pada
penyelesaian tahap
perancangan (dimana
mungkin atau
tidak
mengandung prototyping),
sekarang
dalam posisi mengimplementasikan basisdata dan program aplikasi.
|
31
Implementasi basisdata
dapat
dicapai
menggunakan Data Definition
Language
(DDL) dari DBMS yang dipilih atau dari graphical user
interface (GUI),
yang
menciptakan fungsionalitas yang sama ketika menyembunyikan pernyataan DDL
tingkat rendah. Pernyataan DDL tersebut digunakan untuk menciptakan struktur
basisdata
dan
file
basisdata
yang
kosong.
Program-program aplikasi
dapat
diimplementasikan menggunakan bahasa generasi ketiga atau keempat (3GL atau
4GL).
Transaksi
basis
data
diimplementasikan dengan
menggunakan
Data
Manipulation
Language
(DML)
dan
merupakan bagian
dari program
aplikasi.
Kendali
integritas
dan
keamanan
sebagian
diimplementasikan menggunakan
DDL, namun terdapat beberapa yang membutuhkan perangkat diluar DDL.
2.3.7.9 Pengubahan data dan pengambilan
Merupakan proses transfer data
yang ada kedalam basis data baru dan
mengubah aplikasi
yang
ada
untuk berjalan
pada
basis
data
yang
baru
(Begg,
Connolly,
2005,
p305).
Langkah
ini
dibutuhkan
hanya
ketika
sebuah
sistem
basis data baru mengganti sistem yang lama. Saat ini, merupakan suatu hal
yang
umum untuk DBMS yang memiliki suatu peralatan yang dapat memuat file yang
ada kedalam basis data
yang baru. Peralatan biasanya membutuhkan spesifikasi
dari sumber file dan basis data tujuan, dan kemudian secara otomatis mengubah
data kedalam bentuk format yang dibutuhkan oleh basis data yang baru.
2.3.7.10 Pengujian (Testing)
Merupakan proses
pelaksanaan program
aplikasi
dengan
tujuan
untuk
menemukan kesalahan. Sebelum dihidupkan, sistem basis data yang baru
|
32
dikembangkan
harus seluruhnya
diuji.
Proses uji coba
ini dilakukan
dengan
keadaan yang mendekati kenyataan bersangkutan dengan data-data yang nyata.
2.3.7.11 Pemeliharaan Operasional (Operational Maintenance)
Merupakan proses pengawasan dan perawatan sistem basisdata berikut
instalasi. Kegiatan yang dilakukan pada tahap ini adalah sebagai berikut :
-
Memantau kinerja sistem
-
Merawat
dan
melakukan
upgrade
terhadap
aplikasi basisdata
(ketika dibutuhkan)
2.3.8
Tahap-Tahap Perancangan Basis Data
Metode perancangan database dibagi menjadi tiga bagian utama (Begg,
Connolly, 2005, p293), yaitu :
Perancangan Basis Data Konseptual
Merupakan suatu
proses
membangun
sebuah
model
dari
data
yang
digunakan didalam suatu perusahaan, yang
tidak
tergantung dari seluruh
pertimbangan fisik.
Perancangan Basis Data Logikal
Merupakan suatu
proses
membangun
sebuah
model
dari
data
yang
digunakan
pada
suatu
perusahaan berdasarkan pada
data
model
yang
spesifik,
tetapi
tidak
tergantung pada
Database
Management
System
(DBMS) tertentu dan pertimbangan fisik lainnya.
Perancangan Basis data fisikal
Merupakan
suatu
proses
untuk
menghasilkan sebuah
gambaran
dari
implementasi
basisdata
pada
tempat
penyimpanan
kedua,
menjelaskan
|
33
dikembangkan
harus seluruhnya
diuji.
Proses uji coba
ini dilakukan
dengan
mendapatkan efisiensi akses data dan menghubungkan beberapa batasan
integritas dan tindakan keamanan.
2.3.8.1
Perancangan Basis Data Konseptual
Langkah-langkah
dalam
metodologi
percancangan
basis
data
konseptual adalah sebagai berikut (Begg, Connolly, 2005, p442):
Langkah 1 Membangun Local Conceptual Data Model
-
Langkah 1.1 Mengidentifikasi tipe entitas
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi tipe
entitas
yang
terutama
dibutuhkan
oleh pengguna.
Satu
metode
untuk
mengidentifikasi entitas
adalah
tentukan
kebutuhan
pengguna terlebih
dahulu.
Dan
pada
langkah
ini
dilakukan
identifikasi kata benda
atau
frase
kata
benda pada
spesifikasi
kebutuhan pengguna, objek besar seperti orang, tempat, benda,
atau konsep
dapat
digunakan
untuk
mencari
tipe
entitas.
Cara
lain adalah dengan mencari objek yang bebas. (Begg, Connolly,
2005, p443)
-
Langkah 1.2 Identifikasi tipe relasi
Tujuannya
adalah
untuk
mengidentifikasi relasi
penting
yang
tersedia diantara tipe-tipe entitas (Begg, Connolly, 2005, p445)
-
Langkah
1.3
Mengidentifikasi
dan
menghubungkan
atribut
dengan entitas atau tipe relasi
Tujuannya adalah untuk menghubungkan atribut dengan entitas
atau
tipe relasi
yang
tepat.
Atribut
yang
dimiliki
oleh
setiap
|
![]() 34
entitas
dan relasi
wajib
memenuhi
karakteristik atribut
yaitu
simple/composite attribute, single/multi-valued attribute, dan
derived attribute. (Begg, Connolly, 2005, p447)
-
Langkah 1.4 menentukan domain atribut
Bertujuan
untuk
menentukan domain
atribut
didalam
local
conceptual
data model. Sebuah
domain
adalah
kumpulan
nilai
dimana satu atau lebih atribut memperoleh nilai true atau benar.
Setiap atribut di dalam relasi ditetapkan dalam domain.
(Begg,
Connolly, 2005, p450)
-
Langkah 1.5 Menentukan atribut Candidate Key dan Primary Key
Digunakan
untuk
identifikasi
candidate
key
setiap tipe entitas,
dan
jika
ada
lebih
dari
satu candidate key,
maka
akan terpilih
satu
untuk
menjadi primary
key
dan
yang
lain
akan
menjadi
alternate
key
(Begg,
Connolly, 2005,
p451).
Untuk
memilih
primary
key
diantara candidate key,
pergunakan aturan berikut
untuk membantu pemilihan primary key :
Candidate key dengan minimal kumpulan dari atribut
Candidate key dengan nilai yang paling sedikit berubah.
Candidate key dengan jumlah karakter yang paling sedikit
(untuk yang memiliki textual attributes)
Candidate
key
dengan
nilai
maximum
yang paling
kecil
(untuk yang dengan numerical attributes)
Candidate
key
yang paling
mudah
digunakan dari
sudut pandang pengguna.
|
![]() 35
-
Langkah 1.6 Pertimbangkan penggunaan dari enhanced modeling
concepts (langkah pilihan)
Tujuannya
adalah
untuk
mempertimbangkan penggunaan
dari
peningkatan
model konsep, seperti specialization /
generalization,
generalization,
aggregation,
dan composition.
Specialization
adalah
proses
memaksimalkan
perbedaan
antara
anggota
sebuah
entitas
dengan
mengidentifikasi karakteristik
yang membedakan
entitas tersebut. Generalization adalah
proses
meminimalkan perbedaan antar entitas dengan
mengidentifikasi sifat umum entitas. Aggregation menunjukkan
memiliki atau
bagian dari
relationship diantara tipe entitas,
dimana
yang
satu
menunjukkan keseluruhan
dan
bagian
(Begg, Connolly, 2005, p453).
-
Langkah 1.7 Model pemeriksaan untuk redudancy
Digunakan untuk
memeriksa conceptual
model
agar
terhindar
dari redudansi dalam model (Begg, Connolly, 2005, p453). Dua
kegiatan yang dilakukan pada hal ini adalah :
Memeriksa kembali One-to-one (1:1) Relationship.
Dalam
mengidentifikasi entitas,
mungkin
dapat
menemukan dua entitas atau lebih yang menggambarkan
objek yang sama dalam suatu organisasi.
Menghilangkan Relasi redundant
Sebuah relasi dikatakan redundant apabila informasi
yang sama dapat diperoleh pada relasi lainnya.
|
![]() 36
-
Langkah
1.8 melakukan
validasi conceptual model dengan
transaksi yang dilakukan pengguna
Untuk
memastikan
bahwa
local
conceptual
model
mendukung
transaksi
yang
dibutuhkan
(Begg,
Connolly,
2005, p456). Dua
pendekatan
yang
memungkinkan untuk
memastikan
local
conceptual data model mendukung kebutuhan transaksi :
Menggambarkan transaksi
Memeriksa semua
informasi
(entities,
relationship,
dan
attributes)
yang
dibutuhkan oleh
setiap
transaksi
dan
dihasilkan
oleh
model,
dengan
dokumentasi sebuah
penjelasan dari setiap kebutuhan transaksi.
Menggunakan transaction pathways
Melakukan validasi
data
terhadap
kebutuhan
transaksi
dengan
penggambaran diagram
yang
mewakili
pathway
yang diambil
oleh
setiap
transaksi
secara
langsung pada
diagram ER.
-
Langkah
1.9 Melihat
kembali
conceptual data model bersama
pengguna
Untuk
memastikan bahwa
data
model
adalah
merupakan
representasi yang
benar
dari
kebutuhan
dari
suatu
organisasi
(Begg, Connolly, 2005, p458).
|
37
2.3.8.2
Perancangan Basis Data Logikal
Perancangan basis
data
logika adalah suatu proses
pembangunan
sebuah
model dari data yang digunakan di dalam suatu perusahaan berdasarkan
sebuah
model
data
yang
spesifik,
tetapi
tidak
bergantung pada
suatu
DBMS
tertentu dan pertimbangan fisikal lainnya. (Begg, Connolly, 2005, p439).
Langkah-langkah perancangan basis data logikal adalah sebagai berikut
(Begg, Connolly, 2005, p462):
Langkah 2. Membangun dan melakukan validasi logical data model
Tujuannya
adalah untuk menerjemahkan
conceptual data model
kedalam logical data model dan kemudian memvalidasi model
tersebut agar benar
secara struktural dan
mampu
mendukung
transaksi-transaksi yang dibutuhkan (Begg, Connolly, 2005, p462).
Aktivitas yang ada pada langkah tersebut adalah :
-
Langkah 2.1 Menentukan Relasi-Relasi untuk logical data model
Tujuannya adalah menciptakan relasi untuk logical data model
untuk
merepresentasikan
entitas-entitas,
relasi-relasi,
dan
atribut-atribut yang telah diidentifikasikan (Begg, Connolly,
2005, p463). Relationship yang
mungkin
terjadi
pada
model
data konseptual:
Strong Entity Type
Strong Entity
Type
adalah
tipe
entitas
yang keberadaannya
tidak
bergantung (independent)
pada
beberapa
tipe
entitas
lainnya. Karakteristik dari Strong
entity type
adalah setiap
|
38
tipe
entiti
yang
terjadi
dapat
diidentifikasi secara
unik
menggunakan atribut
primary
key
dari
tipe
entitas.
Strong
entity
type
sering
disebut
dengan parent
atau
owner
atau
dominant entities (Begg, Connolly, 2005, p354).
Weak Entity type
Weak
entity
type
adalah
tipe
entitas yang
keberadaannya
bergantung (dependent)
pada beberapa
tipe
entitas
lainnya.
Weak entity type juga disebut dengan child, dependent, atau
subordinate entities (Begg, Connolly, 2005, p355).
One-to-many (1:*) binary relationship types
Untuk setiap 1:* binary relationship, entitas pada satu sisi
dari relasi dianggap sebagai entitas parent dan entitas pada
banyak
sisi
dianggap sebagai
entitas
child.
Untuk
merepresentasikan relasi
ini,
tampilkan
salinan
atribut
primary
key
dari
entitas
parent
ke
dalam relasi
yang
merepresentasikan entitas
child,
untuk
berlaku
sebagai
foreign key (Begg, Connolly, 2005, p465).
One-to-one (1:1) binary relationship types
Membuat
relasi-relasi
yang
memperlihatkan
sebuah
relasi
1:1
sedikit
lebih
kompleks karena
cardinality
tidak
dapat
digunakan
untuk
membantu
mengidentifikasi entitas-entitas
parent dan child dalam relasi (Begg, Connolly, 2005, p465).
Kita
mempertimbangkan bagaimana
menciptakan relasi-
|
39
relasi untuk merepresentasikan
participation constraint
berikut:
-
Mandatory
Participation
pada
2
sisi
dari
1:1
relationship
Pada kasus ini, harus digabungkan entitas yang terlibat
kedalam
satu
relasi
dan
memilih
salah
satu
dari
primary
key
dari
entitas-entitas aslinya
untuk
menjadi
primary
key
pada
relasi
yang
baru,
sedangkan yang
lainnya
dijadikan
alternate
key.
(Begg,
Connolly,
2005, p466)
-
Mandatory Participation pada 1 sisi dari relasi 1:1
Pada kasus ini dapat diidentifikasi
entitas-entitas
parent dan child untuk relasi 1:1 dengan menggunakan
participation
constraint.
Entitas yang
mempunyai
pilihan
participation
dalam relationship
dianggap
sebagai entitas parent,
dan
entitas
yang
mempunyai
mandatory
participation
dalam relationship
dianggap
sebagai child. (Begg, Connolly, 2005, p466)
-
Optional Participation pada 2 sisi dari 1:1 relationship
Primary key dapat dipilih berdasatkan atas kasus yang
ada (Begg, Connolly, 2005, p467)
One-to-one (1:1) recursive relationship types
Untuk sebuah 1:1 recursive relationship, ikuti aturan
yang dijelaskan
diatas untuk sebuah
1:1 relationship.
|
40
Dalam kasus
tertentu
relasi
1:1,
entity
kedua
sisi
dari
relationship
adalah sama.
Untuk
1:1
recursive
relationship dengan mandatory participation pada 2 sisi,
representasikan recursive
relationship
sebagai
relasi
tunggal dengan salinan 2
primary
key. Sedangkan salah
satu salinan dari primary key
merepresentasikan foreign
key
dan
harus
dubah
namanya untuk
menandakan
relationship yang direpresentasikan.
(Begg, Connolly, 2005, p467)
Superclass/subclass relationship types
Untuk
setiap superclass / subclass relationship dalam
conceptual
data model, dapat diidentifikasi entitas
superclass
sebagai entiti
parent
dan
entiti
subclass
sebagai
entitas
child.
Pilihan
yang
paling
sesuai
tergantung dari
sejumlah faktor
seperti
disjointnese
dan
participation
constraint
pada superclass/subclass
relationship
apakah
subclass-subclass
terlibat
dalam distinct
relationship
dan
jumlah participant dalam relasi superclass / subclass (Begg,
Connolly, 2005, p467).
Many-to-many (*:*) binary relationship types
Untuk setiap relasi biner many-to-many (*:*), buatlah
relasi
yang
mewakili
relasi dan
mencakup seluruh atribut
yang menjadi bagian dari relasi. Dilakukan penyalinan
|
41
atribut
primary key untuk entity yang berpartisipasi
didalam relasi
kedalam
relasi
yang
baru
sebagai
foreign
key (Begg, Connolly, 2005, p469) .
Complex relationship types
Untuk
setiap
relasi
kompleks, buat
sebuah
relasi
untuk
merepresentasikan relasi
dan
meliputi
semua
atribut
yang
merupakan bagian dari
relasi
tersebut.
Lalu
buat salinan
primary
key
dari
entitas
yang
berhubungan dalam relasi
kompleks
kedalam relasi
baru,
untuk
berlaku
sebagai
foreign key.
Multi-valued attributes
Untuk setiap atribut yang
memiliki banyak
nilai
yang ada
pada
entity,
buatlah
relasi
untuk
mewakili atribut
multi-
value
dan
mencakup primary
key
dari entity
pada relasi
yang
baru
sebagai foreign
key
(Begg,
Connolly, 2005,
p471).
-
Langkah 2.2 Melakukan validasi relasi dengan menggunakan
normalisasi
Tujuannya adalah
untuk
melakukan
validasi
terhadap
relasi-
relasi
dalam
logical
data
model
dengan
menggunakan teknik
normalisasi. (Begg, Connolly, 2005, p473).
Normalisasi merupakan teknik untuk menghasilkan sekumpulan
relasi-relasi dengan properti-properti
yang diinginkan, sesuai
|
42
dengan
kebutuhan data-data
yang
diberikan
oleh
suatu
perusahaan (Begg,
Connolly,
2005,
p388).
Tujuan
dari
normalisasi ini
adalah
untuk
mengurangi redudansi
data
(pengulangan data) dan update anomaly.
Update
anomaly
dibedakan menjadi
3,
yaitu
insert
anomaly,
update
anomaly,
dan modification
anomaly/update
anomaly.
Delete anomaly adalah kejanggalan yang
terjadi terhadap suatu
tabel
pada
saat
dilakukan
penghapusan suatu
record,
penghapusan bermaksud
untuk
menghapus suatu
data
tertentu
tetapi menyebabkan kehilangan informasi lain dari tabel
tersebut.
Insert
anomaly
adalah
kejanggalan yang
terjadi
terhadap
sebuah
tabel
pada
saat
dilakukan
penambahan suatu
record
yaitu
berupa
pelanggaran terhadap
batasan
integritas.
Modification/update
anomaly
adalah
kejanggalan yang
terjadi
pada suatu tabel pada saat dilakukan pengubahan suatu
rekaman. (Begg, Connolly, 2005, p392).
Proses
dari
normalisasi melewati
tahap
seperti berikut
(Begg,
Connolly, 2005, p401):
a. First normal form (1NF), yang bertujuan
menghilangkan
perulangan data
b. Second
normal
form
(2NF),
yang
bertujuan
untuk
menghilangkan ketergantungan parsial pada Primary Key.
c. Third
Normal
Form
(3NF),
yang
bertujuan
untuk
menghilangkan ketergantungan transitif pada primary key.
|
43
-
Langkah 2.3 melakukan validasi relasi pada transaksi user
Langkah
ini dilakukan untuk memastikan bahwa relasi didalam
Local
logical
data
model
mendukung
transaksi yang
dibutuhkan. (Begg, Connolly, 2005, p474).
-
Langkah 2.4 memeriksa batasan integrity
Bertujuan untuk
memeriksa batasan
integritas
yang
direpresentasikan dalam logical
data
model
(Begg,
Connolly,
2005, p474). Batasan integritas dibagi menjadi 5 bagian, yaitu :
a. Data yang dibutuhkan (Required Data)
Beberapa
atribut
harus
selalu
mengandung nilai
yang
bernilai valid, dengan kata lain, tidak boleh diperbolehkan
mempunyai nilai null.
b. Batasan domain atribut
Setiap atribut
mempunyai domain,
yaitu sekumpulan
nilai
yang pasti.
c. Multiplicity
Multiplicity
merepresentasikan batasan
yang
ditempatkan
pada relasi diantara data dalam basisdata.
d. Integritas entitas
Primary
key dari sebuah entitas tidak boleh bernilai null.
Batasan
ini
harus
dipertimbangkan ketika
kita
mengidentifikasi primary key untuk tiap tipe entitas.
|
44
e. Integritas referensial
Integritas referensial berarti jika foreign
key
berisi sebuah
nilai,
maka
nilai
tersebut
harus
menunjuk tuple
yang
ada
di dalam relasi parent. Umumnya, jika partisipasi
dari
relasi
child
dalam relationship
adalah
mandatory,
maka
nilainya tidak boleh null. Tetapi jika partisipasi dari relasi
child dalam relasi dapat dipilih, maka boleh null.
f.
Batasan umum
Pengubahan pada
entitas
mungkin
dapat
diatur
oleh
batasan-batasan
yang
mengatur transaksi real
world
yang direpresentasikan oleh perubahan tersebut.
-
Langkah 2.5 Melihat ulang model local logical data dengan
pengguna
Bertujuan untuk
melihat
kembali
logical
data
model
untuk
memastikan
bahwa
pengguna
mempertimbangkan model
data
logikal
untuk
menjadi
representasi yang
sebenarnya
dari
kebutuhan data perusahaan. (Begg, Connolly, 2005, p478).
-
Langkah 2.6 Menggabungkan Local logical data model kedalam
global model.
Langkah
ini bertujuan untuk merepresentasikan semua user
views dari database (Begg, Connolly,
2005, p479). Langkah-
langkahnya adalah sebagai berikut :
a. Melihat kembali nama dan isi datri entitas/relasi serta
candidate keys.
|
45
Bertujuan untuk mengidentifikasi munculnya dua masalah
potensial sebagai berikut :
o
Memiliki nama yang sama, tetapi sebenarnya tidak
sama (homonim)
o
Adalah sebenarnya
sama, tetapi
memiliki
nama
yang
berbeda (sinonim)
b. Melihat kembali nama dan isi dari relationship/foreign key
c. Menggabungkan entitas/relasi dari model data lokal.
d. Memasukkan
(tanpa
menggabungkan) entitas/relasi yang
unik ke dalam setiap model data
e. Menggabungkan relasi/foreign key dari local data model
f.
Memasukkan (tanpa menggabungkan) relasi / foreign key
yang unik kedalam setiap model data
g. Mengecek untuk entitas/relasi dan relasi / foreign key yang
tertinggal.
h. Mengecek foreign key
i.
Mengecek integrity constraint
j.
Menggambarkan diagram ER / relasi global
k. Melakukan update dokumentasi.
2.3.8.3
Perancangan Basis Data Fisikal
Perancangan basis data fisikal adalah proses
membuat sebuah deskripsi
dari
implementasi basis data
pada
penyimpanan
kedua;
mendeskripsikan relasi
dasar, organisasi file, dan index yang digunakan untuk mendapatkan akses
|
46
efisien pada data dan semua integrity constraint yang berhubungan dan security
measures (Begg, Connolly, 2005, p439).
Langkah-langkah perancangan fisik database adalah sebagai berikut :
Langkah 3. Menerjemahkan logical
data
model
untuk
DBMS yang
dipilih
Tujuannya adalah
untuk
menghasilkan skema basis data
relasional
dari data
model logikal yang dapat diimplementasikan dalam target
DBMS
(Begg,
Connolly, 2005,
p497).
Terdapat
3
langkah
dalam
tahap ini, yaitu :
-
Langkah 3.1 Mendesain relasi dasar
Tujuannya
adalah
untuk
memutuskan bagaimana
merepresentasikan relasi
dasar
yang
diidentifikasikan
dalam
model data logikal dalam DBMS yang dipilih (Begg, Connolly,
2005, p498).
-
Langkah 3.2 Merancang Representasi untuk Derived data
Tujuannya
adalah
untuk
memutuskan
bagaimana
merepresentasikan semua data derived
yang ada
dalam model
data logikal dalam DBMS
yang dipilih.
Atribut yang
nilainya
dapat
dicari dengan
memeriksa
nilai-nilai dari
atribut
lainnya
yang diketahui sebagai derived atau
calculate attribute
(Begg, Connolly, 2005,p499).
-
Langkah 3.3 Merancang batasan umum
Tujuannya adalah untuk merancang batasan umum pada DBMS
yang dipilih (Begg, Connolly, 2005,p501).
|
47
Langkah 4 Merancang organisasi file dan indeks
Langkah
ini
mempunyai tujuan
untuk
menentukan organisasi
file
yang optimal untuk menyimpan relasi dasar dan indeks-indeks yang
dibutuhkan untuk
tercapainya performa
yang
daopat
diterima,
dengan
begitu,
relasi
dan
tuple
akan
dapat
disimpan pada
penyimpanan kedua (Begg, Connolly, 2005, p501).
-
Langkah 4.1 Menganalisa transaksi
Tujuan pada
langkah
ini
adalah
untuk
memahami fungsi dari
transaksi-transaksi yang
akan
berjalan
pada
basis
data
dan
untuk
menganalisa
transaksi-transaksi penting
(Begg,
Connolly, 2005, p502).
-
Langkah 4.2 Memilih organisasi file
Tujuannya
adalah
untuk
menentukan sebuah
organisasi
file
yang efisien untuk relasi dasar (Begg, Connolly, 2005, p506).
-
Langkah 4.3 Memilih index-index
Tujuan
dari
langkah
ini
adalah
untuk
menentukan apakah
dengan
menambahkan
indeks-indeks akan
meningkatkan
kemampuan dari suatu sistem (Begg, Connolly, 2005, p508).
-
Langkah 4.4 Memperkirakan kebutuhan disk space
Tujuannya adalah untuk memperkirakan nilai dari disk space
yang dibutuhkan oleh basisdata (Begg, Connolly, 2005, p514).
|
![]() ![]() 48
Langkah 5. Merancang pandangan user.
Tujuannya adalah
untuk
merancang
pandangan
pengguna
yang
diidentifikasikan selama
pengumpulan
kebutuhan
dan
tahapan
analisis dari
database
system
development
lifecycle
(Begg,
Connolly, 2005, p515).
Langkah 6. Merancang mekanisme keamanan
Tujuannya
adalah
untuk
merancang mekanisme keamanan
untuk
basis
data
seperti
yang
ditentukan oleh
pengguna
pada
saat
pengumpulan kebutuhan dari database system development lifecycle
(Begg, Connolly, 2005, p516).
2.3.9
Entity-Relationship Modeling
2.3.9.1
Entity Types
Entity type adalah sekumpulan objek dengan properti yang sama, yang
diidentifikasikan oleh
perusahaan
serta
keberadaannya
yang
mandiri
(Begg,
Connolly, 2005,
p343).
Sedangkan entity
occurance
adalah
setiap
objek
yang
diidentifikasikan secara unik.
Gambar 2.3 Representasi Diagram dari tipe entity staff dan Branch
(Begg, Connolly, 2005, p345)
|
49
2.3.9.2
Relationship Type
Relationship Type adalah sekumpulan hubungan yanng mempunyai arti
diantara
tipe
entiti
(Begg,
Connolly,
2005,
p346).
Setiap
tipe
relasi
memiliki
nama yang
menjelaskan fungsinya.
Derajat dari relationship adalah jumlah dari
partisi tipe entitas dalam sebuah tipe relationship tertentu.
2.3.9.3
Atribut
Atribut adalah suatu properti dari sebuah entitas atau tipe relasi (Begg,
Connolly, 2005,
p350).
Domain
attribute
adalah
sekumpulan
nilai
yang
diperbolehkan untuk satu atau banyak atribut.
Atribut dapat diklasifikasikan sebagai berikut :
1. Simple dan Composite Attribute
Simple
attribute
adalah sebuah atribut yang
disusun
oleh
sebuah
komponen
tunggal
dengan
keberadaan yang
tidak
tergantung. Simple
attribute
tidak
dapat
dipecah
menjadi
komponen yang lebih kecil lagi (Begg, Connolly, 2005,
p351).
Composite attribute adalah sebuah atribut yang disusun oleh
banyak komponen, setiap komponen yang ada tersebut tidak
tergantung/mandiri. Atribut ini dapat dipecah menjadi atribut
yang lebih kecil.
2. Single-valued dan multi-valued attribute
Single-valued
attribute
adalah sebuah atribut yang
memegang
nilai
tunggal
dari
setiap
kejadian
dalam
sebuah
tipe
entitas (Begg, Connolly, 2005,
p351).
Multi-valued
|
50
attribute
adalah
sebuah
atribut
yang
mempunyai
nilai
lebih
dari
satu
untuk
setiap
kejadian pada
sebuah
tipe
entiti.
Contohnya pada
setiap
atribut
entity
Branch
dapat
mempunyai telNo
lebih
dari
satu
(misalnya
cabang
dari
BranchNo B003 mempunyai telNo 0141-339-2178 dan 0141-
339-4439).
3. Derived attributes
Derived
attribute
adalah atribut yang
merepresentasikan
sebuah
nilai yang bisa diperoleh dari suatu
nilai atribut atau
sekelompok
atribut
yang
berkaitan, dan
tidak
harus
berasal
dari satu entitas(Begg, Connolly, 2005, p352).
2.3.9.4 Keys
Candidate
key
adalah
kumpulan atribut
minimal
yang
secara
unik
mengidentifikasikan
setiap
kejadian
dari
sebuah
tipe
entity (Begg,
Connolly,
2005,
p352).
Primary
key
adalah candidate
key
yang
dipilih untuk
mengidentifikasikan secara
unik
setiap
kejadian
dari
sebuah
tipe
entitas.
Composite
key
adalah sebuah candidate
key
yang
terdiri
dari
dua
atau
lebih
atribut. Alternate
key
adalah
candidate
key
yang tidak
dipilih
menjadi
primary
key.
2.3.10 Normalisasi
Normalisasi
adalah
sebuah
teknik
untuk
menghasilkan relasi
dengan
properti-properti yang
diinginkan,
memberikan
kebutuhan
data
dari
sebuah
perusahaan
(Begg, Connolly,
2005, p388). Tujuan normalisasi
adalah untuk
|
51
mengidentifikasi sekumpulan relasi yang benar dan diperlukan oleh perusahaan.
Karakteristik dari sekumpulan relasi yang benar adalah sebagai berikut :
1.
Jumlah
atribut
yang
minimal yang
berguna untuk
mendukung
kebutuhan data dari perusahaan
2.
Atribut
dengan
relasi
logikal
yang
dekat
(dijelaskan sebagai
ketergantungan fungsional) ditemukan pada relasi yang sama
3. Redudansi minimal
dengan setiap atribut
direpresentasikan
hanya
sekali
dengan
pengecualian
atribut
penting
dalam
bentuk
semua
atau
bagian
foreign
key
yang
diperlukan untuk
menggabungkan
relasi yang terkait.
Terdapat 3
tahap
dalam
proses
normalisasi
sehingga disebut
dengan
tabel yang normal apabila sudah melewati ketiga tahapan ini.
a. First Normal Form (1NF)
First
Normal
Form
adalah
relasi
dimana
pertemuan
antar
setiap
baris dan kolom terdiri satu dan hanya satu nilai. Kondisi ini dapat
diperoleh
dengan
melakukan eliminasi
terjadinya
data
ganda
(repeating
group). Pada kondisi
normal
pertama
ini
kemungkinan
masih terjadinya adanya rangkap (Begg, Connolly, 2005, p403).
b. Second Normal Form (2NF)
Aturan
pada
normalisasi ini
adalah
sebuah
relasi
dalam
bentuk
normal
pertama dan
setiap
atribut
yang
bukan
primary
key
bergantung secara
fungsional
penuh
kepada
primary
key
(Begg,
Connolly, 2005, p407).
|
![]() 52
c. Third Normal Form (3NF)
Third
Normal Form
adalah sebuah relasi
yang
telah
berada pada
bentuk
normal
tahap
pertama
dan
kedua dimana
semua
tidak
ada
lagi
atribut
yang
bukan
primary
key
bergantung secara
transitif
kepada primary key (Begg, Connolly, 2005, p409).
Pada tahap ini,
atribut
yang tidak
memberikan kontribusi terhadap
penjelasan
karakteristik primary
key,
akan
dipindahkan kesebuah
tabel
yang terpisah.
Keuntungan dari
tabel
relasional dalam
3NF
adalah menghilangkan data yang berulang-ulang dengan tujuan
menghemat tempat dan mengurangi keanehan manipulasi.
2.3.11 DFD
DFD
adalah
sebuah
model
proses
yang digunakan untuk
menggambarkan
aliran data yang
lewat dari
sebuah sistem dan
bekerja atau proses ditampilkan dari
sistem tersebut (Whitten, Bentley, Dittman, 2004, p344).
Komponen-komponen DFD adalah sebagai berikut:
No
Nama
Simbol
Keterangan
1
Eksternal agents
Menjelaskan batas luar dari sebuah sistem
yang berperan dalam sistem. Bentuk ini
mengikuti aturan dari DeMarco/Yourdon.
2
Proses
Proses menggambarkan kegiatan yang akan
diselesaikan
atau melakukan proses dari
kerangka informasi. Bentuk
ini
mengikuti
aturan dari DeMarco/Yourdon.
3
Arus data
Arus data menjelaskan aliran data, dapat
berperan sebagai masukan (input) atau
|
![]() 53
keluaran (output), dari dan menuju proses
4
Penyimpanan data
(Data Storage)
Penyimpanan data terkadang disebut dengan
basis data (database), digunakan untuk
menyimpan data yang akan dipakai untuk
proses selanjutnya. Bentuk ini mengikuti
aturan dari DeMarco/Yourdon.
Tabel 2.1 Tabel Komponen-Komponen DFD
Tingkatan dalam DFD (Schell, McLeod, 2007, p200), yaitu :
1. Diagram Konteks
Menempatkan sistem dalam konteks lingkungannya. Diagram terdiri dari
symbol proses
tunggal.
Diagram terdiri dari simbol proses tunggal
yang
menggambarkan keseleruhan dari sistem.
2. Diagram Nol
DFD
yang
levelnya
berada
dibawah
diagram konteks
dan
merepresentasikan gambaran
level
tertinggi
dari
fungsi
utama
didalam
sistem.
3. Diagram Gambar n
Mendokumentasikan sistem
yang
lebih
detail
dibandingkan
dengan
diagram
nol.
Huruf
n
menunjukkan jumlah
proses
yang
sedang
didokumentasikan pada tingkat berikutnya yang lebih tinggi.
2.3.12 State Transition Diagram (STD)
|
![]() ![]() 54
State
Transition
Diagram (STD)
adalah
sebuah
alat
yang
digunakan
untuk
menggambarkan suatu urutan dan variasi tampilan yang dapat terjadi saat pengguna
menjalankan sistem (Whitten, Bentley, Dittman, 2004, p673).
Simbol-simbol yang digunakan dalam STD :
No
Simbol
Keterangan
1
Digunakan
untuk
menunjukkan
layar
tampilan (display screen)
2
Digunakan
untuk
menunjukkan
aliran
kendali dan kejadian pemicu (trigger) yang
menyebabkan tampilan menjadi aktif
Tabel 2.2 Tabel Simbol-Simbol STD
2.3.13 Arsitektur Basis Data Oracle
Menurut Loney dan Bryla (2005,p6-8), datafiles dalam basis data
Oracle dikelompokkan bersama menjadi satu atau lebih tablespace. Dalam setiap
tablespace, struktur logikal basis data, seperti tabel dan
indeks yang merupakan
penyimpanan
yang memungkinkan
Oracle untuk memiliki
kontrol
yang
lebih
efisien atas penggunaan ruang disk.
Tablespace
Oracle tablespace terdiri dari satu atau lebih datafiles; sebuah datafiles
dapat menjadi bagian dari satu dan hanya satu tablespace. Untuk instalasi Oracle
10g,
minimal dibtuhkan dua
tablespace
dibuat: SYSTEM
tablespace
dan
SYSAUX tablespace.
|
55
Oracle 10g
memungkinkan anda untuk
membuat tablespace jenis
khusus
yang
disebut bigfile
tablespace,
yang
dapat
sebesar
8EB
(exabyte atau
juta tetrabytes). Menggunakan bigfiles
membuat manajemen tablespace menjadi
transparan untuk
DBA;
dengan
kata
lain,
DBA
dapat
mengelola
tabespace
sebagai
sebuah
unit
tanpa
khawatir tentang
ukuran
dan
struktur
datafiles
yang
mendasarinya.
Jika
sebuah
tablespace
yang
bersifat
sementara maka
tablespace
itu
sendiri adalah permanen; hanya segmen yang tersimpan dalam tablespace
yang
bersifat sementara. Sebuah temporary tablespace dapat digunakan untuk operasi
penyortiran
dan
sebagai
area
kerja
untuk
membangun
indeks. Mendedikasikan
sebuah
tablespace
untuk
operasi
semacam
ini
membantu
mengurangi I/O
contention
antara
sementara segmen-segmen temporary
dan
segmen
permanen
tersimpan dalam tablespace lain, contohnya tabel.
Tablespace
dapat
dikelola dengan
kamus
atau
dikelola secara
lokal.
Dalam
tablespace
yang dikelola oleh
kamus,
manajemen
extent
tercatat
dalam
tabel
kamus
data.
Oleh
karena
itu,
bahkan jika
semua
tabel
aplikasi ada
di
tablespace
USERS,
tablespace
SYSTEM
masih
akan
dapat
diakses untuk
mengelola DML pada tabel aplikasi. Karena semua pengguna dan aplikasi harus
menggunakan tablespace SYSTEM untuk manajemen extent, hal ini menciptakan
hambatan
yang potensial untuk
menulis
aplikasi
yang
intensif. Pada tablespace
yang dikelola secara lokal, Oracle memelihara suatu bitmap dalam setiap datafile
dari tablespace
untuk
melacak ketersediaan ruang. Hanya kuota dikelola dalam
kamus data, secara dramatis mengurangi contention pada kamus data tabel.
Blok
|
56
Blok
basis
data
adalah
unit
terkecil
penyimpanan dalam
basis
data
Oracle.
Ukuran
blok
adalah
jumlah
byte
dari
penyimpanan dalam
tablespace
tertentu dalam basis data.
Satu
blok
biasanya
merupakan
kelipatan
dari
sistem
operasi
ukuran
blok
untuk
memfasilitasi I/O
disk yang efisien. Ukuran
blok
default ditetapkan
oleh Oracle parameter
inisialisasi DB_BLOCK_SIZE.
Sebanyak
empat lainnya
ukuran
blok
dapat
didefinisikan untuk
tablespace
lainnya
dalam
basis
data,
meskipun blok di SYSTEM, SYSAUX, dan setiap tablespace temporary harus dari
ukuran DB_BLOCK_SIZE.
Extent
Extent adalah tingkat berikutnya
dari pengelompokan
logika dalam
basis data. Sebuah extent terdiri dari satu atau lebih blok basis data. Ketika objek
basis
data
diperbesar,
ruang
akan
ditambahkan ke
objek
tersebut
yang
akan
dialokasikan sebagai sebuah extent.
Segments
Tingkat berikutnya dari pengelompokan logika dalam basis data adalah
segment.
Sebuah segment
adalah sekelompok extents
yang
meliputi objek basis
data yang
diperlakukan sebagai
satu
unit,
seperti tabel
atau
indeks.
Akibatnya,
hal
ini biasanya merupakan unit terkecil penyimpanan yang pengguna akhir dari
basis
data akan
menangani. Empat
jenis segment yang ditemukan di basis data
Oracle:
data
segment,
indeks
segment,
temporary
segment,
dan
rollback
segment.
Data segment
|
57
Setiap
tabel
dalam
basis
data
berada
dalam
satu
data
segmen
yang
terdiri dari satu atau lebih extent; lebih dari satu segmen dialokasikan untuk tabel
jika tabel tersebut merupakan tabel yang dipartisi atau tabel cluster.
Index segment
Setiap indeks disimpan dalam segmen indeks sendiri. Seperti pada tabel
yang dipartisi, setiap partisi dari indeks yang dipartisi disimpan dalam segmen
sendiri.
Temporary segment
Ketika pernyataan SQL seorang pengguna mebutuhkan ruang disk
untuk menyelesaikan operasi, seperti operasi penyortiran yang tidak dapat
dimuat
dalam
memori
yaitu temporary
segment
yang
dialokasikan. Temporary
segment ada hanya untuk durasi pernyataan SQL.
Rollback segment
Sebagai Oracle
10g,
rollback
segment
hanya
ada
di
tablespace
SYSTEM,
dan
biasanya
DBA
tidak
perlu
mempertahankan SISTEM
rollback
segment. Oracle yang rilis sebelumnya,
sebuah rollback segment diciptakan
untuk
menyimpan nilai-nilai
sebelumnya dari
sebuah
operasi
DML
basis
data
dalam
kasus
transaksi
dilaukna
rollback,
dan
untuk
memelihara data
image
"sebelum"
untuk
menyediakan read-consistent
views
dari
data
tabel
untuk
pengguna lain mengakses tabel. Rollback segment juga digunakan selama proses
pemulihan basis data
untuk
memutar kembali
terikat
transaksi
yang aktif
pada
saat jatuh contoh basis data atau dihentikan mendadak.
Di Oracle 10g, Automatic Undo Management menangani alokasi secara
otomatis dan pengelolaan pengembalian segment dalam suatu
undo tablespace.
|
58
Dalam satu
undo
tablespace,
maka
akan
dibatalkan
segment
yang
terstruktur
mirip
dengan
pengembalian segment,
kecuali
bahwa
secara
rinci
bagaimana
segment ini dikelola berada di bawah kendali dari Oracle, bukan dikelola (sering
tidak efisien) oleh
DBA. Otomatis membatalkan segment yang tersedia menatap
dengan Oracle 9i, tetapi dikelola secara manual rollback segment masih tersedia
di
Oracle
10g.
Namun,
fungsi
ini
is
deprecated
sebagai Oracle
10g
dan
tidak
akan lagi tersedia di masa mendatang.
2.3.14 Estimating Disk Space Requirements
Terdapat empat langkah untuk menghitung ruang yang dibutuhkan:
1. Menghitung total block header size
Langkah pertama untuk menghitung ukurang dari
block header :
totalBlockHeaderSize =
fixedHeaderSize +
fixedTransactionHeader
+
variableTransactionHeader + dataHeader
fixedHeaderSize = KCBH + UB4
fixedTransactionHeader = KTBBH
variableTransactionHeader = KTBIT*(INITTRANS 1)
dataHeader = KDBH
parameter KCBH,
UB4,
KTBBH, KTBIT,
KDBH bisa
didapat
dari
tabel system v$type_size, dan INITTRANS untuk
tabel non-clustered
dalam sebuah platform NT bernilai = 1, maka kita akan mendapat :
totalBlockHeaderSize = (20 + 4) + 48 + 24 * ( 1 1 )+ 14 = 86
2. Menghitung ruang yang tersedia untuk tiap blok data
|
59
Dalam satu
undo
tablespace,
maka
akan
dibatalkan
segment
yang
terstruktur
sebuah blok data :
availableDataSpace = ROUNDUP ((BlockSize
totalBlockHeaderSize) * (1 PCTFREE/100) KDBT
PCTFREE
adalah
persentase
dari
ruang
yang
dipesan
dalam
sebuah
blok
untuk
mengupdate. Untuk sebuah non-clustered table dalam
sebuah
NT
platform
dengan
PCTFREE =
10,
maka
kita
akan
mendapatkan:
availableDataSpace = (8192 86)*(1 10/100) 4 = 7292
3. Menghitung ruang yang digunakan tiap row
Untuk
menghitung ruang data
yang terkombinasi dan dibutuhkan
rata-
rata untuk tiap row. Hal ini bergantung pada:
Jumlah kolom pada definisi tabel
Tipe data yang digunakan tiap kolom
Total ukuran kolom, termasuk jumlah byte, dihitung dengan cara
sebagai berikut :
totalColumnSize = columnSize + (1, if
column size < 250, else 3)
Ukuran row dihitubng sebagai berikut :
totalRowSize = rowHeaderSize + ?totalColumnSize
Dimana rowHeaderSize = 3 bytes tiap row pada non-clustered table (4
bytes
untuk tiap row pada sebuah clustered
table).
Apabila nilai
yang
dihitung
lebih
kecil
dari
nilai dari
ukuran
row,
maka
akan digunakan
nilai minimum row size.
|
60
4. Menghitung jumlah total row yang akan dimasukkan dalam sebuah blok
data
Kita
dapat
menghitung
jumlah
total
row yang
akan
dimasukkan
ke
dalam blok data dengan cara sebagai berikut :
noRowsPerBlock = ROUNDOWN(availableDataSpace/totalRowSize)
(http://wps.pearsoned.co.uk/wps/media/objects/1538/1575733/appendix
/Appendix_H.pdf)
2.4
Teori-Teori Pendekatan Analisis Sistem
2.4.1
Pendekatan Model-Driven Analysis
Structured
analysis,
information
engineering,
dan object-oriented
analysis
adalah
contoh
dari
analisis
model-driven.
Analisis model-driven
menggunakan
gambar-gambar
untuk
mengkomunikasikan permasalahan
bisnis,
kebutuhan-
kebutuhan,
dan
solusi-solusi. Contoh
model-model yang
mungkin
sudah
dikenal
seperti flowcarts, structure atau hierarchy charts, dan organization charts.
2.4.1.1 Structure Analysis
Structured
analysis
adalah
salah
satu
pendekatan formal
untuk
menganalisa sistem atau sistem informasi. Structured analysis memusatkan pada
alur dari data dalam bisnis dan proses piranti lunak. Structured analysis disebut
sebagai process-centered.
Structured analysis termasuk sederhana
secara konsep. Structured
analysis
menggambarkan sebuah seri dari model proses
yang disebut data flow
diagram yang mengambil proses pada sistem yang ada dengan input, output dan
file yang ada dalam sistem tersebut.
|
61
2.4.1.2 Information Engineering dan Data Modeling
Banyak organisasi yang mengembangkan dari pendekatan structured
analysis menjadi pendekatan information engineering. Information engineering
memusatkan pada struktur dari penyimpanan data dalam sebuah sistem. Model
data dalam information engineering disebut entity relationship diagrams.
2.4.1.3 Object-Oriented Analysis
Object-Oriented
Analysis
adalah sebuah teknik
model-driven
yang
mengintegrasikan data dan proses
yang
menekankan pada gagasan
yang disebut
objects.
Model
Object-Oriented
Analysis
adalah
gambaran yang
mengilustrasikan sistem
objek
dari
berbagai
perspektif,
seperti
structure,
behaviour,
dan
interaction
antar
objek. Model objek
dalam
Object-Oriented
Analysis menggunakan Unified Modeling Language Standard.
|
62
2.5
Teori-Teori Pendukung
2.5.1
Teori Pengiriman Barang
Terdapat beberapa istilah dalam proses pengiriman barang, diantaranya
adalah sebagai berikut :
a. Airway Bill (AWB)
Air Waybill (AWB) merupakan dokumen yang dibuat oleh atau atas nama
pengirim
(shipper)
yang
membuktikan kontrak
antara
pengirim
dan
pembawa
(carrier)
untuk
pengiriman barang
sesuai
dengan
rute
pengiriman. AWB
merupakan dokumen pengiriman
yang paling penting
dan
diperkenalkan pada
konfrensi
WARSAWA
pada
tahun
1929. AWB
menetapkan kewajiban
hukum
dari
pembawa
(carrier) dan
pembatasan
kompensasi, hak dan kewajiban dari pengirim, penerima, dan pembawa
yang tidak dapat dinegosiasi.
GARUDA.htm)
b. Cargo Handling
Cargo
atau
kargo
dapat
diartikan sebagai
semua
barang
(goods)
yang
dikirim
melalui
udara
(pesawat), laut
(kapal),
dan
darat
(truk)
yang
biasanya
untuk
diperdagangkan,
baik
antarwilayah/kota
didalam
negeri
maupun
antarnegara
(internasional). Apapun
jenis
barangnya,
semua
barang
kiriman-kecuali
benda
pos
dan
bagasi
penumpang-baik yang
diperdagangkan ataupun
keperluan
lainnya
(non
komersial)
dan
dilengkapi
dengan
dokumen
pengangkutan (SMU
atau
Airway
Bill)
dikategorikan
sebagai
kargo.
Cargo
handling
berkaitan
dengan
|
63
penanganan kargo
dengan
urutan
penyajian
dimulai
dari
aktifitas
pengiriman
barang,
penggolongan jenis
kargo,
cargo
rate,
serta
perhitungan sewa gudang. (Warpani, Majid, 2009, p95).
c. Freight forwarder/Agents
Ada tiga pihak utama yang terkait dengan pengiriman kargo, yaitu pihak
pengirim (shipper)
dan
atau
pihak
penerima
(consignee);
pihak
pengangkut (carrier);
dan
pihak ground
handling
dan
atau
warehouse
operator. Shipper bisa berupa perorangan, badan usaha, dilakukan secara
langsung tanpa perantara, atau
melalui
jasa ekspedisi pengiriman barang
yang dikenal dengan istilah freight forwarder atau ekspedisi muatan
kapal laut atau ekspedisi muatan pesawat udara. Istilah agen kargo
dewasa
ini
sudah
berkembang menjadi
freight
forwarding
atau
freight
forwarder, baik airfreight maupun seafreight.
d.
IATA
IATA
singkatan dari
International
Air
Transport
Association
atau
Asosiasi
Angkutan
Udara
Internasional.
IATA
bermarkas
di
Montreal
dan
Jenewa.
IATA
merupakan
asosiasi
internasional swasta
dari
perusahaan penerbangan berjadwal. Walaupun swasta dari segi teknisnya,
IATA
juga
dipengaruhi oleh
kepentingan negara
anggotanya
karena
kebanyakan dari perusahaan penerbangan
yang
menjadi
anggotanya
itu
dikendalikan oleh pemerintah negaranya masing-masing (Warpani,
Majid, 2009, p302).
e. SLA
|
64
Service
Level
Agreement
adalah
perjanjian antara
penyedia
jasa
dan
pengguna jasa terdadap jasa layanan yang akan diberikan/ diterima.
Dalam perjanjian
tersebut,
biasanya
diuraikan
secara rinci elemen
layanan, antara lain :
-
Lingkup pekerjaan/layanan
-
Masa berlaku perjanjian
-
Waktu response terhadap permintaan pelanggan
-
Tingkat kinerja
Tingkat layanan yang diberikan/ diterima merupakan kesepakan bersama
|