IS6125/IS6145 Database Analysis and Design Lecture 2: Conceptual Data Modelling 1: The Foundational Concepts Rob Gleasure R.Gleasure@ucc.ie www.robgleasure.com

Course structure Or more specifically Week 1: Introduction Week 2: Foundational Concepts of Data Modelling Week 3: ER Modelling and Beyond the Presentation Layer Week 4: Fine-Granular Design-Specific ER Modelling Week 5: Enhanced Entity-Relationship (EER) Modelling Week 6: Practice with ERDs Week 7: In-Class Data Modelling Exam Week 8: Data Normalisation Week 9: NoSQL and Hadoop Week 10: Blockchain Week 11: The Data Value Map Week 12: Revision

IS6145 Today’s session Summary of last week A Little History What is Conceptual Modelling? The Essential Components of Conceptual Modelling A Conceptual Modelling Framework Entity-relationship Modelling Primitives Foundations of the entity-relationship modelling grammar An exercise

A note on the labs We are going to spend some time on Entity Relationship Diagrams (ERDs), a form of modelling and visualising data There are several different notations for ERDs, by far the most popular of which are Chen’s notation and SSADM notation Chen’s is more detailed and works for different data store types SSADM is popular among many popular design methodologies The basic concepts are the same, so we’re going to focus on Chen’s in lectures and SSADM in labs. This means You are ‘multilingual’ in ERD terms You can appreciate the differences

Last week’s session Key takeaways To make sense of large amounts of information, we need to apply some repeatable structure This structure can be applied during data input, or during retrieval As this structuring becomes more and more sophisticated, we can algorithms and structured queries to automate incredibly complex tasks The information that we get back still requires some interpretation Data Structuring Interpretation Instances

A Little History Early 1960s A Hierarchical Data Model dominated data storage Data was modelled only as it was stored in database, i.e. there was no purely conceptual motive Pointers were used in programming to move from one record to another Dept. Course Student

A Little History Early 1970s The Network Data Model emerged as a way of graphing data Data was still modelled only as it was stored in database and pointers were still used to navigate records. However the need for a hierarchical structure disappeared, meaning more elaborate queries were possible Dept. Course Student

A Little History Post 1970s The Relational Data Model is used (c/o Edgar Codd) Data was modelled as tables with rows and columns No need for pointers, now related items are identified through common data characteristics (columns) Student Stu_ID Dept_ID Year Credits … Department Dept_ID Bldg Head …

A Little History Post 1976 The Entity-Relationship Modelling Grammar is used (c/o Peter Chen) Focuses on conceptual modelling, rather than seeking to transition straight from requirements to a database structure Image from Data Modeling and Database Design, By Narayan Umanath, Richard Scamell

What is Conceptual Modelling? Before designing a database, we must understand the meaning of the data we wish to store This allows A cohesive high-level design to be maintained More front-end aware database design More business-strategy aware database design Technology-independent database design

A Conceptual Modelling Framework We’ll be working off the entity-relationship (ER) modelling framework Why? It works It’s popular It’s interesting

Entity-relationship Modelling Primitives The basic essence of the ER model is the ‘entity’ Any objects* about which we want to store information must be represented by some entity type Specific entities of that type are referred to as entity instances The information we store for an entity type is represented by attributes Individual pieces of data for an entity instance are called values

Entity-relationship Modelling Primitives Entity types can also have a generalised entity class The entity type jumper may have a parent entity class clothes Entity types can also be connected by relationships A jumper may have a relationship with some manufacturer and maybe a retail outlet The ER conceptual modelling framework is made up of these concepts, particularly entities, attributes, and relationships

ER Modelling Primitives Image from Data Modeling and Database Design, By Narayan Umanath, Richard Scamell

ER Modelling Primitives Attributes are depicted with circles connected to an entity, the format of which communicates some of that attribute’s basic characteristics Attribute Characteristics Depiction Name Written beside circle Type Numeric, alphabetic, etc. - Domain The range of possible values Classification Atomic or composite Composite are connected to other attributes Category Single or multi-valued Multi-valued has two circles Source Stored or derived Derived are dotted lines Optionality Optional or mandatory Optional are empty circles Role Key or non-key Key is underlined

ER Modelling Primitives Relationships between entities can vary in several ways The degree of a relationship is the number of entities involved a relationship A binary relationship A ternary relationship Image from Data Modeling and Database Design, By Narayan Umanath, Richard Scamell

ER Modelling Primitives Relationships between entities can vary in several ways The cardinality constraint of a relationship is the maximum number of each of the entities involved a relationship  Cardinalities can be 1-to-1 (often written 1:1) many-to-1 (often written n:1) Many-to-many (often written m:n) Is entered through Building Ground-floor entrance 1 n

ER Modelling Primitives Relationships between entities can vary in several ways The participation constraint of a relationship specifies whether or not, in order to exist, an entity must be related to another entity type through this relationship  Participation can be Optional/0+ (often written with a 0) Mandatory/1+ (often written with a |) Is entered through Building Ground-floor entrance

Strong and Weak Entity Types Strong entity types and weak entity types Not all entries in a database need to have unique identifies, e.g. a library may have multiple copies of the exact same book  These types of entities are called ‘weak’ entities This is communicated by a double line around the entity and the relationship upon which it depends Has Building Help desk 1 n

Strong and Weak Entity Types Image from Data Modeling and Database Design, By Narayan Umanath, Richard Scamell Partial key (means it can be combined with unique identifier from strong entity to identify weak entity) Note that a weak entity can also have normal relationships

Exercise: Draw the following relationships between entities A car has one registered owner but an owner may own many cars A musician has many fans and individuals may be fans of many different musicians A company is composed of many departments. Each department has several employees, but each employee works for only one department. Each department is managed by one employee, and each manager can manage one department at a time. A corporation may operate many factories, each of which is associated with a particular region. A region can house many factories. A factory employs many employees, but each of these employees is employed by only one factory.   An employee on a graduate programme must have one degree but may have many. A graduate programme can exist before it has any employees

Exercise: Draw the following attributes A student has a unique student number, an email address, a nationality, a picture, and at least one previous academic qualification recorded. Students may or may not also have provided dietary preferences. A module has a unique course code, one or more lecturers, and may or may not be active on Blackboard. The department responsible for the module is also available based on the course code. How might these relate to one another?

Example solution