Conceptual DB Design Conceptual database design ERDs Agenda

Conceptual DB Design Conceptual database design ERD’s

Agenda: Attributes & related concepts l Attribute l Characteristics (qualities, properties) of an entity, or of a relationship l l There are many ways to describe attributes Related concepts l l Identifiers (attributes that identify rows) Domain (“value set”) § allowable values for attributes

Diagramming an attribute l Our notation: rectangle under the entity name Underline the primary key Employee. ID Name Title Birth. Date … Show all attributes – I shortened the list of attributes here for display purposes but your diagram should show them all.

Entity/Attribute Example: l l Patient (Pt_ID, Last. Name, First. Name, SSN) Lab. Result (Lab. Result_ID, Pt_ID, Lab. Date, Lab. Value) Patient Pt_ID Last. Name First. Name SSN Lab. Result_ID Pt_ID Lab. Date Lab. Value Lab. Result_ID is surrogate key; instead of the composite of Pt_ID, Lab. Date, Lab. Value

All attributes are not the same l Attributes can be characterized in various ways l l l Simple or composite (compound) Single valued or multi-valued Derived or stored Identifiers Relationship attributes or entity attributes

Simple & Composite Attributes l Simple attribute: one component l l Account. Number Composite attribute: multiple components each of which could have an independent existence l l Address = Street, City, State, Zip Will users need to access any of the individual components (e. g. , sort by zip code)?

Composite Attribute l Group of attributes l l Some authors list the components together Address (street, city, state, zip) My preference: either list components as separate attributes, or just wait for logical design.

Single & Multi-valued attribute l Single-valued: an attribute holds a single value for each entity instance l l Date of birth (attribute) Multi – valued: an entity instance (e. g. 1 person) could have more than one of this attribute l Phone number (home, work, fax…)

Stored vs. Derived l Stored l l In the database Derived l l 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 l l Glasgow Coma Scale (add up each part) Current Age (current date – date of birth)

Derived Attributes l l l Some say do not put derived attributes on ERD. Some say put on ERD and then specify later that it’s a derived attribute. I do whichever approach will help me communicate with my users best

Identifier (Key) l Attribute that uniquely identifies one instance of the entity l l 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 l UML marks the key with a tag l l l {PK} {AK} Primary Key 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 l Primary keys l l l Alternate keys l l Underline Place at top of list of attributes Like any other attribute Foreign keys l l Link to another table Don’t add to ERD (we’ll deal with them later). Only should be on ERD if part of the PK.

Strong/Weak Entity Types l Strong l l l Have an intrinsic primary key Does not depend on another entity for existence Weak l l 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 l Rectangle with name inside top part (Name compartment) Strong l Weak entity: double line or thick line (I avoid whenever possible) Weak

Relationship Attributes l A relationship can have attributes – not a attribute of either entity separatly, but a property of the relationship l l l Newspaper advertises Property. For. Rent The Advertisement has a date and a cost Diagramming l l 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 Unit. Price 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 l l l 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 l l specific list (A, B, C) a set of coded values – perhaps listed in another table (any value from xxx table)

Domain l Business rule – how things are “done” IN THIS ORGANIZATION l Some can be enforced through technology (all SBP values must be positive integer (>=0) and must be <= 350) l 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 l First Name l l Birth date l l Sally, Frank, Jessie (specific names) All first name in use in USA Text of maximum length = 25 1/2/54, 4/17/82 (formatted with 2 digit year) All dates after 1/1/1900 (range) Date type (general) Shippers l from lst. Ship table

Values l l 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 l l l 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 l Domain for strength is “weak, strong, absent”

Review l l l Entity: will become the TABLE Instance: will become the ROW (don’t put on ERD) Attribute: will become the COLUMN NAME (header) l l l Primary Key: Unique identifier for a row Value: will become the actual data in a cell Relationship: how tables interact. l We will use the relationships in the logical design process to determine where to put foreign keys.

Naming Conventions l Entity l Singular noun l Attributes l l l Relationship l l Verb phrase Label both directions (most of the time) Singular noun (usually) Plural noun can be used to indicate multi-valued attribute

A Note about Naming l l 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 l l 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 l l Be neat Be consistent (e. g. entity width, fonts) Entity name centered, attributes left align Align entities where feasible

Assumptions l l Text notations that help to understand or clarify the drawing Short note on the drawing

l Steps to create ERD’s (not necessarily in this order) l l l Create entities Create relationships Add cardinalities Add attributes to entity Identify primary keys Add assumptions, notes, title

Avoiding Problems with your ERD l l 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