Kathleen Durant CS3200 Lecture 2

Similar documents
Chapter 2: Entity-Relationship Model

ER modelling, Weak Entities, Class Hierarchies, Aggregation

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Chapter 8 The Enhanced Entity- Relationship (EER) Model

2. Conceptual Modeling using the Entity-Relationship Model

CSC 742 Database Management Systems

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

Data Analysis 1. SET08104 Database Systems. Napier University

not necessarily strictly sequential feedback loops exist, i.e. may need to revisit earlier stages during a later stage

Unit 2.1. Data Analysis 1 - V Data Analysis 1. Dr Gordon Russell, Napier University

Chapter 7 Data Modeling Using the Entity- Relationship (ER) Model

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

We know how to query a database using SQL. A set of tables and their schemas are given Data are properly loaded

three Entity-Relationship Modeling chapter OVERVIEW CHAPTER

The Entity-Relationship Model

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

Conceptual Design Using the Entity-Relationship (ER) Model

Modern Systems Analysis and Design

The Entity-Relationship Model

Data Modeling. Database Systems: The Complete Book Ch ,

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University

Lecture 12: Entity Relationship Modelling

Requirement Analysis & Conceptual Database Design. Problem analysis Entity Relationship notation Integrity constraints Generalization

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and

Enhanced-ER Data Model

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

Entity-Relationship Model. Purpose of E/R Model. Entity Sets

XV. The Entity-Relationship Model

Foundations of Information Management

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

LiTH, Tekniska högskolan vid Linköpings universitet 1(7) IDA, Institutionen för datavetenskap Juha Takkinen

Converting E-R Diagrams to Relational Model. Winter Lecture 17

IV. The (Extended) Entity-Relationship Model

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. The Relational Model. The relational model

Database Design Process

The Entity-Relationship Model

Entity-Relationship Model

Review: Participation Constraints

BİL 354 Veritabanı Sistemleri. Entity-Relationship Model

Fundamentals of Database System

Relational Schema Design

CS 4604: Introduc0on to Database Management Systems. B. Aditya Prakash Lecture #5: En-ty/Rela-onal Models- - - Part 1

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst

Lesson 8: Introduction to Databases E-R Data Modeling

OVERVIEW 1.1 DATABASE MANAGEMENT SYSTEM (DBMS) DEFINITION:-

Information Systems Modelling Information Systems I: Databases

Database Design Methodology

Database Design Process. Databases - Entity-Relationship Modelling. Requirements Analysis. Database Design

Databases -Normalization III. (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31

Databases and BigData

Concepts of Database Management Seventh Edition. Chapter 6 Database Design 2: Design Method

Data Modeling Basics

Relational Database Basics Review

7.1 The Information system

Umbrello UML Modeller Handbook

A brief overview of developing a conceptual data model as the first step in creating a relational database.

Entity Relationship Diagram

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

2 Conceptual Database Design 2.1 Requirement analysis 2.2 Modeling languages. Terminology. Requirements: Case study. Requirements

Database Design Process

Exercise 8: SRS - Student Registration System

Data Modeling with Entity-Relationship Diagrams

Database Design. Goal: specification of database schema Methodology: E-R Model is viewed as a set of

Why & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements

The Relational Model. Why Study the Relational Model? Relational Database: Definitions


Data Modeling: Part 1. Entity Relationship (ER) Model

Introduction to Database Systems CS4320/CS5320. CS4320/4321: Introduction to Database Systems. CS4320/4321: Introduction to Database Systems

Exercise 1: Relational Model

Designing Databases. Introduction

Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology

Rose Data Modeler (logical)

Principles of of Database Design

LOGICAL DATABASE DESIGN

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

Entity - Relationship Modelling

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1

Entity/Relationship Modelling. Database Systems Lecture 4 Natasha Alechina

Foundations of Information Management

Review Entity-Relationship Diagrams and the Relational Model. Data Models. Review. Why Study the Relational Model? Steps in Database Design

Database Design. Adrienne Watt. Port Moody

Using UML Part One Structural Modeling Diagrams

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints

ER & EER to Relational Mapping. Chapter 9 1

MCQs~Databases~Relational Model and Normalization

Extend Table Lens for High-Dimensional Data Visualization and Classification Mining

Announcements. SQL is hot! Facebook. Goal. Database Design Process. IT420: Database Management and Organization. Normalization (Chapter 3)

Lecture Notes INFORMATION RESOURCES

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Chapter 5: Logical Database Design and the Relational Model Part 2: Normalization. Introduction to Normalization. Normal Forms.

Part 7: Object Oriented Databases

Databases What the Specification Says

The Relational Data Model: Structure

1 Class Diagrams and Entity Relationship Diagrams (ERD)

Chapter 3. Data Analysis and Diagramming

Fundamentals of Database Design

Transcription:

Entity Relationship Model (ERM) Kathleen Durant CS3200 Lecture 2 1

What is the goal of Modeling? Derive a logical description of our data. Understand the various ways in which the data is used. Identify the important or central data. Make decisions about the relationships between data and how to decompose a design. Organize the data to facilitate its uses. Be reasonably efficient. Allow for efficiency of implementation. 2

Why use a model? The data is probably reasonably complex. There are several different sorts of accesses. The data and design will evolve over time: You want a history of this evolution. You want to be able to make changes without constantly dumping and loading your data. Good mental structuring will lead to good physical structure. The act of organizing will make people think of things that got dropped on the floor. 3

How do you develop a model? Steps to model development Identify the entities. Determine all significant interactions. Analyze the nature of the interactions. 4

Entity relationship model (ERM) Maps nicely into a relational data model. Provides a set of terminology and a graphical display of the data. Fairly simple to understand. Alternatives Process and data flow analysis. Seat of the pants methodology. That s sloppy thought Leads to a sloppy database with excessive redundancy, poor performance, and inability to get the job done. 5

The ER Model: Entity Entities: All the world is a set of things. Represented by a rectangle. They have their attributes and relationships. An entity is one object, it is described via its attributes. Entity Set: A collection of similar entities, e.g., all movies. Typically, All entities in an entity set have the same set of attributes. (Exception: ISA hierarchies violate this condition.) Each entity set has a key. 6

The ER Model: Attributes Attributes: Describe the entities. There are many different types of attributes Represented by an oval. Attached to entities with a line. Each attribute has a domain. A set of potential values. Analogies: Fields in a record Elements of a data structure or class object 7

Types of Attribute Simple: indivisible (like a native type). Examples? Composite: decomposable or structured. Examples? Single-valued: only one per entity. Examples? Multi-valued: zero or more per entity. Examples? Represented by a double oval Domain of an attribute: it s possible values Key: subset of attributes that uniquely identifies an entity (candidate key) 8

Example: from IMDB Birthdate Movie Actor Director Title Release Date Name Photo 9

Attribute details Null attributes Do not know the value (NA). Attribute does not exist (e.g., children). Derived values An attribute that can be computed from other attribute(s) Represented by a dashed oval. 10

Example: from IMDB Birthdate Age Movie Actor Director Title Release Date Name Photo 11

Relationships A relationship is a mapping or an association between two or more entities. Relationship represented as a line connecting two entities or entity sets. A Relationship set: a collection of similar relationships, mapping between 2 entity sets. Represented by diamonds Key design issue: distinguishing between entities and relationships -- seems obvious but isn t always. 12

Degree of a Relationship Degree of relationship identifies the number of entities that participate in the relationship. Binary relationships are most common. Higher degree relationships can be modeled as a set of binary relationships. 13

Example: Relationships Birthdate Age Is in Movie Actor Director Title Release Date Role Name Photo 14 Relationships can have attributes too

Relation Constraints: Cardinality The logical structure of the data may impose constraints ERM allows you to represent these constraints Cardinality: defines the relationship between the entities in terms of # s 1 to 1: represented as 2 arrows pointing into the relationship Movie Actor 1 to many: one arrow emanating from the entity set with the cardinality of many (or pointing to the 1 cardinality) Movie Actor Many to many Movie Actor 15

Describe the wacky Movie world Movie Actor Each actor can be in 1 movie and each movie has 1 actor. Movie Actor Each actor can only be in 1 movie but a movie can have 0, 1, or n actors. Movie Actor 16 A movie can have 0, 1, or n actors and an actor can appear in 0, 1, or n movies.

Constraints: Existence Entity X is existent dependent on Entity Y if X can only exist if Y exists. Has implications for deletion: Deleting Y must force delete of X as well. In this example: X is the subordinate entity Y is the dominant entity 17

Constraints: Participation If every entity in an entity set E must be part of a relationship R, then E participates totally (as opposed to partially). Total participation often indicates existence dependencies. Total participation represented by a double line. 18

Existence: Example Assume actors only exist in the IMDB database if they have been in at least one movie If you delete a movie from IMDB Must also delete actors that only appeared in that one movie 19

Types of Keys Superkey: an attribute or set of attributes that uniquely identifies an entity--there can be many of these Candidate key: a superkey such that no proper subset of its attributes is also a superkey (minimal superkey has no unnecessary attributes) Primary key: the candidate key chosen to be used for identifying entities and accessing records. Unless otherwise noted "key" means "primary key Represented with an underline Used for physical clustering of data Alternate key: a candidate key not used for primary key Secondary key: attribute or set of attributes commonly used for accessing records, but not necessarily unique Composite key: a key requiring more than one attribute 20

Example: Keys Actor ID Birthdate Age Actor Role Movie Name Photo Director Title Release Date 21

Weak vs. Strong entity sets An entity set without a primary key is called a weak entity set Represented by a double rectangle Corresponding relationship represented with a double diamond A discriminator (partial key) distinguishes among elements of a weak entity set. An entity set with a primary key is called a strong entity set Members of the strong entity set are dominant; members of the weak entity set are subordinate 22

Example: Weak entity set Scene Actor ID Birthdate Age Number Is in Movie Actor Director Title Release Date Role Name Photo 23

Extended features Specialization Designating subgroups within an entity set (think subclasses or sub-typing). A single entity set can have multiple specializations. Represented using a triangular ISA designator. Generalization Inverse of specialization. Aggregates similar entity sets Represented using a triangular ISA designator. Generalized entity set or the basis of a specialization is called a higher level entity set. (The others are lower level entity sets.) Familiar if you have used objects: Superclass/subclass. Inheritance. If the entire schema has only single inheritance, then the design is a hierarchy. If the schema has multiple inheritance, it is a lattice. 24

Generalization Higher Entity Set Movie Specialization ISA Lower Entity Set Action Drama Comedy 25 ISA function defines a Hierarchy

Generalization constraints Membership Condition-defined: membership in the generalization or (specialization) is based on a predicate. User-defined: membership is defined manually. Cardinality Disjoint: each entity belongs to a single lower level entity set. Single genre for a movie Overlapping: entities may belong to multiple lower level entity sets. Movie classified using multiple genres Completeness Total: every higher level entity must belong to a lower level entity set. All movies have at least one genre. Partial: higher level entities may or may not belong to lower level entity sets. Some movies do not fall into any movie genre. 26

Aggregation When relationship sets have their own relationships Provides a method to build up complicated entities Allows us to treat a relationship set as an entity set Represented as a box around the relationship 27

Example: Aggregation Scene Actor ID Birthdate Age Number Is in Movie Actor Director Title Release Date Role Name Photo Other examples? 28

Summary of Conceptual design Conceptual design follows requirements analysis Yields a high-level description of data to be stored ER model popular for conceptual design Constructs are expressive, close to the way people think about their applications Basic constructs: entities, relationships, and attributes (of entities and relationships) Some additional constructs: weak entities, ISA hierarchies, and aggregation Note: There are many variations on ER model 29

Summary of ER ER design is subjective. There are often many ways to model a given scenario. Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include: Entity vs. attribute Key for the entity / to store or discard an attribute Entity vs. relationship Binary or n-ary relationship Use of ISA hierarchies Use of aggregation 30

Concepts: Part 1 Entity: a thing (abstract or concrete). Relationship: mapping among entities. Enterprise Schema: overall logical schema of a database. Entity set: a collection of entities all of which have the same attributes. Relationship set: the mapping between entity sets Extension: the individual entities that comprise an entity set. Attribute(s): properties that describe an entity or relationship. Domain (value set): permitted values of an attribute. Simple attribute: indivisible type. Composite attribute: attribute may be further broken down into subfields. Single-valued attribute: only one entry for the attribute of a specific entity. Multi-valued attribute: may have multiple entries for the attribute, all for a specific entity (e.g., phone numbers: work, home, cell, fax). Derived attribute: attribute whose value can be determined based upon other data (e.g., a database that includes birthdate and age; age can be a derived attribute given birthdate). Base attribute: an attribute from which you derive another attribute. Descriptive Attributes: attributes added to a relationship. 31

Concepts: Part 2 Participation: the act of an entity belonging to a relationship Total participation: all entities participate in the relation. Partial participation: not all entities participate in the relation. Role: when an entity has a relationship with itself. The role distinguishes how an entity is treated in a relationship. Mapping cardinality (1:1, 1:many, many:1, many:many) Existence dependencies: requiring an entity to exist if another entity exists. Subordinate entity: the dependent entity in an existence dependency. Dominant entity: the entity on which the subordinate entity exists. 32

Concepts: Part 3 Superkey: a set of attributes that uniquely identifies an entity. Candidate key: the minimal set of attributes that forms a superkey. Primary key: a designated candidate key. Weak entity set: an entity set without a candidate key. Strong entity set: an entity set with a candidate key. Discriminator: a set of attributes that distinguishes between the elements of a weak entity set. 33

Concepts: Part 4 Specialization: extracting a subclass from an entity set. Generalization: combining one or more entity sets into a higher level entity. Disjoint generalization: an entity belongs to at most one lower level entity set. Overlapping generalization: entities may belong to multiple lower level entities. Hierarchy: each entity set is only the object of one ISA relationship. Lattice: entity sets may belong to multiple ISA relationships. Condition-defined constraint: defines membership in a subclass via a predicate. User-defined constraint: membership is manually defined. Completeness constraint: all entities belong to a lower level entity. Total constraint: all entities belong to lower level entity sets. Partial Constraint: entities not required to belong to lower level entity set. Aggregation: grouping part of a schema into a larger unit. 34

In Class Work Layout an ERM diagram for a university. The university consists of a number of departments, in particular (Engineering, Humanities, Math, Science). Each department offers several majors. A collection of courses define the minimal collection of courses that satisfy a specific major. Students declare a specific major and take courses towards the completion of that major. Each course is taught by a professor from the appropriate department. 35