1. Conceptual database design ERD’s
Conceptual DB Design
Conceptual database design
ERD’s

2. Agenda Review – modeling principles Conceptual design overview
High level look at various ways to draw ERDs
Detailed look at how we will draw ERD in this class
Components of an ERD
Drawing techniques for the ERD in this course

3. Abstraction & Modeling
Abstraction: Mental processes through which we concentrate upon common properties of data disregarding all irrelevant details
Modeling: A way to represent an abstraction
Simplified picture
Hide details until needed

4. Desired Features of Models
Expressiveness
Detailed representation of requirements
Simplicity, easily understood
Minimality
Not specific to one particular technology
No redundancy, eliminate extraneous information
Smallest common denominator – don’t have two parts that equal each other
Formality
Formal notation/diagram
Well defined, consistent with enterprise definitions and organization
Few models are really optimal, usually a trade-off. For example, in trying to achieve expressiveness we may lose some simplicity.

5. Conceptual Design
Definition: Constructing a model of the data and information, independent of all physical considerations
Purpose: Communicate with the users; understand details of the user requirements; understand the nature of the data itself; understand how data will be used across user views.
End goal is to determine the entities and attributes that will be stored in our database, and the relationships between the entities
We represent conceptual design with an ERD (entity relationship diagram)
Connolley & Begg, p. 281

6. Entity-Relationship Diagram
OK, let’s talk about the diagram itself next.

7. Diagram Notation Graphical representation of conceptual data model
Many methods of drawing are found in the literature
Classic
Crow’s feet
UML Class Diagram
This course notation
Song, Evans, and Park (1995) compared 10 different notations. They found variations in:
Representation of n-ary relationships
Representation of relationship attributes
Representation of cardinalities (min and max)
Placement of cardinalities
Representation of subclass entity types
Representation of specialization
Representation of foreign keys
Representation of primary key
Representation of weak entities

8. ERD (Classic)
Attributes each in an oval, connected to entity (rectangle), relationship between entities indicated by a diamond. Primary key underlined.
This is a “classic” notation. Uses Look Here notation (although you can’t really tell from above—Student has many class, place the cardinality next to student). PK is underlined, relationship in a diamond.Attributes are in an oval scattered around the entity.
Problems: can get very crowded, large “footprint” especially if many attributes.
Harder to locate the line that is the relationship (vs. the line connecting an attribute)
Problems: Can get crowded, large footprint. Hard to locate the relationship (many lines). Look Here cardinality notation (discussed later) can be confusing.

9. ERD (Crow’s feet)
Single line represents one, split line represents many.
Shows relationship type (1:1 or 1:M) but not cardinality (discussed later) PK underlined. Double box = weak entity (discussed later).
Adapted from McFadden et al., 1999

10. ERD (MS Access)
Number 1 represents one, infinity symbol represents many. Shows relationship type (1:1 or 1:M) but not cardinality. PK in bold.
M:M relationship not allowed
Problems: Weak entity has no indication. Can’t do M:M relationship. Can’t use for conceptual design—you can’t make an ERD before you build tables.

11. ERD (UML Class Diagram)
Top box is entity, Middle box has attributes, including data type
Bottom has activities/processes (behavior)
Problems—conceptual phase is independent of physical considerations (don’t do attribute data type yet); we don’t need the behavior/processes (that’s for object oriented programming); relationship verb only for the primary direction; inconsistent– cardinality shows min and max, like (0,*) EXCEPT (1,1) cardinality just shows a single 1
We use a modified UML notation. Minimizes the space on the page, more consistent, more intuitive
UML: Unified Modeling Language
Object Management Group (OMG) standard
Issues: conceptual design is independent of physical considerations (so we may not know data types). We don’t need behavior/processes (for OO programming). Relationship only has verb one direction but cardinality in both directions; small nuances of cardinality representation are inconsistent--shows min and max EXCEPT (1,1) is shown as 1

12. ERD (This Course)
Modified from UML. Top box is entity, Middle box has attributes. Underline PK
Relationship articulated both directions
Relationship structure: (entity) verb, arrow, cardinality (entity)
reads intuitively Student to class: Student takes (min of 0 and max of many) classes Class to student: Class has (min of 0 and max of many) students
We use a modified UML notation. No “behavior” box, don’t show the data types/default values etc. (in most cases). Label relationship both directions.

13. ERD components Entities Relationships Attributes
Instances – do not show on ERD (but may be helpful to think of example instances in thinking through the situation)
Relationships
Attributes
Structural constraints (cardinality)
Assumptions, Notes

14. ER Model Components Entity, attribute, relationship Instance
explain the STRUCTURE of the data
changed by DB designer or developer
Instance
Uniquely identifiable object of an entity type
explains the actual data (CONTENT) at any given time
changed by the end-users
Instance
Uniquely identifiable object of an entity type
Data actually in the database at any given time
Example: if entity is car, and attributes are owner, color, make, model, then the instance that corresponds to my car is Sward’s silver Subaru Impreza

15. Entity also called “entity type” or concept
Group of objects or concepts with same properties
Identified by the enterprise as having an independent existence.
Will eventually become tables

16. Entity Examples of physical entities/objects (“real” objects)
Person
Medication
Lab tests
Examples of conceptual entities (“abstract” objects)
Order
Work experience
Hint: I think of entities as the “nouns” of our DB—the person, place, thing, or idea about which we want to store data

17. HW - Entities
I own a small business that provides disposable supplies to a simulation center. Disposable supplies are items such as bandages, pretend medications, etc. that are used up during the course of simulation practice. I need to keep track of information about my employees and customers. Currently I have a paper-based system. Employee information is contained in handwritten papers that are grouped into folders by employee. Customers place orders for our products, these orders are tracked in order forms that are sorted chronologically by order date. Products are shipped by multiple companies including FedEx and UPS.
I would like to be able to mail advertisements to my customers. Unfortunately, my handwriting is sometimes difficult to read, and it takes quite a bit of time to go through all of the order forms to transcribe customer addresses and to get rid of duplicate addresses. In addition, I am having difficulty answering the following type of questions for my business:
What are my employee teams? (Which employees work for each of my managers?)
For each order, which products were ordered?
For each order, what was the unit price at the time of order, and how many units were ordered?
How did I ship each order?
I plan to create a relational database to store my customer and employee information. This database does not need to interface with any other information systems at the present time. Data to be stored about customers includes name and contact information (address, phone, and fax). Data about employees must include name, address, birth date, phone numbers, and hire date; in addition I want to store data about salary and tax withholding changes. I also need to track products and orders.
From this database, my goal is to obtain, at minimum, answers to the questions above. Creating this database is anticipated to improve my efficiency and reduce inaccuracies that were caused by hand calculations and inability to decipher my handwriting.

18. Diagramming an Entity Employee Rectangle labeled with the entity name
Usually a singular noun
First letter upper case
Short but descriptive and meaningful
Employee