Chap. 7. Cases where extended transactions are recommended:

51
Chap. 7. Cases where extended transactions are recommended: ERP systems • E-commerce • Mobile-commerce Patient records/Elektronisk patientjournal Airline reservation systems CSCW systemer Distributed calender systems Mobile applications Supply chain management Library systems Banking systems

description

Chap. 7. Cases where extended transactions are recommended:. ERP systems E-commerce Mobile-commerce Patient records/Elektronisk patientjournal Airline reservation systems CSCW systemer Distributed calender systems Mobile applications Supply chain management Library systems - PowerPoint PPT Presentation

Transcript of Chap. 7. Cases where extended transactions are recommended:

Page 1: Chap. 7. Cases where extended transactions are recommended:

Chap. 7. Cases where extended transactions are recommended:

• ERP systems • E-commerce• Mobile-commerce• Patient records/Elektronisk patientjournal• Airline reservation systems• CSCW systemer• Distributed calender systems• Mobile applications• Supply chain management• Library systems• Banking systems

Page 2: Chap. 7. Cases where extended transactions are recommended:

Enterprise Resource Planning(ERP)

Page 3: Chap. 7. Cases where extended transactions are recommended:

A distributed modular ERP system have relaxed ACID properties across the autonomous databases of the ERP modules.

Orders

Accounts

Customers

Orderlines

Products

Stocks per product per location

Account items

The sales module

The account module offer services with relaxed ACID properties. (That is read-only, compensatable, and retriable subtransactions).

Exercise:How would you implement relaxed ACID properties between the modules?

Page 4: Chap. 7. Cases where extended transactions are recommended:

A distributed modular ERP system have relaxed ACID properties across the autonomous databases of the ERP modules.

Exercise:How would you replicate the department table?

Orders

Accounts

Customers

Orderlines

Stocks per product per location

Products

Account items

The sales module The account module offer services with relaxed ACID properties. (That is at least read, compensatable, and retriable services).

Departments

Departments

Page 5: Chap. 7. Cases where extended transactions are recommended:

A data model for an integrated E-commerce/ERP system:

LocationLocation#Address

UserSessionSession#IPaddress#ClickTimestamp

ProductProduct#ProductNamePrice

OrderOrder#OrderDateBalanceState

Order-DetailHistoryInv-Item#Order#Seq#StateTimestamp

UserAccountSalesman#PassWordTimestamp#visits#transTtl-tr-amount

Order-DetailProduct#Order#QtyPriceTimestamp

ShippingShipping#ShipMethodShipChargeStateShipDate

CreditCardCard#HolderNameExpireDate

PaymentPayment#AmmountStateTimestamp

InvoyceHistoryInvoice#TimestampStateNotes

AddressAddress#NameAdd1Add2CityStateZip

InvoiceInvoice#CreationDate

Billing

Shipping

Product-StockProduct#Location#Qty

CustomerCustomer#Kredit-LimitBalance

Exercise.Suppose a distributed modular ERP system has Sale, Accounting, Procurement, and CRM modules. What tables/table fragments should these modules own?

Page 6: Chap. 7. Cases where extended transactions are recommended:

Exercise: How would you implement relaxed ACID properties in the E-Government module?

Cases

Account items

Citizens

Case items

Item types

Accounts

An E-Governance module The account module offer services with relaxed ACID properties.

Case officers

Deparments

Page 7: Chap. 7. Cases where extended transactions are recommended:

Concept definitions used in logistic exercise:

Pallet = wooden skeleton where packages may be stored in such a way that they all can be moved by a truck.

Collie = alle the packages that are stored on a pallet(palle).

Leg = Route or subroute where the transportation does not have stops

Page 8: Chap. 7. Cases where extended transactions are recommended:

ER-diagram of a logistics management system

Transport Orders Customers

Transport medias like ships, airplanes, and trucks.

Physical containers

Scheduled routes and legs

Orderlines

Packages, Collies and Containers

Locations

Route-leg hierarchy

Package- Collie hierarchy

Routes and legs

from

to

Damagerelationship

from to

Container-routesrelationships of order 3

Transport operator

How should the transport orders and sub-orders to sub-contractors be replicated in order to optimize the transports?

Page 9: Chap. 7. Cases where extended transactions are recommended:

Transport Orders Customers

Transport medias like ships, airplanes, and trucks.

Physical containers

Scheduled routes and legs

Orderlines

Packages, Collies and Containers

Locations

Route-leg hierarchy

Package- Collie hierarchy

Routes and legs

from

to

Damagerelationship

from to

Global ER-diagram of integrated logistics management

Container-routesrelationships of order 3

Transport operator

Describe the local databases in the central location of the transport company, the locations of the sub-contractors, and the mobile locations of the Transport medias. Design a workflow with focus on the integration of the local database locations.

Page 10: Chap. 7. Cases where extended transactions are recommended:

Petri net: Work flowof a global E-commerce transactions where the stocks are in the locations of the different suppliers.

1. Put products in the basket

Start

Timer

2. Confirm order-lines and update stocks in servers

4. Receive products from suppliers and update QUANTITY received

6. Send the rest of the products to the customer

End

3.Suppliers send products

Non confirmed order

Products

All products are received

5. Send the received products to the customer

Suborders

Canseled order

Stock rejected order

Confirmed order

OR split

Page 11: Chap. 7. Cases where extended transactions are recommended:

Sub- Petri net of activity 2

2.1 try to confirm thenext order-line

Order-line

An-swer

Nonconfirmedorder

2.2 Supplier's servertry to confirm

order-line

More order-lines

2.3 Update Order with supplieranswer for each order-line

All answers received

Order-line

Order

Order

2.4 Send Order with confirmanswers to the Customer. If theOrder was confirmed The Timeris set and confirming Sub-ordersare send to the involvedsuppliers.

Timer Sub-orders

Confirmed Order

Stockrejectedorder

May the suppliers be transport sub-contractors?

AND split

OR split

AND join

Page 12: Chap. 7. Cases where extended transactions are recommended:

Transport Orders Customers

Transport medias like ships, airplanes, and trucks.

Physical containers

Scheduled routes and legs

Orderlines

Packages, Collies and Containers

Locations

Route-leg hierarchy

Package- Collie hierarchy

Routes and legs

from

to

Damagerelationship

from to

Global ER-diagram of integrated logistics management

Container-routesrelationships of order 3

Transport operator

How would you recommend to integrate and later merge the shipping companies Maersk and P&O Nedlloyd if Maersk had used the logistics architecture above?

Page 13: Chap. 7. Cases where extended transactions are recommended:

Ressourcetypes

Physical ressources

Input Output OutputInput

Physical processes

Logical processes

Logical products

Physical products

Time

Exercise. Suppose a production firm has central planning and de-central production. How would you recommend to design the planning and production modules of a distributed modular ERP system that support the organization of the compamy?

Page 14: Chap. 7. Cases where extended transactions are recommended:

Exercise: How would you implement/replicate the tables Network Branches?

Page 15: Chap. 7. Cases where extended transactions are recommended:

Design a modile distributed calender system!

DatesMeatings/

appointments

Room-Location

Relationship

Rooms

PersonsRoles Participants

Time

Locations

ER-diagram of an integrated calender and meating system:

Page 16: Chap. 7. Cases where extended transactions are recommended:

Exercise: How would you implement relaxed ACID properties in the Supplier module?

Suppliers Supplier orders

Products

Product-stocks

Delivery locations

Accepted product deliveries

Orderllines

Page 17: Chap. 7. Cases where extended transactions are recommended:

Exercise:

Customers Orders Products Orderlines

Product-stocks Locations

Describe and design the local databases for a distributed brewery with many different production, sale and depot locations.

Can a distributed modular ERP system bee used to integrate the different locations?

Page 18: Chap. 7. Cases where extended transactions are recommended:

Electronic Health Records (EHR)

Patients

Healthrecords

Hospitaladmis-sions

Diag-noses

Pre-scrip-tions

Surge-ries

Hospitaldis-charges

- Patient - ID- Name - Address- Balance

…….

EHR records should be craeted by Hospital service modules that are exchangable as the modules in a distributed modular ERP system. That is, Hospital service modules should offer and only use reading, compensatable, and retriable SOA services from other modules.

Page 19: Chap. 7. Cases where extended transactions are recommended:

Electronic Health Records (EHR)

Patients

Healthrecords

Hospitaladmis-sions

Diag-noses

Pre-scrip-tions

Surge-ries

Hospitaldis-charges

- Patient - ID- Name - Address- Balance

…….

Suppose all Health records are owned by the ”CRM module”. How would you recommend to integrate a new module that make test results that later are used for making diagnoses? How would you recommend to integrate the diagnose module? How would you recommend to integrate the Surgery planning module and the Surgery module itself?

Page 20: Chap. 7. Cases where extended transactions are recommended:

Health records

Treat-ments

Diagnoses/diseases

Patient admits

Sympthoms/test results

Employees

Pres-criptions

Prescription lines

Patient discharges

...

Conseptual hospital entites in general are below the dottet line

Basic Health records are above the dottet line

...Patient admit types

Health record subtypes

Figure 2. Generalized ER diagram of a local hospital database

Medical tests

subtypes

Sympthom types

Disease types

Treatment types

Patient discharge

types

Medicin types

Medicin productsMedicin

companies

Patients Patient IDNameAddress

ER-diagram for an EHR system

Page 21: Chap. 7. Cases where extended transactions are recommended:

Health records

Treat-ments

Diagnoses/diseases

Patient admits

Sympthoms/test results

Employees

Pres-criptions

Prescription lines

Patient discharges

...

Entities with different versions of 1-safe designsEntities with different versions of 0-safe designs

...Patient admit types

Health record subtypes

Figure 2. Generalized ER diagram of a local hospital database

Medical tests

subtypes

Sympthom types

Disease types

Treatment types

Patient discharge

types

Medicin types

Medicin productsMedicin

companies

Patients Patient IDNameAddress

ER-diagram for an EHR system

Page 22: Chap. 7. Cases where extended transactions are recommended:

The 0-safe design with local commit:

Nearest location Remote location Client

Trans. record drecord

The 0-safe design with local commit is recommended when it is possible to implement sufficient local countermeasures against the isolation anomalies.

Example.

Patients_____ Patient IDNameAddress

SympthomsSymptom

types

Page 23: Chap. 7. Cases where extended transactions are recommended:

The 0-safe design with deferred commit:

The 0-safe design with deferred commit is recommended when update delays should be minimized, and when it is not possible to implement sufficient local countermeasures against the isolation anomalies.

Example.

Nearest location Primary location Client

Compensate?

Trans. record drecord

Compensate?

Patients_____ Patient IDNameAddress

Diagnoses/diseases

Disease types

Page 24: Chap. 7. Cases where extended transactions are recommended:

Health Records Database

Patients

Healthrecords

Hospitaladmis-sions

Diag-noses

Pre-scrip-tions

Surge-ries

Hospitaldis-charges

- Patient - ID- Name - Address- Balance

…….

Entities with different versions of 0-safe design

Deffered commit Local commit

Page 25: Chap. 7. Cases where extended transactions are recommended:

Patient records

TreatmentsDiagnoses/diseases

Patient admits Sympthoms

Doctors

Ordinations

Ordination lines

Patient discharges

...

Entities of conceptual

objects

Entities of physical objects

...Patient admit types

Patient record subtypes

Figure 1. Generalized ER diagram of a local hospital database

Medical tests

Sympthom types

Disease types

Treatment types

Patient discharges

types

Medicin types

Medicin productsMedicin

companies

Patients_____ Patient IDNameAddress

Entities with different versions of 0-safe design

Entities with the basic 1-safe design

Page 26: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Soft-ware costs

Anomaly pro-blems

1. Integration by using SOA health services

Best Worst Worst Worst

2. Central database solution Worst Best Best Best

3. Central database solution mixed with SAO  integration

Average Above worst

Average Above worst

4. Distributed subscriber solution Best Best Worst Average

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central database solution with central subscription and SOA services to others

Average Average Average Average

7. Central database solution mixed with distributed subscription on top of central subscription

Average Best Average Average

Overview of the most important EHR integr. architectures

Page 27: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

1. Integration by using SOA health services

Best Worst Worst Worst

2. Central database solution

Worst Best Best Best

3. Central database solution mixed with SAO  integration

Average Above worst Average Above worst

Read

Read

Hospital of residence Hospital of admission

Any other hospital

Data

Data Data

Page 28: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

1. Integration by using SOA health services

Best Worst Worst Worst

2. Central database solution

Worst Best Best Best

3. Central database solution mixed with SAO  integration

Average Above worst Average Above worst

UpdateHospital of admission

Any other hospital

Central database with all functions

Update

Read

Hospital of residence

Data

Page 29: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

1. Integration by using SOA health services

Best Worst Worst Worst

2. Central database solution

Worst Best Best Best

3. Central database solution mixed with SAO  integration

Average Above worst Average Above worst

UpdateHospital of admission

Any other hospital

Central database with only new develloped functionsData

UpdateRead

Hospital of residence

Read

ReadData

DataData

Page 30: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

4. Distributed subscriber solution Best Best Worst Average

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central solution with central sub-scription and SOA services to others

Average Average Average Average

Hospital of residence Hospital of admission

Any other hospital

Update

Update

Data

DataData

Page 31: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

4. Distributed subscriber solution Best Best Worst Average

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central solution with central sub-scription and SOA services to others

Average Average Average Average

UpdateHospital of admission

Any other hospital

Update

Read

Hospital of residence

Central read distribution of redundant dataData

DataData

Data

Page 32: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

4. Distributed subscriber solution Best Best Worst Average

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central solution with central sub-scription and SOA services to others

Average Average Average Average

UpdateHospital of admission

Any other hospital

Central database with new develloped functionsData

UpdateRead

Hospital of residence

Read

ReadData

DataData

Page 33: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Software costs

Anomaly problems

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central database solution with central subscription and SOA services to others

Average Average Average Average

7. Central solution mixed with distributed subscription on top of central subscription

Average Best Average Average

UpdateHospital of admission

Any other hospital

UpdateHospital of residence

Update Update

Data

Central update distribution of both redundant and central data

Data Data

Data

Page 34: Chap. 7. Cases where extended transactions are recommended:

Architectures for integrating electronic health records

Evaluation criteria

Local auto-nomy

Read perfor-mance

Soft-ware costs

Anomaly pro-blems

1. Integration by using SOA health services

Best Worst Worst Worst

2. Central database solution Worst Best Best Best

3. Central database solution mixed with SOA  integration

Average Above worst

Average Above worst

4. Distributed subscriber solution Best Best Worst Average

5. Central subscriber offering SOA services to others

Best Average Worst Average

6. Central database solution with central subscription and SOA services to others

Average Average Average Average

7. Central database solution mixed with distributed subscription on top of central subscription

Average Best Average Average

Overview of the most important EHR integr. architectures

Page 35: Chap. 7. Cases where extended transactions are recommended:

Countermeasures against missing isolation property

Patients

Healthrecords

Hospitaladmit-ments

Diag-noses

Pre-scrip-tions

Surge-ries

Hospitaldis-charges

- Patient - ID- Name - Address- Balance

…….

Version file countermeasure

Commutative update countermeasure

Version file countermeasure

Pessimistic view countermeasure for related resources

Page 36: Chap. 7. Cases where extended transactions are recommended:

Properties of different EHR database design methods Evaluation criteria Database designs for EHR systems.

Traditional normalized database design

XML based storing of variable health attributes

Generalized subtypes are used for storing variable health attributes

Flexibility towards new health record types

Worst Best Best

Performance of overview queries

Worst Best Best

Performance of queries that need variable health attributes

Best Average Worst

Storage consumption Best Average Worst

Development costs for table driven applications

Worst Best Best

Flexibility towards data analyses

Average Worst Best

Is normalization used? Yes No No

Page 37: Chap. 7. Cases where extended transactions are recommended:

EHR Datawarehouse:

Departments

The most important attributes of Electronic Health Record eventsFact table

Dimensions

Conformed dimension hierarchies

Hospitals

Regions

Contries

Attributes special for ERP event type 1

Dimensions for event type n

Time dimensionPatientsEHR event

types

Attributes special for ERP event type n.........

One-to-one relationship One-to-one relationship

Dimensions for event type 1 .........

Dimension hierarchies special for the different event types

Page 38: Chap. 7. Cases where extended transactions are recommended:

Properties of different EHR database design methods Evaluation criteria Database designs for EHR systems.

Traditional normalized database design

XML based storing of variable health attributes

Generalized subtypes are used for storing variable health attributes

Flexibility towards new health record types

Worst Best Best

Performance of overview queries

Worst Best Best

Performance of queries that need variable health attributes

Best Average Worst

Storage consumption Best Average Worst

Development costs for table driven applications

Worst Best Best

Flexibility towards data analyses

Average Worst Best

Is normalization used? Yes No No

Page 39: Chap. 7. Cases where extended transactions are recommended:

Chap. 7. EHR integration with ERP:

EHR event type

EHR Fact table Common EHR event subtype

Surgery

Surgery item

Accounts

Account itemSymp/Test

Item

Symptoms/Tests

Existing EHR System

New Suregry ModuleAccounting Module of ERPNew Test Module

Work flow processes

Planning Module of ERP

Integration of new modules into an existing EHR system

Page 40: Chap. 7. Cases where extended transactions are recommended:

Design a Distributed Airline Database

Design local databases and the workflow of an integrated distributed database that integrate the e-commerce sale of different airline companies in a way that optimize performance, availability and consistency of a common distributed airline system with local databases in the airline companies, airports, and “sale offices” at e.g. travel agents, hotels and e-commerce servers. (Do not use a GDS in this exercise).

Flight routes

Subroutes

Departures

Airports

Tickets

Travel arrangement

Customers

Airline companies

Plains

Plain types

Page 41: Chap. 7. Cases where extended transactions are recommended:

Exercise:

Hotels

Rooms

Room reservations

Services/ tours/ car rentals Check-in

periods

Customers Customer groups

Hotel chains Design local databases and the

workflow of an integrated distributed database that integrate the e-commerce sale of different airline companies, hotel chains in a way that optimize performance, availability and consistency of a common distributed system with local databases in the airline companies, hotel chains, airports, car rental companies, and “sale offices” at e.g. travel agents, hotels and e-commerce servers. (Do not use a GDS in this exercise).

Describe the workflow of the integrated e-commerce system.

Page 42: Chap. 7. Cases where extended transactions are recommended:

Exercise

How would you recommend integrating two airline companies?

Does it make any difference whether the companies are in alliance or not?

What problems may occur if travel arrangements are converted while some of the flights are not finished yet?

Can the ideas of a distributed modular ERP system be used?

Flight routes

Subroutes

Departures

Airports

Tickets

Travel arrangement

Customers

Airline companies

Plains

Plain types

Page 43: Chap. 7. Cases where extended transactions are recommended:

Exercise: A GDS (Global Distribution Service) is a worldwide computerized reservation system for reserving airline tickets, hotel rooms, rental cars, and other travel related items. The largest GDSs are Amadeus, Galileo, Sabre, and Worldspan. Design an integrated distributed database that integrate the databases of different airline companies and hotel chains in a way that optimize performance, availability and consistency of a common distributed system with local databases in GDSs, the airline companies, hotel chains, airports, and “sale offices” at e.g. travel agents, hotels and e-commerce servers.

GDSSuppliersof travelproducts

Secondaryonline reservation sites

Primaryonline reservation sites

The relationships of the diagram illustrate that a travel product stored in one system may be stored in many other systems from where data are replicated in sequence from left to right between the different types of systems. How would you design relaxed ACID properties in the global distributed system?

Page 44: Chap. 7. Cases where extended transactions are recommended:

How would you design a workflow for flexible transactions?

Committing subtransaction

Root transaction

Page 45: Chap. 7. Cases where extended transactions are recommended:

Routing by using flexible transactions.

Question 1. Describe a Petri net workflow for flexible transactions.

Question 2. Change the Petri net workflow in such a way that it also functions for recovered transactions.

Syntax for the State diagram:

Event

[condition]

Action

Page 46: Chap. 7. Cases where extended transactions are recommended:

Workflow of flexible transactions.

Page 47: Chap. 7. Cases where extended transactions are recommended:

Workflow for making mobile control of supplier deliveries.

Delivery larger than ordered

Delivery matches an Orderline

Delivery less than ordered

Delivery is not ordered

Select a con-trol action

Product deliveries

Orderlines are replicated to the mobile controllers

New Supplier

orders.

Orderlines

Reduced product delivery

ANDJOIN

Update the local stock

Replicate the mobile registrations to the central ERP system

Error reports

Accepted product deliveries

Accepted product deliveries

End of workflow

ANDSPLIT

ANDSPLIT

Reduced orderline

InputInput is supplier orders or deliveries.

What is the most important part of the workflow from a system integration point of view?

Page 48: Chap. 7. Cases where extended transactions are recommended:

Workflow for making mobile control of supplier deliveries.

Delivery larger than ordered

Delivery matches an Orderline

Delivery less than ordered

Delivery is not ordered

Select a con-trol action

Product deliveries

Orderlines are replicated to the mobile controllers

New Supplier

orders.

Orderlines

Reduced product delivery

ANDJOIN

Update the local stock

Replicate the mobile registrations to the central ERP system

Error reports

Accepted product deliveries

Accepted product deliveries

End of workflow

ANDSPLIT

ANDSPLIT

Reduced orderline

InputInput is supplier orders or deliveries.

How would you implement the database of the workflow?

Page 49: Chap. 7. Cases where extended transactions are recommended:

A:

Workflow nodes

Places Activities

Colored tokens

Branches from one workflow node to another

from

to

Page 50: Chap. 7. Cases where extended transactions are recommended:

Allokation of fragments:

Customers Orders Products Orderlines

Product-stocks Locations

Can the Product and Product stock tables be integrated to a single table locally?

Can a DDBMS allocate fragments from different tables in a single local table?

Allocation is the physical placement of fragments in different locations. Allocated fragments may be redundant.

Exercise:How are the tables fragmented and allocated in a distributed ERP system?

Page 51: Chap. 7. Cases where extended transactions are recommended:

End of session

Thank you !!!Thank you !!!