Entidade fraca

Em um banco de dados relacional, uma entidade fraca é uma entidade que não pode ser identificada exclusivamente apenas por seus atributos; Portanto, ele deve usar uma chave estrangeira em conjunto com seus atributos para criar uma chave primária. A chave estrangeira é normalmente uma chave primária de uma entidade à qual está relacionada.

A chave estranha é um atributo do identificando (ou proprietário , pai ou dominante ) < B> Conjunto de entidades . Cada elemento no conjunto de entidades fracas deve ter um relacionamento com exatamente um elemento no conjunto de entidades do proprietário e, portanto, o relacionamento não pode ser um relacionamento de muitos para muitos.

Duas entidades podem ser associadas sem serem classificadas como fracas, mesmo que uma dependa da outra, desde que cada uma tenha seu próprio atributo exclusivo. Por exemplo, uma pessoa pode ser vinculada a um carro sem que um deles seja considerado uma entidade fraca.

Em diagramas de relacionamento de entidade (diagramas de ER), um conjunto de entidades fraco é indicado por um retângulo ousado (ou duplo) (a entidade) conectada por uma seta em negrito (ou duplo) a um ousado (ou duplo -Linado) diamante (o relacionamento). Esse tipo de relacionamento é chamado de relação de identificação e na notação idef1x, é representada por uma entidade oval em vez de uma entidade quadrada para tabelas de base. Uma relação de identificação é aquela em que a chave primária é preenchida à entidade fraca da criança como uma chave primária nessa entidade.

Em geral (embora não necessariamente), uma entidade fraca não possui itens em sua chave primária, exceto sua chave primária herdada e um número de sequência. Existem dois tipos de entidades fracas: entidades associativas e entidades de subtipo. O último representa um tipo crucial de normalização, onde a entidade super-tipo herda seus atributos para entidades de subtipo com base no valor do discriminador.

No IDEF1X, um padrão do governo para capturar requisitos, possíveis relacionamentos de subtipos são:

• relacionamento subtipo completo, quando todas as categorias são conhecidas.
• Relação subtipo incompleta, quando todas as categorias podem não ser conhecidas.

Um exemplo clássico de uma entidade fraca sem um relacionamento subtipe seria o "cabeçalho/detalhe ' Registros em muitas situações do mundo real, como reivindicações, ordens e faturas, onde o cabeçalho captura informações comuns em todos os formulários e os detalhes captura informações específicas para itens individuais.

O exemplo padrão de uma relação de subtipo completa é a entidade Party . Dado o tipo de partido discriminador (que pode ser individual, parceria, corporação C, associação de sub-capítulos, associação, unidade governamental, agência quase-governamental), as duas entidades de subtipo são pessoa, que contém informações específicas de indivíduo, como o primeiro e o sobrenome e data de nascimento e organização, que conteriam atributos como o nome legal e hierarquias organizacionais, como centros de custo.

Quando os relacionamentos do subtipo são renderizados em um banco de dados, o super-tipo se torna o que é chamado de tabela base. Os subtipos são considerados tabelas derivadas, que correspondem a entidades fracas. A integridade referencial é aplicada por meio de atualizações e exclusão em cascata.

Considere um banco de dados que registra os pedidos do cliente, onde um pedido é para um ou mais dos itens que a empresa vende. O banco de dados conteria uma tabela identificando clientes por um número de cliente (chave primária); outro identificando os produtos que podem ser vendidos por um número de produto (chave primária); E continha um par de tabelas que descrevem ordens.

Uma das tabelas poderia ser chamada de ordens e teria um número de pedido (chave primária) para identificar esse pedido exclusivamente e conteria um número de cliente (chave estrangeira) para identificar a quem os produtos estão sendo vendidos, além de outros outros Informações como a data e a hora em que o pedido foi feito, como será pago, onde deve ser enviado e assim por diante.

A outra tabela poderia ser chamada de orderitem ; Seria identificado por uma chave composta que consiste no número do pedido (chave estrangeira) e um número de linha de itens; Com outros atributos-chave não primários, como o número do produto (chave estrangeira) que foi ordenada, a quantidade, o preço, qualquer desconto, quaisquer opções especiais e assim por diante. Pode haver zero, uma ou muitas entradas OrderItem correspondentes a uma entrada de pedido, mas não existe orderItem a entrada pode existir, a menos que a ordem correspondente Existe entrada. (O caso zero orderitem normalmente se aplica apenas transitoriamente, quando o pedido é inserido pela primeira vez e antes do primeiro item ordenado ser gravado.)

O OrderItem Table Stores Entidades fracas Precisamente porque um orderitem não tem significado independente do Ordem. Alguns podem argumentar que um OrderItem tem algum significado por conta própria; Ele registra que em algum momento não identificado pelo registro, alguém não identificado pelo registro ordenou uma certa quantidade de um determinado produto. Esta informação pode ser de algum uso por conta própria, mas é de uso limitado. Por exemplo, assim que você deseja encontrar tendências sazonais ou geográficas nas vendas do item, você precisa de informações do registro de pedidos relacionados.

Uma ordem não existiria sem um produto e uma pessoa para criar a ordem, portanto, pode -se argumentar que uma ordem seria descrita como uma entidade fraca e que os produtos ordenados seriam um atributo multivalue da ordem.

• Entidade associativa