Upload
cathie101
View
2.385
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
1
Database Design E-R
2
ENTITY RELATIONSHIP ANALYSIS
In this area of the course we concentrate an another modelling technique called Entity Relationship Modelling (ERM or ER).
The first stage of this process will look at the following: ER Data Model and Notation Strong Entities Discovering Entities, Attributes Identifying Entities Discovering Relationships
3
Critique of FD Analysis
We originally concentrated on the modelling technique called Functional Dependency Diagrams. They have limitations as follows:
Disadvantages of FDD Does not represents real world objects, but
only data; Cannot represent MVDs or specialization; Cannot represent multiple relationships
without artificial splitting of attributes; Entities fragmented during analysis;
4
Conceptual Data Analysis
By using the ER technique we have the following advantages:
Data Analysis from the User's Point of View Models the Real World Independent of Technology Able to be validated in user terms
5
Entity Relationship Data Model Features
The real value of using this type of modelling is that it considers the design in context to the environment where it comes from. We have these Entities that have there own identifying attributes, real things and real people. They can be observed in the environment. ERM has the following features:
Populations of Real World objects represented by Entities Objects have Natural Identity Entities have Attributes which have values Entities related by Relationships Constraints Subtypes
6
Occurrences versus Entities
56 28Jack Ackov Jill Hill
Entity OccurrencesEntity InstancesObjects
Let’s consider these two instances. Here we have both Jack and Jill, aged 56 and 23 respectively. By themselves they exist as people in their environment. In this case we consider them to be two customers. If we wish to model them and all of the possible customers that we have we need to create an Entity Class for all possibilities.
7
Occurrences versus Entities
56 28Jack Ackov Jill Hill
CUSTOMER
Customer# CustName
Customer# CustName
5628
Jack AckovJill Hill
CUSTOMER(Customer#, CustName)
Entity OccurrencesEntity InstancesObjectsThese are the Tuples of the table below
Entity ClassesEntity TypesEntity SetsThis will convert to the schema below with Customer# being the Primary Key
8
5628
Jack AckovJill Hill
BikeCup of Tea Pussy Cat23 156 234150 25
3
12
41
Here we have Jack and Jill placing orders for particular items of stock. They appear to order different amounts of each. For instance Jack orders 3 bikes. Each item being ordered also has a Stock#, Price and Description. These are individual instances of the process so we need to be able to represent any possibility of this in our model. See how we do this on the next page.
9
5628
Jack AckovJill Hill
CUSTOMER
Customer# CustName
ITEM
Stock#
ORDERS
DescPrice
Quantity
Bike Cup of Tea Pussy Cat23 156 234150 25
3
124
1
10
Customer# CustName
5628
Jack AckovJill Hill
CUSTOMER(Customer#, CustName)
Customer#
56562828
ORDERS(Customer#, Stock#, Quantity)
Stock# Desc
23156234
BikeCup of TeaPussy Cat
ITEM(Stock#, Price, Desc)Price
50125
Stock#
23156156234
Quantity
31241
Occurrences to Entities to Schemas
11
ENTITIES
Entities are classes of objects about which we wish to store information. Examples are:
People: Employees, Customers, Students,..... Places: Offices, Cities, Routes, Warehouses,... Things: Equipment, Products, Vehicles, Parts,.... Organizations: Suppliers, Teams, Agencies, Depts,... Concepts: Projects, Orders, Complaints, Accounts,...... Events: Meetings, Appointments.
STRONG
WEAK
12
STRONG ENTITIES
An entity is Existence Independent if an instance can exist in isolation. For example, CUSTOMER is existence independent of
ORDER, but ORDER is existence dependent on CUSTOMER. The ORDER is by a particular customer for a/many particular item(s)
An entity is identified if each instance can be uniquely distinguished by its attributes (or relationships). For example, CUSTOMER is identified by Customer#,
PERSON is identified by Name+Address+DoB, ORDER is identified by Customer#+Date+Time.
13
An entity is STRONG if it can be identified by its (own) immediate attributes. Otherwise it is weak. For example, CUSTOMER and PERSON are strong entities,
but ORDER is weak because it requires an attribute of another entity to identify it. ORDER would be strong if it had an Order#.
Existence independent entities are always strong.
STRONG ENTITIES
14
The Method: How to Develop the ERM
Step1: Search for Strong Entities and Attributes Step2. Attach attributes and identify strong entities. Step3. Search for relationships. Step4. Determine constraints. Step5. Attach remaining attributes to entities and relationships.
Step6. Expand multivalued attributes, and relationship attributes. Represent attributed relationships and/or multivalued
attributes in a Functional Dependency Diagram.
Step7. Identify weak entities. Step8. Iterate steps 4,5,6,7,8 until no further expansion is possible. Step9. Look for generalization and specialization; Analyze Cycles;
Convert domain-sharing attributes to entities.
15
Narrative&
Forms
1Search for
strong entitiesand attributes
Entities
Attributes
3Search for
relationships
Relationships
2Identifystrongentities
Strong entities
4 & 5Determine
constraints andattach attributes
Entity-RelationshipDiagram6
Expand attributedrelationships and/or
multivalued attributes
Weak Entities
7Identify
weak entitiesIdentified
weak entities
6’Represent attributed
relationships and/or multivalued attributesas Functional Dependencies
FunctionalDependency
Diagrams
The Method
The Method
16
Step1: Search for Strong Entities and Attributes
1 Entities relevant nouns many instances have properties (attributes or relationships) identifiable by properties
2 Strong Entities independent existence identifiable by own single-valued attributes
•3 Attributes–printable names, measurements–domain of values–no properties–dependent existence
17
Narrative
A worked example finding strong Entities
A customer is identified by a customer#. A customer
has a name and an address. A customer may order
quantities of many items. An item may be ordered by many customers. An item is identified by a stock#. An item has a description and a price. A stock item may have many colours. Any
item ordered by a customer on the same day is part of
the same order
Here we have a scenario. Try to firstly identify all of the strong entities followed and all of the attributes. Can you also identify a weak entity? Are there any attributes that you have missed?
18
Worked Example Continued
Let us take and place it around the nouns. These lead us to what we will consider to be the strong entities. If we then place the around items that we think would be the attributes, we can see if if any of the identified Entities are strong. You will notice that the item has a description, price, colour and stock # and a customer has a customer number, name, and address. These a Existence Independent Entities, and hence they must be strong.
Narrative
A customer is identified by a customer#. A
customer has a name and an address. A
customer may order quantities of many
items. An item may be ordered by many
customers. An item is identified by a stock#.
An item has a description and a
price. A stock item may have many
colours. Any item ordered by a
customer on the same day is part of the
same order
19
Conceptual Schema
CUSTOMER ITEM
Description
Address
Price
Quantity
Customer#
Stock#
Customer Name
Date
ORDERColour
Worked Example Continued
We have our Entities and the attributes displayed before us. Customer and Item are strong entities as they are Existence Independent. What about Order?
Order cannot be identified completely by any of its own attributes. It is dependent on the attributes of the other 2 entities to be identified. An order is made up of a customer ordering an item. We need the customer# and the item# to identify the order
20
Step2. Identify Strong Entities.
Conceptual Schema
ITEMCUSTOMER
Customer#Price
AddressCustName
Stock#
Desc
Colour
DateQty
Both Customer and Item have what we call a Natural Identity
We now attach the attributes that belong to each of the Strong Entities. Notice that there are some left that belong to neither Customer or Item. We will look at this later.
21
Another Example of the Difference Between Weak and
Strong Entities
Here is another example of a common occurrence that demonstrates the difference between a strong entity and a weak entity
A strong entity is identified by its own attributes. Bidders make purchases of goods at the auction.
BIDDER and a GOOD have independent existence, hence are strong, but PURCHASE requires attributes of BIDDER and GOOD. The Purchase is the identified by the Bibbers name and the Goods description. These are 2 attributes that belong to both the Bidder and the Good respectively.
22
Additional Rules for Entities
For an Entity to exist we have the following additional rules: There must be more than one instance of an entity.
The company provides superannuation for its workers. Here there is only one instance of COMPANY so it is
not a valid entity.We do not model anything that only has one instance
Each instance of an entity must be potentially distinguishable by its properties. Members send five dollars to the association.
A dollar does not normally have distinguishing attributes.
23
Step3. Search for Relationships.
We can now identify Relationships that have the following properties: Relationships
Have associate entities Are relevant
must be worth recording Can be"structural" verbs in the narrative
persistent, rather than transient relationships Can be "abstract" nouns in the narrative
nonmaterial connections, eg. Enrolment Can be verbalizable in the narrative
eg. Student EnrolledIn Unit Have 2 (binary)or more associated entities.(3-Ternary, up to n-ary
for n associated entities)
24
Relationships:
A relationship must be relevant. It should indicate a structural, persistent (extending over time) association between entities. Students enrol in units selected from the
handbook. A relationship should not usually indicate a
procedural event (one that occurs momentarily, then is forgotten.). Students read about units selected from
the handbook.
25
Relationships and the Worked Example.
Conceptual Schema
ITEMCUSTOMER
Customer#Price
AddressCustName
Stock#
Desc
Colour
DateQty
ORDERS
We can now deal with the order. The order is a relationship between the Customer and the Item. It is for a set Quantity on a given Date.
26
Entity Relationship Analysis 2
We will now concentrate on the following areas of good ERM Cardinality and Participation Constraints Expanding to Weak Entities Identifying Weak Entities Derived Attributes and Relationships Ternary Relationships
27
These are Steps 4,5 & 6 from the Original Diagram
Relationships
Strong entities
4 & 5Determine
constraints andattach attributes
Entity-RelationshipDiagram
6Expand attributed
relationships, domain sharing &
multivalued attributes
Weak Entities
7Identify
weak entities
Identifiedweak
entities
Unattched AttributesUnidentifiedweak
entities
28
Step4. Determine constraints: Cardinality(How many participate
CUSTOMER ITEMORDERS
To complete this we “fix a single instance at one end and ask how many (one or many) are involved at the other end”.Look at the relationship where the Customer Orders an Item. Consider a single Customer. Can they order many items at the one time? Yes We have seen this. So we position a crows foot (<) at the point where the line touches the Entity Item. We then ask if an Item can be ordered by many Customers? Yes So agin we place a crows foot at the Customers end.
From left to right-A Cust can order many Items
From right to left- An Item can be ordered by many Cust
29
Step4. Determine constraints: Cardinality.
CUSTOMER
Again to complete this task we “Fix a single instance at one end and ask how many (one or many) are involved at the other end”. All of the Customers live in a City. A Customer can only live in one City(unless they are politicians) In this case we must place a single straight line (|) at the intersection of the relationship line and the Entity City. However, a city can have many Customers. We show this by placing crows foot (>) at the end near the Customer
CITY
LIVES IN
30
Step4. The Resulting ER with the Cardinality Constraints in Place
CUSTOMER ITEMORDERS
Many CUSTOMERs can ORDER an
ITEM.Many
ITEMs can be
ORDERed by a
CUSTOMER.
CITY
LIVES INMany CUSTOMERs can LIVE IN a
CITY.
A CUSTOMER can LIVE IN only one
CITY.
{Colour}
An ITEM can have
many Colours.
31
Step4.Determine constraints: Participation.
CUSTOMER ITEMORDERS
Again, we “Fix a single instance at one end and ask if any must (might or must) be involved at the other end”.We ask “Does the Customer have to order an Item? Well, some would say that they do not they are not Customers! But we know that we must be able to recognise our Customers even though at present they do not have an order with us. So, in this case they do not have to place an order. This is then not mandatory, and we show it by placing the O beside the cardinality constraint. An Item does not have to be on an order as well, so it also gets the O notation.
32
Step4.Determine constraints: Participation.
CUSTOMER
CITY
LIVES IN
This is also the case for the Customer living in the City. Does the customer have to live in the City? In this case Yes, as we class all areas as being within a City. Hence we place the “|” symbol beside the cardinality constraint next to the Entity City. The next one is difficult. Does a City have to have a Customer living in it. You might think No here, but are you prepared to record all of the cities in the world just to make sure? Common sense tells us that we have to make this mandatory so we only keep a record of the cities where our Customers live.
33
Step4. The Resulting ER with the Participation Constraints in Place
CUSTOMER ITEMORDERS
An ITEM might be ordered by a CUSTOMER.
A CUSTOMER might order a
ITEM.
CITY
LIVES IN A CITY must have a CUSTOMER
LIVing IN it.
A CUSTOMER must LIVE IN a
CITY.
34
Step4. Determine constraints: Validation by Population.
CUSTOMER ITEMORDERS
CITY
LIVES IN
Cust#
Stock#
CityName
{Colour}An important method of evaluating the proposed model is to populate with instances that demonstrate that the constraints that you have identified will work.
35
Step4. Tables Created to Validate
CUSTOMER ITEMORDERS
CITY
LIVES IN
Cust# Stock#122312
13
77778899
CityName Cust#AyrAyr
Tully
122313
Cust#
Stock#
CityName
{Colour}
ColourStock#PinkBlue
7777
36
Step5. Attach remaining attributes to entities and
relationships.In the previous lectures we looked at a worked problem with a Customer ordering an Item. Here we were able to identify Entities from the narration. Next we also listed the attributes which helped us identify the Strong Entities. We noticed that there were some Attributes, Qty and Date, left that could not be attached to any of the strong entities. They, in fact, belong to the Relationship that was associated with the two Entities.
ITEMCUSTOMERCustomer#
Price
AddressCustName
Stock#
Desc
Colour
DateQty
ORDERS
37
Step5. Attach remaining attributes to entities and
relationships.
The quantity attribute cannot be attached to the Customer, as the Customer will order different quantities of various items at any time. It cannot also be attached to the Item. It must therefore be attached to the relationship between them, being the order. This is also the situation for the Date that the order was placed.
38
Step5. Attach remaining attributes to entities and
relationships.
Conceptual Schema
ITEMCUSTOMER
Customer#Price
AddressCustName
Stock#
Desc
{Colour}DateQty
ORDERS
39
Step6.Expand multi-valued attributes, domain sharing attributes and binary
relationship attributes.
Once we have identified the Strong Entities, Relationships and attached all Attributes to either the Strong Entities or Relationships, we are required to expand the diagram as much as possible to permit us to complete the process. This requires us to move in 2 directions. We must first look at all of the binary relationships to see what the cardinality constraints are between them. If they are “many-to-many” they must be carefully considered and expanded where appropriate.
We then must look at what we call Multi-valued Attributes and Domain Sharing Attributes. The process is shown on the following diagram.
40
Step6 Entity-RelationshipDiagram
Expand relationships
with attributes
Dependent Entities
Many-to-many Relationships with Attributes
Multi-valued AttributesDomain Sharing Attributes
ExpandMulti-valued anddomain sharing
attributes
Characteristic EntitiesAssociative Entities
41
Conceptual Schema
ITEMCUSTOMER
Customer#
Price
AddressCustName
Stock#
Desc
{Colour}DateQty
ORDERS
Step6
In the worked example we have a Many-to-Many relationship with 2 attributes . When we have a Many-to-Many relationship with attached attributes we are required to create an Associative Entity that bridges the 2 Entities.
42
ITEMCUSTOMER
Customer#
Price
AddressCustName
Stock#
Desc
Date
Qty
ORDERMAKES FOR
Associative Entity
Step6
Between Customer and Item we create the Weak (Associative) Entity called Order. We have to redo the constraints. A customer can place many orders or none. An order can come from only one customer, and must be from a customer. An order is for many items and must be for at least one item, and an item can be on many orders but does not have to appear on an order. These have all been placed in the diagram shown below in their correct position.
43
ITEMCUSTOMER
Customer#
Price
AddressCustName
Stock#
Desc
Colour
Date
Qty
ORDER
COLOUR
MAKES FOR
HAS
Associative Entity
Characteristic Entity
Step6
We have also noticed that an item can come in many colours. This is a multi-valued attribute. We can show this in our extended diagram by having a relationship between the Item and the Colour, where colour is the only attribute of the entity. In this case we are also saying that the colour of the item is optional (IE natural if requested) and that the only colours to be recorded are those that are used.
44
Step6. Expand domain sharing attributes.
Managers supervise Workers. All employees are residents of a City. Employees who live in different cities from their managers get a special allowance.
MANAGER WORKERSUPERVISES
City City
Allowance
MANAGERSUPERVISES
CityName
Allowance
CITY
OF OF
WORKER
Characteristic Entity
45
Step7. Identify weak entities. Clarify the notion of instance.
Weak entities are often ambiguous and difficult to agree on. Attributes may be part of a key for a weak entity, but at least
one (one-must) relationship for identification is required. So when we convert this into a table it will require one of the PKs from the strong entities as part of its own composite PK.
Validation, not design. The purpose of identification is not to allocate a primary key,
but to validate the concept. We have to be able to justify the concept of the relationship in the real world.
Never invent keys. I know that it is tempting but you must reflect the business as it is.
46
Step7. Identify weak entities.
Conceptual Schema
ITEMCUSTOMER
Customer#
Price
AddressCustName
Stock#
Desc
Colour
Date
Qty
ORDER
COLOUR
MAKES
FOR
HAS
An ORDER is uniquely identified by the CUSTOMER and the Date.
47
Step7. Identify weak entities.
Conceptual Schema
ITEMCUSTOMER
Customer#
Price
AddressCustName
Stock#
Desc
Colour
Date
Qty
ORDER
COLOUR
MAKES
FOR
HAS
Here we still have the relationship between Order and Item that is many to many with attributes. We must expand this.
48
Step8. Iterate until no further expansion is possible.
Conceptual Schema
ITEM
CUSTOMER
Customer#
Price
Address
CustName
Stock#
Desc
Colour
Date
Qty
ORDER
COLOUR
MADE BY
FOR
HAS
ORDERLINEHAS
An ORDERLINE is identified by an ITEM on an ORDER.
An intersection entity is one that is identified by only by its relationships.
We introduce the weak entity orderline that for one item. It is fully dependent on the attributes of Order and Item to be identified
49
Example 2
Ted’s Computer courses is a company that offers a number of computer courses to client companies. A client may request several courses at one time.
A course has a course code, a description and a list of resources required.
Every course has a number of suitable instructors who are qualified to deliver it. An instructor has a name, address, and a telephone.
50
Example 2 cont.
A client company can request that a course begin on any date nominated. This course can be offered repeatedly on many dates.
The cost of the course is negotiated for each offering.
Ted’s Company requires the details of all the attendees.
When a course is offered an instructor is assigned from the list of instructors for that course.
51
Example 2 cont.3
Each course is offered as a series of usually 4 four hour sessions. Each session has a time and a place, again negotiated with the client.
Develop and E-R Diagram for the database application.
The next slide show you the forms filled out when a course is offered.
52
Course Specifications Form
53
Course Offering Form
54
Course Attendance Form
55
Solution 2 - 1
First get the major entities; Client Course Resources Instructors Attendees Session
56
Solution 2 - 2
Lets look at the client.
57
Solution 2 - 3
Lets look at the Course.
58
Solution 2 - 4
Look at the relationship between the client and the course.
59
Solution 2 - 5
The course entity has resources which is a multiple dependency value and is dealt with as follows.
60
Solution 2 - 6
Next step is the Cardinality Constraints of the three entities
61
Solution 2 - 7 Lets include the Instructor entity
62
Solution 2 - 8
For simplicity we are only going to add the attributes that are primary keys.
A client can order a course on a set date. Where does the date belong?
63
Solution 2 - 9
Lets look at the attendees entity. The attendees attend a course requested by a client. This is a binary relationship.
64
Solution 2 - 10
This binary relationship creates a weak entity called Course Offering.
65
Solution 2 - 11
There is one more entity that needs to be added, Sessions.
66
Solution 2 - 12 So far it looks like.
67
Solution 2 - 13
Now lets look at the many to many relationships that are still there.
68
Solution 2 - 14 Creating weak entities.
ResourcesUsed
Resources Qty
Course
teachingStaff
Consultant/Instructor
CourseId
name
CourseOffering
Attendances
Attendees
69
Solution 2 - 15
Now lets do the Network Diagram.
70
Solution 2 - 16
The database schema.