44220: database design & implementation conceptual data modelling ian perry room: c41c tel ext.:...
Post on 03-Jan-2016
221 Views
Preview:
TRANSCRIPT
44220: Database Design & Implementation
Conceptual Data Modelling
Ian PerryRoom: C41C Tel Ext.: 7287
E-mail: I.P.Perry@hull.ac.uk
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)
Ian Perry Slide 344220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 444220: Database Design & Implementation: Conceptual Data Modelling
‘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!
Ian Perry Slide 544220: Database Design & Implementation: Conceptual Data Modelling
‘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.
Ian Perry Slide 644220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 744220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 844220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 944220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 1044220: Database Design & Implementation: Conceptual Data Modelling
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
Ian Perry Slide 1144220: Database Design & Implementation: Conceptual Data Modelling
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
Ian Perry Slide 1244220: Database Design & Implementation: Conceptual Data Modelling
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)
Ian Perry Slide 1344220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 1444220: Database Design & Implementation: Conceptual Data Modelling
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
Ian Perry Slide 1544220: Database Design & Implementation: Conceptual Data Modelling
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
Ian Perry Slide 1644220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 1744220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 1844220: Database Design & Implementation: Conceptual Data Modelling
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.
Ian Perry Slide 1944220: Database Design & Implementation: Conceptual Data Modelling
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!
top related