You 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 ®, 2/06-12/10.
Unfortunately, the term is used for two quite different things.
A "database" can be some data, e.g. the names and addresses of some friends or customers. When I speak of a "database", I will normally be using the term this way.
"A database" is also a term for the programs (i.e. applications) which manage the data in the collection of data. I will generally refer to the programs as "the program to manage your data", or as the RDMS. ("Relational Database Management System". Examples of RDMSs are ooBase, MySql, Access, Paradox and Oracle. The last is for big corporations. The Access is expensive, and supports Mr. Gates' hegemony. Paradox is quite dated, but an excellent choice. You can get Paradox on eBay as part of the Corel Wordperfect suite. There's a run-time package which you can give away so that people can use tables/ forms/ etc which you develop for them, without needing to buy (or install) the full package.
The good people at Open Office have incorporated the HSQL RDMS in version 2 of the free, multi-platform, Open Office office suite. It is almost nothing like the Adabas which you may have tried with Star Office. It is similar to MySQL.
An RDMS cannot cope with any data you may wish to manage... but it will do many important jobs.
Most of us use a wordprocessor almost without effort. Spreadsheets are relatively simple to use in a basic way. (And can be used for simple data management tasks! Both wordprocessors and spreadsheets, of course, are also capable of advanced things. But those applications have more gentle learning curves than databases do.)
Getting started with databases is harder... but worth the effort!
(Apart from the acronym "RDMS", words in IN CAPS in what follows are being used in a narrow way, as a database engineer would use them.)
The data an RDMS is good for is data which can be put in one or more TABLES. They are put together as follows....
A TABLE is a grid of rows arranged in columns. The rows of a TABLE will contain data about one person, event, item of warehouse stock, book, etc, etc. Each column will give information about a single entity.
A telephone book is a simple example of the sort of data that a RDMS can manage well. (Although RDMSs really come into their own with more complex data.)
The elements of each row of the TABLE, taken together, constitute one RECORD. The columns are called FIELDS.
My RECORD in a phone book might be:
TK Boyd....1 Main St....919-555-1212
A simple phone book table like that would be said to have three FIELDS: Name, Address, Number. (The "Name" field might well be split into FirstName and LastName fields, but the principle is the same.)
Once you have data in tables, you can do various useful things....
Instead of working with the data in its "raw" form, instead of working directly with tables, you will set up FORMS. They may display the data looking almost as it does when you access a table directly, but they also allow you to display the data in more convenient layouts.
You can present the data to the user in different formats and with different SORTING or FILTERING schemes. (Filtering screens out some of the data. For instance, a phone company knows all of its ex-directory customers, but it would be a sensation if the phone book was accidentally published without filtering those records out! In some countries, if you know a phone number, you can consult a "reverse look up". Before computers, you could buy a copy of a phone book with the numbers listed sorted by number rather than by customer name. The first table described in these tutorials will let us explore sorting and filtering further.)
You can EDIT the data, i.e. add new records, delete obsolete ones, change the data in some of the fields of a given record, e.g. revise my telephone number and address if I move.
You can run QUERIES: Suppose you want a list of all the people in the phone book who live on Main St... you could use a query. (There are other ways to find the Main Street residents, too.) (Filtering restricts what is displayed. A query fetches a collection of records into a copy of a portion of the database. A query creates a new, usually temporary table. It isn't always a mere subset. Sometimes each record in the query consists of fields from more than one table.)
You can design and run REPORTS: A report design says "Print out bits from the database in the following way....". Sheets of address labels are produced with a report. Mailshots with "Dear "Mr. Smith, You and two other people in Middletown have won..." are produced with reports. Often, you will want to generate the same report from time to time. To answer this need, RDMSs give you a way to save your report specification so that you don't have to repeatedly explain what you want. A report can also do arithmetic with suitable data. (Suppose your database covers your stock market portfolio. If one field were "Number of shares", and another were "Price per share", you wouldn't need a "Value of holding" field.... any report could give you the holdings' values by multiplying the contents of the "Number of.." and "Price per..." fields. The report could also calculate the total value of all your holdings.) From the telephone numbers database, you could print a report of how many customers lived on Main St, on River Drive, on Mountain Way, etc. Reports can be done with the results of a QUERY, for times when you only want to include records meeting some criteria.
You are welcome to use the material here free of charge. But if you want to show your appreciation, you easily can make a gift to me or contribute to a charity I would like to help... I've listed several to choose from. (The link will open in a new tab or window.)
With that basic database vocabulary, you are ready to return main menu, or just jump straight into the first tutorial specific to ooBase. (I've also written some notes on installing OpenOffice. If you have a recently installed setup, which seems to work, but sometimes behaves oddly, see that.)
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 . . . . .