Database Design Lessons 2 & 3 Database Models, Entities, Relationships

Database Design Conceptual Analysis What Logical Design How Physical Build Data Information

An Entity Something of significance to business about which data must be known A name for the things that you can list A single name of noun Entities have Instances Occurrences of entities Rows

Entities vs. Instance Entities can be: Tangible, like Person or Product Nontangible, like skill level An event, like concert, graduation, wedding Instance examples: Animal entity instances like, Dalmatian, Siamese cat, cow, tiger Car entity instances like, sedan, station wagon, SUV, convertible

Examples Entity = Product New York = instance Director can be either an entity or instance – context is important

Attributes Entities have Attributes Single-value property, detail of an entity Piece of information that describes, qualifies, quantifies, classifies and/or specifies an entity Property of an entity Attributes have a data type

Attributes Describe an entity Attribute vs. attribute value color vs. blue animal type vs. dog Can have one and only one value at a given point in time One or more attributes must be defined as a unique identifier (UID)

Unique Identifier (UID) Used to distinguish one instance of an entity from another Example: Student ID as a UID for student entity part number as a UID for product entity Social security number (UID) for employee Denote with a #

Attributes Must be a single-values at any point in time Should be stored in one and only one entity Values have data type Example: entity CAR may have attributes model & color (values of beetle, green) An attribute may change over time

Attribute Volatile may change with time, like age should look for non-volatile attributes like birth date rather than age Mandatory vs. Optional address mandatory for EMPLOYEE if modeling application address optional for CUSTOMER is modeling an online catalog

Entity relationship diagram (ERD) Visual way to display business requirements Tool used in design stage Used to react to, validate, and correct data in database Entities should be implemetation- free

Relationship Represents something significant to a business Expresses how entities are mutually related Always exist between entities Always have two perspectives Is named at both ends Between two entities (or one entity and itself) Have an optionality Have a degree or cardinality

Conventions Entities appear as all capital letters and singular Relationships are italicized Entities are placed in soft boxes (rounded corners) Examples: EMPLOYEE hold JOBs JOBs are held by EMPLOYEEs PRODUCTs are classified by a PRODUCT TYPE PRODUCT TYPE classifies a PRODUCT

Optionality of relationships A relationship adds a link between entities Relationships come from business rules Is it a mandatory or optional relationship

Optionality of relationships Are either Mandatory or Optional Mandatory value is a REQUIRED field Use MUST to describe Denoted with an * and a solid line Optional value may be supplier or not Use MAY to describe Denoted with a ° and a dashed line Example: Each DEPARTMENT must have one or more EMPLOYEEs Each DEPARTMENT may have one or more EMPLOYEEs

Identifying Relationships Cardinality or Degree of relationship Describes how many? Use one and only one or one or more use crow foot to denote one or more in ERD Examples: Each DEPARTMENT may have one or more EMPLOYEEs Each EMPLOYEE must be assigned to one and only one DEPARTMENT See ERD on next slide

ERD Entities use soft boxes DEPARTMENT # ID o name o location EMPLOYEE #ID * first name * last name o telephone number o salary * job hire assigned to

Examples: Each SEAT may be sold to one or more PASSENGERs this example accounts for overbooking Each PASSENGER may purchase one and only one SEAT

Entity naming Name must be unique Create a description of the entity (be explicit) Be aware of homonyms Market = 16 to 25 years Market = Europe, Asia etc. Avoid reserved words Remove the relationship name from the entity name

ERD conventions - summary Entities go in soft boxes Entity names are singular and written in all capital letters Attributes go under Entity # is a UID (unique identifier – Key) * mandatory attribute o optional attribute

ERD conventions - summary Relationships are lines (optionality) solid are mandatory dashed are optional Lines terminations express cardinality single toe denotes one and only one crows foot denotes one or more

Example Each HAIRSTYLIST may work on one or more CLIENTs Each CLIENT must be assigned to one and only one HAIRSTYLIST See next slide to ERD

ERD diagram List entity and attributes HAIRSTYLIST # id * first name *last name * address * phone number * social-security number * salary CLIENT # client number * first name o last name o phone number work on assigned to

Conventions Not a strict requirement (can reverse) this crow is flying east this crow is flying south

Matrix Diagram 3.4 TRAVELERCOUNTRYLANDMARK TRAVELERVisitHave seen COUNTRYVisited byThe location of LANDMARKSeen byLocated in

ERD TRAVELER COUNTRY LANDMARK visit visited by have seen seen by the location of located in

Previous ERD Note ERD included optionality and cardinality Note there are several M:M relationship. This is a valid relationship, but discussed in later chapters