1. Topics
Nonkey Attributes
Attribute Definition
Defining Attributes/Attributes & Entities (Review)
Identifying Attributes
Attribute Considerations
Derived Attributes
Relations

2. Identify “Information Elements” Identify Entities
Database Design Steps
Identify “Information Elements”
Identify Entities
Identify Primary Keys
Identify Relationships
Fix Relationship Problems
Identify Non-Key Attributes
Fix Attribute Problems
Address Performance Issues
Build Application Objects (stored procedures, views)
Design Reports
List is not strictly sequential
Some steps performed recursively
Some steps require returning to previous steps

3. 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

4. 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)

5. 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?
StudentID, 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

6. 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 field description in SQL table definitions

7. 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 from which each student graduated
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

8. 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

9. 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
Watch for attributes that imply subtypes of an entity (later)

10. 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

11. 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 or system
Same entity
Multiple entities
Student.GPA
Employee.YearsOfService
Employee.Age

12. 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

13. 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

14. 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

15. 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

16. Exercise
See the Module Activities section for the exercise entity
Identify as many attributes as you can for this entity
Post your results in the designated discussion area for the module
Review at least one classmate’s posting to identify missing attributes
Do this exercise before viewing any additional videos