Part 7. Logical Data Structures

Similar documents
Detailed Data Modelling: Attribute Collection and Normalisation of Data

Database Management Systems. Chapter 2 Part 2

King Fahd University of Petroleum and Minerals

Detailed Data Modelling. Detailed Data Modelling. Detailed Data Modelling. Identifying Attributes. Attributes

Database Design Process

Contents. Database. Information Policy. C03. Entity Relationship Model WKU-IP-C03 Database / Entity Relationship Model

The Entity-Relationship (ER) Model 2

Database Applications (15-415)

CIS 330: Web-driven Web Applications. Lecture 2: Introduction to ER Modeling

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Representation in Relational Model.

Modeling Your Data. Chapter 2. cs542 1

Introduction to Database Design. Dr. Kanda Runapongsa Dept of Computer Engineering Khon Kaen University

MIS Database Systems Entity-Relationship Model.

COSC 304 Introduction to Database Systems. Entity-Relationship Modeling

Sankalchand Patel College of Engineering, Visnagar B.E. Semester III (CE/IT) Database Management System Question Bank / Assignment

The Entity-Relationship Model

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

Lecture3: Data Modeling Using the Entity-Relationship Model.

Lecture4: Guidelines for good relational design Mapping ERD to Relation. Ref. Chapter3

The Relational Model and Normalization

Database Systems. A Practical Approach to Design, Implementation, and Management. Database Systems. Thomas Connolly Carolyn Begg

The Entity-Relationship (ER) Model

Chapter. Relational Database Concepts COPYRIGHTED MATERIAL

V. Database Design CS448/ How to obtain a good relational database schema

IS 263 Database Concepts

Database Systems ( 資料庫系統 )

Entity Relationship Data Model. Slides by: Shree Jaswal

The Entity-Relationship Model

Objectives. After completing this lesson, you should be able to do the following:

Database Applications (15-415)

Normalization. Normal Forms. Normal Forms

Entity-Relationship Diagrams

IS 263 Database Concepts

LECTURE 3: ENTITY-RELATIONSHIP MODELING

GIFT Department of Computing Science Data Selection and Filtering using the SELECT Statement

Chapter 8 INTEGRITY 1

The Relational Model 2. Week 3

Database Design. Goal: specification of database schema Methodology:

DATABASE DEVELOPMENT (H4)

Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition. Chapter 7 Data Modeling with Entity Relationship Diagrams

Chapter 4 Conceptual Modeling

CS2 Current Technologies Lecture 3: SQL - Joins and Subqueries

CS/INFO 330 Entity-Relationship Modeling. Announcements. Goals of This Lecture. Mirek Riedewald

ajpatelit.wordpress.com

Introduction to Database Design

ER modeling. Lecture 4

The Entity-Relationship Model. Steps in Database Design

Database Systems. Lecture2:E-R model. Juan Huo( 霍娟 )

2004 John Mylopoulos. The Entity-Relationship Model John Mylopoulos. The Entity-Relationship Model John Mylopoulos

CS2 Current Technologies Lecture 2: SQL Programming Basics

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model.

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2)

Conceptual Database Design. COSC 304 Introduction to Database Systems. Entity-Relationship Modeling. Entity-Relationship Modeling

Lecture 5 STRUCTURED ANALYSIS. PB007 So(ware Engineering I Faculty of Informa:cs, Masaryk University Fall Bühnová, Sochor, Ráček

CS403- Database Management Systems Solved Objective Midterm Papers For Preparation of Midterm Exam

Database Management Systems

DATABASE TECHNOLOGY - 1DL124

CS2 Current Technologies Note 1 CS2Bh

The Entity-Relationship Model. Overview of Database Design

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

Chapter 2 ENTITY RELATIONSHIP MODEL

CIS 330: Applied Database Systems

Relational Database design. Slides By: Shree Jaswal

BIRKBECK (University of London)

CS 348 Introduction to Database Management Assignment 2

The Relational Model. Outline. Why Study the Relational Model? Faloutsos SCS object-relational model

Introduction to Database Design

COSC 304 Introduction to Database Systems Enhanced Entity-Relationship (EER) Modeling

Bachelor in Information Technology (BIT) O Term-End Examination

Data Modeling. Yanlei Diao UMass Amherst. Slides Courtesy of R. Ramakrishnan and J. Gehrke

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

Object Modeling. Entity-Relationship (ER) diagrams (1976) Object Modelling Technique (OMT) diagrams (1991)

CS403- Database Management Systems Solved MCQS From Midterm Papers. CS403- Database Management Systems MIDTERM EXAMINATION - Spring 2010

Databases 1. Daniel POP

Conceptual Design. The Entity-Relationship (ER) Model

Database Design Process. Requirements Collection & Analysis

Sample Question Paper

Introduction to Data Management. Lecture #3 (Conceptual DB Design) Instructor: Chen Li

DATA Data and information are used in our daily life. Each type of data has its own importance that contribute toward useful information.

Database Management Systems

ER Model. CSC 343 Winter 2018 MICHAEL LIUT

CS 4604: Introduction to Database Management Systems. B. Aditya Prakash Lecture #5: Entity/Relational Models---Part 1

Overview of db design Requirement analysis Data to be stored Applications to be built Operations (most frequent) subject to performance requirement

DATABASE DESIGN I - 1DL300

The Relational Model. Chapter 3

Home Page. Title Page. Page 1 of 14. Go Back. Full Screen. Close. Quit

OVERVIEW OF DATABASE DEVELOPMENT

The Relational Model

Data Modeling During System Analysis. Logical Data Model Stages. What is Conceptual Database Design? Gathering Information for Conceptual

From ER to Relational Model. Book Chapter 3 (part 2 )

The Relational Model. Chapter 3. Database Management Systems, R. Ramakrishnan and J. Gehrke 1

The Relational Model. Chapter 3. Comp 521 Files and Databases Fall

Copyright 2016 Ramez Elmasri and Shamkant B. Navathe

Chapter 2 Introduction to Relational Models

Table : Purchase. Field DataType Size Constraints CustID CHAR 5 Primary key CustName Varchar 30 ItemName Varchar 30 PurchaseDate Date

Introduction to Data Management. Lecture #3 (E-R Design, Cont d.)

1Z0-007 ineroduction to oracle9l:sql

The DBMS accepts requests for data from the application program and instructs the operating system to transfer the appropriate data.

XV. The Entity-Relationship Model

Babu Madhav Institute of Information Technology 2015

Transcription:

Part 7 Logical Data Structures

Logical Database Design Constructive approach Considers semantics Documents data dependencies identifiers entities needed relations rules Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 2

Logical Data Structures (LDS) Graphical means of naming and depicting the types of data in a database Simple, yet precise Useful to technically oriented analysts application-oriented users Easy to read Supports the design task logical structure design is hard tool aids the design task notation does not get in the way Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 3

Entity Basic LDS Components any type of thing about which information is maintained entity_name EXAMPLE student Attribute a characteristic of exactly one entity (fully functionally dependent on the entity) attribute_name EXAMPLE: Student attributes student student_name student_id# soc_sec# Relationships an association between a pair of entities (or roles ), one-to-one, one-to-many only or but never Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 4

Example Relationships 1-1 Example: Monogamous marriage man woman Can label relationship man wife of man/ husband of woman woman 1-M Example: Students of a college college student Need not label a relationship if it can be stated as: college of student / students of college or student has college / college has students Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 5

Handling an M-M Relationship M-M Example: Brother - Sister man_name man sisters of man/ brothers of woman woman woman_name Problem: how do you represent the presence of sibling rivalry? THIS WON'T WORK man_name woman_name man woman rivalry SOLUTION man_name woman_name man woman brother-sister rivalry Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 6

Identifier Representation Identifier: a set of attributes or relationships that uniquely identify an instance of an entity (single field key) (multiple-field key) Example: college_name student_name student_id# college student college# soc_sec# Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 7

Primary Key / Candidate Key state_name city_name state city state_abbrev city# primary key candidate key Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 8

Sample Database Employee: (emp) attributes: Ename, Job, Mgr, Hired, Rate, Bonus Department: (dept) attributes: DeptNo, Dname, Loc, Dbudget Task: (task) attributes: Tname, Hours Project: (proj) attributes: Project_id, Description, Pbudget, Due_date Relationships employees are members of a department employees have a manager who is an employee employees are assigned to tasks on projects Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 9

LDS for Sample Database DeptNo Dname Loc dept Ename Job Hired Rate Dbudget emp Mgr Bonus Tname task Project_id Description Hours proj Pbudget Due_date Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 10

Functional Dependency Revisited DeptNo Dname Loc Dbudget Ename Job Rate dept emp DeptNo identifies dept instances DeptNo --> Dbudget dependent on DeptNo DeptNo --> Loc on DeptNo Dname is an alternate key Dname --> Dbudget dependent on Dname Ename identifies emp instances Ename --> Job on Ename Ename --> Rate dependent on Ename Dbudget is fully functionally Loc is fully functionally dependent Dbudget is fully functionally Job is fully functionally dependent Rate is fully functionally an employee instance determines exactly one department Ename --> DeptNo DeptNo is fully functionally dependent on Ename Ename --> Loc Loc is fully functionally dependent on Ename, but this is a transitive full functional dependence Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 11

LDS for Example 1 - Suppliers A supplier supplies many parts, and a part can be supplied by many suppliers supplier part supp part_type availability Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 12

LDS for Example 2 - Inventory A product can be stored in many warehouses and a warehouse can contain many products part# warehouse# wh_address product warehouse inventory quantity Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 13

LDS for Example 3 - Departments A department can have many employees, and employee can only be in one department dept dept_loc name department employee Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 14

LDS for Example 4 - Locations Departments have one number, one name, and one location dept# dept_name dept_loc department Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 15

LDS for Example 5 - Stock An inventory is comprised of combinations of various parts from various suppliers - a supplier can supply many parts, and a part can be supplied by many suppliers p# s# sname part supplier inventory qty Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 16

LDS for Example 6 - Enrollment A student can take many subjects; a subject can be taken by many students. A subject can be taught by many teachers, a teacher can teach only one subject. A student can be taught by many teachers, a teacher can teach many students. student subject stu subj registration teach teacher Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 17

LDS for EXAMPLE 7 - SKILLS Employees can have many skills, and a skill can be had by many employees; an employee can know many languages and a language can be known by many employees. employee skill emp job_skill emp/lang/job_skill This diagram is correct if all 3 are interdependent language lang employee emp job_skill skill language This diagram is almost never correct lang (It implies that a skill can be held by only one employee) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 18

CORRECT LDS for INDEPENDENCE Assuming job skills and language skills are independent, they represent two separate many-to-many relationships employee emp/job_skill skill emp job_skill emp-lang language lang Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 19

LDS for EXAMPLE 8 - DEALERSHIPS In the general case, a contract involves one dealer, one manufacturer, and one product. A dealer can have many contracts, a manufacturer can have many contracts, and a product can be mentioned in many contracts. agent company dealership manufacturer contract This diagram is correct in the general case product vehicle Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 20

DEALERSHIPS with CONSTRAINTS Dealers can deal with many manufacturers, and manufacturers with many dealers. Dealers can sell many vehicle types and vehicle types can be sold by many dealers. Manufacturers can make many vehicles and vehicles can be made by many manufacturers. The combinations of who sells what is determined by symmetry. agent dealer-mfgr company dealer manufacturer dealer-vehicle mfgr-vehicle vehicle product Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 21

LDS for EXAMPLE 9 - CUSTOMERS A branch has many customers; a customer is in only one branch. There are only a limited number of legal branch names. branch cust# legal_branch customer Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 22

Entities: it must have identifier attributes relationships Modeling Concepts it must be the focus of the system need to develop for it : name description membership criteria must examine roles within subsets of it Attributes: must be non-transitively fully functionally dependent on the entity it describes must develop for each attribute: name description domain definition Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 23

Concept of Roles when 2 entities share a set of attributes OR when 2 entities have more than one relationship between them OR when subsets of an entity-instance have different attributes OR when subsets of an entity-instance participate in different relationships THEN MULTIPLE ROLES EXIST Examples of roles in the sample database: In emp, an employee plays 2 roles: works in a department (some) manages department In emp regular employees report to managers in the same department managers report to managers in a different department In emp, certain employees eligible for bonus (even if 0) ROLES ARE DOCUMENTED WHEN THEY ARE SIGNIFICANT Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 24

Alternate LDS for Sample Database DeptNo Dname Loc dept Ename Job Hired Rate Dbudget emp isa Mgr Tname Bonus task Project_id Description Hours proj Pbudget Due_date This has changed the rule about the group of employees for whom the bonus is applicable. Previously, analysts were technically eligible, even if none of them actually received a bonus. Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 25

Identifiers: Modeling Concepts (Continued) determine which attributes are part of it verify uniqueness establish not null requirements Relationships: establish degree 1-1 or 1-M entity on 1 side must be functionally dependent on entity on M side develop: - name - definition incorporate constraints, rules note referential integrity - (values of foreign key must exist in key field of another relation) - (e.g. in the emp relation, if an employee is listed as being in department 402, then in the dept relation there must contain a row with a key value of 402) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 26

Entity Analysis Oneness Sameness Categorization Identification Other Modeling Methods Object Abstraction (Smith & Smith) Objective: Intellectual Manageability Create hierarchies of abstraction along 2 dimensions: - aggregation (has / part of) - generalization (is / subtype) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 27

Object Extraction Examples Aggregation (has / part of) department task Tname Hours employee project Ename Job Project_id Pbudget Generalization (is / subtype) employee Ename Rate programmer clerk analyst supervisor language_skills type_speed bonus other_employee Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 28

LDS Map LDS to Well-Formed Relations Relational Model entity relation name attribute descriptor attribute single-valued relationship attribute (foreign key) descriptor multi-valued relationship nothing descriptor 1-1 relationship either or both relationship descriptors are attributes 1-M relationship relationship descriptor with degree 1 (on the M side) is an attribute Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 29

LDS fi Relations Examples Example: College students college_name student_name student_id# college student college# soc_sec# college (college#, college_name) student (student#, college#, student_name, soc_sec#) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 30

Sample Database Relations (See page 10 for the Sample Database LDS) dept (DeptNo, Dname, Loc, Dbudget) emp in emp (Ename, Job, Mgr, Hired, Rate, Bonus, DeptNo) proj (Project_id, Description, Pbudget, Due_date) task (Tname, Ename, Project_id, Hours Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 31

Relations for Example 1 - Suppliers supplier part supp part_type availability supp (supplier) part_type (part) availability (supplier, part) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 32

Relations for Example 2 - Inventory part# warehouse# wh_address product warehouse inventory quantity product (part#) warehouse (warehouse#, wh_address) inventory (part#, warehouse#, quantity) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 33

Relations for Example 3 - Departments dept dept_loc name department employee department (dept, dept_loc) employee (name, dept) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 34

Relations for Example 4 - Locations dept# dept_name dept_loc department department (dept#, dept_name, dept_loc) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 35

p# Relations for Example 5 - Stock s# sname part supplier inventory qty part (p#) supplier (s#, sname) inventory (p#, s#, qty) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 36

Relations for Example 6 - Enrollment student subject stu subj registration teach teacher stu (student) subj (subject) teach (teacher, subject) registration (student, teacher) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 37

Relations for Example 7 - Skills employee emp/job_skill skill emp job_skill emp-lang language lang emp (employee) job_skill (skill) lang (language) emp/job_skill (employee, skill) emp-lang (employee, language) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 38

Relations for Example 8 - Dealerships (See page 21 for Dealership LDS with symmetry restrictions) dealer (agent) manufacturer (company) vehicle (product) dealer-mfgr (agent, company) dealer-vehicle (agent, product) mfgr-vehicle (company, product) Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 39

Copyright 1971-2002 Thomas P. Sturm Logical Data Structures Part 7, Page 40