1. Attributes and Domains
Nonkey Attributes
Attribute Definition
Defining Attributes/Attributes & Entities (Review)
Identifying Attributes
Attribute Considerations
Derived Attributes
Relations
Multi-valued Attributes
Time-Dependent Attribute Values
Space-Dependent Attribute Values

2. Non-key Attributes
Previous discussion has focused on different kinds of attributes
Primary keys
Foreign keys
Alternate keys (candidate keys)
We have implied and sometimes illustrated other attributes
Attributes that just contain information we want to record about an entity
Do not serve as any sort of key

3. Non-key Attributes (cont.)
Four major issues with non-key attributes
Identifying descriptive attributes
Placing attributes in the correct entity
Rules of normalization
Appropriate functional dependency
Fixing problem attributes
Identifying the appropriate data type for the attribute (field)
Specifying appropriate domain business rules for the attribute (field)
Later
Later
Later
Later

4. Attributes
"A property or characteristic of an entity that is of interest to the organization"
E.g., what characteristics of a STUDENT are of interest to the University?
SSN, First Name, Last Name, Major, DOB, …
What characteristics are not of interest?
What about Professors and Classes?
What about your project?
Attributes become fields in a record in the physical database

5. Describing Attributes
Attributes must be described just like entities
What do these mean for a Product entity?
Price − Weight
Supplier − ProductID
“Street address excluding apartment number or P.O. Box where employee receives mail”
“Shipping weight of one unit of product including packaging in decimal fractions of a pound”
“Current retail price that will be charged to a customer purchasing this product”
Use Attribute description in SQL table definitions

6. Entities and Attributes
There can be ambiguity—depending on perspective—in determining what should be an entity and what should be an attribute
UCF may have an attribute of STUDENT that contains the high school each student graduated from
The State of Florida Dept. of Education may consider high schools to be an entity with its own attributes
Refinement of the database may require that some attributes be turned into new entities—watch for this as we continue in the course

7. Identifying Attributes
Identify attributes as part of the discovery and investigation used to discover entities
Review documents and reports
Interview employees
Assign descriptive attributes to the entities that they describe
We will test this assignment through the normalization process later
Review for completeness

8. Identify Attributes (cont.)
Model attributes in entities
I like to make preliminary notes on data types (to be covered soon) while I am documenting attributes
Make notes on attribute definition also
Some entities may have dozens or even hundreds of attributes

9. Attribute Considerations
Do not combine attributes
E.g., if a vehicle license plate was issued by Utah and has tag number ABC123 don’t record “UTABC123” into a License attribute
Use two attributes
IssuingState
TagNumber
Separate Apt/Suite Num from address (so GIS matching software will be more efficient)
Don’t used coded attribute values unless using a look up table

10. Derived Attributes
Meets our definition of an attribute (information we wish to record about an entity)
Value can be derived or calculated from other data in the DB
Same entity
Multiple entities
Student.GPA
Employee.YearsOfService
Employee.Age

11. Derived Attributes (cont.)
I like to document the derived attribute at design time
Label it “Total Value <d>”
Document the derivation/calculation algorithm
Whether or not to explicitly store derivable attributes has performance implications
Faster retrieval if explicitly stored
Explicitly storing requires more data updates and maybe retrievals when component data are updated, deleted, or changed over time
Defer implementation decision for performance analysis

12. Relations—A Formal Definition
"Relation" is a fancy term for table
Entities are the ERD version of a table
Relations are the fully specified logical definition of a table
Table is the physical implementation in the database
There are some formal characteristics of relations that must be understood
Affect the other actions we will take in logical design
Affect DB performance

13. Relations—A Formal Definition (cont.)
"A relation (table) is a named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows"
Every record (row) has the same number of columns
Relations are rectangular
Entities become relations (tables)
Attributes become columns

14. Relations—Properties
Each relation in a database has a unique name
An entry in a cell (intersection of a row and a column) is atomic (single valued)
Each row is unique
Each column in a table has a unique name
The sequence of columns left to right is insignificant
The sequence of rows top to bottom is insignificant
Some databases require column names to be unique throughout all tables but this is not necessary to satisfy the conditions of the theoretical relational model

15. Three Multi-Value Attribute Problems
We often need multiple values for an attribute
Employee.Skill
Student.Address
If we update an attribute value we lose the historical values by overwriting them
Product.Price
Employee.JobTitle
MV attributes create significant retrieval problems

16. Multivalued Attributes (cont.)
Remove multivalued attributes by creating a new entity
PK of new entity is often the PK of the original entity plus the formerly multivalued attribute

17. Multivalued Attributes (cont.)
Each record indicates that a particular star appeared in a particular movie
May have multiple records for the same star (he/she has been in several movies)
May have multiple records for the same movie (it has several stars)
No combination of movie and star will be repeated
Add/move appropriate nonkey attributes
What about Eddie Murphy in Coming to America?

18. Multi-Valued and Repeating Attributes
Do not use “Repeating Attributes” to work around the multi-valued problem
Violates First Normal Form normalization rule (covered soon)
You may have similar attributes if their meanings are distinctly different and strictly limited in number
Student.HomeStreetAddress
Student.LocalStreetAddress
Orders.SalesEmployeeID
Orders.PackingEmployeeID

19. Time Dependent Data
Sometimes the values of attributes are dependent on time
Graduation requirements are dependent on catalog year
Product prices will vary over time
Organization may require access to historical values, not just current values
A new record must be created for each time dependent value

20. Time Dependent Data (cont.)
Create a new entity
Consider original PK and StartTime or StartDate as composite PK
Add attribute of interest as nonkey attribute Consider EndDate/EndTime as nonkey attribute that can be nullable
Consider retaining current value of attribute in the original entity for performance purposes

21. Time Dependent Data (cont.)
What attributes will go in each entity if time dependency is not a factor?

22. Time Dependent Data (cont.)
How do we add attributes to indicate whether a course is required for a particular catalog year?

23. Time Dependent Data (cont.)
Similar problems may exist for spatially dependent data
Anybody remember “Prices slightly higher west of the Mississippi”?
Start times for television programs
Prices
Sales tax rates
What do we do if attribute values vary by space and time?