Base/HSQL table with more than two dimensions?

classic Classic list List threaded Threaded
5 messages Options
John Kaufmann John Kaufmann
Reply | Threaded
Open this post in threaded view
|

Base/HSQL table with more than two dimensions?

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.]

Thanks,
John

--
To unsubscribe e-mail to: [hidden email]
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
Dave Howorth Dave Howorth
Reply | Threaded
Open this post in threaded view
|

Re: Base/HSQL table with more than two dimensions?

On Wed, 24 Jun 2020 02:28:45 -0400
John Kaufmann <[hidden email]> 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.]

Every extra field added to a record creates another dimension in data
space. So you just need to add a column called, say, year that can take
each of the values 'A', 'B', 'C' or 'D' and then add that field to your
SELECT statement.

> Thanks,
> John
>


--
To unsubscribe e-mail to: [hidden email]
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

John Kaufmann John Kaufmann
Reply | Threaded
Open this post in threaded view
|

Re: Base/HSQL table with more than two dimensions?

On 2020-06-24 06:39, Dave Howorth wrote:

>
>> ... 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.]
>
> Every extra field added to a record creates another dimension in data
> space. So you just need to add a column called, say, year that can take
> each of the values 'A', 'B', 'C' or 'D' and then add that field to your
> SELECT statement.

Oh, of course: an extra column for each extra dimension.  Thanks, Dave.


--
To unsubscribe e-mail to: [hidden email]
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
Dan Lewis Dan Lewis
Reply | Threaded
Open this post in threaded view
|

Re: Base/HSQL table with more than two dimensions?

In reply to this post by John Kaufmann
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.

Dan

On 6/24/20 02:28, John Kaufmann 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.]
>
> Thanks,
> John
>

--
To unsubscribe e-mail to: [hidden email]
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
John Kaufmann John Kaufmann
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email]
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