Integrated enterprise information system:
Enterprise (perusahaan): organisasi yang didirikan untuk mencapai suatu tujuan tertentu dengan melibatkan aktivitas yang produktif dan sistematis
Information system (sistem informasi): jaringan kerja dari semua saluran komunikasi yang digunakan dalam suatu organisasi
Integration (integrasi): aktivitas untuk meng-kombinasikan beberapa bagian menjadi satu kesatuan yang utuh
Sistem informasi perusahaan terintegrasi (integrated enterprise information system): suatu himpunan saluran komunikasi pada suatu organisasi bisnis, yang dikombinasikan sedemikian rupa sehingga membentuk suatu jaringan kerja dimana informasi dikumpulkan dan disebarkan
Business Process Reengineering adalah analisis dan desain ulang dari workflow di dalam dan antar perusahaan
(+) Memotong biaya dan meningkatkan fungsionalitas ( menghilangkan tahapan kerja yang tidak penting, penggunaan IT dalam sistem kerja )
(+) Mengidentifikasi waste / masalah / inefisiensi (BPR membantu menunjukan proses, item, dan orang yang tidak efisien )
(-) Menurunkan moral pekerja (ada beberapa pekerja yang mungkin menentang BPR atau kelebihan tanggung jawab karena tugas dan standar yang baruu)
(-) Membutuhkan investasi (BPR membutuhkan investasi yang terkadang tidak murah, seperti untuk penerapan software baru dan training)
Contoh Bussiness Process
Model
Suatu simplifikasi dari sesuatu pada realita. Dibuat dengan tujuan tertentu .Menghilangkan detil yang tidak dibutuhkan untuk tujuan tersebut. Contoh: maket, model mobil, dll Mengapa model dibutuhkan untuk sistem perusahaan? - Model dibuat agar kita dapat memahami sistem yang sedang dikembangkan. Pemodelan sangat bermanfaat untuk meminimalkan kompleksitas dan memungkinkan pengembangan solusi sistem perusahaan . Sistem perusahaan biasanya sangat besar dan kompleks untuk dapat dipahami secara menyeluruh
- Tujuan pemodelan dalam sistem perusahaan adalah untuk menciptakan representasi realita bisnis dalam suatu bentuk yang bisa dibaca oleh computer Dimulai dengan membuat representasi di atas kertas dari realita perusahaan. Kemudian Menerjemahkan model di atas kertas tersebut ke dalam format yang compatible dengan paket perangkat lunak basis data
Model yang baik adalah:
- Model yang sedapat mungkin menyerupai realita yang sesungguhnya
- Model yang baik dapat di-ekpresikan dalam berbagai tingkatan presisi
- Model yang baik dapat dipecah menjadi model-model kecil untuk pengujian fitur dan dapat di-agregasi-kan untuk tinjauan holistik
Object Patterns
adalah kumpulan stereotip benda dan hubungan antar mereka
Dalam menentukan benda & hubungannya, Andaipun kita
CHAPTER 2
REPRESENTASI DAN REA CHAPTER 1
PENGANTAR
kita memiliki pengetahuan (baik secara first-hand ataupun second-hand) tentang sesuatu yang mirip dengan hal tersebut - kita dapat menggunakan pengetahuan tentang obyek yang kita kenal pada obyek yang kita tidak kenal Dalam pemodelan konseptual, pola obyek disebut “stereotypical constellation of entities”: Suatu kumpulan entitas dan hubungan yang kita harapkan eksis pada realita Pada tingkatan proses bisnis, REA adalah suatu pola yang secara khusus dibuat untuk merepresentasikan perusahaan dan menjadi fondasi bagi sistem informasi perusahaan yang terintegrasi
Script Patterns
Rangkaian stereotip event (kejadian) yang biasanya terjadi sebagai kombinasi antar satu sama lain. Sama seperti pada pola obyek, scripts pattern merupakan “pattern-based thinking” yang diaplikasikan pada rangkaian events. Kombinasi dari pola obyek dan script pattern dapat digunakan untuk memodelkan sistem perusahaan
Enterprise Ontology
Usaha untuk mendefinisikan hal-hal tentang perusahaan yang harus direpresentasikan
REA Enterprise Ontology (Konstruksi dasar) :
Resources: sesuatu dengan nilai ekonomis yang disediakan atau dikonsumsi oleh perusahaan
Events: aktivitas dalam perusahaan yang harus direncanakan, dikendalikan, dieksekusi dan dievaluasi
Agents: individu, departemen, divisi atau organisasi yang berpartisipasi dalam pengendalian dan eksekusi events
Tingkatan REA Enterprise Ontology :
1. Value system level (object-based pattern):
Fokus pada resources yang dipertukarkan antara perusahaan dengan berbagai mitra eksternalnya (pemasok, konsumen, kreditur/investor, karyawan). Kombinasi value system dari para mitra bisnis membentuk rantai pasokan RSWS Value System Level REA Model
2. Value chain level (script-based pattern)
Fokus pada aliran resources antar berbagai proses bisnis yang terhubung satu sama (interconnected business processes) lain dan pada events ekonomis yang menyebabkan aliran resources. Interconnected business processes yang lazim disertakan dalam model REA, value chain level: proses keuangan, proses akuisisi/pembayaran,
proses sumber daya manusia, proses konversi (manufaktur) dan proses sales/collection
RSWS value chain level REA Model (Summarized Version)
3. Business Process Level (object-based pattern):
Fokus pada satu atau lebih siklus transaksi dalam suatu enterprise’s value chain. Memperluas representasi dengan menyertakan berbagai jenis resources, events dan agents serta hubungan (relationship) diantara mereka.
Hubungan:
o Stockflow (hubungan antara resources and events – naik atau turun)
o Dualitas (hubungan antara increment economic events dan decrement economic events)
o Kontrol (hubungan antara events and agents yang berpartisipasi)
4. Task Level (script-based pattern)
Fokus pada tahapan individual yang menyebabkan events dalam perusahaan. Dapat digambarkan dalam berbagai format seperti fishbone diagram, system flowchart, data flow diagram, process model, dll
1. UTS 2010 – 2011
a. Apakah yang dimaksud dengan business process re-engineering (BPR)? Apakah manfaat dari
BPR? (5%)
b. Jelaskan keempat tingkatan dari REA-Enterprise Ontology dan jelaskan pula tipe pola (object
pattern atau script pattern) pada tiap tingkatan pemodelan tersebut! (5%)
2. UTS 2012 – 2013
a. Apa yang dimaksud dengan model dan apa saja karakteristik model yang baik?
b. Jelaskan dengan contoh apa yang dimaksud dengan business process! (1 proses)
c. Jelaskan perbedaan antara pola object (object pattern) dan pola script (script pattern)!
Porter’s generic value chain :
Segala sesuatu yang dilakukan oleh suatu perusahaan harus meciptakan nilai bagi para pelanggannya dengan cara menyediakan barang dan jasa sesuai keinginan pelanggannya, tetapi hal itu membutuhkan biaya.
Primary value activities :
Inbound logistics = aktivitas penerimaan, penyimpanan, dan pengiriman input
Operations = aktivitas proses transformasi input menjadi produk akhir
Outbound logistics = aktivitas pengumpulan,
Markeing & sales = aktivitas menarik pelanggan untuk membeli
Service = aktivitas jasa untuk meningkatkan atau memelihara nilai produk
Support value activities :
6. Firm infrastructure = aktivitas pendukung keseluruhan value chain, contoh : manajemen umum, perencanaan, keuangan, akuntansi
7. Human resource = aktivitas perekrutan, pelatihan, pengembangan, dan kompensasi seluruh karyawan
8. Technology development = prosedur teknologi dalam proses peningkatan kualitas produk
9. Procurement = fungsi pembelian input untuk value chain perusahaan
Aktivitas perusahaan pada tingkat value system dan value chain :
1. Dapat membantu agar tetap memiliki perspektif
2. Memberi struktur untuk mengarahkan analisis atas tingkatan yang lebih rendah
3. Mempertimbangkan misi dan strategi perusahaan agar tetap konsisten dan proses
bisnis bias berkembang
Value system
Value system = serangkaian sistem yang memuat aliran kegiatan antar pihak yang terlibat dalam core business perusahaan.
Langkah – langkah membuat value system :
1. Buat firm dengan bentuk lingkaran atau oval di tengah 2. Perhatikan aliran resources (uang, persediaan, tenaga kerja, property, asuransi, jasa, energy, dll) yang masuk perusahaan beserta asalnya dari mana, buat tanda panah sebagai penghubung
3. Perhatikan aliran resources (uang, persediaan, tenaga kerja, property, asuransi, jasa, energy, dll) yang keluar dari perusahaan beserta tujuannya kemana, buat tanda panah sebagai penghubung
4. Buat external party (vendor, pelanggan, karyawan, investor) dengan simbol persegi panjang atau persegi sebagai asal dan tujuan aliran resources baik uang maupun non-uang -> untuk eksternal party yang berbeda tapi sumberdaya nya sama atau sebaliknya perusahaan sama
CHAPTER 3
tapi sumberdaya beda maka bias disatukan atau dipisahkan, subjektif sekali
5. Buat aliran uang dan non-uang masuk dan keluar perusahaan dengan menggunakan tanda panah pada model Sumber aliran uang masuk :
1. Dari investor = untuk arus kas (tambahan modal atau asset)
2. Dari kreditur = untuk arus kas (tambahan pinjaman modal)
3. Dari pelanggan = untuk pembayaran atas barang, layanan perbaikan, dan sewa barang
Sumber aliran uang keluar :
1. Kepada investor = untuk arus kas masa lalu (pembayaran dividen)
2. Kepada kreditur = untuk arus kas masa lalu (pembayaran hutang)
3. Kepada pemasok = untuk pembayaran bahan mentah, persediaan, properti, peralatan, layanan, utilities
4. Kepada karyawan = untuk tenaga kerja (pembayaran gaji, tunjangan, dll)
Value chain level
Value chain level = Menggambarkan interkoneksi dari siklus transaksi pada suatu perusahaan dan aliran resources antar mereka.
Value chain level dibagi sesuai functional area dengan jobdesc masing – masing dan tetap memakai simbol lingkaran atau oval untuk functional area,tanda panah untuk aliran, danpersegi panjang atau persegi untuk jobdesc.
Pada tingkat ini analisis fokus pada aliran resources (input) pada proses bisnis internal. Lalu identifikasi apa yang dilakukan perusahaan pada input dan bagaimana perusahaan dapat menghasilkan output.
Tiap organisasi biasanya paling tidak memiliki tiga jenis proses bisnis:
Proses akuisisi/pembayaran (acquisition/payment):
- bertujuan untuk akuisisi, memelihara dan membayar resources yang dibutuhkan organisasi
- Karena akuisisi financial resources & human resources memiliki kompleksitas yang berbeda, banyak perusahaan memisahkan aktivitas ini menjadi proses bisnis terpisah: proses keuangan (financing process) & proses sumber daya manusia (human resources process)
Proses konversi (conversion)
bertujuan untuk mengubah resources yang dibutuhkan menjadi produk & jasa untuk pelanggan
Proses penjualan/koleksi (sales/collection)
bertujuan untuk menjual dan mengirimkan barang & jasa bagi pelanggan dan mengumpulkan pembayaran - Didalam value chain level terdapat relasi dualitas yang terdiri dari : 1. Increment economic events : meningkatkan resources (stock inflow)
2. Decrement economic events : mengurangi resources (stock outflow)
Tiap event (aktivitas) ekonomis dalam tiap siklus pada value chain, berkaitan dengan suatu aliran resource yang masuk/keluar.
Contoh : jika ada 3 aliran masuk ke siklus dan hanya ada 1 aliran keluar, maka harus ada 3 event yang menggunakan resources itu da nada 1 event yang menyediakan resources itu.
Langkah – langkah membuat value chain level :
1. Tulis script berdasarkan deskripsi dan model value system 2. Hubungkan scenes (simbol – simbol lingkara atau oval) dengan aliran resources-> scenes pertama dan terakhir merupakan proses keuangan
3. Tentukan economic exchange events untuk tiap scene. Tiap scene paling tidak harus memiliki satu economic decrement event dan satu economic increment event. Tiap aliran resource yang masuk harus dikaitkan dengan suatu economic decrement event dan arus ada suatu event dalam proses yang “menggunakan” resource tsb. Tiap aliran resource yang keluar harus dikaitkan dengan suatu economic increment event dan harus ada suatu event dalam proses untuk mendapatkan atau menghasilkan resource tsb.
Pemodelan sistem perusahaan pada tingkatan value system dan value chain - memberikan gambaran tentang strategi dan stockflow suatu perusahaan dan mengindikasikan perpindahan tanggung jawab atau kepemilikan dari satu
agen atau siklus transaksi ke agen atau siklus transaksi lainnya.
Contoh alur dari value chain level di atas :
Uang yang didapatkan dari proses keuangan digunakan sebagai input untuk proses akuisisi/pembayaran dan proses penggajian -> Proses penggajian menggunakan uang dan menghasilkan tenaga kerja -> Proses akuisisi/pembayaran menggunakan uang untuk menghasilkan instrumen, material, overhead & peralatan -> Proses konversi mengubah tenaga kerja, material, overhead dan peralatan menjadi aksesoris & layanan perbaikan -> Proses penjualan/pengumpulan menggunakan aksesoris, layanan perbaikan dan instrumen untuk mendapatkan uang.
Pola REA untuk memodelkan tingkatan proses bisnis bebas menggunakan apa saja, antara lain dengan :
- Deskripsi naratif
- Berbagai diagram dengan notasi yang berbeda - Bahasa terstruktur
- Predicate logic notations
- Tags seperti yang digunakan pada XML (Extensible Markup Language) & XBRL (Extensible Business Reporting Language) - Notasi bahasa pemrograman
Tetapi notasi yang akan digunakan: diagram & bahasa terstruktur yang merupakan turunan dari kumpulan constructs yang dinamakan entity-relationship (ER) modeling (pemodelan relasi entitas)
Conceptual Modelling Constructs :
1. Entitas
kumpulan objek riil, baik bersifat fisik maupun konseptual (berarti himpunan entitas). Contoh : pelanggan ZARA membentuk himpunan entitas “pelanggan” dan mereka memiliki identitas yang sama (nama, no tlp, alamat) -> kata instance berarti anggota suatu himpunan
2. Relasi
kumpulan asosiasi / hubungan antar entitas (berarti himpunan relasi). Contoh : entitas pelangga IM3 & entitas paket full BB service, relasinya mungkin adalah pendaftaran langganan paket
3. Atribut
karakteristik / sifat dasar yang dimiliki entitas dan atau relasi.
Atribut kunci primer (primary key attributes)
untuk mendeskripsikan anggota dari suatu himpunan entitas atau relasi secara unik dan universal .
Atribut sederhana
Tidak dapat dipecah lagi. Contoh : jenis kelamin Atribut komposit
Dapat dipecah menjadi beberapa atribut lain. Contoh :
Atribut derivatif
dapat diturunkan atau dihitung dari nilai atribut lain dalam basis data. Contoh : IPK, ranking kelas, biaya konsumsi, dll. Jenisnya ada 2, yaitu :
(1) Statik = tidak dapat berubah, contoh : atribut “total sale amount” dari entitas “sale”-> kalo ada data penjualan dari pelanggan baru di-input, data jumlah penjualan dari tiap pelanggan lama gak akan berubah.
(2) Volatile = akan berubah kalau ada data baru di-input lagi ke sistem, contoh : atribut “IPK” dari entitas “mahasiswa” 4. Kardinalitas partisipasi
untuk merepresentasikan aturan bisnis, berapa kali
suatu himpunan entitas diperbolehkan berpartisipasi dalam suatu relasi. Contoh : entitas “pelanggan” dengan “penjualan”, relasinya adalah “transaksi jual-beli”, misal aturan kardinalitas bagi “pelanggan” (1,N) artinya minimum “pelanggan” harus melakukan transaksi pembelian 1 kali dan maksimum tak terhingga. Sedangkan aturan kardinalitas bagi “penjualan” (0,N) artinya minimum “penjualan” melakukan transaksi jual beli dengan 0 pelanggan dan maksimum tak terhingga. Baca (min, max).
Kardinalitas minimum : jumlah minimum partisipasi yang harus dilakukan. 0 = partisipasi opsional (boleh gak ada samsek), 1 = partisipasi wajib (min harus 1 kali berpartisipasi)
Kardinalitas maksimum : jumlah maksimum partisipasi yang boleh dilakukan. 1 = partisipasi max hanya 1 kali, N = partisipasi tak terhingga, sebanyak yang dibutuhkan
-
5. Mekanisme abstraksi
untuk merepresentasikan kategori entitas / hirarkhi entitas. Typification : bisa menyimpan karakteristik suatu kategori / tipe dari entitas. Contoh : universitas menyimpan karakteristik jumlah maksimum SKS yang boleh diambil per semesternya, Menteri Perekonomian menyimpan
karakteristik wage rate per hour dari buruh Indonesia, dll.
CHAPTER 4 REA MODELLING
Generalization : menyimpan entitas subtype (anggota entitas yang lebih spesifik) dan supertype (entitas yang lebih general) dengan relasi “is - a”. Contoh : supertype = “instrumen musik” subtype = “alat music tiup”, supertype = “jus buah” subtype = “jus manga”
Dipakai kalau sebagian karakteristik dimiliki oleh semua entitas subtype, tapi ada juga sebagian karakteristik yang hanya dimiliki subtype tertentu. Contoh atribut karyawan NIK, nama, alamat, no tlp, TTL. Tapi atribut SIM Cuma dimiliki oleh beberapa karyawan.
Conceptual Modeling Notations :
Beberapa notasi digunakan untuk mengkomunikasikan konsep pemodelan konseptual yang sama. Contoh : Pak Fulan bisa berbicara dengan Bahasa Indonesia, Inggris, Jerman, dan Prancis.
- Entity Relationship (ER) grammar notation = notasi menggunakan kata – kata / kalimat. *Contoh format notasinya :
Entity: ENTITY NAME
Attributes: ATTRIBUTE NAMES
Identifiers: PRIMARY KEY ATTRIBUTE -> yang jadi pembeda utama
Relationship: RELATIONSHIP NAME Connected entities: (min,max) ENTITY1 (min,max) ENTITY2 Attributes: ATTRIBUTE NAMES (if any)
Objek biasanya disimpan berdasarkan urutan alphabet dari nama dan relasi entitas (urut a-z), ditulis relasi dulu baru entitas. Nama lain notasi ini : BNF Grammar oleh Backus-Nour Form.
Entity Relationship (ER) diagram notation = alternatif untuk merepresentasikan constructs yang sama seperti di ER Grammar. Bedanya ini menggunakan simbol gambar / diagram
# ER Grammars = diurut berdasarkan nama (secara alfabetis, urut dari a-z) & tiap nama didahului oleh kata “Entity” dan “tanda titik dua”. Contoh -> Entity : Customer # ER Diagrams = menggunakan lambang persegi panjang & diberi nama entitas.
Contoh -> Relasi
# ER Grammars = diurut berdasarkan nama (secara alfabetis, urut dari a-z) & tiap nama didahului oleh kata “Relationship” dan “tanda titik dua”. Lalu di bawahnya ditulis kata “Connected Entities” dan “tanda titik dua” nama entitas terkait.
Contoh
# ER Diagrams = menggunakan lambang belah ketupat & dihubungkan dengan garis lurus ke entitas yang saling memiliki relasi tsb.
Contoh ->
Atribut
# ER Grammars = diurut berdasarkan nama dalam deskripsi entitas dan atau relasi. Dipaling bawah tulis juga kata “Identifier” dan “tanda titik dua” lalu nama primary key nya. Contoh
# ER Diagrams = menggunakan lambang lingkaran kecil yang dihungkan dengan garis pendek ke entitas atau relasi terkait. Lingkaran untuk primary key attribute digelapkan Contoh
Kardinalitas partisipasi
# ER Grammars = masukkan ke deskripsi relasi, ditulis setelah nama entitas pada pernyataan “Connected Entities” dan “tanda titik dua”.
*Contoh -> Relationship: Assigned-to
Connected Entities: (0,1) Employee (1,N) Department
# ER Diagrams = menggunakan lambang label pada garis antara entitas & relasi.
* Contoh
Latihan kardinalitas
Q1: Can at least one sale exist in the database without a related instance of cash receipt?
NO! - 1 min on sale
Q2: Can at least one sale in the database relate to multiple instances of cash receipt?
NO! – 1 max on sale
Q3: Can at least one cash receipt exist in the database without a related instance of sale?
NO! – 1min on cahs receipt
Q4: Can at least one cash receipt in the database relate to multiple instances of sale?
NO! – 1 max on cash receipt
In other words, all sales are paid for immediately with cash, and sales are the company’s only source of cash
Langkah – langkah membuat REA business process level :
1. Identifikasi Economic Exchange Events (EEE) -> pakai value chain(kalau ada), mana yang menggunakan resources dan mana yang menghasilkan, tiap EEE menjadi
suatu entitas dan bukan relasi dualitas.
2. Tambahkan resources EEE -> pakai value chain (kalo ada), tentuin mana yang increment event dana decrement event, tiap resources jadi suatu entitas dan buat relasi
stockflow antara resources EEE terkait
3. Tambahkan internal agents pada EEE -> pakai value systems (kalo ada), buat relasi partisipasi diantara event dan agent, tentukan external agent yang jadi sumber dan tujuan aliran resources
4. Tambahkan internal agents pada EEE -> relasi partisipasi, pihak – pihak yang bikin increment dan decrement event 5. Tambahkan atribut pada entitas dan relasi
7. Lakukan validasi model (periksa)
REA business process level with extensions :
1. ) Entitas = *Resources dan resources type *Events :
(1) Instigation = event yg memulai aktivitas pada proses bisnis, internal (event pemasaran), eksternal (telepon dari orang supplier kita bagian pemasaran).
(2) Mutual Commitment Event = event tentang komitmen antara perusahaan dengan mitra bisnis eksternalnya. (3) Economic Exchange Event = event ttg inflow dan outflow resources.
*Agen : internal (mewakili perusahaan), eksternal (mitra bisnis)
2. Relasi = *Event – Event relationships :
(1) Dualitas, menghubungkan encrement dan decrement events.
(2) Reciprocal, menghubungkan increment dan decrement commitment event.
(3) Fulfillment, menghubungkan commitment event dengan economic event).
*Event - Resources relationships :
(1) Stockflow, menghubungkan economic events dan resources atau resource types.
(2) Reservation, menghubungkan commitment events dan resources atau resource types.
*Event - Agent relationships :
Partisipasi, menghubungkan events dan agents yang betpartisipasi dalam events.
*Agent – Agent relationships :
(1) Assignment, menghubungkan agen internal dan eksternal hanya bila relasinya independen.
(2) Responsibility, menghubungkan agen internal dan eksternal hanya bila agent internal bertanggung jawab atas agent internal lainnya dan relasinya independen.
*Resources – Agent relationships :
Custody, menghubungkan resource dan internal agent hanya bila pertanggungjawaban seorang agen internal atas suatu resource di-track secara terpisah dari tiap event. *Resources – Resources relationships :
Linkage, menghubungkan dua resources untuk identifikasi resource yang dibuat dari resource lain.
*Typification :
Tiap resource, event, atau agent dapat dihubungkan pada suatu resource type, event type, atau agent type.
*Generalization :
Tiap resource, event, agent, dan commitment dapat pula
berpartisipasi dalam suatu relasi dengan subclass or superclass melalui suatu relasi generalisasi.
Kesimpulan :
1. Tujuan model konseptual REA pada proses bisnis untuk merancang arsitektur basis data suatu perusahaan dengan menggunakan pola objek tertentu
2. Komponen-komponen arsitektur basis data yang disertakan dalam pemodelan REA adalah entitas, atribut, relasi dan kardinalitas
3. Tiga jenis entitas utama dalam REA ontology adalah Resources, Events, and Agents
4. Tiga jenis relasi utama dalam REA ontology adalah duality, stockflow, dan participation; jenis tambahan adalah assignment, custody, fulfillment, linkage, reciprocal, reservation, dan responsibility. REA ontology juga membolehkan relasi generalization and typification
5. Tambahannya : assignment, custody, fulfillment, linkage, reciprocal, reservation, responsibility, serta generalization dan typification
Tasks (tugas) adalah tahapan individual yang terkait dalam penyelesaian suatu event dalam suatu perusahaan
Events adalah tasks; tetapi tidak semua tasks boleh direpresentasikan sebagai events
Task yang pengukurannya tidak mungkin dilakukan atau tidak berbiaya efektif, tidak boleh direpresentasikan sebagai events. Tasks adalah berbagai aktivitas yang dapat dirubah atau dihilangkan tanpa mengubah karakteristik perusahaan secara substansial. Tujuan pemodelan pada level ini, bukan untuk merancang suatu basis data, tetapi untuk mendokumentasikan aliran data dalam suatu perusahaan. Belum ada suatu pola yang teridentifikasi pada task level
System Flowchart
Mendokumentasikan sistem informasi secara grafis Meringkas halaman-halaman narasi dalam format
diagram
Fokus pada aspek fisik dari aliran dan proses informasi
System Flowcharts: Elemen Dasar
System flowcharts dapat digambarkan secara manual ataupun dengan menggunakan alat bantu plastic flowchart template/stencil. System flowcharts dapat pula dibuat dengan menggunakan perangkat lunak computer. Contoh: SmartDraw, Visio, ABC Flowcharter, Microsoft Word and Powerpoint . System flowcharts menggabungkan tiga elemen dasar grafis untuk merepresentasikan berbagai jenis aliran dan proses informasi fisik.
CHAPTER 5 FLOWCHART
Contoh System Flowchart
Flowchart symbols
More flowchart symbols
Flow Lines
Flow lines (garis aliran) digunakan untuk menghubungan berbagai simbol pada document flowchart. Garis yang tidak putus-putus menggambarkan aliran suatu dokumen atau obyek . Garis titik-titik, atau garis putus-putus menggambarkan suatu aliran informasi, bukan aliran dokumen fisik
Beberapa flowchart juga menggambarkan aliran komunikasi, seperti komunikasi dengan menggunakan modem telepon atau satelit. Tanda panah digunakan bila aliran dokumen atau informasi bukan dari kiri ke kanan ataupun dari atas ke bawah
Areas of Responsibility
Areas of responsibility (Wewenang tanggung jawab) digambarkan agar pembaca flowchart dapat dengan jelas mengetahui perpindahan tanggung jawab seiring dengan
aliran dokumen dalam sistem . Dalam flowchart, areas of responsibility direpresentasikan dengan menggunakan kolom-kolom terpisah yang diberi label. Areas of responsibility dapat berupa departemen, seksi dalam dalam suatu departemen, ataupun karyawan suatu departemen. Pertimbangkan dengan benar pemilihan tingkat subdivisi yang direpresentasikan oleh suatu kolom
Flowchart Preparation Conventions
Left-to-right , Top-to-bottom
Semua dokumen harus memiliki asal dan tujuan (“cradle to grave documentation”). Setiap duplikat dari dokumen harus menuju:
Suatu simbol file permanen
Suatu simbol yang melambangkan titik keluar dari sistem, atau
Penghubung (connector) ke halaman berikutnya
Suatu simbol yang melambangkan penghancuran dokumen (kotak hitam kecil)
Sudut dari originating symbol dapat digelapkan sebagai indikasi dari introduksi terhadap sistem
Buatlah flowchart dengan rapi. Letakkan responsibility area dengan frequent interchange bersebekahan satu sama lain. Tuliskan narasi hanya di dalam simbol
Hindari penjelasan dengan narasi yang tidak perlu
Pastikan bahwa setiap dokumen memiliki aliran yang jelas. Gambarkan suatu dokumen :
Sebelum dan sesudah tiap proses Masuk dan keluar suatu file
Masuk dan pindah (keluar) halaman atau area of responsibility
Pastikan bahwa flowchart dibuat secara lengkap
Ringkasan system flowchart
Kelebihannya:
Flowcharts relatif mudah dimengerti oleh pelanggan dan manajer informasi
Flowcharts membantu auditor untuk memahami business and systems controls
Kekurangannya:
Flowcharts terikat pada aliran informasi dan karakteristik sistem yang menutupi intisari prosedural suatu sistem
Flowcharts dapat bersifat artifactual dan terikat pada teknologi informasi yang sudah kadaluarsa
Jenis Data
Master files (file induk). Berisikan balance atau status dari entitas. Contoh: vendors, credit customers, persediaan, assets, karyawan.
Transaction files (file transaksi). Berisikan data tentang aktivitas. Contoh: pesanan, penjualan, pembayaran. History or archive files (file arsip). Berisikan data historis
atau data masa lalu yang tidak aktif.
Reference files (file acuan). Berisikan informasi yang dibutuhkan untuk tujuan referensi. Contoh: kurs, harga, kode pos, chart of accounts .
Suspense files. Berisikan data yang menunggu diproses, errors, dan informasi yang hilang
Penyimpanan dan Akses Data
Penyimpanan sekuensial dan akses sekuensial Records disimpan secara berurutan
Untuk mengakses suatu record, perangkat aksesnya harus membaca semua record yang disimpan sebelum record yang diinginkan
Tape cartridges dan open reel tapes menggunakan penyimpanan dan akses data sekuensial
Penyimpanan secara acak (random Storage) & akses langsung
Records disimpan secara acak (tidak berurutan)
Setiap record dapat diakses secara langsung tidak bergantung pada posisi fisiknya pada media penyimpanan; perangkat akses tidak harus membaca semua records sebelum record yang diinginkan
Pada hard-disk, floppy disk, zip disk, CD-ROM, DVD-ROM, penyimpanan data dilakukan secara acak, dan akses data dapat dilakukan secara langsung
Media
Kertas
Media yang umum digunakan Mudah digunakan
Tidak bergantung pada listrik
Kekurangan: Bulk (untuk disimpan), Tidak memiliki kemampuan mencari dan pemrosesan otomatis dan Mudah rusak
Penyimpanan sekuensial (dapat diberi indeks untuk akses sekuensial berdasarkan indeks)
Dapat diperbaharui pada media input fisik yang sama Menambahkan informasi pada dokumen yang sama Pita magnetik (magnetic tape)
Pita kaset audio, pita VHS, kaset video kamera 8mm menggunakan pita magnetik
Penyimpanan sekuensial dan akses sekuensial
Pengurutan (sorting) sangat penting untuk pemrosesan (file transaksi harus diurutkan untuk mencocokkan dengan urutan master file)
Media fisik terpisah harus digunakan untuk input dan output pada proses update. Contoh : Master file lama, master file baru
Mudah di-backup
Bergantung pada listrik dan perangkat keras. Tidak dapat dibaca atau diproses secara langsung oleh manusia
Media digital (disks)
hard disk komputer, floppy disks, zip disks, CDs, DVDs, dan memory cards
Penyimpanan secara acak. Informasi dapat disimpan di bagian manapun dari media, dapat dibagi-bagi dan disimpan di beberapa lokasi. Contohnya : “Defragging” suatu hard drive adalah proses untuk mengurutkan data dan menghubungkan kembali semua bagian untuk pemrosesan yang lebih efisien Akses langsung. Dengan indeks, perangkat keras dapat
langsung mengakses informasi yang diinginkan dan kemudian memprosesnya.
Media fisik yang sama dapat digunakan untuk input dan output pada suatu proses update (kecuali bila medianya sudah penuh).
Mudah di-backup
Bergantung pada listrik dan perangkat keras
Tidak dapat dibaca atau diproses secara langsung oleh manusia
Metode Pemrosesan
Batch: mengakumulasikan data untuk suatu periode waktu. Kemudian semua transaksi pada file transaksi di-posting ke master file dalam suatu processing run (pemrosesan pita selalu dilakukan secara batch)
Online: bermakna perangkat input komputer terhubung ke CPU sehingga master file di-update pada saat data transaksi dimasukkan
Real-time: bermakna respon langsung terhadap pengguna informasi; data transaksi dimasukkan dan diproses untuk meng-update master file yang berkaitan, dan suatu respon dengan cepat diberikan pada personil yang menyelenggarakan event bisnis sehingga mempengaruhi hasil dari event tersebut Report-time: data yang digunakan untuk membuat
laporan (report) diproses seiring dengan pembuatan laporan
Data Flow Diagrams (DFD)
Simbol DFD digunakan untuk berbagai tujuan analisis sistem, termasuk penggambaran secara grafis alur logika data dalam suatu proses. Tidak seperti flowcharts yang merepresentasikan komponen fisik suatu sistem. informasi, DFD dapat memberikan gambaran non-fisik yang lebih konseptual dari pergerakan data dalam suatu sistem. DFDs mengabaikan hal-hal seperti unit organisasi, komputer tempat data diproses, dan media penyimpanan data. Pergerakan data melalui berbagai kantor dan departemen dalam suatu sistem tertentu tidak direpresentasikan
Proses
Lingkaran digunakan untuk mewakili proses yang mengambil data inflow dan mengubahnya menjadi information outflow. Tiap lingkaran memiliki dua label : Nomor proses dan Nama proses. Notasi alternatif yang dapat digunakan adalah kotak persegi empat dengan sudut lengkung.
Data Sources and Sinks
Persegi empat (atau bujur sangkar) melambangkan data (inflow) sources dan (information outflow) sinks. Persegi empat diberi label nama dari data source atau sink/destinasi (contoh pelanggan, vendor, lembaga pemerintah). Sources dan sinks adalah agen eksternal (atau diluar cakupan) sistem yang direpresentasikan dalam diagram. Menjelaskan batasan system
Data Flow Lines
Data flow lines menggambarkan rute data inflow dan information outflow Garis boleh lurus ataupun melengkung. Data flows biasanya diberi label dengan nama data (contoh pesanan pelanggan, tagihan, dll). Panah menunjukkan arah aliran data
Data Stores
Dua garis paralel digunakan untuk menunjukkan suatu penyimpanan (store) atau koleksi data. Data stores adalah data yang diistirahatkan. Deskripsi tentang isi data store dituliskan di dalam simbol. Data store digunakan bila output suatu proses harus disimpan terlebih dahulu sebelum dikirimkan ke proses yang berikutnya. Notasi alternatif yang dapat digunakan adalah kotak persegi empat yang terbuka di satu sisinya
Constraints: Aturan Umum
1) Setiap proses harus memiliki nama unik
Bila dua data flow lines (atau data stores) memiliki label yang sama, keduanya harus mengacu pada data flow (atau data store) yang sama
2) Input suatu proses harus berbeda dari output-nya 3) Setiap DFD tidak boleh memiliki lebih dari tujuh proses Constraints: Process rules
4) Tidak bolah ada proses yang hanya memiliki output saja (karena hal tersebut mengindikasikan bahwa proses menghasilkan informasi dari nol). Bila suatu obyek hanya memiliki output maka obyek tersebut pasti suatu source. 5) Tidak boleh ada proses yang hanya memiliki input saja (atau “black hole”)
- Bila suatu obyek hanya memiliki input, maka obyek tersebut suatu sink
6) Proses harus diberi label frase kata kerja
Constraints: Data stores
7) Data harus dipindahkan oleh suatu proses; data tidak dapat langsung pindah dari satu data store ke data store lainnya.
8) Data harus dipindahkan oleh proses yang menerima data dari sources dan menempatkannya pada suatu data store; data tidak dapat langsung pindah dari outside source ke suatu data store
9) Data harus dipindahkan oleh suatu proses; tidak dapat berpindah langsung dari data store ke suatu outside sink
10) Data store harus diberi label dengan frase kata benda.
Constraints: Source/Sink
11) Data tidak dapat berpindah langsung dari suatu source suatu sink. Data harus dipindahkan oleh suatu proses bila data berkaitan dengan sistem. Bila data berpindah langsung dari suatu source ke suatu sink (dan tidak melibatkan pemrosesan) maka diluarcakupan sistem dan tidak diambarkan pada diagram DFD system data flow.
12) suatu source/sink memiliki label frase kata benda.
Constraints: Data flow
13) suatu data flow hanya boleh memilliki satu arah diantara dua simbol. Data boleh bergerak dalam dua arah antara suatu proses dan suatu data store untuk menunjukkan bahwa dibaca dulu sebelum di-update. Untuk menggambarkan hal tersebut secara efektif, gambarlah dua panah terpisah karena dua langkah (pembacaan dan updating) terjadi pada waktu yang berbeda.
14) Pencabangan pada data flow berarti data yang sama (contoh duplikat tagihan) bergerak dari suatu lokasi yang sama ke dua atau lebih proses, data stores, atau sources/sinks yang berbeda
15) Penggabungan pada data flow berarti data yang sama bergerak dari dua atau lebih proses, data stores, atau sources/sinks yang berbeda , ke lokasi yang sama.
16) Suatu data flow tidak boleh langsung kembali ke proses yang sama. Paling tidak harus ada satu proses lain yang menangani data flow tersebut, menghasilkan data flow lain, dan mengembalikan data flow aslinya ke proses awal.
17) Suatu data yang bergerak ke suatu data store, bermakna meng-update (menghapus, menambahkan atau merubah) 18) Suatu data flow dari suatu data store bermakna retrieve or menggunakan.
19) Suatu data flow memiliki frase kata benda. Boleh ada lebih dari satu frase kata benda data flow pada satu tanda panah, selama semua aliran pada panah tersebut bergerak bersama sebagai satu paket.
DFD Levels
DFD dibagi menjadi beberapa level agar ukuran dan kompleksitasnya dapat dikendalikan. Context level adalah DFD yang menunjukkan paling sedikit hal-hal yang rinci (detail) . Tiap level berikutnya (Level Zero, Level One, Level Two, dst) membagi suatu proses pada diagram sebelumnya menjadi lebih rinci. Keseimbangan (balance) antar levels harus selalu dijaga . Semua inflows dari dan outflows ke sources/sinks eksternal harus sama dari level ke level berikutnya.
Context level DFD
Diagram konteks menggambarkan satu proses (merepresentasikan keseluruhan sistem) dan sources/ sinks yang merepresentasikan batasan sistem.
Context diagram untk suatu contoh sistem/collection. Sistem yang diteliti diletakkan di tengah dan diberi label angka 0.
Contoh DFD Level Zero
Sistem sales/collection memiliki 3 proses utama : - proses customer orders (1,0)
- proses customer deliveries (2,0) - proses customer payments (3,0)
Contoh DFD Level One
DFD untuk proses 1,0 (Process customer orders). Proses tersebut terdiri dari dua proses “ Approve and record customer order data” dan “Generate information about orders”,keduanya diberi label 1.1 dan 1,2
Membandingkan DFD dan Flowchart
Perbedaan utama antara flowchart dan DFD:
1.) Representasi karakteristik fisik dan logika dalam suatu sistem
- Flowchart menggambarkan karakteristik fisik sistem - DFD mengabaikan atribut fisik sistem
Sebagai ilustrasi: misalkan kita ingin mendokumentasikan data flow pada skenario sistem manual berikut:
- Seorang supervisor pada suatu pabrik mengumpulkan kartu absen dari para pekerja di departemennya dan me-review kalkulasi total waktu kerja untuk minggu tersebut - Supervisor tersebut mengirimkan kartu absensi pada bagian accounting payroll, yang akan digunakan oleh seorang clerk untuk merekam (record) upah mingguan pada record file upah tiap karyawan, kemudian kartu absensi tersebut di-arsipkan secara alfabetis
Contoh DFD Level Two
Approve and record customer order data terdiri atas 4 subproses pada gambar di atas
Ringkasan
Pemodelan task level merepresentasikan aliran kerja berbagai aktivitas dalam sistem informasi perusahaan
Pemodelan task level sangat bermanfaat untuk merepresentasikan tahap2 individual yang membentuk suatu events, namun tahap2 tersebut dapat dirubah, karenanya tidak boleh dijadikan sebagai elemen dasar pada arsitektur basis data perusahaan
System flowcharts dan data flow diagrams adalah dua alternatif cara untuk merepresentasikan model-model task level. Masing-masing memiliki kelebihan dan kekurangan
Untuk membuat model task level, kita harus memahami media fisik, jenis file dan metode pemrosesan Payroll DFD vs System flowchart
Updated payroll DFD and System flowcharts
Bila accoutning departemen bagian payroll melakukan otomatisasi proses dengan menggunakan pita maqgnetik Second update to payroll DFD and System flowcharts
Bila accounting departemen bagian payroll mengupdate ke magnetic disks
Suatu model konseptual merepresentasikan realita dalam suatu bentuk abstraksi yang dapat digunakan untuk mengembangkan suatu sistem informasi dalam berbagai format (relational, object oriented, dll)
Tidak bergantung pada tipe h/w dan s/w
Tidak bergantung pada tipe model logika (logical model) apa pun
Suatu model logika merepresentasikan realita dalam format yang sesuai dengan model basis data tertentu (contoh relational atau object-oriented)
Tidak bergantung pada h/w dan s/w
Bergantung pada tipe model logika yang dipilih
Suatu model fisik (physical model) dibuat secara khusus untuk suatu paket s/w basis data tertentu.
Bergantung pada h/w, s/w dan pada tipe model logika yang dipilih
CHAPTER 6
Relational Database Model
Relational model adalah suatu tipe model logika basis data yang diciptakan oleh E.F. codd pada tahun 1969. Relational model berbasiskan pada teori himpunan dan predicate logic (terformalisasi dengan baik, sehingga perilakunya dapat diprediksi). Suatu relational database terdiri dari berbagai tabel (hubungan) yang terhubung satu sama lain melalui penggunaan primary & foreign keys.
FOREIGN KEY dalam suatu tabel, adalah primary key dari tabel lain yang telah diposting pada tabel pertama untuk membentuk suatu hubungan diantara dua table.
Tabel relational database terdiri dari kolom dan baris: 1. Baris disebut sebagai table extension atau tuples (urutan baris bukanlah merupakan suatu masalah).
2. Kolom disebut sebagai table intension atau schema. - Urutan kolom bukanlah merupakan suatu masalah
- Semua nilai dalam kolom dan baris harus mengikuti format data yang sama (contoh: tanggal, teks, dll)
3. Tiap sel dalam suatu tabel basis data (perpotongan kolom-baris) hanya dapat memilliki satu nilai saja (repeating groups tidak diperbolehkan).
Contoh Foreign Key
Beberapa prinsip-prinsip dalam relational model
1. Integritas entitas (entity integrity)
Suatu primary key dalam suatu tabel tidak boleh memiliki nilai null (kosong) Untuk memastikan keunikan entitas dan memungkinkan nilai primary key menjadi acuan bagi nilai foreign key.
2. Integritas referensi (referential integrity)
Nilai untuk suatu foreign key pada suatu tabel harus merupakan salah satu dibawah ini:
- Null (kosong)
- Sama dengan nilai primary key pada tabel asalnya 3. Satu fakta, satu tempat (one fact, one place)
Fakta = suatu pasangan nilai atribut kandidat kunci dengan nilai atribut lainnya . Fakta ditemukan pada extensional data
Contoh Integritas Referensi
Pelanggaran Aturan Satu Fakta Satu Tempat
1. Satu fakta ada di beberapa lokasi
Tiap nilai dari tiap atribut pada suatu baris berpasangan dengan primary key, sehingga bila suatu sel memiliki dua atau lebih nilai atribut, hal tersebut dikatakan sebagai beberapa fakta pada satu lokasi (atau disebut juga sebagai repeating group).
Konversi Konseptual menjadi Relational
Langkah 1 - Buatlah sebuah tabel terpisah untuk merepresentasikan tiap entitas pada model konseptual
1A: Tiap atribut dari entitas menjadi kolom pada relational table
2A: Tiap instance (anggota) dari himpunan entitas menjadi baris pada relational table
Langkah 2-4 melibatkan penentuan apakah tiap hubungan dalam model konseptual harus direpresentasikan sebagai suatu tabel terpisah atau di-posting sebagai foreign key Redundancy dan Load adalah faktor penentu yang penting - Redundancy = Satu fakta pada beberapa tempat atau beberapa fakta pada satu tempat
- Load = Persentase dari nilai non null pada suatu kolom Kardinalitas partisipasi mengkomunikasikan beberapa informasi mengenai redundancy dan load .
Kardinalitas maksimum - Aturan umumnya adalah untuk selalu mem-posting pada suatu tabel entitas “1” (Untuk menghindari “repeating groups” redundancy). Kita tidak boleh mem-posting pada entitas “N” (Hal tersebut menyebabkan “repeating groups” redundancy).
Kardinalitas minimum- Aturan umumnya adalah untuk selalu mem-posting pada suatu tabel entitas “1” (mandatory) (Untuk menghindari nilai null pada kolom foreign key). Aturan ini harus dilanggar pada beberapa kondisi (akan dijelaskan kemudian).
Contoh Aturan Umum -
Langkah 2 - Buatlah suatu tabel terpisah untuk merepresentasikan semua many-to-many relationship pada suatu model konseptual, atau pada pola kardinalitas partisipasi berikut:
(0,N)-(0,N) (0,N)-(1,N) (1,N)-(0,N) (1,N)-(1,N)
Suatu tabel terpisah harus dibuat untuk merepresentasikan hubungannya
- Primary key dari tabel entitas terkait di-posting pada tabel hubungan untuk membentuk primary key-nya. Primary key ini disebut sebagai suatu composite/concatenated primary key
- Hal tersebut mencegah redundancy - Tidak ada pengecualian untuk aturan ini.
Bila suatu foreign key di-posting pada kedua arah, redundancy akan menjadi suatu masalah bagi many-to-many relationships.
Langkah 3 - untuk pola kardinalitas partisipasi (1,1)-(1,1), pertimbangkan apakah dua entitas terpisah secara konseptual atau apakah keduanya harus digabungkan. Bila harus dibiarkan terpisah, maka :
3A: posting-lah primary key dari suatu tabel entitas pada tabel entitas lainnya sebagai foreign key.
3B: tidak menjadi masalah primary key entitas mana yang di-posting pada tabel entitas lainnya, tetapi jangan mem-posting keduanya :
- Jangan membuat suatu tabel terpisah
- Redundancy dihindari secara otomatis dan load bukan merupakan suatu masalah bila suatu foreign key di-posting pada tabel manapun dalam hubungan (1,1)-(1,1)
Langkah 4 - untuk hubungan lain yang memiliki partisipasi (1,1) dengan satu himpunan entitas, posting-lah primary key entitas terkait pada tabel entitas (1,1) sebagai foreign key atau untuk pola kardinalitas partisipasi berikut :
(0,N)-(1,1) (1,N)-(1,1) (0,N) (1,N) (0,1)-(1,1) (1,1)-(0,1)
Jangan membuat tabel terpisah
Posting-lah suatu foreign key pada tabel entitas (1,1) dari tabel entitas lainnya
Redundancy akan dihindari dan load bukan merupakan suatu masalah bila instruksi ini diikuti
Bila posting dilakukan pada arah yang berlawanan, redundancy [untuk maksimum N] atau load [untuk minimum 0] akan menjadi suatu masalah
Langkah 5 - untuk hubungan lainnya yang memiliki partisipasi (0,1) pada satu atau kedua entitas, pertimbangkanlah load-nya atau untuk pola kardinalitas partisipasi berikut:
(0,N)-(0,1) (1,N)-(0,1) (0,1)-(0,N) (0,1)-(1,N) (0,1)-(0,1) Aturan untuk maximum cards mengharuskan posting pada suatu (0,1) atau membuat tabel terpisah; tidak boleh melakukan posting pada (0,N) atau (1,N). Aturan untuk minimum cards menyebutkan bahwa tidak boleh melakukan posting pada (0,1) karena hal tersebut akan mengakibatkan nilai null yang akan mengakibatkan pemborosan tempat pada basis data. Namun demikian suatu tabel terpisah tidak akan membuang-buang tempat, maka lebih baik ikuti aturan maksimum dan langgar aturan minimum
5A - posting-lah primary key entitas terkait pada tabel entitas (0,1) sebagai suatu foreign key untuk hubungan manapun yang akan mengakibatkan high load
5B - buatlah tabel terpisah untuk hubungan manapun dimana posting suatu foreign key akan menyebabkan low load. Catatan: untuk (0,1)-(0,1), langkah 5A, posting pada arah manapun akan mengakibatkan highest load; bila kedua arah tidak mengakibatkan high load, maka ikuti langkah 5B Contoh Load Considerations (1)
Contoh Load Considerations (2)
Penempatan Atribut Hubungan
Bila hubungan menjadi suatu tabel terpisah, maka atribut hubungan ditempatkan pada tabel tersebut. Bila hubungan dapat direpresentasikan dengan cara mem-posting foreign key, atribut hubungan di-posting berdampingan dengan foreign ke.
Fixing One Fact Multiple Places
Employee
Fakta-fakta apa saja yang memiliki beberapa lokasi pada tabel ini?
Dapatkan model ER yang direpresentasikan oleh tabel ini!
Apakah model ER-nya benar? Model ER nya harusnya seperti apa?
Bagaimanakah relational model yang benar?
Contoh Lainnya :
1. Fakta apa saja yang ada di beberapa tempat? 2. Bagaimana caranya menghindari hal ini?
Physical Implementation of Relational Model in Microsoft Access
Microsoft Access digunakan pada chapter ini untuk mendemonstrasikan penggunaan model logika ke dalam model praktik. Praktik ini memungkinkan kita untuk mengenal pembuatan tabel di Ms. Access serta mengkomunikasikan informasi tentang link antara beberapa tabel (seperti primary keys yang dikaitkan antara satu tabel dengan tabel lainnya). Di Ms. Access juga terdapat Access Help, dimana kita bisa membaca beberapa instruksi didalamnya perihal informasi yang belum kita ketahui.
Creating and Working with Databases
Untuk memasukkan tabel di Ms. Access, kita harus membuat terlebih dahulu file database. Hal ini yang menjadi perbedaan antara produk – produk Microsoft dengan Ms. Access. Pada Ms. Access, kita harus membuat file terlebih dahulu serta menamai file tersebut sebelum kita bekerja (input data atau mengisi tabel) pada Ms. Access. Pada saat membuka Ms. Acceess, maka akan disajikan New Blank Database, kemudian kita click on New Blank Database, dan isi File Name serta store database kita sesuai dengan driver mana yang ingin kita gunakan untuk menyimpan hasil kerja kita dengan Ms. Access.
Halaman Muka Microsoft Access
Example 1 : Creating and Connecting Entity Tables
Untuk membuat tabel penjualan (sales table), maka masukkan 4 macam field, yaitu SalesID, Date, Amount dan Salesperson. Tipe data untuk masing – masing field antara lain : SalesID menggunakan Text, Date menggunakan Date/Time, Amount menggunakan currency dan Salesperson menggunakan Text. Setelah itu, kita haus menentukan primary key untuk tabel pertama ini. Yaitu SalesID. Dengan cara, click SalesID field, kemudian click primary key, maka SalesID akan langsung menjadi primary key pada tabel pertama ini. Pada Ms. Access 2007, pada pengetikan field awal paling kanan, maka secara otomatis akan menjadi primary key pada tabel yang sedang kita kerjakan. Jika, primary key tidak berada pada pengetikan awal di field pertama, kita masih bisa menentukan primary key yang lainnya, dengan cara simpan terlebih dahulu tabel yang telah kita buat, kemudian klik kanan pada nama tabel yang telah kita buat, dan pilih Design View, maka disitu kita akan bisa mengubah field mana saja yang bisa kita jadikan primary key (Design - Primary Key). Setelah semuanya sudah diketik, maka simpan tabel tersebut dengan file Sale.
Save tabel sale
Setelah kita berhasil menamai tabel pertama tadi dengan sale, maka langkah berikutnya adalah membuat tabel lainnya. Dengan cara, tutup tabel sale yang telah kita simpan tadi, dan buka serta buat tabel baru lagi. Yang isinya antara lain : SalespersonID, Name dan Telephone dan jadikan SalespersonID sebagai primary key pada tabel ini, kemudian simpan dengan file Salesperson.
Sekarang kita telah memiliki 2 tabel yaitu sale dan saleperson. Lalu, icon relationship, ketika telah muncul, maka drag kedua tabel tadi dan klik add, maka akan mucul edit relationship tab, pada tab tersebut klik enforce referential integrity dan cascade update related fields, setelah itu klik create. Enforced referential integrity merupakan pilihan yang sangat bagus untuk di klik karena jika kita merubah customer ID maka hal tersebut juga akan mengubah di seluruh tempat. Sedangkan opsi cascade update related fields merupakan opsi yang berfungsi untuk tidak membiarkan kita kehilangan data data yang akan kita butuhkan di kemudian hari.
Edit Relationships
Setelah klik create, maka akan muncul tabel sale dan salesperson pada relational tabel kita. Kemudian, klik salespersonID pada tabel salesperson dan drag ke salesperson pada tabel sale, maka akan muncul ralationship layout sebagai berikut :
Relationships Layout
Terdapat angka 1 di Salesperson ID pada tabel salesperson, hal tersebut menunjukkan bahwa nilai partikular data untuk atribut tersebut bisa muncul di tabel maksimum satu kali. Hal tersebut masuk akal, hal itulah yang disebut dengan parimary key dan primary key tidak bisa memiliki nilai duplikasi (nilai yang sama). Sedangkan tanda infinity disamping salesperson pada tabel sale menunjukkan bahwa nilai partikular data untuk atribut tersebut bisa muncul di tabel untuk beberapa kali. Sebagai contoh Salesperson 654321 membuat penjualan terus menerus dan bisa selalu muncul pada tabel sale untuk beberapa kali pula.
Example 2 : Creating and Connecting Relationship Tables to Entity Tables
Untuk memulainya, hal yang sama harus dilakukan adalah membuat tabel di Ms. Access. Tabel pertama disimpan dengan nama file Student yang berisi beberapa field meliputi : StudentID (juga dijadikan primary key, dengan tipe data text), Name (tipe data text) dan Address (tipe data text). Tabel berikutnya disimpan dengan nama file Course yang juga berisis beberapa field antara lain : CourseID (tipe data text, dijadikan primary key), Description (tipe data text) dan Credits (tipe data number). Dan tabel terakhir adalah takes, yang berisi field antara lain : StudentID (tipe data text), CourseID (tipe data text) dan Grade earned (tipe data text). Untuk tabel takes, ada 2 primary key, yaitu StudentID dan CourseID.
Cara mengatur untuk memiliki dua primary key adalah, ketika telah kita simpan tabel takes, maka klik kanan pada tabel tersebut, pilih Design View, kemudian block StudentID serta CourseID dan kemudian klik icon primary key, maka dua duanya sekarang sudah akan menjadi primary key.
Relationships Layout
Ketika ketiga tabel tersebut sudah berhasil dibuat, kemudian klik relationship icon. Ketika sudah muncul tabel di relationship, maka : klik StudentID di tabel student dan drag ke StudentID di tabel course serta klik CourseID di tabel course dan drag ke CourseID di tabel takes. Maka hasilnya adalah sebagai berikut :
Deleting Existing Relationships
Untuk menghapus relationship antara tabel, caranya adalah klik garis relationship antara tabel, kemudian klik tombol delete pada keyboard maka relationships antar tabel akan hilang.
Menghapus relationships antar tabel
Entering Data into Microsoft Access Tables
Datasheet view
Ketika kita telah selesai membuat tabel yang hubungan antara beberapa tabel telah dikomunikasikan dengan benar di Ms. Access, maka saat itulah kita telah siap untuk memulai memasukkan data kedalam tabel. 2 views yang dapat membantu kita untuk memasukkan data pada tabel antara lain : datasheet view dan form view. Di chapter ini, kita hanya akan membahas datasheet view. Caranya, ketika kita ingin memasukkan beberapa field di dalam tabel, kemudian ketik field-nya dan ketika ingin berpindah ke field berikutnya bisa dengan menekan tombol TAB pada keyboard. Ketika kita berpindah ke field lain dengan menggunakan TAB, maka ketika kita menekan TAB, software akan secara otomatis menyimpan data yang telah
pensil, hal itu menunjukkan data yang kita masukkan saat ini di posisi tersebut.
Hal yang harus diingat adalah ketika kita telah klik enforce referential integrity dan telah memasukkan data ke dalam field yang sesuai, maka kita harus hati – hati untuk memasukkan datanya. Berusahalah hati hati dalam memasukkan data. Jika kita memasukkan data yang salah, maka kita harus segera memperbaiki dengan segera dimana letak kesalahan data tersebut sebelum kita memasukkan data berikutnya ke dalam tabel Ms. Access.
Concluding Comments
Di chapter ini kita telah mempelajari bagaimana cara mengambil representasi secara konseptual dari enterprise yang nyata kemudian mengubahnya, pertama ke dalam logika hubungan tabel dan kemudian praktik nyata ke dalam Microsoft Access software. Kita juga mempelajari bagaimana memasukkan data pada tabel. Di chapter berikutnya, kita akan mempelajari sesuatu yang bisa kita lakukan setelah memasukkan data pada database yang relasional. Di situlah fungsi yang sesunggunya pada database relasional bisa kita temukan. Ketika kita memasuki chapter tersebut, jangan lupakan apa yang telah kita dapatkan dan telah kita pelajari di chapter ini. Pengertian yang kuat pada desain tabel adalah merupakan dasar pengertin yang kuat pula untuk querying. Pengertian yang kuat tentang querying merupakan dasar yang kuat untuk retrieval of valid data, yang kemudian hasil akhirnya sangat mempengaruhi pengambilan keputusan. Inilah pentingnya mengapa pengguna sistem enterprise harus benar – benar mengerti dasar dari database relational.
Bisnis membutuhkan banyak informasi dalam menentukan pengambilan keputusan. Informasi bisa didapatkan dari berbagai data namun beberapa data bisa diagregasi dalam berbagai bentuk. Karena data disimpan dalam beragam format sesuai dengan kebutuhan, maka dibutuhkan skill tertentu untuk bisa secara efektif memanipulasi data. Beberapa ketentuan yang dibutuhkan untuk menghasilkan sebuah informasi yang baik yaitu pertama sumber data harus didesain dengan baik.. Kedua , data harus dibuat oleh ahli atau orang yang memiliki pengetahuan baik bagaimana memanipulasi data dan yang terakhir pemanipulasi data harus mengetahui output dari hasil olahan data. Beberapa bahasa manipulasi data akan dijelaskan selanjutnya.
RELATIONAL ALGEBRA (Aljabar relasional)
Aljabar relasional adalah sebuah bahasa query prosedural yang terdiri dari sekumpulan operasi dimana masukkannya adalah satu atau dua relasi dan keluarannya adalah sebuah relasi baru sebagai hasil dari operasi tersebut. Tiga operator utamanya adalah select, project dan join. Operator ini nantinya akan membantu dalam memanipulasi tabel relational database. Project merupakan subset vertikal dari tabel, sementara select merupakan subset tabel horizontal. JOIN, adalah operator yang menggabungkan hubungan antar operator aljabar Project dan Select.
CHAPTER 7
- Project Example
Di dalam contoh ini, Operasi Proyeksi menggambarkan suatu relasi yang berisi hanya Atribut Staff yang ditunjuk staff number, first Name, last name, dan salary di dalam order yang ditetapkan itu. Hasil dari operasi ini diperlihatkan pada gambar :
Operasi Proyeksi bekerja pada relasi tunggal R dan menggambarkan suatu relasi yang berisi suatu subset vertikal dari atribut yang ditetapkan dan mengeliminir salinan.
- Select Example
Di sini, relasi masukan adalah staff dan predikat adalah gaji (salary) > 10000. Operasi select menggambarkan suatu relasi hanya berisi Staff itu tuples dengan suatu gaji lebih besar dari £ 10,000. Hasil dari operasi ini ditunjukkan pada gambar.’
Daftar semua staff dengan suatu gaji lebih besar dari£10,000
σ salary > 10000 (Staff) - Join Example
Operasi Join, yang dikombinasikan dua relasi untuk membentuk suatu relasi baru, adalah salah satu dari operasi yang penting di dalam algebra/aljabar relasional.
Operasi join terdiri dari dua maksudnya: 1. Inner join (atau equi-join)
Hanya mengikutsertakan records dari kedua tabel yang memiliki nilai yang sama pada field yang digabungkan.
2. Outer join
Mengikutsertakan semua records dari satu tabel, dan mencocokkan records dari tabel lain yang nilai pada field yang digabungkannya adalah sama.
Contoh left outer join
STRUCTURED QUERY LANGUAGE
Meskipun aljabar relasional (relational algebra) dikembangkan sebagai bagian dari model relasional, tapi itu bukan data manipulation language yang paling umum digunakan saat ini. Salah satu kelemahan dari aljabar relasional (relational algebra) adalah bahwa setiap operator harus diselesaikan dalam query yang terpisah. Yang artinya,
proyeksi dan seleksi tidak dilakukan dalam query yang sama atau untuk mudahnya berarti dua pertanyaan yang perlu dilakukan untuk mencapai dua operasi.
Structured Query Language (SQL) dikembangkan untuk memungkinkan kinerja beberapa operasi dalam satu query. Dipercaya juga bahwa penggunaan format standar untuk setiap query akan menyederhanakan tugas pembangunan query, yang telah terbukti sangat sulit bagi banyak pengguna. Untuk aljabar relasional, pengguna harus belajar syntax yang berbeda untuk masing-masing dari berbagai operator aljabar relasional (termasuk tiga yang telah kita bahas serta beberapa orang lain). Dalam SQL, setiap query pencarian informasi mengikuti, sintaks yang telah ditetapkan terstruktur sebagai berikut:
a. SELECT – Attribute name(s) b. FROM – Table name(s)
c. WHERE – Condition criteria is met;
Perlu diperhatikan bahwa titik koma (semicolon) pada akhir pernyataan SQL sangat penting jika sistem yang digunakan memungkinkan pernyataan lebih dari satu SQL yang akan dieksekusi dalam panggilan yang sama ke server database. Jika hal itu dibiarkan, pertanyaan tidak akan dieksekusi. Sebagian besar relational database software packages saat ini secara otomatis menempatkan titik koma pada akhir pernyataan untuk membantu menghindari kesalahan syntax yang mungkin terjadi saat itu hilang.
Untuk beberapa permintaan tidak setiap komponen dalam syntax ini diperlukan, dan untuk pertanyaan lain komponen tambahan harus disertakan, tetapi secara umum setiap pernyataan SQL harus sesuai dengan format ini. Meskipun sebagian besar perusahaan dan sebagian besar paket perangkat lunak database tidak menggunakan langsung syntax aljabar relasional, akan sangat membantu ketika query digunakan untuk mempertimbangkan tiga operator aljabar relasional utama dan menentukan bagaimana menyelesaikannya, entah menggunakan SQL ataupun QBE. Untuk memulai kita meneliti bagaimana pemilihan, proyeksi, dan bergabung operator yang dicapai dalam SQL.
Correspondence of Relational Algebra Operators and SQL Statement Components
Komponen pertama dari setiap pernyataan SQL (yaitu, SELECT komponen) menentukan mana atribut harus dimasukkan dalam jawaban atas pertanyaan tersebut. Ingat bahwa atribut adalah kolom tabel. Jadi komponen ini pernyataan SQL menyelesaikan operator proyeksi relasional aljabar. Komponen kedua dari setiap pernyataan SQL (yaitu, FROM komponen) menentukan tabel yang berisi data yang akan disertakan dalam jawabannya. Jika hanya ada satu meja, komponen ini dari pernyataan SQL hanya
mengidentifikasi tabel yang itu. Jika beberapa tabel yang diperlukan untuk memenuhi permintaan informasi, komponen ini membantu untuk mencapai aljabar relasional JOIN operasi (tetapi tidak mencapai bergabung tanpa komponen berikutnya). Komponen ketiga dari pernyataan SQL dapat melayani dua tujuan.
Dalam kombinasi dengan FROM komponen, hal ini membantu untuk mencapai aljabar relasional JOIN dengan menentukan kolom untuk dua tabel yang bergabung harus memiliki nilai yang sama. Atau komponen WHERE menentukan kriteria yang harus dipenuhi oleh catatan dalam rangka untuk dimasukkan dalam jawabannya. Dengan demikian komponen WHERE dari pernyataan SQL menyelesaikan operator pilihan aljabar relasional.
PROJECT Example
Pertanyaan pertama yang dihasilkan daftar nama karyawan dan nomor telepon yang akan digunakan untuk pohon telepon darurat. Query hanya dibutuhkan operator proyeksi saja. Dalam SQL query dinyatakan sebagai berikut:
SELECT – LastName; FirstName, Telephone FROM – Employee;
Perhatikan bahwa ketika kita tidak mencoba untuk menyelesaikan aljabar relasional JOIN maupun aljabar relasional SELECT operator, tidak ada kriteria yang harus dipenuhi sehingga tidak ada komponen WHERE dalam pernyataan.
- SELECT Example
Permintaan kedua kami diformulasikan dengan aljabar relasional adalah daftar karyawan (termasuk semua atribut) yang upah kurang bahwa $ 15 per jam. Query ini diperlukan relasional Operator pilihan aljabar tapi tidak ada proyeksi atau bergabung operator. Pernyataan SQL untuk query ini adalah sebagai berikut:
SELECT – *
FROM – Employee WHERE – PayRate <15.00;
Perhatikan bahwa tanda bintang (*) adalah simbol wildcard dan hanya memberitahu database software package untuk memasukkan semua atribut dalam hasil query.
- Combining SELECT and PROJECT in SQL
Perlu diperhatikan bahwa sangat mudah untuk menggabungkan operator relational algebra selection dengan operator proyeksi dalam sebuah pernyataan SQL tunggal. Katakanlah sebuah perusahan ingin mengambil nama dan nomor telepon dari karyawan yang memiliki upah kurang dari $15 sehingga perusahaan bisa menelepon karyawan untuk memberitahu mereka kalau mereka mendapatkan biaya kenaikan hidup. Berikut pernyataan SQL menyelesaikan semuanya dua pernyataan sebelumnya itu. SELECT – LastName, FirstName, Telephone
FROM – Employee WHERE – PayRate <15.00;
JOIN operation pada SQL sama dengan JOIN statement pada algebra. Operasi ini digunakan untuk mendapatkan informasi gabungan. Statementnya adalah:
SELECT *
FROM Employee, Department
WHERE Employee.DeptID=Department.DepartmentID Dalam contoh agebra, kita harus mengeksekusi query kedua untuk memenuhi PROJECT operation. SQL statement dapat diubah untuk memenuhi JOIN dan PROJECT hanya dalam satu query, seperti:
SELECT LastName, FirstName, Name FROM Employee, Department
WHERE Employee.DeptID=Department.DepartmentID Perlu diingat bahwa dalam relational algebra kita harus menggunakan dua query terpisah untuk memenuhi dua operasi berbeda. Namun pada SQL kita mengombinasikan keduanya dalam satu query. Untuk menentukan apakah sebuah JOIN harus menjadi outer join (untuk mengambil seluruh data pada table yang tidak ada sebelumnya dalam table gabungan), syntax perlu bervariasi. Outer JOIN harus dispesifikasi sebagai Left Join maupun Right Join pada klausa From dalam SQL statement. Penggunaan kanan atau kiri tergantung pada informasi yang kita inginkan pada SQL statement tersebut. Contoh:
SELECT DeptName, LastName, FirstName, Name FROM Department LeftJoin Employee
On Department.DepartmentID=Employee.DeptID
Klausa lain kita butuhkan untuk memenuhi query lain untuk pengambilan keputusan. Misalnya, kita membutuhkan kemampuan untuk menghitung jumlah berdasarkan bidang pada database, lebih baik kita tidak menyimpan derivable attributes yang nilainya dapat berubah jika dimasukkan data baru.
Using Mathematical, Special Comparison, and Logical Operators in SQL Queries
Operator Komparasi Matematis terkadang dibutuhkan sebagai kriteria dimana nilai data dipilih untuk dicantumkan dalam hasil query. Contoh operator komparasi matematis adalah:
= sama dengan < kurang dari > lebih dari
<= kurang dari sama dengan >= lebih dari sama dengan
<> tidak sama dengan (dalam beberapa software di notasikan dengan !)
Operator komparasi tersebut dapat diaplikasikan pada berbagai tipe bidang. Karena operator komparasi membantu dalam memisahkan beberapa baris, maka operator tersebut terdapat pada WHERE clause dari SQL
statement. Contoh, SELECT * FROM Employee WHERE PayRate < 15.00.
Operator komparasi special diantaranya adalah BETWEEN, yang mengidentifikasi permintaan dalam range nilai tertentu. Penggunaanya sama seperti penggunaan kombinasi dari kurang dari atau lebih dari.
Contoh:
WHERE SaleDate >=6/1/2005 AND SaleDate <=6/30/2005 atau dapat dituliskan dengan:
WHERE Sale Date BETWEEN 6/1/2005 and 6/30/2005 Selain itu, terdapat operasi IS NULL, yang mengidentifikasi permintaan dimana nilai atribut tidak ada. Sebaliknya, EXIST mengidentifikasi permintaan dimana nilai atribut ada. Queries dapat mengandung logical operator, yang dikenal dengan operator pencari Boolean, seperti AND, OR, dan NOT. AND menunjukkan intersepsi, OR menunjukkan seperangkat union, sedangkan NOT mengidentifikasi permintaan yang tidak memenuhi satu atau lebih kondisi.
Using Calculation and Aggregation Function in SQL Queries
Terdapat dua jenis kalkulasi yang dibutuhkan dalam queries. Salah satunya adalah menggunakan operasi matematika seperti rata-rata atau jumlah dari nilai pada satu kolom. Perhitungan dalam kolom adalah aggregation function. Untuk menghitung rata-rata, dapat menggunakan
perintah AVG didepan field name pada SELECT clause. Contoh:
SELECT AVG(PayRate) FROM Employee
Aggregation function lainnya adalah SUM (jumlah), MAX (nilai terbesar), MIN (nilai terkecil), dan COUNT (menghitung banyak data pada kolom). Untuk mengelompokkan data yang dihitung berdasarkan kombinasi tertentu, dapat digunakan perintah GROUP BY yang ditambahkan setelah komponen WHERE.
Contoh:
SELECT Date, SUM(Amount) FROM Sale
GROUP BY Date
Jenis perhitungan lain yang dibutuhkan dalam queries adalah perhitungan matematis menggunakan nilai data dari dua bidang dalam informasi. Misalkan, ingin mengetahui hubungan antara Sale dan Inventory. Maka digunakan formula seperti berikut:
SELECT QtySold*UnitSellPrice As SaleLineExtension FROM Stockflow
Query by example (QBE) in MS Access
Suatu interface yang dikembangkan agar query dapat dilakukan dengan lebih mudah (point-click). Pengguna tidak harus mempelajari kode SQL untuk melakukan query,
