Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Introduction to Conceptual Database Design These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db 1 Overview of Lecture Entity Classes Relationships & ER Diagrams 1:M Relationship Design Multiple Relationships & The Fan Traps Conceptual Design Other ER Models Mandatory Participation Reflexive 1:M Relationships Class Identification & Surrogate Keys Redundancy & Anomalies Simple Functional Dependencies Simple Conceptual Normalization © Ellis Cohen 2001-2008 2 Entity Classes © Ellis Cohen 2001-2008 3 Conceptual Modeling Conceptual Modeling is a way of designing systems involving collections of tables by focusing on • Entities – an abstraction of tuples • Entity Classes – an abstraction of tables • Relationships – between entities in different entity classes Using diagrams called ER diagrams (or Entity-Relationship Diagrams) © Ellis Cohen 2001-2008 4 Tables as Themes Employees empno ename sal comm 7499 ALLEN 1600 300 7654 MARTIN 1250 1400 7698 BLAKE 2850 7839 KING 5000 7844 TURNER 1500 7986 STERN 1500 0 A row represents a single Employee Every table has a theme -- e.g. Employees Every row represents an instance of that theme -- e.g. a single Employee © Ellis Cohen 2001-2008 5 Columns as Attributes Employees Primary Key is underlined Uniquely identifies an employee empno ename sal comm 7499 ALLEN 1600 300 7654 MARTIN 1250 1400 7698 BLAKE 2850 7839 KING 5000 7844 TURNER 1500 7986 STERN 1500 0 Every column represents an attribute related to the theme -- e.g. the name or salary of an Employee © Ellis Cohen 2001-2008 6 Rows as Objects/Entities Employees empno ename sal comm 7499 ALLEN 1600 300 7654 MARTIN 1250 1400 7698 BLAKE 2850 7839 KING 5000 7844 TURNER 1500 7986 STERN 1500 an Employee Object empno: 7654 ename: MARTIN sal: 1250 comm: 1400 0 It can be useful to think of each row as an object or entity and the table as a collection of these entities. The columns of the table correspond to the instance variables for each object © Ellis Cohen 2001-2008 7 Entity Classes In conceptual modeling, we focus on the entity class which represents the class of entities with the same theme. In general (but as we will see, not always), an entity class is implemented by a table in a relational database © Ellis Cohen 2001-2008 8 Modeling Entity Classes Visual Conceptual Model (Crow Magnum) Sometimes we don't Sometimes we include all the attributes Employee Employee empno ename sal comm Sometimes we just include the primary key Employee empno Textual Conceptual Model (Brief ConText) Employee( empno, ename, sal, comm ) © Ellis Cohen 2001-2008 9 Attributes Types Keep attribute types simple Complex attribute types often mean you need to rethink your design or be more specific Employee empno ename sal comm a number a string a dollar amount a dollar amount © Ellis Cohen 2001-2008 10 Relationships and ER Diagrams © Ellis Cohen 2001-2008 11 ER (Entity-Relationship) Diagrams (Crow Magnum style) Depicts a relationship between Employees and Depts Employee empno ename sal comm relationship characterization works for Dept deptno dname Crows Foot The Crow's foot at Employee means … • A Dept can have MANY Employees No Crow's foot at Dept, so … • An Employee works for no more than ONE Dept © Ellis Cohen 2001-2008 12 ER & Instance Diagrams works for Employee ER Diagram Relationship Entity Class Dept Entity Class Corresponds to links between instances of the related classes Instance Diagram Shows example instances and the links between them 7499 ALLEN 1600 300 7654 MARTIN 1250 1400 7844 TURNER 1500 0 7698 BLAKE 2850 7986 STERN 1500 Entity Instances Links © Ellis Cohen 2001-2008 10 SALES 30 ACCOUNTING Entity Instances 13 Instance Diagrams & Navigation Links 7499 ALLEN 1600 300 7654 MARTIN 1250 1400 7844 TURNER 1500 0 7698 BLAKE 2850 7986 STERN 1500 10 SALES 30 ACCOUNTING Links are the basis of navigation between instances. We will see later that there are SQL queries which effectively find the tuples in one entity class which are related to the tuples in another entity class. So we can write SQL to find information about • The dept associated with an employee • All the employees who work for a department © Ellis Cohen 2001-2008 14 Entities & Links as Persistent Data Every – entity instance of an entity class – link instance of a relationship Represents – data persistently stored in a database – information needed to answer a query (e.g. what’s the salary of ALLEN?, what department does ALLEN work in?) The ONLY reason to represent an entity class or a relationship in a conceptual model is because the requirements clearly indicate they are necessary to provide information needed for some query © Ellis Cohen 2001-2008 15 1:M (1 to Many) Relationships Child Entity Class Employee Parent Entity Class works for Dept deptno empno an Employee works for (at most) 1 Dept a Dept has any number (i.e. M) of Employees © Ellis Cohen 2001-2008 16 Easy Crow Magnum Relationships Visual Conceptual Model (Easy Crow Magnum) Employee Employee empno works for works for Dept Dept deptno no attributes shown in this example just primary keys shown in this example Easy Crow Magnum is meant for quickly drawing designs on paper or a whiteboard In Easy Crow Magnum, don't draw the box outlines on entity classes © Ellis Cohen 2001-2008 17 Visual & Textual Models for Relationships VISUAL Conceptual Model (Crow Magnum) Employee works for Dept relationship characterization TEXTUAL Conceptual Model (Brief ConText) (*) Employee works for Dept relationship characterization © Ellis Cohen 2001-2008 18 Inverse Relationships VISUAL Conceptual Model (Crow Magnum) Dept contains Employee relationship characterization TEXTUAL Conceptual Model (Brief ConText) Dept contains (*) Employee relationship characterization © Ellis Cohen 2001-2008 19 Indicating Relationship Direction Employee Employee Employee works for works for contains Dept Dept Dept Dept Dept Dept contains contains works for Employee Employee Employee Must indicate the relationship direction if it is not the natural reading direction (L-to-R, top-to-bottom) © Ellis Cohen 2001-2008 20
