Upload
xuan
View
33
Download
1
Embed Size (px)
DESCRIPTION
Fundamentals/ICY: Databases 2012/13 WEEK 5. John Barnden Professor of Artificial Intelligence School of Computer Science University of Birmingham, UK. Reminder of Week 4. 1:1 Connectivity between Tables. People. 1:1: that is, no more than one phone allowed per person, and vice versa. - PowerPoint PPT Presentation
Citation preview
Fundamentals/ICY: Databases2012/13
WEEK 5
John BarndenProfessor of Artificial Intelligence
School of Computer ScienceUniversity of Birmingham, UK
Reminder of Week 4
1:1 Connectivity between Tables
PERS-ID NAME PHONE EMPL ID AGE
9568876 Chopples 0121-414-3816 E22561 37
2544799 Blurp 01600-719975 E85704 21
1698674 Rumpel 07970-852657 E22561 88
5099235 Biggles E22561 29
PHONE TYPE STATUS
0121-414-3816 office OK
01600-719975 home FAULT
0121-440-5677 home OK
07970-852657 mobile UNPAID
Note: the representation is still asymmetric in that the People table mentions phones but not vice versa – symmetry would create extra redundancy.
NB: Biggles has no phone listed, and 0121-440-5677 has no person recorded. Suggests a possible reason for not combining such tables.
1:1: that is, no more than one phone allowed per person, and vice versa.
People
Phones
1:M Connectivity between Tables
PERS-ID NAME PHONE EMPL ID AGE
9568876 Chopples 0121-414-3816 E22561 37
2544799 Blurp 01600-719975 E85704 21
1698674 Rumpel 07970-852657 E22561 88
1800748 Dunston 0121-414-3886 E22561 29
EMPL ID EMPL NAME ADDRESS NUM EMPLS SECTOR
E48693 BT BT House, London, …
1,234,5678 Private TCOM
E85704 Monmouth
School
Hereford Rd, Monmouth, …
245 Private 2E
E22561 University of
Birmingham
Edgbaston Park Rd, ….
3023 Public HE
People
Organizations
More than one employee allowed per organization, but no more than one employer per person.
NOTE direction of use of the foreign key. Why so??
New for Week 5
M:N Connectivity between Tables IF we represent M:N connectivity in a similar way to
1:M, then we can expect that
in the People table: some people will have each several employers listed
or in the Organizations table: an organization will have several employees listed
or both.
This is a problem. Why?
M:N Connectivity between Tables, contd.
Because of this problem, an M:N relationship is usually broken up into two 1:M relationships.
This means introducing an extra “bridging” or “linking” or “composite” entity type (hence table) to stand between the two original ones.
ORGANIZATIONS
EMPLOYMENTSeach = person-id + organzn-id
possibly plus otherattributes
M:N -- a person may be employed by more than one organization and an organization may employ more than one person
PEOPLE
does not havean EMPL ID attrib.
does not have a PERS ID attrib
M:N Connectivity between Tablesusing a Bridging Entity Type
PERS-ID NAME AGE
9568876 Chopples 37
2544799 Blurp 21
1698674 Rumpel 88
1800748 Dunston 29
EMPL ID EMPL NAME ADDRESS NUM EMPLS SECTOR
E48693 BT BT House, London, …
1,234,5678 Private TCOM
E85704 Monmouth
School
Hereford Rd, Monmouth, …
245 Private 2E
E22561 University of
Birmingham
Edgbaston Park Rd, ….
4023 Public HE
People
Organizations
PERS-ID EMPL ID START
9568876 E22561 15-06-99
9568876 E85704 23-11-03
1698674 E22561 23-11-03
1800748 E22561 07-07-97
EEmmppllooyymmeennttss
Strong (or Identifying) Relationships A relationship from entity type A to entity type B,
mediated by having A’s primary key (PK) as a foreign key in B, is strong when B’s PK contains A’s PK. (incl. the case of B’s PK just being A’s PK).
So, B entities are defined in terms of A entities.
E.g., A = Customers, B = Dependents, where A’s PK is: CUST_ID
B’s PK is: CUST_ID, FIRST_NAME, CONNECTION.
So a PK value in B could be (1698674, Mary, child) , meaning that this entity is the child called Mary of person 1698674 in the Customer table.
a Strong Relationship
CUST-ID NAME PHONE EMPL ID AGE
9568876 Chopples 0121-414-3816 E22561 37
2544799 Blurp 01600-719975 E85704 21
1698674 Rumpel 07970-852657 E22561 88
1800748 Dunston 0121-414-3886 E22561 29
CUST-ID FIRST NAME CONNECTION LIVES_WITH
2544799 John civil partner TRUE
1698674 Mary child FALSE
1698674 Mary spouse FALSE
1698674 David child TRUE
Customers (the “A” type)
Dependents (the “B” type)
Strong relationship going from A to B
(we could say: “B is strongly dependent on A”)
Weak (or Non-Identifying) Relationships
A relationship is weak when it isn’t strong!
So, most relationships are weak.
Note that strength/weakness is directional: the People to Dependents relationship (above) is strong, but the Dependents to People relationship is weak.
Exercise: Can a relationship be weak in both directions?
Exercise: Can a relationship be strong in both directions?
Weak Entity Types A weak entity type E is one such that there is a
relationship RR from some other entity type F to E that satisfies the following two conditions:
RR is strong.
E is existence-dependent on F via RR.
That is, an E entity e can only exist in the database if some F entity in the database bears relationship RR to e.
This actually just means that R R —1 —1 (the RR relationship but in the E to F direction) is mandatory.
Weak Entity Types, contd. So on a previous slide, Dependents is weak, because there
is a strong relationship to it from Customers, and Dependents is existence-dependent on Customers via this relationship.
Mary’s existence in the database as a member of Dependents relies on the existence of customer 1698674 in the database.
But this doesn’t mean Mary would vanish from the world if customer 1698674 left the database or even if that customer were to vanish from the world.
And indeed Mary could herself be an entity in type Customers, and could remain so even if 1698674 left the DB or really vanished from the world.
Strong Entity Types
A strong entity type is one that is not weak! ….
So, in particular, any entity that receives only weak relationships from other entity types is strong.
So the usual case is for an entity type to be strong.
And any entity type that is not existence-dependent on anything is strong.
Mental Exercises for You What about the Employments bridging type we
introduced?
Although it might look at first as though a strong relationship necessarily implies existence dependence, it doesn’t. Why not?
One entity type can be existence-dependent on another without therefore being weak. Why?
Entity Relationship (ER) Model(s) and Diagrams
(ERMs and ERDs)
The Entity Relationship Model Introduced by Chen in 1976
Most widely used “conceptual model” of DBs.
“The ER model” : general meaning = just the idea of thinking of things as composed of entities, attributes and relationships.
We also say that applying this approach in a particular case gives rise to an “ER model” of the specific environment of interest.
Diagrams based on the/a model are a widely accepted and adopted graphical approach to database design.
The//an ER model has nothing intrinsically to do with diagrams!!! Let alone any specific sort of diagram!!!
A Conceptual Model
ER model that provides high-level, manager//user-friendly view of the database
Basis for identification and description of main data objects and relationships, avoiding details
Entity Relationship Diagrams (ERDs) An ER model of an environment forms the basis of an ER
diagram (ERD) or several ERDs.
There are several markedly different styles of ERD, and for each main style there are several variants.
And the style in the module handouts will differ somewhat from that in the textbooks and these lectures
An ERD depicts (some of) the ER model’s entity types, attributes and relationships, and (depending on the diagram style) varying amounts of other info such as connectivities, cardinalities, keys, weakness, …
Quick Flavour of Two Styles of Diagram
The Completed Tiny College ERD
Relationships: The Basic Chen ERD-let
Relationships: The Basic Crow’s Foot ERD-let
Caution In previous two diagrams, each relationship was
mandatory in both directions.
But saying “1:1”, “1:M” or “M:N” does not of itself imply mandatoriness in either direction. In particular, don’t be deceived by the “1” here – it’s not a minimum.
We will see in a minute how to draw optional (non-mandatory) relationships.
A Model for Tiny College
1:1 Relationship Between PROFESSOR and DEPARTMENT(mandatory in both directions)
1:M Relationship Between PAINTER and PAINTING (mandatory in both directions)
Tables for that 1:M Relationship
M:N Relationship between STUDENT and CLASS (both ways mandatory):preliminary ERD (conceptual level)
Conversion to Two 1:M Relationships (towards “logical” level)
A Bridge (or Composite) Entity Type
Its table is called a linking table (or bridging table)
Its primary key is composed of the primary keys of each of the entity types to be connected
Those keys are also foreign keys in the bridge type
Linking table may contain multiple occurrences of each foreign key value
May also contain additional attributes that play no role in the bridging as such
Direct Impln of M:N Relationship between STUDENT and CLASS
Converting the M:N Relationship into Two 1:M Relationships
Connectivity and Cardinality in an ERD
Relationship Participation Optional [in a particular direction, X to Y]:
an X entity occurrence does not require a corresponding Y entity occurrence
i.e. the minimum number of Ys per X is 0
Mandatory [in a particular direction, X to Y]:
an X entity occurrence requires a corresponding Y entity occurrence
i.e. the minimum number of Ys per X is 1 or more
Drawing Optionality
NOTE: the dashing of the line is NOT because of the optionality, but because of weakness
The Chen Representation of the Invoicing Problem
The Crow’s Foot Representation of the Invoicing Problem
The Attributes of the STUDENT Entity
Attributes
Weak Entity Types in ERDs
A Weak Entity in an ERD
A Weak (Non-Identifying) Relationship