Object Relational database management system

download Object Relational database management system

of 48

  • date post

    17-Jan-2016
  • Category

    Documents

  • view

    12
  • download

    0

Embed Size (px)

description

Object Relational database management system

Transcript of Object Relational database management system

  • 8 OBJECT DATABASE DESIGN This chapter discusses how object databases are designed. The area of objectoriented systems design is very large and a complete treatment would require a book on its own. The chapter therefore concentrates on the parts specific to database design. The methods described are illustrated using the Bruddersfield Bikes case study, introduced in previous chapters, and located in the broader context of objectoriented design. The chapter describes a topdown design method based upon entity analysis, and uses the Unified Modeling Language (UML) to represent the design. Section 8.1 sets the scene by introducing objectoriented design methods, and comparing these with other database design methods. One specific method is then described in detail by working through some of the design stages for the Bruddersfield Bikes object database. The method is overviewed in Section 8.2. The individual stages are then described in greater detail. Section 8.3 discusses the first phase in which the problem area is analysed to identify candidate objects and classes. Sections 8.4 and 8.5 discuss refining objects and then revising attributes and classes. Finally, Section 8.6 gives a summary. 8.1 OBJECTORIENTED DESIGN METHODS There are a number of different objectoriented methods for design, aimed at programming or software development in general, not specifically for databases (although this is not excluded and may be explicitly included in some cases). Important amongst them are the methods associated with Booch [Booch 94] (the Booch method), Rumbaugh [ Rumbaugh 91] (OMT), and Jacobson [Jacobson 92] (OOSE). These methods were developed independently and had different names

    ____271____

  • ______________OBJECT DATABASES: AN INTRODUCTION _____________

    ____272____

    for similar concepts and different ways of representing comparable parts of the design process in diagrams. Starting in 1996 a process of unifying these methods is now underway to produce what was first known as the Unified Method (UM) and is now called the Unified Modeling Language (UML). It is planned that the UML will be submitted to the OMG as the basis for a standard in this area. UML does not prescribe the design process, but instead provides a diagrammatical language for representing the analysis and design of an objectoriented system. WHY IS UML IMPORTANT? In the past, the objectoriented field has been plagued by terminological differences. The same, or very nearly the same, thing has been known by different names, and the same words have had different meanings in some methods. This is true of objectoriented programming languages as well as design methodsfor instance, the implementation of operations on object instances are called methods and operations in different systems. (A guide to differences between objectoriented design notations can be found in the Unified Method Documentation Set [Booch 95, Notation Summary p 47].) The confusion of terminology is a consequence of the manner in which objectoriented technology has evolved. Unlike second generation (relational) database technology, objectoriented technology does not have a single, widely accepted, underlying data model or system and language standards. The variety of conflicting terminologies therefore reflects the various routes by which the technology has emerged. The lack of a consensus terminology for objectoriented systems can be confusing for the newcomer (or even those with plenty of experience). It also obscures the common features across different systems and makes it harder to transfer experiences. Hopefully with the emergence of the UML some of these problems will be overcome. If widely accepted as a standard, UML will provide a single terminology and diagrammatical language for expressing and communicating design ideas for objectoriented systems. TYPES AND CLASSES In this chapter, and the book generally, we try to conform to the conventions of the UML, which is still under development. One

  • _____________________OBJECT DATABASE DESIGN____________________

    important thing to note is that the UML, like many objectoriented design methods, does not make the distinction we have between types and classes. These terms are distinct in the Object Data Model: 1) Type refers to the interface specification for objects of a certain kind.

    Type therefore specifies how the external characteristics of objects of this type will appear to other objects, but says nothing about how that will be implemented. In fact a type may have many implementations, for example a Java implementation and a Smalltalk implementation. These would include sets of methods in those languages which give the object the same external appearance but via different pieces of code.

    2) Types may be classes or interfaces. Instances can be defined on classes but not on interfaces.

    3) Implementation class refers to a type and its implementation. Objectoriented design normally refers only to classes, since the aim is a plan of how to implement a design in a real systemthe term type is not often used in objectoriented design material. Generally, types and classes are regarded as synonymous e.g. [Booch 94, p 65]. Thus our discussions will be of determining the objects in a system and what classes are used to represent them. TWOPHASE DATABASE DESIGN Conventionally, database design proceeds in two stages (see Figure 8.1): 1) Data analysisthe purpose of this stage is to model the part of the

    world relevant to the database (its Universe of Discourse (UoD)) as a collection of abstractions. The result of data analysis is a conceptual model which represents the types of information to be represented within the database.

    2) Data designthe purpose of this stage is to derive an implementation of the conceptual model using the data model supported by the DBMS that is to be used. The output from this phase is a logical model of the UoD that can be implemented directly by the database technology being used.

    The second phase, data design, has been necessary because of the poor expressiveness of data models. Having determined the information that

    ____273____

  • ______________OBJECT DATABASES: AN INTRODUCTION _____________

    the designer would like to express within a database (the conceptual model), she then must express as much of this information as is possible within the limited set of abstractions supported by the DBMS. If for example, a relational DBMS is used, then the conceptual model must be transformed into a set of tables in the data design stage. The difference between what can be expressed in the logical model and what the designer wishes to express (in the conceptual model) is sometimes referred to as the semantic gap.

    Universe of Discourse Real world phenomena: people, places, things, ideas, processes, ... Abstractions of type of real world phenomena: entities, attributes, relationships. Database representations of information: classes, types, ...

    Data Analysis

    Data Design

    Conceptual Model

    Logical Model

    Figure 8.1 Twophase database design When a relational DBMS is used, a further database design phase is normalisation, whereby the logical model is refined so as to remove any unnecessary duplication of data. Redundant data is undesirable partly because it may give rise to inconsistencies within the database when data is inserted, modified, or deleted (see [Eaglestone 91]). However, normalisation is necessary only to overcome problems caused by the restricted modelling capabilities of the relational data model. The above process concerns only the logical structure of the database. Physical database design is a further process by which implementations of the database structures in the logical model are designed, such that the system has sufficient performance within the available hardware and software resources.

    ____274____

  • _____________________OBJECT DATABASE DESIGN____________________

    The data model used for representing the conceptual model is of a type called a semantic data model. Semantic data models represent the meaning of data using different abstractions for different types of real world phenomena. The most widely used has been the entity relationship model [Chen 76] which, as its name suggests, supports different abstractions for entities, their attributes, and relationships between them, including aggregation (i.e., where one entity is a part of another) and is_a relationships (i.e., where one entity is a specialisation of another). OBJECT DATABASE DESIGN The Object Data Model has sufficient expressiveness to implement semantic data models directly. Specifically, the Object Data Model explicitly supports the three main types of abstractions also supported in the entity relationship model entities (as classes), relationships, and attributes. The data design stage therefore becomes redundant for object database design, since the Object Data Model can itself serve as the semantic data model for the conceptual model (see Figure 8.2).

    Universe of Discourse Real world phenomena: people, places, things, ideas, processes, ... Abstractions of type of real world phenomena, entities, attributes, relationships, for implementation as classes

    Data Analysis Conceptual Model

    Data Design Figure 8.2 Object database design However, there is an extra dimension in designing an object database that does not exist for previous generations of database technology. That is, the designing of object behaviour. Accordingly, many object database design methods also analyse the changes to the states of objects and the interchange of messages between objects that can occur during an objects lifetime, in order to determine appropriate object operations.

    ____275_