Entity-Relationship Diagrams Elements, Syntax Guidelines Dictionary.

Slides:



Advertisements
Similar presentations
Entity Relationship Diagrams
Advertisements

Entity Relationship (E-R) Modeling
Developing ER-Diagram
Alternative Approach to Systems Analysis Structured analysis
Chapters 7 & 9 System Scope
Entity Relationship (ER) Modeling
Analysis Modeling.
Jan 16, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration 1: a simple cash-only success scenario of Process Sale.
Entity-Relation Modeling Hun Myoung Park, Ph.D., Public Management and Policy Analysis Program Graduate School of International Relations International.
Entity Relationship (E-R) Modeling
System Analysis - Data Modeling
Communication Notation Part V Chapter 15, 16, 18 and 19.
Systems Analysis Requirements structuring Process Modeling Logic Modeling Data Modeling  Represents the contents and structure of the DFD’s data flows.
Entity Relationship Diagrams Basic Elements and Rules.
1 Design Methods for Reactive Systems, R.J. Wieringa Part IV: Behavior Notations Jens Bæk Jørgensen, University of Aarhus.
Chapter 14 (Web): Object-Oriented Data Modeling
Ch5: Software Specification. 1 Descriptive specifications  Describe desired properties of system  Three types:
Entity-Relationship Diagrams Elements, Syntax Guidelines Dictionary.
Entity Relationship Diagrams
Chapter 3: Modeling Data in the Organization
Database Systems: Design, Implementation, and Management Tenth Edition
Data Modeling Introduction. Learning Objectives Define key data modeling terms –Entity type –Attribute –Multivalued attribute –Relationship –Degree –Cardinality.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Chapter 3 © 2005 by Prentice Hall 1 Objectives Definition of terms Definition of terms Importance of data modeling Importance of data modeling Write good.
Chapter 14: Object-Oriented Data Modeling
Modern Systems Analysis and Design Third Edition
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
3 Chapter 3 Entity Relationship (E-R) Modeling Database Systems: Design, Implementation, and Management, Fifth Edition, Rob and Coronel.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
DeSiamorewww.desiamore.com/ifm1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
Data Modeling ERM ERD.
Entity Relationship Diagrams
Systems Analysis and Design in a Changing World, Fifth Edition
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 6 Structuring.
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
9/10/2012ISC 329 Isabelle Bichindaritz1 Entity Relationship (E-R) Modeling.
4 1 Chapter 4 Entity Relationship (ER) Modeling Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 15: Object-Oriented Data Modeling Modern Database Management 9 h Edition Jeffrey A.
Databases : Data Modeling 2007, Fall Pusan National University Ki-Joune Li.
CHAPTER 13: OBJECT-ORIENTED DATA MODELING (OVERVIEW) © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
DOMAIN MODEL- VISUALIZING CONCEPTS Identify conceptual classes related to the current iteration requirements. Create an initial domain model. Distinguish.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
DeSiamorePowered by DeSiaMore1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
5 Systems Analysis and Design in a Changing World, Fifth Edition.
Msigwaemhttp//:msigwaem.ueuo.com/1 Database Management Systems (DBMS)  B. Computer Science and BSc IT Year 1.
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 4 Entity Relationship (ER) Modeling.
Week III  Recap from Last Week Review Classes Review Domain Model for EU-Bid & EU-Lease Aggregation Example (Reservation) Attribute Properties.
Design Model Lecture p6 T120B pavasario sem.
Repetition af Domæne model. Artifact influence emphasizing the Domain Model.
CIS 210 Systems Analysis and Development Week 6 Part I Structuring Systems Data Requirements,
1 Database Systems Entity Relationship (E-R) Modeling.
Detailed Data Modeling. Outline Data Modeling Modeling Constructs –Entities –Relationships –Cardinality Model Basic Rules Advanced Rules Prototyping Process.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
Department of Mathematics Computer and Information Science1 CS 351: Database Management Systems Christopher I. G. Lanclos Chapter 4.
COP Introduction to Database Structures
Modeling data in the Organization
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Semantic Object Modeling (SOM)
Entity Relationship (E-R) Modeling
Entity Relationship (E-R) Modeling
Object Oriented Concepts -I
Object-Oriented Analysis
Entity Relationship Diagrams
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Entity Relationship (ER) Modeling
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

Entity-Relationship Diagrams Elements, Syntax Guidelines Dictionary

Aim of part III zThe subject domain of a software system is the part of the world talked about by the messages that cross the system interface.

TIS

Juice Factory

E-tickets

Entity type zRepresented by a rectangle. zExtension yAll possible instances of entity type. z Extent yAll existing instances of entity type. zIntension yAll properties shared by all possible instances. zDefining intension yProperties used to define the entity type. This is an abstraction of the full, informal meaning.

Attributes zProperties of entities. zCan be listed in a compartment directly below the type name compartment.

Relationships zA set of tuples of entities. zArity is the number of related entities. Binary, ternary, etc. zWe only describe a relationship if we want to express relative cardinality properties: How many entities of one type can exist for each entity of another type.

Elevator system To find a cardinality property, imagine looking at an arbitrary state of the domain and ask how many instances of some entity type can exist in that state.

Inconsistent cardinality properties Path expressions

Association entities

Generalization Instance of a subtype is instance of a supertype

Dynamic vs. Static specialization d: disjoint subtypes c: covers supertype

ERD Modeling Guidelines zERDs can be used to declare any set of entity types and their cardinality properties. zWe use ERDs only to represent the structure of the subject domain. zGuidelines to determine the boundary of the subject domain are relevant for this kind of use of ERDs only. zAll the other guidelines are relevant for all possible uses of ERDs.

Subject domain boundary zFinding entities and events in the subject domain: yRough approximation: What entities and events do the service descriptions refer to? yBetter approximation: What are the messages entering and leaving the system about? xPhysical bodies, Devices, (Parts of) organizations, Conceptual entities, Lexical items xEvents involving these entities yEntities and events should be identifiable by the SuD

Elevator system

Entities vs. attributes zEntities are the things that the system talks about. zAttributes are the things said about entities. ySo if you want to store information about it, it is an entity. zIf information about it can change, it is an entity zEntities have non-derivable properties yRequire real-world observations zAttributes have derivable properties

Entity or attribute???

Specialization attributes

Static or dynamic specialization?

Classification and identification zA type definition should provide a recognition criterion and an identification criterion. y“Is this a car?” - recognition y“How many cars do we have here?” - identification

Subtypes or roles?

Validation zFour suggestions: yConsistency yElementary Sentences ySnapshots yIdentification

Consistency of cardinality properties

Elementary Sentences zAt each moment: yA batch of juice has exactly one recipe. yA recipe may be applicable to any number of batches. yAt any point in time, a heating tank has at most one batch allocated to it. yAt any point in time, a batch is allocated to either 1 or 2 heating tanks. yEach heating tank has exactly one heater.

Snapshots

Identification zMessages entering and leaving the system. zService descriptions

History

Event

Dictionary zA dictionary should contain: yWords used in service descriptions yWords used in messages that cross the external interface yDomain-specific jargon zThe subject domain ERD is a visual supplement to the dictionary

Domain ontology zDomain is part of the world treated as a whole. zOntology is a meta classification.

Syntactic categories zIdentifier -- Unique proper name. z Predicate name. yEntity type name. yRelationship name. yState predicate name. Boolean property. z Attribute name. z Event name.

An elevator control specification zPlanned direction (c: Elevator cage). Attribute. The preferred direction in which c will depart after closing its doors. If there are requests to be served higher and lower than the current floor of the elevator cage, then it will depart in the planned direction. zRound trip time. The time in seconds for a single car trip around a building from the time the cage doors open at the main terminal until the doors reopen when the cage has returned to the main terminal floor after its trip. zAt_floor(b: Request button, c: Elevator cage). Predicate. yc.current floor = b.floor. z continue (c: Elevator cage). Action. Term is applicable only if yc.planned direction <> none. yIf c.planned direction = up then start up (c.motor). yIf c.planned direction = down then start down (c.motor). zThe motor of c is started in the planned direction of c.

Defining Concepts zExtensional definitions list a few instances of the concept. yEasy to give. But do not define an intension. zIntentional definition lists the defining properties shared by all instance of the concept. yDifficult zAdvice: yGive a few examples, a sketch of the intent, and indicate the procedure that determines whether an instances falls under the concept.

Define a term zTo clarify a term. zTo indicate that the term is open-textured. zTo indicate that we attach little meaning to it. zThe term is absolutely obvious to all stakeholders -- but they attach different meanings to it.

Do not define a term zTo raise a cloud of obscurity. yBad idea, but frequent practice. zDefinitions can also be found in technical documentation of devices. yDon't repeat these. zThe term is absolutely obvious to all stakeholders yThey understand the same by it.

Genus and difference Identificationrecognition

Operational definitions zExample - Heating tank: yEntity type. A tank with a heater and thermometer attached. The heater can be recognized by red, blue and black wires leading up to it, and the thermometer by its rectangular shape

Abbreviations versus correspondence rules zAbbreviation: yTo determine whether an individual is an instance of the defined concept, you do not need new observations but simply look up words in the dictionary. zCorrespondence rules: yTo determine whether an individual is an instance of the defined concept, you must make observations.