Data Modeling and Entity- Relationship Model I IST2101

Question: Where do relations come from? IST2102 Suppose you are now designing database for a company, how should you systematically turn user requirements into actual relations?

IST2103 I want a database to maintain departments in my company. Store information about my employees, their projects and assignments. I want …. $$$ User requirement A database YOUR JOB!

Use Normalization Process to Design a Database? One Approach 1.List all data attributes that will be involved – OwnerID, OwnerName, Owner , PropertyID, PropertyName, PropertyAddress 2.Develop functional dependencies – OwnerID  (OwnerName, Owner ) – PropertyID  (PropertyName, PropertAddress, OwnerID, …) 3.Normalization process IST2104

What if we have many attributes? Sample attributes in user requirements: – DepartmentName, BudgetCode, OfficeNumber, Phone, EmplyeeNumber, FirstName, LastName, Department, Phone, , ProjectID, ProjectName, Department, MaxHours, StartDate, EndData, ProjectID, EmployeeNumber, HoursWorded… Problems of this (top-down) approach – Lack of a systematic approach to identify all relevant attributes – Entities and relationships are mixed together

IST2106 I want a database to maintain departments in my company. Store information about my employees, their projects and assignments. I want …. $$$ User requirement A database YOUR JOB! Data Modeling (Ch.4) Data Modeling (Ch.4) Database Design (Ch.5)

A Two-Step (Bottom-Up) Approach: Step 1 IST2107 Input: User requirement; Output: E-R Diagram Use Entity-Relationship Diagram (E-R Diagram) to capture all user requirements Data Modeling (Ch.4) Data Modeling (Ch.4) Database Design (Ch.5)

A Two-Step (Bottom-Up) Approach: Step 2 IST2108 Data Modeling (Ch.4) Data Modeling (Ch.4) Database Design (Ch.5) Input: E-R diagram; Output: A database Transferring a data model to a relational database Entities  Relations Relationships  Foreign keys and extra

Three Stages of Database Development IST2109 State 1. Requirements Analysis Stage 3. Database Design Stage 2. Entity-Relationship Model Why can’t we skip stage 2? E-R model is a prototype of actual database system. The prototypes are used to obtain feedback from system users * Logical Stage * Physical Stage

Three Stages of Database Development Requirements Analysis Stage – Users are interviewed – Obtain sample forms, reports, queries, … Component Design Stage – Create a data model – Data model: a presentation of the content, relationships, and constraints of the data needed to support the requirements Implementation Stage – Data model transformed to database design – Database design: tables, relationships, and constraints – Database constructed and filled with data; queries, forms, and reports are created; application programs are written; and all these are tested – Users trained, documentation written, system installed for use IST21010

The Requirements Stage Sources of requirements: – User Interviews – Forms – Reports – Queries – Business Rules – Use Cases Stories/Scenarios Important for validating the data model, design, and implementation IST21011

Requirements Become the E-R Data Model After the requirements have been gathered, they are transformed into an Entity Relationship (E-R) Data Model E-R Models consist of – Entities – Attributes – Identifiers – Relationships IST21012

Component 1: Entities An entity or entity class is something that users want to track – Customer, Order, Product An entity instance is a specific occurrence of an entity class – A customer John, an order 10021, a product A42300 IST21013

Component 2: Attributes An entity has attributes that describe the entity’s characteristics – ProjectName – StartDate – ProjectType – ProjectDescription Each attribute has a data type and properties. – Data type: string, number, date, … – Property: default value, value range, … IST21014

Component 3: Identifiers Entity instances have identifiers An identifier will identify a particular instance in the entity class – SocialSecurityNumber – StudentID – EmployeeID Identifier can be considered as the primary key in a relation IST21015

Draw an Entity IST21016 Entity Name  Attributes  Identifier 

In-Class Exercise A-1: Entity IST21017 I want a course registration database. Store information about my students, including their IDs, names, and s. A course should have information about course ID, course name, and instructor name. 1.How many entities do you need? 2.Draw a diagram for each entity using the presentation in the previous slide

In-Class Exercise B-1: Entity IST21018 I am the manager for apartment rental office. I want a database to maintain all my apartments. Each apartment building will have a building ID, name, address, city, state, and zip code. A building have many apartments. An apartment have an apartment number, number of bedrooms, number of bathrooms, and monthly rent cost. 1.How many entities do you need? 2.Draw a diagram for each entity

Component 4: Relationships Entities can be associated with one another in relationships Relationship degree defines the number of entity classes participating in the relationship – Degree 2 is a binary relationship Most relationships we study in this course will be binary relationship – Degree 3 is a ternary relationship – Degree 1 is a recursive (unary) relationship IST21019

Degree 2 Relationship: Binary VIDEO CLIP USER IST21020 Create/Be Created CLASS STUDENT Register

Degree 3 Relationship: Ternary VIDEO CLIP USER COMMENT IST21021

Degree 1 Relationship: Recursive/Unary USER Friending IST21022

Binary Relationship Cardinality Relationships are named and classified by their cardinality, which is a word that means count – Maximum Cardinality One-One, One-Many, Many-Many – Minimum Cardinality Optional, Mandatory IST21023

Maximum Cardinality maximum cardinality is the maximum number of entity instances that may participate in a relationship instance — one, many or other some fixed number – BASKETBALL-TEAM and PLAYER could be 1:5 IST21024

One-to-One Binary Relationship 1:1 (one-to-one) – A single entity instance in one entity class is related to a single entity instance in another entity class An employee may have no more than one locker; and A locker may only be accessible by one employee IST21025

One-to-Many Binary Relationship 1:N (one-to-many) – A single entity instance in one entity class is related to many entity instances in another entity class A video in YouTube is uploaded by one user; and A user may upload several videos. USERVIDEO 1:N UPLOAD IST21026

Many-to-Many Binary Relationship N:M (many-to-many) – Many entity instances in one entity class is related to many entity instances in another entity class A YouTube user may subscribe several channels; and A particular channel may be subscribed by several users. USER CHANNEL N:M SUBSCRIBE IST21027

Maximum Cardinality: Crow’s Foot Notation IST21028 USERVIDEO USER CHANNEL EMPLOYEELOCKER OneMany (crow’s foot) Attention: do not misplace one and many notations An employee has (at most) one locker; a locker can belong to (at most) one employee A user can upload many videos; a video can be uploaded by (at most) one user A user can subscribe to many channels; a channel can be subscribed by many users upload subscribe

How to Determine Maximum Cardinality? IST21029 USERVIDEO USER CHANNEL EMPLOYEELOCKER Attention: do not misplace one and many notations An employee has (at most) one locker; a locker can belong to (at most) one employee A user can upload many videos; a video can be uploaded by (at most) one user A user can subscribe to many channels; a channel can be subscribed by many users upload subscribe User requirements Common Sense

In-Class Exercise: Maximum Cardinality IST21030 In-Class Exercise A-2 Draw a line between STUDENT and COURSE Draw the Maximum Cardinality on the line using Crow’s foot notation In-Class Exercise B-2 Draw a line between BUILDING and APARTMENT Draw the Maximum Cardinality on the line using Crow’s foot notation