Working out validity of table relationship Question Background:
In a quest to improve my skill set with TSQL programming I'm designing a 'simple' database schema for a zoo.
In all I currently have 4 tables but am having an issue working out the relationship) between the zoo itself and its employees (the zoo keepers in this case).
Schema:

Is this a valid schema and relationship? Should there even be a relationship between these two tables Or should they be completely separate?
Though a one-to-many relationship exists between the zoo and the keepers, it's not a terribly useful relationship to model, since every single keeper works at a single zoo. This is probably why you are having an issue. Your Zoo table is not really set up to relate to anything unless you have more than one zoo. You could add a Zoo_ID field to both the Zoo and Keepers table. But, with one zoo, what's the point?  

For more than one zoo, a one-to-many relationship must be explicitly laid out using keys in order for you to track which zoo a keeper works for. Each zoo gets a unique Zoo_ID (primary key), and each keeper has a Zoo_ID field that matches up with one of the Zoo_Ids (foreign key). 

It gets trickier if your keepers can work at multiple zoos. Now you have a many-to-many relationship. You could have multiple rows in your keeper table, one per zoo, but that's kind of tacky and duplicates information. The proper way to represent the relationship is a junction (join) table with the id of the keeper and the id of the zoo. If you imagine a diagram with each zoo and keeper drawn out, and lines connecting the keepers with the zoos, each row in your junction table is like one of those lines, with the zoo's id on one end, and the keeper's id on the other.

tl;dr: Yes, it's a valid relationship. No, you shouldn't bother modeling it, unless you plan on multiple zoos in the future.