bab 2 landasan teori 2.1 pendekatan...

8

BAB 2

Landasan Teori

2.1 Pendekatan BasisData

Penggunaan basisdata yang tradisioanal adalah File-Based System. Setiap

program yang menggunakan File-Based System akan mendefinisikan dan mengontrol

masing-masing data program itu sendiri. Tetapi aplikasi File-Based System mempunyai

banyak kelemahan,contohnya :

Data terpisah-pisah

Data yang terisolasi pada file berbeda mengakibatkan semakin sulitnya

pengaksesan terhadap data tersebut.

Duplikasi data

Karena setiap programmer membuat file dan aplikasi dalam jangka waktu yang

lama, variasi file memiliki format yang berbeda dan kemungkinan program tersebut

ditulis oleh bahasa program yang berbeda-beda. Oleh Karena itu, kemungkianan

informasi yang sama dapat berbeda pada beberapa file

Ketergantungan Data

Struktur fisik dari file data dan record didefinisikan pada kode aplikasi. Hal ini

mengakibatkan pengubahan dari struktur yang telah ada menjadi sulit dilakukan.

Format data yang tidak kompatibel

Karena struktur file tersimpan pada program aplikasi, struktur tersebut

menjadi tergantung pada bahasa pemrograman yang digunakan.

Fixed query

File-Based System menawarkan system yang lebih baik, tetapi seiring dengan

perkembangan akan muncul permintaan-permintaan query baru. Hal ini

9

membutuhkan pembuatan program tambahan untuk menjalankan query tersebut.

Hal ini membutuhka waktu yang lama dan tamahan biaya sehingga dapat

menurunkan efektifitas dari system.

Dengan adanya kekurangan dari File-Based System, maka dibuatlah sisem

basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi

kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan

Database Management System (DBMS).

2.1.1 Pengertian BasisData

Menurut Gerard V. Post (2005,p2) basisdata adalah koleksi penyimpanan data

berdasarkan standar format yang dirancang agar bisa digunakan bersama-sama oleh user

yang berbeda-beda.

Menurut Ramakrishman (3005, p4) basisdata adalah koleksi data, yang bertipikal

penjelasan aktivitas dari satu atau lebih relasi organisasi.

Menurut Atzeni, dkk (2003, p2) basisdata adalah koleksi data, yang digunakan

untk merepresentasikan informasi yang menarik ke dalam sistem informasi.

Maka dari itu, kami menyimpulkan bahwa basisdata adalah koleksi data yang

bertipikal aktivitas dari satu atau lebih relasi organisasi yang dirancang agar bisa

digunakan bersama-sama dan disimpan untuk kepentingan organisasi atau perusahaan.

2.1.2 Database Management System (DBMS)

DBMS (Basisdata Management System) menurut Hofer (2005, p7) adalah sistem

yang digunakan untuk membuat, merawat dan menyediakan control akses untuk

10

pengguna basisdata. DBMS menyediakan metode sistematik untuk pembuatan, updating,

penyimpanan dan penerimaan data pada basisdata. DBMS juga menyediakan fasilitas

untuk mengontrol akses data, menguatkan integritas data, mengatur control konkurensi,

dan menyimpan basisdata.

DBMS menurut Gererd V. Post ( 2005, p2) adalah yang menjelaskan basisdata,

penyimpanan data, mendukung bahasa query, memproduksi laporan, dan membuat layer

data entry.

DBMS menurut Atzeni dkk (2003, p3) adalah sistem piranti lunak yang

memungkinkan untuk mengatur koleksi data yang banyak, berbagi dan persisten serta

untuk memastikan reliabilitas dan privacy mereka. Seperti produk yang lainnya, DBMS

harus efisien dan efektif. Basisdata adalah koleksi data yang diatur oleh DBMS.

DBMS menurut Connolly (2005, p17) adalah suatu sistem piranti lunak yang

memungkinkan user untk mendefinisikan, membuat, merawat, dan mengontrol akses ke

dalam basisdata.

2.1.3 Data Definition Language (DDL)

Definisi dari Data Definition Language menurut Connolly (2005, p40) adalah

suatu bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk

mendeskripsikan nama dari suatu entity, atribut, dan relationship data yang diminta oleh

aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya.

11

2.1.4 Database Manipulation Language (DML)

DML menurut Gerard V. Post (2005, p146) adalah sebuah rangkaian dari

perintah-perintah yang digunakan untuk mengakses data. Contohnya Command Insert,

Delete, dan Update.

DML menurut Connolly (2005, p40) adalah suatu bahasa yang memberikan

fasilitas pengoperasian data yang ada di dalam basis data. Pengoperasian data yang akan

dimanipulasi biasanya meliputi:

1. Penambahan data baru ke dalam basisdata.

2. Modifikasi data yang disimpan ke dalam basisdata.

3. Pengambilan data yang terdapat di dalam basisdata.

Sedangkan definisi Procedural DML menurut Connolly (2005, p41) adalah suatu

bahasa yang memperbolehkan user untuk mendeskripsikan ke sistem data apa yang

dibutuhkan dan bagaimana mendapatkan data tersebut secara persis.

2.1.5 4GL

Fourth-Generalazatin Languages atau 4th GLs menurut Connolly (2005,p42)

adalah generasi bahasa tingkat empat. Tidak ada konsensus tentang apa itu 4th GLs,

ditunjukkan untuk bahasa pemrograman yang sederhana suatu operasi yang

membutuhkan banyak baris dalam bahasa generasi tingkat tiga (3th GLs), seperti

COBOL, biasanya membutuhkan hanya 10-20 baris 4th GLs. Dibandingkan dengan 3 th

GLs, yang membutuhkan produser,pada 4th GLs tidak diperlukan lagi dan pengguna bisa

menentukan apa saja yang harus dilakukan.

4th GLs diharapkan dapat memudahkan penggunanya pada tingkat komponen

yang lebih tinggi seperti tools generasi ke-4. Para pengguna tidak mengharapkan untuk

12

mendefinisikan langkah suatu program untuk melaksanakan suatu tugas, tetapi lebih

mendefinisikan parameter untuk tools yang mana untuk menciptakan suatu program

aplikasi. 4th GLs diyakini dapat mengembangkan produktivitas dalam batasan jenis

masalah yang bisa diatasi oelh 4th GLs:

- Presentasi bahasa, seperti query language and report generator

- Bahasa khusus, seperti spreadsheets dan basisdata language

- Aplikasi generator yang dapat mendefinikan, menyisipkan, memperbaharui, dan

membuka kembali data dari suatu basis data untuk membuat aplikasi.

2.1.6 Database Life Cycle

Sistem informasi berbasis computer terdiri dari sebuah database, piranti lunak

database, piranti lunak aplikasi, perangkat keras komputer dan pemakanian perseorangan

dan perkembangan sistem. Komponen terpenting dari sistem informasi adalah database.

Pemakian dan perkembangan dari database harus memenuhi kebutuhan tersebar dari

perusahaan.

Tingkat dari information system lifecycle atau software development lifecycle

(SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan pembuatan prototype,

implementasi, konversi dan operasi pemeliharaan. Tingkatan dari database application

lifecycle memiliki bentuk yang tidak kaku, tetapi mengikuti bentuk dari bentuk semula

yaitu feedback loops.

Untuk aplikasi database kecil, dengan jumlah pemakai yang kecil, siklus hidup

yang diperlukan tidak terlalu kompleks. Meskipun begitu, ketika merancang database

aplikasi menengah ke atas dengan jumlah pemakai dari 10 hingga 1000, menggunakan

ratusan query dan program aplikasi, sisklus hidup dapat menjadi komplek.

13

Gambar 2.1

Tingkatan dari Database System Development Lifecycle

( Sumber : Connolly dan Begg , 2005 , p284 )

2.1.6.1 Database Planning

Adalah aktifitas manajemen yang memungkinkan setiap tahapan dalam

Database System Development Lifecycle untuk direalisasikan seefisien dan

seefektif mungkin. Database Planning seharusnya diintegrasikan dengan

14

keseluruhan strategi Information System dari organisasi. Ada 3 persoalan utama

dalam menyusun strategi IS, antara lain :

1. Identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara

subsequent dari kebutuhan sistem informasi.

2. Mengevaluasi sistem informasi yang ada untuk mendefinisikan kekuatan dan

kelemahan.

3. Penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing.

2.1.6.2 Sistem Definition

Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi

basisdata dan user view utama. User view mendeskripsikan apa yang dibutuhkan

dari sebuah basisdata dari sudut pandang peran pekerja (seperti manager atau

supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau

kontrol stok).

2.1.6.3 Requirements Collection and Analysis

Suatu proses yang mengumpulkan dan menganalisis informasi mengenai

bagian dari organisasi yang didukung oleh aplikasi basisdata dan penggunaan

informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru.

Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang

dinamakan teknik fact-finding.

Menurut Connolly dan Begg ( 2005, p317), terdapat lima teknik fact -

finding yang umum digunakan:

15

• Mengevaluasi dokumentasi.

• Interview.

• Observasi.

• Research.

• Questioner.

2.1.6.4 Database Design

Menurut Connolly dan Begg ( 2005 , p291 ), Database design adalah

suatu proses yang membuat suatu rancangan untuk basisdata yang akan

mendukung kegiatan operasional dan tujuan dari perusahaan.

Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical

1. Conceptual database design

Pada tahap konseptual ini bertujuan untuk membuat representasi

konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut.

Pada tahap ini dibagi menjadi beberapa langkah, yaitu:

Langkah 1. Membangun conceptual data model

Langkah 1.1 Identifikasikan Tipe Entitas

Langkah 1.2 Identifikasikan Tipe Relationship

Langkah 1.3 Identifikasikan dan Asosiasikan Atribut dengan Tipe

Entitas dan Tipe Relationship

Langkah 1.4 Menentukan Domain Atribut

Langkah 1.5 Penentuan Atribut Candidate key, Primary Key, dan

Alternate Key

16

Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling

concept (optional)

Langkah 1.7 Memeriksa model dari redundancy

Langkah 1.8 Validasi Model Konseptual dengan user transaction

Langkah 1.9 Meninjau local conceptual data model dengan pengguna

2. Logical database design

Pada tahap ini memetakan model konseptual ke model logikal yang

dipengaruhi oleh model data yang menjadi tujuan dari basisdata. Dalam

perancangan model logikal, model data yang telah diperoleh dalam basisdata

konseptual diubah dalam bentuk dimana data yang ada dipengaruhi oleh model

data yang menjadi tujuan basisdata (contoh : relational model). Hal ini dilakukan

untuk menerjemahkan representasi konseptual kedalam bentuk struktur logik

dalam basisdata. Model data logikal merupakan sumber informasi dalam

merancang basisdata fisikal. Perancangan basisdata logikal memberikan sarana

yang membantu para perancang dalam merancang basisdata fisikal. Pada tahap

ini dibagi menjadi beberapa langkah, yaitu :

Langkah 2. Membangun dan memvalidasi logical data model

Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal

Langkah 2.2 Validasi Model dengan Normalisasi

Langkah 2.3 Memvalidasi Relasi dengan User Transaction

Langkah 2.4 Mendefinisikan Kendala Integrity

Langkah 2.5 Me-review logical data model dengan User

17

Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global

Model (optional)

Langkah 2.7 Memeriksa untuk perkembangan lebih lanjut

3. Physical database design

Tahap physical datanbase design memungkinkan perancang basisdata

untuk membuat keputusan mengenai bagaimana basisdata akan

diimplementasikan. Oleh karena itu, physical databse design harus disesuaikan

dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah,

yaitu :

Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih

Langkah 3.1 Merancang relasi – relasi dasar

Langkah 3.2 Merancang representasi untuk data Turunan

Langkah 3.3 Merancang general constraint

Langkah 4. Merancang file organization dan indexes

Langkah 4.1 Menganalisa transaksi

Langkah 4.2 Memilih organisasi file

Langkah 4.3 Memillih index – index

Langkah 4.4 Memperkirakan kebutuhan disk space

Langkah 5. Merancang user view

Langkah 6. Merancang mekanisme keamanan

Langkah 7. Mempertimbangkan pengenalan redudancy control

Langkah 8. Mengawasi dan mengendalikan sistem operasional

18

2.1.6.5 DBMS Selection

Pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan

aplikasi basisdata. Menurut Connolly dan Begg ( 2005, p295 ), berikut ini adalah

langkah –langkah dalam memilih DBMS :

1. Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan

2. Membuat perbandingan mengenai 2 atau 3 produk DBMS

3. Mengevaluasi produk-produk DBMS tersebut

4. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari

evaluasi produk DBMS tersebut.

Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut :

1. Mengijinkan pengguna untuk menentukan basisdata, biasanya melalui

Data Definition Language (DDL). DDL mengijinkan pengguna untuk

menspesifikasikan tipe data, struktur dan batasan-batasan data yang bisa

disimpan di basisdata.

2. Mengijikan pengguna untuk insert, update, delete atau retrive data dari

basisdata, biasanya melalui Data Manipulation Language(DML).

3. DBMS menyediakan akses kontrol ke basisdata. Sebagai contohnya

DBMS menyediakan :

a. Security system, dimana mencegah autorisasi pengguna untuk

mengakses basisdata.

b. Integrity system, dimana menangani konsistensi penyimpanan data.

c. Concurrency control system, dimana mengijinkan basisdata untuk

diakses secara share.

19

d. Recovery control system, dimana basisdata bisa di-restore pada saat

terjadi kesalahan pada hardware maupun software.

e. User-accesable catalog, dimana berisi deskripsi data dalam basisdata.

2.1.6.6 Application Design

Menurut Connolly dan Begg ( 2005 , p299 ), Rancangan aplikasi adalah

rancangan dari user interface dan program aplikasi yang digunakan dan

memproses basisdata. Dalam kebanyakan kasus tidak mungkin dapat

menyelesaikan aplication design sebelum menyelesaikan database design itu

sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada

banyak aliran infomasi anatar application design dan database design.

2.1.6.7 Prototyping (Optional)

Pada kondisi tertentu kita dapat memilih apakah akan membuat prototype

atau langsung mengimplementasikan basisdata. Suatu prototype adalah suatu

model aplikasi basisdata yang mempunyai semua corak yang diperlukan dan

menyediakan semua kemampuan sistem. Tujuan utama prototype itu untuk

menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan

karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan

pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem

tersebut.

Menurut Connolly dan Begg ( 2005, p303 ), ada dua cara strategi

membuat prototype yaitu requirements prototyping dan evolutioner prototyping.

Untuk requirements prototyping digunakan prototype untuk menentukan

20

kebutuhan suatu aplikasi basisdata yang diusulkan dan ketika kebutuhan

dirasakan sudah lengkap maka prototype tersebut tidak lagi digunakan. Protype

evolutioner digunakan untuk tujuan yang sama, perbedaannya adalah bahwa

prototype tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi

aplikasi basisdata tersebut.

2.1.6.8 Implementasi

Menurut Connolly dan Begg ( 2005, p304 ), implementasi merupakan

perwujudan fisik dari basisdata dan desain aplikasi. Setelah menyelesaikan tahap

desain (dengan atau tanpa prototype), selanjutnya pada tahap implementasi

basisdata dan program aplikasi. Implementasi basisdata dicapai dengan

menggunakan Data Definition Language (DDL) dari DBMS yang telah dipilih

atau dengan menggunakan Graphical User Interface (GUI), masing - masing

meyediakan fungsi ketika menyembunyikan pernyataan (statement) DDL yang

low - level. Pernyataan DDL digunakan untuk menciptakan struktur basisdata

dan mengosongkan file yang terdapat dalam basisdata tersebut. User view juga

diterapkan dalam langkah implementasi.

Program aplikasi diterapkan dengan menggunakan bahasa generasi

keempat atau ketiga (4GL atau 3GL). Bagian dari program aplikasi ini adalah

transaksi basisdata yang diterapkan menggunakan Data Manipulation Language

(DML). Transaksi basisdata juga dapat dibuat dalam bahasa pemrograman

seperti Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada, atau Pascal.

Juga dapat diterapkan komponen lain dari desain aplikasi seperti layar menu,

format masukan data, dan laporan.

21

Pengendalian keamanan dan integritas untuk aplikasi juga

diimplementasikan. Sebagian dari kendali ini telah diterapkan dengan

menggunakan DDL, tetapi yang lain mungkin perlu digambarkan diluar DDL.

Sebagai contoh, kegunaan yang disediakan DBMS atau kendali sistem operasi.

2.1.6.9 Data Convertion dan Loading

Menurut Connolly dan Begg ( 2005, p305 ), pemindahan data yang ada

ke basisdata yang baru dan mengubah aplikasi yang sedang berjalan agar dapat

digunakan dalam basisdata yang baru.

2.1.6.10 Testing

Menurut Connolly dan Begg ( 2005, p305 ), Testing adalah suatu proses

yang melaksanakan proses aplikasi dengan tujuan menemukan kesalahan.

Dalam melakukan testing, para pengguna baru harus dilibatkan untuk menguji

proses aplikasi dan basisdata tersebut. Situasi yang ideal untuk pengujian sistem

adalah mempunyai suatu tes basisdata pada suatu sistem perangakat keras, tetapi

ini sering tidak tersedia. Jika data real yang diharapkan untuk digunakan, maka

adalah penting untuk mempunyai backup. Setelah pengujian diselesaikan, maka

sistem aplikasi dan basisdata ini telah siap digunakan.

2.1.6.11 Operational Maintenance

Menurut Connolly dan Begg ( 2005, p306 ), setelah melalui tahapan-tahapan

sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang

melibatkan aktivitas berikut :

22

1. Monitoring performance dari sistem. Jika performansi berada disuatu

tingkatan yang bisa diterima, penyetelan atau menyusun kembali basisdata

mungkin diperlukan.

2. Memelihara dan meningkatkan mutu aplikasi basisdata. Kebutuhan baru

disatukan kedalam aplikasi basisdata dengan mengikuti langkah – langkah

sebelumnya yang terdapat dalam database lifecycle.

Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring

secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat

diterima.

Monitoring proses akan terus berlanjut sepanjang seluruh hidup suatu

aplikasi basisdata tersebut dan pada waktu tertentu boleh melakukan menyusun

kembali basisdata untuk mencukupi kebutuhan dari sistem. Perubahan ini

meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan

datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam

perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan

penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat

mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika

tersedia.

2.1.7 Tahap-Tahap Perancangan BasisData

Dalam merancang suatu basisdata melalui beberapa tahapan, sebagai berikut :

• Perancanagan Basisdata Konseptual

• Perancanagan Basisdata Logikal

23

• Perancanagan Basisdata Fisikal

2.1.7.1 Perancangan Basisdata Konseptual

Menurut Connolly dan Begg ( 2005 , p439 ), perancangan konseptual

basisdata adalah proses pembangunan model data yang digunakan di perusahaan,

yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk

membangun representasi konseptual basisdata, yang meliputi identifikasi dari

entitas - entitas, relationship - relationship, dan atribut - atribut yang penting.

Menurut Connolly dan Begg ( 2005 , p443 ), langkah - langkah perancangan

konseptual basisdata yaitu :

Langkah 1. Membangun Conceptual Data Model

Menurut Connolly dan Begg ( 2005 , p442 ), tujuannya adalah untuk

membangun local conceptual data model dari perusahaan untuk tiap view yang

spesifik. Tiap local conceptual data model terdiri dari entity type, relation type,

atribut - atribut, domain – domain atribut, primary key, alternate key, dan

integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 :

Langkah 1.1 Identifikasikan Tipe Entitas

Menurut Connolly dan Begg ( 2005, p443 ), tujuannya adalah

mengidentifikasikan tipe – tipe entitas utama yang dibutuhkan oleh view.

Langkah 1.2 Identifikasikan Tipe Relationship

Menurut Connolly dan Begg ( 2005 , p445 ), tujuannya adalah

mengidentifikasikan relationship – relationship penting yang ada diantara tipe –

tipe entitas yang telah diidentifikasi.

24

Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas

dan Tipe Relationship


menghubungkan atribut – atribut dengan entitas atau relationship type yang

sesuai.

Langkah 1.4 Menentukan Domain Atribut


menentukan domain – domain untuk atribut – atribut dalam local conceptual

data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk

satu atau lebih atribut. Domain merupakan fitur yang sangat kuat dalam model

relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain

mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin

ditetapkan dalam domain yang sama.

Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate

Key


mengidentifikasikan candidate – candidate key untuk tiap tipe entitas dan, jika

terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan

primary key.

Menurut Connolly dan Begg ( 2005 , p451 ), ketika memilih primary key

diantara candidate key, kita dapat menggunakan panduan berikut untuk

membantu pemilihan primary key, yaitu :

- Candidate key dengan kumpulan atribut yang minimal

- Candidate key yang nilainya jarang berubah

25

- Candidate key dengan karakter – karakter yang paling sedikit (untuk yang

memiliki textual attributes)

- Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki

numerical attributes)

- Candidate key yang paling mudah digunakan dari sudut pandang user

Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept

(optional)


mempertimbangkan penggunaan enhanced modeling concepts, seperti

specialization / generalization, aggregation, dan composition.

Langkah 1.7 Memeriksa model dari redundancy


memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam

langkah ini adalah : memeriksa kembali one-to-one relationship dan

menghilangkan redundant relationships.

Langkah 1.8 Validasi Model Konseptual dengan User Transaction


menjamin bahwa model konseptual mendukung transaksi – transaksi yang

dibutuhkan oleh view.

Langkah 1.9 Meninjau local conceptual data model dengan pengguna


meninjau local conceptual data model dengan user untuk menjamin bahwa

model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan

oleh perusahaan.

26

Supervisor

Staff

staffNo {PK}name fName lNamepositionsexDOB

Owner

ownerNo {PK}addresstelNo

PropertyForRent

propertyNo {PK}address street city postcodetyperoomsrent

Client

clientNo {PK}name fName lNametelNo

viewDatecomment

Preference

prefTypemaxRent

PrivateOwner

name fName lName

BusinessOwner

bNamebTypecontactName

Lease

leaseNo {PK}paymentMethoddepositPaidrentStartrentFinish/deposit/duration

{Optional}Supervises

Registers

1 .. 1

0 .. 10

1 .. 1

0 .. *0 .. 1

0 .. 100Manages

0 .. * 0 .. *

Views

1 .. *

1 .. 1

Owns

AssociatedWith

1 .. 1

0 .. *

1 .. 1

0 .. *

1 .. 1

1 .. 1

Holds States

{Mandatory, Or}

Gambar 2.2 ERD Conseptual


2.1.7.2 Perancangan Basisdata Logikal

Menurut Connolly dan Begg ( 2005 , p439 ), perancangan logikal

basisdata adalah suatu proses pembangunan model data yang digunakan dalam

perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada

27

particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk

menerjemahkan representasi konseptual ke struktur logikal dari basisdata yang

meliputi perancangan relasi – relasi.

Menurut Connolly dan Begg ( 2005 , p462 ), langkah – langkah

perancangan basisdata logikal yaitu :

Langkah 2. Membangun dan memvalidasi logical data model


menerjemahkan logical data model dan kemudian untuk memvalidasi model

tersebut untuk memeriksa model tersebut benar secara struktural dan memiliki

kemampuan untuk mendukung transaksi – transaksi yang dibutuhkan. Tujuan ini

akan tercapai dengan mengikuti langkah – langkah berikut :

Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal


menciptakan relasi – relasi untuk model data logikal untuk merepresentasikan

entitas – entitas, relationship – relationship, dan atribut – atribut yang telah

diidentifikasikan. Relationship yang dapat muncul pada model data konseptual :

● Strong Entity Type dan Weak Entity Type

Menurut Connolly dan Begg ( 2005 , p354 ), strong entity type

adalah tipe entitas yang keberadaannya tidak bergantung (independent)

pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type

adalah tiap entity occurrence dapat diidentifikasi secara unik

menggunakan atribut primary key dari tipe entitas. Strong entity type

sering juga disebut parent atau owner atau dominant entities.

28

Menurut Connolly dan Begg ( 2005 , p355 ), weak entity type

adalah tipe entitas yang keberadaannya bergantung (dependent) pada

beberapa tipe entitas lainnya. Weak entity type juga disebut child,

dependent, atau subordinate entities.

● One-to-many (1:*) binary relationship types

Menurut Connolly dan Begg ( 2005 , p465 ), untuk tiap 1:* binary

relationship, entitas pada ‘one side’ dari relationship dianggap sebagai

entitas parent dan entitas pada ‘many side’ dianggap sebagai entitas child.

Untuk merepresentasikan relationship ini, pasangkan salinan primary key

dari entitas parent ke dalam relation yang merepresentasikan entitas

child, untuk berlaku sebagai foreign key.

● One-to-one (1:1) binary relationsip types

Menurut Connolly dan Begg ( 2005 , p465 ), penciptaan relasi -

relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks

karena cardinality tidak dapat digunakan untuk membantu

mengidentifikasikan entitas - entitas parent dan child dalam relationship.

Sebagai gantinya participation constraint digunakan untuk membantu

memutuskan apakah baik untuk merepresentasikan relationship dengan

menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau

dengan menciptakan dua relasi dengan menyalin salinan dari primary key

dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana

29

menciptakan relasi – relasi untuk merepresentasikan participation

constraint berikut :

- Mandatory participation pada 2 sisi dari 1:1 relationship

- Mandatory participation pada 1 sisi dari 1:1 relationship

- Optional participation pada 2 sisi dari 1:1 relationship

● Mandatory participation pada 2 sisi dari 1:1 relationship

Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita

harus menggabungkan entitas – entitas yang terlibat kedalam satu relasi

dan memilih salah satu dari primary key dari entitas – entitas aslinya

untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya

dijadikan alternate key.

● Mandatory participation pada 1 sisi dari 1:1 relationship

Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita

dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1

relationship menggunakan participation constraint. Entitas yang

mempunyai optional participation dalam relationship dianggap sebagai

entitas parent, dan entitas yang mempunyai mandatory participation

dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan

diatas, salinan primary key dari entitas parent ditempatkan dalam relasi

yang merepresentasikan entitas child. Jika relationship mempunyai satu

atau lebih atribut, atribut ini harus menyertakan penyalinan primary key

ke relasi child.

30

● Optional participation pada 2 sisi dari 1:1 relationship

Menurut Connolly dan Begg ( 2005 , p467 ), kita dapat memilih

primary key mana yang dipilih tergantung dari kasus yang ada.

● One-to-one (1:1) recursive relationship

Menurut Connolly dan Begg ( 2005 , p467 ), untuk 1:1 recursive

relationship, kita mengikuti aturan untuk participation seperti yang

diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan

mandatory participation pada 2 sisi, representasikan recursive

relationship sebagai relasi tunggal dengan 2 salinan primary key.

Sedangkan salah satu salinan dari primary key merepresentasikan foreign

key dan harus diubah namanya untuk menandakan relationship yang

direpresentasikan.

Untuk 1:1 recursive relationship dengan mandatory participation

pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal

dengan 2 salinan primary key atau untuk menciptakan relasi baru untuk

merepresentasikan relationship. Relasi baru hanya akan mempunyai 2

atribut, keduanya merupakan salinan primary key.

Untuk 1:1 recursive relationship dengan optional participation

pada 2 sisi, kita menciptakan relasi baru seperti yang telah diuraikan

diatas.

● Superclass/subclass relationship types

Menurut Connolly dan Begg ( 2005 , p467 ),untuk tiap superclass

atau subclass relationship dalam data model konseptual, kita

31

mengidentifikasikan entitas superclass sebagai entitas parent dan entitas

subclass sebagai entitas child. Terdapat banyak pilihan dalam

merepresentasikan relationship sebagai salah satu atau lebih relasi –

relasi. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti

disjointnese dan participation constraint pada superclass / subclass

relationship apakah subclass – subclass terlibat dalam distinct

relationship dan jumlah participant – participant dalam superclass /

subclass relationship.

● Many-to-many (*:*) binary relationship types

Menurut Connolly dan Begg ( 2005 , p469 ), untuk tiap *:* binary

relationship menciptakan relasi untuk merepresentasikan relationship dan

meliputi atribut – atribut yang menjadi bagian dari relationship. Kita

menyalin salinan primary key dari entitas yang berhubungan dalam

relationship kedalam relasi baru. Untuk berlaku sebagai foreign key.

● Complex relationship types

Menutur Connolly dan Begg ( 2005 , p470 ), untuk setiap complex

relationship menciptakan sebuah relasi untuk merepresentasikan

relationship dan termasuk semua atribut yang merupakan bagian dari

relationship tersebut. Kita menyalin salinan primary key dari entitas yang

berhubungan dalam complex relationship kedalam relasi baru, untuk

berlaku sebagai foreign key.

32

● Multi-valued attributes

Menurut Connolly dan Begg ( 2005 , p471 ), menciptakan relasi

yang merepresentasikan atribut – atribut multi-valued dan menyalin

salinan primary key dari entitas owner kedalam relasi baru untuk menjadi

foreign key.

Langkah 2.2 Validasi Model dengan Normalisasi


memvalidasi relasi – relasi dalam model data konseptual menggunakan teknik

normalisasi.

Menurut Connolly dan Begg ( 2005 , p388 ), normalisasi adalah teknik

untuk menghasilkan sekumpulan relasi – relasi dengan properti – properti yang

diinginkan, sesuai dengan kebutuhan data – data yang diberikan oleh perusahaan.

Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data

(perulangan data) dan update anomalies, menciptakan representasi data,

hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas.

Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar

atas relasi – relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan

karena terjadinya redundansi data atau kejanggalan pengubahan (update

anomaly).

Menurut Connolly dan Begg ( 2005 , p391 ), update anomaly ada tiga

jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly.

Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat

dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity

33

constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel

pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk

menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain

dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi

terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan

terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat

memungkinkan terjadinya inkonsistensi data.

Menurut Connolly dan Begg ( 2005 , p401 ), proses normalisasi meliputi

langkah – langkah utama berikut :

- First Normal Form ( 1NF ), yang menghilangkan repeating groups

- Second Normal Form ( 2NF ), yang menghilangkan partial dependency

dalam primary key

- Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies

dalam primary key

- Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly –

anomaly yang tersisa dari functional dependencies

Langkah 2.3 Mendefinisikan Kendala Integrity

Menurut Connolly dan Begg ( 2005 , p474 ), tujuannya adalah memeriksa

integrity constraint yang direpresentasikan dalam model data logical. Integrity

constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain

constraint, entity integrity, referential integrity, dan general constraint.

34

● Data yang dibutuhkan

Menurut Connolly dan Begg ( 2005 , p475 ), beberapa atribut

harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut

tidak boleh bernilai null.

● Attribute domain constraint

Menurut Connolly dan Begg ( 2005 , p475 ), tiap atribut

mempunyai domain, yaitu kumpulan nilai – nilai yang legal. Misalnya,

ada 2 jenis kelamin yaitu ‘M’ atau ‘F’, jadi domain untuk atribut jenis

kelamin adalah karakter string tunggal yang terdiri dari ‘M; atau ‘F’.

Batasan ini harus diidentifikasikan ketika kita memilih domain atribut

untuk model data.

● Multiplicity

Menurut Connolly dan Begg ( 2005 , p475 ), multiplicity

merepresentasikan batasan yang diletakkan pada relationship antara data

di dalam basisdata.

● Entity integrity

Menurut Connolly dan Begg ( 2005 , p475 ), primary key dari

entitas tidak boleh bernilai null. Batasan ini harus betul – betul

dipertimbangkan ketika kita mengidentifikasikan primary key untuk tiap

tipe entitas.

● Referential integrity

Menurut Connolly dan Begg ( 2005 , p475 ), foreign key

menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent

yang meliputi nilai candidate key yang sesuai. Referential integrity berarti

35

bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk

pada tuple yang ada pada relasi parent.

Menurut Connolly dan Begg ( 2005 , p476 ), terdapat 5 strategi

untuk mempertahankan referential integrity pada saat penghapusan tuple

pada relasi parent, yaitu :

- NO ACTION

Mencegah penghapusan dari relasi parent jika terdapat tuple –

tuple child yang ditunjuk.

- CASCADE

Ketika tuple parent dihapus, secara otomatis juga dihapus tuple –

tuple child yang ditunjuk

- SET NULL

Ketika tuple parent dihapus, nilai foreign key dalam semua tuple –

tuple child yang berhubungan secara otomastis diubah menjadi

null.

- SET DEFAULT

Ketika tuple parent dihapus, nilai foreign key dalam semua tuple –

tuple child yang berhubungan secara otomatis diubah menjadi

nilai default-nya.

- NO CHECK

Ketika tuple parent dihapus, tidak melakukan apa – apa untuk

menjamin referential integrity tetap terjaga.

36

● General constraints

Pengubahan – pengubahan pada entitas – entitas mungkin diatur

oleh batasan – batasan yang memerintah transaksi ’real world’ yang

direpresentasikan oleh pengubahan tersebut

Langkah 2.4 Menggabungkan Logical Data Model ke dalam Global Model

(optional)


merepresentasikan semua user views dari basisdata.

Langkah 2.5 Memeriksa untuk perkembangan lebih lanjut


menentukan apakah terdapat perubahan signifikan pada masa depan yang dapat

diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi

perubahan tersebut.

37

Gambar 2.3 ERD Logical


2.1.7.3 Perancangan Basisdata Fisikal

Menurut Connolly dan Begg ( 2005 , p439 ), perancangan fisik basisdata

adalah proses membuat deskripsi dari implementasi basisdata pada secondary

storage, mendeskripsikan relasi dasar, file organization, dan index yang

digunakan untuk mendapatkan akses efisien pada data dan semua integrity

38

constraint yang berhubungan dan security measures. Tujuannya adalah untuk

memutuskan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar)

secara fisik dalam DBMS yang dipilih.

Menurut Connolly dan Begg ( 2005 , p496 ), langkah – langkah

perancangan fisik basisdata meliputi :

Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih


menghasilkan relational database schema dari data model logikal yang dapat

diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 :

Langkah 3.1 Merancang relasi – relasi dasar


memutuskan bagaimana merepresentasikan relasi – relasi dasar yang

diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk

tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi

yang terdiri dari :

- Nama relasi

- Daftar atribut – atribut sederhana dalam golongan – golongan

- Primary key dan alternate key dan foreign key jika ada

- Referential integrity contraints untuk semua foreign keys yang

diidentifikasikan

Menurut Connolly dan Begg ( 2005 , p498 ), sedangkan dari data dictionary,

dari tiap – tiap atribut kita juga mempunyai :

39

- Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam

domain

- Nilai default optional untuk atribut

- Apakah atribut dapat mempunyai nilai nulls

- Apakah atribut tersebut derived, maka harus dikomputasi

Langkah 3.2 Merancang Representasi untuk Data Turunan


memutuskan bagaimana merepresentasikan semua data derived yang ada dalam

model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari

dengan memeriksa nilai – nilai dari atribut – atribut lainnya disebut derived atau

calculated attribute.

Langkah 3.3 Merancang General Constraint


merancang general constraint untuk DBMS yang dipilih.

Langkah 4. Merancang file organization dan indexes


menentukan file organisasi yang optimal untuk menyimpan relasi – relasi dasar

dan indeks – indeks yang dibutuhkan untuk mencapai performansi yang dapat

diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage.

Terdapat beberapa factor yang dapat digunakan untuk mengukur

efisiensi, yaitu :

40

- Transaction throughput adalah jumlah transaksi yang dapat diproses dalam

jangka waktu tertentu. Diukur pada kondisi peak.

- Response time adalah waktu yang diperlukan untuk menyelesaikan satu

transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin

meminimalkan response time. Response time ini biasanya dipengaruhi waktu

untuk mengakses data yang diperlukan, system load, OS scheduling,

communication delay.

- Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan

file – file basisdata. Para perancang sistem biasanya ingin meminimalkan

disk storage yang digunakan.

Langkah 4.1 Menganalisa Transaksi


mengerti fungsi dari transaksi yang akan diterapkan pada basisdata dan untuk

menganalisa transaksi – transaksi yang penting.

Langkah 5. Merancang mekanisme keamanan


merancang mekanisme keamanan untuk basisdata seperti yang ditentukan oleh

user pada waktu tahap pengumpulan kebutuhan – kebutuhan dari system

development lifecycle. Mekanisme kemanan yang dirancang dalam basisdata

yaitu mekanisme keamanan sistem dan mekanisme keamanan data.

41

Langkah 6. Mempertimbangkan pengenalan redudancy control


menentukan apakah pengenalan redundancy yang dikontrol dengan aturan –

aturan normalisasi akan meningkatkan performansi sistem.

Langkah 7. Mengawasi dan mengendalikan sistem operasional


mengawasi sistem operasional dan meningkatkan performansi dari sistem untuk

memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan

perubahan kebutuhan.

2.1.8 ER Modeling

Terdapat beberpa konsep Model ER yang berupa :

2.1.8.1 Entity Type

Menurut Connolly dan Begg ( 2005, p343) entity type adalah kelompok

objek dengan properties yang sama, yang didefinisikan unutk perusahaan selama

mempunyai keadaan yang independent. Entity type memepuyai kedaan yang

independent dan dapat berupa objek-objek dengan keberadaan fisik atau objek-

objek denga keberadaan konseptual.

2.1.8.2 Entity Occurrence

Menurut Connolly dan Begg (2005, p346) relationship occurrence adalah

penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1

occurrance dari tiap participating entity type

42

2.1.8.3 Atribut

Menurut Connolly dan Begg (2005, p350) atribut adalah property dari

entitas atau relationship type. Atribut domain adalah sekumpulan nilai-nilai yang

diperbolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan

menjadi

a. Simple Atribut yaitu yang terdiri dari satu komponen tunggal dengan

keberadaan yang idependen dan tidak dapat dibagi menjadi bagian yang

lebih kecil lagi

b. Composite Atibut yaitu atribut yang terdiri dari beberpa komponen,

dimana masing-masing komponen memilki keberdaan yang independen

c. Single-valued Atribut yaitu atribut yang mempuyai nilai tunggal untuk

setiap kejadian

d. Multi-valued Atribut yaitu atribut yang mempuyai beberpa nilai untuk

setiap kejadian

e. Derived Atribut yaitu atribut yang memilki nilai yang dihasilakan dari

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

entitas.

2.1.8.4 Key

Menurut Connolly dan Begg ( 2005 , p352 ), candidate key adalah

sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap

occurrence dari entity type.

Menurut Connolly dan Begg ( 2005 , p353 ), primary key adalah key yang dipilih

untuk mengidentifikasikan secara unik tiap occurrence dari entity type.

43

Menurut Connolly dan Begg ( 2005 , p353 ), composite key adalah candidate key

yang terdiri dari dua atau lebih atribut.

Gambar 2.4 ER Diagram

2.1.8.5 Structural constraint

Tipe utama dari constraint dari relationship disebut multiplicity.

Multiplicity adalah jumlah dari kejadian – kejadian yang mungkin dari sebuah

tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang

berhubungan melalui relationship khusus.

Tiga jenis relationship yang digunakan mengikuti enterprise constraint :

• Hubungan one-to-one (1:1)

Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu

dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan

44

member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi

maksimal 1.

Contoh : satu produk hanya memiliki satu bonus dan bonus hanya dimiliki oleh

satu produk. Diasumsikan hanya produk tertentu saja yang mempunyai bonus

dan bonusnya hanya satu.

Gambar 2.5 Hubungan one-to-one (1:1)

• Hubungan one-to-many (1:*)

Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-

banyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau

banyak member dari entitas yang lain dan member dari entitas yang lainnya

berhubungan (bisa dari 0) sampai maksimal 1.

Contoh : seorang kepala sekolah dapat memiliki 1 hingga banyak guru, tetapi

seorang guru hanya memiliki satu dan hanya satu kepala sekolah.

Gambar 2.6 Hubungan one-to-many (1:*)

KepalaSekolah

Guru

1..1 has ► 1..*

Produk

Bonus 1..1 has ► 1..1

45

• Hubungan many-to-many (*:*)

Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyak-

banyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain

dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas

yang berhubungan tersebut.

Contoh : Pembeli dapat memilih 0 hingga banyak produk yang ingin dibeli,

tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu

jenis produk.

Gambar 2.7 Hubungan many-to-many (*:*)

2.1.9 Normalisasi

Tujuan uatama dalam pengembangan model data logical pada sistem

database relational adlah menciptakan representasi akurat suatu data, relationship

anatar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka harus

ditetapkan sekumpulan relasi.

2.1.9.1 Pengetian Normalisasi

Menurut Connolly dan Begg ( 2005 , p401 ), normalisasi adalah teknik

formal untuk menganalisa relasi berdasarkan pada primary key (atau candidate

key) dan functional dependencies.

Pembeli

Produk 0..* Order ► 0..*

◄ OrderedBy

46

2.1.9.2 Tahapan- tahapan Normalisasi

Normalisasi memiliki Empat bentuk normal yang biasa digunakan yaitu :

first normal form, second normal form dan third normal form dan beyce-codd

normal form

2.1.9.2.1 UNF (Un-Normal Form)

Menurut Connolly dan Begg ( 2005 , p402 ), proses normalisasi dimulai

dari bentuk UNF (Un-Normal Form), yaitu tabel yang masih mengandung

repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber

informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom.

2.1.9.2.2 1NF (First Normal Form)

Menurut Connolly dan Begg ( 2005 , p403 ), pada bentuk normal pertama

( First Normal Form – 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan

baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel

mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak

normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan

repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau

sekumpulan atribut dalam tabel yang memiliki multiple values untuk single

occurrence dari atribut key yang terpilih untuk tabel tersebut.

2.1.9.2.3 2NF (second Normal Form)

Menurut Connolly dan Begg ( 2005 , p407 ), sebuah tabel disebut berada

pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan

primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah

1NF telah berada pada 2NF maka tentukan PK dan funtional dependency.

47

2.1.9.2.4 3NF (Third Normal Form)

Menurut Connolly dan Begg ( 2005 , p408 ), sebuah tabel disebut berada

pada bentuk normal ketiga jika dan hanya jika tidak ada atribut bukan primary

key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel

yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya

disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada

3NF jika dan hanya jika tidak mengandung transitive dependency.

2.1.9.2.5 BCNF(Boyce-Codd Normal Form)

Menurut Connolly dan Begg ( 2005 , p419 ), suatu relasi dianggap

sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah

candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk

normal BCNF maka harus dilakukan analisa atas functional dependency dari

sebuah tabel.

2.1.10 Tools Yang Digunakan

Untuk menyelesaikan suatu masalah dengan cara mendekomposisi system ke

dalam komponen yang lebih kecil dengan tujuan untuk mempelajari bagaimana

komponen-komponen tersebut bekerja dan saling berinteraksi maka kita memerlukan

tool-tool yang dapat mencerminkan proses. Adapun beberapa tool yaitu :

2.1.10.1 Data Flow Diagram

Menurut Hall ( 2001 , p69 ), DFD yang juga disebut dengan Diagram

Arus Data, adalah diagram yang menyajikan rangkaian simbol - simbol untuk

mencerminkan proses, sumber-sumber data, arus data, dan entitas dalam sebuah

sistem pada tingkatan rinci yang berbeda.

48

DFD pertama kali diperkenalkan sebagai modeling tools Tom Demarco (

1978 ), Gane dan Sarson ( 1979 ) dengan menggunakan pendekatan metode

analisis sistem terstrukstur (structured system analysis method). DFD juga dapat

digunakan untuk merepresentasikan suatu sistem yang otomatis maupun manual

dengan menggunakan gambar yang berbentuk jaringan grafik.

Tingkatan Diagram Pada DFD :

1 Diagram Konteks

• Merupakan level tertinggi pada DFD yang menggambarkan seluruh output

atau input ke sistem

• Memberikan gambaran tentang keseluruhan sistem

• Terminal yang memberikan masukan kepada sistem disebut source,

sedangkan yang menerima keluaran dari sistem disebut sink

• Hanya ada satu proses didalam diagram konteks

• Tidak boleh ada proses penyimpanan data (data store)

2. Diagram Nol

• Memperlihatkan proses penyimpanan data (data store) yang digunakan

• Untuk proses yang tidak rinci lagi pada level selanjutnya, tambahkan tanda *

pada akhir nomor proses

• Keseimbangan antara input dan output pada diagram nol dan diagram

konteks harus terpelihara

49

Simbol-simbol dalam DFD adalah :

Tabel 2.1 Tabel Simbol DFD

External entity atau

terminal

Proses

Penyimpanan data

atau data storage

Aliran data atau Data

Flow

2.1.10.2 State Transition Diagram (STD)

Menurut Pressman ( 2001 , p302 ), State Transition Diagram merupakan

suatu diagram yang menggambarkan bagaimana state dihubungkan dengan state

yang lain pada satu waktu. State Transition Diagram menunjukkan bagaimana

sistem bekerja sebagai akibat dari kejadian eksternal. Untuk melakukan hal itu,

State Transition Diagram menampilkan model yang bermacam-macam dari

tindakan sebuah sistem dan dibuat dari state ke state.

Komponen dasar dari State Transition Diagram adalah :

50

1. : menyatakan state atau kondisi dari suatu sistem. State

terdiri dari dua macam, yaitu initial state / state awal dan

final state / state akhir. Final state dapat terdiri atas

beberapa state, tetapi initial state tidak boleh lebih dari

satu.

2. : menyatakan perubahan kondisi dari suatu sistem.

Digambarkan untuk menghubungkan keadaan sistem yang

berkaitan.

3. Kondisi dan Aksi

Kondisi : menyatakan suatu kejadian pada lingkungan eksternal yang dapat

dideteksi oleh suatu sistem. Misalnya : suatu sinyal / data.

Aksi : menyatakan sesuatu yang dilakukan oleh sistem apabila terjadi

perubahan state / merupakan suatu reaksi terhadap kondisi. Aksi akan

menghasilkan output, message display pada monitor dan menghasilkan

kalkulasi.

2.1.10.3 Bagan Alir Dokumen (Document FlowChart)

Document FlowChart digunakan untuk menggambarkan bagan alir

dokumen suatu sistem. Berikut adalah simbol – simbol standar beserta

keterangannya untuk mengambarkan bagan alir dokumen :

Tabel 2.2 Tabel Simbol Document FlowChart

Lambang Keterangan Dokumen. Simbol ini digunakan untuk menggambarkan

semua jenis dokumen, yang merupakan formulir yang diunakan untuk merekam data terjadinya suatu transaksi

51

Dokumen dan tembusannya. Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor lembar dokumen dicantumkan di sudut kanan atas

Catatan. Simbol ini digunakan untuk menggambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya di dalam dokumen atau formulir

Penghubung pada halaman yang sama (on-page connector). Dalam menggambarkan bagan 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 ini.

Penghubung pada halaman yang berbeda (off-page connector). Jika untuk menggambarkan bagan alir suatu sistem akuntansi diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan lainnya.

Kegiatan manual. Simbol ini digunakan untuk menggambarkan kegiatan manual seperti : menerima order dari pembeli, mengisi formulir dan kegiatan lainnya

Keterangan, komentar. Simbol ini memungkinkan ahli sistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan alir

Arsip permanen. Simbol ini digunakan untuk menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan

Keputusan. Simbol ini menggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol

Garis alir (flowline). Simbol ini menggambarkan arah proses pengolahan data. Anak panah tidak digambarkan jika arus dokumen mengarah ke bawah dan ke kanan. Jika arus dokumen mengalir ke atas atau ke kiri, anak panah perlu dicantumkan

52

Persimpangan garis alir. Jika dua garis alir bersimpangan, untuk menunjukkan arah masing – masing garis, salah satu garis dibuat sedikit melengkung tepat pada persimpangan ke dua garis tersebut

Pertemuan garis alir. Simbol ini digunakan jika dua garis alir bertemu dan salah satu garis mengikuti arus garis lainnya

Mulai/berakhir (terminal). Simbol ini untuk menggambarkan awal dan akhir suatu sistem akuntansi

Masuk ke sistem. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan masuk ke sistem yang digambarkan dalam bagan alir

Keluar ke sistem lain. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan keluar ke sistem lain

Perbedaan data flow dengan flowchart :

1. Proses dalam data flow dapat dioperasikan secra parallel,sehingga dapat

dieksekusi secara terus menerus, sedangkan proses pada data flow dapat

dieksekusi sekali

2. Diagram data flow menunjukan aliran data melalui system

3. data flow diagram dapat menunjukan proses yang memiliki perbedaan

waktu.

53

2.2 Teori-Teori Khusus

2.2.1 Persediaan

Menurut Mulyadi ( 2001 , p553 ), sistem persediaan bertujuan untuk mencatat

mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan

sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan

sistem akuntansi biaya produksi.

2.2.1.1 Jenis-jenis persediaan

Menurut Sofjan Assauri (1999, 221), persediaan yang terdapat di dalam

perusahaan dapat di bedakan menurut berbagai cara antara lain sebagai berikut:

1) Menurut fungsinya, persediaan dapat dibedakan atas :

a) Batch Stock atau Lot Size Inventory

Adalah persediaan yang diadakan karena kita membeli atau

membuat bahan-bahan atau barang-barang dalam jumlah yang lebih besar

daripada jumlah yang dibutuhkan pada saat itu. Jadi dalam hal ini

pembelian atau pembuatan yang dilakukan untuk jumlah yang besar,

sedangkan penggunaan atau pengeluaran dalam jumlah kecil. Terjadinya

persediaan karena pengadaan bahan atau barang yang dilakukan lebih

banyak daripada yang dibutuhkan.

b) Fluctuation Stock

Adalah persediaan yang diadakan untuk menghadapi fluktuasi

permintaan konsumen yang tidak dapat diramalkan.

c) Anticipation Stock

Adalah persediaan yang diadakan untuk menghadapi fluktuasi

permintaan yang dapat diramalkan berdasarkan pola musiman yang

54

terdapat dalam satu tahun dan untuk menghadapi penggunaan atau

penjualan yang meningkat.

2) Menurut jenis dan posisi barang tersebut didalam urutan pengerjaan produk,

persediaan dapat dibagi atas :

a) Persediaan bahan baku (Raw Materials)

Yaitu persediaan dari barang-barang berwujud yang digunakan

dalam proses produksi. Contoh : kapas dipintal menjadi benang, benang

diolah menjadi kain atau kaos.

b) Persediaan bagian produk atau parts yang dibeli (purchased parts /

komponen stock)

Yaitu persediaan barang-barang yang terdiri dari parts yang

diterima dari perusahaan lain, yang dapat secara langsung di assembling

dengan parts lain, tanpa melalui proses produksi sebelumnya. Jadi bentuk

barang yang merupakan parts tidak mengalami perubahan dalam operasi.

Misalnya pabrik mobil, dimana dalam hal ini bagian-bagian (parts) dari

mobil tersebut tidak diprodusir dalam pabrik mobil, tetapi

diprodusir oleh perusahaan lain, dan kemudian di assembling menjadi

barang yakni mobil.

c) Persediaan barang-barang pembantu atau barang-barang pelengkap

(supplies stock)

Yaitu persediaan barang-barang atau bahan-bahan yang

diperlukan dalam proses produksi untuk membantu berhasilnya produksi

atau yang dipergunakan dalam bekerjanya suatu perusahaan, tetapi tidak

55

merupakan bagian atau komponen dari barang jadi. Misalnya minyak

solar dan minyak pelumas adalah hanya merupakan bahan pembantu.

d) Persediaan barang setengah jadi atau barang dalam proses (work in

process / progress)

Yaitu persediaan barang-barang yang keluar dari tiap-tiap bagian

dalam satu pabrik atau bahan-bahan yang telah diolah menjadi suatu

bentuk, tetapi lebih perlu diproses kembali untuk kemudian menjadi

barang jadi.

e) Persediaan barang jadi (finished goods stock)

Yaitu persediaan barang-barang yang telah selesai diproses atau

diolah dalam pabrik dan siap untuk dijual kepada pelanggan atau

perusahaan lain.

2.2.1.2 Biaya-biaya yang timbul akibat adanya persediaan

Menurut Hani Handoko (2000:336), ada beberapa biaya-biaya yang

timbul dari adanya persediaan antara lain :

1. Biaya penyimpanan

Biaya penyimpanan (holding costs / carrying cost) terdiri atas biaya-

biaya yang bervariasi secara langsung dengan kuantitas persediaan biaya

penyimpanan per periode akan semakin banyak apabila kuantitas bahan

baku yang di pesan semakin banyak, atau rata-rata persediaan semakin

tinggi.

Biaya-biaya yang termasuk sebagai biaya penyimpanan adalah :

56

1. Biaya fasilitas-fasilitas penyimpanan (termasuk penerangan, pemanas,

atau pendingin).

2. Biaya modal.

3. Biaya keusangan

4. Biaya perhitungan fisik dan konsiliasi laporan

5. Biaya asuransi

6. Biaya pajak persediaan

7. Biaya pencurian, pengrusakan, dan perampokan

8. Biaya penanganan persediaan

2. Biaya pemesanan

Setiap kali suatu bahan dipesan, perusahaan menanggung biaya

pemesanan.

Biaya pemesanan secara terperinci meliputi :

1. Pemrosesan pesanan dan biaya ekspedisi

2. Upah

3. Biaya telepon

4. Pengeluaran surat menyurat

5. Biaya pengepakan

6. Biaya pemeriksaan

7. Biaya pengiriman kegudang

57

3. Biaya penyiapan

Bila bahan-bahan tidak dibeli, tetapi diproduksi sendiri”dalam pabrik”

perusahaan. Perusahaan menghadapi biaya penyiapan (setup costs) untuk

memproduksi komponen tertentu.

Biaya-biaya ini terdiri dari :

1. Biaya mesin menganggur

2. Biaya persiapan tenaga kerja langsung

3. Biaya scheduling

4. Biaya ekspedisi

4. Biaya kehabisan atau kekurangan bahan

Dari semua biaya-biaya yang berhubungan dengan tingkat persediaan,

biaya kekurangan (shortage costs) adalah yang paling sulit diperkirakan.

Biaya ini timbul bilamana persediaan tidak mencukupi adanya

permintaan bahan.

Biaya-biaya yang termasuk biaya kekurangan adalah sebagai berikut :

1. Kehilangan penjualan

2. Kehilangan pelanggan

3. Biaya pemesanan khusus

4. Biaya ekspedisi

5. Selisih harga

6. Terganggunya operasi

7. Tambahan pengeluaran kegiatan manajerial

58

2.2.1.3 Fungsi Persediaan

Menurut Sofjan Assauri (1999:230), fungsi persediaan yang efektif

adalah:

1. Memperoleh bahan-bahan

Yaitu menetapkan prosedur untuk memperoleh suplai yang cukup

dari bahan-bahan yang dibutuhkan baik kuantitas maupun kualitas.

2. Menyimpan dan memelihara bahan-bahan dalam persediaan

Yaitu mengadakan suatu system penyimpanan untuk memelihara

dan melindungi bahan-bahan yang telah dimasukkan ke dalam

persediaan.

3. Pengeluaran bahan-bahan

Yaitu menetapkan suatu pengaturan atas pengeluaran dan

penyampaian bahan-bahan dengan tepat pada saat serta tempat dimana

dibutuhkan.

4. Meminimalisasi investasi dalam bentuk bahan atau barang

(mempertahankan persediaan dalam jumlah yang optimum setiap waktu).

2.2.2 Penjualan

Menurut Mulyadi ( 2001 , p202 ), kegiatan penjualan terdiri dari penjualan

barang dan jasa, baik secara kredit maupun secara tunai. Dalam transaksi penjualan

kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau

penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada

pelanggannya. Dalam sistem penjulan secara tunai, barang atau jasa baru diserahkan

oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli.

59

Menurut Mulyadi(2001,p226), Transaksi retur penjualan terjadi jika perusahaan

menerima pengembalian barang dari pelanggan. Pengembalian barang oleh pelanggan

harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Fungsi

yang terkait dalam melaksanakan transaksi retur penjualan adalah :

1. Fungsi penjualan

Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai

pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan

kembali barang yang telah dijual tersebut dilakukan dengan cara membuat

memo kredit yang dikirimkan kepada fungsi penerimaan.

2. Fungsi penerimaan

Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan otorisasi

yang terdapat dalam memo kredit yang diterima dari fungsi penjualan.

3. Fungsi gudang

Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang

diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi

penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat

oleh fungsi gudang dalam kartu gudang.

4. Fungsi akuntansi

Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke

dalam jurnal umum dan pencatatan berkurangnya piutang dan bertambahnya

persediaan akibat retur penjualan dalam kartu piutang dan kartu persediaan.

Disamping itu, fungsi ini juga bertanggung jawab untuk mengirimkan memo

kredit kepada pembeli yang bersangkutan.

60

Menurut Mulyadi(2001,p234), jaringan prosedur dalam sistem retur penjualan

adalah sebagai berikut :

1. Prosedur pembuatan memo kredit

Fungsi penjualan membuat memo kredit yang memberikan perintah kepada

fungsi penerimaan untuk menerima barang dari pembeli tersebut dan kepada

fungsi akuntansi untuk pencatatan pengurangan piutang kepada pembeli yang

bersangkutan.

2. Prosedur penerimaan barang

Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari memo

kredit yang diterima dari fungsi penjualan. Atas penerimaan barang tersebut

fungsi penerimaan membuat laporan penerimaan barang untuk melampiri

memo kredit yang dikirim ke fungsi akuntansi.

3. Prosedur pencatatan retur penjualan

Dalam prosedur ini transaksi berkurangnya piutang dagang dan pendapatan

penjualan akibat dari transaksi retur penjualan dicatat oleh fungsi akuntansi

ke dalam jurnal umum atau jurnal retur penjualan dan ke dalam buku

pembantu piutang. Dalam prosedur ini pula berkurangnya harga pokok

penjualan dan bertambahnya harga pokok persediaan dicatat oleh fungsi

akuntansi ke dalam jurnal umum dan dalam buku pembantu persediaan.

Menurut Mulyadi ( 2001 , p204 ), fungsi yang terkait pada penjualan secara

kredit adalah :

1. Fungsi penjualan

61

Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk

menerima surat order dari pembeli, mengedit order dari pelanggan untuk

menambahkan informasi yang belum ada pada surat order tersebut (seperti

spesifikasi barang dan rute pengiriman), meminta otorisasi kredit,

menentukan tanggal pengiriman dan dari gudang nama barang akan dikirim,

dan mengisi surat order pengiriman. Fungsi ini juga bertanggung jawab untuk

membuat “back order” pada saat diketahui tidak tersedianya persediaan

untuk memenuhi order dari pelanggan.

2. Fungsi kredit

Fungsi ini berada di bawah fungsi keuangan yang dalam transaksi penjualan

kredit, bertanggung jawab untuk meneliti status kredit pelanggan dan

memberikan otorisasi pemberian kredit kepada pelanggan. Karena hampir

semua penjualan dalam perusahaan manufaktur merupakan penjualan kredit,

maka sebelum order dari pelanggan dipenuhi, harus lebih dahulu diperoleh

otorisasi penjualan kredit dari fungsi kredit. Jika penolakan pemberian kredit

seringkali terjadi, pengecekan status kredit perlu dilakukan sebelum fungsi

penjualan mengisi surat order penjualan. Untuk mempercepat pelayanan

kepada pelanggan, surat order pengiriman dikirim langsung ke fungsi

pengiriman sebelum fungsi penjualan memperoleh otorisasi kredit dari fungsi

kredit. Namun, tembusan kredit harus dikirimkan ke fungsi kredit untuk

mendapatkan persetujuan kredit dari fungsi tersebut. Dalam hal otorisasi

kredit tidak dapat diberikan, fungsi penjualan memberitahu fungsi

pengiriman untuk membatalkan pengiriman barang kepada pelanggan.

62

3. Fungsi gudang


menyimpan barang dan menyiapkan barang yang dipesan oleh pelanggan,

serta menyerahkan barang ke fungsi pengiriman.

4. Fungsi pengiriman


menyerahkan barang atas dasar suatu order pengiriman yang diterima dari

fungsi penjualan. Fungsi ini bertanggung jawab untuk menjamin bahwa tidak

ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang

berwenang. Otorisasi ini dapat berupa surat order pengiriman yang telah

ditandatangani oleh fungsi penjualan, memo debit yang ditandatangani oleh

fungsi pembelian untuk barang yang dikirimkan kembali kepada pemasok

(retur pembelian), surat perintah kerja dari fungsi produksi mengenai

penjualan / pembuangan aktiva tetap yang sudah tidak dipakai lagi.

5. Fungsi penagihan


membuat dan mengirimkan faktur penjualan kepada pelanggan, serta

menyediakan copy faktur bagi kepentingan pencatatan transaksi penjualan

oleh fungsi akuntansi.

6. Fungsi akuntansi


mencatat piutang yang timbul dari transaksi penjualan kredit dan membuat

serta mengirimkan pernyataan piutang kepada para debitur, serta membuat

63

laporan penjualan. Di samping itu, fungsi ini juga bertanggung jawab untuk

mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan.

Menurut Mulyadi ( 2001 , p219 ), sistem dan prosedur yang bersangkutan

dengan sistem penjualan kredit adalah :

a. Prosedur order penjualan

Dalam prosedur ini, fungsi penjualan menerima order dari pembeli dan

menambahkan informasi penting pada surat order dari pembeli. Fungsi

penjualan kemudian membuat surat order pengiriman dan mengirimkannya

kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut

memberikan kontribusi dalam melayani order dari pembeli.

b. Prosedur persetujuan kredit

Dalam prosedur ini, fungsi penjualan meminta persetujuan penjualan kredit

kepada pembeli tertentu dari fungsi kredit.

c. Prosedur pengiriman

Dalam prosedur ini, fungsi pengiriman mengirimkan barang kepada pembeli

sesuai dengan informasi yang tercantum dalam surat order pengiriman yang

diterima dari fungsi pengiriman.

d. Prosedur penagihan

Dalam prosedur ini, fungsi penagihan membuat faktur penjualan dan

mengirimkannya kepada pembeli. Dalam metode tertentu faktur penjualan

dibuat oleh fungsi penjualan sebagai tembusan pada waktu bagian ini

membuat surat order pengiriman.

64

e. Prosedur pencatatan puitang

Dalam prosedur ini, fungsi akuntansi mencatat tembusan faktur penjualan ke

dalam kartu piutang atau dalam metode pencatatan tertentu mengarsipkan

dokumen tembusan menurut abjad yang berfungsi sebagai catatan piutang.

f. Prosedur distribusi penjualan

Dalam prosedur ini, fungsi akuntansi mendistribusikan data penjualan

menurut informasi yang diperlukan oleh manajemen.

g. Prosedur pencatatan harga pokok penjualan

Dalam prosedur ini, fungsi akuntansi mencatat secara periodik total harga

pokok produk yang dijual dalam periode akuntansi tertentu.

bab 2 landasan teori 2.1 pendekatan...

Documents