C. J. Date entra em detalhes sobre isso no Capítulo 7 e no Apêndice B da SQL e Teoria Relacional . Você está certo, não há nada na teoria relacional que proíba o tipo de dados de um atributo de ser uma relação em si, contanto que seja o mesmo tipo de relação em cada linha. Seu exemplo se qualificaria.
Mas Date diz que estruturas como esta são "geralmente - mas não invariavelmente - contra-indicadas" (ou seja, uma Idéia Ruim) porque as hierarquias de relações são assimétricas . Por exemplo, uma transformação de estrutura aninhada para uma estrutura "plana" familiar nem sempre pode ser revertida para recriar o aninhamento.
Consultas, restrições e atualizações são mais complexas, mais difíceis de escrever e mais difíceis para o RDBMS suportar se você permitir atributos com valor de relação (RVA).
Isso também confunde os princípios de design do banco de dados, porque a hierarquia das relações melhor não é tão clara. Devemos projetar uma relação de Fornecedores com um RVA aninhado para peças fornecidas por um determinado Fornecedor? Ou uma relação de peças com um RVA aninhado para fornecedores que fornecem uma determinada peça? Ou armazene os dois para facilitar a execução de diferentes tipos de consultas?
Este é o mesmo dilema que resulta do banco de dados hierárquico e do modelos de banco de dados orientados a documentos . Eventualmente, a complexidade e o custo de acessar estruturas de dados aninhadas levam os designers a armazenarem dados de forma redundante para facilitar a pesquisa por diferentes consultas. O modelo relacional desencoraja a redundância, de modo que os RVAs podem trabalhar contra os objetivos da modelagem relacional.
Pelo que entendi (não os usei), Rel e Dataphor são projetos de RDBMS que suportam atributos com valor de relação.
Re comentário de @dportas:
Os tipos estruturados fazem parte do SQL-99, e o Oracle os suporta. Mas eles não armazenam múltiplas tuplas na tabela aninhada por linha da tabela base. O exemplo comum é um atributo "endereço" que parece ser uma única coluna da tabela base, mas tem outras sub-colunas para rua, cidade, código postal, etc.
tabelas aninhadas também são suportados pelo Oracle, e eles permitem várias tuplas por linha da tabela base. Mas eu não estou ciente de que isso faz parte do SQL padrão. E lembre-se da conclusão de um blog: "Nunca usarei uma tabela aninhada em uma instrução CREATE TABLE. Você gasta todo o seu tempo UN-NESTING para torná-los úteis novamente!"