IS6125 Database Analysis and DesignLecture 3: Conceptual Data Modelling 1: The Foundational Concepts

Rob Gleasure

R.Gleasure@ucc.iewww.robgleasure.com

IS6125

Today’s session A note on the labs 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 notation lends itself towards more detail SSADM notation 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

Quantitative Data

Qualitative Data

Structuring Interpretation

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

Straight-forwardMapping

Straight-forwardMapping

database

Real World

Chen’s Proposal

Relational Data Model

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

The Essential Components of Conceptual Modelling? Once we have front-end user requirements and business strategy

inputs, conceptual modelling can be thought of in terms of 3 things

1. The context for the model (what it’s for)

2. The grammar for the model (what it’s made from)

3. The method that describes how to use the grammar (what it does)

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

The ER conceptual modelling framework is made up of these concepts, particularly entities, attributes, and relationships

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

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

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)

BuildingGround-floor

entrance

Is entered through

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

BuildingGround-floor

entrance

Is entered through

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

Building Help deskHas1 n

Strong and Weak Entity Types

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

Note that a weak entity can also have normal relationships

Partial key (means it can be combined with unique identifier from strong entity to identify weak entity)

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?