On 02/07/2012 05:17 PM, e-letter wrote:
On 07/02/2012, Nino Novak<nn.libo@kflog.org> wrote:
As a consequence: It would help most, if the database set up barrier could
be
lowered.
We therefore should ask (and try to learn) what makes database creation so
difficult, and how could we contribute to ease the learing curve?
Or directly: how can we make database creation easy and a low-threshold
task?
The statement made by someone that databases requires planned design
_first_ is important to remember. But for a novice how do you make the
plan?
For example you wish to develop an inventory of all your books. You look
at the data you have for each book such as title, author, subject,
publisher, etc. and determine what data is needed. Next look at each
group of data for a book. A book can have multiple authors and multiple
subjects but only one title, publisher, ISBN number. This suggests that
there should be three tables in the initial: title, author, and subject.
First design you have a main table of based on the title each book -
primary key titleid, an author table with each author linked by a
"foreign key" to the correct title id, and a subject table with each
subject linked by a "foreign key" to the correct titileid. The author
and subject tables have their own internal ids. I like to have an
integer id for each row as the primary key. You can use any column or
group of columns as a primary key as long as each generates a unique
value. Using integer id fields makes implementing foreign keys easier.
To refine the design, you want every individual piece of data only
inputted once and you may find it advisable to split say the title table
into two tables,; one for titles and one for publishers.
Also, determine the best type for each data column, text, date, time,
integer, floating point number, etc and determine which data must be
entered, which has a default value you can override, and which can have
no data entered. The database engine will enforce these rules when one
enters the data. If any is the wrong type or required it will through an
error.
This is why the original poster was asked the question why did
spreadsheet names have to be changed, although he doesn't think it
important. It is important to know the objective. For example, we
could be asked how to manoeuvre a 10-tonne truck a distance of 50
metres, when if we knew the objective was to buy a drink from the shop
across the road, we could advise it would be easier to walk! A silly
analogy but hopefully understood.
Maybe the way to promote the option of designing databases is to
describe particular scenarios and show how particular tasks can be
performed using either a database or a spreadsheet. Users would then
see two tutorial scenarios to show the (dis)advantages.
Hopefully someone can suggest such a scenario or two please?
--
Jay Lozier
jslozier@gmail.com
--
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Context
- Re: [libreoffice-users] Re: database or spreadsheet (continued)
[libreoffice-users] Re: database or spreadsheet · Andreas Säger
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.