Exam 1 Review Dr. Bernard Chen Ph.D. University of Central Arkansas.

Slides:



Advertisements
Similar presentations
© Shamkant B. Navathe CC. © Shamkant B. Navathe CC Chapter 4 - Part I Enhanced Entity-Relationship and UML Modeling Copyright © 2004 Ramez Elmasri and.
Advertisements

1 Class Number – CS 304 Class Name - DBMS Instructor – Sanjay Madria Instructor – Sanjay Madria Lesson Title – EER Model –21th June.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4- 1.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4- 1.
Enhanced Entity-Relationship and UML Modeling
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 4 Enhanced Entity-Relationship (EER) Modeling.
1 Enhanced Entity Relationship Modelling EER Model Concepts Includes all basic ER modeling concepts Additional concepts: subclasses/superclasses specialization/generalization.
December 4, 2002 Data Modeling – James Cohen Enhanced Entity Relationship (EER) Model Presented by James Cohen.
Chapter 4 The Enhanced Entity-Relationship (EER) Model
Chapter 2 Database System Concepts and Architecture
© Shamkant B. Navathe CC METU Department of Computer Eng Ceng 302 Introduction to DBMS Enhanced Entity-Relationship (EER) Model by Pinar Senkul resources:
EXTENDED-ER (EER) MODEL CONCEPTS. Enhanced-ER (EER) Model Concepts  Basic ER diagram + more concepts =EER model  Additional concepts:  Subclasses/superclasses.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4- 1 EER stands for Enhanced ER or Extended ER EER Model Concepts Includes all modeling concepts.
Enhanced Entity-Relationship and UML Modeling. Enhanced-ER (EER) Model Concepts Includes all modeling concepts of basic ER Additional concepts: subclasses/superclasses,
Enhanced Entity-Relationship Model (EER) 1. Enhanced-ER (EER) Model Concepts Includes all modeling concepts of basic ER Additional concepts: subclasses/superclasses,
Chapter 3 Data Modeling Using the Entity- Relationship (ER) Model Dr. Bernard Chen Ph.D. University of Central Arkansas.
Data Modeling Using the Entity-Relationship Model
Data Modeling Using the Entity-Relationship Model
Data Modeling Using the Entity-Relationship Model
Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model.
Entities and Attributes
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 The Enhanced Entry-Relationship (EER) Model.
Chapter 4: The Enhanced ER Model and Business Rules
1 CSE 480: Database Systems Lecture 4: Enhanced Entity-Relationship Modeling Reference: Read Chapter 8.1 – 8.5 of the textbook.
Chapter 3 Data Modeling Using the Entity- Relationship (ER) Model Dr. Bernard Chen Ph.D. University of Central Arkansas Fall 2008.
© Shamkant B. Navathe CC. © Shamkant B. Navathe CC Chapter 4 - Part I Enhanced Entity-Relationship and UML Modeling Copyright © 2004 Ramez Elmasri and.
Database Systems: Enhanced Entity-Relationship Modeling Dr. Taysir Hassan Abdel Hamid.
Initial Design of Entity Types for the COMPANY Database Schema Based on the requirements, we can identify four initial entity types in the COMPANY database:
EER Model.
Chapter 2 Database System Concepts and Architecture Dr. Bernard Chen Ph.D. University of Central Arkansas.
Enhanced Entity-Relationship (EER) Modeling. Slide 4- 2 Chapter Outline EER stands for Enhanced ER or Extended ER EER Model Concepts Includes all modeling.
Keys for Relationship Sets The combination of primary keys of the participating entity sets forms a super key of a relationship set. – (customer-id, account-number)
1 CSBP430 – Database Systems Chapter 4: Enhanced Entity– Relationship and Object Modeling Elarbi Badidi College of Information Technology United Arab Emirates.
Exam 1 Review Dr. Bernard Chen Ph.D. University of Central Arkansas Fall 2008.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4- 1.
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe Enhanced-ER (EER) Model Concepts.
DatabaseIM ISU1 Fundamentals of Database Systems Chapter 3 Data Modeling Using Entity-Relationship Model.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 4 Enhanced Entity-Relationship (EER) Modeling.
Slide 4-1 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005 Exercise 1. a property or description.
© Shamkant B. Navathe CC Enhanced Entity-Relationship Copyright © 2004 Ramez Elmasri and Shamkant Navathe.
Topic 4 - Part I Enhanced Entity-Relationship and UML Modeling
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe CHAPTER 4 Enhanced Entity-Relationship (EER) Modeling Slide 1- 1.
Lecture 3 A short revision of ER and EER modelling See R. Elmasri, S.B. Navathe. Fundamentals of Database Systems (third edition) Addison-wesley. Chapter.
Enhanced Entity-Relationship and UML Modeling. 2.
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Slide 4- 1.
Chapter 4_part2: The Enhanced Entity-Relationship (EER) Model.
ISC321 Database Systems I Chapter 2: Overview of Database Languages and Architectures Fall 2015 Dr. Abdullah Almutairi.
Database Systems 主講人 : 陳建源 日期 :99/10/19 研究室 : 法 Chapter 4 Enhanced Entity-Relationship and Object Modeling.
Databases (CS507) CHAPTER 7.
Enhanced Entity-Relationship (EER) Model
Enhanced Entity-Relationship and Object Modeling Objectives
© Shamkant B. Navathe CC.
ER model Ashima Wadhwa.
Conceptual Design & ERD Modelling
Enhanced Entity-Relationship (EER) Modeling
The Enhanced Entity- Relationship (EER) Model
Enhanced Entity-Relationship (EER) Modeling
Session 2 Welcome: The sixth learning sequence
Enhanced Entity-Relationship (EER) Modeling
Chapter 2 Database System Concepts and Architecture
© Shamkant B. Navathe CC.
© Shamkant B. Navathe CC.
CS4222 Principles of Database System
Sampath Jayarathna Cal Poly Pomona
Sampath Jayarathna Cal Poly Pomona
© Shamkant B. Navathe CC.
Enhanced Entity-Relationship (EER) Modeling
Enhanced Entity-Relationship (EER) Modeling
Presentation transcript:

Exam 1 Review Dr. Bernard Chen Ph.D. University of Central Arkansas

Database System Database: A collection of related data. Data: Known facts that can be recorded and have an implicit meaning. Database Management System (DBMS): A software package/ system to facilitate the creation and maintenance of a computerized database. Database System: DBMS + Database

Database V.S. File In the database approach, a single repository of data is maintained that is defined once then accessed by various users The major differences between DB and File are: 1. Self-describing of a DB 2. Insulation between programs and data 3. Support of multiple views of the data 4. Sharing of data and multiuser transaction processing

Self-describing nature of a database system Database system contains not only the database itself but also a complete definition of the database structure and constrains The information stored in the catalog is called Meta-data (data about data), and it describes the structure of the primary database.

Categories of data models High-level or Conceptual data models: Provide concept that are close to the way many users perceive data Low-level or Physical data model: Provide concepts that describe the details of how data is stored in the computer

Conceptual data models It uses concepts such as entities, attributes and relationships. Entity represents a real-world object or concept, such as employee or project Attribute represents some property of interest that further describes an entity, such as employee’s name or salary Relation among two or more entities represents an association among two or more entitles

Example of a Database Schema

Schemas and Database State The data in the database at a particular moment in time is called a database state The distinction between database schema and database state is very important When we define a new database, we specify its database schema only to the DBMS At this point, the corresponding database state is the empty state with no data We get the initial state of the database when the database is first loaded From then on, every time an update operation is applied to the database, we get another database state

Three-Schema Architecture Defines DBMS schemas at three levels: Internal schema at the internal level to describe physical storage structures and access paths (e.g indexes). Conceptual schema at the conceptual level to describe the structure and constraints for the whole database for a community of users. External schemas at the external level to describe the various user views.

The three-schema architecture

Centralized DBMS Architecture A centralized DBMS in which all the DBMS functionality, application program execution, and user interface processing were carried out on a single machine The client/server architecture was developed to deal with computer environment in which a large number of PCs, workstation, file server… This is called two-tire architectures because the software components are distributed over two systems: client and server The emergence of the Web changed the roles of client and server, leading to the three-tier architecture

A Physical Centralized Architecture

Logical two-tier client server architecture

Three-tier client-server architecture

Entities and Attributes The most basic object that the ER model represents is an entity An entity maybe an object with a physical existence (a person, a car, house…) or it maybe an object with conceptual existence (a company, a job, or a course) Each entity has Attributes --- the particular properties that describe it

Attributes Several types of attribute occur in the ER model Simple vs. Composite Single value vs. Multi-value Stored vs. Derived

Composite vs. Simple Attributes Composite attributes can be divided into smaller subparts. For example: Address attribute of the EMPLOYEE entity can be further subdivided into street_address, city, state, zip_code Simple attributes can not be further divisible For example, street_address can be subdivided into Number, street, and apt# The value of composite attribute is the concatenation of the values of its constituent simple attributes

Single value vs. Multi-value Most attributes have a single value for a particular entity; such attribute are called single-valued In some cases an attribute can have a set of value for the same entity --- for example, colors attribute for a car, or a college_degree for a person Such attributes are called multivalued A multivalued attribute may have lower and upper bonds to constrain the number of values allowed for each entity

Stored vs. Derived In some cases, two (or more) attribute calues are related --- for example, the Age and Birth_date of a person The Age attribute is called a derived attribute and is said to be derived from the Birth_date attribute, which is called a stored value

Key Attributes An important constrain on the entities of an entity type is the KEY on attributes An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE.

Relationship The initial design is typically not complete Refining the initial design by introducing relationships ER model has three main concepts: Entities (and their entity types and entity sets) Attributes (simple, composite, multivalued) Relationships (and their relationship types and relationship sets)

Recursive Relationship In some cases, the same entity type participates more than once in a relationship type in different roles Example Employee and supervised

ER DIAGRAM

Weak Entity Types Entity types do not have key attribute of their own are called weak entity types In contrast, regular entity types that do have key attribute are called strong entity types A weak entity type normally has a partial key, which is the set of attributes that can uniquely identify weak entities that are related to the same owner entity

Weak Entity Type Weak entity types can sometimes be represented as complex attributes Complex Attributes: combination of composite and multi-valued attributes In the example, we could specify a multi-valued attribute Dependents for EMPLOYEE, which is a composite attribute with component attributes Name, Birthday, Sex and Relationship

Subclasses, Superclasses and Inheritance We call each of these subgroupings a subclass of the EMPLOYEE entity type, and the EMPLOYEE entity type is called the superclass for each of these subclasses. These are called superclass/subclass (as well as simply class/subclass) relationships: EMPLOYEE/SECRETARY EMPLOYEE/TECHNICIAN EMPLOYEE/MANAGER … These are also called IS-A relationships SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….

Subclasses and Superclasses

Subclasses, Superclasses and Inheritance An important concept associated with subclasses is that of type inheritance An entity that is member of a subclass inherits All attributes of the entity as a member of the superclass All relationships of the entity as a member of the superclass

Constraints on Specialization and Generalization Two basic constraints can apply to a specialization/generalization: Disjointness Constraint: Specifies that the subclasses of the specialization must be disjoint: an entity can be a member of at most one of the subclasses of the specialization Completeness Constraint: If not disjoint, specialization is overlapping

Displaying an attribute-defined specialization in EER diagrams

Example of overlapping total Specialization

Constraints on Specialization and Generalization Completeness Constraint: Total specifies that every entity in the superclass must be a member of some subclass in the specialization/generalization Shown in EER diagrams by a double line Partial allows an entity not to belong to any of the subclasses Shown in EER diagrams by a single line In general, a superclass that was identified through the generalization process usually total, because the superclass is derived from the subclasses and hence contains only the entities that are in the subclass

Specialization/Generalization Hierarchies, Lattices A subclass may itself have further subclasses specified on it Hierarchy has a constraint that every subclass has only one superclass (called single inheritance); this is basically a tree structure In a lattice, a subclass can be subclass of more than one superclass (called multiple inheritance)

Union All of the superclass/subclass relationships we have seen so far origin from a single superclass Sometimes we may need more than one superclass In this case, the subclass will represent a collection of objects that is a subset of the UNION of distinct entity types We call such a subclass a UNION TYPE

UNION Attribute inheritance works more selectively in the case of UNION. For example, OWNER entity inherits attributes of a COMPANY, a PERSON OR a BANK A shared subclass such as ENGINEERING_MANAGER inherits ALL the attributes of its superclasses

Two categories (UNION types): OWNER, REGISTERED_VEHICLE