Teorey J., Lightstone S., Nadeau T. Database Modeling and Design: Logical Design

Подождите немного. Документ загружается.

• Ad hoc query facility. In SQL, simple queries are very simple

to express. In typical programming languages, there is so

much bookkeeping stuff to do that a simple selection

could take many lines of code. Object-oriented databases

must somehow make it easier than this for users.

Optional features. These are features found in many

object-oriented database system implementations, and in

the minds of some people somehow associated with

object-oriented databases, but not accepted, at least by

the manifesto writers, as necessary for a system to call

itself an object-oriented database.

• Multiple inherit ance. T he type Square inh er its from

both the type Rhombus and t he type Rectangle. There

are many diffi cult issues that ar ise, not the least of

which is what precisely is inherited, particularly when

there are dif ferences between the p arent types (Rhom-

bus and Rectangle, respectiv ely) in their attributes and

methods.

• Type checking and type inferencing. Type checking is

where the system uses its knowledge of the functionality

of declared types to catch programming errors. For

example, multiplication is meaningless for strings, so

there is a type error if we write a¼b*c, where b and c

are strings. (Of course, this would have been a fine thing

to say if b and c were integers.) Type inferencing is when

the programmer does not declare the type in advance,

and the system determines this by seeing what oper-

ations are invoked. For example, seeing the characters

23, the system may not know whether to interpret these

as the string 23 or the number twenty-three. If it sees a

statement such as a¼23*2, then it knows 23 couldn’t

have been a string—it must be an integer.

• Distribution. Whether a database is centralized or dis-

tributed has nothing to do with object orientation. That

this property is even mentioned is a historical artifact.

• Design transactions. Another historical artifact on

account of the fact that at the time object-oriented sys-

tems were being developed, researchers were also

studying systems that effectively supported long-lived

transactions, such as those executed by human designers.

(Traditional database transactions are optimized for

short transactions.)

152 Chapter 8 OBJECT-RELATIONAL DESIGN

• Versions. This is yet another historical artifact. When

human design is involved, it is often useful to keep mul-

tiple versions of objects around.

Open features. Finally, with a view to being inclusive,

the manifesto explicitly left completely open the choice of:

• Programming paradigm—for example, imperative,

logical, or functional.

• Representation system. What the atomic types are, from

which more complex object types are built.

• Type system. Many different techniques have been

proposed for the definition of new types.

• Uniformity. The question is whether metadata is uni-

formly treated as a first-class object in the same way

as data. Is a type an object? Is a method itself an object?

Object-Relational Databases

Relational databases had the lion’s share of the market

at the time object-oriented databases were created. In a

very successful defensive move, relational database

vendors scrambled to add object-oriented concepts to rela-

tional databases, thereby undercutting the market poten-

tial for object-oriented databases even before they had a

chance to mature and become a market threat. The

resulting products were not fully object-oriented. In fact,

retaining the basic relational look and feel, as well as full

compatibility with the pure relational databases in wide

use, was a priority. In consequence, these databases were

called object-relational.

User-Defined Functions and Abstract Data

Types

A central feature that object-relational systems add to

relational databases is the notion of an abstract data type.

Traditional databases have a small set of predefined types

(such as integer, date, double precision, etc.). An abstract

data type (ADT) permits a complex object class to be

defined as a database type. Instances of this data type

can then be stored as attribute values in a table column

of which the type has been defined as this ADT.

Chapter 8 OBJECT-RELATIONAL DESIGN 153

Storing a complex object as an attribute value limits the

database to treating the object as an uninterpreted set of

bits. But we may want the database to access components

of the object. For example, we may wish to perform a

selection based on the value of an attribute of the object.

Or perhaps we want to define a sort order on the objects.

For the database to be able to accomplish these tasks, user-

defined functions are introduced. These are functions

defined by the user, as the name suggests, rather than by

the database system, and may be invoked during query

processing. User-defined functions are invaluable in the

manipulation of abstract data types, but they may be of

use even otherwise. For example, we may wish to represent

a yearly revenue attribute as the summation of four quar-

terly revenue attributes for every product class. The yearly

revenue is clearly a redundant attribute. Nonetheless, one

can imagine scenarios where we would want to store this

explicitly, whether in the same table as the quarterly revenue

or in a separate yearly revenue table (one row per product

class in either case). A user-defined function could be used

to compute the yearly revenue from the quarterly revenues,

even though all fields involved are of type integer.

Support for user-defined functions in database systems

introduces several challenges. The first involves security—

poorly written code could corrupt the database. Database

system builders have to take precautions to protect against

this. Most systems perform a careful balancing act between

giving users unfettered ability to do what they need to and

preventing them from doing harm. The second challenge is

performance—the database system may not know how long

any user-defined function will run. This makes it difficult to

perform the usual query optimization that is so important

for database performance. Most database systems request

hints from users regarding the expected runtimes of user-

defined functions, and make conservative assumptions

where this information is not available.

An Evaluation of Object-Relational Systems

A relational database with user-defined functions and

abstract data types is called object-relational. Note that

such a database does not provide true object orientation.

In particular, the type system for abstract data types could

154 Chapter 8 OBJECT-RELATIONAL DESIGN

be limited with respect to what a full-fledged programming

language provides. Certainly, we do not have notions

such as late binding. Furthermore, there is no notion of

object identity.

In spite of these limitations, object-relational systems

are in wide use today, and most experts generally agree

that the relational database vendors have successfully

fended off competition from object-oriented database sys-

tems by providing enough object-oriented functionality to

satisfy most users. Some functionality not provided can

be simulated. For example, object-relational systems do

not have a notion of object identity, as mentioned above.

However, relational database systems do have a notion of

identifier key in many relational tables—for example, a

Student table will have a student_id field as the primary

key, an Employee table will have employee_id as the pri-

mary key, and so forth. These ID fields are visible to the

user, but in effect serve the role of “object identifiers” for

the object represented by the record. While the user could

manipulate these fields, we do not expect the user to

manipulate them, and in this way we weakly achieve the

desired identifier behavior.

Design Considerations

When objects are stored in a relational database, there

are many choices with regard to how this is done, as

discussed above. With abstract data types, we have even

more options. At one extreme, we could encapsulate the

entire object and store it as a single attribute of a suitable

abstract data type. At the other extreme, each part of the

object can be its own attribute, and each object will then

correspond to a record (or even multiple records, if there

are nested objects or repeated attributes). The advantage

of the former is that all of the member functions (or met-

hods) associated with the object class can still be used.

Some or all of them can even be registered as user-defined

functions and made available to be called within the data-

base. However, what these functions do, and what the

values are for individual component attributes in the

object, are all not visible to the database, and hence can

only be used in limited ways when processing queries.

In contrast, the latter design exposes all components of

Chapter 8 OBJECT-RELATIONAL DESIGN 155

the object to the database, making it possible to query on,

and return, parts of objects. The disadvantage is that there

is no longer an integral object on which the original object

member functions (or methods) can be run. Rather, new

user-defined functions must be created to mimic the

object methods that we wish to retain.

Sometimes, objects can be very large. This is particu-

larly true when they contain multimedia content. One

facility relational databases provide is that of “large

objects.” The idea is simply to have a database type for

a large collection of bits that the database system does

not attempt to interpret. This interpretation is left to some

external application. Such objects are often called binary

large objects (or BLOBs).

Figure 8.5 sho

ws an example of a “mixed object size”

table that may be created by the radiology department in

a hospital. Each record has several small attributes, such

as patient ID, date of X-ray, etc. In addition, there are two

unusual fields: one, with radiologist’s notes, is large, per-

haps a few kilobytes; the second is very large, several

megabytes, and contains the radiological image. A typical

design in such cases is to place the text report and the

image into a separate storage area. This figure shows two

ways of accomplishing this partitioning. In Figure 8.5(a),

an image ID and a note ID are used (as foreign keys) in

the table at hand. A separate image table (not shown

in the figure) is created, with the image ID as the key.

Similarly, a separate notes table is also created. In

Figure 8.5(b), notes and images are stored in files outside

Patient Body Part Date Time Radiologist Notes Image

P2345 Knee Feb 2, 2011 3.45 p.m. R2 N5 I5

P1278 Wrist Aug 11, 2010 9.20 a.m. R2 N7 I7

(a)

Patient Body Part Date Time Radiologist Notes Image

P2345 Knee Feb 2, 2011 3.45 p.m. R2 a.txt a.bmp

P1278 Wrist Aug 11, 2010 9.20 a.m. R2 b.txt b.bmp

(b)

Figure 8.5 An example of a

“mixed object size” table:

(a) an image ID and note ID

are used as foreign keys,

and (b) notes and images

are stored in files outside

the database system.

156 Chapter 8 OBJECT-RELATIONAL DESIGN

the database system. File names are recorded in the data-

base to match images and notes with patient, date, etc.

Large object attributes have special design considerations.

Usually

, in a relational database, the unit of manipulation is

the record. When a selection is performed, the entire record

is retrieved, even if only some attributes of the record

are actually required for display or downstream processing.

If the discarded attributes are small, the additional cost of

retrieving the entire record is not large. However, when

there is a large attribute, it is extremely wasteful to retrieve it

only to discard it. Furthermore, standard relational data-

base backend processing is designed on the assumption

that many records fit on a page. Some operations, such as a

relational scan, can become extremely expensive if the

record is very large.

To address this challenge we can separate the large

object from the database record and store it separately.

One way to do this is to have a file for each large object,

and store the file name in the record. In this way, the size

of the record is greatly reduced, and the large object is

fetched only when it is required. The disadvantage is that

the large object is no longer managed in the database. In

consequence, for example, transactional consistency

guarantees no longer apply to data in the large object.

In summary, there is a choice of placing large objects in

the table or putting them in a separate file. The larger the

object, the greater the cost of having it be part of the record.

At some size, it becomes preferable to store it separately,

even though such separation introduces its own issues.

Recognizing this trade-off, modern database systems

often provide facilities to store each BLOB-valued attribute

separately from the rest of the record it is part of. This is a

form of vertical partitioning of the table. Note that the

BLOB partition only has a single attribute, and even the

table key is not replicated. This is really a second-class par-

tition, linked from the main partition that has the rest of

the table. Since the BLOB is not interpreted by the data-

base, there is no possibility of an index.

Thus far we have considered two extremes: full-fledged

objects that are managed by the database system, and BLOBs

that are left completely uninterpreted. Some systems also

provide facilities at an intermediate point, in the form of

Chapter 8 OBJECT-RELATIONAL DESIGN 157

character large objects (or CLOBs). Here, the database system

knows that the large object is a string of characters. As

such, functions can be provided to process these character

strings. However, any additional structure within the CLOB

is not visible to the database system. For example, if a long

book (or an XML document) is stored as a CLOB, the database

system will know about the character strings in the docu-

ment, but nothing about its paragraphs or sections.

Summary

Object orientation is a popular programming paradigm,

and is widely used in modern programs. Central features of

object-oriented systems include inheritance, identity,

encapsulation, and abstraction. Objects bear some resem-

blance to entities in an ER model. For example, both

objects and entities have attributes. Entities participate in

relationships while objects have links to other objects.

The notion of types (or classes) is central in object-

oriented systems. Each object has a type, and is considered

an instance of its type.

Typical database systems are relational and not object-

oriented. This results in an “impedance mismatch” as data

is moved between tables in a relational database and

objects in the application program. Considerable effort

can be spent in marshalling arguments and moving data

between the two.

Object-oriented database systems have been proposed

as a means for addressing this mismatch by having the

database system explicitly designed to support objects

with links. There are many technical challenges in this

regard, not the least of which is how to translate between

in-memory pointers and disk pointers transparently when

the respective address spaces are different, as are the space

requirements for a pointer. One common solution to this

particular problem is known as pointer swizzling.

There are many flavors of systems that try to marry

concepts from object orientation and databases. These run

the gamut from persistent programming languages

to object-relational systems. There is no formal definition of

what precisely is an object-oriented database system. How-

ever, there is a widely accepted manifesto jointly written by

158 Chapter 8 OBJECT-RELATIONAL DESIGN

several leaders in the field that lays out the defi-

ning characteristics of an object-oriented database system.

Rather than build an object-oriented database, one

could also attempt to manage better the mismatch

between object-oriented systems and relational databases.

Toward this end, relational database systems have added

some object management capabilities, including support

for large objects, user-defined functions, and abstract data

types. In parallel with these efforts, there are also many

tools that simplify and automate the task of storing object

data in a relational database.

Tips and Insights for Database

Professionals

Tip 1. Understand the respective strengths and weak-

nesses of object-oriented programming systems and

of relational databases. The former are computationally

complete, have sophisticated type management, and

often better match the user view of the world; the latter

are easier to manipulate in bulk, are easier to scale

efficiently, and provide superior support for concurrency.

Tip 2. Recognize that most commercially available

database systems today are object-relational in that

they are not only relational databases, but also have

at least some support for objects.

Tip 3. Exploit the complementary strengths of rela-

tional and object-oriented technology in designing

your application flow. Since there remains an imped-

ance mismatch, you will need to pay attention to make

sure you are not crossing the boundary between the

two more often than you need to.

Tip 4. Use commercial object-relational mapping

software to simplify your life and better manage the

impedance mismatch.

Literature Summary

Object-oriented programming as a concept was first

described in the context of the Smalltalk language by

Goldberg (1983), though earlier uses of the object concept

in programming can be found, for example, in Simula 67

Chapter 8 OBJECT-RELATIONAL DESIGN 159

(see Kirkerud, 1989). Today, the Object Management Group

(www.omg.org) serves as

a central clearinghouse for infor-

mation related to object orientation. Among other things,

they also specify the standard for UML (www.uml.org).

There were many independent efforts at introducing

some

features of

object orientation to databases and some

features of persistence to programming languages. The

Object-Oriented Database System Manifesto (see Atkinson

et al., 1989) brought the community together to define the

key characteristics of an object-oriented database. Over the

next several years, a group called the Object Data Manage-

ment Group carefully defined the standard, and published

a book by Cattell (2000). A current portal for information

on object-oriented databases is www.odbms.org.

160 Chapter 8 OBJECT-RELATIONAL DESIGN

XML AND WEB DATABASES

CHAPTER OUTLINE

XML 161

Background 161

Definitions in XML 163

XML Design 168

Schema Design 168

Text 173

XML Data in an RDBMS 176

Web-Based Applications 178

An Overview of HTTP 178

Resources 180

Dynamic Pages 182

Website Structure 184

Summary 185

Tips and Insights for Database Professionals 186

Literature Summary 186

TheeXtensibleMarkupLanguage(XML)hasbecomeavery

popu

lar way to repr esent

data and transfer it between systems.

XML also underlies many important Web technologies, and

therefor e is important when we consider the use of databases

in the context of the Web . We begin this chapter with a quick

overview of XML in the first section. W e then discuss XML data-

basedesigninthesecondsection.Weconclude,inthethird

section, with a discussion of Web-based database applications.

XML

Background

Whenever two parties have to share information, they

have to agree on how this information is to be represented.

161