Baixe o app para aproveitar ainda mais
Prévia do material em texto
Banco de Dados Profª. Rossana Junqueira 1 Disciplina: Banco de Dados Profa. Rossana de Paula Junqueira Almeida Ciência da Computação - 4° Período Banco de Dados Profª. Rossana Junqueira 2 Capítulo 1: Conceitos Básicos Banco de Dados Profª. Rossana Junqueira 3 Como Informática é adotada em organizações z Informática é implementada gradativamente; z Exemplo: uma empresa z Implementa gradativamente sistemas para: z Vendas z Produção z Compras z Onde ficam os dados dos produtos? z Usados em várias funções z Pode ocorrer que, para casa uma das funções, seja criado um arquivo separado de produtos. Banco de Dados Profª. Rossana Junqueira 4 Sistemas isolados – Dados não compartilhados z Problema: redundância de dados z Tipos de redundância da dados: z Redundância controlada de dados z Quando o software tem conhecimento da múltipla representação da informação e garante a sincronia entre as diversas representações. Banco de Dados Profª. Rossana Junqueira 5 Sistemas isolados – Dados não compartilhados z Redundância não controlada de dados z O usuário gerencia a redundância z Dever ser evitado z Problemas: Entrada repetida da mesma informação Inconsistência de dados z Como evitar: Compartilhamento dos dados Cada informação é armazenada uma única vez Usar o conceito de Banco de Dados Banco de Dados Profª. Rossana Junqueira 6 Banco de Dados z Conjunto de arquivos integrados que atendem a um conjunto de sistemas z O compartilhamento de dados tem reflexos na estrutura do software: z A estrutura interna dos arquivos para a ser mais complexa z Devem atender às necessidades dos diferentes sistemas z Solução: z Usar sistema de gerência de banco de dados Banco de Dados Profª. Rossana Junqueira 7 Sistema de gerência de banco de dados z Início da programação de aplicações z Programa continha todas operações z Interface de usuário z Transformação de dados e cálculos z Operações de armazenamento de dados z Tarefas de comunicação com outros sistemas e programas z Evolução da programação: z Foram identificadas funcionalidades comuns a muitos programas z Exibição dos dados na interface Gerenciadores de interface do usuário z Comunicação com processos remotos Gerenciadores de comunicação z Manutenção de grandes repositórios compartilhados de dados Sistemas de Gerência de Banco de Dados (SGBD) Banco de Dados Profª. Rossana Junqueira 8 Sistema de gerência de banco de dados z Software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados z Facilita o desenvolvimento de aplicações de BD z Manutenção de programas torna-se mais simples z Produtividade de programadores aumenta Banco de Dados Profª. Rossana Junqueira 9 z Sistema de Banco de Dados: z Apenas um sistema computadorizado de manutenção de registros ou z Sistema computadorizado cuja finalidade geral é armazenar informações e permitir que os usuários busquem e atualizem essas informações quando as solicitar. z Tal sistema envolve quatro componentes principais: Dados, Hardware, Software e Usuários. Sistema de gerência de banco de dados Banco de Dados Profª. Rossana Junqueira 10 z Sistema de Banco de Dados: z Dados: Sistema Monousuário: sistema em que no máximo um usuário pode acessar o banco de dados em determinado momento; Sistema Multiusuário: é aquele em que muitos usuários podem acessar o banco de dados ao mesmo tempo. Dados Integrados: BD pode ser considerado como uma unificação de vários arquivos que, de outro modo, seriam distintos, com a eliminação de qualquer redundância parcial ou total entre esses arquivos. Dados Compartilhados: BD pode ser compartilhado entre diferentes usuários, no sentido de que diferentes usuários podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo. Sistema de gerência de banco de dados Banco de Dados Profª. Rossana Junqueira 11 z Sistema de Banco de Dados: z Hardware: Volumes de armazenamento, processadores de hardware e memória. z Software: SGBD: Trata todas as requisições de acesso ao BD (acrescentar novos arquivos, inserir , buscar, excluir, alterar dados em arquivos existentes e remover arquivos existentes do banco de dados); SGBD ≠ BD z Usuários: Programadores de aplicações: responsáveis pela escrita de programas de aplicações de banco de dados em alguma linguagem de programação; Usuários finais: que acessam o banco de dados através de uma aplicação; Administrador de banco de dados (DBA). Sistema de gerência de banco de dados Banco de Dados Profª. Rossana Junqueira 12 Modelo de Dados z Modelo de (banco) de dados z Descrição dos tipos de informações que estão armazenadas em um banco de dados z Exemplo da indústria: z Modelo de dados informa: São armazenadas informações sobre produtos Para cada produto, são armazenados seu código, preço e descrição z Modelo de dados não informa: Quais os produtos que estão armazenados no banco de dados Banco de Dados Profª. Rossana Junqueira 13 Esquema de banco de dados z Para construir um modelo de dados usa-se: z Linguagem de modelagem de dados: z Textual z Gráfica z Um modelo de dados pode ser apresentado de várias formas (texto, figura, ...) z Cada apresentação do modelo recebe a denominação esquema de banco de dados Níveis de Abstração: Banco de Dados 14 Modelo Conceitual z Independente do tipo de SGBD z Registra: z Que dados podem aparecer no banco de dados z Não registra: z Como estes dados estão armazenados a nível de SGBD z Técnica mais difundida na modelagem conceitual z Abordagem entidade-relacionamento (ER) z Modelo conceitual é representado através de diagrama entidade-relacionamento (DER) Banco de Dados Modelo Lógico z Nível de abstração visto pelo usuário do SGBD z Depende do tipo particular de SGBD que está sendo usado z Em um SGBD relacional, os dados estão organizados na forma de tabelas Banco de Dados Profª. Rossana Junqueira 16 Modelo Físico z Contém detalhes de armazenamento interno de informações z Detalhes que: z Não têm influencia sobre a programação de aplicações no SGBD z Influenciam na performance das aplicações z Usados por profissionais que fazem sintonia de performance em banco de dados, procurando otimizar o desempenho. Banco de Dados Profª. Rossana Junqueira 17 Modelo conceitual como modelo de organização z Constatação z Um arquivo em computador contém informações sobre um conjunto de objetos ou entidades da organização que é atendida pelo sistema em computador z Exemplo da indústria z Um arquivo para armazenar dados de produtos, outro para armazenar dados de vendas, outro para dados de ordem de serviço e assim por diante z Idéia fundamental do projeto de banco de dados: z Através da identificação das entidades que terão informações representadas no banco de dados, é possível identificar os arquivos que comporão o banco de dados Banco de Dados Profª. Rossana Junqueira 18 Modelo conceitual como modelo de organização z Modelo conceitual tem dupla interpretação: z Modelo da organização z Define as entidades da organização que tem informações armazenadas no banco de dados z Exemplificando: O diagrama nos informa que na organização há produtos e tipos de produtos, que associado a cada tipo de produto há um código do tipo e uma descrição e assim por diante. z Modelo do banco de dados z Define que arquivos (tabelas) farão parte do banco de dados z Exemplificando: O diagrama nos informa que o banco de dados contém um arquivo com dados de produtos e tipos de produtos, que para cada tipo de produto são armazenados seu código e sua descrição e assim por diante. Banco de Dados Profª. Rossana Junqueira 19 Projeto de banco de dados z 3 fases: z Modelagem conceitual z Construído um modelo conceitual, na forma de um diagrama entidade-relacionamento. z Modelo lógico z Objetiva transformar o modelo conceitual obtido na primeira faze em um modelo lógico. z Projeto físico z O modelo é enriquecidocom detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua funcionalidade Banco de Dados Profª. Rossana Junqueira 20 Capítulo 2: Abordagem entidade - relacionamento Banco de Dados Profª. Rossana Junqueira 21 Abordagem entidade- relacionamento z Técnica para construir modelos conceituais de bases de dados z Técnica de modelagem de dados mais difundida e utilizada z Criada em 1976 por Peter Chen z Padrão de fato para modelagem conceitual z Não é única: z NIAM/ORM (técnica européia da década de 70) z UML (Técnica para modelos Orientados a Objetos) z Técnicas de modelagem orientada a objetos (UML) baseiam-se nos conceitos da abordagem ER z Modelo de dados é representado através de um z modelo entidade-relacionamento (modelo ER) z Modelo ER é representado graficamente z diagrama entidade-relacionamento (DER) Banco de Dados Profª. Rossana Junqueira 22 Entidade z Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dados z Exemplos: z Sistema de informações industrial: z Produtos z Tipos de produtos z Vendas z Compras z Sistemas de contas correntes: z Clientes z Conta correntes z Cheques z Agências Banco de Dados Profª. Rossana Junqueira 23 Entidade z Representada através de um retângulo z Retângulo contem o nome da entidade z Entidade = conjunto de objetos z Para se referir a um objeto em particular fala-se em instância ou ocorrência da entidade z Entidade isoladamente não informa nada, é necessário saber quais as informações que devem ser mantidas para cada objeto, ou seja, atribuir propriedades às entidades z Propriedades são especificadas na forma de: relacionamentos, atributos e generalizações/especializações Pessoa Departamento Banco de Dados Profª. Rossana Junqueira 24 Relacionamento z Conjunto de associações entre entidades sobre as quais deseja-se manter informações na base de dados z Relacionamento é um conjunto de associações entre instâncias de entidades z Uma instância (ocorrência) é uma associação específica entre determinadas instâncias de entidade z Exemplo (relacionamento LOTAÇÃO) z ocorrência = par específico formado por uma ocorrência de PESSOA e uma ocorrência de DEPARTAMENTO 25 Relacionamento z Auto-relacionamento: z Relacionamento de casamento z Uma ocorrência de pessoa exerce o papel de marido z Uma ocorrência de pessoa exerce o papel de esposa z Relacionamento entre entidades diferentes não é necessário indicar os papéis das entidades Banco de Dados Profª. Rossana Junqueira 26 Cardinalidade de relacionamentos z Propriedade importante de um relacionamento z Quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência de entidade através do relacionamento z Chamada de cardinalidade de uma entidade em um relacionamento z Cardinalidade máxima: 27 Cardinalidade de relacionamentos z Relacionamento de 1:1 z Relacionamento de 1:n z Relacionamento de n:n Banco de Dados Profª. Rossana Junqueira 28 Cardinalidade de relacionamentos z Cardinalidade mínima: z Número mínimo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamento z Para fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas z cardinalidade mínima 0 z cardinalidade mínima 1 z Denominação alternativa: z cardinalidade mínima 1 = “associação obrigatória” z cardinalidade mínima 0 = “associação opcional” Banco de Dados Profª. Rossana Junqueira 29 Exemplos de entidades e relacionamentos Banco de Dados Profª. Rossana Junqueira 30 Atributo z Dado ou informação que é associado a cada ocorrência de uma entidade ou de um relacionamento Banco de Dados Profª. Rossana Junqueira 31 Atributo z Cada entidade deve possuir um identificador z Identificador = conjunto propriedades de uma entidade (atributos e relacionamentos) cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade Profª. Rossana Junqueira 32 Generalização e Especialização z Este conceito permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. z Associada ao conceito de generalização/ Especialização está a idéia de herança de propriedades. z Herdar propriedades significa que cada ocorrência da entidade especializada possui: z Além de suas próprias propriedades z Também as propriedades da ocorrência da entidade genérica correspondente Banco de Dados Generalização e Especialização z Especialização total ou parcial Banco de Dados 34 Entidade associativa z É necessário saber que medicamentos foram prescritos em cada consulta. z Uma entidade associativa nada mais é que a redefinição de um relacionamento, que passa a ser tratado como se fosse também uma entidade. Banco de Dados Profª. Rossana Junqueira 35 Entidade associativa Banco de Dados Profª. Rossana Junqueira 36 Capítulo 3: Construindo modelos entidade- relacionamento Banco de Dados Profª. Rossana Junqueira 37 Propriedades de modelos ER z É um modelo formal, preciso, não ambíguo. z Isto significa que diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo. z DER pode ser usado como entrada a uma ferramenta CASE. z Fundamental: todos os envolvidos devem estar treinados na sua perfeita compreensão. z Risco: sub-utilização z Modelos ER têm poder de expressão limitado z Modelo ER apresenta apenas algumas propriedades de um banco de dados z Foi concebido para o projeto da estrutura de um BD relacional z Pouco poderoso para expressar restrições de integridade (regras de negócio) Banco de Dados Profª. Rossana Junqueira 38 Equivalência entre modelos z Dois modelos diferentes podem se equivalentes z Modelos equivalentes: z expressam o mesmo z modelam a mesma realidade z Para fins de projeto de banco de dados, dois modelos ER são equivalentes, quando ambos geram o mesmo esquema de banco de dados z Para analisar se dois modelos são equivalentes, é necessário considerar um conjunto de regras de tradução de modelos ER para modelos lógicos de banco de dados Banco de Dados Profª. Rossana Junqueira 39 Exemplo de equivalência entre modelos z CONSULTA como relacionamento n:n z CONSULTA como entidade Banco de Dados Profª. Rossana Junqueira 40 Exemplo de equivalência entre modelos z A determinação de que construção da abordagem ER (entidade, relacionamento, atributo,...) será usada para modelar um objeto de uma realidade z não pode ser feita através da observação do objeto isoladamente z é necessário conhecer o contexto (modelo dentro do qual o objeto aparece) z Decisão por uma construção para a modelagem de um objeto está sujeita a alteração durante a modelagem z Não despender um tempo excessivo em longas discussões sobre como modelar um objeto z O próprio desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e aperfeiçoando o modelo z Existem critérios alguns critérios para escolha de construções de modelagem Banco de Dados Profª. Rossana Junqueira 41 Atributo versus entidade relacionada z Alguns critérios para esta decisão são: z Objeto está vinculado a outros objetos deve ser modelado como entidade z Caso contrário pode ser modelado como atributo z Conjunto de valores de um determinado objeto é fixo, pode ser modelado como atributo z Existem transações no sistema que alteram o conjunto de valores do objeto, não deve ser modelado como atributo Banco de Dados Profª. Rossana Junqueira 42 Atributo versus generalização/especialização z Questão: z Modelar um determinado objeto (por exemplo, a categoria funcional de cada empregado de uma empresa) como atributo ou como especialização? z Especialização deve ser usada quando as classes especializadas de entidades possuem propriedades particulares 43 Verificação do modelo z Uma vez construído, um modelo ER dever ser validado e verificado. z A verificação é o controlede qualidade que procura garantir que o modelo usado para a construção do banco de dados gerará um bom produto. z Um modelo para ser considerado bom, deve preencher uma série de requisitos, como ser completo, ser correto e não conter redundância. z Modelo CORRETO z Dois tipos de erros: sintáticos e semânticos z Sintáticos ocorrem quando o modelo não respeita as regras de construção de um modelo ER z Semânticos ocorrem quando o modelo, apesar de estar sintaticamente correto, reflete a realidade de forma inconsistente. Estabelecer associações incorretas Usar uma entidade do modelo como atributo de outra entidade Banco de Dados Profª. Rossana Junqueira 44 Verificação do modelo z Modelo COMPLETO z Deve fixar todas as propriedades desejáveis do banco de dados. z Somente pode ser verificado por alguém que conhece profundamente o sistema a ser implementado. z Forma de verificar: z Todos os dados que devem ser obtidos do banco de dados estão presentes? z Todas as transações de modificação do banco de dados podem ser executadas sobre o modelo? z Este requisito é aparentemente conflitante com a falta de poder de expressão de modelos ER. Banco de Dados 45 Verificação do modelo z Modelo deve ser livre de REDUNDÂNCIAS z Modelo deve ser mínimo, isto é não deve conter conceitos redundantes z Tipos de redundância: z Relacionamentos redundantes Æ são relacionamentos que são resultados da combinação de outros relacionamentos entre as mesmas entidades. Um relacionamento é redundante, quando é possível eliminá-lo do modelo ER, sem que haja perda de informações no banco de dados. Banco de Dados Profª. Rossana Junqueira 46 Verificação do modelo z Atributos redundantes Æ são atributos deriváveis a partir da execução de procedimentos de busca de dados e/ou cálculos sobre o banco de dados. Banco de Dados Profª. Rossana Junqueira 47 Verificação do modelo z Modelo deve refletir o aspecto temporal z Dados temporais z Dados que mudam ao longo do tempo e para as quais o BD mantém histórico z Tipos de dados temporais: z Atributos cujos valores modificam ao longo do tempo z Relacionamentos que modificam ao longo do tempo 48 Verificação do modelo z Consultas a dados referentes ao passado z Muitas vezes, informações referentes ao passado são eliminadas da base de dados (arquivamento) z Podem ser necessárias no futuro: Por motivos legais Para realização de auditorias Para tomada de decisões z Dados referentes ao passado – planejar arquivamento z Solução que poderia ser considerada Reincluir as informações no banco de dados, quando elas forem necessárias Problema: restrições de integridade referencial z Planejar informações estatísticas Quando informações antigas são necessárias apenas para tomada de decisões Pode ser conveniente manter no banco de dados informações compiladas e eliminar as informações usadas na compilação Banco de Dados Profª. Rossana Junqueira 49 Verificação do modelo z Entidade isolada e entidade sem atributos z Caso raro, mas não incorreto z Entidade que muitas vezes aparece isolada z Caso típico: z Entidade que modela a organização na qual o sistema implementado pelo BD está embutida z Exemplo: BD de uma universidade z A entidade UNIVERSIDADE pode ser necessária, caso se deseje manter no BD alguns atributos da universidade z O modelo não deveria conter o relacionamento desta entidade com outras, como ALUNO ou CURSO BD modela uma única universidade Não é necessário informar no BD em que universidade o aluno está inscrito ou a qual universidade o curso pertence Banco de Dados 50 Estabelecimento de padrões z Modelos de dados são usados para comunicação com: z Pessoas da organização (usuários, analistas, programadores, ...) z Programas (ferramentas CASE, geradores de código, ...) z É necessário estabelecer padrões de confecção de modelos z Na prática e na literatura aparecem muitas versões, que distinguem-se umas das outras não só na representação gráfica, isto é em sua sintaxe, mas também na semântica z Variantes de abordagem ER z Peter Chen (acadêmica) z Engenharia de informações z UML z Merise (notação Européia) Banco de Dados Profª. Rossana Junqueira 51 Estratégias de modelagem z Uma seqüência de passos (uma “receita de bolo”) de transformação de modelos desde o modelo inicial de modelagem até o final z Diferentes estratégias: z Bottom-up Æ Parti de conceitos mais detalhados e abstrai gradativamente. Inicia com a identificação de atributos z Top-down Æ Parti de conceitos mais abstratos e vai gradativamente refinando estes conceitos em conceitos mais detalhados. Inicia com a identificação de entidades genéricas z Inside-out Æ De dentro pra fora. Parti de conceitos considerados importantes e vai gradativamente adicionando conceitos periféricos a eles relacionados Banco de Dados Profª. Rossana Junqueira 52 Definição da estratégia de modelagem z Na prática z Nenhuma das estratégias propostas na literatura é universalmente aceita z Normal z Combinação das diversas estratégias de modelagem z Compreensível z Processo de modelagem é um processo de aprendizagem Banco de Dados Profª. Rossana Junqueira 53 Capítulo 4: Abordagem relacional Banco de Dados Profª. Rossana Junqueira 54 Abordagem Relacional z Abordagem de modelagem de dados usada nos sistemas de gerência de banco de dados do tipo relacional; z Composição de um banco de dados relacional: z Tabelas z Compostas de: linhas, colunas e chaves primárias z Relacionadas através de chaves estrangeiras z Terminologias: Profissional Acadêmica Tabela Relação Linha Tupla Coluna Atributo Valor de campo Valor de atributo Banco de Dados Profª. Rossana Junqueira 55 Abordagem Relacional Banco de Dados Profª. Rossana Junqueira 56 Abordagem Relacional z Características das tabelas: z As linhas de ma tabela não têm ordenação z Valores de campo: z Atômicos Æ o campo não pode ser composto de outros z Monovalorados Æ o campo possui um único valor z Acesso por quaisquer critérios envolvendo os campos de uma ou mais linhas z Programadores escrevem consultas sem considerar a existência de caminhos de acesso z Caminho de acesso: estrutura auxiliar (índice, cadeia de ponteiros,...) acelera a recuperação de registros por determinados critérios evita a leitura exaustiva de todos registros de um arquivo Banco de Dados 57 Abordagem Relacional z Chave Æ conceito usado para identificar e estabelecer relações entre linhas de tabelas de um banco de dados relacional. z Três tipos: z Chave Primária z Chave Alternativa z Chave Estrangeira z Chave Primária Æ é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela. Banco de Dados Profª. Rossana Junqueira 58 Abordagem Relacional z Chave Estrangeira Æ Uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela z Mecanismo que permite a implementação de relacionamentos em um banco de dados relacional Abordagem Relacional z Restrições que devem ser garantidas ao executar diversas operações de alteração do banco de dados: z Quando da inclusão de uma linha na tabela que contém a chave estrangeira: o valor da chave estrangeira deve aparecer na coluna da chave primária referenciada Ex: Um novo empregado deve atuar em um departamento já existente no banco de dados. z Quando da alteração do valor da chave estrangeira: o novo valor de uma chave estrangeira deve aparecer na coluna da chave primária referenciada z Quando da exclusão de uma linha da tabela que contém a chave primária referenciada pela chave estrangeira: na coluna chave estrangeira não deve aparecer o valor da chave primária que está sendo excluída Ex: Um departamento não pode ser excluído, caso nele ainda existirem empregados z Quando da alteração do valor da chave primária referenciada pela chave estrangeira: na coluna chave estrangeira, não apareça o antigo valor da chaveprimária que está sendo alterada Ex: Caso um departamento possua empregados, seu código não pode ser modificado Banco de Dados Profª. Rossana Junqueira 60 Abordagem Relacional z A palavra “estrangeira” pode levar a crer que a chave estrangeira sempre referencia uma chave primária de outra tabela. z Esta restrição não existe. z Um chave primária pode referenciar a chave primária da própria tabela. 61 Abordagem Relacional z Chave Alternativa Æ Mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais z Uma das colunas (ou combinação de colunas) é escolhida como chave primária z As demais colunas ou combinações são denominadas chaves alternativas Banco de Dados Profª. Rossana Junqueira 62 Abordagem Relacional z Domínio de coluna Æ conjunto de valores que podem aparecer em uma coluna (atributo) z Valor vazio: z Um valor de campo pode assumir o valor especial vazio (“null” em inglês) z Colunas nas quais não são admitidos valores vazios são chamadas de colunas obrigatórias z Colunas nas quais podem aparecer campos vazios são chamadas de colunas opcionais z Abordagem relacional: z todas colunas que compõem a chave primária devem ser obrigatórias z demais chaves podem conter colunas opcionais Banco de Dados Profª. Rossana Junqueira 63 Abordagem Relacional z Restrições de Integridade: z Objetivo primordial de um SGBD é garantir a integridade de dados z Dados refletem corretamente a realidade representada pelo bando de dados e que são consistentes entre si z Para garantir a integridade de um banco de dados, SGBD oferecem o mecanismo de restrições de integridade z Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD z São classificadas nas seguintes categorias: z Integridade de domínio Æ o valor de um campo deve obedecer a definição de valores admitidos para a coluna z Integridade de vazio Æ é especificado se os campos de uma coluna podem ou não ser vazios. Banco de Dados Profª. Rossana Junqueira 64 Abordagem Relacional z Integridade de chave Æ define que os valores da chave primária e alternativa devem ser únicos z Integridade referencial Æ define que os valores que aparecem em uma chave estrangeira devem aparecer na chave primária da tabela referenciada z Restrições acima são garantidas automaticamente por um SGBD relacional z Não é exigido que o programador escreva procedimentos para garanti-las explicitamente z Restrições de integridade semânticas: z Restrições de integridade que não se encaixam nas categorias básicas z Exemplos de restrições semânticas: z Um empregado do departamento denominado “Finanças” não pode ter a categoria funcional “Engenheiro”. z Um empregado não pode ter um salário maior que seu superior imediato. Banco de Dados Profª. Rossana Junqueira 65 Abordagem Relacional z Modelo de banco de dados relacional z A especificação de um banco de dados relacional, ou seja um modelo de banco de dados relacional (chamada de esquema do banco de dados) deve conter no mínimo a definição do seguinte: z Tabelas que formam o banco de dados z Colunas que as tabelas possuem z Restrições de integridade Banco de Dados Profª. Rossana Junqueira 66 Abordagem Relacional z Esquema textual de BD relacional Banco de Dados Profª. Rossana Junqueira 67 Abordagem Relacional z Esquema diagramático de BD relacional Banco de Dados Profª. Rossana Junqueira 68 Abordagem Relacional z Consulta sobre o banco de dados: z Na instrução SQL, o programador não faz referência a nenhum tipo de caminho de acesso. Quem decide que caminhos de acesso serão eventualmente usados quando da execução da instrução é o SGBD. Banco de Dados Profª. Rossana Junqueira 69 Capítulo 5: Transformação entre modelos Banco de Dados 70 Transformação entre modelos z Dois processos de transformação de modelos: z Visão geral do projeto lógico: Banco de Dados Profª. Rossana Junqueira 71 Transformação entre modelos z Transformação ER para relacional: z Objetivos básicos: z Boa performance; z Simplificar o desenvolvimento; z Ocupar pouco espaço em disco; z Evitar junções : Operação para buscar dados de diversas linhas associadas pela igualdade de campos Exemplo: buscar os dados de um empregado e os dados de seu departamento (duas tabelas diferentes) SGBD relacional normalmente armazena os dados de uma linha contiguamente em disco Junção envolve diversos acessos a disco Preferível: ter os dados necessários a uma consulta em uma única linha Banco de Dados Profª. Rossana Junqueira 72 Transformação entre modelos z Chave e índice: Implementação eficiente do controle de chaves: SGBD usa um índice – Índices tendem a ocupar espaço considerável em disco Inserção e remoção de entradas em um índice – Podem exigir diversos acesso a disco Usar implementações com menos chaves Exemplo: Cliente (CodCliente,Nome,NomeContato,Endereço,Telefone) ou Cliente (CodCliente,Nome,NomeContato) ClienteEnder (CodCliente,Endereço,Telefone) CodCliente referencia Cliente Banco de Dados Profª. Rossana Junqueira 73 Transformação entre modelos z Campos Opcionais: Campo opcional = campo que podem assumir o valor VAZIO (NULL em SQL). SGBD relacional não desperdiça espaço pelo fato de campos de uma linha estarem vazios Campo opcional não tem influência na performance Controle de campo opcional pode complicar programação – Verificar quais campos podem estar vazios, quando isto depende do tipo de linha z Passos da transformação ER para relacional: z Tradução inicial de entidades e respectivos atributos z Tradução de relacionamentos e respectivos atributos z Tradução de generalizações/especializações Banco de Dados Profª. Rossana Junqueira 74 Transformação entre modelos z Implementação inicial de entidades z Cada entidade é traduzida para uma tabela. z Cada atributo da entidade define uma coluna desta tabela. z Atributos identificadores da entidade correspondem a chave primária da tabela. z Tradução inicial – Regras que seguem, as tabelas definidas nessa etapa ainda poderão ser fundidas. z Ex: Pessoa código nome endereço Data admissão Data nascimento Pessoa (CodPess, Nome, Endereço, Data Nasc, DataAdm) Banco de Dados Profª. Rossana Junqueira 75 Transformação entre modelos z Nome de atributos e Nomes de Colunas: z Referenciados freqüentemente em programas e outras formas de texto em computador z Para diminuir o trabalho de programadores – manter os nomes de colunas curtos. z SGBD relacional – nome de uma coluna não pode conter brancos z Não transcrever os nomes de atributos para nomes de colunas z Nomes de atributos compostos de diversas palavras devem ser abreviados z Nomes de colunas não necessitam conter o nome da tabela – Preferível usar o nome de coluna Nome a usar os nomes de coluna NomePess ou NomePessoa z SQL já exige muitas vezes formar - Pessoa.Nome z Chave primária – pode aparecer em outras tabelas na forma de chave estrangeira z Recomendável – nomes das colunas que compõem a chave primária sufixados ou prefixados com o nome ou sigla da tabela na qual aparecem como chave primária z Exemplo: CodigoPess Banco de Dados Profª. Rossana Junqueira 76 Transformação entre modelos z Implementação de relacionamento z Alternativas: z Tabela própria z Adição de colunas a uma das tabelas z Fusão de tabelas Alternativa depende da cardinalidade (máxima e mínima do relacionamento) z Tabela própria Engenheiro ProjetoAtuaçãon n código nome função código título Engenheiro (CodEng, Nome) Projeto (CodProj, Título) Atuação (CodEng, CodProj, Função) CodEng referencia Engenheiro CodProj referencia Projeto Banco de Dados Profª. Rossana Junqueira 77 Transformação entre modelos z Adição de colunas Departamento EmpregadoLotação1 n código nome data lotação código nome Departamento (CodDept, Nome) Empregado (CodEmp, Nome, CodDept, DataLota) CodDept referencia Departamento z Fusão de tabelas Conferência ComissãoOrganização11 código nome Data instalação ender Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg) Banco de Dados Profª. Rossana Junqueira 78 Transformação entre modelos z Implementação de relacionamentos Æ 1:1 Banco de Dados Profª. Rossana Junqueira 79 Transformação entre modelos z 1:1 – Ambas entidades opcionais Homem MulherCasamento (0,1) (0,1) identidade nome data identidade títuloregime Adição de colunas: Mulher (IdentM, Nome, IdentH, Data, Regime) IdentH referencia Homem Homem (IdentH, Nome) Tabela própria: Mulher (IdentM, Nome) Homem (IdentH, Nome) Casamento (IdentM, IdentH, Data, Regime) IdentM referencia Mulher IdentH referencia HomemFusão de Tabelas: (NÃO USAR) Casamento (IdentM, IdentH, NomeM, NomeH, Data, Regime) Banco de Dados Profª. Rossana Junqueira 80 Transformação entre modelos z 1:1 – Ambas entidades opcionais z Solução por fusão de tabelas é inviável – Chave primária artificial z Solução por adição de colunas: melhor opção z Menor número de junções z Menor número de chaves z Solução por tabela própria: opção aceitável Banco de Dados Profª. Rossana Junqueira 81 Transformação entre modelos z 1:1 – Uma entidade opcional outra obrigatória Correntista Cartão Magnético (1,1) (0,1) código nome código Data expedição Adição de colunas: Correntista (CodCorrent, Nome) Cartão (CodCartão, DataExp, CodCorrent) CodCorrent referencia Correntista Tabela própria: (NÃO USAR) Correntista (CodCorrent, Nome) Cartão (CodCartão, DataExp) CartãoCorrentista (CodCartão, CodCorrent) CodCorrent referencia Correntista CodCartão referencia Cartão Fusão de Tabelas: Correntista (CodCorrent, Nome, CodCartão, DataExp) Banco de Dados Profª. Rossana Junqueira 82 Transformação entre modelos z 1:1 – Uma entidade opcional outra obrigatória z Solução por tabela própria é pior que a solução por adição de colunas z Maior número de junções z Maior número de índices z Nenhuma têm problema de campos opcionais z Adição de colunas versus fusão de tabelas z Fusão de tabelas é melhor em termos de número de junções e número de chaves z Adição de colunas em melhor em termos de campos opcionais z Fusão de tabelas é considerada a melhor opção e adição de colunas é aceitável Banco de Dados Profª. Rossana Junqueira 83 Transformação entre modelos z 1:1 – Ambas entidades tem participação obrigatória Fusão de Tabelas: Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg) Conferência ComissãoOrganização (1,1) (1,1) código nome Data instalação ender z Nenhuma das demais alternativas atende plenamente z Entidades que participam do relacionamento seriam representadas através de duas tabelas distintas z Estas tabelas teriam a mesma chave primária e relação um-para-um entre suas linhas z Maior número de junções z Maior número de chaves primárias Banco de Dados Profª. Rossana Junqueira 84 Transformação entre modelos z Implementação de relacionamentos Æ 1: n Banco de Dados 85 Transformação entre modelos z 1:n – A entidade que tem cardinalidade máxima 1 é obrigatória Departamento EmpregadoLotação (1,1) (0,n) código nome data lotação código nome Adição de Colunas: Departamento (CodDept, Nome) Empregado (CodEmp, Nome, CodDept, DataLota) CodDept referencia Departamento Tabela própria: Departamento (CodDept, Nome) Empregado (CodEmp, Nome) Lotação (CodEmp, CodDept, DataLota) CodDept referencia Departamento CodEmp referencia Empregado Banco de Dados Profª. Rossana Junqueira 86 Transformação entre modelos z 1:n – A entidade que tem cardinalidade máxima 1 é obrigatória z Fusão de tabelas z Não se aplica z Implicaria em: redundância de dados de departamento, ou tabela aninhada z Adição de colunas é melhor que tabela própria: Menor número de chaves Menor número de junções Não há o problema de campos opcionais Banco de Dados 87 Transformação entre modelos z 1:n – A entidade que tem cardinalidade máxima 1 é opcional Financeira VendaFinanciam (0,1) (0,n) código nome taxa de juros id data Adição de Colunas: Financeira (CodFin, Nome) Venda (IdVend, Data, CodFin, NoParc, TxJuros) CodFin referencia Financeira Tabela própria: Financeira (CodFin, Nome) Venda (IdVend, Data) Financiam (IdVend, CodFin, NoParc, TxJuros) IdVend referencia Venda CodFin referencia Financeira nº de parcelas z Implementação por tabela própria também é aceitável: z É melhor em relação a campos opcionais z Perde em relação a junções e número de chaves Banco de Dados Profª. Rossana Junqueira 88 Transformação entre modelos z Implementação de relacionamentos Æ n : n Banco de Dados 89 Transformação entre modelos z n:n Tabela própria: Engenheiro (CodEng, Nome) Projeto (CodProj, Título) Atuação (CodEng, CodProj, Função) CodEng referencia Engenheiro CodProj referencia Projeto Engenheiro ProjetoAtuação (0,n) (0,n) código nome função código título Banco de Dados 90 Transformação entre modelos z Relacionamentos de grau maior que dois z Não são definidas regras específicas z O relacionamento é transformado em uma entidade Produto (CodProd, Nome) Cidade (CodCid, Nome) Distribuidor (CodDistr, Nome) Distribuição (CodProd, CodDistr, CodCid, DataInicio) CodProd referencia Produto CodDistr referencia Distribuidor CodCid referencia Cidade Banco de Dados 91 Transformação entre modelos z Implementação de generalização / especialização z Duas alternativas básicas: z uso de uma tabela para cada entidade z uso de uma única tabela para toda hierarquia z Outra alternativa (exótica): Subdivisão de entidade genérica Banco de Dados 92 Transformação entre modelos z Implementação de generalização / especialização z Uma tabela por hierarquia: z Todas as tabelas referentes às especializações são fundidas em uma única tabela z Tabela contém: Chave primária correspondente ao identificador da entidade mais genérica Caso não exista, adicionar uma coluna Tipo Uma coluna para cada atributo da entidade genérica Colunas referentes aos relacionamentos dos quais participa a entidade genérica e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade genérica Uma coluna para cada atributo de cada entidade especializada (opcional) Colunas referentes aos relacionamentos dos quais participa cada entidade especializada e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade (campo opcional) Banco de Dados 93 Transformação entre modelos z Implementação de generalização / especialização z Uma tabela por hierarquia: Emp (CódigoEmp, Tipo, Nome, CIC, CodigoDept, CartHabil, CREA, CódigoRamo) CódigoDept referencia Depto CódigoRamo referencia Ramo Depto (CódigoDept, Nome) Ramo (CódigoRamo, Nome) ProcessTexto (CódigoProc, Nome) Domínio (CódigoEmp, CódigoProc) CódigoEmp referencia Emp CódigoProc referencia ProcessTexto Projeto (CódigoProj, Nome) Participação (CódigoEmp, CodigoProj) CódigoEmp referencia Emp CódigoProj referencia Projeto Banco de Dados 94 Transformação entre modelos z Implementação de generalização/especializaç ão z Uma tabela por entidade especializada: z Criar uma tabela para cada entidade que compõe a hierarquia z Incluir a chave primária da tabela correspondente à entidade genérica, em cada tabela correspondente a uma entidade especializada Emp (CódigoEmp, Tipo, Nome, CIC, CódigoDept) CódigoDept referencia Depto Motorista (CódigoEmp, CartHabil) CódigoEmp referencia Emp Engenheiro (CódigoEmp, CREA, CódigoRamo) CódigoEmp referencia Emp CódigoRamo referencia Ramo Depto (CódigoDept, Nome) Ramo (CódigoRamo, Nome) ProcessTexto (CódigoProc, Nome) Domínio (CódigoEmp, CódigoProc) CódigoEmp referencia Emp Código Proc referencia ProcessTexto Projeto (CódigoProj, Nome) Participação (CódigoEmp, CódigoProj) CódigoEmp referencia Engenheiro CódigoProj referencia Projeto Banco de Dados Profª. Rossana Junqueira 95 Transformação entre modelos z Implementação de generalização / especialização z Vantagens da implementação com tabela única:z Dados referentes à entidade genérica + dados referentes às especializações – em uma única linha z Minimiza junções z Menor número de chaves z Vantagens da implementação com uma tabela por entidade especializada: z Colunas opcionais – apenas aquelas referentes a atributos que podem ser vazios do ponto de vista da aplicação Banco de Dados Profª. Rossana Junqueira 96 Transformação entre modelos z Refinamento do modelo relacional z Projeto (engenharia) em geral – compromisso entre o ideal e o realizável dentro das restrições de recursos impostas pelas prática z Projeto de banco de dados – compromisso entre o ideal (regras de implementação) e o alcançável frente a limitações de performance z Algumas vezes – esquema de BD criado através do uso das regras acima não atende requisitos de performance impostos ao sistema z Necessário buscar alternativa que resulte em melhor performance do sistema z Alternativas somente devem ser tentadas em último caso - do ponto de vista da programação são sempre piores z Exemplos: Relacionamentos mutuamente exclusivos e Simulação de atributos multivalorados Banco de Dados Profª. Rossana Junqueira 97 Transformação entre modelos z Relacionamentos mutuamente exclusivos: z Implementação pelas regras - colunas CIC e CGC em Venda são especificadas como opcionais PessFis (CIC, Nome) PessJur (CGC, RazSoc) Venda (No, data, CIC, CGC) CIC referencia PessFis CGC referencia PessJur z colunas CIC e CGC em Venda são especificadas como opcionais Banco de Dados Profª. Rossana Junqueira 98 Transformação entre modelos z Relacionamentos mutuamente exclusivos: z Implementação alternativa - criar uma única coluna na qual aparece o CIC ou o CGC do comprador PessFis (CIC, Nome) PessJur (CGC, RazSoc) Venda (No, data, CIC/CGC, TipoCompr) z Desvantagem: Não é possível especificar ao SGBD que o campo CIC/CGC é chave estrangeira Não referencia uma única tabela Banco de Dados Profª. Rossana Junqueira 99 Transformação entre modelos z Tratamento de atributos multivalorados: Cliente (CodCli, Nome) Telefone (CodCli, Número) CodCli referencia Cliente z Condições de contorno: Raros clientes possuem mais que dois telefones. Quando isso ocorrer: é suficiente armazenarmos apenas dois números Não há consultas ao banco de dados usando o número de telefone como critério de seleção Números de telefone são apenas exibidos ou impressos juntos às demais informações de cliente Banco de Dados Profª. Rossana Junqueira 100 Transformação entre modelos z Tratamento de atributos multivalorados: z Implementação “desnormalizada” Cliente (CodCli,Nome,NumTel1,NumTel2) z Simular uma coluna multi-valorada através da criação de diversas colunas NumTel sufixadas por um número z Permite que os telefones de um cliente sejam obtidos mais rapidamente z Implica em menos espaço ocupado – não é necessária chave primária da tabela Telefone z Inconveniente z Consulta usando o número de telefone como critério de busca torna-se mais complicada z Manter os telefones "alinhados à esquerda" exige rotina complexa Banco de Dados Profª. Rossana Junqueira 101 Transformação entre modelos z Engenharia reversa de modelos relacionais: z Parte de modelo de implementação z Obtém modelo de especificação (modelo conceitual) z Passos: z Identificação da construção ER correspondente a cada tabela z Definição de relacionamentos 1:n e 1:1 z Definição de atributos z Definição de identificadores de entidades e relacionamentos Banco de Dados Profª. Rossana Junqueira 102 Transformação entre modelos z Ex: Disciplina (CodDisc, NomeDisc) Curso (CodCr, NomeCr) Curric (CodCr, CodDisc, Obr/Opc) CodCr referencia Curso CodDisc referencia Disciplina Sala (CodPr, CodSl, Capacidade) CodPr referencia Prédio Prédio (CodPr, Endereço) Turma (Anosem, CodDisc, SiglaTur, Capacidade, CodPr, CodSl) CodDisc referencia Disciplina (CodPr, CodSl) referencia Sala Laboratório ( CodPr, CodSl, Equipam) (CodPr, CodSl) referencia Sala Banco de Dados 103 Transformação entre modelos z Identificação da construção ER correspondente a cada tabela z Uma tabela pode corresponder a: z uma entidade z um relacionamento n:n z uma entidade especializada z Fator determinante z composição de sua chave primária Banco de Dados Profª. Rossana Junqueira 104 Transformação entre modelos z Ex: Disciplina (CodDisc, NomeDisc) entidade Curso (CodCr, NomeCr) entidade Curric (CodCr, CodDisc, Obr/Opc) relacionamento n:n CodCr referencia Curso CodDisc referencia Disciplina Sala (CodPr, CodSl, Capacidade) entidade CodPr referencia Prédio Prédio (CodPr, Endereço) entidade Turma (Anosem, CodDisc, SiglaTur, Capacidade, CodPr, CodSl) entidade CodDisc referencia Disciplina (CodPr, CodSl) referencia Sala Laboratório ( CodPr, CodSl, Equipam) especialização (CodPr, CodSl) referencia Sala Banco de Dados Profª. Rossana Junqueira 105 Transformação entre modelos z Construções identificadas: Turma Prédio Sala Laboratório Curso Disciplina Currículo n n Banco de Dados Profª. Rossana Junqueira 106 Transformação entre modelos z Identificação de relacionamentos 1:n ou 1:1 z Chave estrangeira que não se enquadra nas regras acima – representa relacionamento 1:n ou relacionamento 1:1 z Esquema não informa se é 1:1 ou 1:n z Chave estrangeira é parte de uma chave primária trata-se de um relacionamento 1:n z Nos demais casos, para definir a cardinalidade, é necessário verificar os possíveis conteúdos do banco de dados Banco de Dados 107 Transformação entre modelos z Construções identificadas: Turma Prédio Sala Laboratório Curso Disciplina CurrículoCurrículo Currículo Currículo n n 1n n 1 n 1 108 Transformação entre modelos z Definição de atributos: z Cada coluna não chave estrangeira é um atributo na entidade/relacionamento correspondente à tabela z As colunas chave estrangeira não correspondem a atributos correspondem a relacionamentos z Definição de identificadores de entidades: z Coluna da chave primária que não é chave estrangeira corresponde a um atributo identificador da entidade ou relacionamento. z Coluna da chave primária que é chave estrangeira corresponde a um relacionamento identificador da entidade Banco de Dados Profª. Rossana Junqueira 109 Capítulo 6: Normalização Banco de Dados Profª. Rossana Junqueira 110 Normalização z Sistemas de informação hoje usados não utilizam bancos de dados relacionais – Sistemas legados (dados armazenados em arquivos de linguagens de 3ª geração). z Raramente documentados. z Necessidade de modelo ER: z Manutenção z Migração para outro tipo de BD z Integração com outros BD Banco de Dados Profª. Rossana Junqueira 111 Normalização Banco de Dados Profª. Rossana Junqueira 112 Normalização z Objetivo: z Reagrupar informações para eliminar redundâncias de dados z Reagrupar informações para eliminar estruturas inexistentes no modelo ER (atributos multivalorados) z Passos: 113 Normalização z Documento exemplo: Código do Projeto: LSC001 Tipo: Novo desenvolvimento Descrição: Sistema de Estoque Código do Empregado Nome Categoria Funcional Salário Data início no projeto Tempo alocado ao projeto 2146 João A1 4 01/11/91 24 3145 Sílvio A2 4 02/10/91 24 6126 José B1 9 03/10/92 18 1214 Carlos A2 4 04/10/92 18 8191 Mário A1 4 01/11/92 12 Código do Projeto: PAG02 Tipo: Manutenção Descrição: Sistema de RH Código do Empregado Nome Categoria Funcional Salário Data início no projeto Tempo alocado ao projeto 8191 Mário A1 4 01/05/93 12 4112 João A2 4 04/01/91 24 6126 José B1 9 01/11/92 12 Banco de Dados 114 Normalização z Representação na forma de tabela não normalizada: z Tabela não-normalizada ou tabela não-primeira-forma-normal z possui uma ou mais tabelas aninhadas z tabela aninhada ( ou grupo repetido ou coluna multivalorada ou coluna não atômica) - coluna que ao invés de conter valores atômicos, contém tabelas aninhadas z Abreviatura: ÑN z Exemplo: Proj (CodProj,Tipo,Descr, (CodEmp, Nome, Cat, Sal, DataIni, TempAl)) Banco de Dados Profª. Rossana Junqueira 115 Normalização z Forma Normal: z Regra que uma tabela deve obedecer para ser considerada “bem projetada” z Há diversas formas normais, cada vez mais rígidas, para verificar tabelas relacionais z Aqui tratadas: z primeira forma normal (1FN) z segunda forma normal (2FN) z terceira forma normal (3FN) Banco de Dados Profª. Rossana Junqueira 116 Normalização z Passagem à primeira forma normal (1FN) z Alternativas: z Uma única tabela Uma tabela na qual os dados das linhas externas à tabela aninhada são repetidos para cada linha da tabela aninhada Exemplo: ProjEmp (CodProj, Tipo, Descr, CodEmp, Nome, Cat, Sal, DataIni, TempAl) Dados do projeto aparecem repetidos para cada empregado do projeto Banco de Dados Profª. Rossana Junqueira 117 Normalização z Uma tabela para cada tabela aninhada Cria-se uma tabela referente a própria tabela que está sendo normalizada e uma tabela para cada tabela aninhada Exemplo: Proj (CodProj, Tipo, Descr) ProjEmp (CodProj,CodEmp, Nome, Cat, Sal, DataIni, TempAl) z Primeira alternativa (tabela única) é mais correta z Decompor uma tabela em várias tabelas (segunda alternativa) – podem ser perdidas relações entre informações z Para fins práticos – preferimos a segunda alternativa (decomposição de tabelas) z Quando houver diversas tabelas aninhadas, eventualmente com diversos níveis de aninhamento, fica difícil visualizar a tabela na 1FN na alternativa de tabela única Banco de Dados Profª. Rossana Junqueira 118 Normalização z Passo 1: z Criar uma tabela na 1FN referente a tabela não normalizada z A chave primária da tabela na 1FN é idêntica a chave da tabela ÑN Criar tabela referente a tabela ÑN Banco de Dados Profª. Rossana Junqueira 119 Normalização z Passo 2: z Para cada tabela aninhada criar uma tabela na 1FN composta pelas seguintes colunas: a chave primária de cada uma das tabelas na qual a tabela em questão está aninhada as colunas da própria tabela aninhada Criar tabela referente a tabela aninhada Banco de Dados Profª. Rossana Junqueira 120 Normalização z Passo 3: z Definir as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas. Definição da chave primária Banco de Dados Profª. Rossana Junqueira 121 Normalização Normalização z Exemplo na 1FN: CodProj Tipo Descr LSC001 Novo Desenvol. Sistema PAG02 Manutenção Sistema de RH CodProj CodEmp Nome Cat Sal DataIni TempAl LSC001 2146 João A1 4 01/11/91 24 LSC001 3145 Sílvio A2 4 02/10/91 24 LSC001 6126 José B1 9 03/10/92 18 LSC001 1214 Carlos A2 4 04/10/92 18 LSC001 8191 Mário A1 4 01/11/92 12 PAG02 8191 Mário A1 4 01/05/93 12 PAG02 4112 João A2 4 04/01/91 24 PAG02 6126 José B1 9 01/11/92 12 ProjEmp Proj Banco de Dados Profª. Rossana Junqueira 123 Normalização z Dependência Funcional: z Para entender 2FN e 3FN – é necessário compreender o conceito de dependência funcional. z 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 linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2. 124 Normalização z Segunda forma normal 2FN: z Objetiva eliminar um certo tipo de redundância de dados z Exemplo: (CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl) z Dados referentes a empregados (Nome, Cat e Sal) – Redundantes, para os empregados que trabalham em mais de um projeto CodProj CodEmp Nome Cat Sal DataIni TempAl LSC001 2146 João A1 4 01/11/91 24 LSC001 3145 Sílvio A2 4 02/10/91 24 LSC001 6126 José B1 9 03/10/92 18 LSC001 1214 Carlos A2 4 04/10/92 18 LSC001 8191 Mário A1 4 01/11/92 12 PAG02 8191 Mário A1 4 01/05/93 12 PAG02 4112 João A2 4 04/01/91 24 PAG02 6126 José B1 9 01/11/92 12 ProjEmp 125 Normalização z Segunda forma normal 2FN: Æ Dependências parciais Æ Dependências não parciais 126 Normalização z Segunda forma normal 2FN: z Tabela 1FN e que possui apenas uma coluna como chave primária – não contém dependências parciais z É impossível uma coluna depender de uma parte da chave primária, quando a chave primária não é composta por partes z Conclusão – Toda tabela 1FN que possui apenas uma coluna como chave primária já está na 2FN 127 Normalização z Segunda forma normal 2FN: z Tabela que contenha apenas colunas chave primária z Impossível atributo não chave depender de parte da chave (tabela não tem colunas não chave) z Tabela sem colunas não chave já está na 2FN 128 Normalização z Segunda forma normal 2FN: Banco de Dados Profª. Rossana Junqueira 129 Normalização z Segunda forma normal 2FN: 130 Normalização z Terceira forma normal 3FN: z Trata de um outro tipo de redundância z Exemplo: Emp (CodEmp, Nome, Cat, Sal) z Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat) z Salário que é pago a uma categoria funcional é armazenado tantas vezes quantos empregados possui a categoria funcional 131 Normalização z Terceira forma normal 3FN: z Trata de um outro tipo de redundância z Exemplo: Emp (CodEmp, Nome, Cat, Sal) z Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat) z Salário que é pago a uma categoria funcional é armazenado tantas vezes quantos empregados possui a categoria funcional Banco de Dados Profª. Rossana Junqueira 132 Normalização z Terceira forma normal 3FN: Proj (CodProj, Tipo, Descr) ProjEmp (CodProj, CodEmp, DataIni, TempAl) Emp (CodEmp, Nome, Cat) Cat (Cat, Sal) Banco de Dados Profª. Rossana Junqueira 133 Normalização z Normalização do exemplo: z ÑN Proj (CodProj,Tipo, Descr, (CodEmp, Nome, Cat, Sal, DataIni, TempAl)) z 1FN Proj (CodProj, Tipo, Descr) ProjEmp (CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl) z 2FN Proj (CodProj, Tipo, Descr) ProjEmp (CodProj, CodEmp, DataIni, TempAl) Emp (CodEmp, Nome, Cat, Sal) z 3FN Proj (CodProj, Tipo, Descr) ProjEmp (CodProj, CodEmp, DataIni, TempAl) Emp (CodEmp, Nome, Cat) Cat (Cat, Sal) Banco de Dados Profª. Rossana Junqueira 134 Normalização z Tabelas na 3FN: Normalização z Problemas de normalização: z Chaves primárias omitidas ou incorretas z Arquivos convencionais: o conceito de chave primária não é obrigatório é possível encontrar arquivos que não possuem chave primária z Quando um arquivo convencional não possui chave primária ou quando a chave primária nele usada difere da usual na organização: deve-se proceder como se a chave primária aparecesse no arquivo deve-se inseri-la na forma ÑN z Arquivo com dados sobre empregados de uma organização enviado para fins de fiscalização a um órgão governamental z Identificador de empregado usado na organização é omitido, já que este é irrelevante para o órgão fiscalizador z Outra situação: uso de uma chave alternativa, ao invés da chave primária usual do arquivo z No caso mencionado acima: Se o órgão governamental fosse a receita federal, arquivo poderia ter como chave primária o CIC do empregado, ao invés da chave primária normalmente usada na organização. Banco de Dados Profª. Rossana Junqueira 136 Normalização z Problemas de normalização: z Atributos relevantes implicitamente representados z Arquivos convencionais podem conter atributos de forma implícita ordenação de registros ou de listas ponteiros físicos, etc z Deve-se proceder como se o atributo aparecesse explicitamente no documento z Exemplo: arquivo contém registros referentes a cursos em um concurso vestibular para cada curso, há um grupo repetido aninhado, com as informações dos candidatos ao curso em questão informações dos candidatos ordenadas por classificação no concurso Banco de Dados Profª. Rossana Junqueira 137 Normalização z Problemas de normalização: z Atributos irrelevantes, redundantes ou derivados z Devem ser eliminados já quando da passagem a forma não normalizada Banco de Dados Profª. Rossana Junqueira 138 Capítulo 7: SQLBanco de Dados Profª. Rossana Junqueira 139 Criação de Banco de Dados z Conjunto de objetos que armazenam e manipulam dados. z Como nomear arquivos e objetos: z Regras para nomeação dos objetos: z Caracteres A...Z, a...z, 0...9, $ e _ z Nomes devem começar com A...Z ou a...z. z Nomes limitados a 31 caracteres. z Nomes dos objetos devem ser únicos. z CREATE DATABASE ‘C:\Banco de Dados\empresa.fdb’; Criação de Tabelas z Restrições a serem especificadas para uma coluna de tabela: z Regras que governam os relacionamentos e validam entradas de dados. z Atuam em todas as transações que acessam o banco de dados e são automaticamente mantidas pelo sistema. z Restrição UNIQUE e PRIMARY KEY: z Asseguram que os valores inseridos em uma ou mais colunas são únicos para cada linha da tabela. z Uma ou mais colunas definidas com essas restrições devem também ser definidas com o atributo NOT NULL. z Restrição FOREIGN KEY: z Chave estrangeira é uma ou mais colunas em uma tabela que corresponde exatamente a uma ou mais colunas definida(s) como chave primária em outra tabela. z Restrição CHECK: z Estabelece uma condição que deve ser verdadeira durante uma entrada ou atualização de dados na tabela. z Além dessas restrições, uma coluna pode ser definida com o atributo NOT NULL. Esse atributo não permite valores nulos na coluna onde é definida e é obrigatório em colunas com restrições PRIMARY KEY ou UNIQUE. Banco de Dados Profª. Rossana Junqueira 141 Criação de Tabelas z CREATE TABLE cria uma nova tabela, suas colunas e restrições de integridade em um banco de dados. z Tabela Fabrica CREATE TABLE FABRICA ( ID_FABRICA INTEGER NOT NULL, NOME VARCHAR(40) NOT NULL, ENDERECO VARCHAR(40), CIDADE VARCHAR(30), UF CHAR(2), TELEFONE VARCHAR(20), CONSTRAINT PK_FABRICA PRIMARY KEY (ID_FABRICA)); Banco de Dados Profª. Rossana Junqueira 142 Criação de Tabelas z Tabela Produto CREATE TABLE Produto (Id_Produto INTEGER NOT NULL, Referencia VARCHAR(15), Descricao VARCHAR(40) NOT NULL, Unidade CHAR(2) DEFAULT 'UN' NOT NULL, Id_Fabrica INTEGER NOT NULL, Id_ProdutoC INTEGER NOT NULL, CONSTRAINT PK_PRODUTO PRIMARY KEY (ID_PRODUTO), CONSTRAINT FK_PRODUTO_FABRICA FOREIGN KEY (ID_FABRICA) REFERENCES Fabrica (Id_Fabrica), CONSTRAINT FK_PRODUTO_PRODUTO FOREIGN KEY (ID_PRODUTOC) REFERENCES Produto (Id_Produto)); Banco de Dados Profª. Rossana Junqueira 143 Alteração de Tabelas z ALTER TABLE modifica uma tabela adicionando, modificando ou eliminando colunas ou restrições. z Para alterar uma tabela, deve-se observar o seguinte: z Uma tabela pode ser alterada por seu criador ou qualquer usuário com direitos de superusuário do sistema operacional. z ALTER TABLE provoca erro se os novos dados em uma tabela violam as definições de restrição PRIMARY KEY ou UNIQUE. z Eliminar uma coluna provoca falha se: z A coluna é parte de uma restrição UNIQUE, PRIMARY KEY ou FOREING KEY. z A coluna é usada em uma restrição CHECK. z A coluna é utilizada em uma expressão value de uma coluna calculada. z A coluna é referenciada por outros objetos, tais como uma visão. Banco de Dados Profª. Rossana Junqueira 144 Alteração de Tabelas z Exemplos de utilização de ALTER TABLE: z Incluir nova coluna z ALTER TABLE Fabrica ADD Email VARCHAR(30); z ALTER TABLE Fabrica ADD Contato VARCHAR(30) NOT NULL, ADD Fax VARCHAR(18); z Eliminar uma coluna existente z ALTER TABLE Fabrica DROP Fax; z Alterar a posição de uma coluna z ALTER TABLE Produto ALTER Id_ProdutoC POSITION 5; Banco de Dados Profª. Rossana Junqueira 145 Alteração de Tabelas z Exemplos de utilização de ALTER TABLE: z Alterar o tipo de dado de uma coluna z ALTER TABLE Fabrica ALTER Email TYPE VARCHAR(40); z Obs: Tamanhos de tipos não podem ser reduzidos e o novo tipo de dado deve ser capaz de manter os dados originais. z Alterar o nome da coluna z ALTER TABLE Fabrica ALTER Nome TO RazaoSocial; z Adicionar uma nova restrição z ALTER TABLE Fabrica ADD CONSTRAINT Un_Mail UNIQUE (Email); z Eliminar uma restrição existente z ALTER TABLE Fabrica DROP CONSTRAINT Un_Mail; Banco de Dados Profª. Rossana Junqueira 146 Exclusão de Tabelas z A instrução DROP TABLE remove dados de tabela. z Não se pode eliminar uma tabela que é referenciada em uma coluna calculada, uma visão, restrição de chave estrangeira ou procedimento armazenado. z DROP TABLE [nome da tabela] Banco de Dados Profª. Rossana Junqueira 147 Povoamento de Tabelas z INSERT armazena uma ou mais linhas de dados em uma tabela. z Os valores inseridos devem estar na mesma ordem das colunas da tabela. z Se o número de colunas informadas no comando for menor que o número de colunas da tabela, valores padrões ou NULL são armazenados nas colunas não informadas. z Para inserir uma única linha de dados na tabela, deve-se especificar uma lista de valores na cláusula VALUES. z Inserções de dados nas tabelas não podem violar as restrições. z É importante inserir dados primeiramente nas tabelas referenciadas por chaves estrangeiras. Banco de Dados Profª. Rossana Junqueira 148 Povoamento de Tabelas z Exemplos: z INSERT INTO Vendedor VALUES (1, ‘João Dias’); z A instrução seguinte insere uma linha na mesma tabela, mas informa explicitamente as colunas para as quais serão informados: z INSERT INTO Vendedor (Id_Vendedor, Nome) VALUES (2, ‘Fábio Almeida’); z INSERT INTO Cliente VALUES (1, ‘Francisco de Assis’, ‘Av. Principal, 500’, ‘Santarém’, ‘PA’, ‘3522-0101’, ‘Francisco’); Povoamento de Tabelas z INSERT INTO Transportadora VALUES (1, ‘Transpedroso’, ‘Av. Getúlio Vargas, 500’, ‘São Paulo’, ‘SP’); z INSERT INTO Pedido VALUES (1, ’06/15/2005’, 500, 1, 1, 1); z O campo data é inserido no formato mm/dd/aaaa z INSERT INTO Fabrica (Id_Fabrica, RazaoSocial, UF) VALUES (1, ’CAP Computadores Ltda’, ‘SP’); z INSERT INTO Produto VALUES (1, null, 'Microcomputador', 'UN', null, 1); z As colunas Referencia e Id_ProdutoC da tabela Produto permitem valores nulos e esta é uma maneira de inserir nulos. z A outra é a maneira como foi inserida a linha na tabela Fabrica. Omitiram- se as colunas que receberão valores nulos. Banco de Dados Profª. Rossana Junqueira 150 Alteração de dados z A instrução UPDATE modifica os dados em toda ou parte de uma linha de uma tabela. z Em caso de atualizações seletivas, a cláusula opcional WHERE pode ser usada para restringir as atualizações a um subconjunto de linhas na tabela. z Se a cláusula WHERE não for utilizada, todas as linhas da tabela serão atualizadas. z O seguinte comando modifica as linhas da tabela. Esse comando calcula um novo preço para todos os produtos, reajustando-os em 5%: z UPDATE ProdutoCond SET Preco = Preco * 1.05; Banco de Dados Profª. Rossana Junqueira 151 Alteração de dados z O comando a seguir modifica apenas uma linha da tabela. Modifica a descrição do produto que tem chave primária igual a 2: z UPDATE Produto SET Descricao = ‘Monitor de vídeo 15”’ WHERE Id_Produto = 2; z Quando for necessário alterar os dados de uma única linha é aconselhável selecioná-la pela chave primária. Este é a garantia de que a atualização ocorrerá em uma única linha, no máximo. z UPDATE Pedido SET Id_Transportadora = 1, Id_Vendedor = 2 WHERE Data = ’06/15/2005’; z O comando acima modifica dados de duas colunas dos pedidos efetuados em 15/06/2005. Banco de Dados Profª. Rossana Junqueira 152 Exclusão de linhas z O comando DELETE elimina linhas de uma tabela. z Especifica uma ou mais linhas a serem eliminadas de uma tabela. z No caso de deleções seletivas, a cláusula WHERE deve ser utilizada para restringir as exclusões a um subconjunto de linhas de uma tabela. z Se a cláusula WHERE não for especificada, todas as linhas da tabela são eliminadas. z O comando a seguir deleta todas as linhas da tabela: z DELETE FROM ProdutoPedido; z A exclusão de linhas de uma tabela não pode violar as restrições de chave estrangeira. z Se não, devem ser excluídas inicialmente as linhas da tabela filha (a tabelaque tem a chave estrangeira). z O comando seguinte elimina linhas específicas de uma tabela: z DELETE FROM ProdutoPedido WHERE Id_Pedido = 1; Banco de Dados Profª. Rossana Junqueira 153 Consultas a dados de uma tabela z Uma das funções mais importantes de um SGBD é permitir que os dados armazenados em um banco de dados sejam recuperados das formas mais diversas que se possa imaginar. z O comando SELECT é o comando SQL utilizado para recuperar informações de bancos de dados. z Operadores: z A cláusula WHERE utiliza expressões que limitam as linhas da tabela a serem recuperadas. z Dessas expressões fazem parte os operadores que podem ser classificados em quatro categorias: z Aritméticos z Lógicos z De comparação z De concatenação Banco de Dados Profª. Rossana Junqueira 154 Consultas a dados de uma tabela z Aritméticos: + Adição - Subtração * Multiplicação / Divisão z Lógicos: AND E OR Ou NOT Não z De concatenação: || Concatenação de strings z De comparação: < Menor que > Maior que <= Menor ou igual a >= Maior ou igual a = Igual <> Diferente BETWEEN Entre IN Em IS É LIKE Igual a Banco de Dados Profª. Rossana Junqueira 155 Consultas a dados de uma tabela z Consultas simples: z SELECT * FROM CLIENTE; z Esse comando recupera todas as linhas e colunas da tabela CLIENTE. z O asterisco (*) indica que todas as colunas são mostradas. z Se for desejado recuperar colunas específicas da tabela, um exemplo seria: z SELECT NOME, CONTATO, TELEFONE FROM CLIENTE; z É possível também, nas consultas, que os nomes originais das colunas sejam modificados. z SELECT ID_FABRICA AS ID, RAZAOSOCIAL AS "RAZÃO SOCIAL“ FROM FABRICA; z A cláusula AS permite que as colunas recebam um apelido. Banco de Dados Profª. Rossana Junqueira 156 Consultas a dados de uma tabela z A cláusula AS permite que as colunas recebam um apelido. z Se o apelido possuir espaços deve-se defini-lo entre aspas. z A cláusula AS é opcional. z O comando no formato a seguir produz o mesmo resultado: SELECT ID_FABRICA ID, RAZAOSOCIAL "RAZÃO SOCIAL“ FROM FABRICA; z As colunas de consultas podem incluir expressões aritméticas. z SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 FROM PRODUTOCOND; z Esta consulta mostra os preços dos produtos com seus valores reajustados em 5%. z No resultado da consulta, essa coluna não estará identificada. Assim, é fortemente aconselhável utilizar sempre os apelidos. SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 “Novo Preço” FROM PRODUTOCOND; Banco de Dados Profª. Rossana Junqueira 157 Consultas a dados de uma tabela z A consulta seguinte utiliza o operador de concatenação: z SELECT NOME, ENDERECO, CIDADE || '-' || UF "CIDADE-ESTADO" FROM CLIENTE; z A terceira coluna da consulta é resultante da concatenação de três strings: as colunas da tabela, CIDADE e UF, e o literal hífen (-). z Foi atribuído um apelido à coluna resultante do cálculo. z A cláusula DISTINCT é utilizada para suprimir linhas duplicadas do resultado de uma coluna. z SELECT CIDADE FROM CLIENTE; z O comando acima poderia retornar linhas duplicadas. z Para eliminar as duplicações utiliza-se DISTINCT: SELECT DISTINCT CIDADE FROM CLIENTE; Banco de Dados Profª. Rossana Junqueira 158 Consultas a dados de uma tabela z Uso da cláusula WHERE: z O uso de WHERE juntamente com as expressões envolvendo os operadores irá permitir que seja obtido o resultado de uma consulta seletiva, onde apenas as linhas que atendem às restrições estabelecidas são mostradas. z Com operadores de Comparação: z SELECT ID_CLIENTE, NOME FROM CLIENTE WHERE UF = 'PA'; Retornam da tabela CLIENTE as linhas que atendem a condição de que a coluna UF seja igual a ‘PA’. z SELECT ID_PEDIDO, VALOR, ID_CLIENTE FROM PEDIDO WHERE DATA > '06/15/2005'; Essa consulta mostra os pedidos cuja DATA seja maior que 15/06/2005. Banco de Dados Profª. Rossana Junqueira 159 Consultas a dados de uma tabela z SELECT ID_CLIENTE, NOME FROM CLIENTE WHERE NOME LIKE 'A%'; O operador LIKE recupera da tabela os clientes que têm o nome iniciando com a letra A. z SELECT * FROM PEDIDO WHERE VALOR BETWEEN 200 AND 700; Essa consulta retorna todos os pedidos, tais que a coluna VALOR esteja no intervalo entre 200 e 700 reais. Se houver linhas cujos valores sejam iguais a 200 ou 700, elas serão retornadas. z SELECT ID_FABRICA, RAZAOSOCIAL FROM FABRICA WHERE UF IN ('PA', 'AM', 'AC', 'AP'); Essa consulta retorna as linhas onde a coluna UF seja igual a qualquer dos elementos relacionados entre parênteses. Banco de Dados Profª. Rossana Junqueira 160 Consultas a dados de uma tabela z Com operadores Lógicos: z SELECT * FROM CLIENTE WHERE NOT UF = 'PA'; Mostra os clientes que não são do estado do Pará. z SELECT * FROM PEDIDO WHERE VALOR NOT BETWEEN 200 AND 700; Retorna os pedidos cujos valores não estão entre 200 e 700. z SELECT * FROM CLIENTE WHERE NOME NOT LIKE 'D%'; Recupera os clientes cujos nomes não iniciam com a letra D. z SELECT * FROM PRODUTO WHERE ID_PRODUTOC IS NOT NULL; Mostra os produtos que fazem parte da composição de outro produto, ou seja, aqueles em que a coluna ID_COMPOSTOC não é nula. Banco de Dados Profª. Rossana Junqueira 161 Consultas a dados de uma tabela z SELECT * FROM PEDIDO WHERE VALOR > 200 AND VALOR < 700; AND e OR são utilizados para criar condições complexas resultantes de duas ou mais condições que usam operadores de comparação. z Uso da cláusula ORDER BY: z Como padrão, uma consulta recupera linhas na mesma ordem em que ela as encontra na tabela. z Para especificar uma ordem na qual as linhas devem ser retornadas por uma consulta, usa-se a cláusula ORDER BY no fim do comando SELECT. z SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE; z SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE DESC, RAZAOSOCIAL; Banco de Dados Profª. Rossana Junqueira 162 Consultas a dados de uma tabela z Uso de funções: z AVG z SELECT AVG(VALOR) FROM PEDIDO; Calcula a média dos valores numéricos em uma coluna. z COUNT z SELECT COUNT(*) FROM CLIENTE; Calcula o número de linhas que satisfazem uma condição de seleção de uma consulta. z MAX z SELECT MAX(VALOR) FROM PEDIDO; Recupera o valor máximo de uma coluna. z MIN z SELECT MIN(VALOR) FROM PEDIDO; Recupera o valor mínimo de uma coluna. Banco de Dados Profª. Rossana Junqueira 163 Consultas a dados de uma tabela z Agrupamento de linhas com GROUP BY: z Habilita uma consulta retornar um resumo sobre grupos de linhas que compartilham valores de coluna. z SELECT ID_CLIENTE, AVG(VALOR) FROM PEDIDO GROUP BY ID_CLIENTE; z O exemplo retorna o valor médio dos pedidos de cada cliente. z A cláusula GROUP BY garante que o valor médio dos pedidos seja calculado e recuperado com base no identificados de cada cliente. Banco de Dados Profª. Rossana Junqueira 164 Relacionamento entre tabelas z Devido ao Firebird se tratar de um banco de dados relacional, às vezes pode ser necessário construir consultas a dados que estão em tabelas diferentes. z A recuperação de dados de duas ou mais tabelas usando um único comando SELECT é denominada junção (join). select a.ID_PEDIDO, a.DATA, a.VALOR, b.NOME from PEDIDO a, CLIENTE b where a.ID_CLIENTE = b.ID_CLIENTE and a.DATA >= '06/25/2006'; z Observa-se neste exemplo o uso do alias de uma tabela. z Um alias, ou apelido, é uma variável temporária que representa o nome da tabela. Disciplina: Banco de Dados Capítulo 1: Conceitos Básicos Como Informática é adotada em organizações Sistemas isolados – Dados não compartilhados Sistemas isolados – Dados não compartilhados Banco de Dados Sistema de gerência de banco de dados Sistema de gerência de banco de dados Sistema de gerência de banco de dados Sistema de gerência de banco de dados Sistema de gerência de banco de dados Modelo de Dados Esquema de banco de dados Modelo Conceitual Modelo Lógico Modelo Físico Modelo conceitual como modelo de organizaçãoModelo conceitual como modelo de organização Projeto de banco de dados Capítulo 2: Abordagem entidade - relacionamento Abordagem entidade-relacionamento Entidade Entidade Relacionamento Relacionamento Cardinalidade de relacionamentos Cardinalidade de relacionamentos Cardinalidade de relacionamentos Exemplos de entidades e relacionamentos Atributo Atributo Generalização e Especialização Generalização e Especialização Entidade associativa Entidade associativa Capítulo 3: Construindo modelos entidade-relacionamento Propriedades de modelos ER Equivalência entre modelos Exemplo de equivalência entre modelos Exemplo de equivalência entre modelos Atributo versus entidade relacionada Atributo versus generalização/especialização Verificação do modelo Verificação do modelo Verificação do modelo Verificação do modelo Verificação do modelo Verificação do modelo Verificação do modelo Estabelecimento de padrões Estratégias de modelagem Definição da estratégia de modelagem Capítulo 4: Abordagem relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Abordagem Relacional Capítulo 5: Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Transformação entre modelos Capítulo 6: Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Normalização Capítulo 7: SQL Criação de Banco de Dados Criação de Tabelas Criação de Tabelas Criação de Tabelas Alteração de Tabelas Alteração de Tabelas Alteração de Tabelas Exclusão de Tabelas Povoamento de Tabelas Povoamento de Tabelas Povoamento de Tabelas Alteração de dados Alteração de dados Exclusão de linhas Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Consultas a dados de uma tabela Relacionamento entre tabelas
Compartilhar