0025-0028

Previous Table of Contents Next

Page 25

CHAPTER 2

What Is an RDBMS?

IN THIS CHAPTER

  • The Relational Database Model 26
  • RDBMS Components 30
  • Nonprocedural Data Access (SQL) 32
  • Databases and the Web 33

Page 26

In recent years , database management systems (DBMS) have established themselves as the primary means of data storage for information systems ranging from large commercial transaction processing applications to PC-based desktop applications. At the heart of most of today's information systems is a relational database management system (RDBMS). RDBMSs have been the workhorse for data management operations for more than a decade and continue to evolve and mature, providing sophisticated storage, retrieval, and distribution functions to enterprise-wide data processing and information management systems. Compared to file systems, relational database management systems provide organizations with the capability to easily integrate and leverage the massive amounts of operational data into meaningful information systems. The evolution of high- powered database engines such as Oracle7 has fostered the development of advanced "enabling" technologies, including client/server, data warehousing, and online analytical processing, all of which comprise the core of today's state-of-the-art information management systems.

Let's examine the components of the term relational database management system. First, a database is an integrated collection of related data. Given a specific data item, the structure of a database facilitates the access to data related to it, such as a student and all of his registered courses or an employee and his dependents. Next, a relational database is a type of database based in the relational model; non-relational databases commonly use a hierarchical, network, or object-oriented model as their basis. Finally, a relational database management system is the software that manages a relational database. These systems come in several varieties, ranging from single- user desktop systems to full-featured , global, enterprise-wide systems, such as Oracle7.

This chapter discusses the basic elements of a relational database management system, the relational database, and the software systems that manage it. Also included is a discussion of nonprocedural data access. If you are a new user of relational database technology, you'll have to change your thinking somewhat when it comes to referencing data nonprocedurally.

The Relational Database Model

Most of the database management systems used by commercial applications today are based on one of three basic models: the hierarchical model, the network model, or the relational model. The following sections describe the various differences and similarities of the models.

Hierarchical and Network Models

The first commercially available database management systems were the CODASYL type, and many of them are still in use with mainframe-based COBOL applications. Both network and hierarchical databases are quite complex in that they rely on the use of permanent internal pointers to relate records to each other. For example, in an accounts payable application, a vendor record might contain a physical pointer in its record structure that points to purchase order records. Each purchase order record in turn contains pointers to purchase order line-item records.

Page 27

The process of inserting, updating, and deleting records using these types of databases requires synchronization of the pointers, a task that must be performed by the application. As you might imagine, this pointer maintenance requires a significant amount of application code (usually written in COBOL) that at times can be quite cumbersome.

Elements of the Relational Model

Relational databases rely on the actual attribute values as opposed to internal pointers to link records. Instead of using an internal pointer from the vendor record to purchase order records, you would link the purchase order record to the vendor record using a common attribute from each record, such as the vendor identification number.

Although the concepts of academic theory underlying the relational model are somewhat complex, you should be familiar with some basic concepts and terminology. Essentially, there are three basic components of the relational model: relational data structures, constraints that govern the organization of the data structures, and operations that are performed on the data structures.

Relational Data Structures

The relational model supports a single, "logical" structure called a relation, a two-dimensional data structure commonly called a table in the "physical" database. Attributes represent the atomic data elements that are related. For example, the customer relation might contain such attributes about a customer as the customer number, customer name , region, credit status, and so on.

NOTE
In relational database design literature, you might see a relation denoted as Relation(attribute1, attribute2, . . .) with the name of the relation followed by the attribute list enclosed in parentheses.
Customer(Customer_ID, Customer_Name, Region, . . .)

The actual data values for the attributes of a relation are stored in tuples, or rows, of the table. It is not necessary for a relation to have rows in order to be a relation; even if no data exists for the relation, the relation remains defined with its set of attributes. Figure 2.1 illustrates the basic elements of the customer relation.

Key Values and Referential Integrity

Attributes are grouped with other attributes based on their dependency on a primary key value. A primary key is an attribute or group of attributes that uniquely identifies a row in a table. A table has only one primary key, and as a rule, every table has one. Because primary key values are used as identifiers, they cannot be null. Using the conventional notation for relations (shown in the note), an attribute is underlined to indicate that it is the primary key of the relation. If a primary key consists of several attributes, each attribute is underlined.

Page 28

Figure 2.1.
The basic components
of a relation.

You can have additional attributes in a relation with values that you define as unique to the relation. Unlike primary keys, unique keys can contain null values. In practice, unique keys are used to prevent duplication in the table rather than identify rows. Consider a relation that contains the attribute, United States Social Security number (SSN). In some rows, this attribute may be null because not every person has an SSN; however, for a row that contains a non-null value for the SSN attribute, the value must be unique to the relation.

Linking one relation to another typically involves an attribute that is common to both relations. The common attributes are usually a primary key from one table and a foreign key from the other. Referential integrity rules dictate that foreign key values in one relation reference the primary key values in another relation. Foreign keys might also reference the primary key of the same relation. Figure 2.2 illustrates two foreign-key relationships.

NOTE
Many database design tools use underlines to denote primary keys in diagram and report views. Depending on the tool that you use, you might also see (PK) and (FK) next to attributes to denote primary and foreign keys, respectively.
NOTE
You will notice frequent references to the DEPT and EMP sample tables throughout Oracle documentation. You can find these tables along with other sample database objects in Oracle's standard demonstration account. You usually access the account with the username/password combination scott/tiger.
Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net