Cap1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Capítulo 1 
Bancos de dados relacionais 
1.1 UMA IDÉIA GENIAL 
O matemático inglês Edgar F. Codd publicou o primeiro artigo sobre o modelo relacional em 
1970. Nessa época, quase vinte anos depois do surgimento dos primeiros computadores de 
utilização comercial, a comunidade científica vivia um frenético entusiasmo pelas infindáveis 
possibilidades da computação eletrônica. Havia muito que fazer em todas as áreas: arquitetura 
de computadores, periféricos, sistemas operacionais, redes, linguagens de programação, bancos 
de dados, ambientes de desenvolvimento, aplicativos, só para citar algumas. Milhares de 
pesquisadores, professores, estudantes e profissionais da indústria, ao redor do mundo, 
trabalhavam nos fundamentos da Ciência da Computação e na concepção das idéias e artefatos 
que, hoje em dia, nos parecem sempre ter existido. 
Codd era um deles. Vinculado ao Laboratório de Pesquisas da IBM, em San Jose, na California, 
Codd vislumbrou uma solução extremamente simples para o que parecia tão complicado até 
então: criar um modelo lógico para bancos de dados. Muitas empresas ofereciam produtos para 
gerenciar bases de dados, mas as soluções ainda estavam longe do ideal: cada fabricante tinha 
seu próprio modelo, sua própria linguagem de acesso, sua própria concepção do que deveria ser 
uma base de dados. Codd quebrava isso apresentando um modelo baseado em tabelas ou 
relações, claro, sem ambigüidades, de concepção intuitiva, com uma estrutura teórica que 
permitia o desenvolvimento de técnicas que podiam ser formalmente tratadas e demonstradas. 
Enfim, com a marca inconfundível do gênio lógico-matemático: a simplicidade. 
Um dos pontos fortes da proposta de Codd era o conceito de independência de dados, que 
consistia na idéia de que a estrutura lógica do banco de dados independesse de sua 
implementação física. Até então, os modelos conceituais estavam estreitamente ligados às 
técnicas de implementação. Apontadores e localizadores físicos de registros, criados para 
rapidez de acesso, eram importantes porque permitiam as ligações entre os registros. Não havia 
uma separação entre o significado lógico das estruturas e o método para sua implementação. O 
modelo relacional inovava, permitindo que o programador visualizasse a base de dados na 
forma de tabelas, enquanto os detalhes da implementação física ficavam ocultos. 
Desde o início, as possibilidades teóricas do modelo relacional ficaram evidentes e muitos 
pesquisadores lançaram-se ao aprimoramento das idéias de Codd e à exploração de suas 
conseqüências na prática. O número de artigos e trabalhos científicos sobre o assunto crescia 
rapidamente e o interesse teórico pela área de bancos de dados acompanhava esse passo. 
Embora a capacidade de processamento dos computadores então disponíveis estivesse aquém 
do que seria razoável para as implementações dos protótipos do modelo relacional, aumentava a 
crença dos pesquisadores de que, mais cedo ou mais tarde, as coisas aconteceriam. 
E aconteceram. Ainda na década de 70 foram publicados os primeiros resultados sobre o 
Sistema R (System/R), desenvolvido na IBM, que implementava bancos de dados segundo o 
modelo relacional. Também nessa época, o sistema INGRES surgia como uma referência de 
implementação. Os primeiros produtos comerciais baseados no modelo relacional surgiram no 
início dos anos 80, dentre eles o Oracle, que viria a tornar-se o gerenciador de bases de dados 
2 Capítulo 1: Bancos de dados relacionais 
 
mais vendido do mundo na virada do século. Discretos no início, os bancos de dados 
relacionais foram ganhando terreno rapidamente até transformarem-se numa quase unanimidade 
a partir dos anos 90. Poucas vezes pôde-se observar um ciclo tão didático de concepção, 
pesquisa & desenvolvimento e comercialização de uma idéia. 
SQL foi um dos subprodutos desse processo. Inicialmente apenas uma das várias alternativas 
de linguagens de consultas para bancos relacionais, SQL foi consolidando-se e estabeleceu-se 
como um verdadeiro padrão de fato, implementado com leves variações na quase totalidade dos 
gerenciadores de bancos de dados de nossos dias. 
As idéias de Codd tiveram influência no trabalho e no lazer de centenas de milhões de pessoas 
que hoje em dia operam, programam, manipulam ou simplesmente utilizam dados armazenados 
em bancos relacionais. Codd faleceu em 2003, aos 79 anos, mas teve seu talento reconhecido 
ainda em vida, especialmente em 1981, quando recebeu o Prêmio Alan Turing, da ACM, uma 
espécie de Prêmio Nobel da Informática. Esse reconhecimento, contudo, renova-se em cada um 
que percebe a engenhosidade das idéias do modelo relacional. Espero que, ao final deste livro, 
você, leitor, venha a concordar com isso! 
1.2 BANCOS DE DADOS RELACIONAIS = TABELAS + RESTRIÇÕES + OPERAÇÕES 
Um banco de dados relacional é modelado logicamente como um conjunto de tabelas. Cada 
tabela, ou relação, possui colunas, também chamadas de atributos. A cada coluna ou atributo 
está associado um tipo de dados, que rege os valores que aquela coluna (ou atributo) pode 
receber. Essas tabelas são instanciadas por um conjunto de tuplas, ou registros, que populam o 
banco de dados. Um conjunto de tabelas, juntamente com seus atributos, forma um esquema 
relacional. 
O esquema relacional abaixo corresponde ao banco de dados utilizado nos exemplos deste livro. 
Aluno (Matrícula, Nome, Sexo, CodCurso, Nascimento) 
Curso (CodCurso, Curso) 
Disciplina (CodDisciplina, Disciplina, CodProfessor, CHST, CHSP) 
Professor (CodProfessor, Nome) 
Inscrição (Matrícula, CodDisciplina, Nota) 
A instância de cada tabela é mostrada a seguir. 
 
ALUNO
Matricula Nome Sexo CodCurso Nascimento
1001 Ricardo Biondi M DIR 21/02/1980
1002 Maria Rita Colatti F INF 10/11/1978
1004 Oscarito Vianna M DIR 14/08/1979
1005 Barbara Carlito F JOR 29/10/1979
1007 Carlos Maradona M DIR 30/06/1977
1008 Sacadura Miranda M INF 12/12/1981
1010 Maria Lucia Silva F JOR 10/08/1975
CURSO
CodCurso Curso
DIR Direito
JOR Jornalismo
INF Informática
INSCRIÇÃO
Matricula CodDisciplina Nota
1001 112 NULL
1001 317 8,0
1002 210 9,5
1005 316 3,0
1005 117 4,2
1007 112 NULL
1007 114 7,00
1010 317 5,5
1010 316 10,00
PROFESSOR
CodProfessor Nome
2 Olivia Straw
3 Carlos Azambuja
10 Marina Azambuja
12 Pedro Amarante
15 Zenubio Siqueira
17 Lenira Rocha
18 Silvia Ferreira
DISCIPLINA
CodDisciplina Disciplina CodProfessor CHST CHSP
112 Dir. Constitucional 3 4 0
114 Direito Civil 10 4 2
117 Estatística 15 2 2
210 Compiladores 2 2 4
211 Bancos de Dados 17 3 3
316 Sociologia 18 3 1
317 Português 12 4 0
ERROR! STYLE NOT DEFINED. 3 
 
A convenção aqui utilizada é que cada tabela seja descrita por um nome, seguido de uma lista de 
atributos entre parênteses. O banco de dados sendo modelado trata de alunos, cursos, 
disciplinas, professores e inscrições, representados pelas tabelas ALUNO, CURSO, DISCIPLINA, 
PROFESSOR e INSCRIÇÃO, respectivamente. Cada aluno está matriculado em um curso. Os alunos 
podem estar inscritos em disciplinas, sendo atribuída uma nota para cada inscrição. Cada 
disciplina tem um professor, além do registro da carga horária semanal teórica (CHST) e prática 
(CHSP). 
As operações permitidas sobre essas tabelas são a inserção, remoção e atualização de registros. 
Assim, um banco de dados pode ser populado de acordo com o mundo que ele representa, ou 
modela. Cada registro na tabela ALUNO representa um aluno real da escola; cada registro da 
tabela DISCIPLINA representa a existência de uma disciplina que é ministrada na escola, e assim 
por diante. Como cada tabela representa objetos do mundo real, existem características nesses 
objetos que são únicas e portanto servem para identificá-los. Um aluno pode ser identificado 
por sua matrícula;
não há dois alunos com a mesma matrícula; uma disciplina por seu código, 
no atributo coddisciplina. A chave primária de uma tabela é o conjunto (um ou mais) de 
atributos que identificam unicamente cada registro da tabela. O quadro abaixo mostra os 
atributos que que constituem as chaves primárias de cada tabela: 
 
Tabela Atributos que constituem a chave primária 
Aluno matrícula 
Disciplina coddisciplina 
Curso codcurso 
Professor codprofessor 
Inscrição matrícula, coddisciplina 
 
Existem casos de objetos que podem ser identificados por mais de um conjunto de atributos. No 
nosso caso, um curso pode ser identificado pelo seu nome, contido no atributo curso. Diz-se que 
o atributo curso é uma chave candidata da tabela CURSO. Uma tabela pode ter uma ou mais 
chaves candidatas, além da chave primária. 
A tabela INSCRIÇÃO representa os relacionamentos que existem entre alunos e disciplinas: o 
segundo registro, por exemplo, denota que o aluno cuja matrícula é 1001 está inscrito na 
disciplina cujo código é 317, tendo nela obtido a nota 8,0. Os dados sobre o aluno cuja 
matrícula é 1001 aparecem na tabela ALUNO. Este aluno chama-se Ricardo Biondi, é do sexo 
masculino e nasceu em 21/02/1980. A disciplina de código 317 é Português e tem carga horária 
semanal de 4 horas teóricas. Assim, o segundo registro da tabela INSCRIÇÃO denota que Ricardo 
Biondi está inscrito em Português, tendo obtido a nota 8,0. A partir da tabela DISCIPLINA, 
podemos também saber quem é o professor de Ricardo Biondi naquela disciplina: é o professor 
cujo código é 12, Pedro Amarante. Esta última informação pode ser deduzida dos valores dos 
atributos codprofessor, na tabela DISCIPLINA e do atributo professor no registro da tabela 
PROFESSOR que possui o código 12. Essa “navegação” entre registros é possível porque, na 
concepção do esquema, o projetista do banco de dados estabelece elos entre as tabelas. 
Normalmente, esses elos implementam os relacionamentos existentes entre os objetos do mundo 
real. 
Vejamos quais seriam os relacionamentos para o modelo em pauta. 
Alunos e cursos têm um relacionamento do tipo 1:N. Cada aluno está sempre ligado a 
um curso e um curso pode estar ligado a zero ou mais alunos. Disciplinas e professores 
têm um relacionamento 1:1; uma disciplina pode ou não estar ligada a um professor e 
um professor pode estar ligado a zero ou, no máximo, uma disciplina. A tabela Inscrição 
representa o relacionamento N:M existente entre alunos e disciplinas. Dessa forma, uma 
inscrição está sempre ligada a um aluno e a uma disciplina. Um aluno pode estar ligado 
a zero ou mais inscrições, o mesmo ocorrendo com as disciplinas. 
4 Capítulo 1: Bancos de dados relacionais 
 
Normalmente, um elo referencia um objeto de outra tabela através de sua chave primária. Na 
tabela DISCIPLINA, por exemplo, o atributo codprofessor estabelece o elo entre disciplinas e seus 
professores. Diz-se que codprofessor é uma chave estrangeira (foreign key) com relação à 
tabela PROFESSOR. O mesmo pode ser observado na tabela INSCRIÇÃO, onde há duas chaves 
estrangeiras, uma com relação à tabela ALUNO e outra com relação à tabela DISCIPLINA. 
Com isso, nosso esquema relacional pode ser refinado, incluindo essas restrições: as chaves 
primárias e as chaves estrangeiras. As primeiras serão identificadas pelos atributos sublinhados; 
as chaves estrangeiras, textualmente 
Aluno (Matricula, Nome, Sexo, CodCurso, Nascimento) 
 CodCurso é chave estrangeira com relação à tabela Curso 
Curso (CodCurso, Curso) 
Disciplina (CodDisciplina, Disciplina, Creditos, CodProfessor, CHST, CHSP) 
CodProfessor é chave estrangeira com relação à tabela Professor 
Professor (CodProfessor, Nome) 
Inscrição (Matricula, CodDisciplina, Nota) 
 Matricula é chave estrangeira com relação à tabela Aluno 
 CodDisciplina é chave estrangeira com relação à tabela Disciplina 
Note que no caso da tabela INSCRIÇÃO, a chave primária é formada pela concatenação dos 
atributos matrícula e coddisciplina. Isso significa que a mesma combinação de uma matrícula e 
uma disciplina não pode repetir-se na instância desta tabela. Ainda na mesma tabela, algumas 
notas aparecem com a palavra null. Isto significa que tais valores ainda não foram preenchidos 
na base de dados e, portanto, são considerados valores nulos. 
As chaves estrangeiras são, na verdade, restrições de integridade impostas sobre as instâncias 
das tabelas. Uma chave estrangeira é um atributo, ou conjunto de atributos, que referencia 
valores existentes em outra tabela (ou na própria em caso de auto-relacionamento). Por 
exemplo, se um registro na tabela Disciplina faz referência a um professor de código 12 (no 
atributo codprofessor) então deve existir um professor cujo código é 12. Os gerenciadores de 
bancos de dados encarregam-se de manter a integridade do banco. Se houver uma referência a 
um registro inexistente, a operação geradora deve ser recusada. Por sua vez, a operação de 
remoção de um professor que é referenciado em alguma disciplina também deve ser recusada. 
Esse mecanismo é denominado integridade referencial. 
O diagrama a seguir ilustra o esquema ora definido. Ali aparecem as tabelas componentes do 
esquema com seus respectivos atributos. Os atributos em negrito compõem a chave primária de 
cada tabela. Cada linha, representado os elos entre as tabelas, liga o atributo que é chave 
estrangeira de uma ao atributo que compõe a chave primária da outra. 
 
As cardinalidades dos relacionamentos entre as tabelas são mostradas com o intuito de melhor 
ilustrar o esquema relacional. Na notação, escreve-se o número mínimo e máximo de instâncias 
que podem estar relacionadas a um dado registro. Por exemplo, a cardinalidade do 
relacionamento entre as tabelas ALUNO e CURSO deve ser lida seguindo-se os dois sentidos da linha. 
No sentido ALUNO → CURSO, lê-se “um registro de aluno está ligado, sempre, a um registro de 
curso”; no sentido inverso, lê-se “um registro de curso está ligado a no mínimo zero e no 
máximo n registros de alunos”. Note que quando o mínimo e o máximo são iguais, não é 
Aluno 
Matricula 
Nome 
Sexo 
CodCurso 
Nascimento 
Disciplina 
CodDisciplina 
Disciplina 
CodProfessor 
CHST 
CHSP 
Curso 
CodCurso 
Curso 
Inscricao 
Matricula 
CodDisciplina 
Nota Professor 
CodProfessor 
Nome 
0:1 
1
 1 
1
0:1 
0:n
0:n
0:n 
ERROR! STYLE NOT DEFINED. 5 
 
preciso repetir o valor. Assim, uma cardinalidade indicada como 1 é equivalente a 1:1. O 
símbolo n denota um número indefinido de registros, n ≥ 1. 1 
1.3 LINGUAGENS DE CONSULTA 
Quando o modelo relacional surgiu, duas abordagens destacavam-se como as principais 
alternativas para a base teórica das linguagens de consultas para o modelo proposto por Codd. 
De um lado, estavam as linguagens baseadas nas idéias do cálculo relacional, desenvolvido a 
partir da velha e boa lógica de predicados. De outro, estavam as linguagens baseadas na 
álgebra relacional. A diferença entre elas é simples: nas linguagens baseadas na lógica de 
predicados, o usuário do banco de dados especifica sua consulta através de uma expressão 
lógica. Não é preciso dizer como construir a consulta, apenas o que ela deve produzir. Já para 
as linguagens baseadas na álgebra relacional, o usuário constrói uma consulta encadeando 
operações numa determinada seqüência. As duas formas são equivalentes: qualquer consulta 
expressa no cálculo de predicados pode ser expressa na álgebra relacional, e vice-versa. 
As primeiras linguagens de consulta apostavam fortemente no modelo algébrico, parte pela 
simplicidade conceitual das operações, parte pelo parco desenvolvimento, havido até então, das 
linguagens de cunho lógico. O capítulo 3 deste livro aborda aspectos da álgebra relacional
e 
suas operações. 
SQL, que é uma linguagem baseada na lógica de predicados com tinturas de álgebra relacional, 
viria a se destacar e tomar o papel principal dentre as alternativas. 
1.4 O SURGIMENTO DO SQL 
Com um modelo baseado em relações, Codd vislumbrou que operações elementares sobre 
conjuntos e linguagens baseadas no cálculo de predicados seriam bases adequadas para 
consultas no modelo relacional e várias linguagens foram propostas. A linguagem SQUARE, 
originalmente publicada em 1973, continha elementos da álgebra relacional e foi, talvez, o 
primeiro exemplo de uma linguagem com variáveis. Contudo, SQUARE tinha uma sintaxe 
pesada, impregnada de símbolos matemáticos e pouco adequada para ser utilizada por um 
público não especializado. Seguiram-se imediatamente as propostas das linguagens SEQUEL 
(Structured English Query Language), utilizada no Sistema R, da IBM, e da linguagem QUEL, 
empregada no INGRES. Embora com algumas diferenças sintáticas, essas linguagens foram 
concebidas sobre a plataforma comum da lógica de primeira ordem e do cálculo de predicados. 
A diferença maior em relação a SQUARE, porém, estava na sintaxe, bem mais amigável e 
compreensível. 
SEQUEL foi rebatizada como SQL, que ainda é pronunciada ‘si-kuél’ por muitos americanos. 
Rapidamente, o SQL, que era e é uma linguagem aberta, sem proprietários, foi tornando-se uma 
espécie de padrão de fato para linguagens relacionais. A formação de comissões destinadas à 
sua padronização, tanto ANSI (American National Standards Institute) como ISO (International 
Standards Organization), em 1986 e 1987, consolidou este processo, especialmente quando do 
lançamento do padrão ANSI, em 1989, conhecido como SQL-89. Seguiram-se outros dois 
padrões, SQL-92 e SQL-99. 
Muitos fabricantes esforçam-se para oferecer implementações que aderem aos padrões mas, ao 
mesmo tempo, procuram oferecer extensões próprias que tornem seus produtos mais 
interessantes e diferenciados. O resultado, feliz e infelizmente, é a existência de 
 
1 Algumas implementações de bancos de dados oferecem a possibilidade de criar estruturas de 
dados que extrapolam os conceitos básicos do modelo, como é o caso das nested tables no 
Oracle. Algumas dessas variações são tratadas em detalhes no capítulos subseqüentes. 
6 Capítulo 1: Bancos de dados relacionais 
 
implementações que respeitam em parte os padrões mas ainda contêm extensões proprietárias 
que perenizam o problema de portabilidade das consultas escritas em SQL. 
OBTENDO MAIS INFORMAÇÕES 
A seguir, alguns dos artigos mais influentes no desenvolvimento do sistema relacional. Vale a 
pena folhear esses notáveis artigos e conhecer os textos que deram origem aos bancos de dados 
como os conhecemos hoje em dia. 
 
CODD, E. F. A Relational Model of Data for Large Shared Data Banks, Communications of the 
Association for Computing Machinery 13, 6(Junho 1970), 377-387. 
O artigo que estabeleceu as bases do modelo relacional. Codd menciona tabelas, operações 
sobre conjuntos e alternativas para linguagens baseadas na lógica de predicados. 
BOYCE, R. et al Specifying queries as relational expressions: SQUARE, Relatório Técnico RJ 
1291, IBM Laboratory, San Jose, California, Outubro 1973. 
Uma das primeiras linguagens surgidas, tendo influenciado fortemente a concepção das 
linguagens QUEL e SEQUEL. 
CHAMBERLIN, D.; BOYCE, R. SEQUEL: A Structured English Query Language, Proc. ACM 
SIGMOD Workshop on Data Description, Access and Control, 1974. 
Este artigo introduziu a linguagem que viria ser a precursora do SQL, inclusive no nome. 
STONEBRAKER, M.; WONG, E.; KREPS, P.; HELD, G. The Design and Implementation of IN-
GRES, ACM Transactions on Database Systems 1, 3(Setembro, 1976), 189-222. 
Um dos mais importantes protótipos dos bancos relacionais. Stonebraker e colaboradores da 
Universidade de Berkeley, na California, desenvolveram importantes idéias sobre 
implementações relacionais, e descrevem a linguagem, que viria a ser suprimida pelo sucesso do 
SQL. 
ASTRAHAN, M. et al System R; Relational Approach to Database Management, ACM Transac-
tions on Database Systems 1, 2(Junho, 1976), 97-137. 
Talvez o mais importante protótipo de banco de dados relacionais, o desenvolvimento do 
sistema R foi um projeto de grande porte da IBM, que estabeleceu técnicas que ainda hoje 
perduram nos produtos sendo comercializados.