Sistemas Gereciadores de Banco de Dados

Sistemas Gereciadores
de Banco de Dados
Prof. Marcos Alexandruk
alexandruk@uninove.br
www.unilivros.com.br
Aula 1
Informações Importantes
 EMENTA:
 Sistemas gerenciadores de banco de dados relacionais;

 Configurações do ambiente de trabalho;
 Diferenças entre as diversas plataformas;
 Mecanismos de back-up;
 Importação e exportação;
 Criação de tabelas e consultas
 OBJETIVO:
 Conhecer os requisitos de instalação e recursos de alguns

dos principais SGBDs (Sistemas Gerenciadores de Banco
de Dados).
 BIBLIOGRAFIA:
 COSTA, Rogério L. de C. SQL Guia Prático. 2ª ed. Rio de

Janeiro: Brasport, 2006.
 SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema
de Banco de Dados. 5ª ed. Rio de Janeiro: Campus, 2006.
 SOARES, Walace. MySQL conceitos e aplicações. São
Paulo: Érica, 2004.
de Banco de Dados
Conceitos e Características Gerais

Conceitos Gerais e Características
SGBD (Sistema de Gerenciamento de Banco de Dados):
coleção de dados inter-relacionados

+
conjunto de programas para acessar e manipular esses dados
Silberschatz p.4
O principal objetivo de um SGBD é fornecer

um ambiente que seja tanto conveniente
como eficiente para recuperação e
armazenamento de informações.
Gerenciamento de dados envolve:
 Definir estruturas de armazenamento
 Fornecer mecanismos para a manipulação de informações

O SGBD precisa garantir a segurança

apesar de falhas de sistema ou tentativas
de acesso não autorizado.
“Embora as interfaces de usuário ocultem

os detalhes de acesso a um banco de
dados, e a maioria das pessoas nem
mesmo tenha consciência de estar
lidando com um banco de dados, acessar
banco de dados é uma parte essencial da
vida de quase todo mundo hoje.”
Silberschatz p. 2
As doze regras de Codd
 Doze regras estabelecidas por

Edgard F. Codd, em 1985, por
meio das quais podemos
determinar o quanto um banco
de dados é relacional ou não.
As doze regras de Codd
 1. Regra das informações em tabelas
 2. Regra de acesso garantido
 3. Regra de tratamento sistemático de valores nulos
 4. Regra do catálogo relacional ativo
 5. Regra da atualização de alto nível
 6. Regra da sub linguagem de dados abrangente
 7. Regra da independência física
 8. Regra da independência lógica
 9. Regra da atualização de visões
 10. Regra da independência de integridade
 11. Regra da independência de distribuição
 12. Regra não subversiva
de Banco de Dados
Aula 2
Cenário atual
 Hoje encontramos uma grande variedade de

SGDBs (Sistemas Gerenciadores de Banco
de Dados) para as mais diversas plataformas
de hardware e sistemas operacionais.
Classificação de
Banco de Dados
Classificação quanto ao modelo de dados
 Bancos de Dados Hierárquicos:

 IMS - Information Management System: desenvolvido
pela IBM e pela Rockwell no fim da década de 1960 para
ambientes de grande porte (OS/VS1, OS/VS2, MVS,
MVS/XA e ESA)
 Utiliza a organização de endereços físicos do disco na
sua estrutura
 Baseado em dois conceitos fundamentais: registros e
relacionamentos pai-filho
 Um registro "pai" pode se corresponder com vários
registros do lado "filho"
 Bancos de Dados em Rede:

 Definidos pelo DBTG (Data Base Task Group) do comitê do
CODASYL (Conference on Data Systems Language) a partir de
1971
 Permitem que um mesmo registro participe de vários
relacionamentos devido à eliminação da hierarquia
 Os comandos de manipulação de registros devem ser
incorporados a uma linguagem hospedeira (COBOL, a mais
comum, Pascal e FORTRAN)
 Estruturas fundamentais: registros (records) e conjuntos (sets)
 Registros contêm dados relacionados e são agrupados em tipos
de registros que armazenam os mesmos tipos de informações
 Bancos de Dados Relacionais:

 A maioria dos SGBDs atualmente em uso se enquadra no tipo
relacional
 Princípios básicos formulados por Edgard F. Codd em 1968
baseados na teoria dos conjuntos e da álgebra relacional
 Em 1985, Codd propôs um conjunto de doze regras para que
um banco de dados fosse considerado como relacional
 Organiza os dados em tabelas (relações) formadas por linhas
e colunas
 Tabelas são similares a conjuntos de elementos: relacionam
as informações de um mesmo assunto de um modo
organizado
 Bancos de Dados Orientados a Objetos:

 Surgiram em meados de 1980 para armazenamento de dados
complexos, não adequados aos sistemas relacionais: GIS
(Geographical Information System) e CAD/CAM/CAE
 O modelo é caracterizado pela definição de objetos com suas
propriedades e operações
 O OMDG (Object Database Management Group) definiu um
padrão de estrutura para bancos de dados orientados a objetos
 O grupo propôs um padrão conhecido como ODMG-93,
atualmente revisado e denomidado ODMG 2.0
 Linguagens: ODL (Object Definition Language) e OQL (Object
Query Language)
Classificação quanto ao número de usuários
 Bancos de Dados Monousuários:

 Permitem que apenas um usuário por vez acesse o
banco de dados
 Antigos (1980-1990) e direcionados a uso pessoal:
dBASE III, dBASE IV, FoxBase, FoxPro
Classificação quanto ao número de usuários
 Bancos de Dados Multiusuários:

 Suporta o acesso de vários usuários ao mesmo tempo
 A maioria dos bancos de dados atuais oferece suporte a
multiusuários
Classificação quanto a localização
 Bancos de Dados Centralizados::

 Localizados em uma única máquina denominada
Servidor de Banco de Dados
 Embora centralizados, podem oferecer suporte a acesso
concorrente de vários usuários
Classificação quanto a localização
 Bancos de Dados Distribuídos:

 O sistema gerenciador e o banco de dados estão
localizados em diferentes máquinas interligadas em
redes (LANS ou WANS)
 Independentemente de serem centralizados ou
distribuídos os SGBDs atualmente trabalham dentro da
aquitetura cliente-servidor
 Bancos de Dados Heterogêneos:
 Tendência que vem crescendo muito atualmente:
distribuir na arquitetura de SGBDs vários bancos de
dados de fornecedores diferentes
Resumo
 Quais os tipos de classificações dos bancos de
dados?
Podem ser classificados quanto a(o):
 modelo de dados
 número de usuários
 localização
 Como são classificados os bancos de dados
quanto aos MODELOS DE DADOS?
 hierárquicos
 em rede
 relacionais
 orientados a objetos
quanto ao NÚMERO DE USUÁRIOS?
 monousuários
 multiusuários
quanto a sua LOCALIZAÇÃO?
 centralizados
 distribuídos
Principais SGBDs
Oracle Database
 1977: Larry Ellison, Bob Miner e Ed Oates fundam a
SDL (Software Level Laboratories)
 1978: O nome da empresa é mudado para RSI
(Rational Software Inc.)
 1979: A RSI lança o primeiro produto comercial de
banco de dados relacional utilizando a linguagem
SQL
 1983: Lançado o Oracle 3, o primeiro SGBD a rodar
em mainframes e em minicomputadores
 Versão atual: 11g
www.oracle.com/br/index.html
SQL Server
 Lançado pela Microsoft em 1988
 Inicialmente era uma versão especial do
Sybase (parceria com a Microsoft, encerrada
em 1994)
 SQL Server 2005: grande integração com a
plataforma .NET
 Versão atual: SQL Server 2008
www.microsoft.com/sqlserver/2008/pt/br/default.aspx
DB2
 Projeto começou no início dos anos 70 (Edgar
Frank Codd – IBM)
 A princípio o produto foi chamado System R
 Lançado em 1983 com base no SQL/DS (para
mainframe)
 A partir da década de 90 inclui versões para
Windows, LINUX e PDAs
 2006: Lançamento do DB2 9 Express
 DB2 9 é o primeiro SGBD que, segundo a IBM
armazena XML nativo
Teradata
 Teradata foi uma divisão da NCR Corporation,
adquirida em 1991
 É apresentado como um sistema de Data
Warehouse que armazena e gerencia dados.
 O Gartner Group, em 2011, elege a Teradata
como líder global em bancos de dados de
Data Warehouse.
www.teradata.com
MySQL
 Desenvolvido a partir de 1995 por David
Axmark, Allan Larsson e Michael Widenius
 Adquirida pela Sun em 2008 (US$ 1 bilhão)
 2009: Oracle compra a SUN (US$ 7,8 bilhões)
 Licença: GNU-GPL (General Public License)
 Versões para Windows, LINUX, UNIX,
FreeBSD e Mac OS X
 Muito utilizado em soluções para Web
www.mysql.com
PostgreSQL
 Origem: Projeto POSTGRE, Universidade Berkeley,
Califórnia. Equipe orientada pelo Prof. Michael
Stonebraker
 1988: primeira versão estável
 1991: Código adquirido pela Illustra, a qual se
fundiu com a Informix (de Stonebraker), hoje
pertencente à IBM
 Licença: BSD (Berkeley Software Distribution)
 Versões para LINUX, UNIX, Mac OS X e Windows
www.postgresql.org/
Informix
 Projetado por Roger Sippl no final dos anos 70
 A Informix foi fundada em 1980 e tornou-se pública
em 1986
 Na década de 90 foi o segundo banco mais popular
depois do Oracle
 Em 2001 a IBM, por sugestão do Wal-Mart (O maior
usuário do Informix), adquiriu a Informix
 Em meados de 2005, a IBM lançou a versão 10 do
Informix IDS
www.ibm.com/informix
Sybase
 Fundada por Mark Hoffman e Bob Epstein
em 1984, em Berkeley, na Califórnia
 A empresa atua em 120 países e tem mais
de 82.000 clientes.
 2010: A SAP adquire a Sybase por
US$ 5,8 bilhões
www.sybase.com.br
InterBase
 Lançado em 1984 pela Groton Database
Systems (Interbase, a partir de 1986, a
empresa passou a ser controlada, em 1991,
pela Borland)
 Comercializado atualmente através da
Embarcadero Technologies
 A versão 6.0 deu origem ao FireBird (open
source)
www.embarcadero.com/products/interbase
FireBird
 A versão 6.0 deu origem ao FireBird (open
source)
 Versão atual 2.5.1, lançada em outubro de
2011
www.firebirdsql.org/
de Banco de Dados
Aula 3
SGBDOOs
Sistemas Gerenciadores de Banco
de Dados Orientados a Objetos
SGBDOO
 Os SGBDs baseados nos modelos relacional, em
rede ou hierárquico apresentam deficiências
quando é preciso desenvolver aplicações para
engenharia (CAE/CAD/CAM), para Sistemas de
Informações Geográficas, simulações científicas ou
médicas, etc.
 Essas aplicações fazem uso de estruturas de dados
complexas (vídeos, imagens, áudio, textos
formatados, etc.)
 Para atender a esta demanda surgiram os
SGBDOOs (Sistemas Gerenciares de Banco de
Dados Orientados a Objetos).
SGBDOO
 Outro fator que impulsionou o desenvolvimento de
SGBDOOs foi a crescente popularidade de
linguagens orientadas a objetos:
 Smalltalk
 C++
 Java
SGBDOO
 Vários protótipos foram desenvolvidos, alguns
inclusive foram disponibilizados comercialmente:
 GemStone (www.gemstone.com)
 Objectivity (www.objectivity.com)
 ObjectStore (http://web.progress.com/pt-br/objectstore/index.html)
 FastObjects (http://www.versant.com/en_US/products/fastobjects)
 Versant (http://www.versant.com/en_US/products/objectdatabase)
 OpenODB (Hewlett-Packard)
SGBDOO
 Para propor uma linguagem padrão para os bancos
de dados orientados a objetos foi formado o ODMG
(Object Database Management Group)
 O grupo propôs um padrão conhecido como
ODMG-93, atualmente denominado ODMG 2.0
 O padrão foi adotado mundialmente pelos
fornecedores e usuários de SGBDOOs
 O ODMG é responsável também pela definição de
um padrão de linguagem para o modelo orientado a
objetos.
SGBDOO
 O ODMG é responsável também pela definição de
um padrão de linguagem para o modelo orientado a
objeto:
 ODL (Object Definion Language)
 OQL (Object Query Language)
 Nesse padrão foi estabelecido que o banco de
dados orientado a objeto deve possuir um vínculo
com alguma linguagem hospedeira orientada a
objeto (Smalltalk, C++, Java, etc.)
 O padrão define também os tipos de dados e
métodos a serem suportados pelo sistema
SGBDOO
 Uma das principais características dos sistemas de
banco de dados orientados a objetos é que o
desenvolvedor pode especificar não apenas a
estrutura de dados de objetos, mas também
funções que desempenham operações nesses
objetos, comumente chamados de métodos.
SGBDOO
 Cada objeto armazenado no banco de dados possui
uma referência única, gerado pelo sistema quando
ele é adicionado, denominada OID (Object
Identifier). Normalmente utilizam-se números
inteiros grandes como OIDs.
 Este identificador não é visível ao usuário e é
responsável pela correspondência entre um objeto
do "mundo real" e um objeto do banco de dados.
 O identificador não se repete entre objetos
diferentes e quando um objeto é excluído o seu OID
não é reutilizado em um novo objeto criado no
banco de dados, nem pode ser alterado pelo
sistema.
SGBDOO
 O estado de um objeto (seu valor corrente) é
determinado a partir de outros objetos ou valores
utilizando-se construtores de tipos.
 Há seis construtores básicos:
 atom (valores atômicos)
 tuple (tupla/registro de tabela)
 set (conjunto de valores)
 list (lista ordenada)

 bag e array (matriz de dados)
SGBDOO
 Os construtores de tipos são utilizados na definição
das estruturas de bancos de dados.
 Exemplo:
define type Cliente:
tuple (CodigoCliente integer;
NomeCliente string;
Telefone string;
Email string;);
SGBDOO
ENCAPSULAMENTO/OCULTAÇÃO:
 Uma aplicação nunca acessa ou modifica
diretamente os valores de um objeto.
 Essas operações somente são efetuadas por meio
da chamada dos métodos desse objeto.
 Os métodos são invocados por meio do envio de
mensagens ao objeto.
 Exemplo:
objNovoCliente = Cliente.novo_cliente("Fulano");
SGBDOO
 Apesar das suas qualidades, um banco de dados
orientado a objetos normalmente apresenta
problemas relacionados ao desempenho e à
escalabilidade.
 Não são também adequados na manipulação de
dados convencionais, como os existentes em bases
relacionais.
SGBDOO – DB4OBJECTS
SGBDOO – CACHÉ
de Banco de Dados
Aula 4
SGBDORs
Sistemas Gerenciadores de Banco
de Dados Objeto-Relacionais
SISTEMAS HÍBRIDOS
(OBJETO-RELACIONAL)
 Fornecedores de bancos de dados relacionais

adicionaram a seus produtos capacidade de
incorporar objetos mais complexos (imagem, som e
vídeo) além de recursos de orientação a objetos.
 No entanto, isso não os torna sistemas puramente
orientados a objetos, apesar de sua denominação
ORDMS – Object-Relacional Database Management
System (Sistema de Gerenciamento de Banco de
Dados Objeto-Relacional).
SISTEMAS HÍBRIDOS
(OBJETO-RELACIONAL)
 Esses sistemas na realidade implementam uma

camada de abstração de dados em cima de
métodos relacionais, o que torna possível a
manipulação de dados mais complexos.
 Seguem, portanto, as especificações da SQL3 que
fornecem capacidades estendidas e de objetos
adicionadas ao padrão SQL.
SISTEMAS HÍBRIDOS
(OBJETO-RELACIONAL)
 Alguns Sistemas de Gerenciamento de Banco de

Dados Objeto-Relacionais:
 Informix Universal Server
 IBM DB2 Universal DB
 Oracle Database 10g
 O Informix Universal Server, hoje pertencente à
IBM, combina as tecnologias de banco de dados
relacionais e banco de dados orientado a objetos
que já existiam em dois produtos independentes: o
Informix Dynamic Server e o Illustra.
IMPLEMENTAÇÃO OBJETO-RELACIONAL
NO ORACLE
 O Oracle 10g incorporou ao banco de dados

relacional a tecnologia orientada a objetos,
tornando-se assim um SGBD Objeto-Relacional.
 Ele nem pode ser considerado puramente orientado
a objetos, nem tampouco apenas relacional.
 Todas as características relacionais permanecem,
ou seja, as tabelas continuam a existir, porém elas
possuem alguns recursos adicionais.
NO ORACLE
 Anteriormente, as tabelas apenas podiam conter

valores atômicos em seus atributos, agora pode-se
definir novos tipos de dados e usá-los para receber
valores complexos.
 O Oracle, a partir da versão 9i, permite que os
usuários criem outros tipos de objetos, de tabelas,
referências para objetos, entre outros.
 Observe a seguir alguns recursos interessantes
oferecidos nas últimas versões do Oracle:
NO ORACLE
 TIPO OBJETO
 Podemos criar tipos de dados adicionais e depois fazer
referência a eles dentro de outros objetos.
 Os tipos criados são gravados no esquema armazenado no
banco de dados. Outras declarações que acessam o banco de
dados podem fazer uso das definições desses tipos.
CREATE TYPE T_PESSOA AS OBJECT (
CODIGO_PESSOA NUMBER(5),
NOME_PESSOA VARCHAR2(50),
ENDERECO VARCHAR2(50)) NOT FINAL;
 Por padrão, os tipos de objeto são FINAL. Para permitir subtipos,
deve ser obrigatoriamente adicionada a expressão NOT FINAL à
declaração do tipo do objeto.
NO ORACLE
 HERANÇA
 Um dos recursos mais importantes da orientação a objetos é a
herança.
 A definição do tipo T_PESSOA no exemplo anterior pode
funcionar como uma super-classe. A partir dela podemos definir
outros dois tipos, T_FISICA e T_JURIDICA:
CREATE TYPE T_FISICA UNDER T_PESSOA (
CPF CHAR(11),
SEXO CHAR(1));
CREATE TYPE T_JURIDICA UNDER T_PESSOA (

CNPJ CHAR(14),
INSC_ESTADUAL VARCHAR(30));
NO ORACLE
 HERANÇA
 Criação das tabelas PESSOA_FISICA e PESSOA_JURIDICA:
CREATE TABLE PESSOA_FISICA OF T_FISICA;
CREATE TABLE PESSOA JURIDICA OF T_JURIDICA;
 Inserção de dados na tabela PESSOA_FISICA:

INSERT INTO PESSOA FÍSICA VALUES
(1,'FULANO','RUA X, 10','11122233399','M');
 Seleção de dados na tabela PESSOA_FISICA:

SELECT * FROM PESSOA_FISICA;
NO ORACLE
 TABELAS ANINHADAS (NESTED TABLES)

 Nested tables são tabelas cujo tipo de dado é domínio de outra
tabela:
CREATE TYPE T_ENDERECO AS OBJECT (
RUA VARCHAR2(50),
NUMERO INTEGER,
CIDADE VARCHAR2(50),
UF CHAR(2),
CEP CHAR(9));
CREATE TYPE ENDERECOS AS TABLE OF T_ENDERECO;

NO ORACLE
 ARRAY
 O exemplo a seguir cria um tipo chamado TELEFONES que permite

inserir até cinco telefones diferentes:
CREATE TYPE TELEFONES AS VARRAY (5) OF VARCHAR2(10);

NO ORACLE
 CRIAÇÃO DE TABELAS COM OS TIPOS DEFINIDOS:

 O exemplo a seguir cria uma tabela chamada CLIENTE que utiliza os
tipos definidos anteriormente:
CREATE TABLE CLIENTE (

CODIGO_CLIENTE NUMBER(5),
NOME_CLIENTE VARCHAR2(50),
TELEFONE_CLIENTE TELEFONES,
ENDERECO_CLIENTE ENDERECOS)
NESTED TABLE ENDERECO_CLIENTE STORE AS ENDERECOS_TAB;
NO ORACLE
 INSERIR DADOS NA TABELA:

INSERT INTO CLIENTE VALUES (
1,'FULANO',
TELEFONES ('11111111','22222222'),
ENDERECOS (
T_ENDERECO ('RUA X',10,'SÃO PAULO','SP','10000-000'),
T_ENDERECO ('RUA Y',20,'JUNDIAÍ','SP','20000-000')));
 SELECIONAR DADOS DA TABELA:

SELECT * FROM CLIENTE;
SELECT C.CODIGO_CLIENTE, C.NOME_CLIENTE, E.RUA

FROM CLIENTE C, TABLE(C.ENDERECO_CLIENTE) E;
Bancos de Dados Distribuídos

BANCOS DE DADOS DISTRIBUÍDOS
 A arquitetura de banco de dados distribuído descreve a

situação em que um banco de dados está em mais de um
local, no entanto, está acessível como se estivesse
localizado de maneira central.
 A escolha de um banco de dados distribuído representa

uma redução nos custos de comunicação e um aumento
na complexidade.
fonte: WATSON, Richard T. Data management – Banco de Dados e Organizações

Imagine uma empresa com sede em Londres e com
filiais em São Paulo e em Tóquio.
Seus custos de comunicação serão menores se a
maior parte de suas consultas forem realizadas
localmente.
Em um Banco de Dados Distribuído a consulta:
apresente os nomes de dos clientes que
compraram o Produto X no Brasil, provavelmente
será iniciada em São Paulo e processada utilizando-se
a parte do Banco de Dados localizada nesta cidade.
Por outro lado, a consulta: apresente os nomes de
todos os clientes que compraram o produto X,
independentemente de onde for iniciada, acessará
cada um dos bancos de dados, embora o usuário
provavelmente não saiba onde os dados estão
armazenados.
Um SGBDD (Sistema de Gerenciamento de Banco
de Dados Distribuído) é uma "aliança" de SGBDs
individuais.
Um SGBDD introduz a necessidade de um

armazenamento que contenha detalhes sobre a
estrutura e a localização de cada banco de dados,
tabela, coluna, linha e suas possíveis cópias devem
ser registradas.
O catálogo de sistema também deve ser distribuído,

caso contrário, cada solicitação de informação teria
que passar por um ponto central e isto criaria um
gargalo dispendioso.
Objetivos a serem alcançados pelos SGBDDs:
1. Autonomia local
2. Não dependência de um site central
3. Operação contínua
4. Independência de localização
5. Independência de fragmentação
6. Independência de replicação
7. Processamento de consultas distribuído
8. Gerenciamento de transações distribuído
9. Independência do hardware
10. Independência do sistema operacional
11. Independência da rede
12. Independência do SGBD

1. Autonomia Local
Os dados são recebidos e gerenciados no local, que
é também responsável pela segurança, integridade e
armazenamento dos dados locais.
A cooperação entre os vários centros de dados
exige que a autonomia local não seja absoluta.
2. Não dependência de um site central

O controle deve ser distribuído por todo o sistema.
A dependência de um site central causaria problemas
para consultas processadas em horários de pico e se
ocorresse uma falha no site central todo o sistema
também falharia.
3. Operação contínua
O sistema deve ser acessível quando requisitado.
As operações tornam-se cada vez mais globalizadas.
Portanto, o sistema deve estar disponível 7 dias por
semana e 24 horas por dia.
4. Independência de localização
O usuário não precisa saber onde os dados são
armazenados e como são processados. A localização
dos dados, o formato de armazenamento e o método
de acesso devem ser transparentes ao usuário.
5. Independência de fragmentação
A independência de fragmentação significa que
qualquer tabela pode ser partida em fragmentos e
armazenada em diferentes locais físicos.
A fragmentação é a chave para um SGBDD. Sem a
fragmentação os dados não podem ser distribuídos.
6. Independência de replicação
A replicação significa que um fragmento dos dados
pode ser copiado e fisicamente armazenado em vários
sites. Um fragmento localizado em Londres poderia ser
armazenado em São Paulo e um segmento localizado
em São Paulo poderia ser armazenado em Londres.
7. Processamento de consultas distribuído
A decisão quanto ao modo mais eficaz de
processamento de consultas é responsabilidade do
sistema, não do usuário. O sistema é responsável pela
decisão de quais mensagens e quais dados serão
enviados entre os vários sites em que as tabelas estão
localizadas.
8. Gerenciamento de transações distribuído

Em um SGBDD uma única transação pode precisar
atualizar vários arquivos em vários sites. O sistema
deve garantir que a transação será executada com
exito em todos os sites. Atualizações parciais causarão
inconsistências.
9. Independência de hardware
Um SGBDD deveria ser compatível com o hardware

de vários fornecedores sem afetar a capacidade dos
usuários de realizar consultas à base de dados.
10. Independência de Sistema Operacional
Os vários SGBDDs e as aplicações devem trabalhar

com os principais Sistemas Operacionais disponíveis
no mercado.
11. Independência de rede
Se o sistema deve ser capaz de admitir muitos sites
diferentes, com diferentes tipos de hardware e
sistemas operacionais distintos, é evidentemente
desejável ter a possibilidade de admitir uma variedade
de redes de comunicações distintas.
12. Independência de SGBD

Como a SQL é um padrão para os SGBDRs, é
possível, em grande parte dos casos, alcançar esta
independência.
ACESSO A DADOS DISTRIBUÍDOS
SOLICITAÇÃO REMOTA
SELECT NOME_CLIENTE
FROM SP_SERVER.NM_BANCO.CLIENTE
WHERE CODIGO_CLIENTE = 1005;
TRANSAÇÃO REMOTA
BEGIN WORK
INSERT INTO SP_SERVER.NM_BANCO.CLIENTE
(CD_CLIENTE, NOME_CLIENTE)
VALUES (1003, 'FULANO DE TAL')
INSERT INTO SP_SERVER.NM_BANCO.PEDIDO
(NR_PEDIDO, CD_CLIENTE)
VALUES (5350, 1003)
COMMIT WORK;
SOLICITAÇÃO DISTRIBUÍDA
BEGIN WORK
CREATE VIEW TEMP
(CD_CLIENTE, NOME_CLIENTE)
AS
SELECT CD_CLIENTE, NOME_CLIENTE
FROM SP_SERVER.NM_BANCO.CLIENTE
UNION
SELECT CD_CLIENTE, NOME_CLIENTE
FROM TQ_SERVER.NM_BANCO.CLIENTE
COMMIT WORK;
PROJETO DE BANCO DE DADOS DISTRIBUÍDOS
 FRAGMENTAÇÃO HORIZONTAL
 FRAGMENTAÇÃO VERTICAL
 FRAGMENTAÇÃO HÍBRIDA (HORIZONTAL/VETICAL)
 REPLICAÇÃO
VIEWS (VISÕES)

VIEWS
 Uma visão é uma consulta baseada em uma ou

mais tabelas (denominadas tabelas base)
 As consultas em visões são realizadas da mesma

maneira que as consultas em tabelas: basta incluir o
nome da visão na cláusula WHERE.
 É possível realizar (com algumas restrições)

operações DML (INSERT, UPDATE E DELETE) nas
tabelas base através das visões.
VIEWS
Por que utilizar visões?

VIEWS
 Visões ajudam a melhorar a segurança no acesso aos dados.

---------------------------------------
TABELA: FUNCIONARIO
---------------------------------------
CODFUN NOME DEPTO SALARIO
---------------------------------------
1001 FULANO ENGENHARIA 5200
1002 BELTRANO MARKETING 3800
1003 CICRANO JURÍDICO 4600
-----------------------------
VISAO: FUNCIONARIO_VIEW
-----------------------------
CODCLI NOME DEPTO
-----------------------------
1001 FULANO ENGENHARIA
1002 BELTRANO MARKETING
1003 CICRANO JURÍDICO
Pode-se conceder acesso somente às visões e impedir a realização de

consultas diretamente nas tabelas.
VIEWS
 Visões facilitam a realização de consultas complexas

baseadas em duas ou mais tabelas.
--------------------- ------------------
TABELA: CLIENTE TABELA: PEDIDO
--------------------- ------------------ SELECT C.UF, SUM(P.VALOR)
CODCLI NOME UF NR VALOR CODCLI FROM CLIENTE C
--------------------- ------------------ INNER JOIN PEDIDO P
1001 FULANO SP 1 4800 1002 ON C.CODCLI = P.CODCLI
1002 BELTRANO RJ 2 3600 1003 GROUP BY C.UF;
1003 CICRANO SP 3 5500 1001
--------------------------------
VISAO: CLIENTE_PEDIDO_VIEW
-------------------------------- SELECT UF, SUM(VALOR)
CODCLI NOME UF NR VALOR FROM CLIENTE_PEDIDO_VIEW
-------------------------------- GROUP BY UF;
1001 FULANO SP 1 4800
1002 BELTRANO RJ 2 3600
1003 CICRANO SP 3 5500
VIEWS >>> EXERCÍCIO 1 <<<
 Criar a tabela e a visão conforme exemplo abaixo:

NOTA: Criar a visão com restrição READ ONLY.
---------------------------------------
TABELA: FUNCIONARIO
---------------------------------------
---------------------------------------
-----------------------------
-----------------------------
CODFUN NOME DEPTO
-----------------------------
1001 FULANO ENGENHARIA
 Criar a tabela e a visão conforme exemplo abaixo:

NOTA: Criar a visão com restrição READ ONLY.
---------------------------------------
TABELA: FUNCIONARIO
---------------------------------------
---------------------------------------
-----------------------------
----------------------------- CREATE VIEW FUNCIONARIO_VIEW AS
CODFUN NOME DEPTO SELECT CODFUN, NOME, DEPTO
----------------------------- FROM FUNCIONARIO
1001 FULANO ENGENHARIA WITH READ ONLY CONSTRAINT FUNC_READ_ONLY;
 Criar as tabelas e a visão conforme exemplo abaixo:

--------------------- ------------------
--------------------- ------------------
CODCLI NOME UF NR VALOR CODCLI
--------------------- ------------------
1001 FULANO SP 1 4800 1002
1002 BELTRANO RJ 2 3600 1003
1003 CICRANO SP 3 5500 1001
--------------------------------
--------------------------------
CODCLI NOME UF NR VALOR
--------------------------------
1001 FULANO SP 1 4800
1002 BELTRANO RJ 2 3600
1003 CICRANO SP 3 5500
 Criar as tabelas e a visão conforme exemplo abaixo:

--------------------- ------------------
--------------------- ------------------
CODCLI NOME UF NR VALOR CODCLI
--------------------- ------------------
1001 FULANO SP 1 4800 1002
1002 BELTRANO RJ 2 3600 1003
1003 CICRANO SP 3 5500 1001
--------------------------------
-------------------------------- CREATE VIEW CLIENTE_PEDIDO_VIEW AS
CODCLI NOME UF NR VALOR SELECT C.CODCLI, C.NOME, C.UF,
-------------------------------- P.NR, P.VALOR
1001 FULANO SP 1 4800 FROM CLIENTE C
1002 BELTRANO RJ 2 3600 INNER JOIN PEDIDO P
1003 CICRANO SP 3 5500 ON C.CODCLI = P.CODCLI;
Criar um trigger instead of para incluir dados nas tabelas CLIENTE e

PEDIDO através da visão CLIENTE_PEDIDO_VIEW:
CREATE OR REPLACE TRIGGER CLI_PED_INSERT

INSTEAD OF INSERT ON CLIENTE_PEDIDO_VIEW
REFERENCING NEW AS N
FOR EACH ROW
DECLARE
rowcnt number;
BEGIN
SELECT COUNT(*) INTO rowcnt FROM CLIENTE WHERE CODCLI = :N.CODCLI;
IF rowcnt = 0 THEN
INSERT INTO CLIENTE (CODCLI,NOME,UF) VALUES (:N.CODCLI, :N.NOME, :N.UF);
ELSE
UPDATE CLIENTE SET CLIENTE.NOME = :N.NOME, CLIENTE.UF = :N.UF
WHERE CLIENTE.CODCLI = :N.CODCLI;
END IF;
SELECT COUNT(*) INTO rowcnt FROM PEDIDO WHERE NR = :N.NR;
IF rowcnt = 0 THEN
INSERT INTO PEDIDO (NR,VALOR,CODCLI) VALUES (:N.NR, :N.VALOR, :N.CODCLI);
ELSE
UPDATE PEDIDO SET PEDIDO.VALOR = :N.VALOR, PEDIDO.CODCLI = :N.CODCLI
WHERE PEDIDO.NR = :N.NR;
END IF;
END;
/
MATERIALIZED VIEW
 Uma visão materializada é um objeto de banco de

dados que contém o resultado de uma consulta.
 Visões materializadas permitem manter cópias de

dados remotos em um banco de dados local.
 Para seleção de dados de uma visão materializada,

utiliza-se a mesma forma de manipulação de uma
tabela ou visão normal.
MATERIALIZED VIEW
CRIAR A TABELA ALUNO CONFORME SEGUE:
----------------
TABELA: ALUNO
----------------
RA NOME
----------------
1001 ANTONIO
1002 BEATRIZ
1003 CLAUDIO
CRIAR UM LOG DE VIEW MATERIALIZADA (MATERIALIZED VIEW LOG):
Os logs de visões materializadas são usados para sincronização entre a tabela base
(master table) e a visão.
Antes da criação da visão materializada, a master table deve ser associada a um
um materialized view log.
CREATE MATERIALIZED VIEW LOG ON ALUNO;

MATERIALIZED VIEW
CRIAR A VISÃO MATERIALIZADA QUE SERÁ ATUALIZADA MANUALMENTE:

CREATE MATERIALIZED VIEW ALUNO_VIEW_1
-- popular a view no momento de sua criação
BUILD IMMEDIATE
-- selecionar os dados da tabela base
AS SELECT * FROM ALUNO;
CONSULTAR A VIEW ALUNO_VIEW_1:

SELECT * FROM ALUNO_VIEW_1;
INSERIR UMA NOVA LINHA NA TABELA ALUNO:

INSERT INTO ALUNO (RA, NOME) VALUES (4,'DANIELA');
COMMIT;
UTILIZAR A PROCEDURES DBMS_MVIEW.REFRESH PARA ATUALIZAR A VIEW:

CALL DBMS_MVIEW.REFRESH ('ALUNO_VIEW_1','F');
-- F: FAST (INCREMENTAL) | C: COMPLETE (COMPLETA) | ?: FORCE (INCREMENTAL
-- SE POSSÍVEL, CASO NÃO SEJA, REALIZA UMA ATUALIZAÇÃO COMPLETA)

MATERIALIZED VIEW
CRIAR A VISÃO MATERIALIZADA QUE SERÁ ATUALIZADA AUTOMATICAMENTE:
CREATE MATERIALIZED VIEW ALUNO_VIEW_2

-- popular a view no momento de sua criação
BUILD IMMEDIATE
-- atualizar de forma incremental a cada 1 segundo
REFRESH FORCE START WITH SYSDATE NEXT SYSDATE + 1/86400
-- selecionar os dados da tabela base
AS SELECT * FROM ALUNO;

INSERIR UMA NOVA LINHA NA TABELA ALUNO:

INSERT INTO ALUNO (RA, NOME) VALUES (5,‘ERNESTO');
COMMIT;

INDEXES (ÍNDICES)

INDEXES
 Índices permitem acesso mais rápido a

determinadas linhas de uma tabela quando um
pequeno subconjunto de linhas for selecionado.
 Portanto, os índices armazenam os valores das

colunas que estão sendo indexadas juntamente com o
RowID físico da respectiva linha, exceto no caso das
tabelas organizadas por índice, que utilizam a Primary
Key como um RowID lógico.
INDEXES
 O Oracle dispõe de vários tipos de índices,

específicos para cada tipo de tabela, método de
acesso ou ambiente de aplicação. Os principais tipos
de índices são:
 Índices únicos;
 Índices não únicos;
 Índices de chave invertida;
 Índices baseados em funções;
 Índices de bitmap.
INDEXES
Índices únicos (exclusivos)
 Os índices únicos são os mais comuns do tipo árvore B e

são utilizados principalmente para impor a constraint Primary
Key de uma tabela. Este tipo de índice garante que não
existirão valores duplicados na coluna ou nas colunas
indexadas.
CREATE TABLE nome_da_tabela (
nome_coluna_1 tipo_de_dado(tamanho),
...
CONSTRAINT nome_da_constraint PRIMARY KEY(nome_da_coluna_1)
);
INDEXES
Índices não únicos (não exclusivos)
 Os índices não únicos, apesar de não impor exclusividade

de valores, aceleram o acesso aos dados quando a consulta for
realizada utilizando-se como parâmetro a coluna ou as colunas
indexadas. Pode-se, por exemplo, criar um índice deste tipo na
coluna NOME de uma tabela denominada CLIENTE para
localizar mais rapidamente os dados de um cliente a partir de
seu nome.
CREATE INDEX nome_do_indice ON nome_da_tabela(nome_da_coluna);
INDEXES
Índices de chave invertida

 Todos os bytes no valor de chave são invertidos nos índices
de chave invertida. Por exemplo, para o número de pedido 1234
o índice de chave invertida armazenará como 4321. Um de seus
principais objetivos é evitar disputas em sistemas multiusuários.
Quando muitos usuários estiverem inserindo simultaneamente
linhas com chaves baseadas em valores que aumentam
sequencialmente, todas as suas inserções de índice são
concentradas na extremidade mais alta do índice. Optando-se
por índices de chave invertida, as inserções de chave de índice
consecutiva são distribuídas por todo o intervalo do índice.
CREATE INDEX nome_do_indice ON nome_da_tabela(nome_da_coluna)
REVERSE;
INDEXES
Índices baseados em funções
 Um índice baseado em função calcula o valor de uma função

ou expressão envolvendo uma ou mais colunas e o armazena no
índice. O índice baseado em função pode ser uma árvore B ou
um índice de bitmap (ver tópico seguinte). A função usada para
construir o índice pode ser uma expressão aritmética, uma
expressão que contém uma função SQL, uma função definida
pelo usuário utilizando PL/SQL, etc.
CREATE INDEX nome_do_indice ON nome_da_tabela(expressão|função);
INDEXES
Índices de bitmap
 Os índices de mapas de bits estão disponíveis apenas na

versão Enterprise Edition do Oracle. Um índice de bitmap
armazena os RowIDs associados ao valor da chave como um
bitmap. O comprimento da string de bits é, portanto, igual ao
número de linhas que está sendo indexada. Este tipo de índice é
especialmente recomendável quando:
 O número de valores distintos na coluna é baixo;
 O número de linhas na tabela é alto;
 A coluna é utilizada em operações de álgebra booleana.
CREATE BITMAP INDEX nome_do_indice

ON nome_da_tabela(nome_da_coluna);
INDEXES
Índices de bitmap
 O exemplo a seguir apresenta um índice de bitmap
associado à coluna CAMPUS da tabela ALUNO:
ALUNO ÍNDICE DE BITMAP

RA NOME CAMPUS CAMPUS BITMAP
111222333 Antonio Alves Vila Maria Vila Maria 100001000
222333444 Beatriz Bernardes Memorial Memorial 010010001
333444555 Cláudio Carvalho Vergueiro Vergueiro 001000010
444555666 Daniela Damasceno Santo Amaro Santo Amaro 000100100
555666777 Ernesto Eliseu Memorial
666777888 Flávia Fernandes Vila Maria O bitmap correspondente ao
777888999 Higino Hipólito Santo Amaro campus Memorial é 010010001,
888999000 Isabel Inácio Vergueiro pois este valor aparece na 2ª, 5ª
e 9ª linha da tabela ALUNO.
999000111 Josué Jorgeano Memorial
INDEX ORGANIZED TABLES (IOTs)
 Tabelas organizadas por índice permitem que os dados do

índice e da tabela sejam armazenados juntos.
 Portanto, haverá uma redução significativa no espaço em
disco, porque as colunas indexadas não são armazenadas duas
vezes (uma vez na tabela e outra no índice).
 As IOTs devem ser utilizadas principalmente em tabelas em
que o método principal de acesso é a chave primária.
CREATE TABLE nome_da_tabela (
nome_coluna_1 tipo_de_dado(tamanho),
...
CONSTRAINT nome_da_constraint PRIMARY KEY(nome_da_coluna_1))
ORGANIZATION INDEX;
INDEXES >>> EXERCÍCIOS <<<
Criar um exemplo para cada um dos itens abaixo:
 Índices únicos;
 Índices não únicos;
 Índices de chave invertida;
 Índices baseados em funções;
 Índices de bitmap;
 Tabela organizada por índice.
Enviar o script para: unilivros@gmail.com

Sistemas Gereciadores de Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sistemas Gereciadores de Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas Gereciadores

 Sistemas gerenciadores de banco de dados relacionais;

 Conhecer os requisitos de instalação e recursos de alguns

 COSTA, Rogério L. de C. SQL Guia Prático. 2ª ed. Rio de

Conceitos e Características Gerais

SGBD (Sistema de Gerenciamento de Banco de Dados):

coleção de dados inter-relacionados

O principal objetivo de um SGBD é fornecer

Gerenciamento de dados envolve:

 Definir estruturas de armazenamento

 Fornecer mecanismos para a manipulação de informações

O SGBD precisa garantir a segurança

“Embora as interfaces de usuário ocultem

 Doze regras estabelecidas por

 Hoje encontramos uma grande variedade de

 Bancos de Dados Hierárquicos:

 Bancos de Dados em Rede:

 Bancos de Dados Relacionais:

 Bancos de Dados Orientados a Objetos:

 Bancos de Dados Monousuários:

 Bancos de Dados Multiusuários:

 Bancos de Dados Centralizados::

 Bancos de Dados Distribuídos:

 tuple (tupla/registro de tabela)

 set (conjunto de valores)

 list (lista ordenada)

 Fornecedores de bancos de dados relacionais

 Esses sistemas na realidade implementam uma

 Alguns Sistemas de Gerenciamento de Banco de

 O Oracle 10g incorporou ao banco de dados

 Anteriormente, as tabelas apenas podiam conter

CREATE TYPE T_JURIDICA UNDER T_PESSOA (

 Inserção de dados na tabela PESSOA_FISICA:

 Seleção de dados na tabela PESSOA_FISICA:

 TABELAS ANINHADAS (NESTED TABLES)

CREATE TYPE ENDERECOS AS TABLE OF T_ENDERECO;

 O exemplo a seguir cria um tipo chamado TELEFONES que permite

CREATE TYPE TELEFONES AS VARRAY (5) OF VARCHAR2(10);

 CRIAÇÃO DE TABELAS COM OS TIPOS DEFINIDOS:

CREATE TABLE CLIENTE (

 INSERIR DADOS NA TABELA:

 SELECIONAR DADOS DA TABELA:

SELECT C.CODIGO_CLIENTE, C.NOME_CLIENTE, E.RUA

Prof. Marcos Alexandruk

 A arquitetura de banco de dados distribuído descreve a

 A escolha de um banco de dados distribuído representa

fonte: WATSON, Richard T. Data management – Banco de Dados e Organizações

Um SGBDD introduz a necessidade de um

O catálogo de sistema também deve ser distribuído,

7. Processamento de consultas distribuído

8. Gerenciamento de transações distribuído

10. Independência do sistema operacional

11. Independência da rede

12. Independência do SGBD

2. Não dependência de um site central

8. Gerenciamento de transações distribuído

Um SGBDD deveria ser compatível com o hardware

10. Independência de Sistema Operacional

Os vários SGBDDs e as aplicações devem trabalhar

12. Independência de SGBD

 FRAGMENTAÇÃO HÍBRIDA (HORIZONTAL/VETICAL)

Prof. Marcos Alexandruk

 Uma visão é uma consulta baseada em uma ou