definition of flat/relational database

users
#1

Why do the Libreoffice powers that be define dbase/xbase as a flat file database, not a relational database. The below definitions from the Base Intro documentation demonstrate what I am saying:

*Flat databases*

A flat database contains one or more tables, each containing one or more fields. Each table is completely independent of all the other tables in the database. For example, I have an address database with seven tables in it. One has my family's contacts, another has my business contacts, and another has my wife's family contacts. While some contacts are contained in more than one table, different tables may not have the same information about the same person.

dBase is a flat database program. LibreOffice and several database programs can also create flat databases.

*Relational databases*

Relational databases contain one or more tables with one or more relationships; each relaltionship is defined by a pair of fields. One field of each pair belongs to one table and the second field belongs to the same or a different table. Where relationships exist between fields in the same or different tables, a flat database could still be used, but it provides no mechanism for defining the relationship. Instead the same data must be entered in both fields, making data entry errors more likely. A well designed relational database requires the data to be entered only once, reducing possible errors.

dbase is a relational database per the above definition. I link 2 tables with 1 field so I can refer to data in the second database so data does not have to bbe entered multiple times. In our alarm monitoring station, when a police dept. changes its phone number, we change 1 field in 1 database. Hundreds of subscriber records refer to that field to populate the data screen. It seems that LO ptb either have a problem with dbase/xbase, or they are (were) uninformed of the facts.

John Sowden
(been programming in dBase II (under cp/m), Foxbase, Foxpro (under DOS) since 1981)

#2

Good, someone who can provide some information! How far back has dBase been able to create and use relational databases? I ask because until OOo 1.1.15, Base created databases in dBase format. With the switch to using HSQLDB and embedded databases, Base could work with relational databases. Base could also work with dBase but only as a flat database.
      So, how would you suggest this section you quote be written to make it accurate? What are some good examples of flat databases?

--Dan

#3

Hi John,

John R. Sowden schrieb:

Why do the Libreoffice powers that be define dbase/xbase as a flat file
database, not a relational database. The below definitions from the
Base Intro documentation demonstrate what I am saying:

Do you have a direct link?

*Flat databases*

A flat database contains one or more tables, each containing one or more
fields. Each table is completely independent of all the other tables in
the database. For example, I have an address database with seven tables
in it. One has my family's contacts, another has my business contacts,
and another has my wife's family contacts. While some contacts are
contained in more than one table, different tables may not have the same
information about the same person.

dBase is a flat database program. LibreOffice and several database
programs can also create flat databases.

*Relational databases*

Relational databases contain one or more tables with one or more
relationships; each relaltionship is defined by a pair of fields. One
field of each pair belongs to one table and the second field belongs to
the same or a different table. Where relationships exist between fields
in the same or different tables, a flat database could still be used,
but it provides no mechanism for defining the relationship. Instead the
same data must be entered in both fields, making data entry errors more
likely. A well designed relational database requires the data to be
entered only once, reducing possible errors.

I think, it is a wrong definition of the term 'relational database'. The word 'relation' in 'relational database' means the mathematical definition of 'relation', which is connected to 'tupel', a organization of data in rows and columns. It is not about a 'relationship'.

Another database model is a hierarchical model for example, which is tree-like.

http://en.wikipedia.org/wiki/Relational_database.
http://en.wikipedia.org/wiki/Database_model
http://de.wikipedia.org/wiki/Datenbankmodell

It seems, that 'Flat database' is used for a database with one single table. But such a database would still be a relational database. My German text book does not have any term which would correspond to 'Flat database'. And the German Wikipedia article has no database model 'Flat database'.

dbase is a relational database per the above definition. I link 2
tables with 1 field so I can refer to data in the second database so
data does not have to bbe entered multiple times. In our alarm
monitoring station, when a police dept. changes its phone number, we
change 1 field in 1 database. Hundreds of subscriber records refer to
that field to populate the data screen. It seems that LO ptb either
have a problem with dbase/xbase, or they are (were) uninformed of the
facts.

dBase is a relational database application because the data is organized in tables.

I think, there is no need to introduce the term 'flat database' at all. The distinction is in the management system. For files in dBase-format and for spreadsheets, LibreOffice itself is the database management system. For all other database connections, it uses an external database management system.

Kind regards
Regina

#4

I think the (incorrect) definition that is being used is whether LO
manipulates files directly or talks to a database engine.

I don't think there is a dBase or FoxBase engine. I'm pretty sure
there is a Visual FoxPro engine (John doesn't mention VFP, whyzatt
then? :wink: ), however it'll be a Windoze only thing I expect.

So, to answer the original question, LO is calling dBase files flat
because it can't access a database engine for them and it won't do
any engine work itself.

A flat database? Errr, can't think of one, although I know there
have been such things.

You only had to ask :wink:

Regards
Mark Stanton

#5

dBase II (there was never a dbase I. The closest was Vulcan which was written with our tax dollars at the Jet Propulsion Laboratory.) was originally a relational database. The original 3 ring binder manual said "Assembly Language Relational Database" on the cover. It only supported 2 open databases (now called tables). dBase calls its elements fields and records. An example of a 'flat" database is a name and address file. It's not linked to anything, so if you had a city field, and had 25 addresses in Cupertino, and the city got 10 million from Apple to change the name to "Apple City", you would have to change the city field in 25 records. If it were a relational database, and you set up a link between the citycode field in the main database and the citycode field in a cities database, then all of the addresses in Cupertino would have a code in the city field ('14') and the cities database would have 2 fields, one citycode and one cityname. All of the addresses in Cupertino would have a '14' in the city field and all of them would link to the one record in the cities database, so to make the change, all you would have to do is go to the cities database and change the cityname from 'Cupertino' to 'Apple City'.

It sounds like OO 1.1.15 treated the dbf files as unlinked individual databases. Therefore the "flat database" concept was a deficiency in the code of OO, not in the structure of the dbf format. Maybe no one wanted to acknowledge this, so they made the dBase format the scapegoat.

Re: your last comment, I would not mention dBase as a "flat file". If it were necessary to have an example of a "flat fire", I would look for a well known database that actually is a flat file, or define it as a list of data broken into sections, like a comma delimited list.

Another comment was made in another message re: the definition of relation. Actually the 2 databases cited above are related. I the commonness (is that a word?) of them is the citycode field, and the connection is via the software. In dBase they must be indexed on the linking field. The command used to relate them is "set relation to".

Runnin' out of wind,
John

#6

I think the (incorrect) definition that is being used is whether LO
manipulates files directly or talks to a database engine.

I don't think there is a dBase or FoxBase engine. I'm pretty sure
there is a Visual FoxPro engine (John doesn't mention VFP, whyzatt
then? :wink: ), however it'll be a Windoze only thing I expect.

So, to answer the original question, LO is calling dBase files flat
because it can't access a database engine for them and it won't do
any engine work itself.

A flat database? Errr, can't think of one, although I know there
have been such things.

Probably the closet to a flat database would be using a spreadsheet as a database for most people. Depending on the backend for Base and how well they communicate Base is can be the front end to a true relational database or to flat database.

#7

Re: the database engine issue: I think we're muddying the sql concept. In the sql environment, a program accepts a command from the client and only returns the results that are requested in the sql command (query). This became important as database programs were used in, say an order entry environment.

Two hundred desktops with PCs and telephones accepting orders:

Non-SQL environment:
Clerk keys in the account number to bring up the customer file.
All 5000 customer records are carried over the network to that PC, where the local program filters the data to find the customer and display the data.

SQL environment:
The clerk's program accepts the account number from the clerk and creates a short query. The query is sent to the central computer (server). Only the 1 record that meets the account number query is returned over the network.

Obviously, the whole system would be very slow if 200 clerks are downloading 5000 customer records on each call. This has nothing to do with the relational model.

Re: Microsoft's Visual Foxpro: I purchased 5.0 when it came out, but I was having so many problems with MS Windows 95, and then Windows 98, that I decided that my environment could not tolerate the problems. (Yellow devils, secret codes to put in config files, yeah right).
Thank God Linux came arround when it did. I started using Red Hat, version 5.2., but I still use DOS (FreeDOS and 4DOS). It's rock solid. I am still waiting for a database program that will allow me to create applications (not pieces of applications, like queries and forms) without having to learn C (this old dog is not going to learn that new trick!).

set soapbox off,
John

#8

Why do the Libreoffice powers that be define dbase/xbase as a flat
file database, not a relational database.

The main issue for me would be whether the database "management
system" (some call it "engine" or whatever) actually enforces
relational integrity (foreign key constraints) between tables.

In case of directly writing to DBF files from LO Base, I would guess
there's no enforcement.

Sincerely,

Wolfgang

#9

Direct Link: https://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Guide

A spreadsheet is organized as a table. That does not make it a relational database.

John

#10

exactly.

#11

Foxpro and dBase do not support referential integrity. They do not have data dictionaries (possible VFP does, I don't know).

I don't allow my users to write directly to any dbf. They must go through an application that I wrote (gigo, etc.).

John

#12

See the string "Link Base to External Spreadsheet"

#13

Hi all,

Neither OOo, AOO, or LO have ever supported multitable referential integrity, multitable write or multitable query operations with regard to the dBase file format. It was requested by users several times in various ways over the years with the OpenOffice.org project (myself included), but it never happened. Comparisons were made with VFP or Lotus Approach as ways of providing an application layer over the underlying database structure, but they were no doubt deemed too much effort for too little perceived added value.

Personally, I loved the Lotus Approach wrapper for its GUI, access to Smartscript, etc (yes, it was so 80's, but then so were a lot of things at the time ;-)). I only ever used (V)FP sporadically, so find it harder to make comparisons.

Of course, for someone so inclined, there would be nothing standing in the way of coding improved support for dBase in LO and more complete user interface options ;-))

Alex

#14

I don't know if it will be suitable, but you can try Kexi (part of Calligra
suite, I believe; but you can install it separately). I heard it is much
better than LO Base, but I don't know enough to verify that statement.

#15

Thank God Linux came arround when it did...
   I am still waiting for a database program that will allow me to
create applications

I feel your pain. I was a professional VFP developer and have now moved to
Linux and have the same problem.
However, I am wondering if the "one solid lump" approach is the only way to
go or if a collection of pieces will do the job as well (or better?) The
pieces in Base are actually (potentially) pretty good). I'm hoping to get
some time to develop this idea in the not-too-distant future.

C, or its derivatives, would be a very poor database application
environment imnvho.

Mark Stanton
One small step for mankind...

#16

Hi :slight_smile:
I thought Queries were in Sql but Base mostly allows you to build them up in a gui rather than having to learn the Sql that it gets translated into?  I learned a little Sql but not enough to be useful so i prefer using the point&click type gui.

Also Base is a bit different form MS's version in that forms are best done in Writer and that makes it easier to format forms decently without having to learn a complicated and different gui.  Access's forms seemed to switch the Alt and Ctrl keys around for thing like selecting fields and stuff.

Quite possibly i have completely missed the point.  I got confused by that 1st sentence.  Is there soem attempt to reinvent the wheel rather than use Qt libraries (or whatever) for pop-up boxes and stuff? 
Regards from
Tom :slight_smile:

#17

I don't know if it will be suitable, but you can try Kexi (part of
Calligra suite, I believe; but you can install it separately). I
heard it is much better than LO Base, but I don't know enough to
verify that statement.

Kexi will become usable as soon as it supports composite (natural) keys.

It's a pity that Knoda, Rekall etc. have vanished or died without
anyone picking up the code behind the original developers, so that Kexi
is now the n-th re-implementation of the same functionality.

Sincerely,

Wolfgang

#18

I am still waiting for a database program that will allow
me to create applications (not pieces of applications, like queries
and forms) without having to learn C (this old dog is not going to
learn that new trick!).

If LO Base is not enough for you because you need more application
logic, then there are two VFP developers who have implemented their own
successor to VFP. Cross-platform, open-source, free. It's called Dabo
(www.dabodev.com) and it uses Python as the programming language. If
you've ever learned any programming language, learning Python will be a
no-brainer.

There are a couple of other database application development frameworks
for Python (even LO Base can be scripted with Python, although that's
one of the best kept secrets of LO), but Dabo has been specifically
made by (ex-)VFP developers for (ex-)VFP developers.

Sincerely,

Wolfgang

#19

On 2013-03-05 20:12, Wolfgang Keller wrote:>> I am still waiting for a
database program that will allow

me to create applications (not pieces of applications, like queries
and forms) without having to learn C (this old dog is not going to
learn that new trick!).

If LO Base is not enough for you because you need more application
logic, then there are two VFP developers who have implemented their own
successor to VFP. Cross-platform, open-source, free. It's called Dabo
(www.dabodev.com) and it uses Python as the programming language. If
you've ever learned any programming language, learning Python will be a
no-brainer.

There are a couple of other database application development frameworks
for Python (even LO Base can be scripted with Python, although that's
one of the best kept secrets of LO), but Dabo has been specifically
made by (ex-)VFP developers for (ex-)VFP developers.

Didn't know about this one yet! Thanks for the info. I''l take a look at it.

Sometime ago I had some success with Glom (www.glom.org). Maybe it meets
the needs of the other posters.

Grx HdV

#20

And if you want a commercial product there is Dataflex (http://www.dataaccess.com/products.asp?pageid=712).
Our accounting system is written in this.
Steve