DB 를 구성하면서 고민하는 부분이 바로
교집합이죠
자신이 원하는 데이터를 가공하여 보여주기 위해서는
각각의 테이블에서 join 을 하거나 아니면 하나의 테이블에서 가져오거나 하는 이슈..
사실 하나의 테이블에서 가져오는게 더 빠를 수도 있습니다만
각각의 테이블에서 필요한 정보만 가져오는게 관리 및 가독성의 측면에서 좋을 수 있습니다.

사실 속도 이슈는 key 를 어떻게 구성하고 어떠한 데이터를 가져가느냐의 이슈죠
join 을 많이 건 테이블도 사실 각각의 unique 한 key 를 통해 가져간다면 인덱싱으로 인한 퍼포먼스가 좋아지는거구요.
ORM 도 각각의 테이블을 객체화 하면서 생긴 이슈가
이처럼 다수로 쪼개진 테이블을 가져가면서의 고민이 생겼다고 볼 수 있습니다.
따라서 orm 자체에서도 join  을 고려하게 되거나 위 링크를 올린거처럼 소속하게끔 만드는 이슈가 존재하죠.
orm 자체에서는 1 table 1 select 가 제일 효과적입니다.

국내에서 개발할때 1대1, 1대다, 다대다 로 얘기를 많이 했었습니다.
그 다음에 위의 말씀하신것들중 일부가 들어가는것인데
DB 쪽을 깊게파면 수학쪽에 미분 적분과 분포도까지 들어가게 되더군요.

국내 서적중에 유명한 서적으로 2권이 있는데
실무용이라기보다는 개념적인 서적이였습니다.

http://book.naver.com/bookdb/book_detail.nhn?bid=105559

Db 쪽을 공부하실 경우라면, 오라클을 추천 드리고 싶고
DB 쪽을 공부하시면서 웹쪽으로 파시다보면
디자인패턴까지 손대게 되실지도 모르는...

국내 기준입니다.

ORM 쪽은 원도우 응용쪽에서는 사용 하는걸 못봤고, 저 또한 메모리 테이블을 선호하구요.
java 쪽은 맴핑쪽으로 사용하는 방식으로 많이 개발 하더군요.

php 쪽은 관련 엔진들이 몇개 있던데, 사용 빈도율은 없는것 같습니다.
단, php 쪽 프레임워크중 상위 몇개가, 맴핑과 실제 orm 방식으로 지원하는 기능이 있습니다.

orm 방식중 매핑으로 만들어진 엔진은 pk 기준으로 만들어진 것으로 알고 있어서
그누보드는 wr_id 로 pk 을 잡아서 게시판이 꾸며져 있다고 생각하시면 될듯합니다.