2006201170IFBAB2

BAB 2

LANDASAN TEORI

Basis Data

(Database) sekarang merupakan bagian dari kehidupan kita sehari-

hari yang biasanya tidak kita sadari penggunaannya. Basis data merupakan koleksi dari

data

yang

berhubungan

dan

Sistem Manajemen

Basis

Data

(Database

Management

System/DBMS) merupakan perangkat lunak (software) yang mengatur dan mengontrol

akses ke basis data. Aplikasi basis data merupakan program yang berinteraksi dengan

basis data pada beberapa point dalam eksekusinya. Kita juga menggunakan istilah sistem

basis data untuk

memasukkan koleksi program aplikasi

yang berinteraksi dengan basis

data.

2.1

Pengertian Basis Data

Menurut Connolly (2002, p14), Basis

data adalah kumpulan data

yang

berhubungan

secara

logical

yang

dibagi,

dan mendeskripsikan

data, didesain

untuk menemukan kebutuhan informasi pada suatu organisasi.

Ramakrishnan

(2003,

p4)

menyatakan, Basis

data

adalah

koleksi

data,

secara tipikal menggambarkan aktivitas-aktivitas dari satu atau lebih organisasi

yang terkait.

Charles (1984, p5) mengemukakan, Basis data adalah koleksi dari

bermacam-macam

file

yang

merepresentasikan

sumber

informasi

lengkap,

biasanya untuk bisnis.

Hutchinson dan Sawyer (1996, p349) mengungkapkan, Basis data adalah

kumpulan data yang terintegrasi yang diorganisasikan sebagai byte, field, record

dan file.

Menurut Kamus Istilah Akuntansi (1999, p125), Basis data adalah tempat

penyimpanan data yang berkaitan yang dikelola secara bebas terpisah dari segala

program khusus

atau

aplikasi

sistem informasi.

Dapat

menyediakan

berbagai

macam sistem dalam organisasi. Intinya, merupakan lemari berkas kabinet

elektronik

yang

dapat

menyediakan

inti

dari

informasi

umum dalam

sebuah

program.

2.2

Pengertian DBMS

Menurut

Connolly

(2002,

p16),

Sistem Manajemen

Basis

Data

adalah

sistem software

yang

memungkinkan

pemakai

(user)

untuk

mendefinisikan,

membuat, memelihara, dan mengontrol akses ke basis data.

Ramakrishnan (2003, p4) menyatakan, Sistem Manajemen Basis Data

adalah software yang didesain untuk mendukung dalam pemeliharaan dan

pemanfaatan koleksi data dalam jumlah besar.

Hutchinson dan Sawyer (1996,

p349)

mengemukakan,

Sistem

Manajemen Basis Data adalah sistem komputer untuk mendefinisikan, membuat,

memanipulasi, memgontrol, mengatur dan menggunakan basis data.

Menurut Kamus Istilah Akuntansi (1999, p125), Sistem Manajemen

Basis

Data

adalah

perangkat

lunak

yang dipakai

untuk

mengelola

data

dalam

basis

data.

Merupakan

satu

set

program yang

menyediakan

penetapan,

pengawasan, dan pemasukan data.

Silberschatz (2002, p1)

mengungkapkan, Sistem Manajemen

Basis

Data

adalah kumpulan data yang saling berhubungan dan kumpulan program untuk

mengakses data-data tersebut. Kumpulan

data biasanya merujuk kepada basis

data, mengandung informasi yang relevan dengan enterprise. Tujuan utama

DBMS

adalah

untuk

menyediakan

dan

memperoleh informasi basis data yang

nyaman

(convenient)

dan

efisien.

Sistem basis

data

didesain

untuk

mengatur

sejumlah besar informasi,

manajemen data termasuk menjelaskan struktur untuk

penyimpanan

informasi dan menyediakan mekanisme untuk manipulasi

informasi.

2.3

Komponen Lingkungan DBMS

Menurut Connolly (2002, pp18-20), ada lima komponen utama dalam

lingkungan DBMS, yaitu :

Perangkap Keras (hardware), terdiri dari :

Penyimpanan secondary (magnetic disk), I/O device ex : disk

drives), device Controller, I/O Channels, dan lainnya.

Hardware

processor

dan

main

memory,

digunakan

untuk

mendukung saat eksekusi system software database.

Perangkat Lunak, terdiri dari : DBMS, sistem operasi, software jaringan

dan program aplikasinya.

Data, digunakan oleh organisasi dan data ini digambarkan dalam bentuk

skema.

Prosedur

adalah

instruksi

dan

aturan

yang

harus

diterapkan

untuk

mendesain dan menggunakan basis data dan DBMS.

Oran

g, terdiri dari :

Application

Programmers,

bertanggungjawab

untuk

membuat

aplikasi basis data dengan menggunakan bahasa pemrograman

yang ada.

End Users, siapapun yang berinteraksi dengan system secara

online melalui workstation/terminal.

(Data

Administrator),

seseorang

yang berwenang

untuk

membuat keputusan

stategis

dan

kebijakan

mengenai

data

yang

ada.

DBA (DataBase Administrator), menyediakan dukungan teknis

untuk implementasi keputusan tersebut, dan bertanggungjawab

atas keseluruhan kontrol system pada level teknis.

Hardware

Software

Data

Prosedur

Orang

Mesin

Jembatan

Gambar 2.01 Komponen DBMS

Manusia

2.4

Entity-Relationship Modeling

ER (Entity Relationship) data model didasarkan pada presepsi dunia

nyata yang terdiri dari kumpuln objek dasar , yang disebut entiti dan relationship

antara objek-objek ini.

2.4.1

Tipe Entity

Tipe entity merupakan konsep dasar dari suatu model ER. Menurut

Connolly (2002, p331), Tipe entity adalah kumpulan dari objek dengan property

yang sama, yang diidentifikasi oleh perusahaan mempunyai keberadaan yang

independen.

Keberadaan

tipe

entity

dapat

berupa

fisik

atau

‘nyata’

dan

conceptual atau ‘abstrak’.

Entity occurrence adalah pengidentifikasian objek yang unik dari sebuah

tipe entity.

Nama Entity

Staff

Branch

Gambar 2.02 Contoh Tipe Entity

2.4.2

Tipe Relationship

Menurut Connolly (2002, p334), Tipe relationship adalah kumpulan

hubungan yang mempunyai arti antara tipe entity. Relationship occurrence

adalah

hubungan yang diidentifikasi

secara unik, yang

meliputi keberadaan dari

setiap tipe entity yang berpartisipasi.

Nama

Relationship

Has

Staff

Branch

"Branch has staff"

Gambar 2.03 Contoh Tipe Relationship

2.4.3

Derajat Relationship

Menurut Connolly (2002, pp335-338), Derajat relationship adalah jumlah

tipe entity yang berpartisipasi dalam sebuah relationship. Derajat relationship

terdiri dari :

Binary Relationship adalah relationship antara dua tipe entity.

Ternary Relationship adalah relationship antara tiga tipe entity.

Quaternary Relationship adalah relationship antara empat tipe entity.

Unary

Relationship

disebut juga recursive relationship, adalah

relationship antara satu

tipe entity

dimana

tipe

entity

tersebut

berpartisipasi lebih dari satu kali dengan peran yang berbeda.

'Private own er

own s property for ren t'

PO wns >

PrivateO wner

Pro pertyFo rRent

Binary

elation ship

Staff

Branch

Client

'Staff

clien t at a bran ch '

Tern ary

elation sh ip

licito r

'A solicitor

arran ges a

bid

beh alf of buyer

supported

by a

fin an cial

in stitution '

Buyer

Arranges

Financial

Institutio n

Bid

uaternary

elation sh ip

'Staff (Supervisor)

supervises staff

(Supervisee)'

Supervises

Role nam e

Supervisor

Role nam e

Supervisee

Staff

ary

elation sh ip

Gambar 2.04 Contoh Derajat Relationship

2.4.4

Attribute

Menurut Connolly (2002, pp338-340), Atribut adalah sifat atau property

dari sebuah tipe entity atau tipe relationship. Contohnya : sebuah entity karyawan

digambarkan oleh kdKary, nmKary, almtKary dan jabatan. Atribut domain

adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.

Macam-macam atribut :

Simple

Attribute disebut juga

Atomic

Attribute,

yaitu atribut yang

terdiri

dari

satu

komponen

tunggal

dengan

keberadaan

yang

independen

dan

tidak dapat dibagi menjadi bagian yang lebih kecil lagi.

Composite

Attribute

yaitu

atribut

yang

terdiri

dari

beberapa

komponen

dimana

masing-masing komponen

memiliki

keberadaan

yang

independen.

Misalkan

atribut

alamat

dapat

terdiri

dari

jalan,

kota

dan

kode pos.

Single-value Attribute yaitu

atribut yang

mempunyai nilai tunggal untuk

setiap kejadian. Misalnya entity pemesanan memiliki satu nilai untuk

attribut noPesan pada setiap kejadian.

Multi-value Attribute yaitu atribut yang mempunyai beberapa nilai untuk

setiap kejadian. Misalnya entity Karyawan memiliki beberapa nilai untuk

attribut noTelp pada setiap kejadian.

Derived

Attribute

yaitu

atribut

yang

memiliki

nilai

yang dihasilkan dari

satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entity.

2.4.5

Key

Kita

harus

memiliki

cara

untuk menspesifikasikan

bagaimana

entity di

dalam kumpulan

entity

dapat dibedakan.

Maka ,

nilai

dari

nilai

atribut

sebuah

entity

harus

sedemikian

rupa

agar

dapat mengidentifikasi entity

secara

unik.

Sebuah key memberikan kemudahan untuk mengidentifikasi kumpulan atribut

yang

mencukupi

untuk dapat membedakan entity

yang satu dengan yang lain.

Key juga membantu mengidentifikasi relationship secara unik dan membedakan

relationship antara yang satu dengan yang lainnya.

Menurut Connolly (2002, pp340-341), Key terbagi atas :

Candidate Key adalah

jumlah

minimal atribut-atribut

yang

secara

unik

mengidentifikasikan setiap kejadian pada tipe entity.

Primary

Key

adalah

candidate

key

yang

terpilih

untuk

mengidentifikasikan setiap kejadian pada tipe entity secara unik.

Composite

Key

adalah

candidate

key

yang

terdiri

dari

dua

atau

lebih

atribut.

2.4.6

Strong and Weak Entity Type

Menurut Connolly (2002, pp341-342), Strong entity type adalah tipe

entity yang keberadaannya tidak tergantung pada tipe entity lainnya. Sedangkan

weak

entity

type

adalah

tipe

entity

yang

keberadaannya

tergantung

pada

tipe

entity lainnya. Strong entity type disebut juga parent, owner dominant sedangkan

weak entity type disebut child, dependent dan subordinate.

Strong Entity

eak

Entity

Client

States >

Preference

clientNo

{PK}

name

fName

lName

telNo

prefType

maxRent

Gambar 2.05 Contoh Strong dan Weak Tipe Entity

2.4.7

Structural Constraint

Batasan

atau

kendala

utama

pada

relationship

adalah

multiplicity.

Menurut Connolly (2002, p344), Multiplicity adalah jumlah (atau jangkauan) dari

kejadian yang mungkin terjadi pada suatu entity yang terhubung ke satu kejadian

dari entity lain yang berhubungan melalui suatu relationship.

Menurut Connolly (2002, pp345-348), ada 3 tipe relationship binary yang

menggunakan batasan enterprise yaitu :

Relasi satu-satu (1:1) yaitu relasi antara dua tipe entity dimana satu tipe

entity berelasi tepat satu atau nol dengan tipe entity lainnya.

Relasi satu-banyak (1:*)

yaitu relasi antara dua tipe entity dimana satu

tipe entity berelasi nol, satu atau banyak dengan tipe entity lainnya.

Relasi banyak-banyak (*:*)yaitu relasi antara dua tipe entity dimana tipe

entitynya saling berelasi nol, satu atau banyak.

'Each

branch is managed

by one member of

staff'

'A member of staff

can

manage zero or one

branch'

Staff

staffNo

Manages

1..1

0..1

Branch

branchNo

Multiplicity

Relasi satu-satu

(1:1)

'Each property for rent is

overseen by zero or one

member of

staff'

'Each

member

staff

overssen zero or more

properties for rent'

Staff

Oversees >

PropertyForRent

staffNo

0..1

0..*

propertyNo

Relasi satu-banyak (1:*)

'Each property for rent is

advertised in zero or more

newspapers'

'Each newspaper

advertises

one or more

properties for rent'

Newspaper

Advertises >

PropertyForRent

newspaperName

0..*

1..*

propertyNo

Relasi banyak-banyak (*:*)

Gambar 2.06 Contoh Tipe-tipe relationship pada Binary

2.4.8

Multiplicity untuk relasi yang komplek

Menurut Connolly (2002, p349), Multiplicity untuk relasi yang kompleks

adalah

jumlah

(atau

jangkauan)

dari kejadian

yang

mungkin

dari

suatu entity

dalam n-ary relationship ketika nilai entity yang lain (n-1) diketahui.

Staff

1..1

0..*

Branch

Client

Gambar 2.07 Contoh Multiplicity pada Relationship Ternary

Cara

alternatif

untuk

menggambarkan batasan multiplicity

Arti

0..1

1..1 (atau hanya 1)

0..* (atau hanya *)

1..*

5..10

0,3,6-8

Nol atau satu kejadian

Hanya satu kejadian

Nol atau banyak kejadian

Satu atau banyak kejadian

Minimum 5 dan maksimal 10 kejadian

Nol atau tiga atau enam, tujuh, atau delapan

kejadian

Tabel 2.01 Tabel Multiplicity

Multiplicity dibentuk dari 2 macam batasan pada relationship, yaitu :

Cardinality, menjelaskan jumlah maksimal dari kejadian relationship

yang

mungkin

untuk

entity

yang

berpartisipasi

dalam relationship

tersebut.

Participation, menetapkan apakah seluruh atau sebagian entity yang

berpartisipasi dalam suatu relationship.

Cardinality

'One branch is managed by

one member of staff'

'One member of staff

manages one branch

Staff

staffNo

Manages >

1..1

0..1

Branch

branchNo

'All branches are managed'

(mandatory participation for

branch)

'not All staff manage

branches'

(optional participation

for

staff)

Participation

Gambar 2.08 Cardinality dan Participation

2.5

Database Application Lifecycle

Basis data

merupakan komponen mendasar suatu

sistem

informasi,

dimana pengembangan atau pemakaiannya

harus dilihat dari perspektif yang

lebih luas berdasarkan kebutuhan organisasi. Database Aplication Lifecycle

berdampingan dengan lifecycle dari sistem informasi.

Sistem Informasi

merupakan sumberdaya

yang

memungkinkan

pengumpulan (collection), pengaturan (management), pengawasan (control) dan

penyebaran (dissemination) informasi keseluruh organisasi.

Da ta ba se Pla n ning

System D efin ition

Req u ir em en t collection

an d A n alysis

Da ta ba se D esig n

on cep tu a l

ta ba se

Desig n

DBM S Selection

lica tion

esig n

Logica l

ta ba se

Desig n

Ph ysica l D a ta ba se

Desig n

Pr ototyp in g

Im p lem en ta tion

con ver sion

loa d in g

Testin g

Op er a tion a l

in ten a n ce

Gambar 2.09 Tahapan dalam Database Application Lifecycle

2.5.1

Database Planning

Perencanaan basis data merupakan perencanaan bagaimana tahapan-

tahapan

dalam lifecycle

dapat

direalisasikan

seefektif

dan

seefisien

mungkin.

Perencanaan basis

data harus

terintegrasi dengan

keseluruhan

strategi sistem

informasi dari organisasi.

Terdapat 3 hal pokok

yang berkaitan dengan strategi

sistem informasi, yaitu :

Identifikasi rencana dan sasaran (goals) dari enterprise termasuk

mengenai sistem informasi yang dibutuhkan.

Evaluasi sistem

informasi yang ada untuk menetapkan kelebihan dan

kekurangan yang dimiliki.

Penaksiran

kesempatan

yang

mungkin

memberikan

keuntungan

kompetitif.

Metodologi untuk mengatasi hal tersebut diatas yaitu :

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.

Database Planning – Mission Objectives :

Ketika

mission

statement

telah didefinisikan,

maka

mission

objectives

didefinisikan.

Setiap

objective

(tujuan)

harus

lebih luas berdasarkan kebutuhan organisasi. Database Aplication Lifecycle

Dapat

juga

disertai

dengan

beberapa informasi tambahan yang

menspesifikasikan pekerjaan yang harus diselesaikan,

sumberdaya

yang

digunakan dan biaya untuk membayar kesemuanya itu.

2.5.2

System Definition

Definisi

system adalah

menjelaskan

batasan-batasan

dan

cakupan

dari

aplikasi basis data dan sudut pandang user atau pemakai yang utama. Sudut

pandang pemakai mendefinisikan apa

yang diwajibkan dari suatu aplikasi basis

data dari perspektif aturan kerja khusus atau area aplikasi perusahaan. Sudut

pandang pemakai diperlukan untuk memastikan bahwa tidak ada pemakai utama

dari suatu basis data yang terlupakan

ketika

pembuatan

aplikasi

baru

yang

dibutuhkan dan

membantu dalam pengembangan

aplikasi basis data

yang rumit

atau komplek juga memungkinkan permintaan-permintaan dipecah ke dalam

bagian-bagian yang lebih simple.

2.5.3

Requirement Collection and Analysis

Analisis dan pengumpulan kebutuhan merupakan suatu proses

pengumpulan dan analisis informasi mengenai bagian organisasi yang didukung

oleh aplikasi basis data, dan menggunakan informasi tersebut untuk identifikasi

kebutuhan pemakai akan sistem yang baru. Informasi dikumpulkan untuk setiap

user view utama meliputi :

Deskripsi data yang digunakan atau dihasilkan

Detail mengenai bagaimana data digunakan/dihasilkan

Beberapa kebutuhan tambahan untuk aplikasi database yang baru

Informasi dianalisis untuk identifikasi kebutuhan agar disertakan dalam

aplikasi basis data yang baru.

Aktifitas penting lainnya, adalah menentukan

bagaimana mengatur aplikasi basis data dengan multiple user view, yaitu :

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).

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 model 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.

Kombinasi keduanya (Combination of both approaches)

2.5.4

Database Design

Desain basis data merupakan suatu proses pembuatan sebuah desain basis

data yang akan mendukung tujuan dan operasi suatu perusahaan.

Tujuan

utamanya adalah:

merepresentasikan data dan relationship antar data

yang dibutuhkan oleh

seluruh area aplikasi utama dan user group.

Menyediakan model data yang mendukung segala transaksi yang

diperlukan pada data.

Menspesifikasikan desain minimal

yang

yang secara

tepat disusun untuk

memenuhi kebutuhan performa yang ditetapkan pada sistem (misal :

waktu respon).

Pendekatan dalam desain basis data :

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

mengindentifikasikan

entitas lower level, relationship dan atribut lainnya.

Bottom-up

Dimulai

dari

atribut

dasar (yaitu,

sifat-sifat

entitas

dan

relationship),

dengan

analisis

dari penggabungan

antar

atribut,

yang

dikelompokan

kedalam suatu

relasi

yang

merepresentasikan

tipe

dari

entitas dan relationship antar entitas.

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.

Mixed

Menggunakan pendekatan bottom-up dan top-down untuk bagian

yang berbeda sebelum pada akhirnya digabungkan.

Tiga fase desain basis data:

Conceptual database design

Suatu proses pembentukan model dari informasi yang digunakan

dalam perusahaan, independen dari keseluruhan aspek fisik. Model data

dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan

pemakai. Model data konseptual merupakan sumber informasi untuk fase

desain logical.

Logical database design

Suatu proses pembentukan model dari informasi yang digunakan

dalam perusahaan 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.

Physical database design

Suatu proses yang menghasilkan deskripsi implementasi basis

data 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

2.5.5

DBMS Selection

Pemilihan DBMS yang tepat untuk mendukung aplikasi basis data. Dapat

dilakukan

kapanpun

sebelum menuju

desain logical asalkan terdapat cukup

informasi

mengenai

kebutuhan

sistem.

Tahap-tahap

utama

untuk

memilih

DBMS:

Mendefinisikan terminologi studi referensi.

Mendaftar dua atau tiga produk.

Evaluasi produk.

Rekomendasi pilihan dan laporan produk.

2.5.6

Application Design

Desain

aplikasi

adalah desain

interface

user

dan

program aplikasi

yang

menggunakan dan memproses basis data. Desain basis data dan aplikasi

merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu

Transaction design

Transaksi adalah satu aksi atau serangkaian aksi

yang dilakukan

oleh user tunggal atau program aplikasi, yang mengakses atau mengubah

isi

dari

basis

data.

Kegunaan

dari desain transaksi

adalah

untuk

menetapkan dan keterangan

karakteristik high-level

dari

suatu transaksi

yang dibutuhkan pada basis data.

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.

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 instrctions, 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, terminology dan

singkatan yang digunakan harus konsisten.

Consistent use of color.

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.

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.

2.5.7

Prototyping

Prototyping adalah membuat model kerja suatu aplikasi basis data.

Tujuan utama dari pembuatan prototyping adalah:

Untuk

mengidentifikasi

feature dari

sistem

yang berjalan dengan

baik

atau tidak.

Untuk memberikan perbaikan-perbaikan atau penambahan feature baru .

Untuk klarifikasi kebutuhan pemakai.

Untuk evaluasi feasibilitas (kemungkinan

yang akan terjadi) dari desain

sistem khusus.

Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu:

Requirements prototyping, menggunakan prototype untuk menentukan

kebutuhan dari aplikasi basis data yang diinginkan dan ketika kebutuhan

itu terpenuhi maka prototype akan dibuang.

Evolutionary

prototyping,

digunakan

untuk

tujuan

yang

sama.

Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan

lanjutan menjadi aplikasi basis data yang digunakan.

2.5.8

Implementation

Implementasi

merupakan

realisasi

fisik dari

basis

data

dan desain

aplikasi. Implementasi basis data dicapai dengan menggunakan :

DDL untuk membuat skema basis data dan file basis data kosong.

DDL untuk membuat user view yang diinginkan.

3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi

basis data disertakan dengan menggunakan DML, atau ditambahkan pada

bahasa pemrograman.

2.5.9

Data Conversion and Loading

Pemindahan data yang ada kedalam basis data baru dan mengkonversikan

aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini

dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMS

biasanya memiliki

utilitas

yang

memanggil ulang

file yang sudah ada kedalam

basis data baru.

Dapat juga

mengkoversi dan

menggunakan program aplikasi dari sistem

yang lama untuk digunakan oleh sistem yang baru.

2.5.10 Testing

Testing adalah suatu proses eksekusi program aplikasi dengan tujuan

untuk

menemukan

kesalahan.

Dengan menggunakan strategi tes yang

direncanakan dan data yang sesungguhnya. Pengujian

hanya

akan

terlihat

jika

terjadi

kesalahan

software. Mendemostrasikan basis data

dan

program aplikasi

terlihat berjalan seperti yang diharapkan.

2.5.11 Operational Maintenance

Suatu

proses

pengawasan

dan

pemeliharaan

sistem setelah

instalasi,

meliputi:

Pengawasan performa sistem, jika performa menurun maka

memerlukan

perbaikan atau pengaturan ulang basis data.

Pemeliharaan dan pembaharuan aplikasi basis data (jika dibutuhkan).

Penggabungan kebutuhan baru kedalam aplikasi basis data.

2.6

Normalisasi

2.6.1

Pengertian Normalisasi

Menurut Connoly (2002, p376), Normalisasi adalah suatu teknik untuk

menghasilkan sekumpulan relasi dengan sifat-sifat (properties) yang diinginkan,

memenuhi kebutuhan data pada perusahaan.

2.6.2

Data Redundancy

Tujuan utama dilakukan normalisasi adalah untuk meminimalisasi

redundansi data dan mengurangi penggunaan tempat penyimpanan yang

dibutuhkan untuh sebuah relasi dasar.

Redundansi

data

diakibatkan

oleh

Update

Anomalies,

yang

terdiri dari

tiga tipe yaitu :

Insertion Anomalies adalah keadaan dimana kita tidak dapat menyimpan

fakta atau transaksi yang terjadi di dalam perusahaan.

Deletion

Anomalies

adalah

kondisi

bahwa

fakta

hilang

dari

basis

data

disebabkan penghapusan file yang lain.

Modification

Anomalies

adalah

kondisi

bahwa

fakta

hilang

dari

basis

data disebabkan perubahan pada file yang lain.

Untuk mengatasi anomalies ini dapat dilakukan decomposotion pada

relasi dasar. Terdapat dua sifat Decomposition yaitu

Lossless-join

Memungkinkan kita

menemukan suatu

instance relasi dasar dari

instance koresponden dalam relasi yang lebih kecil.

Dependency Preservation Properties

Memungkinkan kita untuk mengadakan batasan pada relasi dasar

dengan menyediakan beberapa batasan pada relasi yang lebih kecil.

2.6.3

Functional Dependency

Merupakan konsep inti yang terkait dengan normalisasi. Functional

Dependency,

menjelaskan

relationship

antar

atribut-atribut

dalam relasi.

Functional

Dependency

merupakan

sifat

dari arti

semantik suatu

atribut

dalam

sebuah relasi.

is functionally

dependent on A

Gambar 2.10 Diagram Function Dependency

Determinant

dari functional dependency

mengacu

kepada

atribut

atau

himpunan atribut disebelah kiri anak panah.

Karakteristik

utama

dari

functional

dependency

yang

digunakan

dalam

normalisasi :

Mempunyai

relationship

1:1

antar

atribut

sebelah

kiri

dan

kanan

dependency.

Saling terkait (Hold for all time)

Misal : staffNo Æ sName dan sName Æ staffNo

Nontrivial.

2.6.4

Proses Normalisasi

Proses Normalisasi adalah :

Suatu teknik

formal

untuk

menganalisis relasi berdasarkan primary key

dan functional dependencies antar atribut.

Dieksekusi dalam beberapa

langkah. Setiap

langkah

mengacu ke bentuk

normal tertentu, sesuai dengan sifat yang dimilikinya.

Setelah

normalisasi

diproses,

relasi

menjadi

secara

bertahap

lebih

terbatas/kuat bentuk formatnya dan juga mengurangi tindakan update

yang anomali.

Gambar 2.11 Tahapan Normalisasi

2.6.4.1 UNF (Unnormalized Form)

Merupakan suatu tabel yang berisikan satu atau lebih groups yang

berulang. Untuk membuat tabel unnormalized yaitu dengan

memindahkan

data

dari

sumber

informasi kedalam format

tabel dengan

baris dan kolom. Jika ada atribut yang bernilai multivalue, maka relasi

tersebut dalam kondisi unnormalized.

2.6.4.2 1NF (First Normal Form)

1NF

merupakan

sebuah

relasi

dimana

setiap

irisan

antara

baris

dan

kolom berisikan satu

dan

hanya satu

nilai (tidak

ada

atribut

yang

bernilai multivalue).

Cara merubah UNF ke 1NF adalah :

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.

2.6.4.3 2NF (Second Normal Form)

Berdasarkan pada konsep full functional dependency, yaitu A dan

B merupakan atribut dari sebuah relasi,

dikatakan

fully

dependent

terhadap A jika B functionally dependent pada A tetapi tidak pada proper

subset dari A.

2NF

adalah

sebuah

relasi

dalam 1NF

dan

setiap

atribut

non-

primary-key bersifat fully functionally dependent pada primary key.

Cara merubah 1NF ke 2NF adalah :

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 determinan-nya.

2.6.4.4 3NF (Third Normal Form)

Berdasarkan pada konsep transitive dependency, yaitu suatu

kondisi dimana A, B dan C merupakan atribut dari sebuah relasi, maka

jika A Æ

dan B Æ C, maka C transitively dependent pada A melalui

B. (Jika A tidak functionally dependent pada B atau C).

3NF adalah sebuah relasi dalam 1NF dan 2NF dan dimana tidak

terdapat atribut non-primary-key atribut yang bersifat transitively

dependent pada primary key.

Transitive

dependency adalah

jika suatu

atribut

dependent

pada

satu atau lebih non-primary-key.

Cara merubah 2NF ke 3NF adalah :

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 determinan-nya.

2.6.4.5 BCNF (Boyce-Codd Normal Form)

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. Suatu relasi dikatakan

BCNF, jika dan hanya jika setiap determinan merupakan candidate key.

Perbedaan antara 3NF dan BCNF yaitu untuk

functional

dependency

3NF

memungkinkan

dependency

ini

dalam

suatu

relasi jika

B adalah

atribut primary-key dan A bukan merupakan

candidate key. Sedangkan

BCNF menetapkan dengan jelas bahwa untuk

dependency

ini

agar

ditetapkan

dalam relasi

maka

harus

merupakan

candidate key.

Setiap relasi dalam BCNF juga merupakan 3NF, tetapi relasi

dalam 3NF belum tentu termasuk kedalam BCNF.

Dalam BCNF

kesalahan

jarang

sekali

terjadi.

Kesalahan

dapat

terjadi pada relasi yang

Terdiri dari 2 atau lebih composite candidate key.

Candate key overlap, sedikitnya satu atribut.

2.6.4.6 4NF (Fourth Normal Form)

Meskipun sebuah tabel telah mencapai normal BCNF, namun

masih mungkin terjadi kesulitan berkenaan dengan adanya informasi

berulang yang disebut sebagai multivalue.

Multi-valued Dependency adalah representasi ketergantungan

antara attribut (contoh : A, B dan C) dalam relasi, misalnya untuk setiap

nilai A ada sekumpulan nilai untuk B dan sekumpulan nilai untuk C.

Tetapi, kumpulan nilai B dan C independen satu sama lain.

4NF adalah relasi yang termasuk

BCNF

dan

tidak

mengandung

nontrivial ketergantungan nilai jamak.

2.6.4.7 5NF (Fifth Normal Form)

5NF

disebut

juga

Project

Join

Normal

Form (PJNF)

karena

berkaitan

dengan

konsistensi

antara tabel asal dengan tabel hasil

pengabungan, tabel proyeksi atau tabel dekomposisi.

Suatu

relasi

berada

dalam 5NF

jika

dan

hanya

setiap

ketergantungan gabungan (Join Dependency) pada relasi R diperoleh dari

kunci-kunci kandidat relasi R.

Ketergantungan gabungan (Join Dependency) merupakan bentuk

umum dari

ketergantungan

nilai

jamak.

Ketergantungan

nilai

jamak

(Multi_Valued Dependency) merupakan bentuk umum dari

ketergantungan fungsional (Functional Dependency).

2.7

Perancangan Software Model Waterfall

Model Waterfall menyarankan pendekatan sistematic, sequential untuk

pengembangan software

yang dimulai pada

level sistem & perkembangan

melalui analysis, design, coding & support.

Model

Waterfall

memiliki

aktivitas System Engineering

and

Modeling,

Software Requirement Analysis, Design, Code Generation, Testing dan Support.

System

Engineering dan

Modeling

Software

Requirement

and

Analysis

Design

Code Generation

Testing

Support

Gambar 2.12 Model Waterfall

2.7.1

System Engineering and Modeling

Karena software selalu menjadi bagian dari sistem yang besar, pekerjaan

dimulai

dengan

membangun

persyaratan

untuk

semua

elemen

sistem dan

kemudian mengalokasikan beberapa subset

dari requirement ini ke dalam

software. Pandangan sistem ini sangat penting ketika software harus berinteraksi

dengan elemen

lain seperti hardware, orang dan database. Langkah ini

meliputi

pengumpulan requirement

pada

level

sistem dengan sejumlah

kecil

design

dan

analysis level atas.

2.7.2

Software Requirement Analysis

Proses pengumpulan requirement diintensifkan dan difokuskan spesifik

pada software. Untuk mengerti cara kerja program yang akan dibuat, analis harus

mengerti domain informasi untuk software. Requirement untuk kedua sistem dan

software didokumentasikan dan direview dengan customer.

2.7.3

Design

Desain software sebenarnya merupakan proses multistep yang fokus pada

atribut berbeda pada program : data struktur,

arsitektur software, representasi

interface dan detail procedural. Proses desain mentranslasikan pengumpulan

requirement menjadi representasi software yang dapat menilai kualitas sebelum

coding dimulai.

2.7.4

Code Generation

Desain

harus

ditranslasikan

dalam

form

machine-readable.

Langkah

Code Generation melakukan tugas ini dan dapat dikerjakan secara mekanis.

2.7.5

Testing

Ketika

code

telah dibuat, testing program dimulai. Proses testing

fokus

pada internal logikal software, memastikan bahwa semua statement telah diuji

coba,

dan

pada

external

fungsional,

melakukan

tes

untuk

mengatasi

kesalahan

dan

memastikan

bahwa

input

terdefinisi

akan

menghasilkan

hasil

sebenarnya

yang sesuai dengan hasil yang dibutuhkan.

2.7.6

Support

Software pasti akan mengalami perubahan

setelah diberikan kepada

customer. Dukungan software/ pemeliharaan menerapkan kembali setiap fase

sebelumnya ke dalam program yang sudah ada daripada ke program yang baru.

2.8 Penjualan

2.8.1

Pengertian Penjualan

Menurut Kamus Istilah Akuntansi (1999, p404), Penjualan adalah (1)

Penerimaan

yang

diperoleh

dari

pengiriman barang dagangan atau dari

penyerahan

pelayanan dalam

bursa

sebagai

bahan

pertimbangan.

Pertimbangan

ini dapat dalam bentuk tunai, peralatan kas, atau harta lainnya. Pendapatan dapat

diperoleh

pada

saat

penjualan,

karena terjadi

pertukaran, harga

jual

dapat

ditetapkan, dan bebannya diketahui. (2) Dalam penjualan eceran, ada penurunan

harga sementara untuk menggerakkan persediaan dan meningkatkan kas.

2.8.2

Tipe-tipe Penjualan

Menurut Mulyadi (2001, p202), penjualan dapat dibagi menjadi dua tipe

berdasarkan cara pembayarannya, yaitu :

Penjualan Tunai

Penjualan

tunai

adalah

transaksi

penjualan

dimana

barang

atau

jasa

baru

diserahkan

oleh

perusahaan kepada pembeli jika perusahaan

telah menerima uang atau pembayaran dari pembeli.

Penjualan Kredit

Penjualan kredit

adalah transaksi penjualan dimana

jika

pesanan

dari pembeli atau pelanggan telah dipenuhi dengan mengirim barang atau

penyerahan jasa, maka untuk jangka waktu tertentu perusahaan memiliki

piutang kepada pelanggannya.

2.9

Pembelian

2.9.1

Pengertian Pembelian

Pembelian

adalah

transaksi

yang

dilakukan

perusahaan

dalam rangka

pengadaan barang yang diperlukan oleh perusahaan baik yang digunakan sendiri

maupun yang akan dijual kembali.

2.9.2

Tipe-tipe Pembelian

Menurut Mulyadi (2001, p299), pembelian dapat dibagi menjadi dua tipe

berdasarkan pemasoknya, yaitu :

Pembelian Lokal

Pembelian lokal adalah pembelian dari pemasok dalam negeri.

Pembelian Impor

Pembelian impor adalah pembelian dari pemasok luar negeri.

2.10

Persediaan

Persediaan adalah barang yang dimiliki dengan tujuan untuk dijual

kembali atau diproses dan kemudian dijual. Menurut Prinsip Akuntansi

Indonesia, persediaan digunakan untuk menyatakan barang berwujud yang :

Tersedia untuk dijual (barang dagang/barang jadi)

Masih

dalam

proses

produksi

untuk

diselesaikan, kemudian

dijual

(barang dalam proses/pengolahan)

Akan digunakan untuk produksi barang jadi yang akan dijual (bahan baku

dan bahan pembantu) dalam rangka kegiatan normal perusahaan

Menurut

Kamus Istilah

Akuntansi (1999,

p251),

Persediaan

adalah

barang dagangan atau persediaan yang ada ditangan atau dalam perjalanan pada

suatu waktu tertentu. Yang termasuk dalam persediaan adalah : (1) barang dalam

transit yang fakturnya telah diterima dan (2) barang selain barang titipan.

Menurut Mulyadi (2001, p553), persediaan bisa berbeda tergantung jenis

usahanya. Dalam perusahaan manufaktur, persediaan terdiri dari :

Persediaan produk jadi

Persediaan produk dalam proses

Persediaan bahan baku

Persediaan bahan penolong

Persediaan bahan habis pakai pabrik

Persediaan suku cadang

Sedangkan dalam perusahaan dagang, persediaan hanya

terdiri dari satu

golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli

untuk tujuan dijual kembali.