5

BAB 2

LANDASAN TEORI

2.1 Teori - Teori Umum

2.1.1 Basis Data

Pengertian basis data menurut Connoly dan Begg (2002, p14), basis data

adalah penggunaan bersama dari data yang terhubung secara logik dan deskripsi dari

data, yang dirancang untuk keperluan informasi dari suatu perusahaan.

Database merupakan kumpulan file-file yang saling berelasi, relasi tersebut

biasa ditujukan dengan kunci dari setiap file yang ada. Kegunaan dari database:

1. Menghilangkan data yang berulang (redundancy)

2. Akses data yang terbatas.

3. Meningkatkan keamanan.

4. Multiple User.

5. Independensi data (kebebasan data).

2.1.2 Database Management System (DBMS)

Database Management System (DBMS) adalah suatu sistem perangkat lunak

yang memungkinkan user untuk mendefinisikan, membuat, dan mengatur basis data

dan juga menyediakan suatu kontrol akses ke database (Connolly, 2002, p16).

DBMS berinteraksi dengan program aplikasi user dan basis data. DBMS

menyediakan fungsi-fungsi sebagai berikut :

6

1. DBMS mengizinkan aplikasi mendefinisikan struktur dari basis data dengan

pernyataan SQL. Pernyataan SQL yang mendefinisikan atau mengubah struktur

ini disebut dengan Data Definition Language (DDL).

2. DBMS mengizinkan aplikasi memanipulasi informasi yang disimpan didalam

basis data dengan pernyataan SQL. Pernyataan SQL yang memanipulasi

informasi ini disebut dengan Data Manipulation Language (DML).

2.1.2.1 Komponen - Komponen DBMS

DBMS memiliki lima komponen penting (Connolly, 2002, p18-20) yaitu:

1. Hardware ( perangkat keras )

Dalam menjalankan aplikasi dan DBMS diperlukan perangkat keras yang dapat

berupa a single personal computer, single mainframe, komputer jaringan berupa

server.

2. Software ( perangkat lunak )

Komponen perangkat lunak meliputi DBMS software dan aplikasi program

berserta sistem operasi (OS), termasuk perangkat lunak tentang jaringan bila

DBMS digunakan dalam jaringan berupa LAN.

3. Data

Data merupakan komponen terpenting dalam DBMS khususnya sudut pandang

dari end user mengenai data.

4. Prosedur

Prosedur merupakan panduan dan instruksi dalam membuat desain dan

menggunakan basis data. Prosedur didalam basis data dapat berupa : login di

dalam basis data, penggunaan sebagian fasilitas DBMS, cara menjalankan dan

7

menghentikan DBMS, mebuat backup database, memeriksa hardware dan

software yang sedang berjalan, mengubah struktur basis data, meningkatkan

kinerja atau mebuat arsip data pada secondary storage.

5. Manusia.

Komponen terakhir yaitu manusia yang terlibat dalam sistem tersebut.

2.1.2.2 Keuntungan dan Kerugian DBMS

Menurut McLeod (2001, p269), keuntungan DBMS adalah sebagai berikut:

1. Mengurangi pengulangan data.

Jumlah total file akan berkurang dengan menghapus file-file duplikat atau dengan

menghapus data yang sama di beberapa file.

2. Mencapai idependensi data.

Spesifikasi data disimpan dalam skema daripada dalam tiap program aplikasi.

Perubahaan dapat dibuat pada struktur data tanpa mengurangi program yang

mengakses data.

3. Mengintegrasikan data dari beberapa file.

Ketika file dibentuk, DBMS menyediakan kaitan logis, organisasi fisik tidak lagi

menjadi kendala.

4. Mengambil data dan informasi secara cepat.

Hubungan-hubungan logis dan DML serta query language memungkinkan

pemakai mengambil data dalam hitungan detik atau menit, yang sebelumnya

memerlukan beberapa jam atau hari.

8

5. Meningkatkan keamanan.

Baik DBMS mainframe maupun komputer mikro dapat menyertakan beberapa

tingkatan keamanan seperti kata sandi (password), directory pemakai, dan bahasa

sandi (encryption). Data yang dikelola oleh DBMS juga lebih aman daripada data

lain dalam perusahaan.

Sedangkan, kerugian dari DBMS adalah sebagai berikut :

1. Menggunakan perangkat lunak yang mahal.

DBMS mainframe masih sangat mahal. DBMS berbasis komputer mikro,

walaupun biayanya hanya beberapa ratus dolar, namun menggambarkan

pengeluaran yang besar bagi organisasi kecil.

2. Memakai konfigurasi perangkat keras yang besar.

DBMS memerlukan kapastias penyimpanan primer dan sekunder yang lebih besar

daripada yang diperlukan oleh program aplikasi lain.

3. Meperkerjakan dan mempertahankan staff DBA.

DBMS memerlukan pengetahuan khusus agar dapat memanfaatkan

kemampuannya secara penuh. Pengetahuan khusus ini dimiliki oleh para pengelola

database (DBA) secara baik.

2.1.3 Entity – Relationship Diagram

Menurut Jeffrey A. Hoffer, Marry R, Prescott dan Fred R. McFadden (2002,

p142), entity relationship modeling adalah perwakilan detil dan logikal dari data untuk

sebuah organisasi atau area bisnis.

Dalam mendesain basis data, hal yang paling penting adalah dengan

menggunakan Entity Relationship (ER). Karena tanpa ER, bisa dipastikan proses

9

pembuatan basis data berjalan lama dan tidak teratur. Selain itu yang perlu

diperhatikan adalah membuat relasi-relasi yang benar diantara tabel. Proses desain

basis data cukup menghasilkan waktu yang lama jika basis datanya besar.

Pendokumentasian desain basis data mutlak harus dilakukan dengan baik, agar mudah

didalam pengembangan dan perbaikan nantinya.

Pendokumentasian desain juga harus dilakukan dengan baik agar mudah di

dalam pengembangan dan perbaikan nantinya.

2.1.3.1 Entity

Konsep dasar dari Model ER adalah Entity, yaitu kumpulan dari objek-

objek dengan sifat (properti) yang sama, yang diidentifikasi oleh enterprise

mempunyai eksistensi yang independen. Keberadaannya dapat berupa fisik

maupun abstrak.

Nama Entiti

Staff Branch

Gambar 2.1 Contoh Tipe Entiti (Connolly and Begg, p333)

2.1.3.2 Attributes

Merupakan sifat-sifat (properti) dari sebuah entity atau type relationship.

Contohnya: sebuah entity Staff digambarkan oleh atribut staffNo, name, position

dan salary.

10

Attribute domain adalah himpunan nilai yang diperbolehkan untuk satu

atau lebih atribut. Macam-macam atribut:

1. Simple Attribute

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

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

Atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entitas

Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian.

4. Multi-valued Attribute

Atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misal entitas

Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian.

5. Derived Attribute

Atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut

lainnya, dan tidak harus berasal dari satu entitas.

2.1.3.3 Relationship Type

Relationship types adalah kumpulan keterhubungan yang mempunyai arti

(meaningful associations) antara tipe entitas yang ada.

11

Relationship occurrence yaitu keterhubungan yang diidentifikasi secara

unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.

Derajat relationship yaitu jumlah entitas yang berpartisipasi dalam suatu

relationship. Derajat relationship terdiri dari :

1. Binary Relationship

Keterhubungan antar dua tipe entitas. Contoh binary relationship antara Staff

dengan Branch yang disebut Has.

Staff BranchHas

RelationshipName

‘Branch has Staff’

Gambar 2.2 Contoh Binary Relationship (Connolly and Begg, p335)

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.

12

Staff

C lient

BranchRegister

‘S taff registers a c lient at a Branch’

Gambar 2.3 Contoh Ternary Relationship (Connolly and Begg,p336)

3. Quaternary Relationship

Keterhubungan antar empat tipe entitas. Contoh Quaternary Relationship yang

dinamakan Arranges. Relasi ini melibatkan 4 entity yaitu Buyer, Solicitor,

Financial Intstuttion dan Bid. Relasi ini menggambarkan Buyer, diberi masukan

oleh Solicitor, dan didukung oleh Financial Institution, melakukan penawaran

(Bid).

Buyer Arranges

Solicitor

Bid

FinancialInstitution

‘A Solicitor arranges a Bid onbehalf of a Buyer supported by a

Financial Institution’

Gambar 2.4 Contoh Quaternary Relationship (Connolly and Begg,p337)

4. Recursive Relationship

Keterhubungan antar satu tipe entitas, dimana tipe entitas tersebut berpartisipasi

lebih dari satu kali dengan peran yang berbeda. Relationship dapat diberikan

13

role names untuk meng-identifikasikan keterkaitan tipe entitas dalam

relationship. Contoh entitas Staff yang berperan menjadi Supervisor dan Staff

yang di-Supervisor-i.

Staff

Role Name

Role Name

Supervises

Supervisee

Supervisor

Gambar 2.5 Contoh Recursive Relationship (Connolly and Begg,p337)

2.1.3.4 Key

Menurut David M. Kroenke (2002, p124), key adalah sebuah field yang

digunakan untuk mengidentifikasi sebuah record.

Candidate key yaitu sebuah atribut satu atau lebih yang secara unik

mengidentifikasi sebuah baris. Atribut ini mempunyai nilai yang unik pada

hampir tiap barisnya. Fungsi dari candidate key adalah sebagai calon primary

key.

Primary key yaitu candidate key yang dipilih untuk mengidentifikasikan

setiap kejadian/record dari suatu entitas secara unik pada hamper tiap barisnya.

Promary key harus merupakan field yang benar-benar unik.

Composite key yaitu candidate key yang terdiri dari dua atau lebih atribut.

Pada kondisi tertentu, suatu atribut tidak dapat digunakan untuk mengidentifikasi

14

baris secara unik dan membutuhkan kolom lain untuk digunakan sebagai primary

key.

Alternate key adalah candidate key yang tidak dipilih sebagai primary key.

Foreign key adalah jika sebuah primary key terhubung ke tabel lain dan

fungsinya sebagai penghubung antar tabel.

2.1.4 Data Definition Language

Merupakan bagian dari sistem manajemen basis data, dipakai untuk

mendefinisikan dan mengatur semua atribut dan properti dari sebuah basis data.

DDL digunakan untuk mendefinisikan basis data, tabel, view.

1. Create Table

Pernyataan create table digunakan untuk membuat tabel dengan

mengidentifikasikan tipe data untuk tiap kolom.

Bentuk umum:

CREATE TABLE Table_Name

( Column_Name DataType [NULL | NOTNULL]

(, Column_Name DataType [NULL | NOTNULL]

2. Alter Table

Pernyataan alter table digunakan untuk menambah atau membuang kolom dan

konstrain.

Bentuk umum:

ALTER TABLE Table_Name

[ADD Column_Name DataType [NULL | NOTNULL] ]

[DROP Column_Name DataType [RESTRICT | CASCADE] ]

15

[ADD Constrain_Name]

[DROP Constrain_Name [RESTRICT \ CASCADE] ]

3. Drop Table

Pernyataan drop table digunakan untuk menghapus tabel berserata semua data

yang terkait didalamnya.

Bentuk umum:

DROP TABLE Table_Name

4. Create Index

Pernyataan create index digunakan untuk membuat indeks pada tabel.

Bentuk umum:

CREATE [UNIQUE] INDEX Index_Name

ON Table_Name

( Column_Name [, Column_Name]… )

5. Drop Index

Pernyataan drop index digunakan untuk menghapus indeks yang telah dibuat.

Bentuk umum:

DROP INDEX Index_Name

2.1.5 Data Manipulation Language

Data Manipulation (DML) dipakai untuk menampilkan, menambah,

mengubah, dan menghapus data didalam obyek-obyek yang didefinisikan oleh DDL.

Operasi manipulasi data yang biasanya digunakan adalah sebagai berikut:

16

1. Select

Pernyataan select digunakan untuk menampilkan sebagian atau seluruh dari suatu

tabel dan menampilkan kombinasi isi dari beberapa tabel.

Bentuk umum:

SELECT Fields

FROM Table_Name

WHERE Condition

2. Update

Pernyataan update digunakan untuk mengubah isi satu atau beberapa atribut dari

suatu tabel.

Bentuk umum:

UPDATE Table_Name

SET Column1 = Value1, Column2 = Value2, …

WHERE Condition

3. Insert

Pernyataan insert digunakan untuk menambah satu atau beberapa baris nilai baru ke

dalam suatu tabel.

Bentuk umum:

INSERT Table_Name ( Column list ) VALUES ( Value list )

4. Delete

Pernyataan delete digunakan untuk menghapus sebagian atau seluruh isi dari suatu

tabel.

Bentuk umum:

DELETE FROM Table_Name

17

WHERE Condition

2.1.6 Normalisasi

Normalisasi adalah sebuah teknik untuk menghasilkan relasi atau hubungan

dengan properti-properti yang diinginkan, yang memberikan kebutuhan data dari

suatu perusahaan Suatu desain database harus memenuhi kondisi untuk tidak

mengandung anomali, yaitu suatu kejanggalan dari penempatan atribut tertentu dari

suatu obyek data. Untuk membedakan satu record dengan yang lainnya maka perlu

dipilih atribut atau kombinasi atribut sebagai kunci primer (primary key) (Connolly,

2002, p376).

Tujuan pembuatan normalisasi adalah:

1. Membuat seminim mungkin terjadinya data rangkap

2. Menghindarkan adanya data yang tidak konsisten terutama bila terjadi

penambahan, penghapusan data sebagai akibat adanya data rangkap

3. Menjamin bahwa identitas tabel secara tunggal sebagai determinan semua

atribut.

2.1.6.1 Bentuk Normal Pertama (First Normal Form / 1st NF )

Aturan normalisasi pertama (1st NF) menurut Connolly dan Begg

(2002,p388), dapat dikatakan bahwa sebuah relasi dimana setiap baris dan

kolom hanya berisi satu nilai.

Suatu data dikatakan unormalized (UNF), jika didalamnya mengandung

kelompok yang berulang (repeating group), sehingga untuk membentuk

normalisasi pertama repeating group harus dihilangkan. Nilai dari setiap atribut

18

adalah tunggal. Kondisi ini dapat diperoleh dengan melakukan eliminasi

terjadinya data ganda (repeating group). Namun pada kondisi pertama ini

kemungkinan masih terjadi adanya data rangkap.

2.1.6.2 Bentuk Normal Kedua (Second Normal Form / 2nd NF )

Aturan normalisasi kedua (2nd NF) menurut Connolly dan Begg

(2002,p392), dapat dikatakan bahwa sebuah relasi dalam bentuk normal pertama

dan setiap atribut bukan primary key yang tergantung secara fungsional kepada

primary key.

Pengujian bentuk normal kedua dapat dihasilkan dengan melihat

apakah ada atribut bukan primary key yang merupakan fungsi dari sebagian

primary key (partial dependency).

2.1.6.3 Bentuk Normal Ketiga (Third Normal Form / 3rd NF)

Aturan normalisasi ketiga (3rd NF) menurut Connolly dan Begg (2002,

p394) adalah sebuah relasi dalam bentuk normal pertama dan kedua dan setiap

atribut yang bukan primary key yang bergantung secara transitif kepada primary

key.

Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah

terdapat atribut yang bukan key tergantung fungsional terhadap atribut bukan key

lainnya (disebut ketergantungan transitif atau transitive dependence). Dengan

cara yang sama, maka setiap ketergantungan transitif dipisahkan. 3rd NF sudah

cukup baik dalam arti anomali (data yang berulang) yang dikandungnya sudah

sedemikian minimum.

19

2.1.7 Data Application Lifecycle

Tahapan penerapan lifecycle dalam metodologi perancangan basis data menurut

Connolly dan Begg (2002, p270), Database Systems A Practical sebagai berikut :

20

Database Planning

Physical Database Design

DBMS Selection (optional) Aplication Design

Logical Database Design

Operation Maintenance

Conceptual Database Design

Testing

Data Conversion and Loading

System Definition

Implementation

Requirement Collection and Analysis

Prototyping(optional)

Database Design

Gambar 2.6 Tahapan dari Application Database Lifecycle (Connolly and Begg,p272)

21

2.1.7.1 Database Planning

Menurut Connoly dan Begg (2002, pp273-274), perencanaan basis data

(database planning) merupakan aktivitas manajemen yang mengizinkan

tingkatan dari aplikasi basis data untuk direalisasikan se-efisien mungkin dan se-

efektif mungkin. Database planning harus diintegrasikan dengan keseluruhan

strategi sistem informasi dari perusahaan. Ada 3 hal penting dalam menyusun

sebuah strategi sistem informasi, yaitu :

1. Identifikasi dari tujuan dan rencana perusahaan dengan penentuan kebutuhan

sistem informasi berikutnya.

2. Evaluasi dari sistem informasi saat ini untuk menentukan kelebihan dan

kelemahan yang ada saat ini.

3 Penilaian dari kesempatan - kesempatan TI yang mungkin menghasilkan

keuntungan kompetitif.

Langkah penting dari tahap ini adalah mendefinisikan secara jelas tentang

pernyataan misi untuk proyek basis data. Pernyataan tersebut mendefinisikan

tujuan utama dari aplikasi basis data. Bila pernyataan tersebut selesai maka

langkah selanjutnya adalah mengidentifikasikan sasarannya. Pernyataan dan

sasaran ini perlu didukung oleh informasi- informasi tambahan yang menentukan

pekerjaan apa saja yang harus diselesaikan, sumber-sumber yang

mendukungnya, dan biaya yang harus dikerluarkan.

22

2.1.7.2 System Definition

Menurut Connolly dan Begg ( 2002, p274 ) definisi sistem (system

definition) adalah memaparkan jangkauan dari aplikasi basis data dan

pandangan-pandangan utama para pemakai. Sebelum mendesain suatu aplikasi

basis data penting untuk terlebih dahulu mengidentifikasikan batasan–batasan

dari sistem yang sedang diteliti, kaitannya dengan sistem informasi di

perusahaan. Perlu dipikirkan untuk kebutuhan yang akan dating selain dari

keadaan saat ini.

Pandangan pemakai yang merupakan aspek penting dari pengembangan

aplikasi basis data karena membantu untuk memastikan bahwa tidak ada

pemakai utama basis data yang terlupa ketika pengembangan aplikasi baru

tersebut.

2.1.7.3 Requirement Collection and Analysis

Menurut Connolly and Begg (2002, p276), analisis data dan

pengumpulan kebutuhan (requirement collection and analysis) adalah proses

pengumpulan dan analisis informasi tentang bagian dari perusahaan yang akan

didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk

mengidentifikasi kebutuhan pemakai terhadap sistem baru.

Informasi yang dikumpulkan termasuk:

1. Penjabaran dari data yang digunakan,

2. Detail mengenai bagaimana data digunakan,

3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru.

23

Informasi ini kemudian dianalisis untuk mengidentifikasi kebutuhan yang

dimasukkan untuk aplikasi basis data tersebut. Ada tiga macam pendekatan

untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai

pandangan pemakai, yaitu :

1. Pendekatan centralized

Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set kebutuhan

untuk aplikasi basis data. Umumnya pendekatan ini dipakai jika basis datanya

tidak terlalu kompleks

2. Pendekatan view integration

Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun sebuah

model data yang terpisah yang merepresentasikan tiap pandangan pemakai

tersebut. Hasil dari data-data model tersebut kemudian disatukan di bagian basis

data.

3. Kombinasi keduanya.

2.1.7.4 Application Design

Menurut Connolly dan Begg (2002, p287-288), perancangan aplikasi

adalah merancang antarmuka pemakai (user interface) dan program aplikasi,

yang akan memproses basis data.

Dalam perancangan aplikasi harus memastikan semua pernyataan

fungsional dari spesifikasi kebutuhan pemakai (user requirement specification)

yang menyangkut perancangan aplikasi program yang mengakses basis data dan

merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap isi

basis data (retrieve , update dan kegiatan keduanya). Artinya bagaimana fungsi

24

yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai (user

interface) yang tepat. Antarmuka yang dirancang harus memberikan informasi

yang dibutuhkan dengan cara untuk menciptakan ‘user friendly’. Kebanyakan

antarmuka pemakai yang diabaikan akan niscaya membuat masalah.

2.1.7.5 DBMS Selection

Menurut Connolly dan Begg (2002,p284), pemilihan DBMS yang sesuai

untuk mendukung aplikasi basis data yang mencakup :

1. Mendefinisikan syarat-syarat referensi studi

Menentukan sasaran, batasan masalah dan tugas yang harus dilakukan.

2. Mendaftar 2 atau 3 jenis barang

Membuat daftar barang-barang, misalkan dari mana barang ini didapat,

berapa biayanya serta bagaimana bila ingin mendapatkannya.

3. Mengevaluasi barang

Barang - barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui

kelebihan dan kekurangan barang tersebut.

4. Merekomendasikan pilihan dan membuat laporan

Merupakan langkah terakhir dari DBMS yaitu mendokumentasikan proses

dan untuk menyediakan pernyataan mengenai kesimpulan dan

rekomendasi terhadap salah satu produk DBMS.

25

2.1.7.6 Database Design

Menurut Connolly dan Begg (2002, p279), perancangan basis data (

database design ) merupakan proses pembuatan suatu desain untuk sebuah basis

data yang akan mendukung operasional dan sasaran suatu perusahaan.

Ada 2 pendekatan untuk mendesain sebuah basis data, yaitu :

1. Pendekatan bottom-up

Yang dimulai pada tingkat awal dari atribut (yaitu properti dari entiti dan

relationship) yang mana melalui analisis dari asosiasi antar atribut,

dikelompokkan menjadi hubungan yang merepresentasikan jenis-jenis entitas

dan hubungan antar entitas. Pendekatan ini cocok untuk mendesain basis data

yang simple dengan jumlah atribut yang tidak banyak.

2. Pendekatan top-down

Digunakan pada basis data yang lebih kompleks, yang dimulai dengan

pengembangan dari model data yang mengandung beberapa entitas dan

hubungan tingkat tinggi dan kemudian memakai perbaikan top down berturut –

turut untuk mengidentifikasi entitas, hubungan dan atribut berkaitan tingkat

rendah. Pendekatan ini biasanya digambarkan melalui ER (entity relationship).

Pada tahap ini ada bagian yang disebut data modeling yang digunakan untuk

membantu pemahaman dari data dan untuk memudahkan komunikasi tentang

kebutuhan informasi. Dengan dibuatnya model data dapat membantu memahami:

1. Pandangan tiap pemakai mengenai data.

2. Kealamian data itu sendiri, kebebasan representasi fisiknya

3. Kegunaan dari data berdasarkan pandangan pemakai.

26

Kriteria untuk model data, yaitu :

1. Structural validity

Konsistensi dengan cara yang didefinisikan perusahaan dan menyusun informasi.

2. Simplicity

Kemudahan untuk pemahaman baik bagi yang professional di bidang sistem

informasi maupun pemakai yang nonteknis.

3. Expressibility

Kemampuan untuk membedakan antara data yang berbeda, dan hubungan antar

data.

4. Nonredundancy

Pembuangan informasi yang tak ada hubungannya khususnya. Representasi dari

tiap potongan informasi tepatnya hanya sekali.

5. Shareability

Tidak spesifik untuk aplikasi dan teknologi khusus apapun dan dengan demikian

dapat digunakan oleh banyak orang.

6. Extensibility

Kemampuan mengembangkan untuk mendukung kebutuhan baru dengan efek

minimal bagi pemakai yang ada.

7. Integrity

Konsistensi terhadap cara yang digunakan perusahaan dan mengatur informasi.

8. Diagrammatic representation

Kemampuan untuk mereprensentasikan sebuah model menggunakan notasi

diagram yang dapat dipahami dengan mudah.

27

Menurut Connolly dan Begg (2002, p419-437) Database design dibagi

dalam tiga tahapan yaitu conceptual database design, logikal database design,

dan physical database design.

2.1.7.7 Prototyping

Prototyping adalah membuat model kerja dari aplikasi basis data, yang

membolehkan perancang atau user untuk mengevaluasi hasil akhir sistem, baik

dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan utama dari

mengembangkan suatu prototype adalah mengijinkan user untuk menggunakan

prototype guna mengidentifikasikan corak sistem apakah bekerja dengan baik

dan jika mungkin meningkatkan corak baru kepada aplikasi database. Dengan

cara ini, kebutuhan dari pemakai dan pengembang sistem dalam mengevaluasi

kelayakan design sistem akan semakin jelas sehingga kelebihan atau kekurangan

sistem dapat ditangani dengan baik.

Strategi prototyping yang umum digunakan sekarang ada dua,yaitu

requirement dan evolutionary prototyping. Requirement prototyping adalah

menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basis

data dan ketika kebutuhna sudah terpenuhi, prototype tidak digunakan lagi atau

dibuang. Sedangkan evolutionary prototype menggunakan tujuan yang sama,

tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya

dikembangkan menjadi aplikasi basis data yang lengkap.

28

2.1.7.8 Implementation

Implementation merupakan realisasi secara fisik dari database dan desain

aplikasi (Connolly, 2002, p292). Pada tahap penyelesaian desain (dimana dapat

melibatkan pembuatan prototype atau tidak), kini kita dapat menerapkan basis

data dan program aplikasi yang telah kita buat. Implementasi basis data

menggunakan DDL yang kita pilih dalam melakukuan pemilihan DBMS atau

dengan menggunakan Graphical User Interface (GUI), yang menyediakan

fungsional yang sama dengan pernyataan DDL yang low level. Pernyataan DDL

digunakan untuk menciptakan struktur basis data dan mengosongkan file yang

terdapat dalam basis data tersebut. Pandangan pemakai lainnya juga

diimplementasikan dalam tahapan ini. Data Manipulation Language (DML)

digunakan untuk mengimplementasikan transaksi basis data di dalam bagian

aplikasi program dari sasaran DBMS,mungkin termasuk host programming

language seperti, Visual basic, Delphi, C, C++, Java, COBOL, Ada atau Pascal.

2.1.7.9 Data Conversion and Loading

Menurut Connolly (2002, p293), Data conversion and loading adalah

mencakup pengambilan data dari sistem lama untuk dipindahkan ke dalam

sistem yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data

baru sedang menggantikan ssitem yang lama. Sekarang, DBMS yang memiliki

kegunaan yang dapat mengisi file yang ada ke dalam sistem yang baru telah

dianggap umum, kegunaan yang ada umumnya memerlukan spesifikasi sumber

file dan target basis data yang baru. Ketika conversion dan loading dibutuhkan,

29

prosesnya harus direncanakan untuk memastikan kelancaran transaksi untuk

keseluruhan operasi.

2.1.7.10 Testing

Testing adalah suatu proses melaksanakan program aplikasi dengan

tujuan menemukan kesalahan (Connolly, 2002, p293). Sebelum diterapkan dalam

suatu sistem, basis data harus dilakukan testing terlebih dahulu. Hal ini dicapai

dengan penggunaan secara hati-hati untuk merencanakan suatu test dan data

yang realistis sedemikian sehingga keseluruhan proses pengujian sesuai dengan

metode dan dilaksanakan sesuai aturan yang ada.

2.1.7.11 Operation Maintenance

Operational maintenance adalah proses memantau dan memelihara

sistem setelah di-install (Connolly, 2002, p293-294). Pada tahapan sebelumnya,

basis data benar-benar diuji dan diimplementasikan. Sekarang sistem beralih ke

tahapan pemeliharaan. Yang termasuk aktifitas dari tahapan ini adalah sebagai

berikut:

1. Memantau kinerja dari sistem.Jika kinerjanya menurun dibawah level yang

dapat diterima, mungkin basis data perlu diorganisasi

2. Pemeliharaan dan upgrade aplikasi basis data-nya (jika diperlukan)

Ketika basis data sepenunya bekerja, pemantauan harus memastikan

kinerjanya dapat berada dalam tingkat yang diterima. Sebuah DBMS biasanya

menyediakan berbagai kegunaan (utilities) untuk membantu administrasi basis

data termasuk kegunaan untuk mengisi data ke dalam basis data dan untuk

30

memantau sistem. Kegunaan ini memperbolehkan sistem pemantauan untuk

memberikan informasi seperti tentang pemakaian basis data dan strategi eksekusi

query. Database administrasi dapat menggunakan informasi ini untuk

memperbaiki sistem agar dapat memberikan kinerja yang lebih baik.

2.1.8 Conceptual, Logikal, and Physical Database Design

2.1.8.1 Conceptual Database Design

Hal yang pertama dilakukan dalam membuat conceptual design adalah

dengan membuat model sata secara konseptual dari perusahaan yang

bersangkutan. Conceptual database design seluruhnya independent dari

implementasi seperti target DBMS software, program aplikasi, bahasa

pemograman, atau physical consideration lainnya. Data tersebut merupakan

informasi-informasi mengenai perusahaan. Dalam conceptual database design,

data yang ada dikembangkan dengan representasi secara konseptual yang

mencakup mengidenifikasi entity, relationship, dan atribut yang sangat penting

dalam perancangan bisnis tersebut.

Langkah-langkah untuk membuat data model lokal yang konseptual

untuk setiap user view dapat digambarkan sebagai berikut :

1. Identifikasikan tipe-tipe entity

Tujuannya adalah untuk mengidentifikasi dan membuat kelas-kelas dari obyek

yang ada berikut penjelasannya serta menentukan entitas utama yang dibutuhkan.

Salah satu metode untuk mengidentifikasi entity adalah dengan menguji

spesifikasi kebutuhan dari user. Dari spesifikasi ini dapat mengidentifikasikan

noun dan nouns phrases yang disebutkan. Selain itu juga dapat melihat objek

31

utama seperti orang, tempat atau konsep dari ketertarikan diluar noun lainnya

yang merupakan kualitas dari objek lain.

Misalkan :

• Staff, yang menggambarkan tingkatan staff yang ada.

• PropertyForRent, menggambarkan semua properti yang disewakan.

2. Identifikasikan tipe-tipe relationship

Tujuannya adalah untuk mengidentifikasi hubungan-hubungan yang ada antara

entitas yang telah diidentifikasikan. Dalam mengidentifikasi tipe relasi yang ada

dengan menggunakan Entity Relationship Diagram (ERD), mencari batasan dari

tipe relationship, memeriksa fan dan chasm traps, memeriksa masing-masing

entity ikut serta setidaknya dalam satu relationship, dan dokumentasikan tipe

relationship.

Misalkan :

• Staff Manages PropertyForRent, yaitu entitas staff mengatur entitas properti.

• PropertyForRent AssociatedWith Lease, yaitu entitas properti yang

disewakan bekerjasama dengan entitas leasing.

3. Identifikasi dan hubungkan atribut-atribut dengan tipe entity atau

relationship

Tujuannya adalah untuk mengidentifikasikan dan menghubungkan atribut-tribut

yang berkaitan dengan entitas atau tipe relationship yang telah sesuai.

4. Tetapkan domain atribut

Tujuannya adalah untuk menetapkan domain untuk tiap-tiap atribut dalam model

data konseptual local dan mendokumentasikan setiap detail dari domain. Suatu

32

domain adalah suatu kelompok nilai yang dari mana satu atau lebih atribut

mengambil nilainya.

Misalkan :

• Domain atribut untuk nilai staffNo yang valid harus huruf dan 3 digit

berikutnya berupa angka yang berkisar antara 1-999

• Nilai yang mungkin untuk atribut gender dari entity staff misalnya huruf M

untuk mewakilkan Man, dan huruf F untuk mewakilkan Female

5. Tetapkan atribut Primary dan Candidate key

Tujuannya adalah untuk menentukan candidate key dan primary key dari

kumpulan atribut-atribut yang telah ditentukan pada tiap entitas. Candidate key

adalah satu atau lebih atribut dari suatu entitas yang dapat dijadikan primary key.

Primary key adalah satu atribut dari suatu entitas yang dipakai sebagai ciri yang

paling unik dari entitas tersebut.

6. Mempertimbangkan kegunaan dari konsep Enhanced Modeling (optional)

Tujuannya adalah untuk mengembangkan ER model dengan menggunakan

konsep enhanced modeling, seperti spesialisasi, generalisasi, penggabungan

(aggregation), komposisi (composition).

7. Periksa model untuk redudansi

Tujuannya adalah untuk memeriksa konsep model data apakah masih

mengandung data maupun entitas serta atribut yang berulang atau tidak. Hal

pertama yang dilakukan adalah memeriksa kembali hubungan-hubungan yang

ada apabila terdapat suatu hubungan yang mirip.

8. Validasi model konseptual lokal terhadap transaksi user

33

Tujuannya untuk memastikan model konseptual lokal mendukung transaksi yang

dibutuhkan oleh view. Diuji dua pendekatan untuk memastikan model data

konseptual lokal mendukung transaksi yang dibutuhkan, dengan cara:

• Mendeskripsikan transaksi-transaksi

Memeriksa seluruh informasi (entitas, relationship, dan atribut) yang

dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan

mendokumentasikan setiap kebutuhan transaksi.

• Mengunakan jalur-jalur transaksi

Untuk validasi model data terhadap transaksi yang dibutuhkan termasuk

representasi diagram jalur yang digunakan oleh setiap transaksi langsung

pada ER diagram.

9. Review model data konseptual dengan user

Tujuannya untuk mengkaji ulang model data konseptual lokal dengan user untuk

memastikan model tersebut adalah representasi sebenarnya dari view. Model data

konseptual ini termasuk ER diagram dan dokumentasi pendukung yang

mendeskripsikan model data. Bila ada kejanggalan (anomali) dalam model data,

maka harus dibuat perubahan yang sesuai yang mungkin membutuhkan

pengulangan langkah-langkah sebelumnya.

2.1.8.2 Logikal Database Design

Logikal design merupakan proses pembuatan model data dengan

menggunakan informasi yang diperoleh dari perusahaan serta berdasarkan pada

model data spesifik. Model data yang telah diperoleh dalam conceptual database

34

design diubah dalam bentuk logikal model dimana data yang ada dipengaruhi

oleh model data yang menjadi tujuan database.

Hal ini dilakukan untuk menerjemahkan representasi konseptual ke dalam

bentuk struktur logic dalam database yang akan dijadikan sumber informasi

dalam merancang physical database design serta memberikan sarana yang

membantu para perancang database dalam merancang physical database.

Hasil akhir dari logikal database design ini berupa sebuah kamus data

yang berisi atribut-atribut beserta key-nya (primary key, alternate key, dan

foreign key) dan ERD keseluruhan dengan atribut key-nya.

Langkah-langkah untuk membuat logikal database design dapat

digambarkan sebagai berikut :

1. Membuat dan memvalidasikan data model lokal yang logikal untuk setiap

view

Aktivitas pada logical database design langkah pertama adalah membangun

pandangan (view) tertentu dari perusahaan dan kemudian mengesahkan model ini

untuk memastikan strukturnya telah benar atau menggunakan teknik normalisasi.

• Pindahkan fitur-fitur yang tidak kompatibel dengan model relational

(langkah optional)

• Ambil hubungan untuk data model lokal yang logikal

• Validasikan hubungan menggunakan normalisasi

• Validasikan hubungan terhadap transaksi user

• Tentukan batasan integrity

• Tinjau kembali model data logikal lokal dengan user

35

2. Membuat dan memvalidasikan model data logikal global

Aktivitas pada logical database design langkah kedua adalah untuk

mengkombinasikan model data logikal lokal individual ke dalam sebuah model

data logikal global tunggal yang menggambarkan perusahaan.

• Gabungkan model data logikal lokal menjadi model global

• Validasikan model data logikal global

• Periksa untuk pengembangan mendatang

• Tinjau kembali model data logikal global dengan user

2.1.8.3 Physical Design

Physical design merupakan proses pembuatan deskripsi dari suatu

impelmentasi basis data pada secondary storge. Hal ini mendeskripsikan base

relation, organisasi file, dan indeks yang digunakan untuk mencapai efisiensi

akses kedalam data, dan associated integrity constraints yang lainnya dan

security measures. Physical database design merupakan fase ketiga dan terakhir

dalam desain database. Tujuan utama dari physical databse design adalah untuk

mendeskripsikan bagaimana desainer bermaksud untuk mengimplementasikan

secara fisik dari logikal database design.

Langkah-langkah dalam pembuatan physical databse design adalah

sebagai berikut :

1. Terjemahkan model data logikal global target DBMS

• Desain hubungan dasar

• Desain representasi dari data yang dihasilkan

36

• Desain batasan-batasan perusahaan

2. Desain reprensentasi fisikal

• Analisa transaksi-transaksi

• Pilih organisasi file

• Pilih indeks-indeks

• Perkirakan kebutuhan tempat penyimpanan

3. Desain user view

4. Desain mekanisme keamanan

5. Pertimbangkan pengenalan dari redundansi terkontrol

6. Awasi dan atur sistem operasional

2.1.9 Document Flowchart

Menurut Romney Steinbart (2003, p165) Document Flowchart mengilustrasikan

aliran dari dokumen-dokumen dan informasi diantara area-area tanggung jawab

didalam sebuah organisasi.

Menurut Mulyadi (2001, p66) bagan alir dokumen (Document Flowchart) adalah

bagan yang menggambarkan aliran dokumen dalam suatu sistem informasi.

Berikut simbol-simbol yang digunakan dengan maknanya masing-masing

(Mulyadi,2001,p60-63)

• Dokumen

Simbol imi digunakan untuk menggambarkan semua jenis dokumen, yang merupakan

formulir yang digunakan untuk merekam data terjadinya suatu transaksi. Nama

dokumen dicantumkan di tengah simbol.

37

Simbol :

Contoh :

• Dokumen dan tembusannya

Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor

lembar dokumen dicantumkan di sudut kanan atas.

Simbol :

Contoh:

• Kegiatan Manual

Simbol ini digunakan untuk menggambarkan kegiatan manual, seperti menerima order

dari pembeli, mengisi formulir. Uraian singkat kegiatan manual dicantumkan di dalam

simbol ini.

Simbol :

Contoh:

38

• Catatan

Simbol ini digunakan untuk menggambarkan catatan yang digunakan untuk mencatat

data yang direkam sebelumnya di dalam dokumen atau formulir. Nama catatan

dicantumkan di dalam simbol ini

Simbol :

Contoh:

• Penghubung pada halaman yang sama (on page connector)

Dalam menggambarkan diagram alir, arus dokumen dibuat mengalir dari atas ke

bawah dan dari kiri ke kanan. Karena keterbatasan ruang halaman kertas untuk

menggambar, maka diperlukan simbol penghubung untuk memungkinkna aliran

dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi

lain pada halaman yang sama. Dengan memperhatikan nomor yang tercantum di dalam

simbol penghubung pada halaman yang sama, dapat diketahui aliran dokumen dalam

sistem yang digambarkan dalam bagan alir.

Simbol :

• Arsip permanen

Simbol ini digunakan untuk menggambarkan arsip permanen yang merupakan tempat

penyimpanan dokumen yang tidak akan diproses lagi dalam sistem yang bersangkutan.

39

Untuk menunjukkan urutan pengarsipan dokumen digunakan simbol sebagai berikut

ini :

A = menurut abjad

N = menurut nomor urut

T = kronologis, menurut tanggal

Simbol :

Contoh :

N

• Keying (typing, verifying)

Simbol ini digunakan untuk menggambarkan pemasukkan data ke dalam komputer

melalui online terminal

Simbol :

Contoh :

• Keputusan

Simbol ini digunakan untuk menggambarkan keputusan yang harus dibuat dalam

proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol.

Simbol :

40

Contoh :

• Garis Alir (flowline)

Simbol ini menggambarkan arah proses pengolahan data.

Simbol :

• Mulai / berakhir (terminal)

Simbol ini menggambarkan awal dan akhir suatu sistem

Simbol :

Contoh :

2.1.10 State Transition Diagram

State Transition Diagram (STD) adalah sebuah modeling tool yang

menggambarkan ketergantungan waktu pada sistem real time dan human interface

pada sistem online.

Notasi yang paling penting dari STD adalah :

1. State

Merupakan kumpulan keadaan atau atribut-atribut yang mencirikan benda atau

orang pada waktu, keadaan dan kondisi tertentu.

41

Notasi State

2. Transition (Perubahan) State

Perubahan state ditandakan dengan tanda panah.

Kondisi

Aksi

Ada 2 hal yang perlu ditambahkan untuk melengkapi STD, yaitu :

1. Kondisi adalah keadaan lingkungan luar yang dapat dideteksi oleh sistem

dan menyebabkan perubahan state. Kondisi dapat berupa sinyal,

interrupt dan lainnya

2. Aksi adalah apa yang dilakukan sistem jika ada perubahan state. Aksi dapat

menghasilkan keluaran, tampilan pesan pada layar pengguna, membuat

kalkulasi, dan lainnya.

2.2 Teori - Teori Khusus

2.2.1 Pembelian

Menurut Mulyadi (2001, p301), pembelian adalah suatu usaha yang

digunakan oleh perusahaan untuk pengadaan barang yang diperlukan oleh

perusahaan.

Menurut Mulyadi (2001, p301), fungsi yang terkait dengan pembelian

adalah:

42

1. Fungsi Gudang

Dalam sistem pembelian, fungsi gudang bertanggung jawab untuk mengajukan

permintaan pembeluian sesuai dengan posisi persediaan yang ada di gudang dan

untuk menyimpan barang yang telah diterima oleh bagian penerimaan. Untuk

barang-barang yang langsung pakai, permintaan pembelian diajukan oleh

pemakai barang.

2. Fungsi Pembelian

Dalam sistem pembelian, 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

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. Selain itu juga

bertanggung jawab untuk menerima barang dari pembeli yang berasal dari

transaksi retur penjualan.

4. Fungsi Akuntansi

Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat

ulang dan fungsi pencatat persediaan. Dalam sistem akuntansi pembelian,fungsi

pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam

register bukti kas keluar dan puntuk menyelenggarakan arsip dokumen sumber.

Dalam sistem akuntansi pembelian, fungsi pencatat persediaan bertanggung

43

jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu

persediaan.

2.2.2 Persediaan

Persediaan pada perusahaan dagang disebut persediaan barang dagangan

atau kadang-kadang disingkat persediaan, yang terdiri atas barang-barang yang

disediakan untuk dijual kepada padra konsumen selama periode normal kegiatan

perusahaan.

Beberapa istilah inventori yang sering digunakan menurut Sugiono

adalah

1. Stok Card (Kartu Stok)

Stok Card adalah catatan stok harian dimana masukan berupa jumlah barang

dengan sistem pembelian merupakan penambahan terhadap stok barang

sedangkan dari sistem penjualan merupakan pengurangan. Setiap hari catatan

stok perlu diperbaharui, meski secara sistem dapat dilakukan kapan saja. Jadi bila

terjadi transaksi, stok card perlu dibuat.

2. Stok Opname

Stok Opname adalah pemeriksaan stok fisik yang tersedia (di gudang) dan

membandingkannya dengan stok yang tercantum (pada komputer). Biasanya

dilakukan pada periode tertentu misalnya sebulan sekali, 6 bulan sekali bahkan

ada yang setahun sekali. Pemeriksaan ini tergantung pada banyaknya jenis

barang. Bila terlalu banyak maka bisa memerlukan waktu yang cukup lama. Di

sebuah swalayan besar bisa membutuhkan waktu 1 hari hingga mereka terpaksa

mnutup outletnya selama stock opname berlangsung. Berdasarkan hasil

44

perbandingan stok fisik denagn stok yang tercatat, apabila terdapat selisih antara

stok fisik dengan stok yang tercatat maka akan dilakukan adjustment stok,

dimana jika terdapat kekurangan pada stok fisik, maka kekurangan akan menjadi

biaya. Setelah pencatatan rampung semuanya, sistem stok berperan kembali

untuk memperbaharui catatan stok akhir pada tabel barang.

3. Adjustment Stok

Setelah dilakukan stock opname, bila ada barang yang rusak, hilang dan

sebagainya, maka akan dilakukan penyesuaian terhadap stok fisik yang tercatat.