Introduction to Data Modeling—Topics

1. Introduction to Data Modeling—Topics • Introduction to Data Modeling • Information elements • Introduction to Entities, Attributes, and Relationships • Basic notation • Chen • Alternative • More on attributes

2. What is Data Modeling? • Data modeling is a step in the process that begins with the planning phase of Information Engineering and ends with construction of the physical database EntitiesAttributesRelation-shipsRules InformationSystemsPlanning InformationElements PhysicalDatabase Data Modeling

3. What is Data Modeling (cont.) • Data Modeling is a process of requirements identification, documentation, and revision that results in a finished DB design • Process begins with gross identification of basic DB components • Design is refined according to rules for storage and retrieval efficiency • Finished DB design is converted to the physical DB • Some DB design tools make the conversion automatically

4. Information Elements • IS Design involves interviews with clients • Clients don’t understand our terminology or DB concepts (or they wouldn’t need us!) • We probably don’t understand much of theirs • Examine forms, reports & filing cabinets • Interviews & research will result in a collection of "Information Elements" (my term) • Lists of items of concern to the client • Items that crop up in interviews & research • Items you recognize from your experience

5. Information Elements (cont.) • Task is to determine which part of a data model the different information elements fit • Entity • Attribute • Relationship • Business rule • System input or output • None of the above (irrelevant)

6. Information Elements (cont.) • Our determinations generate the base data model • Further analysis modifies and extends the data model to its final form • Add new entities as review of the business model reveals overlooked items • Add many new entities as part of the normalization process

7. Entities • "A person, place, object, thing, event, or concept about which the organization wishes to maintain data" • Examples from the university's database might be STUDENT, CLASS, and PROFESSOR • Each entity in the final data model will become a table in the physical database • It is important to distinguish between entities and attributes of an entity • Distinction may change with perspective • We will also create new entities as we refine our data model

8. Occurrences • "Occurrences" of an entity are individual instances of the entity • You are an occurrence of the STUDENT entity • I am an occurrence of the FACULTY entity • Occurrences correspond to records in the database • Take care not to confuse occurrences with entities • Some authors use the term “Entity Set” to imply that the Entity is a collection of occurrences

9. Defining Entities • It is amazingly important to explicitly define what is meant by each entity • What is contained in the following entities? • Customer − Order • Sale − Employee • Entity descriptions become part of the DB documentation (description property in SQL Server) • You cannot assume that developers using the DB will have the save vision for the meaning of an entity that you do

10. Defining Entities (cont.) • (One occurrence of this entity represents…) “A person or organization that has purchased products from the company or who has inquired about purchasing products” (Customer) • … “A person that has signed an employment agreement with the company including former employees. Excludes applicants, contractors, and contractor employees” (Employee) • Try very hard to avoid using the entity name as part of the definition. • See lesson on Course Lessons Page

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

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

13. Naming Entities and Attributes • Balance brevity with completeness • No Spaces • Order Detail → OrderDetail or Order_Detail • No SQL Reserved Words • Order → CustomerOrder • Date → OrderDate, HireDate, BirthDate • My preference is for “Pascal Case” • CustomerOrder • LastInventoryDate • Some organizations include data type indicator as an attribute prefix (e.g. smnySalesPrice)

14. Identifier Attributes (Primary Keys) • Identifier Attribute: An attribute whose value uniquely identifies each occurrence of an entity • SSN for student or faculty • VIN for an automobile • SKU for a retail product • Composite Identifiers: More than one attribute is needed to uniquely identify an entity occurrence • Dept Code & Number for a course • Building Code & Room Number for a classroom • Review Alternate Keys

15. Identifier Attributes (cont.) • Identifier attributes define the entity as well as identifying occurrences • What entity does VIN identify? • What entity does State + TagNumber identify? • SKU, SaleID, SKU + SaleID? • SKU + StartDate? • EmployeeID + SkillID? • EmployeeID + PositionID + StartDate? • Always check to ensure that the primary key is consistent with the entity name and the entity description

16. Documenting Identifier Attributes (cont.) • Identifier attributes are underlined in an ER diagram(sometimes bold faced)

17. Relationships • "A meaningful association between (or among) entities" • What in the world does this mean? • Relationships indicate how entities interact from the organization's perspective • Relationships will end up defining paths through the database along which data will be retrieved • The paths usually mirror real world associations between entities

18. Relationships (cont.) • Relationships are verbs • Buys, teaches, sells, owns, … • Is a • Has • Relationship verb describes how two entities interact with each other • If two entities do not interact (from the organization’s official viewpoint) then there is no relationship between them • Professor ?? Football_Play • ‘Direction’ of verb is not very important Important special cases

19. Two Notation Schemes (Chen LDM) Relationships are connectedto entities by notation toindicate the cardinality ofthe relationship Entities are indicated by a box with the entity nameinside Relationships are indicatedby diamonds Attributes are listed in ovalsattached to entities

20. Two Notation Schemes (Alternative LDM) Relationship shown withoutthe diamond Entity name Attributes Entities shown as boxes

21. Multivalued Attributes • Multivalued Attributes are those that may have more than one value for the same entity occurrence • EMPLOYEE Skill • STUDENT Major • Chen recommends illustrating with a double ellipse around the attribute • We will see that multivalued attributes must be eliminated from the ER diagram • I recommend dealing with this immediately (to be covered later) • Don't model multivalued attributes

22. Derived Attributes • A derived attribute is one that can be calculated from other information in the database (data model) • EMPLOYEE.Birthdate and Date give EMPLOYEE.Age • Sum of all CUSTOMER.Purchases minus sum of all CUSTOMER.Payments gives CUSTOMER.Balance • Derived attributes are shown with a dashed ellipse or the notation <d> in my modeling technique • Later we will cover the decision on whether to implement derived attributes in the database

23. What's Next? • More on relationships • Attributes of relationships • Degree of a relationship • Cardinality of relationships