What I’m suggesting is a unique identifier for each record; primary key being an applicable term for it. Other databases can then look for it in your Contacts to find anything that record contains. If you have two Mary Smiths, but each has a unique identifier, there’s no confusion on making matches. The key, id or whatever you call it doesn’t need to be displayed anywhere. It just needs to exist in the background for the software to use as users only deal with a Mary Smith.
As your other databases come into existence they don’t need a name field or any other field, aside from the identifier, that contains data from the Contacts. That can always be obtained instantly via lookups, arrays or other Panorama Functions. Mary Smith’s name, address and family members are instantly obtainable without redundant data storage.
Regarding family members in Contacts, there are lots of ways to do it, but say Mary has an ID of 123. Another field could be used to give all of her family members a group id of xyzzy, unique to the group. Or they could be 123.1, 123.2…
One of the beauties of Panorama is that you don’t have to overthink it up front. You can change, add or delete fields readily, so as you discover a new need, you add a new field or two. Or split an existing field. It’s normal for Panorama databases to evolve rather than be replaced with new designs.
Start simple to learn the basics and build it out.