Attributes and Domains

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? • 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

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

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 noteson data types (to be coveredsoon) while I am documentingattributes • Make notes on attributedefinition also • Some entities may have dozensor 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 or system • 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 theoriginal entity plus the formerly multivalued attribute

17. Multivalued Attributes (cont.) • Each record indicates that aparticular star appeared in aparticular movie • May have multiple records forthe same star (he/she has beenin 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-valuedproblem • Violates First Normal Formnormalization 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 PKand StartTime or StartDate as compositePK • Add attribute of interestas nonkey attributeConsider 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?