Dois relacionados entidades

Uma entidade com um attribute

Uma relação com um atributo

Uma entidade pode ser definida como uma coisa capaz de uma existência independente que pode ser identificada de forma única. Uma entidade é uma abstracção das complexidades de um domínio. Quando falamos de uma entidade, normalmente falamos de algum aspecto do mundo real que pode ser distinguido de outros aspectos do mundo real.

Uma entidade é uma coisa que existe física ou logicamente. Uma entidade pode ser um objecto físico como uma casa ou um carro (existem fisicamente), um evento como a venda de uma casa ou um serviço de automóveis, ou um conceito como uma transacção ou encomenda do cliente (existem logicamente como um conceito). Embora o termo entidade seja o mais frequentemente utilizado, seguindo Chen devemos realmente distinguir entre uma entidade e um tipo de entidade. Uma entidade-tipo é uma categoria. Uma entidade, estritamente falando, é uma instância de um determinado tipo de entidade. Há normalmente muitas instâncias de um tipo de entidade. Como o termo tipo de entidade é algo pesado, a maioria das pessoas tende a usar o termo entidade como sinónimo para este termo

Entidades podem ser pensadas como substantivos. Exemplos: um computador, um empregado, uma canção, um teorema matemático, etc.

Uma relação capta a forma como as entidades se relacionam umas com as outras. As relações podem ser pensadas como verbos, ligando dois ou mais substantivos. Exemplos: uma relação própria entre uma empresa e um computador, uma relação de supervisão entre um empregado e um departamento, uma relação de execução entre um artista e uma canção, uma relação de prova entre um matemático e uma conjectura, etc.

O aspecto linguístico do modelo descrito acima é utilizado na linguagem de consulta da base de dados declarativa ERROL, que imita as construções da linguagem natural. A semântica e a implementação do ERROL baseiam-se na álgebra relacional (RRA) remodelada, uma álgebra relacional que se adapta ao modelo entidade-relação e capta o seu aspecto linguístico.

Entidades e relações podem ambos ter atributos. Exemplos: uma entidade empregada pode ter um atributo Número de Segurança Social (SSN), enquanto uma relação comprovada pode ter um atributo data.

Todas as entidades excepto as entidades fracas devem ter um conjunto mínimo de atributos de identificação única que podem ser utilizados como uma chave única/primária.

Diagramas de relações entre entidades não mostram entidades únicas ou instâncias únicas de relações. Pelo contrário, mostram conjuntos de entidades (todas as entidades do mesmo tipo de entidade) e conjuntos de relações (todas as relações do mesmo tipo de relação). Exemplos: uma determinada canção é uma entidade; a colecção de todas as canções numa base de dados é um conjunto de entidades; a relação comida entre uma criança e o seu almoço é uma relação única; o conjunto de todas essas relações criança-almoço numa base de dados é um conjunto de relações.Por outras palavras, um conjunto de relações corresponde a uma relação em matemática, enquanto que uma relação corresponde a um membro da relação.

Determinadas restrições de cardinalidade em conjuntos de relações também podem ser indicadas.

Mapeamento da linguagem naturalEditar

Chen propôs as seguintes “regras de polegar” para mapear descrições da linguagem natural em diagramas de ER: “Diagramas em inglês, chinês e ER” de Peter Chen.

Tipo de relação

Tipo de entidade

Verbo transitivo

Estrutura gramatical inglesa -estrutura TER
Comum substantivo Tipo de entidade
Tipo de entidade
Tipo de relação
Verbo intrínseco Tipo de atributo
Adjectivo Tributo para entidade
Adverb Attributo para relação

Vista física mostra como os dados são realmente armazenados.

Relações, papéis e cardinalidadesEditar

No papel original de Chen ele dá um exemplo de uma relação e dos seus papéis. Ele descreve uma relação “casamento” e os seus dois papéis “marido” e “esposa”.

Uma pessoa desempenha o papel de marido num casamento (relação) e outra pessoa desempenha o papel de esposa no (mesmo) casamento. Estas palavras são substantivos. Isso não é surpresa; nomear coisas requer um substantivo.

A terminologia dehen também foi aplicada a ideias anteriores. As linhas, setas e pés de galinha de alguns diagramas devem-se mais aos diagramas Bachman anteriores do que aos diagramas de relação de Chen.

Outra extensão comum ao modelo de Chen é “nomear” relações e papéis como verbos ou frases.

Nomeação de papéisEditar

Tornou-se também prevalecente nomear papéis com frases tais como o dono de e é propriedade de Chen. Neste caso, os substantivos correctos são o proprietário e a posse. Assim, a pessoa desempenha o papel de proprietário e o carro desempenha o papel de posse e não de pessoa, é o proprietário de, etc.

O uso de substantivos tem benefício directo quando se geram implementações físicas a partir de modelos semânticos. Quando uma pessoa tem duas relações com o carro, então é possível gerar nomes tais como owner_person e driver_person, que são imediatamente significativos.

CardinalitiesEdit

Modificações à especificação original podem ser benéficas. Chen descreveu cardinalities look-across. Como um aparte, a notação Barker-Ellis, utilizada no Oracle Designer, usa o mesmo lado para a cardinalidade mínima (análoga à opcionalidade) e o papel, mas procura a cardinalidade máxima (o pé de corvo).

In Merise, Elmasri & Navathe e outros há uma preferência pelo mesmo lado para os papéis e tanto para as cardinalidades mínimas como máximas. Investigadores recentes (Feinerer, Dullea et al.) demonstraram que isto é mais coerente quando aplicado a relações n-árias de ordem superior a 2.

Em Dullea et al. lê-se “Uma notação de ‘olhar para além’, tal como utilizada na UML, não representa efectivamente a semântica das restrições de participação impostas às relações em que o grau é superior ao binário”

Em Feinerer diz-se “surgem problemas se operarmos sob a semântica de olhar para além”, tal como utilizada para as associações UML. Hartmann investiga esta situação e mostra como e porque falham as diferentes transformações”. (Embora a “redução” mencionada seja espúria, pois os dois diagramas 3.4 e 3.5 são na realidade os mesmos) e também “como veremos nas páginas seguintes, a interpretação look-across introduz várias dificuldades que impedem a extensão de mecanismos simples de associações binárias para associações n-árias.”

Vários métodos de representar o mesmo para muitas relações. Em cada caso, o diagrama mostra a relação entre uma pessoa e um local de nascimento: cada pessoa deve ter nascido em um, e apenas um, local, mas cada local pode ter tido zero ou mais pessoas nascidas nele.

Duas entidades relacionadas mostradas utilizando a notação Crow’s Foot. Neste exemplo, é mostrada uma relação opcional entre Artista e Música; os símbolos mais próximos da entidade canção representam “zero, um, ou muitos”, enquanto uma canção tem “um e só um” Artista. A primeira é portanto lida como, um Artista (pode) actuar(s) “zero, uma, ou muitas” canção(s).

A notação de Chen para modelagem de entidade-relação utiliza rectângulos para representar conjuntos de entidades, e diamantes para representar relações apropriadas para objectos de primeira classe: eles podem ter atributos e relações próprias. Se um conjunto de entidades participa num conjunto de relações, são ligados com uma linha.

Atributos são desenhados como ovais e são ligados com uma linha a exactamente uma entidade ou conjunto de relações.

As restrições de cardinalidade são expressas da seguinte forma:

  • uma linha dupla indica uma restrição de participação, totalidade ou sobrejectividade: todas as entidades do conjunto de entidades devem participar em pelo menos uma relação no conjunto de relações;
  • uma seta de conjunto de entidades para conjunto de relações indica uma restrição de chave, i.e. injectividade: cada entidade do conjunto de entidades pode participar no máximo numa relação no conjunto de relações;
  • uma linha grossa indica ambas, ou seja, bijectividade: cada entidade do conjunto de entidades está envolvida exactamente numa relação.
  • um nome sublinhado de um atributo indica que é uma chave: duas entidades ou relações diferentes com este atributo têm sempre valores diferentes para este atributo.

Atributos são frequentemente omitidos, uma vez que podem desorganizar um diagrama; outras técnicas de diagrama listam frequentemente atributos de entidades dentro dos rectângulos desenhados para conjuntos de entidades.

Técnicas de convenções de diagramação relacionadas com diagramas:

  • notação de Bachman
  • notação de Barker
  • EXPRESS
  • IDEF1X
  • notação de pé de corda (também notação de Martin)
  • li> (min, max)-notação de Jean-Raymond Abrial em 1974

  • diagramas de classesUML
  • li>Merise

  • Modelagem de corda de abjecto

Notação do pé de galinhaEditar

notação do pé de galinha, cujo início remonta a um artigo de Gordon Everest (1976), é utilizado na notação de Barker, Structured Systems Analysis and Design Method (SSADM) e na engenharia das tecnologias de informação. Os diagramas de pé de corvo representam entidades como caixas, e as relações como linhas entre as caixas. As diferentes formas nas extremidades destas linhas representam a cardinalidade relativa da relação.

A notação do pé de galinha foi utilizada na prática de consultoria CACI. Muitos dos consultores da CACI (incluindo Richard Barker) mudaram-se subsequentemente para Oracle UK, onde desenvolveram as primeiras versões das ferramentas CASE da Oracle, introduzindo a notação a um público mais vasto.

Com esta notação, as relações não podem ter atributos. Quando necessário, as relações são promovidas a entidades por direito próprio: por exemplo, se for necessário capturar onde e quando um artista executou uma canção, é introduzida uma nova entidade “performance” (com atributos que reflectem o tempo e o lugar), e a relação de um artista com uma canção torna-se uma relação indirecta através da performance (artista executa performance, performance-canção-canção).

Três símbolos são utilizados para representar a cardinalidade:

  • o anel representa “zero”
  • o traço representa “um”
  • o pé de galinha representa “muitos” ou “infinito”

Estes símbolos são utilizados aos pares para representar os quatro tipos de cardinalidade que uma entidade pode ter numa relação. O componente interior da notação representa o mínimo, e o componente exterior representa o máximo.

  • anel e travessão → mínimo zero, máximo um (opcional)
  • travessão e travessão → mínimo um, máximo um (obrigatório)
  • anel e pé-de-cabra → mínimo zero, máximo muitos (opcional)
  • traço e pé de galinha → mínimo um, máximo muitos (obrigatório)

Problemas de usabilidade dos modelosEditar

Esta secção necessita de expansão com: causas de armadilhas de ventoinhas. Pode ajudar, acrescentando-lhe. (Fevereiro de 2018)

>br>>p>Na utilização de uma base de dados modelada, os utilizadores podem encontrar dois problemas bem conhecidos onde os resultados devolvidos significam algo diferente dos resultados assumidos pelo autor da consulta.

O primeiro é a ‘armadilha de ventoinha’. Ocorre com uma tabela (mestre) que se liga a múltiplas tabelas numa relação de um para muitos. A questão deriva o seu nome da forma como o modelo se apresenta quando é desenhado num diagrama entidade-relação: as tabelas ligadas ‘fan out’ a partir da tabela principal. Este tipo de modelo é semelhante a um esquema em estrela, um tipo de modelo utilizado em armazéns de dados. Ao tentar calcular somas sobre agregados utilizando SQL padrão sobre a tabela principal, podem ocorrer resultados inesperados (e incorrectos). A solução é ou ajustar o modelo ou o SQL. Esta questão ocorre principalmente em bases de dados para sistemas de apoio à decisão, e o software que consulta tais sistemas inclui por vezes métodos específicos para lidar com esta questão.

A segunda questão é uma ‘armadilha de abismos’. Uma ‘armadilha de abismo’ ocorre quando um modelo sugere a existência de uma relação entre tipos de entidades, mas o caminho não existe entre certas ocorrências de entidades. Por exemplo, um Edifício tem Salas um ou mais, que contêm zero ou mais Computadores. Seria de esperar que se pudesse consultar o modelo para ver todos os Computadores do Edifício. No entanto, os Computadores não atribuídos actualmente a uma Sala (porque estão em reparação ou noutro sítio qualquer) não são mostrados na lista. Outra relação entre Edifício e Computadores é necessária para capturar todos os computadores do edifício. Esta última questão de modelação é o resultado de uma falha na captura de todas as relações existentes no mundo real no modelo. Ver Entity-Relationship Modelling 2 para detalhes.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *