Systems analysis and design methods 7th whitten and benley chapter 05

Data Modeling Introduction  The presentation will address the following questions:        What is systems modeling and what is the difference between logical and physical system models? What is data modeling and what are its benefits? Can you recognize and understand the basic concepts and constructs of a data model? Can you read and interpret a entity relationship data model? When in a project are data models constructed and where are they stored? Can you discover entities and relationships? Can you construct an entity-relationship context diagram? Data Modeling Introduction  The presentation will address the following questions:   Can you discover or invent keys for entities? Can you construct a fully attributed entity relationship diagram and describe all data structures and attributes to the repository or encyclopedia? Data Modeling An Introduction to Systems Modeling  Systems Modeling    One way to structure unstructured problems is to draw models  A model is a representation of reality Just as a picture is worth a thousand words, most system models are pictorial representations of reality Models can be built for existing systems as a way to better understand those systems, or for proposed systems as a way to document business requirements or technical designs What are Logical Models?  Logical models show what a system ‘is’ or ‘does’ They are implementation-independent; that is, they depict the system independent of any technical implementation As such, logical models illustrate the essence of the system Data Modeling An Introduction to Systems Modeling  Systems Modeling   What are Physical Models?  Physical models show not only what a system ‘is’ or ‘does’, but also how the system is physically and technically implemented They are implementation-dependent because they reflect technology choices, and the limitations of those technology choices Systems analysts use logical system models to depict business requirements, and physical system models to depict technical designs Data Modeling An Introduction to Systems Modeling  Systems Modeling  Systems analysis activities tend to focus on the logical system models for the following reasons:  Logical models remove biases that are the result of the way the current system is implemented or the way that any one person thinks the system might be implemented  Logical models reduce the risk of missing business requirements because we are too preoccupied with technical details  Logical models allow us to communicate with end-users in non-technical or less technical languages Data Modeling An Introduction to Systems Modeling  Systems Modeling    Data modeling is a technique for defining business requirements for a database  Data modeling is a technique for organizing and documenting a system’s DATA Data modeling is sometimes called database modeling because a data model is usually implemented as a database It is sometimes called information modeling Many experts consider data modeling to be the most important of the modeling techniques Why is data modeling considered crucial?  Data is viewed as a resource to be shared by as many processes as possible As a result, data must be organized in a way that is flexible and adaptable to unanticipated business requirements – and that is the purpose of data modeling Data Modeling An Introduction to Systems Modeling  Systems Modeling  Why is data modeling considered crucial? (continued)  Data structures and properties are reasonably permanent – certainly a great deal more stable than the processes that use the data Often the data model of a current system is nearly identical to that of the desired system  Data models are much smaller than process and object models and can be constructed more rapidly  The process of constructing data models helps analysts and users quickly reach consensus on business terminology and rules Data Modeling CUSTOMER Customer Number (PK) Customer Name Shipping Address Billing Address Balance Due ORDER has placed Order Number (PK) Order Date Order Total Cost Customer Number (FK) sold ORDERED PRODUCT INVENTORY PRODUCT Product Number (PK) Product Name Product Unit of Measure Product Unit Price sold as Ordered Product ID (PK) Order Number (FK) Product Number (FK) Quantity Ordered Unit Price at Time of Order Data Modeling System Concepts for Data Modeling  System Concepts   Most systems analysis techniques are strongly rooted in systems thinking  Systems thinking is the application of formal systems theory and concepts to systems problem solving There are several notations for data modeling, but the actual model is frequently called an entity relationship diagram (ERD)  An ERD depicts data in terms of the entities and relationships described by the data Data Modeling System Concepts for Data Modeling  Entities  STUDENT An entity   All systems contain data Data describes ‘things’ A concept to abstractly represent all instances of a group of similar ‘things’ is called an entity  An entity is something about which we want to store data Synonyms include entity type and entity class  An entity is a class of persons, places, objects, events, or concepts about which we need to capture and store data  An entity instance is a single occurrence of an entity 10 Data Modeling How to Construct Data Models  3rd Step - The Key-Based Data Model  The following guidelines are suggested for keys: (continued)  Consider inventing a surrogate key instead to substitute for large concatenated keys of independent entities • This suggestion is not practical for associative entities since because each part of the concatenated key is a foreign key that must precisely match its parent entity’s primary key  If you cannot define keys for an entity, it may be that the entity doesn’t really exist—that is, multiple occurrences of the so-called entity not exist 54 Data Modeling How to Construct Data Models  3rd Step - The Key-Based Data Model  Business Codes  There are several types of codes and they can be combined to form effective means for entity instance identification • Serial codes assign sequentially generated numbers to entity instances – Many database management systems can generate and constrain serial codes to a business’ requirements • Block codes are similar to serial codes except that serial numbers are divided into groups that have some business meaning • Alphabetic codes use finite combinations of letters (and possibly numbers) to describe entity instances – Alphabetic codes must usually be combined with serial or block codes in order to uniquely identify instances of most entities 55 Data Modeling How to Construct Data Models  3rd Step - The Key-Based Data Model  Business Codes  There are several types of codes and they can be combined to form effective means for entity instance identification (continued) • In significant position codes, each digit or group of digits describes a measurable or identifiable characteristic of the entity instance – Significant digit codes are frequently used to code inventory items • Hierarchical codes provide a top-down interpretation for an entity instance – Every item coded is factored into groups, subgroups, and so forth 56 Data Modeling How to Construct Data Models  3rd Step - The Key-Based Data Model  Business Codes  The following guidelines are suggested when creating a business coding scheme: • Codes should be expandable to accommodate growth • The full code must result in a unique value for each entity instance • Codes should be large enough to describe the distinguishing characteristics, but small enough to be interpreted by people without a computer • Codes should be convenient A new instance should be easy to create 57 Data Modeling responds t o sells PRODUCT ON ORDER Key Data Order-Number [PK1] [FK] Member-Number [PK2] [FK] Product-Number [PK3] [FK] Universal-Product-Code [PK4] [FK] MEMBER ORDER Key Data Order-Number [PK1] Member-Number [PK2] [FK] places MEMBER Key Data Member-Number [PK1] enrolls in CLUB MEMBERSHIP Key Data Member-Number [PK2] [FK] Club-Name [PK3] [FK] generat es binds AGREEMENT Key Data Club-Name [PK2] [FK] Agreement -Number [PK1] sold as PRODUCT Key Data Prod uct -Number [PK1] Universal-Product -Cod e [PK2] is feat ured in sponsors PROMOT ION Key Data Prod uct -Number [PK2] [FK] Club-Name [PK1] [FK] Universal-Product -Code [PK3] [FK] sponsors 58 CLUB Key Data Club-Name [PK1] est ablishes Data Modeling How to Construct Data Models  4th Step - Generalized Hierarchies  At this time, it would be useful to identify any generalization hierarchies in a business problem 59 Data Modeling responds to sells PRODUCT ON AN ORDER Key Data Order-Number [PK1] [FK] Product-Number [PK2] [FK] Universal-Product-Code [PK3] [FK] MEMBER ORDER Key Data Order-Number [PK1] MEMBER Key Data Member-Number [PK1] placed CLUB MEMBERSHIP Key Data Club-Name [PK1] [FK] Member-Number [PK2] [FK] Agreement-Number [PK3] [FK] enrolls in generates sold as binds PRODUCT Key Data Product-Number [PK1] Universal-Product-Code [PK2] sponsors is a AGREEMENT Key Data Club-Name [PK2] [FK] Agreement-Number [PK1] MERCHANDISE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] PROMOTION Key Data Club-Name [PK1] [FK] generates is a AUDIO TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] VIDEO TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] GAME TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] 60 sponsors establishes CLUB Key Data Club-Name [PK1] Data Modeling How to Construct Data Models  5th Step - The Fully Attributed Data Model  The fifth task is to identify the remaining data attributes  The following guidelines are offered for attribution • Many organizations have naming standards and approved abbreviations – The data or repository administrator usually maintains such standards • Many attributes share common base names such as NAME, ADDRESS, DATE – Unless the attributes can be generalized into a supertype, it is best to give each variation a unique name such as: CUSTOMER NAME vs SUPPLIER NAME – Names must be distinguishable across projects • Logical attribute names should not be abbreviated 61 Data Modeling How to Construct Data Models  5th Step - The Fully Attributed Data Model  The following guidelines are offered for attribution (continued) • For attributes that have only YES or NO values, name as questions – For example, CANDIDATE FOR A DEGREE? • Each attribute should be mapped to only one entity – Foreign keys are the exception – they identify associated instances of related entities • An attribute’s domain should not be based on logic 62 Data Modeling PRODUCT ON AN ORDER Key Data Order-Number [PK1] [FK] Product-Number [PK2] [FK] Universal-Product-Code [PK3] [FK] Non-Key Data Quantity-Ordered Quantity-Shipped Quantity-Backordered Purchase-Unit-Price Credits-Earned sells sold as PRODUCT Key Data Product-Number [PK1] Universal-Product-Code [PK2] Non-Key Data Product-Quantity-in-Stock Product-Type Manf-Suggested-Price Club-Default-Price Special-Price Units-Sold-Month-to-Date Units-Sold-Year-to-Date Units-Sold-Lifetime MEMBER ORDER Key Data Order-Number [PK1] Non-Key Data Order-Creation-Date Order-Fill-Date Shipping-Address-Name Shipping-Street-Address Shipping-City Shipping-State Shipping-Zip Shipping-Instructions Order-Sub-Total Order-Sales-Tax Order-Shipping-Method Order-Shipping-&-Handling-Cost Order-Status Order-Prepaid-Amount Order-Prepayment-Method Member-Number [FK] Club-Name [FK] Promotion-Number responds to placed generates MEMBER Key Data Member-Number [PK1] Non-Key Data Member-Name Last-Name First-Name Middle-Initial Member-Status Member-Street-Address Member-Post-Office-Box Member-City Member-State Member-Zip-Code Member-Daytime-Phone-Number Area-Code Phone-Number Extension () Member-Date-of-Last-Order Member-Balance Member-Credit-Card-Type Member-Credit-Card-Number Member-Credit-Card-Expire-Date Member-Bonus-Balance enrolls in binds sponsors AGREEMENT Key Data Club-Name [PK2] [FK] Agreement-Number [PK1] Non-Key Data Agreement-Active-Date Agreement-Expire-Date Fulfillment-Period establishes Required-Number-of-Credits is a MERCHANDISE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] Non-Key Data Merchandise-Name Merchandise-Description Merchadise-Type Unit-of-Measure TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] Non-Key Data Title-of-Work Title-Cover Catalog-Description Copyright-Date Entertainment-Category Credit-Value PROMOTION Key Data Club-Name [PK1] [FK] Non-Key Data Promotion-Number Promotion-Release-Date Promotion-Status Promotion-Type Automatic-Fill-Delay Product-Number [FK] Universal-Product-Code [FK] generates is a AUDIO TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] Non-Key Data Artist Audio-Category Audio-Sub-Category Number-of-Units-in-Package Audio-Media-Code Content-Advisory-Code CLUB MEMBERSHIP Key Data Club-Name [PK1] [FK] Member-Number [PK2] [FK] Agreement-Number [PK3] [FK] Non-Key Data Date-Enrolled Expiration-Date Number-of-Credits-Required Number-of-Credits-Earned VIDEO TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] Non-Key Data Producer Director Video-Category Video-Sub-Category Closed-Captioned Language Running-Time Video-Media-Type Video-Encoding Screen-Aspect MPA-Rating-Code GAME TITLE Key Data Product-Number [PK1] [FK] Universal-Product-Code [PK2] [FK] Non-Key Data Manufacturer Game-Category Game-Sub-Category Game-Platform Game-Media-Type Number-of-Players Parent-Advisory-Code 63 sponsors CLUB Key Data Club-Name [PK1] Non-Key Data Club-Description Club-Charter-Date Data Modeling How to Construct Data Models  6th Step - The Fully Described Model  The last task is to fully describe the data model  This task is the most time consuming  This task can be started in parallel with the key-based model or fully attributed model, but it is usually the last data modeling task completed  At this time the descriptions for the attributes are still incomplete – they require domains • Most CASE tools provide extensive facilities for describing the data types, domains, and defaults for all attributes to the repository 64 Data Modeling How to Construct Data Models  6th Step - The Fully Described Model  Additional descriptive properties may be recorded for attributes such as: • Who should be able to create, delete, update, and access each attribute? • How long should each attribute (or entity) be kept before the data is deleted or archived? 65 Data Modeling The Next Generation  Data modeling should remain a value-added skill for many years  The demand for data modeling as a skill is dependent on two factors:  (1) the need for databases, and  (2) the use of relational database management system technology to implement those databases • There is some belief that relational database technology will eventually be replaced by object technology • If that were to happen, data modeling would be replaced by object modeling techniques • Even as object database technology becomes available, we expect the relational database industry to add object features and technologies to their product lines 66 Data Modeling The Next Generation  CASE technology will continue to improve   Today’s better CASE tools provide a two-way synchronization between the logical data models and their database designs This synchronization will likely extend as CASE vendors enable their tools to directly communicate and interoperate with database management systems and working databases 67 Data Modeling Summary       Introduction An Introduction to Systems Modeling System Concepts for Data Modeling The Process of Logical Data Modeling How to Construct Data Models The Next Generation 68 ... System Concepts   Most systems analysis techniques are strongly rooted in systems thinking  Systems thinking is the application of formal systems theory and concepts to systems problem solving... worth a thousand words, most system models are pictorial representations of reality Models can be built for existing systems as a way to better understand those systems, or for proposed systems as... technology choices, and the limitations of those technology choices Systems analysts use logical system models to depict business requirements, and physical system models to depict technical designs Data