Uma tabela filha (também conhecida como entidade fraca ) é uma tabela cujos atributos de chave primária dependem em outra tabela, portanto, a tabela filha é identificada ou parcialmente identificado por linhas na tabela de que depende (pai). As linhas em uma tabela filha não podem existir sem uma linha correspondente em sua tabela pai.

Para ilustrar, vamos dar um exemplo simples e completamente relevante que todos conhecemos:Pais e filhos no contexto da família . Podemos modelar esse relacionamento com tabelas assim:



No modelo acima, cada linha no Parents a tabela é identificada exclusivamente por um SSN . O SSN é um atributo intrínseco e único para cada pai, portanto, é uma entidade autônoma ou "forte" porque não depende de outra tabela para definir sua identidade.

Crianças, no entanto, requer um pai para existir (Parent_SSN deve referência a um SSN existente em Parents tabela).

Observe a chave primária composta (Parent_SSN, Name ) em Children tabela. Isso significa que as crianças são identificadas de forma única pela combinação de Parent_SSN e Name . Você não pode consultar um filho individual com base apenas no Name campo porque vários pais podem ter filhos com o mesmo nome. Da mesma forma, você não pode consultar um filho individual com base apenas no Parent_SSN campo porque um pai pode ter muitos filhos. Levando isso em consideração, as crianças são parcialmente identificadas pelos pais, portanto identificando relação.

Mas as crianças também não podem ser identificadas exclusivamente por um SSN? Por que sim, certamente. Vamos em frente e ajustar nosso modelo para incluir isso:



Nesta versão do modelo, observe que introduzimos o SSN campo para Children . A identidade única de filhos agora é definido por seu próprio SSN intrínseco e exclusivo . Sua identidade não depende mais nos Parents tabela. Embora o Parent_SSN campo ainda referencia o SSN dos Parents tabela, ela não faz parte da identidade única da criança, assim os pais têm um não-identificação relacionamento com seus filhos, e ambas as tabelas agora podem ser consideradas entidades autônomas "fortes".

Como aparte, esta versão do modelo tem algumas vantagens sobre a primeira:

• Um pai pode agora ter dois ou mais filhos com o mesmo nome, enquanto a integridade da entidade a> restrição no modelo anterior não permitiria isso.
• Você pode permitir o Parent_SSN campo para conter NULL para explicar o caso de você ter dados sobre a criança, mas não saber quem é o pai dela.

Em ambos os modelos acima, o Parents table é considerada a tabela pai do Children tabela. No entanto, em não identificáveis relacionamentos como no segundo modelo, Parents é apenas uma tabela pai no contexto da chave estrangeira Parent_SSN porque Parent_SSN referências/dependências em SSN em Parents tabela, mas não têm qualquer papel na definição da identidade real das crianças.

Para ilustrar por que o contexto é importante ao decidir quais tabelas são pai/filho, considere o seguinte exemplo envolvendo uma dependência circular:



Neste exemplo, funcionários e departamentos são identificados exclusivamente por seus próprios atributos e não derivam nenhuma parte de sua identidade de outras tabelas.

Aqui, temos dois relacionamentos não identificáveis:um funcionário trabalha para um departamento (DeptNo no Employee table), e um departamento é gerenciado por um funcionário (ManagerSSN no Department tabela). Qual é a tabela pai? ...Mesa infantil?

Depende do contexto - de qual relacionamento de chave estrangeira você está falando? A tabela Department seria considerada a tabela pai no contexto de DeptNo no Employee tabela porque DeptNo é referenciado/dependente no Department tabela.

No entanto, a tabela Employee seria considerada a tabela pai no contexto de ManagerSSN no Department tabela porque ManagerSSN é referenciado/dependente no Employee tabela.