advanced design copyright 1995 technology mentors inc. workshop-1 relational database design...

Advanced Design Copyright 1995 Technology Mentors Inc.

WORKSHOP-1

Relational Database Design Workshop

©Copyright Technology Mentors Inc. 1995

All rights reserved. No part of this material may be reproduced, stored in a retrieval system, or transmitted in

any form or by any means, electronic, mechanical, photographic, or otherwise, without the written permission

of the copyright owner.


WORKSHOP-2

Table of Contents

Basic Analysis......................................2Advanced Analysis.............................16Basic Relational Design......................31Advanced Relational Design...............47


WORKSHOP-3

1. Basic Analysis


WORKSHOP-4

1. Problem Statement

Develop a basic analysis for the Frenzy Department of Motor Vehicles from interviews, as follows:

(a) Steps E1 and E3. Read the requirements statement on pages four through six and make a list of entities. Specify a primary key for each entity. If the requirements do not mention a primary key, invent a surrogate key.

(b) Step R1. Now review the requirements statement a second time. Make a list of relationships, and specify which entities they relate.

(c) Draw a diagram of entities and relationships.

(d) Step R3. Determine the maximum and minimum cardinality of each relationship. Write your answers directly on the diagram of problem (c).

(e) Step A1, A2, A4. In your third and final review of the requirements, list all attributes and assign them to entities and relationships. Develop a list of standard domains, and use them in attribute names.

(f) Step A3. Specify maximum , minimum, and maximum per value cardinality for each attribute. Write your answers directly on the diagram of problem (e).

(g) Step A4. Two attributes are homonyms. Which are they? For clarity, revise one or both of the names.

(h) Steps E1 and A1. EXAM_SCORE has an attribute CENTER_NAME. Should there also be a CENTER entity? Discuss.

(optional) Steps E5, R5, A5. Write a complete description for several entities, relationships, and attributes.


WORKSHOP-5

Requirements StatementThe Department of Motor Vehicles (DMV) for the State of Frenzy

is developing a new database, to support three related functional areas:

• Vehicle Registration

• Driver Licensing

• Tracking of Accidents and Violations

The following requirements have been specified, based on interviews with key staff and a review of DMV documents.

Vehicle RegistrationThe vehicle registration unit of the DMV tracks data on

automobiles, busses, motorcycles, trucks, aircraft, and boats. Every vehicle has a year, make, model, and manufacturer’s ID number stamped on the engine block. The manufacturer’s ID is usually referred to as the VIN (vehicle identification number) by DMV staff. Most vehicles have license plates, with the exception of aircraft and boats.

In Frenzy, vehicles are registered annually; the DMV must record the most recent registration date, full name and mailing address of owner(s), and sales price of the vehicle. Annual registration fees are calculated as the greater of $30 or 4% of sales price.


WORKSHOP-6

Driver Licensing

The DMV administers vehicle operator exams, and maintains license records. Each exam consists of five parts - parallel parking, U-turn, Y-turn, use of turn signals, and speed control. A rating of 0 to 100 is assigned by the administering officer, except for the speed control portion, which is rated on a scale of 30.

Vehicle operators occasionally fail the exam several times before passing. Each person is allowed only one attempt per day. Full historic records of exams, both passed and failed, must be stored. The DMV tracks the name of the DMV center administering each exam, as well as the responsible police officer, for internal statistical analysis.

The DMV maintains a list of all Frenzy police officers, by badge number, police department, rank, and name. Frequently there are duplicate badge numbers between departments (and sometimes even within a department), so badge number is not sufficient to identify officers; rank and department are also necessary.

When a new driver passes an exam, his full name, address, date of birth, hair and eye color are entered to the system. The operator is issued a driver’s license, and an expiration date (usually four years from the date of issue) is recorded. Driver’s licenses are issued with one or more authorization codes, such as ‘M’ (motorcycle), ‘CF’ (commercial/freight), or ‘CP’ (commercial/passenger). Occasionally a license number is assigned with no authorization - for example, for those who have taken the exam but not yet passed.


WORKSHOP-7

Tracking of Accidents and Violations

The Records Bureau of the DMV maintains historic lists of all accidnets and most violations reported in Frenzy.

An accident report is written by an officer at the scene, and includes names and license numbers of all involved drivers, and the license plate numbers of their vehgicles. Officers also describe any damage to each vehicle or injury to the fdriver. If a vehicle or driver is out-of-state, the state of registry is documented. If the officer suspects drunk driving, he may administer a sobriety test and note the level of alcohol in the driver’s bloodstream. The accident report also notes date, time, location, weather conditions (visibility, precipitation, road conditions), and a narrative description of the circumstances of the accident.

In addition, the DMV records all violations of State of Frenzy Traffic Code, including speeding tickets, parking tickets, drunk driving, and the like.

Information on violations is entered by DMV clerks from tickets, which list the citation number, officer, date, time, location, license plate number, and state of registration. if a driver is present (for example, a speeding ticket), the policeman notes driver’s license number, name, and occasionally administers a sobriety test. Occasionally a violation involves damage to the vehicle, which is described on the ticket and transferred to the DMV databse. If a violation causes a vehicle to be towed, the name of the towing company is recorded for the benefit of the owner. For some violations, ‘points’ are recorded in the database and charged against the driver’s record. All violations are cited against sections of the Frenzy State Traffic Code.

STOP!

End of requirements statement - solutions follow...


WORKSHOP-8

Solution 1(a) - Entities and Primary Keys

ACCIDENTLOCATION(?)

DATE(?)TIME(?)

EXAM_SCORELICENSE NUMBER

DATE

LICENSELICENSE NUMBER

OFFICERBADGE NUMBER

DEPARTMENT NAMERANK CODE

OPERATORLICENSE NUMBER

OWNERFULL NAME(?)

VEHICLEVIN

VIOLATIONCITATION NUMBER


WORKSHOP-9

Solution 1(b) - Relationships

OWNER - OWN - VEHICLE

OPERATOR - PARTICIPATE_IN - ACCIDENT

VIOLATION - INVOLVE - VEHICLE

ACCIDENT - INVOLVE - VEHICLE

OPERATOR - CAUSE - VIOLATION

OPERATOR - SCORE - EXAM_SCORE

OFFICER - ADMINISTER - EXAM_SCORE

OFFICER - CITE - ACCIDENT

OFFICER - CITE - VIOLATION

OPERATOR - HOLD - LICENSE


WORKSHOP-10

Solution 1(c) - Basic Analysis Diagram

OWN

INVOLVE

HOLD

ACCIDENT

CITE

CAUSE

SCORE

PARTICIPATE_INVIOLATION

CITE

INVOLVE

OWNER VEHICLE

OFFICER

LICENSE

OPERATOR

EXAM_SCORE

ADMINISTER


WORKSHOP-11

1(d) Relationship Cardinality

OWN

INVOLVE

HOLD

ACCIDENT

CITE

CAUSE

SCORE

PARTICIPATE_INVIOLATION

CITE

INVOLVE

OWNER VEHICLE

OFFICER

LICENSE

OPERATOR

EXAM_SCORE

ADMINISTER

11

1

M(0)

1

1

1

M

M MM M

M 1(0)M(0)

M(0)

M(0)

M(0)M(0)

1(0)


WORKSHOP-12

Solution 1(e) - Standard Domains

DESC(DESCRIPTION)

NAME

QTY(QUANTITY)

SCORE

PERCENT

COLOR

CODE

COST

DATE(YEAR, MONTH, DAY)

DATETIME(YEAR, MONTH, DAY, HOUR, MINUTE)

FULL_NAME(FIRST_NAME, MIDDLE_NAME, LAST_NAME, SUFFIX_CODE)

ADDRESS(STREET_DESC, CITY_NAME, STATE_CODE, ZIP_CODE)


WORKSHOP-13

Solution 1(e) - Attributes

OWNERFULL NAMEADDRESS OWN

INVOLVEDAMAGE_DESC

INVOLVEDAMAGE_DESCTOWCOMPANY_NAME

CITE CITE

ADMINISTER

SCORE

HOLD

CAUSEALCOHOL_PERCENTPOINTS_QTY

PARTICIPATE_ININJURY_DESCALCOHOL_PERCENT

OPERATORLICENSE NUMBERFULL_NAMEADDRESSBIRTH_DATEHAIR_COLOREYE_COLOR

VIOLATIONCITATION NUMBERTYPE_CODEDATETIMELOCATION_DESCSECTION_NUMBER

ACCIDENTDATETIMELOCATION DESCVISIBILITY_CODEPRECIPITATION_CODEROAD_CODEREPORT_DESC

OFFICERBADGE NUMBERDEPARTMENT NAMERANK CODEFULL_NAME

VEHICLEVINYEARMAKE_CODEMODEL_NAMELICENSE_NUMBERSTATE_CODEREGISTRATION_DATESALES_COSTREGISTRATION_COST

LICENSELICENSE NUMBERAUTHORIZATION_CODEEXPIRATION_DATE

EXAM_SCORELICENSE NUMBEREXAM DATECENTER_NAMEPARALLEL_SCOREUTURN_SCOREYTURN_SCORESIGNAL_SCORESPEED_SCORE


WORKSHOP-14

Solution 1(f) - Attribute Cardinality


INVOLVEDAMAGE_DESC (0)

INVOLVEDAMAGE_DESC (O)TOWCOMPANY_NAME (O)

CITE CITE

ADMINISTER

SCORE

HOLD

CAUSEALCOHOL_PERCENT(O)POINTS_QTY

PARTICIPATE_ININJURY_DESC(O)ALCOHOL_PERCENT(O)





VEHICLEVINYEARMAKE_CODEMODEL_NAMELICENSE_NUMBER (O)STATE_CODE (O)REGISTRATION_DATESALES_COSTREGISTRATION_COST

LICENSELICENSE NUMBERAUTHORIZATION_CODE (M,O)EXPIRATION_DATE



WORKSHOP-15

Solution 1(g) - Homonyms

The attributes LICENSE_NUMBER of entities OPERATOR and VEHICLE are homonyms. They have the same name but different meanings (‘driver’s license’ vs. ‘license plate’), which might easily create confusion and errors. Rename the VEHICLE attribute as PLATE_NUMBER for clarity, and always use the term ‘plate’ rather than ‘license’ in conversation.


WORKSHOP-16

Solution 1(h) - Entity vs. Attribute

The requirements statement requested only that the name of a DMV center be recorded for every exam score. A name is a ‘piece of data’, or in other words, an attribute.

If additional information were required for DMV centers, such as the name of the manager, location, and budget, then an entity CENTER would be necessary. If you anticipate this requirement in the future, it makes sense to create the entity now.


WORKSHOP-17

2. Advanced Analysis


WORKSHOP-18


Apply the advanced analysis steps. Begin with the diagram on the next page.

(a) Step E2. Find the dependent entity in the basic analysis diagram

(b) Step E7. Create new superentities around similar entities in the basic analysis diagram. Reassign common relationships and attributes to the superentity. Review and revise primary keys of the super- and subentities.

(c) Steps E2, E7, A9. Read the additional requirements statement on page 21. What new subentities can you find? Are any of these ‘similar’? Consider converting optional attributes to subentities. Document your solution in a diagram of VEHICLE and its subentities.

(d) Step E8. Organize the new subentities from (c) into classes. Document the classifying attributes (create a new one if necessary).

(e) Step R2. Occasionally a violation, such as drunk driving, is cited at the scene of an accident. Although the DMV does not pass judgement on responsibility, it wants to relate violations and accidents in this way. How?

(f) Step R8. Should we model INVOLVE as a relationship or an entity INVOLVED_VEHICLE? Discuss

(g) Step R8. One of your data analysts reviews the basic analysis and suggests that ‘the EVENT entity should have a BADGE_NUMBER attribute, so that we can determine the presiding officer, and a PLATE_NUMBER attribute, to document all involved vehicles’. Discuss.

(h) Step A7. Can you find an indirect attribute in the diagram on page 20? Reassign it to another entity. Beware, this is a tricky problem!

(i) Step A8. Review the requirements statement on pages 4 to 6 for derivable attributes and document the derivation formula.

(j) Draw a new diagram of entities and relationships to reflect the advanced analysis, (a) through (i) above.

(k) Steps E6 and R6. Which of the entities and relationships in (j) include past or future states? Should any changes be made in this regard?

(optional) Step E2. What additional subentities and subentity classes might we anticipate some day for PERSON, VEHICLE, and EVENT? Should we model OFFICER as a subentity of PERSON? Discuss.

(optional) Steps R2, R8. A new requirement has been stated: “The DMV must now be able to determine the driver of each vehicle in an accident.” Remember, an accident may involve several vehicles and drivers. How is this new requirement modeled?


WORKSHOP-19

2. Starting Diagram for Advanced Analysis


INVOLVEDAMAGE_DESC


CITE CITE

ADMINISTER

SCORE

HOLD











WORKSHOP-20

Solution 2(a) - Dependent Entities


INVOLVEDAMAGE_DESC


CITE CITE

ADMINISTER

SCORE

HOLD











WORKSHOP-21

Solution 2(b) - Similar Entities

OWNER

OWN


CITE

ADMINISTER

HOLD

PARTICIPATE_ININJURY_DESCALCOHOL_PERCENTPOINTS_QTY

OPERATORBIRTH_DATEHAIR_COLOREYE_COLOR




EXAM_SCOREPERSON IDEXAM DATECENTER_NAMEPARALLEL_SCOREUTURN_SCOREYTURN_SCORESIGNAL_SCORESPEED_SCORE

SCORE

PERSONPERSON IDFULL_NAMEADDRESS

VIOLATIONCITATION NUMBERTYPE_CODESECTION_NUMBER


EVENTEVENT_IDDATETIMELOCATION_DESC


WORKSHOP-22

2(c) - Additional Requirements

Specific kinds of vehicles have special data requirements. The DMV must record teh displacement and engine class (diesel, gas, sail) of boats. Manufacturer’s horsepower rating and date of last emissions check are recorded for all busses, trucks, autos, and motorcycles. The number of axles of busses and trucks must be maintained for calculation of the annual commercial highway tax. The DMV tracks the home airp[ort and Federal Aviation Administration code of each airplane, but does not record accidents or violations for boats or aircraft.

For taxis, commercial airplanes, municipal busses and ferry boats, the DMV also issues and records an eight-character ‘medallion’ number, the date of most recent inspection, and vehicle capacity (maximum number of passengers). Special authorization is required to operate commercial vehicles such as taxis and busses.


WORKSHOP-23

Solution 2(c) - New Subentities

OWN

OWNER EVENT

INVOLVE

VEHICLEVINYEARMAKE_CODEMODEL_NAMEPLATE_NUMBERSTATE_CODEREGISTRATION_DATESALES_COSTREGISTRATION_COST

AIRCRAFTAIRPORT_NAMEFAA_CODE

BOATDISPLACEMENT_QTYENGINE_CODE

PUBLIC_VEHICLEMEDALLION_CODEINSPECTION_DATECAPACITY _QTY

GROUND_VEHICLEHORSEPOWER_QTYEMISSIONS_DATEAXLE_QTY

AUTO

BUS

TRUCK

MOTORCYCLE


WORKSHOP-24

Solution 2(d) - Classes and Classifying Attributes

OWN

OWNER EVENT

INVOLVE




PUBLIC_VEHICLEMEDALLION_CODEINSPECTION_DATECAPACITY _QTY


AUTO

BUS

TRUCK

MOTORCYCLE

COMMERCIAL_CLASS

PRIVATE_VEHICLE


WORKSHOP-25

Solution 2(e) - Recursive Relationships

An obvious solution is to add a relationship VIOLATION-CAUSE-ACCIDENT. This meets the requirement, but it is somewhat inflexible. It does not support unanticipated requirements, such as accidents causing accidents, or new subentities such as VEHICLE_THEFT. A more general solution is the recursive relationship EVENT-CAUSE-EVENT. We might add a code or descriptive attribute to this relationship for more detail.

CAUSE

EVENT

ACCIDENT

VIOLATION

EVENT

ACCIDENT

CAUSE

VIOLATION


WORKSHOP-26

Solution 2(f) - Relationship or Entity?

We could create an entity called INVOLVED_VEHICLE instead of the relationship INVOLVE. However the primary key of this entity would be (EVENT_ID, VIN), since both attributes are necessary to identify a specific vehicle involved in a particular event. Step R8 states that if the primary key consists only of other primary keys, it is a relationship. Thus we use the relationship INVOLVE in this case, not an entity.


VEHICLE EVENT

EVENTVEHICLE INVOLVED_VEHICLEEVENT IDVINDAMAGE_DESCTOWCOMPANY_NAME


WORKSHOP-27

Solution 2(g) - Relationship or Attribute?

An attribute BADGE_NUMBER under EVENT represents the officer who cited the event. However this requiremtn is already modeled in the relationship CITE. As step R8 states, attributes which designate entities are actually relationships. In other words, do not adda BADGE_NUMBER attribute under EVENT, because it is redundant to the OFFICER-CITE-EVENT relationship.

Similarly, a PLATE_NUMBER attribute of EVENT is equivalent to the EVENT-INVOLVE-VEHICLE relatinship, and should not be included in the diagram.


WORKSHOP-28

Solution 2(h) - Indirect Attributes

In Frenzy, the points charged to a driver for a violation depend only on the relevant section of the Traffic Code. It has nothing to do with the person in question or the time and location of the event. Consequently, the POINTS_QTY attribute depends indirectly on the PARTICIPATE_IN relationship and should be reassigned. In this case we must create a new SECTION entity:

PERSONPARTICIPATE_ININJURY_DESCALCOHOL_PERCENT

VIOLATE

SECTIONSECTION_NUMBERPOINT_QTY

EVENT

ACCIDENT

VIOLATIONCITATION_NUMBERTYPE_CODE


WORKSHOP-29

Solution 2(i) - Derivable Attributes

The requirements state that “registration fees are calculated as the greater of $30 or 4% of sales price.” Thus the REGISTRATION_COST attribute of VEHICLE is derivable. This formula should be documented in the dictionary. The attribute should be calculated, not stored in a table, unless performance is a problem.


WORKSHOP-30

Solution 2(j) - Final Diagram

OWNINVOLVEDAMAGE_DESCTOWCOMPANY_NAME


CAUSE


ACCIDENTVISIBILITY_CODEPRECIPITATION_CODEROAD_CODEREPORT_DESC


HOLD SCORE

LICENSELICENSE_NUMBERAUTHORIZATION_CODEEXPIRATION_DATE

EXAM_SCOREPERSON_IDEXAM_DATECENTER_NAMEPARALLEL_SCOREUTURN_SCOREYTURN_SCORESIGNAL_SCORESPEED_SCORE

ADMINISTER

CITE VIOLATE

OFFICERBADGE_NUMBERDEPARTMENT_NAMERANK_CODEFULL_NAME

SECTIONSECTION_NUMBERPOINTS_QTY


VEHICLE_CLASS COMMERCIAL_CLASS

PUBLIC_VEHICLEMEDALLION_CODEINSPECTION_DATECAPACITY_QTY

PRIVATE_VEHICLE




MOTORCYCLE

AUTO

BUS

TRUCK

PERSONPERSON_IDFULL_NAMEADDRESS

OWNER OPERATORBIRTH_DATEHAIR_COLOREYE_COLOR


WORKSHOP-31

Solution 2(k) - Past and Future States

The following entities model both past and present states:

• EXAM_SCORE

• EVENT

• ACCIDENT

• VIOLATION

(ACCIDENT and VIOLATION inherit the DATETIME attribute of EVENT.)

All other entites and relationships model present states only.

Any of these could model past states - it is simply a matter of what information the DMV wants to track. For example, the DMV might record historic ownership information by adding START_DATE and END_DATE attributes to the OWN relationship. It might record historic address information with the composite plural attribute (ADDRESS, EFFECTIVE_DATE) of the PERSON entity. If there are changes to point penalties of the Traffic Code, it may be necessary to add EFFECTIVE_DATE attributes to SECTION.


WORKSHOP-32

3. Basic Relational Design


WORKSHOP-33


Develop a basic relational design using steps T, K, and C. Begin with the diagram on the following page. (Derivable attributes and entities without attributes have been deleted.

(a) Step K1. Implement all the many-one relationships as foreign keys, by marking foreign keys on the diagram.

(b) Step K3 and C4. Implement many-many relationships and their attributes by drawing new tables and marking foreign keys on the diagram.

(c) Step K2. Suppose we add a relationship OFFICER-BE-PERSON, so that the DMV can determine which officers have been cited for drunk driving. Maximum cardinality of BE is one-one. Which table gets the foreign key?

(d) Step K2. Implement all one-one relationships by marking foreign keys on the diagram. Don’t forget the ISA relationships between sub- and superentities!

(e) Step C1. Implement plural attributes on the diagram.

(f) Steps T1, T2, T3, K3. Write SQL to create the following tables. Include primary keys, foreign keys, and foreign key rules.

EVENT (independent table)

EXAM_SCORE (dependent table)

INVOLVE (associative table)

OPERATOR (subtable)

(g) step T4. For this exercise, we add attributes to tables as follows:

For each of these tables, draw the dependency diagram. What normal form is the table in? If the table is not in 3NF, how can 3NF best be achieved?

(h) Step C1, Fourth Normal Form. Suppose attributes PRECIPITATION_CODE and ROAD_CODE of ACCIDENT were plural-several codes may apply to a single accidnet, such as ‘rain’ and ‘fog’. Implement the revised ACCIDENT entity. (Draw a table diagram for the basic relational design.)

PERSONPERSON_IDFULL_NAMESTREET_DESCCITY_NAMESTATE_CODEZIP_CODE

PARTICIPATE_INPERSON_IDEVENT_IDINJURY_DESC (0)ALCOHOL_PERCENT (0)LICENSE_NUMBERFULL_NAME

INVOLVEVINEVENT_IDDAMAGE_DESC (0)TOWCOMPANY_NAME (0)PLATE_NUMBER


WORKSHOP-34

Starting Diagram for Basic Relational Design

OWN

INVOLVEDAMAGE_DESC (0)TOWCOMPANY_NAME (0)

PARTICIPATE_ININJURY_DESC (0)ALCOHOL_PERCENT (0)

CAUSE




HOLD SCORE


ADMINISTER

CITE VIOLATE



VEHICLEVINYEARMAKE_CODEMODEL_NAMEPLATE_NUMBERSTATE_CODE (0)REGISTRATION_DATESALES_COSTREGISTRATION_COST



PRIVATE_VEHICLE




MOTORCYCLE

AUTO

BUS

TRUCK



LICENSELICENSE_NUMBERAUTHORIZATION_CODE (M,0)EXPIRATION_DATE

M(0)

M(0)M(0)

M(0) M(0)

M(0) M(0)

M(0)

M(0)

1

1 1

1(0)

M

1

1

1

M


WORKSHOP-35

Solution 3(a) - Many-One Relationships

OWN

INVOLVEDAMAGE_DESC (0)TOWCOMPANY_NAME (0)

PARTICIPATE_ININJURY_DESC (0)ALCOHOL_PERCENT (0)

CAUSE




HOLD SCORE


ADMINISTER

CITE VIOLATE






PRIVATE_VEHICLE




MOTORCYCLE

AUTO

BUS

TRUCK




M(0)M(0)

M(0) M(0)

M(0)

M

1

1X

X

X

X

X

o


WORKSHOP-36

Solution 3(b) - Many-Many Relationships













CAUSE




ADMINISTER

CITE VIOLATE

X

X

X

X

o

PARTICIPATEPERSON_IDEVENT_IDINJURY_DESC (0)ALCOHOL_PERCENT (0)

OWNVINPERSON_ID

X

XINVOLVEVINEVENT_IDDAMAGE_DESC (0)TOWCOMPANY_NAME (0)

X

XX

XX

1

1

HOLD SCORE


WORKSHOP-37

Solution 3 (c) - One-One Relationships

Rule K2 states that, for one-one relationships, the foreign key goes in the table with fewer rows. In this case there are far fewer officers than people, so OFFICER would get a foreign key PERSON_ID in the basic relational design.


WORKSHOP-38

Solution 3(d) - One-One Relationships









LICENSELICENSE_NUMBEREXPIRATION_DATE




CAUSE




ADMINISTER

CITE VIOLATE

X

X

X

X

o


OWNVINPERSON_ID

X


X

XX

XX

X

X

X

X

X

X

X

HOLD SCORE

X


WORKSHOP-39

Solution 3(e) - Plural Attributes













CAUSE




ADMINISTER

CITE VIOLATE

X

X

X

X

o


OWNVINPERSON_ID

X


X

XX

XX

X

X

X

X

X

X

X

HOLD SCORE

X

LICENSE_AUTHORIZELICENSE_NUMBERAUTHORIZATION_CODE

X


WORKSHOP-40

Solution 3(f) - SQL for EVENT

create domain EVENT_TYPE integer

create domain TEXT varchar(200)

create domain NAME varchar(25)

create domain CODE char(5)

create table EVENT (

primary key (EVENT_ID)

foreign key ( CAUSE_EVENT_ID identifies EVENT delete of EVENT nullifies update of EVENT restricted)

foreign key ( (BADGE_NUMBER, DEPARTMENT_NAME, RANK_CODE) identifies OFFICER delete of OFFICER nullifies update of OFFICER cascades)

create unique index EVENT on EVENT(EVENT_ID)

EVENT_IDDATETIMELOCATION_DESCBADGE_NUMBERDEPARTMENT_NAMERANK_CODECAUSE_EVENT_ID

EVENT_TYPEDATETIMETEXTINTEGERNAMECODEEVENT_TYPE)

not null,not null,not null,not null,not null,not null,


WORKSHOP-41

Solution 3(f) - SQL for EXAM_SCORE

create domain PERSON_TYPE integer


create domain CODE char(5)

create table EXAM_SCORE (

primary key (PERSON_ID, EXAM_DATE)

foreign key ( PERSON_ID identifies PERSON delete of PERSON cascades update of PERSON restricted)

foreign key ( (BADGE_NUMBER, DEPARTMENT_NAME, RANK_CODE) identifies OFFICER delete of OFFICER nullifies update of OFFICER cascades)

create unique index EXAM_SCORE on EXAM_SCORE(PERSON_ID, EXAM_DATE)

PERSON_IDEXAM_DATECENTER_NAMEBADGE_NUMBERDEPARTMENT_NAMERANK_CODEPARALLEL_SCOREUTURN_SCOREYTURN_SCORESIGNAL_SCORESPEED_SCORE

PERSON_TYPEDATETIMENAMEINTEGERNAMECODESMALLINTSMALLINTSMALLINTSMALLINTSMALLINT

not null,not null,not null,not null,not null,not null,not null,not null,not null,not null,not null)


WORKSHOP-42

Solution 3(f) - SQL for INVOLVE

create domain VEHICLE_TYPE integer

create domain EVENT_TYPE integer


create domain TEXT varchar(200)

create table INVOLVE (

primary key (VIN, EVENT_ID)

foreign key ( VIN identifies VEHICLE delete of VEHICLE cascades update of VEHICLE restricted)

foreign key ( EVENT_ID identifies EVENT delete of EVENT cascades update of EVENT restricted)

create unique index INVOLVE on INVOLVE(VIN, EVENT_ID)

VINEVENT_IDDAMAGE_DESCTOWCOMPANY_NAME

VEHICLE_TYPEEVENT_TYPETEXT,NAME)

not null,not null,


WORKSHOP-43

Solution 3(f) - SQL for OPERATOR

create domain PERSON_TYPE integer

create domain COLOR char(10)

create table OPERATOR (

primary key (PERSON_ID)

foreign key ( PERSON_ID identifies PERSON delete of PERSON cascades update of PERSON restricted)

foreign key ( LICENSE_NUMBER identifies LICENSE delete of LICENSE restricted update of LICENSE restricted)

create unique index OPERTOR on OPERATOR(PERSON_ID)

PERSON_IDLICENSE_NUMBERBIRTH_DATEHAIR_COLOREYE_COLOR

PERSON_TYPEINTEGERDATETIMECOLORCOLOR

not null,not null,not null,not null,not null)


WORKSHOP-44

Solution 3(g) - INVOLVE Table

This table is in 1NF, but not 2NF, because the PLATE_NUMBER column depends on VIN only, not on the entire primary key. This introduces redundancy when the same vehicle is involved in several events. The redundancy causes potential anomalies and performance problems on update.

To achieve 3NF, remove PLATE_NUMBER and place it in a separate table. (In fact it is already in VEHICLE, so it is sufficient to remove it from INVOLVE.)

PLATE_NUMBER

DAMAGE_DESC

TOWCOMPANY_NAME

VINEVENT_ID


WORKSHOP-45

This table is analogous to INVOLVE. It is in 1 NF but not 2NF, which introduces redundancy and update anomalies. To achieve 3 NF, remove LICENSE_NUMBER and FULL_NAME.

Solution 3(g) - PARTICIPATE_IN Table

LICENSE_NUMBER

FULL_NAME

INJURY_DESC

ALCOHOL_PERCENT

PERSON_IDEVENT_ID


WORKSHOP-46

Solution 3(g) - PERSON Table

This table is in 2NF but not 3NF, because of the dependencies on columns other than the primary key. Again this results in potential redundancy.

There are two ways to achieve 3NF. The best is to remove CITY_NAME and STATE_CODE and place them in a ‘look-up’ table with primary key ZIP_CODE. (What is the other alternative?) Most companies would not do this, however, for two reasons:

– Zip codes don’t often change, so update anomalies are unlikely

– Usually we retrieve the complete address; performance might be a problem if address data were stored in two or more tables.

PERSON_ID

FULL_NAME

STREET_DESC

CITY_NAME

STATE_CODE

ZIP_CODE


WORKSHOP-47

Solution 3(h) - Fourth Normal Form

For purposes of this exercise, assume that PRECIPITATION_CODE and ROAD_CODE are independent. (This assumption must be verified with DMV staff.) Then the basic relational design is as follows:

The main point here is that two or more unrelated plural attributes are implemented in separate (dependent) tables. Implementing unrelated plural attributes in the same table introduces redundancy and violates fourth normal form.

ACCIDENTEVENT_IDVISIBILITY_CODEPRECIPITATION_CODE (M)ROAD_CODE (M)REPORT_DESC

ACCIDENTEVENT_IDVISIBILITY_CODEREPRORT_DESC

PRECIPITATIONEVENT_IDPRECIPITATION_CODE

ROADEVENT_IDROAD_CODE

X

X


WORKSHOP-48

4. Advanced Relational Design


WORKSHOP-49


Complete the advanced relational design. Begin with the diagram on the following page.

(a) Step C5. Identify one table which contains a row-oriented vector, and one which contains a column-oriented vector. For each of these tables,

– Diagram an alternative design.

– List advantages and disadvantages of the alternative designs. Make assumptions on processing requirements as necessary.

(b) Step K5. Which table might benefit most from an surrogate key? List advantages and disadvantages of introducing the surrogate key.

(c) Step T5. Which subtables might be merged with the supertable? List advantages and disadvantages of merging each of these subtables. Make assumptions on processing requirements and data statistics as necessary.

(d) Step T6. Which foreign key in the diagram represents a one-one relationship (other than ISA)? What are the advantages and disadvantages of merging the two tables connected by this foreign key?

(e) Step T8. Our relational design has many small tables, which may result in joins for critical queries and degrade performance. Suggest denormalization to improve performance. Make assumptions on processing requirements as necessary, and discuss the problem of redundancy.

(f) Based on your assumptions and design decisions for (a) through (e) above, draw a final diagram for the advanced relational design.


WORKSHOP-50

4. Starting Diagram for Advanced Relational Design













CAUSE




ADMINISTER

CITE VIOLATE

X

X

X

X

o


OWNVINPERSON_ID

X


X

XX

XX

X

X

X

X

X

X

X

HOLD SCORE

X


X


WORKSHOP-51

Solution 4(a) - Row vs. Column-orientedEXAM_SCORE contains a row-oriented vector, scores for the five parts of the exam. An alternative column-

oriented design looks like this:

Advantages of the column-oriented design are

• flexibility - less restructuring if the exam parts change or expand

• compatibility with SQL functions - for example, SUM of scores on all parts may be easier to compute

Disadvantages of column-oriented design are

• an extra table is necessary, which leads to more joins

• more physical space

• an additional foreign key, with the overhead of maintaining referential integrity

LICENSE_AUTHORIZE contains a column-oriented vector, assuming that there is a limited number of possible authorization codes. Here is the row-oriented design:

(FLAG is a true/false data type - the authorization either applies or does not apply to the license.) The tradeoffs are similar to the EXAM_SCORE designs.

EXAM_SCOREPERSON_IDEXAM_DATECENTER_NAMEOFFICER_IDPARALLEL_SCOREUTURN_SCOREYTURN_SCORESIGNAL_SCORESPEED_SCORE

ROW-ORIENTED COLUMN-ORIENTED

EXAMPERSON_IDEXAM_DATECENTER_NAMEOFFICER_ID

EXAM_SCOREPERSON_IDEXAM_DATEPART_CODESCORE

X

ROW-ORIENTED

LICENSELICENSE_NUMBEREXPIRATION_DATEPRIVATE_AUTH_FLAGCOMMERCIAL_AUTH_FLAGFREIGHT_AUTH_FLAGMOTORCYCLE_AUTH_FLAG

COLUMN-ORIENTED



X


WORKSHOP-52

Solution 4(b) - Surrogate Keys

The natural primary key of OFFICER is logically complex (three columns), physically complex (many bytes), and unstable (RANK_CODE may change). Since several foreign keys refer to OFFICER, it makes sense to introduce an surrogate key. One alternative is to consider OFFICER a subentity of PERSON and use PERSON_ID as the primary key. Another is to introduce a new column OFFICER_ID. Either way, the foreign keys in EXAM_SCORE and VIOLATION which refer to officer become more co mpact and stable.

NATURAL KEY SURROGATE KEY


OFFICEROFFICER_IDBADGE_NUMBERDEPARTMENT_NAMERANK_CODEFULL_NAME


WORKSHOP-53

Solution 4(c) - L-Shaped Data

OPERATOR should probably be merged with PERSON, for the following reasons:

• Most people are operators, so the expanded PERSON table will have few nulls.

• Any null values in the BIRTH_DATE, HAIR_COLOR, and EYE_COLOR columns of the new table mean ‘unknown’, which is better than ‘inapplicable’.

• It seems likely that merging these tables will eliminate many joins and significantly improve performance.

GROUND_VEHICLE should probably be merged with VEHICLE, for the same reasons. However in this case ‘inapplicable’ nulls will appear, since the GROUND_VEHICLE columns are apparently meaningless for BOAT and AIRCRAFT.

VIOLATION might be merged with EVENT. Again, the benefits are simlar to OPERATOR/PERSON, except that ‘inapplicable’ nulls are created.

PERSONPERSON_IDFULL_NAMEADDRESSBIRTH_DATEHAIR_COLOREYE_COLOR

PERSONPERSON_IDFULL_NAMEADDRESS OPERATOR

BIRTH_DATEHAIR_COLOREYE_COLOR

X


WORKSHOP-54

Solution 4(d) - One-One Relationships

OPERATOR - HOLD - LICENSE is one-one, both maximum and minimum. To reduce joins and eliminate a foreign key, it is a good idea to merge LICENSE into OPERATOR> SInce the relationship is required (every operator must have a license), the merger creates no nulls.

Unless the cardinality of HOLD changes (for example, the DMV starts tracking aircraft and boat licenses), there appear to be no significant disadvantages of this merger.

This leads to a curious situation. In 4(a), we considered merging LICENSE_AUTHORIZE into LICENSE with a row-oriented design. In 4(c), we merged OPERATOR and PERSON as L-Shaped data. If we now merge LICENSE and OPERATOR, then three talbes collapse into one, greatly improving performance.

OPERATORPERSON_IDBIRTH_DATEHAIR_COLOREYE_COLOR


HOLD

X

OPERATORPERSON_IDBIRTH_DATEHAIR_COLOREYE_COLORLICENSE_NUMBEREXPIRATION_DATE

1

1


WORKSHOP-55

Solution 4(e) - Denormalization

To calculate total points accumulated by a person in the past year requires a four-way join of PERSON, PARTICIPATE_IN, VIOLATION, and SECTION. This could become a five- or six-way join if a driver’s license number is provided rather than a name or PERSON_ID.

To speed up this query, some form of redundancy might be necessary. For example, add a POINTS_QTY column to PARTICIPATE_IN, or alternatively, maintain a running total of points in the PERSON table. If you adopt either of these alternatives,

• Retain POINTS_QTY in the SECTION table as ‘official’ source data.

• Clearly document the redundancy.

• Control the update anomalies and inconsistency with triggered procedures or similar techniques.


WORKSHOP-56

Solution 4(f) - Final Diagram

VEHICLEVINYEARMAKE_CODEMODEL_NAMEPLATE_NUMBERSTATE_CODE (0)REGISTRATION_DATESALES_COSTHORSEPOWER_QTYEMISSIONS_DATEAXLE_QTY





PERSONPERSON_IDFULL_NAMEADDRESSBIRTH_DATEHAIR_COLOREYE_COLORLICENSE_NUMBEREXPIRATION_DATETOTAL_POINTS_QTY


OFFICEROFFICER_IDBADGE_NUMBERDEPARTMENT_NAMERANK_CODEFULL_NAME


CAUSE

EVENTEVENT_IDDATETIMELOCATION_DESCCITATION_NUMBERTYPE_CODE


ADMINISTER

CITE VIOLATE

X

X

X

o


OWNVINPERSON_ID

X


X

XX

XX

X

X

X

X

SCORE


X

X

advanced design copyright 1995 technology mentors inc. workshop-1 relational database design...

Documents