|
BAB 2
LANDASAN TEORI
2.1
Teori
Umum
Merupakan teori - teori pokok yang merupakan teori landasan bagi teori -
teori lainnya yang terdapat dalam skripsi ini, yaitu:
2.1.1
Pengertian Sistem
Menurut O’Brien (2003, p8) sistem dapat didefinisikan secara sederhana
sebagai
kumpulan
dari
elemen-elemen yang
saling
berkaitan
dan
berinteraksi
membentuk kesatuan yang utuh.
Menurut
Hall
(2001,
p5)
sistem adalah
sekelompok
dua
atau
lebih
komponen-komponen yang saling berkaitan (interrelated)
atau
subsitem-
subsistem yang bersatu untuk mencapai tujuan yang sama (common purpose).
Menurut Mulyadi (2001, p5) sistem adalah suatu jaringan prosedur yang
dibuat menurut pola yang terpadu untuk melaksanakan kegiatan pokok
perusahaan.
Berdasarkan
pengertian-pengertian
sistem diatas,
maka
dapat
ditarik
kesimpulan bahwa sistem adalah suatu rangkaian proses atau sekelompok elemen
yang terintegrasi untuk melaksanakan kegiatan pokok perusahaan untuk
mencapai tujuan dan target.
8
|
|
9
2.1.2
Database
2.1.2.1 Pengertian Database
Menurut Gerald V. Post (2005, p2), database merupakan kumpulan dari
data yang disimpan dalam format yang telah distandarisasikan, didesain untuk
dibagikan oleh banyak user.
Menurut Connolly (2005, p15) database adalah sebuah koleksi data yang
dipakai bersama dan terhubung secara logis dan deskripsi dari data ini dirancang
untuk memenuhi kebutuhan informasi dari sebuah organisasi.
Jadi, dapat disimpulkan bahwa database merupakan kumpulan data
dalam file-file yang terdiri dari atribut-atribut, entity-entity, dan relationship dari
informasi sebuah perusahaan yang dirancang
untuk
memenuhi
kebutuhan
informasi dari sebuah organisasi.
2.1.3
Database Management System (DBMS)
2.1.3.1 Pengertian Database Management System
Menurut Jeffery, Lonnie dan Kevin (2004, p524), Database Management
System (DBMS) adalah perangkat lunak khusus yang digunakan untuk membuat,
mengontrol, dan mengelola sebuah database.
Menurut Gerald V. Post (2005, p2), Database Management System
(DBMS)
merupakan
software yang
mendefinisikan
database,
menyimpan
data,
mendukung query language,
menghasilkan
report, dan membuat data entry
screen.
|
|
10
Menurut
Connolly
(2005,
p16) Database
Management System (DBMS)
adalah
sebuah
sistem perangkat
lunak
yang
memungkinkan
user
untuk
mendefinisikan, membuat, memelihara, dan mengendalikan akses ke dalam basis
data.
Jadi, dapat disimpulkan bahwa Database
Management
System
adalah
suatu sistem perangkat lunak (software) yang digunakan untuk
mendefinisikan,
membuat, memelihara/mengontrol, serta mengelola/mengendalikan akses ke
dalam database yang saling bersangkutan.
Sebuah DBMS biasanya memberikan fasilitas-fasilitas sebagai berikut :
1.
Terdapat fasilitas yang memungkinkan user untuk mendefinisikan
basisdata,
biasanya
melalui
sebuah
Data
Definition Language
(DDL),
DDL
memungkinkan user
untuk
menspesifikasikan
tipe data
dan
struktur
data
dan
batasan dari data yang akan disimpan ke dalam basisdata.
2. Terdapat fasilitas yang memungkinkan user untuk melakukan insert,
update,
delete,
dan
mengambil
data
dari
basis
data, biasanya
melalui
sebuah
Data Manipulation Language (DML). Biasanya terdapat fasilitas untuk melayani
pengaksesan data yang dinamakan
query language. Bahasa query
yang paling
diakui adalah Structured Query Language (SQL), yang merupakan standar
bahasa formal dan de fakto bagi DBMS relasional.
|
 11
Gambar 2.1 Typical DBMS Architecture
2.1.3.2 Komponen DBMS Environment
DBMS
Environment
mempunyai
komponen
diantaranya
adalah
:
(Connolly, 2005, p19-24)
|
|
12
1. Hardware
a. Meliputi PC sampai dengan jaringan komputer.
b.
Tempat penyimpanan
secondary
(magnetic disk),
I/O
device ex
:
disk
drives, device Controller, I/O Channels dan lainnya.
c.
Hardware processor dan main memory, digunakan untuk mendukung
saat eksekusi sistem software database.
2. Software
DBMS, operating system, network software (jika diperlukan) dan
program aplikasi pendukung lainnya.
3. Data
a. Data pada
sebuah sistem
database
baik
itu single-user system maupun
multi-user
system
harus
terintegrasi
dan
dapat
digunakan
bersama
(Integrated
and Shared).
b. Digunakan oleh organisasi dan deskripsi dari data disebut schema.
4. Procedures
Instruksi
dan
aturan
yang
harus
disertakan
dalam
mendesain
dan
menggunakan database dan DBMS.
|
|
13
5.
People
People ada 5 orang yaitu :
a.
DA (Data Administrator), seseorang yang berwenang untuk membuat
keputusan strategis dan kebijakan mengenai data yang ada.
b.
DBA (Database Administrator), menyediakan dukungan teknis untuk
implementasi keputusan tersebut, dan bertanggungjawab atas keseluruhan
kontrol sistem pada level teknis.
c.
Database Designer
-
Logical
Database
Designer,
bertugas
untuk
mengidentifikasi
data(entitas
dan
atribut),
hubungan
antar
data
dan
constraint
pada
data yang disimpan dalam database
-
Physical
Database
Designer,
memutuskan
bagaimana
rancangan
database logikal direalisasikan secara fisik
•
Mapping rancangan database logikal ke dalam suatu set tabel dan
integrity constraints
•
Pemilihan struktur tempat penyimpanan yang spesifik dan metode
akses supaya data mencapai performa yang baik
•
Perancangan keamanan yang dibutuhkan pada data
d.
Application Programmers, bertanggungjawab untuk membuat aplikasi
database
dengan menggunakan bahasa pemrograman
yang
ada,
seperti
:
C++,
Java, dan lainnya.
|
|
14
e. End Users, siapapun yang berinteraksi dengan sistem secara online
melalui workstation/terminal.
-
Naive users, mengakses program aplikasi untuk membuat operasi
semudah
mungkin. User
ini
menggunakan operasi
database dengan
memasukkan perintah yang sederhana dengan memilih opsi dari
menu.
-
Sophisticated
users.
User
ini
familiar
dengan struktur
database
dan
fasilitas
yang ditawarkan oleh
DBMS. Sophisticated end-users boleh
menggunakan
bahasa query
level
tinggi
seperti
SQL
untuk
menjalankan operasi yang dibutuhkan.
2.1.3.3 Komponen DBMS
DBMS mempunyai komponen diantaranya adalah : (Connolly, 2005,
p53-55)
1.
Query Processor,
merupakan komponen utama dalam DBMS
yang
merubuah query kedalam bahasa
instruksi
tingkat rendah
yang ditujukan untuk
database manager.
2. Database Manager (DM), DM berhadapan dengan program aplikasi dan
query
yang
diajukan
oleh
user.
DM
menerima query
dan
memeriksa
skema
eksternal dan konseptual untuk menentukan record konseptual apa yang dapat
memenuhi permintaan user.
|
|
15
Komponen software utama dalam DM :
a. Authorization Control, modul
ini
memeriksa bahwa
user
memiliki
otorisari yang dibutuhkan untuk melakukan transaksi.
b.
Command Processor, ketika sistem telah memeriksa otorisasi user, maka
hak pengawasan dialihkan pada command processor.
c. Integrity Checker, untuk operasi yang menyebabkan perubahan database,
integrity
checker memeriksa
bahwa
operasi
yang diminta memenuhi batasan-
batasan integritas yang ada.
d. Query
Optimizer,
modul
ini
menentukan
strategi
yang
paling
optimal
untuk eksekusi query.
e.
Transaction
Manager,
modul
ini
menampilkan
proses
yang
diinginkan
dari suatu operasi.
f.
Scheduler, modul
ini bertanggung
jawab
untuk memastikan bahwa
operasi terhadap database
yang berurutan tidak mengalami konflik satu dengan
lainnya.
g.
Recovery Manager, modul ini memastikan database selalu berada pada
kondisi yang konsisten jika terjadi kesalahan.
h.
Buffer
Manager,
modul
ini
bertanggung
jawab
untuk
mentransfer
data
antara main memory dan secondary storage.
3. File Manager, memanipulasi file-file dasar yang tersimpan dan mengatur
alokasi tempat penyimpanan.
4.
DML
Processor,
modul
ini
mengkonversikan
pernyataan
DML
dalam
program aplikasi ke bentuk standar dari bahasa host.
|
|
16
5. DDL Compiler, mengkonversikan pernyataan DDL kedalam sekumpulan
tabel-tabel yang berisikan meta-data. Tabel-tabel ini tersimpan di katalog sistem
dan informasi pengawasannya disimpan pada file header data.
2.1.3.4 Keuntungan DBMS
Adapun keuntungan DBMS menurut Connolly (2005, p26-29) adalah :
1. Penggunaan data bersama (The Data Can Be Shared).
2. Mengurangi kerangkapan data (Redudancy Can Be Reduced).
3. Menghindari ketidakkonsistenan data (Inconsistency Can Be Avoided).
4. Integritas data terpelihara (Integrity Can Be Maintained).
5. Keamanan terjamin (Security Can Be Enforced).
6.
Kebutuhan user
yang kompleks dapat teratasi (Balanced conflicting
requirements).
7. Pelaksanaan standarisasi (Standards Can Be Enforced).
8. Meningkatkan produktivitas (Increased productivity).
9.
Layanan
back
up
dan
recovery
semakin
baik
(Improved
back
up
and
recovery services).
2.1.3.5 Kerugian DBMS
Adapun kerugian DBMS menurut Connolly (2005, p29-30) adalah :
1. Kompleksitas
2. Memerlukan size/ukuran software yang besar.
3. Biaya dari suatu DBMS sangat mahal.
|
|
17
4.
Biaya penambahan perangkat keras.
5.
Biaya konversi tinggi.
6.
Performa sistem dapat tidak sesuai dengan keinginan.
7.
Menimbulkan pengaruh yang besar pada perusahaan jika
terjadi
kegagalan pada sistem.
2.1.3.6 Fungsi-Fungsi DBMS
Adapun fungsi-fungsi DBMS menurut Connolly (2005, p48-52) adalah :
1.
Penyimpanan, pengambilan dan perubahan data.
2.
Katalog yang dapat diakses oleh pengguna.
3.
Dukungan transaksi.
4.
Layanan kontrol konkurensi.
5.
Layanan recovery.
6.
Layanan kepemilikan (Authorization Services).
7.
Dukungan komunikasi data.
8.
Layanan integrasi.
9.
Layanan untuk peningkatan independensi data.
10.
Layanan utilitas.
|
 18
2.1.3.7 ANSI-SPARC three-level architecture
User 1
User 2
User n
External level
Conceptual level
Internal level
View 1
View 2
View n
Conceptual
schema
Internal
schema
Physical data organization
Database
Gambar 2.2
ANSI-SPARC three-level architecture
External level
Merupakan
pandangan
user
terhadap
database.
Level
ini
menjelaskan
bagian
dari database yang relevan kepada tiap user.
Conceptual level
Merupakan pandangan komunitas terhadap database. Level ini menjelaskan data
apa yang disimpan dalam database dan hubungan antar data
|
|
19
Internal level
Merupakan
representasi
fisik
dari
database
pada
komputer.
Level
ini
menjelaskan bagaimana data disimpan dalam database.
2.1.3.8 Data Definition Language (DDL)
Menurut Jeffery, Lonnie dan Kevin (2004, p525) Data
Definition
Language (DDL) adalah sebuah bahasa yang digunakan oleh DBMS untuk
menentukan
sebuah
database
atau
melihat/view database.
View tersebut
membatasi bagian dari sebuah database yang dapat digunakan atau diakses oleh
para pengguna dan program yang berbeda. DDL digunakan oleh
DBMS untuk
menetapkan secara fisik tipe, record, field, dan hubungan struktural.
Menurut Connolly (2005, p40) Data Definition Language (DDL) adalah
sebuah bahasa
yang
memungkinkan DBA atau user
untuk menggambarkan dan
menentukan nama dari entitas, atribut, dan hubungan yang diperlukan untuk
sebuah aplikasi, bersamaan dengan integritas yang terasosiasi dan batasan
keamanan yang ada.
Jadi, dapat disimpulkan bahwa Data Definition Language (DDL) adalah
sebuah bahasa yang memungkinkan user untuk melihat database, maupun
menggambarkan serta menentukan nama dari entitas, atribut, dan hubungan yang
diperlukan untuk sebuah aplikasi.
|
|
20
2.1.3.9 Data Manipulation Language (DML)
Menurut Jeffery, Lonnie dan Kevin (2004, p525) Data Manipulation
Language
(DML)
adalah
bahasa
DBMS yang
digunakan
untuk
membuat,
membaca,
memperbarui,
dan
menghapus
record-record
pada
sebuah
database
dan untuk menjelajahi di antara record-record dan tipe-tipe record yang berbeda
–
misal, dari record CUSTOMER ke record ORDER untuk seorang pelanggan.
Menurut Connolly (2005, p40) Data
Manipulation
Language
(DML)
adalah
sebuah
bahasa
yang
memberikan
fasilitas
pengoperasian
tehadap
data
yang ada di dalam basis data.
Jadi, dapat disimpulkan bahwa Data
Manipulation
Language
(DML)
adalah bahasa DBMS yang dapat digunakan untuk merubah
atau
mengoperasikan data.
DML biasanya meliputi :
1.
Memasukkan data yang baru ke dalam basis data.
2.
Memodifikasi data yang tersimpan di dalam basis data.
3.
Mengambil data yang terdapat di dalam basis data.
2.1.4
Tahapan dari Database Application Lifecycle
Database merupakan komponen mendasar suatu sistem informasi,
dimana
pengembangan/pemakaiannya
harus
dilihat
dari
perspektif
yang
lebih
luas berdasarkan kebutuhan organisasi. Berikut ini adalah tahapan dari database
application lifecycle menurut Connolly (2005, p283-306) :
|
 21
Gambar 2.3
Tahapan Database Application LifeCycle
1. Perencanaan database (Database Planning)
Merupakan aktivitas manajemen yang memungkinkan tahapan dari
database
application
lifecycle
direalisasikan
se-efektif dan
se-efisien
mungkin.
Perencanaan database
harus
terintegrasi
dengan
keseluruhan
strategi
sistem
informasi dari organisasi.
Terdapat 3 hal pokok
yang berkaitan dengan strategi
sistem informasi, yaitu :
|
|
22
a.
Identifikasi rencana dan sasaran (goals) dari enterprise termasuk
mengenai sistem informasi yang dibutuhkan.
b.
Evaluasi sistem
informasi yang ada untuk menetapkan kelebihan dan
kekurangan yang dimiliki.
c.
Penaksiran
kesempatan
IT
yang
mungkin
memberikan
keuntungan
kompetitif.
Metodologi untuk mengatasi hal tersebut diatas yaitu :
a.
Database Planning – Mission Statement :
Mission
statement untuk database project mendefinisikan tujuan utama
dari aplikasi database. Mengarahkan database project, biasanya
mendefinisikan
perintah
tugas
(mission statement). Mission
statement
membantu
menjelaskan
kegunaan dari database project
dan menyediakan alur yang lebih jelas untuk
mencapai
efektifitas
dan
efisiensi
penciptaan
dari
suatu
aplikasi database
yang
diinginkan.
b.
Database Planning – Mission Objectives :
Ketika
mission
statement
telah didefinisikan, maka
mission
objectives
didefinisikan. Setiap objective
(tujuan) harus mengidentifikasikan tugas khusus
yang harus didukung oleh
database. Dapat juga disertai
dengan beberapa
informasi tambahan yang menspesifikasikan pekerjaan yang harus diselesaikan,
sumber daya yang digunakan dan biaya untuk membayar kesemuanya itu.
|
|
23
Database planning juga harus menyertakan pengembangan standar-
standar yang menentukan :
a.
Bagaimana data akan dikumpulkan.
b.
Bagaimana menspesifikasikan format/bentuk data.
c.
Dokumentasi penting apakah yang akan diperlukan.
d.
Bagaimana desain dan implementasi harus dilakukan.
2. Definisi sistem (System Definition)
Menjelaskan
batasan-batasan
dan
cakupan
dari
aplikasi database
dan
sudut pandang user (user view) yang utama. User view mendefinisikan apa yang
diwajibkan dari suatu aplikasi
database
dari
perspektif
aturan
kerja
khusus
(seperti
Manager
atau Supervisor)
atau
area
aplikasi enterprise
(seperti
Marketing,
Personnel,
atau
Stock
Control).
Aplikasi
database
dapat
memiliki
satu atau
lebih user view. Identifikasi user view,
membantu memastikan bahwa
tidak ada user
utama
dari
suatu database
yang terlupakan ketika pembuatan
aplikasi baru yang dibutuhkan. User view juga membantu dalam pengembangan
aplikasi database yang rumit/kompleks memungkinkan permintaan-permintaan
dipecah kedalam bagian-bagian yang lebih simple.
3. Analisis dan pengumpulan persyaratan (Requirements Collection and
Analysis)
Suatu proses pengumpulan dan analisa
informasi
mengenai
bagian
organisasi
yang
didukung
oleh
aplikasi
database,
dan
menggunakan
informasi
|
|
24
tersebut untuk identifikasi kebutuhan user akan sistem baru. Informasi
dikumpulkan untuk setiap user view utama meliputi :
a.
Deskripsi data yang digunakan atau dihasilkan.
b.
Detail mengenai bagaimana data digunakan/dihasilkan.
c.
Beberapa kebutuhan tambahan untuk aplikasi database yang baru.
Informasi dianalisa untuk identifikasi kebutuhan agar disertakan dalam
aplikasi database yang baru. Aktifitas penting lainnya adalah menentukan
bagaimana mengatur aplikasi database dengan multiple user view, yaitu :
a.
Pendekatan terpusat (Centralized approach)
Kebutuhan
untuk
setiap
user view
digabungkan
menjadi
sekumpulan
kebutuhan. Sebuah global data model dibuat berdasarkan atas
penggabungan kebutuhan (dimana merepresentasikan seluruh user view).
b.
Pendekatan integrasi view (View integration approach)
Kebutuhan
untuk
setiap user
view digunakan
untuk
membangun
model
data terpisah untuk merepresentasikan user view tersebut. Hasil dari
model data tersebut nantinya digabungkan dalam tahapan desain
database.
Model data yang merepresentasikan user view tunggal disebut local data
model, dan
tersusun atas diagram-diagram dan dokumentasi yang secara
formal
menggambarkan
kebutuhan
dari
user view khusus terhadap
database.
Kemudian local data model digabungkan untuk menghasilkan global
data model, yang merepresentasikan seluruh user view untuk database.
|
|
25
c. Kombinasi keduanya (Combination of both approaches).
4. Database design
Merupakan suatu proses
pembuatan sebuah desain database yang akan
mendukung tujuan dan operasi suatu enterprise. Tujuan utamanya adalah :
a.
Merepresentasikan data dan relationship antar data yang dibutuhkan oleh
seluruh area aplikasi utama dan user group.
b.
Menyediakan model data yang mendukung segala transaksi yang
diperlukan pada data.
c.
Menspesifikasikan desain minimal
yang secara
tepat disusun
untuk
memenuhi
kebutuhan
performa
yang
ditetapkan
pada
sistem (misal
:
waktu
respon).
Pendekatan dalam desain database :
1. Top-down
Diawali dengan pembentukan model data yang berisi beberapa entitas
high-level dan relationship,
yang kemudian menggunakan pendekatan top-down
secara berturut-turut untuk mengidentifikasi entitas lower level, relationship dan
atribut lainnya.
2. Bottom-up
Dimulai dari
atribut dasar (yaitu, sifat-sifat entitas dan relationship),
dengan analisis
dari
penggabungan
antar
atribut,
yang
dikelompokan
kedalam
|
|
26
suatu relasi yang merepresentasikan tipe dari entitas dan relationship antar
entitas.
3.
Inside-out
Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda dengan
identifikasi awal entitas utama dan kemudian
menyebar ke entitas,
relationship,
dan atribut terkait lainnya yang lebih dulu diidentifikasi.
4.
Mixed
Menggunakan pendekatan bottom-up dan top-down untuk bagian yang
berbeda sebelum pada akhirnya digabungkan.
Data modeling, ada dua kegunaan utama dari data modeling yaitu :
1.
Untuk membantu dalam memahami arti (semantik) dari data.
2.
Untuk memfasilitasi komunikasi mengenai informasi yang dibutuhkan.
Pembuatan
model
data
menjawab
pertanyaan
mengenai
entitas,
relationship dan atribut. Model data memastikan kita memahami :
a.
Setiap user perspektif mengenai data.
b.
Sifat dari data itu sendiri, independen terhadap representasi fisiknya.
c.
Kegunaan data melalui user view.
Kriteria untuk menghasilkan model data yang optimal :
a.
Validitas Struktural (Structural Validity), harus konsisten dengan definisi
enterprise dan informasi organisasi.
|
|
27
b. Kesederhanaan (Simplicity),
mudah dimengerti baik oleh profesional
sistem informasi maupun pengguna non-teknik.
c. Kecepatan (Expressibility), kemampuan untuk
membedakan antara data
yang berlainan, relationship antar data dan batasan-batasan.
d.
Tidak rangkap (Nonredundancy), pengeluaran informasi yang tidak
berhubungan, dengan kata lain,
representasi setiap bagian
informasi
hanya satu
kali.
e.
Digunakan bersama (Shareability), tidak ditentukan untuk aplikasi atau
teknologi tertentu dan dapat digunakan oleh banyak pengguna.
f. Perluasan penggunaan (Extensibility), kemampuan untuk menyusun dan
mendukung
kebutuhan
baru
dengan
akibat
sampingan
yang
minimal
terhadap
user yang sudah ada.
g. Integritas (Integrity), konsistensi dengan cara yang digunakan enterprise
dan pengaturan informasi.
h. Representasi diagram (Diagrammatic Representation), kemampuan untuk
merepresentasikan model menggunakan notasi diagram yang mudah dimengerti.
Tiga fase database design :
1. Conceptual database design
Suatu
proses
pembentukan model
dari
informasi
yang
digunakan
dalam
enterprise,
independen dari keseluruhan aspek
fisik. Model data dibangun
dengan
menggunakan
informasi
dalam spesifikasi
kebutuhan
user. Model data
konseptual merupakan sumber informasi untuk fase desain logical.
|
|
28
2.
Logical database design
Suatu
proses
pembentukan model
dari
informasi
yang
digunakan
dalam
enterprise berdasarkan model data tertentu (misal : relasional), tetapi independen
terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang
telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logical.
3.
Physical database design
Suatu proses
yang
menghasilkan
deskripsi
implementasi database
pada
penyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode
akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat
dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS
tertentu.
4.
DBMS selection (optional)
Pemilihan DBMS yang tepat
untuk
mendukung aplikasi database. Dapat
dilalukan
kapanpun
sebelum menuju
desain logical
asalkan
terdapat
cukup
informasi
mengenai
kebutuhan
sistem.
Tahap-tahap
utama
untuk
memilih
DBMS :
a. Mendefinisikan terminologi studi referensi.
b. Mendaftar dua atau tiga produk.
c. Evaluasi produk.
d. Rekomendasi pilihan dan laporan produk.
|
|
29
5.
Desain aplikasi (Application design)
Desain interface user dan program aplikasi yang menggunakan dan
memproses database.
Desain database dan aplikasi
merupakan aktifitas paralel
yang meliputi dua aktifitas penting yaitu :
a.
Transaction design
Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan oleh user
tunggal atau program aplikasi,
yang
mengakses atau merubah
isi dari database.
Kegunaan dari desain transaksi adalah untuk menetapkan dan keterangan
karakteristik
high-level
dari suatu transaksi
yang
dibutuhkan
pada database,
diantaranya :
-
Data yang akan digunakan oleh transaksi.
-
Karakteristik fungsional dari suatu transaksi.
-
Output transaksi
-
Keuntungannya bagi user.
-
Tingkat kegunaan yang diharapkan.
Terdapat tiga tipe transaksi, yaitu :
-
Retrieval
transaction,
digunakan
untuk
pemanggilan
(retrieve)
data
untuk ditampilkan di layar atau menghasilkan suatu laporan.
-
Update transaction, digunakan untuk menambahkan record baru,
menghapus record lama, atau memodifikasi record yang sudah ada
didalam database.
-
Mixed transaction, meliputi pemanggilan dan perubahan data.
|
|
30
b.
User interface design
Beberapa aturan pokok dalam pembuatan user interface :
-
Meaningful title, diusahakan pemberian nama suatu form cukup
jelas
menerangkan kegunaan dari suatu form/report.
-
Comprehensible
instructions, penggunaan
terminologi
yang
familiar
untuk
menyampaikan
instruksi ke user
dan
jika
informasi
tambahan
dibutuhkan, maka harus disediakan helpscreen.
-
Logical grouping and sequencing of fields, field yang saling
berhubungan ditempatkan pada form/report yang sama. Urutan field
harus logis dan konsisten.
-
Visually
appealing
layout
of
the
form/report, tampilan
form/report
harus menarik, dan sesuai dengan hardcopy agar konsisten.
-
Familiar field labels, penggunaan label yang familiar.
-
Consistent
terminology and abbreviation,
terminologi
dan
singkatan
yang digunakan harus konsisten.
-
Consistent use of color, penggunaan warna dalam pembuatan aplikasi
harus
konsisten
(tidak
terlalu
banyak
warna
yang
membuat user
menjadi bingung)
-
Visible
space
and
boundaries
for
data-entry
fields,
jumlah
tempat
yang disediakan untuk data entry harus diketahui oleh user.
-
Convinient cursor movement, user dapat dengan
mudah
menjalankan
operasi
yang
diinginkan
dengan
menggerakkan cursor pada
form/report.
|
|
31
-
Error correction for individual characters and entire fields, user
dapat
dengan
mudah
menjalankan operasi yang diinginkan dan
melakukan perubahan terhadap nilai field.
-
Error messages for unacceptable values.
-
Optional fields marked clearly.
-
Explanatory messages for fields, ketika user meletakkan cursor pada
suatu
field,
maka
keterangan
mengenai
field tersebut harus dapat
dilihat.
-
Completion
signal,
indikator
yang
menjelaskan
bahwa
suatu
proses
telah selesai dilaksanakan.
6.
Prototyping (optional)
Membuat
model
kerja
suatu
aplikasi
database. Tujuan
utama
dari
pembuatan prototyping adalah :
a.
Untuk
mengidentifikasi
feature dari
sistem
yang berjalan dengan
baik
atau tidak.
b.
Untuk memberikan perbaikan-perbaikan atau penambahan feature baru.
c.
Untuk klarifikasi kebutuhan user.
d.
Untuk evaluasi feasibilitas (kemungkinan
yang akan terjadi) dari desain
sistem khusus.
|
|
32
Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu :
a.
Requirements
prototyping,
menggunakan
prototype untuk menentukan
kebutuhan dari aplikasi
database
yang diinginkan
dan
ketika kebutuhan
itu terpenuhi maka prototype akan dibuang.
b. Evolutionary
prototyping,
digunakan
untuk
tujuan
yang
sama.
Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan
lanjutan menjadi aplikasi database yang digunakan.
7. Implementation
Merupakan realisasi fisik dari database dan desain aplikasi. Implementasi
database dicapai dengan menggunakan :
a.
DDL untuk membuat skema database dan file database kosong.
b.
DDL untuk membuat user view yang diinginkan.
c. 3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi
database disertakan dengan
menggunakan DML, atau ditambahkan pada bahasa
pemrograman.
8. Data conversion and loading
Pemindahan data yang ada ke dalam database baru dan mengkonversikan
aplikasi
yang ada agar dapat digunakan pada database yang baru.
Tahapan ini
dibutuhkan ketika sistem database baru menggantikan sistem yang lama. DBMS
biasanya memiliki
utilitas
yang memanggil ulang file
yang sudah ada ke dalam
database baru.
Dapat juga mengkonversi dan menggunakan program aplikasi dari sistem
yang lama untuk digunakan oleh sistem yang baru.
|
|
33
9.
Testing
Suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan
kesalahan. Dengan menggunakan strategi tes yang direncanakan dan data yang
sesungguhnya.
Penguji
hanya
akan
terlihat
jika
terjadi
kesalahan software.
Mendemonstrasikan database dan program aplikasi terlihat berjalan seperti yang
diharapkan.
10. Operational maintenance
Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi :
a.
Pengawasan performa sistem, jika performa menurun maka
memerlukan
perbaikan atau pengaturan ulang database.
b.
Pemeliharaan dan pembaharuan aplikasi database (jika dibutuhkan).
c.
Penggabungan kebutuhan baru kedalam aplikasi database.
2.1.5
Normalisasi
Normalisasi
adalah sebuah
teknik
untuk
menghasilkan
sejumlah
relasi
dengan sifat-sifat (properties) yang diinginkan, memenuhi kebutuhan data pada
enterprise.
Tujuan
utama
dalam pengembangan
model
data
logikal
pada
sistem
database relasional adalah menciptakan representasi akurat suatu data,
relationship antar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka
harus ditetapkan sekumpulan relasi.
Enam bentuk normal yang biasa digunakan yaitu, first normal form (1NF),
second normal form (2NF), third normal form (3NF), dan Boyce-Codd normal
|
 34
form (BCNF), UNF, SNF. Konsep utamanya terkait dengan functional
dependencies,
dimana
menerangkan
hubungan
antar
atribut
yang ada.
Sebuah
relasi
dapat
dinormalisasikan
kedalam
bentuk
tertentu
untuk
mengatasi
kemungkinan
terjadinya
pengulangan
dari
update
yang
tidak
baik.
(Connolly,
2005, p388)
Hubungan
diantara
normal
forms
menurut
Connolly
(2005,
p401-422)
sebagai berikut :
Gambar 2.4
Diagram Ilustrasi dari Hubungan Diantara Normal Forms
1.
Unnormalized Form (UNF)
a.
Merupakan suatu tabel
yang berisikan satu atau
lebih groups yang
berulang.
b.
Membuat
tabel unnormalized
yaitu dengan
memindahkan data dari
sumber informasi kedalam format tabel dengan baris dan kolom.
|
|
35
2.
First Normal Form (1NF)
a. Merupakan sebuah relasi dimana setiap irisan antara baris dan kolom
berisikan satu dan hanya satu nilai.
b. UNF ke 1NF
-
Tunjuk
satu
atau sekumpulan atribut sebagai kunci
untuk tabel
unnormalized.
-
Identifikasikan groups yang berulang dalam tabel unnormalized yang
berulang untuk kunci atribut.
-
Hapus group yang berulang dengan cara :
>
Masukkan
data
yang semestinya kedalam
kolom
yang kosong
pada
baris yang berisikan data yang berulang (flattening the table), atau
dengan cara
>
Menggantikan
data
yang
ada
dengan copy
dari
kunci
atribut
yang
sesungguhnya kedalam relasi terpisah.
3. Second Normal Form (2NF)
a.
Berdasarkan pada konsep full functional dependency, yaitu A dan B
merupakan
atribut
dari
sebuah
relasi,
B
dikatakan
fully
dependent
terhadap
A
jika B functionally dependent pada A tetapi tidak pada proper subset dari A.
b. 2NF, merupakan sebuah
relasi dalam 1NF dan setiap atribut non-
primary-key bersifat fully functionally dependent pada primary key.
|
|
36
c. 1NF ke 2NF
-
Identifikasikan primary key untuk relasi 1NF.
-
Identifikasikan functional dependencies dalam relasi.
-
Jika terdapat partial dependencies terhadap primary key, maka hapus
dengan
menempatkannya
dalam relasi
yang
baru
bersama
dengan
salinan determinannya.
4. Third Normal Form (3NF)
a. Berdasarkan pada konsep transitive dependency, yaitu suatu kondisi
dimana A, B dan C merupakan atribut dari sebuah relasi, maka jika A -> B dan B
-> C, maka C transitively dependent pada A melalui B. (Jika A tidak functionally
dependent pada B atau C).
b. 3NF, adalah sebuah relasi dalam 1NF dan 2NF dan dimana tidak terdapat
atribut non-primary-key atribut yang bersifat transitively dependent pada primary
key.
c. 2NF ke 3NF
-
Identifikasikan primary key dalam relasi 2NF.
-
Identifikasikan functional dependencies dalam relasi.
-
Jika terdapat transitive dependencies
terhadap primary key, hapus
dengan
menempatkannya
dalam relasi
yang
baru
bersama
dengan
salinan determinannya.
|
|
37
5.
Boyce-Codd Normal Form (BCNF)
a.
Berdasarkan pada functional dependencies yang dimasukan kedalam
hitungan seluruh
candidate
key
dalam
suatu relasi,
bagaimanapun
BCNF
juga
memiliki batasan-batasan tambahan disamakan dengan definisi umum dari 3NF.
b.
Suatu relasi dikatakan BCNF, jika dan hanya jika setiap determinan
merupakan candidate key.
c. Perbedaan antara 3NF dan BCNF yaitu untuk functional dependency A ->
B, 3NF memungkinkan dependency ini dalam suatu relasi jika B adalah atribut
primary key dan A bukan merupakan candidate key.
d.
Sedangkan BCNF menetapkan dengan jelas bahwa untuk dependency ini
agar ditetapkan dalam relasi maka A harus merupakan candidate key.
e.
Setiap relasi dalam BCNF juga merupakan 3NF, tetapi relasi dalam 3NF
belum tentu termasuk kedalam BCNF.
2.1.6
Entity-Relationship Modeling
2.1.6.1 Entity Types
Konsep dasar dari
Model
ER adalah Entity
Types,
yaitu kumpulan dari
objek-objek
dengan
sifat
(property)
yang
sama,
yang
diidentifikasi
oleh
enterprise mempunyai eksistensi yang independen. Keberadaannya dapat berupa
fisik maupun abstrak.
Entity Occurrence, yaitu pengidentifikasian objek yang unik dari sebuah
operational
maintenance.
Setiap entitas
di
identifikasikan
dan
disertakan
property-nya.
|
 38
2.1.6.2 Relationship Types
Kumpulan
keterhubungan
yang
mempunyai
arti
(meaningful
associations) antara tipe entitas yang ada.
Relationship occurrence, yaitu keterhubungan
yang diidentifikasi
secara
unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.
Contoh : Gambar relationship type
Gambar 2.5
A Semantic Net Showing Individual Occurrences of the
Has Relationship Type
2.1.6.3 Derajat Relationship
Yaitu jumlah entitas yang berpatisipasi dalam suatu relationship. Derajat
relationship terdiri dari :
1.
Binary relationship, keterhubungan antar dua tipe entitas. Contoh binary
relationship antara PrivateOwner dengan PropertyForRent yang disebut POwns.
|
 39
Gambar 2.6
Binary Relationship Powns
2. Ternary relationship, keterhubungan antar
tiga tipe entitas. Contoh
Ternary
Relationship
yang dinamakan registers. Relasi ini
melibatkan
tiga tipe
entity
yaitu
Staff,
Branch
dan
Client.
Relationship
ini menggambarkan staff
mendaftarkan client pada branch.
Gambar 2.7 Ternary Relationship Registers
3. Quaternary relationship, keterhubungan antar empat tipe entitas. Contoh
quaternary relationship yang dinamakan Arranges. Relasi ini melibatkan 4 entity
yaitu Buyer, Solicitor, Financial Institution, dan Bid. Relasi ini menggambarkan
buyer, diberi masukan oleh Solicitor, dan didukung oleh Financial
Institution,
melakukan penawaran (bid).
|
 40
Gambar 2.8
Quaternary Relationship Arranges
4.
Unary
relationship,
keterhubungan
antar
satu
tipe
entitas,
dimana
tipe
entitas
tersebut
berpartisipasi
lebih dari
satu
kali
dengan peran
yang berbeda.
Kadang
disebut
juga
recursive
relationship. Relationship dapat
diberikan role
names
untuk
mengidentifikasikan
keterkaitan
tipe
entitas
dalam relationship.
Contoh
entitas Staff
yang
berperan
menjadi supervisor
dan
staff yang
di-
supervisor-i.
Gambar 2.9 Recursive Relationship Supervises with Role Names
Supervisor and Supervisee
|
|
41
2.1.6.4 Attributes
Merupakan sifat-sifat (property) dari sebuah entity atau relationship type.
Contohnya : sebuah entity Staff digambarkan oleh attribut staffNo, name, position
dan salary.
Attribute Domain adalah
himpunan
nilai
yang diperbolehkan
untuk satu
atau lebih atribut. Macam-macam atribut :
1. Simple
Attribute,
yaitu atribut
yang
terdiri
dari
satu
komponen
tunggal
dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang
lebih kecil lagi. Dikenal juga dengan nama Atomic Attribute.
2. Composite Attribute, yaitu atribut yang terdiri dari beberapa komponen,
dimana
masing-masing
komponen
memiliki
keberadaan yang
independen.
Misalkan atribut Address dapat terdiri dari Street, City, PostCode.
3. Single-valued Attribute, yaitu atribut yang mempunyai nilai tunggal untuk
setiap
kejadian.
Misalnya
entitas
Branch
memiliki
satu nilai
untuk
atribut
branchNo pada setiap kejadian.
4. Multi-valued Attribute, yaitu atribut yang mempunyai beberapa nilai
untuk setiap kejadian. Misal entitas Branch memiliki beberapa nilai untuk atribut
telpNo pada setiap kejadian.
5. Derived Attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari
satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
|
|
42
2.1.6.5 Keys
1. Super Key : Atribut unik yang mengidentifikasikan row.
2. Candidate Key
:
Atribut
unik
yang mengidentifikasikan table. Jumlah
minimal atribut-atribut yang dapat meng-identifikasikan setiap
kejadian/record
secara unik.
3.
Primary
Key
:
Atribut unik
yang
mengidentifikasikan
setiap
row
dalam
table.
Candidate
Key yang
dipilih untuk
mengidentifikasikan setiap
kejadian/record dari suatu entitas secara unik.
4. Alternate Key : Candidate Key yang tidak terpilih menjadi Primary Key.
5. Composite Key : Candidate Key yang terdiri dari dua atau lebih atribut.
6. Foreign
Key
:
Atribut
sebuah tabel
yang
menggabungkan
diri
ke tabel
lain.
2.1.6.6 Strong and Weak Entity Types
Strong Entity Type, yaitu entitas yang keberadaannya tidak
bergantung
pada
entitas
lain
sedangkan Weak Entity Type,
adalah
entitas
yang
keberadaannya bergantung pada entitas lain. Strong Entity Type terkadang
disebut
dengan
parent, owner
dominant
dan
Weak
Entity
Type
disebut
child,
dependent, subordinate.
|
 43
Gambar 2.10 A Strong Entity Type Client and A Weak Entity Type
Preference
2.1.6.7 Structural Constraints
Batasan utama pada relationship disebut multiplicity, yaitu jumlah (atau
range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke
satu kejadian dari entitas lain yang berhubungan melalui suatu relationship.
Relationship yang
paling
umum
adalah
binary
relationship.
Macam-
macam binary relationship :
1.
One-to-One (1:1)
2.
One-to-Many (1:*)
3.
Many-to-Many (*:*)
|
 44
Tabel 2.1
Tabel Summary of Multiplicity Constraints
2.1.7
Perancangan Basis Data Konseptual
Langkah 1 Membangun Model Data Konseptual Lokal
Tujuan dari langkah ini adalah untuk membangun sebuah model data
konseptual
lokal
dari
sebuah
perusahaan untuk
masing-masing
view yang
spesifik.
Langkah 1.1 Mengidentifikasikan tipe entitas
Tujuan dari langkah ini adalah untuk
mengidentifikasi tipe entitas
utama
yang diperlukan oleh view.
Langkah pertama dalam membangun sebuah model data konseptual lokal
adalah
menentukan
objek
utama
yang
mana user
tertarik terhadapnya. Objek-
objek ini adalah tipe entitas untuk model. Salah satu metode untuk
mengidentifikasikan
entitas
adalah dengan
menentukan
spesifikasi
kebutuhan
user. Dari spesifikasi ini, kita mengidentifikasikan kata benda atau frase benda
yang disebutkan.
|
|
45
Langkah 1.2 Mengidentifikasikan tipe relasi
Tujuannya adalah untuk mengidentifikasikan relasi penting
yang muncul
antara tipe entitas yang telah diidentifikasikan.
Ketika
mengidentifikasikan
entitas, salah
satu
metode
adalah
dengan
mencari
kata benda
yang
ada
di
dalam
spesifikasi
kebutuhan
user.
Kita
juga
dapat
menggunakan
tata
bahasa dari
spesifikasi
kebutuhan
untuk
mengidentifikasikan relasi. Biasanya,
relasi
diindikasikan
oleh
kata
kerja
atau
ekspresi verbal.
Menurut
Connolly
(Connolly, 2005, p445-446),
langkah-langkah
dalam
mengidentifikasikan tipe relasi adalah sebagai berikut :
1.
Menggunakan Entity-Relationship Diagrams (ERD).
2.
Menentukan batasan multiplicity dari sebuah tipe relasi.
3.
Memeriksa fan dan chasm traps.
4.
Mendokumentasikan tipe relasi.
Langkah 1.3 Mengidentifikasikan dana mengasosiasikan atribut dengan
entitas atau tipe relasi
Tujuannya adalah untuk mengasosiasikan atribut dengan entitas atau tipe
relasi yang sesuai.
Langkah 1.4 Menentukan domain atribut
Tujuannya adalah
untuk
menentukan domain
dari atribut dalam model
data konseptual lokal.
|
|
46
Domain adalah sekumpulan nilai-nilai di
mana satu atau lebih atribut
menggambarkan nilai darinya. Model data yang sudah dikembangkan
sepenuhnya menspesifikasikan domain untuk setiap atribut dan menyertakan :
1.
Sekumpulan nilai yang diperbolehkan untuk atribut.
2.
Ukuran dan format dari atribut.
Langkah 1.5 menentukan atribut candidate dan primary key
Tujuannya
untuk
mengidentifikasikan
candidate
key untuk
setiap
tipe
entitas dan, jika terdapat lebih dari satu candidate key, memilih salah satu
sebagai
primary key. Candidate key adalah
sekumpulan
atribut
minimal
dari
sebuah entitas yang secara unik mengidentifikasikan
masing-masing
kejadian
(occurence) dari entitas tersebut. Kita dapat mengidentifikasikan
lebih dari satu
candidate key, di mana kita memilih salah satu sebagai primary key dan sisanya
dinamakan alternate key.
Ketika
memilih
sebuah primary key di antara candidate key, perhatikan
petunjuk berikut untuk membantu pemilihan.
1.
Candidate key dengan sekumpulan atribut yang minimal.
2.
Candidate key yang nilainya paling jarang berubah.
3.
Candidate key dengan karakter yang paling sedikit.
4.
Candidate key dengan nilai maksimun yang paling kecil.
5.
Candidate key yang paling mudah digunakan dari sudut pandang user.
|
|
47
Langkah
1.6
Mempertimbangkan
penggunaan
konsep pemodelan
tingkat
tinggi (langkah optional)
Tujuannya untuk mempertimbangkan penggunaan konsep pemodelan
tingkat tinggi, seperti spesialisasi, generalisasi, aggregasi, dan komposisi.
Jika kita
menggunakan pendekatan spesialisasi (specialization), kita
berusaha
untuk
memperlihatkan
perbedaan
antara
entitas
dengan
menentukan
satu atau
lebih subclass dari
sebuah
entitas superclass.
Jika
kita
menggunakan
pendekatan generalisasi (generalization),
kita
berusaha
untuk
mengidentifikasikan
fitur-fitur
umum antara
entitas
untuk
menentukan
sebuah
entitas superclass yang umum.
Kita dapat menggunakan aggregasi
untuk
merepresentasikan sebuah
relasi
’memiliki’ atau ’bagian dari’ antara tipe entitas,
di mana yang satu
merepresentasikan ’seluruh’ dan yang lainnya sebagai ’bagian’. Kita dapat
mengguanakan komposisi (tipe khusus dari aggregasi)
untuk
merepresentasikan
sebuah asosiasi antara tipe entitas di mana terdapat kepemilikan yang kuat
(strong ownership) dan coincidental lifetime antara ’seluruh’ dan ’bagian’.
Langkah 1.7 Memeriksa model terhadap adanya pengulangan (redudancy)
Tujuannya adalah untuk memeriksa adanya pengulangan di dalam model.
Pada langkah ini, kita menguji model data konseptual lokal dengan tujuan
spesifik
yaitu
untuk
mengidentifikasikan
apakah
terdapat
sebuah
pengulangan
dan menghilangkan pengulangan yang ada.
|
|
48
Dua aktivitas dalam langkah ini adalah ”
1.
Menguji ulang relasi one-to-one (1:1).
2.
Menghapus relasi yang redundant.
Langkah 1.8 Memvalidasi model konseptual lokal terhadap transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa model
konseptual lokal mendukung transaksi yang diperlukan oleh view.
Kita menguji dua kemungkinan pendekatan untuk memastikan bahwa
model data konseptual lokal mendukung transaksi yang diperlukan :
1.
Menguraikan transaksi.
2.
Menggunakan jalan kecil (pathway) transaksi.
Langkah 1.9 Melakukan review model data konseptual lokal dengan user
Tujuannya adalah untuk memeriksa (review) model data konseptual lokal
dengan user
untuk
memastikan
bahwa
model
merupakan
representasi
yang ’benar’ dari view.
Hasil akhir dari perancangan konseptual basis data adalah memproses
pembuatan
suatu
model
dari
informasi
yang
akan
digunakan
di
dalam suatu
perusahaan organisasi yang tidak tergantung dengan apapun (independent)
|
|
49
2.1.8
Perancangan Basis Data Logikal
Langkah 2 Membangun dan memvalidasi model data logikal lokal
Tujuan dari langkah ini adalah untuk membangun sebuah model data logikal
lokal dari model data konseptual lokal yang merepresentasikan sebuah view
utama dari perusahaan dana kemudian memvalidasi model ini untuk memastikan
bahwa model ini secara struktur adalah benar (menggunakan teknik normalisasi)
dan untuk memastikan model mendukung transaksi yang dibutuhkan.
Langkah
2.1
menghapus
fitur-fitur
yang
tidak
compatible
dengan
model
relasional (optional)
Tujuannya untuk memperbaiki model data konseptual lokal untuk
menghapus fitur-fitur yang tidak kompatibel dengan model relasional.
Tujuan dari langkah ini adalah untuk :
1.
Menghilangkan tipe biner many-to-many (*:*).
2.
Menghilangkan tipe relasi rekursif many-to-many (*:*).
3.
Menghilangkan tipe relasi kompleks.
4.
Menghilangkan atribut multi-valued.
Langkah 2.2 Memperoleh relasi untuk model data logikal lokal
Tujuannya adalah untuk membuat relasi untuk model data logikal lokal yang
merepresentasikan entitas, relasi, dan atribut yang sudah diidentifikasikan. Cara
untuk
memperoleh
relasi
dari
kemungkinan
struktur
yang
ada
di
dalam
data
model yaitu :
|
|
50
1.
Tipe strong entity.
2.
Tipe weak entity.
3.
Tipe relasi biner one-to-many (1:*).
4.
Tipe relasi biner one-to-one (1:1).
5.
Relasi rekursif one-to-one (1:1).
6.
Tipe relasi superclass/subclass.
7.
Tipe relasi biner many-to-many (*:*).
8.
Tipe relasi kompleks.
9.
Atribut multi-valued.
Langkah 2.3 Validasi relasi dengan menggunakan normalisasi
Tujuannya
untuk memvalidasi relasi pada
model data
logikal
lokal dengan
menggunakan teknik dari normalisasi.
Langkah 2.4 Validasi relasi terhadap transaksi user
Tujuannya
untuk
memastikan
bahwa
relasi
pada
model
data
logikal
lokal
mendukung transaksi yang diperlukan oleh view.
Langkah 2.5 Menentukan batasan integritas
Tujuannya adalah untuk mendefinisikan batasan integritas yang diberikan di
dalam view.
|
|
51
Lima tipe dari batasan integritas menurut Connolly (Connolly, 2005, p81), yaitu :
1.
Data yang diminta.
2.
Batasan domain atribut.
3.
Integritas entitas.
4.
Integritas referensial.
5.
Batasan perusahaan.
Langkah 2.6 review model data logikal dengan user
Tujuannya adalah untuk
memastikan bahwa model data logikal lokal dan
dokumentasi pendukung yang menggambarkan
model merupakan representasi
yang benar dari view.
Langkah 2.7 Relasi antara model data logikal dan data flow diagrams
Sebuah model data logikal merefleksikan struktur dari data tersimpan pada
sebuah perusahaan. Sebuah Data Flow Diagram (DFD) menunjukkan data yang
bergerak
di
dalam sebuah
perusahaan
dana
disimpan
di
dalam media
penyimpanan data
(data stores). Semua atribut
harus
muncul dalam sebuah tipe
entitas jika disimpan di dalam perusahaan, dan mungkin akan terlihat mengalir di
sepanjang perusahaan sebagai aliran data (data flow).
|
|
52
Langkah 3 Membangun dan memvalidasi model data logikal global
Tujuan
dari
langkah
ini
adalah
untuk
menggabungkan
model
data
logikal
lokal individual menjadi sebuah model
data
logikal
global
tunggal
yang
merepresentasikan perusahaan.
Langkah 3.1 Menggabungkan model data logikal lokal ke dalam model
global
Tujuannya adalah untuk menggabungkan model data logikal lokal individual
ke dalam sebuah model data logikal global tunggal dari perusahaan.
Beberapa tugas dari pendekatan ini adalah sebagai berikut :
1.
Review nama dan isi dari entitas/relasi dan candidate key.
2.
review nama dan ini dari relasi/foreign key.
3.
Gabungkan entitas/relasi dari model data lokal.
4.
Masukkan (tanpa menggabungkan) entitas/relasi yang unik ke dalam
masing-masing model data lokal.
5.
Gabungkan relasi/foreign key dari model data lokal.
6.
Masukkan (tanpa menggabungkan) relasi/foreign key yang unik ke dalam
masing-masing model data lokal.
7.
Periksa entitas/relasi dan relasi/foreign key yang hilang.
8.
Periksa batasan integritas.
9.
Gambarkan diagram relasi/ERD global.
10.
Update dokumentasi.
|
|
53
Langkah 3.2 Validasi model data logikal global
Tujuannya untuk memvalidasi relasi yang dibuat dari model data logikal
global menggunakan teknik normalisasi dan untuk memastikan relasi
mendukung transaksi yang diperlukan.
Langkah 3.3 Memeriksa untuk pertumbuhan ke depan
Tujuannya
untuk
menentukan
apakah
ada
perubahan
yang significant
di
kemudian hari yang dapat diramalkan dan untuk menduga apakah model data
logikal global dapat menyesuaikan perubahan ini.
Langkah 3.4 Review model data logikal global dengan user
Tujuannya untuk memastikan bahwa model data logikal global merupakan
representasi yang benar dari perusahaan.
Hasil akhir dari perancangan logikal basis data adalah merancang suatu
model informasi berdasarkan spesifikasi model yang ada (seperti model
relasional), tetapi tidak bergantung terhadap
suatu DBMS dan
perangkat
keras
lainnya.
Basis
data
logikal
merancang suatu
peta
untuk
setiap
model
data
konseptual lokal. Jika terdapat lebih dari satu pandangan user, maka model data
logikal lokal akan dikombinasikan menjadi suatu model data logikal global yang
merepresentasikan semua pandangan user dari suatu perusahaan.
|
|
54
2.1.9
Perancangan Basis Data Fisikal
Langkah 4 Menterjemahkan
model data logikal global untuk sasaran
DBMS
Tujuan dari langkah ini adalah untuk menghasilkan skema
basis data
relasional
untuk
model
data
logikal
global yang dapat diimplementasikan pada
sasaran DBMS.
Langkah 4.1 Merancang relasi dasar (base relations)
Tujuannya
adalah
untuk
memutuskan bagaimana
merepresentasikan
relasi
dasar yang diidentifikasikan dalam model data logika global pada sasaran DBMS.
Untuk setiap relasi
yang diidentifikasikan dalam
model data
logika
global,
kita memiliki definisi yang terdiri dari :
1.
Nama relasi
2.
Daftar dari simple attribute dalam tanda kurung
3.
Primary key dan, jika perlu, alternate key (AK) dan foreign key (FK)
4.
Daftar dari setiap atribut yang diperoleh dan bagaimana dikomputasikan
5.
Batasan integritas referensial untuk foreign key yang diidentifikasikan
Dari kamus data, untuk setiap atribut juga didapatkan :
1.
Domain, terdiri dari tipe data, panjang, dan setiap batasan dari domain
2.
Pilihan nilai default untuk atribut
3.
Apakah atribut boleh berupa null
|
|
55
Langkah 4.2 Merancang representasi dari data yang diperoleh (derived
data)
Tujuannya adalah
untuk
memutuskan bagaimana
merepresentasikan derived
data yang ada dalam model data logikal global pada sasaran DBMS.
Atribut
yang
nilainya
dapat
ditemukan dengan
menguji
nilai dari
atribut
yang lain dikenal sebagai derived atau calculated attributes.
Langkah 4.3 Merancang batasan perusahaan
Tujuannya untuk merancang batasan perusahaan untuk target DBMS.
Langkah 5 Merancang representasi fisik
Tujuan dari langkah ini adalah untuk menentukan organisasi file yang
optimal untuk menyimpan relasi dasar (base relation) dan index yang diperlukan
untuk mendapatkan kinerja yang dapat diterima, yaitu bagaimana relasi dan
tuples akan disimpan dalam penyimpanan sekunder (secondary strorage).
Langkah 5.1 Menganalisa transaksi
Tujuannya adalah untuk memahami kegunaan dari transaksi yang akan
dijalankan pada basis data dan untuk menganalisa transaksi yang penting.
Dalam
menganalisa
transaksi,
kita berusaha
untuk
mengidentifikasikan
kriteria kinerja, seperti :
1.
Transaksi
yang sering dilakukan dan akan
memiliki pengaruh yang
signifikan pada kinerja.
|
|
56
2.
Transaksi yang kritikal terhadap operasi bisnis
3.
Waktu selama satu hari/minggu dimana akan ada permintaan yang tinggi
terhadap basis data (dinamakan peak load).
Langkah 5.2 Memilih organisasi file
Tujuannya untuk menentukan sebuah organisasi file yang efisien untuk setiap
relasi dasar (base relations).
Untuk
membantu memahami organisasi file pada setiap relasi, terdapat
petunjuk untuk memilih sebuah organisasi file berdasarkan tipe file berikut :
1.
Heap
2.
Hash
3.
Indexed Sequential Access Method (ISAM)
4.
B-tree
5.
Clusters
Langkah 5.3 Memilih index
Tujuannya
untuk
menentukan
apakah
menambahkan
index
akan
meningkatkan kinerja dari sistem.
Pada kasus ini, pilih atribut untuk mengurutkan atau mengelompokkan tuple
sebagai :
1.
Atribut yang paling sering digunakan pada operasi join, karena atribut ini
membuat operasi join lebih efisien, atau
|
|
57
2.
Atribut yang paling sering digunakan untuk mengakses tuple dalam
sebuah relasi untuk atribut tersebut.
Langkah 5.4 Menghitung kebutuhan disk space
Tujuannya untuk memperkirakan jumlah dari disk space yang akan
diperlukan oleh basis data. Merupakan sebuah kebutuhan bahwa implementasi
basis data dapat ditangani oleh konfigurasi perangkat keras yang sedang
digunakan. Tujuan dari tahapan ini adalah untuk memperkirakan jumlah dari disk
space yang diperlukan untuk mendukung implementasi basis data pada
penyimpanan sekunder.
Langkah 6 Merancang user view
Tujuan dari langkah ini adalah untuk merancang pandangan user
yang
diidentifikasikan selama pengumpulan kebutuhan dan menganalisa tahapan dari
siklus hidup aplikasi basis data relasional.
Langkah 7 Merancang mekanisme keamanan
Tujuan dari langkah ini adalah untuk merancang mekanisme keamanan bagi
basis data sebagaimana yang dispesifikasikan oleh user.
Mekanisme keamanan basis data adalah suatu mekanisme yang memproteksi
basis
data
dari
suatu
kejadian
yang
disengaja
maupun
yang
tidak disengaja
(Connolly, 2005, p542).
|
|
58
Suatu basis data merupakan sumber dari perusahaan yang penting yang perlu
dilindungi dengan suatu kontrol
yang
memadai. Beberap issue keamanan basis
data yang perlu diperhatikan antara lain :
1.
Pencurian data (Theft and Fraund)
2.
Kehilangan kerahasiaan suatu data (Loss of Confidentiality)
3.
Kehilangan hak pribadi (Loss of Privacy)
4.
Kehilangan integritas (Loss of Integrity)
5.
Kehilangan ketersediaan data (Loss of Availability)
Hasil akhir dari perancangan basis data fisikal adalah suatu proses
yang
mendeskripsikan suatu implementasi basis data pada media penyimpanan. Ini
menggambarkan suatu relasional dan struktur penyimpanan serta metodologi
pengaksesan
data oleh
user
yang efisien,
selama
memenuhi batasan
integritas
dan mekanisme keamanan.
2.1.10 Pengantar Pemodelan Proses
Membahas tentang cara menggambar diagram aliran data sebuah
model
proses yang berguna untuk mendokumentasikan proses
sistem dan aliran data.
Pemodelan data sabagai alat analisis sistem.
Model sistem memainkan peranan penting dalam pengembangan sistem.
Banyak
masalah
–
masalah
yang
tidak terstruktur, salah satu cara
untuk
menyusun persoalan tersebut adalah dengan
menggambar
model. Model adalah
representasi kenyataan atau gambar yang melukiskan banyak kata. Model sistem
adalah representasi
bergambar
mengenai kenyataan. Model
berguna
untuk
|
|
59
memahami sistem dengan lebih baik, mendokumentasikan persyaratan bisnis
atau desain
teknis.
Terdapat
dua
macam model,
yaitu
model
fisik
dan
model
logika.
2.1.10.1
Model Fisik
Model
fisik
tidak
hanya
menunjukkan
apa
sebenarnya
sistem
tersebut
atau
apa
yang
dilakukannya,
tetapi
juga
bagaimana
sistem tersebut
diimplementasikan
secara
fisik
dan
teknis.
Model
tersebut implementation-
dependent karena merefleksikan pilihan teknologi dan batasan pilihan teknologi.
2.1.10.2
Model Logika
Model logika menunjukkan apa sebenarnya sistem tersebut dan apa yang
dilakukan.
Model
tersebut implementation-independent,
yaitu
memberi
gambaran
tentang
sistem
terlepas
dari implementasi
teknis.
Dengan
demikian
model logika menggambarkan implementasi teknis.
Model
sistem
logika berguna
untuk menggambarkan
persyaratan
bisnis
dan
model
sistem
fisik
untuk
menggambarkan desain teknisnya. Kegiatan
analisis sistem cenderung fokus pada model sistem logika karena :
a. Model logika meningkatkan kreativitas.
b. Model logika memisahkan antara apa yang seharusnya dikerjakan sistem
dari bagaimana sistem akan mengerjakannya, kita
menjadi
menganalisa dengan
baik dalam hal kelengkapan, keakuratan dan konsistensi.
|
|
60
c.
Model logika memungkinkan kita untuk berkomunikasi dengan pengguna
akhir dalam bahasa teknis maupun non-teknis.
2.1.10.3
Pemodelan Proses
Pemodelan proses adalah teknis mengelolah dan mendokumentasi
struktur dan aliran data
melalui proses sistem dan/atau
logika, kebijakan,
prosedur yang akan diimplementasikan oleh proses sistem.
Model proses logika digunakan untuk mendokumentasikan fokus proses
sistem informasi dari sudut pandang pengguna dan pemilik sistem. Model proses
terdapat tipe khusus yang disebut diagram konteks, yang menggambarkan fokus
komunikasi dari sudut pandang pemilik dan pengguna sistem, atau model proses
yang menggambarkan secara aktual antar muka sistem ke bisnis, dunia luar, dan
termasuk
sistem informasi
lain.
Berbagai
tipe
model
proses
misalnya
bagan
struktur program, flowchart logical, model proses analisis sistem, diagram aliran
data (data flow diagram).
2.1.10.4
Data Flow Diagram (DFD)
Data
flow
diagram
atau
diagram aliran
data
adalah
alat
yang
menggambarkan
aliran
data
melalui
sistem dan
kerja
atau
pengolahan
yang
dilakukan
oleh
sistem tersebut.
Sinonimnya
disebut
bagan
buble,
grafik
transformasi, dan model proses.
|
 61
Beda DFD dengan Flowchart, antara lain :
a. Proses dalam DFD dapat beroperasi secara paralel. Artinya beberapa
proses
dapat
dilaksanakan
atau dikerjakan
secara serempak.
Sebaliknya,
proses
pada flowchart hanya satu proses dalam satu waktu.
b. DFD
menunjukkan data flow melalui sistem. Sebaliknya, flowchart
menunjukkan rangkaian proses dalam algoritma atau program.
c. DFD
tunggal
dapat
menyertakan
proses
setiap
jam,
secara
harian,
mingguan, tahunan, dan sesuai permintaan. Hal ini tidak terjadi pada flowchart.
2.1.10.4.1
Simbol DFD
DFD (menurut Whitten, Bentley, Dittman) terdapat tiga simbol dan satu
koneksi :
a. Persegi empat
tumpul,
lingkaran atau
lonjong
menyatakan
proses
atau
bagaimana tugas dikerjakan. (PROSES)
Proses
Proses
Proses
b.
Persegi
empat
menyatakan
agen
eksternal
batasan
sistem
tersebut.
(INTERFACE)
Eksternal
|
 62
c.
Kotak dengan ujung terbuka menyatakan data store atau disebut file atau
database. (DATA)
Data Strore
d.
Panah menyatakan aliran data atau input dan output ke dan dari proses
tersebut.
Data Flow
2.1.10.4.2 Aliran Data Ilegal dan Legal
Gambar 2.11
Aliran Data ILEGAL dan Aliran TERKOREKSI
|
 63
2.1.10.5
DFD Konteks
Pertama perlu mendokumentasikan lingkup proyek awal. Semua proyek
memiliki
lingkup.
Lingkup
proyek
mendefinisikan
aspek
bisnis
yang
harus
didukung
oleh
sistem atau
aplikasi dan bagaimana
sistem yang
dimodelkan
berinteraksi dengan
sistem lain
dan
bisnis
secara
keseluruhan.
Context
data flow
diagram
adalah
model
proses untuk mendokumentasikan lingkup sistem. Disebut juga model lingkungan. DFD
konteks berisi satu dan hanya satu proses.
2.1.10.6
State Transition Diagram (STD)
State Transition Diagram (STD) adalah alat yang digunakan untuk menggambarkan
urutan dan variasi screen yang dapat terjadi selama satu sesi pengguna. STD digunakan
untuk menjelaskan siklus objek dari sistem yang ditunjukkan dengan komponen –
komponen sebagai berikut :
1.
State
Gambar diatas merepresentasikan keadaan-keadaan tertentu dari objek dalam sistem.
Contohnya keadaan “Start” menunjukkan awal dari sistem
2. Aksi
Reaksi
Komponen tersebut
menunjukkan arah aliran data dari sistem dimana
terdapat aksi
yaitu apa yang dilakukan oleh pengguna (input) dan reaksi yang ditunjukkan oleh
sistem (output).
|
 64
2.1.11 Pengertian Flowchart Diagram
Menurut Hollander (2000, p399).
Flowchart
digunakan
untuk
menggambarkan seluruh sistem informasi atau beberapa bagiannya. Keseluruhan
sistem
informasi
meliputi
dalam proses
input secara
manual atau proses
komputer dan beberapa hasil ouput nya. Hasil output diberikan kepada pengguna
untuk
membantu
dalam pengambilan keputusan
atau
disimpan
dan
sesudah
itu
digunakan sebagai masukkan ke dalam proses lainnya.
Flowchart
Diagram digunakan
untuk
menggambarkan
bagan
aliran
dokumen suatu sistem. Berikut ini adalah simbol – simbol yang biasa digunakan
dalam menggambarkan flowchart diagram
Simbol
Keterangan
Dokumen. Simbol ini digunakan untuk menggambarkan
semua jenis dokumen. Yang merupakan formulir yang
digunakan untuk mencatat data ketika terjadinya suatu
transaksi
Input/ Output. Simbol ini digunakan untuk menampilkan
data atau pun master file.
|
 65
On page connector. Memungkinkan aliran proses dalam
dokumen
di
hubungkan
dalam sebuah
halaman
flowchart, panah yang mengarah pada connector
menandakan arah dari connector lain dalam halaman
yang sama dimana aliran proses dan dokumen berjalan.
Panah yang keluar dari connector menandakan connector
dimulai kembali dari proses sebelumnya dari sistem.
Off
page
connector.
Jarang
dokumen
flow
chart muat
dalam satu
halaman
karena
itu
off
page
connector
digunakan untuk menghubungkan beberapa halaman dari
sebuah dokumen flowchart.
Kegiatan
manual.
Simbol
ini
digunakan
untuk
menggambarkan kegiatan manual seperti menerima
order dari pemesanan, mengisi formulir, dan sebagainya.
Atau operasional yang disertai dengan dokumen.
Disk tempat penyimpanan file (database).
Keputusan. Simbol ini digunakan untuk menampilkan
pemilihan keputusan yang harus dibuat.
|
 66
C
Sebuah tempat penyimpanan manual sistem secara
offline,
menggambarkan tempat
penyimpanan
apapun
dari dokumen kertas seperti laci, rak. Simbol ini
merupakan file yang disimpanan secara permanent
(bukan sementara). Metode untuk mengurutkan dokumen
digambarkan
dengan
simbol
A
(Alphanumeric), N
(Numeric), C (Chronological).
Garis alur
(flow line).
Simbol
ini digunakan
untuk
menghubungkan simbol-simbol dalam dokumen
flowchart. Garis ini menandakan alur fisikal dari
dokumen ataupun objek nyata.
Input
dalam
peralatan
komputer. Simbol
ini digunakan
untuk menggambarkan pemasukkan data ke dalam
komputer
melalui sebuah komputer terminal ataupun key
board
Mulainya
/
berakhir
sistem
dan
prosesnya.
Simbol
ini
untuk
mengidentifikasikan
titik
awal
dan
akhir
dari
proses
yang
digambarkan
dalam flowchart,
dapat
juga
digunakan untuk menampilkan entry atau pemasukan
data dalam sistem atau akhir dari data.
Tabel 2.2 Tabel Simbol Dalam Penggambaran Flowchart
|
|
67
2.2
Teori Khusus
2.2.1
Pengertian Penjualan
Menurut Mulyadi (1997, p204) bahwa kegiatan penjualan terdiri dari
transaksi barang atau jasa baik secara kredit maupun secara tunai. . Penjualan
merupakan aktivitas
yang penting dalam suatu perusahaan, karena dengan
adanya penjualan dapat menghasilkan pendapatan bagi perusahaan.
Menurut Hollander (2000, p.230), Proses penjualan adalah rangkaian dari
event operasi
yang secara
bersama-sama untuk
menarik pelanggan,
membantu
pelanggan
memilih barang dan
jasa
layanan,
mengantar barang
dan jasa
yang
diminta, dan mengumpulkan pembayaran untuk barang dan jasa.
Secara umum, penjualan merupakan suatu kegiatan yang dilakukan oleh
perusahaan untuk mempengaruhi orang agar mau membeli sesuatu barang atau
jasa yang ditawarkan oleh perusahaan dan pejualan
itu sendiri
menitik beratkan
pada kebutuhan pembeli.
2.2.2
Pengertian Sistem Informasi Penjualan
Menurut
Sidharta
(1996,
p.46),
Sistem informasi
penjualan
merupakan
struktur interaksi antar manusia, peralatan
metode-metode
dan
kontrol-kontrol
yang disusun untuk mencapai tujuan-tujuan tertentu. Sistem informasi penjualan
mendukung pembuatan keputusan untuk personel yang mengatur fungsi
penjualan.
|
|
68
Metode penjualan terdiri dari dua macam, yaitu :
a. Penjualan Tunai
Penjualan tunai dilaksanakan oleh perusahaan dengan cara mewajibkan
pembeli
melakukan
pembayaran
barang
terlebih
dahulu
sebelum
barang diserahkan oleh perusahaan ke pembeli.
b. Penjualan Kredit
Penjualan
kredit
dilaksanakan
oleh
perusahaan
dengan
mengirim barang
sesuai dengan order yang diterima pembeli dan untuk jangka waktu
tertentu
perusahaan
mempunyai
tagihan
kredit
yang pertama
kepada
seorang
pembeli selalu
didahului
dengan analisis
terhadap ada
atau
tidaknya pembeli tersebut diberi kredit.
2.2.3
Pengertian Pembelian
Menurut Mulyadi (1997, p.301 -
p.302), Sistem akuntansi pembelian
digunakan
dalam perusahaan
untuk
pengadaan
barang
yang
diperlukan
oleh
perusahaan.
Transaksi pembelian dapat digolongkan menjadi dua yaitu :
a. Pembelian local yaitu pembelian dari pemasok dalam negeri
b. Pemberian impor, pembelian dari pemasok luar negeri.
|
|
69
Fungsi yang terkait dengan sistem akuntansi pembelian adalah :
1.
Fungsi gudang, bertanggung jawab untuk mengajukan permintaan
pembelian sesuai dengan posisi persediaan yang ada di gudang dan
menyimpan barang yang telah diterima oleh fungsi penerimaan.
2. Fungsi pembelian, bertanggung jawab untuk memperoleh informasi
mengenai harga barang menentukan pemasok yang dipilih dalam
pengadaan barang dan mengeluarkan order pembelian kepada pemasok
yang dipilih.
3.
Fungsi penerimaan, bertanggung jawab untuk melakukan pemeriksaan
terhadap
jenis,
mutu,
dan
kuantitas
barang
yang
diterima
dari
pemasok
guna
menentukan
dapat
atau
tidaknya barang
tersebut
diterima
oleh
perusahaan.
4. Fungsi akuntansi. Fungsi akuntansi yang terkait dalam transaksi pembelian
adalah fungsi pencatat utang dan fungsi pencatat persediaan.
2.2.4
Pengertian Persediaan
Menurut
Mulyadi
(1997,
p.555),
Sistem persediaan
bertujuan
untuk
mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Dalam
perusahaan dagang persediaan terdiri dari satu golongan yaitu persediaan barang
dagangan yang merupakan barang yang dibeli untuk tujuan dijual kembali.
Menurut Thomas R.Dyckman (1998, p.376), Persediaan terdiri dari
barang-barang
yang
dimiliki
suatu bisnis dan di
impan baik
untuk digunakan
membuat produk atau sebagai produk yang siap dijual.
|
|
70
Persediaan dapat diklasifikasikan sebagai berikut,
1. Persediaan barang dagang (merchandise inventory) merupakan barang yang
ada
di
gudang
dibeli oleh
pengecer atau perusahaan
perdagangan
seperti
importir atau exportir untuk dijual kembali.
2. Persediaan manufaktur (manufacturing inventory). Persediaan gabungan
dari entitas manufaktur , yang terdiri.
a.
Persediaan bahan baku. Barang berwujud yang dibeli atau diperoleh
dengan cara lain. (misalnya, dengan
menambah dan disimpan untuk
pengunaan langsung dalam membuat barang untuk dijual kembali.)
b.
Persediaan barang dalam proses.
Barang-barang
yang
membutuhkan
pemrosesan lebih lanjut sebelum penyelesaiaan dan penjualan barang.
c.
Persediaan
barang
jadi,
barang-barang manufaktur yang telah
diselesaikan dan disimpan untuk dijual.
d.
Persedian perlengkapan manufaktur. (contoh, barang minyak pelumas
untuk bensin, bahan pembersih, dan barang lain yang merupakan
bagian kurang penting dari produk jadi)
3. Persediaan rupa - rupa, biasanya digunakan segera dan dicatat sebagai
beban
penjualan
/
umum ketika
dibeli.
(contoh,
perlengkapan
kantor,
kebersihan dan pengiriman).
|