proposal bd rudi

33
PROPOSAL PRAKTIKUM BASIS DATA PERIODE I 2011/ 2012 SISTEM INFORMASI MINIMARKET Oleh : Laboratorium Bahasa Pemrograman RUDI SUSANTO 06.2008.1.04477 HENI KURNIAWAN 06.2008.1.04219 AFIFUDDIN 06.2008.1.90346

Upload: cintametri

Post on 02-Aug-2015

64 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Proposal BD Rudi

PROPOSAL PRAKTIKUMBASIS DATA

PERIODE I2011/ 2012

SISTEM INFORMASI MINIMARKET

Oleh :

Laboratorium Bahasa Pemrograman

Jurusan Teknik Informatika

Fakultas Teknologi Informasi

Institut Teknologi Adhi Tama Surabaya

RUDI SUSANTO 06.2008.1.04477

HENI KURNIAWAN 06.2008.1.04219

AFIFUDDIN 06.2008.1.90346

Page 2: Proposal BD Rudi

2011/ 2012

Page 3: Proposal BD Rudi

KATA PENGANTAR

Syukur alhamdulillah kami panjatkan kehadirat Allah Swt atas limpahan

karunia-Nya sehingga kami dapat menyelesaikan tugas pembuatan rancangan

proposal database dengan judul “Perancangan Sistem Informasi Database

Minimarket“.

Sistem Database Minimarket sangatlah kompleks, mengingat bukan hanya

bagian internal perusahaan yang harus direncanakan desain databasenya,

melainkan pihak ekstern seperti supplier. Selain itu kita juga harus merencanakan

storage yang baik, sehingga bila nantinya ada pengembangan usaha, desain

database ini masih bisa dan layak untuk digunakan. Selain itu, efektifitas dan

efisiensi dalam perancangan desain database ini pun merupakan tolak ukur bagi

kami dalam menyelsaikan proposal ini.

Dalam menyelesaikan Praktikum ini, kami berpegang pada teori yang

pernah kami dapatkan dari Mata Kuliah Basis Data, dan dari Dosen pengajar serta

dari pihak – pihak lain yang sangat membantu kami dalam mempelajari konsep

dan penerapan serta aplikasi Database.

Kami menyadari bahwa masih banyak kekurangan kami dalam

pemahaman dan penguasaan materi Database. Oleh karena itu, besar harapan

kami kepada Kepala Laboratorium dan Assistennya untuk membimbing dan

mengarahkan kami selama mengikuti praktikum. Semoga dengan mengikuti

praktikum ini kami dapat menguasai dan memahami serta dapat membuat aplikasi

Database.

Surabaya, 10 Oktober 2011

Penyusun

Page 4: Proposal BD Rudi

DAFTAR ISI

KATA PENGANTAR i

DAFTAR ISI ii

I. PENDAHULUAN

1

I.1 LATAR BELAKANG 1

I.2 PERMASALAHAN 1

I.3 TUJUAN

II. LANDASAN TEORI

2

II.1 ORACLE 2

II.2 DIAGRAM KONTEKS 4

II.3 DFD LEVEL 11

II.4 DIAGRAM BERJENJANG 12

II.5 DOKUMEN FLOW 21

II.6 ER - DIAGRAM 26

III. URAIAN SISTEM

31

III.1 DESKRIPSI SISTEM 31

III.2 DIGRAM KONTEKS 32

III.3 DFD - LEVEL 33

III.4 CDM + PDM 34

III.5 HIPO 35

III.9 PENJADWALAN PRAKTIKUM 36

Page 5: Proposal BD Rudi

BAB I

PENDAHULUAN

1.1. LATAR BELAKANG

Persaingan yang ketat diantara industri franchised seperti halnya

minimarket, mau tak mau mendorong para pelaku industri tersebut untuk

memberikan pelayanan yang sebaik-baiknya kepada pelanggan, termasuk

penyediaan informasi bagi para supplier, dan penyusunan jadwal distribusi produk

mereka. Hal ini semakin terikat erat dengan pesatnya pula perkembangan

teknologi computer yang mengubah semua proses pencatatatan dan akuntansi

yang awalnya masih bersifat manual menjadi ter-komputerisasi dengan baik.

Sealian di sisi sumber daya material yang sudah siap ‘menyambut’ kelutnya

persaingan di dunia usaha, para pelaku industry juga perlu membekali

kemampuan para pekerjanya untuk bisa mengoperasikan alat-alat dan computer

yang sudah disediakan sebagai media pencatat.

1.2. PERMASALAHAN

Berdasarkan pada uraian dari latar belakang, maka ada beberapa hal yang

perlu dipikirkan oleh seorang system analis database dalam menyusun database

sebuah minimarket yang dipersiapkan untuk berkembang dan maju. Selain

tentunya system database untuk menampung semua jenis dan detail barang yang

akan dijual, namun juga perlu memikirkan system database untuk menampung

data stock barang, data pembelian dan data penjualan, data karyawan dan

penggajian, juga perlu memikirkan system database yang menampung data para

supplier.

Setelah memikirkan rancangan database, seorang system analis database

juga merancang bagaimana flow kerja dari system database tersebut, serta

mungkin perlu dipikirkan desain softwarenya mengingat tampilan yang user

friendly memudahkan proses penginputan dan pengolahan data, sehingga

Page 6: Proposal BD Rudi

meminimalisir factor kesalahan oleh human error. Mengingat begitu kompleksnya

rancangan desain database ini, melatarbelakangi kami dalam menyusun rancangan

databasenya termasuk pula software yang akan menjadi input dan tampilan

pertama bagi end user.

TUJUAN

Adapun tujuan pembuatan Sistem Informasi Minimarket adalah sebagai berikut :

1. Membangun suatu system database yang didukung oleh software yang

handal dan dibangun dengan fasilitas untuk mengolah data minimarket,

dan membuat laporan yang sesuai.

2. Memperbaiki kinerja system database dari sebuah minimarket yang

mungkin masih manual, sehingga membutuhkan waktu lama sehingga

menjadi sebuah informasi yang berguna dalam pengambilan keputusan.

Page 7: Proposal BD Rudi

BAB II

LANDASAN TEORI

2.1. Sekilas Tentang Oracle

Oracle Corporation adalah salah satu perusahaan pembuat software yang

terkenal khususnya pada Database software. Perusahaan ini telah mengeluarkan

banyak versi dari software mulai dari oracle 6.0, 8i, 9i hingga 10g. Produk produk

tersebut biasa digunakan paa skala Enterprise (perusahaan), yang tentu saja

harganya tidak murah bagi kita pengguna individual, lantas bagaimana kita bisa

belajar Oracle dengan harga terjangkau , Oracle memberikan solusi untuk hal

tersebut, Oracle XE merupakan versi freeware yang ditujukan bagi pemula atau

pengguna individual yang ingin mempelajari oracle tanpa harus mengeluarkan

biaya besar atau membajak software tersebut.

Kebutuhan sistem komputer

untuk pengguna widows :

– RAM minimum 256 namun lebih baik lebih

– prosesor pentium 4

– sistem operasi windows XP , server 2003 dan vista.

Struktur Berkas Oracle XE

menggunakan Oracle sebagai aplikasi akan sangat mudah jika kita sudah

memahami struktur dari

oracle tersebut, banyak sekali kesulitan dalam penggunaan oracle hanya

dikarenakan pola fikir yang instant , yaitu langsung ingin menggunakan sebagai

aplikasi, tanpa mengerti seperti apa oracle itu sendiri. Untuk itu anda perlu

melihat gambar berikut ini.

Page 8: Proposal BD Rudi

Gambar diatas memberikan ilustrasi tentang struktur database oracle , pada satu

database Oracle yang sudah terinstall akan memiliki lebih dari satu tablespace.

Tablespace digunakan untuk mengelompokkan data lojik. Sehingga secara

adminstrasi akan lebih mudah mengelola setiap file yang berkaitan dengan

aplikasi. Pada saat instalasi awal dalam direktori $ORACLE_BASE/oradata/ kita

akan mendapatkan 6 buah file data yang memiliki ekstensi

.DBF file tersebut berkaitan dengan Tablespace sebagai berikut.

Page 9: Proposal BD Rudi

II.1.1. DATA FLOW DIAGRAM

Data Flow Diagram (DFD) adalah representasi grafik dari sebuah sistem.

DFD menggambarkan komponen-komponen sebuah sistem, aliran-aliran data di

mana komponen-komponen tersebut, dan asal, tujuan, dan penyimpanan dari data

tersebut.

Kita dapat menggunakan DFD untuk dua hal utama, yaitu untuk membuat

dokumentasi dari sistem informasi yang ada, atau untuk menyusun dokumentasi

untuk sistem informasi yang baru.

Empat simbol yang digunakan :

Ada 3 (tiga) jenis DFD, yaitu ;

Context Diagram (CD)

DFD Fisik

DFD Logis

Page 10: Proposal BD Rudi

A. DFD Level

DFD dapat digambarkan dalam Diagram Context dan Level n. Huruf n

dapat menggambarkan level dan proses di setiap lingkaran.

Diagram Context

Diagram Level n

DFD Logis

DFD Fisik

B. Context Diagram (CD)

Diagram konteks adalah diagram yang terdiri dari suatu proses dan

menggambarkan ruang lingkup suatu sistem. Diagram konteks merupakan level

tertinggi dari DFD yang menggambarkan seluruh input ke sistem atau output dari

sistem.

Ia akan memberi gambaran tentang keseluruhan sistem. Sistem dibatasi oleh

boundary (dapat digambarkan dengan garis putus). Dalam diagram konteks hanya

ada satu proses. Tidak boleh ada store dalam diagram konteks.

Diagram konteks berisi gambaran umum (secara garis besar) sistem yang akan

dibuat. Secara kalimat, dapat dikatakan bahwa diagram konteks ini berisi “siapa

saja yang memberi data (dan data apa saja) ke sistem, serta kepada siapa saja

informasi (dan informasi apa saja) yang harus dihasilkan sistem.”

Jadi, yang dibutuhkan adalah

(1) Siapa saja pihak yang akan memberikan data ke sistem,

(2) Data apa saja yang diberikannya ke sistem,

.(3) kepada siapa sistem harus memberi informasi atau laporan, dan (4) apa

saja isi/ jenis laporan yang harus dihasilkan sistem

Kata “Siapa” di atas dilambangkan dengan kotak persegi (disebut dengan

terminator), dan kata “apa” di atas dilambangkan dengan aliran data (disebut

Page 11: Proposal BD Rudi

dengan data flow), dan kata “sistem” dilambangkan dengan lingkaran (disebut

dengan process).

Jenis pertama Context Diagram, adalah data flow diagram tingkat atas

(DFD Top Level), yaitu diagram yang paling tidak detail, dari sebuah sistem

informasi yang menggambarkan aliran-aliran data ke dalam dan ke luar sistem dan

ke dalam dan ke luar entitas-entitas eksternal. (CD menggambarkan sistem dalam

satu lingkaran dan hubungan dengan entitas luar. Lingkaran tersebut

menggambarkan keseluruhan proses dalam sistem).

Beberapa hal yang harus diperhatikan dalam menggambar CD;

Terminologi sistem :

Batas Sistem adalah batas antara “daerah kepentingan sistem”.

Lingkungan Sistem adalah segala sesuatu yang berhubungan atau

mempengaruhi sistem tersebut.

Interface adalah aliran yang menghubungkan sebuah sistem dengan

lingkungan sistem tersebut.

Catatan:

Yang masuk didalam lingkaran konteks (simbol proses) adalah kegiatan

pemrosesan informasi (Batas Sistem). Kegiatan informasi adalah mengambil data

dari file, mentransformasikan data, atau melakukan filing data, misalnya

mempersiapkan dokumen, memasukkan, memeriksa, mengklasifikasi, mengatur,

Page 12: Proposal BD Rudi

menyortir, menghitung, meringkas data, dan melakukan filing data (baik yang

melakukan secara manual maupun yang dilakukan secara terotomasi).

Nama/keterangan di simbol proses tersebut sesuai dengan fungsi sistem

tersebut, Antara Entitas Eksternal/Terminator tidak diperbolehkan komunikasi

langsung Jika terdapat termintor yang mempunyai banyak masukan dan keluaran,

diperbolehkan untuk digambarkan lebih dari satu sehingga mencegah

penggambaran yang terlalu rumit, dengan memberikan tanda asterik ( * ) atau

garis silang ( # ).

Jika Terminator mewakili individu (personil) sebaiknya diwakili oleh

peran yang dipermainkan personil tersebut. Aliran data ke proses dan keluar

sebagai output keterangan aliran data berbeda.

C. Diagram Level n / Data Flow Diagram LevelledDalam diagram n DFD dapat digunakan untuk menggambarkan diagram

fisik maupun diagram diagram logis. Dimana Diagram Level n merupakan hasil

pengembangan dari Context Diagram ke dalam komponen yang lebih detail

tersebut disebut dengan top-down partitioning. Jika kita melakukan

pengembangan dengan benar, kita akan mendapatkan DFD-DFD yang seimbang.

Sebagai contoh, gambar 1.1, gambar 1.2, gambar 1.3, gambar 1.4 dan gambar 1.5.

Beberapa hal yang harus diperhatikan dalam membuat DFD ialah:

Pemberian Nomor pada diagram level n dengan ketentuan sebagai berikut:

Setiap penurunan ke level yang lebih rendah harus mampu

merepresentasikan proses tersebut dalam sepesifikasi proses yang jelas.

Sehingga seandainya belum cukup jelas maka seharusnya diturunkan ke

level yang lebih rendah.

Setiap penurunan harus dilakukan hanya jika perlu.

Tidak semua bagian dari sistem harus diturunkan dengan jumlah level

yang sama karena yang kompleks bisa saja diturunkan, dan yang

sederhana mungkin tidak perlu diturunkan. Selain itu, karena tidak semua

proses dalam level yang sama punya derajat kompleksitas yang sama juga.

Page 13: Proposal BD Rudi

Konfirmasikan DFD yang telah dibuat pada pemakai dengan cara top-

down.

Aliran data yang masuk dan keluar pada suatu proses di level n harus

berhubungan dengan aliran data yang masuk dan keluar pada level n+1.

Dimana level n+1 tersebut mendefinisikan sub-proses pada level n

tersebut.

Penyimpanan yang muncul pada level n harus didefinisikan kembali pada

level n+1, sedangkan penyimpanan yang muncul pada level n tidak harus

muncul pada level n-1 karena penyimpanan tersebut bersifat lokal.

Ketika mulai menurunkan DFD dari level tertinggi, cobalah untuk

mengidentifikasi external events dimana sistem harus memberikan respon.

External events dalam hal ini berarti suatu kejadian yang berkaitan dengan

pengolahan data di luar sistem, dan menyebabkan sistem kita memberikan

respon.

Jangan menghubungkan langsung antara satu penyimpanan dengan

penyimpanan lainnya (harus melalui proses).

Jangan menghubungkan langsung dengan tempat penyimpanan data dengan

entitas eksternal / terminator (harus melalui proses), atau sebaliknya.

Jangan membuat suatu proses menerima input tetapi tidak pernah

mengeluarkan output yang disebut dengan istilah “black hole”.

Jangan membuat suatu tempat penyimpanan menerima input tetapi tidak

pernah digunakan untuk proses.

Jangan membuat suatu hasil proses yang lengkap dengan data yang terbatas

yang disebut dengan istilah “magic process”.

Jika terdapat terminator yang mempunyai banyak masukan dan keluaran,

diperbolehkan untuk digambarkan lebih dari satu sehingga mencegah

penggambaran yang terlalu rumit, dengan memberikan tanda asterik ( * ) atau

garis silang ( # ), begitu dengan bentuk penyimpanan.

Aliran data ke proses dan keluar sebagai output keterangan aliran data berbeda

Page 14: Proposal BD Rudi
Page 15: Proposal BD Rudi

D. Model Entity Relationship (Model ER)

ERD adalah model konseptual yang mendeskripsikan hubungan antara

penyimpanan (dalam DFD). ERD digunakan untuk memodelkan struktur data dan

hubungan antar data. Dengan ERD, model dapat diuji dengan mengabaikan proses

yang dilakukan.

ERD pertama kali dideskripsikan oleh Peter Chen yang dibuat sebagai bagian dari

perangkat lunak CASE. Notasi yang digunakan dalam ERD dapat dilihat pada

Tabel di bawah ini :

Page 16: Proposal BD Rudi

E. Kardinalitas Relasi

Dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang

disebut dengan derajad relasi. Derajad relasi maksimum disebut dengan

kardinalitas sedangkan derajad minimum disebut dengan modalitas. Jadi

kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat berelasi

dengan entitas pada himpunan entitas lain. Kardinalitas relasi yang terjadi diantara

dua himpunan entitas (misalnya A dan B) dapat berupa :

1. Satu ke satu (one to one/ 1-1)

Setiap entitas pada himpunan entitas A dapat berelasi dengan paling banyak

satu entitas pada himpunan entitas B, demikian juga sebaliknya.

2. Satu ke banyak (one to many/ 1- N)

Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas

pada himpunan entitas B, tetapi tidak sebaliknya.

3. Banyak ke banyak (many to many/ N –N)

Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas

pada himpunan entitas B, demikian juga sebaliknya.

Tahapan Pembuatan ERD

Diagram ER dibuat secara bertahap, ada dua kelompok pentahapan yang biasa

ditempuh didalam pembuatan diagram ER, yaitu :

1. Tahap pembuatan diagram ER awal (preliminary design)

2. Tahap optimasi diagram ER (final design)

Tujuan dari8 tahap pertama adalah untuk mendapatkan sebuah rancangan

basis data minimal yang dapata mengakomodasi kebutuhan penyimpanan data

terhadap sistem yang sedang ditinjau. Tahap awal ini umumnya mengabaikan

anomali-anomali (proses pada basis data yang memberikan efek sampaing yang

tidak diharapkan) yang menang ada sebagai suatu fakta. Anomali-anomali

tersebut biasanya baru dipertimbangkan pada tahap kedua.

Tahap kedua mempertimbangkan anomali-anomali dan juga

memperhatikan aspek-aspek efisiensi, performasi dan fleksibilitas. Tiga hal

Page 17: Proposal BD Rudi

tersebut seringkali dapat saling bertolak belakang. Karena itu, tahap kedua ini

ditempuh dengan melakukan koreksi terhadap tahap pertama. Bentuk koreksi

yang terjadi dapat berupa pendekomposisian himpunan entitas, penggabungan

himpunan entitas, pengubahan derajad relasi, penambahan relasi baru atau

perubahan (penambahan dan pengurangan) atribut-atribut untuk masing-masing

entitas dan relasi.

Langkah-langkah teknis yang dapat dilakukan untuk mendapatkan ERD awal adalah :

1. Mengidentifikasi dan menetapkan seluruh himpunan entitas yang akan terlibat.

2. Menetukan atribut-atribut key (kunci) dari masing-masing himpunan entitas.

3. Mengidentifikasi dan menetapkan seluruh himpunan relasi diantara himpunan entitas-himpunan entitas yang ada beserta foreign-keynya (kunci asing/ kunci tamu).

4. Menentukan derajad /kardinalitas relasi untuk setiap himpunan relasi.

5. Melengkapi himpunan entitas dan himpunan relasi dengan atribut dekriptif (atribut yang bukan kunci)

Page 18: Proposal BD Rudi

BAB III

URAIAN SISTEM

3.1. Deskripsi System

Ada beberapa diskripsi yang menjelaskan Sistem Informasi Minimarket ini, yaitu

:

Di dalam sebuah manajemen Minimarket menyediakan beberapa macam barang

untuk dijual, dan system ini akan membagi hak akses untuk menjalankan system ini,

yaitu:

1. Admin, yaitu Admin dapat mengakses seluruh system yang terdapat Sistem

Informasi ini, yaitu

Page 19: Proposal BD Rudi

3.2. Diagram Konteks

System informasi Minimarket

Page 20: Proposal BD Rudi

3.3. DFD LEVEL

Page 21: Proposal BD Rudi
Page 22: Proposal BD Rudi
Page 23: Proposal BD Rudi

3.4. Conceptual Data Model

MengecheckDidapat

Melaksanakan

Melaporkan

Mendetailkan

Dilakukan_oleh

Memiliki

Input_order

Petugas

id_petugasnama_petugasalamat_petugastlp_petugas

<pi> Variable characters (7)Variable characters (20)Variable characters (30)Number (15)

<M><M><M><M>

Identifier_1 <pi>

Barang

id_barangnama_barangjenis_barangstokharga_jualharga_beliketerangan

<pi> Variable characters (7)Variable characters (20)Variable characters (20)Variable characters (10)Variable characters (20)Variable characters (20)Variable characters (15)

<M><M><M><M><M><M><M>

Identifier_2 <pi>

Supplier

id_suppliernama_supplieralamat_suppliertlp_supplier

<pi> Variable characters (7)Variable characters (20)Variable characters (35)Number (17)

<M><M><M><M>

Identifier_1 <pi>

Transaksi

id_transaksinama_transaksijenis_transaksijumlah_transaksitotal_bayar

<pi> Variable characters (7)Variable characters (20)Variable characters (20)Variable characters (10)Variable characters (15)

<M><M><M><M><M>

Identifier_4 <pi>

owner

id_ownernama_owneralamat_ownertlp_owner

<pi> Variable characters (7)Variable characters (20)Variable characters (35)Number (17)

<M><M><M><M>

Identifier_6 <pi>

order

id_ordertgl_orderstatus_orderApprovalid_petugas_supplytgl_supply

<pi> Variable characters (7)Date & TimeVariable characters (10)Variable characters (8)Variable characters (7)Date & Time

<M><M><M><M><M><M>

Identifier_7 <pi>

detail_order

jml_barang_orderjml_barang_supplyharga_supply

Variable characters (20)Variable characters (20)Variable characters (15)

detail_transaksi

jumlahharga_jualharga_beli

Variable characters (20)Variable characters (20)Variable characters (20)

3.5. Physical Data Model

Petugas

id_petugasid_ownernama_petugasalamat_petugastlp_petugas

varchar(7)varchar(7)varchar(20)varchar(30)numeric(15)

<pk><fk>

Barang

id_barangid_petugasid_suppliernama_barangjenis_barangstokharga_jualharga_beliketerangan

varchar(7)varchar(7)varchar(7)varchar(20)varchar(20)varchar(10)varchar(20)varchar(20)varchar(15)

<pk><fk1><fk2>

Supplier

id_supplierid_ordernama_supplieralamat_suppliertlp_supplier

varchar(7)varchar(7)varchar(20)varchar(35)numeric(17)

<pk><fk>

Transaksi

id_transaksiid_petugasnama_transaksijenis_transaksijumlah_transaksitotal_bayar

varchar(7)varchar(7)varchar(20)varchar(20)varchar(10)varchar(15)

<pk><fk>

owner

id_ownerid_petugasnama_owneralamat_ownertlp_owner

varchar(7)varchar(7)varchar(20)varchar(35)numeric(17)

<pk><fk>

order

id_orderid_petugastgl_orderstatus_orderApprovalid_petugas_supplytgl_supply

varchar(7)varchar(7)timestampvarchar(10)varchar(8)varchar(7)timestamp

<pk><fk>

detail_order

id_orderjml_barang_orderjml_barang_supplyharga_supply

varchar(7)varchar(20)varchar(20)varchar(15)

<fk>

detail_transaksi

id_transaksijumlahharga_jualharga_beli

varchar(7)varchar(20)varchar(20)varchar(20)

<fk>

Page 24: Proposal BD Rudi

Penjadwalan Praktikum

Kegiatan PelaksanaPertemuan

I II III IV V

Implementasi Modul

- Membuat Uraian Sistem

- Membuat Phisical Diagram

Semua Anggota

Membuat Implementasi Desain Phisic dan Pemberian hak akses

- Membuat tabel sesuai project

- Memberikan hak akses kepada setiap user

Semua Anggota

Membuat Procedure dan Function untuk melakukan proses DML

Semua Anggota

Membuat Trigger Semua Anggota

Merancang Program Aplikasi Semua Anggota

Mengkoneksikan Database ke program Aplikasi

Semua Anggota

Page 25: Proposal BD Rudi

DAFTAR PUSTAKA

1. Razaq,Abdul, 2004. Belajar Cepat Langsung Praktek VISUAL BASIC 6.0,

Yogyakarta: Penerbit Indah

2. Dian, Jaya, ST, 2005. Pemrograman Visual Basic, Yogyakarta: IMKI Prima

3. Fathansyah Ir, 1999, Basis Data, Informatika, Bandung.

4. Firdaus, 2005, Pemrograman Database Visual Basic 6.0, Maxikom,

Palembang.

5. Jogiyanto HM, 2005, Sistem Teknologi Informasi Edisi II, Andi,

Yogyakarta

6. Kadir Abdul, 2002, Pengenalan Sisitem Informasi, Andi, Yogyakarta.