0% found this document useful (0 votes)
8 views

5-rel-db-design-05-converting-slides

Uploaded by

etest2272
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

5-rel-db-design-05-converting-slides

Uploaded by

etest2272
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 62

Relational Database Design

Module 5: Converting to Relational


Hugo Kornelis
[email protected]
Outline

 Conversion between representations


 Entity Relationship diagram
 Relational database design

 Why do we need two representations?

 How to represent a relational database design?

 Conversions
 ER diagram to relational
 Relational to ER diagram
Why convert from ER to relational?

 Entity Relationship diagram


 Good for design
 Quick overview
 Easy to read
 Accessible
 Not good for implementation
 Mapping not exactly one on one

 Relational database design


 Good for implementation
 Not good for design
Why convert from relational to ER?

 Inherited database
 No documentation
 Outdated documentation

 Convert to Entity Relationship diagram


 Quick overview
 Understand how tables relate
When to convert?

 Ideal?
 Initial model (ER)
 Normalize (ER)
 Convert (Relational)

 Practical?
 Initial model (ER)
 Convert (Relational)
 Normalize (Relational)
 Convert changes back (ER)
What to convert?

 Relational representation
 Physical model
 Optimized for performance
 Vendor-specific tweaks
 Logical model

 Entity Relationship representation


 Logical model
 Physical model?
 (Only when converting FROM relational implementation – use with care!)
Representing a relational database design

 Compact form
 Benefits
 Compact
 Quick to create
 Downside Optional? Reference?
 Lack of detail

Table1 (Column1, Column2, Column3)

Table2 (Column4, Column5)


Data type?

Table3 (Primary key, Alternate key, Foreign key)


or
Table3 (Primary key, Alternate key, Foreign key)
Representing a relational database design

 DDL
 All details included
 Not accessible
Representing a relational database design

 Graphical

Tables
Representing a relational database design

 Graphical

Tables
Relationships
Representing a relational database design

 Graphical

Tables
Relationships
Keys
Optionality
Data types
Representing a relational database design

 Graphical
 Notation similar to ER diagrams
 Easy to understand
 Blurs distinction between
design and implementation
 Leads to implementation
choices in design

Tables
Relationships
Keys
Optionality
Data types
ER to relational: Entity types

 Entity type
 Converted to a relational table
 Same name or different name?

 ER naming convention
 Singular (e.g. Person)

 Relational naming convention


 Plural (e.g. Persons)
 Or group (e.g. People)
ER to relational: Entity types

 Entity type
 Converted to a relational table
 Same name or different name?

 Same name
 Easier mapping between representations
 Plural entity type names make the ER diagram look wrong
 (And the relationship readings sound weird)
 Singular table names introduce wrong mindset
 Encourage one-row-at-a-time coding instead of set-based
 Queries sound better with plural table names
 Less chance of hitting a reserved word
ER to relational: Entity types

 Entity type
 Converted to a relational table
 One column for every attribute
 Column name is (almost always) equal to attribute name
 Optional = nullable; mandatory = NOT NULL
 Add data type
 Implementation independent (e.g. “character” / “numeric”)
 Optionally shortened
 C = character data
 N = numeric data
 D = date/time data
 Full details in appendix
 Range
 Precision
 Maximum length
 …
ER to relational: Candidate keys

 Candidate key
 Enforced by constraint
 Primary key  PRIMARY KEY constraint
 Required by Codd’s 2nd rule
 At most one
 Alternate key  UNIQUE constraint

 Primary key vs alternate key:


 Primary key is default target for FOREIGN KEY constraint
 Primary key must be on NOT NULL columns
 Implementation-dependent differences
 Final choice of primary key in physical model
ER to relational: Candidate keys

 Representation of primary key


Table1 (Column1, Column2, Column3)

Column1 Column2 Column3


C D opt N

 Representation of alternate key


 Appendix Table1 (Column1, Column2, Column3)

Column1 Column2 Column3


C D opt N
ER to relational: Candidate keys

 Representation of primary key


Table1 (Column1, Column2, Column3)

Column1 Column2 Column3


C D opt N

 Representation of alternate key


 Appendix Table1 (Column1, Column2, Column3)

Column1 Column2 Column3


C D opt N
ER to relational: Candidate keys

 Every key in ER diagram


 Candidate key in relational database design
 Primary or alternate?
 Stick to choice made in ER diagram
 Choose now

Final choice in physical model!!!


ER to relational: One-to-many relationships
Player
League

 One-to-many relationship Player number is of /


p lays in
League code
Player name (AK1.1) P
Frames to play
League code (FK)

Me mbership term Player

 Special case: identifying relationship Year has / Player number


Player number (FK) is of
P Player name (AK1.1)
Paid? League code (FK)

Player
B oard position

 One-to-one relationship Player number holds /


is held by Z
Position name
Player name (AK1.1)
Player number (FK) (AK1.1)
League code (FK)

Player

 Special case: subtype relationship Player number


Player name (AK1.1)
League code (FK)

V olunteer
Player number (FK)
Primary duty
ER to relational: One-to-many relationships
Me mbership term Fina ncial transaction
Year Bank statement number
 One-to-many relationship Player number (FK) is p aid with /
is p ayment for
Line number
Paid? Date
 FOREIGN KEY constraint Amount
MembShipTerm_Year (FK)
Referenced table MembShipTerm_Player (FK)

MembershipTerms
YearNbr PlayerNbr Paid
N N C Referencing columns

FinancialTransactions
StatementNbr LineNbr TranDate Amount MembShipTerm_Year MembShipTerm_Player
N N D N N opt N opt
ER to relational: One-to-many relationships

 One-to-many relationship
 FOREIGN KEY constraint
 Foreign key attributes represented in ER diagram?
 Just add the FOREIGN KEY constraint
 Using ER method that leaves out the foreign key attributes?
 Add referencing columns first, then add FOREIGN KEY constraint
 Choose one of the candidate keys in the referenced table
 Default to PRIMARY KEY
ER to relational: One-to-many relationships

 One-to-one relationship
 FOREIGN KEY constraint
 Choice of parent (referenced) and child (referencing) table:
 Copy from ER diagram, if choice was made there
 Choose now otherwise
 CHOICE CAN BE CHANGED LATER (physical model)

 Subtype relationship
 FOREIGN KEY constraint
 Always subtype = referencing table / supertype = referenced table
 Appendix for additional information
 Discriminator
 Complete / incomplete subtype relationship
 Mutual exclusive subtype relationships
ER to relational: One-to-many relationships

 One-to-many / one-to-one relationship


 Minimum cardinality of child
 If zero, allow NULLs in referencing columns
 If one, define NOT NULL on referencing columns

 Minimum cardinality of parent


 If zero, nothing needed (standard behavior)
 If one, cannot be represented
 Specify in appendix
 Has to be enforced in code
 Only possible with deferred constraint checking

 Special maximum cardinality of parent


 Cannot be represented
 Specify in appendix
 Has to be enforced in code
ER to relational: Many-to-many relationships

 Many-to-many relationship Employee Project

 Minimum/special cardinality EmployeeName


wo rks on / ProjectCode
SSN (AK1.1) is worked on by Date Started
 Appendix / code DeptCode (FK) Date Due

Employees Salary

EmployeeName SSN DeptCode Salary


C C Opt C N

Projects
ProjectCode DateStarted DateDue
N D D Opt

Good name goes here


ProjectCode EmployeeName
N C
ER to relational: Many-to-many relationships

 Many-to-many relationship Employee Project

 Minimum/special cardinality EmployeeName


wo rks on / ProjectCode
SSN (AK1.1) is worked on by Date Started
 Appendix / code DeptCode (FK) Date Due

Employees Salary

EmployeeName SSN DeptCode Salary


C C Opt C N

Projects
ProjectCode DateStarted DateDue
N D D Opt

EmployeesProjects
ProjectCode EmployeeName
N C
ER to relational: Many-to-many relationships

 Many-to-many relationship Employee Project

 Minimum/special cardinality EmployeeName


wo rks on / ProjectCode
SSN (AK1.1) is worked on by Date Started
 Appendix / code DeptCode (FK) Date Due

Employees Salary

EmployeeName SSN DeptCode Salary


C C Opt C N

Projects
ProjectCode DateStarted DateDue
N D D Opt

EmployeesWorkOn
ProjectCode EmployeeName
N C
ER to relational: Many-to-many relationships

 Many-to-many relationship Employee Project

 Minimum/special cardinality EmployeeName


wo rks on / ProjectCode
SSN (AK1.1) is worked on by Date Started
 Appendix / code DeptCode (FK) Date Due

Employees Salary

EmployeeName SSN DeptCode Salary


C C Opt C N

Projects
ProjectCode DateStarted DateDue
N D D Opt

ProjectStaffing
ProjectCode EmployeeName
N C
ER to relational: Many-to-many relationships

 Many-to-many relationship
 Implemented as extra table
 Junction table
 Linking table
 Cross-reference table
 Join table
 …
 Not different from other tables!
ER to relational: Many-to-many relationships

 Relationships between three or more entity types


 Not supported in IDEF1X
 Possible in some other ER methods
 Implemented as extra table (similar to many-to-many relationship)
 Three or more foreign keys, for each connected entity type
 Primary key over all columns
ER to relational: Other constraints

 CHECK constraint
 Logical expression
 May never evaluate to FALSE for any row
 Can include one column, or several column
 Cannot reference other tables
 Cannot reference other rows in the same table



ER to relational: Other constraints

 Generated column
 What if only a single value is allowed?
 Database can compute it for you
 Generated column (aka derived column / computed column)
 No access to other tables or other rows in same table

FramesLost always equal to (5 – FramesWon)


ER to relational: Other constraints

 Assertion
 Similar to CHECK constraint
 Does allow access to other rows / other tables
 Not supported by many RDBMS vendors
 Can be used as a way to specify logic for database developers
ER to relational: Other constraints

 DEFAULT constraint
 Not really a constraint
 Provides standard value to use if no value specified
 Not the same as a generated column!
 DEFAULT used only for new rows
 DEFAULT can be overridden or changed
 DEFAULT cannot reference any other columns or contain logic
 Constant values
 Built-in functions
ER to relational: Other constraints

 CHECK constraint
 Generated column
 Assertion
 DEFAULT constraint

 Found in appendix
 Not represented in ER diagram
Calendar ER to relational: demo c annot play on /
Day
Date
is blocked by
Day of week

is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
League code (FK) is played by P Frames won pl 1
P
Frames won pl 2
is of /
p lays in
Leagues League
League code
Frames to play

Co mp etition match Cup match


Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round

CompetitionMatches CupMatches
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek is blocked by
Day of week
D C
is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek is blocked by
Day of week
D C
is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek is blocked by
Day of week
D C
is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek is blocked by
Day of week
D C
is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek is blocked by
Day of week
D C
is for /
is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek BlockedDates is blocked by
Day of week
D C
Date PlayerNbr is for /
D N is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
LeagueCode FramesToPlay Frames to play
C N
Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar ER to relational: demo c annot play on /
Day
Date
Date DayOfWeek BlockedDates is blocked by
Day of week
D C
Date PlayerNbr is for /
D N is played on

Player Match
plays in /
Players Player number is played by P
Player 1 (FK)
Player 2 (FK)
Player name (AK1.1) plays in / Date (FK)
PlayerNbr PlayerName LeagueCode League code (FK) is played by P Frames won pl 1
N C C opt P
Frames won pl 2
is of /
p lays in
Leagues League
League code
Both empty
LeagueCode FramesToPlay or Frames to play
C N
both filled Co mp etition match Cup match
Player 1 (FK) Player 1 (FK)
c onsists of / Player 2 (FK) Player 2 (FK)
Matches is played for P Date (FK) Date (FK)
League code (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Relational to ER: First draft

 Reverse from conversion ER to relational


 How to handle tables?
 Can result from entity type OR from many-to-many relationship!
 For first draft, assume they all come from entity type
 Alternative explored in second phase
Relational to ER: First draft

 Tables  Entity types


 Naming?
 PRIMARY KEY columns  Key attributes
 Other columns  Non-key attributes
 NOT NULL  mandatory / otherwise optional
 UNIQUE constraints  Alternate keys
 Elements that go to the appendix:
 CHECK constraints
 Assertions
 DEFAULT constraints
 Generated columns
Relational to ER: First draft

 FOREIGN KEY constraints  relationships


 Normally one-to-many
 Referenced table = parent entity type
 Referencing table = child entity type
 One-to-one when referencing columns are PRIMARY KEY / UNIQUE

 Referencing columns NOT NULL  Mandatory relationship


 Referencing columns nullable  Optional relationship

 Minimum cardinality at parent side is always zero


 Unless …

 Relationship readings cannot be reconstructed from relational model


Relational to ER: First draft

 FOREIGN KEY constraints  relationships


 All referencing columns included in the PRIMARY KEY?
 Relationship is identifying
 Referencing entity type is weak

 Referencing columns exactly equal to the PRIMARY KEY?


 Relationship is subtype relationship
 Referencing entity type is subtype
 Not possible to reconstruct:
 Discriminator
 Complete/incomplete
 Mutually exclusive
Relational to ER: First draft

 FOREIGN KEY constraints  relationships


 IDEF1X and other methods that include foreign key attribute
 Done
 ER diagramming methods that don’t show foreign key attribute
 Remove attributes that correspond to referencing columns
Relational to ER: Variations

 First draft: all tables  entity types


 Alternative: some tables  many-to-many relationships
 Only possible for some entity types
 All attributes included in key
 Entity type participates in exactly two relationships
 Both identifying
 Entity type must be child in both
 Option to replace
 Remove entity type
 Remove both identifying relationships
 Replace with many-to-many relationship
 Minimum cardinalities copied from (replaced) identifying relationships
 Naming?
Relational to ER: Variations

 IDEF1X: All relationships connect TWO entity types


 Some methods support relationships with more entity types
 Only possible for some entity types
 All attributes included in key
 Entity type participates in at least two relationships
 All identifying
 Entity type must be child in each
 Option to replace
 Remove entity type
 Remove all identifying relationships
 Replace with many-to-many relationship or relationship with >2 entity types
 Minimum cardinalities copied from (replaced) identifying relationships
 Naming?
Relational to ER: Variations

 Use many-to-many or leave as entity type?


 Both versions are correct
 Choose the one that best expresses the meaning of the facts represented
 Might even mix & match, depending on audience

 Use relationship between >2 entity types or leave as entity type?


 (Only relevant if supported by your method)
 Both versions are correct
 Choose the one that best expresses the meaning of the facts represented
 Might even mix & match, depending on audience
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date DayOfWeek
D C
PlayerNbr
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1


Player2
PlayerName (AK1.1) Date
LeagueCode
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date DayOfWeek
D C
PlayerNbr
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1


Player2
PlayerName (AK1.1) Date
LeagueCode
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date DayOfWeek
D C
PlayerNbr
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1


Player2
PlayerName (AK1.1) Date
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date DayOfWeek
D C
PlayerNbr
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1


Player2
PlayerName (AK1.1) Date
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode (FK) Round


Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date (FK) DayOfWeek
D C
PlayerNbr (FK)
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1


Player2
PlayerName (AK1.1) Date
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode (FK) Round


Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date (FK) DayOfWeek
D C
PlayerNbr (FK)
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1 (FK)


Player2 (FK)
PlayerName (AK1.1) Date (FK)
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mp etitionMatch CupMatch
Date Date
Player1 Player1
Matches Player2 Player2

LeagueCode (FK) Round


Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date (FK) DayOfWeek
D C
PlayerNbr (FK)
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1 (FK)


Player2 (FK)
PlayerName (AK1.1) Date (FK)
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mpetitionMatch CupMatch
Date Date (FK)
Player1 Player1 (FK)
Matches Player2 Player2 (FK)
LeagueCode (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date (FK) DayOfWeek
D C
PlayerNbr (FK)
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1 (FK)


Player2 (FK)
PlayerName (AK1.1) Date (FK)
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mpetitionMatch CupMatch
Player1 (FK) Date (FK)
Player2 (FK) Player1 (FK)
Matches Date (FK) Player2 (FK)
LeagueCode (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates BlockedDate
Date (FK) DayOfWeek
D C
PlayerNbr (FK)
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1 (FK)


Player2 (FK)
PlayerName (AK1.1) Date (FK)
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mpetitionMatch CupMatch
Player1 (FK) Date (FK)
Player2 (FK) Player1 (FK)
Matches Date (FK) Player2 (FK)
LeagueCode (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Mon,Tue,Wed,Thu,Fri
Calendar Relational to ER: demo Calendar
Date
Date DayOfWeek BlockedDates
DayOfWeek
D C
Date PlayerNbr
D N
Player Match

Players PlayerNbr Player1 (FK)


Player2 (FK)
PlayerName (AK1.1) Date (FK)
LeagueCode (FK)
PlayerNbr PlayerName LeagueCode Frames1
N C C opt Frames2

Leagues League
LeagueCode
Both empty
LeagueCode FramesToPlay or FramesToPlay
C N
both filled Co mpetitionMatch CupMatch
Player1 (FK) Date (FK)
Player2 (FK) Player1 (FK)
Matches Date (FK) Player2 (FK)
LeagueCode (FK) Round
Player1 Player2 MatchDate Frames1 Frames2
N N D N opt N opt

R1,R2,QF,SF,Fin
CompetitionMatches CupMatches

LeagueCode Player1 Player2 MatchDate Player1 Player2 MatchDate Round


C N N D N N D C
Summary

 Convert between ER and relational


 Reasons for two representations
 How to represent a relational design
 From ER to relational
 Entity types
 Attributes
 Keys
 Relationships
 One-to-many / one-to-one
 Many-to-many
 Other elements
 From relational to ER
 First version
 Alternatives (with many-to-many relationships)

You might also like