Objectives for Week (1/29 & 1/31)  Know how to read, understand, and create a database model using a modeling tool - ERD’s.  Know the process of completing.

Slides:



Advertisements
Similar presentations
Chapter # 4 BIS Database Systems
Advertisements

More Diagramming & Practice with Relationship Modeling
Build a database I: Design tables for a new Access database
Database Design The process of finding user requirement
Entity-Relationship Modeling (ER-M)
ENTITY RELATIONSHIP MODELLING
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Copyright © 2015 Pearson Education, Inc. Database Design Chapters 17 and
Agenda for Week 1/31 & 2/2 Learn about database design
Data Modeling Entity - Relationship Models. Models Used to represent unstructured problems A model is a representation of reality Logical models  show.
Information Resources Management January 30, 2001.
Database Design Chapter 2. Goal of all Information Systems  To add value –Reduce costs –Increase sales or revenue –Provide a competitive advantage.
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 4 Entity Relationship (ER) Modeling
Database Systems: Design, Implementation, and Management Tenth Edition
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Entity/Relationship Modelling
APPENDIX C DESIGNING DATABASES
BIS310: Week 7 BIS310: Structured Analysis and Design Data Modeling and Database Design.
MIS2502: Data Analytics Relational Data Modeling
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
© 2007 by Prentice Hall (Hoffer, Prescott & McFadden) 1 Entity Relationship Diagrams (ERDs)
Chapter 3: Modeling Data in the Organization
Chapter 7 Data Modeling with Entity Relationship Diagrams Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
Practice of ER modeling
Module Title? Data Base Design 30/6/2007 Entity Relationship Diagrams (ERDs)
Chapter 5 Entity Relationship (ER) Modelling
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 6 Structuring.
Relational databases and third normal form As always click on speaker notes under view when executing to get more information!
Conceptual Data Modeling. What Is a Conceptual Data Model? A detailed model that shows the overall structure of organizational data A detailed model.
Database Design Principles – Lecture 3
McGraw-Hill/Irwin © 2008 The McGraw-Hill Companies, All Rights Reserved Plug-In T5: Designing Database Applications Business Driven Technology.
© 2011 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 2: Modeling Data in the Organization.
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
© Pearson Education Limited, Chapter 7 Entity-Relationship modeling Transparencies.
IS 475/675 - Introduction to Database Design
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Chapter 4 Entity Relationship (ER) Modeling.  ER model forms the basis of an ER diagram  ERD represents conceptual database as viewed by end user 
System Design System Design - Mr. Ahmad Al-Ghoul System Analysis and Design.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.
3 & 4 1 Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel Keys Consists of one or more attributes that determine other.
Data modeling using the entity-relationship model Chapter 3 Objectives How entities, tuples, attributes and relationships among entities are represented.
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 4 Entity Relationship (ER) Modeling.
AL-MAAREFA COLLEGE FOR SCIENCE AND TECHNOLOGY INFO 232: DATABASE SYSTEMS CHAPTER 4 ENTITY RELATIONSHIP (ER) MODELING Instructor Ms. Arwa Binsaleh 1.
Database Design – Lecture 4 Conceptual Data Modeling.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management
Database Design – Lecture 6 Moving to a Logical Model.
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
MIS2502: Data Analytics Relational Data Modeling
Chapter 3: Modeling Data in the Organization. Business Rules Statements that define or constrain some aspect of the business Assert business structure.
Entity Relationship Diagram (ERD). Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship.
EntityRelationshipDiagrams. Entity Relationship Models The E-R (entity-relationship) data model views the real world as a set of basic objects (entities)
Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 2: MODELING DATA.
Database Design Chapters 17 and 18.
Let try to identify the conectivity of these entity relationship
TMC2034 Database Concept and Design
MIS2502: Data Analytics Relational Data Modeling
© The McGraw-Hill Companies, All Rights Reserved APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Tables and Their Characteristics
ERD’s REVIEW DBS201.
MIS2502: Data Analytics Relational Data Modeling
Database Systems Instructor Name: Lecture-11.
Chapter 2 Modeling Data in the Organization
Review of Week 1 Database DBMS File systems vs. database systems
MIS2502: Data Analytics Relational Data Modeling
Chapter 4 Entity Relationship (ER) Modeling
MIS2502: Data Analytics Relational Data Modeling 2
Database Management system
Presentation transcript:

Objectives for Week (1/29 & 1/31)  Know how to read, understand, and create a database model using a modeling tool - ERD’s.  Know the process of completing a database design.  Understand the structure and limitations of the relational model.  Know how to identify and differentiate the required components of a database design. 1

2 Visualization Method: Data Model (Blueprint) This ERD is referred to as a “logical” ERD

3 Vocabulary about entities  Entity: Person, place or thing about which we want to store data. Should be a noun.  Entity instance: One row in an entity. In a customer entity, one customer such as “Joe’s Diner” is an entity instance.  Strong entity: An entity that contains data we want to store regardless of its relationship to other data. Examples?  Weak entity: An entity that doesn’t exist unless it is related to other entities. Examples?

4 Vocabulary about keys One of the rules about a relational database is that each entity must have a primary key.  Primary key: One or more attributes that has/have a unique value in each entity instance.  Concatenated primary key: More than one attribute required for the primary key.  Natural primary key: Can be created from existing attributes.  Surrogate primary key: Is created by the database designer.

5 Vocabulary about relationships  Relationship: A business rule connection between entities. A relationship is a verb.  Bi-Directional: All data relationships can be read both ways.  Cardinality: describes the minimum and maximum number of instances that one entity has with another entity in a relationship.  Foreign Key: Each relationship requires a foreign key. The primary key of one table is added to another table to link the two tables together. A concatenated primary key yields a concatenated foreign key.

6

7 1a. What is the purpose of the DoesBusinessIn entity? What data might be stored in that entity? 1b. What would be an appropriate primary key for the DoesBusinessIn entity? 1c. Is the DoesBusinessIn entity strong or weak? Why? 1d. Identify a composite attribute on the data model. What are the meaningful parts of that attribute?

8

9 1e. Where is a unary relationship on the data model? Explain the meaning of the relationship. Describe how the cardinalities of the relationship might differ for different organizations.

10 1f. Explain in words the relationship between the entities Vendor, Supplies, and RawMaterial. In what way might Pine Valley change the way it does business that would cause the Supplies entity to be eliminated?

11 ERD 2a A corporation owns a series of shopping malls. Each shopping mall has similar stores (examples are: Footlocker, Walking Company, Jones New York, Abercrombie and Fitch) but each store is physically different at each mall. Each shopping mall is identified by a MallID. For each shopping mall, we want to keep track of the name of the mall, the address, zip code, and main telephone number. Each store is identified by a StoreID. For each store, we want to keep track of the name of the store and a long description of the type of the store. The corporation needs to associate a given store with a given shopping mall. For a given store at a given shopping mall, the corporation wants to keep track of the date the store opened at the mall, the name of the manager for the store, and the telephone number for that specific store in that specific mall.

12 Mall ID Mall Name Mall Address Mall Zip Code Mall Phone # Store ID Store Name Store Description Date Open ed Manager Name Store Phon e 123Gilroy Outlets 123 Garlic Street, Gilroy, CA Jones New York Women's professional attire, mid- range 9/12/ 1995 Joanne Brown Gilroy Outlets 123 Garlic Street, Gilroy, CA FootLockerAthletic Shoes, Men, Women, Family 8/16/ 1998 Bill Targenson Gilroy Outlets 123 Garlic Street, Gilroy, CA New York and Company Women's casual attire, bargain 3/15/ 2005 Ahmad Cedersill Sacram ento Outlets 8922 Oak Street, Roseville, CA Jones New York Women's professional attire, mid- range 4/16/ 2006 Willie Masters

13 ERD 2b A student, identified by a studentID, can participate in zero or many campus-based organizations. Each organization is identified by an organizationID and we store the original date the organization was started on campus, as well as the name of the organization in the data. Each organization may have multiple students participating in that organization. For each student we store his or her name, address, and telephone number. For each student who participates in an organization, we want to store the date that the student started participating in that organization, and an attribute that indicates whether or not the student is willing to be an officer for the organization. There is only one start date per student per organization (in other words, we don’t care whether a student quits an organization and rejoins – we are going to store only one start date per student per organization).

14 ERD 2c You have been asked to design a database for a single hospital. The hospital wants to keep track of data about patients. The hospital wants to keep track of patient admittance, as well as patient treatment by health care professionals. Patients are admitted to the hospital by physicians, but physicians are only one kind of health care professional (HCPROF) at the hospital. Assume that the hospital has a large number of HCPROF’s, but they don’t need to differentiate between physicians and other types of HCPROF’s. Attributes of HCPROF include HCPROFID (identifier), type, and specialty. The hospital wants to keep track of the date a patient was admitted and also the admitting HCPROF. It is possible that a patient may be admitted to the hospital more than once. This is an example of “time stamping” data so that the data can be maintained over time. The hospital wants to keep the patients on file with the assumption that the patient may be admitted more than once and the hospital needs to know each different date that a patient was admitted. Attributes of PATIENT include patient_id (identifier) and patient_name. Any individual patient who is admitted must have exactly one admitting HCPROF, but an HCPROF may admit no patients or many patients. Once admitted, a given patient may be treated by no HCPROF’s, but could be treated by multiple HCPROFs. The particular HCPROF who admits a given patient may or may not treat that same patient. A particular HCPROF may treat any number of patients, or may not treat any patients. Whenever a patient is treated, the hospital records the details of the treatment (TREATMENTDETAIL). Attributes of TREATMENTDETAIL include date, time, and outcome. It is possible that more than one HCPROF participates in the same TREATMENTDETAIL for a patient. The hospital wants to keep track of all HCPROF’s who participate in a treatment. For each HCPROF who participates in a TREATMENTDETAIL, the hospital wants to record the notes from the HCPROF and the amount of time that the HCPROF spent on the treatment. For example, if three HCPROF’s participate in a single TREATMENTDETAIL for a single patient, the hospital wants to keep track of the notes and time spent for each of the three HCPROF’s.