proposal bd rudi
TRANSCRIPT
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
2011/ 2012
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
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
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
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.
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.
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.
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
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
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,
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.
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
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 :
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
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)
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
3.2. Diagram Konteks
System informasi Minimarket
3.3. DFD LEVEL
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>
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
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.