1. Problem 1a - Relational Algebra (Spr15)
List the name and address of all vendors that provide both hardware and software.
BOTHV = HVendorID,SVendorID (
 HWFlag=T and SWFlag=T (Vendor))
ANS = HVName, HVAddr (HardwareVendor * BOTHV)
HVendorID
 SVName, SVAddr (SardwareVendor * BOTHV)
SVendorID

2. Problem 1b - Relational Algebra (Spr15)
List the versions and vendor names of all C++ software installed on computers made by the vendor DEC.
COMPV = VendorID,CInventNum (Computer * Inventory)
CInventNum=InventNum
HWVEND = HVendorID,CInventNum (COMPV * Vendor)
VendorID
DEC = CInventNum ( HVName=DEC
(HWVEND * HardwareVendors))
HVendorID
DECSW = SInventNum (DEC * InstalledSW)
CInventNum
DEC++SW = SVendorID,SWVersion ( SWName=C++
DECSW * Software)
SInventNum
ANS = SWName,SWVersion (DEC++SW * SoftwareVendor)
SVendorID

3. Problem 1c - Relational Algebra (Spr15)
List all purchase orders from the vendor Dell that have been ordered but not delivered.
DELL = VendorID ( HVName=DELL
(Vendor * HardwareVendors))
HVendorID
ANS = PONumber, PODate, POCost ( DeliveredDate=Null
DELL * Inventory)
VendorID

4. Problem 2 - ER Specialization (Spr15)
Each Specialization was worth 5 pts – deductions for
Not indicating Total
Not supplying attributes
Most Popular Answers:
Disjoint: Inventory with Computer, Accessory, and Software as Children
Overlap Vendor with HWVendor and SWVendor as Children
Union:
Accessory m
Software
Computer 1 m u 1
DeployedPC

5. Problem 3- Functional Dependencies (Spr15)
Computer( CInventNum, ComputerName, ComputerType, AccID);
CInventNum  ComputerName, ComputerType
CInventNum, AccID  ComputerName, ComputerType
Inventory( InvenNum, SerialNum, PONum, PODate, DeliveredDate, POCost, VendorID);
PONum  InventNum, SerialNum, PODate, DeliveredDate, etc.
InventoryNum  SerialNum (or some other one not involving PO)
SoftwareVendor (SVendorID, SVName, SVAddr, SWName, SWVersion, SWDesc);
SVendorID  SVName, SVAddr
SVendorID, SVName, SWName, SWVersion SWDesc, SWAddr
SVendorID   SWName (first two basically equivalent)
SVName   SWName
SWName   SWVersion

6. Prob 4 – Relational Schema Analysis (Spr15)
Computer( CInventNum, ComputerName, ComputerType, AccID);
Insert - For a new computer, you must always insert an accessory (since it is part of the key). If there are N accessories, there are N rows for each computer.
Update – if you change the Name or Type, you must change all N tuples.
Delete - No obvious delete anomalies.
Conclusion: Computer represents two different entities (Guideline 1) – the computer and its accessories, and as a result, violates Guideline 2 in regards to insert anomalies. A better design would separate accessories in a similar manner to the Installed Software table.
Accessory( AccID, AInventNum, HVendorID, AccName, AccType, AccSize);
From an inventory control perspective, there is no way to track the total number of each accessory that has been purchased. You may have 10 USB 120 Gig external hard drives, and each one would have its own AccID and AIventNum. The other problem is related to Guideline 3 due to null values for AccSize (limited problem).
Insert, Delete, and Update: No obvious anomalies.
Conclusion: The table is OK – but it could be improved by separating out the different types of accessories (that have been purchased). It may also make sense not to track this at all in their gory detail – many companies (UConn included) don’t track equipment that is less than $1000, and many of these fit into that category.

7. Prob 4 – Relational Schema Analysis (Spr15)
Software( SInventNum, SVendorID, SWName, SWVersion);
The only real problem in this table is that SVendorID, SWName, and SWVersion are foreign keys into the SoftwareVentor table, and as a result, this information is replicated in both tables.
Conclusion: There may be a better way to design the Software, Installed Software, and SoftwareVendor tables, particularly in regards to reducing the key size (and hence the foreign key linkages).
Inventory(InvenNum, SerialNum,
PONum, PODate, DeliveredDate, POCost, VendorID);
This table suffers violates two guidelines: Guideline 1 in regards to representing two different entities (inventory and purchase orders), and Guideline 3 in regard to an excessive amount of null values.
Insert, Delete, and Update: No obvious anomalies.
Conclusion: Split into two different tables: Inventory (InvenNum, SerialNum, PONum) and PurchaseOrder (PONum, PODate, DeliveredDate, POCost, VendorID) which will address Guideline 1 and will not result in a Inventory tuple until the item is actually received. DeliveredDate will still be null for all outstanding orders.

8. Prob 4 – Relational Schema Analysis (Spr15)
InstalledSoftware( CInventNum, SWInventNum);
Vendor( VendorID, HWFlag, HWVendorID, SWFlag, SWVendorID);
InstalledSoftware is dealing with two foreign key references to the Computer and Software tables, respectively. Vendor is allowing us to unify the different ID tracking systems for software and hardware vendors. The only problem with Vendor is that there are potentially null values for companies that sell either hardware or software but not both. You could argue that the flags are not needed in Vendor as well, since the null values (or not-null) has this information.
Conclusion: In the case of Vendor (and VendorID, SVendorID, HVendorID), this may be a poor design and if the database has not been deployed, it may make sense
to totally redesign this identifier to have a single identifier. This would allow the Vendor table to be eliminated. This would separate vendor common information
into a single Vendor (VendorID, VName, VAddr). This would eliminate the null value (Guideline 3) problem of Vendor.
Thus, changes to Vendor would impact both the HardwareVendor and SoftwareVendor Tables.

9. Prob 4 – Relational Schema Analysis (Spr15)
HardwareVendor ( HVendorID, HVName, HVAddr, ModelNum, ModelName, ModelDescr);
SoftwareVendor (SVendorID, SVName, SVAddr, SWName, SWVersion, SWDesc);
Both tables have insert anomalies (can’t insert HWV or SWV without inserting a product), delete anomalies (if you delete the last item for a vendor you delete the vendor), and update anomalies (if you change an address, or a name – buyout, you need to change multiple tuples) – Guideline 2 is a real issue in this regard.
Both tables are representing two different entities: the contact information for a vendor (id, name, and address) and the vendors products – violating Guideline 1 for having a relation only represent a single entity. As a result, the keys are convoluted – you need to have a ModelNum for HardwareVendors and a compound key for SoftwareVendors; this makes the foreign key references more complicated.
Conclusion: As mentioned, redesign the tables Vendor, HWVendor, and SWVendor to pull out their commonalities and unify the identifier. Use Vendor as defined on the previous slide, use VendorID in the HWVendor and SWVendor tables while dropping Name and Addr from those tables.

10. Problem 1a - Relational Algebra (Fa15)
List the full names of all mens players that have/had the uniform number 5. 3pts
PL = PLName, PFName ( UniformNumber=5 (PLAYER))
½ pt
MT = TeamID ( Squad=‘Mens’ (TEAM))
½ pt
ANS1a = PLName, PFName (PL * ( MT * ROSTERS))
1 pt
1 pt

11. Problem 1b - Relational Algebra (Fa15)
List the full names and points per game of all mens players that averaged more than 20 points per game and at least 5 rebounds per game in one year on teams with winning regular season records. 4pts
MT = TeamID ( Squad=‘Mens’ (TEAM))
1 pt
WR = TeamID ( Wins > Losses (RSRECORD * MT ))
1 pt
PL = ( PPG > 20 and RPG  5 (STATISTICS * WR ))
1 pt
ANS1b = PLName, PFName, PPG (PT * PLAYER)
1 pt

12. Problem 1c - Relational Algebra (Fa15)
List the full names and uniform numbers of all womens players that played for Geno Auriemma in pts
WT = TeamID ( Squad=‘Womens’ and Year =1996 (TEAM ))
1 pt
GAP = ( CLName=‘Auriemma’ (ROSTERS * WT))
1.5 pts
1.5 pts
ANS1c = PLName, PFName, UniformNumber (PLAYER*GAP)

13. Problem 1d - Relational Algebra (Fa15)
List the full names of all mens players who played on a team with a losing regular season record coached by Jim Calhoun. 4pts
MT =  Squad=‘Mens’ and Wins < Losses (TEAM * RSRECORD))
1 pt
MP = ( PlayerPersonID  CLName=‘Calhoun’ (ROSTERS * MLT))
1.5 pts
ANS1d = PLName, PFName (PLAYER*MP)
1.5 pts

14. Problem 2 – Relation to EER
Team – 2 pts
Person Hier – 3 pts
Record Hier – 3 pts
Rosters Relat – 3pts
Titles Relat – 2pts
Stats Relat – 3pts
Record
Wins
Losses
RSRecord
PORecord  d 1
Player
NumYrs
Uniform#
Person
PersonId
Lname
Fname
StartYr 
has o 
Coach
EndYear 1 1 m
Team
TeamID
Year
Squad n k
Rosters n
Statistics 1 n
Deductions for
Misplaced attributes Missing Attributes
Missing 1, n, m, k
Wrong d and o
Titles
PPG
TitleType
RPG
APG

15. Problem 3 - Update Anomalies (Fa15)
4pts
No Modify Anomaly - only one entry per player/coach (unique LNames)
Insert Anomaly - Player in past can’t be coach in future - Player or coach leaves for 1 (or more years) and then returns - no way to store his/her return.
No Delete Anomaly-only one entry per player/coach (unique LNames)
Note: Lots of null values due to capturing two types of people.
2pts if mention guideline 1 (not single entity)
2pts if mention null values
2pts if player/coach insert anomaly
Up to at most 4pts

16. Problem 3 - Update Anomalies (Fa15)
6pts
There are numerous problems for this table, since many values are replicated.
For Example, teams that win multiple titles (NCAA and BigEastRS) must have each player and coach listed twice to capture this data. If you insert a player for a past team (that was omitted), you would have to make sure you inserted the player for all Titles of TeamID.
Specifically: Insert: Can’t have a Team without having a player. Can’t have TitleType unless there is a Team with that title Delete: Last Player on a team - loose the team Modify: Change PLName, impact all TeamIDs for the player
Basically - I looked for reasoning and a solid argument for this table.
2pts per issue – up to three issues – including others if the argument is OK.

17. Problem 3 - Update Anomalies (Fa15)
Modify Anomaly - Whenever RSWins or RSLosses is modified (for a win or a loss), TTLWins or TTLLosses must be incremented.
No Insert Anomaly - only one entry per team.
No Delete Anomaly - no information is lost on anything but the team.
3pts
Looking for the key anomaly re. dependencies among totals
Accepted other answers for partial credit
No Modify Anomaly - PPG, RPG, and APG are independent of one another and no values in common across different players.
No Insert Anomaly - only one entry per player.
No Delete Anomaly- no information is lost on anything but the player.
2pts
Need to give at least a reason or only 1pt if just say NONE.

18. Problem 4 - Functional Dependencies (Fa15)
LName  FName, StartYear
LName, PFlag  NumYears, UniformNumber
a. 4pts
LName, CFlag  EndYear
Year, Squad  CLName
a. 2pts
CLName  TitleType
TeamID  Year, Squad
b. 2pts
PLName  TitleType
CLName  TeamId, Year, Squad
b. 3pts
TeamID, Year, Squad  TitleType
TeamID, Year, Squad  PLName

19. Problem 4 - Functional Dependencies (Fa15)
TeamID  RSWins, RSLosses, TTLWins, TTLLosses
a. 1 pts
PLName, TeamID  PPG, RPG, APG
a. 1 pts
PLName   PPG, RPG, APG
PLName   TeamID
b. 3pts
TeamID   PLName

20. Problem 5 (Fa15) - Normalization
NBAPLAYER( Name, Year, Coach, Team, State, Salary)
2NF Team Depends on {Year, Name} which is part of key Name, Year, Coach
Salary Depend on Coach which is part of key Name, Year, Coach
5pts NBAPLAYER1(Name, Year, Coach, Salary)
4pts NBAPLAYER2(Name, Year, Team, State)
Need to Not Break out Coach, Salary into one table, since Coach maps to different salaries (Clinton has 800,000, 700,000, and 1,000,000)
Name, Year, Coach  Team, State, Salary
Coach  Salary
Name, Year  Team; Team  State
3NF – Look at NBAPLAYER2 TABLE
For Team  State – State depends on Team which is NOT part of a key
Transitive from Name,Year to Team to State
3pts NBAPLAYER2a(Name, Year, Team)
3pts NBAPLAYER2b(Team, State)
Name, Year  Team; Team  State