bina nusantara | library & knowledge...

BAB 2

LANDASAN TEORI

2.1 Teori Umum

Pada teori umum ini kami akan menjelaskan teori yang akan sering

digunakan sebagai penunjang dan pedoman untuk membuat rancangan basis data

dan prototype pada skripsi kami

2.1.1 Pengertian Data

Menurut (Hoffer, Presscot, & McFadden, 2005, p.5), data yaitu

sebuah representasi penyimpanan dari obyek – obyek dan kejadian – kejadian

yang beramakna dan penting di lingkungan pemakai.

Sedangkan menurut (Laudon & Laudon, 2010, p.6), mengatakan

bahwa “data adalah aliran fakta mentah yang merupakan kejadian yang

terjadi dalam organisasi atau lingkungan fisik sebelum mereka terorganisir

dan disusun menjadi bentuk yang orang – orang dapat memahami dan

digunakan”

2.1.2 Pengertian Informasi

(Menurut Brian K & Stacey, 2007, p.25), mendefinisikan informasi

adalah data yang sudah diolah atau dimanipulasi untuk digunakan dalam

pengambilan keputusan.

Menurut (O'Brian & Marakas, 2011, p.34) informasi adalah data yang

telah diubah menjadi isi yang mempunyai arti dan kegunaan untuk pengguna

akhir tertentu.

Dalam jurnal (Fattahi & Afshar,2006) disimpulkan bahwa informasi

akan sangat berguna tergantung dari pemberian nilai informasi tersebut. Nilai

informasi dapat dilihat dari sudut pandang yang berbeda oleh pihak

manajemen atas untuk membuat keputusan manajemen operasional. Nilai

informasi berguna sebagai nilai tambah dalam menghemat waktu proses

7

8

bisnis, produktivitas serta meningkatkan pengembangan kualitas kerja dengan

membagi informasi tersebut ke dalam internal perusahaan.

2.1.3 Basis Data

Menurut (Connolly & Begg, 2010, p.15), basis data adalah kumpulan

data yang saling berhubungan secara logis, dan sebuah penjelasan dari data

tersebut, yang didesain untuk menemukan data yang diperlukan organisasi.

Di dalam basis data, semua data diintegrasikan dengan menghindari duplikasi

data. Basis data banyak digunakan oleh banyak departemen dan user. Basis

data tidak hanya menangani data operasional organisasi, tetapi juga

mengenai data tersebut.

Menurut(Turban et al 2005, p.16), database merupakan kumpulan file,

tabel,dan relasi yan menyimpan data beserta hubungan diantara data tersebut.

Menurut (Lonely & Bryla, 2005, p.4), basis data merupakan

kumpulan data pada disk dalarn satu atau lebih file pada server basis data

yang dikumpulkan dan dikelola berdasarkan informasi terkait.

Didalam jurnal juga dikatakan :

Menurut (Honni, 2011) Perusahaan membutuhkan sebuah sistem yang

terintegrasi baik dalam pengolahan data dan penyimpanan data maupun

pengolahan terhadap arus transaksi yang berdasarkan pada sistem basis data

sehingga dalam melakukan proses bisnisnya dapat cepat, akurat dan dapat

diandalkan sehingga dapat meningkatkan efisiensi dan kualitas kerja

perusahaan.

Menurut (Ayuliana, 2012) dengan dibuatnya sistem basis data dan

program aplikasi ini dengan baik dapat membantu kinerja karyawan dalam

menangani transaksi persediaan, penjualan, karena memiliki fitur-fitur yang

memudahkan user untuk mengaksesnya sesuai dengan kebutuhan.

Menurut (Christensen, Brandt, & McCracken, 2011) menyatakan

bahwa data – data yang nantinya akan menghasilkan informasi, disimpan ke

dalam suatu tabel dimana tabel tersebut berhubungan satu sama lainnya.

9

Setiap tabel yang mengandung satu atau lebih atribut digunakan untuk

menghasilkan kualifikasi, identifikasi, pengelompokan, kuantitas, atau

mendeskripsikan susunan informasi tabel tersebut

2.1.4 Database Management System

Menurut (Connolly & Begg, 2010, p.66).Database management

system (DBMS) adalah sistem perangkat lunak yang memungkinkan

pengguna sistem untuk mendefinisikan, membuat, memelihara, dan

mengendalikan akses ke dalam basis data

Gambar 2.1 Database Management System

Sumber : (Connolly & Begg, 2010, p.67)

Pada gambar 2.1 dijelaskan tentang bagian sales dan contracts

menyatakan bahwa ada dua pengguna sistem yang memasukan data yaitu

bagian sales dan bagian contracts. Dua pengguna sistem dengan komputer

client yang berbeda mengakses satu basis data yang sama tentu dengan

pemasukan data yang berbeda, seperti pada gambar yang tertera bahwa

bagian penjualan memasukan data dan laporan dengan mengakses aplikasi

“sales application program” dan bagian contracts memasukan data dan

laporan dengan mengakses aplikasi yang berbeda dari bagian sales, yaitu

“contracts application program”, hal seperti ini membutuhkan suatu

manajemen atau pengendalian ke dalam basis data dengan adanya DBMS.

Fungsi DBMS itu sendiri adalah memberikan hak akses kepada dua pengguna

bagian sales dan bagian contracts, data – data apa saja yang mereka masukan,

modifikasi serta menghapus tergantung dari hak akses mereka, sehingga

kontrol terhadap data – data yang berbeda jenis dapat teratasi

10

2.1.4.1 Fasilitas DBMS

Biasanya DBMS memiliki fasilitas-fasilitas sebagai berikut:

1. Data Definition Language (DDL) adalah fasilitas

mendefinisikan basis data. DDL mengizinkan pengguna untuk

memspesifikasikan tipe, struktur, dan batasan aturan mengenai

data yang bisa disimpan ke dalam basis data.hal yang bisa

dilakukan DDL adalah :

Create Table

Untuk membuat tabel dengan mengidentifikasikan tipe data

untuk tiap kolom.

Alter Table

Untuk menambah atau membuang kolom dan constrain.

Drop Table

Untuk membuang atau menghapus tabel beserta semua data

yang terkait di dalamnya.

Create Index

Untuk membuat index pada suatu tabel.

Drop Index

Untuk membuang atau menghapus index yang telah dibuat

sebelumnya.

2. Data Manipulation Language (DML) adalah fasilitas

pengguna untuk menambah, menghapus mengedit dan

mendapatkan kembali data dari basis data,. Ada juga suatu

fasilitas yang melayani pengaksesan data yang disebut query

language. Bahasa yang diakui adalah Structured Query

Language (SQL), yang merupakan standard dari DBMS.

3. Data Control Language (DCL) Fasilitas yang digunakan

mengontrol ke basis data . Contoh :

Sistem keamanan yang mencegah user yang tidak punya

autoritas untuk akses data.

11

Suatu sistem terintegasi yang memelihara konsistensi

penyimpanan data.

Suatu Sistem kontrol pengembalian data yang mana dapat

mengembalikan data ke keadaan sebenarnya apabila terjadi

kegagalan perangkat keras atau perangkat lunak.

Terdapat suatu katalog yang dapat di akses oleh pengguna,

yang menjelaskan data didalam basis data tersebut.

2.1.4.2 Komponen DBMS

Menurut (Connoly & Begg, 2010, p.18), Komponen DBMS terbagi

menjadi lima yaitu :

1. Hardware (perangkat keras)

DBMS dan program aplikasi membutuhkan perangkat

keras untuk bisa menjalankan fungsi – fungsinya. dapat

berkisar dari komputer tunggal, mainframe tunggal, hingga

jaringan komputer. perangkat keras yang dipakai tergantung

pada kebutuhan organisasi dan Database Management System

(DBMS) yang digunakan. Sebuah DBMS memerlukan jumlah

minimum memori dan hardisk untuk bekerja, tetapi konfigurasi

yang minimum tidak memberikan performa yang handal.

2. Software (perangkat lunak)

Komponen perangkat lunak terdiri dari perankat lunak

DBMS dan program aplikasi beserta sistem operasi (OS),

termasuk jaringan perangkat lunak jika DBMS digunakan

melalui jaringan.

3. Data

Data merupakan data terpenting dalam DBMS

khususnya sudut pandang dari end user mengenai data, dimana

data berfungsi sebagai jembatan antara komponen mesin

dengan komponen manusia.

4. Procedures

12

Prosedur merupakan panduan dan aturan dalam

membuat dan menggunakan basis data. Prosedur didalam basis

data berupa : login ke dalam basis data, penggunaan fasilitas

DBMS atau aplikasi program, cara menjalankan dan

menghentikan DBMS, membuat backup database, menangani

kerusakan hardware atau software, mengubah struktur table,

mengumpulkan basis data dari beberapa disk, meningkatkan

kinerja atau membuat arsip data pada secondary storage.

5. People (manusia)

Komponen terakhir yaitu manusia yang terlibat dengan

sistem tersebut.

Gambar 2.2 The DBMS EnvirontmentSumber : (Connolly & Begg, 2010, p.68)

2.1.4.3 Keuntungan dan kerugian DBMS

Keuntungan dari DBMS

- Berbagi data

- Standarisasi

- Konsistensi Data

- Meningkatkan konkurensi

- Meningkatkan produktifitas

- Meningkatkan keamanan data

- Mengendalikan redudansi data

- Mengimprovisasi integritas data

- Menyediakan backup data dan recovery

- Menyeimbangkan kebutuhan yang bertentangan

13

- Informasi yang lebih dari jumlah data yang sama

- Meningkatkan aksebilitas data dan responsiveness

- Meningkatkan pemeliharaan melalui data independen

Kerugian dari DBMS

- Mahal

- Compexity atau rumit

- Memperlambat kinerja beberapa aplikasi lain

- Membutuhkan tempat atau penyimpanan besar

-

2.1.5 Database System Development Lifecycle

Menurut(Connolly & Begg 2010, p.283), sistem basis data adalah

komponen yang fundamental didalam organisasi yang besar dengan sistem

informasi yang luas. Hal penting yang harus diperhatikan dalam Database

System Development Lifecycle adalah bahwa tingkatannya tidak sepenuhnya

berurutan (sequential). Dimana ada beberapa tingkatan yang berulang dengan

alur balik (feedback loop), contohnya masalah ditemukan pada tingkat

perancangan basis data yang membutuhkan tambahan kumpulan kebutuhan

dan analisis. Untuk aplikasi basis data yang kecil dengan pengguna yang

sedikit maka lifecycle-nya tidak terlalu kompleks. Sebaliknya ketika

merancang basis data yang sedang sampai ke basis data yang banyak dengan

ribuan bahkan puluhan ribu pengguna, mengunakan ratusan query dan

program aplikasi maka lifecycle akan menjadi sangat kompleks.

Gambar 2.3

Tingkatan dari Database System Development Lifecycle

Sumber : (Connolly & Begg, 2010, p.284)

2.1.5.1 Database Planning

14

aktifitas manajemen yang memungkinkan setiap tahapan

dalam Database System Development Lifecycle untuk direalisasikan

menjadi paling efisien dan paling efektif. Database Planning

seharusnya diintegrasikan dengan keseluruhan strategi sistem

informasi dari organisasi. Ada 3 persoalan utama dalam menyusun

strategi sistem informasi, 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 keunggulan dan kelemahan.

3. penafsiran dari IT opportunity untuk mendapatkan

keuntungan bersaing.

2.1.5.2 System definition

Sistem definisi mendeskripsikan cakupan dan batasan dari

aplikasi basis data dan user view utama. User view mendeskripsikan

apa yang dibutuhkan dari sebuah basis data dari sudut pandang peran

pekerja (seperti manager atau supervisor) atau area aplikasi

perusahaan (seperti marketing, personel, atau control stock).

2.1.5.3 Requirements Collection and Analysis

Adalah Suatu proses yang mengumpulkan dan menganalisis

informasi mengenai bagian mana saja dari organisasi yang didukung

oleh aplikasi basis data 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 & Begg, 2010, p.317), terdapat lima teknik fact -

finding yang umum digunakan.

15

Interview.

Mengevaluasi dokumentasi.

Observasi.

Questioner.

Research.

2.1.5.4 Database Design

Menurut (Connolly & Begg, 2010, p291 ), Database design

adalah suatu proses yang membuat suatu perancangan untuk basis

data 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 Identifikasi Tipe Entitas

Langkah 1.2 Identifikasi Tipe Relationship

Langkah 1.3 Identifikasi dan Asosiasi Atribut dengan

Tipe Entitas dan Tipe Relationship

Langkah 1.4 Menentukan Domain Atribut

Langkah 1.5 Menentukan Atribut Candidate key,

Primary Key, dan Alternate Key

Langkah 1.6 Mempertimbangkan penggunaan

enhanced modeling concept (optional)

16

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 merubah model konseptual ke model

logikal yang dipengaruhi oleh model data yang menjadi tujuan

dari basis data. Didalam perancangan model logikal, model

data yang telah didapat dalam basis data konseptual diubah

kedalam bentuk dimana data yang ada dipengaruhi oleh model

data yang menjadi tujuan basis data (contoh : relational

model). Hal ini dilakukan untuk menjelaskan representasi

konseptual kedalam bentuk struktur logikal dalam basis data.

Data model logikal adalah sebagai sumber informasi dalam

merancang basis data fisikal. Perancangan basis data logikal

memberikan sarana yang membantu para perancang dalam

merancang basis data 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 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

Pada tahap perancangan basis data fisikal

memungkinkan perancang basis data untuk membuat

keputusan tentang bagaimana basis data akan

diimplementasikan. Oleh karena itu, perancangan basis data

fisikal 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

yang dipilih

18

Langkah 8. Mengawasi dan mengendalikan sistem operasional

2.1.5.5 DBMS selection

Seleksi /pemilihan DBMS dilakukan untuk memilih DBMS yang

sesuai dengan aplikasi basis data. Menurut ( Connolly & Begg, 2010,

p.295 ), berikut ini adalah langkah –langkah dalam memilih DBMS :

1. Mebdeskirpsikan cakupan tugas berdasarkan kebutuhan

perusahaan

2. Membuat perbandingan mengenai 2 atau lebih 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. Memperkenankan pengguna untuk menentukan basis data,

biasanya melalui Data Definition Language (DDL). DDL

memperkenankan pengguna untuk menspesifikasikan tipe

data, struktur data dan batasan-batasan data yang bisa

disimpan di basis data.

2. Memperkenankan pengguna untuk insert, update, delete atau

retrive data dari basis data, biasanya melalui Data

Manipulation Language (DML).

3. DBMS menyediakan akses kontrol ke basis data. Sebagai

contohnya DBMS menyediakan :

a. Security system, dimana menghalangi autorisasi

pengguna untuk mengakses basis data.

b. Integrity system, dimana menangani konsistensi

penyimpanan data.

19

c. Concurrency control system, dimana memperkenankan

basis data untuk diakses secara share.

d. Recovery control system, dimana basis data bias di-

restore pada saat terjadi kesalahan pada hardware

maupun software.

e. User-accesable catalog, berisi deskripsi data dalam

basis data.

2.1.5.6 Application Design

Menurut (Connolly & Begg, 2010, p.299), rancangan aplikasi

adalah perancangan dari user interface dan program aplikasi yang

digunakan dan memproses basis data. Dari gambar 2.1, dapat dilihat

bahwa database design dan application design adalah aktifitas yang

paralel dalam database lifecycle.Didalam kebanyakan kasus tidak

mungkin dapat menyelesaikan application design sebelum

menyelesaikan database design itu sendiri. Dengan kata lain database

yang ada mendukung aplikasi sehingga ada banyak aliran informasi

antara application design dan database design.

2.1.5.7 Prototyping (optional)

Pada kondisi tertentu kita dapat memilih apakah akan

membuat prototipe atau langsung mengimplementasikan basis data.

Suatu prototipe adalah suatu model aplikasi basis data yang

mempunyai semua rupa yang diperlukan dan menyediakan semua

kemampuan sistem. Tujuan utama prototipe adalah 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 & Begg, 2010, p.303), ada dua cara

strategi membuat prototipe yaitu requirements prototyping dan

evolutioner prototyping. Untuk requirements prototyping digunakan

prototipe untuk menentukan kebutuhan suatu aplikasi basis data yang

20

diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka

prototipe tersebut tidak lagi digunakan. Prototype evolutioner

digunakan untuk tujuan yang sama, perbedaannya ialah bahwa

prototipe tidaklah dibuang tapi dikembangkan lebih lanjut sehingga

menjadi aplikasi basis data tersebut.

2.1.5.8 Data Convertion dan Loading

Menurut (Connolly & Begg, 2010, p.305), pemindahan data

yang sudah ada ke basis data yang baru dan mengubah aplikasi yang

sedang berjalan agar dapat digunakan dalam basis data yang baru.

2.1.5.9 Operational Maintenance

Menurut (Connolly & Begg, 2010, p.306), setelah melalui

tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap

pemeiharaan yang melibatkan aktivitas berikut :

1. Monitoring performance dari sistem. Jika performance berada

disuatu tingkatan yang bisa diterima, setting atau menyusun

kembali basis data mungkin diperlukan.

2. Memelihara dan meningkatkan mutu aplikasi basis data.

Kebutuhan baru disatukan kedalam aplikasi basis data 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.

Proses monitoring akan terus berlanjut sepanjang hidup suatu aplikasi

basis data tersebut dan pada waktu tertentu boleh melakukan

menyusun kembali basis data 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

21

rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat

mengembangkan kegunaan yang diperlukan atau memberi tools

tambahan jika tersedia.

2.16 Tahap – Tahap Perancangan Basis data

Dalam merancang suatu basis data melalui beberapa tahapan, sebagai

berikut :

Perancanagan Basis data Konseptual

Perancanagan Basis data Logikal

Perancanagan Basis data Fisikal

2.1.6.1 Perancangan Basis data Konseptual

Menurut (Connolly & Begg 2010, p.439), perancangan

konseptual basis data adalah proses pembangunan model data yang

digunakan di perusahaan, yang tidak bergantung pada semua

pertimbangan fisikal. Tujuannya untuk membangun representasi

konseptual basis data, yang meliputi identifikasi dari entitas - entitas,

atribut - atribut, dan relationship – relationship yang penting.

Langkah 1. Membangun conceptual data model

Tujuannya adalah menurut (Connolly & Begg, 2010, p.442),

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

Tujuannya adalah menurut (Connolly & Begg, 2010,

p.443), mengidentifikasikan tipe – tipe entitas utama yang

dibutuhkan oleh view.

Langkah 1.2 Identifikasikan Tipe Relationship

22


p.445), mengidentifikasikan relationship – relationship

penting yang ada diantara tipe – tipe entitas yang telah

diidentifikasi.

Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut

dengan Tipe Entitas dan Tipe Relationship

Tujuannya adalah menurut (Connolly & Begg, 2010 ,

p.447), untuk menghubungkan atribut – atribut dengan entitas

atau relationship type yang sesuai.

Langkah 1.4 Menentukan Domain Atribut

Tujuannya adalah menurut (Connolly & Begg 2010,

p.450), untuk menentukan domain – domain untuk atribut –

atribut dalam local conceptual data model. Domain atribut

adalah kumpulan nilai yang diperbolehkan untuk satu atau

lebih atribut. Domain adalah 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


p.451), untuk 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 & Begg, 2010, p.451), ketika

memilih primary key diantara candidate key, kita dapat

menggunakan panduan berikut untuk membantu pemilihan

primary key, yaitu :

23

- Candidate key dengan kumpulan atribut yang minimal

- Candidate key yang nilainya jarang berubah

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

Tujuannya adalah menurut (Connolly & Begg, 2010 ,

p.453), untuk mempertimbangkan penggunaan enhanced

modeling concepts, seperti specialization / generalization,

aggregation, dan composition.

Langkah 1.7 Memeriksa model dari redundancy


p.453), untuk 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


p.456), untuk menjamin bahwa model konseptual mendukung

transaksi – transaksi yang dibutuhkan oleh view.

Langkah 1.9 Meninjau local conceptual data model

dengan pengguna

Tujuannya adalah menurut (Connolly & Begg, 2010, p.458),

untuk meninjau local conceptual data model dengan user

24

untuk menjamin bahwa model tersebut adalah representasi

yang sebenarnya dari data yang dibutuhkan oleh perusahaan

2.1.6.2 Perancangan Basis data Logikal

Menurut (Connolly & Begg, 2010, p.439), perancangan

logikal basis data adalah suatu proses pembangunan model data yang

digunakan dalam perusahaan berdasar atas model data yang spesifik,

tetapi tidak bergantung pada particular DBMS dan pertimbangan

fisikal lainnya. Tujuannya untuk menerjemahkan representasi

konseptual ke struktur logikal dari basis data yang meliputi

perancangan relasi – relasi.

Langkah 2. Membangun dan memvalidasi logical data model

Menurut (Connolly & Begg, 2010, p.462), tujuannya adalah

menerjemahkan logical data model dan kemudian untuk mevalidasi

model tersebut untuk memeriksa model tersebut dengan 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

tujuannya adalah menurut (Connolly dan Begg, 2010,

p.463), 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 & Begg, 2010 , p.354), strong

entity type adalah tipe entitas yang keberadaannya tidak

bergantung (independent) pada beberapa tipe entitas lainnya.

Karakteristik dari strong entity type adalah tiap entity

25

occurrence dapat diidentifikasi secara unik menggunakan

atribut primary key dari tipe entitas. Strong entity type sering

juga disebut parent atau owner atau dominant entities.

Menurut (Connolly & Begg, 2010, p.355), 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 & Begg 2010, p.465), 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 & Begg, 2010, p.465), 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 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

26

- Optional participation pada 2 sisi dari 1:1 relationship

● Mandatory participation pada 2 sisi dari 1:1 relationship

Menurut (Connolly & Begg, 2010, p.466), dalam 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 & Begg, 2010, p.466), dalam kasus

ini, kita dapat mengidentifikasikan entitas - entitas parent dan

child untuk 1:1 relationship memakai participation constraint.

Entitas yang memiliki 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.

● Optional participation pada 2 sisi dari 1:1 relationship

Menurut (Connolly & Begg, 2010, p.467), kita dapat

memilih primary key mana yang dipilih tergantung dari kasus

yang ada.

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

Menurut (Connolly & Begg, 2010, p.467), untuk 1:1

recursive relationship, kita mengikuti aturan untuk

participation seperti yang diuraikan untuk 1:1 relationship.

Untuk 1:1 recursive relationship dengan mandatory

27

participation pada dua sisi, direpresentasikan recursive

relationship sebagai relasi tunggal dengan dua salinan primary

key. Sedangkan salah satu salinan dari primary key

merepresentasikan foreign key dan harus diganti 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 dua 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 dua sisi, kita menciptakan relasi baru

seperti yang telah diuraikan diatas.

● Superclass/subclass relationship types

Menurut (Connolly & Begg, 2010, p.467),untuk tiap

superclass / subclass relationship dalam data model

konseptual, kita 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 beberapa 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 & Begg, 2010, p.469), untuk setiap

*:* binary relationship menghasilkan relasi untuk

merepresentasikan relationship dan meliputi atribut – atribut

yang menjadi bagian dari relationship. Kita menyalin salinan

28

primary key dari entitas yang berhubungan dalam relationship

kedalam relasi baru. Untuk valid sebagai foreign key.

● Complex relationship types

Menurut (Connolly & Begg, 2010, p.470), 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.

● Multi-valued attributes

Menurut (Connolly & Begg, 2010, p.471),

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

tujuannya adalah menurut (Connolly & Begg, 2010,

p.473), untuk memvalidasi relasi – relasi dalam model data

konseptual memakai teknik normalisasi.

Menurut (Connolly & Begg, 2010, p.388), 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

29

dilakukan karena terjadinya redundansi data atau kejanggalan

pengubahan (update anomaly).

Menurut (Connolly & Begg, 2010, p.391), 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 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 & Begg, 2010, p.401), 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 Mevalidasi Relasi dengan User Transaction


p.474), untuk menjamin bahwa relasi – relasi dalam model

30

data logikal mendukung transaksi – transaksi yang dibutuhkan

oleh view.

Langkah 2.4 Mendefinisikan Kendala Integrity


p.474),untuk 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.

● Data yang dibutuhkan


beberapa atribut harus selalu memiliki nilai yang valid.

Dengan kata lain, atribut tersebut tidak boleh bernilai

null.

● Attribute domain constraint

Menurut (Connolly & Begg, 2010, p.475), 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 & Begg, 2010, p.475),

multiplicity merepresentasikan batasan yang diletakkan

pada relationship antara data di dalam basis data.

● Entity integrity

31


primary key dari entitas tidak boleh bernilai null.

Batasan ini harus benar – benar dipertimbangkan

ketika kita mengidentifikasikan primary key untuk tiap

tipe entitas.

● Referential integrity


foreign key menghubungkan tiap tuple dalam relasi

child ke tuple dalam relasi parent yang meliputi nilai

candidate key yang sesuai. Referential integrity berarti

bahwa jika foreign key memiliki nilai, maka nilai

tersebut harus menunjuk pada tuple yang ada pada

relasi parent.

Menurut ( Connolly & Begg, 2010, 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

32

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.

● General constraints

Pengubahan – pengubahan pada entitas –

entitas mungkin diatur oleh batasan – batasan yang

memerintah transaksi ’real world’ yang

direpresentasikan oleh pengubahan tersebut

Langkah 2.5 Me-review Logical Data Model dengan User


p.478),untuk menjamin bahwa pengguna mempertimbangkan

model data logikal menjadi representasi yang sebenarnya dari

kebutuhan data perusahaan.

Langkah 2.6 Menggabungkan Logical Data Model ke

dalam Global Model (optional)


p.479), untuk merepresentasikan semua user views dari basis

data.

Langkah 2.7 Memeriksa untuk perkembangan lebih

lanjut


p.490),untuk menentukan apakah terdapat perubahan yang

signifikan pada masa depan yang dapat diramalkan dan untuk

33

menilai apakah model data logikal dapat mengakomodasi

perubahan tersebut.

2.1.6.3 Perancangan Basis data Fisikal

Menurut (Connolly & Begg , 2010, p.439), perancangan fisik

basis data adalah proses membuat deskripsi dari implementasi basis

data pada secondary storage, mendeskripsikan relasi dasar, file

organization, dan index yang digunakan untuk mendapatkan akses

efisien pada data dan semua integrity constraint yang berhubungan

dan security measures. Tujuannya adalah untuk menentukan

bagaimana struktur logikal diimplementasikan (sebagai relasi dasar)

secara fisik dalam DBMS yang dipilih.

Menurut (Connolly & Begg, 2010, p.496), langkah – langkah

perancangan fisik basis data meliputi :

Langkah 3. Menerjemahkan logical data model untuk DBMS

yang dipilih

tujuannya adalah menurut (Connolly & Begg, 2010, p.497),

untuk 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

tujuannya adalah menurut (Connolly & Begg,2010,

p.498), untuk 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

34

- Referential integrity contraints untuk semua foreign keys

yang diidentifikasikan

Menurut (Connolly & Begg, 2010, p.498), sedangkan dari

data dictionary, dari tiap – tiap atribut kita juga mempunyai :

- 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


p.499), untuk menentukan 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

Menurut (Connolly & Begg, 2010, p.501), tujuannya

adalah untuk merancang general constraint untuk DBMS yang

dipilih.

Langkah 4. Merancang file organization dan indexes

Menurut (Connolly & Begg, 2010, p.501), tujuannya adalah

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

35

Terdapat beberapa factor yang dapat digunakan untuk

mengukur efisiensi, yaitu :

- 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 basis data. Para perancang

sistem biasanya ingin meminimalkan disk storage yang

digunakan.

Langkah 4.1 Menganalisa Transaksi

tujuannya adalah menurut (Connolly & Begg 2010,

p.502), untuk mengetahui fungsi dari transaksi yang akan

diterapkan pada basis data dan untuk menganalisa transaksi –

transaksi yang penting.

Langkah 4.2 Memilih Organisasi file


p.506), untuk menentukan organisasi file yang paling efisien

untuk tiap relasi dasar.

Langkah 4.3 Memillih index – index


p.508), untuk mempertimbangkan apakah dengan

menambahkan index akan meningkatkan performansi dari

sistem.

Langkah 4.4 Memperkirakan kebutuhan disk space

36

Menurut (Connolly & Begg, 2010, p.514), untuk

memperkirakan jumlah disk space yang dibutuhkan oleh basis

data. Untuk menyimpan data dan semua index – index

nonclustered dasar dalam tabel yang tidak mempunyai

clustered index oleh karena itu kita dapat menggunakan

beberapa langkah berikut :

1. Menghitung space yang digunakan untuk menyimpan

data

2. Menghitung space yang digunakan untuk menyimpan

tiap index – index nonclustered dasar.

3. Menjumlahkan nilai – nilai yang dikalkulasikan.

Langkah 5. Merancang user view

tujuannya adalah menurut (Connolly & Begg 2010, p.515),

untuk merancang user view yang diidentifikasikan selama

pengumpulan kebutuhan – kebutuhan dan tahap analisis dari system

development lifecycle.

Langkah 6. Merancang mekanisme keamanan


untuk merancang mekanisme keamanan untuk basis data seperti yang

ditentukan oleh user pada waktu tahap pengumpulan kebutuhan –

kebutuhan dari system development lifecycle. Mekanisme kemanan

yang dirancang dalam basis data yaitu mekanisme keamanan sistem

dan mekanisme keamanan data.

Langkah 7. Mempertimbangkan pengenalan redudancy control


untuk menentukan apakah pengenalan redundancy yang dikontrol

dengan aturan – aturan normalisasi akan meningkatkan performansi

sistem.

Langkah 8. Mengawasi dan mengendalikan sistem operasional

37


untuk mengawasi sistem operasional dan meningkatkan performansi

dari sistem untuk memperbaiki keputusan perancangan yang tidak

sesuai atau merefleksikan perubahan kebutuhan.

2.1.7 ER Modeling

2.1.7.1 Entity Type

Pada kutipan jurnal (Bahl, Sharma & Rajpal, 2011, p.2), entity

relationships (ER) model digunakan untuk menunjukkan hubungan antar

entitas dan sebagai tool dasar dalam merancang basis data

Menurut (Connolly & Begg, 2010, p.343), entity type adalah

kelompok objek dengan properties yang sama, yang didefinisikan untuk

perusahaan selama mempunyai keadaan yang independent. Entity type

mempunyai keadaan yang independent dan dapat berupa objek – objek

dengan keberadaan fisik atau objek – objek dengan keberadaan konseptual

2.1.7.2 Entity Occurrence

Menurut (Connolly & Begg, 2010, p.345), entity occurrence adalah

objek dari entity type yang dapat diidentifikasi secara unik.

2.1.7.3 Relationship Type

Menurut (Connolly & Begg, 2010, p.346), relationship type adalah

sekelompok penyatuan yang memiliki arti antar entity types atau sekelompok

penyatuan antara satu atau lebih participating entity type.

2.1.7.4 Relationship Occurrence

Menurut (Connolly & Begg, 2010, p.346), relationship occurrence

adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1

occurrence dari tiap participating entity type.

2.1.7.5 Derajat tipe relasi (Degree of relationship type)

Menurut (Connolly & Begg, 2010, p.376), derajat tipe relasi

merupakan jumlah tipe entitas yang berpartisipasi dalam relasi.Entitas yang

berkaitan dalam tipe relasi dikenal sebagai participant dalam relasi. Jumlah

38

participant dalam tipe relasi dikenal sebagai degree dari relasi. Relasi dengan

degree dua disebut binary, sedangkan relasi dengan degree tiga disebut

ternary, dan relasi dengan degree empat disebut quaternary.

2.1.7.6 Relasi Rekursif (Recursive relationship)

Menurut Connolly dan Begg (2010, p376), relasi rekursif merupakan

sebuah tipe relasi dimana tipe entity yang sama berpartisipasi lebih dari satu

kali dalam peran yang berbeda.

2.1.7.7 Atribut

Menurut (Connolly & Begg, 2010, 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 simple atau composite ; single-valued atau multi-

valued; atau derived.

Simple attribute adalah atribut yang terdiri dari komponen tunggal

dengan keadaan independent. Sedangkan composite attribute adalah atribut

yang terdiri dari beberapa komponen, dimana setiap komponen dengan

keadaan independent contoh nama bisa dipecah lagi menjadi nama depan dan

nama belakang.

Single-valued attribute adalah atribut yang memiliki nilai tunggal

untuk setiap kejadian contohnya entitas staff memiliki IDstaff. Sedangkan

multi-valued attribute adalah atribut yang memiliki beberapa nilai untuk

kejadian contoh no telepon pasti setiap orang mempunyai beberapa telepon .

Derived attribute adalah atribut yang merepresentasikan nilai yang

diperoleh (derived) dari satu atau lebih atribut yang berhubungan contoh lama

pinjam dihasilkan dari awal tanggal pinjam dikurangi tanggal pengembalian.

2.1.7.8 Key

Menurut (Connolly & Begg, 2010, p.352), candidate key adalah

sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap

occurrence dari entity type.

39

Menurut (Connolly & Begg, 2010, p.353), primary key adalah key

yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari

entity type.

Menurut (Connolly & Begg 2010, p.353), composite key adalah

candidate key yang terdiri dari dua atau lebih atribut.

2.1.7.9 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 member dari entitas yang berelasi dengannya

dan entitas tersebut juga berelasi maksimal 1.

Contoh : satu ruang kelas hanya memiliki satu computer dan.

Diasumsikan didalam ruangan tersebut

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

Hubungan one-to-many (1:*)


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 manager dapat memiliki 1 hingga banyak karyawan,

tetapi seorang guru hanya memiliki satu dan hanya satu manager.

Ruang kelas komputer

1..1 memiliki 1..1

40

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

Hubungan many-to-many (*:*)


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 : Pembelian 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.6 Hubungan many-to-many (*:*)

2.1.8 Spesialisasi/ Generalisasi (Specialization/Generalization )

Menurut Thomas (Connolly & Begg, 2010, p.400-403),konsep dari

spesialisasi dan generalisasi adalah asosiasi tipe entitas dengan tipe entitas

khusus yang dikenal sebagai superclass dan subclass, dan proses dari atribut

turunan (inheritance).Superclass adalah suatu tipe entitas yang mengandung

satu atau lebih subgroup terpisah dari suatu occurance, yang dibutuhkan

untuk direpresentasikan pada suatu data model. Subclass adalah suatu

subgroup terpisah dari occurance suatu tipe entitas, yang dibutuhkan untuk

direpresentasikan pada suatu data model.

2.1.9 Normalisasi

2.1.9.1 Pengertian Normalisasi

manager karyawan

1..1 memiliki 1..*

Pembelian barang

0..* Order > 0..*

41

Menurut (Connolly & Begg, 2010, p.401), normalisasi adalah teknik

formal untuk mnganalisa relasi berdasarkan pada primary key (atau candidate

key) dan functional dependencies.

2.1.9.2 Tahapan - tahapan Normalisasi

2.1.9.2.1 UNF (Un-Normal Form)

Menurut (Connolly & Begg, 2010, p.402), proses normalisasi

dimulai dari bentuk UNF (Un-Normal Form), yaitu table 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 & Begg, 2010, 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 & Begg 2010, p.407), 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.

2.1.9.2.4 3NF (Third Normal Form)

Menurut (Connolly & Begg, 2010, p.408), sebuah tabel

disebut berada pada bentuk normal ketiga jika dan hanya jika tidak

42

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 & Begg, 2010, p.419), 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 Teori Activity Diagram

Definisi activity diagram menurut (Satzinger, Jackson, & Burd, 2009,

p.141), adalah diagram alur kerja yang menggambarkan berbagai kegiatan

pengguna atau sistem, orang yang melakukan setiap kegiatan, dan aliran

sekuensial dari kegiatan ini.

Gambar 2.7 Notasi Activity Diagram (Satzinger, 2009)

Notasi – notasi dalam activity diagram antara lain:

1. Oval mewakili kegiatan individu dalam sebuah alur kerja.

2. Connecting Arrow mewakili urutan antara kegiatan.

43

3. Black Circles digunakan untuk menunjukkan awal dan akhir dari alur kerja.

4. Diamond merupakan titik keputusan dimana aliran proses tersebut akan

mengikuti satu jalur atau jalur lain.

5. Synchronization Bar merupakan garis padat yang membagi satu jalur ke

beberapa jalur atau menggabungkan jalur secara bersamaan.

6. Swimline membagi kegiatan – kegiatan pada alur kerja menjadi kelompok –

kelompok yang menunjukkan agen – agen yang melakukan aktivitas – aktivitas.

2.1.11 Use Case Diagram

Menurut (Satzinger, Jackson, & Burd, 2009, p.141), use case diagram

adalah “sebuah diagram yang menunjukkan berbagai peran user dan bagaimana

peran tersebut menggunakan sistem”..

Notasi-notasi yang digunakan dalam use case diagram terdiri dari:

1. Use case: suatu kegiatan yang dilakukan oleh sistem, biasanya dalam

menanggapi permintaan oleh pengguna sistem.

2. Actor: orang yang menggunakan sistem pada setiap use case.

3. Connecting Line: berada di antara aktor dan use case yang

mengindikasikan aktor mana yang menjalankan use case.

4. Automation Boundary: menunjukkan batas antara lingkungan dimana

aktor berada dengan komponen internal dari sistem komputer.

(Satzinger, Jackson, & Burd, 2009, p.242)

Gambar 2.8 Notasi untuk Use Case Diagram

2.1.12 State transition diagram (STD)

State Transition Diagram adalah suatu tools modelling yang

menggambarkan sifat dependent pada waktu dari suatu sistem.

44

Menurut (Harel & Moore, 2011) State Transition Diagram

digunakan untuk membuat modelling berorientasi objek. Hal yang

mendasarinya adalah untuk mengartikan suatu sistem yang memiliki

sejumlah states. Suatu sistem menerima kejadian dari interaksi yang

ada di luar, dan masing - masing kejadian tersebut menyebabkan

perpindahan dari satu state ke state lainnya.

STD juga memiliki arah yang mengelilingi dalam pemodelan

berorientasi objek. Hal tersebut menjelaskan behavior suatu sistem. Ini

berarti mengharuskan analis untuk mendefinisikan semua state yang

mungkin terjadi dan ada pada suatu sistem. Baik pada sistem yang

kecil, maupun sistem yang besar.

Ada 2 (dua) jenis STD, yaitu : model Harel dan model Moore.

Sebagai gambaran,dapat dilihat pada gambar di bawah ini :

a. State Transition Diagram model Harel

Gambar 2.9 Contoh STD model Harel

(Harel & Moore, 2011)

45

sumber :http://www.cs.unc.edu/~stotts/145/CRC/state.html

Gambar 2.10 Contoh State Transistion Diagram model Moore

(Harel & Moore, 2011)

Sumber : http://www.cs.unc.edu/~stotts/145/CRC/state.html

2.2 Teori Khusus

Teori khusus merupakan teori pendukung yang dibuat untuk memenuhi kriteria dari

batasan masalah analisa dan perancangan yang dihadapi

2.2.1 Pembelian

Menurut (Hall, 2008, p.235), prosedur pembelian terdiri dari tugas –

tugas yang meliputi identifikasi kebutuhan persediaan, penempatan order,

penerimaan persediaan. Secara umum definisi pembelian adalah usaha

pengadaan barang atau jasa dengan tujuan yang akan digunakan sendiri,

untuk kepentingan proses produksi yang selanjutnya barang atau jasa tersebut

akan di jual kembali, baik dengan atau tanpa proses, dalam proses pembelian

46

yang ada, agar kegiatan pembelian dapat dilakukan dengan benar. Fungsi

pembelian betanggung jawab untuk memperoleh informasi mengenai harga

barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan

mengeluarkan pesanan pembelian kepada pemasok yang dipilih.

Dokumen – dokumen yang terkait atau termasuk dalam prosedur

sistem pembelian adalah sebagai berikut :

1. Purchase order

Dokumen purchase order disiapkan ketika adanya

kebutuhan barang atau jasa yang dibutuhkan . Dokumen

purchase order disiapkan untuk melakukan pembelian kepada

supplier, tentu kepada supplier yang sudah termasuk di dalam

daftar list. Duplikat dari purchase order diberikan kepada

supplier, bagian keuangan untuk membuat account payabl),

dan terakhir diberikan kepada bagian gudang (persediaan).

2. Retur Pembelian

Retur pembelian merupakan dokumen yang dibuat

apabila barang yang kita beli rusak atau tidak sesuai dengan

apa yang kita inginkan, dokumen yang diberikan dari bagian

pembelian kepada supplier untuk ditanggung jawabkan

barang atau jasa tersebut.

Proses pembelian adalah sebuah struktur interaksi antar orang-orang,

peralatan, metode-metode, dan pengendalian yang dirancang untuk mencapai

fungsi-fungsi utama berikut (Indrajani, 2011,p71) :

1. Menangani rutinitas pekerjaan yang berulang-ulang dari bagian

pembelian dan bagian gudang(persediaan).

2. Mendukung kebutuhan pengambilan keputusan dari orang-orang yang

mengatur bagian pembelian dan persediaan.

3. Membantu Penyiapan laporan internal dan eksternal

Aktivitas Siklus Pembelian

47

Aktivitas-aktivitas yang ada dalam sebuah sistem pemrosesan

pembelian (purchases processing system) (Indrajani, 2011 , p71-72):

1. Fungsi pembelian berawal dari kebutuhan untuk menyediakan stok

kembali setelah melalui pengamatan atas catatan persediaan. Tingkat

persediaan menurun karena penjualan langsung kepada pelanggan

atau karena pengeluaran ke proses produksi. Informasi atas kebutuhan

persediaan dikirimkan ke bagian proses pembelian dan utang usaha

(account payable).

2. Proses pembelian menentukan kuantitas yang akan dipesan, memilih

pemasok, dan menyimpan purchase order. Informasi ini dikirimkan ke

pemasok dan bagian proses utang usaha.

3. Setelah suatu periode tertentu, perusahaan menerima persediaan dari

pemasok. Barang yang diterima akan diperiksa terlebih dahulu untuk

menjamin kuantitas dan kualitas kemudian dikirimkan ke toko atau

gudang.

4. Informasi mengenai penerimaan persediaan digunakan untuk

memperbarui catatan persediaan.

5. Bagian proses utang usaha (account payable) menerima faktur

(invoice) dari pemasok. Bagian ini kemudian akan merekonsiliasi

informasi dalam faktur ini dengan informasi lainnya yang telah

dikumpulkan sehubungan dengan transaksi ini, kemudian mencatat

kewajiban (obligation) untuk pembayaran di waktu mendatang,

tergantung jangka waktu pembayaran dengan pemasok. Biasanya,

pembayaran akan dilakukan pada hari terakhir jangka waktu

pembayaran untuk mengambil manfaat atas bunga dan diskon yang

ada.

6. Buku besar (general ledger) akan menerima informasi dari bagian

utang usaha (account payable) berupa total peningkatan dari utang

(liabilities) dan dari bagian pengendalian persediaan berupa total

peningkatan persediaan. Informasi ini direkonsiliasi untuk menjamin

keakuratan dan diposting ke akun utang usaha dan persediaan

(account payable and inventory).

2.2.2 Persediaan

48

Asset yang tersedia untuk dijual dalam proses bisnis biasa atau asset

yang ada dalam proses produksi untuk dijual kembali, atau asset dalam

bentuk material atau bahan baku untuk digunakan dalam proses produksi.

Asset di sini dapat berbentuk barang atau jasa (Indrajani, 2011 , p70-71).

Dalam perusahaan dagang, persediaan hanya terdiri atas satu

golongan, yaitu persediaan barang dagangan, yang merupakan barang yang

dibeli untuk tujuan dijual kembali. Transaksi yang mengubah persediaan

produk jadi, persediaan bahan baku, persediaan bahan penolong, persediaan

bahan habis pakai pabrik, persediaan suku cadang, bersangkutan dengan

transaksi internal perusahaan dan transaksi yang menyangkut pihak luar

perusahaan (penjualan dan pembelian).

Suatu perusahaan memiliki inventory (persediaan) dengan tujuan

untuk menjaga kelancaran usahanya. Bagi perusahaan, persediaan barang

dagangan memungkinkan untuk memenuhi permintaan pembeli atau pasar.

Di satu sisi persediaan yang tinggi memungkinkan perusahaan untuk

memenuhi permintaan yang mendadak, akan tetapi di sisi lain persediaan

yang tinggi menyebabkan perusahaan memerlukan modal kerja yang makin

besar pula. Untuk itu dibutuhkan pengelolaan terhadap persediaan.Tujuan

pengelolaan inventory adalah turnover (perputaran) dari inventory, yaitu

turnover secepat mungkin tanpa kehilangan sales sebagai akibat kehabisan

inventory.

Pemeliharaan atau pengawasan persediaan adalah sesuatu hal biasa

dalam semua organisasi di setiap faktor ekonomi. (Yamit, 2005, p.3)

mengatakan bahwa masalah persediaan tidak hanya terbatas pada perusahaan

pencari keuntungan saja tetapi juga dialami oleh organisasi sosial maupun

perusahaan non profit oriented, seperti persediaan dalam pabrik, agrobisnis,

pedagang besar, pengecer, rumah sakit, sekolah, hotel dan mesjid, rumah

tangga, restoran, pemerintah dan lain sebagainya. Istilah (terminologi)

persediaan bisa digunakan dalam perbedaan seperti :

1. Persediaan bahan baku di tangan (stock on hand)

2. Daftar persediaan secara fisik

49

3. Jumlah item di tangan

4. Nilai persediaan barang

Fungsi persediaan

Menurut (Yamit, 2005, p.5), persediaan muncul disebabkan oleh tidak

sesuainya permintaan dengan penyediaan dan waktu yang digunakan untuk

memproses material / bahah baku. untuk menjaga keseimbangan permintaan

dengan penyediaan material dan waktu proses diperlukan persediaan. Oleh

karena itu, terdapat empat faktor yang dijadikan sebagai fungsi perlunya

persediaan, yaitu

1. Faktor waktu

Faktor waktu menyangkut lamanya proses produksi dan

distribusi sebelum barang jadi sampai kepada konsumen seperti

outlet/distro. Waktu diperlukan untuk membuat jadwal produksi,

sablon/bordir bahan baku, pengiriman bahan baku, pengawasan bahan

baku, produksi dan pengiriman barang jadi ke outlet dan distro.

Persediaan dilakukan untuk memenuhi kebutuhan selama waktu

tunggu (lead time).

2. Faktor ketidakpastian waktu datang

Faktor ketidakpastian waktu datang dari supplier

menyebabkan perusahaan memerlukan persediaan, agar tidak

menghambat proses produksi maupun keterlambatan pengiriman

kepada outlet/distro. Persediaan bahan baku terikat pada supplier,

persediaan barang dalam proses terikat pada departemen produksi dan

persediaan barang jadi terikat pada konsumen seperti outlet/distro.

Ketidak pastian waktu datang mengharuskan perusahaan membuat

jadwal operasi lebih detail pada setiap tingkatan.

3. Faktor ketidakpastian penggunaan dalam pabrik

Faktor ketidakpastian penggunaan dari dalam perusahaan

disebabkan oleh kesalahan dalam peramalan permintaan, kerusakan

50

mesin, keterlambatan operasi, bahan cacat, dan berbagai kondisi

lainnya. Persediaan dilakukan untuk mengantisipasi ketidaktepatan

peramalan maupun akibat lainnya tersebut.

4. Faktor ekonomis

Faktor ekonomis adalah adanya keinginan perusahaan untuk

mendapatkan alternatif biaya rendah dalam memproduksi atau

membeli item dengan menentukan jumlah yang paling ekonomis.

Pembelian dalam jumlah besar memungkinkan perusahaan

mendapatkan potongan harga yang dapat menurunkan biaya. Selain

itu pemesanan dalam jumlah besar dapat pula menurunkan biaya

karena biaya transportasi per unit menjadi lebih rendah. Persediaan

diperlukan untuk menjaga stabilitas produksi dan fluktuasi bisnis.

Fungsi Inventory

Inventory memiliki fungsi tersendiri, sebagaimana tujuan dari

diadakannya persediaan, berikut ini fungsi-fungsi utamanya (Indrajani, 2011,

p71) yaitu :

1. Menghilangkan/mengurangi resiko keterlambatan pengiriman bahan.

2. Menyesuaikan dengan jadwal produksi.

3. Menghilangkan/mengurangi resiko kenaikan harga.

4. Menjaga persediaan bahan yang dihasilkan secara musiman.

5. Mengantisipasi permintaan yang diramalkan.

6. Mendapatkan keuntungan dari quantity discount.

7. Komitmen terhadap pelanggan

2.2.3 Pengertian Penjualan

Penjualan merupakan kegiatan yang dilakukan oleh penjual dalam menjual

barang atau jasa dengan harapan akan memproleh laba dari adanya transaksi -

51

transaksi tersebut dan penjualan dapat diartikan sebagai pengalihan atau pemindahan

hak kepemilikan atas barang atau jasa dari pihak penjual ke pembeli. Pengertian

penjualan ada bermacam- macam. Namun, menurut (Mulyadi, 2001, 202) adalah

sebagai berikut :

Dalam trasaksi penjualan credit, jika order dari pelanggan telah terpenuhi

dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu

perusahaan memiliki pituang kepada pelanggannya. Kegiatan penjualan secara kredit

ini ditangani oleh perusahaan melalui sistem penjualan kredit.

Jadi, secara umum penjualan pada sadarnya terdiri dari dua jenis yaitu

penjualan tunai dan kredit. Penjualan tunai terjadi apabila penyerahan barang atau

jasa secara diikuti dengan pembayaran dari pembelian, sedangkan penjualan

kredit ada tenggang waktu antara saat penyerahan barang dan atau jasa dalam

penerimaan pembelian. Dalam penjualan kredit, pada saat penyerahan barang dan

atau jasa, penjual menerima tanda bukti penerimaan barang.

Keuntungan dari penjualan tunai adalah hasil dari penjualan tersebut

langsung terealisir dalam bentuk kas yang dibutuhkan perusaan untuk

mempertahankan likuiditasnya, tetapi saat ini umumnya pembelian lebih

cenderung dilakukan secara kredit. Oleh karena itu, dalarn rangka usaha untuk

memperbesar volume penjualaunya, umumnya perusahaan menjual produknya secara

kredit. Penjualan kredit tidak segera menghasilkan pendapatan kas, tetapi kemudian

menumbulkan pituang. Kerugaian dari pei\iualan kredit adalah timbulnya

biaya administrasi piutang dan kerugian akibat piutang tak tertagih.

Penjualan Tunai

Secara umum, terdapat dua jenis penjualan, yaitu penjualan tunai dan

penjualan kredit. Menurut (Narko, 2008, p.71) pengertian penjualan tunai adalah

sebagi berikut: "sistem penjualan dikatakan penjualan tunai apabila pembeli sudah

memilih barang yang adakn di beli, pembeli diharuskan membayar ke bagian kassa".

Jadi penjualan tunai adalah penjualan yang trasaksi pembayaran dan

pemindahan hak atas barangnya langsung. Sehingga tidak perlu ada prosedur piutang

pada perusahaan penjual.

52

Penjualan Kredit

Selain penjualan tunai, jenis penjualan lainnya adalah penjualan kredit.

Penjualan credit menurut (Mulyadi, 2001, p.202) adalah sebagai berikut:

"penjualan kredit dilaksanakan oleh perusahaan dengan cara mengirimkan barang

sesuai dengan order yang diterima dari pembeli dan untuk jangka waktu tertentu

perusahaan mempunyai tagihan kepada pembeli tersebut."

2.2.4 Kebutuhan Untuk Implementasi

2.2.4.1 PHP

PHP Hypertext Preprocessor merupakan HTML-embedded scripting

language, maksudnya adalah bahasa pemrograman yang bisa dimasukan

kedalam penggunaan HTML. PHP mengkombinasikan fitur-fitur terbaik dari

bahasa pemrograman modern untuk menciptaan pendekatan yang unik untuk

membuat aplikasi web. Walaupun banyak bahasa pemrograman namun PHP

didesain dari dasar hingga keatas dengan menggunakan pemikiran web-

development (Allen & Hornberger, 2002, p xix )

2.2.4.2 MySQL

Menurut (Allen & Hornberger, 2002, p.220) MySQL merupakan

bahasa pemrograman open source yang paling popular dan banyak digunakan

di lingkungan Linux. Kepopuleran ini karena ditunjang oleh performansi

query dari databasenya yang jarang bermasalah.

(Nugroho, 2004, p.29) mengemukakan, MySQL (My Structure Query

Language) adalah sebuah program pembuat database yang bersifat open

source, artinya siapa saja dapat menggunakannya secara bebas. Karena

sifatnya open source, MySQL dapat berjalan pada semua platform baik

Windows maupun Linux. Selain itu, MYSQL juga merupakan program

pengakses database yang bersifat jaringan sehingga dapat digunakan untuk

aplikasi multiuser (banyak pengguna). Saat ini database MYSQL telah

digunakan oleh hampir semua pemrograman database , terlebih dalam

pemrograman web

53

KERANGKA BERPIKIR

Melakukan survey dan wawancara ke perusahaan

Mengididentifikasi masalah dengan menanyakan proses bisnis yang sedang berjalan di perusahaan

Membuat perancangan basis data sesuai ketentuan Database System

Development Lifecycle

Melakukan protyping ke perusahaan

bina nusantara | library & knowledge...

Documents