1. IS 325
Notes for
Wednesday
September 18, 2013

2. Homework Grades/Feedback
I’m behind on homework.. I will catch-up this weekend

3. Today’s Class
Periodically you might need to be reminded why you are here
Why It's Important to Know Computer Programming
The World is Flat

4. MAPPING UNARY RELATIONSHIPS
Unary relationships in ER diagrams are mapped in the same way as binary relationships

5. MAPPING UNARY RELATIONSHIPS
Mapping 1:M unary relationships
The relation mapped from an entity involved in a 1:M unary relationship contains a foreign key that corresponds to its own primary key

6. MAPPING UNARY RELATIONSHIPS
Mapping a 1:M unary relationship
Client can be referred by only one client but can refer multiple clients
Sample data records for the mapped relation

7. MAPPING UNARY RELATIONSHIPS
Mapping M:N unary relationships
In addition to the relation representing the entity involved in a unary M:N relationship, another relation is created to represent the M:N relationship itself
This new relation has two foreign keys, both of them corresponding to the primary key of the relation representing the entity involved in the unary M:N relationship
Each of the foreign keys is used as a part of the composite primary key of the new relation

8. MAPPING UNARY RELATIONSHIPS
Mapping a M:N unary relationship
Sample data records for the mapped relations

9. MAPPING UNARY RELATIONSHIPS
Mapped in the same way as 1:M unary relationships

10. MAPPING UNARY RELATIONSHIPS
Mapping a 1:1 unary relationship
Sample data records for the mapped relation

11. MAPPING MULTIPLE RELATIONSHIPS BETWEEN THE SAME ENTITIES
Each relationship is mapped

12. MAPPING MULTIPLE RELATIONSHIPS BETWEEN THE SAME ENTITIES
Sample data records for the mapped relations

13. MAPPING WEAK ENTITIES Mapping weak entities
Weak entities are mapped in a same way as regular entities with one addition:
The resulting relation has a composite primary key that is composed of the partial identifier and the foreign key corresponding to the primary key of the owner entity

14. MAPPING WEAK ENTITIES Mapping a weak entity
Sample data records for the mapped relations

15. MAPPING WEAK ENTITIES Mapping a weak entity with two owners
Sample data records for the mapped relations

16. MAPPING WEAK ENTITIES Mapping a weak entity with no partial identifier
Sample data records for the mapped relations

17. Example ER diagram : HAFH Realty Company Property Management Database

18. Example mapped relational schema: HAFH Realty Company Property Management Database

19. Example: Sample data records for the HAFH Realty Company Property Management Database (part 1)

20. Example: Sample data records for the HAFH Realty Company Property Management Database (part 2)

21. RELATIONAL DATABASE CONSTRAINTS
Relational database constraints - rules that a relational database has to satisfy in order to be valid
Implicit constraints
The implicit relational database model rules that a relational database must satisfy in order to be valid
User-defined constraints
Database constraints that are added by the database designer

22. RELATIONAL DATABASE CONSTRAINTS
Implicit constraints
Each relation in a relational schema must have a different name
Each relation must satisfy the following conditions:
Each column must have a different name
Each row must be unique
In each row, each value in each column must be single valued
Domain constraint - all values in each column must be from the same predefined domain
The order of columns is irrelevant
The order of rows is irrelevant

23. RELATIONAL DATABASE CONSTRAINTS
More Implicit constraints
Primary key constraint - each relation must have a primary key, which is a column (or a set of columns) whose value is unique for each row
Entity integrity constraint
Referential integrity constraint

24. RELATIONAL DATABASE CONSTRAINTS
User-defined constraints
Added by the database designers

25. RELATIONAL DATABASE CONSTRAINTS
Specific minimum and maximum cardinalities
Sample data records for the mapped relations

26. RELATIONAL DATABASE CONSTRAINTS
Business rules
User defined constraints that specify restrictions on databases that are not a part of the standard notation for creating ER diagrams

27. RELATIONAL DATABASE CONSTRAINTS
Business rule for salary amounts
Sample data records for the mapped relation

28. RELATIONAL DATABASE CONSTRAINTS
Business rule for the dates of enrollment and graduation
Sample data records for the mapped relation

29. RELATIONAL DATABASE CONSTRAINTS
Business rule for gender of students in an organization
Sample data records for the mapped relation

30. MAPPING ASSOCIATIVE ENTITIES
Associative entities are mapped into relational database constructs in the identical way as M:N relationships

31. Example: An M:N relationship and associative entity mapped into a relation in the same way

32. MAPPING TERNARY RELATIONSHIPS
Ternary relationships are used as many-to-many-to-many relationships
A new relation is created with foreign keys from the participating entities forming a composite primary key of the new relation

33. Example: Mapping a ternary relationship

34. Example: Sample data records for the mapped relations

35. DESIGNER-CREATED PRIMARY KEYS AND THE AUTONUMBER OPTION
Autonumber data type option - enables automatic generation of consecutive numeric data values in a column
Designer-created primary key - primary key column, not called for by the original requirements, added to a table by the database designer
Often used in conjunction with the autonumber data type option

36. DESIGNER-CREATED PRIMARY KEYS AND THE AUTONUMBER OPTION
Entity and the resulting relation with a designer-created primary key column
Entity and the resulting relation
Sample data records for the relation with a designer-created primary key

37. ER AND RELATIONAL MODELING
Process of requirements collection should be accompanied by the ER modeling and then followed by mapping the ER model into a subsequent relational schema
Some practitioners prefer to create relational schemas straight from the requirements
In such cases, the ER modeling phase is simply omitted

38. ER AND RELATIONAL MODELING
Create relational schemas straight from the requirements is not advisable for following reasons
ER modeling is more suited for visualization of the requirements
Certain concepts can be visualized graphically only in ER diagrams
Every attribute is mentioned only once in the ER diagram
An ER model is a better communication and documentation device