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

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

Uploaded by

etest2272
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

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

Uploaded by

etest2272
Copyright
© © All Rights Reserved
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