cb1a4c8df305b07704b716de9865eff7.ppt
- Количество слайдов: 82
Information Systems System Analysis 421 Class Seven
Learning Objectives ü Define key data modeling terms ü Entity type ü Attribute ü Multivalued attribute ü Relationship ü Degree ü Cardinality ü Business Rule ü Associative entity ü Trigger ü Supertype ü Subtype 10. 2
Learning Objectives ü Learn to draw Entity-Relationship (E-R) Diagrams Review the role of conceptual data modeling in overall design and analysis of an information system ü Distinguish between unary, binary, and ternary relationships, and give an example of each ü Define four basic types of business rules in an E-R diagram ü Explain the role of CASE technology in the analysis and documentation of data required in an information system ü Relate data modeling to process and logic modeling as different views describing an information system 10. 3
System Analysis Entity Relationship Data Flow Diagram Prototypes
System Modeling • One way to structure unstructured problems is to draw a model – A model is a representation of reality - picture worth a thousand words – Built to understand the existing system as a way to document business requirements – Data modeling is a technique for defining business requirements • Data is viewed as a resource to be shared by as many processes as possible, data must be organized in a way that is flexible and adaptable to unanticipated business requirements
System modeling • Physical model shows not only what a system does but how the system is physically and technically implemented - depicts technical design • Logical models depict business requirements illustrates the essence of the system – Move biases that are the results of the way the current system is implemented – Reduce the risk of missing requirements – Allow us to communicate with end users – Help analysts and users understand business terminology and rules
Data Modeling • Data modeling is done during the project definition stage and refined in physical design • Data model help the analyst identify business vocabulary and uncover business requirements • Built more quickly • Can be fit on several sheets of paper • Looking ahead – logical models will be transformed into a physical model called database schema – Also be analyzed for adaptability and flexibility through a process called normalization
Conceptual Data Modeling • • Purpose is to show rules about the meaning and interrelationships among data • Entity-Relationship (E-R) diagrams are commonly used to show data are organized • Main goal of conceptual data modeling is to create accurate E-R diagrams • Methods such as interviewing, questionnaires and JAD are used to collect information • 10. 8 Representation of organizational data Consistency must be maintained between process flow, decision logic and data modeling descriptions
Process of Conceptual Data Modeling • First step is to develop a data model for the system being replaced • Next, a new conceptual data model is built that includes all the requirements of the new system • In the design stage, the conceptual data model is translated into a physical design • Project repository links all design and data modeling steps performed during SDLC 10. 9
Deliverables and Outcome • Primary deliverable is the entity-relationship diagram • There may be as many as 4 E-R diagrams produced analyzed during conceptual data modeling – Covers just data needed in the project’s application – E-R diagram for system being replaced – An E-R diagram for the whole database from which the new application’s data are extracted – An E-R diagram for the whole database from which data for the application system being replaced is drawn 10. 1 0
Figure 10 -3 Sample conceptual data model diagram 10. 1 1
Deliverables and Outcome • Second deliverable is a set of entries about data objects to be stored in repository or project dictionary – Repository links data, process and logic models of an information system – Data elements that are included in the DFD must appear in the data model and visa versa – Each data store in a process model must relate to business objects represented in the data model 10. 1 2
Gathering Information for Conceptual Data Modeling • Two perspectives – Top-down • Data model is derived from an intimate understanding of the business – Bottom-up • Data model is derived by reviewing specifications and business documents 10. 13
Introduction to Entity. Relationship (E-R) Modeling • Notation uses three main constructs – Data entities – Relationships – Attributes • Entity-Relationship (E-R) Diagram – A detailed, logical representation of the entities, associations and data elements for an organization or business 10. 14
Entity-Relationship (E-R) Modeling Key Terms • Entity – A person, place, object, event or concept in the user environment about which the organization wishes to maintain data – Represented by a rectangle in E-R diagrams • Entity Type – A collection of entities that share common properties or characteristics • Attribute – A named property or characteristic of an entity that is of interest to an organization 10. 15
Entity-Relationship (E-R) Modeling Key Terms • Candidate keys and identifiers – Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type – Candidate key • Attribute (or combination of attributes) that uniquely identifies each instance of an entity type 10. 16
Entity-Relationship (E-R) Modeling Key Terms • Identifier – A candidate key that has been selected as the unique identifying characteristic for an entity type – Selection rules for an identifier • • 10. 17 Choose a candidate key that will not change its value Choose a candidate key that will never be null Avoid using intelligent keys Consider substituting single value surrogate keys for large composite keys
Entity-Relationship (E-R) Modeling Key Terms • Multivalued Attribute – An attribute that may take on more than one value for each entity instance – Represented on E-R Diagram in two ways: • double-lined ellipse • weak entity • Relationship – An association between the instances of one or more entity types that is of interest to the organization – Association indicates that an event has occurred or that there is a natural link between entity types – Relationships are always labeled with verb phrases 10. 18
Conceptual Data Modeling • Goal – Capture as much of the meaning of the data as possible • Result – 10. 19 A better design that is easier to maintain
Degree of Relationship • Degree – Number of entity types that participate in a relationship • Three cases – Unary • A relationship between two instances of one entity type – Binary • A relationship between the instances of two entity types – Ternary • A simultaneous relationship among the instances of three entity types • Not the same as three binary relationships 10. 20
Figure 10 -6 Example relationships of different degrees 10. 21
Cardinality • The number of instances of entity B that can be associated with each instance of entity A • Minimum Cardinality – The minimum number of instances of entity B that may be associated with each instance of entity A • Maximum Cardinality – The maximum number of instances of entity B that may be associated with each instance of entity A 10. 22
ERD Sample
Entity • All systems contain data • Data describes things • A thing that can be uniquely identified -- a noun – person – object (e. g. , machine, tool, equipment, document) – concept • An entity is a class of persons, place, objects, events or concepts about which we need to capture and store data • An entity instance - is a single occurrence of an entity
Entity Type
Entity Instance
Entity Symbol What are some groupings of data? What are some entity instance?
Entity Rules • Some Rules of Thumb · Each entity is going to end up being represented by at least one table. Therefore, something which does not involve at least two data elements to describe it is probably not an entity. · Entities will become data stores on the Data Flow Diagram. · If each data store does not represent at least one entity, it may not be necessary to the system. · If you cannot imagine the entity you propose as being the name of a data store on a system DFD, it is probably not worth defining as one.
Entity Review • Review – they are primary things about which an organization records data – they have unique names that are nouns – they have primary keys that are unique – they have attributes – they have at least one relationship – they can be fundamental or attributive entities.
ERD Concepts - Attributes • The piece of data that we want to store about each element within a given entity • An attribute is a descriptive property or character of an entity • A compound attribute is one that actually consist of more primitive attributes – Name ==> Last, First, middle
Entity Attributes Last_name Street City Persons State First_name Zip
Compound Attributes Last_name Persons First_name Address
Properties Attributes • The value of each attribute are defined in terms of three properties: type, domain and default – Type - the class of data – Domain - potential values – Default - what is recorded if nothing is specified
Keys • Primary • Alternate • Foreign
Properties Attributes • Identification - an entity has many occurrences, could run into the millions, there is a need to uniquely identify each instance based on the data value of one or more attributes • Every entity must have an identifier or key which assumes an unique value - primary • Sometimes you will have more than one key concatenated keys • Any field that is not a primary key is a candidate for alternate/foreign keys
Entity Keys • Primary Key – unique – never changes – never is null – sometimes is compound • Alternate Key – for searching – sometimes compound
Foreign Key • Use Foreign key as pointer to establish this relationship.
Guidelines for Naming Attributes • Compound names – name should reflect the meaning of the entity and attribute – name must be unique to the whole context – good to make the name hierarchical (almost like an object environment. ) consider using the entity name, then underscore, then attribute name when needed for clarity Salesmen Customers Salesman_Name_First Salesman_Name_Last Customer_Name_First Customer_Name_Last
Guidelines for Naming Attributes • Abbreviations – allow for more descriptive names • Blanks – avoid blanks as many languages do not permit them in variable names
Attribute Types and Width • Defines physical structure of the attribute – – – – Character Numeric Money Date BLOB Phone number Zipcode • Width defines the size of the type – Zipcode might have width of 9
Guidelines for Naming Attributes • Consistency – Best to use the same name in ERD, DFD, database, actual code • Length – Depends upon limits of the tools in use. Don’t violate the limit of a tool if you are in a separate stage of SDLC if you can help it • Capitalization – Use unless implementation language discourages it. It is clearer to read
ERD Concepts Relationships • Entities and attributes do not exist in isolation • A relationship is a natural business association that exist between one or more entities. • A connecting line between two entities represents a relationship • A verb phase describes the relationship – Directional – Event – Something happens – Linkage
Entity Relationship Diagrams
ERD Concepts - Relationships
Is related to Relationship
Relationships Student SSN Name Last First Middle Address Town State Sex Disability Birth date Overall GPA has taken Class SSN Course No. Time YR/QTR Grade Credit
Relationship Degree • The degree of a relationship is the number of entities that participate in the relationship • The number of entities involved – Unary - relate back to itself • This is called a recursive relationship (sometimes called a unary relationship; degree = 1). – Binary- two entity – Ternary - relationship exist between more than two entities
Unuary Relationship Organization Hierarchy SSN Name Report to 123 Joe Smith 456 245 Kraft Cheese 456 Top Dog Emp Hierarchy SSN Name Report to
Binary Relationships Student SSN Name Last First Middle Address Town State Sex Disability Birth date Overall GPA has taken Class SSN Course No. Time YR/QTR Grade Credit
Ternary Relationships 8 Relationships can also exist between more than two different entities. – These are sometimes called N-ary relationships. – A relationship existing among three entities is called a 3 -ary or ternary relationship. – An N-ary relationship maybe associated with an associative entity. – An associative entity is an entity that inherits primary key from more than one other entity (parents). Each part of that concatenated key points to one and only one instance of each of the connecting entities.
Ternary Relationships Teacher SSN Name Last First Middle Address Town State Sex Disability Birth date meets in is assign Classroom SSN Course. No. Facility Room Night Class Course No. Time YR/QTR Grade Credit
Ternary Relationships
ERD Cardinality • The minimum and maximum number of occurrences of one entity for a single instance – zero – one – many – specific number – 1: 1, 1: M, M: N
ERD Relationships Unary Person Employee is married to Manages 1 to 1 1 to many
ERD Relationships Binary Employee Product Line Student is assigned Parking Place contains Product Registers for Course 1 to 1 1 to many
ERD Relationships Symbols Mandatory 1 Cardinality n 1 to Many Cardinality n is a number for upper limit -- if one exits Optional 0 or 1 n Optional 0 to Many Cardinality (0, 1, 2…)
ERD Cardinality Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4 ed by J. L. Whitten & L. D. Bentley
Relationships
Relationships A is related to one and only one B A is related to zero or one B A is related to one or more B A is related to zero, one or more B A is related to more than one B A B A B A B
Relationships Customer Places Is-Placed-by Order Claims Employee is-claimed-by Dependent Teaches Instructor is-taught-by Class
Problem
Naming and Defining Relationships • Relationship name is a verb phrase • Avoid vague names • Guidelines for defining relationships – Definition explains what action is being taken and why it is important – Give examples to clarify the action – Optional participation should be explained – Explain reasons for any explicit maximum cardinality 10. 62
Naming and Defining Relationships • Guidelines for defining relationships – Explain any restrictions on participation in the relationship – Explain extent of the history that is kept in the relationship – Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance 10. 63
Associative Entity • An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances 10. 64
Domains • The set of all data types and ranges of values that an attribute can assume • Several advantages – – Ensure that various data manipulation operations are logical – 10. 65 Verify that the values for an attribute are valid Help conserve effort in describing attribute characteristics
Triggering Operations • An assertion or rule that governs the validity of data manipulation operations such as insert, update and delete • Includes the following components: – User rule • Statement of the business rule to be enforced by the trigger – Event • Data manipulation operation that initiates the operation – Entity Name • Name of entity being accessed or modified – Condition • Condition that causes the operation to be triggered – Action • Action taken when the operation is triggered 10. 66
Triggering Operations • Responsibility for data integrity lies within scope of database management system, not individual applications 10. 67
The Role of CASE in Conceptual Data • CASE tools provide two important functions: – Maintain E-R diagrams as a visual depiction of structured data requirements – Link objects on E-R diagrams to corresponding descriptions in a repository 10. 68
Summary • Process of conceptual data modeling – Deliverables – Gathering information • Entity-Relationship Modeling – Entities – Attributes – Candidate keys and identifiers – Multivalued attributes • Degree of relationship 10. 69
Summary • Cardinality • Naming and defining relationships • Associative entities • Domains • Triggering Operations • Role of CASE 10. 70
How do you build an ERD for your project? Here is a cookbook approach
How to Construct a Data Model • Identify data entities • What are the entities of interest around which data must be stored? • “Model the world” be more rather than less comprehensive • Pay attention to key words • True entities have many instances dozens, hundreds or more! • Entities should be named with a singular noun when possible • Define each entity in business terms – Sometimes the start of a business glossary – Show slide 43
How to Construct a Data Model • Data entry forms (paper and screen) • Reports (paper and screen) • Existing Databases • DFDs (if completed. Each data flow must be an attribute of some entity. Data stores may be associated with entities. ) • Interviews
How to Construct a Data Model • Derive a high level, first cut data model • Sometimes referred to as a context data model • What are the techniques? • look at forms, look at existing database, do interviews, do a JAD-like session • Define relationships between entities, form simple business sentences
Data Model
How to Construct a Data Model • Identify likely attributes of those entities • • What are the keys? (Primary, Alternate, Foreign) How should you name them? Determine what type each is Determine constraints (cardinalities) of attributes • Determine relationships among entities • How are they related? Optional or mandatory? • Fundamental, attributive, and associative entities • What are the cardinalities of the relationships? • Identify remaining attributes
How to Construct a Data Model • Other key questions to ask – What people, places, and things are used in the business? How many of each are there? How do you differentiate them? Entities and attributes – What unique characteristics distinguish one object from another? Attributes and primary key – What characteristics describe each object? Attributes and secondary keys
How to Construct a Data Model • How do you use the data? What is the source of the data? Who controls it? • Over what time periods are you interested in this data? If it changes over time, do you need to know that? Cardinality and time issues • Are all instances of each object the same? Supertypes and subtypes • What kinds of transactions do you keep track of? Relationships • Are transactions always handled the same way, or are there sometimes exceptions? Can only some of the attributes of an object change? Cardinality • Can the associations or relationships among objects change over time?
Class Problem • Given the following data attributes and entities, indicate which attributes could be identifiers for each of the entities. You may have to combine attributes or even add some attributes that are not listed. Map all of the attributes to their appropriate entity. Remember, each attribute should describe one and only one entity. Draw a rough draft entity relationship diagram.
Class Problem Green Acres Real Estate System Entities: Seller House Closing Buyer Offer Showing Listing Property Room Seller name Square foot size Seller address House style Closing location Listing price Number of bathrooms Garage size Showing date Garage location Buyer name Basement size House heating method Offer amount Listing date Property description Offer date Room type Property size Showing time Room size Elementary school zone Buyer phone number Attributes: Sales terms Closing date
Answers
Answers