Barkers Erd Notation

Entity Relationship Modelling
A short guide to designing Entity Relationship Models using Barkers notation. By Frankie Inguanez
Table of Contents
Part 01 - Introduction!...............................................................................................................4 Disclaimer ............................................................................................................................4 Scope of this document .......................................................................................................4 Purpose of this document ....................................................................................................4 Part 02 - Modelling! ...................................................................................................................5 Data Modelling .....................................................................................................................5 Entity Relationship Diagrams ...............................................................................................5 General Rules of ERDs ........................................................................................................5 ERD Concepts .....................................................................................................................6 Drawing an Entity .................................................................................................................7 Drawing attributes ................................................................................................................7 Drawing Relationships .........................................................................................................8
Optionality of a Relationship ! ......................................................................................................8 Relationship Perspectives! ..........................................................................................................9 Labeling of relationships!..........................................................................................................10 Degree of a Relationship ! .........................................................................................................11
UID Bar ..............................................................................................................................16 Recursive Relationships.....................................................................................................17 Redundant Relationships ...................................................................................................18 UID Attributes ....................................................................................................................19 Entity Subtypes ..................................................................................................................22
Entity Subtypes Rules! ..............................................................................................................22 Drawing subtypes!....................................................................................................................22 Implementing a subtype !..........................................................................................................24 Exclusive Relationship Arc!.......................................................................................................25 Rules of the exclusive relationship arc!.....................................................................................27 Drawing an exclusive relationship arc!......................................................................................27 Implementing an exclusive relationship arc! ..............................................................................27
Non-Transferability of Relationships ..................................................................................28

Drawing of Non-Transferability !................................................................................................28 Implementation of Non-Transferability!.....................................................................................28
Frankie Inguanez - 2012
Page 2 of 31
Part 04 - Notes .......................................................................................................................29 Part 04 Feedback and Queries ..........................................................................................31 Contact Details ..................................................................................................................31
Page 3 of 31
Entity Relationship Modelling - Introduction
Part 01 - Introduction
Disclaimer
The contents of this document is completely my work and no prot has been generated during the making or through this document.
The Barkers notation is not my work but rather the work of Richard Barker.
This document has been created for research and educational purposes and in no way is it intended for commercial use.
Use of this document in commercial projects is at your own risk.
The colours used in this document are purely for educational purposes and should not be considered as part of the notation being documented.
The name of items, products and persons listed in examples are purely ctional and intended for educational purposes and no advertisement or reference to actual persons is intended!
Scope of this document

This document is intended for database designers, educators and learners, This document is intended as supporting documentation to the topic of Entity Relationship Modelling in particular, using the Barker Notation.
Purpose of this document

My intention for this document is to portray my method and approach of explaining topics and to partially showcase my understanding of such topics.
Page 4 of 31
Entity Relationship Modelling - ERD Notes
Part 02 - Modelling
Data Modelling
Denition: A data model is a graphical representation of the solution to a problem as adopted by a particular community. Different communities trying to resolve the same problem will produce different yet valid solutions.
N.B. !
Entity Relationship Diagrams

Denition: An Entity Relationship Diagram is a logical diagram representing the database structure using the relational model. There are different notations or ERDs, for the following notes we shall be adopting Barkers notation.
N.B. !
General Rules of ERDs

1. Capture all required information 2. Information appears only once 3. Model no information that is derivable from other information already modelled 4. Information is in a predictable, logical place
Page 5 of 31
Entity Relationship Modelling - ERD Concepts
ERD Concepts
ERDs make use of three concepts: 1. Entity An entity is an object which the community trying to solve a problem, feel that it is important to include. Other communities trying to resolve the same problem might depreciate the entity to an attribute or else might completely omit it from their solution. E.g.: In a database collecting information of CDs one would expect to nd entities such as CD N.B. When implementing a database an entity would transmit to a table. N.B. An entity instance is a record within a table. ENTITY
2. Attribute An attribute is a property of an entity which describes the characteristics of a particular entity instance. An attribute can be of three types: a. Unique Identier: A UID is an attribute whose value uniquely identies an entity instance. A UID is implemented as a Primary Key. b. Mandatory Attribute: A mandatory attribute is one whose value cannot be null. c. Optional Attribute: An optional attribute is one whose value can be null. ENTITY # UID * Mandatory O Optional
3. Relationship A relationship links two or more entity instances together. N.B. A relationship is implemented as a Foreign Key and therefore the FK attribute is not listed as an attribute in the target entity. EMPLOYEE # Id * Name * Surname DEPARTMENT have # Id * Name
work in
Page 6 of 31
Entity Relationship Modelling - Drawing Concepts
Drawing an Entity
When drawing an Entity using Barkers notation the following rules need to be respected: 1. An entity is a rounded corner rectangle. 2. An entity must be named and the name must be placed inside of the entity, upper most part. 3. The entity name should be in upper case form. 4. The entity name should be in singular form. E.g.: CD CAR PERSON SCHOOL TOWN
Drawing attributes
When drawing an Attribute using Barkers notation the following rules need to be respected: 1. The attributes must be written such that all persons can understand and not just developers (meaningful terms) 2. Attributes must be written with the rst letter of each word in upper case and the rest in lower case. 3. Next to each attribute a symbol should be placed representing the type of attribute. E.g.: EMPLOYEE # Id * First Name * Last Name * Date of Birth * Telephone Number o Mobile Number DEPARTMENT # Id * Name JOB # Id * Title
N.B. The colours used in this document are solely to assist in the explanation of the topics.
Page 7 of 31
Drawing Relationships
When drawing a Relationship using the Barkers notation the following rules need to be respected: 1. A relationship can exist between a maximum of two entities. 2. A relationship can exist on the same entity. 3. A relationship has two perspectives. 4. Both perspectives of a relationship must be labelled. When drawing a Relationship using the Barkers notation the following steps need to be taken: 1. Determine the entities affected by the relationship. 2. Determine the optionality of the relationship. 3. Determine the degree of the relationship. 4. Label the perspectives of the relationship. Optionality of a Relationship 1. Mandatory Relationship: A mandatory relationship species that each instance from an entity must be related to another instance. This is represented by a straight line. 2. Optional Relationship: An optional relationship species that each instance from an entity may be related to another instance. This is represented by a dashed line.
Page 8 of 31
Relationship Perspectives A relationship is always made up of two perspectives using the following notation:
label a
First Perspective / A Perspective: Each A must label a one or more Bs
A label b
Second Perspective / B Perspective: Each B may label b exactly one A.
label a label b
E.g.: PERSON own

owned by
CAR
First Perspective / PERSON Perspective: Each PERSON may own one or more CARs. Second Perspective / CAR Perspective: ! Each CAR must be owned by exactly one PERSON.
AIRLINE
have belong to
AIRPLANE
First Perspective / AIRLINE Perspective: Each AIRLINE must have one or more AIRPLANEs. Second Perspective / AIRPLANE Perspective: ! Each AIRPLANE must belong to exactly one AIRLINE.
Page 9 of 31
Labeling of relationships When labelling relationships the following notations need to be followed:
label 4
A
label 3 label 2
label 1
1. 2. 3. 4. 5. E.g.:
A label should be applied for each perspective. A label should be a verb. A label should be written in lower case form. A label should be positioned according to the diagram shown above. A label should be relevant to the scenario.
LEAGUE # Id * Name * Year be won by be the winner of
TEAM # Id * Name
be organized by
be made up of
organize
be a member of
CONFEDERATION
PLAYER # Id * Name # Id * Name * Surname
Page 10 of 31
Degree of a Relationship A relationship can be one of three types: 1. One-to-One Relationship (1:1) Each entity instance is related to just one entity instance. In the following table we shall see the four possible combinations of a one-to-one relationship and the various optionality. In the last two columns we have an indication of the minimum and maximum number of entity instances that can be related according to perspective.
# 1
Scenario
Minimum A -> B 0
Maximum A -> B 1 B -> A 1
A
2
B B B B
B -> A 0
A -> B 1
A -> B 1 B -> A 1
A
3
B -> A 0
A -> B 0
A -> B 1 B -> A 1 A -> B 1 B -> A 1
A
4
B -> A 1 A -> B 1
B -> A 1
N.B. Labels and attributes have been removed from the above scenario since they are not the focus of the topic.
Page 11 of 31
The following table indicates where the foreign keys should be implemented:
# 1 Scenario Foreign Key FK should be placed in the entity with the least number of rows/nulls or where it is the most relevant. FK should be placed in entity A since there will never be any NULL values in the FK. FK should be placed in entity B since there will never be any NULL values in the FK. FK should be placed where it is the most relevant according to the scenario since it will never be a NULL value in the FK.
A
2
B B B B
A
3
A
4
N.B. Labels and attributes have been removed from the above scenario since they are not the focus of the topic. N.B. The FK attribute would never be listed in the ERD, the above explanation is referring to the database implementation phase.
Page 12 of 31
2. One-to-Many Relationship (1:M) Each entity instance is related to multiple entity instances. In the following table we shall see the four possible combinations of a one-to-one relationship and the various optionality. In the last two columns we have an indication of the minimum and maximum number of entity instances that can be related according to perspective.
# 1 Scenario Minimum Maximum A -> B 0 A -> B n B -> A 1 A -> B n B -> A 1 A -> B n B -> A 1 A -> B n B -> A 1
A
2
B B B B
B -> A 0 A -> B 1
A
3
B -> A 0 A -> B 0 B -> A 1 A -> B 1 B -> A 1
A A
N.B. Labels and attributes have been removed from the above scenario since they are not the focus of the topic. N.B. When implementing this type of relationship a foreign key should be placed in entity B, meaning the entity touched with the crows foot, many symbol, since many rows in B will be related to only one row in A.
Page 13 of 31
3. Many-to-Many Relationship (M:M) This type of relationship is never required and needs to be resolved.
# 1 Scenario Problem: A B
Solution: A AB B
Problem: A B
Solution: A AB B
Problem: A Solution: A AB B B
Problem: A B
Solution: A AB B
N.B. Labels and attributes have been removed from the above scenario since they are not the focus of the topic.
Page 14 of 31
The following steps need to be followed when resolving a many-to-many relationship: 1. Create a third/intermediary/transactional entity. A B AB
2. Add two one-to-many relationships from the original entities to the new entity. A B 3. The optionality from the AB perspective should always be mandatory. A B 4. The optionality of the remaining perspectives is derived from the original many-to-many relationship. 5. UID Bars are added to the AB perspectives (These indicate that the foreign keys are also primary keys refer to next chapter UID Bar). A B E.g.: AB AB AB
ORDER
have listed in
ITEM
ORDER
listed in refers to
ORDER ITEM
refers to listed in
ITEM
Page 15 of 31
Entity Relationship Modelling - UID Bar
UID Bar
It could be the case that sometimes a foreign key is also part of a primary key, generally a composite key. Consider the following scenario: A database stores a list of daily orders. A table is needed for the daily orders and another for the various items available. A third table (resolving a manyto-many relationship) lists the items sold in each order Implementation:
Table: Orders Order ID Order Date 1 22/11/10 2 23/11/10 Table: Order Items Order ID Item ID 1 10 1 1 2 2 20 30 10 20 Quantity 3 1 2 2 1 Table: Items Item ID Item Name Item Price 10 Coca 50 20 30 Fanta Sprite 40 30
N.B. Primary Keys are underlined and foreign keys are in italics. ERD:
ORDER listed in # Order Id * Order Date listed in * Quantity ORDER ITEM listed in listed in # Item Id * Item Name * Item Price ITEM
Problem: The problem with the above ERD is that we cannot indicate that the same foreign keys found in ORDER ITEM, represented by the relationships, are also the primary keys of the same entity. We cannot list the attributes and add a UID symbol (#) since Barkers notation requires that no data is represented twice. Solution:
ORDER listed in # Order Id * Order Date * Quantity listed in ORDER ITEM listed in listed in # Item Id * Item Name * Item Price ITEM
The solution is to add the UID Bar to the ORDER ITEM perspectives. Each individual UID Bar represents the fact that the foreign key represented by the relationship is also a primary key of the entity to which the perspective belongs to.
Frankie Inguanez - 2012 Page 16 of 31
Entity Relationship Modelling - Recursive Relationships
Recursive Relationships
There are situations where a relationship acts upon the same entity. This type of relationship is called a recursive relationship and is generally implemented by having a foreign key referring to the primary key of the same entity. Consider the following scenario: A company is made up of a number of employees. Joe is the chairman and has no manager. Joe is the manager of Tony and Lisa. Tony is the manager of Alex and Sarah. Lisa is the manager of Ian and Joanne. Organisational Structure Chart: Joe
Tony
Lisa
Alex ERD:
Sarah
Ian
Joanne
EMPLOYEE # Id * Name manage
managed by
Perspectives: ! Each EMPLOYEE may manage one or more EMPLOYEEs. Each EMPLOYEE may be managed by exactly one EMPLOYEE. Implementation:
Table: Employees Employee Id
1 2 3 4 5 6 7
Name
Joe Tony Lisa Alex Sarah Ian Joanne
Manager ID
1 1 2 2 3 3
N.B. Primary keys are underlined and foreign keys are in italics.
Frankie Inguanez - 2012 Page 17 of 31
Entity Relationship Modelling - Redundant Relationships
Redundant Relationships
It could be the case that the information represented by a relationship can be derived from other information already being represented in an ERD. This relationship is called a redundant relationship and needs to be removed. E.g.: COUNTRY # Id * Name host live in have located in TOWN # Id * Name host live in PERSON # Id * Name * Surname
Problem: The relationship between COUNTRY and PERSON is redundant since the same information can be deduced from the other two relationships. Solution ERD: COUNTRY # Id * Name
have
located in
TOWN # Id * Name
host live in
PERSON # Id * Name * Surname
N.B. There can be other relationships between COUNTRY and PERSON as long as it represents different information.
Page 18 of 31
Entity Relationship Modelling - UID Attributes
UID Attributes
There are four types of Unique Identier attributes which are implemented as primary keys: 1. Single UID Attribute: A single UID attribute is when an entity is made up of only one UID attribute which is not a foreign key. ERD: EMPLOYEE # Id * First Name * Surname Implementation:
Table: Employees Id 1 2 3 First Name Joe Tony Lisa Surname Borg Galea Abela
N.B. Primary keys are underlined. 2. Multiple UID Attribute: A multiple UID attribute is when a primary key is made up of multiple attributes (composite primary key) all of which are nonforeign keys. ERD: SOFTWARE # Name # Version Implementation:
Table: Software Name Oracle DBMS MySQL SQL Server Version 11g 5.1 2008
N.B. Primary keys are underlined.
Page 19 of 31
3. Composed UID Attribute: A composed UID attribute is when an entity has a primary key which is also a foreign key. These are marked with a UID Bar. ERD:
PERSON # Id * Name * Surname have refers to VISITED COUNTRY COUNTRY refers to listed in # Id * Name
Implementation:
Table: Persons Id 1 2 3 Name Joe Tony Lisa Surname Borg Galea Abela Table: Visited Countries Person ID 1 1 1 2 3 Country ID 1 2 3 4 4 Table: Countries Id 1 2 3 4 Name Italy England France Switzerland
N.B. The attributes Person Id and Country Id in the relation Visited Countries are the composed UID attributes since they are both foreign keys as well as primary keys in the VISITED COUNTRY entity. This is represented by the UID Bars on both relationships.
Page 20 of 31
4. Composed Cascade UID Attribute: A composed cascade UID attribute is when an entity uses its foreign keys as primary keys from an entity with composed UID attributes. ERD:
HOTEL # Id * Name have belong to
FLOOR have # Number located on
ROOM # Number
Implementation:
Table: Hotels Id 1 2 Name Hilton Westin Table: Floors Hotel ID Floor Number 1 1 2 1 2 2 Table: Rooms Hotel Id Floor Number 1 1 1 1 2 1 2 1 2 2 Room Number 1 2 1 2 1
N.B. Primary keys are underlined and foreign keys are written in italics. N.B. Hotel Id and Floor Number in ROOM are composed cascade attribute UIDs.
Page 21 of 31
Entity Relationship Modelling - Entity Subtypes
Entity Subtypes
There are situations where different entities can be grouped together under one common entity called a super type entity whilst the nested entities would be the subtype entities. E.g.:
CAR
SEDAN
STAFF
ACADEMIC
VENUE
PRIVATE VENUE HATCHBACK ADMINISTRATIVE PUBLIC VENUE
OTHER CAR
OTHER STAFF
Entity Subtypes Rules 1. Exhaustive Rule: This rule states that every entity instance of the super type must be an instance of one of the subtypes. 2. Mutually Exclusive Rule: This rule states that every entity instance of the super type can be an instance of only one entity subtype and not the other. Drawing subtypes When drawing entity subtypes the following notes need to be kept in mind: 1. Each subtype is a specialisation of a super type and therefore must be enclosed within an entity. 2. The common attributes and relationships for all subtypes must be listed in the super type only but are inherited in every subtype. 3. A subtype can and would generally have attributes and relationships of its own. 4. There can never be just one subtype; another subtype should be created to cater for the rest.
SUPERTYPE A
SUBTYPE B OTHER A
Page 22 of 31
N.B. If none of the subtypes have any unique attributes or relationships then it is not recommended to make use of subtypes but rather create a separate entity containing a list of the various types required. E.g.:
ENGINE TYPE # Id * Power * Capacity
VEHICLE used in use # Id * Number of passengers CAR * Number of doors * Has Roof-Rack
TRANSMISSION TYPE # Id * Name
used in use
OTHER VEHICLE MOTORCYCLE
have In this ERD note that:

The relationships acting on VEHICLE are also acting on its subtypes. Each subtype has attributes ID and Number of passengers. The CAR subtype has two extra attributes. The MOTORCYCLE subtype has an extra relationship. The OTHER VEHICLE subtype is catering for those VEHICLE instances that are neither cars nor motorcycles.
associated with CUSTOM HELMET # Id * Model Name
Page 23 of 31
Implementing a subtype There are various methods of implementing a subtype but the preferred method is as follows: 1. Create a table for the super type with all common attributes and relationships. 2. Create a separate table for each subtype. 3. In the subtypes include the specic attributes and relationships. 4. Create a foreign key in the super type for each subtype. 5. Impose a constraint that only one foreign key may not be null. 6. Impose a constraint that at least one foreign key must not be null. ERD: VENUE # Id * Name PUBLIC PRIVATE * Fee
Implementation:
Table: Venues
Vid Name 1 2 3 Floriana Granaries Villa Arrigo MFCC Pub_id Prv_id 1 1 2
Table: Public Venues

Pub_id 1
Table: Private Venues

Prv_id Fee 1 2 500 600
Page 24 of 31
Entity Relationship Modelling - Exclusive Relationship Arc
Exclusive Relationship Arc There can be situations where an entity is either related to one entity or to another but not both. Whenever a selection needs to be done between relationships, an exclusive relationship arc is created. Recall the subtypes scenario: VENUE # Id * Name PUBLIC VENUE PRIVATE VENUE * Fee The above entity with respective subtypes can, in principal, be represented as follows:
VENUE # Id * Name
is is
PUBLIC VENUE # Id * Name
is is
PRIVATE VENUE # Id * Name * Fee
Each VENUE must either be exactly one PUBLIC VENUE or PRIVATE VENUE. ! Each PUBLIC VENUE must be exactly one VENUE. ! Each PRIVATE VENUE must be exactly one VENUE. N.B. Even though both rules of subtypes can be modelled as shown above they should always be represented as subtypes rather than using the arc. N.B. If other relationships cross the exclusive relationship arc but are not affected by the exclusivity then they will not be circled.
Page 25 of 31
Consider: A database is required to store a list of runways. A runway might be owned by an airport, such as Malta International Airport. An airport would own at least one runway but may own more. A runway may instead be owned by a club, such as a Motor Racing Club that owns the runway in al-Far, or the Remote Control Club that owns the runway in Ta Qali. Lets say that a law in our country imposes that a club is allowed to own only one runway. Lets also say that no runway may be abandoned. N.B. We cannot use subtypes since a RUNWAY is not an AIRPORT, nor is it a CLUB. Also an airport may have more than one runway whilst a club may have only one runway. Therefore the following is wrong.
RUNWAY AIRPORT CLUB
This scenario therefore cannot be resolved by using subtypes. But we need the mutually exclusive rule. Therefore we use the exclusive relationship arc.
Solution:
RUNWAY
AIRPORT
CLUB
Page 26 of 31
TARGET
SOURCE
SOURCE
Rules of the exclusive relationship arc The following rules need to be applied when drawing an exclusive relationship arc: 1. A relationship arc may be applied to only one entity, called the target entity. 2. The relationship arc must be applied to a minimum number of two relationships. 3. The target entity will contain the foreign keys of the relationships affected by the arc. 4. The optionality of the relationships affected by the arc must be the same from the perspective of the target entity. 5. The optionality of the relationships affected by the arc may be different from the perspectives of the source entities. 6. The relationships affect by the arc may be have a different cardinality (oneto-one, one-to-many). Drawing an exclusive relationship arc To design an exclusive relationship arc the following steps need to be taken: 1. Determine the owner of the relationship arc. 2. Draw an arc across the relationships to be affect and around the entity that owns the arc. 3. Circle the crossed relationships that are to be affected.
Implementing an exclusive relationship arc To implement an exclusive relationship arc the following steps need to be done: 1. Create a foreign key for each relationship affected by the arc. The foreign keys must be placed in the entity to which the arc belongs to. 2. Implement a constraint that allows only one foreign key value not to be null.
Page 27 of 31
Entity Relationship Modelling - Non-Transferability of Relationships
Non-Transferability of Relationships
In certain situations once a relationship is set it can never change. We call this the non-transferability of a relationship. E.g.: ERD: BOOK # Id * Name
written by the author of
PERSON # Id * Name * Surname
Perspectives: Each BOOK must be written by exactly one PERSON. Each PERSON may be the author of one or more BOOKs.
Drawing of Non-Transferability When drawing the non-transferability of a relationship the following rules need to be respected: 1. The diamond symbol should be on the perspective where the foreign key will be implemented. 2. The non-transferability symbol should be displayed only once per relationship provided that any many-to-many relationships have been resolved. Implementation of Non-Transferability When implementing the non-transferability of a relationship a constraint is applied to the foreign key which does not allow the values to be updated.
Page 28 of 31
Entity Relationship Modelling - Notes
Part 04 - Notes
_________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________
Page 29 of 31
Entity Relationship Modelling - Notes
_________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________ _________________________________________________________________________
Page 30 of 31
Entity Relationship Modelling - Feedback and Queries
Part 04 Feedback and Queries

Contact Details
In case you need to query about this report or would like to provide feedback you can use the following contact details:
Name: ! E-Mail:! LinkedIn:!
Frankie Inguanez [email protected] http://mt.linkedin.com/in/frankieinguanez
Page 31 of 31

Barkers Erd Notation

Uploaded by

Copyright:

Available Formats

Barkers Erd Notation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Barkers Erd Notation

Uploaded by

Copyright:

Available Formats

Entity Relationship Modelling

Entity Relationship Modelling

Non-Transferability of Relationships ..................................................................................28

Frankie Inguanez - 2012

Entity Relationship Modelling

Frankie Inguanez - 2012

Entity Relationship Modelling - Introduction

Use of this document in commercial projects is at your own risk.

Scope of this document

Purpose of this document

Frankie Inguanez - 2012

Entity Relationship Modelling - ERD Notes

Entity Relationship Diagrams

General Rules of ERDs

Frankie Inguanez - 2012

Entity Relationship Modelling - ERD Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

First Perspective / A Perspective: Each A must label a one or more Bs

Second Perspective / B Perspective: Each B may label b exactly one A.

E.g.: PERSON own

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

LEAGUE # Id * Name * Year be won by be the winner of

PLAYER # Id * Name # Id * Name * Surname

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Maximum A -> B 1 B -> A 1

A -> B 1 B -> A 1 A -> B 1 B -> A 1

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

B -> A 0 A -> B 0 B -> A 1 A -> B 1 B -> A 1

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - Drawing Concepts

Frankie Inguanez - 2012

Entity Relationship Modelling - UID Bar

Entity Relationship Modelling - Recursive Relationships

EMPLOYEE # Id * Name manage

Entity Relationship Modelling - Redundant Relationships

PERSON # Id * Name * Surname

Frankie Inguanez - 2012

Entity Relationship Modelling - UID Attributes

N.B. Primary keys are underlined.

Frankie Inguanez - 2012

Entity Relationship Modelling - UID Attributes

Frankie Inguanez - 2012

Entity Relationship Modelling - UID Attributes

HOTEL # Id * Name have belong to

FLOOR have # Number located on

Frankie Inguanez - 2012