Re: [libreoffice-users] Base/HSQL table with more than two dimensions?

On 2020-06-24 08:40, Dan Lewis wrote:
 
> > A lectionary is an ordered set of readings, typically using a cycle of three or more years, to 
> > cover the Bible. In a four-year cycle the years are simply designated {A,B,C,D}, and for each day 
> > in a year readings are prescribed from different parts of the Bible. For any year, storing the 
> > readings in a database table is straightforward in two dimensions [fields (readings) x records 
> > (days)], and it is simple to SELECT the set of readings (usually from four different fields) for 
> > any day.
> >
> > Obviously it is possible to do this in one table per year (say, four tables for four years), but 
> > since the pattern of records and fields is the same for all years, that is clumsy and should be 
> > unnecessary. It should be possible to do a table of three dimensions, of which the third dimension 
> > is the year {A,B,C,D} in the cycle, so that one could compare the readings for any given day across 
> > all years. But I don't see how to extend tables into three (as in this case) or more dimensions. 
> > Can someone point me in the right direction?  [It seems like this kind of database design issue 
> > should be common to a lot of domains.]
>
> What I see, you are talking about three tables which contain data: readings, days, and years. A 
> fourth table should be created containing three foreign keys for these three tables. What you need 
> for this data is a relational database which Base can create. Just make sure you normalize these 
> tables. You might want to read up on relational databases to see how to do this.

Actually, Dan, it's not that ambitious: the table contains not the readings, but a set of indices 
(keys) to the readings, one index/key per column (with each column/field drawn from a particular 
set of books of the Bible). Each row/record is for one day, and the day also modified by the year 
in the cycle of readings. That's why Dave Howorth's answer was right: just add one column for every 
added dimension (in this case, that added dimension being the year in the cycle).

The main reason it does not make sense to go further is a procedural one that predates [you think? 
;-)] computer generation of these things. The lectionary bounds the list of readings by day, but 
does not necessarily determine it; often a choice will be offered, and a person must make that 
choice.

Then that reduced/approved set is used to fetch (with some string processing) the actual readings 
for print. Where there is a choice, the full set could also be used to fetch the optional readings 
to assist the person making the choice, but that gets into how much you want to impose computerized 
methods on a person who is not (yet, at least) so inclined. [No project is without non-technical 
constraints, which is fine; the purpose is to help with a solution, not impose one.]  On the whole, 
this project has much that is relational (~20 completely normalized (third form) tables, 
relationally connected). It's just not particularly relational in this function.

I appreciate your thinking about it,
John

--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy