Back to William's Archives.
Database Concepts:
I am going to skip a week on my Writing and Publishing series
because I want to address a different subject. Consider it a change
of pace. I'll get back to W&P next time. I don't know if this
essay will be of interest to others or not. It is on a subject
which is of interest to me. At one time, I worked as a software
systems analyst. With that background I tend to be more specific
than most folks about the meanings of some technical words. Database
falls into that category.
I recently received an e-mail solicitation from a magazine person offering ad space in the magazine she represented. This happened after I sent a copy of my book, No-Count-Charlie to the magazine's review editor.
Other than the obvious blatancy of the solicitation, which I will discuss in another essay, I was bothered by a phrase she used. In her first line, she said she could not find our firm in her database. I easily guessed that she did not know the difference between a database and a list. That was because we receive regular copies of the magazine and regular e-mail newsletters from these people. Obviously Wesoomi is on at least two of their lists.
I have heard that word database tossed about quite often. In most cases I suspect that the person using the word is ignorant of its technical meaning. They are usually using the word incorrectly. Because of that, it occurred to me to discuss what the word means from a technical standpoint. Think of this as an overview rather than a tutorial.
First, I will look at the meaning of the word in a very general way. When I go to my dictionary, I find this:
Database: A collection of data arranged for ease and speed of search and retrieval.
Taking the general nature of that meaning, the little tin box of 3 X 5 recipes in your cupboard is a database. I assume it is arranged by food category, perhaps even alphabetically. That would satisfy the ease and speed of search and retrieval requirement.
In that sense, even a telephone book or your address book qualify as databases. So, in the general sense, my solicitor above used the word correctly. I was not on her list. I am tempted to say, thank God. The real problem with calling a customer list a database is that you are implying a technical capability which you do not actually have. While you may seem sophisticated to some people, you will not fool anyone who knows.
Now to the technical meaning. In computer technology, there is a more formal and specific meaning of the word database. When we use that word we are implicitly speaking of a specific set of tools and methods. These are specialized tools and methods used to store and retrieve data using a computer.
Many companies make various versions of these tools. They are usually called relational databases. If you own one of the major office suites, you probably have one. Also, you probably don't know how to use it. The one which comes with WordPerfect is called Paradox. I have it and I have never tried to use it. Thus, I don't know how it works, or even if it works. If I ever need it, I'll find out.
Here is the general structure of a relational database. The basic entity of the database is the record. Each record is composed of elements, sometimes called cells. A typical database would consist of records containing customer information. Each record would represent one customer with each element within the record containing a single customer specific datum. A database user would then be able to search the database for specific customer records. The user could also search on certain key elements. State of residency, for example as in "Retrieve All California Customers."
If the magazine people cited above really had a functioning relational database, Wesoomi would appear in only one place as a single record with multiple elements. The woman, as a user, would have found the Wesoomi record using a Structured Query Language (SQL) search. We can look at SQL later. First let us look at how a record in a database might be arranged. For an example we could create the hypothetical Wesoomi record in the magazine's hypothetical database.
I stated that a record consists of elements. If we were to do a database design for a specific group, we would sit down with the group and define these elements based on the groups needs. We can pretend we are doing this for a magazine's customer database.
Obviously, the first elements of the record could be the Customer'
name, and address. We could list those with our Wesoomi example.
|
Customer name Street address City State Country Postal code |
Wesoomi Publishing P. O. Box 656 Ortonville Michigan USA 48462-0656 |
Once we know the intent of each element, we could create database records for each customer on our list. These would be stored in a relational database on a computer. One thing to notice in passing is that not all records would be full. Some elements of data may not be pertinent or simply not available for some customers. In that case, the element remains empty.
Now our magazine would have just one customer database rather than a bunch of lists. When my above correspondent wanted to find if I was in the database, she would use SQL to find out. She would enter a SQL command to retrieve the Wesoomi record. SQL is a simple, English language type of, query language. It is supposed to be standard, but I have found that it is not. It is similar, but it must be relearned for each system for each one will have its own idiosyncracies.
At any rate, the query engine would retrieve the Wesoomi record and display it on her screen or print it or whatever she wanted to do with it. She would instantly know, if Wesoomi was in the database and, if so, all of the other information in the Wesoomi record.
What is the advantage of a database as opposed to a list? The main advantage is that there is only one record for each entity defined. The users would only have to enter the record once in a single database. They would not have multiple lists with redundant entries.
As I said, Wesoomi would only appear once. There would be keys in the Wesoomi record to show all other facts about us. The subscriber key would be a simple yes or no flag. The advertiser key would also be a simple yes or no flag. This arrangement will allow queries such as, "List all Michigan customer who are not advertisers." That could be very handy for the Michigan marketing rep.
This has been a rather simplified overview of database concepts.
For a more complete understanding, the best step might be to start
playing around with the one which came with your office suite.
Back to William's Archives.
|
|
|
|