06 June 2006

Databases for Laypeople: Part 3 in a series

Why Relational?
(Table of Contents--Part 2)

In order to organize data in a way that it can be arranged freely by the computer user, programmers developed the relational DBMS (RDBMS). In an RDBMS, the data is organized into tables based on the type of information the data represents. For example, suppose you have a company that arranges events like weddings, corporate picnics, or fundraisers. Your company will have a set of customers, some employees, some suppliers, and some contractors. In a non-relational database, you need to have a table, rather like an Excel spreadsheet, with a row for each record (or example of whatever is on the list) and a column for each field (e.g., name, phone number). In addition to all the contacts, you will have want to have a table for events. The events, of course, will have one or more customers who paid for it, plus one or more contractors (caterers, florists, et al.). You might have another table that says which employee is working what event, and some tracking of payments to suppliers for what event.


If you want to look up the names of contractors for an event--say, Rosa Luxembourg's wedding--then you want to have a table that includes the names of events, plus three or four fields for possible contractors who might serve at the event. If you want to call those vendors and tell them Rosa is getting married a week later than initially planned, you have to open another table for the vendors--unles, naturally, your master event list is so immense it can include all the vendor's phone numbers as well. Supposing you need to include a cell phone number and an office number for each vendor--which seems likely---it's possible a change in the area code would leave you franctically updating many different tables. The master event table would have a stupendous number of fields , causing it to require a long time to open or search, and the information might be wrong.


Here, a hypothetical listing of vendors for our hypothetical firm.


For that reason, you would want a DBMS that simply pulls up the data you request, and displays it all conveniently. That's what an RDBMS does.

But how does an RDBMS work?

At the core of the RDBMS is the concept of hypertext. Hypertext is the technology of organizing text through links, like the World Wide Web (WWW). If you start off researching the concept of a Riemann surface in Wikipedia, for example, you will find an entry like this:
In mathematics, particularly in complex analysis, a Riemann surface, named after Bernhard Riemann, is a one-dimensional complex manifold. Riemann surfaces can be thought of as "deformed versions" of the complex plane: locally near every point they look like patches of the complex plane, but the global topology can be quite different. For example, they can look like a sphere or a torus or a couple of sheets glued together.

The main point of Riemann surfaces is that holomorphic functions may be defined between them. Riemann surfaces are nowadays considered the natural setting for studying the global behavior of these functions, especially multi-valued functions such as the square root or the logarithm.

Every Riemann surface is a two-dimensional real analytic manifold (i.e., a surface), but it contains more structure (specifically a complex structure) which is needed for the unambiguous definition of holomorphic functions. A two-dimensional real manifold can be turned into a Riemann surface (usually in several inequivalent ways) if and only if it is orientable. So the sphere and torus admit complex structures, but the Möbius strip, Klein bottle and projective plane do not.


Each bit of blue underlined text links, obviously, to another article in Wikipedia. The relational database works the same way. Rather than actually have all of the data, such as detailed information about each vendor, event, employee, supplier, and customer appear on some colossal event table, many of the fields for each event are linked to a corresponding record on another table. The vendor field will be linked to a record in the vendor table; the customer field will be linked to a record in the customer table.

Likewise, just our example of the Wikipedia entry on Riemann surfaces linked to complex manifold, the entry for which links back to Riemann surface. In our database example, this would include the link from the event record to customer; say, the event is a convention of textbook publishers, so the customers include several publishers. Each publisher, in turn, needs to be linked to the events it has participated in. In my next entry I'll discuss the way relational databases handle this.

(Part 4)

Labels:

0 Comments:

Post a Comment

<< Home