FIS 1311 - Describing Information Systems

Describing Information Systems: Entity Relationship Diagrams

Required Resources:

Wikipedia: Entity Relationship Model - http://en.wikipedia.org/wiki/Entity_relationship
Systems Analysis & Design: Developing Entity Relationship Diagrams - http://infocom.cqu.edu.au/Courses/spr2000/95169/Extra_Examples/ERD.htm
Review Presentation (.ppt)

Outline:

Entity Relationship Diagram
ERD Example

Entity Relationship Diagrams:

The Entity-relationship diagram (ERD) is a graphical notation for high-level descriptions of conceptual data models --especially for relational database systems. Like UML use case diagrams, these ERDs are typically used in the first, "requirements analysis" stage of information-system design. It is used, for example, to describe information needs and/or the type of information that is to be stored in a relational database to address these needs. At the same time, it can be used to describe any ontology (i.e. an overview and classification of used terms and their relationships) or for a certain universe of discourse (i.e. area of interest). (Adapted from Wikipedia: Entity Relationship Model)

Entity: an object or concept about which you want to store information. Represents a category or example, (e.g. a person or a project) rather than a specific instance of that category (e.g. Michel, Magda, Manhattan project). Entities can be thought of (roughly) as nouns.

Attribute: the properties or characteristics of an entity (e.g. a person has a name [usually first and last] and a phone number; a project usually has a name, duration and budget).
There are two specific types of attributes: key and multi-value attributes.

Key Attribute: an attribute that has the same characteristics as a primary key: it is unique, cannot be empty or null, and does not change (e.g. a person's Social Insurance Number). Not every entity will have a key attribute.

Multi-valued Attribute: can have more than one value. For example, an person entity can have multiple phone numbers.

Relationship: A relationship captures how two or more entities are related to one another. Or how two entities share information in the database structure. Relationships can be thought of (roughly) as verbs. (Relationships are combined with a line, which is used to indicate relationship sub-types.)

one-to-one relationship

one-to-one or more relationship: the arrow points to the entity where there may be "one-or-more")

no diagram Associative Entity: An intermediate entity used to link together two entities in a "many-to-many" relationship, using two separate "one to one or more relationships." It is similar to a junction table (see week 3, Data Storage Devices), and is illustrated in the ERD example, below.

ERD Example

Model the entities, relationships and attributes in the phrase "Dogs sometimes bite people."

Note the nouns (possible entities) and verbs (possible relations): Dogs sometimes bite people.

The entities and the relation can be diagrammed as shown in the centre of the figure, below.

Think of attributes of each entity that are useful for data management purposes, and that may be relevant to the scenario described in the initial sentence. Especially important are attributes can be used as key attributes.

Note that the sentence speaks of dogs in the plural. The relationship implied by "bites" is actually many to many: many (or some) dogs bite (many) people.

This type of relationship is constructed using a type of intermediate entity, or what is called an associative entity. It is placed in the middle of the relationship. It relates to each of the pre-existing entities (dog, people) through two separate relationships (or arrows).

Note: As in the case of UML use cases, you will notice slight variations on notation and rules for entity relationship diagrams. The subset of these rules and notation provided here have been created as a way for eliminating this ambiguity.

	Entity: an object or concept about which you want to store information. Represents a category or example, (e.g. a person or a project) rather than a specific instance of that category (e.g. Michel, Magda, Manhattan project). Entities can be thought of (roughly) as nouns.

	Attribute: the properties or characteristics of an entity (e.g. a person has a name [usually first and last] and a phone number; a project usually has a name, duration and budget). There are two specific types of attributes: key and multi-value attributes.
		Key Attribute: an attribute that has the same characteristics as a primary key: it is unique, cannot be empty or null, and does not change (e.g. a person's Social Insurance Number). Not every entity will have a key attribute.
		Multi-valued Attribute: can have more than one value. For example, an person entity can have multiple phone numbers.
	Relationship: A relationship captures how two or more entities are related to one another. Or how two entities share information in the database structure. Relationships can be thought of (roughly) as verbs. (Relationships are combined with a line, which is used to indicate relationship sub-types.)
		one-to-one relationship
		one-to-one or more relationship: the arrow points to the entity where there may be "one-or-more")
no diagram		Associative Entity: An intermediate entity used to link together two entities in a "many-to-many" relationship, using two separate "one to one or more relationships." It is similar to a junction table (see week 3, Data Storage Devices), and is illustrated in the ERD example, below.