MODELAGEM DE DADOS PARTE 2

Fundação Centro de Análise, Pesquisa e Inovação Tecnológica Instituto de Ensino Superior - FUCAPI MODELAGEM DE DADOS PARTE 2 Disciplina: Banco de Dados Prof: Márcio Palheta, Esp. Manaus - AM

ROTEIRO Diagrama ER Papéis Restrições e Relacionamentos Restrições de Participação e Dependência de Existência Relacionamentos binários vs não-binários Tipo Entidade Fraca Notações para modelagem Referências 2

Diagrama ER Diagrama entidade relacionamento (ER) é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração É a principal representação do Modelo de Entidades e Relacionamentos É usado para representar o modelo conceitual do negócio Não confundir com modelo relacional, que representam as tabelas, atributos e relações materializadas no banco de dados 3

Diagrama ER Retângulos representam conjuntos de entidades Losângulos representam conjuntos de relacionamentos Linhas ligam atributos a entidades e entidades a relacionamentos Elipses representam atributos 4

Diagrama ER Elipses duplas representam atributos multivalorados Elipses tracejadas denotam atributos derivados atributos Atributos sublinhados são chaves primárias atributos Atributos pontilhados são chaves parciais 5

Diagrama ER num_apto meio num_casa nome primeiro último rua cidade nome Endereço estado cep Id_cliente Cliente idade num_telefone data_nascimento 6

Diagrama ER nome rua Id_cliente cidade Id_emprestimo quantia Cliente Empréstimos FAZ_EMPRÉSTIM O 7

Diagrama ER Sempre faça modelagem de dados, isso ajuda no entendimento do problema e no planejamento de uma solução mais aderente aos seus objetivos O objetivo do modelo conceitual é a definição do problema, não da solução Existem diferentes terminologias para modelagem conceitual 8

Diagrama ER Notação de Peter Chen Cliente 1 N Pedido Notação de Pé de Galinha Crow s Foot Cliente Pedido Notação IDEF1X Cliente Pedido 9

PAPÉIS

Papéis Entidades de um relacionamento não precisam ser distintas Os rótulos gerente e funcionário são chamados de papéis Eles especificam como as entidades empregados interagem através do relacionamento trabalha_em Papéis são indicados através dos rótulos nas linhas que conectam os losângulos aos retângulos Rótulos são opcionais O uso de rótulo é usado para esclarecer a semântica do relacionamento 11

Papéis Um relacionamento recursivo é chamado de uma associação reflexiva empregado SUPERVISAO Relacionamento Recursivo 12

RESTRIÇÕES E RELACIONAMENTOS

Restrições e Relacionamentos Geralmente certas restrições limitam a possibilidade de combinação de entidades que podem participar do conjunto de relacionamentos correspondente (regras do minimundo) Podemos distinguir dois tipos principais de restrições: Razão de cardinalidade Participação 14

Razão de Cardinalidade para Relacionamento Binário Especifica o número máxima de instâncias de relacionamento em que uma entidade pode participar As razões de cardinalidade possíveis para os tipos relacionamento binário são: 1:1 (um pra um) ou 1..1 (mínimo : máximo) 1:N (um pra N) ou 1..* (mínimo : máximo) N:1 (N pra um) ou *..1 (mínimo : máximo) M:N (M pra N) ou *..* (mínimo : máximo) 15

Razão de Cardinalidade para Relacionamento Binário Restrição: um empregado pode gerenciar apenas um departamento, e um departamento pode ter apenas um gerente EMPREGADO GERENCIA DEPARTAMENTO e1 r1 d1 e2 e3 e4 e5 r2 r3 r4 r5 d2 d3 d4 d5 Relacionamento GERENCIA 1:1 16

Razão de Cardinalidade para Relacionamento Binário Restrição: um empregado pode trabalhar em diversos projetos, e um projeto pode ter diversos empregados EMPREGADO TRABALHA_EM PROJETO e1 r1 p1 e2 e3 e4 e5 r2 r3 r4 r5 p2 p3 p4 p5 Relacionamento TRABALHO_EM M:N 17

RESTRIÇÕES DE PARTICIPAÇÃO E DEPENDÊNCIA DE EXISTÊNCIA

Restrição de Participação Determina se a existência de uma entidade depende da existência relacionada a outra entidade Essa restrição determina o número mínimo de instância de relacionamento em que cada entidade pode participar Também é chamada de restrição de cardinalidade mínima Há dois tipos de restrição de participação: Total ou Dependência de Existência Parcial 19

Restrição de Participação Total A empresa adota a política de que todo empregado deve trabalhar para um departamento EMPREGADO TRABALHO_PARA DEPARTAMENTO e2 e3 e4 r1 r2 r3 d1 d2 d3 A participação EMPREGADO em TRABALHA_PARA é PARTICIPAÇÃO TOTAL 20

Restrição de Participação Parcial Nem todo empregado pode gerenciar um departamento, logo a participação do EMPREGADO no tipo relacionamento GERENCIA é PARCIAL EMPREGADO GERENCIA DEPARTAMENTO e2 e3 e4 r1 r2 r3 d1 d2 d3 21

Restrições de Participação e Dependência de Existência Exemplo: Participação Total: Todo empréstimo deve ter um cliente Participação Parcial: nem todo cliente tem um empréstimo Cliente FAZ_EMPRÉSTIMO Empréstimos Linha Simples: participação parcial Linha Dupla: participação total 22

Restrições de Participação e Dependência de Existência Os limites de cardinalidade podem expressar restrições de participação Cliente 0..* FAZ_EMPRÉSTIMO 1..1 Empréstimos participação parcial participação total 23

RELACIONAMENTOS BINÁRIOS VS NÃO-BINÁRIOS

Relacionamentos binários vs não-binários Alguns relacionamentos que parecem ser não-binários são melhor representados usando relacionamentos binários Exemplo: O relacionamento ternário pais que relaciona uma criança a seu pai e a sua mãe é melhor representada por dois relacionamentos binários, pai e mãe 25

Relacionamentos binários vs não-binários A B R C A R 2 B R 1 E R 3 C 26

Relacionamentos binários vs não-binários Pai Criança PAIS Mãe Pai É Criança tem Pais É Mãe 27

TIPO ENTIDADE FRACA

Tipo Entidade Fraca Tipos entidade que não têm seus próprios atributos-chaves (identificação) são chamados de tipo entidade fraca As Entidades Fracas precisam de um Relacionamento Identificador para serem distinguidas As Entidades Fracas possuem uma chave (não-primária) que distingue todas as entidades que dependem de determinada entidade forte. Ela é denominada Discriminador ou Chave Parcial Um Relacionamento Identificador é composto pela chave primária da Entidade Forte e pelo Discriminador da Entidade Fraca 29

Tipo Entidade Fraca parentesco cpf Nome datanasc sexo salário nome sexo datanasc EMPREGADO DEPENDENTE_DE DEPENDENTE O relacionamento Identificadoré composto CPFe pelo discriminador nome da tabela DEPENDENTE 30

Tipo Entidade Fraca 1..1 TRABALHA_PARA 4..N 0..N supervisor EMPREGADO 0..1 1..1 DEPARTAMENTO 0..1 gerencia GERENCIA departamento 0..N gerenciado supervisionado 1..N departamento trabalha controlador SUPERVISÃO TRABALHA_EM CONTROLA 0..N DEPENDENTE_DE projeto 1..N 1..1 PROJETO projeto controlado 1..1 DEPENDENTE 31

NOTAÇÕES PARA MODELAGEM

Notações para Modelagem Elimine qualquer redundância de dados Redundâncias permitidas são aquelas relativas a chaves estrangeiras, que fazem referência à chave primária de outra tabela Por exemplo, não se deve repetir o nome do cliente em seus pedidos, pois ele pode ser facilmente obtido através do relacionamento 33

Notações para Modelagem Utilize um padrão para dar nomes a entidades Normalmente, nomes de entidades são no singular Dê nomes significativos a entidades, atributos e relacionamentos Nomes que não representam seu real objetivo dificultam a compreensão do modelo Deve-se determinar os relacionamentos e, decidir como é a relação de dependência entre cada entidade é sempre importante Os tipos de relacionamento podem ser: 0:1; 0:N; 1:1; 1:N; N:M 34

Notações para Modelagem Relacionamentos não obrigatoriamente precisam ter nomes, mas é uma boa prática de modelagem nomeá-los, pois facilita o entendimento Assim, utilize nomes significativos para os relacionamentos Relacionamentos N:N ou que possuem atributos normalmente geram novas tabelas no modelo lógico O nome do relacionamento pode ser utilizado como nome da tabela e deve ser cuidadosamente escolhido 35

Notações para Modelagem 0..N 0..N Funcionário Lotação Departamento Lotacao matricula cod_depto carga_horaria 36

Notações para Modelagem Muitas vezes costuma-se pular a etapa de modelo conceitual de dados e passa-se diretamente para o modelo lógico Em grande parte pode-se creditar isso a muitas ferramentas CASE, que partem diretamente do modelo lógico Considera-se isso perigoso! A modelagem conceitual foi criada para atender às necessidades do usuário, sem limitações tecnológicas 37

Notações para Modelagem Desta forma, no primeiro modelo, não se deve preocupar com chaves primárias e estrangeiras As chaves são necessárias uma vez que é assim que os SGBDs trabalham, mas isso não faz parte das necessidades do usuário O mesmo pode ser dito com relação ao tipo e tamanho de dados, e ainda mais do mapeamento de relacionamentos 1:1 e n:n O objetivo do projeto lógico é a definição da solução 38

Notações para Modelagem Vale lembrar que nem todo modelo lógico de dados é a cópia fiel do modelo conceitual de dados. Toda entidade do modelo conceitual vira uma tabela no modelo lógico! Dimensione corretamente os tipos de dados em função de seus conteúdos para diminuir o espaço de armazenamento Campos de texto com tamanho variável tendem a consumir menos espaço de armazenamento 39

Notações para Modelagem Defina corretamente a obrigatoriedade para atributos das entidades de forma a retratar o objetivo da entidade Por exemplo, o nome do cliente deve ser obrigatório, pois não faz sentido cadastrar um cliente sem seu nome Muitas vezes, preocupa-se apenas com a obrigatoriedade para os atributos chave, mas esta questão é importante para todos os atributos, tomando-se o devido cuidado de não impor restrições demais que impeçam que novos registros possam ser inseridos 40

Notações para Modelagem Elimine atributos derivados ou calculados: não é recomendado armazenar o resultado de cálculos nas tabelas O correto é que o cálculo seja gerado sob demanda, normalmente em uma consulta Toda tabela deve ter uma chave primária, que pode ser simples ou composta A chave primária é o identificador do registro e deve ser única dentro de uma tabela 41

Notações para Modelagem Ao determinar a chave primária, deve-se escolher, em cada tabela, quais colunas formarão a chave primária. Para uma coluna ser candidata à chave primária, deverá atender aos principais requisitos: Deverá ser a menor possível; O seu valor deverá ser diferente de vazio ou zero (not null); Deverá ser de preferência numérica; O seu valor deverá ser único para toda a tabela 42

Notações para Modelagem Chaves estrangeiras devem corresponder a chaves primárias da relação associada ou ser nulas, quando não for um campo obrigatório Crie chaves cegas (Blind Key) toda vez que não for possível identificar a chave primária, ou quando esta for muito complexa, composta por muitos atributos Esses tipos de atributos geralmente são conhecidos por atributos falsos, ou seja, não fazem parte de forma explícita da regra de negócio, porém foram criados para garantir flexibilidade ou integridade ao modelo de dados desenvolvido 43

Notações para Modelagem Por exemplo, um funcionário pode ter diversos dependentes, que possuem nome e data de nascimento Nenhum destes atributos, nem mesmo a concatenação deles, garante uma chave primária única Uma solução é a criação de um novo atributo determinante, como cod_dependente 44

Notações para Modelagem Relacionamentos são representados por chaves estrangeiras, ou Foreign Key (FK), atributos correspondentes à chave primária de outra relação, estabelecendo a base para a integridade referencial No exemplo o atributo cod_cliente, chave primária da tabela Cliente, foi repetido na tabela Pedido para representar o relacionamento Desta forma, um Pedido possui um cliente que necessariamente deve estar presente na tabela Cliente (através de seu código) 45

Notações para Modelagem Chaves estrangeiras representando relacionamentos Cliente Pedido Pedido num_pedido cod_cliente(fk) 46

REFERÊNCIAS ELMASRI, R., NAVATHE, S. B. Sistemas de Banco de Dados, 4ª Edição. Editora Pearson Addison Wesley. Ano 2005 SILBERSCHATZ, A., KORTH, H. F., SUDARSHAN, S., Sistema de Banco de Dados, 3ª Edição, Makron Books. 1999 http://pt.wikipedia.org/wiki/diagrama_entidade_relacionament o 47