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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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?