Advanced Data Modeling _Handout_ - Courseweb

Document Sample
Advanced Data Modeling _Handout_ - Courseweb Powered By Docstoc
					Advanced Data Modeling
  Concepts and Tools

 CS 95 Advanced Database

        Handout 2
                     The Database Design Process

• Phases of Database Design                                Steps in DB Design

    Conceptual Design using Semantic
     Data Modeling Tools, e.g.                                   Definition

          Entity-Relationship Model

          Enhanced ER Model
                                                               Conceptual Model

          Object-oriented Data Model                          Logical/Physical

          Object-relational Data Model
 Data-oriented approach - because data are more stable
   than the functions (or processes) in an organization.
Database Design and Conceptual Data

Analogous to analysis phase of software development
Requirement Collection and Analysis
  - Designers interview database users to understand and
  document data requirements.
Functional Requirements
  - User defined operations to be applied on the database
      Database Design and Conceptual
           Data Modeling (cont’d)

• Conceptual Design
  -Conceptual schema; a permanent description of
   database specifications.
  - Capture the semantics of the data; description of data,
    constraints, relationships
  - No storage or physical details yet
  - Use of semantic data modeling tools (e.g. ERD)
  - relational model is not a semantic data model
             What is a data model?

• Description in high-level model
   - Close to the user' view of mini-world
   - Abstract concepts
   - Means of communication between the non-technical
     users and the developer
   - Allows user to influence design and is independent of
     any particular DBMS.
•Examples: ER, Enhanced ER, Object-Oriented and
           Object-Relational Data Model
•Unified Modeling Language (UML) - data modeling subset
           (i.e., structural modeling subset)
     Enhanced Entity-Relationship Model
•Subclass/superclass (or subtype/supertype)
   Specialization -- define subclasses
   Generalization -- define superclass
   •Constraints on Specialization
      Disjointness (Disjoint or Overlap)
      Completeness (Total or Partial Specialization)
•Hierarchies and Lattices
•Union Types (Categories)
               Semantic Data Models

Most common database management systems represent
information in a simple record-based format, semantic
  provides richer data structuring capabilities for database
  provide mechanisms for representing structurally
   complex interrelations among data typically arising in
   commercial applications
  complements work on knowledge representation (in
   artificial intelligence) and on the new generation of
   database models based on the object-oriented paradigm
   of programming languages.
       Enhanced ER Model (EER)

•   EER Model = ER Model + Extensions
•   Extensions:
       - Subclass (Specialization)
       - Superclass (Generalization)
       - Category
       - Attribute and Relation Inheritance

•   Subclass: Entities of an Entity type sharing a set of
             attribute which are grouped together
•   Superclass: The ‘parent’ entity type from which
                subclasses are formed
•   Class/Subclass relationship: Relationship between a
                superclass and oneof the subclasses
•   Specialization: The process of forming subclasses
                    from a superclass
        Subclass/Superclass (contd.)

•   Type Inheritance: Member of subclass possessing all
    attributes and relationships of a member of superclass
•   Local Attributes: Attributes that apply only to
    members of a subclass (a.k.a. specific attribute)
•   Local Relationships: Relationships applicable only to
    members of a subclass(a.k.a. specific relationships)
•   Generalization: Process of forming a supercalss from
    subclasses. (Functionally, inverse of specialization)

•   Several Specializations could be defined on the same
    entity type (Superclass)
•   Specialization with single subclass is also permitted
•   Predicate-defined subclass: Specialization specified
    by a condition on the value some attribute of
    superclass. (a.k.a. condition-defined)
•   Defining predicate: Condition satisfied by all
    members of a predicate-defined subclass
          Characteristics (contd.)

•   Attribute-defined specialization: All subclasses
    having membership condition on the same attribute of
    the superclass
•   Defining Attributes: No condition exists for determing
    membership in the subclass

•   Disjointness constraint: Subclasses of the
    specialization must be disjoint (an entity is a member
    of at most one subclass)
    - Overlapping: Subclasses not constrained to be
•   Completeness Constraint:
    - Total: Every entity in superclass must be a member of
        some subclass (e.g.\{HOURLY\_EMPLOYEE,
            Constraints (contd.)

    - Partial: An entity in superclass may not be a member
               of any subclass
•   Disjointness and Completeness are independent.
    (leads to 4 possible constraints on specialization)
       - Disjoint, Total
       - Disjoint, Partial
       - Overlapping, Total
       - Overlapping, Partial
Specialization Hierarchies and Lattices

•   Subclass may have further subclasses, and so on.
•   Specialization Hierarchy: Every subclass participates
               in only one class/subclass relationship
•   Specialization Lattice: A subclass can participate in
              more than one class/subclass relationship
•   Leaf Node: A class that has no subclass
Specialization Hierarchies and Lattices

•   Shared Subclass: A subclass with more than one
•   Multiple Inheritance: A shared subclass inheriting
    attributes and relationships from multiple (super)
           Union Type/Categories

•   Uniontype (Category): Subclass with class/subclass
          relationship with more than one superclass of
          different entity types
•   Category is a subset of the union of its superclass
•   An entity in Category is a member of only one of its
•   Category types: Total or Partial
         Object-Oriented Data Model
 Object models describe the system in terms of object
  classes. An object class is an abstraction over a set of
  objects with common attributes and the services
  (operations) provided by each object
 Various object models may be produced
   Inheritance models
   Aggregation models
   Relation models
   Service models
 Object databases allow storage of complex data types or
  objects and supports inheritance, polymorphism, and
  encapsulation for full object-oriented development
        Object-Oriented Data Model

 Natural ways of reflecting the real-world entities
  manipulated by the system
 More abstract entities are more difficult to model using this
 Object class identification is recognized as a difficult
  process requiring a deep understanding of the application
 Object classes reflecting domain entities are reusable
  across systems
      Key OO Concepts

Classes             Encapsulation
Objects             Persistence
Methods/Operation   Polymorphism/Oper
Messages             ator Overloading
Inheritance         Multiple/Selective
Complex Objects      Inheritance
Approximate Equivalence of Object-Oriented
  and Conventional Data Modeling Terms

Object-Oriented        Conventional
  Object                 Record instance, row
  Object Class           Record type, table
  Instance attribute     Field
  Instance attribute     Field type
  Method                 Procedure
  Message                Procedure call
          Object-Oriented Data
            Model Example
                                                          Company                 Person
                                                          Name                    Name
                   Vehicle                                Location                Birthday
                   Serial#                                Contact Name
                   Manufacturer                           Auto Company
                                                          Total Sales

  Trunk capacity    Set Type            Cargo Space
                                                           Foreign Auto Company
                                                          Import Limits
  Automobile       Motor Bike          Truck              Trade

Legend:               Class-subclass

                      Attribute/aggregation association
    Object-Relational Data Model

Hybrid data model combining relational
 and object-oriented model features
Object-relational database is a hybrid type
 of database, i.e., the relational database
 server is usually extended to support
 objects as if they are new data types
Unified Modeling Language
         Why do we model?

Provide structure for problem solving
Experiment to explore multiple solutions
Furnish abstractions to manage complexity
Reduce time-to-market for business
 problem solutions
Decrease development costs
Manage the risk of mistakes
Why do we model

Graphics reveal data.
  Edward Tufte
   The Visual Display of Quantitative Information,

1 bitmap = 1 megaword.
  Anonymous visual modeler
 UML - Quick Tour
The UML is a graphical language for
 specifying, visualizing, constructing
 and documenting the artifacts of
 software systems
 Added to the list of OMG adopted technologies in
  November 1997 as UML 1.1
 Most recent minor revision is UML 1.3, adopted in
  November 1999
 Next minor revision will be UML 1.4, planned to be
  adopted in Q2 2001
 Next major revision will be UML 2.0, planned to be
  completed in 2002
 UML Goals
Define an easy-to-learn but semantically rich
 visual modeling language
Unify the Booch, OMT, and Objectory modeling
Include ideas from other modeling languages
Incorporate industry best practices
Address contemporary software development
  scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different
Enable model interchange and define
 repository interfaces
  OMG UML Contributors
Aonix                       Microsoft
Colorado State University   ObjecTime
Computer Associates         Oracle
Concept Five                Ptech
Data Access                 OAO Technology Solutions
EDS                         Rational Software
Enea Data                   Reich
Hewlett-Packard             SAP
IBM                         Softeam
I-Logix                     Sterling Software
InLine Software             Sun
Intellicorp                 Taskon
Kabira Technologies         Telelogic
Klasse Objecten             Unisys
Lockheed Martin             …
 Building Blocks

The basic building blocks of UML are:
  model elements (classes, interfaces, components,
   use cases, etc.)
  relationships (associations, generalization,
   dependencies, etc.)
  diagrams (class diagrams, use case diagrams,
   interaction diagrams, etc.)
Simple building blocks are used to create large,
 complex structures
  cf. elements, bonds and molecules in chemistry
  cf. components, connectors and circuit boards in
  Unifying Concepts

classifier-instance dichotomy
  e.g., an object is an instance of a class OR
   a class is the classifier of an object
specification-realization dichotomy
  e.g., an interface is a specification of a class OR
   a class is a realization of an interface
analysis-time vs. design-time vs. run-time
  modeling phases (“process creep”)
  usage guidelines suggested, not enforced
What is structural modeling?

Structural model: a view of an system
 that emphasizes the structure of the
 objects, including their classifiers,
 relationships, attributes and operations.
Data modeling is a subset of structural
Structural Modeling: Core
Structural Modeling: Core
Elements (cont’d)

¹ An extension mechanism useful for specifying structural elements.
Structural Modeling: Core
Structural Modeling: Core Relationships
 Structural Diagram Tour

Show the static structure of the model
  the entities that exist (e.g., classes, interfaces,
   components, nodes)
  internal structure
  relationship to other entities
Do not show
  temporal information
  static structural diagrams
     class diagram
     object diagram
  implementation diagrams
     component diagram
     deployment diagram
Static Structural Diagrams

Shows a graph of classifier
 elements connected by static
  class diagram: classifier view
  object diagram: instance view

          Fig. 3-20, UML Notation Guide
Classes: compartments with

         Fig. 3-23, UML Notation Guide
Classes: method body

       Fig. 3-24, UML Notation Guide
Types and Implementation

         Fig. 3-27, UML Notation Guide
Interfaces: Shorthand

         Fig. 3-29, UML Notation Guide
Interfaces: Longhand

         Fig. 3-29, UML Notation Guide

        Fig. 3-40, UML Notation Guide
Association Ends

        Fig. 3-41, UML Notation Guide
Ternary Associations

        Fig. 3-44, UML Notation Guide

        Fig. 3-45, UML Notation Guide
Composition       (cont’d)

        Fig. 3-45, UML Notation Guide

        Fig. 3-47, UML Notation Guide

       Fig. 3-48, UML Notation Guide

       Fig. 3-50, UML Notation Guide

       Fig. 3-51, UML Notation Guide
Derived Attributes and

          Fig. 3-52, UML Notation Guide

          Fig. 3-38, UML Notation Guide
Composite objects

       Fig. 3-39, UML Notation Guide

        Fig. 3-46, UML Notation Guide
Constraints and

       Fig. 3-17, UML Notation Guide
Class Diagram Examples

                  Adapted from Fig. 23 [EJB 2.0].
Adapted from Fig. 23 [EJB 2.0].
Adapted from Fig. 23 [EJB 2.0].

Shared By: