Introduc;ao a Sistemas de BANeOS DE DADOS

c. J. Date
Introdu~ao a Sistemas de BANeOS DE DADOS
Tradufiio.da 80 Edifiio Americana
Tradu~ao Daniel Vieira Revisao Tecnica Sergio Lifschitz
Professor do Departamento de Informatica da PUC-Rio

F# F1 F2 F3 F4 F5

FNOME Smith Jones Blake Clark Adams

STATUS 20 10 30 20 30

CIDADE Londres Paris Paris Londres Atenas

F# F1 F1 Fl F1 F1 Fl F2 F2 F3 F4 F4 F4

P# P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 P4 P5

QDE 300 200 400 200 100 100 300 400 200 200 300 400

P# P1 P2 P3 P4 P5 P6

PNOME Porea Pino Parafuso Parafuso Came Tubo

COR Vermelho Verde Azul Vermelho Azul Vermelho

PESO 12.0 17.0 17.0 14.0 12.0 19.0

CIDADE Londres Pari s Oslo Londres Paris Londres

F# F1 F2 F3 F4 F5

FNOME Smith Jones Blake Clark Adams

STATUS 20 10 30 20 30

C !DADE Londres Paris Paris Londres Atenas

P# P1 P2 P3 P4 P5 P6

PNOME Porea Pino Parafuso Parafuso Came Tubo

COR Vermelho Verde Azul Vermelho Azul Vermelho

PESO 12.0 17.0 17 .0 14.0 12.0 19.0

C !DADE Londres Paris Oslo Londres Paris Londres

J# J1 J2 J3 J4 J5 J6 J7

JNOME Classifieador Monitor OCR Console RAID EDS Fita

CIDADE Paris Roma Atenas Atenas Londres Oslo Londres

F# F1 F1 F2 F2 F2 F2 F2 F2 F2 F2 F3 F3 F4 F4 F5 F5 F5 F5 F5 F5 F5 F5 F5 F5

P# P1 P1 P3 P3 P3 P3 P3 P3 P3 P5 P3 P4 P6 P6 P2 P2 P5 P5 P6 P1 P3 P4 P5 P6

J# J1 J4 J1 J2 J3 J4 J5 J6 J7 J2 J1 J2 J3 J7 J2 J4 J5 J7 J2 J4 J4 J4 J4 J4

QDE 200 700 400 200 200 500 600 400 800 100 200 500 300 300 200 100 500 100 200 100 200 800 400 500

Restri<;:ao

Proje<;:ao

I,'

r;OdutO, CJ m
a a b b c c Diferen<;:a

x y x Y x y

Uniao

Interse<;:ao

Jun<;:ao(natural)

DiVlsao~

a1 a2 a3

b1 b1 b2

b1 b2 b3

c1 c2 c3

a1 a2 a3

b1 b1 b2

c1 c1 c2

a b c

a a a b c

x
y

~~

x
y

Sumario

Visao geral do gerenciamento

de bancos de dados 6

1.1 Introdu~ao 3 1.2 0 que e urn sistema de banco de dados?

0 que urn banco de dados? 10 Por que banco de dados? 15 Independencia de dad os 18 Sistemas relacionais e outros sistemas 1.7 Resumo 25 Exerdcios 26 Referencias e bibliografia 27 Arquitetura de sistemas de bancos de dados 1.3 1.4 1.5 1.6

23

28

2.1 Introdu~ao 28 2.2 Os tres nfveis da arquitetura 29 2.3 0 nfvel externo 31 2.4 0 nfvel conceitual 33 2.5 0 nfvel interno 34 2.6 Mapeamentos 35 2.70 administrador do banco de dados 35 2.8 0 sistema de gerenciamento de bancos de dados 2.9 Comunica~6es de dados 40 2.10 Arquitetura c1iente/servidor 41 2.11 Utilid.rios 43 2.12 Processamento distribufdo 43 2.13 Resumo 46 Exerdcios 47 Referencias e bibliografia 48 Introdu~ao aos bancos de dados relacionais

37

50 50

3.1 Introdu~ao 50 3.2 Uma olhada informal do modelo relacional 3.3 Rela~6es e RelVars 54 3.4 0 que significam as rela~6es 56 3.5 Otimiza~ao 58 3.60 catalogo 60 3.7 RelVars basicas e vis6es 61 3.8 Transa~6es 64

3.9 0 banco de dados de fornecedores 3.10 Resumo 67 Exercfcios 68 Referencias e bibliografia 69 Vma introduc;:iio

e pec;:as

65

a SQL

71

4.1 Introduc;:ao 71 4.2 Visao geral 72 4.3 0 cad.logo 74 4.4 Visoes 76 4.5 Transac;:oes 76 4.6 SQL embutida 76 4.7 SQL dinamica e SQL/CLI 82 4.8 A SQL nao e perfeita 85 4.9 Resumo 85 Exercfcios 86 Referencias e bibliografia 87

Tipos

95

5.1 introduc;:ao 95 5.2 Valores versus variaveis 96 5.3 Tipos versus representac;:oes 98 5.4 Definic;:ao de tipo 102 5.5 Operadores 104 5.6 Geradores de tipos 109 5.7 Recursos de SQL 110 5.8 Resumo 118 Exercfcios 118 Referencia e bibliografia 120 Re1ac;:oes

121

6.1 Introduc;:ao 121 6.2 Tuplas 121 6.3 Tipos de re1ac;:oes 125 6.4 Valores de relac;:oes 127 6.5 Variaveis de re1ac;:ao 134 139 6.6 Recursos de SQL 6.7 Resumo 144 Exercfcios 146 Referencias e bibliografia Algebra re1acional 7.1 7.2 7.3 7.4 7.5 7.6

150
152 154 156

Introduc;:ao 150 Vma revisao do fechamento A algebra original: sintaxe A algebra original: semantica Exemplos 164 Para que serve a algebra?

CONCEITOS BASICOS

0 Capitulo 1 define 0 cenario, explicando 0 que e urn banco de dados e por que os sistemas de bancos de dados saD desejaveis. Ele tambem explica resumidamente a diferen~a entre sistemas relacionais e outros sistemas. Em seguida, 0 Capitulo 2 apresenta uma arquitetura geral para os sistemas de bancos de dados, denominada arquitetura ANSI/SPARe. Essa arquitetura serve como uma estrutura sobre a qual 0 restante do livro sera montado. 0 Capitulo 3 apresenta uma visao geral a respeito dos sistemas relacionais (0 objetivo e servir como uma rapida introdu~ao as discuss6es muito mais abrangentes do mesmo assunto, na Parte II e em outras partes do livro). Ele tambem apresenta e explica 0 exemplo utilizado, 0 banco de dados de fornecedores e pe~as. Finalmente, 0 Capitulo 4 apresenta mente, SQL: 1999). a linguagem relacional padrao, denominada SQL (mais precisa-

CAPITULO

Visao geral do gerenciamento de bancos de dados

1.1 1.2 1.3 1.4 1.5 1.6 1.7

Introdus;ao 0 que 0 que

e urn e urn

sistema de banco de dados? banco de dados?

Por que banco de dados? Independencia de dados

Sistemas relacionais e outros sistemas Resumo Exercfcios Referencias e bibliografia

1.1INTRODUC;Ao
Um sistema de banco de dados e basicamente apenas um sistema computadorizado de manutenfiio de registros. 0 banco de dados, por si s6, pode ser considerado como 0 equivalente eletronico de urn armario de arquivamento; ou seja, ele e urn reposit6rio ou recipiente para uma cole<;iio de arquivos de dados computadorizados. Os usuarios de urn sistema podem realizar (ou melhor, solicitar que 0 sistema realize) diversas opera<;6es envolvendo tais arquivos - por exemplo: Acrescentar novos arquivos ao banco de dados

Inserir dados em arquivos existentes Buscar dados de arquivos existentes Excluir dados de arquivos existentes Alterar dados em arquivos existentes Remover arquivos existentes do banco de dados

A Figura 1.1 mostra urn banco de dados muito pequeno, con tendo apenas urn arquivo, chamado ADEGA, que, por sua vez, contem dados referentes ao conteudo de uma adega de vinhos. A Figura 1.2 mostra urn exemplo de uma requisi<;:ao de busca contra esse banco de dados, junto com os dados retornados por essa requisi<;:ao. (Por todo este livro, mostramos requisi<;:6es de banco de dados, nomes de arquivo e outros itens semelhantes em maiusculas, para maior clareza. Na pratica, geralmente e mais conveniente representar esses itens em minusculas. A maior parte dos sistemas ace ita as duas formas.) A Figura 1.3 oferece exemplos, todos mais ou menos auto-explicativos, de requisi<;:6es inser~ao, exclusao e altera~ao sobre 0 banco de dados da adega de vinhos. Alguns exemplos de acrescimo e remo<;:ao de arquivos inteiros sao dados em outros capftulos.

DEPH* 2 3 6 12 21 22 30 43 45 48 50 51 52 58 64 72

VINHO Chardonnay Chardonnay Chardonnay Joh. Riesling Fume Blanc Fume Blanc GewUrztraminer Cab. Sauvignon Cab. Sauvignon Cab. Sauvignon Pinot Noir Pinot Noir Pinot Noir Merlot Zinfandel Zinfandel

PRODUTOR Buena Vista Geyser Peak Simi Jekel Ch. St. Jean Robt. Mondavi Ch. St. Jean Windsor Geyser Peak Robt. Mondavi Gary Farrell Fetzer Dehlinger Clos du Bois Cline Rafanelli

ANO 2001 2001 2000 2002 2001 2000 2002 1995 1998 1997 2000 1997 1999 1998 1998 1999

GARRAFAS 1 5 4 1 4 2 3 12 12 12 3 3 2 9 9 2

PRONTO 2003 2003 2002 2003 2003 2002 2003 2004 2006 2008 2003 2004 2002 2004 2007 2007

Busca:
SELECT VINHO, DEPH, PRODUTOR FROM ADEGA WHERE PRONTO = 2004 ;

Cab. Sauvignon Pinot Noir Merlot

43 51 58

Wi ndsor Fetzer Clos du Bois

Inser~ao de novos dados:

INSERT INTO ADEGA ( DEPH, VINHO, PRODUTOR, ANO, GARRAFAS, PRONTO) VALUES ( 53, 'Pinot Noir', 'Saintsbury' , 2001, 6, 2005 ) ;

Exclusao de dados existentes:

DELETE FROM ADEGA WHERE DEPH
=

2 ;

Altera~ao de dados existentes:

UPDATE ADEGA SET GARRAFAS = 4 WHERE DEPH = 3 ;

1. Em primeiro lugar, as requisi~6es (tambem chamadas instrufoes, comandos ou operadores) SELECT, INSERT, DELETE e UPDATE nas Figuras 1.2 e 1.3 sao expressas em uma linguagem chamada SQL. Originalmente uma linguagem propria da IBM, SQL agora e urn padrao internacional, aceito por praticamente todo produto disponivel comercialmente; na verdade, 0 mercado estava totalmente dominado por produtos SQL quando este livro foi escrito. Logo, devido a sua importfmcia comercial, 0 Capitulo 4 apresenta uma visao geral do padrao SQL, e outros capitulos incluem uma se~ao chamada "Recursos da SQL", que des creve os aspectos desse padrao que sao pertinentes ao assunto do capitulo em questao. A proposito, 0 nome SQL significava originalmente Structured Query Language (linguagem de consulta estruturada) e se pronunciava como em "sequel" (siqual). Porem, agora que ela se tornou urn padrao, 0 nome e apenas urn nome - nao e oficialmente uma abreviatura para coisa alguma pronunciado oficialmente como "esse-que-ele". Adotaremos essa ultima pronuncia como padrao em todo 0 livro. 2. Observe, na Figura 1.3, que a SQL emprega a palavra-chave UPDATE com 0 significado especifico de "alterar". Esse fato pode causar confusao, pois 0 termo update (atualizar) tambem e usado para se referir aos ttes operadores INSERT, DELETE e UPDATE, consider ados como urn grupo. Neste livro, vamos distinguir entre os dois significados usando minusculas para 0 significado generico e maiusculas para fazer referencia especificamente ao operador UPDATE. A proposito, voce pode ter notado que agora usamos 0 termo operador e 0 termo operafdo. Estritamente falando, ha uma diferen~a entre os dois (a operafdo e aquilo realizado quando o operador e invocado); porem, em discuss6es informais, os termos costumam ser usados com 0 mesmo significado. 3. Em SQL, arquivos computadorizados como ADEGA, da Figura 1.1, sao chamados tabelas (por motivos obvios); as linhas desse tipo de tabela podem ser consideradas como registros do arquivo, e as colunas podem ser consideradas como os campos. Neste livro, usaremos a terminologia de arquivos, registros e campos quando estivermos falando de sistemas de bancos de dados em geral (em sua maioria, apenas nos dois primeiros capitulos); usaremos a terminologia de tabelas, linnas e colunas quando estivermos falando sobre sistemas SQL em particular. (E, quando chegarmos as discuss6es mais formais no Capitulo 3 e em outras partes do livro, usaremos outro conjunto de termos: relafoes, tuplas e atributos, em vez de tabelas, linhas e colunas.) 4. Com rela~ao a tabela ADEGA, por simplicidade, consideramos implicitamente que as colunas VINHO e PRODUTOR contem dados de strings de caracteres e que todas as outras colunas contern dados inteiros. Contudo, em geral, as colunas podem conter dados com qualquer complexidade. Por exemplo, poderiamos estender a tabela ADEGA para incluir outras colunas, como a segUlr:

ROTULO

(fotografia

do rotulo da garrafa de vinho)

CRITICA (texto da critic a de alguma revista de vinhos) MAPA (mapa mostrando de onde vem
0

vinho)
0

NOTAS (grava~ao de audio contendo

nossas proprias notas sobre

sabor)

e muitas outras coisas. Por motivos obvios, a maior parte dos exemplos neste livro envolve apenas tipos de dados muito simples, mas nao perea de vista 0 fato de que possibilidades mais exoticas sempre estao disponiveis. Examinaremos essa questao de tipos de dados de colunas com mais detalhes em outros capitulos (especialmente nos Capitulos 5,6,26 e 27). 5. A coluna DEP# de deposito constitui a chave primaria para a tabela ADEGA (0 que significa que nunca hayed duas linhas na tabela ADEGA com 0 mesmo valor de DEP#). Em determinadas figuras, usamos a linha dupla para indicar as colunas de chave primaria, como na Figura 1.1.

Urn Ultimo comentario para encerrar esta se~ao preliminar: embora uma compreensao deste capitulo e do seguinte seja necessaria para uma percep~ao completa dos recursos e das capacidades de urn sistema moderno de banco de dad os, nao podemos negar que 0 material e urn pouco abstrato e bastante seco em alguns aspectos (alem disso, ele tende a envolver uma grande quantidade de conceitos e termos que podem ser novos para voce). Nos Capitulos 3 e 4, voce encontrara urn material muito men os abstrato e, portanto, talvez mais inteligivel a primeira vista. Portanto, por enquanto, voce pode preferir apenas dar uma passada superficial nestes dois primeiros capitulos, relendo-os cuidadosamente mais tarde, quando se tornarem mais relevantes aos t6picos que estiverem sendo estudados. .

1.2 0 QUE

E UM

SISTEMA DE BANCO DE DADOS?

Repetindo 0 que dissemos na se~ao anterior, urn sistema de banco de dados e basicamente urn sistema computadorizado de manuten~ao de registros; em outras palavras, e urn sistema computadorizado cuja finalidade geral e armazenar informa~6es e permitir que as usuarios busquem e atualizem essas informa~6es quando as solicitar. As informa~6es em questao podem ser qualquer coisa que tenha algum significado ao individuo au a organiza~ao a que 0 sistema deve servir - ou seja, qualquer coisa que seja necessaria para auxiliar no processo geral das atividades de sse individuo ou dessa organiza~ao. A prop6sito, observe que tratamos os termos dados e informar;6es como sinonimos neste livro. Alguns autores preferem distinguir entre os do is, usando dados para se referir ao que realmente e armazenado no banco de dados, e informar;6es para se referir ao significado desses dados para determinado usuario. A distin~ao e claramente importante - tao importante que parece preferivel torna-Ia explicita, onde for apropriado, em vez de contar com uma diferencia<;;ao de certa forma arbitraria entre dois term os basicamente sinonimos. A Figura 1.4 e uma imagem simplificada de urn sistema de banco de dados. Como a figura no mostra, tal sistema envolve quatro componentes principais: dados, hardware, software e usuarios. Examinaremos esses quatro componentes resumidamente a seguir. Depois, discutiremos sobre cada urn deles com muito mais detalhes (exceto pelo componente do hardware, cujos detalhes estao, em sua maioria, alem do escopo deste livro).
Sistema de gerenciamento de bancos de dados (SGBD)

I~\

I~\

I~\
Programas de aplica~ao

I~\

[0 [0 [0 [0

Os sistemas de bancos de dad os estao disponiveis em maquinas que variam desde pequenos computadores de mao (hand-helds) ou computadores pessoais ate os maiores mainframes ou clusters de computadores de grande porte. Nem e preciso dizer que os recursos fornecidos por qualquer sistema sao determinados, ate certo ponto, pelo tamanho e pela potencia da maquina sendo utilizada. Particularmente, os sistemas em maquinas grandes ("sistemas grandes") costumam ser multiusudrios, enquanto os que estao em maquinas menores ("sistemas pequenos") tendem a ser de monousudrio. Urn sistema monousuario e urn sistema em que no maximo urn usuario pode acessar 0 banco de dados em determinado momento; urn sistema multiusuario e aquele em que muitos usuarios podem acessar 0 banco de dad os ao mesmo tempo. Conforme demonstrado pela Figura 1.4, neste livro, normalmente consideraremos 0 segundo casa, para generalizar; porem, na verdade, a distinc;:ao e irrelevante para a maioria dos usu<irios, pois urn objetivo dos sistemas multiusu<irios, em geral, e que cada usuario se comporte como se estivesse trabalhando com urn sistemas monousudrio. Os problemas especiais dos sistemas multiusuarios sao, principalmente, problemas internos ao sistema, e nao aqueles visiveis ao usuario (consulte a Parte IV deste livro, especialmente 0 Capitulo 16). Agora, e conveniente supor, por questao de simplicidade, que a totalidade dos dados no sistema esteja armazenada em urn unico banco de dados, e normalmente faremos tal suposic;:ao neste livro, ja que isso material mente nao afeta qualquer outra discussao a respeito do assunto. Na pratica, porem, poderia haver bons motivos, ate mesmo em urn sistema pequeno, para que os dados estejam divididos em varios bancos de dados distintos. Veremos alguns desses motivos mais adiante, no Capitulo 2 e em outros lugares. Portanto, de modo geral, os dados de urn banco de dados - pelo menos, em urn sistema grande - estarao integrados e tambem compartilhados. Conforme veremos na Sec;:ao 1.4, esses dois aspectos (integrac;:ao de dados e compartilhamento de dad os) representam uma vantagem importante dos sistemas de bancos de dad os nos ambientes "grandes", e a integrac;:ao de dados, pelo menos, pode ser significativa tambem em ambientes "pequenos". Naturalmente, tambem pode haver muitas outras vantagens, a serem discutidas mais adiante, ate mesmo no ambiente pequeno. Porem, primeiro vamos explicar 0 que significam os termos integrado e compartilhado: Por integrado, queremos dizer que 0 banco de dados pode ser considerado como uma unificac;:ao de varios arquivos que, de outro modo, seriam distintos, com a eliminac;:ao de qualquer redundancia parcial ou total entre esses arquivos. Por exemplo, determinado banco de dados poderia conter urn arquivo FUNCIONARIO, oferecendo nomes, enderec;:os, departamentos, salarios e outros itens sobre os funcionarios, e urn arquivo MA TRICULA, representando 0 recrutamento dos funcionarios em cursos de treinamento (veja a Figura 1.5). Agora suponha que, para executar 0 processo de administrac;:ao do curso de treinamento, seja necessario saber 0 departamento para cada aluno matriculado. Entao, e claro que nao e preciso incluir essa informac;:ao de forma redundante no arquivo MATRICULA, pois e1a sempre podera ser obtida atraves do arquivo FUNCIONARIO.

NOME

ENDERE~O

DEPARTAMENTO

SALARIO

NOME

CURsa

Por compartilhado, queremos dizer que 0 banco de dados pode ser compartilhado entre diferentes usu<irios, no sentido de que diferentes usuarios podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo ("acesso concorrente"). Tal compartilhamento, concorrente ou nao, em parte e uma conseqiiencia do fato de que 0 banco de dados e integrado. No exemplo da Figura 1.5, por exemplo, a informac;:ao do departamento no arquivo FUNCIONARIO geralmente seria compartilhada pelos usua-

rios no Departamento de Pessoal e pelos uswhios no Departamento de Treinamento. (Urn banco de dados que nao e compartilhado no sentido deste exemplo as vezes e considerado "pessoal" ou "especffico da aplica<;:ao".) Outra conseqiiencia dos fatos mencionados - que 0 banco de dad os e integra do e compartilhado - e que, normalmente, qualquer usuario s6 estara interessado em alguma parte pequena do banco de dados completo; alem do mais, as partes de diferentes usuarios poderao estar superpostas de varias maneiras. Em outras palavras, determinado banco de dados sera percebido por diferentes usuarios de diferentes maneiras. Na verdade, ate mesmo quando dois usuarios compartilham a mesma parte do banco de dados, suas vis6es dessa parte podem diferir bastante, em urn nivel detalhado. Esse ultimo ponto e discutido com muito mais detalhes na Se<;:ao1.5 e nos pr6ximos capitulos (especialmente no Capitulo 10). Teremos mais a dizer com rela<;:ao a natureza do componente de dados do sistema na Se<;:ao1.3.

II

Volumes de armazenamento secundario - normalmente, discos magneticos -, que san us ados para manter os dados armazenados, juntamente com os dispositivos de E/S (entrada/saida) associ ados (unidades de disco etc.), controladores de dispositivos, canais de E/S e assim por diante. Processador(es) de hardware e mem6ria principal associada, que san usados para dar suporte a execu<;:aodo software do sistema de banco de dados (veja na pr6xima subse<;:ao). sistema, pelos seguintes motivos, dentre oupor si mesmos; em segundo lugar, os problede banco de dados; em terceiro lugar, esses em outros volumes.

I!l

Este livro nao trata de muitos aspectos do hardware do tros: primeiro, esses aspectos formam urn t6pico importante mas encontrados nessa area nao san peculiares aos sistemas problemas ja foram exaustivamente investigados e descritos

Entre 0 banco de dados ffsico - ou seja, os dados fisicamente armazenados - e os usuarios do sistema existe uma camada de software, conhecida como gerenciador de banco de dados ou servidor de banco de dados ou, mais freqiientemente, como sistema de gerenciamento de bancos de dados (SGBD). Todas as requisi<;:6esde acesso ao banco de dados san tratadas pelo SGBD; os recursos esbo<;:ados na Se<;:ao1.1 para acrescentar e remover arquivos (ou tabelas), buscar dados e atualizar dados em tais arquivos ou tabelas, e assim por diante, san facilidades fornecidas pelo SGBD. Uma fun<;:aogeral fornecida pelo SGBD e, portanto, a de isolar os usuarios do banco de dados dos detalhes no nivel de hardware (assim como os sistemas de linguagens de programa<;:ao isolam os programadores de aplica<;:6es dos detalhes no nivel de hardware). Em outras palavras, 0 SGBD oferece aos usuarios uma visao do banco de dados urn tanto elevada acima do nivel de hardware, e ele admite opera<;:6es do usuario (como as opera<;:6es SQL, discutidas rapidamente na Se<;:ao1.1) que san expressas em termos dessa visao de nivel mais elevado. Discutiremos essa e outras fun<;:6esdo SGBD com muito mais detalhes no decorrer deste livro. Algumas observa<;:6es adicionais:
II

componente de software mais importante de todo 0 sistema, mas nao e 0 unico. Outros componentes incluem utilitarios, ferramentas de desenvolvimento de aplica<;:6es, recursos para auxiliar no projeto, geradores de relat6rios e (mais importante) 0 gerenciador de transar;oes ou monitor de TP (Transaction Processing - processamento de transa<;:6es). Consulte os Capitulos 2, 3 e, especialmente, 15 e 16, para ver uma descri<;:ao melhor desses componentes.
0

0 SGBD e, de longe,

0 termo SGBD tambem e usado para se referir genericamente

necedor em particular - por exemplo,
0

produto

a algum produto especffico de algum forDB2 Universal Database da IBM. 0 termo instancia

do SGBD, entao, costuma ser usado para se referir a c6pia espedfica de tal produto que esta sendo executada em determinada instala~ao de computador. Como voce certamente notara, as vezes e preciso distinguir cuidadosamente a diferen~a entre esses dois conceitos. Dito isso, e preciso saber que 0 pessoal da area frequentemente usa 0 termo banco de dados quando, na realidade, quer se referir ao SGBD (em qualquer urn dos sentidos explicados anteriormente). Aqui esta urn exemplo tfpico: "0 banco de dados do vendedor X superou 0 banco de dados do fornecedor Y por urn fator de dois para urn". Esse uso e incorreto e desaconselhavel, porem muito comum. (0 problema e que, se cha:narmos 0 SGBD de banco de dados, como sera chamado 0 pr6prio banco de dados? Cuidado, leitor!)

Consideramos

tres classes gerais (e urn tanto superpostas)

de usuarios:

Primeiro, ha os programadores de aplicac;:6es, responsaveis pela escrita de programas de aplica~6es de bancos de dados em alguma linguagem de programa~ao, como COBOL, PUI, C+ +, Java ou alguma linguagem de alto nfvel de "quarta gera~ao" (Consulte 0 Capftulo 2). Esses program as acessam 0 banco de dados emitindo a requisi~ao apropriada (normalmente, uma instru~ao SQL) ao SGBD. as programas propriamente ditos podem ser aplica~6es convencionais em batch, ou entao podem ser aplicac;:6es on-line, cuja finalidade e permitir que urn usuario final- veja no pr6ximo paragrafo - acesse 0 banco de dados interativamente (por exemplo, a partir de uma esta~ao de trabalho ou terminal on-line, ou de urn microcomputador). A maioria das aplica~6es modernas e do tipo on-line. Em seguida, existem os usmirios finais, que acessam 0 banco de dados interativamente, como ja dissemos. Determinado usuario final pode acessar 0 banco de dados por meio de uma das aplica~6es on-line mencionadas no paragrafo anterior, ou entao pode usar uma interface fornecida como parte integrante do software do sistema. Essas interfaces oferecidas pelo fornecedor SaG admitid<;1spor meio de aplica~6es on-line, mas essas aplica~6es SaGinternas (built-in), e nao escritas pelo usuario. A maior parte dos sistemas inclui pelo menos uma aplica~ao interna, chamada processador de linguagem de consulta, por meio do qual 0 usuario pode emitir requisi~6es ao banco de dados, como SELECT e INSERT, interativamente ao SGBD. SQL e urn exemplo dpico de uma linguagem de consult a de banco de dados. (A prop6sito, observe que 0 termo linguagem de consulta, embora comum, na realidade e mal utilizado, ja que 0 verbo "consultar" sugere apenas busca, enquanto as linguagens de consulta normalmente (mas nao sempre) of ere cern tambem opera~6es de atualiza~ao e outras. A maior parte dos sistemas tambem oferece outras interfaces intern as, em que os usuarios finais nao emitem requisi~6es espedficas ao banco de dados, como SELECT e INSERT, mas operam, por exemplo, escolhendo itens de urn menu ou preenchendo caixas em urn formulario. Essas interfaces acionadas por menus ou por formularios costumam ter urn usa mais facil para pessoas que nao possuem urn treinamento formal em TI (Tecnologia da Informa~ao; a abreviatura SI, Sistemas de Informa~ao, tambem e usada com 0 mesmo sentido). Por outro lado, interfaces acionadas por comandos - ou seja, linguagens de consulta - costumam exigir uma certa experiencia profissional em TI, embora talvez nao muita (obviamente, nao tanto quando e necessario para escrever urn programa em uma linguagem como COBOL). Novamente, uma interface acionada por comandos talvez seja mais flexfvel do que uma acionada por menus ou formularios, no sentido de que as linguagens de consulta normalmente incluem certos recursos que nao SaG admitidos por essas outras interfaces.
III

A terceira classe de usuarios, nao ilustrada na Figura 1.4, e 0 administrador de banco de dados, ou DBA (de Data Base Administrator). A descri~ao da fun~ao do administrador de banco de dad os - e da fun~ao de administrador de dados (muito importante) associada sera deixada para a Se~ao 1.4 e para 0 Capftu10 2 (Se~ao 2.7).

Isso encerra nossa descri~ao preliminar dos aspectos principais de urn sistema de banco de dados. Agora, vamos prosseguir discutindo essas ideias com mais detalhes.

1.3 0 QUE

E UM

BANCO DE DADOS?

Dados persistentes

E comum

referir-se aos dados em urn banco de dados como "persistentes" (embora, na verdade, nao persistam por muito tempo!). Por persistente, queremos sugerir intuitivamente que os dados desse banco de dados diferem em especie de outros dados mais efemeros, como dados de entrada, dados de saida, filas de trabalho, blocos de controle de software, instru\6es SQL, resultados intermediarios e, de modo geral, quaisquer dados que tenham natureza transitoria. Mais precisamente, dizemos que os dados no banco de dados "persistem" porque, uma vez aceitos pelo SGBD para entrada no banco de dados em primeiro lugar, eles s6 podem ser removidos do banco de dados mais tarde por alguma requisifdo explicita ao SGBD, e nao como urn mero efeito co lateral de (par exemplo) algum programa concluindo sua execu\ao. Essa no\ao de persistencia, assim, nos permite oferecer uma defini\ao urn pouco mais precisa para 0 termo banco de dados: Urn banco de dados terminada empresa.

e uma

cole\ao de dados persistentes,

usada pelos sistemas de aplica\ao

de uma de-

termo empresa, aqui, e simplesmente urn termo generico para qualquer organiza\ao comercial, cientifica, tecnica ou outra organiza\ao razoavelmente autonoma. Uma empresa poderia ser urn unico individuo (com urn pequeno banco de dados pessoal) ou uma corpora\ao ou grande empresa completa (com urn enarme banco de dados compartilhado), ou qualquer coisa entre esses extremos. Aqui estao alguns exemplos:

Qualquer empresa precisa necessariamente manter muitos dados sobre sua opera\ao. Esses dados san os "dados persistentes" a que nos referimos anteriormente. As empresas que mencionamos normalmente incluiriam os seguintes itens (respectivamente) entre seus dados persistentes:

1. Dados sobre produtos

2. Dados sobre contas

3. Dados sobre pacientes

4. Dados sobre alunos 5. Dados sobre planejamento Nota: As primeiras edi\6es deste livro usaram 0 termo dados operacionais no lugar de dados persistentes. 0 termo anterior refletia a enfase original em sistemas de bancos de dad os sobre aplica\6es operacionais ou de produ\ao - ou seja, aplica\6es de rotina altamente repetitivas, que eram executadas diversas vezes para dar suporte opera\ao do dia-a-dia da empresa (par exemplo, uma aplica\ao para dar suporte a depositos ou saques de dinheiro em urn sistema bancario). 0 termo processamento de transa\oes on-line (OLTP - On-Line Transaction Processing) tern sido usado para fazer referencia a essa especie de ambien-

te. Contudo, os bancos de dados agora sao cada vez mais usados tambem para outros tipos de aplica~6es por exemplo, aplica~6es de apoio a decisao - e 0 termo dados operacionais ja nao e mais inteiramente adequado. De fato, as empresas de hoje freqiientemente man tern dois bancos de dados separados, urn contendo dados operacionais e outro, normalmente chamado data warehouse, ':-contendo dados de apoio a decisao. 0 data warehouse geralmente inclui informar;;6es agregadas/sumdrias (por exemplo, totais, medias), extraidas periodicamente do banco de dados operacionaldigamos, uma vez por dia ou uma vez por semana. 0 Capitulo 22 contem uma discussao mais profunda sobre os bancos de dados e as aplica~6es de apoio a decisao.

Vamos considerar agora 0 exemplo de uma fabrica ("FazTudo Ltda.") mais detalhadamente. Uma empresa assim, normalmente desejara registrar informa~6es sobre os projetos em andamento; as per;;asusadas nesses projetos; os fornecedores que estao contratados para fornecer essas pe~as; os empregados que trabalham nesse projeto; e assim por diante. Assim, projetos, pe~as, fornecedores etc. constituem as entidades basicas sobre as quais a FazTudo Ltda. precisa registrar informa~6es (0 termo entidade normalmente e usado na area de banco de dados para indicar qualquer objeto distinguivel que deva ser representado no banco de dados). Veja a Figura 1.6.

Alem das entidades basicas propriamente ditas (fornecedores, pe~as etc., no exemplo), havera tambem relacionamentos interligando essas entidades basicas. Tais relacionamentos sao representados por losangos e linhas de conexao na Figura 1.6. Por exemplo, ha urn relacionamento ("FP" ou remessas) entre fornecedores e pe~as: cada fornecedor remete certas pe~as e, inversamente, cada pe~a e fornecida por certos fornecedores (mais precisamente, cada fornecedor remete certos tipos de pe~as, e cada tipo de pe~a e fornecido por certos fornecedores). De modo semelhante, as pe~as sao usadas em projetos, e os projetos usam pe~as (relacionamento PJ); as pe~as sao mantidas em armazens, e os armazens man tern pe~as (relacionamento AP); e assim por diante. Observe que esses relacionamentos sao todos bidirecionais - ou seja, eles podem ser percorridos em qualquer sentido. Por exemplo, 0 relacionamento FP, entre fornecedores e pe~as, pode ser usa do para solucionar as duas situa~6es a seguir: Dado urn fornecedor, obter as pe~as fornecidas por esse fornecedor que fornecem essa pe~a

Dada uma pe~a, obter os fornecedores

significativo a respeito desse relacionamento (e de todos os eles fazem parte dos dados tanto quanta as entidades bdsicas. Portanto, banco de dados, assim como as entidades basicas.1 Notamos de passagem que a Figura 1.6 e urn exemplo daquilo que diagram a de entidades e relacionamentos (diagrama E/R, para abreviar). esses diagramas com mais detalhes. A Figura 1.6 tambem ilustra varios outros pontos importantes:

o ponto

outros ilustrados na figura) e que eles devem ser representados no e chamado (por motivos 6bvios) No Capitulo 14, examinaremos

1. Embora a maior parte dos relacionamentos nessa figura envolva dois tipos de entidades - ou seja, eles san relacionamentos bindrios -, de modo algum podemos dizer que todos os re1acionamentos san binarios nesse sentido. No exemplo, existe urn re1acionamento ("FPJ") envolvendo tres tipos de entidade (fornecedores, pec,;ase projetos): urn relacionamento terndrio. A interpretac,;ao pretendida e que certos fornecedores remetem certas pec,;aspara certos projetos. Observe cuidadosamente que esse relacionamento ternario ("fornecedores remetem pec,;as a projetos"), em geral, nao e equivalente a combinac,;ao dos tres re1acionamentos binarios "fornecedores remetem pec,;as", "pec,;assan usadas em projetos" e "projetos san remetidos pelos fornecedores". Por exernplo, a afirmac,;a02 de que a. Smith fornece chaves inglesas para 0 projeto Manhattan e mais informativa que as tres dec1arac,;6es a seguir:

b. Smith fornece chaves inglesas c. Chaves inglesas san usadas no projeto Manhattan d. 0 projeto Manhattan e fornecido por Smith

Nao podemos (de forma valida!) deduzir a conhecendo apenas b, c e d. Mais precisamente, se soubermos b, c e d, podemos deduzir que Smith fornece chaves inglesas a algum projeto (digamos, o projeto ]z), que algum fornecedor (digamos, 0 fornecedor Fx) fornece chaves inglesas para 0 projeto Manhattan, e que Smith fornece alguma pec,;a(digamos, a pec,;aPy) ao projeto Manhattanmas nao podemos deduzir de modo valido que Sx e Smith ou que Py e chaves inglesas ou que]z e 0 projeto Manhattan. Deduc,;6es falsas como essas san exemplos do que algumas vezes se chama armadilha da conexao (connection trap). 2. A figura t~mbem rnostra urn re1acionamento (PP) envolvendo apenas um tipo de entidade (pec,;as). re1acionamento aqui que certas pec,;asinc1uem outras pec,;as como componentes imediatos (0 re1acionamento charnado lista de materiais - bill-of-rnaterials); por exemplo, urn parafuso e urn cornponente de uma dobradic,;a, que tarnbem e uma pec,;ae poderia ser urn componente de alguma outra pec,;ade nivel mais alto, como urna tampa. Observe que esse re1acionamento ainda e binario; simplesmente, os dois tipos de entidade envolvidos, pec,;as e pec,;as, san do mesmo tipo.

3. Em geral, determinado conjunto de tipos de entidades poderia estar envolvido em qualquer quantidade de re1acionamentos distintos. No exernplo da Figura 1.6, existem do is relacionamentos distintos envolvendo projeto e empregado: urn de1es (EJ) representa 0 fato de que os empregados san designados aos projetos, e 0 outro (GJ) representa 0 fato de que ernpregados gerenciam projetos.

lEspecificamente em urn banco de dados relacional (consulte a Se~ao 1.6), as entidades basicas e os relacionamenros que as conectam sac representados por meio de relar;;6esou, em outras palavras, por tabelas como a que mostramos na Figura 1.1, abertamente falando. Portanto, tenha 0 cui dado de observar que 0 termo relacionamento, usado nesta se~ao, e 0 termo relar;;iio,usado no contexto dos bancos de dados relacionais, nao tern 0 mesmo significado. 20 termo ingles statement, infelizmente, e usado no mundo do banco de dados para significar duas coisas bem diferentes: ele pode ser usado, como aqui, para indicar uma afirmar;;iio de um fato, ou 0 que os matematicos 16gicos chamam de proposir;;iio (veja na subse~ao "Dados e modelos de dados", mais adiante nesta se~ao); ele tambem pode ser usa do, como ja vimos nas discuss6es anteriores, como urn sinonimo para comando, como na expressao "instru~ao SQL" (SQL statement).

Agora, observamos que um relacionamento pode ser considerado uma entidade em si. Se tomarmos como nossa defini\ao de entidade "qualquer objeto sobre 0 qual queremos registrar informa\oes", entao urn relacionamento certamente se encaixad. na defini\ao. Por exemplo, "a pe\a P4 est;).armazenada no armazem AS" e uma entidade sobre a qual poderiamos muito bem querer registrar informa\6es - por exemplo, a quantidade correspondente. Alem disso, ha vantagens definidas (que estao alem do escopo deste capitulo) que podem ser obtidas se nao forem feitas distin\oes desnecessarias entre entidades e relacionamentos. Portanto, neste livro, tentaremos tratar os relacionamentos simplesmente como urn tipo especial de entidade.

Propriedades
Conforme explicamos, uma entidade e qualquer objeto sobre 0 qual que rem os registrar informa\oes. Por conseguinte, as entidades (incluindo os relacionamentos) podem ser consideradas como possuindo propriedades, correspondendo as informa\oes que queremos registrar a respeito delas. Por exemplo, os fornecedores possuem locais; as pe\as possuem pesos; os projetos possuem prioridades; atribui\oes (de empregados a projetos) possuem datas inicias; e assim por diante. Tais propriedades, portanto, precisam ser representadas no banco de dados. Por exemplo, urn banco de dados SQL poderia incluir uma tabela chamada F, representando fornecedores, e essa tabela poderia incluir uma coluna chamada CIDADE, representando os locais dos fornecedores. Em geral, as propriedades podem ser tao simples ou tao complexas quanto desejarmos. Por exemplo, a propriedade "local de fornecedor" e presumivelmente muito simples, consistindo apenas no nome de uma cidade, podendo ser representada no banco de dados como uma simples string de caracteres. Ao contrario, urn armazem poderia ter uma propriedade "planta baixa", e essa propriedade poderia ser muito complexa, contendo talvez urn desenho arquitet6nico inteiro, juntamente com 0 texto descritivo associado. Conforme indicamos na Se\ao 1.1, em outras palavras, os tip os de dados que poderfamos manter (por exemplo) nas co lunas de tabelas SQL podem ter qualquer nivel de complexidade. Como dissemos na mesma se\ao, retornaremos a esse assunto mais tarde (principal mente, nos Capitulos 5 -6 e 26-27); ate la, vamos considerar na maioria das vezes (onde fizer diferen\a) que as propriedades saG "simples" e que podem ser representadas por tipos de dados "simples". Alguns exemplos desses tipos "simples" incluem numeros, strings de caracteres, datas, horas etc.

Existe outra (e importante) maneira de pensar sobre 0 que saG realmente os dad os e os bancos de dados. A palavra dado vem da palavra latina datu, que corresponde a "dar"; portanto, dados SaGna realidade fatos dados, a partir dos quais podemos deduzir fatos adicionais. (Deduzir fatos adicionais a partir de fatos dados e exatamente 0 que 0 SGBD esta fazendo quando responde a uma consulta do usuario.) Por sua vez, urn "fato dado" corresponde ao que os matematicos chamam proposic;do verdadeira; por exemplo, a afirma\ao "0 fornecedor F1 esta localizado em Londres" pode ser uma proposi\ao verdadeira. (Uma proposi\ao, em logica, e algo que pode ser verdadeiro ou falso, inequivocamente. Por exemplo, "Jorge Amado escreveu 0 Guarani" e uma proposi\ao - falsa, nesse caso.) Concluimos que urn banco de dados e, na verdade, uma cole\ao de proposi~oes verdadeiras. Ja dissemos que os produtos SQL passaram a dominar 0 mercado. Uma razao pela qual isso acontece e que os produtos SQL saG baseados em uma teoria formal chamada modelo relacional de dados, e essa teoria, por sua vez, oferece suporte direto a interpreta\ao anterior de dados e bancos de dad os - na realidade, de forma quase trivial. Para ser espedfico, no modelo relacional: 1. Os dad os SaGrepresentados por meio de linhas em tabelas,3 e essas linhas podem ser interpretadas diretamente como proposi\6es verdadeiras. Por exemplo, a linha correspondente a DEP# 72, na Figura 1.1, pode ser interpretada de forma obvia como a seguinte proposi\ao verdadeira:

numero 72 contem duas garrafas de Rafanelli Zinfandel1999, servir em 2007.

o deposito

que estariio prontas para

2. Sao fornecidos operadores para a opera<;:ao sobre as linhas das tabe1as, e esses operadores admitem de forma direta 0 processo de dedu<;:ao de proposi<;:6es verdadeiras adicionais a partir das proposi<;:6esindicadas. Como urn exemplo simples, 0 operador re1acional de projer;iio (ver Se<;:ao1.6) nos permite deduzir, a partir da proposi<;:ao verdadeira que acabamos de citar, a seguinte proposi<;:ao verdadeira adicional, entre outras: Algumas garrafas de Zinfandel estariio prontas para servir em 2007. produzidas por algum

(Mais precisamente: "Algumas garrafas de Zinfande1 em algum deposito, produtor em algum ano, estarao prontas para servir em 2001".)

Porem, 0 modelo relacional nao e 0 unico modelo de dados; existem outros (ver Se<;:ao1.6) - embora a maioria de1es seja diferente do mode1o re1acional pelo fato de serem ad hoc, ate certo ponto, em vez de terem uma base salida, assim como 0 mode1o re1acional e baseado na logica formal. Nesse caso, surge a pergunta: em geral, 0 que urn mode1o de dados? Seguindo a referencia [1.1] (mas parafraseando bastante), podemos definir 0 conceito desta forma:

Urn modelo de dados e uma defini<;:aoabstrata, autonoma e 16gica dos objetos, operadores e outros elementos que, juntos, constituem a maquina abstrata com a qual os usuarios interagem. Os objetos nos permitem modelar a estrutura dos dados. as operadores nos permitem modelar seu comportamento.

Uma implementa~ao de urn determinado modelo de dados e uma representa<;:ao ffsica em uma maquina real dos componentes da maquina abstrata que, juntos, constituem esse modelo. Em resumo: 0 mode1o e aquilo que os usuarios tern de conhecer; a implementa<;:ao e aquilo que os usuarios nao precisam conhecer. Como podemos ver pela explica<;:ao anterior, a distin<;:ao entre modelo e implementa<;:ao e realmente apenas urn caso especial (urn caso especial muito importante) da distin<;:ao familiar entre logico e fisico. No entanto, infelizmente observamos que muitos dos sistemas de bancos de dados de hoje, mesmo aque1es que se anunciam.f:omo re1acionais, nao deixam essas distin<;:6es tao claras quanto deveriam. De fato, parece haver uma falta generalizada de conhecimento dessas distin<;:6es e da impordncia de faze-Ias. Como conseqiiencia, constantemente existe uma lacuna entre os principios de bancos de dados (a maneira como os sistemas de bancos de dados deveriam ser) e a pratica de bancos de dados (0 modo que e1es realmente saG). Neste livro, estaremos preocupados principalmente com os principios, mas, apenas como advertencia, voce deve estar ciente de que, por esse motivo, podera ter algumas surpresas, a maio ria de1as de natureza desagradave1, se e quando come<;:ar a usar urn produto comercial. Fechando esta se<;:ao,devemos mencionar 0 fato de que modelo de dados e outro termo empregado na literatura com dois significados bastante diferentes. 0 primeiro significado ja foi explicado. 0 segundo e 0 seguinte: Urn modelo de dados (segundo sentido) e um modelo dos dados persistentes de alguma empresa em particular (por exemplo, a fabrica FazTudo Ltda., descrita anteriormente nesta se<;:ao).A diferen<;:a entre os dois significados pode ser caracterizada desta maneira: Urn modelo de dados no primeiro sentido e como uma linguagem de programar;iio - embora seja uma linguagem urn tanto abstrata - cujas constru<;:6es podem ser usadas para resolver uma grande variedade de problemas especificos, embora nao tenham por si proprias nenhuma conexao direta com qualquer problema especifico. Urn mode1o de dados no segundo sentido e como urn programa especifico escrito nessa linguagem. Em outras palavras, urn mode1o de dados no segundo sentido utiliza os recursos fornecidos por algum mo-

delo no primeiro sentido e os aplica a algum problema espedfico. fao espedfica de algum modelo no primeiro sentido.

Ele pode ser considerado

uma aplica-

Neste livro, deste ponto em diante, 0 termo modelo de dados sera usado apenas no primeiro sentido, exceto quando houver instrU(;:oes explfcitas em contrario.

Por que usar urn sistema de banco de dados? Quais SaDsuas vantagens? Ate certo ponto, a resposta a essas questoes depende de 0 sistema em questao ser urn sistema monousuario ou multiusuario (ou entao, para ser mais preciso, existem numerosas vantagens adicionais no caso dos sistemas multiusuarios). Vamos considerar primeiro 0 caso do sistema monousuario. Voltemos mais uma vez ao exemplo da adega de vinhos (Figura 1.1), que podemos considerar ilustrativo do caso monousuario. Esse banco de dad os em particular e tao pequeno e tao simples que as vantagens podem nao ser muito 6bvias. Porem, imagine urn banco de dados semelhante para urn grande restaurante, com urn estoque de talvez milhares de garrafas na adega e mudan<;:as frequentes nesse estoque; ou, entao, imagine uma loja de bebidas, tambem com urn estoque muito grande e alta rotatividade nesse estoque. As vantagens de urn sistema de bancos de dados em rela<;:ao aos metod os tradicionais, baseados em papel, para manuten<;:ao de registros, talvez sejam mais faceis de observar nesses casos. Aqui estao algumas delas: Densidade: Nao ha necessidade de arquivos de papel, possivelmente volumosos.

Velocidade: A maquina pode obter e atualizar dados com rapidez muito maior que 0 ser humano. Em particular, consultas ad hoc, de inspira<;:ao momentanea (por exemplo, "Temos mais Zinfandel que Pinot Noir?"), podem ser respondidas com rapidez sem qualquer necessidade d;pesquisas manuais ou visuais demoradas. Menos trabalho mon6tono: Grande parte do tedio de manter arquivos mecanicas SaD sempre feitas com melhor qualidade por maquinas. Atualidade: Informa<;:oes precisas e atualizadas

a mao

e eliminada. As tarefas sob consulta.

estao disponfveis a qualquer momenta contra perda nao intencional

Protefao: Os dados podem ser mais bem protegidos

e acesso ilegal.

As vantagens anteriores se aplicam com intensidade ainda maior a urn ambiente multiusuario, no qual o banco de dados provavelmente sera muito maior e mais complexo que no caso do ambiente monousuario. Porem, ha uma vantagem adicional predominante em tal ambiente: 0 sistema de banco de dados proporciona a empresa 0 controle centralizado de seus dados (que, como voce deve ter percebido, e urn de seus bens mais valiosos). Tal situa<;:ao contrasta nitidamente com aquela encontrada em uma empresa sem urn sistema de banco de dad os, onde em geral cada aplica<;:ao tern seus pr6prios arquivos privados - muitas vezes tambem suas pr6prias fitas e seus discos privados - de modo que os dados ficam bastante dispersos e SaD diffceis de controlar de forma sistematica.

Administra~ao de dados e administra~ao de bancos de dados

Vamos aprofundar urn pouco esse conceito de controle centralizado. 0 conceito implica que havera na empresa alguma pessoa identificavel que tenha a responsabilidade central pelos dados, e essa pessoa e 0 administrador de dados (abreviado como DA - Data Administrator), mencionado brevemente final da Se<;:ao1.2. Tendo em vista que (repetindo) os dados constituem urn dos bens mais valiosos da empresa, e imperativo que deva existir alguma pessoa que entenda esses dados e as necessidades da empresa com rela<;:ao a esse dados, em um nivel elevado de administrafao. 0 administrador de dados e essa pessoa. Assim, e trabalho do administrador de dados decidir, para come<;:ar, que dados devem ser armazenados no banco de dados, alem de estabelecer normas para manter e tratar esses dados, uma vez que venham a

ser armazenados. Urn exemplo de tal norma seria a de determinar quem pode executar quais operas:oes sobre quais dados em que circunstancias - em outras palavras, uma norma de seguranr;ade dados (veja na proxima subses:ao). Observe atentamente que 0 administrador de dados e urn gerente, e nao urn tecnico (embora com certeza precise ter algum conhecimento dos recursos de sistemas de bancos de dados em urn nivel tecnico). 0 tecnico responsavel pela implementas:ao das decisoes do administrador de dados e 0 administrador de banco de dados (abreviado como DBA - Data Base Administrator). 0 DBA, diferente do administrador de dados, e urn profissional de tecnologia da informas:ao (TI). 0 trabalho do DBA e criar 0 banco de dados propriamente dito e implementar os controles tecnicos necessarios para por em pratica as diversas decisoes sobre normas tomadas pelo administrador de dados. 0 DBA tambem e responsavel por assegurar que o sistema operara com desempenho adequado e por oferecer varios outros servis:os tecnicos. 0 DBA normalmente tera uma equipe de programadores de sistemas e outros auxiliares tecnicos (isto e, a funs:ao do DBA normalmente sera executada na pratica por uma equipe, nao apenas por uma unica pessoa); contudo, por questao de simplicidade, e conveniente supor que 0 DBA seja de fato urn unico individuo. 0 Capitulo 2 discute com mais detalhes a funs:ao do DBA.

Vantagens da abordagem de banco de dados

Nesta subses:ao, identificaremos zado que acabamos de estudar. algumas vantagens especfficas que surgem da nos:ao de controle centrali-

as dados podem

ser compartilhados.

Discutimos esse topico na Ses:ao 1.2 mas, para manter tudo em urn so lugar, vamos menciona-Io novamente aqui. 0 compartilhamento significa nao apenas que as aplicas:oes existentes podem compartilhar os dados do banco de dados, mas tambem que podem ser desenvolvidas novas aplicas:oes para operar sobre os mesmos dados. Em outras palavras, seria possivel satisfazer aos requisitos de dados de novas aplicas:oes sem ter de acrescentar novos dados ao banco de dados.

A redundancia pode ser reduzida.

Em sistemas sem bancos de dados, cada aplicas:ao tern seus proprios arquivos privados. Esse fato pode constantemente levar a uma consideravel redundancia nos dad os armazenados, com 0 resultante desperdfcio no espas:o de armazenamento. Por exemplo, uma aplicas:ao de pessoal e uma aplicas:ao de registros de treinamento poderiam ambas possuir urn arquivo que incluisse informas:oes departamentais rderentes aos empregados. Porem, conforme sugerimos na Ses:ao 1.2, esses do is arquivos podem ser integrados, e a redundancia eliminada, desde que 0 administrador de dados esteja consciente dos requisitos de dados de ambas as aplicas:oes - ou seja, desde que a empresa detenha necessariamente 0 controle geral. possa ou deva necessariamente ser eliminada. As vezes, ha motivos comerciais ou tecnicos plausiveis para manter varias capias distintas dos mesmos dados. Porem, queremos sugerir que toda redundancia deve ser cuidadosamente controlada; isto e, 0 SGBD deve estar ciente dela (caso exista) e deve assumir a responsabilidade pela "propagas:ao de atualizas:oes" (veja 0 proximo item).

Nota: Nao queremos sugerir que toda redundancia

A inconsistencia pode ser evitada (ate certo ponto).

Na realidade, isso e urn corolario do topico anterior. Vamos supor que urn determinado fato sobre 0 mundo real - por exemplo, 0 fato de que 0 empregado E3 trabalha no departamento D8 - seja representado por duas entradas diferentes no banco de dados. Vamos supor tambem que 0 SGBD nao saiba dessa duplicas:ao (isto e, a redundancia nao esta controlada). Entao, havera necessariamente ocasioes em que as duas entradas nao combinarao: isto e, quando uma das duas tiver sido atualizada e a outra nao. Em tais ocasioes, diz-se que 0 banco de dados esta inconsistente (ou incoerente). E claro que urn banco de dados que se encontre em urn estado inconsistente tern a possibilidade de fornecer informas:oes incorretas ou contraditorias a seus usuarios.

Sem duvida, se 0 fato for representado par uma unica entrada (ou seja, se a redundancia for removida), entao tal inconsistencia nao podera ocorrer. Por outro lado, se a redundancia nao for removida, mas for controlada (tornando-se conhecida para 0 SGBD), 0 SGBD podera garantir que 0 banco de dados nunca se tornara inconsistente sob 0 ponto de vista do usudrio, garantindo que qualquer mudan~a feita em uma das duas entradas tambem sera aplicada de forma automatica a outra entrada. Esse processo e conhecido como propagac;ao de atualizac;6es.

0 suporte a transafoes pode ser fornecido.

Uma transac;ao e uma unidade l6gica de trabalho (mais precisamente, uma unidade l6gica de trabalho de banco de dados), em geral envolvendo diversas opera~6es de banco de dados - em particular, varias operac;6es de atualiza~ao. 0 exemplo padrao envolve a transferencia de uma quantia de dinheiro de uma conta A para outra conta B. E claro que san exigidas duas atualizac;6es nesse caso, uma para retirar o dinheiro da conta A, e outra para deposita-lo na conta B. Se 0 usuario declarar que as duas atualizac;6es san parte da mesma transac;ao, entao 0 sistema podera efetivamente garantir que ambas serao realizadas ou nenhuma delas - ainda que, par exemplo, 0 sistema venha a falhar (digamos, devido a uma queda de energia) em meio ao processo. Nota: A caracteristica de atomicidade de uma transac;ao, que acabamos de ilustrar, nao e a unica vantagem do suporte a transa~6es mas, diferente de alguns outros, e a unica que se aplica mesmo no caso monousuario. (Por outro lado, os sistemas monousuarios normalmente nao of ere cern suporte a transac;6es, mas simplesmente deixam 0 problema para 0 usuario.) Uma descric;ao completa das diversas vantagens do suporte a transa~6es e de como elas podem ser alcan~adas sera vista nos Capitulos 15 e 16. A integridade pode ser mantida. da integridade e 0 problema de assegurar que os dados no banco de dados estao corretos. A inconsistencia entre duas entradas que deveriam representar 0 mesmo "fato"'eum exemplo de falta de integridade (veja a discussao desse ponto no inicio desta subsec;ao); e claro que este problema especifico s6 podera surgir se houver redundancia nos dados armazenados. Contudo, mesmo que nao haja qualquer redundancia, 0 banco de dados ainda podera conter informac;6es incorretas. Por exemplo, urn empregado poderia ser mostrado como tendo trabalhado 400 horas na seman a em vez de 40, ou como pertencendo a urn departamento que nao existe. 0 controle centralizado do banco de dados pode ajudar a evitar tais problemas - a medida que eles possam ser evitados - permitindo ao administrador de dad os definir, e ao DBA implementar, restric;6es de integridade a serem verificadas sempre que for executada alguma opera~ao de atualiza~ao. Vale a pena observar que a integridade de dados e ainda mais importante em urn sistema de banco de dados que em urn ambiente de "arquivos privados", exatamente porque os dados san compartilhados. Sem a existencia de controles apropriados, seria possivel urn usuario atualizar 0 banco de dados de forma incorreta, gerando assim dados errados e "infectando" desse modo outros usuarios inocentes desses dados. Tambem devemos mencionar que a maioria dos produtos de bancos de dados atuais e bastante fraca em seu suporte a restri~6es de integridade (embora tenham ocorrido alguns avan~os recentes nessa area). Esse fato e desastroso, considerando-se que (como veremos no Capitulo 9) as restri~6es de integridade san ao mesmo tempo fundamentais e de importancia crucial - na verdade, muito mais do que se costuma supor. A seguranfa pode ser reforfada. Tendo jurisdic;ao completa sobre 0 banco de dados, 0 DBA (sob orientac;ao apropriada do administrador de dados) pode assegurar que 0 unico meio de acesso ao banco de dados seja atraves dos canais apropriados e, em consequencia, pode definir restric;6es de seguranc;a a serem verificadas sempre que houver uma tentativa de acesso a dados confidenciais. Podem ser estabelecidas diferentes restric;6es para cada tipo de acesso (busca, inser~ao, exclusao etc.) a cada item de infarma~ao no banco de dados. Todavia, observe que, sem tais restri~6es, a seguran~a dos dados podera carrer urn risco maiar que em

o problema

urn sistema tradicional de arquivos (dispersos); ou seja, a natureza centralizada de urn sistema de banco de dados de certo modo exige que urn born sistema de seguran~a tambem seja implantado. Requisitos contradit6rios podem ser equilibrados.

Conhecendo os requisitos globais da empresa, em oposi~ao aos requisitos de uswirios individuais, 0 DBA (mais uma vez sob a orienta~ao do administrador de dados) pode estruturar 0 sistema de modo a oferecer urn servi~o global que seja "0 melhor para a empresa". Par exemplo, pode ser escolhida uma representa~ao ffsica para os dados no meio de armazenamento que proporcione acesso rapido para as aplica~6es mais importantes (possivelmente ao custo de acesso mais lento para outras aplica~6es).

as padroes

podem ser impostos.

Com 0 controle central do banco de dad os, 0 DBA (de novo sob a orienta~ao do administrador de dados) pode garantir que todos os padr6es aplicaveis sejam observados na representa~ao dos dados, incluindo qualquer urn ou todos os seguintes: padr6es departamentais, da instala~ao, da empresa, do mercado, nacionais e internacionais. A padroniza~ao da representa~ao dos dados e particularmente desejavel como auxflio ao intercambio de dados, ou a migra~ao de dados entre sistemas (essa considera~ao esta se tornando especialmente importante com 0 advento dos sistemas distribuidos - consulte os Capitulos 2,21 e 27). Da mesma forma, os padr6es de nomenclatura e documenta~ao de dados tambem saD muito desejaveis como auxflio ao compartilhamento e a compreensao dos dados. A maiar parte das vantagens aqui citadas provavelmente e bastante 6bvia. Porem, urn outro ponto, que pode nao ser tao 6bvio (embora, na verda de, seja urn fato implfcito em varios outros), deve ser acrescentado a lista: a provisao da independencia de dados. (Estritamente falando, esse e urn objetivo para os sistemas de bancos de dad os, mais que necessariamente uma vantagem.) 0 conceito de independencia de dados e tao importante que dedicamos a de uma se~ao separada.

Come~amos por observar que existem dois tipos de independencia de dados, ffsica e l6gica [1.3, 1.4]; par enquanto, porem, estaremos preocupados somente com 0 tipo ffsico. Assim, ate notifica~ao adicional, 0 termo "independencia de dados" nao qualificado deve ser entendido especificamente como independencia de dados ffsica. (Talvez devamos dizer tambem que 0 termo independencia de dados nao e muito adequado - de nao reflete muito bem a essencia do que esta realmente acontecendo -, mas e 0 termo usado tradicionalmente, e 0 manteremos neste livro.) A independencia de dados pode ser compreendida mais facilmente considerando-se primeiro seu oposto. Aplica~6es implementadas em sistemas mais antigos - sistemas pre-relacionais ou mesmo sistemas anteriores aos bancos de dados - costumam ser dependentes de dados. Isso significa que a maneira como os dados saD representados fisicamente no meio de armazenamento secundario, bem como a tecnica usada para obter acesso a eles saD ambas determinadas pelos requisitos da aplica~ao que esta sendo considerada e, acima de tudo, que 0 conhecimento dessa representarsao {isica e dessas tecnicas de acesso estd embutido no c6digo da aplicafao. Por exemplo, vamos supor que temos uma aplica~ao que utiliza 0 arquivo EMPREGADO da Figura 1.5, e tambem que decidimos, par motivos de desempenho, que 0 arquivo deve ser indexado sobre seu campo "nome do empregado" (ver Apendice D, on-line). Em urn sistema mais antigo, a aplica~ao em questao normalmente estara ciente do fato de que 0 indice existe, e tambem ciente da seqliencia de registros definida por esse indice, e a estrutura interna da aplica~ao sera elaborada em torno desse conhecimento. Em particular, a forma exata das divers as rotinas de acesso a dados e tratamento de exce~6es dentro da aplica~ao dependera bastante dos detalhes da interface apresentada a aplica~ao pelo software de gerenciamento de dad os. Dizemos que uma aplica~ao como a deste exemplo e dependente de dados, porque e impossivel mudar a representa~ao ffsica (0 modo como os dados saD representados fisicamente no meio de armazenamento) ou a tecnica de acesso (0 modo como ocorre 0 acesso ffsico aos dados) sem afetar a aplica~ao, provavel-

mente de forma drastica. Por exemplo, nao seria possivel substituir 0 indice no exemplo por urn esquema de hashing sem efetuar modificac;:oes importantes na aplicac;:ao. Mais ainda, as partes da aplicac;:ao que exigirao alterac;:oes em tal situac;:ao serao exatamente aquelas que se comunicam com 0 software de gerenciamento de dados; as dificuldades envolvidas sao bastante irrelevantes para 0 problema sobre 0 qual a apliac;:aofoi escrita originalmente para resolver - ou seja, sao dificuldades introduzidas pela natureza da inerface de gerenciamento de dados. Contudo, em urn sistema de bancos de dados, seria extremamente indesejavel permitir que as aplica:oes fossem dependentes de dados no sentido anterior, pelo menos por estas duas razoes:

1. Aplicac;:oes diferentes exigirao visoes diferentes dos mesmos dados. Por exemplo, vamos supor
que antes da implantac;:ao pela empresa de seu banco de dados integrado, existissem duas aplicac;:oes(A e B), cada qual com urn arquivo privativo inc1uindo 0 campo "saldo do c1iente". No entanto, suponha que a aplicac;:ao A armazene esse campo em formato decimal, enquanto a aplicac;:ao B 0 armazena em binario. Ainda sera possivel integrar os do is arquivos e eliminar a redundancia, desde que 0 SGBD esteja pronto e seja capaz de executar todas as conversoes necessarias entre a representac;:ao armazenada escolhida (que, novamente, poderia ser a representac;:ao decimal, binaria ou outra qualquer) e a forma na qual cad a aplicac;:ao deseja ver 0 campo. Por exemplo, se for decidido armazenar 0 campo em formato decimal, entao to do acesso por B exigira uma conversao de ou para binario. Esse e urn exemplo bastante simples de uma diferenc;:a que poderia existir em urn sistema de banco de dados, entre os dados vistos por uma determinada aplicac;:ao e a forma como os dados es60 fisicamente armazenados. Consideraremos muitas outras diferenc;:as possiveis mais adiante nesta sec;:ao. 2. 0 DBA - ou, possivelmente, 0 SGBD - deve ter liberdade para alterar a representac;:ao fisica ou a tecnica de acesso em resposta a mudanc;:as nos requisitos, sem ter de moditicar aplicac;:oes existentes. Por exemplo, novos tipos de dad os poderiam ser acrescentados ao banco de dados; novos padroes poderiam ser adotados; as prioridades das aplicac;:oes (e, portanto, os requisitos relativos de desempenho) poderiam mudar; novos dispositivos de armazenamento poderiam se tomar disponiveis; e assim por diante. Se as aplicac;:oes forem dependentes de dados, em geral tais modificac;:oes exigirao que sejam feitas mudanc;:as correspondentes no c6digo dos programas, amarrando os esforc;:os de programadores que de outra forma ficariam disponiveis para a criac;:ao de novas aplicac;:oes. Mesmo hoje, nao e incomum verificar que uma frac;:aosignificativa do esforc;:o de programac;:ao disponivel e dedicado a essa especie de manutenc;:ao (pense em to do 0 trabalho realizado para resolver 0 problema do "Ano 2000") - urn evidente desperdicio de recursos escassos e valiosos. T emos, entao, que a provisao de independencia de dad os e urn objetivo importante dos sistemas de _ ---'1 os de dados. A independencia de dados pode ser definida como a imunidade das aplicac;:oes a altera~i>esna representac;:ao flsica e na tecnica de aces so - 0 que significa que as aplicac;:oes envolvidas nao de:;:=:ldam de qualquer representac;:ao fisica ou tecnica de acesso espedfica. No Capitulo 2, descrevemos oa arquitetura para sistemas de bancos de dados que fornece uma base para se alcanc;:ar esse objetivo. Po:Ln antes disso, vamos considerar com mais detalhes alguns exemplos dos tipos de alterac;:oes que 0 DBA ~ e querer fazer e as quais, portanto, desejarfamos que as aplicac;:oes fossem imunes. Comec;:amos por definir tres termos: campo armazenado, registro armazenado e arquivo armazenado -.-~rFigura 1.7). Urn campo armazenado e, informalmente, a menor unidade de dados armazenados. 0 banco de dados contera muitas ocorrencias (ou instancias) de cada urn dos varios tipos de campos armazenados. Por exemplo, urn banco de dados contendo informac;:oes sobre diferentes tipos de pec;:as provavel;:nente inc1uiria urn tipo de campoarmazenado chamado "numero da pec;:a", e haveria entao uma o orrencia de sse campo armazenado para cada especie de pec;:a (parafuso, dobradic;:a, tampa etc.).

Qutros arquivos armazenados Arquivo armazenado nQ da nome pe9a da pe9a de "pe<;:as" cor da pe9a peso da pe9a

~
Duas ocorrencias do tipo de registro Qcorrencias armazenado "pe<;:a"

" \ \ t t \ \ \
~
nQ da pe9a nome da pe9a cor da pe9a

de campos armazenados

peso da pe9a

Nota: Na pratica, apesar do paragrafo anterior, e comum que se abandone os qualificadores tipo e ocorrencia e que se confie no contexto para indicar 0 que se deseja dizer. Embora exista urn pequeno risco de confusao, 0 habito e conveniente e nos 0 adotaremos em varios pontos deste livro. (Esses comentarios tambem se aplicam aos registros armazenados - consulte 0 paragrafo imediatamente a seguir.) Urn registro-armazenado e uma cole<;:aode campos arrnazenados, relacionados entre si. De novo distinguimos entre tipo e ocorrencia. Uma ocorrencia (ou instancia) de registro armazenado consiste em urn grupo de ocorrencias de campos armazenados relacionados entre si. Por exemplo, uma ocorrencia de registro arrnazenado no banco de dados de "pe<;:as" poderia consistir em uma ocorrencia de cada urn dos seguintes campos armazenados: numero da pe<;:a,nome da pe<;:a,cor da pe<;:ae peso da pe<;:a.Dizemos que 0 banco de dados contem muitas ocorrencias do tipo de registro armazenado "pe<;:a" - novamente, uma ocorrencia para cada tipo diferente de pe<;:a. Finalmente, urn arquivo armazenado e a cole<;:ao de todas as ocorrencias atualmente existentes de urn unico tipo de registro armazenado. (Por questiio de simplicidade, consideramos que qualquer arquivo armazenado contenha apenas urn tipo de registro arrnazenado. Essa simplifica<;:ao nao afeta de forma substancial quaisquer de nossas discuss6es subseqiientes.) Em sistemas que nao saD bancos de dados, geralmente acontece de algum registro 16gico, visto por algum a aplica<;:ao, ser identico a algum registro armazenado correspondente. Entretanto, como ja vimos, isso nao necessariamente acontece em urn sistema de banco de dad os, porque 0 DBA poderia ter a necessidade de efetuar mudan<;:as na representa<;:ao dos dados armazenados - isto e, nos campos, registros e arquivos armazenados -, enquanto os dados vistos pelas aplica<;:6es nao se alterarn. Por exemplo, 0 campo SALARIO do arquivo EMPREGADO poderia ser armazenado em binario para economizar espa<;:ode ar-

mazenamento, ao passo que determinada aplicas;ao COBOL poderia ve-Io como uma string de caracteres. Alem disso, mais tarde 0 DBA poderia decidir alterar, por algum motivo, a representas;ao armazenada desse campo, digamos, de binaria para decimal, e ainda assim permitir que a aplicas;ao COBOL 0 veja sob a forma de caracteres. Como ja foi dito, uma diferens;a como essa - envolvendo conversao de tipo de dados em determinado campo a cada aces so - e relativamente pequena. Contudo, em geral a diferens;a entre aquilo que a aplicas;ao ve e 0 que esta realmente armazenado po de ser consideravel. Para amp liar essa observas;ao, apresentamos a seguir uma lista de aspectos da representas;ao armazenada que poderiam estar sujeitos a alteras;6es. Voce deve considerar em cada caso 0 que 0 SGBD teria de fazer para tomar as aplicas;6es imunes a tal mudans;a (e, de fato, se tal imunidade sempre podera ser alcans;ada). Representaqao de dados numericos. Urn campo numerico poderia ser armazenado em urn formato aritmetico interno (por exemplo, decimal compactado) ou como uma string de caracteres. De qualquer forma, 0 DBA precisa escolher se usara ponto fixo ou ponto flutuante; uma base ou raiz apropriada (por exemplo, binaria ou decimal); uma precisao (urn numero de dfgitos); e, se for ponto fixo, 0 fator de escala (numero de dfgitos apos 0 ponto decimal). Quaisquer desses aspectos podem pre cisar ser alterados para melhorar 0 desempenho ou para se adaptar a urn novo padrao, ou ainda por muitos outros motivos. Representaqao de dados de caracteres. Urn campo de string de caracteres poderia ser armazenado usando-se qualquer urn dentre varios conjuntos de caracteres codificados distintos - por exemplo, ASCII, EBCDIC ou Unicode. Unidades para dados numericos. As unidades em urn campo numerico poderiam mudar - por exemplo, de polegadas para centfmetros, durante urn processo de conversao para 0 sistema metrico. Codificaqao de dados. Em algumas situas;6es, poderia ser desejavel representar dados armazenados por val ores codificados. Por exemplo, 0 campo "cor da pes;a", que uma aplicas;ao ve como urn string de caracteres ("Vermelho" ou "Azul" ou "Verde" ...), poderia ser armazenado como urn unico dfgito decimal, interpretado de acordo com 0 esquema de codificas;ao: 1 = "Vermelho", 2 = "Azul", e assim por diante. Materializaqao de dados.

Na pratica, 0 campo l6gico visto por uma aplicas;ao correspondera em geral a algum campo armazenado especffico (embora, como ja vimos, pudessem existir diferens;as no tipo de dados, na codificas;ao, e assim por diante). Nesse caso, 0 processo de materializaqao - ou seja, a crias;ao de uma ocorrencia do campo logico a partir de uma ocorrencia do campo armazenado correspondente e sua apresentas;ao a aplicas;ao - pode ser considerado direto. As vezes, porem, urn campo logico nao ted uma correspondencia armazenada unica; em vez disso, seus valores serao materializados por meio de algum calculo, talvez sobre diversas ocorrencias de campos armazenados. Por exemplo, valores do campo logico "quantidade total" poderiam ser materializados pela totalizas;ao de uma serie de quantidades armazenadas individuais. No caso, 0 processo de materializas;ao e chamado indireto. Estrutura de registros armazenados. Dois registros armazenados nados: poderiam ser combinados em urn

so. Por

exemplo,

os registros armaze-

no da pe~a

cor

da pe~a

no da pe~a

peso

da pe~a

~n_o_d_a_pe_<;_a __

cor da pe<;a

peso da pe<;a

Tal mudans;a pode ocorrer a medida que aplicas;oes existentes saG integradas ao sistema de banco de dados. Ela implica que 0 registro l6gico de uma aplicas;ao poderia consistir em urn subconjunto apropriado do registro armazenado correspondente - isto e, certos campos nesse registro armazenado seriam invisiveis para a aplicas;ao em questao. Como alternativa, urn unico tipo de registro armazenado poderia ser dividido em dois. Invertendo-se 0 exemplo anterior, 0 registro armazenado:

no da pe<;a

cor da pe<;a

peso da pe<;a

no da pe<;a

cor da pe<;a

no da pe<;a

I peso da pe<;a I

Essa divisao permitiria, por exemplo, que partes do registro original utilizadas com menos frequencia fossem armazenadas em urn dispositivo mais lento. A implicas;ao e que 0 registro l6gico de determinada aplicas;ao poderia conter campos de diferentes registros armazenados - ou seja, seria urn superconjunto apropriado de qualquer urn desses registros armazenados . Estrutura de arquivos armazenados. Urn determinado arquivo armazenado pode ser implementado fisicamente no meio de armazenamento de varias maneiras diferentes (ver Apendice D, on-line). Por exemplo, ele poderia estar inteiramente contido em urn unico volume de armazenamento (urn unico disco, por exemplo), ou estar espalhado entre diversos volumes (possivelmente, em varios tipos diferentes de dispositivos); ele poderia estar ou nao em sequencia ffsica, de acordo com os valores de algum campo armazenado; poderia estar ou nao em sequencia de urn ou mais modos adicionais, por algum outro meio (por exemplo, por urn ou mais indices, ou por uma ou mais cadeias de ponteiros embutidos, ou ambos); poderia estar ou nao acessivel por meio de algum esquema de hashing; os registros armazenados poderiam ou nao estar agrupados fisicamente em blocos; e assim por diante. Contudo, nenhuma dessas consideras;oes deve afetar de forma alguma as aplicas;oes (a nao ser quanto ao desempenho, e claro). Isso conclui nossa lista de aspectos da representas;ao dos dados armazenados que estao sujeitos a possiveis modificas;oes. Observe que a lista implica (entre outras coisas) que 0 banco de dad os deveria ser capaz de crescer sem afetar as aplicas;oes existentes; na verdade, permitir que 0 banco de dados cress;a sem prejudicar logicamente as aplicas;oes existentes uma das razoes mais importantes para se exigir a independencia dos dados em primeiro lugar. Por exemplo, deve ser possivel estender urn registro armazenado existente pela adis;ao de novos campos armazenados, em geral representando informas;oes adicionais relativas a algum tipo de entidade existente (por exemplo, urn campo "custo unitario" poderia ser acrescentado ao registro armazenado de "pes;as"). Esses novos campos devem simplesmente ser invisiveis para as aplicas;oes existentes. Do mesmo modo, deve ser possivel acrescentar tip os de registros armazenados inteiramente novos e, em consequencia, novos arquivos armazenados, mais uma vez sem exigir qualquer mudans;a nas aplicas;oes existentes; esses novos registros e arquivos representariam novos tipos de entidades (por exemplo, urn tipo de registro "fornecedor" poderia ser acrescentado ao banco de dados de "pes;as"). De novo, tais inclusoes devem ser invisiveis para as aplicas;oes existentes. Por tudo isso, voce deve ter percebido que a independencia de dados e uma das razoes pelas quais a separas;ao do modelo de dados de sua implementas;ao, conforme discutimos ao final da SeS;ao 1.3, tao importante: se nao fizermos essa separas;ao, nao conseguiremos a independencia de dados. A opS;ao generalizada de deixar de fazer a separas;ao de maneira apropriada, particularmente nos sistemas SQL de hoje e, portanto, particularmente infeliz. Nota: Nao estamos sugerindo, com esses comentarios, que os sistemas SQL atuais nao fornecem independencia de dados - mas apenas que eles of ere cern

muito menos do que os sistemas re1acionais ::>alavras, a independencia de dados nao e urn :es graus, e poucos - se houver algum - nao a uais of ere cern mais que os sistemas antigos, . roximos capitulos.

san teoricamente capazes de proporcionar.4 Em outras valor absoluto; sistemas distintos a of ere cern em diferenproporcionam independencia alguma. Os sistemas SQL mas ainda estao longe da perfei~ao, como veremos nos

"Jissemos que os sistemas SQL vieram a dominar 0 mercado dos SGBDs e que urn motivo importante para .' 0 e que tais sistemas san baseados no modelo relacional dos dados. Informalmente, de fato, os sistemas -QL normalmente san considerados especificamente como sistemas relacionais.5 Mais que isso, a grande .aioria das pesquisas sobre bancos de dados ao longo dos ultimos trinta an os tambem se baseou (embora :.l:l1 tanto indiretamente, em alguns cas os) nesse mode1o. De fato, a introdu~ao do mode1o re1acional em 69-1970 foi sem duvida 0 evento mais importante em toda hist6ria da area de bancos de dados. Por esraz6es, alem da razao adicional de que 0 mode1o re1acional se baseia solidamente na logica e na mate atica e, por conseguinte, fornece urn vekulo ideal para 0 ensino de prindpios de bancos de dados, a ene neste livro esta fortemente concentrada nos sistemas re1acionais. Entao, 0 que e exatamente urn sistema relacional? E obvio que nao e possivel responder completamen: a essa pergunta neste ponto inicial do livro - mas e possive1 e desejave1 dar uma resposta urn tanto vaga, ue mais tarde podera se tornar mais precisa. De modo abreviado (e informal), urn sistema re1acional e .::.uele no qual:

:a

1. Os dados san percebidos

pe10 usuario como tabelas (e nada alem de tabe1as).

2. Os operadores a disposi~ao do usuario (por exemplo, para busca de dados) san operadores que geram tabelas "novas" a partir de tabelas "antigas". Por exemplo, ha urn operador restrifao * para extrair urn subconjunto das linhas de uma dada tabela, e outro operador, projefao, que extrai urn subconjunto das colunas - e, e claro, urn subconjunto de linhas e urn subconjunto de colunas de uma tabe1a podem ambos, por sua vez, ser considerados tabelas, conforme veremos em breve. Logo, por que tais sistemas san chamados "re1acionais"? A razao e que 0 termo relafao e essencialmenpenas urn termo mate matico para designar uma tabela. (De fato, os term os relafao e tabela podem ser ~ !1 iderados sinonimos, pe10 menos para propositos informais. Consulte os Capitulos 3 e 6 para examiuma discussao adicional.) Talvez devamos acrescentar que a razao definitivamente nao e que 0 termo ~ .1 ,ao seja "essencialmente apenas urn termo matematico para" urn relacionamento, no sentido dos dia.::-a.llas de entidades e relacionamentos (ver Se~ao 1.3); de fato, como observamos naque1a se~ao, existe =:1' 0 pouca conexao entre os sistemas re1acionais e tais diagramas. Conforme prometemos, tornaremos as defini~6es anteriores muito mais precisas adiante mas, por ento, e1as servirao. A Figura 1.8 fornece uma ilustra~ao. Os dados - veja a parte a da figura - consistem __ ma unica tabe1a, chamada ADEGA (na verdade, e1a e uma versao em escala menor da tabela ADEGA ..:.2 Figura 1.1, reduzida em tamanho para torna-la mais tacil de representar). Dois exemplos de buscas, urn envolvendo uma opera~ao de restrifao ou defini~ao de urn subconjunto de linhas e 0 outro uma ope-~:' 0 de projefao ou defini~ao de urn subconjunto de colunas, san mostrados na parte b da figura. Mais - yez, os exemplos san expressos em SQL.

';:: exemplo impressionante daquilo que os sistemas relacionais SaD capazes de fazer em rela"iio a isso e descrito no Apendice A. r do fato de que, em muitos aspectos, a SQL e not6ria por seus desvios do modelo relacional, conforme veremos . . '_:J do revisor tecnico: Operador tambem conhecido como SELE<::Ao.

-'--=~ -

a. Tabela dado:

ADEGA

VINHO Zinfandel Fume Blanc Pinot Noir Zinfandel

ANO 1999
2000

GARRAFAS
2 2 3

1997 1998

b. Operadores l. Restric;ao:

(exemplos) : Resultado: VINHO Zinfandel Fume Blanc Resultado: VINHO Zi nfandel Fume Blanc Pinot Noir Zinfandel ANO 1999
2000

GARRAFAS
2 2

SELECT VINHO, ANO, GARRAFAS FROM ADEGA WHERE ANO > 1998
2. Projec;ao:

GARRAFAS
2 2 3

SELECT VINHO, GARRAFAS FROM ADEGA ;

Agora, podemos distinguir entre sistemas relacionais e nao-relacionais. Em urn sistema relacional, 0 uswirio ve os dados como tabelas e nada mais que tabelas (como ja explicamos). Em contraste, 0 usuario de urn sistema nao-relacional ve outras estruturas de dados (seja em lugar das tabelas de urn sistema relacional ou em adi~ao a elas). Por sua vez, essas outras estruturas exigem outros operadores para acessa-Ias. Por exemplo, em urn sistema hierarquico como 0 IMS da IBM, os dados sao representados para 0 usuario sob a forma de arvores (hierarquias) e os operadores fornecidos para acessar tais estruturas incluem operadores para acompanhar ponteiros (a saber, os ponteiros que representam os caminhos hierarquicos para cima e para baixo nas arvores). Em contraste, uma caracterfstica distintiva importante dos sistemas relacionais e o fato de eles nao envolverem ponteiros (pelo menos, nao ponteiros visiveis ao usuario - ou seja, nenhum ponteiro no nivel de modelo - embora possa haver ponteiros no nivel da implementa~ao ffsica). Para levar a questao urn pouco adiante, os sistemas de bancos de dados podem ser divididos em categorias de modo conveniente, de acordo com as estruturas de dados e os operadores que eles apresentam ao usuario. De acordo com esse esquema, os sistemas mais antigos (pre-relacionais) se enquadram em tres categorias principais: os sistemas de lista invertida, hierarquicos e em rede.6 (Aqui, 0 termo rede nao tern qualquer rela~ao com as redes no sentido das comunica~oes de dados, conforme descrevemos no pr6ximo capitulo.) Nao aiscutiremos essas categorias em detalhes neste livro porque, de urn ponto de vista tecnol6gico, elas devem ser consideradas obsoletas. Voce podera encontrar descri~oes tutoriais de todos os tres sistemas na referencia [1.5], se estiver interessado. Os primeiros produtos relacionais come~aram a aparecer no final da decada de 1970 e no inicio da decada de 1980. No momenta em que este livro e escrito, a imensa maioria dos sistemas de bancos de dados e relacional, e eles funcionam em praticamente to do tipo de plataforma de hardware e software existente. Os principais exemplos incluem, em ordem alfabetica, 0 DB2 (varias versoes), da IBM Corp.; 0 Ingres II, da Computer Associates International Ine.; 0 Informix Dynamic Server, da Informix Software Inc.;? 0 Microsoft SQL Server, da Microsoft Corp.; 0 Oracle 9i, da Oracle Corp.; e 0 Sybase Adaptive Server, da Sybase Inc. Nota: Quando tivermos de nos referir a quaisquer desses produtos mais adiante neste livro, faremos referencia a eles (como a maioria do mercado faz informalmente) pelos nomes abreviados DB2, Ingres (pronuncia-se como em "ingress"), Informix, SQL Server, Oracle e Sybase, respectivamente.
6Por analogia com a modelo relacional, as edi~6es anteriores deste livro se referiam a modelos de lista invertida, hierarquico e em rede (e grande parte da literatura ainda a faz). Contudo, falar em tais termos e bastante enganoso; ao contrario do modelo relacional, os "modelos" de lista invertida, hierarquico e em rede foram todos definidos depois de criados; au seja, produtos comerciais de listas invertidas, hierarquicos e em redes foram implementados primeiro, e os "model os" correspondentes foram definidos subseqiientemente por urn processo de indu~iio (nesse contexto, urn termo mais brando para indicar adivinha~iio) a partir das implementa.;;6es existentes. Para obter mais detalhes, consulte a anota.;;iio da referencia [1.1]. 7 A divisiio de SGBD da Informix Software Ine. foi adquirida pela IBM Corp. em 2001.

Mais recentemente, certos produtos de objetos e relacionallobjeto se tornaram disponiveis - sistemas de objetos no final da decada de 1980 e infcio da decada de 1990, sistemas relacionallobjeto no final da decada de 1990. Os sistemas relacionallobjeto representam extensoes para certos produtos relacionais originais (como no caso do DB2 e do Informix); os sistemas de objetos - tambem chamados sistemas orientados a objeto - representam tentativas de fazer algo completamente diferente, como no caso do GemSrone, da GemStone Systems Ine. e do SGBDO Versant, da Versant Object Technology. Discutiremos esses sistemas na Parte VI deste livro. (Devemos observar que 0 termo objeto, no contexto de sua utiliza~ao nes.- paragrafo, possui urn significado bem espedfico, que sera explicado quando chegarmos a Parte VI. .\ntes desse ponto, usaremos 0 termo em seu sentido generico normal, salvo quando outro sentido for indicado explicitamente.) Alem das varias abordagens que acabamos de mencionar, diversos esquemas alternativos for am pesquisados ao longo dos anos, inclusive a abordagem multidimensional e 0 baseado em logica (tambem cha:nado dedutivo ou especialista). Os sistemas multidimensionais SaGdiscutidos no Capitulo 22 e os sistemas ~aseados em 16gica SaG apresentados no Capitulo 24. Alem disso, 0 recente crescimento, explosivo da odd Wide Web e 0 usa da XML geraram grande interesse pelo que se tornou conhecido (nao muito adequadamente) como abordagem semi-estruturado. Discutimos a respeito dos sistemas "semi-estrutu:-ados" no Capitulo 27.

erramos este capitulo introdut6rio resumindo os principais pontos discutidos. Primeiro, urn sistema e banco de dados pode ser considerado urn sistema computadorizado de manuten~ao de registros. Tal :"-rema envolve os pr6prios dados (armazenados no banco de dados), 0 hardware, 0 software (particular:nente, 0 sistema de gerenciamento de dados ou SGBD) e - 0 mais importante! - os usmirios. Por sua vez, ',r usuarios podem ser divididos em programadores de aplica~oes, usuarios finais e 0 administrador de anco de dados, ou DBA. 0 DBA e responsavel pela administra~ao do banco de dados e do sistema de :-anco de dados de acordo com normas estabelecidas pelo administrador de dados, ou DA. Os bancos de dados SaGintegrados e (normalmente) compartilhados; eles SaGusados para armazenar ados persistentes. Esses dados podem ser - de modo Util, embora informal - considerados representa.;:6esde entidades, juntamente com relacionamentos entre essas entidades - apesar do fato de que urn rela2onamento seja, na realidade, urn tipo especial de entidade. Examinamos muito rapidamente a ideia de .agramas de entidades e relacionamentos. Os sistemas de bancos de dados of ere cern diversos beneffcios, dos quais urn dos mais importantes e a dependencia de dados (ffsica). A independencia de dados pode ser definida como a imunidade de pro;:-amas de aplica~ao a altera~oes no modo de armazenar fisicamente os dados e obter acesso a eles. Entre :mas coisas, a independencia de dados requer 0 estabelecimento de uma distin~ao nitida entre 0 modelo ~e dados e sua implementa~ao. (De passagem, voltamos a lembra-Io de que 0 termo modelo de dados, tal. ::-::: infelizmente, possui dois significados bem diferentes.) Os sistemas de bancos de dados normalmente tambem aceitam transa~6es ou unidades 16gicas de tra-.;o~ho.Uma vantagem das transa~oes e que elas tern a garantia de ser atomicas (tudo ou nada), mesmo que =i-rema venha a falhar no meio de sua execu~ao. Por fim, os sistemas de bancos de dados podem se basear em uma serie de abordagens diferentes. Em -~-ticular, os sistemas relacionais se baseiam em uma teoria formal chamada modelo relacional, de acordo :: .. 0 qual os dados SaGrepresentados como linhas em tabelas (interpretados como proposi~6es verdadei- - e SaGfornecidos operadores que admitem diretamente 0 processo de inferencia (ou dedu~ao) de pro:-:: :i, 6es verdadeiras adicionais a partir de proposi~6es dadas. Tanto a partir de urn ponto de vista econo-"0 quanto te6rico, os sistemas relacionais SaGos mais importantes (e esse estado de coisas provavelmen-.= :laO sera mudado no futuro previsivel). Vimos alguns exemplos simples de SQL, a linguagem padrao ~.=.=-a lidar com sistemas relacionais (especificamente, vim os exemplos das instru~oes SQL SELECT, - ERT, UPDATE e DELETE). Este livro e baseado quase totalmente nos sistemas relacionais, embora:- - :- morivos explicados no prefacio - nao tanto na SQL propriamente dita.

::::l

acesso concorrente administras;ao de dados aplicas;ao on-line arquivo armazenado banco de dados campo armazenado

DBA
dados persistentes entidade diagrama de entidades e relacionamentos independencia de dados integras;ao integridade interface acionada por comandos 1.2 Quais sao as vantagens nao- relacionais.

interface acionada por formuLlrios interface acionada por menus linguagem de consulta compartilhamento propriedade relacionamento relacionamento binario redundancia registro armazenado segurans;a SGBD sistema de bancos de dados sistema multiusuario transas;ao

de se usar urn sistema de banco de dados? Quais sao as desvantagens? e sistemas

1.3 0 que voce entende pelo termo sistema relacional? Fas;a a distins;ao entre sistemas relacionais

1.4 0 que voce entende pelo termo modelo de dados? Explique a diferens;a entre urn modelo de dad os e sua implementas;ao. gura 1.1: Por que essa diferens;a

e importante?
0

1.5 Mostre os efeitos das seguintes operas;6es de busca em SQL sobre a. SELECT VINHO, PRODUTOR FROM ADEGA WHERE DEP# = 72 ;
b. SELECT VINHO, PRODUTOR

banco de dados da adega de vinhos da Fi-

FROM ADEGA WHERE ANO > 2000 ; c. SELECT DEP#, VINHO, ANO FROM ADEGA WHERE PRONTO < 2003 ; d. SELECT FROM WHERE AND VINHO, DEP#, ANO ADEGA PRODUTOR = 'Rabt. Mandavi GARRAFAS > 6 ;

1.6 Com suas proprias palavras, de uma interpretas;ao como uma proposis;ao verdadeira partir de cad a uma das suas respostas ao Exercfcio 1.5.

de uma linha tfpica a

1.7 Mostre os efeitos das seguintes operas;6es de atualizas;ao em SQL sobre

da Figura 1.1:

banco de dados da adega de vinhos

a. INSERT INTO ADEGA ( DEP#, VINHO, PRODUTOR, ANO, GARRAFAS, PRONTO) VALUES ( 80, 'Syrah', 'Meridian', 1998, 12, 2003 ) ; b. DELETE FROM ADEGA WHERE PRONTO

>

2004

c. UPDATE ADEGA SET GARRAFAS = 5 WHERE DEP# = 50 ;

d. UPDATE ADEGA SET GARRAFAS = GARRAFAS WHERE DEP# = 50 ;

2
0

1.8 Escreva instrU(;:6es SQL para executar as seguintes opera<;:6es sobre a. Obter 0 numero do deposito, Geyser Peak.
0

banco de dados da adega de vinhos:

nome do vinho e

numero de garrafas para todos os vinhos do produtor a todos os vinhos para os quais existem

b. Obter 0 numero do deposito e 0 nome do vinho correspondentes mais de cinco garrafas em estoque. c. Obter
0

numero do deposito para todos os vinhos tintos. tres garrafas ao deposito de numero 30. do estoque. deposito numero 55,

d. Acrescentar

e. Remover todos os vinhos Chardonnay

f. Acrescentar uma entrada para uma nova caixa (12 garrafas) de Gary Farrel Merlot: ana 2000, pronto em 2005.

1.9 Suponha que voce tenha uma cole<;:aode musica classica consistindo em CDs e/ou MDs e/ou LPs e/ou fitas de audio, e queira elaborar urn banco de dados que lhe permitira encontrar as grava<;:6es que possui de determinado compositor (e.g., Sibelius), urn maestro (e.g., Simon Rattle), urn solista (e.g., Arthur Grumiaux), uma obra (e.g., a Quinta Sinfonia de Beethoven), uma orquestra (e.g., a Filarmonica de Nova York), uma especie de obra (e.g., concerto para violino) ou urn grupo de camara (e.g., 0 Kronos Quartet). Esboce urn diagrama de entidades e relacionamentos para esse banco de dad os, como 0 da Figura 1.6.

1.1 E. F. Codd: "Data Models in Database Management", Proc. Workshop on Data Abstraction, Databases, and Conceptual Modelling, Pingree Park, Colo. (junho de 1980), ACM SIGMOD Record 11, Numero 2 (fevereiro de 1981) e outros. Codd foi 0 inventor do modelo relacional, descrito pela primeira vez na referencia [6.1]. Contudo, a referencia [6.1] nao definiu de fato 0 termo modelo de dados como tal- mas este artigo (muito posterior) faz isso. Em seguida, ele aborda a questao: a que propositos pretendem servir os modelos de dados em geral e 0 modelo relacional em particular? Alem disso, ele continua a oferecer evidencias que apoiam a afirmativa de que, ao contrario da cren<;:apopular, na realidade 0 modelo relacional foi 0 primeiro modelo de dados a ser definido. Em outras palavras, Codd tern uma certa razao ao afirmar ser 0 inventor do conceito de modelo de dados em geral, bem como do modelo de dados relacional em particular. 1.2 Hugh Darwen: "What a Database Really Is: Predicates and Propositions", em C.]. Date, Hugh Darwen e David McGoveran, Relational Database Writings 1994-1997. Reading, Mass.: Addison-Wesley (1998). Esse artigo oferece uma explica<;:ao informal (embora precisa) da ideia, discutida rapidamente no final da Se<;:ao1.3, de que 0 melhor conceito de urn banco de dados e como uma cole<;:ao de proposi<;:6es verdadeiras.

1.3 C. J. Date e P. Hopewell:

Workshop Workshop

"Storage Structures and Physical Data Independence", Proc. 1971 ACM SIGFIDET on Data Definition, Access, and Control, San Diego, California (novembro de 1971).

1.4 C. J. Date e P. Hopewell:

"File Definition and Logical Data Independence", Proc. 1971 ACM SIGFIDET on Data Definition, Access, and Control, San Diego, California (novembro de 1971). a definir e a fazer distin<;:ao entre independencia

As referencias [1.3-1.4] foram os primeiros documentos de dados ffsica e logica.

1.5 C. J. Date: Relational Database Writings 1991-1994.

Reading, Mass.: Addison-Wesley

(1995).