Download Object persistence design

Kuliah Enterprise Information System
 Sebuah
cetak
biru
(blueprint)
untuk
mendeskripsikan bagaimana keterkaitan antara
elemen
TI
dan
manajemen
informasi
bekerjasama dalam membentuk suatu sistem
yang terintegrasi.
 Pendekatan


EAP:
Menyediakan arahan, tahapan-tahapan, dan artifak
arsitektur yang dihasilkan
Memilih metodologi penunjang yang efektif, sesuai
dengan kondisi dan kebutuhan enterprise tersebut
 Kegiatan
EAP dimulai dengan mendefinisikan
bisnis organisasi, bukan mendefiniskan system
yang diperlukan oleh organisasi.

EAP ≈ perencanaan yang bersifat business driven.
 EAP


mendefinisikan data sebelum aplikasi.
Langkah pertama yang dilakukan dalam kegiatan ini
adalah mengidentifikasi data yang dibutuhkan untuk
mendukung bisnis,
Kemudian mendefinisikan aplikasi-aplikasi yang
diperlukan untuk mengelola data tersebut.







Fokus pada penggunaan strategi teknologi untuk mengelola
data sebagai aset
Standarisasi kosakata (nama data, nama sistem, dan
sebagainya) merupakan fasilitas untuk berkomunikasi dan
mengurangi inkonsistensi dan redundansi data.
Adanya dokumentasi meningkatkan pemahaman terhadap
bisnis.
Kebijakan pengambilan keputusan dapat ditinjau ulang.
Memperhatikan integrasi sistem baru dengan sistem aplikasi
yang sudah ada.
Solusi jangka panjang yang bersifat efektif terhadap biaya
(cost effective).
Mempermudah dalam menilai manfaat dan dampak
pemanfaatan teknologi informasi bagi bisnis.
Data
(what)
Function
(how)
Network
(where)
Planner
Daftar hal-hal
penting (entitas)
bagi enterprise
Daftar fungsi
bisnis
Daftar lokasi
operasional
Owner
Hubungan entitas
bisnis dengan
menggunakan
Entity Relationship
Diagram (ERD)
Dekomposisi
fungsi dan
proses
menggunakan
model proses
bisnis (DFD)
Jaringan logistik
(node & link)
Komunikasi antar
lokasi bisnis
 Tahap

Menentukan metodologi apa yang digunakan, personil
yang terlibat, dan tools apa yang diperlukan
 Tahap

3
Mendefinisikan arsitektur secara berurut dimulai dari
data, aplikasi dan teknologi di masa depan
 Tahap

2
Membangun suatu basis pengetahuan tentang bisnis dan
informasi yang digunakan saat ini dan teknologi
pendukungnya
 Tahap

1
4
Mendefinisikan urutan prioritas tentang implementasi
aplikasi, jadwalnya, rencana biaya, rencana migrasinya
Inisiasi
Perencanaan
Pemodelan
Bisnis
Arsitektur
Data
Tahap I
Sistem & Teknologi
Saat ini
Arsitektur
Aplikasi
Rencana Implementasi / Migrasi
Arsitektur
Teknologi
Tahap II
Tahap III
Tahap IV
LAPISAN
1
2
TAHAPAN
Pemodelan Bisnis
Ruang lingkup, sasaran, visi, penentuan metodologi
dan alat-alat yang akan digunakan, perencanaan tim,
presentasi, rencana kerja.
Struktur oragnisasi, model fungsi bisnis awal
Survey Perusahaan
Perlengkapan model bisnis fungsional
Inisiasi Perencanaan
Sistem dan teknologi saat ini
Arsitektur Data
3
Arsitektur Aplikasi
Arsitektur Teknologi
Katalog sumber daya informasi (IRC), skema sistem
Pendefisian entitas, diagram ER, matriks entitas
terhadap fungsi, dokumen arsitektur data.
Pendefinisian aplikasi-aplikasi, matriks aplikasi,
dokumen arsitektur aplikasi.
Distribusi data/aplikasi, dokumen arsitektur aplikasi.
Kesimpulan Perencanaan
Urutan aplikasi/roadmap, rencana migrasi, factorfaktor sukses dan rekomendasi
Dokumen akhir, presentasi
Transisi terhadap
implementasi
Peningkatan
organisasi,
kebijakan-kebijakan,
standard, prosedur-prosedur, rencana terperinci.
Rencana Implementasi
4
HASIL
Kuliah Enterprise Information System
 Untuk
menggambarkan proses suatu sistem
yang telah ada atau sistem baru secara logika
tanpa mempertimbangkan lingkungan fisik
dimana data tersebut mengalir atau
lingkungan fisik dimana data tersebut
disimpan.
 Alat
bantu pengembangan sistem yang
terstruktur untuk menggambarkan arus data
di dalam sistem dengan terstruktur dan jelas.
 Pengertian
lebih jauh terhadap
ketidaktergantungan antara sistem dan
subsistem
 Bebas dari implementasi teknis sistem lebih
dini
 Mengkomunikasikan keadaan sistem yang ada
kepada user
 Memungkinkan analisis sistem untuk
menerangkan komponen-komponen dari
sebuah sistem
 Process
dengan process
 External entity dengan process
 Process dengan data storage
Data flow tidak boleh terjadi antara
 Data store dengan data store
 External entity dengan external entity
 External entity denga data store
 Activity
Diagram

Salah satu notasi Unified Modeling Language (UML)
untuk menggambarkan suatu proses

Lebih baik dilengkapi dengan swinlane yang
menunjukkan aktivitas yang dikerjakan pada bagianbagian yang terkait dengan aktivitas tersebut
 Flow
chart
 System Diagram
Kuliah Enterprise Information System
 Model
diagram yang didasarkan pada sebuah
persepsi dunia nyata yang terdiri dari obyek dasar
yang disebut entitas (entity), dan hubungannya
(relationship) diantara entitas tersebut.
 Diagram ER dikembangkan untuk menjembatani
kegiatan perancangan basis data dengan
menggunakan
skema
entrprise,
yang
mempresentasikan seluruh struktur logic dari basis
data.
Silberschatz A., Korth Henry F, Sudarshan S, 2002
 Menggambarkan
model data yang digunakan dalam
proses bisnis
 Setiap
entity terdiri dari beberapa atribut yang
menunjukkan karakteristik data yang disimpan di
dalamnya
 Entity
dengan entity lainnya saling berelasi untuk
menunjang informasi yang dibutuhkan oleh sistem
 One

Satu baris entity table berelasi dengan satu baris di
entity relasinya
 One

to one relationship
to many relationship
Satu baris entity table berelasi dengan banyak bari s di
entity relasinya
 Many

to many relationship
Satu baris entity table berelasi dengan banyak bari s di
entity relasinya demikian juga sebaliknya
 Mandatory

Penanda apakah semua anggota entity harus berelasi
dengan entity lain atau tidak. Bila semua anggota
harus berelasi maka di beri simbol “|”, dan bila semua
tidak harus berelasi diberi simbol “O”
ruang belajar
jurusan
perwalian
berita acara kuliah
hasil studi
melakukan
mempunyai
mempunyai
mempunyai
jadwal kuliah
mempunyai
mata kuliah
Terdaftar di
mahasiswa
mengontrak
mempunyai
melakukan
berdasarkan
mempunyai
Terdaftar sebagai
Terdaftar sebagai
registrasi ulang
mahasiswa lama
kalender akademik
jadwal ujian
peserta sidang
Kerja Praktek (KP)
mempunyai
peserta sidang
Tugas Akhir (TA)
mempunyai
mempunyai
berita acara ujian
pembimbing
mempunyai
mempunyai
jadwal sidang KP
dan TA
nilai
Kuliah Enterprise Information System
 Relational




Databases
The most popular kind of database application.
It is based on collection of tables, with each
table having a primary key – a field(s) whose
value is unique for every row of the table.
The tables are related to each other by placing
the primary key from one table into the related
table as a foreign key.
Most RDBMS support referential integrity.
 Object-Relational



Databases
ORDBMS
Relational database management systems with
extensions to handle the storage of objects in
the relational table structure. This is typically
done through the use of user-defined types
(images, complex data type).
In pure RDBMS, attributes are limited to simle or
atomic data types such as integers, floats, or
characters.

Object-Oriented Databases
OODBMS
 There have been two primary approaches to
supporting object persiestence:




Adding persistence extensions to an OOP language
Creating an entirely separate DBMS
Standarization process



Object Definition Language – ODL
Object Manipulating Language – OML
Object Qeury languange – OQL
Object is associated with extent. Extent is simply the
set of instances associated with a particular class;
that is, it is the equivalent of a table in a RDBMS.
 Pure OODBMS: Gemstone, Jasmine, O2, ObjectStore,
Versant, Objectivity, etc

 Major
strengths and weaknesses
 Data types supported
 Type of application system
 Existing storage formats
 Future needs
 Other miscellaneous criteria
RDBMS
ORDBMS
OODBMS
Major
Strengths
Leader in the
database market
Can handle
diverse data
needs
Based on
established,
proven
technology (e.g.
SQL)
Able to handel
complex data
Able to handle
complex data
Direct support for
Object
Orientation
Major
Weakness
Cannot handel
complex data
No support for OO
Impedance
mismatch
between tables
and objects
Limited support
for OO
Impedance
mismatch
between tables
and objects
Technology is still
maturing
Skills are hard to
find
RDBMS
ORDBMS
OODBMS
Data types
supported
Simple
Simple and
complex
Simple and
complex
Types of
App.
Systems
supported
Transaction
processing &
decision making
Transaaction
processing &
decision making
Transaction
processing &
decision making
Existing
Storage
formats
Organization
dependent
Organization
dependent
Organization
dependent
Future
needs
Good future
prospects
Good future
prospects
Good future
prospects
 Normalization

A process whereby a series of rules are applied to
the data management layer to determine how
well formed it is.
 Types



of normalization
First normal form
Second normal form
Third normal form
0 Normal Form
Do any tables have repeating fields? Do some records have a
different number of columns from other records?
Yes: Remove the repeating fields. Add a new table that contains
the fields that repeat
No: The data model is in 1NF
First Normal Form
Is the primary key made up of more than one field? If so, do any
fields depend on only a part of the primary key
Yes: Remove the partial dependency. Add a new table that contains
the fields that are partially dependent.
No: The data model is in 2NF
Second Normal Form
Do any fields depend on another nonprimary key field?
Yes: Remove the transitive dependency; Add a new table that contains
the fields that are transitively dependent.
No: The data model is in 3NF
Third Normal Form
ORDER
Order No. (PK)
Cust. Fname
Cust. Lname
Cust. Home ddress
Cust. Ship address
Cust. Payment
Item No.
Item Desc.
Item Price
Item Qty
Repeating
groups
ITEM
ORDER
Order No. (PK)
Cust. Fname
Cust. Lname
Cust. Home ddress
Cust. Ship address
Cust. Payment
0..*
1..*
Order No. (PK)(FK)
Item No. (PK)
Item Desc.
Item Price
Item Qty
ORDER
Order No. (PK)
Cust. Fname
Cust. Lname
Cust. Home ddress
Cust. Ship address
Cust. Payment
ITEM
0..*
1..*
ORDER ITEM
Order No.(PK)(FK)
Item No.(PK)(FK)
Item Qty
Item No.(PK)
Item Desc.
Item Price
ORDER
Order No. (PK)
Cust. No. (FK)
Cust. Ship address
Cust. Payment
0..*
0..*
1..*
ITEM
Item No. (PK)
Item Desc.
Item Price
ORDER ITEM
CUSTOMER
Cust. No. (PK)
Cust. Fname
Cust. Lname
Cust. Home ddress
Order No. (PK)(FK)
Item No. (PK)(FK)
Item Qty
1..1
 Denormalization
 Clustering
 Indexing
 THE
OPPOSITE OF NORMALIZATION
 THE
PROCESS TO ADD REDUNDANCY BACK
INTO THE DESIGN
 WHY?

It reduces the number of joins that need to
performed in a query, thus speeding up access.
 Speed
of access also is influenced by the way
the data is retrieved.
 One
way to improve access speed is to
reduce the number of times that the storage
medium needs to be accessed during a
transaction.
 Place
records together phisically so that
similar records are stored close together.
Intra-file clustering
 Like records in the table are stored together
in some way.
Inter-file clustering
 Combines records from more than one table
that tipically are retrieved together
A
time server that you are familiar with is an
index located in the back of a textbook

Which points you directly to the page or pages
that contain your topic of interest.
 An
index in relational database has function
like index in a textbook


A query can use an index to find the locations of
only those records that are included in the query
answer.
A table can have an unlimited number of
indexes.
Payment Pointer
Type
AMEX
*
AMEX
*
MC
*
MC
*
MC
*
VISA
*
Index
Order
Date CustID Amount Total
Payment
Number
Type
234
11/23/01 2242 $90.00 $95.85 MC
235
11/23/01 9500 $12.00 $12.60 AMEX
.
.
.
.
.
246
11/24/01 4254 $20.00 $21.00 VISA
247
11/24/01 2241 $50.00 $52.50 AMEX
Table of Order
 One
last way to plan for good performance of
database is to apply volumetrics.

It means estimating the amount of data that the
hardware will need to support.

We can incorporate our estimates into the
database server hardware specification to make
sure that the database hardware is sufficient for
the project’s needs.
 The


size of the database is based on
The amount of raw data in the tabless
The overhead requirements of the DBMS.
Estimating size of database
 we will need to have a good understanding of
the initial size of data as well as it expected
growth rate over time.
Field
Average Size (characters)
Order number
8
Date
7
Cust ID
4
Last name
13
First name
9
State
2
Amount
4
Tax
2
Record size
49
Overhead
30%
Total record size
63,7
Initial table size
50,000
Initial table volume
3,185,000
Growth rate/month
1,000 records
Table volume @3years
5,478,200
Tugas II:
Buatlah deskripsi secara global proses bisnis yang
ada di sekitar tempat kerja anda dengan
menggunakan swimlane activity diagram dan
swimlane flowchart diagram