IS 325 Notes for Wednesday September 18, 2013
Homework Grades/Feedback I’m behind on homework.. I will catch-up this weekend
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
MAPPING UNARY RELATIONSHIPS Unary relationships in ER diagrams are mapped in the same way as binary relationships
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
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
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
MAPPING UNARY RELATIONSHIPS Mapping a M:N unary relationship Sample data records for the mapped relations
MAPPING UNARY RELATIONSHIPS Mapped in the same way as 1:M unary relationships
MAPPING UNARY RELATIONSHIPS Mapping a 1:1 unary relationship Sample data records for the mapped relation
MAPPING MULTIPLE RELATIONSHIPS BETWEEN THE SAME ENTITIES Each relationship is mapped
MAPPING MULTIPLE RELATIONSHIPS BETWEEN THE SAME ENTITIES Sample data records for the mapped relations
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
MAPPING WEAK ENTITIES Mapping a weak entity Sample data records for the mapped relations
MAPPING WEAK ENTITIES Mapping a weak entity with two owners Sample data records for the mapped relations
MAPPING WEAK ENTITIES Mapping a weak entity with no partial identifier Sample data records for the mapped relations
Example ER diagram : HAFH Realty Company Property Management Database
Example mapped relational schema: HAFH Realty Company Property Management Database
Example: Sample data records for the HAFH Realty Company Property Management Database (part 1)
Example: Sample data records for the HAFH Realty Company Property Management Database (part 2)
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
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
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
RELATIONAL DATABASE CONSTRAINTS User-defined constraints Added by the database designers
RELATIONAL DATABASE CONSTRAINTS Specific minimum and maximum cardinalities Sample data records for the mapped relations
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
RELATIONAL DATABASE CONSTRAINTS Business rule for salary amounts Sample data records for the mapped relation
RELATIONAL DATABASE CONSTRAINTS Business rule for the dates of enrollment and graduation Sample data records for the mapped relation
RELATIONAL DATABASE CONSTRAINTS Business rule for gender of students in an organization Sample data records for the mapped relation
MAPPING ASSOCIATIVE ENTITIES Associative entities are mapped into relational database constructs in the identical way as M:N relationships
Example: An M:N relationship and associative entity mapped into a relation in the same way
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
Example: Mapping a ternary relationship
Example: Sample data records for the mapped relations
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
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
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
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