Fundamentals/ICY: Databases 2010/11 WEEK 5 John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK

Reminder of Week 4

Mental Exercises for You uWhat about the Employments bridging type we introduced? uOne entity type can be existence-dependent on another without therefore being weak. Why?

New for Week 5

Entity Relationship (ER) Model(s) and Diagrams

Rob, Coronel & Crockett Database Systems: Design, Implementation, and Management, (2008) Uses different diagrams from main book and my slides! More like the notation in the Additional Notes

The Entity Relationship Model uIntroduced by Chen in 1976 uMost widely used “conceptual model” of DBs. u“The ER model” : general meaning = just the idea of thinking of things as composed of entities, attributes and relationships. uWe also say that applying this approach in a particular case gives rise to an “ER model” of the specific environment of interest. uDiagrams based on the/a model are a widely accepted and adopted graphical approach to database design. / uThe/an ER model has nothing intrinsically to do with diagrams!!! Let alone any specific sort of diagram!!!

A Conceptual Model / uER model that provides high-level, manager/user- friendly view of the database uBasis for identification and description of main data objects and relationships, avoiding details

Entity Relationship Diagrams (ERDs) uAn ER model of an environment forms the basis of an ER diagram (ERD) or several ERDs. uThere are several markedly different styles of ERD, and for each main style there are several variants. l And the style in the module handouts will differ somewhat from that in the textbooks and these lectures uAn ERD depicts (some of) the ER model’s entity types, attributes and relationships, and (depending on the diagram style) varying amounts of other info such as connectivities, cardinalities, keys, weakness, …

Quick Flavour of Two Styles of Diagram

The Completed Tiny College ERD

Relationships: The Basic Chen ERD-let

Relationships: The Basic Crow’s Foot ERD-let

Caution uIn previous two diagrams, each relationship was mandatory in both directions. uBut saying “1:1”, “1:M” or “M:N” does not of itself imply mandatoriness in either direction. In particular, don’t be deceived by the “1” here – it’s not a minimum. uWe will see in a minute how to draw optional (non- mandatory) relationships.

A Model for Tiny College

1:1 Relationship Between PROFESSOR and DEPARTMENT (mandatory in both directions)

Tables for that 1:1 Relationship

1:M Relationship Between PAINTER and PAINTING (mandatory in both directions)

Tables for that 1:M Relationship

The M:N Relationship uCan be implemented by breaking it up to produce two 1:M relationships uCan avoid problems inherent to M:N relationship by creating a composite entity or bridge entity

M:N Relationship between STUDENT and CLASS (both ways mandatory): preliminary ERD (conceptual level)

Conversion to Two 1:M Relationships (towards “logical” level)

A Bridge (or Composite) Entity Type uIts table is called a linking table (or bridging table) uIts primary key is composed of the primary keys of each of the entity types to be connected uThose keys are also foreign keys in the bridge type uLinking table may contain multiple occurrences of each foreign key value uMay also contain additional attributes that play no role in the bridging as such

Direct Impln of M:N Relationship between STUDENT and CLASS

Converting the M:N Relationship into Two 1:M Relationships

Connectivity and Cardinality in an ERD

Relationship Participation uOptional [in a particular direction, X to Y]: l an X entity occurrence does not require a corresponding Y entity occurrence l i.e. the minimum number of Ys per X is 0 uMandatory [in a particular direction, X to Y]: l an X entity occurrence requires a corresponding Y entity occurrence l i.e. the minimum number of Ys per X is 1 or more

Drawing Optionality NOTE: the dashing of the line is NOT because of the optionality, but because of weakness

1:M Relationship, Mandatory Both Ways NOTE: error in top diagram – what??

An M:N Case NOTE: error in top diagram – what??

The Chen Representation of the Invoicing Problem

The Crow’s Foot Representation of the Invoicing Problem

The Attributes of the STUDENT Entity

Derived Attributes uAttribute whose value may be calculated (derived) from other attributes uNeed not be physically stored within the database uCan be derived by using an algorithm

Depiction of a Derived Attribute

Attributes

Weak Entity Types in ERDs

Weak Entity Types uWeak entity type W meets two conditions (as clarified by J.A.B.): l Existence-dependent on some other entity type X via some relationship R: An entity of type W cannot exist as such without being in relationship R to an entity of type X l Has primary key that is partially or totally derived from the primary key of X uDatabase designer usually determines whether an entity can be described as weak based on the business rules

A Weak Entity in an ERD

A Weak (Non-Identifying) Relationship

Multivalued Attributes in ERMs and ERDs (now with more explanation)

A Multivalued Attribute in an Entity: CAR_COLOR gives multiple colours

Multivalued Attributes u“You should not implement them in the relational DBMS” [rather, you should re-represent them in a special way – J.A.B.] uOne possibility: Use a variable-length string for the attribute, and list all the values within the string. Disadvantage: little support supplied by the DBMS – insertions and deletion require special extra programming. Similarly if calculations are needed on the individual values.

Multivalued Attributes, contd uAnother possibility: Within original entity type, split the attribute into several different attributes corresponding to different natural components of the entity. (See next slide.)

Splitting the Multivalued Attribute into New Naturally Namable Attributes

Multivalued Attributes, contd uDisadvantages: l The attribute may need to be split differently for different entities. l The attribute may not have naturally namable aspects at all. E.g., imagine blotches of colour in random places on a car.

Multivalued Attribute Problems, contd uAnother possibility: Within original entity type, split the attribute into several different attributes not corresponding to specific components of the entity. E.g., have attributes called Colour1, Colour2, …, Colour6. l Advantage: copes with the no-identifiable-components problem and the different-split problems. NB: also allows repetition of colours. l Disadvantages: Have to set aside enough columns to accommodate the conceivable max, but if this max not often approached then have a lot of wasted space. Searching for a colour, or doing insertions and deletions, can be very cumbersome.

Multivalued Attributes, contd uOften Better: Replace the attribute by a new 1:M relationship to a new entity type holding the original attribute’s data. If the components of the original attribute are conceptually distinguishable in a natural way, the new entity can have an attribute whose values identify those components.

So “trim colour” is one of the components of the original multivalued attribute

Multivalued Attributes, contd uIf the original multivalued attribute does not have namable components, leave out the component-naming attribute (COL_SECTION in diagram). l But NB: the PK would then need to include, in our example, the colour. So we can’t have repetitions of colours. uOr include an integer-valued attribute to allow the values to be distinguished. l The PK now includes that attribute. Now we can have repetitions of colours.