Introdução a Teoria de Banco
de Dados
Prof. Rogério Gonçalves Bittencourt, M.Sc.
Prof. Rogério Bittencourt
Literatura Recomendada
BATINI, C.; CERI, S.; NAVATHE, S. B.: Conceptual database desing.
Benjamin/Cummings Publ. Co., Redwood City, 1992.
ELMASRI, R.; NAVATHE, S.B.: Fundamentals of database systems. AddisonWesley. 3Ed. Reprinted June 2000.
ULLMAN, J. D. & WIDON, J.: A first course in database systems. Prentice-Hall,
Inc. 1997.
RAMAKRISHNAN, R.: Database management systems. McGraw-Hill. 1998.
HEUSER, C. A.: Projeto de banco de dados. 3Ed. Sagra-Luzzatto, Porto Alegre.
1999.
DATE, C. J.: Introdução a sistemas de bancos de dados. Ed. Campus, Rio de
Janeiro, 6ª Edição, 2000.
KORTH. H. F.; SILBERSCHATZ, A.: Sistemas de bancos de dados. McGrawHill, São Paulo, 1994.
Prof. Rogério Bittencourt
Terminologia Básica
Dados  representação de fatos, conceitos ou
instruções de maneira formalizada.
Informação  significado que pessoas associam aos
dados através de convenções usadas em sua
interpretação.
Conhecimento  discernimento, critério, apreciação
prática de vida, experiência.
Prof. Rogério Bittencourt
Como a Informática é Adotada nas
Organizações
Informática é implementada gradativamente
Exemplo – Empresa hipotética
Implementa gradativamente sistemas para:
Vendas
Produção
Compras
Onde ficam os dados de PRODUTO?
Prof. Rogério Bittencourt
Sistemas Isolados
Dados não Compartilhados
Dados de diferentes aplicações não estão integrados
Dados estão projetados para atender uma aplicação
específica
Produção
Vendas
Compras
Arquivos produção
Arquivos vendas
Arquivos compras
Produtos
Prof. Rogério Bittencourt
....
Produtos
....
Produtos
....
Sistemas Isolados
Dados não Compartilhados
Problema: redundância de dados
Tipos de redundância de dados:
Redundância controlada de dados
Software gerencia redundância
Redundância não controlada de dados
Usuário gerencia redundância (não há gerência
automática)
Prof. Rogério Bittencourt
Redundância Não Controlada
Conseqüências
Entrada repetida da mesma informação
Inconsistências de dados
Dificuldade de extração de informações
Dados projetados para atender aplicações específicas
geram dificuldades para o cruzamento de informações
Dados pouco confiáveis e de baixa disponibilidade
Prof. Rogério Bittencourt
Como Evitar Redundância Não
Controlada
Compartilhamento de dados
Cada informação é armazenada uma única vez
Usar o conceito de Banco de Dados
Produção
Vendas
Compras
Banco de Dados
Produtos
Prof. Rogério Bittencourt
....
Definições de Banco de Dados
Literatura
“Um banco de dados é um conjunto de arquivos relacionados
entre si” (Chu, 1983)
“Um banco de dados é uma coleção de dados operacionais
armazenados, sendo usados pelos sistemas de aplicação de
uma determinada organização” (C. J. Date, 1985)
“Um banco de dados é uma coleção de dados relacionais”
(Elmasri & Navathe, 1989)
“Um banco de dados é um conjunto de dados armazenados,
cujo conteúdo informativo representa, a cada instante, o
estado atual de uma determinada aplicação” (Laender, 1990)
Prof. Rogério Bittencourt
Banco de Dados
Conjunto de arquivos integrados que atendem a um
conjunto de sistemas
Cada informação armazenada uma única vez
Eventualmente redundância controlada pelo sistema em computador e
invisível ao usuário
Produção
Vendas
Compras
Banco de Dados
Produtos
Prof. Rogério Bittencourt
....
Banco de Dados
Compartilhamento de dados tem reflexos na
estrutura do software
Estrutura interna dos arquivos passa a ser mais
complexa
Devem atender à necessidades dos diferentes sistemas
Solução
Usar Sistema de Gerência de Banco de Dados
Prof. Rogério Bittencourt
Evolução da Programação de
Sistemas
Início da programação de aplicações 
Programa continha todas operações
Interface de usuários
Transformações de dados e cálculos
Operações de armazenamento de dados
Tarefas de comunicação com outros sistemas e
programas
Prof. Rogério Bittencourt
Evolução da Programação de
Sistemas
Foram identificadas funcionalidades comuns
Exibição dos dados na interface
Gerenciadores de interface de usuários
Comunicação com processos remotos
Gerenciadores de comunicação
Manutenção de grandes repositórios compartilhados
de dados
• Sistemas de Gerência de Banco de Dados (SGBD)
Prof. Rogério Bittencourt
Sistema de Gerência de Banco de
Dados
Software que incorpora as funções de definição,
recuperação e alteração de dados em um banco de
dados
Facilita desenvolvimento de aplicações de Banco de
Dados (BD)
Manutenção de programas torna-se mais simples
Produtividade de programadores aumenta
Prof. Rogério Bittencourt
Sistemas de Gerência de Banco de
Dados
“O SGBD permite a definição, construção e manipulação do
banco de dados para diversas aplicações.”
DEFINIÇÃO do BD:
Envolve a especificação dos tipos de dados a serem
armazenados no BD, mais a descrição de cada tipo de dado.
CONSTRUÇÃO do BD:
Processo de armazenar os dados em um meio controlado
pelo SGBD.
MANIPULAÇÃO do BD:
Execução de operações de consulta e recuperação de dados
específicos, além de atualização de dados para refletir, no
BD, mudanças no mini-mundo sendo modelado. A
manipulação inclui, também, a geração de relatórios a partir
dos dados do BD.
Prof. Rogério Bittencourt
Componentes de SBD
Prof. Rogério Bittencourt
Objetivos
SBD
Isolar os usuários dos detalhes mais internos do banco de
dados (abstração de dados).
Prover independência de dados às aplicações (estrutura
física de armazenamento e à estratégia de acesso).
Prof. Rogério Bittencourt
Porque Usar Banco de Dados
Sistema de Banco de Dados proporciona à empresa o
controle centralizado de seus dados operacionais. Tal
situação contrasta nitidamente com o que podemos
encontrar em uma empresa que não utiliza um SGBD, onde
cada aplicação dispõe de seus próprios arquivos de tal
forma que os dados operacionais são muito dispersos,
dificultando o controle sistemático.
• Isto implica que exista um DBA
Prof. Rogério Bittencourt
Vantagens do Controle Centralizado
Reduzir Redundância
Compartilhamento dos Dados
Evitar Inconsistência
Padronização (redução do esforço humano (desenvolvimento
e utilização))
Manter a Integridade
Integridade Referencial
Integridade Transacional
Rapidez na manipulação e no acesso à informação
Controle integrado de informações distribuídas fisicamente,
Aplicação automática de restrições de segurança
Prof. Rogério Bittencourt
Modelos de Dados
Modelo de (Banco de) Dados
Descrição formal dos tipos de dados que estão
armazenados em um Banco de Dados
Prof. Rogério Bittencourt
Modelos de Dados
Conteúdo
Exemplo de Indústria
Modelo de dados informa
São armazenadas informações sobre PRODUTOS
Para cada PRODUTO são armazenadas seu código, preço
e descrição
Modelo de dados não informa
Quais os produtos que estão armazenados no Banco de
Dados
Prof. Rogério Bittencourt
Esquema de Banco de Dados
Para construir um BD usa-se
Linguagem de modelagem de dados
Textual
Gráfica
Um modelo de dados pode ser apresentado de
várias formas (texto, figura, ...)
Cada apresentação do modelo recebe a
denominação Esquema de Banco de Dados
Prof. Rogério Bittencourt
Modelos de Dados
Níveis de Abstração
Modelo Conceitual
Abstração
Modelo Lógico
Modelo Físico
Prof. Rogério Bittencourt
Modelo Conceitual
Independente do tipo de SGBD
Registra
Estrutura dos dados podem aparecer no BD
Não registra
Como estes dados estão armazenados a nível de
SGBD
Prof. Rogério Bittencourt
Modelo Conceitual
ER
Técnica mais difundida de modelagem
conceitual
Abordagem entidade-relacionamento (ER)
Modelo conceitual é representado
graficamente através de Diagrama EntidadeRelacionamento (DER)
Prof. Rogério Bittencourt
Diagrama EntidadeRelacionamento
preço
Produto
descrição
código
Prof. Rogério Bittencourt
descrição
n
1
Tipo de
Produto
código
Modelo Lógico
Nível de abstração visto pelo usuário do SGBD
Depende do tipo particular de SGBD que está
sendo usado
Descrição dos dados nos níveis conceitual e
de visões de usuários
O banco de dados é estruturado em registros de
formatos fixos, de diversos tipos
Cada tipo de registro tem sua coleção de atributos
Há linguagens para expressar consultas e
atualizações no banco de dados
Prof. Rogério Bittencourt
Modelo Lógico
Abordagens
Tipos de abordagem:
Navegacional: caminhos de acesso explícitos
Modelo de dados em árvore
1. Abordagem hierárquica (histórica)
2. Abordagem XML
Modelo de dados em grafo
1. Abordagem em rede (histórica)
2. Abordagem orientada a objetos
Associativa: sem caminhos de acesso explícitos
Abordagem relacional
Prof. Rogério Bittencourt
Histórico das Abordagens
Desde o fim da década de 1960, diversos SGBD comerciais
foram construídos. Algumas abordagens estabeleceram-se
na prática.
Abordagem Hierárquica
Origem: SGBD da IBM (IMS)
Largamente utilizado durante as décadas de 1970 e início da
década de 1980
Abordagem em Rede
Grande família de SGBD baseados em um padrão ANSI
Originário do IDMS (BF Goodrich, depois Culinane)
Exemplos: IDMS, IDS/2
Década de 1970
Prof. Rogério Bittencourt
Histórico das Abordagens
Abordagem Relacional
Embasamento teórico: trabalhos de Codd (IBM) procurando um
modelo lógico independente de detalhes de implementação
Década de 1970: pesquisa e construção de diversos protótipos.
Os mais importantes são:
System R (IBM), precursor do DB2
INGRES (Stonebraker, Universidade da Califórnia), precursor do
produto comercial de mesmo nome e do PostgreSQL
Década de 1980: surgimento de produtos comerciais
DB2, Oracle, Informix, Sybase (SQL/Server)
Domínio do mercado
Padrão ISO
Prof. Rogério Bittencourt
Histórico das Abordagens
Abordagem Orientada a Objetos
Abordagem relacional não é completamente adequada para
programação orientada a objetos
Década de 1990: surgimento de SGBD orientados a objetos
O2, Gemstone, ObjectStore, Jasmine, ...
Padrão ODMG
Modelo de dados semelhante ao modelo em rede
Abordagem XML
Abordagem voltada para o intercâmbio de dados e representação de
documentos
Não foi concebida para armazenamento (exceção: SGBD Tamino)
Final da década de 1990: Padrão W3C
Modelo de dados semelhante ao modelo hierárquico
Prof. Rogério Bittencourt
Comparação entre Abordagens
Aspectos
Comparação da estrutura de dados
Construções que compõe uma base de dados na abordagem
Comparação das instruções de acesso a dados
DML fictícia mínima destinada apenas a comparar as abordagens
DML opera registro-a-registro (não há operações que tratam
conjuntos de dados)
Comparação das instruções de alteração
Será verificado como alterações são implementadas em cada
modelo lógico
Comparação da independência de dados
Prof. Rogério Bittencourt
Exemplo Utilizado
Informações armazenadas:
Para cada peça: código, nome, cor, peso e cidade em que se encontra
Para cada fornecedor: código, nome, status e cidade
Para cada embarque: fornecedor que fez o embarque, peça
embarcada, quantidade embarcada
Operações consideradas:
Buscar os nomes dos produtos embarcados por um fornecedor de
código dado.
Buscar os nomes dos fornecedores que embarcaram um produto de
código dado.
Incluir um produto e um fornecedor
Excluir um produto e um fornecedor
Alterar os nome de um produto e o nome de um fornecedor
Prof. Rogério Bittencourt
Abordagem Hierárquica
Importância:
IBM teve IMS (DL/1), largamente utilizado durante a
década de 70 e início da década de 80
Própria IBM adaptou o IMS para modelo semelhante a
rede
Poucos produtos além de IMS
Ainda aparece em sistemas legados
Prof. Rogério Bittencourt
Abordagem Hierárquica
Estrutura de Dados
Um BD hierárquico é uma floresta composta de
árvores de registros
Há dois tipos básicos de construção
registro (chamado segmento em IMS)
ligação pai-filho entre os registros
Restrição:
um determinado registro somente pode possuir um
registro pai
Prof. Rogério Bittencourt
Abordagem Hierárquica
Esquema Gráfico
Peça
CodPeça NomePeça CorPeça PesoPeça CidadePeça
definição de
tipo de relação
“pai-filho”
Fornec
CodFornec NomeFornec StatusFornec CidadeFornec QtdeEmbarc
definição de
tipo registro
Prof. Rogério Bittencourt
Abordagem Hierárquica
Um estado da base de dados IMS
Peça
P1
Eixo
Cinza
10
PoA
Fornec
F3
Álvares
F2
Souza
F1
Silva
5
10
5
São Paulo
200
Rio
400
São Paulo
300
Peça
P2
Rolamento
Preto
16
Rio
Fornec
F4
Tavares
F1
Silva
8
5
Rio
350
São Paulo
300
Peça
P3
Prof. Rogério Bittencourt
Mancal
Verde
30
São Paulo
Abordagem Hierárquica
Instruções de Acesso a Dados
get next root <record name> [where
<select criteria>]
Esta instrução busca um registro raiz que obedece a determinado
critério com base em valores de seus campos
get next child <record name>
[where <select criteria>]
Esta instrução busca um registro que:
1. é filho do registro corrente
2. obedece a determinado critério
Prof. Rogério Bittencourt
Abordagem Hierárquica
Exemplo de Acesso a Dados
Consulta 1
Buscar os nomes dos fornecedores que embarcaram o
produto de código P2
get next root Peça where CodPeça='P2';
do until no more Fornec under this;
get next child Fornec;
print NomeFornec;
end;
Prof. Rogério Bittencourt
Abordagem Hierárquica
Exemplo de Acesso a Dados
Consulta 2
Buscar os nomes das peças embarcadas pelo
fornecedor F1
do until no more Peça;
get next
get next
where
if found
end;
Prof. Rogério Bittencourt
root Peça;
child Fornec
CodFornec = 'F1';
then print NomePeça;
Abordagem Hierárquica
Assimetria na abordagem IMS
O problema das peças e fornecedores é simétrico.
A abordagem IMS força uma assimetria inexistente na
realidade modelada.
O modelador tem que escolher um tipo de registro pai
com base em considerações de performance.
Consultas simétricas são resolvidas de forma diferente.
Somente problemas hierárquicos são modelados
adequadamente na abordagem hierárquica.
Prof. Rogério Bittencourt
Abordagem Hierárquica
Operações de modificação da base de dados - Inclusão
Incluir um novo fornecedor (sem embarques)
criar um registro “fantasma” de peça
Anomalia de inclusão
Uma operação que do ponto de vista da realidade
modelada inclui um único objeto é implementada na
base de dados pela inclusão de múltiplos objetos
É conseqüência da redundância de dados
Prof. Rogério Bittencourt
Abordagem Hierárquica
Operações de modificação da base de dados - Exclusão
Anomalia de exclusão
A exclusão do último embarque de um fornecedor
implica na exclusão de seus dados
A exclusão da única peça fornecida por um
fornecedor implica na exclusão de seus dados
Para resolver o problema, fornecedores sem
embarques teriam que ser movidos para baixo de um
registro fantasma
Prof. Rogério Bittencourt
Abordagem Hierárquica
Operações de modificação da base de dados - Alteração
Anomalia de alteração
A alteração de um campo de um fornecedor implica
em busca em toda base de dados
Prof. Rogério Bittencourt
Abordagem Hierárquica
Análise da Abordagem
Adequada somente para problemas hierárquicos
Em caso de problemas não hierárquicos cria:
Redundância de dados
Resulta em anomalias de atualização ("update anomalies") nas instruções de
modificação da base de dados
Assimetrias indesejáveis na representação de dados e na programação
Porque abordagem hierárquica foi usada?
Performance
Modelava a idéia de armazenar contiguamente um registro pai e seus vários
filhos
IBM fez cedo uma reforma introduzindo o conceito de pai-filho lógico
Permitia estabelecer relações entre diferentes árvores e de fato implementar
o modelo em rede (ver adiante)
Prof. Rogério Bittencourt
Abordagem XML
Padrão W3C:
Intercâmbio de documentos
Representação de conteúdo de documentos (separar
apresentação de conteúdo)
Em evolução
Modelo de dados em árvore, semelhante hierárquico
Como modelo de dados de SGBD, mesmos problemas
Prof. Rogério Bittencourt
Abordagem XML
Estrutura de Dados
Banco de dados é um documento XML
Documento XML é composto de um elemento raiz
Elemento raiz pode ser composto por outros elementos
e assim recursivamente
Estrutura em árvores
Prof. Rogério Bittencourt
Abordagem XML
Exemplo de Documento
<pecas>
<peca>
<codpeca>P1</codpeca>
<nomepeca>Eixo</nomepeca>
<corpeca>Cinza</corpeca>
<pesopeca>10</pesopeca>
<cidadepeca>PoA</cidadepeca>
<embarques>
<fornec>
<codfornec>F1</codfornec>
...
</fornec>
<fornec>
<codfornec>F2</codfornec>
...
</fornec>
</embarques>
</peca>
...
</pecas>
Prof. Rogério Bittencourt
Abordagem XML
Assimetria das Consultas
Modelo em rede implica em assimetria de consultas
Exemplos em Xpath (linguagem para referenciar partes
de um documento - faz parte do padrão XML)
Consulta 1
Buscar os nomes dos fornecedores que embarcaram o produto de
código P2
/pecas/peca[codpeca="P2"]/embarques/fornec/nomefornec
Consulta 2
Buscar os nomes das peças embarcadas pelo fornecedor F1:
/pecas/peca[embarques/fornec[codfornec="F1"]]/nomepeca
Prof. Rogério Bittencourt
Abordagem em Rede
Grande família de SGBDs baseada em um padrão estabelecido
na década de 70
Padrão CODASYL/DBTG
Tentativa de padronizar modelos de dados de SGBD
Precursores foram sistemas de gerência de arquivos em listas
encadeadas como TOTAL
Originário do IDMS (BF Goodrich, depois Culinane)
Depois adotado por muitos fornecedores de Hardware
Prof. Rogério Bittencourt
Abordagem em Rede
Estrutura de Dados
BD em rede é um grafo
nós = registros
arcos = ligações entre registros
Há dois tipos básicos de construção
registro (“record type”)
ligação pai-filho entre os registros (“set type”)
Não há a restrição da abordagem hierárquica: um determinado
registro pode possuir diversos registros pai.
A única restrição é que, em um tipo de ligação, um registro somente
pode participar uma vez
Prof. Rogério Bittencourt
Abordagem em Rede
Esquema Gráfico
Peça
CodPeça NomePeça CorPeça PesoPeça CidadePeça
Peça-Embarq
Embarq
Fornec
QtdeEmbarc
definição de
tipo de relação
“pai-filho”
Fornec-Embarq
CodFornec NomeFornec StatusFornec CidadeFornec
definição de
tipo registro
Prof. Rogério Bittencourt
Abordagem em Rede
Conteúdo da base de dados
Prof. Rogério Bittencourt
Abordagem em Rede
Instruções de Acesso a Dados
Na abordagem de rede são necessárias duas instruções de
acesso a dados semelhantes às da abordagem hierárquica:
get next <record name> where <select criteria>
Esta instrução busca um registro de um tipo (<record name>)
que obedece a determinado critério (<select criteria>) com
base em valores de seus campos
Não está restrita a registros raiz
get next child <record name> via <set name>
where <select criteria>
Esta instrução busca um registro de um tipo (<record name>)
que obedece a determinado critério (<select criteria>) e que
é filho do registro corrente dentro da ligação (<set name>)
indicada.
Na abordagem de rede são necessárias duas instruções de acesso a
dados semelhantes às da abordagem hierárquica:
Prof. Rogério Bittencourt
Abordagem em Rede
Instruções de Acesso a Dados
Adicionalmente, aparece uma instrução própria da
abordagem em rede para buscar um registro pai (<record
name>1) de um filho em uma cadeia dada (<set name>)
get parent <record name>1 via <set name>
Prof. Rogério Bittencourt
Abordagem em Rede
Exemplo de Acesso a Dados
Consulta 1
Buscar os nomes dos fornecedores que embarcaram o
produto de código P2
get next Peça where CodPeça='P2';
do until no more Embarq under this in Peça-Embarq;
get next child Embarq via Peça-Embarq;
get parent Fornec via Fornec-Embarq;
print NomeFornec;
end;
Prof. Rogério Bittencourt
Abordagem em Rede
Exemplo de Acesso a Dados
Consulta 2
Buscar os nomes das peças embarcadas pelo fornecedor F1
get next Fornec where CodFornec='F1';
do until no more Embarq under this in Fornec-Embarq;
get next child Embarq via Fornec-Embarq;
get parent Peça via Peça-Embarq;
print NomePeça;
end;
Prof. Rogério Bittencourt
Abordagem em Rede
Assimetria na abordagem
O problema das peças e fornecedores que é simétrico do
ponto de vista da realidade implementada
➔
tratado de forma simétrica na abordagem em rede
A abordagem em rede modela o problema e as consultas
simetricamente.
Prof. Rogério Bittencourt
Abordagem em Rede
Operações de modificação da base de dados
Na abordagem em rede, não aparecem as anomalias de
alteração que podem aparecer na abordagem hierárquica
Para incluir um novo fornecedor (sem embarques) é necessário criar
apenas um registro de fornecedor
A exclusão do último embarque de um fornecedor não implica na
exclusão de seu registro
A exclusão de uma peça não implica na exclusão de seus
fornecedores (apenas de seus embarques)
A alteração de um campo de um fornecedor implica em alteração de
um registro somente
Na abordagem em rede, não aparecem as anomalias de alteração
que podem aparecer na abordagem hierárquica
Prof. Rogério Bittencourt
Análise das Abordagens com
Caminhos de Acesso Explícitos
Todas abordagens mostradas tem caminhos de acesso
explícitos
Significa: programador inclui referências explícitas a caminhos
de acesso dentro do código das consultas
São chamadas de abordagens navegacionais
Independência de dados fica prejudicada:
criação/eliminação de ligações implica em alteração do código das consultas
Solução proposta:
Não permitir que o programador faça referência a caminhos de acesso
Abordagem associativa
Base do desenvolvimento da abordagem relacional
Prof. Rogério Bittencourt
Abordagem Relacional
Prof. Rogério Bittencourt
Abordagem Relacional
Tanto os dados quanto os relacionamentos são
representados por tabelas.
Possui fundamento matemático sólido.
Prescinde de estruturas de índice eficientes e
hardware adequado para alcançar desempenho
viável em situações práticas.
Prof. Rogério Bittencourt
Abordagem Relacional
TipoDeProduto (CodTipoProd, DescrTipoProd)
Produto (CodProd, DescrProd, PrecoProd, CodTipoProd)
CodTipoProd referencia TipoDeProduto
Prof. Rogério Bittencourt
Modelo Físico
Contém detalhes de armazenamento interno de
informações
Detalhes que
Não têm influência sobre a programação de aplicações
no SGBD
Influenciam a performance das aplicações
Usado por profissionais que fazem a sintonia
(tunning) de performance de BD
Prof. Rogério Bittencourt
Arquitetura de SGBD
Nível Interno  Mais próximo do armazenamento físico, isto é,
relaciona-se com a forma como os dados são armazenados.
Emprega-se o Modelo de Dados Físico para descrever detalhes de
armazenamento.
Nível Conceitual  Descreve a estrutura completa de um BD
para uma comunidade de usuários. É uma descrição global do BD,
que esconde detalhes da estrutura física de armazenamento.
Pode-se empregar um modelo de alto nível (modelo conceitual)
ou de implementação.
Nível Externo  Mais próximo dos usuários. É formado por um
conjunto de visões de usuários ou esquemas externos. Cada visão
descreve a parte do BD que um grupo de usuários está
interessado. Pode ser empregado um modelo de alto nível
(modelo conceitual) ou de implementação
Prof. Rogério Bittencourt
Arquitetura de SGBD
Exemplo
O exemplo mostra a visão conceitual de um simples
banco de dados sobre funcionários.
A visão interna correspondente e as duas visões
externas correspondentes, uma para um usuário de
PL/1 e outra para o usuário de COBOL.
O exemplo é totalmente
hipotético - não pretende
simular qualquer sistema
real - e muitos detalhes
irrelevantes
foram
deliberadamente
omitidos.
Prof. Rogério Bittencourt
Externo (PL/1)
DCL 1 EMPP,
2 EMP # CHAR (6),
2 SAL FIXED BIN (31)
Conceitual
EMPLOYEE
EMPLOYEE_NUMBER
DEPARTAMENT_NUMBER
SALARY
Externo (COBOL)
01 EMPC.
02 EMPNO PIC X (6)
02 DEPTNO PIC X (4).
CHARACTER (6)
CHARACTER (4)
NUMERIC
(5)
Interno
STORED_EMP
LENGTH = 118
PREFIX TYPE = BITE(6), OFFSET = O
EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX
DEPT# TYPE = BYTE(4), OFFSET = 12
SAL
TYPE = FULLWORD, OFFSET = 16
Arquitetura de SGBD
Interpretação do Exemplo
Externo (PL/1)
DCL 1 EMPP,
2 EMP # CHAR (6),
2 SAL FIXED BIN (31)
Conceitual
EMPLOYEE
EMPLOYEE_NUMBER
DEPARTAMENT_NUMBER
SALARY
Externo (COBOL)
01 EMPC.
02 EMPNO PIC X (6)
02 DEPTNO PIC X (4).
CHARACTER (6)
CHARACTER (4)
NUMERIC
(5)
Interno
STORED_EMP
LENGTH = 118
PREFIX TYPE = BITE(6), OFFSET = O
EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX
DEPT# TYPE = BYTE(4), OFFSET = 12
SAL
TYPE = FULLWORD, OFFSET = 16
Prof. Rogério Bittencourt
banco de dados contém, no nível
conceitual, informações referentes ao
tipo de entidade chamada EMPLOYEE.
Cada EMPLOYEE tem um EMPLOYEENUMBER (seis caracteres), um
DEPARTMENT-NUMBER (quatro
caracteres) e um SALARY (cinco dígitos
decimais).
Arquitetura de SGBD
Interpretação do Exemplo
Externo (PL/1)
DCL 1 EMPP,
2 EMP # CHAR (6),
2 SAL FIXED BIN (31)
Conceitual
EMPLOYEE
EMPLOYEE_NUMBER
DEPARTAMENT_NUMBER
SALARY
Externo (COBOL)
01 EMPC.
02 EMPNO PIC X (6)
02 DEPTNO PIC X (4).
CHARACTER (6)
CHARACTER (4)
NUMERIC
(5)
Interno
STORED_EMP
LENGTH = 118
PREFIX TYPE = BITE(6), OFFSET = O
EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX
DEPT# TYPE = BYTE(4), OFFSET = 12
SAL
TYPE = FULLWORD, OFFSET = 16
Prof. Rogério Bittencourt
Os funcionários estão representados, no
nível interno, por um tipo de registro
armazenado chamado STORED-EMP, com
dezoito bytes de comprimento. O
STORED-EMP contém quatro tipos de
campos armazenados: um prefixo de seis
bytes (contendo, provavelmente,
informações de controle como
sinalizadores ou ponteiros), e três campos
de dados correspondendo às três
propriedades dos funcionários' Os registros
STORED_FMP são, adicionalmente,
indexados no CAMPO EMP por um índice
chamado EMPX.
Arquitetura de SGBD
Interpretação do Exemplo
Externo (PL/1)
DCL 1 EMPP,
2 EMP # CHAR (6),
2 SAL FIXED BIN (31)
Conceitual
EMPLOYEE
EMPLOYEE_NUMBER
DEPARTAMENT_NUMBER
SALARY
O usuário de PL/1 tem uma visão externa do banco
de dados, na qual cada funcionário é representado
por um registro PL/I, contendo dois campos (os
números de departamento não são do interesse
deste usuário, e por isto foram omitidos da visão). O
tipo de registro é definido por uma declaração
comum de estrutura PL/I, de acordo com as regras
Externo (COBOL)
normais de PL/I.
01 EMPC.
02 EMPNO PIC X (6)
02 DEPTNO PIC X (4).
CHARACTER (6)
CHARACTER (4)
NUMERIC
(5)
Interno
STORED_EMP
LENGTH = 118
PREFIX TYPE = BITE(6), OFFSET = O
EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX
DEPT# TYPE = BYTE(4), OFFSET = 12
SAL
TYPE = FULLWORD, OFFSET = 16
Prof. Rogério Bittencourt
Arquitetura de SGBD
Interpretação do Exemplo
Externo (PL/1)
DCL 1 EMPP,
2 EMP # CHAR (6),
2 SAL FIXED BIN (31)
Conceitual
EMPLOYEE
EMPLOYEE_NUMBER
DEPARTAMENT_NUMBER
SALARY
Externo (COBOL)
01 EMPC.
02 EMPNO PIC X (6)
02 DEPTNO PIC X (4).
CHARACTER (6)
CHARACTER (4)
NUMERIC
(5)
Interno
STORED_EMP
LENGTH = 118
PREFIX TYPE = BITE(6), OFFSET = O
EMP# TYPE = BYTE(6), OFFSET = 6, INDEX = EMPX
DEPT# TYPE = BYTE(4), OFFSET = 12
SAL
TYPE = FULLWORD, OFFSET = 16
Prof. Rogério Bittencourt
Do mesmo modo, o usuário de COBOL
tem uma visão externa,
na qual
cada funcionário é representado por
um registro COBOL, contendo,
novamente, dois campos (desta vez foi
omitido o de salário). O tipo de registro
é definido por um registro comum
COBOL, de acordo com as regras
normais do COBOL.
Linguagens de SGBD's
DDL = Data Definition Language - Linguagem de definição
de dados, possibilita a definição ou descrição dos objetos do
BD.
DML = Data Manipulation Language - Linguagem de
manipulação de dados, que suporta manipulação (acesso e
alteração.
DCL = Data Control Language – Linguagem de controle de
segurança e acesso, que possibilita a definição de usuários.
Prof. Rogério Bittencourt
Tipos de DML's
DML’s podem ser:
procedurais - o usuário tem que especificar o que
deseja e como pretende obter isso. Recuperam
registros individuais do BD e processam cada registro
separadamente. (devem ser embutidas em LPG’s)
não procedurais - são capazes de expressar
operações complexas de maneira concisa. O usuário
especifica apenas o que deseja, e permite que o
sistema decida como obter isso. (pode ser embutida
em uma LPG de propósito geral)
Prof. Rogério Bittencourt
Níveis de Abstração
O sistema de bancos de dados deve prover uma
visão abstrata de dados para os usuários.
A abstração se dá em três níveis:
Nível de visão dos usuários
Nível do conjunto de usuários
Nível de armazenamento
Prof. Rogério Bittencourt
Independência de Dados
Níveis de Abstração
Nível Físico  nível mais baixo de abstração, descreve como os
dados estão realmente armazenados. Complexas estruturas de
dados de baixo nível são descritas em detalhes.
Nível Conceitual  descreve quais dados estão armazenados
de fato no BD e as relações que existem entre eles. Aqui o BD
inteiro é descrito em termos de um pequeno número de
estruturas relativamente simples.
Nível Visual  o mais alto nível de abstração descreve apenas
parte do BD, de acordo com a necessidade de cada usuário.
Apesar do uso de estruturas mais simples do que no nível
conceitual, alguma complexidade perdura devido ao grande
tamanho do BD.
Prof. Rogério Bittencourt
Independência de Dados
visão 1
...
visão 2
Nível
Conceitu al
Nível Físico
Prof. Rogério Bittencourt
visão n
Independência de Dados
A habilidade de modificar a definição de um esquema em um
nível sem afetar a definição de esquema num nível mais alto é
chamada de independência de dados.
Independência física de dados é a habilidade de modificar o
esquema físico sem a necessidade de rescrever os programas
aplicativos. As modificações no nível físico são ocasionalmente
necessárias para aprimorar o desempenho.
Independência lógica de dados é a habilidade de modificar o
esquema conceitual sem a necessidade de rescrever os programas
aplicativos. As modificações no nível conceitual são necessárias
quando a estrutura lógica do BD é alterada.
Prof. Rogério Bittencourt
Estrutura Geral de um Sistema de
Banco de Dados
Usuários
Ingênuos
Interfaces do
aplicativo
Programadores
de aplicativos
Usuários
sofisticados
Programas
aplicativos
Consulta
Pré-compilador
da linguagem
de manipulação
de dados
Processador
de consultas
Código objeto
de programas
aplicativos
Esquema de
bancos de
dados
Compilador de
linguagem de
definição de
dados
Gerenciador
de banco
de dados
SGDB
Gerenciador
de arquivos
DISCO
Prof. Rogério Bittencourt
Administrador de
banco de dados
Arquivos
de dados
Dicionários
de dados