Desain dan Analisis Sistem Dari Suatu Sistem Business Event Driven

Presentasi berjudul: "Desain dan Analisis Sistem Dari Suatu Sistem Business Event Driven"— Transcript presentasi:

1 Desain dan Analisis Sistem Dari Suatu Sistem Business Event Driven
Bab 4

2 Objektif Objektivitas dari bab ini untuk membantu anda memahami langkah – langkah kunci di dalam mendesain dan menganalisis aplikasi teknologi informasi – IT.

3 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 ?

4 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

5 Langkah dari Systems Analysis and Design Life Cycle (SDLC)
Project Identification and Selection Project Initiation Langkah dari Systems Analysis and Design Life Cycle (SDLC) I. Phase Analisis – Menentukan persyaratan sistem dan persyaratan struktur dengan menciptakan model proses, model logika, dan model data konseptual. IV. Phase Implementasi dan Pemeliharaan – melaksanakan sistem coding, testing, instalasi, dokumentasi, pelatihan user, mendukung user, dan pemeliharaan sistem. Analysis III. Phase Desain Fisik – merancang file secara fisik, database, dan intruksi pemograman. II. Phase Desain Logika – mengembangkan desain logika dari database dan merancang forms, laporan-laporan, penghubung, dan dialog – tanya jawab. Logical Design Physical Design Implementation Maintenance J.A. Hoffer, J.F. George, and J.S. Valacich, Modern Systems Analysis and Design, Reading, Massachusetts: Addison Wesley, 1999.

6 The Systems Development Process
Systems Planning Proses pengembangan aplikasi terencana Systems Support Detail sistem yang berjalan dan pembatasan Detail sistem yang berjalan dan pembatasan Systems Analysis Pernyataan Persyaratan bisnis Systems Implementation Sistem informasi produksi Systems Design Pernyataan desain teknis 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.

7 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 Process Modeling Logical Models Conceptual data modeling

8 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?

9 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.

10 Gambar 4-3 Model REAL Christopher Inc.
Pemeliharaan data referensi tentang sumber daya, agen-agen, dan lokasi-lokasi Sumber daya Kejadian Agen Menyimpan data kejadian operasional Christopher Inc. menyediakan topi baseball kepada team baseball liga utama untuk di jual di dalam ballparks mereka. Sementara menganalisis proses bisnis mereka, team analisis Christopher’s mengenali tiga aktivitas operasional kunci : terima order dari team-team baseball (siapa pelangan Christopher’s), topi dipaket dan dikirim kepada team-team (penjualan dari barang dagangan), dan menerima pembayaran dari team-team Order personnel Customer Inventory Receive customer order includes takes places Melaporkan informasi bermanfaat ke informasi pelanggan Shipping personnel Shipping firm Ship Order is made up of goes to executes carried by Cashier Collect payment Cash Bank is kept at increases takes in sends

11 Struktur Proses – Proses Informasi
Maintaining Process Stimulus Response Notification Data Untuk mendukung suatu proses-proses bisnis, suatu sistem harus mengumpulkan data tentang sumber daya, agen-agen, dan lokasi-lokasi dengan menentukan kejadian operasional. Sistim itu harus mengizinkan data untuk menyimpan peristiwa . Pemeliharaan referensi data melibatkan menambahkan, menghapus, atau memodifikasi data tentang sumber daya, agen-agen, dan lokasi-lokasi (eg., mengubah produk-produk yang ditawarkan oleh suatu penjual; mengubah suatu status perkawinan karyawan; dan menambahkan suatu penjual baru kepada daftar penjual). Sasaran itu untuk memelihara akurat, lengkap, dan data tepat waktu tentang sumber daya, agen-agen, dan lokasi-lokasi yang terlibat di dalam kejadian operasional untuk proses yang anda sedang memperagakan - modeling Recording Process Stimulus Response Notification Data Melaksanakan masing-masing peristiwa operasi yang mencetuskan kebutuhan untuk merekam deskriptif data tentang peristiwa Ketika data ditangkap selagi peristiwa operasi terjadi, proses perekaman dapat melaksanakan aturan bisnis yang ditetapkan oleh manajemen untuk masing-masing peristiwa operasi. Aturan-aturan ini adalah petunjuk, patokan-patokan, kebijakan-kebijakan, dan/atau prosedur-prosedur yang diharapkan untuk meningkatkan mutu operasional dan informasi dengan mengurangi beberapa masalah seperti kesalahan-kesalahan, ketidakteraturan-ketidakteraturan, atau tipuan. Idealnya, eksekusi keterkaitan peristiwa operasi dan proses informasi terjadi secara serempak. Reporting Process Stimulus Data Response Notification Proses-proses pelaporan mengambil dan mengubah data penyimpanan kejadian-kejadian, sumber daya, agen-agen, dan lokasi-lokasi ke dalam informasi, dan memformat informasi untuk presentasi kepada infromasi pelanggan. Pandangan-pandangan ini terdiri atas keuangan dan ukuran kinerja dan boleh mengambil bentuk dari sumber dokumen hardcopy, laporan hardcopy, aliran data elektronik, atau query-query khusus - ad hoc . Aliran data ini memberi hak tindakan-tindakan, menyediakan dokumentasi kepada fungsi bisnis yang lain atau kepada pihak luar, dan mendukung pengambilan keputusan strategis dan operasional.

12 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.

13 Gambar 4-4 Christopher Inc., Diagram Konteks
Customers Order Shipping/Bill Payment Suatu diagram konteks menunjukkan sumber dan tujuan-tujuan data yang di luar batasan-batasan atau lingkup dari sistim yang dianalisa.. Anda tidak menunjukkan penyimpan data dan aliran data di dalam batasan-batasan dari sistim. O Sales / collection system Decision Makers Desired Information lingkaran menunjukkan pengolahan komputer Christopher Inc. memerlukan suatu sistim yang memungkinkan komunikasi dengan pelanggan-pelanggan beberapa kali selama proses (eg., pelanggan-pelanggan memasukkan data order seperti juga data pembayaran, dan Christopher Inc. pengiriman pengiriman balik, penjualan, penagihan, dan data pembayaran). Carriers Shipping Data Confirmation Akhirnya, Sistem Christopher Inc. perlu mengizinkan akses oleh agen-agen internal (seperti manajemen dan pengambil-keputusan-pengambil-keputusan lain) kepada data dan informasi kritis. Christopher Inc. memerlukan suatu sistim yang dapat mengizinkan untuk mengirimkan data pengiriman kepada pembawa-pembawa mereka dan menerima konfirmasi-konfirmasi pengiriman dari pembawa-pembawa mereka.

14 Gambar 4-5 Christopher, Inc. Level 0 Data Flow Diagram
1.0 Proses Order pelanggan Permintaan informasi Orders Pengiriman data permintaan 2.0 Proses Pengiriman Ke konsumen Permintaan informasi Konsumen Tagihan Pembuat keputusan Data pembayaran tiba Pembayaran 3.0 Proses Pembayaran dari konsumen Permintaan informasi

15 Gambar 4-6 Christopher Inc., Level 1 Data Flow Diagram
Order disetujui Data order konsumen Order 1.1 Setujui dan rekam data order pelanggan Data Order 1.2 Hasilkan informasi tentang order Permintaan infromasi Mengirimkan Data Permintaan

16 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. Masing-masing 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

17 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

18 Langkah – langkah Prototipe Tambahan
Ketika anda sedang menciptakan diagram alur data atau work-flows untuk suatu proses bisnis, bagaimana anda mengetahui berapa banyak perekaman, pemeliharaan, dan proses pelaporan yang anda perlukan pada suatu aplikasi IT? Anda dapat menggunakan model REAL anda dan diagram konteks sebagai suatu pemandu. Banyaknya proses pelaporan yang diperlukan selama satu aplikasi adalah suatu fungsi banyaknya pandangan-pandangan yang diperlukan oleh informasi pelanggan. Anda akan memerlukan satu proses pelaporan untuk masing-masing memerlukan pandangan keluaran. Untuk membantu rencana anda, menentukan berapa banyak yang harus mengikuti dari tiga jenis pelaporan uraian keluaran yang dibutuhkan sebagai informasi pelanggan anda: Dokumen sumber: yang dicetak atau transmisi elektronik dokumentasi data peristiwa laporan-laporan Preformated: melaporkan secara teratur digunakan oleh informasi pelanggan Laporan-laporan khusus - ad hoc: melaporkan bahwa desain informasi pelanggan dan permintaan untuk menyediakan suatu pandangan baru atau suatu pandangan yang jarang digunakan diagram konteks - context diagram inflow dan outflow untuk Record data kejadian Maintain sumber daya, agen, lokasi data Report dokumen sumber, queri, pelaporan Anda memerlukan satu proses perekaman di dalam aplikasi IT Anda untuk masing-masing objek peristiwa bisnis di dalam model aplikasi-aplikasi REAL Anda memerlukan satu proses pemeliharaan di dalam aplikasi IT Anda untuk masing-masing sumber daya, agen, dan objek lokasi di dalam model aplikasi-aplikasi REAL

19 Kasus penyimpanan penjualan eceran McKell's Checkpoint
Proses pelaporan untuk menangani fungsi manajemen kunci: Faktur Penjualan - rekening pelanggan ; Profil Pelanggan -suatu pelaporan yang menyediakan informasi tentang pelanggan-pelanggan dan kebiasaan-kebiasaan pembelian mereka; Penjualan Produk -suatu pelaporan yang menyediakan margin dan kontribusi untuk masing-masing jenis tipe barang dagangan yang dijual; Pendapatan Akuntansi -suatu 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 masing-masing penjual) Menggunakan contoh penjualan eceran kita, aplikasi IT ingin mempunyai:: Satu proses perekaman (i.e., merekam data penjualan) untuk merekam satu peristiwa yang diminati Empat proses – proses pemaliharaan Pelihara data konsumen, Pelihara data barang dagangan, Pelihara data penjual dan Peliharan data register untuk menyimpan sumber daya, agen, dan data lokasi terbaru dan valid

20 Langkah 1-C: Persyaratan membangun 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 proses-proses 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 masing-masing 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.

21 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 (Gambar 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.

22 Gambar 4-7 Contoh Struktur Inggris
Proses Data Input 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 Output

23 Intruksi Struktur Inggris
DO READ customer record BEGIN IF IF customer birthday month is January THEN GENERATE birthday card ELSE DO nothing END IF UNTIL End of file

24 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.

25 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 data taklengkap, taktepat, atau 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 yang 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. .

26 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 keluaran-keluaran 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 data Untuk melengkapi langkah ini, kebanyakan analis-analis menggunakan salah satu dari dua teknik-teknik modeling : Entity-Relationship (E-R) or Object Oriented (OO).

27 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

28 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 menghubungjan satu atau lebih entity Entity Name Relationship Name

29 Tempat/ atau di tempatkan oleh
Contoh Konsumen Tempat/ atau di tempatkan oleh Pesanan Berisi atau dimasukan oleh Pemasok

30 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

31 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

32 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

33 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

34 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)

35 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 masing-masing kejadian dari suatu entity. Satu atribut harus mempunyai nilai lebih atau satu nilai yang sah jika tidak merupakan suatu konstan.

36 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

37 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

38 Derajat Tingkat Hubungan
MOTHER FATHER CHILD PARENT Degree 3 SALESPERSON ORDER SP-ORDER Degree 2

39 Tiga Tipe Dari Binary Relationships
EMPLOYEE AUTO AUTO-ASSIGNMENT 1:1 may or may not These are often called HAS A relationships must exist DORMITORY STUDENT DORM-OCCUPANT 1:N Shows MAXIMUM cardinality STUDENT CLUB STUDENT-CLUB N:M

40 Relationships Lain DORMITORY STUDENT Kardinalitas minimum
DORM-OCCUPANT 1:N Kardinalitas minimum Hubungan berulang STUDENT 1:N ROOMS-WITH Hubungan lemah EMPLOYEE 1:N DEPENDENT ID Dependent entity BUILDING 1:N APARTMENT

41 Semantic Object Model (SALSA)
ERD: Semantic Object Model (SALSA) CUSTOMER SALESPERSON SALES-ORDER LINEITEM ITEM I:N N:1

42 Access Database Relationships

43 Diagram REAL Product-Item (Resource) Customer (Agent) Take Order
(1,1) Customer (Agent) (0,*) (0,*) (1,1) Take Order (Event) (0,*) SalesPerson (Agent) List Items Ordered (Event) (1,*) (1,1) (0,*) CUSTOMER (Customer#, CustomerName, Street, City, State, Zip) SALESPERSON (SalesPerson#, SalesPersonName) SALES-ORDER (Order#, Date, [Customer#], [SalesPerson#],Subtotal, Tax, Total) ITEM (Item#, Name, Description) (LineItem#, [Order#],Quantity, [Item#], ExtendedPrice) ITEMS-ORDERED

44 Gambar 4-8 Contoh Hubungan Berualang
manages Employee Employee manages

45 Relationships Digambarkan oleh kata kerja atau prasa kata kerja
Relationships berganda bersifat mungkin antara dua entity Is Being Taken by COURSE STUDENT Was Taken by

46 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

47 Kardinalitas - Cardinality
Menggambarkan nomor maksimum dari kejadian-kejadian 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 dua. 0:M Order Products Customer 1:1 Contains 0:M Places 1:M

48 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

49 Many to Many Service Pengiriman Is Placed For Requested Service 0:M
1:1 OR Pesanan AND 1:1 1:M Ordered Product Is Placed For 0:M 0:M Product Faktur

50 Buatlah suatu tabel yang terpisah termasuk atribut kunci dari
Menghubungkan Objek Dengan Many to Many (*:*) Relationships Buatlah suatu tabel yang terpisah termasuk atribut kunci dari keduanya objek tabel.

51 Menghubungkan Objek Dengan One to One (1:1) Relationships
Buat suatu tabel Yang terpisah Termasuk atribut Kunci dari keduanya objek tempakan Atribut kunci Dari manapun objek Di dalam tabel Yang lain atau 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

52 objek dengan 1 sisi dari cardinality kedalam tabel dari sisi
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.

53 Gambar 4-9 Model REAL Christopher Inc.
Resources Events Agents (1,1) Order personnel Receive customer order (0,*) takes (0,*) (1,*) (1,1) (1,1) Customer Inventory (0,*) includes places (1,1) (1,*) (1,1) goes to is made up of (0,*) (0,*) Ship Order (1,1) Shipping personnel (0,*) (0,*) executes (0,*) (1,*) (1,1) carried by Shipping firm (0,*) is kept at increases Collect payment (0,*) sends Bank Cash (1,1) (0,*) (1,1) (0,*) (0,*) takes in Cashier (1,1)

54 Exhibit 4-10 Notasi yang berbeda untuk menunjukan Hubungan Kardinalitas
(1,1) (1,*) (0,1) (0,*)

55 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 #

56 Exhibit 4-12 Contoh Hubungan Tabel Database
Tabel konsumen

57 Tabel Penjulan (tanpa suatu tabel yang terpisah untuk sale-inventory *:* relationship):
Sales Event # Date Terms of Sale Salesperson ID Customer Inventory Item # Quantity Price each 1 2/5 2 10, net 30 4 3654 987 5 2.50 785 1.75 562 15 1.99 2 6 746 998 27 2.95 624 94 1.05 3 COD 8 2956 847 18 9.99 112 29 5.75 413 3.00 335 57 7.50

58 (*:*) Sale-Inventory Table
Sales Event Table Sales Event # Date Terms Salesperson ID Customer 1 2/5 2 10, net 30 4 3654 2 6 746 3 COD 8 2956 (*:*) Sale-Inventory Table Sales Event # Inventory Item # Quantity Price each 1 987 5 2.50 785 4 1.75 562 15 1.99 2 998 27 2.95 624 94 1.05 3 847 18 49.99 112 29 15.75 413 8 16.00 335 57 17.50

59 Gambar4-13 Christopher Inc
Gambar4-13 Christopher Inc. Struktur Peristiwa Logis – Pengambilan Order RECEIVE CUSTOMER ORDER Sales Order #, [Customer #], [Customer Order Representative Employee #], Date, Time, Instructions, Cancel by Date, Location or order CUSTOMER Customer #, Name, Street Address, City, State, Zip, Telephone# Credit Rating, Credit Limit ORDER/INVENTORY [Sales Order #], [Inventory item #], Quantity Ordered Legend EMPLOYEE, Employee #, Name, Address Telephone #, BirthDate Start date, Salary, INVENTORY Inventory Item #, Description, Product Specification, Reorder Point, Current Price, Beginning Quantity, Beginning Quantity Date RELATION Primary Key [Foreign Key]

60 Gambar4-13 Christopher Inc. Struktur Peristiwa Logis – Pengiriman
SHIP ORDER Invoice #, [Sales Order #], [Customer #], [Shipping Personnel Employee #], [Shipping Firm ID #], Date, Time, Shipment tracking #, Sales Tax SHIP/INVENTORY [Invoice #], [Inventory Item #], Quantity Shipped, Price Each Sales Order Customer Employee SHIPPING FIRM, Shipping Firm ID#, Shipping Firm Name, Address Telephone #, Contact Person Rate Information Inventory

61 Gambar4-13 Christopher Inc
Gambar4-13 Christopher Inc. Struktur Peristiwa Logis –- Pengumpulan Tunai BANK Bank #, Bank Name, Address CASH Cash Account #, [Bank #], Type of Account Beginning Balance Date Shipping Order SHIP/COLLECT PAYMENT [Invoice #], [Cash Receipt #], Amount applied to this Invoice COLLECT PAYMENT Cash Receipt #, [Cash Account #], [Customer #], [Cashier Employee #], Date, Time, Amount Received, Electronic Funds Transfer # Customer Employee

62 Exhibit 4-14 Menghubungkan proses perekaman pesanan dengan Data Repository
INVENTORY Record Sale ORDER Order-Data CUSTOMER ORDER PERSONNEL ORDER-INVENTORY

63 Gambar 4-15 Contoh proses-proses pemeliharaan dan akses data
Update Bank Data Register-Data BANK Update Customer Data Customer-Data CUSTOMER Update Shipping firm Data Salesperson-Data SHIPPING FIRM Update Inventory Data Merchandise-Data INVENTORY

64 Gambar 4-16 Contoh secara umum suatu laporan Sales-by-Salesperson
MERCHANDISE Request Sales-by- Salesperson report Report Sale SALE Sales-by- Salesperson SALESPERSON SALE-MERCHANDISE Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution

65 Gambar 4-17 Evolusi Pemodelan AIS Stage 1 Stage 2 Stage 3
Sistem manual Sistem otomatisasi Aplikasi IT Event Driven Sumber daya: Manual Proses: Perputaran Akt Penyimpanan data Journals & Ledgers Sumber daya: Information Technology Proses: Perputaran AKt Penyimpanan data (file) Journals & Ledgers 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 Bias: Laporan keuangan umum Bias: Laporan keuangan umum

66 Prototyping: Langkah Pendahuluan
Langkah 1: Meninjau ulang proses bisnis dan mengidentifikasi peristiwa bisnis yang diminati.

67 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

68 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.

69 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

70 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.

71 Merencanakan Suatu Aplikasi Event-Driven
Identifikasi kejadian bisnis yang diminati Identifikasi sumberdaya, agen dan lokasi pada masing-masing 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 Chapter 2

72 Merencanakan Suatu Aplikasi Event-Driven
Chapter 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

73 Toko Penjualan Eceran McKell’s
Sale Customer Merchandise Salesperson Register

74 Aplikasi Diagram Context
Event-Data Reports Application Context Response Notification Maintenance-Data 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

75 Penjualan Eceran McKell’s Diagram Context
Event-Data Reports Application Context Response Notification Maintenance-Data 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}

76 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

77 Penjualan Eceran McKell’s Model REAL dengan Kardinalitis
Salesperson Register (1,1) (1,1) (0,*) (0,*) Sale (0,*) (0,*) (1,*) (1,1) Customer Merchandise

78 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

79 Toko Penjualan Eceran McKell’s - Tabel
Register (Register#, Merchandise (Merchandise#, Sale (Sale#, Customer (Customer#, Salesperson (Employee#, Sale-Merchandise ([Sale#], [Merchandise#],

80 Toko Penjualan Eceran McKell’s - Tabel
Register (Register#, Merchandise (Merchandise#, Sale (Sale#, [Register#], [Customer#], [Employee#], Customer (Customer#, Salesperson (Employee#, Sale-Merchandise ([Sale#], [Merchandise#],

81 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, ...

82 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)

83 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.

84 Toko penjualan McKell’s Update Model REAL dengan Cardinalities
Sale Customer Merchandise Salesperson Register (1,1) (0,*) (1,*) Receive Payment Receipts Clerk Cash Store

85 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? Who was involved and what roles did they play? Sale Merchandise Sale-Merchandise Register Customer Salesperson

86 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.

87 Pemodelan Proses Bisnis REAL
Proses Pengumpulan/Penjualan surat Pesanan Customer Places Order Package and Deliver Product Receive Payment Salesperson Product Components Packager Carrier Customer Customer Payment Clerk Cash Package Customer Service Center Distribution Center Customer Returns Merchandise Returns Clerk

88 The End