Должны ли прародительские внешние ключи храниться в таблице внуков?

Каковы преимущества и недостатки включения дедушек и дедушек + внешние ключи в таблицу.

Например, если моя объектная модель выглядит так, как показано ниже. (Значительно упрощено, поэтому его нельзя использовать для иерархической рекурсивной таблицы.)

a {aId, bCollection, ...}
b {bId, cCollection, ...}
c {cId, dCollection, ...}
d {dId}

На ум приходят два варианта модели данных:

вариант 1:

a {pkA, ...}
b {pkB, fkA, ...}
c {pkC, fkB, ...}
d {pkD, fkC, ...}

вариант 2:

a {pkA, ...}
b {pkB, fkA, ...}
c {pkC, fkB, fkA, ...}
d {pkD, fkC, fkB, fkA, ...}

Вариант 1 более нормализован, и вставки и обновления будут проще, но я вижу, что запросы становятся довольно сложными, особенно со многими отношениями и / или составными ключами.

Вариант 2 усложняет вставки и обновления, но извлечение отчетов будет Полегче. Кроме того, база данных будет больше, но меня это не особо беспокоит, поскольку она все равно довольно мала.

Но это довольно незначительные проблемы по сравнению с проблемами, которые могут возникнуть с ORM-подобной структурой сущностей. Я склоняюсь к варианту 2, потому что я хотел бы получить доступ к внукам напрямую от родителя следующим образом:

Class A { id, bCollection, cCollection, dCollection, ... }
Class B { id, cCollection, dCollection, ... }
Class C { id, dCollection, ... }
Class D { id, ...}

Изящно ли обрабатывает Entity Framework 4.0 эту ситуацию? Каковы плюсы и минусы двух вариантов? Есть ли еще одна альтернатива, которую я должен рассмотреть?

Или, проще говоря, Как, черт возьми, можно погуглить с таким вопросом?!?

Еще одно замечание: как и многие из вас, должно быть, нутро и голова сильно склоняются к варианту А, но я знаю, что прочитал статью msdn, в которой подробно рассказывается о почему вариант Б лучше. К сожалению, найти не могу. : (

заранее спасибо за ваши мысли.