ADVANCED DATA MODELINGCS 260

Database Systems

Overview

Weak entities Relationship degrees E-R diagrams

Chen’s notation Crow’s foot notation

Specialization and generalization

Weak Entities

A “weak entity” is one that cannot be uniquely identified by its attributes alone

A weak entity instance is dependent on (and may be thought of as a subcomponent of) an associated “strong entity” instance Referred to as an “identifying relationship” In other words, the weak entity does not make

sense in the system without the strong entity In a relational database, a weak entity

typically has a composite primary key that includes a foreign key to its strong entity’s primary key

Weak Entities

Example Courses rarely change ids, titles, or credits,

but are not taught every semester and may be taught in multiple sections We could represent the section, semester, and

year as course attributes, but the other attributes will have redundant values

Instead, make course a strong entity and section a weak entity

A course entity has an id, title, and credits A section has a section number, semester, and year For a relational database, the section will include a

foreign key to its associated course’s primary key, and all attributes will constitute the section’s primary key

Overview

Weak entities Relationship degrees E-R diagrams

Chen’s notation Crow’s foot notation

Specialization and generalization

Relationship Degrees

A relationship’s “degree” is the number of entities that participate in the relationship This differs from cardinalities which express

the number of entity instances that participate in a relationship between two entities

Relationship degree types Unary Binary N-ary

Relationship Degrees

Unary relationships Occurs when an entity has a relationship

with itself Example

Suppose an employee entity has an attribute that indicates that employee’s supervisor

If the employee entity is used to model supervisors as well, then the employee entity has a unary relationship

Relationship Degrees

Binary relationships Occurs when exactly two entities

participate in a given relationship Example

Suppose student and course entities exist If a student enrolls in courses, then a binary

relationship exists between the student and course entities

Relationship Degrees

N-ary relationships Occurs when more than two entities

participate in a given relationship Example

Suppose student, course, and tutor entities exist

If a course has both students and tutors, then an n-ary (more specifically a ternary) relationship exists

Relationship Degrees

N-ary relationships can always be replaced by multiple binary relationships Multiple binary relationships may be preferable in

situations where one of the entities that participates in the relationship could be absent This would result in null values that could be avoided if

using multiple binary relationships May require more data

Some relationships aren’t naturally binary, making an N-ary relationship clearer Additionally, constraints involving more than two

entities may not be possible to model using multiple binary relationships

Relationship Degrees

Equivalent binary and n-ary relationships

The ternary relationship (a) clearly indicates that 3 entities participate in the relationship

The multiple binary relationships (b) uses an extra entity (E) to facilitate the relationships

Relationship Degrees

Identify the unary, binary, and n-ary relationships in our candy database

If there are any n-ary relationships, how many entities participate in the relationship?

Sample Database (CANDY)CUST_ID CUST_NAME CUST_TYPE CUST_ADDR CUST_ZIP CUST_PHONE USERNAME PASSWORD

1 Jones, Joe P 1234 Main St. 91212 434-1231 jonesj 12342 Armstrong,Inc. R 231 Globe Blvd. 91212 434-7664 armstrong 33333 Sw edish Burgers R 1889 20th N.E. 91213 434-9090 sw edburg 23534 Pickled Pickles R 194 CityView 91289 324-8909 pickpick 53335 The Candy Kid W 2121 Main St. 91212 563-4545 kidcandy 23516 Waterman, Al P 23 Yankee Blvd. 91234 w ateral 89007 Bobby Bon Bons R 12 Nichi Cres. 91212 434-9045 bobbybon 30118 Crow sh, Elias P 7 77th Ave. 91211 434-0007 crow el 10339 Montag, Susie P 981 Montview 91213 456-2091 montags 9633

10 Columberg Sw eets W 239 East Falls 91209 874-9092 columsw e 8399

PURCH_ID PROD_ID CUST_ID PURCH_DATE DELIVERY_DATE POUNDS STATUS

1 1 5 28-Oct-04 28-Oct-04 3.5 PAID2 2 6 28-Oct-04 30-Oct-04 15 PAID3 1 9 28-Oct-04 28-Oct-04 2 PAID3 3 9 28-Oct-04 28-Oct-04 3.7 PAID4 3 2 28-Oct-04 3.7 PAID5 1 7 29-Oct-04 29-Oct-04 3.7 NOT PAID5 2 7 29-Oct-04 29-Oct-04 1.2 NOT PAID5 3 7 29-Oct-04 29-Oct-04 4.4 NOT PAID6 2 7 29-Oct-04 3 PAID7 2 10 29-Oct-04 14 NOT PAID7 5 10 29-Oct-04 4.8 NOT PAID8 1 4 29-Oct-04 29-Oct-04 1 PAID8 5 4 29-Oct-04 7.6 PAID9 5 4 29-Oct-04 29-Oct-04 3.5 NOT PAID

PROD_ID PROD_DESC PROD_COSTPROD_PRICE

1 Celestial Cashew Crunch 7.45$ 10.00$

2 Unbrittle Peanut Paradise 5.75$ 9.00$

3 Mystery Melange 7.75$ 10.50$

4 Millionaire’s Macadamia Mix 12.50$ 16.00$

5 Nuts Not Nachos 6.25$ 9.50$

CUST_TYPE_IDCUST_TYPE_DESC

P Private

R Retail

W Wholesale

CANDY_CUSTOMER

CANDY_PURCHASE

CANDY_CUST_TYPE

CANDY_PRODUCT

Overview

Weak entities Relationship degrees E-R diagrams

Chen’s notation Crow’s foot notation

Specialization and generalization

E-R Diagrams

There are many different E-R diagram notations Chen Crow’s foot Bachman UML Plenty of others

Each have their own advantages and disadvantages

We’ll discuss and use Chen’s notation and Crow’s foot notation

Chen’s Notation

Chen’s notation uses the following to illustrate E-R model components Entities are represented using rectangles

Weak entities represented using a double rectangle Attributes are represented using ovals

Keys are underlined Multivalued attributes are represented using a double oval Derived attributes are represented using a dotted oval

Relationships are represented using diamonds Identifying relationships (relationships between strong and

weak entities) are represented using a double diamond Lines are used to link attributes to entities, attributes to

relationships, and entities to relationships

Chen’s Notation

Indicating relationship participation Double line: mandatory participation Single line: optional participation Cardinality

1: at most a single instance participates in the relationship

N (or M): multiple instances may participate in the relationship

Alternatively, an entity’s cardinality “upper bound” (a limit on the number of instances that may participate in the relationship) may be specified above the line and its “lower bound” (a minimum number of instances that may participate in the relationship) may be specified below the line

Chen’s Notation

Example

Overview

Weak entities Relationship degrees E-R diagrams

Chen’s notation Crow’s foot notation

Specialization and generalization

Crow’s Foot Notation

Crow’s foot notation uses the following to illustrate E-R model components Entities are represented using rectangles with 3 stacked

compartments The top compartment contains the entity name Weak entities have no special representation

Attributes are represented within their entity’s compartments The middle compartment contains the entity’s key(s), which may

also include a key indicator (e.g. “PK”) The bottom compartment contains the entity’s other attributes

Multivalued attributes have no special representation Derived attributes have no special representation

Relationships are represented by dashed lines connecting entities A description of the relationship is provided with these lines Identifying relationships are represented using solid lines

Crow’s Foot Notation

Indicating relationship participation Cardinality indicated by line endpoints

Zero or more

One or more

One and only one

Zero or 1

Additionally, an entity’s cardinality “upper bound” (a limit on the number of instances that may participate in the relationship) may be specified above the line and its “lower bound” (a minimum number of instances that may participate in the relationship) may be specified below the line

Crow’s Foot Notation

Example

Chen’s and Crow’s Foot Comparison

Chen’s notation is better suited for conceptual diagrams, as it’s design is more suited for systems that lack detail

Crow’s foot notation is better suited for logical and physical diagrams, as it allows for details that apply in that domain However, it does not support n-ary

relationships or relationship attributes As a result, entities must be used for these

purposes, which we’ll see translates well to a relational database

Overview

Weak entities Relationship degrees E-R diagrams

Chen’s notation Crow’s foot notation

Specialization and generalization

Specialization and Generalization Specialization occurs when multiple

entities are designed to “reuse” the attributes in a single more generic entity

Generalization occurs when a single entity is designed to encapsulate common attributes pulled out of multiple more specific entities

Think inheritance in Java Specialization is a “top down” approach

while generalization is a “bottom up” approach

Specialization and Generalization Example

Overlapping specialization An entity instance can

belong to multiple subentities

Indicated here using multiple arrows

Disjoint specialization An entity instance can

belong to only one subentity

Indicated here usinga single arrow

Entity-Relationship Model Diagrams Create a Chen’s E-R diagram for the following system

UW-Eau Claire keeps data on students including student ID, student name, campus address and phone number, permanent address and phone number, and email address

Data is also kept on courses that are offered, including the course call ID (like ‘CS 260’), course name (like ‘Database Systems’), course description that appears in the catalog, the semester offered (such as "Fall 2014”), section number, day, time, location, and instructor

Instructor data includes instructor ID, name, title, department, office location, and office phone number

Instructors teach course sections, instructors advise students, and students enroll in course sections