Desain dan Analisis Sistem Dari Suatu Sistem Business Event Driven Sistem Informasi Julius Nursyamsi
Objektif
Objektivitas dari bab ini untuk membantu anda memahami langkah – langkah kunci di dalam mendesain dan menganalisis aplikasi teknologi informasi – IT.
Analisis dan Desain Dari Suatu Aplikasi IT Business Event-driven
Merancang kualitas aplikasi IT memerlukan suatu pemahaman pengorganisasian termasuk didalamnya sasaran saat ini dan yang inginkan, strategi - strategi, rantai nilai, risiko - risiko, dan proses – proses bisnis Terdapat banyak macam metode untuk menganalisis dan merancang sistem informasi. Bagaimana para profesional melangkah dari suatu kebutuhan bisnis untuk informasi dalam menciptakan prasarana IT secara fisik dapat menyediakan suatu informasi ?
Metode – Metode Desain dan Analisis Sistem
Gambar 1 masa sekarang systems analysis and design life cycle (SDLC) dari J.A. Hoffer, J.F. George, and J.S. Valacich Gambar 2 menampilkan systems development process diperkenalkan oleh J.L. Whitten, L.D. Bentley, and V.M. Barlow Pendekatan desain dan analisis lain, termasuk Disain dan analisa berorientasi-objek, Pembuatan prototype / bentuk dasar, Rekayasa sistem, Menggabungkan disain aplikasi, Disain keikutsertaan, Disain sistem pokok, Otomatisasi SDLC menggunakan alat-alat CASE
Project Identification and Selection
Langkah dari Systems Analysis and Design Life Cycle (SDLC)
I. Phase IV. Analisis Phase– Implementasi Menentukan persyaratan sistem dan Pemeliharaan dan persyaratan – struktur dengan melaksanakan menciptakan sistem model proses, model coding, testing, dan instalasi, model Analysis III.logika, Phase Desain data dokumentasi, konseptual. pelatihan Fisik – merancang Logical user, II. Phase Desain Logika filemendukung secara fisik,user, dan database, pemeliharaan – mengembangkan dan sistem. Design desain logika dari intruksi Physical database dan pemograman. Design merancang forms, laporan-laporan, Implementation penghubung, dan dialog – tanya jawab. Project Initiation
J.A. Hoffer, J.F. George, and J.S. Valacich, Modern Systems Analysis and Design, Reading, Massachusetts: Addison Wesley, 1999.
Maintenance
The Systems Development Process Systems Planning
Detail sistem yang berjalan dan pembatasan
Systems Support
Proses pengembangan aplikasi terencana
Detail sistem yang berjalan dan pembatasan
Sistem informasi produksi
Systems Implementation
Pernyataan desain teknis
Systems Analysis Pernyataan Persyaratan bisnis
Systems Design
J.L. Whitten, L.D. Bentley, and V.M. Barlow, Systems Analysis and Design, instructors ed., 3rd ed. Burr Ridge, Ill.: Richard D. Irwin, 1994.
Phase 1: Analisis Sistem
Langkah 1-A: Mendefinisikan persyaratan sistem Langkah 1-B: Strukturisasi persyaratan sistem menggunakan pemodelan proses Langkah 1-C: Strukturisasi persyaratan sistem menggunakan model-model logika langkah 1-D: Strukturisasi persyaratan sistem menggunakan pemodelan data konseptual Langkah 1-E: Pemilihan suatu strategi desain
LANGKAH I-A: Analisis Sistem Mendefinisikan persyaratan sistem
Setelah organisasi memiliki : Identifkasi akan kebutuhan akan suatu proyek sistem dan dengan sukses membuat suatu kasus bisnis untuk membenarkan ivestigasi waktu dan kebutuhan dana untuk memulai suatu proyek, suatu team proyek mengorganisir dan merencanakan pekerjaan untuk diselesaikan. Team mempertimbangkan biaya-biaya, manfaat-manfaat, kelayakan, tanggung jawab, dan timeline proyek. Setelah detail – detail lengkap mereka menentukan persyaratan sistem: Apakah yang merupakan harapan-harapan dari sistem ini? Apa pekerjaan dan keputusan yang akan mendukung? Apa objektif yang akan membantu organisasi untuk memenuhi?
Menentukan Persyaratan Sistem
Analisisn bisnis anda mennyoroti aktivitas yang suatu organisasi butuhkan untuk membentuk eficiensi dan efektifitan untuk memenuhi objektivitas. Suatu sistem informasi perlu mendukung aktivitas-aktivitas ini. Tambahkan proses informasi, termasuk penyimpanan data, dan aliran data, untuk analisis Pertimbangkan permintaan lingkungan dan bayangkan cara-cara inovasi pada sistem untuk memungkinkan objektivitas organisasi dan proses – proses yang diinginkan.
Gambar 4-3 Model REAL Christopher Inc.
e ad m f is p o u
Sumber daya Agen Kejadian Christopher Inc. menyediakan topi baseball Order kepada team baseball liga utama untuk di jual s ke a t personnel Receive di dalam ballparks mereka. Sementara ludes Melaporkanincinformasi customer menganalisis proses bisnis mereka, team p l Inventory a ces bermanfaat ke order analisis Christopher’s mengenali tiga Customer informasi to aktivitas operasional kunci : terimaes order dari Pemeliharaan datapelanggan o Shipping Menyimpan g team-team baseball (siapa pelangan referensi tentang tes personnel Ship u c data kejadian e Christopher’s), topi dipaket dan dikirim x sumber daya, agene Order kepada team-team (penjualan dari car barang operasional agen, dan lokasi-lokasi ri e d Shipping dagangan), dan menerima pembayaranby dari firm is kept team-team increases Collect at sends Bank Cash payment takes in Cashier
Struktur Proses – Proses Informasi Data Data Data
Maintaining Recording Reporting Process Process
Stimulus Stimulu Stimulu ss Response Response Response
Notification Notification Notification Untuk mendukung suatu proses-proses bisnis, suatu sistem harus mengumpulkan masing-masing peristiwa operasi yang mencetuskan kebutuhan Melaksanakan Proses-proses pelaporan mengambil mengubah data penyimpanan kejadiandata tentang sumber daya, agen-agen, dandan lokasi-lokasi dengan menentukan kejadian untuk merekam deskriptif data tentang kejadian, sumber agen-agen, danperistiwa lokasi-lokasi ke dalam informasi, operasional. Sistimdaya, itu harus mengizinkan data untuk menyimpan peristiwadan . Ketika datainformasi ditangkap selagi peristiwa operasiinfromasi terjadi, proses perekaman dapat untuk pelanggan. memformat Pemeliharaan referensi datapresentasi melibatkankepada menambahkan, menghapus, atau melaksanakan aturan bisnisini yang ditetapkan oleh manajemen untuk masing-masing Pandangan-pandangan terdiri atasagen-agen, keuangan dan kinerja dan mengubah boleh memodifikasi data tentang sumber daya, dan ukuran lokasi-lokasi (eg., peristiwa operasi. mengambil bentuk sumber oleh dokumen laporan hardcopy, aliran data produk-produk yang dari ditawarkan suatuhardcopy, penjual; mengubah suatu status Aturan-aturan ini adalah petunjuk, kebijakan-kebijakan, elektronik, atau query-query khusus -patokan-patokan, ad hoc perkawinan karyawan; dan menambahkan suatu. penjual baru kepada daftar penjual). dan/atau yangtindakan-tindakan, diharapkan untuk meningkatkandokumentasi mutu operasional Aliranprosedur-prosedur datauntuk ini memberi hak Sasaran itu memelihara akurat, lengkap, danmenyediakan data tepat waktu tentang kepada dan informasi dengan beberapa masalah seperti kesalahan-kesalahan, fungsi bisnisagen-agen, yang lainmengurangi atau pihak yang luar, dan mendukung sumber daya, dan kepada lokasi-lokasi terlibat di dalam pengambilan kejadian ketidakteraturan-ketidakteraturan, atau tipuan. Idealnya, eksekusi keterkaitan keputusan untuk strategis dan operasional. operasional proses yang anda sedang memperagakan - modeling peristiwa operasi dan proses informasi terjadi secara serempak.
LANGKAH I-B: Analisis Sistem – Strukturisasi Persyaratan Sistem Menggunakan Pemodelan Proses
Beberapa motode analisis menciptakan beberapa versi diagram alur data, termasuk Diagram alur data konteks - context data flow diagrams, Diagram alur data sistem fisik umum, diagran alur data sistem logika umum, dan Diagram alur data sistem logika usulan. Sering kali, masing-masing diagram alur data termasuk suatu uraian dari setiap alur data.
Gambar 4-4 Christopher Inc., Diagram Konteks Pesanan Informasi Suatu diagram konteks lingkaran menunjukkan O diinginkan menunjukkan dan Shipping/tagihan Pembuatan komputer Sales /sumberpengolahan Konsumen tujuan-tujuan data yang di keputusan collection luar batasan-batasan atau system Pembayaran Christopher Inc. memerlukan suatu lingkup dari sistim yang sistim yangInc. memungkinkan Christopher memerlukan Akhirnya, Sistem Christopher dianalisa.. komunikasi dengan pelanggansuatu sistim yang dapat Inc. perlu mengizinkan akses pelanggan beberapa kali selama Shipping Data tidak Anda mengizinkan untuk mengirimkan oleh agen-agen internal (seperti proses (eg., pelanggan-pelanggan data pengiriman kepada menunjukkan penyimpan manajemendata danorder pengambilmemasukkan seperti juga pembawa-pembawa mereka dan data dan aliran data di pembayaran, dan Christopher data Carriers keputusan-pengambil-keputusan Konfirmasi menerima konfirmasi-konfirmasi Inc. pengiriman balik, lain) kepada datapengiriman dan informasi dalam batasan-batasan dari pengiriman dari pembawapenjualan, penagihan, dan data kritis. sistim. pembawa mereka. pembayaran).
Gambar 4-5 Christopher, Inc. Level 0 Data Flow Diagram rs e d Or
1.0 Proses Order pelanggan Pengiriman data permintaan
Konsumen
Tagihan
Pe mb a
ya ra n
2.0 Proses Pengiriman Ke konsumen
Per inf minta o rm a n asi
Permintaan informasi
Pembuat keputusan
Data pembayaran n a a tiba nt i i rm mas e 3.0 Proses P or Pembayaran inf dari konsumen
Gambar 4-6 Christopher Inc., Level 1 Data Flow Diagram Order
1.1 Setujui dan rekam data order pelanggan Mengirimkan Data Permintaan
Order disetujui
Data order konsumen
Data Order 1.2 Hasilkan informasi tentang order
Permintaan infromasi
Kamus Konteks
Beberapa analis-analis suka menambahkan lebih detil kepada konteks dan diagram alur data lain, dengan menyediakan elemen data bahwa terdiri dari alur data didalam diagram. Kita akan mengacu pada detail alur data ini seperti kamus konteks. Masingmasing isi kamus konteks terpisah dari didefinisikan oleh suatu tanda (=) dan menartikan pemakaian sebagai kelanjutan set dari lambang:
+
{}
Untuk menyambung unsur-unsur dari definisi Untuk mengidentifikasi unsur-unsur pengulangan dari definisi
Contoh Masukan kamus Konteks
Sales-Invoice = Invoice # + Sale-Date + Register # + Customer Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total Customer-Profile = Report-Date + Name + State + Birth date + Telephone + {Merchandise Description + Qty-Sold} Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold + %Margin + $ Contribution} Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-Period Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} + Total Sales + Total Contribution
Langkah – langkah Prototipe Tambahan Ketika proses andapelaporan sedang yang menciptakan diagram alur data atau Banyaknya diperlukan selama satu aplikasi adalah suatu work-flows untuk suatu proses bagaimana anda fungsi banyaknya pandangan-pandangan yangbisnis, diperlukan oleh informasi pelanggan. Anda akan memerlukan proses pelaporan untuk masing-masing mengetahui berapa banyaksatuperekaman, pemeliharaan, dan memerlukan pandangan keluaran. Untuk membantu rencana menentukan proses pelaporan yang anda perlukan pada suatuanda, aplikasi IT? berapa banyak yang harus mengikuti dari tiga jenis pelaporan uraian keluaran yangAnda dibutuhkan informasi pelanggan anda: anda dan diagram dapatsebagai menggunakan model REAL •Dokumen sumber: konteks sebagai suatu pemandu. yang dicetak atau -transmisi • diagram konteks contextelektronik diagramdokumentasi data peristiwa •laporan-laporan Preformated: • inflow dan outflow untuk melaporkan secara teratur digunakan oleh informasi pelanggan Anda memerlukan satukejadian proses pemeliharaan perekaman di di dalam dalam aplikasi Record data •Laporan-laporan khusus - ad hoc: IT Anda aplikasi IT untuk Anda masing-masing untuk masing-masing objek peristiwa sumber bisnis daya, agen, di Maintain sumber daya, agen, lokasi dan data melaporkan bahwa desain informasi pelanggan permintaan untuk dalam dan objek model lokasi aplikasi-aplikasi di dalam model REAL aplikasi-aplikasi REAL Report dokumen sumber, queri, pelaporan
menyediakan suatu pandangan baru atau suatu pandangan yang jarang digunakan
Kasus penyimpanan penjualan eceran McKell's Checkpoint Proses pelaporan untuk menangani fungsi manajemen kunci: Menggunakan contoh penjualan eceran kita, Empat proses-–rekening prosespelanggan pemaliharaan • Faktur Penjualan ; •Pelihara data konsumen, aplikasi IT ingin mempunyai:: • Profil Pelanggan -suatu pelaporan yang menyediakan informasi tentang dan kebiasaan-kebiasaan •Pelihara data barang dagangan, •Satupelanggan-pelanggan proses perekaman (i.e., merekam data pembelian mereka; •Pelihara data penjual dan yangperistiwa penjualan) untuk merekam yang • Penjualan Produk -suatu pelaporansatu menyediakan margin dan •Peliharan register jenis tipe barang dagangan yang kontribusi untukdata masing-masing diminati dijual; untuk menyimpan sumber daya, agen, dan data • Pendapatan Akuntansi lokasi terbaru dan-suatu valid pelaporan yang menyediakan suatu kalkulasi hasil penjualan untuk suatu periode yang spesifik ; • Menjual oleh Salesperson -suatu melaporkan bahwa detil barang dagangan dan sumbangan kepada hasil penjualan untuk masingmasing penjual)
Langkah 1-C: Strukturisasi Persyaratan Sistem Menggunakan Model-Model Logika
Setelah diagram alir data lengkap bahwa secara grafik menunjukkan alir data untuk memenuhi persyaratan-persyaratan sistim, banyak analis menggunakan model logika untuk mewakili logika dari prosesproses informasi penanda di dalam diagram-diagram alur data. Sasaran mereka untuk menghasilkan uraian-uraian dan diagram yang menyebutkan satu per satu logika yang terdapat di masingmasing proses penanda di dalam diagram-diagram alur data. Teknik-teknik yang digunakan selama langkah ini memasukkan di dalamnya struktur bahasa Inggris, tabel keputusan, pohon keputusan, dan diagram transisi status atau tabel-tabel.. Kita akan ikhtisar hanya satu saja teknik-teknik ini: Struktur Bahasa Inggris.
Struktur English
Structured English digunakan untuk merencanakan dan membangun langkah-langkah sehimpunan instruksi komputer (sebuah program) tanpa menggunakan bahasa pemrograman. Structured English digunakan untuk menentukan logik terinci dari setiap proses informasi (Exhibit 4-7). Structured English fokus pada keringkasan dan kejelasan dokumen yang merupakan hal pokok dari sebuah proses informasi dan menghilangkan :
kata sifat. Kata keterangan. Kalimat-kalimat gabungan. Ekspresi-ekspresi non-imperative (non-bentuk perintah). Semua kecuali sebuah himpunan terbatas struktur logik dan kondisional. Sebagian besar pemberian tanda baca. Detil-detil jenis catatan kaki.
Gambar 4-7 Contoh Struktur Inggris Data
Input Proses Output
Karena masing-masing Pesanan Pelanggan dilakukan mengikuti: 1. Mencari Nama Pelanggan jika ditemukan Konfirmasikan info pelanggan dengan pelanggan jika tidak menemukan Masukkan data pelanggan 2. Periksa ketersediaan permintaan inventori jika tersedia Konfirmasikan informasi kepada kapal jika tidak tersedia Informasikan pelanggan dengan konfirmasi pesanan 3. Sediakan pelanggan dengan Order Confirmation 4. Kirimkan pemberitahuan untuk agen mengemasi
Risiko Peristiwa Bisnis
Sebagai tambahan untuk memasuk logika dalam melengkapi suatu tugas yang diinginkan, langkah ini menyediakan suatu peluang untuk berpikir tentang jalannya teknologi informasi dapat digunakan untuk membantu mengurangi risiko bisnis dan informasi.
Satu peristiwa operasi yang terjadi di waktu atau urutan yang salah. Satu peristiwa operasi yang terjadi tanpa otorisasi yang tepat. Satu peristiwa operasi yang disertai agen internal yang salah. Satu peristiwa operasi yang disertai agen eksternal yang salah. Satu peristiwa operasi yang disertai sumber daya yang salah. Satu peristiwa operasi yang disertai jumlah sumber daya. Satu peristiwa operasi yang terjadi di lokasi yang salah.
Risiko – Risiko Peristiwa Informasi
Risiko peristiwa informasi memasukkan di dalamnya resiko-resiko yang berhubungan dengan taklengkap, taktepat, atau perekaman tidak syah, pemeliharaan, dan aktivitas informasi pelaporan:
Merekam resiko -Merekam resiko memasukkan di dalamnya merekam taklengkap, taktepat, atau data takberlaku sekitar satu peristiwa operasi. Data yang tidak sempurna mengakibatkan tidak di rekamnya semua karakteristik yang relevan pada suatu peristiwa operasi ke dalam penyimpan data. Ketidaktepatan-ketidaktepatan dari merekam data bahwa tidak teliti mewakili - menunjukkan peristiwa. Takberlaku mengacu pada data yang direkam tentang suatu peristiwa yang dibuat. Pemeliharaan risiko - Pemeliharaan risiko hal yang utama sama halnya dengan merekam risiko. Satu-satunya perbedaan adalah karena pemeliharaan data berhubungan dengan sumber daya, agen-agen, dan lokasi-lokasi dibandingkan dengan kejadian operasi.. Risiko-risiko pelaporan - Risiko-risiko pelaporan memasukkan di dalamnya data yang tidak sesuai digolongkan, tidak sesuai dengan meringkas, syarat kepada para pihak yang tidak syah, atau tidak menyiapkan dalam bentuk suatu cara yang tepat waktu. .
Langkah I-D: Analisis Sistem : Persyaratan membangun sistem menggunakan pemodelan data konseptual
Berfokus kepada spesifik data yang anda ingin menangkap untuk menguraikan kenyataan dan menghasilkan keluarankeluaran yang diperlukan kita menggunakan suatu model data konseptual.. Model data konseptual menunjukkan kesatuan-kesatuan atau object yang anda ingin mengumpulkan tentang data, dan memutuskan tentang artinya dan hubungan timbal balik dari antara object
Contoh Entity
Person : EMPLOYEE, STUDENT, or PATIENT Place : STATE, REGION, or COUNTRY Object : MACHINE, BUILDING, or AUTOMOBILE Event : SALE, REGISTRATION, or RENEWAL Concept : ACCOUNT, COURSE, or WORK CENTER
ERD – Entity Relationship Data
Data Entity
apapun, nyata atau abstrak, tentang yang kita ingimnkan untuk menyimpan data. Sinomim – sinomim memasukan jenis entity, kelas entity atau objek
Data relationship
Suatu asosiasi yang alami bahwa ada diantara satu atau lebih entity Aktivitas bisnis atau peristiwa bahwa menghubungkan satu atau lebih entity
Entity Name
Relationship Name
Contoh Konsumen Tempat/ atau di tempatkan oleh
Pesanan Berisi atau dimasukan oleh Pemasok
Kesatuan – kesatuan ; Entities
AGEN Kesatuan-kesatuan yang menguraikan peran-peran yang dimainkan di dalam suatu sistim. Biasanya menunjukkan orang-orang atau organisasi-organisasi PELANGGAN, AGEN, BINATANG, PELAMAR/PEMINTA, PEMINJAM, ANAK, KELAS, KLIEN, PEMBORONG, KREDITUR, DEPARTEMEN, KARYAWAN, PEMBERI KERJA, INSTRUKTUR, MANAJER, KANTOR, PENJUAL, PENYALUR, REGU, PENJUAL
Kesatuan – kesatuan ; Entities
Sumber daya - RESOURCES Kesatuan-kesatuan yang menguraikan berbagai hal yang terukur. berbagai hal Yang paling mudah terukur untuk mengidentifikasi karena anda dapat melihatnya. . BUKU, BAHAN KIMIA, KURSUS, DISK, PERALATAN, MESIN, MATERIAL, LOGAM, SUKU CADANG, PRODUK, PROGRAM, PELAYANAN, UNSUR POKOK, SARANA
Kesatuan – kesatuan ; Entities
Peristiwa - EVENTS Kebanyakan peristiwa-kejadian mudah diidentifikasi karena bisnis merekam data dalam bentuk form atau file-file. Peristiwa-kejadaian ditandai oleh suatu fakta yang terjadi atau mempunyai durasi PERSETUJUAN, APLIKASI, PERJANJAJIAN, PENUGASAN, BACKORDER, ANGGARAN, TUNTUTAN, KONTRAK, DEPOSITO, PENGELUARAN, PERAMALAN, FAKTUR, PEKERJAAN, LISENSI, PEMBAYARAN, PEMBELIAN PESANAN, REGISTRASI, RESERVASI, RESUME, SEMESTER, PENGIRIMAN, LANGKAH, TUGAS, UJIAN, PESANAN PEKERJAAN
Kesatuan – kesatuan ; Entities
Lokasi - LOCATIONS Entity dapat menguraikan lokasi - lokasi CABANG, BANGUNAN, KAMPUS, KOTA, NEGARA, DAERAH, RUANG, RUTE, DAERAH PENJUALAN, ZONE SEKOLAH, PROVINSI, RUANG SIMPAN, DAERAH PEMBERI SUARA, ZONE GUDANG
Entiti dan Kelas atau Kelompok Entity
Entiti suatu jenis yang dikelompokan ke dalam suatu kelompok kelas entity Dengan demikian, penggolongan kelas entity EMPLOYEE merupakan kumpulan semua entiti EMPLOYEE Kelas Entity digambarkan oleh struktur mereka Suatu kejadian dari entity mewakili entiti tertentu seperti Customer 1234 dan digambarkan oleh nilai-nilai dari atribut-atributnya Yang hanya dapat menentukan untuk membantu dalam mendapatkan kesatuan-kesatuan adalah suatu kesatuan yang biasanya merupakan nama benda ; INVOICE - FAKTUR Kejadian dari entity diidentifikasi dalam jamak – faktur-faktur (Invoices)
Atribut - Atribut
Atribut merupakan suatu pemilikan dari suatu kesatuan Atribut Data menunjukan karakteristik yang bersifat umum kepada semua atau kebanyakan semua kejadian dari entity tertentu. Termasuk sinonim-sinonim : properties, data elements, descriptors, dan fields Atribut-atribut menerima nilai-nilai untuk masingmasing kejadian dari suatu entity. Satu atribut harus mempunyai nilai lebih atau satu nilai yang sah jika tidak merupakan suatu konstan.
Identifier
Identifier adalah satu atribut atau kombinasi dari atribut dengan unik mengidentifikasi satu dan hanya satu kejadian dari suatu entity. Sinonim termasuk key atau primary key Suatu contoh, Kejadian karywan dapat dikenali oleh SocialInsuranceNumber, EmployeeNumber atau EmployeeName Identifiers dari suatu kejadian entity terdiri dari satu atau lebih atribut-atribut entity Suatu identifier dapat bersifat unik atau tidak unik Identifiers terdiri atas dua atau lebihatribut-atribut yang disebut gabungan identifiers
Relationships
Suatu hubungan adalah suatu asosiasi atau perhubungan antara dua atau lebih kesatuan Entiti – kesatuan dapat dihubungkan dengan satu sama lain di dalam hubungan-hubungan (relationships). Suatu hubungan dapat termasuk banyak kesatuan ; dan banyaknya kesatuan – entiti di dalam suatu hubungan adalah suatu derajat tingkat dari hubungan . Derajat tingkat 2 hubungan bersifat umum dan menyebutnyahubungan biner 1:1 one to one AUTO - ASSIGNMENT 1:N one to many DORM - OCCUPANT N:M many to many STUDENT - CLUB
Derajat Tingkat Hubungan SALESPERSON
FATHER
MOTHER
PARENT
SP-ORDER
ORDER
CHILD
Degree 2
Degree 3
Tiga Tipe Dari Binary Relationships may or may not These are often called HAS A relationships
EMPLOYEE
1:1
AUTO
AUTO-ASSIGNMENT
must exist DORMITORY
1:N
STUDENT
DORM-OCCUPANT
Shows MAXIMUM cardinality
STUDENT
N:M STUDENT-CLUB
CLUB
Relationships Lain Kardinalitas minimum DORMITORY
1:N
STUDENT
DORM-OCCUPANT
Hubungan berulang STUDENT
1:N ROOMS-WITH
Hubungan lemah EMPLOYEE ID Dependent entity
BUILDING
1:N
DEPENDENT
1:N
APARTMENT
ERD:
Semantic Object Model (SALSA)
CUSTOMER
SALESPERSON
N:1
I:N
SALES-ORDER
I:N
LINEITEM I:N
ITEM
Access Database Relationships
Diagram REAL (1,1)
Product-Item (Resource)
(0,*)
(1,1) (0,*)
List Items Ordered (Event)
(1,*)
Customer (Agent)
(0,*)
Take Order (Event) (0,*)
SalesPerson (1,1) (Agent)
CUSTOMER SALESPERSON
(Customer#, CustomerName, Street, City, State, Zip)
ITEM
(Item#, Name, Description)
SALES-ORDER
(SalesPerson#, SalesPersonName)
(Order#, Date, [Customer#], [SalesPerson#],Subtotal, Tax, Total) ITEMS-ORDERED (LineItem#, [Order#],Quantity, [Item#], ExtendedPrice)
Gambar 4-8 Contoh Hubungan Berualang Employee
manages
Employee
manages
Relationships
Digambarkan oleh kata kerja atau prasa kata kerja Relationships berganda bersifat mungkin antara dua entity Sedang diambil oleh
COURSE
STUDENT Diambil oleh
Ordinalitas - Ordinality
Didefinisikan apakah hubungan antara entity adalah wajib atau opsional. Ordinality menentukan nomor minimum dari kejadian dari satu entity relatif untuk yang lain. Ordinality harus digambarkan ke dalam dua arah
Kardinalitas - Cardinality Menggambarkan nomor maksimum dari kejadiankejadian dari satu entity suatu kejadian dari entity yang terkait Ini adalah nomor disebelah kanan dari tanda titik dua di bawah. Ordinality adalah nomor disebelah kiri tanda titik 0:M dua. Order Products Customer
1:1
Places
0:M
Contains
1:M
Relationships Dapat digambarkan Oleh Data
Secara nomor hubungan tidak dapat digambarkan oleh atribut – atribut data. Bagaimanapun jika Cardinality banyak dikedua arah, suatu hubungan dengan sendirinya frekuensi yang digambarkan oleh atribut - atribut data. Hubungan “Many to Many” Suatu asosiatif entity adalah suatu atribut-atribut data entity yang menggambarkan suatu hubungan antara dua atau lebih entity dasar
Many to Many Service Requested
0:M
1:M Service OR
1:M Product
Ordered Product
1:1 Pesanan 1:1 0:M
Is Placed For
Pengiriman 0:M
AND Is Placed For
0:M Faktur
Menghubungkan Objek Dengan Many to Many (*:*) Relationships
Buatlah suatu tabel yang terpisah termasuk atribut kunci dari keduanya objek tabel.
Menghubungkan Objek Dengan One to One (1:1) Relationships Buat suatu tabel Yang terpisah Termasuk atribut Kunci dari keduanya objek
atau
tempakan Atribut kunci Dari manapun objek Di dalam tabel Yang lain
Ketika anda sedang menghubungkan dua kejadian dengan suatu hubungan 1:1, baik tempatkan kunci dari tabel peristiwa sebelumnya kedalam tabel peristiwa yang berikutnya atau membuat tabel ketiga
Menghubungkan objek dengan One to Many (1:*) atau Many to One (*:1) Relationships
Menempatkan atribut kunci dari objek dengan 1 sisi dari cardinality kedalam tabel dari sisi many (*) dari cardinality. Jika anda mengikuti aturan yang ditetapkan dan menemukan Bahwa anda akan menempatkan kunci dari peristiwa Terjadi detik kedalam tabel dari peristiwa pertama, Menciptakan tabel yang terpisah termasuk atribut kunci dari kedua tabel peristiwa.
Gambar 4-9 Model REAL Christopher Inc. Resources
Agents
Events (1,1)
Inventory
(1,*)
(0,*)
includes
(1,*)
Receive customer order (1,1)
is e ad m of up
Bank
is kept at (1,1)
(0,*)
(0,*) pla ces
st e go
(0,*) (0,*)
s take
(0,*)
Ship Order
(0,*) (0,*)
(1,1)
Order personnel Customer
(1,1)
o (1,1)
executes
(0,*) carr (1,*) ied (1,1) by (0,*)
Cash
increases (1,1)
(0,*)
Collect payment
(0,*)
Shipping personnel Shipping firm
sends
(0,*) take s in (1,1)
Cashier
(1,1)
Exhibit 4-10 Notasi yang berbeda untuk menunjukan Hubungan Kardinalitas (1,1) (1,*) (0,1) (0,*)
Gambar 4-11 Atribut Entity Di Dalam Suatu Diagram ER Inventory Item # Inventory Item # Inventory Item # Inventory Item #
Inventory Item #
Inventory
Inventory Item # Inventory Item #
Exhibit 4-12 Contoh Hubungan Tabel Database Tabel konsumen C u s t o m e r # L a s t F i r s t A d d r e s s T e l e p h o n e N a m e N a m e 1 0 0 1 M a y s W i l l i e1 1 2 S a y H e y A v e . 2 4 2 4 2 4 2 1 0 0 2 M c C o v e y W i l l i e1 4 7 F e n c e b u s t e r W a y9 9 9 9 9 9 9 1 0 0 3 B o n d s B o b b y3 0 1 O u t o f h e r e B l v d . 1 2 3 4 5 6 7
Tabel Penjulan (tanpa suatu tabel yang terpisah untuk sale-inventory *:* relationship): Sales Event #
Terms of Sale
Salesperson Customer Inventory Inventory Price ID ID Item # Quantity each
Date
1
2/5
2 10, net 30
4
3654
987
5
2.50
1
2/5
2 10, net 30
4
3654
785
4
1.75
1
2/5
2 10, net 30
4
3654
562
15
1.99
2
2/5
2 10, net 30
6
746
998
27
2.95
2
2/5
2 10, net 30
6
746
624
94
1.05
3
2/5
COD
8
2956
847
18
9.99
3
2/5
COD
8
2956
112
29
5.75
3
2/5
COD
8
2956
413
8
3.00
3
2/5
COD
8
2956
335
57
7.50
Sales Event Table
Sales Event # 1 2 3
Date 2/5 2/5 2/5
Salesperson Terms ID 2 10, net 30 4 2 10, net 30 6 COD 8
Customer ID 3654 746 2956
(*:*) Sale-Inventory Table Sales Event # 1 1 1 2 2 3 3 3 3
Inventory Item # 987 785 562 998 624 847 112 413 335
Inventory Quantity 5 4 15 27 94 18 29 8 57
Price each 2.50 1.75 1.99 2.95 1.05 49.99 15.75 16.00 17.50
Gambar4-13 Christopher Inc. Struktur Peristiwa Logis – Pengambilan Order CUSTOMER Customer #, Name, Street Address, City, State, Zip, Telephone# Credit Rating, Credit Limit EMPLOYEE, Employee #, Name, Address Telephone #, BirthDate Start date, Salary,
RECEIVE CUSTOMER ORDER Sales Order #, [Customer #], [Customer Order Representative Employee #], Date, Time, Instructions, Cancel by Date, Location or order INVENTORY Inventory Item #, Description, Product Specification, Reorder Point, Current Price, Beginning Quantity, Beginning Quantity Date
ORDER/INVENTORY [Sales Order #], [Inventory item #], Quantity Ordered
Legend RELATION Primary Key [Foreign Key]
Gambar4-13 Christopher Inc. Struktur Peristiwa Logis – Pengiriman Sales Order Customer Employee SHIPPING FIRM, Shipping Firm ID#, Shipping Firm Name, Address Telephone #, Contact Person Rate Information
SHIP ORDER Invoice #, [Sales Order #], [Customer #], [Shipping Personnel Employee #], [Shipping Firm ID #], Date, Time, Shipment tracking #, Sales Tax
Inventory
SHIP/INVENTORY [Invoice #], [Inventory Item #], Quantity Shipped, Price Each
Gambar4-13 Christopher Inc. Struktur Peristiwa Logis –- Pengumpulan Tunai BANK
CASH
Bank #, Bank Name, Address
Cash Account #, [Bank #], Type of Account Beginning Balance Date
Shipping Order
COLLECT PAYMENT
[Invoice #], [Cash Receipt #], Amount applied to this Invoice
Customer Employee
Cash Receipt #, [Cash Account #], [Customer #], [Cashier Employee #], Date, Time, Amount Received, Electronic Funds Transfer #
SHIP/COLLECT PAYMENT
Exhibit 4-14 Menghubungkan proses perekaman pesanan dengan Data Repository INVENTORY ORDER
Order-Data
Record Sale
CUSTOMER ORDER PERSONNEL ORDER-INVENTORY
Gambar 4-15 Contoh proses-proses pemeliharaan dan akses data Register-Data
Customer-Data
Salesperson-Data
Merchandise-Data
Update Bank Data
BANK
Update Customer Data
CUSTOMER
Update Shipping firm Data
SHIPPING FIRM
Update Inventory Data
INVENTORY
Gambar 4-16 Contoh secara umum suatu laporan Sales-by-Salesperson MERCHANDISE
Request Sales-bySalesperson report Sales-bySalesperson
SALE
Report Sale
SALESPERSON SALE-MERCHANDISE
Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution
Gambar 4-17 Evolusi Pemodelan AIS Stage 1 Sistem manual Sumber daya: Manual Proses: Perputaran Akt Penyimpanan data Journals & Ledgers
Bias: Laporan keuangan umum
Stage 2 Sistem otomatisasi Sumber daya: Information Technology Proses: Perputaran AKt Penyimpanan data (file) Journals & Ledgers
Bias: Laporan keuangan umum
Stage 3 Aplikasi IT Event Driven Sumber daya: Information Technology Proses: Record, Maintain, Report Data aktivitas bisnis Penyimpanan data: Business Activity Data Integrated Stores Bias: Mendukung perencanaan, Pengawasan & evaluasi Berbagai macam aktivitas Informasi konsumen
Prototyping: Langkah Pendahuluan Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati.
Prototyping: Langkah Pendahuluan Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati Langkah 2: Analisis masing-masing peritiwa untuk mengidentifikasi sumber daya, agen dan likasi peristiwa
Prototyping: Langkah Pendahuluan Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati Langkah 2: Analisis masing-masing peritiwa untuk mengidentifikasi sumber daya, agen dan lokasi peristiwa. Langkah 3 : Identifikasi prilaku yang relevan, karakteristik, dan atribut – atribut dari peristiwa, sumber daya, agen dan lokasi.
Prototyping: Langkah Pendahuluan Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati. Langkah 2: Analisis masing-masing peritiwa untuk mengidentifikasi sumber daya, agen dan lokasi peristiwa. Langkah 3 : Identifikasi prilaku yang relevan, karakteristik, dan atribut – atribut dari peristiwa, sumber daya, agen dan lokasi. Langkah 4 : Identifikasi hubungan langsung antara objek
Prototyping: Langkah Pendahuluan Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati. Langkah 2: Analisis masing-masing peritiwa untuk mengidentifikasi sumber daya, agen dan lokasi peristiwa. Langkah 3 : Identifikasi prilaku yang relevan, karakteristik, dan atribut – atribut dari peristiwa, sumber daya, agen dan lokasi. Langkah 4 : Identifikasi hubungan langsung antara objek Langkah 5: Mengesahkan model dengan orang bisnis.
Merencanakan Suatu Aplikasi EventDriven C h a p t e r 2
❶ ❷
❸
❹ ❺
Identifikasi kejadian bisnis yang diminati Identifikasi sumberdaya, agen dan lokasi pada masingmasing peristiwa yang diminati Identifgikasi prilaku yang relevan, karakteristikdan atribut-atribut dari peristiwa, sumber daya, agen dan lokasi Identifikasi hubungan langsu antara objek Mengesahkan model proses bisnis anda dengan orang bisnis
Merencanakan Suatu Aplikasi EventDriven C h a p t e r
❻ ❼
❽ ❾
❿
4
Mendefinisikan lingkaup dari aplikasi IT Tingkatkan hubungan – hubungan pada model REALdengan penjelasan kardinalitas mereka Merancang tempat penyimpanan data Menghubungkan dengan proses recording, maintaining, dan reporting kepada tempat penyimpanan data Membangun prototipe
Toko Penjualan Eceran McKell’s Salesperson
Register
Sale
Merchandise
Customer
Aplikasi Diagram Context Event-Data Maintenance-Data Response
Application Context
Reports
Notification EVENT-DATA Mendefinisikan berbagai aliran data untuk masing-masing peristiwa bisnis di dalam lingkup aplikasi MAINTENANCE-DATA Mendefinisikan berbagai alitan data berdasarkan aplikasi pemerilahran referensi data RESPONSES Mendefinikan berbagai aliran data tanggapan-tanggapan yang disediakan oleh aplikasi NOTIFICATIONS Mendefinisikan berbagai pemberitahuan yang disediakan oleh aplikasi REPORTS Mendefinisikan berbagai laporan yang disediakan oleh aplikasi
Penjualan Eceran McKell’s Diagram Context Event-Data Maintenance-Data Response
Application Context
Reports
Notification EVENT-DATA Example= Sale-Data = Sale-Date + Register # + Customer # + Employee # + {Merchandise # + Qty-Sold} MAINTENANCE-DATA Example= Definitions of various data flows for maintaining customer, salesperson, and register reference data RESPONSE Example= Sales-Invoice = Invoice# +Sale-Date + Register # + Customer Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total NOTIFICATION Example = Warehouse-notification = Invoice#+{Merchandise# + Qty-Sold} REPORT Example = Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold + %Margin + $ Contribution} Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-Period Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution Customer-Profile = Report-Date + Name + State + Birthdate + Telephone + {Merchandise Description + Qty-Sold}
Prototyping :Langkah Tambahan Langkah 6: Gambarkan lingkup dari aplikasi. Langkah 7: Tingkatkan hubungan – hubungan model REAL dengan penjelasan kardinalitis mereka. • objek 1(min, max) --- objek 2(min, max) • minimum menandakan aturan bisnis • maksimum membantu penetapan struktur data • Keduanya membatu jejak audit struktur
Penjualan Eceran McKell’s Model REAL dengan Kardinalitis Salesperson
Register (1,1)
(1,1) (0,*)
(0,*)
Sale (0,*) (1,*)
Merchandise
(0,*) (1,1)
Customer
Prototyping :Langkah Tambahan Langkah 6: Gambarkan lingkup dari aplikasi. Langkah 7: Tingkatkan hubungan – hubungan model REAL dengan penjelasan kardinalitis mereka. Langkah 8: Desain struktur penyimpanan data • tabel atau objek • primary keys • kunci – kunci ditempatkan • Atribut non kunci
Toko Penjualan Eceran McKell’s - Tabel Register
(Register#,
Merchandise (Merchandise#, Sale
(Sale#,
Customer
(Customer#,
Salesperson (Employee#, Sale-Merchandise
([Sale#], [Merchandise#],
Toko Penjualan Eceran McKell’s - Tabel Register
(Register#,
Merchandise (Merchandise#, Sale
(Sale#, [Register#], [Customer#], [Employee#],
Customer
(Customer#,
Salesperson (Employee#, Sale-Merchandise
([Sale#], [Merchandise#],
Toko Penjualan Eceran McKell’s - Tabel Register
(Register#, Store, Date-Purchased, Cost, ...
Merchandise (Merchandise#, Description, Current-Price, Current-Cost, ... Sale (Sale#, [Register#], [Customer#], [Employee#], Time, ... Customer
(Customer#, Name, Address, State, Zip, Birthdate, Telephone#, Marital-Status, ...
Salesperson (Employee#, Name, Commission-Rate, ... Sale-Merchandise
([Sale#], [Merchandise#], Qty-Sold, Historical-Cost, Historical-Price, ...
Prototyping :Langkah Tambahan Langkah 6: Definisikan luasnya suatu aplikasi. Langkah 7: Menambah relationships pada model REAL berdasarkan pendefinisian cardinalities. Langkah 8: Desain struktur data penyimpanan. Langkah 9: Hubungkan dengan proses – proses penyimpanan, pemeliharaan dan pelaporan untuk penyimpanan data. • Menyalin peristiwa-peristiwa • Maintain sumber daya, agen, dan lokasi • Pelaporan (dokumen sumber, queries, laporan)
Prototyping :Langkah Tambahan Langkah 6: Definisikan luasnya suatu aplikasi. Langkah 7: Menambah relationships pada model REAL berdasarkan pendefinisian cardinalities. Langkah 8: Desain struktur data penyimpanan. Langkah 9: Hubungkan dengan proses – proses penyimpanan, pemeliharaan dan pelaporan untuk penyimpanan data. Langkah 10: Membangun prototype aplikasi.
Toko penjualan McKell’s Update Model REAL dengan Cardinalities Register
(1,1)
(1,1)
Salesperson
(0,*)
(0,*)
Sale Merchandise
(0,*) (1,*)
(1,1) (0,*)
Store Cash
(0,*) (1,1)
(1,*)
(0,*) (1,1)
(0,*)
(1,1) (0,*)
Receive Payment
(0,*) (1,1)
Customer
Receipts Clerk
Tabel Toko Penjualan Eceran McKell’s Sale Merchandise Sale-Merchandise
We are able to satisfy multiple views by the data we collect: •What happened? •When? •What resources were involved and how much? •Where did it occur?
Register Customer Salesperson
•Who was involved and what roles did they play?
Langkah mengembangkan suatu Prototype Aplikasi IT 1. Build a table for each table defined using the REAL model, 2. Build a menu system that has the following choices: Record Event Data, Maintain Data, Reports, and Exit. 3. Develop the necessary forms and procedures to collect event data and store it in the appropriate tables. 4. Develop the necessary forms and procedures to maintain the resource, agent, and location tables. 5. Develop queries required to generate desired information. 6. Develop report formats for each report. 7. Write the procedures required to execute the queries and format the reports. 8. Link each recording, maintaining, and reporting form to the application menu defined in step 2. Each form becomes a choice under either the Record Event Data, Maintenance, or Reports menu options.
Pemodelan Proses Bisnis REAL Proses Pengumpulan/Penjualan surat Pesanan Customer Service Center
Salesperson
Product Components
Customer Places Order
Customer
Distribution Center
Package and Deliver Product
Carrier
Package Cash
Packager Receive Payment
Customer Payment Clerk
Customer Returns Merchandise
Returns Clerk
The End
