Sd2052 - Lect 3 and 4 Entity Modelling 2010

SD2052 - Database Systems 1

ReviewA data model is a (relatively) simple abstraction of a complex real-world data environmentBasic data modeling components are:

EntitiesAttributesRelationshipsConstraints

Importance of Business RulesRelational model

Current database implementation standardER model is a popular graphical tool for data modeling that complements the relational model

Data modeling requirements are a function of different data views (global vs. local) and level of data abstraction: External, Conceptual, Internal

SD2052 -

DATABASE SYSTEMS

LECTURE 3 and 4:

ENTITY RELATIONAL

MODELLING

Source: Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel


Learning Outcome

That the relational database model takes a logical view of data

The main characteristics of entity relationship components

How ERD components affect database design and implementation

The relational model’s basic components are relations implemented through tables in a relational DBMS

How relations are organised in tables composed of rows (tuples) and columns (attributes)

How relationships between entities are defined and refined and how those relationships are incorporated into the database design process


Entity Relationship Modelling

ER (Entity-Relational) model developed by Peter Chen in 1976 to aid database design. Used for conceptual design.

ER diagrams give a visual indication of the design. It is a diagrammatic technique used to analyse the nature of application system


The Importance of Data Models

Data models

Relatively simple representations, usually graphical, of complex real-world data structures

Facilitate interaction among the designer, the applications programmer, and the end user

End-users have different views and needs for data

Data model organises data for various users


Business Rules

Brief, precise, and unambiguous descriptions of policies, procedures, or principles within a specific organisation

Apply to any organisation that stores and uses data to generate information

Description of operations that help to create and enforce actions within that organisation’s environment

Must be easy to understand and widely disseminated

Describe characteristics of the data as viewed by the company


Basic Characteristics of ER Data Model

Entity (Table):

Anything about which data are to be collected and stored, eg, customer, student, products (generally nouns)

Attribute (Column Headings/Field):

Characteristic or properties of an entity, eg, name, date of birth, description, Employee_Name, Student_Name, etc

Relationship:

Describes an association/relationship (generally verbs)among entities

One-to-many (1:M) relationship

Many-to-many (M:N or M:M) relationship

One-to-one (1:1) relationship

Constraint:

A restriction placed on the data. Eg, a student can only enroll on one course.


Examples of ER Modelling Notations


Case Study: Tiny College

Business Rules:A professor may teach many classes, however a class can only be taught by only one professor.

A class may enrol many students, and each student may enrol in many classes.

Each course may generate many classes, but each class references a single course.

Finally, a class requires one room, but a room may be scheduled for many classes.


Example of Crow’s feet ER Model

Entity

Degree of relationship

Relationship name Optionality/ cardinality

NOTE: You should be able to ‘read’ an E-R model in sentence form. e.g “A professor

teaches many class(es)” and “A class can only be taught by one professor”. The subject and object of the sentence are entities (nouns) and the relationship is the verb. Inverse relationship names should be shown.


Attributes

An attribute is a property or characteristic of an entity that is of interest to the organisation.

Eg, Date_of_Birth, Student_Name, Years_Employed, Product_Description, etc

Attributes represents column headings/fields in a relational table

The domain of an attribute is the set of allowable values for the attribute.

Eg the domain of the attribute, “Student_Name” may be “Diana”, “Charles”, etc


Attributes - Keys

Primary key (PK) is an attribute (or a combination of attributes) that uniquely identifies any given entity (row):

Primary Key/Superkey (PK)

Any key that uniquely identifies each row

Foreign key (FK)

An attribute whose values match primary key values in its original table

Composite key

Composed of more than one attribute

Candidate key

A superkey without redundancies


Composite Key

Composite Key:Composite entity/table must contain at least the must contain at least the primary keys of original tablesprimary keys of original tables

Linking entity/table contains multiple occurrences of the foreign key values. Must be repeated in table

Student Enroll ClassST_ID ST_ID CL_IDCL_ID

ST_ID CL_ID Date_Enroll

S_01 C_04 17-Jan-09

S_01 C_07 17-Jan-09

S_20 C_04 17-Jan-09

S_01 C_15 17-Jan-09


Example of Keys

Primary Key

Primary Key

Foreign Key


Relationship Degree

Indicates number of entities or participants associated with a relationship

Binary relationship

Two entities are associated

Ternary relationship

Three entities are associated

Unary relationship

Association is maintained within single entity


One-to-Many Relationships

1:M relationship (Binary relationship)

Relational modeling ideal

Should be the norm in any relational database design

(Binary relationship) - Two entities are associated

The Primary Key from the “1” relationship must be included in

the ”M” relationship.


22 7799

Course Classhas

has


Instance of an entity

Think of instances as records/rows

in a table

Instance of

an entity




One-to-One Relationships

1:1 relationshipShould be rare in any relational database design

One entity can be related to only one other entity, and vice versaSometimes means that entity components were not defined properlyCould indicate that two entities actually belong in the same tableAs rare as 1:1 relationships should be, certain conditions absolutely require their use

Where would you put the Foreign Key?


1:1 Relationship (Table format)

A Foreign Key must be included in one of the entities/tables that are related base on business rule.


Many-to-Many Relationships

M:N relationshipsCannot be implemented as such in the relational model

M:N relationships can be changed into two 1:M relationships

Can avoid problems inherent to M:N relationship by creating a composite entity or bridge entity

Where would you put the Foreign Key?


Data Redundancy

Data redundancy leads to data anomalies:

Such anomalies can destroy the effectiveness of the database

Insertion: Occur when entering new records

Deletion: Occur when deleting records

Modifications/update: Occur when changes must be made to existing records.

Foreign keys

Control data redundancies by using common attributes shared by tables

Crucial to exercising data redundancy control


The M:N Relationship (contd)

How many classes is Bowser taking?

You must have only single valued data for each attribute.





To resolve the M:N relationship:

Must convert the M:N to 1:M

Include a Linker (composite)

entity/table between entities

Composite entity/table must contain at least the primary keys of original tables

Linking entity/table contains multiple occurrences of the foreign key values

Additional attributes may be assigned as needed



Linker

Entity/Table

Transfer both “M”

relationship symbol to the Linker entity/table



Composite

Keys

Foreign Key values

are being repeated for

each record



Where would you put the Foreign Keys?




Connectivity and Cardinality

Connectivity/Optionality

Used to describe the relationship classification

Cardinality

Expresses minimum and maximum number of entity occurrences associated with one occurrence of related entity

Established by very concise statements known as business rules


Connectivity and Cardinality (contd)


Relationship Participation (contd)


Relationship Participation

Optional participation

One entity occurrence does not require corresponding entity occurrence in particular relationship

Mandatory participation

One entity occurrence requires corresponding entity occurrence in particular relationship

OptionalMandatory


Relationship Participation (contd)


Unusual Relationships: Ternary relationship

3-Way

Linker


Unusual Relationships: Ternary relationship


Unusual Relationships: Unary relationship (Recursive)

Relationship can exist between occurrences of the same entity set

Naturally found within unary relationship


Recursive Relationships (contd)


Recursive Relationships (contd)


Unusual Relationship (contd)

Student

Lecturer

Tutored by

tutors

S#

L#

L#

Taught b

y

teaches

Student taught by “M” Lecturer – Lecturer teaches “M” student

Student tutored by one lecturer – Lecturer tutors “M” student


Case Study: Tiny College (Recap)

Business Rules:A professor may teach many classes, however a class can only be taught by only one professor.

A class may enrol many students, and each student may enrol in many classes.

Each course may generate many classes, but each class references a single course.

Finally, a class requires one room, but a room may be scheduled for many classes.


Tiny College ER Modelling/Diagram


ER Modelling - stepsNOTE: (this is how I do it)

First of all, identify the enterprise which is = TINY COLLEGE (YOU DO NOT MODEL THE ENTERPRISE)

Secondly, read through the scenario and identify the entities (remember what an entity is !!)

Third, read through again and try to establish the relationships between the entities.

Fourth, go through the scenario again and try to identify attributes of entities. This way, it is highly possible that some of the entities that may have been identified will actually come out as attributes by the time you are through.

CAUTION: Do not read too much into the scenario and try to incorporate things that are not RELEVANT to the Application Domain but which may be CONVENIENT for you.


RULES AND TIPS IN ER Modelling/DIAGRAM

1. One to One Relationships:For each binary 1:1 relationship choose the entity with total participation and include the Primary key of the other in that entity as a foreign key

2. One to Many Relationships:For each 1:M relationship - move the Primary key from the entity on the 1 side to the entity on the M(many) side where it will become a foreign key.

3. Many to Many Relationships:For each M:M relationship – break it up with a new entity called a linker. Combine the Primary keys from the original tables which then become a COMPOSITE KEY (in the linker table).


Assumptions

Assumptions are very important in ER diagramming

ER modelling is highly subjective. It is similar to painting a picture. The artists perception is what is painted.

In ER modelling assumptions can be made by the modeller with regards to the Application domain, although whatever assumption made must fit within the Application domain.

Assumptions are made to highlight those important facts that are not so obvious, they are ambiguous,but influences the identification of entities, relationships or attributes.


Assumptions (Contd)

Example:

Draw an entity-relationship diagram for database showing fatherhood, motherhood and spouse relationships among men and women.

ER 1 for scenario 1 ER 1 for scenario 2

Husband Wife

Child

has

has

Husband/

Father

Wife/

Mother

Child

has

has


Assumptions

For scenario 1:In Western cultures Each man marries one and only one wife at a particular time.In Western cultures Each woman marries one husband at a particular time.Each child belongs one parent (i.e. if the Application Domain has a specific restriction. Eg. If modelling relationship between only biological parents)

For scenario 2:In other cultures a man can marry one or more wives at a particular time.In other cultures a child can belong to one or more parents (i.e. if the Application Domain does not state any specific restriction)


Integrity Rules


THINKTHINKand be

POSITIVEPOSITIVEalways!

Sd2052 - Lect 3 and 4 Entity Modelling 2010

Documents

Transcript of Sd2052 - Lect 3 and 4 Entity Modelling 2010