CSE 880:Database Systems. ER Model and Relation Schemas

Size: px

Start display at page:

Download "CSE 880:Database Systems. ER Model and Relation Schemas"

Brenda Arnold
6 years ago
Views:

1 CSE 880:Database Systems ER Model and Relation Schemas 1

2 Major Steps for Database Design and Implementation 1. Requirements Collection and Analysis: Produces database requirements such as types of data, types of updates, data flow and states, types of transactions, etc. Process may include survey questionnaire, interviews with new and existing users and key personnel, study exiting operations and operating documents. 2. Conceptual Database Design: Produces a conceptual schema for the database. Meet with a few people who are knowledgeable and experts in the application domain to detail out the design. This includes defining entity types relationship types, constraints, etc. (ER model). This does not include implementation details related to a particular database system. 3. Logical Database Design: Produces logical schema for a specific database system by mapping conceptual schema into a data model available for implementation. For example, relational 2

3 tables may be defined from ER diagram in this step. This may be done in two steps. First use general mapping rules to create tables from the ER diagram and then map these tables into the available database system. 4. Physical Database Design: Storage structure design, creating indices, clustering, partitioning and placement of database files, etc. One of the criteria used in physical database design is to optimize performance. 5. System Implementation and Performance Tuning: After the logical and the physical designs are completed, database system is implemented. Schemas are defined in the database system using DDL. Compiling and loading databases are done. Check for database integrity. Perform further performance tuning. (Performance tuning is an ongoing process normally handled by a database administrator) 3

4 An Example Requirements Specification (Conceptual Database Design) Consider the following set of requirements for an Employees database that is used to keep track of employees information for a company. 1. The database should keep track of an employee s id, social security number, address and phone number, birth date, sex, supervisor, department, Salary and projects. 2. The department has the following information: department id, department name, department locations, phone, employees, number of employees, manager, projects. 3. Projects has the following information: Project title, project number, project manager, employees working on the project, department controlling the project. 4. Employee dependents has the following information: Dependent name, BDate, relationship to employee. 5. What is the next step? 4

5 Entity Relationship (ER) Model (Conceptual Database Design) 1. ER model describes data as entities, relationships, and attributes. 2. entities: object with independent existence. entity: <Student ID:s1, Student name: John, Student address: 10 elm street> not an entity: <student ID:s1, student name: John, Student address: 10 elm street, Depatment name: CSE, Department Tel. NO.: > Department information can exists by itself without being with student information. 3. relationship: Student belonging to a department is a relationship between a student entity and a department entity. 4. Attributes: particular property that describes an entity: Student ID is an attribute of the entity for student. Student name is another attribute. 5. An ER diagram for the above: ID Name address ID Name Tel. No \ / \ / student -- students department--- department

6 Why ER Model? 1. Data requirements specification is first captured by using an ER model, and then ER model is mapped into relational data model. 2. Why use ER model first? Real world information is more naturally mapped into ER model than into relational data model. In relational data model many data relationships are captured through data values at query time using programs while in ER diagram these relationships are explicit in Data definition. ER model is pictorial and more comprehensive. ER model can be more easily reviewed and modified at design time than relational data model. 6

7 Examples Comparing Relational Model and ER model Semantic that the name is a composite attribute such as first, middle and last names cannot be captured by relational model but can be captured in ER model. In relational data model Employees and Departments are related through the foreign keys (referential integrity constraint) while in ER diagram this relationship is more explicit. For a company database, data such as Employees and Departments objects exist by themselves while the fact that an employee belongs to a department depends on the existence of the employee and the corresponding department object. In other words, Employees and Departments objects exist independently while an employee belongs to a department is a relation between them. Similarly, in a STUDENT database Students and Courses objects can exist by themselves while the fact that a student taking a particular course can be created only after the Students and Courses objects are created. This difference in semantics between entity and relationship of 7

8 real word information is more naturally captured by ER model than in relational model by considering Employees and Departments as entity types and the information an employee works for a department as the relationship between Employees and Departments. Similarly, in STUDENT database Students and Courses are created as entity types and the information a student taking a course is a relationship between Students and Courses. An example of an ER diagram: Figure 3.2. (Elmasri/third Edition) 8

9 Definitions 1. Entities and Entity types: Entity: An object that has independent existence. Example: in a Company database Employee object < ssno : , Name : JohnDoe, Dept : CSE > is an entity In a Company database < Name : JohnDoe, Department : CSE > may not be an entity because it is relationship. Entity Type: Defines a set of entities that have the same attributes and it must have a key. Example: Employees (ssno, Name, Dept); ssno is the key. Entity set: A set of entities of a particular entity type. Normally, entity type name is used to represent the entity set. Example: entity set Employees: {(s1,n1,d1),(s2,n2,d2)} 9

10 Weak Entity Type and identifying relationship type: Entity type that does not have key attributes of its own. Example: Entity EmployeeDependent depends on the entity type Employee. Normally weak entities have partial keys and become unique when combined with the key of its parent entity. Thus the relationship between the weak entity and it s parent entity is called the identifying relationship type. 2. Relationships and Relationship types: Relationship type is the association between entity types. For example, relationship type Works- For associates one entity type Employees with another entity type Departments Relationship Degree: Number of participating entity types: Relationship type WorksFor is of degree two (binary relationship). Relationship type Supply between Suppliers, Parts and Projects is of degree 3 (ternary relationship). Attributes of Relationship type: 10

11 Relationship types can have attributes just like in entity types. WorksFor can have attributes Hours and RateOfPay. Entity types, Relationship types and Attribute types: Whether data is entity or relationship or attribute depends on the application. For example, Works- For can be an attribute in the Employee entity type. WorksFor may contain department number, the employee works for. 3. Simple and Complex Attributes: Attributes (simple): Particular properties that entities describe. Example: ssno, Name, Dept Composite Attributes: Consists of a set of simple (atomic) attributes. It can be a hierarchy of simple attributes. Example: The composite attribute Name is composed of the three simple attributes FirstName, MiddleName and LastName Multivalued attributes: An attribute with multiple values for an entity. Important information for mapping into relational data model 11

12 because attribute values in relational model are atomic. Example: Department Locations (if a department has several locations) Stored attributes: Attributes whose values are stored in the table. Example: BirthDate Derived attributes: Attributes whose values are computed from values of other attributes at query time. This approach avoids storing replicated information. Example: Age (can be computed from birth date). NULL values: Value is not known yet. Example: Local address of a new employee may not be known yet. Complex attributes: Nesting of composite and multivalued attributes. AddressPhone: ({P hone(areacode, P honen umber)}, Address(StreetAddress(number, Street), City, State, Zip)) 4. Notations: Figure 3.15 (third edition) 12

13 Constraints on Relationship types Constraints are useful for efficiently mapping ER diagram into relational tables. 1. Cardinality constraints indicate whether an entity of one type can relate to one or more than one entities in another type. A database may not allow a professor to be a chair of more than one departments. Further, a department is not allowed to have more than one professor as chair. Note these two constraints are different. If the second constraint was not there, a department could have two professors as chairs while not violating the first constraint. 2. Cardinality Constraints for Binary Relationships: Three types: 1:1, 1:N, N:M. 1:1 relationship: Employees Manages Departments. An employee manages at the most one department and a department is manged by at most one employee as manager. Figure 3.12 (third edition) 13

14 1:N (1 to many) relationship: Employees WorkFor Departments. An employee can work for at the most one department but a department can have more than one employees working for it. 1 is on the Departments side and N is on the Employees side of the relationship Workfor in the ER diagram. Figure 3.9 (third edition) N:M (many to many) relationship: Employees workon Projects An employee can work on (workon) more than one projects and a project can be worked on (workon) by more than one employee. Figure 3.13 (third edition) How about ternary relationship? Figure 3.10 (third edition) 3. Participation Constraints (with respect to a relationship): Whether some or all of the entities are participating in a relationship. Thus an entity exits with respect to a relationship if the entity is related to another entity via the relationship. The participation is a total participation when every entity in the entity 14

15 set satisfies this constraint else it is a partial participation. For example, for total participation, every Employee in the Employee entity set must belong to some department for the WorksFor relationship. Figure 3.2 (Elmasri/third edition) 4. Refer to Figure 3.14, 3.15 of the text booki (third edition). 15

16 Mapping ER Model to Relational Schemas (Details in section 9.1) A S /\ T ---- / \ ---- X -- R -- Y ---- \ / ---- \/ primary key of S: X primary key of T: Y T is total participation in R. 1. R is of 1:1 relationship type: S(X), T(Y,X,A) foreign key X in T. 2. R is of 1:N relationship type (N is on the side of T): S(X), T(Y,X,A) foreign key X in T 3. R is of N:M relationship type: S(X), T(Y), R(X,Y,A) foreign keys: Primary key of R: (X,Y) Two foreign keys in R: X and Y. 16

1/24/2012. Chapter 7 Outline. Chapter 7 Outline (cont d.) CS 440: Database Management Systems

1/24/2012. Chapter 7 Outline. Chapter 7 Outline (cont d.) CS 440: Database Management Systems CS 440: Database Management Systems Chapter 7 Outline Using High-Level Conceptual Data Models for Database Design A Sample Database Application Entity Types, Entity Sets, Attributes, and Keys Relationship