Baixe Banco de Dados: Conceitos, Modelagem e Linguagem SQL e outras Esquemas em PDF para Análise e Design de Sistemas, somente na Docsity!
Unidade II
Unidade II
3 MODELO ENTIDADE-RELACIONAMENTO (MER)
O modelo entidade-relacionamento (MER) foi idealizado por Peter P. Chen em março de 1976 no trabalho intituladoThe entity-relationship model: toward the unified view of data, no qual ele definiu uma possível abordagem para o processo de modelagem dos dados.
O MER possui uma técnica de diagramação e um conjunto de conceitos que devem ser bem entendidos e não devem ser desrespeitados quanto à simbologia. Nessa técnica de diagramação, a simplicidade é um dos preceitos básicos e serve como meio de representação dos próprios conceitos por ela manipulados. Utiliza-se um retângulo para representar as entidades, um losango para representar os relacionamentos e pequenos balões para indicar os atributos que cada entidade possui.
Entidade 1 Entidade 2
Relacionamento
Atr 1
Atr 2
Figura 20 – Abordagem entidade-relacionamento
O desenvolvimento de um diagrama ER envolve diversas escolhas, incluindo as seguintes:
- Uma entidade ou um atributo deve possuir um conceito para que possa ser modelado?
- Uma entidade ou um relacionamento deve possuir um conceito para que possa ser modelado?
- Quais são os conjuntos de relacionamentos e seus conjuntos de entidades participantes?
- Devemos usar relacionamentos binários ou ternários?
- Devemos usar agregação?
Discutiremos agora os aspectos envolvidos ao fazer essas escolhas.
BANCO DE DADOS
Entidadeversus atributo
Quando identificamos os atributos de um conjunto de entidades, algumas informações não ficam claras no início, entre elas: se uma propriedade pode ser modelada como um atributo ou como um conjunto de entidades. Como opção podemos partir do exemplo de entidade Funcionario; o atributo endereço pode ser um dado adequado para representar o endereço da entidade em questão, entretanto outros atributos podem e devem estar descritos nessa entidade.
3.1 Elementos do modelo de dados
Entidade é um objeto ou evento (real ou abstrato) que se torna um ponto de interesse dentro de uma determinada realidade e ao qual podem ser associados dados, relacionamentos etc. O retângulo representa o tipo Entidade. Exemplo: Cliente, Fornecedor, Produto, Aluno etc.
Figura 21 – Objeto Funcionario
Atributos são propriedades (características) que identificam as entidades. Uma entidade é representada por um conjunto de atributos. Os atributos podem ser simples, compostos ou multivalorados. Um atributo no DER é representado por um pequeno círculo ligado ao Tipo Entidade.
Figura 22 – Entidade Funcionario
Atributo simples não possui qualquer característica especial. A maioria dos atributos será simples. São chamados também de atributos atômicos, porque eles não são divisíveis.
Atributo composto tem seu conteúdo formado por vários itens menores. Exemplo: endereço. Seu conteúdo poderá ser dividido em vários outros atributos, como: rua, número, complemento, bairro, CEP e cidade. Esse tipo de atributo é chamado de atributo composto. Um atributo composto pode formar uma hierarquia.
BANCO DE DADOS
Atributo identificador de entidade ou identificador único é um conjunto de um ou mais atributos cujos valores servem para distinguir uma entidade em uma coleção de entidades. O identificador de uma entidade é denominado chave primária. Os atributos da entidade que formam seu identificador são representados graficamente através de círculos pretos ou um traço, conforme mostra a figura a seguir:
Figura 26 – Entidade Funcionario com atributos (codigoFunc e nome)
Atributos de relacionamento são utilizados com a finalidade de estabelecer um vínculo entre os dados de entidades distintas.
3.2 Generalização/especialização
Uma entidade pode ter propriedades particulares e específicas em um subconjunto de ocorrências de uma entidade genérica. Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades através do conceito de generalização/especialização. A partir desse conceito, é possível atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. No DER, o símbolo para representar generalização/especialização é um triângulo isósceles, conforme mostra a figura a seguir. A generalização/especialização, representada nessa figura, expressa que a entidade CLIENTE é dividida em dois subconjuntos, as entidades PESSOA FÍSICA e PESSOA JURÍDICA, cada uma com propriedades próprias.
Figura 27 – Generalização/especialização
Unidade II
Figura 28 – Generalização/especialização entidade Cliente com pessoa física e pessoa jurídica
Saiba mais
O conceito de generalização/especialização é amplamente utilizado na programação orientada a objeto e remete ao recurso POO de herança.
Para conhecer mais sobre esse recurso, pesquise sobre o assunto no livro a seguir:
THORWALD, G. A. G.UML2: uma abordagem prática. 2. ed. São Paulo: Novatec, 2011.
3.3 Relacionamento
Relacionamento é uma estrutura que indica uma associação entre duas ou mais entidades. Trata-se dos elementos de dados que representam associações entre entidades e que chamamos de relacionamentos. Alguns exemplos de relacionamentos típicos são “trabalha-em”, “trabalha-para”, “compra”, “dirige” ou qualquer verbo que conecte entidades. Para cada relacionamento, os seguintes conceitos devem ser especificados: grau (binário, ternário etc.), conectividade (um-para-muitos etc.), participação opcional ou obrigatória; e quaisquer atributos associados ao relacionamento, e não às entidades. A seguir, vejamos algumas orientações para definir os tipos de relacionamentos mais difíceis.
Observação
Todo relacionamento muitos-para-muitos pode ser entendido como uma entidade, no qual essas entidades se associam entre si, pois elas representam um fato.
Unidade II
As conectividades e cardinalidades são estabelecidas por afirmações muito concisas conhecidas como regras de negócio. Essas regras, resultantes da descrição precisa e detalhada do ambiente de dados de uma organização, também estabelecem as entidades, atributos, relacionamentos, conectividades, cardinalidades e restrições do ER. Como as regras de negócio definem os componentes do ER, assegurar que todas estejam identificadas é uma parte importante do trabalho de um projetista de banco de dados.
3.4.1 Força do relacionamento
O conceito de força de relacionamento baseia-se em como é definida a relação entre a chave primária de uma entidade relacionada. Para implementar um relacionamento, a chave primária de uma entidade aparece como chave estrangeira relacionada. Por exemplo, o relacionamento 1:M entre Escritor e Livro é implementado pela utilização de chave primária idEscritor de Livro como uma chave estrangeira de Escritor.
Lembrete
Relacionamento é uma representação das associações existentes entre entidades no mundo real. Muitos relacionamentos não têm existência física ou conceitual, outros dependem da associação de outras entidades.
Figura 31 – Diagrama entidade-relacionamento entre Escritor e Livro
Quando trabalhamos com relacionamentos, a teoria do conjunto pode ser absorvida para o relacionamento binário R entre o conjunto de entidades A e B, e a cardinalidade do mapeamento precisa ser um dos seguintes tipos:
- Um-para-um : a entidade A está associada no máximo a uma entidade B e uma entidade B está associada no máximo à entidade de A.
BANCO DE DADOS
- Um-para-muitos : a entidade A está associada a qualquer número de entidades de B. Uma entidade de B, entretanto, pode estar associada, no máximo, a uma entidade de A.
- Muitos-para-um : a entidade A está associada, no máximo, a uma entidade de B. Uma entidade de B, entretanto, pode estar associada a qualquer número de entidades de A.
- Muitos-para-muitos : a entidade A está associada a qualquer número de entidades de B e uma entidade de B está associada a qualquer número de entidades de A.
Figura 32 – Regras (baseadas nos tipos de relacionamento)
3.5 Regras de integridade
As questões de integridade de um modelo relacional estão ligadas aos conceitos de chave primária e chave estrangeira. Essas regras servem para garantir que as tabelas guardam informações compatíveis e são de extrema importância para a confiabilidade das informações contidas no banco de dados.
Os conceitos de chaves no projeto devem ser uma das questões centrais, pois as chaves de modelagem em um projeto eliminam o maior número de efeitos da redundância. Uma chave representa um conjunto de um ou mais atributos que, unidos, permite identificar unicamente uma entidade a partir de sua chave. Podemos encontrar mais de uma chave em uma entidade, que será chamada de chave candidata.
BANCO DE DADOS
especial (caso contrário, o código tem de recuperar essas informações das tabelas de catálogo sem, presumivelmente, conhecer o esquema das tabelas de catálogo).
Tabela 2 –
Nome Descrição Tipo Tamanho Domínio Formato Restrições
Segue exemplo:
Tabela 3 – Dados Entidade Funcionario
Atributo Descrição Tipo Tamanho Domínio Formato Restrições Código Código que identifica os dados dofuncionário no banco de dados Numérico - - Chave primária Nome Nome completo do funcionário Texto 50 - - - CPF Número do Cadastro Pessoa Físicado funcionário Numérico 11 - 999999999-99 CPF deve ser válido
Sexo Sexo do funcionário(Masc ou Fem) Texto 12 M-MasculinoF-Feminino F - M -
DataNasc Data de nascimento do funcionário Data 10 - DD/MM/AAAA O funcionário deveser maior de idade
Email Endereço dee-mail do funcionário Texto 30 - nome@dominio.com função de validaçãoDeve possuir Telefone Número de contato do funcionário Numérico 20 - (00)0000-0000 - Celular Número de contato celular dofuncionário Numérico 20 - (00)90000-0000 -
Endereço Endereço de correspondência dofuncionário Texto 60 - - -
Adaptada de: Rob e Coronel (2011).
Analisando a tabela 3, teremos:
- Entidade : é o nome da entidade que foi definida no MER. A entidade é uma pessoa, objeto ou lugar que será considerada como objeto pelo qual temos interesse em guardar informações a seu respeito.
- Atributo : os atributos são as características da entidade Funcionario que desejamos guardar.
- Descrição : é opcional e pode ser usada para descrever o que é aquele atributo ou dar informações adicionais que possam ser usadas futuramente pelo analista ou programador do sistema.
Unidade II
- Tipo : pode ser numérico, texto, data e booleano. Podemos chamar também de tipo do valor que o atributo irá receber. A definição desses tipos deve seguir um processo lógico, por exemplo: nome é texto, salário é numérico, data de nascimento é data, e assim por diante.
- Tamanho : define a quantidade de caracteres que serão necessários para armazenar o seu conteúdo. Geralmente, o tamanho é definido apenas para atributos de domínio texto.
- Domínio : determina os valores permitidos em uma coluna.
- Formato : especifica a formatação padrão para os dados armazenados.
- Restrições : informam restrições a serem implementadas em uma coluna de uma tabela.
Podemos também incluir no dicionário de dados a classe:
- Classe : as classes podem ser simples, composto, multivalorado e determinante (obrigatório).
Mais um exemplo de dicionário de dados:
Tabela 4 – Dados Tb_Aluno
Adaptada de: Rob e Coronel (2011).
3.7 Normalização
Ao estudarmos modelagem e o papel de um banco de dados, independentemente da estrutura de hardware esoftware onde ele será implementado, é necessário que os dados estejam normalizados. Vimos que existem entidades que são compostas por um conjunto de atributos e estas se relacionam entre si através de relacionamentos especificados, como chave primária e estrangeira, para que haja uma ligação entre as entidades. Entretanto, percebemos que, no cenário atual, as dúvidas começam a
Unidade II
- Redundância de dados.
- Perda de informações.
- Falhas na sincronização dos mesmos dados existentes.
- Existência de atributos que dependem apenas de parte da chave primária.
- Existência de dependências transitivas entre atributos.
A maior parte do trabalho realizado no processo de projetos de um banco de dados consiste na sua normalização até um determinado nível (forma normal).
A teoria da normalização é baseada no conceito de forma normal. Existem regras às quais a estrutura da informação deve obedecer para que se possa afirmar qual o nível de normalização da estrutura. A essas regras dá-se, habitualmente, o nome de “formas normais”:
- Primeira forma normal (1FN).
- Segunda forma normal (2FN).
- Terceira forma normal (3FN).
- Forma normal de Boyce-Codd (FNBC).
- Quarta forma normal (4FN).
- Quinta forma normal (5FN).
O objetivo final da normalização é permitir criar um conjunto de tabelas em um banco de dados livre de informações redundantes e que possa ser modificado de forma correta e consistente.
Objetivos da normalização:
- Minimizar ou eliminar a redundância de informações.
- Melhorar a performance do sistema, ao eliminar informações redundantes.
- Permitir a integridade referencial entre entidades.
O processo de normalização permite obter um esquema de banco de dados relacional capaz de suportar, de forma adequada, os dados relevantes de um determinado universo, evitando a redundância de informações e a existência de valores NULL propagada ao longo das tabelas e não permitindo, assim, decomposições ruins ou decomposições com perda de informações.
BANCO DE DADOS
A existência de redundância de dados em uma determinada implementação acarreta problemas muitos sérios, dos quais destacamos:
- Armazenamento : a existência de redundância implica a ocupação de espaço físico adicional.
- Manutenção : o processamento dos dados (inserção, alteração, remoção) pode implicar o acesso a múltiplas tabelas devido à redundância existente. Tal situação é difícil de gerenciar, pois dificulta manter a consistência dos dados.
- Desempenho : quanto maior a redundância, maior será o conjunto de tabelas a serem processadas, o que implicará maior número de acessos a disco e correspondente aumento nos tempos de resposta.
A normalização pode ser vista como um processo através do qual as relações não satisfatórias são decompostas em um conjunto de outras relações por meio da operação de projeção. Essa decomposição terá de ser realizada de tal modo que não haja perda de informação, garantindo que o processo contrário continue a ser possível.
Existem seis formas normais e, em geral, se considera que um esquema de banco de dados que se encontre na terceira forma normal está em um bom nível e é considerado suficiente para a maioria das aplicações.
A terceira forma normal (3FN), habitualmente, é o objetivo da aplicação da normalização. As duas primeiras formas normais (1FN e 2FN) correspondem a passos intermediários para obter a 3FN.
A primeira, a segunda e a terceira formas normais e a forma normal de Boyce-Codd baseiam-se no conceito de dependência funcional entre atributos de uma relação.
A quarta forma normal baseia-se em dependência multivalorada e a quinta forma normal baseia-se em dependência de junção.
Lembrete
Para realizar a normalização de dados, é primordial que seja definido para a tabela o objeto da normalização, um campo de chave primária para sua estrutura de dados, o qual permite identificar os demais campos da estrutura.
3.7.1 Dependências funcionais
O conceito de dependência funcional é a base das primeiras três formas normais e da forma normal de Boyce-Codd, e está ligado à possibilidade de existir, em uma relação, um subconjunto de atributos com uma relação de dependência de outro subconjunto de atributos nessa mesma relação.
BANCO DE DADOS
3.7.2 Dependências triviais e não triviais
Um bom ponto de partida para a remoção do conjunto de dependências funcionais consiste na eliminação das denominadas dependências triviais.
Uma dependência funcional existe somente se a parte direita da sua expressão for um subconjunto da sua parte esquerda. Exemplo:
{Aluno, Curso, Disciplina} -> Aluno
Para o processo de normalização, interessa particularmente o estudo das dependências funcionais não triviais.
3.7.3 Regras de inferência e axiomas de Armstrong
Segundo Elmasri e Navathe (2011), em um esquema de relação R, é possível definir o conjunto F das dependências funcionais imediatas ou óbvias. No entanto, existem outras dependências funcionais implícitas em F.
Chama-se fecho de F o conjunto de todas as dependências funcionais inferidas de F (denominada F+).
Para determinar F+, usam-se os axiomas de Armstrong e as regras de inferência que eles dão origem.
Quadro 2 – Axiomas de Armstrong
Axiomas de Armstrong Reflexividade Se B é subconjunto de A, então A -> B Aumento2 Se A -> B, então AC -> BC Transitividade Se A -> B e B -> C, então A -> C
Adaptado de: Ramakrishnan e Gehrke (2011).
Quadro 3 – Regras de inferência
Regras de inferência (derivada dos axiomas) Decomposição Se A -> BC, então A -> B e A -> C União Se A -> B e A -> C, então A -> BC Pseudotransitividade Se A -> B e B -> K, então AK -> C Composição Se A -> B e C -> D, então AB -> CD
Adaptado de: Ramakrishnan e Gehrke (2011).
3.8 Formas normais
Normalização é uma técnica idealizada para aumentar a confiabilidade na extração e atualização de dados num banco de dados. Idealizado em 1972 por Edgar F. Codd, é um processo onde é criado uma
Unidade II
relação de séries de testes para certificar-se de que os dados manipulados de certa maneira satisfaçam uma certa forma normal. Para entendermos melhor a aplicação das formas normais, vamos considerar os seguintes exemplos:
Uma fatura é emitida a um cliente com todos os produtos adquiridos, incluindo a quantidade e o valor total dos produtos adquiridos em um determinado estabelecimento.
Fatura = n. Fatura, CodCliente, NomeCliente, EnderecoCliente, EmailCli, Produtos, TotalFatura, DataCompra, FormaPagamento.
Diante das informações do objeto Fatura, vamos abordar quatro diretrizes informais que podem ser usadas como medidas para determinar a qualidade de projeto do esquema da relação:
- Garantir que a semântica dos atributos seja clara no esquema.
- Reduzir a informação redundante nas tuplas.
- Reduzir os valores NULL nas tuplas.
- Reprovar a possibilidade de gerar tuplas falsas.
Sempre que agrupamos atributos para formar um esquema de relação, consideramos que aqueles atributos pertencentes a uma relação têm certo significado no mundo real e uma interpretação apropriada associada a eles. A semântica de uma relação refere-se a seu significado resultante da interpretação dos valores de atributo em uma tupla. Se o projeto conceitual for feito cuidadosamente e o procedimento de mapeamento for seguido de maneira sistemática, o projeto do esquema relacional deverá ter um significado claro.
Em geral, quanto mais fácil for explicar a semântica da relação, melhor será o projeto do esquema de relação. Para ilustrar isso, considere o quadro a seguir, que mostra uma versão simplificada do esquema de banco de dados relacional EMPRESA e apresenta um exemplo de estados de relação preenchidos desse esquema. O significado do esquema de relação FUNCIONARIO é muito simples: cada tupla representa um funcionário, com valores para o nome do funcionário (Fnome), número do Cadastro de Pessoa Física (FCPF), data de nascimento (FDataNasc), endereço (FEndereco) e o número do departamento para o qual o funcionário trabalha (CodDepto). O atributo CodDepto é uma chave estrangeira que representa um relacionamento implícito entre FUNCIONARIO e DEPARTAMENTO. A semântica dos esquemas DEPARTAMENTO e PROJETO é muito simples: cada tupla DEPARTAMENTO representa uma entidade de departamento e cada tupla PROJETO representa uma entidade de projeto. O atributo CPFGerente de DEPARTAMENTO relaciona um departamento ao funcionário que é seu gerente, enquanto PNumero de PROJETO relaciona um projeto a seu departamento de controle; ambos são atributos de chave estrangeira. A facilidade com que o significado dos atributos de uma relação pode ser explicado é uma medida informal de quão bem a relação está projetada.
Unidade II
DEPARTAMENTO
DNome CodDepto CPFGerente Administrativo 1 33344455578 Contabilidade 2 34565434512 Financeiro 5 89876543211
LOCALIZACAO_DEP
DNumero Local 1 São Paulo 2 Barueri 3 Santos 4 Brasília 5 Itu
TRABALHA_EM
FCPF PNUMERO HORAS 12345678910 1 32. 78910121314 2 7. 88844487698 3 40. 33344555587 1 40.
PROJETO
PNome PNumero PLocal CodDepto ProdutoX 1 Santo André 5 ProdutoY 2 Itu 5 ProdutoZ 3 São Paulo 5 Informatização 10 Mauá 4 Reorganização 20 São Paulo 1
Figura 33 – Exemplo de banco de dados com esquema relacional
(a) FUNC_DEP
FNome FCPF FDataNasc FEndereco DNome CPFGerente
BANCO DE DADOS
(b) FUNC_PROJ
FCPF PNumero Horas FNome PNome PLocal DF DF DF
Figura 34 – Dois esquemas de relação de anomalias de atualização (a) FUNC_DEP e (b) FUNC_PROJ
O armazenamento de junções naturais de relações da base leva a um problema adicional conhecido como anomalias de atualização. Elas podem ser classificadas em anomalias de inserção, anomalias de exclusão e anomalias de modificação.
Anomalias de inserção podem ser diferenciadas em dois tipos, ilustrados pelos seguintes exemplos baseados na relação FUNC_DEP:
Para inserir uma nova tupla de funcionário em FUNC_DEP, temos de incluir ou os valores de atributo do departamento para o qual o funcionário trabalha ou NULL (se o funcionário ainda não trabalha para nenhum departamento).
Por exemplo, para inserir uma nova tupla para um funcionário que trabalha no departamento 5, temos de inserir todos os valores de atributo do departamento 5 corretamente, de modo que eles sejam coerentes com os valores correspondentes para o departamento 5 em outras tuplas de FUNC_DEP. No projeto da figura 34 não temos de nos preocupar com esse problema de coerência, pois entramos apenas com o número do departamento na tupla do funcionário. Todos os outros valores de atributo do departamento 5 são registrados apenas uma vez no banco de dados, como uma única tupla na relação DEPARTAMENTO.
É difícil inserir um novo departamento que ainda não tenha funcionários na relação FUNC_DEP. A única maneira de fazer isso é colocar valores NULL nos atributos para funcionário. Isso viola a integridade de entidade para FUNC_DEP, porque CPF é sua chave primária. Além do mais, quando o primeiro funcionário é atribuído a esse departamento, não precisamos mais dessa tupla com valores NULL. Esse problema não ocorre no projeto da figura 33, visto que um departamento é inserido na relação DEPARTAMENTO independentemente de haver ou não funcionários trabalhando para ele, e sempre que um funcionário é atribuído a esse departamento, uma tupla correspondente é inserida em FUNCIONARIO.
Agora, vamos apresentar as três primeiras formas normais: 1FN, 2FN e 3FN. Elas foram propostas por Codd como uma sequência para conseguir o estado desejável de relações 3FN ao prosseguir pelos estados intermediários de 1FN e 2FN, se necessário. Conforme veremos, 2FN e 3FN atacam diferentes problemas. Contudo, por motivos históricos, é comum segui-los nessa sequência. Logo, por definição, uma relação 3FN já satisfaz a 2FN.
