Further data modelling
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Further Data Modelling PowerPoint PPT Presentation


  • 33 Views
  • Uploaded on
  • Presentation posted in: General

Further Data Modelling. …and the effect of time. Plan. Introduction Structured Methods Data Flow Modelling Data Modelling Relational Data Analysis Further Systems Analysis Topics. Relationships. Remember… During Normalisation it is important to maintain the relationship between tables

Download Presentation

Further Data Modelling

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Further data modelling

Further Data Modelling

…and the effect of time


Further data modelling

Plan

  • Introduction

  • Structured Methods

    • Data Flow Modelling

    • Data Modelling

    • Relational Data Analysis

    • Further Systems Analysis Topics


Relationships

Relationships

  • Remember…

  • During Normalisation it is important to maintain the relationship between tables

  • These relationships are maintained by Compound Keys (1NF) and foreign keys (3NF)


Example 1 3nf

Student ID

Module Code

Grade

Module Code

Module Name

Student ID

Student Name

Course ID

Course ID

Course

Example 1 – 3NF

*

Compound Key

Foreign Key


Relationships1

Relationships

  • Relationships can now be drawn

  • They will be 1:M relationships

  • In general the many end “grabs” the foreign key

  • Compound Keys are also treated as foreign keys


Example 1 3nf1

Student ID

Module Code

Grade

Module Code

Module Name

Student ID

Student Name

Course ID

Course ID

Course

Example 1 – 3NF

*


Bottom up data model

Bottom Up Data Model

  • A normalised set of data can now be represented as an ERD

  • This will improve the communication aspect of Normalisation

  • It also helps to check the sanity of your normalisation


Example 2 3nf

Student ID

Name

Faculty

Student ID

Book ID

Return Date

Book ID

Title

Author

Example 2 - 3NF

Compound Key


Example 3 3nf

Customer ID

Customer Name

Address

Branch No*

Branch No

Branch Manager

Customer ID

Stock ID

Stock ID

Title

Format

Example 3 - 3NF

Compound Key

Foreign Key


Data modelling

Data Modelling

  • Entity Relationship Diagrams

    • Top down view of data modelling

    • Gives a good overview of system

    • Good communication tool

    • May lack accuracy

  • Normalisation

    • Bottom up view of data modelling

    • Difficult with large systems

    • Poor communication tool

    • Very accurate


Data modelling1

Data Modelling

  • A hybrid approach gives the benefits of

    • good communication

    • more formal approach

  • This is done as follows:

    • Develop an ERD of the system

    • Check each entity is in 3NF


Data modelling2

Data Modelling

  • Another approach to data modelling

    • Divides the system into user views

    • Develop an ERD for each

  • Each view is then combined into one whole system ERD

  • TopDog is a Good Example

  • Similar to a Use Case based approach

  • See also (Conolly and Begg, 2000)


Further data modelling1

Further Data Modelling

…and the effect of time


Entity life histories

Entity Life Histories

  • Remember that an entity occurrence is a instance of an entity

    • E.g. Each student is an occurrence of the entity student

  • Every Occurrence shares the same attributes

  • Every Occurrence is also effected by the same set of events


Events

Events

  • External Events

    • In Big John’s Store, receipt of a customer order caused the creation of an order, and maybe also a customer

  • Internal Events

    • In the Ticket Agency, the creation of a list of pre-purchase events causes an order to be placed.

  • Time Based

    • In CD Hotels a statement is produced every week.


Events1

Events

  • Events will affect entity occurrences in a number of ways

  • Create

    • A new student record is created when a student registers on a course.

  • Delete

    • A student record is deleted when a student leaves a course.

  • Update

    • A student successfully completes year 1 and so their year attributes is updated to Year 2.


Events2

Events

All entity occurrences will be created

…all will have some events update them during their lifetime

…and all will be deleted at some point

The description of these events and the order in which they occur is called an Entity Life History


Order of events

Order of Events

  • The Order in which events can occur is Governed by three primary structures:

    • Sequence

    • Selection

    • Iteration


Entity life history

Entity Life History

Entity

Creation

Life

Deletion

This diagram represents a sequence of events. This sequence is always read from left to right and is always carried out in the exact order shown.


Entity life history1

Entity Life History

Example: Student Record at Mulchester University

Student

Registration

Update Records

Student Leaves

Student records are created when a student registers, various changes occur during the life of a student entity. Student records are deleted when a student leaves.

This diagram represents a sequence of events. This sequence is always read from left to right and is always carried out in the exact order shown.


Sequence

Student

Registration

Updates

Student Leaves

3 Years after departure

Sequence

Mulchester realise that they might need to keep student record after a student has left – so they modify their system so that records are kept for 3 years after a student leaves.


Sequence1

Student

Registration

Updates

Course Completed

Student Leaves

3 Years after departure

Sequence

A student leaves after a course is complete.


Check the model

Check the Model!

  • This is only correct if a student always leaves after course completed

  • Sometime a student may leave before the course is finished

  • This means there are two conditions under which a student leaves

    • Either they complete the course and then leave OR they leave pre-maturely

  • This is an example of a Selection


Selection

Option2

O

………

Option n

O

Option 1

O

Selection

We show selection in ELHs as follows:

Option boxes have an “O” in the top right hand corner

The order is no longer important as we are only using one of the options


Selection1

Student

Registration

Updates

3 Years after departure

Student Leaves (Premature)

Student Leaves (C. Complete)

O

O

Selection

Note that we do not put the options on the same level as the original sequence. They are placed on the level below with an empty box marking their place in the sequence.

In general we do not mix logical structures at the same level on an ELH diagram


Updates

Updates

  • During the life of the entity, many updates to a student’s personal details occur (student’s move house etc.)

  • These updates can occur one or more times and there is no logical order to them

  • This is an example of an Iteration Structure and its general form is as follows:


Iteration

Iterated Event

*

Iteration

Iteration boxes have a “*” in the top right hand corner

The event can happen zero, one or many times


Iteration1

Student

Registration

3 Years after departure

Student Leaves (Premature)

Student Leaves (C. Complete)

O

O

Amend Personal Details

*

Iteration

Note that, again the iteration is not shown on the same level as the original sequence, but a placeholder is used to show its position in that sequence.


Adding more detail

Adding More Detail

  • The university realises that it also needs to amend a student’s module details throughout their time on the course

  • This will again be iterative as it can occur any number of times

  • These updates occur anytime between student registration and a student leaving


A solution

Student

Registration

3 Years after departure

Student Leaves (Premature)

Student Leaves (C. Complete)

O

O

Amend Personal Details

Amend Module Details

*

*

A Solution?

This is wrong!

It says that Module details will only be amended after all amendments to personal detail have been done.


A solution1

Student

Registration

3 Years after departure

Student Leaves (Premature)

Student Leaves (C. Complete)

Amend Personal Details

Amend Module Details

O

O

O

O

*

A Solution!

This is correct!

When an update occurs it could be to the personal details or it could be to the module details – it doesn’t matter which, and now the order in which these occur doesn’t matter.


A useful structure

Student Leaves (Premature)

Student Leaves (C. Complete)

Amend Personal Details

Amend Module Details

O

O

O

O

*

A Useful Structure

Student

Registration

3 Years after departure

This is a common structure for the life of an entity as it allows updates in any order


Further elh

Further ELH

  • There are other structures that can be applied

    • Quit/Resume (bit like GOTO)

    • Parallel Structures

    • State Indicators

  • State Diagrams are another way of showing the same thing


References

References

  • Lejk, M. and D. Deeks (2002) Systems Analysis Techniques, Addison Wesley 2002

  • Connolly, T. and C. Begg (2000) Database Solutions, Addison-Wesley, 2000


  • Login