Banco de Dados

Banco de Dados
Projeto e Implementao
Felipe Nery Rodrigues Machado
Banco de Dados
Projeto e Implementao
3 Edio
www.editoraerica.com.br
1
Dados Internacionais de Catalogao na Publicao (CIP)
(Cmara Brasileira do Livro, SP, Brasil)
Machado, Felipe Nery Rodrigues
Projeto e implementao de banco de dados / Felipe Nery Rodrigues Machado. -- 3. ed. --

So Paulo : rica, 2014.
Bibliografia.
ISBN 978-85-365-0984-6
1. Banco de dados I. Ttulo.
14-05221 CDD-005.75
ndice para catlogo sistemtico:

1. Bancos de Dados: Sistemas: Projeto e implementao: Processamento de dados 005.75
Copyright 2004 da Editora rica Ltda.

Todos os direitos reservados. Nenhuma parte desta publicao poder ser reproduzida por qualquer meio ou forma sem prvia
autorizao da Editora rica. A violao dos direitos autorais crime estabelecido na Lei n 9.610/98 e punido pelo Artigo 184
do Cdigo Penal.
Coordenao Editorial: Rosana Arruda da Silva

Capa: Samir M. de Machado
Maurcio S. de Frana
Editorao e Finalizao: Dalete R. de Oliveira
Lvia Vilela de Lima
Rosana Ap. A. dos Santos
Marlene Teresa S. Alves
O Autor e a Editora acreditam que todas as informaes aqui apresentadas esto corretas e podem ser utilizadas para
qualquer fim legal. Entretanto, no existe qualquer garantia, explcita ou implcita, de que o uso de tais informaes conduzir
sempre ao resultado desejado. Os nomes de sites e empresas, porventura mencionados, foram utilizados apenas para ilustrar
os exemplos, no tendo vnculo nenhum com o livro, no garantindo a sua existncia nem divulgao. Eventuais erratas
estaro disponveis para download no site da Editora rica.
Contedo adaptado ao Novo Acordo Ortogrfico da Lngua Portuguesa, em execuo desde 1 de janeiro de 2009.
A Ilustrao de capa e algumas imagens de miolo foram retiradas de <www.shutterstock.com>, empresa com a qual se
mantm contrato ativo na data de publicao do livro. Outras foram obtidas da Coleo MasterClips/MasterPhotos da IMSI,
100 Rowland Way, 3rd floor Novato, CA 94945,USA, e do CorelDRAW X5 e X6, Corel Gallery e Corel Corporation Samples.
Copyright 2013 Editora rica, Corel Corporation e seus licenciadores. Todos os direitos reservados.
Todos os esforos foram feitos para creditar devidamente os detentores dos direitos das imagens utilizadas neste livro.
Eventuais omisses de crdito e copyright no so intencionais e sero devidamente solucionadas nas prximas edies,
bastando que seus proprietrios contatem os editores.
Seu cadastro muito importante para ns

Ao preencher e remeter a ficha de cadastro constante no site da Editora rica, voc passar a receber informaes
sobre nossos lanamentos em sua rea de preferncia.
Conhecendo melhor os leitores e suas preferncias, vamos produzir ttulos que atendam suas necessidades.
Contato com o editorial: editorial@editoraerica.com.br
Editora rica Ltda. | Uma Empresa do Grupo Saraiva

Rua So Gil, 159 - Tatuap
CEP: 03401-030 - So Paulo - SP
Fone: (11) 2295-3066 - Fax: (11) 2097-4060
www.editoraerica.com.br
2 Banco de Dados - Projeto e Implementao

Dedicatria
Aos meus filhos Samir e Thamis pelo amor e carinho que me dedicam e por serem a
razo do meu viver. In memoriam ao meu pai, Dr. Nery de Almeida Machado, que me ensinou
determinao e carter, e acima de tudo me ensinou que honestidade o bem maior de uma
vida. minha esposa Maria Cristina Vaz Machado e a meus enteados Joo Pedro, Luiz Felipe
e Lucas pelo carinho e amor que me dedicam e pela famlia que constitumos.
Agradecimentos
A Deus, por estar sempre ao meu lado, com seus anjos e com sua energia irradiante,
que me mantm sempre com apoio e segurana, mesmo nos momentos mais difceis em que
nEle tenho o repouso e o empurro para a frente.
Produziro as montanhas frutos de paz ao

vosso povo; e as colinas, frutos de justia.
Sl 71, 3
3
Sobre o Autor
Felipe Nery Rodrigues Machado

Consultor com mais de vinte anos de vivncia na rea de informtica, na qualidade de
projetista de sistemas. Com formao em Engenharia Mecnica, possui larga experincia no
projeto de banco de dados com profundos conhecimentos de metodologias e modelagem de
dados.
Especialista em projetos de bancos de dados para aplicaes transacionais e
gerenciais, possui amplo conhecimento no desenvolvimento de projetos de bancos de dados
para as mais diversas reas de negcio, tais como indstria metalrgica, indstria de alimen-
tos, varejo e atacado, jornais e televiso, distribuio de produtos, concessionrias de autom-
veis, rgos pblicos diversos, hospitais e companhias areas. Sua experincia abrange o
ciclo completo de negcios de uma organizao, tendo j desenvolvido igualmente aplicaes
com Arquitetura de Data Warehouse, processos de ETL, com grande nfase em modelagem
multidimensional e arquitetura de processos OLAP.
Professor universitrio de disciplinas de Bancos de Dados e Metodologias de Desenvol-
vimento, no Rio de Janeiro, dedica-se pesquisa e divulgao das tcnicas e metodologias do
estado da arte em desenvolvimento de aplicaes.
Autor dos livros Tecnologia e Projeto de Data Warehouse, Banco de Dados: Projeto
e Implementao e Anlise Relacional de Sistemas, todos publicados pela Editora rica e
adotados nas principais universidades de informtica do Pas.
E-mail: fnr.machado@gmail.com

Sumrio
Captulo 1 - O Que Projeto de Banco de Dados................................................................................. 13

Modelagem de Dados ................................................................................................................... 14
Que Abstrao? ......................................................................................................................... 16
Minimundo ................................................................................................................................ 18
Banco de Dados ....................................................................................................................... 18
Modelo Conceitual.................................................................................................................... 18
Modelo Lgico .......................................................................................................................... 19
Modelo Fsico ........................................................................................................................... 20
O Projeto de Banco de Dados ...................................................................................................... 21
O Modelo Entidade-Relacionamento (ER) .................................................................................... 23
A Implementao de Banco de Dados.......................................................................................... 24
Concluso ..................................................................................................................................... 26
Captulo 2 - Abstrao em Modelagem de Dados ................................................................................ 27

Classificao de Abstrao ........................................................................................................... 28
Agregao de Abstrao............................................................................................................... 29
Generalizao de Abstrao ......................................................................................................... 29
A Cozinha ................................................................................................................................. 31
Comear por Dados ...................................................................................................................... 33
Agregaes Binrias ..................................................................................................................... 33
Cardinalidade Mnima ................................................................................................................... 34
Cardinalidade Mxima .................................................................................................................. 36
Exerccios de Abstrao ............................................................................................................... 37
Captulo 3 - Bancos de Dados Relacionais ........................................................................................... 39

Introduo ..................................................................................................................................... 39
Teoria Relacional .......................................................................................................................... 40
Caractersticas Principais de uma Relao (Tabela Relacional) .................................................. 43
Domnio ......................................................................................................................................... 44
Chave Primria ............................................................................................................................. 46
Valores Nulos e Integridade de Identidade ................................................................................... 51
Regra de Integridade de Identidade.............................................................................................. 53
Chave Primria......................................................................................................................... 53
Chave Estrangeira.................................................................................................................... 54
Integridade Referencial ................................................................................................................. 57
Restries para Garantir a Integridade Referencial ................................................................. 59
Resumo de Restries de Integridade Relacional ........................................................................ 61
Exerccios...................................................................................................................................... 62
5
Captulo 4 - Modelo Entidade-Relacionamento..................................................................................... 65
Elementos de um Modelo ER........................................................................................................ 67
Entidades ...................................................................................................................................... 68
Relacionamentos........................................................................................................................... 70
Atributos ........................................................................................................................................ 72
Grau de Relacionamento .............................................................................................................. 75
Conectividade de um Relacionamento.......................................................................................... 76
Conectividade Um-para-Um ..................................................................................................... 77
Conectividade Um-para-Muitos ................................................................................................ 78
Conectividade Muitos-para-Muitos ........................................................................................... 79
Atributos em um Relacionamento ................................................................................................. 80
Opcionalidade de Relacionamento ............................................................................................... 82
Condicionalidade de um Relacionamento ..................................................................................... 82
Relacionamentos Reflexivos ......................................................................................................... 83
Resoluo de Relacionamentos Muitos-para-Muitos .................................................................... 85
Entidade Fraca ou Dependente .................................................................................................... 92
Como Reconhecer Entidades na Prtica ...................................................................................... 92
Como Reconhecer Relacionamentos............................................................................................ 93
Uma Distribuidora de Filmes .................................................................................................... 94
Exerccios ...................................................................................................................................... 99
Captulo 5 - Extenses do Modelo Entidade-Relacionamento .......................................................... 102

Generalizao: Supertipos e Subtipos ........................................................................................ 102
Relacionamentos Ternrios ........................................................................................................ 106
Modelagem de Atributos (Modelagem Lgica)............................................................................ 108
O Problema ................................................................................................................................. 110
Quando os Fatos Podem Confundir ............................................................................................ 115
Captulo 6 - Agregao: Uma Extenso Especial ............................................................................... 122

O Hotel ........................................................................................................................................ 129
Explicao Adicional sobre as Chaves ....................................................................................... 136
Clnicas Mdicas ......................................................................................................................... 136
A Fbrica ..................................................................................................................................... 144
Regras para Identificar e Utilizar Agregao............................................................................... 146
Agregao Reflexiva .............................................................................................................. 152
Produto Composto e Componente .............................................................................................. 155
Uma Distribuidora de Filmes - O Retorno ................................................................................... 157
Concluso ................................................................................................................................... 158
Captulo 7 - Tratamento de Interpretaes de Dados......................................................................... 159

Pontos de Vista Diferentes .......................................................................................................... 159
Relacionamentos entre Interpretaes ....................................................................................... 162

Tratamento de Subinterpretaes............................................................................................... 165
Mais Interpretao ...................................................................................................................... 167
Diagrama Hierrquico de Interpretaes .................................................................................... 174
Concluso ................................................................................................................................... 175
Cuidado, Abra o Olho!................................................................................................................. 176
Captulo 8 - Normalizao ..................................................................................................................... 177

Conceituao .............................................................................................................................. 177
Primeira Forma Normal (1FN)..................................................................................................... 179
Segunda Forma Normal (2FN).................................................................................................... 184
Terceira Forma Normal (3FN) ..................................................................................................... 187
Forma Normal de Boyce/Codd (FNBC).................................................................................. 190
Entidade Cliente ................................................................................................................ 192
Entidade Agncia .............................................................................................................. 192
Entidade Emprstimos ...................................................................................................... 193
Quarta Forma Normal (4FN) ....................................................................................................... 195
Quinta Forma Normal (5FN) ....................................................................................................... 200
Roteiro de Aplicao da Normalizao ....................................................................................... 200
Aplicao da 1FN .............................................................................................................. 200
Aplicao da 2FN .............................................................................................................. 200
Aplicao da 3FN .............................................................................................................. 201
Aplicao da FNBC ........................................................................................................... 201
Aplicao da 4FN .............................................................................................................. 201
Aplicao da 5FN .............................................................................................................. 201
Consideraes Finais sobre Normalizao................................................................................. 202
Desnormalizao dos Dados ...................................................................................................... 203
Alguns Motivos para a Desnormalizao ............................................................................... 203
Captulo 9 - Um Estudo de Caso .......................................................................................................... 204

O Problema - Administrao de Cirurgias................................................................................... 204
Modelagem ................................................................................................................................. 205
Captulo 10 - Hierarquias ...................................................................................................................... 215

Tratamento de Hierarquias de Dados ......................................................................................... 215
Captulo 11 - Modelo Fsico .................................................................................................................. 218

O Modelo Fsico em Si ................................................................................................................ 218
Propriedades de uma Coluna ..................................................................................................... 219
A Opo de Nulo .................................................................................................................... 220
Uma Regra de Validao ....................................................................................................... 220
Valor Padro .......................................................................................................................... 221
Vises de Dados ......................................................................................................................... 221
7
ndices do Banco de Dados ........................................................................................................ 223
Chaves Substitutas................................................................................................................. 223
As Generalizaes ................................................................................................................. 224
Tabelas do Exemplo ............................................................................................................... 225
Relao entre Modelo Lgico e Modelo Fsico ........................................................................... 227
Captulo 12 - Mapeamento de Objetos ER .......................................................................................... 231

Mapeamento de Objetos para Tabelas (ER)............................................................................... 232
Regra 1........................................................................................................................................ 233
Classes com Colees de Objetos ............................................................................................. 234
Regra 2........................................................................................................................................ 234
Regra 3 - Transposio de Associaes Um-para-Um ............................................................... 235
Regra 4 - Transposio de Associaes Um-para-Muitos .......................................................... 236
Regra 5 - Transposio de Associaes Um-para-Muitos com Classe de Associao .............. 236
Regra 6 - Transposio de Associaes Muitos-para-Muitos ..................................................... 237
Regra 7 - Transposio de Associaes Muitos-para-Muitos com Classe de Associao ......... 237
Regra 8 - Transposio de Generalizaes ................................................................................ 238
Regra 9 - Transposio de Agregaes...................................................................................... 240
Consideraes Finais .................................................................................................................. 241
Captulo 13 - lgebra Relacional ......................................................................................................... 242

lgebra Relacional e Operaes Relacionais ............................................................................. 242
Os Operadores de lgebra Relacional........................................................................................ 243
Operao de Projeo ................................................................................................................ 244
Operao de Seleo.................................................................................................................. 247
Produto Cartesiano ..................................................................................................................... 251
Operao Renomear ................................................................................................................... 259
Operao de Unio (Binria)....................................................................................................... 266
Operao de Diferena (Binria)................................................................................................. 269
Operao de Interseco de Tabelas ......................................................................................... 273
Operao de Juno ................................................................................................................... 275
Operao de Diviso ................................................................................................................... 281
Exerccios Resolvidos e Operadores Adicionais ......................................................................... 284
Funes em lgebra Relacional ................................................................................................. 290
Projeo Generalizada ................................................................................................................ 292
Operao de Semijuno ............................................................................................................ 298
Juno Externa (Outer-Join) ....................................................................................................... 300
Exerccios Propostos................................................................................................................... 302
Captulo 14 - SQL ................................................................................................................................... 306

A Importncia da Linguagem SQL .............................................................................................. 306
A Linguagem SQL ....................................................................................................................... 307

Vantagens e Desvantagens da Linguagem SQL ................................................................... 309
O Exemplo.............................................................................................................................. 310
Criao e Distribuio de Tabelas .............................................................................................. 313
Criao de Tabelas ................................................................................................................ 314
Criao de Chaves Primrias Compostas ............................................................................. 317
Eliminao de uma Tabela ..................................................................................................... 318
Alterao da Estrutura das Tabelas ............................................................................................ 318
Coluna Calculada ................................................................................................................... 320
Criao de Aes em Cascata.................................................................................................... 321
A Clusula ON DELETE CASCADE e ON UPDATE CASCADE ........................................... 321
Regras de Validao .............................................................................................................. 321
Extrao de Dados de uma Tabela: SELECT............................................................................. 322
Seleo de Colunas Especficas da Tabela ........................................................................... 322
Seleo de Todas as Colunas da Tabela .............................................................................. 324
Alterao do Heading (Cabealho) da Coluna ....................................................................... 325
Manipulao de Dados Numricos: Operadores Aritmticos................................................. 326
Seleo de Somente Algumas Linhas da Tabela .................................................................. 326
Comparaes na Clusula WHERE .................................................................................. 327
Ordenao dos Dados Selecionados.......................................................................................... 334
Realizao de Clculos com Informao Selecionada ............................................................... 337
Utilizao de Funes de Agregao sobre Conjuntos .............................................................. 338
Busca de Mximos e Mnimos (MAX, MIN)............................................................................ 338
Totalizao dos Valores de Colunas (SUM) .......................................................................... 338
Clculo de Mdias (AVG) ....................................................................................................... 339
Contagem dos Registros (COUNT)........................................................................................ 339
Utilizao da Clusula DISTINCT ............................................................................................... 339
Agrupamento de Informaes Selecionadas (GROUP BY e HAVING) ..................................... 340
Utilizao com HAVING ......................................................................................................... 342
Recuperao de Dados de Vrias Tabelas (JOINS) .................................................................. 342
O Conceito de Qualificadores de Nome ................................................................................. 342
Inner Joins .............................................................................................................................. 344
Cross Join ou Produto Cartesiano ......................................................................................... 345
Outer Joins ............................................................................................................................. 346
Uso de Aliases ....................................................................................................................... 350
Juno de Mais de Duas Tabelas .......................................................................................... 351
Utilizao de Consultas Encadeadas (Subqueries) .................................................................... 354
Inserir, Modificar e Apagar Registros .......................................................................................... 358
Adio de Registro Tabela .................................................................................................. 358
Adio de Registros com um SELECT .................................................................................. 359
Atualizao de um Registro - UPDATE.................................................................................. 360
Alterao de Registros com Dados de Outra Tabela ............................................................. 362
Apagar Registros da Tabela................................................................................................... 363
9
Apagar Registros da Tabela com Base em Dados de Outra Tabela ........................................ 364
Utilizao de Views ..................................................................................................................... 364
Criao de uma View por meio de um Join ............................................................................ 366
Utilizao de uma View ............................................................................................................... 367
Listagem ................................................................................................................................. 367
Insero de Linhas numa View .............................................................................................. 367
Modificao de uma Linha da View ........................................................................................ 368
Apagar .................................................................................................................................... 368
Eliminao de uma View ........................................................................................................ 368
Garantia dos Privilgios de Acesso - GRANT e REVOKE .......................................................... 369
Comando GRANT (Garantir) .................................................................................................. 369
Lista de Opes de Privilgios .......................................................................................... 370
Comando REVOKE (Revogao) .......................................................................................... 371
Trabalho com ndices .................................................................................................................. 372
Um Checklist para Criao de ndices ................................................................................... 372
Quando No Criar ndices ...................................................................................................... 373
Criao de ndices .................................................................................................................. 373
Eliminao de ndices............................................................................................................. 374
Tpicos Avanados de SQL ........................................................................................................ 375
Combinao de Resultados de Pesquisas (UNION) .............................................................. 375
Realizao de um Join entre uma Tabela e Ela Mesma ........................................................ 376
NVL ............................................................................................................................................. 377
A utilizao da expresso condicional DECODE ................................................................... 378
A utilizao da expresso condicional CASE ......................................................................... 378
Trabalho com tempo (campos date)....................................................................................... 379
Estudo de Caso - Banco de Dados ............................................................................................. 379
Captulo 15 - Modelagem de Dados e Mtodos geis ........................................................................ 386

Mtodos geis............................................................................................................................. 386
A refatorao de banco de dados ............................................................................................... 389
O futuro da modelagem de dados ............................................................................................... 390
Bibliografia ............................................................................................................................................. 391
ndice Remissivo ................................................................................................................................... 393

Prefcio
A Modelagem de Dados e o Projeto de Banco de Dados tm sofrido significantes evolu-

es nos anos recentes com o avano de aplicaes empresariais com uso do modelo de
dados relacional e aplicaes em sistemas de bancos de dados.
Este livro continua a concentrar-se nas tcnicas de modelagem e projeto de bancos de
dados para o ambiente relacional com a abordagem entidade-relacionamento, buscando a cria-
o de modelos conceituais, lgicos e fsicos de dados, porm com um olhar sobre as meto-
dologias do estado da arte no desenvolvimento de aplicaes como as tecnologias orientadas
a objetos.
Entendemos que o desenvolvimento de aplicaes continua enfrentando os mesmos
problemas do surgimento dos papers do Dr. Peter Chen, pela inexistncia de farta informao
sobre as tcnicas de modelagem de dados com exemplos do mundo real e tambm, em parte,
pelo pouco estmulo dado aos trabalhos e tempos gastos com o processo de projetar bancos
de dados. Outrossim, o vnculo entre os conceitos de lgebra Relacional na interpretao e
construo de consultas em SQL para bancos de dados relacionais explorado com intuito de
fornecer ao desenvolvedor uma viso mais ampla dos caminhos de navegao por um modelo
de dados.
As mltiplas extenses do modelo original de Peter Chen tambm foram preocupao
neste livro, que explora e apresenta extenses tais como generalizao, agregao, assim
como o tratamento a ser dado, durante a anlise, s interpretaes diferentes de objetos do
mundo real que originam as hierarquias e vises de dados, com exemplos aderentes a situa-
es simples do dia a dia.
A importncia das chaves primrias e estrangeiras tambm bastante discutida e
estudada, objetivando criar no desenvolvedor o costume de sempre utilizar esse padro, que
nada mais que uma exigncia tcnica para integridade e acesso a um banco de dados, seja
ele de que tipo for ou para que aplicao se destine.
Atualmente existe uma incrvel sede de conhecimento para a execuo de projetos de
software no Pas, e despretensiosamente buscamos contribuir em formato educacional e sem
academicismos com uma tcnica j consagrada de projeto de software, mas cujas opes de
soluo ainda so pouco exploradas, e importante por sua capacidade de aderncia ao mundo
real e sua expressividade nos processos de negcios.
Desde a antiguidade o homem procura transmitir e documentar seu conhecimento, obje-
tos e situaes da vida real. Nas cavernas pr-histricas foram encontrados desenhos de ani-
mais, caadas e cenas do cotidiano. Com smbolos que representavam objetos e animais, os
habitantes das cavernas eternizavam a sua realidade. O homem evoluiu.
11
As metodologias que chegam ao Pas, do exterior, centralizam tudo quanto aos projetos
de desenvolvimento de aplicativos. Estes so, por consequncia, proprietrios dos dados. A
modelagem de dados fica ento reduzida, simplesmente, a uma atividade paralela, quase
desconhecida e muitas vezes desprezada. Quando utilizada, seu objetivo meramente
documental.
Ao reconhecer os dados como um dos recursos mais importantes das corporaes,
ultrapassando as prprias fronteiras dos sistemas aplicativos, a modelagem de dados se torna,
com justa razo, a mais importante tcnica utilizada na produo dos resultados das fases de
planejamento e anlise dos projetos de sistemas de informao na era dos bancos de dados
relacionais.
Os princpios bsicos da modelagem de dados j so, nos dias de hoje, conhecidos,
ensinados e divulgados pelos mais diversos meios. Na vida real, entretanto, muitas vezes nos
defrontamos com situaes inusitadas, desconhecidas e que nunca foram cobertas ou sequer
mencionadas em cursos e publicaes. Os projetistas de sistemas de informaes precisam
ento acumular uma vasta experincia na rea, para fazer frente a esses eventos, ou procurar
auxlio externo. Neste sentido, o autor deste livro disponibiliza sua vasta experincia, de uma
maneira clara, simples e didtica, desde os primeiros passos da arte de modelar dados at as
mais avanadas solues.
A questo que sempre se coloca : quantos modelos de dados voc realiza por ano?
Sabemos que durante a permanncia em uma organizao nos envolvemos sempre
com um ou dois sistemas de aplicao, e na maior parte realizamos muitas das vezes somente
manuteno de aplicaes. Isso leva a um cio de modelagem de dados e limita a explorao
de solues e o prprio domnio amplo da tcnica, independentemente da sua importncia.
Estamos cada dia mais ligados a cdigos do que ao projeto de uma aplicao em si.
preciso procurar um balanceamento perfeito entre a anlise dos processos e dos
dados envolvidos, ambos centrados, porm, na viso do negcio, em que a informao o
objetivo final de toda a aplicao. Neste contexto, a modelagem de dados continua a ter uma
importncia maior ainda.
O desafio de criar um livro de leitura e compreenso fceis, que seja instrumento de
referncia de projeto de bancos de dados, foi o fator que motivou a escrev-lo.
Nesta terceira edio, apresentamos um novo captulo importante para apresentar a
relao entre o projeto e a implementao de bancos de dados e a utilizao de mtodos
geis, como o SCrum, assim como as implicaes decorrentes desta associao.
Destacamos os fatores importantes a serem considerados na gesto da implantao de
banco de dados em conjunto com essas metodologias, buscando colocar o contedo deste
livro aderente ao estado da arte em desenvolvimento de software.
O autor

1
O QUE PROJETO DE
BANCO DE DADOS
Durante muito tempo criou-se a ideia de que projetar bancos de dados era uma
disciplina com identidade prpria, uma atividade especfica e at certo ponto isolada no ciclo de
vida de um sistema, que tinha existncia prpria e podia ser realizada a partir de primitivas e
conceitos exclusivos da tcnica de modelagem de dados.
Com a evoluo das tecnologias de desenvolvimento de aplicaes, novas linguagens e
principalmente com o advento da orientao a objetos no mais restrita ao ambiente de
programao, mas extensiva s metodologias de anlise de sistemas, o trabalho de projetar as
bases de dados que sero utilizadas por um sistema em desenvolvimento assume, nos dias de
hoje, caractersticas que objetivam mixar um projeto orientado a objetos com as necessidades
de esse mesmo sistema interagir com um banco de dados relacional, constitudo por um
conjunto de tabelas, que equivale denominada camada de persistncia de dados.
Essa necessidade de mixagem real pela absoluta ausncia de projetos comerciais
que utilizem bancos de dados orientados a objetos que sejam confiveis a grandes massas de
dados, no popularizao desses produtos e aos grandes investimentos j realizados em
softwares de Sistemas Gerenciadores de Bancos de Dados Relacionais existentes no mercado
nacional e mundial.
indiscutvel a vantagem obtida em um projeto orientado a objetos; logo, surge a
necessidade de uma nova tcnica de projetar banco de dados, que no a formatao pura de
classes de dados, mas uma interao alta entre o ambiente de anlise orientada a objetos e a
nossa sempre presente modelagem de dados, que estritamente necessria administrao
de dados da organizao de TI. A utilizao de ferramentas para a camada de persistncia,
tais como o Hybernate, acaba levando o desenvolvedor a deixar de lado a preocupao com
as estruturas do banco de dados, assim como a preocupao com a qualidade das queries
realizadas em uma aplicao.
No existem tcnicas nem ferramentas que possibilitem tanto ao administrador de
dados (DA) quanto ao administrador de bancos de dados (DBA) realizar suas funes sobre
classes de dados, pois esses mesmos bancos de dados relacionais atuam e tm todas as suas
funcionalidades sobre tabelas relacionais de dados, as quais so hoje de domnio maior dos
usurios de aplicaes.
O Que Projeto de Banco de Dados 13

H muito tempo escrevemos sobre modelagem de dados e o processo continua
existindo como sempre existiu, porm o que desejamos neste livro apresentar essas tcnicas
integradas com a anlise orientada a objetos, de forma a permitir que quem trabalha tanto com
OO como com anlise estruturada tenha domnio de projetos de bancos de dados eficientes a
uma aplicao, seja qual for o ambiente de desenvolvimento em que esteja. Busca-se ainda
permitir que um projeto totalmente desenvolvido em OO seja facilmente inserido em um
ambiente de banco de dados relacional, com o mnimo de traumas e mantida a coerncia com
os objetos de negcios de uma organizao.
Modelagem de Dados
Modelagem de dados o estudo das informaes existentes em um contexto sob
observao para a construo de um modelo de representao e entendimento de tal contexto.
A modelagem de dados minera as informaes que representam um contexto, estruturando-as
em um conjunto que denominamos modelo lgico de dados.
Uma das principais caractersticas da abordagem de modelagem de banco de dados
que ela fornece nveis de abstrao de dados que omitem do usurio final detalhes sobre o
armazenamento dos dados. No existe a preocupao com um banco de dados tecnologica-
mente falando.
O modelo de dados um conjunto de conceitos que podem ser utilizados para descre-
ver as estruturas lgicas e fsicas de um banco de dados.
J um modelo de classes de objetos no se detm somente s informaes e dados,
sendo mais amplo no momento em que integra as informaes e os seus mtodos de acesso,
recuperao, processamento e outros em um nico objeto.
Logo, temos de encontrar e separar os dados dos seus processos em um determinado
momento, para que possamos efetivamente obter domnio do negcio para o qual a aplicao
est sendo desenvolvida. Os objetivos reais da aplicao continuam sendo mais facilmente
compreendidos por meio de um modelo de dados, e no de um modelo de objetos.
Normalmente as aplicaes tm sido desenvolvidas com AOO (Anlise Orientada a
Objetos) mesclada com a tradicional modelagem de dados, com a utilizao de paterns, ou
melhor, padres de modelos de dados, que no so obtidos to simplesmente quando da pura
criao de diagramas de classes. Desenvolvemos com isso um processo que pode ser chama-
do two fase commit entre diagrama de classes e modelo de dados Entidade-Relacionamento.
Para que isso possa ser realizado, preciso entender e dominar as tcnicas de
modelagem de dados e depois, finalmente, aprender a lidar com a sua equivalncia em um
modelo de classes de objetos.
O objetivo deste livro explorar e ensinar da melhor forma possvel como modelar da-
dos para ambientes de bancos de dados relacionais, complementando com a implementao
desses bancos seja em um ambiente tradicional, seja em um ambiente orientado a objetos, tal
como uma aplicao desenvolvida em Java, com base em experincias por ns realizadas.

Estrutura a forma como esses dados esto agrupados, os relacionamentos entre eles
e as restries que podem recair sobre eles, o que no totalmente explcito em um diagrama
de classes da anlise orientada a objetos.
Historicamente, os primeiros modelos de bancos de dados datam da dcada de 1960.
Desde ento, a pesquisa cientfica na rea procura evoluir no sentido de definir, encontrar
modelos que representem da melhor maneira possvel os dados de uma realidade, ou seja,
que organizem os dados de uma forma mais prxima da maneira como so vistos e
manipulados pelas pessoas no mundo real.
A ideia definir abstraes que facilitem a compreenso da organizao dos dados
pelo usurio, tornando cada vez mais transparente e independente o conhecimento da
organizao fsica, independente de precisar utilizar o conhecimento tcnico de um conjunto de
tcnicas orientadas a objetos para ter esse entendimento.
O objetivo de um modelo de dados ter certeza de que todos os objetos de dados
existentes em determinado contexto e requeridos pela aplicao e pelo banco de dados esto
completamente representados e com preciso. Pelo fato de os dados modelados usarem
notaes facilmente compreendidas e em um idioma natural, eles podem ser revisados e
verificados pelos usurios finais.
O modelo de dados tambm deve ser detalhado o bastante para ser usado pelo
implementador (DBA) do banco de dados como uma espcie de fotocpia para construir o
banco de dados fsico.
Ser utilizada toda a informao que est no modelo de dados lgico para definir as
tabelas de um banco de dados relacional, chaves primrias e estrangeiras, procedimentos
armazenados (stored procedures) e gatilhos (triggers).
Um banco de dados mal projetado requer mais tempo e retrabalho a longo prazo.
Sem planejamento e anlise cuidadosa voc pode criar um banco de dados que omita
alguns dados exigidos, ou inconsistente em relao ao contexto de informaes que ele deve
refletir. Os resultados incorretos ou incompatveis em uma aplicao sistmica impossibilitam
inclusive acomodar as mudanas de exigncias dos usurios ao longo do tempo, ou implicam
que o banco de dados tenha constante manuteno em suas estruturas e a aplicao fique
extremamente dependente do prprio banco de dados.
Para ser efetivo, um modelo de dados deve ser simples o bastante para comunicar ao
usurio final a estrutura de dados requerida pelo banco de dados e bastante detalhado para o
administrador de banco de dados usar para criao da estrutura fsica correspondente em um
SGBD.
O modelo de Entidade-Relacionamento (ER) o mtodo mais comum para construo
de modelos de dados para bancos de dados de relacionais.
O mais comum em um modelo de dados uma pequena coleo de mecanismos de
abstrao ditos primitivos, que so classificao, agregao e generalizao.

Abstraes ajudam o analista a entender, classificar e modelar uma realidade, alguma
coisa do mundo real que est em observao.
Que Abstrao?
Vamos levar o leitor a resolver exerccios que possibilitem um maior desenvolvimento
dessa sua capacidade, antes de desenvolvermos os conhecimentos e tcnicas especficos de
modelagem de dados.
Uma abstrao ou a capacidade de abstrao um processo, com certeza mental, que
usamos quando selecionamos vrias caractersticas e propriedades de um conjunto de objetos
ou fatos, e exclumos outras que no so relevantes em um contexto. Em outras palavras,
aplicamos abstrao quando nos concentramos nas propriedades de um conjunto de objetos
ou coisas que consideramos essenciais, e desprezamos outras que no consideramos impor-
tantes, sempre dentro de um determinado contexto sob observao ou anlise.
O analista, durante a modelagem conceitual dos dados, deve se concentrar na obser-
vao dos objetos relevantes que existem em uma realidade ou contexto, com a finalidade de
construir um modelo de compreenso e conceitos existentes nessa realidade. Esse primeiro
modelo denominamos de minimundo, sem pensar no momento em automatizar ou processar a
informao dessa realidade.
Abstrao, em sntese, nada mais do que a viso, sem conceituaes tcnicas, que
obtemos na mente de uma realidade qualquer do mundo real.
Por exemplo, quando olhamos a figura ao lado, temos
o resultado de um processo de abstrao em que exclumos
detalhes da estrutura de uma bicicleta, como os pedais, os
freios, os mecanismos de trao e inclusive as possveis
diferenas entre vrias bicicletas, e definimos o objeto como o
que conceituamos e denominamos de "bicicleta". Normal-
mente associamos um nome a cada abstrao. No caso da figura, o conceito bicicleta uma
representao dessa prtica de abstrao. Definimos um conceito para um objeto existente em
contexto sob observao. Denominamos essa capacidade humana de modelo conceitual.
Em realidade o que criamos um modelo de conceitos de objetos em um primeiro
instante que denominamos de modelo conceitual.
Outra representao poderia ser a descrio textual da mesma figura apresentada.
Vamos detalhar mais os conceitos de abstrao e as primitivas em captulo parte neste livro.
Quando modelamos, como veremos no livro, devemos buscar a realidade do ambiente,
o contexto em anlise com total abstrao em primeiro lugar, para somente depois iniciarmos
um processo de modelagem lgico que detalharemos adiante.

Ao coletar e selecionar os objetos relevantes de um contexto, o analista deve identificar
os elementos geradores de cada objeto, as leis que os regem no contexto, bem como as
operaes que incidem sobre os objetos bsicos (dados).
Nesse momento, os documentos que registram esses objetos ou elementos de negcio
s devem ser utilizados como apoio ao entendimento, e no como base para o desenvol-
vimento do sistema de informaes, ou seja, no devemos ter a preocupao de simular o
ambiente atual, seja ele manual ou automatizado.
A preocupao que o analista deve ter retratar as necessidades de informao que as
pessoas (que agem sobre um contexto) precisam para alcanar os objetivos em seu ambiente
de negcios.
Para registrarmos as necessidades de informao de uma realidade e sempre dentro do
contexto desta realidade, precisamos fazer uso de um modelo de dados, ou seja, algo que nos
mostre as informaes existentes e como elas esto relacionadas (regras de negcio).
Com base nesse modelo criado, os analistas podem interagir com os usurios validando
seus objetivos e metas, permitindo o detalhamento do que denominamos base de dados para
construo de um sistema de informaes aderente s necessidades dos usurios finais.
Em seguida apresentamos uma descrio dos principais macroelementos construdos

com a aplicao de tcnicas de abstrao.

Minimundo
Poro da realidade, captada pelo analista, que a gesto de negcios de uma organiza-
o tem interesse em observar, controlar e administrar. A complexidade existente no momento
de analisar um minimundo pode levar o analista a subdividi-lo em partes menores, s quais
damos o nome de viso de processo de negcio.
Banco de Dados
Um banco de dados pode ser definido como um conjunto de dados devidamente
relacionados. Podemos compreender como dados os objetos conhecidos que podem ser
armazenados e que possuem um significado implcito, porm o significado do termo banco de
dados mais restrito que simplesmente a definio dada anteriormente. Um banco de dados
possui as seguintes propriedades:
uma coleo lgica coerente de dados com um significado inerente; uma dis-
posio desordenada dos dados no pode ser referenciada como banco de dados.
Ele projetado, construdo e preenchido com valores de dados para um propsito
especfico; um banco de dados possui um conjunto predefinido de usurios e de
aplicaes.
Ele representa algum aspecto do mundo real, o qual chamado de minimundo;
qualquer alterao efetuada no minimundo automaticamente refletida no banco
de dados.
Modelo Conceitual
Representa, descreve a realidade do ambiente do problema, constituindo-se em uma
viso global dos principais dados e seus relacionamentos (estruturas de informao), comple-
tamente independente dos aspectos de sua implementao tecnolgica.
Quando falamos em modelo conceitual, estamos nos referindo quela que deve ser
sempre a primeira etapa de um projeto de banco de dados.

O objetivo do modelo conceitual descrever de forma simples e facilmente compre-
endida pelo usurio final as informaes de um contexto de negcios, as quais devem ser
armazenadas em um banco de dados.
uma descrio de alto nvel (macrodefinio), mas que tem a preocupao de captar
e retratar toda a realidade de uma organizao, processo de negcio, setor, repartio, depar-
tamento etc.
importante destacar que o modelo conceitual no retrata nem vinculado aos
aspectos ligados abordagem do banco de dados que ser utilizado, tampouco se preocupa
com as formas de acesso ou estruturas fsicas implementadas por um Sistema Gerenciador de
Banco de Dados especfico. Sem modelo conceitual no temos uma viso clara das regras
do negcio e acabamos por criar aplicaes sem entender para que elas foram criadas.
O resultado de um modelo conceitual um esquema grfico que representa a realidade

das informaes existentes em determinado contexto de negcios, assim como as estruturas
de dados em que esto organizadas essas informaes.
O modelo conceitual nunca deve ser construdo com consideraes sobre processos de
negcio, com preocupaes de acesso aos dados, no devendo existir nenhuma preocupao
com o modo como sero realizadas as operaes de consulta e manuteno dos dados nele
apresentados. O foco deve ser dirigido sempre ao entendimento e representao de uma
realidade, de um contexto.
Modelo Lgico
Ele somente tem incio aps a criao do modelo conceitual, pois agora vamos considerar
uma das abordagens possveis da tecnologia Sistemas Gerenciadores de Banco de Dados
(relacional, hierrquica, rede ou orientada a objetos) para estruturao e estabelecimento da
lgica dos relacionamentos existentes entre os dados definidos no modelo conceitual.
A elaborao direta e um modelo lgico de dados, independentemente de j sabermos a
abordagem para banco de dados, para a qual estamos realizando um projeto, levam vinculao
tecnolgica de nosso raciocnio, perturbando a interpretao pura e simples de um contexto.
Sempre que analisamos um contexto sob a ptica tecnolgica, temos a tendncia de sermos

tcnicos demais, distorcer a realidade, conduzindo-a s restries da tecnologia empregada, o
que sempre, e j estatisticamente comprovado, leva a erros de interpretao da realidade,
criando assim modelos de dados que no possuem aderncia ao minimundo descrito.
O modelo lgico descreve em formato as estruturas que estaro no banco de dados de

acordo com as possibilidades permitidas pela sua abordagem, mas sem considerar, ainda,
nenhuma caracterstica especfica de um Sistema Gerenciador de Banco de Dados (SGBD).
Isso resulta um esquema lgico de dados sob a ptica de uma das abordagens citadas, pelo
emprego de uma tcnica de modelagem de dados orientada s restries de cada abordagem.
Modelo Fsico
O modelo fsico ser construdo a partir do modelo lgico e descreve as estruturas
fsicas de armazenamento de dados, tais como:
Tipo e tamanho de campos;
ndices;
Domnio de preenchimento desses campos;
Nomenclaturas;
Exigncia de contedo;
Gatilhos etc.
Elas so projetadas de acordo com os requisitos de processamento e uso mais econ-
mico dos recursos computacionais. Esse modelo detalha o estudo dos mtodos de acesso do
SGBD para criao dos ndices necessrios para cada informao colocada nos modelos
conceitual e lgico.

Esta a etapa final do projeto de banco de dados, na qual ser utilizada a linguagem de
definio de dados do SGBD (DDL) para a realizao da sua montagem no dicionrio de dados.
Em ambiente de banco de dados relacional denominamos script de criao do banco de dados o
conjunto de comandos em SQL (DDL) que ser executado no Sistema Gerenciador de Banco de
Dados para a criao de banco de dados correspondente ao modelo fsico.
A seguir apresentamos um exemplo de script (conjunto de comando DDL) escrito em
SQL para criao de um pequeno banco de dados:
CREATE TABLE Empregado (
codigo_empregado INTEGER NOT NULL,
tipo_empregado CHAR(15) NULL,
nome CHAR(35) NULL,
cota VARCHAR2(9) NULL,
PRIMARY KEY (codigo_empregado));
CREATE UNIQUE INDEX XPKEmpregado ON Empregado

( codigo_empregado ASC);
CREATE TABLE Area (
codigo_regiao CHAR(2) NOT NULL,
tipo_regiao CHAR(25) NULL,
nome CHAR(30) NULL,
codigo_empregado INTEGER NULL,
codigo_regiao_superior CHAR(2) NULL,
PRIMARY KEY (codigo_regiao),
FOREIGN KEY (codigo_regiao_superior)
REFERENCES Area,
FOREIGN KEY (codigo_empregado)
REFERENCES Empregado);
CREATE UNIQUE INDEX XPKArea ON Area
(codigo_regiao ASC);
CREATE INDEX XIF1Area ON Area
(codigo_empregado ASC);
CREATE INDEX XIF2Area ON Area
(codigo_regiao_superior ASC);
O Projeto de Banco de Dados

Todo projeto de sistema de banco de dados necessita de um foco, um centro nervoso.
A modelagem de um banco de dados por meio da abordagem Entidade-Relacionamento repre-
senta esse ponto central no projeto conceitual de um sistema.

O objetivo da modelagem de dados transmitir e apresentar uma representao nica,
no redundante e resumida, dos dados de uma aplicao. Em projetos conceituais de aplica-
es em banco de dados o modelo Entidade-Relacionamento o mais largamente utilizado
para representao e entendimento dos dados que compem a essncia de um sistema.
O projeto de banco de dados para sistemas de aplicao, hoje em dia, no mais uma
tarefa a ser realizada somente por profissionais especializados em bancos de dados da rea
de desenvolvimento de sistemas, mas tambm por analistas de sistemas independentemente
de experincia anterior em um determinado produto de banco de dados, pela utilizao de
tcnicas estruturadas como a modelagem conceitual de dados Entidade-Relacionamento.
O projeto de um sistema de informaes atividade complexa que inclui planejamento,
especificaes e desenvolvimento de vrios componentes.
O que se prope situar a sequncia dessas atividades em uma ordem que possa
resultar ganhos de produtividade e confiabilidade dos sistemas desenvolvidos, eliminando
sensivelmente as falhas de sistema aps sua implantao.
Desafortunadamente as metodologias de projeto de banco de dados, para sistemas de
aplicao, apesar de j serem muito populares entre a comunidade tcnica, no so utilizadas
corretamente.
Em vrias organizaes os profissionais utilizam-se de pequenas tcnicas pessoais, ou
ainda pior, de uma inexistncia completa de metodologia para esses projetos e com distores
na utilizao das tcnicas, sendo esta uma das maiores causas de falhas nos sistemas de
informao desenvolvidos, mesmo com a existncia de modelos de dados.
A utilizao de abordagem correta de metodologia orientada a modelagem de banco de
dados envolve a estruturao nos trs nveis de viso de dados vistos anteriormente, ou seja,
trs etapas na execuo de um projeto: conceitual, lgico e fsico.
Isola-se desta forma a realidade a ser retratada em dados de suas implicaes lgicas e
fsicas, determinando o momento para adequao do modelo construdo ponderao desses
fatores.
evidente e bvio que a realidade dos negcios de uma empresa simplesmente
diferente da realidade de outra empresa, mesmo que os ambientes sejam similares. Existem
particularidades que s dizem respeito ao funcionamento de um ambiente especfico.
Devido a essa no similaridade completa entre ambientes de mesma natureza, ser
sempre necessria a criao de um modelo especfico para cada nova realidade observada.
Fica bem claro, ento, a necessidade de ter uma metodologia estruturada que permita
construir vrios modelos, resultando o chamado metamodelo, ou seja, uma tcnica especfica
de ampla abrangncia e flexibilidade.
O metamodelo a ser utilizado deve ter a caracterstica de poder modelar qualquer
realidade, ter uma forma de trabalho bastante simples e caractersticas grficas que sejam bem
simples de construir e entender.
O nosso metamodelo o modelo Entidade-Relacionamento (ER).

Como j destacamos, o modelo de dados um plano para construir o banco de dados.
Para ser efetivo, deve ser simples o bastante para comunicar ao usurio final a estrutura de
dados requerida pelo banco de dados e detalhada o suficiente para criar a estrutura fsica de
banco de dados.
O modelo Entidade-Relacionamento (ER) o mtodo mais comum para a construo
de modelos de dados para bancos de dados relacionais.
O Modelo Entidade-Relacionamento (ER)

Ele foi proposto originalmente por Peter, em 1976 (CHEN, 1976), como um modo de
unificar as vises de um banco de dados relacional, e teve como base a teoria relacional criada
por E. F. Codd (1970).
Simplesmente declarado como modelo de ER, ele conceitual e v o mundo real como
entidades e relacionamentos. Um componente bsico do modelo o diagrama de Entidade-
-Relacionamento, que visualmente representa objetos de dados.
Ao longo dos anos, vrios estudiosos (Theorey, Fry, James Martin, entre outros) evolu-
ram e expandiram esse metamodelo.
Segundo Chen, a viso de uma determinada realidade baseia-se no relacionamento
entre as entidades, as quais retratam os fatos que governam essa mesma realidade, e cada
um (entidade ou relacionamento) pode possuir atributos (qualificadores descritivos dessa
realidade).
Grande parte das extenses ao metamodelo baseia-se em alguns mecanismos de
abstrao: classificao, generalizao e agregao.
O conceito de abstrao, como j destacamos, permite ao analista separar da realidade
em estudo as partes que so realmente relevantes para o desenvolvimento do sistema de
informaes e excluir da modelagem todos os aspectos que no exercem influncia sobre o
ambiente a ser modelado.
Os conceitos do modelo ER destinam-se prioritariamente ao projeto de banco de dados,
entretanto eles podem ser utilizados para o entendimento de um determinado negcio, por
exemplo, na modelagem de processos de negcios (modelo do negcio), bem como auxiliar o
desenvolvimento de estruturas de dados que possam ser implementadas fora de um ambiente
de banco de dados, utilizando-se uma linguagem de programao (Cobol, C, Pascal etc.).
O modelo ER ainda a base para o desenvolvimento de sistemas orientados a objetos.
Somente o domnio das tcnicas de modelagem no suficiente para produzir bons
modelos. O essencial na modelagem de dados o total entendimento dos conceitos perten-
centes realidade em questo.
Ao modelar dados, ou qualquer outra coisa, o objeto observado, o ambiente sob an-
lise ser sempre o ponto de partida. Ele serve como referncia para a construo de todo o

modelo. Por este motivo a fase de levantamento de dados, investigao e anlise dos dados
propriamente dita to importante.
O processo de modelagem consiste em cinco aspectos importantes:
Observao: entrevistas, reunies, questionrios, anlise de documentos aliados
ao conhecimento e experincia prvios da rea de negcios ou seu perfeito
entendimento e compreenso.
Entendimento dos conceitos: ncleo do processo de modelagem. Essa fase
destina-se a identificar, conceituar, entender e assimilar o objeto observado.
Representao dos objetos: aplicao de tcnicas de modelagem de dados
Entidade-Relacionamento.
Verificao de fidelidade e carncias: detectar falhas e anomalias, identificando
respectivas causas que podem residir em conceitos malformados, pontos de vista
equivocados, falha na concepo ou aplicao errada da tcnica de representao.
Validaes: nessa fase busca-se a aprovao formal do modelo. Para que esse
objetivo seja alcanado, necessria a participao ativa do usurio final, bem
como a viso de outros profissionais da rea tcnica (administrador de dados,
analista de sistemas, administrador de banco de dados etc., de acordo com o
caso). Esse processo deve ser rigoroso e crtico, tanto quanto possvel.
As tcnicas de modelagem de dados devem ser disseminadas rea usuria para que
a validao no se transforme em um monlogo de analistas de sistemas e deixe de cumprir o
seu verdadeiro objetivo (detectar falhas e anomalias), porm nunca tente fazer do usurio final
um expert no assunto modelagem de dados.
A Implementao de Banco de Dados

Em sntese a criao efetiva em um Sistema Gerenciador de Banco de Dados de uma
estrutura de dados correspondente ao modelo fsico derivado do modelo construdo por meio
das tcnicas de modelagem Entidade-Relacionamento.

Muitas vezes ouvimos afirmaes como: projeta-se o modelo Entidade-Relacionamento,
mas o que se implementa um conjunto de tabelas que muitas vezes no tm nada a ver com
o modelo projetado.
Em suma isso at ocorre, mas constitui um ERRO da administrao de dados em
conflito com a administrao de banco de dados, pois o modelo de tabelas, por assim
dizer, implementado deve obrigatoriamente corresponder ao modelo lgico derivado do modelo
conceitual projetado.
Em empresas so muitas as situaes cujo modelo de dados desprezado em
decorrncia de os projetistas no possurem abrangncia de aspectos fsicos e operacionais de
um Sistema Gerenciador de Banco de Dados no tocante forma de recuperao dos dados
nele inseridos, quanto utilizao de ndices ou disponibilidade de rea de armazenamento e
viso da populao que vai ter um banco de dados. Isso faz com que o projetista de BD seja
meramente conceitual, saltando-se desta forma o modelo lgico ou o conceitual, tratando o
processo de modelagem em somente dois nveis:
Modelo conceitual e fsico, ou
Modelo lgico e fsico.
Isso provoca buracos de anlise bem sensveis que conduzem a uma implementao
equivocada e de alto ndice de manuteno das aplicaes e do banco de dados.
Sejam quais forem os processos utilizados, completos ou parciais, devemos validar
esse modelo antes de implement-lo efetivamente, pela aplicao de conceitos e comandos de
lgebra relacional na busca de recuperao das informaes que nele estaro.
fundamental para o projetista de banco de dados que ele possua capacitao na
navegao do banco de dados proposto e implementado e, principalmente, compreenso do
modelo, conhecendo seus caminhos de navegao. Apresentamos a lgebra relacional em
captulo especfico adiante.
Quando falamos de lgebra relacional, destacamos o fator de importncia que ela
assume em relao ao projeto de banco de dados, destacando a seguinte afirmativa:
De que adianta projetar banco de dados se no sei como recuperar suas informaes?
De que adianta saber comandos SQL se no sei como a estrutura interna de um
comando para recuperar dados de um conjunto de tabelas?
Foi comprovado, ao longo do tempo, que o domnio e o conhecimento de lgebra
relacional dotam o analista de sistemas da capacidade de resolver qualquer tipo de consulta
necessria navegao e recuperao de situaes, da mais simples mais complexa exigida
em uma aplicao de banco de dados.

Concluso
So indiscutveis as vantagens de trabalharmos hoje em dia com orientao a objetos,
pelo alto ndice de reutilizao de cdigo, pela simplicidade de criao de aplicaes e pela
alta velocidade de desenvolvimento, mas, outrossim, tambm indiscutvel a contnua neces-
sidade de executar a modelagem de dados para que as duas tcnicas se complementem na
execuo de sistemas eficazes que utilizem tecnologia Java, por exemplo, com um banco de
dados relacional.
Como o ambiente tradicional em que so implementados os bancos de dados proje-
tados o de bancos de dados relacionais, vamos detalhar tambm a abordagem relacional de
bancos de dados que, por mais escrita, lida e estudada, mantm a importncia da aderncia
de seus conceitos para o processo de projeto de bancos de dados.

2
ABSTRAO EM
MODELAGEM DE DADOS
Como j citamos no captulo anterior, preciso usar de abstrao para construo de
um modelo de conceitos sobre uma realidade em observao.
Mas como usar a abstrao?
Este um ponto em que vamos levar o leitor a executar exerccios que possibilitem um
maior desenvolvimento dessa sua capacidade.
Repetindo a nossa afirmao, abstrao ou a capacidade de abstrao um processo,
digamos, mental, que usamos quando selecionamos vrias caractersticas e propriedades de
um conjunto de objetos ou fatos, e exclumos outras caractersticas que no so relevantes.
Em outras palavras, aplicamos abstrao quando nos concentramos nas propriedades de um
conjunto de objetos ou coisas que consideramos essenciais, e desprezamos outras que no
consideramos importantes.
No exemplo do captulo anterior vimos como resultado
de um processo de abstrao uma bicicleta, da qual exclumos
detalhes da estrutura, como os pedais, os freios, os mecanis-
mos de trao e, inclusive, as possveis diferenas entre vrias
bicicletas e associamos um nome abstrao. A figura da bici-
cleta era a representao dessa abstrao.
Abstrao em sntese nada mais do que a viso, sem conceituaes tcnicas, que
obtemos na mente de qualquer realidade que observamos no mundo real.
O que queremos buscar com a conceituao a utilizao mental desse processo de
abstrao, que fundamental para um processo de anlise de sistemas.
No existe neste caso a desculpa de que no podemos gastar tempo no desenvolvi-
mento de um projeto com tcnicas de abstrao, pois em realidade sempre o fazemos, porm
com baixa intensidade e sem preocupao e destaque para isso. Podemos sim, e ainda
devemos ter essa caracterstica como relevante no processo de desenvolvimento, pois ela vai
permitir que se obtenham todas as variantes que vo influenciar na criao de um modelo de
dados, assim como a qualidade e a esttica desses modelos tambm so fundamentais.
Abstrao em Modelagem de Dados 27

Existem trs tipos de abstrao que vamos utilizar em modelo conceitual de dados, ou
melhor, para a construo de modelos conceituais de dados: classificao, agregao e
generalizao, como nos referimos no captulo anterior. Lembre-se de que so tipos de
abstrao e nada tm ainda a ver com os conceitos de entidades e relacionamentos da tcnica
Entidade-Relacionamento de Peter Chen.
Classificao de Abstrao
O processo chamado de classificao de abstrao o utilizado por ns para definir o
conceito de uma classe de objetos ou coisas do mundo real caracterizadas por propriedades
comuns.
Por exemplo, o conceito de bicicleta uma classe de objetos cujos membros so todas
as bicicletas semelhantes (bicicleta azul, vermelha, a minha bicicleta etc.). Similarmente o
conceito de ms uma classe cujos membros so janeiro, fevereiro, maio etc.
Quando pensamos em um ms, nos abstramos nas caractersticas especficas de cada
ms, por exemplo, o nmero de dias daquele ms, e ainda enfatizamos na mente aspectos
comuns a todos os meses, como os dias predefinidos como o primeiro e o ltimo dia do ms,
que os meses so aproximadamente iguais em tamanho, 28 ou 31 dias.
Podemos representar a classificao graficamente com um nvel maior com o nome da
classe e um segundo nvel com os elementos que pertencem a essa classe.
Nos exemplos referidos teremos para bicicleta:
Para ms:
Observe que este um processo incondicional que realizamos mentalmente. No est

ligado ou relacionado a nenhuma tecnologia, porm espontneo do nosso processo de
raciocnio e entendimento do universo como tal.

Agregao de Abstrao
Agregar significa compor parte de alguma coisa.
O conceito de agregao de abstraes significa
que podemos entender classes de coisas como elementos
de composio de outra classe maior.
Algo como entender que um conjunto de vrias
classes compe outra classe superior.
Vamos supor que as classes guido, pedais, coroas
e rodas sejam o nosso ponto inicial de anlise, pois as
encontramos ao analisarmos o universo de componentes
de uma bicicleta.
Essas classes existem, pois temos vrios tipos de coroa, de pedal etc., e essas classes
vo compor o que denominamos classe bicicleta.
Devemos entender este conceito como um objeto que composto de partes.
O processo de entendimento tanto pode ser realizado por decomposio de partes
como pelo entendimento e compreenso inicial das partes at chegarmos ao todo.
Generalizao de Abstrao
A generalizao de abstrao ocorre quando definimos um subconjunto de relaciona-
mentos entre elementos de duas ou mais classes. Por exemplo, a classe veculo a generali-
zao da classe bicicleta, pois toda bicicleta um veculo.
Estamos generalizando um conceito que temos de uma realidade.
Logo, veculo uma generalizao da classe de objetos bicicleta.
Como visualizar isso em coisas mais simples?
Vamos olhar a cozinha em casa. Neste livro vamos falar muito do armrio de cozinha
com alimentos e produtos de limpeza.
Imagine voc entrar na sua cozinha e olhar para o armrio da despensa.
Quais os conceitos do que voc observa? Alimentos, materiais de limpeza, panelas?
Epa! Temos j duas classes no mnimo: classe alimentos e classe materiais de limpeza.
Veja que seu primeiro nvel de abstrao de generalizao.
Voc identifica objetos como alimentos e materiais de limpeza.

Mentalmente distinguimos e relacionamos componentes e participantes dessas duas
classes. Temos ento um processo de classificao e generalizao de coisas abstratas at o
momento: alimentos e materiais de limpeza.
Alimento uma classe de objetos e produto de limpeza outra classe de objetos.
Por que ento um processo de generalizao neste caso?
Analisando os objetos da classe alimentos, vamos perceber que h classes menores
dentro dela, por exemplo, lquidos e temperos.
Ora, amigos, na classe lquido temos leos, azeites, vinagres etc.
Em temperos podemos ter pimenta, caldo de carne, organo etc.
Graficamente existe a demonstrao inicialmente da classificao:
Para a classe temperos:
Para a classe lquidos:
Agora vamos entender graficamente a generalizao.

Observe que no momento em que realizamos uma segunda ordenao das classes que
possuem vrias coisas, estamos generalizando ou classificando em um nvel de hierarquia. Isto
generalizar.
Dizer que temperos, lquidos, massas e gros so alimentos generalizar as classes
temperos e companhia em alimentos.
A Cozinha
Como exerccio voc deve realizar a classificao completa dos produtos de limpeza,
pois certamente encontrar os dois processos.
Para obter um processo de agregao, experimente abstrair em relao a uma feijoada,
que pertence classe de alimentos preparados. Imagine aquela feijoada enlatada ou a que
voc come aos sbados.
Provavelmente, para os que leem e concluem at agora isto bvio.
Mas, em realidade, na hora em que fazemos anlise de sistemas no utilizamos metodi-
camente esse processo de abstrao, principalmente na anlise de dados. Se utilizssemos,
obteramos certamente modelos mais consistentes com a realidade a que se destinam ou a
qual devem refletir.
O processo comum nos seres humanos ao analisarem um ambiente, uma pequena
poro do mundo real, de interpret-lo por meio de uma agregao.
Inconscientemente realizamos sempre um processo de entendimento em um mais alto
nvel, o de conceitos agregados.
Vejamos ainda o caso da cozinha.
Perguntando a um aluno quais objetos, conceitos ele obtinha ao observar uma cozinha,
a resposta imediata foi eletrodomstico.
Eletrodomstico uma classe de objetos, um conceito de algo em uma realidade,
entretanto uma generalizao ou uma classificao?
Se considerarmos que a cozinha j tem um conceito de utenslios de cozinha, existem
mais conceitos em uma cozinha a serem explorados. Eletrodomstico faz parte de utenslios
de cozinha, uma parte de utenslios de cozinha, logo agregamos essa abstrao em relao
ao conceito de utenslios de cozinha.
Mas eletrodomstico pode ser um liquidificador, um forno micro-ondas, uma geladeira,
um fogo.
Podemos ainda lembrar que panelas e talheres so utenslios de cozinha.
Como organizar esse conjunto imenso de conceitos abstratos?
Bem, j sabemos que eletrodomstico uma classe de conceitos.

Eletrodomsticos podem ser de vrios tipos: liquidificador, forno micro-ondas, batedeira,
torradeira etc.
Mas existe uma classe acima na hierarquia de interpretao, que a classe utenslios
de cozinha.
Se observarmos, veremos que mais coisas existem numa cozinha. Talheres, alimentos,
materiais de limpeza e panelas, por exemplo.
A nossa anlise inicial somente se dete-
ve nos alimentos, classificando-os em temperos
e lquidos.
Mas devemos realizar uma observao e
um esforo no sentido de refinar e classificar o
melhor possvel o conceito de alimento, pois
cada elemento do armrio, por exemplo, pode
ter uma classificao diferenciada dentro da
classe alimento.
A figura serve para lembr-lo de que temos frutas, verduras, legumes, acar, pes etc.
Logo, devemos eliminar a tendncia generalista e simplesmente parar a nossa anlise aps a
obteno de um conceito simples, pois o perfeito entendimento de uma realidade composto
da definio clara de todos os objetos que o realizam.
Para utilizar a modelagem conceitual de dados com a tcnica de entidades e relaciona-
mentos, necessitamos utilizar ao mximo os conceitos de abstrao. Somente abstraindo o
nosso entendimento de uma realidade que obteremos resultados e esquemas puramente
conceituais sobre a essncia de um sistema, ou melhor, sobre o negcio para o qual estamos
desenvolvendo um projeto, no representando procedimentos ou fluxo de dados de processos
existentes.
No livro Projeto de Banco de Dados: Uma Viso Prtica, publicado pela Editora rica,
afirmamos que modelagem de dados como a arte fotogrfica. Prepara-se a cmera e tira-se
a foto, sem se importar com os movimentos, mas cabe destacar que essa foto interpretada
pela nossa capacidade de abstrao, e nela aplicamos os conceitos apresentados.
Entretanto, o esquema produzido pelo trabalho de modelagem de dados possibilita a
visualizao dos fatos que ocorrem, fornece uma noo clara de movimento, dinmica de

negcios e permite que realizemos a abstrao das atividades e procedimentos que podem ser
exercidos sobre eles.
Comear por Dados

A teoria de que a anlise de um sistema deve comear sempre por dados se justifica
pela estabilidade que os dados possuem para representar qualquer realidade.
Em segundo lugar fato evidente que no conseguimos entender nenhum procedi-
mento sem os dados.
Vamos voltar cozinha para demonstrar.
Como preparar um prato, cozinhar se voc no tiver a receita do prato? Voc precisa de
dados para executar um processo, para entender um procedimento.
Para executar, preparar um prato, voc precisa dos ingredientes obrigatoriamente. A
execuo de uma receita culinria nada mais do que a sequncia em que voc mistura e
acrescenta os ingredientes, com um dado importante sempre que o tempo de execuo.
Como voc pode entender o que cozinhar um prato se no souber os seus dados
principais, que so os ingredientes? Simplesmente impossvel!
Agregaes Binrias
Agregaes binrias, segundo Batini, Navathe e Ceri, no livro Conceptual Database
Design, so o mapeamento estabelecido entre duas classes de coisas, ou objetos que visuali-
zamos atravs de abstrao.
Por exemplo, motorista representa a agregao binria de uma classe pessoas e de
uma classe veculos.
Ela existe quando se estabelece uma correspondncia entre os elementos de duas
classes. Obviamente, interpretamos esse mapeamento como um fato, o fato de uma pessoa
dirigir um veculo. Novamente preciso destacar que tambm utilizamos abstrao para fatos
e acontecimentos.
Esse tipo de abstrao que nos permite entender as relaes entre os objetos e fatos
do mundo real.
Vamos expandir um pouco mais nossos exemplos.

Considerando a realidade comum de moradia, um fato,
um negcio ou um acontecimento, como quiser neste primeiro
momento, qual conjunto de coisas ns podemos abstrair e
classificar nesta realidade?
Existem pessoas que moram em imveis, assim como
existem pessoas que so os proprietrios de imveis em que
vamos morar ou que vamos alugar.
Abstraindo ento temos um conjunto de coisas agrupadas que formam a classe imvel,
e temos outro conjunto de coisas que denominamos pessoa, uma outra classe de objetos com
vrios elementos cada um.
Ao realizarmos uma abstrao binria, ou melhor, uma anlise
binria, obteremos os fatos que retratam a correspondncia ou relao
existente entre elementos dos objetos em anlise.
Pessoa proprietria de imvel.
Pessoa morador ou locador de imvel.
Temos duas classes mais neste caso: proprietrios e morado-
res, e isso caracteriza uma abstrao binria, pois essas classes
somente existem como resultado da associao, da correspondncia
entre elementos das outras duas classes. Somente existem em funo
de fatos que ocorrem no mundo real.
Genericamente podemos afirmar que, em realidade, em um imvel podem morar
diversas pessoas no decorrer do tempo, porm somente uma pessoa proprietria do imvel.
Esta observao relata o que se chama de cardinalidade do mapeamento entre as
classes. Essa cardinalidade descreve a forma como as coisas, os elementos de um grupo
ou classe se correspondem ou se relacionam com os elementos da outra classe ou grupo de
coisas.
Cardinalidade Mnima
Considerando a relao entre duas classes de objetos denominadas C1 e C2, cardina-
lidade mnima de C1 nesta relao o menor nmero de vezes que cada elemento de C1 pode
participar da relao.
Vejamos no nosso exemplo de pessoas e imveis.
Consideremos as agregaes binrias de proprietrio e morador entre pessoas e
imveis.

Se ns considerarmos que cada pessoa mora em somente um imvel, a cardinalidade
mnima igual a 1 (um), considerando-se a leitura dessa relao no sentido da classe pessoas
e a agregao binria aluga e a classe imveis.
Ou seja, uma pessoa aluga somente um imvel.
Se ns considerarmos que muitos imveis podem no estar sendo habitados, ou seja,
no mora ningum neles, ento a cardinalidade mnima 0 (zero), considerando-se a classe
imvel e a agregao binria aluga.
Na realidade significa que um imvel pode estar alugado ou estar vazio, desabitado.
Se analisarmos agora a relao entre a classe pessoas e a agregao binria proprie-

trio, ou seja, o mapeamento de elementos de pessoas e imveis na agregao binria
proprietrio, temos a figura em seguida.
Se analisarmos a relao olhando por pessoas, podemos afirmar que muitos elementos
de pessoa no so proprietrios de nenhum imvel, logo a cardinalidade mnima 0 (zero).
Se analisarmos a relao olhando imveis em relao pessoa, a agregao proprie-
trio vai nos apresentar uma cardinalidade mnima de 1, pois todo imvel tem no mnimo um
proprietrio.
O importante neste momento de abstrao analisarmos a correspondncia, a relao
entre as duas classes de objetos em dois sentidos para que seja possvel obter o entendimento
correto da realidade que estamos observando e modelando.

Cardinalidade Mxima
Assim como analisamos e registramos a cardinalidade mnima, devemos analisar a
cardinalidade mxima em cada uma dessas relaes.
Se considerarmos que cada pessoa pode morar em vrios imveis, a cardinalidade
mxima em realidade infinita, ou no tem limites.
Se assumirmos que cada imvel pode ter vrios moradores, a cardinalidade mxima
tambm infinita.
No sentido de imvel podemos afirmar que cada imvel pode ter muitos proprietrios,
logo a cardinalidade mxima tambm infinita, ou seja, representada por = n.
Porm, se considerarmos que cada imvel tem no mnimo obrigatoriamente 1 (um) proprie-
trio e somente pode pertencer a uma pessoa, ento a cardinalidade mxima tambm 1 (um).
Esta exemplificao mostra que os valores importantes de cardinalidade mxima so 1
e n respectivamente; n representa qualquer nmero e indica que cada elemento de uma classe
possui um grande nmero de relaes com outra classe de objetos.
Se a cardinalidade mnima igual a 1 e a cardinalidade mxima tambm igual a 1,
dizemos que essa agregao binria de um-para-um. Se a agregao possui uma cardina-
lidade mnima = 1 e uma cardinalidade mxima igual a n, dizemos que uma agregao de
um-para-muitos. Finalmente, se a agregao possui ambas as cardinalidades iguais a n, dize-
mos que de muitos-para-muitos.

Caro leitor, analise qualquer situao em que voc se abstraia e classifique classes de
coisas. Logo aps estude as classes de relao que existem entre essas classes. A partir do
momento em que estabelecemos uma relao entre os dois conjuntos de objetos ou coisas,
podemos ento determinar por meio de uma anlise criteriosa a cardinalidade existente nessa
relao.
Exerccios de Abstrao
1. Observe agora o seu ambiente de trabalho, seu escritrio. Utilizando a abstrao, execute
a identificao dos conceitos que existem no ambiente, dos objetos e suas classificaes e
agregaes.
2. Identifique o contexto de uma videolocadora XXX, uma empresa prestadora de servios
com sede no Rio de Janeiro, cuja principal finalidade a locao de fitas de vdeo, DVDs e
games. Com o intuito de melhor atender a seus clientes oferece alguns outros tipos de
servio, tais como:
a. Reserva de fitas/DVDs/games com antecedncia de um dia.
b. Entrega de fitas/DVDs/games locados cujo nmero exceda trs unidades.
c. Venda de fitas de vdeo/DVDs/games.
d. Encomenda de fitas/DVDs/games para venda.
e. Venda de produtos de consumo diferenciados, tais como balas, chocolates, pipoca,
refrigerantes, artigos e acessrios para vdeo, som e imagem.

3. O setor de compras de uma empresa possui uma srie de atividades, mas vamos exercitar
a capacidade de abstrao na rea de controle de solicitaes de compra a fornecedores.
A seguir h um descritivo das principais atividades. Capte delas os objetos, classificaes
e agregaes possveis.
A rea recebe as solicitaes de reposio ou compra de produtos.
Identifica se um produto regular de estoques ou se uma compra de produto
especfico, e se existirem solicitaes do mesmo produto, unifica a necessidade
totalizando as quantidades solicitadas.
Verifica em planilhas os fornecedores que disponibilizam cada produto e realiza
cotao de preos para a solicitao. Se no existir ocorrncia anterior de forneci-
mento, busca no mercado os fornecedores que possuem o produto solicitado e
realiza uma cotao de preos.
Elabora uma planilha de cotaes por fornecedor, produto e preos, efetua os
clculos de custos por produto/fornecedor e escolhe o fornecedor.
Ao fornecedor escolhido dada uma ordem de compra de produtos especificando
produto, quantidades, preo, prazos de pagamento e condies gerais de entrega.
As compras so acompanhadas at o momento da conferncia de recebimento dos
produtos adquiridos, comparando os dados da nota fiscal do fornecedor com os
dados e condies da ordem de compra.
Aps o recebimento so atualizadas as planilhas de compras realizadas, mantendo
um histrico de desempenho de fornecedores quanto a prazos de entrega e condi-
es de preo e pagamentos, alm de informaes sobre o controle de qualidade
dos produtos adquiridos.
Observe que no so muitos os objetos existentes neste contexto, e sim mais pro-
cessos que permitiro ao leitor identificar as relaes entre as classes encontradas e
suas cardinalidade.

3
BANCOS DE DADOS
RELACIONAIS
Introduo
Este livro define os conceitos bsicos de modelo de dados Entidade-Relacionamento,
aplicados anlise de sistemas de informao, e apresenta os conceitos originais realizados
por Peter Chen e estendidos por outros autores.
A utilizao de modelagem de dados nos trabalhos de desenvol-
vimento de sistemas de informao cresceu muito nos ltimos anos,
entretanto esses trabalhos continuam dirigidos a aspectos fsicos dos
Sistemas Gerenciadores de Bancos de Dados, tais como ndices e
performance, provocando uma acelerao no processo de desenvol-
vimento que leva o analista de sistemas a criar estruturas de dados que
no refletem nenhuma realidade de forma clara, criando bancos de dados
inchados, e principalmente instveis, contrariando alguns dos preceitos
lanados por Codd, criador da Teoria Relacional.
O livro destina-se a projetar aplicaes de Tecnologia da Informao orientadas a
bancos de dados relacionais. Logo, para que isso se concretize, preciso que haja um
entendimento correto de como so realizadas as operaes lgicas sobre os dados de um
banco de dados relacional, assim como esto organizados esses dados nessas estruturas
lgicas.
Criado por Edgar F. Codd, nos anos de 1970, comeou a ser realmente utilizado nas
empresas a partir de 1987. A abordagem relacional est baseada no princpio de que as
informaes em uma base de dados podem ser consideradas relaes matemticas e que
esto representadas de maneira uniforme com o uso de tabelas bidimensionais.
Este princpio coloca os dados direcionados a estruturas mais simples de armazena-
mento de dados, que so as tabelas, e nas quais a viso do usurio privilegiada.
comum observarmos analistas desenhando modelos de dados sem preocupao ou
conhecimento lgico dos processos de recuperao e navegao em um banco de dados
relacional, assim como no dedicando ateno suficiente lgica por trs dos conceitos de
chaves primrias e estrangeiras.
Bancos de Dados Relacionais 39

Observe que uma concepo lgica. Claro que inerente a uma tecnologia
especfica, a dos bancos de dados relacionais, porm so as concepes lgicas lanadas por
Edgard Codd que norteiam a Teoria Relacional, em um formato lgico, que posteriormente foi
implementado nas tecnologias dos Sistemas Gerenciadores de Bancos de Dados Relacionais.
Teoria Relacional
Agora vamos estudar os conceitos lgicos de banco de dados relacional, que ajudaro
a entender e navegar em dados existentes em bancos dados relacionais.
Em 1970, Edgar F. Codd ofereceu-nos uma colaborao revolucionria ao formular o
modelo de dados relacional. Em 1979, Codd e tambm Chris Date refinaram o modelo
relacional, chegando ao que se denominou modelo relacional estendido.
A abordagem relacional representa uma forma de descrever o banco de dados atravs
de conceitos matemticos simples: a teoria dos conjuntos.
Voltada, principalmente, a melhorar a viso dos dados pelos usurios, a abordagem
relacional faz com que os usurios vejam o banco de dados como um conjunto de tabelas
bidimensionais, originadas em linhas e colunas.
Definio Clssica
So conjuntos de dados vistos segundo um conjunto de TABELAS, e as operaes que as

utilizam so feitas por linguagens que o manipulam, no sendo procedurais, ou seja, manipu-
lando conjuntos de uma s vez.
O conceito principal vem da teoria dos conjuntos atrelado concepo de que no

relevante ao usurio saber onde os dados esto nem como os dados esto (transparncia).
Tabela de Clientes
CodCliente NomCliente RuaCliente CidadeCliente

1 Luis Sampaio Rua A Rio de Janeiro
2 Carlos Pereira Rua B Niteri
3 Jos Alves Rua C Rio de Janeiro
4 Luis Paulo Souza Rua D Niteri
Os usurios manipulam estes objetos dispostos em linhas e colunas das tabelas que
possuem informaes sobre o mesmo assunto de forma estruturada e organizada.

NumReg NomeFunc DtAdmisso Sexo CdCargo CdDepto
101 Luis Sampaio 10/08/2003 M C3 D5
104 Carlos Pereira 02/03/2004 M C4 D6
134 Jos Alves 23/05/2002 M C5 D1
121 Luis Paulo Souza 10/12/2001 M C3 D5
195 Marta Silveira 05/01/2002 F C1 D5
139 Ana Luiza Magalhes 12/01/2003 F C4 D6
123 Pedro Sergio Doto 29/06/2003 M CC7 D3
148 Larissa Silva 01/06/2002 F C4 D6
115 Roberto Fernandes 15/10/2003 M C3 D5
22 Sergio Nogueira 10/02/2000 M C2 D4
CdCargo NumCargo VlrSalario

C1 Aux Vendas 350,00
C3 Vendedor 800,00
C7 Diretor 2500,00
C2 Vigia 400,00
C5 Gerente 1000,00
C4 Aux Cobrana 250,00
Para lidar com estes objetos, o usurio conta com um conjunto de operadores e funes
de alto nvel, constantes na lgebra relacional.
A Teoria Relacional possui premissas que definem uma tabela de dados:
Cada uma das tabelas chamada de relao.
O conjunto de uma linha e suas colunas chamado de tupla.
Cada coluna dessa tabela tem um nome e representa um domnio da tabela.
A ordem das linhas irrelevante.
No h duas linhas iguais.
Usamos nomes para fazer referncia s colunas.
A ordem das colunas tambm irrelevante.
Cada tabela tem um nome prprio, distinto de qualquer outra tabela no banco de
dados.
Vamos analisar algumas tabelas de dados para entendermos como esto organizados
os dados em um banco de dados relacional.
importante que exercitemos a mente para enxergar dados dentro de uma tabela
relacional sempre que nos referirmos ao nome dela, e no somente a estrutura de seus dados.
Por exemplo, uma tabela de CDs para o nosso microcomputador:

Tabela de CDs
Nmero do CD Data da Gravao Ttulo do Contedo Responsvel Local onde est guardado
1 24/1/2001 Clipart Samir Estojo Verde
3 13/2/2000 IRRF 2000 Felipe Caixa Docs
2 14/12/2000 Backup textos Felipe Estojo Azul
4 25/1/2000 Fotos Gramado Samir Cx. lbum 3
Este livro utiliza como nomenclatura o que existe mais tradicionalmente, que chamarmos de
tabelas e no de relaes, assim como utiliza linhas em vez de tuplas.
Mas observe nesta simples tabela de CDs que os conceitos listados anteriormente em
relao s tabelas relacionais esto destacados:
A ordem das linhas irrelevante, pois o CD nmero 2 vem aps o CD de nmero 3.
Se observar mais detalhadamente, voc ver que o CD nmero 3 tem uma data
inclusive menor que o CD nmero 2.
Nenhuma linha se repete nesta tabela.
A ordem das colunas tambm no tem nenhum destaque, ou importncia, pois no
esto em nenhuma ordem lgica.
Todas as colunas tm nome, que identifica o seu contedo, ou melhor, o significado
do valor de seu contedo.
Vamos observar outra tabela para fixar este entendimento:
Tabela de Funcionrios, a clssica de exemplos
Nome Sexo Matrcula Departamento Cargo Salrio

Joo Carlos Masc. 373 TI - Operaes Operador 3.000,00
Carlos Brito Masc. 872 TI - Programao Programador I 3.500,00
Silvia Moraes Fem. 963 TI - Anlise Analista Sist II 5.500,00
Cludia Tereza Fem. 161 TI - Gerncia Secretria 1.500,00
Pedro Julio Masc. 292 R. H. Diretor 6.000,00
Pedro Julio Masc 574 TI - Anlise Analista Sist I 4.500,00
Vamos analisar estes dados, j que parece que todos tm mais facilidade de entender
esta tabela, talvez por j terem visto em tantos e tantos livros.
A coluna Matrcula no indica nenhuma ordem para as linhas, confirmando o conceito
de que a ordem das linhas irrelevante.
Todas as colunas tm um nome referente ao assunto, o que bem evidente.

A disposio das colunas no tem nenhuma finalidade de classificao, tampouco
indica ordem de leitura dos dados.
Observe o exemplo seguinte em que modificamos a ordem das colunas, sem prejuzo
nenhum do assunto ou da representatividade da tabela.
Tabela Funcionrios
Salrio Nome Sexo Matrcula Departamento Cargo

3.000,00 Joo Carlos Masc. 373 TI -Operaes Operador
3.500,00 Carlos Brito Masc. 872 TI - Programao Programador I
5.500,00 Silvia Moraes Fem. 963 TI - Anlise Analista Sist II
1.500,00 Cludia Tereza Fem. 161 TI - Gerncia Secretria
6.000,00 Pedro Julio Masc. 292 R. H. Diretor
4.500,00 Pedro Julio Masc 574 TI - Anlise Analista Sist I
O importante que toda vez que nos referirmos tabela funcionrios visualizemos os
dados que ela contm, e simulando valores possveis, pois assim vamos mentalizando e nos
abstraindo em algum objeto que a tabela representa.
Caractersticas Principais de uma Relao

(Tabela Relacional)
Vamos definir a concepo tcnica de uma relao (tabela).
DtAdmisso
NumReg NomeFunc Sexo Telefone CdDepto
Dia Ms Ano
101 Luis Sampaio 10 08 2003 M 2565-8974 D5
104 Carlos Pereira 02 03 2004 M 3131-4649 D6
134 Jos Alves 23 05 2002 M 2386-8897 D1
121 Luis Paulo Souza 10 12 2001 M 2241-5896 D5
5693-521 /
195 Marta Silveira 05 01 2002 F 5694-8523 / D5
5694-852
139 Ana Luiza Magalhes 12 01 2003 F 4545-8899 D6
123 Pedro Sergio Doto 29 06 2003 M 4296-8853 D3
148 Larissa Silva 01 06 2002 F 4289-9675 D6
115 Roberto Fernandes 15 10 2003 M 2685-8132 D5
22 Sergio Nogueira 10 20 2000 M 2594-3122 D4
Atributo composto Atributo multivalorado

Todos os atributos (colunas) de uma relao devem ser atmicos, isto , indivisveis em
termos de valores e componentes.
Isso quer dizer que no existem colunas do tipo subgrupo, todas so itens elementares
no subdivididos em nenhuma hiptese E tambm no permitida a existncia da mltipla
ocorrncia de valores (multivalorao) em nenhum de seus atributos (colunas). Observe o
exemplo anterior.
importante a compreenso de que cada linha de uma tabela representa um objeto,
um assunto que descrito pelos valores de cada uma dessas colunas.
O esquema de uma relao, ou seja, a sua definio, pode ser interpretada como uma
declarao, ou um tipo de afirmao.
O exemplo de uma tabela funcionrio apresenta:
Nmero de Registro (NUMREG), Nome do Funcionrio (NOMEFUNC), Data de
Admisso (DTADMISSO), Sexo (SEXO), Telefone (TELEFONE) e Departamento
(CDDEPTO).
Cada tupla (linha) da relao (tabela) deve ser interpretada como um fato ou uma
ocorrncia particular dessa afirmao.
Fato NumReg NomeFunc DtAdmisso Sexo Telefone CdDepto

Existe um funcionrio 101 Luis Sampaio 10/08/2003 M 2565-8974 D5
de nome Luis Sampaio
104 Carlos Pereira 02/03/2004 M 3131-4649 D6
de NumReg="101, com
data de admisso em 134 Jos Alves 23/05/2002 M 2386-8897 D1
'10/08/2003', do sexo 121 Luis Paulo Souza 10/12/2001 M 2241-5896 D5
'masculino', com
195 Marta Silveira 05/01/2002 F 5693-521 D5
telefone '2565-8974 e
CdDepto = "D5". 139 Ana Luiza Magalhes 12/01/2003 F 4545-8899 D6
123 Pedro Sergio Doto 29/06/2003 M 4296-8853 D3
148 Larissa Silva 01/06/2002 F 4289-9675 D6
115 Roberto Fernandes 15/10/2003 M 2685-8132 D5
22 Sergio Nogueira 10/02/2000 M 2594-3122 D4
Domnio
Representa o conjunto de valores atmicos admissveis de um componente (coluna) de
uma relao (tabela).
Exemplo:
Telefone: conjunto de 10 dgitos.
CPF: conjunto de 7 dgitos.
Idade_Empregado: 16 idade 70.
Departamentos: conjunto de departamentos de uma empresa.

A cada domnio est associado um tipo de dados ou formato.
Exemplo:
Telefone (ddd) dddd-dddd em que d = {0,1,2,...,9}.
IdadeEmpregado: nmero inteiro entre 16 e 70.
Um esquema de uma tabela R, definida por R(A1,A2,...,An), um conjunto de atributos
do tipo R = {A1,A2,...,An}.
Cada atributo Ai o nome de um papel realizado por algum domnio D na tabela R, ou

seja, o nome de uma coluna na tabela R.
Restries de domnios so estabelecidas determinando-se domnios de valores para
cada coluna de uma tabela. Normalmente so estabelecidos e definidos os valores que uma
coluna de uma tabela pode ter, isto , o domnio da coluna.
Permitem, por exemplo:
Verificar os valores inseridos em um banco de dados.
Testar consultas para garantir que as comparaes tenham sentido.
Em geral o domnio especificado por tipos primitivos de dados, tais como integer,
float, char, date, time, money etc.
Tambm podem ser descritos pela definio de subconjuntos de tipos primitivos ou de
listas enumeradas, ou seja, lista de valores possveis de existir na coluna.
Observando os conceitos at agora descritos, destacamos

mais um detalhe:
Nenhuma linha se repete tambm nesta tabela. Concorda?
Poderia o leitor questionar: posso ter duas pessoas com o
mesmo nome?
Claro que sim. mais comum ocorrer do que voc possa
imaginar, mas como eles tm matrculas na empresa diferentes,
as linhas da tabela so obviamente diferentes.
Se o leitor for atuar como analista em rgos pblicos em nosso pas, vai encontrar
situaes deste tipo: o mesmo servidor com duas matrculas. Isso parece uma anormalidade,
porm fato corriqueiro em administrao pblica.
Se cada linha da tabela representa um fato, no faz sentido descrevermos o mesmo
fato mais de uma vez. Motivo conceitual bsico para definir que no existem duas linhas iguais
em uma mesma tabela.
Que outras caractersticas importante entender e utilizar em uma tabela relacional?

Por exemplo, como garantir que as linhas no se repitam em uma tabela relacional?
Essa garantia conseguida pela propriedade e conceito de chave primria.
Mas, efetivamente, o que uma chave primria?
Chave Primria
Em toda e qualquer tabela existente em um banco de dados relacional haver sempre
uma coluna ou um conjunto de colunas concatenadas, cujos valores so nicos na tabela, isto
, nunca se repete aquele valor em nenhuma outra linha da tabela.
Essa coluna ou conjunto de colunas concatenadas identifica uma nica linha da tabela.
Ento dizemos que essa coluna ou conjunto de colunas forma a chave primria da tabela.
Observe que falamos em uma coluna ou conjunto de colunas concatenadas.
O que analisamos o valor de cada coluna ou desse
conjunto para que no se repitam, ou no possam se repetir.
Ao definirmos uma chave primria, se no observarmos
corretamente, podemos definir erradamente a chave primria
de uma tabela.
Na tabela anterior que apresentamos de funcionrios ainda no havamos definido a
sua chave primria, o que vamos efetivar neste ponto:
Olhe a tabela:
Nome Sexo Matrcula Departamento Cargo Salrio

Joo Carlos Masc. 373 TI -Operaes Operador 3.000,00
Carlos Brito Masc. 872 TI -Programao Programador I 3.500,00
Silvia Moraes Fem. 963 TI - Anlise Analista Sist II 5.500,00
Cludia Tereza Fem. 161 TI - Gerencia Secretria 1.500,00
Pedro Julio Masc. 292 R. H. Diretor 6.000,00
Pedro Julio Masc 574 TI - Anlise Analista Sist I 4.500,00
Qual coluna ou conjunto de colunas que, concatenadas, formam um identificador nico

para cada linha desta tabela?
Nome? Com certeza no, pois se repete. Sexo? Idem, se repete.
Departamento tambm no, e cargo e salrio sozinhos tambm no fazem nada.
Sobra neste caso a nica coluna que no tem valores repetidos, que matrcula.

Matrcula
Existe somente um valor de matrcula para cada linha, que no se 373
repete, logo podemos determinar que matrcula a chave primria da 872
tabela funcionrios. 963
Vamos tentar observar uma tabela mais complicadinha, em que 161
tenhamos de realizar um estudo maior para determinar a chave primria. 292
574
Vamos imaginar que temos uma tabela que apresenta registros de consumo de bebidas
em um hotel.
Tabela de Consumo de Bebidas
Valor Local Data Hora Valor

Bebida Qtde Quarto
Unitrio Consumo Consumo Consumo Total
Cerveja Long Neck 2 3 Restaurante 101 22/01/2001 14:30 6.00
Chopp 3 2 Bar 203 19/01/2001 11:00 8.00
Cerveja Long Neck 2 3 Restaurante 101 23/01/2001 14:30 6.00
Refrig. Lata 3 2 Restaurante 203 20/01/2001 05:45 6.00
Mate 1 1,5 Frigobar 407 21/01/2001 16:30 1.50
Caf 1 0,8 Restaurante 203 18/01/2001 08:00 0.80
Suco 1 3 Service Room 505 22/01/2001 21:30 3.00
Mate 1 1,5 Restaurante 203 21/01/2001 16:30 1.50
Chopp 4 2 Bar 101 19/01/2001 17:10 8.00
gua Min. 1 1 Frigobar 203 18/01/2001 08:30 1.00
Caf 1 0,8 Restaurante 18/01/2001 18:00 0.80
Observe com ateno esta tabela.

Que coluna ou conjunto de colunas poderamos utilizar para definir como identificador
nico de cada linha?
Poderamos utilizar, por exemplo, a concatenao das colunas Bebida e Quarto do
hotel?
Se observarmos com ateno, veremos que quando existe um segundo consumo da
mesma bebida no mesmo bar, perde-se a caracterstica de identificador nico, pois o valor, por
exemplo, Cerveja Long Neck_101, se repete.

Data Hora Valor
Bebida Qtde Valor Unitrio Local Consumo Quarto
Consumo Consumo Total
Cerveja
2 3 Restaurante 101 22/1/2001 14:30 6.00
Long Neck
Cerveja
2 3 Restaurante 101 23/1/2001 14:30 6.00
Long Neck
Se acrescentarmos o local de consumo concatenao das colunas referidas, tambm

no obteremos a condio de identificador nico, pois um outro consumo da mesma bebida,
pelo mesmo quarto em datas diferentes, propiciaria a existncia de duas ocorrncias de linhas
iguais.
Data Hora Valor

Cerveja
2 3 Restaurante 101 22/1/2001 14:30 6.00
Long Neck
Cerveja
2 3 Restaurante 101 23/1/2001 14:30 6.00
Long Neck
Valores resultantes da concatenao de colunas:
Bebida+Local Consumo+Quarto
Cerveja Long NeckRestaurante101
ChoppBar203
Refrig. LataRestaurante203
MateFrigobar407
CafRestaurante203
SucoService Room505
MateRestaurante407
ChoppBar203
gua Min.Frigobar101
CafRestaurante203
Chaves encontradas repetidas:

Vamos ento tentar acrescentar uma coluna concatenao que estamos tentando: a
data de consumo.

Como teoricamente os consumos foram realizados em datas diferentes, podemos
inserir a data na composio da chave primria.
Bebida+Local Consumo+Quarto+Data Consumo

Cerveja Long NeckRestaurante10122/1/2001
ChoppBar20319/1/2001
Refrig. LataRestaurante20320/1/2001
MateFrigobar40721/1/2001
CafRestaurante20318/1/2001
SucoService Room50522/1/2001
MateRestaurante40721/1/2001
gua Min.Frigobar10118/1/2001
Desta vez no aparecem valores repetidos? Ser que conseguimos efetivamente uma
chave primria?
Voltando a analisar toda a tabela e seus dados, existe algum caso em que estes valores
estejam repetidos?
Classificando as concatenaes obtidas, podemos observar se existem repeties:
Bebida+Local Consumo+Quarto+Data Consumo

MateFrigobar40721/1/2001
MateRestaurante40721/1/2001
Refrig. LataRestaurante20320/1/2001
SucoService Room50522/1/2001
Observe o consumo do Mate pelo quarto 407, o consumo de Chopp do quarto 203 e o
consumo de Caf do mesmo 203.
Para estes casos houve dois consumos na mesma data.

Data Hora Valor
Chopp 3 2 Bar 203 19/1/2001 11:00 8.00
Chopp 4 2 Bar 203 19/1/2001 17:10 8.00
Caf 1 0,8 Restaurante 203 18/1/2001 08:00 0.8
Caf 1 0,8 Restaurante 203 18/1/2001 18:00 0.8
Mate 1 1,5 Frigobar 407 21/1/2001 16:30 1.50
Mate 1 1,5 Restaurante 407 21/1/2001 16:30 1.50
Porm, os dois consumos de Mate foram realizados em locais diferentes, logo o valor
de nossa chave primria diferente nas duas linhas em questo. O consumo de Chopp do
quarto 203 e o consumo de Caf do quarto 203 tambm foram ambos realizados no mesmo
local e na mesma data. Logo, no podemos utilizar esta concatenao como a chave primria
desta tabela. Ento vamos continuar a analisar o contedo da tabela para concluirmos melhor.
Analisando os valores da tabela, percebemos que os dois consumos foram realizados
no mesmo local, mesma data e pelo mesmo quarto, mas em horrios diferentes. Salvao!
Temos ento mais uma alternativa para finalmente obtermos a chave primria. Vamos
concatenar mais uma coluna, a coluna horrio do consumo, e ver como fica o resultado desta
concatenao.
Colunas Concatenadas
Bebida+Local Consumo+Quarto+Data Consumo+Hora Consumo

CafRestaurante20318/1/200111:00
CafRestaurante20318/1/200114:30
Cerveja Long NeckRestaurante10122/1/200108:45
ChoppBar20319/1/200108:00
ChoppBar20319/1/200121:30
MateFrigobar40721/1/200116:30
MateRestaurante40721/1/200117:10
Refrig. LataRestaurante20320/1/200108:30
SucoService Room50522/1/200118:00
Os casos que temos de concatenao com repetio de valores foram eliminados, no

existindo agora nenhuma linha repetida nesse resultado, ou seja, no existem dois valores
iguais nesta tabela para o resultado da concatenao de colunas.

Logo, podemos definir como chave primria da tabela o conjunto de colunas concatenas
pelo qual obtivemos este resultado:
Chave Primria (Primary Key) =

Bebida + Local Consumo + Quarto + Data Consumo + Hora Consumo
Veja a importncia de darmos ateno ao contedo possvel em uma tabela de banco

de dados antes de determinarmos a sua chave primria.
Vamos continuar e estudar outra caracterstica importante da chave primria de uma
tabela relacional.
Valores Nulos e Integridade de Identidade

Para a apresentao deste tpico necessrio o perfeito entendimento do significado
de valor nulo. Vamos ilustrar abstraindo-nos em alguma realidade do dia a dia.
O que existe no mundo que contm de tudo o que
se imagina? Resposta: as bolsas femininas.
Este mundo incrivelmente inventivo faz com que
esses fantsticos seres coloquem os objetos mais incr-
veis e at s vezes absurdos dentro das pequenas e
mdias bolsas que sempre carregam orgulhosas.
A pergunta que colocamos neste momento : qual o valor do contedo de uma dessas
bolsas olhando-a simplesmente, sem abri-la e sem ter visto o que foi colocado nela?
O leitor pode dizer:
Deve ter .........hummm..???? hummmm...??????
Deve ter, pois voc no sabe o que h l dentro.
Para voc o contedo da bolsa no instante desconhecido. uma informao perdida,
ou no disponvel, logo nula a sua resposta.
O valor do contedo da bolsa logo nulo.
Vamos a outro exemplo. Ao observarmos a sada
de um shopping, vemos muitas pessoas carregar sacolas
de compras. Elas nunca saem com uma sacola somente.
Pergunta-se:
Qual o contedo daquelas sacolas para quem as
observa, sem abri-las?
(O marido apavorado!)

Voc deve concordar comigo que o contedo desconhecido. Voc tem certeza de que
existe alguma coisa dentro, porm no sabe o que nem quanto custou.
O valor do contedo de cada bolsa ento um valor nulo para nossa mente!
Concluindo, ento, valor nulo um valor ausente, desconhecido para ns.
Por definio, todas as linhas de uma tabela tm de ser distinguveis umas das outras,
devem possuir um identificador nico.
Um identificador de chave primria nulo significa dizer que existe uma ocorrncia (linha)
na tabela sem identificao nica, ou no distinguvel.
Se uma tabela relacional tem uma chave primria, que um valor nico para cada linha
da tabela, logo esse valor no pode em hiptese nenhuma estar nulo, ou seja, ser desco-
nhecido.
Estendendo este conceito, destacamos que nenhuma das colunas que participam da
composio da chave primria pode ter valor nulo, pois o resultado da concatenao seria
nulo, em uma operao de concatenao de valores.
Imagine o leitor ento nossa tabela utilizada como exemplo na qual existisse uma linha
cuja data e hora de consumo fossem no informadas ou no registradas, desconhecidas, isto
, fossem colunas com valor nulo como apresentado em seguida:
Data Hora Valor

Cerveja
2 3 Restaurante 101 nula nula 6.00
Long Neck
Cerveja
2 3 Restaurante 101 23/1/2001 14:30 6.00
Long Neck
O resultado da concatenao de colunas neste caso seria:
Bebida+Local Consumo+Quarto+Data Consumo+Hora Consumo

NULO
Qualquer valor concatenado com nada igual a nada.

No caso de consumos do hotel, isto quer dizer, por exemplo, que no poderamos ter
uma linha de consumo sem a existncia de um valor para a data de consumo e hora de con-
sumo. Voc no poderia localizar o consumo nem confirm-lo.
O leitor poderia questionar, como j aconteceu de um aluno perguntar:
Considerando que s existe uma linha cuja concatenao resultou em valor nulo, e esse valor
nulo logicamente no se repete na tabela, por que no vlido como identificador nico
(afinal ele nico na tabela)? Por que no pode ser chave primria?

A resposta simples; um valor nulo no identifica absolutamente nada. uma questo
mais conceitual do que matemtica.
Como recuperar a linha cuja identificao nula?
Como identificar uma pessoa cujo registro de nascimento nulo, ou seja, desconhecido?
Qual o valor de um consumo que no podemos identificar quando ocorreu? Voc
aceitaria ser cobrado por um consumo em um hotel sem que ele fosse identificado?
Imagine esta situao:

O atendente do check-out do hotel informa-lhe:
O senhor consumiu duas cervejas no restaurante, mas
no sabemos informar o dia nem a hora, porm o valor de
R$ 10,00.
Voc pagaria?
Se voc pagar, vai permitir que isso se repita! Logo,
permitir chave primria duplicada.
Se permitirmos valores nulos como chave primria, como garantir que no se repitam?
Regra de Integridade de Identidade

Desta forma conclumos que a identificao de uma linha de uma tabela no pode ser
feita por um valor desconhecido, motivo pelo qual a chave primria de uma tabela no pode
possuir nenhum elemento de sua composio com valor nulo.
Chave Primria
Coluna ou concatenao de colunas.
Valor nico na tabela.
Cada linha tem um valor diferente na chave primria.
No existem valores nulos na chave primria.
Atributos cujos valores no mundo real podem ser duplicados no devem ser definidos
como chaves de uma tabela (Nome, como j destacamos).
Em geral, uma tabela pode ter mais de uma chave que possua a capacidade de identifi-
cao nica das linhas da tabela. Neste caso, cada uma dessas chaves da tabela chamada
de CHAVE CANDIDATA.

Uma das chaves definida como primria e as outras ficam como chaves alternativas
chave primria.
Em geral, entre todas as chaves candidatas, escolhe-se para chave primria aquela
com o menor nmero de atributos ou mais significativa conceitualmente na identificao de
cada fato ou ocorrncia (linha) de uma tabela.
Esquema de uma Tabela

A definio de uma tabela relacional realizada por um formato denominado esquema
da tabela. Esse formato destaca a chave primria por um sublinhado no nome da coluna:
Para a tabela de funcionrios que apresentamos o esquema seria:
Funcionrio {NUMREG, NOMEFUNC, DTADMISSAO, SEXO, TELEFONE, CDDEPTO}
Chave Estrangeira
Uma tabela relacional, como j vimos, uma estruturao dos dados por assunto,
organizada em tabelas com linhas e colunas, e cada linha a representao de uma
ocorrncia de um objeto, um assunto, descrita por valores em cada coluna. Dessas colunas j
sabemos que uma ou um conjunto delas forma o que definimos como o identificador nico de
cada linha que a chave primria da tabela.
Vamos agora apresentar outras propriedades que as colunas de uma tabela relacional
podem ter e as regras dessas propriedades.
Continuando o estudo, vamos analisar mais caractersticas das colunas das tabelas em
um banco de dados relacional, e para isso utilizaremos um conjunto de tabelas em um banco
de dados como apresentado em seguida.
Existem trs tabelas nesse pequeno banco de dados.
So as tabelas referentes aos produtos de nossa cozinha, neste caso somente os
alimentos. Uma chamaremos de tabela de Estoque de alimentos, uma de Fornecedores e uma
de Unidade de armazenamento.
Uma caracterstica importante nas tabelas relacionais que elas tm muitas vezes
colunas comuns.

Estoque de Alimentos
Alimento Quantidade Data Validade Fabricante Unidade

Feijo 2 20/08/2004 2 1
Leite 3 12/07/2004 4 2
Acar 5 12/08/2004 1 1
Arroz 3 10/10/2004 6 1
Azeite 2 12/03/2004 5 6
Caf 1 12/12/2004 3 1
Fornecedores Unidades de Armazenamento
Fabricante NomeFab Unidade Descricao

2 Coral 1 Kg
4 CCPL 2 Litro
1 Unio 3 Pea
6 Tio Joo 4 Envelope
5 Galo 5 Pote 500 g
3 Pilo 6 Vidro 500 g
Esquema do Banco de Dados

Estoque de Alimentos {ALIMENTO, QUANTIDADE, DATA VALIDADE, FABRICANTE, UNIDADE}
Fornecedores {FABRICANTE, NOME FABRICANTE}
Unidades de armazenamento {UNIDADE, DESCRICAO}
Observe que a tabela de Estoque de alimentos tem as colunas Nmero do Fabricante e
Cdigo da Unidade, que tambm existem, respectivamente, nas tabelas Fornecedores e
Unidade de armazenamento.
Esta uma caracterstica que em primeiro lugar tem como objetivo evitar que sejam
inseridos na tabela de alimentos, por exemplo, valores relativos a um mesmo fornecedor de
duas maneiras: Tio Joo e T. Joo, fazendo com que apresentssemos o mesmo produto
como se fossem de dois fornecedores diferentes.
Isso ajuda a eliminar ou diminuir erros de entrada de dados nos sistemas, e manter a
consistncia do banco de dados, pois utilizamos o nmero do fornecedor em lugar de, talvez,
digitar o seu nome. Isso ser objeto do captulo de normalizao neste livro.
Mas bem, o que significa uma tabela ter coluna ou colunas que existem em outra tabela
do mesmo banco de dados?
Analisando a figura anterior e o esquema do banco de dados, observamos que cada
tabela tem uma chave primria.

A tabela Estoque de alimentos tem como chave primria a coluna Alimento.
A tabela Fornecedores tem como chave primria a coluna Fabricante, e a tabela
Unidades de armazenamento tem como chave primria a coluna Unidade.
O que significa quando temos um campo que chave primria de uma tabela que faz
parte dos campos de outra tabela?
Isso o que denominamos de chave estrangeira.
uma referncia de um elemento de uma tabela a um elemento de outra tabela, uma
relao entre as tabelas, uma ligao lgica entre elas.
Unidades de
Armazenamento
Fabricante NomeFab
1 Kg
2 Litro
Estoque de Alimentos 3 Pea
4 Envelope
Alimento Quantidade Data Validade Fabricante Unidade
5 Pote 500 g
Feijo 2 20/08/2004 2 1
6 Vidro 500 g
Leite 3 12/07/2004 4 2
Acar 5 12/08/2004 1 1
Fornecedores
Arroz 3 10/10/2004 6 1
Azeite 2 12/03/2004 5 6 Fabricante NomeFab
Caf 1 12/12/2004 3 1 2 Coral

4 CCPL
1 Unio
6 Tio Joo
5 Galo
3 Pilo
Ento, em nosso exemplo a coluna Fabricante na tabela Estoque de alimentos uma

chave estrangeira, assim como Unidade tambm outra chave estrangeira nesta tabela.
Uma tabela pode ter tantas chaves estrangeiras quantas forem as suas associaes a
outras tabelas.
Uma tabela pode ter um conjunto de atributos que contm valores com o mesmo
domnio de um conjunto de atributos que formam a chave primria de uma outra tabela.
Esse conjunto se chama chave estrangeira.
Vejamos outro exemplo clssico e simples.

Funcionrio

134 Jose Alves 23/5/2002 M C5 D1
123 Pedro Sergio Doto 29/6/2003 M C7 D3
Departamento Cargo
CdDepto NumDepto RamalTel CdCargo NumCargo VlrSalario

D1 Assist.Tcnica 2246 C1 Aux Vendas 350,00
D2 Estoque 2589 C3 Vendedor 800,00
D3 Administrao 2772 C7 Diretor 2500,00
D4 Segurana 1810 C2 Vigia 400,00
D5 Vendas 2599 C5 Gerente 1000,00
D6 Cobrana 2688 C4 Aux Cobrana 250,00
A coluna CdDepto na tabela Funcionrios uma chave estrangeira, pois ela chave
primria na tabela Departamentos.
A coluna CdCargo em Funcionrio tambm uma chave estrangeira, pois ela chave
primria em Cargos
Para lembrar e fixar, vamos deixar neste ponto regras que norteiam o conceito de
chave estrangeira em uma tabela.
Sempre que uma coluna de uma determinada tabela A (Funcionrio) for uma chave primria
em uma tabela B (Cargo), essa coluna (CodCargo) na tabela A uma chave estrangeira em
relao mesma coluna (CodCargo) na tabela B.
Este conceito estabelece uma regra em bancos de dados relacionais denominada de

integridade referencial.
Vamos ento entender um pouco mais isso.
Integridade Referencial
Quando colocamos uma coluna como chave estrangeira em uma tabela, assumimos
responsabilidade com o banco de dados por assim dizer.

As colunas pertencentes chave estrangeira da tabela A devem ter o mesmo domnio
das colunas pertencentes chave primria da tabela B.
O valor de uma chave estrangeira em uma tabela A deve ser de chave primria da
tabela B, ou ento ser nulo.
Sintetizando, uma tabela contm uma chave estrangeira, ento o valor dessa chave s
pode ser:
Nulo. Neste caso pode, pois representa a inexistncia de referncia para uma linha
da tabela.
Igual ao valor de alguma chave primria na tabela referenciada.
Voc pode perguntar como ficaria uma tabela com chave estrangeira nula. Vejamos:
Funcionrio

134 Jose Alves 23/5/2002 M C5 D1
123 Pedro Sergio Doto 29/6/2003 M Nulo D3
Na linha de Pedro Sergio Doto o valor para CdDepto est nulo, o que pode significar
que ainda no est alocado a nenhum departamento, ou foi deslocado de algum departamento.
O que importa que ele no tem um departamento assinalado, o que uma situao
vlida.
O que no pode haver um valor de chave estrangeira que no exista como chave
primria de nenhuma linha da tabela referenciada, no caso a tabela Departamento.
Na definio de uma chave estrangeira somente podemos nos referenciar a uma chave
primria de uma outra tabela?
Nem sempre isso verdade.
Na criao de uma chave estrangeira, alm de podemos nos referenciar a um campo
chave primria de outra tabela, tambm podemos nos referenciar a uma coluna que tenha sido
definida como nica, uma chave candidata.
Qual a razo da integridade referencial? O que ela implica?

Restries para Garantir a Integridade Referencial
Existe um conjunto de regras de operao para um banco de dados relacional que
coloca restries, regras nas operaes de atualizao das tabelas do banco de dados, de
forma a garantir e manter a integridade referencial.
PARENT DELETE RESTRICT: (Deleo Restrita)

Ao excluir (deletar) a tabela pai (parent), se ela possuir filhos relacionados (ou seja, se o
departamento tiver funcionrios), a excluso impedida (RESTRICT).
Isso evita que o banco de dados fique inconsistente, ou seja, linhas de Funcionrio com
valor de chave estrangeira inexistente como chave primria na tabela associada.
Outras opes para garantir a integridade de referncias do banco de dados seriam
excluir todos os filhos em cascata (CASCADE), fazendo com que todos os funcionrios
referenciem um departamento padro, CdDepto=3 (Administrao), por exemplo, ou fazer com
que todos os funcionrios fiquem sem departamento, CdDepto = NULL
CHILD INSERT RESTRICT: (Incluso e Linha Restrita)

Ao inserir um funcionrio, caso seja obrigatrio que j possua departamento associado,
verifica se ele est relacionado a um departamento existente na tabela Departamento, seno
impede a operao (RESTRICT).
CHILD UPDATE RESTRICT:

Ao atualizar (UPDATE) a chave estrangeira de uma tabela (CHILD), verifica se existe
uma linha da tabela associada que possua como chave primria o novo valor da chave
estrangeira, seno impede essa operao (RESTRICT).
A opo Cascade (Cascata) sempre perigosa de ser utilizada em banco de dados,
pois existe o risco de perder todos os dados existentes em uma determinada tabela se optar
por apagar as suas linhas que esto associadas a uma determinada linha que ser deletada da
tabela que possui a chave primria referenciada.
Vamos observar esta hiptese com uma simulao de tabelas.
Suponha que a tabela tenha somente os funcionrios do departamento de vendas (D5).

Funcionrio

134 Jose Alves 23/5/2002 M C5 D1
Departamento
CdDepto NumDepto RamalTel

D1 Assist.Tcnica 2246
D2 Estoque 2589
D3 Administrao 2772
D4 Segurana 1810
D5 Vendas 2599
D6 Cobrana 2688
Se estabelecermos para a tabela Departamento a regra de Cascade, e apagarmos

(deletar) a linha cuja chave primria ="D5", o resultado ser a tabela funcionrio como
apresentada em seguida:
Vazia, completamente sem linhas. O Cascade provoca que todas as linhas de tabelas
associadas a essa chave primria sejam deletadas, apagadas para evitar que existam no
banco de dados referncias s linhas inexistentes em uma tabela.
No somente o caso de deleo completa da tabela que preocupa, pois trabalhamos
com nossa tabela original de funcionrios:

134 Jose Alves 23/5/2002 M C5 D1

Se executarmos a mesma operao de deleo da linha relativa a Departamento de
Vendas (D5), essa tabela perder todas as linhas que estavam associadas pelo valor de chave
estrangeira ="D5", perdendo os dados de alguns funcionrios:
Funcionrio

134 Jose Alves 23/5/2002 M C5 D1
Importante: As chaves estrangeiras baseiam-se em valores (dados) e so puramente lgi-

cas, no existem apontadores fsicos.
Resumo de Restries de Integridade Relacional

Dada uma linha de uma tabela A:
Restrio de Incluso
se ocorre uma incluso da linha ,
se algum atributo da chave primria da linha for nulo,
ou existe outra linha na tabela A com o mesmo valor da chave primria da linha ,
ento impede-se a incluso de linha,
seno, realiza-se a incluso de linha.
Restrio de Deleo
se ocorre uma excluso da linha ,
se algum atributo de uma outra tabela faz referncia chave primria da linha
(existe uma chave estrangeira com o valor da chave primria de ),
ento impede-se a incluso de linha,
ou realiza-se a deleo em cascata das linhas da outra tabela que referenciam o
valor da chave primria de ,
ou modifica-se (altera-se) para nulo o valor da chave estrangeira da outra tabela.

Exerccios
1. Dadas as tabelas de um banco de dados e as operaes a serem realizadas, complete as
tabelas resultantes:
Tabela R Tabela S
A B C B C D
3 5 2 4 2 9
3 4 1 5 1 3
5 5 4 7 8 3
6 7 8
Tabela R{A,B,C)
Tabela S{B,C,D)
a. Incluso da linha {2,4,2} na tabela R.
Tabela R Tabela S
A B C B C D
b. Deleo da linha {4,2,9} da tabela S.
Tabela R Tabela S
A B C B C D

2. Dadas as tabelas de um banco de dados bancrio, defina as chaves candidatas, as
chaves primrias e as chaves estrangeiras existentes nas tabelas.
Cliente

3 Jose Alves Rua C Rio de Janeiro
4 Luis Paulo Souza Rua B Niteri
Conta-Corrente
CodAgencia NumConta CodCliente Saldo

1 256589 1 1200,00
3 328941 1 845,00
4 749621 3 512,00
2 856200 2 2650,00
3 454501 4 800,00
2 468952 3 6920,00
4 278156 1 10000,00
Agncia
CodAgencia NomAgencia CidadeAgencia

1 Rio Branco Rio de Janeiro
2 Icara Niteri
3 Leblon Rio de Janeiro
4 Ipanema Rio de Janeiro
5 Copacabana Rio de Janeiro
Emprstimo
CodAgencia CodCliente NumEmprest Valor

1 1 902230 500,00
3 1 902231 1500,00
4 2 902240 1200,00
2 3 902289 3000,00
3 1 902255 850,00
1 3 902299 700,00
4 3 902212 400,00

3. Responda s questes seguintes:
a. O que acontece se deletamos a linha...
3 1 902231 1500,00
... da tabela Emprstimo?

b. O que acontece se deletamos a linha...
... da tabela Agncia?

c. Como fica a tabela ContaCorrente se deletarmos a linha seguinte da tabela Cliente,
considerando a manuteno da integridade referencial?
4. Explique a diferena entre manter a integridade referencial por deleo em Cascata e

manter por chaves estrangeiras nulas.
5. Uma tabela B pode ter duas chaves estrangeiras para uma tabela A?
6. O que significa uma chave estrangeira com valor nulo?
7. Uma chave alternativa pode ter valores repetidos na mesma tabela?
8. Quais dos esquemas de BD apresentados em seguida esto errados?
a. Cliente{NOME, IDADE, SEXO, TELEFONE, TELEFONE, RUA}
b. Cliente{CODCLIENTE, NOME, IDADE, SEXO, TELEFONE, ENDERECO, CIDADE}
c. Cliente{CODCLIENTE, NOME, IDADE, SEXO, TELEFONE, ENDERECO, CIDADE, CODSEXO}
Sexo {NUMSEXO,NOMESEXO}
d. }Cliente{CODCLIENTE, NOME, IDADE, SEXO, TELEFONE, , ENDERECO, CIDADE, CODSEXO}
Sexo {CODSEXO,NOMESEXO}
e. Todos
f. Nenhum

4
MODELO ENTIDADE-RELACIONAMENTO
A utilizao da abordagem correta de uma metodologia orientada a banco de dados

envolve a estruturao nos trs nveis de viso de dados vistos anteriormente, ou seja, trs
etapas na execuo de um projeto de um banco de dados:
Um modelo conceitual;
Um modelo lgico;
Um modelo fsico.
Isola-se desta forma a realidade a ser retratada em dados de suas implicaes lgicas e
fsicas, determinando-se o momento para adequao do modelo a estes fatores.
evidente e bvio que a realidade dos negcios de uma empresa sempre diferente
da realidade de outra empresa, mesmo que falem de ambientes similares. Existem particulari-
dades que s dizem respeito ao funcionamento de um determinado ambiente.
Devido a essa no similaridade entre ambientes de mesma natureza, ser sempre
necessria a criao de um modelo especfico para cada nova realidade observada. Fica bem
clara, ento, a necessidade de termos um modelo que permita construir vrios outros modelos,
o qual chamado de metamodelo.
O metamodelo modelo a ser utilizado deve ter a caracterstica de poder modelar qualquer
realidade, uma forma de trabalho bastante simples e caractersticas grficas fceis de construir e
entender. O metamodelo que apresentamos neste livro o Entidade-Relacionamento (ER).
O modelo Entidade-Relacionamento (ER) foi definido por Peter Pin-Shan Chen, em
1976, e baseia-se na percepo do mundo real como constitudo por um conjunto de objetos
bsicos chamados entidades e relacionamentos e define uma tcnica de diagramao para
modelos de dados, o diagrama de entidades e relacionamentos.
A estrutura lgica global de um banco de dados pode ser expressa graficamente por
um diagrama de entidades (representadas por retngulos), por relacionamentos (represen-
tados por losangos) e pelos atributos de cada entidade ou relacionamento atravs de elipses
(notao Peter Chen).
Modelo Entidade-Relacionamento 65
Apesar de ser uma forma grfica de representar um banco de dados relacional, o
modelo ER possui um elevado grau de semntica, que o torna mais simples, alm de permitir
uma comunicao mais otimizada entre os usurios e os profissionais de informtica, desen-
volvedores de sistemas.
Dentro do que utilizamos como mtodo de desenvolvimento podemos tanto iniciar a

anlise por modelagem de eventos ou casos de uso quanto por modelagem de dados para
depois, com as entidades definidas, analisarmos os eventos que existem relativos a cada um
desses objetos.
A prpria UML prega a utilizao da criao dos diagramas de casos de uso como
primeira etapa de um processo metodolgico de desenvolvimento de aplicaes. Porm, um
cacoete derivado dos conceitos de anlise estruturada e anlise essencial, em que destaque e
importncia maior sempre foram dados aos processos e no aos dados.
Voltamos a lembrar que dados so sempre mais estveis que processos.
Observe que podemos mudar completamente um processo de faturamento, mas os
dados relativos ao faturamento continuaram estveis. Na pior das hipteses esses dados
seriam reduzidos, mas no haveria uma mudana completa dos dados utilizados para esse
processo.
Os diagramas de caso de uso fornecem um modo de descrever a viso externa do
sistema e suas interaes com o mundo exterior, representando uma viso de alto nvel de
funcionalidade intencional mediante o recebimento de um tipo de requisio de usurio.
Entretanto, no caso de iniciarmos um desenvolvimento pela especificao de casos de uso,
podem conduzir-nos criao de classes de dados redundantes ou no aderentes ao mundo
real, o que obtemos sempre quando trabalhamos com modelagem de dados pura.
J a modelagem de dados pode permitir a criao mais concisa de modelo de classes,
j que um modelo de dados retrata com maior fidelidade uma realidade, ou seja, o mundo real.
A estabilidade do modelo de dados obtida quando se investe quantidade de tempo
nos aspectos conceituais de modelagem de dados, revertendo esse tempo em benefcios
considerveis durante a implementao da base de dados.
A tcnica de modelagem Entidade-Relacionamento proposta por Peter Chen est
definida como uma notao orientada para o desenho de um modelo conceitual, pois permite a
descrio desse esquema conceitual sem preocupao com problemas de implementao
fsica ou de performance do banco de dados.

O diagrama Entidade-Relacionamento descreve a estrutura conceitual e lgica geral de
um banco de dados.
Observa-se ento que o objetivo da modelagem de dados definir o contexto dos
dados em que os sistemas funcionam. Por isso, o produto da modelagem de dados deve ser o
mais fiel possvel ao mundo real e, alm disso, possuir uma caracterstica adicional muito
importante: as suas especificaes no devem implicar e tampouco estarem limitadas a
nenhuma implementao fsica em particular. Tudo aquilo que for proposto pela modelagem de
dados deve ocorrer num nvel conceitual e lgico, de maneira a no viciar a anlise pela
restrio de pontos de vista tcnicos da equipe de participantes do processo de anlise. Os
detalhes fsicos vm depois.
A abordagem de sistemas para bancos de dados relacionais tem como principal
caracterstica o alto nvel em que ocorrem as definies necessrias implantao de uma
base de dados.
Assim, a qualidade de um projeto como um todo muito dependente da qualidade da
modelagem de dados que o antecede.
muito importante ento que exista uma metodologia simples, precisa e eficiente para
a representao dos objetos modelados pelo analista e que tambm seja de fcil transposio
para os diversos SGBD disponveis.
isso que se obtm com a utilizao do modelo ER proposto por Peter Chen.
Elementos de um Modelo ER
Um modelo de dados ER composto de trs classes de objetos: entidades, relacio-
namentos e atributos.
As literaturas existentes nunca deixam claro como podemos entender entidades e
relacionamentos. Uma vez que a maioria dos profissionais de anlise de sistemas tem sua
cultura baseada em sistemas procedurais, em que os dados so o resultado e no o meio,
existe a necessidade de que se coloque mais enfoque didtico no detalhamento da definio
de entidades e relacionamentos.
As tcnicas orientadas a objetos, hoje utilizadas no Pas e que alcanaram divulgao
profissional prtica, baseiam-se na anlise dos procedimentos, e com enfoque principalmente
direcionado aos casos de uso (use case) e em diagramas de classes excessivamente
preocupados em retratar no s dados e sim processo em conjunto, ou nos casos de anlise
essencial em diagramas de fluxo de dados, o que provoca uma derivao de foco e possibilita
uma larga margem de erro de conceituao do mundo real.
Essas tcnicas estruturadas colocam as informaes derivadas dos procedimentos em
classes de dados (OO) ou depsitos de dados (A Essenc.) as quais sintetizando-se finalmente
acabam sendo convertidas em tabelas de um sistema, pura e simplesmente.
Para que se efetue ento a migrao dessa base cultural, necessrio que a regra b-
sica - procedimentos no nos interessam - seja atendida nesta abordagem de levantamento.
Vamos estabelecer como preocupao somente a necessidade de retratarmos as
informaes existentes no negcio. Nosso objetivo primordial entendermos o negcio, para o
qual projetaremos um sistema, atravs de seus dados.
Quando escrevemos objetos conceituais, no pretendemos inserir na orientao a

objetos. Apesar de a modelagem conceitual de dados ser a base para o entendimento dessa
nova abordagem tecnolgica, o objetivo na realidade ir at as razes da conceituao de
modelo Entidade-Relacionamento.
Quando Peter Chen formulou a proposta do modelo Entidade-Relacionamento, ele se
baseou no na viso de um sistema de aplicao como princpio e sim na compreenso da
realidade em que se situava o problema. Como vamos projetar um sistema se no entendemos
o negcio para o qual ser realizado?
Chen dedicou-se a destacar a importncia de reconhecer os objetos que compem
esse negcio, independentemente de preocupar-se com formas de tratamento das infor-
maes, procedimentos, programas etc.
Entidades
Correspondem a quaisquer coisas do mundo real sobre as quais se deseja armazenar
informaes.
So exemplos tpicos de entidades: pessoas (fsicas ou jurdicas, tais como funcionrio,
empresa, fornecedor e cliente); objetos materiais ou abstratos, como produto, veculo, disci-
plina e projeto e eventos ou fatos como pedido, viagem, emprstimo e venda principalmente.
No modelo ER so representados por meio de um retngulo com o nome representativo
da entidade (um substantivo no singular) ao centro.
Uma entidade normalmente tem vrias manifestaes dela mesma. Por exemplo, a enti-
dade funcionrio representa todos os funcionrios da empresa, e no apenas um deles; a
entidade produto representa todos os produtos com os quais a empresa trabalha etc.
Se fizermos uma comparao com a UML, funcionrio o um objeto, o conjunto dos
objetos funcionrios forma a classe de objetos funcionrio, que a nossa entidade. Ento uma
entidade corresponde a uma classe de objetos e as ocorrncias desta entidade so os objetos
funcionrios.

Dizemos ento que uma entidade possui ocorrncias ou instncias, e cada um dos
funcionrios descritos pela entidade funcionrio uma de suas ocorrncias, ou instncias.
Entidade a principal classe de objetos sobre a qual so coletadas informaes. Ela
normalmente denota pessoa, lugar, coisa ou fato de interesse de informaes.
todo objeto concreto ou abstrato que tem existncia prpria, quando considerado o
mbito de um negcio. So coisas sobre as quais desejamos arquivar informaes.
Define-se entidade como aquele objeto que existe no mundo real com uma identificao
distinta e com um significado prprio.
So as coisas que existem no negcio, ou ainda, descrevem o negcio em si.
A figura seguinte apresenta o ambiente de uma clnica mdica correspondente
descrio de um minimundo.
Uma clnica mdica necessita controlar as consultas mdicas realizadas e marcadas
pelos mdicos a ela vinculados, acompanhar os pacientes atendidos e manter o seu
acompanhamento clnico. Para cada mdico a clnica mantm uma ficha com o nmero de
CRM, seu nome, endereo, especialidade etc. Os pacientes tm cadastro com dados pessoais,
tais como nome, endereo, data de nascimento, sexo etc. Toda consulta registrada em
fichrio prprio com as informaes sobre mdico e paciente, diagnstico etc.
Quais so os objetos candidatos a entidades

nesse ambiente em observao?
Observe com a sua capacidade de abstra-
o as coisas que existem no ambiente: mdicos,
pacientes, exames, consulta.
Essas coisas que fazem parte do ambiente
so entidades, pois podemos manter informaes
sobre elas, e so participativas na existncia do
ambiente. Cada uma delas tem significado prprio.
Se alguma coisa existente no ambiente negcio nos proporciona algum interesse em

mantermos dados sobre essa coisa (informaes armazenadas sobre ele), isso a caracteriza
como uma entidade do negcio.
Cada entidade ser ento um elemento em nosso modelo conceitual de dados.
Uma entidade a representao de uma classe de dados de um ambiente especfico,
um conjunto de informaes de mesmas caractersticas. Cada ocorrncia da coisa que
representamos como uma entidade chamada de instncia (ocorrncia) e representa um
conjunto particular desses dados.
Quando representamos classe de dados, atuamos em um nvel de abstrao de dados
interpretado de acordo com o entendimento do meio, do ambiente em que nos localizamos e
seus interesses e objetivos.
Uma instncia de uma entidade no tem representao no diagrama ER, porm

devemos sempre visualizar em uma entidade a ocorrncia de linhas de uma tabela relacional,
uma vez que estamos realizando anlise para o contexto lgico de banco de dados relacional.
Data_da_Consulta CRM_do_Medico Identificacao_Paciente

22/04/92 21113 Joo Pedro Lima
22/04/92 21113 Clara Mathias
21/03/91 14442 Lus Alberto Conde
31/03/92 55555 Maria Luiza Andrade
Endereco Sexo Idade

R. Silva S, 23/11 Masc 33
R. Dias Melhores 334/122 Fem 18
Av. Arapans 4487/1915 Fem 44
R. Botica do Ouvidor 44/fundos Masc 29
Trav. das Camlias 661 Masc 38
Quando analisamos um ambiente, tiramos uma fotografia dele que nos apresenta as
entidades que participam, ou esto naquele ambiente.
A representao grfica de uma entidade em um diagrama ER realizada por meio de
um retngulo com o nome da classe de dados inserido em seu interior conforme apresentamos
na fotografia da pgina anterior.
Numa viso simplista, entidade similar a um arquivo de um sistema convencional, e
natural fazer esta correspondncia: um conjunto de ocorrncias de uma entidade corresponde
a um arquivo, e uma nica ocorrncia, que podemos denominar de linha, corresponde a um
registro.
Relacionamentos
Relacionamento a representao das associaes existentes entre entidades no
mundo real. Muitos relacionamentos no tm existncia fsica ou conceitual, outros dependem
da associao de outras entidades.

No mundo real uma entidade muito raramente se apresenta
isolada, tendo existncia completamente independente de quaisquer
outras.
Normalmente ocorre o contrrio: detectada a existncia de
uma associao entre as ocorrncias de duas entidades distintas.
Essa conexo lgica entre duas ou mais entidades definimos como relacionamento, que
representado em um diagrama Entidade/Relacionamento por meio de uma linha unindo as
entidades associadas, contendo ainda um losango com o nome do relacionamento (um verbo
flexionado) ao centro.
Uma ocorrncia em particular de um relacionamento chamada de instncia de relacio-

namento, ou ocorrncia. Um relacionamento descrito em termos de grau, cardinalidade e
existncia.
O mais comum dos termos associados a um relacionamento a indicao da
cardinalidade entre as ocorrncias das entidades relacionadas: um-para-um, um-para-muitos e
muitos-para-muitos.
Como cardinalidade um termo que no explicita muita coisa, vamos utilizar a palavra
conectividade porque acreditamos que entender o conceito de conexo mais simples.
Alguma coisa se conecta a outra.
O nome do relacionamento normalmente um verbo, pois resultante de um fato que
associa as entidades. Podemos dar dois nomes, digamos assim, a um relacionamento.
Um verbo para explicar o fato no sentido da entidade A para a entidade B, e outro verbo
no sentido da entidade B para a entidade A, uma vez que a leitura de um relacionamento no
possui um lado especfico do modelo para ser realizada.
Entender relacionamentos e a capacidade de enxergar esses objetos, assim como a

sua participao no mundo real, fator primordial para o resultado de uma modelagem de
dados com entendimento e retrato fiel do ambiente em anlise.
No devemos ter antecipadamente medo da provvel complexidade de uma tcnica, e
sim lembrarmo-nos de que nada mais do que uma forma estruturada de representar as
coisas que existem e ocorrem no mundo real, como sempre fizemos com papel e lpis desde a
infncia.
Dentro deste enfoque relacionamento um fato, acontecimento que liga dois objetos,
duas "coisas" existentes no mundo real.
Considerando que estamos nos orientando para aplicaes que sero desenvolvidas e
administradas por um Sistema Gerenciador de Banco de Dados, poderamos estender o
conceito, principalmente para ambientes relacionais, como sendo relacionamento o fato que
efetua a juno de duas ou mais tabelas de dados.
Vamos continuar a conceituao dos elementos de um modelo de dados ER, e depois
voltamos ao entendimento e identificao mais clara de relacionamento no mundo relacional.
Atributos
So as caractersticas de uma entidade que a descrevem detalhadamente.
Uma ocorrncia especfica de um atributo em uma entidade ou relacionamento deno-
mina-se valor do atributo.
Os atributos representam propriedades elementares de uma entidade ou relacionamento.

Cada atributo est associado a um domnio particular, que um conjunto de valores vlidos
para o atributo.
Os atributos da entidade empregado, por exemplo,

so normalmente a identificao do empregado, o nome,
endereo, sexo, telefone, cargo, salrio.
A notao de Peter Chen original apresenta o
atributo como uma elipse com o nome do atributo em seu
interior e conectada entidade a que pertence.
A simbologia utilizada por Rumbaugh em seu livro coloca uma lista de atributos dentro
do retngulo da entidade, deixando sobre ele o nome da entidade. Esta uma notao grfica
tambm interessante, entretanto os produtos de software para modelagem de dados utilizam
mais a notao IDEF1X e a notao da engenharia de informao que veremos tambm neste
livro.

Existem dois tipos de atributo: identificadores e descritores.
Um identificador (ou chave) usado unicamente para determinar a identificao de uma
ocorrncia de uma entidade. Em nosso ambiente relacional equivale chave primria. Observe
que quando estamos executando o processo de abstrao para identificar as entidades, no
existem chaves primrias do tipo cdigo.
Os atributos descritores (no chaves) so utilizados para descrever caractersticas no
nicas de uma ocorrncia particular da entidade.
Por exemplo, no diagrama da entidade funcionrio, o atributo chave, identificador de
uma ocorrncia de funcionrio matrcula; endereo e nome so seus descritores.
Todo objeto para ser uma entidade tem propriedades que so descritas por atributos e
valores. Esses atributos e seus valores, juntos, descrevem as instncias de uma entidade.
Entidade: Funcionrio
Matricula NomeFunc DtAdmissao Sexo

104 Carlos Pereira 2/3/2004 M
134 Jose Alves 23/5/2002 M
123 Pedro Sergio Doto 29/6/2003 M
22 Sergio Nogueira 10/2/2000 M
Vamos considerar que em uma empresa temos uma entidade, um objeto sobre o qual
desejamos manter informaes armazenadas, chamado funcionrio.
O que descreve funcionrio?
Funcionrio descrito por um nmero de matrcula, um nome desse funcionrio, sua
data de admisso e sexo, como representado na tabela anterior. Poderamos ainda
descrev-lo com mais dados, tais como data de nascimento, valor de seu salrio etc. Esses
dados que caracterizam o objeto funcionrio so os atributos inerentes entidade funcionrio.
Cada instncia de funcionrio, cada existncia de um objeto da classe funcionrio ser
formada por valores nesses atributos. o conjunto desses valores representados que
devemos visualizar como uma linha de uma tabela de dados da entidade.
Os valores de determinados atributos ou de um determinado atributo, nas ocorrncias
dessa entidade, so sempre diferentes para cada instncia, caracterizando que no existem
objetos repetidos dentro de uma classe de objetos, isto , dentro de uma entidade.
Esse(s) atributo(s) cujos valores nunca se repetem, sempre tem (tm) a funo de atuar
como identificador(es) nico(s) das instncias da entidade. Dentro da abordagem relacional de
banco de dados, denomina-se essa propriedade como chave primria de uma tabela, conceito
que vamos utilizar dentro de nosso contexto, quando realizarmos o modelo lgico de dados.
Este conceito no foge de forma nenhuma do que acontece no mundo real, j que um
objeto sempre possui uma forma de identificao unvoca.
Quando modelamos, independentemente de
estarmos pensando em ambiente de banco de dados
relacional, encontramos alguns atributos que so
multivalorados, ou seja, acontecem mais de uma vez
para cada ocorrncia da entidade. Por exemplo, no
caso de funcionrio, poderamos ter um atributo
especialidades, ou habilidades, que seria mais de um
para cada existncia de funcionrio.
Em um primeiro momento vamos representar
esses atributos em destaque com uma conexo de
linha dupla com a entidade.
Apesar de afirmarmos a existncia de atributos identificadores e descritivos, encontra-
mos entidades que so derivadas de outras, tendo parte de seus atributos identificadores igual
de outra entidade.

Estas entidades tm existncia dependente, ou seja, somente existem se existir a
entidade da qual possuem parte dos atributos identificadores. Exemplos claros deste caso so
as entidades histricas em um negcio.
No caso da entidade funcionrio seria a existncia de uma entidade histria dos cargos
ocupados por cada ocorrncia de funcionrio. Mas observe que isso uma derivao, pois
inicialmente esses cargos ocupados poderiam ser entendidos como um atributo multivalorado
da entidade funcionrio.
O objetivo apresentar as formas de representao de um modelo ER. Representao
que exemplifica entidades, relacionamentos e atributos.
Grau de Relacionamento
O grau de um relacionamento o nmero de entidades que participam dele.
Existem trs tipos bsicos de grau de relacionamento: binrio, ternrio e e-nrio que referem
a existncia de duas, trs ou mais entidades envolvidas no fato que o relacionamento
representa.
Um relacionamento binrio acontece entre duas entidades que o fato mais comum de
acontecer no mundo real.
Podemos ter tambm um relacionamento binrio recursivo construdo por meio de
conexes com a mesma entidade, acontecendo como se fossem duas coisas diferentes se
relacionando na abstrao, duas ocorrncias da entidade se relacionando, se associando.
De um relacionamento ternrio participam trs entidades no mesmo fato. Um relacio-
namento e-nrio aquele do qual participam mltiplas entidades.
Esta teoria existe nos trabalhos de Peter Chen, porm quando elevamos o nvel de
abstrao, podemos observar que esse tipo de relacionamento no ocorre no mundo real. O
que vamos estudar a existncia de relacionamentos dependentes de um relacionamento
binrio.
impossvel para o ser humano verbalizar um evento, um fato, um acontecimento de
forma ternria. O que sempre interpretamos em uma realidade um acontecimento como
consequncia de outro. Logo, no recomendamos nem vamos estudar relacionamentos
ternrios e mltiplos detalhadamente e sim com poucas apresentaes, pois podemos
perfeitamente explic-los e utiliz-los por meio da teoria dos relacionamentos dependentes
(agregaes), como veremos mais adiante.
Relacionamento Binrio
Relacionamento Ternrio Relacionamento E-nrio
Uma entidade pode estar envolvida em indeterminado nmero de relacionamentos,

assim como podemos ter mais de um relacionamento entre duas entidades, se efetivamente as
duas participam de fatos ou acontecimentos distintos, ou essas associaes representam
formas diferentes de associao entre as suas ocorrncias.
Conectividade de um Relacionamento
A conectividade, como gostamos de denominar, descreve as restries no mapeamento
das associaes existentes entre as ocorrncias de entidades em um relacionamento.
Os valores de conectividade esto sempre entre um ou muitos em um dos lados do
relacionamento, da mesma forma que vimos no captulo 2 sobre abstrao em modelagem de
dados.
A ocorrncia de uma entidade se associa, conecta a uma ocorrncia de outra entidade,
ou a muitas ocorrncias dessa outra entidade.

CRM
Nome Mdico Especialidade Nome Paciente Endereo Paciente Sexo
Mdico
21113 Luis Paulo Carvalho Pediatria Jlio Adamastor R. Silva S, 23/11 Masc
21113 Pedro Estevo Ginecologista Carmem Milhor R. Dias Melhores 334/122 Fem
51024 Mauricio Abreu Neurologia Sandra Chu Li Av. Arapans 4487/1915 Fem
76004 Simone Almeira Cardiologia lvaro Medeiros S R. Botica do Ouvidor 44/fundos Masc
Paulo Alengui Trav. das Camlias 661 Masc
Observe que no necessrio que todas as ocorrncias de uma entidade estejam

associadas, conectadas a alguma ocorrncia da outra entidade. Podem existir ocorrncias em
uma entidade que no possuem nenhum relacionamento com ocorrncias da outra entidade.
Um relacionamento possui sempre esta caracterstica bsica chamada de conectividade
ou cardinalidade.
A conectividade de um relacionamento consiste na especificao do sentido da associa-
o entre as entidades envolvidas.
Por exemplo, lendo o relacionamento no sentido de funcionrio para departamento, um

funcionrio pertence sempre a no mnimo um e no mximo um departamento, ou seja,
obrigatrio que exista, para uma ocorrncia especfica da entidade funcionrio, to somente
uma ocorrncia da entidade departamento associada.
Por outro lado, no sentido de departamento para funcionrio, para um determinado
departamento possvel que existam vrios funcionrios relacionados: mais de uma ocorrncia
da entidade funcionrio refere-se mesma ocorrncia da entidade departamento. Dizemos
neste caso que a cardinalidade do relacionamento "Pertence" de 1:N ("um-para-ene" ou
"um-para-muitos"). Este o grau de conectividade ou cardinalidade de um relacionamento.
Vejamos ento as conectividades existentes em um modelo de dados.
Conectividade Um-para-Um
Quando entre duas entidades temos um relacionamento em que cada ocorrncia da
entidade A se associa ou relaciona com uma e somente uma ocorrncia da entidade B e cada
ocorrncia da entidade B se relaciona com uma e somente uma ocorrncia da entidade A,
ento temos um relacionamento com conectividade um-para-um (1:1).
A representao no diagrama realizada pela insero do nmero 1 de cada lado do
relacionamento, e deve ser lido da seguinte forma:
Um departamento gerenciado por um e somente um funcionrio.
Um funcionrio gerencia um e somente um departamento.
Observe que colocamos dois verbos para explicar este relacionamento, permitindo a
leitura nos dois sentidos.
Vamos buscar outro exemplo de conectividade de um-para-um.
Um computador possui um e somente um teclado conectado a ele.
Um teclado est ligado a um e somente um computador.
No mundo real e principalmente no ambiente de negcios de uma empresa, que nor-

malmente onde modelamos, so muito raros os casos de relacionamento de conectividade
um-para-um, porm a Lei de Murphy sempre aparece.
Conectividade Um-para-Muitos
a conectividade mais comum no mundo real e no mundo dos negcios e a mais
utilizada na soluo de modelo de dados.
Ela acontece quando uma ocorrncia da entidade A se associa ou conecta a mais de
uma ocorrncia da entidade B, visto que a ocorrncia da entidade B est conectada a uma e
somente uma ocorrncia da entidade A.
Vejamos ento alguns exemplos:
Um pedido de venda de um cliente tem vrios produtos.

A anlise e a interpretao de um relacionamento de um-para-muitos devem ser muito
cuidadosas, pois comum observarmos analistas interpretarem como um-para-muitos relacio-
namentos que em verdade so de muitos-para-muitos.
Observe a figura seguinte que apresenta dois domnios relativos a duas entidades.
Vamos considerar que temos uma entidade
prateleira em nosso escritrio. Os nossos produtos
so guardados nessas prateleiras.
Cada prateleira pode ter vrios produtos, e
como somos organizados, um produto sempre est
somente em uma prateleira.
Sempre temos uma leitura em dois sentidos
para validar que esse relacionamento seja efetiva-
mente de um-para-muitos.
Cada ocorrncia da entidade prateleira pode estar conectada a muitas ocorrncias da
entidade produto. Entretanto, cada ocorrncia da entidade produto somente est conectada a
uma e somente uma ocorrncia da entidade prateleira.
Vamos analisar agora os relacionamentos que so de conectividade muitos-para-muitos
utilizando a mesma situao, porm considerando que somos muito desorganizados e colo-
camos um produto em mais de uma prateleira.
Conectividade Muitos-para-Muitos
Agora nos dois sentidos de leitura encontra-
mos a conectividade de um-para-muitos. Uma pra-
teleira possui muitos produtos e um produto pode
estar em muitas prateleiras.
Quando encontramos nos dois sentidos de
leitura a conectividade de um-para-muitos, temos
ento o que se denomina de conectividade muitos-
-para-muitos.
Um relacionamento com essa conectividade
normalmente um fato, acontecimento de negcios
no mundo real.
Vejamos mais alguns exemplos. Essa conectividade muito comum em negcios. Uma
nota fiscal tem muitos produtos, e um produto pode estar em muitas notas fiscais. Este um
fato corriqueiro em qualquer empresa.
Neste caso podemos afirmar que um relacionamento muito-para-muitos, pois
antecipadamente realizamos a leitura nos dois sentidos, e encontramos nos dois a mesma
conectividade de um-para-muitos.
Vamos abstrair e procurar no ambiente domstico um relacionamento muitos-para-muitos.

Como somos fanticos por corridas de Frmula 1, vamos analisar esta situao.
O campeonato de Frmula 1 tem muitas corridas
durante o ano que assistimos confortavelmente instalados
em frente ao nosso televisor. As equipes que disputam o
campeonato possuem muitos carros, pilotos e mecnicos e
esses carros e pilotos participam normalmente de todas as
provas do campeonato.
Que modelo de dados podemos obter deste fato?
Tambm neste caso nos dois sentidos de leitura confirmamos a existncia deste tipo de
conectividade:
Cada carro de Frmula 1 participa de muitos Grandes Prmios.
De um Grande Prmio participam muitos carros de Frmula 1.
Nos dois sentidos obtivemos uma conectividade de um-para-muitos, que caracteriza um

relacionamento ser de conectividade muitos-para-muitos.
Atributos em um Relacionamento
Como estamos atuando no nvel conceitual, temos a obrigao de observar que neste
tipo de relacionamento de muitos-para-muitos normalmente ocorre a presena de atributos.
No caso das corridas de Frmula 1, temos um atributo que a posio de chegada de
um carro, o tempo que levou para completar a prova, quantas voltas realizou (pode ser que
tenha abandonado), s para ilustrar alguns atributos.
Por que estes atributos so do relacionamento?

Analisando, entendemos que o relacionamento representa o fato de um carro participar
de um Grande Prmio. No so informaes somente do GP nem tampouco somente de um
carro. So referentes participao do carro em um GP, logo so dados do relacionamento.
Atributos so normalmente assinalados em relacionamentos muitos-para-muitos. Nunca

assinalamos atributos em relacionamentos um-para-um e em relacionamentos um-para-muitos
porque no sentido de leitura de um relacionamento deste tipo sempre temos um lado que tem
somente um elemento relacionado, e seria ambguo colocarmos o atributo no relacionamento
em vez de colocarmos na entidade. Por exemplo, no relacionamento entre funcionrios e
departamentos:
Poderamos dizer que o atributo data de incio de atividades pertence ao relacio-

namento, pois o funcionrio comeou a trabalhar em um departamento em uma determinada
data. Como ele somente trabalha em um departamento e cada ocorrncia de funcionrio
possui a sua data de incio em um departamento, essa data um atributo de funcionrio.
Se essa data se referisse data de incio de atividades do departamento, ela seria refe-
rente a uma ocorrncia de departamento, desta forma tambm no seria do relacionamento.
Sempre que temos relacionamentos de um-para-um ou um-para-muitos, os atributos

que possam existir decorrentes do fato so elementos de descrio de uma das duas
entidades.
Opcionalidade de Relacionamento
Analisando o modelo funcionrio e departamento, vamos verificar a validade de
algumas afirmativas:
Todo funcionrio trabalha em um departamento?
Todo departamento tem funcionrios?
Das duas afirmativas podemos dizer que nem todo departamento necessita ter
funcionrios, logo o relacionamento de departamento no sentido de leitura para funcionrio
opcional. Isso quer dizer que podemos ter uma ocorrncia de departamentos sem funcionrios,
ou seja, ainda no foram alocados funcionrios para eles.
Como representar essa opcionalidade?
Esta situao quer nos dizer que a conectividade mnima igual a 0 (zero).
Um pequeno crculo no lado que existe a opcionalidade faz esta representao.
Em um departamento trabalha nenhum, ou muitos funcionrios.

Um funcionrio trabalha em no mnimo 1 (um) departamento.
Condicionalidade de um Relacionamento
Um relacionamento pode ser condicional ou ter restries, ou seja, podemos ter um
modelo em que uma entidade se relacione com outras duas, porm com cada uma exclusiva-
mente. Vejamos uma situao para exemplificar.
A entidade A se relaciona com a entidade B ou com a entidade C.

Isso quer dizer que cada ocorrncia da entidade A pode se relacionar com uma
ocorrncia da entidade B ou ento com uma ocorrncia da entidade C, sendo esse
relacionamento mutuamente exclusivo, isto , no possvel existir um relacionamento com as
duas ocorrncias das entidades B e C.

O desenho torto somente para ilustrar, pois certamente podemos realizar um design
melhor esteticamente.
Uma tarefa "indica" um projeto interno, seno ela " para" um projeto externo.
Relacionamento mutuamente exclusivo.
Quando estudarmos os conceitos de generalizao e especializao de entidades,

vamos entender melhor quando acontecem esses casos.
Relacionamentos Reflexivos
So os relacionamentos que acontecem entre as ocorrncias de uma mesma entidade.
Normalmente esses relacionamentos representam algum sentido de hierarquia.
Por exemplo, a entidade funcionrios representa todos os funcionrios de uma empre-
sa. Alguns desses funcionrios gerenciam outros funcionrios. Este um autorrelacionamento,
pois ocorre dentro da mesma entidade.
Observe a representao.
Os relacionamentos reflexivos podem ter qualquer uma das trs possibilidades de

conectividade, um-para-um, um-para-muitos e muitos-para-muitos.
Quando utilizamos estruturas que representam algum tipo de composio de algo, a
conectividade muitos-para-muitos.
Um computador, por exemplo, entregue como composto por quatro produtos: monitor,
CPU, teclado e mouse.
Vamos supor que temos uma entidade
produto e nas suas ocorrncias temos todos
os produtos de nossa empresa, inclusive os
que so compostos por outros produtos.
Como representar essa composio?
Por meio de um relacionamento refle-
xivo de muitos-para-muitos.
O relacionamento em si tem os atributos que identificam qual o produto composto e

qual o produto que est participando de uma composio, assim como a quantidade com que
ele participa.
So ocorrncias distintas na mesma entidade.
A pergunta que voc deve fazer se todos os componentes de um produto composto
esto em uma ocorrncia do relacionamento. A resposta no.
Cada componente forma uma ocorrncia do relacionamento, logo se um produto
formado por dez outros produtos, existiro dez ocorrncias no relacionamento indicando cada
uma dessas ocorrncias do produto composto e um dos componentes.
Peter Chen especifica a existncia de um papel para cada elemento de entidade,

participante de um relacionamento, mas no autorrelacionamento ou relacionamento reflexivo
que isso se torna mais evidente e necessrio.
Usualmente esses papis so denominados ALIAS.
Cdigo Cdigo Cdigo Quantidade

Descrio
Produto Composto Componente Componente
3758 Parafuso 5532 3758 10
8596 Rosca 5532 4512 22
4512 Arruela 5532 8596 14
5532 Bloco 7626 3758 65
7626 Carburador 7626 4512 70

Para obter uma viso dos dados do relacionamento, vamos apresent-lo no formato
tabela.
Isso denota que o relacionamento reflexivo de conectividade muitos-para-muitos implica
em uma estrutura de dados para ele, ou seja, ele possui dados da mesma forma que uma
entidade.
Na estrutura de atributos do relacionamento existem dois papis, o papel de produto
composto e o papel de produto componente.
Resoluo de Relacionamentos Muitos-para-Muitos

A interpretao de um relacionamento muitos-para-muitos pode variar na anlise do
minimundo que estamos modelando. Entretanto, podemos conciliar esses casos por meio
do que denominamos resolver o relacionamento muitos-para-muitos.
Todo relacionamento muitos-para-muitos pode ser entendido como uma entidade. Essas
entidades denominam-se associativas, pois elas representam um fato, um relacionamento
muitos-para-muitos.
Considerando os modelos vistos at o momento, as alternativas so as seguintes:

Neste caso de autorrelacionamento, ou relacionamento reflexivo de muitos-para-muitos
que apresentamos, a incluso da entidade composio tem o mesmo efeito de representati-
vidade que o relacionamento reflexivo.
Observe a leitura do modelo:

Um produto (componente) participa de 'n' ocorrncias de composio.
Cada ocorrncia de composio participa de um produto (componente).
Cada produto (composto) est em 'n' ocorrncias de composio.
Cada ocorrncia de composio tem um produto (composto).
No caso de relacionamentos reflexivos como este, so substitudos por dois relaciona-
mentos um-para-muitos.
Observe a tabela da entidade associativa, idntica ao relacionamento para um melhor
entendimento.
Cdigo Cdigo Quantidade
Composto Componente Componente
5532 3758 10
5532 4512 22
5532 8596 14
7626 3758 65
7626 4512 70
O produto 5532 (composto) EST na entidade associativa mais de uma vez, logo
ele est relacionado "N" vezes com a entidade composio.
Cada ocorrncia de composio TEM somente UM produto composto.
Cdigo Cdigo Quantidade

Composto Componente Componente
5532 3758 10
5532 4512 22
5532 8596 14
7626 3758 65
7626 4512 70
O produto 3758, como destacamos, aparece mais de uma vez na entidade compo-
sio, logo UM produto participa de "N" composio.
Cada ocorrncia da entidade composio tem UM produto (componente).
Peter Chen usa um formato de diagramao para representar os papis que deixam um
pouco mais clara essa definio do modelo.
Vamos ver agora o caso do exemplo que apresentamos de nota fiscal e produtos.

Poderia ser resolvido tambm como:
Procure agora visualizar como so os dados da entidade produtos da nota fiscal.
Nota Fiscal Produto Quantidade

2585999 Mouse 2
2585999 Teclado 5
2586000 Tela para Monitor 10
2586001 CD-RW 20
2586001 Mouse 5
Toda ocorrncia de produtos da nota fiscal tem um produto.

Todo produto pode estar em mais de um produto da nota fiscal.
Uma nota fiscal pode estar em mais de um produto da nota fiscal.
Toda ocorrncia de produtos da nota fiscal tem uma nota fiscal.
Vamos agora exercitar um pouco a descoberta de entidades e relacionamentos, assim
como descobrir os atributos das entidades e relacionamentos.
Para este exerccio vamos utilizar um minimundo, cuja descrio apresentamos em
seguida:
Existem empresas identificadas univocamente pelo respectivo nmero de contribuinte
(nmero do CNPJ). Adicionalmente, so caracterizadas por um nome e um segmento de
negcio.
Cada empresa tem uma sede e zero, uma ou mais filiais. Tanto a sede como as filiais
tm um endereo e um s nmero de telefone cada uma. Os empregados das empresas so
identificados univocamente por uma matrcula de empregado. So ainda caracterizados pelo
respectivo nome, endereo e data de nascimento. Cada empregado trabalha apenas num local
(sede ou filial); no seu local de trabalho, existe um nmero de telefone direto.
Bem, vamos observar o que candidato ou quais so as entidades existentes neste
contexto.
Seguindo um critrio de que substantivos indicam entidades, temos neste caso:
Empresa
Filial
Nmero de contribuinte
Nmero de telefone
Endereo
Empregados
Matrcula de empregado
Local de trabalho
Nesta lista temos dois substantivos compostos que indicam atributos de alguma
entidade e no propriamente entidades, pois no tm existncia prpria: nmero de telefone e
matrcula de empregado.
Analisando mais, podemos concluir que endereo uma propriedade de algo, tambm
no tem existncia prpria, logo deve ser atributo de alguma entidade e no uma entidade.
Local de trabalho tambm composto e claramente caracteriza-se como uma propriedade de
uma entidade e uma entidade em si.
Logo existem ento trs entidades neste contexto:
Vamos analisar os atributos de cada uma dessas entidades que podemos entender do
minimundo.

Aps termos obtido e identificado as entidades que compem o contexto do aplicativo
que estamos projetando, a prxima etapa consiste na definio dos relacionamentos que
existem entre as entidades e que interessam aos propsitos. No momento em que obtivermos
o domnio dos relacionamentos e entidades, poderemos traar um primeiro diagrama ER que
servir de base para as etapas seguintes.
Uma vez que temos as entidades definidas para o caso, vamos analisar os verbos que
existem no minimundo e quais fatos descritos podem caracterizar a existncia de relaciona-
mentos no modelo de dados.
"Cada empresa possui uma sede e zero, uma ou mais filiais."
Aqui temos claramente a viso de que existe um relacionamento entre empresa e filial,
e ainda est indicada a conectividade (cardinalidade) desse relacionamento e sua opcionalidade.
O diagrama agora j apresenta estas duas entidades com o seu relacionamento.

Seguindo, devemos analisar com quem a entidade Empregado se relaciona, porm um
detalhe at o momento chama a ateno:
Empresa e filial tm os mesmos atributos.
No so uma nica entidade? Ser filial ou sede no ser um atributo, uma propriedade
dessa entidade?
Vejamos se esta soluo no plausvel:

Quando a empresa for sede, o atributo sede ou filial indicar um valor 'sede'.
Quando for uma filial, o valor do atributo ser 'filial'.
Desta forma conseguimos simplificar um pouco o nosso modelo, porm como devemos
saber quem filial de quem, vamos colocar um relacionamento reflexivo no modelo.
Voltando ao raciocnio de continuidade, qual o relacionamento entre empregado e a

entidade empresa?
"Cada empregado trabalha apenas num local (sede ou filial); no seu local de trabalho
tem um nmero de telefone direto."
Logo temos um relacionamento.
Resolvendo, temos:

Porm, ainda falta alguma coisa para que este modelo fique correto:
"........no seu local de trabalho tem um nmero de telefone direto."
Este atributo de o empregado ter um telefone em seu local de trabalho no est visvel
no modelo at o momento, pois no o telefone da empresa. Logo:
Vamos agora apresentar o modelo completo segundo a notao de Peter Chen.
Ao analisarmos o contexto, devemos ter em mente uma forma de pensar ER.

Logo, algo que no requeira pelo menos dois atributos para descrev-lo provavelmente
no caracterizar uma entidade e sim um atributo de alguma outra entidade, ou ser simples-
mente uma varivel do contexto.
importante estabelecermos alguns princpios para que obtenhamos (a partir dos
levantamentos e entrevistas com os usurios e na construo do minimundo ) as entidades de
interesse para a aplicao que est em projeto.
O usurio sempre se refere a processo quando nos descreve uma realidade em que
esto situadas suas atividades.
Pense e lembre que o modelo de dados no fluxograma, logo no tem comeo nem
fim. Esteja atento a referncias a substantivos, pois pode ser a indicao de uma entidade.
Entidade Fraca ou Dependente
uma entidade que no possui existncia prpria individualizada no ambiente sem que
seja dependente da existncia de uma entidade dita forte qual ela est relacionada.
A entidade fraca no modelo lgico no possui chave primria, pois por definio uma
entidade subordinada. Para formarmos a chave primria de uma entidade fraca, utilizamos a
chave primria da entidade forte da qual ela existencialmente dependente, mais o conjunto
mnimo de atributos que possa identificar uma entidade em um conjunto de entidades fracas.
Por exemplo, no relacionamento que apresentamos entre as entidades funcionrio e
histrico de cargos, podem ser modeladas respectivamente como entidades forte e fraca.
Isso porque a entidade funcionrio (matrcula, nome, endereo) tem por natureza
atributos que so chaves candidatas e, por consequncia, possui uma chave primria.
J a entidade Histrico de cargos (data, cargo) no possui um conjunto de atributos que
possa identificar cada uma de suas instncias.
Desta forma, para montarmos a chave primria de histrico de cargos, usamos a chave
primria da entidade funcionrio, definindo assim a entidade histrico de cargos (matrcula,
data, cargo).
Como Reconhecer Entidades na Prtica

Observe em seguida uma lista de perguntas teis para identificar entidades em um
contexto:
Que coisas so trabalhadas?
O que pode ser identificado por nmero, cdigo?
Essa coisa tem atributos? Esses atributos so relevantes, pertinentes?
Essa coisa pode assumir a forma de uma tabela?
um documento externo (recibo, fatura, nota fiscal)? Se sim, forte candidato
entidade.
Tem significado prprio?
Qual a entidade principal do contexto?
Dicas:
Substantivos que no possuem atributos podem ser atributos de outras entidades.
Adjetivos colocados pelos usurios indicam normalmente atributos de uma entidade.
Verbos indicam provveis relacionamentos.
Advrbios temporais indicam provveis atributos de um relacionamento.

Procure sempre visualizar a entidade principal do contexto sob anlise.
Entidades cujo nome termine por "ento" ou por "o" geralmente so procedimentos.
Como Reconhecer Relacionamentos

Aps obter e identificar as entidades que compem o contexto de aplicativo que
estamos projetando, a prxima etapa consiste na definio dos relacionamentos que existem
entre as entidades e que interessam aos nossos propsitos.
No momento em que obtivermos o domnio dos relacionamentos e entidades, pode-
remos traar um primeiro diagrama ER que servir de base para as etapas seguintes.
Dicas para reconhecer e inserir relacionamentos no modelo:
O relacionamento necessrio?
Ele til?
redundante?
Se redundante, retirar?
Qual a sua finalidade? (Documentar)
Verbos indicam possveis relacionamentos.
Analisar sempre as entidades aos pares.
Veja que a notao de Peter Chen interessante e bastante expressiva, porm quando
temos modelos com grande quantidade de entidades e relacionamentos, o espao ocupado no
diagrama pela representao desse relacionamento torna o modelo sensivelmente confuso,
com muitos cruzamentos de linha e complicado de ser lido apesar da expressividade dos
relacionamentos por meio de losangos.
As ferramentas CASE de mercado no disponibilizam esse tipo de notao para
diagramas de Entidade-Relacionamento. A maior parte delas utiliza a notao da engenharia
de informaes, mais conhecida e divulgada.
Vamos ento apresentar neste ponto como essa notao, para que possamos seguir
utilizando-a neste livro.
Chamada de notao da engenharia de informaes ou notao James Martin. Para a
engenharia de informao (mtodo de desenvolvimento de sistemas de informao) foi definida
a seguinte notao grfica para o que apresentamos at o momento neste livro:
Comparativo entre Notao Peter Chen e Engenharia de Informao
Conectividade Engenharia de Informao Peter Chen
1:1
1:N
N:N
Existncia
Obrigatrio
Opcional
simples trabalhar com este tipo e notao, principalmente se perdermos o foco na

expresso do relacionamento que pode ser escrita sobre a linha do relacionamento.
Mais importante que descobrir e relacionar os atributos de cada entidade assinalar as
entidades e seus relacionamentos independentemente de atributos quando trabalhamos com
modelos conceituais.
Deixe para um segundo momento a anlise de atributos.
Outro detalhe na engenharia de informao que a notao que a entidade
representada da mesma forma que a notao de Peter Chen, quando tratamos somente da
entidade. Entretanto, quando modelamos a entidade de atributos, essa notao passa a ser
muito parecida com a de Rumbaugh. Vejamos ento como fica o modelo com essa notao:
Para continuarmos a fixar o apresentado at este ponto do livro, vamos estudar outra
situao de contexto e realizar o modelo de dados necessrio sua soluo.
Uma Distribuidora de Filmes

Vamos projetar um modelo de dados que atenda s necessidades de controle dos
cinemas e filmes em uma determinada empresa de distribuio de filmes:

A empresa de distribuio possui vrios cinemas em diversas localidades.
Cada cinema possui uma identificao nica (cdigo do cinema), um nome
fantasia, um endereo completo, incluindo rua, avenida, bairro, municpio, estado e
sua capacidade de lotao.
Os filmes podem ser dos mais variados tipos e gneros.
Os cinemas apresentam os mais diversos filmes durante a sua existncia. Cada
apresentao de filme tem uma data de incio de uma data de fim de exibio, que
corresponde ao ltimo dia do filme em cartaz.
Cada filme registrado com um ttulo original, e se for estrangeiro, possuir
tambm o ttulo em portugus, o gnero, sua durao, sua impropriedade e
seu pas de origem, informaes sobre os atores que compem seu elenco e o seu
diretor.
Existir um nico diretor para cada filme.
Um filme pode ser exibido simultaneamente em vrios cinemas de diversas locali-
dades.
Os atores de um filme podem, obviamente, atuar em diversos filmes, assim como o
diretor de um filme pode tambm ser ator nesse filme ou ainda mais, ser ator em
outro filme. Em cada filme o ator representa um papel ou personagem. Um ator tem
as seguintes caractersticas: um nome, uma nacionalidade, sexo e uma idade.
Seguindo as dicas para identificao de entidades, temos neste contexto as seguintes
entidades:
Observando os critrios no texto que define o minimundo, encontramos os substantivos:

Cinema, Ator, Filme.
Estes elementos tm significado prprio, logo podem ser caracterizados como
entidades.
Filme tem uma srie de atributos que o caracterizam, alm do que podemos visualizar
que existem muitas ocorrncias de filme em nosso caso.
Cinema, da mesma forma, j tem atributos prprios que o caracterizam, alm de ser
fcil imaginar a existncia de diversos cinemas. O mesmo critrio vale para ator.
Vamos analisar e descobrir os relacionamentos existentes por pares de entidades:
Cinema e filme tm algum relacionamento entre elas?
A resposta correta sim, pois cinema exibe filme.
Logo temos um relacionamento existente entre cinema e filme.
Representando pela notao de Chen:
Porm, temos agora que determinar a conectividade desse relacionamento.

Um cinema exibe quantos filmes?
Quantos filmes voc lembra que foram exibidos em um cinema perto de voc? (Credo,
at parece comercial.)
Um modelo de dados espacial em relao a tempo. As entidades e os relacio-
namentos no so temporais, devem ser analisados em um espao de tempo indeterminado.
As ocorrncias do relacionamento so temporais, mas o relacionamento no, ele espacial.
Logo, um cinema exibe muitos filmes, mas lendo esse relacionamento no sentido con-
trrio de filme para cinema, o que obtemos?
Um filme exibido em quantos cinemas? Em muitos, claro!
Ento um filme exibido em muitos cinemas.
Isso faz com que nosso modelo seja na notao de Peter Chen:
Ou na notao de engenharia de informao:
Agora vamos analisar se existe algum relacionamento entre filme e ator.

Como diz o texto:
"Os atores de um filme podem, obviamente, atuar em diversos filmes..."
Logo o relacionamento de ator com filme, pois na vida real sabemos que os atores
no esto no cinema e sim nos filmes aos quais assistimos. Claro que eventualmente eles
podem aparecer no cinema (vo assistir a uma estreia), mas no nesse contexto que esta-
mos trabalhando.
Ento temos:

Devemos agora descobrir a conectividade entre a entidade ator e a entidade filme.
"Os atores de um filme podem, obviamente, atuar em diversos filmes... ."
A afirmao do contexto clara, e podemos concluir pela vida real que um filme
tambm tem vrios atores, apesar de existirem monlogos.
Logo, nosso modelo agora fica com o seguinte contedo:
ou
Podemos agora partir para analisar se existe mais alguma entidade nesse contexto.
Seria diretor uma entidade?
"Existir um nico diretor para cada filme."
Com esta afirmativa podemos concluir que cada ocorrncia de filme tem uma
informao de diretor e um diretor pode estar informado em mais de uma ocorrncia de filme,
j que sabemos no mundo real que vrios filmes so dirigidos pelo mesmo diretor.
Isso caracteriza que diretor at o momento um atributo de cada ocorrncia de filme,
no se caracterizando como uma entidade com significado prprio, pois ainda no conse-
guimos determinar atributos claros que o descrevam.
Vamos agora colocar atributos nesse modelo para deix-lo

mais legvel.
Para cinema temos:
"Cada cinema possui uma identificao nica (cdigo do
cinema), um nome fantasia, um endereo completo, incluindo rua,
avenida, bairro, municpio, estado e sua capacidade de lotao."
Para filmes temos:
"Cada filme registrado com um ttulo original, e se for filme
estrangeiro, possuir tambm o ttulo em portugus, o gnero, sua
durao, sua impropriedade e seu pas de origem, informaes sobre
os atores que compem seu elenco e o seu diretor."
As informaes sobre os atores de um filme, ou seja, quem
participa do filme, podem ser colocadas no relacionamento entre os
dois, uma vez que um relacionamento de muitos-para-muitos.
Para ator temos:
"Um ator possui as seguintes caractersticas: um nome, uma
nacionalidade, sexo e uma idade."
Entretanto, podemos analisar a afirmativa seguinte e conside-
rar que diretor tem os mesmos atributos de ator, pelo menos at o
momento.
Concluindo o que apresentamos at este ponto do livro, este seria o modelo obtido do
ponto de vista conceitual.
Este modelo de dados deve ser considerado conceitual inicial, pois existem extenses
do modelo ER que podem ser aplicadas a ele.
Para que ele fique mais claro, vamos resolver os relacionamentos muitos-para-muitos.
"Cada apresentao de filme tem uma data de incio e uma data de fim de exibio, que
corresponde ao ltimo dia do filme em cartaz."
Esta afirmao caracteriza atributos do relacionamento exibe.
Logo, data de incio e data de fim so atributos da entidade associativa exibe que vai
substituir o relacionamento muitos-para-muitos.
Vamos analisar o relacionamento entre ator e filme que tambm muitos-para-muitos.

"Em cada filme o ator representa um papel ou personagem."
Logo temos um atributo que do relacionamento entre ator e
filme que ser agora da entidade associativa que denominaremos de
elenco de filme.
Mas como temos de associar e saber quem o ator e qual o filme, vamos colocar um
par desses dados em cada ocorrncia de elenco para ficar claro quem quem.
Nosso modelo ento fica completo at o momento:
Este modelo no pode ainda ser considerado definitivo, pois como j citamos, existem
extenses ao modelo ER proposto por Peter Chen, as quais podem ser aplicadas a este
modelo, deixando efetivamente mais claro e correto. No prximo captulo vamos estudar essas
extenses e aplic-las no prximo exerccio.
Exerccios
Realize o diagrama entidade-relacionamento para os contextos apresentados.
1. Academia de ginstica
Os clientes podem frequentar quantas aulas desejem.
As aulas so identificadas por um nmero sequencial
relativamente modalidade e so caracterizadas pelo
nvel de dificuldade, professor e sala.
Os professores so identificados pelo nome e sobre eles ainda guardado o sobrenome e
o telefone.
Sobre os alunos so conhecidos o nome, idade, sexo, instituio (caso pertena a uma
instituio que o beneficie de desconto) e telefone.
2. Empresa de transportes
Uma companhia de transportes chamada Carregaki
responsvel por transportar encomendas de um con-
junto de armazns at um conjunto de lojas de uma
cadeia denominado Venda Tudo.
Atualmente existem seis armazns e 45 lojas.
Um caminho pode transportar vrias encomendas em
cada viagem, identificada por um nmero de viagem,
descarregando em diferentes lojas.
Cada encomenda identificada por um nmero e inclui a data da encomenda, o peso, o
destino etc.
Os caminhes tm diferentes capacidades, quer relativas ao volume ou ao peso que
podem transportar.
A empresa Carregaki detm, de momento, 150 caminhes e cada caminho tem a
capacidade de fazer trs a quatro viagens por semana.
Pretende-se projetar um banco de dados, utilizado por ambas as empresas, que mantenha
a informao sobre a utilizao dos caminhes e distribuio de encomendas, e que possa
auxiliar na definio dos horrios de distribuio.
3. Revenda de veculos
A AutoStand, que comercializa veculos novos e usa-
dos, deseja um banco de dados para gerir a sua infor-
mao, que descreveu da seguinte forma:
Sobre o veculo:
Matrcula (identificador)
Marca e modelo (tabela)
Data de matrcula
Tipo de veculo: esportivo, passeio, utilitrio, transporte de mercadorias etc. (tabela)
Cor (tabela)
Localizao: indicao do local do veculo (que pode ser um estande, um armazm ou
uma oficina) (tabela)

Data de entrada na AutoStand
Indicao de novo ou usado
Cilindrada
Potncia
Quilometragem
Sobre o cliente:
Nome, endereo, localidade, telefone, CPF, RG
Classificao como regular ou frotista
Vendedor associado
Sobre o fornecedor e proprietrio anterior:
Nome, endereo, localidade, telefone, fax, CPF, RG
Sobre os tipos de custos:
Custos associados ao veculo (funilaria, pintura, eletricista, combustvel, transporte,
despesas de legalizao, despesas de importao, manuteno etc.)
Sobre os valores:
Valor de compra do veculo
Indicao do valor pelo qual se pretende vender o veculo
Indicao dos custos atribudos ao veculo (necessrios para o clculo do custo do
veculo)
Preo da venda, data da venda e condies
Notas: importante guardar as vendas efetuadas por cada vendedor com as respectivas
datas e comisses sobre as vendas para clculo do prmio mensal dos vendedores. Os
veculos novos so disponibilizados por um fornecedor e os veculos usados so comprados do
seu proprietrio anterior.
Importante: Elabore esse modelo com calma e no se preocupe com a quantidade de

entidades que sero descobertas. Siga os roteiros e dicas apresentadas e voc o concluir
com sucesso.

5
EXTENSES DO MODELO
ENTIDADE-RELACIONAMENTO
O modelo de dados Entidade-Relacionamento, como proposto por Peter Chen, tem sido
usado para a comunicao do usurio final apresentando entidades e relacionamentos.
Entretanto, quando usado para integrar diversos modelos conceituais com diferentes usurios
finais, fica severamente limitado at que se utilize um conceito de abstrao de dados denomi-
nado generalizao.
Generalizao: Supertipos e Subtipos

Relembrando o captulo em que foram apresentados os conceitos de abstrao em
modelagem de sistemas, a generalizao ocorre quando se define um subconjunto de
relacionamentos entre duas ou mais classes de dados.
Quando analisamos a entidade funcionrios, conforme o enfoque e o ponto de vista de

cada grupo de usurios finais, observamos que essa classe de dados que definimos como a
entidade funcionrios generalizao de outras classes, tais como gerentes, engenheiros,
secretria, tcnicos em sistemas etc.
Na realidade, a generalizao ocorre quando entidades que possuem atributos em
comum so generalizadas em alto nvel como uma entidade s, como uma entidade genrica
ou uma superclasse de dados. As entidades de nvel mais baixo que fazem parte desse
supertipo de entidade so denominadas de subtipos, e elas refletem a especializao de partes
da entidade supertipo.

A simbologia para representar o relacionamento entre a entidade supertipo e a entidade
subtipo muito variada. Apresentaremos a simbologia utilizando um pequeno crculo na
interseco das linhas que levam do supertipo at os subtipos, com uma indicao em seu
interior.
Essa indicao objetiva distinguir quando a especializao exclusiva, ou seja, no
nosso exemplo, quando um funcionrio engenheiro, ele no nenhum dos outros subtipos,
ou no pertence a nenhum deles.
Existem casos em que a especializao pode no ser exclusiva, existindo overlaping
das entidades subtipos dentro da entidade supertipo.
Observe que dentro do crculo do primeiro exemplo colocamos uma letra D, indicando
disjoint (disjuno) subtipos, o que significa que so subtipos exclusivos, e no segundo
exemplo colocamos a letra O, que significa overlaping de subtipos.
Quando temos a situao de overlaping
de subtipos, uma ocorrncia da entidade super-
tipo no caso empresa, pode ser cliente ou forne-
cedora, dependendo do relacionamento com
outras entidades existentes em um modelo de
dados.
No exemplo ao lado, quando existe o
relacionamento entre nota fiscal de entrada e a
entidade empresa, ele estabelecido com o
subtipo fornecedor. E quando existe o relacio-
namento com pedido, estabelecido com a
entidade subtipo cliente.
Desta forma conseguimos apresentar
uma semntica que possibilita ao usurio final
entender e discutir o modelo de dados, mesmo
existindo reas de negcios distintas e com
usurios finais distintos, com conceitos distintos.
Agora vamos imaginar uma situao em que temos uma entidade de produto de
software, e sabemos que programas e manuais compem cada pacote de produto de software.
Extenses do Modelo Entidade-Relacionamento 103

Como entender esse relacionamento ou essa generalizao?
Em primeiro lugar no podemos denominar de generalizao este caso, pois a entidade
programa e a entidade manual no possuem atributos em comum.
Algumas literaturas denominam de agregao de entidades,
porm no vamos utilizar este termo, pois apresentaremos agregao
em captulo parte, explorando os seus conceitos corretamente.
Vamos denominar de composio, apesar de em abstraes
termos estudado que quando uma classe de dados composta de
vrias outras, estamos agregando coisas.
Analisando, ento, temos que cada ocorrncia de produto de software composta de
muitos programas e tambm de muitos manuais.
Veja que este caso resolve-se simplesmente com dois relacionamentos. importante
destacar que o principal neste momento entender que estamos utilizando dois relaciona-
mentos para desenhar a composio de um determinado produto, uma vez que os atributos de
manual e programa so completamente diferentes neste exemplo.
Utilizamos no primeiro diagrama o crculo de generalizao com uma letra C, indicando

tratar-se de uma composio de entidades relacionadas, mas num diagrama ER devemos
representar os relacionamentos na forma tradicional, exceto pela indicao de que os dois
relacionamentos so obrigatrios.

Optamos ento por uma simbologia mista que permita expressar esse entendimento de
forma simples.
Em realidade existe um s relacionamento no modelo conceitual, pois as duas entida-
des tm o mesmo relacionamento com a entidade produto de software.
No pense agora nos aspectos fsicos dessa implementao para no atrapalhar o seu
raciocnio lgico e conceitual.
Leia-se produto de software composto de muitos programas e muitos manuais.
Esta uma interpretao conceitual do diagrama Entidade-Relacionamento e permite
apresentar um diagrama de entendimento simples para o usurio final.
Vamos voltar ao exerccio de cinemas que estvamos fazendo no captulo anterior para
visualizarmos uma aplicao de generalizao e especializao.
"Existir um nico diretor para cada filme."
"Os atores de um filme podem, obviamente, atuar em diversos filmes, assim como o
diretor de um filme pode tambm ser ator neste filme ou ainda mais, ser ator em outro filme.
Em cada filme o ator representa um papel ou personagem. Um ator possui as seguintes
caractersticas: um nome, uma nacionalidade, sexo e uma idade."
A afirmativa de um diretor tambm pode ser ator permite que visualizemos a seguinte
realidade:
Pessoas podem atuar em filmes, neste caso so atores, ou podem dirigir filmes, ou fazer os
dois simultaneamente.
Logo, podemos aplicar a generalizao e substituir a entidade ator do modelo anterior

por uma entidade, digamos, generalista pessoa.
A entidade pessoa relaciona-se com
filme, criando o papel ator quando ela est
associada pelo fato de atuar em um filme e
relaciona-se com filme da mesma forma por
outro fato que dirige um filme, criando o
papel (alias) diretor.
Ento sabemos que diretor e ator so
papis de uma mesma entidade, pessoa. H
uma generalizao com overlaping, sobreposi-
o de papis.
Vamos ento olhar nosso modelo e ver
como ele ficaria com esse tipo de soluo no
tocante a ator, diretor e filme.
Na representao de engenharia de informao temos uma nica entidade com dois

relacionamentos distintos.

Desta forma agora esto unificadas em uma s entidade tanto as informaes de atores
como de diretores, j que os dois papis podem existir em relao a um mesmo filme. No so
redundantes as informaes de determinada pessoa que atua e dirige um filme, por exemplo.
Relacionamentos Ternrios
So utilizados quando os relacionamentos binrios no conseguem semntica para
descrever uma associao de trs entidades.
No acreditamos muito profundamente nesta afirmativa, mas como em nosso primeiro
livro, tambm vamos manter a apresentao, pois pode ser que um dia algum leitor venha em
nosso socorro e apresente efetivamente uma utilizao real para os relacionamentos ternrios.
Em alguns casos podemos dizer que at possvel a utilizao e o acontecimento de
algum fato ternrio, mas como contraria totalmente o princpio da polarizao binria da forma
de pensar do ser humano, fica difcil aceit-los.
Um exemplo apresentado em muitas literaturas o que est ilustrado a seguir entre
tcnico, projeto e notebook.
Vamos apresentar esta soluo e a nossa, contestando a utilizao de relacionamento
ternrio.
A explicao para este modelo apresentada em outros livros que um tcnico usa
exatamente um notebook para cada projeto.

Cada notebook utilizado por um tcnico em cada projeto. Se o tcnico estiver em
outro projeto, vai utilizar outro notebook.
A afirmao invalida esta soluo, pois teramos um lado muitos nesse relacionamento.
Se imaginarmos que cada um dos projetos somente tem um tcnico, pois so projetos
individuais, estamos colocando o tcnico em mais de um projeto, logo o lado de projeto em
relao a tcnico seria muitos. E se um projeto somente tem um tcnico e no projeto ele usa
somente um notebook que somente utilizado nesse projeto, o relacionamento correto de
notebook seria com projeto. um retrato binrio da situao.
Se ns mantivermos a afirmao de que a relao entre tcnico e projeto de

um-para-um, tanto faz sentido ligarmos o notebook a projeto quanto se ligarmos a tcnico.
Acreditamos que um erro de interpretao procurarmos montar estruturas ternrias ou
mltiplas para retratar coisas de um ambiente que, por realidade, se relacionam sempre
binariamente.

Como veremos no captulo sobre agregao de relacionamentos, o que podemos ter
um relacionamento dependente da existncia anterior de outro relacionamento.
A sntese do pensamento humano est na paridade de raciocnio e entendimento das
coisas de nosso universo e do ambiente que analisamos. Sempre existem dois caminhos ou
duas opes, alm de que sempre mais simples dividir para entender, ou explicar.
Vamos apresentar outro exemplo oriundo de literaturas diversas que mostra um relacio-
namento mltiplo ou ternrio. o relacionamento existente entre alunos, professores e dis-
ciplinas, clssico da literatura de modelagem de dados.
Observe que no conseguimos um verbo para explicitar o relacionamento. Como

denominar um fato que acontece com trs coisas simultaneamente?
Dentro da tcnica de modelagem de dados isto considerado vlido, apesar do
absurdo de nada representar, e ser efetivamente uma soluo criada para viso fsica dos
dados, sem preocupao conceitual de retratar o real.
Vamos agora comear a estudar a modelagem dos atributos das entidade e suas
implicaes nos relacionamentos que aprendemos at o momento, considerando que estamos
modelando relacionalmente, ou seja, para banco de dados relacional, passamos agora a tratar
tambm no nvel de modelo lgico de dados.
Modelagem de Atributos (Modelagem Lgica)

Quando estamos trabalhando com entidades e relacionamentos, devemos manter os
princpios relacionais e suas regras de integridade, a integridade de identidade e a integridade
referencial, pois as nossas entidades vo se transformar em tabelas relacionais e devemos
visualiz-las como tais no modelo lgico.
A partir deste momento vamos iniciar a utilizao tambm da notao grfica para
modelo ER lanada por Gordon Everest, em 1986, que elimina o losango que representa o
relacionamento e simplesmente escreve sobre a linha que une as entidades a nomenclatura do
relacionamento, alm de utilizar os famosos "ps de galinha" para identificar a conectividade
de cada lado de um relacionamento. Vamos manter ainda em conjunto a notao de Chen por
ser em alguns casos mais claro o seu entendimento.

A razo para apresentarmos este outro tipo de notao justifica-se, como j citamos,
pelas ferramentas CASE que dela se utilizam em sua grande maioria.
Outra caracterstica desta notao que, seguindo alguns preceitos de Rumbagh, os
modelos apresentam no interior do retngulo da entidade a relao dos atributos que o
descrevem, inclusive com suas chaves primrias em destaque. Na parte superior da caixa da
entidade esto os atributos que compem a chave primria, e os outros atributos na parte
inferior da caixa, sendo destacadas as chaves estrangeiras como FK (foreign key).
Observe que o mesmo modelo anterior agora possui somente uma linha pontilhada
entre as duas entidades, explicitando o relacionamento.
Como utilizamos um software CASE para este exemplo e no demos nome ao
relacionamento, o software inseriu um cdigo (R/18) para representar tal relacionamento.
Outra caracterstica que se pode perceber que, alm
das chaves primrias das entidades, o modelo apresenta as
chaves estrangeiras, que realizam a efetivao lgica do
relacionamento em banco de dados relacional, transformando
o modelo conceitual em modelo lgico.
Este smbolo de mnimo zero indica que o relacionamento opcional no sentido em que
apresenta o smbolo.
O importante a destacar que todas as entidades que modelamos
no possuem chave estrangeira no mundo real. Ela colocada para que se
possibilite a efetivao lgica dos relacionamentos de acordo com os
princpios relacionais.
Da mesma forma nem todas as entidades que sero encontradas possuem chave
primria evidente, sendo muitas vezes necessria a insero de um atributo cdigo, como
realizamos em departamento.
importante a modelagem de atributos de chave primria, pois eles nos fornecem as
restries lgicas do mundo real para a existncia das ocorrncias de uma entidade.
Em seguida apresentamos um modelo ER maior para exercitar seu entendimento, pois
apresentamos o problema em si e a soluo adotada com um modelo ER.

O Problema
Um negcio imaginrio que chamaremos de softball compreende a participao de
clubes de softball em diversos campeonatos que so realizados por confederaes.
Cada clube pertence a uma confederao somente, entretanto participa de campeo-
natos de todas as confederaes.
Nesse negcio as pessoas so os jogadores ou os organizadores dos campeonatos.
Um campeonato tem muitos jogos.
Um campeonato pode ser organizado por mais de uma confederao. Elas podem
realiz-lo em conjunto.
Desculpe se isso parece com o futebol brasileiro, mas no era este o objetivo.
O mesmo modelo visto sob a perspectiva da notao de Chen ficaria como na figura
apresentada em seguida.
Interpretando o modelo, importante que faamos a leitura dele.
Utilizamos nesta soluo os conceitos de generalizao e especializao, inserindo

uma entidade pessoa que engloba tanto jogadores como organizadores, uma vez que permi-
timos assim que alguns dos jogadores tambm sejam organizadores de uma confederao.

Um jogador atua em muitos clubes.
Um clube tem muitos jogadores.
Um organizador organiza uma confederao somente.
Uma confederao organizada por muitos organizadores.
Uma confederao organiza muitos campeonatos.
Um campeonato organizado por muitas confederaes.
Um clube filiado a uma e somente uma confederao.
Uma confederao tem como filiados muitos clubes.
Um clube joga muitos jogos.
Um jogo jogado por muitos clubes (mximo 2).
Um clube participa de muitos campeonatos.
De um campeonato participam muitos clubes.
Uma crtica que o modelo ER sofre que restries de nmero mximo nos relaciona-
mentos no so expressas.
Existe uma notao que utiliza a expresso dos valores mximos e mnimos em cada
lado do relacionamento, deixando assim mais expressivas essas restries. Lamenta-
velmente as ferramentas CASE mais conhecidas e utilizadas no mercado no implementam
essas possibilidades.

Exemplo
Agora ficam claras as limitaes em cada relacionamento:

Um clube pode ter no mnimo 15 e no mximo 25 jogadores inscritos.
Um jogador s pode estar inscrito em um e no mximo em um clube.
Uma confederao organizada no mnimo por um organizador e no mximo por
quatro organizadores.
Um jogo jogado por no mnimo duas e no mximo duas equipes.
Um clube participa de nenhum ou no mximo de dois campeonatos.
Um campeonato tem no mnimo cinco clubes e no mximo quinze clubes.
Uma confederao organiza nenhum ou no mximo trs campeonatos, que so
organizados por no mnimo uma ou no mximo duas confederaes.
Vamos ento ao modelo lgico desta soluo com a visualizao dos atributos e das
chaves primrias e estrangeiras existentes no modelo.
Importante agora observar que o modelo de dados possui a identificao de chaves
primrias e chaves estrangeiras que efetivam os relacionamentos em um ambiente relacional.

Apresentamos at este ponto a necessidade de incluirmos campos na estrutura de
dados das entidades para que se efetuem os relacionamentos, ou seja, existem campos
comuns para a ligao.
Quando um campo em uma entidade caracteriza-se por ser a chave de identificao
nica de ocorrncias dessa entidade, denomina-se, como j vimos no ambiente relacional,
chave primria.
Quando em uma entidade temos um campo, que chave primria de outra entidade,
temos ento a chave estrangeira dessa entidade.
Essa ligao realiza-se por comparao do valor da chave estrangeira de uma entidade
com o valor da chave primria de outra entidade.
Ora, isso fornece uma expresso lgica, de comparao de valores, que explicita e
estabelece uma regra para o relacionamento entre as duas entidades:
Por exemplo:
Nome do clube em clube = Nome do clube em pessoa
Esta uma expresso de efetivao lgica de um relacionamento.

Se desejarmos saber o nome das pessoas que jogam em um clube especfico, basta
informarmos o valor do nome desse clube para que sejam selecionadas todas as ocorrncias
de pessoas cujo campo NomeClube seja igual ao valor informado.
Este um processo de seleo, ou melhor, uma operao de projeo e seleo
relacional sobre o relacionamento entre a entidade clube e a entidade pessoa.
Nome_pessoa (CLUBE Clube.NomeClube = Pessoa.NomeClube PESSOA)

Veja s, j estamos navegando em um modelo de dados.
Mas vamos aprender isso especificamente em lgebra relacional.
Vamos observar agora as tabelas seguintes, que simulam o contedo das duas entidades.
Entidade: Departamento
Cdigo Departamento Nome Departamento Verba

01 Contabilidade 500,00
10 Vendas 1.000,00
21 Faturamento 250,00
Entidade: Funcionrio
Cdigo Nome Data Admisso Cdigo Depto

0111 Joo 12/11/90 01
0112 Antnio 12/12/91 01
0271 Carlos 05/06/91 10
0108 Eduardo 03/03/90 10
0357 Lus 20/10/91 10
0097 Vera 15/02/92 21
Como estas tabelas que representam as duas entidades possuem chaves primrias e
estrangeiras, conforme o modelo seguinte, podemos responder s questes:
Quais so os funcionrios do departamento de vendas?
Primeiro devemos ver que cdigo do departamento de vendas igual a 10.

Em segundo lugar preciso saber quais funcionrios que tm cdigo de departamento
igual a 10.
Resposta= "Carlos, Eduardo e Lus."
Logo, a existncia no modelo lgico de chaves primrias e chaves estrangeiras possibi-
lita a recuperao de informaes e efetiva logicamente os relacionamentos.
Gostaramos de salientar que a preocupao tem sido sempre nos orientarmos para
recuperar informaes combinadas, no dando nfase neste momento insero, manuteno
ou deleo de dados, aspectos que vamos comentar adiante no livro, mas so elementos que
auxiliam na descoberta do contexto e sua consolidao.
Para um bom trabalho de modelagem devemos esquecer essas operaes comenta-
das, preocupando-nos somente com os dados em si, no nos importando com procedimentos
que sero inerentes ao sistema como um todo.
Na realidade, quando modelamos, no pensamos em sistemas, e sim em conseguir
obter o entendimento de um negcio ou problema, estruturando os dados desse problema com
vistas ao seu domnio e sua soluo.
Para que se solidifiquem os conceitos de uma tcnica, no suficiente apenas a
apresentao de um exemplo de situao e sua aplicabilidade; pelo contrrio, a massificao
de casos analisados que nos d a possibilidade de ter segurana no conhecimento adquirido.
A visualizao de uma massa de casos tem por objetivo, alm da solidificao de uma
cultura, propiciar diversidade de situaes de anlise.
Entendemos que quanto mais situaes passarmos com esta publicao, maior fonte
de consulta o leitor ter para a sua vida profissional.
Quando os Fatos Podem Confundir

O correto entendimento de uma informao depende muito da condio de interpreta-
o dos fatos e da determinao da inerncia do dado pelo analista de sistemas.
O saber interpretar o que um dado caracteriza, ou a quem esse dado se refere de
suma importncia para o resultado correto do modelo de dados.
Vamos ento analisar uma situao em que poderamos ter interpretaes errneas da
verdadeira caracterizao que um dado efetua.
Em uma determinada empresa so realizados diversos projetos de engenharia que
alocam os funcionrios disponveis de seu quadro funcional conforme a necessidade, ficando
esses funcionrios alocados a somente um projeto at o seu encerramento.

Uma vez alocado o funcionrio a um determinado projeto, deve ser registrada a data de
incio de suas atividades no projeto, assim como o tempo em meses que ele vai ficar alocado.
O modelo ER que representa este fato o apresentado na figura seguinte.
Interpretando, ou melhor, lendo o diagrama que exprime o modelo de dados temos:

Um funcionrio alocado a um projeto e um projeto aloca muitos funcionrios.
Surge agora no tocante aos dois dados antes referidos, data de incio e tempo de
alocao, a dvida de sua caracterizao. Esses dados so inerentes ao fato alocao, logo
so campos, dados do relacionamento alocado.
No, esta afirmativa est errada.
Seriam de fato, se um funcionrio fosse alocado a mais de um projeto, mas como um
funcionrio alocado a um projeto somente, esses dados so informaes inerentes ao funcio-
nrio, pois possuem uma nica existncia para cada ocorrncia de funcionrio, que esteja
relacionado com o projeto.
Da mesma forma que na entidade funcionrio, para que se estabelea o relacionamento
com a entidade projeto, necessitamos do atributo Cdigo_do_Projeto em sua estrutura.
Temos assim a seguinte estrutura de dados:
Entidade Atributos Relacionamento

Matrcula do Funcionrio
Nome do Funcionrio
Endereo
Funcionrio Aloca N:1
Cdigo do Projeto (FK)
Data de Incio no Projeto
Tempo Previsto de Alocao
Cdigo do Projeto
Projeto Aloca 1:N
Nome do Projeto
Utilizamos o padro FK (foreign key) para indicar uma chave estrangeira.

Se a realidade colocada em anlise fosse a de que um funcionrio estivesse alocado a
muitos projetos, ela seria uma informao do relacionamento entre funcionrio e projeto, j que
para cada associao do funcionrio com um projeto teramos esses dados para caracteriz-la.
Veremos mais adiante um estudo desse tipo de relacionamento.
A figura seguinte exibe o diagrama de instncias para o relacionamento um-para-muitos
entre funcionrio e projeto.

Propositalmente, colocamos no diagrama de instncias ocorrncias em ambas as
entidades, que no participam de nenhum relacionamento, ou seja, no esto relacionadas.
O funcionrio F7 no est alocado a nenhum projeto, assim como os projetos P4 e P2
no possuem nenhum funcionrio alocado.
Queremos dizer com isso que a condicionalidade, ou melhor, a opcionalidade de um
relacionamento tem tambm o seu grau de importncia no contexto, pois permite que uma
ocorrncia de projeto seja inserida na entidade projeto sem que exista a necessidade, a
obrigatoriedade de j possuir funcionrios alocados antecipadamente, assim como a insero
de uma ocorrncia em funcionrio sem que ela esteja previamente relacionada com uma
ocorrncia em projeto.
Na vida real, esta situao ocorre exatamente desta forma, pois em 99% dos casos em
anlise e projeto, os relacionamentos so obrigatoriamente condicionais no mnimo para um
dos lados do relacionamento.
Que existem ocorrncias de funcionrios que no esto alocados a nenhum projeto
fato concreto, mas como podemos visualizar este fato?
Uma caracterstica para efetivao lgica de um relacionamento um-para-muitos o
fato de ele necessitar da existncia de chave estrangeira em uma das entidades.
Tomamos como regra geral que sempre que existir um relacionamento com cardinalidade de
um-para-muitos, a referncia lgica (chave estrangeira) estar colocada na entidade que
possui o lado muitos da cardinalidade.
No exemplo, a ligao da entidade funcionrio com a entidade projeto ser possvel de

efetuar pela insero do atributo Codigo_do_Projeto (chave primria de projeto) na entidade
funcionrio.
E como devemos entender a opcionalidade do relacionamento com relao aos valores
dos atributos?
Para as ocorrncias da entidade funcionrio que no estiverem relacionadas com nenhuma

ocorrncia de projeto, o atributo tambm existir, porm o valor desse atributo ser NULO,
isto , uma informao desconhecida, inexistente.

Funcionrio
Matrcula Nome Cdigo do Projeto Data de Incio no Projeto Tempo de Alocao

1466 Pedro Antnio P-25 12/12/91 16 meses
2322 Luiz Paulo Diniz P-18 05/01/92 4 meses
7712 Carlos Estevo NULO NULO NULO
4415 Slvia Cristina P-18 18/04/92 5 meses
Projeto
Cdigo do Projeto Nome do Projeto

P-18 Projeto Phoenix
P-25 Projeto Minerva
P-32 Projeto Corrup (Cruzes!!)
P-55 Projeto Nova Ponte
P-203 Oramento 95
importante destacar que existem ocorrncias que justificam a cardinalidade muitos-

-para-um, independentemente de existirem ocorrncias com cardinalidade um-para-um no
conjunto de informaes em anlise.
Na tabela de instncias de funcionrios apresentada, existe um projeto que s
referenciado por uma ocorrncia de funcionrio. Somente o funcionrio Pedro Antnio est
com cdigo de projeto P-25, mas como podemos perceber, existe menos um caso de um
projeto ter seu valor de Codigo_do_projeto referenciado em mais de uma ocorrncia de
funcionrio, o que suficiente para estabelecer esta cardinalidade de muitos-para-um entre
funcionrio e projeto.
A tabela que representa a entidade projeto, se agora analisada em conjunto com a
tabela de instncias de funcionrio, possibilita a visualizao da parcialidade do relaciona-
mento entre as entidades.
Na entidade projeto existe uma ocorrncia (projeto p-32) que no referenciada por
nenhuma ocorrncia da tabela da entidade funcionrio, assim como a entidade funcionrio
possui uma ocorrncia que tem valor nulo para os atributos relativos ao relacionamento com a
entidade projeto: Cdigo_do_Projeto, Data_de_incio e Tempo_de_Alocao so a ocorrncias
do funcionrio Carlos Estevo.
Pelo apresentado nos exemplos, preciso que tenhamos uma massa crtica de dados
para simularmos as suas ocorrncias no mundo real, para que a definio de cardinalidades
seja realizada com segurana.
Agora vamos estudar outra situao neste mesmo caso.
Se, por exemplo, neste caso, a empresa informa que um funcionrio pode atuar em
mais de um projeto, ou melhor, est alocado a mais de um projeto simultaneamente.

Vamos ver como ficaria o modelo de dados, qual alterao sofreria. Teramos um
relacionamento muitos-para-muitos, conforme o diagrama.
Como estudamos na definio de relacionamento com cardinalidade muitos-para-muitos,

esse tipo de relacionamento tem a caracterstica de possuir campos para represent-lo, infor-
maes que podem ser inerentes ao fato, ao evento, que o relacionamento.
Para a efetivao lgica desse tipo de relacionamento, necessitamos de no mnimo dois
atributos, que so as chaves primrias das entidades participantes do relacionamento.
Neste caso em estudo, Data_de_Incio_no_Projeto e Tempo_de_Alocao_no_Projeto
so informaes relativas ao evento que une funcionrio a projeto, e como pode existir mais de
um evento destes para cada ocorrncia de funcionrio, assim como de projeto, esses dados
passam a ser nicos por cada ocorrncia do relacionamento, passando a ser mltiplos no
contexto do modelo.
Como o nmero de ocorrncias do relacionamento indeterminado, no podemos mais
mant-los como atributos de funcionrio, pois no saberamos quantas ocorrncias colocar
desses atributos em funcionrio, sendo necessrio o desdobramento em mltiplos e indefinidos
atributos.
Logo, o relacionamento alocado passa a ter existncia lgica, ou seja, possui dados ou
pode ser transformado em uma entidade associativa, como j vimos outros casos.
As estruturas de dados correspondentes ao modelo apresentado ficam delineadas da
seguinte forma:
Relacionamento ou
Entidades Atributos Atributos
Entidade Associativa
Matrcula_Funcionrio Matrcula_Funcionrio
Funcionrio
Nome_Funcionrio Cdigo_Projeto
Alocado
Cdigo_Projeto Data_Incio_no_Projeto
Projeto
Nome_Projeto Tempo_de_Alocao
Como se efetiva logicamente este relacionamento?

O relacionamento efetiva-se por meio de uma expresso relacional que indica como
deve ser feita a comparao entre os campos comuns s entidades, s que agora com uma
caracterstica diferente: a comparao realizada entre campos das entidades e campos do
relacionamento, formando uma expresso composta.

Expresso de relacionamento:
Funcionrio.Matrcula-funcionrio = Alocado.Matrcula-Funcionrio e
Alocado.cdigo-projeto = Projeto.cdigo-projeto
Esta expresso quer nos dizer que o valor do campo matrcula na entidade funcionrio
deve ser igual ao valor do campo matrcula no relacionamento alocado, e que o valor do campo
Cdigo_do_Projeto no relacionamento alocado deve ser igual ao valor de Cdigo_do_Projeto
na entidade projeto, conjuntamente.
Quando isso acontecer com uma ocorrncia de funcionrio, uma ocorrncia de alocado
e uma ocorrncia de projeto, estaremos relacionando as duas entidades que so funcionrio e
projeto.
Vamos visualizar estes fatos na simulao das tabelas relacionais que representam
esta realidade.
Funcionrio
Matrcula Nome Data_Admisso

1466 Pedro Antnio 12/05/90
2322 Luiz Paulo Diniz 18/06/91
7712 Carlos Estevo 24/05/90
4415 Silvia Cristina 05/05/91
1216 Sandra Chi Min 01/02/92
1401 Maurcio Abreu 15/05/92
Projeto
Cdigo_do_Projeto Nome_do_Projeto
P-18 Projeto Phoenix
P-25 Projeto Minerva
P-32 Projeto Corrup (Cruzes!!)
P-55 Projeto Nova Ponte
P-203 Oramento 95
Vamos ento simular relacionamentos muitos-para-muitos com estas duas tabelas de

ocorrncias das entidades, criando o relacionamento alocado, e suas possveis ocorrncias.

Alocado
Matrcula
Cdigo_do_Projeto Data_Incio_no_Projeto Tempo_de_Alocao no_Projeto
Funcionrio
1466 P-18 24/05/90 24 meses
1466 P-25 12/11/91 06 meses
1466 P-32 02/01/92 12 meses
7712 P-18 10/06/91 04 meses
7712 P-79 12/12/91 12 meses
4415 P-18 15/01/92 03 meses
1216 P-25 01/03/92 05 meses
Vamos interpretar o mundo real pela tabela de ocorrncias do relacionamento alocado:

A ocorrncia de funcionrio com matrcula 1466 est alocada a trs (03) projetos,
respectivamente, P-18, P-25 e P-32, isto , um funcionrio alocado a muitos
projetos.
A ocorrncia de funcionrio com matrcula 7712 est tambm alocada a muitos
projetos (dois).
J as ocorrncias de funcionrio de matrcula 4415 e a de matrcula 1216 esto
cada uma alocada a somente um projeto, pois s constam uma vez dentro do
relacionamento com campos alocados.
Novamente lembramos que ocorrncias relacionando-se com cardinalidade um-para-um
no invalidam a cardinalidade bsica do relacionamento, uma vez que possumos ocorrncias
que realizam a cardinalidade muitos-para-muitos.
sempre muito importante que se efetue a leitura do modelo de dados em dois senti-
dos para compreenso perfeita da realidade. Ento vamos agora analisar a situao por outro
sentido de leitura do relacionamento:
O projeto de cdigo P-18 possui muitas ocorrncias de funcionrio a ele alocadas,
ou seja, respectivamente, 1466, 7712 e 4415, assim como o projeto de cdigo P-25
possui tambm muitas ocorrncias de funcionrio a ele relacionadas (1466 e 1216).
J os projetos P-32 e P-79 possuem somente uma ocorrncia de funcionrio a eles
relacionada.
Observe que interpretamos, ou melhor, realizamos a leitura pura e simples da tabela
que representa esse relacionamento, no considerando ainda neste instante as ocorrncias
das duas entidades que no figuram no relacionamento.
Essas ocorrncias so irrelevantes para a interpretao do relacionamento.

6
AGREGAO:
UMA EXTENSO ESPECIAL
O modelo Entidade-Relacionamento, proposto por Peter Chen na dcada de 1970,
sofreu posteriormente algumas adaptaes e extenses, que visaram torn-lo mais completo e
abrangente. Uma dessas extenses foi o conceito de agregao, introduzido para viabilizar a
modelagem de algumas situaes tpicas envolvendo relacionamentos de cardinalidade N:N.
Existem momentos em que temos uma viso dos dados que nos deixa em dvida sobre
a forma como representar um fato que est relacionado a outro. Isso equivale a dizer que um
relacionamento est relacionado a outro. Mas, conceitualmente, no existem relacionamentos
entre relacionamentos, uma inverdade conceitual.
O que existe no mundo real so relacionamentos depen-
dentes de outros, que somente existem aps a ocorrncia do
outro, considerado fundamental.
O termo agregao tem sido utilizado pelas tcnicas de
modelagem de sistemas nos mais variados conceitos, porm o
conceito lanado em modelagem de dados refere-se viso de
um relacionamento como um bloco, como alguma coisa que se
relaciona com outra.
Chamamos tambm a ateno para o fato da existncia de dependncia entre os fatos,
ou seja, um fato somente acontece aps a existncia do primeiro fato.
Em muitos trabalhos de consultoria observamos que o analista tem medo ou insegu-
rana quanto utilizao de agregaes em seus modelos de dados, seja porque existe a
tendncia de realizar diretamente o modelo fsico ou o lgico, com a visualizao da entidade
associativa, ou porque cometem erros ao utilizar o conceito.
Quando um paciente toma remdios, isso configura um tratamento.
Tratamento existe sem que paciente tome remdio? Sim, pode ter existncia prpria.

Tratamento pode ser, por exemplo:
Tratamento de diabetes
Tratamento de clica intestinal
Tratamento de presso alta
E assim por diante.
Vamos imaginar ento que temos vrios tipos de tratamento.
Poderamos afirmar que quando um paciente toma remdios, pode ter associado um
tratamento, que no impede de existir um tratamento que no esteja associado ao fato de o
paciente tomar remdios. Lembre-se de que nem todas as ocorrncias de uma entidade devem
estar associadas.
O resultado de modelo apresentado uma aplicao certa de agregao, com uma
dose maior de interpretao da realidade.
Vamos exemplificar com outras situaes.
Um determinado rgo pblico de planejamento possui alguns escritrios regionais
estrategicamente distribudos pelo interior de um certo estado, de maneira a facilitar o suporte
aos inmeros projetos desenvolvidos por seus funcionrios.
Tipicamente os funcionrios so alocados a projetos (muitas vezes simultneos) que
atingem vrias regies e tornam-se relativamente comuns situaes em que um funcionrio ou
equipe desempenha algumas tarefas numa determinada regio contando com os recursos
locais do escritrio mais prximo.
Para isso, basta requisitar com antecedncia os equipamentos necessrios ao projeto.
Como existem vrios projetos em andamento ao mesmo tempo, com frequncia ocorre que um
dado recurso seja alocado por mais de um funcionrio para projetos diferentes.
Suponha agora que existem dois funcionrios A e B, alocados a projetos distintos.
A est alocado aos projetos 1 (Censo escolar) e 2 (Censo industrial), enquanto o funcionrio B
est alocado aos projetos 3 (Censo agropecurio estadual) e 2.
Agregao: Uma Extenso Especial 123

Para o projeto 1 o funcionrio A alocou um veculo e um notebook disponveis no
escritrio de uma regio.
O funcionrio B alocou o mesmo veculo para o projeto 3. Considere que, em princpio,
no devemos ter problemas ligados ao compartilhamento do automvel pelos dois funcion-
rios, visto que o projeto 3, digamos, depende da concluso do projeto 1.
Observe que so vlidas, portanto, as seguintes afirmaes:
Um funcionrio pode estar alocado a mais de um projeto.
Um projeto pode ser desenvolvido por mais de um funcionrio.
Um funcionrio pode requisitar um recurso para utilizao num projeto.
Um recurso pode ser utilizado por mais de um funcionrio, geralmente em projetos
diferentes.
Para associarmos um recurso a um funcionrio, devemos levar em conta que

importante que esteja disponvel a informao referente tambm ao projeto para o qual o
recurso ser utilizado. Desta forma, no devemos relacionar recurso nem unicamente a
funcionrio nem unicamente a projeto, mas a ambos. Em termos mais prticos, seria o caso de
associarmos a entidade recurso ao relacionamento alocado que possui atributos, pois
muitos-para-muitos.
Entretanto, o modelo Entidade-Relacionamento no permite esse tipo de ligao direta
com um relacionamento com atributos, pois conceitualmente no existe relacionamento entre
relacionamentos.
Aqui ento entra um parmetro novo em nossa anlise de uma realidade.
Se observarmos o mundo real, a utilizao de um recurso somente acontece QUANDO
existe o fato de um funcionrio estar alocado a um projeto, ou seja, um par do relacionamento
descrito.
Este QUANDO coloca condicionalidade existncia da associao a entidade recurso.
Interpretando mais abrangentemente:
Quando e somente quando funcionrio alocado a projeto, requisita um recurso.
Ento funcionrio alocado a projeto um bloco do modelo, que neste momento
interpretado como uma coisa nica que se relaciona com a entidade recurso.

Esta a representao conceitual de uma agregao.
Algumas literaturas exibem uma representao que uma mistura desta com entidades
associativas.
Veremos outra situao.

Vamos iniciar o estudo com um caso policial, como se estivssemos lendo um jornal
dirio atual, acontecido no Rio de Janeiro, a que tanto assistimos nos telejornais. Uma tpica
(credo!) chacina (arhg!!, quando isso vai parar?).
Os assassinos em nosso caso foram encontrados, mas necessitamos de provas, tais
como as armas do crime.
Nesta situao, podemos afirmar que um criminoso assassinou vrias vtimas e que
uma vtima foi assassinada por vrios criminosos, j que no podemos determinar com
exatido o tiro que realmente causou a morte do coitado, uma vez que vrios meliantes
participaram do fato. Estamos frente a frente com um relacionamento de muitos-para-muitos.
J imaginou isso sendo explicado em um telejornal?

O diagrama da figura apresenta um impasse: temos a entidade marginal e a entidade
vtima relacionadas com cardinalidade muitos-para-muitos.
Aparece ento em cena uma terceira entidade, denominada de arma, arma do crime,
que contm as armas apreendidas.
Como vamos ligar as ocorrncias de arma, ao fato, ao evento representado pelo
relacionamento mata, este um relacionamento com campos?
As entidades arma tm suas ocorrncias relacionadas a marginal, ou est relacionada
vtima?
Se ligarmos arma a marginal, no podemos afirmar que ela foi utilizada no assassinato
de uma vtima. Se ligarmos vtima, mais difcil torna-se estabelecermos uma relao com o
marginal.
Como resolver esta questo?
relativamente simples a soluo. Basta nos determos em retratar a realidade da
mesma forma como ela expressa em linguagem natural, ou seja:
Um marginal mata vtimas. Quando ele mata vtimas, utiliza arma.
Desta forma temos o diagrama Entidade-Relacionamento em seguida:
Nesta expresso da realidade existem dois verbos inter-relacionados, ou seja, existe um

relacionamento entre objetos dependentes um da existncia de outro.
Na realidade so necessrios dois relacionamentos para retratar um fato por completo.
O que desejamos relacionar uma ocorrncia de arma com uma ocorrncia do fato, do
relacionamento mata.
O relacionamento mata, como colocamos na situao, possui campos. Vamos ento
relacionar uma ocorrncia desse relacionamento com uma ou vrias ocorrncias da entidade
arma, criando um relacionamento entre mata e arma, que denominamos de utiliza.
Como j explicamos neste livro, podemos resolver relacionamentos muitos-para-muitos
com a utilizao de entidades associativas.

O diagrama de Entidade-Relacionamento com a utilizao de entidades associativas,
neste caso, apresenta duas destas entidades, uma para substituir o relacionamento muitos-
-para-muitos mata, e outra para substituir o relacionamento tambm muitos-para-muitos utiliza.
Tanto no modelo anterior com a utilizao de relacionamentos muitos-para-muitos como
no seguinte existem atributos nesses relacionamentos ou nas entidades associativas.
Para melhor entendimento vamos conhecer as estruturas de atributos das entidades

envolvidas neste caso policial e seus relacionamentos.
Entidade Atributos Relacionamento

Registro do meliante
Com Vtima atravs de Mata
Nome Oficial
MARGINAL 1:N (Parcial)
Codinome
(Nem todo Meliante assassinou uma Vtima)
Idade
Nm. documento da vtima
Com Meliante atravs de Mata
Nome do infeliz
VTIMA 1:N (Total)
Sexo
(Toda Vtima foi assassinada por um Meliante)
Idade
Nm. apreenso da arma
Com Assassina atravs de Utiliza
Marca da arma
ARMA 1:N (Parcial)
Tipo da arma
(Nem toda arma apreendida foi usada num assassinato)
Nmero de srie
Agora vamos observar as tabelas seguintes que apresentam a simulao das tabelas
representativas das entidades e dos relacionamentos envolvidos nesta novela policial.

Marginal
Registro Nome Codinome Idade

121212 Joo Pedrum Jo Caveira 33
221134 Luiz Cabrum L Vampiro 42
334455 Carlos S Carlinhos Mau 18
212378 Srgio Bruks Balaustre 26
335588 Tonho Silva Tonho Faco 19
Vtima
Documento Nome Sexo Idade

111111111 Antnio Moacir M 58
243387569 Jlio A. Macedo M 35
806578913 Sazaina Moraeis F 24
684714325 Ana Luiza Martins F 32
Arma
Nmero Marca Tipo Srie

191 Taurus Pistola A656B767
192 Magnus Pistola Mg457T8V9
As tabelas apresentadas em seguida mostram apenas uma parte dos valores de dados
dos relacionamentos possveis para as ocorrncias das entidades marginal e vtima, conside-
rando que os casos no esto relacionados ou no foram at esta edio registrados.
Mata Usa
Data Vtima Meliante Vtima Meliante Arma

11/02/92 111111111 121212 111111111 121212 191
14/03/92 243387569 121212 111111111 121212 192
03/04/92 806578913 334455
O fato de um crime associar duas armas ao mesmo meliante um exerccio de

imaginao, mas permite observar que a agregao admite que se tenha uma cardinalidade de
muitos-para-muitos entre o objeto resultante do relacionamento entre marginal e vtima com a
entidade arma.
Ou seja, nesse crime o infeliz matou uma nica vtima utilizando-se de duas armas
simultaneamente ou juntas.
Um detalhe muito importante que a agregao no representada pelas ferramentas
CASE mais conhecidas, o que leva, quando se executam trabalhos de modelagem, a no ser

utilizada, porm isso dificulta a expresso e o entendimento do minimundo , motivo pelo qual
recomendamos sempre a execuo manual de um modelo conceitual para depois iniciarmos
os trabalhos com a ferramenta CASE.
O Hotel
Vamos estudar outros casos e explorar mais situaes de agregao.
Destacamos aqui que necessrio que os analistas de sistemas modelem sempre em
um primeiro nvel conceitual, sendo necessrio para isso utilizar a capacidade mxima de
abstrao. pela viso perceptiva do ambiente que est sendo modelado que conseguimos
atingir modelos mais consistentes, que retratem o mundo real.
Considere um modelo de dados como o da figura, que retrata o ambiente de um hotel.
A leitura do modelo diz que um cliente do hotel pode ocupar muitos quartos e um quarto
pode ser ocupado por muitos clientes.
s vezes, quando apresentamos este modelo, os alunos questionam esta espacialidade
do modelo de dados.
As afirmativas anteriores esto corretas porque o relacionamento entre cliente e quarto
uma relao espacial, no temporal.
Um cliente em relao ao objeto quarto tem um relacionamento de conectividade
muitos-para-muitos porque ele pode vir muitas vezes ao hotel e ficar sempre em quartos
diferentes. O quarto de hotel pode ser ocupado por vrios clientes diferentes em momentos
diferentes.
A noo de tempo est dentro do relacionamento. Cada ocorrncia do relacionamento
possui informaes sobre uma estadia, registro de datas, horas etc.
Seguindo a leitura deste pequeno modelo, coloca-se a seguinte questo:
O cliente do hotel utiliza vrios servios disponveis, alguns com consumo de produtos
como frigobar, restaurante, e outros meramente servios como diria, por exemplo, que um
dos servios do hotel.
Como relacionar estas coisas chamadas servios e produtos com o fato de um cliente
hospedar-se no hotel (Cliente hospeda-se em quarto)?

Em primeiro lugar devemos entender que tudo o que acontece a seguir decorrente,
dependente de cliente hospedar-se em quarto de hotel, logo todo e qualquer relacionamento
ser com esta viso agregada de parte do modelo.
Como servios uma coisa sobre a qual interessa manter informaes, tem significado
prprio, caracteriza uma entidade a mais em nosso modelo. Assim sendo, temos de estudar e
entender como isso no mundo real.
No mundo real os servios so utilizados quando cliente hospeda-se em quarto de
hotel, logo a entidade servios se relaciona com o bloco superior.
Interpretamos o bloco cliente hospeda-se quarto hotel e relacionamos com a entidade
servios.
Agora vamos buscar entender a conectividade que existe entre as ocorrncias de
servios e o bloco cliente no hotel por assim dizer.
Antes, porm, vamos visualizar como seriam os dados numa estruturao de tabelas
destas entidades at o momento.

Cliente

Quarto
NumQuarto Andar Tipo Quarto

101 1 Single
102 1 Doble
301 3 Single Luxo
401 4 Single Luxo
1402 14 Sute Presidencial
O relacionamento hospeda-se possui atributos, uma vez que um muitos-para-muitos.
Hospeda-se
CodCliente NumQuarto DataEntrada DataSaida

1 101 21/12/2003 22/12/2003
2 102 15/2/2004 17/2/2004
3 301 10/1/2004 18/2/2004
4 101 11/1/2004 30/1/2004
2 401 15/2/2004 16/2/2004
3 1402 25/12/2003 3/1/2004
1 102 15/3/2004 1/4/2004
Acompanhe a tabela de servios para que fique claro o que ela representa.
Servios
CodServico Nome Servico

1 frigobar
2 Restaurante
5 Servio de Quarto
7 Sauna
10 Diria

Um cliente hospeda-se em quarto utiliza quantos servios? Muitos, claro.
Um servio utilizado por quantos clientes que se hospedam em quarto de hotel?
Tambm a resposta muitos, logo temos um relacionamento muitos-para-muitos entre
servios e clientes que se hospedam em quarto de hotel.
Este mais um relacionamento que deve ter atributos, pois devem estar registradas
nesse relacionamento as datas de utilizao, hora, valor do servio.
Utiliza
CodCliente NumQuarto CodServico Data Hora Valor

1 101 1 21/12/2003 15:30 50,00
2 102 5 15/2/2004 18:00 75,00
3 301 10 10/1/2004 12:00 150,00
4 101 1 11/1/2004 8:00 8,00
2 102 10 15/2/2004 12:00 220,00
3 1402 2 25/12/2003 21:45 150,00
1 102 10 15/3/2004 12:00 90,00
2 401 5 16/2/2004 22:00 18,00
3 1402 2 31/12/2003 19:00 1.500,00
Logo voc vai se perguntar: mas os produtos no so atributos do relacionamento

utiliza?
Antes de respondermos, vamos analisar um pouco mais a realidade.
Quando produtos so consumidos?
Os produtos so consumidos normalmente quando se utiliza algum servio do hotel. No
restaurante, no bar, no frigobar e principalmente o fato de estar no hotel, pois a diria nada
mais que o valor cobrado por cada dia de estada e tambm um servio, o servio de hospe-
dagem propriamente dito.

Ento, produto est relacionado com o relacionamento
utiliza?
Claro, pois nada impede ou limita o nmero de agrega-
es em um modelo de dados. Elas podem ser superpostas
sem nenhum problema, pois estamos nada mais nada menos
que retratando uma realidade.
Leia o modelo soluo apresentado, interprete-o e procure visualizar o mundo real para
valid-lo. Lembre-se de que deve ser lido da mesma forma que foi construdo: em camadas
superpostas.
Claro que os relacionamentos so opcionais neste caso, e como apresentamos no
captulo, no possvel explicitar no modelo na notao de Chen as regras da opcionalidade
quanto sua temporalidade.
O utiliza um relacionamento de muitos-para-muitos, pois uma ocorrncia de servio

pode ser utilizada por muitas ocorrncias de cliente hospeda-se em quarto.
Agregao o bloco cliente hospeda-se em quarto, um fato multirrelacional nos dois
sentidos de leitura.
O fato dependente utiliza, pois ele somente existe, ou melhor, acontece, quando o
primeiro fato j existe.
Aps agregarmos cliente hospeda-se em quarto e relacionarmos com servios, vamos
ento agregar este fato (utiliza) com o anterior (hospeda-se) e tratar este fato composto como
um nico bloco, uma nica coisa, e relacion-lo com o consumo de produtos.
Lendo o modelo final, temos:
Cliente hospeda-se em quarto. Quando se hospeda utiliza servios. Quando utiliza ser-
vios consome produtos.

Observe que os trs relacionamentos muitos-para-muitos possuem dados.
Hospeda-se pode ter os dados de data de chegada do hspede, data de sada, alm de
informaes padro Embratur etc.
Utiliza tem informaes sobre quando foi utilizado o servio, conforme apresentamos na
tabela.
Consome indica as quantidades de produtos consumidas pelo servio utilizado.
Vejamos ento a tabela representativa de produto e de consumo.
Produto
CodProduto Descrio Valor Unitario

1 Coca-Cola R$ 2,00
5 Cerveja Long Neck R$ 3,50
52 Mate R$ 1,50
84 Caf R$ 1,00
21 Suco R$ 3,00
16 gua Min. R$ 1,80
85 Steack T-Bone R$ 25,00
12 Camaro Empanado R$ 32,00
9 Cheesburger R$ 12,00
1 Castanhas de Caju R$ 15,00
7 Vinho Tinto Importado R$ 80,00
25 Sobremesas R$ 10,00
99 Ceia Fim de Ano R$ 900,00
59 Champagne Importado R$ 200,00
Consumo
CodCliente NumQuarto CodServico Data Hora CodProduto Quantidade Valor Total

1 101 1 21/12/2003 15:30 52 1 1,50
1 101 1 21/12/2003 15:30 5 5 17,50
1 101 1 21/12/2003 15:30 1 2 30,00
4 101 1 11/1/2004 8:00 5 2 7,00
4 101 1 11/1/2004 8:00 84 1 1,00
2 102 5 15/2/2004 18:00 85 3 75,00
3 1402 2 25/12/2003 21:45 7 1 80,00
3 1402 2 25/12/2003 21:45 85 2 50,00
3 1402 2 25/12/2003 21:45 25 2 20,00

CodCliente NumQuarto CodServico Data Hora CodProduto Quantidade Valor Total
2 102 5 16/2/2004 22:00 5 4 14,00
2 102 5 16/2/2004 22:00 21 1 3,00
2 102 5 16/2/2004 22:00 84 1 1,00
3 1402 2 31/12/2003 19:00 7 6 480,00
3 1402 2 31/12/2003 19:00 99 1 900,00
3 1402 2 31/12/2003 19:00 25 2 20,00
3 1402 2 31/12/2003 19:00 59 1 200,00
Para entendermos agregao, voltamos a insistir que necessrio modelar o ambiente

sem pensar em procedimentos e no pensar no banco de dados fsico.
Para fins de esclarecimento apresentamos o modelo de tabelas para a implantao
desse modelo do hotel, mas somente para voc conseguir visualizar os dados e sua organi-
zao em um modelo de dados conceitual, pois como sempre destacamos, no devemos
modelar diretamente para o ambiente fsico, pois retira a capacidade de visualizar abstraes e
modelar corretamente o mundo real.
Observe que nas tabelas referentes ao modelo os relacionamentos aparecem como
tabelas tambm, pois se possuem dados, logo so tabelas relacionais. Como so relaciona-
mentos muitos-para-muitos, as chaves estrangeiras tambm esto neles, pois so as efetiva-
es lgicas dos relacionamentos.
Com colunas comuns podemos realizar junes de tabelas para a recuperao de

informaes do negcio.

Explicao Adicional sobre as Chaves
Quando partimos para um modelo de dados em que inserimos chaves primrias e
chaves estrangeiras, estamos realizando modelos lgicos, pois fazemos a efetivao dos
relacionamentos agora voltados para regras do modelo relacional, com o uso de colunas
comuns entre tabelas associadas a um fato ou por um fato.
Vamos continuar a estudar mais agregaes.
Uma pergunta que j foi feita vrias vezes: uma agregao pode estar relacionada
outra agregao?
Pode, pois so dois objetos que se relacionam no mundo real, logo possvel.
Vamos estudar rapidamente um caso com esse tipo de aplicao de modelo.
Clnicas Mdicas
Vamos expor a situao e o modelo de soluo para este caso.
Uma clnica mdica que uma empresa realiza atendimentos mdicos nas mais diver-
sas especialidades e situa-se em determinados endereos, que denominaremos de local.
Em cada endereo, uma clnica mdica atende uma e somente uma especialidade
mdica.
As clnicas mdicas tm mdicos contratados, que atendem somente uma especia-
lidade mdica na clnica na qual so contratados. Uma especialidade mdica pode ser exercida
por vrios mdicos, mas um mdico pode exercer somente uma especialidade em uma clnica
mdica.
Um mdico somente pode ser contratado por uma clnica.
Uma clnica pode disponibilizar atendimento na mesma especialidade ou especialidades
diferentes em locais diferentes.
Um nico local e suas instalaes podem ser compartilhados por duas ou mais clnicas
mdicas por meio de um contrato de compartilhamento.
Por exemplo, uma clnica atende na parte da manh em um determinado local, e outra
clnica atende nesse local na parte da tarde, ou ento as salas do local so divididas no
mesmo horrio ou turno.
Sempre que atende um paciente, o mdico preenche um receiturio por paciente
atendido, que pode conter de ZERO a N (muitos) remdios, e no mnimo uma prescrio
mdica ou um atestado, portanto sempre obrigatrio o preenchimento. Todos os pacientes
so registrados independentemente da clnica que os atendeu.
Um mesmo paciente em datas diferentes pode ter receitas com o mesmo remdio, com
mdicos diferentes ou com o mesmo mdico.

O cdigo e o nome dos remdios so padres internos do sistema, obedecem ao
critrio de formulao genrica, portanto podem ser supridos por qualquer laboratrio
farmacutico. So controlados pela sua substncia ativa e no por marca.
Um remdio s pode ser receitado uma nica vez na mesma data para o mesmo
paciente.
Vamos analisar este modelo tentando isolar as partes do negcio para facilitar a nossa
conquista do modelo de negcio.
Como j dizia Jack, o estripador, vamos por partes.
O primeiro bloco de modelo que vamos analisar talvez seja o centro do negcio de
clnicas mdicas, o atendimento, a consulta de pacientes.
Um mdico atende muitos pacientes.
Um paciente consulta com muitos mdicos
Logo, nosso relacionamento no centro do negcio est correto como na figura seguinte.
Entretanto, dependendo da interpretao do ambiente e da capacidade de abstrao do

analista, tambm vlida a interpretao de que existe um objeto consulta neste contexto.
Desta forma devemos nos preocupar em entender como so os relacionamentos entre
as entidades do contexto: mdico, paciente e consulta.
Um mdico faz muitas consultas.
Cada consulta tem um e somente um mdico.
Um paciente tem muitas consultas.
Cada consulta tem um e somente um paciente.
Esta tambm uma interpretao vlida para este problema.

Bem, vamos quebrar outro bloco para o modelo.
"Uma clnica mdica, que empresa, realiza atendimentos mdicos nas mais diversas
especialidades e situa-se em determinados endereos, que denominaremos de local."
Ento temos a entidade clnica e uma entidade local, e existe um relacionamento entre
as duas entidades.

Analisando as afirmativas seguintes sobre clnicas e locais:
"Um nico local e suas instalaes podem ser compartilhados por duas ou mais clnicas
mdicas por meio de um contrato de compartilhamento."
Ento um local pode ter mais de uma clnica.
Podemos concluir que uma clnica situa-se em muitos locais e em um local situam-se
muitas clnicas?
Ainda no. At o momento somente podemos concluir que um local pode ter mais de
uma clnica.
"Uma clnica pode disponibilizar atendimento na mesma especialidade ou especia-
lidades diferentes em locais diferentes."
"Uma clnica mdica... situa-se em determinados endereos, que denominaremos de local."
"Porm, em cada endereo uma clnica mdica atende uma e somente uma especia-
lidade mdica."
Analisando estas trs assertivas, podemos afirmar que uma clnica pode situar-se em
muitos locais de atendimento.
Temos agora a conectividade deste relacionamento, que muitos-para-muitos tambm.
Da mesma forma podemos visualizar ou entender estas associaes sem o uso de

agregao, simplesmente pelo entendimento de que existe um objeto contrato que associa
clnica e local.
O leitor deve estar perguntando: onde foram colocados os remdios e as especialidades?

Sim, porque esto caracterizados pelo critrio e dicas como entidades.
Calma, chegaremos l.
Existem afirmativas neste caso que estabelecem relaes entre mdicos e clnicas e
ainda por cima destaca-se especialidade como algo relevante. Seno, vejamos:

"As clnicas mdicas tm mdicos contratados, e estes atendem somente uma especia-
lidade mdica na clnica pela qual esto contratados."
"Porm, em cada endereo atende (a clnica) uma e somente uma especialidade
mdica."
"Um mdico somente pode ser contratado por uma clnica."
Logo, temos relaes entre mdicos, clnicas e especialidades e ainda por cima entre
especialidades e clnicas.
Todo mdico tem uma e somente uma especialidade quando est associado,
contratado por uma clnica, que a especialidade em que ele vai atuar nessa
clnica.
A clnica em um local atende uma e somente uma especialidade
Um mdico s pode estar relacionado a uma clnica.
Como o mdico s pode atuar em uma especialidade na clnica que o contratou, e
somente pode estar vinculado a uma clnica, somente nos interessa a especialidade em que
ele atua na clnica.
Vejamos a soluo para a primeira afirmativa.
Um mdico tem uma e somente uma especialidade, e uma especialidade tem muitos
mdicos.
Continuando o modelo.
Quem mais tem especialidade? A clnica? O local?
A resposta correta que a clnica no local tem especialidade.
"Porm, em cada endereo atende (a clnica) uma e somente uma especialidade
mdica."
Logo podemos usar mais uma agregao no modelo.
O conjunto, bloco de agregao "clnica situa-se local" relaciona-se com especialidade.
"Uma clnica situa-se local" atende em uma especialidade, e uma especialidade
atendida em muitos "uma clnica situa-se local".
O relacionamento de especialidade com o bloco feito com a agregao apresentada.

Continuando com as alternativas de interpretao, se estamos com o modelo aberto
anteriormente sem agregao, como efetivar esses relacionamentos?
O diagrama apresenta o relacionamento de especialidade com o equivalente da

agregao anterior, que a entidade associativa contrato. O relacionamento de especialidade
com mdico idntico ao modelo com agregao.
Vamos analisar e estudar agora o que fazemos com os remdios citados neste caso.
"O cdigo e o nome dos remdios so padres internos do sistema, obedecem ao
critrio de formulao genrica, portanto podem ser supridos por qualquer laboratrio
farmacutico. So controlados pela sua substncia ativa e no por marca."
Logo, remdio uma entidade, pois tem significado prprio e dados que o descrevem.
Analisando outra afirmativa do problema: "Sempre que atende um paciente o mdico
preenche um receiturio por paciente atendido, que pode conter de zero a N (muitos) rem-
dios, e no mnimo uma prescrio mdica ou um atestado, portanto sempre obrigatrio esse
preenchimento. Todos os pacientes so registrados independentemente da clnica que o
atendeu."
Isso denota que existe um relacionamento entre remdio e o atendimento de um mdico
a um cliente, a consulta propriamente dita.
Como temos um relacionamento de muitos-para-muitos entre mdico e paciente, e
representa o fato da consulta, podemos realizar uma agregao e relacion-la com remdios,
pois quando existe consulta (agregao) so receitados de zero a N remdios.

Destacamos no modelo apresentado em seguida as ligaes entre remdios e a
agregao e a ligao entre especialidade e mdico.
O objetivo destacar que um relacionamento ocorre entre uma entidade e um bloco,
uma agregao, enquanto outro (especialidade tem mdico) ocorre entre duas entidades
diretamente.
Observe no modelo que a linha que une o relacionamento tem e a entidade mdico
contnua at a caixa da entidade, enquanto a linha do relacionamento entre remdio e o fato
consulta contnua at a caixa que representa, destaca a agregao.
Agora ser que nosso modelo est completo? No representamos ainda neste modelo
a associao, o relacionamento entre mdico e clnica.
"As clnicas mdicas tm mdicos contratados, e estes atendem somente uma espe-
cialidade mdica na clnica pela qual so contratados. Uma especialidade mdica pode ser
exercida por vrios mdicos, mas um mdico pode exercer somente uma especialidade em
uma clnica mdica."
"Um mdico somente pode ser contratado por uma clnica."
Logo, devemos ainda inserir mais um relacionamento no modelo obtido at o momento.
Um mdico atende em uma clnica.
Uma clnica pode ter muitos mdicos atendendo.
O relacionamento entre as entidades mdico e clnica.

Neste ponto destaca-se a seguinte questo:
Neste modelo, como podemos descobrir onde o mdico atende paciente?
Do jeito que est no existe nenhum caminho de navegao que possibilite chegar a
esta resposta.
Se obtivermos os dados do paciente, do mdico e da consulta, podemos identificar uma
especialidade. Seguindo por especialidade, vamos obter mais de uma clnica, sem falar nos
locais mltiplos que podemos encontrar para cada clnica. Se navegarmos por mdico e
clnica, tambm vamos encontrar muitos locais.
Como resolver ento este problema do modelo?
A soluo vem de um relacionamento entre duas agregaes neste modelo.

Observe a ligao do relacionamento com os dois blocos que representam a agregao.
Este mesmo modelo, no momento em que formos utilizar uma ferramenta de mode-
lagem, como estas esto direcionadas para bancos de dados relacionais e no implementam o
conceito de agregao nos seus templates de modelagem lgica, causar a necessidade de
utilizar tabelas associativas no lugar de relacionamento muitos-para-muitos.
Vamos mostrar agora o mesmo modelo lgico de duas formas diferentes: sem os
relacionamentos muitos-para-muitos com agregaes, realizado em uma ferramenta CASE, e o
modelo a partir dos exemplos de entendimento do minimundo sem agregaes que vnhamos
j apresentando neste caso.
Todos os modelos apresentados satisfazem as necessidades explicitadas para o
minimundo.
Modelo com notao de Chen sem relacionamentos muitos-para-muitos

O modelo seguinte gerado em uma ferramenta CASE com a especificao dos
atributos de todas as entidades.
Como detalhe no estamos apresentando os nomes das entidades para que o leitor
exercite e identifique cada uma das nossas entidades e relacionamentos.
Observe que os trs relacionamentos muitos-para-muitos que se transformaram em

entidades possuem um nmero acentuado de atributos, principalmente em suas chaves
primrias, pois herdam as chaves primrias, constituindo-se em chaves estrangeiras dentro
das prprias primrias, das entidades relacionadas.
O que desejamos mostrar que a utilizao de agregao um fato natural na maioria
dos modelos de dados. Sempre temos algum fato que se relaciona com uma outra entidade ou
com outro fato.
Em empresas industriais um fato muito comum, como vamos demonstrar no prximo
exemplo em estudo, uma fbrica de produtos sob encomenda.
A Fbrica
Vamos analisar outra situao de agregao bem prtica, em uma indstria que fabrica
seus produtos sob encomenda, ou seja, no existe estoque, os pedidos de produtos so
recebidos e tabulados. Existe ento a emisso de muitas ordens de produo. A ordem de
produo depende da quantidade de cada produto solicitado nos pedidos, executada para
atender vrios pedidos ou somente um.

Considerando que as ordens de produo executam a
fabricao de somente um produto cada uma, podemos ter vrias
ordens de produo sendo executadas para atender cada pedido.
Vamos iniciar a nossa interpretao da realidade pela relao existente entre pedido e
produto, muito apresentada em literaturas que falam (falam, mas no ensinam) sobre modelo
de dados Entidade-Relacionamento. A figura mostra este relacionamento.
Um pedido solicita um ou vrios produtos.

Um produto solicitado por um, vrios ou nenhum pedido.
Novamente destacamos que este relacionamento opcional no sentido de produto para
pedido, pois podemos ter ocorrncias de produto que no estejam solicitadas por nenhuma
ocorrncia de pedido. Somente no podemos dizer quando e como isso ocorre na vida real.
E como relacionamos a ordem de produo comentada com o fato?
Se voc acompanhou este livro com calma at este ponto, j sabe o resultado da
questo proposta.
Ordem de produo se relaciona com a agregao formada por pedido solicita produto.
Este relacionamento muitos-para-muitos.

Como? Vamos ler o modelo e entender a realidade.
Quando um pedido solicita produtos, ento atendido por uma ou vrias ordens de
produo.

Uma ordem de produo atende um ou vrios pedidos que solicitam produtos.
Por que no relacionar a ordem de produo diretamente com pedido?
Porque a ordem de produo vai atender a solicitao de produtos especificados no
relacionamento entre pedido e produto e no ao pedido todo.
Onde est a informao sobre os produtos em cada pedido?
Est no relacionamento, que possui campos, dados.
Observe o modelo com atributos bsicos nos relacionamentos e exercite sua leitura de
um modelo de dados.
Existe uma regra para todo vendedor: voc s vende aquilo que compraria.
Aplicada a este caso:
Voc s aprova o modelo de dados que entende.
Regras para Identificar e Utilizar Agregao

Mesmo apresentando exemplos, sabemos que no dia a dia dos analistas de sistemas a
atividade de modelar dados realizada sob intensa presso de gerentes e usurios, logo
necessitamos passar aos leitores algumas regras e dicas para identificar rapidamente as
possibilidades de existncia de agregaes nos modelos de dados em construo.

Regra 1
Somente podem existir agregaes em relacionamentos de muitos-para-muitos.
Um relacionamento muitos-para-muitos sempre representa um fato, um acontecimento

entre duas coisas, duas entidades.
Ora, na vida real sabemos que quando algo acontece, podem existir coisas ou fatos que
so decorrentes do acontecido.
Por exemplo, na vida real:
Acidentes de Trnsito
Acidentes ocorrem em vias de circulao, sejam
estradas, ruas ou avenidas, e envolvem sempre veculos e
pessoas.
Modelando isso, sabemos que acidente um fato, e
poderamos afirmar que:
Veculos acidentam-se em locais.
Como nosso trnsito muito maluco, ou melhor, mal-educado mesmo, em um determi-
nado local podem ocorrer muitos acidentes com muitos veculos.
Um veculo pode sofrer muitos acidentes em vrios locais.
J temos neste momento a regra nmero 1 satisfeita: um relacionamento de muitos-
-para-muitos entre veculos e locais.
Regra 2
Sempre que obtivermos em um modelo de dados um relacionamento
muitos-para-muitos, devemos questionar, ou melhor, dirigir nossa anlise
para o que existe neste mundo real que seja decorrente do fato representado.
Se existir alguma coisa associada, decorrente do fato, estamos j com a definio de

que algo se agrega ao relacionamento definido.
Seno, vejamos o exemplo real.
Quando veculo acidenta-se em local, o que acontece?
O que nos interessa saber?

O que perguntaramos logo que obtivssemos esta informao?
O sdico perguntaria:
Quantos morreram?
O tcnico perguntaria: foi imprudncia ou excesso de velocidade?
O policial perguntaria:
J registraram a ocorrncia?
J chamaram socorro?
Os envolvidos perguntariam, se estiverem vivos:
Voc tem seguro?
Observa-se que existiriam, na vida real, muitas questes que naturalmente nos levariam
a encontrar alternativas de coisas relacionadas ao fato.
Vamos analisar somente uma: vtimas (sdico).
Quando veculo acidenta-se em local, existem vtimas.
Vtimas participam de veculo acidenta-se em local.
Com base nas afirmativas podemos desenhar um modelo de
dados com agregao como soluo, como na figura seguinte.
Regra 3
A ltima regra determinarmos a conectividade
do relacionamento entre a entidade e a agregao.
Por que isso importante para colocarmos como regra?

Porque em certos casos a conectividade vai nos apresentar ou fazer entender que a
"coisa" um atributo do relacionamento e no uma entidade, o que elimina a utilizao da
agregao.

No caso, quando um veculo acidenta-se em local, pode existir uma ou vrias vtimas.
E uma vtima vtima de um acidente, ou pode tambm ser muito azarada e aparecer
como vtima em muitos acidentes.
Se existir conectividade desta forma, temos um relacionamento entre a entidade vtimas
e o bloco de modelo veculo acidenta-se em local do tipo muitos-para-muitos.
E como colocamos as outras perguntas feitas?

Vejamos:
Imprudncia ou excesso de velocidade d a entender que toda vez que houver um
acidente existe uma causa.
Descobrimos mais um objeto, as causas possveis de um acidente.
Mas pode haver mais de uma causa em um acidente? Claro que pode, pois se o
acidente for com dois veculos, pode ser que um estava em excesso de velocidade, o motorista
alcoolizado, e o outro participante foi imprudente, pois entrou em uma via preferencial.
Logo, podemos ter outra entidade relacionada com a agregao, a entidade causas de
acidentes de trnsito. Est achando o nome muito grande? Isso no deve ser importante ao
modelar dados, o importante expressar a realidade.
Veja adiante a figura que apresenta mais uma entidade relacionada com a agregao.
Duas entidades relacionadas a uma agregao.
Lembre que os relacionamentos de muitos-para-muitos so representados por tabelas
associativas que fazem o mesmo papel do relacionamento.
Fica fcil a implementao de um aspecto conceitual na forma de tabelas relacionais,
porm de grande importncia no entendimento de uma realidade trabalharmos com este
recurso de agregao.

Recomendamos mais uma vez que os analistas procurem sempre modelar no nvel e
abstrao que o modelo conceitual, para somente aps entender e expressar a realidade,
para elaborar o modelo lgico e o modelo fsico.
As regras que lanamos para descobrir e utilizar agregaes servem como orientao
para que o leitor possa trabalhar os dados num nvel mais alto de abstrao, e facilitar o
direcionamento de sua viso e observao de um ambiente que est sendo modelado.
A regra nmero 1 apresenta a condio bsica para a existncia de uma agregao,
porm nada indica que sempre que houver um relacionamento de muitos-para-muitos haja
uma agregao.
Agregao enxergar um bloco de modelo que possui um relacionamento de muitos-
-para-muitos como uma entidade, relacionado com outras entidades, ou ento relacionado com
outro bloco de modelo, isto , com outra agregao.
Destacamos no livro que nunca existe agregao quando da existncia de relacionamen-

tos um-para-muitos. Nunca, no esquea!
Vamos agora apresentar uma situao de relacionamento um-para-muitos e discutir por

que nunca existe a aplicao do conceito de agregao para estes casos.
Uma situao tpica de vendas:

Vendedor emite pedido como na figura.
Este relacionamento tem a cardinalidade de um-para-muitos, ou seja, cada ocorrncia

de vendedor pode ter emitido vrios pedidos. Por seu lado uma ocorrncia de pedido foi
emitida por uma e somente uma ocorrncia de vendedor.
Vamos ento procurar se existem coisas associadas ao fato de vendedor emite pedido.

Supondo que afirmem que quando vendedor emite pedido implica em ter cliente.
At parece que estamos no mesmo

caminho.
Quem tem cliente?
Pedido ou vendedor.
S existe cliente quando vendedor
emite pedido?
No, a verdade que cliente uma informao, um atributo do pedido e no da relao

entre as duas entidades.
Na vida real se prestarmos bem ateno ao que acontece, veremos que as informaes
so de uma entidade, ou de outra, ou ainda caracterizam outra entidade que se relaciona com
uma das duas em anlise, mas no com o fato representado pelo relacionamento entre elas.
Vejamos na prxima figura a soluo correta.
Cliente, vendedor e pedido.

No mundo real um cliente faz um pedido a um vendedor, que o emite, ou melhor, que o
encaminha empresa.
Logo, temos as trs entidades como apresentadas no modelo da figura.
Lendo o modelo, vamos encontrar as mesmas afirmaes do mundo real.
Cliente faz pedido
Vendedor emite pedido
E a relao, ou melhor, relacionamento entre vendedor e cliente.
Vendedor atende cliente.

Cuidado com vendedor atende cliente, pois dependendo das regras de negcio da
empresa, isso no existir.
Se a regra de negcio for que os vendedores da empresa no tm exclusividade sobre
os clientes, isto , mais de um vendedor pode atender um mesmo cliente, este relacionamento
perde a sua razo de ser.
Neste caso somente atravs da entidade pedido podemos saber que vendedor atendeu
a um determinado cliente.
Esta soluo da figura parece ter dois relacionamentos redundantes, porm so dois
caminhos alternativos para pedido e cliente em relao a vendedor.
Agregao Reflexiva
Este um dos casos mais trabalhosos de visualizao de realidades.
Vamos colocar exemplos bem reais, assim como uma brincadeira simulada para que
voc possa gravar, mentalizar os caminhos de soluo.
Vamos iniciar este estudo com uma pequena brincadeira.
Suponha que em uma cidade, de poucos habitantes, resolvemos fazer um controle das
pessoas que namoram. Aquele negcio de ningum de ningum.

Temos a entidade pessoas da cidade na qual esto, por assim dizer, todos os habitan-
tes, seja do sexo masculino, feminino.
Considerando que uma ocorrncia do sexo masculino pode namorar com mais de uma
do sexo oposto, e que o caminho no sentido contrrio tambm verdadeiro, ou seja, uma
ocorrncia do sexo feminino tambm pode namorar com mais de uma do sexo oposto, logo
temos um relacionamento reflexivo de cardinalidade muitos-para-muitos.
Observe, mesmo rindo, que estamos lidando

com duas vises de dados da entidade pessoa. A
viso ocorrncias do sexo masculino e a viso
ocorrncias do sexo feminino. Temos dois subtipos
distintos neste caso.
Veja a figura que apresenta este relaciona-
mento, que possui dados, pois ali esto a data e a
hora e talvez at a indicao do local em que o fato
aconteceu.
Observe duas representaes grficas, uma

com o entendimento generalista e outra com vises
de dados (especializaes) colocadas como subtipos,
o que vai facilitar o entendimento da realidade.
Mas vamos seguir para obter o resultado de entendimento que buscamos, apesar de
ser possvel afirmar que no estamos realizando modelagem sexual.
Na referida pequena cidade, como normal neste Brasil afora, existem vrios motis,
muito frequentados.
Analisando o modelo obtido at este instante, podemos colocar a questo:
As pessoas quando namoram utilizam um motel?
Pelo que falam do movimento que eles tm, certamente utilizam.
Bem, a nossa entidade motel ento se relaciona com o qu?
A questo que colocamos tem como resposta:
Motel se relaciona com a agregao resultante do relacionamento entre duas vises de
dados da entidade pessoas.
Observe o resultado no diagrama Entidade-Relacionamento.

Pessoas e motel.
Lendo o modelo, temos:
Pessoas do sexo masculino namoram com vrias pessoas do sexo feminino, e pessoas
do sexo feminino igualmente namoram com vrias pessoas do sexo masculino. Continuando.
Quando pessoas namoram com pessoas utilizam um motel.
Este relacionamento, da agregao namora com motel, de muitos-para-um, pois uma
relao s pode ocorrer cada vez em um lugar.
Certamente este exemplo no sair mais da sua memria, pois quando ele apresen-
tado, o resultado de fixao muito alto.
O resultado bom para entender, isto !
Um aluno absorveu bem este modelo de dados, inclusive incrementou o seu resultado,
com a insero da entidade marcas de camisinha, pois segundo ele, quando algum namora
com algum, ainda mais nestes tempos de AIDS, sempre deve usar camisinha de alguma
marca e at cor. Concordamos que esta entidade poderia existir, pois teria fins estatsticos.
Este modelo retrata mesmo uma realidade. O problema , se implementado, como se
obteriam os dados para os relacionamentos se efetuarem? Difcil, no acha?
Vamos agora para um exemplo muito utilizado em ambiente industrial, a questo dos
produtos compostos e produtos componentes.
A figura apresenta o modelo de relacionamento reflexivo que vamos estudar e agregar.

Produto Composto e Componente
Em uma entidade produto suas ocorrncias
so compostas de produtos completos e compo-
nentes.
Um produto acabado composto de vrios
componentes.
Um determinado componente participa da
composio de vrios produtos acabados.
Esses fatos esto retratados no modelo de
dados da figura ao lado na forma de subtipos com
um relacionamento muitos-para-muitos entre eles.
Este relacionamento possui os dados de quantidade de cada componente na compo-

sio do produto acabado, conforme destacamos na figura anterior.
Produto
Cdigo Produto Descrio

3758 Parafuso
8596 Rosca
4512 Arruela
5532 Bloco
7626 Carburador
Composto - Compe
Cdigo Composto Cdigo Componente Quantidade Componente

5532 3758 10
5532 4512 22
5532 8596 14
7626 3758 65
7626 4512 70

Quando h uma ordem de produo para produzir uma quantidade determinada de um
produto acabado, essa ordem provoca a retirada, dos estoques da empresa, das quantidades
necessrias de cada componente.
Essa retirada realizada para atender uma ordem de produo, que produz somente
um item acabado, o qual tem componentes.
Essa retirada, ou melhor, requisio de componentes visualizada pelo relacionamento
entre ordem de produo e uma agregao que o relacionamento entre o subtipo produto
acabado e produto componente, o relacionamento compe/ composto, conforme apresen-
tamos no diagrama ER.
Desta forma, permite-se que se associe a quantidade necessria de cada produto
componente para ser utilizada em uma ordem de produo determinada.
Vamos inserir a demonstrao das tabelas que representariam com dados este
relacionamento utiliza e a ordem de produo para um melhor entendimento.
Ordem de Produo
NumOrdProd ProdutoOrdem Qtde Data Ordem

200152 5532 2 20/2/2004
200155 7626 2 21/3/2004

Utiliza / utilizado
NumOrdProd ProdutoOrdem Componente Qtde Requisitada

200152 5532 3758 20
200152 5532 4512 44
200152 5532 8596 28
200155 7626 3758 130
200155 7626 4512 140
A tabela que representa o relacionamento entre ordem de produo e a agregao

possui como chave estrangeira a concatenao das colunas ProdutoOrdem que o produto
composto a ser fabricado e a coluna Componente que o produto componente que participa
desse produto a ser fabricado.
Voltando ao caso que estvamos estudando no modelo ER, de cinemas e filmes, vamos
concluir o contexto, inserindo uma assertiva que no colocamos para poder utilizar os recursos
de agregao.
Uma Distribuidora de Filmes - O Retorno

Vamos considerar agora adicionalmente que desejamos controlar o pblico que assiste
aos filmes exibidos nos cinemas.
Queremos saber por horrio de sesso, se na sesso das 14 horas, ou das 22 horas,
por exemplo, e as datas em que ocorreu maior pblico.
Entrou um objeto neste contexto que no existia anteriormente: a sesso de cinema.
Se lhe perguntarem quando voc foi ao cinema pela ltima vez, voc certamente
responder que foi talvez ao cinema A, passando o filme B, no dia tal, na sesso das X horas.
Bem, olhando por cima, j sabemos que sesso tem informao sobre dia e horrio,
alm de indicar um filme e um cinema.
Ou seja, existe um objeto sesso, s que devemos considerar que no um objeto com
existncia independente, pois no existe sesso sem filme e tampouco sesso sem cinema.
Logo, sesso somente existe quando cinema exibe filme.
A expresso, quando aqui colocada, resulta que temos uma aplicao de agregao
entre uma entidade sesso e o conjunto, bloco de modelo cinema passa filme, que j havamos
modelado.
Vamos ento ver como fica o modelo de dados agora.
Antes vamos colocar mais uma questo: as pessoas so identificadas e registradas
quando entram para assistir a uma sesso de cinema? claro que no, logo nossa sesso de

cinema deve ter um atributo para que seja possvel identificar o pblico no sentido de
quantidade de pessoas que assistiram a um filme em exibio em um cinema.
Uma sesso de cinema tem um cinema e um filme, ou seja, sua conectividade em

relao ao bloco agregado um. E um cinema exibe filme tem muitas sesses, logo a
conectividade neste sentido muitos.
Concluso
O nosso objetivo neste captulo foi apresentar uma viso mais ampla da tcnica de
modelagem de dados, ampla no sentido de retratar com fidelidade as situaes do mundo real.
Agregao no considerada por ns somente uma tcnica a mais, porm uma
abstrao que utilizamos no dia a dia sem perceber que estamos modelando alguma coisa.
O raciocnio do homem normalmente binrio. Observamos e lemos todas as nossas
realidades aos pares de coisas.
E quando uma terceira ou quarta coisa entra no meio, utilizamos sempre a expresso
quando.
Mas dificilmente voc interpreta ou l algo com mais de duas coisas ao mesmo tempo.
No Velho Oeste os pistoleiros conseguiam sempre atirar com duas armas, mas nunca
atiravam num determinado instante com mais de duas. Isso faz parte da polaridade binria do
sistema nervoso do ser humano.
Neste ponto do livro podemos apresentar exerccios mais complexos, pois conside-
ramos que voc adquiriu conhecimentos sobre o modelo ER, inclusive com todas as suas
extenses propostas, o que permite a construo de qualquer modelo necessrio como os que
vamos apresentar.

7
TRATAMENTO DE
INTERPRETAES DE DADOS
Pontos de Vista Diferentes

A interpretao da realidade difere muito de uma pessoa para outra. Mesmo estando no
mesmo lugar e assistindo a um mesmo fato, pessoas diferentes, de ambientes diferentes,
podem interpretar e denominar fatos e coisas de forma desigual, alm de relacionarem essas
coisas com outras completamente diversas.
O desenho ao lado apresenta um cometa, mas que pode ser

uma estrela cadente para outras pessoas.
Assim como algumas relacionam este objeto com o fim do
mundo, outras relacionam com seres extraterrestres.
Os modelos de dados devem sempre refletir a interpretao que pessoas de uma

organizao tm de coisas que significam algo para elas. Quando estamos modelando, muito
comum encontrarmos muitas interpretaes diferentes em departamentos da empresa sobre a
mesma coisa.
Por outro lado, em funo de as ferramentas existentes para modelagem de dados no
implementarem essas interpretaes, assim como a existncia de direcionamento para o
modelo fsico, leva o analista a pensar imediatamente em SQL e seus recursos para trata-
mento de interpretaes de uma entidade.
Cria-se ento uma distncia enorme entre o modelo fsico, que um

esquema de tabelas e colunas, e o modelo conceitual, que vai ser apresentado
aos usurios, o qual a representao de um ambiente real, externo ao SGBD.
O que buscamos uma ateno maior questo da representao e
modelagem das interpretaes de dados que existem, no s em departa-
mentos de uma empresa, como os diversos fatos que esto relacionados com
interpretaes de uma determinada coisa em uma empresa.
Tratamento de Interpretaes de Dados 159

Lembre-se de que muitas vezes o no tratamento e modelagem dessas interpretaes
dentro de um modelo nos levam a no definir relacionamentos entre entidades, uma vez
existindo relacionamentos especficos de uma interpretao de dados com outra entidade, ou
com outra interpretao. Este problema faz com que fatos do ambiente sejam retratados de
maneira confusa, gerando no futuro divergncias entre a realidade da empresa e o que o
sistema retrata com falta de informaes.
A figura seguinte apresenta uma situao de interpretaes de dados simples, em que
temos a entidade produto e que possui os mais variados tipos de interpretao dentro de uma
empresa. Como tratar isso?
Toda empresa, seja comercial, industrial ou de servios, tem essa coisa chamada
produto, porm as interpretaes em cada negcio so em maior ou em menor nmero, mas
podemos afirmar que sempre existir um conjunto de interpretaes idntico.
Devemos resolver o problema dando ateno e explorando mais acentuadamente as
possibilidades de interpretaes dentro de uma entidade.
No nosso exemplo, temos ainda o fato de usurios diferentes utilizarem nomenclaturas
diferentes para suas coisas. Por exemplo, materiais de consumo e no produtos de consumo.
Muitas vezes esta coisa chamada produto provoca erros graves de modelagem, ou
modelos no otimizados, pois coisas iguais so modeladas separadamente.
Produto acabado e matria-prima.
Ora, os dois no so coisas iguais, por que possuem tratamento diferente?
Ou qual a diferena entre produto acabado e item de patrimnio? So coisas distintas
dentro de um negcio, apesar de um produto fornecido por algum ser um item imobilizado, um
bem patrimonial.

A figura ilustra este problema, principalmente em empresas do segmento industrial.
Podemos ter um produto acabado que, mudando de rea de negcio, um bem do patrimnio.
Se produzirmos poltronas, ou computadores, quando um produto destes est no estoque, um
produto acabado; quando utilizamos um desses produtos na empresa, ele passa a ser um bem
imobilizado.
Veja bem que no estamos falando de processos, mas em anlise de dados, de
entendimento do papel dos objetos no mundo de negcios.
Vamos apresentar conceitos sobre esses conflitos de nomes e entendimento da semn-
tica dos objetos no mundo real.
Existem duas fontes de conflito de nomes em um ambiente real em anlise: sinnimos e
antnimos.
Sinnimo quando um mesmo objeto de um ambiente representado por nomes diferentes,

mesmo sendo o mesmo objeto.
Sinnimo indica o mesmo objeto com nomes diferentes.
Antnimo quando objetos diferentes so representados pelo mesmo nome no ambiente.
Antnimo, mesmo nome, coisas diferentes.

Devemos estar atentos ao executarmos um modelo de dados para conseguir obter
clareza no entendimento dessas similaridades de conceitos do usurio que nos fornece
informaes.
Os dois modelos de conceitos da figura seguinte apresentam os mesmos objetos com
foco de entendimento de negcio diferenciado, e inclusive com conceitos diferentes em relao
aos objetos que compem o ambiente de negcios. Isso no impede que seja realizada uma
unificao de conceitos. Porm, destaca-se a necessidade de utilizarmos o que denominamos
de renomear os conceitos, removendo as ambiguidades do modelo causadas por sinnimos, e
nos casos de antnimos apresentar sempre uma segunda interpretao com os objetos
renomeados.

Esta anlise de similaridade deve ser realizada principalmente quando conceitos com
nomes diferentes possuem as mesmas propriedades, o que permitir definirmos objetos nicos
ou diferentes.
Devemos estar atentos aos conceitos com mesmo nome e que possuam propriedades e
restries diferentes. Lembrando que restries para ns querem dizer regras e condies que
restringem os conjuntos de valores vlidos para o objeto.
A prtica tem mostrado que exemplos mais simples podem ser mais fceis de
visualizar, porm devemos nos orientar para apresentar os objetos e conceitos que existem no
ambiente do usurio e da forma mais prxima possvel de seu vocabulrio e conceitos.
Devemos buscar uma forma de apresentar, integrar e valorizar essas vises de dados
para possibilitar que os modelos sejam realmente legveis, no somente por um grupo de
usurios de um futuro sistema, mas por todos os envolvidos na utilizao desse sistema.
Relacionamentos entre Interpretaes

No modelo de dados importante tratar os relacionamentos que essas interpretaes
tm entre si e com outras entidades.
Vamos iniciar pelos casos de relacionamentos entre interpretaes de uma entidade.
Observe a figura em que apresentamos o relacionamento entre interpretaes de produto.

Na entidade produto temos as seguintes interpretaes: material de consumo, produtos
acabados, produtos semiacabados, componentes de fabricao, matrias-primas e material de
marketing. Temos ainda as subinterpretaes de produtos semiacabados: peas de plstico e
peas de vidro.
Peas de vidro uma interpretao de um determinado grupo de pessoas dentro da
empresa, do departamento de engenharia, e que possui forma de classificao e visualizao
de coisas totalmente diferente da administrao, por exemplo.
Da mesma forma existem as interpretaes de operao. Dois tipos de operao so
considerados, as operaes normais e as de risco, uma qualificao para diferenciar as
operaes em uma fbrica hipottica.
No nosso exemplo, peas de vidro se relacionam com as interpretaes de operaes
denominadas de operaes de risco.
Por exemplo, produto de consumo, que no aparece na figura, poderia relacionar-se

com o qu?
Com nenhuma das interpretaes apresentadas, porm, pode existir relacionamento
entre produtos acabados e produtos semiacabados?
Sim, pois um produto acabado considerando-se que nossa empresa modelo fabrica, por
exemplo, garrafas trmicas, possuiria em sua composio produtos semiacabados.

So produzidos diversos produtos em uma linha de montagem os quais vo formar uma
garrafa trmica.
Logo, a figura seguinte apresenta o relacionamento entre as duas interpretaes.
Um relacionamento de muitos-para-muitos, que colocamos conceitualmente com dados,
contm a informao de quem o componente e quem ele compe, ou seja, qual o produto
final de cuja composio ele participa.
Aprofundando a anlise, qual ser a jogada com matria-prima?

Produto acabado no est relacionado com matria-prima?
Neste exemplo vamos inicialmente considerar que matria-prima est sendo utilizada
para produzir os componentes de um produto acabado.
Logo, teramos um relacionamento entre as interpretaes produto semiacabado e
matria-prima da mesma forma que temos entre produto acabado e produto semiacabado.
Mas estes dois relacionamentos so os mesmos?
Evidente que so.
Na realidade existe um nico grande relacionamento que produto compe produto, e
que pode ser visto em grupos separados, porm estruturalmente o mesmo relacionamento.
O que temos na realidade uma hierarquia embutida na entidade produto.

Tratamento de Subinterpretaes
Mas poderamos agora nos perguntar: e a interpretao peas de vidro no faz parte de
uma garrafa trmica? (a parte interna, o bojo da garrafa). Como relacion-la?
O importante entendermos que nem todas as interpretaes esto no mesmo nvel
hierrquico. Podemos ter interpretaes dentro de outra interpretao.
Neste caso peas de vidro uma interpretao dentro da interpretao produto
semiacabado. Observando a realidade em questo, seu relacionamento se d com a interpre-
tao produto acabado, conforme apresentamos, porm nada mais que um segundo grau de
especializao do modelo em questo.
Veja a figura em que vamos simplificar o modelo e apresentar uma existncia dessa
subinterpretao, alm de, claro, apresentar um relacionamento reflexivo geral denominado
Compe entre Produto e o prprio Produto (reflexivo). Esta uma linguagem que o departa-
mento de engenharia e seus profissionais entendem.
Para que o modelo no tenha sua legibilidade prejudicada, devemos desenhar as
interpretaes com os relacionamentos especficos de cada uma, mas sem perder a
apresentao dos relacionamentos que no so exclusivos de uma interpretao.

Necessariamente uma interpretao, ou melhor, subinterpretao de dados, no precisa
ser apresentada atravs de um relacionamento com a entidade na qual ela est inserida. Ou
seja, no h necessidade de perdermos tempo em relacionar, por exemplo, peas de vidro
com produto acabado.
O modelo no perde seu entendimento por no ser inserido um relacionamento
especfico para cada subinterpretao.
O mais importante que peas de vidro tm este destaque como uma subinterpretao
de produtos semiacabados atravs do entendimento da rea de engenharia. Entretanto,
tambm h relacionamentos com outros objetos do modelo, e que so especficos dessa
subinterpretao, pois nem todas as ocorrncias da interpretao denominada de produtos
semiacabados se relacionam com a interpretao denominada de operaes de risco.
Quando apresentada uma interpretao ou uma subinterpretao de dados, devemos
observar que ela existe porque possui algum tipo de tratamento significativo no negcio.
Isso quer dizer que quando uma coisa tem sua existncia afirmada, ela est relacionada
de forma peculiar com as outras coisas significativas do negcio.
Mas todos sero unnimes em afirmar que as ferramentas de modelagem no permitem
representar essas interpretaes de forma ampla e ainda com subinterpretao.

A maioria dos cursos de modelagem de dados no apresenta corretamente a questo
da subinterpretao, o que provoca que a maioria dos analistas no explore em seus modelos
de dados esse recurso.
Muitos so os casos que analisamos em que no foi tratada a subinterpretao, ficando
o modelo sem retratar a realidade, e o que mais grave, quando da modelagem dos eventos
cria-se uma confuso, pois os eventos esto suportados exatamente pela subinterpretao.
Perde-se o que de mais importante existe para um modelo de dados, a sua expressividade do
mundo real.
Quando da modelagem de algum objeto, coisa significativa de uma empresa, gostamos
de explorar as possibilidades de classificao desse objeto, pois isso leva a identificar subtipos
e suas divises existentes, assim como as hierarquias que podem existir na relao entre os
conceitos levantados.
Vamos ento explorar mais alguns casos normais que encontrarmos de identificao de
interpretao de dados.
A implementao de vises mesmo em SQL pouco utilizada na implementao do
esquema fsico do banco de dados por provocar problemas de performance, mas ainda no
concordamos que performance seja o fator fundamental em hiptese nenhuma no momento de
modelarmos.
Se sua aplicao tratar seus programas atravs das vises de dados, porque voc as
definiu, logo no se preocupe com a forma de implementao no momento da modelagem.
Siga o princpio bsico de um bom modelista de dados. No pense em processos enquanto
modela; retrate a realidade das coisas de uma empresa.
Mais Interpretao
A maioria das literaturas do mercado somente explora interpretao ou subtipos e
supertipos dentro de um exemplo comum e simples de um primeiro entendimento, a entidade
pessoas.
No vamos fugir deste exemplo, mas vamos procurar explor-lo mais profundamente,
considerando no o conceito puro de subtipo, porm o conceito amplo de especializao, que
nada mais que a tcnica de representao das interpretaes.
Existe um ponto em que a representao de uma interpretao fica mais complexa em
funo de que as ferramentas de modelagem so dirigidas a ambiente relacional, e as
interpretaes resultantes de uma entidade e um relacionamento necessitem de vrios nveis
de hierarquia.
Como no existe implementao desse tipo de interpretao em SGBDs relacionais,
muitas vezes ela provoca a insero de flags muito estranhos em domnio dentro dos modelos
de dados, gerando resultados ambguos e de pouco controle.
Seja como na figura a entidade pessoas e entidade contratos de venda.

Qualquer pessoa existente na entidade pessoa pode efetuar uma venda de um contrato,
assim como pode ser cliente de um contrato de venda.
Num Contrato ........ ........ ........ Vendedor Cliente

45 12 45
85 11 74
32 84 56
21 101 94
Identificao ........ ........ ........ Nome

12 Ado
11 Joo
45 Cludia
74 Pedro
84 Srgio
101 Ivan
56 Maurcio
94 Jos
O relacionamento existe entre pessoas e contratos, porm a interpretao vendedor

derivada exclusivamente do relacionamento entre as duas entidades. No uma interpretao
exclusiva e caracterizada por um grupamento especfico que possua um identificador de
categoria, mas uma interpretao resultante somente da existncia de um relacionamento, em
que ocorrncias desta entidade possuem um papel denominado de vendedor.
Uma pessoa pertence interpretao vendedor somente quando tiver realizado uma
venda, ou seja, quando existir uma ocorrncia de contrato de venda que indique aquela pessoa
como o vendedor.
Observe as tabelas demonstrativas para um melhor entendimento.

No contrato de nmero 32, o vendedor a ocorrncia de pessoa com identificao 84
(Srgio) e o cliente a ocorrncia de pessoa com identificao 56 (Mauricio).
Como apresentar este modelo, como apresentar a interpretao vendedor se no
simplesmente um subtipo, uma especializao?
Infelizmente as ferramentas de modelagem no permitem que se criem alias ou roles de
entidades para permitir essa representao, porm o nosso desenho, o nosso diagrama ER,
deve apresentar um submodelo (subject area) em que existir um subtipo com os mesmos
atributos da entidade funcionrio, e sem que exista nenhum atributo identificando o papel
vendedor, podendo, isto sim, apresentar que existe o papel por meio de uma clusula no
modelo, especificando-o:
Pessoa vendedor, quando em contrato de venda a identificao do vendedor for igual

identificao de pessoa.
Vamos ampliar o problema de interpretao, ampliando o universo da entidade
pessoas, em funo do tratamento e da forma como so considerados os clientes de uma
empresa.
Se considerarmos que os clientes em um primeiro momento so pessoas fsicas e no
empresas, a entidade possui dados de pessoas.
Logo, pessoa uma entidade generalizadora que possui ocorrncias de clientes, funcio-
nrios e vendedores por assim dizer.
Num diagrama de mais alto nvel h, como na figura apresentada, dois relacionamentos
entre contrato e pessoas. O relacionamento compra e o relacionamento vende.

Pessoas esto relacionadas com contratos pelo fato de serem vendedores de
ocorrncias de contratos, e por outro lado tambm existe outro relacionamento que pessoas
que so clientes de um contrato.
Sem que se abra no diagrama a representao das vises resultantes e condicionadas
existncia do relacionamento, nosso modelo poderia suscitar perguntas como: mas algum
pode ser vendedor e cliente de um mesmo contrato?
No momento em que apresentamos as interpretaes e os relacionamentos com cada
uma delas, estamos com um resultado de interpretao da realidade que no ser questio-
nado, pois estamos qualificando e destacando os papis, perfeitamente como no mundo real.
Este ltimo diagrama apresentado tem um nvel semntico de maior grau, permitindo
desta forma seu entendimento e representatividade do mundo real de melhor qualidade.
Quando retratamos em um modelo de dados um ambiente de negcios, no devemos
poupar a insero de interpretaes, pois elas so fundamentais ao entendimento desse
ambiente.
A utilizao de generalizao e especializao em modelos de dados um dos artifcios
da tcnica de maior poder de expresso. Infelizmente, voltamos a salientar, pouco explorado
e utilizado pelos analistas de sistemas.
Vamos avanar as interpretaes de dados.
Explorar potenciais interpretaes pode tornar uma ferramenta muito til no domnio de
negcios, quando de sua modelagem.
Vamos discutir um enfoque de interpretao de dados muito comum na maioria dos
sistemas corporativos existentes hoje, a questo cliente e fornecedor para comearmos.
Em uma organizao, cliente ocorrncia de alguma coisa que mantm relao de

compra de produtos ou servios.
Fornecedor a ocorrncia de alguma coisa de quem a organizao adquire bens ou
servios por assim dizer.
A questo que sempre colocada que uma ocorrncia de cliente pode ser em
determinado momento uma ocorrncia de fornecedor e vice-versa.
O que impede de que, quem me fornea servios, tambm compre meus produtos e
seja meu cliente? Nada!
Logo, a existncia de venda ou de compra que determina a interpretao de dados, e
no existe neste caso a caracterizao especfica da entidade cliente e da entidade fornecedor.
No se trata de querer otimizar redundncias!

Somente estamos analisando que existe uma entidade ainda sem nomenclatura, que
engloba ocorrncias de clientes e de fornecedores.
A maioria dos analistas tem o mau costume de dar o nome de CliFor a essa entidade.
Uhrg! Que coisa horrorosa!
Nada diz nada este nome de significativo, pois continua limitado.
Observe a prxima figura e veja que o conceito de cada interpretao dependente do
relacionamento que cada uma possui.
Qual nomenclatura daramos a essa entidade?
Vamos continuar a explorar as possveis interpretaes ou descobrir coisas significan-

tes no ambiente em anlise.
Quando estamos tratando com compras de produtos, ou com venda, temos um elemen-
to que se denomina normalmente de transporte de mercadorias. Logo, temos quem transporta,
os transportadores.
Mas transportador no fornecedor?

Sim, fornecedor de servios.
Da mesma forma que a oficina do Zezinho na esquina, em que ns pagamos e temos a
comprovao com recibos!
Ento temos na mesma entidade mais uma ou duas interpretaes, ou melhor, temos
uma nova interpretao e subinterpretaes e assim por diante.
A figura seguinte mostra o nvel de especializao a que chegamos somente com esta
rpida anlise.
Mas os clientes podem ser pessoas fsicas e pessoas jurdicas.
Complicou mais, porque existem tratamentos diferentes na rea comercial.

As vendas a pessoas fsicas so realizadas por departamento especfico da empresa,
que vende, por exemplo, a varejo, separadamente das vendas realizadas a pessoas jurdicas,
as empresas, as quais compram por atacado (grandes quantidades).
Logo, a interpretao clientes possui suas especializaes, suas subinterpretaes.
Devemos considerar que estamos realizando a determinao ainda macro de entidades
e interpretaes, pois no demonstramos at este instante nenhum atributo especfico de cada
entidade ou interpretao de dados.

Modelo com Cliente Pessoas Jurdicas e Pessoas Fsicas
Neste diagrama somente inserimos a classificao de entidade subtipo para pessoa

fsica e pessoa jurdica.
O relacionamento compra no foi afetado, pois a realidade continua a mesma, somente
temos uma classificao diferenciada para clientes.
A anlise das tipologias de um objeto pouco explorada inclusive nas tcnicas orien-
tadas a objetos, considerando-se que, dentro dos conceitos de mensagem, essas mensagens
so especficas de cada tipo de interpretao.
Vamos ler o modelo apresentado e interpret-lo.
Antes acreditamos que j possvel revelar o nome desta entidade generalizadora:
entidade pessoa.
Ento, pessoa pode ser Pessoa Fsica ou Pessoa Jurdica.
Fornecedor uma especializao que absorve tanto pessoa fsica quanto jurdica. Da
mesma forma cliente absorve tanto pessoa fsica quanto jurdica.
importante que se faa um diagrama de estrutura inicial com a rvore de vises que
oriente na forma hierrquica em que elas esto inseridas.

Porque a interpretao de subinterpretaes somente possvel se entendermos a sua
relao de encapsulamento com a entidade bsica do modelo. A figura exibe este diagrama de
forma simples, somente estruturando essa hierarquia.
Diagrama Hierrquico de Interpretaes

O modelo de dados que vai representar esta situao est no modelo ER a seguir, em
que simulamos de forma macro os relacionamentos que criam as interpretaes de cliente,
fornecedor e transportador. Os subtipos de cada uma dessas interpretaes so as suas
especializaes atravs de caractersticas de atributos que indicam se organizao fsica ou
jurdica.
Vamos apresentar uma leitura simples deste modelo para que voc compreenda a
realidade que estamos apresentando:
Uma ocorrncia de pessoa cliente quando se relaciona com pedido de venda,
podendo ser jurdica se o atributo do tipo da organizao for, por exemplo, "J".
Uma ocorrncia de pessoa fornecedor quando se relaciona com nota fiscal de
entrada.
Expandindo o modelo em grau de especializao, podemos ter o resultado da figura
apresentada em seguida.
As nossas notas fiscais de entrada poderiam tambm ser controladas ou identificadas
como dois tipos: notas fiscais de transporte ou notas fiscais de entrada de produtos.
Logo, podemos ter que uma ocorrncia do subtipo fornecedor pertencente interpre-
tao transportador quando est relacionada com a interpretao notas fiscais de transporte.

A amplitude do nmero de interpretaes inerente s formas de tratamento da
informao nos diversos departamentos de uma empresa.
Nosso modelo, ou melhor, o diagrama ER deve representar sempre que possvel essas
interpretaes, pois elas so esclarecedoras do ambiente que est sendo modelado.
Poderamos ainda apresentar um modelo com o desdobramento mais detalhado de
fornecedor, inserindo um subtipo como fornecedor de produtos para deixar completa a clas-
sificao da coisa fornecedor.
Concluso
Interpretaes de dados so estratgicas em um modelo de dados.
A no prospeco das interpretaes durante os levan-
tamentos para obteno e no refinamento de um modelo de dados,
ou simplesmente a aplicao dos conceitos de generalizao no
enfocando acentuadamente as interpretaes de dados, por con-
ceitos de SQL, ou de implementao fsica de bancos de dados,
seguramente vai conduzir construo de modelo de dados falho e
incompleto.

Alm disso, no vai permitir ganhos de produtividade na anlise de eventos do sistema,
pois se voc no tem todas as classificaes de um conceito, tambm no ter a absoro e
entendimento completo dos eventos que so especficos de cada uma dessas classificaes.
A seguir esto algumas questes que, se respondidas, podem ajudar a descobrir inter-
pretaes e subinterpretaes de dados nos trabalhos de modelagem de dados.
1. Que fatos esto relacionados com somente algum subconjunto de ocorrncias e uma
entidade?
2. Que interpretao de dados no modelo se relaciona com um subconjunto da entidade que
estamos analisando?
3. Existe algum fato que se relacione com somente parte de um subconjunto de dados?
4. Pessoas diferentes e de departamentos diversos se referenciam a uma coisa com nomes
diferentes?
5. Coisas de nomes diferentes no so subconjuntos de uma nica coisa?
Cuidado, Abra o Olho!

Coisas de nomes iguais podem ser totalmente dife-
rentes e caracterizarem duas entidades, assim como desta-
camos que coisas de nomes diferentes podem representar o
mesmo conceito. Nesse momento devemos parar e observar
os atributos que descrevem esses objetos.
Desta forma podemos entender dois objetos que no so interpretaes, mas duas
entidades diferentes em nosso modelo, ou entender a existncia de classificaes em mltiplos
nveis em um modelo de dados Entidade-Relacionamento.

8
NORMALIZAO
Conceituao
O objetivo da normalizao evitar os problemas que podem provocar falhas no projeto
do banco de dados, bem como eliminar a mistura de assuntos e as correspondentes redun-
dncias desnecessrias de dados.
Uma regra que devemos observar quando do projeto de um banco de dados orientado
para o modelo relacional no misturar assuntos em uma mesma tabela.
O processo de normalizao aplica uma srie de regras sobre as tabelas de um banco
de dados, para verificar se esto corretamente projetadas. Embora exista um conjunto de cinco
formas normais (ou regras de normalizao), na prtica usamos desse conjunto efetivamente
trs formas normais.
As tabelas de um banco de dados relacional so derivadas de um modelo Entidade-
-Relacionamento, e muitas vezes nessa derivao temos muitos problemas de performance,
integridade e manuteno de dados.
Normalmente aps a aplicao das formas normais, algumas tabelas acabam sendo
divididas em duas ou mais tabelas, o que no final gera um nmero maior de tabelas do que o
originalmente existente.
Esse processo causa a simplificao dos atributos de uma tabela, colaborando significa-
tivamente para a estabilidade do modelo de dados, reduzindo consideravelmente as neces-
sidades de manuteno.
Neste captulo vamos entender o processo de normalizao na prtica por meio de
exemplos e estudos de caso para a sua aplicao.
Por exemplo, a tabela que apresentamos em seguida traz os dados produtos, vende-
dores, clientes e pedidos de venda.
Observe na tabela que as informaes de produto e cliente esto armazenadas de
forma redundante, desperdiando espao.
Normalizao 177
Pedido Endereo Limite de
Nome Produto Nome Cliente Data Nome Vendedor
Nmero Cliente Crdito
Limpadora a Vcuo 1458 Davi Bachmamm Rio de Janeiro US$ 5,000 05/05/00 Carlos Book
Computador 2730 Helena Daudt Vancouver US$ 2,000 05/06/00 Joo Hans
Refrigerador 2461 Jos Stolaruck Chicago US$ 2,500 07/03/00 Silvio Pherguns
Televiso 456 Pedro Albuquerque So Paulo US$ 4,500 09/05/00 Frederico Raposo
Rdio 1986 Carlos Antonelli Porto Alegre US$ 2,000 18/09/00 Rui Ments
CD Player 1815 Davi Bachmamm Rio de Janeiro US$ 5,000 18/04/00 Silvio Pherguns
Limpadora a vcuo 1963 C.V. Ravishandar Bombaim US$ 7,000 03/01/00 Carlos Book
Limpadora a vcuo 1855 Carlos Antonelli Porto Alegre US$ 2,000 13/05/00 Joo Hans
Refrigerador 1943 Davi Bachmamm Rio de Janeiro US$ 5,000 19/06/00 Silvio Pherguns
CD Player 2315 Davi Bachmamm Rio de Janeiro US$ 5,000 15/07/00 Joo Hans
Para uma seleo do tipo: quais os clientes que tm pedido de limpadora a vcuo no
ltimo ms, preciso fazer uma pesquisa em toda a tabela, comparando linha a linha a coluna
produto, para encontrar as linhas em que essa coluna tenha valor de limpadora a vcuo.
Por outro lado, uma atualizao do endereo de um cliente da mesma forma exige que
se faa a consulta de todas as linhas em que o nome do cliente seja igual ao desejado e se
realize a alterao nessas linhas. Da mesma forma a deleo do nico pedido da cliente
Helena vai apagar a nica cpia de seus dados de endereo e limite de crdito.
Estes fatos so considerados anomalias de incluso, alterao e deleo de dados.
Ento podemos definir que normalizao consiste em definir o formato lgico adequado
para as estruturas de dados das tabelas de um banco de dados relacional, identificadas no
projeto lgico do sistema, com objetivo de minimizar o espao utilizado pelos dados e garantir
a integridade e confiabilidade das informaes.
A normalizao feita pela anlise dos dados que compem as estruturas utilizando o
conceito chamado formas normais (FN).
As formas normais so conjuntos de restries as quais os dados devem satisfazer.
Por exemplo, pode-se dizer que a estrutura est na primeira forma normal (1FN), se os
dados que a compem satisfizerem as restries definidas para esta etapa.
A normalizao completa dos dados feita seguindo as restries das cinco formas
normais existentes. A passagem de uma forma normal para outra feita tendo como base o
resultado obtido na etapa anterior, ou seja, na forma normal anterior.
Para realizar a normalizao dos dados, primordial que seja definido para a tabela
objeto da normalizao um campo de chave primria para a sua estrutura de dados, o qual
permite identificar os demais campos da estrutura.
O conceito de normalizao foi introduzido para o modelo relacional por Edgar F. Codd,
em 1970 (primeira forma normal). Essa tcnica baseada em um processo matemtico formal,
que tem seus fundamentos na teoria dos conjuntos.

Primeira Forma Normal (1FN)
Uma tabela de dados relacional, como a que apresentamos, no tem colunas repetidas,
pois cada coluna tem exatamente uma definio na tabela.
A tabela ento considerada na primeira forma normal. evidente que como este o
mais baixo nvel de normalizao, a tabela na primeira forma normal pode ainda conter outras
anomalias.
Definio de Primeira Forma Normal

Uma tabela est na primeira forma normal se e somente se todas as colunas possuem um
nico valor, e no existem grupos repetitivos (colunas) em uma linha ou atributos compostos.
Aplicar a primeira forma normal consiste em retirar da estrutura os elementos repeti-
tivos, ou seja, aqueles dados que podem compor uma estrutura do tipo vetor.
Nmero Cdigo do Nome do Endereo CNPJ do Data de Total Geral

da NF Cliente Cliente do Cliente Cliente Emisso da Nota
456123 1458 Davi Bachmamm Rio de Janeiro 60890837/0001-85 05/05/00 R$ 5.421,00
859632 2730 Helena Daudt Fortaleza 80890575/0001-70 05/06/00 R$ 6.612,00
859631 2461 Jos Stolaruck Macei 33016338/0002-71 07/03/00 R$ 1.820,00
745689 456 Pedro Albuquerque So Paulo 68596006/0001-07 09/05/00 R$ 453,00
745692 1986 Carlos Antonelli Porto Alegre 02930076/0002-22 18/09/00 R$ 184,00
745694 1963 C.V. Ravishandar Recife 60890837/0001-85 03/01/00 R$ 1.112,00
745695 1855 Carlos Antonelli Porto Alegre 02930076/0002-22 13/05/00 R$ 1.235,00
Cdigo do Descrio do Quantidade Valor Valor

Produto Produto de Produto Unitrio Total
45 Limpadora a Vcuo 1 R$ 600,00 R$ 600,00
25 Computador 1 R$ 1.800,00 R$ 1.800,00
32 Refrigerador 2 R$ 800,00 R$ 1.600,00
27 Televiso 3 R$ 950,00 R$ 2.850,00
... ... ... ... ....
32 Refrigerador 4 R$ 1.235,00 R$ 4.940,00
27 Televiso 2 R$ 4.150,00 R$ 8.300,00
25 Computador 4 R$ 2.225,00 R$ 8.900,00
Podemos afirmar que uma estrutura est normalizada na 1FN, se no tiver elementos
repetitivos. Acompanhe um exemplo.
Normalizao 179
Estrutura Original de Notas Fiscais de Venda de Mercadorias
{NUMERO DA NOTA FISCAL, SERIE, DATA EMISSO, CODIGO DO CLIENTE, NOME DO CLIENTE,
ENDEREO DO CLIENTE, CNPJ DO CLIENTE, RELACAO DOS PRODUTOS VENDIDOS (ONDE PARA CADA
PRODUTO TEMOS: CDIGO DO PRODUTO, DESCRIO DO PRODUTO, QUANTIDADE VENDIDA, PREO
UNITRIO DE VENDA E TOTAL DA VENDA DESTE PRODUTO) E TOTAL GERAL DA NOTA)}
J destacamos nesta estrutura de dados uma coluna para identificao nica, como
chave primria do nmero da nota fiscal.
Analisando a estrutura, observamos que existem vrios produtos em uma nica nota
fiscal, sendo, portanto, elementos repetitivos que devem ser retirados da estrutura.
Resultado da estrutura aps a aplicao da primeira forma normal (1FN):
Tabela de Notas Fiscais

{NUM. NF, SERIE, DATA EMISSAO, CODIGO DO CLIENTE, NOME DO CLIENTE, ENDERECO DO CLIENTE,
CNPJ DO CLIENTE E TOTAL GERAL DA NOTA}
Tabela de Item de Nota Fiscal

{NUM. NF, CODIGO DO PRODUTO, DESCRICAO DO PRODUTO, QUANTIDADE VENDIDA, PRECO DE VENDA E
TOTAL DA VENDA DESTE PRODUTO}
Observao: Os campos sublinhados identificam as chaves das estruturas.
Nmero Cdigo do Nome do Endereo do CNPJ do Data de Total Geral

da NF Cliente Cliente Cliente Cliente Emisso da Nota
859632 2730 Helena Daudt Fortaleza 80890575/0001-70 05/06/00 R$ 6.612,00
859631 2461 Jos Stolaruck Macei 33016338/0002-71 07/03/00 R$ 1.820,00
745689 456 Pedro Albuquerque So Paulo 68596006/0001-07 09/05/00 R$ 453,00
745692 1986 Carlos Antonelli Porto Alegre 02930076/0002-22 18/09/00 R$ 184,00
745694 1963 C.V. Ravishandar Recife 60890837/0001-85 03/01/00 R$ 1.112,00
745695 1855 Carlos Antonelli Porto Alegre 02930076/0002-22 13/05/00 R$ 1.235,00
Nmero Cdigo do Descrio do Quantidade Valor Valor

da NF Produto Produto do Produto Unitrio Total
456123 45 Limpadora a Vcuo 1 R$ 600,00 R$ 600,00
859632 25 Computador 1 R$ 1.800,00 R$ 1.800,00
859631 32 Refrigerador 2 R$ 800,00 R$ 1.600,00
745689 27 Televiso 3 R$ 950,00 R$ 2.850,00

Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas,
a saber:
Primeira estrutura (tabela de nota fiscal): dados que compem a estrutura
original, excluindo os elementos repetitivos.
Segunda estrutura (tabela de item de nota fiscal): dados que compem os
elementos repetitivos da estrutura original, tendo como chave o campo-chave da
estrutura original (Num. NF) o qual herdado por dependncia, e um campo-chave
da estrutura de repetio (Cdigo do Produto).
Vamos ver mais um exemplo de aplicao da primeira forma normal.
Utilizamos um documento que preenchido por uma suposta instituio bancria.
Ficha de Cliente
NomCliente
Endereo
Rua
Cidade
Bairro
Emprstimos
Agncia Nmero Emprstimo Valor
1 902230 500,00
4 902231 1500,00
3 902240 1200,00
Se visualizarmos agora como uma entidade e, consequentemente, uma tabela, ela teria
uma estrutura de dados como segue:
Cliente {NOMCLIENTE, RUA, CIDADE, BAIRRO, (AGENCIA1, NUMERO EMPRESTIMO1, VALOR1, AGNCIA1,
AGNCIA2, NUMERO EMPRESTIMO2, VALOR2,............... AGENCIAN, NUMERO EMPRESTIMON, VALORN)}
em que se observa que o conjunto de atributos AGENCIA, NMERO EMPRESTIMO1, VALOR repete-se
indefinidas vezes, ou seja, um conjunto de atributos multivalorados.
Definimos NOMCLIENTE como a chave primria que identifica o conjunto de informaes.
Entretanto, temos neste caso uma mistura de assuntos se colocarmos todos estes atributos em
uma mesma tabela, alm do aspecto de multivalorao.
Ou os dados so de clientes ou so de emprstimos dos clientes.
Aplicando a 1FN, obtm-se ento duas estruturas de dados ou tabelas que representam
a realidade do formulrio.
Normalizao 181
Os atributos repetitivos, ou multivalorados, passam a compor uma entidade, a qual
derivada da entidade principal que seria cliente, com seus dados sem repetio.
Teremos ento duas tabelas ou entidades neste caso:
Cliente {NOMCLIENTE, RUA, CIDADE, BAIRRO} e
EmprestimoCliente {NOMCLIENTE, AGENCIA, NUMEROEMPRESTIMO, VALOR}
Logo, de um formulrio obtivemos um pequeno modelo de dados.
Observe que a entidade que derivada no processo de normalizao atravs da

aplicao da primeira forma normal herda os atributos da chave primria da entidade, na qual
estavam anteriormente inseridos esses dados, ou seja, da qual essa entidade derivada.
No exemplo, herdou o atributo NOMCLIENTE e comps com o atributo mais significativo e
sem possibilidade de repetio de valor NUMERO EMPRESTIMO.
A primeira forma normal ento no permite a existncia de atributos multivalorados ou
compostos.
Uma relao est na primeira forma normal se possui apenas atributos com valores
atmicos (indivisveis).
Ficha de Emprstimo de Livros

ISBN
Nmero do exemplar
Ttulo do Livro
Histrico de Emprstimos
Data Prevista
Matrcula Nome Data Emprstimo Data Devoluo Assinatura
Devoluo
Vamos aplicar agora a primeira forma normal no exemplo de uma ficha de emprstimo
de livros em uma biblioteca.

Qual seria a estrutura inicial? Temos assuntos misturados em um nico objeto?
Temos ocorrncia de valores repetitivos?
Sim, temos informaes sobre o livro e seu emprstimo e os valores dos emprstimos
so repetidos indeterminadas vezes para cada livro.
Inicial
Ficha de Emprstimo= {ISBN, NUMERO DO EXEMPLAR, TITULO DO LIVRO, N VEZES (MATRICULA,
NOME, DATA EMPRESTIMO, DATA DEVOLUCAO, DATA PREVISTA DEVOLUCAO, ASSINATURA)}
Aplicando a primeira forma normal, extramos o conjunto de dados repetitivos para
compor uma segunda entidade ou tabela, considerando que herdaremos para a chave primria
dessa entidade a chave primria original da estrutura que ISBN, e acrescentamos um dado
que seja significativo como identificador para esse conjunto de repeties. Neste caso o dado
mais significativo seria a matrcula de quem retira o livro.
Logo, temos como resultado da aplicao da primeira forma normal neste exemplo duas
entidades:
Livro {ISBN, NUMERO DO EXEMPLAR, TITULO DO LIVRO} e Emprestimo {ISBN, MATRICULA, NOME,
DATA EMPRESTIMO, DATA DEVOLUCAO, DATA PREVISTA DEVOLUCAO, ASSINATURA}
No pergunte como ser o valor da informao assinatura, pois no o objeto deste
processo.
Para que seja correto o entendimento das formas normais seguintes, vamos apresentar
os conceitos de dependncia funcional entre dados.
Dados dois conjuntos de atributos A e B de uma entidade, diz-se que:
B funcionalmente dependente de A ou
A determina B ou
B depende de A
Vamos ver isto com um exemplo:
Matrcula Nome Sobrenome Departamento

1021 Joo Barros 900
1145 Pedro Silva 700
1689 Antonio Jardim 900
Departamento determina matrcula? Ou seja, matrcula depende de departamento?

No, pois departamento 900 est em 1021 e 1689.
Matrcula determina departamento?
Normalizao 183
Sim, pois se conhecer a matrcula, possvel saber o departamento, j um funcionrio
s tem um departamento.
Isso quer dizer que as informaes de uma entidade devem ser dependentes da
informao que a sua identificadora, sua chave primria.
Papelaria Artigo Preo

Colmeia Caneta Bic 2,50
Central Cola 1,50
Colmeia Borracha 1,00
Catedral Caneta Bic 2,00
Preo funcionalmente dependente de artigo?

No, pois o preo pode ser diferente em diferentes papelarias.
Preo dependente sim do conjunto papelaria e artigo.
Preo dependente de papelaria?
No, pois existem tantos valores de preos quantos os artigos vendidos na papelaria.
Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A
pertencente a ela dependente funcional de outro atributo B contido na mesma entidade, se a
cada valor de B existir nas linhas da entidade em que aparece, um nico valor de A. Em outras
palavras, A depende funcionalmente de B.
Existe uma dependncia funcional quando o valor de um dado ou dados determina os
valores de outros dados.
No exemplo:
Livro {ISBN, NUMERO DO EXEMPLAR, TITULO DO LIVRO}
O nmero do exemplar e o ttulo do livro dependem do ISBN, pois se mudarmos o valor
do ISBN, mudaro o nmero do exemplar e o ttulo do livro.
Vamos adiante com a aplicao da segunda forma normal que entenderemos melhor a
questo de dependncia funcional.
Segunda Forma Normal (2FN)

Consiste em retirar das estruturas de dados que possuem chaves compostas (chave
primria formada por mais de um campo) todos os dados que so funcionalmente dependentes
de somente alguma parte dessa chave.
Podemos afirmar que uma estrutura est na 2FN, se ela estiver na 1FN e no possuir
campos que sejam funcionalmente dependentes de parte da chave. Exemplo:

Estrutura na Primeira Forma Normal (1FN)
Tabela de Notas Fiscais = {NUMNF, SERIE, DATA EMISSO, CODIGO DO CLIENTE, NOME DO
CLIENTE, ENDERECO DO CLIENTE, CNPJ DO CLIENTE E TOTAL GERAL DA NOTA}
Tabela de Item de Nota Fiscal = {NUMNF, CODIGO DO PRODUTO, DESCRICAO DO PRODUTO,

QUANTIDADE VENDIDA, PRECO UNITARIO DE VENDA E TOTAL DA VENDA DESTE PRODUTO}
Observe que existe uma chave primria composta na tabela ITEM DE NOTA FISCAL.
Item de Nota Fiscal
Cdigo do Descrio Quantidade Valor Valor

NumNF
Produto do Produto de Produto Unitrio Total
456123 45 Limpadora a Vcuo 1 600,00 600,00
859032 25 Computador 1 1.800,00 1.800,00
859631 32 Refrigerador Brastemp 2 800,00 1.600,00
745689 27 Televiso LG 3 950,00 2.850,00
485689 45 Limpadora. a Vcuo 2 600,00 1.200,00
As perguntas que colocamos agora definem onde existe e onde no existe dependncia
funcional total da chave primria:
O valor de Descrio do produto depende de NUMNF, CODIGO DO PRODUTO?
Se considerarmos que em cada linha da tabela o produto pode ser descrito de forma
diferente, fica ainda mais grave a anomalia nesta tabela.
Mas a resposta no, pois em realidade a descrio do produto depende somente do
cdigo do produto. Ela varia pela mudana do valor do atributo CODIGO DO PRODUTO somente,
assim como valor unitrio varia de acordo com o valor de cdigo do produto. Logo, estes dois
atributos no possuem dependncia funcional total da chave primria.
O atributo valor total varia conforme varia o valor do conjunto NUMNF, CODIGO DO
PRODUTO.
Logo, esse atributo tem dependncia funcional total da chave primria, assim como o
atributo quantidade.
Uma tabela est na segunda forma normal (2FN) se ela estiver na 1FN e todo atributo
no chave plenamente dependente da chave primria.
A resoluo da aplicao da segunda forma normal realizada atravs da excluso dos
atributos que no dependem totalmente da chave primria, da tabela original, e constituindo-se
com estes uma nova tabela, que ter como chave primria o atributo participante da chave
primria da tabela origem.
Neste exemplo a soluo ser composta de trs tabelas agora, considerando a tabela
de partida utilizada.
Normalizao 185
Estrutura na Segunda Forma Normal (2FN)
Tabela de Notas Fiscais (NUMNF, SERIE, DATA EMISSAO, CODIGO DO CLIENTE, NOME DO CLIENTE,
ENDERECO DO CLIENTE, CNPJ DO CLIENTE E TOTAL GERAL DA NOTA)
Tabela de Item de Nota Fiscal (NUMNF, CODIGO DO PRODUTO, QUANTIDADE VENDIDA E TOTAL DA
VENDA DESTE PRODUTO)
Tabela de Produto (CODIGO DO PRODUTO, DESCRICAO DO PRODUTO, PRECO UNITRIO DE VENDA)
Cdigo do Produto Descrio do Produto Valor Unitrio

45 Limpadora a Vcuo 600,00
25 Computador 1.800,00
32 Refrigerador Brastemp 800,00
27 Televiso LG 950,00
NumNF Cdigo do Produto Quantidade de Produto Valor Total

456123 45 1 600,00
859032 25 1 1.800,00
859631 32 2 1.600,00
745689 27 3 2.850,00
485689 45 2 1.200,00
Nota Fiscal
Data de Cdigo Nome do Endereo Total da

NumNF Srie CNPJ
Emisso Cliente Cliente do Cliente Nota
456123 nica 20/02/2004 1 Luis Sampaio R. Silva S 23/11 01.253.523/0001-85 600,00
859032 nica 20/02/2004 2 Carlos Pereira R. Dias Melhores 334/122 32.253.501/0001-12 1.800,00
859631 nica 20/02/2004 3 Jos Alves Av. Arapans 4487/1915 005.333.510/0001-08 1.600,00
745689 nica 20/02/2004 4 Luis Paulo Souza R. Botica do Ouvidor 44 11.111.111/0007-01 2.850,00
Como resultado desta etapa, houve um desdobramento da tabela de item de nota fiscal
(a tabela de notas fiscais ainda no foi alterada por no ter chave composta) em duas
estruturas, a saber:
Primeira estrutura (tabela de item de nota fiscal): contm os elementos origi-
nais, sendo excludos os dados que so dependentes apenas do campo cdigo do
produto.
Segunda estrutura (tabela de produto): contm os elementos que so identifi-
cados apenas pelo cdigo do produto, ou seja, independentemente da nota fiscal, a
descrio e o preo unitrio de venda sero constantes.

Quando um atributo ou conjunto de atributos A de uma tabela depende de outro atributo
B, que no pertence chave primria, mas dependente funcional deste, dizemos que A
dependente transitivo de B.
As dependncias funcionais podem existir para atributos que no so chaves em uma
tabela. Este fato denominamos de dependncia funcional transitiva.
Terceira Forma Normal (3FN)

A terceira forma normal determina que no devem existir atributos com dependncia
funcional transitiva em uma tabela, pois podem provocar da mesma forma anomalias de
incluso, manuteno e deleo.
A aplicao da terceira forma normal consiste em retirar das estruturas os campos que
so funcionalmente dependentes de outros campos que no so chaves.
Podemos afirmar que uma estrutura est na terceira forma normal se ela estiver na
segunda forma normal e no possuir campos dependentes de outros campos no chaves.
Exemplo:
Estruturas na Segunda Forma Normal (2FN)

Tabela de Notas Fiscais (NUMNF, SERIE, DATA EMISSAO, CODIGO DO CLIENTE, NOME DO CLIENTE,
ENDERECO DO CLIENTE, CNPJ DO CLIENTE E TOTAL GERAL DA NOTA)
Tabela de Item de Nota Fiscal (NUMNF, CODIGO DO PRODUTO, QUANTIDADE VENDIDA E TOTAL DA
VENDA DESTE PRODUTO)
Tabela de Produto (CODIGO DO PRODUTO, DESCRICAO DO PRODUTO, PRECO UNITARIO DE VENDA)
Nota Fiscal
Data de Cdigo Nome do Endereo Total

NumNF Srie CNPJ
Emisso Cliente Cliente do Cliente Nota
456123 nica 20/02/2004 1 Luis Sampaio R. Silva S 23/11 01.253.523/0001-85 600,00
859631 nica 20/02/2004 3 Jos Alves Av. Arapans 4487/1915 005.333.510/0001-08 1.600,00
745689 nica 20/02/2004 4 Luis Paulo Souza R. Botica do Ouvidor 44 11.111.111/0007-01 2.850,00
Observa-se que na tabela de notas fiscais os dados NOME DO CLIENTE, ENDERECO DO

CLIENTE, CNPJ DO CLIENTEdependem funcionalmente da coluna CODIGO DO CLIENTE, a qual no faz
parte da chave primria desta tabela, logo tm dependncia funcional transitiva.
Normalizao 187
Estas colunas so ento retiradas e vo constituir uma nova tabela levando como chave
primria o atributo do qual possuam dependncia transitiva.
Estrutura de Dados na Terceira Forma Normal (3FN)
Tabela de Notas Fiscais (NUMNF, SERIE, DATA EMISSAO, CODIGO DO CLIENTE E TOTAL GERAL DA
NOTA)
Existe agora uma nova estrutura, ou nova tabela:
Tabela de Clientes (CODIGO DO CLIENTE, NOME DO CLIENTE, ENDERECO DO CLIENTE E CNPJ DO
CLIENTE)
Cliente
Cdigo do Cliente Nome do Cliente Endereo do Cliente CNPJ

1 Luis Sampaio R. Silva S 23/11 001.253.523/001-85
2 Carlos Pereira R. Dias Melhores 334/122 032.253.501/001-12
3 Jose Alves Av. Arapans 4487/1915 005.333.510/001-08
4 Luis Paulo Souza R. Botica do Ouvidor 44 011.111.111/007-01
2 Carlos Pereira R. Dias Melhores 334/122 032.253.501/001-12
Como resultado desta etapa, houve um desdobramento do arquivo de notas fiscais, por
ser o nico que tinha campos que no eram dependentes da chave principal (Num. NF), uma
vez que agora independentes de nmero da nota fiscal, o nome, endereo e CNPJ do cliente
so inalterados.
Esse procedimento permite evitar inconsistncia nos dados das tabelas e economizar
espao por eliminar o armazenamento frequente desses dados e sua repetio.
A cada nota fiscal emitida para um cliente no mais haver o armazenamento desses
dados, no havendo divergncia entre eles.
NotaFiscal
NumNF Srie Data de Emisso Cdigo do Cliente Total Nota

456123 nica 20/2/2004 1 600,00
859032 nica 20/2/2004 2 1.800,00
859631 nica 20/2/2004 3 1.600,00
745689 nica 20/2/2004 4 2.850,00
485689 nica 20/2/2004 2 1.200,00

As estruturas de dados foram alteradas pelos seguintes motivos:
Primeira estrutura (tabela de notas fiscais): contm os elementos originais,
sendo excludos os dados que eram dependentes apenas do campo cdigo do
cliente (informaes referentes ao cliente).
Segunda estrutura (tabela de clientes): contm os elementos que so identifi-
cados apenas pelo cdigo do cliente, ou seja, so independentes da nota fiscal, o
nome, endereo e CNPJ dos clientes sero constantes.
Aps a normalizao, as estruturas dos dados esto projetadas para eliminar as
inconsistncias e redundncias dos dados, eliminando desta forma qualquer problema de
atualizao e operacionalizao do sistema.
A verso final dos dados pode sofrer alguma alterao, para atender s necessidades
especficas do sistema, a critrio do analista de desenvolvimento durante o projeto fsico do
sistema.
Se analisarmos em termos de modelo de dados Entidade-Relacionamento, a evoluo
do seu processo de normalizao da sequncia de figuras que apresentamos:
Antes da primeira forma normal:
Aps a aplicao da primeira forma normal:
Temos duas entidades e um relacionamento.

Aps a aplicao da segunda forma normal:
Existem agora trs entidades e dois relacionamentos.

Finalmente, aps a aplicao da terceira forma normal temos quatro entidades e trs
relacionamentos.
Normalizao 189
A aplicao do processo de normalizao sobre documentos, formulrios e relatrios
existentes em um ambiente em anlise pode transformar-se em um instrumento de descoberta
de objetos e conceitos muito til ao processo de modelagem Entidade-Relacionamento.
Forma Normal de Boyce/Codd (FNBC)

As definies da 2FN e 3FN, desenvolvidas por Codd, no cobriam certos casos. Essa
inadequao foi apontada por Raymond Boyce em 1974. Os casos no cobertos pelas
definies de Codd somente ocorrem quando trs condies aparecem juntas:
A entidade tenha vrias chaves candidatas.
As chaves candidatas sejam concatenadas (mais de um atributo).
As chaves concatenadas compartilhem pelo menos um atributo comum.
Na verdade, a FNBC uma extenso da 3FN, que no resolvia certas anomalias
presentes na informao contida em uma entidade. O problema foi observado porque a 2FN e
a 3FN s tratavam dos casos de dependncia parcial e transitiva de atributos fora de qualquer
chave, porm quando o atributo observado estiver contido em uma chave (primria ou
candidata), ele no captado pela verificao da 2FN e 3FN.
A definio da FNBC a seguinte: uma entidade est na FNBC se e somente se todos
os determinantes forem chaves candidatas. Note que esta definio em termos de chaves
candidatas e no sobre chaves primrias.
Vamos imaginar a entidade filho com os seguintes atributos:
Por hiptese, vamos assumir que um professor possa estar associado a mais de uma
escola e uma sala.
Com esta suposio tanto a chave (candidata) concatenada NOME-DA-ESCOLA +
SALA-DA-ESCOLA como NOME-DA-ESCOLA + NOME-DO-PROFESSOR podem ser determinantes.
Logo, esta entidade atende s trs condies relacionadas anteriormente:

1. As chaves candidatas para a entidade FILHO so: NOME-DO-FILHO + ENDERECO-DO-FILHO,
NOME-DO-FILHO + NUMERO-DA-SALA e NOME-DO-FILHO + NOME-DO-PROFESSOR;
2. As trs chaves apresentam mais de um atributo (concatenados).
3. As trs chaves compartilham um mesmo atributo: NOME-DO-FILHO.
Neste exemplo, NOME-DO-PROFESSOR no completamente dependente funcional do
NUMERO-DA-SALA nem NUMERO-DA-SALA completamente dependente funcional do NOME-DO-
-PROFESSOR.
Neste caso, NOME-DO-PROFESSOR completamente dependente funcional da chave
candidata concatenada NOME-DO-FILHO + NUMERO -DA-SALA ou NUMERO -DA-SALA completamente
dependente funcional da chave candidata concatenada NOME-DO-FILHO + NOME-DO-PROFESSOR.
Ao aplicar FNBC, a entidade FILHO deve ser dividida em duas entidades, uma que
contm todos os atributos que descrevem o FILHO e a segunda que contm os atributos que
designam um professor em uma escola em particular e nmero de uma sala.
Entidade FILHO
Entidade SALA
Os casos para aplicao dessa forma normal a FNBC so mais raros de encontrar na
prtica, pois derivam de erros de modelagem realizados quando da estruturao dos atributos
de uma entidade.
Vamos buscar mais um exemplo de forma que fique clara a utilizao da FNBC e seja
visto algo um pouco mais prximo de uma realidade prtica e uma definio mais ampla para a
FNBC:
Normalizao 191
Uma tabela R est na FNBC com respeito a conjunto F de dependncias funcionais da forma
A B, em que A R e B A R se ao menos se realizam:
A B uma dependncia funcional trivial, isto , B A.
A uma superchave para a tabela R.
Sejam as tabelas semelhantes s que j utilizamos neste livro para uma aplicao
bancria.
Entidade Cliente
Cliente
NomCliente RuaCliente CidadeCliente

Luis Sampaio Rua A Rio de Janeiro
Carlos Pereira Rua B Niteri
Jose Alves Rua C Rio de Janeiro
Luis Paulo Souza Rua B Niteri
Cliente = {NOMCLIENTE, RUACLIENTE, RUACLIENTE}

Podemos afirmar que a entidade cliente est na FNBC, pois uma chave candidata para
esta entidade (tabela) NomCliente.
Observando, temos:
NOMCLIENTE RUACLIENTE, CIDADECLIENTE
Isso denota que no existem dependncias multivaloradas nesta entidade nem existem
mltiplas chaves candidatas.
Entidade Agncia
Agncia
NomAgencia Fundos CidadeAgencia

Rio Branco 1.210.000,00 Rio de Janeiro
Icarai 1.500.000,00 Niteri
Leblon 2.500.000,00 Rio de Janeiro
Ipanema 150.000,00 Rio de Janeiro
Estacio 38.000,00 Rio de Janeiro
Agencia = {NOMAGENCIA, FUNDOS, CIDADEAGENCIA}

NOMAGENCIA FUNDOS, CIDADEAGENCIA

Entidade Emprstimos
Emprstimo
NomAgencia NomCliente NumEmprest Valor

Rio Branco Luis Sampaio 902230 1500,00
Rio Branco Carlos Pereira 902230 1500,00
Rio Branco Luis Paulo Souza 902240 1200,00
Ipanema Jose Alves 902289 3000,00
Ipanema Luis Paulo Souza 902255 850,00
Icarai Carlos Pereira 902290 700,00
Icarai Jose Alves 902212 400,00
Emprestimo = {NOMAGENCIA, NOMCLIENTE, NUMEMPREST, VALOR}

Esta estrutura de dados, entretanto, no satisfaz a FNBC, pois se considerarmos
NUMEMPREST somente como sua chave candidata, pode haver um par de linhas representando
o mesmo emprstimo, desde que fossem duas as pessoas participantes dele, como na tabela
apresentada.
NomAgencia NomCliente NumEmprest Valor

Rio Branco Luis Sampaio 902230 1500,00
Rio Branco Carlos Pereira 902230 1500,00
Isso provocaria que o valor do emprstimo aparecesse repetidas vezes na tabela.

Logo,
NUMEMPREST valor no total para a tabela, pois no podemos considerar o
somatrio das ocorrncias de nmero de emprstimo.
Poderamos considerar como chaves candidatas os seguintes conjuntos de atributos:
NOMAGENCIA+ NUMEMPREST
NOMCLIENTE+ NUMEMPREST
Da mesma forma, se analisarmos as dependncias funcionais, veremos que no
vlido o que segue:
(NOMAGENCIA+ NUMEMPREST) VALOR
NOMCLIENTE+ NUMEMPREST VALOR
Como existe dependncia multivalorada neste caso, temos de aplicar a FNBC.
Normalizao 193
Decompomos a entidade que no est na FNBC em duas entidades sem perder a
capacidade de juno delas.
Emprstimo = {NOMAGENCIA, NUMEMPREST, VALOR}
Devedor = {NOMCLIENTE, NUMEMPREST}
Emprstimo Devedor
NomAgencia NumEmprest Valor NomCliente NumEmprest

Rio Branco 902230 1500,00 Luis Sampaio 902230
Rio Branco 902240 1200,00 Carlos Pereira 902230
Ipanema 902289 3000,00 Luis Paulo Souza 902240
Ipanema 902255 850,00 Jose Alves 902289
Icarai 902299 700,00 Luis Paulo Souza 902255
Icarai 902212 400,00 Carlos Pereira 902299
Jose Alves 902212
Olhando o resultado desta aplicao em um modelo de dados, vamos ver o modelo

inicial e o modelo final aps a aplicao da FNBC.
Modelo Inicial
Identificando as chaves candidatas em Cliente e Agncia, temos a figura seguinte.

Este um modelo de dados que no satisfaz ainda a FNBC.

Aplicando a FNBC, teremos ento um novo modelo refinado:
Modelo Final
Observe que o processo de modelagem natural de dados poderia comear este modelo
muito prximo da realidade final com a FNBC. Tudo se origina na sua capacidade de abstrao
e de descrio das propriedades de um objeto.
Quando modelamos com foco lgico no modelo relacional, dificilmente temos situaes
como esta para resolver, pois inerente a esse processo de modelagem a finalizao
encontrada, porm se o analista interpretar separadamente os objetos do ambiente, pode
realmente criar a situao inicial para a aplicao da FNBC.
Quarta Forma Normal (4FN)

Na grande maioria dos casos, as entidades normalizadas at a 3FN so fceis de
entender, atualizar e recuperar dados, mas s vezes podem surgir problemas com relao a
algum atributo no chave, que recebe valores mltiplos para um mesmo valor de chave. Essa
nova dependncia recebe o nome de multivalorada que existe somente se a entidade contiver
no mnimo trs atributos.
Normalizao 195
Uma entidade que esteja na 3FN tambm est na 4FN, se ela no contiver mais do que
um fato multivalorado a respeito da entidade descrita. Essa dependncia no o mesmo que
uma associao M:N entre atributos, geralmente descrita desta forma em algumas literaturas,
mas ocorre quando consideramos a existncia de relacionamentos, por exemplo, ternrios.
Vamos imaginar o contedo desta tabela compra:
CodFornecedor CodProduto CodComprador

101 BA3 01
102 CJ10 05
110 88A 25
530 BA3 01
101 BA3 25
Como podemos observar, esta entidade tenta conter dois fatos multivalorados: os diver-
sos produtos comprados e as diversas categorias. Com isso apresenta uma dependncia multi-
valorada entre CodFornecedor e CodProduto e entre CodFornecedor e CodComputador.
Esta tabela est representada no modelo de dados em seguida:
Embora esteja na 3FN, pois no existem dependncias transitivas na tabela, ao conter

mais de um fato multivalor, sua atualizao torna-se muito difcil. Tambm existe a possibi-
lidade de problemas relativos ao espao fsico de armazenamento virem a ocorrer, causados
pela ocupao desnecessria de rea de memria (primria ou secundria), podendo acarretar
situaes crticas em termos de necessidade de mais espao para outras aplicaes.
Para passarmos a entidade anterior para a 4FN, necessria a realizao de uma
diviso da entidade original, em duas outras, ambas herdando a chave CodFornecedor e
concatenada, em cada nova entidade, com os atributos CodProduto e CodComputador.

CodFornecedor CodProduto CodProduto CodComprador
101 BA3 BA3 01
102 CJ10 CJ10 05
110 88A 88A 01
530 BA3 BA3 25
101 BA3
Observando o modelo de dados, podemos entender melhor:
claro que incrementamos o modelo com mais atributos para ilustrao, j que eles
no atrapalham nada e permitem uma visualizao de contexto maior.
A aplicao da 4FN foi realizada neste caso para corrigir um erro de modelagem de
dados, pois no primeiro modelo utilizamos um relacionamento ternrio de forma desnecessria,
associando o comprador somente ao processo de compra, e no aos produtos que ele compra.
A conectividade apresentada a mesma para os dois casos, um comprador compra
muitos produtos, e um produto comprado somente por um comprador. Entretanto, a anomalia
iria permitir que esta regra de negcio fosse burlada pela simples estruturao com erro de
4FN no modelo inicial.
Um modelo de dados conceitual e lgico pode estar aparentemente correto at que se
validem as possibilidades de dados no interior de suas tabelas relacionais.
Vamos usar como exemplo uma empresa que constri equipamentos complexos.
A partir de desenhos de projeto desses equipamentos, so feitos documentos de
requisies de materiais, necessrios para a construo do equipamento; toda a requisio
de um material d origem a um ou mais pedidos de compra.
A modelagem deste exemplo mostra quais materiais de requisies geraram quais
pedidos. Na figura apresentado esse relacionamento ternrio.
Normalizao 197
A tabela seguinte representa o relacionamento ternrio faz que poderia conter os
seguintes dados:
Material Pedido de Compra Requisio

ROTOR 1BW PC 0792 R1292
ROTOR 1BW PC0992 R3192
CI 102 PC0792 R3192
Utilizando uma soma de visualizao da dependncia de juno, apresentada por

James Bradley, obtemos o grfico de dependncia de juno, mostrado na figura seguinte:
Uma pergunta surge sobre este problema: possvel substituir o relacionamento tern-
rio por relacionamentos binrios, como os apresentados a seguir?
Como resposta podemos dizer que geralmente no possvel criar essa decomposio
sem perda de informao, armazenada no relacionamento ternrio.

Realizando uma projeo na tabela inicial, chegamos aos relacionamentos mostrados
pelo modelo:
Relacionamento Pede Relacionamento Tem
Material Pedido de Compra Pedido de Compra Requisio

ROTOR 1BW PC 0792 PC 0792 R1292
ROTOR 1BW PC0992 PC0992 R3192
CI 102 PC0792 PC0792 R3192
Relacionamento Faz
Material Requisio
ROTOR 1BW R1292
ROTOR 1BW R3192
CI 102 R3192
Se realizarmos agora um processo de juno destas trs entidades, teremos:

Inicialmente, vamos juntar a tabela do relacionamento pede com a tabela do relaciona-
mento tem por meio do campo pedido de compra. Obtemos ento a tabela 4.
Tabela 4

CI 102 PC0792 R3192
CI 102 PC0792 R1292
Podemos observar que o registro apontado com sombreamento no existia na tabela

original, ou seja, foi criado pela juno das tabelas parciais.
Devemos juntar a entidade 4, resultante da primeira juno, com a tabela do relaciona-
mento faz, atravs dos campos material e requisio. Aps esta ltima operao de juno,
obtemos a tabela 5, mostrada a seguir.
Tabela 5

CI 102 PC0792 R3192
Normalizao 199
Como se pode notar, ao juntar as trs tabelas, fruto da decomposio da tabela original,
as suas informaes foram preservadas. Isso significa que o relacionamento Faz inicial no
est na 5FN, sendo necessrio decomp-lo em relacionamentos binrios, os quais estaro na
5FN.
Quinta Forma Normal (5FN)

A definio da 5FN diz que uma tabela de 4FN estar em 5FN quando seu contedo
no puder ser reconstrudo (existir perda de informao) a partir das diversas tabelas menores
que no possuam a mesma chave primria. Essa forma normal trata especificamente dos
casos de perda de informao, quando da decomposio de relacionamentos mltiplos.
Com a 5FN algumas redundncias podem ser retiradas, como a informao de que o
"ROTOR 1BW" est presente na requisio "R3192", ser armazenada uma nica vez, a qual
na forma no normalizada pode ser repetida inmeras vezes.
Roteiro de Aplicao da Normalizao

Entidade ou documento no normalizado, apresentando grupos repetitivos e certas
anomalias de atualizao.
Aplicao da 1FN
Decompor a entidade em uma ou mais entidades, sem grupos repetitivos;
Destacar um ou mais atributos como chave primria da(s) nova(s) entidade(s), e
este ser concatenado com a chave primria da entidade original;
Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s)
gerada(s) e a entidade geradora;
Verificar a questo da variao temporal de certos atributos e criar relacionamentos
1:N entre a entidade original e a entidade criada por questes de histrico.
ENTIDADES NA 1FN
Aplicao da 2FN
Para entidades que contenham chaves primrias concatenadas, destacar os atribu-
tos que tenham dependncia parcial em relao chave primria concatenada;
Criar uma entidade que conter esses atributos, e que ter como chave primria
o(s) atributo(s) do(s) qual(quais) se tenha dependncia parcial;
Sero criadas tantas entidades quantos forem os atributos da chave primria
concatenada, que gerem dependncia parcial;

Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s)
gerada(s) e a entidade geradora.
ENTIDADES NA 2FN
Aplicao da 3FN
Verificar se existem atributos que sejam dependentes transitivos de outros que no
pertencem chave primria, sendo ela concatenada ou no, bem como atributos
que sejam dependentes de clculo realizado a partir de outros atributos;
Destacar os atributos com dependncia transitiva, gerando uma nova entidade com
esse atributo e cuja chave primria o atributo que originou a dependncia;
Eliminar os atributos obtidos por clculos realizados a partir de outros atributos.
ENTIDADES NA 3FN
Aplicao da FNBC
S aplicvel em entidades que possuam chaves primrias e chaves candidatas
concatenadas;
Verificar se alguma chave candidata concatenada um determinante, e em caso
afirmativo, criar uma entidade com os que dependam funcionalmente desse
determinante e cuja chave primria o prprio determinante.
ENTIDADES NA FNBC
Aplicao da 4FN
Para se normalizar em 4FN, a entidade precisa estar (obrigatoriamente) na 3FN;
Verificar se a entidade possui atributos que no sejam participantes da chave
primria e que sejam multivalorados e independentes em relao a um mesmo
valor da chave primria;
Retirar esses atributos no chaves e multivalorados, criando entidades para cada
um deles, herdando a chave primria da entidade desmembrada.
ENTIDADES NA 4FN
Aplicao da 5FN
Aplicada em elementos que estejam na 4FN;
A ocorrncia desse tipo de forma normal est vinculada aos relacionamentos
mltiplos (ternrios etc.) ou entidades que possuam chave primria concatenada
com trs ou mais atributos;
Normalizao 201
Verificar se possvel reconstruir o contedo do elemento original a partir de
elementos decompostos desta;
Se no for possvel, o elemento observado no est na 5FN; caso contrrio, os
elementos decompostos representam um elemento na 5FN.
ENTIDADES NA FORMA NORMAL FINAL
O processo de normalizao leva ao refinamento das entidades, retirando delas grande

parte das redundncias e inconsistncias. Naturalmente, para que haja uma associao entre
entidades, preciso que ocorram redundncias mnimas de atributos que evidenciam esses
relacionamentos. Sem essas redundncias no haveria relacionamento entre entidades.
Consideraes Finais sobre Normalizao

Antes de qualquer concluso, podemos observar que as formas normais nada mais so
do que restries de integridade, e medida que se alimenta este grau de normalizao,
tornam-se cada vez mais restritivas. Dependendo do SGBD relacional utilizado, essas restri-
es podem se tornar benficas ou no.
A forma de atuao da normalizao no ciclo de vida de um projeto de bases de dados
pode ser mais satisfatria no desenvolvimento (bottom-up) de modelos preliminares, a partir da
normalizao da documentao existente no ambiente analisado, bem como de arquivos
utilizados em alguns processos automatizados neste ambiente.
No caso do desenvolvimento top-dowm, no qual um modelo de dados criado a partir
da visualizao da realidade, a normalizao serve para realizar um aprimoramento desse
modelo, tornando-o menos redundante e inconsistente. No caso desta viso, a normalizao
torna-se um poderoso aliado da implementao fsica do modelo.
Por experincia, podemos afirmar que a construo de um modelo de dados j leva
naturalmente ao desenvolvimento de entidades e relacionamentos na 3FN, ficando as demais
(FNBC, 4FN e 5FN) para melhorias e otimizaes.
A criao de modelos de dados, partindo-se da normalizao de documentos e arquivos
pura e simplesmente, no o mais indicado, pois na verdade vamos observar o problema e
no dar uma soluo a ele. Neste caso, vamos projetar estruturas de dados que se baseiam na
situao atual (muitas vezes catica) e que certamente no vo atender s necessidades reais
do ambiente em anlise. Ao passo que, se partirmos para a criao do modelo de dados com
entidades e relacionamentos aderentes realidade em estudo (mundo real), vamos natural-
mente desenvolver uma base de dados ligada viso da realidade e, como consequncia,
vamos solucionar o problema de informao.
A aplicao da modelagem de dados, ao longo da nossa vida profissional, tem sido
bastante gratificante, mostrando principalmente que a tcnica de normalizao uma
ferramenta muito til como apoio ao desenvolvimento do modelo de dados. Seja ela aplicada
como levantamento inicial (documentos e arquivos), bem como otimizadora do modelo de

dados, tendo em vista certas restries quanto implementao fsica nos bancos de dados
conhecidos.
Todas as ideias sobre eficincia da normalizao passam necessariamente sobre
tempo e espao fsico, em funo, principalmente, das consultas efetuadas pelos usurios,
bem como a quantidade de bytes necessrios para guardar as informaes.
Nota-se, pela observao, que o projeto do modelo conceitual nem sempre pode ser
derivado para o modelo fsico final. Com isso, de grande importncia que o responsvel pela
modelagem (analista, AD etc.) no conhea s a teoria iniciada por Peter Chen, mas tambm
tenha bons conhecimentos a respeito do ambiente de banco de dados utilizado pelo local em
anlise.
Desnormalizao dos Dados

Normalizao essencial para que bases de dados relacionais preservem a consis-
tncia da informao com respeito ao estado atual do sistema e torna o relacionamento entre
entidades de dados (registros) implcito. Porm, requer navegao atravs de tabelas, que
podem ser vrias, para a composio de uma informao.
Alguns Motivos para a Desnormalizao

Em contraste com os bancos de dados relacionais, um Data Warehouse diferencia-se,
neste contexto, por manter dados em formato no normalizado, beneficiando-se da agilidade
garantida em consultas. Alm disso, a desnormalizao faz com que o usurio realize
consultas de forma transparente, isto , ele no precisa saber o nome de tabelas de ndices, ou
tabelas intermedirias, resultantes da normalizao. Desta forma, um Data Warehouse estabe-
lece relacionamentos entre entidades de dados e possibilita consultas de forma eficiente.
A desnormalizao apenas tolervel devido a imperativos (rgidos) de desempenho
como no caso de Data Warehouse, entre outros, ou se o sistema no consegue atingir um
patamar mnimo de desempenho sem o processo de desnormalizao.
Sempre devemos questionar se, aps a desnormalizao, o desempenho melhorar
significativamente.
O processo de desnormalizao vai retirar confiabilidade ou consistncia da informao?
Importante documentar todos os atos de desnormalizao e respectivas justificativas.
Outra justificativa para a desnormalizao a existncia de vrias consultas de desem-
penho crtico e que necessitam de informao de mais que duas tabelas (elevado nmero de
junes) ou nmero elevado de chaves estrangeiras em uma tabela.
Tambm podemos usar a desnormalizao se existir um nmero elevado de clculos
que devem ser efetuados sobre uma ou vrias colunas antes da resposta a uma consulta.
Normalizao 203
9
UM ESTUDO DE CASO
Para que possamos desenvolver as tcnicas que apresentamos at este momento no

livro, vamos estudar um caso relativamente simples, partindo de uma anlise de requisitos de
sistemas. Construiremos uma lista de eventos, particionaremos os eventos para entendimento
e detalhamento maior, e logo em seguida com maior abstrao vamos desenhar um modelo de
dados Entidade-Relacionamento.
bvio que um caso fictcio com algumas afirmaes que so totalmente aderentes
administrao hospitalar, mas um exerccio de anlise de sistemas. Posteriormente voc
pode expandir os modelos resultantes para uma realidade mais prxima da sua.
O Problema - Administrao de Cirurgias

Para este problema foi fornecido um conjunto de informa-
es obtidas em uma reunio para definir o que o sistema deve
controlar e realizar na viso dos usurios administradores.
Em um hospital existem diversas salas em seu centro
cirrgico. As salas de cirurgia possuem recursos para grupos de
especialidades mdicas, sendo apropriadas para cirurgias de
uma especialidade.
Existem salas que se prestam somente a cirurgias de uma nica especialidade, pois
esto dotadas de equipamentos apropriados a essa especialidade mdica.
Os mdicos que realizam cirurgias no hospital em seus pacientes agendam as cirurgias
conforme a disponibilidade das salas, informando datas, hora inicial e hora final prevista, junto
operadora do sistema.
Os horrios para controle das salas so modulados de 30 em 30 minutos, de forma a
manter-se uma quebra equilibrada da distribuio de horrios. Quando uma cirurgia
encerrada, informado ao controle do Centro Cirrgico para a preparao e higienizao para
a prxima ocupao.

Uma sala de cirurgia no pode ser utilizada simultaneamente por mais de uma cirurgia,
pois somente existe um leito cirrgico em cada uma.
Um mdico no pode ter cirurgias coincidentes em data e horrio, mesmo que em salas
diferentes.
Uma cirurgia somente deve ser realizada em uma sala apropriada para a sua espe-
cialidade. Admitem-se urgncias, porm devem ser destacadas para utilizarem salas que no
as especficas da especialidade.
Urgncia considerada uma qualificao da cirurgia, mas no tem restrio de especia-
lidade, podendo utilizar qualquer uma das salas.
Toda cirurgia tem somente um mdico responsvel, que devemos registrar para o
controle do sistema.
Importante: No constam deste escopo os assistentes, instrumentadores nem anestesistas.
Os medicamentos, materiais e remdios consumidos pela cirurgia devem ser compu-

tados para cobrana posterior.
O paciente identificado pelo hospital, inclusive com o seu leito de internao e datas.
No existe no sistema nenhum controle pr-cirrgico.
O sistema deve controlar cirurgias marcadas, assim como as j realizadas.
Para o Centro Cirrgico especialidade um dado do tipo: Cardiorrespiratria, Nefro-
logia, Ginecologia e Obstetrcia, Transplantes, Gastroenterologia, Oftalmologia, Traumatologia,
Cirurgia Plstica, Oncologia etc.
Os mdicos so todos registrados como habilitados no hospital, suas especialidades
tambm controladas, podendo realizar cirurgias em somente uma especialidade.
So considerados materiais gastos em uma cirurgia as agulhas de
sutura, algodes, sangue, gaze. Como medicamentos temos produtos como
anestsicos em geral, antisspticos, soro etc., e remdios diversos com
aplicao intravenosa.
Modelagem
Vamos ento comear a modelar este caso.
O que temos de coisa neste ambiente de negcios?
Utilizamos esta ilustrao para despertar em voc um olhar atento e estimular a sua
capacidade de utilizar-se de abstrao para identificar as coisas que esto neste ambiente.
Um Estudo de Caso 205

Analisando, podemos concluir alguns objetos que temos neste ambiente de sistema.
A primeira coisa que aparece pode at causar
dvidas e permite duas interpretaes. Uma como um fato
e outra como uma entidade. A primeira interpretao
apresenta-se como uma entidade.
A cirurgia.
Seguindo nossa abstrao para a descoberta de entidades, pela ordem relativa temos
dois objetos mais: mdico e paciente.
normal nos exerccios resolvidos em aula o aluno esquecer o paciente, mas ns j o

movimentamos em nossos eventos e seria pouco provvel esquec-lo.
Temos ento um conjunto de entidades at agora em nmero de trs: mdico, paciente
e cirurgia.
interessante discutir a segunda interpretao do objeto cirurgia com o leitor.

Cirurgia uma entidade ou um fato?
Tudo depende de sua interpretao do mundo real.
Se analisarmos que um mdico realiza uma cirurgia, parece mais com uma entidade,
pois mdico relaciona-se com ela. Se analisarmos a realidade como mdico opera paciente,
este mesmo objeto passa a ser um relacionamento entre mdico e paciente, um fato
equivalente entidade cirurgia.
Na realidade temos duas solues possveis de modelo de dados conceitual para esta
relao, ou o fato de acontecer uma cirurgia, ou do que uma cirurgia.
No primeiro caso temos uma entidade cirurgia relacionada com a entidade Mdico e
com a entidade Paciente, pois os dois participam de cirurgia.
Resta-nos definir a conectividade entre estas entidades. Vamos l!
Um mdico pode realizar muitas cirurgias.
Uma cirurgia, segundo as premissas iniciais, tem somente um mdico.
Uma cirurgia tambm tem somente um paciente, pois no so realizadas cirurgias

coletivas nesse hospital. J imaginou como seria?
Um paciente pode vir a sofrer muitas cirurgias. O mdico pode esquecer uma tesoura
na barriga do sujeito e ter de operar de novo para tirar.
Logo, podemos ter o Diagrama Entidade-Relacionamento (DER) com as conectividades
corretas desta primeira interpretao.
Vamos agora exercitar e confirmar se a segunda interpretao est correta ou no.

Temos um relacionamento entre mdico e paciente que um fato, a prpria cirurgia, o
mdico opera paciente.

Esse relacionamento deve ser entendido como a representao de um fato que pode
ser denominado de cirurgia em si.
O que muda neste modelo em relao ao anterior?

A conectividade agora diferente da anterior.
Um mdico participa de opera muitos pacientes.
Um paciente sofre muitas cirurgias.
Logo, temos um relacionamento de muitos-para-muitos.
Vamos apresentar este relacionamento com atributos, pois nele estaro as informaes
de hora, data, especialidade da cirurgia etc.
Veja que os atributos so os mesmos que estariam na entidade cirurgia da soluo

anterior, com trs entidades.
E nos atributos aparece a localizao da cirurgia, a sala.
Voltando abstrao em busca de entidades, pergunta-se:
Sala no um objeto, uma coisa desse ambiente que possui dados, e objeto do
sistema?

A resposta evidente positiva. Sala uma
entidade, pois pode estar localizada em uma ala, em um
andar, tem uma especialidade que pode atender etc.
Vamos acrescentar ao modelo a entidade sala.
Mas j analisando, sala se relaciona com quem?

Sala se relaciona com mdico?
Somente atravs da cirurgia ou do relacionamento opera.
Sala se relaciona com paciente?
No, somente por meio da cirurgia tambm.
Mas afinal, sala se relaciona com quem?
Sala se relaciona com cirurgia em nossa primeira soluo.
Ou com a agregao do relacionamento opera da seguinte soluo:
So duas solues para retratar uma realidade, e as duas esto corretas.

Vamos seguir para verificar se existem mais entidades nesse ambiente de sistema.

Existe uma entidade a mais que mencionada em vrias afirmativas no levantamento
de ambiente:
"As salas de cirurgia possuem recursos para grupos de especia-
lidades mdicas, sendo apropriadas para cirurgias de uma especialidade."
"Existem salas que se prestam somente a cirurgias de uma nica
especialidade, pois esto dotadas de equipamentos apropriados a essa
especialidade mdica."
"Os mdicos so todos registrados como habilitados no hospital,
sendo suas especialidades tambm controladas, podendo realizar cirur-
gias em somente uma especialidade."
Isso nos leva existncia da entidade especialidade.
Mas especialidade efetivamente uma entidade ou um atributo de sala e de mdico?
No mundo real especialidade um dado qualificativo de sala e de mdico, pois comple-
menta a descrio destes dois objetos.
Entretanto, como estamos pensando e raciocinando em termos de banco de dados
relacional, podemos realizar uma anlise de redundncias do modelo de dados.
O que seria a anlise?
Se especialidade um atributo comum a duas entidades, podemos otimizar essa
informao tabulando-a na forma de um objeto externo a estas duas entidades. Desta forma
certamente teramos informao unificada tanto para a qualificao de salas quanto para a
qualificao de mdicos.
Como fazemos isso?
Criamos a entidade especialidade, que se relaciona com a entidade sala e com a
entidade mdico.
Com isso obtemos duas conectividades distintas em cada relacionamento:
Um mdico possui uma especialidade
Uma especialidade qualifica muitos mdicos
Uma sala tem muitas especialidades
Uma especialidade tem muitas salas
Com esta soluo estamos com mais um relacionamento muitos-para-muitos no
modelo.

No segundo formato de soluo teramos o mesmo formato de relacionamento,
somente com o detalhe de observar que a ligao de especialidade com mdico indicada no
diagrama ER com uma linha que conecta com a entidade mdico e no com a caixa da
agregao.
Seguindo nosso raciocnio abstrato, o que mais teramos de significativo neste modelo
de dados, com base no levantamento de informaes inicial?
Temos mais duas afirmativas para analisar:
"Os medicamentos, materiais e remdios consumidos pela cirurgia devem ser compu-
tados para cobrana posterior."

"So considerados materiais gastos em uma cirurgia as agulhas de sutura, algodo,
sangue, gaze. Como medicamentos temos produtos como anestsicos em geral, antisspticos,
soro etc., e remdios diversos com aplicao intravenosa."
Cuidado para no criar de imediato trs entidades, pois temos um grupo de objetos que
so consumidos por uma cirurgia.
Voltando aos conceitos de abstrao, vamos lembrar que existe o conceito de classifi-
cao de objetos.
H na realidade um conjunto de
coisas que so consumidas na cirurgia,
uma classe de objeto, que composta
de medicamentos, materiais e remdios
por assim dizer.
Logo, podemos utilizar o conceito
de generalizao de entidades neste mo-
delo para realizar o diagrama ER.
Este bloco de modelo deve estar relacionado com que entidade?
Bem, se os produtos so consumidos, utilizados na cirurgia, devem estar relacionados
obviamente com cirurgia.

Um produto consumido em muitas cirurgias e uma cirurgia consome muitos produtos.
Logo, h mais um relacionamento muitos-para-muitos para encerrar o nosso modelo.
Com base nas informaes obtidas em nosso levantamento de dados, conseguimos
determinar em um primeiro momento um conjunto de eventos e um modelo conceitual de
dados para o sistema.
Vamos analisar os atributos desse modelo de dados at agora construdo, utilizando
uma ferramenta CASE que permita destacar as chaves primrias e estrangeiras do modelo, o
ERwin.
Vamos elencar os possveis atributos das nossas entidades e relacionamentos, assim
como os obrigatrios para a efetivao dos relacionamentos.
Neste modelo apresentado, propositalmente deixamos de colocar informaes relativas

data e hora da cirurgia.
Queremos provocar a discusso de onde devem ser colocados esses atributos.
Vamos exercitar ento.
Se colocarmos somente a data na chave primria da entidade cirurgia, efetivamos uma
restrio no modelo: um mdico somente pode operar um paciente uma vez em um dia.
Caso o paciente tenha de voltar para uma nova cirurgia com o mesmo mdico na
mesma data, isso ser impossvel de ser registrado, pela restrio de identidade em uma
tabela relacional. No existe mais de uma ocorrncia na tabela com a mesma chave primria.

Logo, temos de colocar os dois dados na chave primria para que se evite essa
restrio no mundo real.
Assim, a chave primria da entidade cirurgia ter mais dois dados:
Data da cirurgia
Hora inicial da cirurgia
A informao de hora final estimada no necessita ficar na chave primria, at por ser
um dado estimado, assim como no relevante na identificao da coisa cirurgia.
Observe que a entidade cirurgia ficou composta somente de chave primria. Fica a
cargo de sua criatividade completar essa entidade com outros atributos que, certamente,
existem no mundo real.
Basta irmos at os usurios e question-los agora sobre que dados mais existem e so
controlados em cirurgia.
Encerramos aqui este estudo de caso, no qual j conseguimos aplicar os princpios que
estudamos em modelo de dados ER.

10
HIERARQUIAS
Tratamento de Hierarquias de Dados

As estruturas hierrquicas so aparentemente mais complexas de serem resolvidas,
com Diagramas Entidade-Relacionamento e em ambientes relacionais, ou seja, bancos de
dados relacionais.
Tudo uma questo de entendimento e raciocnio por partes.
Ento, seguindo a filosofia de Jack, o estripador, vamos por partes.
No nosso exemplo at que bem simples:
Cabea composta de olho, ocelo, armadura bucal, antena e rea intersutural.
Essa estrutura de informaes possui somente um nvel de decomposio.
, ento, uma estrutura hierrquica de um nvel como o diagrama apresentado a seguir:
O importante conseguir visualizar uma tabela de dados e seu contedo para entender
o modelo de dados que ser apresentado como soluo.
Vejamos que o conjunto de dados ou o objeto que se deseja modelar so, digamos,
partes do corpo humano.
Hierarquias 215
"Partes do corpo humano so compostas por outras partes do corpo humano."
Logo, temos um autorrelacionamento ou relacionamento reflexivo em uma mesma
entidade, que denominamos de partes do corpo humano.
O modelo de dados fica simples de entender se analisarmos a tabela com que imple-
mentamos esse modelo de dados ER.
Identificao da
Descrio Caractersticas Parte que Compe etc. etc.
Parte do Corpo
1 Cabea xxxx nulo kjgjgfj
2 Ocelo yyyy 1 oiuytoru
3 Armadura Bucal zzzz 1 b cbvu
4 rea intersutural dddd 1 kmnfkj
5 Olho fffff 1 mn fke
6 Pupila vvvvv 5 ldoirr
Observe que foi acrescentado um nvel estrutura hierrquica:
Cabea tambm composta por olho, que composto por pupila, retina etc.
A navegao nesta tabela buscando os registros inter-relacionados fornece a rvore de
composio de qualquer objeto modelado desta forma.

Parte Identificao Parte
Identificao da
Descrio que da Parte do Descrio que
Parte do Corpo
Compe Corpo Compe
1 Cabea nulo 2 Ocelo 1
1 Cabea nulo 3 Armadura Bucal 1
1 Cabea nulo 4 rea intersutural 1
1 Cabea nulo 5 Olho 1
5 Olho 1 6 Pupila 5
Neste caso observamos muito bem a importncia do conceito de chave estrangeira,

pois com ela conseguimos realizar a comparao de valores e identificar quem se relaciona
com quem.
O resultado de um SELECT, para encontrar a rvore de composio, fornece a tabela
apresentada anteriormente.
Mesmo que existam vrios nveis de hierarquia, sempre utilizaremos esse tipo de
autorrelacionamento.
Somente vamos mudar o modelo quando tivermos composies em que uma
determinada parte entra na composio de uma outra parte. Ento teremos autorrelacio-
namentos de muitos-para-muitos.
No exemplo tratamos a composio como um relacionamento de um-para-muitos, pois
estamos discutindo a implementao de uma hierarquia em um modelo de dados ER.
Hierarquias 217
11
MODELO FSICO
O Modelo Fsico em Si
Nesta etapa, o analista passa as vises do modelo conceitual para o modelo lgico
relacional, no qual os dados so vistos como estruturas de dados voltadas para as caracte-
rsticas da abordagem escolhida, objetivando a implementao do banco de dados.
O modelo fsico prov um contexto para definio e registro no catlogo do banco de
dados dos elementos de dados que formam um database, por assim dizer, e fornece aos
analistas de uma aplicao a possibilidade de escolha dos caminhos e acesso s estruturas de
dados.
Na criao de um modelo fsico de dados, realizada pela converso do modelo concei-
tual, possumos uma lista de conceitos dos componentes de cada modelo e sua equivalncia,
que pode orientar na relao dos termos utilizados que vamos apresentar neste captulo, alm
de consideraes gerais sobre o processo.
A transformao de um modelo conceitual ou lgico em modelo fsico exige que sejam
realizadas as definies dos atributos de uma tabela (colunas) que sero ndices, como ser o
tipo desse atributo (numrico, caractere, data, outros), assim como a exigncia de sua exis-
tncia ou no, sua identificao como chave primria ou estrangeira na tabela em si.
Na realidade, vamos adequar o tipo de dado ao tipo de dado permitido, implementado
pelo Sistema Gerenciador de Banco de Dados Relacional com que vamos trabalhar.
As principais ferramentas CASE do mercado possuem interfaces de converso do
modelo lgico no modelo fsico, que disponibilizam o tipo de dado correto e permitido para
cada SGBD usualmente utilizado, alm de permitirem assinalamento das outras caractersticas
de um modelo fsico necessrio.

Representao Lgica de um Modelo de Dados
Representao Fsica de um Modelo de Dados
Propriedades de uma Coluna

Quando convertemos um modelo lgico em modelo fsico, cada um dos atributos
existentes nas entidades do modelo deve possuir agora um conjunto de propriedades relativas
a uma coluna de uma tabela.
Vamos ver quais so as regras e o que devemos cuidar para a criao do modelo fsico
de dados.
As propriedades que devem ser seguidas neste processo de converso de modelo
lgico em modelo fsico dizem respeito, em sua grande parte, a informaes de implementao
sobre cada coluna da tabela a ser criada.
O nome da coluna ser restringido pelas convenes e regras de metodologia utilizada
ou da administrao de dados da empresa, bem como pelos requisitos semnticos do SGBD.
O tipo de dado ser limitado queles suportados pelo SGBD. Vale ressaltar que cada
SGBD possui caractersticas prprias que determinam os tipos de dados aceitos por ele.
Entretanto, vamos apresentar os principais tipos de dados e o seu significado para que o leitor
familiarize-se com eles.
So tipos de dados que cada campo de uma tabela deve possuir.
Toda coluna deve ter preestabelecido o tipo de dado que pode conter. Por exemplo, se
um campo de uma tabela for do tipo numrico, ele no pode receber dados que forem letras.
A seguir apresentamos uma tabela com os tipos de dados mais usuais.
Modelo Fsico 219

Tipos de Dados Mais Comuns (Padro ANSI)
Armazena valores numricos, em dois bytes binrios,

Smallint
entre o intervalo 32768 e +32767.
Armazena valores numricos, em quatro bytes binrios,
Integer
entre o intervalo 2147483648 e +2147483647.
Armazena valores numricos com ponto flutuante, em oito bytes binrios,
Float entre o intervalo 1.79769313486232E308 e 4.94065645841247E-324 para valores
negativos, 4.94065645841247E-324 e 1.79769313486232E308 para valores positivos.
Armazena valores numricos com no mximo 15 dgitos. Nessa opo deve ser definida
Decimal(n,m)
a quantidade de dgitos inteiros (n) e de casas decimais (m) existentes no campo.
Definir um campo alfanumrico de at n caracteres,
Varchar (n)
em que n deve ser menor ou igual a 254 caracteres.
Definir um campo alfanumrico de n caracteres,
Char (n)
em que n deve ser menor ou igual a 254 caracteres.
Definir um campo alfanumrico de
Long Varchar
comprimento maior que 254 caracteres.
Date Definir um campo que vai armazenar datas.
Time Definir um campo que vai armazenar horas.
Em seguida temos de definir se a existncia de valor de dados obrigatria para a

coluna ou no.
A Opo de Nulo
Por padro, as chaves primrias so definidas como not null, ou seja, no admitem a
inexistncia de valor em qualquer uma das colunas que a compem.
Uma Regra de Validao

Se existir a regra de validao, ela deve conter uma lista de valores vlidos para a
coluna que voc define. As regras de validao podem ser intervalos de valores ou um cdigo
em SQL.
Uma regra de validao uma expresso que estabelece o intervalo de valores
aceitveis que podem ser armazenados em uma coluna.
Observe que a utilizao e a implementao no modelo fsico de tabelas de domnio
para colunas de uma tabela so uma alternativa s regras de validao em alguns casos.
Se a lista de valores vlidos for voltil ou longa, pode ser prefervel usar, em sua
substituio, uma tabela de domnio, visto que uma tabela de domnio ser mais fcil de ser
atualizada no ambiente de produo.

As tabelas de domnio podem e devem ser criadas somente no modelo fsico, pois so
objetos apenas fsicos, uma vez que elas no tm base nem existem no modelo conceitual ou
no modelo lgico.
Se a lista de valores for estvel, o uso da regra de validao pode ser a melhor opo.
Isso significa uma tabela a menos no banco de dados para cada regra usada.
Exemplo de regra de negcios
Regra de negcios: o nmero de itens por nota fiscal est sempre entre 5 e 15.
NumItensNota >= 5 and NumItensNota <= 15
Outro exemplo de regra de validao

Regra de validao StatusNotaFiscal:
F = 'Faturada'
C = 'Cancelado'
Por exemplo, se a empresa no permitisse cancelar uma nota com data de trs dias
antes do dia da prpria nota.
Neste caso, teramos a regra de validao:
NOT StatusNotaFiscal="C"(date < (DataNota+3) AND StatusNotaFiscal = "F")
Valor Padro
Este o valor colocado na coluna durante uma insero de registro na tabela na
ausncia de qualquer outro valor para aquela coluna. Conhecido como valor default do atributo.
Vises de Dados
Uma viso do banco de dados (Database View) uma apresentao personalizada dos
dados armazenados em uma ou mais tabelas. As vises tambm so conhecidas como tabelas
virtuais ou consultas armazenadas.
Modelo Fsico 221

Uma viso pode:
Incluir um subconjunto de colunas de uma tabela do banco.
Incluir colunas de mltiplas tabelas do banco.
Ser baseada em outras vises em vez das tabelas do banco.
Ser consultada, atualizada, inserida e apagada. Todas estas aes afetam os
dados armazenados nas tabelas do banco, com algumas restries, como veremos
no captulo sobre SQL.
Pode ser frequentemente alterada para se adequar s necessidades de alterao
sem exigir uma mudana para a tabela do banco subjacente.
importante lembrar-se de que as vises exibem dados das tabelas do banco, mas no
armazenam dados.
Visto o conceito, podemos ter no modelo fsico de dados a insero de vises de dados
no sentido de criarmos limitaes ou restries ao acesso amplo da aplicao a todos os
dados de uma tabela, ou na anlise de volumes de dados criar vises de subtipos para acesso
distinto de usurios.
As vises podem ser usadas para fornecer um nvel adicional de segurana de tabelas,
ocultar a complexidade de determinados dados, simplificar os comandos para usurios,
fornecer diferentes apresentaes de dados ou armazenar consultas complexas, evitando que
se consumam recursos de processamento elevados desnecessariamente.
As vises de dados somente existem no modelo fsico, e as suas colunas podem ser:
colunas de tabela, colunas de outras vises ou expresses em SQL.
Exemplo de Viso

ndices do Banco de Dados
Um ndice uma estrutura associada a uma tabela que torna a pesquisa mais rpida.
Deve-se levar em conta o emprego de ndices em qualquer coluna frequentemente
utilizada na pesquisa de uma tabela, pois, com essa opo, a durao das pesquisas ser
consideravelmente diminuda.
Os ndices de livro so uma boa analogia; por exemplo, os divisores tabulados repre-
sentam um ndice agrupado e os outros ndices esto dispostos no final do livro.
Entretanto, pode haver uma diminuio de rendimento com a utilizao de ndices.
medida que mais ndices so criados, o banco de dados realiza mais lentamente atualizaes.
Por exemplo, cada vez que uma insero realizada em uma coluna indexada, cada ndice
precisa ser atualizado.
Tecnicamente no h limite ao nmero de ndices, mas quanto maior o nmero deles
mais difcil fica a sua manuteno.
Outro aspecto a considerar para insero de ndices em uma tabela a sua utilizao
nas consultas mais frequentes, pois conforme a disposio e execuo dessa consulta,
principalmente se estivermos utilizando mltiplas junes, esses ndices no sero totalmente
utilizados quando da sua execuo.
Vamos comentar mais sobre este aspecto na abordagem do SQL e sua decomposio
algbrica de comandos.
A escolha de indexao de colunas depende tambm do negcio para o qual o BD foi
modelado, sendo preciso considerar:
As atualizaes ou consultas so muito crticas?
Qual o volume de dados previsto para a tabela?
Quo voltil ser essa tabela?
Para tabelas de um Data Warehouse, por exemplo, quase tudo indexado porque os
requisitos do negcio so consultas rpidas e as tabelas possuem baixa volatilidade.
Chaves Substitutas
comum que a chave primria de uma tabela seja substituta, ou seja, criada uma
coluna que contm um nmero ou cdigo de identificao que um identificador nico, mas
que no tem um significado intrnseco no que se refere ao objeto sendo modelado.
Uma chave substituta artificial e ser usada como uma substituta para uma chave
natural, derivada dos relacionamentos da tabela.
A insero de chaves substitutas no modelo fsico uma realidade, mas deve ser feita
de forma criteriosa, pois implica na existncia de processos de consistncia das colunas que
originalmente compunham a chave primria da tabela, e que foram definidas no modelo lgico.
Modelo Fsico 223

As Generalizaes
O tratamento que deve ser dado converso de generalizaes no modelo fsico envol-
ve o seu mapeamento e clara definio de tabelas para os subtipos, quando eles efetivamente
possurem conjuntos distintos de atributos.
Exemplo
Dada a entidade funcionrio, existe uma variao de atributos para ela, pois h um
ponto bsico para os funcionrios que so engenheiros: eles tm informaes adicionais, que
so dados adicionais no subtipo 'engenheiro', e para o subtipo 'vendedor' existem outros dados
que so diferentes dos dados adicionais de engenheiro.
Como no possvel ter colunas com tamanho e tipo varivel, temos de criar tabelas
para os casos em que as informaes variam.
A tabela funcionrio s pode ter um e somente um conjunto de colunas.
As informaes dos engenheiros sero completadas pela tabela engenheiro.

Se no tivesse atributo diferente para os outros, todos os que no fossem engenheiros
ou vendedores s teriam seus dados na tabela funcionrio.
No possvel um empregado cuja funo engenheiro atuar como tcnico, porque os
elementos no podem se sobrepor.
Os subtipos tornam-se tabelas carregando o identificador do conjunto a que pertencem.

Tabelas do Exemplo
Departamento
CodigoDepto Nome Departamento

1 Engenharia
2 Vendas
3 Administrao
Funcionrio
Matricula Nome Funcao CodigoDepto

101 Luis Sampaio Eng 1
104 Carlos Pereira Vend 2
134 Jose Alves Vend 2
121 Luis Paulo Souza Sec 3
123 Pedro Sergio Doto Vend 1
Engenheiro
Matricula Ajuda de Custo Especialidade

101 1.500,00 Obras Civis
Vendedor
Matricula Hora Extra Despesa Extra Placa carro

104 5,00 255,00 LVW 5289
134 3,50 300,00 LXT 5289
123 2,50 150,00 LOP 5289
Secretaria
Matricula Lingua Estrang Curso

121 Ingls Computao
Colocamos secretria neste exemplo para ampliar a sua viso da implementao dos
subtipos no modelo fsico.
A entidade funcionrio vira uma tabela (regra padro) e os subtipos so transformados
em outras tabelas, carregando a chave primria matrcula.
Efetivado o modelo fsico de dados, estamos aptos a criar o banco de dados projetado
pela gerao de um script de comandos SQL para o SGBD.
Modelo Fsico 225

CREATE TABLE Cliente (
CodCliente int NOT NULL,
NomCliente varchar(30) NULL,
RuaCliente varchar(25) NULL,
CidadeCliente varchar(25) NULL,
PRIMARY KEY (CodCliente ASC) )
CREATE TABLE Agencia (
CodAgencia int NOT NULL,
NomAgencia varchar(15) NULL,
CidadeAgencia varchar(30) NULL,
PRIMARY KEY (CodAgencia ASC) )
CREATE TABLE ContaCorrente (
NumConta numeric(15) NOT NULL,
CodCliente int NOT NULL,
CodAgencia int NOT NULL,
Saldo money NULL,
PRIMARY KEY (NumConta ASC),
FOREIGN KEY (CodAgencia)
REFERENCES Agencia (CodAgencia),
FOREIGN KEY (CodCliente)
REFERENCES Cliente (CodCliente) )
CREATE TABLE Emprestimo (
NumEmprest int NOT NULL,
Valor decimal(11,2) NULL,
CodAgencia int NULL,
CodCliente int NULL,
PRIMARY KEY (NumEmprest ASC),
FOREIGN KEY (CodCliente)
REFERENCES Cliente (CodCliente),
FOREIGN KEY (CodAgencia)
REFERENCES Agencia (CodAgencia) )
CREATE VIEW MaioresContas AS
SELECT ContaCorrente.Saldo, Agencia.NomAgencia
FROM ContaCorrente, Agencia
WHERE Saldo > 100000

Relao entre Modelo Lgico e Modelo Fsico
Esta tabela apresenta as correspondncias entre o modelo lgico e o modelo fsico.
Modelo Lgico Modelo Fsico

Entidade Tabela
Entidade dependente A chave estrangeira faz parte da chave primria
Entidade independente A chave estrangeira no faz parte de sua chave primria
Atributo Coluna
Tipo de dado Restrito aos tipos de dados fsicos
(texto, numrico, alfanumrico etc.) implementados no SGBD a ser utilizado
Chave primria Coluna ndice nico de chave primria
Chave estrangeira Coluna ndice no nico de chave estrangeira
Atributo de busca no chave Coluna ndice no nico
Regra de validao Restrio de integridade
Domnio, ou regra de validao,
Regra de negcio
ou stored procedure ou trigger
Observe em seguida alguns modelos fsicos (inclusive o do nosso estudo de caso).
Modelo Fsico 227

228
Modelo Fsico para Administrao de Cirurgias
Banco de Dados - Projeto e Implementao

Modelo Fsico para Sistema de Vendas (ver captulo de SQL)
Modelo Fsico
229
Modelo Fsico de Cinemas e Filmes

12
MAPEAMENTO DE
OBJETOS - ER
A adoo das metodologias de desenvolvimento orientadas a objetos como um padro
de mercado levou a uma mudana radical na estruturao e organizao de informao.
Contudo, a utilizao de bancos de dados relacionais ainda uma prtica comum e
ser mantida por grande perodo de tempo. Graas necessidade de trabalhar com essas
bases de dados relacionais para o armazenamento persistente de dados, comum adaptar os
modelos de objetos na tentativa de compatibiliz-los com o modelo Entidade-Relacionamento,
mais direcionado ao modelo relacional.
Para piorar ainda mais este quadro, notrio o esforo aplicado no processo de
persistncia manual dos objetos no banco de dados, o que fora os desenvolvedores
de aplicaes a terem de dominar a linguagem SQL e utiliz-la para realizar acessos ao banco de
dados.
Estas duas questes principais levam a uma reduo considervel na qualidade do
produto final, construo de uma modelagem orientada a objetos inconsistente e a um
desperdcio considervel de tempo na implementao manual da persistncia.
Apesar disso, no possvel ignorar a confiabilidade dos Sistemas de Gerenciamento
de Bancos de Dados (SGBDs) relacionais, aps anos de desenvolvimento e ajustes de perfor-
mance que fazem dos bancos de dados relacionais a opo mais eficiente, se comparados
maioria dos SGBDs orientados a objetos disponibilizados no mercado nos dias de hoje.
Para permitir um processo de mapeamento entre sistemas baseados em objetos e
bases de dados relacionais, foram propostas diversas ideias que convergiram para o conceito
de Camada de Persistncia.
Conceitualmente, Camada de Persistncia de Objetos uma biblioteca que permite a
realizao do processo de persistncia (isto , o armazenamento e manuteno do estado de
objetos em algum meio no voltil, como um banco de dados) de forma transparente.
Graas independncia entre a camada de persistncia e o repositrio utilizado,
tambm possvel gerenciar a persistncia de um modelo de objetos em diversos tipos de
repositrio, teoricamente com pouco ou nenhum esforo extra.
Mapeamento de Objetos - ER 231

A utilizao deste conceito permite ao analista trabalhar como se estivesse em um
sistema completamente orientado a objetos - utilizando mtodos para incluir, alterar e remover
objetos e uma linguagem de consulta para SGBDs orientados a objetos, comumente a
linguagem OQL, para realizar consultas que retornam colees de objetos instanciados. Mas
destaque-se somente em um ambiente de SGBDs orientados a objetos e no no ambiente
tradicional de SGBDs relacionais.
As vantagens decorrentes do uso de uma Camada de Persistncia no desenvolvimento
de aplicaes orientadas a objetos so evidentes: a sua utilizao isola os acessos realizados
diretamente ao banco de dados da aplicao, bem como centraliza os processos de
construo de consultas e operaes de manipulao de dados em uma camada de objetos
inacessvel ao programador.
Esse encapsulamento de responsabilidades garante maior confiabilidade s aplicaes
e permite que, em alguns casos, o prprio SGBD ou a estrutura de suas tabelas possam ser
modificados, sem trazer impacto aplicao nem forar a reviso e recompilao de cdigos.
Deixar o programador atuar sem acesso a uma camada de objetos pode provocar erros
de desconhecimento da estrutura de banco de dados sobre a qual ele opera suas instrues,
levando a erros conceituais de projeto de consultas e regras de negcio.
Hoje existem diversos utilitrios que permitem uma independncia de cdigo SQL nas
aplicaes orientadas a objetos e escritas em JAVA, por exemplo. Esses aplicativos realizam o
acesso e manipulao do banco de dados por meio da insero somente das condies de
validao e ou seleo de dados, no envolvendo o programador em altos conhecimentos de
SQL, por exemplo.
De qualquer maneira existe a necessidade de no simplesmente traduzir diretamente
em um script SQL de criao de banco de dados o modelo de classes de um projeto OO, pois
no nos permite nenhuma interao do mundo real de negcios com a persistncia que vamos
utilizar, que um banco de dados relacional. Isso provoca a existncia de mapeamento de
objetos em um modelo de dados Entidade-Relacionamento.
Mapeamento de Objetos para Tabelas (ER)

Para permitir a correta persistncia de objetos em um banco de dados relacional, algo
deve ser feito no tocante forma como os dados sero armazenados.
No decorrer deste captulo, detalhamos algumas sugestes de como feito o mapea-
mento de cada um dos elementos de um objeto: seus atributos, relacionamentos e classes
descendentes (herana).
Ao transpor um objeto para uma tabela relacional, os seus atributos so mapeados em
colunas dessa tabela.

Entretanto, esse processo de mapeamento deve levar em considerao fatores como
os tipos dos dados e o tamanho mximo dos campos (no caso de nmeros e strings).
Tambm importante destacar que, em muitas vezes, os atributos de um objeto no
devem ser obrigatoriamente uma coluna em uma tabela.
Como exemplo, podemos citar atributos que so o valor total de alguma coisa: pois
esse dado poderia ser armazenado no objeto para fins de consulta, mas mant-lo no banco de
dados simplesmente talvez no seja interessante, por tratar-se de um valor que pode ser
obtido por processamento de uma consulta.
Alm disso, existem casos em que um atributo pode ser mapeado para diversas
colunas, pois definido no modelo de forma genrica sem preocupao com composio e
atributos como no modelo relacional (exemplos incluem endereos completos, nome dividido
em 'primeiro nome' e 'sobrenome' no banco de dados) ou vrios atributos que podem ser
mapeados para uma mesma coluna (prefixo e nmero de telefone, por exemplo).
Em uma viso minimalista o mapeamento de objetos em modelo relacional (ER) o da
figura apresentada em seguida:
A transposio do modelo de classes para o modelo relacional tem como objetivo final a
criao da base de dados do sistema, coerente com a modelagem da fase de anlise.
As regras descritas no devem ser interpretadas como "leis" rgidas de transposio,
mas uma indicao suscetvel de adaptao em funo da anlise do problema em questo,
para que possam traduzir rigorosamente a realidade.
Regra 1
Todas as tabelas (ou relaes) devem ter uma chave primria, um conjunto mnimo de
atributos que permitam identificar univocamente cada linha da tabela. No caso de no existirem
atributos que satisfaam esta condio, preciso criar um identificador nico designado por id.

Aqui provavelmente comea um dos problemas da transposio de classes em tabelas,
pois existem classes que contm colees de objetos e classes que tm objetos dentro de
objetos.
Por exemplo, classe departamento que tem incluso um objeto diretor e um conjunto de
objetos seo.
Class Departamento {
String nome;
Empregado Diretor
Seo sees[];
}
Criar na tabela correspondente classe original, por exemplo (departamento), uma

coluna com o nome do atributo/objeto incluso (diretor), desempenhando o papel de chave
estrangeira para a tabela correspondente outra classe (empregado), pois muitas vezes no
representada esta associao no modelo de classes.
Classes com Colees de Objetos

Se a relao entre a classe contentora e a classe contida for um-para-muitos, como no
exemplo anterior, departamento e seo, inserir na tabela correspondente classe contida o
identificador da classe contentora (chave principal da respectiva tabela). Inserir na entidade
seo a chave primria de departamento como chave estrangeira do relacionamento.
Class empregado {
String nome;
Tarefa tarefas[};
..........
}
Se a relao entre a classe contentora (empregado) e a classe contida (tarefa) for

muitos-para-muitos, criar uma terceira tabela que contm duas colunas.
A primeira coluna contm o identificador da classe contentora (empregado), e a
segunda coluna contm o identificador da classe contida (tarefa). Com isso criamos uma
entidade associativa entre as duas entidades relacionadas de muitos-para-muitos.
Regra 2
As tabelas resultam exclusivamente das classes do modelo e das associaes de
muitos-para-muitos.

Regra 3 - Transposio de Associaes Um-para-Um
Nesse tipo de associao uma das tabelas deve herdar como um atributo normal (chave
estrangeira) a chave primria da outra tabela.
A determinao da tabela que herdar a chave estrangeira fica a critrio do analista e
da interpretao que faz da realidade, devendo optar pelo que fizer mais sentido, lembrando
que a associao um-para-um somente pode ser garantida totalmente se a chave estrangeira
for no modelo fsico definida como nica da mesma forma que a chave primria, transfor-
mando-se assim em uma chave candidata.
Em princpio, o esquema da tabela que herdar a chave estrangeira corresponde

classe que tiver um menor nmero de ocorrncias potenciais.
Departamento={IDDEPTO, NOMDEPTO, NOMGERENTE}
Empregado={IDEMPREG, NOMEEMP}
Este caso melhor solucionado com:
Departamento={IDDEPTO, NOMDEPTO, IDEMPREGGERENTE}
Empregado={IDEMPREG, NOMEEMP}
Outra soluo a viabilizao de que esta relao seja transformada em um simples
atributo descritivo do lado da classe maior quando uma das classes possuir somente um
atributo alm de seu identificador.
Livro= {IDLIVRO, TITULO, EDITORA, ANO, COTA}
Cota={COTA}
Se estas duas classes tiverem sido modeladas assim, podem se transformar em uma
nica tabela:
Livro={IDLIVRO, TITULO, EDITORA, ANO, COTA}

Regra 4 - Transposio de Associaes Um-para-Muitos
Numa associao de um-para-muitos a tabela cujos registros so suscetveis de serem
endereados diversas vezes a que herda a referncia da tabela cuja correspondncia
unitria.
Logo, temos ento:

Departamento={IDDEPTO, NOMDEPTO, IDEMPREGGERENTE }
Empregado={IDEMPREG, NOMEEMP, IDDEPTO}
Regra 5 - Transposio de Associaes Um-para-Muitos

com Classe de Associao
Neste caso aplica-se a regra da associao de um-para-muitos (Regra 4) e os atributos
da classe associativa so herdados como atributos normais pela tabela que herda a chave
estrangeira.
Resultado:
Departamento={IDDEPTO, NOMDEPTO, IDEMPREGGERENTE }
Empregado={IDEMPREG, NOMEEMP, IDDEPTO, DATADEADMISSAO, SALARIO}

Regra 6 - Transposio de Associaes Muitos-para-Muitos
A associao de muitos-para-muitos caracteriza-se por fazer a correspondncia mltipla
entre os elementos das classes associadas, sendo o nmero de correspondncias o mximo
permitido pela combinao de dois elementos com ocorrncias variveis (nmero de registos).
Assim, a regra de transposio dessa associao d origem a uma tabela represen-
tativa da associao em que a chave primria composta pelas chaves primrias das tabelas
associadas famosa e j conhecida entidade ou tabela associativa.
Logo, temos as seguintes tabelas:

Aluno={IDALUNO, NOMEALUNO, ENDERECOALUNO}
Disciplina={IDDISCIPLINA, NOMEDISCIPLINA, SIGLADISCIPLINA}
Frequenta={IDDISCIPLINA, IDALUNO}
Regra 7 - Transposio de Associaes Muitos-para-Muitos

com Classe de Associao
Neste caso aplica-se a regra da associao de muitos-para-muitos (Regra 6) e os atri-
butos da classe associativa permanecem na tabela que gerada para mapear a associao.
Fornecedor={CNPJ, NOME, CONTATO}

Produto={CODIGO, NOME}
Fornecimento={CNPJ, CODIGO, DATA, PRECO}

Regra 8 - Transposio de Generalizaes
Nas generalizaes duas situaes distintas podem ocorrer:
1. As classes filhas (subclasses) tm entidade prpria independentemente da classe pai
(superclasse).
Neste caso, a chave primria das tabelas que implementam as classes filhas obtida
por meio dos atributos da prpria tabela.
preciso criar um atributo chave primria para a tabela que implementa a classe pai, e
essa tabela deve ter uma propriedade discriminante (um atributo) que indica a qual das filhas o
registro diz respeito.
Todos os atributos que constituem a chave

primria da tabela que implementa a superclasse
tero de constar nas tabelas que implementam as
subclasses como atributos normais (como chaves
estrangeiras).
Os subtipos tornam-se tabelas carregando
o identificador do conjunto ao qual pertencem na
formao de sua chave primria.
Pessoa={RG, NOME, ENDERECO, TELEFONE}

Aluno={RG ,NUMEROALUNO, CURSO, ANOINGRESSO}
Professor={RG, NUMEROPROFESSOR, CLASSIFICACAO}

2. As classes filhas s tm identidade enquanto associadas classe pai.
Neste caso, a chave primria da tabela que implementa a classe pai obtida por meio
dos atributos da prpria tabela.
Importante entender a equivalncia existente com um modelo lgico de dados neste
caso, pois temos uma generalizao disjunta, em que existem subtipos determinantes com
atributos especficos de cada subtipo. No caso o subtipo oftalmologista possui um atributo
especfico que inserido em um nova entidade que fica associada ao subtipo.
Tambm necessrio criar uma propriedade discriminante para indicar a qual das
subclasses o registro diz respeito. Neste caso a propriedade determinante pode ser imple-
mentada como uma regra de negcio. Mas quando o valor de especialidade, por exemplo, for
igual a oftalmologista, a condio para a existncia do relacionamento.
As tabelas correspondentes s classes filhas herdaro a chave primria da tabela que
implementa a classe pai, caracterizando relacionamentos um-para-um.
Mdico={CRM, NOMEMEDICO, ENDEREO, TELEFONE, ESPECIALIDADE}
Especializao={CRM, ESPECIALIZACAO}

Regra 9 - Transposio de Agregaes
Existem dois tipos de agregao:
1. As agregaes simples
No caso, a agregao tem como objetivo indicar a existncia de uma relao em que os
elementos da classe agregada fazem parte de um todo, representado pela classe agregadora.
A transposio para o modelo relacional obedece s regras de transposio das

associaes com a mesma multiplicidade (Regras 3, 4 e 6).
O que temos um formato de composio, ou seja, relacionamentos distintos em
entidades dependentes, que s tm sentido quando da existncia da entidade da qual
dependem. So na realidade entidades fracas.
Carro={REGISTRO, MARCA, MODELO}
Roda={REGISTRO, TIPORODA, TIPOPNEU}
Direo={REGISTRO, DIAMETRO, MATERIAL}
O que corresponde ao modelo seguinte:

2. As composies
A composio tambm uma agregao, mas com um sentido de dependncia mais
forte. Neste caso, os elementos agregados fazem parte da composio que os une. No caso
de a composio ser eliminada, tambm os seus componentes desaparecem.
Na transposio para o relacional, a chave primria das tabelas que representam as
classes componentes composta pela respectiva chave primria, associada chave primria
da tabela referente classe composio.
NotaFiscal={NUMNOTA, DATANOTA}
ItemNota={NUMNOTA, NUMEROITEM, PRODUTO, PRECO}
Consideraes Finais
Acreditamos que com o material disposto neste captulo auxiliamos sensivelmente
o trabalho de converso, transposio de classes de dados para um modelo Entidade-
-Relacionamento.
Devemos considerar que mesmo com a existncia nas ferramentas de modelagem UML
de processo para converso automtica com gerao de scripts de bancos de dados a partir
do modelo de classes, ela no supre a aderncia aos conceitos de um modelo ER.
Com isso criam-se situaes que no correspondem ao que seria normalmente mode-
lado utilizando os conceitos e extenses do modelo Entidade-Relacionamento.
Por este motivo recomendvel realizar sempre manualmente essa transposio.

13
LGEBRA RELACIONAL
lgebra Relacional e Operaes Relacionais

A lgebra relacional uma linguagem de consulta procedural. Ela consiste em um
conjunto de operaes que tomam uma ou duas tabelas como entrada e produzem uma nova
tabela como resultado.
Essas operaes baseiam-se na teoria dos conjuntos (as tabelas correspondem a
conjuntos).
Existem cinco operaes fundamentais na lgebra relacional que so selecionar, pro-
jetar, renomear, (unrias) - produto cartesiano, unio e diferena de conjuntos (binrias).
Alm das operaes fundamentais, existem outras, como interseo de conjuntos, liga-
o natural, dentre outras, que so definidas em termos das operaes fundamentais.
Toda operao relacional opera (age) sobre um ou mais conjuntos de dados e fornece
como resultado um novo conjunto. Devido a essa caracterstica, podemos combinar mais de
uma operao relacional em uma nica expresso algbrica, fazendo com que o resultado de
uma operao seja utilizado como entrada para outra operao, aumentando com isso
grandemente o poder dessa linguagem de consulta.
O entendimento e o domnio das operaes de lgebra relacional so fundamentais
para a compreenso da linguagem SQL e um auxiliar excelente no momento de construo de
consultas, pois dota o analista de conhecimento sobre a operao interna que realizada pelo
Sistema Gerenciador de Banco de Dados, tanto no tocante recuperao dos dados como na
anlise da performance que a execuo de um comando SQL vai possuir conforme a construo
utilizada na consulta.
Todo o comando SQL pode ser desmembrado em operaes de lgebra relacional,
desta forma a visualizao da sequncia de execuo das operaes de lgebra relacional
possibilita ao analista compreender a utilizao de ndices em determinadas consultas de SQL
mais complexas, ou que envolvam vrias tabelas.

Os Operadores de lgebra Relacional
A lgebra relacional uma linguagem formal composta por um conjunto de operadores
que permite expressar qualquer operao de manipulao de dados em um banco de dados
relacional. Esses operadores so classificados de vrias formas conforme a funcionalidade.
As classificaes so as seguintes:
Quanto sua origem:
Fundamentais: cinco operadores so ditos primitivos ou fundamentais, ou seja,
atravs deles qualquer expresso de consulta de dados possvel. So eles:
seleo, projeo, produto cartesiano, unio e diferena.
Derivados: derivam dos operadores fundamentais. So definidos para facilitar a
especificao de certos procedimentos. So eles: interseco, juno (normal e
natural) e diviso.
Especiais: operadores que no se enquadram nos itens anteriores. So eles:
renomeao e alterao.
Quanto ao nmero de relaes operandas:
Unrios: operam em uma nica tabela. So eles: seleo, projeo, renomeao e
alterao.
Binrios: operam em duas tabelas. So eles: unio, interseo, diferena, produto
cartesiano, juno e diviso.
Quanto origem da rea da matemtica:
Teoria dos conjuntos: operadores usuais da teoria de conjuntos da matemtica.
So eles: unio, interseo, diferena e produto cartesiano.
Especiais: operadores adicionais, definidos pela lgebra relacional para manipula-
o de dados. So eles: seleo, projeo, juno, diviso, renomeao e alterao.
Alm desses operadores, definido tambm o operador de atribuio que permite
atribuir o resultado de uma expresso da lgebra a uma tabela.
Para que possamos entender mais facilmente as operaes de lgebra relacional,
vamos utilizar algumas tabelas para a explanao e apresentao de exemplos.
Estas so as tabelas que apresentamos em seguida, mas no se preocupe que vamos
apresent-las novamente sempre que for necessrio ao bom entendimento deste assunto.
Estamos interessados em obter informaes armazenadas nesse banco de dados (as
trs tabelas) e para isso devemos formular expresses em lgebra relacional combinando
operaes bsicas, as quais vamos apresentar uma a uma de forma simplificada e tambm
grfica, para obtermos entendimento de seu significado prtico e notao clssica.
lgebra Relacional 243

Tabela Cargo Tabela Departamento
CdCargo NumCargo VlrSalario CdDepto NumDepto RamalTel
C1 Aux Vendas 350,00 D1 Assist.Tcnica 2246
C3 Vendedor 800,00 D2 Estoque 2589
C7 Diretor 2500,00 D3 Administrao 2772
C2 Vigia 400,00 D4 Segurana 1810
C5 Gerente 1000,00 D5 Vendas 2599
C4 Aux Cobrana 250,00 D6 Cobrana 2688
Tabela Funcionrio
134 Jose Alves 23/5/2002 M C5 D1
Vamos imaginar ento que desejamos obter o nome completo de todos os funcionrios
que existem em nosso banco de dados.
Para isso vamos utilizar uma operao denominada projeo, aplicada sobre a tabela
funcionrio que contm esta informao.
Operao de Projeo
Na literatura que trata de bancos de dados indica-se por (a letra grega pi) e produz
um conjunto (tabela) em que h um elemento para cada elemento (linha) do conjunto (tabela)
de entrada, e a estrutura dos membros do conjunto (tabela) resultante definida nos argu-
mentos da operao.
Conjunto de Entrada (Tabela)
nome coluna1, nome coluna2, ..., nome colunan (NOME TABELA)
Argumentos da Operao
Pode ser entendida como uma operao que filtra as colunas de uma tabela. Por operar
em apenas um conjunto de entrada, a projeo classificada como uma operao unria.

Apesar de que vamos apresentar operaes conjuntas, convm salientar que o ope-
rador de projeo sempre atua em uma tabela somente, seja ela do nosso banco de dados ou
uma tabela resultante de outra operao relacional executada, motivo pelo qual a denominao
de operao unria.
Ento, em nosso exemplo temos:
NomeFunc (FUNCIONRIO)
Argumentos da Operao
Este o formato do operador, projeo da coluna NomeFunc da tabela funcionrio.

Vamos agora olhar a operao e o resultado na tabela para melhor entend-la.

134 Jose Alves 23/5/2002 M C5 D1
NomeFunc
Luis Sampaio
Carlos Pereira
Jose Alves
Luis Paulo Souza
Marta Silveira
Ana Luiza Magalhes
Pedro Sergio Doto
Larissa Silva
Roberto Fernandes
Sergio Nogueira

Observe que a tabela resultante obedece regra de ter somente as colunas constantes
no comando de projeo.
Vamos ver mais um exemplo da mesma tabela. Digamos que queremos saber alm do
nome, o sexo de todos os funcionrios.
O formato do comando de projeo ento seria:
NOMEFUNC, SEXO (FUNCIONRIO)
E o resultado aplicado na mesma tabela funcionrio apresenta como tabela resultante a

seguinte:
NomeFunc Sexo
Luis Sampaio M
Carlos Pereira M
Jose Alves M
Luis Paulo Souza M
Marta Silveira F
Ana Luiza Magalhes F
Pedro Sergio Doto M
Larissa Silva F
Roberto Fernandes M
Sergio Nogueira M
Grave bem, projeo a operao que recupera colunas determinadas (especificadas)

de uma tabela em um banco de dados relacional.
NOME COLUNA1, NOME COLUNA2, ..., NOME COLUNAN (NOME TABELA)
Praticamente devemos considerar que toda operao sobre tabelas de um banco de

dados, quando queremos obter algum resultado visvel, ou seja, queremos ver algum dado
resultante, necessita utilizar a operao de projeo.
A operao de projeo a efetivao de resultado de qualquer tipo de consulta.
Devemos lembrar sempre que as colunas utilizadas como argumento da operao devem
obrigatoriamente existir na tabela de entrada da operao.
Entretanto, existem casos em que queremos descartar algumas ocorrncias do conjunto
de entrada, ou seja, da tabela de entrada da operao. Por exemplo, se desejamos saber os
funcionrios que so do sexo masculino somente.
Neste caso usamos a operao de seleo, que alguns autores e professores destacam
como sendo de restrio.

Operao de Seleo
Indicada por (a letra grega sigma), uma operao que, para um conjunto inicial
fornecido como entrada, produz um subconjunto estruturalmente idntico, mas apenas com os
elementos do conjunto entrada que atendem a uma determinada condio (tambm chamada
de predicado).
Predicado (TABELA)
Predicado da Operao
A seleo pode ser entendida como a operao que filtra, seleciona as linhas de uma
tabela, e tambm uma operao de projeo, uma operao unria, operando em um nico
conjunto de dados.
Para melhor visualizar a estrutura da operao, vamos apresentar como ela sintatica-
mente no caso de desejarmos obter os funcionrios do sexo masculino.
Sexo='M' (FUNCIONRIO)
Predicado da Operao
A execuo dessa operao produz uma tabela resultante, que nada mais do que o
conjunto de ocorrncias de funcionrios que atendem condio de a coluna sexo possuir o
valor 'M', ou seja, os funcionrios do sexo masculino.
Um detalhe importante que esse subconjunto gerado possui todos os atributos do
conjunto de entrada (tabela funcionrios).
Seno, vejamos:

134 Jose Alves 23/5/2002 M C5 D1

134 Jose Alves 23/5/2002 M C5 D1
Analisando o resultado, efetivamente comprovamos que retornaram todas as colunas

da tabela original, funcionrios, das linhas desta tabela que satisfizeram a condio, predicado,
Sexo='M'.
Agora, considerando que desejamos saber somente o nome e a data de admisso dos
funcionrios de sexo masculino, o que fazer?
Neste caso comeamos a utilizar operaes combinadas, pois queremos realizar a
seleo dos dados, porm projetar somente duas colunas do resultado dessa seleo.
Em primeiro lugar devemos entender as precedncias de operaes quando as utili-
zamos combinadas.
Se voc quiser projetar, ver colunas determinadas, especficas de uma tabela, para uma
determinada condio, primeiro deve selecionar as linhas que atendem a esta condio, para
ento desse resultado realizar a projeo das colunas desejadas.

Vejamos ento graficamente:
Vamos ver agora o que acontece com as tabelas, que resulta essa operao combinada
e qual a sua sintaxe:
NOMEFUNC,DTADMISSO ( SEXO='M' (FUNCIONRIO))

Comparando o grfico com a sintaxe do comando para a operao, podemos observar
que a escrevemos de cima para baixo, ou seja, top-down.
Este esquema de precedncia deve sempre ser considerado, e aconselhamos por
prtica utilizar um projeto grfico para a execuo de operaes relacionais, pois simplifica o
entendimento e proporciona maior clareza de entendimento das operaes em si.
Vamos ilustrar novamente para fixar agora as tabelas do incio at o fim da operao:
Tabela Inicial - Funcionrios

134 Jose Alves 23/5/2002 M C5 D1
Execuo da operao de seleo - Sexo='M' (FUNCIONRIO) resulta a tabela tempo-

rria, intermediria, apresentada em seguida:

134 Jose Alves 23/5/2002 M C5 D1
Execuo da operao de projeo da tabela intermediria:
NOMEFUNC,DTADMISSO ( SEXO='M' (FUNCIONRIO))

em que Sexo='M' (Funcionrio) representa a tabela intermediria, e temos como resultado
final da operao a tabela seguinte:
NomeFunc DtAdmisso
Luis Sampaio 10/8/2003
Carlos Pereira 2/3/2004
Jose Alves 23/5/2002
Luis Paulo Souza 10/12/2001
Pedro Sergio Doto 29/6/2003
Roberto Fernandes 15/10/2003
Sergio Nogueira 10/2/2000
J aconteceu de perguntarem em aulas algo como:

Mas e a coluna sexo, por que no apareceu, se o argumento de seleo?
Para muitos pode parecer uma pergunta sem sentido, mas comum alunos se embara-
lharem com a conjuno de comandos nas operaes relacionais.
A razo que deve ficar clara que na tabela resultado somente as colunas projetadas, que
fazem parte do argumento do comando de projeo, que o ltimo a ser executado, estaro
no resultado final.
Por estes motivos sempre so utilizados esquemas grficos tanto para explicar como
para projetar operaes e queries.
A lgebra relacional considerada uma linguagem procedural, uma vez que requer
sempre a existncia de definio quanto ordem em que as operaes sero realizadas.
Linguagens em que apenas definimos o resultado que desejado, sem fazer meno
nenhuma forma e sequncia de como isso deve ser feito, so chamadas de linguagens
no procedurais.

Suponha agora que precisamos obter o nome completo, a data de admisso, o nome do
cargo e o salrio de cada funcionrio cadastrado.
Observe que para essa consulta temos um diferencial que podemos dizer que um fato
novo na utilizao de operaes relacionais at o momento, que a referncia a colunas de
mais de uma tabela, uma vez que o nome e a data de admisso fazem parte da tabela
funcionrio, enquanto o nome do cargo e salrio existem apenas na tabela cargos.
Isso seria problemtico, pois as duas operaes que conhecemos at o momento so
unrias, e temos necessidade de combinar os dados de mais de uma tabela neste caso.
Como resolver este impasse?
Para situaes como esta existe uma operao chamada produto cartesiano que pode
ser ento utilizada conjuntamente com outras operaes para obtermos o resultado desejado.
Produto Cartesiano
A notao adotada em matemtica (conjunto1 conjunto2) para representar o produto
cartesiano entre dois conjuntos (uma operao binria) indica tipicamente a natureza dessa
operao: o resultado de um produto cartesiano de duas tabelas uma terceira tabela com as
combinaes possveis entre os elementos das tabelas originais.
Essa tabela resultante possui um nmero de colunas que igual soma do nmero de
colunas das duas tabelas iniciais, e um nmero de linhas igual ao produto do nmero de linhas
das duas tabelas.
Se fizermos o produto cartesiano de uma tabela X que possua quatro colunas e dez
linhas com uma tabela Y em que existem trs colunas e seis linhas, a tabela resultante ter:
4 colunas + 3 colunas = 7 colunas
10 linhas * 7 linhas = 70 linhas.
Porque cada linha da tabela resultante corresponder concatenao de uma linha da

primeira tabela com uma linha da segunda.
Ento, a primeira linha da tabela X ser concatenada com sete linhas da tabela Y, a
segunda linha da tabela X ser concatenada com as mesmas sete linhas da tabela Y e assim
por diante, chegando a um total de 70 linhas na tabela resultado.
O produto cartesiano no muito usado como um fim em si mesmo, ou seja, dificil-
mente estaremos interessados em saber todas as combinaes possveis entre as linhas de
duas tabelas, pois a utilidade desse tipo de conhecimento muito discutvel, apesar de
existirem casos de sua utilizao prtica.

Entretanto, esta a forma primitiva de que dispomos para unir informaes de duas
tabelas heterogneas para posterior processamento.
Se desejarmos obter apenas algumas das combinaes resultantes de um produto
cartesiano, ser necessrio executar uma operao de seleo do seu resultado, de forma a
descartar as combinaes que no so de interesse entre as linhas das tabelas originais.
Essa operao mostra todos os atributos das relaes envolvidas.
A forma geral :
Tabela A Tabela B
Antes que perguntem, a resposta no.

No existe nenhum smbolo grego associado a esta operao relacional. O smbolo
exatamente o operador entre o nome das tabelas participantes.
importante ressaltar neste ponto a questo colunas do resultado de um produto
cartesiano, pois apresentamos a regra numrica para o nmero de colunas, porm no
apresentamos de forma bem clara ainda a composio dessas colunas.
Se considerarmos a estrutura de duas de nossas tabelas, por exemplo, a tabela
funcionrios e a tabela cargo:
A tabela funcionrios possui os seguintes atributos:
NumReg Sexo
NomeFunc CdCargo
DtAdmissao CdDepto
A tabela cargo possui os seguintes atributos:
CdCargo
NumCargo
VlrSalario
Seguindo o raciocnio, temos seis colunas na primeira tabela e trs colunas na segunda
tabela, logo o resultado final ter nove colunas.
Como elas vo aparecer? Em que ordem? Quais sero as colunas resultantes?
A tabela resultante ter as seguintes colunas:
NumReg
NomeFunc
DtAdmissao
Sexo

CdCargo
CdDepto
CdCargo
NumCargo
VlrSalario
Exatamente nesta ordem, sendo esta a estrutura final de atributos da tabela resultado.
Agora vamos ver como fica o resultado, visualizando as tabelas de entrada da operao
e a tabela de sada com dados do exemplo:
Funcionrios Cargo
Tabela Funcionrios

134 Jose Alves 23/5/2002 M C5 D1
Tabela Cargos

C3 Vendedor 800,00
C7 Diretor 2500,00
C2 Vigia 400,00
C5 Gerente 1000,00

A tabela resultado ser:
NumReg NomeFunc DtAdmisso Sexo CdCargo CdDepto CdCargo NumCargo VlrSalario

101 Luis Sampaio 10/8/2003 M C3 D5 C1 Aux Vendas 350,00
101 Luis Sampaio 10/8/2003 M C3 D5 C3 Vendedor 800,00
101 Luis Sampaio 10/8/2003 M C3 D5 C7 Diretor 2500,00
101 Luis Sampaio 10/8/2003 M C3 D5 C2 Vigia 400,00
101 Luis Sampaio 10/8/2003 M C3 D5 C5 Gerente 1000,00
101 Luis Sampaio 10/8/2003 M C3 D5 C4 Aux Cobrana 250,00
104 Carlos Pereira 2/3/2004 M C4 D6 C1 Aux Vendas 350,00
104 Carlos Pereira 2/3/2004 M C4 D6 C3 Vendedor 800,00
104 Carlos Pereira 2/3/2004 M C4 D6 C7 Diretor 2500,00
104 Carlos Pereira 2/3/2004 M C4 D6 C2 Vigia 400,00
104 Carlos Pereira 2/3/2004 M C4 D6 C5 Gerente 1000,00
104 Carlos Pereira 2/3/2004 M C4 D6 C4 Aux Cobrana 250,00
...... ......... ....... ...... ...... ...... ....... ......... .....
...... ........ ...... ..... ..... ..... ....... ......... ......
22 Sergio Nogueira 10/2/2000 M C2 D4 C1 Aux Vendas 350,00
22 Sergio Nogueira 10/2/2000 M C2 D4 C3 Vendedor 800,00
22 Sergio Nogueira 10/2/2000 M C2 D4 C7 Diretor 2500,00
22 Sergio Nogueira 10/2/2000 M C2 D4 C2 Vigia 400,00
22 Sergio Nogueira 10/2/2000 M C2 D4 C5 Gerente 1000,00
22 Sergio Nogueira 10/2/2000 M C2 D4 C4 Aux Cobrana 250,00
Evidentemente no apresentamos todas as linhas da tabela resultado, pois no caberia

nesta pgina, mas a demonstrao de que para cada linha da tabela funcionrios combinamos
todas as linhas existentes na tabela cargo.
Acreditamos que seja possvel o leitor compreender o resultado final desta operao.
Agora vamos estudar uma aplicao de operaes relacionais em que possamos utilizar
o produto cartesiano combinado com outras operaes, e a forma como utiliz-las.
Supondo que desejamos saber o nome e a data de admisso dos funcionrios que tm
cargo de auxiliar de cobrana.
A primeira operao a ser realizada um produto cartesiano entre a tabela funcionrios
e a tabela cargos, o que est evidente pelo que estudamos at este ponto.
A segunda operao selecionar do resultado do produto cartesiano as linhas que
satisfazem a condio de Nome do Cargo se igual a "auxiliar de cobrana" e alguma coisa a
mais que vamos deixar como dvida at este ponto:
NumCargo='Auxiliar de Cobrana'

A terceira operao a projeo das colunas nome do funcionrio e data de admisso
do resultado desta seleo.
Ento, graficamente:
Se estruturarmos o comando em uma nica sentena, temos:
NOMEFUNC,DTADMISSO ( NUMCARGO='AUXILIAR DE COBRANA' (FUNCIONRIOS CARGO))
Cabe o questionamento: est correta esta aplicao de produto cartesiano combinada?

Para que voc entenda, vamos colocar a tabela resultante para que possamos estudar
o erro que acontece pela falta de um argumento no contexto todo.
NumReg NomeFunc DtAdmissao Sexo CdCargo CdDepto CdCargo NumCargo VlrSalario

101 Luiz Sampaio 10/08/2003 M C3 D5 C4 Aux Cobrana 250,00
134 Jose Alves 25/05/2002 M C5 D1 C4 Aux Cobrana 250,00
121 Luis Paulo Souza 10/12/2001 M C3 D5 C4 Aux Cobrana 250,00
195 Marta Silveira 05/01/2002 F C1 D5 C4 Aux Cobrana 250,00
139 Ana Luiza Magalhes 12/01/2003 F C4 D6 C4 Aux Cobrana 250,00
123 Pedro Sergio Doto 29/06/2003 M C7 D3 C4 Aux Cobrana 250,00
148 Larissa Silva 01/06/2002 F C4 D6 C4 Aux Cobrana 250,00
115 Roberto Fernando 15/10/2003 M C3 D5 C4 Aux Cobrana 250,00
22 Sergio Nogueira 10/02/2000 M C2 D4 C4 Aux Cobrana 250,00
"Voc cometeu uma operao ilegal e o programa ser fechado. Reinicie o computador."
Felizmente este um livro e no aquele programa conhecido.

Como o produto cartesiano junta todas as linhas da primeira tabela com todas as linhas
da segunda tabela, o resultado foi que todos os funcionrios aparecem no resultado da
primeira operao, conduzindo-nos a um resultado final errado, pois teremos uma tabela final
com o contedo apresentado em seguida:
NomeFunc DtAdmisso
Luis Sampaio 10/08/2003
Carlos Pereira 02/03/2004
Jose Alves 23/05/2002
Luis Paulo Souza 10/12/2001
Marta Silveira 05/01/2002
Ana Luiza Magalhes 12/01/2003
Pedro Sergio Doto 29/06/2003
Larissa Silva 01/06/2002
Roberto Fernandes 15/10/2003
Sergio Nogueira 10/02/2000
Talvez voc ache estranho ensinar por meio de erros, mas a prtica levou a esta
metodologia neste caso, pois faz com que o estudante fixe as regras com maior amplitude.
Vejamos o que faltou:
Faltou informar a condio de que queramos somente os funcionrios com o cargo de
auxiliar de cobrana.
No comando que realizamos, especificamos somente que o nome do cargo deveria ser
auxiliar de cobrana, no especificando de nenhuma forma como associar que este era o cargo
ao funcionrio que efetivamente o possui.
Olhando as tabelas, vemos que somente os funcionrios cujo atributo CdCargo for igual
a 'C4' que possuram este cargo de auxiliar de cobrana.
Para descobrir o cargo verdadeiro de um funcionrio, observando as tabelas e as
chaves estrangeiras, conclui-se que necessrio que o atributo da tabela funcionrio CdCargo
seja igual ao atributo CdCargo da tabela resultante do produto cartesiano.
Funcionrio.CdCargo = Cargo.CdCargo
Aqui entram as referncias de cada tabela na identificao do atributo, pois no pode-

mos ser ambguos ao nos referirmos s colunas atributos de tabelas.
Desta forma, o critrio de seleo correto uma condio composta de dois critrios:
O campo NumCargo deve ser igual a 'Auxiliar de Cobrana' e Funcionrio.CdCargo =
Cargo.CdCargo.
Como se representa ento uma dupla condio, uma condio com um conectivo lgico 'E'?

O smbolo utilizado na lgebra relacional o circunflexo '^', tradicionalmente conhecido
por representar este conectivo lgico.
Vamos ento montagem de nosso comando, agora de forma correta.
NOMEFUNC,DTADMISSO ( NUMCARGO='AUXILIAR DE COBRANA' ^ FUNCIONRIO.CDCARGO = CARGO.CDCARGO

(FUNCIONRIOS CARGO))
Para que no restem dvidas, observe a representao grfica do esquema da consulta

agora corrigida.
Vamos para um outro exemplo simples para aumentarmos a fixao do contedo dessa
operao relacional.
Sejam as tabelas de uma cantina, como num exemplo do professor Francisco Rapchan,
em sua apostila de lgebra relacional, o qual achei muito interessante. Uma cantina, seus
clientes e suas contas de fiado (pagamento futuro, conta pendurada). Temos neste caso duas
tabelas, a tabela de clientes e a de fiados, as famosas continhas de botequim.
Observao: No Rio de Janeiro muito comum ter conta em um botequim e este exemplo
adapta-se perfeitamente.
Vamos usar tabelas pequenas de poucas ocorrncias para facilitar a visualizao.
Tabela Clientes Tabela Contas Penduradas (Fiado)
CodCliente NomCliente CodCliente Valor

1 Luis Sampaio 1 50,00
2 Carlos Pereira 2 43,00
3 Jose Alves 3 28,00
4 Luis Paulo Souza 4 15,00

Se desejarmos uma consulta com o nome dos clientes e o valor que esto devendo,
devemos realizar um conjunto de operaes combinadas, utilizando-nos de produto cartesiano
como base das operaes.
CLIENTE.CODCLIENTE = CONTA.CODCLIENTE (CLIENTES CONTA)

Com esta operao obtemos os clientes e suas contas.

Mas como queremos no resultado somente o nome do cliente e o valor que ele est
devendo, devemos completar este comando com a projeo das colunas que desejamos no
resultado final:
NOMCLIENTE,VALOR ( CLIENTE.CODCLIENTE= CONTA.CODCLIENTE (CLIENTES CONTA))

E teremos, ento, como resultado a tabela seguinte:
NomCliente Valor
Luis Sampaio 50,00
Carlos Pereira 43,00
Jose Alves 28,00
Luis Paulo Souza 15,00
Voltando nossa mania de visualizar tudo graficamente, observe o grfico:

importante salientar neste ponto que o produto cartesiano no possui cardinalida-
de, ou seja, no importa a ordem em que as tabelas so dispostas no comando, o resultado
prtico ser sempre o mesmo.
Entretanto, a ordem de disposio das colunas no seu resultado muda conforme a
ordem em que as tabelas forem escritas na operao.
Logo, a sequncia das colunas para Cliente Conta diferente da sequncia para
Conta Cliente:
Cliente Conta Conta Cliente
CodCliente NomCliente CodCliente Valor CodCliente Valor CodCliente NomCliente

1 Luis Sampaio 1 50,00 1 50,00 1 Luis Sampaio
1 Luis Sampaio 2 43,00 1 50,00 2 Carlos Pereira
1 Luis Sampaio 3 28,00 1 50,00 3 Jose Alves
1 Luis Sampaio 4 15,00 1 50,00 4 Luiz Paulo Souza
2 Carlos Pereira 1 50,00 2 43,00 1 Luis Sampaio
2 Carlos Pereira 2 43,00 2 43,00 2 Carlos Pereira
2 Carlos Pereira 3 28,00 2 43,00 3 Jose Alves
2 Carlos Pereira 4 15,00 2 43,00 4 Luiz Paulo Souza
3 Jose Alves 1 50,00 3 28,00 1 Luis Sampaio
3 Jose Alves 2 43,00 3 28,00 2 Carlos Pereira
3 Jose Alves 3 28,00 3 28,00 3 Jose Alves
3 Jose Alves 4 15,00 3 28,00 4 Luiz Paulo Souza
4 Luis Paulo Souza 1 50,00 4 15,00 1 Luis Sampaio
4 Luis Paulo Souza 2 43,00 4 15,00 2 Carlos Pereira
4 Luis Paulo Souza 3 28,00 4 15,00 3 Jose Alves
4 Luis Paulo Souza 4 15,00 4 15,00 4 Luiz Paulo Souza
Agora existem alguns casos em que necessitamos realizar produto cartesiano.

Com a mesma tabela, ou seja, a tabela vai aparecer duas vezes na mesma operao.
Se utilizarmos o mesmo nome de tabela, vamos provocar uma ambiguidade, inviabilizando o
comando, ou melhor, a operao relacional desejada.
Para este caso existe a operao de renomear, ou rename, que atribui tabela uma
segunda nomenclatura.
Operao Renomear
A operao de renomear uma tabela utilizada sempre que ela aparece mais de uma
vez em uma consulta. Como ao contrrio dos bancos de dados o resultado de uma operao

em lgebra relacional no tem nome, tambm utilizamos a operao rename para nomear um
resultado.
Essa operao representada pela letra grega (rho).

O formato geral :
<novo nome> (TABELA)

Por exemplo:
Cliente2 (CLIENTE)
Este operador permite agora que se realizem operaes como Cliente2 Cliente.
Vamos criar um exemplo em que possamos visualizar e entender mais claramente a
operao.
Seja a tabela cliente seguinte:

Pode parecer uma consulta bem ridcula, mas serve aos nossos propsitos de explicar
a utilizao da operao renomear:
Quais so os clientes que moram na mesma rua e cidade que Carlos Pereira?
Pela simples leitura da tabela voc vai responder consulta, mas queremos realiz-la
com instrues de lgebra relacional, ento vamos l.
Em primeiro lugar vamos definir como selecionar os dados relativos a Carlos Pereira.
Devemos selecionar a linha que contm os dados de Carlos Pereira e projetar as
colunas rua e cidade.
O comando seguinte o que efetiva a seleo do cliente especfico:
NOMCLIENTE = "CARLOS PEREIRA" (CLIENTE)

Em seguida devemos projetar as colunas desejadas:
RUACLIENTE,CIDADECLIENTE ( )

Concluindo o comando, temos:
RUACLIENTE,CIDADECLIENTE ( NOMCLIENTE = "CARLOS PEREIRA" (CLIENTE))

No se esquea de que devemos fechar dois conjuntos de parnteses.
Feito isso, devemos pensar que contra essa operao, ou melhor, tomando como
base de tudo essa operao, vamos descobrir quem tem a mesma rua e cidade que o nosso
amigo Carlos Pereira.
Vamos realizar o produto cartesiano do resultado obtido com a tabela cliente, porm
renomear para que no existam ambiguidades em nossa consulta.
Cliente2 (CLIENTE)
Vamos realizar a esquematizao grfica da ordem de execuo dos comandos para
que possamos entender melhor e mais claramente esta consulta, at certo ponto complexa em
sintaxe:
O primeiro passo j demos que foi selecionar e projetar as colunas de rua e endereo
da tabela cliente para o cliente = "Carlos Pereira", que no grfico chamamos de resultado1.
RuaCliente CidadeCliente
Rua B Niteri
O segundo passo realizarmos o produto cartesiano entre o resultado do primeiro

passo e a tabela cliente agora renomeada como Cliente2, que no grfico denominamos de
Resultado2.
( NOMCLIENTE ="CARLOS PEREIRA" (CLIENTE)) ( Cliente2 (CLIENTE)) Resultado2
Como terceiro passo devemos selecionar as linhas do resultado2 em que a seguinte

condio satisfeita.
CLIENTE2.RUACLIENTE = CLIENTE.RUACLIENTE ^ CLIENTE2.CIDADECLIENTE = CLIENTE.CIDADECLIENTE (Resultado2)

Resultado3
As linhas iguais s de Carlos Pereira sero selecionadas e teremos o Resultado3.

O quarto passo a projeo das colunas do Resultado3 que nos interessam, sendo
NomCliente, RuaCliente e CidadeCliente.
CLIENTE2.NOMCLIENTE,CLIENTE2.RUACLIENTE,CLIENTE2.CIDADECLIENTE (Resultado3)

Observe o grfico e depois leia o comando completo, prestando ateno nos parn-
teses que separam cada bloco.
CLIENTE2.NOMCLIENTE,CLIENTE2.RUACLIENTE,CLIENTE2.CIDADECLIENTE (
CLIENTE2.RUACLIENTE = CLIENTE.RUACLIENTE ^ CLIENTE2.CIDADECLIENTE = CLIENTE.CIDADECLIENTE (
( NOMCLIENTE ="CARLOS PEREIRA" (CLIENTE)) ( Cliente2 (CLIENTE))
)
)
Destacamos os parnteses para que voc possa identific-los em seu fechamento.
Agora, se analisarmos corretamente esta aplicao das operaes relacionais, pode
surgir a questo:
Por que a resposta veio com o Carlos Pereira novamente?
No h como ver os clientes sem ver a linha relativa a Carlos Pereira?
A resposta sim. possvel ver somente os clientes que tm a mesma rua e cidade de
Carlos Pereira sem ter de mostrar os dados de Carlos Pereira.
Basta acrescentar condies de seleo ao terceiro passo apresentado. Vamos inserir a
condio de que o NomCliente seja diferente de 'Carlos Pereira'.

Qual a simbologia utilizada para expressar esta condio?
NomCliente <> 'Carlos Pereira'
Entretanto, devemos cuidar da montagem desta condio porque em alguns casos

pode implicar a insero de novo conjunto de parnteses na sintaxe.
Ento vejamos: a primeira condio que composta de dois elementos de seleo
acrescida de um terceiro elemento pela conjuno e (^).
(Cliente2.RuaCliente = Cliente.RuaCliente ^ Cliente2.CidadeCliente = Cliente.CidadeCliente)

^ Cliente2.NomCliente <>'Carlos Pereira'
Desta forma, temos de inserir parnteses para que este bloco efetivamente funcione da
forma correta, s selecionando quando as trs condies forem satisfeitas.
CLIENTE2.RUACLIENTE = CLIENTE.RUACLIENTE ^ CLIENTE2.CIDADECLIENTE= CLIENTE.CIDADECLIENTE

^ CLIENTE2.NOMCLIENTE <>'CARLOS PEREIRA' (Resultado2)
CLIENTE2.NOMCLIENTE,CLIENTE2.RUACLIENTE,CLIENTE2.CIDADECLIENTE (
CLIENTE2.RUACLIENTE = CLIENTE.RUACLIENTE ^ CLIENTE2.CIDADECLIENTE= CLIENTE.CIDADECLIENTE
^ CLIENTE2.NOMCLIENTE <>'CARLOS PEREIRA' (
( NOMCLIENTE=" CARLOS PEREIRA" (CLIENTE)) ( Cliente2 (CLIENTE))
)
)
A tabela resultante no final das operaes seria a apresentada a seguir:

Sequncia de tabelas do resultado da operao:
Resultado1 (Seleo e Projeo)
RuaCliente CidadeCliente
Rua B Niteri

Resultado2 (Produto Cartesiano)
RuaCliente CidadeCliente CodCliente NomCliente RuaCliente CidadeCliente

Rua B Niteri 1 Luis Sampaio Rua A Rio de Janeiro
Rua B Niteri 2 Carlos Pereira Rua B Niteri
Rua B Niteri 3 Jose Alves Rua C Rio de Janeiro
Rua B Niteri 4 Luis Paulo Souza Rua B Niteri
Resultado3 (Seleo com Duas Condies)
RuaCliente CidadeCliente CodCliente NomCliente RuaCliente CidadeCliente

Rua B Niteri 4 Luis Paulo Souza Rua B Niteri
Resultado4 (Projeo)

Esperamos que com este exemplo detalhado voc tenha condies de compreender
completamente o jogo de sequncia de operaes e montagem de consultas com as opera-
es relacionais at o momento apresentadas.
Observe que com apenas trs operaes de lgebra relacional vistas at este ponto do
livro foi possvel extrair um grande conjunto de consultas de um banco de dados.
O nome de todos os funcionrios.
O nome e o sexo de todos os funcionrios.
O nome e data de admisso dos funcionrios de sexo masculino.
O nome e a data de admisso de funcionrios que so auxiliares de cobrana.
O nome e a dvida dos clientes de um bar.
O nome, a rua e a cidade de clientes que moram na mesma rua e cidade de um
cliente especfico.
Isso que s vimos trs operaes relacionais at o momento e ainda no exploramos
todo o potencial delas.
Vamos adiante!
Agora vamos conhecer as operaes binrias e que exigem o que denominado de
tabelas de unio compatveis. Somente podem ser utilizadas com duas tabelas que possuam a
mesma estrutura de dados, ou seja, mesmo conjunto de colunas e dispostas na mesma ordem.
Para este estudo vamos utilizar as tabelas seguintes, apresentadas em sua estrutura,
modelo de dados e exemplo de contedo para auxiliar no entendimento.

Estruturas de Dados
Tabela Cliente CodCliente,

NomCliente,
RuaCliente,
CidadeCliente
Tabela Agncia CodAgencia,
NomAgencia,
CidadeAgencia
Tabela Conta-Corrente CodAgencia,
NumConta,
CodCliente,
Saldo
Tabela Emprstimo CodAgencia,
CodCliente,
NumEmprest,
Valor
Modelo de Dados

Tabelas Exemplo
Cliente Agncia
CodCliente NomCliente RuaCliente CidadeCliente CodAgencia NomAgencia CidadeAgencia

1 Luis Sampaio Rua A Rio de Janeiro 1 Rio Branco Rio de Janeiro
2 Carlos Pereira Rua B Niteri 2 Icarai Niteri
3 Jose Alves Rua C Rio de Janeiro 3 Leblon Rio de Janeiro
4 Luis Paulo Souza Rua B Niteri 4 Ipanema Rio de Janeiro
Conta Corrente Emprstimo
CodAgencia NumConta CodCliente Saldo CodAgencia CodCliente NumEmprest Valor

1 256589 1 1200,00 1 1 902230 500,00
3 328941 1 845,00 3 1 902231 1500,00
4 749621 3 512,00 4 2 902240 1200,00
2 856200 2 2650,00 2 3 902289 3000,00
3 454501 4 800,00 3 1 902255 850,00
2 468952 3 6920,00 1 3 902299 700,00
4 3 902212 400,00
Estes emprstimos esto um pouco miserveis, mas a realidade que existem casos
assim ainda hoje em dia.
Operao de Unio (Binria)

Essa operao requer como operandos tabelas de unio compatveis.
Produz como resultado uma tabela que contm todas as linhas da primeira tabela
seguida de todas as linhas da segunda tabela.
A tabela resultante possui a mesma quantidade de colunas que as tabelas originais, e
tem um nmero de linhas que no mximo igual soma das linhas das tabelas fornecidas
como operandos, j que as linhas que so comuns a ambas as tabelas aparecem uma
nica vez no resultado.
Ou seja, as duas tabelas devem ter o mesmo nmero de atributos e os domnios dos
atributos correspondentes (mesma coluna) devem ser idnticos.
A operao de unio representada, como na teoria dos conjuntos, pelo smbolo .
A sintaxe geral :
Tabela 1 Tabela 2

Suponha que quisssemos saber o nome de todas as pessoas que possuem CONTA
OU EMPRSTIMO numa determinada agncia. Observe que usamos um operador lgico OU.
Com os recursos que temos at agora no seria possvel conseguirmos tal informao,
pois as operaes vistas at o momento no fornecem subsdios para executar tal consulta.
Para resolver esta situao, devemos fazer a unio de todos que possuem conta nessa
agncia com todos que possuem emprstimos nessa mesma agncia, por exemplo, a agncia
3 (CodAgencia=3).
Como fazer isso?
O primeiro passo determinar quem possui conta na agncia especificada.
NOMCLIENTE ( CODAGENCIA = '3' ^ CONTACORRENTE.CODCLIENTE= CLIENTE.CODCLIENTE

(CLIENTE CONTA))
Devemos agora saber quem tem emprstimos na agncia 3 (CodAgencia=3):
NOMCLIENTE (CODAGENCIA = '3' ^ CONTACORRENTE.CODCLIENTE= CLIENTE.CODCLIENTE

(EMPRESTIMO CLIENTE))
Vamos olhar as duas operaes e o seu resultado aps cada uma delas:
Seleo em Cliente Conta
CodCliente NomCliente RuaCliente CidadeCliente CodAgencia NumConta CodCliente Saldo

1 Luis Sampaio Rua A Rio de Janeiro 3 328941 1 845,00
4 Luis Paulo Souza Rua B Niteri 3 454501 4 800,00
Com a projeo informada temos como resultado a tabela seguinte:
NomCliente
Luis Sampaio
Luis Paulo Souza
No segundo caso temos como resultado da seleo sobre o produto cartesiano de

emprstimos e clientes:
CodCliente NomCliente RuaCliente CidadeCliente CodAgencia CodCliente NumEmprest Valor


Projetando, temos:
NomCliente
Luis Sampaio
Luis Sampaio
Coincidentemente o nosso exemplo teve resultados idnticos.

Para responder consulta desejada (o nome de todas as pessoas que possuem
CONTA ou EMPRSTIMO na agncia 3), realizamos ento a unio dos dois resultados:

(CLIENTE CONTA))

NOMCLIENTE ( CODAGENCIA = '3' ^ EMPRESTIMO.CODCLIENTE= CLIENTE.CODCLIENTE
E temos a tabela resultado final:
NomCliente
Luis Sampaio
Luis Paulo Souza
Pois Luis Sampaio ou tem Conta ou tem Emprstimo na agncia 3 e Luis Paulo
Souza igualmente ou tem Conta ou tem Emprstimo na agncia 3.
Sem esquecer um certo grafismo tradicional, esta operao ilustrada graficamente da
seguinte forma:
Para uma operao unio Tabela 1 Tabela 2 ser vlida, preciso que condies
sejam cumpridas:
As relaes r e s precisam ter a mesma paridade, isto , elas precisam ter o
mesmo nmero de atributos.
Os domnios do i-simo atributo de r e do i-simo atributo de s devem ser os
mesmos.

A disposio dos atributos nas duas tabelas deve ser a mesma, ou seja, no
podemos ter os mesmos atributos nas duas tabelas e sequncias diferentes.
Observe o exemplo seguinte:
Cliente

Cliente
CodCliente RuaCliente NomCliente CidadeCliente

1 Rua A Luis Sampaio Rio de Janeiro
2 Rua B Carlos Pereira Niteri
3 Rua C Jose Alves Rio de Janeiro
4 Rua B Luis Paulo Souza Niteri
Estas duas tabelas no so de unies compatveis. Os atributos no esto na mesma

ordem nas tabelas.
Operao de Diferena (Binria)

A operao de diferena de tabelas permite encontrar linhas que esto em uma tabela,
mas no esto em outra.
A expresso Tabela 1 Tabela 2 resulta uma tabela que contm todas as linhas que
esto na tabela 1 e no esto na tabela 2.
O formato geral :
Tabela 1 Tabela 2
Utilizando o mesmo banco de dados usado para a operao de unio, vejamos a

consulta:
Encontrar todos os clientes que possuam uma conta, mas no tenham um emprstimo
na agncia 3.

(CLIENTE CONTA))

NOMCLIENTE ( CODAGENCIA = '3' ^ EMPRESTIMO.CODCLIENTE= CLIENTE.CODCLIENTE
O primeiro bloco resulta a tabela:
NomCliente
Luis Sampaio
Luis Paulo Souza
Que so os clientes que possuem conta na agncia 3.

O segundo bloco resulta a tabela:
NomCliente
Luis Sampaio
Luis Sampaio
Que so os clientes que possuem emprstimos na agncia 3.

Um simples olhar nas duas tabelas e j sabemos a resposta de quem tem conta, mas
no tem emprstimo na agncia 3, e o resultado a tabela seguinte:
NomCliente
Luis Paulo Souza
Que o cliente que tem conta, mas no tem emprstimo nessa agncia especfica.
Muito importante salientar que a operao de diferena no comutativa, ou seja, a
ordem dos operandos afeta o seu resultado.
Ento:
Tabela 1 Tabela 2
no a mesma coisa que
Tabela 2 Tabela 1
Se invertssemos a ordem dos dois blocos no exemplo anterior, teramos como

resultado uma tabela que no responderia corretamente nossa consulta:

NomCliente
Pois retornaria uma tabela vazia como resultado.

Elimina-se o elemento comum na tabela 1 (Luis Sampaio) e sobra o Luis Paulo Souza:
Tabela 1 Tabela 2 Resultado
NomCliente NomCliente NomCliente

Luis Sampaio Luis Sampaio Luis Paulo Souza
Luis Paulo Souza Luis Sampaio
Elimina-se o elemento comum na tabela 1 (Luis Sampaio) e no sobra nada.
Tabela 2 Tabela 1 Resultado
NomCliente NomCliente NomCliente

Luis Sampaio
Luis Sampaio
Luis Sampaio Luis Paulo Souza
Vamos agora a um exemplo muito interessante, voltando ao nosso banco de dados do

botequim, com os clientes e as contas penduradas.
Veja em seguida as tabelas para voc lembrar.

Queremos agora saber qual a maior conta pendurada no botequim.

Vamos utilizar as operaes j estudadas at este ponto do livro.
Temos de descobrir os menores valores de conta. Vamos usar a tabela conta em
produto cartesiano com ela mesma, utilizando o operador de renomear.
VALOR ( VALOR < FIADO.VALOR (CONTA Fiado(CONTA)))

Com isso obtemos os menores valores de conta, seno vejamos a resoluo com as
tabelas:

Conta - Fiado
CodCliente Valor CodCliente Valor

1 50,00 1 50,00
1 50,00 2 43,00
1 50,00 3 28,00
1 50,00 4 15,00
2 43,00 1 50,00
2 43,00 2 43,00
2 43,00 3 28,00
2 43,00 4 15,00
3 28,00 1 50,00
3 28,00 2 43,00
3 28,00 3 28,00
3 28,00 4 15,00
4 15,00 1 50,00
4 15,00 2 43,00
4 15,00 3 28,00
4 15,00 4 15,00
As linhas sombreadas representam as que satisfazem a condio de:
Valor < Fiado.valor
Logo, a tabela resultante ser:
Menores Valores
Valor
43,00
28,00
28,00
15,00
15,00
15,00
Agora fazemos a diferena entre conta e este resultado:
VALOR (CONTA ( VALOR ( VALOR < FIADO.VALOR (CONTA Fiado(CONTA))

A ilustrao da operao facilita o entendimento.

Valor
CodCliente Valor 43,00
1 50,00 28,00 Valor
2 43,00 28,00 = 50,00
3 28,00 15,00
4 15,00 15,00
15,00
Para simplificar os comandos, vamos aprender outro operador que permite assinalar o
resultado de uma operao a uma tabela.
Esta outra forma de renomear uma tabela.
Realizamos atravs do smbolo , assim como podemos atribuir a outra tabela o

resultado de uma consulta, ou de um bloco de uma consulta.
Neste ltimo exemplo poderamos realiz-lo com a seguinte sintaxe passo a passo.
1 passo
Menores VALOR ( VALOR < FIADO.VALOR (CONTA Fiado(CONTA)))

2 passo
VALOR (CONTA Menores)
Operao de Interseco de Tabelas

Esta uma operao adicional que produz como resultado uma tabela que contm,
sem repeties, todos os elementos que so comuns s duas tabelas fornecidas como
operandos.
As tabelas devem ser neste caso igualmente unio-compatveis. representado pelo
smbolo .
Sua forma de sintaxe bsica :
Tabela A Tabela B
Interessante que o mesmo resultado da operao de interseco pode ser obtido

realizando uma combinao de diferenas entre tabelas:
Tabela A Tabela B = Tabela A (Tabela A Tabela B)

Ou ainda uma combinao de unio e diferenas:
= (Tabela A Tabela B) (Tabela A Tabela B) (Tabela B Tabela A)
ou
= (Tabela A Tabela B) ((Tabela A Tabela B) (Tabela B Tabela A))
Parece complicado, mas se voc tiver o trabalho de exercitar com tabelas estas opes,
vai concluir igualmente pela montagem dos comandos.
Vamos ver ento uma consulta com a utilizao de interseco de tabelas. No caso das
tabelas de contas-correntes, emprstimos, clientes e agncia.
Agora vamos saber o nome de todos os clientes que tm emprstimo e conta-corrente
na agncia 3.
Antes queramos uma consulta com o operador lgico OU, agora desejamos com o
operador lgico E.
Novamente o primeiro passo determinar quem possui conta em agncia especificada,
a agncia 3.
ComConta NOMCLIENTE (CODAGENCIA = '3'

^ CONTACORRENTE.CODCLIENTE = CLIENTE.CODCLIENTE (CLIENTE CONTA))
Devemos agora saber quem tem emprstimos na agncia 3 (CodAgencia=3).
ComEmprestimo NOMCLIENTE (CODAGENCIA = '3'

^ EMPRESTIMO.CODCLIENTE = CLIENTE.CODCLIENTE (EMPRSTIMO CLIENTE))
Para obtermos quem tem conta e emprstimo nessa agncia, usamos a interseco dos
dois resultados com o operador para assinalar, renomear os resultados anteriores.
NOMCLIENTE (ComConta ComEmprestimo)

Vamos olhar as duas tabelas resultado e verificar as linhas comuns:
ComConta - Cliente Conta


Resultado1
NomCliente
Luis Sampaio
Luis Paulo Souza
ComEmprestimo - Cliente Emprstimo

Resultado2
NomCliente
Luis Sampaio
Luis Sampaio
As linhas comuns entre as duas tabelas esto sombreadas, destacadas; logo, o

resultado final destacando-se as linhas comuns ser:
NomCliente
Luis Sampaio
Vamos estudar outra operao que efetiva a juno das tabelas baseada em atributos
comuns s duas tabelas.
Operao de Juno
Esta uma operao que realiza a combinao das linhas de uma tabela com as linhas
correspondentes de outra tabela, sendo correspondente a uma operao de seleo atravs
dos atributos do relacionamento entre essas duas mesmas tabelas, aplicada essa seleo no
produto cartesiano dessas mesmas tabelas.
A operao de juno foi criada justamente porque esse tipo de combinao de tabelas
de uso muito comum, pois os modelos de dados Entidade-Relacionamento estabelecem
relacionamentos atravs de colunas comuns entre as tabelas, normalmente as chaves estran-
geiras de um relacionamento, facilitando com isso a escrita de expresses.
O formato geral da operao de juno :
Tabela A A.CHAVE1 = B.CHAVE2 Tabela B

Em que A.chave1 = B.chave2 o predicado da seleo, ou seja, uma seleo do
produto cartesiano das duas tabelas:
A.chave1 = B.chave2 (A B)
Na juno a tabela resultante tem todas (sem exceo) as colunas da primeira tabela e
todas da segunda tabela, pois derivada de um produto cartesiano.
Isso faz com que os valores dos campos utilizados como critrio para a correspon-
dncia entre as linhas apaream duplicados, j que um vem da primeira tabela e outro da sua
existncia na segunda tabela.
Existe uma tipologia da juno, chamada juno natural, que fornece mesmo resultado,
mas sem essa repetio de valores: uma das colunas correspondentes aos atributos de
relacionamento descartada.
A juno natural utiliza como predicado de seleo as colunas comuns s duas tabelas,
com um detalhe sem especificao de predicado, como na juno normal.
A juno natural, pelo fato de combinar sempre todos os atributos idnticos de duas
relaes, no deve ser empregada quando se deseja associar duas relaes apenas por um
ou alguns dos seus atributos idnticos.
Logo, analisando um modelo de dados, se as duas tabelas s quais se deseja aplicar
uma operao de juno possurem mais de uma coluna em comum, os resultados da apli-
cao da juno natural so imprevisveis, e certamente no vo responder adequadamente
nossa consulta.
A prtica leva-nos sempre a optar por utilizar uma operao de juno com especifi-
cao de predicados, que a torna segura para atingirmos os resultados desejados de consulta.
Vamos visualizar as duas utilizaes de juno em um dos nossos modelos de tabelas,
o bancrio.
Para que o leitor no tenha que voltar pginas, vamos reapresentar a estrutura de
dados, modelo de dados e a simulao das tabelas.
Tabela Cliente CodCliente, Tabela Conta-Corrente CodAgencia,

NomCliente, NumConta,
RuaCliente, CodCliente,
CidadeCliente Saldo
Tabela Agncia CodAgencia, Tabela Emprstimo CodAgencia,
NomAgencia, CodCliente,
CidadeAgencia NumEmprest,
Valor

Tabelas
Cliente Agncia
CodCliente NomCliente RuaCliente CidadeCliente CodAgencia NomAgencia CidadeAgencia

1 Luis Sampaio Rua A Rio de Janeiro 1 Rio Branco Rio de Janeiro
2 Carlos Pereira Rua B Niteri 2 Icarai Niteri
3 Jose Alves Rua C Rio de Janeiro 3 Leblon Rio de Janeiro
4 Luis Paulo Souza Rua B Niteri 4 Ipanema Rio de Janeiro
Conta Corrente Emprstimo
CodAgencia NumConta CodCliente Saldo CodAgencia CodCliente NumEmprest Valor

1 256589 1 1200,00 1 1 902230 500,00
3 328941 1 845,00 3 1 902231 1500,00
4 749621 3 512,00 4 2 902240 1200,00
2 856200 2 2650,00 2 3 902289 3000,00
3 454501 4 800,00 3 1 902255 850,00
2 468952 3 6920,00 1 3 902299 700,00
4 3 902212 400,00
Exemplo
1. Desejamos o nome de todos os cliente que tm emprstimos e a cidade em que
vivem.
O primeiro passo realizarmos uma juno das duas tabelas.

CLIENTE CLIENTE.CODCLLIENTE=EMPRSTIMO.CODCLIENTE EMPRSTIMO
Ou com juno natural, uma vez que s possuem uma coluna em comum.
CLIENTE EMPRSTIMO
Como resultado da juno teremos a tabela seguinte:

2 Carlos Pereira Rua B Niteri 4 2 902240 1200,00
3 Jose Alves Rua C Rio de Janeiro 2 3 902289 3000,00
Deste resultado devemos projetar as colunas desejadas na consulta:
NOMCLIENTE, CIDADECLIENTE (RESULTADO)

Realizando agora a consolidao das operaes em uma nica operao, temos:
NOMCLIENTE, CIDADECLIENTE (CLIENTE CLIENTE.CODCLLIENTE=EMPRSTIMO.CODCLIENTE EMPRSTIMO)
Ou com juno natural:
NOMCLIENTE, CIDADECLIENTE (CLIENTE EMPRSTIMO)
Vamos a outro exemplo:

Encontre todos os clientes que tm emprstimos e moram em "Niteri".
Usando juno natural, temos:
NOMCLIENTE, CIDADECLIENTE (CIDADECLIENTE = 'NITERI' (CLIENTE EMPRSTIMO)
Colocamos a seleo da coluna CidadeCliente='Niteri' sobre a juno natural de

Cliente e Emprstimo.
Tabela resultante:

CodCliente NomCliente RuaCliente CidadeCliente CodAgencia NumEmprest Valor
2 Carlos Pereira Rua B Niteri 4 902240 1200,00
Observe que este resultado, alm de ser diferente do anterior pelo fato de existir uma
seleo para a cidade de Niteri, possui somente uma coluna CodCliente, por ser uma juno
natural, a qual elimina uma das colunas comuns no resultado.
Agora vamos complicar um pouquinho:
Encontre os nomes de todos os clientes que tm conta nas agncias situadas em
"Niteri".
Voc vai se perguntar: opa, neste caso temos trs tabelas envolvidas: cliente, conta e
agncia.
Lembrando a conceituao de juno:
Esta uma operao que realiza a combinao das linhas de uma tabela com as
linhas correspondentes de outra tabela, sendo correspondente a uma operao de seleo
atravs dos atributos do relacionamento entre essas duas mesmas tabelas, aplicada essa
seleo no produto cartesiano dessas mesmas tabelas.
Como ento trabalhar com trs tabelas?
Sem problema, se considerarmos juno natural.
NOMCLIENTE, NUMCONTA (CIDADEAGENCIA ="NITERI" (CLIENTE CONTA AGNCIA))
Se quisermos abrir em junes com predicado, o comando somente ficar mais longo,
nada mais.
NOMCLIENTE, NUMCONTA (CIDADEAGENCIA ="NITERI" ((CLIENTE CLIENTE.CODCLIENTE = CONTA.CODCLIENTE
CONTA) CONTA.CODAGENCIA=AGENCIA. CODAGENCIA AGNCIA)
Vamos analisar as operaes sobre os resultados das tabelas para melhor entender o
escopo das operaes:
Cliente Conta

2 Carlos Pereira Rua B Niteri 2 856200 2 2650,00

(Este resultado) || Agncia
CodCLiente NomCliente RuaCliente CidadeCliente CodAgencia NumConta Saldo NomAgencia CidadeAgencia CidadeAgencia
1 Luis Sampaio Rua A Rio de Janeiro 1 256589 1200,00 Rio Branco Rio de Janeiro Rio de Janeiro
1 Luis Sampaio Rua A Rio de Janeiro 3 328941 845,00 Leblon Rio de Janeiro Rio de Janeiro
2 Carlos Pereira Rua B Niteri 2 856200 2650,00 Icarai Niteri Niteri
3 Jose Alves Rua C Rio de Janeiro 4 749621 512,00 Ipanema Rio de Janeiro Rio de Janeiro
3 Jose Alves Rua C Rio de Janeiro 2 468952 6920,00 Icarai Niteri Niteri
4 Luis Paulo Rua C Niteri 3 454501 800,00 Leblon Rio de Janeiro Rio de Janeiro
A seleo desta tabela retorna:
CodClente NomCliente RuaCliente CidadeCliente CodAgencia NumConta Saldo NomAgencia CidadeAgencia CidadeAgencia
2 Carlos Pereira Rua B Niteri 2 856200 2650,00 Icara Niteri Niteri
3 Jose Alves Rua C Rio de Janeiro 2 468952 6920,00 Icara Niteri Niteri
E a projeo do comando fornece o resultado final:
NomCliente
Carlos Pereira
Jose Alves
Para auxiliar a visualizao da sequncia de operaes realizadas, apresentamos em

seguida o diagrama da operao completa:
Vamos acompanhar a sequncia e estudar a ltima das operaes relacionais desse

conjunto que estamos apresentando, que a operao de diviso.

Operao de Diviso
A operao diviso, representada por , serve para consultas como as do tipo para
todos. Vamos exemplificar esta situao.
Para que o exemplo possa ser vivel dentro do esquema bancrio que temos utilizado
neste captulo, vamos aumentar os dados da tabela conta-corrente para entendermos melhor a
operao.
Observe a nova tabela de conta-corrente qual acrescentamos a linha:
4 278156 1 10000,00
Colocando o CodCliente de valor 1 agora com uma conta na agncia 4 tambm.
Conta-Corrente

1 256589 1 1200,00
3 328941 1 845,00
4 749621 3 512,00
2 856200 2 2650,00
3 454501 4 800,00
2 468952 3 6920,00
4 278156 1 10000,00
Suponha que desejamos encontrar todos os clientes que tm uma conta em todas as
agncias localizadas no Rio de Janeiro. Podemos obter todas as agncias do Rio de Janeiro
pela expresso:
Agncia

2 Icarai Niteri
Sabendo que pela tabela as agncias do Rio de Janeiro so as com CodAgencia de

valor 1, 3 e 4, com um rpido olhar na tabela de conta-corrente j observamos que o cliente
CodCliente=1 tem conta em todas as agncias da cidade do Rio de Janeiro.
Mas vamos obter esta resposta utilizando o operador de diviso.
Em primeiro lugar temos de obter uma tabela com todas as agncias do Rio de Janeiro:

AgenciaRio CODAGENCIA (CIDADEAGENCIA="RIO DE JANEIRO" (AGNCIA))
Obtemos a tabela seguinte:
AgenciaRio
CodAgencia
1
3
4
Assinalamos o resultado para a tabela AgenciaRio, colocamos uma tabela temporria,

uma varivel por assim dizer.
Vamos encontrar todos os pares NomCliente, CodAgencia referentes a um cliente
possuir uma conta em uma agncia realizando a juno entre conta e cliente:
ClienteConta NOMCLIENTE, CODAGENCIA (CONTA CLIENTE)
ClienteConta
NomCliente CodAgencia
Luis Sampaio 1
Luis Sampaio 3
Jose Alves 4
Carlos Pereira 2
Luis Paulo Souza 3
Jose Alves 2
Luis Sampaio 4
Agora precisamos encontrar clientes que apaream em ClienteConta com cada nome
de agncia em AgenciaRio.
Escrevemos esta consulta no seguinte formato:
NOMCLIENTE, CODAGENCIA (CONTA CLIENTE)

CODAGENCIA (CIDADEAGENCIA="RIO DE JANEIRO" (AGNCIA))
So procurados os conjuntos de linhas em ClienteConta cujos valores dos atributos
comuns so iguais a todos os que aparecem em AgenciaRio.

NomCliente CodAgencia
Luis Sampaio 1
CodAgencia Luis Sampaio 3
1 Jose Alves 4
3 Carlos Pereira 2
4 Luis Paulo Souza 3
Jose Alves 2
Luis Sampaio 4
O resultado final desta operao a tabela seguinte:
NomCliente
Luis Sampaio
O operando divisor a tabela AgenciaRio e o operando dividendo consiste na tabela

ClienteConta. A tabela resultante da operao o Quociente da operao.
Vistas todas as operaes relacionais, vamos resolver alguns exerccios complexos de
consulta para que o leitor aumente sua base de conhecimento sobre a utilizao de operaes
de lgebra relacional e enfrente qualquer prova de conceitos com sua utilizao.
Antes, porm, vamos apresentar uma tabela com as operaes e seus smbolos e
sintaxe para disponibilizar a voc uma fonte nica de consulta da simbologia utilizada.
Smbolo Operao Sintaxe
Seleo/Restrio Condio (Tabela)

Projeo Colunas (Tabela)
Unio Tabela 1 Tabela 2
Interseco Tabela 1 Tabela2
Diferena Tabela 1 Tabela 2
Produto Cartesiano Tabela 1 Tabela 2
Juno Tabela 1 Tabela 2
Diviso Tabela 1 Tabela 2
Renomeao Nome (Tabela)

Atribuio Nome Tabela ou Resultado Operao
Agora vamos a modelos e casos mais complexos para estudarmos solues com
lgebra relacional.

Exerccios Resolvidos e Operadores Adicionais
Considere o seguinte esquema de uma base de dados de uma transportadora area
(em que os atributos chave primria se encontram sublinhados):
Marca ({Marca, Lugares, Autonomia})
Piloto ({NomeP, Endereco, Local, Idade})
Aviao ({Matr, NomeA, Marca})
Voo ({Num, Matr, Data, Hora, De, Para, NomeP})
A seguir vamos simular dados nas tabelas apresentadas:
Marca
Marca Lugares Autonomia

Boeing 747 180 10.000
Boeing 737-300 120 8000
Boeing 737-500 118 8000
Airbus 300 150 8500
Airbus 200 110 7500
Piloto Avio
Nomep Endereo Local Idade Matr NomeA Marca

Joao E-1 Local-1 34 12 PPT-XP Boeing 747
Pedro E-2 Local-2 36 15 PPT-CD Boeing 747
Inacio E-3 Local-3 42 20 PPT-AS Boeing 737-300
Jose E-4 Local-4 28 5 PPT-TD Boeing 737-500
Carlos E-5 Local-5 31 3 PPT-FR Boeing 737-300
Adao E-6 Local-6 37 40 PPT-XJ Airbus 300
Karl E-7 Local-7 48 32 PPT-AM Airbus 200
Daniel E-8 Local-8 45
Voo
Num Matr Data Hora De Para NomeP

100 15 15/12/2002 08:00 SDU CGH Pedro
101 12 16/12/2002 09:00 SDU CGH Pedro
102 5 16/12/2002 10:05 SDU BSB Inacio
103 12 16/12/2002 11:00 CGH SDU Pedro
104 5 16/12/2002 17:42 BSB SDU Daniel
105 12 16/12/2002 13:00 SDU CGH Inacio

Num Matr Data Hora De Para NomeP
106 15 15/12/2002 10:00 CGH SDU Inacio
108 20 16/12/2002 09:12 SDU POA Pedro
321 40 18/12/2002 09:52 SDU FOR Inacio
322 32 19/12/2002 09:57 SDU REC Inacio
324 20 17/12/2002 11:03 POA SDU Pedro
456 15 15/12/2002 14:00 SDU CGH Daniel
457 15 15/12/2002 19:00 CGH SDU Daniel
4020 20 20/12/2002 09:12 SDU POA Inacio
4010 15 20/12/2002 21:12 SDU BSB Daniel
4011 3 15/12/2002 13:02 SDU GOI Karl
3010 3 15/12/2002 17:51 GOI SDU Karl
3110 5 17/12/2002 11:03 POA SDU Inacio
3011 12 17/12/2002 08:00 CGH SDU Pedro
E o modelo de dados para o caso em estudo.
Vamos s questes a serem respondidas sobre esta base de dados.
1 Questo
Quais so as matrculas dos avies que tm autonomia superior a 7.500 quilmetros?
MATR ( MARCA.MARCA=AVIO.MARCA ^ MARCA.AUTONOMIA > 7500 (MARCA AVIO))

A tabela resultante do produto cartesiano (utilizamos neste caso) com a seleo de
colunas comuns ( marca.marca=aviao.marca) a seguinte:

Marca Lugares Autonomia Matr NomeA Marca
Boeing 747 180 10.000 12 PPT-XP Boeing 747
Boeing 747 180 10.000 15 PPT-CD Boeing 747
Boeing 737-300 120 8000 20 PPT-AS Boeing 737-300
Boeing 737-300 120 8000 3 PPT-FR Boeing 737-300
Boeing 737-500 118 8000 5 PPT-TD Boeing 737-500
Airbus 300 150 8500 40 PPT-XJ Airbus 300
Airbus 200 110 7500 32 PPT-AM Airbus 200
Completando a seleo com ^ MARCA.AUTONOMIA > 8000, temos a tabela resultado:
Marca Lugares Autonomia Matr NomeA Marca

Boeing 747 180 10.000 12 PPT-XP Boeing 747
Boeing 747 180 10.000 15 PPT-CD Boeing 747
Boeing 737-300 120 8000 20 PPT-AS Boeing 737-300
Boeing 737-300 120 8000 3 PPT-FR Boeing 737-300
Boeing 737-500 118 8000 5 PPT-TD Boeing 737-500
Airbus 300 150 8500 40 PPT-XJ Airbus 300
E com a projeo final MATR, o resultado ser a tabela seguinte:
Matr
12
15
20
3
5
40
2 Questo
Quais so os nomes e endereos dos pilotos que alguma vez pilotaram um avio de
marca Boeing 737?
NOMEP, ENDEREO (PILOTO PILOTO.NOMEP=NOMEP
( NOMEP ( AVIAO.MARCA="BOEING 737-300" V AVIAO.MARCA="BOEING 737-500" (VOO AVIAO.MATR = VOO.MATR AVIO)

)
)
)
Vamos analisar esta soluo.

Em primeiro lugar temos de pensar que necessitamos descobrir em cada voo o nome
do avio nele utilizado, uma vez que s temos a coluna Matr em cada linha da tabela voo.
Logo, necessitamos de uma juno da tabela avio com a tabela voo, selecionando
dessa juno as linhas em que aviao.marca="Boeing 737-300" ou aviao.marca="Boeing
737-500".
Isso nos fornece como resultado sete voos que utilizaram esse tipo de aeronave:
Matr NomeA Marca Num Matr Data Hora De Para NomeP

5 PPT-TD Boeing 737-500 104 5 16/12/2002 17:42 BSB SDU Daniel
20 PPT-AS Boeing 737-300 108 20 16/12/2002 09:12 SDU POA Pedro
20 PPT-AS Boeing 737-300 324 20 17/12/2002 11:03 POA SDU Pedro
20 PPT-AS Boeing 737-300 4020 20 20/12/2002 09:12 SDU POA Inacio
3 PPT-FR Boeing 737-300 4011 3 15/12/2002 13:02 SDU GOI Karl
3 PPT-FR Boeing 737-300 3010 3 15/12/2002 17:51 GOI SDU Karl
5 PPT-TD Boeing 737-500 3110 5 17/12/2002 11:03 POA SDU Inacio
Resta agora obter os endereos dos pilotos assinalados em cada um desses voos.
Vamos realizar a juno da tabela piloto com o resultado obtido anteriormente (vamos
utilizar uma juno especificando novamente a condio de juno) e projetar as colunas que
desejamos no resultado final.
NOMEP, ENDEREO
(PILOTO PILOTO.NOMEP=NOMEP (Resultado anterior)
Tabelas obtidas na sequncia (juno):
Matr NomeA Marca Num Matr Data Hora De Para NomeP NomeP Endereo Local Idade
5 PPT-TD Boeing 737-500 104 5 16/12/2002 17:42 BSB SDU Daniel Daniel E-8 Local-8 45
20 PPT-AS Boeing 737-300 108 20 16/12/2002 09:12 SDU POA Pedro Pedro E-2 Local-2 36
20 PPT-AS Boeing 737-300 324 20 17/12/2002 11:03 POA SDU Pedro Pedro E-2 Local-2 36
20 PPT-AS Boeing 737-300 4020 20 20/12/2002 09:12 SDU POA Incio Incio E-3 Local-3 42
3 PPT-FR Boeing 737-300 4011 3 15/12/2002 13:02 SDU GOI Karl Karl E-7 Local-7 48
3 PPT-FR Boeing 737-300 3010 3 15/12/2002 17:51 GOI SDU Karl Karl E-7 Local-7 48
5 PPT-TD Boeing 737-300 3110 5 17/12/2002 11:03 POA SDU Incio Incio E-3 Local-3 42
Com a projeo temos a tabela seguinte, que o resultado final.
NomeP Endereo
Daniel E-8
Pedro E-2
Inacio E-3
Karl E-7

3 Questo
Quais so os nomes dos pilotos que j pilotaram avies de todas as marcas existentes?
A palavra todas lembra que nesta questo preciso realizar uma diviso. Vamos
adiante.
Acompanhe a soluo passo a passo:
1 passo: obter nome do piloto e avio na tabela voo.
MATR, NOMEP (VOO)
Matr NomeP
3 Karl
3 Karl
5 Inacio
5 Inacio
12 Inacio
12 Pedro
12 Pedro
12 Pedro
15 Daniel
15 Daniel
15 Daniel
15 Inacio
15 Pedro
20 Inacio
20 Inacio
20 Pedro
20 Pedro
32 Inacio
40 Inacio
2 passo: obter nome do piloto e marca de avio pela projeo das colunas desejadas
na juno da tabela avio com o resultado do comando anterior:
MARCA,NOMEP
(
AVIO AVIAO.MATR=MATR ( MATR, NOMEP (VOO))
)
E j temos uma tabela com pilotos e avies que eles pilotaram.

Marca NomeP
Boeing 747 Daniel
Boeing 747 Daniel
Boeing 747 Daniel
Boeing 737-500 Inacio
Boeing 747 Inacio
Boeing 747 Inacio
Airbus 200 Inacio
Airbus 300 Inacio
Boeing 737-300 Karl
Boeing 737-300 Karl
Boeing 747 Pedro
Boeing 747 Pedro
Boeing 747 Pedro
Boeing 747 Pedro
Boeing 737-300 Pedro
Boeing 737-300 Pedro
Agora vamos obter as marcas de avio existentes pela projeo da tabela marca.
MARCA (MARCA)
Marca
Boeing 747
Boeing 737-300
Boeing 737-500
Airbus 300
Airbus 200
Podemos agora dividir o resultado obtido anteriormente pelo resultado dessa projeo.
MARCA,NOMEP (AVIO AVIAO.MATR=MATR ( MATR, NOMEP (VOO)))

/
MARCA (MARCA)
A pergunta que no quer calar:
A soluo no poderia ser mais simples eliminando um passo?

Sim, efetivamente est de parabns o leitor que chegar a esta concluso.
A soluo mais simples :
MARCA,NOMEP (AVIO AVIAO.MATR=MATR (VOO) )

/
MARCA (MARCA)
Observe que na juno que estamos utilizando j obtivemos com a projeo uma tabela
que possui marca e nome do piloto, dispensando um passo dos apresentados anteriormente.
O resultado final ser a tabela seguinte:
NomeP
Inacio
Que o quociente entre as duas projees utilizadas.
4 Questo
Quais so os avies que, num mesmo dia, passaram mais de uma vez por um mesmo
aeroporto?
Parece que complicou, meu amigo leitor?
No muito, s que para resolver este exerccio vamos aprender algumas funes adicio-
nais existentes na lgebra relacional.
Funes em lgebra Relacional

Algumas operaes muito comuns sobre base de dados no podem ser executadas
usando apenas as operaes de lgebra relacional vistas at agora.
Tais operaes, entretanto, so implementadas na linguagem de consulta base de
dados (SQL) fornecida por fabricantes dos principais SGBDR existentes no mercado.
O primeiro grupo de funes que no pode ser expresso usando lgebra relacional
composto por funes matemticas de agregao executadas com uma coleo de valores de
uma base de dados.
Por exemplo, calcular mdia e o total de salrios pagos para um grupo de empregados
de uma empresa.
Entre as funes de agregao mais comuns aplicadas em uma coleo de valores
numricos esto a SOMA, a MDIA, o MXIMO e o MNIMO, alm da funo CONTADOR,
que usada para contar linhas.

Cada uma destas funes pode ser aplicada em uma coleo de linhas, seja de uma
tabela, seja de um resultado de operao relacional.
Considere a seguinte tabela:
Funcionrio
Nmero Nome Departamento Salrio

31445 Antnio Silva Contabilidade 130
30442 Isabel Sousa Armazm 240
27710 Mrio Gomes Vendas 240
27720 Maria Mendes Vendas 300
27730 Joo Pereira Vendas 130
Para responder questo:

Qual a soma dos salrios de todos os empregados?
necessrio aplicar uma funo de agregao tabela.
As funes de agregao usuais so:
COUNT contagem do nmero de linhas

SUM clculo da soma
AVERAGE clculo da mdia
MAXIMUM identificao do valor mximo
MINIMUM identificao do valor mnimo
Outra questo que se pode colocar :

Por departamento, qual o valor mximo dos salrios dos seus empregados?
A resposta a esta questo implica:
Agrupar as linhas da tabela pelo valor de alguns dos seus atributos e aplicar uma
funo de agregao a cada um dos grupos de linhas.
Vamos definir o operador de agregao que permite escrever estas questes.
Sendo uma tabela A, o operador de agregao tem o formato geral:
<Atributos para Agrupamento> <Funes de Agregao> (Tabela A)
Ento sobre a tabela exemplo de funcionrios, para saber o valor mximo de salrios,
temos a seguinte expresso:
<Departamento> <Max salrio> (FUNCIONRIO)

Que retorna uma nica coluna de resultado que o valor do maior salrio:
Salrio
300
E na questo da soma dos salrios:
Sun salrio> (FUNCIONRIO)

Retorna somente o valor 1040.
Por outro lado, podemos ter de utilizar operaes aritmticas simples, como soma,
subtrao etc. que denominamos de projeo generalizada.
Projeo Generalizada
As operaes de projeo ditas generalizadas estendem a lista de atributos de uma
projeo de forma a permitir a utilizao de operaes aritmticas nessa lista de atributos.
O formato nada mais do que colocar na lista uma expresso aritmtica com ou sobre
os atributos existentes na tabela que est sendo projetada.
Para exemplificar melhor, vamos apresentar a tabela seguinte:
InfoCredito
NomeCliente LimiteCredito SaldoCredito
Joo 6.000,00 700,00
Silva 2.000,00 400,00
Pedro 1.500,00 1.500,00
Cintia 2.000,00 1.750,00
Supondo que desejamos saber o quanto uma pessoa ainda pode gastar e temos a
tabela info_crdito que lista limites de crdito e valores de crdito j utilizados (saldo_credito).
Projeo generalizada uma operao no seguinte formato:
NOMECLIENTE, LIMITECREDITO SALDOCREDITO (INFO_CREDITO)

Que fornece como resultado a tabela seguinte:
Joo 5.300,00
Silva 1.600,00
Pedro 0,00
Cintia 250,00

Apresentadas as duas extenses da lgebra relacional, vamos continuar na resoluo
da questo nmero 4:
Quais so os avies que, num mesmo dia, passaram mais de uma vez por um mesmo
aeroporto?
Neste exerccio vamos precisar de dois conjuntos iguais inicialmente, para posterior-
mente realizarmos a sua unio e obter assim a matrcula do avio, as datas e os aeroportos
por onde passaram, porque devemos considerar a origem (De) e o destino (Para) como sendo
aeroportos por onde passaram os avies.
Como fazer isso?
Devemos utilizar um artifcio para obter uma projeo das linhas com a coluna 'Para'
modificada para aeroporto, assim como a coluna tambm modificada para aeroporto, e obter
duas tabelas de mesma estrutura de dados para possibilitar a unio das duas. Podemos
utilizar o operador de rename, a letra grega rho , tambm para dar nome s colunas do
resultado de uma projeo
Para isso utiliza-se o operador de renomear, porm com o acrscimo de renomear
tambm seus atributos:
VOODE (MATRICULA, DATA, AEROPORTO)( MATRICULA, DATA, DE (VOO)

Desta forma temos a projeo da tabela de voos agora como a apresentada em seguida:
VooDe
Matr Data Aeroporto
15 15/12/2002 SDU
12 16/12/2002 SDU
5 16/12/2002 SDU
12 16/12/2002 CGH
5 16/12/2002 BSB
12 16/12/2002 SDU
15 15/12/2002 CGH
20 16/12/2002 SDU
40 18/12/2002 SDU
32 19/12/2002 SDU
20 17/12/2002 POA
15 15/12/2002 SDU
15 15/12/2002 CGH
20 20/12/2002 SDU
15 20/12/2002 SDU
3 15/12/2002 SDU
3 15/12/2002 GOI
5 17/12/2002 POA
12 17/12/2002 CGH

Vamos aplicar a mesma operao considerando a coluna Para:
VOOPARA(MATRICULA, DATA, AEROPORTO)( MATRICULA, DATA, PARA (VOO)

Temos ento a tabela seguinte, que a renomeao da coluna Para.
VooPara
Matr Data Aeroporto

15 15/12/2002 CGH
12 16/12/2002 CGH
5 16/12/2002 BSB
12 16/12/2002 SDU
5 16/12/2002 SDU
12 16/12/2002 CGH
15 15/12/2002 SDU
20 16/12/2002 POA
40 18/12/2002 FOR
32 19/12/2002 REC
20 17/12/2002 SDU
15 15/12/2002 CGH
15 15/12/2002 SDU
20 20/12/2002 POA
15 20/12/2002 BSB
3 15/12/2002 GOI
3 15/12/2002 SDU
5 17/12/2002 SDU
12 17/12/2002 SDU
Fazemos agora a unio das duas tabelas resultantes de projeo.

A prxima pgina vai ser dedicada a apresentar esta enorme tabela resultante:
TodosVoos VOOPARA U VOODE
TodosVoos
Matr Data Aeroporto

15 15/12/2002 SDU
12 16/12/2002 SDU
5 16/12/2002 SDU
12 16/12/2002 CGH

Matr Data Aeroporto
5 16/12/2002 BSB
12 16/12/2002 SDU
15 15/12/2002 CGH
20 16/12/2002 SDU
40 18/12/2002 SDU
32 19/12/2002 SDU
20 17/12/2002 POA
15 15/12/2002 SDU
15 15/12/2002 CGH
20 20/12/2002 SDU
15 20/12/2002 SDU
3 15/12/2002 SDU
3 15/12/2002 GOI
5 17/12/2002 POA
12 17/12/2002 CGH
15 15/12/2002 CGH
12 16/12/2002 CGH
5 16/12/2002 BSB
12 16/12/2002 SDU
5 16/12/2002 SDU
12 16/12/2002 CGH
15 15/12/2002 SDU
20 16/12/2002 POA
40 18/12/2002 FOR
32 19/12/2002 REC
20 17/12/2002 SDU
15 15/12/2002 CGH
15 15/12/2002 SDU
20 20/12/2002 POA
15 20/12/2002 BSB
3 15/12/2002 GOI
3 15/12/2002 SDU
5 17/12/2002 SDU
12 17/12/2002 SDU
Temos os avies, o dia e por onde passaram, resta descobrir quem passou mais de
uma vez em um aeroporto no mesmo dia.
Vamos para uma aplicao de funo de agregao.

MATR, DATA, AEROPORTO COUNT (TODOSVOOS)
Agrupamos as linhas pelas colunas Matr, Data e Aeroporto.
Isso nos fornece como resultado a tabela:
Matr Data Aeroporto Count

3 15/12/2002 GOI 2
3 15/12/2002 SDU 2
5 16/12/2002 BSB 2
5 16/12/2002 SDU 2
5 17/12/2002 POA 1
5 17/12/2002 SDU 1
12 16/12/2002 CGH 3
12 16/12/2002 SDU 3
12 17/12/2002 CGH 1
12 17/12/2002 SDU 1
15 15/12/2002 CGH 4
15 15/12/2002 SDU 4
15 20/12/2002 BSB 1
15 20/12/2002 SDU 1
20 16/12/2002 POA 1
20 16/12/2002 SDU 1
20 17/12/2002 POA 1
20 17/12/2002 SDU 1
20 20/12/2002 POA 1
20 20/12/2002 SDU 1
32 19/12/2002 REC 1
32 19/12/2002 SDU 1
40 18/12/2002 FOR 1
40 18/12/2002 SDU 1
Como estamos pedindo somente os avies que estiveram mais de uma vez no mesmo
aeroporto, interessa selecionar somente aqueles cujo contador maior que 1.
Logo:
MATR ( COUNT > 1 (MATR, DATA, AEROPORTO COUNT (TODOSVOOS) )
E temos, finalmente, a tabela que responde questo:

Matr
3
5
12
15
Complicadinho, mas na realidade somente uma sequncia lgica de como realizamos

mentalmente a soluo deste problema passo a passo.
Observe o grfico ilustrativo da sequncia de operaes.
1. Projetamos por avio, data e local (Para) todos os voos.

2. Projetamos por avio, data e local (De) todos os voos.
3. Unimos as duas tabelas resultantes e temos agora os dados projetados por avio,
data e um nico local (De e Para como uma nica coluna 'Aeroporto').
4. Aplicamos a contagem de linhas iguais agrupadas por avio, data e local.
5. Aplicamos uma agregao (funo) e selecionamos as linhas com contador de
valor maior que 1.
Agora pode parecer algo meio novo, mas ainda no terminamos de ver todas as
operaes de lgebra relacional. Vimos a maior parte dos operadores, porm ainda existem
mais operaes a serem estudadas. Vamos seguir com a apresentao dos operadores e seus
exemplos.

Operao de Semijuno
A operao de semijuno de uma tabela A definida com um conjunto de atributos por
outra tabela B com seu conjunto de atributos e relacionada com a tabela A so as linhas da
tabela A que participam da juno da tabela A com a tabela B.
A notao da sintaxe de semijuno :
Tabela A F Tabela B
A vantagem de utilizar a semijuno o fato de diminuir o nmero de linhas que

precisam ser manipuladas para formar uma juno.
Ela muito importante em bancos de dados distribudos, pois reduz, na maioria das
vezes, a quantidade de dados que precisam ser transmitidos entre sites.
Para facilitar o entendimento da semijuno e da juno, vamos exemplificar utilizando
as tabelas de funcionrios e cargos j vistas neste captulo, que repetimos aqui para voc no
ter de voltar pginas do livro.
Funcionrio

134 Jose Alves 23/5/2002 M C5 D1
Cargo

C3 Vendedor 800,00
C7 Diretor 2500,00
C2 Vigia 400,00
C5 Gerente 1000,00

O resultado da juno expressa por:
FUNCIONRIO FUNCIONARIO.CDCARGO=CARGO.CDCARGO CARGO
a tabela seguinte:
NumReg NomeFunc DtAdmisso Sexo CdCargo CdDepto CdCargo NumCargo VlrSalario

101 Luis Sampaio 10/08/2003 M C3 D5 C3 Vendedor 800,00
134 Jose Alves 23/05/2002 M C5 D1 C5 Gerente 1000,00
121 Luis Paulo Souza 10/12/2001 M C3 D5 C3 Vendedor 800,00
195 Marta Silveira 05/01/2002 F C1 D5 C1 Aux Cobraa 350,00
139 Ana Luiza Magalhes 12/01/2003 F C4 D6 C4 Diretor 250,00
123 Pedro Sergio Doto 29/06/2003 M C7 D3 C7 Aux Cobrana 2500,00
148 Larissa Silva 01/06/2002 F C4 D6 C4 Vendedor 250,00
115 Roberto Fernandes 15/10/2003 M C3 D5 C3 Vendedor 800,00
22 Sergio Nogueira 10/02/2000 M C2 D4 C2 Vigia 400,00
J o resultado da semijuno de funcionrio e cargo expresso pela sintaxe:
a tabela seguinte:

134 Jose Alves 23/05/2002 M C5 D1
115 Roberto Fernander 15/10/2003 M C3 D5
Observe que a tabela resultante no tem os outros atributos de cargo, portanto temos
como resultado uma tabela menor.
A semijuno, entretanto, tem comutatividade, ou seja, o resultado diferente se ela for
aberta direita ou esquerda.
A semijuno a seguir, por exemplo, tem resultado diferente da anterior.


C3 Vendedor 800,00
C7 Vendedor 800,00
C7 Diretor 2500,00
C2 Vigia 400,00
C5 Gerente 1000,00
Resultando praticamente na tabela cargo.
Juno Externa (Outer-Join)

Esta outra extenso da operao e juno e objetiva apresentar informaes omitidas
em uma operao de juno normalmente.
Para explicar melhor, diramos que uma juno externa permite descobrir quais ele-
mentos de uma tabela no esto associados, relacionados a elementos de outra tabela.
A juno externa possui comutatividade, ou seja, temos juno externa esquerda e
juno externa direita:
Formato para juno externa direita:
Tabela A Tabela B
Formato para juno externa esquerda:
Tabela A Tabela B
Vamos trabalhar com as tabelas bancrias um pouco modificadas em seus elementos

para exemplificar as opes de juno externa.
Agncia

2 Icarai Niteri
5 Copacabana Rio de Janeiro

Cliente

5 Silvio Luis Rua D Rio de Janeiro
Conta-Corrente

1 256589 1 1200,00
3 328941 1 845,00
4 749621 3 512,00
2 856200 2 2650,00
Observe que nem todas as agncias da tabela possuem contas-correntes referen-

ciando-as, assim como temos clientes cadastrados que agora no possuem conta-corrente.
Utilizando a operao de juno, no conseguimos visualizar essas ocorrncias, porm
com a juno externa podemos obter a informao faltante.
Para vermos as agncias que possuem conta-corrente e tambm as que no possuem,
usamos uma juno direita:
AGNCIA CONTACORRENTE
Observe a tabela resultado da operao:
CodAgencia NomAgencia CidadeAgencia CodAgencia NumConta CodCliente Saldo

1 Rio Branco Rio de Janeiro 1 256589 1 1200,00
2 Icarai Niteri 2 856200 2 2650,00
3 Leblon Rio de Janeiro 3 328941 1 845,00
4 Ipanema Rio de Janeiro 4 749621 3 512,00
5 Copacabana Rio de Janeiro nulo nulo nulo nulo
A agncia CodAgencia = 5 no possui nenhuma linha de conta-corrente associada,

porm apresentada com as colunas referentes tabela ContaCorrente com valor nulo.
Se realizarmos a operao inversa:
AGNCIA CONTACORRENTE

No existiro linhas com contedo nulo:
CodAgencia NomAgencia CidadeAgencia CodAgencia NumConta CodCliente Saldo

1 Rio Branco Rio de Janeiro 1 256589 1 1200,00
2 Icarai Niteri 2 856200 2 2650,00
3 Leblon Rio de Janeiro 3 328941 1 845,00
4 Ipanema Rio de Janeiro 4 749621 3 512,00
E se houvesse, apresentariam falha de integridade do banco de dados, pois teramos

ocorrncias de conta-corrente sem agncia.
Entretanto, podemos ver um outro caso dessa juno em:
CONTACORRENTE CLIENTE
Que fornece como resultado:
CodAgencia NumConta CodCliente Saldo CodCliente Nom Cliente RuaCliente CidadeCliente

1 256589 1 1200,00 1 Luis Sampaio Rua A Rio de Janeiro
3 328941 1 845,00 1 Luis Sampaio Rua A Rio de Janeiro
2 856200 2 2650,00 2 Carlos Pereira Rua B Niteri
4 749621 3 512,00 3 Jose Alves Rua C Rio de Janeiro
nulo nulo nulo nulo 4 Luis Paulo Souza Rua B Niteri
nulo nulo nulo v 5 Silvio Luis Rua D Rio de Janeiro
Como nas tabelas apresentadas somente trs clientes possuem conta-corrente, apare-
cem os outros dois clientes, porm com os valores relativos tabela ContaCorrente nulos.
Exerccios Propostos
1. Dadas as tabelas da figura seguinte, que expresses utilizando apenas as tabelas R e S
permitem construir as tabelas T e U?
Tabela R Tabela S Tabela T Tabela U

A B C B C D A B C D A D
a b c b c d a b c d a d
d b c b c e a b c e a e
b b f a d b d b c d d d
c a d d b c e d e
c a d b

2. Construa expresses em lgebra relacional para as seguintes consultas, relativas ao
banco de dados para controle de estoque apresentado em seguida. muito importante
simular os contedos das tabelas do modelo de dados.
a. Encontre os nomes dos produtos de primeira qualidade.

b. Encontre os nomes dos fornecedores da Regio Sul do Brasil.
c. Fornea as quantidades de produtos pedidas para cada local de armazenamento.
d. Localize os nomes dos produtos para os quais h pedido(s) cadastrado(s).
e. Encontre as cidades dos fornecedores para os quais h pedidos cadastrados.
f. Encontre os nomes de produtos em estoque procedentes de fornecedores da Regio
Sul do Brasil.
g. Localize os nomes dos produtos para os quais h pedidos e mercadorias em estoque.
h. Encontre os nomes dos produtos cadastrados para os quais no h registros em
estoque nem em pedido.
3. Construa mais expresses em lgebra para este modelo conforme as solicitaes de

consulta apresentadas em seguida:
a. Encontre os fornecedores que contriburam com produtos de primeira qualidade no
estoque atual.
b. Encontre os fornecedores que contriburam com produtos de primeira qualidade no
estoque atual ou para os quais haja pedido(s) de algum produto de primeira
qualidade.
c. Quais so os nomes dos produtos esgotados no estoque para os quais no h
pedido(s)?
d. Quais so os nomes dos produtos para os quais h estoque e pedido(s)?

e. Quais produtos do estoque tm procedncia diferente das cidades dos respectivos
fornecedores? Retorne o nome do fornecedor, o nome do produto, a cidade do
fornecedor e a procedncia do produto.
f. Quais so os fornecedores localizados nas mesmas cidades dos armazns a que se
destinam os pedidos? Retorne o nome do fornecedor, o nome do produto e a cidade.
4. Dado o modelo seguinte:
Responda:
a. Quais so os nomes de todos os vendedores?
b. Quais so os nmeros dos vendedores que realizaram algum pedido?
c. Quais so os nmeros dos vendedores que no tm pedidos?
d. Quais so os vendedores que realizaram pedidos para clientes do tipo indstria?
e. Que tipo de clientes foram atendidos pelo vendedor de nome Luis Paulo?
5. Fornecidas as estruturas de dados (sem o modelo de dados), responda s consultas

seguintes utilizando as operaes de lgebra relacional.
Formato Tabela (Atributos)
Empregado (IDEMP, NOMEEMP, DTNASCIMENTO, ENDERECOEMP, SEXOEMP, SLARIOEMP,
NUMDEP)
Departamento (NUMDEP, NOMEDEP, IDGERENTE, HORARIO)

Localizacao (LOCALIZAO, NUMDEP)
Trabalha_Em (IDEMP, NUMPROJETO, HORAS)
Projeto (NUMPROJETO, NOMEPROJETO, NUMDEP)
Dependente (IDEMP, IDDEPENDENTE, NOMEDEPEDENDENTE, SEXODEPENDENTE,
DTNASCDEPEND, PARENTESCO).
a. Obter o nome e o endereo de todos os empregados que trabalham no departamento

de compras.
b. Para cada projeto localizado no Rio de Janeiro exibir o nmero do projeto, o nmero
do departamento que o controla e a identidade de seu gerente, seu endereo e a data
de nascimento dele.

c. Descobrir os nomes dos projetos nos quais trabalham empregados com o nome
Antonio.
d. Listar os empregados que no tm dependentes.
No basta saber como se escrevem as operaes relacionais, preciso pensar e estruturar

as consultas.
Acreditamos ter apresentado de uma forma bem didtica as operaes relacionais e

fornecido os caminhos de soluo e raciocnio que normalmente no so explanados em sala
de aula. O objetivo contribuir para o aprendizado e domnio da utilizao de lgebra relacio-
nal por todos os que dela necessitam e a utilizam.

14
SQL
A Importncia da Linguagem SQL

SQL significa Structured Query Language - Linguagem Estruturada de Pesquisa. De
grande utilizao, teve seus fundamentos no modelo relacional de Codd (1970). Sua primeira
verso recebeu o nome de SEQUEL (Structured English Query Language), definida por D. D.
Chamberlin, entre outros, em 1974, nos laboratrios de pesquisa da IBM (Califrnia).
Em 1975, foi implementado um prottipo de aplicao dessa nova linguagem. Entre
1976 e 1977, o SEQUEL foi revisado e ampliado, e teve seu nome alterado para SQL por
razes jurdicas.
Com essa reviso foi posto em prtica um projeto ambicioso da IBM chamado System R
e novas alteraes foram introduzidas na SQL, graas s ideias apresentadas pelos diversos
usurios do ambiente.
Devido ao sucesso dessa nova forma de consulta e manipulao de dados, dentro de
um ambiente de banco de dados, a utilizao da SQL foi aumentando cada vez mais. Com isso
uma grande quantidade de SGBDs foi utilizando como linguagem bsica a SQL - SQL/DS e
DB2 da IBM, Oracle da Oracle Corporation, RDB da Digital, Sybase da Sybase Inc., Microsoft
SQL Server, entre outras.
A SQL se tornou um padro de fato no mundo dos ambientes de banco de dados
relacionais. Bastava agora se tornar de direito. Em 1982, o American National Standard
Institute (ANSI) tornou a SQL padro oficial de linguagem em ambiente relacional.
Infelizmente, como todo padro que se preze, existem hoje vrios dialetos SQL, cada
um, evidentemente, tentando ser mais padronizado que o outro. Neste captulo vamos seguir o
padro ANSI da SQL, tentando ser o mais isento possvel de implementaes especficas de
cada fabricante.
Como vimos no captulo anterior, o modelo relacional constitudo basicamente de
tabelas, cada qual contendo linhas (registros, tuplas) e colunas. Os registros na tabela no so
ordenados e sua localizao feita por um campo-chave, ou seja, um campo que assume o
papel de chave primria da tabela. Com essa chave identifica-se uma, e somente uma, ocor-
rncia do valor contido no campo.

Uma das razes da popularidade dos sistemas relacionais a sua facilidade de mani-
pulao e entendimento.
A linguagem SQL foi desenvolvida especialmente para o ambiente relacional, podendo
ser adaptada a qualquer ambiente no relacional.
A Linguagem SQL
A ideia original da SQL s previa seu uso de forma interativa. Aps sofrer alguns
acrscimos, ela passou tambm a ter capacidade de ser utilizada em linguagens hospedeiras,
tais como Cobol, Fortran, "C" etc.
Atualmente, a linguagem SQL assume um papel muito importante nos Sistemas de

Gerenciamento de Banco de Dados, podendo ter muitos enfoques, como mostra a figura.
Linguagem interativa de consulta (Query AdHoc): com os comandos SQL os
usurios podem montar consultas poderosas sem a necessidade de criar um
programa, podendo utilizar forms ou ferramentas de montagem de relatrio.
Linguagem de programao para acesso a banco de dados: comandos SQL
embutidos em programas de aplicao que acessam os dados armazenados.
Linguagem de administrao de banco de dados: o responsvel pela adminis-
trao do banco de dados (DBA) pode utilizar comandos SQL para realizar suas
tarefas.
SQL 307
Linguagem cliente/servidor: os programas (cliente) dos computadores pessoais
usam comandos SQL para se comunicarem por meio de uma rede local, com-
partilhando os dados armazenados em um nico local (servidor). A arquitetura
cliente/servidor minimiza o trfego de dados pela rede.
Linguagem para banco de dados distribudo: a SQL auxilia na distribuio dos
dados atravs de vrios ns conectados ao sistema de aplicao. Auxilia tambm
na comunicao de dados com outros sistemas.
Caminho de acesso a outros bancos de dados em diferentes mquinas: a SQL
auxilia na converso entre diferentes produtos de banco de dados colocados em
diversas mquinas (de micro at mainframe).
Por ser uma linguagem de numerosas aplicaes, a SQL pode manipular objetos de
diferentes classes entre as funes de um SGBD:
Definio de dados (DDL): permite ao usurio a definio da estrutura e organiza-

o dos dados armazenados, e as relaes que existem entre eles.
Manipulao de dados (DML): permite ao usurio ou a um programa de aplicao
a incluso, remoo, seleo ou atualizao de dados previamente armazenados
no banco.
Controle de acesso: protege os dados de manipulaes no autorizadas.
Compartilhamento de dados: coordena o compartilhamento dos dados por usu-
rios concorrentes, sem, contudo, interferir na ao de cada um deles.
Integridade dos dados: auxilia no processo de definio da integridade dos
dados, protegendo contra corrupes, inconsistncias e falhas do sistema de
computao.

Vantagens e Desvantagens da Linguagem SQL
Com o uso e a padronizao da SQL algumas vantagens so diretas:
Independncia de fabricante: a SQL oferecida em praticamente todos os
SGBDs, e os que ainda no tm esto se encaminhando para l. Com isso
possvel mudar de SGBD sem se preocupar com o novo que vai chegar.
Portabilidade entre computadores: pode ser utilizada tanto em um computador
pessoal, passando por uma estao de trabalho, como em computador de grande
porte.
Reduo dos custos com treinamento: baseado no item anterior, as aplicaes
podem se movimentar de um ambiente para o outro sem que seja necessria uma
reciclagem da equipe de desenvolvimento.
Ingls estruturado de alto nvel: a SQL formada por um conjunto bem simples
de sentenas em ingls, oferecendo um rpido e fcil entendimento.
Consulta interativa: a SQL prov acesso rpido aos dados, fornecendo respostas
ao usurio, a questes complexas, em minutos ou segundos.
Mltiplas vises dos dados: permite ao criador do banco de dados levar diferen-
tes vises dos dados a vrios usurios.
Definio dinmica dos dados: com a SQL possvel alterar, expandir ou incluir,
dinamicamente, as estruturas dos dados armazenados com a mxima flexibilidade.
Apesar de todas essas vantagens, algumas crticas so dirigidas SQL:
A padronizao leva a uma, natural, inibio da criatividade, pois quem desenvolve
aplicaes fica preso a solues padronizadas, no podendo sofrer melhorias ou
alteraes.
A SQL est longe de ser uma linguagem relacional ideal - segundo C. J. Date em
seu livro Relational Database: Selected Writing (Addison - Werley, 1986), algumas
crticas so feitas linguagem SQL:
- Falta de ortogonalidade nas expresses, funes embutidas, variveis indica-
doras, referncia a dados correntes, constante NULL, conjuntos vazios etc.
- Definio formal da linguagem aps sua criao.
- Discordncia com as linguagens hospedeiras.
- Falta de algumas funes.
- Erros (valores nulos, ndices nicos, clusula FROM etc.).
- No d suporte a alguns aspectos do modelo relacional (atribuio de relao,
join explcito, domnios etc.).
SQL 309
Mesmo enfrentando alguns problemas e crticas, a linguagem SQL veio para ficar,
auxiliando de forma bastante profunda a vida dos usurios e analistas no trabalho de
manipulao dos dados armazenados em um banco de dados relacional.
E sobre esse auxlio que o captulo trata, mostrando comandos e funcionalidades da
SQL com exemplos prticos.
No vamos mostrar todos os comandos, principalmente os que foram definidos para
serem utilizados dentro de uma linguagem hospedeira (cursor), porm apresentamos os
comandos para criao, atualizao, alterao, pesquisa e eliminao de tabelas dentro de um
ambiente relacional tpico.
Alm dos comandos da SQL padro ANSI, vamos apresentar a sintaxe de comandos
SQL efetuados no MS-SQL Server 2008, um produto da Microsoft.
O Exemplo
Todo o percurso pela linguagem SQL ser efetuado com base no exemplo de modelo
de dados apresentado na figura a seguir, criado no captulo sobre normalizao, quando da
apresentao das trs principais formas normais.
A seguir, so apresentadas as tabelas referentes ao modelo.
Tabela Cliente
Cd. do Nome do
Endereo Cidade CEP UF CNPJ IE
Cliente Cliente
720 Ana Rua 17 n. 19 Niteri 24358310 RJ 12113231/0001-34 2134
870 Flvio Av. Pres. Vargas 10 So Paulo 22763931 SP 22534126/9387-9 4631
110 Jorge Rua Caiapo 13 Curitiba 30078500 PR 14512764/9834-9
222 Lcia Rua Itabira 123 Loja 9 Belo Horizonte 22124391 MG 28315213/9348-8 2985
830 Maurcio Av. Paulista 1236 sl 2345 So Paulo 3012683 SP 32816985/7465-6 9343
130 Edmar Rua da Praia sn Salvador 30079300 BA 23463284/234-9 7121
410 Rodolfo Largo da Lapa 27 sobrado Rio de Janeiro 30078900 RJ 12835128/2346-9 7431
20 Beth Av. Climrio 45 So Paulo 25679300 SP 32485126/7326-8 9280
157 Paulo Tv. Moraes c/3 Londrina PR 32848223/324-2 1923

Cd. do Nome do
Cliente Cliente
180 Lvio Av. Beira Mar n. 1256 Florianpolis 30077500 SC 12736571/2347-4
260 Susana Rua Lopes Mendes 12 Niteri 30046500 RJ 21763571/232-9 2530
290 Renato Rua Meireles 123 bl.2 sl. 345 So Paulo 30225900 SP 13276571/1231-4 1820
390 Sebastio Rua da Igreja 10 Uberaba 30438700 MG 32176547/213-3 9071
234 Jos Quadra 3 bl. 3 sl. 1003 Braslia 22841650 DF 21763576/1232-3 2931
Tabela Vendedores
Cdigo do Vendedor Nome do Vendedor Salrio Fixo Faixa de Comisso

209 Jos 1.800,00 C
111 Carlos 2.490,00 A
11 Joo 2.780,00 C
240 Antnio 9.500,00 C
720 Felipe 4.600,00 A
213 Jonas 2.300,00 A
101 Joo 2.650,00 C
310 Josias 870 B
250 Maurcio 2.930,00 B
Tabela Pedido
Nmero do Pedido Prazo de Entrega Cdigo do Cliente Cdigo do Vendedor

121 20 410 209
97 20 720 101
101 15 720 101
137 20 720 720
148 20 720 101
189 15 870 213
104 30 110 101
203 30 830 250
98 20 410 209
143 30 20 111
105 15 180 240
111 20 260 240
103 20 260 11
91 20 260 11
138 20 260 11
108 15 290 310
119 30 390 250
127 10 410 11
SQL 311
Tabela Produto
Cdigo do Produto Unidade do Produto Descrio do Produto Valor Unitrio

25 Kg Queijo 0,97
31 BAR Chocolate 0,87
78 L Vinho 2
22 M Linho 0,11
30 SAC Acar 0,3
53 M Linha 1,8
13 G Ouro 6,18
45 M Madeira 0,25
87 M Cano 1,97
77 M Papel 1,05
Tabela Item de Pedido
Nmero do Cdigo do Nmero do Cdigo do

Quantidade Quantidade
Pedido Produto Pedido Produto
121 25 10 143 78 10
121 31 35 105 78 10
97 77 20 111 25 10
101 31 9 111 78 70
101 78 18 103 53 37
101 13 5 91 77 40
98 77 5 138 22 10
148 45 8 138 77 35
148 31 7 138 53 18
148 77 3 108 13 17
148 25 10 119 77 40
148 78 30 119 13 6
104 53 32 119 22 10
203 31 6 119 53 43
189 78 45 137 13 8
143 31 20
As informaes das tabelas sero utilizadas pelos comandos SQL, apresentados ao

longo deste captulo.

Criao e Distribuio de Tabelas
So as operaes para que seja possvel criar e inserir as tabelas de uma aplicao em
banco de dados, dependendo do ambiente de SGBD que estivermos utilizando, criar o
database, ou seja, criar um banco de dados em que residiro as tabelas de nosso sistema.
Por exemplo, no Microsoft SQL Server 2008 essa operao realizada normalmente
por equipes de suporte. Consiste em dois passos, no mnimo, que so pela ordem:
1. Inicializar os arquivos em que sero armazenados os databases das aplicaes
(devices);
Esta uma criao de nomes fsicos e lgicos e determinao do tamanho da rea
em meio magntico desse device. No Microsoft SQL Server 2008 o comando
utilizado o DISK INIT, mas no objeto de nosso estudo.
2. Criar os databases nos devices j criados anteriormente.
Para isso vamos ao Microsoft SQL Server 2008 usar o comando CREATE DATABASE
com a sintaxe seguinte:
CREATE DATABASE database_name

[ON {DEFAULT| database_device} [= size]
[,database_device [= size] ]]
[LOG ON database_device [= size]
[, database_device [= size] ]]
Exemplos:
CREATE DATABASE vendas
Cria o database vendas no device default com tamanho default de 2 MB.

CREATE DATABASE vendas ON default = 256
Cria o database vendas no device default com 256 MB.

CREATE DATABASE vendas ON default = 50, novosdados = 25
Cria o database vendas e aloca 50 MB no device default e 25 MB no device

novosdados.
CREATE DATABASE vendas ON library_dev1 = 10 LOG ON librlog_dev2 = 4
Cria o database vendas, aloca 10 MB em library_dev1 e coloca 4 MB para log de

transaes num device separado chamado librlog_dev2.
Uma vez que j criamos o database, ou seja, o banco de dados da aplicao, podemos
partir para a criao das tabelas.
SQL 313
Criao de Tabelas
O comando CREATE TABLE cria a tabela solicitada e obedece seguinte forma na
linguagem SQL padro:
CREATE TABLE <tabela>

(<descrio das colunas>);
(<descrio das chaves>);
em que:
<tabela>: o nome da tabela a ser criada.
<descrio das colunas>: uma lista de colunas (campos) e seus respectivos
tipos de dados. O tipo determinado quando a tabela criada e no pode ser
alterado posteriormente. Os tipos de dados existentes so:
Para dados Tipo Tamanho

Caractere char(n), varchar(n), nvarchar(n), nchar(n) at n bytes
Numrico exato decimal(p,e) ou numeric(p,e) depende
Numrico aproximado float, real 8, 4 bytes
Numrico inteiro int, smallint, tinyint 4, 2, 1 byte
Monetrio money, smallmoney 8, 4 bytes
Data e hora datetime, smalldatetime 8, 4 bytes
Binrio binary(n), varbinary(n) n bytes
Texto e imagens text, image, ntext -varivel-
Outros bit, timestamp 1 bit, 8 bytes
Para dados contendo caracteres, char(n), ser armazenado um nmero fixo de caracte-
res. Por exemplo, uma coluna do tipo char(30) tem sempre 30 caracteres. Se forem informados
menos, o restante ser completado com espaos. J o tipo varchar(n) armazena uma quantida-
de varivel de caracteres at o mximo informado. Os tipos nchar(n) e nvarchar(n) armazenam
dados Unicode, de comprimento fixo ou varivel, e usam o conjunto de caracteres UNICODE
UCS-2.(Microsoft SQL Server 2008).
Por exemplo, decimal (9,2) permite guardar sete dgitos antes do ponto decimal e dois
aps, num total de nove, assim o maior valor possvel 9999999,99.
Os tipos numricos inexatos, float e real, armazenam dados numricos, mas nem
sempre mantm a preciso suficiente para armazenar corretamente nmeros de vrios dgitos.
O tipo money usado para valores monetrios, ocupando 8 bytes em disco e permi-
tindo valores entre -922.337.203.685.477,5808 e +922.337.203.685.477,5807 (922 trilhes). O
tipo smallmoney permite valores entre - 214.748,3648 e +214.748,3647 (214 mil) e ocupa
4 bytes em disco.

Dos tipos inteiros, int usa 32 bits (4 bytes), permitindo armazenar at +/-2.147.483.647,
smallint usa 16 bits (2 bytes), permitindo +/-32767 e tinyint usa 8 bits (1 byte), permitindo
nmeros no negativos de 0 a 255.
O tipo datetime armazena valores contendo a data e hora, com preciso de 1/300 de
segundo, entre 1 de janeiro de 1753 e 31 de dezembro de 9999 (o sculo sempre arma-
zenado). O tipo smalldatetime ocupa menos espao e armazena datas e horas de 1 de janeiro
de 1900 at 6 de junho de 2079 com preciso de 1 minuto.
Tipos binrios so usados para dados que o Microsoft SQL Server 2008 no
interpreta, por exemplo, o contedo de um arquivo binrio. O tipo text usado para colunas
com dados "memo", ou seja, com texto de tamanho varivel; o tipo ntext armazena dados
Unicode de tamanho varivel. O tipo image armazena imagens tambm de tamanho varivel.
Os tipos text e ntext armazenam dados de tamanho varivel, mas podem armazenar
1.073.741.823 caracteres para o caso do ntext, e 2.146.483.647 caracteres para o caso do tipo
text. Enquanto isso, os tipos varchar e nvarchar armazenam "somente" 8.000 caracteres
(varchar) ou 4.000 caracteres (nvarchar).
O tipo bit armazena valor 1 ou 0. Uma coluna do tipo timestamp no pode ser alterada
pelo usurio. Ela definida automaticamente com a data e hora atual quando a linha inserida
ou atualizada.
Os tipos "numricos exatos", decimal e numeric, permitem armazenar dados exatos,
sem perdas devido a arredondamento. Ao usar esses tipos, voc pode especificar uma
preciso, que indica quantos dgitos podem ser usados no total e uma escala, que indica
quantos dgitos podem ser usados direita do ponto.
Alguns campos podem receber o valor NULL (nulo) e o campo definido como chave
primria, alm de no poder receber nulo (NOT NULL), deve ser um campo UNIQUE (sem
repeties - chave primria). Para o banco de dados da figura anterior temos os seguintes
comandos:
<descrio das chaves>: a lista de colunas tratadas como chave estrangeira.
Ento, para o nosso modelo de dados temos:
CREATE TABLE CLIENTE
(codigo_cliente smallint not null unique,
nome_cliente char(20),
endereco char(30),
cidade char(15),
CEP char(8),
UF char(2),
CNPJ char(20),
IE char(20));
CREATE TABLE PEDIDO

numero_pedido int not null unique,
prazo_de_entrega smallint not null,
codigo_cliente smallint not null,
codigo_vendedor smallint not null,
SQL 315
FOREIGN KEY (codigo_cliente
REFERENCES CLIENTE,
FOREIGN KEY (codigo_vendedor)
REFERENCES VENDEDORES);
CREATE TABLE ITEM_DE_PEDIDO

(numero_pedido int not null unique,
codigo_produto smallint not null unique,
quantidade decimal,
FOREIGN KEY (numero_pedido)
REFERENCES PEDIDO,
FOREIGN KEY (codigo_produto)
REFERENCES PRODUTO);
Observe que a clusula REFERENCE estabelece a restrio de integridade referencial

entre as tabelas no SQL padro, porm s podemos incluir essas restries se as tabelas
referidas na clusula REFERENCE j foram criadas antes desta.
No Microsoft SQL Server 2008 a integridade referencial necessita de um acrscimo
na estrutura da sintaxe do comando com a incluso da declarao de uma constraint. As
constraints so propriedades que devem ser declaradas para determinadas colunas, como
chaves primrias e chaves estrangeiras.
Essas propriedades implicam em regras de validao para essas colunas, objetivando
impedir operaes de incluso, alterao ou deleo que possam tornar os dados do banco de
dados inconsistentes.
Quando desejamos criar a chave primria da tabela no prprio comando CREATE, a
sintaxe do Microsoft SQL Server 2008 a seguinte:
CREATE TABLE CLIENTE
(codigo_cliente smallint not null unique,
nome_cliente char(20),
endereco char(30),
cidade char(15),
CEP char(8),
UF char(2),
CNPJ char(20),
IE char(20) )
CONSTRAINT PK_Cliente Primary Key (codigo_cliente);
Desta forma a tabela cliente foi criada com a chave primria com restrio (constraint).
Como em nosso exemplo a tabela produto ainda no foi criada, teramos um erro ao
executar esses comandos. A tabela item de pedido deve ser criada aps a tabela produto.
Da mesma forma a tabela pedido somente pode ser criada com a restrio de integri-
dade referencial aps a criao de cliente e vendedor.
Esses fatores de sequncia de criao so muitas vezes ignorados por quem executa
a criao das tabelas do banco de dados, sendo muito comum para a fuga do erro, realizar a
criao das tabelas sem especificar a clusula REFERENCE. Posteriormente ao processo
de criao, utilizar-se o comando ALTER TABLE, para realizar a insero das restries de
integridade referencial, como mostraremos quando da apresentao deste comando.

CREATE TABLE VENDEDORES
(codigo_vendedor smallint not null,
nome_vendedor char(20),
salario_fixo money,
faixa_de_comissao char(1)
PRIMARY KEY (codigo_vendedor));
Note que a chave primria j est definida juntamente com o registro da tabela. A
criao do ndice, por razes bvias, aps a tabela, naturalmente um comando totalmente
independente do primeiro comando create, que serviu para criar a tabela e suas caracterstica
bsicas.
CREATE TABLE PRODUTO
(codigo_produto smallint not null unique,
unidade_produto char(3),
descricao_produto char(30),
val_unitario money
CONSTRAINT PK_Produtos Primary Key (codigo_produto));
No SQL Server e no Oracle, a integridade referencial baseia-se nas relaes entre

chaves estrangeiras e chaves primrias ou entre chaves estrangeiras e chaves exclusivas, por
meio de restries FOREIGN KEY e CHECK. A integridade referencial assegura que os
valores chave permaneam consistentes em todas as tabelas. Esse tipo de consistncia requer
que no haja referncias a valores no existentes e que se um valor chave alterado, todas as
referncias a ele so consistentemente alteradas em todo o banco de dados.
Cha ve Pr im ria
Chave Es trangeira
C ha ve Prim ria
Nmero do Pedido Cdigo do Prod ut o Quant idade
121 25 10 Cdigo do Unidad e do Descrio do Valor

Produto Produ to Produto Unitrio
121 31 35
25 Kg Queijo 0,97
97 77 20
31 BAR Chocolate 0,87
101 31 9
78 L Vinho 2
101 78 18
101 13 5
Criao de Chaves Primrias Compostas

At este momento criamos a tabela item_de_pedido sem declarao nenhuma de chave
primria. Criamos somente com as chaves estrangeiras.
Vamos analisar essa tabela para cri-la com chave primria.
Em nosso modelo de dados essa tabela representa uma entidade associativa entre
pedido e produto, logo sua chave primria ser composta das duas chaves primrias das
tabelas adjacentes do relacionamento, produto e pedido.
CREATE TABLE ITEM_DE_PEDIDO
(numero_pedido int not null unique,
codigo_produto smallint not null unique,
quantidade decimal,
SQL 317
CONSTRAINT PK_ ITEM_DE_PEDIDO
PRIMARY KEY (numero_pedido, codigo_produto)
CONSTRAINT FK_ PEDIDO
FOREIGN KEY (numero_pedido)
REFERENCES PEDIDO
CONSTRAINT FK_ PRODUTO
FOREIGN KEY (codigo_produto)
REFERENCES PRODUTO);
Eliminao de uma Tabela

Para eliminar uma tabela criada, utiliza-se o comando DROP:
Sintaxe Bsica
DROP TABLE <tabela>;
Exemplo:
DROP TABLE PEDIDO
Elimina a tabela de pedidos que foi previamente criada, seus dados e suas referncias
a outras tabelas. Esse comando somente resulta erro se existir alguma tabela que seja
dependente dele quando da criao.
Por exemplo, se existe no nosso caso a tabela item de pedido e j criamos as restries
de integridade referencial, o comando retorna erro, pois no ser permitida a eliminao da
tabela por existirem referncias a ela em outra tabela.
Alterao da Estrutura das Tabelas

Depois que uma tabela for criada, possvel mudar vrias das opes que foram
definidas quando a tabela foi originalmente criada, incluindo:
Colunas podem ser acrescentadas, modificadas ou excludas. Por exemplo, o nome da
coluna, comprimento, tipo de dados, preciso, escala e o fato de aceitar ou no valores nulos
podem ser mudados, embora existam algumas restries.
As restries PRIMARY KEY e FOREIGN KEY podem ser acrescentadas ou excludas.
importante considerar que a mudana de tipo de dados em uma coluna pode causar
truncamento dos dados, ou mesmo ser impossvel de ser feita (por exemplo, se voc quiser
converter um tipo char em um tipo inteiro e j houver valores no numricos armazenados
nessa coluna).
O nome ou o dono de uma tabela tambm pode ser modificado.
Quando voc faz isso, tambm deve mudar o nome da tabela em qualquer proce-
dimento armazenado, scripts SQL, ou outro cdigo de programao que utilize o nome ou
proprietrio antigo da tabela.

Para alterar uma tabela, utiliza-se o comando ALTER TABLE.
Adicionar uma chave primria (PRIMARY KEY) feito com a incluso de uma restrio
na tabela, uma constraint, e a sua sintaxe :
ALTER TABLE cliente
ADD Constraint PK_Cliente
Primary Key (codigo_cliente)
Se quando da execuo do ALTER TABLE j existirem dados na tabela, o SQL verifica

se existem dados repetidos nessa coluna. Se no existirem, a chave primria ser criada com
sucesso; caso contrrio, ser emitida uma mensagem de erro do banco, e a chave primria
no ser acrescentada tabela.
Adicionar uma chave estrangeira (FOREIGN KEY/REFERENCES) tambm se realiza
com a incluso de uma restrio na tabela, uma constraint, e a sua sintaxe :
ALTER TABLE pedido
ADD Constraint FK_Pedido
Foreign Key (codigo_cliente)
References Cliente(codigo_cliente)
Da mesma forma se j existirem dados na tabela pedido, verificado se os valores

existentes na coluna codigo_cliente da tabela pedido existem na tabela cliente na mesma
coluna. Se todos existirem, o comando executado com sucesso e a chave estrangeira
criada na tabela; caso contrrio, ser emitida mensagem de erro e no ser acrescentada a
chave estrangeira.
Para acrescentar colunas a uma tabela, a sintaxe :
ALTER TABLE produto
ADD tipo_produto Char(20) NULL
Se considerarmos que j havamos criado a tabela produto e carregado seus dados co-
mo na tabela apresentada no incio deste captulo, teremos agora a seguinte tabela resultado:
Cdigo do Produto Unidade do Produto Descrio do Produto Valor Unitrio Tipo Produto
25 Kg Queijo 0,97 Null
31 BAR Chocolate 0,87 Null
78 L Vinho 2 Null
22 M Linho 0,11 Null
30 SAC Acar 0,3 Null
53 M Linha 1,8 Null
13 G Ouro 6,18 Null
45 M Madeira 0,25 Null
87 M Cano 1,97 Null
77 M Papel 1,05 Null
Observe que foi colocada a coluna como NULL para permitir que voc insira dados nas
linhas da tabela j existente, mesmo que esses dados venham a ter caractersticas de serem
SQL 319
sempre obrigatrios. Desta forma voc vai inserir valores na coluna em todas as linhas e
depois modificar novamente a coluna para NOT NULL.
ALTER TABLE produto
ALTER COLUMN tipo_produto Char(20) NOT NULL
E da mesma forma podemos agora retirar esta coluna da tabela:

ALTER TABLE produto
DROP COLUMN tipo_produto
E nossa tabela volta situao anterior.

No caso de a tabela possuir uma coluna que tem uma constraint associada, voc deve
primeiro eliminar a constraint para depois realizar a alterao de eliminar a coluna.
Digamos que queremos eliminar a coluna codigo_cliente da tabela pedido, porm ela
possui uma propriedade de constraint, pois uma chave estrangeira.
ALTER TABLE pedido
DROP Constraint FK_Pedido
ALTER TABLE pedido
DROP COLUMN codigo_cliente
Em alguns casos possvel alterar o datatype de uma coluna.

Vamos supor que queremos alterar na tabela Produto o datatype da coluna unidade de
CHAR(3) para Int.
Obviamente isso no possvel se j carregamos dados na tabela, pois a coluna
contm dados no formato caractere que no podem ser convertidos em nmeros. Mas se, por
exemplo, desejssemos transformar a coluna valor_unitario em caractere, seria possvel, pois
podemos transformar um datatype money em char.
ALTER TABLE produto
ALTER COLUMN valor_unitario char (12)
Coluna Calculada
No Microsoft SQL Server 2008 podemos ter uma tabela com colunas calculadas que
no existem fisicamente, pois no so armazenadas. No possuem datatype nem condio de
NULL, j que assumem esses valores das expresses que as definem, mas podem ser
definidas quando da criao da tabela.
salario_fixo money,
faixa_de_comissao char(1),
Comissao_maxima as salario_fixo * 2,
Constraint PK_VENDEDORES
Primary Key (codigo_vendedor)

Criao de Aes em Cascata
A Clusula ON DELETE CASCADE e ON UPDATE CASCADE

Esta uma clusula que deve ser utilizada com muito critrio quando construmos um
banco de dados pelos riscos implcitos na sua utilizao, porm ela de grande valia na
garantia de integridade referencial no banco de dados.
A utilizao de uma clusula ON DELET CASCADE em uma declarao de constraint
de FOREIGN KEY especifica que se houver uma tentativa de apagar uma linha com uma
chave primria referenciada por chaves estrangeiras em linhas existentes em outras tabelas,
tambm sero apagadas todas as linhas que contm essas chaves estrangeiras.
Vejamos ento um comando possvel no nosso exemplo:
ALTER TABLE Pedido
Foreign Key (codigo_cliente)
References cliente(codigo_cliente)
ON DELETE CASCADE;
O que implica na operao das tabelas a existncia de ON DELETE CASCADE?

Se for deletada alguma linha de cliente que tenha referncia em pedido, as linhas
correspondentes de pedido tambm sero deletadas.
A opo de ON UPDATE CASCADE impede que sejam feitas mudanas na chave
referenciada caso existam linhas referenciando o valor desta.
Caso fosse possvel mudar o valor de uma chave primria de cliente, a existncia de
ON UPDATE CASCADE na tabela pedido provocaria a alterao dos valores das chaves
estrangeiras associadas ao valor original.
ALTER TABLE Pedido
Foreign Key (Codigo_cliente)
References Cliente(Codigo_cliente)
ON DELETE CASCADE
ON UPDATE CASCADE;
Podemos utilizar as duas clusulas juntas sem problema.
Regras de Validao
Vamos considerar que nossa tabela de vendedores s permita por regra de negcio a
existncia de trs faixas de comisso: A, B e C.
Desta forma no queremos permitir em hiptese nenhuma que seja cadastrado um
vendedor, por exemplo, com faixa D.
SQL 321
Para isso utilizamos uma constraint check.
salario_fixo money,
faixa_comissao char(1),
Comissao_maxima as salario_fixo * 2,
Constraint PK_VENDEDORES
Primary Key (codigo_vendedor),
CONSTRAINT CH_Vendedor
Check (faixa_comissao IN ('A', 'B', 'C'))
Como apresentamos em modelo fsico, voc pode aqui colocar a regra de negcio de
cada coluna por meio de um constraint check.
Voc pode tambm assinalar valores default para s colunas atravs de uma constraint
default como no exemplo para a faixa de comisso tambm.
faixa_de_comissao char(1) CONSTRAINT DF_Vendedores Default 'A'
As constraints, quando criadas aps a carga dos dados, podem ser utilizadas para
validar os contedos e valores das colunas, pois se houver valores em desacerto com os
checks definidos, por exemplo, ser emitida mensagem de erro.
Extrao de Dados de uma Tabela: SELECT

Uma das operaes mais comuns, realizadas com um banco de dados, examinar
(selecionar) as informaes armazenadas. Essas operaes so realizadas pelo comando
SELECT.
Neste item vamos mostrar vrias situaes de utilizao do comando SELECT.
O comando SELECT tem palavras-chave em um comando bsico:
SELECT: especifica as colunas da tabela que queremos selecionar.
FROM: especifica as tabelas.
WHERE: especifica a condio de seleo das linhas.
Seleo de Colunas Especficas da Tabela
Sintaxe Bsica
select <nome(s) da(s) coluna(s)>

from <tabela>;

Problema: Listar todos os produtos com respectivas descries, unidades e valores unitrios.
Diagrama: Sintaxe:
SELECT unidade_produto, descricao_produto,
valor_unitario
FROM produto;
O que equivale em lgebra relacional a:
UNIDADE_PRODUTO, DESCRICAO_PRODUTO, VALOR_UNITARIO (PRODUTO)
A execuo deste comando neste formato lista todas as linhas da tabela produto, pois
no apresenta nenhuma condio para a projeo dos dados.
SELECT sem WHERE lista todas as linhas de uma tabela.
Resultado:
Descrio Unidade Valor Unitrio

Queijo Kg 0,97
Chocolate BAR 0,87
Vinho L 2,00
Linho M 0,11
Acar SAC 0,30
Linha M 1,80
Ouro G 6,18
Madeira M 0,25
Cano M 1,97
Papel M 1,05
Problema: Listar da tabela CLIENTE o CNPJ, o nome do cliente e seu endereo.
Diagrama: no caso cumpre destacar que estamos

realizando a seleo de colunas especficas da tabela e
apresentando o resultado com a disposio dos campos
diferente da ordem em que se encontram na tabela.
SQL 323
Sintaxe:
SELECT CNPJ, nome_cliente, endereco
FROM cliente;
Resultado:
CNPJ Nome do Cliente Endereo

12113231/0001-34 Ana Rua 17 n. 19
22534126/9387-9 Flvio Av. Pres. Vargas 10
14512764/98349-9 Jorge Rua Caiapo 13
28315213/9348-8 Lcia Rua Itabira 123 Loja 9
32816985/7465-6 Maurcio Av. Paulista 1236 sl/2345
23463284/234-9 Edmar Rua da Praia sn/
12835128/2346-9 Rodolfo Largo da Lapa 27 sobrado
32485126/7326-8 Beth Av. Climrio n. 45
32848223/324-2 Paulo Tv. Moraes c/3
1273657/2347-4 Lvio Av. Beira Mar n. 1256
21763571/232-9 Susana Rua Lopes Mendes 12
13276571/1231-4 Renato Rua Meireles n. 123 bl.2 sl.345
32176547/213-3 Sebastio Rua da Igreja n. 10
2176357/1232-3 Jos Quadra 3 bl. 3 sl. 1003
Seleo de Todas as Colunas da Tabela
Sintaxe Bsica
SELECT *
FROM <tabela>;
Problema: Listar todo o contedo de vendedor.
Diagrama: Sintaxe ANSI1:

SELECT *
FROM vendedores;
1 A utilizao do comando SELECT sem a clusula WHERE causa uma desnecessria carga nos recursos de sistema. Por esta
razo, em SQL Server 2008 ou em qualquer outro SGBD utilize sempre a clusula WHERE.

Resultado:
Cdigo do Vendedor Nome do Vendedor Salrio Fixo Faixa de Comisso

209 Jos 1.800,00 C
111 Carlos 2.490,00 A
11 Joo 2.780,00 C
240 Antnio 9.500,00 C
720 Felipe 4.600,00 A
213 Jonas 2.300,00 A
101 Joo 2.650,00 C
310 Josias 870,00 B
250 Maurcio 2.930,00 B
Alterao do Heading (Cabealho) da Coluna

Por default, o heading (nome da coluna criado no database) apresentado na sada do
SELECT o nome da coluna na tabela (Ver comando CREATE).
O SQL permite que se apresente a sada de um SELECT com cabealhos de colunas a
nosso gosto.
Sintaxe Bsica
SELECT cabealho da coluna = nome da coluna, [, nome da coluna]

FROM nome da tabela
Exemplo:
SELECT numero = codigo_vendedor,
nome = nome_vendedor,
rendimentos = salario_fixo,
comissao = faixa_de_comissao
FROM vendedores
Resultado:
Nmero Nome Rendimentos Comisso

209 Jos 1.800,00 C
111 Carlos 2.490,00 A
11 Joo 2.780,00 C
240 Antnio 9.500,00 C
720 Felipe 4.600,00 A
213 Jonas 2.300,00 A
101 Joo 2.650,00 C
310 Josias 870,00 B
250 Maurcio 2.930,00 B
SQL 325
Manipulao de Dados Numricos: Operadores Aritmticos
Operadores aritmticos podem ser usados em qualquer coluna numrica, incluindo
colunas de tipo de dado int, smallint, tinyint, float, real, money ou smallmoney 2.
Os operadores aritmticos so:
Smbolo Operao Pode ser usado com (Microsoft SQL Server 2008)
+ Adio Int, smallint, tinyint, numeric, decimal, float, real, money and smallmoney
- Subtrao Int, smallint, tinyint, numeric, decimal, float, real, money and smallmoney
/ Diviso Int, smallint, tinyint, numeric, decimal, float, real, money and smallmoney
* Multiplicao Int, smallint, tinyint, numeric, decimal, float, real, money and smallmoney
% Mdulo Int, smallint e tinyint
Exemplo:
SELECT nome_vendedor,
salario_fixo = (salario_fixo * 2)
FROM vendedores
Nome do Vendedor Salrio Fixo

Jos 3,600.00
Carlos 4,980.00
Joo 5,560.00
Antnio 19,000.00
Felipe 9,200.00
Jonas 4,600.00
Joo 5,300.00
Josias 1,740.00
Maurcio 5,860.00
O resultado apresenta os salrios com valores multiplicados por dois.
Seleo de Somente Algumas Linhas da Tabela

A clusula WHERE em um comando SELECT especifica quais linhas queremos obter
baseada em condies de seleo.
Chamamos isso de observar uma seleo horizontal de informaes e estamos apli-
cando uma operao de lgebra relacional seleo.
2 Datatypes de SQL Server 2008.

Sintaxe Bsica
SELECT <nome(s) da(s) coluna(s)>

FROM <tabela>
WHERE <condies de seleo>;
Comparaes na Clusula WHERE

WHERE <nome da coluna> <operador> <valor>
Operadores de Comparao
= igual
<> ou != diferente
< menor do que
> maior do que
>= maior ou igual do que
!> no maior
!< no menor
<= menor ou igual do que
Quando a coluna do tipo caractere, o <valor> deve estar entre aspas ( ' ).
Exemplo: 'PARAFUSO'
Na linguagem SQL existe a diferenciao entre maisculas e minsculas em alguns
SGBDs, logo 'PARAFUSO' diferente de 'parafuso'.
Problema: Listar o num_pedido, o cdigo_produto e a quantidade dos itens do pedido com a

quantidade igual a 35 da tabela item_de_pedido.
Diagrama:
Sintaxe:
SELECT numero_pedido, codigo_produto, quantidade
FROM item_de_pedido
WHERE quantidade = 35;
SQL 327
Resultado:
Nmero do Pedido Cdigo do Produto Quantidade

121 31 35
138 77 35
Problema: Quais so os clientes que moram em Niteri?
Diagrama: Sintaxe:
SELECT nome_cliente
FROM cliente
WHERE cidade = 'Niteroi';
Resultado:
Nome do Cliente
Ana
Susana
Operadores Lgicos
AND "e" lgico

OR "ou" lgico
NOT negao
Problema: Listar os produtos que tenham unidade igual a 'M' e valor unitrio igual a R$ 1,05
da tabela produto.
Diagrama: Sintaxe:
SELECT descricao_produto
FROM produto
WHERE unidade_produto = 'M' AND
valor_unitario = 1.05;
Resultado:
Descrio do Produto
Papel

Problema: Listar os clientes e seus respectivos endereos, que moram em 'SO PAULO' ou
estejam na faixa de CEP entre '30077000' e '30079000'.
Diagrama:
Sintaxe:
SELECT nome_cliente, endereco
FROM cliente
WHERE (CEP >= '30077000' AND CEP <= '30079000')
OR cidade = 'Sao Paulo';
Isso equivale em lgebra relacional a:
NOME_CLIENTE, ENDERECO ( (CEP >= '30077000' AND CEP <= '30079000')

OR CIDADE = 'SAO PAULO' (CLIENTE))
Resultado:
Nome do Cliente Endereo do Cliente

Flvio Av. Pres. Vargas 10
Jorge Rua Caiapo 13
Maurcio Av. Paulista 1236 sl/2345
Rodolfo Largo da Lapa 27 sobrado
Beth Av. Climrio n. 45
Lvio Av. Beira Mar n. 1256
Renato Rua Meireles n. 123 bl.2 sl.345
A utilizao dos parnteses fundamental para a construo correta da sentena, pois

sem eles as consultas podem ser analisadas de forma errada, devido prioridade do operador
AND ser maior que a prioridade do operador OR.
Problema: Mostrar todos os pedidos que no tenham prazo de entrega igual a 15 dias.
SQL 329
Diagrama:
Sintaxe:
SELECT numero_pedido
FROM pedido
WHERE NOT (prazo_de_entrega = 15);
NUMERO_PEDIDO ( PRAZO_DE_ENTREGA <> 15 (PEDIDO))

Ou podemos alternativamente utilizar um operador de comparao <> que vai realizar a
mesma operao de seleo.
Sintaxe:
SELECT numero_pedido
FROM pedido
WHERE (prazo_de_entrega <> 15);
Resultado:
Nmero do Pedido
121
97
137
148
104
203
98
143
111
103
91
138
119
127

Operadores Between e NOT Between
WHERE <nome da coluna> BETWEEN <valor1> AND <valor2>

WHERE <nome da coluna> NOT BETWEEN <valor1> AND <valor2>
Esse operador propicia a pesquisa por uma determinada coluna e selecionando as

linhas cujo valor da coluna esteja dentro de uma faixa determinada de valores, sem a
necessidade dos operadores >=, <= e AND. Tanto o VALOR1 quanto o VALOR2 precisam ser
do mesmo tipo de dado da coluna.
Quando executado sobre colunas do tipo char, varchar, text, datetime e smalldatetime,
devemos colocar estes valores entre aspas.3
Problema: Listar o cdigo e a descrio dos produtos que tenham o valor unitrio na faixa de
R$ 0,32 at R$ 2,00.
Diagrama:
Sintaxe:
SELECT codigo_produto, descricao_produto
FROM produto
WHERE valor_unitario between 0.32 and 2.00;
Resultado:
Cdigo do Produto Descrio

25 Queijo
31 Chocolate
78 Vinho
53 Linha
87 Cano
77 Papel
3 Especificao para SQL Server 2008.
SQL 331
Operadores Baseados em String de Caracteres LIKE e NOT LIKE
WHERE <nome da coluna> LIKE <valor>;

WHERE <nome da coluna> NOT LIKE <valor>;
Os operadores LIKE e NOT LIKE s trabalham com colunas que sejam do tipo CHAR.
Eles tm praticamente o mesmo funcionamento que os operadores = e < > , porm o poder
desses operadores est na utilizao dos smbolos (%) e (_) que podem fazer o papel de
"curinga":
% substitui uma palavra

_ substitui um caractere
Exemplo:
LIKE 'LPIS %' pode enxergar os seguintes registros:
'LAPIS PRETO'
'LAPIS CERA'
'LAPIS BORRACHA'
Ou seja, todos os registros que contenham 'LPIS' seguido de qualquer palavra ou

conjunto de caracteres.
LIKE 'BROCA N_' pode enxergar os seguintes registros:
'BROCA N1'
'BROCA N9'
'BROCA N3'
LIKE '%o_' pode enxergar qualquer nome que termine em "o".

LIKE '[CM]%' permite enxergar qualquer nome que comece com 'C ' ou com 'M'.
LIKE '[C-X]%' permite enxergar qualquer nome que comece com 'C ' at 'X.
LIKE 'M[^o]%' permite enxergar qualquer nome que comece com 'M' e no tenha 'o'
como segunda letra.
Vamos ver mais alguns exemplos de utilizao da clusula LIKE.
Problema: Listar todos os produtos cujo nome comece por Q.
Diagrama: Sintaxe:
FROM produto
WHERE descricao_produto LIKE 'Q_';

Resultado:
Cdigo do Produto Descrio

25 Queijo
Problema: Listar os vendedores que no comeam por 'Jo'.
Diagrama:
Sintaxe ANSI e Microsoft SQL Server 2008:

SELECT codigo_vendedor, nome_vendedor
FROM vendedores
WHERE nome_vendedor NOT LIKE 'Jo%';
Resultado NOT LIKE:
Cdigo do Vendedor Nome do Vendedor

111 Carlos
240 Antnio
720 Felipe
250 Maurcio
Operadores Baseados em Listas IN e NOT IN
WHERE <nome da coluna> IN <valores>;

WHERE <nome da coluna> NOT IN <valores>;
Estes operadores pesquisam registros que esto ou no no conjunto de <valores>

fornecido. Eles minimizam o uso dos operadores =, <>, AND e OR.
Problema: Listar os vendedores que so da faixa de comisso A e B.
Diagrama: Sintaxe:
SELECT nome_vendedor
FROM vendedores
WHERE faixa_de_comissao IN ('A', 'B');
SQL 333
Resultado:
Nome do Vendedor
Carlos
Felipe
Jonas
Josias
Maurcio
Operadores Baseados em Valores Desconhecidos: IS NULL e IS NOT NULL
WHERE <nome da coluna> IS NULL;

WHERE <nome da coluna> IS NOT NULL;
A utilizao do valor nulo (NULL) muito problemtica, pois cada implementao da

linguagem pode adotar qualquer representao para o valor nulo.
O resultado da aplicao desses operadores permite o tratamento de valores nulos em
colunas de uma tabela, selecionando as linhas correspondentes.
Problema: Mostrar os clientes que no tenham inscrio estadual.
Diagrama: Sintaxe:
SELECT *
FROM cliente
WHERE IE IS NULL;
Resultado:
Cdigo do Nome do
Cliente Cliente
110 Jorge R. Caiapo 13 Curitiba 30078500 PR 145127645/983493-9
180 Lvio Av. Beira Mar 1256 Florianpolis 30077500 SC 127365713/2347-4
Ordenao dos Dados Selecionados

Quando se realiza uma seleo, os dados recuperados no esto ordenados. Os dados
so recuperados pela ordem em que se encontram dispostos fisicamente na tabela do SGBD.

A SQL prev a clusula ORDER BY para realizar a ordenao dos dados selecionados.
Sintaxe Bsica
SELECT <nome da(s) coluna(s)>

FROM <tabela>
WHERE <condio(es)> >
ORDER BY <nome da(s) coluna(s)> [ASC/DESC]
ou
ORDER BY <nmero da coluna>
A informao <nmero da coluna> se refere posio relativa das colunas quando for
apresentado o resultado da consulta, e no posio na tabela original, contada da esquerda
para a direita. As palavras ASC e DESC significam, respectivamente, ascendente e descen-
dente. A forma ascendente de ordenao assumida como padro.
Problema: Mostrar em ordem alfabtica a lista de vendedores e seus respectivos salrios fixos.
Diagrama:
Sintaxe:
SELECT nome_vendedor, salario_fixo
FROM vendedores
ORDER BY nome_vendedor;
Resultado:
Nome do Vendedor Salrio Fixo

Antnio 9.500,00
Carlos 2.490,00
Felipe 4.600,00
Joo 2.780,00
Joo 2.650,00
Jonas 2.300,00
Jos 1.800,00
Josias 870,00
Maurcio 2.930,00
SQL 335
Problema: Listar os nomes, cidades e estados de todos os clientes, ordenados por estado e
cidade de forma descendente.
Diagrama: Sintaxe:
SELECT nome_cliente, cidade, UF
FROM cliente
ORDER BY UF DESC, cidade DESC;
Resultado:
Nome do Cliente Cidade UF

Flvio So Paulo SP
Maurcio So Paulo SP
Beth So Paulo SP
Renato So Paulo SP
Lvio Florianpolis SC
Rodolfo Rio de Janeiro RJ
Ana Niteri RJ
Susana Niteri RJ
Paulo Londrina PR
Jorge Curitiba PR
Sebastio Uberaba MG
Lcia Belo Horizonte MG
Jos Braslia DF
Edmar Salvador BA
Problema: Mostrar a descrio e o valor unitrio de todos os produtos que tenham a unidade
'KG', em ordem de valor unitrio ascendente.
Diagrama: Sintaxe:
SELECT descricao_produto, valor_unitario
FROM produto
WHERE unidade_produto = 'M'
ORDER BY 2 ASC;

Resultado:
Descrio Valor Unitrio

Linho 0,11
Madeira 0,25
Papel 1,05
Linha 1,80
Cano 1,97
Realizao de Clculos com Informao Selecionada

Com a linguagem SQL possvel criar um campo que no pertena tabela original e
seja fruto de clculo de alguns campos da tabela para ser exibido no momento da consulta.
Problema: Mostrar o novo salrio fixo dos vendedores, de faixa de comisso 'C', calculado
com base no reajuste de 75% acrescido de R$ 120,00 de bonificao. Ordenar pelo nome do
vendedor.
Diagrama:
Sintaxe:
SELECT nome_vendedor,
novo_salario = (salario_fixo * 1.75) + 120
FROM vendedores
WHERE faixa_de_comissao = 'C'
Resultado:
Nome do Vendedor Novo Salrio

Antnio 16.745,00
Joo 4.985,00
Joo 4.757,50
Jos 3270,00
SQL 337
Utilizao de Funes de Agregao sobre Conjuntos
As funes de agregao resultam sempre uma nova coluna no resultado da pesquisa.
Busca de Mximos e Mnimos (MAX, MIN)
Problema: Mostrar o menor e o maior salrios da tabela vendedores.
Diagrama: Sintaxe:
SELECT MIN(salario_fixo), MAX(salario_fixo)
FROM vendedores;
Resultado:
MIN (salario_fixo) MAX (salario_fixo)

870,00 9.500,00
Totalizao dos Valores de Colunas (SUM)
Problema: Mostrar a quantidade total pedida para o produto 'VINHO' de cdigo '78' na tabela
item_de_pedido.
Diagrama: Sintaxe:
SELECT SUM(quantidade),
FROM item_de_pedido
WHERE codigo_produto = '78';
Resultado:
SUM(Quantidade)
183

Clculo de Mdias (AVG)
Problema: Qual a mdia dos salrios fixos dos vendedores?
Diagrama: Sintaxe:
SELECT AVG(salario_fixo),
FROM vendedores;
Resultado:
AVG (salario_fixo)
3.324,44
Contagem dos Registros (COUNT)
Problema: Quantos vendedores ganham acima de R$ 2.500,00 de salrio fixo?
Diagrama: Sintaxe:
SELECT COUNT(*),
FROM vendedores
WHERE salario_fixo >2500;
O comando COUNT, quando utilizado sem a clusula WHERE, realiza a contagem das
linhas da tabela.
Resultado:
COUNT (*)
5
Utilizao da Clusula DISTINCT

Normalmente, vrios registros dentro de uma tabela podem conter os mesmos valores,
com exceo da chave primria. Com isso muitas consultas podem trazer informaes erradas.
SQL 339
A clusula DISTINCT, aplicada em uma consulta, foi criada para no permitir que certas redun-
dncias, obviamente necessrias, causem problemas. A clusula DISTINCT elimina repeties
de valores em relao a uma coluna.
Problema: Quais so as unidades de produtos, diferentes, na tabela produto?
Diagrama: Sintaxe:
SELECT DISTINCT unidade_produto,
FROM produto;
Resultado:
Unidade
Kg
BAR
L
M
SAC
G
Importante: Com a utilizao de DISTINC no se classificam os dados de sada4.
Agrupamento de Informaes Selecionadas

(GROUP BY e HAVING)
A funo de agregao por si prpria produz um nmero simples para uma tabela.
A clusula organiza esse sumrio de dados em grupos, produzindo informao sumari-
zada para os grupos definidos na tabela objeto de seleo.
A clusula HAVING realiza as restries das linhas resultantes da mesma forma que a
clusula WHERE o faz em um SELECT.
Podemos igualmente continuar com a clusula WHERE selecionando as condies da
seleo.
4 Especificao para SQL Server 2008.

FROM <tabela>
WHERE condio(es)>
GROUP BY <nome da(s) coluna(s)>;
HAVING <condio(es)>;
Problema: Listar o nmero de produtos que cada pedido contm.
Diagrama: Sintaxe:
SELECT numero_pedido,
total_produtos = COUNT(*)
FROM item_de_pedido
GROUP BY numero_pedido;
Inicialmente, os registros so ordenados de forma ascendente por nmero do pedido.

Num segundo passo aplicada a operao COUNT(*) para cada grupo de registros que
tenha o mesmo nmero de pedido.
Aps a operao de contagem de cada grupo, o resultado da consulta utilizando a clu-
sula GROUP BY apresentado.
Resultado:
Nmero do Pedido Total de Produtos

91 1
97 1
98 1
101 3
103 1
104 1
105 1
108 1
111 2
119 4
121 2
138 3
143 2
148 5
189 1
203 1
Geralmente, a clusula GROUP BY utilizada em conjunto com as operaes COUNT

e AVG.
SQL 341
Utilizao com HAVING
Problema: Listar os pedidos que tm mais de trs produtos.
Diagrama: Sintaxe:
SELECT numero_pedido,
total_produtos = COUNT(*)
FROM item_de_pedido
GROUP BY numero_pedido;
HAVING COUNT(*) >3;
Resultado:
Nmero do Pedido Total de Produtos

119 4
148 5
A clusula GROUP BY pode ser utilizada em conjunto com qualquer outra clusula que
j estudamos at este ponto.
Recuperao de Dados de Vrias Tabelas (JOINS)

At agora trabalhamos com a recuperao de dados em uma nica tabela, mas o
conceito de banco de dados rene, evidentemente, vrias tabelas diferentes.
Para que possamos recuperar informaes de um banco de dados, muitas vezes temos
a necessidade de acessar simultaneamente vrias tabelas relacionadas entre si. Algumas
dessas consultas necessitam realizar uma juno (JOIN) entre tabelas, para que dessa juno
possa extrair as informaes necessrias consulta formulada.
O Conceito de Qualificadores de Nome

O qualificador de nome consiste no nome da tabela seguido de um ponto e o nome da
coluna na tabela, por exemplo:
O qualificador de nome para a coluna descrio da tabela produto ser:
PRODUTO.descricao
Os qualificadores de nome so utilizados em uma consulta para efetivar a juno (join)
entre tabelas, uma vez que o relacionamento entre tabelas realizado atravs de chaves
estrangeiras, como vimos em lgebra relacional, e isso implica na existncia de colunas com o
mesmo nome em tabelas diferentes.

Existem duas sintaxes que vamos considerar no estudo:5 a sintaxe ANSI SQL e a do
Microsoft SQL Server 2008 para a implementao de joins.
Sintaxe ANSI SQL

SELECT <nome_da_tabela.nome_da_coluna
[nome_da_tabela.nome_da_coluna..]>
FROM {nome_da_tabela [tipo de join] nome_da_tabela ON condio de pesquisa
WHERE [condio de pesquisa..]
Sintaxe Microsoft SQL Server 2008

SELECT < nome_da_tabela.nome_da_coluna
[nome_da_tabela.nome_da_coluna..]>
FROM <nome_da_tabela, nome_da_tabela>
ON <nome_da_tabela.nome_da_coluna [operador de join]
nome_da_tabela.nome_da_coluna
Na sintaxe ANSI criamos uma tabela de join, "uma join_table", para as linhas selecio-
nadas conforme a clusula WHERE. Podemos escolher o tipo de join conforme o processado,
escolhendo a palavra que o identifica.
Quando usamos INNER JOIN como tipo de join, so includas somente as linhas que
satisfazem a condio do join.
Quando usamos CROSS JOIN, inclumos cada uma das combinaes de todas as
linhas entre as tabelas.
E, finalmente, quando usamos OUTER JOIN, inclumos as linhas que satisfazem a
condio de join e as linhas restantes de uma das tabelas do join.
Na sintaxe Microsoft SQL Server 2008 so comparadas as tabelas por uma coluna
especfica para cada tabela (chave estrangeira), linha por linha, e so listadas as linhas em que
a comparao verdadeira.
Nos joins do Microsoft SQL Server 2008 a clusula FROM lista as tabelas envolvidas
no join e a clusula WHERE especifica que linhas devem ser includas no conjunto resultante.
Na clusula WHERE o operador de join utilizado entre os componentes a serem juntados.
Os operadores a seguir so usados como join operators no Microsoft SQL Server
2008:
5 Vale a pena destacar que existe um padro de sintaxe ANSI e um padro de sintaxe Microsoft SQL Server para a execuo
de joins, mas no podemos usar os dois simultaneamente.
SQL 343
Smbolo Significado
= Igual a
> Maior que
< Menor que
>= Maior ou igual
<= Menor ou igual
<> Diferente
Problema: Ver os pedidos de cada cliente.
Diagrama:
Inner Joins
Sintaxe ANSI SQL: Sintaxe Microsoft SQL Server 2008:
SELECT Cliente.nome_cliente, SELECT Cliente.nome_cliente,
pedido.codigo_cliente, pedido.codigo_cliente,
pedido.numero_pedido pedido.numero_pedido
FROM cliente INNER JOIN pedido FROM cliente, pedido
ON cliente.codigo_cliente ON cliente.codigo_cliente
= pedido.codigo_cliente = pedido.codigo_cliente
Resultado:
Nome_do_cliente Pedido.Codigo_do_cliente Pedido.numero_pedido

Ana 720 97
Ana 720 101
Ana 720 137
Ana 720 148
Flvio 870 189
Jorge 110 104
Mauricio 830 203
Rodolfo 410 121
Rodolfo 410 98

Nome_do_cliente Pedido.Codigo_do_cliente Pedido.numero_pedido
Rodolfo 410 127
Beth 20 143
Lvio 180 105
Susana 260 111
Susana 260 103
Susana 260 91
Susana 260 138
Renato 290 108
Sebastio 390 119
Nesta juno so apresentados os pedidos de cada cliente, pois a condio de join

restringe e qualifica a juno dos dados entre as tabelas. A equao apresentada na clusula
WHERE chamada de equao de juno.
Cross Join ou Produto Cartesiano
Problema: Juntar clientes com pedidos.
Sintaxes ANSI SQL e Microsoft SQL Server 2008 so idnticas.

SELECT nome_cliente,
pedido.codigo_cliente,
numero_pedido
FROM cliente CROSS JOIN pedido
Resultado:
Nome_do_cliente Pedido.codigo_do_cliente Pedido.numero_pedido

Ana 720 97
Ana 260 111
Ana 870 54
Ana 390 119
Ana 260 103
Ana 830 203
Ana 410 121
Ana 110 104
Ana 180 105
Ana 720 83
Ana 290 108
Ana 410 89
Flvio 720 97
SQL 345
Nome_do_cliente Pedido.codigo_do_cliente Pedido.numero_pedido
Flvio 260 111
Flvio 870 54
Flvio 390 119
Flvio 260 103
Flvio 830 203
Flvio 410 121
Flvio 110 104
Flvio 720 83
Flvio 290 108
Flvio 410 89
Jorge 720 97
Jorge 260 111
Jorge 870 54
Jorge 390 119
Jorge 260 103
Jorge 830 203
Jorge 410 121
Jorge 110 104
Jorge 180 105
Jorge 720 83
Jorge 290 108
Jorge 410 89
Lcia 720 97
Lcia 260 111
Lcia 870 54
Lcia 390 119
Lcia 260 103
: : :
: : :
Podemos observar que no existe muito proveito do resultado desse tipo de join,
excetuando-se quando queremos fazer referncia cruzada entre duas tabelas e suas linhas
todas.
Outer Joins
a seleo em que so restritas as linhas que interessam em uma tabela, mas so
consideradas todas as linhas de outra tabela. Ou seja, queremos ver as linhas de uma tabela
que esto relacionadas com as da outra tabela e quais linhas no esto.

Exemplificando no mundo real, poderamos dizer que queremos ver quais clientes tm
pedidos e quais no tm nenhum pedido.
de muita utilidade quando queremos verificar se existem membros rfos em um
banco de dados, ou seja, chave primria e chave estrangeira sem sincronia ou simetria.
Um OUTER JOIN somente pode ser realizado entre duas tabelas, no mais que duas
tabelas.
A sintaxe ANSI SQL possui trs tipos de qualificador para o OUTER JOIN:
LEFT OUTER JOIN: so includas todas as linhas da tabela do primeiro nome de
tabela (a tabela mais esquerda da expresso).
RIGHT OUTER JOIN: so includas todas as linhas da tabela do segundo nome de
tabela da expresso (tabelas mais direita da expresso).
FULL OUTER JOIN: so includas as linhas que no satisfazem a expresso tanto
da primeira quanto da segunda tabelas.
O Microsoft SQL Server 2008 utiliza os mesmos operadores para OUTER JOIN:
*= Inclui todas as linhas da primeira tabela da expresso.

=* Inclui todas as linhas da segunda tabela da expresso.
Vamos ver um exemplo de OUTER JOIN para entender melhor a sua funcionalidade.
Problema: Quais so os clientes que tm pedido e os que no tm pedido?
Diagrama:
Sintaxe ANSI SQL e Microsoft SQL Server 2008:

SELECT nome_cliente,
pedido.codigo_cliente,
numero_pedido
FROM cliente LEFT OUTER JOIN pedido
ON cliente.codigo_cliente =
Pedido.codigo_cliente
SQL 347
Resultado:
Nome__do_cliente Pedido.Codigo_do_cliente Pedido.numero_pedido
Ana 720 97
Ana 720 101
Ana 720 137

Ana 720 148
Flvio 870 189

Jorge 110 104
Mauricio 830 203
Rodolfo 410 121
Rodolfo 410 98
Rodolfo 410 127
Beth 20 143
Lvio 180 105
Susana 260 111

Susana 260 103
Susana 260 91
Susana 260 138
Renato 290 108
Sebastio 390 119
Lcia NULL NULL
Edmar NULL NULL

Paulo NULL NULL
Jose NULL NULL
Como os clientes Lcia, Edmar, Paulo e Jos no tm nenhuma linha da tabela pedido,
a informao de seu cdigo apresentada como NULL.
Por este motivo no devemos utilizar NULL na condio de seleo, pois teremos de
utilizar os resultados mais imprevisveis e imaginveis possveis.
Podemos utilizar as clusulas LIKE, NOT LIKE, IN, NOT IN, NULL, NOT NULL e
mistur-las com os operadores AND, OR e NOT, dentro de uma clusula WHERE na juno de
tabelas.
Vamos estudar comandos de seleo de dados com esses operadores.

Problema: Quais clientes tm pedidos com prazo de entrega superior a 15 dias e que
pertencem aos estados de So Paulo ('SP') ou Rio de Janeiro ('RJ')?
Diagrama:
Sintaxe:
SELECT Cliente.nome_cliente,
pedido.codido_cliente,
pedido.numero_pedido
FROM cliente INNER JOIN pedido
ON cliente.codigo_cliente = pedido.codigo_cliente
WHERE UF IN ('SP', 'RJ') AND prazo_de_entrega > 15
Resultado:
Nome do Cliente UF Prazo de Entrega
Ana RJ 20
Maurcio SP 30
Rodolfo RJ 20
Beth SP 30
Susana RJ 20
Problema: Mostrar os clientes e seus respectivos prazos de entrega, ordenados do maior para
o menor.
Diagrama:
SQL 349
Sintaxe ANSI SQL e Microsoft SQL Server 2008:
SELECT nome_cliente, prazo_de_entrega
FROM cliente, pedido
ORDER BY prazo_de_entrega desc;
Resultado:
Nome do Cliente Prazo de Entrega

Jorge 30
Maurcio 30
Beth 30
Sebastio 30
Rodolfo 20
Ana 20
Susana 20
Ana 15
Flvio 15
Lvio 15
Renato 15
Rodolfo 10
Uso de Aliases
Para que no seja necessrio escrever todo o nome da tabela nas qualificaes de
nome, podemos utilizar ALIASES (sinnimos) definidos na prpria consulta. A definio dos
ALIASES feita na clusula FROM e utilizada normalmente nas outras clusulas (where, order
by, group by, having, select).
Problema: Apresentar os vendedores (ordenados) que emitiram pedidos com prazos de

entrega superiores a 15 dias e que tenham salrios fixos iguais ou superiores a R$ 1.000,00.
Sintaxe:
SELECT nome_vendedor, prazo_de_entrega
FROM vendedores V, pedido P
WHERE salario_fixo >= 1000.00 AND
prazo_de_entrega > 15 AND
V.codigo_vendedor = P.codigo_vendedor

Resultado:
Nome do Vendedor Prazo de Entrega

Antonio 20
Carlos 30
Joo 20
Jos 20
Maurcio 30
Juno de Mais de Duas Tabelas

Problema: Mostrar os clientes (ordenados) que tm prazo de entrega maior que 15 dias para o
produto 'QUEIJO' e que sejam do Rio de Janeiro.
Diagrama:
Novamente vamos apresentar a sintaxe ANSI e a sintaxe especfica do Microsoft SQL

Server 2008.
Sintaxe ANSI e Microsoft SQL Server 2008:
SELECT cliente.nome_cliente,
FROM cliente INNER JOIN pedido
INNER JOIN item_de_pedido
ON pedido.numero_pedido = item_de_pedido.numero_pedido
INNER JOIN produto
ON item_de_pedido.codigo_produto = produto.codigo_produto
WHERE pedido.prazo_de_entrega > 15 AND
produto.descricao_produto ='queijo' AND
cliente.UF = 'RJ'
ORDER BY cliente.nome_cliente
SQL 351
Resultado:
Nome Cliente
Ana
Rodolfo
Susana
Vamos a mais um exemplo.
Problema: Mostrar todos os vendedores que venderam chocolate em quantidade superior a

dez quilos.
Diagrama:
Sintaxe:
SELECT DISTINCT nome_vendedor
FROM vendedores, pedido, item_de_pedido, produto
WHERE Vendedores.codigo_vendedor = Pedido.codigo_vendedor AND
Pedido.numero_pedido = Item_de_pedido.numero_pedido AND
Item_de_pedido.codigo_produto = Produto.codigo_produto AND
quantidade > 10 AND descricao_produto = 'Chocolate';
Resultado:
Nome do Vendedor
Jos
Carlos

Problema: Quantos clientes fizeram pedido com o vendedor Joo?
Diagrama:
Sintaxe Microsoft SQL Server 2008:

SELECT COUNT (codigo_cliente)
FROM cliente, pedido, vendedores
WHERE Cliente.codigo_cliente = Pedido.codigo_cliente AND
Pedido.codigo_vendedor = Vendedores.codigo_vendedor AND
Vendedores.nome_vendedor = 'Joao';
Resultado:
COUNT (Cdigo Cliente)
4
Problema: Quantos clientes das cidades do Rio de Janeiro e Niteri tiveram seus pedidos
tirados com o vendedor Joo?

SELECT cidade, numero = COUNT (nome_cliente)
FROM cliente, pedido, vendedores
WHERE nome_vendedor = 'Joao' AND
CIDADE IN ('Rio de Janeiro', 'Niteroi') AND
Vendedores.codigo_vendedor = Pedido.codigo_vendedor AND
Pedido.codigo_cliente = Cliente.codigo_cliente
GROUP BY cidade;
Resultado:
Cidade Nmero
Niteri 2
Rio de Janeiro 1
SQL 353
Utilizao de Consultas Encadeadas (Subqueries)
O que subquery? Em linhas gerais, quando o resultado de uma consulta utilizado
por outra consulta de forma encadeada e contida no mesmo comando SQL.
Problema: Utilizando IN - Que produtos participam de qualquer pedido cuja quantidade seja 10?
Diagrama:
Sintaxe:
SELECT descricao_produto
FROM produto
WHERE codigo_produto IN
(SELECT codigo_produto
FROM item_de_pedido
WHERE quantidade = 10)
Resultado:
Descrio
Queijo
Vinho
Linho
Problema: Utilizando AVG - Quais vendedores ganham um salrio fixo abaixo da mdia?
Diagrama:
Sintaxe:
SELECT nome_vendedor
FROM vendedores
WHERE salario_fixo <
(SELECT AVG(salario_fixo)
FROM vendedores);

Resultado:
Nome do Vendedor
Jos
Carlos
Joo
Jonas
Josias
Maurcio
Problema: Utilizando NOT IN - Quais os produtos que no esto presentes em nenhum pedido?
Diagrama:
Sintaxe:
FROM produto
WHERE codigo_produto NOT IN
(SELECT * FROM item_de_pedido
WHERE item_de_pedido.codigo_produto = produto.codigo_produto)
Resultado:
Cdigo do Produto Descrio do Produto

87 Carro
Na consulta anterior, a subquery no executada diretamente de uma vez s. Ela

executada para cada valor do registro do produto, ou seja, para cada execuo da subquery
utilizado um valor do cdigo do produto dentro do produto, o qual comparado, via condio
de subquery, com vrios valores em itens do pedido.
SQL 355
Problema: Quais os vendedores que s venderam produtos por grama ('G')?
Diagrama:
Sintaxe:
SELECT DISTINCT codigo_vendedor, nome_vendedor
FROM vendedores
WHERE unidade ALL =('G')
(SELECT unidade_produto
FROM pedido, item_de_pedido, produto
WHERE Pedido.numero_pedido = item_de_pedido.numero_pedido
AND Item_de_pedido.codigo_produto = Produto.codigo_produto
AND Pedido.codigo_vendedor = Vendedores.codigo_vendedor);
Resultado:
Cdigo do Vendedor Nome do Vendedor

720 Felipe
310 Josias
Interpretando o comando aplicado:

Selecione todas as ocorrncias da tabela vendedores que esto associadas
tabela pedidos e na tabela item de pedido relacionada com a tabela pedidos,
relacionada com a tabela produtos, todos os itens de pedido sejam de produtos
com unidade 'G', ou seja, Grama (no existe correspondente no Microsoft SQL
Server 2008).

Condio que satisfaz a query:
Todos os itens de pedido de um pedido tm unidade = G.
Mostrar o nome dos vendedores associados a esses pedidos.
Esse comando complicado de entender, por isso tentamos uma forma de explic-lo
em linguagem mais natural, mas mesmo assim talvez no tenhamos conseguido esclarecer
completamente.
Problema: Subquery testando a existncia - Quais clientes esto presentes em mais de trs
pedidos?
Diagrama:
Sintaxe:
SELECT nome_cliente
FROM cliente
WHERE EXIST
(SELECT COUNT(*)
FROM pedido
WHERE codigo_cliente = cliente.codigo_cliente
HAVING COUNT(*) >3);
Resultado:
Nome Cliente
Ana
Susana
Entendendo o comando:
Sempre analisamos a query entre parnteses primeiro.
Nesse select estamos contando (count) os pedidos de cada cliente e selecionando
os clientes que tm mais de trs pedidos.
A query principal, por assim dizer, somente lista o nome dos clientes que EXISTEM
nesse conjunto obtido (EXIST).
SQL 357
Destaca-se aqui a diferena entre o comando select com EXIST e com NOT IN (IN):
Quando utilizamos EXIST, no colocamos nenhum nome de coluna antes da
clusula, e quando utilizamos IN ou NOT IN, somos obrigados a colocar o nome da
coluna antes.
WHERE coluna IN (NOT IN): retorna uma lista de zero ou mais valores.
WHERE EXIST (NOT EXIST): retorna um valor falso ou verdadeiro.
Problema: Criar uma tabela com o resultado de um SELECT.
Quando usamos um comando select com a clusula INTO, definimos uma tabela e
colocamos os dados resultantes da query dentro dela.
Se a tabela j existir com o mesmo nome dado no comando, ele falha.
Sintaxe Bsica Microsoft SQL Server 2008
SELECT <lista de colunas>

INTO <nova tabela>
FROM < lista de tabelas>
WHERE <condies de seleo>
No Microsoft SQL Server 2008 a clusula INTO cria uma tabela permanente apenas
se a opo select into/bulkcopy estiver setada; caso contrrio, cria uma tabela temporria.
Se as colunas selecionadas na lista de colunas no possurem nomes (SELECT *), as
colunas criadas na nova tabela tambm no vo possuir nomes e somente podero ser sele-
cionadas por meio de um SELECT * FROM <nome da tabela>.
Inserir, Modificar e Apagar Registros
Adio de Registro Tabela
Sintaxe Bsica
INSERT INTO <nome da tabela>

(<nome da(s) coluna(s)>)
VALUES (<valores>);

Problema: Adicionar o produto 'parafuso' tabela produto.
Diagrama: Sintaxe:
INSERT into produto
VALUES (108,'Parafuso','Kg',1.25);
A clusula VALUE especifica os dados que voc deseja inserir na tabela. Ela uma
palavra requerida para introduzir no comando uma lista de valores para cada coluna.
Se no forem especificados os nomes de colunas, essa lista de valores deve estar na
ordem das colunas definidas no comando CREATE TABLE.
Adio de Registros com um SELECT
Sintaxe Bsica
INSERT INTO <nome da tabela>

(<nome da(s) coluna(s)>)
FROM <nome da tabela>
WHERE <condio>;
Problema: Cadastrar como clientes os vendedores que emitiram mais de 50 pedidos. Usar
para cdigo de cliente o mesmo cdigo de vendedor.
Diagrama:
SQL 359
Sintaxe ANSI 92:
INSERT INTO cliente (codigo_cliente, nome_cliente)
SELECT codigo_vendedor, nome_vendedor, COUNT(*)
FROM vendedores, pedido
WHERE Vendedores.codigo_vendedor = Pedido.codigo_vendedor
HAVING COUNT(*) > 50;

INSERT cliente (codigo_cliente, nome_cliente)
SELECT codigo_vendedor, nome_vendedor, COUNT(*)
FROM vendedores, pedido
WHERE Vendedores.codigo_vendedor = Pedido.codigo_vendedor
HAVING COUNT(*) > 50;
A diferena de sintaxe se resume somente existncia da clusula INTO no ANSI 92, e

cumpre destacar que o Microsoft SQL Server 2008 no exige a clusula INTO, porm no
causa nenhum erro se voc a utilizar.
Atualizao de um Registro - UPDATE

A atualizao de dados em linhas existentes na tabela permite que:
Especifique-se uma determinada coluna e altere-se seu valor.
Seja indicada uma linha especfica ou uma condio de identificao de linhas para
que sejam alterados os valores de determinadas colunas.
Sintaxe Bsica
UPDATE <nome da tabela>

SET <nome da(s) coluna(s)> = valor
WHERE <condio>;
Problema: Alterar o valor unitrio do produto 'parafuso' de R$ 1.25 para R$ 1.62.
Diagrama: Sintaxe:
UPDATE produto
SET valor_unitario = 1.62
WHERE descricao_produto = 'Parafuso';
Resultado:
Cdigo do Produto Descrio Unidade Valor Unitrio
108 parafuso Kg 1.62

Problema: Atualizar o salrio fixo de todos os vendedores em 27% mais uma bonificao de
R$ 100,00.
Diagrama:
Sintaxe:
UPDATE vendedores
SET salario_fixo = (salario_fixo * 1.27) + 100.00;
O resultado desse comando provoca que todos os vendedores tenham o mesmo valor
de salrio fixo.
A sintaxe idntica para Microsoft SQL Server 2008.
Problema: Acrescentar 2,5% ao preo unitrio dos produtos que estejam abaixo da mdia dos
preos para os comprados a quilo.
Diagrama:
Sintaxe:
UPDATE produto
SET valor_unitario = valor_unitario * 1.025
WHERE valor_unitario <
(SELECT AVG(valor_unitario)
FROM produto
WHERE unidade_produto = 'Kg');
SQL 361
Alterao de Registros com Dados de Outra Tabela
Para explicar esse comando, vamos supor que nossa tabela de produtos possua um
campo de vendas acumuladas ao ano.
Problema: Atualizar as vendas acumuladas ao ano para cada produto.
Diagrama:
Sintaxe:
UPDATE produto
SET vendas_acumuladas = 0
UPDATE produto
SET vendas_acumuladas = (SELECT SUM (quantidade)
FROM item_de_pedido)
Resultado:
Cdigo do Produto Unidade do Produto Descrio do Produto Valor Unitrio Vendas Acumuladas
25 Kg Queijo 0,97 30
31 BAR Chocolate 0,87 57
78 L Vinho 2,00 193
22 M Linho 0,11 20
30 SAC Acar 0,30 0
53 M Linha 1,80 82
13 G Ouro 6,18 36
45 M Madeira 0,25 8
87 M Cano 1,97 0
77 M Papel 1,05 143

Apagar Registros da Tabela
Sintaxe Bsica
DELETE FROM <nome da tabela>

WHERE <condio>;
Problema: Apagar todos os vendedores com faixa de comisso nula.
Diagrama:
Sintaxe:
DELETE FROM vendedores
WHERE faixa_de_comissao IS NULL;
Problema: Apagar todos os registros de pedidos realizados por vendedores fantasmas (opera-
o caa-fantasma).
Diagrama:
Sintaxe:
DELETE FROM pedido
WHERE NOT EXIST
(SELECT vendedor
FROM vendedores
WHERE codigo_vendedor = Pedido.codigo_vendedor);
SQL 363
Apagar Registros da Tabela com Base em Dados de Outra Tabela
Problema: Apagar todos os registros de item de pedidos realizados para produtos que tenham
"lh" no nome.
Sintaxe ANSI 92:

DELETE FROM item_de_pedido
WHERE pedido.codigo_produto IN
(SELECT * FROM produto, item_de_pedido
WHERE produto.codigo_produto = item_de_pedido.codigo_produto
AND produto.descricao_produto LIKE %lh%)

DELETE FROM item_de_pedido
FROM produto P, item_de_pedido I
WHERE P.codigo_produto = I.codigo_produto
AND produto.descricao_produto LIKE %lh%)
Utilizao de Views
View um caminho alternativo para visualizarmos dados derivados de uma ou mais
tabelas em um banco de dados. Um usurio pode necessitar ver partes selecionadas de dados
com nome, departamento e supervisor, porm no visualizar salrio. As views tambm podem
ser utilizadas para informao calculada ou derivada, como preo total de um item de pedido
que calculado pela multiplicao de quantidade e preo unitrio.
As tabelas criadas em um banco de dados relacional tm existncia fsica dentro do
sistema de computao. Muitas vezes necessrio criar tabelas que no ocupem espao
fsico, mas que possam ser utilizadas como as tabelas normais. Estas so chamadas de views
(tabelas virtuais).
Como as tabelas reais, as views devem ser criadas:
Sintaxe Bsica
CREATE VIEW <nome da VIEW>

(<nome da(s) coluna(s)>) AS
FROM <nome da tabela>
WHERE <condio>
[WITH CHECK OPTION];
As views so utilizadas para se ter uma particular viso de uma tabela, para que no
seja necessria a utilizao do conjunto como um todo.

Restries de Views
No utilize SELECT INTO, ORDER BY, COMPUTE, COMPUTE BY ou UNION.
Problema: Criar uma view que contenha s os produtos cuja medida seja metro.
Diagrama:
Sintaxe:
CREATE VIEW PR_metro (codigo_PR_metro, descricao, unidade) AS
SELECT codigo_produto, descricao_produto, unidade_produto
FROM produto
WHERE unidade_produto = 'M';
Problema: Criar uma view contendo o cdigo do vendedor, o seu nome e o salrio fixo mdio
no ano.
Diagrama:
Sintaxe:
CREATE VIEW salario_medio (codigo_vendedor, nome_vendedor, salario_medio) AS
SELECT codigo_vendedor, nome_vendedor, salario_fixo/12
FROM vendedores;
SQL 365
Criao de uma View por meio de um Join
Problema: Criar uma view contendo os vendedores, seus pedidos efetuados e os respectivos
produtos.
Diagrama:
Sintaxe:
CREATE VIEW lista_pedidos AS
SELECT nome_vendedor, numero_pedido, descricao
FROM vendedor V, pedido P, item_pedido I, produto PR
WHERE V.codigo_vendedor = P.codigo_vendedor and
P.numero_pedido = I.numero_pedido and
I.codigo_produto = PR.codigo_produto;
As views criadas passam a existir no banco de dados como se fossem tabelas reais. As
views so volteis, desaparecendo no final da sesso de trabalho. Depois de criadas, elas
podem ser utilizadas em todas as funes da linguagem SQL (listar, inserir, modificar, apagar
etc.).

Utilizao de uma View
Listagem
Problema: Com base na view salario_medio mostrar os vendedores que possuem mdia
salarial superior a R$ 2.000,00.
Diagrama:
Sintaxe:
SELECT nome_vendedor, salario_medio
FROM salario_medio
WHERE salario_medio > 2000.00;
Insero de Linhas numa View
Problema: Inserir o registro: 110, Linha_10, M; na view PR_Metro.
Diagrama:
Sintaxe:
INSERT INTO pr_metro
VALUES (110, 'Linha_10', 'M');
importante observar que a insero de linhas em uma view causa a insero da linha
na tabela qual a view est associada, ou seja, tabela origem da view.
SQL 367
Modificao de uma Linha da View
Problema: Alterar a descrio de 'Linha_10' para 'Linha_20' no cdigo 110 da view PR_Metro.
Diagrama:
Sintaxe:
UPDATE pr_metro
SET descricao = 'Linha_20'
WHERE codigo_pr_metro = 110;
Da mesma forma vamos alterar a tabela original da view.
Apagar
Problema: Apagar da view salario_medio o registro de cdigo do vendedor igual a 240.
Diagrama:
Sintaxe:
DELETE FROM salario_medio
WHERE codigo_vendedor = 240;
Eliminao de uma View
Sintaxe Bsica
DROP VIEW <nome da VIEW>;

Problema: Eliminar a view salario_medio.
Sintaxe:
DROP VIEW salario_medio;
Garantia dos Privilgios de Acesso - GRANT e REVOKE

Muitos sistemas de banco de dados relacionais podem ser acessados por diversos
usurios. Cada usurio tem determinada necessidade em relao aos dados armazenados. De
acordo com o projeto do banco de dados, alguns usurios s podem consultar alguns dados,
outros podem atualizar, outros podem inserir etc. Para que o dado fique protegido do uso
indevido de qualquer usurio, a linguagem SQL permite a definio dos privilgios que cada
um pode ter em relao s tabelas criadas no banco de dados.
Os privilgios garantem a segurana e a integridade dos dados, bem como a responsa-
bilidade de cada usurio sobre seus dados especficos.
Comando GRANT (Garantir)

Quando uma tabela/view criada, o nome do usurio que a criou anexado interna-
mente ao nome da tabela.
Por exemplo, se a tabela produto foi criada pelo usurio Felipe, ento internamente ela
ser conhecida como Felipe.produto.
O criador da tabela/view tem total privilgio sobre a tabela criada, podendo disponibilizar
qualquer privilgio para outros usurios pelo comando GRANT:
Sintaxe Bsica
GRANT {ALL |Lista de privilgios}

ON {nome da tabela/view [lista de colunas]}
TO {PUBLIB |lista de usurios}
[WITH GRANT OPTION]
A palavra ALL usada quando qualquer privilgio aplicvel ao objeto, ou ento espe-
cificamos o privilgio que est sendo dado (SELECT, UPDATE etc.).
A clusula ON especifica a tabela ou view e suas colunas para as quais est sendo
dado o privilgio.
Importante: Somente pode ser utilizada uma tabela ou view por comando.
SQL 369
As diferentes verses de SQL dos SGBDs relacionais incluem diferentes conjuntos de
privilgios. SELECT, UPDATE, DELETE e INSERT esto sempre presentes em todos esses
conjuntos, indiferentemente do SGBD.
Os privilgios podem ser especificados para algumas colunas, porm devem ser todas
elas da mesma tabela. Se no for especificada nenhuma coluna, os privilgios valem para
todas.
A clusula opcional WITH GRANT OPTION permite que quando se d o privilgio a um
usurio, ele o passe a outros usurios.
Lista de Opes de Privilgios

Select: pode executar uma consulta tabela.
Insert: permite executar uma insero na tabela.
Delete: pode apagar registros da tabela.
Update: modifica registros na tabela.
All privileges/all: pode executar qualquer operao com a tabela.
<usurio>: nome do usurio que vai receber os privilgios. Deve ser cadastrado
dentro do ambiente.
PUBLIC: concede os privilgios especificados a todos os usurios do ambiente.
Exemplos:
GRANT SELECT ON Produto TO Felipe;
Permite s consultas ao usurio Felipe na tabela produto.

GRANT SELECT, INSERT, UPDATE ON pedido to tele_mark;
Concede ao usurio tele_mark (entrada de pedidos) os privilgios de seleo,

insero e alterao sobre a tabela PEDIDO.
GRANT ALL PRIVILEGES ON cliente to public;
Permite todos os privilgios a todos os usurios sobre a tabela cliente.

GRANT SELECT ON cliente to Felipe, Mauricio;
Concede aos usurios Mauricio e Felipe o privilgio de seleo na tabela CLIENTE.

Problema: Disponibilizar para seleo a view salario_medio a todos os usurios.
Sintaxe:
GRANT SELECT ON salario_medio TO public;
Utilizando o comando GRANT, possvel disponibilizar acessos s a alguns campos da

tabela/view. Vamos a um exemplo:
Problema: Disponibilizar para seleo, s os campos cdigo de vendedor e nome do vendedor

da tabela vendedor a todos os usurios.
Sintaxe:
GRANT SELECT (codigo_vendedor, nome_vendedor)
ON vendedores
TO public;
Podemos passar nossa concesso de privilgios a outros usurios por meio da clusula
WITH GRANT OPTION, como explicamos anteriormente
Problema: Dar ao usurio FELIPE o poder de concesso de todos os privilgios a outros

usurios sobre a tabela PEDIDO.
Sintaxe:
GRANT ALL
ON pedido
TO Felipe
WITH GRANT OPTION
Comando REVOKE (Revogao)

Da mesma forma que o criador da tabela pode garantir (GRANT) privilgios de acesso
aos outros usurios, ele pode revogar esses privilgios por meio do comando REVOKE:
Sintaxe Bsica
REVOKE [ lista de privilgios ]

ON [nome da tabela/view]
FROM [lista de usurios];
SQL 371
Problema: Retirar o privilgio de seleo sobre a tabela produto do usurio Maurcio.
Sintaxe:
REVOKE select
ON produto
FROM Mauricio;
Problema: Revogar todos os privilgios concedidos a todos os usurios sobre a tabela cliente.
Sintaxe:
REVOKE select
ON cliente
FROM public;
Problema: Retirar os privilgios de atualizao e insero concedidos ao usurio tele_mark

sobre a tabela pedido.
Sintaxe:
REVOKE insert, update
ON pedido
FROM tele_mark
Trabalho com ndices

ndice uma estrutura que permite rpido acesso s linhas de uma tabela com base
nos valores de uma ou mais colunas. O ndice simplesmente uma outra tabela no banco de
dados, na qual esto armazenados valores e ponteiros, arrumados de forma ascendente ou
descendente. O SGBD utiliza os ndices para pesquisar rapidamente um determinado valor
dentro do banco de dados. Com os ponteiros se localiza a linha em que o valor desejado est
armazenado.
As tabelas de ndices so utilizadas internamente pelo SGBD, ficando totalmente
transparente ao usurio sua utilizao.
Um Checklist para Criao de ndices

Quando vamos criar ndices em colunas, devemos considerar:
O ndice deve ser de coisas que vamos pesquisar com frequncia.
Indexe as suas chaves estrangeiras quando precisar de joins mais eficientes e
performticos.

As colunas que so regularmente utilizadas em joins devem ser indexadas, porque
o sistema pode executar esses joins de modo muito mais rpido, e como tempo de
resposta algo vital no desenvolvimento de projetos fsicos de bancos de dados,
recomendvel a sua utilizao.
Crie ndices sempre em colunas que so pesquisas por um intervalo de valores.
Por fim, crie ndices sempre em colunas que so utilizadas em clusulas WHERE.
Quando No Criar ndices

Se a expectativa de retorno de linhas de uma consulta for muita alta, ndices no devem
ser utilizados. Por exemplo, se uma coluna tem somente dois valores: masculino e feminino,
uma consulta nessa coluna sempre vai retornar uma alta quantidade de linhas. Como um
ndice no grupado, pode ocupar muito espao e no ser utilizado para consultas.
O ndice cluster ou agrupado tem os valores constantes na coluna e pode ser agrupado
em pequenos conjuntos, facilitando a pesquisa na rea de ndices da tabela. Quando o nmero
de valores diferentes que pode aparecer na coluna pequeno, o ndice no grupado. O
objetivo aqui somente conceituar. No vamos nos aprofundar demais, pois estes aspectos
fazem parte de um estudo todo especfico para administradores de bancos de dados.
ndices agrupados ou clustered so colocados na mesma ordem fsica das linhas da
tabela, e ndices no agrupados ou nonclustered so dispostos na ordem lgica das linhas
da tabela.
Vamos ver como se criam ndices.
Criao de ndices
Cada ndice aplicado a uma tabela, especificando uma ou mais colunas dessa tabela.
ndices so criados pelo comando CREATE INDEX que cria um ndice com as colunas
de uma tabela.
Sintaxe Bsica
CREATE [UNIQUE] INDEX <nome do ndice>
ON <nome da tabela> (<coluna(s)>);
A clusula UNIQUE opcional e define que para aquela coluna no existiro valores
duplicados, ou seja, todos os dados armazenados na coluna sero nicos.
A juno do ndice unique e da especificao NOT NULL para uma coluna define a
chave primria da tabela, quanto ao aspecto lgico, pois uma chave primria, como vimos
neste livro, no pode ser NULA.
SQL 373
A criao dos ndices depende muito do projeto do banco de dados e das necessidades
de pesquisa formuladas pelos usurios do banco de dados. Os ndices esto muito ligados s
necessidades de velocidade na recuperao da informao, e na execuo rpida de uma
operao de JOIN.
Para cada SGBD existem clusulas especficas operacionais que devem ser usadas,
mas neste caso vamos apresentar a sintaxe padro geral do ANSI SQL.
Exemplos:
CREATE INDEX nome_pro
ON produto (descricao_produto);
Cria a tabela de ndices chamada nome_pro baseada no campo descrio da

tabela produto.
CREATE INDEX ped_pro
ON item_produto (numero_pedido, codigo_produto);
Cria a tabela de ndices ped_pro baseada na concatenao dos campos

numero_pedido e codigo_produto da tabela item_de_pedido.
importante considerar que praticamente todas as sintaxes em se tratando de
SGBDs relacionais exigem que se identifique o database proprietrio da tabela,
principalmente em Microsoft SQL Server 2008.
CREATE UNIQUE INDEX clientex
ON [nome do database] cliente (codigo_cliente);
Cria o ndice nico para a tabela cliente baseada no cdigo do cliente, no podendo
haver duplicidade de informao armazenada.
Eliminao de ndices
Da mesma forma que um ndice criado ele pode ser eliminado, dependendo das
necessidades do projeto do banco de dados.
Sintaxe Bsica
DROP index <nome do ndice>;
Exemplos:
DROP index nome_pro;
DROP index ped_pro;

Tpicos Avanados de SQL
Combinao de Resultados de Pesquisas (UNION)

Eventualmente, necessrio combinar os resultados de duas ou mais consultas feitas
sobre tabelas. Para realizar essa operao, a linguagem SQL oferece o operador UNION e
uma listagem com os resultados das consultas combinadas.
Problema: Listar nomes e cdigos dos vendedores que tm salrio fixo maior que R$ 1.000,00
e clientes que residem no Rio de Janeiro.
Diagrama:
Sintaxe:
SELECT codigo = codigo_cliente, nome = nome_cliente
FROM cliente
WHERE UF = 'RJ'
UNION
SELECT codigo_vendedor, nome_vendedor
FROM vendedores
WHERE salario_fixo > 1000.00
Observe que as duas listas de colunas dos SELECT contm o mesmo nmero de itens
(duas colunas) e os tipos de dados so compatveis.
Resultado:
Cdigo Nome
209 Jos
111 Carlos
11 Joo
240 Antnio
720 Felipe
213 Jonas
101 Joo
250 Maurcio
410 Rodolfo
SQL 375
Realizao de um Join entre uma Tabela e Ela Mesma
Muitas vezes, quando temos autorrelacionamentos, necessitamos apresentar os seus
dados. Para isso utilizamos um join entre a tabela e ela mesma, o self join.
O autorrelacionamento acontece quando temos em uma tabela uma chave estrangeira
que est relacionada com a chave primria dessa mesma tabela.
Vamos ampliar o exemplo at o momento e colocar na tabela de vendedores o chefe de
cada um, que tambm um vendedor.
Vamos preencher a tabela com os chefes de cada vendedor:

Nova tabela vendedores:
Cdigo do Nome do Faixa de

Salrio Fixo Chefe
Vendedor Vendedor Comisso
209 Jos 1.800,00 C 250
111 Carlos 2.490,00 A 720
11 Joo 2.780,00 C 250
240 Antnio 9.500,00 C 250
720 Felipe 4.600,00 A null
213 Jonas 2.300,00 A 720
101 Joo 2.650,00 C 250
310 Josias 870 B 720
250 Maurcio 2.930,00 B null
Observe que as linhas correspondentes aos dois vendedores que so chefes de outros
possuem a chave estrangeira com valor nulo, pois no possuem nenhum chefe acima deles.
Para realizar um self join, voc precisa utilizar o conceito de alias das tabelas.
Ento, para listarmos o nome dos funcionrios e de seus chefes:

Select A.Nome_Vendedor as Chefe,
B. Nome_Vendedor as Funcionario
From Funcionario A, Funcionario B
Where A.Codigo_vendedor = B.Chefe
Order by 1
Resultado:
Chefe Funcionario
Felipe Carlos
Felipe Jonas
Felipe Josias
Maurcio Jos
Maurcio Joo
Maurcio Antnio
Maurcio Joo
NVL
Converte valores nulos em um valor real. A funo est apta a trabalhar com os tipos de
dados DATE, CHARACTER e NUMBER. Os parmetros informados devem ser do mesmo tipo
de dado.
A utilizao de NVL importante para o controle de valores nulos quando da utilizao
de uma expresso de clculo, evitando-se divises por zero, por exemplo.
Frequentemente nos deparamos com algum select de banco de dados em que alguns
campos retornam null.
O mais comum que o tratamento desta situao seja feito do lado da aplicao, ge-
rando um aumento de cdigo.
Entretanto, para facilitar a vida do programador, no Oracle, a funo que faz esse ser-
vio a NVL. Ela recebe dois parmetros; o primeiro o nome do campo, ou expresso, que
queremos tratar e o segundo parmetro o valor que ser retornado quando for encontrado o
null no campo escolhido.
Supondo uma tabela TESTE de exemplo:
codigo descricao valor

1 codigo 1 1
2 codigo 2 2
3 null null
Podemos fazer o tratamento da Descrio e do Valor.

Select Codigo, NVL (Descricao, Inexiste), NVL (Valor, 0.0) from teste;
SQL 377
O retorno seria ento:
codigo descricao valor
1 codigo 1 1
2 codigo 2 2
3 Inexiste 0
A utilizao da expresso condicional DECODE

A expresso DECODE trabalha de um modo similar lgica IF-THENELSE. Ela com-
para uma expresso ou o contedo de uma coluna a todas as condies, uma por vez. Se a
expresso igual condio, ento o Oracle retorna o resultado correspondente. Se no
encontrar nenhuma correspondncia, o Oracle retorna o valor default. Neste caso, se default
estiver omitido, Oracle retorna Nulo.
DECODE (expr
,search1,result1
,search2,result2,...,
,searchN,resulN]
,default)
Exemplos:
Select funcao,
salario,
DECODE(funcao, 'IT_PROG',salario*1.1,
'ST_MAN',salario*1.2,
'MK_REP',salario*1.3,
salario) reajuste
from empregados
select
DECODE (PD.CLIENTE,'S',VAREJO,'ATACADO') cliente
from Pedidos PD
Where trunc(PD.DIA_DE_DISTRIBUICAO) >= 07/set/2011'
A utilizao da expresso condicional CASE

Em uma expresso CASE, o Oracle pesquisa a partir da primeira clusula WHEN, em
que expr igual a compare e retorna result. Se nenhuma das clusulas WHEN for selecio-
nada e uma clusula ELSE existir, ento o Oracle retorna resultElse.
CASE expresso WHEN valor de comparao1 THEN resultado1
WHEN valor de comparaoN THEN resultado2
WHEN valor de comparaoN THEN resultadoN
ELSE resultado de Else
END
select
funcao,
salario,

CASE funcao
WHEN 'IT_PROG' THEN salario * 1.1
WHEN 'ST_MAN' THEN salario * 1.2
WHEN 'MK_REP' THEN salario * 1.3
ELSE salario
END
from empregados
Trabalho com tempo (campos date)

Como todo desenvolvedor Oracle sabe, os campos do tipo DATE costumam ser usados
em tabelas para a representao de informao referente data e hora de algum evento.
Campos do tipo DATE ocupam apenas 7 bytes e so capazes de armazenar datas com a
preciso na casa dos segundos. Melhor detalhando, um campo DATE capaz de manter as
seguintes informaes temporais associadas a um determinado evento: sculo, ano, ms, dia,
hora, minuto e segundo de ocorrncia do evento.
Em muitas situaes prticas podemos estar interessados em adicionar ou subtrair no
dias, mas horas, minutos ou segundos do valor de uma data. Isso tambm possvel no
Oracle, no entanto o SGBD solicita que seja especificada uma frao de dia adequada para a
operao aritmtica. Sabemos que um dia possui:
24 horas
24 x 60 = 1440 minutos
24 x 60 x 60 = 86.400 segundos
Com isso, se desejamos somar 5 minutos a uma determinada data no Oracle, deve-
mos somar a frao 5/1440 a esta data! Observe este clculo no exemplo a seguir:
SELECT
TO_CHAR(SYSDATE,DD/MM/YYYY HH24:MI:SS) AS AGORA,
TO_CHAR(SYSDATE + 5/1440, DD/MM/YYYY HH24:MI:SS) AGORA_MAIS_5_MIN
FROM DUAL;
Agora Agora mais 5 min

25/06/2007 18:18:29 25/06/2007 18:23
Estudo de Caso - Banco de Dados

Para que voc possa comparar as sintaxes dos comandos SQL, nesta reviso vamos
apresentar os scripts gerados para o estudo de caso das cirurgias apresentado no livro, agora
com o modelo ampliado em detalhes.
Utilizamos o software ERwin 4.0 para os servidores Microsoft SQL Server 2008,
assim como realizamos uma gerao de script de banco de dados para Oracle 11g, que
permite avaliar as estruturas de banco de dados aps cri-lo em um desses dois SGBDs.
SQL 379
Desta forma voc ter sua disposio duas formas de criao para os bancos de
dados fsicos dos estudos de caso. Bom proveito, amigo!
Microsoft SQL Server2008

CREATE TABLE Cidade (
ID_Cidade char(18) NOT NULL,
UF char(18) NOT NULL,
Descricao char(18) NULL
)
ALTER TABLE Cidade
ADD PRIMARY KEY (ID_Cidade ASC, UF ASC)
CREATE TABLE Cirurgia (
CRM char(18) NOT NULL,
Numero_Internacao char(18) NOT NULL,
Numero_Sala char(18) NOT NULL,
Data_Cirurgia char(18) NOT NULL,
Hora_Cirurgia char(18) NOT NULL,
Identificacao_Especialidade char(18) NOT NULL,
Qtde_sangue_solicitada char(18) NULL,
Qtde_sangue_utilizada char(18) NULL
)
ALTER TABLE Cirurgia

ADD PRIMARY KEY (CRM ASC, Numero_Internacao ASC, Numero_Sala ASC,
Data_Cirurgia ASC, Hora_Cirurgia ASC)
CREATE TABLE Consumo (
Numero_Consumo char(18) NOT NULL,
Codigo_Produto char(18) NOT NULL,
Hora_Cirurgia char(18) NOT NULL,
Data_Cirurgia char(18) NOT NULL,
Quantidade char(18) NULL
)
ALTER TABLE Consumo
ADD PRIMARY KEY (Numero_Consumo ASC, Codigo_Produto ASC)
CREATE TABLE Especialidade (
Descricao_Especialidade char(18) NULL
)
ALTER TABLE Especialidade
ADD PRIMARY KEY (Identificacao_Especialidade ASC)
CREATE TABLE Estado (
Nome__Estado char(18) NULL
)
ALTER TABLE Estado
ADD PRIMARY KEY (UF ASC)
CREATE TABLE Material_e_Medicamento (
Codigo_Produto char(18) NOT NULL,
Principio_Ativo char(18) NULL,
Descricao char(18) NULL,
Unidade char(18) NULL,
Saldo_Estoque char(18) NULL
)
ALTER TABLE Material_e_Medicamento
ADD PRIMARY KEY (Codigo_Produto ASC)
CREATE TABLE Medico (

ID_Cidade char(18) NOT NULL,
Id_Especialidade char(18) NOT NULL,
Nome char(18) NULL,
Endereco char(18) NULL,
Bairro char(18) NULL,
Salario char(18) NULL
)
ALTER TABLE Medico
ADD PRIMARY KEY (CRM ASC)
CREATE TABLE Paciente (
CPF char(18) NULL,
Nome char(18) NULL,
Endereco char(18) NULL,
Sexo char(18) NULL,
Nascimento char(18) NULL,
Profissao char(18) NULL
)
ALTER TABLE Paciente
ADD PRIMARY KEY (Numero_Internacao ASC)
CREATE TABLE Qualificacao_da_Sala (
Data_Inicio_qualificacao char(18) NULL
)
ALTER TABLE Qualificacao_da_Sala
ADD PRIMARY KEY (Numero_Sala ASC, Identificacao_Especialidade ASC)
CREATE TABLE Sala (
Andar char(18) NULL,
Ala_do_Centro char(18) NULL
)
ALTER TABLE Sala
ADD PRIMARY KEY (Numero_Sala ASC)
ALTER TABLE Cidade
ADD FOREIGN KEY (UF)
REFERENCES Estado (UF)
ADD FOREIGN KEY (Identificacao_Especialidade)
REFERENCES Especialidade (Identificacao_Especialidade)
ADD FOREIGN KEY (Numero_Sala)
REFERENCES Sala (Numero_Sala)
ADD FOREIGN KEY (Numero_Internacao)
REFERENCES Paciente (Numero_Internacao)
ADD FOREIGN KEY (CRM)
REFERENCES Medico (CRM)
ALTER TABLE Consumo
ADD FOREIGN KEY (Codigo_Produto)
REFERENCES Material_e_Medicamento (Codigo_Produto)
ALTER TABLE Consumo
ADD FOREIGN KEY (CRM, Numero_Internacao, Numero_Sala,
Data_Cirurgia, Hora_Cirurgia)
REFERENCES Cirurgia (CRM, Numero_Internacao,
Numero_Sala, Data_Cirurgia, Hora_Cirurgia)
ALTER TABLE Medico
ADD FOREIGN KEY (ID_Cidade, UF)
REFERENCES Cidade (ID_Cidade, UF)
SQL 381
ALTER TABLE Medico
ADD FOREIGN KEY (Id_Especialidade)
ADD FOREIGN KEY (Identificacao_Especialidade)
ADD FOREIGN KEY (Numero_Sala)
REFERENCES Sala (Numero_Sala)
Oracle 11g
CREATE TABLE Cidade (
ID_Cidade INTEGER NOT NULL,
UF CHAR(2) NOT NULL,
Descricao VARCHAR2(45) NULL
);
CREATE UNIQUE INDEX XPKCidade ON Cidade
(
ID_Cidade ASC,
UF ASC
);
CREATE INDEX XIF15Cidade ON Cidade
(
UF ASC
);
ALTER TABLE Cidade
ADD ( PRIMARY KEY (ID_Cidade, UF) ) ;
CREATE TABLE Cirurgia (
CRM SMALLINT NOT NULL,
Numero_Internacao INTEGER NOT NULL,
Numero_Sala INTEGER NOT NULL,
Data_Cirurgia DATE NOT NULL,
Hora_Cirurgia DATE NOT NULL,
Identificacao_Especialidade INTEGER NOT NULL,
Qtde_sangue_solicitada DECIMAL(2,1) NULL,
Qtde_sangue_utilizada DECIMAL(2,1) NULL
);
CREATE UNIQUE INDEX XPKCirurgia ON Cirurgia
(
CRM ASC,
Numero_Internacao ASC,
Numero_Sala ASC,
Data_Cirurgia ASC,
Hora_Cirurgia ASC
);
CREATE INDEX XIF1Cirurgia ON Cirurgia
(
CRM ASC
);
(
Identificacao_Especialidade ASC
);
(
Numero_Internacao ASC
);
(

Numero_Sala ASC
);
ADD ( PRIMARY KEY (CRM, Numero_Internacao, Numero_Sala,
Data_Cirurgia, Hora_Cirurgia) ) ;
CREATE TABLE Consumo (
Numero_Consumo CHAR(18) NOT NULL,
Codigo_Produto INTEGER NOT NULL,
Hora_Cirurgia DATE NOT NULL,
Data_Cirurgia DATE NOT NULL,
Quantidade DECIMAL(2) NULL
);
CREATE UNIQUE INDEX XPKConsumo ON Consumo
(
Numero_Consumo ASC,
Codigo_Produto ASC
);
CREATE INDEX XIF17Consumo ON Consumo
(
Codigo_Produto ASC
);
CREATE INDEX XIF3Consumo ON Consumo
(
CRM ASC,
Numero_Internacao ASC,
Numero_Sala ASC,
Hora_Cirurgia ASC,
Data_Cirurgia ASC
);
ALTER TABLE Consumo
ADD ( PRIMARY KEY (Numero_Consumo, Codigo_Produto) ) ;
CREATE TABLE Especialidade (
Descricao_Especialidade VARCHAR2(35) NULL
);
CREATE UNIQUE INDEX XPKEspecialidade ON Especialidade
(
);
ALTER TABLE Especialidade
ADD ( PRIMARY KEY (Identificacao_Especialidade) ) ;
CREATE TABLE Estado (
Nome__Estado VARCHAR2(40) NULL
);
CREATE UNIQUE INDEX XPKEstado ON Estado
(
UF ASC
);
ALTER TABLE Estado
ADD ( PRIMARY KEY (UF) ) ;
CREATE TABLE Material_e_Medicamento (
Codigo_Produto INTEGER NOT NULL,
Principio_Ativo VARCHAR2(50) NULL,
Descricao VARCHAR2(40) NULL,
Unidade VARCHAR2(2) NULL,
Saldo_Estoque DECIMAL(5,2) NULL
);
CREATE UNIQUE INDEX XPKMaterial_e_Medicamento ON Material_e_Medicamento
SQL 383
(
Codigo_Produto ASC
);
ALTER TABLE Material_e_Medicamento
ADD ( PRIMARY KEY (Codigo_Produto) ) ;
CREATE TABLE Medico (
ID_Cidade INTEGER NOT NULL,
Id_Especialidade INTEGER NOT NULL,
Nome VARCHAR2(40) NULL,
Endereco VARCHAR2(35) NULL,
Bairro VARCHAR2(25) NULL,
Salario NUMBER(24,4) NULL
);
CREATE UNIQUE INDEX XPKMedico ON Medico
(
CRM ASC
);
CREATE INDEX XIF16Medico ON Medico
(
ID_Cidade ASC,
UF ASC
);
CREATE INDEX XIF7Medico ON Medico
(
Id_Especialidade ASC
);
ALTER TABLE Medico
ADD ( PRIMARY KEY (CRM) ) ;
CREATE TABLE Paciente (
CPF VARCHAR2(11) NULL,
Nome VARCHAR2(40) NULL,
Endereco VARCHAR2(35) NULL,
Sexo VARCHAR2(1) NULL,
Nascimento DATE NULL,
Profissao VARCHAR2(35) NULL
);
CREATE UNIQUE INDEX XPKPaciente ON Paciente
(
Numero_Internacao ASC
);
ALTER TABLE Paciente
ADD ( PRIMARY KEY (Numero_Internacao) ) ;
CREATE TABLE Qualificacao_da_Sala (
Data_Inicio_qualificacao DATE NULL
);
CREATE UNIQUE INDEX XPKQualificacao_da_Sala ON Qualificacao_da_Sala
(
Numero_Sala ASC,
);
CREATE INDEX XIF5Qualificacao_da_Sala ON Qualificacao_da_Sala
(
Numero_Sala ASC
);
CREATE INDEX XIF6Qualificacao_da_Sala ON Qualificacao_da_Sala
(

);
ADD ( PRIMARY KEY (Numero_Sala, Identificacao_Especialidade) ) ;
CREATE TABLE Sala (
Andar VARCHAR2(5) NULL,
Ala_do_Centro VARCHAR2(25) NULL
);
CREATE UNIQUE INDEX XPKSala ON Sala
(
Numero_Sala ASC
);
ALTER TABLE Sala
ADD ( PRIMARY KEY (Numero_Sala) ) ;
ALTER TABLE Cidade
ADD ( FOREIGN KEY (UF)
REFERENCES Estado ) ;
ADD ( FOREIGN KEY (Identificacao_Especialidade)
REFERENCES Especialidade ) ;
ADD ( FOREIGN KEY (Numero_Sala)
REFERENCES Sala ) ;
ADD ( FOREIGN KEY (Numero_Internacao)
REFERENCES Paciente ) ;
ADD ( FOREIGN KEY (CRM)
REFERENCES Medico ) ;
ALTER TABLE Consumo
ADD ( FOREIGN KEY (Codigo_Produto)
REFERENCES Material_e_Medicamento ) ;
ALTER TABLE Consumo
ADD ( FOREIGN KEY (CRM, Numero_Internacao, Numero_Sala,
Data_Cirurgia, Hora_Cirurgia)
REFERENCES Cirurgia ) ;
ALTER TABLE Medico

ADD ( FOREIGN KEY (ID_Cidade, UF)
REFERENCES Cidade ) ;
ALTER TABLE Medico
ADD ( FOREIGN KEY (Id_Especialidade)
ADD ( FOREIGN KEY (Identificacao_Especialidade)
ADD ( FOREIGN KEY (Numero_Sala)
REFERENCES Sala ) ;
SQL 385
15
MODELAGEM DE DADOS E
MTODOS GEIS
Os mtodos geis so hoje uma metodologia de desenvolvimento consolidada, e sua
aplicao torna-se cada dia mais indiscutvel.
Nesse contexto, o projeto conceitual de bancos de dados precisa ser adaptado para que
se representem as abstraes de dados em um ambiente dinmico de validao delas.
Em projetos em que se utilizam mtodos geis, todos os desenvolvedores esto
orientados metodologia, evoluo e a uma caracterstica muito especfica desse mtodo,
que a refatorao do cdigo, e estes processos de refatorao so realizados com
naturalidade, produtividade e qualidade.
Refatorao (Refactoring) uma das prticas dos mtodos geis para um projeto
simples. Essa prtica mantm o foco das atividades de projeto (design) nas funcionalidades de
cada verso do sistema, sem prever possveis necessidades futuras. nesse ponto que
devemos nos concentrar para entender como ficam os projetos de bancos de dados com a
utilizao dos mtodos geis.
A seguir, vamos apresentar resumidamente os conceitos bsicos dos mtodos geis,
para facilitar o entendimento da modelagem conceitual com a utilizao desses mtodos e as
consequncias de projeto e implantao de banco de dados.
Mtodos geis
O Manifesto for Agile Software Development, ou simplesmente Manifesto gil, formaliza
os princpios bsicos que do suporte aos mtodos geis de desenvolvimento de software.
O termo gil (agile) foi adotado pelos criadores desses mtodos, que formaram a
Aliana gil (Agile Alliance) e disponibilizaram suas ideias, bem como diversos recursos
relacionados a elas, em um website (AGILE ALLIANCE, 2005).
O Manifesto gil resume-se s linhas do quadro apresentado a seguir:

De acordo com o site do Manifesto, seus participantes esto descobrindo melhores formas de
desenvolver software, enquanto o fazem e enquanto ajudam os outros a faz-lo.
Por meio desse trabalho, passaram a valorizar:
indivduos e interaes mais que processos e ferramentas;
software funcionando mais que documentao abrangente;
colaborao do cliente mais que negociao contratual;
responder a mudanas mais que seguir um plano.
Embora tambm haja valor nos itens direita, o manifesto d mais valor aos itens esquerda.
Os princpios fundamentais que do suporte aos mtodos geis so os seguintes:
1. A maior prioridade satisfazer o cliente por meio da entrega pronta e contnua de software
com valor agregado.
2. Devem-se receber bem as alteraes em requisitos, mesmo tarde no desenvolvimento.
Processos geis suportam mudanas para a vantagem competitiva do cliente. Responder a
mudanas mais que seguir um plano significa uma rpida adaptao s mudanas.
3. Deve haver entregas de softwares funcionando frequentemente, de algumas semanas a
alguns poucos meses, com preferncia para a escala de tempo mais curta.
4. Interessados na aplicao (stakeholders) e desenvolvedores devem trabalhar juntos
diariamente ao longo do projeto. Deve haver cooperao constante entre pessoas que
entendem do negcio e desenvolvedores.
5. Os projetos devem ser construdos ao redor de indivduos motivados, dando a eles o
ambiente e o suporte de que precisam e confiando neles para que faam o servio.
6. O mtodo mais eficiente e eficaz de conduzir informaes para e dentro de um time de
desenvolvimento a comunicao face a face. Devem-se valorizar indivduos e interaes
mais que processos e ferramentas.
7. Software funcionando a medida principal de progresso.
8. Processos geis promovem desenvolvimento sustentvel. Patrocinadores, desenvolvedores
e usurios devem ser capazes de manter um ritmo constante indefinidamente. Deve-se
valorizar a colaborao com clientes mais que a negociao de contratos.
9. Ateno contnua excelncia tcnica e ao bom projeto aumenta a agilidade.
10. Simplicidade a arte de maximizar a quantidade de trabalho no realizado essencial.
11. As melhores arquiteturas e os melhores requisitos e projetos surgem de times auto-
organizados.
12. Em intervalos regulares, o time deve refletir sobre como pode se tornar mais eficaz, e ento
deve melhorar e ajustar seu comportamento de acordo com isso.
Fonte: Manifesto para o Desenvolvimento gil de Software. Disponvel em: http://manifestoagil.com.br/.
Modelagem de Dados e Mtodos geis 387

Os valores e princpios do Manifesto gil so a fundamentao dos mtodos geis.
Dentro da viso gil, o projeto de sistemas realizado por meio de releases, ou verses
do projeto que vo sendo liberadas e implementadas evolutivamente, em sntese.
Em vez de etapas e atividades definidas no incio do projeto, o ciclo de vida de um
projeto gil composto por iteraes de software funcionando, denominadas sprints.
Esse ciclo de vida representado pela figura a seguir, conhecidssima de vrios artigos
na web, mas que vale a pena apresentar:
Ciclo de vida gil
Nessa viso e nesse formato de execuo de um projeto, cria-se uma zona de conflito
entre os desenvolvedores e os administradores de dados, pois estes ltimos atuam com
processos e ferramentas no to flexveis, alm de trabalharem com a preocupao de manter
estruturas de dados duradouras e estveis.
Como o projeto de sistema vai sendo desenvolvido e so liberados releases
periodicamente, as estruturas de bancos de dados tambm podem ser modeladas pouco a
pouco, apesar de ser possvel explorar suas caractersticas e detalhes mais profundamente,
mesmo durante o desenvolvimento de um sprint, em que no sejam explorados ou apaream
todos os seus atributos durante a anlise de requisitos na modelagem gil1.
1Conhea mais sobre mtodos geis em: MACHADO, F. N. Anlise e gesto de requisitos de
software: onde nascem os sistemas. So Paulo: rica, 2013.

A refatorao de banco de dados
Analisando o impacto sobre a implantao dos bancos de dados, observamos que
refatorar qualquer estrutura de tabelas de um deles uma tarefa complexa e que pode, caso
exista uma administrao de dados independente do desenvolvimento com os mtodos geis,
criar um ponto de perda de produtividade dos ganhos obtidos com a aplicao desses
mtodos.
Por outro lado, podemos considerar que esse formato de desenvolvimento pode criar
estruturas de dados particionadas verticalmente, ou seja, uma tabela que representaria um
objeto de negcio pode ser criada como duas tabelas com nomenclatura similar e com
relacionamento um para um entre si, ou tambm pode levar a estruturas de dados com nvel
acentuado de redundncias.
De qualquer maneira, uma vez que um projeto de banco de dados tenha sido
implementado e seja necessrio acrescentar colunas em tabelas j em produo, ser
necessrio que, antes que um novo release de aplicao seja liberado, realize-se a recarga
das tabelas com as novas colunas.
Lembre-se de que o modelo fsico sempre construdo a partir de um modelo lgico, e
que descreve as estruturas fsicas de armazenamento de dados importantes, como restries,
gatilhos etc., o que faz com que, a cada release liberado, seja necessrio implementar tabelas
com seus relacionamentos ou colunas de foreign key e restries para novos relacionamentos
decorrentes de requisitos detalhados nesse sprint de desenvolvimento.
Considere que, entre os primeiros sprints, no normal aparecerem muitas alteraes
desse tipo; porm, conforme o projeto vai avanando, a probabilidade aumenta, e assim as
consequncias, caso no haja ateno suficiente.
Quando mais avanado estiver o projeto e quanto maior o nmero de sprints realizados
e verses liberadas para o ambiente de produo do software objeto do projeto, maior o
trabalho para a realizao de refatorao do banco de dados. Isso ir, inclusive, criar
momentos em que a produtividade obtida com os mtodos geis ser afetada, pois pode ser
necessria a realizao de anlise de impacto nas aplicaes j liberadas e em produo com
relao s mudanas que sero necessrias na refatorao do banco de dados, o que, por si
s, j demanda tempo de trabalho para a realizao do cruzamento das estruturas do banco
com a utilizao delas pela aplicao j liberada e em produo.
Consequentemente, existir a necessidade de refatorao de cdigos j liberados e
novos testes de aplicao e aderncia das estruturas de banco, provocando a existncia de
sprints paralelos de manuteno e gesto de mudanas, antes da finalizao do sprint gerador
do fato.
Modelagem de Dados e Mtodos geis 389

O futuro da modelagem de dados
Ao trabalhar com mtodos geis, importante, antes de realizar qualquer refatorao
no banco de dados, entender a necessidade preservar tanto a semntica comportamental das
aplicaes que j acessam o banco de dados implementado quanto a semntica informacional,
ou seja, o significado das informaes j implementadas no banco de dados do ponto de vista
dos usurios dessas informaes.
Assim, qualquer alterao na base, seja ela uma refatorao, uma transformao ou
uma migrao, precisa ser submetida constantemente a testes de integrao, e posteriormente
ser controlada em um ambiente de homologao, da mesma forma que as aplicaes, antes
que essas alteraes sejam aplicadas na base de produo e seja possvel liberar um novo
release do projeto que est sendo realizado.
Com ateno e sem perder o foco na obteno dos requisitos de dados, podemos
realizar a modelagem de dados de forma gil e precisa, e tambm controlar a evoluo das
instncias do banco de dados.
Em breve, vamos explorar com mais detalhes as tcnicas de controle de scripts de
bancos de dados, em conjunto com as verses de sistemas, pois consideramos importante ter
um ciclo de vida para as alteraes da base de dados que envolvam a aplicao dos scripts
SQL, obtendo uma estrutura/tabela nova. Tambm importante, antes que a estrutura/tabela
antiga seja considerada obsoleta, termos mtodos para certificar-nos de que a alterao
realmente apropriada e adequada verso da aplicao que est por ser liberada.
Sugerimos, ento, de forma simplificada, que sejam adotadas como boas prticas:
agrupar alteraes pequenas, formando uma nica alterao grande;
identificar unicamente cada alterao;
simplificar o processo de negociao de alteraes com o time de desen-
volvimento, assim como o processo de controle de alteraes do banco de dados;
no duplicar scripts SQL, dispondo-os em um nico lugar, com controle de
versionamento relacionado diretamente verso de software.
Com este captulo, esperamos ter dado uma contribuio aos que estudam tanto
projetos de software quanto projetos de bancos de dados, disciplinas que caminham em
conjunto.
Indicaes de leitura
AMBLER, S. W.; SADALAGE, P. J. Refactoring databases: evolutionary database
design. Michigan: Addison Wesley, 2006.
SADALAGE, P. J. Recipes for continuous database integration: evolutionary
database development. Michigan: Addison Wesley, 2007.

Bibliografia
BATINI, C.; CERI, S.; NAVATHE, S.B. Conceptual Database Design: An Entity-Relationship Approach.
California: Benjamin/Cummings Publishing, 1992.
BOEHM, B.W. Software Engineering Economics. New Jersey: Prentice-Hall, 1981.
BOHM, C.; JACOPINI, G. Flow Diagrams, Turing Machines and Languages with Only Two
Formation Rules. EUA: Communications of the ACM, v. 9, n. 5, pp. 366-371, 1966.
BOWMAN, J.S. The Pratical SQL Handbook: using strutured query language. USA: Addison-Wesley
Developers Press, 1996.
BRADLEY, J. Introduction to DataBase Management in Business. 2. ed. New York: HRW IE, 1987.
CHEN, P. The Entity-Relationship Model: Toward a Unified View of Data. EUA: ACM Transactions on
DataBase Systems, v. 1, n. 1, pp. 9-36, 1976.
CODD, E. F. Is Your DBMS Really Relational? EUA: Computer World, out 1985.
______. The Relational model for database management. USA: Addison-Wesley Publishing, 1990.
______. A relational Model of Data for Large Shared Data Banks. EUA: Communications ACM. v. 13,
n. 6, pp. 377-387, 1970.
DEMARCO, T. Structured Analisys and System Specification. New Jersey: Prentice-Hall, 1978.
DIJKSTRA, E.W. Go To Statements Considered Harmful. EUA: Communications of the ACM. v. 11,
n. 3, pp. 147-148, maio, 1966.
FERNANDES, A.C.; LAENDER, A.H.F. MER+: uma extenso do modelo de entidades e
relacionamentos para o projeto conceitual de Banco de Dados. Rio de Janeiro: Revista Brasileira de
Computao, v. 5, n. 1, 08/09, SBC/NCE, 1989.
FLAVIN, M. Fundamental Concepts of Information Modeling. New York: Yourdon Press, 1981.
GANE, C.; SARSON, T. Structured Systems Analysis: Tools and Techniques. New Jersey:
Prentice-Hall, 1979.
KENT, W. A Simple Guide to Five Normal Forms in Relational DataBase Theory. EUA:
Communications of the ACM. v. 26, n. 2, pp. 120-125, 1983.
KIPPER, E.F.; et al. Engenharia de Informaes: Conceitos, Tcnicas e Mtodos. Porto Alegre:
SAGRA-DC LUZZATO, 1993.
KOWAL, J.A. Analyzing Systems. New Jersey: Prentice-Hall, 1988.
LEO, R.O.; SILVA, J.C. SQL Server 2000: Estrutura e Implementao de Sistemas de Bancos de
Dados. So Paulo: rica, 2002.
LIMA, A.S. ERwin 4.0: Modelagem de Dados. So Paulo: rica, 2002.
MACHADO, FELIPE. Analise e Gesto de Requisitos de Software: Onde Nascem os Sistemas.
So Paulo: rica, 2013.
MACIASZEK, L.A. Database Design and Implementation. Austrlia: Prentice-Hall, 1990.
Bibliografia 391
______. Database Design and Implementation. Austrlia: Prentice-Hall, 1989.
MARTIN, J.; FINKELSTEIN, C. Information Engineering. v. I / II. Inglaterra: Savant Institute, 1981.
MATOS, A.V. UML: Prtico e Descomplicado. So Paulo: rica, 2002.
MELO, L.E.V. Gesto do Conhecimento: Conceitos e Aplicaes. So Paulo: rica, 2003.
MORELLI, E.T. Oracle 8: SQL, PL/SQL e Administrao. So Paulo: rica, 2000.
ZSU, M.T.; VALDURIEZ, P. Princpios de Bancos de Dados Distribudos. Rio de Janeiro: Campus, 2001.
RODRIGUES, M. V. R. Gesto Empresarial: Organizaes que Aprendem. Rio de Janeiro, 2002.
SETZER, V.W. Bancos de Dados: Conceito, Modelos, Gerenciadores, Projeto Lgico e Projeto Fsico.
So Paulo: Edgard Blcher, 1986.
SHLAER, S.; MELLOR, J.S. Anlise de Sistemas Orientada para Objetos. So Paulo: McGraw-Hill/
Newstec, 1990.
SILBERSCHATZ, A.; KORTH, H.F.; SUDARSHAN, S. Sistema de Banco de Dados. So Paulo: Makron
Books, 1999.
STAA, A.V. Engenharia de Programas. Rio de Janeiro: LTC, 1986.
STEVENS, W.; MYERS, G.; CONSTANTINE, L. Structured Design. EUA, IBM Systems Journal, v. 13,
n. 2, pp. 115-139, 1979.
TASKER, D. Fourth Generation Data: A Guide to Data Analysis for New and Old Systems. Austrlia:
Prentice-Hall, 1989.
TEOREY, T.J. Database Modelling & Design. San Francisco: Morgan Kaufmann Publisher, 1999.
TRIMBLE Jr., J.H.; CHAPPELL, D. A Visual Introduction to SQL. New York: John Wiley & Sons /
Metaphor Computer System., 1989.
YOURDON, E. Anlise Estruturada Moderna. Rio de Janeiro: Campus, 1990.
YOURDON, E.; COAD, P. Anlise Baseada em Objetos. Rio de Janeiro: Campus, 1992.
Sites
AMBLER, S. W. Agile Modeling and the Unified Process. 2001.
Disponvel em: http://www.agilemodeling.com/essays/agileModelingRUP.htm.
NASCIMENTO, A. O que SCRUM.
Disponvel em http: //www.oficinadanet.com.br/artigo/gerencia/o_que_e_scrum.
SCHWABER, K. The Impact of Agile Processes on Requirements Engineering. 2002.
Disponvel em: http://www.agilealliance.org/articles/schwaberkentheimpacto/view?searchterm=requirements.
Marcas Registradas
ERWin 4.0 by Computer Associates International, Inc.
Microsoft SQL Server 2008 by Microsoft Corporation.
Oracle Database 11g by Oracle Corporation.

ndice Remissivo
A
Abstrao, 14-17, 23, 27-29, 31-35, 37, 38, 69, 70, 73, 75, 76, 102, 129, 137, 150,
158, 195, 204-206, 208, 212
Administrao de dados, 13, 25, 219
Administrador de dados, 24
Agregao, 15, 23, 28, 29, 31, 33, 35, 36, 104, 122, 123, 125, 128, 129, 135, 136,
138141, 143-145, 148-150, 153, 154, 156, 157, 209, 211, 240, 241, 290, 291,
297, 338, 340
reflexiva, 152
Agregar, 29
lgebra Relacional, 25, 41, 114, 242, 243, 250, 260, 264, 283, 290, 297, 303-305,
323, 326, 329, 342
Anomalias, 24, 178, 179, 187, 190, 200
rvore de vises, 173
Atributos, 53, 67, 72, 80, 81, 108, 116, 119, 127, 291, 304
de uma entidade, 72, 92, 191
Autorrelacionamento, 83, 85, 216, 217, 376
B
Binrio, 75, 76, 314
Boyce, 190
C
Cardinalidade
mxima, 36
mnima, 34-36
Cascade, 59, 60
CASE, 93, 109, 111, 128, 143, 144, 213, 218
Char, 45, 314-318, 320, 322, 331, 380, 381
Chave
candidata, 54, 58, 63, 92, 191-193, 201, 235
estrangeira, 56-59, 61, 64, 117, 157, 217, 227, 234-236, 315, 319, 320, 343,
347, 376
primria, 46, 47, 49-59, 61, 73, 92, 109, 113, 181-185, 187, 188, 200, 201,
213, 218, 223, 225, 227, 233-235, 237-239, 241, 284, 306, 315, 317, 319,
321, 339, 347, 373, 376
substituta, 223
Classes de dados, 67
Classificao, 15, 23, 28, 30-32, 43, 101, 163, 167, 173, 175, 212
Codd, 23, 39, 40, 178, 190, 306
Comutatividade, 299, 300
Concatenao das colunas, 47, 48, 157
Condicional, 82
ndice Remissivo 393

Conectividade, 71, 76-80, 82, 83, 85, 89, 96, 97, 108, 129, 130, 138, 148, 149,
158, 197, 207, 208
Converso de modelo lgico, 219
D
Data Warehouse, 203, 223
DBA, 15, 307
DDL, 21, 308
Dependncia
de juno, 198
funcional, 184, 185, 187, 192
multivalorada, 193, 195, 196
Dependentes transitivos, 201
Desnormalizao, 203
Diagrama ER, 70, 104, 156, 169, 175, 211, 212
Diferena, 64, 160, 242, 243, 269, 270, 272, 358, 360
Diviso, 196, 243, 280, 281, 288
DML, 308
Domnio, 44, 227
E
Efetivao lgica, 109, 113, 117, 119
E-nrio, 75, 76
Encapsulamento, 174, 232
Entidade, 32, 65, 67, 68, 92, 93, 119
fraca, 92
generalizadora, 169, 173
Erros de modelagem, 191
Estruturas hierrquicas, 215
F
FNBC, 190-195, 201, 202
Funes em lgebra Relacional, 290
G
Generalizao, 15, 23, 28-31, 83, 102, 104, 105, 170, 212, 239
H
Herdar a chave, 196, 201
I
ndices, 20, 25, 218, 223, 242, 309, 372-374
Integer, 45
Integridade referencial, 57, 59

Interpretaes, 115, 159, 160, 162-167, 170, 171, 172, 174, 175, 176, 206
Interseo, 242, 243, 274
J
Java, 14, 26
Juno, 72, 194, 198-199, 243, 275-279, 282, 287, 288, 290, 298-302, 342, 345,
348, 373
L
Levantamento de dados, 24, 213
M
Mapeamento, 33-35, 76, 224, 231-233
Metamodelo, 22, 23, 65
Minimundo, 16, 18, 20, 69, 85, 87, 88, 91, 95, 129, 143
Modelagem de dados, 13, 14, 16, 20, 23, 24, 26, 32, 39, 66, 67, 71, 72, 108, 158,
159, 167, 197, 202
Modelo
conceitual, 16, 18, 19, 25
de classes, 14, 66, 232, 233, 234, 241
de classes de objetos, 14
Entidade-Relacionamento, 22, 65, 68
lgico de dados, 14, 19, 74, 239
N
Necessidades de informao, 17
Notao grfica, 72, 93, 108
O
Opcionalidade, 82, 89, 117, 133
Operaes relacionais, 249, 250, 251, 254, 262, 264, 280, 283, 305
P
Persistncia, 13, 231, 232
Primeira forma normal, 178-180, 182, 185
Produto cartesiano, 242, 243, 251, 254, 259, 261, 267, 275, 276, 279
Projeo, 114, 199, 243-248, 250, 255, 258, 261, 280, 286, 288-290, 292, 293,
323
Projeto orientado a objetos, 13
Q
Quarta Forma Normal, 195, 200
ndice Remissivo 395

R
Redundncias, 170, 177, 189, 200, 202, 210, 340
Relacionamento, 15, 18, 19, 23, 28, 29, 65, 67, 70, 71, 75, 76, 81, 83, 85, 87, 89,
92- 96, 98, 102, 104, 105, 106, 108, 109, 111, 113, 115, 117, 120, 122, 124,
126-128, 133-137, 140, 143, 144, 146, 147, 149, 150, 152, 154, 160, 162,
164-166, 169, 170, 174, 189, 196, 198, 199-203, 213, 223, 232, 239, 240,
275
reflexivo, 84, 85, 90, 153, 154, 216
Renomeao, 243, 303
Renomear, 259, 260, 293
Repositrios, 231
Restrio, 61, 227, 283
Rumbaugh, 72, 94
S
Script, 21, 225, 232, 379
Segunda Forma Normal, 184, 184, 186, 187
Seleo, 114, 178, 232, 243, 246-248, 250, 255, 256, 260, 262, 263, 267, 275,
276, 278-280, 285, 286, 308, 322, 323, 326, 327, 330, 334, 340, 346, 348,
358, 370-372
SELECT, 217, 226, 322-347, 349-367, 369, 370, 375
Similaridades, 161
Subtipos, 102, 103
Supertipo, 102, 103
T
Teoria Relacional, 39-41
Terceira Forma Normal, 187, 188
Ternrios, 76, 106, 196, 201
Tipo de dado, 45, 218, 219, 318, 326, 331
U
Um-para-muitos, 78, 79-81, 83, 85, 117, 217
Unio, 242, 243, 264, 266, 267, 269, 274, 293
V
Valor nulo, 51-53, 64, 118, 301, 334, 376
Vises, 23, 153, 162, 167, 170, 218, 222, 309

T-SQL com Microsoft SQL Server 2012 Express na Prtica
Autor: Rodrigo Ribeiro Gonalves
Cdigo: 4537 120 pginas Formato: 17 x 24 cm ISBN: 978-85-365-0453-7 EAN: 9788536504537
Esta obra serve como referncia para o desenvolvimento de banco de dados com o Microsoft SQL Server 2012 Express, para
profissionais, estudantes e interessados na rea de Tecnologia da Informao. De forma didtica, com exemplos e exerccios
prticos, descreve tcnicas de programao com a linguagem SQL, ensinando a instalar e utilizar softwares relacionados. Explica
como criar e alterar tabelas, procedures, funes, views e triggers; utilizar o SQL dinmico; trabalhar com datas, chaves primrias
e estrangeiras, JOINS e strings. Oferece noes de administrao de banco de dados, como rotinas de backup e restaurao.
Recomenda-se que o leitor tenha noes de programao e teoria de banco de dados.
MariaDB 5.5 - Interativo: Guia Essencial de Orientao e Desenvolvimento - para Windows

Autor: Jos Augusto N. G. Manzano
Cdigo: 4155 256 pginas Formato: 17,5 x 24,5 cm ISBN: 978-85-365-0415-5 EAN: 9788536504155
Apresenta ao iniciante na administrao de bancos de dados os recursos do programa gerenciador MariaDB verso 5.5, de forma
simples e didtica. Destaca os conceitos bsicos, o surgimento da linguagem de consulta estruturada SQL; aquisio e instalao
do programa; manuseio, criao e remoo de bancos de dados.
Descreve como criar tabelas e realizar consultas; operadores aritmticos; uso de funes; agrupamentos, unies, junes e visua-
lizaes de dados; utilizao de ndices; chaves primria e estrangeira; stored procedures; triggers e functions.
Integrao de Dados na Prtica

Tcnicas de ETL para Business Intelligence com Microsoft Integration Services 2012
Autor: Rodrigo Ribeiro Gonalves
Entender conceitos como Data Warehouse, Business Intelligence, ETL (extrao, transformao e carga) e os jarges da indstria
essencial para quem quer trabalhar com integrao de dados. Neste sentido, o livro foi escrito, explicando tambm tabelas fato e
dimenso e a importncia das dimenses que mudam lentamente, chamadas de Slowly Changing Dimensions.
Apresenta o Microsoft Integration Services 2012 e o Solution Explorer, introduzindo controles mais avanados como Control Flow e
Data Flow, variveis e arquivos de configurao. Para que o leitor entenda melhor a ferramenta, um pequeno projeto de Business
Intelligence desenvolvido, sendo criados trs bancos de dados bsicos. Conforme o projeto de ETL montado, integraes so
realizadas: Import/Export Wizard, arquivos texto, Microsoft SQL Server 2012, Data Conversion, Derived Column, Conditional Split,
Merge e o MultiCast, alm de mostrar como utilizar o Data Viewer para analisar a execuo dos pacotes.
indicado a analistas de sistemas, administradores de banco de dados e desenvolvedores de software com conhecimentos bsi-
cos de banco de dados e SQL para criao de tabelas e consultas, assim como inserts e updates.
Microsoft SQL Server 2012 Express - Guia Prtico e Interativo

Cdigo: 414A 208 pginas Formato: 17 x 24 cm ISBN: 978-85-365-0414-8 EAN: 978853654148
Estudantes e profissionais da rea encontram nesta obra os principais recursos do programa gerenciador Microsoft SQL Server
2012 Express.
Descreve o surgimento da linguagem de consulta estruturada SQL; aquisio e instalao do programa; manuseio, criao e remo-
o de bancos de dados; tabelas e consultas; uso de funes; agrupamentos, unies, junes e visualizaes de dados; utilizao
de ndices; chaves primria e estrangeira; stored procedures; triggers e functions.
Contempla tambm uma srie de atividades para facilitar o aprendizado.
MySQL 5.5 - Interativo - Guia Essencial de Orientao e Desenvolvimento

Esta obra apresenta ao leitor iniciante na prtica de administrao de bancos de dados o programa gerenciador Oracle MySQL 5.5.
Abrange o surgimento da linguagem de consulta estruturada SQL; aquisio e instalao do programa; manuseio, criao e remo-
o de bancos de dados; tabelas e consultas; uso de funes; agrupamentos, unies, junes e visualizaes de dados; utilizao
de ndices; chaves primria e estrangeira; stored procedures; triggers e functions.
O contedo segue a mesma estrutura didtica do livro MySQL 5.1 - Interativo - Guia Bsico de Orientao e Desenvolvimento,
porm as telas, os comandos e os textos foram adaptados verso 5.5 do programa.
Banco de Dados
PostgreSQL 8.3.0 - Interativo: Guia de Orientao e Desenvolvimento
Objetiva, didtica e interativa, esta obra fornece um estudo do programa gerenciador de banco de dados PostgreSQL em sua
verso 8.3.0, para Windows.
Apresenta o histrico da linguagem de consulta estruturada SQL e do PostgreSQL. Descreve a aquisio e instalao do pro-
grama, manuseio, criao e remoo de bancos de dados, tabelas, consultas, uso de funes, agrupamentos, unies, junes
e visualizao de dados, gerenciamento de usurios, chaves primria e estrangeira, rotinas armazenadas (funes e gatilhos) e
ferramentas de administrao.
Possui uma srie de atividades de manuseio do programa e exerccios de fixao e indispensvel aos iniciantes na administrao
de banco de dados.
Oracle Database 10g Express Edition - Guia de Instalao, Configurao e Administrao

com Implementao PL/SQL Relacional e Objeto-Relacional
Autor: Robson Soares Silva
O livro detalha os principais recursos desse poderoso banco de dados, como a aquisio e instalao do programa, criao de
tabelas, chaves primria e estrangeira, consultas SQL, utilizao de ndices, usurios do sistema, criao de usurios, concesso e
restrio de direitos de acesso, programao PL/SQL, procedures, functions, packages, triggers, implementao objeto-relacional,
criao de aplicaes, acesso remoto, backup e restore, flashback, nveis de certificao e conexo Oracle com o Java.
Possui tambm diversos exerccios propostos, alm de um simulado com questes para certificao.
Estudo Dirigido de Microsoft Access 2013

Autor: William Pereira Alves
Com estilo agradvel, este livro trata dos principais recursos do Access 2013 para o desenvolvimento de aplicaes de banco de
dados. O aprendizado complementado com exerccios e exemplos, incluindo um projeto de aplicativo.
Conceitos e fundamentos de bancos de dados relacionais abrem o estudo. Em seguida, explicam-se criao e alterao de tabelas;
manipulao de registros do banco de dados (insero, alterao e excluso); criao, alterao e execuo de consulta; constru-
o e uso de formulrios de entrada de dados, relatrios e etiquetas de endereamento; elaborao de macros e desenvolvimento
de rotinas em Visual Basic for Applications (VBA), para automatizar tarefas. Ao final, ensina-se como trocar informaes do Access
2013 com o Word 2013 e o Excel 2013.
A leitura recomendada a estudantes, profissionais e demais interessados na rea.
Banco de Dados - Projeto e Implementao - Edio Revisada

Autor: Felipe Nery Rodrigues Machado
Com uma apresentao diferenciada, utilizando metodologia e conceitos embasados na execuo prtica de projetos de banco
de dados, o livro traz a experincia do autor, com uma linguagem simples e objetiva, que permite a compreenso das tcnicas de
forma gradativa e efetiva.
Destaca aspectos conceituais, a orientao gesto de negcios e aborda a utilizao de lgebra relacional, mapeamento
OO -> ER no projeto de banco de dados, comandos bsicos da linguagem SQL ANSI, explanados com exemplos e estudos de
caso.
A segunda reimpresso da segunda edio foi revisada e atualizada para Microsoft SQL 2008 e Oracle 10g.
Banco de Dados - Teoria e Desenvolvimento

Didtico e interativo, este livro aborda os principais conceitos e fundamentos de bancos de dados, como os tipos de acesso a
arquivos, estruturas de dados (listas lineares e rvores), mtodos de ordenao (Bubble Sort, QuickSort e Shell), arquitetura e orga-
nizao, lgebra relacional, uso de ndices, modelagem e normalizao de dados, os cuidados necessrios implementao de um
banco de dados, conceito e estrutura de Data Warehouse (OLAP, OLTP, Data Mining e Data Mart), bancos de dados distribudos,
dedutivos, hierrquicos, de rede e orientados a objetos (ODL e OQL), segurana e proteo com nveis de acesso dos usurios,
processamento de transaes e princpios da linguagem SQL.
Banco de Dados
Estudo Dirigido de Microsoft Word 2013
Autores: Andr Luiz N. G. Manzano e Maria Izabel N. G. Manzano
Cdigo: 4568 160 pginas Formato: 17 x 24 cm ISBN 978-85-365-0456-8 EAN 9788536504568
As principais ferramentas do Word 2013 para criao de documentos criativos e sofisticados compem este livro. Com diversos
exerccios, ensina como inserir e remover textos, movimentar o cursor, editar documentos, acentuar palavras, fazer a correo
ortogrfica, usar a rea de transferncia, salvar arquivos e imprimi-los.
Tambm explora a formatao de documentos, alinhamentos, recuos de pargrafo, marcadores, tabulao, cabealho, rodap e
numerao de pginas, insero de tabelas e grficos.
Descreve como elaborar um jornal e, ainda, abrange mala direta, uso de textos automticos e etiquetas, mesclagem de documentos
e impresso. Indica como sanar dvidas sobre o programa, usar atalhos para executar comandos, personalizar a barra de status,
revisar o texto e muito mais.
Estudo Dirigido de Microsoft Excel 2013

Autor: Andr Luiz N. G. Manzano
Cdigo: 449A 208 pginas Formato: 17 x 24 cm ISBN: 978-85-365-0449-0 EAN: 9788536504490
O livro apresenta os principais recursos do Excel 2013, com abordagem simples e dinmica. Estudantes e profissionais da rea po-
dem se beneficiar de explicaes didticas, exemplos prticos, descritos passo a passo, e exerccios, para reforar o aprendizado.
Introduz a nova interface do aplicativo, incluindo grupos, comandos e guias. Ensina a criar e formatar planilhas, inserir frmulas,
trabalhar com funes matemticas, operar com bases de dados, criar grficos, imprimir relatrios e usar comandos de congela-
mento. Trata do bloqueio de edio e da criao de senhas para planilhas. Apresenta planilhas de consolidao e traz dicas sobre
personalizao e teclas de atalho.
Estudo Dirigido de Microsoft Excel 2013 - Avanado

Autores: Jos Augusto N. G. Manzano e Andr Luiz N. G. Manzano
O livro destaca os recursos avanados do Excel 2013, sendo direcionado para estudantes e profissionais da rea. Em dez captu-
los, apresenta, demonstra e revisa funes de clculos; abrange a criao e a anlise de bases de dados; compreende o uso de
tabelas e grficos dinmicos. Oferece exemplos de folhas de pagamento, cadastros de alunos, planejamento financeiro e tabelas
de vendas. Descreve a utilizao de macros e recursos relacionados a atividades de programao, incluindo tipos de macro e sua
execuo, cadastros para armazenamento de dados, macros interativas e tcnicas para a personalizao de campos. Oferece,
tambm, exemplos e exerccios.
Integrao de Dados com PowerPivot e Microsoft Excel 2010

Autor: Newton Roberto Nunes da Silva
Fornece explicaes passo a passo sobre o PowerPivot para Excel 2010, com exerccios e exemplos para auxiliar estudantes e
profissionais da rea. Explica a instalao do programa e procedimentos para importar dados, formatar colunas, vincular dados
do Excel e atualiz-los no PowerPivot. Aborda relacionamentos, Expresses de Anlise de Dados (Data Analysis Expressions),
segmentaes, relatrios de tabela e grfico dinmico, alm do uso de funes DAX para criar medidas especficas para relatrios
dinmicos. Concluindo, abrange a formatao final do relatrio no PowerPivot, deixando-o com um aspecto mais profissional e com
caractersticas de painel de controle, que consolida dados e exibe-os de forma inteligvel.
Guia Prtico de Informtica - Terminologia, Microsoft Windows 7

(Internet e Segurana), Microsoft Office Word 2010, Microsoft Office Excel 2010,
Microsoft Office PowerPoint 2010 e Microsoft Office Access 2010
Esta obra apresenta os conceitos essenciais de informtica para o dia a dia, principalmente para leitores nos primeiros estgios
de aprendizagem. Mostra a terminologia da rea, como computadores, sistemas operacionais, programas aplicativos e perifricos,
bem como os recursos do Microsoft Windows 7, Internet e princpios de segurana. Abrange as principais ferramentas do Microsoft
Office 2010: Word (processador de textos), Excel (planilha eletrnica), PowerPoint (gerenciador de apresentaes) e Access
(gerenciador de banco de dados).
Office & Processamento de Dados

Estudo Dirigido de Microsoft Office PowerPoint 2010
Autor: Andr Luiz N. G. Manzano
A verso 2010 do PowerPoint proporciona mais criatividade e produtividade aos trabalhos desenvolvidos com essa ferramenta.
O livro apresenta de forma didtica e objetiva as tcnicas de oratria, conceitos de apresentao, etapas para criao de slides,
formatao, alinhamentos, grficos, aplicao de design e cores, padres, indicao dos meios para obter ajuda, atalhos.
O contedo programtico til a alunos e professores de instituies de ensino e tambm a profissionais da rea.
Informtica - Terminologia - Microsoft Windows 7 - Internet -

Segurana - Microsoft Office Word 2010 - Microsoft Office Excel 2010
- Microsoft Office PowerPoint 2010 - Microsoft Office Access 2010
Autor: Mrio Gomes da Silva
Embasamento fundamental sobre o uso do computador com Windows 7 e o conjunto de aplicativos Office 2010 encontrado
nesta obra.
Apresenta a histria do computador, unidades de armazenamento, perifricos, funcionalidades e tarefas bsicas do Windows
7, conexo com Internet, navegao, e-mails e ferramentas de segurana. Destaca os principais recursos do Word 2010 para
criao e formatao de textos, ortografia, impresso e reviso, rodaps e tabelas. Explora a criao de planilhas com Excel 2010,
navegao, edio e manipulao de arquivos, operaes bsicas, cpias e formatao de dados, frmulas, funes e grficos.
Com o PowerPoint 2010 ensina como criar apresentaes, estruturar tpicos, usar formas, animaes, transio de slides e im-
presso. Mostra como criar banco de dados com Access 2010, terminologias, edio de tabelas, digitao de dados, consultas,
formulrios e relatrios. Traz uma srie de exerccios de fixao que objetivam aprimorar o conhecimento transmitido na obra.
Informtica - Conceitos e Aplicaes

Autores: Marcelo Marula e Pio Armando Benini Filho
Este livro indicado como material de apoio aos cursos de Informtica e disciplinas afins dos demais cursos. Pode ser utilizado por
professores (como uma diretriz bsica para a disciplina), alunos (fonte de pesquisa para os principais conceitos) e profissionais de
todas as reas, que necessitem adquirir conhecimentos sobre informtica.
Aborda conceitos bsicos de informtica, caractersticas dos componentes que formam o hardware, definio e classificao dos
softwares, redes, arquiteturas, infraestrutura e servios de Internet, segurana de dados, autenticao, criptografia, antivrus e
firewall.
Informtica Fundamental - Introduo ao Processamento de Dados

Muitas pessoas utilizam computadores no dia a dia sem ter a menor ideia de como eles e seus diversos componentes e perifricos
trabalham. Pensando neste aspecto, o livro apresenta conceitos e fundamentos de um sistema computacional, explicando como
funcionam monitores, impressoras, escneres, leitores de CD/DVD etc.
Aborda os circuitos lgicos existentes em todos os processadores, como portas AND, OR e XOR, e estuda as bases numricas e
os tipos de memria mais utilizados em computao.
Divide-se em trs partes, sendo a primeira referente arquitetura dos computadores, a segunda sobre os perifricos e a terceira
relacionada ao sistema operacional e softwares mais comuns.
Os captulos possuem diversas questes para fixao do aprendizado.
Estudo Dirigido de Informtica Bsica

Autores: Andr Luiz N. G. Manzano e Maria Izabel N. G. Manzano
A stima edio do livro foi revisada e ampliada, pois h grande preocupao de trazer informaes mais atualizadas frente s
novas tecnologias, alm de muitas novidades.
A obra manteve sua estrutura original no que tange histria e sua cronologia, preservando a linguagem simples e acessvel aos
novos usurios da informtica. Apresenta informaes riqussimas sobre novos recursos computacionais, como, por exemplo, as
tecnologias Bluetooth e Wireless, possibilidades novas dentre muitos recursos oferecidos, alm de contemplar um assunto muito
importante, a segurana de dados, seja em uma simples pgina web ou em um inocente bate-papo em salas de chat ou, ainda,
em mensagens instantneas.
Office & Processamento de Dados

Banco de Dados - Projeto e Implementação PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Banco de Dados - Projeto e Implementação PDF

Caricato da

Copyright:

Formati disponibili

Machado, Felipe Nery Rodrigues

Projeto e implementao de banco de dados / Felipe Nery Rodrigues Machado. -- 3. ed. --

1. Banco de dados I. Ttulo.

ndice para catlogo sistemtico:

Copyright 2004 da Editora rica Ltda.

Coordenao Editorial: Rosana Arruda da Silva

Seu cadastro muito importante para ns

Contato com o editorial: editorial@editoraerica.com.br

Editora rica Ltda. | Uma Empresa do Grupo Saraiva

2 Banco de Dados - Projeto e Implementao

Produziro as montanhas frutos de paz ao

Felipe Nery Rodrigues Machado

4 Banco de Dados - Projeto e Implementao

Captulo 1 - O Que Projeto de Banco de Dados................................................................................. 13

Captulo 2 - Abstrao em Modelagem de Dados ................................................................................ 27

Captulo 3 - Bancos de Dados Relacionais ........................................................................................... 39

Captulo 5 - Extenses do Modelo Entidade-Relacionamento .......................................................... 102

Captulo 6 - Agregao: Uma Extenso Especial ............................................................................... 122

Captulo 7 - Tratamento de Interpretaes de Dados......................................................................... 159

6 Banco de Dados - Projeto e Implementao

Captulo 8 - Normalizao ..................................................................................................................... 177

Captulo 9 - Um Estudo de Caso .......................................................................................................... 204

Captulo 10 - Hierarquias ...................................................................................................................... 215

Captulo 11 - Modelo Fsico .................................................................................................................. 218

Captulo 12 - Mapeamento de Objetos ER .......................................................................................... 231

Captulo 13 - lgebra Relacional ......................................................................................................... 242

Captulo 14 - SQL ................................................................................................................................... 306

8 Banco de Dados - Projeto e Implementao

Captulo 15 - Modelagem de Dados e Mtodos geis ........................................................................ 386

Bibliografia ............................................................................................................................................. 391

ndice Remissivo ................................................................................................................................... 393

10 Banco de Dados - Projeto e Implementao

A Modelagem de Dados e o Projeto de Banco de Dados tm sofrido significantes evolu-

12 Banco de Dados - Projeto e Implementao

O Que Projeto de Banco de Dados 13

14 Banco de Dados - Projeto e Implementao

O Que Projeto de Banco de Dados 15

16 Banco de Dados - Projeto e Implementao

Em seguida apresentamos uma descrio dos principais macroelementos construdos

O Que Projeto de Banco de Dados 17

18 Banco de Dados - Projeto e Implementao

O resultado de um modelo conceitual um esquema grfico que representa a realidade

O Que Projeto de Banco de Dados 19

O modelo lgico descreve em formato as estruturas que estaro no banco de dados de

20 Banco de Dados - Projeto e Implementao

CREATE UNIQUE INDEX XPKEmpregado ON Empregado

O Projeto de Banco de Dados

O Que Projeto de Banco de Dados 21

22 Banco de Dados - Projeto e Implementao

O Modelo Entidade-Relacionamento (ER)

O Que Projeto de Banco de Dados 23

A Implementao de Banco de Dados

24 Banco de Dados - Projeto e Implementao

O Que Projeto de Banco de Dados 25

26 Banco de Dados - Projeto e Implementao

Abstrao em Modelagem de Dados 27

Observe que este um processo incondicional que realizamos mentalmente. No est

28 Banco de Dados - Projeto e Implementao

Abstrao em Modelagem de Dados 29

Para a classe lquidos:

Agora vamos entender graficamente a generalizao.

30 Banco de Dados - Projeto e Implementao