Slide 1

Modelling I1In this weeks lectures:An introduction to data modelling

The purpose of data modelling

Modelling data relationships2Some backgroundA database will contain a logically coherent collection of data with some inherent meaning[1]In this module we are dealing with modelling to support relational databases such as Access, MYSQL, Oracle In a relational database, data is stored in relations (tables) The purpose of the data model is to show how the data is related

3Why do it? The process model provides information about the processes you are dealing with to help you build the data model

The data model provides information about the data enabling you to get from this:

(student enrolment form) 4To this:

5Why do it? The data model includes the ER diagram but also includes other elements covered in later lectures

An ERD on its own is not a complete data model

6(First 2 sections of the student enrolment form)Student ref noAward detailsAward titleAward codeLevelHome facultyIntake monthAward completion datePersonal DetailsFamily nameForename(s)TitleGenderDOBPrevious Family name (if any0Work contact addressTerm time addressPost codeHome addressPostcodeTelMobile phonePostcodeTel Private email address

There are at least 84 possible items of information on the student enrolment form

Most of these items would need to be broken down further to store in a database

Data modelling is the tool that lets you order this information7Does it work? Yes but only if you do it properly

A correct data model will give you:A diagrammatic representation of the way in which entities are relatedData dictionary information about the entities and the attributes and the relationshipsProperly organised dataA basis for design

8Some key concepts: Data & Information10.41 is an item of data

The time is 10:41 is a piece of information

Data is raw, unstructured factsInformation is data organised to provide meaning

9Entities and AttributesAn entityIs something about which you wish to store informationSTUDENT is an entity

An attribute is information about an entitySTUDENT DOB is information about the entity STUDENT

It is better to talk about an occurrence of an entity. We have an entity STUDENT. We then store information about specific students Mr John Doe and Ms Jane Doe. Each of these is an occurrence of the entity STUDENTOne entity may have many occurrences of an entity you would expect this one table may have many rows; there are many students at the university10Entities and AttributesData modelling starts by identifying the entities

An entity is usually a noun Customer, Order, Delivery would be entities

You can use the process model as the starting point for identifying entities a store on the DFD holds information about something

11The DFD example used in Daves lecture include a data store

Since you want to store information about staff, reasonable that this will be an entity on the data model

Starting to create the data model

If the descriptions for the data flow have been done correctly, we will know what staff details meansAssume it covers:Name, Address, Age, Position12This could become an entity staff

How would you tell one member of staff from another?How useful is address?What is the problem with age?Get in the habit now of always putting data into atomic formLook at what the attributes are really describing13Suppose there isnt a process model? Why isnt there a process model?A good place to start is by identifying the nouns:A Student enrols on a Module taught by a Tutor The convention is that an entity is always described in the singular, and starts with a capitalWhat does Module mean? (if you have done a process model, you will already have the answer to this question)

14AN ASIDE

15Always state assumptionsGetting Started3 entities have been identified:STUDENTMODULETUTOR

Start by identifying the primary key for each entity

16What is a primary key (PK)? Uniquely identifies each occurrence of an entity; is not nullWhich means that:A primary key cannot be duplicated. You cannot have 2 Tutors identified by the same PKCannot be left blankIs essential - in a relational database, every occurrence of an entity must have a PK

17A PK for TutorLast Name?No, because the PK must be unique not only now but in the future. Module? OK as long as a tutor only teaches on one module but Tutors teach on many modulesModule details and tutors change from time to time The obvious answer is a Tutor_ID18PKMust uniquely identify the occurrence of the entityMust not be likely to change (another reason for not using Name)Does not usually contain meaningful data so will tend to be numeric or alphanumeric19Identifying RelationshipsPossible relationships are:1:M1:1Not allowed:M:M also written as N:MIn this system, a tutor may teach on many modules, but a module is only ever taught by 1 tutor20A 1:M Relationship

21What is a foreign key? Think of it as the primary key of another entity that you use to link two entities

22A 1:M Relationship

23PKFKAttributesOptionalMandatoryCardinalityProbably the most common mistake

24What happens if you do this?

Dealing with Many to Many RelationshipsMany students study many modulesA M:M or N:M relationship cannot be implemented in a relational databaseSince you cant change reality, you must change the data model25Finding the Missing Entity Whenever you have or appear to have a N:M relationship, look carefully at the entitiesMany students enrol on many modules1 student can enrol on 1 or more or no modulesA module can be studied by 1 or more or no studentsHidden in this scenario is the idea of enrolment26Finding the Missing Entity

27Weak Entity A Weak (or Link or Intersection) entity depends for its existence on other entities.A student can choose whether to enrol or not, but an enrolment cannot exist without the studentParticipation is always mandatory on the Weak entity side28