Advanced Database Design

1
Advanced Database Design

• David Nelson
• October 2002

2
Contents

• Database Design Techniques
• Database Application Lifecycle
• Relational Data Modelling
• Advanced Data Modelling
• Object Data Modelling
• Summary
• Further Reading

3
Database Design Techniques

• Database Design is a well established technique
  particularly for relational systems
• Database Application Lifecycle includes three
  database design stages
• Conceptual
• Logical
• Physical

4
Database Application Lifecycle
5
Design Stages

• Conceptual Design
• The Process of constructing a model of the
  information used in an enterprise, independent of
  all physical considerations
• Logical Design
• The process of constructing a model used in an
  enterprise based on a specific data model, but
  independent of a particular DBMS and other
  physical considerations
• Physical Design
• The process of producing a description of the
  implementation of the database on secondary
  storage it describes the storage structure and
  access methods used to achieve efficient access
  to the data

6
Relational Data Modelling

• Lifecycle maps well into designing a relational
  system
• Tools available
• E-R model - map conceptual into logical
• entities identify relations
• relationships (11, 1N, M1) identify PKlt-gtFK
  dependencies
• MN relationships identify further relations
• Result is normally a set of normalised relations

7
Advanced Data Modelling

• But this system does not fit object modelling
• do not need to separate conceptual/logical design
  stages in OO design
• Poor expressiveness of relational model
  semantic gap
• Basic E-R model is inadequate for representing
  more complex associations, e.g.
• inheritance hierarchies
• Aggregation, e.g. is part of

8
Object Data Modelling

• Extended Entity Relationship modelling
• models inheritance hierarchies
• models aggregation
• But does not model behaviour
• can use DFDs, but model processes rather than
  object behaviour
• use object modelling technique such as UML

9
Design Stages

• Identify candidate objects in the system
• Refine objects
• selection of classes
• identification of relationships
• determine cardinality of relationships
• classification of relationships
• identify attributes
• identify operations
• Revision of attributes and classes

10
Object Identification

• Identify the candidate objects
• Some of which will be selected for implementation
• Potential sources
• things, or tangible things
• people
• roles
• organisations
• concepts
• events or processes
• places or locations

11
Object Identification

• Description of an organisation is output from a
  previous stage, gained in various ways
• observing the organisation working
• interviewing individuals concerned with the
  organisation and the future object database
  system
• inspecting existing procedures and documentation
  within the organisation
• surveying experts and existing solutions to the
  problems the ODB is to address
• utilising other information already known by the
  designers
• Usually description is in natural language

12
Object Identification

• Objects should be grouped to determine sets of
  classes which characterise the candidates
  (candidate classes)
• remove/refine objects which are too general/too
  specific
• remove redundant objects
• identity is_a relationships
• refine groups into subgroups
• identify inter-group relationships
• Output is an outline class diagram showing
• selected objects
• important relationships between them (e.g. is_a,
  part_of)

13
Class Selection

• Aim is to select classes which will be
  implemented and determine their characteristics
• i.e. attributes, relationships and operations
• Need to identify classes to omit
• redundant classes
• irrelevant classes
• too vague

14
Class Selection

• Need to ensure effectively using hierarchies
• Are classes too high/low a level of abstraction
• are the extents under populated
• are subclasses and superclasses different
• are there superclasses without instances
• does addition of a subclass improve the object
  database querying capabilities
• abstract objects are sometimes more important
  that tangible (real world) objects

15
Relationships

• Guidelines
• analyse verbs - provide good indicators of
  relationships between objects, and of potential
  attributes
• is_a - specialism
• aggregation, e.g. is made up, is a part of, is
  composed of
• has - may indicate relationships or attributes
• need to distinguish
• Identify cardinalities

16
Attributes

• The facts or things that are known about an
  object that cant be represented by relationships
  to other objects
• totally dependent on the object for example
  date_of_birth is meaningless if person does not
  exist

17
Operations

• Can be used to represent
• derived attributes, e.g. age
• behaviour of the entity represented by an object,
  e.g. paying an employee
• Can use state diagrams for each class
• Also use object interaction diagrams

18
Revision of Attributes and Classes

• Attribute identification may identify changes to
  design
• revise classes
• Design is an iterative process

19
Summary

• Object database design does not need to be split
  into conceptual and logical stages
• E-R and EER modelling are inadequate as they do
  not model operations and behaviour
• UML is an evolving design model

20
Further Reading

• Eaglestone and Ridley, Object Databases An
  Introduction, McGraw Hill
• chapter 8 provides an example of using UML for
  designing an object database from a text
  description
• Any good book on UML!
• Blaha, Premerlani, OO Modelling and Design for Db
  Applications - a whole book on DB Design, uses UML