Você está na página 1de 8

Resumo – tópicos de Banco de Dados I

prof. Edilberto Silva

http://edilms.eti.br

Banco de Dados

Conceitos Fundamentais de Banco de Dados

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

15/12/08) – (texto na íntegra)

(acesso

Artigo

de

Ricardo

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

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 componen- tes 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 ban- co de dados.

1 ilustra os componentes de um sistema de ban- co de dados. Figura 1. Componentes de

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.

Abstração de dados

O sistema de banco de dados deve garantir uma vi-

sã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 mes- mos 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.

efetivamente de que maneira os dados estão armazenados. Figura 2. Níveis de abstração. Projeto de banco

Figura 2. Níveis de abstração.

Projeto de banco de dados

Todo bom sistema de banco de dados deve apre- sentar 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 infinitamen- te 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 ban- co 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 le- gado, por exemplo, ou um sistema muito antigo sem documentação, o processo de projeto de banco de da- dos se dará através da utilização de uma técnica cha- mada 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

http://edilms.eti.br

Uma das técnicas mais utilizadas dentre os profis- sionais da área é a abordagem entidade- relacionamento (ER), onde o modelo é representado graficamente através do diagrama entidade- relacionamento (DER) (Figura 3).

do diagrama entidade- relacionamento (DER) (Figura 3). Figura 3. Exemplo relacionamento. de diagrama entidade- O

Figura

3.

Exemplo

relacionamento.

de

diagrama

entidade-

O modelo acima, entre outras coisas, nos traz infor-

maçõ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 infor- maçã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 pode- mos 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 Fran- co

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 mo-

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 ferra- menta de apoio fundamental para a implementação e manutenção futura no sistema.” Ricardo Rezende

Conceitos Fundamentais de Banco de Dados (parte 2)

Parte 2

(ricardo@sqlmagazine.com.br) publicado na Revista Sql

Magazine. Disponível on-line em

http://www.devmedia

(acesso

15/12/08) – (texto na íntegra)

Artigo de Ricardo Rezende

.com.br/articles/viewcomp.asp?comp=1678

Histórico

A melhor maneira de entendermos o presente é co- nhecendo 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 exa- tamente 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, ape- nas 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 impres- sa para consultas posteriores. Foi lá que tudo começou. Havia um histórico muito longo de informações armaze- nadas 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 performan- ce, segurança e confiabilidade.

Década de 60

Os computadores se tornam parte efetiva do custo das empresas juntamente com o crescimento da capa- cidade 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

http://edilms.eti.br

informação a ser armazenada, desta forma, a adição de um campo extra necessitava de uma reescrita dos fun- damentos 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-para- muitos.

São usados apenas relacionamentos muitos-para- muitos. Figura 1. Representação de um modelo de dados em rede.

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 re- presentar os dados e links para os relacio- namentos;

São organizados na forma de uma árvore com raiz;

Como Exemplo: Clipper, Dbase 2, Fox Pro, COBOL.

raiz; ∑ Como Exemplo: Clipper, Dbase 2, Fox Pro, COBOL. Figura 2. Representação de um modelo

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 estrutu- ra lógica do banco de dados do método de armazena- mento físico. Este sistema se tornou padrão desde en- tão.

Figura 3. Dr. Edgar Frank Codd, o pai do modelo re- lacional.

Conheça mais o trabalho do Dr. Codd em

http://www.informatik.uni-

trier.de/~ley/db/about/codd.html

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 desen- volvidos 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 co- mo 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 co- mo 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 tabe- las.

Figura 4. Dr. Peter Chen, criador do modelo ER.

Início dos anos 80

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 (Struc- tured 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árqui- co passam a ficar em segundo plano praticamente sem desenvolvimentos utilizando seus conceitos, porém vários sistemas legados continuam em uso. O desen- volvimento 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

http://edilms.eti.br

produtos a custos muito elevados. Muito desenvolvi- mento acontece em ferramentas de desenvolvimento para o desktop no desenvolvimento de aplicações (cli- ent 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 Mana- gement Systems (ODBMS).

Metade dos anos 90

É quando vemos a explosão da Internet./WWW e

uma louca corrida para prover acesso remoto a siste- mas de computadores com dados legados. Percebe-se um crescimento exponencial na tecnologia Web/BD.

Aumentam o uso de soluções de código aberto (o- pen 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) atin- gem maturidade através de muitos negócios utilizando os PDVs (Ponto de Venda).

Final dos anos 90

O grande investimento em empresas de Internet im-

pulsiona as vendas de ferramentas para conexão Web/Internet/BD. Active Server Pages, Front Page, Java Servlets, JDBC, Enterprise Java Beans, ColdFusi- on, 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.

com

PDAs (Personal Digital Assistant), transações em PDVs, consolidação de vendas, etc.

Aparecem

mais

aplicações

que

interagem

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 na- cional e dados de exploração espacial.

Data mining, data warehousing, data marts são téc- nicas 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 segmen-

tos. 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. Ob- ject 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) futu- ro(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ê vi- sitou 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 in- formações?

Resumo – tópicos de Banco de Dados I

prof. Edilberto Silva

http://edilms.eti.br

E o questionamento mais difícil de se responder:

Quem tomará estas decisões?

Conclusões

Como podemos perceber, a história nos ensina mui- to do que somos hoje. Não voltaremos ao passado para trabalhar com o velho WordStar, mas é extremamente importante aprendermos com o passado para decidir- mos melhor o nosso futuro afinal, o futuro está em nos- sas mãos. “

Fim do artigo

Conceitos

Modelagem conceitual Nesta fase, é construí- do um modelo conceitual na forma de um diagra- ma entidade-relacionamento (DER).

o Este modelo captura as necessidades da organi- zaçã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 ou- tras. Correlação: UNION

3.

Diferença - obter uma relação a partir da dife- renç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. Cor- relação: SELECT.

6.

ρ Renomeação - renomear uma relação com ou- tro nome, permitindo desta forma o uso desta co- mo 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. Corre- lação: INNER JOIN, =, IN

8.

Divisão - produz como resultado a projeção de todos os elementos da primeira relação que

Divisão - produz como resultado a projeção de todos os elementos da primeira relação que se re- lacionam com todos os elementos da segunda re- lação. Correlação: IN

9. |X| Junção - junção é utilizada para combinar tu- plas de duas relações partindo dos atributos co- muns 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 se-

guintes 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 anterior-

mente, 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 primei-

ra transação executar novamente o comando

de pesquisa, ela receberá um conjunto diferen-

te de linhas.

Os quadros de níveis de isolamentos são des- critos a seguir para você entender melhor.

Read Uncommitted Uma transação

pode enxergar dados não confirmados por ou-

tra transação

Read Committed Uma transação não

pode enxergar dados não confirmados por ou- tra transação, até que estes dados sejam con- firmados.

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ó pode-

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:

Dirty

Reads

Non-

Repeatable

Reads

Phantom

Read

Nível

Read Uncom-

mitted

Possível

Possível

Possível

Read Commit-

ted

Impossível

Possível

Possível

Repeatable

Read

Impossível

Impossível

Possível

Resumo – tópicos de Banco de Dados I

prof. Edilberto Silva

http://edilms.eti.br

Serializable

Impossível

Impossível

Impossível

Níveis de ABSTRAÇÃO de DADOS

Sistema BD deve prover uma visão abs-

trata de dados para os usuários, isolando, desta

forma, detalhes mais internos do BD.

Nível físico ou Interno descreve co-

mo 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 ex-

terno:, descrevendo partes do BD que serão vi-

sualizadas pelos usuários de acordo com suas necessidades. Subconjunto de dados do BD, sem que exista a necessidade de estarem ar- mazenados no BD. Provê a independência lógi- ca e física dos dados. Independência lógica possui a capacidade de mudar o esquema con- ceitual sem a necessidade de modificar pro- gramas da aplicação e esquemas externos, en- quanto que a física tem a capacidade de mudar o esquema interno sem a necessidade de alte- rar os esquemas conceitual e externo.

a necessidade de alte- rar os esquemas conceitual e externo. 12 Regras de Codd Regra das

12 Regras de Codd

Regra das

devem ser apresentadas como relações (tabelas formadas por linhas e colunas). Vinculo entre tabelas por campos comuns tanto aos dados quanto aos metadados

informações

em tabelas

Regra de a- cesso garan- tido:

o método de referência deve ser o nome da tabela, o valor da chave primária e o nome do cam- po/coluna.

Regra de tra-

permita a distinção de dados re-

tamento sis-

ais. Valores nulos devem ter um tratamento diferente de “valores em branco”.

temático de

valores nulos

catálogo rela-

estrutura do banco de dados (do- mínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em tabelas (tam- bém referenciadas como catálo- go).

cional ativo:

atualização de

capacidade de manipular as in- formações do banco de dados em grupos de registros, ou seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo.

alto-nível

sub-

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

linguagem de

dados abran-

gente

independência

Se houve modificação na forma como os dados estão armazena- dos fisicamente, nenhuma altera- ção deve ser necessárias nas aplicações que fazem uso do ban- co

física

independência

alteração na estrutura do banco de dados como inclusão ou exclu- são campos da tabela ou altera- ção no relacionamento entre tabe- las não deve afetar os aplicativo

lógica

atualização de

deve ser capaz de efetuar altera- ções, exclusões e inclusões nelas e devem ser repassadas para tabelas originais

visões

independência

(integridade de entidade, integri- dade referencial, restrições,etc) precisam ser estabelecidas dentro do catálogo ou dicionário de da- dos, e ser totalmente independen- tes da lógica dos aplicativos.

de integridade

independência

SGBD´s podem ser distribuídos em diversas plataformas que se encontrem interligados em re- de.Isto não pode afetar a funcionalidade do sistema e dos aplicativos

de distribui-

ção

não-

O sistema deve ser capaz de im- pedir qualquer usuário ou progra- mador de transgredir os mecanis- mos de segurança, regras de inte- gridade do banco de dados e res- trições,

subversiva

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

http://edilms.eti.br

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 rela-

cionamento; (obrigatório ou opcional)

Relação conjunto de n-tuplas ou tu-

plas 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 or- denadas

o Os atributos não são relacionados

o Cada tupla contém apenas um valor pa- ra cada atributo (1Fnormal)

Relacionamento

 
 

o

uma

associação

entre

entida-

des".(Korth)

o "É uma estrutura abstrata que indica as

associações entre elementos de um con- junto de entidades e elementos de outro

conjunto de entidades".(Betzer)

o Identificado a chave estrangeira par-

ticipa 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 re-

lacionamentos devedor denota a associa- ção entre clientes e empréstimos bancários contraídos pelo cliente.

Instância Os dados atuais armaze-

nados no BD em um momento particular. Tam-

bém chamado estado do banco de dados.

Entidades são objetos ou "coisas" do

mundo real que possuem uma existência inde- pendente e são de interesse para uma determi-

nada aplicação.

o "Uma entidade é uma representação

abstrata de um objeto do mundo real um ser, um fato, uma coisa, um organismo so-

cial, 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 atri- buto identificador (chave candidata) da en-

tidade fraca

Atributos são propriedades usadas

para descrever uma entidade. Mapeia um con-

junto 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 entida- de".( 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 atribu-

tos

simples,

exemplo:

Endereco

=

ru-

a+numero+bairro+cidade+UF)

o Monovalorado somente um valor pa-

ra cada instância. Ex: Nome, Data

Nasci-

mento

 

o

Multivalorado

Vários

valores

para

cada instância. Ex: Dependentes

o Derivados São obtidos a partir de va- lores 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 valo- res para o mesmo

Domínio Conjunto de valores per-

missí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

ou

mais atributos que, tomados em conjunto, per-

mite identificar unicamente uma entidade no conjunto de entidades

Chaves candidatas Superchaves

menores possíveis, em que nenhum subconjun- to 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

SuperChave

Conjunto

de

um

com o mesmo valor para K

o Irredutibilidade nenhum sub-

conjunto próprio de K tem a proprieda- de de unicidade

Chave Primária Chave candidata es-

colhida 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

http://edilms.eti.br

tidades no conjunto de entidades (chave primá- ria)

candidata

não escolhida para ser chave primária

Chave Estrangeira Conjunto de atri-

butos de uma relação R2 cujos valores devem obrigatoriamente corresponder a valores de al- guma chave candidata de alguma variável de

relação R1

Chave Substituta (surrogate key) ou ar-

tificial Chave criada artificialmente para iden-

tificar uma entidade não tendo nenhum signifi- cado no negócio

Chave

Alternativa

Chave

Linguagens

 

DML (Data Manipulation Language)

 
 

o

Procedimental Específica quais da-

dos são desejados e como chegar a eles

 

o

Não procedimental Especifica quais

dados são desejados, sem especificar co-

mo chegar a eles

 

DDL

(Data

Definition

Language)

-

Linguagem de Definição de Dados).

o permite ao usuário definir tabe-

las novas e elementos associados. A maioria dos bancos de dados de SQL comerciais tem extensões proprietárias

no DDL.

Exemplos:

o CREATE cria um objeto (uma

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 so- mente valores atômicos (não contiver gru- pos repetitivos). Para atingir esta forma normal devemos eliminar os grupos de re-

petição.

(2FN) Segunda Forma Normal Uma

relação R está na 2FN se e somente se ela es- tiver na 1FN e todos os atributos não chave fo- rem 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 de- pendentes 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 cha- ve forem independentes entre si

o Uma relação está na Terceira Forma

Normal se estiver na 2FN e todos os atri-

Tabela, por exemplo) dentro do base de

 

butos não chave forem dependentes não

dados;

transitivos da chave primária”

o

DROP

apaga

um

objeto

do

(BCNF) Forma Normal Boyce-Codd -

banco de dados.

o ALTER TABLE;

DCL (Data Control Language) – é a lin-

guagem 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, “Profi-

le”

Restrições de Integridade

De Domínio especifica que, para um

certo atributo A de uma relação, todo valor as-

sociado 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

Uma relação está na FNBC se e só se todo o determinante da relação for uma chave candi-

data.

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