In designing a DB schema is it generally the case that tables representing a child property (in the OO world) should reference their parent?

Question

It's been a while since I've had to work with relational databases (I've been avoiding it as much as I can in my personal projects, and at work we use an object database) so I'm fairly sure this is the correct way, but I wanted to make sure.

When modeling a relational database from an existing object hierarchy it is generally the case that non-primitive child properties should go in their own tables with a reference to the ID of the parent object (table-row thingy). It seems a little backwards from an OO standpoint (and obviously I realize that relational is way different from OO) but I guess it's the only way to represent one-to-many relationships (which feels like it should be more accurately described as many-to-one as the one parent doesn't reference the many children, it's many child entries that reference the one parent)

Answer 1

Yes.

In one-to-many relationships, the child points to the parent.

In many-to-many relationships (and one-to-many relationships with attributes, ternary relationships, etc.), you have relation tables.

In one-to-one relationships, you either merge the tables, or either entity can point to the other.

While this is by no means the only way, it certainly is the only sane way of representing relationships. All other methods I can think of break normalization (in fact, I can't even think of another 1NF method, let alone 3NF).