1. IS6125/IS6145 Database Analysis and Design Lecture 2: Conceptual Data Modelling 1: The Foundational Concepts
Rob Gleasure

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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 …

9. 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

10. 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

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

12. 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

13. 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

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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Exercise: Draw the following attributes
A student has a unique student number, an 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?

23. Example solution