Apostila Banco de Dados 2008-1

Banco de Dados Profª. Rossana Junqueira 1

Disciplina: Banco de Dados

Profa. Rossana de Paula JunqueiraAlmeida

Ciência da Computação - 4° Período


Capítulo 1: Conceitos Básicos


Como Informática é adotada em organizaçõesInformática é implementada gradativamente;Exemplo: uma empresa

Implementa gradativamente sistemas para:VendasProduçãoCompras

Onde ficam os dados dos produtos?Usados em várias funçõesPode ocorrer que, para casa uma das funções, seja criado um arquivo separado de produtos.


Sistemas isolados – Dados não compartilhados

Problema: redundância de dadosTipos de redundância da dados:

Redundância controlada de dadosQuando o software tem conhecimento da múltipla representação da informação e garante a sincronia entre as diversas representações.


Sistemas isolados – Dados não compartilhados

Redundância não controlada de dadosO usuário gerencia a redundânciaDever ser evitadoProblemas:

Entrada repetida da mesma informaçãoInconsistência de dados

Como evitar:Compartilhamento dos dadosCada informação é armazenada uma única vezUsar o conceito de Banco de Dados


Banco de DadosConjunto de arquivos integrados que atendem a um conjunto de sistemas

O compartilhamento de dados tem reflexos na estrutura do software:A estrutura interna dos arquivos para a ser mais complexaDevem atender às necessidades dos diferentes sistemas

Solução:Usar sistema de gerência de banco de dados


Sistema de gerência de banco de dadosInício da programação de aplicações

Programa continha todas operaçõesInterface de usuárioTransformação de dados e cálculosOperações de armazenamento de dadosTarefas de comunicação com outros sistemas e programas

Evolução da programação:Foram identificadas funcionalidades comuns a muitos programas

Exibição dos dados na interfaceGerenciadores de interface do usuário

Comunicação com processos remotosGerenciadores de comunicação

Manutenção de grandes repositórios compartilhados de dadosSistemas de Gerência de Banco de Dados (SGBD)


Sistema de gerência de banco de dadosSoftware que incorpora as funções de definição, recuperação e alteração de dados em um banco de dadosFacilita o desenvolvimento de aplicações de BD

Manutenção de programas torna-se mais simplesProdutividade de programadores aumenta


Sistema de Banco de Dados:

Apenas um sistema computadorizado de manutenção de registros

ouSistema computadorizado cuja finalidade geral éarmazenar informações e permitir que os usuários busquem e atualizem essas informações quando as solicitar.

Tal sistema envolve quatro componentes principais: Dados, Hardware, Software e Usuários.

Sistema de gerência de banco de dados


Sistema de Banco de Dados: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 Banco de Dados:Hardware:

Volumes de armazenamento, processadores de hardware e memória.

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

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).



Modelo de DadosModelo de (banco) de dados

Descrição dos tipos de informações que estão armazenadas em um banco de dadosExemplo da indústria:

Modelo de dados informa:São armazenadas informações sobre produtosPara cada produto, são armazenados seu código, preço e descrição

Modelo de dados não informa:Quais os produtos que estão armazenados no banco de dados


Esquema de banco de dadosPara construir um modelo de dados usa-se:

Linguagem de modelagem de dados:TextualGráfica

Um modelo de dados pode ser apresentado de várias formas (texto, figura, ...)Cada apresentação do modelo recebe a denominação esquema de banco de dados

Níveis de Abstração:

Banco de Dados 14

Modelo ConceitualIndependente do tipo de SGBDRegistra:

Que dados podem aparecer no banco de dadosNão registra:

Como estes dados estão armazenados a nível de SGBDTécnica mais difundida na modelagem conceitual

Abordagem entidade-relacionamento (ER)Modelo conceitual é representado através de diagrama entidade-relacionamento (DER)

Banco de Dados

Modelo LógicoNível de abstração visto pelo usuário do SGBDDepende do tipo particular de SGBD que está sendo usadoEm um SGBD relacional, os dados estão organizados na forma de tabelas


Modelo FísicoContém detalhes de armazenamento interno de informaçõesDetalhes que:

Não têm influencia sobre a programação de aplicações no SGBDInfluenciam na performance das aplicações

Usados por profissionais que fazem sintonia de performance em banco de dados, procurando otimizar o desempenho.


Modelo conceitual como modelo de organizaçãoConstatação

Um arquivo em computador contém informações sobre um conjunto de objetos ou entidades da organização que é atendida pelo sistema em computador

Exemplo da indústriaUm arquivo para armazenar dados de produtos, outro para armazenar dados de vendas, outro para dados de ordem de serviço e assim por diante

Idéia fundamental do projeto de banco de dados: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


Modelo conceitual como modelo de organizaçãoModelo conceitual tem dupla interpretação:

Modelo da organizaçãoDefine as entidades da organização que tem informações armazenadas no banco de dadosExemplificando:

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.

Modelo do banco de dadosDefine que arquivos (tabelas) farão parte do banco de dadosExemplificando:

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.


Projeto de banco de dados3 fases:

Modelagem conceitualConstruído um modelo conceitual, na forma de um diagrama entidade-relacionamento.

Modelo lógicoObjetiva transformar o modelo conceitual obtido na primeira faze em um modelo lógico.

Projeto físicoO modelo é enriquecido com detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua funcionalidade


Capítulo 2: Abordagem entidade -

relacionamento


Abordagem entidade- relacionamento

Técnica para construir modelos conceituais de bases de dadosTécnica de modelagem de dados mais difundida e utilizadaCriada em 1976 por Peter ChenPadrão de fato para modelagem conceitualNão é única:

NIAM/ORM (técnica européia da década de 70)UML (Técnica para modelos Orientados a Objetos)

Técnicas de modelagem orientada a objetos (UML) baseiam-se nos conceitos da abordagem ERModelo de dados é representado através de um

modelo entidade-relacionamento (modelo ER)Modelo ER é representado graficamente

diagrama entidade-relacionamento (DER)


EntidadeConjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dadosExemplos:

Sistema de informações industrial:ProdutosTipos de produtosVendasCompras

Sistemas de contas correntes:ClientesConta correntesChequesAgências


EntidadeRepresentada através de um retânguloRetângulo contem o nome da entidade

Entidade = conjunto de objetosPara se referir a um objeto em particular fala-se em instânciaou ocorrência da entidadeEntidade isoladamente não informa nada, é necessário saber quais as informações que devem ser mantidas para cada objeto, ou seja, atribuir propriedades às entidadesPropriedades são especificadas na forma de: relacionamentos, atributos e generalizações/especializações

Pessoa Departamento


RelacionamentoConjunto de associações entre entidades sobre as quais deseja-se manter informações na base de dados

Relacionamento é um conjunto de associações entre instâncias de entidadesUma instância (ocorrência) é uma associação específica entre determinadas instâncias de entidadeExemplo (relacionamento LOTAÇÃO)

ocorrência = par específico formado por uma ocorrência de PESSOA e uma ocorrência de DEPARTAMENTO

25

RelacionamentoAuto-relacionamento:

Relacionamento de casamentoUma ocorrência de pessoa exerce o papel de maridoUma ocorrência de pessoa exerce o papel de esposa

Relacionamento entre entidades diferentes não é necessário indicar os papéis das entidades


Cardinalidade de relacionamentosPropriedade importante de um relacionamento

Quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência de entidade através do relacionamento

Chamada de cardinalidade de uma entidade em um relacionamentoCardinalidade máxima:

27

Cardinalidade de relacionamentosRelacionamento de 1:1 Relacionamento de 1:n

Relacionamento de n:n


Cardinalidade de relacionamentosCardinalidade mínima:

Número mínimo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamentoPara fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas

cardinalidade mínima 0cardinalidade mínima 1

Denominação alternativa:cardinalidade mínima 1 = “associação obrigatória”cardinalidade mínima 0 = “associação opcional”


Exemplos de entidades e relacionamentos


AtributoDado ou informação que é associado a cada ocorrência de uma entidade ou de um relacionamento


AtributoCada entidade deve possuir um identificador

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çãoEste conceito permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica.Associada ao conceito

de generalização/Especialização está

a idéia

de herança de propriedades.Herdar propriedades significa

que cada ocorrência da entidadeespecializada possui:

Além de suas próprias propriedadesTambém as propriedades da ocorrência da entidade genérica correspondente

Banco de Dados

Generalização e EspecializaçãoEspecialização total ou parcial

Banco de Dados 34

Entidade associativa

É necessário saber que medicamentos foram prescritos em cada consulta.Uma entidade associativa

nada mais é

que a redefiniçãode um relacionamento, quepassa a ser tratado como sefosse também uma entidade.


Entidade associativa


Capítulo 3: Construindo modelos entidade-

relacionamento


Propriedades de modelos ERÉ um modelo formal, preciso, não ambíguo.

Isto significa que diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo.DER pode ser usado como entrada a uma ferramenta CASE.Fundamental: todos os envolvidos devem estar treinados na sua perfeita compreensão.Risco: sub-utilização

Modelos ER têm poder de expressão limitadoModelo ER apresenta apenas algumas propriedades de um banco de dadosFoi concebido para o projeto da estrutura de um BD relacionalPouco poderoso para expressar restrições de integridade (regras de negócio)


Equivalência entre modelosDois modelos diferentes podem se equivalentesModelos equivalentes:

expressam o mesmomodelam a mesma realidade

Para fins de projeto de banco de dados, dois modelos ER são equivalentes, quando ambos geram o mesmo esquema de banco de dadosPara 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


Exemplo de equivalência entre modelos

CONSULTA como relacionamento n:n

CONSULTA como entidade


Exemplo de equivalência entre modelos

A determinação de que construção da abordagem ER (entidade, relacionamento, atributo,...) será usada para modelar um objeto de uma realidade

não pode ser feita através da observação do objeto isoladamenteé necessário conhecer o contexto (modelo dentro do qual o objeto aparece)

Decisão por uma construção para a modelagem de um objeto está sujeita a alteração durante a modelagemNão despender um tempo excessivo em longas discussões sobre como modelar um objetoO próprio desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e aperfeiçoando o modeloExistem critérios alguns critérios para escolha de construções de modelagem


Atributo versus entidade relacionada

Alguns critérios para esta decisão são:Objeto está vinculado a outros objetos

deve ser modelado como entidadeCaso contrário pode ser modelado como

atributoConjunto de valores de um determinado objeto é fixo, pode ser modelado como atributoExistem transações no sistema que alteram o conjunto de valores do objeto, não deve ser modelado como atributo


Atributo versus generalização/especialização

Questão:Modelar um determinado objeto (por exemplo, a categoria funcional de cada empregado de uma empresa) como atributo ou como especialização?

Especialização deve ser usada quando as classes especializadas de entidades possuem propriedades particulares

43

Verificação do modeloUma vez construído, um modelo ER dever ser validado e verificado.A verificação é o controle de qualidade que procura garantir que o modelo usado para a construção do banco de dados gerará um bom produto.Um modelo para ser considerado bom, deve preencher uma série de requisitos, como ser completo, ser correto e não conter redundância.Modelo CORRETO

Dois tipos de erros: sintáticos e semânticosSintáticos ocorrem quando o modelo não respeita as regras de construção de um modelo ERSemânticos ocorrem quando o modelo, apesar de estar sintaticamente correto, reflete a realidade de forma inconsistente.

Estabelecer associações incorretasUsar uma entidade do modelo como atributo de outra entidade


Verificação do modeloModelo COMPLETO

Deve fixar todas as propriedades desejáveis do banco de dados.Somente pode ser verificado por alguém que conhece profundamente o sistema a ser implementado.Forma de verificar:

Todos os dados que devem ser obtidos do banco de dados estão presentes?Todas as transações de modificação do banco de dados podem ser executadas sobre o modelo?

Este requisito é aparentemente conflitante com a falta de poder de expressão de modelos ER.

Banco de Dados 45

Verificação do modeloModelo deve ser livre de REDUNDÂNCIAS

Modelo deve ser mínimo, isto é não deve conter conceitos redundantesTipos de redundância:

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.


Verificação do modeloAtributos 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.


Verificação do modeloModelo deve refletir o aspecto temporal

Dados temporaisDados que mudam ao longo do tempo e para as quais o BD mantém histórico

Tipos de dados temporais:Atributos cujos valores modificam ao longo do tempoRelacionamentos que modificam ao longo do tempo

48

Verificação do modeloConsultas a dados referentes ao passado

Muitas vezes, informações referentes ao passado são eliminadas da base de dados (arquivamento)Podem ser necessárias no futuro:

Por motivos legaisPara realização de auditoriasPara tomada de decisões

Dados referentes ao passado – planejar arquivamentoSolução que poderia ser considerada

Reincluir as informações no banco de dados, quando elas forem necessárias

Problema: restrições de integridade referencialPlanejar informações estatísticas

Quando informações antigas são necessárias apenas para tomada de decisõesPode ser conveniente manter no banco de dados informações compiladas e eliminar as informações usadas na compilação


Verificação do modeloEntidade isolada e entidade sem atributos

Caso raro, mas não incorretoEntidade que muitas vezes aparece isoladaCaso típico:

Entidade que modela a organização na qual o sistema implementado pelo BD está embutida

Exemplo: BD de uma universidadeA entidade UNIVERSIDADE pode ser necessária, caso se deseje manter no BD alguns atributos da universidadeO modelo não deveria conter o relacionamento desta entidade com outras, como ALUNO ou CURSO

BD modela uma única universidadeNã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õesModelos de dados são usados para comunicação com:

Pessoas da organização (usuários, analistas, programadores, ...)Programas (ferramentas CASE, geradores de código, ...)

É necessário estabelecer padrões de confecção de modelosNa 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ânticaVariantes de abordagem ER

Peter Chen (acadêmica)Engenharia de informaçõesUMLMerise (notação Européia)


Estratégias de modelagemUma seqüência de passos (uma “receita de bolo”) de transformação de modelos desde o modelo inicial de modelagem até o finalDiferentes estratégias:

Bottom-up Parti de conceitos mais detalhados e abstrai gradativamente. Inicia com a identificação de atributosTop-down Parti de conceitos mais abstratos e vai gradativamente refinando estes conceitos em conceitos mais detalhados. Inicia com a identificação de entidades genéricasInside-out De dentro pra fora. Parti de conceitos considerados importantes e vai gradativamente adicionando conceitos periféricos a eles relacionados


Definição da estratégia de modelagem

Na práticaNenhuma das estratégias propostas na literatura é universalmente aceita

NormalCombinação das diversas estratégias de modelagem

CompreensívelProcesso de modelagem é um processo de aprendizagem


Capítulo 4: Abordagem relacional


Abordagem RelacionalAbordagem de modelagem de dados usada nos sistemas de gerência de banco de dados do tipo relacional;Composição de um banco de dados relacional:

TabelasCompostas de: linhas, colunas e chaves primárias

Relacionadas através de chaves estrangeirasTerminologias:

Profissional AcadêmicaTabela Relação

Linha Tupla

Coluna Atributo

Valor de campo Valor de atributo


Abordagem Relacional


Abordagem RelacionalCaracterísticas das tabelas:

As linhas de ma tabela não têm ordenaçãoValores de campo:

Atômicos o campo não pode ser composto de outrosMonovalorados o campo possui um único valor

Acesso por quaisquer critérios envolvendo os campos de uma ou mais linhas

Programadores escrevem consultas sem considerar a existência de caminhos de acessoCaminho de acesso:

estrutura auxiliar (índice, cadeia de ponteiros,...)acelera a recuperação de registros por determinados critériosevita a leitura exaustiva de todos registros de um arquivo

Banco de Dados 57

Abordagem RelacionalChave conceito usado para identificar e estabelecer relações entre linhas de tabelas de um banco de dados relacional.

Três tipos:Chave PrimáriaChave AlternativaChave Estrangeira

Chave Primária é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela.


Abordagem RelacionalChave Estrangeira Uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela

Mecanismo que permite a implementação de relacionamentos em um banco de dados relacional

Abordagem RelacionalRestrições que devem ser garantidas ao executar diversas operações de alteração do banco de dados:

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 referenciadaEx: Um novo empregado deve atuar em um departamento já

existente no banco de dados.

Quando da alteração do valor da chave estrangeira: o novo valor de uma chave estrangeira deve aparecer na coluna da chave primária referenciadaQuando 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ídaEx: Um departamento não pode ser excluído, caso nele ainda existirem

empregadosQuando 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 chave primária que está sendo alteradaEx: Caso um departamento possua empregados, seu código não pode ser

modificado


Abordagem RelacionalA palavra “estrangeira” pode levar a crer que a chave estrangeira sempre referencia uma chave primária de outra tabela.Esta restrição não existe.Um chave primária pode referenciar a chave primária da própria tabela.

61

Abordagem RelacionalChave Alternativa Mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais

Uma das colunas (ou combinação de colunas) é escolhida como chave primáriaAs demais colunas ou combinações são denominadas chaves alternativas


Abordagem RelacionalDomínio de coluna conjunto de valores que podem aparecer em uma coluna (atributo)Valor vazio:

Um valor de campo pode assumir o valor especial vazio (“null” em inglês)Colunas nas quais não são admitidos valores vazios são chamadas de colunas obrigatóriasColunas nas quais podem aparecer campos vazios são chamadas de colunas opcionaisAbordagem relacional:

todas colunas que compõem a chave primária devem ser obrigatóriasdemais chaves podem conter colunas opcionais


Abordagem RelacionalRestrições de Integridade:

Objetivo primordial de um SGBD é garantir a integridade de dadosDados refletem corretamente a realidade representada pelo bando de dados e que são consistentes entre si

Para garantir a integridade de um banco de dados, SGBD oferecem o mecanismo de restrições de integridadeUma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBDSão classificadas nas seguintes categorias:

Integridade de domínio o valor de um campo deve obedecer a definição de valores admitidos para a colunaIntegridade de vazio é especificado se os campos de uma coluna podem ou não ser vazios.


Abordagem RelacionalIntegridade de chave define que os valores da chave primária e alternativa devem ser únicosIntegridade referencial define que os valores que aparecem em uma chave estrangeira devem aparecer na chave primária da tabela referenciada

Restrições acima são garantidas automaticamente por um SGBD relacionalNão é exigido que o programador escreva procedimentos para garanti-las explicitamente

Restrições de integridade semânticas:Restrições de integridade que não se encaixam nas categorias básicasExemplos de restrições semânticas:

Um empregado do departamento denominado “Finanças” não pode ter a categoria funcional “Engenheiro”.

Um empregado não pode ter um salário maior que seu superior imediato.


Abordagem RelacionalModelo de banco de dados relacional

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:

Tabelas que formam o banco de dadosColunas que as tabelas possuemRestrições de integridade


Abordagem RelacionalEsquema textual de BD relacional


Abordagem RelacionalEsquema diagramático de BD relacional


Abordagem RelacionalConsulta sobre o banco de dados:

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.


Capítulo 5: Transformação entre

modelos

Banco de Dados 70

Transformação entre modelosDois processos de transformação de modelos:

Visão geral do projeto lógico:


Transformação entre modelosTransformação ER para relacional:

Objetivos básicos:Boa performance;Simplificar o desenvolvimento;Ocupar pouco espaço em disco;Evitar junções :

Operação para buscar dados de diversas linhas associadas pela igualdade de camposExemplo:

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 discoJunção envolve diversos acessos a discoPreferível: ter os dados necessários a uma consulta em uma única linha


Transformação entre modelosChave e índice:

Implementação eficiente do controle de chaves: SGBD usa um índice –Índices tendem a ocupar espaço considerável em discoInserção e remoção de entradas em um índice – Podem exigir diversos acesso a discoUsar implementações com menos chaves

Exemplo:Cliente (CodCliente,Nome,NomeContato,Endereço,Telefone)

ouCliente (CodCliente,Nome,NomeContato)ClienteEnder (CodCliente,Endereço,Telefone)CodCliente referencia Cliente


Transformação entre modelosCampos 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 vaziosCampo opcional não tem influência na performanceControle de campo opcional pode complicar programação – Verificar quais campos podem estar vazios, quando isto depende do tipo de linha

Passos da transformação ER para relacional:Tradução inicial de entidades e respectivos atributosTradução de relacionamentos e respectivos atributosTradução de generalizações/especializações


Transformação entre modelosImplementação inicial de entidades

Cada entidade é traduzida para uma tabela.Cada atributo da entidade define uma coluna desta tabela.Atributos identificadores da entidade correspondem a chave primária da tabela.Tradução inicial – Regras que seguem, as tabelas definidas nessa etapa ainda poderão ser fundidas.Ex:

Pessoacódigonomeendereço

Data admissão

Data nascimento

Pessoa (CodPess, Nome, Endereço, Data Nasc, DataAdm)


Transformação entre modelosNome de atributos e Nomes de Colunas:

Referenciados freqüentemente em programas e outras formas de texto em computadorPara diminuir o trabalho de programadores – manter os nomes de colunas curtos.SGBD relacional – nome de uma coluna não pode conter brancosNão transcrever os nomes de atributos para nomes de colunasNomes de atributos compostos de diversas palavras devem ser abreviadosNomes 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 ouNomePessoaSQL já exige muitas vezes formar - Pessoa.NomeChave primária – pode aparecer em outras tabelas na forma de chave estrangeiraRecomendá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áriaExemplo: CodigoPess


Transformação entre modelosImplementação de relacionamento

Alternativas:Tabela própriaAdição de colunas a uma das tabelasFusão de tabelas

Alternativa depende da cardinalidade (máxima e mínima do relacionamento)

Tabela própria

Engenheiro ProjetoAtuaçãon n

códigonome

função códigotítulo

Engenheiro (CodEng, Nome)Projeto (CodProj, Título)Atuação (CodEng, CodProj, Função)

CodEng referencia EngenheiroCodProj referencia Projeto


Transformação entre modelosAdição de colunas

Departamento EmpregadoLotação1 n

códigonome

data lotação códigonome

Departamento (CodDept, Nome)Empregado (CodEmp, Nome, CodDept, DataLota)

CodDept referencia Departamento

Fusão de tabelas

Conferência ComissãoOrganização1 1

códigonome

Data instalaçãoender

Conferência (CodConf, Nome, DataInstComOrg, EnderComOrg)


Transformação entre modelosImplementação de relacionamentos 1:1


Transformação entre modelos1:1 – Ambas entidades opcionais

Homem MulherCasamento(0,1) (0,1)

identidadenome

data identidadetítuloregime

Adição de colunas:Mulher (IdentM, Nome, IdentH, Data, Regime)

IdentH referencia HomemHomem (IdentH, Nome)

Tabela própria:Mulher (IdentM, Nome)Homem (IdentH, Nome)Casamento (IdentM, IdentH, Data, Regime)

IdentM referencia MulherIdentH referencia HomemFusão de Tabelas: (NÃO USAR)

Casamento (IdentM, IdentH, NomeM, NomeH, Data, Regime)


Transformação entre modelos1:1 – Ambas entidades opcionais

Solução por fusão de tabelas é inviável – Chave primária artificialSolução por adição de colunas: melhor opção

Menor número de junçõesMenor número de chaves

Solução por tabela própria: opção aceitável


Transformação entre modelos1:1 – Uma entidade opcional outra obrigatória

Correntista Cartão Magnético(1,1) (0,1)

códigonome

códigoData 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ãoFusão de Tabelas:Correntista (CodCorrent, Nome, CodCartão, DataExp)


Transformação entre modelos1:1 – Uma entidade opcional outra obrigatória

Solução por tabela própria é pior que a solução por adição de colunas

Maior número de junçõesMaior número de índicesNenhuma têm problema de campos opcionais

Adição de colunas versus fusão de tabelasFusão de tabelas é melhor em termos de número de junções e número de chavesAdição de colunas em melhor em termos de campos opcionaisFusão de tabelas é considerada a melhor opção e adição de colunas éaceitável


Transformação entre modelos1: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ódigonome

Data instalaçãoender

Nenhuma das demais alternativas atende plenamenteEntidades que participam do relacionamento seriam representadas através de duas tabelas distintasEstas tabelas teriam a mesma chave primária e relação um-para-um entre suas linhasMaior número de junçõesMaior número de chaves primárias


Transformação entre modelosImplementação de relacionamentos 1: n

Banco de Dados 85

Transformação entre modelos1:n – A entidade que tem cardinalidade máxima 1 é obrigatória

Departamento EmpregadoLotação(1,1) (0,n)

códigonome

data lotação códigonome

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 DepartamentoCodEmp referencia Empregado


Transformação entre modelos1:n – A entidade que tem cardinalidade máxima 1 é obrigatória

Fusão de tabelasNão se aplicaImplicaria em:

redundância de dados de departamento, outabela aninhada

Adição de colunas é melhor que tabela própria:Menor número de chavesMenor número de junçõesNão há o problema de campos opcionais

Banco de Dados 87

Transformação entre modelos1:n – A entidade que tem cardinalidade máxima 1 é opcional

Financeira VendaFinanciam(0,1) (0,n)

códigonome

taxa de juros iddata

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 VendaCodFin referencia Financeira

nº

deparcelas

Implementação por tabela própria também éaceitável:

É melhor em relação a campos opcionaisPerde em relação a junções e número de chaves


Transformação entre modelosImplementação de relacionamentos n : n

Banco de Dados 89

Transformação entre modelosn:n

Tabela própria:Engenheiro (CodEng, Nome)Projeto (CodProj, Título)Atuação (CodEng, CodProj, Função)

CodEng referencia EngenheiroCodProj referencia Projeto

Engenheiro ProjetoAtuação(0,n) (0,n)

códigonome

função códigotítulo

Banco de Dados 90

Transformação entre modelosRelacionamentos de grau maior que dois

Não são definidas regras específicasO relacionamento é transformado em uma entidade

Produto (CodProd, Nome)Cidade (CodCid, Nome)Distribuidor (CodDistr, Nome)Distribuição (CodProd, CodDistr, CodCid, DataInicio)

CodProd referencia ProdutoCodDistr referencia DistribuidorCodCid referencia Cidade

Banco de Dados 91

Transformação entre modelosImplementação de generalização / especialização

Duas alternativas básicas:uso de uma tabela para cada entidadeuso de uma única tabela para toda hierarquia

Outra alternativa (exótica): Subdivisão de entidade genérica

Banco de Dados 92


Uma tabela por hierarquia:Todas as tabelas referentes às especializações são fundidas em uma única tabelaTabela contém:

Chave primária correspondente ao identificador da entidade mais genéricaCaso não exista, adicionar uma coluna TipoUma coluna para cada atributo da entidade genéricaColunas 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éricaUma 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


Uma tabela por hierarquia:

Emp (CódigoEmp, Tipo, Nome, CIC, CodigoDept, CartHabil, CREA, CódigoRamo)

CódigoDept referencia DeptoCódigoRamo referencia Ramo

Depto (CódigoDept, Nome)Ramo (CódigoRamo, Nome)ProcessTexto (CódigoProc, Nome)Domínio (CódigoEmp, CódigoProc)

CódigoEmp referencia EmpCódigoProc referencia ProcessTexto

Projeto (CódigoProj, Nome)Participação (CódigoEmp, CodigoProj)

CódigoEmp referencia EmpCódigoProj referencia Projeto

Banco de Dados 94

Transformação entre modelosImplementação de generalização/especialização

Uma tabela por entidade especializada:

Criar uma tabela para cada entidade que compõe a hierarquiaIncluir 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 DeptoMotorista (CódigoEmp, CartHabil)

CódigoEmp referencia EmpEngenheiro (CódigoEmp, CREA,

CódigoRamo)CódigoEmp referencia EmpCódigoRamo referencia Ramo

Depto (CódigoDept, Nome)Ramo (CódigoRamo, Nome)ProcessTexto (CódigoProc, Nome)Domínio (CódigoEmp, CódigoProc)

CódigoEmp referencia EmpCódigo Proc referencia

ProcessTextoProjeto (CódigoProj, Nome)Participação (CódigoEmp, CódigoProj)

CódigoEmp referencia EngenheiroCódigoProj referencia Projeto



Vantagens da implementação com tabela única:Dados referentes à entidade genérica + dados referentes às especializações – em uma única linhaMinimiza junçõesMenor número de chaves

Vantagens da implementação com uma tabela por entidade especializada:

Colunas opcionais – apenas aquelas referentes a atributos que podem ser vazios do ponto de vista da aplicação


Transformação entre modelosRefinamento do modelo relacional

Projeto (engenharia) em geral – compromisso entre o ideal e o realizável dentro das restrições de recursos impostas pelas práticaProjeto de banco de dados – compromisso entre o ideal (regras de implementação) e o alcançável frente a limitações de performanceAlgumas vezes – esquema de BD criado através do uso das regras acima não atende requisitos de performance impostos ao sistemaNecessário buscar alternativa que resulte em melhor performance do sistemaAlternativas somente devem ser tentadas em último caso - do ponto de vista da programação são sempre pioresExemplos: Relacionamentos mutuamente exclusivos e Simulação de atributos multivalorados


Transformação entre modelosRelacionamentos mutuamente exclusivos:

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 PessFisCGC referencia PessJur

colunas CIC e CGC em Venda são especificadas como opcionais


Transformação entre modelosRelacionamentos mutuamente exclusivos:

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)

Desvantagem:Não é possível especificar ao SGBD que o campo CIC/CGC é chave estrangeiraNão referencia uma única tabela


Transformação entre modelosTratamento de atributos multivalorados:

Cliente (CodCli, Nome)Telefone (CodCli, Número)

CodCli referencia Cliente

Condições de contorno:Raros clientes possuem mais que dois telefones.Quando isso ocorrer: é suficiente armazenarmos apenas dois númerosNão há consultas ao banco de dados usando o número de telefone como critério de seleçãoNúmeros de telefone são apenas exibidos ou impressos juntos às demais informações de cliente


Transformação entre modelosTratamento de atributos multivalorados:

Implementação “desnormalizada”

Cliente (CodCli,Nome,NumTel1,NumTel2)

Simular uma coluna multi-valorada através da criação de diversas colunas NumTel sufixadas por um númeroPermite que os telefones de um cliente sejam obtidos mais rapidamenteImplica em menos espaço ocupado – não é necessária chave primária da tabela TelefoneInconveniente

Consulta usando o número de telefone como critério de busca torna-se mais complicadaManter os telefones "alinhados à esquerda" exige rotina complexa


Transformação entre modelosEngenharia reversa de modelos relacionais:

Parte de modelo de implementaçãoObtém modelo de especificação (modelo conceitual)Passos:

Identificação da construção ER correspondente a cada tabelaDefinição de relacionamentos 1:n e 1:1Definição de atributosDefinição de identificadores de entidades e relacionamentos


Transformação entre modelosEx:

Disciplina (CodDisc, NomeDisc)Curso (CodCr, NomeCr)Curric (CodCr, CodDisc, Obr/Opc)

CodCr referencia CursoCodDisc 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 modelosIdentificação da construção ER correspondente a cada tabela

Uma tabela pode corresponder a:uma entidadeum relacionamento n:numa entidade especializada

Fator determinantecomposição de sua chave primária


Transformação entre modelosEx:

Disciplina (CodDisc, NomeDisc) entidadeCurso (CodCr, NomeCr) entidadeCurric (CodCr, CodDisc, Obr/Opc) relacionamento n:n

CodCr referencia CursoCodDisc referencia Disciplina

Sala (CodPr, CodSl, Capacidade) entidadeCodPr referencia Prédio

Prédio (CodPr, Endereço) entidadeTurma (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


Transformação entre modelosConstruções identificadas:

Turma

Prédio

Sala

Laboratório

Curso

Disciplina

Currículo

n

n


Transformação entre modelosIdentificação de relacionamentos 1:n ou 1:1

Chave estrangeira que não se enquadra nas regras acima – representa relacionamento 1:n ou relacionamento 1:1Esquema não informa se é 1:1 ou 1:nChave estrangeira é parte de uma chave primária trata-se de um relacionamento 1:nNos 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 modelosConstruções identificadas:

Turma

Prédio

Sala

Laboratório

Curso

Disciplina

CurrículoCurrículo

Currículo

Currículo

n

n

1nn

1

n

1

108

Transformação entre modelosDefinição de atributos:

Cada coluna não chave estrangeira é um atributo na entidade/relacionamento correspondente à tabelaAs colunas chave estrangeira não correspondem a atributos correspondem a relacionamentos

Definição de identificadores de entidades:

Coluna da chave primária que não é chave estrangeira corresponde a um atributo identificador da entidade ou relacionamento.Coluna da chave primária que échave estrangeira corresponde a um relacionamento identificador da entidade


Capítulo 6: Normalização


NormalizaçãoSistemas de informação hoje usados não utilizam bancos de dados relacionais – Sistemas legados (dados armazenados em arquivos de linguagens de 3ª geração).Raramente documentados.Necessidade de modelo ER:

ManutençãoMigração para outro tipo de BDIntegração com outros BD


Normalização


NormalizaçãoObjetivo:

Reagrupar informações para eliminar redundâncias de dadosReagrupar informações para eliminar estruturas inexistentes no modelo ER (atributos multivalorados)

Passos:

113

NormalizaçãoDocumento 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çãoRepresentação na forma de tabela não normalizada:

Tabela não-normalizada ou tabela não-primeira-forma-normalpossui uma ou mais tabelas aninhadastabela 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 aninhadasAbreviatura: ÑNExemplo:

Proj (CodProj,Tipo, Descr,(CodEmp, Nome, Cat, Sal, DataIni, TempAl))


NormalizaçãoForma Normal:

Regra que uma tabela deve obedecer para ser considerada “bem projetada”Há diversas formas normais, cada vez mais rígidas, para verificar tabelas relacionaisAqui tratadas:

primeira forma normal (1FN)segunda forma normal (2FN)terceira forma normal (3FN)


NormalizaçãoPassagem à primeira forma normal (1FN)

Alternativas:Uma única tabela

Uma tabela na qual os dados das linhas externas à tabela aninhada são repetidos para cada linha da tabela aninhadaExemplo:

ProjEmp (CodProj, Tipo, Descr, CodEmp, Nome, Cat, Sal, DataIni, TempAl)Dados do projeto aparecem repetidos para cada empregado do projeto


NormalizaçãoUma tabela para cada tabela aninhada

Cria-se uma tabela referente a própria tabela que está sendo normalizada e uma tabela para cada tabela aninhadaExemplo:

Proj (CodProj, Tipo, Descr)ProjEmp (CodProj,CodEmp, Nome, Cat, Sal, DataIni, TempAl)

Primeira alternativa (tabela única) é mais corretaDecompor uma tabela em várias tabelas (segunda alternativa) –podem ser perdidas relações entre informaçõesPara fins práticos – preferimos a segunda alternativa (decomposição de tabelas)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


NormalizaçãoPasso 1:

Criar uma tabela na 1FN referente a tabela não normalizadaA chave primária da tabela na 1FN é idêntica a chave da tabela ÑN

Criar tabela referente a tabela ÑN



Para cada tabela aninhada criar uma tabela na 1FN composta pelasseguintes colunas:

a chave primária de cada uma das tabelas na qual a tabela em questão estáaninhadaas colunas da própria tabela aninhada

Criar tabela referente a tabela aninhada



Definir as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas.

Definição da chave primária


Normalização

NormalizaçãoExemplo na 1FN:

CodProj Tipo DescrLSC001 Novo Desenvol. Sistema

PAG02 Manutenção Sistema de RH

CodProj CodEmp Nome Cat Sal DataIni TempAlLSC001 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


NormalizaçãoDependência Funcional:

Para entender 2FN e 3FN – é 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 linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2.

124

NormalizaçãoSegunda forma normal 2FN:

Objetiva eliminar um certo tipo de redundância de dadosExemplo:

(CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)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 TempAlLSC001 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


Dependências parciais

Dependências não parciais

126


Tabela 1FN e que possui apenas uma coluna como chave primária –não contém dependências parciaisÉ impossível uma coluna depender de uma parte da chave primária, quando a chave primária não é composta por partesConclusão – Toda tabela 1FN que possui apenas uma coluna como chave primária já está na 2FN

127


Tabela que contenha apenas colunas chave primáriaImpossível atributo não chave depender de parte da chave (tabela não tem colunas não chave)Tabela sem colunas não chave já está na 2FN

128


130

NormalizaçãoTerceira forma normal 3FN:

Trata de um outro tipo de redundânciaExemplo: Emp (CodEmp, Nome, Cat, Sal)Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat)Salário que é pago a uma categoria funcional é armazenado tantas vezes quantos empregados possui a categoria funcional

131


Trata de um outro tipo de redundânciaExemplo: Emp (CodEmp, Nome, Cat, Sal)Considerar: – salário (coluna Sal) é determinado pela categoria funcional (coluna Cat)Salário que é pago a uma categoria funcional é armazenado tantas vezes quantos empregados possui a categoria funcional



Proj (CodProj, Tipo, Descr)ProjEmp (CodProj, CodEmp, DataIni, TempAl)Emp (CodEmp, Nome, Cat)Cat (Cat, Sal)


NormalizaçãoNormalização do exemplo:

ÑNProj (CodProj,Tipo, Descr,(CodEmp, Nome, Cat, Sal, DataIni, TempAl))

1FNProj (CodProj, Tipo, Descr)ProjEmp (CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)

2FNProj (CodProj, Tipo, Descr)ProjEmp (CodProj, CodEmp, DataIni, TempAl)Emp (CodEmp, Nome, Cat, Sal)

3FNProj (CodProj, Tipo, Descr)ProjEmp (CodProj, CodEmp, DataIni, TempAl)Emp (CodEmp, Nome, Cat)Cat (Cat, Sal)


NormalizaçãoTabelas na 3FN:

NormalizaçãoProblemas de normalização:

Chaves primárias omitidas ou incorretasArquivos convencionais:

o conceito de chave primária não é obrigatórioé possível encontrar arquivos que não possuem chave primária

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 arquivodeve-se inseri-la na forma ÑN

Arquivo com dados sobre empregados de uma organização enviado para fins de fiscalização a um órgão governamentalIdentificador de empregado usado na organização é omitido, já que este éirrelevante para o órgão fiscalizadorOutra situação: uso de uma chave alternativa, ao invés da chave primária usual do arquivoNo 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.



Atributos relevantes implicitamente representadosArquivos convencionais podem conter atributos de forma implícita

ordenação de registros ou de listasponteiros físicos, etc

Deve-se proceder como se o atributo aparecesse explicitamente no documentoExemplo:

arquivo contém registros referentes a cursos em um concurso vestibularpara cada curso, há um grupo repetido aninhado, com as informações dos candidatos ao curso em questãoinformações dos candidatos ordenadas por classificação no concurso



Atributos irrelevantes, redundantes ou derivadosDevem ser eliminados já quando da passagem a forma não normalizada


Capítulo 7: SQL


Criação de Banco de Dados

Conjunto de objetos que armazenam e manipulam dados.Como nomear arquivos e objetos:

Regras para nomeação dos objetos:Caracteres A...Z, a...z, 0...9, $ e _Nomes devem começar com A...Z ou a...z.Nomes limitados a 31 caracteres.Nomes dos objetos devem ser únicos.

CREATE DATABASE ‘C:\Banco de Dados\empresa.fdb’;

Criação de TabelasRestrições a serem especificadas para uma coluna de tabela:

Regras que governam os relacionamentos e validam entradas de dados.Atuam em todas as transações que acessam o banco de dados e são automaticamente mantidas pelo sistema.Restrição UNIQUE e PRIMARY KEY:

Asseguram que os valores inseridos em uma ou mais colunas são únicos para cada linha da tabela.Uma ou mais colunas definidas com essas restrições devem também ser definidas com o atributo NOT NULL.

Restrição FOREIGN KEY: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.

Restrição CHECK:Estabelece uma condição que deve ser verdadeira durante uma entrada ou atualização de dados na tabela.

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.


Criação de Tabelas

CREATE TABLE cria uma nova tabela, suas colunas e restrições de integridade em um banco de dados.

Tabela FabricaCREATE 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));


Criação de Tabelas

Tabela ProdutoCREATE 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));


Alteração de Tabelas

ALTER TABLE modifica uma tabela adicionando, modificando ou eliminando colunas ou restrições.Para alterar uma tabela, deve-se observar o seguinte:

Uma tabela pode ser alterada por seu criador ou qualquer usuário com direitos de superusuário do sistema operacional.ALTER TABLE provoca erro se os novos dados em uma tabela violam as definições de restrição PRIMARY KEY ou UNIQUE.Eliminar uma coluna provoca falha se:

A coluna é parte de uma restrição UNIQUE, PRIMARY KEY ou FOREING KEY.A coluna é usada em uma restrição CHECK.A coluna é utilizada em uma expressão value de uma coluna calculada.A coluna é referenciada por outros objetos, tais como uma visão.



Exemplos de utilização de ALTER TABLE:Incluir nova coluna

ALTER TABLE Fabrica ADD Email VARCHAR(30);

ALTER TABLE FabricaADD Contato VARCHAR(30) NOT NULL,ADD Fax VARCHAR(18);

Eliminar uma coluna existenteALTER TABLE Fabrica DROP Fax;

Alterar a posição de uma colunaALTER TABLE Produto ALTER Id_ProdutoC POSITION 5;



Exemplos de utilização de ALTER TABLE:Alterar o tipo de dado de uma coluna

ALTER TABLE Fabrica ALTER Email TYPE VARCHAR(40);Obs: Tamanhos de tipos não podem ser reduzidos e o novo tipo de dado deve ser capaz de manter os dados originais.

Alterar o nome da colunaALTER TABLE Fabrica ALTER Nome TO RazaoSocial;

Adicionar uma nova restriçãoALTER TABLE Fabrica ADD CONSTRAINT Un_Mail UNIQUE (Email);

Eliminar uma restrição existenteALTER TABLE Fabrica DROP CONSTRAINT Un_Mail;


Exclusão de Tabelas

A instrução DROP TABLE remove dados de tabela.Não se pode eliminar uma tabela que é referenciada em uma coluna calculada, uma visão, restrição de chave estrangeira ou procedimento armazenado. DROP TABLE [nome da tabela]


Povoamento de Tabelas

INSERT armazena uma ou mais linhas de dados em uma tabela.Os valores inseridos devem estar na mesma ordem das colunas da tabela.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.Para inserir uma única linha de dados na tabela, deve-se especificar uma lista de valores na cláusula VALUES.Inserções de dados nas tabelas não podem violar as restrições.É importante inserir dados primeiramente nas tabelas referenciadas por chaves estrangeiras.



Exemplos:INSERT INTO Vendedor VALUES (1, ‘João Dias’);

A instrução seguinte insere uma linha na mesma tabela, mas informa explicitamente as colunas para as quais serão informados:

INSERT INTO Vendedor (Id_Vendedor, Nome)VALUES (2, ‘Fábio Almeida’);

INSERT INTO Cliente VALUES (1, ‘Francisco de Assis’, ‘Av. Principal, 500’, ‘Santarém’, ‘PA’, ‘3522-0101’, ‘Francisco’);


INSERT INTO Transportadora VALUES (1, ‘Transpedroso’, ‘Av. Getúlio Vargas, 500’, ‘São Paulo’, ‘SP’);

INSERT INTO Pedido VALUES (1, ’06/15/2005’, 500, 1, 1, 1);O campo data é inserido no formato mm/dd/aaaa

INSERT INTO Fabrica (Id_Fabrica, RazaoSocial, UF)VALUES (1, ’CAP Computadores Ltda’, ‘SP’);

INSERT INTO Produto VALUES (1, null, 'Microcomputador', 'UN', null, 1);

As colunas Referencia e Id_ProdutoC da tabela Produto permitem valores nulos e esta é uma maneira de inserir nulos.A outra é a maneira como foi inserida a linha na tabela Fabrica. Omitiram-se as colunas que receberão valores nulos.


Alteração de dados

A instrução UPDATE modifica os dados em toda ou parte de uma linha de uma tabela.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.Se a cláusula WHERE não for utilizada, todas as linhas da tabela serão atualizadas.O seguinte comando modifica as linhas da tabela. Esse comando calcula um novo preço para todos os produtos, reajustando-os em 5%:

UPDATE ProdutoCond SET Preco = Preco * 1.05;


Alteração de dados

O comando a seguir modifica apenas uma linha da tabela. Modificaa descrição do produto que tem chave primária igual a 2:

UPDATE Produto SET Descricao = ‘Monitor de vídeo 15”’WHERE Id_Produto = 2;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.

UPDATE Pedido SET Id_Transportadora = 1, Id_Vendedor = 2 WHERE Data = ’06/15/2005’;

O comando acima modifica dados de duas colunas dos pedidos efetuados em 15/06/2005.


Exclusão de linhas

O comando DELETE elimina linhas de uma tabela.Especifica uma ou mais linhas a serem eliminadas de uma tabela.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.Se a cláusula WHERE não for especificada, todas as linhas da tabela são eliminadas.O comando a seguir deleta todas as linhas da tabela:

DELETE FROM ProdutoPedido;A exclusão de linhas de uma tabela não pode violar as restrições de chave estrangeira.Se não, devem ser excluídas inicialmente as linhas da tabela filha (a tabela que tem a chave estrangeira).O comando seguinte elimina linhas específicas de uma tabela:

DELETE FROM ProdutoPedido WHERE Id_Pedido = 1;


Consultas a dados de uma tabela

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.O comando SELECT é o comando SQL utilizado para recuperar informações de bancos de dados.Operadores:

A cláusula WHERE utiliza expressões que limitam as linhas da tabela aserem recuperadas.Dessas expressões fazem parte os operadores que podem ser classificados em quatro categorias:

AritméticosLógicosDe comparaçãoDe concatenação



Aritméticos:+ Adição-

Subtração

* Multiplicação/ Divisão

Lógicos:AND EOR OuNOT Não

De concatenação:|| Concatenação de

strings

De comparação:< Menor que> Maior que<= Menor ou igual a>=

Maior ou igual a

=

Igual<>

Diferente

BETWEEN

EntreIN

Em

IS

ÉLIKE

Igual a



Consultas simples:SELECT * FROM CLIENTE;

Esse comando recupera todas as linhas e colunas da tabela CLIENTE. O asterisco (*) indica que todas as colunas são mostradas.

Se for desejado recuperar colunas específicas da tabela, um exemplo seria:

SELECT NOME, CONTATO, TELEFONE FROM CLIENTE;

É possível também, nas consultas, que os nomes originais das colunas sejam modificados.

SELECT ID_FABRICA AS ID, RAZAOSOCIAL AS "RAZÃO SOCIAL“FROM FABRICA;A cláusula AS permite que as colunas recebam um apelido.



A cláusula AS permite que as colunas recebam um apelido.Se o apelido possuir espaços deve-se defini-lo entre aspas.A cláusula AS é opcional.O comando no formato a seguir produz o mesmo resultado:

SELECT ID_FABRICA ID, RAZAOSOCIAL "RAZÃO SOCIAL“ FROM FABRICA;

As colunas de consultas podem incluir expressões aritméticas.SELECT ID_PRODUTO, ID_CONDICAO, PRECO * 1.05 FROM PRODUTOCOND;Esta consulta mostra os preços dos produtos com seus valores reajustados em 5%.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;



A consulta seguinte utiliza o operador de concatenação:SELECT NOME, ENDERECO, CIDADE || '-' || UF "CIDADE-ESTADO" FROM CLIENTE;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 (-). Foi atribuído um apelido à coluna resultante do cálculo.

A cláusula DISTINCT é utilizada para suprimir linhas duplicadas do resultado de uma coluna.

SELECT CIDADE FROM CLIENTE;O comando acima poderia retornar linhas duplicadas.Para eliminar as duplicações utiliza-se DISTINCT:

SELECT DISTINCT CIDADE FROM CLIENTE;



Uso da cláusula WHERE: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.

Com operadores de Comparação: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’.

SELECT ID_PEDIDO, VALOR, ID_CLIENTE FROM PEDIDOWHERE DATA > '06/15/2005';

Essa consulta mostra os pedidos cuja DATA seja maior que 15/06/2005.



SELECT ID_CLIENTE, NOME FROM CLIENTEWHERE NOME LIKE 'A%';

O operador LIKE recupera da tabela os clientes que têm o nome iniciando com a letra A.

SELECT * FROM PEDIDOWHERE 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.

SELECT ID_FABRICA, RAZAOSOCIAL FROM FABRICAWHERE 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.



Com operadores Lógicos:SELECT * FROM CLIENTE WHERE NOT UF = 'PA';

Mostra os clientes que não são do estado do Pará.

SELECT * FROM PEDIDO WHERE VALOR NOT BETWEEN 200 AND 700;

Retorna os pedidos cujos valores não estão entre 200 e 700.

SELECT * FROM CLIENTE WHERE NOME NOT LIKE 'D%';Recupera os clientes cujos nomes não iniciam com a letra D.

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.



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.

Uso da cláusula ORDER BY:Como padrão, uma consulta recupera linhas na mesma ordem em que ela as encontra na tabela.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.

SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE;SELECT ID_FABRICA, RAZAOSOCIAL, CIDADE FROM FABRICA ORDER BY CIDADE DESC, RAZAOSOCIAL;



Uso de funções:AVG

SELECT AVG(VALOR) FROM PEDIDO;Calcula a média dos valores numéricos em uma coluna.

COUNTSELECT COUNT(*) FROM CLIENTE;

Calcula o número de linhas que satisfazem uma condição de seleção de uma consulta.

MAXSELECT MAX(VALOR) FROM PEDIDO;

Recupera o valor máximo de uma coluna.

MINSELECT MIN(VALOR) FROM PEDIDO;

Recupera o valor mínimo de uma coluna.



Agrupamento de linhas com GROUP BY:Habilita uma consulta retornar um resumo sobre grupos de linhas que compartilham valores de coluna.

SELECT ID_CLIENTE, AVG(VALOR) FROM PEDIDO GROUP BY ID_CLIENTE;

O exemplo retorna o valor médio dos pedidos de cada cliente.A cláusula GROUP BY garante que o valor médio dos pedidos seja calculado e recuperado com base no identificados de cada cliente.


Relacionamento entre tabelas

Devido ao Firebird se tratar de um banco de dados relacional, àsvezes pode ser necessário construir consultas a dados que estãoem tabelas diferentes.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 bwhere

a.ID_CLIENTE = b.ID_CLIENTE and

a.DATA >= '06/25/2006';Observa-se neste exemplo o uso do alias de uma tabela.Um alias, ou apelido, é uma variável temporária que representa o nome da tabela.

Apostila Banco de Dados 2008-1

Documents

Transcript of Apostila Banco de Dados 2008-1