0003-0006

Previous Table of Contents Next

Page 3

CHAPTER 1

Oracle Company Overview

IN THIS CHAPTER

• Databases Before Oracle 4
• The Birth of Oracle 5
• The Relational Database Wars A Never-Ending Story 6
• Oracle Today and Tomorrow 7
• Oracle's New Baby: Network Computing Architecture 8
• CORBA 11
• Introducing the Cartridge 13
• The Universal Data Server 14
• The Oracle Alliance 14
• Oracle Support 16
• The Oracle Developer Programme 20
• Back to School: Oracle Education 20
• Oracle Consulting 22
• Oracle Sales 23
• Oracle on the Web 23

Page 4

Welcome to the land of Oracle. This chapter will help you understand the Oracle mindset and the company history that has created a subculture of programming and database professionals who look toward Oracle's headquarters in Redwood City as one might look toward Mecca.

Databases Before Oracle

Today we discuss, ponder, and pontificate on the nuances of relational databases and argue about which vendor's database is the best, but we forget that in the good old days, there were no relational databases. The good old days belonged to an era of punch cards and mainframes. Data was stored on magnetic tape reels. A database was really a room full of magnetic tape reels. Out of this backdrop arose two basic paradigms for the first databases: the hierarchical model and the network model.

The Hierarchical Database Model

The first paradigm was the hierarchical database. It grouped data in hierarchies of parent and child. A parent contained data, and each data element had related child data. For instance, customer data was a parent to sales data because each customer created a sales record whenever he or she shopped.

Figure 1.1 illustrates how data was described in a hierarchical database. You might have customer and sales data on magnetic tape reels, and for each time the customer reel spun, the sales tape spun back and forth, gathering all the "child" sales for that customer. Later, of course, more of this work was done on disk, and hierarchical databases such as IBM's IMS actually became very fast.

Figure 1.1.
The hierarchical data
modeldata access is
defined by moving
along the parent/child
tree.

Page 5

The Network Database Model

The second paradigm was the network database, where data actually related to other data and did not need to be hierarchical (see Figure 1.2). For instance, a customer might live in a Zip code and there might be data on the Zip code. Instead of defining the Zip code as the parent of the customer, you simply linked it to the customer, yet this link was the only path you could follow to get combinations of your data.

Figure 1.2.
The network database
modeldata access is
defined by the pathways
that link your schema.

This paradigm might appear relational, but it was not. A major reason was that you could only query data using the defined relationships in your schema. Any new relationship meant changing the schema of the database. No mathematical definition for this method allowed any query within a broader scope outside of what was explicitly defined.

Relational Databases, So Help Me Codd

In 1970, a researcher named E.F. Codd wrote a series of papers that changed computer science forever. He proposed taking the basis of relational algebra, an area of mathematics, and making it a defining paradigm for writing database software. Although relational databases now seem obvious and straightforward, this initial leap of faith by Codd, followed by rigorous research, led to a method of writing database software that gave users a complete, theoretically infinite, set of operations they could perform on any relational database.

The original works on relational theory were abstract. For instance, in relational algebra, joining two tables R, S is expressed with syntax such as R[a = b]S or R[a < b]S. This concept is hardly intuitive or user -friendly for the business manager. The original papers by Codd didn't capture a lot of attention until IBM took an interest in this approach to databases. IBM saw the value of relational databases and created a series of design documents for a relational database called System/R and the relational language it called Structured Query Language, or SQL.

The Birth of Oracle

A young man named Lawrence Ellison happened to read the IBM papers on System/R and saw the universal applicability of the relational model. In 1977, he founded the Oracle Corporation. Oracle was able to deliver the first commercial relational database ever to reach the market

Page 6

in 1979. Not only was it relational, but it also used the language SQL, pronounced "sequel." The first version of Oracle, version 2.0, was written in assembly language for the DEC PDP-11 machine.

The differences between the early Oracle start-up and IBM were the factors that resulted in today's great proliferation of Oracle databases, or servers, and the less-than -spectacular sales of IBM's DB2. For one thing, IBM's major philosophy centered around hardware sales, so databases for it were only a way to enhance the value of a piece of hardware. On the other end of the spectrum, Oracle cared little about hardware and just wanted to sell databases. The result of this philosophy was Oracle's portability. As early as version 3.0, the database was written in the C language, a portable language.

Different hardware platforms such as DEC, HP, and Burroughs were attracting customers whom Oracle wanted. Oracle began to move its portable C-based database code to a variety of different vendors . Suddenly, Oracle had a portable relational database, and the sales of Oracle spread. At this time, many companies moved data to smaller mini-computers. Companies such as DEC and platforms such as the Motorola 6800-based UNIX machines began to prosper . All these new environments could offer Oracle as a relational database.

The Relational Database WarsA Never-Ending Story

Other vendors soon moved in on Oracle. Informix, Sybase, Ingres, and Unify, all located near the Silicon Valley area (as was Oracle), began to offer relational databases. What kept Oracle in the lead was that as the first vendor out of the gate, it had a richer and more stable SQL language. Oracle also began to offer a product that became SQL*Forms, which allowed users to quickly build screens and interfaces that hooked directly into Oracle's database. The SQL*Forms tool was like a virus from outer space when it hit corporate America: Thousands of Oracle-based applications sprung up all over the country. Oracle was growing fast!

The vendor that came closest to matching Oracle was Sybase, which offered a faster relational database in the mid-1980s for OLTP applications. Sybase focused on Sun Microsystems's UNIX RISC machine, which was replacing the DEC Micro-VAXes running Oracle databases. Unfortunately for Sybase, although its database was fast, it crashed a lot and had many bugs . The only industry that seemed to allow for this nuisance was the trading floors on Wall Street. For them, speed paid off, and they were fully committed to the Sun UNIX hardware.

Aside from Sybase, Informix is probably Oracle's closest competitor now, but in the early days of the relational wars, it struggled to move from a C-ISAM product for C programmers to a full-fledged relational database. Ingres, on the other hand, pushed a nonstandard relational language, QUELL, as superior to SQL. Because it was nonstandard, it was doomed to failure. Ingres then had to work fast to build a SQL parser, but it moved too late.

Previous Table of Contents Next