Banco de Dados Conceitos Fundamentais de Banco de Dados Artigo de Ricardo Rezende (ricardo@sqlmagazine.com.br) publicado na Revista Sql Magazine. Disponível on-line em http://www.devmedia. com.br/articles/viewcomp.asp?comp=1649 (acesso 15/12/08) (texto na íntegra) A idéia deste artigo não é a de reinventar a roda, mas sim a de trazer à tona todos os fundamentos que servem de pilar para o imenso mundo que é banco de dados. Conceitos Básicos Segundo Korth, um banco de dados é uma coleção de dados inter-relacionados, representando informações sobre um domínio específico, ou seja, sempre que for possível agrupar informações que se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco de dados. Abstração de dados O sistema de banco de dados deve garantir uma visão totalmente abstrata do banco de dados para o usuário, ou seja, para o usuário do banco de dados pouco importa qual unidade de armazenamento está sendo usada para guardar seus dados, contanto que os mesmos estejam disponíveis no momento necessário. Esta abstração se dá em três níveis (Figura 2): Nível de visão do usuário: as partes do banco de dados que o usuário tem acesso de acordo com a necessidade individual de cada usuário ou grupo de usuários; Nível conceitual: define quais os dados que estão armazenados e qual o relacionamento entre eles; Nível físico: é o nível mais baixo de abstração, em que define efetivamente de que maneira os dados estão armazenados. Podemos exemplificar situações clássicas como uma lista telefônica, um catálogo de CDs ou um sistema de controle de RH de uma empresa. Já um sistema de gerenciamento de banco de dados (SGBD) é um software que possui recursos capazes de manipular as informações do banco de dados e interagir com o usuário. Exemplos de SGBDs são: Oracle, SQL Server, DB2, PostgreSQL, MySQL, o próprio Access ou Paradox, entre outros. Por último, temos que conceituar um sistema de banco de dados como o conjunto de quatro componentes básicos: dados, hardware, software e usuários. Date conceituou que sistema de bancos de dados pode ser considerado como uma sala de arquivos eletrônica. A Figura 1 ilustra os componentes de um sistema de banco de dados. Figura 1. Componentes de um sistema de banco de dados. Os objetivos de um sistema de banco de dados são o de isolar o usuário dos detalhes internos do banco de dados (promover a abstração de dados) e promover a independência dos dados em relação às aplicações, ou seja, tornar independente da aplicação, a estratégia de acesso e a forma de armazenamento. Figura 2. Níveis de abstração. Projeto de banco de dados Todo bom sistema de banco de dados deve apresentar um projeto, que visa a organização das informações e utilização de técnicas para que o futuro sistema obtenha boa performance e também facilite infinitamente as manutenções que venham a acontecer. O projeto de banco de dados se dá em duas fases: 1. Modelagem conceitual; 2. Projeto lógico. Estas duas etapas se referem a um sistema de banco de dados ainda não implementado, ou seja, que ainda não exista, um novo projeto. Para os casos em que o banco de dados já exista, mas é um sistema legado, por exemplo, ou um sistema muito antigo sem documentação, o processo de projeto de banco de dados se dará através da utilização de uma técnica chamada de Engenharia Reversa, que será visto em outra oportunidade. Modelo conceitual É a descrição do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecerão no BD, mas sem se importar com a implementação que se dará ao BD. Desta forma, há uma abstração em nível de SGBD.
Uma das técnicas mais utilizadas dentre os profissionais da área é a abordagem entidaderelacionamento (ER), onde o modelo é representado graficamente através do diagrama entidaderelacionamento (DER) (Figura 3). Figura 3. Exemplo de diagrama entidaderelacionamento. O modelo acima, entre outras coisas, nos traz informações sobre Alunos e Turmas. Para cada Aluno, será armazenado seu número de matrícula, seu nome e endereço, enquanto para cada turma, teremos a informação de seu código, a sala utilizada e o período. Modelo Lógico Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de SGBD que será usado. Não podemos confundir com o Software que será usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é relacional, orientado a objetos, hierárquico, etc. Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados são organizados em tabelas (Quadro 1). Aluno Mat_aluno Nome Endereço 1 Cecília Ortiz Rezende Rua dos Ipês, 37 2 Abílio José Dias Av.Presidente Jânio Quadros 3 Renata Oliveira Franco Rua Nove de Julho, 45 Turma Cod_turma Sala Período 1 8 Manhã 2 5 Noite Quadro 1. Exemplo de tabelas em um SGBD relacional. O modelo lógico do BD relacional deve definir quais as tabelas e o nome das colunas que compõem estas tabelas. Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o seguinte: Aluno(mat_aluno, nome, endereco) Turma (cod_turma, sala, periodo) É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema. Conclusões Nesta primeira coluna, abordei os conceitos básicos de banco de dados. Estes conceitos são os primeiros passos para se aventurar em projetos de bancos de dados. Vimos algumas terminologias e conceitos que são importantes para iniciar um projeto de maneira a documentar todas as etapas tendo assim, uma ferramenta de apoio fundamental para a implementação e manutenção futura no sistema. Ricardo Rezende Conceitos Fundamentais de Banco de Dados (parte 2) Artigo de Ricardo Rezende Parte 2 (ricardo@sqlmagazine.com.br) publicado na Revista Sql Magazine. Disponível on-line em http://www.devmedia.com.br/articles/viewcomp.asp?comp=1678 (acesso 15/12/08) (texto na íntegra) Histórico A melhor maneira de entendermos o presente é conhecendo o passado. Seguindo uma dica de um amigo, Fernando Boaglio (www.boaglio.com), neste artigo irei abordar os primórdios dos bancos de dados, mostrando sua evolução e cronologia até os dias de hoje. Em muitos momentos conseguimos entender exatamente o motivo que trouxe a tecnologia ao atual estágio de amadurecimento e podemos inclusive arriscar alguns palpites das tendências para os próximos anos. Não tenho a pretensão de ser um guru ou vidente, apenas tentarei esclarecer o internauta de como as coisas aconteceram neste nosso mundo dos bancos de dados. Boa leitura! Do antigo ao recente Temos que voltar aos registros de bibliotecas, negócios em geral, registros policiais, fichas de pacientes e todas as informações armazenadas de maneira impressa para consultas posteriores. Foi lá que tudo começou. Havia um histórico muito longo de informações armazenadas desta maneira e também uma metodologia de indexação e recuperação da informação quando se precisava dela. Não se pode ignorar esta história, pois há muito a se aprender com os sucessos e fracassos deste pessoal que manipulava estas informações. Boas práticas e bons princípios de projetos de bancos de dados datam aquela época e muito se aprendeu para a criação de bons projetos que alcançam boa performance, segurança e confiabilidade. Década de 60 Os computadores se tornam parte efetiva do custo das empresas juntamente com o crescimento da capacidade de armazenamento. Foram desenvolvidos dois principais modelos de dados: modelo em rede (CODASYL - Comitee for Data Systems Language) e o modelo hierárquico (IMS Information Management System). O acesso ao BD é feito através de operações de ponteiros de baixo nível que unem (link) os registros. Detalhes de armazenamento dependiam do tipo de
informação a ser armazenada, desta forma, a adição de um campo extra necessitava de uma reescrita dos fundamentos de acesso/modificação do esquema. Os usuários precisavam conhecer a estrutura física do BD para poder realizar uma consulta. Modelo de dados em rede (Figura 1): Os primeiros trabalhos foram realizados em 1964 por Charles Bachman; Dados são representados por uma coleção de registros e os relacionamentos por meio de links; É representado por um diagrama constituído por caixas e linhas; São usados apenas relacionamentos muitos-paramuitos. Figura 1. Representação de um modelo de dados em rede. Modelo de dados hierárquico (Figura 2) Também se utilizava de registros para representar os dados e links para os relacionamentos; São organizados na forma de uma árvore com raiz; Como Exemplo: Clipper, Dbase 2, Fox Pro, COBOL. Década de 70 Muitas discussões a respeito do valor da competição entre os sistemas enquanto a teoria de banco de dados conduz ao objetivo final de projeto de pesquisa. Dois principais protótipos de sistema relacional foram desenvolvidos entre 1974 e 1977 e demonstram um ótimo exemplo de como a teoria conduz a boas práticas. Ingres: Desenvolvido pela UCB. Que no final das contas serviu como base para Ingres Corp., Sybase, MS SQL Server, Britton-Lee, Wang PACE. Este sistema utilizava QUEL como linguagem de consulta; System R: Desenvolvido pela IBM San Jose e serviu de base para o IBM SQL/DS, IBM DB2, Oracle, todas os BD da HP, Tandem's Non- Stop SQL. Este sistema utilizava SEQUEL como linguagem de consulta. O termo Sistema de Gerenciamento de Banco de Dados Relacional (SGBDR RDBMS em inglês) foi definido durante este período. 1976 O Dr. Peter Chen (visite bit.csc.lsu.edu/~chen/chen.html (Figura 4) propõe o modelo Entidade-Relacionamento (ER) para projetos de banco de dados dando uma nova e importante percepção dos conceitos de modelos de dados. Assim como as linguagens de alto nível, a modelagem ER possibilita ao projetista concentrar-se apenas na utilização dos dados, sem se preocupar com estrutura lógica de tabelas. Figura 4. Dr. Peter Chen, criador do modelo ER. Início dos anos 80 Figura 2. Representação de um modelo de dados hierárquico. O maior sucesso comercial foi o sistema SABRE, desenvolvido pela IBM e American Airlines. 1970 1972 Edgar Frank Codd (Figura 3) propõe o modelo de dados relacional, que se tornou um marco em como pensar em banco de dados. Ele desconectou a estrutura lógica do banco de dados do método de armazenamento físico. Este sistema se tornou padrão desde então. Figura 3. Dr. Edgar Frank Codd, o pai do modelo relacional. Conheça mais o trabalho do Dr. Codd em http://www.informatik.unitrier.de/~ley/db/about/codd.html A comercialização de sistemas relacionais começa a virar uma febre entre as organizações. Metade dos anos 80 A Linguagem Estruturada de Consulta SQL (Structured Query Language) se torna um padrão mundial. A IBM transforma o DB2 como carro chefe da empresa em produtos para BD. Os modelos em rede e hierárquico passam a ficar em segundo plano praticamente sem desenvolvimentos utilizando seus conceitos, porém vários sistemas legados continuam em uso. O desenvolvimento do IBM PC desperta muitas empresas e produtos de BD como: RIM, RBASE 5000, PARADOX, OS/2 Database Manager, Dbase III e IV (mais tarde transformado em FoxBase e mais tarde ainda como Visual FoxPro), Watcom SQL, entre outros. Início dos anos 90 Tem início uma leve crise econômica nas indústrias e algumas empresas sobrevivem oferecendo alguns
produtos a custos muito elevados. Muito desenvolvimento acontece em ferramentas de desenvolvimento para o desktop no desenvolvimento de aplicações (client tolls), tais como: PowerBuilder (Sybase), Oracle Developer, Visual Basic (Microsoft), entre outros. O modelo cliente-servidor (client-server) passa a ser uma regra para futuras decisões de negócio e vemos o desenvolvimento de ferramentas de produtividade como Excel/Access (Microsoft) e ODBC, também é marcado como o início dos protótipos de Object Database Management Systems (ODBMS). Metade dos anos 90 É quando vemos a explosão da Internet./WWW e uma louca corrida para prover acesso remoto a sistemas de computadores com dados legados. Percebe-se um crescimento exponencial na tecnologia Web/BD. Aumentam o uso de soluções de código aberto (open source) através de gcc, cgi, Apache, MySQL, etc. Processos de transação em tempo real (OLTP - On- Line Transaction Process) e processos analíticos em tempo real (OLAP On-Line Analitical Process) atingem maturidade através de muitos negócios utilizando os PDVs (Ponto de Venda). Final dos anos 90 O grande investimento em empresas de Internet impulsiona as vendas de ferramentas para conexão Web/Internet/BD. Active Server Pages, Front Page, Java Servlets, JDBC, Enterprise Java Beans, ColdFusion, Dream Weaver, Oracle Developer 2000, são um exemplo dessas ferramentas. Chegamos ao século 21 Vemos a decadência da indústria da Internet de uma maneira geral, mas sólidos crescimentos em aplicações para BD continuam. Aparecem mais aplicações que interagem com PDAs (Personal Digital Assistant), transações em PDVs, consolidação de vendas, etc. Três companhias predominam no amplo mercado de BD: IBM (que comprou a Informix), Microsoft e Oracle. 2003 Em 18 de abril, morre o pai do modelo relacional, o Dr. Edgar Frank Ted Codd. Aos 76 anos de idade, em sua casa na Flórida. Nascido em 1923 em Portland, na Inglaterra. O caçula de 07 irmãos, filho de pai fabricante de artigos de couro e mãe professora. Quais as tendências? Sistemas gigantescos (Terabytes) estão surgindo e necessitarão cada vez mais de novos recursos para manipulação e análise dos dados. Estamos presenciando grandes projetos envolvendo BD como o projeto Genoma, geologia, segurança nacional e dados de exploração espacial. Data mining, data warehousing, data marts são técnicas utilizadas atualmente e no futuro serão utilizados cada vez mais, sem dúvida alguma. Sistemas de compras personalizadas e inteligentes serão fato e utilizarão histórico de vendas. Sucessores do SQL (e quem sabe dos Sistemas de Gerenciamento de Banco de Dados Relacionais RDBMS, em inglês) surgirão no futuro. Várias tentativas de padronizar um sucessor do SQL não foram bem sucedidas. SQL92, SQL2 e SQL3 ainda estão pouco potentes e mais extensões são difíceis de implementar. Muito provavelmente isto será alcançado pelo XML e outras técnicas emergentes. XML com Java para BD é a nova aposta como o próximo grande acontecimento. Vejamos mais tarde o que mais será novidade. O uso de BD móveis são os novos produtos que vem surgindo para comercialização em vários segmentos. Processos de transações distribuídas começam a se tornar uma regra em várias áreas de planejamento de negócios. Provavelmente veremos uma leve crise nas vendas dos RDBMS e Linux com Apache suportarão MySQL (e até mesmo Oracle) com um hardware relativamente barato e isso será a maior ameaça ao alto custo de sistemas legados da Oracle e DB2 e então se dará início a projetos para manter seus clientes. Tudo será orientado a objeto, inclusive os BD. Object Database Management Group (ODMG) propôs um padrão que foi aceito e, quem sabe, algo venha deles. Assuntos como ética e segurança tendem a diminuir, mas invariavelmente voltarão à tona. Seremos capazes de consultar um BD de registros médicos/genéticos de um futuro empregado de nossa empresa? Poderemos consultar as informações de um(a) futuro(a) companheiro(a) / namorado(a) para descobrir possíveis falhas ou distúrbios genéticos? A submarino.com poderá ficar de olho nas suas compras de livros ou CDs? Haverá um banco de dados nacional com informações de estupradores, assassinos, traficantes? Quem terá permissão de fazer rastreamentos na Web? Quantas vezes, nestes últimos seis meses, você visitou uma sala de bate-papo, site pornográfico, site de sátira política, visitou o site da SQL Magazine? Quem terá permissão de armazenar ou ver estas informações?
E o questionamento mais difícil de se responder: Quem tomará estas decisões? Conclusões Como podemos perceber, a história nos ensina muito do que somos hoje. Não voltaremos ao passado para trabalhar com o velho WordStar, mas é extremamente importante aprendermos com o passado para decidirmos melhor o nosso futuro afinal, o futuro está em nossas mãos. Conceitos Fim do artigo Modelagem conceitual Nesta fase, é construído um modelo conceitual na forma de um diagrama entidade-relacionamento (DER). o Este modelo captura as necessidades da organização em termos de armazenamento de dados de forma independente de implementação. Projeto lógico Esta etapa objetiva transformar o modelo conceitual obtido na primeira fase em um modelo lógico. o O modelo lógico define como o banco de dados será implementado em um TIPO de SGBD específico.* Álgebra Relacional Primitivas e Binárias 1. Χ Produto Cartesiano combinação de Tuplas. Correlação: SELECT 2. U União - cria uma relação partindo de duas outras. Correlação: UNION 3. Diferença - obter uma relação a partir da diferença da primeira pela segunda relação. Correlação: NOT IN Específicas para relações Primitivas e Unárias 4. σ Seleção - Retorna tuplas que satisfazem um predicado. Subconjunto horizontal de uma relação. Correlação: WHERE. <, =, >, AND, NOT, IN 5. π Projeção retorna um ou mais atributos. Correlação: SELECT. 6. ρ Renomeação - renomear uma relação com outro nome, permitindo desta forma o uso desta como primeiro operando Permite também renomear atributos. Adicionais 7. Interseção - todas as tuplas que pertençam a ambas as relações presentes na operação. Correlação: INNER JOIN, =, IN 8. Divisão - produz como resultado a projeção de todos os elementos da primeira relação que se relacionam com todos os elementos da segunda relação. Correlação: IN 9. X Junção - junção é utilizada para combinar tuplas de duas relações partindo dos atributos comuns a ambas. Correlação: INNER JOIN, OUTER JOIN, LEFT JOIN, RIGHT JOIN IDEMPOTENTES o Onde de pode aplicar IdemPotência: o União, Interseção e Junção Isolamento das Transações O Padrão SQL ANSI/ISSO define quatro níveis de isolamento de transações baseados nas seguintes situações: Dirty Reads ocorre quando uma transação lê dados escritos por uma transação corrente que ainda não foi confirmada (COMMIT). Non-Repeatable Reads uma transação lê um dado que ela já havia lido anteriormente, e descobre que aqueles dados foram modificados por outra transação (confirmada após a primeira leitura). Phantom Read uma transação lê um conjunto de linhas que satisfaça algum critério de pesquisa. Outra transação insere uma linha que satisfaça o critério da anterior. Se a primeira transação executar novamente o comando de pesquisa, ela receberá um conjunto diferente de linhas. Os quadros de níveis de isolamentos são descritos a seguir para você entender melhor. Read Uncommitted Uma transação pode enxergar dados não confirmados por outra transação Read Committed Uma transação não pode enxergar dados não confirmados por outra transação, até que estes dados sejam confirmados. Repeatable Read Uma transação neste nível garante que valores já lidos não possam ser alterados por outra transação. Serializable Uma transação só poderá interagir com outras transações concorrentes no sentido de produzir o mesmo efeito, como se cada transação estivesse sendo executada uma após a outra. A tabela a seguir mostra quais situações podem ocorrer em cada um dos níveis de isolamento: Nível Read Uncommitted Read Committed Repeatable Read Dirty Reads Non- Repeatable Reads Phantom Read Possível Possível Possível Impossível Possível Possível Impossível Impossível Possível
Serializable Níveis de ABSTRAÇÃO de DADOS Impossível Impossível Impossível Sistema BD deve prover uma visão abstrata de dados para os usuários, isolando, desta forma, detalhes mais internos do BD. Nível físico ou Interno descreve como os dados estão realmente armazenados, englobando estruturas complexas de baixo nível. Nível conceitual ou lógico Esquema Conceitual, descreve quais os dados estão armazenados e seus relacionamentos. descrito através de estruturas relativamente simples Nível de visões do usuário ou nível externo:, descrevendo partes do BD que serão visualizadas pelos usuários de acordo com suas necessidades. Subconjunto de dados do BD, sem que exista a necessidade de estarem armazenados no BD. Provê a independência lógica e física dos dados. Independência lógica possui a capacidade de mudar o esquema conceitual sem a necessidade de modificar programas da aplicação e esquemas externos, enquanto que a física tem a capacidade de mudar o esquema interno sem a necessidade de alterar os esquemas conceitual e externo. 12 Regras de Codd Regra das informações em tabelas Regra de a- cesso garantido: Regra de tra- devem ser apresentadas como relações (tabelas formadas por linhas e colunas). Vinculo entre tabelas por campos comuns tanto aos dados quanto aos metadados o método de referência deve ser o nome da tabela, o valor da chave primária e o nome do campo/coluna. permita a distinção de dados retamento sistemático de valores nulos catálogo relacional ativo: atualização de alto-nível sublinguagem de dados abrangente independência física independência lógica atualização de visões independência de integridade independência de distribuição nãosubversiva Conceitos Cardinalidade x Modalidade ais. Valores nulos devem ter um tratamento diferente de valores em branco. estrutura do banco de dados (domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em tabelas (também referenciadas como catálogo). capacidade de manipular as informações do banco de dados em grupos de registros, ou seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo. Pelo menos uma linguagem deve ser suportada, para que possa manipular a estrutura do banco de dados (como criação e alteração de tabelas), assim como extrair, inserir, atualizar ou excluir dados Se houve modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser necessárias nas aplicações que fazem uso do banco alteração na estrutura do banco de dados como inclusão ou exclusão campos da tabela ou alteração no relacionamento entre tabelas não deve afetar os aplicativo deve ser capaz de efetuar alterações, exclusões e inclusões nelas e devem ser repassadas para tabelas originais (integridade de entidade, integridade referencial, restrições,etc) precisam ser estabelecidas dentro do catálogo ou dicionário de dados, e ser totalmente independentes da lógica dos aplicativos. SGBD s podem ser distribuídos em diversas plataformas que se encontrem interligados em rede.isto não pode afetar a funcionalidade do sistema e dos aplicativos O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do banco de dados e restrições, Cardinalidade é a especificação do número de ocorrências de um item que pode ser relacionado com o número de ocorrências de outro item; (1:1, 1:N, N:M). É o número de
entidades ao qual outra entidade pode estar associada via um relacionamento Modalidade ou totalidade indica se um item precisa ou não participar em um relacionamento; (obrigatório ou opcional) Relação conjunto de n-tuplas ou tuplas onde cada tupla t é uma lista ordenada de n valores v t=(v1,v2,vn) onde cada elemento Vn é um elemento do domínio de atributos ou tem valor especial nulo. o Os SGBD s relacionais representam as relações por meio de tabelas o As tuplas de uma relação não são ordenadas o Os atributos não são relacionados o Cada tupla contém apenas um valor para cada atributo (1Fnormal) Relacionamento o "É uma associação entre entidades".(korth) o "É uma estrutura abstrata que indica as associações entre elementos de um conjunto de entidades e elementos de outro conjunto de entidades".(betzer) o Identificado a chave estrangeira participa da chave primária na tabela filha o Não-Identificado a chave estrangeira é um campo comum e não participa da chave primária na tabela filha Conjunto De Relacionamentos é um conjunto formado por relacionamentos de um mesmo tipo. o cliente e empréstimo:. O conjunto de relacionamentos devedor denota a associação entre clientes e empréstimos bancários contraídos pelo cliente. Instância Os dados atuais armazenados no BD em um momento particular. Também chamado estado do banco de dados. Entidades são objetos ou "coisas" do mundo real que possuem uma existência independente e são de interesse para uma determinada aplicação. o "Uma entidade é uma representação abstrata de um objeto do mundo real um ser, um fato, uma coisa, um organismo social, etc)." (Setzer) o Uma entidade é um objeto que existe e é distinguível de outros objetos. (Korth) o Entidade Forte (Dominante) Aquela que possui chave primária o Entidade fraca (subordinada ) Aquela que sua chave primária é composta da chave primária da entidade forte e de atributo identificador (chave candidata) da entidade fraca Atributos são propriedades usadas para descrever uma entidade. Mapeia um conjunto de entidades em um domínio. o "Funções que levam um ponto de um conjunto de entidades a um ponto de um conjunto - de valores (ou seja, registram o que se deseja descrever sobre uma entidade".( Chen:) o "Atributo é uma função que mapeia um conjunto de entidades em um domínio".( Korth:) Tipos de Atributo o Simples com um único núcleo. Não se dividem em partes. Ex.: idade, iniciais o Compostos compostos (com n atributos simples, exemplo: Endereco = rua+numero+bairro+cidade+uf) o Monovalorado somente um valor para cada instância. Ex: Nome, Data Nascimento o Multivalorado Vários valores para cada instância. Ex: Dependentes o Derivados São obtidos a partir de valores de outra entidade ou atributos. Ex: TempoEmpresa (data atual dataentrada na entidade contrato), idade (pela data de aniversário o Nulo quando não se apresenta valores para o mesmo Domínio Conjunto de valores permissíveis de um determinado atributo. Tipo de dado (int, caracter, {AM,DF, SP} Independência física Capacidade de se modificar o esquema físico sem alterar os programas de aplicação Independência lógica Capacidade de se modificar o esquema conceitual sem alterar os programas de aplicação Chaves SuperChave Conjunto de um ou mais atributos que, tomados em conjunto, permite identificar unicamente uma entidade no conjunto de entidades Chaves candidatas Superchaves menores possíveis, em que nenhum subconjunto próprio é superchave. Seja K um conjunto de atributos da variável de relação R. Então, K é uma chave candidata para R se e somente se ela possui as seguintes propriedades: o Unicidade nenhum valor válido de R contém duas tuplas diferentes com o mesmo valor para K o Irredutibilidade nenhum subconjunto próprio de K tem a propriedade de unicidade Chave Primária Chave candidata escolhida pelo projetista do banco de dados como mecanismo principal para a identificação de en-
tidades no conjunto de entidades (chave primária) Chave Alternativa Chave candidata não escolhida para ser chave primária Chave Estrangeira Conjunto de atributos de uma relação R2 cujos valores devem obrigatoriamente corresponder a valores de alguma chave candidata de alguma variável de relação R1 Chave Substituta (surrogate key) ou artificial Chave criada artificialmente para identificar uma entidade não tendo nenhum significado no negócio Linguagens DML (Data Manipulation Language) o Procedimental Específica quais dados são desejados e como chegar a eles o Não procedimental Especifica quais dados são desejados, sem especificar como chegar a eles DDL (Data Definition Language) - Linguagem de Definição de Dados). Exemplos: o permite ao usuário definir tabelas novas e elementos associados. A maioria dos bancos de dados de SQL comerciais tem extensões proprietárias no DDL. o CREATE cria um objeto (uma Tabela, por exemplo) dentro do base de dados; o DROP apaga um objeto do banco de dados. o ALTER TABLE; DCL (Data Control Language) é a linguagem de controle de dados, usada pelo DBA para controlar o acesso aos dados pelos usuários. Possui comandos de atribuição e remoção de privilégios. Exemplos: Grant, Revoke, Profile Restrições de Integridade De Domínio especifica que, para um certo atributo A de uma relação, todo valor associado a A deve ser atômico e pertencente ao domínio deste atributo Referencial que se uma tupla T2 de uma relação R2 referencia uma tupla T1 de uma relação R1,então a tupla T1 deve existir ou ser nula De Vazio (nulo) Se o valor de um a- tributo pode ou não ser nulo De Chave especifica que nenhuma das tuplas de uma relação pode possuir valor nulo para nenhum dos atributos que formam sua chave primária Formas Normais (1FN) Primeira Forma Normal Uma relação está na primeira forma normal (1FN) se não possuir grupos de repetição ( ou seja, se todos atributos na relação estiveram baseados em domínios simples ). o Uma relação está na 1FN se somente todos os domínios básicos contiverem somente valores atômicos (não contiver grupos repetitivos). Para atingir esta forma normal devemos eliminar os grupos de repetição. (2FN) Segunda Forma Normal Uma relação R está na 2FN se e somente se ela estiver na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela) o Uma relação está na 2ª forma normal se está na 1ª FN e os atributos que não são chave dependem da totalidade da chave. (3FN) Terceira Forma Normal Uma relação R está na 3FN se somente estiver na 2FN e todos os atributos não chave forem dependentes não transitivos da chave primária (cada atributo for funcionalmente dependente apenas dos atributos componentes da chave primária ou se todos os seus atributos não chave forem independentes entre si o Uma relação está na Terceira Forma Normal se estiver na 2FN e todos os atributos não chave forem dependentes não transitivos da chave primária (BCNF) Forma Normal Boyce-Codd - Uma relação está na FNBC se e só se todo o determinante da relação for uma chave candidata. REFERÊNCIAS BIBLIOGRÁFICAS. DATE, C, J. Introdução Sistemas de Bancos de Dados. 7ª edição, Rio de Janeiro - RJ; Editora Campus 1999. HEUSER, Carlos Alberto. Projeto de banco de dados, Imprenta: 3ª ed. Porto Alegre:Sagra Luzzatto, 2000 SILBERSCHARTZ, Abraham; KORTH, Henry; SUDARSHAN, S. Sistemas de Banco de Dados. 3º edição, São Paulo: Makron Books 1999 Atualizado em: 15/dez/2008