Banco de Dados

MDULO:
BANCO DE DADOS
AUTOR:
CARLOS ALBERTO VALENTE ANDRADE
Copyright 2007, ESAB Escola Superior Aberta do Brasil
Mdulo de: Banco de Dados;

Autor: Carlos Alberto Valente Andrade
Primeira edio: 2007
Todos os direitos desta edio reservados

ESAB ESCOLA SUPERIOR ABERTA DO BRASIL LTDA
http://www.esab.edu.br
Av. Santa Leopoldina, n 840/07
Bairro Itaparica Vila Velha, ES
CEP: 29102-040
PRESENTAO
Este mdulo ir apresentar conceitos fundamentais de Sistemas de Bancos de Dados dos

principais fabricantes de software.
Nesses conceitos est includo o Gerenciamento de um Banco de Dados, bem como
aspectos de projeto, linguagens e implementao de um Sistema de Banco de Dados, alm
de explicar os conceitos bsicos, fornecer uma viso geral dos recursos de um Banco de
Dados e como se inter-relaciona com programas aplicativos, sistema operacional e usurios.
Discutiremos os vrios modelos de Banco de Dados, dando nfase ao modelo EntidadeRelacionamento, e focando na linguagem relacional orientada ao usurio, largamente
utilizada, conhecida como SQL.
BJETIVO
Capacitar o leitor a lidar com um Sistema de Gerenciamento de Banco de Dados (SGBD)

aprendendo conceitos e tcnicas para a administrao eficiente destes dados.
MENTA
Conceituao e anlise de caractersticas prprias de Sistemas de Gerncia de Banco de

Dados multiusurio. Gerenciamento de transaes, controle de concorrncia, recuperao de
falhas, segurana e integridade de dados. Comparao de abordagens no-convencionais
para Bancos de Dados; integrao de Bancos de Dados e Internet. Estudo dos principais
comandos da Linguagem de Consulta Estruturada SQL.
OBRE O AUTOR
Carlos Alberto Valente Andrade:
Professor e Consultor de Tecnologia de Informao
Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em

Anlise de Sistemas (Mackenzie), Administrao (Luzwell-SP), e Reengenharia (FGVSP). Graduado/Licenciado em Matemtica.
Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB

(Ensino a Distncia). Autor de livros em Conectividade Empresarial. Prmio em ELearning no Ensino Superior (ABED/Blackboard).
Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor,

etc. Viagens internacionais: EUA, Frana, Inglaterra, Itlia, Portugal, Espanha, etc.
UMRIO
UNIDADE 1 .............................................................................................................................. 9
O que um Banco de Dados? e o que vem a ser um SGBD? .............................................9
UNIDADE 2 ............................................................................................................................ 14
Principais Caractersticas de um SGBD ..............................................................................14
UNIDADE 3 ............................................................................................................................ 19
Conceitos e Arquiteturas de um SGBD ...............................................................................19
UNIDADE 4 ............................................................................................................................ 23
Caractersticas das Principais Arquiteturas de um SGBD ................................................... 23
UNIDADE 5 ............................................................................................................................ 28
Nveis de Abstrao dos Dados na Arquitetura de um SGBD .............................................28
UNIDADE 6 ............................................................................................................................ 32
Quem so os usurios de um SGBD? ................................................................................ 32
UNIDADE 7 ............................................................................................................................ 36
Modelagem de Dados I: Modelos Lgicos baseado em Registros......................................36
UNIDADE 8 ............................................................................................................................ 42
Modelagem de Dados II: Modelos Lgicos baseado em Objetos .......................................42
UNIDADE 9 ............................................................................................................................ 47
Definio de Entidade, Atributo e Tupla ..............................................................................47
UNIDADE 10 .......................................................................................................................... 53
Definio de Chave Primria Simples, Composta, nica e Estrangeira ............................. 53
UNIDADE 11 .......................................................................................................................... 56
Relacionamentos entre Bancos de Dados ..........................................................................56
UNIDADE 12 .......................................................................................................................... 60
Relacionamentos Especiais com Mltiplas Entidades......................................................... 60
UNIDADE 13 .......................................................................................................................... 62
Integridade dos Dados ........................................................................................................62
UNIDADE 14 .......................................................................................................................... 65
Normalizao A Primeira, Segunda e a Terceira Forma Normal .....................................65
UNIDADE 15 .......................................................................................................................... 72
Fundamentos de Armazenamento e Manipulao de Dados..............................................72
UNIDADE 16 .......................................................................................................................... 78
A Linguagem SQL ...............................................................................................................78
UNIDADE 17 .......................................................................................................................... 81
Comando para Criao de um Banco de Dados .................................................................81
UNIDADE 18 .......................................................................................................................... 86
Comando SELECT para Consulta de Tabelas ....................................................................86
UNIDADE 19 .......................................................................................................................... 90
Clusula e Operadores usados no Comando SELECT....................................................... 90
UNIDADE 20 .......................................................................................................................... 97
Funes Agregadas e a Clusula HAVING.........................................................................97
UNIDADE 21 ........................................................................................................................ 101
Relacionamentos, sub-consulta e unio............................................................................ 101
UNIDADE 22 ........................................................................................................................ 106
Inseres, Alteraes e Excluses em Tabelas ................................................................ 106
UNIDADE 23 ........................................................................................................................ 110
Relatrios comando REPORT ....................................................................................... 110
UNIDADE 24 ........................................................................................................................ 114
Privilgios de Acesso GRANT e REVOKE ..................................................................... 114
UNIDADE 25 ........................................................................................................................ 119
Trabalhando com ndices .................................................................................................. 119
UNIDADE 26 ........................................................................................................................ 123
Resumo dos Comandos SQL ............................................................................................ 123
UNIDADE 27 ........................................................................................................................ 128
Otimizar Consultas SQL .................................................................................................... 128
UNIDADE 28 ........................................................................................................................ 132
Comando CREATE TRIGGER para criao de um gatilho ............................................... 132
UNIDADE 29 ........................................................................................................................ 136
Protegendo seu Servidor de Banco de Dados .................................................................. 136
UNIDADE 30 ........................................................................................................................ 142
Caractersticas dos vrios SGBDs de uso Comercial ....................................................... 142
GLOSSRIO ........................................................................................................................ 148

BIBLIOGRAFIA .................................................................................................................... 149
NIDADE
Objetivo: Conceituar Banco de Dados, indicando os seus principais componentes bsicos.

Mostrar a importancia e o significado de um SGBD dentro de um Sistema de Banco de
Dados
O que um Banco de Dados? E o que vem a ser um SGBD?

Os Bancos de Dados esto atualmente em situaes corriqueiras do nosso cotidiano.
Podem-se citar vrios exemplos, desde quando anotamos os dados em nossos celulares do
telefone e endereo de um amigo, at a incluso de nossos dados cadastrais, atravs da
Web, num Banco de Dados de uma loja de Comrcio Eletrnico.
Podemos dizer que, assim que nascemos, j somos parte de um Banco de Dados!! Na
maternidade nos cadastram em Banco de Dados, no cartrio para tirar a Certido de
Nascimento, ou mais tarde quando passamos a ter a nossa identidade - o RG, ou mesmo
junto receita federal com o CPF e assim por diante.
Conceito de banco de dados

Pode-se definir de forma bem simples, que Banco de Dados um conjunto de registros
manipulveis, de mesma natureza, inseridas em um mesmo local, obedecendo a um padro
de armazenamento.
Vimos anteriormente alguns exemplos de Banco de Dados, no entanto, para esse material
ns vamos nos dedicar especialmente tcnica de informatizar estas informaes de forma
que seja possvel dar manuteno nestes dados. Algumas dessas tarefas sero como incluir,
alterar, consultar ou excluir, com o objetivo de manter estas informaes organizadas e
disponveis. E outro ponto que quando solicitados esses dados que sejam com rapidez e
confiabilidade.
Portanto, em outras palavras, podemos afirmar que um Sistema de Banco de Dados

basicamente um sistema computadorizado de manuteno de registros, cuja finalidade
armazenar informaes e permitir que os usurios busquem e atualizem essas informaes
quando solicitadas.
Sistemas multiusurios e monousurios

Os sistemas de Bancos de Dados esto disponveis em mquinas desde pequenos
computadores de mo conhecidos como palmtops (genericamente como handhelds), em
clusters de computadores (aglomerado de processadores), ou mesmo em mainframes
(computadores de grande porte).
Figura 1.1 - Representao simplificada de um sistema de Banco de Dados
Quando vrios usurios acessam o mesmo Banco de Dados, o que muito comum hoje em
dia, denominamos esses sistemas de multiusurios. Enquanto que em mquinas menores,
ou em pequenos sistemas, tendem a ser monousurios. Interessante que mesmo em
sistemas multiusurios o objetivo que cada usurio se comporte como se tivesse
10
trabalhando como num sistema monousurio, de forma que os problemas internos ao

sistema sejam invisveis para o usurio final.
A figura 1.1 uma imagem simplificada de um Sistema de Banco de Dados. De uma forma
geral, um Sistema desses envolve quatro componentes principais: dados, hardware, software
e usurios. Vejamos agora cada um destes componentes com mais riqueza de detalhes.
Dados
De modo geral, num Sistema Multiusurio os dados so integrados e compartilhados:
Integrados: no sentido de ter uma unificao de vrios arquivos para eliminar qualquer
redundncia (repetio da mesma informao ou dado) parcial ou total entre estes arquivos.
Por exemplo, um arquivo de FUNCIONRIOS com vrios campos sobre os funcionrios
como nome, endereo, departamento, salrio e outros dados. E um arquivo de CURSOS
com todas as informaes sobre o treinamento que os funcionrios tiveram, ou esto tendo,
na empresa. No seria bom senso incluir novamente todos os dados dos funcionrios no
arquivo CURSOS, pois ficaria redundante ao arquivo FUNCIONRIOS que j possui esses
dados. Portanto, bastaria integrar estes dois arquivos e eliminar qualquer redundncia entre
eles.
Compartilhados:
quando
diferentes
usurios
acessam
os
mesmos
dados,
e provavelmente ao mesmo tempo (acesso concorrente). Por exemplo, no arquivo citado

anteriormente, o de FUNCIONRIOS, ele poderia ser compartilhado tanto entre os usurios
do Departamento Pessoal, como simultaneamente pelos usurios do Departamento de
Treinamento.
Hardware
11
Os componentes de hardware usados num sistema de Banco de Dados consistem

basicamente num volume de armazenamento secundrio, normalmente em discos
magnticos. Esses discos rgidos so usados para manter por longo tempo os dados
armazenados. Normalmente esto associados a um processador de alta performance e
memria principal em grande quantidade. Eles que daro suporte a execuo do software
de Sistema de Banco de Dados.
Software
Entre os dados fisicamente armazenados no hardware, e os usurios do sistema, existe o
software conhecido como Gerenciador de Banco de Dados. Tambm denominado de
Servidor de Banco de Dados, ou ainda mais frequentemente chamado de Sistema de
Gerenciamento de Bancos de Dados (SGBD) - a sigla em ingls DBMS.
Um SGBD o conjunto de programas de computador (software) responsvel pelo
gerenciamento de uma base de dados. Todos os acessos ao Banco de Dados so tratados
pelo SGBD. Porm, apesar de ser o componente de software mais importante de todo o
sistema, no o nico a ser utilizado. Componentes como utilitrios, ferramentas de
desenvolvimento, geradores de relatrios, gerenciador de transaes e outros, auxiliam
tambm em um SGBD.
Podemos citar como principais exemplos de SGBD: Oracle, SQL-Server (Microsoft), e o DB2
(IBM). E alguns exemplos de SGBD que so software livre: MySQL, PostgreSQL e SQLite
(veja detalhes dos principais SGBDs na Unidade 30).
Usurios
Existem vrias classes de usurios em um Sistema de Banco de Dados. Temos o
Administrador de Banco de Dados (DBA), e o Administrador de Dados (DA), que como o
12
prprio nome j diz, administram o Banco de Dados para que tenha a melhor performance
possvel, mantendo a integridade dos dados, alm de outras atribuies.
Outros tipos de usurios so os programadores de aplicao, responsveis pela escrita de
programas de aplicaes de Banco de Dados em alguma linguagem de programao, como
COBOL, C++, JAVA entre outras linguagens de alto nvel.
E temos os usurios finais que acessam o Banco de Dados usando uma linguagem prpria
para isso, o exemplo tpico o SQL (que veremos com maiores detalhes em outras
unidades). Ou ento, aqueles com conhecimento mais superficial fazem uso de interfaces
acionado por comandos, ou seja, programas com formulrios e menus que facilitam o
trabalho do usurio final.
O nosso Glossrio ser super dinmico!! Ou seja, toda vez que voc tiver dvida
de alguma expresso tcnica, ou algum termo desconhecido, dever consultar o
WIKIPDIA (http://pt.wikipedia.org/). Se tiver condies de ajudar nesse projeto,
pois essa enciclopdia on-line criada com as contribuies de todos os
internautas, esteja vontade e enriquea essa Biblioteca Digital. Se mesmo
assim, voc ainda ficar com dvidas, ou no conseguir achar o que voc queria,
ento dirija para o nosso FRUM, intitulado GLOSSRIO, para que possamos
ajud-lo discutindo com o grupo.
Pesquise no Wikipdia sobre Banco de Dados e SGBD, e responda, por escrito,

as seguintes perguntas:
Quais so os componentes bsicos de um Sistema de Banco de Dados?
O que um SGBD?
Mencione alguns exemplos de SGBDs
13
NIDADE
Objetivo: Apontar e detalhar as principais vantagens de um Sistema de Gerenciamento de

Banco de Dados.
Principais Caractersticas de um SGBD
A tecnologia aplicada aos mtodos de armazenamento de informaes vem crescendo e
gerando um impacto cada vez maior no uso de Banco de Dados. Um Banco de Dados ,
antes de tudo, uma coleo coerente de dados armazenados logicamente, cuja finalidade
organizar estas informaes visando otimizao dos sistemas, facilitando a entrada,
alteraes, processamento e consulta de dados.
Para criao e manuteno de um Banco de Dados informatizado utiliza-se um Sistema
Gerenciador de Banco de Dados (SGBD). O conjunto formado por um Banco de Dados, o
SGBD e mais as aplicaes que o manipulam, chamado de Sistema de Banco de Dados,
conforme representado pela figura 2.1.
Figura 2.1 - Sistema de Banco de Dados
O acesso s informaes em sistemas de processamento de dados que no utilizam SGBDs

feito pelo acesso sequencial a arquivos (um ou mais). Nesse caso, cabe ao desenvolvedor,
criar mecanismos de recuperao da informao. No entanto, com a utilizao de um SGBD
o acesso diferenciado. As informaes so solicitadas ao Gerenciador do Banco de Dados
14
e devolvidas por ele mesmo. O gerenciador que assume toda a responsabilidade de

recuperar as informaes desejadas.
As principais caractersticas ou vantagens de um SGBD so:
Integridade;
Consistncia ou Compartilhamento de Dados;
Segurana ou Restrio de Acesso;
Restaurao ou Tolerncia a Falhas;
No Redundncia ou Controle de Redundncia;
Padronizao dos Dados.
Integridade
Consiste em assegurar que os dados no Banco de Dados estejam corretos, sempre
permitindo que um cdigo ou chave em uma tabela tenha correspondncia adequada em
outra tabela. Por exemplo, um cdigo de uma determinada disciplina na tabela Histrico
Escolar com a devida descrio na tabela Disciplina. Caso contrrio, por exemplo, um
empregado poderia ser mostrado como pertencendo a um departamento que no existe
mais.
Consistncia ou compartilhamento de dados

Por armazenar os dados em um nico local, e compartilhando-os para vrios sistemas, os
usurios acabam utilizando a informao de forma muito mais confivel. Por outro lado, em
sistemas inconsistentes ocorrem que um mesmo campo tem valores distintos pelos vrios
programas. Por exemplo, o estado civil de uma pessoa solteiro em um sistema e casado
em outro.
15
Isso ocorre com certa incidncia em Sistemas sem SGBD, pois os usurios atualizam o
campo em um sistema e no o fazem em outro. Quando o dado armazenado em um nico
local e compartilhado pelos sistemas, esse problema eliminado. Essas inconsistncias
tambm podem ser controladas por meio de regras estabelecidas no prprio Banco de
Dados.
Segurana ou restrio de acesso

Define para cada usurio o nvel de acesso tabela e/ou ao campo (somente leitura, leitura e
gravao ou sem acesso). Esse recurso impede que pessoas no autorizadas utilizem ou
atualizem uma
determinada informao. Por exemplo, num sistema bancrio, o
departamento pessoal necessita apenas do Banco de Dados as informaes sobre os

diversos empregados da empresa. Eles no necessitam, at por questo de segurana, ter
acesso s informaes sobre contas dos clientes do banco.
Restaurao ou tolerncia a falhas

Esta caracterstica tambm mencionada como tolerncia a falhas implica na caracterstica
que o SGBD deve apresentar como facilidade para recuperar falhas de hardware e software.
A estratgia do SGBD para realizar isso por meio da existncia de arquivos de backup
(cpia de segurana) ou de outros recursos automticos.
No redundncia ou controle de redundncia

A redundncia consiste no armazenamento de uma mesma informao em locais diferentes,
provocando inconsistncias. Em um Banco de Dados as informaes se encontram
armazenadas em um nico local e no deve existir duplicao descontrolada dos dados. Os
dados, que eventualmente so comuns a mais de um sistema, so compartilhados por eles,
permitindo o acesso a uma nica informao consultada pelos vrios sistemas. Deve-se
16
observar apenas o processo de atualizao concorrente, para no gerar erros de

processamento (usurios atualizando simultaneamente o mesmo campo)
s vezes, h motivos comerciais ou tcnicos plausveis para manter cpias distintas dos
mesmos dados. Porm toda redundncia deve ser cuidadosamente controlada; isto , o
SGBD deve estar ciente dela (caso exista) e deve garantir que qualquer mudana feita em
uma das duas entradas tambm seja aplicada de forma automtica a outra entrada. Esse
processo conhecido como propagao de atualizaes.
Padronizao dos dados

Permite que as informaes da base de dados sejam padronizadas segundo um determinado
formato de armazenamento (padronizao de tabela, contedo de campos, etc.), e o nome
de variveis, segundo critrios preestabelecidos pelo analista. A padronizao da
representao dos dados particularmente desejvel quando ocorre a migrao de dados
entre sistemas.
Por exemplo: para o campo sexo somente ser permitido como padro o armazenamento
dos contedos M ou F.
As desvantagens de um SGBD
Em algumas situaes, cada vez mais raras, o uso de um SGBD pode representar uma
carga desnecessria aos custos quando comparado ao processamento tradicional de
arquivos como, por exemplo:
Alto investimento inicial na compra de software e hardware adicionais;
Generalidade que um SGBD fornece na definio e processamento de dados;
Sobrecarga na proviso de controle de segurana, controle de concorrncia,

recuperao e integrao de funes.
17
Tambm podemos considerar desvantagens de um SGBD quando os projetistas do Banco

de Dados ou os administradores de Banco de Dados no elaborem os projetos corretamente
ou se as aplicaes no so implementadas de forma apropriada.
http://www.plugmasters.com.br/sys/materias/108/1/SGBD---Sistema-Gerenciadorde-Banco-de-Dados
Discusso sobre qual o melhor Banco de Dados?
http://www.jack.eti.br/www/?p=38
Nesta unidade vimos as principais caractersticas de um SGBD, porm

interessante complementar seu estudo procurando saber quais so as vantagens
e desvantagens de usar um SGBD free, ou seja, livres do pagamento da licena
para uso do software, os mais conhecidos so: MySQL, PostgreSQL e SQLite. Em
que casos melhor um sistema proprietrio do que pagar a licena?
18
NIDADE
Objetivo: Indicar os principais aspectos das arquiteturas de um Sistema de Gerenciamento

de Banco de Dados, abordando a arquitetura centralizada e a arquitetura cliente-servidor.
Conceitos e Arquiteturas de um SGBD

Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficincia e a
eficcia dos sistemas informatizados desenvolvidos. Como se atende os usurios nos mais
variados domnios de aplicao (automao de escritrios, sistemas de apoio a decises,
controle de reserva de recursos, controle e planejamento de produo, alocao e estoque
de recursos, etc.), os aspectos a serem observados so:
Os projetos Lgico e Funcional do Banco de Dados devem ser capazes de prever o volume
de informaes armazenadas a curto, mdio e longo prazo. Os projetos devem ter uma
grande capacidade de adaptao;
Deve-se ter generalidade e alto grau de abstrao de dados. Isso possibilitando ter
confiabilidade e eficincia no armazenamento dos dados e permitindo a utilizao de
diferentes tipos de SGBDs atravs de linguagens de consultas padronizadas;
Projeto de uma interface gil e com uma "rampa ascendente" para propiciar aprendizado
suave ao usurio, no intuito de minimizar o esforo cognitivo;
Implementao desejvel de um projeto de interface compatvel com mltiplas plataformas
(UNIX, Windows NT, Windows Workgroups, etc);
Independncia de implementao da interface em relao aos SGBDs que daro condies
s operaes de armazenamento de informaes (ORACLE, SYSBASE, INFORMIX,
PADRO XBASE, etc).
Converso e mapeamento da diferena semntica entre os paradigmas utilizados no
desenvolvimento de interfaces (imperativo, Orientado a Objeto, Orientado a evento),
19
servidores de dados (relacional) e programao dos aplicativos (Imperativo, Orientado a

Objetos).
Viso Geral das Arquiteturas

As primeiras arquiteturas usavam mainframes para executar o processamento principal e de
todas as funes do sistema, incluindo os programas aplicativos, programas de interface com
o usurio, bem como a funcionalidade dos SGBDs.
Esta a razo pela qual a maioria dos usurios da poca, que faziam acesso aos sistemas
via terminais, no possuam poder de processamento e sim a capacidade de visualizao.
Todos os processamentos eram feitos remotamente. Apenas as informaes a serem
visualizadas e controles eram enviadas do mainframe para os terminais de visualizao,
atravs de redes de comunicao. Com os preos do hardware decrescendo, os terminais
foram substitudos por computadores pessoais (PC) e estaes de trabalho.
No comeo, os SGBDs usavam esses PCs da mesma maneira que usavam os terminais, o
SGBD era centralizado e toda sua funcionalidade, execuo de programas aplicativos e
processamento da interface do usurio eram executados em apenas uma mquina.
Gradualmente, os SGBDs comearam a explorar o poder de processamento do lado do
usurio, o que levou arquitetura cliente-servidor.
Figura 3.1 Exemplo de Arquitetura Cliente-Servidor Simples
20
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computao. A ideia

de definir servidores especializados, tais como servidor de arquivos, que mantm os
arquivos de mquinas clientes, ou mesmo servidores de impresso que podem estar
conectados a vrias impressoras. Assim, quando se desejar imprimir algo, todas as
requisies de impresso so enviadas a este servidor. As mquinas clientes disponibilizam
para o usurio as interfaces apropriadas para utilizar esses servidores. Esta arquitetura
muito popular pelas seguintes razes:
A facilidade de implementao, com a clara separao das funcionalidades dos servidores.
Os servidores so mais inteligentemente utilizados porque as tarefas simples so delegadas
s mquinas clientes mais baratas.
O usurio executa uma interface grfica mais simples, ao invs de usar a interface do
servidor que mais complexa.
Diferentes tcnicas foram propostas para se implementar essa arquitetura, sendo a mais
adotada foi a incluso da funcionalidade de um SGBD centralizado no servidor. As consultas
e a funcionalidade transacional tambm ficam no servidor, sendo que este chamado de
servidor de consulta ou servidor de transao.
assim que um servidor SQL fornecido aos clientes. Cada cliente formula suas consultas
SQL, prov a interface do usurio e as funes de interface usando a mesma linguagem de
programao. Comumente o servidor SQL tambm chamado de back-end e o cliente de
front-end. Como SQL prov uma linguagem padro para o SGBDs, esta criou o ponto de
diviso lgica entre o cliente e o servidor.
21
Figura 3.2 Exemplo de Arquitetura Cliente-Servidor Bi-Nvel
http://www.sebraepb.com.br:8080/bte/download/informtica/190_1_arquivo
_bdados.pdf
http://pt.wikipedia.org/wiki/Servidor
Responda por escrito as seguintes perguntas:

O que ajudou muitas empresas a migrarem de uma arquitetura centralizada
(Mainframe) para uma arquitetura baseada em computadores pessoais (PC)?
Cite algumas razes que fez a arquitetura cliente-servidor ganhar popularidade?
Numa arquitetura cliente-servidor quais so algumas das funcionalidades do
servidor e do cliente?
Que tipos diferentes da arquitetura cliente-servidor existem?
22
NIDADE
Objetivo: Mostrar as principais arquiteturas de um Sistema de Gerenciamento de Banco de

Dados e o seu desenvolvimento.
Caractersticas das Principais Arquiteturas de um SGBD

Atualmente, existem vrias tendncias para arquitetura de Banco de Dados, nas mais
diversas direes. Faremos aqui um resumo das principais arquiteturas do ponto de vista
histrico.
Primeira Arquitetura: Plataformas Centralizadas (uso de Mainframes)

Na
arquitetura
centralizada,
existe
um
computador
com
grande
capacidade
de
processamento, o qual o hospedeiro do SGBD e emuladores para os vrios aplicativos.

Esta arquitetura tem como principal vantagem a de permitir que muitos usurios manipulem
grande volume de dados. Sua principal desvantagem est no seu alto custo, pois exige
ambiente especial para mainframes e solues centralizadas. Suas principais caractersticas
so:
O processamento principal e de todas as funes do sistema (aplicativos, interface e SGBD)
so executados no mainframe.
Os usurios interagiam com o sistema, via terminais, sem poder de processamento,
conectados ao mainframe por redes de comunicao.
Com o barateamento do hardware, os terminais foram sendo trocados por estaes de
trabalho e naturalmente a tecnologia de Banco de Dados comeou a aproveitar esse
potencial de processamento no lado do usurio.
23
Segunda Arquitetura: Cliente-Servidor

Na arquitetura Cliente-Servidor, o cliente (front-end) executa as tarefas do aplicativo, ou seja,
fornece a interface do usurio (tela, e processamento de entrada e sada). O servidor (backend) executa as consultas no SGBD e retorna os resultados ao cliente. Apesar de ser uma
arquitetura bastante popular, so necessrias solues sofisticadas de software que
possibilitem: o tratamento de transaes, as confirmaes de transaes (commits), desfazer
transaes (rollbacks), linguagens de consultas (stored procedures) e gatilhos (triggers). A
principal vantagem desta arquitetura a diviso do processamento entre dois sistemas, o
que reduz o trfego de dados na rede. So caractersticas dessa arquitetura:
Diviso das tarefas de processamento criando servidores especializados como os servidores
de arquivos.
As mquinas clientes disponibilizavam as interfaces para os usurios, de forma a capacit-lo
ao uso de servidores. Tambm tinham autonomia para executar aplicaes locais.
Um SGBD centralizado implantado no servidor, permitindo que as consultas (servidor SQL)
e funcionalidades transacionais sejam executadas nesse servidor.
No lado do cliente possvel personalizar as consultas e desenvolver programas aplicativos
especficos.
Terceira Arquitetura: Sistemas em Computadores Pessoais

Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus
processamentos sozinhos. No comeo, esse processamento era bastante limitado, porm,
com a evoluo do hardware, os PCs foram ganhando grande capacidade de
processamento. Eles utilizam o padro Xbase e quando se trata de SGBDs, funcionam como
hospedeiros e terminais. Desta maneira, possuem um nico aplicativo a ser executado na
mquina. Suas caractersticas so:
24
Trabalham no sistema stand-alone, executando sozinhos todas as funes necessrias para

o funcionamento do SGBD.
Principal vantagem desta arquitetura a simplicidade.
Aplicaes tpicas so de baixa e mdia complexidade.
Quarta Arquitetura: Distribuda (N camadas)

Nesta arquitetura, a informao est distribuda em diversos servidores. Como exemplo,
observe na figura 4.1 abaixo. Cada servidor atua como no sistema cliente-servidor, porm as
consultas oriundas dos aplicativos so feitas para qualquer servidor indistintamente. Caso a
informao solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se
de obter a informao necessria, de maneira transparente para o aplicativo.
Exemplos tpicos so as bases de dados corporativas, em que o volume de informao
muito grande e, por isso, deve ser distribudo em diversos servidores. A caracterstica bsica
a existncia de diversos programas aplicativos consultando a rede para acessar os dados
necessrios, porm, sem o conhecimento explcito de quais servidores dispem desses
dados. Vejamos suas principais caractersticas:
Os dados e o processamento so distribudos por diversos servidores (ou hosts).
Cada host pode atuar como um servidor de um sistema cliente-servidor, e como

cliente.
Muito usado em bases de dados corporativas, ou em aplicaes sofisticadas, onde o

volume de informaes seja muito grande.
Desvantagem: aumento da complexidade de gerenciamento.
25
Figura 4.1 Arquitetura Distribuda N Camadas
Quinta Arquitetura: Paralela

Combinam tcnicas de gerncia de dados e processamento paralelo para aumentar
desempenho e confiabilidade. A arquitetura paralela vem tornando-se uma tendncia em
funo da demanda sempre crescente por poder computacional. Os sistemas que oferecem
essa capacidade de processamento, ainda tm um custo muito elevado ou so difceis de
programar. O estudo de arquiteturas paralelas contribui para o entendimento e para a busca
de alternativas para as outras arquiteturas. So suas caractersticas:
O processamento do sistema utiliza as tcnicas de paralelismo.
Computadores multiprocessados, ou vrios computadores, so utilizados para o

processamento paralelo de uma nica transao.
A paralelizao do processamento interno de consultas resulta numa diminuio do

tempo de resposta.
A paralelizao do processamento de transaes resulta num aumento da capacidade

do sistema (throughput).
Desvantagem: custo e complexidade alta de gerenciamento.
26
Figura 4.2 Arquitetura de SGBDs Paralelos
http://pt.wikipedia.org/wiki/Banco_de_dados_distribu%C3%ADdos
http://pt.wikipedia.org/wiki/N_camadas
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp
http://www.inf.puc-rio.br/~casanova/LivroCasanova/ncap1.pdf
http://www.inf.puc-rio.br/~casanova/LivroCasanova/ncap2.pdf
Visite os links referenciados anteriormente e responda as seguintes perguntas:

Quais so alguns exemplos de arquiteturas de SGDBs?
Qual tipo de arquitetura a mais utilizada nas grandes empresas?
27
NIDADE
Objetivo: Detalhar os nveis de abstrao dos dados na Arquitetura de um Sistema de

Gerenciamento de Banco de Dados.
Nveis de Abstrao dos Dados na Arquitetura de um SGBD

Como j vimos o SGBD composto de uma coleo de arquivos inter-relacionados e um
conjunto de programas que permitem aos usurios fazerem o acesso e a modificao desses
arquivos. O grande objetivo desse sistema prover aos usurios uma viso abstrata dos
dados. Isto , o sistema omitir certos detalhes de como os dados so armazenados e
mantidos, mantendo total transparncia para os usurios.
Este conceito tem direcionado o projeto de estruturas de dados complexas para a
representao desses dados. Existem diversos nveis de abstrao que simplificam a
interao do usurio com o sistema: Nvel Fsico, Nvel Conceitual e o Nvel de Vises. O
inter-relacionamento entre estes trs nveis de abstrao ilustrado na Figura 3.1:
Figura 3.1 - Os trs nveis de abstrao de dados
28
Nvel Fsico, ou Nvel Interno (tambm conhecido como nvel de armazenamento)

O nvel mais baixo de abstrao descreve como os dados esto realmente armazenados. No
nvel fsico, complexas estruturas de dados de baixo nvel so descritas em detalhes. Este
nvel o mais prximo do meio de armazenamento fsico, ou seja, aquele que se ocupa do
modo como os dados so fisicamente armazenados no sistema, tais como: tamanho de
campos, ndices, como os campos armazenados esto representados, em que sequncia
fsica os registros sero armazenados, e assim por diante.
Nvel Conceitual, ou Nvel Lgico (tambm conhecido como nvel lgico de

comunidade)
Este nvel de abstrao descreve quais dados esto armazenados de fato no Banco de
Dados e as relaes que existem entre eles. Aqui, o Banco de Dados descrito em termos
de um pequeno nmero de estruturas relativamente simples. Embora a implementao de
estruturas simples no nvel conceitual possa envolver complexas estruturas de nvel fsico, o
usurio do nvel conceitual no precisa preocupar-se com isso.
O nvel conceitual de abstrao usado pelos administradores de Banco de Dados, para
decidir quais informaes devem ser mantidas no Banco de Dados. Este nvel est
preocupado com a percepo da comunidade de usurios, ou seja, uma viso do contedo
total do Banco de Dados.
Nvel de Vises, ou Nvel Externo (tambm conhecido como nvel lgico do usurio)
O mais alto nvel de abstrao descreve apenas uma viso limitada do Banco de Dados.
Muitos usurios do SGBD no esto interessados em todos os dados, em vez disso,
precisam apenas uma parte do Banco de Dados.
O nvel de abstrao das vises dos dados definido para simplificar esta interao com o
sistema, que pode fornecer muitas vises para o mesmo Banco de Dados. Apesar do uso de
29
estruturas mais simples do que no nvel conceitual, alguma complexidade perdura nesse
nvel.
Concluses Gerais dos Nveis de Abstrao dos Dados

Observe que o Nvel de Vises e o Conceitual so nveis de modelo, enquanto que o Nvel
Fsico um nvel de implementao. Em outras palavras, o Nvel de Vises e o Conceitual
so definidos em termos de construes voltadas para o usurio, como registros e campos,
enquanto o Nvel Fsico definido em termos de construes voltadas para a mquina, como
bits e bytes.
Enquanto o Nvel de Vises se preocupa com as percepes dos usurios individuais, o
Nvel Conceitual est preocupado com a percepo da comunidade dos usurios. A maior
parte dos usurios no est interessada no Banco de Dados inteiro, mas somente em
alguma parte restrita dele.
Assim, haver muitas vises externas distintas, cada qual consistindo em uma
representao mais ou menos abstrata das partes de um Banco de Dados.
http://www.criarweb.com/artigos/arquitetura-bancos-de-dados.html
http://www.linhadecodigo.com.br/Artigo.aspx?id=332
30
Com base do link abaixo da UFRJ, que contm uma apresentao sobre
Arquitetura de Banco de Dados, realize um pequeno resumo desse material:
http://www.cos.ufrj.br/~marta/ArchitectureP.pdf
31
NIDADE
Objetivo: Descrever a formao e as caractersticas de cada usurio que trabalha com SGBD
Quem so os usurios de um SGBD?

Para um sistema de Banco de Dados aplicado numa mdia e complexa atividade, existe um
grande nmero de pessoas envolvidas, desde o projeto at a manuteno propriamente dito.
Entre estes, podemos destacar os seguintes profissionais:
Administrador de Dados
O grande objetivo do administrador de dados permitir que vrios usurios compartilhem os
dados corporativos. Deste modo, os dados no pertencem a nenhum sistema ou usurio de
forma especfica, e sim, organizao como um todo. Assim, o administrador de dados se
preocupa basicamente com a organizao dos dados, e no com o seu armazenamento
propriamente dito. Vejamos, suas caractersticas:
Gerenciar o dado como um recurso da empresa.
Planejar, desenvolver e divulgar as bases de dados da empresa.
Permitir a descentralizao dos processos, mas manter centralizado os dados.
Permitir, fcil e rpido acesso s informaes a partir dos dados armazenados.
Administrador de Banco de Dados (DBA)

Em qualquer organizao que compartilha muitos recursos computacionais, existe a
necessidade de um administrador para gerenciar esses recursos. Em um ambiente de Banco
32
de Dados, o recurso primrio o prprio Banco de Dados e o recurso secundrio o SGBD

(e os recursos relacionados).
O Administrador de Banco de Dados o responsvel pela autorizao de acesso ao Banco
de Dados e pela coordenao e monitorao de seu uso. a pessoa que, numa equipe de
desenvolvimento, centraliza tanto o controle dos dados quanto os programas de acesso a
eles. conhecido com a sigla em ingls: DBA (DataBase Administrator).
O DBA tambm responsvel pelos problemas de quebra de segurana ou de baixo
desempenho nos SGBDs. As principais funes do DBA so:
Definio do esquema do Banco de Dados;
Definio da estrutura de dados e mtodos de acesso;
Modificaes no esquema ou na organizao fsica;
Controle das autorizaes de acesso ao sistema;
Especificao das regras de integridade.
Projetista de Banco de Dados (DB Designer)

O Projetista de Banco de Dados responsvel pela identificao dos dados que devem ser
armazenados no Banco de Dados. Ele escolhe a estrutura mais adequada para representar e
armazenar esses dados. funo do projetista tambm avaliar as necessidades de cada
grupo de usurios. Muitas vezes, os projetistas de Banco de Dados atuam como staff do
DBA, assumindo outras responsabilidades aps a construo do Banco de Dados.
Usurios Finais
33
Existem basicamente quatro categorias de usurios de Banco de Dados, que fazem

operaes mais bsicas nos SGBD, tais como consultas, atualizaes e gerao de
documentos:
Usurios Casuais: acessam o Banco de Dados casualmente, mas que podem necessitar de
diferentes informaes a cada acesso. Utilizam normalmente sofisticadas linguagens de
consulta para especificar suas necessidades;
Usurios Novatos ou Paramtricos: utilizam vises do Banco de Dados, utilizando consultas
preestabelecidas que j foram exaustivamente testadas. So tambm chamados de usurios
navegantes, ou seja, usurios comuns que interagem com o sistema atravs de interfaces
pr-definidas;
Usurios Sofisticados: so usurios que esto familiarizados com o SGBD e realizam
consultas mais complexas;
Usurios
Especialistas:
usurios
sofisticados
que
chegam a
escrever
aplicaes
especializadas.
Analistas de Sistemas e Programadores de Aplicaes

Os analistas de sistemas determinam os requisitos dos usurios finais e desenvolvem
especificaes para transaes que atendam estes requisitos. Os programadores de
aplicaes implementam estas especificaes com os programas, testando, depurando,
documentando e dando manuteno aos mesmos. So profissionais em computao que
interagem com o sistema por meio de DMLs, envolvidas em programas escritos em
diferentes linguagens hospedeiras.
Profissionais de Apoio
34
Profissionais que auxiliam e apoiam a todos os outros. So projetistas e implementadores de

SGBD, desenvolvedores de ferramentas, e tambm operadores de manuteno.
Observe no link abaixo, no Captulo II, as atribuies do Administrador de

Banco de Dados:
http://pt.wikipedia.org/wiki/Administrador_de_banco_de_dados
Procure saber qual a necessidade no mercado de trabalho de cada um dos

profissionais mencionados, e qual a remunerao mdia deles.
Verifique nos fornecedores de Banco de Dados quais cursos e
treinamentos iro aumentar e especializar seus conhecimentos nessa rea.
35
NIDADE
Objetivo: Apresentar os diversos modelos fsicos e lgicos existentes em Banco de Dados.
Modelagem de Dados I: Modelos Lgicos baseado em Registros

Com a evoluo dos processos, surgiram novas formas de modelar os Bancos de Dados,
visando a suprir as necessidades das empresas e a maior eficcia no processo de
armazenamento das informaes. Na Modelagem de Dados podemos dividir em trs grupos
diferentes:
Modelos Fsicos de Dados
Modelos Lgicos Baseados em Registros
Modelos Lgicos Baseados em Objetos (veremos na Unidade 8)
Modelos Fsicos de Dados

Os modelos fsicos de dados so usados para descrever dados no nvel mais baixo. Em
comparao com os modelos lgicos de dados, existem poucos modelos fsicos em uso.
Dois dos mais conhecidos so: Modelo Unificador (unitying model) e Estrutura de Memria
(frame memory). Para os nossos objetivos mais importante conhecer com maior riqueza de
detalhes os modelos lgicos.
Modelos Lgicos Baseados em Registros

Esses Modelos Lgicos so usados nas descries de dados no Nvel conceitual e no de
Vises. Igualmente como os Modelos de Dados Baseado em Objetos, ambos so usados
36
para especificar a estrutura lgica geral do Banco de Dados e para fornecer uma descrio
de alto nvel da implementao.
Modelos baseados em registros so assim chamados porque o Banco de Dados
estruturado em registros de formato fixo. Cada tipo de registro define um nmero fixo de
campos, ou atributos, e cada campo so usualmente de tamanho fixo. Com esse conceito
surgiram os seguintes modelos de Banco de Dados: Hierrquico, Rede e Relacional.
Desses trs, o Modelo Relacional o que tem maior penetrao no mercado em relao aos
outros dois. O Modelo Hierrquico e o de Rede eram usados em um grande nmero de
Banco de Dados antigos, e em algumas aplicaes na Internet.
O Modelo Hierrquico
O modelo hierrquico surgiu na dcada de 60. Permite organizar dados em uma estrutura
hierrquica (estrutura em rvore invertida), com acesso unidirecional, de pai para o filho,
sempre comeando pela raiz.
Em outras palavras, esse tipo de Banco de Dados formado por uma coleo de registros
conectada uns aos outros por links. Os SGBDs mais conhecidos desse tipo so o IMS
(Information Management System da IBM), Adabas e o System2000.
Os dados organizados, segundo este modelo, podem ser acessados segundo uma
sequncia hierrquica com uma navegao do topo para as ramificaes. Um registro pode
estar associado a vrios registros diferentes, desde que seja replicado. A replicao possui
grandes desvantagens causando inconsistncia nos dados e o desperdcio de espao.
Na Figura 7.1, vemos exemplo de um Banco de Dados no Modelo Hierrquico. Exibem-se
dados como: Nome, Cidade, UF, Conta e Saldo. A conta corrente de dois clientes, Jos Silva
e Maria Silva mantm uma conta em comum (conta: 20343). Por usar o Modelo Hierrquico,
notamos que a conta em comum replicada, apresentando as desvantagens apresentadas
anteriormente.
37
Figura 7.1 Exemplo de modelo hierrquico
O Modelo de Rede
Esse modelo foi utilizado principalmente no final da dcada de 60 e durante a dcada de 70.
Ele permite organizar os dados em uma estrutura formada por vrias listas, que definem uma
intrincada rede de ligaes (estrutura similar a um grafo direcionado). O IDMS e o Total so
os SGBDs mais conhecidos com essa estrutura.
Esse Modelo de Rede , essencialmente, um conjunto ilimitado de ns e de ramais de
ligao. Na verdade, uma hierarquia apenas um tipo particular de rede, pois uma rede no
apresenta o conceito de n raiz e os registros podem ter diversos tipos de registros-pai,
assim como diversos tipos de registros-filho.
Similar ao Modelo Hierrquico, os dados no modelo de rede so organizados em tipos de
registros e ligaes entre registros. No existe restrio hierrquica, ou seja, quaisquer dois
tipos de registros podem se relacionar. Um esquema no Modelo de Rede chamado de
Diagrama de Estrutura de Dados.
Vejamos um exemplo na Figura 7.2, onde utilizamos os mesmo dados do exemplo anterior,
porm adaptado ao Modelo de Rede. Observamos que no existe mais o conceito de raiz, e
tambm no ocorre a replicao do registro. A principal desvantagem dessa abordagem
38
que, se o Banco possuir muitos tipos de entidades, pode resultar em esquemas muito
complexos de relacionamentos.
Figura 7.2 Exemplo de modelo de rede
O Modelo Relacional
O modelo relacional foi formalmente definido por E. Codd, do Laboratrio da IBM em San
Jose, Califrnia, em 1970. O projeto inicial foi denominado de Sistema R e definia a
organizao dos dados e linguagens formais para a sua manipulao.
Com base nessas linguagens, foi definida a primeira verso do SQL (Structured Query
Language). Essa linguagem o padro em SGBD relacionais. Os Bancos de Dados
Relacionais mais famosos so: Oracle, SQL Server, Informix, Sybase e Ingres.
O objetivo bsico tratado pelo modelo relacional entidade ou relao. Uma entidade
equivale ao conceito matemtico de conjunto, ou seja, um agrupamento de elementos.
Um Banco de Dados Relacional visa manter os dados de forma no redundante (repetio
de vrios campos em vrias tabelas), executar processamento integrado, lidar com relaes
mltiplas (relacionamentos) e fornecer certo grau de independncia dos dados.
39
O modelo relacional, de longe, o mais utilizado, pois o modelo que se obtm o maior
desempenho e agilidade. Desde pequenas a grandes empresas e instituies utilizam, com
segurana, gigantes bases relacionais para gerenciar e manter seus dados.
Novamente, usando o mesmo exemplo, vamos ilustrar na Figura 7.3 como que no modelo
relacional so representados os dados. O relacionamento existente entre os dados foi
realizado atravs de um conjunto de 3 tabelas.
A primeira com os dados cadastrais do cliente, a segunda relacionando as contas de cada
cliente, e finalmente na ltima tabela o saldo de cada conta.
Figura 7.3 - Exemplo de modelo relacional
40
http://pt.wikipedia.org/wiki/Modelo_Hierrquico
http://pt.wikipedia.org/wiki/Modelo_em_rede
http://pt.wikipedia.org/wiki/Modelo_Relacional
http://www.linhadecodigo.com.br/Artigo.aspx?id=396
http://www.plugmasters.com.br/sys/materias/586/1/Modelagem-deDados:A-Hierarquias---Parte-1
http://www.plugmasters.com.br/sys/materias/587/1/Modelagem-deDados:A-Hierarquias---Parte-2
Com base nessa Unidade, responda por escrito:

Que exemplos de modelo lgico, baseado em registros, podemos
mencionar?
Qual o modelo de Banco de Dados mais utilizado atualmente?
Quais so as vantagens do modelo relacional de Banco de Dados?
41
NIDADE
Objetivo: Apresentar os vrios modelos lgicos de Banco de Dados baseado em Objetos
Modelagem de Dados II: Modelos Lgicos baseado em Objetos

Na descrio de dados no Nvel Conceitual e no de Vises, so usados Modelos Lgicos
baseados em Objetos. Eles se caracterizam pela capacidade de formar estruturas flexveis,
com restries de dados que podem ser explicitamente especificados. Existem muitos
modelos diferentes, alguns dos mais conhecidos so:
O Modelo Entidade-Relacionamento (MER);
O Modelo Orientado a Objeto (OO);
O Modelo Binrio;
O Modelo Semntico de Dados;
O Modelo Infolgico;
O Modelo Funcional de Dados.
Nesta apostila iremos considerar apenas o Modelo Entidade-Relacionamento e o Modelo

Orientado a Objeto, por serem os maiores representantes da classe de Modelos Lgicos
baseados em Objetos.
O Modelo Entidade-Relacionamento (MER) tem ganhado bastante aceitao nos projetos de
Banco de Dados, e muito utilizado na prtica. O Modelo Orientado a Objeto (OO) inclui
muito dos conceitos do prprio MER, mas representa os cdigos executveis, assim como os
dados, de forma diferente e est ganhando rpida aceitao.
42
Modelo Entidade-Relacionamento (MER)

O MER baseado na percepo do mundo real numa coleo de objetos bsicos chamados
entidades, e nos relacionamentos entre esses objetos. Uma entidade um objeto que
distinguvel de outro, por um conjunto especfico de atributos. O relacionamento uma
associao entre vrias entidades. Por exemplo, um relacionamento Conta-Cliente associa
um cliente a cada conta que ele possui.
A estrutura lgica geral de um Banco de Dados pode ser expressa graficamente por um
Diagrama Entidade-Relacionamento (DER), que consiste nos seguintes componentes:
Retngulos que representam conjunto de entidades;
Elipses que representam atributos;
Losangos que representam relacionamentos entre conjuntos de entidades;
Linhas que interligam atributos, conjuntos de entidades e relacionamentos.
A diferena entre MER e DER que o Modelo Entidade-Relacionamento conceitual, e o

Diagrama Entidade-Relacionamento mostra graficamente a relao existente entre as
entidades (tabelas). Exemplo: Em um MER voc pode ter uma relao n pra n entre duas
entidades, j em um DER nunca! Isto claramente geraria uma terceira tabela pelas regras de
normalizao.
No MER so representadas as entidades, dando uma ideia geral sobre como vai ser o Banco
de Dados. J no DER representado graficamente o prprio Banco de Dados, com suas
tabelas, relacionamentos, regras, restries, tipos de dados, chaves primrias, etc...
Para ilustrar melhor, considere o sistema de Banco de Dados de uma instituio bancria tal
como fizemos at o momento. O Diagrama Entidade-Relacionamento (DER) correspondente
mostrado na Figura 8.1 abaixo.
43
Figura 8.1 - Exemplo de um Diagrama Entidade-Relacionamento (DER)
Modelo Orientado a Objeto

Os Bancos de Dados Orientados a Objeto comearam a se tornar comercialmente viveis
em meados de 1980. A motivao para seu surgimento foi em funo dos limites de
armazenamento e representao semntica impostas no modelo relacional. Alguns exemplos
so os Sistemas de Informaes Geogrficas (SIG), e os sistemas CAD e CAM, que so
mais facilmente construdos usando tipos complexos de dados. A habilidade para criar esses
tipos de dados uma caracterstica das linguagens de programao Orientadas a Objetos.
Assim como o MER, o Modelo Orientado a Objeto baseado num conjunto de objetos. Um
objeto contm valores armazenados em variveis de instncia dentro do prprio objeto.
Contrariamente ao modelo a registros, estes valores so os objetos em si. Um objeto
tambm possui trechos de cdigo que operam nele mesmo. Estes trechos de cdigos so
chamados mtodos. Os objetos que contm os mesmos tipos de valores e os mesmos
mtodos so agrupados em classes. Uma classe pode ser vista como uma definio de tipo
de objetos. O nico modo pelo qual um objeto pode fazer o acesso ao dado de outro objeto
invocando o mtodo desse outro objeto.
O termo Modelo Orientado a Objetos usado para documentar o padro que contm a
descrio geral das facilidades de um conjunto de linguagens OO e a biblioteca de classes
que formam a base para o SGBD. Quando os Bancos de Dados Orientados a Objetos foram
introduzidos, algumas das falhas perceptveis do Modelo Relacional pareceram ter sido
44
solucionadas, e acreditava-se que tais BD ganhariam grande parcela do mercado. Hoje,

porm, acredita-se que os Bancos de Dados Orientados a Objetos somente devem ser
utilizados em aplicaes especiais, e os Sistemas Relacionais continuaro a sustentar os
negcios tradicionais, onde as estruturas de dados baseadas em relaes so suficientes.
O Diagrama de Classes da UML (Unified Modeling Language) serve geralmente de esquema
para o Modelo de Dados Orientado a Objetos. Observe o exemplo da Figura 8.2, e compare
as diferenas com o modelo anterior.
Figura 8.2 - Diagrama UML Cliente - Conta
http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
http://pt.wikipedia.org/wiki/Diagrama_entidade_relacionamento
http://www.unipan.br/emerson/Engenharia/DER.doc
http://www.plugmasters.com.br/sys/materias/453/1/Modelagem-de-Dados4---Validao-do-modelo-ER
Veja tambm o artigo Uma Nova Era na Tecnologia dos Bancos de Dados
no site abaixo:
http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=68
45
Faa um Diagrama Entidade-Relacionamento de um sistema de Banco de

Dados de uma escola, usando as seguintes entidades Aluno, Professor e
Disciplina. E preste ateno nos relacionamentos existentes entre cada
entidade.
46
NIDADE
Objetivo: Definir e exemplificar os conceitos de entidade, atributo e tupla
Definio de Entidade, Atributo e Tupla

Para construirmos uma base de dados, necessrio um alicerce, que ser a estrutura do
Banco de Dados. Essa estrutura chamada de entidade e, na prtica, conhecida como
tabela. Para facilitar, vamos fazer uma analogia com uma agenda de dentista, que pode ser
considerado um simples Banco de Dados.
Em uma agenda de dentista convencional, podemos encontrar pelo menos duas entidades,
sendo uma o paciente (com o nome e telefone) e a outra os horrios (com o dia e a hora da
consulta). Note que o tipo de dado em cada entidade pode ser diferente, mas de mesma
natureza. A entidade no o conjunto dos dados em si, mas sim os registros, que veremos a
definio em seguida. A entidade, ou tabela, a estrutura na qual foi elaborada a agenda
(quais informaes devem ser anotadas, a forma, o espao reservado para cada telefone,
etc).
A entidade um objeto de um Banco de Dados (BD). A ela pertencem os atributos. No
exemplo do BD Agenda, ela possui duas entidades, ou tabelas: Paciente (com os Atributos
Nome e Telefone) e a Entidade Horrio (com os atributos Data e Hora). Um atributo, ou
campo, um conjunto de caractersticas de um registro.
47
Figura 9.1 - Esquema de um Banco de Dados
O elemento principal de um Banco de Dados a tabela (entidade). Anlogo a uma planilha

com colunas e linhas (ver Figura 9.2 a seguir), a tabela um objeto do Banco de Dados,
constituda de colunas (campos ou atributos) e linhas que so os dados em si (registros ou
tuplas).
Na Figura 9.2 abaixo, podemos observar uma tabela (entidade) que possui os campos
(atributos): Cdigo, Nome, Endereo e Telefone. O campo deve definir os parmetros para a
incluso de um registro. Podemos ainda observar a existncia de trs registros (ou tuplas),
ou seja, trs pessoas cadastradas, cada uma com os seus respectivos dados definidos pelo
campo.
Figura 9.2 Exemplo de entidade e atributos
Nomenclatura de Campos
48
Voc pode observar que nos exemplos anteriores, desobedecemos algumas regras de
ortografia. Isso se deve ao fato de que os campos devem respeitar alguns padres em
termos de nomenclatura. Esses padres no so sempre obrigatrios. Mas, recomenda-se
observar as seguintes regras:
No utilizar caracteres especiais (@,#,$,%...), exceto o underline (_);
Evitar acentos e cedilhas;
Nome do campo deve comear com uma letra maiscula e no com nmero;
Evitar o uso de nomes compostos de duas ou mais palavras com espaos em branco.
Exemplo de nomes de campos recomendados:
Codigo (sem acento)
Endereco (sem cedilha)
NomedoCliente ou Nome_Cliente (campos sem espaos em branco)
Acessorio1
Acessorio2
Procure saber qual a necessidade no mercado de trabalho de cada um dos

profissionais mencionados, e qual a remunerao mdia deles.
Verifique nos fornecedores de Banco de Dados quais cursos e treinamentos
iro aumentar e especializar seus conhecimentos nessa rea.
49
interessante, para maior organizao, definir-se um padro de nomenclatura.

Em um Banco de Dados pequeno pode parecer exagero, mas quando
trabalharmos com uma base de dados maior, isso vai ser de grande ajuda. Voc
pode, por exemplo, definir quatro dgitos para o nome do campo e mais trs
dgitos para o nome da tabela.
Exemplos: Codi_cli (campo Codi da tabela cli), Nome_cli (campo Nome da tabela
cli), Desc_pro, Fone_fun, e assim por diante.
Tipos de Dados
Voc pode observar na figura 9.2, que o tipo de dado computado no campo Nome bem
diferente do tipo de dado computado no campo Telefone. Seria incorreto generalizar os
campos. Cada campo deve conter um tipo de dado especfico conforme as caractersticas
que ele receber.
Nesse caso, os campos Nome e Endereo podem ser do tipo alfanumrico. E o campo
Telefone poder ser do tipo numrico. Observe que o campo Nome contm menos
caracteres (letras) que o campo Endereo. O tamanho dos campos tambm deve ser
avaliado individualmente. Vamos supor um campo que contenha a sigla de um Estado do
Brasil; ele somente precisar de dois dgitos.
Cada SGBD introduz tipos de valores de campo que no necessariamente so padres.
Entretanto, existe um conjunto de tipos de dados que so representados praticamente na
totalidade destes bancos. Estes tipos de dados comuns so os seguintes:
Alfanumricos
Contm letras e nmeros. Tamanho limitado normalmente a 255

caracteres.
50
Numricos
Booleanos
Binrios)
Normalmente com a possibilidade de inserir nmeros inteiros (sem

decimais) ou reais (com decimais).
(ou Permitem somente dois valores (Verdadeiro e Falso, Sim ou No, ou
ainda 0 e 1).
Armazena datas possibilitando ordenar os registros cronologicamente
Datas
ou calcular os dias entre uma data e outra.
Memos
Autoincrementveis
So campos alfanumricos de tamanho ilimitado. No podendo ser

indexado (veremos mais adiante essa definio).
So numricos inteiros que so incrementados automaticamente em
uma unidade para cada registro incorporado. timo para chaves.
Se tiver dificuldades para criar uma tabela no MS-Access, siga o tutorial

abaixo que explicar passo a passo:
http://www.apoioinformatica.inf.br/sgbd/sgbd1.htm
http://www.apoioinformatica.inf.br/sgbd/sgbd2.htm
Por exemplo, veja os vrios Tipos de Campos usados no MySQL no site
abaixo:
http://dev.mysql.com/doc/refman/4.1/pt/column-types.html
51
Procure no MS-Access criar uma tabela e preste ateno nos Tipos de

Dados usados no Access quando for criar os campos de uma tabela.
52
NIDADE
10
Objetivo: Conceituar o significado de chaves e analisar os vrios tipos de chaves utilizados

em um Banco de Dados.
Definio de Chave Primria Simples, Composta, nica e Estrangeira

recomendado que uma tabela tenha um ou mais atributos que seja possvel identificar um
especfico registro. Esse atributo chamado de chave primria. Uma chave primria dever
ser sempre nica, nunca poder ser repetida. Por exemplo, normalmente todo cliente
identificado por um cdigo. O cdigo do cliente a chave primria, e no poder existir outro
cliente com esse mesmo cdigo. Se os cdigos de dois clientes fossem iguais, como iramos
identificar cada um deles?!?
Ao escolher uma chave primria, voc deve estar atento aos seguintes detalhes:
A chave primria NUNCA deve ser repetida, portanto no escolha campos que no
satisfaam esta condio. Por exemplo, datas de aniversrio normalmente no so boas
chaves primrias.
O tamanho da chave primria afeta a velocidade das operaes do seu Banco de Dados.
Para um bom desempenho, use o menor tamanho possvel que acomode esses valores.
Prefira campos numricos.
O campo chave primria sempre vai estar automaticamente indexado, ou seja, ordenado.
Vejamos agora, com maiores detalhes, anlise dos trs tipos de chaves convencionais:
Chave Primria Simples e Composta

Quando apenas um atributo compe a chave primria, ela chamada de chave primria
simples. Quando mais de um atributo compe a chave primria, ela chamada de chave
53
primria composta. Por exemplo, o nmero da conta corrente normalmente formado por
dois atributos: o nmero da agncia e o nmero da conta. Obviamente, o nmero da agncia
pode ser repetido individualmente, afinal uma agncia bancria no tem apenas um nmero
de conta.
Chave nica
Uma chave nica um meio que utilizamos quando um determinado campo no deve ser
repetido e no deve ser chave primria. Com esse mtodo, damos mais consistncia ao
Banco de Dados. Por exemplo, em um cadastro de clientes, normalmente a cada cliente
atribudo um nmero que a chave primria. Para se ter maior segurana, adiciona-se o RG
como chave nica, para evitar que o cliente seja cadastrado duas vezes.
Chave Estrangeira
A chave estrangeira utilizada quando queremos que o valor de um atributo seja validado a
partir do valor de atributo de outra tabela. Nesse caso h certa relao de dependncia entre
as tabelas. Por exemplo, antes de efetuar o cadastro de um pedido de venda, devemos nos
certificar de que o cliente em questo consta no cadastro de clientes. O campo cdigo do
cliente na tabela de clientes uma chave primria. Esse mesmo valor na tabela de pedidos
uma chave estrangeira.
http://www.imasters.com.br/artigo/5403/bancodedados/modelagem_de_dad
os_-_parte_05_transformacao_entre_modelos//imprimir/
54
Antes de dar continuidade aos seus estudos fundamental que voc

entre no site da ESAB e, em sua Sala de Aula, faa a Atividade 1, no link
Atividades.
55
NIDADE
11
Objetivo: Conceituar o significado de relacionamento e analisar os vrios tipos utilizados em

Banco de Dados.
Relacionamentos entre Bancos de Dados

Uma associao estabelecida entre campos comuns em duas tabelas leva o nome de
relacionamento. Dessa forma permitimos o estabelecimento de correspondncia entre
registros de diferentes tabelas.
Um relacionamento funciona pela coincidncia de dados em campos-chaves (geralmente um
campo com o mesmo nome em ambas as tabelas). Na maioria dos casos, esses campos
coincidentes so a chave primria de uma tabela, e uma chave estrangeira em outra tabela.
Um Banco de Dados Relacional requer dados duplicados entre tabelas (os dados que
efetivaro as ligaes), mas no permite dados duplicados dentro das prprias tabelas.
Por exemplo, podemos associar um cliente especfico a uma tabela de pedidos atravs do
campo cdigo do cliente. Com isso, na tabela de pedidos no necessrio ter os dados
cadastrais do cliente (nome, endereo, cidade, etc.), pois devido associao, obtm-se
esses dados a qualquer momento.
Com o relacionamento entre duas entidades, o nmero de ocorrncias de uma entidade com
a outra, determina o Grau de Relacionamento, ou a Cardinalidade. No mundo real
apresentam-se trs possibilidades de relacionarmos os dados, ou seja, trs Graus de
Relacionamento, que so:
Relacionamento um-para-um
Relacionamento um-para-muitos
Relacionamento muitos-para-muitos
56
Relacionamento um-para-um
Em um relacionamento um-para-um, cada registro na tabela X pode ter somente um registro
coincidente na tabela Y. E por sua vez, cada registro na tabela Y pode ter somente um
registro coincidente na tabela X. Para que esse relacionamento acontea, os campos
relacionados nas duas tabelas devem ser chaves primrias. Esse tipo de relacionamento no
muito comum, pois a maioria dos dados relacionados poderia simplesmente estar em uma
nica tabela.
A utilizao de um relacionamento um-para-um recomendada quando voc deseja dividir
uma tabela com muitos campos, isolar parte de uma tabela por segurana ou armazenar
dados que se apliquem somente a um subconjunto da tabela principal. Outra possibilidade
seria aumentar a performance do Banco de Dados quando uma tabela, muito acessada,
apresenta-se com muitos campos dividindo-a em duas tabelas.
Por exemplo, o relacionamento na tabela de Funcionrio com a de Armrio (veja a Figura
11.1). Observe que para que haja este relacionamento, os campos relacionados nas duas
tabelas devem ser chaves primrias (codigo e funcionario). Nesta aplicao especfica, um
funcionrio somente poder ter um armrio e vice-versa.
Figura 11.1 - Relacionamento um-para-um
Relacionamento um-para-muitos
Um relacionamento um-para-muitos estabelece que um registro em uma tabela X pode ter
vrios registros associados em uma tabela Y. Para isso o campo relacionado na tabela X
deve ser chave primria, e o campo na tabela Y no deve ser chave primria. Ao efetuarmos
57
o relacionamento, o campo relacionado na tabela Y ser chamado de chave estrangeira.

Este o relacionamento mais comum e o mais utilizado em Banco de Dados.
Por exemplo, um cliente pode efetuar vrios pedidos, mas um pedido s pode ser feito por
um cliente. Note que para isso preciso que o campo relacionado na tabela Cliente seja
chave primria (cdigo), e o campo relacionado em Pedido no seja chave primria (cliente).
Figura 11.2 Relacionamento um-para-muitos
Em um relacionamento um-para-muitos, a tabela com a chave primria dita tabela pai. E,

consequentemente, a outra ser chamada de tabela filho.
Relacionamento muitos-para-muitos
Note que a tabela de Pedido no exemplo anterior possui uma falha: cada pedido somente
poder ter um nico produto. Na vida real, os clientes ao solicitarem vrios produtos teriam
que fazer um pedido para cada produto, invivel !!
Uma soluo seria colocar mais campos na tabela de Pedido para que pudessem colocar
mais produtos (produto1, produto2, etc). Mas, mesmo assim, estaramos limitados ao nmero
de campos criados, e o processamento de informaes nessa tabela seria lento. Uma melhor
soluo seria estabelecermos um relacionamento muitos-para-muitos, em que vrios
produtos podem estar em vrios pedidos.
Em um relacionamento muitos-para-muitos, um registro na tabela X pode ter vrios registros
coincidentes na tabela Y, e um registro da tabela Y pode ter vrios registros coincidentes na
tabela X. No entanto, no possvel efetuar este relacionamento de forma direta. Esse tipo
de relacionamento s possvel definindo uma terceira tabela (denominada tabela de
associao ou tabela de detalhes). Ela deve possuir chave primria composta de dois
campos, e as chaves estrangeiras provenientes tanto da tabela X como da Y. Observe que
58
na verdade, um relacionamento muitos-para-muitos so dois relacionamentos um-paramuitos, com uma tabela intermediria.
Por exemplo, para efetuar uma venda de um produto apenas, so necessrios no mnimo um
registro na tabela de Pedido e um registro na tabela de ItensPedido. Ao efetuar uma venda
com dois produtos, so necessrios um registro em Pedido e dois registros em ItensPedido.
Dessa forma, cada produto vendido ser necessrio um registro na tabela de ItensPedido, e
a cada pedido, um registro na tabela de Pedido.
Figura 11.3 Relacionamento muitos-para-muitos
Note que a tabela de associao possui uma chave primria composta pelos campos pedido
e produto. Esses campos so chaves estrangeiras nos relacionamentos um-para-muitos.
http://access-exemplos.blogspot.com/2007/08/relacionamentos-numabase-de-dados.html
Tente atravs do MS-Access criar as tabelas dos exemplos citados, e fazer

os relacionamentos aprendidos.
59
NIDADE
12
Objetivo: Conceituar o significado de Relacionamentos Especiais com Mltiplas Entidades

em um Banco de Dados.
Relacionamentos Especiais com Mltiplas Entidades

At o momento estudamos e analisamos situaes em que as entidades se relacionam aos
pares. Este o princpio de descoberta dos relacionamentos na construo de um modelo de
dados: analisar as entidades aos pares.
Entretanto um relacionamento pode existir envolvendo mais de duas entidades, que podem
ser trs, quatro, ou uma quantidade indeterminada de entidades que os relacionamentos
estiverem envolvidos.
Os relacionamentos entre mltiplas entidades expressam um fato em que todas as entidades
ocorrem simultaneamente, ou seja, todas as ocorrncias do relacionamento possuem,
sempre, ligaes com todas as entidades envolvidas no relacionamento. No pode existir um
relacionamento triplo, que em um determinado momento, se transforme em duplo.
O Relacionamento Mltiplo com mais de quatro entidades relacionadas extremamente
difcil de se encontrar na realidade do dia a dia. Quando voc encontrar com algum fato que
d origem a um relacionamento mltiplo, analise com cuidado, pois o mesmo pode ser
desmembrado em mais de um relacionamento. A implementao de relacionamento mltiplo
em Bancos de Dados torna o trabalho de manipulao bastante complexo.
60
Baixe a apresentao do Prof. Yasuo Kono sobre Relacionamentos

Especiais (link referenciado anteriormente no Estudo complementar) e
realize um breve resumo.
61
NIDADE
13
Objetivo: Definir o que vem a ser integridade dentro do contexto de Banco de Dados.
Integridade dos Dados

Os dados de um SGBD devem ser ntegros e consistentes. Para isso so necessrios que se
estabeleam alguns critrios que garantam a consistncia em um Banco de Dados e sua
integridade. Veja as seguintes situaes tpicas de falha na integridade dos dados:
Pense o leitor como seria complicado conseguir o endereo de um cliente, se na hora do seu
cadastro esqueceu-se esse detalhe. Ainda por cima se existem outros clientes cadastrados
com esse mesmo problema. Uma mala direta seria invivel.
Um funcionrio, ao cadastrar o cliente, cometeu um erro de digitao e digitou um estado
inexistente ou um estado em que a empresa no atua?
Imagine um pedido de vendas de um valor bem alto e importante para a empresa, e que
devido a um lamentvel erro perdeu-se o cdigo do cliente.
So problemas que devemos considerar na criao de um Banco de Dados. As regras de
integridade podem se apresentar de vrias formas, vamos aqui considerar as trs formas
mais comuns:
Integridade de Domnio
Integridade de Entidade
Integridade Referencial
Integridade de Domnio
62
Este tipo de integridade zela pelos valores ideais e necessrios para um atributo. Para isso,
definimos algumas regras de validao por meio de expresses compostas de valores
constantes. Por exemplo:
No permitir um estoque negativo.
Impedir uma data de nascimento incompatvel com a idade mnima do pblico-alvo.
No permitir que o valor de um produto seja negativo.
Integridade de Entidade
A integridade de entidade tem o objetivo de validar os valores permitidos a partir de valores
j inseridos anteriormente. Aps uma autoconsulta a entidade vai permitir ou no a
gravao de um novo registro. Por exemplo:
No permitir duas pessoas com o mesmo RG.
Em uma locadora, impedir que seja locada uma fita que j est locada.
Integridade Referencial
A partir do momento que estabelecemos alguns relacionamentos, as regras de integridade
referencial j esto automaticamente criadas. Elas zelam pela consistncia dos registros de
uma entidade a partir de valores provenientes de outras entidades. Ou seja, determinado
registro vai depender diretamente de um registro em outra tabela.
Um registro em uma determinada tabela pai pode ter um ou mais registros coincidentes na
tabela filho.
Um registro em uma tabela filho sempre tem um nico registro coincidente em uma tabela
pai.
63
Para a incluso de um registro em uma determinada tabela filho, necessrio que exista um
registro pai coincidente.
Um registro pai s poder ser excludo se no possuir nenhum registro filho.
Realize uma anlise crtica, e comparativa com o que a gente j viu at

agora, com o excelente artigo de Joo Roberto da Cunha, da Serpro, no
link abaixo:
http://www1.serpro.gov.br/publicacoes/tematec/pubtem03.htm
64
NIDADE
14
Objetivo: Fundamentar o conceito de normalizao e as suas tcnicas.
Normalizao A Primeira, Segunda e a Terceira Forma Normal

O conceito de normalizao foi introduzido por E.F. Codd em 1970 (primeira forma normal).
Esta tcnica um processo matemtico formal, que tem seus fundamentos na teoria dos
conjuntos. Atravs deste processo pode-se, gradativamente, substituir um conjunto de
entidades e relacionamentos, purificando os mesmos evitando certos problemas, tais como:
grupos repetitivos de dados, redundncia de dados desnecessrios e perdas acidentais de
informaes.
Um cadastro de funcionrio certamente conteria todos os dados necessrios sobre o
funcionrio, porm ter um grande volume de redundncias com relao a outros
funcionrios. Normalizao uma tcnica de anlise e organizao de dados, que consiste
na decomposio de um depsito de dados (estrutura no-normalizada), em formas mais
simples, denominadas formas normais.
Os objetivos da normalizao so:
Independncia dos dados.
Minimizar redundncias, que por sua vez minimiza os riscos de inconsistncias.
Facilitar a manipulao do Banco de Dados.
Facilitar a manuteno dos sistemas de informao, sem grandes impactos.
Existem duas formas de utilizao da normalizao:

TOP-DOWN: aps a definio do modelo de dados (diagrama entidade-relacionamento, por
exemplo), aplica-se a normalizao para se obter uma sntese dos dados, bem como uma
65
decomposio das entidades e relacionamentos em elementos mais estveis, tendo em vista

sua implementao fsica em um BD;
BOTTOM-UP: aplica-se a normalizao como ferramenta de projeto do modelo de dados,
usando os relatrios, formulrios e documentos utilizados pela realidade em estudo,
constituindo-se em uma ferramenta de levantamento.
Para ilustrar os problemas da falta de normalizao e iniciar um processo BOTTOM-UP,
considere a entidade PEDIDO baseada numa nota fiscal de uma loja, como mostrado abaixo:
Pedido (Num_Ped, Nome_Cli, Endereco, Cidade, UF, Cod_Prod, Qtde, Descr, Valor_Unit, Total_Prod,
Total_Ped, Cod_Vend, Nome_Vend)
As anomalias de atualizao desse projeto so:
Anomalia de Incluso: ao ser includo um novo cliente, o mesmo tem que estar
relacionado a uma venda;
Anomalia de Excluso: ao ser excludo um cliente, os dados referentes s suas

compras sero perdidos;
Anomalia de Alterao: caso algum fabricante de produto altere o preo de um

produto, ser preciso percorrer toda a relao para se realizar mltiplas alteraes.
Primeira Forma Normal (1FN)

A 1FN trata de informaes que se repetem (atributos multivalorados) e define que cada
ocorrncia da chave primria deve corresponder a uma e somente uma informao de cada
atributo, ou seja, a entidade no deve conter grupos repetitivos.
66
Para um esquema com relaes no normalizadas (como a relao PEDIDO acima), a

soluo decompor cada relao no normalizada em tantas entidades quanto for o nmero
de grupos repetitivos.
Nas novas relaes, a chave primria a concatenao da chave primria da relao
original mais os atributos do grupo repetitivo visualizados como chave primria.
Exemplo:
Aplicando 1FN na relao PEDIDO, observa-se que existe um grupo repetitivo dentro da
relao, que trata dos vrios produtos que podem constar num pedido. Isto se deve ao fato
de que este grupo forma uma coluna no atmica. Este grupo composto dos atributos
Cod_Prod, Qtde, Descr, Valor_Unit, Total_Prod. Portanto, cria-se uma nova relao, a ser
chamada de ITEM_PEDIDO, ficando o esquema da seguinte forma:
PEDIDO (Num_Ped, Nome_Cli, Endereco, Cidade, UF, Total_Ped, Cod_Vend, Nome_vend)

ITEM_PEDIDO (Num_Ped, Cod_Prod, Qtde, Descr, Valor_Unit, Total_Prod)
Dependncia
Para mostrar a 2FN e 3FN, necessrio introduo dos Conceitos de Dependncia entre
atributos.
Dependncia Funcional Total - Um atributo ou conjunto de atributos depende de forma total
da chave primria concatenada se a cada valor da chave est associado um valor para este
atributo.
67
Dependncia Funcional Parcial - O atributo s depende de parte da chave primria. Exemplo:

ITEM_PEDIDO (Num_Ped, Cod_Prod, Qtde, Descr, Valor_Unit, Total_Prod)
O atributo Qtde depende de forma total da chave primria (Num_Ped + Cod_Prod)

O atributo Descr (descrio do produto) depende de forma parcial da chave primria, pois s
depende do Cod_Prod e no do Num_Ped + Cod_Prod.
Dependncia Funcional Transitiva - Quando um atributo ou conjunto de atributos A depende
de outro atributo B que no pertence chave primria, mas dependente funcional desta,
dizemos que A dependente transitivo de B. Exemplo:
Os atributos Endereco, Cidade, UF so dependentes transitivos do atributo Nome_Cli.

Nome_vend dependente transitivo de Cod_Vend
Segunda Forma Normal (2FN)

Uma relao se encontra em 2FN quando estiver em 1FN e todos os atributos que no
participam da chave primria so dependentes desta. Assim devemos verificar se todos os
atributos so dependentes da chave primria, e retirar da relao todos os atributos de um
grupo no dependente que dar origem a uma nova relao, que conter esse atributo como
no chave. Desta maneira, em 2FN evita inconsistncias devido a duplicidades.
Exemplo: (a nica relao no nosso esquema com chave concatenada)
ITEM_PEDIDO (Num_Ped, Cod_Prod, Unid, Qtde, Descr, Valor_Unit, Total_Prod)
Os atributos Descr, Valor_Unit dependem de Cod_Prod o qual faz parte da chave primria.
Cria-se a relao PRODUTO (Cod_Prod, Descr, Valor_Unit), com a chave primria
Cod_Prod e em ITEM_PEDIDO, a chave primria permanece Num_Ped + Cod_Prod.
68
ITEM_PEDIDO (Num_Ped, Cod_Prod, Qtde, Total_Prod )

PRODUTO (Cod_Prod, Descr, Valor_Unit)
Terceira Forma Normal (3FN)

Uma relao est na 3FN se est em 2FN e se nenhum de seus atributos possui
dependncia transitiva em relao a outro atributo que no esteja na chave primria. Ao
retirarmos a dependncia transitiva, criam-se novas relaes com os atributos que
dependem transitivamente do outro, e a sua chave primria o atributo que causou essa
dependncia.
Uma relao na 3FN, alm de no ter dependncia transitiva, no pode ter atributos que
sejam resultado de algum clculo sobre outro atributo, o que, de certa forma, pode ser
encarado como dependncia funcional. Exemplo:
O atributo Nome_vend depende transitivamente de Cod_Vend, o qual no pertence chave

primria, mas depende desta;
Cria-se a relao VENDEDOR (Cod_Vend, Nome_vend);
Os atributos Endereco, Cidade, UF dependem transitivamente de Nome_Cli que no est na
chave primria (mas depende desta);
Cria-se a relao CLIENTE (Cod_Cli, Nome_Cli, Endereco, Cidade, UF).
69
No final ficaramos com um esquema, mais ou menos, assim:

PEDIDO (Num_Ped, Cod_Cli, Total_Ped, Cod_Vend)
VENDEDOR (Cod_Vend, Nome_vend)
CLIENTE (Cod_Cli, Nome_Cli, Endereco, Cidade, UF)
ITEM_PEDIDO (Num_Ped, Cod_Prod, Qtde, Total_Prod )
PRODUTO (Cod_Prod, Descr, Valor_Unit)
Observao: note que foi criado um cdigo para o cliente, sendo este cdigo a chave
primria da relao, pois o nome do cliente no seria uma chave apropriada. Um modelo ER
do problema acima seria:
O processo de normalizao deve ser aplicado em uma relao por vez, pois durante o
processo de normalizao vamos obtendo quebras, e, por conseguinte, novas relaes. No
70
momento em que o sistema estiver satisfatrio, do ponto de vista do analista, este processo
iterativo interrompido. Embora existam 4FN e 5FN, no vamos explor-las devido a sua
complexidade.
http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados
A normalizao uma parte complexa, mas importante dentro dos

conceitos de Banco de Dados. Quem domina adequadamente esse
conceito, consegue criar Bancos de Dados inteligentes e racionais.
Portanto, faa um comparativo entre o que foi explicado nesta unidade com
o material referenciado do wikipdia no Estudo Complementar.
71
NIDADE
15
Objetivo: Entender os princpios bsicos do armazenamento e manipulao de dados.
Fundamentos de Armazenamento e Manipulao de Dados

Linguagem de Definio de Dados
Um esquema de Banco de Dados especificado por um conjunto de definies expressas
por uma linguagem especial chamada linguagem de definio de dados (Data Definition
Language, DDL). O resultado da compilao de comandos de uma DDL um conjunto
tabelas que so armazenadas em um arquivo especial chamado dicionrio (ou diretrio) de
dados.
Um diretrio de dados um arquivo que contm metadados, ou seja, "dados sobre dados".
Este arquivo consultado antes que os dados sejam lidos ou modificados no sistema de
Banco de Dados.
A estrutura de armazenagem e os mtodos de acesso usados em um sistema de Banco de
Dados so especificados por um conjunto de definies em um tipo especial de DDL
chamado linguagem de armazenagem e definio de dados. O resultado da compilao
destas definies um conjunto de instrues para especificar a implementao de detalhes
do esquema de Banco de Dados que esto normalmente escondidos dos usurios.
Linguagem de Manipulao de Dados

Os nveis de abstrao discutidos anteriormente (nveis fsico, conceitual e de viso) no se
aplicam somente definio ou estrutura de dados, mas tambm sua manipulao. A
manipulao de dados significa:
A busca da informao armazenada no BD;

72
A insero de novas informaes nos BD;
A eliminao de informaes no BD;
A modificao de dados armazenados no BD.
No nvel fsico precisamos definir algoritmos que permitam um acesso eficiente aos dados.
Nos nveis mais altos de abstrao dada nfase facilidade de uso. O objetivo fornecer
uma interao humana eficiente com o sistema.
A linguagem de manipulao de dados (Data Manipulation Language, DML) a linguagem
que permite aos usurios fazer o acesso a os dados ou manipul-los, conforme modelo
apropriado de dados. Existem basicamente dois tipos:
DMLs procedurais requerem do usurio a especificao de qual dado necessrio e

de como obt-lo;
DMLs no-procedurais requerem do usurio a especificao de qual dado

necessrio sem especificar como obt-lo.
DMLs no-procedurais so usualmente mais fceis de aprender e usar do que DMLs

procedurais. Entretanto, se um usurio no necessita especificar como obter os dados, estas
linguagens podem gerar cdigo no to eficiente como o produzido por linguagens
procedurais. Esta dificuldade pode ser remediada por meio de vrias tcnicas de otimizao.
Uma consulta (query) um comando requisitando a busca de uma informao. A poro de
uma DML que envolve busca de informaes chamada linguagem de consulta. Embora
tecnicamente incorreto, comum utilizar os termos linguagem de consulta e linguagem de
manipulao de dados como sinnimos.
Estrutura geral do sistema

Um sistema de Banco de Dados dividido em mdulos que tratam de cada uma das
responsabilidades do sistema geral. Na maioria dos casos, o sistema operacional do
73
computador fornece apenas os servios mais bsicos e o sistema de Banco de Dados

precisa ser construdo sobre essa base. Portanto, o projeto do sistema de Banco de Dados
precisa incluir consideraes sobre a interface entre o sistema de Banco de Dados e o
sistema operacional.
Os componentes funcionais de um sistema de Banco de Dados incluem:
Gerenciador de arquivos, que gerencia a alocao do espao na armazenagem do

disco e as estruturas de dados usadas para representar a informao armazenada no
disco.
Gerenciador do Banco de Dados, que fornece a interface entre os dados de baixo

nvel armazenados no disco e os programas aplicativos e de consulta submetidos ao
sistema.
Processador de consultas, que traduz os comandos numa linguagem de consulta para

instrues de baixo nvel que o gerenciador do Banco de Dados pode interpretar.
Alm disso, o processador de consultas tenta transformar uma requisio do usurio
em uma forma compatvel e mais eficiente com respeito ao Banco de Dados,
encontrando uma boa estratgia para a executar a consulta.
Pr-compilador da DML, que converte comandos da DML embutidos em um aplicativo

para chamadas de procedimento normal na linguagem hospedeira. O pr-compilador
precisa interagir com o processador de consultas pra gerar o cdigo apropriado.
Compilador da DDL, que converte comandos da DDL em um conjunto de tabelas

contendo metadados ou "dados sobre dados".
Adicionalmente, diversas estruturas de dados so requeridas como parte da implementao

do sistema fsico, incluindo:
Arquivos de dados, que armazenam o Banco de Dados propriamente dito.
74
Dicionrio de dados, que armazena metadados sobre a estrutura do Banco de Dados. O

dicionrio de dados usado com frequncia. Assim, deve-se dar grande nfase no
desenvolvimento de um bom projeto e implementao eficiente do dicionrio.
ndices, que fornecem acesso rpido aos itens de dados guardando determinados valores.
Figura 15.1 - Diagrama simplificado da arquitetura do sistema de Banco de Dados
75
Figura 15.2 - Diagrama expandido da arquitetura do sistema de Banco de Dados
http://pt.wikipedia.org/wiki/Servidor
76
Com base nas figuras 15.1 e 15.2, tente descrever atravs de palavras o que
os diagramas tentam repassar.
77
NIDADE
16
Objetivo: Definir e exemplificar a linguagem mais significativa em Banco de Dados

A Linguagem SQL
O nome SQL significa Structured Query Language (Linguagem Estruturada de Pesquisa).
Essa linguagem, de grande utilizao, teve seus fundamentos no modelo relacional de Edgar
Frank Codd (1970). Sua primeira verso recebeu o nome de SEQUEL (Structured English
Query Language), em 1974, nos laboratrios da IBM. Entre 1976 e 1977, o SEQUEL foi
revisado e ampliado, mas teve que ser alterado o seu nome para SQL devido j ter sido
registrado o cognome anterior.
Graas ao sucesso dessa nova forma de consulta e manipulao de dados, dentro de um
ambiente de Banco de Dados, a utilizao da SQL foi se tornando cada vez maior. Com isso
uma grande quantidade de SGBDs tem como linguagem bsica o SQL, como por exemplo,
DB2 da IBM, ORACLE da Oracle Coporation, RDB da Digital, SYBASE da Sybase INC e
SQL Server da Microsoft, entre outros.
O SQL se tornou um padro de fato, no mundo dos ambientes de Banco de Dados
relacionais, porm somente em 1982. Infelizmente, existem hoje vrios dialetos SQL, cada
SGBD inclui implementaes especficas. Neste curso seguiremos o padro ANSI do SQL,
mostrando os conceitos bsicos e a importncia desta linguagem.
Atualmente, a linguagem SQL, assume um papel muito importante nos SGBD, podendo ter
muitos enfoques, como os listados abaixo:
Linguagem interativa de consulta: Por meio de comandos SQL, os usurios podem montar
consultas poderosas sem a necessidade de criao de um programa, podendo utilizar Forms
ou ferramentas de montagem de relatrio;
78
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 administrao do
Banco de Dados (DBA) pode utilizar comandos SQL para realizar suas tarefas;
Linguagem cliente/servidor: Os programas (cliente) dos computadores pessoais usam
comandos SQL para se comunicarem por meio de uma rede local, compartilhando 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: O SQL auxilia na distribuio dos dados por
meio de vrios ns conectados ao sistema de computao. Auxilia tambm na comunicao
de dados com outros sistemas;
Caminho de acesso a outros Bancos de Dados em diferentes mquinas: O SQL auxilia na
converso entre diferentes produtos de Banco de Dados colocados em diferentes mquinas
(de micro at mainframe).
O SQL apresenta uma srie de comandos que permitem a definio dos dados, chamada de
DDL (Data Definition Language). Como exemplo de comandos da classe DDL temos os
comandos Create, Alter e Drop.
Os comandos da srie DML (Data Manipulation Language), so destinados a consultas,
inseres, excluses e alteraes em um ou mais registros. Como exemplo de comandos da
classe DML temos os comandos Select, Insert, Update e Delete.
Existe ainda uma subclasse de comandos DML, a DCL (Data Control Language). Ela dispe
de comandos de controle como Grant e Revoke.
Outra caracterstica muito importante disponvel em SQL sua capacidade de construo de
vises, que so formas de visualizarmos os dados na forma de listagens independente das
tabelas e organizao lgica dos dados. Os comandos Commit e Rollback na linguagem SQL
79
tm a capacidade de cancelar uma srie de atualizaes ou de as gravarmos, depois de

iniciarmos uma sequncia de atualizaes.
Devemos notar que a linguagem SQL consegue implementar estas solues, somente pelo
fato de estar baseada em Banco de Dados, que garantem por si mesmo a integridade das
relaes existentes entre as tabelas e seus ndices. Vamos destacar alguns comandos:
COMMIT; Confirma a transao
R OLLBACK; Desfaz a transao
SHOW <tabela>; Mostra os nomes das tabelas existentes em determinado Banco de Dados
SHOW FIELDS FOR <tabela>; Mostra os campos de determinada tabela
SHOW INDEXES FOR <tabela>; Lista de ndices da tabela
SHOW RELATIONSHIPS FOR <tabela>; Lista os relacionamentos da tabela
LIST <tabela>; Lista contedo da tabela
http://pt.wikipedia.org/wiki/SQL
Devido importncia do SQL em Banco de Dados, recomendemos

fortemente a leitura complementar do link acima dentro do Wikipdia, e a
visita aos links recomendados.
80
NIDADE
17
Objetivo: Detalhar a sintaxe do comando SQL mais bsico de um SGBD.
Comando para Criao de um Banco de Dados

Comando Create
Este comando permite a criao de tabelas no Banco de Dados.
Sintaxe:
CREATE DATABASE < nome_db >;
onde:
nome_db - indica o nome do Banco de Dados a ser criado.
Sintaxe:
CREATE TABLE < nome_tabela >
( nome_atributo1 < tipo > [ NOT NULL ],
nome_atributo2 < tipo > [ NOT NULL ],
......
nome_atributoN < tipo > [ NOT NULL ] );
onde:
nome_table
indica o nome da tabela a ser criada.
nome_atributo
indica o nome do campo a ser criado na tabela.
tipo
indica a definio do tipo de atributo ( integer(n), char(n),
81
real(n,m), date... ).
n
nmero de dgitos ou de caracteres.
nmero de casas decimais.
Agora vamos criar nossa primeira tabela:

CREATE DATABASE TRABALHO;
O comando acima criou um Banco de Dados, porm este na verdade no passa de uma
abertura no diretrio, pois no conta com nenhuma tabela. Agora criaremos as tabelas que
estaro contidas no Banco de Dados TRABALHO.
A primeira Tabela ser a de Departamentos (Dept). Essa tabela conter, alm de campos,
tambm sua chave primria, suas chaves estrangeiras e tambm seus ndices. A segunda
tabela ser a de Empregados (EMP).
No devemos nos esquecer de primeiramente abrirmos o Banco de Dados. Diferentemente
do que ocorre em alguns aplicativos, em SQL quando criamos um Banco de Dados, no
significa que o banco recm criado j est preparado para utilizao. A instruo a seguir,
providencia a abertura do Banco de Dados:
OPEN DATABASE TRABALHO;
Agora estamos prontos para criarmos as tabelas necessrias. A seguir, entramos com o
cdigo necessrio para a criao da tabela Departamento (Dept) e seu ndice:
create table Dept
(DepNume
integer(4) not null,
DepNome
char(20) not null,
DepLoca
char(20) not null,
DepOrca
integer(12,2),
82
primary key (DepNume)

);
create unique index DepNum on Dept (DepNume asc);
Note que a chave primria j est definida juntamente com o registro da tabela. A criao do
ndice, que por razes bvias deve ser criado aps a tabela, naturalmente um comando
totalmente independente do primeiro create, que serviu para criar a tabela e suas
caractersticas bsicas.
Vamos analisar o cdigo necessrio para a criao da tabela de empregados, apresentado a
seguir:
create table Emp
(EmpNume
EmpNome
char(30) not null,
EmpGere
integer(5) ,
EmpServ
char(20) ,
DepNume
EmpAdmi
date not null,
EmpSala
integer(10,2),
EmpComi
integer(10,2),
primary key (EmpNume),

foreign key has (DepNume)
references Dept
on delete restrict
on update cascade
);
83
create unique index EmpNum on Emp (EmpNume asc);

create index EmpDep on Emp (DepNume asc);
A Tabela de Empregados no poderia ter sido criada antes da Tabela de Departamento, pois
contm uma referncia direta quela tabela. Quando declaramos que DepNume chave
estrangeira, promovemos de fato a ligao do cadastro de empregados com o cadastro de
departamentos. Ao restringirmos as excluses, permitimos a existncia de funcionrios no
alocados a nenhum departamento. Apesar de esta prtica ser contrria tese de que
devemos possuir apenas registros perfeitamente relacionveis em nossas tabelas, podemos
deixar esta pequena abertura, pois um usurio que exclusse inadvertidamente determinado
departamento, acabaria por excluir tambm uma grande quantidade de funcionrios, que
estivessem ligados a este departamento.
J a atualizao em cascata dos cdigos de departamento uma boa providncia. Uma vez
alterado algum cdigo de departamento, a atualizao ser imediata em todos os
funcionrios pertencentes ao departamento cujo cdigo foi modificado.
Observaes importantes:
Observar que os ndices so partes intrnsecas das tabelas.
A integridade relacional garantida pelo Banco de Dados e no pelo aplicativo.
Excluses ou Alteraes em Chaves Primrias podem acarretar excluses, anulaes ou at
mesmo perda de integridade nas tabelas onde esta chave primria existir como chave
estrangeira.
Portanto, imprescindvel muito cuidado quando da elaborao de um Banco de Dados.
Uma tentao muito comum dos novatos comear criando as tabelas do Banco de Dados
sem utilizar a Normalizao. Este talvez seja o melhor caminho para perder tempo em vo,
pois quando voc terminar de projetar suas telas de entrada de dados, notar "que nada
funciona!".
84
Comando DROP
Este comando elimina a definio da tabela, seus dados e referncias.
Sin taxe:
DROP TABLE < nome_tabela > ;
Exemplo: DROP TABLE EMP;
http://pgdocptbr.sourceforge.net/pg80/sql-createtableas.html
Nos links acima estamos verificando o mesmo comando em dois

conhecidos Bancos de Dados. Existem diferenas significativas?
85
NIDADE
18
Objetivo:.Verificar e exemplificar o comando SQL mais importante em Banco de Dados.
Comando SELECT para Consulta de Tabelas

Devemos ressaltar que a linguagem SQL utilizada tanto por profissionais responsveis
pelos dados, onde ressaltada principalmente pela figura do Administrador do Banco de
Dados, como tambm pelos desenvolvedores de aplicaes. Enquanto aqueles esto
preocupados com o desempenho, integridade do Banco de Dados e utilizam toda gama de
recursos disponveis no SQL, estes ltimos esto preocupados em "transformar dados em
informaes". Portanto, para os desenvolvedores costuma-se dizer que conhecer o SELECT j
basta, devido importncia e o potencial desse comando. Devido importncia deste
comando, vamos ensin-lo didaticamente atravs de vrios exerccios que comeam de
forma bem simples, at os mais complexos.
Exemplo 1 - Selecione todos os campos (ou colunas) da tabela de Departamentos.
RESPOSTA:
SELECT * FROM DEPT;
O exemplo acima utiliza o coringa "*" para selecionar as colunas na ordem em que foram
criadas. A instruo Select, como podemos observar, seleciona um grupo de registros de
uma ou mais tabela(s). No caso a instruo From nos indica a necessidade de pesquisarmos
tais dados apenas na tabela Dept.
Where como base das Restries de registros
A clusula where corresponde ao operador restrio da lgebra relacional. Contm a
condio que os registros devem obedecer a fim de serem listadas. Ela pode comparar
valores em colunas, literais, expresses aritmticas ou funes.
86
A seguir apresentamos operadores lgicos e complementares a serem utilizados nas

expresses apresentadas em where.
Operadores lgicos
operador
Significado
igual a
>
maior que
>=
maior que ou igual a
<
menor que
<=
menor que ou igual a
Exemplos:
SELECT EMPNOME, EMPSERV
FROM EMP
WHERE DEPNUME > 10;
FROM EMP
WHERE EMPSERV = 'GERENTE';
O conjunto de caracteres ou datas deve estar entre apstrofes () na clusula WHERE.
Exemplo 2 - Selecione todos os departamentos cujo oramento mensal seja maior que
100000. Apresente o Nome de tal departamento e seu oramento anual, que ser obtido
multiplicando-se o oramento mensal por 12.
87
RESPOSTA: Neste problema precisamos de uma expresso que a combinao de um ou

mais valores, operadores ou funes que resultaro em um valor. Esta expresso poder
conter nomes de colunas, valores numricos, constantes e operadores aritmticos.
SELECT DEPNOME, DEPORCA * 12
FROM DEPT
WHERE DEPORCA > 100000;
Exemplo 3 - Apresente a instruo anterior, porm ao invs dos nomes "feios" DepNome e
DepOrca, os Ttulos Departamento e Oramento.
RESPOSTA: Neste exemplo deveremos denominar colunas por apelidos. Os nomes das
colunas mostradas por uma consulta so geralmente os nomes existentes no Dicionrio de
Dados. Porm, geralmente esto armazenados na forma do mais puro "informatiqus", onde
"todo mundo" sabe que CliCodi significa Cdigo do Cliente. possvel (e provvel) que o
usurio desconhea estes smbolos, portanto devemos os apresentar dando apelidos s
colunas "contaminadas" pelo informatiqus, que apesar de fundamental para os analistas,
somente so vistos como enigmas para os usurios.
SELECT DEPNOME "DEPARTAMENTO", DEPORCA * 12 "ORCAMENTO ANUAL"
FROM DEPT
WHERE DEPORCA > 100000;
Exemplo 4 - Apresente todos os salrios existentes na empresa, porm omita eventuais

duplicidades.
RESPOSTA: A clusula DISTINCT elimina duplicidades, significando que somente relaes
distintas sero apresentadas como resultado de uma pesquisa.
SELECT DISTINCT EMPSERV
88
FROM EMP;
Exemplo 5 - Apresente todos os dados dos empregados, considerando sua existncia fsica
diferente de sua existncia lgica (ou seja, devidamente inicializado).
RESPOSTA: Desejamos um tratamento diferenciado para valores nulos. Qualquer coluna de
um registro que no contenha informaes denominada de nula, portanto informao no
existente. Isto no o mesmo que "zero", pois zero um nmero como outro qualquer,
enquanto que um valor nulo utiliza um "byte" de armazenagem interna e so tratados de
forma diferenciada pelo SQL.
SELECT EMPNOME, EMPSALA + EMPCOMI
FROM EMP;
SELECT EMPNOME, NVL(EMPSALA,0) + NVL(EMPCOMI,0)
FROM EMP;
Obs: a funo "NVL" utilizada para converter valores nulos em zeros.
http://www.htmlstaff.org/postgresqlmanual/sql-select.html
http://www.hospedia.com.br/artigos/10/mysql/1/mysql_basico__o_comando_select_-_realizando_consultas.html
Resolva os exerccios apresentados nessa Unidade, sem ver as respostas,

e veja quanto voc acerta!!
89
NIDADE
19
Objetivo: Explorar com maior profundidade o comando SELECT.
Clusula e Operadores usados no Comando SELECT

Vimos na unidade anterior que na linguagem SQL temos o importante comando SELECT para
consulta de registros de uma tabela num Banco de Dados. Porm, se queremos consultas
mais complexas, teremos que usar algumas clusulas e/ou operadores junto com o comando
SELECT. Por exemplo, a clusula ORDER BY modificar a ordem de apresentao do resultado
da pesquisa de forma ascendente ou descendente.

Exemplo 6 - Liste os nomes e cargos da cada funcionrio contidos na tabela empresa (EMP),
porm classificados alfabeticamente (A.. Z) e depois alfabeticamente invertido (Z..A).
RESPOSTA:
SELECT FUN_NOME, FUN_CARG
FROM EMP
ORDER BY FUN_NOME;
FROM EMP
ORDER BY EMPPNOME DESC;
NOTA: Tambm possvel fazer com que o resultado da pesquisa venha classificado por
vrias colunas. Sem a clusula ORDER BY as linhas sero exibidas na sequncia que o SGBD
determinar.
Exemplo 7 - Selecione os Nomes dos Departamentos que estejam na fbrica.

90
RESPOSTA:
SELECT DEPNOME
FROM DEPT
WHERE DEPLOCA = "SAO PAULO";
O exemplo exigiu uma restrio (So Paulo) que nos obrigou a utilizar na instruo WHERE.
Demais Operadores
Operador
Significado
BETWEEN ... AND ...
entre dois valores ( inclusive )
IN ( .... )
lista de valores
LIKE
com um padro de caracteres
IS NULL
um valor nulo
Exemplos:
SELECT EMPNOME, EMPSALA
FROM EMP
WHERE EMPSALA BETWEEN 500 AND 1000;
SELECT EMPNOME, DEPNUME

FROM EMP
WHERE DEPNUME IN (10,30);
91
FROM EMP
WHERE EMPNOME LIKE 'F%';

FROM EMP
WHERE EMPCOMI IS NULL;
O smbolo "%" pode ser usado para construir a pesquisa ("%" = qualquer sequncia de
nenhum at vrios caracteres).
Operadores Negativos
Operador
descrio
<>
diferente
NOT NOME_COLUNA =
diferente da coluna
NOT NOME_COLUNA >
no maior que
NOT BETWEEN
no entre dois valores informados
NOT IN
no existente numa dada lista de valores
NOT LIKE
diferente do padro de caracteres informado
IS NOT NULL
no um valor nulo
Exemplo 8 - Selecione os Empregados cujos salrios sejam menores que 1000 ou maiores
que 3500.
92
RESPOSTA: Necessitaremos aqui
a utilizao de expresso negativa. A seguir
apresentamos operadores negativos.

SELECT EMPNOME, EMPSALA
FROM EMP
WHERE EMPSALA NOT BETWEEN 1000 AND 3500;
Exemplo 9 - Apresente todos os funcionrios com salrios entre 200 e 700 e que sejam
Vendedores.
RESPOSTA: Necessitaremos de consultas com condies mltiplas. Operadores AND (E) e
OR (OU).
SELECT EMPNOME, EMPSALA, EMPSERV
FROM EMP
WHERE EMPSALA BETWEEN 700 AND 2000
AND EMPSERV = 'VENDEDOR';
Exemplo 10 - Apresente todos os funcionrios com salrios entre 200 e 700 ou que sejam
Vendedores.
RESPOSTA:
FROM EMP
OR EMPSERV = 'VENDEDOR';
93
Exemplo 11 - Apresente todos os funcionrios com salrios entre 200 e 700 e que sejam
Vendedores ou Balconistas.
RESPOSTA:
FROM EMP
AND ( EMPSERV = 'BALCONISTA' OR EMPSERV = 'VENDEDOR' );
Funes de Caracteres
Lower
Fora caracteres maisculos aparecerem em minsculos
Upper
Fora caracteres minsculos aparecerem em maisculos
Concat(x,y)
Concatena a string "x" com a string "y"
Substring(x,y,str)
Extrai um substring da string "str", comeando em "x", e termina em "y"
To_Char(num)
Converte um valor numrico para uma string de caracteres
To_Date(char,fmt)
Converte uma string caracter em uma data
^Q
Converte data para o formato apresentado
Exemplo 12 - Apresente o nome de todos os empregados em letras minsculas.

RESPOSTA:
SELECT LOWER( EMPNOME )
94
FROM EMP;
Exemplo 13 - Apresente o nome de todos os empregados (somente as 10 primeiras letras).

RESPOSTA:
SELECT SUBSTRING (1,10,EMPNOME)
FROM EMP;
Exemplo 14 - Apresente o nome de todos os empregados admitidos em 01/01/80.

RESPOSTA:
SELECT *
FROM EMP
WHERE EMPADMI = ^Q"DD-AAA-YYYY"("01-JAN-1980");
ou
SELECT *
FROM EMP
WHERE EMPADMI = ^Q("01-JAN-1980");
http://pgdocptbr.sourceforge.net/pg80/sql-select.html
95

96
NIDADE
20
Objetivo: Explorar mais recursos do complexo comando SELECT.
Funes Agregadas e a Clusula HAVING

Funes Agregadas (ou de Agrupamento)
Funo
Retorno
avg(n)
Mdia do valor n, ignorando nulos
count(expr)
Vezes que o nmero da expr avalia para algo no nulo
max(expr)
Maior valor da expr
min(expr)
Menor valor da expr
sum(n)
Soma dos valores de n, ignorando nulos
Exemplo 15 - Apresente a Mdia, o Maior, o Menor e tambm a Somatria dos Salrios

pagos aos empregados.
RESPOSTA:
SELECT AVG(EMPSALA) FROM EMP;
SELECT MIN(EMPSALA) FROM EMP;
SELECT MAX(EMPSALA) FROM EMP;
SELECT SUM(EMPSALA) FROM EMP;
Agrupamentos
97
As funes de grupo operam sobre grupos de registros (linhas). Retornam resultados

baseados em grupos em vez de resultados de funes por registro individual. A clasula
GROUP BY do comando SELECT utilizada para dividir registros em grupos menores.
A clusula GROUP BY pode ser usada para dividir os registros de uma tabela em grupos
menores. As funes de grupo devolvem uma informao sumarizada para cada grupo.
Exemplo 16 - Apresente a mdia de salrio paga por departamento.

RESPOSTA:
SELECT DUPNUME, AVG(EMPSALA)
FROM EMP
GROUP BY DEPNUME;
Obs.: Qualquer coluna ou expresso na lista de seleo, que no for uma funo agregada,
dever constar da clasula GROUP BY. Portanto errado tentar impor uma "restrio" do tipo
agregada na clusula WHERE.
Clusula HAVING
A clusula HAVING pode ser utilizada para especificar quais grupos devero ser exibidos,
portanto restringindo-os.
Exemplo 17 - Retome o problema anterior, porm apresente resposta apenas para

departamentos com mais de 10 empregados.
RESPOSTA:
SELECT DEPNUME, AVG(EMPSALA)
FROM EMP
98
GROUP BY DEPNUME
HAVING COUNT(*) > 10;
Obs.: A clasula GROUP BY deve ser colocada antes da HAVING, pois os grupos so formados
e as funes de grupos so calculadas antes de se resolver a clusula HAVING. E a clusula
WHERE no pode ser utilizada por restringir grupos que devero ser exibidos.
Exemplificando ERRO tpico - Restringindo Mdia Maior que 1000:

FROM EMP
WHERE AVG(SALARIO) > 1000
GROUP BY DEPNUME;
( Esta seleo est ERRADA! )

FROM EMP
GROUP BY DEPNUME
HAVING AVG(EMPSALA) > 1000;
( Seleo Adequada )
Sequncia no comando SELECT:

SELECT
FROM
coluna(s)
tabela(s)
99
WHERE
Condio(es) do(s) registro(s)
GROUP BY
Condio(es) do(s) grupo(s) de registro(s)
HAVING
Condio(es) do(s) grupo(s) de registro(s)
ORDER BY
Coluna(s);
O SQL far a seguinte avaliao:

a) WHERE, para estabelecer tuplas individuais candidatas (no pode conter funes de grupo)
b) GROUP BY, para fixar grupos.
c) HAVING, para selecionar grupos para exibio.
http://www.imasters.com.br/artigo/241
Antes de dar continuidade aos seus estudos fundamental que voc

entre no site da ESAB e, em sua Sala de Aula, faa a Atividade 2, no link
Atividades.
100
NIDADE
21
Objetivo: Explorar os comandos SQL que trabalham com relacionamentos em SGBD.
Relacionamentos, sub-consulta e unio

Equi-Juno (Juno por igualdade)
O relacionamento existente entre tabelas chamado de equi-juno, pois os valores das
colunas das duas tabelas so iguais. A Equi-juno possvel apenas quando tivermos
definido de forma adequada a chave estrangeira de uma tabela e sua referncia a chave
primria da tabela precedente.
Apesar de admitir-se em alguns casos, a equi-juno de tabelas, sem a correspondente
Chave Primria-Chave Estrangeira, recomendamos fortemente a no utilizao desse tipo de
construo.
Exemplo 18 - Listar Nomes de Empregados, Cargos e Nome do Departamento onde o

empregado trabalha.
RESPOSTA:
Observemos que dois dos trs dados solicitados esto na Tabela Emp, enquanto o outro
dado
est
na
Tabela
Dept.
Deveremos
ento
acessar
os
dados
restringindo
convenientemente as relaes existentes entre as tabelas.

De fato, sabemos que DEPNUME chave primria da tabela de Departamentos e tambm
chave estrangeira da Tabela de Empregados. Portanto, este campo ser o responsvel pela
equi-juno.
SELECT A.EMPNOME, A.EMPSERV, B.DEPNOME
101
FROM EMP A, DEPT B

WHERE A.DEPNUME = B.DEPNUME;
OBSERVAO: Note que as tabelas quando contm colunas com o mesmo nome, usa-se
um apelido (ALIAS) para substituir o nome da tabela associado coluna. Imagine que algum
tivesse definido NOME para ser o Nome do Empregado na Tabela de Empregados e tambm
NOME para ser o Nome do Departamento na Tabela de Departamentos. Tudo funcionaria de
forma adequada, pois o ALIAS se encarregaria de evitar que uma ambiguidade fosse
verificada.
Embora SQL resolva de forma muito elegante o problema da nomenclatura idntica para
campos de tabelas, recomendamos fortemente evitar tal forma de nomear os campos. O
SQL nunca confundir um A.NOME com um B.NOME, porm podemos afirmar o mesmo de
ns mesmos?
Exemplo 19 - Liste os Cdigos do Cada Funcionrio, seus Nomes, seus Cargos e o nome do
Gerente ao qual este se relaciona.
RESPOSTA:
Precisamos criar um auto-relacionamento, ou seja, juntar uma tabela a ela prpria.
possvel juntarmos uma tabela a ela mesma com a utilizao de apelidos (permitindo juntar
registros da tabela a outros registros da mesma tabela).
SELECT A.EMPNUME, A.EMPNOME, A.EMPSERV, B.EMPNOME
FROM EMP A, EMP B
WHERE A.EMPGERE = B.EMPNUME;
102
SubConsultas
Uma subconsulta um comando SELECT que aninhado dentro de outro SELECT e que
devolve resultados intermedirios.
Exemplo 20 - Relacione todos os nomes de funcionrios e seus respectivos cargos, desde

que o oramento do departamento seja igual a 300.000
RESPOSTA:
FROM EMP A
WHERE 300000 IN ( SELECT DEPORCA
FROM DEPT
WHERE DEPT.DEPNUME = A.DEPNUME );
NOTA: Observe que a clusula IN torna-se verdadeira quando o atributo indicado est
presente no conjunto obtido atravs da subconsulta.
Exemplo 21 - Relacione todos os departamentos que possuem empregados com

remunerao maior que 3.500
RESPOSTA:
SELECT DEPNOME
FROM DEPT A
WHERE EXISTS (SELECT *
FROM EMP
WHERE EMPSALA > 3500 AND EMP.DEPNUME = A.DEPNUME');
103
NOTA: Observe que a clusula EXISTS indica se o resultado de uma pesquisa contm ou no
registros. Observe tambm que poderemos verificar a no existncia (NOT EXISTS), caso esta
alternativa seja mais conveniente.
Unies
Podemos eventualmente unir duas linhas de consultas simplesmente utilizando a palavra
reservada UNION.
Exemplo 22 - Liste todos os empregados que tenham cdigos > 10 ou Funcionrios que
trabalhem em departamentos com cdigo maior que 10.
RESPOSTA:
Poderamos resolver esta pesquisa com um nico SELECT, porm devido ao fato de estarmos
trabalhando, em nosso exemplo, com apenas duas tabelas, no conseguimos criar um
exemplo mais adequado para utilizao deste recurso.
(SELECT *
FROM EMP
WHERE EMPNUME > 10)
UNION
(SELECT *
FROM EMP
WHERE DEPNUME > 10);
104
www.j soares.net/CEFET/BD/apostilaSQL.pdf

105
NIDADE
22
Objetivo: Estudar os comandos SQL responsveis por manipulaes em tabelas.
Inseres, Alteraes e Excluses em Tabelas

Uma linguagem direcionada a extrao de informaes de um conjunto de dados no deveria
incorporar comandos de manipulao de tabelas. No entanto, a mera existncia de uma
linguagem padronizada para acesso a dados "convida" os desenvolvedores a aderirem a
uma linguagem "padro" de manipulao de tabelas. E naturalmente cada fabricante coloca
"um algo mais" em seu SQL (SQL PLUS, SQL *, ISQL, e toda sorte de nomenclaturas).
Isso por um lado, desvirtua os objetivos da linguagem (padronizao absoluta), mas em
contrapartida, otimiza os acessos ao Banco de Dados. E por maior que sejam essas
mudanas, no chegam a impedir que um programador versado em SQL tenha grandes
dificuldades em se adaptar ao padro de determinada implementao.
De fato as diferenas entre o SQL da Sybase, Oracle, Microsoft, so muito menores dos que
as existentes entre as linguagens "irms": C, BASIC e o Pascal (todas com origem conceitual
do FORTRAN). Podemos observar que todas as trs linguagens mencionadas possuem
estruturas de controle, blocos de instruo, regras semelhantes para declarao de variveis
e usam comandos de tomada deciso, porm apesar de tantas semelhanas, praticamente
impossvel que um programador excelente em uma linguagem consiga em curto espao de
tempo ser excelente em outra linguagem.
O mesmo no ocorrer com um especialista em SQL, ao migrar de um SGBD para outro.
Naturalmente existir a necessidade de algum aprendizado, mas o programador poder ir
adaptando-se aos poucos sem precisar ser re-treinado, o que um aspecto extremamente
vantajoso para as empresas e para os prprios profissionais.
106
Inserir (INSERT)
INSERT INTO <tabela> [<campos>] [VALUES <valores>]
Exemplos:
INSERT INTO DEPT;
Possibilita a insero de registros de forma interativa.

INSERT INTO DEPT (DEPNUME,DEPNOME,DEPLOCA) VALUES (70,"PRODUCAO","RIO DE JANEIRO");
Possibilita a insero de registros em tabelas sem digitao dos dados.

Atualizar (UPDATE)
UPDATE <tabela> SET <campo> = <expresso> [WHERE <condio>];
Exemplo:
UPDATE EMP SET EMPSALA = EMPSALA* 1.2 WHERE EMPSALA< 1000;
Excluir (DELETE)
DELETE FROM <tabela> [WHERE <condio>];
Exemplo:
DELETE FROM emp WHERE EMPSALA > 5000;
Transaes
Muitas vezes gostaramos que determinado processo, caso fosse abortado por qualquer
motivo, pudesse ser inteiramente cancelado. Imaginemos por exemplo um usurio digitando
um pedido. Imaginemos ainda que o sistema possa reservar cada item solicitado de maneira
107
"on-line", ou seja, ao mesmo tempo em que se est digitando a quantidade, o sistema j

"empenhe" uma quantidade equivalente no estoque. Imaginemos ainda que o sistema deva
cancelar todas as operaes se apenas um dos itens no puder ser atendido. Seria um
grande problema, caso no pudssemos anular todos os processos a partir de determinada
condio.
Vamos simular tal ocorrncia com nosso Banco de Dados EMP. Imaginemos que ao invs de
digitarmos DELETE FROM emp WHERE salrio > 5000; tivssemos digitado DELETE FROM
emp WHERE salrio > 500; Ao invs de eliminarmos 2 registros, praticamente teramos
eliminado o Banco de Dados todo. Para evitarmos que um erro de digitao, ou um processo
iniciado, porm sem condio de ser completado integralmente, comprometa todos nossos
dados, podemos criar uma transao que nos assegurar que nossos testes sejam bem
sucedidos ou cancelados sem comprometer os dados.
begin transaction;
delete from emp where salario > 500;
if SQL_RECORDCOUNT > 20 THEN;
ROLLBACK TRASACTION;
else
COMMIT;
endif;
end transaction;
Vises (VIEW)
Uma viso consiste basicamente de uma tabela derivada de outras tabelas. Considerando o
exemplo TRABALHO, poderamos criar uma viso baseada na tabela de Empregados (EMP)
e na tabela de Departamentos (DEPT) onde tivssemos somente os Nomes dos
Funcionrios e os Departamentos nos quais estes trabalhassem. Teramos algo assim:
108
CREATE VIEW EMP_DEP

AS SELECT E.EMPNOME, D.DEPNOME
FROM EMP E, DEPT D
WHERE E.DEPNUME = D.DEPNUME;
Devemos observar que:

1.Uma viso definida sobre uma nica tabela somente ser atualizvel se os atributos da tal
viso contiverem a chave primria.
2.Vises sobre vrias tabelas no so passveis de atualizaes.
3.Vises que se utilizam de funes de agrupamentos, tambm no podero ser atualizadas.
http://pt.wikipedia.org/wiki/CRUD
http://pgdocptbr.sourceforge.net/pg80/rules-update.html
Com o link do Wikipdia, referenciado no Estudo Complementar, verifique

se todos os comandos abordados nesta unidade esto no acrnimo CRUD.
109
NIDADE
23
Objetivo: Entender a sintaxe do comando SQL responsvel em gerar relatrios.
Relatrios comando REPORT

Sintaxe:
REPORT DISTINCT / UNIQUE
[ atributo(s) ]
REPORTTOP
PAGETOP
TOP
DETAIL
NONE
BOTTOM
PAGEBOTTOM
REPORTBOTTOM
FROM [ tabela(s) ]
[ WHERE clausula-where ]
[ GROUP BY clausula-grupo ]
[ ORDER BY clausula-order by ];
Como exemplo, converteremos um simples Select em um Report:

SELECT EMPNOME
REPORT
110
FROM EMP
DETAIL EMPNOME
WHERE DEPNUME = 1000;
WHERE DEPNUME = 1000;
Podemos direcionar a sada de um relatrio tanto para um arquivo como para uma
impressora.
Para um arquivo:
REPORT ON RELAT.DAT ...
Para uma impressora:

REPORT ON LP: ...
Agora vamos incrementar mais o REPORT (veja na prxima folha):

REPORT
REPORTTOP COL 10, *** RELATORIO DE FUNCIONARIOS *** ,
TODAY %QDD/MM/YY, SKIP,
COL 10, =================================, SKIP 2
DETAIL COL 10, NOME %C22, SALARIO %FS, ADMISSAO %QDD/MM/YY
REPORTBOTTOM COL 10,
=================================, SKIP,
COL 20, TOTAL:, TOTAL(SALARIO)
FROM EMP
ORDER BY NOME;
Onde:
111
REPORTTOP
O que ser impresso no topo do relatrio
PAGETOP
Impresso em cada topo de pgina
TOP
Impresso em cada topo do Sort (Grupo do Relatrio)
DETAIL
O que ser impresso em cada linha
NONE
Se o select no tiver resultado, no ser impresso o relatrio
BOTTOM
Impresso em cada rodap do Sort (Grupo do relatrio)
PAGEBOTTOM
O que ser impresso no rodap de cada pgina
REPORTBOTTOM
O que ser impresso no rodap do relatrio
Formatos
Tipos
%C
caracter
%D
data
ano
ms numrico
ms alfanumrico
dia
dia e ano Juliano
Exemplo: %Ddd/mm/yy
%I
inteiro
%F
ponto flutuante
112
%FSZ
onde: S - separador de 3 dgitos e decimal point e

Z - zeros sero suprimidos
%Q
Data
%J
Hora
Hora
Minutos
Segundos
%T
Hora
E temos as funes: TOTAL, AVERAGE, MAXIMUM, MINIMUM.
http://www.activedelphi.com.br/modules.php?op=modload&name=News&fil
e=article&sid=53&mode=thread&order=0&thold=0
Com base no link do Estudo Complementar, aproveite para fazer um bom

resumo de tudo o que j vimos at agora de comandos SQL.
113
NIDADE
24
Objetivo: Estudar como definir privilgios especficos conforme as necessidades dos usurios
Privilgios de Acesso GRANT e REVOKE
Como a grande maioria dos Bancos de Dados Relacionais pode ser acessada por diversos
usurios, cada um possui necessidade especfica 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 algum usurio, a linguagem SQL permite a definio de privilgios que cada um
pode ter em relao s tabelas. Os privilgios garantem a segurana e a integridade dos
dados, bem como a responsabilidade de cada usurio sobre seus dados especficos.
1.Comando GRANT (garantir)
Quando uma tabela/view criada, o nome do usurio que a criou anexado, internamente,
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:
GRANT {ALL | Lista de privilgios}
ON {nome da tabela/view (lista de colunas)}
TO {PUBLIC | Lista de usurios}
[WITH GRANT OPTION]
114
A palavra ALL indica que esto sendo dados TODOS privilgios, ou ento especificamos qual
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
privilgio.
Dica: Somente pode ser utilizada uma tabela ou view por comando.
Os privilgios podem ser especificados para algumas colunas, porm devem ser todas 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 passe esse privilgio para os outros usurios.
Lista de opes de privilgios:
Select
Pode executar uma consulta sobre a tabela
Insert
Pode executar uma insero sobre a tabela
Delete
Pode apagar registros da tabela
Update
Pode modificar registros da tabela
All privileges / all Pode executar qualquer operao sobre a tabela

<usurio>
Nome do usurio que vai receber os privilgios
PUBLIC
Concede privilgios a todos os usurios do ambiente
Exemplos:
Permite somente consultas ao usurio Jorge sobre a tabela Produto.
GRANT Select
ON Produto
TO Jorge;
115
Concede ao usurio Gilmar, os privilgios de seleo, insero e alterao sobre a tabela

Pedido.
GRANT Select, Insert, Update
ON Pedido
TO Gilmar;
Permite todos os privilgios a todos os usurios sobre a tabela Cliente.

GRANT All privileges
ON Cliente
TO PUBLIC;
Concede aos usurios Felipe e Carlos, o privilgio de seleo sobre a tabela Cliente.
GRANT Select
ON Cliente
TO Felipe, Carlos;
Disponibilizar para seleo, somente os campos cdigo de vendedor e nome de vendedor da

tabela Vendedor a todos os usurios.
GRANT Select (Ven_Codi, Ven_nome)
ON Vendedor
TO PUBLIC;
Conceder ao usurio Jorge o poder de permitir a concesso de todos os privilgios a outros

usurios sobre a tabela PEDIDO.
GRANT ALL
ON Pedido
TO Jorge
116
WITH GRANT OPTION;
2.Comando REVOKE (revogao)

Da mesma forma que o criador da tabela pode garantir os privilgios de acesso aos outros
usurios (GRANT), ele pode revogar esses privilgios por meio do comando REVOKE.
Sintaxe:
REVOKE [Lista de privilgios]
ON [nome da tabela / view]
FROM [Lista de usurios]
Retirar o privilgio de seleo sobre a tabela Produto do usurio Carlos.

REVOKE select
ON Produto
From Carlos;
Revogar todos os privilgios concedidos a todos os usurios sobre a tabela Cliente.

REVOKE select
ON Cliente
FROM PUBLIC;
Retirar os privilgios de atualizao e insero concedidos ao usurio Felipe sobre a tabela

Pedido.
REVOKE Insert, Update
ON Pedido
FROM Felipe;
117
http://dev.mysql.com/doc/refman/4.1/pt/grant.html
http://www.htmlstaff.org/postgresqlmanual/sql-grant.html
http://www.htmlstaff.org/postgresqlmanual/sql-revoke.html
Com base nos Manuais de Referncia do MySQL, e do PostgreSQL, vistos

no Estudo Complementar, veja a diferena que possa existir.
118
NIDADE
25
Objetivo: Definir ndices e estratgias para a sua melhor utilizao.
Trabalhando 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 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. Por intermdio dos ponteiros se localiza em que linha o valor desejado est
armazenado. As tabelas de ndices so utilizadas internamente pelo SGBD, ficando
totalmente transparente ao usurio.
Quando vamos criar ndices e colunas, devemos considerar:
Criar ndice sobre valores que vamos pesquisar com frequncia.
Indexe suas chaves estrangeiras quando precisar fazer consultas mais eficientes e rpidas.
As colunas que so regularmente utilizadas em consultas devem ser indexadas porque o
sistema pode otimizar estas consultas, deixando-as mais rpidas.
Crie ndice sempre em colunas que so pesquisadas por um intervalo de valores.
E por fim, crie ndice sempre em colunas que so utilizadas em clusulas WHERE.
Criando ndices
119
Cada ndice aplicado a uma tabela, especificando uma ou mais colunas dessa tabela.
ndices so criados por meio do comando CREATE INDEX, que cria um ndice sobre colunas
de uma tabela.
Sintaxe:
CREATE [UNIQUE] INDEX <nome do ndice>
ON <nome da tabela> (<coluna(s)>);
A clusula UNIQUE opcional e define para aquela coluna no existiro 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, no pode
ser NULA.
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 consulta.
Para cada SGBD existem clusulas especficas operacionais que devem ser usadas, mas
neste caso vamos apresentar a sintaxe padro geral do SQL ANSI.
Exemplos:
Cria a tabela de ndices chamada nome_pro baseada no campo nome_produto da tabela
Produto.
CREATE INDEX nome_pro
ON Produto (nome_produto);
Cria a tabela de ndices ped_pro baseada na concatenao dos campos num_pedido e

cod_produto da tabela item_pedido
CREATE INDEX ped_pro
120
ON item_pedido (num_pedido, cod_produto);
importante considerar que praticamente todas as sintaxes em se tratando de SGBDs

relacionais exigem que se identifique o database proprietrio da tabela, principalmente no
Microsoft SQL Server.
Cria o ndice nico para a tabela Cliente baseada no cdigo do cliente, no podendo haver
duplicidade de informao armazenada.
CREATE UNIQUE INDEX cliente_ind
ON [nome do database] cliente (cod_cliente);
Eliminando ndices
Da mesma forma que um ndice criado, ele pode ser eliminado, dependendo das
necessidades do projeto do Banco de Dados.
Sintaxe:
DROP INDEX <nome do ndice>;
Exemplos:
Elimina o ndice que foi criado para o nome do produto
DROP INDEX nome_pro;
Elimina o ndice criado para o cdigo do cliente

DROP INDEX cod_cliente;
121
http://www.htmlstaff.org/postgresqlmanual/sql-createindex.html
http://www.htmlstaff.org/postgresqlmanual/sql-dropindex.html
Ao consultar o Manual de Referncia do PostgreSQL citado no Estudo

Complementar, compare com a sintaxe apresentada nesta unidade.
122
NIDADE
26
Objetivo: Rever comandos SQL e os especficos de outros SGBDs.
Resumo dos Comandos SQL

Esta Unidade contm informaes de referncia para os comandos SQL e tambm aqueles
suportados pelo PostgreSQL (ver mais detalhes na Unidade 30).
Table of Contents
ABORT -- aborta a transao corrente
ALTER GROUP -- inclui ou exclui usurios em um grupo
ALTER TABLE -- altera a definio da tabela
ALTER USER -- altera a conta de um usurio do Banco de Dados
ANALYZE -- coleta estatsticas sobre um Banco de Dados
BEGIN -- inicia um bloco de transao
CHECKPOINT -- fora um ponto de controle no log de transao
CLOSE -- fecha o cursor
CLUSTER -- agrupa uma tabela de acordo com um ndice
COMMENT -- cria ou altera o comentrio de um objeto
COMMIT -- efetiva a transao corrente
COPY -- copia dados entre arquivos e tabelas
CREATE AGGREGATE -- define uma nova funo de agregao
123
CREATE CONSTRAINT TRIGGER -- define um novo gatilho de restrio

CREATE DATABASE -- cria um Banco de Dados novo
CREATE FUNCTION -- define uma nova funo
CREATE GROUP -- define um novo grupo de usurios
CREATE INDEX -- define um ndice novo
CREATE LANGUAGE -- define uma nova linguagem procedural
CREATE OPERATOR -- define um novo operador
CREATE RULE -- define uma nova regra
CREATE SEQUENCE -- define um novo gerador de sequncia
CREATE TABLE -- define uma nova tabela
CREATE TABLE AS -- cria uma nova tabela a partir do resultado de uma consulta
CREATE TRIGGER -- define um novo gatilho
CREATE TYPE -- define um novo tipo de dado
CREATE USER -- define uma nova conta de usurio do Banco de Dados
CREATE VIEW -- define uma nova viso
DECLARE -- define um cursor
DELETE -- exclui linhas de uma tabela
DROP AGGREGATE -- remove uma funo de agregao definida pelo usurio
DROP DATABASE -- remove um Banco de Dados
DROP FUNCTION -- remove uma funo definida pelo usurio
DROP GROUP -- remove um grupo de usurios
124
DROP INDEX -- remove um ndice

DROP LANGUAGE -- remove uma linguagem procedural definida pelo usurio
DROP OPERATOR -- remove um operador definido pelo usurio
DROP RULE -- remove uma regra
DROP SEQUENCE -- remove uma sequncia
DROP TABLE -- remove uma tabela
DROP TRIGGER -- remove um gatilho
DROP TYPE -- remove um tipo de dado definido pelo usurio
DROP USER -- remove uma conta de usurio do Banco de Dados
DROP VIEW -- remove uma viso
END -- efetiva a transao corrente
EXPLAIN -- mostra o plano de execuo de uma instruo
FETCH -- busca linhas de uma tabela usando um cursor
GRANT -- define privilgios de acesso
INSERT -- cria novas linhas na tabela
LISTEN -- escuta uma notificao
LOAD -- carrega ou recarrega um arquivo de biblioteca compartilhada
LOCK -- bloqueia explicitamente uma tabela
MOVE -- posiciona o cursor em uma determinada linha da tabela
NOTIFY -- gera uma notificao
REINDEX -- reconstroi ndices corrompidos
125
RESET -- atribui a um parmetro de tempo de execuo o seu valor padro

REVOKE -- revoga privilgios de acesso
ROLLBACK -- aborta a transao corrente
SELECT -- retorna linhas de uma tabela ou de uma viso
SELECT INTO -- cria uma nova tabela a partir do resultado de uma consulta
SET -- muda um parmetro de tempo de execuo
SET CONSTRAINTS -- especifica o modo de restrio da transao corrente
SET SESSION AUTHORIZATION -- define o identificador do usurio da sesso e o identificador
do usurio corrente, da sesso corrente.

SET TRANSACTION -- define as caractersticas da transao corrente
SHOW -- mostra o valor de um parmetro de tempo de execuo
TRUNCATE -- esvazia a tabela
UNLISTEN -- pra de escutar uma notificao
UPDATE -- atualiza linhas de uma tabela
VACUUM -- limpa e opcionalmente analisa o Banco de Dados
http://www.htmlstaff.org/postgresqlmanual/index.html
126
Navegue pelo site da PostgreSQL, e revise os principais comandos SQL.
127
NIDADE
27
Objetivo: Aprender as tcnicas bsicas de otimizao das consultas SQL.
Otimizar Consultas SQL

Existem diferentes formas de otimizar as consultas realizadas em SQL. A linguagem SQL
no procedimental, ou seja, nas sentenas se indica o que queremos conseguir e no como.
Isso seria na teoria, pois na prtica todos os gerenciadores de SQL tm que especificar seus
prprios truques para otimizar o rendimento.
Portanto, se quisermos que o tempo de resposta seja o mnimo, no basta especificar uma
sentena SQL correta, e sim indicar como tem que fazer. Nesta seo, veremos como
melhorar o tempo de resposta de nosso intrprete ante as determinadas situaes:
Design de tabelas
Normalize as tabelas, pelo menos at a terceira forma normal, para garantir que no haja
duplicidade de dados. Se tiver que desnormalizar alguma tabela pense na ocupao e no
rendimento antes de proceder.
Os primeiros campos de cada tabela devem ser aqueles campos requeridos, e primeiro se
definem os de longitude fixa e depois os de longitude varivel. Ajuste ao mximo o tamanho
dos campos para no desperdiar espao. normal deixar um campo de texto para
observaes nas tabelas. Se este campo for utilizado com pouca frequncia ou se for
definido com grande tamanho, por via das dvidas, melhor criar uma nova tabela que
contenha a chave primria da primeira e o campo para observaes.
Gerenciamento e escolha dos ndices

128
Os ndices so campos escolhidos pelo construtor do Banco de Dados e que permitem a

busca de um campo a uma velocidade notavelmente superior. Entretanto, ocupam muito
memria (o dobro mais ou menos), e requer para sua insero e atualizao, um tempo de
processo superior.
Evidentemente, no podemos indexar todos os campos de uma tabela extensa j que
dobramos o tamanho do Banco de Dados. Igualmente, tampouco serve indexar todos os
campos numa tabela pequena j que as selees podem se efetuar rapidamente de qualquer
forma.
Um caso em que os ndices podem ser muito teis quando realizamos peties
simultneas sobre vrias tabelas. Neste caso, o processo de seleo pode se acelerar
sensivelmente se indexamos os campos que servem de nexo entre as duas tabelas.
Campos a Selecionar
Na medida do possvel devem-se evitar sentenas SQL que estejam embebidas dentro do
cdigo da aplicao. muito mais eficaz usar vistas ou procedimentos armazenados, por
que o gerenciador os salva compilados. Tratando-se de uma sentena embebida, o
gerenciador deve compil-la antes de execut-la.
Selecionar exclusivamente aqueles que se necessitem

No utilizar o SELECT * porque o gerenciador deve ler primeiro a estrutura da tabela antes de
executar a sentena. Se utilizar vrias tabelas na consulta, especifique sempre a que tabela
pertence cada campo, isso economizar tempo ao gerenciador de localiz-los. Ao invs de:
SELECT Nome, Fatura FROM Clientes, Faturamento WHERE IdCliente = IdClienteFaturado;
utilize:
SELECT Clientes.Nome, Faturamento.Fatura WHERE Clientes.IdCliente = Faturamento.IdClienteFaturado;
129
Interrogar sempre por campos que sejam chave

Se desejarmos interrogar por campos pertencentes a ndices compostos melhor utilizar
todos os campos de todos os ndices. Suponhamos que temos um ndice formado pelo
campo NOME e o campo SOBRENOME e outro ndice formado pelo campo IDADE. A
sentena WHERE NOME='Jose' AND SOBRENOME Like '%' AND IDADE = 20 seria melhor que WHERE
NOME = 'Jose' AND IDADE = 20 porque o gerenciador, neste segundo caso, no pode usar o
primeiro ndice e ambas as sentenas so equivalentes porque a condio SOBRENOME Like

'%' devolveria todos os registros.
Ordem das Tabelas

Quando se utilizam vrias tabelas dentro da consulta tomar cuidado com a ordem
empregada na clusula FROM. Se desejarmos saber quantos alunos se matricularam no ano
1996 e escrevermos: FROM Alunos, Matriculas WHERE Aluno.IdAluno = Matriculas.IdAluno AND
Matriculas.Ano = 1996 o gerenciador percorrer todos os alunos para buscar suas matrculas e
devolver as correspondentes. Se escrevermos FROM Matriculas, Alunos WHERE Matriculas.Ano =

1996 AND Matriculas.IdAluno = Alunos.IdAlunos, o gerenciador filtra as matrculas e depois seleciona
os alunos, desta forma percorre menos registros.
http://sqlcomoumtodo.wordpress.com/2007/09/29/como-criar-consultas-sqlmais-rapidas/
130
Realize a Leitura Complementar ao excelente artigo de Flavio Augusto

Weber e Elaini Simoni Angelotti, intitulado Otimizando Consultas SQL no
ambiente SQLServer, para conhecer melhor esse ambiente:
http://www.pr.gov.br/batebyte/edicoes/2003/bb132/otimizando.shtml
131
NIDADE
28
Objetivo: Mostrar os parametros necessrios para disparar um gatilho para um determinado

evento em um Banco de Dados.
Comando CREATE TRIGGER para criao de um gatilho

O gatilho define um conjunto de aes a serem executadas quando ocorre um evento de
Banco de Dados em uma determinada tabela. O evento de Banco de Dados pode ser uma
operao de excluso, insero ou de atualizao. Por exemplo, se for definido um gatilho
para excluso em uma determinada tabela, a ao do gatilho ocorre sempre que se remove
uma ou mais linhas da tabela.
Junto com as restries, os gatilhos podem ajudar a impor regras de integridade com aes
como excluses ou atualizaes em cascata. Os gatilhos tambm podem realizar vrias
funes como emitir alertas, atualizar outras tabelas, enviar e-mail, e outras aes teis.
Pode ser definido qualquer nmero de gatilhos para uma nica tabela, inclusive vrios
gatilhos para a mesma tabela para o mesmo evento. Pode ser criado gatilho em qualquer
esquema, exceto os comeados por SYS. O gatilho no precisa residir no mesmo esquema
da tabela para a qual definido. Se for especificado um nome de gatilho qualificado, o nome
do esquema no poder comear por SYS.
Sintaxe
CREATE TRIGGER nome-do-gatilho
{ BEFORE | AFTER } { INSERT | DELETE | UPDATE [ OR ] }
ON nome-da-tabela [FOR EACH { ROW | STATEMENT }]
EXECUTE PROCEDURE nome-da-funo
132
Disparar Gatilhos
Os gatilhos so definidos como: BEFORE (antes) ou AFTER (depois).
Os gatilhos BEFORE disparam antes das modificaes da instruo serem aplicadas, e
antes de qualquer restrio ser aplicada.
Os gatilhos AFTER disparam aps todas as restries terem sido satisfeitas, e aps todas as
alteraes terem sido aplicadas tabela de destino.
Tanto o gatilho BEFORE, como o AFTER podem ser tanto de linha (ROW) quanto de
instruo (STATEMENT).
Insero, excluso e atualizao: o que faz o gatilho disparar

O gatilho disparado por um dos seguintes eventos do Banco de Dados, dependendo de
como foi definido:
INSERT
DELETE
UPDATE
O gatilho pode ser especificado para disparar antes de tentar realizar a operao na linha ou
aps a operao estar completa. Se o gatilho for disparado antes do evento, o gatilho pode
evitar a operao para a linha corrente, ou modificar a linha sendo inserida (para as
operaes de INSERT e UPDATE somente). Se o gatilho for disparado aps o evento, todas
as mudanas, incluindo a ltima insero, atualizao ou excluso, so "visveis" para o
gatilho.
Se o gatilho estiver marcado como FOR EACH ROW ento ele chamado uma vez para cada
linha modificada pela operao. Por exemplo, um comando DELETE afetando 10 linhas faz
133
com que todos os gatilhos ON DELETE da relao de destino sejam chamados 10 vezes, uma
vez para cada linha excluda. Por outro lado, um gatilho marcado como FOR EACH STATEMENT
somente executa uma vez para uma determinada operao, independente de quantas linhas
sejam modificadas. Em particular, uma operao que no modifica nenhuma linha, ainda
assim resulta na execuo de todos os gatilhos FOR EACH STATEMENT aplicveis.
Se vrios gatilhos do mesmo tipo esto definidos para o mesmo evento, estes so
disparados na ordem alfabtica de seus nomes. O SELECT no modifica nenhuma linha e,
portanto, no possvel criar gatilhos para SELECT. Regras e vises so mais apropriadas
neste caso.
Parmetros Utilizados
CREATE TRIGGER nome-do-gatilho
Nome dado ao novo gatilho, devendo ser distinto do nome de qualquer outro gatilho para a
mesma tabela.
{ BEFORE | AFTER }
Determina se a funo chamada antes ou depois do evento.

{ INSERT | DELETE | UPDATE [ OR ] }
Especifica o evento que dispara o gatilho. Vrios eventos podem ser especificados utilizando
OR.
ON nome-da-tabela
O nome (opcionalmente qualificado pelo esquema) da tabela que o gatilho se destina.

[FOR EACH { ROW | STATEMENT }]
Especifica se o procedimento do gatilho deve ser disparado uma vez para cada linha afetada
pelo evento do gatilho, ou apenas uma vez para a declarao SQL. Se nenhum dos dois for
especificado, FOR EACH STATEMENT usado por padro.
134
EXECUTE PROCEDURE nome-da-funo
Uma funo fornecida pelo usurio, declarada como no recebendo nenhum argumento e
retornando o tipo trigger, que executada quando o gatilho dispara.
Exemplo:
CREATE TRIGGER tafter
AFTER INSERT OR UPDATE OR DELETE
ON ttest FOR EACH ROW
EXECUTE PROCEDURE trigf();
Observaes:
Para poder criar um gatilho em uma tabela, o usurio deve possuir o privilgio TRIGGER na
tabela. Deve ser utilizado o comando DROP TRIGGER para remover um gatilho.
http://htmlstaff.org/postgresqlmanual/sql-createtrigger.html
http://www.javalinux.com.br/javalinux/pg74/sql-createtrigger.html
Para voc se ambientar ao PL/SQL da ORACLE, veja no final desse artigo como
eles co nceituam TRIGGER:
http://www.sqlmagazine.com.br/artigos/oracle/04_Intro_PLSQL.asp
135
NIDADE
29
Objetivo: Apresentar aspectos de segurana e proteo num SGBD.
Protegendo seu Servidor de Banco de Dados

Geralmente Bancos de Dados contm dados muito confidenciais (por exemplo: detalhes
pessoais de recursos humanos, detalhes sobre clientes, ordens de compra ou detalhes sobre
carto de crdito). Esses dados devem ser armazenados com segurana e protegidos contra
divulgao no autorizada, violao ou uso mal intencionado. O servidor de Banco de Dados,
mesmo que no esteja diretamente conectado Internet, precisa ser protegido contra
ataques que exploram os pontos fracos da configurao, estouros de buffer existentes ou
prticas de desenvolvimento ineficazes. Esses ataques podem ser executados, por exemplo:
Um aplicativo da Web desprotegido, usado para explorar o Banco de Dados.
Um administrador mal intencionado com acesso rede.
Um usurio do Banco de Dados que, sem saber, executa cdigos mal intencionados.
Um invasor pode visar e comprometer um servidor de Banco de Dados de diversas

formas ao explorar vrias configuraes e vulnerabilidades no nvel do aplicativo. As
principais ameaas para um servidor de Banco de Dados so:
Incluso de cdigo SQL

Com um ataque de incluso de cdigo SQL, o invasor explora as vulnerabilidades do cdigo
de acesso a dados. Outro ponto a validao da entrada do aplicativo para executar
comandos arbitrrios que usa o contexto de segurana do aplicativo da Web.
136
Espionagem na rede
A arquitetura de implantao da maioria dos aplicativos inclui uma separao fsica entre o
cdigo de acesso a dados e o servidor de Banco de Dados. Consequentemente, os dados
confidenciais, como dados especficos do aplicativo ou credenciais de logon ao Banco de
Dados, devem ser protegidos contra a espionagem na rede.
Acesso no autorizado ao servidor

O acesso direto ao servidor de Banco de Dados deve ser restrito a computadores cliente
para impedir o acesso no autorizado ao servidor. Ataques de conexo direta existem para
usurios autenticados, e tambm para usurios sem nome de usurio e sem senha.
Quebra de senha
Uma primeira linha de ataque comum tentar quebrar as senhas de nomes de conta
conhecidos, como a conta do administrador do SGBD.
A figura a seguir mostra as principais ameaas e vulnerabilidades que podem resultar em um
servidor de Banco de Dados. E visto tambm a possibilidade de destruio ou no roubo de
dados confidenciais.
137
Figura - Principais ameaas e vulnerabilidades de um SGBD
Algumas medidas de segurana do servidor de Banco de Dados tm como base as prticas

recomendadas obtidas em experincias reais, na validao de clientes e em estudos de
implantaes de segurana. Algumas medidas de segurana recomendadas so:
Patches e atualizaes
Muitas ameaas de segurana existem devido a vulnerabilidades nos Sistemas
Operacionais e aplicativos. Geralmente, quando novas vulnerabilidades so descobertas, o
cdigo de ataque publicado na Internet, poucas horas aps o primeiro ataque. O patch e a
atualizao do software do servidor so a primeira etapa para a proteo do servidor de
Banco de Dados.
Servios
Os servios so os pontos de vulnerabilidade preferenciais dos invasores que exploram os
privilgios e os recursos do servio para acessar o servidor. Alguns servios foram criados
para funcionar usando contas com privilgios. Se esses servios estiverem comprometidos, o
invasor poder efetuar operaes privilegiadas. Por padro, os servidores de Banco de
138
Dados no precisam de todos os servios ativados. Ao desativar os servios desnecessrios,

e no utilizados, voc reduz de maneira rpida e fcil a rea de superfcie de ataque.
Protocolos
Limite o intervalo de protocolos que computadores cliente podem usar para estabelecer
conexo com o servidor de Banco de Dados e verifique se possvel proteger esses
protocolos.
Contas
Restrinja o nmero de contas do Windows acessveis pelo servidor de Banco de Dados ao
conjunto necessrio de contas de usurio e de servio. Use contas com menos privilgios e
com senhas de alta segurana. Uma conta com menos privilgios, usada para executar o
SQL Server, limita os recursos de um invasor que compromete o SQL Server e que
consegue executar comandos do sistema operacional.
Arquivos e diretrios
Use as permisses do sistema de arquivos NTFS para proteger programas, Bancos de
Dados e arquivos de log contra o acesso no autorizado. Quando voc usa ACLs (Listas de
Controle de Acesso) junto com a auditoria do Windows, possvel detectar a ocorrncia de
atividades suspeitas ou no autorizadas.
Compartilhamentos
139
Remova
todos
os
compartilhamentos
de
arquivos
desnecessrios,
incluindo
os
compartilhamentos de administrao padro caso no sejam necessrios. Proteja quaisquer

compartilhamentos restantes com permisses NTFS restritas.
Portas
As portas no utilizadas esto fechadas no firewall, mas necessrio que os servidores
subjacentes ao firewall tambm bloqueiem ou restrinjam as portas com base no uso. Para
um SGBD dedicado, bloqueie todas as portas, exceto as portas necessrias para
autenticao.
Auditoria e log
A auditoria uma ajuda vital para a identificao de intrusos e de ataques em andamento,
bem como para o diagnstico de sinais de ataque. Configure um nvel mnimo de auditoria
para o servidor de Banco de Dados usando uma combinao de recursos de auditoria do
Windows e do SGBD.
http://www.microsoft.com/brasil/security/guidance/default.mspx
http://forums.microsoft.com/technet-br
http://www.activedelphi.com.br/modules.php?op=modload&name=News&fil
e=article&sid=293&mode=thread&order=0&thold=0
140
Pesquise na Internet casos de invaso em Banco de Dados
141
NIDADE
30
Objetivo: Fazer um comparativo dos vrios SGBD usados atualmente no mundo corporativo.
Caractersticas dos vrios SGBDs de uso Comercial

Vamos aqui mencionar algumas caractersticas dos principais SGBDs hoje utilizados nos
mais variados segmentos da atividade humana. Entre os vrios SGBDs usados atualmente
para diversas utilidades e propsitos, podemos dividi-los em SGBDs free (licena gratuita) e
os SGBDs proprietrios.
Referente aos SGBDs free vamos analisar o MySQL e o PostgreSQL. Referente aos SGBDs
proprietrios vamos mencionar o SQL Server da Microsoft, o Oracle e o DB2 da IBM. Com
relao ao Access do pacote Office da Microsoft, muitos no consideram como sendo um
SGBD devido a sua relativa simplicidade.
MySQL
O MySQL um SGBD, que utiliza a linguagem SQL como interface. atualmente um dos
Bancos de Dados mais populares. O MySQL foi criado na Sucia por dois suecos e um
finlands: David Axmark, Allan Larsson e Michael "Monty" Widenius. Todos esses
desenvolvedores trabalham juntos desde a dcada de 1980. Hoje em seu desenvolvimento e
manuteno, empregam aproximadamente 70 profissionais no mundo inteiro. Mais de mil
pessoas contribuem testando o software, integrando-o a outros produtos, e escrevendo a
respeito do mesmo.
O sucesso do MySQL deve-se em grande parte fcil integrao com o PHP. Essa
linguagem oferecida atualmente, quase que obrigatoriamente, nos pacotes de hospedagem
de sites na Internet. O Wikipdia um exemplo de utilizao do MySQL com grande
eficincia e robustez. Algumas de suas caractersticas so:
142
Portabilidade (suporta praticamente qualquer plataforma atual);
Compatibilidade (existem drivers ODBC, JDBC e .NET e mdulos de interface para

diversas linguagens de programao, como Delphi, Java, C/C++, Python, Perl, PHP e
Ruby);
Excelente desempenho e estabilidade;
Pouco exigente quanto a recursos de hardware;
Facilidade de uso;
Software Livre;
Suporte a vrios tipos de tabelas (como MyISAM e InnoDB).
No entanto, mesmo com todas essas caractersticas positivas, ainda faltam alguns recursos
avanados quando comparados como outros Banco de Dados, como o PostgreSQL.
PostgreSQL
PostgreSQL um Sistema Gerenciador de Banco de Dados Objeto Relacional (SGBDOR),
desenvolvido como projeto software livre. Inicialmente foi desenvolvido na Universidade de
Berkeley, Califrnia. A partir de 1996, o PostgreSQL firmou-se como um projeto de software
open source e comeou a ser desenvolvido por uma comunidade de voluntrios sob a
coordenao do PostgreSQL Global Development Group.
Embora as atividades do grupo sejam patrocinadas por diversas organizaes de todo o
mundo, seu desenvolvimento feito por um grupo de desenvolvedores, em sua maioria
voluntrios, espalhados por todo o mundo e que se comunicam via Internet. Hoje, o
PostgreSQL um dos SGBD de cdigo aberto mais avanados, contando com recursos
especiais tais como:
Consultas complexas;
143
Chaves estrangeiras;
Integridade transacional;
Controle de concorrncia multiverso;
Suporte ao modelo hbrido objeto-relacional;
Triggers;
Views;
Stored procedures em vrias linguagens.
SQL Server
O SQL Server um Gerenciador de Banco de Dados Relacional feito pela Microsoft. um
Banco de Dados robusto e usado por sistemas corporativos dos mais diversos portes. Entre
os novos recursos est a integrao com o Framework .Net, que possibilita construir rotinas
utilizando as linguagens do .Net como VB.Net e C#.
Existe a necessidade de se destacar que no se deve confundir esse especfico SGBD, com
a linguagem SQL que geral e criada pela IBM. Por estratgias de marketing, espertamente
a Microsoft incluiu o nome dessa linguagem dentro do seu SGBD.
O SQL Server funciona apenas sob as vrias verses do Sistema Operacional Windows, da
prpria Microsoft. Os seus grandes concorrentes: Oracle e Postgres, por sua vez so mais
flexveis, pois funcionam em diversas plataformas e sistemas operacionais diferentes.
Oracle
O Oracle um SGBD que surgiu no final dos anos 70, quando Larry Ellison vislumbrou uma
oportunidade que outras companhias ainda no haviam percebido. Esse grande
144
empreendedor encontrou um prottipo funcional de um Banco de Dados relacional e

descobriu que nenhuma empresa tinha se empenhado em comercializar essa tecnologia.
Ellison e os cofundadores da Oracle Corporation, Bob Miner e Ed Oates, perceberam que
havia um tremendo potencial de negcios no modelo de Banco de Dados Relacional
tornando assim a maior empresa de software empresarial do mundo. O SGBD da Oracle se
tornou lder de mercado. O Oracle 9i foi pioneiro no suporte ao modelo Web. O Oracle 10g,
mais recente, se baseia na tecnologia de grid.
DB2
O DB2 o Sistema Gerenciador de Banco de Dados Relacionais (SGDBR) produzido pela
IBM. Existem diferentes verses do DB2 que rodam desde num simples computador de mo,
at em potentes mainframes. Funcionam em servidores baseados em sistemas Unix,
Windows, ou Linux.
O projeto DB2 comeou no inicio dos anos 70 quando Edgar Frank Codd, trabalhando para
IBM, descreveu e publicou a teoria dos Bancos de Dados Relacionais. Para aplicar o modelo,
Codd criou uma linguagem que chamou de Alpha. Entretanto, a IBM no acreditava no
potencial das suas ideias, deixando-o fora da superviso do grupo de programadores, que
violaram diversas ideias fundamentais do modelo relacional de Codd. O resultado foi a
linguagem SEQUEL, que depois foi mudado para seu acrnimo SQL porque SEQUEL j era
uma marca registrada.
Por muitos anos, DB2 foi feito exclusivamente para rodar nos mainframes da IBM.
Posteriormente a IBM introduziu o DB2 para outras plataformas de servidores, incluindo o
Unix e o Windows, para ento colocar no Linux e PDAs.
145
Veja um comparativo entre o MySQL e o PostgreSQL

http://articles.techrepublic.com.com/5100-22-1050671.html
http://www.devx.com/dbzone/Article/29480
Analise o SGBD usado pelo Metr de So Paulo e o motivo de fazerem

esta opo:
https://extranet.metrosp.com.br/downloads/outros/usopostgres.pdf
Para concluir seus estudos fundamental que voc entre no site da

ESAB e, em sua Sala de Aula, faa a Atividade 3, no link Atividades.
146
Atividade Dissertativa
Desenvolva uma pesquisa gerando um texto, de 2 a 3 folhas adicionando imagens, de uma
das unidades da nossa apostila, de sua livre escolha, permitindo a expanso da temtica
selecionada.
Ateno: Qualquer bloco de texto igual ou existente na internet ser devolvido para o aluno
realize novamente.
147
LOSSRIO
Como dito anteriormente, utilizamos o glossrio virtual http://pt.wikipedia.org.
148
IBLIOGRAFIA
DATE, C.J. Introduo a Sistemas de Bancos de Dados (traduo da 8a ed.). Rio de

Janeiro: Elsevier, 2003.
KORTH, H.F.; Silberschatz, A. Sistema de Banco de Dados. 3a ed. So Paulo: Makron
Books, 1999.
FANDERUFF, Damaris. Dominando o Oracle 9i: Modelagem e Desenvolvimento. So
Paulo: Pearson Education do Brasil, 2003.
SILVA, Luciano Carlos da. Banco de Dados para WEB: do Planejamento Implementao.
So Paulo: rica, 2001.
149

Banco de Dados

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Banco de Dados

Uploaded by

Copyright:

Available Formats

MDULO:

CARLOS ALBERTO VALENTE ANDRADE

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Mdulo de: Banco de Dados;

Primeira edio: 2007

Todos os direitos desta edio reservados

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Este mdulo ir apresentar conceitos fundamentais de Sistemas de Bancos de Dados dos

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Capacitar o leitor a lidar com um Sistema de Gerenciamento de Banco de Dados (SGBD)

Conceituao e anlise de caractersticas prprias de Sistemas de Gerncia de Banco de

Carlos Alberto Valente Andrade:

Professor e Consultor de Tecnologia de Informao

Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB

Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor,

Copyright 2007, ESAB Escola Superior Aberta do Brasil

GLOSSRIO ........................................................................................................................ 148

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Objetivo: Conceituar Banco de Dados, indicando os seus principais componentes bsicos.

O que um Banco de Dados? E o que vem a ser um SGBD?

Conceito de banco de dados

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Portanto, em outras palavras, podemos afirmar que um Sistema de Banco de Dados

Sistemas multiusurios e monousurios

Figura 1.1 - Representao simplificada de um sistema de Banco de Dados

Copyright 2007, ESAB Escola Superior Aberta do Brasil

trabalhando como num sistema monousurio, de forma que os problemas internos ao

e provavelmente ao mesmo tempo (acesso concorrente). Por exemplo, no arquivo citado

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Os componentes de hardware usados num sistema de Banco de Dados consistem

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Pesquise no Wikipdia sobre Banco de Dados e SGBD, e responda, por escrito,

Quais so os componentes bsicos de um Sistema de Banco de Dados?

Mencione alguns exemplos de SGBDs

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Objetivo: Apontar e detalhar as principais vantagens de um Sistema de Gerenciamento de

Figura 2.1 - Sistema de Banco de Dados

O acesso s informaes em sistemas de processamento de dados que no utilizam SGBDs

e devolvidas por ele mesmo. O gerenciador que assume toda a responsabilidade de

Consistncia ou Compartilhamento de Dados;

Segurana ou Restrio de Acesso;

Restaurao ou Tolerncia a Falhas;

No Redundncia ou Controle de Redundncia;

Padronizao dos Dados.

Consistncia ou compartilhamento de dados

Segurana ou restrio de acesso

determinada informao. Por exemplo, num sistema bancrio, o

departamento pessoal necessita apenas do Banco de Dados as informaes sobre os

Restaurao ou tolerncia a falhas

No redundncia ou controle de redundncia

observar apenas o processo de atualizao concorrente, para no gerar erros de

Padronizao dos dados

Alto investimento inicial na compra de software e hardware adicionais;

Generalidade que um SGBD fornece na definio e processamento de dados;

Sobrecarga na proviso de controle de segurana, controle de concorrncia,

Tambm podemos considerar desvantagens de um SGBD quando os projetistas do Banco

Nesta unidade vimos as principais caractersticas de um SGBD, porm

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Objetivo: Indicar os principais aspectos das arquiteturas de um Sistema de Gerenciamento

Conceitos e Arquiteturas de um SGBD

servidores de dados (relacional) e programao dos aplicativos (Imperativo, Orientado a

Viso Geral das Arquiteturas