44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C41C Tel Ext.:...

44220: Database Design & Implementation

Conceptual Data Modelling

Ian PerryRoom: C41C Tel Ext.: 7287

E-mail: [email protected]

http://itsy.co.uk/ac/0708/sem2/44220_DDI/

Ian Perry Slide 244220: Database Design & Implementation: Conceptual Data Modelling

Remember the ‘Stack’

You MUST begin by developing a Conceptual Data Model.

Conceptual Overview of things that are perceived to be of ‘interest’ in the ‘real’ world.

Model of the Business System. (ER Model)

Logical Data elements & the relationships between those elements in a tabular form.

Model of Data Storage Theory (Db Schema)

Physical Actual data held in a database & the means to manipulate that data.

Physical Implementation (RDBMS)


Conceptual Data Model? A Conceptual Data Model is an abstraction

which reflects the requirements of a ‘real-world’ system, by definition of: Objects of Interest Semantics Constraints

Need a ‘language’ to explore & explain our view of a ‘real-world’ situation: Ideally this ‘language’ should be compromise

free and will ‘work’ using any Software & Hardware.

Useful choice is that of ER Modelling: Need to identify Entities, Attributes &

Relationships.


‘Facts’ about the ‘Real-World’ Customers place orders. Patients take medication. Lecturers teach students. Students attend lectures:

Some students attend all lectures. Some students attend some lectures. Some students attend no lectures!


‘Facts’ need to be Expressed An ER Model lets us do so in way that:

Encourages thorough Analysis. Can be applied to ALL Database

Theories. Is independent of Software & Hardware. Provides an effective means of

Communication. For an ER Model we must determine:

the Objects of Interest. their Characteristics. their Associations.


Entities/Attributes/Relationships

Entities - Objects of Interest (Nouns): Customer, Supplier, Order, Employee,

Stock, etc. Attributes - Characteristics

(Adjectives): Customer - Name, Address, etc. Stock - Description, Price, Quantity, etc.

Relationships - Associations (Verbs): Customer ‘places’ Order. Stock ‘supplied by’ Supplier.


Entities = Objects of Interest Must play a necessary role in the

business system: so, we must make decisions about what

to include and what to exclude. Each Entity MUST have name that is:

a noun; is singular; is succinct; and is meaningful.

Each Entity MUST be described by; one-or-more Attributes.


Attributes = Characteristics Attributes describe an Entity. Must have Meaningful Names:

NOT; Field 1, Field 2, etc. Should be Atomic:

NOT; Address, Invoice, etc. For example:

House No., Street, Town, County, Post Code, etc.

Invoice No., Customer ID, Invoice Date, etc.


Entities & Attributes Each Entity requires an Attribute

Identifier, which can be defined as: the minimum number of Attributes that,

when given value(s), uniquely identify one Entity Occurrence from another.

these are often called ‘key’ Attributes. Consequently:

it is mandatory that values exist for all of these ‘key’ Attributes.


Entities & Attributes (Example 1)

Entity

Attributes

Key Attribute

Invoice

1000214 Jan 20057 Jan 20052005_0003

100344 Jan 20052005_0002

1000211 Jan 20054 Jan 20052005_0001

CustomerIDPaymentDateInvoiceDateInvoiceNo


Entities & Attributes (Example 2)

Entity

Attributes

Key Attributes

ModuleName Level CourseCode StaffNoDatabase Design 1 ITB 234

Marketing 1 ITB 346

Marketing 2 ITB

Research Methods

IS Planning M 254

Module

2


Relationships = Associations A Relationship MAY OCCCUR;

between any TWO Entities. Each Relationship REPRESENTS;

the possible existence of an Association between TWO Entities.

Every Relationship SHOULD be described : by Degree (a quantitative association) by Type (a qualitative association)


Quantitative = Degree Identifies the number of Entity

Occurrences that might be on each side of a Relationship.

May be simple: one_to_one (1:1), e.g. Wife - Husband one_to_many (1:M), e.g. Lecturer - Student

May be complex: many_to_many (M:M), e.g. Product – Customer many_to_many (M:M), e.g. Lecturer – Student

MOST ‘real-world’ Relationships are M:M, however: Logical & Physical Data Models CAN NOT handle

such complex Relationships.


Qualitative = Type MUST be a succinct & meaningful

verb (or verb-phrase), e.g.: Wife is married to Husband

ALL Relationships are bi-directional, e.g.: Lecturer bores Student Student bored by Lecturer

Product bought by Customer Customer buys Product


Example Relationships (by Degree & Type)

Husband Wife is married to

One-to-One11

Lecturer Studentbores =>

One-to-Many1 M

<= bored by

Product Customerbought by =>

Many-to-ManyM M

<= buys


Decomposing Complexity You MUST simplify any complex ‘real-

world’ M:M Relationships that you discover, into 2 x 1:M Relationships: This results in the creation of an new ‘artificial’

linking Entity composed of the identifiers (i.e. the ‘key’ Attributes) from either side of the original Many-to-Many relationship.

ALWAYS attempt to simplify any complex (i.e. M:M) Relationships at the Conceptual Data Modelling stage: you will have to ‘solve’ these ‘problems’ when

you move on to the Logical Data Model.


An Example of Decomposition

CustomerKeyProductKey CustomerKey

ProductKey

Product Customerbought by =>

1 x Many-to-ManyM M

<= buys

Product Customer

2 x One-to-Many

Prod/Cust1M1 M

<= buysbought by =>

NB. The Relationship is still between the two ‘real-world’ Entities; the ‘artificial’ Entity is just there to solve a problem.


Conceptual Data Modelling Process

Identify ALL of the relevant Entities: must play a necessary role in the business

system. Identify those Attributes that adequately

describe each Entity: remember to choose ‘key’ attribute(s).

Identify the Relationships between Entities: determine the Degree of each Relationship. determine the Type of each Relationship. attempt to decompose any many-to-many

Relationships that you have identified.


This Week’s Workshop In this Workshop we will continue to explore

some of the design decisions you must make in order to begin to construct a Conceptual Data Model of the ‘real world’.

Working alone, or in a small team, consider the following ‘things’ that exist in the ‘real’ world. University, Bank, Sports Activity.

For each of the above; list the Entities, list likely Attributes that ‘describe’ each Entity, and identify Key Attribute(s).

Be prepared to contribute in the workshop!

44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C41C Tel Ext.:...

Documents

Transcript of 44220: Database Design & Implementation Conceptual Data Modelling Ian Perry Room: C41C Tel Ext.:...