1. Domain Modeling Part1: Entity Relationship Diagram Chapter 4 pp. 93-102 - part 1 1

2. Domain Modeling Define system requirements by:  understanding “things” (within the problem domain) that needs to be stored 2 Classification Scheme

3. How to Identify "Things" for our Domain Model Identify the "Nouns"  From various sources: Interviews Current system – forms, reports, procedures, software Use cases, use case descriptions, actors  Refine the list Include if: Within the scope, and Need to know about it Exclude: Synonyms Derived Research others Domain Modeling Techniques  Entity Relationship Diagram (ERD) – part1  Domain Class Diagram – part2 3

4. Entity Relationship Diagram ERD 4

5. Entity Relationship Diagram ERD - a data modeling technique Entity − A “Thing” (in the scope) − A noun - person, place, object, event, etc. − Within our scope & we need to remember it! 5 Employee

6. ERD: Attributes Attribute − A characteristic − Information about the entity that is within the scope Attribute TypeExamples Atomic/Simple JobTitle, Salary Composite Name, Address Derived Age, TotalPay Separate Address  StreetAddr, City, State, Zip 6 Employee LastName FirstName SSN BirthDate JobTitle Salary Don't separate StreetAddr  houseNo & streetName

7. ERD: Primary Key An attribute (or a group of attributes) that uniquely identifies an instance  3 Rules for a good Primary Key is… 1.Unique - no duplicate values 2.Required - cannot be null 3.Static - does not change (e.g. build name – poor PK)  Candidate Key − Multiple unique attributes may exist, if so pick: Attribute that is used most often 7 Employee EmpID - PK LastName FirstName SSN BirthDate JobTitle Salary Tip: Try to match the PK name with the Entity Name Order  OrderNo Dept  DeptCode

8. ERD: Relationships Relationship  An association between entities − represents a "NEED TO KNOW the relationship" between the instances of each entity  Occurs in two directions Left to Right: A Department employs _?_ Employees Right to Left: An Employee is employed by _?_ Department employs 8 DepartmentEmployee

9. ERD: Relationships Cardinality  # of association between instances − Minimum – 0 or 1 (optional or required, respectively) − Maximum – 1 or many − Use “Crows foot” Notation 9 EmployeeParking Space DepartmentEmployee Project employs is assigned

10. ERD: Relationships Type of Relationship  Determined by the _____________ Cardinalities − One to One − One to Many − Many to Many 10 EmployeeParking Space DepartmentEmployee Project employs is assigned

11. ERD: Relationships Can have >1 relationship between the same 2 entities  Thus, Use precise relationship names! manages 11 EmployeeProject assigned

12. Practice: ERD  Academic Department "employs"  Student "is member of"  Student Organization is "sponsored by"  Course is "offered by"  Faculty "teaches"  Course "has"  Student "registers for" 12 Student Faculty Section Student Organization Course Academic Department Faculty – anyone who teaches and/or does research

13. Associative Entity Where do we place these attributes?  Employee and Project o Add StartDate – the date an employee started working on a project  Employee and SkillType o Add ProfLevel – how proficient is the employee at that skill  Student and Section o Add Grade – the grade the student made in a particular section 13 Adding an Associative Entity  Know when to add an associative entity  Name it appropriately  Determine the cardinalities  Determine the concatenated PK  Add any non-key attributes

14. Typical Example Customer  Order  OrderItem 14

15. Understand these! 15

16. ERD: Relationships Degree of the Relationship  Refers to how many ___________ participate in the relationship. − Unary Relationship (aka: Recursive Relationship) − Binary Relationship − Ternary Relationship − n-ary Relationship 16

17. Let's model a Business Object! A business object is not always = 1 Entity. It may require more! 17

18. ERD General Tips RemindersFor example… Naming Entities & Attributes Entity name -singularEmployee  not Employees Attribute name -specificstartDate  not date Attribute name -don’t add entity in the name startDate  not employeeStartDate Other No composite attributesNo: address  Yes: address, city, state, zip No: name  Yes: firstName, lastName Primary Key: o Must be unique o Must always have a value o Doesn't change These are not good PKs: Name  may be duplicates SSN  everyone may not have a SSN BuildingName  it may be renamed Be careful w/mandatory 1 to 1’sIn this case A & B may be the same thing  If so, use one entity Report/Form  usually >1 entityOrder Form  may need 4 entities In Analysis, only resolve a many-to-many when there is a non-key attribute. …Otherwise, the model will be unnecssarilty busy. In Design, however, we will resolve all many-to-mnys. AB 18