A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Banco de Dados Parte do conteúdo exposto nestas transparências foi retirado dos livros: “Projeto de Banco de Dados”, de Carlos A. Heuser ; “Projeto de.

Apresentações semelhantes


Apresentação em tema: "Banco de Dados Parte do conteúdo exposto nestas transparências foi retirado dos livros: “Projeto de Banco de Dados”, de Carlos A. Heuser ; “Projeto de."— Transcrição da apresentação:

1 Banco de Dados Parte do conteúdo exposto nestas transparências foi retirado dos livros: “Projeto de Banco de Dados”, de Carlos A. Heuser ; “Projeto de Banco de Dados - Uma visão prática”, de Felipe Machado e Maurício Abreu

2 Parte 1 Conceitos Básicos

3 Dado x Informação DADO: algo conhecido, informado, mas sem tratamento sistêmico, ou seja, o DADO precisa de um processamento básico para se transformar em INFORMAÇÃO; INFORMAÇÃO é o DADO processado ! Ex: Jogo de Baralho. Cartas/Jogada Algoritmo para fazer a soma de dois nºs X e Y. Os números são os dados e o resultado é a informação que se deseja saber.

4 Dado x Informação Ex: Imagine que o sistema armazene os seguintes itens a respeito dos funcionários de uma empresa. Número Nome Data Contratação Endereço Bairro Cidade O que é DADO e o que é INFORMAÇÃO? Os itens acima referem-se aos dados do funcionário e a partir destes dados é possível extrair informações. Ex: - O tempo que o funcionário trabalha na empresa; - O endereço do funcionário (endereço+bairro+ cidade)

5 Compartilhamento de Dados
Quando a implantação da Informática nas organizações ocorre de forma gradual, é provável que ocorram alguns problemas. Suponha que uma indústria execute três funções básicas: Vendas: concentra as atividades relativas ao contado com os clientes, como fornecimento de cotações de preços, vendas e a disponibilidade de produtos Produção: concentra as atividades relativas à produção propriamente dita, como planejamento da produção, ou seja, dos produtos e controle do que foi produzido Compras: concentra as atividades relativas à aquisição de insumos necessários à produção, como cotações de preços junto a fornecedores, etc.

6 Compartilhamento de Dados
SISTEMA PRODUÇÃO SISTEMA VENDAS SISTEMA DE COMPRAS Arquivos Produção Arquivos Vendas Arquivos Compras O que você vai PRODUZIR? PRODUTO É preciso saber quais os componentes dos produtos e como são produzidos. O que você vai VENDER? PRODUTO É preciso saber o preço do produto, seu prazo de validade, estoque... O que você vai COMPRAR? MATÉRIA-PRIMA do PRODUTO É preciso saber quais componentes serão adquiridos para fabricar o produto

7 Compartilhamento de Dados
Se cada uma das funções for informatizada de forma separada, pode ocorrer que, para cada uma delas, seja criado um arquivo separado para PRODUTOS. SISTEMA PRODUÇÃO SISTEMA VENDAS SISTEMA DE COMPRAS Arquivos Produção Arquivos Vendas Arquivos Compras Produto Produto Produto Dados de diferentes aplicações não estão integrados; Dados estão projetados para atender uma aplicação específica.

8 Problemas da Falta de Integração de Dados
Redundância de Dados - o mesmo objeto da realidade é armazenado mais de uma vez no banco de dados. Ex: Produtos Redundância Controlada e Não Controlada de Dados Redundância Controlada - acontece quando o software tem conhecimento da múltipla representação e garante a sincronia entre as diversas representações. Ou seja, atualiza automaticamente os dados quando necessário. Ex: Sistemas distribuídos - um mesmo dado é armazenado em vários computadores, permitindo acesso rápido a partir de qualquer um deles.

9 Problemas da Falta de Integração de Dados
Redundância Não Controlada - acontece quando a responsabilidade pela manutenção da sincronia entre as diversas representações de um dado está com o usuário. Redundância Não Controlada leva a : Redigitação de Dados - o mesmo dado é digitado várias vezes no sistema. Este trabalho repetitivo pode levar a erros; Inconsistência dos Dados - os dados podem não representar corretamente a realidade. Imagine que o usuário alterou o preço de um produto no sistema de compra mas não alterou no sistema de vendas. Dificuldade de extração de informações - os dados projetados para atender uma aplicação específica po- dem gerar dificuldade para o cruzamento dos dados

10 COMPARTILHAMENTO DE DADOS
Solução A solução para evitar a redundância NÃO CONTROLADA de informações. COMPARTILHAMENTO DE DADOS SISTEMA PRODUÇÃO SISTEMA VENDAS SISTEMA DE COMPRAS BANCO DE DADOS Produtos Assim, cada dado é armazenado uma ÚNICA VEZ, sendo acessada pelos vários sistemas que dele necessitam.

11 Compartilhamento de Dados
SISTEMA PRODUÇÃO SISTEMA VENDAS SISTEMA DE COMPRAS Arquivos Produção Arquivos Vendas Arquivos Compras Produto Produto Produto SISTEMA PRODUÇÃO SISTEMA VENDAS SISTEMA DE COMPRAS BANCO DE DADOS Produto

12 BANCO DE DADOS Banco de Dados
É o nome dado ao conjunto de arquivos integrados que atendem a um conjunto de sistemas Conjunto de dados integrados que tem por objetivo atender a uma comunidade de usuários BANCO DE DADOS “Uma coleção de dados operacionais inter-relacionados. Estes dados são armazenados de forma independente dos programas que os utilizam, servindo assim a múltiplas aplicações de uma organização.” (Kort, Henry F.)

13 Banco de Dados O que muda com o surgimento dos Bancos de Dados, ou seja, com o Compartilhamento dos Dados? Acesso por múltiplos programas - pode haver mais de uma equipe de desenvolvimento envolvida no desenvolvimento de uma aplicação Os programas devem garantir a Restrição de Integridade, ou seja, garantir a veracidade e a correção dos dados Ex: Um funcionário não pode estar alocado em dois departamentos. O BD pode ser acessado concorrentemente por múlti- plos usuários - os programas devem implementar o controle de acesso concorrente

14 Banco de Dados Restrições de Acesso - nem todo usuário pode acessar qualquer informação. O programa deve implementar o controle de acesso, ou seja, quem tem permissão para acessar o quê Dados são de importância vital e não podem ser perdi- dos - mecanismos simples como cópias de “backup” não são suficientes. Caso haja uma falha, o banco de dados deve ser recuperado rapidamente. Os programas devem implementar mecanismos de tolerância a falhas Estruturas de dados mais complexas - os arquivos devem ser projetados para atender a diferentes necessidades dos sistemas, portanto, há que se tomar bastante cuidado na fase de definição dos DADOS.

15 Sistema de Gerência de Banco de Dados
SGBD  Software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados Software que serve para armazenar e acessar dados em um banco de dados Aplicação SGBD Banco de Dados

16 Sistema de Gerência de Banco de Dados: Vantagens
Independência de dados - SGBD oferece isolamento das aplicações em relação aos dados, ou seja, altera- ções no modelo de dados (estrutura) afeta pouco as aplicações Abstração de dados - aplicações não se preocupam com detalhes físicos de implementação (localização no meio de armazenamento, existência de índices, caminhos de acesso..) Controle de segurança - que usuário pode fazer o que sobre qual dado Tolerância a falhas - recuperação em caso de falha imperceptível ao usuário Controle a acesso concorrente - muitos usuários acessando o banco ao mesmo tempo

17 Quatro Gerações de Gerenciamento de Dados
SGBD’s OO (Versant, Objectivity) SGBD’s RELACIONAIS (DB2,SQL Server, Oracle) SGBD’s Hierárquicos (IMS) e em Rede (CODASYL) Sistemas de Gerenciamento de Arquivos(ISAM, VSAM) 1960 1970 1980 1990 2000

18 Projeto de Banco de Dados - Aplicação
Mas e daí, onde vou aplicar isto? Quando estudamos as metodologias de desenvolvimento de sistemas, estudamos análise de requisitos e definimos o que é necessário ser executado, quais as rotinas devem ser desenvolvidas para atender as necessidades do cliente, isto é, quais as informações que o cliente necessita para ter sucesso em seu negócio. Porém, para obter estas informações, é preciso definir quais são os dados que devem ser armazenados no banco de dados para que, posteriormente, possamos devolver ao cliente, as informações que satisfaçam as exigências definidas por ele, ou seja, as necessidades de informação do negócio.

19 o que afinal de contas eu vou aprender nesta disciplina!!!
Ainda não entendi o que afinal de contas eu vou aprender nesta disciplina!!!

20 Entidade-Relacionamento
Parte 2 Abordagem Entidade-Relacionamento

21 Objetivos Compreender os conceitos de ENTIDADE e algumas de suas características: RELACIONAMENTO, ATRIBUTO, CARDINALIDADE

22 Abordagem Entidade-Relacionamento
A primeira etapa do projeto de um banco de dados é a construção de um modelo conceitual, a chamada Modelagem Conceitual. MODELO CONCEITUAL LÓGICO FÍSICO A Modelagem Conceitual tem por objetivo obter uma descrição abstrata, independente de implementação em computador, dos dados que serão armazenados no banco de dados.

23 Abordagem Entidade-Relacionamento
Dentre as técnicas mais difundidas e utilizadas para a modelagem conceitual dos dados destacam-se: a Abordagem Entidade-Relacionamento, definida por Peter Chen em 1976 e que segue a metodologia de desenvolvimento Estruturado de Sistemas a UML (Unified Modeling Language), que é uma metodologia de desenvolvimento Orientado a Objeto O Modelo Entidade Relacionamento (M.E.R.) é representado graficamente pelo Diagrama Entidade Relacionamento (D.E.R.) e este é convertido para o Modelo Relacional/Lógico para ser implementado fisicamente num Banco de Dados Relacional.

24 Abordagem Entidade-Relacionamento
A UML é uma excelente metodologia, porém, até este momento, depara-se com um grande problema: ainda não existe um Banco de Dados totalmente Orientado a Objeto. Para solucionar tal problema, a UML utiliza um procedimento denominado “Mapeamento Objeto-Relacional”, de forma a permitir que as estruturas definidas no modelo Orientado a Objeto possam ser implementadas em um Banco de Dados Relacional.

25 Modelo Entidade-Relacionamento
Peter Chen, ao formular a proposta do modelo E-R baseou-se na compreensão da realidade em que se situava o problema e não na visão de um sistema de aplicação. CHEN preocupou-se em destacar a importância de reconhecer os objetos (coisas) que compõem este negócio, independentemente de preocupar-se com formas de tratamento das informações, procedimentos, programas, etc Estes objetos ele classificou em dois grupos: ENTIDADE e RELACIONAMENTO

26 Abordagem Entidade-Relacionamento
Faz Contém PEDIDO CLIENTE PRODUTO O fato acima pode acontecer em qualquer realidade. Ele deve, portanto, ser retratado através de elementos básicos que compõem o Modelo ER.

27 Modelo Entidade-Relacionamento (M.E.R.)
Os componentes básicos do Modelo ER são: ENTIDADES RELACIONAMENTOS ATRIBUTOS

28 Modelo ER: ENTIDADE ENTIDADE
“Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no Banco de Dados” (Heuser). Considera-se objeto qualquer coisa perceptível ou manipulável. É uma “coisa” ou um “objeto” no mundo real que pode ser identificada de forma única em relação aos outros objetos. São as “coisas” que existem no negócio sobre as quais temos interesse em manter armazenadas no banco de dados.

29 Modelo ER: ENTIDADE ENTIDADE
Uma ENTIDADE é uma representação de um CONJUNTO DE DADOS do negócio, um conjunto de informações de mesmas características e suas ocorrências. É representada através de um retângulo com o nome da entidade em seu interior. CLIENTE PRODUTO FUNCIONÁRIO NOTA FISCAL ORDEM DE PRODUÇÃO

30 Modelo ER: ENTIDADE Exemplo:
O retângulo CLIENTE representa o conjunto de todas as pessoas sobre as quais se deseja manter informações no BD.. CLIENTE Este objeto particular (um dos clientes) é chamado de OCORRÊNCIA de uma entidade, neste caso CLIENTE.

31 Modelo ER: ENTIDADE As ocorrências de uma entidade não são representadas no DER mas são semanticamente interpretadas no mesmo, ou seja, ao visualizar uma entidade, devemos entendê-la como uma tabela de dados, onde cada linha representa uma ocorrência da mesma. FUNCIONÁRIO Matrícula Nome Data Admissão João Carlos da Silva /04/91 Sílvia de Oliveira /02/92 Carla Martinez /04/92

32 Modelo ER: ENTIDADE Exemplo:
Quais são as “coisas” que vocês conseguem identificar nos LABORATÓRIOS de INFORMÁTICA da UNINOVE ? Máquinas Bancadas Pessoas Quadro-negro Canetas Ar-condicionado

33 Modelo ER: ENTIDADE PERGUNTA 1 !!
Todas estas “coisas” identificadas deveriam ter seus dados armazenados, caso nós quiséssemos desenvolver um Sistema para Controlar os Equipamentosdos Laboratórios de Informática? NÃO!!! Pois se quero controlar equipamentos, a entidade PESSOA, por exemplo, não teria importância alguma no contexto

34 Modelo ER: ENTIDADE PERGUNTA 2 !!
Se ao invés do caso anterior, nós quiséssemos desenvolver um sistema para controlar não somente os Equipamentos existentes, mas também a Utilização dos Laboratórios ? Neste caso temos que lembrar que quem utiliza, ou seja, as PESSOAS são de interesse do sistema

35 Modelo ER: PROPRIEDADES
Além de especificar as entidades, ou seja, os objetos sobre os quais se deseja manter informações, o MER deve permitir a especificação das PROPRIEDADES destas entidades. Estas propriedades são : Ter um ATRIBUTO Participar de um Relacionamento

36 Modelo ER : ATRIBUTO ATRIBUTO
Dado que é associado a cada ocorrência de uma entidade ou de um relacionamento (características específicas)

37 Modelo ER: ATRIBUTO Ex 1: Projeto
Em uma entidade Projeto, por exemplo, poderá ser importante armazenar o Código, o Tipo e no nome do Projeto. A representação gráfica deverá ficar, então: ENTIDADE PROJETO tipo ATRIBUTOS código nome

38 Modelo ER: ATRIBUTO Ex 2: Funcionário
Vamos supor que em uma empresa temos uma entidade chamada Funcionario, ou seja, um objeto sobre o qual desejamos manter informações. O que descreve FUNCIONÁRIO? - um número de matrícula, o nome do funcionário, sua data de admissão, data de nascimento, valor do salário,... FUNCIONÁRIO Número Matrícula Nome Data Admissão Data Nascimento Valor Salário

39 Modelo ER: ATRIBUTO Cada ocorrência de Funcionário será formada por valores nestes atributos e o conjunto destes valores representa a informação de um funcionário que devemos visualizar como uma linha de uma tabela de dados. Entidade: Funcionário Data Admissão Matrícula Nome João Carlos da Silva /04/91 Sílvia de Oliveira /02/92 Carla Martinez /04/92 Pedro Guilherme Souza /01/92

40 Modelo ER: ATRIBUTO Os atributos podem ser de vários tipos:
CLIENTE Endereço Nome CPF Telefone Os atributos podem ser de vários tipos: monovalorado: possui apenas um valor que não pode ser decomposto. Ex: CPF multivalorado: possui vários valores na mesma ocorrência. Ex: Telefone composto: possui vários valores sobre o mesmo nome e quando decomposto não perde o sentido. Ex: Nome, Endereço

41 Modelo ER: ATRIBUTO IDENTIFICADOR
Cada entidade deve possuir um identificador!!! IDENTIFICADOR  é um conjunto de um ou mais atributos (e possivelmente relacionamentos) cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade código PESSOA nome endereço Identificador simples Cód. Departamento DISCIPLINA Cód. Disciplina Nome da disciplina Identificador composto

42 Modelo ER: ATRIBUTO IDENTIFICADOR
O identificador de uma Entidade deve obedecer UMA propriedade: Deve ser MÍNIMO  isto é, se retirarmos um dos atributos ou relacionamentos que o compõe, ele deixa de ser identificador Não é necessário utilizar Código e nome para identificar a entidade. Código é suficiente para distinguir as ocorrências de PESSOA código PESSOA nome endereço

43 Modelo ER: RELACIONAMENTO
Conjunto de associações entre entidades através de algo comum. LOTAÇÃO DEPARTAMENTO PESSOA Um conjunto de objetos classificados como pessoa (Entidade PESSOA) ; Um conjunto de objetos classificados como departamento (Entidade DEPARTAMENTO); Um conjunto de ASSOCIAÇÕES, cada uma ligando um departamento a uma pessoa (relacionamento LOTAÇÃO);

44 Modelo ER: RELACIONAMENTO
No nosso dia-a-dia convivemos com os mais variados tipos de entidades (objetos reais), que são descritos por uma série de atributos (características) e que expressam uma realidade de existência. Estas entidades do dia-a-dia estão relacionadas de forma a mostrar a realidade com um conteúdo lógico: As pessoas Moram em Apartamentos; Os apartamentos Formam Condomínios; Os condomínios Localizam-se em Ruas ou Avenidas; As Avenidas e Ruas Estão em uma Cidade

45 Modelo ER: RELACIONAMENTO
Assim como ocorre com as entidades, temos as ocorrências de relacionamentos. Isto pode ser melhor observado através do Diagrama de Ocorrências. Nele, ocorrências de entidades são representadas por círculos brancos e de relacionamentos por círculos pretos.

46 Modelo ER: RELACIONAMENTO
Neste caso, uma ocorrência seria um par específico formado por uma determinada ocorrência da entidade PESSOA e por uma determinada ocorrência da entidade DEPARTAMENTO p3 p7 p8 Entidade p4 p1 p2 p5 PESSOA Relacionamento p4,d2 LOTAÇÃO p1,d1 p5,d3 p2,d1 Entidade DEPARTAMENTO d3 d1 d2 Diagrama de ocorrências

47 Modelo ER: RELACIONAMENTO
Assim como Entidade, Relacionamentos também podem possuir atributos ENGENHEIRO código nome PROJETO título ATUAÇÃO (0,n) Função No exemplo, ATUAÇÃO possui um atributo (Função), ou seja, o papel que um engenheiro deve desempenhar dentro de um projeto. Função  ENGENHEIRO Função  PROJETO

48 Modelo ER: CARDINALIDADE
CARDINALIDADE (mínima e máxima) num relacionamento É o número (mínimo,máximo) de ocorrências de uma entidade associadas a uma ocorrência de outra entidade através do relacionamento

49 Modelo ER: LEITURA da CARDINALIDADE
? HOMEM CASADO MULHER PERGUNTA: Um homem pode estar casado com quantas mulheres? RESPOSTA: Um homem pode não ser casado com NENHUMA mulher, portanto a cardinalidade mínima é “0”; Um homem pode se casar com no máximo UMA mulher, portanto, a cardinalidade máxima é “1”; HOMEM CASADO (0,1) MULHER

50 Modelo ER: LEITURA da CARDINALIDADE
? HOMEM CASADO MULHER PERGUNTA: Uma mulher pode estar casada com quantos homens? RESPOSTA: Uma mulher pode não ser casada com NENHUM homem, portanto a cardinalidade mínima é “0”; Uma mulher pode se casar com no máximo UM homem, portanto, a cardinalidade máxima é “1”; HOMEM (0,1) CASADO MULHER

51 Modelo ER: LEITURA da CARDINALIDADE
HOMEM CASADO (0,1) MULHER HOMEM (0,1) CASADO MULHER HOMEM (0,1) CASADO (0,1) MULHER

52 Modelo ER: Cardinalidade MÍNIMA
Cardinalidade Mínima  é o número mínimo de ocorrências de uma entidade associadas a uma ocorrência de outra entidade num relacionamento Consideram-se apenas duas cardinalidades: Opcional (“0”)  indica que o relacionamento existe independente de haver ou não uma ocorrência de uma entidade ligada à outra Obrigatória (“1”)  indica que o relacionamento deve obrigatoriamente associar uma ocorrência de uma entidade a uma ocorrência de outra entidade

53 Modelo ER: Cardinalidade MÍNIMA
EMPREGADO (0,n) ALOCAÇÃO (1,1) DEPARTAMENTO Cada empregado deve estar obrigatoriamente alocado a um setor-departamento (“1”) Um setor-departamento pode existir mesmo que não exista nenhum empregado alocado nele (“0”)

54 Modelo ER: Cardinalidade MÁXIMA
Cardinalidade Máxima  é o número máximo de ocorrências de uma entidade associadas a uma ocorrência de outra entidade num relacionamento Consideram-se apenas duas cardinalidades: “1”  indica que uma ocorrência de uma determinada entidade pode estar associada a no máximo UMA ocorrência da entidade relacionada a ela “n”  indica que uma ocorrência de uma determinada entidade pode estar associada a muitas ocorrências da entidade relacionada a ela

55 Modelo ER: Cardinalidade MÁXIMA
EMPREGADO LOTAÇÃO DEPARTAMENTO (0,n) (1,1) Uma ocorrência de empregado pode estar associada a no máximo uma (“1”) ocorrência de departamento, isto é, empregado tem cardinalidade máxima 1 no relacionamento Lotação Uma ocorrência de departamento pode estar associada a muitas (“n”) ocorrências de empregado, isto é, Departamento tem cardinalidade máxima n no relacionamento Lotação

56 Modelo ER: TIPO DE RELACIONAMENTO
Para a descoberta do tipo de relacionamento devemos analisar de forma macro a possibilidade de relacionamentos entre as entidades, sendo que a ocorrência de maior valor é que determina sempre o tipo do relacionamento (cardinalidade máxima). São eles: 1:1 1:N N:N

57 Modelo ER: TIPO DE RELACIONAMENTO
Relacionamento de 1:1  Cada elemento de uma entidade relaciona-se com um e somente um elemento de outra entidade HOMEM MULHER A • B • C • D • • X • Y • Z • W (0,1) CASADO (0,1) MULHER HOMEM

58 Modelo ER: TIPO DE RELACIONAMENTO
Exemplo  Relacionamento de 1:1 (0,1) (0,1) GERENCIADA GERÊNCIA DIVISÃO Cada divisão é gerenciada por UM e apenas UM gerente Cada gerente administra UMA e apenas UMA divisão

59 Modelo ER: TIPO DE RELACIONAMENTO
Relacionamento de 1:N  Cada elemento da entidade A relaciona-se com muitos elementos da entidade B, mas cada elemento da entidade B só pode estar relacionado a um elemento da entidade A FILHO MÃE • a • b • c • d • e • f A • B • C • Este tipo de relacionamento é o mais comum no mundo real, entretanto, possui características específicas quanto ao sentido de leitura dos fatos e sua interpretação

60 Modelo ER: TIPO DE RELACIONAMENTO
Exemplo  Relacionamento de 1:N POSSUI (1,n) FILHO MÃE (1,1) POSSUI FILHO MÃE A cardinalidade determinante é sempre a máxima obtida da interpretação dos fatos (1,1) POSSUI (1,n) FILHO MÃE

61 Modelo ER: TIPO DE RELACIONAMENTO
Regra geral: um relacionamento é do tipo 1:N quando um sentido de leitura dos fatos nos apresenta a cardinalidade máxima de 1:N e o sentido oposto apresenta obrigatoriamente cardinalidade máxima de 1:1 (1,1) POSSUI (1,n) FILHO MÃE (1,1) POSSUI (0,n) DEPENDENTE EMPREGADO

62 Modelo ER: TIPO DE RELACIONAMENTO
Relacionamento de N:N  Em ambos os sentidos de leitura encontramos uma cardinalidade máxima de 1:N, o que caracteriza ser então um contexto geral de N:N ESTUDANTE DISCIPLINA E1 • E2 • E3 • E4 • E5 • • D1 • D2 • D3 • D4 ESTUDANTE DISCIPLINA E1 • E2 • E3 • E4 • E5 • • D1 • D2 • D3 • D4

63 Modelo ER: TIPO DE RELACIONAMENTO
Exemplo  Relacionamento de N:N ALUNO CURSA DISCIPLINA (0,n) (0,n)

64 Modelo ER: TIPO DE RELACIONAMENTO
CURSA 1 2 3 4 5 6 7 8 DISCIPLINA ALUNO • D1 • D2 • D3 • D4 E1 • E2 • E3 • E4 • E5 •

65 Modelo ER: TIPO DE RELACIONAMENTO
Exemplo  Relacionamento de N:N (0,n) FORNECE (0,n) PRODUTO FORNECEDOR Vl_Unit Cada produto é fornecido por UM ou MUITOS fornecedores Cada fornecedor fornece UM ou MUITOS produtos Este tipo de relacionamento caracteriza-se por apresentar atributos, isto é, o relacionamento possui dados que são inerentes ao fato e não as entidades

66 Modelo ER: IDENTIFICANDO ENTIDADES
IDENTIFICADOR Relacionamento  quando o identificador de uma entidade é composto por atributos da própria entidade e também por relacionamentos dos quais a entidade participa Número seqüência nome código nome (1,1) (0,n) EMPREGADO DEPENDENTE CADA dependente está relacionado a exatamente UM empregado um dependente é identificado através do código do empregado ao qual ele está relacionado e por um número de seqüência que distingue os diferentes dependentes de um mesmo empregado Alguns autores chamam esta entidade de “FRACA” pois ela só existe relacionada à outra entidade

67 Modelo ER: GRAU DE RELACIONAMENTO
É o número de entidades ligadas num mesmo relacionamento. São eles: Grau 1 ou Auto-relacionamento Grau 2 ou Binário Grau 3 ou Ternário N-ário (acima de 3 entidades)

68 Modelo ER: GRAU DE RELACIONAMENTO
Grau 1 ou Auto-relacionamento  Quando existe apenas uma entidade envolvida num relacionamento, ou seja, uma entidade se relacionando com ela mesma. Neste caso, é necessário definir o papel da entidade no relacionamento, ou seja, a função que a entidade exerce dentro do relacionamento p3 p7 p8 p4 p1 PESSOA p2 p5 marido marido marido esposa esposa CASAMENTO esposa p2,p3 p4,p5 Uma ocorrência de pessoa exerce o papel de marido e a outra ocorrência exerce o papel de esposa

69 Modelo ER: GRAU DE RELACIONAMENTO
Grau 2 ou Binário  é quando existem duas entidades envolvidas num mesmo relacionamento. 1:1  Um para Um HOMEM MULHER CASADO 1 1:N  Um para Muitos ALUNO CURSO INSCRIÇÃO n 1 N:N  Muitos para muitos MÉDICO PACIENTE ATENDE n

70 Modelo ER: GRAU DE RELACIONAMENTO
Grau 3 ou Ternário  é quando existem três entidades envolvidas num mesmo relacionamento. CIDADE DISTRIBUIDOR n 1 DISTRIBUIÇÃO n PRODUTO Cada ocorrência do relacionamento DISTRIBUIÇÃO associa três ocorrências de entidade: - um produto a ser distribuído, - uma cidade na qual é feita a distribuição e - um distribuidor

71 Modelo ER: GRAU DE RELACIONAMENTO
Neste caso analisaremos PARES de entidades DISTRIBUIDOR CIDADE n 1 DISTRIBUIÇÃO A cardinalidade “1”refere-se a um par cidade produto n PRODUTO Cada par de ocorrências de Cidade e Produto está relacionado a NO MÁXIMO um distribuidor , isto é, em cada cidade só pode haver um distribuidor para cada produto.

72 Modelo ER: GRAU DE RELACIONAMENTO
CIDADE DISTRIBUIDOR n 1 DISTRIBUIÇÃO n PRODUTO (Cidade, Produto) está associado a no Máximo 1 Distribuidor  Cada produto só pode ter um distribuidor em cada cidade (Cidade, Distribuidor) está associada a MUITOS produtos  um distribuidor pode distribuir muitos produtos em uma cidade (Distribuidor, Produto) está associado a MUITAS cidades  um produto pode ser distribuído em muitas cidades por um distribuidor

73 Modelo ER: EXERCÍCIOS (0,n) 2) Observe o MER e responda às questões:
1) Explique a diferença entre uma entidade e uma ocorrência de entidade. 2) Observe o MER e responda às questões: PRÉ_REQUIS (0,n) (0,n) DEPARTAMENTO RESPONSÁVEL DISCIPLINA (1,1) (0,n) (0,n) DISC-CURSO ALUNO (0,n) (0,n) INSCRIÇÃO (1,1) CURSO

74 Modelo ER: EXERCÍCIOS Identifique as entidades e os relacionamentos do modelo; Interprete cada um dos relacionamentos abaixo, identificando o tipo de cardinalidade e o grau do relacionamento: a) b) c) d) RESPONSÁVEL DEPARTAMENTO DISCIPLINA (1,1) (0,n) INSCRIÇÃO ALUNO CURSO (0,n) (1,1) PRÉ_REQUIS DISCIPLINA (0,n) (0,n) (0,n) DISC-CURSO DISCIPLINA (0,n) CURSO

75 Modelo ER: EXERCÍCIOS ____ ____ ____ ____
3) Identifique a Cardinalidade dos relacionamentos, exibindo os passos conforme o exemplo: Um Aluno DEVE estar inscrito em no mínimo um curso (mínimo “1”) e somente UM curso (máximo “1”). Um Curso pode ter NENHUM aluno inscrito ou MUITOS alunos inscritos. a) b) ALUNO INSCRIÇÃO CURSO (0,n) (1,1) ____ ____ ATENDE MÉDICO PACIENTE ____ ____ ALOCAÇÃO ENGENHEIRO PROJETO

76 Modelo ER: EXERCÍCIOS ____ ____ ____ ____ ____ ___ ____ ___ c) d) e)
f) COMPOSIÇÃO ____ compõe ____ é composto PRODUTO FORNECE PEÇA FORNECEDOR ____ ____ POSSUI EMPREGADO DEPENDENTE ____ ___ PRESCRIÇÃO MÉDICO MEDICAMENTO ____ ___

77 Modelo ER: EXERCÍCIOS 4) Identifique as entidades, os relacionamentos e a cardinalidade entre os relacionamentos, como no exercício 1. trabalha EMPREGADO DEPARTAMENTO gerencia possui controla trabalha PROJETO DEPENDENTE

78 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
É importante, durante a visualização dos dados, prestar atenção ao nível de abstração em que estamos atuando, pois, quando definimos uma entidade, estamos com a visão de uma classe genérica de dados, que pode estar incorporando, implicitamente, diversas outras classes de dados Ou seja, temos classes diferenciadas mas que possuem características que nos permitam colocá-las sob a visão de uma única entidade. Por exemplo, CLIENTE é na realidade uma generalização para diversas classes de dados de clientes, tais como: - Cliente – Pessoa Física - Cliente – Pessoa Jurídica

79 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
Através deste conceito é possível atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. FILIAL CLIENTE PESSOA FÍSICA JURÍDICA CPF Sexo CNPJ Tipo de organização nome código (0,n) (1,1) Cliente é dividida em dois subconjutnos, as entidades PESSOA FÍSICA e JURÍDICA, cada uma com propriedades específicas

80 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
Mas por que a preocupação deste gênero? Quando ela se torna importante? Ela é importante porque podemos vir a ter na análise funcional do sistema, tratamentos procedurais e diferenciados para cada subconjunto, assim como poderemos tratar simultaneamente todos os conjuntos. Desta forma, devemos representá-los de forma que possamos vir a tratá-los como um todo ou como parte do todo

81 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
HERANÇA DE PROPRIEDADE  cada ocorrência da entidade especializada possui, além de suas propriedades, também as propriedades da ocorrência da entidade genérica. FILIAL CLIENTE PESSOA FÍSICA JURÍDICA CPF SEXO CNPJ Tipo de organização nome código (0,n) (1,1) Pessoa Física tem como atributos nome, código, CPF e sexo. É identificada pelo código e está obrigatoriamente relacionada a exatamente uma filial.

82 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
CLIENTE PESSOA FÍSICA JURÍDICA CPF Sexo CNPJ Tipo de organização nome código t Generalização TOTAL  para cada ocorrência da entidade genérica existe sempre uma ocorrência em uma das entidades especializadas. Isto é válido para o exemplo pois, para TODA ocorrência de cliente deve haver uma ocorrência em uma das duas especializações

83 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
FUNCIONÁRIO MOTORISTA SECRETÁRIA Tipo de funcionário p Generalização PARCIAL  nem toda ocorrência da entidade genérica corresponde a uma ocorrência em uma entidade especializada. Ex: Nem todo funcionário é Motorista ou secretária!! Neste caso, há necessidade de especificar o atributo que identifica o tipo de ocorrência da entidade genérica

84 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
Uma entidade pode ser especializada em qualquer número de entidades, inclusive em uma única. FUNCIONÁRIO MOTORISTA Tipo de funcionário p VEÍCULO TERRESTRE AQUÁTICO AUTOMÓVEL ANFÍBIO BARCO

85 Modelo ER: GENERALIZAÇÃO/ESPECIALIZAÇÃO
Só pode haver UMA ENTIDADE GENÉRICA em cada hierarquia de generalização/Especialização

86 Modelo ER: ENTIDADE ASSOCIATIVA
CONSULTA MÉDICO n n PACIENTE Como ficaria o modelo se quiséssemos saber QUE MEDICAMENTOS EXISTEM e QUAIS FORAM PRESCRITOS em cada consulta? Teríamos, claro, que definir uma nova entidade, denominada MEDICAMENTO. Mas, como esta nova entidade deveria estar relacionada no modelo? Ou seja, ela deveria estar ligada a MÉDICO ou a PACIENTE ?

87 Modelo ER: ENTIDADE ASSOCIATIVA
1a OPÇÃO CONSULTA MÉDICO n n PACIENTE n PRESCRIÇÃO n MEDICAMENTO Neste caso, teríamos a informação de que médico prescreve qual medicamento. Entretanto, não teríamos a informação de quais pacientes receberam a prescrição.

88 Modelo ER: ENTIDADE ASSOCIATIVA
2a OPÇÃO CONSULTA MÉDICO n n PACIENTE n PRESCRIÇÃO n MEDICAMENTO Neste outro caso, teríamos a informação de quais pacientes receberam quais medicamentos, porém, não saberíamos dizer qual foi o médico que prescreveu tais medicamentos.

89 Modelo ER: ENTIDADE ASSOCIATIVA
SOLUÇÃO CONSULTA MÉDICO n n PACIENTE n PRESCRIÇÃO n MEDICAMENTO A entidade MEDICAMENTO, portanto, deve estar relacionado ao relacionamento CONSULTA. A isso, damos o nome de ENTIDADE ASSOCIATIVA, ou seja, o relacionamento que passa a ser tratado como se fosse também uma entidade.

90 Modelo ER: ENTIDADE ASSOCIATIVA
MÉDICO PACIENTE (1,1) (1,1) n Caso não se desejasse usar o conceito de Entidade Associativa, seria necessário transformar o relacionamento CONSULTA em uma entidade. Neste caso, uma consulta deve estar relacionada com exatamente um médico e um paciente. n CONSULTA n PRESCRIÇÃO n MEDICAMENTO

91 Modelo Relacional/Lógico
Parte 3 Modelo Relacional/Lógico 91

92 Modelo Relacional/Lógico – TABELAS
Uma tabela é um conjunto não ordenado de linhas (tuplas, na terminologia acadêmica). Cada linha é composta por uma série de campos (valor de atributo). Nome Código 0111 0112 0271 0108 0357 0097 João Antônio Carlos Eduardo Luís Vera Data Admissão 12/11/2000 12/12/2001 05/06/2001 03/03/2000 20/10/2001 15/02/2002 Código Depto 01 10 21 linha coluna A primeira linha (registro) da tabela quer dizer que o Cliente João, cujo código é igual a 0111, foi admitido no dia 12/11/2000 e trabalha no Departamento cujo código é 01. 92

93 Modelo Relacional/Lógico – TABELAS
coluna (atributo) linha(tupla) Código Nome Data Admissão Código Depto 0111 0112 0271 0108 0357 0097 João Antônio Carlos Eduardo Luís Vera 12/11/2000 12/12/2001 05/06/2001 03/03/2000 20/10/2001 15/02/2002 01 10 21 Valor do campo As linhas de uma tabela não tem ordenação. A ordem de recuperação pelo SGBD é arbitrária, a menos que a instrução de consulta tenha especificado explicitamente uma ordenação (ORDER BY).

94 Modelo Relacional/Lógico – CHAVES
CHAVE  é a forma de identificar linhas e estabelecer relações entre linhas de tabelas de um banco de dados relacional CHAVE PRIMÁRIA é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela Nome CodEmp E5 E3 E2 E1 Souza Santos Silva Soares CategFuncional C5 C2 ---- D1 D2 CodDepto Empregado

95 Modelo Relacional/Lógico – CHAVES
Nome CodEmp E5 E3 E2 E1 Souza Santos Silva Soares CategFuncional C5 C2 ---- D1 D2 CodDepto Empregado Chave Primária Simples EmpxProj Chave Primária Composta Horastrab CodEmp E1 E2 E6 86 32 180 40 120 01 02 CodProj

96 Modelo Relacional/Lógico – CHAVES
CHAVE ESTRANGEIRA é uma coluna ou uma combinação de colunas cujos valores aparecem necessariamente na chave primária de uma tabela. É ela que permite a implementação de relacionamentos em um banco de dados relacional Chave estrangeira Nome CodEmp E5 E3 E2 E1 Souza Santos Silva Soares CategFuncional C5 C2 ---- D1 D2 CodDepto Empregado

97 Modelo Relacional/Lógico – CHAVES
Tabela: Departamento CodDepto Nome Depto Verba Qual o nome do departamento do Funcionário João? 01 10 21 Contabilidade Vendas Faturamento 9.500,00 15.000,00 12.800,00 Tabela: Empregado Codigo Nome Data Admissão CodDepto 0111 0112 0271 0108 0357 0097 João Antônio Carlos Eduardo Luís Vera 12/11/2000 12/12/2001 05/06/2001 03/03/2000 20/10/2001 15/02/2002 01 10 21

98 Modelo Relac./Lógico – EXPRESSÃO RELACIONAMENTO
Quais os funcionários do Depto de vendas? - Código do Depto de vendas = 10 Quais os funcionários que tem código do Depto igual a 10? - Carlos, Eduardo e Luís Tabela: Departamento CodDepto Nome Depto Verba 01 10 21 Contabilidade Vendas Faturamento 9.500,00 15.000,00 12.800,00 Tabela: Empregado Código Nome Data Admissão Código Depto 0111 0112 0271 0108 0357 0097 João Antônio Carlos Eduardo Luís Vera 12/11/2000 12/12/2001 05/06/2001 03/03/2000 20/10/2001 15/02/2002 01 10 21

99 Modelo Relacional/Lógico – REGRAS DE CONVERSÃO
Modelo Conceitual para o Modelo Relacional/Lógico: Cada entidade do Modelo Conceitual transforma-se em uma tabela no Modelo Relacional/Lógico contendo como campos os respectivos atributos da entidade. O atributo identificador da entidade transforma-se em chave primária na tabela. Analisar os relacionamentos entre as entidades para gerar a chave estrangeira, aplicando a regra de acordo com o tipo de relacionamento:

100 Modelo Relacional/Lógico – REGRAS DE CONVERSÃO
Analisando os relacionamentos: Relacionamento de 1:N – Não cria nova tabela, mas a chave primária da tabela de lado 1 transforma-se em chave estrangeira na tabela de lado N do relacionamento. Caso o relacionamento contenha atributos, esses devem acompanhar a chave estrangeira. 1 LOTAÇÃO N DEPARTAMENTO EMPREGADO

101 Modelo Relacional/Lógico – REGRAS DE CONVERSÃO
Analisando os relacionamentos: Relacionamento de N:N – Cria-se nova tabela cuja chave primária será composta pela chave primária das duas tabelas relacionadas. Caso o relacionamento contenha atributos, esses devem ser adicionados na nova tabela, do contrário, será uma tabela contendo apenas a chave primária. Esses campos receberão a restrição de chave primária composta e ao mesmo tempo serão, individualmente, chave estrangeira. N ALOCADO N PROJETO EMPREGADO HorasTrab

102 Modelo Relacional/Lógico – REGRAS DE CONVERSÃO
Analisando os relacionamentos: Relacionamento de 1:1 – Não cria nova tabela, mas a chave primária de um dos lados deve se transformar em chave estrangeira do outro lado do relacionamento. O lado a ser escolhido deverá ser aquele que terá menor possibilidade de conter valores nulos na coluna que será a chave estrangeira. Caso o relacionamento contenha atributos, esses devem acompanhar a chave estrangeira. 1 GERA 1 PEDIDO NOTA FISCAL DataEmissão

103 Modelo Relacional/Lógico – REGRAS DE CONVERSÃO
ATENÇÃO: Qualquer tabela que não tenha sido gerada de acordo com essa regra está errada, ou seja, todas as tabelas que surgirem no modelo relacional devem corresponder a uma entidade ou ser fruto do relacionamento de N:N no modelo conceitual. Uma tabela gerada a partir do relacionamento de N:N só contém campos além das chaves se esses forem atributos do relacionamento na Modelagem Conceitual.

104 Modelo Relac./Lógico – RESTRIÇÕES DE CHAVES
A existência de uma chave estrangeira impõe restrições que devem ser garantidas ao executar diversas operações de alteração no banco de dados Quando da inclusão de uma linha na tabela que contém a chave estrangeira (ela deve existir na chave primária); Quando da alteração do valor da chave estrangeira (ele deve existir na chave primária); Quando da exclusão de uma linha da tabela que contém a chave primária referenciada pela chave estrangeira (verificar se outra tabela a utiliza); Quando da alteração do valor da chave primária referenciada pela chave estrangeira (garantir que na coluna chave estrangeira não apareça o antigo valor da chave primária alterada);

105 Modelo Relac./Lógico – DOMÍNIOS E VALORES VAZIOS
Quando uma tabela do banco de dados é definida, para cada coluna da tabela, deve ser especificado um conjunto de valores (alfanumérico, numérico,..) que os campos da respectiva coluna podem assumir. Este conjunto de valores é chamado de DOMÍNIO DA COLUNA ou do CAMPO Também deve ser especificado se os campos da coluna podem estar vazios (“null” em inglês) ou não. As colunas nas quais não são admitidos valores vazios são chamadas de colunas Obrigatórias e as outras são chamadas de Opcionais.

106 Parte 4 Álgebra Relacional
106

107 Álgebra Relacional – OPERAÇÕES
Conjunto de operadores de alto nível que manipulam os dados coletados em uma ou mais tabelas. Tipos de Operações: Tradicionais UNIÃO (OPERADOR OU) INTERSECÇÃO (OPERADOR E) DIFERENÇA PRODUTO CARTESIANO Especiais SELEÇÃO PROJEÇÃO JUNÇÃO

108 Álgebra Relacional – OPERAÇÕES
UNIÃO COMPATÍVEL Quando as relações possuem as mesmas estruturas São consideradas operações do tipo União Compatível as operações de UNIÃO, INTERSECÇÃO e DIFERENÇA.

109 Álgebra Relacional – SIMBOLOGIAS
UNIÃO – A  B INTERSEÇÃO – A  B DIFERENÇA – A B SELEÇÃO –  (Condição seleção) PROJEÇÃO –  (Lista de Campos) PROD.CARTESIANO – A  B JUNÇÃO – A x <condição de junção> B

110 Álgebra Relacional – SIMBOLOGIAS
SELEÇÃO Ex:  < condição de seleção > (nome da relação) PROJEÇÃO Ex:  < lista de campos > (nome da relação) JUNÇÃO é uma operação de Produto Cartesiano seguida pela operação de seleção. Ex: R x < condição JOIN > S  < condição de seleção > (R  S)

111 Álgebra Relacional – UNIÃO
A união de duas tabelas normalizadas “A” e “B”, é uma tabela normalizada “C” que contém todas as linhas de “A” e/ou “B”.

112 Álgebra Relacional – INTERSECÇÃO
A intersecção das tabelas “A” e “B” é uma tabela normalizada “C” que só contém aquelas linhas que pertencem a “A” e “B” simultaneamente.

113 Álgebra Relacional – DIFERENÇA
A diferença entre duas tabelas “A” e “B” é uma tabela normalizada “C” que contém as linhas de “A” que não pertencem a “B”.

114 Álgebra Relacional – PRODUTO CARTESIANO
O produto cartesiano de duas tabelas “A” e “B” é uma tabela “C” cujas linhas são obtidas fazendo todas as concatenações possíveis entre as linhas de “A” e “B”.

115 Álgebra Relacional – PROJEÇÃO
A projeção de uma tabela normalizada sobre uma ou várias de suas colunas é uma nova tabela que contém somente as colunas projetadas.

116 Structured Query Language
Parte 5 SQL Structured Query Language 116

117 SQL – Structured Query Language
( Linguagem Estrutura de Consulta ) Compõe-se de: DDL – criação do esquema, ou seja, estruturas de armazenamento DML – linguagem de consulta baseada em álgebra relacional DCL – linguagem de controle de acessos e autorização Estrutura básica de uma expressão SQL: Onde Ai = atributo i, ti = tabela i e C = conjunto de condições

118 SQL – Structured Query Language
Forma o produto cartesiano das tabelas indicadas na cláusula FROM (quando houver mais de uma tabela na cláusula) Executa uma seleção da álgebra relacional usando as condições da cláusula WHERE Projeta o resultado para os atributos da cláusula SELECT Obs.: O caractere * permite selecionar todos os atributos de uma ou mais tabelas, quando colocado após a cláusula SELECT Ex.: SELECT * FROM Tabela1

119 SQL – Structured Query Language
SELEÇÃO A SELEÇÃO DE UMA TABELA “T” COM REFERÊNCIA A CERTA CONDIÇÃO, É UMA OUTRA TABELA “R” QUE CONTÉM TODAS AS LINHAS DE “T” PARA AS QUAIS A CONDIÇÃO É CERTA. NRO_PED DATA REG_VDA TOTAL 10 23/01/86 SP 1250 11 13/12/87 RJ 722 12 27/01/86 347 14 28/04/87 MG 2455 17 27/03/86 GO 145 T R=SELEÇÃO T; (REG_VDA .NEQ. ‘SP’ AND TOTAL .GT. 500) NRO_PED DATA REG_VDA TOTAL 11 13/12/87 RJ 722 14 28/04/87 MG 2455 R

120 SQL – Structured Query Language
SELEÇÃO - Exemplos TAB. AGENCIA AG_NUM AG_NOME ENDERECO REGIAO 11-002 Itaim R. Dr. Mário F. Sul 11-003 Sto. Amaro Lgo. 13 de Maio 12-005 Boa Vista R. Boa Vista, 2 Centro 12-007 Direita R. Direita, 344 15-001 Diamantina R. Diamantina Norte AG_NUM AG_NOME ENDERECO REGIAO 11-002 Itaim R. Dr. Mário F. Sul 11-003 Sto. Amaro Lgo. 13 de Maio 12-005 Boa Vista R. Boa Vista, 2 Centro 12-007 Direita R. Direita, 344 15-001 Diamantina R. Diamantina Norte a) SELECT * FROM Agencia b) SELECT AG_NOME, REGIAO FROM Agencia AG_NOME REGIAO Itaim Sul Sto. Amaro Boa Vista Centro Direita Diamantina Norte

121 SQL – Structured Query Language
SELEÇÃO - Exemplos AG_NUM AG_NOME ENDERECO REGIAO 11-002 Itaim R. Dr. Mário F. Sul 11-003 Sto. Amaro Lgo. 13 de Maio 12-005 Boa Vista R. Boa Vista, 2 Centro 12-007 Direita R. Direita, 344 15-001 Diamantina R. Diamantina Norte TAB. AGENCIA c) SELECT AG_NOME, REGIAO FROM Agencia WHERE REGIAO = “Centro” AG_NOME REGIAO Boa Vista Centro Direita d) SELECT AG_NOME, REGIAO FROM Agencia WHERE REGIAO <> “Centro” AG_NOME REGIAO Itaim Sul Sto. Amaro Diamantina Norte e) SELECT REGIAO FROM Agencia REGIAO Sul Centro Norte f) SELECT DISTINCT REGIAO FROM Agencia REGIAO Sul Centro Norte

122 SQL – Structured Query Language
JOIN - Fusão A fusão de duas tabelas A e B com referência a um atributo ou conjunto de atributos comuns é uma tabela que contém todas as linhas obtidas concatenando linhas de A e linhas de B para as quais o atributo escolhido tem o mesmo valor. A: PEDIDOS B: FORNECEDORES PEDIDO FORNEC DATA 720 214 110295 721 273 220595 916 120396 930 240496 FORNEC NOME 214 ALFA AS 273 BETA AS 283 GAMA AS C: Fusão de A e B segundo FORNEC PEDIDO FORNEC DATA NOME 720 214 110295 ALFA AS 721 273 220595 BETA AS 916 120396 930 240496

123 SQL – Structured Query Language
JOIN - Exemplos TAB. AGENCIA TAB. CLIENTE AG_NUM AG_NOME ENDERECO REGIAO 11-002 Itaim R. Dr. Mário F. Sul 11-003 Sto. Amaro Lgo. 13 de Maio 12-005 Boa Vista R. Boa Vista, 2 Centro 12-007 Direita R. Diereita, 344 15-001 Diamantina R. Diamantina Norte NUM_CLI NOM_CLI AG_NUM END_CLI 1002 Jair Bastos 12-005 R 1003 Nair Mendes 15-001 Av 1004 Nelson Alves 11-002 R 1005 Ana Pádua 1006 Hugo Torres 11-003 ... 1007 Tiago Melo a) SELECT * FROM Agencia, Cliente  Produto Cartesiano b) SELECT NUM_CLI,NOM_CLI,AG_NOME FROM Agencia, Cliente WHERE Agencia.AG_NUM = Cliente.AG_NUM NUM_CLI NOM_CLI AG_NOME 1002 Jair Bastos Boa Vista 1003 Nair Mendes Diamantina 1004 Nelson Alves Itaim 1005 Ana Pádua 1006 Hugo Torres Sto. Amaro 1007 Tiago Melo

124 SQL – Structured Query Language
JOIN - Exemplos TAB. AGENCIA TAB. CLIENTE AG_NUM AG_NOME ENDERECO REGIAO 11-002 Itaim R. Dr. Mário F. Sul 11-003 Sto. Amaro Lgo. 13 de Maio 12-005 Boa Vista R. Boa Vista, 2 Centro 12-007 Direita R. Diereita, 344 15-001 Diamantina R. Diamantina Norte NUM_CLI NOM_CLI AG_NUM END_CLI 1002 Jair Bastos 12-005 R 1003 Nair Mendes 15-001 Av 1004 Nelson Alves 11-002 R 1005 Ana Pádua 1006 Hugo Torres 11-003 ... 1007 Tiago Melo c) SELECT NUM_CLI, NOM_CLI, AG_NOME FROM Agencia, Cliente WHERE Agencia.AG_NUM=Cliente.AG_NUM AND REGIAO=“Sul” NUM_CLI NOM_CLI AG_NOME 1004 Nelson Alves Itaim 1005 Ana Pádua 1006 Hugo Torres Sto. Amaro 1007 Tiago Melo d) SELECT NOM_CLI, NUM_CLI, AG_NOME FROM Agencia, Cliente WHERE Agencia.AG_NUM=Cliente.AG_NUM AND NOM_CLI LIKE “N%” NOM_CLI NUM_CLI AG_NOME Nair Mendes 1003 Diamantina Nelson Alves 1004 Itaim

125 Normalização de Tabelas
Parte 6 Normalização de Tabelas 125

126 Normalização de Tabelas
Normalização é uma técnica aceita para aumentar a confiabilidade na extração e na atualização de dados num banco de dados. Partimos de dados não-normalizados e otimizados até a 3ª Forma Normal. Note que cada grau de otimização depende do anterior, isto é, para ir à 2ª F.N. é necessário que a tabela esteja na 1ª F.N., e para ir à 3ª F.N., é necessário que a tabela esteja na 2ª F.N. Nem sempre é conveniente atingir a 3ª F.N., por várias razões. Por exemplo, o aumento da quantidade de tabelas (que provoca, no mínimo, prejuízo de performance) e pouco interesse de manter-se a consistência ou integridade dos dados.

127 Normalização de Tabelas Consequências da Não-Normalização
PEDIDO 900,00 9,00 100 GIZ 21 RUA CHUÍ N. 240 CARLOS 864 18/05 302 * 2180,00 90,00 10 CLIPS 16 RUA A, N.76 28/04 238 480,00 2,00 240 LÁPIS 63 800,00 8,00 VAL-PED-TOT VAL-PRC-TOT VAL-PRC-UNT QTD NOM-PRD NUM-PRD DES-END-CLI NOM-CLI NUM-CLI DAT NUM PERGUNTAS: Pode-se manter informação sobre um cliente que nunca fez pedido? O que acontece com os dados do cliente se for excluído o único pedido que ele fez? O que é necessário fazer para alterar informações sobre um cliente?

128 Normalização de Tabelas
PEDIDO 900,00 9,00 100 GIZ 21 RUA CHUÍ N. 240 CARLOS 864 18/05 302 * 2180,00 90,00 10 CLIPS 16 RUA A, N.76 28/04 238 480,00 2,00 240 LÁPIS 63 800,00 8,00 VAL_ TOT_ PED ITEM UNIT_ PRD QTD NOME_PRD NUM_ DES_ END_ CLI NOME_ DATA NUM NORMALIZAÇÃO

129 Normalização de Tabelas
PEDIDO CLIENTE * 2180,00 900,00 864 28/04 18/05 238 302 VAL_TOT_PED NUM_CLI (FK) DATA NUM (PK) * RUA CHUÍ, N.240 CARLOS 864 DES_END_CLI NOME NUM (PK) ITEMPRD ITEMPRD PRD * 800,00 480,00 900,00 100 240 10 21 63 16 238 302 VAL_TOT_ITEM QTD NUM_ PRD (FK) PED * 800,00 480,00 900,00 100 240 10 21 63 16 238 302 VAL_TOT_ITEM QTD NUM_ PRD (FK) PED * 98,00 9,00 2,60 CLIPS GIZ LÁPIS 16 21 63 VAL_UNIT_PRD NOME NUM (PK)

130 Normalização de Tabelas
1ª Forma Normal A 1ª F.N. exige que não se criem grupos de repetição em uma tabela, isto é, o cruzamento de linha-coluna não deve ter mais de uma informação. Também não se pode ter registros duplicados, ou seja, deve-se eliminar os atributos compostos e multivalorados.

131 Normalização de Tabelas
1ª FN – Exemplo 1 ELIMINAR DADO ESTRUTURADO (Atributo Composto) FUN 90000 8888 * JOÃO CRISTINA 0100 0200 VAL_SAL NUM_TEL_DDD NOME NUM (PK) 1ª FN FUN 424166 * NUM_TEL 9000 8888 011 0194 JOÃO CRISTINA 0100 0200 VAL_SAL DDD NOME NUM(PK)

132 Normalização de Tabelas
1ª FN – Exemplo 2 ELIMINAR DADO REPETITIVO (Atributo Multivalorado) FUN 90000 80000 * JOSÉ,MARIA,CAIO BEATRIZ JOÃO JOSÉ 0100 0300 VAL_SAL NOME_DEPEND NOME NUM(PK) 1ª FN FUN 90000 JOSÉ MARIA CAIO BEATRIZ JOÃO 0100 0300 VAL_SAL NOME_DEPEND(PK) NOME NUM(PK)

133 Normalização de Tabelas
Dependência Funcional Para entender a 2ª e 3ª formas normais que serão apresentadas a seguir, é necessário compreender o conceito de dependência funcional. Em uma tabela relacional, diz-se que uma coluna C2 depende funcionalmente de uma coluna C1 (ou que a coluna C1 determina a coluna C2) quando, em todas as linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2.

134 Normalização de Tabelas
Dependência Funcional O conceito fica mais fácil de entender se considerarmos um exemplo: CÓDIGO SALÁRIO E1 10 E3 E2 5

135 Normalização de Tabelas
Dependência Funcional A tabela anterior contém, entre outras colunas irrelevantes ao exemplo, as colunas Código e Salário. Diz-se que a coluna Salário depende funcionalmente da coluna Código (ou que a coluna Código determina a coluna Salário) pelo fato de cada valor de Código estar associado sempre ao mesmo valor de Salário. Exemplificando o valor “E1” da coluna Código identifica sempre o mesmo valor de Salário (“10”). Para denotar esta dependência funcional, usa-se uma expressão na forma Código  Salário. A expressão denota que a coluna Salário depende funcionalmente da coluna Código. Diz-se que a coluna Código é o determinante da dependência funcional. De forma geral, o determinante de uma dependência funcional pode ser um conjunto de colunas e não somente uma coluna como na definição acima.

136 Normalização de Tabelas
2ª Forma Normal Uma tabela está na 2ª F.N. se estiver na 1ª F.N. e, adicionalmente, se cada campo não pertencente à chave for dependente da chave completa, e não apenas de uma parte dela.

137 Normalização de Tabelas
2ª FN – Exemplo 1 FUN 90000 * VAL_SAL PESQUISA NUM_DEPTO CAROLINE JOSÉ MARIA CAIO JOÃO 0100 NOME_DIR NOME_DEP NOME NUM 2ª FN FUN PESQUISA * NOME_DEPTO CAROLINE 90000 JOÃO 0100 NOME_DIR VAL_SAL NOME NUM(PK) + DPD JOSÉ MARIA CAIO * 0100 NOME_DEP(PK) NUM_FUN(PK)

138 Normalização de Tabelas
2ª FN – Exemplo 2 RSV 3 2 * QT_DIAR STD LUXO SUITE TIP_APT 100,00 140,00 170,00 VL_DIAR 300,00 420,00 340,00 104 105 82 01/07/89 08/07/89 JOSÉ ELZA VL_TOT NUM_APT DT_ENTR NOMECLI A tabela está na 1ª FN, pois não contém grupos repetidos. A tabela não está na 2ª FN, pois TIP_APT e VL_DIAR são determinados apenas conhecendo-se NUM_APT. 2ª FN

139 Normalização de Tabelas
2ª FN – Exemplo 2 RSV 3 * QT_DIAR 300,00 420,00 104 105 01/07/89 JOSÉ VL_TOT NUM_APT DT_ENTR NOMECLI + APT STD LUXO SUÍTE TIP_APT 100,00 140,00 170,00 * 104 105 82 VL_DIAR NUM(PK)

140 Normalização de Tabelas
3ª Forma Normal Uma tabela está na 3ª F.N. se estiver na 2ª F.N. e, se todos os campos não pertencentes à chave primária (completa) forem independentes entre si.

141 Normalização de Tabelas
3ª FN – Exemplo 1 FUN CAROLINE JORGE FLAVIA PESQUISA VENDAS FINANÇAS 0100 0200 0300 0400 NOME_DIR NOME_DEPTO NUM(PK) NUM  NOME_DEPTO NOME_DEPTO  NOME_DIR NOME_DEPTO  NUM / 3ª FN FUN DEP PESQUISA VENDAS FINANÇAS NOME_DEPTO(FK) 0100 0200 0300 0400 NUM(PK) CAROLINE JORGE FLAVIA NOME_DIR PESQUISA VENDAS FINANÇAS NOME_DEPTO(PK) +

142 Normalização de Tabelas
3ª FN – Exemplo 2 FUN 3,57 4,59 2,05 4,99 6,00 * VAL_SAL_HOR 101 202 303 NUM_PRJ BIBLIOTECA RH PD NOME_PRJ 23/06/90 20/08/91 20/12/92 0100 0200 0300 0400 0500 DT_FIM NUM_TEL NUM (PK) Está na 1ª e 2ª FN, porém, não está na 3ª FN, pois NOM-PRJ e DAT-FIM são determinados apenas conhecendo-se o NUM-PRJ FUN NUM_TEL 3,57 4,59 2,05 4,99 6,00 VAL_SAL_HOR 101 202 303 NUM_PRJ (FK) 0100 0200 030 0040 0050 NUM (PK) PRJ + BIBLIOTECA RH PD NOME 23/06/90 20/08/91 20/12/92 DT_FIM 101 202 303 NUM (PK)

143 Normalização de Tabelas
Regras 1ª Forma Normal A 1ª F.N. exige que não se criem grupos de repetição em uma tabela, isto é, o cruzamento de linha-coluna não deve ter mais de uma informação. Também não se pode ter registros duplicados, ou seja, deve-se eliminar os atributos compostos e multivalorados. 2ª Forma Normal Uma tabela está na 2ª F.N. se estiver na 1ª F.N. e, adicionalmente, se cada campo não pertencente à chave for dependente da chave completa, e não apenas de uma parte dela. 3ª Forma Normal Uma tabela está na 3ª F.N. se estiver na 2ª F.N. e, se todos os campos não pertencentes à chave principal (completa) forem independentes entre si.

144 Normalização de Tabelas

145 Normalização de Tabelas
Implicações


Carregar ppt "Banco de Dados Parte do conteúdo exposto nestas transparências foi retirado dos livros: “Projeto de Banco de Dados”, de Carlos A. Heuser ; “Projeto de."

Apresentações semelhantes


Anúncios Google