Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


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.