Databases Reference
In-Depth Information
7.
Dynamic sparse matrix handling.
Missing data should be handled correctly and efficiently and
not affect the accuracy or speed of data retrieval.
8.
Multiuser support.
OLAP software must provide secure, concurrent retrieval of data. Because you
don't update a data warehouse when you're using it, concurrent update is not an issue; so prob-
lems of security and access are less difficult than in an OLTP environment.
9.
Unrestricted, cross-dimensional operations.
Users must be able to perform the same opera-
tions across any number of dimensions. For example, you should be able to ask for statistics based
on the dimensions of time, location, and part just as easily as you would ask for statistics based
on the single dimension of location.
10.
Intuitive data manipulation.
Users should be able to act directly on individual data values with-
out needing to use menus or other interfaces. Of course, these other interfaces can be used, but
they should not be the required method of processing.
11.
Flexible reporting.
Users should be able to retrieve data results and view them any way they want
for analysis.
12.
Unlimited dimensions and aggregation levels.
OLAP software should allow at least 15 data
dimensions and an unlimited number of aggregation (summary) levels.
299
Organizations use relational databases to store and access data consisting of text and numbers. Additionally,
some organizations store and access graphics, drawings, photographs, video, sound, voice mail, spread-
sheets, and other complex objects in their databases. RDBMSs store these complex objects using special data
types, generically called
binary large objects (BLOBs)
. Some applications, such as computer-aided design and
manufacturing (CAD/CAM) and geographic information systems (GIS), have as their primary focus the stor-
age and management of complex objects. For these systems, many companies use object-oriented DBMSs.
The relational model, which has a strong theoretical foundation, is the foundation for RDBMSs. Although
object-oriented DBMSs do not have a corresponding theoretical foundation, they all exhibit several common
characteristics. Central to all object-oriented systems is the concept of an object. An
object
is a set of related
attributes along with the actions that are associated with the set of attributes. A customer object, for example,
consists of the attributes associated with customers (number, name, balance, and so on) together with the
actions that are associated with customer data (add customer, change credit limit, delete customer, and so on).
In relational systems, you create the actions as part of data manipulation (in the programs that update
the database), rather than as part of the data definition. In contrast, in object-oriented systems, you define the
actions as part of the data definition and then use the actions whenever they are required. In an object-
oriented system, the data and actions are
encapsulated
, which means that you define an object to contain both
the data and its associated actions. Thus, an
object-oriented database management system (OODBMS)
is a
database management system in which data and the actions that operate on the data are encapsulated into
objects.
To become familiar with OODBMSs, you should have a general understanding of the following object-
oriented concepts: objects, classes, methods, messages, and inheritance.
To understand the distinction between objects and classes, you will examine an object-oriented representa-
tion of the following relational model representation of the Premiere Products database.
Rep (RepNum, LastName, FirstName, Street, City, State, Zip, Commission, Rate)
Customer (
CustomerNum
, CustomerName, Street, City, State, Zip, Balance, CreditLimit, RepNum)
Orders (OrderNum, OrderDate, CustomerNum)
OrderLine (
OrderNum
,
PartNum
, NumOrdered, QuotedPrice)
Part (PartNum, Description, OnHand, Class, Warehouse, Price, Allocated)
