Distributed Database Systems

CHP 4 DB INTEGRATION – CASE STUDY

Database Integration
Bottom-up Design
 Overview
• The design process in
multidatabase systems is Database 1 Database 2 Database 3
bottomup.
– The individual databases Translator 1 Translator 2 Translator 3
actually exists
– Designing the global InS1 InS2 InS3
conceptual schema (GCS)
involves integrating these Intermediate
local databases into a schema in
canonical
multidatabase. representation INTEGRATOR
• Database integration can
occur in two steps:
GCS
Schema Translation and
Schema Integration.
 Network Data Model (Review)
• There are two basic data structures in the network
model: records and sets.
Record type: a group of records of the same type.
Set type: indicates a many-to-one relationship in the direction of the arrow.

DEPARTMENT (DEPT-NAME, BUDGET, MANAGER) owner record type

Employs set type
EMPLOYEE (E#, NAME, ADDRESS, TITLE, SALARY)
member record type

• Implementation of set instances:

DEPARTMENT (owner record)
Database

EMPLOYEE
Jones, L. (member records)

Patel, J. Vu, K.
Example: Three Local Databases
Database 1 (Relational Model):
S (TITLE, SAL)

E (ENO, ENAME, TITLE)

J (JNO, JNAME, BUDGET, LOC, CNAME)

G (ENO, JNO, RESP, DUR)

Database 2 (Network Model):

DEPARTMENT (DEPT_NAME, BUDGET, MANAGER)
Employs
Dummy
Work
Record Type
Worksin

EMPLOYEE (E#, NAME, ADDRESS, TITLE, SALARY)

Example: Three Local Databases

Database 3 (ER Model):

Project Project
Responsibility
Engineer Engineer No. Name
No. Name
Budget
1
ENGINEER N WORKS PROJECT
IN
N
Location
Title Salary CONTRACTED
Duration BY

Contract 1
Date
CLIENT

Client Address
Name
 Schema Translation: Relational to ER
S (TITLE, SAL)
JNO JNAME
ENO ENAME RESP
E (ENO, ENAME, TITLE)
N M
J (JNO, JNAME, BUDGET, LOC, CNAME) E G J
N
G (ENO, JNO, RESP, DUR) DUR LOC
BUDGET
PAY
CNAME
• E & J have a many-to- 1
many relationship
• E & S have a 1-to-many S
relationship
SAL
TITLE
Treat salary as
an attribute of
an engineer
JNO JNAME entity
ENO ENAME RESP

N M
E G J

SAL DUR BUDGET LOC

TITLE Relationships may be identified from
CNAME the foreign keys defined for each
relation.
 Schema Translation: Network to ER
DEPARTMENT EMPLOYEE WORK
N M
Employs Works-in

WORK EMPLOYS WORKS-IN

Dummy 1 1
record type
DEPARTMENT EMPLOYEE

N M
DEPARTMENT EMPLOYS EMPLOYEE

• Map each record type in the network schema to an entity

and each set type to a relationship.
• Network model uses dummy records in its representation of
many-to-many relationships that need to be recognized
during mapping.
 Schema Integration
Schema integration follows the translation
process and generates the GCS by
integrating the intermediate schemas.
– Identify the components of a database which
are related to one another.
• Two components can be related as (1) equivalent, (2)
one contained in the other one, (3) overlapped, or (4)
disjoint.
– Select the best representation for the GCS.
– Integrate the components of each
intermediate schema.
 Integration Methodologies

Integration
Process
Binary: Decreases the
potential integration
Binary N-ary
complexity and lead toward
automation techniques.

Ladder Balanced One-shot Iterative One-shot: There is no

implied priority for
integration order of
schemas, and the trade-off
can be made among all
schemas rather than among
a few.
 Schema Integration Process
Schema integration occurs in a sequence of four
steps:

• Preintegration: establish the “rules” of the integration

process before actual integration occurs.
• Comparison: naming and structural conflicts are identified.
• Conformation: resolve naming and structural conflicts
• Merging and restructuring: all schemas must be merged into
a single database schema and then restructured to create
the “best integrated schema.
 Schema Integration: 1.Preintegration
1. An integration method (binary or n-ary) must be
selected and the schema integration order defined.
– The order implicitly defines priorities.

2. Candidate keys in each schema are identified to

enable the integrator to determine dependencies
implied by the schemas.

3. The mapping or transformation rules should be

described before integration begins.
– e.g., mapping from degree Celsius in one schema to
degrees Fahrenheit in another.
Preintegration Example: InS1

Project Project
Responsibility No. Name
Engineer Engineer
No. Name
Budget
1
ENGINEER N WORKS PROJECT
IN
N
Location
Title Salary CONTRACTED
Duration BY

Contract 1
Date
CLIENT

Client Address
Name
 Preintegration Example: InS2 & InS3

Name
Dept-name Budget
E#
Title
Manager
N 1
EMPLOYEE EMPLOYS DEPARTMENT

Address Salary InS2

Resp JNO Jname

Eno Ename
Budget
M
ENGINEER N EMPLOYS J
InS3
Title Sal Cname Loc
Dur
 Keys & Integration Order

KEYS

InS1: Engineer No. in ENGINEER

Project No. in PROJECT
Client name in CLIENT

InS2: E# in EMPLOYEE
InS1 InS2 InS3
Dept-name in DEPARTMENT

Integration method InS3: Eno in E

Jno in J
 Schema 2.Comparison:
Naming Conflict (1)
Synonyms: two identical entities that have
different names.

InS1 InS3
ENGINEER E
Engineering No Eno
Engineer Name Ename
Salary Sal
WORKSIN G
Responsibility Resp
Duration Dur
PROJECT J
Project No Jno
Project Name Jname
Location Loc
 Schema Comparison:
Naming Conflict (2)
Homonyms: Two different entities that have
identical names.
• In InS1, ENGINEER.Title refers to the title of
engineers.
• In InS2, EMPLOYEE.Title refers to the title of all
employees.

domain (EMPLOYEE.Title) >> domain (ENIGNEREER.Title)

Schema Comparison – Relation
between Schemas
• Two schemas can be related in four
possible ways:
–They can be identical to one another.
–One can be a subset of the other.
–Some components from one may occur in other
while retaining some unique features
–They could be completely different with no
overlap.
• An attribute in one schema may represent
the same information as an entity in
another one
 Schema Comparison Example
• InS3 is a subset of InS2 E#

Name

ENGINEER EMPLOYEE Title

Address
EMPLOYS
IS-A relationship Salary

DEPARTMENT

• Some parts of InS (about engineers) and InS

 Schema Comparison – Structural
Conflicts (1)
• Type conflicts: occur when the same object is
represented by an attribute in one schema and by an
entity in another schema.
– The client of a project is modeled as an entity in InS ,
1
however
– the client is included as an attribute of the J entity in InS
3

N
Resp JNO Jname CONTRACTED
BY
PROJECT
Budget Contract 1
M
EMPLOYS
J Date
InS1
CLIENT
InS3
Cname Loc
Dur Client Address
Name
 Schema Comparison – Structural
Conflicts (2)
This is
1-to-many
Project
Dependency conflicts: Engineer
No.
Engineer
Name
No.

occur when different

1
relationship modes are ENGINEER N WORKS
IN
PROJECT
used to represent the
Title Salary InS1
same thing in different
schemas.
This is
Resp many-to-many
Eno Ename

M
ENGINEER N EMPLOYS J

Title Sal Dur InS3

 Schema Comparison: Structural
Conflicts (3)

• Key conflicts: occur when different candidate

keys are available and different primary keys are
selected in different schemas
• Behavioral conflicts: are implied by the modeling
mechanism,
– e.g., deletion of the last employee causes the dissolution
of the department.
 Conformation: Naming Conflicts
Naming conflicts are resolved simply by renaming
conflict ones.
Homonyms:
Synonyms: rename the schema of InS3 • Prefix each attribute
to conform to the naming of InS1. by the name of the
entity to which it
InS3 InS1 belong,
E ENGINEER e.g., ENGINEER.Title
Eno  Engineering No Engineering No EMPLOYEE.Title
Ename  Engineering Name Engineer Name • and prefix each entity
Sal  Salary Salary
by the name of the
G WORKSIN
schema to which it
Resp  Responsibility Responsibility
belongs.
Dur  Duration Duration
J PROJECT e.g., InS1.ENGINEER
Jno  Project No Project No InS2.EMPLOYEE
Jname  Project Name Project Name
Loc  Location Location
 3.Resolving Structural Conflicts
Transforming entities/attributes/relationships among one another

Responsibility Project Project

Engineer Engineer
No. Name
No. Name
Budget

InS3
M
ENGINEER N WORKS PROJECT
IN
Location
Client
Title Salary Name
Duration

Project Project
Responsibility
Engineer Engineer No. Name
No. Name
Budget
M
ENGINEER N WORKS PROJECT
IN
N
Location
Title Salary C-P
Duration
Example: M
New
Transform the attribute Client name in Client
C
InS3
InS3 to an entity C to make InS3 Name

conform to the presentation of InS1.

 Schema Integration:
4.Merging & Restructuring

Merging requires that the information contained in

the participating schemas be retained in the
integrated schema.
Merging using the IS-A
relationship

Use InS3 as the final schema

since it is more general in
terms of the C-P relationship
(i.e., many-to-many)
(next page)
InS2 InS3 InS1
(Employees) (Engineers) (Engineers)
 Integrate InS1 & InS3
Project Project
Responsibility
Engineer Engineer No. Name

InS1
No. Name
Budget
1
ENGINEER N WORKS PROJECT
IN
N Location
Title Salary CONTRACTED
Duration BY

Contract 1
Date
CLIENT

Client Address
Project Project Name
Responsibility
Engineer Engineer No. Name
No. Name
Budget
M
PROJECT
InS3 is
N
ENGINEER WORKS
IN
N Location
Title Salary CONTRACTED
more
Duration BY

M InS3 general
Client
Name C
 Merging & Restructuring Example
Final Result: Project Project
Duration No. Name
Responsibility

Budget
M
ENGINEER N WORKS PROJECT
IN
Location

CONTRACTED
E# BY

Name
CLIENT InS1/InS3
EMPLOYEE Title
N

Address Client Address

EMPLOYS name
SAL
1
InS2 DEPARTMENT
Unfortunately, Conformation and
Budget Manager Dept-name
restructuring stages are an art
rather then a science