GVHD: Assoc. Prof. Dr.

ngTrn Khnh

SV: Li Minh Lm Nguyn Bo Quc

51201837 51102795
1

outline
1. INTRODUCTION 2. RELATION CONSTRAINTS 3. ATTRIBUTE CONSTRAINTS 4. CAPTURING SEMANTICS 2

INTRODUCTION
+ Entity-Relationship modeling is a basic tool in database design + It is widely agreed that E-R models do a good job of capturing the basic semantics of many different situations,is limited on its expressive power + However, as databases are asked to support more complex applications, capturing more domain semantics is becoming a more pressing need

INTRODUCTION
Including more semantics can only be achieved if the domain semantics are gathered and represented in the conceptual model, at the requirement specification phase . Therefore, exploring enhancements and extensions to the E-R model becomes a legitimate and important area of research

INTRODUCTION
such addition should be :
minimal, in order to protect the simplicity of the E-R model, which is acknowledged as one its virtues; at the conceptual level, to fit with the rest of the model. powerful. In order to justify the addition, any construct should substantially contribute to the semantics of the model. In particular, any new constructs should have a clear and positive impact on database analysis and design.

INTRODUCTION
Clearly, this is a tall order that will be difficult to fulfill. Since capturing semantics is a never-ending task, there has to be a clear goal in mind (and, if possible, a cost/benefit analysis) for any extension proposed. What kind of additions should we consider? Where should the model be extended?

RELATION CONSTRAINTS
Example 1:
PRODUCT N
Concession

DEALER

concession -date

N STATE

each product must be sold by a single dealer in each state

7

RELATION CONSTRAINTS
N PRODUCT N
Distribute

Concession

DEALER

1 1

concession -date

N
1

STATE

LOCATED

each product must be sold by a single dealer in each state

8

RELATION CONSTRAINTS
Example 2:
Sem

1
Teaches

TEACHER

N
Faculty

N
COURSE

Offers

1 DEPARTMENT

teachers can only teach classes offered by the department in which they are faculty
9

RELATION CONSTRAINTS
Example 3:
EMPLOYEE

Manager

1
Manage Of

10

RELATION CONSTRAINTS
Example 4:
DIVISION
1
IsAllocated

1
Operates

N
STAFF

N
BRANCH

11

RELATION CONSTRAINTS
DIVISION
1
IsAllocated

1
Operates

N N
Works-at

N
1

STAFF

BRANCH

12

ATTRIBUTE CONSTRAINTS
EMPLOYEE

RANK

SALARY

13

CAPTURING SEMANTICS
Traditional Applications
+ Based on a model of small, + local transactions, + involved simple + localized database access

14

CAPTURING SEMANTICS
Todays applications
+ require complex, + global data manipulation + It is not enough to achieve a certain normal form anymore

15

CAPTURING SEMANTICS
many of the examples above would be simply written down in natural language, because of a lack of tools to (semi)formally express such constraints . This information tends to be lost and not make it into the database design, since it may be difficult to interpret (because of vagueness and ambiguity) and there are no established methods to incorporate such information into a design

16

CAPTURING SEMANTICS
We contend that the E-R model is the place where the added information should be placed, for at least two reasons. + First, the new additional information carries its full meaning only in the context of the basic information already present in the E-R model. +Second, the new information must be used in the database design process. There are well known methodologies to transform an E-R diagram into a database design; -> therefore, adding information to the E-R model opens up the possibility of extending said methodologies as a proven way to incorporate the extra semantics into database design
17

For example, if one entity type happens to be an instance of another, there is no way to say this in an entity-relationship diagram.

18

Each pump is a member of exactly one equipment type. So, according to this data model, it is not the entity type pump that is an instance of equipment type.

19

however, one type of relationship that is between entity types and that is the subtype/supertype relationship.

20

THANKS FOR YOUR ATTENTION !

21