Information Systems Engineering Database Design Data Scenario ER Design Entity Relationship Model Relational DBMS Relational Schema ER Design After the requirements analysis in terms of data needs, a high level design method as the Entity- -Relationship model should be used 1 MIB - ESIN apm@feup 2 ER components represent the relevant data of a scenario, describing a concrete situation Entities are like nouns: the persons, places, things being modeled in the world of a concrete scenario Relationships are like verbs representing an action or possession (e.g. a doctor treats patients, or a clinic has medical specialties) Attributes are like adjectives that describe an entity (e.g. identification numbers, names, dates, phones, price, etc.) Entities Entities can have several instances, differing in their attribute values A collection of several instances of an entity, characterized by the same attributes, but with different values, n entity set The entity instances belonging to an entity set must be all different, meaning that they must differ in at least one attribute value If all entities have differences only on one or some of the attributes, that set constitutes a key Entity Set Example: Key title year length genre Attributes MIB - ESIN apm@feup 3 MIB - ESIN apm@feup 4
Attributes Attributes must be simple values Attributes should not be decomposable in simpler components The set of all possible values of an attribute is its domain The domain can be infinite We can indicate the domain (or type) after the attribute name in an entity title : string year : integer length : float genre : enumeration (scifi, drama, comedy, action) Relationships Relationships usually link two entity sets using a verb, say entity sets A and B Relationships between entity sets A and B are also sets of sequences of entities containing an entity from A and an entity from B say for instance the sequence (a 1, b 1 ) where a 1 A and b 1 B Relationships are usually represented by diamonds with its name inside it, and between the entities that they link Representation of a Relationship owns MIB - ESIN apm@feup 5 MIB - ESIN apm@feup 6 Multiplicity of relationships Multiplicity indicates the possible number of entities from entity sets A and B that the relationship connects If each member of A can be related to at most 1 member of B by a relationship R then we say that R is many-to-one from A to B. If R is both many-to-one from A to B and from B to A we say that R is one-to-one If R is not many-to-one in both directions then we say that it is many-to-many Example In this scenario we have related to their and the Studio that has produced it Also we know the President that commands each Studio acts in Presidents the many end owns Representation of multiplicity the one end produces commands MIB - ESIN apm@feup 7 MIB - ESIN apm@feup 8
Multiway Relationships A multiway relationship involves more than two entity sets Ternary or higher degree relationships are not so common as binary, but some times are convenient Example: In the world of movie making a Studio must celebrate a contract with to act in one of its contracts for Roles in a Relationship When an Entity Set appears more than once in a Relationship we say that it has more than one role in the Relationship For clarity those roles should be named sequel original Examples sequel contracts for actor studio producing studio MIB - ESIN apm@feup 9 MIB - ESIN apm@feup 10 Attributes and Relationships Attributes in a Relationship In the ER model, Relationships can have attributes Those attributes only make sense associated to each sequence (aka tuple) of entities belonging to the relationship Example: The ternary relationship (contract) of slide 9 needs to stipulate the actor salary Salaries may be different for the same actor to each movie, and the same studio pays differently to each actor, also varying from movie to movie contracts salary Attributes and Relationships Attributes from a Relationship as a new Entity It is never necessary to have Relationships with attributes (but it is clearer) The attributes of a Relationship can constitute a new Entity The Relationship must now involve the new Entity Salaries contracts MIB - ESIN apm@feup 11 MIB - ESIN apm@feup 12
Multiway and Binary Relationships Converting from multiway to binary Any multiway Relationship can be converted to a set of equivalent binary Relationships The multiway Relationship becomes a new Entity set containing as entities the elements of the Relationship New many-to-one Relationships are created between the new Entity set and the Entity sets already linked by the multiway Relationship signs makes Contracts Salaries stipulates mentions Weak Entities A weak entity depends or is subordinate to another entity and needs the other entity to be fully characterized The relationship between the dominant entity and the weak entity is called supporting relationship Weak entities and supporting relationships are represented with double borders To distinguish between weak entity instances we may need the dominant keys Every weak entity instance must be related to a dominant entity instance Genus name belongs Species name Ex: Dyospyros virginiana Pinus virginiana Gazella cuvieri Orestias cuvieri MIB - ESIN apm@feup 13 MIB - ESIN apm@feup 14 Referential Integrity Constraint Definition We say that an entity satisfies the referential integrity constraint, relative to a relationship, if every instance of the entity appears in the relationship We note this fact using a small vertical segment meaning that each member of the other entity is mandatorily related (to at least one member) to this entity If the relationship is not mandatory we can use a small circle to note it Subclasses Specifying subclasses Sometimes some entities in an Entity set should have special attributes in addition to the general ones and may belong to special Relationships that make sense only for them If in an Entity set we have some entities in these conditions we can define a subset of the Entity set called a subclass Subclasses are graphically depicted as an Entity set with its specific attributes, but using a special Relationship () represented by a triangle produce at least one optional attributes Cartoons cartoon attributes MIB - ESIN apm@feup 15 MIB - ESIN apm@feup 16
Subclasses ER Model Design Principles Example speaks in Cartoons acts in All instances of a subclass are also instances of the superclass title year length genre Murder Mysteries weapon Rules for good design Faithfulness The design and chosen elements (entities, attributes, relationships) must represent all the relevant facts in the data scenario Also the multiplicity of the relationships must be carefully determined to be the right ones Avoid redundancy Redundancy is dangerous. Not also occupies extra space in concrete implementations, but can conduct to inconsistencies as entities and sequences in relationships are added, updated and deleted Simplicity Avoid introducing more elements in the model than those absolutely necessary for its purpose MIB - ESIN apm@feup 17 MIB - ESIN apm@feup 18 ER Model Design Principles Rules for good design (continued) Choose the right Relationships Don t represent every possible relationship between your entities. Some of them can be deduced from the others (redundancy) Pick the right kind of element Many times we can choose between attributes and a new entity, or multiway relationships versus binary ones, or even relationship attributes and new entities Choose always the simplest faithful design that better adapts to your objectives Some Common Mistakes Fan trap Employees Companies Offices work operate Companies Although the 3 entities are connected with relationships we cannot answer the question which employees work in a certain office? Chasm trap Offices have operate Offices Salesperson sells have Employees Properties CORRECT To what office belongs this property? enlist CORRECT MIB - ESIN apm@feup 19 MIB - ESIN apm@feup 20