IS6125 Database Analysis and Design Lecture 3: Conceptual Data Modelling 1: The Foundational Concepts Rob Gleasure

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 StructuringInterpretation

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_IDDept_IDYearCredits ………… ………… Department Dept_IDBldgHead ……… ………

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

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 AttributeCharacteristicsDepiction NameWritten beside circle TypeNumeric, alphabetic, etc.- DomainThe range of possible values ClassificationAtomic or compositeComposite are connected to other attributes CategorySingle or multi-valuedMulti-valued has two circles SourceStored or derivedDerived are dotted lines OptionalityOptional or mandatoryOptional are empty circles RoleKey or non-keyKey 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) Building Ground-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 |) Building Ground-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 BuildingHelp desk Has 1 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 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?