Banco de Dados - Prof. Edilberto Silva

Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
Abstração de dados
Banco de Dados
Conceitos Fundamentais de Banco de Dados
Artigo
de
Ricardo
Rezende
([email protected]) 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)
http://edilms.eti.br
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):
“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.
•
•
•
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.
Figura 2. Níveis de abstração.
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.
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.
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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).
http://edilms.eti.br
delo 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
Figura 3. Exemplo
relacionamento.
de
diagrama
entidade-
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
1
Cecília Ortiz Rezende
2
Abílio José Dias
3
Renata Oliveira Franco
Turma
Cod_turma Sala
1
8
2
5
Quadro 1. Exemplo de tabelas em um
Endereço
Rua dos Ipês,
37
Av.Presidente
Jânio Quadros
Rua Nove de
Julho, 45
Período
Manhã
Noite
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 mo-
Conceitos Fundamentais de Banco de Dados (parte 2)
Artigo
de
Ricardo
Rezende
Parte
2
([email protected]) 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
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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;
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 NonStop SQL. Este sistema utilizava SEQUEL como linguagem de consulta.
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.
http://edilms.eti.br
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
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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 - OnLine 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.
http://edilms.eti.br
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?
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.
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?
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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. “
http://edilms.eti.br
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
Fim do artigo
Conceitos
• 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
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
Dirty
Reads
Possível
Read CommitImpossível
ted
Repeatable
Read
NonPhantom
Repeatable
Read
Reads
Possível
Possível
Possível
Possível
Impossível Impossível
Possível
Resumo – tópicos de Banco de Dados I
Serializable
prof. Edilberto Silva
Impossível Impossível Impossível
Níveis de ABSTRAÇÃO de DADOS
•
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.
http://edilms.eti.br
tamento sis- ais. Valores nulos devem ter um
temático de tratamento diferente de “valores
valores nulos em branco”.
estrutura do banco de dados (domínios, campos, tabelas, regras
catálogo rela- de integridade, índices, etc) deve
cional ativo: estar disponível em tabelas (também referenciadas como catálogo).
capacidade de manipular as informações do banco de dados em
atualização de
grupos de registros, ou seja, ser
alto-nível
capaz de inserir, alterar e excluir
vários registros ao mesmo tempo.
sublinguagem de
dados abrangente
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 armazenaindependência dos fisicamente, nenhuma alterafísica
çã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 excluindependência
são campos da tabela ou alteralógica
ção no relacionamento entre tabelas não deve afetar os aplicativo
deve ser capaz de efetuar alteraatualização de ções, exclusões e inclusões nelas
visões
e devem ser repassadas para
tabelas originais
(integridade de entidade, integridade referencial, restrições,etc)
independência precisam ser estabelecidas dentro
de integridade 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
independência
encontrem interligados em rede distribuide.Isto não pode afetar a
ção
funcionalidade do sistema e dos
aplicativos
12 Regras de Codd
Regra das
informações
em tabelas
devem ser apresentadas como
relações (tabelas formadas por
linhas e colunas). Vinculo entre
tabelas por campos comuns tanto
aos dados quanto aos metadados
Regra de acesso garantido:
o método de referência deve ser o
nome da tabela, o valor da chave
primária e o nome do campo/coluna.
Regra de tra-
permita a distinção de dados re-
nãosubversiva
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,
Conceitos
Cardinalidade x Modalidade
•
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
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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)
•
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:)
•
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 "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 As tuplas de uma relação não são ordenadas
o
o Compostos compostos (com n atributos simples, exemplo: Endereco = rua+numero+bairro+cidade+UF)
Os atributos não são relacionados
o Cada tupla contém apenas um valor para cada atributo (1Fnormal)
•
o Monovalorado somente um valor para cada instância. Ex: Nome, Data Nascimento
Relacionamento
o "É uma
des".(Korth)
associação
entre
entida-
o Multivalorado Vários valores para
cada instância. Ex: Dependentes
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 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 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.
http://edilms.eti.br
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
•
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.
•
SuperChave Conjunto de um ou
mais atributos que, tomados em conjunto, permite identificar unicamente uma entidade no
conjunto de entidades
o "Uma entidade é uma representação
abstrata de um objeto do mundo real um
ser, um fato, uma coisa, um organismo social, etc)." (Setzer)
•
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 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
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-
Resumo – tópicos de Banco de Dados I
prof. Edilberto Silva
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
http://edilms.eti.br
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.
o Procedimental Específica quais dados são desejados e como chegar a eles
•
(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 Não procedimental Especifica quais
dados são desejados, sem especificar como chegar a eles
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.
Linguagens
•
DML (Data Manipulation Language)
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.
•
(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
CREATE cria um objeto (uma
Tabela, por exemplo) dentro do base de
dados;
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”
•
DDL (Data Definition Language)
Linguagem de Definição de Dados).
-
Exemplos:
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 atributo 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
•
(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