Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Objectives of Chap 7 – Data Modeling Learn more about logical and physical modeling Address data modeling and all that it involves Be able to create – read and understand Entity- Relationship models (entities and relations…) Explain when data models are constructed and where the models are stored. Build an entity relationship context diagram Learn about key for entities and key-based diagrams Build a fully-attributed entity relationship diagram and describe all the data structures and attributes to the repository or encyclopedia. Be able to normalize your logical model.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Purpose of Modeling: Give structure to unstructured problems… Models – Logical and Physical Logical Models – ‘the whats’ of a system –implementation independent –independent of any technology –sometimes called ‘essential model’ Great for separating business matters from technical constraints. Allow us to communicate with users using the language of their business. Physical Models – the ‘hows’ of a system – how the system is implemented. –clearly implementation dependent –sometimes called implementation model or technical model Great for describing an existing system Ultimately, physical models must be done to reflect implementation…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling 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 eventually implemented as a database. The actual model is frequently called an entity relationship diagram (ERD) because it depicts data in terms of the entities and relationships described by the data.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Sample Entity Relationship Diagram (ERD) Sample ERD … with entities and attributes Example also shows relationships and dependencies… This is just a sample. There are many variations of the symbols. But the meaning is the same…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition So, what does this sample model tell us??? Look at p. 259) We have four main entities (customers, orders, inventory products, and ordered products. Keys: –The value of the customer number (note: primary key) uniquely defines a specific customer; –Value of Order Number uniquely defines a specific order; likewise, the product number uniquely defines a specific product in the inventory. (both primary keys w/I their entities) Each entity has specific ‘attributes’ that are logically ‘part’ of every entity “instance.” Relationships: –A customer has placed zero or more ‘orders.’ Similarly, a specific order can only be placed by a specific customer. (Note the ‘foreign key’ in Order…) –Notice that the order points back to a single, specific Customer.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition So, what does this sample model tell us??? Look at p. 259) Continuing… –For an ‘order’ to make sense, there must be at least ‘one or more’ ordered product on the order…. (similarly, if there is an ‘ordered product’ the ordered product must have come from an order! –So, each instance of an Ordered Product has the number of the product we ordered and the unit price of that item. (two attributes in entity) –Can have many Inventory Products and no Ordered Products –….and more to come….

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition  Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier.  Places: sales region, building, room, branch office, campus.  Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle.  Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip.  Concepts: account, block of time, bond, course, fund, qualification, stock.  Recall: Level 0 DFD had ‘external entities’ – ones that interface with the Application Name of Entity Data Modeling Concepts: Entity An entity is a class of persons, places, objects, events, or concepts about which we need to capture and store data. Can view this as a ‘noun.’ Entities are ‘abstractions’ An entity is something about which a business needs to store data. Sometimes called an ‘entity class’ or ‘entity type.’ An entity is a class of things…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition  Betty Arnold  John Taylor  Lisa Simmons  Bill Macy  Heather Leath  Tim Wrench Data Modeling Concepts: Entity An entity instance is a single occurrence of an entity. Example: instances of the entity STUDENT may include

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Attributes An attribute is a descriptive property or characteristic of an entity. Synonyms include element, property, and field. A compound attribute is one that actually consists of other attributes

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Domains The data type for an attribute defines what type of data can be stored in that attribute. Examples: numbers, text, data, time, yes/no, value set, image, …. The domain of an attribute defines what values an attribute can legitimately take on. Think ‘Range…” The default value for an attribute is the value that will be recorded if not specified by the user. Think: A signal can have a domain of {red, yellow, green} So attributes have data type, domain and default values.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Identification of Entity Instances A key is an attribute, or a group of attributes, that assumes a unique value for each entity instance. If more than one attribute is needed to uniquely identify an entity instance, the key is called a concatenated key. (or composite key or compound key) Think: book title, copy number in a library….. A candidate key is a “candidate to become the primary key” of instances of an entity. A primary key is that candidate key that will most commonly be used to uniquely identify a single entity instance. Any candidate key that is not selected to become the primary key is called an alternate key. Consider your account at Sears: Could have your person instance with ssan as primary key and account number as an alternate key. May also have your phone number as another alternate key.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Identification Keys & Subsetting Criteria A subsetting criteria is an attribute (or concatenated attribute) whose finite values divide all entity instances into useful subsets.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Relationships Instances of entities ‘interact’…Hence, we discuss’the notion of ‘relationships.’ A relationship is a natural business association that exists between one or more entities. The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities. Here, we say a student ‘is enrolled in’ one or more curriculum; Or, a Curriculum ‘is being studied by’ zero or more students… Notice relationships are bidirectional! Facts of the business…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition bidirectional Data Modeling Concepts: Cardinality Cardinality defines the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity. Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship. Relationships also show ‘degree’ or ‘Cardinality’…. Must there exist an instance of Student for each instance of Curriculum? No. Must there exist an instance of Curriculum for each instance of Student? Yes How many instances of Curriculum can exist for each instance of Student? Many How many instances of Student can exist for each instance of Curriculum? Many.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Degree The degree of a relationship is the number of entities that participate in the relationship. Typical cardinalities are exactly one (one and only one) zero or one one or more zero or more more than one

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Cardinality and Links (Quoting from page 264-265.) Cardinality decisions dramatically affect building our database. ‘When we insert a Student instance in the database, we must link (associate) that Student to at least one Curriculum. Similarly, a Student can study more than one Curriculum, and we must be able to store data that indicates all Curricula for a given Student. We must insert a Curriculum before we can link (associate) Students to that Curriculum. That is why Curriculum can have zero students – students have not yet been admitted to that Curriculum… Once Curriculum has been inserted into the database, we can link (associate) many Students with that Curriculum.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Degree The degree of a relationship is the number of entities that participate in the relationship. A recursive relationship is a relationship that exists between different instances of the same entity This course is a prerequisite for zero or more courses; Or, This course has zero or more prerequisites.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Degree Relationships may exist between more than two entities and are called N- ary relationships. The example ERD depicts a ternary relationship.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Degree An associative entity is an entity that inherits its primary key from more than one other entity (called parents). Each part of that concatenated key points to one and only one instance of each of the connecting entities. The key of Assignment entities uniquely identify an employee-id, project number, and a location number. Clearly, the key is a composite key. Can have, also, its own attributes (begin date ….)

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Foreign Keys A foreign key is a primary key of one entity that is “contributed to” (duplicated in) another entity to identify instances of a relationship. The foreign key is the primary key for another entity instance. The CIS department offers curricula in computer science, information science, and information systems One or more curriculum Is offered by by one and only one dept. But dept can offer many curriculum. Many instances of curriculum will point back to a single dept.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Foreign Keys Nonidentifying relationships are those in which each of the participating entities has its own independent primary key. In other words, none of the primary key attributes is shared. Identifying relationships are those in which the parent entity contributes its primary key to become part of the primary key of the child entity. The difference here (with the foreign key) is that it is part of the primary key of the ‘entity.’ In a weak entity, its existence depends on the strong entity, BUILDING Notice further that there are no ‘zero’ cardinalities…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Weak Entities Data Modeling Concepts: Foreign Keys Dashed line - Used to distinguish a nonidentifying relationship. The solid line: an identifying relation. Cardinality  must have the flight entity to have a seat… Symbol: rounded rectangle within a rounded rectangle Significant: while non-identifying relationships don’t share primary key as part of Weak Entity’s primary key, we still need a way to link these. Enter: foreign key. Weak entity depends upon the strong entity for its existence.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition A nonspecific relationship (or many- to-many relationship) is one in which many instances of one entity are associated with many instances of another entity. Who is the parent?? Child?? Nonspecific relationships must be resolved. Most nonspecific relationships can be resolved by introducing an associative entity. Associative Entities Many to Many relationships (with foreign keys…) Replace many-to-many with 0 or 1 to many relationships… Each entity becomes a parent…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Many to Many Relationships Many-to-Many (n:m) relationships can be very troublesome. Yet, when we model real-life situations, they arise. But in order to represent these in our database design, we need alternative representations. In previous overhead, you saw the introduction of an associative entity as an approach to eliminate n:m relationships. (Have two parents and a child…) The relationship between the child and parent is always one-to-one. Parent to child follows the business rules… This approach might not always work…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Resolving Nonspecific Relationships (continued) A new entity might arise naturally on closer examination…We note that Product and Customer are related only indirectly via an Order! See (b) Still have n:m here though… Can replace this with an Associative entity (see book)

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Resolving Nonspecific Relationships (continued) Still n:m A third way to assist in n:m relationships is to refine a relationship into to relationships neither of which is n:m.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling Concepts: Generalization Generalization:technique wherein the attributes that are common to several types of an entity are grouped into their own entity, called a supertype. An entity supertype is an entity whose instances store attributes that are common to one or more entity subtypes. An entity subtype is an entity whose instances inherit some common attributes from an entity supertype and then add other attributes that are unique to an instance of the subtype. Entity subtypes also inherit data types, domains, and defaults of those attributes from ‘above.’ They also inherit relationships. These are called is_a relationships.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Modeling during Systems Analysis Remember, to accommodate your data base design, you must have well-defined entities and their relationships… First – data models evolve and are ‘living’ – they change in response to changing business rules –Need to be accessible.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Why Data Modeling Before Process Modeling? 1. Data models help analysts to quickly identify business vocabulary more completely than process models. 2. Data models are almost always built more quickly than process models 3. A complete data model can fit on a single sheet of paper. Process models often require dozens of sheets of paper. 4. Process modelers frequently and too easily get hung up on unnecessary detail. 5. Data models for existing and proposed systems are far more similar that process models for existing and proposed systems. Consequently, there is less work to throw away as you move into later phases.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Models in Requirements Analysis Context Data Model –Only includes entities and relationships – no attributes –Don’t clutter the entities at this time with attributes that can be added later. –Need to get the basic relationships down using the Project Scope and Use Cases. –Intent: Refine our understanding of the Scope and not worry about the business rules. –At this time, many of the relations may also be nonspecific – (many to many) As you may recall, these relationships are often found in preliminary data models. But they need to be resolved.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Logical Data Model Steps: Context Data Model –Establishes (refines) Project Scope. Key-Based Data Model –Eliminates non-specific relationships and adds associative entities; includes primary and alternate keys. Also includes precise cardinalities. Fully-Attributed Data Model –Includes all other attributes and any subsetting criteria if any. –Each of these attributes are to be defined in the data dictionary and contain data type, domain, and any defaults. Normalized Data Model –Must be normalized to 3NF.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Case Tools Some nice words about Database design on pp. 276- 277 and the use of CASE tools. Please note the encouragement I am giving – and implied by the book…System Architect has all you will need for data modeling, design, and the repository (encyclopedia). Please take advantage of this tool! No more warnings…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition How to Construct Data Models Identify fundamental entities in the system that are or might be described by data. –Look for key words in Use Cases or Project Scope –Look for ‘nouns’ – names of persons, places, things, events, etc. Find these also in JRP sessions, system documentation, studying existing forms, screens, reports; Look at the corporation’s web page too. Some CASE tools can reverse engineer existing files and databases into physical data models, which can lead to entity identification. –Remember: a real entity should have many instances as your book points out: dozens, hundreds, thousands… If not, I the entity probably does not exist.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition How to Construct Data Models Give entities simple, business-oriented names. Remember: an entity is defined as something about which we want to keep track of or about which we want to store data…. Be careful of synonyms. Adjectives are oftentimes ‘attributes’ used later in the fully-attributed data model.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Context Data Model Now, build the Context Data Model Name the relationship (System Architect permits naming the relationship in both directions; others, merely parent to child.) –Hint: Load System Architect. On Menu Bar, select Help, Tutorial, Data Modeling, Logical Data Modeling, Creating a new ER Diagram…… Next slide is a context data model generated from System Architect. Let’s go through it to see what it communicates.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Context Data Model MEMBER ORDER MEMBER TRANSACTION PRODUCT AGREEMENTPROMOTION responds to places binds is a has conducted generates features sells 1. An agreement binds one or more members. Relationship here is between parent and child. Reverse is implied. 2.A member has conducted zero or more transactions. 3.A Member Order “is a” Transaction. In fact, a given Member Order may correspond to many Transactions. 4. A Promotion features one or more products. Implicitly, a product is featured in zero or more promotions. 5.A Promotion generates many Member Orders. Implicitly, a Member Order is generated for 0 or 1 promotions

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Context Data Model MEMBER ORDER MEMBER TRANSACTION PRODUCT AGREEMENTPROMOTION responds to places binds is a has conducted generates features sells 6. A Member responds to 0 or more Member Order A Member places 0 or 1 Member Orders. 6’ The member responding supports the promotion- generated orders. The Second relation supports member- Initiated orders. It is possible for more than one relationship to exist between the same two entities if the separate relationships communicate different business events or associations. 7.A Member Order sells one or more products - and conversely.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Key-Based Model So, we have the context data model….Now, keys. Some principles about keys… –Should not change over the lifetime of an entity –Cannot be null –When populated, attribute must be controlled for valid values (domain; database controls will validate…) –Avoid intelligent keys – keys are codes that can communicate data about the entity you are identifying. Some experts feel that this data can change; hence violation of the first principle above…Your authors disagree. –In practice, codes representing entities are used very often!!! There are lots of codes – see text, page 182 –If used, be careful. Guidelines on page 282… Let’s look at a key-based data model…

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Key-based Data Model 1.Many entities have a simple, single-attribute primary key. 2.We introduce an associate entity to resolve the nonspecific relation between Member Order and Product 1.Many entities have a simple, single-attribute primary key. 1.Many entities have a simple, single-attribute primary key. Each associative entity instance represents one product on one member order. The parent entities contributed their own primary keys to comprise the associative entity’s concatenated key. N.B. System Architect places a PK1 or PK2… Each of these is a FK too Warning: If you cannot define keys for an entity, it may be that the entity doesn’t exist – that is, multiple occurrences of the so-called entity do not exist.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Key-based Data Model With Generalization AUDIO TITLE Primary Key Product-Number [PK1] [FK] VIDEO TITLE Primary Key Product-Number [PK1] [FK] GAME TITLE Primary Key Product-Number [PK1] [FK] TITLE Primary Key Product-Number [PK1] [FK] MERCHANDISE Primary Key Product-Number [PK1] [FK] TRANSACTION Primary Key Transaction-Reference-Number [PK1] MEMBER ORDERED PRODUCT Primary Key Order-Number [PK1] [FK] Product-Number [PK2] [FK] PROMOTION TITLE Primary Key Promotion-Number [PK1] [FK] Product-Number [PK2] [FK] MEMBER ORDER Primary Key Order-Number [PK1] MEMBER Primary Key Member-Number [PK1] PRODUCT Primary Key Product-Number [PK1] AGREEMENT Primary Key Agreement-Number [PK1] PROMOTION Primary Key Promotion-Number [PK1] is featured as features sold as sells places binds is a has conducted responds to is a generates

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Fully-Attributed Data Model Here is where we must FULLY understand all the data attributes of the system. Scrutinize attributes carefully. Guidance: –Use standard naming conventions. (Data elements and codes…) All organizations have these. –Choose attribute names carefully. Give each variation a unique name, as in Order Date, Invoice Date, Flight Date, … Often these common names are used across the organization. –“Physical attribute names on existing forms and reports are frequently abbreviated to save space.” –“Logical names must be clearer.” e.g. QTY on report; Quantity Ordered on logical elements. –Some attributes take on simple values: yes/no; true/false. –Be careful of attribute domains. These domains need to be carefully articulated and differentiated (video media; audio media…)

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition The Fully-Attributed Data Model Not sufficient to add attributes here. The data types, domains, and defaults must all be captured and stored in our repository. Each attribute must be defined.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Analyzing the Data Model: Data Analysis & Normalization Here, we look at good database design – the quality of the data model. Qualities: 1.A good data model is simple. 1.Attributes describe only that entity. 2.May need a ‘pointer’ to another entity but not that data… 3.Each attribute of an instance can have only one value. 2.Redundancy 1.Each data item (except other foreign keys) describes at most a single entity. 2.Be careful of synonyms – same attribute with different names.. 3.Model should be flexible and adaptable to future needs. 1.Make these application-independent so that the database structures can be extended or modified easily. We do all this through data analysis

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Data Analysis and Normalization Data analysis is a process that prepares a data model for implementation as a simple, non-redundant, flexible, and adaptable database. The specific technique is called Normalization. Normalization is a data analysis technique that organizes data attributes such that they are grouped to form non-redundant, stable, flexible, and adaptive entities. Three steps to creating a normalized data base.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Normalization: 1NF, 2NF, 3NF An entity is in first normal form (1NF) if there are no attributes that can have more than one value for a single instance of the entity. Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. (single-valued; repeating groups.) An entity is in second normal form (2NF) if it is already in 1NF and if the values of all non-primary key attributes are dependent on the full primary key—not just part of it. Any non-key attributes that are dependent on only part of the primary key should be moved to any entity where that partial key is actually the full key. This may require creating a new entity and relationship on the model. (functional dependency on primary key) An entity is in third normal form (3NF) if it is already in 2NF and if the values of its non-primary key attributes are not dependent on any other non-primary key attributes. Any non-key attributes that are dependent on other non-key attributes must be moved or deleted. Again, new entities and relationships may have to be added to the data model. (transitive dependencies and derived data)

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition First Normal Form There are several approaches and some are quite theoretical. We will take a pragmatic approach to Normalization. Step 1 – Place each entity in 1NF. –Look for repeating groups – remember, we are looking for attributes that are single-valued variables (attributes) –Look at two entities that are not in 1NF: Member Order and Promotion. Each contains a repeating group – something that can have multiple values for a single instantiation. In Member Order: Attributes: Ordered Product number, Ordered Product Description, Ordered Product Title, Quantity Ordered, Quantity Shipped, Quantity Backordered, Purchased Unit Price, and Extended Price will probably repeat for each item ordered!

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition First Normal Form Member Order (Un) Order-Number – PK Order-Creation Date Order-Fill-Date Member Number (FK) Member Number 2 (FK) Member Name Member Address Shipping Address Shipping instructions Promotion-Number (FK) 1 {Ordered-Product-Number} N 0{Ordered Product Description}N 0{Ordered Product Title} N 1{Quantity-Ordered} N 1{Quantity-Shipped} N 1{Quantity-Backordered}N 1{Purchased-Unit-Price}N 1{Extended-Price}N Order-Sub-total-cost Order-Sales-Tax Ship-Via-Method Shipping-Charge Order Status Prepaid-Amount Prepaid-Method Correction Member Order (1NF) Product (1NF) Member Ordered Product (1NF) Order-Number – PK Order-Creation Date Order-Fill-Date Member Number (FK) Member Number 2 (FK) Member Name Member Address Shipping Address Shipping instructions Promotion-Number (FK) Order-Sub-total-cost Order-Sales-Tax Ship-Via-Method Shipping-Charge Order Status Prepaid-Amount Prepaid-Method Product-Number (PK) Universal-Product-Code (Alt Key) Quantity-in-Stock Product-Type Suggested-Retail-Price Default-Unit-Price Current-Special-Unit-Price Current-Month-Units-Sold Current-Year-Units-Sold Total-Lifetime-Units-Sold Ordered-Number PK1 and FK Product-Number (PK2 and FK) Ordered Product Description Ordered Product Title Quantity-Ordered Quantity-Shipped Quantity-Backordered Purchased-Unit-Price Extended-Price In Member Order, we moved attributes (now in Member Ordered PRoduct) out, since these are clearly repeating groups. We created new entity, Member Order. Both Member Order and Member Ordered Product are now in 1NF….. (Promotion can also be similarly reconfigured to result in 1NF arrangement. (See Fig 7.18))

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Second Normal Form In Second Normal Form, we ensure that all elements are functionally-dependent upon the full primary key. Any entities whose entire array of attributes fully depend upon the entire entity key are already in 2NF. Examining our entities, we note that all entities except Member-Ordered Product entity with attributes Ordered Product Description and Ordered Product Title are in 2NF. These attributes are not fully dependent on the full primary key, Order Number and Product Number. They are really dependent only on Product Number. We must get rid of this partial dependency anomaly.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Second Normal Form Example Ordered-Product-Description and Ordered-Product-Title are moved from Member-Ordered-Product into an entity that has Product Number as its key. In our case, such an entity already exists: Product. But ‘Product’ is a ‘supertype.’ In looking at the subtypes, we see that these two attributes are already present (under different names) in Merchandise and Title. So, we merely eliminate the redundant attributes. The Promotion entity is similarly handled in the next overhead.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Second Normal Form Example Title-of-Work is eliminated from Title Promotion. But Title-of-Work already exists in the entity, Title, which has a product number as its primary key.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Third Normal Form Example Entities in 2NF can be inspected and Normalized to 3NF…. Look for two types of problems (to be removed): 1) derived data and 2) transitive dependencies. If data is derived, like in ‘computed’, then such a derived attribute might be dependent upon other non key attributes. This is a no-no. Derived Data. Clearly, below, attribute ‘Extended-Price’ is derived from quantity-ordered and purchased-unit-price. Simple change in this case. Eliminate this derived attribute. Generally-accepted rule, if the derived attribute is dependent on attributes in a single entity, eliminate it. If it depends on attributes from more that one entity, it may not be wise to eliminate it.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition Third Normal Form Example Transitive Dependencies : These exist whenever a non-key attribute is dependent upon another non-key attribute (other than by derivation) Failure to deal with this transitive dependency can cause us problems. Often, this indicates another entity should be defined. If a new entity is not established, we could end up with problems later when new requirements arise that might require us to implement such an entity not yet declared. Transitive analysis is performed only on those entities that do not have a concatenated key. Entities Product, Promotion, Agreement, and Transaction indicate that they are all in 3NF, as all non-key attributes re dependent only on the primary key. Member Order – Member Name and Member Address. Are these dependent upon the primary key, Order Number? No. These values are dependent on another non primary key in the entity, Member Number. What to do? Remember, we said that this problem => a missing entity! So, Need to move Member Name and Member Address into an entity whose key is merely Member Number. But we already have them in the Member entity, and Member Address is already in Member as Member Street Address.

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.

Similar presentations

Presentation on theme: "Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.

Similar presentations

Presentation on theme: "Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition."— Presentation transcript:

Similar presentations

About project

Feedback