Conceptual DB Design

Conceptual database design

ERD’s
Agenda: Attributes & related
concepts
 Attribute
 Characteristics (qualities, properties) of an entity,
or of a relationship
 There are many ways to describe attributes
 Related concepts
 Identifiers (attributes that identify rows)
 Domain (“value set”)
 allowable values for attributes
Diagramming an attribute
 Our notation: rectangle under the entity name
Underline the primary key
Employee Show all attributes – I shortened
EmployeeID the list of attributes here for
Name display purposes but your diagram
should show them all.
Title
BirthDate
…
Entity/Attribute Example:

 Patient (Pt_ID, LastName, FirstName, SSN)

 LabResult (LabResult_ID, Pt_ID, LabDate,
LabValue)

Patient LabResult LabResult_ID is

Pt_ID LabResult_ID surrogate key; instead
Pt_ID of the composite of
LastName
Pt_ID, LabDate,
FirstName LabDate LabValue
SSN LabValue
All attributes are not the same
 Attributes can be characterized in various
ways
 Simple or composite (compound)
 Single valued or multi-valued
 Derived or stored
 Identifiers
 Relationship attributes or entity attributes
Simple & Composite Attributes
 Simple attribute: one component
 AccountNumber
 Composite attribute: multiple components
each of which could have an independent
existence
 Address = Street, City, State, Zip
 Will users need to access any of the individual
components (e.g., sort by zip code)?
Composite Attribute
 Group of attributes
 Some authors list the Student
components together
Address (street, city, state, zip) SSN
Name
 My preference: either list Age
Address
components as separate Major
attributes, or just wait for Advisor
Required Credits
logical design.
Single & Multi-valued attribute
 Single-valued: an attribute holds a single
value for each entity instance
 Date of birth (attribute)
 Multi – valued: an entity instance (e.g. 1
person) could have more than one of this
attribute
 Phone number (home, work, fax…)
Stored vs. Derived
 Stored
 In the database
 Derived
 Value can be determined from the value of a
related attribute; calculated values
 May use data in database or other data such as
date or time
 Glasgow Coma Scale (add up each part)
 Current Age (current date – date of birth)
Derived Attributes
 Some say do not put derived
Student
attributes on ERD.
 Some say put on ERD and SSN
then specify later that it’s a Name
DOB
derived attribute. age
Street
 I do whichever approach City
will help me communicate State
Zip Code
with my users best Major
Advisor
Required Credits
Identifier (Key)
 Attribute that uniquely identifies one instance
of the entity
 Candidate Key(s) are the attribute/attribute sets
that could uniquely identify an instance
 “Best” candidate becomes Primary Key
 Other candidates become Alternate Key
 Diagramming: underline the primary key, do
not specify alternate keys (we’ll come back to
them in logical design, though)
Diagramming attributes
 UML marks the key with a tag
 {PK} Primary Key
 {AK} Alternate Key
 We underline the PK, don’t specify alternate
 For this class show all the attributes of an
entity
 In real life some people just show the keys or
a partial list of attributes
Identifiers
 Primary keys
Student
 Underline
 Place at top of list of SSN
attributes Name
DOB
 Alternate keys age
 Like any other attribute Street
City
 Foreign keys State
Zip Code
 Link to another table Major
 Don’t add to ERD Advisor
Required Credits
(we’ll deal with them
later). Only should be on
ERD if part of the PK.
Strong/Weak Entity Types
 Strong
 Have an intrinsic primary key
 Does not depend on another entity for existence
 Weak
 No intrinsic primary key
 Can’t exist without a strong entity (“existence
dependent”)
Example of weak entity: Employee_Dependents (Name, relationship, gender)
What is primary key? For each employee, it’s probably the dependent’s name.
But that’s not unique within the table (both you and I could have kids with the same
name)
Could make this weak entity strong by adding Employee’s ID#
Strong/Weak Entity
Class
 Rectangle with name inside Semester

top part (Name compartment) Class Number

Class Name
Credits
# Students Strong
Schedule
Max Enrolled
 Weak entity: double line or
thick line (I avoid whenever
possible)
Student
Major
Advisor
Required Credits
Weak
Relationship Attributes
 A relationship can have attributes – not a attribute of
either entity separatly, but a property of the
relationship
 Newspaper advertises PropertyForRent
 The Advertisement has a date and a cost
 Diagramming
 The text uses an un-named rectangle attached by a
dashed line—but this can look on your diagram like an
entity
 OUR NOTATION: We place the attributes with the
relationship name, within square brackets
Relationship Attributes
Order
OrderID Product
OrderDate
RequiredDate [UnitPrice, Quantity] ProductID
ShippedDate contains --> (1,*) ProductName
ShippedVia (0,*) <-- sold in CategoryName
. CategoryDescription
ReorderLevel
QuantityPerUnit

UnitPrice and Quantity are attributes of the relationship—they

apply to products at the time they are sold in a specific order.
They are not attributes of orders in general
They are not attributes of products in general
Domain
 Allowable values for the attribute
 Examples:
 a data type (text, integer, real number, date)
 a data type with limits (real number >100.0)
 a data type with a business rule *
 an enumerated list
 specific list (A,B,C)
 a set of coded values – perhaps listed in another table (any
value from xxx table)
Domain
 Business rule – how things are “done” IN THIS
ORGANIZATION
 Some can be enforced through technology (all SBP values
must be positive integer (>=0) and must be <= 350)

 Some cannot be enforced through technology. These

are enforced through policy or procedure (“people” means).
Example – “the last name field must be an actual person’s
last name, not a random string of letters”
Domain
 First Name
 Sally, Frank, Jessie (specific names)
 All first name in use in USA
 Text of maximum length = 25

 Birth date
 1/2/54, 4/17/82 (formatted with 2 digit year)
 All dates after 1/1/1900 (range)
 Date type (general)

 Shippers
 from lstShip table
Values

 Comes from the domain

 A value is not the same as an attribute!
 The attribute is the property or category
 A value is a specific selection from the
attribute domain, relevant to a specific
instance of the entity
Values

 If you answer Yes/No, you are probably

looking at a value, not an attribute, especially
if you can only say yes to one of the choices
 Hand grasps (SSN, weak, strong, absent)
WRONG
 Hand grasps (SSN, strength) RIGHT
 Domain for strength is “weak, strong, absent”
Review
 Entity: will become the TABLE
 Instance: will become the ROW (don’t put on ERD)
 Attribute: will become the COLUMN NAME
(header)
 Primary Key: Unique identifier for a row
 Value: will become the actual data in a cell
 Relationship: how tables interact.
 We will use the relationships in the logical design process
to determine where to put foreign keys.
Naming Conventions
 Entity  Attributes
 Singular noun  Singular noun (usually)
 Plural noun can be used
 Relationship to indicate multi-valued
attribute
 Verb phrase
 Label both directions
(most of the time)
A Note about Naming
 Keep names short but clear.
 Be consistent
 Avoid common “reserved words” (functions,
data types…)
 Recommend: Begin with a letter, no spaces,
no symbols other than underscore (this
format is acceptable across most DBMSs)
Drawing conventions
 Underline Primary Key
 Don’t worry about foreign keys yet!
 Relationship is line between entities. Try to
avoid crossing lines. No arrow on relationship
line for basic ERD (arrows go above/below)
 Cardinalities go both directions at the point of
arrow – above/below the line

has  (1,*)
(1,1)  belong to
General Drawing Principles
 Be neat
 Be consistent (e.g.
entity width, fonts)
 Entity name centered,
attributes left align
 Align entities where
feasible
Assumptions
 Text notations that help to understand or
clarify the drawing
 Short note on the drawing
 Steps to create ERD’s (not necessarily in this
order)
 Create entities
 Create relationships
 Add cardinalities
 Add attributes to entity
 Identify primary keys
 Add assumptions, notes, title
Avoiding Problems with your
ERD
 Model DATA, not processes
 Don’t put “reports” on the ERD. Think
about the data that go into the report, instead
 Think about your cardinalities.
 Know the difference between attributes and
values/domain