I will have another look later to see if I can answer your questions, but I think it would be worth thinking about your data in another way.
So…rather than making it data-centric, make it query-centric. Instead of “what answers do I have” it is “what questions do I have”. What are the scenarios for how you are pulling this out ? That tends to drive non-relational database design.
One of the things that is very different is the idea of denormalisation, i.e. that redundant data is not bad. If you are familiar with relational database design, then this is (almost) entirely opposite to the way you think.
Bubble can link things in several ways, but the simplest is just to embed one this in another. This tends to be how you do the “one to many” situation.
So instead of having an “Art Object” and “Photo Of Object” and linking the two with a key … you put the Photo inside the Art Object thing.
So our art object might look like…
type : Painting
title : The Man
medium : oil on canvas
image : //filepath/filename etc
view : front
location : studio}
image : //filepath/filename etc
view : rear
location : gallery}
date : 1/1/2016
So here we have two “things”. The Object thing and the Photo thing.
In Bubble this means a field with type Photo which is a List. You don’t need to worry about ids and relationships, because you embed the photo in the object it relates to, in the same way you might embed an excel in a word document. The relationship is explicit in the document, not implicit in a field in the file.
You can of course embed Object things in other Objects. So this would be a field of type Object on the Object, which is a list, and this could be your “related objects” concept. This is how we do things like “friend list”. The User thing has an embedded list of other users. If I make someone a friend I just add one user to the other’s list. That user might exist as an embeded user in hundreds of other other users, but it makes the QUERY easier (it just works). We don’t worry about redundancy, in fact we look to achieve denormalisation where possible. That way the data you want is there when you want it, you don’t have to go navigating multiple joins and things. Want a repeating group with photos of the object … you have it already.
Excel makes everything a bit hierarchical, so it can be difficult to visualise this (arguable word is a better tool !) …
But on first glance I would say you add Photo as a list to Object, as well as Series (it will be duplicated, but don’t worry about redundancy). And that you embed Exhibition in Photo. Location is embeded in Object and Exhibition.
Now… it looks like you might have a many-to-many relationship with your various relationships between objects ?
That is probably the only slightly tricky one to model, and it depends (again) on what you want to query. But in this case you might want to have a thing that holds an “index” to the two things and the relationship type.
object1name : “The Man”
object2name : “The Tree”
relationship : “a sketch of”
That would, potentially, be better than embeding the BOTH objects in there. Just think about how you want to query.