Tim Powys-Lybbe wrote: > On 12 Nov at 23:40, Ian Goddard<goddai01@hotmail.co.uk> wrote: > >> I was recently shown an example page from a tithe book. As this is >> possibly going to become a collaborative transcription project I've >> been giving some thought to the sort of data structure needed to hold >> the data. I've got some ideas in the back of my head but although it >> looks simple it presents some interesting problems, especially if a >> relational solution and capability of indexing personal names are >> objectives. >> >> The pages are ruled vertically into a number of columns. These are: >> >> Landowner. To be thought of as a single entity but names are not >> necessarily unique and a "Landowner" may not even be a single person >> or even a natural person, e.g. one "Landowner" is a named person plus >> the executors of another. So a Landowner is to be structured as a >> list of sub-entities but even then the sub-entities aren't all of one >> type. >> >> Occupier. Again this is to be thought of as a single entity but an >> "Occupier" can consist of multiple non-unique names. In one instance >> there is a name followed by "and another". Although there were none >> in the example it wouldn't surprise me to see executors listed. The >> structural problems are similar to those of "Landowner" >> >> Plan reference. A single number. For each such number there are >> columns for: Name and Description which may describe one or more >> buildings; e.g "2 Houses" or "House, outbuildings and garden"; or >> land. State of cultivation - land only Quantities or statute measure >> Greater Tithe Lesser Tithe >> >> Several plan items may be listed against an "Occupier" and apart from >> the individual quantities& tithes for each item these are summed >> against the "Occupier". >> >> Neither the pages nor any other items are numbered except the plan >> entries. >> >> On the face of it this is a basic master/detail relationship extending >> to two levels of detail: >> >> One Landowner to one or more Occupier One Occupier to one or more Plan >> item >> >> However as both Landowner and Occupier are themselves potentially >> identified by multiple names or descriptions there is no existing >> content above Plan item which can be used as keys to hang this >> together. >> It would be possible to create artificial keys such as >> auto-incrementing numbers or UUIDs (preferable for a collaborative >> project) but, at least for a relational solution, this results in the >> schema including two tables with no content other then the artificial >> key. >> > > Unique keys are always useful. True. >I can only see one here, that of the plot of land. Me too. That's why I think it will be necessary to use artificial keys. > > What I don't know is whether the beneficiary of the tithe is unique? Far from it. From the sample I've seen the beneficiaries are the same for the whole page. > Are Greater and Lesser tithes names for different beneficiaries? Or are > there other categories of tithe recipient? See http://en.wikipedia.org/wiki/Vicar_%28Anglicanism%29#Greater_tithes > > Sounds to me that you need several sheets of paper, each charting a > different entity. Not too many responses here except this & another off-group. I'd hoped to get some specific ideas to compare with my own idea about data structure which is: Data types Person: Surname : string Forenames : list of string (probably implement in Free Pascal so that would be TStringList) Qualification : string (e.g. Executors of) PersonList : list of Name StatuteMeasure Acres : smallint Roods : smallint Perches : smallint OldMoney Pounds : smallint Shillings : smallint Pence : smallint (assumes that further investigation doesn't reveal ha'pence or farthings!) Classes Ownership LandOwnership_ID : UUID LandOwners : PersonList Occupation Occupation_ID : UUID Occupiers : PersonList TotalQuantity : StatuteMeasure TotalGreatTithes : OldMoney TotalLesserTithes : OldMoney LandsAndPremises LandsAndPremises_ID : UUID ReferenceNumber : smallint NameAndDescription : string StateOfCultivation : string Quantities : StatuteMeasure GreaterTithe : OldMoney LesserTithe : OldMoney Subject to further investigation One or more LandsAndPremises are associated with one Occupation One or more Occupations are associated with one Ownership The associations would be implemented by including the ID of the master class within the detail class. This is sufficient to deal with what I've seen so far. Alternatively I could take the pessimistic view & define association classes: OwnershipOccupation LandOwnership_ID Occupation_ID OccupationPremises Occupation_ID LandsAndPremises_ID -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk