TUTORIAL 9
1. Consider the following normalized relations for a sports league:
TEAM (TeamID, TeamName, LocationID)
PLAYER (PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode)
SPECIALTY (SpecialtyCode, SpecialtyDescription)
CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary)
LOCATION (LocationID, City, State, Country, CityPopulation)
MANAGER (ManagerID, ManagerName, TeamID)
What are the possible opportunities for denormalization? What
additional information would you need in order to make fully informed
denormalization decisions?
What are the possible opportunities for denormalization?
TEAM (TeamID, TeamName, LocationID)
PLAYER (PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode)
SPECIALTY (SpecialtyCode, SpecialtyDescription)
CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary)
LOCATION (LocationID, City, State, Country, CityPopulation)
MANAGER (ManagerID, ManagerName, TeamID)
The foreign keys in this database are: TEAM (LocationID), PLAYER
(SpecialtyCode), CONTRACT (TeamID, PlayerID), and MANAGER
(TeamID). We consider each of them as a denormalization opportunity;
however, we carry out denormalization only if a pair of tables are co-accessed
together (joined in queries) very often.
One possibility for denormalization would be the inclusion of
SpecialtyDescription attribute in the PLAYER relation, i.e., merge
SPECIALTY table into PLAYER table, to get PLAYER_SPECIALTY
(PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode,
SpecialtyDescription), which is no longer 3NF. (In fact, it is 1NF, due to the
partial dependency: PlayerID determines FirstName, LastName, DateOfBirth;
also SpecialtyCode determines SpecialtyDescription.)
What additional information would you need in order to make fully
informed denormalization decisions?
TEAM (TeamID, TeamName, LocationID)
PLAYER (PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode)
SPECIALTY (SpecialtyCode, SpecialtyDescription)
CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary)
LOCATION (LocationID, City, State, Country, CityPopulation)
MANAGER (ManagerID, ManagerName, TeamID)
To decide whether to do this, you would need to know if SpecialtyDescription and Player
information are co-accessed together very often. Another consideration is the size of the
SpecialtyDescription attribute. In addition to re-introducing update anomalies, denormalizing
the relations by adding the SpecialtyDescription data to the PLAYER relation might add a lot
of repeated information that could take up a great deal of storage, although storage wastage is
considered a minor price to pay. The main problem is the risk of data inconsistencies when
updating SpecialtyDescription.
Other possible opportunities for denormalization are as follows:
• merge LOCATION into TEAM if these tables are co-accessed together very often
• merge TEAM into MANAGER if these tables are co-accessed together very often.
• merge TEAM into CONTRACT if these tables are co-accessed together very often.
• merge PLAYER into CONTRACT if these tables are co-accessed together very often.
2. Consider the 3NF relational schema shown in Figure 1. Assume that the
most important reports that the organization needs are as follows:
a) A list of project assignments of each developer;
b) A list of the total costs for each project;
c) For each team, a list of its membership history;
d) For each country, a list of all assignments in which the country’s
developers are involved;
e) For each year separately, a list of all the assignments that were for the
projects completed during that year, sorted by project end date.
(i) Based on the limited information, make a recommendation regarding
the indexes that you would create for this database.
(ii) Choose two relations and provide the SQL command that you would
use to create secondary indexes for the relations.
2(i). Based on the limited information,
make a recommendation regarding the
indexes that you would create for this
database.
Every Primary Key already has an index by
default (so we don’t need to worry about
creating indexes for primary keys).
For foreign keys and other columns, based on
the reporting needs, the following indexes
could be useful for improving the
performance for generating each of the
reports (a) to (e):
a) A list of project assignments of each
developer:
foreign key DevID in Assignment relation: to
speed up the join of DEVELOPER and
ASSIGNMENT by DevID.
b) A list of the total costs for each project:
foreign key ProjID in Assignment relation: to
speed up the join of PROJECT with
ASSIGNMENT by ProjID.
6
Week 10 Wang Lipo [email protected] 6
c) For each team, a list of its membership
history:
foreign key TeamID in Membership relation: to
speed up the join of TEAM with MEMBERSHIP
by TeamID.
d) For each country, a list of all assignments in
which the country’s developers are involved:
foreign key CountryID in Country Mgr relation,
foreign key CMID in Develop Mgr relation,
foreign key DMID in Developer relation, and
foreign key DevID in Assignment relation: to
speed up the join of COUNTRY with COUNTRY
MGR by CountryID, with DEVELOP MGR by
CMID, with DEVELOPER by DMID, with
ASSIGNMENT by DevID.
e) For each year separately, a list of all the
assignments that were for the projects
completed during that year, sorted by project
end date:
foreign key ProjID in Assignment relation, and
ProjEndDate in Project relation: the former is to
speed up the join of PROJECT with
ASSIGNMENT by ProjID, and the latter is to
speed up the ordering of the result by ProjEndDate
(only ProjEndDate is not a foreign key in the
above indexes created)
Week 10 Wang Lipo
[email protected] 7
2(ii). Choose two relations and provide the SQL command that
you would use to create secondary indexes for the relations.
SQL command for creating an index:
CREATE INDEX index_name ON table_name(column_name);
For our question here:
CREATE INDEX assigndevindx ON ASSIGNMENT(DevID);
CREATE INDEX assigprojindx ON ASSIGNMENT(ProjID);
CREATE INDEX projenddateindx ON PROJECT(ProjEndDate);
3. Consider the following normalized relations for sports leagues in global scope:
LEAGUE (LeagueID, LeagueName, LocationID)
TEAM (TeamID, TeamName, LocationID, LeagueID)
PLAYER (PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode)
SPECIALTY (SpecialtyCode, SpecialtyDescription)
CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary)
LOCATION (LocationID, City, State, Country, CityPopulation)
MANAGER (ManagerID, ManagerName, TeamID)
The following database operations are frequently used:
1. Reporting players by team
2. Reporting players by team and specialty
3. Reporting players ordered by salary in descending order
4. Reporting teams and players by city
Based on the above-mentioned information:
a) Identify the primary keys and foreign keys
b) Make a recommendation regarding the indexes that you would create for
this database. Explain how you used the list of operations to arrive at your
recommendation.
3. a) Identify the primary keys and foreign keys
LEAGUE (LeagueID, LeagueName, LocationID)
TEAM (TeamID, TeamName, LocationID, LeagueID)
PLAYER (PlayerID, FirstName, LastName, DateOfBirth, SpecialtyCode)
SPECIALTY (SpecialtyCode, SpecialtyDescription)
CONTRACT (TeamID, PlayerID, StartTime, EndTime, Salary)
LOCATION (LocationID, City, State, Country, CityPopulation)
MANAGER (ManagerID, ManagerName, TeamID)
3. The following database operations are LEAGUE (LeagueID, LeagueName, LocationID)
frequently used: TEAM (TeamID, TeamName, LocationID, LeagueID)
1. Reporting players by team PLAYER (PlayerID, FirstName, LastName, DateOfBirth,
2. Reporting players by team and specialty SpecialtyCode)
3. Reporting players ordered by salary in SPECIALTY (SpecialtyCode, SpecialtyDescription)
descending order CONTRACT (TeamID, PlayerID, StartTime, EndTime,
4. Reporting teams and players by city Salary)
b) Make a recommendation regarding the LOCATION (LocationID, City, State, Country,
indexes that you would create for this CityPopulation)
database. Explain how you used the list of MANAGER (ManagerID, ManagerName, TeamID)
operations to arrive at your
recommendation.
All Primary Keys are automatically indexed (so no worries about adding indexes for primary
keys).
The following indices could be useful for improving the performance for generating each of
the required reports:
1. foreign keys TeamID and PlayerID on CONTRACT, since we need to join PLAYER,
CONTRACT, and TEAM tables (different from the primary key index for the composite
primary key TeamID, PlayerID).
2. We create index for foreign key SpecialityCode on PLAYER, since we need to join
PLAYER, SPECIALTY tables.
3. In addition to PlayerID on CONTRACT in part 1, we also create an index for non-key
Salary on CONTRACT, since we need to join PLAYER and CONTRACT tables, as well as
sort by Salary.
4. In addition to foreign keys TeamID and PlayerID on CONTRACT in part 1, we create
index for foreign key LocationID on TEAM, since we need to join PLAYER, CONTRACT,
LOCATION, and TEAM tables
Week 10 Wang Lipo
[email protected] 11
4. Identify the key differences between logical database design and physical
database design.
Logical database design is to establish an ER diagram and a set of 3NF relations
(relational schema). No redundancy should be included in logical database design
(normalization).
Physical database design is to enhance performance, database integrity, security and
resources, etc. Some redundancy may be introduced in physical database design for
performance reasons (e.g., denormalization, indexes).
5. State the major tasks to be carried out in physical database design and the
methods that may be applied in each task.
The major tasks are:
(1) Designing fields (columns): include data type and integrity control
(2) For efficiency purposes, the following methods or a combination of them may
be used:
(a) Denormalization
(b) Partitioning: Horizontal Partitioning, Vertical Partitioning
(3) Design physical database files:
Unordered File, Ordered File, Hashed File, Clustering files
(4) Indexes: primary index should be defined for primary key (usually done
automatically by the DBMS), secondary indexes should also be defined for
frequently access columns (e.g., columns frequently used in joins, frequently
ordered columns, frequently searched columns)
(5) Design for parallel query processing: use horizontal partition to divide tables
into portions so that the query on these portions are processed in parallel
6. Explain the difference between a static web page and a dynamic one.
A static web page is fixed in time and cannot include information that change with
time or user input, i.e., a web page ending with *.htm and *.html.
• Made up of a fixed number of pre-built files
• When user request for a webpage from the server via a URL the corresponding
HTML/CSS/JavaScript files are returned
• All users who request for the same URL will see the same content
• Static websites can be interactive/engaging (e.g., clickable links and buttons,
images and video)
• Common static websites are typically informational or read-only sites (e.g.,
school websites, resume/biography websites)
6. Explain the difference between a static web page and a dynamic one.
A dynamic page includes information that changes with time and/or user input,
therefore allowing the display of data from querying and storage of user input, i.e.,
a dynamic web page is an output of a program, that is, a web page ending with
*.php, *.asp, *.jsp, etc.
• Displays different content to different users, determined by several factors
(e.g., location, time, setting, history, etc)
• A dynamic page is build “on-the-fly” when request a page from the web server
• Greater flexibility on the front-end (client side), but more complexity on the
back-end (server side)
• Common dynamic websites are websites where the information is changed
frequently (e.g., stock price, weather) or personalized (e.g., Shopee, Netflix,
X).
7. Contrast the following terms in client-server architecture:
a) Two-tier architecture; three-tier architecture.
b) Fat client; thin client.
c) SQL; Java.
a) Two-tier architecture consists of 1 client plus 1 server, i.e., distributes
presentation logic on the client, storage logic (database) on the server, and then
places the processing logic either on the client, server, or distributed between the
server and client. Three-tier architectures consist of 1 client plus 2 servers, i.e.,
application server and database server; usually, processing logic or application
programs resides and runs on the application server.
b) A distinction among client capabilities that is based on processing capabilities, a
fat client is responsible for more processing—including presentation logic,
extensive processing logic (i.e., application logic, and business rules logic)—while
a thin client is responsible for much less processing, usually only presentation logic
(e.g., display of a web page).
c) SQL is a standard language for creating and querying relational databases. Java
is a general-purpose programming language.
