1. More Diagramming & Practice with Relationship Modeling

2. ER Notation
There is no standard for representing data objects in ER diagrams. Each modeling methodology uses its own notation. The original notation used by Chen is widely used in academics texts and journals but rarely seen in either CASE tools or publications by non-academics. Today, there are a number of notations used, among the more common are Bachman, crow's foot, and IDEFIX.
All notational styles represent entities as rectangular boxes and relationships as lines connecting boxes. Each style uses a special set of symbols to represent the cardinality of a connection. The symbols used for the basic ER constructs are:
Entities are represented by labeled rectangles. The label is the name of the entity. Entity names should be singular nouns.
Relationships are represented by a solid line connecting two entities. The name of the relationship is written above the line. Relationship names should be verbs.
Attributes, when included, are listed inside the entity rectangle. Attributes which are identifiers are underlined. Attribute names should be singular nouns.
Cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is omitted, the cardinality is one.
Existence is represented by placing a circle or a perpendicular bar on the line. Mandatory existence is shown by the bar (looks like a 1) next to the entity for an instance is required. Optional existence is shown by placing a circle next to the entity that is optional.

3. Steps In Building the Data Model
While ER model lists and defines the constructs required to build a data model, there is no standard process for doing so. Typically, the entities and relationships are modeled first, followed by key attributes, and then the model is finished by adding non-key attributes. The sequence used for this course are:
Identification of data objects and relationships
Drafting the initial ER diagram with entities and relationships
Refining the ER diagram
Add key attributes to the diagram
Adding non-key attributes
Validating the model through normalization
Adding integrity rules to the Model

4. Single Entity Data Model
CUSTOMER
Name
Address
City
State
Zip Code
Telephone
*Account Number

5. One-to-Many Relationship 1:m
CUSTOMER
Name
Address
City
State
Zip Code
Telephone
*Account Number
ORDER
*OrderNumber
OrderDate
PromiseDate

6. Many-to-Many Relationship (m:m)
CUSTOMER
Name
Address
City
State
Zip Code
Telephone
*Account Number
ORDER
*OrderNumber
OrderDate
PromiseDate
PRODUCT *ProductNo Description UnitPrice Room Finish QtyOnHand ?

7. Many-to-Many Relationship (m:m)
To depict the m:m relationship, a third entity is created forming two 1:m relationships
This entity is known as an intersection entity or the junction table
The vertical bar added to the “chicken foot” indicates the unique identifier is concatenated from ORDER and PRODUCT

8. Many-to-Many Relationship (m:m)
An order has many requested items, but each requested item refers to only one order
A product can be requested many times, but each requested item refers to only one product
CUSTOMER
Name
Address
City
State
Zip Code
Telephone
*Account Number
ORDER
*OrderNumber
OrderDate
PromiseDate
PRODUCT
*ProductNo
Description
UnitPrice
Room
Finish
QtyOnHand
REQUEST
QtyOrdered
LinePrice

9. Many-to-Many Relationship (m:m)

10. Many-to-Many Relationship (m:m)
Foreign key
Foreign keys
Together they make up the primary key for this table
Remember the primary keys and foreign keys must be the same data type and length

11. The final part of the ERDiagram
The final part of the ERDiagram is the series of notations at the end of the lines. It is their appearance that gives rise to the name "Crow's Foot," which is what this kind of ERD is called. These lines indicate the nature of the relationship, which is called cardinality.

12. Cardinality Notation

13. Applying these interpretations
In the relationship between Employee and Department, one or more employees belong to one department. In other words, each employee belongs to one and only one department, but each department has at least one and probably several employees in it. This is called a one-to-many relationship.
In the relationship between Employee and Class we see that zero or more employees can take zero or more classes. In other words, a class could be taken by no one or by several employees. Similarly an employee could take zero classes or several classes. This is called a many-to-many relationship.

14. Applying these interpretations
The relationships between Employee and Salaried Employee and between Employee and Hourly Employee are both one-to-one relationships. Each person in the Salaried Employee entity will have a corresponding record in the Employee entity. Also, each person in the Hourly Employee entity will have a corresponding record in the Employee entity. Since an employee will not be both hourly and salary, it is obvious that the Salaried Employee and Hourly Employee entities will each have fewer records than the Employee entity. For instance, there might be 1,000 employees, 700 of whom are hourly and 300 of whom are salaried. So when you see entities in a one-to-one relationship, it doesn't necessarily mean that they have the same number of records. It simply means that each record in the one entity has no more than one corresponding record in the other entity.

15. Try this:
Scenario:
Our database has authors who have an authorid, firstname, and lastname. These authors have many books, and the books have many authors. The books have a bookid, and a booktitle.
Create the data model and show the relationships between the tables.

16. Answer: BOOKS *BookID AUTHORS BOOKTITLES *AuthorID BookTitle *AuthorID
FName
LName
BOOKTITLES
*AuthorID
*BookID

17. Try this:
Scenario:
Languages spoken, an important (and likely a multivalued) attribute for a job candidate, deserves elevation to entity status in this database. The original creator of this customer's database had realized this and created a separate table for languages. The problem then became that, if each candidate can speak many languages and each language can be spoken by many candidates, there is a many-to-many relationship between the two tables.
In the candidates entity we have a candidateid, salutation, fname, lname, address, and city.
In the languages entity we have a language
Create the data model and show the relationships between the tables.

18. Answer:

19. Try This:
This database must track the members’ orders for merchandise. The info for each order must include the member who placed the order, amount paid, form of payment, order date, status of order, shipped date, products sold, and the quantity of each product.

20. Try This:
This database must store information about the staff who work for the organization. The information must include the first names, last names, and middle initials, as well as the staff members’ addresses, phone numbers, and start dates. The information must also include their positions within the organization as well as who each one’s supervisor is.

21. Creating the relationships in Visio or MySQL Workbench
In Visio or MySQL Workbench, it is only a drawing to depict how your relationship will look once you get it into mySQL. It does not have an physical impact on the data itself.
Note: some of the newer programs allow you to directly import your data from their drawing program.

22. Steps In Building the Data Model
While ER model lists and defines the constructs required to build a data model, there is no standard process for doing so. Typically, the entities and relationships are modeled first, followed by key attributes, and then the model is finished by adding non-key attributes. The sequence used for this course are:
Identification of data objects and relationships
Drafting the initial ER diagram with entities and relationships
Refining the ER diagram
Add key attributes to the diagram
Adding non-key attributes
Validating the model through normalization
Adding integrity rules to the Model

23. Questions?