Data Modelling Assignment 1
Barb Khayat
Student ID 991218886
-2Narrative for Question #1
We will observe the Baseball League for professional players. The league has teams and each team is made of
many players and can have several coaches.
A player may play for only one team (otherwise a clear conflict of interest), but might be without a team as well.
A team has several coaches and a coach may coach only one team, but might not coach at all.
A team plays many games and a game is always played by exactly 2 teams.
A coach coaches many players and a player is coached by many coaches (e.g. pitching coach, batting coach, head
coach)
A player is always represented by only one agent and cannot be without one.
An agent may represent many players, but may also be without clients.
Entities
Relationships
Attributes
Assumptions:
That a player will have at least one or more coaches.
A coach will be either a head coach, pitching coach, or batting coach.
A coach can have only one specialty.
Business Rules:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Each team is made of many players and can have several coaches.
A player may play for only one team (otherwise a clear conflict of interest), but might be without a team
as well.
A team has several coaches and a coach may coach only one team, but might not coach at all.
A team plays many games
Each game must always be played by exactly 2 teams
A coach coaches many players
A player is coached by many coaches (e.g. pitching coach, batting coach, head coach)
A player is always represented by only one agent and cannot be without one.
An agent may represent many players, but also be without clients.
Process:
When developing my Conceptual Model ERD by dissecting the vignette above, I first identified each Entity,
Attribute, and relationship. I also identified which words might be associated with determining the cardinality
constraint ratios and the participation values. I decided whether these attributes were stored or derived, single or
multi-valued, or mandatory or optional. I then determined whether any of these attributes could serve as a unique
identifier of an entity type. I captured business rules that applied to the scenario in order to identify data
constraints to allow data integrity to be achieved using domain and key constraints.
I drew the model according to the information collected. I included the entities, their attributes, and the
relationships between them. I determined that the entity type was an n-ary type since there was 5 Entities
involved (Team, Player, Coach, Game & Agent). I labelled cardinality and participation constraints. I indicated the
prime keys for each entity and showed them as mandatory.
I decided that the Coaching entity needed to be shown as a Superclass–Subclass relationship (SC/sc). Total
Student ID 991218886
-3-
participation is shown for the subclasses because there are only 3 choices of positions that a coach can have if he is
coaching and nothing else. The subclasses of this specialization are disjoint as a coach cannot be a member of
more than one subclass of the specialization. I placed a fork on each subclass connector pointing toward the
Superclass identifying the subclasses. The subclasses in the specialization are predicate-defined subclasses. The
defining predicate is Coach type and the values head, pitching and batting coach are next to their corresponding
subclass connectors.
When transforming the Presentation Layer ER model (used for communicating with end users), to the (database
designer oriented) Design-Specific ER model, I incorporated additional details about the characteristics of
attributes obtained from the users. I showed this by demonstrating Foreign Keys, Primary Keys, weak entities and
relationships.
This layer of this model is the fine granularity. This maps the attribute characteristics to the ER diagram and
decomposes specific constructs (multi-valued attributes and m:n relationship types). I decomposed the m:n
relationships between the entities Team & Game and Player & Coach and displayed them as weak entities and
relationships. I added a new entity and new relationship types to both m:n constructs and reassigned the
cardinality ratios. I created new PK’s for them and showed them as foreign. I added a foreign key to Team entity
so that Player and Coach could have access to the Game entity. I determined that all Coaching entities in the
Superclass Coach marked by their defining predicate will also be members of that subclass.
Student ID 991218886
-4-
Narrative for Question #2
The Jarvis Art Gallery wishes to maintain data about their customers, artists and paintings. They may have several
paintings by each artist in the gallery at one time. Paintings may be bought and sold several times. In other words,
the gallery may sell a painting, then buy it back at a later date and sell it to another customer.
Gallery Customer History Form
Customer Name
Jackson, Elizabeth
123 – 4th Avenue
Fonthill, ON
L3J 4S4
Phone
(206) 284-6783
Purchases Made
Artist ID
Title
Purchase Date
Sales Price
03 - Carol Channing
15 - Dennis Frings
1800.00
03 - Carol Channing
15 - Dennis Frings
2200.00
Laugh with Teeth
09/17/2000
South toward Emerald Sea
05/11/2000
7000.00
At the Movies
02/14/2002
South toward Emerald Sea
07/15/2003
5550.00
Assumptions:
A customer is not a customer until they purchase a painting.
The title Artist in the view should be called Artist ID so it will not be confused with the entity Artist.
Sales and purchases cannot be on the same transaction. They must have separate transactions.
C_Name & P_Title are unique IDs
Painting titles must be unique to be used as the Primary key
Business Rules:
1.
2.
3.
They may have several paintings by each artist in the gallery at one time.
Paintings may be bought and sold several times.
The gallery may sell a painting, then buy it back at a later date and sell it again.
Process:
When developing my Conceptual Model ERD by dissecting the vignette above, I first identified each Entity,
Attribute, and relationship. I also identified which words might be associated with determining the cardinal
constraint ratios and the participation values. I decided whether these attributes were stored or derived, single or
multi-valued, or mandatory or optional. I then determined whether any of these attributes could serve as a unique
identifier of an entity type. I captured business rules that applied to the scenario in order to identify data
constraints to allow data integrity to be achieved using domain and key constraints.
Student ID 991218886
-5-
I drew the model according to the information collected. I included the entities, their attributes, and the
relationships between them. I noted that the entity type was a ternary type since there were 3 Entities involved
(Customer, Painting & Artist). I showed cardinality and participation constraints. I indicated the primary keys for
each entity and showed them as mandatory.
To address the problem of how to record the purchasing and selling of the paintings separately I created a
Categorization structure to show buying transactions and selling transactions as superclasses and transaction as a
subclass of the union of the two. I showed attributes and primary keys for each SC.
I noted that the completeness constraint for the superclasses in the categorization exhibits total participation thus
it is called a total category. I showed the fork on the subclass connector facing towards the SCs. I used role names
connecting the buy and sell relationships to their respective superclasses. Type inheritance of the subclass
Transactions is selective. After doing all this and going over the process I didn’t feel comfortable with the
functionality of the SC/sc in its role. It seemed problematic and the relationships complex. I decided to change the
schema.
When transforming the Presentation Layer ER model to the Design-Specific ER model, I changed the structure to
show a specialization construct instead of a category construct. Transaction is now the Superclass and the
subclasses are Buy and Sell each with their own unique PK. I showed attributes, primary and Foreign keys which
were brought from Customer and Painting. The subclasses of this specialization must be disjoint because it can
only be a buy or sell transaction at one time. The defining predicate is Transaction type and the values buy and sell
transaction are next to their corresponding subclass connectors. I incorporated additional details about the
characteristics of attributes obtained from the users. I showed this by using min/max notations. This layer of this
model is the fine granularity.
Student ID 991218886
Assignment 1 Question 1 Part A
fig 1-a
\
Conceptual Model ER Presentation Layer
AG_ID
TM_ID
PLYR_ID
Team
Team
1
is made of
n
Player
Player
n
2
represents
1
n
1
plays
has
Coaches
n
m
n
CO_ID
GM_ID
Coach
Coach
d
U
Head
Coach
Head
Head
Coach
Coach
Student ID 991218886
U
d
U
Game
Game
Pitching
coach
Pitching
Coach
Batting
Coach
Batting
Coach
Agent
Agent
Assignment 1 Question 1 Part B
fig 1-b
Design Specific EER Fine Granularity
AG_ID
TM_ID
PLYR_ID
(FK) GM_ID
(FK) GM_ID
Team
Team
1
is made of
1
represents
1
1
has
has
Game
Game
Assignment
Assignment
A_Plyr_ID (FK)
n
n
(FK) GA_T_ID
A_CO_ID (FK)
1
Assignment
Assignment
has
n
2
(FK) GA_GM_ID
m
Belongs
to
has
GM_ID
n
Player
Player
n
1
CO_ID
1
Coach
Coach
Game
Game
Coach_type
d
“Pitching”
Head
Head
Coach
Coach
Student ID 991218886
U
U
“Head”
d
U
“Batting”
Pitching
Coach
Batting
Coach
Agent
Agent
Assignment 1 Question 2 Part A
fig 1-c
Conceptual Model ER Presentation Layer
1
sell
n
C_Name
ST_Price
C_Phone
ST_ID
via
P_Title
P_Title
Transaction
Transaction
Total
Total
U
Customer
Customer
Artist_ID (FK)
Sell
Sell
Transaction
Transaction
C_Name
U
ST_Date
U
BT_Price
C_Name
1
Painting
Painting
BT_Date
Buy
Buy
Transaction
Transaction
through
C_addr
P_Title
n
BT_ID
create
Buy
n
1
A_#
A_NAME
Artist_ID
Artist
Artist
Student ID 991218886
Assignment 1 Question 2 Part B
fig 1-d
Design Specific EER Model Fine Granularity
C_addr
C_Phone
(FK) P_Title
T_Date
P_Title
T_Price
(FK) C_Name
(FK)
C_Name
Artist_ID
1
1
Customer
Customer
creates
1
Transaction
Transaction
Painting
Painting
has
n
Transaction_type
n
d
d
U
BT_ID
“Buy”
creates
U
ST_ID
A_#
“Sell”
A_NAME
1
Artist_ID
Buy
Buy
Transaction
Transaction
Student ID 991218886
Sell
Sell
Transaction
Transaction
Artist
Artist