Relational Data Modeling question - 2 different tables needing the same "sub-data"

I've read many of the answers here about 1-1 relationships, modeling object-type relationships, etc. I am trying to do something that I'm just not sure what is the right way.

I have 2 different tables that both need to reference/contain lists of polygons (the polygon is actually represented as an outer loop and any number of inner loops to represent holes in the surface). Each of the 2 tables is a completely different set of attributes.

Here is a view of the model with only 1 table referencing the polygons:

Now I want to have a second table that each row also represents a collection of of polygons. I know how to do this from an Object-oriented point of view, but the relational view has me confused as to what is the right way.

One way is to add another foreign key to the polygonwitholes table, and one is null while the other is populated. That is shown here:

This just doesn't seem right. So I thought about an intermediate table, but the relationships seem more object-oriented than relational. Is this an unreasonable way to do it, to have an either/or on those foreign keys? or I could have one field that is an integer and not add any constraint to the database that it is a foreign key to another table, and use it for whichever table is used at that time? From a query perspective, I will have to retrieve all the points in each of the polygons for a row in either table1 or table2.

So one of the options I came up with was this, but then I think about how to do queries, and something just doesn't see开发者_StackOverflowm right:

I know that for a true data modeler, this will be an obvious question! This site has been great for me, this is my first question, and I hope it makes sense! So are there any suggestions of how this should be modeled?

(Ok, I tried to post, but the images didn't come up. Going to try to get someone to post them for me)

---

So I made a decision after consulting with people.

I went with the 3rd-normal form and made intermediate tables to tie the surfaces to polygons and the grids to polygons. The final solution has the following tables:

Surface (ID primary key)
SensorGrid (ID primary key)

Polygon(ID primary key)
Point(ID primary key, PolygonID foreign key)

Surface_Polygon(surfaceID, polygonID: composite primary key)
SensorGrid_Polygon(sensorGridID, polygonID: composite primary key)

So the 2 intermediate tables tie the polygons to whether they are in a grid or a surface. I will check to make sure the extra join doesn't impact performance too badly. It is the cleanest solution, and if the performance really needs to be optimized in the future, i will consider making separate tables for SurfacePolygon, SurfacePoint, SensorPolygon, and SensorPoint and get rid of the intermediate tables.

Thank you for your help.

---

Ok I am going to take a stab at this. If this is truly a 1 to 1 and that a given PolygonwithHoles cannot be both a surface and a grid then I would use your last example but I would drop the container table is it is completely redundant. That table could always be created using a sql union if for some reason you wanted to get all the polygonwithholes as surfaces and grids.