When you are in a big electronics
store buying the latest edition of the iPod, how does that store’s inventory tracking
system know you just bought an iPod and not, for example, a car stereo or a television?
Let’s walk through the process of buying an iPod and consider all the implications this
has on the inventory database that sits far underneath all the shiny, new gadgets on the
sales floor.When you hand the iPod box to the cashier, a barcode scanner reads the label
on the box, which has a product identification number. In barcode language, this
number might be something like 885909054336. The barcode acts as a unique identifier
for the product; in this case, all iPods that are the same model as the one passing across
the barcode reader have the same exact barcode.The barcode scanner relays the number
represented by the barcode to the register at the cashier’s station, which sends a request
(or a query) to the store’s inventory database. This database could be in the same store
as the register or somewhere across the country or even around the world, thanks to the
speed and reliability of the Internet.The register asks the database, “What are the name
and price of the product that has this barcode?” To which the database responds, “That
product is an iPod, and it costs $200.” You, the customer, pay your $200 and head home
with a new toy. Your work in the store is finished, but the inventory management system
still needs to reconcile your purchase with the database! When the sale is complete, the
register needs to tell the database that the iPod was sold. The ensuing conversation goes
something like the following. Register: “How many products with this barcode are in our
inventory?” Database: “1,472.” Register: “Now, 1,471 products with this barcode are in
our inventory.”Database: “OK.”
What Did the Database Do?
Data Retrieval
Of course, this is not the whole story. Much more happens behind the scenes than simple
conversational requests and acknowledgements.The first interaction the register had
with the database occurred when the request for the product name and price was
processed. Let’s take a look at how that request was really handled.If the database is an
SQL database, like MySQL or PostgreSQL or many others, then the request would be
transmitted in the standard Structured Query Language (SQL). The software running on
the register would send a query to the database that looks similar to the
following.SELECT name, price FROM products WHERE id = 885909054336;
This query instructs the database to look in the products table for a row (also called a
record) in which the id column exactly equals 885909054336.Every database may
contain multiple tables, and every table may contain multiple rows, so specifying the
name of the table and the row’s unique identifier is very important to this query.When
the database has successfully found the table and the row with the specified id, it looks
for the values in the name and price columns in that row. In our example, those values
would be “iPod” and “200.00”, as seen in Figure 2. The execution of the previous SELECT
statement, which extracts those values from the table.
Database
Systems Early Databases In the 1960s, the System Development
Corporation, one of the world’s first computer software companies and a significant
military technology contractor, first used the term “data base” to describe a system to
manage United States Air Force personnel. The term “databank” had also been used in
the 1960s to describe similar systems, but the public seemed less accepting of that term
and eventually adopted the word “database”, which is universally used today A number
of corporations, notably with IBM and Rockwell at the forefront, developed database
software throughout the 1960s and early 1970s. MUMPS (also known as M), developed by
a team at Massachusetts General Hospital in the late 1960s, was the first programming
language developed specifically to make use of database technology.In 1970, the
relational database model was born. Although this model was more theoretical than
practical at the time, it took hold in the database community as soon as the necessary
processing power was available to implement such systems.The advent of the relational
model paved the way for Ingres and System R, which were developed at the University of
California at Berkeley and IBM, respectively, in 1976. These two database systems and
the fundamental ideas upon which they were built evolved into the databases we use
today. Oracle and DB2, two other very popular database platforms, followed in the
footsteps of Ingres and System R in the early 1980s.
Modern Databases
The Ingres system developed at Berkeley spawned some of the professional database
systems we see today, such as Sybase, Microsoft SQL Server, and PostgreSQL.
Now, PostgreSQL is arguably the most advanced and fastest free database system
available, and it is widely used for generic and specific database applications alike.
MySQL is another free database system used in roughly the same scope of applications as
PostgreSQL. While MySQL is owned and developed by a single company, MySQL AB in
Sweden, PostgreSQL has no central development scheme, and its development relies on
the contributions of software developers around the world.IBM’s System R database was
the first to use the Structured Query Language (SQL), which is also widely used today.
System R, itself, however, was all but abandoned by IBM in favor of focusing on more
powerful database systems like DB2 and, eventually, Informix. These products are now
generally used in large-scale database applications. For example, the Wal-Mart chain of
large department stores has been a customer of both DB2 and Informix for many
years.