Help Thinking thru Medieval Maps + Manuscripts Dbase

[mapsgal]

Hello,

 

I am trying to think through a relational database involving medieval maps as linked to manuscripts.

 

I have set up the manuscript end of the database. What I am trying to figure out is whether or not I should make the maps in each manuscript relational or not. Each manuscripts comes with on average 21 maps but these can sometimes be missing, so the numbers can fall. Some contain only 1-2 maps and others no maps at all. On the other end there are a few manuscripts that contain 100+ maps and images. There is in other words, no steady amount. If I had to pick a fixed number I would opt for 21 since those are the map manuscripts that I work with the most.

 

I could set this up as a flat database with container options for 25 maps and info for each one repeated and then fill in those as needed according to each manuscript.

 

But my better sense tells me that I need to make this relational and set up the maps in a separate database and link them. Then the question is do I need one separate database for all the maps or one for each type of map. So, for instance, there are world maps, maps showing the Mediterranean, maps showing North Africa and Spain, etc. It would be useful to be able to search for all maps of the Mediterranean or the world across all manuscripts but this is not essential because I am also a Lightroom user and I can tag my images to create collections of maps.

 

My own experience with FM databases varies with the decades. (My skill level should read Beginner not Intermediate) Back in the early days of FM (FM4) when it was owned by Claris (yes, I go back that far) I designed a super complicated manuscript-map database. Then I stumbled over the lack of a big container field for notes so I ended up used printed copies and hand-filling out the data. Life, research, teaching, deprived me of time to work on this again. I bought FM12 ran out of time and now we have FM13 and I cannot afford to buy the upgrade. So I have to do this on FM12 and limp along until FM14 comes out. At which point I will spring for the upgrade. 

 

It sounds odd to say this in 2015 but I really love those delicious container fields that can now even take a pdf. Wow!

 

Thanks for any advice on this crazy complicated database for a poverty-struck academic who cannot afford to hire a professional to help her out.

 

[jbante]

Yes, you should make maps a child table (not the same thing as a separate database) of your manuscript table.

 

Whether or not you need separate tables for different types of maps depends on how differently you treat different types of maps and how different are the data that you track for different map types. If you just want to be able to search for maps by type, then you just need a type field in your map table, and you should store them all in the same table.

[mapsgal]

Thanks jbante. 

Can I pick your brain for a little while longer?

 

Each map needs a separate entry. World, Mediterranean, etc., with different pictures. Sometimes the details are different and sometimes they overlap.

So, for instance, the number of places on each map will be different. But I can address that by plugging in extra place fields—unless the list of places has to be a child table of the maps table.

Other details may overlap. Such as info on pigments used, decorations, etc.

 

If I create a single map table and need to link back 21 different map entries to the main manuscript table is that possible? Or is the relation 1-1?

[jbante]

I still think you should keep the maps in a single table. When one map doesn't have details that other maps do, you can leave those fields empty.

 

Having multiple places represented by a map should be represented by a child table of the map table. If you also want to be able to look at a place and see what maps cover that place, you may want to have an intermediary join table between a map and a place so that many maps can link to the same place, and vice-versa. If you don't track any additional information about a place that's independent of the map it's on, just the one child table should be fine.

 

It is possible to have several map records linked back to one manuscript. Both tables should have what we call a "primary key" field, that is guaranteed to be unique and immutable — usually a UUID (universally unique ID, with the Get ( UUID ) function) or auto-enter serial number. Your map table would then have a "foreign key" field containing the ID of the manuscript record it's linked to. In your relationship graph, you would make a relationship between the two tables (table occurrences, technically) by connected the ID field of the manuscript to the foreign key field in the map table. The field list can get confusing fast without a solid naming convention.

[mapsgal]

Hi,

 

I am using an MssIDfk on the child tables. I have one for notes and one for maps.

I am having some update issues though. For the notes table I am using a timestamp and these timestamps do not always come through into the main layout properly. I am using portals to place these in the main layout but these portals have issues. For instance, with the maps there are too many to display in one stretch. Do I repeat the portal to get another display box?

I hope that my queries make sense. 

What I am wondering is if there is an alternative to using portals. Or are they my only option?

[jbante]

Do you have scrollbars turned on in your portal?

 

It is also possible to have multiple portals to continue the list. Just set the "Initial row" value for the 2nd (and 3rd, and...) portal to the next row after what's displayed in the 1st.

 

Another display option is to have a Go to Related Records button that opens the related child records in a list view layout.

[mapsgal]

Thanks!
Yes, I have scroll bars turned on. I have so much data that I am using a tabbed structure which was making my portals a tad jumpy. But I have them laid out now.

Could you further explain: "set the "Initial row" value for the 2nd (and 3rd, and...) portal to the next row after what's displayed in the 1st."

I will do a list view layout as you recommend both for my manuscripts and the maps.
I am almost done. Hope to start entering data tomorrow. The more I work with FM the more I realize there is to learn. Sadly I don't have the extra time to put into fully mastering it right now. Must make do with what I have managed to set up. Down the road I am going to have to set up more child tables and at that point I will have to master join tables. I am under a great deal of pressure to start writing my next book so sadly I cannot devote the time now.

Is there some way I can share my structure with you to take a look at? I could do screenshots but that won't provide the full picture.
My timestamps are still messing up from time to time 

[Lee Smith]

As I said here in your other posts link, attach a file.