Database Design – Lecture 4 Conceptual Data Modeling – adding attributes

Lecture Objectives How to correctly define attributes for an entity Determining the key structure of an entity Refining relationships between entities based on Business Rules

Attributes Characteristics of entities In Chen model, attributes are represented by ovals and are connected to entity rectangle with a line Each oval contains the name of attribute it represents In Crow’s Foot model, attributes are written in attribute box below entity rectangle

Attributes ERD Notation

Attributes Should be meaningful Rule of thumb is to prefix attribute with entity name i.e. CUSTOMER_NAME versus NAME Can be single valued An attribute that can have only a single value i.e. social insurance number Can be multivalued An attribute that can have many values i.e. an employee has many skills

Derived Attributes Attribute whose value may be calculated (derived) from other attributes Need not be physically stored within database Can be derived by using an algorithm Can show in the conceptual model

Derived Attributes

Primary Keys Should uniquely identify each entity instance Can not be nulls Should preferably be numeric Should have the minimum number of attributes possible

Composite Primary Keys To satisfy M:N relationship When identifying a weak entity

RELATIONSHIP Strength Existence dependence Entity’s existence depends on the existence of one or more other entities Obvious here that a DEPENDENT can not exist without a PARENT Characteristic: strong relationship, with dependent entity being a weak entity, the parent entity being a strong entity

RELATIONSHIP Strength Strong (Identifying) Relationships Related entities are existence-dependent Primary key of parent entity is part of the primary key of the child entity In Visio, denote the identifying (solid line) relationship by selecting Identifying in the Database Properties

RELATIONSHIP Strength Existence independence Entity can exist apart (independent) from one or more related entities A PLAN can exist whether there is a CLIENT or not Characteristic: weak relationship, strong entities

RELATIONSHIP Strength Weak (non-identifying) relationships One entity is not existence-independent on another entity Primary key of parent entity is not part of the primary key of the child entity In Visio, denote the non-identifying (dashed line) relationship by selecting Non-identifying in the Database Properties

Relationship Participation Optional: One entity occurrence does not require a corresponding entity occurrence in a particular relationship Mandatory: One entity occurrence requires a corresponding entity occurrence in a particular relationship

Binary Relationships Most common type of relationship Types: 1:M relationship M:N relationships

Binary Relationships 1:1 relationship: 1:M relationship: PK from each table becomes FK of the related table 1:M relationship: PK from the ‘1’ table becomes FK of the ‘M’ table M:N relationship: Create a bridge table PK of the bridge table is a composite primary key made up of the PK of each of the related tables Bridge table may also contain additional attributes

Binary Relationships Bridge Table needed. It will contain the primary keys from the other two entities as its primary key – a composite primary key. These primary keys will also be foreign keys at the same time

Developing an ER Diagram Database design is iterative rather than linear or sequential process Iterative process Conceptual Model: Entities, Relationships Logical Model: Entities, Attributes, Relationships, PKs and FKs identified

Developing an ER Diagram Building an ERD usually involves the following activities: Create detailed narrative of organization’s description of operations Identify business rules based on description of operations Identify main entities and relationships from business rules Develop initial ERD Identify attributes and primary keys that adequately describe entities Revise and review ERD

Summary Entity relationship (ER) model Uses ERD to represent conceptual database as viewed by end user ERD’s main components: Entities Attributes Relationships Includes connectivity and cardinality notations M:N relationship is valid at conceptual level (providing there is not an attribute that represents the intersection of the two entities)