7 

 

 

 

BAB 2

LANDASAN TEORI

2.1 Teori-teori Dasar/Umum

2.1.1 Pengertian Data dan Informasi

Data adalah komponen paling penting DBMS environment dari

sudut pandang end-user. Data bertindak sebagai jembatan penghubung

antara komponen mesin dan manusia. Basis data terdiri dari data operational

dan metadata. (Connoly dan Begg, 2005, p70)

Menurut Whitten, data adalah fakta mentah mengenai tempat,

orang, kejadian, dan hal-hal yang penting dalam organisasi(Whitten, 2004,

p23). Informasi adalah data yang telah diproses atau diorganisasi ulang

menjadi bentuk yang berarti. Informasi dibentuk dari kombinasi data yang

diharapkan memiliki arti ke penerima. (Whitten, 2004, p23)

Hubungan antara data dan informasi tidak dapat saling di tukar

pemakaiannya. Nilai suatu informasi berhubungan dengan keputusan. Bila

tidak ada pilihan atau keputusan, informasi menjadi tidak diperlukan.

2.1.2 Pengertian Basis Data

Menurut Connoly database atau basis data adalah kumpulan data

yang dihubungkan secara bersama-sama, dan gambaran dari data yang

dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi.

(Connoly dan Begg, 2005, p65)

8 

 

 

 

Sedangkan menurut C.J. Date database adalah koleksi “data

operasional” yang tersimpan dan dipakai oleh sistem aplikasi dari suatu

organisasi. (C.J. Date, 1990, p5)

Data dalam basis data disimpan dalam 3 struktur, yaitu file, tabel,

dan objek. File terdiri dari record dan field, tabel terdiri dari baris dan

kolom. Objek terdiri dari data dan instruksi program yang memfungsikan

data. Tabel terdiri dari kolom-kolom yang saling terkait.

2.1.3 Pengertian DBMS

DBMS (Database Management System) menurut Connoly dan

Begg adalah suatu sistem perangkat lunak yang memungkinkan user untuk

mendefinisikan, membuat, dan memelihara basis data dan menyediakan

akses kontrol terhadap basis data. (Connoly dan Begg, 2005, p66)

Secara khusus DBMS menyediakan fasilitas berikut ini :

• DDL (Data Definition Language), memberikan fasilitas kepada user

untuk menspesifikasikan tipe data dan strukturnya serta batasan aturan

mengenai data yang bisa disimpan ke dalam basis data tersebut.

• DML (Data Manipulation Language), memberikan fasilitas kepada

user untuk menambah, mengedit, menghapus, serta memperoleh

kembali data dari basis data.

• Pengendalian akses ke dalam basis data, meliputi :

i. Keamanan sistem : mencegah user yang tidak memilik hak akses

untuk memasuki basis data.

ii. Integritas sistem : menjaga konsistensi data dalam basis data.

9 

 

 

 

iii. Pengendalian sistem recovery : mengembalikan data ke dalam

kondisi semula apabila terjadi kegagalan dalam perangkat keras

ataupun perangkat lunak.

iv. Pengendalian sistem yang concurent, mengizinkan akses basis

data secara bersama-sama oleh user.

v. Catalog yang dapat diakses user, yang berisi deskripsi data

dalam basis data.

2.1.4 Komponen DBMS

Menurut (Connoly dan Begg, 2005, p68) terdapat 5 komponen

utama dalam lingkungan DBMS yaitu :

1. Perangkat keras (hardware)

Perangkat keras yang berupa PC tunggal, atau suatu mainframe, atau

juga suatu jaringan komputer yang dibutuhkan DBMS dan aplikasinya

untuk dijalankan.

2. Perangkat lunak (software)

Komponen perangkat lunak DBMS itu sendiri dan aplikasi

programnya yang bekerja bersama-sama dengan sistem operasi,

mencakup perangkat lunak jaringan jika DBMS digunakan pada suatu

jaringan.

10 

 

 

 

3. Data

Komponen terpenting dari DBMS yang menggambarkan sudut

pandang end-user yang bertindak sebagai suatu jembatan penghubung

antara komponen mesin dan komponen manusia.

4. Prosedur

Prosedur memuat instruksi dan aturan yang mengatur desain dan

penggunaan database. Para pemakai sistem database memerlukan

dokumentasi prosedur yang berisi cara menggunakan atau

menjalankan sistem itu.

5. People

Orang-orang yang memiliki keterkaitan dengan sistem database

tersebut, yang meliputi :

a. Data administrator (DA), mengatur sumber daya data antara lain:

perancangan basis data, pengembangan dan pemeliharaan

standar, kebijakan, prosedur, dan desain basis data konseptual

dan logikal.

b. Database Administrator (DBA), mengatur realisasi fisik dari

aplikasi database yang meliputi desain fisik basis data,

implementasi, pengaturan keamanan dan kontrol integritas,

pengawasan performa sistem dan pengaturan ulang basis data.

c. Desainer basis data logikal yang berhungan dengan identifikasi

data yaitu entitas dan atribut-atributnya serta hubungan antar-

data dan batasan-batasan dari data yang akan di simpan ke dalam

11 

 

 

 

database. Dan desainer basis data fisikal yang memutuskan

bagaimana desain basis data yang secara fisik dapat diwujudkan.

d. Programer aplikasi, bertanggung jawab untuk menyediakan

fungsionalitas yang diperlukan untuk pengguna akhir dari basis

data yang sudah diimplementasikan.

e. Pengguna akhir(end-user)

Merupakan client dari database. Pengguna akhir dapat

diklasifikasikan berdasarkan bagaimana mereka menggunakan

sistem.

• Naive : user yang tidak tahu mengenai basis data dan DBMS

dan hanya menggunakan aplikasinya saja.

• Sophisticated : user yang terbisa dengan struktur basis data

dan DBMS.

2.1.5 Keuntungan dan kerugian dari penggunaan DBMS

Menurut (Connoly dan Begg, 2005, p77) keuntungan penggunaan

DBMS, antara lain:

a. Kontrol atas redudansi atau perulangan data.

b. Konsistensi data.

c. Informasi yang diperoleh dari data yang sama lebih banyak.

d. Data dapat digunakan bersama-sama.

e. Meningkatkan integritas data.

f. Meningkatkan keamanan data.

12 

 

 

 

g. Penetapan standarisasi pelaksanaan (format data, penamaan, prosedur

update).

h. Pengurangan biaya

i. Mempermudah pengoperasian data.

j. Meningkatkan aksesibilitas dan respon data.

k. Meningkatkan produktivitas.

l. Meningkatkan pemeliharaan data melalui data independence (data

menjadi global).

m. Mengurangi kehilangan informasi dan integritas data.

n. Meningkatkan layanan backup dan recovery.

Sedangkan kerugiannya menurut (Connolly dan Begg, 2005, p80) yaitu :

a. Kompleksitas.

b. Ukuran.

c. Biaya dari penggunaan DBMS.

d. Biaya penambahan perangkat keras.

e. Biaya konversi data.

f. Dampak kegagalan cukup besar.

2.1.6 Metodologi siklus hidup pengembangan aplikasi database (DatabaseSystem Development Lifecycle)

Menurut (Connoly dan Begg, 2005, p313), sistem basis data

merupakan komponen dasar dari organsasi yang lebih besar dengan sistem

informasi yang lebih luas.

13 

 

 

 

Hal yang penting yang perlu diketahui adalah bahwasanya tahapan-

tahapan dalam siklus pengembangan sistem basis data tidak sepenuhnya

harus berurutan, tetapi melibatkan beberapa pengulangan dari tahapan

sebelumnya melalui umpan balik (feed back loops).

Gambar berikut menggambarkan tahapan-tahapan Database System

Development Lifecycle :

Gambar 2.1 Database lifecycle

(Sumber : Connolly, 2005, p285)

14 

 

 

 

Perencanaan Basis data (Database Planning)

Merupakan aktivitas management yang memungkinkan tahapan-

tahapan dari siklus hidup pengembangan basis data direalisasikan seefisien

dan seefektif mungkin. Perencanaan basis data harus terintegrasi dengan

seluruh strategi sistem informasi dari suatu organisasi. Terdapat 3 isu pokok

yang terlibat dalam perumusan strategi sistem informasi.

• Identifikasi rencana dan sasaran dari perusahaan termasuk menentukan

kebutuhan sistem informasi.

• Mengevaluasi sistem informasi yang ada untuk menentukan kelebihan

dan kelemahan yang ada

• Memperkirakan kesempatan teknologi informasi yang dapat

menghasilkan keuntungan yang kompetitif.

Langkah pertama yang terpenting dalam perencanaan basis data

adalah mendefinisikan secara jelas mission statement untuk sistem basis

data. Mission statement mendefinisikan tujuan utama dari sistem basis data.

Mission statement membantu untuk menjelaskan tujuan dari proyek basis

data dan menyediakan garis yang jelas bagi pembuatan sistem basis data

yang dibutuhkan secara efektif dan efisien.

Setelah mission statement didefinisikan, aktivitas selanjutnya terkait

pengidentifikasian mission objectives. Setiap mission objectives akan

menetapkan tugas khusus yang didukung oleh sistem basis data. Dengan

15 

 

 

 

asumsi bahwa jika sistem basis data mendukung mission objectives, maka

mission statement akan didapat.

Pendefinisian sistem (system definition)

Pendefinisian sistem menggambarkan cakupan dan batasan dari

sistem basis data dan sudut pandang para pengguna (user view).

User view mendefinisikan apa yang dibutuhkan oleh sistem basis

data dari sudut padang jabatan tertentu misalnya, manajer atau supervisor,

atau bidang perusahaan tertentu misalanya marketing, personalia, dan

kontrol stok barang.

Sebelum merancang sistem basis data, diperlukan identifikasi

batasan sistem yang kita selidiki dan bagaimana interface-nya dengan

bagian-bagian lain dari sistem informasi suatu organisasi. Dan yang

terpenting bagaimana sistem dibuat tidak hanya mencakup pengguna dan

aplikasi sekarang tetapi juga untuk aplikasi yang akan datang.

Aplikasi basis data dapat memiliki satu atau lebih user view.

Mengidentifikasi user view merupakan aspek penting dalam pengembangan

basis data karena membantu untuk memastikan bahwa tidak ada pengguna

utama basis data yang terlupakan ketika mengembangkan kebutuhan untuk

aplikasi basis data yang baru.

16 

 

 

 

Pengumpulan dan analisis kebutuhan (requirement collection and

analysis)

Pengumpulan dan analisis kebutuhan adalah proses pengumpulan

dan penganalisaan informasi tentang bagian-bagian dari organisasi yang

akan didukung oleh sistem basis data, dan menggunakan informasi tersebut

untuk mengidentifikasi kebutuhan sistem yang baru.

Teknik atau cara untuk mendapatkan informasi adalah dengan

teknik Fact Finding. Fact Finding adalah teknik yang digunakan untuk

mengidentifikasi kebutuhan. Beberapa contoh teknik Fact Finding antara

lain : mempelajari dokumen perusahaan, wawancara, pengamatan terhadap

kegiatan perusahaan (observasi), penelitian (research), dan kuisioner.

Tiap informasi tersebut diambil dari setiap user view yang penting yaitu :

a. Deksripsi mengenai data yang digunakan atau dihasilkan.

b. Detail mengenai bagaimana data tersebut digunakan atau dihasilkan.

c. Kebuthan-kebutuhan tambahan lain untuk sistem basis data yang baru.

Hal penting lainnya yang terkait dengan tahap ini adalah

memutuskan bagaimana menghadapi situasi dimana terdapat lebih dari satu

user view untuk sistem basis data. Terdapat tiga pendekatan yagn digunakan

untuk mengatur kebutuhan-kebutuhan sistem basis data dengan multiple user

view :

17 

 

 

 

• Centralized approach

Kebutuhan-kebutuhan untuk setiap user view digabungkan menjadi

satu perangkat kebutuhan untuk sistem basis data yang baru.

• View integration approach

Kebutuhan-kebutuhan untuk setiap user view digunakan untuk

membangun model data terpisah yang akan merepresentasikan user

view tersebut. Hasil dari model data kemudian digabungkan pada tahap

perancangan basis data.

• Combination of both approaches

Merupakan kombinasi dari centralized approach dan view integration

approach yang digunakan untuk beberapa sistem basis data yang

kompleks.

Perancangan basis data (Database design)

Perancangan basis data adalah proses pembuatan rancangan basis

data yang akan mendukung misi dan sasaran perusahaan untuk sistem basis

data yang dibutuhkan. Ada dua pendekatan utama yang digunakan dalam

perancangan basis data, yaitu :

− Bottom-up approach

Pendekatan ini dimulai dari level paling dasar yaitu atribut (property

dari entitas dan hubungan relasional), dimana melalui analisis

gabungan antara atribut-atribut dikelompokkan ke dalam relasi-relasi

yang mewakili tipe-tipe entitas dan hubungannya. Pendekatan ini

18 

 

 

 

biasanya digunakan ketika akan merancang basis data yang sederhana

dengan atribut dalam jumlah yang sedikit.

− Top-down approach

Pendekatan ini dimulai dari pengembangan dari model data yang

terdiri daari beberapa entitas tingkat tinggi dan hubungan-

hubungannya dan kemudian diterapkan pendekatan top-down berturut-

turut untuk mengidentifikasi entitas pada level terendah, hubungan-

hubungannya, dan atribut lainnya.

− Inside-out

Berhubungan dengan pendekatan bottom-up, tetapi sedikit berbeda

dengan identifikasi awal entitas utama dan kemudian menyebar ke

entitas, relationship, dan atribut terkait lainnya yang lebih dulu

diidentifikasi.

− Mixed

Menggunakan pendekatan bottom-up dan top-down untuk bagian-

bagian yang berbeda sebelum pada akhirnya digabungkan.

Perancangan basis data terdiri dari tiga tahap utama, yaitu

Perancangan basis data conceptual (Conceptual database design)

Merupakan proses pembangunan sebuah model data yang akan

digunakan oleh suatu perusahaan, tetapi terlepas dari semua

pertimbangan fisik.

19 

 

 

 

Perancangan basis data logikal (Logical database design)

Merupakan proses pembangunan sebuah model data yang akan

digunakan oleh perusahaan berdasarkan spesifik model data, terbebas

dari keterikatan DBMS dan pertimbangan fisik lainnya.

Perancangan basis data fisikal (Physical database design)

Merupakan proses untuk memproduksi sebuah deskripsi dari

implementasi basis data dalam media penyimpanan sekunder

(secondary storage), yang menggambarkan relasi-relasi dasar,

organisasi file, serta index untuk mencapai akses yang efisien terhadap

data, dan setiap kendala yang terkait integritas dan pengukuran

keamanan.

Pemilihan DBMS (DBMS Selection)

Menurut Connolly dan Begg (2005, p295), pemilihan DBMS adalah

sebuah proses penyeleksian suatu DBMS yang tepat untuk mendukung

sistem basis data. Langkah-langkah utama dalam penyeleksian DBMS :

a. Mendefinisikan lama waktu belajar, istilah referensi dalam

penyeleksian DBMS yang sudah ditetapkan, pernyataan tujuan dan

ruang lingkup pembelajaran, serta tugas-tugas yang harus dilakukan.

b. Membuat daftar pendek untuk dua atau tiga produk DBMS, kriteria

yang dianggap ‘penting’ agar impelementasi dapat berjalan dengan

sukses yang mana dapat digunakan untuk menghasilkan daftar awal

produk-produk DBMS untuk evaluasi. Sebagai contoh, keputusan

untuk memasukkan sebuah produk DBMS mungkin bergantung pada

20 

 

 

 

anggaran yang tersedia, tingkat dukungan dari vendor, kesesuaian

dengan perangkat lunak lainnya, dan apakah produk tersebut berjalan

pada perangkat keras tertentu.

c. Mengevaluasi produk

Ada berbagai fitur yang dapat digunakan untuk mengevaluasi produk

DBMS. Untuk tujuan evaluasi tersebut, fitur-fitur ini dapat dinilai

secara kelompok (sebagai contoh, definisi data) atau secara individual

(sebagai contoh, ketersediaan tipe data).

d. Merekomendasikan produk DBMS yang terpilih dan membuat laporan

Ini merupakan tahap akhir dari pemilihan DBMS yaitu

mendokumentasikan proses-proses yang terjadi dan menyediakan

pernyataan untuk merekomendasikan produk DBMS yang terpilih.

Perancangan aplikasi (Application design)

Pada tahap ini kita akan merancang antarmuka pengguna dan

program aplikasi yang menggunakan dan memproses basis data. Harus dapat

dipastikan bahwa semua fungsionalitas yang ditetapkan dalam spesifikasi

kebutuhan ‘user’ ada dalam desain aplikasi untuk sistem basis data. Ini

melibatkan perancangan program aplikasi yang mengakses basis data dan

perancangan transaksi. Pada bagian berikut ini, akan dijelaskan dua aspek

perancangan aplikasi, yaitu :

21 

 

 

 

• Perancangan transaksi (transaction design)

Menurut (Connolly dan Begg, 2005, p300), transaksi dapat diartikan

sebagai sebuah aksi, atau serangkaian tindakan yang dilakukan oleh

satu pengguna atau program aplikasi yang mengakses atau mengubah

isi basis data.

Tujuan dari perancangan transaksi adalah untuk mendefinisikan dan

mendokumentasikan karakteristik high-level daru suatu transaksi yang

dibutuhkan pada basis data, termasuk didalamnya :

1. Data yang akan digunakan oleh suatu transaksi.

2. Karakteristik fungsional dari suatu transaksi.

3. Output dari transaksi.

4. Kepentingan bagi pengguna.

5. Tingkat kegunaan yang diharapkan.

• Perancangan antarmuka pengguna

Aturan-aturan pokok dalam pembuatan desain antarmuka pengguna:

a. Informasi yang disampaikan pada judul harus jelas dan tidak

ambigu.

b. Perintah harus ditulis dalam gaya gramatikal yang konsisten dan

sesuai dengan format yang standar.

c. Bagian-bagian yang saling berkaitan harus diposisikan secara

bersama-sama pada formulir atau laporan dan juga urutan bagian-

bagian tersebut harus logis dan konsisten.

22 

 

 

 

d. Formulir atau laporan harus disajikan dalam bentuk yang menarik

bagi pengguna.

e. Label field harus mudah dimengerti.

f. Daftar yang telah disepakati dalam istilah yang familiar dan

singkatan-singkatan harus digunakan secara konsisten.

g. Warna yang digunakan haruslah konsisten dan memiliki makna.

h. Pengguna haruslah secara visual menyadari total jumlah ruang

yang tersedia untuk setiap field.

i. Operasi yang diperlukan untuk memindahkan kursor ke seluruh

formulir atau laporan.

j. Operasi yang dibutuhkan untuk melakukan perubahan nilai harus

mudah diidentifikasi pengguna.

k. Pesan eror harus ditampilkan ketika pengguna melakukan

kesalahan.

l. Field-field yang opsional harus dapat dengan mudah diidentifikasi

secara jelas oleh pengguna.

m. Informasi tentang field harus ditampilkan pada posisi yang regular

pada layar.

n. Ketika proses pengisian pada field dalam formulir telah dilakukan,

maka harus jelas bagi pengguna bahwa seluruhnya telah lengkap

diisi.

23 

 

 

 

Prototyping (opsional)

Prototyping adalah sebuah proses membangun model kerja (model

working) dari sistem basis data. Sebuah prototype merupakan sebuah model

kerja yang tidak secara normal memiliki semua fitur-fitur yang dibutuhkan

atau menyediakan semua fungsionalitas dari akhir suatu sistem. Tujuan

utama dalam mengembangkan sebuah prototyping sistem basis data adalah

untuk mengizinkan para pengguna untuk menggunakan prototype untuk

mengidentifikasi fitur-fitur dari sustem yang telah bekerja dengan baik, dan

jika memungkinkan untuk memberikan saran perbaikan atau fitur-fitur baru

untuk sistem basis data.

Implementasi (implemetation)

Implementasi merupakan perwujudan secara fisik dari sistem basis

data dan perancangan aplikasi. Implementasi basis data dapat dicapai dengan

menggunakan Data Definition Language (DDL) dari DBMS yang dipilih

atau Graphical User Interface (GUI), yang mana menyediakan fungsionalitas

yang sama saat menyembunyikan low level pernyataan DDL.

Program aplikasi yang diimplementasikan menggunakan bahasa

tingkat ke-tiga atau ke-empat yang disukai. Bagian dari program aplikasi ini

adalah transaksi basis data, yang mana diimplementasikan menggunakan

Data Manipulation Language (DML) dari target DBMS.

24 

 

 

 

Pengubahan dan pemuatan data (Data conversion and loading)

Pengubahan dan pemuatan data adalah memindahkan setiap data

yang ada ke dalam basis data yang baru dan mengubah semua aplikasi yang

ada untuk dapat dijalankan pada basis data yang baru.

Uji coba (Testing)

Uji coba merupakan proses dalam menjalankan sistem basis data

dengan maksud menemukan kesalahan-kesalahan yang ada. Sebelum

digunakan, aplikasi basis data yang baru dikembangkan harus diuji coba

secara menyeluruh terlebih dahulu. Dalam perancangan basis data, para

pengguna yang akan menggunakan sistem yang baru harus dilibatkan dalam

proses uji coba. Untuk menguji coba sistem secara ideal adalah dengan

menguji basis data yang baru pada perangkat keras yang berbeda.

Pengujian juga diharuskan mencakup kegunaan dari sistem basis

data. Idealnya, sebuah evaluasi harus dilakukan terhadap spesifikasi

kegunaan. Contoh kriteria yang dapat digunakan untuk melakukan evalusi

antar lain (Sommerville, 2002) :

• Mudah untuk dipelajari – berapa lama pengguna baru menjadi

produktif dengan sistem yang baru ?

• Performa – seberapa baik sistem tersebut merespon sesuai dengan

praktik kerja pengguna ?

• Kekuatan – seberapa tolerankah sistem dapat bertahan dari kesalahan

pengguna ?

25 

 

 

 

• Kemampuan pemulihan – seberapa baik sistem saat pemulihan dari

kesalahan pengguna ?

• Kemampuan beradaptasi – seberapa dekat sistem terkait dengan

model tunggal kerja ?

Perawatan operasional (Operational maintenance)

Merupakan proses memonitor dan merawat sistem setelah instalasi

sistem basis data dilakukan. Pada tahapan sebelumnya, sistem basis data

secara penuh telah diimplementasikan dan diujicobakan. Kemudian

sekarang, sistem melangkah pada tahapan perawatan, yang melibatkan

aktivitas-aktivitas berikut ini :

• Memonitor kinerja dari sistem. Apabila kinerja sistem tersebut turun di

bawah tingkat yang dapat diterima, penyetelan atau reorganisasi basis

data mungkin diperlukan.

• Pemeliharaan dan mengupgrade sistem basis data (ketika dibutuhkan).

Kebutuhan-kebutuhan baru yang tergabung ke dalam sistem basis data

melalui tahapan sebelumnya dari siklus hidup.

2.1.7 Metodologi perancangan basis data

Sebuah metodologi perancangan adalah pendekatan terstruktur yang

menggunakan prosedur-prosedur, teknik-teknik, alat-alat, dan dokumentasi

tambahan untuk mendukung dan memfasilitasi proses dari perancangan.

26 

 

 

 

2.1.7.1 Perancangan Basis Data Konseptual

Langkah 1 Membangun model data konseptual

Langkah pertama pada perancangan basis data konseptual adalah

membangun sebuah atau lebih model data dari informasi-informasi

mengenai perusahaan. Langkah-langkah dalam membangun model data

konseptual terdiri dari :

Langkah 1.1 Mengidentifikasi tipe-tipe entitas

Langkah pertama dalam membangun sebuah model data

konseptual adalah mendefinisikan objek-objek utama yang mana user

membutuhkannya. Objek-objek tersebut adalah tipe-tipe entitas untuk

model tersebut. Salah satu metode mengidentifikasi entitas-entitas adalah

memeriksa spesifikasi kebutuhan-kebutuhan user. Dari spesifikasi ini,

kita dapat mengidentifikasi kata benda dan frase-frasenya yang telah

disebutkan.

Gambar 2.2 Identifikasi tipe entitas

(Sumber Connolly, 2005, p444)

27 

 

 

 

Langkah 1.2 Mengidentifikasi tipe-tipe relasi

Setelah pengidentifikasian entitas, langkah berikutnya adalah

mengidentifikasi seluruh relasi yang ada di antara entitas-entitas ini.

Khasnya, relasi-relasi dapat ditunjukkan dengan kata kerja atau ekpresi

verbal. Dalam kebanyakan instance, relasi-relasi adalah biner; dengan

kata lain, relasi-relasi ada di antara tepat dua tipe entitas.

Gambar 2.3 Identifikasi tipe relasi (Sumber Connolly, 2005, 447)

Langkah 1.3 Mengidentifikasi dan menghubungkan atribut-atribut dengan entitas atau tipe relasi

Langkah berikutnya dalam adalah mengidentifikasi tipe-tipe

fakta tentang entitas dan relasi yang telah dipilih untuk ditampilkan ke

dalam basis data. Dengan cara yang sama untuk mengidentifikasi entitas,

maka dicari nomina dan frasa nomina dalam spesifikasi kebutuhan user.

Atribut-atribut tersebut dapat diidentifikasi ketika nomina atau frasa

nomina adalah sebuah properti, kualitas, identifier, atau karakteristik dari

salah satu entitas atau relasi tersebut.

28 

 

 

 

Gambar 2.4 Identifikasi atribut-atribut beserta relasinya

(Sumber : Connolly, 2005, p447)

Langkah 1.4 Menentukan domain atribut

Tujuan dari langkah ini adalah menentukan domain-domain

untuk seluruh atribut dalam model tersebut. Sebuah domain adalah

sekumpulan nilai-nilai dari satu atribut atau lebih yang telah diambil

nilainya. Model data sepenuhnya dikembangkan dalam menentukan

domain untuk setiap atribut dan termasuk didalamnya :

a. Set nilai untuk atribut yang diijinkan.

b. Ukuran dan format atribut.

c. Menentukan atribut-atribut candidate key, primary key, dan alternate

key

Langkah ini terkait dengan pengidentifikasian candidate key

untuk sebuah entitas dan kemudian memilih satu untuk menjadi primary

key. Sebuah candidate key adalah seperangkat set atribut dari sebuah

entitas yang secara unik mengidentifikasi setiap kemunculan dari entitas

29 

 

 

 

tersebut. Candidate key dapat diidentifikasi lebih dari satu, namun dalam

hal ini pemilihan primary key hanya diidentifikasi satu saja. Candidate

key yang tersisa disebut alternate key.

Pada saat pemilihan sebuah primary key diantara candidate key

yang ada, maka pedoman untuk melakukan pemilihan adalah sebagai

berikut :

• Candidate key dengan minimal seperangkat set atribut.

• Candidate key yang paling tidak mungkin memiliki nilai yang dapat

berubah.

• Candidate key dengan karakter yang paling sedikit.

• Candidate key dengan nilai maksimum yang terkecil.

• Candidate key yang paling mudah digunakan dari sudut pandang

user.

30 

 

 

 

Gambar 2.5 ERD dengan primary key

(Sumber : Connolly, 2005, p452)

Langkah 1.6 Mempertimbangkan penggunaan konsep enhanced modeling (bersifat opsional)

Pada langkah ini, yang bersifat opsional (pilihan) dalam

melanjutkan pengembangan dari model ER (Entity Relationship)

menggunakan konsep pemodelan lanjutan, seperti

spesialisasi/generalisasi, agregasi, dan komposisi. Pada pendekatan

spesialisasi, maka upaya yang digunakan untuk menyoroti perbedaan

31 

 

 

 

entitas-entitas adalah dengan mendefinisikan satu atau lebih sub-class

dari sebuah entitas super-class.

Pada pendekatan generalisasi, upaya yang digunakan untuk

mengidentifikasi fitur-fitur umum diantara entitas adalah dengan

menetapkan sebuah generalisasi entitas super-class. Penggunaan agregasi

untuk menunjukkan sebuah relasi ‘memiliki sebuah..’ atau ‘bagian dari..’

antara tipe-tipe entitas yang ada, dimana yang satu merupakan

keseluruhan dan yang lainnya merupakan bagian. Penggunaan komposisi

untuk menunjukkan sebuah sebuah perkumpulan antara tipe-tipe entitas

yang mana terdapat sebuah kepemilikan yang kuat dan sepanjang waktu

antara keseluruhan dan bagian.

32 

 

 

 

Staff

staffNo

BusinessOwner

ownerNo

PropertyForRent

propertyNo

PrivateOwner

ownerNo

Client

clientNo

Lease

leaseNo

PreferenceviewDatecomment

1..1

0..10

0..1

0..100

0..* 0..*

1..1

0..* 0..*

1..1 1..1

1..1

Registers

Supervises

Views

AssosiatedWith Holds

States

Supervisor

Owner

ownerNo

Owns

1..*

1..1

{Mandatory,or}

1..1

0..*

Manages

Gambar 2.6 ERD dengan menggunakan spesialisasi/generalisasi (Sumber : Connolly, 2005, p454)

Langkah 1.7 Memeriksa model terhadap redundansi

Pada langkah ini, dilakukan pemeriksaan terhadap model data

konseptual lokal dengan tujuan spesifik dari pengidentifikasian apakah

terdapat kehadiran rendundan dan penghapusan apapun rendundan yang

tidak ada. Dua aktivitas pada langkah ini adalah :

• Menguji ulang hubungan one to one (1:1)

33 

 

 

 

• Menghapus relasi-relasi yang rendundan.

• Mempertimbangkan dimensi waktu.

PropertyForRent

propertyNo

Client

clientNo

Lease1

leaseNo

0..* 0..*

1..1

0..* 0..*

1..1

Rents

AssosiatedWith Holds

Remove the rendundant relationship called Rents

Gambar 2.7 ERD dengan menghilangkan rendundansi

(Sumber : Connolly, 2005, p455)

Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna

Tujuan utama dari langkah ini adalah memeriksa model yang ada

untuk memastikan bahwa model tersebut telah mendukung transaksi-

transaksi yang dibutuhkan. Terdapat dua kemungkinan pendekatan yang

digunakan untuk langkah ini :

• Menggambarkan transaksi tersebut.

• Menggunakan jalur transaksi.

34 

 

 

 

Staff

staffNo

BusinessOwner

ownerNo

PropertyForRent

propertyNo

PrivateOwner

ownerNo

Client

clientNo

Lease

leaseNo

PreferenceviewDatecomment

1..1

0..10

0..1

0..100

0..* 0..*

1..1

0..* 0..*

1..1 1..1

1..1

Registers

Supervises

Views

AssosiatedWith Holds

States

Supervisor

Owner

ownerNo

Owns

1..*

1..1

{Mandatory,or}

Manages

(a)

(b)

(c),(g)

(e)

(m)

(h),(i)

(d)

(f)(m)

(j)(l)

(k)

Gambar 2.8 ERD degan penggambaran jalur transaksi

(Sumber : Connolly, 2005, p457)

Langkah 1.9 Meninjau model data konseptual dengan user

Sebelum melengkapi keseluruhan metodologi ini, dilakukan

peninjauan model data konseptual dengan user. Model data konseptual

mencakup diagram ER dan dokumentasi pendukung yang

menggambarkan model data tersebut. Bila muncul perbedaan (anomali),

35 

 

 

 

maka harus dilakukan perubahan, yang mungkin memerlukan

pengulangan langkah-langkah sebelumnya.

2.1.7.2 Perancangan Basis Data Logikal

Langkah 2 Membangun dan memvalidasi model data logikal

Setelah membuat rancangan basis data konseptual maka

dilakukan langkah kedua yaitu membuat dan memvalidasi model data

logikal. Tujuan dari tahap ini adalah menerjemahkan model data

konseptual ke dalam model data logikal dan kemudian melakukan

validasi model ini untuk memeriksa bahwa secara struktural model ini

mampu mendukung transaksi yang diperlukan. Tahapan-tahapan dalam

perancangan basis data logikal yaitu :

Langkah 2.1 Menurunkan relasi untuk model data logikal

Tujuan dari proses ini adalah membuat relasi untuk model data

logikal untuk menunjukkan entitas, relasi, dan atribut yang telah

diidentifikasi. Komposisi dari setiap relasi dideskripsikan menggunakan

Database Definition Language (DBDL) untuk basis data relasional.

Langkah-langkah dalam proses ini adalah

1. Menentukan tipe entitas kuat.

2. Menentukan tipe entitas lemah.

3. Menentukan one to many (1:*) tipe relasi binary.

4. Menentukan one to one (1:1) tipe relasi binary.

5. Menentukan one to one (1:1) tipe relasi recursive.

6. Menentukan superclass/subclass tipe relasi.

36 

 

 

 

7. Menghilangkan many to many (*:*) tipe relasi binary.

8. Menghilangkan tipe relasi kompleks.

9. Menghilangkan atribut multi-valued.

Langkah 2.2 Memvalidasi relasi menggunakan normalisasi.

Tujuan dari langkah ini adalah untuk memastikan bahwa

sekumpulan relasi memiliki jumlah minimal dan memadai dari atribut

yang diperlukan untuk mendukung kebutuhan data dari perusahaan.

Menurut Connoly (2005, p326), normalisasi adalah sebuah teknik untuk

menghasilkan kumpulan relasi yang diinginkan berdasarkan kebutuhan

data suatu organisasi. Bentuk-bentuk dalam normalisasi yaitu :

1. Bentuk tidak normal (UNF)

UNF adalah sebuah tabel yang berisi satu atau lebih kelompok-

kelompok yang berulang.

2. Bentuk normal pertama (1NF)

Suatu relasi dimana setiap perpotongan antara kolom dan baris

hanya mengandung satu nilai saja

3. Bentuk normal kedua (2NF)

Suatu relasi yang berbentuk 1NF dan setiap atribut yang bukan

primary key yang bergantung secara fungsional sepenuhnya

terhadap primary key.

4. Bentuk normal ketiga (3NF)

Suatu relasi yang berada dalam 1NF dan 2NF yang bergantung

secara transitif kepada primary key.

37 

 

 

 

Langkah 2.3 Memvalidasi relasi terhadap transaksi user.

Tujuan dari langkah ini adalah untuk memastikan bahwa relasi

dalam model data logikal mendukung transaksi yang dibutuhkan oleh

user.

Langkah 2.4 Memeriksa integrity constraint.

Yang dimaksud integrity constraint adalah aturan yang kita ingin

paksa untuk melindungi basis data dari ketidaklengkapan,

ketidakakuratan, atau ketidakkosistenan. 6 tipe integrity constraint :

a. Data yang dibutuhkan (required data).

b. Batasan domain atribut.

c. Integritas entitas (primary key tidak boleh null).

d. Integritas referensi (foreign key pada suatu entitas harus sesuai

dengan candidate key pada entitas lain).

e. Batasan umum (aturan tambhan yang dibuat user atau seorang

Database Administrator dari basis data tersebut).

Langkah 2.5 Melihat kembali model data logikal dengan user.

Tujuan dari langkah ini adalah untuk memastikan bahwan model

data yang telah dibuat telah sesuai dengan representasi user yang

sebenarnya mengenai kebutuhan data perusahaan.

Langkah 2.6 Menggabungkan model data logikal ke dalam model

model data global.

Langkah ini dibutuhkan hanya untuk perancangan sebuah basis

data dengan multiple-user yang dikelola dengan menggunakan

38 

 

 

 

pendekatan integritas tampilan. Sebuah model data logikal menunjukkan

satu atau lebih tetapi tidak keseluruhan sudut pandang user dari basis data

sebaliknya model data logikal global menunjukkan keseluruhan sudut

pandang user dari sebuah basis data. Pada langkah ini dilakukan

penggabungan dua atau lebih model data logikal lokal ke dalam model

data logikal global tunggal.

Langkah 2.7 Memeriksa perkembangan yang akan datang.

Langkah ini bertujuan untuk memastiakn apakah akan muncul

perubahan yang signifikan yang dapat diperkirakan dan memastikan

apakah model data logikal tersebut dapat mendukung perubahan tersebut.

2.1.7.3 Perancangan Basis Data Fisikal

Perancangan basis data fisikal adalah suatu proses produksi

sebuah deskripsi implemtentasi dari basis data pada tempat penyimpanan

kedua (secondary storage); menggambarkan relasi dasar, organisasi file,

dan indeks yang digunakan untuk mencapai akses yang efisie terhadap

data, dan batasan integritas dan pengukuran keamanan yang telah

diasosiasikan. (Connoly dan Begg, 2005, p496). Metodologi perancangan

basis data fisikal memiliki langkah-langkah sebagai berikut:

Langkah 3 Menerjemahkan model data logikal terhadap DBMS yang telah ditentukan.

Sasaran dari langkah ini adalah untuk menghasilkan suatu skema

basis data relasional dari model data logikal yang dapat

diimplementasikan ke dalam DBMS yang telah ditentukan. Langkah ini

39 

 

 

 

memerlukan pengetahuan yang mendalam tentang fungsi yang

ditawarkan oleh DMBS yang telah ditentukan.

Langkah 4 Merancang organisasi file dan indeks.

Tujuan langkah ini adalah untuk menentukan organisasi file yang

optimal untuk menyimpan hubungan dasar dan indeks yang diperlukan

untuk mencapai kinerja yang dapat diterima, yaitu cara di mana relasi dan

tupel akan ditanggung oleh tempat penyimpanan sekunder.

Langkah 5 Merancang tampilan user.

Tujuan utama langkah ini adalah untuk merancang tampilan

pengguna yang telah teridentifikasi selama pengumpulan kebutuhan dan

tahap analisis dari siklus hidup pengembangan sistem basis data.

Langkah 6 Merancang mekanisme keamanan.

Tujuannya adalah merancang mekanisme keamanan untuk basis

data yang telah dispesifikasikan oleh user selama pengumpulan

kebutuhan dan tahapan dari siklus hidup pengembangan sistem basis data.

2.1.7.4 ER-Modeling

Salah satu aspek yang paling sulit pada perancangan basis data

adalah fakta bahwa perancang, programmer, dan pengguna akhir

memandang data dan kegunaan dari data tersebut dari sudut pandang

yang berbeda. Sayangnya, meskipun dengan memperoleh sebuah

pemahaman yang umum yang mencerminkan bagaimana perusahaan

beroperasi, perancangan yang dihasilkan akan gagal memenuhi kebutuhan

user. Untuk memastikan untuk memperoleh pemahaman yang tepat dari

40 

 

 

 

sifat dasar suatu data dan bagaimana data tersebut digunakan oleh

perusahaan, salah satu model yang digunakan untuk komunikasi yang

bersifat non-teknis dan bebas dari ambiguitas adalah model Entity-

Relationship (ER). Model ER adalah sebuah pendekatan top-down

terhadap perancangan basis data yang dimulai dengan mengidentifikasi

data penting yang disebut entitas dan relasi diantara data yang harus

ditunjukkan dalam model tersebut.

Entity name

Gambar 2.9 Entitas

Tipe Entitas

Tipe entitas adalah sekumpulan objek-objek yang memiliki

properti yang sama, yang didefinisikan oleh perusahaan yang memiliki

keberadaan yang independen. Konsep dasar dari model ER adalah tipe

entitas, yang menunjukkan kumpulan objek pada dunia nyata dengan

properti yang sama. Sebuah tipe entitas memiliki keberadaan yang bebas

dan bisa menjadi objek dengan keberadaan fisik (entitas pegawai, rumah,

dan pelanggan) atau menjadi objek dengan keberadaan konseptual (entitas

inspeksi, penjualan, pembelian)

41 

 

 

 

Entitas 1 Entitas 2

Nama relasi

Relasi

Gambar 2.10 Relasi

Tipe Relasi

Tipe relasi adalah gabungan yang mempunyai arti diantara tipe-

tipe entitas. Setiap tipe relasi diberikan nama sesuai dengan fungsinya.

Relationship occurence adalah suatu gabungan yang dapat diidentifikasi

secara unik, meliputi kejadian dari setiap entitas yang berpartisipasi.

a. Tipe relasi one-to-one (1:1)

Multiplicity

Gambar 2.11 relasi one to one (1:1)

42 

 

 

 

b. Tipe relasi one-to-many (1:*)

Multiplicity

Gambar 2.12 relasi one to many (1:*)

c. Tipe relasi many-to-many (*:*)

Multiplicity

Gambar 2.13 relasi many to many (*:*)

Biasanya sebuah relasi dinamakan menggunakan kata kerja

seperti memiliki atau dengan frase singkat yang meliputi kata kerja

seperti dimiliki oleh. Tanda panah diletakkan di samping nama relasi

yang mengidentifikasikan arah bagi pembaca untuk mengartikan nama

dari sebuah relasi. Kumpulan semua relasi di antara entitas-entitas yang

terdapat pada himpunan entitas membentuk himpunan relasi.

43 

 

 

 

Spesialisasi/generalisasi

Konsep dari spesialisasi/generalisasi diasosiasikan dengan tipe

spesial dari entitas-entitas yang di kenal sebagai superclass dan subclass,

sekaligus proses dari penurunan atribut. Superclass adalah sebuah tipe

entitas yang mencakup satu atau lebih pengelompokan yang berbeda,

yang perlu ditunjukkan dalam sebuah model data. Subclass adalah sebuah

pengelompokan yang berbeda dari kemunculan sebuah tipe entitas, yang

harus ditunjukkan dalam model data.

Manager

mgrStartDatebonus

SalesPersonnel

salesAreacarAllowance

Staff

staffNonamepositionsalary

Secretary

typingSpeed

Subclasses

Superclass

Gambar 2.14 spesialisasi/generalisasi

44 

 

 

 

Flowchart

Flowchart adalah penggambaran secara grafik dari langkah-

langkah dan urutan-urutan prosedur dari suatu program. Flowchart

menolong analis dan programmer untuk memecahkan masalah kedalam

segmen-segmen yang lebih kecil dan menolong dalam menganalisis

alternatif-alternatif lain dalam pengoperasian.

Table 2.1 Simbol-simbol flowchart

Simbol Penjelasan

Simbol dokumen

Simbol yang menyatakan input

berasal dalam bentuk kertas atau

output dicetak ke kertas

Simbol proses

Simbol yang menunjukkan

pengolahan yang dilakukan oleh

komputer.

Simbol keputusan

Simbol untuk kondisi yang

menghasilkan beberapa

kemungkinan jabawan/aksi.

Simbol manual

Simbol yang menunjukkan

pengolahan yang tidak dilakukan

oleh komputer.

Simbol terminal

Simbol untuk menunjukkan

permulaan atau akhir dari suatu

program

45 

 

 

 

2.1.7.5 Arsitektur basis data

File server

Proses didistribusikan ke dalam jaringan sejenis LAN (Local

Area Network). File server mengendalikan file yang diperlukan oleh

aplikasi dan DBMS. Meskipun aplikasi dan DBMS dijalankan pada

masing-masing workstation tetapi tetap meminta file dari file server jika

diperlukan (perhatikan gambar di halaman berikut ini).

Gambar 2.16 Arsitektur file-server

Dengan cara ini, file server berfungsi sebagai sebuah hard disk yang

digunakan secara bersamaan. Kerugian arsitektur file-server adalah :

- Terdapat lalulintas jaringan yang besar.

- Masing-masing workstation membutuhkan copy DBMS.

Kontrol terhadap concurrency, recovery dan integrity menjadi lebih

kompleks karena sejumlah DBMS mengakses file secara bersamaan.

46 

 

 

 

Client Server

Untuk mengatasi kelemahan arsitektur-arsitektur di atas maka

dikembangkan arsitektur client-server. Client-server menunjukkan cara

komponen software berinteraksi dalam bentuk sistem.

Sesuai dengan namanya, ada sebuah pemroses client yang

membutuhkan sumber dan sebuah server yang menyediakan sumbernya.

Tidak ada kebutuhan client dan server yang harus diletakkan pada mesin

yang sama. Secara ringkas, umumnya server diletakkan pada satu sisi

dalam LAN dan client pada sisi yang lain.

Gambar 2.17 Arsitektur Client Server

Dalam konteks database, client mengatur interface berfungsi

sebagai workstation tempat menjalankan aplikasi database. Client

menerima permintaan pemakai, memeriksa sintaks dan generate

kebutuhan database dalam SQL atau bahasa yang lain. Kemudian

47 

 

 

 

meneruskan pesan ke server, menunggu response dan bentuk response

untuk pemakai akhir. Server menerima dan memproses permintaan

database kemudian mengembalikan hasil ke client.

Proses-proses ini melibatkan pemeriksaan autorisasi, jaminan

integritas, pemeliharaan data dictionary dan mengerjakan query serta

proses update. Selain itu juga menyediakan kontrol terhadap concurrency

dan recovery.

Adapun beberapa keuntungan jenis arsitektur ini adalah :

• Memungkinkan akses basis data yang besar.

• Meningkatkan performa.

• Jika client dan server diletakkan pada komputer yang berbeda

kemudian CPU yang berbeda dapat memproses aplikasi secara

paralel. Hal ini mempermudah merubah mesin server jika hanya

memproses basis data.

• Biaya untuk hardware dapat dikurangi.

• Hanya server yang membutuhkan storage dan kekuatan proses yang

cukup untuk menyimpan dan mengatur basis data.

• Biaya komunikasi berkurang.

• Aplikasi menyelesaikan bagian operasi pada client dan

mengirimkan hanya bagian yang dibutuhkan untuk akses basis data

48 

 

 

 

melewati jaringan, menghasilkan data yang sedikit yang akan

dikirim melewati jaringan.

• Meningkatkan kekonsistenan.

• Server dapat menangani pemeriksaan integritas sehingga batasan

perlu didefinisikan dan validasi hanya di satu tempat, aplikasi

program mengerjakan pemeriksaan sendiri.

• Pemetaan ke arsitektur open-system dengan sangat alami.

Berikut ini adalah ringkasan fungsi client-server

Table 2.2 Perbedaan client server

Client Server

Mengatur user interface Menerima dan memproses database yang diminta dari client

Menerima dan memeriksa sintaks input dari pemakai

Memeriksa autorisasi

Memproses aplikasi Menjamin tidak terjadi pelanggaran terhadap integrity constraint

Generate permintaan database dan memindahkannya ke server

Melakukan query/pemrosesan update dan memindahkan respon ke client

Memberikan respon balik kepada pemakai Memelihara data dictionary Menyediakan akses database secara

bersamaan Menyediakan kontrol recovery

49 

 

 

 

Ada beberapa jenis model client – server arsitektur yaitu :

- Two Tier Arsitektur

- Three Tier Arsitektur

Gambar 2.18 Arsitektur Aplikasi Two Tier dan Three Tier

2.2 Teori-teori khusus yang Berhubungan dengan Topik yang Dibahas

2.2.1 SQL Server

Microsoft SQL Server adalah sebuah sistem manajemen basis data

relasional (RDBMS) produk Microsoft. Bahasa query utamanya adalah

Transact-SQL yang merupakan implementasi dari SQL standar ANSI/ISO

yang digunakan oleh Microsoft dan Sybase. Umumnya SQL Server

digunakan di dunia bisnis yang memiliki basis data berskala kecil sampai

dengan menengah, tetapi kemudian berkembang dengan digunakannya SQL

Server pada basis data besar.

Microsoft SQL Server dan Sybase/ASE dapat berkomunikasi lewat

jaringan dengan menggunakan protokol TDS (Tabular Data Stream). Selain

dari itu, Microsoft SQL Server juga mendukung ODBC (Open Database

50 

 

 

 

Connectivity), dan mempunyai driver JDBC untuk bahasa pemrograman

Java. Fitur yang lain dari SQL Server ini adalah kemampuannya untuk

membuat basis data mirroring dan clustering. Pada versi sebelumnya, MS

SQL Server 2000 terserang oleh cacing komputer SQL Slammer yang

mengakibatkan kelambatan akses Internet pada tanggal 25 Januari 2003.

2.2.2 Visual Basic

Microsoft Visual Basic (sering disingkat sebagai VB saja)

merupakan sebuah bahasa pemrograman yang menawarkan Integrated

Development Environment (IDE) visual untuk membuat program perangkat

lunak berbasis sistem operasi Microsoft Windows dengan menggunakan

model pemrograman (COM), Visual Basic merupakan turunan bahasa

pemrograman BASIC dan menawarkan pengembangan perangkat lunak

komputer berbasis grafik dengan cepat, Beberapa bahasa skrip seperti Visual

Basic for Applications (VBA) dan Visual Basic Scripting Edition

(VBScript), mirip seperti halnya Visual Basic, tetapi cara kerjanya yang

berbeda.

Para programmer dapat membangun aplikasi dengan menggunakan

komponen-komponen yang disediakan oleh Microsoft Visual Basic

Program-program yang ditulis dengan Visual Basic juga dapat menggunakan

Windows API, tapi membutuhkan deklarasi fungsi luar tambahan. Dalam

pemrograman untuk bisnis, Visual Basic memiliki pangsa pasar yang sangat

luas. Dalam sebuah survey yang dilakukan pada tahun 2005, 62%

51 

 

 

 

pengembang perangkat lunak dilaporkan menggunakan berbagai bentuk

Visual Basic, yang diikuti oleh C++, JavaScript, C#, dan Java.

2.2.3 State Transition Diagram (STD)

Menurut Yourdon (1989, p259) State Transition Diagram

merupakan suatu alat bantu perancangan yang menggambarkan sifat

ketergantungan waktu dari sistem. Komponen utama yang digunakan dalam

diagram transisi adalah :

a. Keadaan sistem (system state)

State merupakan suatu kumpulan keadaan atau atribut yang

mencirikan suatu benda pada waktu atau kondisi tertentu. State

disimbolkan dengan gambar kotak persegi panjang

Gambar 2.19 State

b. Perubahan keadaan (change of state)

Perubahan keadaan digambarkan dengan garis panah

menghubungkan dua keadaan yang berkaitan. Notasinya adalah

52 

 

 

 

Gambar 2.20 Change of state

c. Kondisi dan aksi (condition and action)

Untuk melengkapi diagram transisi diperlukan dua komponen

tambahan, yaitu kondisi dan aksi. Kondisi merupakan penyebab suatu

keadaan berubah, sedangkan aksi yang dilakukan oleh sistem apabila

terjadi perubahan keadaan. Notasinya adalah

State 1

State 2

Gambar 2.21 Kondisi dan aksi

2.2.4 Teori pendukung

Pemesanan

Menurut Kamus Besar Bahasa Indonesia, pemesanaan adalah proses,

perbuatan, cara memesan atau memesankan. Maka pengertian pemesanaan secara

53 

 

 

 

umum yaitu kondisi dimana pembeli melakukan pemesanan terhadap satu atau

lebih barang yang ditawarkan oleh penjual.

Pembelian

Menurut Mulyadi (2001, p299), pembelian digunakan dalam perusahaan

untuk pengadaan barang yang diperlukan oleh perusahaan. Fungsi yang terkait

dalam sistem pembelian, antara lain :

1. Fungsi gudang

Dalam sistem pembelian, fungsi gudang bertanggung jawab untuk

mengajukan permintaan pembelian sesuai dengan posisi persediaan yang

ada di gudang dan untuk menyimpan barang yang telah diterima oleh

fungsi penerimaan.

2. Fungsi pembelian

Dalam prosedur ini, fungsi gudang mengajukan permintaan pembelian

dalam formulir surat permintaan pembelian kepada fungsi pembelian.

3. Fungsi penerimaan barang

Dalam prosedur ini, fungsi penerimaan melakukan pemeriksaan mengenai

jenis, kuantitas dan mutu barang yang diterima dari pemasok dan kemudian

membuat laporan penerimaan barang untuk menyatakan penerimaan

barang dari pemasok tersebut.

Menurut Mulyadi (2001,p301), jaringan prosedur pembentuk sistem

pembelian, antara lain :

1. Prosedur order pembelian

54 

 

 

 

Dalam prosedur ini, fungsi pembelian mengirim surat order pembelian

kepada pemasok yang dipilih dan memberitahukan kepada unit-unit

organisasi lain dalam perusahaan mengenai order pembelian yang

sudah dikeluarkan oleh perusahaan.

2. Prosedur permintaan penawaran harga dan pemilihan pemasok.

Dalam prosedur ini, fungsi pembelian mengirimkan surat permintaan

penawaran harga kepada para pemasok untuk memperoleh informasi

mengenai harga barang dan berbagai syarat pembelian yang lain, untuk

memungkinkan pemilihan pemasok yang akan ditunjuk sebagai

pemasok barang yang diperlukan oleh perusahaan.

3. Prosedur pencatatan harga pokok produk jadi yang dijual

Dalam prosedur ini, sistem penjualan beserta prosedur order penjualan,

prosedur persetujuan kredit, prosedur pengiriman barang, prosedur

penangihan dan prosedur pencatatan piutang mencatat transaksi

penjualan produk jadi (surat order pengiriman dan faktur penjualan).

Estimasi Biaya

Definisi Estimasi biaya adalah seni memperkirakan kemungkinan jumlah

biaya yang diperlukan untuk suatu kegiatan yang didasarkan pada informasi yang

tersedia pada waktu itu, berdasarkan definisi, tersebut maka perkiraan biaya

mempunyai pengertian sebagai berikut :

• Estimasi biaya yaitu melihat, memperhitungkan dan mengadakan

perkiraan atas hal –hal yang akan terjadi selanjutnya

55 

 

 

 

• Analisis biaya yang berarti pengkajian dan pembahasan biaya yang

pernah ada yang digunakan sebagai informasi yang penting (Iman

Soeharto - National Estimating Society – USA).

Penjualan

Penjualan adalah proses dimana sang penjual memuaskan segala

kebutuhan dan keinginan pembeli agar dicapai manfaat baik bagi sang penjual

maupun sang pembeli yang berkelanjutan dan yang menguntungkan kedua belah

pihak. ( William G.Nickels,1998,10 ).

Menurut Assauri (1992) Kegiatan penjualan merupakan kegiatan

pelengkap atau suplemen dari transaksi, oleh karena itu kegiatan penjualan terdiri

dari serangkaian yang meliputi, menemukan pembeli ,negosiasi harga serta syarat-

syarat pembayaran Dalam hal ini penjual harus menentukan kebijaksanaan dan

prosedur yang akan diikuti untuk memungkinkan dilaksanakannya rencana

penjualan yang telah ditetapkannya .

Penggajian

Penggajian adalah salah satu hal yang penting bagi setiap karyawan yang

bekerja dalam suatu perusahaan, karena dengan gaji yang diperoleh seseorang

dapat memenuhi kebutuhan hidupnya.

Hasibuan (2002, p118) menyatakan bahwa “Gaji adalah balas jasa yang

dibayar secara periodik kepada karyawan tetap serta mempunyai jaminan yang

pasti”. Pendapat lain dikemukakan oleh Handoko (1993, p218), “Gaji adalah

pemberian pembayaran finansial kepada karyawan sebagai balas jasa untuk

pekerjaan yang dilaksanakan dan sebagai motivasi pelaksanaan kegiatan di waktu

56 

 

 

 

yang akan datang” . Selain pernyataan Hasibuan dan Handoko, ada pernyataan

lainnya mengenai gaji dari Hariandja (2002), yaitu Gaji merupakan salah satu

unsur yang penting yang dapat mempengaruhi kinerja karyawan, sebab gaji adalah

alat untuk memenuhi berbagai kebutuhan pegawai, sehingga dengan gaji yang

diberikan pegawai akan termotivasi untuk bekerja lebih giat.

Teori yang lain dikemukakan oleh Sastro Hadiwiryo (1998), yaitu : Gaji

dapat berperan dalam meningkatkan motivasi karyawan untuk bekerja lebih

efektif, meningkatkan kinerja, meningkatkan produktivitas dalam perusahaan,

serta mengimbangi kekurangan dan keterlibatan komitmen yang menjadi ciri

angkatan kerja masa kini. Perusahaan yang tergolong modern, saat ini banyak

mengaitkan gaji dengan kinerja.

Pernyataan tesrsebut juga didukung oleh pendapat Mathis dan Lackson

(2002, p165), “Gaji adalah suatu bentuk kompensasi yang dikaitkan dengan

kinerja individu, kelompok ataupun kinerja organisasi”.