Docstoc

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
         Systems

        Handout 2
                     The Database Design Process
                                             (Revisited)

• Phases of Database Design                                Steps in DB Design

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

          Entity-Relationship Model
                                                                   Develop

          Enhanced ER Model
                                                               Conceptual Model


          Object-oriented Data Model                          Logical/Physical
                                                                   Design

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


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
           (Concepts/Features)
•Subclass/superclass (or subtype/supertype)
   Specialization -- define subclasses
   Generalization -- define superclass
   •Constraints on Specialization
      Disjointness (Disjoint or Overlap)
      Completeness (Total or Partial Specialization)
•Inheritance.
•Hierarchies and Lattices
•Union Types (Categories)
               Semantic Data Models

Most common database management systems represent
information in a simple record-based format, semantic
modeling:
  provides richer data structuring capabilities for database
   applications
  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/Superclass


•   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)
         Specialization/Generalization
               Characteristics

•   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
        Specialization/Generalization
          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
        Specialization/Generalization
                 Constraints

•   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
                   disjoint
•   Completeness Constraint:
    - Total: Every entity in superclass must be a member of
        some subclass (e.g.\{HOURLY\_EMPLOYEE,
        SALARIED\_EMPLOYEE\}
        Specialization/Generalization
            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
                                    (contd.)

•   Shared Subclass: A subclass with more than one
    superclass
•   Multiple Inheritance: A shared subclass inheriting
    attributes and relationships from multiple (super)
    classes
           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
    superclass
•   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
  approach
 Object class identification is recognized as a difficult
  process requiring a deep understanding of the application
  domain
 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
   constraint
  Method                 Procedure
  Message                Procedure call
          Object-Oriented Data
            Model Example
                                                          Company                 Person
                                                          Name                    Name
                   Vehicle                                Location                Birthday
                   Serial#                                Contact Name
                   Weight
                   Wheelbase
                   Manufacturer                           Auto Company
                                                          Allocation
                                                          Total Sales


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

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
          (UML)
         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
graphically?

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


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
 languages
Include ideas from other modeling languages
Incorporate industry best practices
Address contemporary software development
 issues
  scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different
 processes
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
   hardware
  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
 modeling
Structural Modeling: Core
Elements
Structural Modeling: Core
Elements (cont’d)




¹ An extension mechanism useful for specifying structural elements.
Structural Modeling: Core
Relationships
Structural Modeling: Core Relationships
(cont’d)
 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
Kinds
  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
 relationships.
kinds
  class diagram: classifier view
  object diagram: instance view
Classes




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




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




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




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




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




         Fig. 3-29, UML Notation Guide
Associations




        Fig. 3-40, UML Notation Guide
Association Ends




        Fig. 3-41, UML Notation Guide
Ternary Associations




        Fig. 3-44, UML Notation Guide
Composition




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




        Fig. 3-45, UML Notation Guide
Generalization




        Fig. 3-47, UML Notation Guide
Generalization




       Fig. 3-48, UML Notation Guide
Dependencies




       Fig. 3-50, UML Notation Guide
Dependencies




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




          Fig. 3-52, UML Notation Guide
Objects




          Fig. 3-38, UML Notation Guide
Composite objects




       Fig. 3-39, UML Notation Guide
Links




        Fig. 3-46, UML Notation Guide
Constraints and
Comments




       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].

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:10
posted:8/30/2011
language:English
pages:68