Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgYou may find that the database being shipped with OpenOffice (ver.2 and higher) delights you as much as it has me. This page tries to help you use it.
Forget anything you may have heard about Adabas, which came with Star Office, the commercial version of Open Office 1. The current Open Office's database, "Base", aka "ooBase", is unrelated. And remember that Open Office, including ooBase, is free! But don't let that fool you. And it's not new. Big organizations, government and civilian, are adopting it as their standard office suite... and saving million$, but still Getting The Job Done.
There's more about ooBase in the main index to this material.
This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is more fully explained, and there's another tip, at my Power Browsing page.)
Page contents © TK Boyd, Sheepdog Software ®, 3/06.
Please note the title: "Introduction to Primary Keys". I have also written a second page about primary keys, going into more advanced topics.
At the heart of a database is at least one table. Note: "The database" is more than the table(s)... but the tables are the heart.
A table consists of rows and columns.
The rows: Each row is a "record" (database term), with data about an entity. A record in a simple telephone numbers database might consist of the number and the name of the person you reach if you phone that telephone number.
The columns: For each record, there is at least provision to store different bits of data, and what data can be stored is consistent for every record. In the simple telephone numbers table there would be a column for the number, and a column for the name. The database term for the "things" of which the record is made up is "field". We speak of, say, "the data in the 'person you reach' field."
If you are new to databases, you will benefit from following the simple rule which I will give in a moment. Later in this essay, I will...
In a moment, I'm going to be talking about "auto increment fields". They are neat: Without any effort on the users part (once the table is built!) these fields have something put in them, a different something every time.
The rule I'm about to give you is to get you started. As you become more proficient with databases, you will realize that primary keys can be done other ways, can consist of other things. But until you understand all that, use my rule. Even if you don't want to follow my rule, do have some kind of primary key for each table you make.
Every time you create a table, make the first field as follows. (If you use the wizard to create tables, help for you follows in a moment.) (Not every property listed below is available until you have selected the right field type.
If you use the wizard to create tables, then in step 1 choose a field (from those on offer for the sample you are building your table from) which will not be needed in your table. Then, in step 2 of the wizard, change the field's information to make it conform to the above specification. In step 3, elect to "Use an existing field as primary key." (And select PriKey, or whatever you called it.)
If you build the table with "Create table in design view..." (I'd recommend this, by the way), then....
That's almost it.
Before you save the new table, though, you need to right-click in the gray column to the left of "PriKey" in the first line of the datagrid. You should see "Primary Key" in the menu which pops up. Click on that. A little gold key icon should now appear in the gray box. (The "this line is selected" green arrow will be there too, for the moment.)
Now save your new table, giving it a sensible name along the way.
A simple primary key, like the one above, will probably never be of any direct use.... to you.
However, virtually all databases will work better for you if the tables have primary keys, and there are some things you may grow into wanting to do which cannot be done without a primary key.
I used to worry about the "wasted" space taken up with that "useless" PriKey field. Of course, today's PCs are so fast, and have such vast disks, that one little field hardly matters... but the principle still matters.
If the data in your database has a field which will never be filled with the same value on any two lines, then that field can be the primary key.
Suppose, for instance, that you cared about your health, and were doing a database recording your weight and blood pressure.
If you are willing to decide that you will only take one reading per day. In that case, your table could have "Date", "Weight" and "Blood Pressure" fields, and the "Date" field could do double duty, being the primary key as well as holding useful information. (A detail: If you did this, there would not be any need to have data for every day. There can be gaps in the sequence of values in the primary key field.)
The primary key field does not have to be called "PriKey", nor does it have to be of type "Integer".
Primary keys often are made of type "Integer" because you can set integer fields to be auto incrementing. And if the contents of the field "don't matter" to you, you won't be caught out by something implied in the following paragraph.
To underscore something I said above: When you designate a field as the table's primary key, you are creating a situation in which you will not be allowed to create two records with the same data in that field. This can be a nuisance, (if you failed to anticipate a need) but at least ooBase protects you from accidentally entering a non-unique value in a primary key field.
You are supposed to be able to add new fields, even primary key fields, to a table after they have already been in use for a while.
From things I see at oooForum.org, and from personal experience, it seems that this doesn't always go according to plan. Don't be alarmed or depressed if you have trouble. Sometimes it isn't too hard just to make a new table, made the way the first one should have been made!
So! There you have it. When you make a table, give it a primary key. If you're not too sure about these "primary key" things, then call it PriKey, make it an auto-incrementing integer.
Happy data management!
Please note the title of this tutorial: "Introduction to Primary Keys". I have also written a second page about primary keys, going into more advanced topics.
I dislike 'fancy' websites with more concern for a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Of course, an attractive site WITH content deserves praise... as long as that pretty face doesn't cost download time. In any case....
I am trying to present this material in a format which makes it easy for you to USE it. There are two aspects to that: The way it is split up, and the way it is posted. See the main index to this material for more information about the way it is split up, and the way it is posted.
PLEASE >>> Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages <<< PLEASE
If you liked this ooBase tutorial, see the main index for information other help from the same author.
Editor's email address. Suggestions welcomed! - - - Want a site hosted, or email? I like 1&1's services.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
. . . . . P a g e . . . E n d s . . . . .