What Is A Data Model. Table of Contents. Abstract An Analogy: Architecture in the Real World Why a Data Model?... 5

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "What Is A Data Model. Table of Contents. Abstract An Analogy: Architecture in the Real World Why a Data Model?... 5"

Transcription

1 Author: Bob Zoltok, Roberts Logan Inc. Date: September 23, 2015 Table of Contents Abstract... 2 An Analogy: Architecture in the Real World... 3 Why a Data Model?... 5 What s In A Data Model (And How To Read It)... 6 What To Review In A Data Model... 9 Health Care Insurance - Conceptual Data Model (inactive for this paper)... 9 Medical Claims Subject Area (inactive for this paper)... 9 Medical Encounters Subject Area (inactive for this paper)... 9 Members Subject Area (inactive for this paper)... 9 Providers Subject Area (inactive for this paper)... 9 Appendix Supertypes and Subtypes This material is not copy-protected. Copying is not only permitted, it is encouraged. Knowledge only has value when it is shared. Permission to copy, store, redistribute, reference, or reuse is granted with one caveat. If you copy and paste without attribution, you re plagiarizing. Please attribute (the verb) your usage to the author: Bob Zoltok Roberts Logan Inc. Unit nd Ave. Surrey, British Columbia V4A 9T4 Canada Phone: Sep :18 PM Roberts Logan Inc Page 1 of 10

2 Abstract Forget about data for a minute. What exactly is a model (think model houses, model cars, model airplanes, etc.)? A model is a visual communication mechanism that describes a simplified but rigorous virtual representation of a physical reality, in terms of its parts and the relationships between those parts, in just enough clarity and detail so that you can begin to: verify and validate those parts and relationships before the physical reality is delivered; and scope and plan the complexity, the priority, the sequence, and the delivery of those parts before you know all the answers. What distinguishes a model from a picture? A picture represents static behavior; a model represents dynamic behavior, for which assumptions can be made, theories and changes can be tested (and re-tested), and from which conclusions can be drawn. So what is a data model? It is just what it says: a model of the data that an organization requires. It is not a model of the processes that the organization may execute against the data, nor a model of the organization s alignment or its technology environment. It is a model of data that is process-agnostic, organization-agnostic, and technology-agnostic. A data model defines the informational items of which the organization is interested, and for which the organization wishes to retain a permanent record. A data model classifies and organizes those items, the details or properties of each item, and the naturally occurring relationships between those items. A data model therefore limits itself to those business rules of the organization that can be expressed as data and relationships between data. It is the structural load-bearing data framework, around which people will interact, processes will execute, and technology will implement. A data model is quite literal. It doesn t know why the data is required (organization knowledge), what is going to be done with the data (process knowledge), or how the data is going to be stored and processed (technical knowledge). Its focus is singleminded; it only knows that the organization requires the data. Finally, a data model is not a flow model. It does not define when, where, why, or how data flows in and out of an organization; think of a data model as defining data at rest. Data models are often defined in terms of 3 levels of abstraction, where each level is designed for a different audience: 1. Conceptual, providing a high-level view of organization-wide data relationships, to enable an organization to identify, scope, and approve subsets of that data for a more detailed analysis and expansion to the next level; 2. Logical, providing a more-detailed view for review and approval by the functional units within the organization; and 3. Physical, providing the most-detailed technology-dependent view for review and approval by the technical colleagues with the organization who will transform the physical data model into a physical data base. This white paper defines the purpose and contents of a Conceptual Data Model. Sep :18 PM Roberts Logan Inc Page 2 of 10

3 An Analogy: Architecture in the Real World In the real world, architects prepare models of buildings/houses they will build. An architect s conceptual model of a house might look like this: This model illustrates many of the fundamental principles of a conceptual model: It is a simplified view of the house, it doesn t show everything, just the highlights, i.e. the rooms, their relative position, and how to navigate between rooms; It scopes the house, i.e. it clearly defines what s in and what s out ; Within a room, many details are not shown. What is shown are the major fixtures, i.e. fridge and dishwasher in the kitchen, shower in the bathroom, etc.; and It shows the connectors between the rooms, i.e. doors and hallways. In this real world, this conceptual model provides just enough details to get agreement in principle that: The client can look at the model and confirm it captures the essentials of what they want; the client looks at the model and says I get it ; They understand the model enough to be able to visualize the ultimate to-bedelivered house; the client says I understand enough to envision what the finished house will look like ; and They feel sufficiently reassured and are confident enough to approve this model and authorize the architectural team to proceed, not to final completion, but to the next phase (which will produce a more detailed model). Sep :18 PM Roberts Logan Inc Page 3 of 10

4 A data model follows those same principles. Starting with level 1, the Conceptual view, a Conceptual Data Model: Is a simplified view of the data, i.e. it does not show every data item, just the highlights. In a conceptual data model, those highlights are called subject areas. Think of a subject area like a room in a house. For example, the kitchen contains the major kitchen-related items (fridge, dishwasher, etc.). The subject area Medical Claims (see below) contains the major medical claim-related data items. Scopes the data, by classifying the data into in-scope areas and out-of-scope areas, and showing how all the areas connect. Within a subject area, does not show most details. What is shown are the important data items, upon which the subject area is focused. Those important data items are called entities. Shows the important connectors between entities. Those connectors are called relationships. You may have heard these types of models referred to as entity-relationship diagrams or ERD s. A Conceptual Data Model is always an evolving framework; the example below is for a Health Insurance organization: MEMBERS MEMBER A person who has been enrolled (or is being enrolled) as a member of a health INSURANCE PLAN offered by a PLAN SPONSOR that reimburses the person for the cost of healthcare SERVICE OFFERING's incurs at a HEALTHCARE FACILITY INSURANCE ORGANIZATIONS reimburses sells belongs to HEALTHCARE INSURANCE PLAN executes enrolls as A plan established for the purposes of insuring persons for the costs of ENCOUNTER's at a HEALTHCARE FACILITY INSURANCE ORGANIZATION A legal organization incorporated and authorized to sell INSURANCE PLAN's reimburses PLAN SPONSORS EMPLOYEE A person employed by a PLAN SPONSOR AGREEMENTS employs PLAN SPONSOR A legal organization that sponsors a health INSURANCE PLAN that provide medical coverage to its MEMBER's AGREEMENT buys A legally defined and executed conce that defines the terms and obligations of a business relationship to which 2 parties agree COLOR LEGEND Logical construct that may require further research and elaboration HEALTHCARE ORGANIZATIONS executes HEALTHCARE ORGANIZATION A legal organization established for the purposes of delivering healthcare. The actual SERVICE OFFERING's are delivered via a "network" of facilities that are operated under the terms and conditions of an AGREEMENT between the HEALTHCARE ORGANIZATION and an INSURANCE ORGANIZATION operates is submitted to S ITEM The specific healthcare SERVICE OFFERING that was provided during a ENCOUNTER by a MEMBER at a HEALTHCARE FACILITY includes The request for payment resulting from a ENCOUNTER by a MEMBER at a HEALTHCARE FACILITY submits HEALTHCARE FACILITY A specific clinic or facility that is part of a HEALTHCARE ORGANIZATION's "network", which receives patients and provides specific medical services ENCOUNTERS ENCOUNTER triggers An encounter by a MEMBER at an HEALTHCARE FACILITY with a PROVIDER, where a healthcare SERVICE OFFERING is provided. occurs at provides service in PROVIDERS practices at PROVIDER participates in An individual who has been medically licensed and/or certified to provide SERVICE's This Conceptual Data Model defines 8 subject areas (red boxes), 12 entities (black boxes), and 20 relationships (black and blue lines), of which some have been expanded into a further level of detail; other subject areas may be added and detailed later. Sep :18 PM Roberts Logan Inc Page 4 of 10

5 Why a Data Model? Once we understand what a data model is (and is not), it is critical to understand why, i.e. why build a model of anything, why not just build the actual physical thing, be it a house, a plane, a nuclear reactor, etc. Obviously, we could just build it, but our assumption is that s not a smart way to build something complicated or with lots of moving parts. Hopefully, you agree. If I still haven t convinced you, think about driving from Seattle to Miami. Do you use a map? If yes, why; if not, why not? Do you really just get in your car, start driving, and not stop until you reach Miami? As an aside, a map also does not teach you the technical aspects of driving; it assumes you already know that. We build a data model for 6 reasons. A data model allows you to: 1. classify and organize work into smaller bite-size parts ; 2. scope, prioritize, sequence, and schedule those parts 1 ; 3. start work and objectively measure forward progress; 4. conduct in-progress checkpoints, to assess results and identify errors; 5. make mid-course corrections and approve progressive milestones; and 6. know and plan when/how to stop work. These 6 reasons should be the litmus test for your data models. If your data models are not helping you in at least 4 of the above areas, stop modeling and just build the thing. If you are not doing points 2 and 4, stop modeling and just build the thing. (If you re not conducting checkpoints and finding errors, you re not looking hard enough.) The purpose of a data model is not to get it perfectly right. Be careful if asked when will the data model be finished?. In our opinion, a data model is never finished; it is finished enough. The purpose of a data model is to get it perfect enough (a.k.a. not obviously wrong) and get everybody on the same page. Once it s perfect enough, you can start work, catch mistakes early in virtual reality (when they are easier and cheaper to fix), and make forward progress that can be objectively measured. you can now bring all sorts of data together to create models that will show you how all kinds of complex things work together before you actually go through the expensive process of building them. 2 As an example, an organization has many rules, policies, standards, etc. Some rules are processing rules. In health insurance for example, a Medical Claim will not be considered complete until approved by a Provider. Some rules are organizational; a Healthcare Organization may create multiple Addresses (physical, billing, etc.). A data model models the data about which the organization is interested and those rules, policies, or standards that can be fully defined in terms of data and data relationships. A data model can capture the rule that, as part of creation, a Medical Claim may be approved by a Provider; it cannot easily capture the rule that, as part of completion, a Medical Claim must be approved by a Provider. A data model can easily capture the above organizational rule that a Healthcare Organization may create multiple Addresses. 1 This assumption is fundamental: the model structure defines the sequence, not the other way around. 2 Thomas Friedman, The World Is Flat, page 296 Sep :18 PM Roberts Logan Inc Page 5 of 10

6 What s In A Data Model (And How To Read It) We said earlier that a data model is a visual communication mechanism. As such, it uses a consistent visual grammar that communicates and implies specific data rules. The major visual grammars are as follows: 1. Data is described visually by boxes called entities. An entity is named in the singular. E.g. If an organization wishes to retain data about the medical claims submitted by its members and the medical claim items within each medical claim, it could model it by creating 3 entities: MEMBER ORDER ITEM ORDER ITEM Details about the member (E.g. First Name, Last Name) would go in the Member entity; details about the claim (E.g. Occurrence Date) would go in the Medical Claim entity; details about the services performed (E.g. Flu Shot) would go in the Medical Claim Item entity, etc. 2. Naturally occurring business rules between entities are described visually by lines called relationships. The line is named with an active-tense verb that describes the relationship in terms of a parent entity and a child entity. The verb is placed as close as possible to the entity to which it applies. Relationships are then read in this order: entity closest to verb, verb, other entity. (For those with an analog watch, relationships may also be read clockwise.) E.g. Each Medical Claim includes Medical Claim Items; each Medical Claim Item is included in a Medical Claim. includes ITEM 3. Relationships are further described by two properties: cardinality and optionality. Cardinality 3 defines how many, i.e. the number of occurrences of one entity involved in one occurrence of the other entity (called a pairing ). There are 2 cardinality choices: exactly one or one or more than one. E.g. Each Medical Claim includes one or more than one Medical Claim Item; each Medical Claim Item is included in exactly one Medical Claim. includes ITEM The symbol means one or more than one; the symbol without the means exactly one. 3 Cardinality may also be referred to as Multiplicity. Sep :18 PM Roberts Logan Inc Page 6 of 10

7 4. Optionality defines if, when a parent entity is created, it must be related to a child and vice versa. There are 3 optionality choices: fully mandatory, partially optional, and fully optional. In a fully mandatory relationship, when you create a parent entity, you must create a related child entity and a pairing; AND when you create a child entity, you must create a related parent entity and a pairing. E.g. Each Medical Claim always includes one or more than one Medical Claim Item; each Medical Claim Item always is included in exactly one Medical Claim. includes ITEM 5. In a partially optional relationship, one of the entities (usually the parent) may be created without the creation of the related entity. E.g. Each Medical Encounter sometimes 4 triggers one or more than one Medical Claim; each Medical Claim always is triggered by exactly one Medical Encounter. ENCOUNTER triggers The circle ( ) means optional. It means that the entity next to the is optional, i.e. the entity that does not need to be created. In example 4, the lack of the circle means always; in example 5, the circle means sometimes 4. Example 4 says that, when a Medical Claim is created, at least one Medical Claim Item must also be created. Example 5 says that a Medical Encounter may be created without creating (i.e. triggering) a Medical Claim, but a Medical Claim may not be created without a triggering Medical Encounter. 6. In a fully optional relationship, either entity may be created and exist (or not), independent of the related entity. E.g. Each Provider sometimes 4 approves one or more than one Medical Claim; each Medical Claim sometimes 4 is approved by exactly one Provider. PROVIDER approves Example 6 says that a Provider may be created and retained without a Medical Claim AND a Medical Claim may be created and retained without an approving Provider. This does not mean a Medical Claim will be paid without an approving Provider (possible organization rule). It only says, from a data perspective, a Medical Claim may be initially created and retained without an approving Provider (just like a bedroom may be created without any furniture). 4 Sometimes is often combined with cardinality and referred to as Zero or One or Zero, One, or More. Sep :18 PM Roberts Logan Inc Page 7 of 10

8 These rules implied by the relationship may or may not be true. One of the major goals of a data model is to portray the data and the implied data rules visually, so that they can be reviewed and confirmed before we build the ultimate deliverable. If we now put parts 1-6 together, the result is a model which summarizes all the data objects and rules (i.e. entities and relationships) into one visual representation as shown below. MEMBER incurs ENCOUNTER triggers PROVIDER submits approves includes ITEM This single visual model implies many business rules; their truth will be confirmed by the client: Each Medical Encounter must trigger a Medical Claim; this is a change from the previous point 5 on page 7. Obviously, there will be Medical Encounters that don t trigger a Medical Claim, but this insurance organization isn t interested in those encounters. They re not in the business of tracking Medical Encounters that don t trigger a Medical Claim. They don t track all Medical Encounters, only those encounters that trigger a claim. They care about claims. Each Medical Claim can only be triggered by one Medical Encounter. If the same Member has 2 Medical Encounters, a second Medical Claim must be submitted for that second encounter. Each Medical Claim, and by implication all the Medical Claim Items included in that claim, can only be approved by one Provider. If 2 Providers are required to approve a Medical Claim (or one of the Medical Claim Items), the model must be changed or a Member will be required to submit a second Medical Claim. Providers play multiple roles in a Medical Claim: the submitting Provider and the approving Provider. Each role may have different business rules, some of which may not be easily shown in a data model. We may wish to introduce this concept of roles into the model, to capture role-specific business rules. This organization may or may not wish to operate its business according to these rules; the purpose of the data model is to bubble up (and make crystal clear) these business rules so they can be confirmed. Sep :18 PM Roberts Logan Inc Page 8 of 10

9 What To Review In A Data Model When you are asked to review a data model, keep in mind that one of the purposes of the review is to find errors. While it is usually difficult to confirm that the model is right, it is often easier to see that the model is wrong. This is one of the advantages of a visual mechanism, and is one of the expectations of a review: find errors. The deliverables of a Conceptual Data Model may consist of two documents: Subject Area ERD Overview (inactive for this paper) An entity-relationship diagram (ERD), showing the major subject areas, the major entities within each subject area, and the major relationships between entities. Pages 4 and 8 provides examples of an ERD. Entity-Attribute Detail Definitions (inactive for this paper) A text document, containing definitions for all the objects in the Conceptual Data Model. Those objects include all subject areas, all entities, all known details (attributes) about entities, and all relationships between entities. In a Conceptual Data Model, the majority of the collateral will be for the subject areas and the entities. The model may or may not contain any attributes or any details about attributes. This deliverable may be a Word document, an Excel spreadsheet, a PDF document, or some type of an HTML/Web document. Focus your review on the following: Anything missing, i.e. in your mind, what key data concept do you not see? For our sample model on Page 8: where would Child Claims go? Are all the major subject areas present? Are there any subject areas missing? Are all the major entities correctly identified and defined? Are the definitions correct and do the examples make sense to you? Are the cardinality and optionality implications of the major relationships correct, in terms of Mandatory vs. Optional and One vs. One or More? Do not focus too much on the names of an entity (unless you believe it s really wrong); those names can be changed. Instead, focus on the definitions and examples; is it clear from the definition what the entity represents? If there are attributes in the Conceptual Data Model (there may be none), do not focus too much on them. At this phase of the project, attributes are analogous to the colour of the wall paint in the second bedroom: important, but may be deferred and resolved later. As stated on page 4, our sample Conceptual Data Model defines 8 subject areas. Those interested in further details may review each subject area in more detail at: Health Care Insurance - Conceptual Data Model (inactive for this paper) Specific subject areas of interest may include: Medical Claims Subject Area (inactive for this paper) Medical Encounters Subject Area (inactive for this paper) Members Subject Area (inactive for this paper) Providers Subject Area (inactive for this paper) Sep :18 PM Roberts Logan Inc Page 9 of 10

10 Appendix Supertypes and Subtypes In a data model, you may encounter situations where the organization views some entities as the same, but still wants to allow for minor differences. The modeler may choose to further classify those entities in a hierarchy by type. To model this hierarchy, selected typed entities may be defined as supertypes or subtypes. Details applicable to all the entities are contained within the supertype; details unique to one (or more) of the entities are contained within the subtype(s). E.g. A Provider may be typed as either Primary Care Provider, Psychologist, Neurologist, etc. They re all Providers with some details in common: they all have a Name, University Graduation Date. Each has unique details: a Primary Care Provider may have an Office Address, etc.; a Psychologist may have a Specialty and Sub-Specialty; a Neurologist may have a Board Certification Date. PROVIDER SUPERTYPE PRIMARY CARE PROVIDER SUBTYPES PSYCHOLOGIST NEUROLOGIST A Medical Claim may be typed as Hospital Claim, Ambulance Claim, etc. They re both Medical Claims with some details in common: they both have an Effective Date, etc. Each has unique details: a Hospital Claim will have an Admission Date, a Discharge Date, etc.; an Ambulance Claim may have a Distance Travelled, Time of Day, etc. HOSPITAL AMBULANCE ORGANIZATION Sep :18 PM Roberts Logan Inc Page 10 of 10

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Prof. David Gadish Structuring System Data Requirements Learning Objectives Concisely define each of the following key data modeling terms: entity type, attribute, multivalued

More information

Modeling As A Risk Management Strategy

Modeling As A Risk Management Strategy Modeling As A Risk Management Strategy Enterprise Data World 2010 San Francisco March 17 th, 2010 All rights reserved. This material is protected under U.S. and Canadian copyright. No part of this material

More information

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc.

Chapter 10 Structuring System Requirements: Conceptual Data Modeling. Copyright 2002 Prentice-Hall, Inc. Chapter 10 Structuring System Requirements: Conceptual Data Modeling 10.1 Copyright 2002 Prentice-Hall, Inc. Learning Objectiveses 10.2 Define key data modeling terms Entity type Attribute Multivalued

More information

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring System Requirements: Conceptual Data Modeling 10.1 Copyright 2002 Prentice-Hall,

More information

Appendix C: Entity Relationship Diagram for Electronic Resource Management

Appendix C: Entity Relationship Diagram for Electronic Resource Management Appendix C: Entity Relationship Diagram for Electronic Resource Management Nathan D. M. Robertson, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Kimberly Parker, and Angela Riggio Introduction

More information

Entity-Relationship Model. Database Modeling (Part 1) Entity. Entity-Relationship Model EMPLOYEE

Entity-Relationship Model. Database Modeling (Part 1) Entity. Entity-Relationship Model EMPLOYEE Entity-Relationship Model Database Modeling (Part 1) A conceptual data model, which is a representation of the structure of a database that is independent of the software that will be used to implement

More information

Systems Analysis and Design

Systems Analysis and Design Systems Analysis and Design Slides adapted from Jeffrey A. Hoffer, University of Dayton Joey F. George, Florida State University Joseph S. Valacich, Washington State University Modern Systems Analysis

More information

ERD Getting Started Guide

ERD Getting Started Guide Enterprise Studio ERD Getting Started Guide 2016-11-08 Table of contents 1 About modeling with ERD 3 1.1 What are entity-relationship diagrams? 3 1.2 Entity-relationship modeling 3 1.3 ERD in Enterprise

More information

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 2 Conceptual Design Greetings to you all. We have been talking

More information

Why & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements

Why & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements Introduction It should be a requirement of the job that business analysts document process AND data requirements Process create, read, update and delete data they manipulate data. Process that aren t manipulating

More information

Using the Information Engineering Notation.

Using the Information Engineering Notation. Using the Information Engineering Notation. Scott Lurton Specialist Master slurton@deloitte.com 1 I wrote this white paper because I was becoming more and more concerned about the loss of time caused by

More information

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 1a Conceptual Design Hello in today session we would be looking

More information

Chapter 3. Data Analysis and Diagramming

Chapter 3. Data Analysis and Diagramming Chapter 3 Data Analysis and Diagramming Introduction This chapter introduces data analysis and data diagramming. These make one of core skills taught in this course. A big part of any skill is practical

More information

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc.

Database Systems - Introduction to Databases and Data Warehouses. Copyright (c) 2014 Pearson Education, Inc. Database Systems - Introduction to Databases and Data Warehouses Copyright (c) 2014 Pearson Education, Inc. INTRODUCTION Entity-relationship (ER) modeling - conceptual database modeling technique Enables

More information

PERANCANGAN SISTEM INFORMASI

PERANCANGAN SISTEM INFORMASI PERANCANGAN SISTEM INFORMASI Session 5 Data Modeling Based on on System Analysis & Design 2 nd nd Edition Authors :: Alan Dennis & Barbara Haley Wixom Publisher :: John Wiley & Sons Faculty of Computer

More information

Lecture 12: Entity Relationship Modelling

Lecture 12: Entity Relationship Modelling Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This

More information

Variables and Hypotheses

Variables and Hypotheses Variables and Hypotheses When asked what part of marketing research presents them with the most difficulty, marketing students often reply that the statistics do. Ask this same question of professional

More information

(Refer Slide Time 6:09)

(Refer Slide Time 6:09) Digital Circuits and Systems Prof. S. Srinivasan Department of Electrical Engineering Indian Institute of Technology, Madras Lecture 3 Combinational Logic Basics We defined digital signal as a signal which

More information

Elementary Algebra. Section 0.4 Factors

Elementary Algebra. Section 0.4 Factors Section 0.4 Contents: Definitions: Multiplication Primes and Composites Rules of Composite Prime Factorization Answers Focus Exercises THE MULTIPLICATION TABLE x 1 2 3 4 5 6 7 8 9 10 11 12 1 1 2 3 4 5

More information

The Entity-Relation Diagram (ERD)

The Entity-Relation Diagram (ERD) Key Definitions Data Modelling Chapter 7 A data model shows the people, places and things of interest to an organization and the relationships among them. The logical data model shows the organization

More information

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group

More information

Modeling Guidelines Manual

Modeling Guidelines Manual Modeling Guidelines Manual [Insert company name here] July 2014 Author: John Doe john.doe@johnydoe.com Page 1 of 22 Table of Contents 1. Introduction... 3 2. Business Process Management (BPM)... 4 2.1.

More information

Guide To Data Modeling

Guide To Data Modeling Guide To Data Modeling Advisor Major Student Major = { MajorCode + Desc } Advisor = { StudentNo + MajorCode + Advisor } Student = { StudentNo + Name + Address } Major Table Advisor Table MajorCode Desc

More information

Data Modeling: Part 1. Entity Relationship (ER) Model

Data Modeling: Part 1. Entity Relationship (ER) Model Data Modeling: Part 1 Entity Relationship (ER) Model MBA 8473 1 Cognitive Objectives (Module 2) 32. Explain the three-step process of data-driven information system (IS) development 33. Examine the purpose

More information

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

Database Design Process

Database Design Process Entity-Relationship Model Chapter 3, Part 1 Database Design Process Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning 1 Problem: University

More information

Business Definitions for Data Management Professionals

Business Definitions for Data Management Professionals Realising the value of your information TM Powered by Intraversed Business Definitions for Data Management Professionals Intralign User Guide Excerpt Copyright Intraversed Pty Ltd, 2010, 2014 W-DE-2015-0004

More information

Model Simulation in Rational Software Architect: Business Process Simulation

Model Simulation in Rational Software Architect: Business Process Simulation Model Simulation in Rational Software Architect: Business Process Simulation Mattias Mohlin Senior Software Architect IBM The BPMN (Business Process Model and Notation) is the industry standard notation

More information

A data model can be thought of as a diagram or flowchart that illustrates the relationships between data Data modeling techniques and tools capture

A data model can be thought of as a diagram or flowchart that illustrates the relationships between data Data modeling techniques and tools capture DATA MODELING definition A data model is a visual representation of people, places and things of interest to a business and is composed of a set of symbols that communicate concepts and their business

More information

Database Design Process

Database Design Process Database Design Process Entity-Relationship Model From Chapter 5, Kroenke book Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning Problem:

More information

True. All that perfect systems need are correct programs.

True. All that perfect systems need are correct programs. Skip navigation elements to page contents Test: Mid Term Exam - Database Design Review your answers, feedback, and question scores below. An asterisk (*) indicates a correct answer. Section 1 Lesson 1

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

Lesson III. Entity- Relationship Model

Lesson III. Entity- Relationship Model Lesson III Entity- Relationship Model IN THIS LESSON YOU WILL LEARN What a ER diagram is (ERD) and what it is used for. To identify the main constructs in a ERD. To understand the difference between entities

More information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

Data Modeling. Relationships within the Relational Database:

Data Modeling. Relationships within the Relational Database: Data Modeling Relationships within the Relational Database: A relationship describes association among entities. For example, a relationship exists between customers and an agent, in that an agent can

More information

NRS Business Process Standards and Guidelines using BPMN

NRS Business Process Standards and Guidelines using BPMN Corporate Services for the Natural Resource Sector Information Management Branch NRS Business Process Standards and Guidelines using BPMN Last Updated: June 21, 2016 Version: 1.0.1 Document: NRS Business

More information

22 st Annual Psychological Science Poster Session

22 st Annual Psychological Science Poster Session 22 st Annual Psychological Science Poster Session Instruction Booklet Poster Session: Thursday, April 17, 2014, 1:00-4:00 p.m. Deadline for Entering: Thursday, April 3, 2014 Location: World Languages &

More information

مدلسازی اطالعات سازمان. Entity Relationship Diagram (ERD)

مدلسازی اطالعات سازمان. Entity Relationship Diagram (ERD) مدلسازی اطالعات سازمان Entity Relationship Diagram (ERD) Introduction A database is a collection of data that is organized in such a manner that its contents can be readily accessed, managed and updated

More information

In-Depth Guide: Database Design

In-Depth Guide: Database Design In-Depth Guide: Database Design Learning Objectives Define terms related to conceptual data modeling Understand the elements of a conceptual data model Develop a conceptual data model based on business

More information

Solution Architecture Guide Working example for an organization attempting to implement a Data Governance Framework

Solution Architecture Guide Working example for an organization attempting to implement a Data Governance Framework Solution Architecture Guide Working example for an organization attempting to implement a Data Governance Framework Measuring, Creating, & Delivering the RIGHT Value Page 1 Solution Architecture There

More information

6.3 Conditional Probability and Independence

6.3 Conditional Probability and Independence 222 CHAPTER 6. PROBABILITY 6.3 Conditional Probability and Independence Conditional Probability Two cubical dice each have a triangle painted on one side, a circle painted on two sides and a square painted

More information

Construction Junction. Inventory Management Software Requirements Specification

Construction Junction. Inventory Management Software Requirements Specification Construction Junction Inventory Management Software Requirements Specification Version 2.0 Summa Technologies October 1st, 2009 Summa Technologies, Inc. 925 Liberty Avenue 6 th Floor Pittsburgh, PA 15222

More information

Data Extraction Guide

Data Extraction Guide 1 Data Extraction Guide One of the big advantages of process mining is that it starts with the data that is already there, and usually it starts very simple. There is no need to first set up a data collection

More information

Logical Database Design and the Relational Model (Significant Concepts)

Logical Database Design and the Relational Model (Significant Concepts) Logical Database Design and the Relational Model (Significant Concepts) Learning Objectives This topic is intended to introduce the Logical Database Design and the Relational Model. At the end of the topic

More information

Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization

Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization Modern Database Management, 12e (Hoffer) Chapter 2 Modeling Data in the Organization 1) The logical representation of an organization's data is called a(n): A) database model. B) entity-relationship model.

More information

Chapter 4. Entity Relationship (ER) Modeling. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel

Chapter 4. Entity Relationship (ER) Modeling. Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel Chapter Entity Relationship (ER) Modeling Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel 1 In this chapter, you will learn: How relationships between entities

More information

LECTURE 11: PROCESS MODELING

LECTURE 11: PROCESS MODELING LECTURE 11: PROCESS MODELING Outline Logical modeling of processes Data Flow Diagram Elements Functional decomposition Data Flows Rules and Guidelines Structured Analysis with Use Cases Learning Objectives

More information

Assigning Probabilities

Assigning Probabilities What is a Probability? Probabilities are numbers between 0 and 1 that indicate the likelihood of an event. Generally, the statement that the probability of hitting a target- that is being fired at- is

More information

A brief overview of developing a conceptual data model as the first step in creating a relational database.

A brief overview of developing a conceptual data model as the first step in creating a relational database. Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction

More information

TEACHER S PAGE. Reporting Verbs

TEACHER S PAGE. Reporting Verbs TEACHER S PAGE Reporting Verbs AIM: To get students practicing and using reporting verbs. SUB-AIMS: Listening, speaking. STUDENT AGE/LEVEL: Young adults / Upper-Intermediate SUPPLEMENTARY MATERIALS: I

More information

Conceptual Modeling and Entity-Relationship Diagrams

Conceptual Modeling and Entity-Relationship Diagrams Conceptual Modeling and Entity-Relationship Diagrams Chapter 3 & 4: Elmasri/Navathe 3753 X1 Outline Phases of Database Design Conceptual Modeling Abstractions in Conceptual Design Example Database Requirements

More information

Measurement Information Model

Measurement Information Model mcgarry02.qxd 9/7/01 1:27 PM Page 13 2 Information Model This chapter describes one of the fundamental measurement concepts of Practical Software, the Information Model. The Information Model provides

More information

January 2010. Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling. Sponsored by:

January 2010. Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling. Sponsored by: Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling January 2010 Claudia Imhoff, Ph.D Sponsored by: Table of Contents Introduction... 3 What is a Data Model?...

More information

Database Management Systems

Database Management Systems Database Management Systems Database Design (1) 1 Topics Information Systems Life Cycle Data Base Design Logical Design Physical Design Entity Relationship (ER) Model Entity Relationship Attributes Cardinality

More information

Architecture Artifacts Vs Application Development Artifacts

Architecture Artifacts Vs Application Development Artifacts Architecture Artifacts Vs Application Development Artifacts By John A. Zachman Copyright 2000 Zachman International All of a sudden, I have been encountering a lot of confusion between Enterprise Architecture

More information

CSI 2132 Tutorial 2. Conceptual Modeling: The Entity-Relationship Model. Database Design: Overview 30/01/2012. Get Requirements and Data

CSI 2132 Tutorial 2. Conceptual Modeling: The Entity-Relationship Model. Database Design: Overview 30/01/2012. Get Requirements and Data CSI 2132 Tutorial 2 Conceptual Modeling: The Entity-Relationship Model Database Design: Overview Get Requirements and Data Conceptual Model Logical Model Physical Model 2 1 Entity-Relationship Diagram

More information

Chapter 4B Objectives. Developing an ER Diagram. Refining an E-R Model. Developing an E-R Model. Understand

Chapter 4B Objectives. Developing an ER Diagram. Refining an E-R Model. Developing an E-R Model. Understand Chapter 4B Objectives Understand How ERD components affect database design and implementation That real-world database design often requires the reconciliation of conflicting goals Database design is an

More information

Microsoft Excel IF & AND Functions. By Stephen Groulx

Microsoft Excel IF & AND Functions. By Stephen Groulx Microsoft Excel IF & AND Functions By Stephen Groulx Excel IF & AND Functions Table of Contents Page Introduction... 3 IF Function, Simplified... 6 IF Function, Nested... 8 AND Function... 16 Assumptions

More information

Annex B Database Entity Relationship Diagrams

Annex B Database Entity Relationship Diagrams Annex B Database Entity Relationship Diagrams 1. Overview The data model presented in this annex represents a logical view of the database design for the ITL. It does not include all the entities needed

More information

Chapter 3 Use Cases. Table of Contents. Chapter Overview. Chapter Overview Learning Objectives Notes on Opening Case

Chapter 3 Use Cases. Table of Contents. Chapter Overview. Chapter Overview Learning Objectives Notes on Opening Case Systems Analysis and Design in a Changing World, sixth edition 3-1 Chapter 3 Use Cases Table of Contents Chapter Overview Learning Objectives Notes on Opening Case Chapter Overview This chapter extends

More information

Populating a Data Quality Scorecard with Relevant Metrics WHITE PAPER

Populating a Data Quality Scorecard with Relevant Metrics WHITE PAPER Populating a Data Quality Scorecard with Relevant Metrics WHITE PAPER SAS White Paper Table of Contents Introduction.... 1 Useful vs. So-What Metrics... 2 The So-What Metric.... 2 Defining Relevant Metrics...

More information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps. DATABASE DESIGN - The ability to design databases and associated applications is critical to the success of the modern enterprise. - Database design requires understanding both the operational and business

More information

Producing a Gantt Chart Using Microsoft Excel s Bar Graph Functionality

Producing a Gantt Chart Using Microsoft Excel s Bar Graph Functionality Producing a Gantt Chart Using Microsoft Excel s Bar Graph Functionality Introduction Gantt Charts are used in a variety of settings, especially when complex projects are implemented. Gantt Charts give

More information

Guidelines for Best Practices in Data Management Roles and Responsibilities

Guidelines for Best Practices in Data Management Roles and Responsibilities Guidelines for Best Practices in Data Management Roles and Responsibilities September 2010 Data Architecture Advisory Committee A subcommittee of Information Architecture & Standards Branch Table of Contents

More information

Communicating with Allied Trades

Communicating with Allied Trades Communicating with Allied Trades CHAPTER 7 In this chapter, you will learn about The related professionals you work with on an AV project Three common organizational tools used to track an AV project The

More information

ARIS Filter for SAP Definitions

ARIS Filter for SAP Definitions ARIS Filter for SAP Definitions As of August 9, 2006 Claudius Müller-Wening SAP Process Office SAP AG Process Information in Models Business Rules Purpose & Goal Why is the performed? Ultimate reason for

More information

Five Core Principles of Successful Business Architecture

Five Core Principles of Successful Business Architecture Five Core Principles of Successful Business Architecture Authors: Greg Suddreth and Whynde Melaragno Strategic Technology Architects (STA Group, LLC) Sponsored by MEGA Presents a White Paper on: Five Core

More information

Quick Preview PROPERTY DAMAGE

Quick Preview PROPERTY DAMAGE Quick Preview PROPERTY DAMAGE You are you first priority, take care of you first Understand rental insurance, towing and storage costs Figure out what kind of insurance coverage you have Choose a reputable

More information

The Entity-Relationship Diagram

The Entity-Relationship Diagram The Entity-Relationship Diagram Overview of Database Design Conceptual design: (ER Model is used at this stage.) What are the entities and relationships in the enterprise? What information about these

More information

UML Use Case Diagram? Basic Use Case Diagram Symbols and Notations

UML Use Case Diagram? Basic Use Case Diagram Symbols and Notations This file will be helpful during viva exam. You should have all the knowledge about the diagrams which you have included in your presentation. You should know all the symbols, relationships. You must prepare

More information

DAMA-DMBOK Functional Framework

DAMA-DMBOK Functional Framework DAMA-DMBOK Functional Framework Version 3.02 Mark Mosley September 10, 2008 2008 DAMA International All Rights Reserved Table of Contents Table of Contents... 1 About This Document... 1 Revision History...

More information

Preview DESIGNING DATABASES WITH VISIO PROFESSIONAL: A TUTORIAL

Preview DESIGNING DATABASES WITH VISIO PROFESSIONAL: A TUTORIAL DESIGNING DATABASES WITH VISIO PROFESSIONAL: A TUTORIAL A Microsoft Visio Professional is a powerful database design and modeling tool. The Visio software has so many features that it is impossible to

More information

A Relationship Type defines a relationship set among entities of certain entity types

A Relationship Type defines a relationship set among entities of certain entity types Relationship Types A Relationship Type defines a relationship set among entities of certain entity types A relationship type is illustrated in an ERD using a diamond symbol. Consider the following diagram

More information

Entity Relationship (ER) Modeling

Entity Relationship (ER) Modeling Entity Relationship (ER) Modeling ERDs A diagram of the end-user view of a DB Primary goal is to model Attributes Relationships Entities (duh) They look like this! The Types Chen Emphasis on modeling Crow's

More information

How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM

How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM November 5 th, 2015 How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM Requirements Techniques Narrative Statements often in the form of The system/solution

More information

GO-ITS 56.5 OPS Grants Management Reference Model. Appendix A. Approved V2.4

GO-ITS 56.5 OPS Grants Management Reference Model. Appendix A. Approved V2.4 GO-ITS 56.5 OPS Grants Management Reference Model Appendix A Approved V2.4 Preface The Ontario Public Service (OPS) has developed an enterprise architecture program to: Enable the transformation of the

More information

Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking

Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking A DataFlux White Paper Prepared by: David Loshin Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking Leader in Data Quality and Data Integration www.dataflux.com 877 846

More information

Providing a plan of your property.

Providing a plan of your property. Providing a plan of your property. In order to licence the house, the Council has to obtain certain information from you about the property in order that it can assess the type of property it is, and what

More information

CSE 412/598 DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING

CSE 412/598 DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING DATABASE MANAGEMENT COURSE NOTES 3. ENTITY-RELATIONSHIP CONCEPTUAL MODELING Department of Computer Science & Engineering Arizona State University 2 Quality of Conceptual Schema Correctness. No syntactic

More information

RUP iteration planning

RUP iteration planning Page 1 of 13 Copyright IBM Corporation 2004. http://www-106.ibm.com/developerworks/rational/library/5335.html Search for: within All of dw Use + - ( ) " " Search help IBM home Products & services Support

More information

Critical Success Factors of Project Management Planning

Critical Success Factors of Project Management Planning Critical Success Factors of Project Management Planning Kathy Schroeder, RN, PMP, Senior Director, Tenet Healthcare and Liz Coffey, PMP, Service Line Executive, Global Services DISCLAIMER: The views and

More information

Style Guide For Writing Mathematical Proofs

Style Guide For Writing Mathematical Proofs Style Guide For Writing Mathematical Proofs Adapted by Lindsey Shorser from materials by Adrian Butscher and Charles Shepherd A solution to a math problem is an argument. Therefore, it should be phrased

More information

White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications

White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications Accelerate Development Reduce Time to Product Automate Critical Tasks White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications The ASHVINS GROUP, Inc. 6161 Blue Lagoon

More information

Conceptual Design: Entity Relationship Models. Objectives. Overview

Conceptual Design: Entity Relationship Models. Objectives. Overview Conceptual Design: Entity Relationship Models Craig Van Slyke, University of Central Florida cvanslyke@bus.ucf.edu John Day, Ohio University Objectives Define terms related to entity relationship modeling,

More information

DISCLAIMER OVERVIEW WHY DO WE MODEL WHAT IS QUALITY? Jeff Jacobs, jmjacobs@jeffreyjacobs.com

DISCLAIMER OVERVIEW WHY DO WE MODEL WHAT IS QUALITY? Jeff Jacobs, jmjacobs@jeffreyjacobs.com DEVELOPING HIGH CLASS UML CLASS MODELS Jeff Jacobs, jmjacobs@jeffreyjacobs.com DISCLAIMER The views presented here are those of the presenter and do not represent those of any other person, organization,

More information

Chapter 2 Modeling Data in the Organization

Chapter 2 Modeling Data in the Organization 17 Chapter 2 Modeling Data in the Organization Chapter Overview The purpose of this chapter is to present a detailed description of the entity-relationship model and the use of this tool within the context

More information

COMPUTERS WILL GIVE YOU WHAT YOU ASK FOR, NOT WHAT YOU WANT!!! (Some) DEFINITIONS

COMPUTERS WILL GIVE YOU WHAT YOU ASK FOR, NOT WHAT YOU WANT!!! (Some) DEFINITIONS (Some) PRINCIPLES USED TO SEARCH DATABASES (Brief) INTRODUCTION COMPUTERS WILL GIVE YOU WHAT YOU ASK FOR, NOT WHAT YOU WANT!!! Simply put, computers are math machines. As math machines, they process your

More information

Scope Planning (IS PM 5. Lecture, 2012 Spring)

Scope Planning (IS PM 5. Lecture, 2012 Spring) Scope Planning Project success is determined by its usefulness or profitability: in increase of revenue in savings of costs The main reason to change existent information system is to get more benefits

More information

Lesson 26: Reflection & Mirror Diagrams

Lesson 26: Reflection & Mirror Diagrams Lesson 26: Reflection & Mirror Diagrams The Law of Reflection There is nothing really mysterious about reflection, but some people try to make it more difficult than it really is. All EMR will reflect

More information

The 9 Secrets of Successful Project Initiation

The 9 Secrets of Successful Project Initiation The 9 Secrets of Successful Project Initiation Sponsored by AtTask By Andy Jordan March 2012 The 9 Secrets of Successful Project Initiation 2 Introduction There is a lot of time, effort and money spent

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

XV. The Entity-Relationship Model

XV. The Entity-Relationship Model XV. The Entity-Relationship Model The Entity-Relationship Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of E-R Diagrams and Business Rules The

More information

Presentation Guidelines

Presentation Guidelines Presentation Guidelines Presentation Team: Try to keep the number of presenters to 3 or less, but if the presentation requires more people include them. Copies: 10 copies for the judges unless told otherwise.

More information

Writing Learning Objectives: Beginning With The End In Mind

Writing Learning Objectives: Beginning With The End In Mind Writing Learning Objectives: Beginning With The End In Mind Learning Objectives Participants will be able to: Compare and contrast learning objectives vs. learning goals. List the 3 parts of the ideal

More information

? G WE RE HERE TO HELP. Spotted a higher than expected bill? Here s what to do.

? G WE RE HERE TO HELP. Spotted a higher than expected bill? Here s what to do. WE RE HERE TO HELP. J You can find all sorts of information to help reduce the amount of water you use or how to spot and get leaks repaired on our website anglianwater.co.uk or you can call us on 03457

More information

Pan-Canadian Primary Health Care Electronic Medical Record Content Standard, Version 3.0

Pan-Canadian Primary Health Care Electronic Medical Record Content Standard, Version 3.0 pic Pan-Canadian Primary Health Care Electronic Medical Record Content Standard, Version 3.0 Technical Guide Types of Care Our Vision Better data. Better decisions. Healthier Canadians. Our Mandate To

More information

Database Design and Database Programming with SQL - 5 Day In Class Event Day 1 Activity Start Time Length

Database Design and Database Programming with SQL - 5 Day In Class Event Day 1 Activity Start Time Length Database Design and Database Programming with SQL - 5 Day In Class Event Day 1 Welcome & Introductions 9:00 AM 20 Lecture 9:20 AM 40 Practice 10:00 AM 20 Lecture 10:20 AM 40 Practice 11:15 AM 30 Lecture

More information

ETEC 2601 Database Systems

ETEC 2601 Database Systems ETEC 2601 Database Systems Chapter 5: Data Modeling With The Entity-Relationship Model Copyright 2004-2010 J. B. Gallaher The Data Model The design of a database Is the way the user conceives the information

More information

Oracle Data Modeling and Relational Database Design

Oracle Data Modeling and Relational Database Design Oracle University Contact Us: 1.800.529.0165 Oracle Data Modeling and Relational Database Design Duration: 4 Days What you will learn This Oracle Data Modeling and Relational Database Design training covers

More information

1 Class Diagrams and Entity Relationship Diagrams (ERD)

1 Class Diagrams and Entity Relationship Diagrams (ERD) 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural

More information