Apostila de Inglês

,QVWLWXWRGH,QIRUPiWLFD
&XUVRGH$QiOLVHGH6LVWHPDV
%DQFRGH'DGRV,
R6HPHVWUHGH
3URI$QGUp/XtVGRV5*GH&DUYDOKR
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS
INSTITUTO DE INFORMÁTICA
PLANO DE ENSINO
Curso: Disciplina: Docente: C.H. Semanal Período Letivo:

Análise de Sistemas Bancos de Dados I André Luís dos Reis Gomes de Carvalho 04 (quatro horas aula) 1º Semestre de 2000
Objetivo Geral da Disciplina:

• Sistematizar o desenvolvimento de bancos de dados (estudo das fases de modelamento de dados).
Avaliação:
• Haverá apenas uma prova, a prova final (P).
• Haverá apenas um trabalho que se desenvolverá em várias fases (Fi).
• A nota de trabalho T será dada pela média aritmética das notas de cada fase (Fi).
• Os trabalhos serão realizados sob supervisão do professor através de reuniões periódicas com o grupo envolvido nos trabalhos. Deverá haver um número mínimo de 6 reuniões no semestre. A cada
reunião o professor atribuirá aos integrantes do grupo uma nota individual que expressará a participação (Ri) de cada membro do grupo no trabalho.
• A nota de acompanhamento A será dada pela média aritmética das notas de cada reunião (Ri).
• A nota corrigida de trabalho TC será dada pela seguinte expressão: T.A/10.
• A média final M será dada pela seguite expressão: 0,4.TC + 0,6.P.
Freqüência:
• Nenhum abono de falta será concedido pelo professor. Qualquer problema neste sentido deverá ser encaminhada ao PA que tomará todas as providências no sentido de encaminhar a solução do mesmo.
Bibliografia Utilizada :
• Introdução a Sistemas de Bancos de Dados
Date, C.J.
• Projeto Lógico e Projeto Físico de Bancos de Dados

Setzer, V.W.
• The Entity-Relationship Approach to Logical Database Design

Chen, P.
• Computer Database Organization

Martin, J.
• Fundamental Concepts of Information Modeling

Flavin, M.
• Sistemas de Bancos de Dados

Korth, H.F.; e Silberschatz
1~PGH &RQWH~GRV6HOHFLRQDGRV 2%-(7,926 (VWUDWpJLDV )RUPDGH$YDOLDomR
$XODV 0HWDVGH(QVLQR 7pFQLFDVGH(QVLQR
04 • Histórico. • O objetivo desta unidade didática é mostrar ao aluno a importância • Aulas • Prova escrita
• Fases de modelamento de dados. de sistematizar o processo de modelamento de dados. expositivas • Trabalho Prático
• O objetivo desta unidade didática é que o aluno aprenda a identificar • Aulas • Prova escrita
08 • Levantamento de visões (conceito de visão, como identificar visões. expositivas • Trabalho Prático
visões, tipos de visões). • Trabalhos
práticos em
campo
• Estudo dirigido
20 • Modelamento conceitual de visões (modelo entidade- • O objetivo desta unidade didática é que o alunos aprenda a modelar • Aulas • Prova escrita
relacionamento extendido binário: entidades, dados. expositivas • Trabalho Prático
relacionamentos, atributos, tipos de atributos, agregados, • Trabalhos
hierarquias). práticos em
• Integração das visões (construção do modelo conceitual campo
global). • Estudo dirigido
18 • Derivação dos arquivos físicos. • O objetivo desta unidade didática é que o aluno aprenda a derivar • Aulas • Prova escrita
• Particionamento dos arquivos físicos. arquivos físicos a partir de modelos lógicos. expositivas • Trabalho Prático
• Implementação das visões. • Trabalhos
práticos em
campo
• Estudo dirigido
10 • Linguagens de Consulta Teóricas (Álgebra e Cálculo • O objetivo desta unidade didática é que o aluno aprenda a expressar • Aulas • Prova escrita
Relacional). consultas em linguagens de consulta. expositivas • Trabalho prático
• SQL. • Estudo dirigido
ËQGLFH
ËQGLFH
,QIRUPDomR'DGRH(OHPHQWRGH'DGR
$QWHVGD7HFQRORJLDGH%'V
Normalização ................................................................................................................ 7
Desenvolvimento .......................................................................................................... 8
6LVWHPDVGH%DQFRGH'DGRV
(VTXHPDV
0RGHORV)tVLFRV
'HVHQYROYLPHQWRGH6LVWHPDV
$GPLQLVWUDomRGH'DGRV
(QJHQKDULDGH%DQFRVGH'DGRV
A Construção do Modelo Descritivo .......................................................................... 20
O MER ........................................................................................................................ 21
A Construção do Modelo Conceitual.......................................................................... 33
A Construção dos Modelos Conceituais Parciais ................................................. 33
A Construção do Modelo Conceitual Global........................................................ 34
A Construção do Modelo Interno ............................................................................... 35
A Construção do Modelo Interno Preliminar........................................................ 35
A Construção do Modelo Interno Otimizado........................................................ 39
A Implementação dos Programas Aplicativos ............................................................ 39
/LQJXDJHQVGH&RQVXOWD
Linguagens de Consultas Teóricas.............................................................................. 40
Cálculo Relacional ................................................................................................ 41
Álgebra Relacional................................................................................................ 43
SQL (Structured Query Language) ............................................................................. 46
Principais Comandos ............................................................................................ 47
a) Criação de Domínios:..................................................................................... 47
b) Eliminação de Domínios:............................................................................... 48
c) Criação de Tabelas: ........................................................................................ 48
d) Acréscimo de Colunas a uma Tabela ............................................................. 49
e) Eliminação de Colunas a uma Tabela ............................................................ 49
f) Eliminação de Tabelas: .................................................................................. 50
g) Criação de Índices:......................................................................................... 50
h) Eliminação de Índices: ................................................................................... 51
i) Inclusão de Dados: ......................................................................................... 51
j) Exclusão de Dados: ........................................................................................ 51
k) Atualização de Dados: ................................................................................... 52
l) Criação de Asserções: .................................................................................... 52
m)Eliminação de Asserções:................................................................................. 52
n) Consultas:....................................................................................................... 53
o) Junção de Tabelas: ......................................................................................... 63
p) União de Tabelas:........................................................................................... 66
q) Interseção de Tabelas: .................................................................................... 68
r) Diferença de Tabelas:..................................................................................... 68
s) Criação de Visões: ......................................................................................... 70
t) Eliminação de Visões:.................................................................................... 71
u) Definição de Sinônimos:................................................................................ 72
v) Eliminação de Sinônimos: ............................................................................. 72
w) Concessão de Privilégios.................................................................................. 72
x) Revogação de Privilégios............................................................................... 75
y) Processamento de Transações ........................................................................ 75
Catálogos............................................................................................................... 76
Modo Programado ................................................................................................ 77
Comandos Simples de Modo Programado............................................................ 78
a) SELECT com criação de tabela...................................................................... 78
b) Inserção de grandes volumes de dados .......................................................... 79
Comandos de Modo Programado relacionados com Cursores ............................. 79
a) Declaração de Cursores.................................................................................. 79
b) Abertura de Cursores...................................................................................... 80
c) Obtenção de Dados de Cursores .................................................................... 80
d) Atualização de Dados de Cursores................................................................. 81
e) Fechamento de Cursores ................................................................................ 82
Comandos Dinâmicos em Modo Programado ...................................................... 82
a) Preparação de Comandos ............................................................................... 82
b) Execução de Comandos ................................................................................. 82
$SrQGLFH$([HUFtFLRVGH3URMHWRGH%'
$SrQGLFH%7DEHODVGD6HomRGHÈOJHEUD&iOFXOR5HODFLRQDO
$SrQGLFH&7DEHODV8VDGDVQD6HomRVREUH64/
$SrQGLFH'3DODYUDV5HVHUYDGDVGH64/
$SrQGLFH(([HUFtFLRVGH/LQJXDJHQVGH&RQVXOWD
%DQFRVGH'DGRV 3iJLQD
,QIRUPDomR'DGRH(OHPHQWRGH'DGR
Quando nos propomos a falar de sistemas de bancos de dados, sem dúvida não poderemos
deixar de esbarrar no conceito de LQIRUPDomR. Dizemos LQIRUPDomR qualquer FRQKHFLPHQWR
de que não disponhamos mas de que tenhamos necessidade.
Em sendo conhecimento, a informação só existe na mente das pessoas, constituindo uma parte
de um quadro mental de referência. A LQIRUPDomR está sempre associada a um ente específico
concreto ou abstrato, que poderíamos chamar de HQWHGHUHIHUrQFLD.
Hoje em dia, mais do que nunca, LQIRUPDomR constitui um recurso básico e imprescindível
para toda e qualquer atividade humana. Informações completas e oportunas acabam por
diferenciar uma companhia de seus concorrentes, vindo até mesmo a ter implicações não
desprezíveis no sucesso ou insucesso de uma empresa.
Dizemos GDGR qualquer conjunto de símbolos organizados com intencionalidade para

representar a informação fora da mente humana, possibilitando seu armazenamento e
transferência.
No contexto da computação, quando falamos a respeito de armazenar informações do mundo

real em arquivos de dados, nos referimos à armazenagem de coisas que se conheça a cerca das
entidades que povoam o mundo real, visando construir uma representação destas mesmas
entidades através de seus atributos.
Neste processo de representação, assumimos de maneira implícita que todos os entes do

mundo real sejam idênticos a um ente de referência o que nos possibilita construir uma
representação padrão.
Um dado representa primariamente informações sobre uma entidade em uma realidade, e

secundariamente um próprio pedaço da realidade. Quando extraímos informações dos entes do
mundo real e as representamos através de dados em um banco de dados, acabamos por
restringir a informação real que virtualmente poderia requerer uma quantidade infinita de
dados para representá-la com propriedade. Isto sem falar a respeito das coisas que são
DOUJF
deixadas de lado a fim de conseguir maior semelhança com o ente de referência e em última
instância a construção de uma representação padrão.
Desta maneira, GDGRV não são mais que uma imagem pálida do que é a informação viva do
mundo real. Assim, quando obtemos de um sistema de informação dados a respeito de algum
ente do mundo real, deve-se realizar sobre eles um processo inverso de enriquecimento
semântico, de maneira que se consiga associar os dados obtidos a partir de um banco de dados
às entidades do mundo real que lhes deram origem.
Não sendo mais que uma representação das entidades do mundo real, podemos dizer que
podem existir inúmeras representações possíveis, sendo cada uma mais ou menos adequada a
cada situação.
Chamamos HOHPHQWRGHGDGR a qualquer conjunto de símbolos com um significado específico

que compõe um dado mas que não constitui informação completa.
$QWHVGD7HFQRORJLDGH%'V
1RUPDOL]DomR
O processo de normalização consiste de um algoritmo que descreve uma série de
transformações que devem ser realizadas sobre arquivos de dados a fim de torná-los estáveis e
econômicos. O objetivo é colocar todos os arquivos em consideração na 3ª forma normal.
Antes de vermos um exemplo, convém que apresentemos algumas definições:
• 'HSHQGrQFLD)XQFLRQDO
Dizemos que o atributo Y da relação R é funcionalmente do atributo X da mesma relação

se e somente se cada valor de X em R tiver associado a si precisamente um valor de Y em
R a qualquer momento.
• 3ULPHLUD)RUPD1RUPDO)1
Dizemos que uma relação R está na 1FN se e somente se todos os domínios básicos de R
contiverem somente valores atômicos.
DOUJF
• 6HJXQGD)RUPD1RUPDO)1
Dizemos que uma relação R está na 2FN se e somente se ela estiver na 1FN e todos os
atributos não chave forem totalmente dependentes funcionalmente da chave primária.
• 7HUFHLUD)RUPD1RUPDO)1
Dizemos que uma relação R está na 3FN se e somente se ela estiver na 2FN e todos os
atributos chave forem dependentes funcionalmente não transitivos da chave primária.
A título de exemplo, consideremos a relação não normalizada abaixo:
Prod {3, NomeP, CorP, PesoP, FornP {#F, NomeF, CidF, DistF,QdeF}}
• Passando para a 1FN temos:
Prod {3, NomeP, CorP, PesoP}

Fornec {3, ), NomeF, CidF, DistF, QdeF}
• Passando para a 2FN temos:

Fornec {), NomeF, CidF, DistF}
PF {3, ), QdeF}
• Finalmente, passando para a 3FN temos:

Fornec {), NomeF, CidF}
PF {3, ), QdeF}
Dist {&LG, Dist}
'HVHQYROYLPHQWR
Podemos dizer de maneira simplificada, que o método tradicional de desenvolvimento de
sistemas pode ser resumido em entradas, processamento, e saídas.
Entre as características desta abordagem tradicional, podemos ressaltar o incentivo ao

desenvolvimento de múltiplas aplicações isoladas, cada qual mantendo seus próprios arquivos
de dados.
DOUJF
Se procedermos a uma análise nas implicações desta abordagem poderemos identificar a

existência de alguns problemas, como por exemplo a falta de integração entre os arquivos, o
elevado índice de "sorts" e "merges" para a obtenção de ordenação apropriada para a emissão
de relatórios, o elevado grau de redundância de dados entre os arquivos das diversas
aplicações, a incompatibilidade entre as ocorrências do mesmo dado, a duplicidade de
procedimentos e a ocupação inadequada de espaço.
Como já fizemos alusão anteriormente, não é possível negar que os dados são um recurso
imprescindível à boa operação de uma empresa, e desta maneira faz-se necessário que os
dados se caracterizem por sua disponibilidade, facilidade de interpretação, atualidade, exatidão
e precisão.
Um sistema de computação que modele os dados de uma organização de acordo com a

estrutura e o ambiente reais da organização poderá garantir as metas acima. Para permitir esta
modelagem adequada, surge a tecnologia de bancos de dados.
6LVWHPDVGH%DQFRGH'DGRV
O que é afinal um sistema de banco de dados? Poderíamos dizer que um sistema de banco de
dados é um sistema de armazenamento de dados em ambiente computacional, cujo objetivo
global é registrar e manter informações de maneira a eliminar os problemas que podem ser
identificados em sistemas desenvolvidos segundo a abordagem tradicional, e a conferir aos
dados as características apontadas acima como necessárias.
Entendemos por EDQFR GH GDGRV um depósito de dados armazenados em geral de forma
integrada e compartilhada. Podemos imaginar um banco de dados como sendo a unificação de
diversos arquivos que de outra forma seriam distinguíveis, eliminando total ou parcialmente
(mas de qualquer forma mantendo sob controle) qualquer redundância entre aqueles arquivos.
Os dados em um banco de dados podem em geral ser compartilhados entre diversas aplicações
e usuários diferentes. Na verdade, a possibilidade de compartilhamento poderia ser vista como
uma conseqüência da integração do banco de dados. Desta maneira, informações sobre peças
que uma empresa fabrique poderiam ser compartilhadas pelo setor de fabricação, pelo setor de
controle de qualidade e pelo setor de vendas.
DOUJF
O termo FRPSDUWLOKDGR é em geral estendido para descrever compartilhamento no tempo, isto

é, a possibilidade de diversos usuários ou aplicações acessarem em conjunto o banco de dados
ao mesmo tempo.
Um sistema de banco de dados envolve quatro componentes maiores: hardware, software,

usuários e os dados propriamente ditos. Para que seja possível a integração e o
compartilhamento de informações em um banco de dados, faz-se necessário que os dados
residam em dispositivos de acesso direto como discos ou fitas.
Em geral, para controlar o acesso e o uso das informações em um banco de dados, entre o
banco de dados físico e os sistemas aplicativos que os manipulam, encontra-se um software
normalmente chamado de sistema gerenciador de banco de dados ou simplesmente SGBD.
Este sistema manipula todas as solicitações dos usuários para acesso e/ou utilização dos dados
do BD, isolando os sistemas aplicativos dos detalhes de hardware, garantindo a integridade de
atualizações aos dados e promovendo o acesso controlado (proteção) aos dados. Em outras
palavras, o SGBD fornece uma visão do BD a um bom nível de abstração, suporta operações
de usuários, garante a integridade dos dados, bem como a segurança deles.
Antes dos SGBD, como já dissemos anteriormente, os próprios programas aplicativos

mantinham seus arquivos de dados, de maneira que a estrutura dos arquivos utilizados por um
programa dependia dos programas que utilizariam os mesmos. Este tipo de dependência entre
os dados e os programas aplicativos não é uma coisa desejável, pois qualquer mudança que um
programa aplicativo necessite na estrutura de um arquivo implicaria em mudanças em talvez
muitos programas que fizessem uso do arquivo, ainda que estes programas logicamente não
tivessem nenhuma razão para serem afetados por estas mudanças.
Definimos dependência de dados como sendo suposições sobre a organização físicas de dados
e o aproveitamento deste conhecimento por parte de programas aplicativos que manipulem
estes dados. Vejamos agora, a título de ilustração, alguns exemplos de dependência de dados.
1. Alguns programas aplicativos são extremamente sensíveis à organização dos arquivos

que manuseiam. Considere por exemplo a aplicação de recuperar informações de
funcionários em um arquivo seqüencial.
DOUJF
Suponhamos que exista um arquivo de funcionários com os campos número e nome, e que
seja fornecido a um programa aplicativo o código do funcionário a fim de que este proceda
à busca e forneça o nome do funcionário. Analisemos o seguinte programa:
Programa Ordem;
Leia (NumFunc);
Achou = F;
Fim = F;
Enquanto Não Achou E Não Fim Faça

Se FimArq (ArqFunc)
Fim = V;
Senão
Leia (ArqFunc, RegFunc);
Se RegFunc.NumFunc = NumFunc
Achou = V;
Senão
Se RegFunc.NumFunc > NumFunc
Fim = V;
FimSe;
FimSe;
FimSe;
FimEnquanto;
Se Achou
Escreva (RegFunc.NomeFunc);
Senão
Escreva ('Não Encontrado!');
FimSe;
FimPrograma.
Este programa supõe e se aproveita da suposição de que o arquivo de funcionários estaria

ordenado em ordem crescente de número de funcionário. Desta maneira, se o arquivo for
reordenado por nome de funcionário, o programa não mais funcionará.
2. Certos programas aplicativos podem ainda ser sensíveis ao formato dos dados. Considere o
seguinte trecho de um programa aplicativo:
Programa Formato;
Tipo
TipoRegFunc = Registro
DOUJF
NumFunc : Int;
NomeFunc: Char [30];
SalarFunc: Real;
FimRegistro;
Variável
ArqFunc: Arquivo De TipoRegFunc;
•
•
•
Qualquer das mudanças abaixo provocaria mudanças no programa aplicativo:
Adicionar ao registro um campo (por exemplo o campo endereço) não utilizado pelo
programa;
Mudança do tipo de um campo do arquivo não utilizado pelo programa;
Retirada de um campo do arquivo não utilizado pelo programa.
No entanto note que o programa aplicativo não deveria ser sensível a este tipo de coisa,
uma vez que não se utiliza dos dados que sofreram alterações.
3. Considere a seguinte situação: dois programas precisam do mesmo arquivo, só que em

formatos diferentes, por exemplo, um programa que, para todo aluno, lista as matérias que
ele cursa; e outro que, para toda matéria, lista os alunos que estão matriculados nela.
Entre as possíveis soluções para o uso compartilhado do arquivo por parte dos dois
programas poderíamos destacar:
Freqüentes reorganizações (são caras e limitam o acesso "on-line");
Manter duas cópias do arquivo (além de também serem caras, podem criar problemas
de consistência interna, isto é, será possível garantir que os dois arquivos contêm as
mesmas informações? Também têm a questão da segurança, isto é, será possível
garantir ambos os arquivos estarão igualmente protegidos?).
Para alcançar a independência de dados, o SGBD mantém o BD e provê comandos para

acessá-lo, sendo este acesso sempre feito através do SGBD. O SGBD mantém uma visão
DOUJF
estável dos dados, que não é afetada por mudanças na organização. Para tal, o SGBD deve
distinguir entre a organização lógica e a organização física dos dados.
Entendemos por organização lógica dos dados, a maneira pela qual os dados são YLVWRV pelos
programas aplicativos; e por organização física dos dados, o modo como estes se encontram
armazenados em dispositivos físicos.
Enquanto os programas aplicativos GHYHP conhecer a organização lógica dos dados, pPHOKRU
TXHLJQRUHP a organização física dos dados.
Como vantagens do controle centralizado dos dados por parte do SGBD poderíamos citar:
• Reduzir e/ou manter a redundância de informações sob controle (redundâncias por um lado
provocam desperdício de espaço de armazenamento e podem causar inconsistências, mas
por outro podem vir a melhorar a eficiência de um sistema de banco de dados);
• Promover o compartilhamento dos dados (não somente as aplicações existentes podem

compartilhar entre si os dados do BD, mas também novas aplicações podem ser
desenvolvidas sem que se tenha que criar um só arquivo de dados);
• Manter restrições de segurança (a centralização dos dados permite um maior controle

destes, e os SGBD em geral permitem a manutenção de diversas permissões de
acesso - acréscimo, remoção, modificação, recuperação, etc - e a diversos níveis);
• Garantir a integridade (restrições de integridade ou procedimentos de validação podem ser

definidos e serão executados pelo SGBD sempre que for tentada uma atualização do BD. É
importante chamar a atenção para o fato de que a integridade dos dados é ainda mais
importante em sistemas de banco de dados do que em sistemas convencionais, pois uma
vez que os dados são compartilhados, torna-se possível que o mal uso que alguma
aplicação possa fazer dos dados do banco de dados tenha um efeito não somente local à
aplicação, mas possivelmente afetar diversas outras aplicações);
• Obter independência dos dados (uma aplicação enxerga os dados do banco de dados da
maneira que lhe for conveniente, sem preocupações com o formato, localização ou método
de acesso aos dados. Aplicações diferentes poderão ter visões diferentes do BD permitindo
DOUJF
alterações no BD com menor impacto sobre as aplicações, tornando possíveis

modificações no software ou no hardware sem necessidade de reprogramações e
facilitando o uso compartilhado dos dados uma vez que permite uma visão adequada às
necessidades das diversas aplicações sobre o mesmo conjunto de dados).
(VTXHPDV
A palavra HVTXHPD neste contexto deve ser entendida como GHVFULomR. Desta maneira,
esquema lógico é uma descrição da organização lógica dos dados e um esquema físico é uma
descrição da organização física dos dados.
Em uma arquitetura de dois esquemas, cada esquema lógico é definido em termos de esquema
físicos existentes. Deste modo, poderemos adicionar ou mudar esquemas lógicos facilmente.
Por outro lado, esta arquitetura causa uma grande dependência entre os esquemas lógico e
físico, e mudar um esquema físico pode ser muito complicado e causar grandes mudanças nos
esquemas lógicos existentes.
Em uma arquitetura de três esquemas, para isolar os esquemas lógico e físico, introduzimos
um esquema intermediário. Assim teremos:
• Um esquema externo ou lógico que consiste dos dados tais como estes são vistos pelos
programas aplicativos;
• Um esquema intermediário ou conceitual que consiste de uma descrição global e não

redundante do BD a nível conceitual;
• Um esquema interno ou físico que consiste dos dados tais como estes são armazenados em
dispositivos físicos.
Cada esquema lógico é definido em termos de esquemas conceituais, e estes por sua vez, são
definidos em termos de esquemas físicos. Uma vez que o esquema conceitual é não
redundante, mudanças no esquema físico só afetam uma pequena parte do esquema conceitual,
levando a uma maior simplicidade e facilidade na realização de mudanças no esquema físico
nesta arquitetura do que na de dois esquemas.
DOUJF
Com isso, poderemos distinguir dois tipos de independência de dados: a independência lógica
dos dados (mudanças na visão do BD de um programa aplicativo não afetam as visões que
outros programas aplicativos possam ter do BD) e a independência física dos dados (mudanças
na estrutura física do BD deixam intacto o esquema lógico, isto é, nenhum programa
aplicativo tem sua visão do BD afetada).
0RGHORV)tVLFRV
Entendemos por modelo físico a forma (estrutura) usada internamente para organizar os dados
no BD, isto é, a forma como os dados estão armazenados. Os três modelos mais consagrados
são os modelos de rede, hierárquico e o relacional.
Para efeitos deste estudo, concentraremos nossa atenção no modelo relacional que é de longe o
mais comumente empregado.
Podemos definir o modelo relacional como um modelo em que os conjuntos de dados são
representados por tabelas de valores. Cada tabela é bidimensional e organizada em linhas e
colunas. Cada elemento em um conjunto de dados é representado por uma linha na tabela,
cada atributo dos elementos de um conjunto é representado por uma coluna na tabela e cada
item de dado deste elemento é representado pelo valor da célula que ocupa na tabela.
Ex.: 0DWpULDV
Sigla Nome Nº Aulas/Semana

BDAD Banco de Dados 3
APSI Análise e Projeto de Sistemas de Informação 2
IART Inteligência Artificial 2
No modelo relacional, cada linha se compõe de apenas um tipo de registro, possui um número
fixo de atributos, é única (não é permitido a existência de linhas iguais) e possui pelo menos
um identificador (chave); os atributos têm valores sempre atômicos (não há grupos que se
repetem) e assumem valores em domínios de valores possíveis; o mesmo domínio pode ser
usado por diversos atributos; as linhas e colunas podem ser consideradas em qualquer
seqüência sem que a mudança de ordem afete as informações em qualquer momento.
DOUJF
Mais adiante voltaremos a falar do modelo relacional, uma vez que estudaremos com detalhes
a implementação relacional. A escolha do modelo relacional como objeto de estudo mais
profundo se deve ao fato de que este modelo é o modelo usado pelos SGBD mais em uso nos
dias de hoje.
'HVHQYROYLPHQWRGH6LVWHPDV
Numa abordagem moderna, a tarefa de desenvolvimento de sistemas pode ser enxergada em
três dimensões: a dimensão funcional, a dimensão de armazenamento e a dimensão de
transição de estados.
Como o objetivo deste curso é o projeto de BD, restringiremos nosso estudo somente à
dimensão de armazenamento. Achamos importante no entanto lembrar que os métodos
modernos de desenvolvimento de sistemas recomendam a seguinte ordem para a definição
destas três dimensões:
• Definição preliminar do modelo de armazenamento de dados;
• Definição do modelo funcional com revisão do modelo de armazenamento de dados;
• Definição do diagrama de estados do sistema, isto é, do diálogo do sistema através de

janelas, botões, menus, submenus, comandos, teclas, etc.
Uma técnica moderna para representar a estrutura de armazenamento de dados em um sistema

de computação é a modelagem de dados. Dentre os modelos para a realização desta tarefa,
escolhemos estudar uma extensão do Modelo Entidade Relacionamento (MER), o MER
Estendido Binário, que, doravante, chamaremos apenas de MER.
A fim de diminuir a dificuldade de absorção das idéias que passaremos a abordar a seguir,
faremos uma analogia entre os termos comumente utilizados na modelagem conceitual,
relacional e tradicional:
&RQFHLWXDO 5HODFLRQDO 7UDGLFLRQDO

Atributo Coluna, ou Campo, ou
item de dado item de dado
Entidade Tabela, ou Arquivo
DOUJF
Relação
Objeto Linha Registro
Relacionamento Tabelas auxiliares para Arquivos auxiliares para
ligação, ou ligação, ou
chaves estrangeiras chaves estrangeiras
Ligações Linhas das tabelas auxiliares Registros das tabelas auxiliares
para ligação, ou para ligação, ou
valores das chaves valores das chaves estrangeiras
estrangeiras
$GPLQLVWUDomRGH'DGRV
Tradicionalmente, considera-se que uma empresa, para alcançar seus objetivos, deve usar de
maneira eficaz e racional seus recursos. Estes recursos são normalmente separados em
recursos humanos, recursos financeiros, máquinas e equipamentos, e tecnologia. Pode-se
observar no entanto, que a esta lista, cada dia se torna mais importante acrescentar como um
recurso da empresa os seus dados.
Cada órgão encarregado de administrar um destes recursos tem como funções recrutar,
selecionar e captar novos recursos; garantir a plena disponibilidade dos recursos
administrados; evitar o uso indevido dos recursos da empresa; e promover o uso eficaz dos
recursos.
Para executar estas tarefas com relação aos dados, torna-se necessário o surgimento da figura
do Administrador de Dados comas funções de gerenciar os dados enquanto recursos da
empresa, construir e manter o modelo conceitual dos dados da empresa, manter um registro
com a descrição de todos os dados existentes na empresa, divulgar aos usuários e profissionais
de informática as descrições dos dados da empresa, promover a integração entre os diversos
sistemas de aplicação, e facilitar o desenvolvimento de aplicações para as quais já existem
dados.
(QJHQKDULDGH%DQFRVGH'DGRV
Tradicionalmente, existem duas maneiras para se abordar o desenvolvimento de sistemas: a
partir das funções e a partir dos dados. Uma boa razão para a abordagem funcional é o fato de
um sistema ser uma função, sendo análise a atividade de decompor esta função em suas
DOUJF
funções componentes e estas em suas componentes menores. A abordagem funcional parece

ser uma abordagem bastante natural para sistemas. Por outro lado, os dados são mais estáveis
que as funções e a abordagem funcional normalmente leva a sistemas isolados e arquivos
redundantes, enquanto a abordagem pelos dados permite obter sistemas que compartilham
dados.
Estudos a respeito da evolução das empresas no que diz respeito ao uso do processamento de
dados apontam seis estágios pelos quais passam as empresas: iniciação, contágio, controle,
integração, administração de dados e maturidade. Segundo estes estudos, esta evolução é
gradativa, reflete a progressiva maturação dos profissionais de informática e dos usuários, e
não pode ser artificialmente apressada. Nos primeiros estágios a empresa se preocupa com a
automatização das funções mudando o enfoque gradativamente até que entre o terceiro e o
quarto estágio, quando começa a mudar o foco das funções para os dados. Assim, o estágio em
que a empresa se encontra pode sugerir o enfoque adequado a se dar nos desenvolvimentos da
mesma.
Nem todos os sistemas de computação fazem uso de bancos de dados, mas para aqueles que
fazem, o elemento sistêmico BD é na maioria das vezes um elemento de importância vital.
No processo de engenharia de BD, segue-se uma rotina de vários passos que conduzem do
mundo real à criação de um BD.
• mundo real do ponto de vista formal é muito nebuloso. Este mundo é povoado por seres,
fatos, coisas, etc. Faz-se necessária uma organização deste mundo. o que normalmente se
dá através do levantamento de informações a respeito da porção do mundo real que é de
interesse no escopo computacional em questão. Estas informações, organizadas ainda de
uma forma informal, são constituídas por relatórios escritos em uma linguagem natural
(português, inglês, etc.).
Podem conter um simbolismo difícil de ser entendido. Este é um nível dito descritivo, pois
procura-se descrever o mundo real por meio de frases. Não existem regras formais para
desenvolver este modelo, pois tanto o mundo real quanto o modelo descritivo não são
formais.
DOUJF
• Vencidas todas estas dificuldades e de posse de um modelo descritivo do mundo real,

poderemos passar à descrição das estruturas e transações envolvidas no modelo descritivo,
construindo o modelo conceitual do BD.
O modelo aqui desenvolvido deve ser estritamente formal, o mais próximo possível dos
formalismo matemático. Este modelo em geral é feito baseado em símbolos para os quais
deve haver uma conceituação rigorosa.
Sem dúvida podemos dizer que o modelo descritivo também é um modelo conceitual, mas
sempre que nos referirmos ao modelo conceitual da base de dados, estaremos nos referindo
a este modelo conceitual formal.
Em geral, a construção do modelo conceitual de um BD se processa em duas fases: a fase

dos modelos conceituais parciais e a do modelo conceitual global. Exploraremos com mais
riqueza de detalhes esta modelagem a medida que prosseguirmos nosso estudo.
• Desta fase para a frente, a tarefa modelar um BD se torna bastante mais amena, uma vez
que não mais lidamos com informações informais, mas sim com um modelo conceitual
bem e formalmente definido.
Nosso objetivo nesta fase é a construção do modelo interno do BD, ou seja definir as
representações internas dos dados e dos programas. Este modelo em geral permanece
sempre um mistério para os usuários do BD que desconhecem (uma vez que não lhes
interessa) como seus dados estão descritos internamente, isto é, como as estruturas de
dados fornecidas por eles são gravadas internamente no BD.
Esta fase também é feita em duas etapas: a construção de um modelo interno preliminar e a
otimização deste. Voltaremos a abordar este assunto mais para frente nesta apostila.
• Por fim, vem a fase da implementação dos programas que manipularão os dados a fim de
realizar os objetivos funcionais inicialmente estabelecidos. No caso de realizarmos a
implementação do BD fazendo uso de um SGBD, desconheceremos nós também a
maneira pela qual os dados serão internamente armazenados e interagiremos com o SGBD
para solicitar o acesso ao BD. No caso da implementação ser feita com a utilização de uma
linguagem tradicional de programação, teremos que nos preocupar mais ou menos com
DOUJF
este tipo de coisa, dependendo dos recursos que a linguagem de programação coloque à
disposição.
$&RQVWUXomRGR0RGHOR'HVFULWLYR
Esta fase se caracteriza por ser extremamente subjetiva e de vital importância para o sucesso
do sistema de computação que se tenciona desenvolver. Diversos fatores contribuem
grandemente para a dificuldade da execução desta fase a saber:
• Dificuldades de ordem técnica (estas dificuldades de certa forma são até esperadas, tendo
em vista a inexistência de métodos precisos para a realização das tarefas desta fase);
• Dificuldades de natureza política (quando os grupos de usuários não exista, possuem

interesses conflitantes e não se consegue uma solução consensual);
• Problemas de comunicação (sabemos que a linguagem que utilizamos para nos

comunicarmos é uma linguagem informal e imprecisa, gerando a possibilidade de
múltiplas interpretações. Sabemos ainda que outra grande fonte de problemas reside na
diferença de contextos e vocabulários que existe entre profissionais de informática e
usuários de uma maneira geral);
• Omissões voluntárias ou involuntárias de informação (as omissões voluntárias são via de

regra causadas por uma sensação de insegurança por parte dos usuários com relação ao
sistema que se pretende implantar. Muitos por questão de ignorância ou desinformação
temem perder seus lugares com o advento do sistema. Por outro lado as omissões
involuntárias em geral são causadas pelo fato de que para os usuários, muitas das coisas
que fazem parte das suas atividades são tão obvias que eles acham irrelevantes, acabando
por omitir informações importantes);
• Ignorância e mistificação a cerca do que seja e do que seja capaz um computador (ainda
nos dias de hoje, há quem pense que basta por no computador para ter tudo resolvido, há
quem ainda veja o computador como uma caixinha de milagres);
• Tabu (muitos usuários vêm as coisas relacionadas com a área como algo hermético, onde
sua entrada é vedada. Muitos ainda acham tudo relacionado com informática
DOUJF
extremamente complicado e nutrem uma espécie de aversão preconceituosa a tudo

relacionado à computação. Neste contexto, não tentam entender nossos "feed-backs",
acham de devemos saber o que estamos fazendo, para que se intrometer no assunto?);
• Visualização global (muitas vezes, principalmente quando ainda nos falta alguma
experiência, podemos encontrar dificuldade em enxergar o problema a enfrentar como um
todo, nos sentindo perdidos em meio aos inúmeros detalhes envolvidos na situação).
Chega o momento de definirmos mais formalmente um conceito ao qual de certa forma já

fizemos alusão anteriormente e que constitui peça fundamental para a elaboração do produto
desta fase.
Já mencionamos anteriormente que a tecnologia de BD vem para aglutinar dados de

aplicações tradicionalmente esparsos, redundantes, incoerentes e incompletos. Desta maneira,
todas aplicações deixariam de manter seus próprios arquivos e passariam a armazenar seus
dados no BD.
Naturalmente neste processo de aglutinação, acabaremos angariando para o BD dados que são
de interesse de certas aplicações mas não de outras. Uma vez que cada aplicação manipulado
BD a parte que lhe é devida e desconhece todo o resto dos dados que por ventura lá existam
armazenados, podemos dizer que as aplicações não possuem uma visão global do BD, cada
aplicação vê o BD como sendo o subconjunto dos dados do BD que utiliza para a realização
de suas funções. Assim, existirão várias visões do BD, uma para cada aplicação.
Mais formalmente, definiremos visão como sendo um par ordenado (dados, operações) que
descreve os dados do futuro BD do modo que deverão ser vistos por uma aplicação e as
operações que serão feitas com estes dados.
O produto desta fase deverá ser uma especificação de todas as visões que estão envolvidas na
porção do mundo real de interesse.
20(5
Iniciaremos o estudo do MER através de algumas definições. Entenderemos por objeto
qualquer coisa que exista no mundo real da qual se tenha necessidade de ter informações.
DOUJF
Entenderemos por entidade um conjunto de objetos semelhantes segundo algum critério.

Entenderemos por ligação qualquer vínculo entre objetos do qual se tenha necessidade de ter
informações. Entenderemos por relacionamento um conjunto de ligações semelhantes segundo
algum critério. Entenderemos por atributo qualquer informação a respeito de um objeto ou de
uma ligação entre objetos da qual se tenha necessidade. Por fim, entenderemos por restrição
qualquer exigência que se faça a respeito de qualquer dos itens que definimos acima.
O MER é um modelo que tem como meio de expressão um simbolismo gráfico.
Entidades são representadas por um retângulo com uma inscrição interna representando o
nome da entidade. Os nomes são no singular por convenção. Considere os exemplos de
entidades abaixo.
Relacionamentos são representados por um losango com uma inscrição interna representando
o nome do relacionamento. Os nomes são no singular por convenção. Como um
relacionamento é um conjunto de ligações semelhantes, e tendo em vista que cada ligação
vincula sempre dois objetos, temos que sempre existem dois sentidos associados a uma
ligação, e em última instância a um relacionamento. Acrescentamos por esta razão ao losango
duas setas em sentidos opostos representando dos dois sentidos das ligações do
relacionamento. Sobre estas setas, inscreve-se frases especificando cada um dos dois sentidos.
O exemplo abaixo, simboliza um relacionamento que contêm ligações que vinculam objetos
que são empregados no mundo real com objetos que são departamentos da empresa no mundo
real.
DOUJF
Relacionamentos têm sempre duas cardinalidades (uma para cada sentido do relacionamento)
que expressam restrições com respeito àquele relacionamento. Uma cardinalidade é escrita
como um par de valores numéricos separados por uma vírgula. N representa um valor
desconhecido, podendo ser arbitrariamente grande. As cardinalidades de um relacionamento
costumam ser posicionadas em lados opostos do losango, no sentido das setas. O exemplo
abaixo já contém uma carga semântica um pouco mais pesada que os anteriores. O que
queremos dizer com o modelo abaixo é que funcionários se vinculam com dependentes pelo
relacionamento posse. As setas nos dizem que funcionários têm dependentes e que
dependentes são de funcionários. Lemos o modelo abaixo da seguinte maneira: um
funcionário tem de 0 até N dependentes, e um dependente é de 1 e sempre um funcionário.
Como no mundo real cada objeto pode ter diversos relacionamentos diferentes, também no
modelo poderemos expressar este fato. Considere o exemplo abaixo. Nele expressamos que
clientes se relacionam pelo relacionamento compra com produtos e também com duplicatas a
pagar pelo relacionamento posse. Cada cliente compra de 0 até N produtos e cada produto é
comprado por de 0 até N clientes. Cada cliente tem de 0 até N duplicatas a pagar e cada
duplicata a pagar e de 1 e sempre 1 cliente.
DOUJF
Também à semelhança do mundo real, duas entidades podem ter mais de um relacionamento.
Veja o exemplo abaixo. Nele, funcionários se relacionam com projetos pelos relacionamentos
lotação e gerência. Cada funcionário está lotado em 1 e sempre 1 projeto e cada projeto lota de
1 até N funcionários. Além disto, cada funcionário pode gerenciar ou não um projeto e cada
projeto é gerenciado por 1 e sempre 1 funcionário.
Auto relacionamentos são relacionamentos que expressam vínculos entre objetos de uma
mesma entidade. No exemplo abaixo temos dois casos de auto relacionamentos. No primeiro,
peças se relacionam com peças pelo relacionamento composição. Cada peça compõe de 0 até
N outras peças e por outro lado cada peça pode compor de 0 até N outras peças. No segundo,
DOUJF
pessoas se relacionam com pessoas pelo relacionamento casamento. Cada pessoa pode ser
casada ou não com outra pessoa.
Entidades podem ser fracas com relação a outras. Isto significa que não fazem sentido se a
entidade dita forte. Esta relação de fraqueza é expressa no modelo como um relacionamento
com um pequeno círculo de um dos lados. A entidade do lado do círculo é a entidade fraca. No
exemplo abaixo, mostramos que a entidade dependente, como o próprio nome diz, é fraca pelo
relacionamento de posse com a entidade funcionário, isto é, não tem sentido sem a entidade
funcionário.
O MER é um modelo para expressar dados e seus vínculos que se tem interesse de manter. Por
esta razão, não expressamos em um MER nem operações (uma vez que não são dados nem
vínculos entre dados) nem dados sobre os quais não se tenha interesse. Assim, no exemplo
abaixo, mostramos a entidade paciente relacionada com a entidade consulta pelos
relacionamentos agendamento e desagendamento. A menos que se tenha uma boa razão para
se guardar desagendamentos, desagendamento é uma operação que se faz sobre o
relacionamento agendamento. Quando desejamos agendar uma consulta, geramos uma ligação
DOUJF
no relacionamento agendamento, quando desejamos desagendar uma consulta, simplesmente

retiramos uma ligação do relacionamento agendamento, não precisamos de um relacionamento
desagendamento.
Como definimos acima, atributos representam as informações que se deseja manter a respeito
de uma entidade ou relacionamento.
Segundo suas funções, os atributos se classificam em chave primária, chave adicional, super
chave, chave secundária e atributo comum. Mais para frente veremos que existe ainda um
outro tipo de atributo, mas deixemos para comentar mais a respeito adiante.
Chave primária é o menor conjunto de atributos que identifica unicamente um único objeto em
uma entidade ou uma única ligação em um relacionamento. Toda entidade e todo
relacionamento possui chave primária, embora nos relacionamentos ela não seja indicada, mas
sim implicitamente conhecida como a concatenação das chaves primárias das entidades
relacionadas.
Às vezes, esta combinação de chaves não é o suficiente para identificar unicamente uma
ligação em um relacionamento (pela possibilidade da existência de mais de uma ligação entre
os mesmos dois objetos das mesmas duas entidades em um relacionamento). Nestes casos,
existem duas opções: colocar uma chave adicional no relacionamento (que em conjunto com
as chaves primárias implícitas identificaria unicamente uma ligação) ou colocar uma super
DOUJF
chave no relacionamento (que sozinha identificaria unicamente uma ligação no

relacionamento, se sobreporia às chaves primárias implícitas que continuariam implícitas, mas
sem propriedades de chave primária).
Chaves secundárias são chaves que não identificam unicamente um único objeto em uma
entidade ou uma única ligação em um relacionamento, mas sim um grupos deles.
Por fim, atributos comuns são atributos sem nenhuma função especial, representam tão
somente informações que se deseje manter sobre objetos de entidades ou ligações de
relacionamentos.
Vale a pena ressaltar o fato de que não se pode expressar com o MER atributos iterativos
(repetitivos), por esta razão não se pode ter atributos com nome no plural.
Aconselha-se que em paralelo à construção do modelo, vá se construindo também um

GLFLRQiULRGHGDGRV contendo informações sobre os dados do BD (nome, tipo, tamanho, visões
em que está envolvido e em que operações, etc.).
Qualquer que seja o tipo do atributo, eles sempre são representados por uma haste com um
símbolo em uma das extremidades que indica o tipo do atributo seguido do nome do atributo.
Veja abaixo o símbolo de cada um dos atributos acima mencionados.
O símbolo de chave primária é um asterisco seguido opcionalmente por um número. Este

número serve para numerar os componentes da chave primária em caso de chave composta.
O símbolo de chave adicional é um sinal de mais seguido opcionalmente por um número. Este
número serve para os mesmos fins do número que segue opcionalmente o símbolo de chave
primária.
DOUJF
O símbolo de super chave é um sinal de sustenido seguido opcionalmente por um número.

Este número serve para os mesmos fins do número que segue opcionalmente o símbolo de
chave primária.
O símbolo de chave secundária é uma letra S seguida opcionalmente por um número. Este
número serve para diferenciar as chaves secundárias em caso de haver mais de uma. Este
número pode ser seguido opcionalmente por outro número separado do primeiro por uma
vírgula. Este segundo número serve para os mesmos fins do número que segue opcionalmente
o símbolo de chave primária.
Veja no exemplo abaixo atributos apropriadamente dispostos em entidades e relacionamentos.

O que se pretende expressar é que a entidade cliente tem com chave primária o atributo CGC,
como uma chave secundária o atributo RamAtivdd, como outra chave secundária composta os
atributos Estado e Cidade, e com o atributo comum RazSoc. A entidade produto tem como
chave primária o atributo Cod, e como atributo comum Nome. Por fim, o relacionamento
compra tem como chave adicionam o atributo Data, e como atributo comum Qtd.
Às vezes, entidades se classificam em alguns tipos, cada tipo tendo atributos próprios
diferenciados. Surge para isto o conceito de hierarquia. Existem dois tipos de hierarquias
conforme pode-se observar no exemplo abaixo. O primeiro desenho representa uma hierarquia
sem interseção e o segundo uma com interseção.
Qualquer que seja o tipo de uma hierarquia, a entidade superior detém os atributos comuns a
todos os membros da hierarquia e as inferiores os atributos próprios a cada uma delas.
DOUJF
É perfeitamente possível se ter árvores de hierarquia mais profundas, isto é, hierarquias sob
hierarquias. Também é possível se ter mais de uma hierarquia sob uma mesma entidade. Todas
entidades que participam de uma hierarquia são entidades como outra qualquer, portanto
podem ter seus atributos e relacionamentos. Não faz sentido uma hierarquia em que não haja
atributos ou relacionamentos próprios nas entidades inferiores.
No primeiro desenho, vemos que veículos se classificam em aéreo, terrestre e marítimo,

podendo um veículo ser de um, dois ou dos três tipos concomitantemente.
No segundo desenho, vemos que funcionários se classificam em motorista, secretária e

engenheiro, não podendo alguém que ocupa uma função ocupar também outra.
DOUJF
Surge com as hierarquias sem interseção aquele último tipo de atributo que havíamos
mencionado acima. Trata-se do atributo classificador, que serve para dizer de que tipo (onde
se encontra nas entidades inferiores) é cada objeto da entidade superior.
Este tipo de atributo é representado por uma haste seguida por uma letra C e pelo nome do
atributo. Note no exemplo abaixo, que além da novidade do atributo classificador, não se usa
colocar chave primária nas entidades inferiores de uma hierarquia uma vez que estas têm
como chave primária a chave primária da entidade superior.
O último conceito que introduziremos é o conceito de agregação. Usa-se agregação quando se

tem duas entidades relacionadas por um relacionamento e se deseja relacionar através de outro
relacionamento uma terceira entidade não com a primeira entidade, nem com a segunda, mas
com as duas relacionadas. Agregados têm como chave primária a chave do seu relacionamento
interno.
DOUJF
No exemplo abaixo, temos a entidade aluno relacionada não coma entidade professor, não
com a entidade matéria, mas sim com ambas relacionadas pelo relacionamento ministério.
Segue agora um exemplo mais complexo que envolve quase todos conceitos apresentados até
agora.
Nele temos a entidade matéria relacionada com a entidade turma pelo relacionamento posse
(cada matéria tem de 0 até N turmas e cada turma é de 1 até N matérias, sendo a entidade
turma fraca pelo relacionamento posse com a entidade matéria.
Estas duas entidades relacionadas, se relacionam pelo relacionamento ministério com a

entidade professor (cada turma de matéria se é ministrada por 1 e sempre 1 professor e cada
professor ministra de 0 até N turma de matéria), pelo relacionamento faz com a entidade aluno
(cada turma de matéria é feita por de 0 até N alunos e cada aluno faz de 0 até N turma de
matéria) e pelo relacionamento fez também com a entidade aluno (cada turma de matéria foi
feita por de 0 até N alunos e cada aluno fez de 0 até N turma de matéria).
A entidade matéria se relaciona pelo relacionamento PreReq consigo própria (cada matéria é
pré-requisito de 0 até N matérias, podendo também ter como pré-requisito de 0 até N
matérias).
DOUJF
As entidades professor, graduação e pós-graduação formam uma hierarquia com interseção,

sendo a primeira a entidade superior e as duas últimas entidades inferiores.
A entidade matéria tem chave primária Cod e atributos comuns Nome e Ementa. A entidade
turma tem como chave primária os atributos Letra, Semestre e Ano. A entidade professor tem
como chave primária Matr e como atributos comuns Nome e Ender. A entidade graduação que
representa os professores de graduação, tem como chave primária implícita Matr e como
atributo comum próprio o atributo Local da Graduação. A entidade pós-graduação que
representa os professores de pós-graduação, tem a mesma chave primária implícita
mencionada acima e como atributo comum próprio o atributo Área de Orientação. A entidade
aluno tem como chave primária o atributo RA e como atributos comuns Nome e Ender. O
relacionamento fez tem como atributos comuns Nota e Freq. Todos os relacionamentos têm
como chave primária as chaves das duas entidades que eles relacionam. A chave da entidade
agregada é a chave do relacionamento posse em seu interior.
DOUJF
$&RQVWUXomRGR0RGHOR&RQFHLWXDO
Poderíamos definir esta fase como sendo a construção de uma representação do conhecimento
de uma organização orientada para a representação dos dados envolvidos e das relações dos
dados entre si. Tem-se por objetivo captar o mais fielmente possível a realidade da
organização a fim de prover base para a implantação física de um BD.
Como dissemos anteriormente, a construção do modelo conceitual é feita normalmente em

duas fases: a construção dos modelos conceituais parciais (um para cada visão identificada na
fase anterior) e a integração deles na formação do modelo conceitual global.
$&RQVWUXomRGRV0RGHORV&RQFHLWXDLV3DUFLDLV
Esta parte do modelo conceitual tem duas componentes: uma representação gráfica e uma
linguagem descritiva. Representaremos graficamente os dados e suas relações e nos
utilizaremos da linguagem descritiva a fim de descrever as operações que são realizadas sobre
os dados. Desta maneira, teremos expressos no modelo tanto os aspectos estáticos (dados)
como dinâmicos (operações). Deve-se ainda ter expresso neste modelo restrições semânticas e
de integridade.
Como representação gráfica dos dados, suas relações e algumas restrições semânticas e de
integridade, sugerimos que se use o MER. Como linguagem descritiva das operações que são
realizadas sobre os dados e de algumas restrições semânticas e de integridade que não
puderam ser representadas graficamente através do MER, sugerimos que se use algo como
português estruturado.
É imprescindível advertir que durante a construção dos MER, deve-se evitar ao máximo
pensar em processos, arquivos e fluxos de informação. Vale a pena ressaltar que no modelo de
uma visão, só devem aparecer os dados que são usados naquela visão, e da maneira como são
usados. Assim, é perfeitamente possível haver uma entidade ou um relacionamento em uma
visão com um conjunto de atributos diferentes daquele que possua em uma outra visão. Além
disto, podem existir atributos que em uma visão sejam comuns e em outra sejam chaves
secundárias, e assim por diante. O atributo chave primária deve ser o mesmo sempre em todas
as visões tanto para entidades como para relacionamentos. A cardinalidade de um
DOUJF
relacionamento também é sempre a mesma em todas as visões. É possível que uma entidade
apareça em uma visão como parte de uma hierarquia, com determinados relacionamentos ou
como parte de um agregado, e em outra visão não.
$&RQVWUXomRGR0RGHOR&RQFHLWXDO*OREDO
O modelo conceitual global é construído a partir dos modelos conceituais parciais de uma
maneira incremental. A maneira mais simples que conheço de se entender como se dá a
construção do modelo conceitual global é através de uma alegoria.
Basicamente, tudo que deve ser feito é transportar para o papel em branco onde será
construído o modelo conceitual global, todos os modelos conceituais parciais com o cuidado
de fazer com que elementos do modelo parcial (entidades, relacionamentos atributos,
agregados e hierarquias) que está sendo transportado que já se encontrem presentes no modelo
global se sobreponham de maneira incremental.
Desta maneira, se ao transferirmos uma entidade ou um relacionamento de um modelo parcial

para o modelo global observarmos que esta entidade ainda não se encontra transferida para o
modelo global, tudo o que teremos que fazer será copiá-la para lá. Se ao contrário,
observarmos que esta entidade já se encontra transferida, tudo que teremos que fazer será
adequar os atributos no modelo global.
Antes de dizermos como proceder essa adequação, convém agora definirmos alguns termos
que empregaremos a seguir. Entenderemos por atributo sem função especial qualquer atributo
que não seja chave primária, chave adicional, super chave, chave secundária, nem
classificador. Entenderemos por atributo com função especial aqueles atributos que possuírem
uma das funções acima mencionadas (chave primária, chave adicional, super chave, chave
secundária ou classificador).
Passaremos agora a descrever o processo de adequação dos atributos no modelo conceitual

global quando da transferência de uma entidade ou relacionamento já presente neste modelo.
Se no modelo parcial houverem atributos que não se encontrem presentes no modelo global,
tudo que temos que fazer será transportá-los para o modelo global.
DOUJF
Se no modelo parcial houverem atributos sem função especial que já se encontrem presentes
no modelo global sem função especial prevalecerá a função que já se possuem no modelo
global, e tudo ficará como está.
Se der o contrário, no parcial houverem atributos com função especial que já se encontrem
presentes no modelo global sem função especial, prevalecerá a função que possuem no modelo
parcial, e alteraremos o modelo global.
Se no modelo parcial houver um atributo com função especial que já se encontra presente no
modelo global também com função especial, neste caso o atributo passará a acumular funções.
Agregados e hierarquias são simplesmente transportados dos modelos parciais para o global.
$&RQVWUXomRGR0RGHOR,QWHUQR
Como já havíamos comentado anteriormente, esta fase se compõe de duas subfases (a
construção do modelo interno preliminar e a otimização deste) que passaremos a detalhar em
seguida.
$&RQVWUXomRGR0RGHOR,QWHUQR3UHOLPLQDU
O objetivo desta fase é trabalhar o modelo conceitual global a fim de eliminar, ou melhor
transformar em entidade qualquer coisa presente no modelo conceitual global que não seja
entidade. O modelo conceitual global trabalhado para ser constituído somente por entidades
será o modelo interno preliminar.
Como perceberemos a seguir, os casos possíveis que poderemos ter que analisar são
virtualmente infinitos. Desta maneira, nosso objetivo nesta parte do estudo é o de formar uma
linha de pensamento que possa ser utilizada quando em face a uma situação real nova.
Por simplicidade, inicialmente deixaremos de lado qualquer tipo de MER diferente de duas
entidades relacionadas por um relacionamento. Qualquer que seja a cardinalidade do
relacionamento, sempre é possível reduzir o MER a três entidades. Em alguns casos é possível
a redução a duas e até mesmo a uma. Seremos sempre ambiciosos, desejando a máxima
redução possível. Consideraremos a seguir algumas possibilidades para a cardinalidade do
relacionamento.
DOUJF
• &DVR
Nesta situação, cada objeto de A se relaciona com exatamente um objeto de B (um objeto
de A possui exatamente uma ligação no relacionamento R) e vice versa.
Desta maneira é possível a redução do MER a uma só entidade ARB que aglutinaria os
atributos de A, de R e de B, naturalmente eliminando os possíveis atributos comuns.
• &DVR1
Neste caso, cada objeto de A pode estar relacionado com de 1a N objetos de B (um objeto
de A pode possuir de 1 a N ligações no relacionamento R). B por sua vez sempre se
relaciona com exatamente um objeto de A (um objeto de B pode possuir uma e somente
uma ligação no relacionamento R).
Como não somos capazes de precisar a quantidade de relacionamentos que um objeto de A

poderá vir a ter com um objeto de B, não poderemos aglutinar o MER em uma única
entidade onde cada objeto representasse um objeto de A, todos seus relacionamentos com
objetos de B, e os próprios objetos de B relacionados.
Para alcançarmos a solução mais ambiciosa (uma entidade ARB), existe ainda uma
possibilidade. Podemos aglutinar o MER em uma única entidade onde cada objeto
representasse um objeto de A, um relacionamento com um objeto de B, e o próprio objeto
de B relacionado. Neste caso, como os objetos de A podem ter muitos relacionamentos
com objetos de B, teremos muitos objetos na entidade aglutinada associados a um único
objeto de A. Isto naturalmente caracteriza uma redundância, mas se soubermos de antemão
que na prática a probabilidade dos objetos de A terem muitos relacionamentos com objetos
de B é baixa, poderemos optar por esta solução.
Existem ainda duas possibilidades mais modestas (duas entidade): aglutinar A com R em
uma entidade AR deixando B só; e deixar A só aglutinando R com B em uma entidade RB.
A primeira possibilidade não faz muito sentido, pois encerra os mesmos problemas da
aglutinação em uma única entidade. Assim temos como viável somente a segunda
possibilidade.
DOUJF
• &DVR11
Neste caso, cada objeto de A pode estar relacionado com de 1a N objetos de B (podendo
um objeto de A possuir de 1 a N ligações no relacionamento R) e vice versa.
Podemos raciocinar de maneira semelhante à que utilizamos no caso anterior.
Para aglutinarmos o MER em uma única entidade ARB, teríamos que garantir que a
probabilidade dos objetos de A terem muitos relacionamentos com objetos de B é baixa e
também que a probabilidade dos objetos de B terem muitos relacionamentos como objetos
de A é baixa.
Para aglutinarmos o MER em duas entidade AR e B teríamos que garantir que a

probabilidade dos objetos de A terem muitos relacionamentos com objetos de B é baixa.
Para aglutinarmos o MER em duas entidade A e RB teríamos que garantir que a

probabilidade dos objetos de B terem muitos relacionamentos com objetos de A é baixa.
Sempre podemos ficar com três entidades A, R, e B. Vale a pena lembrar, que a maneira
de julgar se uma probabilidade é baixa ou não depende do caso que tratamos (depende
fundamentalmente do número de objetos e ligações que se espera ter nas entidades e
relacionamento respectivamente).
• &DVR
Neste caso, cada objeto de A pode estar relacionado com nenhum ou exatamente um
objeto de B (um objeto de A pode não ter, ou ter exatamente uma ligação no
relacionamento R). B por sua vez, sempre se relaciona com exatamente um objeto de A
(um objeto de B tem exatamente uma ligação no relacionamento R).
Podemos levantar duas possibilidades uma mais ambiciosa (aglutinar A, R e B em uma

entidade ARB, deixando os atributos de R e de B nulos no caso de um objeto de A não ter
relacionamentos) e uma mais modesta (aglutinar R com B na entidade RB deixando A só).
DOUJF
Se a probabilidade de um objeto de A não possuir relacionamento com um objeto de B for

baixa, poderemos optar pela primeira solução. Em qualquer caso, sempre poderemos ficar
com a segunda solução.
O raciocínio para o caso dos auto relacionamentos é idêntico ao que tivemos quando tratamos
dos relacionamentos comuns. No caso de cardinalidade 1,1 - 1,1 teremos uma única entidade
AR que aglutina dois objetos de A e uma ligação de R e nos casos 1,1 - 1,N e 1,N - 1,N
poderemos ter uma única entidade ou duas. Ampliemos agora nosso universo, deixando de
lado somente os agregados e as hierarquias e passando a trabalhar com MER com diversas
entidades e relacionamentos.
O processo é simples. Escolhemos sempre um relacionamento e suas entidades (talvez uma só,
no caso de auto relacionamento)para começar. Procedemos conforme o raciocínio
desenvolvido acima. Se alguma das entidades primitivas possuíam algum relacionamento com
outra entidade não considerada na operação, este relacionamento é transferido para a entidade
que aglutinou a entidade primitiva (no caso de ter havido aglutinação). Repete-se este processo
até que não se tenha mais relacionamentos no MER.
O caso das hierarquias é o mais simples de todos, em geral o processo se resume em eliminar a
hierarquia, deixando apenas entidades soltas. Existem no entanto algumas outras
possibilidades que passaremos a considerar.
No caso das hierarquias sem interseção cuja entidade superior não possua relacionamento,
poderemos fazer uma espécie de implosão, trazendo os objetos apropriados da entidade
superior para cada entidade inferior.
No caso das hierarquias com interseção cuja entidade superior não possua relacionamento,
poderemos fazer a mesma implosão, mas neste caso haverá redundância que teremos que
considerar probabilisticamente a viabilidade de manter.
No caso dos agregados, procedemos com segue. Faremos o processo comum com o
relacionamento e a(s) entidade(s) interna(s) ao agregado. Eliminamos o agregado, deixando
somente as entidades possivelmente aglutinadas em seu interior. Todos os relacionamentos
DOUJF
com o agregado deverão ser transferidos para a entidade que aglutinou o relacionamento que
estava dentro do antigo agregado.
$&RQVWUXomRGR0RGHOR,QWHUQR2WLPL]DGR
Quando falamos em otimização do modelo interno, falamos em particionamentos de arquivos.
Particionamentos podem ser horizontais ou verticais. Entendemos por particionamento
horizontal de um arquivo, a separação de grupos de registros deste arquivo em arquivos
separados; e por particionamento vertical de um arquivo, a separação de campos deste arquivo
em arquivos separados.
É importante notar, que pode-se ter interseções, isto é, em um particionamento horizontal

podemos levar certos grupos de registros para mais de um arquivo, e em um particionamento
vertical podemos levar certos grupos de campos para mais de um arquivo.
Vale a pena ressaltar, que um arquivo pode ser particionado tanto horizontal como
verticalmente em qualquer ordem. Os arquivos resultantes de um particionamento também
podem ser particionados em mais arquivos.
Particionamentos têm por objetivo isolar em arquivos separados e menores, informações que
possuem uma grande taxa de acesso, aumentando assim a eficiência do acesso ao BD.
$,PSOHPHQWDomRGRV3URJUDPDV$SOLFDWLYRV
Agora que temos os arquivos físicos otimizados resultantes do modelagem, podemos retornar
aos modelos conceituais parciais (visões) para a implementação do algoritmo em português
estruturado associado a cada visão, que poderá ser feita sob um SGBD ou em uma linguagem
de programação adequada.
/LQJXDJHQVGH&RQVXOWD
Linguagens de consulta fazem parte de uma classe de linguagens que costumamos chamar de
linguagens de quarta geração.
Para melhor compreendermos o que são linguagens de quarta geração e as implicações

oriundas de seu advento, faremos uma analogia.
DOUJF
Antes da analogia propriamente dita, vale a pena equalizar os termos que usaremos.
Entendemos por linguagens de primeira geração a programação direto em linguagem de
máquina (binário), por linguagens de segunda geração os montadores de maneira geral e por
linguagens de terceira geração a grande maioria das linguagens de programação em uso nos
dias de hoje.
Consideremos o que se ganhou com o surgimento de cada nova geração de linguagens. Por um
lado, ganhou-se maior de conforto para o desenvolvedor na tarefa de escrever programas,
maiores facilidades de manutenção, maior vida útil dos sistemas e maior portabilidade.
Naturalmente, existe outro lado a se considerar ganhamos linguagens cada vez mais
específicas para determinados tipos de aplicação e programas bastante maiores e mais lentos.
Felizmente, com a constante melhoria do elemento hardware estas desvantagens têm se

tornado cada vez mais insignificantes, o que vêm possibilitando o surgimento de uma nova
geração de linguagens, a quarta.
Após o comentado acima a cerca das conseqüências do surgimento de cada geração de

linguagens, é fácil imaginar o que nos espera com o surgimento desta nova geração.
Não é sem motivo que introduzimos este tópico no estudo deste curso, como já dissemos, as
linguagens que estudaremos a seguir fazem parte da quarta geração de linguagens e mais
especificamente à família das linguagens de consulta.
Linguagens de consulta, como diz o próprio nome, são linguagens dedicadas à consulta a
bancos de dados. Existem inúmeras linguagens de consulta implementadas e em uso nos mais
diversos ambientes computacionais.
/LQJXDJHQVGH&RQVXOWDV7HyULFDV
Por um lado, seria de fato impraticável estudar exaustivamente todas as linguagens de
consulta, por outro, seria restringente o estudo de apenas uma ou outra delas.
Felizmente, todas elas possuem uma de duas raízes teóricas, e são a estas linguagens teóricas,
que serviram de base para as linguagens reais que temos nos dias de hoje, que nos
dedicaremos a seguir.
DOUJF
&iOFXOR5HODFLRQDO
Para podermos compreender cálculo relacional e conseguir expressar consultas a BD através
desta linguagem, primeiramente faz-se necessário que mudemos um pouco a visão que temos
de um BD.
Normalmente quando pensamos em BD, talvez por influência do modelo relacional, pensamos
em uma porção de tuplas organizadas em tabelas.
Desta maneira, quando desejamos obter informações a partir do BD, tudo que tem que ser
feito é construir a resposta através de particionamentos e junções, tanto verticais como
horizontais.
Introduziremos a seguir a forma que a linguagem cálculo relacional supõe estar o BD, não
significando isto, que o BD efetivamente esteja neste formato, o que vai depender da
implementação da linguagem baseada em cálculo relacional.
Para o cálculo relacional, o BD se compõe por uma grande quantidade de tuplas, todas
misturadas (não organizadas em tabelas). No entanto lá, não existem somente as tuplas que
poderíamos chamar de "originais", existem também todas a tuplas resultantes de todas as
possíveis partições das tuplas originais, e existem ainda, todas as tuplas resultantes de todas as
possíveis junções das tuplas originais entre si, das partições das tuplas originais entre si, e das
tuplas originais com as partições das tuplas originais.
Se pararmos para pensar por um momento, considerando que neste universo de tuplas existem
todas as tuplas originais, todas as partições das tuplas originais, todas as junções das tuplas
originais entre si, das partições das tuplas originais entre si, e das tuplas originais com as
partições das tuplas originais, chegaremos à conclusão de que neste universo de tuplas existem
respostas para todas as possíveis consultas que se queira farão BD, e tudo que temos que fazer
com o cálculo relacional é especificar, compor, selecionar deste universo a resposta que
desejamos.
Para especificar uma resposta em cálculo relacional, temos que antes estudar sua sintaxe e
semântica. Para tal, apresentaremos a seguir, uma seqüência de definições que nos dirão a
respeito desta sintaxe e semântica.
DOUJF
Assumiremos que se conheça o que é uma constante, uma variável, uma função, e argumentos
de uma função. Desta maneira, definimos:
Um predicado é o mesmo que uma função booleana;
Um término pode ser uma constante, uma variável ou um símbolo de função de grau N
seguida por N términos (seus N argumentos);
Uma fórmula atômica é um símbolo de predicado de grau N seguido por N términos (seus N
argumentos);
Para definir fórmula bem formada diremos:
• Toda fórmula atômica é uma fórmula bem formada;
• Se F é uma formula bem formada, então F (F negado) também é uma fórmula bem
formada;
• Se F1 e F2 são fórmulas bem formadas, então F1 ∧ F2 (F1 e F2), F1 ∨ F2 (F1 ou F2), F1 ⇒ F2

(F1 implica F2), (∃x) [F1, F2] (existe uma tupla X dentre as que satisfazem F1 que também
satisfaz F2) e (∀x) [F1, F2] (qualquer das tuplas X que satisfazem F1 também satisfazem F2)
também são fórmulas bem formadas.
Sendo t uma variável e Φ(t) uma fórmula bem formada em função de t, toda consulta em
cálculo relacional tem a forma: {t / Φ(t)}.
Consideraremos como predicados pré definidos todos os nomes de tabelas do BD. Estes
predicados recebem como argumento uma tupla (são predicados de grau 1) e têm o seguinte
comportamento: produzem resultado verdadeiro sempre que a tupla passada como argumento
for um membro daquela tabela, e resultado falso no caso contrário.
Consideraremos ainda como funções pré definidas as funções tuple (atr1,..., atrn) (que produz
como resultado uma tupla formada pela concatenação dos n atributos fornecidos como
argumento) e concat (tpl1,..., tpln) (que produz como resultado a concatenação das n tuplas
fornecidas como argumento).
DOUJF
Conhecidos os fundamentos do cálculo relacional, nada melhor para fixar os conceitos do que
concretizar tudo em um exemplo. Para isto, consideremos o BD que nos serviu de modelo para
os exemplos de álgebra relacional. Para maior comodidade, reproduziremos o modelo
mencionado abaixo:
Consideremos agora que desejamos nos utilizar deste BD e, com cálculo relacional, responder
às consultas abaixo:
• Quais os alunos de PD do 1º ano?

{t / Alu_1o_Ano (t) ∧ t.CodCur = PD}
• Quais os nomes dos alunos do 1º ano?

{t / (∃x) [Alu_1o_Ano (t), tuple (x.NomAlu) = t]}
• Qual o nome do curso do aluno 90147 do 3º ano?

{t / (∃x) [Alu_3o_Ano (t), x.RAAlu = 90147 ∧ (∃y) [Curso (y), x.CodCur = y.CodCur ∧
tuple (y.NomCur) = t]]}
• Quais os alunos do colégio?

{t / Alu_1o_Ano (t) ∨ Alu_2o_Ano (t) ∨ Alu_3o_Ano (t)}
ÈOJHEUD5HODFLRQDO
Para iniciarmos o estudo de álgebra relacional, faremos uma analogia desta com a álgebra
tradicional da matemática. Naturalmente, não é nossa intenção um estudo profundo nem
rigoroso da álgebra matemática, mas apenas tomar emprestado algumas idéias que poderão
nos ser úteis no estudo que faremos a seguir.
Poderíamos dizer que o universo da álgebra matemática é povoado por expressões algébricas
cujos componentes chamamos de operandos e operadores, sendo que os operandos pertencem
a algum conjunto de números, e o resultado das expressões também. Poderíamos pensar que
este universo é povoado por "contas".
De maneira análoga, o universo da álgebra relacional também é povoado por expressões de

álgebra relacional cujos componentes também chamamos de operandos e operadores.
Poderíamos, também aqui, pensar que este universo é povoado por "contas", só que desta vez,
DOUJF
o que temos são contas diferentes, uma vez que os operandos da álgebra relacional são tabelas
de um BD e o resultado das expressões também.
Agora que já conhecemos os conceitos que estão por trás desta linguagem de consulta,
passemos a averiguar quais são os operadores desta linguagem.
2V2SHUDGRUHVGDÈOJHEUD5HODFLRQDO
6HOHomR
O operador seleção tem como símbolo a letra grega sigma (σ).
Sua forma geral é: σ tab [cond].
Seu efeito é criar uma tabela com as tuplas da tabela WDE que satisfazem a condição FRQG e
devolvê-la como resultado.
3URMHomR
O operador projeção tem como símbolo a letra grega pi (π).
Sua forma geral é: π tab [atr_1,..., atr_n ].
Seu efeito é criar uma tabela com todas as tuplas da tabela WDE,porem somente com os
atributos especificados entre colchetes, e devolvê-la como resultado.
3URGXWR&DUWHVLDQR
O operador produto cartesiano tem como símbolo a letra ;.
Sua forma geral é: tab1 ; tab2.
Seu efeito é promover todas as combinações possíveis entre tuplas de WDE e WDE
concatenando-as em uma única tupla, e com estas tuplas resultantes desta concatenação,
criar uma tabela que é devolvida como resultado.
-XQomR
O operador junção tem como símbolo o caracter *.

DOUJF
Sua forma geral é: tab1 tab2 [cond].
Seu efeito é promover todas as combinações possíveis entre tuplas de WDE e WDE
concatenando-as em uma única tupla, e destas tuplas resultantes da concatenação, tomar
apenas aquelas que satisfizerem FRQG e criar uma tabela que é devolvida como resultado.
8QLmR
O operador união tem como símbolo o símbolo de união da matemática ( ∪ ). (UNION)
Sua forma geral é: tab1 ∪ tab2.
Este operador possui a restrição de somente poder operar em tabelas que possuem a
mesma estrutura.
Seu efeito é tomar deWDE e de WDE todas as suas tuplas, criando uma tabela com todas
elas juntas e devolvê-la como resultado.
,QWHUVHomR
O operador interseção tem como símbolo o símbolo de interseção da matemática ( ∩.
Sua forma geral é: tab1 ∩ tab2.
mesma estrutura.
Seu efeito é tomar de WDE aquelas tuplas que também estão em WDE, criar com elas uma
tabela e devolvê-la como resultado.
'LIHUHQoD
O operador diferença tem como símbolo o símbolo de diferença da matemática (-).
Sua forma geral é: tab1 - tab2.
mesma estrutura.
DOUJF
Seu efeito é tomar de WDE aquelas tuplas que não estão também em WDE, criar com elas
uma tabela e devolvê-la como resultado.
Conhecidos os operadores da álgebra relacional, nada melhor para fixar os conceitos do que
concretizar tudo em um exemplo. Para isto, consideremos o seguinte BD:
Consideremos agora, que desejamos nos utilizar deste BD e, com álgebra relacional, responder
às consultas abaixo:
Quais os alunos de PD do 1º ano?

σ Alu_1º_Ano [CodCur = PD]
Quais os nomes dos alunos do 1º ano?

π Alu_1º_Ano [NomAlu]
Qual o nome do curso do aluno 90147 do 3º ano?

π ((σ Alu_3º_Ano [RA = 90147]) * Curso [1.CodCur = 2.CodCur]) [NomCur]
Quais os alunos do colégio?

Alu_1º_Ano ∪ Alu_2º_Ano ∪ Alu_3º_Ano
64/6WUXFWXUHG4XHU\/DQJXDJH
SQL é uma linguagem unificada de dados para:
1. Definição de dados (criar tabelas, visões);
2. Acesso a dados (consultas);
3. Manipulação de dados (operações);
4. Controle de acesso a dados (definir em que parte do BD o usuário pode manipular).
SQL existe em duas modalidades:
1. Como linguagem autônoma, interativa, permitindo que através de um terminal ou

computador o usuário acesse diretamente os dados que procura;
DOUJF
2. Como sub linguagem de programação, interna à uma outra linguagem como COBOL,
Dbase, que se encarregue das estruturas básicas de programação, da formatação de
telas, impressão de relatórios, etc.
Toda estrutura SQL deriva da álgebra e do cálculo relacional. O usuário especifica o resultado
desejado e não o método de obter o resultado.
O formato dos comando SQL é livre, podendo usar uma ou mais linhas. O comando deve ser
terminado por um “;”.
3ULQFLSDLV&RPDQGRV
D &ULDomRGH'RPtQLRV
• Sintaxe:
CREATE DOMAIN <dominio> <tipo>;
• Tipos Válidos:
&+$57 Cadeia de caracteres (possivelmente constituída de letras,

dígitos e caracteres especiais) de tamanho fixo T.
9$5&+$57 Cadeia de caracteres (possivelmente constituída de letras,

RX dígitos e caracteres especiais) de tamanho variável
&KDUDFWHU9DU\LQJ7
limitado a no máximo T caracteres.
,17 Número inteiro com faixa de valores válidos dependente

RX do equipamento.
,QWHJHU
60$//,17 Número inteiro com faixa de valores válidos dependente

do equipamento.
180(5,&7' Número real de ponto fixo com tamanho T (que inclui
eventual sinal e o ponto decimal) e D dígitos à direita do
ponto decimal.
DOUJF
5($/ Número real de ponto flutuante com faixa de valores

válidos dependente do equipamento.
'RXEOH3UHFLVLRQ Número real de ponto flutuante com faixa de valores

válidos dependente do equipamento.
)/2$7' Número real de ponto flutuante com precisão de no

mínimo D dígitos.
'$7( Data representada por ano (com 4 dígitos), mês e dia do

mês.
7,0( Horário representado por horas, minutos e segundos.
• Exemplo:
CREATE DOMAIN NomeAluno CHAR (30);
E (OLPLQDomRGH'RPtQLRV
• Sintaxe:
DROP DOMAIN <dominio>;
• Exemplo:
DROP DOMAIN NomeAluno;
F &ULDomRGH7DEHODV
• Sintaxe:
CREATE TABLE <tabela>

( <coluna> <tipo> [NOT NULL]
[,...]
[,<coluna> <tipo> [NOT NULL]]
[PRIMARY KEY (<coluna>
[,<coluna>]
[,...]
[,<coluna>])]
[FOREIGN KEY (<coluna>
[,<coluna>]
DOUJF
[,...]
[,<coluna>]) REFERENCES <tabela>
[ON DELETE CASCADE] [ON UPDATE CASCADE]]
[...]
[FOREIGN KEY (<coluna>
[,<coluna>]
[,...]
[,<coluna>]) REFERENCES <tabela>
[ON DELETE CASCADE] [ON UPDATE CASCADE]]
[CHECK <condicao>]);
• Exemplo:
CREATE TABLE alunos3oPD (RA SMALLINT,

Nome CHAR (30));
• A cláusula NOT NULL proíbe que a coluna receba valor nulo;
• A cláusula PRIMARY KEY especifica a chave primária da tabela;
• A cláusula CHECK especifica uma condição que constitui uma restrição de

integridade que precisa ser verificada para toda linha da tabela criada.
G $FUpVFLPRGH&ROXQDVDXPD7DEHOD
• Sintaxe:
ALTER TABLE <tabela> ADD

( <coluna> <tipo>
[,...]
[,<coluna> <tipo>]);
• Exemplo:
ALTER TABLE alunos3oPD

ADD (Apelido CHAR (15));
H (OLPLQDomRGH&ROXQDVDXPD7DEHOD
• Sintaxe:
DOUJF
ALTER TABLE <nome da tabela> DROP

( <coluna>
[,...]
[,<coluna>);
• Exemplo:
ALTER TABLE alunos3oPD

DROP (Apelido);
I (OLPLQDomRGH7DEHODV
• Sintaxe:
DROP TABLE <tabela>;
• Exemplo:
DROP TABLE professores;
J &ULDomRGHËQGLFHV
• Sintaxe:
CREATE [UNIQUE] INDEX <indice>

ON <tabela> (<coluna> [ASC/DESC]
[,<coluna> [ASC|DESC]]
[,...]
[,<coluna> [ASC/DESC]]);
[UNIQUE] é um parâmetro opcional que teta a duplicidade de dados na chave de

indexação.
[ASC|DESC] indica que o índice será baseado na coluna podendo se ascendente ou

descendente.
As demais colunas especificadas na sintaxe servem para desempatar a primeira coluna

índice.
• Exemplo:
DOUJF
CREATE INDEX indice_materia

ON materias
(cod_mat ASC);
• Restrições:
ä Índice só pode estar associado a tabelas e nunca à visões;
ä Não é possível misturar chaves ascendentes e descendentes no mesmo índice.
K (OLPLQDomRGHËQGLFHV
• Sintaxe:
DROP INDEX <indice>;
• Exemplo:
DROP INDEX indice_materia;
L ,QFOXVmRGH'DGRV
• Sintaxe:
INSERT INTO <tabela> [(<coluna>

[,<coluna>]
[,...]
[,<coluna>]]
VALUES(<valor>
[,<valor>]
[,...]
[,<valor>]);
• Exemplo:
INSERT INTO alunos3oPD

VALUES (90057, “André”, “Boca”);
M ([FOXVmRGH'DGRV
• Sintaxe:
DELETE FROM <tabela>

DOUJF
[WHERE <condicao>];
[WHERE <condicao>] é uma cláusula que determina as linhas que serão

eliminadas.
• Exemplo:
DELETE FROM matéria

WHERE nome = “FPD”;
N $WXDOL]DomRGH'DGRV
• Sintaxe:
UPDATE <tabela>
SET <coluna> = <valor>
[, <coluna> = <valor>]
[,...]
[WHERE <condicao>];
• Exemplo:
UPDATE notas
SET nota = nota + 3.0
WHERE cod_mat = “01”;
Adiciona 3 pontos na nota de cada aluno da matéria 01, na tabela NOTAS.
O &ULDomRGH$VVHUo}HV
• Sintaxe Geral:
CREATE ASSERTION <assercao> <condicao>;
P(OLPLQDomRGH$VVHUo}HV
• Sintaxe Geral:
DROP ASSERTION <assercao>;
DOUJF
Q &RQVXOWDV
O comando SELECT é uma query, isto é, faz pesquisas em tabelas.
• Sintaxe Geral:
SELECT [ALL/DISTINCR] <coluna> [as <apelido>]

[,<coluna> [as <apelido>]]
[,...]
FROM <tabela> [as <apelido>]
[,<tabela> [as <apelido>]]
[,...]
[WHERE <condicao>]
[GROUP BY <coluna>
[,<coluna>]
[,...]
[,<coluna>]]
[HAVING <condicao>]
[ORDER BY <coluna> [ASC|DESC]
[,...]
[,<coluna> [ASC|DESC]]];
• Seleção Simples:
ä Exemplo:
SELECT *
FROM notas
WHERE cod_mat = “01”;
Resultado:
5$ &2'B0$7 127$
90218 01 9.5
90230 01 5.0
90003 01 0.5
90199 01 8.0
90109 01 8.0
• Projeção Simples:
ä Exemplo:
DOUJF
SELECT nome
FROM professores;
Resultado:
1RPH
André
Chico
Lucius
Celso
Rogério
Vagner
Renato
• Seleção com Resultados Ordenados:
ä Exemplo:
SELECT *
FROM notas
ORDER BY cod_mat, nota;
Resultado:
5$ &2'B0$7 127$
90003 01 0.5
90230 01 5.0
90199 01 8.0
90109 01 8.0
90218 01 9.5
. . .
. . .
. . .
90090 08 0.0
90113 08 1.0
90033 08 10.0
• Operadores Aritméticos:
+ (sinal) : número positivo

- (sinal) : número negativo
** ou ^ : exponenciação
* : multiplicação
/ : divisão
+ : soma
- : subtração
DOUJF
• Operadores Lógicos:
SÍMBOLO DESCRIÇÃO
= igual a
!= diferente de
> maior que
>= maior ou igual a
< menor que
<= menor ou igual a
AND e
OR ou
NOT não
• Between...And:
Testa o conteúdo de uma coluna e extrai apenas os dados

que se encontram dentro da faixa especificada.
ä Exemplo:
SELECT ra, nota

FROM notas
WHERE nota BETWEEN 5.0 AND 10.0
Resultado:
5$ 127$
90218 9.5
90230 5.0
90033 10.0
90199 8.0
90109 8.0
• In (Lista):
Opera sobre uma lista de valores e testa se o valor da coluna especificada pertence a
esta lista.
ä Exemplo:
SELECT *
FROM professores
DOUJF
WHERE cod_prof IN (“01”,”04”);
Resultado:
&2'B352) 120(
01 André
04 Celso
• Like:
Quando não se sabe o valo exato que está sendo procurado, usa-se o operador LIKE
que reconhece dois caracteres especiais: (1) corresponde a uma seqüência qualquer
de 0 ou mais caracteres; e (2) B corresponde a qualquer caracter.
ä Exemplo:
SELECT alunos3oPD
WHERE nome LIKE “R%”;
Resultado:
5$ 120( $3(/,'2
90223 Rachel de Carvalho Pascolino
90228 Raquel Moricone Pacheco Pézinho
90229 Raquel Pinhantelli da Silva Vamp
90230 Regiane Feltrin de Melo
90238 Ricardo Cesar Sebastião Tião
90242 Ricardo Santos Lisboa Pipoca
90249 Rodrigo Spadaccia Zolhu’s
• Is [Not] Null:
Verifica se a coluna especificada possui ou não um valor nulo.
ä Exemplo:
SELECT ra, cod_mat

FROM notas
WHERE notas IS NULL;
Resultado:
DOUJF
5$ &2'B0$7
90090 09
90090 08
90090 03
• Group By:
Agrupamento de linhas permite que as linhas da tabela de resultado sejam agrupadas,

de acordo com critérios especificados pelo usuário.
ä Funções de Grupo:
As funções de grupo retornam um valor para um grupo de linhas.
AVG([DISTINCT] N): calcula a média dos valores de uma coluna. Ignora

nulos.
COUNT([DISTINCT] {*|<expressão>}): conta o número de vezes que a

expressão retorna qualquer coisa diferente de nulo.
MAX(<espressao>): determina o valor máximo de uma coluna alfanumérica ou

numérica.
MIN(<expressao>]: determinado valor mínimo de uma coluna alfanumérica

ou numérica.
STDDEV ([DISTINCT] <expressão>): totaliza os valores de uma coluna.

Só pode ser usado com colunas numéricas.
VARIANCE ([DISTINCT] <expressão>): determina a variância da

expressão. Ignora nulos.
ä Primeiro Exemplo:
SELECT cod_mat, AVG (nota) as Media

FROM notas
GROUP BY cod_mat
HAVING Media >= 5.0;
DOUJF
Resultado:
&2'B0$7 0HGLD
01 6.2
08 5.5
ä Segundo Exemplo:
SELECT COUNT (*) as Qtos

FROM matérias;
Resultado:
4WRV
9
ä Observações:
A diferença entre as cláusulas HAVING e WHERE é que, a cláusula WHERE define

as linhas de resultado como um todo, já a cláusula HAVING opera sobre um grupo
de linhas.
• Sub Queries:
Uma subquery é um comando SELECT que está aninhado dentro de um comando

SELECT, INSERT, UPDATE, ou DELETE.
Subqueries constituem operandos dos operandos de comparação.
Como um comando SELECT pode retornar uma lista de valores, é necessário que o
operador seja adequado ao resultado produzido pelo comando. A alternativa é que, no
caso de listas, o outro operando também seja uma lista.
ä Exemplo:
SELECT ra, nota

FROM notas
WHERE cod_mat = (SELECT cod_mat
FROM matérias
DOUJF
WHERE nome = “LPC”);
Resultado:
5$ 127$
90218 9.5
90230 5.0
90003 0.5
90199 8.0
90109 8.0
ä Observações:
A cláusulas DISTINCT, ORDER BY, UNION, INTERSECT e EXCEPT só

podem ser utilizadas uma única vez na instrução SELECT inteira.
Subqueries não podem ter as cláusulas ORDER BY, GROUP BY e HAVING.
• Distinct:
Como default de SELECT é ALL, sempre que a instrução SELECT é executada ela
selecionará todas as linhas que atenderem a condição especificada, mesmo que haja
duplicidade na tabela de resultado.
Com a cláusula DISTINCT as linhas repetidas desaparecem da tabela de resultados

(embora continuem existindo dentro da tabela de dados).
ä Exemplo:
SELECT DISTINCT ra, nota

FROM notas
WHERE nota <= ALL (SELECT nota
FROM notas);
Resultado:
5$ 127$
90090 0.0
DOUJF
• Os Predicados Any e All:
Os predicados ANY e ALL estão sempre associados a uma subquery.
ANY determina se a condição estabelecida pela cláusula WHERE é verdadeira para

pelo menos uma das linhas da tabela de resultado da subquery.
ä Exemplo:
SELECT ra, cod_mat, nota

FROM notas
WHERE not nota < ANY (SELECT nota
FROM notas);
Resultado:
5$ &2'B0$7 127$
90113 08 1.0
90218 01 9.5
90287 03 3.5
90090 09 0.0
90089 05 0.5
90230 01 5.0
90118 06 1.0
90259 07 4.0
90214 04 1.5
90090 08 0.0
90090 03 0.0
90242 02 2.5
90238 04 2.5
90003 01 0.5
90074 07 3.0
90198 05 4.0
90199 01 8.0
90109 01 8.0
ALL determina se a condição estabelecida pela cláusula WHERE é verdadeira para

todas as linhas da tabela resultado da subquery.
ä Exemplo:
SELECT ra, nota, cod_mat

FROM notas
WHERE nota <= ALL (SELECT nota
FROM notas);
DOUJF
Resultado:
5$ 127$ &2'B0$7
90090 0.0 09
90090 0.0 08
90090 0.0 03
• O Predicado EXISTS:
O predicado EXISTS está sempre associado a uma subquery e determina se a subquery

seleciona ou não alguma linha.
Em outras palavras, o predicado EXISTS permite que um SELECT selecione as linhas

que fazem com que a subquery selecione ou não alguma linha.
O predicado EXISTS é o único que permite o uso do asterisco (*) na subquery. Outra
observação é que a subquery envolver informações da query principal.
ä Exemplo:
SELECT ra
FROM alunos3oPD as A
WHERE EXISTS (SELECT *
FROM Notas as N
Where N.RA = A.RA and Nota = 0);
Resultado:
5$
90090
90090
90090
• O Predicado UNIQUE:
O predicado UNIQUE está sempre associado a uma subquery e determina se a

subquery seleciona ou não linhas replicadas.
Em outras palavras, o predicado UNIQUE permite que um SELECT selecione as

linhas que fazem com que a subquery selecione linhas linhas replicadas.
DOUJF
ä Exemplo:
SELECT ra
FROM alunos3oPD as A
WHERE UNIQUE (SELECT *
FROM Notas as N
Where N.RA = A.RA and Nota = 0);
Resultado:
5$
• Queries Correlacionadas:
A subquery é executada para cada linha selecionada no SELECT principal, diferente

dos subqueries simples que são executados somente uma vez. Para isso ocorrer, o
subquery deve fazer referência a uma coluna referente a uma tabela selecionada do
query principal.
ä Exemplo:
SELECT ra, nota, cod_mat

FROM notas n1
WHERE nota1 > (SELECT AVG (nota)
FROM notas
WHERE n1.ra!= ra AND
Cod_mat = n1.cod_mat
ORDER BY cod_mat);
Mostra os alunos cuja nota é maior que a média das notas de todos os outros
alunos. É listado em ordem do código da matéria.
Resultado:
5$ 127$ &2'B0$7
90218 9.5 01
90199 8.0 01
90109 8.0 01
90242 2.5 02
90287 3.5 03
90238 2.5 04
DOUJF
90198 4.0 05
90118 1.0 06
90259 4.0 07
90033 10.0 08
90090 0.0 09
R -XQomRGH7DEHODV
As junções de tabelas possibilitam a criação de tabelas de resultado contendo
informações extraídas de duas tabelas de dados. Os atributos da tabela resultado de
uma junção de duas tabelas serão os atributos da primeira tabela, seguidos pelos
atributos da segunda tabela. As linhas da tabela resultado de uma junção serão obtidas
pela concatenação de linhas da primeira tabela com linhas da segunda tabela.
Existem vários tipos de junção, a saber: produto cartesiano, junção interna, junção
externa esquerda, junção externa direita e junção externa completa.
O PRODUTO CARTESIANO consiste em combinar CADA UMA das linhas da

primeira tabela com TODAS as linhas da segunda tabela. Este tipo de junção não exige
a existência de um ou mais atributos comuns às duas tabelas.
A JUNÇÃO INTERNA pressupõe a existência de um ou mais atributos comuns às

duas tabelas. SOMENTE as linhas cujos valores desses atributos comuns forem
coincidentes serão combinadas na junção interna; as linhas da primeira tabela cujos
valores desses atributos comuns não coincidirem com os valores destes mesmos
atributos de nenhuma linha da segunda tabela NÃO serão combinadas na junção
interna; as linhas da segunda tabela cujos valores desses atributos comuns não
coincidirem com os valores destes mesmos atributos de nenhuma linha da primeira
tabela NÃO serão combinadas na junção interna.
A JUNÇÃO EXTERNA ESQUERDA também pressupõe a existência de um ou mais

atributos comuns às duas tabelas. As linhas cujos valores desses atributos comuns
forem coincidentes SERÃO combinadas neste tipo de junção. As linhas da primeira
tabela cujos valores desses atributos comuns não coincidirem com os valores destes
mesmos atributos de nenhuma linha da segunda tabela TAMBÉM serão combinadas
neste tipo de junção (os valores dos atributos provindos da segunda tabela ficarão
DOUJF
nulos). As linhas da segunda tabela cujos valores desses atributos comuns não
tabela NÃO serão combinadas neste tipo de junção.
A JUNÇÃO EXTERNA DIREITA também pressupõe a existência de um ou mais

mesmos atributos de nenhuma linha da segunda tabela NÃO serão combinadas neste
tipo de junção. As linhas da segunda tabela cujos valores desses atributos comuns não
tabela TAMBÉM serão combinadas neste tipo de junção (os valores dos atributos
provindos da primeira tabela ficarão nulos).
A JUNÇÃO EXTERNA COMPLETA também pressupõe a existência de um ou mais

mesmos atributos de nenhuma linha da segunda tabela TAMBÉM serão combinadas
neste tipo de junção (os valores dos atributos provindos da segunda tabela ficarão
nulos). As linhas da segunda tabela cujos valores desses atributos comuns não
tabela TAMBÉM serão combinadas neste tipo de junção (os valores dos atributos
provindos da primeira tabela ficarão nulos).
Os atributos comuns que serão levados em conta para combinar linhas da primeira
tabela com linhas da segunda tabela podem ser indicados explicitamente ou não.
No caso de uma junção NATURAL eles não são indicados explicitamente; TODOS os
atributos comuns serão levados em conta e eles aparecerão UMA ÚNICA VEZ na
tabela resultante da junção.
DOUJF
No caso de junções não naturais, o critério de junção precisará ser explicitado com ON
ou com USING. No primeiro caso (ON), os atributos comuns às duas tabelas
aparecerão DUPLICADOS na tabela resultante da junção. No segundo caso (USING),
os atributos comuns às duas tabelas aparecerão UMA ÚNICA VEZ na tabela resultante
da junção.
ä Sintaxe:
<tabela>
[NATURAL]
{INNER | LEFT OUTER | RIGHT OUTER | FULL OUTER}
JOIN
<tabela>
[ON <condicao>]
[USING (<coluna>
[, <coluna>]
[,...]
[, <coluna>]]
[AS <tabela> (<coluna>
[, <coluna>]
[,...]
[, <coluna>])];
ä Exemplo de Inner Join:
SELECT ra, nota, nome

FROM (notas NATURAL INNER JOIN materias)
WHERE nota >= 8.0;
Resultado:
5$ 127$ 120(B'$7
90218 9.5 LPC
90033 10.0 LMON
90199 8.0 LPC
90109 8.0 LPC
ä Exemplo de Left Outer Join:
SELECT nome_prof, nome_mat

FROM (professores LEFT OUTER JOIN materias
DOUJF
USING (cod_prof)
AS temp (cod_prof, nome_prof, cod_mat, nome_mat))
ORDER BY nome_prof;
Mostra os professores e as matérias que lecionam, mesmo que alguém não lecione
matéria alguma.
Resultado:
SQRPH PQRPH
André LPC
André APSI
André IA
Celso CAI
Chico CG
Lucius ISSO
Lucius REDES
Lucius LMON
Renato
Rogério FPD
Vagner
ä Observações:
AUTO JUNÇÕES (Self Joins) são o tipo de junção em que uma tabela é juntada
consigo própria.
S 8QLmRGH7DEHODV
A união de tabelas permite agrupar, em uma única tabela de resultado, as linhas de
duas outras tabelas. É imprescindível que as tabelas envolvidas tenham a mesma
estrutura, i.e., a mesma quantidade de colunas, com os mesmos nomes e tipos. Este
tipo de operação só poderá ser realizada se as tabelas envolvidas residirem no mesmo
BD.
ä Sintaxe:
<tabela>
UNION
<tabela>;
DOUJF
ä Exemplo:
SELECT ra, apelido

FROM alunos3oPD
UNION
SELECT ra, apelido
FROM alunos2oTA;
Mostra uma tabela com os alunos do 3o PD e do 2o TA.
Resultado:
5$ $3(/,'2
89131
89147 Maçãzinha
89276
90002 Béri
90003 Kety
90030 Gaf’s
90033
90036 Boca
90062 Cleq
90074 Chuchu
90089 Queixada
90090 Philco
90095 Nelinho
90109 Tocha
90113 Marciano
90118 Aparecida
90123 Labareda
90152
90185 Herman
90198 Magé
90199
90214 Muambeira
90218
90223
90228 Bastiana
90229 Vamp
90230
90238 Tião
90242 Pipoca
90249 Zolhu’s
90259 Chibata
90268
90269
90287 Vaca Loka
90501 Ploff
90144 Cogumelo
DOUJF
90166 Nariguda
90262 Nadadeira
T ,QWHUVHomRGH7DEHODV
A interseção de tabelas permite obter uma tabela de resultado com as linhas comuns a
duas outras tabelas. É imprescindível que as tabelas envolvidas tenham a mesma
estrutura, i.e., a mesma quantidade de colunas, com os mesmos nomes e tipos. Este
tipo de operação só poderá ser realizada se as tabelas envolvidas residirem no mesmo
BD.
ä Sintaxe:
<tabela>
INTERSECT
<tabela>;
ä Exemplo:
SELECT ra, apelido

FROM alunos3oPD
INTERSECT
SELECT ra, apelido
FROM alunos 2oTA;
Mostra uma tabela com os alunos que são simultaneamente do 3o PD e do 2o TA.
Resultado:
5$ $3(/,'2
U 'LIHUHQoDGH7DEHODV
A diferença de tabelas permite obter uma tabela de resultado com todas as linhas da
primeira tabela, exceto aquelas que também se encontram na segunda tabela. É
imprescindível que as tabelas envolvidas tenham a mesma estrutura, i.e., a mesma
quantidade de colunas, com os mesmos nomes e tipos. Este tipo de operação só poderá
ser realizada se as tabelas envolvidas residirem no mesmo BD.
DOUJF
ä Sintaxe:
<tabela>
EXCEPT
<tabela>;
ä Exemplo:
SELECT ra, apelido

FROM alunos3oPD
EXCEPT
SELECT ra, apelido
FROM alunos 2oTA;
Mostra uma tabela com os alunos do 3o PD que não são do 2o TA.
Resultado:
5$ $3(/,'2
89131
89147 Maçãzinha
89276
90002 Béri
90003 Kety
90030 Gaf’s
90033
90036 Boca
90062 Cleq
90074 Chuchu
90089 Queixada
90090 Philco
90095 Nelinho
90109 Tocha
90113 Marciano
90118 Aparecida
90123 Labareda
90152
90185 Herman
90198 Magé
90199
90214 Muambeira
90218 P. P.
90223
90228 Bastiana
90229 Vamp
90230
90238 Tião
90242 Pipoca
90249 Zolhu’s
DOUJF
90159 Chibata
90268
90269
90287 Vaca Loka
90501 Ploff
V &ULDomRGH9LV}HV
Visão é uma tabela virtual, ou seja, uma tabela que não existe fisicamente em disco,
mas que funciona praticamente como se existisse.
Cada visão pode basear se em diversas outras tabelas e visões, assim como conter
colunas resultantes de expressões.
A visão será atualizada toda vez que as tabelas ou visões em que se baseiam forem
atualizadas.
• Sintaxe:
CREATE VIEW <visao>

[( <coluna>
[,...]
[, <coluna>])]
AS <query>
[WITH CHECK OPTION];
[WITH CHECK OPTION] é uma cláusula opcional que, quando usada impede a
inclusão de linhas que não atendem aos critérios da instrução de definição da visão.
• Exemplo:
CREATE VIEW melhor_aluno AS

(SELECT ra, nota, cod_mat
FROM nota AS n1
WHERE nota1 > (SELECT AVG (nota)
FROM notas
WHERE n1.ra!= ra AND
cod_mat = n1.cod_mat));
Resultado:
DOUJF
PHOKRUBDOXQR
5$ 127$ &2'B0$7
90218 9.5 01
90287 3.5 03
90090 0.0 09
90118 1.0 06
90259 4.0 07
90033 10.0 08
90242 2.5 02
90238 2.5 04
90198 4.0 05
90199 8.0 01
90109 8.0 01
ä Observações:
O query da cláusula AS seleciona colunas, linhas e tabelas que comporão a

visão.
Qualquer query válido pode ser usado na cláusula AS, desde que não contenha
uma cláusula ORDER BY.
O query pode acessar outras visões.
A lista de colunas é opcional, mas se existir deve conter o mesmo número de

colunas da cláusula SELECT do query.
Pode-se consultar uma visão do mesmo modo que uma tabela.
Pode-se atualizar informações diretamente em umas visões, bem como através

das tabelas que as definem.
Para que uma visão seja atualizável a query que a definiu deve obedecer certas
restrições: (1) deve-se referir a uma única tabela; (2) não pode conter cláusulas
GROUP BY e DISTINCT e nem funções de grupo.
W (OLPLQDomRGH9LV}HV
• Sintaxe:
DOUJF
DROP VIEW <nome da visão>;
• Exemplo:
DROP VIEW melhor_aluno;
X 'HILQLomRGH6LQ{QLPRV
Os sinônimos são como abreviaturas do nome das tabelas ou visões, existindo apenas
de forma lógica com a única finalidade de diminuir o tempo de digitação.
• Sintaxe:
CREATE SYNONYM <sinônimo>

FOR <nome da tabela/visão>;
• Exemplos:
CREATE SYNONYM 3pd

FOR alunos3oPD;
Y (OLPLQDomRGH6LQ{QLPRV
Quando uma tabela é eliminada eventuais sinônimos que ela tenha são também
eliminados automaticamente.
• Sintaxe:
DROP SYNONYM <sinônimo>;
• Exemplo:
DROP SYNONYM 3pd;
Z &RQFHVVmRGH3ULYLOpJLRV
Os Sistemas Gerenciadores de Banco de Dados, por definição, armazenam grandes
volumes de informações.
DOUJF
Podemos dizer, sem risco de erros, que uma das medidas mais fiéis da qualidade de um
Sistema de Gerenciamento de Banco de Dados é a proteção que ele oferece contra o acesso
e o uso dessas informações não se perderão ou serão indevidamente modificadas em
conseqüência do uso do sistema.
Privilégio é o nome que se dá, em SQL, à autorização fornecida a um usuário para que
realize determinadas operações, tais como:
• Alterar tabelas (ALTER);
• Atualizar dados (UPDATE);
• Criar índice (CREATE INDEX);
• Eliminar dados (DELETE);
• Incluir dados (INSERT);
• Selecionar dados (SELECT).
Todos os privilégios são concedidos com o comando GRANT.
• Sintaxe:
GRANT {ALL [PRIVILEGES]| <privilegio>

[, <privilegio>]
[,...]
[, <privilegio>]}
ON [TABLE] {<tabelas> | <visao>}
[,{<tabelas> | <visao>}]
[,...]
TO {PUBLIC | <usuario>
[, <usuario>]
[,...]
[, <usuario>]}
[WITH GRANT OPTION];
ALL implica a concessão de todos os privilégios disponíveis.
DOUJF
[PRIVILEGES] é um indicador opcional desnecessário, servindo apenas para tornar o

comando mais claro.
Os <privilégio> representam a relação dos privilégios que estão sendo concedidos.
[TABLE] é um termo opcional de uso equivalente ao [PRIVILEGES].
Os {<tabela> | <visao>} indicam as tabelas ou visões às quais os privilégios se

referem.
TO PUBLIC representa a concessão dos privilégios indicados a todos os usuários.
Os <usuario> indicam os usuários a quem os privilégios estão sendo concedidos.
[WITH GRANT OPTION] dá aos usuários a capacidade de conceder a outros usuários

os mesmos privilégios que a eles foram concedidos nesta instrução.
• Primeiro Exemplo:
GRANT DELETE, INSERT, SELECT

ON TABLE alunos3oPD, alunos2oTA
TO CLEUZA, WAINER;
Dá aos usuários Cleuza e Wainer os privilégios de apagar, inserir e listar linhas das
tabelas alunos3oPD e alunos2oTA.
• Segundo Exemplo:
GRANT UPDATE (cod_prof)

ON professores
TO PUBLIC;
Todos os usuários passam a poder atualizar os valores da coluna cod_prof da tabela

professores.
• Terceiro Exemplo:
GRANT ALL
ON TABLE notas
TO Sílvia
WITH GRANT OPTION;
DOUJF
O usuário Sílvia recebe todos os privilégios sobre a tabela notas podendo conceder esse
privilégios a outros usuários.
[ 5HYRJDomRGH3ULYLOpJLRV
Da mesma forma que são concedidos,os privilégios podem ser revogados.
• Sintaxe:
REVOKE {ALL [PRIVILEGES]| <privilegio>

[, <privilegio>]
[,...]
[, <privilegio>]}
ON [TABLE] {<tabelas> | <visao>}
[,...]
FROM {PUBLIC | <usuario>
[, <usuario>]
[,...]
[, <usuario>]};
As cláusulas REVOKE têm significado análogo às cláusulas GRANT, sendo que a

primeira revoga privilégios, enquanto a última concede.
• Exemplo:
REVOKE UPDATE
ON notas
FROM Sílvia;
Retira o privilégio de alterar a tabela notas do usuário Sílvia.
É interessante ressaltar que, se o privilégio concedido a um usuário com a cláusula WITH

GRANT OPTION for revogado, todos os usuários a quem ele tiver repassado o privilégio
perderão esse direito.
\ 3URFHVVDPHQWRGH7UDQVDo}HV
Transação é uma série de operações consideradas em conjunto. Assim, um transação só
será concluída se todas as operações que a compõem forem completadas com sucesso.
DOUJF
Com o uso de transações, torna-se possível garantir a integridade das informações do

Banco de Dados, uma vez que nenhum processo será executado parcialmente.
Caso algum problema ocasione a interrupção da transação, todas as tabelas serão

revertidas à situação que se encontravam no início da transação.
• Sintaxe:
BEGIN TRANSACTION
<comando SQL>
...
<comando SQL>
END TRANSACTION
• Exemplo:
BEGIN TRANSACTION
UPDATE notas
SET nota = 0
WHERE NOTA >= 5.0;
END TRANSACTION
As transações podem ser usadas tanto interativamente quanto dentro de programas.

Como é fácil perceber, as transações retardam a execução dos programas e por isso
devem ser usadas com critério.
As inclusões, alterações e exclusões só podem ser revertidas dentro de transações. Fora

de transações elas são registradas fisicamente. As instruções de criação e eliminação de
elementos do Banco de Dados não podem ser utilizadas dentro de transações.
&DWiORJRV
É um grupo de tabelas e visões que contém informações sobre o Banco de Dados. Elas são
criadas quando o Banco de Dados é criado.
O catálogo de dados descreve tabelas, colunas, índices, usuários, privilégios de acesso e outros
objetos.
Pode-se ler tabelas do catálogo com os comandos SELECT padrões.
DOUJF
0RGR3URJUDPDGR
Dentre as vantagens de utilizar SQL em modo programado, podemos citar: (1) SQL torna os
programas muito mais legíveis e portanto bem mais fáceis de depurar e manter; (2) SQL
produz um código significativamente mais compacto que qualquer linguagem procedural; e
(3) Toda boa implementação de SQL tem performance superior à das linguagens procedurais
na execução das tarefas de processamento às quais SQL se destina (definição, manipulação e
controle de dados).
Ao usar SQL junto com uma outra linguagem, devemos utilizar desta outra linguagem o que
ela tem de melhor e que não existe em SQL, ou seja, construções de programação estruturada
como comandos condicionais, comandos iterativos, funções de manipulação de strings e datas,
comandos de vídeo, comandos de rede, comandos de configuração de ambiente, comandos de
formatação de relatório, etc.
Há uma diferença importante entre as duas linguagens, com reflexo direto na construção de
programas. SQL se baseia em conjuntos para acessar os dados, e faz esse acesso de modo não
procedimental, ou seja, determina os dados necessários e deixa a cargo dos recursos internos
da linguagem a localização desses dados.
Linguagens convencionais, por sua vez, obrigam o programador a dizer quais as áreas de
trabalho utilizadas, quais os arquivos abertos e quais os registros desejados, por meio de
instruções procedimental que a cada passo determina o que deve ser feito.
Além disso, linguagens convencionais não manipulam sobre conjunto de dados, uma vez que
trabalha registro a registro (o que é caracterizado pelo uso de um ponteiro de arquivo para
indicar sempre o registro afetado pela operação em curso).
Na prática, isso significa que existe um ponto de incompatibilidade entre as duas linguagens, e
no entanto, não tem maiores conseqüências. Basta que o programador não misture no mesmo
programa comandos de criação e acesso aos arquivos de ambas as linguagens, e não inclua em
programas que contenham instruções SQL e comandos e funções de linguagens convencionais
(voltadas para o posicionamento de ponteiros do arquivo), uma vez que o conceito de
ponteiros não tem aplicação dentro de SQL.
DOUJF
Quase tudo que é realizado interativamente no SQL pode ser incluído dentro de programas.
No entanto, em modo programado, dispõe-se também de alguns comandos novos.
Os comandos de SQL são, em geral, usados nas linguagens hospedeiras entre os delimitadores
EXEC SQL e END EXEC. Uma exceção desta regra é o ambiente de programação do
DBaseIV.
&RPDQGRV6LPSOHVGH0RGR3URJUDPDGR
D 6(/(&7FRPFULDomRGHWDEHOD
• Sintaxe:
SELECT [ALL/DISTINCR] <coluna> [as <apelido>]

[,...]
,172WDEHOD!
FROM <tabela> [as <apelido>]
[,...]
[WHERE <condicao>]
[GROUP BY <coluna>
[,<coluna>]
[,...]
[,<coluna>]]
[HAVING <condicao>]
[,...]
• Exemplo:
SELECT ra, nome, apelido

INTO aprovados3oPD
FROM alunos3oPD
WHERE nota > 5.0;
DOUJF
E ,QVHUomRGHJUDQGHVYROXPHVGHGDGRV
Este comendo impõe a restrição de que a tabela de resultado deve ter a mesma estrutura da
tabela destino. Para realizar a inserção de dados de uma tabela para outra, a inclusão dos
dados poderia ser programada como se segue.
• Sintaxe:
INSERT INTO <tabela> <query>;
&RPDQGRVGH0RGR3URJUDPDGRUHODFLRQDGRVFRP&XUVRUHV
D 'HFODUDomRGH&XUVRUHV
Cursores são um recurso que permite processar tabelas de resultado com várias linhas.
• Sintaxe:
DECLARE <cursor> CURSOR

FOR <query>
[FOR UPDATE OF <coluna>
[, <coluna>]
[,...]
[, <coluna>]]
[,...]
[FOR UPDATE OF] é uma cláusula opcional que permite a atualização da tabela
vinculada ao cursor.
• Exemplo:
DECLARE posição CURSOR

FOR SELECT DISTINCT p.nome, m.nome
FROM professores AS p, matéria AS m
WHERE p.cod_prof = m.cod_prof
ORDER BY p.nome;
Declara o cursor posição contendo as linhas dos professores e as matérias que ele
leciona.
DOUJF
• Restrições:
a) As cláusulas FOR UPDATE OF e ORDER BY são mutuamente exclusivas;
b) a tabela de resultado não poderá ser atualizada se a cláusula SELECT: (1) contiver
funções agregadas; (2) contiver as cláusulas UNION, DISTINCT, GROUP BY, ou
HAVING; (3) contiver, na lista de colunas, colunas de mais de uma tabela ou visão;
(4) contiver, na lista de colunas, uma ou mais colunas de uma visão que não possa
ser atualizada.
E $EHUWXUDGH&XUVRUHV
• Sintaxe:
OPEN <cursor>;
• Exemplo:
OPEN posição;
F 2EWHQomRGH'DGRVGH&XUVRUHV
A manipulação de um cursor depende de outros elementos SQL:
• Existe a variável SQLCNT que registra automaticamente o número de linhas

produzidas por qualquer comando SQL e, no caso, registra o número de linhas do
cursor logo que é aberto;
• Ainda assim faltaria um recurso que permitisse acessar uma linha do cursor de cada
vez e armazenar o seu conteúdo numa variável de memória;
ä Sintaxe:
FETCH <cursor>
INTO:<var>
[,:<var>]
[,...]
[,:<var>];
DOUJF
Todas as <var> são variáveis de memória na qual os valores de cada linha do cursor
serão transferidos.
• Antes do comando FETCH o ponteiro do cursor (um indicador da linha que será
processada) está posicionado antes da primeira linha da tabela de resultado.
Quando o FETCH é executado pela primeira vez dentro de um laço iterativo, o ponteiro
vai para a primeira linha da tabela e prossegue linha a linha a cada execução do
FETCH.
Nesse laço iterativo deve-se testar se o comando FETCH está devolvendo linha, ou
seja, se SQLCNT é diferente de 0. Caso contrário, já foram utilizadas todas as linhas da
tabela.
G $WXDOL]DomRGH'DGRVGH&XUVRUHV
Os cursores também podem ser usados para atualização de tabelas desde que respeitadas as
restrições mencionadas anteriormente (por exemplo, eles só poderão ser construídos a
partir de uma única tabela). Para isso será preciso recorrer à cláusula FOR UPDATE OF.
• Sintaxe:
UPDATE <tabela>
SET <coluna> = <valor>
[,...]
WHERE CURRENT OF <cursor>;
• Exemplo:
DECLARE posicao CURSOR

FOR SELECT *
FROM professores
FOR UPDATE OF cod_prof;
OPEN posição;
codigo_aux = “00”
DO WHILE SQLCNT <> 0
@ 10, 10 SAY “Digite o código: “;
GET codigo_aux;
DOUJF
PICTURE “99”
read
UPDATE professores
SET cod_prof = codigo_aux
WHERE CURRENT OF posição;
FETCH posição
INTO cod_prof, nome_prof;
ENDDO
CLOSE posição;
H )HFKDPHQWRGH&XUVRUHV
Cada cursor aberto eqüivale a uma área de trabalho ocupada, por isso, o controle do
número de áreas abertas se torna crítico para o bom funcionamento dos programas. Por
isso, existe um comando que permite fechar os cursores que se tornarem desnecessários.
• Sintaxe:
CLOSE <cursor>;
• Exemplo:
CLOSE posição;
&RPDQGRV'LQkPLFRVHP0RGR3URJUDPDGR
Comandos dinâmicos permitem que se construa e submeta comandos SQL em tempo de
execução sob a forma de cadeias de caracteres.
D 3UHSDUDomRGH&RPDQGRV
Preparar um comando SQL significa compilá-lo e deixá-lo pronto para uso subseqüente.
• Sintaxe:
PREPARE <comando> FROM <string>;
E ([HFXomRGH&RPDQGRV
Comandos não precisam, necessariamente, serem preparados antes de serem executados.
• Sintaxe:
DOUJF
EXECUTE <comando> USING <parametro>

[, <parametro>]
[,...]
[, <parametro>];
• Exemplo:
void main ()
{
char* Scomando = “Update notas \
set nota = nota * 1.25 \
where cod_mat =?”;
char Materia [3];
printf (“Entre com o Codigo da Materia: “);

scanf (“%s”, Materia);
EXEC SQL
prepare Comando from:Scomando;
execute Comando using:Materia;
END EXEC
}
DOUJF
$SrQGLFH$
([HUFtFLRVGH3URMHWRGH%'
1. Uma companhia de comércio de livros trabalha recebendo pedidos de livros dos clientes,
encomendando-os para editoras e remetendo-os aos clientes assim que disponíveis.
Os pedidos de compra a editoras são feitos em lotes para que a companhia possa desfrutar
de descontos por fazer encomendas maiores.
As remessas aos clientes são feitas assim que o pedido estiver completamente atendido.
Quando da entrega, o cliente recebe também um aviso de cobrança para que possa efetuar
o pagamento (o cliente paga somente após ter recebido os livros encomendados).
As editoras, por sua vez, de posse dos pedidos, enviam à companhia juntamente com os
livros, uma guia de remessa (para possibilitar a companhia conferir os produtos enviados
com os realmente recebidos) e uma fatura que deverá ser liquidada pela companhia.
2. A TELEFONICA está querendo automatizar suas operações, e após algumas conversas

com esta, conseguimos a seguinte descrição.
Existem duas maneiras para se adquirir um telefone: através de um particular e através da

própria TELEFONICA.
Ao adquirir um telefone de um particular, deve-se preencher um formulário apropriado

que é conseguido na própria TELEFONICA onde constam os dados pessoais de ambas as
partes e também suas assinaturas. Entregue este formulário na TELEFONICA, é feita
então a transferência de titularidade do proprietário antigo para o novo proprietário.
Para se adquirir um telefone da própria TELEFONICA, deve-se dirigir a uma de suas lojas
e preencher um formulário de inscrição com os dados pessoais do pretendente. Verifica-se
então, com base no endereço do pretendente, mais especificamente com base no bairro em
que resido o mesmo, os prefixos das linhas que poderiam atender a sua residência. No caso
DOUJF
de haver alguma linha da TELEFONICA com o prefixo apropriado e livre, esta é vendida
ao interessado; caso contrário, a TELEFONICA lhe vende um plano de expansão. Em
qualquer caso, o pagamento poderá ser feito de diversas maneiras, de acordo com os
planos de pagamento vigentes (estes planos são mutáveis com o tempo, naturalmente
somente para compradores novos).
Quando a TELEFONICA instala novas centrais na rede telefônica (e portanto passa a

dispor de novas linhas), contata-se os proprietários de planos de expansão da linha
(prefixo)correspondente à central instalada e faz-se então a instalação da linha se o
proprietário ainda morar em um local adequado a linha e cancela-se o plano de expansão
correspondente, transferindo-se a titularidade da nova linha da TELEFONICA para o novo
assinante.
3. A indústria de autopeças AUTOPARTS fornece seus produtos a três classes básicas de

clientes: Indústrias Automobilísticas, Revendedores Autorizados e Público em Geral. A
cada reajuste de preços a AUTOPARTS emite listas de preços, que contém, para cada
produto, o preço que será cobrado pela AUTOPARTS de seus clientes, a partir da data de
vigência da lista. Note que os preços são diferentes para cada classe de cliente. Uma lista
de preços é válida desde sua data de vigência, até que outra lista com outra data de
vigência seja emitida.
As listas de preços são base para o Sistema de Faturamento, que, a partir da identidade do
cliente e do produto, aplica o preço correspondente e o desconto instituído para obter o
preço de venda.
O desconto na AUTOPARTS é algo bastante flexível: ele pode ser dado para um produto,
para uma categoria de produtos, para um cliente, para uma classe de clientes ou para
qualquer combinação destas coisas. No entanto, o faturamento só considerará o desconto
se ele tiver sido cadastrado previamente.
O Departamento de Administração de Vendas possui um órgão coordenador centralizado

na SEDE e órgãos operacionais distribuídos pelas FILIAIS.
DOUJF
É atribuição da coordenação centralizada na SEDE operar a política de reajustes de preços

que podem ser motivados por:
• Reajuste nos formadores de preços dos produtos (matéria prima, salários, custos operacionais, etc);
• Índices de reajustes autorizados pelo governo;
• Preços praticados pela concorrência.
Assim, a política de preços da AUTOPARTS varia entre "estabelecer o melhor preço para
a AUTOPARTS" e "praticar aquilo que o governo e a concorrência permitem",
dependendo do momento.
Para operar essa "política de preços", a coordenação precisa de apoio informatizado para:
Estabelecer índices de reajustes variados, de acordo com as várias situações (por produtos,
por classes de produto, por cliente, por classes de cliente, etc);
Simular as listas de preços resultantes e seu impacto no faturamento futuro;
Optar por uma determinada situação de simulação e efetivá-la;
Estabelecer índices de desconto de acordo com as várias possibilidades;
Simular o impacto desses descontos no faturamento, de acordo com uma determinada lista
de preços e uma determinada projeção de vendas;
Optar por uma determinada simulação de descontos e efetivá-la;
Manter histórico de listas de preços praticadas e de índices de desconto praticados.
Os órgãos operacionais distribuídos pelas FILIAIS tem por objetivo controlar a aplicação
da política de preços da AUTOPARTS.
O sistema de faturamento tem a opção de atribuir o preço e o desconto automaticamente

ou, por comando do operador do faturamento, permitir a entrada manual de preço ou de
um desconto quando a combinação preço/desconto não satisfizer a condição de venda. É
necessário acompanhar o preço efetivamente praticado para, com isso, subsidiar a geração
das novas tabelas de preços e de descontos, de forma a minimizar o preço dado
manualmente no futuro.
DOUJF
$SrQGLFH%
7DEHODVGD6HomRGH
ÈOJHEUD&iOFXOR5HODFLRQDO
$OXBRB$QR
RAAlu NomeAlu CodCur
92023 Álvaro PD
92078 Ana EL
92128 Débora EL
92159 Fábio PD
92193 Gabriela EL
92210 Ana PD
92309 Victor PD
$OXBRB$QR
91019 Gilmar PD
91056 Antônio EL
91152 Durval EL
91187 Fabrício PD
91190 Gilmar EL
91231 João PD
91359 Valter PD
$OXBRB$QR
90001 Alex PD
90036 André EL
90147 David EL
90179 Felipe PD
90182 Gilmar EL
92236 José PD
92393 Sérgio PD
&XUVRV
CodCur NomeCur
DOUJF
PD Processamento de Dados
EL Eletro Eletrônica
0DW2EU&XU$QR
CodCur Ano NomeMat
PD 1 Matemática
PD 1 Português
PD 2 Banco de Dados
PD 3 Inteligência Artificial
PD 3 Redes
EL 1 Eletrônica Básica
EL 2 Circuitos Lógicos
EL 2 Automação
EL 3 Projeto Elétrico
DOUJF
$SrQGLFH&
7DEHODV8VDGDVQD6HomRVREUH64/
DOXQRVR3'
5$ 120( $3(/,'2
89131 Heloisa Girardi Malavasi
89147 Jorge Hissasi Hori Maçãzinha
89276 Silas Davi Santos
90002 Adriana Davólio Béri
90003 Adriana Ketaiama Kojima Kety
90030 Alvaro de Matos Miranda Filho Gaf’s
90033 Ana Carolina Teles de Souza
90036 André Luís Arendt Boca
90062 Clenilce Valença Reis Cleq
90074 David A. C. Romanetto Chuchu
90089 Eduardo Seiti de oliveira Queixada
90090 Eduardo Tsuyoshi Tanabe Philco
90095 Eric Fernando do Amaral Neves Nelinho
90109 Fernando Tessari Rodrigues Tocha
90113 Fernando Luís do Nascimento Marciano
90118 Gabriela de Fátima Batista Aparecida
90123 Gisele Leite Bizarri Labareda
90152 Juliana Cristina Biason
90185 Marcelo Eduardo dos Anjos Herman
90198 Maria Eugênia Verdaguer Magé
90199 Mariana Rodrigues
90214 Mônica de Grazia Henrique Muambeira
90218 Nívea Oliveira Camargo P. P.
90223 Rachel de Carvalho Paschoalino
90228 Raquel Moriconi Pacheco Bastiana
90229 Raquel Pinhatelli da Silva Vamp
90230 Regiane Feltrin de Melo
90238 Ricardo César Sebastião Tião
90242 Ricardo Santos Lisboa Pipoca
90249 Rodrigo Spadaccia Zolhu’s
90159 Sandra Regina Rigamonti Chibata
90268 Simone Rejane Mafra
90269 Tábata Emke
90287 Wesley Pires Bonifácio Vaca Loka
90501 Flávia Zaroni Camargo Ploff
DOUJF
DOXQRVR7$
5$ 120( $3(/,'2
90144 Joana Cogumelo
89166 Kelly Nariguda
89262 Sharon Nadadeira
QRWDV
5$ &2'B0$7 127$
90113 08 1.0
90218 01 9.5
90287 03 3.5
90090 09 0.0
90089 05 0.5
90230 01 5.0
90118 06 1.0
90259 07 4.0
90033 08 10.0
90214 04 1.5
90090 08 0.0
90090 03 0.0
90242 02 2.5
90238 04 2.5
90003 01 0.5
90074 07 3.0
90198 05 4.0
90199 01 8.0
90109 01 8.0
PDWHULDV
&2'B0$7 120( &2'B352)
01 LPC 01
02 CG 02
03 ISSO 03
04 APSI 01
05 IA 01
06 CAI 04
07 REDES 03
08 LMON 03
09 FPD 05
DOUJF
SURIHVVRUHV
&2'B352) 120(
01 André
02 Chico
03 Lucius
04 Celso
05 Rogério
06 Vagner
07 Renato
DOUJF
$SrQGLFH'
3DODYUDV5HVHUYDGDVGH64/
CHAR HAVING PUBLIC

CHARACTER IN REAL
CHECK INDICATOR ROLLBACK
CLOSE INSERT SCHEMA
COBOL INT SECTION
COMMIT INTEGER SELECT
CONTINUE INTO SET
COUNT IS SMALLINT
CRATE LANGUAGE SOME
CURRENT LIKE SQL
CURSOR MAX SQLCODE
DEC MIN SQLERROR
DECIMALDECLARE MODULE SUM
DELETE NOT TABLE
DESC NULL TO
DISTINCT NUMERIC UNION
DOUBLE OF UNIQUE
END ON UPDATE
ESCAPE OPEN USER
EXEC OPTION VALUES
EXISTS OR VIEW
FETCH ORDER WHENEVER
FLOAT PASCAL WHERE
FOR PLI WITH
FORTRAN PRECISION WORK
GRANT PRIVILEGES
GROUP PROCEDURE
DOUJF
$SrQGLFH(
([HUFtFLRVGH/LQJXDJHQVGH&RQVXOWD
1. Considere o seguinte BD:
Motoristas {Cart, DtVencCart, Nom, End, Cid,Est}

Veículos {Plac, Propr, EndProp, CidProp, EstPropVei,EstProp, Comb, Chas, Ano}
IPVA {PlacVei, Ano, Qta, ValQta, DtPagQta}
Infrações {Nro, Descr}
Multas {PlacVei, Dt, Hor, NroInfr, Local, Cid, Est}
MultasPagas {PlacVei, Dt, Hor, NroInfr, Local, Cid, Est}
Responda usando Cálculo Relacional, Álgebra Relacional e SQL às seguintes consultas:
Quais os proprietários em dia com o IPVA?
Quais os proprietários multados por excesso de velocidade?
Quais os proprietários que nunca foram multados?
Quais os proprietários que foram multados pelo menos uma vez?
Médicos {CRM, Nom}

Cirurgiões {CRM, NroBIP}
Clínicos {CRM, Tel}
Especialidades {Cod, Nom}
EspecDosMed {CRM, Cod}
Enfermarias {Cod, Nom}
Trabalha {CRM, Cod}
Coordena {CRM, Cod}
DOUJF
Quais as especialidades do coordenador da enfermaria deemergência?
Qual o nome de todos os cirurgiões da enfermaria de pediatriaespecialistas em

correção?
HospitaisGeriátricos {Cod, Nom, NroLeit}

HospitaisPsiquiátricos {Cod, Nom, NroLeit}
Laboratórios {Nro, Nom, Tel}
HospLab {Cod, Nro}
Qual o nome dos laboratórios que não trabalham com nenhum hospital?
Qual o nome e o telefone dos laboratórios que trabalham apenas com hospitais que são
só geriátricos?
Qual o número dos laboratórios que trabalham apenas com hospitais que são
geriátricos e psiquiátricos?
DOUJF

Apostila de Inglês

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila de Inglês

Enviado por

Direitos autorais:

Formatos disponíveis

,QVWLWXWRGH,QIRUPiWLFD

Curso: Disciplina: Docente: C.H. Semanal Período Letivo:

Objetivo Geral da Disciplina:

• Projeto Lógico e Projeto Físico de Bancos de Dados

• The Entity-Relationship Approach to Logical Database Design

• Computer Database Organization

• Fundamental Concepts of Information Modeling

• Sistemas de Bancos de Dados

Dizemos GDGR qualquer conjunto de símbolos organizados com intencionalidade para

No contexto da computação, quando falamos a respeito de armazenar informações do mundo

Neste processo de representação, assumimos de maneira implícita que todos os entes do

Um dado representa primariamente informações sobre uma entidade em uma realidade, e

Chamamos HOHPHQWRGHGDGR a qualquer conjunto de símbolos com um significado específico

Antes de vermos um exemplo, convém que apresentemos algumas definições:

Dizemos que o atributo Y da relação R é funcionalmente do atributo X da mesma relação

A título de exemplo, consideremos a relação não normalizada abaixo:

• Passando para a 1FN temos:

Prod {3, NomeP, CorP, PesoP}

• Passando para a 2FN temos:

Prod {3, NomeP, CorP, PesoP}

• Finalmente, passando para a 3FN temos:

Prod {3, NomeP, CorP, PesoP}

Entre as características desta abordagem tradicional, podemos ressaltar o incentivo ao

Se procedermos a uma análise nas implicações desta abordagem poderemos identificar a

Um sistema de computação que modele os dados de uma organização de acordo com a

O termo FRPSDUWLOKDGR é em geral estendido para descrever compartilhamento no tempo, isto

Um sistema de banco de dados envolve quatro componentes maiores: hardware, software,

Antes dos SGBD, como já dissemos anteriormente, os próprios programas aplicativos

1. Alguns programas aplicativos são extremamente sensíveis à organização dos arquivos

Enquanto Não Achou E Não Fim Faça

Este programa supõe e se aproveita da suposição de que o arquivo de funcionários estaria

Qualquer das mudanças abaixo provocaria mudanças no programa aplicativo:

 Mudança do tipo de um campo do arquivo não utilizado pelo programa;

 Retirada de um campo do arquivo não utilizado pelo programa.

3. Considere a seguinte situação: dois programas precisam do mesmo arquivo, só que em

 Freqüentes reorganizações (são caras e limitam o acesso "on-line");

Para alcançar a independência de dados, o SGBD mantém o BD e provê comandos para

• Promover o compartilhamento dos dados (não somente as aplicações existentes podem

• Manter restrições de segurança (a centralização dos dados permite um maior controle

• Garantir a integridade (restrições de integridade ou procedimentos de validação podem ser

alterações no BD com menor impacto sobre as aplicações, tornando possíveis

• Um esquema intermediário ou conceitual que consiste de uma descrição global e não

Sigla Nome Nº Aulas/Semana

• Definição preliminar do modelo de armazenamento de dados;

• Definição do modelo funcional com revisão do modelo de armazenamento de dados;

• Definição do diagrama de estados do sistema, isto é, do diálogo do sistema através de

Uma técnica moderna para representar a estrutura de armazenamento de dados em um sistema

&RQFHLWXDO 5HODFLRQDO 7UDGLFLRQDO

funções componentes e estas em suas componentes menores. A abordagem funcional parece

• Vencidas todas estas dificuldades e de posse de um modelo descritivo do mundo real,

Em geral, a construção do modelo conceitual de um BD se processa em duas fases: a fase

• Dificuldades de natureza política (quando os grupos de usuários não exista, possuem

• Problemas de comunicação (sabemos que a linguagem que utilizamos para nos

• Omissões voluntárias ou involuntárias de informação (as omissões voluntárias são via de

extremamente complicado e nutrem uma espécie de aversão preconceituosa a tudo

Chega o momento de definirmos mais formalmente um conceito ao qual de certa forma já

Já mencionamos anteriormente que a tecnologia de BD vem para aglutinar dados de

Entenderemos por entidade um conjunto de objetos semelhantes segundo algum critério.

O MER é um modelo que tem como meio de expressão um simbolismo gráfico.

no relacionamento agendamento, quando desejamos desagendar uma consulta, simplesmente

chave no relacionamento (que sozinha identificaria unicamente uma ligação no

Aconselha-se que em paralelo à construção do modelo, vá se construindo também um

O símbolo de chave primária é um asterisco seguido opcionalmente por um número. Este

O símbolo de super chave é um sinal de sustenido seguido opcionalmente por um número.

Prod {3, NomeP, CorP, PesoP}

Prod {3, NomeP, CorP, PesoP}

Prod {3, NomeP, CorP, PesoP}

Mudança do tipo de um campo do arquivo não utilizado pelo programa;

Retirada de um campo do arquivo não utilizado pelo programa.

Freqüentes reorganizações (são caras e limitam o acesso "on-line");

O operador interseção tem como símbolo o símbolo de interseção da matemática ( ∩.

Quais os alunos de PD do 1º ano?

Quais os nomes dos alunos do 1º ano?

Qual o nome do curso do aluno 90147 do 3º ano?

Quais os alunos do colégio?

&+$57 Cadeia de caracteres (possivelmente constituída de letras,

9$5&+$57 Cadeia de caracteres (possivelmente constituída de letras,

)/2$7' Número real de ponto flutuante com precisão de no