BD - Aspectos Basicos

Aspectos
Bsicos de
Banco de
Dados
Prof. Rogrio Gonalves Bittencourt, M.Sc.
Florianpolis, fevereiro de 2004.
ASPECTOS BSICOS DE BANCO DE DADOS
Copyright 2004. Adobe Acrobat eBookReader for Windows.

Todos os direitos reservados. O contedo deste livro somente para
informao e est sujeito a correes sem avisos. Nenhuma parte deste livro
pode ser reproduzida ou transmitida, em qualquer forma ou em qualquer
meio, eletrnico, gravao mecnica, ou qualquer outro, sem uma
permisso por escrito do autor. Por favor, lembre-se que a arte existente ou
imagens que voc pode querer incluir em seu projeto podem ser protegidas
pela lei de direitos autorais. A incorporao de tal material em seu trabalho
sem autorizao poderia ser uma violao dos direitos autorais. Por favor,
esteja certo de obter permisso do autor.
Contedo
INTRODUO
Qual a Diferena Entre Dados, Informao e Conhecimento
Banco de Dados
Sistema de Gerncia de Banco de Dados (SGBD)
Sistema de Banco de Dados
Porque Usar Banco de Dados
Vantagens do Controle Centralizado
O Que se Pode Almejar Com o Uso de SBD
Modelos de Dados
Arquitetura de um SGBD
Os Trs Nveis da Arquitetura
Nvel Externo
10
Nvel Conceitual
12
Nvel Interno
13
Mapeamentos
14
Linguagens de SGBDs
14
Independncia de Dados
16
Administrador de Banco de Dados
16
Exerccios
19
MODELOS DE DADOS (MODELOS CONCEITUAIS E LGICOS)
21
Classificao de Modelos de Dados
21
Modelos Lgicos Baseados Em Objetos
21
ii
Modelos Lgicos Baseados Em Registro
21
Modelos Fsicos de Dados
25
Classificao de SGBDs
25
Exerccios
25
MODELO RELACIONAL
27
Dicionrio de Dados
30
Tabelas de Exemplo do Dicionrio de Dados
31
Regras de Integridade Relacional
32
Implicaes das Regras
33
Especificao de Banco de Dados Relacional
33
As 12 Regras de Codd
34
INTEGRIDADE
43
Controle de Integridade Semntica do Banco de Dados
43
Classificao dos Requisitos de Integridade (RI)
45
Mtodos Utilizados no Suporte Especificao de Restries de Integridade

47
Definio e Teste de Restries de Integridade
47
Exemplo de Manuteno de Restrio de Integridade Com e Sem

48
TRIGGER (SQL)
Triggers Podem Causar Problemas
Tcnicas Para a Implementao de Controle Automtico de RIs no SGBD
Vantagens do Esquema Pr-Compilativo
49
50
50
VISES
53
Vantagens
55
Algumas Sugestes Importantes
55
TRIGGERS
56
iii
Vantagens
57
Utilizao de Triggers
57

Introduo
Introduo
Neste captulo apresentaremos alguns termos (terminologia) e
conceitos de grande importncia.
Qual a Diferena Entre Dados, Informao e

Conhecimento
DADOS - representao de fatos, conceitos ou instrues de maneiras
formalizadas,
adequadas
para
comunicao,
interpretao
ou
processamento por pessoas ou meios automatizados.
INFORMAO - significado que pessoas associam aos dados atravs
de convenes usadas em sua interpretao.
CONHECIMENTO - discernimento, critrio, apreciao prtica de vida,
experincia.
Banco de Dados
Um banco de dados um conjunto de arquivos
relacionados entre si (Chu, 1983)
Um banco de dados uma coleo de dados
operacionais armazenados, sendo usados pelos sistemas de
aplicao de uma determinada organizao (C. J. Date,
1985)
Um banco de dados uma coleo de dados
relacionais (Elmasri & Navathe, 1989)
Um banco de dados um conjunto de dados
armazenados, cujo contedo informativo representa, a cada
instante, o estado atual de uma determinada aplicao
(Laender, 1990)

Introduo
Baseado nas definies acima se pode deduzir ento que Banco de

Dados :
Coleo de dados relacionados;

Coleo logicamente coerente de dados com algum significado
inerente;
Um BD est sempre associado a aplicaes e a usurios que tm
interesse nele.
Ex: Agenda de endereos
Sistema de Gerncia de Banco de Dados (SGBD)

O SGBD permite a definio, construo e manipulao
do banco de dados para diversas aplicaes.
DEFINIO do BD:
Envolve a especificao dos tipos de dados a serem armazenados no BD,
mais a descrio de cada tipo de dado.
CONSTRUO do BD:
Processo de armazenar os dados em um meio controlado pelo SGBD.
MANIPULAO do BD:
Execuo de operaes de consulta e recuperao de dados especficos,
alm de atualizao de dados para refletir, no BD, mudanas no minimundo sendo modelado. A manipulao inclui, tambm, a gerao de
relatrios a partir dos dados do BD.
Sistema de Banco de Dados

Sistema de Banco de Dados um sistema de software composto
pelos programas de aplicao, pelo SGBD e pelo BD, para um conjunto de
aplicaes de uma mesma organizao.
Programas de aplicao, colocado na definio acima, so
programas que realizam funes da aplicao. EX.: clculo das dedues e
impostos, a partir da receita apurada, dos custos computados e da
legislao em vigor. Eles tambm so os responsveis pela garantia das
restries de integridade que no podem ser controladas pelo SGBD.
Implementam interfaces e relatrios especficos. Acessam o BD atravs do
SGBD para consulta e atualizao dos dados da aplicao.

Introduo
Resumindo:
SBD = BD + SGBD + PA
De acordo com (DATE,1985), um SBD dividido em mdulos que
tratam de partes, em separado, cada uma das responsabilidades do sistema
geral. Estes componentes fundamentais so:
Gerenciador de Arquivos que trata da alocao do espao para

armazenamento e das estruturas de dados utilizadas para representar
a informao armazenada no disco;
Gerenciador de Banco de Dados fornece a interface entre os
dados de baixo nvel armazenados no disco e os programas
aplicativos e de consulta submetidos ao sistema;
Processador de Consultas traduz as consultas escritas em uma
linguagem de alto nvel para instrues de baixo nvel que o
gerenciador do banco de dados entende;
Pr-compilador DML converte comandos DML embutidos em um
aplicativo para chamadas de procedimento normal na linguagem
hospedeira;
Arquivos de Dados armazenam banco de dados por si mesmos;
Dicionrio de Dados o componente responsvel pelo
armazenamento dos metadados sobre a estrutura do banco de
dados. O dicionrio de dados bastante utilizado;
Usurios
Ingnuos
Interfaces do
aplicativo
Programadores
de aplicativos
Usurios
sofisticados
Programas
aplicativos
Consulta
Esquema de
bancos de
Pr-compilador
da linguagem
de manipulao
de dados
Processador
de consultas
Compilador de
linguagem de
definio de
Cdigo objeto
de programas
aplicativos
Administrador de
banco de dados
Gerenciador
de banco
de dados
SGDB
Gerenciador
de arquivos
DISCO
Arquivos
de dados
Dicionrios
de dados

Introduo
Porque Usar Banco de Dados

Sistema de Banco de Dados proporciona empresa o controle
centralizado de seus dados operacionais. Tal situao contrasta nitidamente
com o que podemos encontrar em uma empresa que no utiliza um SGBD,
onde cada aplicao dispe de seus prprios arquivos de tal forma que os
dados operacionais so muito dispersos, dificultando o controle sistemtico.
Isto implica que exista um DBA, isto , um Administrador do Banco de Dados
(Database Administrator, em ingls).
Vantagens do Controle Centralizado

Reduzir Redundncia
Nos sistemas gerenciadores de arquivos, cada aplicao possui seus prprios
arquivos. Este fato costuma provocar uma redundncia considervel nos
dados armazenados, causando desperdcio de espao de armazenamento.
Evitar Inconsistncia
A inconsistncia conseqncia natural da redundncia. Suponhamos que
um certo fato do mundo real (o fato de que um fornecedor X fornece o item
Y para a empresa) representado por duas entradas distintas no banco de
dados, e que o SGBD no tenha conhecimento da duplicidade
(redundncia no controlada). Ocorrer que em determinado momento
duas entradas no so concordantes. Diz-se, ento, que o banco de dados
inconsistente.
Compartilhamento dos Dados
O compartilhamento no significa apenas que as aplicaes existentes
podem compartilhar os dados do banco de dados, mas tambm que novas
aplicaes podem ser desenvolvidas para operar sobre os mesmos dados
armazenados.
Padronizao
Pelo fato do controle centralizado, o SGBD pode assegurar que todos os
padres aplicveis sero observados na representao dos dados.
Restries de Segurana
O DBA (Adm. do Banco de Dados), detendo toda a autoridade sobre as
dados operacionais, pode assegurar:
Que os nicos meios de acesso ao banco de dados sejam

realizados atravs de certos canais;
Definir controles de segurana a adotar (principalmente para
dados especiais);

Introduo
Estabelecer diferentes controles para cada tipo de acesso

(recuperao, modificao, anulao, etc.), e para cada
parte da informao no banco de dados.
Manter a Integridade
O problema da integridade assegurar que os dados do banco de dados
sejam corretos (ntegros), ou seja, as informaes que compe o BD tm que
expressar exatamente o que foi informado, o BD no pode permitir que as
informaes se modifiquem incorretamente.
Integridade Referencial - os registros de relacionamentos

devem fazer referncia a ocorrncias de entidades existentes
no banco de dados. No deve haver relacionamento
referenciando uma chave primria inexistente.
Integridade Transacional - as transaes efetuadas na base de
dados devem ocorrer com segurana, completando-se ou no
o procedimento, os dados devem se manter ntegros.
Equilibrar Necessidades Conflitantes

O DBA, tendo conhecimento das necessidades globais da empresa (em
oposio s necessidades de um usurio individual) pode estruturar o
sistema, a fim de proporcionar um servio geral que seja o melhor para a
empresa.
Independncia dos Dados
Independncia de dados um dos objetivos de um SGBD, e consiste na
capacidade de isolar programas de aplicao das mudanas em estruturas
de armazenamento (esquema fsico), definio dos dados (esquema lgico)
e das estratgias de acesso do BD. Um SGBD que oferea independncia de
dados garante que programas continuem a rodar se os dados armazenados
forem reorganizados para atender a outra aplicao prioritria. Aplicaes
baseadas em sistemas de arquivos dependem dos dados.
O Que se Pode Almejar Com o Uso de SBD
Redundncia controlada de dados

Compartilhamento de dados por aplicaes diversas
Controle de autorizao de acesso a dados
Acesso a dados atravs de diferentes interfaces
Modelagem de relacionamentos complexos entre dados
Garantia de restries de integridade da aplicao
Garantia de consistncia fsica dos dados
Potencial para imposio de padres (modelagem
programao)
Flexibilidade na definio e manuteno dos dados
Reduo do tempo de desenvolvimento de aplicaes

Introduo
Modelos de Dados
Conjunto de conceitos que podem ser usados para descrever o BD.
Divide-se em Modelos Conceituais, Modelos de Implementao e Modelos
Fsicos.
Modelos Conceituais: Provem conceitos prximos aos percebidos por
muitos usurios. Usam conceitos como entidades, atributos e
relacionamentos.
EX: Modelo ER, Modelo OO
Modelos de Implementao: Tem conceitos que podem ser
entendidos pelos usurios e no esto muito distantes da maneira como os
dados so organizados fisicamente. So usados freqentemente em SGBDs
comerciais. Representam os dados usando estruturas de registro.
EX: Modelo Relacional, Modelo Rede, Modelo Hierrquico.
Modelos Fsicos: Descrevem como os dados so armazenados
representando informao como formato de registros, ordenao de
registros, mtodos de acesso.
Arquitetura de um SGBD
A arquitetura divide-se em trs nveis gerais:
Nvel Interno Mais prximo do armazenamento fsico, isto ,
relaciona-se com a forma como os dados so armazenados. Emprega-se o
Modelo de Dados Fsico para descrever detalhes de armazenamento.
Nvel Conceitual Descreve a estrutura completa de um BD para
uma comunidade de usurios. uma descrio global do BD, que esconde
detalhes da estrutura fsica de armazenamento. Pode-se empregar um
modelo de alto nvel (modelo conceitual) ou de implementao.
Nvel Externo Mais prximo dos usurios. formado por um conjunto
de vises de usurios ou esquemas externos. Cada viso descreve a parte
do BD que um grupo de usurios est interessado. Pode ser empregado um
modelo de alto nvel (modelo conceitual) ou de implementao
A maioria dos SGBDs no separa os 3 nveis completamente. Alguns
incluem detalhes de nvel fsico no nvel conceitual.

Introduo
Notar que os 3 esquemas so apenas descries de dados. Os dados

que realmente existem esto no nvel fsico.
Estamos agora prontos para delinearmos uma arquitetura para um
sistema de banco de dados.
Nosso propsito, ao apresentar esta
arquitetura, estabelecer a base sobre a qual possamos trabalhar nos
captulos subseqentes. Esta base extremamente til para descrevermos
os conceitos gerais do banco de dados e explicarmos a estrutura de sistemas
de banco de dados especficos - mas, certamente, no queremos afirmar
que todo o sistema se encaixa nesta estruturao, nem sugerir que esta
arquitetura, em particular, estabelece a nica base possvel. Os sistemas
"pequenos" (com base em micro), especialmente, no suportaro todos os
aspectos da arquitetura. Entretanto, parece que ela ajustase razoavelmente
bem maioria dos sistemas (relacionais ou outros); ademais, em termos
gerais, concorda com a proposio do "ANSI/SPARC Study Group on Data
Base Management Systems" [2.1-2.4]. Optamos, contudo, por no seguir a
terminologia ANSI/SPARC em todos os detalhes.
Os Trs Nveis da Arquitetura

A arquitetura divide-se em trs nveis gerais: interno, conceitual e
externo. Em termos amplos:
O nvel interno o mais prximo ao armazenamento fsico - i.e.

relaciona-se forma como so realmente armazenados os
dados;
O nvel externo o mais prximo aos usurios - i.e., forma
como os dados so vistos pelos usurios individuais;
O nvel conceitual o "nvel de simulao", entre os dois outros.
Se o nvel externo diz respeito s vises do usurio individual, o nvel

conceitual pode ser considerado a viso do grupo de usurios.
Em outras palavras, haver muitas "vises externas" distintas, cada
uma consistindo em uma representao mais ou menos abstrata de
determinada parte do banco de dados e haver precisamente uma "viso
conceitual", que corresponde representao abstrata do banco de dados
em sua totalidade.' (Lembremo-nos que a maioria dos usurios no estar
interessada em todo o banco de dados, mas somente numa parte restrita do
mesmo.) Da mesma forma, haver exatamente uma "viso interna",
representando todo o banco de dados como armazenado de fato.

Introduo
Nvel externo
(vises do usurio
individual)
viso 1
...
viso 2
viso n
Nvel conceitual
(viso do conjunto
de usurios)
Nvel
Conceitual
Nvel interno
(viso do
armazenamento)
Nvel Fsico
Os trs nveis da arquitetura.
Um exemplo tornar estas idias mais claras. A figura seguinte mostra

a viso conceitual de um simples banco de dados sobre funcionrios, a viso
interna correspondente e as duas vises externas correspondentes, uma
para um usurio de PL/1 e outra para o usurio de COBOL. O exemplo, na
certa, totalmente hipottico - no pretende simular qualquer sistema real e muitos detalhes irrelevantes foram deliberadamente omitidos. Veja os
esquemas abaixo:
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
PAY
TYPE = FULLWORD, OFFSET = 16
Exemplos dos trs nveis.
Interpretamos da seguinte maneira:
Banco de dados contm, no nvel conceitual, informaes

referentes ao tipo de entidade chamada EMPLOYEE. Cada
EMPLOYEE tem um EMPLOYEE-NUMBER (seis caracteres), um

Introduo
DEPARTMENT-NUMBER (quatro caracteres) e um SALARY (cinco

dgitos decimais).
Os funcionrios esto representados, no nvel interno, por um
tipo de registro armazenado chamado STORED-EMP, com
dezoito bytes de comprimento. O STORED-EMP contm quatro
tipos de campos armazenados: um prefixo de seis bytes
(contendo, provavelmente, informaes de controle como
sinalizadores ou ponteiros), e trs campos de dados
correspondendo s trs propriedades dos funcionrios' Os
registros STORED_FMP so, adicionalmente, indexados no
CAMPO EMP por um ndice chamado EMPX.
O usurio de PL/1 tem uma viso externa do banco de dados,
na qual cada funcionrio representado por um registro PL/I,
contendo dois campos (os nmeros de departamento no so
do interesse deste usurio, e por isto foram omitidos da viso).
O tipo de registro definido por uma declarao comum de
estrutura PL/I, de acordo com as regras normais de PL/I.
Do mesmo modo, o usurio de COBOL tem uma viso externa,
na qual cada funcionrio representado por um registro
COBOL, contendo, novamente, dois campos (desta vez foi
omitido o de salrio). O tipo de registro definido por um
registro comum COBOL, de acordo com as regras normais do
COBOL.
Observemos que objetos correspondentes podem ter nomes
diferentes em cada nvel. O nmero do funcionrio, por
exemplo, chamado de EMP# na viso da PL/I, e de EMPNO
na viso COBOL, como EMPLOYEE-NUMBER na viso conceitual
e como EMP # (novamente) na viso interna. O sistema
certamente deve estar a par das correspondncias. Deve ser
informado, por exemplo, que o campo COBOL EMPNO deriva
do objeto conceitual EMPLOYEE-NUMBER que, por sua vez,
representado no nvel interno pelo campo armazenado EMP#.
Tais concordncias, ou mapeamentos, no so mostradas no
esquema acima.
Observao: Em um sistema relacional o primeiro nvel, o nvel

conceitual, ser definitivamente relacional, no sentido de que os objetos
visveis neste nvel sero tabelas relacionais (os operadores tambm sero
operadores relacionais, i.e., operadores que trabalham com tais tabelas).
Uma determinada viso externa (segundo nvel, nvel externo) ser
igualmente relacional ou algo bem prximo; por exemplo, os registros PL/1 e
COBOL da Fig. 1.3 podem ser considerados, respectivamente, como as
representaes PL/I e COBOL de (uma linha dentro de) uma tabela
relacional. O terceiro nvel, o nvel interno, certamente no ser sempre
relacional, desde que os objetos desse nvel no sero exatamente tabelas
relacionais (armazenadas) - ao contrrio, sero a mesma espcie de objetos
encontrados no nvel interno de outros tipos de sistema (a saber, registros
armazenados, ponteiros, ndices, acessos hash etc.). De fato, a teoria

Introduo
10
relacional como tal no tem nada a dizer sobre o nvel interno (repetimos,
sobre como o banco de dados aparece para o usurio).
Examinaremos agora mais detalhadamente os trs nveis da
arquitetura, iniciando com o nvel externo. A figura abaixo, qual estaremos
nos referindo neste captulo, mostra os principais componentes da
arquitetura e seus inter-relacionamentos.
Nvel Externo
O nvel externo o nvel do usurio individual. Um determinado
usurio, como explicado no Captulo I, tanto pode ser um programador de
aplicaes como um usurio de terminal on-line - i.e., um usurio final - de
qualquer grau de sofisticao. O DBA um caso especial importante. (Ao
contrrio dos usurios comuns, o DBA ter de se interessar pelos nveis
conceitual e interno tambm. Vide as prximas duas sees.) Cada usurio
tem uma linguagem sua disposio:
Esta linguagem, para o programador de aplicao, pode ser

uma linguagem convencional de programao, como COBOL
ou PL/I, ou uma linguagem de programao apropriada,
especfica do sistema em questo (sistemas NOMAD, Rdv/VMS
ou dbase II).
Para o usurio final, pode ser uma linguagem de consulta ou

uma linguagem de propsitos especiais, talvez baseada em
formulrios ou menu, modelada s necessidades do usurio e
suportada por um programa de aplicao on-line.
Para nossos propsitos, o que importa sabermos que todas essas

linguagens incluiro uma sublinguagem de dados - ou seja, um subconjunto
de toda a linguagem, voltado para os objetivos e operaes do banco de
dados. A sublinguagem de dados (abreviada na Fig. 2.3 como DSL)
embutida na linguagem hospedeira correspondente, a qual proporciona os
diversos recursos no-especficos de banco de dados, tais como variveis
locais (temporrias), operaes computacionais, lgica if-then-else e assim
por diante. Um determinado sistema pode suportar mltiplas linguagens
hospedeiras e mltiplas sublinguagens de dados.
Observao: Embora seja conveniente diferenciar, na arquitetura, a
sublinguagem de dados e linguagem hospedeira, as duas, em
relao ao usurio, podem ser indistinguveis. Se assim for, ou
se s puderem ser separadas com dificuldades, dizemos que
so unidades de maneira firme. Se as linguagens so fceis
e claramente separadas, dizemos que so "unidas de maneira
indefinida". A maioria dos sistemas de hoje suporta apenas a
unio indefinida. Um sistema firmemente unido propiciar um
conjunto de recursos mais uniforme para o usurio, mas
obviamente requer maior esforo por parte dos projetistas do

Introduo
11
sistema (o que poderia explicar o que temos hoje). Entretanto,

parece haver um movimento que, gradualmente, nos levar a
dispor, nos prximos anos, de sistemas com unio mais firme.
Em princpio, qualquer sublinguagem de dados realmente uma
combinao de pelo menos duas linguagens subordinadas: a linguagem de
definio de dados (DDL), que possibilita a definio ou descrio dos
objetos do banco de dados, e a linguagem de manipulao de dados
(DML), que suporta a manipulao ou processamento desses objetos.
Consideremos o usurio de PL/1 da Fig. 2.2 de Seo 2.2. A sublinguagem de
dados para aquele usurio compe-se dos aspectos de PL/1 utilizados para
a comunicao com o DBMS. A parte DDL consiste nas construes
declarativas do PL/I necessrias para declarar os objetos do banco de
dados: a prpria instruo DECLARE (DCL), certos tipos de dados PL/I, e
possivelmente as extenses especiais para PL/I, para suportar novos objetos
que no so tratados pelo PL/1 existente. A parte DML compe-se das
instrues executveis do PL/I que transferem as informaes de e para o
banco de dados - podendo, novamente, incluir novas instrues especiais.
(Observao: Os PL/I atuais de fato no incluem aspectos especficos de
banco de dados. As instrues "DML", por isto, so apenas "CHAMADAS" para
o DBMS. Eis por que sistemas PL/I, como muitos sistemas atuais, s
proporcionam uma unio muito indefinida entre a sublinguagem de dados e
a hospedeira.)
Voltando arquitetura: J mencionamos que o usurio individual, por
via de regra, s vai interessar-se por determinada parte do banco de dados;
alm disso, a viso que o usurio ter daquela parcela , em geral, algo
abstrato, em comparao forma como os dados so fisicamente
armazenados. Em termos ANSI/SPARC, a viso de determina do usurio
uma viso externa. A viso externa , portanto, o contedo do banco de
dados como visto por determinado usurio (ou seja, para aquele usurio, a
viso externa o banco de dados). Um usurio d Departamento de
Pessoal, por exemplo, pode ver o banco de dados como uma coleo de
eventos de registros do departamento, e uma coleo de eventos de
registros de empregados (podendo estar totalmente desinformado das
ocorrncias de registros de fornecedores e peas vistas pelos usurios do
Departamento de Compras).
Portanto, uma viso externa consiste, em geral, em ocorrncias
mltiplas, de mltiplos tipos de registro externo'. Um registro externo no
necessariamente o mesmo que um registro armazenado. A sublinguagem
de dados do usurio definida em termos de registros externos; por
exemplo, uma operao de recuperao de registro da DML ir recuperar
um evento de registro externo, e no uma ocorrncia de registro
armazenado.
Cada viso externa definida por meio de um esquema externo, que
consiste, basicamente, em definies para cada um dos vrios tipos de
registro externo naquela viso externa. O esquema externo descrito

Introduo
12
usando-se a parte DDL da sublinguagem de dados do usurio. (Denominase, assim, a DDL, s vezes, de DDL externa.) O tipo de registro externo
funcionrio, por exemplo, pode ser definido como um campo de seis
caracteres, nmero do funcionrio, mais um campo de cinco dgitos
decimais, 'salrio', e assim por diante. Alm disso, deve haver uma definio
do mapeamento entre o esquema externo e o esquema conceitual
fundamental (descrito na prxima seo).
Voltamo-nos agora para o nvel conceitual.
Nvel Conceitual
A viso conceitual a representao de todo o contedo de
informaes do banco de dados, tambm (como a viso externa) um tanto
abstrato quando comparada forma como os dados so fisicamente
armazenados, que tambm pode ser bem diferente da maneira como os
dados so vistos por qualquer usurio em particular. A grosso modo,
podemos dizer que a viso conceitual a viso dos dados "como realmente
so", e no como os usurios so forados a v-los devido s restries (por
exemplo) da linguagem ou do hardware utilizados pelos mesmos.
A viso conceitual consiste em ocorrncias mltiplas de tipos mltiplos
de registros conceituais. A mesma pode consistir, por exemplo, em uma srie
de ocorrncias de registros de departamentos, mais um conjunto de
ocorrncias de registros de funcionrios, ou de fornecedores de peas ... De
um lado, um registro conceitual no necessariamente o mesmo do que um
registro externo e, de outro, nem o mesmo que um registro armazenado.
A viso conceitual definida pelo esquema conceitual que inclui
definies de todos os diversos tipos de registros conceituais. O esquema
conceitual escrito atravs de outra linguagem de definio de dados, a
DDL conceitual. Para que se possa alcanar a independncia de dados,
essas definies da DDL conceitual no podem conter quaisquer
consideraes sobre a estrutura de armazenamento ou a estratgia de
acesso - devem ser apenas definies das informaes. Assim, no pode
haver referncia ao esquema conceitual para as representaes do campo
armazenado, seqncia de registro armazenado, indexao, acesso hash,
ponteiros ou quaisquer outros detalhes de armazenamento/acesso. Se o
esquema conceitual for realmente independente de dados, ento os
esquemas externos, que so definidos em termos do esquema conceitual,
tambm sero necessariamente independentes de dados.
A viso conceitual, ento, a viso do contedo total do banco de
dados, e o esquema conceitual uma definio desta viso. Seria errado,
porm, dizer-se que o esquema conceitual no nada mais do que um
conjunto de definies parecidas com simples definies de registros como
encontrados, por exemplo, num programa COBOL.
As definies no
esquema conceitual devem incluir uma grande quantidade de aspectos,
como controles de segurana e de integridade. Algumas autoridades na

Introduo
13
matria ainda vo mais alm, e sugerem que o objetivo final do esquema

conceitual descrever toda a empresa - no somente os dados
operacionais, mas tambm como so usados: como transcorre o fluxo em
cada ponto da empresa, como usado em cada ponto, como se aplicam
auditoria ou outros controles em cada ponto, e assim por diante [2.5].
Enfatizamos, no entanto, que hoje em dia nenhum sistema realmente suporta
um nvel conceitual que se aproxime deste grau de abrangncia; na maioria
dos sistemas existentes, o esquema conceitual realmente pouco mais
que uma simples unio de todos os esquemas externos e individuais, com a
provvel adio de alguns controles de segurana e integridade. Mas tudo
indica que os sistemas, no futuro, sero eventualmente mais sofisticados
quanto ao suporte do nvel conceitual.
Nvel Interno
O terceiro nvel da arquitetura o nvel interno. A viso interna uma
pequena representao de todo o banco de dados; consiste em
ocorrncias mltiplas de tipos mltiplos de registros internos. O "registro
interno" termo ANSI/SPARC para a estrutura que temos denominado de
registro armazenado (termo que continuaremos a empregar). A viso
interna um tanto distante do nvel fsico, uma vez que no trabalha em
termos de registros fsicos (tambm chamados pginas ou blocos), nem de
consideraes de dispositivos especficos tais como cilindro ou comprimento
de trilha. (A viso interna assume basicamente um espao de
endereamento linear e infinito. Os detalhes de como este espao de
endereamento mapeado at o armazenamento fsico so altamente
especficos a cada sistema, e deliberadamente omitidos de arquitetura).
A viso interna descrita por meio do esquema interno, que no s
define os vrios tipos de registros armazenados como tambm especifica os
ndices que existem, como os campos armazenados so representados, a
seqncia fsica dos registros armazenados, e assim por diante. O esquema
interno preparado atravs de uma outra linguagem de definio de dados
- a DDL interna.
Observao: Nesse livro, usaremos normalmente o termo "banco de dados
armazenado" em vez de viso interna, e o termo definio
de estrutura de armazenamento em vez de esquema
interno.
Observamos, parte, que, em certas situaes excepcionais, os
programas de aplicao - em particular, as aplicaes de natureza
"utilitria" - podem operar diretamente no nvel interno, ao invs do nvel
externo. No necessrio dizer que esta prtica no recomendvel;
representa um risco de segurana (posto que o controle de segurana no
observado) e um risco de integridade (uma vez que os controles de
integridade tambm no so observados), e o programa, alm disso, tornase dependente de dados, em algumas ocasies, porm esta poder ser a
nica forma de se obter a funo ou a performance necessria - assim

Introduo
14
como o usurio de uma linguagem de programao de alto nvel pode,

ocasionalmente, precisar utilizar a linguagem de montagem (assembler)
para satisfazer certos objetivos funcionais ou de desempenho.
Mapeamentos
O leitor poder observar dois nveis de mapeamento na arquitetura,
um entre os nveis externo e conceitual do sistema e um entre os nveis
conceitual e interno.
O mapeamento conceitual interno define a
correspondncia entre a viso conceitual e o banco de dados armazenado;
especifica como os registros e campos conceituais so representados no
nvel interno. Se a estrutura do banco de dados armazenado for modificada
- i.e., se for executada uma mudana na definio da estrutura armazenada
-, o mapeamento conceitual/interno tambm dever ser modificado de
acordo, de forma que o esquema conceitual permanea invarivel. (O
controle destas mudanas da responsabilidade do DBA.) Em outras
palavras, os efeitos dessas modificaes devem ser isolados abaixo do nvel
conceitual, de maneira a preservar a independncia de dados.
Um mapeamento externo conceitual define a correspondncia entre
uma determinada viso externa e a viso conceitual. As diferenas que
podem existir entre estes dois nveis so similares quelas que podem existir
entre a viso conceitual e o banco de dados armazenado. Como exemplo,
os campos podem ter tipos de dados diferentes, as denominaes de
campo e registro podem ser modificadas, campos conceituais mltiplos
podem ser combinados num nico campo externo (virtual) etc. Pode haver
qualquer nmero de vises externas ao mesmo tempo; qualquer quantidade
de usurios pode compartilhar de uma determinada viso externa;
diferentes vises externas podem sobrepor-se. Alguns sistemas possibilitam
que a definio de uma viso externa seja expressa em termos de outra (de
fato, via mapeamento externo/externo), ao invs de exigirem sempre uma
definio explcita do mapeamento a nvel conceitual - um aspecto muito
til, quando diversas vises externas se relacionam entre si.
Linguagens de SGBDs
A linguagem de SGBD's essencialmente SQL, que por sua vez
subdividido em grupos de comandos, de acordo com a funo de cada
comando. Infelizmente, estas subdivises no so utilizadas por todas as
implementaes de SGBD's. Elas so enfatizadas pela ANSI (American
National Standards Institute), mas muitos produtos SQL no as tratam
separadamente na prtica.
A Linguagem de Definio de Dados (ou DDL - Data Definition
Language, ou tambm chamado pela ANSI como Linguagem de Definio
de Esquema) consiste nos comandos que criam os objetos (tabelas, ndices,

Introduo
15
vises, e assim por diante) no banco de dados. Linguagem de Manipulao

de Dados (DML - Data Manipulation Language) um conjunto de comandos
que determinam quais valores esto presentes nas tabelas em qualquer
momento. A Linguagem de Controle de Dados (DCL - Data Control
Language) consiste nas caractersticas que determinam se a um usurio
permitido executar uma ao particular. Isto considerado parte da DDL
pela ANSI. Elas (DDL, DML e DCL) no so linguagens diferentes por si s, mas
divises de comandos SQL em grupos de acordo com suas funes.
Ento, resumindo,
DDL = Data Definition Language - Linguagem de definio de
dados, possibilita a definio ou descrio dos objetos
do BD.
DML
= Data Manipulation Language - Linguagem de

manipulao de dados, que suporta manipulao
(acesso e alterao).
DCL = Data Control Language - Linguagem de controle de

dados, possibilita a determinao das permisses que
cada usurio ter sobre os objetos do BD (permisso de
criao, consulta, alterao, etc.).
No SQL, por exemplo, so instrues DML:
SELECT - consulta (seleo)
UPDATE - atualizao
DELETE - excluso
INSERT - incluso
DMLs podem ser:
procedurais - o usurio 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 LPGs)
no procedurais - so capazes de expressar operaes
complexas de maneira concisa. O usurio especifica apenas o
que deseja, e permite que o sistema decida como obter isso.
(pode ser embutida em uma LPG de propsito geral)

Introduo
16
Independncia de Dados
O Banco de Dados pode ser visto sob trs nveis de abstrao:
Nvel Fsico nvel mais baixo de abstrao, descreve como os

dados esto realmente armazenados. Complexas estruturas de
dados de baixo nvel so descritas em detalhes.
Nvel Conceitual descreve quais dados esto armazenados
de fato no BD e as relaes que existem entre eles. Aqui o BD
inteiro descrito em termos de um pequeno nmero de
estruturas relativamente simples.
Nvel Visual o mais alto nvel de abstrao descreve apenas
parte do BD. Apesar do uso de estruturas mais simples do que
no nvel conceitual, alguma complexidade perdura devido ao
grande tamanho do BD.
A habilidade de modificar a definio de um esquema em um nvel

sem afetar a definio de esquema num nvel mais alto chamada de
independncia de dados. Existem dois nveis de independncia de dados:
Independncia fsica de dados a habilidade de modificar o

esquema fsico sem a necessidade de rescrever os programas
aplicativos. As modificaes no nvel fsico so ocasionalmente
necessrias para aprimorar o desempenho.
Independncia lgica de dados a habilidade de modificar o
esquema conceitual sem a necessidade de rescrever os
programas aplicativos. As modificaes no nvel conceitual so
necessrias quando a estrutura lgica do BD alterada.
Administrador de Banco de Dados

Uma das principais razes para empregar um SGBD ter um controle
central dos dados e dos programas de acesso a eles. A pessoa que tem esse
controle sobre o sistema chamada administrador do banco de dados
(DBA). O administrador do banco de dados (DBA) a pessoa (ou grupo de
pessoas) responsvel pelo controle do sistema. As responsabilidades do DBA
incluem o seguinte:
Decidir o contedo de informaes do banco de dados
Faz parte do trabalho do DBA decidir exatamente que
informao manter no banco de dados - em outras palavras,
deve identificar as entidades do interesse da empresa e a
informao a registrar em relao a estas entidades.' Uma vez
feito isto, o DBA deve ento definir o contedo do banco de
dados, descrevendo o esquema conceitual (usando o DDL
conceitual). A forma objeto (compilado) daquele esquema

Introduo
17
utilizada pelo DBMS para responder s solicitaes de acesso. A

forma (no compilada) atua como documento de referncia
para os usurios do sistema.
Decidir a estrutura de armazenamento e a estratgia de acesso
O DBA tambm deve decidir como os dados sero representados
no banco de dados', e definir esta representao escrevendo a
definio da estrutura de armazenamento (usando a DDL
interna). Alm disso, deve definir o mapeamento associado entre
os nveis interno e conceitual. Na prtica, tanto a DDL conceitual
quanto a DDL interna - mais provavelmente a primeira provavelmente incluiro os meios de definio desse
mapeamento, mas as duas funes (a definio do esquema, a
definio do mapeamento) devem ser claramente separadas.
Tal como o esquema conceitual, o esquema interno e o
mapeamento correspondente existiro no s na forma fonte
como na forma objeto.
Servir de elo de ligao com usurios
funo do DBA servir de elo de ligao com os usurios, a fim
de
garantir a disponibilidade dos dados de que estes
necessitam, e preparar - ou auxili-los na preparao dos
necessrios esquemas externos, utilizando a DDL externa
apropriada (como j mencionamos, um determinado sistema
pode suportar diversas DDLs externas e distintas). E, ainda,
tambm deve ser definido o mapeamento entre qualquer
esquema externo e o esquema conceitual. Na prtica, a DDL
externa provavelmente incluir os meios de especificao do
mapeamento, mas o esquema e o mapeamento devem ser
claramente separados.
Cada esquema externo e o
mapeamento correspondente existiro tanto na forma fonte
como na forma objeto.
Definir os controles de segurana e integridade
Os controles de segurana e de integridade, como j
mencionado, podem ser considerados parte do esquema
conceitual.
A DDL conceitual incluir os recursos para a
especificao de tais controles. a Definir a estratgia de reserva e
recuperao. A partir do momento em que a empresa comea
efetivamente a basear-se em banco de dados, torna-se
dependente do bom funcionamento deste sistema.
Na
eventualidade de danos parte do banco de dados - causados,
digamos, por erro humano, ou por falha no hardware, ou no
sistema operacional de suporte -, de suma importncia fazer
retornar os dados envolvidos com um mnimo de demora e com
as menores conseqncias ao restante do sistema. Por exemplo,
os dados que no sofreram danos no devero ser afetados.' O
DBA deve definir e implementar uma estratgia de recuperao
apropriada envolvendo, por exemplo, o descarregamento

Introduo
18
peridico do banco de dados na memria auxiliar de

armazenamento e procedimentos para recarreg-lo, quando
necessrio.
Monitorar o desempenho e atender as necessidades de modificaes
O DBA deve organizar o sistema de tal maneira que obtenha o
melhor desempenho para a empresa; e efetuar os ajustes
adequados quanto s necessidades de modificaes. Como j
mencionamos,
quaisquer
mudanas
nos
detalhes
de
armazenamento e acesso devem ser acompanhadas de
mudanas correspondentes na definio do mapeamento, a
partir do nvel conceitual, de forma que o esquema conceitual
possa permanecer constante. O DBA precisa de diversos
programas utilitrios que o auxiliem nas tarefas de administrao
do BD. Estes so uma parte essencial de um sistema de banco de
dados prtico, embora no sejam mostrados na Fig. 1.3 da
arquitetura. Abaixo esto alguns exemplos dos programas
utilitrios necessrios.
Rotinas de Carga
Para criar uma verso inicial do banco de dados a partir de um
ou mais arquivos.
Rotinas de Despejo na Memria e Recuperao
Despejar o banco de dados, auxiliar de armazenamento de
dados, e recarregar o banco de dados a partir dessa cpia de
segurana. Observao: As rotinas de carga mencionadas
acima consistiro, na prtica, no aspecto de "recuperao" das
rotinas de despejo/recuperao na memria.
Rotinas de Reorganizao
Para rearrumar os dados no banco de dados, em vista de
diversas razes de desempenho - por exemplo, agrupar os dados
de certa maneira ou regenerar espao ocupado por dados que
se tornaram obsoletos.
Rotinas Estatsticas
Para computar diversos desempenhos estatsticos, tamanhos de
arquivos e distribuio de valores de dados.
Rotinas Analticas
Para analisar as estatsticas mencionadas. Uma das ferramentas
mais importantes do DBA - de muitas maneiras e, de fato, o
corao de todo o sistema - o dicionrio de dados (conhecido
tambm como catlogo do sistema). O dicionrio de dados
pode ser considerado um banco de dados, um banco de dados
de sistema. O contedo do dicionrio pode ser considerado
"dados sobre dados" (s vezes denominado metadados) - ou

Introduo
19
seja, descries de outros objetos no sistema, ao invs de simples

"dados em bruto".
Exerccios
1) Quais so os principais componentes dos sistemas de BD?
Explique sucintamente a funcionalidade de cada uma.
2) Defina os termos:
3) Banco de Dados
4) Sistemas de Gerncia de Bancos de Dados
5) Sistemas de Banco de Dados
6) Cite e explique algumas vantagens do uso de BD.
7) O que Integridade Referencial e Transacional?
8) O que Independncia de Dados?
9) Descreva a arquitetura de SBD de 3 nveis.
10) Quais so os tipos de linguagens de SGBD? Para que serve
cada uma?
11) Qual a diferena entre Independncia Fsica e Lgica?
12) Cite e explique algumas responsabilidades do DBA.

Modelos de Dados
21
MODELOS DE DADOS (MODELOS CONCEITUAIS E

LGICOS)
Uma Coleo de ferramentas conceituais para descrio de dados,
relacionamentos de dados, semntica de dados e restries de consistncia.
Classificao de Modelos de Dados

Os vrios modelos de dados propostos atualmente, e encontrados na
literatura, podem ser divididos em trs (3) grandes grupos: modelos lgicos
baseados em objetos (= Modelos Conceituais), modelos lgicos baseados
em registros (= Modelos Lgicos ou Modelos de Implementao) e, modelos
fsicos de dados.
Modelos Lgicos Baseados Em Objetos - Modelos Conceituais

So usados na descrio de dados nos nveis conceitual e visual.
Caracterizam-se pelo fato de fornecerem, de forma conveniente,
capacidade de estruturao flexvel e admitem restries de dados para
serem explicitamente especificados. Os mais conhecidos so:
Modelo Entidade-Relacionamento (MER);
Modelo Orientado a Objetos
O Modelo ER tem ganhado aceitao no projeto de BD e bastante
utilizado na prtica.
O Modelo OO inclui muito dos conceitos no modelo ER, mas
representa cdigos executveis assim como dados.
Modelos Lgicos Baseados Em Registro - Modelos Lgicos Ou De

Implementao
So usados na descrio de dados nos nveis conceitual e visual. Em
comparao aos modelos de dados baseados em objetos, ambos so
usados para especificar a estrutura lgica geral do banco de dados e para
fornecer uma descrio de alto nvel da implementao.

Modelos de Dados
22
So assim chamados porque o BD estruturado em registros de

formato fixo de diversos tipos. Cada tipo de registro define um nmero fixo
de campos (atributos), e cada campo usualmente de um tamanho fixo.
Desde o final dos anos 60, vrios SGBDs comerciais foram
construdos........
Os trs modelos mais aceitos so:
Modelo Relacional;
Modelo Rede;
Modelo Hierrquico.
Modelo Relacional
O Modelo Relacional representa dados e relacionamentos entre
dados por um conjunto de tabelas, cada uma tendo um nmero de colunas
com nomes nicos. Veremos o Modelo Relacional com mais detalhes mais
adiante.
nome
Ana
Joo
Joo
Carlos
Carlos
rua
Arvoredo
Norte
Norte
Alameda
Alameda
cidade
Porto Alegre
So Paulo
So Paulo
Florianpolis
Florianpolis
nmero
900
556
647
801
saldo
55
100.000
105.366
10533
nmero
900
556
647
801
647
Modelo Rede
Os dados no Modelo Rede, tambm conhecido como Modelo
CODASYL ou DBTG, so representados por colees de registros (como no
Pascal ou PL/I), e os relacionamentos entre os dados so representados por
elos, que podem ser vistos como ponteiros. Os registros no BD so
organizados como colees de grficos arbitrrios.
Um banco de dados rede consiste em uma coleo de registros que
so conectados uns aos outros por meio de ligaes. Um registro em
muitos aspectos similar a uma entidade no modelo ER. Cada registro uma
coleo de campos (atributos), cada um dos quais contendo apenas um

Modelos de Dados
23
valor de dado. Uma ligao uma associao entre precisamente dois

registros. Assim, uma ligao pode ser vista como uma forma restrita (binria)
de relacionamento no modelo ER.
Existem dois conceitos bsicos de estruturas:
registro (record type), onde cada registro descreve a

estrutura de um grupo de registros que armazenaram o mesmo
tipo de informao;
ligao pai-filho (set type), onde cada ligao pai-filho um
relacionamento um-para-muitos (1:n) entre dois record types.
Cada registro representa alguma informao do mundo real sobre um grupo

de itens, chamados itens de dados (ou atributos).
A figura abaixo mostra record types ESTUDANTE e CURSO, e um set

type SE_MATRICULA entre eles, com ESTUDANTE como o registro-pai e
CURSO como registro-filho. A representao diagramtica mostra o uso de
uma seta do registro pai para o registro filho, chamada de DIAGRAMA DE
BACHMAN, pois foi Charles Bachman que primeiro introduziu isto.
O conjunto de ocorrncias inclui o registro-pai JOO e trs registrosfilhos correspondendo aos trs cursos nos quais ele se matriculou. Um banco
de dados pode conter muitas ocorrncias da ligao pai-filho
SE_MATRICULA, um por estudante. Note que se um estudante no
associado em qualquer curso, a ocorrncia do registro ESTUDANTE ainda
define um conjunto de ocorrncias na qual existe um registro-pai e zero
registros-filhos. A figura mostra os itens de dados contidos nos registros acima
mencionados.
Sistemas de banco de dados rede permitem vetores, que so itens de
dados que podem ter valores mltiplos dentro de um registro. Isto
corresponde a um atributo multivalorado no modelo ER.
Ana
Joo
Carlos
Arvoredo
Norte
Alameda
Porto Alegre
900
55
556
100.000
647
105.366
801
10.533
So Paulo
Florianpolis
Exemplo de esquema de BD em rede BATINI, 1992

Modelos de Dados
24
Modelo Hierrquico
O primeiro SGBD comercialmente disponvel e que se tornou popular
era hierrquico, o BD da IBM, conhecido como IMS (Information
Management System), que esteve no seu auge na dcada de 70. Como
resultado, hoje existe uma grande base de dados que ainda utilizam a
abordagem hierrquica.
O modelo hierrquico possui dois conceitos bsicos de estruturas:
Registro (record types), que definido como um grupo de

registros que armazenam informaes de um mesmo tipo (no
IMS, chamado de segmento);
Relacionamento pai-filho (parent-child relationship types),
tambm chamado PCR type , um relacionamento umpara-muitos entre um segmento-pai e um segmento-filho.
Um segmento (record type) possui muitas ocorrncias, chamados

registros. Uma ocorrncia de um PCR consiste de um registro do segmentopai e muitos (zero ou mais) ocorrncias de um segmento-filho.
Um esquema de um BD hierrquico possui um nmero de hierarquias,
onde cada hierarquia (esquema hierrquico) consiste de um nmero de
segmentos e PCRs arranjados de maneira que forma uma rvore. A figura
2.4 mostra um esquema hierrquico com 2 segmentos e 1 PCR. Os PCRs so
referidos como o par (segmento-pai, segmento-filho). Um registro pode
somente possuir um segmento-pai. A figura mostra um possvel estado de um
BD IMS.
Ana
Arvoredo
Porto Alegre
Joo
556
900
55
Carlos
Norte
100.000
Alameda
Florianpolis
So Paulo
647
105.366
647
105.366
Esquema de um BD hierrquico Heuser, 1995
801
10.533

Modelos de Dados
25
Modelos Fsicos de Dados

So usados para descrever dados no nvel mais baixo. Existem poucos
modelo fsicos em uso. Dois dos mais conhecidos:
Modelo Unificador;
Estrutura de Memria.
Modelos Fsicos de dados capturam aspectos da implementao de

sistemas de BD.
Classificao de SGBDs
Quanto ao modelo de dados (principal critrio):
Relacional representa o BD como coleo de tabelas;

Hierrquico representa o BD um conjunto de rvores;
Rede representa o BD como um grafo;
Outros OO, relacional extendido, semntico,...
Quanto ao nmero de usurios:
mono-usurio;
multi-usurio.
Quanto distribuio dos dados e software:
centralizado;
distribudo.
Quando o SGBD distribudo e multi-usurio, cada usurio percebe o

BD como se ele fosse mono-usurio e centralizado (conceito de
transparncia em Sistemas Distribudos).
Exerccios
1) Defina Modelo de Dados.
2) Como so classificados os Modelos de Dados?
ASPECTOS BSICOS DE BANCO DE DADOS 27

Modelo Relacional
Modelo Relacional
Durante o perodo problemtico dos modelos hierrquico e rede,
Edward F. Codd (1970) props o MODELO RELACIONAL. A partir da, diversas
implementaes de Bancos de Dados Relacionais (RDBS - SGBDR)
comearam a aparecer.
Os Bancos de Dados Relacionais possuem diversas caractersticas
importantes que resolvem muitos dos problemas dos outros modelos
(hierrquico e rede). Ao contrrio de seus antecessores, o Modelo Relacional
no se baseia num paradigma de estruturao de dados particular, e sim
em um fundamento matemtico especfico.
A viso de Banco de Dados mudou para um nvel mais alto,
concentrando seus princpios no modelo de negcios e no na
implementao de estruturas complexas.
O Modelo Relacional representa o BD como uma coleo de
relaes. Informalmente, uma relao uma tabela ou arquivo simples.
..............
.........................
.........
..............
.........................
.........
London
Domniosos
Paris
Relao
Tupla
COD
001
002
003
NOME
Smith
Jones
Adams
CIDADE
London
Paris
Paris
Atributos
Chave
Primria
Domnio
A noo de domnio de um item de dado assemelha-se noo de
domnio de um conjunto na matemtica. Um Domnio D um conjunto de
valores atmicos (indivisveis). o universo de valores permitido para um
dado conjunto. Para tanto, necessrio o uso da DDL e da DCL do SGBD.
Ainda, a definio de um domnio acarreta em certas operaes e
comparaes de valor vlidas para um item de dado.
Domnios podem ser simples, ou seja, possuem um nico valor, como
um inteiro, ou compostos, quando possuem vrios valores, como uma data,
que apresenta dia, ms e ano. Os valores dos itens de dados que

Modelo Relacional
28
apresentam domnios compostos so abstrados e tratados como um nico

valor. Uma data poderia ser manipulada como uma string, por exemplo.
O Domnio especifica o tipo do atributo:
inteiros
reais
conjunto de cidades
etc.
Atributo
Um Atributo representa o uso de um Domnio dentro de uma Relao.
Vrios Atributos podem pertencer a um mesmo Domnio.
Matematicamente, um atributo o nome de um conjunto. Em uma
tabela, representa uma coluna. Um atributo pode apresentar um valor
condizente com o domnio associado a ele ou null. Null indica ausncia de
valor ou valor desconhecido.
Relao
Uma Relao dos Domnios D1, D2, ..., Dn compe-se de:
um conjunto fixo de atributos (esquema da relao) A1, A2, ...,

An, de forma que cada atributo Ai ( i = 1, 2, ..., n) corresponda
exatamente a um dos domnios bsicos Di (colunas da tabela).
um conjunto de tuplas (linhas da tabela)
Uma relao vista como uma tabela no modelo relacional,

composta por um cabealho e um corpo. O cabealho formado por um
conjunto fixo de atributos que possuem nomes distintos, para evitar
ambigidade na localizao de um item de dado.
Uma Relao possui uma Cardinalidade (= nmero de tuplas, = linhas)
e um Grau (= nmero de atributos, = colunas).
O conceito de relao ligeiramente diferente do conceito de
tabela. Relao equivale noo de conjunto, ou seja, um agrupamento
de elementos sem repetio. Tabela equivale a noo de coleo, ou seja,
um agrupamento de elementos onde permitida a repetio. SGBD's lidam,
na prtica, com o conceito de tabela.
Uma relao r do esquema R(A1, A2, ..., An) um conjunto de tuplas
r={t1, t2, ..., tn}, cada tupla uma lista de n valores t=<v1, v2, ..., vn> onde
cada valor vi ( i = 1, 2, ..., n) um elemento do domnio dom(Ai) ou um valor
nulo especial.

Modelo Relacional
29
Ex.: ESTUDANTE
Matrcula
01
-----...
------
Nome
N1
-----...
------
Endereo
E1
Null
...
------
t1
t2
...
tn
t1 = <01, N1, E1>

01 dom (matrcula)
N1 dom (nome)
E1 dom (endereo)
Chaves
O conceito de chaves fundamental, pois permitem a identificao
de tuplas em uma tabela, e permitem o estabelecimento de
relacionamentos entre tabelas.
Tipos de Chaves:
Ex.:
Chave Primria Atributo ou combinao de atributos que

permite a identificao nica de uma tupla em uma relao.
uma ou mais colunas cujos valores distinguem uma linha das
demais dentro de uma tabela. Uma chave primria no tem
nenhuma ligao com a ordenao e com o acesso tabela,
pois, segundo CODD, declarar um atributo como chave
primria e acessar a tabela por outro atributo, serve para
manter duas restries de integridade (vamos ver este conceito
mais adiante).
Chave Candidata Em uma tabela, podemos identificar
vrias alternativas de identificador nico, ou seja, vrios
atributos ou combinaes de atributos que permitem a
identificao nica de uma tupla em uma relao. Estas
chaves seriam vrias chaves candidatas a serem chave
primria. Toda chave primria uma chave candidata, porm
nem toda chave candidata chave primria.
Chave Alternativa Do conjunto de chaves candidatas
escolhemos somente uma para ser chave primria, as outras
so chamadas de chaves alternativas.
Chave Estrangeira Atributo ou combinao de atributos de
uma relao que so chaves primrias de outra relao. uma
coluna ou combinao de colunas, cujos valores aparecem
necessariamente na chave primria de uma tabela. A chave
estrangeira o mecanismo que permite a implementao de
relacionamentos em um BD Relacional.
FUNCIONRIO (COD#, FNOME, DEPT#, SALARIO)
DEPARTAMENTO (DEPTNUM, DEPTNOME)

Modelo Relacional
30
ndices
Permitem a otimizao da recuperao de tuplas em uma tabela, via
um mtodo de acesso. um recurso fsico, cujo principal objetivo est
relacionado com a performance do sistema. Cada estrutura de ndice est
associada a uma chave de pesquisa particular.
Uma chave pode ser utilizada como ndice, porm um ndice no
necessariamente uma chave. Existem vrios tipos de ndice (que dependem
do ambiente relacional que estamos trabalhando):
ndices Primrios se um arquivo for organizado

seqencialmente, isto , um arquivo seqencial, o ndice que
possui uma chave de pesquisa que especifica esta ordem
seqencial, chamado de ndice primrio. A chave de
pesquisa de um ndice primrio geralmente a chave primria.
Os arquivos que so organizados em ordem seqencial e
possuem um ndice primrio, so chamados de arquivos
seqenciais-indexados.
ndices Secundrios so os outros ndices que possuem uma
chave de pesquisa, e esta chave de pesquisa no especifica a
ordem seqencial do arquivo.
Dicionrio de Dados
A estrutura de um banco de dados relacional armazenada em um
dicionrio de dados ou catlogo do sistema. O dicionrio de dados
composto de um conjunto de relaes, idnticas em propriedades s
relaes utilizadas para armazenar dados. Elas podem ser consultadas com
as mesmas ferramentas utilizadas para consultar relaes de tratamento de
dados. Nenhum usurio pode modificar as tabelas de dicionrio de dados
diretamente. Entretanto, os comandos da linguagem de manipulao de
dados que criam e destroem os elementos estruturais do banco de dados
trabalham para modificar as linhas em tabelas de dicionrios de dados.
Em geral, voc encontrar os seguintes tipos de informaes em um
dicionrio de dados:
Definio de colunas que compe cada tabela;
Restrio de integridade imposta sobre relaes;
As informaes de segurana (qual o usurio tem o direito de

realizar o qual operao sobre qual tabela);
Definies de outros elementos estruturais de um banco de

dados, como visualizaes e domnios definidos pelo usurio;

Modelo Relacional
31
Quando um usurio e tentar acessar dados de qualquer maneira, um

SGBD relacional primeiro dirige-se ao dicionrio de dados para determinar se
os elementos do banco de dados que o usurio solicitou fazem realmente
parte do esquema. Alm disso, o SGBD verifica se o usurio tem os direitos de
acesso quilo que ele est solicitando.
Quando um usurio tenta modificar dados, o SGBD tambm vai para
o dicionrio de dados afins de procurar restries de integridade que podem
ter sido colocadas na relao. Se os dados atendem s restries, a
modificao permitida. Caso contrrio, o SGBD retorna uma mensagem
de erro e no faz a alterao.
Como todo acesso ao banco de dados relacional feita atravs do
dicionrio de dados, dizemos que os SGBD's relacionais so baseados em um
dicionrio de dados.
Tabelas de Exemplo do Dicionrio de Dados

As tabelas precisas que compe um dicionrio de dados dependem
um pouco do SGBD. Nesta seo, voc ver um exemplo de uma maneira
tpica em que um SGBD especfico (SYBASE SQL ANYWHERE) organiza seu
dicionrio de dados.
O fecho do dicionrio de dados realmente uma tabela que
documenta todas as tabelas do dicionrio de dados. A partir dos nomes das
tabelas do dicionrio de dados, voc provavelmente pode adivinhar que h
tabelas para armazenar dados sobre tabelas bsicas, suas colunas, seus
ndices e suas chaves estrangeiras.
creator
tname
dbspace
tabletype
ncols
Primary key
SYS
SYSTABLE
SYSTEM
TABLE
12
SYS
SYSCOLUMN
SYSTEM
TABLE
14
SYS
SYSINDEX
SYSTEM
TABLE
SYS
SYSIXCOL
SYSTEM
TABLE
SYS
SYSFOREIGNKEY
SYSTEM
TABLE
SYS
SYSFKCOL
SYSTEM
TABLE
SYS
SYSFILE
SYSTEM
TABLE
SYS
SYSDOMAIN
SYSTEM
TABLE
SYS
SYSUSERPERM
SYSTEM
TABLE
10
SYS
SYSTABLEPERM
SYSTEM
TABLE
11
SYS
SYSCOLPERM
SYSTEM
TABLE

Modelo Relacional
32
A tabela syscatalog descreve as colunas em cada tabela (incluindo

as tabelas do dicionrio de banco de dados). Na figura anterior, voc pode
ver uma parte de uma tabela syscolumns que descreve a tabela de itens de
vendas da Lasers Only.
creator
cname
tname
coltype
nulls
lenth
InPrymaryKey
colno
DBA
item_numb
itens
integer
DBA
title
itens
varchar
60
DBA
distributor-numb
itens
integer
DBA
release_date
itens
date
DBA
retail_price
itens
numeric
Lembre-se sempre de que essas tabelas de dicionrio de dados tm a

mesma estrutura e deve obedecer s mesmas regras que as tabelas bsicas.
Elas devem ter chave primria nica no-nula e tambm devem por
integridade referencial entre elas prprias.
Regras de Integridade Relacional
Integridade da Entidade
Integridade Referencial
As duas regras referem-se s chaves primrias e s chaves

estrangeiras.
Regra de Integridade da Entidade:
Nenhum atributo de uma chave primria pode ter valor nulo.
Regra de Integridade Referencial:
Todas as chaves estrangeiras presentes em uma relao s podem ter
valor igual a algum valor na relao onde ela chave primria.
Por exemplo, vamos supor o seguinte Diagrama ER:
CLIENTE
(1,n)
DEPSITO
(1,n)
AGNCIA
ATIVOS
CIDADECLI
RUA
CONTANUM
SALDO
NOMECLI
Este diagrama geraria as seguintes tabelas:
CIDADEAG
NOMEAG

Modelo Relacional
NOMECLI
JOO
CARLOS
SILVA
RUA
XYZ
XXX
XXX
CIDADECLI
WWWWW
WWWWW
WWWWW
33
NOMEAG
DOWN
MIANUS
MIANUS
CLIENTE
NOMEAG
DOWN
REDWOOD
MIANUS
CIDADEAG
YYYYYY
ZZZZZZZZ
WWWWW
ATIVOS
1000000
5000000
8000000
AGNCIA
NOMECLI
JOAO
JOAO
CARLOS
SILVA
NOMEAG
DOWN
REDWOOD
MIANUS
MIANUS
CONTANUM
155123
134556
111111
548123
SALDO
2000120,00
255613,00
125842,00
456982,00
DEPSITO
Implicaes das Regras
1) O SGBD deve rejeitar uma operao que torne o BD no

ntegro, ou;
2) O SGBD deve aceitar a operao, mas realizar outras
operaes compensatrias (se necessrio).
Especificao de Banco de Dados Relacional

A especificao de uma base de dados relacional (chamada de
esquema da base de dados) deve conter no mnimo a definio do
seguinte:
Tabelas que formam a base de dados

Colunas que as tabelas possuem
Restries de integridade
Abaixo mostrado o esquema correspondente s tabelas:

Modelo Relacional
CODEMP
......
......
NOME
......
......
CODDEP
......
......
34
CATEGFUNC
......
......
EMP (CODEMP, NOME, CODDEP, CATEGFUNC)

CODDEP referencia DEPT
CODDEP
......
......
NOME
......
......
DEP (CODDEP, NOME)

Nesta notao, so listadas as tabelas e, para cada tabela,
enumerados, entre parnteses, os nomes das colunas que compe a tabela.
As colunas que compe a chave primria aparecem sublinhadas. Aps a
definio da tabela aparecem as definies das chaves estrangeiras que
aparecem na tabela na forma:
<nome de coluna ch. Estrangeira> referencia <nome de tabela>
Ou, quando tratar-se de uma chave estrangeira composta por
mltiplas colunas:
(<nome de coluna>1, <nome de coluna>2, ....) referencia <nome de tabela>
As 12 Regras de Codd
Em outubro de 1985, E. F. Codd publicou uma srie de dois artigos no
semanrio da indstria de computao chamado COMPUTER WORLD. O
primeiro artigo delimitava 12 critrios a que um banco de dados relacional
deve obedecer integralmente. O segundo artigo comparava os atuais
produtos para mainframes com esses 12 critrios, produzindo uma srie de
controvrsias sobre se os SGBD's devem ser teoricamente rigorosos ou se eles
simplesmente devem trabalhar eficientemente.
Raros so os Bancos de Dados que se enquadrem em mais do que 10
destas regras.
As regras de Codd so:
Regra 1: as regras para informaes

Modelo Relacional
35
"Toda as informaes em um banco de dados

relacional so representadas explicitamente no nvel
lgico e exatamente de uma maneira - por valores em
tabelas.
O primeiro critrio para bancos de dados Relacionais lida com a
estrutura de dados que so utilizadas para armazenar dados e representar
relacionamentos de dados. O objetivo dessa regra fazer com que as
relaes (e tabelas de dimensionar esse) sejam as nicas estruturas de dados
utilizadas em um banco de dados relacional. Portanto, produtos que
requerem links codificados diretamente entre tabelas no so relacionais. A
linha Independentemente de da sua posio com relao a esse
argumento em particular h duas razes importantes por que uma boa
idia criar um banco de dados e com nada alm de tabelas.
Relacionamentos lgicos so muito flexveis. Em uma rede

simples ou em um banco de dados hierrquico, os nicos
relacionamentos que podem ser utilizados na recuperao so
aqueles que foram predeterminados pelo projetista de banco
de dados e que escreveu o esquema. Entretanto, uma vez que
um
banco
de
dados
Relacional
representa
seus
relacionamentos e por meio da correspondncia com valores
de dados, a operao de join pode ser utilizada para
implementar relaes instantaneamente, mesmo quelas que
um projetista de banco de dados talvez no tenha
antecipado.
Esquemas de banco de dados relacional so bem flexveis.

Voc pode adicionar, modificar em remover relaes
individuais sem afetar o restante do esquema. O fato, contanto
que no alterem a estrutura de tabelas que atualmente est
sendo utilizada, voc pode modificar o esquema de um banco
de dados ao vivo. Entretanto, para modificar o esquema de
uma rede simples o de um banco de dados e hierrquico,
preciso interromper todo o processamento do banco de dados
e gerar novamente o todo o esquema. Em muitos casos,
modificar o projeto de banco de dados tambm significa
recriar todos os arquivos fsicos (utilizando um processo de
dump) para corresponder com o novo projeto.
Quando Codd originalmente escreveu suas regras, os bancos de

dados no poderiam armazenar imagens. Hoje em dia, vrios SGBD's
oferecem a opo de ir armazenar imagens como BLOBs dentro do banco
de dados ou como nomes de caminho ou OVFLS para arquivos de imagens
que so armazenados fora do banco de dados. Tecnicamente, nomes de
caminho ou URLS para arquivos externos so ponteiros para algo alm de
tabelas e, portanto, aparentemente fariam com que um SGBD viola-se essa
regra. Entretanto, o esprito da regra que relacionamentos entre entidades
- os relacionamentos lgicos no banco de dados - so representados

Modelo Relacional
36
correspondendo valores de dados, sem o uso de ponteiros de qualquer tipo

para indicar conexes entre entidades.
Regra 2: a regra de acesso garantido
"Cada e todos os dados (valor atmico) em um
banco de dados relacional tm a garantia de serem
logicamente acessveis pela reclassificao de uma
combinao de nomes de tabelas, valor de chave
primria e nome de coluna.
Como a principal razo pela qual em seremos os dados em um
banco de dados para que possamos recuper-lo os novamente, devemos
estar certos de que poderemos recuperar todos dados possveis.
Essa regra afirma que voc deve conhecer apenas trs aspectos para
localizar um dado especfico: o nome da tabela, o nome da coluna e a
chave primria da linha.
No h nenhuma regra nesse conjunto de doze regras e que afirme
categoricamente que cada linha em uma relao de Evans ter uma chave
primria nica. Entretanto, uma relao no pode obedecer regra de
acesso garantido, a menos que ela tenha uma chave primria nica. Sem
uma chave primria nica, voc recuperar algumas linhas com o valor da
chave primria utilizado em uma pesquisa, mas no necessariamente a linha
exata desejada. Portanto, alguns dados talvez no estejam acessveis sem a
capacidade nica de identificar linhas.
Antigos bancos de dados Relacionais no requeriam um qualquer
chave primria. possvel criar eu utilizar tabelas sem restries de chave
primria. Hoje em dia, entretanto, a SQL permite criar uma tabela sem
especificao de uma chave primria, mas a maioria dos SGBD's no
permite que voc em si j dados nessa tabela.
Regra 3: tratamento sistemtico de valores nulos

"Valores nulos (distintos da e string de caracteres
vazia ou de uma string de caracteres em branco ou de
qualquer outro nmero) so suportados completamente
em um SGBD relacional para representar de maneira
sistemtica
as
informaes
ausentes,
independentemente do tipo de dados".
Como voc sabe, nulo um valor de banco de dados especial que
significa " desconhecida". A presena dele em um banco de dados traz
problemas especiais durante recuperao de dados. Por exemplo,
considere o que acontece voc tiver uma relao de funcionrios que
contm uma coluna para falar. Assuma que o salrio nulo em algumas

Modelo Relacional
37
partes das linhas. O que deve acontecer se algum consultar a tabela para
todas as pessoas que ganham mais de US$ 60.000? As linhas com nulos
devem ser recuperadas ou permanecer fora?
Quando SGBD avaliam nulo em relao ao critrio lgico de valor de
um salrio maior que US$ 60.000, ele no pode afirmar se a linha contendo
nulo cumprir com os critrios. Talvez compra; talvez no. Por essa razo,
dizemos que bancos de dados relacionais utilizam lgica trivalorada. O
resultado da avaliao de uma expresso lgica verdadeiro, falso ou
talvez.
Primeiro, com SGBD relacional deve armazenaram o mesmo valor de
nulo em todas as colunas e linhas onde o usurio no insere explicitamente
os valores de dados. O valor utilizado para o nulo deve ser o mesmo,
independentemente do tipo de dados da coluna. Observa que o nulo no
o mesmo que um caractere de espao em branco; ele tem seu prprio valor
ASCII ou UNICODE distinto. Entretanto, na maioria das vezes quando voc v
na tela uma tabela de resultados de uma consulta, nulos no aparecem
como valores em branco.
Segundo, o SGBD deve ter alguma maneira conhecida e coerente de
tratar desses nulos ao realizar consultas. Em geral, voc descobrir que linhas
com nulos no so recuperadas por uma consulta como a do exemplo de
salrio maior que US$ 60.000, a menos que o usurio solicite explicitamente
linhas com um valor de nulo. Atualmente, a maioria dos SGBD's relacionais
obedece ao na tabela de verdade lgica trivalorada para determinar o
comportamento de recuperao quando eles encontram nulos.
A incluso de nulos em uma relao pode ser extremamente
importante. Eles oferecem uma maneira consistente de extinguir entre dados
vlidos, como um 0, e dados ausentes. Por exemplo, faz muita diferena
saber que o soldo de uma conta a pagar 0 em vez de desconhecido. A
conta com comearam nmero zero cancelar algo que gostamos de ver;
a conta com saldo desconhecido poder ser um grande problema.
Regra 4: catlogo on-line dinmico baseado no modelo relacional

"A descrio de banco de dados representada
no nvel lgico da mesma maneira que dados simples,
de modo que usurios autorizados possam aplicar a
mesma linguagem relacional que aplicam a dados
regulares a sua interrogao".
Uma vantagem da utilizao de estruturas de dados idnticas para
um dicionrio de dados, como ocorre com tabelas de dados, que voc
tem uma maneira consistente para acessar todos os elementos do banco de
dados. Voc precisa aprender apenas uma linguagem de consulta. Isso

Modelo Relacional
38
tambm simplifica o prprio SGBD, uma vez que ele pode utilizar o mesmo
mecanismo para tratar dados sobre o banco de dados (metadados) que ele
utiliza para dados sobre a organizao.
Regra 5: a regra da sublinguagem de dados abrangentes

"Um sistema relacional pode suportar vrias
linguagens e vrios modos de utilizao de terminal (por
exemplo, modo de preenchimento de espaos em
branco). Entretanto, h pelo menos uma linguagem
cujas instrues podem ser descritos por alguma sintaxe
bem definida, como string de caracteres, e que seja
abrangente para suportar a todos os seguintes itens:
A definio dos dados

Definio da visualizao
Manipulao de dados
Restries de integridade
Limites de transao
Um banco de dados relacional deve ter alguma linguagem que possa

manter elementos estruturais do banco de dados, modificar em recuperar
dados. Como a maioria dos atuais SGBD as relacionais utilizam SQL como sua
principal linguagem de manipulao de dados, parece no haver nenhum
problema aqui.
Entretanto, com SGBD que no suporta SQL, mas utiliza uma
linguagem grfica, tecnicamente no atenderia essa regra. No obstante, a
vrios produtos hoje em dia cuja linguagem grfica pode realizar o todas as
tarefas que Codd estou sem uma sintaxe de linha de comando.
Teoricamente, esses SGBD as talvez no seja completamente relacionais,
mas uma vez que eles possam realizar todas as tarefas relacionais
necessrias, voc no perde nada se no tiver a linguagem de linha de
comando.
Regra 6: a regra da visualizao de atualizao

"Todas s vezes realizaes que teoricamente so
atualizveis so tambm atualizveis pelo sistema".
Essa regra simplesmente significa que se uma visualizao atender aos
critrios de atualizao, com SGBD deve ser capaz de tratar dessa
atualizao e propagar as atualizaes de volta s tabelas bsicas.

Modelo Relacional
39
Regra 7: insero de alto nvel, atualizao e excluso

A capacidade de tratar uma relao bsica o
uma relao derivada como um nico operando
aplicada no apenas a recuperao de dados, mas
tambm insero, atualizao e excluso de dados".
Codd quis assegurar que o SGBD pudesse tratar ao mesmo tempo de
mltiplas linhas de dados, especialmente quando os dados fossem
modificados.
A linguagem SQL fornece essa capacidade para os atuais SGBDs
relacionais. O que isso traz para voc? Poder modificar mais de uma linha
com um nico comando simplificar lgica da manipulao de dados. Por
exemplo, em vez de precisar ler linha por linha de uma relao para localizar
as linhas para modificao, voc pode especificar critrios lgicos que
identificam as linhas a serem modificadas e deixar que o SGBD encontre as
linhas para voc.
Regra 8: independncia de dados fsicos

"Atividades de programas de aplicaes e
atividades de terminais permanecem logicamente
intactas sempre que alguma alterao ocorrer na
representao de armazenamento e o nos mtodos de
acesso".
Um dos benefcios da utilizao de um sistema de banco de dados,
em vez de um sistema de processamento de arquivos, que o SGBD isola
usurio de detalhes de armazenamento fsico.
Isso significa que voc pode mover o banco de dados a partir de um
volume de disco para outro, alterar o layout fsico dos arquivos e assim por
diante, sem causar nenhum impacto na maneira como os programas de
aplicaes e os usurios finais interagem com as tabelas do banco de
dados.
A maioria dos SGBDs atuais oferece pouco controle sobre as
estruturas de arquivos utilizadas para armazenar dados no disco. Portanto, na
prtica, independncia de dados fsicos significa que voc pode mover o
banco de dados e a partir de um volume de discos ou diretrio para outro
sem afetar as aplicaes ou os usurios interativos. Com algumas excees em particular, SGBD's deu usurio final baseados no modelo dBase - a
maioria dos SGBD's atuais fornecem independncia de dados fsicos.

Modelo Relacional
40
Regra 9: independncia de dados lgicos

Programas de aplicaes e atividades de
terminais permanece logicamente intactos quando so
feitas alteraes de qualquer tipo as tabelas bsicas que
preservam informaes que teoricamente permitem a
estabilidade dos dados".
Independncia de dados lgicos um pouco mais sutil que a
independncia de dados fsicos. Em essncia, significa que se voc alterar o
esquema, talvez adicionando ou removendo uma tabela ou adicionando
uma coluna para uma tabela, as outras partes do esquema que no devem
ser afetadas pela alterao permanecem inalteradas.
Como um exemplo, considere o que acontece quando voc
adiciona uma tabela a um banco de dados. Uma vez que as relaes so
logicamente independentes entre si, adicionar uma tabela no causa
absolutamente nenhum impacto sobre qualquer tabela. Para obedecer
regra de independncia de dados lgicos, com SGBD deve assegurar que
de fato no h nenhum impacto sobre outras tabelas.
Por outro lado, se voc escolher uma tabela do banco de dados, essa
modificao no de preservao de informaes. quase certo que os
dados sero perdidos quando a tabela for removida. Portanto, no
necessrio que aplicaes e usurios interativos no sero afetados pela
operao.
Regra 10: independncia de integridade

"Restries de integridade especficas para um
banco de dados relacional em particular devem ser
definido vez na sublinguagem de dados Relacionais e
passveis de serem armazenados no catlogo, no nos
programas de aplicaes.
No mnimo duas das seguintes restries de integridade e devem ser
suportadas:
1. Integridade de entidade: nenhum componente de uma chave

primria tem permisso para ter um valor nulo
2. Integridade referencial: para cada valor de chave estrangeira no
nulo e distinto em um banco de dados relacional, deve existir um valor
de chave primria e que corresponda ao mesmo domnio.

Modelo Relacional
41
Observe que essa regra requer que a declarao de restries de

integridade faa parte de qualquer que seja a linguagem utilizada para
definir a estrutura do banco de dados. Alm disso, qualquer tipo de restrio
de integridade deve ser armazenado em um dicionrio de dados que possa
ser acessado enquanto o banco de dados utilizado.
Quando a IBM lanou seu carro-chefe de banco de dados relacional
o DB/2 uma entre duas reclamaes dos usurios foi a falta de suporte
para integridade referencial. Quanto a isso, a IBM e outros fornecedores de
SGBD omitiram a integridade referencial, pois ela reduzia o desempenho.
Todas as vezes que voc modificar uma linha de dados, o SGBD deve ir ao
dicionrio de dados, procurar uma regra de integridade e realizar o teste
indicado pela regra, tudo isso antes de realizar uma atualizao. Uma
verificao de integridade referencial de uma nica coluna pode envolver
dois ou mais acessos ao disco, que leva mais tempo do que simplesmente
fazer a modificao diretamente na tabela bsica.
Entretanto, sem a integridade referencial os relacionamentos em um
banco de dados relacional tornam-se rapidamente inconsistentes. Portanto,
consultas de recuperao no necessariamente recuperam todos os dados,
pois referncias cruzadas ausentes fazem com que joins omitam dados.
Nesse caso, o banco de dados no ser confivel e praticamente
inutilizvel. (Tudo bem, a IBM adicionou integridade referencial ao DB/2 bem
rapidamente!)
Regra 11: independncia de distribuio
"Um SGBD relacional tem independncia de
distribuio.
Um banco de dados distribudo um banco de dados onde os
prprios dados so armazenados em mais de um computador. Portanto, o
banco de dados a unio de todas as suas partes. Na prtica, as partes
no so nicas, mas contm um grande volume de dados duplicados.
Em outras palavras, um banco de dados distribudo deve parecer ao
usurio como uma banco de dados centralizado. As aplicaes e os usurios
interativos no precisam conhecer o local de armazenamento dos dados,
incluindo a localizao de mltiplas cpias dos mesmos dados.
Regra 11: regra da no-subverso
"Se um sistema relacional tiver uma linguagem de
baixo nvel (um nico registro de cada vez), essa
linguagem de baixo nvel no pode ser utilizada para
subverter ou pular as regras de integridade ou restries
expressas na linguagem relacional de nvel mais alto
(mltiplos registros de cada vez).

Modelo Relacional
42
Muitos produtos de SGBD na dcada de 1980 tinham linguagens que

poderiam acessar diretamente as linhas nas tabelas, separadamente da
SQL, que opera em mltiplas linhas de cada vez. Essa regra afirma que no
h nenhuma maneira de utilizar essa linguagem de acesso direto para evitar
as restries de integridade armazenadas no dicionrio de dados. Todas as
regras de integridade devem ser observadas.
Destas doze regras, pelo menos seis devem ser cumpridas para
que o SGBD possa ser qualificado como completo relacionalmente.

Integridade
Integridade
Controle de Integridade Semntica do Banco de
Dados
O termo integridade utilizado em banco de dados com o seguinte
significado: preciso, correo, validade. O grande problema da
integridade o de assegurar que os dados no banco de dados se
mantenham precisos, corretos, validos. Ou seja, o de preservar o banco de
dados contra atualizaes/inseres no vlidas (controle de acesso).
Se o objetivo do controle de acesso ao BD o de evitar que pessoas
e/ou programas no autorizados leiam e/ou atualizem a base de dados,
ento objetivo dos mecanismos que zelam pela integridade semntica do
BD garantir que somente atualizaes permitidas sejam executadas na base
de dados.
Por permitidas, entenda-se as modificaes que mantenham a
relao entre o mini-mundo (do usurio/da aplicao) e a representao
deste no BD.
Requisitos (restries) de Consistncia (Consistency Constraints) dizem
respeito consistncia dos dados em sua representao nos nveis mais
baixos da arquitetura do SGBD.
Exemplo: no endereo de disco (cilindro, trilha, bloco fsico) deve estar
armazenado o bloco de dados lgico (pgina) correto (correspondente).
Em nveis mais altos da arquitetura do SGBD, o nmero de requisitos de
consistncia a serem preservados de multiplica.
Exemplo: os endereos de registros apontados por um arquivo de
ndice devem sempre refletir o estado atual do arquivo
indexado.
Requisitos de Consistncia dos nveis mais baixos da arquitetura do
SGBD podem ser derivados durante seu projeto e no dependem de uma
aplicao particular (so vlidos para qualquer aplicao).
No nvel mais alto da arquitetura (nvel das estruturas de dados lgicas
- modelo externo, dicionrio de dados) devem ser levados em conta e
assegurados os relacionamentos entre o mini-mundo no qual o usurio
baseia seu trabalho e o mapeamento deste mini-mundo no BD. Este
mapeamento especfico e dependente de cada aplicao.

Integridade
44
A partir da definio, por parte do usurio, dos estados corretos e das

transies de estado corretas no seu mini-mundo, o SGBD deve garantir que
o BD reflita somente estes estados e que as operaes sobre o BD reflitam
somente estas transies.
A garantia da integridade semntica a garantia de que o estado
dos dados do BD est sempre coerente com a realidade para o qual o
mesmo foi projetado e criado. No basta ter um esquema com os dados
eficientemente bem estruturados, se no existir nenhum controle sobre os
valores dos mesmos (falta de confiabilidade). Se no existe gerenciamento
de integridade semntica, pode-se ter violaes de domnio (valores no
condizentes com a semntica de certo atributo - por exemplo, um
empregado com idade de 10 ou 100 anos), dados desconhecidos (ausncia
de valor em atributos significativos, como nome do empregado) e
relacionamentos incorretos ou inexistentes (por exemplo, a ocorrncia de
situaes proibidas, como departamentos sem gerente ou algum sendo
gerente de mais de um departamento).
Garantir integridade semntica garantir estados corretos de um
dado (verificado sempre aps alguma atualizao no BD) e transies de
estado tambm vlidas (s vezes, uma atualizao no BD acarreta outras
aes de atualizao sobre outros dados - transparentes para a aplicao de forma a manter a integridade do esquema).
Um subsistema de integridade semntica de um SGBD controla
restries especificadas sobre um esquema. Estas restries (ou regras) so
chamadas restries de integridade (RIs). O gerenciamento destas restries
envolve trs funes bsicas:
Especificao de RIs: deve ser possvel especificar testes e

aes para garantia de integridade. Para tanto, o SGBD deve
suportar uma linguagem de especificao de restries (DCL),
cujos comandos so compilados e mantidos no catlogo do
sistema (DD) para posterior consulta e modificao;
Monitoramento de RIs: sempre que ocorrer uma operao de
atualizao sobre um dado, todas as RIs que dizem respeito ao
mesmo devem ser consultadas no DD, para verificar se alguma
delas no foi violada ou se algo mais (por exemplo, outra
atualizao ou a execuo de um procedimento qualquer)
deve ser realizado;
Aes para garantia de RIs: quando alguma operao de
atualizao gera alguma inconsistncia, devem ser tomadas
aes como o impedimento da atualizao (rollback da
atualizao) ou a execuo de outros procedimentos para
atualizar dados relacionados.
Assim sendo, em toda RI deve ser possvel especificar:
Para quais dados deve-se verificar a regra (alcane da regra);

Integridade
45
Quando a regra deve ser verificada (antes, imediatamente

aps ou um tempo aps a operao de atualizao);
Que ao deve ser tomada para garanti-la.
A existncia de um subsistema de integridade semntica

extremamente vantajosa para as aplicaes que utilizam um SGBD, pois
existe total independncia deste controle, ou seja, o gerenciamento de
integridade fica a cargo do SGBD. As aplicaes ficam liberadas desta
pesada tarefa, sendo que estas apenas submetem operaes ao SGBD e
recebem indicao de O.K. ou sinalizaes de violaes e atitudes tomadas
para garanti-las.
Classificao dos Requisitos de Integridade (RI)

Os requisitos de integridade podem ser classificados segundo os
seguintes aspectos:
Segundo o Seu Alcance (volume de informao associada

RI)
a) Atinge um nico atributo de uma relao.
Ex.: e-nome s pode conter letras ou brancos (RI1)
b) Atinge mais de um atributo de uma mesma tupla
Ex: s-total s-oramento (RI2)
c) Atinge mais de uma tupla (um registro) do mesmo tipo
(mesma relao)
Ex.: e-no deve ser unvoco (cada tupla em EMP tem valor
diferente em e-no) (RI3)
d) Atinge mais de uma tupla que podem ser de tipos
diferentes
Ex.: s-totsal (var_seo) = e-sal (i)
var_seo (RI4)
e-sec (i) =
Segundo o Momento do Teste da Restrio

a) Instantnea sempre que o dado associado RI for
inserido ou atualizado, a RI deve ser testada.
Ex.: e-no 0001 e-no 9999 (RI5)

Integridade
46
b) Postergada a RI s pode ser testada aps uma srie de

operaes sobre o BD (tpico para RIs que atingem mais
de uma tupla de relaes diversas).
Ex.: O usurio deseja aumentar o salrio de alguns
empregados (da mesma seo). A RI4 s necessita
ser testada ao final das atualizaes. (performance!!)
RIs Que Regulamentam a Atualizao de Valores
RIs baseadas em Verses de Valores de Dados.

Testes levam em conta a relao (valor_antigo, valor_novo).
Exemplo 1: O salrio do empregado no pode ser rebaixado (RI6)
e-sal (novo_valor) e-sal (valor_atual)
Exemplo 2: As transies do estado civil do empregado devem
respeitar o seguinte grafo de precedncias:
VIVO
SOLTEIRO
CASADO
SEPARADO
DIVORCIADO
RIs Que Devem Ser Testadas na Ocorrncia de Eventos Externos

O momento do teste da RI determinado pela aplicao.
Exemplo: A partir de trs meses de sua data de ingresso na empresa, o
salrio do empregado deve refletir o salrio bsico
estipulado para sua funo (piso salarial da categoria).
(3 meses = perodo de experincia) (RI7)
(data_atual - e-dataing 90) e-sal sal_base (e-func)

Integridade
47
Mtodos Utilizados no Suporte Especificao de

Restries de Integridade
a) Oferecimento de mecanismos embutidos na linguagem de
manipulao de dados (DML para a definio das RIs. (A DML pode ser
procedural, (ex.: CODASYL) ou descritiva (ex.: SQL, QUEL, QBE)).
b) Especificao de RI associadas ao objeto e integradas
especificao do prprio objeto com base no conceito de tipos abstratos
de dados (ADT) (proposta nova).
Definio e Teste de Restries de Integridade

Em SGBDs Mais Antigos (No Relacionais)
Restries de Integridade no DBTG (modelo em Rede):

As RIs so como procedures em uma linguagem baseada em
COBOL. O DBTG oferece uma clusula de sua linguagem de
declarao que associa operaes sobre a base de dados com
procedures que testam RIs.
ON < command_list> CALL <procedure>
Esta clusula associada a declaraes de tipos de registros e
sets:
<command_list> C {insert, delete, modify, find,...}
Exemplo: Teste de RI5 durante a insero de um novo empregado:
PROCEDURE P1:
IF (e_nr < 0001 OR e_nr > 9999)
THEN GO TO TRATA_ERRO_RI5
END P1;
DEFINE RECORD_TYPE EMP
e_no : CHAR(4);
...
ON INSERT CALL P1
END;
Em SGBDs Relacionais
RIs em SQL definio com o uso da DML

Integridade
48
Alternativa 1: atravs da clusula ASSERT

ASSERT RI5 ON EMP:
e-no BETWEEN 0001 AND 9999 IMMEDIATE
ASSERT RI2 ON SEO:
s-totsal s-oram
ASSERT RI4 ON SEO X:
s-totsal = (SELECT SUM (e-sal) FROM EMP WHERE s-sec=x.s-no)
ASSERT RI6 ON EMP (e-sal):
NEW e-sal OLD e-sal
RIs especificadas com ASSERT tem seu teste postergado at o fim
do trabalho do usurio, a no ser que estejam associadas
clusula IMMEDIATE.
Alternativa 2: atravs do conceito de TRIGGER

Permite que o sistema execute automaticamente uma srie de
operaes quando uma determinada operao executada
pelo usurio (lembra DBTG).
TRIGGER: Evento Teste Procedimento
DEFINE TRIGGER T1:
ON UPDATE EMP x (e-sal)
(UPDATE SEO
SET s-totsal = s-totsal + (NEW x.e-sal - OLD x.e-sal)
WHERE s-no = x.e-sec)
Exemplo de Manuteno de Restrio de Integridade Com e Sem

TRIGGER (SQL)
MANUTENO SEM USO DE TRIGGER (tudo programado pelo usurio)

ASSERT RI4 ON SEO X:
/* X representa cursor */
s-totsal = (SELECT SUM (e-sal)
FROM EMP
WHERE e-sec = x.s-NO)
/* postergado */
Begin-Of-Transaction
/* incio do programa do usurio */
UPDATE EMP
SET e-sal = e-sal + e-sal * 0.1
/* aumento de 10% */
WHERE e-sec = SETOR B
UPDATE SEO
SET s-totsal = s-totsal + s-totsal * 0.1
WHERE s-nr = SETOR B
End-Of-Transacton
/* fim do programa do usurio */

Integridade
49
No final do programa, a clusula ASSERT automaticamente

avaliada.
MANUTENO COM USO DE TRIGGER (atualizao automtica de s-totsal)

DEFINE TRIGGER T1:
ON UPDATE EMP x (e-sal)
(UPDATE SEO
SET s-totsal = s-totsal + (NEW x.e-sal - OLD x.e-sal)
WHERE s-no = x.e-sec)
Begin-Of-Transaction
/* incio do programa do usurio */
UPDATE EMP
SET e-sal = 1.1 * e-sal
WHERE e-sec = Setor B
Neste ponto do programa, o SGBD executa T1, mantendo
RI4
End-Of-Transaction
/* fim do programa do usurio */
Outros programas podem fazer uso do mesmo Trigger T1.
Triggers Podem Causar Problemas
O programador deve conhecer todos os triggers declarados no SBD,

caso contrrio programar de forma redundante, podendo provocar
inconsistncias no BD;
A definio de novos triggers pode implicar na alterao de
programas de aplicao j existentes;
J que triggers podem ser ativados de dentro de outros triggers, sua
definio em cadeia (e talvez recursiva) pode fugir ao controle de
seus programadores e gerar inconsistncias na base de dados;
O usurio no tem como definir uma ordem de execuo de triggers
(SQL). Caso uma operao do usurio dispare mais de um trigger, o
resultado dos primeiros a serem executados pode interferir no
processamento dos prximos;
O sistema no testa a semntica de um trigger;
Posso declarar triggers conflitantes entre si (Um trigger pode fazer
alguma coisa e outro desfazer).

Integridade
50
Tcnicas Para a Implementao de Controle

Automtico de RIs no SGBD
Existem duas alternativas:
1. As rotinas de controle de restries de integridade constituem parte
do cdigo do SBD.
> O controle , portanto interpretativo e acontece em tempo de
execuo das operaes sobre o BD. A cada operao, as RIs a ela
associadas so testadas e, em caso de transgresso, um cdigo de erro
transmitido ao programa do usurio.
2. O programa de aplicao pr-compilado por um mdulo especial
que investiga cada operao que ser executada sobre o BD.
> Para cada uma destas operaes, suas RIs associadas so
indentificadas e o pr-compilador/processador, ou expande o programa
com o cdigo necessrio ao teste das RIs (ex.: query-modification), ou
conecta o programa (logicamente) a rotinas pr-compiladas que realizam
estes testes (ex.: triggers).
Vantagens do Esquema Pr-Compilativo
1. A identificao das RIs que devem ser garantidas para cada operao
a ser executada pelo programa feita uma s vez.
Compare com o esquema interpretativo no seguinte caso:
WHILE Recebe_Tupla_Do_Usurio /* via arquivo */
DO Insere_Tupla_Em_Relao_EMP
2. O pr-processador pode varrer todo o programa de aplicao,
identificando grupos de comandos associados s mesmas RIs.
Sendo assim os respectivos testes podem ser inseridos aps todos os
comandos do grupo correspondente. Por exemplo:
Atualiza_Salrio_Emp (e-no = E-1)
Remove_Tupla_Emp (e-no = E-2)
Atualiza_Tupla_Seo (s-totsal)
Testa_Ris:

Integridade
51
s-totsal = SELECT SUM (e-sal) FROM EMP WHERE e-sec = s-no

s-totsal s-oram
3. No esquema interpretativo, o sistema vai analisando as operaes do
programa de aplicao conforme estas vo sendo executadas.
Sendo assim, possveis transgresses que poderiam ser detectadas
em tempo de compilao do programa s sero identificadas aps a
execuo de vrias operaes.
Exemplo: imagine que a terceira operao do exemplo acima
no conste do programa de aplicao.
As observaes feitas, acima, s so vlidas para interfaces de BDs
embutidos em linguagens de programao de uso geral (ex.: Pascal,
COBOL, C). Em interfaces para consultas ad-hoc, as premissas podem ser
outras.
custoso para o SGBD identificar, automaticamente, o conjunto de
operaes que se relacionam com o mesmo conjunto de RIs.
Para o SGBD seria custoso verificar se existem RIs conflitantes. Para
a aplicao seria difcil verificar se todas as RIs foram descritas.
As restries de integridade mais complexas (envolvendo mais de
uma relao e funes de agregao so mantidas pelos programas de
aplicao ou atravs de triggers e stored procedures. Os programadores
de aplicao podem construir programas mais eficientes para situaes
especficas.
Mesmo que fosse possvel implementar todo o controle de RIs no
SGBD, o tempo de execuo dos testes seria proibitivo para aplicaes
maiores (mais complexas).

Vises
Vises
Relaes, no modelo relacional, so as tabelas fsicas no banco de
dados. As vises so relaes virtuais derivadas das relaes do banco de
dados, ou seja, tabelas virtuais derivadas das tabelas fsicas do banco de
dados.
Uma viso criada com o intuito de melhorar a segurana de acesso
ao banco de dados, e gerar relaes que melhor se adequam s
necessidades de uma aplicao, para um determinado usurio (ou grupo
de usurios).
Uma viso pode ser encarada como uma janela para um conjunto de
dados mantidos em um BD. Considerando um BD relacional, por exemplo,
uma viso seria uma relao virtual derivada a partir de dados de uma ou
mais relaes do esquema. Esta derivao transparente para a aplicao
que a manipula, ou seja, para a aplicao como se os dados da viso
fossem tabelas mantidas fisicamente no BD.
Vises so dinmicas por definio, ou seja, sempre refletem o estado
atual dos dados das relaes das quais derivam. Caso novos dados sejam
inseridos, ou alguns deles modificados diretamente nas tabelas, os mesmos
sero naturalmente vistos por futuras consultas solicitadas s vises que
tm acesso a estes dados.
Por exemplo:
a) Um funcionrio do hospital no deve ter acesso a
todos os dados pessoais de um paciente, somente ao seu
cdigo e nome;
b) Pode ser interessante vincular os dados de um
mdico aos dados de suas consultas
O principal cuidado quando se define uma viso consider-la
passvel de atualizao ou no. Por default, toda viso passvel de
consulta. Por outro lado, nem toda viso atualizvel. Se nenhum tipo de
controle for feito explicitamente pelo projetista do BD ou implicitamente pelo
SGBD, dados inconsistentes podem surgir no BD, em decorrncia de uma
atualizao proveniente de uma viso. necessrio que toda viso
atualizvel atenda as seguintes premissas (supondo um BD relacional):
1) Toda viso atualizvel deve preservar a chave primria (CP) da
relao da qual deriva.

Vises
54
2) Toda viso atualizvel deve conter atributos cujos valores

tenham uma correspondncia direta com valores de atributos
presentes na relao da qual deriva.
3) Toda viso atualizvel deve ser derivada, preferencialmente, de
apenas uma relao.
A premissa 1 garante que toda tupla modificada por uma viso tenha
condies de ser identificada e modificada na relao fsica, sem problema
de ambiguidade, ou seja, deve existir um mapeamento 1 para 1 de uma
tupla da viso para uma tupla da relao. Quando isto no garantido,
tem-se vrios problemas, como por exemplo, incluses de tuplas com CP
total ou parcialmente nula nas relaes ou remoes de tuplas na viso sem
saber exatamente quantas tuplas sero efetivamente removidas na relao.
A premissa 2 considera vises estatsticas, ou seja, vises que retornam
certos clculos associados a alguns atributos de uma relao. So vises
tipicamente para consulta a informaes derivadas do BD, no havendo
sentido a realizao de atualizaes a partir delas. Isto porqu, ocorrendo
atributos da viso que so clculos a partir de atributos da relao, no h
uma correspondncia direta entre colunas da viso e da relao. Isto pode
dificultar e at mesmo inviabilizar a atualizao fsica do BD, ainda mais
quando no se consegue determinar precisamente esta correspondncia
(por exemplo, um clculo com vrias variveis, cada uma sendo um atributo
de uma relao).
A premissa 3 considera problemas de efeitos indesejveis de
atualizaes feitas a partir de vises, pelo fato da mesma agregar atributos
de diversas relaes. Por exemplo, a incluso de uma nova tupla na viso se
reflete na incluso de tuplas em todas as relaes envolvidas, podendo
gerar violao de CP, se nem todos os atributos que compem as chaves
das relaes envolvidas estiverem presentes. A atualizao de uma tupla da
viso acarreta atualizaes em atributos de relaes que podem violar
restries de CP e chave estrangeira (CE). Da mesma forma, por no haver
uma correspondncia 1 para 1 entre tuplas da viso e da relao, uma
excluso feita na viso pode ter o efeito indesejvel de excluir mais dados
do que o realmente esperado.
Ao nvel de controle de atualizao a partir de vises, a linguagem
SQL permite a incluso da clusula With Check Option ao comando Create
View, que impede a incluso ou atualizao de valores de atributos da viso
que possam violar o seu predicado de definio. Por exemplo, se a viso
enxerga apenas dados de pessoas maiores de idade, no permitido
cadastrar, a partir dela, uma pessoa com menos de 18 anos. Porm, este
controle insuficiente, considerando que, em algumas vises, os atributos
que fazem parte do seu predicado de definio no so manipulados por
ela. Assim, uma nova tupla inserida a partir dela gera null nestes atributos e,
se nenhum controle explcito for implementado, esta nova tupla no ser
mais enxergada.

Vises
55
Vantagens
Elas fazem com que o mesmo dado seja visto por diferentes
usurios de diferentes formas (ao mesmo tempo);
A percepo do usurio simplificada;
bvio que o mecanismo da viso possibilita aos usurios
centrarem-se unicamente nos dados que lhes so importantes e
ignorarem o resto. O que talvez no seja to bvio que, pelo
menos na recuperao (consulta), tal mecanismo tambm possa
simplificar consideravelmente as operaes de manipulao de
dados feitas pelo usurio;
Segurana automtica para os dados ocultos Dados ocultos
so aqueles no visveis atravs de determinada viso. Ficam
claramente protegidos por meio desta viso especfica. Assim,
obrigar os usurios a acessar o banco de dados atravs de vises
um mecanismo simples, porm eficaz de controle de
autorizao.
Algumas Sugestes Importantes
Impedir operaes de atualizao sobre vises;

As tuplas de uma viso devem corresponder a tuplas que tenham
condies de serem identificadas nas tabelas fsicas das quais ela
deriva;
Cada atributo de uma viso deve corresponder a um atributo
distinto e identificvel de alguma das tabelas fsicas das quais ela
deriva.
Concluindo, vises so um mecanismo importante em BDs, uma vez

que garantem independncia lgica do esquema do BD, ou seja, permite
que cada aplicao ou usurio manipule apenas os dados que lhe
interessam. A viso tambm esconde (abstrai) o processo de busca destes
dados, que pode ser complexo caso vrias relaes tenham que ser
consultadas e combinadas para se obter a estrutura pretendida pela
aplicao ou usurio. Outra importante vantagem de uma viso ser um
mecanismo de autorizao de acesso, ou seja, disponibiliza para uma
aplicao ou usurio apenas dados que o(a) mesmo(a) tem permisso.

ndice Remissivo
Triggers
Um trigger foi definido inicialmente como um procedimento prdefinido de um banco de dados, condicional ou incondicionalmente
sucedido ou precedido de outras operaes do banco de dados
automaticamente (K.P Eswaran, "Specifications, Implementations and
Interactions of a Trigger Subsystem in an Integrated Database System," IBM
Research Report, RJ1820, 1976). Isto significa, cdigos procedurais ou uma
seqncia de operaes codificadas em uma mistura de SQL e comandos
de programao. Um trigger , ento, uma lgica de processamento
procedural, armazenada nos SGBD's e executada automaticamente pelos
servidores de SGBD sob condies especficas. A palavra automtica
muito importante - aplicaes ou usurios no disparam triggers, eles so
executados automaticamente quando as aplicaes ou usurios realizam
operaes especficas sobre a base de dados. Um trigger tem os seguintes
componentes:
Coao (situao): a situao de integridade ou regra de negcio
forada pelo trigger, em outras palavras, a proposta desta ferramenta.
Na prtica, aparece no cabealho do trigger e deve refletir-se no seu
nome. Por exemplo, Abertura de Balano Positivo requer que todas
novas contas devem ter saldos positivos.
Evento: uma situao especfica ocorrendo na base de dados, que
indica quando a situao deve ser forado. O evento dito para ser
realizado quando a situao ocorre. O evento especificado de duas
maneiras:
Estado de alterao da base de dados e
Condio de atributo opcional usado para extrair algumas das
situaes alteradas.
Exemplo: somente inclui-se registro na tabela PLANO com valores positivos no
atributo saldo.
Ao: uma procedure ou seqncia de operaes procedurais que
implementam uma lgica de processamento requerida obrigadas pela
situao. Por exemplo, a ao deve forar a regra de negcio que
contas contbeis no podem ter saldo negativo na abertura de balano.
Isto pode ser feito pela rejeio da operao de insero se o balano
de abertura negativo, ou pela substituio do valor negativo por zero e
sua insero numa tabela de acontecimentos. A condio if implicada
reala um outro ponto : operaes de manipulao convencional em
SGBD tambm so limitadas para implementar as aes requeridas. Eles
devem ser estendidos com construes procedurais como repeties

Triggers
57
(while, repeat e for) e comandos de condio (if e case). Um trigger ,

portanto, um evento que dispara uma ao obrigado por uma situao.
Vantagens
A principal caractersticas que eles so armazenados e executados
no banco de dados. Segue algumas outras vantagens :
O trigger sempre disparado quando o evento associado ocorre
Desenvolvedores de aplicativos no tem a lembrana para incluir a
funcionalidade em todas a aplicaes e os usurios no podem desviar dos
triggers atravs de ferramentas interativas. A maioria dos SGBDs tem alguns
mecanismos para desviar dos triggers, ou por desativao temporria ou
usando um trace point. Este artifcio somente pode ser usado por pessoas
altamente responsveis pelos seus atos.
Triggers so administrados cetralizadamente
Eles so codificados, testados e, ento, forados para todas
aplicaes de acesso ao Banco de Dados. Os triggers so usualmente
controlados e at controlados, por um DBA experiente. O resultado que os
triggers so implementados eficientemente.
A ativao central e o processamento de triggers adapta perfeitamente
a arquitetura cliente-servidor
Uma simples requisio de um cliente pode resultar em uma
seqncia completa de verificaes, e a execuo de operaes
subsequentes sobre o banco de dados. Os dados e as operaes no so
trafegadas pela rede entre cliente e servidor.
Pelo motivo de que os triggers so to poderosos, eles devem ser
gerenciados muito bem e usados corretamente. Triggers ineficientes podem
corromper a integridade dos dados.
Utilizao de Triggers
Triggers so extremamente poderosos e podem ser usados para vrios
propsitos:

Triggers
58
CONTROLE DE INTEGRIDADE pode-se usar triggers para implementar

integridade de domnio, integridade de atributos, integridade referencial e
situaes de integridade no-referencial.
REGRAS DE NEGCIO utiliza-se triggers para centralizar obrigaes de
regras de negcios. Regras de negcios so situaes invocadas sobre
relacionamentos entre tabelas ou entre registros diferentes na mesma tabela.
Por exemplo, a soma dos totais de ITEM_PEDIDO devem adicionar ao
total do registro de PEDIDO do correspondente pedido.
APLICAO LGICA pode-se usar triggers para forar lgicas de negcio
de modo centralizado. Por exemplo, inserir automaticamente registros em
ORDEM e ITEM_ORDEM quando o valor de QTDE_DISPONIVEL estiver abaixo,
pedindo uma aquisio. Regras de negcios podem ser formalizadas e,
atualmente, serem definidas de modo declarativo. Isto tudo se a sintaxe
declarativa permitir, mas aplicaes lgicas mais complexas em
funcionalidade podem ser especificadas.
SEGURANA utiliza-se triggers para verificar situaes importantes de
segurana sobre a base de dados. Quando uma operao realizada
sobre uma entidade sensvel, o trigger disparado para verificar se esta
operao permitida para o usurio.
Por exemplo, pode-se somente inserir um registro na tabela de
FUNCIONARIO se a coluna DEPARTAMENTO conter o valor deste prprio
departamento. Em muitos sistemas, entretanto, no pode-se usar triggers
para restringir a visualizao dos dados pelos usurios. Geralmente, estes
sistemas possuem ferramentas especficas otimizadas para atender estes
casos de permisso de acesso s tabelas.
AUDITORIA triggers podem incluir registros em tabelas de auditoria com a
finalidade de registrar todas operaes sobre tabelas importantes ao
sistema. O problema desta abordagem que muitas aes de triggers so
feitas sob controles transacionais. Quando uma operao retornada
(rollback), todas as operaes relacionadas em triggers, tambm, so
recuperadas. Os triggers somente gravam os efeitos das operaes
concludas com sucesso. Quando uma operao malsucedida
recuperada posteriormente, a entrada de auditoria desta operao
tambm ser retornada. A auditoria no contm a ameaa de perigo
violao da integridade dos dados ou restrio de segurana.
REPLICAO DE DADOS muitos representantes comerciais de SGBD's e
consultores tem implementado replicadores usando triggers como
mecanismo de gravao. Na prtica, quando as tabelas replicadas so
alteradas, os triggers disparam um registro de movimentao em tabelas de
armazenamento (buffer table). Um servidor de replicao ento propaga as
operaes efetuadas a partir das buffer tables para os vrios Bancos de
Dados de destino. Nesta situao, o controle transacional sobre os triggers

Triggers
59
extremamente utilizado, para que somente seja replicado transaes

completadas com sucesso.
O uso de triggers limitado somente funcionalidade provida pelo
SGBD especificado e, lgico, a sua imaginao e ao seu esprito inovador.
Atualmente, os triggers esto prximo ao servidor de Banco de Dados.
Em muitos casos, tornando o servio de banco de dados bastante pesado.
Para descarregar este servio de triggers dos servidores, as novas verses de
SGBD's esto isolando os triggers em um servidor especfico, para receber
tratamento especfico.
Exemplo de trigger para obrigar a abertura de balano na tabela
PLANO. Implementado em CA-OpenIngres/Desktop 1.1
create table PLANO_CONTAS
(num_conta
char (10) not null,
desc_conta
char (10) not null,
tipo_conta
char (1) not null,
saldo_conta
decimal (10,2) not null,
primary key (num_conta));
/* procedure stored FORCA_BALANCO */
/* situacao: obriga a entrada de valores positivos */
store FORCA_BALANCO
procedure FORCA_BALANCO static
parameters
string
num_conta
number
saldo_conta
local variables
sql handle AcctHandle
actions
on procedure startup
begin
call sqlconnect (AcctHandle)
call
sqlprepare
(AcctHandle,
update
PLANO_CONTAS
\
set
saldo_conta
=
0
where
num_conta
=
:num_conta)
end
on procedure execute
begin
if (saldo_conta < 0)
call sqlexecute (AcctHandle)
call
sqlgetmodified_rows
(AcctHandle,RowCount)
if RowCount <= 0
return 20001
end
on procedure close
begin
call sqldisconnect (AcctHandle)
end

Triggers
60
create trigger FORCA_BALANCO_TRIGGER

after insert on PLANO_CONTAS
(execute
FORCA_BALANCO
(PLANO_CONTAS.num_conta,
PLANO_CONTAS.saldo_conta))
for each row

BD - Aspectos Basicos

Enviado por

Dados do documento

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

BD - Aspectos Basicos

Enviado por

Direitos autorais:

Formatos disponíveis

Aspectos

Florianpolis, fevereiro de 2004.

ASPECTOS BSICOS DE BANCO DE DADOS

Copyright 2004. Adobe Acrobat eBookReader for Windows.

ASPECTOS BSICOS DE BANCO DE DADOS

Qual a Diferena Entre Dados, Informao e Conhecimento

Sistema de Gerncia de Banco de Dados (SGBD)

Sistema de Banco de Dados

Porque Usar Banco de Dados

Vantagens do Controle Centralizado

O Que se Pode Almejar Com o Uso de SBD

Os Trs Nveis da Arquitetura

Administrador de Banco de Dados

MODELOS DE DADOS (MODELOS CONCEITUAIS E LGICOS)

Classificao de Modelos de Dados

Modelos Lgicos Baseados Em Objetos

ASPECTOS BSICOS DE BANCO DE DADOS

Modelos Lgicos Baseados Em Registro

Modelos Fsicos de Dados

Tabelas de Exemplo do Dicionrio de Dados

Regras de Integridade Relacional

Implicaes das Regras

Especificao de Banco de Dados Relacional

Controle de Integridade Semntica do Banco de Dados

Classificao dos Requisitos de Integridade (RI)

Mtodos Utilizados no Suporte Especificao de Restries de Integridade

Exemplo de Manuteno de Restrio de Integridade Com e Sem

Algumas Sugestes Importantes

ASPECTOS BSICOS DE BANCO DE DADOS

ASPECTOS BSICOS DE BANCO DE DADOS

Qual a Diferena Entre Dados, Informao e

ASPECTOS BSICOS DE BANCO DE DADOS

Baseado nas definies acima se pode deduzir ento que Banco de

Coleo de dados relacionados;

Sistema de Gerncia de Banco de Dados (SGBD)

Sistema de Banco de Dados

ASPECTOS BSICOS DE BANCO DE DADOS

Gerenciador de Arquivos que trata da alocao do espao para

ASPECTOS BSICOS DE BANCO DE DADOS

Porque Usar Banco de Dados

Vantagens do Controle Centralizado

Que os nicos meios de acesso ao banco de dados sejam

ASPECTOS BSICOS DE BANCO DE DADOS

Estabelecer diferentes controles para cada tipo de acesso

Integridade Referencial - os registros de relacionamentos

Equilibrar Necessidades Conflitantes

O Que se Pode Almejar Com o Uso de SBD

Redundncia controlada de dados

ASPECTOS BSICOS DE BANCO DE DADOS

ASPECTOS BSICOS DE BANCO DE DADOS

Notar que os 3 esquemas so apenas descries de dados. Os dados

Os Trs Nveis da Arquitetura

O nvel interno o mais prximo ao armazenamento fsico - i.e.

Se o nvel externo diz respeito s vises do usurio individual, o nvel

ASPECTOS BSICOS DE BANCO DE DADOS

Os trs nveis da arquitetura.

Um exemplo tornar estas idias mais claras. A figura seguinte mostra

Interpretamos da seguinte maneira:

Banco de dados contm, no nvel conceitual, informaes

ASPECTOS BSICOS DE BANCO DE DADOS

DEPARTMENT-NUMBER (quatro caracteres) e um SALARY (cinco

Observao: Em um sistema relacional o primeiro nvel, o nvel

ASPECTOS BSICOS DE BANCO DE DADOS

Esta linguagem, para o programador de aplicao, pode ser