December 20, 2016 | Author: Estevao Magro | Category: N/A
BD TEMP Componentes
Componentes de um sistema de Banco de Dados
1. 2. 3. 4.
Dados Hardware Software Usuários
Sistema de Banco de Dados: Definição: Sistema de manutenção de registros por computador - ou seja, um sistema cujo objetivo global é manter as informações e torná-las disponíveis quando solicitadas. Num sistema grande, dados dos bancos de dados são integrados e compartilhados.
Integração: o Por integrado, pode-se dizer que os Bancos de Dados podem ser imaginados como a unificação de diversos arquivos de dados que, de outra forma, seriam distintos, eliminando-se total ou parcialmente qualquer redundância entre os mesmos. o Exemplo: Quando um funcionário é contratado pela Universidade, é criado um cadastro com todos os seus dados. Se ele for aluno também, e tiver um cadastro à parte, teremos uma redundância de informações.
Compartilhamento: o Por compartilhado, pode-se dizer que parcelas de dados podem ser compartilhadas por diversos usuários num BD, no sentido de que todos os usuários podem ter acesso a mesma parcela de dados (e podem usá-los com finalidades diferentes) e isto pode ser feito concorrentemente o Exemplo: No exemplo acima, os mesmos dados de um funcionário poderia ser ao mesmo tempo, requisitado por vários setores ao mesmo tempo: Pessoal, Financeiro e Acadêmico. Imagine o impacto que pode ter se um deles estiver alterando os dados.
Dados
O que é um dado? o Representação da informação que pode estar registrada em papel, quadro de aviso ou num HD. o Fatos fornecidos que descrevem uma característica de um objeto ou evento do mundo real. o Elemento que mantém a sua forma bruta (texto, imagens, sons, vídeos, etc.), ou seja, sozinho não leva a compreender determinada situação. o Exemplos: Nome de um empregado
Número de horas trabalhadas Número peças em estoque Pedidos de venda Cor e peso da fruta Autonomia e carga da bateria Número de cômodos e área do apartamento Etc.
Informação: o Informação é este mesmo dado, porém, trabalhado, lapidado, contextualizado, ou seja, informação é o dado, cuja forma e conteúdo são apropriados para um uso específico. o Exemplos: Total de vendas mensais Lista de clientes ordenada por total comprado Média de alunos por turma Turmas com menos 10 alunos Peso total da grade de frutas Tempo de vida da bateria Preço final do apartamento Etc.
Processo: o Série de tarefas logicamente relacionadas, executadas para atingir um resultado definido. o Exemplos: Ordenação dos alunos pelo número de matricula Restauração das tabelas Verificação de integridade dos dados Disparo de uma ação de alarme Etc.
Conhecimento: o Regras, diretrizes e procedimentos usados para selecionar, organizar e manipular dados, para torná-los mais úteis para determinado fim. o Exemplos: Backup diário numa janela de 0 a 3 horas da manhã Seleção dos registros de duas tabelas filtrando dados específicos Disparo de uma ação quando o saldo ficar negativo Etc.
Hardware
Composto de toda infraestrutura necessária para manter as unidades de armazenamento. Envolve principalmente unidades de disco de cabeça móvel com algumas características específicas: o Tempo de posicionamento - seek time o Retardo rotacional o Cilindro, trilha
o Cabeça de leitura/gravação Complementado com dispositivos de backup como robôs Expandido no conceito de cluster e nuvem o Cluster: Sistema que compreende dois ou mais computadores ou sistemas que trabalham em conjunto para executar aplicações ou realizar outras tarefas. Tem como características básicas confiança, distribuição de carga e desempenho. o Nuvem: A ideia central dessa arquitetura é prover uma ampla replicação de dados, distribuindo-os entre milhares e milhares de servidores, minimizando assim os aspectos de desempenho, e principalmente, de disponibilidade. Essa proposta quebra parte paradigma tradicional de centralização de dados, transações e de storage. Assim, foi desenhado um novo modelo de sistemas de armazenamento que atende ao objetivo de estender a disponibilidade. O conceito fundamental de ACID (atomicidade, consistência, isolamento e durabilidade) teve que ser revisto de forma a ajustar a esse novo cenário. Um dos grandes desafios do hardware do sistema de banco de dados é minimizar o número de acessos a disco (entradas/saídas de disco) Outro ponto que onera o hardware de um sistema de banco de dados é a necessidade de: o Segurança: Preservação do acesso físico e virtual o Backup: Frequentes rotinas de cópias de dados o Redundância: Duplicação das estruturas de armazenamento.
Software
Entre o banco de dados físico (dados armazenados) e os usuários do sistema encontra-se o software Gerenciador de Banco de Dados, SGBD ou DBMS. Todas as solicitações dos usuários de acesso ao banco de dados são manipuladas pelo SGBD Recursos providos pelo SGBD: o Criação de tabelas o Inserção de dados o Recuperação de dados o Etc. Função relevante: isolar os usuários do Bancos de Dados dos detalhes a nível de hardware fazendo com que os usuários do SGBD tenham uma visão acima do nível mais elevado que não exija conhecimentos técnicos aprofundados.
Profissionais
Projetistas de BD Lógico: Profissionais com habilidade suficiente para interpretar as necessidades de armazenamento de dados e criar os modelos de bancos de dados utilizados pelo projetista para sua criação
Projetistas de BD Físico: Especialistas na técnica de criar estruturas físicas envolvendo hardware, software e processos que permita armazenar grandes bases de dados e operá-las por meio de mecanismos eficientes como discos, robôs, rotinas, fitas e demais aparelhos componentes do sistema como um todo.
Implementadores de BD: Responsáveis por receber o modelo (projeto) do Banco de Dados e torná-lo real com a utilização de uma ferramenta (software)
Programadores de aplicações: responsável pela definição dos programas de aplicação que usam o banco de dados usando linguagens como Java, DotNet, PHP, etc. Estes programas podem ser executados de forma online ou ainda processamento em batch
Usuários finais: Interage com o sistema a partir de um equipamento acessando instantaneamente o BD por meio de uma das aplicações desenvolvidas para esse fim ou alguma interface integrante do sistema, por exemplo, o padrão SQL.
Administradores de BD ou DBAs: Profissional com alto nível de capacitação técnica que tem a responsabilidade central sobre os dados operacionais.
Banco de Dados
Modelo Arcaico: o Kardex, Arquivo: Um conjunto de fichas que registravam os dados de objetos ou eventos. o Normalmente em papel e dispostos segundo uma tabela com linhas e colunas numeradas com uma etiqueta na parte superior visível o Ordenação: Alfabética ou numérica, na parte externa do armário e internamente por pastas com etiquetas. o Infraestrutura: Armário de ferro ou de madeira, com gavetas que mantinham as pastas suspensas por meio de guias.
Modelo antigo: o Rotinas de tratamento de arquivos no próprio código o Fatores inconvenientes [Alves, William Pereira]: Ausência de controle de acesso concorrente de vários usuários Impossibilidade de se executar mais de um processo ao mesmo tempo num arquivo de dados A definição da estrutura de do arquivo armazenada no próprio código do aplicativo Inconsistência, redundância, dificuldade de acesso e isolamento dos dados. Segurança dos dados Duplicidade de informações entre os vários arquivos Aplicação dependente dos dados Incompatibilidade dos formatos de arquivos.
Modelo Atual: o SGBDs mantidos em discos com enorme capacidade o Formato eletrônico organizados em tabelas com associações entre elas de alto desempenho o Ordenação: Baseada em chaves para fácil localização e recuperação no padrão SQL o Infraestrutura: Centralizada e mantida normalmente em estruturas cliente-servidor ou na nuvem
o
Características: Aplicativos não tem nenhum conhecimento dos detalhes relativos aos métodos de gravação e leitura física dos dados nas tabelas Diversos programas podem acessar um mesmo BD SGBD oferece alta produtividade no desenvolvimento e manutenção dos softwares aplicativos Qualidade dos Softwares se tornou maior Informações extraídas se tornaram mais confiáveis e com maior credibilidade
Modelos em expansão: o Distribuído o NoSQL o Semânticos o ...
Banco de Dados: Conjunto de dados relacionados entre si armazenados segundo uma determinada lógica de forma que possam ser recuperados quando necessário. Possui três características básicas [Alves, William]:
1. Um BD representa uma porção do mundo real (minimundo) => interação com o mundo real 2. Um BD é um conjunto lógico e ordenado de dados que possuem algum significado => fonte de informação 3. UM BD é construído e povoado com dados que têm um determinado objetivo, com usuários e aplicações desenvolvidas para manipulá-los=> público que demonstra interesse nos dados.
Porte de um BD: o Pode ser pequeno, médio ou grande. o Independente do tamanho deve ser confiável, eficiente e acessível. o Exemplos de porte de banco de dados: Banco: com abrangência nacional => grande porte Biblioteca de uma escola => médio porte Base de conhecimento local => pequeno porte Vídeos no youtube => grande porte Etc.
SGBD
Um Sistema Gerenciador de Banco de Dados é uma coleção de programas que permite aos usuários criar e manter um banco de dados
É um sistema de software de uso geral que facilita o processo de definição, construção, manipulação e compartilhamento de bancos de dados entre diversos usuários e aplicações. o Definir um banco de dados envolve especificar os tipos, estruturas e restrições dos dados a serem armazenados cuja informação descritiva pode ser mantida em dicionários ou catálogos chamados de metadados.
o o
o
A construção do banco de dados é o processo de armazenar os dados em algum meio controlado pelo SGBD A manipulação de um banco de dados inclui funções como consulta ao banco de dados para recuperar dados específicos, atualização de dados e geração de relatórios ou consultas. O compartilhamento de um banco de dados permite que diversos usuários e programas acessem-no simultaneamente
Além dessas funções, um SGBD permite: o Criação de consultas com base em padrões pré-definidos o Controle e geração de transações fazendo com que dados sejam lidos ou gravados no banco de dados o Proteção do sistema contra defeitos (ou falhas) de hardware ou software o Controle e proteção de segurança contra acesso não autorizado ou malicioso o Escalabilidade, ou seja, capacidade de evoluir e crescer de acordo com as demandas. o Controle de redundância evitando replicações de dados e estruturas o Garantia de restrições de integridade o Backup e recuperação de dados.
Passos para a criação de um BD o Especificação o Análise de requisitos o Projeto Conceitual o Projeto Lógico o Projeto Físico
Arquiteturas: o Cliente-Servidor o Distribuída o Móvel o ...
Soluções disponíveis: o Interbase o MySQL o Access o Oracle o PostgreSQL o Firebird o Informix o HSQLDB o IBM DB2 o mSQL o SQL Server o TinySQL o JADE o ZODB o Sybase
o o
Visual Foxpro Etc.
O que se espera de um BD?
1. Permitir aos usuários a criação de novas bases de dados e especificação de seus esquemas (estrutura lógica de dados) usando uma DDL (data-definition language) 2. Dar aos usuários a habilidade para consulta aos dados e modificá-los usando uma linguagem apropriada normalmente chamada de DML (data-manipulation language) 3. Suportar o armazenamento de grandes quantidades de dados (terabytes ou mais) por um longo período de tempo com acesso eficiente 4. Habilitar a durabilidade, a recuperação do banco de dados face a falhas, erros de vários tipos ou mal uso intencional 5. Controlar o acesso de muitos usuários simultâneos sem permitir interações inesperadas (isolamento) e sem ações sobre os dados que sejam executadas parcialmente mas não completamente (atomicidade)
Classificação de Bancos de Dados
Quanto ao Modelos de dados Hierárquico
Primeiro tipo de banco de dados Conceito fundamental: registro e relacionamento pai-filho
Nesse modelo de dados, os dados são estruturados em hierarquias. Os registros possuem sub-registros e assim sucessivamente, formando uma ramificação semelhante a uma árvore. Dois registros são unidos por um elo, um é ascendente e outro é descendente. Um ascendente pode ter vários descendentes, mas cada descendente tem apenas um ascendente direto. As raízes são os únicos registros que não possuem “PAI” e nenhum nível de ascendente pode faltar
Registro: o Coleção de valores que representam informações sobre uma dada entidade de um relacionamento
Relacionamento Pai-Filho: o Um tipo de registro do lado Pai pode se corresponder com vários (ou nenhum) tipos de registros do lado Filho
Uma ligação é uma associação entre dois registros
O relacionamento entre um registro-pai e vários registros-filhos possui cardinalidade 1:N
Os dados organizados segundo este modelo podem ser acessados segundo uma sequencia hierárquica com uma navegação do topo para as folhas e da esquerda para direita
Um registro pode estar associado a vários registros diferentes, desde que seja replicado.
A replicação possui duas grandes desvantagens: o Pode causar inconsistência de dados quando houver atualização o O desperdício de espaço é inevitável.
Exemplos: Um banco de Dados hierárquico representando cliente... o Nome, Rua e Cidade. o Número da Conta e Saldo Onde cada cliente tem uma conta
Propriedades:
1. Um tipo de registro que não possui um tipo de registro pai é denominado raiz 2. Com exceção do tipo de registro raiz, todos os demais correspondem a tipos de registros filho dentro de um único tipo de relacionamento. 3. Um tipo de registro pai pode aparecer em qualquer número de relacionamentos 4. Um tipo de registro filho, que não possui descendentes é denominado folha.
IMS - Information Management System: 1o. Banco de dados hierárquico conhecido. Desenvolvido pela IBM e Rockwell International.
Considerações sobre BD hierárquico: o Pode ser mapeado à partir de um diagrama Entidade Relacionamento o Consultas complexas o O modelo impõe restrições à descrição do mundo real atual o Requer boas noções para a estruturação dos dados o O modelo hierárquico é fortemente dependente da implementação.
Problemas: o Complexidade dos diagramas de estrutura de árvore o Não pode haver ciclos no gráfico básico de um diagrama de estrutura de árvore o Restrições à cardinalidade dos links (de muitos para muitos (N:M) e de muitos para um (N:1)) o Não diferencia objeto de associação com atributo o Ausência de facilidades de consultas declarativas o Necessidade de navegação por ponteiros para acesso a informações o Pode gerar dados incoerentes e ainda redundância
Relacional
Organiza os dados em tabelas formadas por linhas e colunas
Como na Matemática, podemos efetuar operações entre dois ou mais conjuntos, ou entre duas ou mais tabelas.
Permitem criar ligações entre duas ou mais tabelas usando campos comuns
Uma operação de consulta gera uma tabela virtual
As 12 regras de Codd:
1. Regra de informações: base em tabelas e campos em comum 2. Regra de acesso garantido: referência a parâmetros específicos 3. Tratamento de valores nulos: valores nulos devem ter tratamento diferente de valores em branco 4. Catálogo relacional ativo: Mantém a estrutura do banco 5. Inserção, exclusão e alteração em bloco: capacidade de permitir manipulação de registros em grupo. 6. Linguagem de manipulação de dados abrangentes: permite manipulação de dados por meio de aplicativos 7. Independência física dos dados: Transparência - Separa as aplicações de usuários da base de dados física 8. Independência lógica dos dados: Transparência do esquema lógico do banco de dados, exemplo: visões. 9. Regra de atualização de visões: aplicativos devem ser capazes de alterar visões; 10. Independência de integridade: devem estar desvinculadas dos aplicativos 11. Independência de distribuição: a diversificação dos sistemas não pode afetar a funcionalidade dos aplicativos 12. Regra não subversiva: sistema deve ser capaz de impedir transgressões nos mecanismos de segurança Em bancos de dados relacionais pode ser necessário um campo comum em diversas tabelas para que seja possível definir relacionamentos entre elas. Orientado a objetos
Utilizam conceitos tais como Entidades, Atributos e Relacionamentos. Uma entidade é um objeto que é representado na base de dados. Um atributo é uma propriedade que descreve algum aspecto de um objeto Relacionamentos entre objetos são facilmente representados em modelos de dados de alto-nível
Representação de baixo nível: o Descreve como os dados são armazenados no computador, representando informações em formato de registros, ordem dos registros e caminho de acesso. Um caminho de acesso é uma estrutura que facilita a busca de um registro particular na base de dados
Esquema: o Descrição das estruturas e das operações de um banco de dados específico, utilizando um modelo de dados.
o o o
Especificado durante o projeto da base de dados, sendo que a expectativa de mudanças normalmente não é grande A forma de visualização de um esquema é chamada diagrama do esquema Muitos modelos de dados têm convenções para criar diagramas (mostrar o modelo através de um desenho)
Instância: São os dados da base de dados num momento específico. Pois os dados existentes podem ser modificados
A necessidade de armazenar dados mais complexos levou à criação dessa modalidade de Banco de Dados
Exemplos: o SIG o CAD o CAM o Imagens o ...
Baseado na definição por meio de objetos com suas propriedades e operações
O registro é mais parecido com uma classe
Padrão de estrutura: ODMG - Object Data Manager Group
Rede
Utilizado principalmente no final da década de 60 e durante a década de 70, o modelo em rede surgiu como uma extensão ao modelo hierárquico, eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em várias associações.
Organiza os dados em uma estrutura formada por várias listas, que definia uma confusa rede de ligações, estrutura similar a um grafo direcionado.
Cada registro “filho” pode ser ligado a mais de um registro “pai”, possibilitando a formação de ligações mais complexas, porque não há a restrição a um só tipo de relacionamento que vigora.
Conhecidos como DBTG (Data Base Task Group) ou CODASYL Largamente utilizados em computadores de grande porte Mesmo registro pode participar de vários relacionamentos Possibilidade de acesso direto a determinado registro/nó da rede Linguagens comuns: COBOL, PASCAL e FORTRAN
Estruturas fundamentais: Registros (Records) e Conjuntos (Sets)
Permite que várias tabelas sejam usadas simultaneamente através do uso de ponteiros
Algumas colunas contêm ponteiros para outras tabelas ao invés de dados, assim, as tabelas são ligadas por referências.
O modelo de banco de dados em rede amplia o modelo de registros permitindo a adição de múltiplos registros Uma coluna do registro pode ser definida como, uma referência a uma ou mais entradas de um registro diferente.
Assim os registros são relacionados, por meio de referências o que pode ser visualizado como uma estrutura em rede. Também utilizam ponteiros para fazer referência aos registros propriamente ditos Os dados são representados por uma coleção de registros e os relacionamentos entre dados são representados por meio de links Um link é uma associação entre exatamente dois valores
Acesso a qualquer nó da rede sem passar pelo nó raiz Exemplos: Adabas e IDMS o Adabas: Considerado por alguns como um dos primeiros SGDBs produzidos comercialmente. Inicialmente foi lançado para mainframes da IBM, porém atualmente o Adabas é suportado em diversas plataformas, incluindo o OpenVMS, Unix, Linux e Windows. Adabas tem mantido a posição como um dos mais rápidos banco de dados OLTP oferecendo a funcionalidade 24x7 Baseado em Listas Invertidas o IDMS: Integrated Data Management System ou Sistema de Gerenciamento de Dados Integrado É um banco de dados em rede da Computer Associates e foi desenvolvido há cinco décadas São executados em minicomputadores até poderosos mainframes.
Problemas: o O modelo de rede é fortemente dependente da implementação o Registros artificiais precisam ser criados para implementar relacionamentos muitos para muitos o As consultas são complicadas: o programador é forçado a pensar em termos de links e, em como percorrê-los para obter as informações de que necessita. o Essa manipulação de dados é chamada navegacional o Manteve-se, durante anos, à frente do modelo relacional porque, inicialmente, as implementações do modelo relacional eram ineficientes.
E hoje, por que desenvolvedores escolhem Graph Database ao invés de um banco de dados tradicional? o Jonathan Allen o "Ao contrário dos bancos de dados que armazenam seus dados em linhas, colunas ou pares de chave-valor, um banco de dados de grafos armazena toda informação em uma rede de nós e arestas. As arestas representam o relacionamento entre os nós que representa os objetos. Devido aos nós e
o
o
arestas serem representados como objetos (os quais os desenvolvedores estão acostumados) é possível definir atributos (também chamado de propriedades) a eles. Adicionando uma direção para uma aresta cria o conhecido grafo de propriedades que representa a explícita estrutura de dados dentro de um banco de dados de grafo. Portanto, diferente de outras abordagens de banco de dados onde apenas implicitamente é possível formar uma estrutura de grafos, um banco de dados de grafo explicitamente representa um grafo. Enquanto outros bancos de dados precisam usar índices e algumas estruturas auxiliares (como tabelas de relacionamento para fazer JOINs) um banco de dados de grafo pode percorrer de um objeto aos seus objetos relacionados, pois esses objetos são organizados para possuir adjacências sem índices. Existem diversos casos de uso onde banco de dados de grafos é a opção mais natural. Por exemplo, em redes sociais é mais fácil utilizar uma estrutura de grafos para representar relações entre amigos e percorrer e realizar pesquisas como "busque todos os amigos dos amigos de meus amigos". Além disso, algoritmos comuns baseados em grafos, como pesquisas através de um caminho, são fáceis de implementar percorrendo o grafo."
Vantagens no uso do SGBD: o Responsabilidade de manter a integridade dos dados do sistema o Checagem fica a cargo do SGBD e não do programador (ex.: como acontecia com a linguagem Clipper) o Facilita a manutenção no armazenamento dos dados, nos quais são modificados através de procedimentos do próprio sistema. o Balanceamento de carga o Responsabilidades do SGBD (ficam com o SGBD) e responsabilidades da aplicação (ficam com a aplicação) o Rotinas de backup o Procedimentos de concorrência ao sistema o Ambientes distintos entre Desenvolvimento (ou Testes), Homologação (ou Qualidade) e Produção. o Ambientes em servidores físicos diferentes
Quanto ao Número de Usuários Suportados
Monousuário: apenas um usuário por vez. Dbase III, Dbase IV, FoxBase, FoxPro.
Multiusuário: Acesso de vários usuários ao mesmo tempo. Fator concorrência.
Quanto à Localização
Centralizado: Sistema de gerenciamento e banco de dados estão localizados na mesma máquina, o servidor de banco de dados
Distribuído: Sistema gerenciador e banco de dados armazenados em diferentes máquinas.
Características dos Bancos de Dados
Os sistemas de gerenciamento de banco de dados tem por incumbência básica manter os dados estáveis, ou seja, devem cuidar de toda a manutenção e atualização dos registros
A construção de rotinas, criação de interface ou desenvolvimento de aplicativos completos deve ficar a cargo de uma ferramenta destinada a essa tarefa, como linguagem de programação que se comunica com o gerenciador utilizando um mecanismo oferecido por ele, como drives de comunicação. o Exemplos: ODBC, ADO (ActiveX) e JDBC
Abstração de dados
Um SGBD oferece aos usuários uma representação conceitual dos dados que não inclui muitos dos detalhes de como os dados são armazenados ou como as operações são implementadas
Este isolamento entre programas e dados se resume na capacidade de se alterar a estrutura do BD sem que seja necessária a modificação nos aplicativos
Como a definição da estrutura do banco está gravada no catálogo e não dentro do código-fonte do programa, tudo o que a aplicação precisa é consultar esta estrutura.
A isso denominamos independência de dados referenciada como abstração de dados.
Exemplo: o Um registro de cliente é estruturado internamente por meio de um nome, a posição inicial do registro e o tamanho em bytes. o É o que o sistema precisa para organizar os dados no BD o Acontece que quem pretende pesquisar, filtrar, operar ou descartar estes dados nada se importa com tamanho e posição. o Porém são informações obrigatórias para o SGBD que ficam transparentes para o usuário final.
Metadados
Num sistema de BD, não há somente os dados em si gravados, mas também toda a definição da estrutura das tabelas que o compõem.
Essa estrutura denominamos de catálogo do sistema: o Nomes das tabelas o Definições dos seus campos o Formato de armazenamento o Índices que foram criados o Restrições relativas aos dados São os metadados.
Compartilhamento
Um BD é preparado para o acesso de inúmeros usuários, portanto requer um controle de concorrência que na situação onde vários usuários tentam atualizar um dado, que o façam de forma controlada de maneira que os resultados das operações sejam corretos.
Consiste na reutilização dos dados do BD pelo maior número possível de aplicações dentro da empresa. Nesse sentido, os dados do BD devem ser muito bem planejados e estruturados. Portanto, este objetivo de banco de dados esta mais ligada à atividade de análise e projeto de BD.
O compartilhamento de dados visa diminuir a redundância de dados, considerando-o como um recurso da empresa e não propriedade de setores isolados da organização.
Para implementar o compartilhamento de dados é necessário que a empresa disponha de recursos de rede, que permitam colocar o BD ao alcance dos diversos usuários. Além disso, é necessário que o SGBD possua um competente sistema de segurança, para que se estabeleça a privacidade de dados, através de mecanismos de restrição de acesso.
Dê exemplos de situações onde existe redundância de dados? Dê exemplos de situações onde o compartilhamento de dados é necessário?
Suporte a múltiplas visões
Sendo o banco de dados multiusuário, é imprescindível que ele permita a cada um ter sua própria visão dos dados.
Esta visão é na verdade um subconjunto do banco de dados como um todo, que pode ser representado como tabela de dados virtuais gerados a partir de consultas.
Exemplos: o Num sistema acadêmico, podemos ter as seguintes visões: o Aluno acessa relatório de notas com suas notas e a situação final (A ou R) o Professor consulta dados obtendo dados de todos os alunos da turma detalhando cada nota e situação o Pai acessa sistema buscando situação final do filho
Novas queries?
Processamento de transações
Os SGBDs, em geral, são Multiusuários e processam simultaneamente operações disparadas por vários usuários, concorrentemente.
Deseja-se alta disponibilidade e tempo de resposta pequeno e execução intercalada por conjuntos de operações Operações são chamadas transações O uso concorrente é possível devido ao conceito de Multiprogramação
Uma transação é uma unidade da execução de programa que acessa e possivelmente atualiza vários itens de dados. Korth (2006)
Devido à característica de suporte a vários usuários simultâneos, é preciso que o sistema de gerenciamento possua capacidade de controlar o acesso concorrente para assegurar que as atualizações efetuadas pelos diversos usuários sejam executadas de maneira controlada para não ocorrerem erros nos dados.
Qualquer pessoa que costuma frequentar fóruns de discussão deve, em algum momento, ter se deparado com uma pergunta recorrente, feita, especialmente, por aqueles que estão iniciando ou migrando de BD para algum tipo de servidor de banco de dados como o Interbase, SQL Server, Oracle ou outro: como fazer para travar um registro e impedir que dois usuários tentem alterá-lo ao mesmo tempo?
Seria uma pergunta fácil de responder se fechássemos os olhos para as implicações que essa mudança pode trazer para o desenvolvimento da aplicação e até mesmo para o profissional que lançou a pergunta.
A questão real seria: o É realmente necessário travar um registro para impedir que dois usuários eventualmente tentem modificá-lo ao mesmo tempo? E, para respondê-la, é necessário pensar em outra questão: o Quais as implicações de travar um registro de forma a impedir seu acesso concorrente?
Exemplo de transferência de fundos: o Transação para transferir R$50,00 da conta A para a conta B:
1. 2. 3. 4. 5. 6.
read(A) A = A - 50 write(A) read(B) B = B + 50 write(B)
Requisito de atomicidade: Se a transação falhar após a etapa 3 e antes da etapa 6, o sistema deve garantir que suas atualizações não sejam refletidas no banco de dados, ou uma inconsistência irá resultar
Requisito de consistência: A soma de A e B é inalterada pela execução da transação
Requisito de isolamento: Se entre as etapas 3 e 6, outra transação receber permissão de acessar o banco de dados parcialmente atualizado, ele verá um
banco de dados inconsistente (a soma A + B será menor do que deveria ser). Isso pode ser trivialmente assegurado executando transações serialmente
Novos cases?
Enfoque dos Bancos de Dados
Incumbência básica do Banco de Dados: o manter os dados estáveis, ou seja, cuidar de toda a manutenção e atualização dos registros
Funções básicas: o Métodos de acesso: DDL (Data Definition Language): especificação do esquema do BD (dados e seus tipos de dados, índices, ...) DML (Data Manipulation Language): manipulação de dados Processamento eficaz de consultas: Exemplo, buscar professores que lecionam em turmas lotadas em salas do quarto andar o Integridade Semântica: Garantia de dados sempre corretos com relação ao domínio de aplicação Exemplos: estados válidos para os dados (sexo; Estado Civil), relacionamentos válidos entre os dados o Segurança: Evitar violação de consistência dos dados Segurança de acesso (usuários e aplicações) - matrizes de autorização, visões Segurança contra falhas: monitoração de transações, transações, categorias de falhas Concorrência: evitar conflitos de acesso simultâneo a dados por transações. Principais técnicas: bloqueio (lock) e timestamp o Independência: transparência da organização dos dados, níveis de independência, física e logica
A construção de rotinas, criação de interface ou desenvolvimento de aplicativos completos devem ficar a cargo de uma ferramenta destinada a essa tarefa
Linguagem de programação que se comunica com o gerenciados utilizando um mecanismo oferecido por ele como drives de comunicação: o ODBC: Open Data Base Connectivity. Conexão criada para definir uma conexão entre um computador e um banco de dados em outro sistema. Esta conexão contém as informações necessárias para permitir a um usuário de computador o acesso às informações armazenadas que não estão disponíveis localmente. É necessário definir o tipo de SGBD e o driver apropriado para a conexão. o ADO: ActiveX Data Objects. Teve a intenção de forneceder um método de acesso aos dados independente para um amplo número de bases de dados. Isto significa que pode-se isar a mesma função para qualquer um, Access, Microsoft SQL Server, Sybase, Oracle, etc. Pode-se usar o ADO
o
com Python, Delphi, VB, ASP, Visual C++, any .NET language, Borland C++ Builder, etc. JDBC: Java database connectivity. API Java API que permite acessar qualquer tipo de dado tabular, especialmente os armazenados num banco de dados relacional. Ajuda a escrever aplicações que gerenciar principalmente 3 atividades. Conexão À fonte dos dados como um banco de dados Envio de declarações de consulta e atualização para o banco de dados Recuperação e processamento de resultados recebidos do banco em resposta à consulta
Banco de Dados Relacionais
Tabelas e Relações
Idealizado por Ted Codd, da IBM Research, atualmente, é o modelo de dados mais utilizado pela indústria
Baseado na teoria dos conjuntos utilizando conceitos de relações matemáticas
Definição mais formal do termo relação (C. J. Date):
"Dada uma coleção de n tipos ou domínios Ti (i= 1, 2, 3, ..., n), não necessariamente todos distintos, r será uma relação sobre esses tipos, se existir em duas partes, um cabeçalho e um corpo, onde: a. O cabeçalho é um conjunto de n atributos da forma AiTi: onde Ai (que devem ser todos distintos) são os nomes dos atributos de r e Ti são os nomes de tipos correspondentes (i= 1, 2, 3,..., n) b. O corpo é um conjunto de m tuplas t, onde t é por sua vez um conjunto de componentes da forma Ai:vi, no qual vi é um valor do tipo Ti - o valor do atributo correspondente ao atributo Ai da tupla t(i = 1, 2, 3, ..., n) Os valores de m e n são chamados respectivamente de cardinalidade e grau da relação r."
O BD Relacional é representado por coleções de relações, que no mundo real assumem a forma de tabelas de registros considerada a unidade básica
As tabelas são compostas por linhas que representam uma instância de uma entidade do mundo real
As colunas (atributos) de uma tabela representam campos e as linhas (tuplas) representam registros
A tabela pode ser considerada como uma relação e é então vista como um arquivo de dados onde os registros são gravados fisicamente no banco de dados seguindo uma certa ordem: de acordo com a entrada ou segundo uma chave primária
Uma tabela somente pode ser considerada uma relação quando as seguintes condições forem satisfeitas: o A interseção de uma linha com uma coluna deve necessariamente conter um valor atômico o Todos os valores de uma coluna devem ser do mesmo tipo de dado o Cada coluna deve ter um nome único o Não há duas ou mais linhas idênticas, ou seja, com os mesmos valores em suas colunas.
Exemplo
Exemplo: Membros de um clube de colecionadores de moedas o Tabela 1: membros
idmembro 1221 9375 9439 3420 6439
nome
sobrenome profissao
telefone email 3212Sérgio Bernardes advogado
[email protected] 3219 3243Nivaldo Duarte bancario
[email protected] 8539 3232Andre Ferreira garcom
[email protected] 4398 3212Janete Lourenco advogado
[email protected] 4397 3234Margarete Pires comerciaria
[email protected] 3482
Nesta tabela, o primeiro campo de cada registro contém o mesmo tipo de dado: um código de identificação do membro chamado idmembro
O segundo campo de cada registro contém o nome do membro
O terceiro campo contém o sobrenome e assim por diante
Não há nada especial na ordem dos campos, pode-se reagrupar, adicionar ou remover campos sem afetar a funcionalidade da tabela
Porém, dentro da mesma tabela, não se pode fazer com que o campo idmembro seja o primeiro campo em um registro e o segundo campo em outro registro
Nem se pode fazer com que um registro contenha um campo a mais ou a menos que outro registro
Todo SGBD relacional precisa propiciar três funções para acessar os dados:
1. Select: Apresenta uma tabela mostrando somente aqueles registros que tenham valores especificados em campos determinados. Ação: "Recupere todos os registros da tabela membros cuja profissão seja igual a advogado" 2. Project: Apresenta uma tabela que não inclui todos os seus campos. Ação: "Obtenha somente os campos nome e sobrenome da tabela membros" 3. Join: Apresenta uma combinação de duas tabelas como se elas fossem apenas uma. O resultado é uma tabela temporária que o SGBD monta combinando os valores dos registros de uma tabela com os valores dos registros de outra tabela e então combinando os campos dos dois registros juntos.
Para mostrar o exemplo de uma combinação destas, precisamos de uma segunda tabela.
Tabela 2: venda
pais Brasil EUA EUA EUA EUA EUA
Moeda 2o reis 20 gold Nickel Penny Penny Penny
ano quantidade idmembro preco 1889 6 1221 32.00 1890 2 9439 100.00 1899 100 9375 0.06 1850 1 6439 1.05 1850 4 1221 1.00 1850 5 3420 0.95
A Tabela acima mantem as moedas a venda com seus preços e respectivos proprietários Observa-se um campo comum às duas tabelas chamado idmembro
Dessa forma, podemos ordenar ao SGBD: o "Combine as tabelas com base em idmembro que mostre": venda.pais venda.moeda venda.ano
venda.quantidade venda.preco membros.idmembro membros.email
O resultado deve ser o seguinte:
Tabela 3:
pais Brasil EUA EUA EUA EUA EUA
Moeda 20 reis 20 gold Nickel Penny Penny Penny
ano quantidade idmembro preco email 1889 6 1221 32.00
[email protected] 1890 2 9439 100.00
[email protected] 1899 100 9375 0.06
[email protected] 1850 1 6439 1.05
[email protected] 1850 4 1221 1.00
[email protected] 1850 5 3420 0.95
[email protected]
Domínios
Designa o tipo de dado que cada coluna de uma tupla pode conter
Normalmente dá-se o nome aos domínios como forma de identificá-los e também auxiliar na interpretação do valores que eles representam
Também devem ser declarados num domínio, o tipo de dado que deve ser aceito e o tamanho da informação
Exemplos: o CNPJ: 14 dígitos divididos em três blocos: 1o. o número da inscrição propriamente dito 2o. localizado após a barra, representa um código único para a matriz ou filial 3o. representados pelos dois últimos valores chamados de dígitos verificadores (DV) Os dígitos verificadores (DV) são criados a partir dos doze primeiros. O cálculo é feito em duas etapas utilizando o módulo de divisão 11. Processo: Calcular os dígitos verificadores de um CNPJ hipotético, por exemplo, 11.444.777/0001-XX. o CPF: 11 dígitos: 9 + 2 o Titulo de Eleitor: 8 + 2 o http://ghiorzi.org/cgcancpf.htm
Um domínio também pode ser útil para restringir os dados que devem ser gravados em um atributo/campo
Exemplos: o Data Nascimento: A partir de 01/01/1900 o Estado Civil: Casado, Solteiro, Viúvo, Separado, Divorciado, ... o Situação Aluno: Regular, Trancado, Jubilado, Abandono, ...
Assim como na Matemática, todos os elementos pertencentes a um conjunto devem ser distintos, uma tabela de bancos de dados deve conter registros, que também são únicos, ou seja, os valores de todos os seus campos não podem se repetir.
Da mesma forma, não se pode ter registros cujo campo que seja chave primária esteja sem valor, normalmente definido como nulo ou branco. Em SQL, isso pode ser resolvido, acrescentando a cláusula NOT NULL à linha que o atributo é definido (Restrição de Integridade da Entidade)
Outro tipo de restrição muito importante é a Restrição de Integridade Referencial que existe entre duas tabelas e cuja função é prevenir a inconsistência de dados.
Exemplo: Controle de Estoque
Descreva um conjunto de tabelas que controlem dados de produtos com suas categorias o Tabela Categorias possua um relacionamento com a tabela Produtos o Cada produto se enquadra em uma categoria o Suponha que um registro de Categoria seja excluido da tabela Categorias o A tabela Produtos contém registros que fazem referência à categoria excluída o Teríamos então os registros órfãos Solução: Chave Estrangeira
Chaves
Chave é um componente de uma relação que pode ser formada por um ou mais atributos, cuja função é permitir identificar uma linha na relação, ou registro numa tabela.
Superchave: o Representa uma restrição capaz de prevenir a existência dos mesmos valores em atributos de duas ou mais entidades diferentes, o que em síntese torna possível identificar uma entidade unicamente. o É um conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira unívoca uma entidade em um conjunto de entidades. Em outras palavras, não podem existir duas ou mais linhas da tabela com o(s) mesmo(s) valores de uma Super-Chave o Exemplo:
O atributo CPF do conjunto de entidades CLIENTE é suficiente para distinguir uma entidade CLIENTE de outra. Assim, o CPF é uma superchave Do mesmo modo, a combinação de NOME_CLIENTE e CPF é superchave para o conjunto de entidades CLIENTE Já o NOME_CLIENTE não é superchave de CLIENTE.
Chave Candidata: o Representa um conjunto mínimo de atributos que podem identificar uma tupla dentro de uma relação, da mesma forma que faria uma chave primária o São chamadas de candidatas porque podem perfeitamente ser chaves primárias da relação o Exemplo: Veículo com os atributos chapa, chassis e renavam o Suponha uma combinação de nome_cliente e rua_cliente seja suficiente para distinguir todos os membros do conjunto de entidades cliente, assim como o atributo cpf, sozinho. Então (cpf) e (nome_cliente, rua_cliente) são chaves candidatas. Embora os atributos (cpf, nome_cliente), juntos, possam, distinguir as entidades cliente, sua combinação não forma uma chave candidata, uma vez que cpf, sozinho, é uma chave candidata.
Chave Primária: o Chave candidata escolhida para identificar unicamente uma tupla e definir uma ordem física das tuplas dentro de uma relação o Chaves cujos atributos são usados para identificar as tuplas em uma relação. Geralmente, é escolhida a chave candidata de menor tamanho.
Chave Estrangeira: o Atributos de uma relação que fazem referência à chave primária de outra relação, ou até mesmo à própria
Exercício: o Identifique as chaves primárias: Uma escola necessita de um sistema de controle acadêmico Esse sistema deverá possibilitar que sejam persistidos os alunos, professores, disciplinas e cursos Deverá prover a efetivação de matrículas dos alunos em um determinado curso O enquadramento de professores em uma determinada disciplina A composição desses cursos pelas disciplinas
Modelo Entidade-Relacionamento
Uma base de dados é modelada como o conjunto de entidades o associações entre entidades
Entidade: um conceito com existência independente com objetos distintos de outros objetos o com existência física ou não o com um conjunto de atributos específicos o e um valor para cada um desses atributos Exemplo: empregados
Exemplo
Entidades cliente e emprestimo o cada uma com seus atributos o ligadas pelo relacionamento beneficiario
Tipos de atributos
Atributo: propriedade da entidade o Exemplo: nome, endereco, sexo, datanascimento Atributos podem ser o simples ou compostos exemplo: nome, sexo, estadocivil, endereço o de valor único ou valor múltiplo exemplo: telefone o derivados exemplos: Idade, se já existir a data de nascimento Digito Verificador Status Atributos compostos, multi-valor e derivados o Associações também podem ter atributos
Cardinalidade de uma associação
Uma associação pode ser entendida como um relacionamento entre instâncias de Entidades devido a regras de negócio
Normalmente ocorre entre instâncias de duas ou mais Entidades, podendo ocorrer entre instâncias da mesma Entidade (auto-relacionamento).
Por que a associação é necessária? o Quando existem várias possibilidades de relacionamento entre o par das entidades e se deseja representar apenas um o Quando ocorrer mais de um relacionamento entre o par de entidades
o o
Para evitar ambiguidade Quando houver auto-relacionamento Para definir o número de ocorrências de uma entidade usamos o conceito de Cardinalidade. A Cardinalidade indica quantas ocorrências de uma Entidade participam no mínimo e no máximo do relacionamento.
id-cliente c1 c2 c3
nro-conta a1 a1 a2
data-acesso 20/09/2012 19/09/2012 01/06/2012
Exemplos:
o
o
o
Em alguns exemplos, podemos ter uma Seta indica entidade “um” em associações
Papéis (roles)
Associações entre a mesma entidade o papéis ajudam a clarificar o Exemplo: Professor ministra disciplina Disciplina é ministrada pelo professor Alunos pertence a turma Turma contém alunos Atendente aprova empréstimos Aluno solicita empréstimos Gerente autoriza empréstimo
Chaves de associações
A chave da associação depende da cardinalidade o se a associação for muitos para muitos um para muitos
muitos para um um-para-um Exemplo: Veículo (placa, chassis,motor)
Exercício: o Desenvolver a avaliação das chaves para a seguinte situação: Nota fiscal e Itens da Nota Fiscal Definir tabelas, associações e chaves
Avaliar o seguinte problema: Um sistema de lotação de pessoas onde ... o empregado pode fazer apenas uma tarefa em cada agência o empregados possuem diferentes tarefas em diferentes agências Seta pode definir a cardinalidade
Chaves
A chave pode ser o super-chave qualquer conjunto de atributos que identificam univocamente o chave candidata conjunto mínimo de atributos o chave primária a chave candidata escolhida normalmente prefere-se um atributo separado por si só, mas há chaves compostas por vários atributos
Entidade fraca e Entidade forte
Pode haver algum tipo de entidade que não possui nenhum atributo-chave, o que significa que ficamos impossibilitados de distinguir uma entidade específica dentro de todo o conjunto, já que é possível haver entidades duplicadas
A esse tipo de entidade chamados Entidade Fraca
Por outro lado, entidades que possuem atributos-chave são denominadas de Entidades Fortes
As entidades fracas tem como característica o fato de serem identificadas por meio de sua associação com outra entidade específica, denominada de entidade identificadora
Exemplo 1: Entidades Fracas
o
Exerício: Empréstimos e Devoluções o empréstimo (aluno, livro, data, ...) o devolução (aluno, livro, data, ...) o número sequencial para cada empréstimo? o Este número fica sendo a chave da devolução?
Especialização / Generalização
Especialização o vista de cima para baixo (top-down) o a partir da super-classe encontram-se sub-classes
Generalização o vista de baixo para cima (bottom-up) o a partir das sub-classes identifica-se a super-classe
Condições de especialização
Disjunta o quando só pode pertencer a uma das sub-classes Exemplo: Conta pode ser ou “conta à vista” ou “conta a prazo”
Sobreposta o Quando pode estar presente em várias sub-classes Exemplo: Empregado que é também Cliente do banco
Agregação
Cardinalidade em associações
Exemplo anterior: o empregados com diferentes cargos em diferentes agências
E se houver um Gestor para cada tarefa desempenhada por um empregado numa agência?
Solução: agregação! o uma associação passa a ser uma entidade
Exemplo de Modelo E-A
Conversão de entidades
Entidade forte converte-se numa tabela o atributos simples mantêm-se o chave da tabela é a mesma da entidade Emprestimo (nro-emprestimo, valor)
Conversão de associações
Associação “muitos-para-muitos” converte-se numa tabela com as chaves primárias das entidades o (professor, disciplina)
Associação “um-para-um” o É possível mas não obrigatório, criar tabela Ex: Veículo - Motor o Qualquer um dos lados pode ter uma chave estrangeira Se a participação for parcial, aparecem nulls
Atributos compostos o cliente (id-cliente, primeiro-nome, nome-do-meio, último-nome, ...)
Integridade
Integridade dos Bancos de Dados
Uma das maiores preocupações de qualquer desenvolvedor ou projetista de BD é encontrar uma forma de garantir a integridade dos dados que se encontram armazenados
Isso se deve ao fato de que se houver algum dado crucial armazenado de forma incorreta, o resultado pode ser catastrófico, pois o BD pode apresentar informações imprecisas ou mesmo totalmente errôneas
Imagine a situação: o Uma aplicação de contas a receber tem em seu BD, vinte e dois registros de pagamento em aberto, referentes a um determinado cliente o A ligação entre essas informações (o cadastro do cliente e o pagamento em aberto) é feita pelo pagamento de código do cliente e por isso o valor desse campo não pode ser alterado de forma nenhuma o Digamos que um usuário ou o próprio administrador do BD tenha aberto o BD fora da aplicação e alterado o valor do campo do código do cliente na tabela de cadastro de clientes o Logicamente o vínculo será quebrado pois os campos utilizados no relacionamento agora possuem valores distintos
Exemplos: Arquivo:BDA-Integridade1.pdf
Se o próprio sistema de BD oferecer formas de restringir ou mesmo impossibilitar a quebra dessa integridade, o desenvolvedor terá menos trabalho. Acessando os dados fora da aplicação, as informações ficaram vulneráveis
Como solução para este problema, a maioria dos sistemas hoje existentes possui recursos capazes de gerenciar esta integridade de dados.
Será que todos os considerados SGBDs possuem esta funcionalidade?
Integridade de Entidades
Define que as chaves primárias de uma tabela não podem ser nulas, ou seja, sempre deverão conter um valor mesmo que sejam compostas. Valor nulo => diferente de zero ou espaço em branco. E para números? Alguns sistemas: Campo requerido Motivo: o A chave primária é um atributo (ou mais de um) que identifica um registro único o Determina a ordem física dos registros o É utilizada no relacionamento com outras tabelas
Integridade Referencial
Estabelece restrições ou bloqueios de algumas operações (exclusão ou alteração) nos dados de campos das chaves primárias utilizadas no relacionamento de uma tabela com outra
Exemplo: Tabelas de Produtos e Categorias
o o o
A categoria H222 se relaciona com um ou mais produtos,[1001, 1005, 1008] Se o usuário acidentalmente excluir a categoria H222, os produtos que pertencem a esta categoria ficarão órfãos na tabela de produtos Teríamos também registros sem nenhum vínculo na tabela de categorias
Integridade referencial: o Proibe este tipo de inconsistência impedindo que a relação entre a chave primária e a chave estrangeira seja quebrada o Isto facilita para o desenvolvedor evitando que ele implemente tarefas de vigilância na aplicação
Formas de tratamento o Proibição: Não permite que o usuário altere ou exclua dados de uma chave primária que é chave estrangeira em outras tabelas A menos que ... o Execução em cascata: A exclusão ou alteração é refletida automaticamente nas tabelas relacionadas Exemplo: Os produtos que pertencem à categoria H222 serão excluídos junto com a própria categoria Caso real: Ajuda dos universitários
SQL: o
o
Suporte à Integridade Referencial permitindo que sejam criadas chaves estrangeiras (CONSTRAINT) para especificar as ações a serem desempenhadas para operações de exclusão e atualização de dados Access: integridade parcial
Integridade de Domínios
Estabelece restrições e regras na definição dos domínios em si, em vez de diretamente nos campos Ajuda a economizar tempo e trabalho Vários campos são formatados a partir de domínios Com a regra de integridade definida neles, esses campos automaticamente herdam essas restrições Exemplo: o Definir Dominio "Salario" com tipo decimal e valor maior que 1 SM
Integridade de Campos
Eventualmente, mesmo o desenvolvedor tendo definido integridade de domínio, é necessário adicionar restrições extras aos campos Exemplo: o Salário: restringir o intervalo aceito entre 622 (valor minimo) e 2700 (valor máximo). A integridade de campos não deve conflitar com a de domínio
Validação de dados: o Possibilita que o próprio SGBD faça uma verificação quanto aos valores inseridos pelo usuário se são válidos ou não o Exemplo: Cadastro de funcionários Cada funcionário tem um cargo e seu salário é definido pelo cargo que ocupa Neste caso, mesmo que o valor para essa informação esteja dentro da regra definida para o campo deve ser efetuada uma validação para certificar-se de que o valor fornecido está dentro do padrão para o cargo do funcionário
Formato dos dados: o CNPJ - formato 99.999.999/9999-99 o Algumas soluções provem as "máscaras de entrada" para cada campo do BD
Regras de Codd Informações em tabelas
Toda informação deve ser representada de uma única forma, como dados em uma tabela
Os nomes das tabelas, colunas e domínios são representados por séries de caracteres que, por sua vez, devem também ser guardadas em tabelas, as quais formam o catálogo do sistema, o dicionário de dados
O princípio de que a informação deve estar sob a forma de tabela é extensiva ao dicionário de dados
As tabelas são bidimensionais, o que equivale a dizer que não há colunas repetitivas (Cláusula Occurs, por exemplo, não existe).
Acesso garantido
Todo dado pode ser acessado logicamente (e unicamente) usando padrões específicos
A ordem das linhas, assim como a das colunas, é irrelevante
Para obter o valor de uma coluna em uma linha de uma tabela, basta informar: o o nome da tabela o o valor de uma chave primária (no caso, da linha a ser recuperada) o o nome da coluna da tabela em questão
Para saber quais ocorrências de uma tabela têm um determinado valor em uma coluna, basta informar o nome da tabela e o nome da coluna, que o conteúdo poderá ser comparado
Conclusão: a regra especifica que, em um banco de dados efetivamente relacional, não existe informação inacessível.
Tratamento de valores nulos
Os valores nulos (diferente do zero, da string vazia, da string de caracteres em brancos e outros valores não nulos) existem para representar dados não existentes de forma sistemática e independente do tipo de dado
Valores nulos são suportados em um SGBD relacional nulo para representar exatamente a informação perdida ou inexistente, inaplicável
Atenção: o Não confundir zero(s) ou espaço(s) em branco com strings vazios
Comparação: Imagine um pacote de supermercado de papel, desdobrado. Sem tocá-lo ou olhar em seu interior, você não pode saber se está vazio ou contém algum produto. Portanto, nesse instante, para você, o conteúdo do pacote é NULO. É uma informação desconhecida, inexistente
Para suportar a integridade de identidade é preciso especificar “não são permitidos valores nulos” em cada coluna da chave primária e em qualquer outra coluna que se considerar como uma restrição de integridade
Se levarmos em conta que um atributo tem de, obrigatoriamente, possuir conteúdo, estaremos especificando que seu valor não pode ser nulo. Assim, o SGBD precisa reconhecer a informação nula para poder restringi-la ou aceitá-la, se necessário.
Catálogo relacional ativo
A descrição do banco de dados é representada no nível lógico como dados ordinários (isso é, em tabelas), permitindo que usuários autorizados apliquem as mesmas formas de manipular dados aplicada aos dados comuns ao consultá-las
Esta regra exige que um SGBD relacional tenha uma mesma linguagem para acesso e definição dos dados no dicionário e para a manipulação dos dados do banco e do dicionário
Exemplo: o um comando para adicionar informações em uma tabela da aplicação deve ser o mesmo para acrescentar informações no dicionário de dados.
Atualização de alto nível
A capacidade de manipular a relação base ou relações derivadas como um operador único não se aplica apenas a recuperação de dados, mas também a inserção, alteração e eliminação de dados
Operações realizadas sobre a base de dados tratam conjuntos de informações (tabelas), não registro por registro
A linguagem de alto nível não é procedural, uma característica das linguagens denominadas de quarta geração.
Sublinguagem de dados abrangentes
Um sistema relacional pode suportar várias linguagens e formas de uso, porém deve possuir ao menos uma linguagem com sintaxe bem definida e expressa por cadeia de caracteres e com habilidade de apoiar: o a definição de dados: criar ou adicionar tabelas no dicionário de dados
o o o
o o
a definição de visões: fazer operações relacionais de junção, criar visões de partes do modelo de dados a manipulação de dados: permitir criar, alterar, consultar e deletar conjuntos de dados as restrições de integridade: possibilitar que sua sublinguagem controle as restrições específicas de uma tabela ou de valores aceitáveis para uma determinada coluna a autorização: definir limites de acesso a tabelas por usuário, inclusive em nível de coluna limites de transação: tornar viável a delimitação de uma transação lógica de modificação do banco de dados, o que fornece um alto nível de segurança da integridade de informações no banco de dados.
Independência física
Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas quaisquer que sejam as modificações na representação de armazenagem ou métodos de acesso internos
Essa regra nos dá uma diretriz essencial quanto aos programas de aplicação: esses programas lidam somente com dados lógicos. Se houver qualquer modificação quanto ao local de armazenamento físico dos dados ou, ainda, uma mudança qualquer de índices de acesso, o programa de aplicação, logicamente estável, não sofrerá nenhuma paralisação nem precisará de alterações
Exemplo: o Se desenvolvermos uma aplicação em um diretório de dados e, posteriormente, em consequência de uma migração ou expansão de hardware, essa base de dados for transferida para um outro diretório de dados, as aplicações desenvolvidas originalmente para tal base não serão afetadas, já que a definição de localização dos dados deve ser externa à linguagem de manipulação de dados.
Independência lógica
Os programas de aplicação também permanecem inalterados quando são feitos nas tabelas, mudanças de qualquer tipo para preservar a informação
A regra implica, por exemplo, que a junção de duas tabelas não afeta os programas, assim como a criação de novos campos e as operações de seleção que dividem uma tabela por linhas ou colunas, desde que se preservem as chaves primárias
Exemplo: o Se criarmos um novo relacionamento entre duas entidades ou modificarmos a condição de relacionamento entre elas, em hipótese nenhuma isso afetará as aplicações existentes.
Atualização de visões
Toda visão que for teoricamente atualizável será também atualizável pelo sistema
Atualizar significa mais do que simplesmente modificar a informação; abrange também a inclusão e/ou exclusão de dados
Se definimos uma visão de dados como um subconjunto horizontal de uma tabela, deve ser possível adicionar dados a essa visão
Exemplo 1: o Consideremos uma tabela de funcionários e que haja visões de funcionários técnicos, funcionárias secretárias e funcionários administrativos o Atualizar uma dessas visões quer dizer, entre outras possibilidades, adicionar dados para a inclusão de uma secretária ou de um técnico
Exemplo 2: o Criar uma visão de uma tabela de médicos por especialidade, digamos cem médicos em uma tabela, dos quais trinta são especializados em pediatria o Ao criarmos a visão Pediatras, uma seleção de linhas, que conterá somente os médicos com esta especialidade, cria-se no dicionário de dados um sinônimo de médico, denominado Pediatra, que tem como condição para esse role (literalmente, papel) o valor da coluna especialidade ser igual a pediatria o Esta visão deve ter a possibilidade de ser deletada. Se comandarmos DELETAR PEDIATRIA ou ALTERAR um pediatra específico, tais atualizações devem ser realizadas diretamente na tabela originária da visão.
Independência de integridade
As relações de integridade específicas de um banco de dados relacional devem ser definidas em uma sublinguagem de dados e armazenadas no catálogo (e não em programas de aplicação)
Restrições de domínio e regras para validação de alguns ou todos os atributos também devem ser armazenáveis no dicionário de dados
Exemplo: o Definições do tipo de caractere de um campo – se numérico, se inteiro ou de tamanho variável – devem estar especificadas nele o Já para o controle de sua validade (consistência), deve haver a possibilidade de ser realizado pela sublinguagem do SGBD, sem que, para isso, haja necessidade de que o programa de aplicação o controle o Da mesma forma, a exigência da existência de um campo deve ser informada no dicionário e também deve ser administrada por este, ficando os programas de aplicação desobrigados de tais controles.
Independência de distribuição
A linguagem de manipulação de dados deve possibilitar que as aplicações permaneçam inalteradas estejam os dados centralizados ou distribuídos fisicamente
Um SGBD relacional tem independência de distribuição quando sua sublinguagem permite que os programas de aplicação permaneçam inalterados enquanto os dados são distribuídos, tanto na inicialização de um sistema quanto na ocorrência de uma redistribuição
Se um sistema, por sua implementação, tiver arquivos redistribuídos em meios ou máquinas diferentes, a sublinguagem do SGBD fará o controle e a ligação com os programas de aplicação, sem que seja necessário realizar nenhuma modificação neles.
Não subversiva
Se o sistema relacional possui uma linguagem de baixo nível, não deve ser possível subverter ou ignorar as regras de integridade e restrições definidas no alto nível
Isso quer dizer que, se processarmos registro a registro, isso não poderá implicar a burla de restrições específicas dos objetos do banco de dados
Tal regra pode ser considerada extensiva à utilização de outras linguagens capazes de interagir com o banco de dados
Exemplo: o a utilização de uma linguagem de baixo nível não poderá adicionar um registro sem os atributos definidos, no dicionário, como obrigatórios para uma determinada tabela.
Normalização Dependência Funcional
Consiste numa restrição entre dois conjuntos de atributos de uma mesma entidade/relação
Uma dependência funcional é representada pela relação X -> Y, em que X e Y são subconjuntos de atributos de uma relação qualquer
Isso impõe uma restrição na qual um componente Y de uma tupla (registro) é dependente de um valor do componente X (ou é determinado por ele)
Do mesmo modo, o valores do componente X determinam de forma unívoca os valores do componente Y
Resumindo, Y é dependente funcionalmente de X
Supondo o esquema de uma relação abaixo, onde os três primeiros atributos, cujos nomes se encontram destacados, representam a chave primária da relação
MatriculaAl CodigoCu CodigoDiscip NomeAlu DataMatric NomeCu NomeDiscip NotaPr uno rso lina no ula rso lina ova -
-
-
-
-
-
-
-
Podemos estabelecer 4 dependências funcionais neste exemplo: o 1. MatriculaAluno -> {NomeAluno, DataMatricula) => O valor do atributo MatriculaAluno determina o valor dos atributos NomeAluno e DataMatricula o 2. CodigoCurso -> NomeCurso => O valor do atributo CodigoCurso determina o valor do atributo NomeCurso o 3. CodigoDisciplina -> NomeDisciplina => O valor do atributo CodigoDisciplina determina o valor do atributo NomeDisciplina o 4. {MatriculaAluno, CodigoCurso, CodigoDisciplina} -> NotaProva => A combinação de valores dos atributos MatriculaAluno, CodigoCurso e CodigoDisciplina determina o valor do atributo NotaProva.
Categorias
Total ou Completa: o Podemos ter situações em que não se utilizam atributos simples para determinar os valores de outros atributos Neste caso, teremos um atributo que é dependente funcional da combinação de dois ou mais atributos o Quando um atributo que não faz parte da chave primária depende funcionalmente de todos os atributos que fazem parte da chave, tem-se uma dependência funcional total. o É considerado o 1o. tipo, onde a dependência só existe se a chave primária composta por vários atributos determinar univocamente um atributo ou um conjunto de atributos o No nosso exemplo, o atributo NotaProva é dependente total da chave primária formada pelos atributos MatriculaAluno/ CodigoCurso/CodigoDisciplina. o Exemplo: Entidade DEPENDENTE (CodigoPaciente, DataNascimento} -> {NomeDependente} (?) No caso, os valores dos atributos CodigoPaciente e DataNascimento determinam o valor para o atributo NomeDependente O nome do dependente só pode ser determinado em função de dois atributos
Parcial: o Temos uma situação em que um atributo/conjunto de atributos depende de outro(s) atributo(s) que não fazem parte de uma chave primária
o
o o
Quando um atributo que não faz parte da chave primária depende funcionalmente de apenas alguns dos atributos que fazem parte da chave primária o 2o. tipo, então, ocorre quando o atributo/conjunto de atributos depende apenas de parte dos valores da chave primária Exemplo: Banco de Dados com as entidades MEDICO e PACIENTE CRM -> NomeMedico CodigoPaciente -> {NomePaciente, CPF, RG } A 1a, dependência especifica que o valor atributo CRM da entidade MEDICO determina de forma unívoca o valor do atributo NomeMedico dessa mesma entidade O valor do atributo CodigoPaciente (entidade PACIENTE) determina o nome, o CPF e o RG do paciente É importante notar que apenas o valor dos atributos CRM e CodigoPaciente é necessário para que seja possível determinar o nome do médico ou o CPF e RG do paciente, ou seja, é uma dependência parcial
Transitiva ou Indireta: o Esta dependência ocorre quando a dependência funcional se realiza entre atributos que não fazem parte da chave primária o Exemplo: Numa tabela de Vendas, temos o atributo PreçoTotal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um preço total existir ele DEPENDE de valor unitário e quantidade O ValorUnitário deve estar numa tabela Produtos, relacionada à venda e Quantidade está na própria tabela Vendas. PreçoTotal depende destes dois campos e eles não são campos-chave.
Normalização
Após a construção do modelo conceitual dos dados (Modelo Entidade/Relacionamento) é feita a transformação para o modelo lógico (Esquema de Tabelas)
O desenho de tabelas obtido representa a estrutura da informação de um modo natural e completo.
Normalização é um processo baseado nas chamadas formais normais o Uma forma normal é uma regra que deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem estruturadas A normalização pode ser entendida como um processo submetido a estas várias formas normais o Objetivo principal: eliminar a redundância nos dados armazenados em tabelas, resultando na diminuição do espaço e dos riscos de inconsistências em atualizações de dados
Quando um atributo é alterado em uma tabela que não está totalmente normalizada, é necessário alterá-lo em todas as linhas em que ele ocorre, haja visto a sua repetição
Tal operação poderia ser executada apenas uma vez, caso este atributo estivesse normalizado
As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.
Efetivamente, a Normalização tem como objetivo avaliar a qualidade do Modelo de Tabelas e transformá-lo (em caso de necessidade) num Modelo (Conjunto de Tabelas) equivalente, menos redundante e mais estável.
1FN
Verificação de Tabelas Aninhadas
Uma relação está na 1a. Forma Normal se e somente se cada linha contiver exatamente um valor para cada atributo o Dado que as Relações(Tabelas) são estruturas bidimensionais, então no cruzamento de uma linha com uma coluna (atributo) só é possível armazenar valores atómicos.
Para isso, não deve conter tabelas aninhadas
Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta: o Este campo depende de algum outro?
Se sim, então devemos arrumar um método para corrigir o problema.
Método: o Remover o grupo de repetição o Expandir a chave primária
Seguindo a definição devemos normalizar a tabela decompondo-a em duas Uma relação R está na 1FN se: o Todo valor em R for atômico o Ou seja, R não contém grupos de repetição.
Considerações: o Geralmente considerada parte da definição formal de uma relação o Não permite atributos multivalorados, compostos ou suas combinações
Caso 1
cliente (NroCliente, Nome, {End-Cliente}) Corrigindo o problema: o Solução: cliente (NroCliente, Nome, End-Cliente, CidCliente, UFCliente)
Caso 2
Exemplificando com a tabela Venda Esquema relacional da tabela: o Venda Codvenda (Int) Cliente (Str) Endereco (Str) Cep (Int) Cidade (Str) Estado (Str) Telefone (Int) Produto (Str) Quantidade (Float) ValorUnitário (Float) PreçoTotal (Float)
Análise: o o
o
A tabela Venda, deve armazenar informações da venda O campo Cliente é dependente de CodVenda, afinal para cada Venda há um cliente Campo Endereço: não depende de Codvenda, e sim de Cliente, pois é uma informação particular ao cliente Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não á venda Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone], Produto, Quantidade, ValorUnitário, PreçoTotal)
Solução: o Extrair estes campos para uma nova tabela o Adicionar uma chave-primária à nova tabela o Relacioná-la com a tabela Venda criando uma chave-estrangeira
Resultado: o Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone). o Venda (Codvenda, Codcliente, Produto, Quantidade, ValorUnitário, PreçoTotal).
Aplicando novamente a 1a. forma normal às 2 tabelas geradas
Uma situação comum em tabelas de cadastro é o caso Cidade-Estado
Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade
No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina
Isso é o que chamamos de Dependência funcional: o aparentemente, uma informação depende da outra
No caso Cidade-Estado a solução é simples: o Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela o Em seguida, o mesmo processo feito anteriormente: Adicionar uma chave-primária à nova tabela e relacioná-la criando uma chave-estrangeira na antiga tabela
Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, ValorUnitário, PreçoTotal)
Seguindo com o exemplo, a tabela Cliente encontra-se na 1a. forma normal, pois não há mais tabelas aninhadas
Verificando Venda, identificamos mais uma tabela aninhada
Os campos entre colchetes são referente á mesma coisa: Produto de Venda
Venda (Codvenda, Codcliente, Codcidade, [Produto, Quantidade, Valorunitario, Valorfinal])
Na maioria das situações, produtos têm um valor previamente especificado
O ValorUnitário depende de Produto
Já a Quantidade não depende do Produto e sim da Venda
Cidade (Codcidade, Nome, Estado)
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
Produto (Codproduto, Nome, ValorUnitário)
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)
Utilizando a 1a. Forma Normal na tabela Venda, obtivemos 3 tabelas
2FN
A 2a. Forma Normal exige um pouco mais de conhecimento sobre as dependências funcionais, prioritariamente para a dependência funcional total
Uma relação está na 2a. Forma Normal se estiver na 1a. e se todos os atributos descritores (não pertencentes a nenhuma chave candidata) dependerem da totalidade da chave (e não apenas de parte dela)
Isso quer dizer que uma tabela encontra-se na 2FN, quando, além de estar na 1FN, não contem dependências parciais
Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta
Resumindo, a entidade se encontra na 2FN se, além de estar na 1a., todos os seus atributos são totalmente dependentes da chave primária composta
Significa que atributos que são parcialmente dependentes devem ser removidos.
Se observarmos as tabelas e identificarmos repetição dos dados nas tuplas requer-se a 2FN
Relendo cada campo e questionando: o Este campo depende de toda a chave? o Se não, temos uma dependência parcial
Caso 3
Uma entidade Item possui chave primária composta que é constituída pelos atributos NumPedido e CodProduto
Os atributos Descricao e PrecoUnit não dependem totalmente dessa chave, ao contrário de Quantidade e ValorTotal
Nova entidade: Produto
Caso 4
Reavaliando o caso Cidade-Estado que gerava uma dependência funcional o Após a normalização da tabela Venda, obtivemos uma chave composta de 4 campos: o Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal) A questão agora é verificar se cada campo não-chave depende destas 4 chaves
Procedimento:
1. O 1o. campo não-chave é Quantidade 2. Quantidade depende de Codvenda => Para cada venda há uma quantidade específica de itens 3. Quantidade depende de Codvenda e Codcliente => Para um cliente podem ser feitas várias vendas, com quantidades diferentes 4. Quantidade não depende de Cidade e quem depende de Cidade é Cliente 5. Temos uma dependência parcial pois Quantidade depende de Codproduto, pois para cada produto da Venda há uma quantidade certa
Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda o Quem sobra nessa história é Codcidade o A tabela Cidade já está ligada com Cliente, que já está ligada com Venda
o
A chave Codcidade em Venda é redundante, portanto podemos eliminá-la Venda (Codvenda, Codcliente, Codproduto, Quantidade, PrecoTotal)
Problema: o Existe alguma necessidade de manter CodCidade como campo não-chave?
O próximo campo não-chave é PreçoTotal
Avaliando PreçoTotal da mesma forma que Quantidade o Chega-se à conclusão de que ele depende de toda a chave de Venda.
3FN
Uma relação encontra-se na 3a. Forma Normal se está na 2a. Forma Normal e se não existirem atributos descritores (não pertencentes a nenhuma Chave Candidata) a dependerem funcionalmente de outros atributos descritores (não-chaves)
Após a aplicação das regras da 2FN se ainda restarem dados redundantes na tabela avaliada pode-se empregar a 3FN
Terceira Forma Normal (3FN): o Efetivamente, uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas o Dependência transitiva: Uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela. o Assim sendo, cada atributo deve depender apenas das Chaves Candidatas da relação.
Caso 5
Em Pedidos, existem atributos que identificam: o um cliente (nome do cliente e endereço completo) o um vendedor (nome do vendedor)
Os dados dos atributos: o NomeCliente o EndCliente o CidCliente o UFCliente são dependentes de CodCliente o Podemos criar outra entidade => Cliente
Da mesma forma, NomeVendedor é dependente de CodVendedor
FNBC
Uma relação está na forma normal de Boyce-Codd se e somente se, para todas as dependências funcionais X -> Y existentes na relação, X é chave ou super-chave da relação
A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata). Aplica-se a FNBC quando: o Encontramos duas ou mais chaves candidatas o As chaves candidatas são compostas (apresentam mais de um atributo) o Todas as chaves candidatas têm um atributo em comum
Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante
A Forma Normal de Boyce/Codd foi criada com a intenção de resolver algumas situações que não eram inicialmente cobertas pelas três primeiras formas normais o Foco especial para quando haviam várias chaves na entidade formadas por mais de um atributo o E que compartilhavam ao menos um atributo Isso porque as formas normais tratam atributos dependentes das chaves primárias
Para estar na FNBC, uma entidade precisa possuir somente atributos que são chaves candidatas
Caso 6
Assumindo que um professor possa estar associado a mais de uma escola e uma sala.
Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala, NomeProfessor)
Chaves candidatas: o NomeAluno+EnderecoAluno o NomeAluno+NumeroSala o NomeAluno+NomeProfessor
Encontramos três chaves candidatas o Todas apresentam mais de um atributo (concatenados) o Todas compartilham um mesmo atributo: NomeAluno
Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas o uma que contém todos os atributos que descrevem o aluno o outra que contém os atributos que designam um professor em uma determinada escola e número de sala
Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala) Sala (NomeEscola, NumeroSala, NomeProfessor)
Resumo
1FN o o
o
2FN o o
1. Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave 2. Para cada tabela com chave primária composta e com pelo menos uma coluna não chave Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN Para cada coluna não chave fazer a seguinte pergunta: ”a coluna depende de toda a chave ou de apenas parte dela” Caso a coluna dependa de toda a chave Criar a coluna correspondente na tabela com a chave completa na 2FN Caso a coluna não dependa apenas de parte da chave Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão Criar a coluna dependente dentro da tabela na 2FN
3FN o
o o o
4FN
1. Cria-se uma tabela na 1FN referente à tabela N e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas; 2. Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas: A chave primária de uma das tabelas na qual a tabela em questão está aninhada As colunas da própria tabela 3. São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas
Copiar para o esquema da 3FN cada tabela que tenha menos de duas colunas não chave, pois neste caso não há como haver dependências transitivas Para tabelas com duas ou mais colunas não chaves, fazer a seguinte pergunta: ”a coluna depende de alguma outra coluna não chave?” Caso dependa apenas da chave Copiar a coluna para a tabela na 3FN Caso a coluna depender de outra coluna Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna na qual há a dependência indireta Copiar a coluna dependente para a tabela criada A coluna determinante deve permanecer também na tabela original
Em geral uma relação na BCNF já está na 4FN e 5FN, que surgem para resolver problemas muito raros
Uma relação encontra-se na 4FN, se está na BCFN e não existem dependências multivalor
Uma relação R está na 5FN se não puder ser mais decomposta sem perda de informação.
A normalização na 4a. Forma Normal requer que não exista nenhuma dependência multi-valorada não-trivial de conjuntos de atributos em algo mais de que um superconjunto de uma chave candidata
Mesmo tendo chegado na 3FN, pode ser que a uma entidade contenha um ou mais fatos multivalorados
Exemplos:
5FN
A 5a. Forma Normal requisita a não existência de dependências de joins não triviais que não venham de restrições chave.
A 5a. Forma Normal lida com relacionamentos múltiplos (ternário, quaternário, etc)
Uma entidade estará na 5FN, se estando na 4FN, não for possível reconstruir as informações originais a partir do conteúdo dos outros registros menores
O processo de Normalização ajuda imensamente o projetista do Banco de Dados, porém, em alguns casos, algumas formas normais eventualmente, podem ser ignoradas, visando o aprimoramento da performance do sistema
Caso 9
Sistema de uma loja de materiais elétricos: o Venda de materiais como fios, fusíveis, lâmpadas, etc o Padrões de entrada do cliente: postes de concreto, caixa de medidor, etc o Na venda de um padrão, o sistema deve baixar o estoque de cada um dos seus componentes o Cada um desses componentes pode ser comprado pela loja individualmente, ou sejam podem constar de vários pedidos de compra
Caso 10
Se realizarmos uma junção dessas três entidades, utilizando o atributo NumeroPedido como o determinante, teremos como resultado o seguinte:
Repare que o penúltimo registro abaixo (destaque) não havia na relação original
Se a junção for efetuada tomando o atributo Fornecedor, o resultado será:
Entidade:
Novamente, um registro que não existia na relação original é gerado
Durante o processo de normalização de dados, descobre-se duas situações, diametralmente opostas: o o número de campos das tabelas diminui enquanto o número de tabelas aumenta O SGBD gerencia tranquilamente e eficientemente, as associações que vão aumentando em função de análise do profissional
Exemplo
1a. Forma Normal
Uma Tabela está na 1a. FN quando seus atributos não contêm grupos de repetição (tabelas aninhadas): o Projeto (CodProjeto, Descricao, (CodFunc, Nome, Salario, DataInicio)) => Não está na 1FN o Projeto (CodProjeto, Descricao) => Está na 1FN o ProjFunc (CodProjeto, CodFunc, Nome, Salario, DataInicio) => Está na 1FN
2a. Forma Normal
Ocorre quando a chave primária é composta por mais de uma coluna Neste caso, deve-se observar se todas as colunas que não fazem parte da chave dependem de todos as colunas que compõem a chave Se alguma coluna depender somente de parte da chave composta (dependência funcional parcial), então esta coluna deve pertencer a outra tabela o ProjFunc (CodProj, CodFunc, Nome, Cargo, Salario, DataInicio) => Não está na 2FN o ProjFunc (CodProj, CodFunc, DataInicio) => Está na 2FN o Func (CodFunc, Nome, Cargo, Salario) => Está na 2FN
3a. Forma Normal
Uma tabela está na 3a. Forma Normal quando cada coluna não chave depende diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas Uma dependência funcional transitiva acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária o Func (CodFunc, Nome, Cargo, Salario) => Não está na 3FN o Func (CodFunc, Nome, CodCargo) => Está na 3FN o Cargo (CodCargo,Salario) => Está na 3FN
Forma Normal de Boyce-Codd
A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata) Aplica-se a FNBC quando: o Encontramos duas ou mais chaves candidatas o As chaves candidatas são compostas (apresentam mais de um atributo) o Todas as chaves candidatas têm um atributo em comum Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante Exemplo: o Assumindo que um professor possa estar associado a mais de uma escola e uma sala. o Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala, NomeProfessor)
Chaves candidatas: o NomeAluno + EnderecoAluno o Nomeluno + NroSala o NomeAluno + NomeProfessor
Encontramos três chaves candidatas o Todas apresentam mais de um atributo (concatenados) o Todas compartilham um mesmo atributo: NomeAluno
Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas o uma que contém todos os atributos que descrevem o aluno o outra que contém os atributos que designam um professor em uma determinada escola e número de sala
Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala) Sala (NomeEscola, NroSala, NomeProfessor)
4a. Forma Normal
Uma tabela está na 4a. Forma Normal caso não possua mais de uma dependência funcional multivalorada
Uma situação onde temos um controle de projetos ligados a funcionários e a equipamentos.
CodProj multidetermina de forma independente CodFunc e CodEquip.
5a. Forma Normal
Aplicada em casos de relacionamentos múltiplos Trata do conceito de dependência de junção
Primeiro decompõe-se a tabela através de uma operação de projeção e em seguida faz-se a reconstrução da mesma através de uma junção A tabela está na 5a. Forma Normal quando seu conteúdo não puder ser reconstruído através da junção destas tabelas secundárias
Reconstruindo o conteúdo da tabela original através da junção natural das tabelas secundárias
Índices
Depois de evoluir no: o projeto ER o refinamento do esquema o definição de visões podemos ter os esquemas conceitual e externo para o BD
Próximo passo: o escolher índices o fazer decisões de agrupamento o e (se necessário) refinar os esquemas conceitual e externo para atingir metas de desempenho.
Função do indice: o No contexto do livro, serve para procurar um determinado assunto identificando o volume ou página. o No contexto da estrutura de dados, o índice é uma referência associada a uma chave, que é utilizada para fins de otimização, permitindo uma localização mais rápida de um registro quando efetuada uma consulta. o No contexto de banco de dados, um índice tem a função de permitir que os registros com dados sejam encontrados com rapidez o Também oferecem um acesso alternativo aos registros sem que a posição física seja alterada Exemplo: Se precisarmos de uma lista dos alunos por ordem de CEP, é possível indexar e listar dessa maneira.
O processo pode ser iniciado pela compreensão do ambiente (negócio) onde será implantando e definir: o As consultas mais importantes e a frequência com que aparecem o As atualizações mais relevantes a frequência com que podem ser feitas o O desempenho desejado para estas consultas e atualizações.
Um índice pode ser: o simples: quando formado por apenas uma coluna o composto: referenciado por mais de uma coluna o interno: a chave está contida dentro da tabela o externo: quando existe uma tabela de chaves separada que associa ponteiros à registros de uma tabela
Que índices deve-se criar? o Quais relações devem ter índices? o Qual(is) campo(s) devem estar na chave de pesquisa?
o
Deve-se construir vários índices?
Devemos fazer mudanças no esquema conceitual? o Considerar esquemas normalizados alternativos? o Há várias escolhas na decomposição em formas normais, etc o Devemos “desfazer” alguns passos da decomposição e ficarcom uma forma normal mais baixa? o Desnormalização?
Considerações para Seleção de Índice: o É necessária a criação do índice? o Escolha da chave de busca o Utilizar múltiplos atributos na chave de busca o É necessário o agrupamento? o Devo usar hash ou árvore? Hash:Permite inserção de novos elementos mas ocupa maior quantidade de espaço Árvore: No caso de árvore binária, da busca é muito eficiente mas a tabela deve estar em ordem crescente
ou decrescente. o
Balanceamento do custo de manutenção do índice.
Os campos utilizados na definição dos índices denominam-se campos de indexação Os índices não contém dados propriamente ditos e sim valor de campo de indexação e ponteiros que direcionam para o registro adequado dentro da tabela o Inserindo ou excluindo o registro, força também uma alteração nos índices
Em alguns sistemas, os índices encontram-se separados do arquivo de dados
Exemplos Como o MySQL Utiliza Índices Os índices são utilizados para encontrar registros com um valor específico de uma coluna rapidamente. Sem um índice o MySQL tem de iniciar com o primeiro registro e depois ler através de toda a tabela até que ele encontre os registros relevantes. Quanto maior a tabela, maior será o custo. Se a tabela possui um índice para as colunas em questão, o MySQL pode rapidamente obter uma posição para procurar no meio do arquivo de dados sem ter que varrer todos os registros. Se uma tabela possui 1000 registros, isto é pelo menos 100 vezes mais rápido do que ler todos os registros sequencialmente. Note que se você precisar acessar quase todos os 1000 registros, seria mais rápido acessá-los sequencialmente porque evitaria acessos ao disco. Todos os índices do MySQL (PRIMARY, UNIQUE e INDEX) são armazenados em árvores B. Strings são automaticamente compactadas nos espaços finais e prefixados.
Indexação no Microsoft Office Acces
Na medida em que consultas de certos dados vão sendo realizadas, registros sendo classificados por um campo específico,
que com frequência é utilizado como referência, torna-se necessário utilizá-lo como índice em uma tabela. O Microsoft Office Acces procura o local dos dados através do índice e em alguns casos como em chaves primárias esta indexação é feita de maneira automática visando melhorar o desempenho do banco de dados. No entanto, alguns casos é provável que a definição do índice deverá ser feita manualmente.
O índice auxilia o MS Office Access a localizar e classicar os registros com mais rapidez. Tal índice armazena o local dos registros com base no(s) campo(s) escolhido(s) para ser(em) indexado(s). Após obter a localização do índice, os dados poderão ser recuperados.
A criação de índices pode ser baseada em um único campo ou em vários. Os campos mais propensos à indexação são aqueles citados em várias pesquisas, campos associados a campos de outras tabelas.
Se de uma forma os índices agilizam as pesquisas e consultas, de outra pode comprometer o desempenho na medida em que dados vão sendo criados ou atualizados. Quando os dados são inseridos em uma tabela que contém um ou mais campos indexados, o Access atualiza os índices cada vez que um registro é adicionado ou modificado. A adição de registros através de uma consulta acréscimo ou do acréscimo de registros importados provavelmente também será mais lenta se a tabela de destino contiver índices.
Para a indexação de um campo, alguns critérios deverão ser levados em consideração e as condições abaixo devem aplicáveis:
1) O tipo de dado do campo é Texto, Memorando, Número, Data/Hora, Auto numeração, Moeda, Sim/Não ou Hiperlink. 2) Você espera procura por valores armazenados no campo. 3) Você espera classificar por valores no campo. 4) Você espera armazenar diversos valores diferentes no campo. Se muitos dos valores no campo forem guais,provavelmente o índice não poderá acelerar significativamente as consultas.
Oracle
Oferece vários tipos de índices disponibilizando boas alternativas para todos os tipos de sistemas e processamentos no banco de dados Índices B-Trees: Índice padrão que o Oracle tem usado desde as primeiras versões. A fim de gerenciar corretamente os blocos, o Oracle controla o alocamento dos ponteiros dentro de cada bloco dos dados o Uma “árvore de blocos” (analogia à forma com a qual o Oracle aloca os blocos de dados) cresce através da inserção de linhas na tabela. Quando um bloco é preenchido, o mesmo “racha”, a fim de criar novos “galhos”, ou se preferir, blocos de dados. É ai que entra o índice do tipo B-Tree, controlando ponteiros dentro dos blocos de dados. o Um bloco de índice do Oracle pode conter dois tipos de ponteiros: Ponteiro para um outro nó de blocos de dados de índices
Ponteiros para linhas específicas da tabelas ou ROWID (endereço físico do registro , informando em qual arquivo e setor o dado se encontra).
Índice Bitmapped:
Lista dos valores distintos da coluna chave, onde cada um desses valores recebe um bitmap contendo um bit para cada linha da tabela O bit ligado indica que a linha específica contém o valor da coluna chave Sua estrutura, então, é apropriada para colunas chaves com pequena cardinalidade e com grande quantidade de linhas porém, a modificação dos valores da coluna chave revela o ponto fraco desse índice, uma vez que essa operação leva ao reajuste de grandes porções do bitmap e ao conseqüente bloqueio – lock – de uma grande quantidade de linhas da tabela, comprometendo a concorrência do ambiente
Índice Baseado em Função:
O algoritmo do otimizador dos SGBD comerciais desconsidera, na montagem do plano de acesso, o índice associado a uma coluna chave referenciada em uma função como, por exemplo, TO_CHAR ou TO_NUMBER Para suplantar essa limitação, os índices B-tree ou Bitmapped podem ser criados com a inclusão de uma função – padrão SQL ou construída pelo desenvolvedor – ou mesmo uma expressão aritmética, conforme a sentença de criação do índice necessário.
PostgreSQL: o B-Tree: Índices baseados em árvores B pois este padrão facilita consultas utilizando a igualdade de valores ou intervalos de valores (>= > = <
O comando CREAT INDEX cria um índice B-tree, que é adequado para a maioria das situações
R-tree
O índice R-tree é sempre utilizado quando a coluna indexada está envolvida em uma comparação utilizando um dos seguintes operadores:
>> @ ~= &&
Para criar um índice R-tree, podemos utilizar o seguinte código:
CREATE INDEX nome ON tabela USING RTREE (coluna);
Hash
O índice Hash é sempre utilizado quando a coluna indexada está envolvida em uma comparação utilizando o operador =. Código para criar um índice Hash:
CREATE INDEX nome ON tabela USING HASH (coluna);
Os índices Hash não possuem desempenho superior aos índices B-tree. Por este motivo é desaconselhado o uso de índices Hash no PostgreSQL
GiST
Os índices GiST não são um único tipo de índice, mas em vez disto uma infraestrutura dentro da qual podem sem implementadas muitas estratégias de indexação diferentes. Assim sendo, os operadores em particular com os quais o índice GiST pode ser utilizado variam dependendo da estratégia de indexação
Estruturas de Dados
Listas Lineares o Coleção ou agrupamento de dados, tendo cada elementos da lista uma referência de acordo com sua posição o Dependendo de como são tratados podemos ter: filas: parece-se com uma fila na vida real. Operação básica: FIFO. Uso: Impressão, ... pilhas: tipo de lista linear onde os elementos são inseridos e removidos a partir da extremidade final. Semelhança com uma pilha de pratos. Operação básica: LIFO. Uso: rotinas internas de avaliação de expressões matemáticas, controle de chamadas e retorno de funções.
Árvores o o o o o
Itens organizados de forma hierárquica se parecendo com uma árvore na vida real Possuem um nó principal chamado raiz, nós secundários chamados nós interiores e nós terminais chamados folhas Cada nó possui uma chave para organizar as informações e os dados propriamente ditos O nó superior é chamado de pai e o inferior de filho Muito comum o uso da árvore binária pois a chave de pesquisa permite iniciar a busca a partir da raiz que representa a posição central dentro do BD
Ordenação de Dados
Exercício V: Daniel o Método Bubble: Descrição do métido e Exemplo
Descrição:
O Método de bubble , ou ordenação por flutuação (literalmente "por bolha"), é um algoritmo de ordenação dos mais simples. A ideia é percorrer o vetor diversas vezes, a cada passagem fazendo flutuar para o topo o maior elemento da sequência. Essa movimentação lembra a forma como as bolhas em um tanque de água procuram seu próprio nível, e disso vem o nome do algoritmo.
No melhor caso, o algoritmo executa operações relevantes, onde 'n' representa o número de elementos do vetor. No pior caso, são feitas operações. A complexidade desse algoritmo é de Ordem quadrática. Por isso, ele não é recomendado para programas que precisem de velocidade e operem com quantidade elevada de dados.
Exemplo de como é feita a ordenação no método:
o
Método QuickSort: Descrição do métido e Exemplo
Descrição:
Quicksort é um método de ordenação muito rápido e eficiente, inventado por C.A.R. Hoare em 1960.
Este método adota a estratégia de divisão e conquista. A estratégia consiste em rearranjar as chaves de modo que as chaves "menores" precedam as chaves "maiores". Em seguida o Quicksort ordena as duas sublistas de chaves menores e maiores recursivamente até que a lista completa se encontre ordenada. Os passos são: Escolha um elemento da lista, denominado pivô; Rearranje a lista de forma que todos os elementos anteriores ao pivô sejam menores que ele, e todos os elementos posteriores ao pivô sejam maiores que ele. Ao fim do processo o pivô estará em sua posição final e haverá duas sublistas não ordenadas. Essa operação é denominada partição; Recursivamente ordene a sublista dos elementos menores e a sublista dos elementos maiores; A base da recursão são as listas de tamanho zero ou um, que estão sempre ordenadas. O processo é finito, pois a cada iteração pelo menos um elemento é posto em sua posição final e não será mais manipulado na iteração seguinte. o
Método Direct Insertion: Descrição do métido e Exemplo
O Método de inserção direta(Direct Insertion), é um simples algoritmo de ordenação, eficiente quando aplicado a um pequeno número de elementos. Em termos gerais, ele percorre um vetor de elementos da esquerda para a direita e à medida que avança vai deixando os elementos mais à esquerda ordenados. O algoritmo de inserção funciona da mesma maneira com que muitas pessoas ordenam cartas em um jogo de baralho como o pôquer.
Características: - Menor número de trocas e comparações entre os algoritmos de ordenação O(n) quando o vetor está ordenado. - Pior caso O(n²) o
Método Shell: Descrição do métido e Exemplo
Descrição:
Criado por Donald Shell em 1959, publicado pela Universidade de Cincinnati, Shell sort é o mais eficiente algoritmo de classificação dentre os de complexidade quadrática. É um refinamento do método de inserção direta. O algoritmo difere do método de inserção direta pelo fato de no lugar de considerar o array a ser ordenado como um único segmento, ele considera vários segmentos sendo aplicado o método de inserção direta em cada um deles.[3] Basicamente o algoritmo passa várias vezes pela lista dividindo o grupo maior em menores. Nos grupos menores é aplicado o método da ordenação por inserção.
A ordenação Shell utiliza a quebra sucessiva da sequência a ser ordenada e implementa a ordenação por inserção na sequência obtida. Por ser um método de complexidade O(n^2 ) não é aconselhável a sua implementação para sequências grandes, mas possui uma boa eficiência para as pequenas e medianas.
RAID
Índices: o o
o
o
Índice Primário: definido pela PRIMARY KEY e ordenam fisicamente os registros Índice Secundário: Otimizam as consultas feitas pelo comando SELECT do SQL. Não ordenam fisicamente os registros gravados nas tabelas mas são utilizados na localização de registros Índice Denso: O arquivo de índice possui uma entrada para cada registro armazenado no arquivo de dados, sendo assim, quando procuramos um registro utilizando o índice, ele nos remete diretamente para uma posição específica no arquivo ou tabela Índice Esparso: Armazenam apenas uma entrada para cada blocode dados armazenado no disco. O arquivo de dados é dividido em diversos blocos endereçáveis a partir de um tamanho padrão (1024 bytes por exemplo). Com um pesquisa binária podemos ter um melhoria na performance de até 10 vezes
RAID
Redundant Array Inexpensive/Independent Disk (Conjunto Redundante de Discos Econômicos/Independentes) o Agrupamento de discos rígidos que funcionam de forma concomitante ou paralela, com o objetivo de reduzir os riscos de danos causados a arquivos e aumentar a performance no acesso aos dados o Os discos podem trabalhar independentemente ou de forma sincronizada, com os dados espalhados entre eles o O RAID pode ser implementado via software ou hardware
Configuração
RAID 0 o o o o
São necessários ao menos 2 discos Os dados são fragmentados em segmentos consecutivos gravados sequencialmente em diferentes discos do conjunto O segmento possui um tamanho fixo, definido por bloco. Utiliza o máximo do espaço portanto sem garantia de redundância A idéia é espelhar as informações em um segundo disco de forma que o sistema grave os dados ao mesmo tempo nos dois discos
o
Protege os dados, pois caso um dos discos falhe, o sistema continua funcionando normalmente porém tem a desvantagem do custo, pois com dois Discos utiliza-se a área útil de apenas 1.
RAID 0 + 1
Exige pelo menos 4 discos na implementação com espelhamento de cada par de disco e os pares representando o RAID nivel 0 Ao mesmo tempo obtém-se ganho de desempenho e redundância O problema de usar RAID 0 + 1, é o custo alto que se tem com os discos, pois no mínimo se é obrigado a possuir 4 discos.
RAID I
Distribui os dados entre os discos mas além do espelhamento como faz o RAID 0, possui duplicidade de discos Para sua implementação são necessários pelo menos 2 discos.
RAID 2
Possui semelhança com o RAID 4 mas exige um disco extra onde são gravadas informações de controle de erros (ECC - Error Correcting Code) Ficou obsoleto depois que os novos drives de disco rígidos foram fabricados possuindo este controle no próprio circuito.
RAID 3
Possui como característica principal a gravação paralela com paridade O controle dos discos é bastante complexo uma vez que utiliza-se o menor tamanho possível para o segmentos de dados Desta forma, é necessário que todos os discos tenham seis eixos perfeitamente sincronizados, a fim de evitar o atraso na transferência dos dados.
RAID 4
Exige um conjunto de discos iguais, com um mínimo de 3 unidades. Um dos discos é reservado para gravação das informações de paridade dos dados, como no RAID 3 Os discos de gravação de dados são configurados para armazenar segmentos grandes o suficiente para conter um registro inteiro, o que permite a leitura independente dos dados.
RAID 5
Tem funcionamento similar ao RAID 4, mas em vez de gravar as informações de paridade num disco extra, elas são distribuídas pelos discos do conjunto, gravando-se um ou mais bits em cada disco RAID5 é conhecido como data guarding ou strip set com paridade
A implementação é possível devido à criação de informações a partir de cálculos booleanos feitos com o dado útil (a informação a ser gravada no disco), gravando essa paridade em um dos discos e de forma distribuída.
RAID 6
Novo tipo de relacionamento que trabalha de forma similar ao RAID 5 Utiliza o dobro de bits de paridade, o que permite que no caso de dois discos apresentarem falha, os dados permanecerão íntegros.