Base/HSQL table with more than two dimensions?

users
#1

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

#2

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.

#3

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

#4

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

#5

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