|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
RESUMO DA AULA, CRIBS
Base de dados. Relacionamentos de classe de entidade (mais importante)
Diretório / Notas de aula, folhas de dicas Índice (expandir) Aula nº 12. Relacionamentos de classes de entidades Assim, todos os conceitos pelos quais passamos, nomeadamente diagramas e seus tipos, multiplicidades e tipos de relações, bem como tipos de migração de chaves, vão agora ajudar-nos a percorrer o material sobre as mesmas relações, mas já entre classes específicas de entidades. Entre eles, como veremos, também existem conexões de vários tipos. 1. Relacionamento recursivo hierárquico O primeiro tipo de relacionamento entre classes de entidade, que iremos considerar, é o chamado relacionamento recursivo hierárquico. Em geral recursão (ou link recursivo) é a relação de uma classe de entidade consigo mesma. Às vezes, por analogia com as situações da vida, essa conexão também é chamada de "anzol". Relacionamento recursivo hierárquico (ou simplesmente recursão hierárquica) é qualquer relacionamento recursivo do tipo "no máximo um para muitos". A recursão hierárquica é mais comumente usada para armazenar dados em uma estrutura de árvore. Ao especificar um relacionamento recursivo hierárquico, a chave primária da classe de entidade pai (que neste caso específico também atua como uma classe de entidade filha) deve ser migrada como uma chave estrangeira para os atributos não chave obrigatórios da mesma classe de entidade. Tudo isso é necessário para manter a integridade lógica do próprio conceito de "recursão hierárquica". Assim, levando em consideração tudo o que foi dito acima, podemos concluir que um relacionamento recursivo hierárquico só pode ser não necessariamente não identificador e nenhum outro, pois se fosse utilizado qualquer outro tipo de relacionamento, os valores Null para a chave estrangeira seriam inválidos e a recursão seria infinita. Também é importante lembrar que os atributos não podem aparecer duas vezes na mesma classe de entidade com o mesmo nome. Portanto, os atributos da chave migrada devem receber o chamado nome da função. Assim, em um relacionamento recursivo hierárquico, os atributos de um nó são estendidos com uma chave estrangeira que é uma referência opcional à chave primária do nó que é seu ancestral imediato. Vamos construir uma apresentação e diagramas-chave que implementam a recursão hierárquica em um modelo de dados relacional e dar um exemplo de um formulário tabular. Vamos criar um diagrama de apresentação primeiro:
Agora vamos construir um diagrama chave mais detalhado:
Considere um exemplo que ilustra claramente um tipo de relacionamento como um relacionamento recursivo hierárquico. Vamos receber a seguinte classe de entidade, que, como no exemplo anterior, consiste nos atributos "Código Antepassado" e "Código do Nó". Primeiro, vamos mostrar uma representação tabular dessa classe de entidade:
Agora vamos construir um diagrama representando esta classe de entidades. Para isso, selecionamos na tabela todas as informações necessárias para isso: o ancestral do nó com o código "um" não existe ou não está definido, a partir disso concluímos que o nó "um" é um vértice. O mesmo nó "um" é o ancestral dos nós com o código "dois" e "três". Por sua vez, o nó com o código “dois” tem dois filhos: o nó com o código “quatro” e o nó com o código “cinco”. E o nó com o código "três" tem apenas um filho - o nó com o código "seis". Então, levando em consideração tudo o que foi dito acima, vamos construir uma estrutura em árvore que reflita as informações sobre os dados contidos na tabela anterior:
Assim, vimos que é realmente conveniente representar estruturas de árvore usando um relacionamento recursivo hierárquico. 2. Comunicação recursiva de rede A conexão recursiva de rede de classes de entidade entre si é, por assim dizer, um análogo multidimensional da conexão recursiva hierárquica pela qual já passamos. Somente se a recursão hierárquica for definida como um relacionamento recursivo "no máximo um para muitos", então recursão de rede representa o mesmo relacionamento recursivo, apenas do tipo "muitos para muitos". Devido ao fato de que muitas classes de entidades participam dessa conexão em cada lado, ela é chamada de conexão de rede. Como você já pode imaginar por analogia com a recursão hierárquica, os links do tipo recursão de rede são projetados para representar estruturas de dados grafos (enquanto os links hierárquicos são usados, como lembramos, exclusivamente para a implementação de estruturas de árvore). Mas, como na conexão do tipo de recursão de rede, as conexões do tipo "muitos para muitos" são especificadas, é impossível prescindir de seu detalhamento adicional. Portanto, para refinar todos os relacionamentos muitos-para-muitos no esquema, torna-se necessário criar uma nova classe de entidade independente que contenha todas as referências ao pai ou descendente do relacionamento Antepassado-Descendente. Tal classe é geralmente chamada classe de entidade associativa. Em nosso caso particular (nos bancos de dados a serem considerados em nosso curso), a entidade associativa não possui atributos adicionais próprios e é chamada chamando, porque nomeia os relacionamentos Antepassado-Descendente fazendo referência a eles. Assim, a chave primária da classe de entidade que representa os hosts deve ser migrada duas vezes para as classes de entidade associativa. Nesta classe, as chaves migradas juntas devem formar uma chave primária composta. Do exposto, podemos concluir que o estabelecimento de links ao usar a recursão de rede não deve ser totalmente identificador e nada mais. Assim como ao usar um relacionamento recursivo hierárquico, ao usar a recursão de rede como um relacionamento, nenhum atributo pode aparecer duas vezes na mesma classe de entidade com o mesmo nome. Portanto, como da última vez, é estipulado especificamente que todos os atributos da chave de migração devem receber o nome da função. Para ilustrar a operação da comunicação recursiva de rede, vamos construir uma apresentação e os principais diagramas que implementam a recursão de rede em um modelo de dados relacional. Vamos começar com um diagrama de apresentação:
Agora vamos construir um diagrama chave mais detalhado:
O que vemos aqui? E vemos que ambas as ligações neste diagrama chave são ligações “muitos para um”. Além disso, a multiplicidade “0... ∞” ou a multiplicidade “muitos” está no final da conexão voltada para a classe de nomenclatura de entidades. Na verdade, existem muitos links, mas todos eles se referem a um código de nó, que é a chave primária da classe de entidade “Nodes”. E, finalmente, vamos considerar um exemplo ilustrando a operação de tal tipo de conexão por uma classe de entidade como recursão de rede. Vamos receber uma representação tabular de alguma classe de entidade, bem como uma classe de entidade de nomenclatura contendo informações sobre links. Vamos dar uma olhada nessas tabelas. Nós:
Links:
De fato, a representação acima é exaustiva: ela fornece todas as informações necessárias para reproduzir facilmente a estrutura do grafo aqui codificada. Por exemplo, podemos ver sem obstáculos que o nó com o código "um" tem três filhos, respectivamente, com os códigos "dois", "três" e "quatro". Também vemos que os nós com os códigos "dois" e "três" não têm descendentes, e um nó com o código "quatro" tem (assim como o nó "um") três descendentes com os códigos "um", "dois" e três". Vamos desenhar um gráfico dado pelas classes de entidade dadas acima:
Assim, o gráfico que acabamos de construir são os dados para os quais as classes de entidade foram vinculadas usando uma conexão do tipo recursão de rede. 3. Associação De todos os tipos de conexões incluídos na consideração de nosso curso particular de palestras, apenas duas são conexões recursivas. Já conseguimos considerá-los, são links hierárquicos e recursivos de rede, respectivamente. Todos os outros tipos de relacionamentos que temos que considerar não são recursivos, mas, via de regra, representam um relacionamento de várias classes de entidades pai e várias classes de entidades filhas. Além disso, como você pode imaginar, as classes de entidade pai e filho agora nunca coincidirão (na verdade, não estamos mais falando sobre recursão). A conexão, que será discutida nesta seção da palestra, é chamada de associação e refere-se justamente às conexões do tipo não recursivo. Então a conexão chamada Associação, é implementado como um relacionamento entre várias classes de entidade pai e uma classe de entidade filha. E ao mesmo tempo, o que é curioso, essa relação é descrita por relações de vários tipos. Também é importante notar que pode haver apenas uma classe de entidade pai durante a associação, como na recursão de rede, mas mesmo em tal situação, o número de relacionamentos provenientes da classe de entidade filha deve ser pelo menos dois. Curiosamente, em associação, assim como na recursão de rede, existem tipos especiais de classes de entidade. Um exemplo de tal classe é uma classe de entidade filha. De fato, no caso geral, em uma associação, uma classe de entidade filha é chamada classe de entidade associativa. No caso especial em que uma classe de entidade associativa não possui seus próprios atributos adicionais e contém apenas atributos que migram junto com as chaves primárias das classes de entidade pai, essa classe é chamada classe de nomeação de entidades. Como você pode ver, há uma analogia quase absoluta com o conceito de entidades associativas e de nomenclatura em uma conexão recursiva de rede. Na maioria das vezes, uma associação é usada para refinar (resolver) relacionamentos muitos-para-muitos. Vamos ilustrar esta afirmação. Deixe-nos, por exemplo, o seguinte diagrama de apresentação, que descreve o esquema de recepção de um determinado médico em um determinado hospital:
Este diagrama significa literalmente que há muitos médicos e muitos pacientes no hospital, e não há outro relacionamento e correspondência entre médicos e pacientes. Assim, é claro, com tal banco de dados, nunca ficaria claro para a administração do hospital como marcar consultas com diferentes médicos para diferentes pacientes. É claro que as relações muitos-para-muitos aqui utilizadas precisam apenas ser detalhadas para concretizar a relação entre os vários médicos e pacientes, ou seja, para organizar racionalmente a agenda de consultas de todos os médicos e seus pacientes em o hospital. E agora vamos construir um diagrama de chaves mais detalhado, no qual já detalhamos todos os relacionamentos muitos-para-muitos existentes. Para fazer isso, vamos introduzir uma nova classe de entidade, vamos chamá-la de "Receber", que funcionará como uma classe de entidade associativa (mais adiante veremos porque esta será uma classe de entidade associativa, e não apenas uma classe de nomenclatura entidades, sobre as quais falamos anteriormente). Portanto, nosso diagrama de chaves ficará assim:
Então, agora você pode ver claramente porque a nova classe "Receive" não é uma classe de nomeação de entidades. Afinal, esta classe possui seu próprio atributo adicional "Data - Hora", portanto, de acordo com a definição, a classe recém-introduzida "Recepção" é uma classe de entidades associativas. Esta classe "associa" as classes de entidades "Médicos" e "Pacientes" entre si por meio do horário em que esta ou aquela consulta é realizada, o que torna muito mais conveniente trabalhar com esse banco de dados. Assim, ao introduzir o atributo "Data - Hora", organizamos literalmente o tão necessário horário de trabalho de vários médicos. Também vemos que a chave primária externa "Código do médico" da classe de entidade "Recepção" refere-se à chave primária de mesmo nome da classe de entidade "Médicos". Da mesma forma, a chave primária externa "Código do Paciente" da classe de entidade "Recepção" refere-se à chave primária de mesmo nome na classe de entidade "Paciente". Neste caso, naturalmente, as classes de entidade "Médicos" e "Paciente" são as pai, e a classe de entidade associativa "Recepção", por sua vez, é a única filha. Podemos ver que o relacionamento muitos-para-muitos no diagrama de apresentação anterior agora está totalmente detalhado. Em vez do relacionamento muitos-para-muitos que vemos no diagrama de apresentação acima, temos dois relacionamentos muitos-para-um. O filho final do primeiro relacionamento tem a multiplicidade "muitos", o que significa literalmente que a classe da entidade "Acolhimento" tem muitos médicos (todos eles no hospital). E no final desse relacionamento está a multiplicidade de "um", o que isso significa? Isso significa que na classe de entidade "Recepção", cada um dos códigos disponíveis de cada médico em particular pode ocorrer indefinidamente muitas vezes. De fato, no agendamento no hospital, o código do mesmo médico ocorre várias vezes, em dias e horários diferentes. E aqui está o mesmo código, mas já na classe de entidade "Médicos", pode ocorrer uma vez e apenas uma vez. De fato, na lista de todos os médicos do hospital (e a classe de entidade "Médicos" nada mais é do que essa lista), o código de cada médico em particular pode estar presente apenas uma vez. Algo semelhante acontece com o relacionamento entre a classe pai "Patient" e a classe filha "Patient". Na lista de todos os pacientes do hospital (na classe de entidade "Pacientes"), o código de cada paciente específico pode ocorrer apenas uma vez. Mas por outro lado, no agendamento de consultas (na classe de entidade "Recepção"), cada código de um determinado paciente pode ocorrer arbitrariamente muitas vezes. É por isso que as multiplicidades nas extremidades do vínculo são dispostas dessa maneira. Como exemplo da implementação de uma associação em um modelo de dados relacional, vamos construir um modelo que descreva o cronograma de reuniões entre o cliente e o contratante com a participação opcional de consultores. Não vamos nos deter no diagrama de apresentação, porque precisamos considerar a construção de diagramas em todos os detalhes, e o diagrama de apresentação não pode fornecer essa oportunidade. Então, vamos construir um diagrama chave que reflita a essência do relacionamento entre o cliente, o contratante e o consultor.
Então, vamos começar uma análise detalhada do diagrama chave acima. Primeiramente, a classe "Graph" é uma classe de entidades associativas, mas, como no exemplo anterior, não é uma classe de entidades nomeadas, pois possui um atributo que não migra para ela junto com as chaves, mas é seu próprio atributo. Este é o atributo "Data - Hora". Em segundo lugar, vemos que os atributos da classe de entidade filha "Gráfico" "Código do cliente", "Código do executor" e "Data - Hora" formam uma chave primária composta dessa classe de entidade. O atributo "Advisor Code" é simplesmente uma chave estrangeira da classe de entidade "Chart". Observe que este atributo permite valores Nulos entre seus valores, pois conforme a condição não é necessária a presença de consultor na reunião. Além disso, em terceiro lugar, notamos que os dois primeiros links (dos três links disponíveis) não são totalmente identificáveis. Ou seja, não identificando totalmente, porque a chave de migração em ambos os casos (chaves primárias "Código do cliente" e "Código do executor") não formam completamente a chave primária da classe de entidade "Gráfico". De fato, o atributo "Data - Hora" permanece, que também faz parte da chave primária composta. Nas extremidades desses dois vínculos de identificação incompleta, as multiplicidades "um" e "muitos" são marcadas. Isso é feito para mostrar (como no exemplo sobre médicos e pacientes) a diferença entre mencionar o código do cliente ou do executor em diferentes classes de entidade. De fato, na classe de entidade "Gráfico", qualquer código de cliente ou contratante pode ocorrer quantas vezes desejar. Portanto, nesta extremidade da conexão, filho, há uma multiplicidade de "muitos". E na classe de entidade "Clientes" ou "Empreiteiros", cada um dos códigos do cliente ou contratante, respectivamente, pode ocorrer uma vez e apenas uma vez, porque cada uma dessas classes de entidade nada mais é do que uma lista completa de todos os clientes e executores. Portanto, nesta extremidade principal da conexão, há uma multiplicidade de "um". E, finalmente, observe que o terceiro relacionamento, ou seja, o relacionamento da classe de entidade "Gráfico" com a classe de entidade "Consultores", não é necessariamente não identificador. De fato, neste caso, estamos falando sobre a transferência do atributo-chave "Código do consultor" da classe de entidade "Consultores" para o atributo não-chave da classe de entidade "Gráfico" de mesmo nome, ou seja, a chave primária de a classe de entidade "Consultores" na classe de entidade "Gráfico" não identifica a chave primária já desta classe. Além disso, como mencionado anteriormente, o atributo "Advisor Code" permite valores Null, então aqui é precisamente o relacionamento de não identificação que é usado. Assim, o atributo "Advisor Code" adquire o status de chave estrangeira e nada mais. Prestemos atenção também às multiplicidades de links colocados nas extremidades pai e filho desse link incompletamente não identificador. Sua extremidade pai tem uma multiplicidade de "não mais que um". Com efeito, se recordarmos a definição de uma relação que não é completamente não identificadora, então entenderemos que o atributo "Código do consultor" da classe de entidade "Gráfico" não pode corresponder a mais de um código do consultor da lista de todos os consultores (que é a classe de entidade "Consultores"). E, em geral, pode acontecer que não corresponda a nenhum código de consultor (lembre-se da caixa de seleção para a admissibilidade de valores nulos Código do consultor: nulo), porque de acordo com a condição, a presença de um consultor em um reunião entre o cliente e o contratante, de um modo geral, não é necessária. 4. Generalizações Outro tipo de relacionamento entre classes de entidade, que iremos considerar, é um relacionamento da forma generalização. É também um tipo de relacionamento não recursivo. Assim, um relacionamento como generalização é implementado como um relacionamento de uma classe de entidade pai com várias classes de entidade filha (em contraste com o relacionamento de Associação anterior, que lidava com várias classes de entidade pai e uma classe de entidade filha). Ao formular regras de representação de dados usando o relacionamento de Generalização, deve-se dizer imediatamente que esse relacionamento de uma classe de entidade pai e várias classes de entidade filha é descrito por relacionamentos de identificação total, ou seja, relacionamentos categóricos. Relembrando a definição de identificar totalmente os relacionamentos, concluímos que ao usar a Generalização, cada atributo da chave primária da classe da entidade pai é transferido para a chave primária das classes da entidade filha, ou seja, os atributos da chave primária de migração da classe pai classe de entidade formam completamente as chaves primárias de todas as classes de entidades filhas, elas as identificam. É curioso notar que a Generalização implementa o chamado hierarquia de categorias ou hierarquia de herança. Nesse caso, a classe da entidade pai define classe de entidade genérica, caracterizada por atributos comuns a entidades de todas as classes filhas ou chamadas entidades categóricas ou seja, uma classe de entidade pai é uma generalização literal de todas as suas classes de entidade filha. Como exemplo da implementação da generalização em um modelo de dados relacional, construiremos o seguinte modelo. Este modelo será baseado no conceito generalizado de “Estudantes” e descreverá os seguintes conceitos categóricos (ou seja, generalizará as seguintes classes de entidades filhas): “Alunos”, “Alunos” e “Alunos de Pós-Graduação”. Então, vamos construir um diagrama chave que reflita a essência do relacionamento entre a classe de entidade pai e as classes de entidade filha, descrita por uma conexão do tipo Generalização.
Então, o que vemos? Primeiramente, cada uma das relações básicas (ou de classes de entidade, que é a mesma) "Alunos", "Estudantes" e "Alunos de Pós-Graduação" corresponde a atributos próprios, como "Turma", "Curso" e "Ano Cursado". " . Cada um desses atributos caracteriza os membros de sua própria classe de entidade. Também vemos que a chave primária da classe de entidade pai "Estudantes" migra para cada classe de entidade filha e forma a chave estrangeira primária lá. Com a ajuda dessas conexões, podemos determinar pelo código de qualquer aluno seu nome, sobrenome e patronímico, informações sobre as quais não encontraremos nas próprias classes de entidades filhas correspondentes. Em segundo lugar, como estamos falando de um relacionamento totalmente identificador (ou categórico) de classes de entidade, prestaremos atenção à multiplicidade de relacionamentos entre a classe de entidade pai e suas classes filhas. A extremidade pai de cada um desses links tem uma multiplicidade de "um" e cada extremidade filha dos links tem uma multiplicidade de "no máximo um". Se recordarmos a definição de um relacionamento totalmente identificador de classes de entidade, fica claro que o código realmente único do aluno, que é a chave primária da classe de entidade "Estudantes", especifica no máximo um atributo com tal código em cada entidade filha classe "Estudante", "Estudantes" e Pós-graduados. Portanto, todos os vínculos têm exatamente essas multiplicidades. Vamos escrever um fragmento dos operadores para criar as relações básicas "Alunos" e "Alunos" com a definição de regras para manter a integridade referencial do tipo cascata. Então nós temos: Criar tabela Alunos ... chave primária (código do aluno) chave estrangeira (Student ID) referencia Alunos (Student ID) na atualização em cascata em excluir cascata Criar mesa Alunos ... chave primária (código do aluno) chave estrangeira (Student ID) referencia Alunos (Student ID) na atualização em cascata na cascata de exclusão; Assim, vemos que na classe da entidade filha (ou relacionamento) "Estudante" é especificada uma chave estrangeira primária que se refere à classe da entidade pai (ou relacionamento) "Estudantes". A regra de cascata para manter a integridade referencial determina que, quando os atributos da classe da entidade pai "Estudantes" forem excluídos ou atualizados, os atributos correspondentes da relação filha "Estudante" serão atualizados ou excluídos automaticamente (em cascata). Da mesma forma, quando os atributos da classe de entidade pai "Estudantes" são excluídos ou atualizados, os atributos correspondentes da relação filha "Estudantes" também serão atualizados ou excluídos automaticamente. Refira-se que é esta regra de integridade referencial que aqui se utiliza, pois neste contexto (lista de alunos) não é racional proibir a eliminação e atualização de informação, e também atribuir um valor indefinido em vez de informação real . Agora vamos dar um exemplo das classes de entidade descritas no diagrama anterior, apresentadas apenas em forma de tabela. Assim, temos as seguintes tabelas de relacionamento: Alunos - relacionamento pai que combina informações sobre os atributos de todos os outros relacionamentos:
Crianças em idade escolar - relação infantil:
Alunos - relação de segundo filho:
alunos de doutorado - relação de terceiro filho:
Então, de fato, vemos que as classes filhas de entidades não contêm informações sobre o sobrenome, nome e patronímico dos alunos, ou seja, alunos, alunos e alunos de pós-graduação. Essas informações só podem ser obtidas por meio de referências à classe da entidade pai. Também vemos que diferentes códigos de alunos na classe de entidade "Estudantes" podem corresponder a diferentes classes de entidades filhas. Assim, sobre o aluno com o código "1" Nikolai Zabotin, nada se sabe na relação parental, exceto seu nome, e todas as outras informações (quem ele é, estudante, aluno ou aluno de pós-graduação) só podem ser encontradas referindo-se à classe de entidade filha correspondente (determinada pelo código). Da mesma forma, você precisa trabalhar com o restante dos alunos, cujos códigos são especificados na classe "Estudantes" da entidade pai. 5. Composição O relacionamento de classes de entidade do tipo composição, como os dois anteriores, não pertence ao tipo de relacionamento recursivo. Composição (ou, como às vezes é chamado, agregação composta) é um relacionamento de uma única classe de entidade pai com várias classes de entidade filha, assim como o relacionamento que discutimos acima. Generalização. Mas se a generalização foi definida como um relacionamento de classes de entidades descritas por relacionamentos de identificação completa, então a composição, por sua vez, é descrita por relacionamentos de identificação incompleta, ou seja, durante a composição, cada atributo da chave primária da classe de entidade pai migra para o atributo chave da classe entidade filho. E, ao mesmo tempo, os atributos de chave de migração formam apenas parcialmente a chave primária da classe de entidade filha. Assim, com agregação composta (com composição), a classe de entidade pai (ou agregado) está associado a várias classes de entidades filhas (ou componentes). Nesse caso, os componentes do agregado (ou seja, os componentes da classe da entidade pai) referem-se ao agregado por meio de uma chave estrangeira que faz parte da chave primária e, portanto, não pode existir fora do agregado. Em geral, a agregação composta é uma forma aprimorada de agregação simples (sobre a qual falaremos um pouco mais adiante). Uma composição (ou agregação composta) é caracterizada pelo fato de que: 1) a referência ao conjunto está envolvida na identificação dos componentes; 2) esses componentes não podem existir fora do agregado. Uma agregação (um relacionamento que consideraremos mais adiante) com relacionamentos necessariamente não identificadores também não permite que componentes existam fora do agregado e, portanto, tem um significado próximo à implementação da agregação composta descrita acima. Vamos construir um diagrama chave que descreva o relacionamento entre uma classe de entidade pai e várias classes de entidade filha, ou seja, descrevendo o relacionamento de classes de entidade do tipo de agregação composta. Seja este um diagrama-chave representando a composição dos edifícios de um determinado campus, incluindo edifícios, suas salas de aula e elevadores. Portanto, este diagrama ficará assim:
Então, vamos dar uma olhada no diagrama que acabamos de criar. O que vemos nele? Primeiro, vemos que o relacionamento usado nessa agregação composta é de fato identificador e não totalmente identificador. Afinal, a chave primária da classe de entidade pai "Edifícios" está envolvida na formação da chave primária das classes de entidade filha "Públicos" e "Elevadores", mas não a define completamente. A chave primária "Case No" da classe da entidade pai migra para as chaves primárias estrangeiras "Case No" de ambas as classes filhas, mas, além dessa chave migrada, ambas as classes da entidade filha também possuem sua própria chave primária, respectivamente "Audience Não" e "Nº do elevador", ou seja, as chaves primárias compostas das classes de entidades filhas são apenas atributos parcialmente formados da chave primária da classe de entidade pai. Agora vamos ver as multiplicidades de links que conectam as classes pai e ambas as classes filhas. Como se trata de vínculos identificadores incompletos, as multiplicidades estão presentes: "um" e "muitos". A multiplicidade "um" está presente na extremidade pai de ambos os relacionamentos e simboliza que na lista de todos os corpora disponíveis (e a classe de entidade "Corpus" é exatamente essa lista), cada número pode ocorrer apenas uma vez (e não mais do que isso) vezes. E, por sua vez, dentre os atributos das classes “Público” e “Elevadores”, cada número de prédio pode ocorrer muitas vezes, pois há mais públicos (ou elevadores) do que prédios, e em cada prédio há vários auditórios e elevadores. Assim, ao listar todas as salas de aula e elevadores, inevitavelmente repetiremos os números dos prédios. E, finalmente, como no caso do tipo de conexão anterior, vamos anotar os fragmentos dos operadores para criar relações básicas (ou, o que é a mesma coisa, classes de entidade) "Audiências" e "Elevadores", e vamos fazer isso com a definição de regras para manter a integridade referencial do tipo cascata. Portanto, esta declaração ficaria assim: Criar audiências de tabela ... chave primária (número do corpus, número da audiência) chave estrangeira (número do caso) referências Padrões (número do caso) na atualização em cascata em excluir cascata Criar Tabela Elevações ... chave primária (número do caso, número do elevador) chave estrangeira (número do caso) referências Padrões (número do caso) na atualização em cascata na cascata de exclusão; Assim, definimos todas as chaves primárias e estrangeiras necessárias das classes de entidades filhas. Tomamos novamente a regra de manter a integridade referencial como cascata, pois já a descrevemos como a mais racional. Agora daremos um exemplo em forma de tabela de todas as classes de entidades que acabamos de considerar. Vamos descrever essas relações básicas que refletimos com a ajuda de um diagrama na forma de tabelas e, para maior clareza, introduziremos ali uma certa quantidade de dados indicativos. Conchas O relacionamento pai se parece com isso:
Públicos-alvo - classe de entidade filha:
Elevadores - a segunda classe de entidade filha da classe pai "Enclosures":
Assim, podemos ver como as informações são organizadas para todos os prédios, suas salas de aula e elevadores neste banco de dados, que pode ser usado por qualquer instituição educacional da vida real. 6. Agregação A agregação é o último tipo de relacionamento entre classes de entidade que será considerado como parte de nosso curso. Também não é recursivo, e um de seus dois tipos é bastante próximo em significado à agregação composta considerada anteriormente. Assim, agregação é o relacionamento de uma classe de entidade pai com várias classes de entidade filha. Neste caso, a relação pode ser descrita por dois tipos de relações: 1) links necessariamente não identificáveis; 2) links não identificáveis opcionais. Lembre-se de que, com relacionamentos necessariamente não identificadores, alguns atributos da chave primária da classe da entidade pai são transferidos para um atributo não chave da classe filha, e valores nulos para todos os atributos da chave de migração são proibidos. E com relacionamentos não necessariamente não identificadores, a migração de chaves primárias ocorre exatamente de acordo com o mesmo princípio, mas valores nulos para alguns atributos da chave de migração são permitidos. Ao agregar, a classe de entidade pai (ou agregado) está associado a várias classes de entidades filhas (ou componentes). Os componentes do agregado (ou seja, a classe da entidade pai) referem-se ao agregado por meio de uma chave estrangeira que não faz parte da chave primária e, portanto, no caso não necessariamente relacionamentos de não identificação, os componentes agregados podem existir fora do agregado. No caso da agregação com relacionamentos necessariamente não identificadores, os componentes do agregado não podem existir fora do agregado e, nesse sentido, a agregação com relacionamentos necessariamente não identificadores se aproxima da agregação composta. Agora que ficou claro o que é um relacionamento do tipo agregação, vamos construir um diagrama chave que descreva a operação desse relacionamento. Deixe nosso diagrama futuro descrever os componentes marcados dos carros (ou seja, o motor e o chassi). Ao mesmo tempo, assumiremos que a desativação do carro implica a desativação do chassi junto com ele, mas não implica a desativação simultânea do motor. Portanto, nosso diagrama de chaves fica assim:
Então, o que vemos neste diagrama chave? Primeiramente, o relacionamento da classe da entidade pai “Carros” com a classe da entidade filha “Motores” não é necessariamente não identificador, pois o atributo “car #” permite valores nulos entre seus valores. Por sua vez, este atributo permite valores nulos pelo motivo de que a desativação do motor, por condição, não depende da desativação de todo o veículo e, portanto, não ocorre necessariamente na desativação de um carro. Também vemos que a chave primária "Motor #" da classe de entidade "Carros" migra para o atributo não-chave "Motor #" da classe de entidade "Motores". E, ao mesmo tempo, esse atributo adquire o status de chave estrangeira. E a chave primária nesta classe de entidade Engines é o atributo Engine Marker, que não se refere a nenhum atributo do relacionamento pai. Em segundo lugar, a relação entre a classe da entidade pai “Motores” e a classe da entidade filha “Chassis” é necessariamente uma relação não identificadora, pois o atributo chave estrangeira “Car #” não permite valores Nulos entre seus valores. Esta, por sua vez, ocorre porque se sabe pela condição que a desativação da viatura implica a desativação simultânea obrigatória do chassis. Aqui, assim como no caso do relacionamento anterior, a chave primária da classe de entidade pai "Motores" é migrada para o atributo não-chave "Número do carro" da classe de entidade filha "Chassis". Ao mesmo tempo, a chave primária desta classe de entidade é o atributo "Chassis Marker", que não se refere a nenhum atributo do relacionamento pai "Motores". Ir em frente. Para melhor assimilação do tema, vamos anotar novamente os fragmentos dos operadores para criar as relações básicas "Motores" e "Chassis" com a definição de regras para manter a integridade referencial. Criar motores de tabela ... chave primária (marcador do motor) chave estrangeira (nº do veículo) referencia Carros (nº do veículo) na atualização em cascata ao excluir definir nulo Criar mesa Chassis ... chave primária (marcador do chassi) chave estrangeira (nº do veículo) referencia Carros (nº do veículo) na atualização em cascata na cascata de exclusão; Vemos que usamos a mesma regra para manter a integridade referencial em todos os lugares - cascata, pois mesmo antes a reconhecemos como a mais racional de todas. No entanto, desta vez usamos (além da regra em cascata) a regra de integridade referencial nula definida. Além disso, nós o usamos sob a seguinte condição: se algum valor da chave primária "Número do carro" da classe da entidade pai "Carros" for excluído, o valor da chave estrangeira "Número do carro" da relação filha "Motores" referindo-se a ele será atribuído um valor nulo . 7. Unificação de atributos Se, durante a migração de chaves primárias de uma determinada classe de entidade pai, atributos de diferentes classes pais que coincidem em significado forem para a mesma classe filha, então esses atributos devem ser "mesclados", ou seja, é necessário realizar o procedimento -chamado unificação de atributos. Por exemplo, no caso em que um funcionário pode trabalhar em uma organização, sendo listado em não mais de um departamento, após unificar o atributo "Código da organização", obtemos o seguinte diagrama de chaves:
Ao migrar a chave primária das classes de entidade pai "Organização" e "Departamentos" para a classe filha "Funcionários", o atributo "ID da organização" fica na classe de entidade "Funcionários". E duas vezes: 1) primeira vez com marcador PFK da classe de entidade "Organização" ao estabelecer um relacionamento de identificação incompleta; 2) e a segunda vez, com o marcador FK com a condição de aceitar valores nulos da classe de entidade "Departamentos" ao estabelecer um relacionamento não necessariamente não identificador. Quando unificado, o atributo "ID da organização" assume o status de atributo de chave primária/estrangeira, absorvendo o status do atributo de chave estrangeira. Vamos construir um novo diagrama chave que demonstre o próprio processo de unificação:
Assim, ocorreu a unificação de atributos. << Voltar: Design de esquema de banco de dados (Diferentes tipos e multiplicidades de conexões. Diagramas. Tipos de diagramas. Relacionamentos e migração de chaves) >> Encaminhar: Sistemas especialistas e modelo de produção de conhecimento (Objetivo dos sistemas especialistas. Estrutura dos sistemas especialistas. Participantes no desenvolvimento de sistemas especialistas. Modos de operação dos sistemas especialistas. Modelo de produto do conhecimento)
A existência de uma regra de entropia para o emaranhamento quântico foi comprovada
09.05.2024 Mini ar condicionado Sony Reon Pocket 5
09.05.2024 Energia do espaço para Starship
08.05.2024
▪ Fontes de alimentação de laboratório de alta tensão 800W TDK-Lambda ▪ Gotas de matéria primária do Universo são criadas ▪ Drivers para comutação de LEDs brancos EL7513 ▪ Espuma metálica - isolante térmico ▪ Pulseiras de silicone medem a qualidade do ar
▪ seção do site História da tecnologia, tecnologia, objetos que nos rodeiam. Seleção de artigos ▪ artigo de Thomas Gray. Aforismos famosos ▪ artigo Bug de campo. Lendas, cultivo, métodos de aplicação ▪ artigo Dispositivos de coordenação. Enciclopédia de rádio eletrônica e engenharia elétrica
Página principal | Biblioteca | Artigos | Mapa do Site | Revisões do site
www.diagrama.com.ua |
Recomendamos artigos interessantes seção 
Veja outros artigos seção 
Últimas notícias de ciência e tecnologia, nova eletrônica:
Todos os idiomas desta página