SlideShare a Scribd company logo
Chapter 8



                     Data Modeling and
                          Analysis



McGraw-Hill/Irwin    Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Objectives
•   Define data modeling and explain its benefits.
•   Recognize and understand the basic concepts and constructs of
    a data model.
•   Read and interpret an entity relationship data model.
•   Explain when data models are constructed during a project and
    where the models are stored.
•   Discover entities and relationships.
•   Construct an entity-relationship context diagram.
•   Discover or invent keys for entities and construct a key-based
    diagram.
•   Construct a fully attributed entity relationship diagram and
    describe data structures and attributes to the repository.
•   Normalize a logical data model to remove impurities that can
    make a database unstable, inflexible, and nonscalable.
•   Describe a useful tool for mapping data requirements to business
    operating locations.
8-3
Data Modeling

      Data modeling – a technique for organizing
      and documenting a system’s data.
      Sometimes called database modeling.

      Entity relationship diagram (ERD) – a
      data model utilizing several notations to
      depict data in terms of the entities and
      relationships described by that data.
8-4
Sample Entity Relationship Diagram
      (ERD)




8-5
Data Modeling Concepts: Entity
      Entity – a class of persons, places, objects,
      events, or concepts about which we need to
      capture and store data.
        • Named by a singular noun
             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,
8-6           qualification, stock.
Data Modeling Concepts: Entity
      Entity instance – a single occurrence of an entity.

        entity
                          Student ID Last Name First Name
                          2144      Arnold     Betty
                          3122      Taylor     John
                          3843      Simmons    Lisa

      instances           9844      Macy       Bill
                          2837      Leath      Heather
                          2293      Wrench     Tim
8-7
Data Modeling Concepts:
      Attributes
      Attribute – a descriptive property or
      characteristic of an entity. Synonyms
      include element, property, and field.
         • Just as a physical student can have
           attributes, such as hair color, height,
           etc., data entity has data attributes


      Compound attribute – an attribute
      that consists of other attributes.
      Synonyms in different data modeling
      languages are numerous:
      concatenated attribute, composite
      attribute, and data structure.
8-8
Data Modeling Concepts: Data
     Type
        Data type – a property of an attribute that identifies what
        type of data can be stored in that attribute.
             Representative Logical Data Types for Attributes
Data Type    Logical Business Meaning
NUMBER       Any number, real or integer.
TEXT         A string of characters, inclusive of numbers. When numbers are included in a TEXT
             attribute, it means that we do not expect to perform arithmetic or comparisons with
             those numbers.
MEMO         Same as TEXT but of an indeterminate size. Some business systems require the
             ability to attach potentially lengthy notes to a give database record.
DATE         Any date in any format.
TIME         Any time in any format.
YES/NO       An attribute that can assume only one of these two values.
VALUE SET    A finite set of values. In most cases, a coding scheme would be established (e.g.,
             FR=Freshman, SO=Sophomore, JR=Junior, SR=Senior).
IMAGE
8-9          Any picture or image.
Data Modeling Concepts:
       Domains
         Domain – a property of an attribute that defines what
         values an attribute can legitimately take on.
           Representative Logical Domains for Logical Data Types
  Data Type    Domain                                                       Examples
  NUMBER       For integers, specify the range.                             {10-99}
               For real numbers, specify the range and precision.           {1.000-799.999}
  TEXT         Maximum size of attribute. Actual values usually infinite;   Text(30)
               however, users may specify certain narrative restrictions.
  DATE         Variation on the MMDDYYYY format.                            MMDDYYYY
                                                                            MMYYYY
  TIME         For AM/PM times: HHMMT                                       HHMMT
               For military (24-hour times): HHMM                           HHMM
  YES/NO       {YES, NO}                                                    {YES, NO} {ON, OFF}
  VALUE SET    {value#1, value#2,…value#n}                                  {M=Male
8-10           {table of codes and meanings}                                F=Female}
Data Modeling Concepts:
       Default Value
       Default value – the value that will be recorded if a
       value is not specified by the user.

                     Permissible Default Values for Attributes
Default Value        Interpretation                                                   Examples
A legal value from   For an instance of the attribute, if the user does not specify   0
the domain           a value, then use this value.                                    1.00
NONE or NULL         For an instance of the attribute, if the user does not specify   NONE
                     a value, then leave it blank.                                    NULL
Required or NOT      For an instance of the attribute, require that the user enter    REQUIRED
NULL                 a legal value from the domain. (This is used when no value       NOT NULL
                     in the domain is common enough to be a default but some
                     value must be entered.)
8-11
Data Modeling Concepts:
       Identification
       Key – an attribute, or a group of
       attributes, that assumes a unique value
       for each entity instance. It is sometimes
       called an identifier.
          • Concatenated key - group of attributes
            that uniquely identifies an instance.
            Synonyms: composite key, compound
            key.
          • Candidate key – one of a number of
            keys that may serve as the primary key.
            Synonym: candidate identifier.
          • Primary key – a candidate key used to
            uniquely identify a single entity instance.
          • Alternate key – a candidate key not
            selected to become the primary key.
            Synonym: secondary key.
8-12
Data Modeling Concepts:
       Subsetting Criteria
        Subsetting criteria – an
         attribute(s) whose finite
         values divide all entity
         instances into useful subsets.
         Sometimes called an
         inversion entry.




8-13
Data Modeling Concepts:
       Relationships
       Relationship – 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.




8-14
Data Modeling Concepts:
       Cardinality
       Cardinality – 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.

                             bidirectional




8-15
Cardinality Notations




8-16
Data Modeling Concepts:
       Degree
       Degree – the number of entities that
       participate in the relationship.
           A relationship between two entities is called
           a binary relationship.
           A relationship between three entities is
           called a 3-ary or ternary relationship.
           A relationship between different instances of
           the same entity is called a recursive
           relationship.
8-17
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.


8-18
Data Modeling Concepts:
       Degree
       Associative entity
       – 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         Associative
       only one instance of        Entity
       each of the
       connecting entities.

8-19
Data Modeling Concepts:
       Recursive Relationship
       Recursive relationship - a relationship that
       exists between instances of the same entity




8-20
Data Modeling Concepts:
       Foreign Keys
       Foreign key – a primary key of an entity that is
       used in another entity to identify instances of a
       relationship.
       • A foreign key is a primary key of one entity that is
         contributed to (duplicated in) another entity to identify
         instances of a relationship.
       • A foreign key always matches the primary key in the
         another entity
       • A foreign key may or may not be unique (generally
         not)
       • The entity with the foreign key is called the child.
       • The entity with the matching primary key is called the
8-21     parent.
Data Modeling Concepts:
       Parent and Child Entities
       Parent entity - a data entity that contributes
       one or more attributes to another entity,
       called the child. In a one-to-many
       relationship the parent is the entity on the
       "one" side.

       Child entity - a data entity that derives one
       or more attributes from another entity,
       called the parent. In a one-to-many
       relationship the child is the entity on the
8-22
       "many" side.
Data Modeling Concepts:
        Foreign Keys
        Primary Key
                           Student ID      Last Name       First Name    Dorm
                           2144            Arnold          Betty         Smith
                           3122            Taylor          John          Jones
                           3843            Simmons         Lisa          Smith
                           9844            Macy            Bill
                           2837            Leath           Heather       Smith
                           2293            Wrench          Tim           Jones
Primary Key
                                                         Foreign Key
                                                       Duplicated from
              Dorm    Residence Director               primary key of
              Smith   Andrea Fernandez                   Dorm entity
              Jones   Daniel Abidjan
                                                        (not unique in
 8-23                                                  Student entity)
Data Modeling Concepts:
       Nonidentifying Relationships
       Nonidentifying relationship – relationship where each
       participating entity has its own independent primary key
          • Primary key attributes are not shared.
          • The entities are called strong entities




8-24
Data Modeling Concepts:
       Identifying Relationships
       Identifying relationship – relationship in which the parent
       entity’ key is also part of the primary key of the child entity.
          • The child entity is called a weak entity.




8-25
Data Modeling Concepts:
       Sample CASE Tool Notations




8-26
Data Modeling Concepts:
       Nonspecific Relationships
       Nonspecific
       relationship –
       relationship where
       many instances of
       an entity are
       associated with
       many instances of
       another entity.
       Also called many-
       to-many
       relationship.

       Nonspecific
       relationships must
       be resolved,
       generally by
       introducing an
       associative entity.
8-27
Resolving Nonspecific
       Relationships



               The verb or verb phrase of a many-
                to-many relationship sometimes
                    suggests other entities.




8-28
Resolving Nonspecific
       Relationships (continued)



                         Many-to-many
                        relationships can
                        be resolved with
                          an associative
                              entity.




8-29
Resolving Nonspecific
       Relationships (continued)
                            Many-to-Many Relationship




           While the above relationship is a many-to-many, the many on
           the BANK ACCOUNT side is a known maximum of "2." This
           suggests that the relationship may actually represent multiple
           relationships... In this case two separate relationships.




8-30
Data Modeling Concepts:
       Generalization
       Generalization – a concept wherein the attributes
       that are common to several types of an entity are
       grouped into their own entity.

       Supertype – an entity whose instances store
       attributes that are common to one or more entity
       subtypes.

       Subtype – an entity whose instances may inherit
       common attributes from its entity supertype
           And then add other attributes unique to the subtype.
8-31
Generalization Hierarchy




8-32
Process of Logical Data
       Modeling
       • Strategic Data Modeling
         • Many organizations select IS development
           projects based on strategic plans.
           • Includes vision and architecture for information
             systems
           • Identifies and prioritizes develop projects
           • Includes enterprise data model as starting point
             for projects
       • Data Modeling during Systems Analysis
         • Data model for a single information system is
           called an application data model.
8-33
Logical Model Development
       Stages
       1. Context Data model
          •   Includes only entities and relationships
          •   To establish project scope
       2. Key-based data model
          •   Eliminate nonspecific relationships
          •   Add associative entities
          •   Include primary and alternate keys
          •   Precise cardinalities
       3. Fully attributed data model
          •   All remaining attributes
          •   Subsetting criteria
       4. Normalized data model


8-34   Metadata - data about data.
JRP and Interview Questions
       for Data Modeling
  Purpose                               Candidate Questions
                                        (see textbook for a more complete list)
  Discover system entities              What are the subjects of the business?
  Discover entity keys                  What unique characteristic (or characteristics) distinguishes
                                        an instance of each subject from other instances of the same
                                        subject?
  Discover entity subsetting criteria   Are there any characteristics of a subject that divide all
                                        instances of the subject into useful subsets?
  Discover attributes and domains       What characteristics describe each subject?
  Discover security and control needs   Are there any restrictions on who can see or use the data?
  Discover data timing needs            How often does the data change?
  Discover generalization hierarchies   Are all instances of each subject the same?
  Discover relationships?               What events occur that imply associations between
                                        subjects?
  Discover cardinalities                Is each business activity or event handled the same way, or
                                        are there special circumstances?
8-35
Automated Tools for Data
       Modeling




8-36
Entity Discovery

       • In interviews or JRP sessions, pay attention to
         key words (i.e. "we need to keep track of ...").
       • In interviews or JRP sessions, ask users to
         identify things about which they would like to
         capture, store, and produce information.
       • Study existing forms, files, and reports.
       • Scan use case narratives for nouns.
       • Some CASE tools can reverse engineer
         existing files and databases.
8-37
The Context Data Model




8-38
The Key-based Data Model




8-39
The Key-based Data Model
       with Generalization




8-40
The Fully-Attributed Data Model




8-41
What is a Good Data Model?
       • A good data model is simple.
         • Data attributes that describe any given entity
           should describe only that entity.
         • Each attribute of an entity instance can have only
           one value.
       • A good data model is essentially
         nonredundant.
         • Each data attribute, other than foreign keys,
           describes at most one entity.
         • Look for the same attribute recorded more than
           once under different names.
       • A good data model should be flexible and
8-42     adaptable to future needs.
Data Analysis & Normalization
Data analysis – a technique used to
improve a data model for implementation
as a database.
   Goal is a simple, nonredundant, flexible, and
   adaptable database.


Normalization – a data analysis technique
that organizes data into groups to form
nonredundant, stable, flexible, and
adaptive entities.
Normalization: 1NF, 2NF, 3NF
       First normal form (1NF) – entity whose attributes have no more
       than one value for a single instance of that entity
        • Any attributes that can have multiple values actually describe a
          separate entity, possibly an entity and relationship.
       Second normal form (2NF) – entity whose nonprimary-key
       attributes are dependent on the full primary key.
        • Any nonkey attributes dependent on only part of the primary key
           should be moved to entity where that partial key is the full key.
           May require creating a new entity and relationship on the model.
       Third normal form (3NF) – entity whose nonprimary-key
       attributes are not dependent on any other non-primary key
       attributes.
        • Any nonkey attributes that are dependent on other nonkey
           attributes must be moved or deleted. Again, new entities and
8-44       relationships may have to be added to the data model.
First Normal Form Example 1




8-45
First Normal Form Example 2




8-46
Second Normal Form Example 1




8-47
Second Normal Form Example 2




8-48
Third Normal Form Example 1
       Derived attribute – an attribute whose value can be
       calculated from other attributes or derived from the
       values of other attributes.




8-49
Third Normal Form Example 2
       Transitive dependency
       – when the value of a
       nonkey attribute is
       dependent on the value
       of another nonkey
       attribute other than by
       derivation.




8-50
SoundStage 3NF Data Model




8-51
Data-to-Location-CRUD Matrix




8-52

More Related Content

PPT
PDF
Tutorial On Database Management System
PDF
UNIFIED MODELING LANGUAGE
PPT
Succesfactors demo
PPT
Chapter10 conceptual data modeling
PDF
Dbms 10: Conversion of ER model to Relational Model
PPTX
Strategy of software design
PPT
Database Chapter 1
Tutorial On Database Management System
UNIFIED MODELING LANGUAGE
Succesfactors demo
Chapter10 conceptual data modeling
Dbms 10: Conversion of ER model to Relational Model
Strategy of software design
Database Chapter 1

What's hot (20)

PPTX
Entity Relationship Modelling
PPT
Object Oriented Analysis and Design with UML2 part1
PPT
Laudon mis12 ppt01
PPT
Management information system database management
PDF
4 the relational data model and relational database constraints
PDF
2 database system concepts and architecture
PDF
Comparison of Relational Database and Object Oriented Database
PPTX
Types, purposes and applications of information systems
PPTX
ER DIAGRAM & ER MODELING IN DBMS
PPTX
Importance of data model
PPT
Database connectivity and web technologies
PPT
Information systems in Organizations
PPTX
Enhance ERD(Entity Relationship Diagram)
PPTX
Uml Presentation
PPTX
Data Dictionary in System Analysis and Design
PDF
Chapter7
PPT
Query optimization
PPT
Object Oriented Dbms
PPT
Chapter 1 Enterprise Resource Planning Alexis Leon
PDF
Sql commands
Entity Relationship Modelling
Object Oriented Analysis and Design with UML2 part1
Laudon mis12 ppt01
Management information system database management
4 the relational data model and relational database constraints
2 database system concepts and architecture
Comparison of Relational Database and Object Oriented Database
Types, purposes and applications of information systems
ER DIAGRAM & ER MODELING IN DBMS
Importance of data model
Database connectivity and web technologies
Information systems in Organizations
Enhance ERD(Entity Relationship Diagram)
Uml Presentation
Data Dictionary in System Analysis and Design
Chapter7
Query optimization
Object Oriented Dbms
Chapter 1 Enterprise Resource Planning Alexis Leon
Sql commands
Ad

Viewers also liked (10)

PPT
PPT
PPT
PPT
PDF
RDBMS ERD
PPT
PDF
The Relational Data Model and Relational Database Constraints
PPT
Fact finding techniques
PPTX
Concept of Relational Database and Integrity Constraints [DIFFERENCE BETWEEN ...
PPT
Data integrity
RDBMS ERD
The Relational Data Model and Relational Database Constraints
Fact finding techniques
Concept of Relational Database and Integrity Constraints [DIFFERENCE BETWEEN ...
Data integrity
Ad

Similar to Chap08 (20)

PPTX
8.pptx
PPT
Data Modelling on the Relation between two or more variables
PDF
Summary data modelling
PPTX
Database Modeling Using Entity.. Weak And Strong Entity Types
PPTX
PPTX
Data Modeling PPT
PPTX
DATA MODELING.pptx
PDF
Sq lite module3
PPTX
Chapter 8
PDF
PDF
Unit 2 DBMS
PDF
Conceptual Data Modelling Using ER-models
PPTX
U2_ER_modeling.pptx
PPTX
Data Modelling..pptx
PPTX
Entity-Relationship Model.pptx data modeling
PDF
3. Chapter Three.pdf
PDF
Unit 2-Data Modeling.pdf
PPTX
ER modeling
PPT
PDF
Sq lite module4
8.pptx
Data Modelling on the Relation between two or more variables
Summary data modelling
Database Modeling Using Entity.. Weak And Strong Entity Types
Data Modeling PPT
DATA MODELING.pptx
Sq lite module3
Chapter 8
Unit 2 DBMS
Conceptual Data Modelling Using ER-models
U2_ER_modeling.pptx
Data Modelling..pptx
Entity-Relationship Model.pptx data modeling
3. Chapter Three.pdf
Unit 2-Data Modeling.pdf
ER modeling
Sq lite module4

More from professorkarla (8)

PPT
PPT
PPT
PPT
PPT
PPT
PPT
PPT

Recently uploaded (20)

PDF
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
PPTX
Big Data Technologies - Introduction.pptx
PDF
NewMind AI Monthly Chronicles - July 2025
PDF
Network Security Unit 5.pdf for BCA BBA.
PDF
Electronic commerce courselecture one. Pdf
PPTX
A Presentation on Artificial Intelligence
PDF
Approach and Philosophy of On baking technology
PDF
CIFDAQ's Market Insight: SEC Turns Pro Crypto
PDF
NewMind AI Weekly Chronicles - August'25 Week I
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PPTX
Cloud computing and distributed systems.
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
DOCX
The AUB Centre for AI in Media Proposal.docx
PDF
Agricultural_Statistics_at_a_Glance_2022_0.pdf
PDF
Dropbox Q2 2025 Financial Results & Investor Presentation
PPT
“AI and Expert System Decision Support & Business Intelligence Systems”
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
PPTX
MYSQL Presentation for SQL database connectivity
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
Big Data Technologies - Introduction.pptx
NewMind AI Monthly Chronicles - July 2025
Network Security Unit 5.pdf for BCA BBA.
Electronic commerce courselecture one. Pdf
A Presentation on Artificial Intelligence
Approach and Philosophy of On baking technology
CIFDAQ's Market Insight: SEC Turns Pro Crypto
NewMind AI Weekly Chronicles - August'25 Week I
Diabetes mellitus diagnosis method based random forest with bat algorithm
Spectral efficient network and resource selection model in 5G networks
Mobile App Security Testing_ A Comprehensive Guide.pdf
Cloud computing and distributed systems.
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
The AUB Centre for AI in Media Proposal.docx
Agricultural_Statistics_at_a_Glance_2022_0.pdf
Dropbox Q2 2025 Financial Results & Investor Presentation
“AI and Expert System Decision Support & Business Intelligence Systems”
Advanced methodologies resolving dimensionality complications for autism neur...
MYSQL Presentation for SQL database connectivity

Chap08

  • 1. Chapter 8 Data Modeling and Analysis McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
  • 2. Objectives • Define data modeling and explain its benefits. • Recognize and understand the basic concepts and constructs of a data model. • Read and interpret an entity relationship data model. • Explain when data models are constructed during a project and where the models are stored. • Discover entities and relationships. • Construct an entity-relationship context diagram. • Discover or invent keys for entities and construct a key-based diagram. • Construct a fully attributed entity relationship diagram and describe data structures and attributes to the repository. • Normalize a logical data model to remove impurities that can make a database unstable, inflexible, and nonscalable. • Describe a useful tool for mapping data requirements to business operating locations.
  • 3. 8-3
  • 4. Data Modeling Data modeling – a technique for organizing and documenting a system’s data. Sometimes called database modeling. Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data. 8-4
  • 5. Sample Entity Relationship Diagram (ERD) 8-5
  • 6. Data Modeling Concepts: Entity Entity – a class of persons, places, objects, events, or concepts about which we need to capture and store data. • Named by a singular noun  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, 8-6 qualification, stock.
  • 7. Data Modeling Concepts: Entity Entity instance – a single occurrence of an entity. entity Student ID Last Name First Name 2144 Arnold Betty 3122 Taylor John 3843 Simmons Lisa instances 9844 Macy Bill 2837 Leath Heather 2293 Wrench Tim 8-7
  • 8. Data Modeling Concepts: Attributes Attribute – a descriptive property or characteristic of an entity. Synonyms include element, property, and field. • Just as a physical student can have attributes, such as hair color, height, etc., data entity has data attributes Compound attribute – an attribute that consists of other attributes. Synonyms in different data modeling languages are numerous: concatenated attribute, composite attribute, and data structure. 8-8
  • 9. Data Modeling Concepts: Data Type Data type – a property of an attribute that identifies what type of data can be stored in that attribute. Representative Logical Data Types for Attributes Data Type Logical Business Meaning NUMBER Any number, real or integer. TEXT A string of characters, inclusive of numbers. When numbers are included in a TEXT attribute, it means that we do not expect to perform arithmetic or comparisons with those numbers. MEMO Same as TEXT but of an indeterminate size. Some business systems require the ability to attach potentially lengthy notes to a give database record. DATE Any date in any format. TIME Any time in any format. YES/NO An attribute that can assume only one of these two values. VALUE SET A finite set of values. In most cases, a coding scheme would be established (e.g., FR=Freshman, SO=Sophomore, JR=Junior, SR=Senior). IMAGE 8-9 Any picture or image.
  • 10. Data Modeling Concepts: Domains Domain – a property of an attribute that defines what values an attribute can legitimately take on. Representative Logical Domains for Logical Data Types Data Type Domain Examples NUMBER For integers, specify the range. {10-99} For real numbers, specify the range and precision. {1.000-799.999} TEXT Maximum size of attribute. Actual values usually infinite; Text(30) however, users may specify certain narrative restrictions. DATE Variation on the MMDDYYYY format. MMDDYYYY MMYYYY TIME For AM/PM times: HHMMT HHMMT For military (24-hour times): HHMM HHMM YES/NO {YES, NO} {YES, NO} {ON, OFF} VALUE SET {value#1, value#2,…value#n} {M=Male 8-10 {table of codes and meanings} F=Female}
  • 11. Data Modeling Concepts: Default Value Default value – the value that will be recorded if a value is not specified by the user. Permissible Default Values for Attributes Default Value Interpretation Examples A legal value from For an instance of the attribute, if the user does not specify 0 the domain a value, then use this value. 1.00 NONE or NULL For an instance of the attribute, if the user does not specify NONE a value, then leave it blank. NULL Required or NOT For an instance of the attribute, require that the user enter REQUIRED NULL a legal value from the domain. (This is used when no value NOT NULL in the domain is common enough to be a default but some value must be entered.) 8-11
  • 12. Data Modeling Concepts: Identification Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier. • Concatenated key - group of attributes that uniquely identifies an instance. Synonyms: composite key, compound key. • Candidate key – one of a number of keys that may serve as the primary key. Synonym: candidate identifier. • Primary key – a candidate key used to uniquely identify a single entity instance. • Alternate key – a candidate key not selected to become the primary key. Synonym: secondary key. 8-12
  • 13. Data Modeling Concepts: Subsetting Criteria Subsetting criteria – an attribute(s) whose finite values divide all entity instances into useful subsets. Sometimes called an inversion entry. 8-13
  • 14. Data Modeling Concepts: Relationships Relationship – 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. 8-14
  • 15. Data Modeling Concepts: Cardinality Cardinality – 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. bidirectional 8-15
  • 17. Data Modeling Concepts: Degree Degree – the number of entities that participate in the relationship. A relationship between two entities is called a binary relationship. A relationship between three entities is called a 3-ary or ternary relationship. A relationship between different instances of the same entity is called a recursive relationship. 8-17
  • 18. 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. 8-18
  • 19. Data Modeling Concepts: Degree Associative entity – 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 Associative only one instance of Entity each of the connecting entities. 8-19
  • 20. Data Modeling Concepts: Recursive Relationship Recursive relationship - a relationship that exists between instances of the same entity 8-20
  • 21. Data Modeling Concepts: Foreign Keys Foreign key – a primary key of an entity that is used in another entity to identify instances of a relationship. • A foreign key is a primary key of one entity that is contributed to (duplicated in) another entity to identify instances of a relationship. • A foreign key always matches the primary key in the another entity • A foreign key may or may not be unique (generally not) • The entity with the foreign key is called the child. • The entity with the matching primary key is called the 8-21 parent.
  • 22. Data Modeling Concepts: Parent and Child Entities Parent entity - a data entity that contributes one or more attributes to another entity, called the child. In a one-to-many relationship the parent is the entity on the "one" side. Child entity - a data entity that derives one or more attributes from another entity, called the parent. In a one-to-many relationship the child is the entity on the 8-22 "many" side.
  • 23. Data Modeling Concepts: Foreign Keys Primary Key Student ID Last Name First Name Dorm 2144 Arnold Betty Smith 3122 Taylor John Jones 3843 Simmons Lisa Smith 9844 Macy Bill 2837 Leath Heather Smith 2293 Wrench Tim Jones Primary Key Foreign Key Duplicated from Dorm Residence Director primary key of Smith Andrea Fernandez Dorm entity Jones Daniel Abidjan (not unique in 8-23 Student entity)
  • 24. Data Modeling Concepts: Nonidentifying Relationships Nonidentifying relationship – relationship where each participating entity has its own independent primary key • Primary key attributes are not shared. • The entities are called strong entities 8-24
  • 25. Data Modeling Concepts: Identifying Relationships Identifying relationship – relationship in which the parent entity’ key is also part of the primary key of the child entity. • The child entity is called a weak entity. 8-25
  • 26. Data Modeling Concepts: Sample CASE Tool Notations 8-26
  • 27. Data Modeling Concepts: Nonspecific Relationships Nonspecific relationship – relationship where many instances of an entity are associated with many instances of another entity. Also called many- to-many relationship. Nonspecific relationships must be resolved, generally by introducing an associative entity. 8-27
  • 28. Resolving Nonspecific Relationships The verb or verb phrase of a many- to-many relationship sometimes suggests other entities. 8-28
  • 29. Resolving Nonspecific Relationships (continued) Many-to-many relationships can be resolved with an associative entity. 8-29
  • 30. Resolving Nonspecific Relationships (continued) Many-to-Many Relationship While the above relationship is a many-to-many, the many on the BANK ACCOUNT side is a known maximum of "2." This suggests that the relationship may actually represent multiple relationships... In this case two separate relationships. 8-30
  • 31. Data Modeling Concepts: Generalization Generalization – a concept wherein the attributes that are common to several types of an entity are grouped into their own entity. Supertype – an entity whose instances store attributes that are common to one or more entity subtypes. Subtype – an entity whose instances may inherit common attributes from its entity supertype And then add other attributes unique to the subtype. 8-31
  • 33. Process of Logical Data Modeling • Strategic Data Modeling • Many organizations select IS development projects based on strategic plans. • Includes vision and architecture for information systems • Identifies and prioritizes develop projects • Includes enterprise data model as starting point for projects • Data Modeling during Systems Analysis • Data model for a single information system is called an application data model. 8-33
  • 34. Logical Model Development Stages 1. Context Data model • Includes only entities and relationships • To establish project scope 2. Key-based data model • Eliminate nonspecific relationships • Add associative entities • Include primary and alternate keys • Precise cardinalities 3. Fully attributed data model • All remaining attributes • Subsetting criteria 4. Normalized data model 8-34 Metadata - data about data.
  • 35. JRP and Interview Questions for Data Modeling Purpose Candidate Questions (see textbook for a more complete list) Discover system entities What are the subjects of the business? Discover entity keys What unique characteristic (or characteristics) distinguishes an instance of each subject from other instances of the same subject? Discover entity subsetting criteria Are there any characteristics of a subject that divide all instances of the subject into useful subsets? Discover attributes and domains What characteristics describe each subject? Discover security and control needs Are there any restrictions on who can see or use the data? Discover data timing needs How often does the data change? Discover generalization hierarchies Are all instances of each subject the same? Discover relationships? What events occur that imply associations between subjects? Discover cardinalities Is each business activity or event handled the same way, or are there special circumstances? 8-35
  • 36. Automated Tools for Data Modeling 8-36
  • 37. Entity Discovery • In interviews or JRP sessions, pay attention to key words (i.e. "we need to keep track of ..."). • In interviews or JRP sessions, ask users to identify things about which they would like to capture, store, and produce information. • Study existing forms, files, and reports. • Scan use case narratives for nouns. • Some CASE tools can reverse engineer existing files and databases. 8-37
  • 38. The Context Data Model 8-38
  • 39. The Key-based Data Model 8-39
  • 40. The Key-based Data Model with Generalization 8-40
  • 42. What is a Good Data Model? • A good data model is simple. • Data attributes that describe any given entity should describe only that entity. • Each attribute of an entity instance can have only one value. • A good data model is essentially nonredundant. • Each data attribute, other than foreign keys, describes at most one entity. • Look for the same attribute recorded more than once under different names. • A good data model should be flexible and 8-42 adaptable to future needs.
  • 43. Data Analysis & Normalization Data analysis – a technique used to improve a data model for implementation as a database. Goal is a simple, nonredundant, flexible, and adaptable database. Normalization – a data analysis technique that organizes data into groups to form nonredundant, stable, flexible, and adaptive entities.
  • 44. Normalization: 1NF, 2NF, 3NF First normal form (1NF) – entity whose attributes have no more than one value for a single instance of that entity • Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. Second normal form (2NF) – entity whose nonprimary-key attributes are dependent on the full primary key. • Any nonkey attributes dependent on only part of the primary key should be moved to entity where that partial key is the full key. May require creating a new entity and relationship on the model. Third normal form (3NF) – entity whose nonprimary-key attributes are not dependent on any other non-primary key attributes. • Any nonkey attributes that are dependent on other nonkey attributes must be moved or deleted. Again, new entities and 8-44 relationships may have to be added to the data model.
  • 45. First Normal Form Example 1 8-45
  • 46. First Normal Form Example 2 8-46
  • 47. Second Normal Form Example 1 8-47
  • 48. Second Normal Form Example 2 8-48
  • 49. Third Normal Form Example 1 Derived attribute – an attribute whose value can be calculated from other attributes or derived from the values of other attributes. 8-49
  • 50. Third Normal Form Example 2 Transitive dependency – when the value of a nonkey attribute is dependent on the value of another nonkey attribute other than by derivation. 8-50
  • 51. SoundStage 3NF Data Model 8-51

Editor's Notes

  • #2: This repository of slides is intended to support the named chapter. The slide repository should be used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector.
  • #3: No additional notes
  • #4: Teaching Notes This slide shows the how this chapter's content fits with the building blocks framework used throughout the textbook. The emphasis of this chapter is upon the DATA. It also reflects the fact that data modeling may be performed during certain analysis phases and involves not only systems analysts…but owners and users.
  • #5: No additional notes
  • #6: Teaching Notes Be sure to explain that this is merely an example – there are numerous data modeling notations. While they may differ in appearance (symbology) the knowledge that data models are intended to convey the same.
  • #7: Teaching Notes: Prompt the students for additional examples. Have them classify their example(s). Obtain a data model from a source other than the textbook. Ask the students to classify the entities.
  • #8: Teaching Notes Substitute the name(s) of one or more of your students. Be sure to explain that these are “instances” and that instances do NOT appear in the names of entity symbols.
  • #9: Teaching Notes: Go back to the slide showing the sample ERD (Figure 8-1). Pick an entity and ask the students to list attributes that they feel describe those entities. Show the students a form. Ask the students to identify the attributes. Be sure that the students recognize what items appearing on the form are truly attributes and those that are simply headings or preprinted items. Also, often students accidentally identify attribute values as attributes. For example, they may say that an item that appears as a check box is an attribute when in fact it may be the value of an attribute (ie. Male and female are values, whereas GENDER is the real attribute).
  • #10: Teaching Notes These are generic data types. If your students have taken a database class they would be familiar with the data types specific to that database.
  • #11: No additional notes
  • #12: No additional notes
  • #13: Teaching Notes Students can generally relate to the following example. Suppose you are working for an hourly wage. The employer has some method of tracking the hours you work. Whether that involves a time clock, an identification badge that it scanned, or a log book, the system records a certain number of hours and some employee identifier that says those hours are yours. Without that identifier, come pay day the employer would not know whose hours were whose. The employer might pay someone else for the hours you worked. That’s how important a primary key or identifier is.
  • #14: No additional notes
  • #15: Teaching Notes Explain that there may be more than one relationship between two entities. You may reinforce this by adding additional relationships to the example (such as “transferred from” (to reflect a relationship where students changed from one curriculum to another).
  • #16: Teaching Notes Ask the students to read (or write) declarative sentences to reflect the bidirectional meaning of the relationship between student and curriculum.
  • #17: Teaching Notes Although this figure shows five different options, help students see that there are really only two options for minimum cardinality (0 or 1) and two options for maximum cardinality (1 or many).
  • #18: Teaching Notes: Provide the students with an ERD that does not contain relationships. Ask the students to identify possible relationships and indicate a possible degree for that relationship. Emphasize to the students that the degree represents a business rule! Failure to accurately identify and document the degree will result in a system that does not reflect a correct business requirement.
  • #19: Teaching Notes The example also depicts an associative entity for the first time…as explained on the next slide.
  • #20: No additional notes
  • #21: Teaching Notes Ask the students to read (or write) declarative sentences to reflect the bidirectional meaning of the relationship. We created a composite key in this example. Be sure to point out the notation. Another classic example of a recursive relationship is in an Employee entity with a Supervisor attribute that holds the identifier of the supervisor’s instance of that same Employee entity.
  • #22: Teaching Notes Foreign keys are what make a relational database relational.
  • #23: Teaching Notes These concepts are illustrated on the next slide.
  • #24: Teaching Notes Have students identity which is the parent entity (Major) and which is the child (Student). Additional examples should be given to test the student’s ability to recognize the parent entity. We suggest you also provide an example of a one-to-one relationship!
  • #25: No additional notes.
  • #26: No additional notes.
  • #27: Teaching Notes Add slides to show students how the CASE or modeling tool that will be used in the class differentiates between identifying and nonidentifying relationships and weak and strong entities.
  • #28: Teaching Notes You may need to refer to the earlier slide that defines an associative entity In the bottom diagram we see that a student can declare multiple majors and that a curriculum can offer multiple majors. Note that for associative entities the cardinality from child to parent is always one and only one . An instance of MAJOR must correspond to one and only one STUDENT and to one and only one CURRICULUM.
  • #29: Teaching Notes Part (c) of Figure 8-9 is on the next slide
  • #30: No additional notes
  • #31: Teaching Notes This shows that while most nonspecific relationships are resolved by introducing a third entity, some are resolved by introducing separate relationships.
  • #32: Teaching Notes: If students have already studied object-oriented modeling, they will be familiar with generalization from that. Ask the students to identify a generalization example. What are some common attributes? What are some unique attributes associated with the subtype(s)? One common example is EMPLOYEE (supertype) with HOURLY EMPLOYEE (subtype) and SALARY EMPLOYEE (subtype).
  • #33: Teaching Notes Generalization can be multiple levels deep.
  • #34: Teaching Notes Data modeling may be performed during various types of projects and in multiple phases of projects. Data models are progressive and should be considered a living document that will change in response to changing business needs.
  • #35: Teaching Notes These are the steps that are followed in the case studies that accompany the text
  • #36: Teaching Notes Regardless of whether you use JRP, interviewing, or any other approach for information gathering, these are good questions to ask. Ask students to suggest other questions they could ask. It will help them and you make sure they understand the concepts and their real-world application. Students can ask themselves these questions as they walk though data modeling for class assignments.
  • #37: Teaching Notes You could substitute a screen shot from the modeling tool you use in your class. If your classroom has computer projection capabilities, you could demo the modeling tool.
  • #39: Teaching Notes The purpose of this slide is not just to show what a context data model looks like. Take the time to walk through the entities and relationships using information from the textbook as a guide.
  • #40: Teaching Notes Depending on your room conditions, you may want to break this diagram into two or more parts and resize each to insure readability. Discuss the issues regarding keys and codes from the textbook
  • #41: Teaching Notes Depending on your room conditions, you may want to break this diagram into two or more parts and resize each to insure readability. Discuss the need for the generalization.
  • #42: Teaching Notes Depending on your room conditions, you may want to break this diagram into two or more parts and resize each to insure readability. Discuss attribute naming conventions, attribute discovery from forms, and other attribute issues. Use the information in the textbook as a guide.
  • #43: No additional notes.
  • #44: No additional notes
  • #45: No additional notes
  • #46: Teaching Notes The repeating attributes are moved to a separate entity that has a one-to-many relationship to the original entity.
  • #47: Teaching Notes The repeating attributes are moved to a separate entity that has a one-to-many relationship to the original entity.
  • #48: Teaching Notes The attributes ordered-product-description and ordered-product-title do not describe the primary key (order-number) of Member Ordered Product. They describe Merchandise and Title instead.
  • #49: Teaching Notes This could be a good time to bring out the old saw, “The key, the whole key, and nothing but the key.”
  • #50: Teaching Notes Some students also might see Purchased-Unit-Price as a derived attribute since it can be derived from Suggested-Retail-Price of the PRODUCT entity. This is a useful concept to discuss in class. The reason why Purchased-Unit-Price must exist in MEMBER ORDERED PRODUCT is that while it can initially be derived from the PRODUCT entity, one would not be able to derive it at a later time if there were a price change. So these two attributes have subtly different definitions. One is the current price, which may change. The other is the price use for that particular order, which should not change.
  • #51: Teaching Notes Member Name and Member Address are dependent on Member Number, which is a foreign key to the Member entity. So they are moved to the Member entity.
  • #52: Teaching Notes Edit this slide as needed to ensure readability or refer students to the textbox.
  • #53: No additional notes