Tecnologias e Linguagens para Banco de Dados I Efetivação Lógica de Normalização Prof. Gilberto Braga de Oliveira Expressão do Relacionamento Necessidade de incluir campos nas tabelas para que os relacionamentos sejam efetivados. Campo de identificação única em uma entidade: Chave Primária; Uma entidade que contem a Chave Primária de Outra terá, neste campo, uma Chave Estrangeira. A A ligação é a comparação dos valores da Chave Primária com os da Chave Estrangeira em ambas as tabelas. 2 Expressão do Relacionamento Se temos uma consulta marcada para o dia 13/07/2007 as 15:00 e a Dra. Joana, Pediatra eles só estarão relacionados se, e somente se: O O campo CRM na tabela consulta na ocorrência 13/07/2007, 15:00 for igual ao valor do campo CRM na tabela Médico na ocorrência Joana, Pediatra. CRM da Consulta = CRM do Médico 3 1
Relacionamento Lógico: Cod 07 12 21 35 47 CRM 45-6 34-5 45-6 34-5 0789-0 Consulta DtCons 05/07/07 08/07/07 13/07/07 19/07/07 21/07/07 Quais os Médicos que têm consulta marcada no período da manhã? HrCons 08:00 09:00 15:00 11:00 13:00 CRM 23-4 34-5 45-6 0456-7 0789-0 Quantas consultas marcadas o Dr. Mário tem? E a Dra. Josefa? Médico Joana Mário Joana Josefa Ana Medico Especialidade Cardiologista Clínico Pediatra Cardiologista Ortopedista 4 Evitando confusões Em uma escola cada aluno registrado por número, nome e endereço pode cursar uma e somente uma disciplina; As disciplinas podem ser cursadas por um ou mais alunos. As disciplinas são registradas por código e nome da disciplina. Uma vez matriculado um aluno em uma disciplina registra-se se a data e a hora do curso do aluno. 5 Evitando confusões Interpretando o diagrama: Um aluno cursa uma disciplina enquanto uma disciplina é cursada por muitos alunos. A data e hora do curso são atributos que pertencem ao Curso, mas onde alocá-lo? lo? 1 1 São campos da tabela pois possuem uma única existência para cada ocorrência de aluno. N Cursa 1 N 1 6 2
Modelo Conceitual Numero DataCurso HoraCurso Cod com 1:1 com 1:N 7 1 Identificar chaves candidatas #Numero DataCurso HoraCurso #Cod # com 1:1 com 1:N 8 2 Determinar ou criar chaves primárias *#Numero DataCurso HoraCurso *#Cod # com 1:1 com 1:N 9 3
3 Criar chaves estrangeiras *#Numero Cod DataCurso HoraCurso *#Cod # com 1:1 com 1:N 10 Exemplo x 1:N DISCIPLINA Cod 07 Lógica 09 Matemática 12 Rec. Humanos Num 0 007 2 Marcelo Joaquina Roberto Ana ALUNO CodDisc Rua Zero, 07 Rua Hum, <NULO> Rua Dois, 12 Rua Seis, 07 07 DtCurso //07 <NULO> /04/07 //07 HrCurso 13: <NULO> 19:00 11 13: Valor Nulo Nulo não é zero Exemplo: Cod, DataCurso e HoraCurso Nulo é desconhecido Neste caso: nulo = aluno ainda não escolheu uma disciplina. 12 4
Mudando as regras de negócio Em uma escola cada aluno registrado por número, nome e endereço pode cursar UMA OU MAIS disciplinas; As disciplinas podem ser cursadas por um ou mais alunos. As disciplinas são registradas por código e nome da disciplina. Uma vez matriculado um aluno em uma disciplina registra-se se a data e a hora do curso do aluno 13 Evitando confusões Interpretando o diagrama: Um aluno cursa uma ou mais disciplinas enquanto uma disciplina é cursada por um ou mais alunos. A A data e hora do curso são informações que pertencem ao Curso, mas onde alocar esses atributos? 1 N N N Cursa N 1 São campos do relacionamento Curso pois possuiria várias existências nas tabelas aluno e disciplina. (Redundância) 14 Modelo Conceitual Numero Cod com 1:N com 1:N Curso DtCurso HrCurso 15 5
1 Identificar chaves candidatas #Numero #Cod # com 1:N com 1:N Curso DtCurso HrCurso 16 2 Determinar ou criar chaves primárias *#Numero *#Cod # com 1:N com 1:N Curso *CodCurso DtCurso HrCurso 17 3 Criar chaves estrangeiras *#Numero *#Cod # com 1:N com 1:N Curso *CodCurso Numero Cod DtCurso HrCurso 18 6
Utilização de Chave secundária 4. Otimizar o modelo identificando chaves secundárias Observar a composição das chaves estrangeiras do relacionamento N:N A combinação dos campos pode se repetir? Sim: O modelo não pode ser otimizado Não: Elimine a chave primária do relacionamento, (se ela foi criada artificialmente) e torne as chaves estrangeiras chaves primárias marcando ambas com asterísco * 19 4 Otimizar o modelo *#Numero *#Cod # com 1:N com 1:N Curso *CodCurso *Numero *Cod DtCurso HrCurso 20 Exemplo Relacionamento x : N:N CodDisc 07 12 CURSO NumAl DtCurso HrCurso 0 //07 13: 0 /04/07 19:00 07 //07 13: 12 //07 13: Num 0 2 ALUNO Marcelo Rua Zero, Roberto Rua Dois, Ana Rua Seis, 07 DISCIPLINA Cod 07 Lógica 09 Matemática 12 Rec. Humanos 21 7
Tecnologias e Linguagens para Banco de Dados I Normalização Prof. Gilberto Braga de Oliveira Definição Objetivo: Melhorar a organização, a recuperação, a alteração e a atualização dos dados armazenados. Três formas normais são aplicadas na maioria dos modelos de banco de dados: 1FN: (Toda tabela deve conter ao menos uma chave primária) Cada dado um campo, cada campo um dado Não deve haver campos multivalorados nas tabelas 2FN: (1FN deve estar OK) Campos devem depender da chave primária completa (Dependência Funcional ) 3FN: (1FN e 2FN devem estar OK) Campos com dependência funcional transitiva são colocados em outra tabela ou eliminados (no caso de campos calculados). 23 Situação problema Aplicando a 1FN: Cada dado um campo: Coloque um terceiro telefone para algum funcionário O O dado telefone está distribuído nos campos tel1 e tel2 não escaláveis. Cada campo um dado: Altere os prefixos 1234 para 4321 O O prefixo e o sufixo dos telefones podem ser armazenados em campos diferentes, evitando anomalias de atualização. Mat 0 9 1 9 045 João Marisa Pedro Joana Mário Tel1 1234-5678 1234-5678 3645-6789 6789 Pedrina 3645-6789 6789 5678-92 5678-92 Tel2 78-1234 89-2345 7788-99 8899-02 7997-88 8998-9989 9989 Depto Projeto Intranet Intranet DtAl 17/05/08 21/06/08 22/06/08 18/05/08 PrazoAl 24 8
*CodTel 04 05 Resolução do problema Aplicando a 1FN: *Mat 0 9 1 9 045 Prefixo 1234 3645 5678 78 89 João Marisa Pedro Joana Mário Sufixo 5678 6789 92 1234 2345 Depto Pedrina 18/05/08 Projeto Intranet Intranet *CodTel 05 DtAl 17/05/08 21/06/08 22/06/08 PrazoAl *Mat 0 9 1 0 25 Anomalias de atualização Aplicando a 1FN: Anomalias de atualização de Projeto e Departamento; Altere para Marketing e veja quantas alterações são necessárias Observe que o usuário precisa preencher o Departamento toda vez que um funcionário é cadastrado. *Mat 0 9 1 9 045 João Marisa Pedro Pedrina Joana Mário Depto Producão Projeto Intranet Intranet DtAl 17/05/08 21/06/08 22/06/08 18/05/08 PrazoAl 26 *CodDep Resolução do problema Aplicando a 1FN: Departamento Recursos Humanos *CodProjeto Projeto Intranet Integração *Mat 0 9 1 9 045 João Marisa Pedro Pedrina Joana Mário CodDep DtAl 17/05/08 21/06/08 22/06/08 18/05/08 PrazoAl *CodProjeto *Mat 0 9 1 0 27 9
Resolução do problema Aplicando a 1FN: Departamento 1 1 1 lota 1 N N N 1 1 N Telefone N tem N Funcionario N N aloca Projeto N 1 1 1 1 N 1 é 1 1 1 Vendedor Crie a entidade Telefone para conter o prefixo e o sufixo de cada telefone Relacione a entidade Telefone a entidade Funcionário Crie a entidade Departamento para conter o nome do Departamento; Relacione a entidade Departamento com a entidade Funcionário Crie e relacione a entidade Projeto, que armazena o nome de cada projeto Relacione a entidade Funcionário a entidade Projeto 28 Situação problema Aplicando a 2FN: Todo atributo não chave deve depender totalmente da chave primária: Para existir um nome de um funcionário precisa existir apenas um funcionário cadastrado? Sim: Depende totalmente da chave primária Não: Depende parcialmente da chave primária Para existir uma Data a de Alocação de um funcionário precisa apenas existir um funcionário cadastrado? *Mat CodDep DtAl PrazoAl 0 9 1 9 045 João Marisa Pedro Pedrina Joana Mário 17/05/08 21/06/08 22/06/08 18/05/08 29 *Mat 0 9 1 9 045 Resolução do problema Aplicando a 2FN: João Marisa Pedro Pedrina Joana Mário CodDep *CodProjeto *Mat 0 9 1 0 DtAl 17/05/08 21/06/08 22/06/08 18/05/08 A A Data de Alocação depende de um funcionário a ser alocado, mas depende também de um Projeto onde o funcionário possa ser alocado. A A Data da Alocação depende da chave primária do funcionário e da chave primária do projeto PrazoAl 10
Situação problema Aplicando a 3FN: não chave que dependam funcionalmente de outros atributos não chave são eliminados: Comissão depende do Salário Fixo ou do Salário? Não. Apenas do código do vendedor Salário Fixo depende da Comissão ou do Salário? Não. Apenas do código do vendedor Salário depende da Comissão ou do Salário? Mat Comissao SalFixo Sal 9 20 800 9 10 0 6 045 15 700 805 31 Mat Resolução do problema Aplicando a 3FN: Comissao SalFixo Sal 9 20 800 9 10 0 6 045 15 700 805 O O Salário do vendedor é o produto do cálculo do Salário Fixo vezes a Comissão A A coluna Salário deve ser eliminada pois os dados contidos nela são desnecessários. 32 Banco de Dados Exercício Modelo de Negócio: Comércio Prof. Gilberto Braga de Oliveira 11
Exemplo: Comércio Os produtos são registrados pela descrição, valor unitário e quantidade de cada produto, pelo setor onde o produto está contido e a data de fabricação dos produtos perecíveis; Os cliente são cadastrados pelo nome, endereço1, endereço2 e CPF de cada cliente, pela quantidade e total da venda de cada produto a cada cliente Cada cliente pode comprar um ou mais produtos, enquanto cada produto pode ser vendido para um ou mais clientes. 34 Modelo Conceitual Cliente Descricao Quantidade ValorUnitario Setor DtFabricacao 1 2 CPF Venda Cliente N Venda N 35 Cliente 1 Encontrar chaves candidatas #Descricao Quantidade ValorUnitario Setor DtFabricacao 1 2 #CPF Venda 36 12
Cliente 2 Criar ou promover chaves primárias *Cod #Descricao Quantidade ValorUnitario Setor DtFabricacao *CodCliente 1 2 #CPF Venda *CodVenda 37 Cliente *Cod #Descricao Quantidade ValorUnitario Setor DtFabricacao *CodCliente 1 2 #CPF 3 Criar chaves estrangeiras Venda *CodVenda Cod CodCliente 38 Anomalias de Atualização: De Inclusão Cada cliente novo deve se relacionar a uma quantidade de produtos vendidos Cada produto,, mesmo que não seja perecível, exige o preenchimento do campo Data de Fabricação A A cada produto cadastrado em um setor já existente obriga o recadastramento do setor De Alteração Os clientes s não podem ter mais de três endereços s e não podem ser pesquisados por qualquer dado do endereço. A A atualização do endereço de um cliente ou do nome de um setor será muito difícil De Exclusão Cada venda excluída exclui também o registro do cliente e vice-versa versa 39 13
1FN Todas as entidades e atributos com relacionamentos devem ter ao menos uma chave primária Cada dado um campo, cada campo um dado Não devem haver atributos multivalorados Setor Perecivel *Cod CodSetor #Descricao Quantidade ValorUnitario *CodSetor #Setor *Cod DtFabricacao com Perecivel 1:1 com Setor 1:1 com 1:1 40 1FN...continuação Cliente Atributo *CodCliente #CPF *Cod Tipo Logradouro Bairro Cidade CEP Relacionamento com 1:N Venda Cliente *CodVenda Cod CodCliente *CodCliente *Cod 41 2FN Todas as tabelas devem estar na primeira forma normal Não devem haver atributos que dependam parcialmente da chave primária (depedência funcional parcial) Setor Perecivel *CodSetor #Setor *Cod CodSetor #Descricao Quantidade ValorUnitario *Cod DtFabricacao com Perecivel 1:1 com Setor 1:1 com 1:1 42 14
2FN...continuação Cliente Atributo *CodCliente CPF *Cod Tipo Logradouro Bairro Cidade CEP Relacionamento com 1:N Venda Cliente *CodVenda Cod CodCliente *CodCliente *Cod 43 3FN Todas as tabelas devem estar na segunda forma normal Não devem haver atributos que dependam de campos não chave (depedência funcional transitiva) Setor Perecivel *CodSetor #Setor *Cod CodSetor #Descricao Quantidade ValorUnitario *Cod DtFabricacao com Perecivel 1:1 com Setor 1:1 com 1:1 44 3FN...continuação Cliente Atributo *CodCliente #CPF *Cod Tipo Logradouro Bairro Cidade CEP Relacionamento com 1:N Venda Cliente *CodVenda Cod CodCliente *CodCliente *Cod 45 15
Modelo - Relacionamento 1 N N tem N N 1 1 N Cliente N Vende N N 1 Setor 1 1 1 lota N N 1 1 1 e 1 1 1 1 Perecivel 46 16