I'm sticking with my theme. We may come back to your tables, but for the moment, I'd like to see a data model using names of the "things"/"entities you have described.
For each of the things, we need to see how they relate, based on your business.
Here is a data model from Barry Williams' site
http://www.databaseanswers.org/tutor...al_slide_9.htm
Here's an example of the business rules/facts from Barry Williams' site (for demonstration purposes)
Code:
B. THE THINGS OF INTEREST include :-
B.1 Addresses.
B.2 Customers.
B.3 Deliveries
B.4 Orders.
B.5 Payments
B.6 Products.
B.7 Suppliers.
C. These THINGS are Related as follows :-
C.1 A Customer can have zero,one or many ORDERS.
C.2 A CUSTOMER_ADDRESS can be associated with only one ADDRESS.
C.3 A CUSTOMER_ADDRESS can be associated with only one CUSTOMER.
C.4 A DELIVERY is associated with just one ORDER.
C.5 An ORDER must be associated with one and only one CUSTOMER.
In different applications in the real world, it is possible that an ORDER can
be associated with more than one CUSTOMER,but in our example, it's only one.
C.6 An ORDER can be associated with one or many PRODUCTS.
C.7 A PAYMENT must be associated with one and only one ORDER.
Please NOTE: This does not mean there is anything wrong with your set up. I just don't like table1 and table2 as names--they convey no business meaning (to me).
In your samples:
In 1 only 1 link so these field values have to match in both tables. ConservationAction must match, but any Habitat is OK.
In 2 you have 2 links/joins, so values of both corresponding fields in each table have to match.
You are dealing with records that have equal values for ConservationAction and for Habitat.