Apostila BD

1
1. BANCOS DE DADOS................................................................................4
1.1. Banco de Dados (BD)...................................................................................4
1.2. Sistema de Gerncia de Banco de Dados (SGBD)....................................4
1.2.1.Processamento de Dados sem Banco de Dados....................................5
1.2.2.Processamento de dados com uso de SGBD.........................................5
1.2.3.Principais Componentes de um SGBD..................................................6
1.2.4.Funes de um SGBD.............................................................................6
1.3. Fluxo Operacional de Dados e Controle.....................................................8
1.4. Abstrao de Dados....................................................................................10
1.5. Modelos de Bancos de Dados....................................................................11
1.6. Independncia de Dados.............................................................................11
1.7. Especificao CODASYL para arquitetura BD.......................................12
1.8. Especificao ANSI/X3/SPARC para arquitetura BD............................12
1.9. Funes relacionadas ao SGBD................................................................14
1.9.1.Administrador de Dados.......................................................................14
1.9.2.Administrador de Banco de Dados......................................................14
1.10.Arquiteturas para uso do SGBD................................................................15
1.10.1.Mono-usurio.......................................................................................15
1.10.2.Multi-Usurio com Processamento Central ......................................15
1.10.3.Arquitetura Cliente/Servidor ..............................................................15
1.11.Fases do Projeto de BD..............................................................................16
1.11.1.Construir o Modelo Conceitual.........................................................16
1.11.2.Construir o Modelo Lgico ................................................................16
1.11.3.Construir o Modelo Fsico..................................................................16
1.11.4.Avaliar o Modelo Fsico .....................................................................16
1.11.5.Implementar o BD...............................................................................16
2. MODELAGEM DE DADOS....................................................................17
2.1. Conceitos .....................................................................................................17
2.2. Requisitos para Modelagem de Dados......................................................17
2.3. Modelos Conceituais ..................................................................................17
2.4. Modelos Lgicos.........................................................................................18
2.4.1.Modelo Relacional.................................................................................18
2.4.2.Modelo de Rede.....................................................................................19
2.4.3.Modelo Hierrquico ..............................................................................20
2.5. Modelo de Dados Fsico.............................................................................23
2
3. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)....................23
3.1. Introduo....................................................................................................23
3.2. Entidade .......................................................................................................23
3.3. Relacionamento...........................................................................................24
3.3.1.Auto-relacionamento.............................................................................25
3.3.2.Cardinalidade de Relacionamentos......................................................25
3.3.3.Cardinalidade Mxima..........................................................................26
3.3.4.Classificao de Relacionamentos Binrios .......................................27
3.3.5.Relacionamento ternrio.......................................................................30
3.3.6.Cardinalidade mnima ...........................................................................30
3.4. Notaes Alternativas.................................................................................31
3.5. Atributo........................................................................................................32
3.5.1.Domnio..................................................................................................32
3.5.2.Tipos de Atributos.................................................................................32
3.5.3.Atributo de Relacionamento.................................................................33
3.5.4.Identificador de Entidades ....................................................................33
3.5.5.Relacionamento Identificador (Entidade Fraca).................................34
3.5.6.Identificador de Relacionamentos........................................................34
3.6. Generalizao/Especializao....................................................................35
3.7. Entidade Associativa (Agregao) ............................................................37
3.8. Relacionamento Mutuamente Exclusivo..................................................38
4. O MODELO RELACIONAL....................................................................39
4.1. Caractersticas das Tabelas - Modelo Relacional ...................................40
4.2. Conceitos Bsicos.......................................................................................41
4.2.1.Chave primria : (primary key) ............................................................41
4.2.2.Chave estrangeira : (foreign key).........................................................41
4.2.3.Chave candidata ou alternativa ............................................................41
4.3. Normalizao...............................................................................................42
4.3.1.Ilustrao de um sistema a ser normalizado .......................................43
4.3.2.Anlise de Dependncia Funcional......................................................46
4.3.3.Formas Normais.....................................................................................50
4.3.4.Roteiro Prtico para Normalizao......................................................50
4.3.5.Exemplo de Normalizao....................................................................52
4.4. Transposio D.E.R para D.T.R (Diagrama de Tabelas Relacionais)...56
4.4.1.Simbologia adotada no modelo relacional ..........................................56
4.4.2.Anlise da Entidade no D.E.R..............................................................57
4.4.3.Anlise de Relacionamento..................................................................57
3
4.5. Restries de integridade no modelo Relacional .....................................65
4.5.1.Integridade Lgica.................................................................................65
4.5.2.Integridade Fsica ..................................................................................65
4.6.Linguagens Relacionais................................................................................80
4.7.SQL (Structured Query Language) .............................................................85
4.7.1.DDL (Data Definition Language .........................................................86
4.7.2.DML (Data Manipulation Language).................................................93
4.7.3.DCL (Data Control Language).......................................................... 107
4.7.4.Transaction Control............................................................................ 110
4.7.5.Restries de Integridade usando Stored Procedures e Triggers... 113
5. EXERCCIOS: ......................................................................................... 127
5.1.Exercicios de Modelagem de Dados......................................................... 127
5.2.Exerccios de Normalizao:..................................................................... 130
5.3.Exerccios de SQL...................................................................................... 133
5.4.Execcios de Algebra Relacional .............................................................. 138
6. BIBLIOGRAFIA............................... .................................................142
4
1. BANCOS DE DADOS
1.1. BANCO DE DADOS (BD)
Um Banco de Dados (BD) pode ser definido como uma coleo de
dados interrelacionados, armazenados de forma centralizada ou distribuda,
com redundncia controlada, para servir a uma ou mais aplicaes.
1.2. SISTEMA DE GERNCIA DE BANCO DE DADOS (SGBD)
Conjunto de software para gerenciar (definir, criar, modificar,
usar) um BD e garantir a integridade e segurana dos dados. O SGBD a
interface entre os programas de aplicao e o BD. Em ingls denominado
DataBase Management System (DBMS).
5
1.2.1. PROCESSAMENTO DE DADOS SEM BANCO DE DADOS
Dados de diferentes aplicaes no esto integrados, pois so projetados
para atender a uma aplicao especfica.
Problemas da falta de integrao de dados:
O mesmo objeto da realidade mltiplas vezes representado na base de
dados. Exemplo: dados de um produto em uma indstria.
Redundncia no controlada de dados: No h gerncia automtica da
redundncia, o que leva a inconsistncia dos dados devido a
redigitao de informaes
Dificuldade de extrao de informaes: os dados so projetados para
atender aplicaes especificas gerando dificuldades para o
cruzamento de informaes
Dados pouco confiveis e de baixa disponibilidade
1.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD
Os dados usados por uma comunidade de usurios so integrados no
Banco de Dados. Cada informao armazenada uma nica vez, sendo que as
eventuais redundncias so controladas pelo sistema em computador, ficando
transparentes para os usurios.
6
1.2.3. PRINCIPAIS COMPONENTES DE UM SGBD
Dicionrio de dados (Data Dictionary):
Descreve os dados e suas relaes em forma conceitual e independente de
seu envolvimento nas diversas aplicaes. Fornece referncias cruzadas entre
os dados e as aplicaes.
Linguagem de definio de dados (DDL - Data Definition Language):
Descreve os dados que esto armazenados no BD. As descries dos dados
so guardadas em um meta banco de dados.
Linguagem de acesso (DML - Data Manipulation Language):
Usada para escrever as instrues que trabalham sobre a base de dados,
permitindo o acesso e atualizao dos dados pelos programas de aplicao.
Linguagem de consulta (QUERY):
Permite que o usurio final, com poucos conhecimentos tcnicos, possa
obter de forma simples, informaes do BD.
Utilitrios administrativos:
Programas auxiliares para carregar, reorganizar, adicionar, modificar a
descrio do BD, obter cpias de reserva e recuperar a integridade fsica em
caso de acidentes.
1.2.4. FUNES DE UM SGBD
Um princpio bsico em BD determina que cada item de dado deveria
ser capturado apenas uma vez e ento armazenado, de modo que possa tornar
disponvel para atender a qualquer necessidade de acesso qualquer momento.
7
Alguns pontos importantes so:
Independncia dos dados: O SGBD deve oferecer isolamento das
aplicaes em relao aos dados. Esta caracterstica permite
modificar o modelo de dados do BD sem necessidade de reescrever
ou recompilar todos os programas que esto prontos. As definies
dos dados e os relacionamentos entre os dados so separados dos
cdigos os programas.
Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturas
de dados complexas, os arquivos devem ser projetados para atender a
diferentes necessidades, permitindo desenvolver aplicaes melhores,
mais seguras e mais rapidamente. Deve possui comandos poderosos
em sua linguagem de acesso.
Integridade dos dados: O SGBD deve garantir a integridade dos dados,
atravs da implementao de restries adequadas. Isto significa que
os dados devem ser precisos e vlidos.
Redundncia dos dados: O SGBD deve manter a redundncia de dados
sob controle, ou seja, ainda que existam diversas representaes do
mesmo dado, do ponto de vista do usurio como se existisse uma
nica representao.
Segurana e privacidade dos dados: O SGBD deve assegurar que estes
s podero ser acessados ou modificados por usurios autorizados.
Rpida recuperao aps falha: Os dados so de importncia vital e
no podem ser perdidos. Assim, o SGBD deve implementar sistemas
de tolerncia a falhas, tais como estrutura automtica de recover e
uso do conceito de transao.
Uso compartilhado: O BD pode ser acessado concorrentemente por
mltiplos usurios.
Controle do espao de armazenamento: O SGBD deve manter
controle das reas de disco ocupadas, evitando a ocorrncia de falhas
por falta de espao de armazenamento.
8
1.3. FLUXO OPERACIONAL DE DADOS E CONTROLE
PROGRAMA DE
APLICACAO
SISTEMA
OPERACIONAL
BASE
DADOS
1
AREA LOCAL
DO PROGRAMA
10
S.G.B.D
5
AREA DE
9
ENTRADA/SAIDA
2 6
ESQUEMAS,
DICIONARIO
DE DADOS,
DIRETORIOS
3 7
FLUXO DE DADOS
FLUXO DE CONTROLE
8
4
9
1 - O programa do usurio comunica-se com o SGBD utilizando DML
pedindo a leitura de um registro lgico.
2 - O SGBD emite um comando para o S.O. para leitura dos
esquemas (META DADOS).
3 - O S.O. acessa os esquemas.
4 - Os Meta-dados so transferidos para rea de E/S do SGBD.
5 - O SGBD consulta os Meta-dados para saber como traduzir o
comando do usurio.
6 - O SGBD emite os comandos para que o S.O. leia os
registros fsicos necessrios.
7 - O S.O. acessa a base de dados.
8 - Os registros fsicos so transferidos para rea de E/S do
SGBD.
9 - O SGBD seleciona os dados necessrios para formar o(s)
registro(s) lgico(s) pedidos pelo usurio, se necessrio faz a
transformao, e coloca o registro lgico na rea do
usurio/aplicao.
10 - O SGBD envia ao programa de aplicao um cdigo indicando fim
de comando.
10
1.4. ABSTRAO DE DADOS
Um propsito central de um SGBD proporcionar aos usurios uma
viso abstrata dos dados, isto , o sistema esconde certos detalhes de como os
dados so armazenados ou mantidos. No entanto, os dados precisam ser
recuperados eficientemente.
A preocupao com a eficincia leva a concepo de estruturas de
dados complexas para representao dos dados no BD. Porm, uma vez que
SGBD so freqentemente usados por pessoas sem treinamento na rea de
computao, esta complexidade precisa ser escondida dos usurios. Isto
conseguido definindo-se diversos nveis de abstrao pelos quais o BD pode
ser visto:
NVEL FSICO: o nvel mais baixo de abstrao, no qual se descreve
como os dados so armazenados. Estruturas complexas, de baixo
nvel, so descritas em detalhe.
NVEL CONCEITUAL: o nvel que descreve quais os dados so
realmente armazenados no BD e quais os relacionamentos existentes
entre eles. Este nvel descreve o BD como um pequeno nmero de
estruturas relativamente simples. Muito embora a implementao de
estruturas simples no nvel conceitual possa envolver estruturas
complexas no nvel fsico, o usurio do nvel conceitual no
precisa saber disto.
NVEL VISO: Este o nvel mais alto de abstrao, no qual se expe
apenas parte do BD. Na maioria das vezes os usurios no esto
preocupados com todas as informaes do BD e sim com apenas
parte delas (Vises dos Usurios)
11
1.5. MODELOS DE BANCOS DE DADOS
Um modelo de (banco de) dados uma descrio dos tipos de
informaes que esto armazenadas em um banco de dados, ou seja, a
descrio formal da estrutura de BD.
Estes modelos podem ser escritos em linguagens textuais ou linguagens
grficas. Cada apresentao do modelo denominado esquema de banco de
dados.
Se tomarmos como exemplo uma indstria, o modelo de dados deve
mostrar que so armazenadas informaes sobre produtos, tais como cdigo,
descrio e preo. Porm o modelo de dados no vai informar quais produtos
esto armazenados no Banco de Dados.
No projeto de um banco de dados, geralmente so considerados 3
modelos: conceitual, lgico e fsico.
Modelo conceitual: uma descrio mais abstrata da base de dados.
No contm detalhes de implementao e independente do tipo de
SGBD usado. o ponto de partida para o projeto da base de dados.
Modelo Lgico: a descrio da base de dados conforme vista pelos
usurio do SGBD (programadores e aplicaes). dependente do tipo
de SGBD escolhido, mas no contm detalhes da implementao
(uma vez que o SGBD oferece abstrao e independncia de dados).
Modelo fsico (interno): Descrio de como a base de dados
armazenada internamente. Geralmente s alterada para ajuste de
desempenho. A tendncia dos produtos modernos ocultar cada vez
mais os detalhes fsicos de implementao.
1.6. INDEPENDNCIA DE DADOS
Independncia de dados a nvel fsico: a capacidade de se modificar o modelo
fsico, sem precisar reescrever os programas de aplicao.
Independncia dados a nvel lgico: a capacidade de se modificar o esquema
lgico, sem a necessidade de reescrever os programas de aplicao.
Modificaes no nvel lgico so necessrias sempre que a estrutura lgica
do BD for alterada. Em alguns casos a recompilao pode ser requerida.
12
1.7. ESPECIFICAO CODASYL PARA ARQUITETURA BD
Primeira especificao padro de BD conhecida, no papel 1960,
implementada 1971 - Modelo DBTG-CODASYL(Data Base Task Group
Conference on Data Systems and Languages)
Introduziu o conceito de SCHEMA ( descrio completa do BD) e SUB-
SCHEMA (descrio do dados que so conhecidos por um ou mais programas
de aplicao)
1.8. ESPECIFICAO ANSI/X3/SPARC PARA ARQUITETURA BD
Proposta de modelo de referncia para arquiteturas de BD.
Teve incio em 1972 (Relatrio provisrio ) e terminou em 1983 (
Relatrio final ).
Abordagem proposta por um grupo de trabalho estabelecido pelo
SPARC(Standard Planning and Requeriments Committe) do
ANSI/X3(American National Standards Committe on Computers and
Information Processing).
Os objetivos do grupo de estudo, foram os de determinar as reas, se
existentes, de tecnologia de BD onde fosse apropriada uma atividade de
padronizao, e de produzir um conjunto de recomendaes para aes em
cada uma dessas reas.
Trabalhando sobre estes objetivos, o grupo verificou que os
INTERFACES seriam os nicos aspectos do SBD possivelmente passveis de
serem padronizados.
13
Grupo sugere trs esquemas:
ESQUEMA EXTERNO 1 ESQUEMA EXTERNO 2 ESQUEMA EXTERNO 3
S.G.B.D. ESQUEMA
CONCEITUAL
ESQUEMA INTERNO
BD
APLICACAO 1 APLICACAO 2 APLICACAO 3
VISAO
USUARIO
VISAO GLOBAL
(de toda empresa)
VISAO IMPLEMENTACAO
(fisica)
14
1.9. FUNES RELACIONADAS AO SGBD
1.9.1. ADMINISTRADOR DE DADOS
Gerenciar o dado como um recurso da empresa.
Planejar, desenvolver e divulgar as bases de dados da empresa.
Permitir a descentralizao dos processos, mas manter centralizado os dados.
Permitir fcil e rpido acesso as informaes a partir dos dados armazenados
O grande objetivo de administrador de dados permitir que vrios usurios
compartilhem os mesmos dados. Deste modo, os dados no pertencem a
nenhum sistema ou usurio de forma especfica, e sim, organizao como
um todo. Assim, o administrador de dados se preocupa basicamente com a
organizao dos dados e no com o seu armazenamento.
1.9.2. ADMINISTRADOR DE BANCO DE DADOS
O DBA (DataBase Administrator) pessoa ou grupo de pessoas
responsvel pelo controle do SGBD. So tarefas do DBA:
Responsabilidade pelos modelos lgico e fsico (definindo a estrutura de
armazenamento)
Coordenar o acesso ao SGBD (usurios e senhas)
Definir a estratgia de backup
Melhorar o desempenho do SGBD
Manter o dicionrio de dados
15
1.10. ARQUITETURAS PARA USO DO SGBD
1.10.1. MONO-USURIO
BD est no mesmo computador que as aplicaes
No h mltiplos usurios
Recuperao geralmente atravs de backup
Tpico de computadores pessoais
1.10.2. MULTI-USURIO COM PROCESSAMENTO CENTRAL
BD est no mesmo computador que as aplicaes
Mltiplos usurios acessando atravs de terminais
Tpico de ambientes com mainframe
1.10.3. ARQUITETURA CLIENTE/SERVIDOR
Multi-usurio
Servidor dedicado ao Banco de Dados, executando o SGBD
As estaes clientes executam apenas as aplicaes
Trfego na rede menor
Arquitetura atualmente em uso
16
1.11. FASES DO PROJETO DE BD
1.11.1. CONSTRUIR O MODELO CONCEITUAL
Modelo de alto nvel, independente da implementao
Etapa de levantamento de dados
Uso de uma tcnica de modelagem de dados
Abstrao do ambiente de hardware/software
1.11.2. CONSTRUIR O MODELO LGICO
Modelo implementvel, dependente do tipo de SGBD a ser usado
Considera as necessidades de processamento
Considera as caractersticas e restries do SGBD
Etapa de normalizao dos dados
1.11.3. CONSTRUIR O MODELO FSICO
Modelo implementvel, com mtodos de acesso e estrutura fsica
Considera necessidades de desempenho
Considera as caractersticas e restries do SGBD
Dependente das caractersticas de hardware/software
1.11.4. AVALIAR O MODELO FSICO
Avaliar o desempenho das aplicaes
Avaliar os caminhos de acesso aos dados e estruturas utilizadas
1.11.5. IMPLEMENTAR O BD
Etapa de carga (load) dos dados
Gerar as interfaces com outras aplicaes
17
2. MODELAGEM DE DADOS
2.1. CONCEITOS
Abstrao: processo mental atravs do qual selecionamos determinadas
propriedades ou caractersticas dos objetos e exclumos outras, consideradas
menos relevantes para o problema que esta sendo analisado.
Modelo: uma abstrao, uma representao simplificada, de uma parcela do
mundo real, composta por objetos reais.
Modelagem: atividade atravs da qual se cria um modelo.
Modelo de dados: Um modelo de dados uma descrio das informaes que
devem ser armazenadas em um banco de dados, ou seja, a descrio
formal da estrutura de BD (descrio dos dados, dos relacionamentos entre
os dados, da semntica e das restries impostas aos dados).
2.2. REQUISITOS PARA MODELAGEM DE DADOS
Entender a realidade em questo, identificando os objetos que compe a parte
da realidade que vai ser modelada..
Representar formalmente a realidade analisada, construindo um modelo de
dados.
Estruturar o modelo obtido e adequ-lo ao SGBD a ser usado, transformando o
modelo conceitual em modelo lgico.
2.3. MODELOS CONCEITUAIS
So usados para descrio de dados no nvel conceitual. Proporcionam
grande capacidade de estruturao e permitem a especificao de restries de
dados de forma explcita. Exemplos:
Modelo Entidade-Relacionamento (M.E.R.)
Modelo de Semntica de dados
Modelo Infolgico
Modelos Orientados para Objetos (OO)
18
2.4. MODELOS LGICOS
So usados na descrio dos dados no nvel lgico. Em contraste com
modelos conceituais, esses modelos so usados para especificar tanto a
estrutura lgica global do BD como uma descrio em alto nvel da
implementao.
2.4.1. MODELO RELACIONAL
Um BD relacional possui apenas um tipo de construo, a tabela. Uma
tabela composta por linhas (tuplas) e colunas (atributos). Os relacionamentos
entre os dados tambm so representados ou por tabelas, ou atravs da
reproduo dos valores de atributos.
Idias bsicas Edward F. Codd , laboratrio pesquisas da IBM em 1970
Exemplo : Considere o BD composto de clientes e contas.
NOME RUA CIDADE N CONTA
Jos Rua A JF 40
Juca Rua B RJ 30
Juca Rua B RJ 38 *
Carlos Rua C SP 45
Carlos Rua C SP 38 *
N CONTA SALDO
40 1.000,00
30 2.000,00
38 2.500,00
45 3500,00
* compartilham a mesma conta, devem ser scios
19
2.4.2. MODELO DE REDE
O BD em rede um grafo, onde os ns representam os registros e os
arcos representam os relacionamentos entre os registros, atravs de ligaes
pai-filho. Diferente do modelo hierrquico, um registro pode possuir diversos
registros pai.
Origem na linguagem de programao Cobol, Primeiro SGBD comercial
IDS (Integrated Data Store) projetado para a General Eletric na dcada de 60.
Extenso : DBTG-CODASYL(Data Base Task Group Conference on
Data Systems and Languages) , 1 especificao padro de BD em 1971.
Exemplos : TOTAL, IDMS, ADABAS
JOSE RUA A JF
CARLOS RUA C SP
40 1.000,00
45 3.500,00
38 2.500,00
30 2.000,00 JUCA RUA B RJ
20
2.4.3. MODELO HIERRQUICO
Um BD hierrquico uma coleo de rvores de registros. Os registros
so usados para representar os dados e ponteiros so usados para representar o
relacionamento entre os dados, numa ligao do tipo pai-filho. A restrio
que um determinado registro somente pode possuir um registro pai.
Exemplo : 1 SGBD da IBM IMS (Information Management System),
DMS2 SGBD da Unisys.
JOS RUA A JF JUCA RUA B RJ CARLOS RUA C SP
40 1.000,00 30 2.000,00
45 3.500,00 38 2.500,00
38 2.500,00
21
EXEMPLOS DOS MODELOS
A) MODELO RELACIONAL :
FORNECEDOR ( fabricante )
RAZO TECNOLOGIA
Unisys Propria
Elebra Control Data
Flex Disk Shugart
IBM Propria
Microlab Ampex
PEA (disco)
CODIGO TIPO ACIONAMENTO
410 Flexvel Step Motor
416 Rgido Voice Coil Linear
421 Rgido Step Motor
427 Rgido Voice Coil Rotatrio
FORNECIMENTO
RAZAO CODIGO PREO
Unisys 416 6.360,00
Elebra 416 2.480,00
Elebra 410 230,00
Flex Disk 421 250,00
Flex Disk 427 900,00
IBM 416 5.808,00
Microlab 427 1.100,00
22
B) MODELO REDE
UNISYS PROP. ELEBRA CON.DATA FLEX DISK SHUGART IBM PROP. MICROLAB AMPEX
6.360,00 2.480,00 230,00 250,00 900,00 5.808,00 1.100,00
410 FLEXIVEL STEP M 416 RIGIDO VOICE 421 RIGIDO STEP M 427 RIGIDO VC DAT
C) MODELO HIERRQUICO
416 RIGIDO VOICE COIL LINEAR
410 FLEXIVEL STEP M
UNISYS PROPRIA 6.380,00
ELEBRA C. DATA 2.420,00
ELEBRA C. DATA 230,00 IBM PROPRIA 5.808,00
427 RIGIDO VOICE COIL ROTATORIO
421 RIGIDO STEP M
F DISK SHUGART 900,00
F DISK SHUGART 250,00
MICROLAB AMPEX 1.100,00
23
2.5. MODELO DE DADOS FSICO
Usados para descrever os dados em seu nvel mais baixo. Capturam os
aspectos de implementao do SGBD.
3. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)
3.1. INTRODUO
Apresentado por Peter Chen, em 1976
a tcnica mais difundida para construir modelos conceituais de bases de
dados
o padro para modelagem conceitual, tendo sofrido diversas extenses
Est baseado na percepo de uma realidade constituda por um grupo bsico
de objetos chamados ENTIDADES e por RELACIONAMENTOS entre
estas entidades
Seu objetivo definir um modelo de alto nvel independente de implementao
O modelo representado graficamente por um Diagrama de Entidade-
Relacionamento (DER), que simples e fcil de ser entendido por usurios
no tcnicos
Conceitos centrais do MER: entidade, relacionamento, atributo,
generalizao/especializao, agregao (entidade associativa)
3.2. ENTIDADE
Conjunto de objetos da realidade modelada sobre os quais deseja-se manter
informaes no Banco de Dados
Uma entidade pode representar objetos concretos da realidade (pessoas,
automveis, material, nota fiscal) quanto objetos abstratos (departamentos,
disciplinas, cidades)
A entidade se refere a um conjunto de objetos; para se referir a um objeto em
particular usado o termo instncia (ou ocorrncia)
No DER, uma entidade representada atravs de um retngulo que contm o
nome da entidade
PESSOA
DEPARTAMENTO
24
3.3. RELACIONAMENTO
toda associao entre entidades, sobre a qual deseja-se manter informaes
no Banco de Dados.
Os relacionamentos representam fatos ou situaes da realidade, onde as
entidades interagem de alguma forma
Um dado por si s no faz uma informao, pois no tem sentido prprio;
necessrio que haja uma associao de dados para que a informao seja
obtida.
Exemplos:
Fornecimento: entre as entidades FORNECEDOR e MATERIAL
Matrcula: entre as entidades ALUNO e DISCIPLINA
Financiamento: entre as entidades PROJETO e AGENTE
FINANCEIRO
No DER, os relacionamentos so representados por losangos, ligados s
entidades que participam do relacionamento
Diagrama de ocorrncias de relacionamentos:
DEPARTAMENTO EMPREGADO
LOTAO
25
3.3.1. AUTO-RELACIONAMENTO
Relacionamento entre ocorrncias da mesma entidade.
Diagrama de ocorrncias no auto-relacionamento:
O papel da entidade no relacionamento indica a funo que uma
ocorrncia de uma entidade cumpre em uma ocorrncia de um relacionamento.
3.3.2. CARDINALIDADE DE RELACIONAMENTOS
A cardinalidade de uma entidade em um relacionamento expressa o
nmero de instncias da entidade que podem ser associadas a uma determinada
instncia da entidade relacionada.
Devem ser consideradas duas cardinalidades:
Cardinalidade mnima de uma entidade o nmero mnimo de instncias
da entidade associada que devem se relacionar com uma instncia da
entidade em questo.
Cardinalidade mxima de uma entidade o nmero mximo de
instncias da entidade associada que devem se relacionar com uma
instncia da entidade em questo.
marid
o
esposa
PESSOA
CASAMENTO
26
3.3.3. CARDINALIDADE MXIMA
No projeto para BD relacional (como neste curso) no necessrio
distinguir as cardinalidades que sejam maiores que 1. Assim, so usados
apenas as cardinalidades mximas 1 e n (muitos).
27
3.3.4. CLASSIFICAO DE RELACIONAMENTOS BINRIOS
A cardinalidade mxima usada para classificar os relacionamentos
binrios (aqueles que envolvem duas entidades).
a) Relacionamentos 1:1 (um-para-um)
Uma instncia da entidade A est associada com no mximo uma instncia
da entidade B.
Uma instncia da entidade B est associada com no mximo uma instncia
da entidade A.

A B
A1 B1
A2 B2
A3 B3
28
b) Relacionamentos 1:N (um-para-muitos)
. Uma instncia da entidade "A" esta associada a qualquer nmero de
instncias da entidade "B".
. Uma instncia da entidade "B", todavia, pose estar associada a no
mximo uma instncia da entidade "A"

A1 B1
A2 B2
B3
B4
29
c) Relacionamentos N:N (muitos-para-muitos)
Uma instncia da entidade "A" esta associada a qualquer nmero
instncias da entidades "B". Uma instncia da entidade "B" esta associada a
qualquer nmero de instncia da entidades "A"
A B
A1 B1
A2 B2
A3 B3
A4 B4
30
3.3.5. RELACIONAMENTO TERNRIO
o relacionamento formado pela associao de trs entidades
Cardinalidade em relacionamentos ternrios:
3.3.6. CARDINALIDADE MNIMA
A cardinalidade mnima usada para indicar o tipo de participao da
entidade em um relacionamento. Esta participao pode ser:
Parcial ou Opcional: quando uma ocorrncia da entidade pode ou no
participar de determinado relacionamento; indicado pela
cardinalidade mnima = 0 (zero).
Total ou Obrigatria: quando todas as ocorrncias de uma entidade
devem participar de determinado relacionamento; indicado pela
cardinalidade mnima > 0 (zero).
31
Exemplos:
Um cliente pode fazer pedidos ou no, mas todos os pedidos devem
estar associados a um cliente.
Todos os departamentos devem possuir pelo menos um empregado
alocado, e todos os empregados devem estar alocados em um departamento.
Parcialidade mnima: para um departamento ser criado, devem existem
pelo menos 10 empregados alocados.
3.4. NOTAES ALTERNATIVAS
Notao Santucci/MERISE: semntica participativa
Notao Setzer: semntica associativa
Notao Heuser: semntica associativa
1 N
CLIENTE
REALIZ
A
PEDIDO
1 N
DEPTO
ALOCA
EMPREGADO
10
1 N
DEPTO ALOCA EMPREGADO
(0,
N)
(1,
1)
DEPTO
ALOCA
EMPREGADO
1
N
DEPTO
ALOCA
EMPREGADO
(1 (0,N
DEPTO
ALOCA
EMPREGADO
32
3.5. ATRIBUTO
um dado que associado a cada ocorrncia de uma entidade ou
relacionamento.
Os atributos no possuem existncia prpria ou independente - esto sempre
associados a uma entidade ou relacionamento
Exemplos:
Funcionrio: Matrcula, Nome, Endereo
Material: Cdigo, Descrio
Financiamento: Valor total, Meses
Fornecedor: Nome, Endereo
3.5.1. DOMNIO
o conjunto de valores vlidos que um atributo pode assumir.
Ex: Estado civil: solteiro, casado, divorciado, vivo
3.5.2. TIPOS DE ATRIBUTOS
a) Opcional/Mandatrio
Opcional: o atributo pode possuir um valor nulo (vazio). Ex: nmero de
telefone
Mandatrio: o atributo deve possuir um valor vlido, no nulo. Ex:
nome do cliente
b) Monovalorado/Multivalorado
Monovalorado: o atributo assume um nico valor dentro do domnio.
Ex: data de nascimento
Multivalorado: o atributo pode assumir um nmero qualquer de valores
dentro do domnio. Ex: Telefone para contato
33
c) Atmico/Composto
Atmico: o atributo no pode ser decomposto em outros atributos. Ex:
Idade
Composto: o atributo composto por mais de um atributo. Ex: Endereo
3.5.3. ATRIBUTO DE RELACIONAMENTO
Assim como as entidades, os relacionamentos tambm podem possuir
atributos.
3.5.4. IDENTIFICADOR DE ENTIDADES
Conjunto de atributos que tem a propriedade de identificar univocamente cada
ocorrncia de uma entidade
Toda entidade deve possuir um identificador
O identificador deve ser mnimo, nico, monovalorado e mandatrio
34
3.5.5. RELACIONAMENTO IDENTIFICADOR (ENTIDADE FRACA)
Existem casos em que uma entidade no pode ser identificada apenas
com seus prprios atributos, mas necessita de atributos de outras entidades com
as quais se relaciona. Este relacionamento denominado Relacionamento
Identificador. Alguns autores denominam uma entidade nesta situao de
Entidade Fraca.
3.5.6. IDENTIFICADOR DE RELACIONAMENTOS
Uma ocorrncia de relacionamento diferencia-se das demais pelas
ocorrncias das entidades que participam do relacionamento. No exemplo
No exemplo, uma ocorrncia de ALOCAO identificada pela
ocorrncia de Engenheiro e pela ocorrncia de Projeto. Ou seja, para cada par
(engenheiro, projeto) h no mximo um relacionamento de alocao.
Em certos casos, ser necessrio o uso de atributos identificadores de
relacionamentos. Por exemplo:
Como o mesmo mdico pode consultar o mesmo paciente em diversas
ocasies, necessrio o uso de um atributo que diferencie uma consulta da
outra.
35
3.6. GENERALIZAO/ESPECIALIZAO
A generalizao um processo de abstrao em que vrios tipos de entidade
so agrupados em uma nica entidade genrica, que mantm as propriedades
comuns
A especializao o processo inverso, ou seja, novas entidades especializadas
so criadas, com atributos que acrescentam detalhes entidade genrica
existente
A entidade genrica denominada superclasse e as entidades especializadas
so as subclasses. A superclasse armazena os dados gerais de uma entidade,
as subclasses armazenam os dados particulares
Este conceito est associado idia de herana de propriedades. Isto significa
que as subclasses possuem, alm de seus prprios atributos, os atributos da
superclasse correspondente.
Usada quando necessrio caracterizar entidades com atributos prprios ou
participao em relacionamentos especficos
36
Uma generalizao/especializao pode ser total ou parcial:
total quando, para cada ocorrncia da entidade genrica, existe sempre
uma ocorrncia em uma das entidades especializadas.
parcial quando nem toda ocorrncia da entidade genrica possui uma
ocorrncia correspondente em uma entidade especializada.
37
3.7. ENTIDADE ASSOCIATIVA (AGREGAO)
O uso desta abstrao necessrio quando um relacionamento deve ser
representado como uma entidade no modelo conceitual. Isto ocorre quando
necessrio estabelecer um relacionamento entre uma entidade e um
relacionamento.
Para atender a esta situao foi criado o conceito de Entidade Associativa ou
Agregao. A agregao simplesmente um relacionamento que passa a ser
tratado como entidade.
Considerando o exemplo
Se for necessrio adicionar a informao que, a cada consulta um ou
mais medicamentos podem ser prescritos ao paciente, ser necessrio criar uma
nova entidade (MEDICAMENTO). Esta entidade deve se relacionar com as
consultas, mas CONSULTA um relacionamento. Deve ser criada ento uma
entidade associativa.
38
Outra forma alternativa de se representar a entidade associativa
3.8. RELACIONAMENTO MUTUAMENTE EXCLUSIVO
Neste tipo de relacionamento uma ocorrncia de um entidade pode estar
associada com ocorrncias de outras entidades, mas no simultaneamente.
AVIO
PASSAGEIRO
CARGA
TRANSPORTE
TRANSPOR
TE
39
4. O MODELO RELACIONAL
Foi introduzido pelo pesquisador da IBM Edward F. Codd, 1970.
Duas caractersticas marcantes, razes de sucesso :
. estrutura de dados simples e uniforme
. fundamentao terica slida
o modelo que opera com os dados organizados como um conjunto de
relaes.
O modelo de dados Relacional representa o banco de dados com uma coleo
de tabelas
Representao tabular :
Toda relao pode ser vista como uma tabela, onde cada linha uma tupla e em
cada coluna esto valores de um mesmo domnio.
Exemplo :
FORNECIMENTO
FORNECEDOR PEA PROJETO QUANTIDADE
1 2 5 18
2 3 7 25
4 1 1 4
Relao = tabela
Tupla = linha
Atributo = coluna
40
4.1. CARACTERSTICAS DAS TABELAS - MODELO RELACIONAL
a) Cada Tabela tem um nome nico atravs do qual ela referenciada.
b) Cada Tabela contm um nmero fixo de colunas(grau tabela).
c) No existem linhas iguais.
d) A ordem das linhas irrelevante(identificao no feita pela
localizao, mas sim pelo valor da chave primria).
e) Cada coluna tem um nome nico(diferente das demais colunas).
f) A ordem das colunas irrelevante(a coluna identificada pelo seu nome).
g) Cada coluna contm valores atmicos(no so permitidos grupos de
valores).
h) Cada valor de coluna extraido de um determinado DOMNIO(conjunto
de valores possveis).
i) Duas ou mais colunas podem ser definidas sobre um mesmo Domnio.
j) Operaes sobre colunas diferentes exigem que as colunas pertenam ao
mesmo Domnio,
k) Conexes entre Tabelas somente sero expressas atravs de valores das
colunas(Chave Estrangeira).
41
4.2. CONCEITOS BSICOS
4.2.1. CHAVE PRIMRIA : (PRIMARY KEY)
um atributo(coluna) ou uma combinao de atributos cujos valores
distinguem uma linha das demais dentro de uma tabela.
NUMFUNC NOMEFUNC CPFFUNC DEPTOFUNC
Chave primria
4.2.2. CHAVE ESTRANGEIRA : (FOREIGN KEY)
um atributo ou uma combinao de atributos, cujos valores aparecem
necessariamente na chave primria de uma tabela.
A chave estrangeira o mecanismo que permite a implementao de
relacionamentos(navegabilidade) em um banco de dados relacional.
Chave primria Chave estrangeira
DEPTO NOMEDPTO
Chave primria
4.2.3. CHAVE CANDIDATA OU ALTERNATIVA
Em alguns casos, mais de um atributo ou combinaes de atributos podem
servir para distinguir uma linha das demais. Um dos atributos (ou combinao
de atributos) escolhido como chave primria, os demais atributos (ou
combinaes) so denominados chaves CANDIDATAS
Chave primria Chave candidata Chave estrangeira
42
4.3. NORMALIZAO
O que ?
o processo formal de exame e agrupamento de dados numa forma capaz
de suportar melhor as mudanas futuras, minimizando o impacto destas
mudanas sobre a base de dados.
Segundo Edward F. Codd , normalizao um processo sistemtico e
reversvel, que consiste em substituir um determinado conjunto de relaes por
sucessivos conjuntos nos quais as relaes tenham uma estrutura mais simples
e regular.
Principais objetivos :
Reduzir as redundncias
Reduzir a necessidade de reestruturar as relaes quando novos tipos de
dados so introduzidos
Escopo :
A partir deste processo pode-se, gradativamente, substituir um conjunto
de entidades e relacionamentos por um outro, o qual se apresenta purificado
em relao as anomalias de (incluso, alterao, excluso)
Concluso :
Durante a Modelagem Conceitual poderemos estar trabalhando sobre
estruturas no normalizadas, pois o objetivo deste modelo com a
representao semntica da realidade da empresa em primeiro lugar.
Nossa proposta que seja feita uma reviso a nvel de transposio do
DER para o DTR, verificando as regras de normalizao antes da transposio
entre os modelos Conceitual e Lgico da realidade modelada.
43
4.3.1. ILUSTRAO DE UM SISTEMA A SER NORMALIZADO
PEDIDO(Num-Ped, Data-Ped, Num-Cli, Nome-Cli, End-Cli
((Cod-Prod, Nome-Prod, Qtde-Ped,Preo-Prod, Total-Prod)), Total-Ped)
( ) Dentro dos parenteses esto os tens de dados que constituem o
Pedido
(( )) Os parenteses duplos envolvem os atributos do item da tupla do
Pedido. Esses (( )) so utilizados para indicar que mais do que um Pedido de
linha pode compor um Pedido:
O tem de linha do Pedido chamado de GRUPO DE REPETIO
Produtos Num
-Ped
Data-
Ped
Num
-Cli
Nome
-Cli
End-Cli
Cod-
Prod
Nome-
Prod
Qtde-
Ped
Preo-
Prod
Total-
prod
Total
-Ped
100 1/3/99 100 Joo Rua A, 19 10
20
30
Banana
Maa
Laranja
10
15
20
0,10
1,00
0,20
1,00
15,00
4,00
20,00
200 2/4/99 100 Joo Rua A, 19 20
40
Maa
Mamo
20
10
1,00
0,50
20,00
5,00
25,00
300 3/5/99 200 Jlio Rua B, 19 10
50
Banana
Pra
20
10
0,10
0,50
2,00
5,00
7,00
400 4/7/99 300 Carlos Rua C, 20 10 Banana 10 0,10 1,00 1,00
44
Nesta Estrutura
O que acontece se:
- O Cliente mudar o endereo
Estes problemas ocorrem na vida real
Devemos analisar tambm a redundncia, um mesmo Cliente cada
vez que fizer um pedido vamos guardar (nome-cli, end-cli).
Anomalias de armazenamento.
1 Incluso :
S possvel incluir um novo Cliente a partir de um pedido.
Se nosso sistema fosse, nica e exclusivamente baseado na tabela
apresentada at o momento, no poderamos cadastrar um novo Cliente em
nossa tabela, a menos que surgisse um pedido para ele.
2 Excluso :
Se houver a excluso do Pedido nmero 400, toda a informao do
Cliente Carlos ser perdida.
Neste caso, podemos perceber que o fato de um pedido conter, em sua
estrutura, os dados do Cliente, vinculados diretamente a sua existncia, pode
nos levar simplesmente, perder esses dados quando um pedido for excludo.
3 Alterao :
Se algum dado do Cliente 100 mudar, teremos que efetuar esta operao
em vrias linhas da tabela.
Neste caso ser necessrio processar a alterao em cada uma das linhas
de cada um dos pedidos pertencentes a esse cliente
45
Um analista experiente, intuitivamente separaria os vrios
atributos do Pedido em arquivos(TABELAS) distintos.
CLIENTE
PEDIDO
ITEM-PEDIDO
PRODUTO
A Normalizao realiza formalmente esta separao dos atributos
em registros normalizados(CLIENTE, PEDIDO, ITEM-PEDIDO, PRODUTO)
baseado na Dependncia existente entre cada atributo e sua chave primria.
Ela consegue essa separao de ENTIDADES baseada no na
intuio(como acontece com um analista de sistemas experiente), mas atravs
de uma metodologia formal, que no requer experincia anterior com
computadores.
46
4.3.2. ANLISE DE DEPENDNCIA FUNCIONAL
Tcnica de normalizao adotada em nosso curso.
Dependncia Funcional :
O atributo B funcionalmente dependente do atributo A se, em qualquer
instante, um valor em A determina, de modo nico, o valor correspondente em
B, na mesma relao.
Exemplo:
EMPREGADO
#Num-Emp
Nome-Emp
Vlr-Sal-Emp
O Nome-Emp funcionalmente dependente do Num-Emp, pelo fato de cada
Num-Emp est associado sempre ao mesmo Nome-Emp.
Para denotar esta dependncia funcional, usa-se uma expresso na forma
Num-Emp Nome-Emp. A expresso denota que a coluna Nome-Emp
depende funcionalmente da coluna Num-Emp. Diz-se que a coluna Num-Emp
o determinante da dependncia Funcional.
De forma geral, o determinante de uma dependncia funcional pode ser um
conjunto de colunas e no somente uma coluna como na definio acima.
47
Prope trs tipos de dependncias entre os atributos de uma tabela.
a) Dependncia Funcional Total:
Os atributos de uma tabela tem que depender da chave primria e somente da
chave primria.
Um atributo C totalmente funcionalmente dependente da chave primria
composta pelo atributos A e B , quando for funcionalmente dependente de A
e B e no dependente funcionalmente de qualquer parte da chave primria.
Exemplo :
ALOCAO
# Num-Emp
# Cod-Proj
Qtde-horas-trab
- A quantidade de horas trabalhadas num projeto no funcionalmente
dependente do cod-proj, porque no significa o total de horas do projeto e
no funcionalmente dependente da matrcula do funcionrio, porque no
significa o total de horas trabalhadas pelo empregado.
- A quantidade de horas trabalhadas determinada, de modo nico, pela
composio da matrcula do empregado e do cdigo do projeto, porque
significa a quantidade de horas trabalhadas por empregado em um
determinado projeto.
b) Dependncia Funcional Parcial :
O atributo C parcialmente funcionalmente dependente da chave primria
composta pelos atributos A e B quando for funcionalmente dependente de
A ou B e no de ambos A e B

# Cod-mat
# Cod-forn
Nom-forn
Prc-mat
O atributo nom-forn funcionalmente dependente somente do atributo
cod-forn. O nome do fornecedor determinado, de modo nico pelo cdigo
do fornecedor, independente dos materiais que so fornecidos.
48
A dependncia funcional parcial ocorre quando a chave primria da
relao composta e se constitui numa anomalia que se deve ser evitada.
A soluo para o problema da dependncia parcial consiste na criao
de uma nova relao, que ser composta pelo atributo ou atributos que
dependem de parte da chave e a chave que determine, de modo nico estes
atributos

# Cod-mat
# Cod-forn
# Cod-forn
Nom-forn
Prc-mat
c) Dependncia Funcional Transitiva
- O atributo C dependente funcional transitivo de A se C funcionalmente
dependente de B e B funcionalmente dependente de A, na mesma relao.

# Num-emp
DFT
D
D
Nom-emp
F
F
T
Data-adm-emp A B C
Cod-proj
DF
Data-term-proj
DF DF
- O atributo data-term-proj funcionalmente dependente do atributo
cod-proj, que por sua vez funcionalmente dependente do atributo Num-
emp. Ento data-term-proj dependente transitivo de Num-emp.
- A dependncia funcional transitiva constitui numa anomalia que deve ser
evitada.
- A soluo para o problema da D.F.T. consiste na criao de uma nova
relao que ser composta pelo atributo ou atributos que so dependentes
funcionais transitivos tendo como chave primria o atributo que determina a
transitividade.

# Num-emp
# Cod-proj
Nom-emp
Data-term-proj
Data-adm-emp
Cod-proj
49
Resultado da anlise da dependncia Funcional:
Uma relao estar normalizada segundo a anlise da dependncia funcional,
quando possuir uma nica chave primria, todos os atributos no chaves
forem totalmente funcionalmente dependentes da chave primria e
independentes entre si, ou seja, aps a eliminao da dependncia funcional
parcial e transitiva, caso exista.
50
4.3.3. FORMAS NORMAIS:
1
a
Forma Normal :
Uma relao estar na 1
a
FN se no houver atributo representando
agrupamento e nem atributo repetitivo(multivalorado).
2
a
Forma Normal :
a
FN, se e somente se, estiver na 1
a
FN e os seus
atributos no chaves forem dependentes funcionais completos da chave
primria.
3
a
Forma Normal :
a
FN, se e somente se, estiver na 2 FN e todos os
seus atributos no chaves forem dependentes no transitivos da chave primria.
4.3.4. ROTEIRO PRTICO PARA NORMALIZAO:
A)TRANSFORMAO DE RELAES NO NORMALIZADAS EM
RELAOES NA 1 FN.
- Escolher uma chave primria para a relao
- Separar da relao os atributos(ou grupos) repetitivos, transformando a
relao em outras duas relaes.
. Uma delas contendo o grupo repetitivo e que ter como chave a
combinao da chave primria da relao no normalizada e uma chave (ou +)
escolhida(s) entre os atributos repetitivos. (Regra Geral)
. Outra que permanece com a chave original e os atributos restantes.
- Transformar atributos COMPOSTOS em atributos ATMICOS
51
B)TRANSFORMAO DAS RELAES EM 1 FN PARA RELAES
NA 2 FN.
- Examinar as relaes com chave primria composta e verificar se todos os
atributos dependem funcionalmente de toda a chave ou apenas de parte dela.
- Os atributos que dependem de parte da chave, formam uma nova relao, cuja
chave primria a parte da chave da relao em 1 FN da qual dependem.
- Apenas os atributos que dependem totalmente da chave composta
permanecem na relao original.
C) TRANSFORMAO DAS RELAES EM 2 FN PARA RELAES
EM 3 FN.
- Examinar as dependncias funcionais entre todos os atributos das relaes em
2 FN.
- Aqueles atributos que dependem de outro atributo da relao, que no a sua
chave, vo constituir uma nova relao cuja chave o atributo do qual
dependem.
ATENO : Esta chave continua como atributo na tabela Base pois o
elo de ligao entre ambas.
52
4.3.5.EXEMPLO DE NORMALIZAO:
ENTIDADE
ATRIBUTO
PEDIDO
Num-Ped X
Data-Ped \
Num-Cli \
Nome-Cli \
End-Cli \
Cod-Prod ( \ )
Nome-Prod ( \ )
Qtde-Ped ( \ )
Preo-Prod ( \ )
Total-Prod ( \ )
Total-Ped \
53
1 FN liminar atributos multivalorados e atributos representam agrupamento
ENTIDADE
ATRIBUTO
PEDIDO ITEM PED
Num-ped X X
Data-Ped \
Num-Cli \
Nome-Cli \
Nome-log \
Numero-log \
Cidade-log \
Estado-log \
Cep-log \
Cod-Prod X
Nome-Prod \
Qtde-Ped \
Preo-Prod \
Total-Prod \
Total-Ped \
54
2 FN Eliminar D.F.P
ENTIDADE
ATRIBUTO
PEDIDO ITEM PED PRODUTO
Num-Ped X X
Data-Ped \
Num-Cli \
Nome-Cli \
Nome-Log \
Numero-Log \
Cidade-Log \
Estado-Log \
Cep-Log \
Cod-Log X X
Nome-Prod \
Qtde-Ped \
Preo-Prod \
Total-Prod \
Total-Ped \
55
3 FN Eliminar D.F.T
- Redundncia deve ser evitada. No devo guardar o que posso
calcular(Cuidado - carroa)
ENTIDADE
ATRIBUTO
PEDIDO ITEM PED PRODUTO CLIENTE
Num-Ped X X
Data-Ped \
Num-Cli \ X
Nome-Cli \
Nome-Log \
Numero-Log \
Cidade-Log \
Estado-Log \
Cep-Log \
Cod-Prod X X
Nome-Prod \
Qtde-Ped \
Preo-Prod \
Total-Prod
Total-Ped
56
4.4. TRANSPOSIO D.E.R PARA D.T.R (DIAGRAMA DE TABELAS
RELACIONAIS)
4.4.1. SIMBOLOGIA ADOTADA NO MODELO RELACIONAL
. James Martin
.
um opcional
um obrigatrio
vrios
N : N
1 : N
1 : 1
Bachman Notao de setas
57
4.4.2. ANLISE DA ENTIDADE NO D.E.R
Toda Entidade vai virar uma Tabela no D.T.R
4.4.3. ANLISE DE RELACIONAMENTO
As ligaes entre as tabelas assumem um papel importante, pois
atravs delas que so representados os relacionamentos do modelo relacional.
Regra Geral :
Toda vez que um relacionamento tiver atributo, este relacionamento
vai ser representado por uma Tabela
Representao do Relacionamento no D.T.R
. Relacionamento vira Tabela
. Relacionamento vai ser representado por uma Chave Estrangeira
4.4.3.1 Mapeamento Relacionamento 1 p/ 1
A) - As duas relaes possuem a mesma chave primria.
H uma forte razo para unir as duas relaes em uma s. Combinam-se
os atributos permanecendo uma nica chave primria.
PRODUTO
#COD-PROD
DESC-PROD
PRC-UNIT
ESTOQUE-PROD
#COD-PROD
QTDE-EST
DATA-ULT-MOV
PRODUTO
#COD-PROD
DESC-PROD
PRC-UNIT
QTDE-EST
DATA-ULT-MOV
58
B) - As duas relaes possuem diferentes chaves primrias
B.1) - Pelo menos uma das entidades possue participao total no
relacionamento. O atributo Num-emp foi transposto para a relao
departamento, com o objetivo de representar a restrio de que todo
departamento possui um gerente que empregado da empresa.
B.2) - Ambas entidades possuem participao parcial no relacionamento
Define-se uma terceira relao correspondendo ao relacionamento.
DEPTO CHEFIA EMPREGADO
DEPTO
#COD-DEPTO
NOME-DEPTO
NUM-EMP
1 1
EMPREGADO
#NUM-EMP
NOME-EMP
HOMEM MULHER CASAMENTO
HOMEM
#CPF-H
NOME-H
MULHER
#CPF-M
NOME-M
HOMEM
#CPF-H
NOME-H
CASAMENTO
#CPF-H
#CPF-M
DATA-CAS
MULHER
#CPF-M
NOME-M
1 1
59
4.4.3.2 Mapeamento Relacionamento 1 p/ N
A) - A entidade do lado 1 possui participao total no relacionamento.
A chave primria da relao do lado "um" parte integrante da relao do
lado muitos.
B) - A entidade do lado um possui participao parcial no
relacionamento. Define-se uma terceira relao correspondendo ao
relacionamento.
CLIENTE PEDIDO FAZ
CLIENTE
#COD-CLI
NOME-CLI
CGC-CLI
PEDIDO
#NRO-PED
DATA-PED
COD-CLI
1 N
HOMEM MULHER CASAMENTO
HOMEM
#CPF-H
NOME-H
MULHER
#CPF-M
NOME-M
HOMEM
#CPF-H
NOME-H
CASAMENTO
#CPF-H
#CPF-M
DATA-CAS
MULHER
#CPF-M
NOME-M
1 N
60
4.4.3.3 Mapeamento Relacionamento N p/ N
- Um relacionamento N:N sempre pode ser resolvido em dois relacionamentos
1:N. Uma relao de interseo dever ser implementada.
4.4.3.4 Mapeamento Relacionamento Mltiplo
FORNECEDOR MATERIAL FORNECIMENTO
PROJETO
N N
N
FORNECEDOR
#COD-FORN
NOME-FORN
FORNECIMENTO
#COD-FORN
#COD-MAT
#COD-PROJ
QTDE
MATERIAL
#COD-MAT
DESC-MAT
PROJETO
#COD-PROJ
NOME-PROJ
FORNECEDOR MATERIAL FORNECIMENTO
FORNECEDOR
#COD-FORN
NOME-FORN
FORNECIMENTO
#COD-FORN
#COD-MAT
QTDE
MATERIAL
#COD-MAT
DESC-MAT
N N
61
4.4.3.5 Mapeamento Agregao
MEDICO PACIENTE ATENDE
EXAME
SOLICITA
MEDICO
#COD-MED
NOME-MED
ATENDE
#COD-MED
#COD-PAC
DATA-CONS
PACIENTE
#COD-PAC
NOME-PAC
SOLICTA
#COD-MED
#COD-PAC
#COD-EXAME
RESULTADO-EX
EXAME
#COD-EXAME
DESC-EXAME
N N
N
N
62
4.4.3.6 Mapeamento Auto Relacionamento
DISCIPLINA
PRE-REQUISITO
DISCIPLINA
#COD-DISC
NOME-DISC
PRE-REQUISITO
#COD-DISC-P
#COD-DISC-S
DATA-PRE
N
N
63
4.4.3.7 Mapeamento Hierarquia de Classe
CLIENTE
TIPO
FISCAL
PESSOA
FSICA
PESSOA
JURDICA
COD-CLI
NOME-CLI
CPF CGC
64
a) Mapear em uma nica Relao
CLIENTE
# COD-CLI
NOME-CLI
CPF-CLI /CGC-CLI
b) Mapear nas Subclasses as relaes
PESSOA FSICA
# COD-CLI
NOME-CLI
CPF-CLI
PESSOA JURDICA
# COD-CLI
NOME-CLI
CGC-CLI
c) Mapear como Relaes distintas
CLIENTE
# COD-CLI
NOME-CLI
PESSOA FSICA
# COD-CLI
CPF-CLI
PESSOA JURDICA
# COD-CLI
CGC-CLI
65
4.5. RESTRIES DE INTEGRIDADE NO MODELO RELACIONAL
4.5.1. INTEGRIDADE LGICA
. Conjunto de regras que existem para o modelo de dados, assim como um
conjunto de regras de negcio, que regem a manipulao do BD, de forma a
no ferir nenhuma destas regras estabelecidas
4.5.2. INTEGRIDADE FSICA
. Conjunto de procedimentos operacionais que garantem a integridade do BD,
mesmo em situaes de falha de algum componente do ambiente onde o BD
manipulado
4.5.1- INTEGRIDADE LGICA
a) Restrio de Chave
Uma relao deve ter pelo menos uma chave
b) Restrio de Integridade de Entidade
Nenhum valor da chave primria de uma relao pode ser nula
c) Restrio de Integridade de Referncia
A chave estrangeira deve ter correspondncia com a chave primria em outra
tabela ou ser nula
d) Restrio de Integridade Semntica ou Regras do Negcio
So regras ditadas pelo negcio e no so mapeadas pelo M.E.R por se tratar
de condies especiais
EX: . Valor mnimo de depsito para abertura de uma conta R$10.000,00
. Conta corrente sem movimento a 180 dias ser encerrada.
Podem ser cumpridas e implementadas pelos SGBDs Relacionais, atravs do
mecanismo de Regras ou gatilhos (Triggers), hoje existentes no SQL
66
4.5.1.1 - INTEGRIDADE REFERENCIAL DE INSERO
1 - Respeitar as cardinalidades mnimas
2 - Antes de INSERIR uma nova linha em uma tabela que contem um valor de
chave estrangeira, necessrio que j exista uma linha em uma tabela com este
valor de chave primria.
Caso contrrio, a operao de INSERO deve ser rejeitada ou uma linha
com a chave primria dever ser inserida na respectiva tabela.
DEPARTAMENTO
NUM-
DEPTO
DESCRIO
100 R.H
200 COBRANA
300 INFORMTICA
FUNCIONRIO
NUM-
FUNC
NOME NUM-
DEPTO
9999 LUIZ 100
8888 VERA 300
9898 ALBERTO 200
4.5.1.2 - INTEGRIDADE REFERENCIAL DELEO
. Quando uma linha de uma tabela deletada ento:
a) Todas as ocorrncias de chave estrangeira desta chave primria tambm
devem ser deletadas (CASCATA)
b) Os valores de chave estrangeira devem ser atualizados para nulo(SET
NULL)
c) A operao de deleo pode ser rejeitada, se existir uma ocorrncia de chave
estrangeira da chave primria a ser deletada. (RESTRITA)
67
4.5.1.3 - INTEGRIDADE REFERENCIAL ATUALIZAO:
. Se uma chave primria atualizada, ento
a) Mudar para nulas todas as ocorrncias existentes de chave estrangeira como
antigo valor
b)Mudar todas as ocorrncias de chave estrangeira do antigo valor para o novo
valor
c)Rejeitar a atualizao
68
SISTEMAS DE BANCOS DE DADOS
FORMULRIOS PARA OS MODELOS CONCEITUAL E LGICO DE BANCO DE DADOS
Este texto visa apresentar os formulrios usados para documentao do projeto de
Banco de Dados.
Dentro do projeto pretende-se abordar duas fases bsicas:
- O Modelo Conceitual: um modelo de alto nvel, independente da implementao. O
principal objetivo desta fase uma produo de uma descrio formal dos dados levantados a
partir dos requisitos dos usurios. O modelo adotado o Modelo de Entidades e
Relacionamentos (MER), estendido com o conceito de abstrao de dados. Nesta fase
gerado um Diagrama de Entedidades e Relacionamentos (DER).
- O Modelo Lgico: um modelo implementvel, que seja processvel por determinada
classe de SGBD. O modelo adotado o Modelo Relacional. Nesta fase do projeto gerado um
Diagrama de Tabelas Relacionais (DTR), derivado do DER da fase anterior. Durante o projeto
lgico, devero ser levadas em considerao as necessidades de processamento, a
normalizao dos dados e as restries de integridade das tabelas.
A documentao do projeto de dados constar ento de 3 formulrios:
a) O Modelo Conceitual de Dados (Anexo 1), composto pelo Diagrama de Entidades e
Relacionamentos (DER) - entidades, relacionamentos, cardinalidade, participao das
entidades nos relacionamentos, abstraes de dados (agregao,
generalizao/especializao).
b) O Modelo Relacional (Anexo 2), composto pelo Diagrama de Tabelas Relacionais
(DTR), com a identificao das tabelas e das ligaes entre as mesmas.
c) A Descrio da Tabela (Anexo 3), sendo usado um formulrio para cada tabela,
composto pela descrio dos dados da tabela e as restries aplicveis. As restries para
garantir a integridade dos dados sero consideradas sob 3 aspectos:
- Integridade de chave:
Em cada tabela ser definida uma chave primria, com valores no-nulos.
- Restrio de existncia:
Devem ser analisadas as restries no caso de incluso de uma nova tupla
ou de alterao de uma tupla existente.
Deve ser mantida a integridade referencial, no caso de tabelas que
possuam chaves estrangeiras.
- Restrio de persistncia:
Devem ser analisadas as restries no caso de excluso de uma tupla, a
fim de ser mantida a integridade referencial.
3 situaes podem ser consideradas:
a) Remoo em CASCATA: propaga a remoo ocorrida em uma tabela
para as outras tabelas relacionadas atravs de uma chave estrangeira.
b) Bloqueio total (Regra Restrita): a remoo no permitida se a tupla
referenciada por outra tabela atravs de uma chave estrangeira; caso contrrio a
remoao permitida.
c) Nulificao (Regra SET NULL): a remoo de uma tupla que
referenciada por outra tabela, atravs de uma chave estrangeira, implica em
atribuir valores nulos para estas chaves estrangeiras.
69
Anexo 1
Modelo de Dados Nome Sistema Data
CES Diagrama de Entidades e Relacionamentos - DER
70
Anexo 2
CES Diagrama de Tabelas Relacionais - DTR
71
Anexo 3
CES Descrio de Tabela- DT
Nome da
Tabela
Cdigo da
Tabela
Descrio Sumria da Tabela
Composio da Tabela
Nome do Elemento de Dado Tipo Cdigos para o Tipo de Elemento de Dado:
CP - Chave Primria
CS - Chave Secundria
PO - Preenchimento Obrigatrio
CE - Chave Estrangeira
Restries de Integridade da Tabela
Cdigo da
Tabela
Cdigo do Restries em relao Tabela Relacionada
Relacionada Relacionamento
XX YY Incluso:
Alterao:
Excluso:
72
Exerccio Padro Seo Eleitoral
EXERCCIO - UMA SEO ELEITORAL
A narrativa a seguir descreve o funcionamento de uma seo eleitoral durante uma eleio:
Um eleitor fornece a sua identificao e esta validada. Se for um eleitor vlido ele recebe
autorizao para votar. Um eleitor vlido aquele cadastrado na seo, identificado pelo nmero de seu
Ttulo de elitor (Num_Tit_Ele). Para cada eleitor existem informaes armazenadas: nome (Nome_Ele),
Data de nascimento (Data_Nasc_Ele), Endereo(End_Ele), Zona Eleitoral(Num_Zona_Ele) e Seo
Eleitoral(Num-Seo_Ele).
Os votos recebidos so armazenados, sendo gerado um comprovante de votao, entregue ao
eleitor. O voto uma associao entre um eleitor com os candidatos. Cada voto tem uma data (Data_Vot)
associada e vlido quando o candidato citado vlido. Os candidatos so identificados atravs de sua
inscrio na Justia Eleitoral (Num_Insc_Cand), alm de seu nome (Nome_Cand) e partido ao qual se
filia (Partido_Cand).
Se o eleitor no comparecer seo para votar, ele pode justificar-se, enviando um documento
Justia Eleitoral. Se a justificativa aceita, ela registrada, sendo gerado um comprovante de
justificativa, enviado ao eleitor. As justificativas so registradas atravs de um nmero de identificao,
alm de informaes sobre o eleitor e do local de origem. Existem eleitores que no comparecem
votao e que, ainda assim, no justificam sua absteno.
Baseie-se na narrativa apresentada para fazer:
a) Um diagrama de fluxo de dados - DFD;
b) Um diagrama de entidades e relacionamentos - DER;
c) Transponha o DER para o Modelo Relacional, usando as Regras de Mapeamento.
73
Diagrama de Fluxo de dados
1
VALIDAR
ELEITOR
ELEITOR
3
GERAR
CONFIRMAO
VOTO
4
VALIADAR
JUSTIFICATIVA
5
REGISTRAR
JUSTIFICATIVA
2
REGISTRAR
VOTO
6
GERAR
CONFIRMAP
JUSTIFICATIVA
ELEITORES
ELEITORES
JUSTIFICATIVAS
VOTOS
CANDIDATOS
ELEITOR
ELEITOR NO
AUTORIZADO
AUTORIZAO
IDENTIFICAO
ELEITOR
VOTO
CONFIRMAO
VOTO
COMPROVANTE
VOTO
JUSTIFICATIVA
JUSTIFICATIVA
NAO ACEITA
JUSTIFICATIVA
ACEITA
CONFIRMAO
JUSTIFICATIVA
COMPROVANTE
JUSTIFICATIVA
74
Diagrama de Entidade e Relacionamento
ELEITOR JUSTIFICATIVA FAZ
VOTA
CANDIDATO
1 1
N
N
75
Diagrama de Tabelas Relacionais
T1-ELEITOR
T3-CANDIDATO
T2-VOTA
T4-JUSTIF
R1
R2
R3
76
CES Descrio de Tabela- DT Eleio MMM/AA
Nome da
Tabela
Eleitor Cdigo da
Tabela
T1
Cadastro dos eleitores vlidos
Composio da Tabela
Num-Tit-Ele CP,PO CP - Chave Primria
Nome-Ele PO CS - Chave Secundria
Data-Nasc-Ele PO PO - Preenchimento Obrigatrio
End-Ele PO CE - Chave Estrangeira
Num-Zona-Ele PO
Num-Seo-Ele PO
Cdigo da
Tabela
Cdigo do Restries em relao Tabela Relacionada [ I - Incluso A - Alterao
E - Excluso]
T2 R2 I : Sem restries
A : No permitida a alterao da CP
E : Restrita
E : Restrita
77
Nome da
Tabela
Voto Cdigo da
Tabela
T2
Votos realizados pelos eleitores
Composio da Tabela
Num-Tit-Ele CP,CE,PO CP - Chave Primria
Num-Insc-Cand CP,CE,PO CS - Chave Secundria
Data-Voto PO PO - Preenchimento Obrigatrio
Cdigo da
Tabela
Cdigo do Restries em relao Tabela Relacionada [ I - Incluso A -
Alterao E - Excluso]
T1 R2 I : O eleitor deve estar cadastrado e no deve possuir nenhuma
justificativa
A : No permitida a alterao das CP
E : Sem restries
T3 R3 I : O candidato deve estar cadastrado
A : No permitida a alterao das CP
E : Sem restries
78
Nome da
Tabela
Candidato Cdigo da
Tabela
T3
Candidatos cadastrados para a eleio
Composio da Tabela
Num-Insc-Cand CP,PO CP - Chave Primria
Nome-Cand PO CS - Chave Secundria
Partido-Cand PO PO - Preenchimento Obrigatrio
Cdigo da
Tabela
Alterao E Excluso]
E : Restrita
79
Nome da
Tabela
Justif Cdigo da
Tabela
T4
Justificativas apresentadas pelos eleitores ausentes eleio
Composio da Tabela
Num-Justif CP,PO CP - Chave Primria
Local-Justif PO CS - Chave Secundria
Data-Justif PO PO - Preenchimento Obrigatrio
Motivo-Justif PO CE - Chave Estrangeira
Num-Tit-Ele CE,PO
Cdigo da
Tabela
Alterao E - Excluso]
T1 R1 I : O eleitor deve estar cadastrado e no deve possuir nenhum voto
A : No permitida a alterao das chaves CP ou CE
E : Sem restries
80
4.6.LINGUAGENS RELACIONAIS
- FORMAIS LGEBRA
CLCULO TUPLAS
DOMNIO
-
- COMERCIAIS SQL
QUEL (Linguagem Consulta) INGRES (1976)
QBE (Query by Example) IBM (1975)
HISTRICO
. 1970: Edward F. Codd
Artigo Modelo Relacional de Dados para grandes BD compartilhados
1 prottipo de um SGBD relacional. SYSTEM/R
. 1974/1975 : Criada a Linguagem SEQUEL
. 1975: QBE(Qurey by Example) - IBM
. 1976/1977: Verso SEQUEL/2 (alterado SQL)
. 1976: Criada a Linguagem QUEL - INGRES
. 1978/1979: ORACLE (Oracle Corporation)
. 1981: Diversos fabricantes lanam produtos baseados no SQL
. 1982: Criao comit na ANSI para proposta padro
. 1983: DB2 (IBM)
. 1986: O padro ANSI SQL utilizado SQL 1
. 1988: DB2 verso 2 (IBM)
SQL 1: Padro original no havia clusula para especificar chave; modificado
em 1989
SQL 2: aprovado em 1992: implementa conexo cliente/servidor
SQL 3: em fase de aprovao; implementa o Modelo Orientado a Objeto
81
4.6.1 - LGEBRA RELACIONAL
Matemticamente falando, uma tabela (relao) um conjunto , um conjunto
de linhas.
No modelo relacional temos o B.D. representado como uma coleo de tabelas,
quando queremos manipular ( recuperar ) dados em geral o resultado nos
apresentado como uma tabela, derivada de alguma forma de outras tabelas.
A lgebra relacional um conjunto de operaes e relaes.
4.6.1.1 - Operaes tradicionais
- union
- intersection
- diference
- cartesian
4.6.1.2- Operaes especiais
- project
- select
- join
- divide
82
4.6.1 - LGEBRA RELACIONAL
Operadores SQL possuem equivalentes diretos em lgebra
Um S.G.B.D. para ser considerado completamente relacional tem que suportar:
- B.D.R. ( conceito domnio, chave, ...)
- Uma linguagem que seja pelo menos to potente quanto a lgebra.
4.6.1.1 - Operaes Tradicionais
. UNION
R1 union R2 giving R3
R1 COD NOME CIDADE R2 COD NOME CIDADE R3 COD NOME CIDADE
S1 JOAO RJ S1 JOAO RJ S1 JOAO RJ
S2 JOSE RJ S3 BETO SP S2 JOSE RJ
S3 BETO SP
. INTERSECTION
R1 intersection R2 giving R4

R4 COD NOME CIDADE
S1 JOAO RJ
. DIFERENCE
R1 diference R2 giving R5
R5 COD NOME CIDADE
S2 JOSE RJ
83
4.6.1.1 - Operaes Tradicionais
. CARTESIAN
R6 cartesian R7 giving R8

R6 A B R7 C D R8 A B C D
A1 B1 C1 D1 A1 B1 C1 D1
A2 B2 C2 D2 A1 B1 C2 D2
A2 B2 C1 D1
A2 B2 C2 D2
4.6.2.2- Operaes Especiais
. PROJECT
Project R1 over Cod giving R9
R1 COD NOME R9 COD
F1 JOSE F1
F2 JOAO F2
F3 MARIA F3
F4 PEDRO F4
. SELECT
Select R10 where salario > 5.000 giving R11

R10 COD DEPTO SALARIO R11 COD DEPTO SALARIO
F1 D1 1.000 F3 D1 6.000
F2 D2 4.000
F3 D1 6.000
84
4.6.2.2- Operaes Especiais
. DIVIDE
Divide R12 by R13 over Cod giving R14
R12 COD B R13 B R14 COD
A1 B1 B2 A3
A2 B1 B3 A7
A3 B2
A7 B2
A2 B3
A3 B3
A7 B3
JOIN NATURAL
O JOIN na verdade duplica a coluna que passada como argumento. (
Ns adotamos que no )
R15 A B C D R16 A E F R17 A B C D E F
S1 ZE 20 RJ S1 5 6 S1 ZE 20 RJ 5 6
S2 JO 10 SP S2 10 7 S2 JO 10 SP 10 7
S3 15 8
!
!
A
S1
S2
Join R15 and R16 over A giving R17
Estamos trabalhando com JUNO baseada em igualdade de valores
(EQUI-JOIN). Mas poderamos ter JUNO "maior que", JUNO "no
igual", etc...
Uma EQUI-JOIN com uma das colunas idnticas eliminadas chama-se
JOIN NATURAL.
85
4.7.SQL (STRUCTURED QUERY LANGUAGE)
Mais que uma linguagem de consulta, oferece funes para DEFINIO,
MANIPULAAO e CONTROLE dos dados de um Banco de dados.
DDL (Data Definition Language)
- CREATE : criao de novas estruturas
- ALTER : alterao de estruturas
- DROP : remoo de estruturas
DML (Data Manipulation Language)
- INSERT : Insero de registros
- DELETE : deleo de registros
- UPDATE : atualizao de registros
- SELECT : Seleo de registros
DCL (Data Control Language)
- GRANT : concesso de privilgios a tabelas e vises
- REVOKE : revogao de privilgios a tabelas e vises
Transaction Control
- COMMIT : efetiva uma alterao no banco de dados
- ROLLBACK : desfaz uma alterao antes de ser efetivada no banco
- SAVEPOINT : permite uma subdiviso lgica de uma transao longa
Restries de integridade usando
-.STORED PROCEDURES
-.TRIGGERS
86
Dicionrio de Dados (Catlogo)
. um BD de sistema, que pode ser consultado por meio de comandos
SELECT da SQL, contendo:
.informaes sobre as tabelas bsicas
.as vises
.os direitos de acesso
.as identificaes dos usurios, etc
. Sua forma exata uma caracterstica de cada sistema e no da SQL
4.7.1 - DDL (DATA DEFINITION LANGUAGE)
a)CREATE
a-1) CREATE TABLE nome_tabela
(nome_coluna tipo [(tamanho)] [restrio_coluna],
nome_coluna tipo [(tamanho)] [restrio_coluna],
[restrio_tabela] );
.restrio: um mecanismo pelo qual voc limita ou restringe o tipo de dado
que uma coluna pode armazenar.
.restrio_coluna: referencia somente uma coluna, aceitando todos os tipos de
restries.
[CONSTRAINT nome_restrio] tipo_restrio
.restrio_tabela: referencia uma ou mais colunas. S no aceita o tipo NOT
NULL.
[CONSTRAINT nome_restrio] tipo_restrio (coluna, ...)
Tipos de restries
[NOT] NULL :
Indica se a coluna pode ou no receber valores nulos. O default NULL
UNIQUE :
Indica que a coluna ou combinao de colunas no pode ter valores
repetidos.
87
PRIMARY KEY :
Indica que a coluna ou combinao de colunas forma a chave primria.
Chave Estrangeira
REFERENCES nome_tabela_pai(nome_coluna_pai)
[ON DELETE CASCADE]
Usada a nvel de coluna, indica que a coluna uma chave estrangeira.
FOREIGN KEY(nome_coluna_filho)
REFERENCES nome_tabela_pai(nome_coluna_pai)
[ON DELETE CASCADE]
Usada a nvel de tabela, indica que a coluna ou combinao de colunas
uma chave estrangeira.
ON DELETE CASCADE
Indica quando uma linha na tabela_pai deletada haver uma deleo das
linhas correspondentes (chave estrangeira) na tabela_filho.
Obs : O default na ausncia da clausula ON DELETE CASCADE
RESTRICT.
. .E Ex xi is st t e e a ai i n nd da a o op p o o n no o p pa ad dr r o o S SQ QL L/ /2 2 O ON N D DE EL LE ET TE E S SE ET T N NU UL LL L e e
O ON N U UP PD DA AT TE E C CA AS SC CA AD DE E. .
CHECK
No permite que valores que violem a condio estabelecida sejam gravados na
coluna.
Tipos de dados permitidos
CHAR(n): Tipo de dado caracter de tamanho fixo.
VARCHAR(n): Tipo de dado caracter de tamanho varivel, sendo sempre
definido seu tamanho mximo(n).
NUMBER(n): Tipo numrico.
NUMBER(p,q): Tipo numrico de ponto decimal (p : posies sendo q: casas
decimais).
DATE: Tipo data
88
Exemplos
a) Restries a nvel de Tabela
CREATE TABLE depto (
num_depto NUMBER(2),
nome_depto VARCHAR(15),
local_depto VARCHAR(15),
CONSTRAINT depto_PK
PRIMARY KEY (num_depto),
CONSTRAINT depto_nome_depto_UK
UNIQUE (nome_depto)
);
CREATE TABLE emp (
num_emp NUMBER(6),
nome_emp VARCHAR(30),
salario_emp NUMBER(7,2),
sexo_emp CHAR(1),
cargo_emp VARCHAR(30),
num_depto NUMBER(7) NOT NULL,
CONSTRAINT emp_PK
PRIMARY KEY (num_emp),
CONSTRAINT sexo_emp_CK
CHECK (sexo_emp in (M, F)),
CONSTRAINT emp_num_depto_FK
FOREIGN KEY (num_depto)
REFERENCES depto (num_depto)
ON DELETE CASCADE
);
89
b) Restries a nvel de coluna
CREATE TABLE depto (
num_depto NUMBER(2) PRIMARY KEY,
nome_depto VARCHAR(15) UNIQUE KEY,
local_depto VARCHAR(15)
);
CREATE TABLE emp (
num_emp NUMBER(6) PRIMARY KEY,
nome_emp VARCHAR(30),
salario_emp NUMBER(7,2),
sexo_emp CHAR(1) CHECK ( sexo_emp in (M, F)),
cargo_emp VARCHAR(30),
num_depto NUMBER(7) NOT NULL REFERENCES
depto(num_depto) ON DELETE CASCADE
);
90
a-2) CREATE [UNIQUE] INDEX nome_ndice
ON nome_tabela (nome_coluna1, nome_coluna2, ...);
Sugestes criao ndices:
. Colunas usadas frequentemente na clusula WHERE
. FOREIGN KEYS pois esto geralmente envolvidas em JOINS
. PRIMARY KEYS e UNIKE KEYS (normalmente o Sistema cria
automaticamente um UNIQUE INDEX).
Exemplo:
CREATE INDEX emp_nome_emp_idx
ON emp (nome_emp);
Observaes:
1 ndices no podem ser alterados; devem ser removidos (com DROP) e
recriados
2 A deciso de se usar ou no um ndice em resposta a uma solicitao
especfica de dado no tomada pelo usurio mas sim pelo sistema
91
b)ALTER
Comando usado para alterar a estrutura de uma tabela:
. adicionando ou alterando colunas.
. inserindo ou removendo restries
b.1) Adicionando ou modificando colunas de uma tabela
ALTER TABLE nome_tabela
[ ADD (nome_coluna tipo[(tamanho)],...)]
[ MODIFY (nome_coluna tipo[(tamanho)],...)]
Exemplo:
ALTER TABLE emp
ADD (data_nasc_emp date);
ALTER TABLE emp
MODIFY (nome_emp(60) NOT NULL);
b.2) Adicionando ou removendo uma restrio de uma tabela
[ ADD restrio_tabela]
[ DROP PRIMARY KEY | UNIQUE (nome_coluna) |
CONSTRAINT nome_restrio [CASCADE] ];
Exemplo:
ALTER TABLE depto
ADD CONSTRAINT depto_local_depto_UK
UNIQUE (local_depto);
ALTER TABLE depto
DROP PRIMARY KEY CASCADE;
Neste exemplo o comando remove a restrio PRIMARY KEY na tabela
Depto e remove a restrio FOREIGN KEY associada na tabela Emp.
Obs : Aqui estamos removendo apenas as constraints associadas as
tabelas e no os registros de fato.
92
b.3) Habilitando e desabilitando uma restrio em uma tabela
ENABLE | DISABLE nome_restrio [CASCADE];
Exemplo :
ALTER TABLE depto
ENABLE CONTRAINT depto_local_depto_uk;
c)DROP
Para excluir uma tabela ou ndice
c.1) Excluir uma tabela, onde os ndices tambm so excludos
DROP TABLE nome_tabela [CASCADE CONSTRAINTS];
Exemplo:
DROP TABLE emp;
DROP TABLE depto CASCADE CONSTRAINTS;
Neste exemplo o comando exclui a tabela depto e remove todas as
restries FOREIGN KEY que fazem referncia a PRIMARY KEY desta
tabela.
Obs : Aqui CASCADE CONSTRAINTS desfaz apenas as restries
associadas chave primria e no excluiu os registros associados pelas chaves
estrangeiras.
c.2) Exclui um ndice
DROP INDEX nome_indice
Exemplo :
DROP INDEX emp_nome_emp_idx
93
4.7.2.-DML (DATA MANIPULATION LANGUAGE)
a) INSERT
a-1) Adicionar novas linhas em uma tabela
INSERT INTO nome_tabela [(nome_coluna1 [,nome_coluna2 ...] )]
VALUES ( valor1 [, valor2 ...]);
Exemplo:
INSERT INTO depto
VALUES (100, INFORMATICA, JUIZ DE FORA);
INSERT INTO emp (Num_Emp, Nome_Emp, Sexo, Num_Depto)
VALUES (1313, TEREZA CRISTINA, F, 100);
a-2) Copiando linhas de uma outra tabela:
INSERT INTO nome_tabela [(nome_coluna1 [, nome_coluna2...])]
Subquery;
Exemplo:
CREATE TABLE gerente
num_emp NUMBER(6) PRIMARY KEY,
nome_emp VARCHAR(30);
INSERT INTO gerente
Select num_emp, nome_emp
From emp
Where cargo_emp = GERENTE;
94
b)DELETE
DELETE FROM nome_tabela
[WHERE condio] ;
Exemplo:
DELETE FROM depto
WHERE local_depto = JUIZ DE FORA;
DELETE FROM depto;
Deleta todas as linhas da tabela se for omitida WHERE
95
c)UPDATE
c.1) Atualizar linhas de uma tabela
UPDATE nome_tabela
SET nome_coluna = valor [, nome_coluna = valor]
[WHERE condio];
Exemplo
UPDATE emp
SET nome_emp = JAIR BATISTA , sexo_emp = M
WHERE num_emp = 1313;
Obs : Todas as linhas de uma tabela so atualizadas se voc omitir a clusula
WHERE.
c.2) Atualizar linhas a partir de uma Subquery
UPDATE nome_tabela
SET (nome_coluna, nome_coluna ...) =
(SELECT nome_coluna, nome_coluna, ...
FROM nome_tabela
WHERE condio);
Exemplo:
UPDATE emp
SET (cargo_emp, num_depto) =
(SELECT cargo_emp, num_depto
FROM emp
WHERE num_emp = 1313)
WHERE num_emp = 1320;
96
d)SELECT
Comando usado para fazer consultas as bases de dados
d.1) Forma Bsica:
SELECT [DISTINCT] nome_coluna [,nome_coluna...] FROM nome_tabela
Seleo de colunas especficas : Basta relacionar as colunas desejadas
Exemplo:
SELECT num_emp, nome_emp
FROM emp;
Seleo de todas as colunas : Substituir os nome das colunas por *
Exemplo:
SELECT *
FROM emp;
Evitando duplicaes: Usar a palavra DISTINCT na clusula SELECT
Exemplo:
SELECT DISTINCT nome_emp, cargo_emp
FROM emp;
Usando Pseudnimos: Uma consulta SQL normalmente usa o nome da coluna
como cabealho; possvel definir um pseudnimo para a coluna que
aparecera no cabealho
Exemplo:
SELECT num_emp Numero do Empregado
FROM emp;
97
d.2) Uso clusula WHERE
Usada para filtrar um subconjunto de linhas de uma tabela
SELECT nome_colunas
FROM nome_tabela
[WHERE condio]
Operadores:
= igual a
< > diferente de
> maior que
< menor que
Between ... and... entre dois valores
In(lista) qualquer valor da lista
Like corresponde a um gabarito
% : corresponde a uma seqncia de zero ou mais caracteres
- : corresponde a um caracter
IS NULL valor nulo
Obs : Os quatro ltimos podem ser negados atravs do operador NOT:
. NOT BETWEEN, NOT IN , NOT LIKE, IS NOT NULL
Conjuno de Condies: vrias condies podem ser conectadas na clusula
WHERE usando o operador AND
Exemplo:
WHERE nome_cargo = GERENTE AND num_depto > 1000;
Disjuno de Condies : usando operador OR
Exemplo:
WHERE num_depto = 1313 OR local_depto LIKE _J %;
Obs: _ :primeira posio, J: segunda posio
98
d.3 ) Uso Clusula ORDER BY
Ordenando o resultado de uma consulta
SELECT nome_colunas
FROM nome_tabela
[WHERE condio]
[ORDER BY {nome_coluna, ...} [ASC|DESC]]
Exemplo:
ORDER BY nome_emp
d.4) Juno de Tabelas
As linhas de uma tabela podem ser combinadas(JOIN) s linhas de outra tabela
atravs de valores comuns em colunas correspondentes.
Exemplo:
SELECT emp_name, depto_name
FROM emp e, depto d
WHERE e.num_depto = d.num_depto;
d.5) Produto Cartesiano
Todas as linhas da primeira tabela so combinadas com todas as linhas da
segunda tabela.
Ocorre na omisso da clusula WHERE.
Exemplo:
Tabela EMP com 14 registros
Tabela DEPTO com 4 registros
SELECT nome_emp, nome_depto
FROM emp, depto;
99
d.6) Funes de Manipulao de Valores
Operadores aritmticos
+ soma
- subtrao
* multipllicao
/ diviso
Funes Numricas
SIGN(nmero) : -1 se negativo, 1 se positivo
MOD(dividendo, divisor) retorna o resto da diviso
ROUND (nmero, [n_casas]) retorna o numero arrendondado com n casas
TRUNC(nmero,[n_casas] retorna o nmero truncado com n casas
Funes Alfanumricas
CHR(nmero) retorna o caracter cujo cdigo ASCII seja igual ao nmero
Ex: CHAR(75) k
LOWER(string) retorna a string toda em letra minuscula
Ex: LOWER(EXEMPLO FUNC) exemplo func
UPPER(string) retorna a string toda em letra maiscula
Ex: UPPER(exemplo func) EXEMPLO FUNC
LENGH(sring) retorna o tamanho da string
Funes de Grupo
Retornam um valor para um grupo de linhas
SELECT funo_grupo(nome_coluna)
FROM nome_tabela
[WHERE condio]
[ORDER BY nome_coluna]
100
Obs: Se a clusula SELECT contiver funes de grupo, o resultado ser
somente uma linha. Assim na clusula SELECT no podem aparecer resultados
individuais junto com expresses que contenham funes de grupo. Neste caso
deveramos usar GROUP BY
Exemplo : SELECT nome-emp, AVG(salario_emp)
FROM emp WHERE num_depto = 30;
COUNT(* | [DISTINCT] nome_coluna) : Retorna a quantidade de linhas do
grupo
COUNT(*) : inclui linhas duplicatas e linhas que contenham valores NULL.
COUNT(nome_coluna) : retorna o nmero de linhas com valores NOT NULL
para a coluna(expresso) especificada.
COUNT(DISTINCT nome_coluna) : retorna o nmero de linhas com valores
distintos.
MAX([DISTINCT] expresso) : Retorna o valor mximo dessa expresso ou
coluna dentro do grupo
MIN([DISTINCT] expresso) : Retorna o valor mnimo dessa expresso ou
coluna dentro do grupo
SUM([DISTINCT] expresso) : Retorna o somatrio da expresso de todas as
linhas do grupo
AVG([DISTINCT] expresso) : Retorna a mdia aritmtica de todas as linhas.
Valores NULL so ignorados.
AVG(NVL(nome_coluna,0)) : considera como zero os NULL na mdia
aritmtica.
101
d.7) Uso da Clusula GROUP BY
Usada para dividir as linhas de uma tabela em grupos menores.
O SQL recupera cada grupo de linhas de acordo com os valores da(s)
expresso(es) especificada(s) na clusula GROUP BY.
SELECT nome_colunas , funo_de_grupo(nome_coluna)
FROM nome_tabela
[WHERE condio]
[GROUP BY exp1, exp2...]
A clusula GROUP BY dever vir sempre aps a clusula WHERE (ou aps a
clusula FROM quando no existir WHERE)
Quando a clusula GROUP BY utilizada possvel combinar resultados
individuais com funes de grupo na clusula SELECT.
Quando a clusula GROUP BY utilizada, possvel combinar resultados
individuais com funes de grupo na clusula SELECT, desde que aqueles
resultados individuais sejam usados no GROUP BY.
Exemplo
SELECT num_ depto, COUNT(nome_emp)
FROM emp
GROUP BY num_depto;
Observao:
Quando estiver usando o GROUP BY certifique-se que todas as colunas no
usadas na funo de grupo estejam includas na clausula GROUP BY
Usando a clusula WHERE voc pode selecionar linhas antes de agrupar.
Usando GROUP BY para mltiplas colunas:
SELECT num_depto, cargo_emp, SUM(salario_emp)
FROM emp
GROUP BY num_depto, cargo_emp;
102
d.8) Uso da Clusula GROUP BY com HAVING
A clusula WHERE no pode ser usada para restringir funes de grupo.
Exemplo:
SELECT num_depto, AVG(salario_emp)
FROM emp
WHERE AVG(salario_emp) > 2000
GROUP BY num_depto;
Os grupos definidos pela clusula GROUP BY podem ser filtrados pela
clusula HAVING.
Exemplo:
SELECT num_depto, AVG(salario_emp)
FROM emp
GROUP BY num_depto
HAVING AVG(salario_emp) > 2000
SELECT nome_colunas , funo_de_grupo(nome_coluna)
FROM nome_tabela
[WHERE condio]
[GROUP BY exp1, exp2...]
[HAVING funo_de_grupo(nome_coluna)]
[ORDER BY nome_coluna]
Exemplo
SELECT cargo_emp, SUM(salario_emp)
FROM emp
WHERE cargo_emp NOT LIKE GEREN%
GROUP BY cargo_emp
HAVING SUM(salario_emp) > 5000
ORDER BY SUM(salario_emp);
103
d.9) Uso de Subqueries
Subqueries
So comandos SELECT que so utilizados em condies de clusulas
WHERE ou HAVING para prover resultados que so utilizados para completar
a consulta principal.
Exemplo
SELECT nome_emp, cargo_emp
FROM emp
WHERE cargo_emp = ( SELECT cargo_emp
FROM emp
WHERE nome_emp = JONES);
Operadores ANY e ALL
Quando a subquery retornar mais de um valor, os operadores ANY e ALL
podem ser utilizados para compatibilizar o resultado da subquery com o tipo do
operador de comparao.
Exemplo
salario_emp > ANY <subquery>
Essa condio ser verdadeira quando salario_emp for maior que qualquer um
dos resultados da query.
salario_emp < ANY <subquery>
Essa condio ser verdadeira quando salario_emp for menor que qualquer um
dos resultados da query.
salario_emp > ALL <subquery>
Essa condio ser verdadeira quando salario_emp for maior que todos os
resultados da subquery.
salario_emp < ALL <subquery>
Essa condio ser verdadeira quando salario_emp for menor que todos os
resultados da subquery.
104
Exemplo
SELECT num_emp, nome_emp, cargo_emp
FROM emp
WHERE salario_emp < ANY (
SELECT salario_emp
FROM emp
WHERE cargo_emp = GERENTE);
Operadores IN e NOT IN
igual para qualquer membro da lista
... WHERE cargo_emp IN (
SELECT cargo_emp
FROM emp
WHERE nome_emp LIKE A%);
SELECT nome_emp, salario_emp
FROM emp
WHERE salario_emp IN (800, 950, 13000);
Operadores de Conjuntos
Como o resultado de um query um conjunto de linhas voc pode realizar
operaes de conjuntos entre queries:
UNION : Unio entre os resultados das queries;
INTERSECT : Interseo entre os resultados das queries;
MINUS : Subtrao entre os resultados das queries.
105
Exemplo
SELECT nome_emp, cargo_emp, salario_emp
FROM emp
WHERE salario_emp IN(
SELECT salario_emp
FROM emp
WHERE nome_emp = CARLOS
UNION
SELECT salario_emp
FROM emp
WHERE nome_emp = MARIO);
Operador EXIST e NOT EXIST
EXIST: retorna verdadeiro se uma determinada subquery retornar ao menos
uma linha e falso caso contrrio
NOT EXIST: retorna o resultado contrrio do EXIST.
106
d.10) Criao e Uso de Vises
OBJETIVO
Restringir acesso certas pores dos dados por questes de segurana. Pr definir
certas consultas definindo tabelas virtuais que podero ser utilizadas por outras
consultas.
VISO
Pode ser vista como uma tabela virtual, isto , uma tabela que realmente no existe
como tal, mas sim como derivao de uma ou + tabelas bsicas.
Uma definio da viso fica armazenada no dicionrio, esta definio mostra como
ela derivada das tabelas bsicas.
CRIAO
CREATE VIEW nome_viso [(nome_coluna [, nome_coluna..])]
AS <SELECT ...>
Obs : Na clusula AS a Subquerie no pode conter : ORDER BY
Exemplo
A) CREATE VIEW emp_visao
AS SELECT num_emp, nome_emp, cargo_emp
FROM emp WHERE cod_depto = 20;
B) Depois de criada uma viso, ela estar disponvel no Dicionrio de Dados;
at este ponto a instruo SELECT no foi executada.
SELECT * FROM emp_visao;
REMOO
DROP VIEW <nome viso>
A definio ser removida do Dicionrio de Dados.
107
4.7.3. DCL (DATA CONTROL LANGUAGE)
Responsvel pela segurana das informaes no Banco de dados
Informando ao SGBD, quais operaes que um usurio ter sobre uma
determinada tabela do BD
Quando um usurio cria seus objetos(tabelas, vises, procedures,...) diz-se que ele
o OWNER(dono) destes objetos.
O conjunto de todos os objetos que pertencem a determinado usurio chamado de
ESQUEMA deste usurio.
Para acessar os objetos de outro esquema( de outro usurio ) basta prefixar o nome
do objeto com o nome do usurio que o criou ( seu owner).
Exemplo
SELECT * FROM CARLOS.emp;
Voc pode evitar a repetio da prefixao de uma tabela de outro usurio criando
um sinnimo para ela:
CREATE SYNONYM emp1
FOR CARLOS.emp;
SELECT * FROM emp1;
a) Criao de objetos
a.1) Criao um usurio (CREATE USER)
CREATE USER user
IDENTIFIED BY password;
Exemplo:
CREATE USER carlos ALTER USER carlos
IDENTIFIED BY solrac; IDENTIFIED BY newsenha;
O DBA cria o usurio e concede privilgios ao usurio que determinam o que este
usurio pode fazer a nvel de Banco de dados
108
b) Concesso de privilgios (GRANT)
b.1) Concesso de privilgios de sistema
GRANT privilgio[, privilgio...]
TO usurio[, usurio..]
privilgios: . CREATE SESSION, CREATE TABLE, CREATE SEQUENCE,
CREATE VIEW, CREATE PROCEDURES.
Exemplo :
GRANT create table, create view
TO carlos;
b.2) Concesso de privilgios sob objetos
O OWNER tem todos os privilgios de um objeto.
GRANT <lista_privilgios>
ON objeto
TO {<lista de usurios> | grupo | PUBLIC }
[WITH GRANT OPTION];
109
lista_privilgios
SELECT
INSERT
UPDATE
DELETE
ALTER
INDEX
ALL
A opo WITH GRANT OPTION : permite que o usurio que est recebendo
o privilgio, possa dar GRANT neste objeto a outros usurios.
Exemplo
GRANT SELECT, INSERT
ON depto
TO julio, mario;
c) Revogao de privilgios
REVOKE <lista_privilgios>
ON objeto
FROM {<lista_usuarios> | grupo | PUBLIC };
OBS : Privilgios concedidos a outros com a opo WITH GRANT OPTION
tambm sero revogados.
Exemplo
REVOKE SELECT, INSERT
ON depto
FROM mario;
110
4.7.4 - TRANSACTION CONTROL
A linguagem SQL possui tambm comandos que permitem o controle do
resultado de uma transao.
Uma transao uma seqncia ATMICA de operaes no BD que constitui
a unidade lgica de trabalho dos SGBDs.
Exemplo
Transferencia de dinheiro entre duas contas.
Conta A = 1000 e Conta B = 2000 .
Consistncia Somatrio Contas A e B igual 3000.
Transao de Transferncia A B
Passo 1 da transao
Read(A,a)
a:= a-100
Write(A,a)
Passo 2 da transao
Read(B,b)
B:= b+100
Write(B,b)
Imagine o que aconteceria se o primeiro passo fosse executado com sucesso,
mas por algum motivo no fosse possvel completar o segundo passo. O
dinheiro da conta A haveria desaparecido e a consistncia do BD estaria
comprometida.
O esquema de transaes garante que isso no acontecer, pois enquanto o
COMMIT no for executado, as atualizaes no sero efetivadas. No caso de
uma falha, o primeiro passo seria desfeito.
111
a) COMMIT
Sempre que um comando COMMIT executado :
. A transao em andamento implicitamente terminada.
. As alteraes realizadas pelas transaes so tornadas permanentes e
irreversveis.
Os possveis bloqueios que a transao mantinha so liberados.
Apaga todos os savepoints.
b) ROLLBACK [to SAVEPOINT point_name]
Sempre que um comando ROLLBACK executado:
. Encerra a transao
. As alteraes realizadas pela transao em andamento so desfeitas
como se nunca tivessem ocorrido.
. Os possveis bloqueios que a transao mantinha so desfeitos.
. Apaga todos os SAVEPOINTs.
Se voc executar comando ROLLBACK TO SAVEPOINT :
. Desfaz todas as alteraes at o SavePoint especificado.
. Apaga todos os SavePoints criados aps o especificado e mantm os
demais.
c)SAVEPOINT point_name
Em muitas implementaes de SQL, existe o comando SAVEPOINT para
permitir a subdiviso lgica de transaes longas.
112
Exemplo
INSERT UPDATE INSERT DELETE
|<----------------------------------transao------------------------------------------- >|
. Commit . Savepoint A . Savepoint B
< --------------------
RollBack to Savepoint B
< ----------------------------------------------------------------------
RollBack to Savepoint A
< ---------------------------------------------------------------------------------------------
RollBack
Commit : Termina a corrente transao tornando permanentes as alteraes.
Savepoint : Marca um Savepoint na corrente transao
RoolBack : Termina a corrente transao descartando todas as alteraes no
efetivadas.
RollBack to Savepoint name : descarta as alteraes no efetivadas at o
savepoint indicado
113
4.7.5 RESTRIES DE INTEGRIDADE USANDO STORED PROCEDURES E
TRIGGERS
. Conforme foi mostrado anteriormente as restries de integridade so
especificadas de forma declarativa no momento da definio dos dados
(CREATE) ou depois (ALTER). SQL/92.
.Uma outra forma de especificar restries de integridade a forma
procedimental, atravs de TRIGGERS e STORED PROCEDURES.
. A maioria dos SGBDs relacionais de ponta disponveis no mercado suporta
este tipo de regras ativas mas infelizmente a SQL/92 no previu a sua
padronizao.
4.7.5.1 - STORED PROCEDURES
114
.Quando uma aplicao solicita a execuo de uma QUERY, todo o texto da
mesma enviado pela rede ao servidor onde ser finalmente compilado e
executado.
. Stored Procedures so na verdade uma seqncia de comandos SQL,
armazenados no Dicionrio de Dados (DD), agrupados de forma que executar a
stored procedure execut-los todos seqencialmente no servidor
. Podem ser tambm usadas para implementar regras de negcios que no
podem ser especificadas declarativamente na descrio das tabelas.
-
- Criando uma Stored Procedured
-
CREATE PROCEDURE <Nome_procedure>
[(argumento [IN|OUT|IN OUT] tipo)]
AS Comandos_SQL;
IN : argumento de entrada
OUT : argumento de sada
IN OUT argumento utilizado como entrada na chamada da procedure e
como sada aps sua execuo.
115
a) Exemplo de procedure sem parmetro
Criar uma procedure que aumente o salrio dos empregados em 10%
CREATE PROCEDURE aumento_salario
AS
BEGIN
UPDATE emp
SET salario_emp = salario_emp * 1.1;
END;
EXEC aumento_salario;
b)Exemplo de procedure com parmetro de input:
Criar uma procedure para aumentar os salrios de apenas um departamento e
com um percentual diferente
CREATE PROCEDURE aum_sal_depto
(var_depto IN number, percentual IN number)
AS
BEGIN
UPDATE emp
SET salario_emp = salario_emp *(1+percentual/100)
WHERE num_depto = var_depto;
END;
EXEC aum_sal_depto(30,21)
Estabelecendo aumento de 21 por cento para o depto 30
- Excluindo uma Stored Procedure
DROP PROCEDURE <nome_procedure>
116
4.7.5.2. TRIGGERS
.So tipos especiais de Stored Procedures que so executados automaticamente
pelo servidor quando um comando INSERT, UPDATE ou DELETE
executado em uma tabela ou viso.
.Permite especificar regras de negcios do tipo EVENTO-CONDIO-
AO, em que o SGBD detecta a ocorrncia de um EVENTO, avalia uma
CONDIO no banco de dados e, se esta for satisfeita, executa uma AO
predeterminada.
117
Criando uma Trigger
CREATE [OR REPLACE] TRIGGER <nome_da_trigger>
{BEFORE | AFTER }
{DELETE | INSERT | UPDATE [OF coluna [,coluna]...]}
[OR { DELETE | INSERT | UPDATE [OF coluna [,coluna]...]} ]
ON {nome_tabela}
[ [REFERENCING { OLD [AS] old | NEW [AS] new}...]
FOR EACH {ROW | STATMENT}[WHEN (condio)] ]
Comandos SQL
BEFORE : o trigger disparado antes de executar o comando associado ao
trigger (quando for necessrio fazer algum pr-processamento antes do
comando)
AFTER: o trigger disparado depois de executar o comando associado ao
trigger
DELETE : o trigger associado ao comando DELETE
INSERT : : o trigger associado ao comando INSERT
UPDATE : o trigger associado ao comando UPDATE. UPDATE OF associa
o trigger a colunas especficas; caso contrrio, o trigger ser associado
alterao de qualquer coluna
STATMENT
Este trigger disparado apenas uma vez.
Exemplo:Se um comando UPDATE atualizar 15 linhas, os comandos contidos
no trigger sero executados apenas uma vez, e no a cada linha processada.
ROW
Esse trigger tem os seus comandos executados para todas as linhas que sejam
afetadas pelo comando que gerou o acionamento do trigger
Dentro de um trigger do tipo ROW_LEVEL possvel acessar o valor de um
campo de uma linha. Normalmente necessrio preceder o nome da coluna
com o sufixo :new ou :old, pois em determinado instante pode-se obter tanto o
valor antigo como o valor novo do campo.
118
No comando INSERT, os valores dos campos que sero gravados devero ser
precedidos pelo sufixo :new
No comando DELETE os valores dos campos da linha que est sendo
processada devem ser precedidos do sufixo :old
No comando UPDATE, o valor original que ser gravado acessado com o
sufixo :old; os novos valores que sero gravados devem ser precedidos do
sufixo :new
WHEN
S valida para FOR EACH ROW
Especifica a restrio do trigger, onde a condio avaliada para cada linha e
se a condio for verdadeira a expresso SQL associada ao trigger executada.
119
a)Exemplo
Regra: Nenhum funcionrio pode ganhar mais que oito mil reais.
Alm de ativar o trigger de incluso (INSERT), evitando que um novo
funcionrio tenha um salrio superior ao limite, as rotinas de atualizao
(UPDATE) devem ser verificadas para evitar que os salrios dos funcionrios
existentes sejam alterados para valores no permitidos.
CREATE TRIGGER testa_salario
BEFORE INSERT OR UPDATE OF salario_emp
ON emp
FOR EACH ROW
BEGIN
IF :NEW.salario_emp > 8000 THEN
raise_application_error (-20000, valor incorreto);
END IF
END;
Disparo do gatilho
UPDATE emp
SET salario_emp = 30000
WHERE num-emp = 2500;
Sada do comando:
Update emp
ERRO na linha 1
ORA-20000 : valor incorreto
ORA-04088 : erro durante a execuo do trigger testa_salario
120
b)Exemplo
Aps incluir um registro na tabela emp vamos replicar este registro na tabela
empdup.
CREATE TRIGGER repins_emp
AFTER INSERT ON emp
FOR EACH ROW
BEGIN
INSERT INTO empdup
VALUES
(:NEW.num_emp, :NEW.nome_emp, :NEW.salario_emp,
:NEW.sexo_emp, :NEW.cargo_emp, : NEW.num_depto);
END;
Quando inserir na tabela emp inserir tambm na tabela repins_emp
INSERT INTO emp
(1313, CARLOS, 4000,00 ,M, GERENTE, 30);
c)Exemplo
Aps deletar um registro na tabela emp vamos deletar este registro na tabela
empdup.
CREATE TRIGGER repdel_emp
AFTER DELETE ON emp
FOR EACH ROW
BEGIN
DELETE FROM empdup
WHERE num_emp = :old.num_emp;
END;
121
d)Exemplo
Regra: No permitido aumentar o limite de crdito em mais de 50%.
CREATE TRIGGER T_monitora_limite
BEFORE UPDATE OF limite_credito
ON conta
REFERENCING OLD AS antes, NEW AS depois
FOR EACH ROW
BEGIN
IF :depois.limite_credito > 1,5 * :antes.limite_credito THEN
raise_application_error (-20001, Aumento invlido);
END IF
END;
.Esta caracterstica da SQL fundamental em sistemas Cliente-Servidor.
.Uma regra de negcios global, vlida para todo o banco de dados, pode ser
especificada no servidor, no havendo a necessidade de ser replicada em todos
os programas de aplicao que potencialmente possam violar a regra.
.Isto confere modularidade na especificao de regras, o que implica em
facilidade de manuteno, j que a regra especificada apenas uma vez e
automaticamente executada no servidor.
Ativando/desativando um trigger
ALTER TRIGGER <nome-trigger> ENABLE/DISABLE;
Removendo um trigger
DROP TRIGGER <nome_trigger>;
122
Exerccio:
Suponhamos que exista uma regra no Banco de Dados BANCO: Quando uma
registro de PESSOA excludo, seu CPF, nome e endereo devem ser
gravados num tabela de histrico EX_CLIENTES.
Com uso de STORED POCEDURE
CREATE PROCEDURE P_exclui_pessoa
(X_CPF IN VARCHAR)
AS
X_Nome VARCHAR;
X_End VARCHAR;
BEGIN
SELECT nome, endereo INTO X_nome , X_end
FROM pessoa WHERE CPF = X_CPF;
INSERT INTO ex_cliente VALUE (X_CPF, X_nome, X_end);
DELETE FROM pessoa WHERE CPF = X_CPF;
EXCEPTION
WHEN NO_DATA_FOUND
THEN raise_application_error(-20002, CPF invlido);
END exclui_pessoa;
Sendo assim qualquer excluso de PESSOA deve ser feito atravs do
procedimento P_exclui_pessoa.
Com uso do TRIGGER T_exclui_pessoa
CREATE TRIGGER T_exclui_pessoa
BEFORE DELETE
ON pessoa
FOR EACH ROW
BEGIN
INSERT INTO ex_cliente
VALUES (:old.CPF, :old.nome, :old.endereco);
END T_exclui_pessoa;
A diferena entre P-exclui_pessoa e T_exclui_pessoa que o trigger executa a
regra automaticamente toda vez que um registro de PESSOA excludo,
enquanto o procedure requer uma chamada explcita do usurio ou de uma
aplicao.
123
4.7.6 - SQL EMBUTIDA
As instrues da SQL EMBUTIDA so prefixadas por um sinal $(para que
possa ser facilmente reconhecida pelo pr compilador) e as instrues SQL
podem referenciar variveis do programa utilizando o prefixo %
Observao:
Estes prefixos podem variar de linguagem para linguagem.
1 - A instruo $SELECT inclui uma clausula INTO especificando variveis as
quais so atribudos valores recuperados do BD.
2 - A maioria das instrues SQL pode ser embutida em linguagens
hospedeiras(COBOL, PASCAL, C, ...) de uma forma bastante direta (isto ,
com apenas algumas alteraes sobre sua sintaxe)
Entretanto a instruo SQL SELECT faz com que seja retornada uma tabela ao
usurio(dai, conceito CURSOR: mecanismo que permite acesso aos registros
do conjunto 1 por 1)
* Definio
LET <cursor nome> BE <expresso>
* Ativao
OPEN <cursor nome>
Posiciona antes do 1 registro que satisfaa a condio
* Avano
FETCH <cursor nome>
Avana e extrai campos para INTO
* Desativao
CLOSE <cursor nome>
@ SQLCODE :
Status da pesquisa :
0 ok!
+100 problema
124
Exemplo 1
BD Empresa Bancria
Type Nome = String[25];
Var Aumento : Integer
Continua : Char
D : Record
Anome, Cnome :Nome;
Conta :String[07];
Saldo :Real;
end;
C : Record
Cnome :Nome;
Rua :String[20];
Cidade :String[15];
end;
125
A) Segmento de programa que l o Nome de um Cliente e imprime seu
endereo.
$ DECLARE CLIENTE TABLE
(Nome-Cliente :Char[50] NOT NULL,
Rua-Cliente :Char[10],
Cidade-Cliente :Char[10]);
C1: Continua := S;
WHILE Continua = S DO
BEGIN
WRITELN(Entre com o nome do Cliente);
READLN(C.Cnome);
$ SELECT Rua-Cliente, Cidade-Cliente
INTO %C.Rua, %C.Cidade
FROM CLIENTE
WHERE Nome-Cliente = %C.Cnome;
WRITELN(C.Rua, C.Cidade);
WRITELN(Mais Nomes de Clientes (S/N));
READLN(Continua);
END;
126
B) Porem, uma consulta SQL pode recuperar vrias tuplas.
O que fazer?
Seja um Segmento de programa que l um nome de agncia e lista os Clientes
que tem depsito nesta agncia.
Este segmento tambm l uma quantidade utilizada para aumentar o saldo de
cada um dos clientes acima.
$ DECLARE DEPOSITO TABLE
(Nome-Agencia :Char[10] NOT NULL,
Numero-Conta :Char[08],
Nome-Cliente :Char[30] NOT NULL,
Saldo : Real);
C2 : WRITELN(Entre com o Nome da Agencia : );
READLN(D.Anome);
$ LET DEPCUR BE
$ SELECT Numero-Conta, Nome-Cliente,Saldo
FROM DEPOSITO
WHERE Nome-Agencia = % D.Anome
FOR UPDATE OF Saldo;
$ OPEN DEPCUR;
$ FETCH DEPCUR INTO %D.Conta, %D.Cnome,%D.Saldo;
WHILE SQLCODE = 0 DO
BEGIN
WRITELN(NomeEmpregado,D.Cnome,D.Conta);
WRITELN(Entre com o aumento :);
READLN(Aumento);
$ UPDATE DEPOSITO SET Saldo=Saldo+%Aumento
WHERE CURRENT OF DEPCUR;
$ FETCH DEPCUR INTO %D.Conta,%D.Cnome,%D.Saldo;
END;
$ CLOSE DEPCUR;
127
5. EXERCCIOS:
5.1. EXERCICIOS DE MODELAGEM DE DADOS
5.1.1.Projetos
Este texto descreve uma Empresa de Projetos de grande porte, envolvendo diversos
projetos como Engenharia, Urbanismo, Transporte. A Empresa organizada em Deptos.
Cada Depto coordena ( responsvel) por vrios projetos e um projeto coordenado
obrigatoriamente por um nico Depto.
Cada Depto tem um Empregado que o gerencia. Um empregado deve pertencer
obrigatoriamente a um Depto, mas pode estar alocado vrios Projetos.
5.1.2.Loja
Uma loja especializada em computadores resolveu automatizar seus procedimentos de
venda e aluguel de computadores. Atravs de entrevistas com seu diretor, gerente e
funcionrios, observou o seguinte:
Os clientes da loja podem alugar ou comprar computadores.
Se o cliente faz opo por alugar ento obrigatoriamente tem que fazer um contrato de
manuteno para dar cobertura ao computador que est sendo alugado.
Sabe-se ainda que :
Dado um cliente e um Contrato este par pode estar associado a vrias mquinas.
Dado uma mquina de um determinado contrato este par pertence a vrias mquinas.
Dado um Cliente e uma mquina este par pertence a um nico contrato.
5.1.3.A Universidade Milenium
Os diversos institutos da Universidade Milenium esto organizados em Departamentos.
Cada departamento possui um corpo docente e um dos professores o Chefe do
Departamento.
Um Departamento responsvel pelo ensino de diversas disciplinas. Cada disciplina
pode ser lecionada por vrios professores. Um professor pode lecionar mais de uma
disciplina.
Os alunos cursam as disciplinas de acordo com os pr-requisitos j alcanados. Os
alunos podem optar com qual professor ele cursar determinada disciplina.
A Universidade mantm, para cada aluno, um Histrico Escolar, que relaciona as
disciplinas que ele j cursou, com as respectivas notas e a freqncia.
5.1.4.Controle de Projetos
Uma Empresa manufatureira funciona num esquema de Projeto, nos quais so alocados
seus empregados com um certo percentual de dedicao.
Administrativamente, os empregados esto lotados em departamentos e podem gerenciar
um ou mais projetos que so gerenciados por um nico empregado.
As Peas utilizadas nos projetos so armazenadas nos vrios armazns.
A Empresa mantm um controle do fornecimento Efetivo de Peas feito aos projetos
pelos fornecedores, e um controle de fornecimento Potencial de Peas de cada um
dos seus fornecedores.
Deve-se controlar a composio das peas, onde uma pea pode ser simples ou composta.
As peas compostas so montagens de peas simples. Cada pea simples pode ser
utilizada para compor vrias peas compostas.
128
5.1.5. Empresa do ramo de alimentao
Deseja-se controlar as principais atividades de uma empresa do ramo de alimentao,
que possui vrias lojas de varejo e vrios armazns para guardar seus produtos. Estes
armazns so especializados (por exemplo, frigorfico) de maneira que um produto s
pode ser armazenado em um nico armazm e um armazm pode armazenar vrios produtos.
As lojas podem emitir vrios pedidos, sendo que um pedido deve pertencer
obrigatoriamente a uma loja. Um Pedido composto de vrios produtos e um produto
pode fazer parte de vrios pedidos.
Para entregar os pedidos a empresa conta com uma frota de caminhes dos mais variados
tipos. Um caminho pode atender a vrios pedidos, e um pedido pode ser atendido por
mais de caminho (por exemplo, no caso em que pedido no caiba em um nico caminho).
Observe que o sistema deve ser capaz de informar quais os produtos de determinado
pedido esto em determinado caminho. O sistema deve permitir ainda que existam
pedidos que no sejam atendidos por nenhum caminho.
Cada caminho tem um obrigatoriamente um funcionrio que o responsvel pelo mesmo,
e um Funcionrio pode ser responsvel por mais de um caminho.
5.1.6.Restaurante
Deseja-se desenvolver um Sistema de Controle das principais atividades de um
restaurante, atendendo s seguintes consideraes:
Os Clientes novos devero ser cadastrados pelo sistema para efeito de
correspondncias futuras, sendo necessrio armazenar os dados pessoais. Sabe-se que
cada cliente pode fazer vrios pedidos, ou nenhum, e um pedido sempre estar
associado a um nico cliente.
Um pedido est associado obrigatoriamente a vrios itens de cardpio. Cada item do
cardpio pode estar associado a vrios pedidos ou nenhum, sendo necessrio armazenar
quais itens foram pedidos, a quantidade de cada um e a data do pedido, a fim de que a
conta, com o valor total, possa ser gerada no final do atendimento.
Cada item do cardpio possui um cdigo, um nome, um tipo (indicando se bebida ou
comida), uma descrio detalhada e um preo unitrio.
Cada pedido est obrigatoriamente associado a uma mesa, sendo possvel associar
vrios pedidos a uma mesma mesa. Cada mesa atendida por um nico garon, que pode
atender a vrias mesas. O nmero de identificao do garon tambm deve constar na
conta a ser gerada.
5.1.7.A cadeia de Hotis Imperador
A cadeia de Hotis Imperador possui diversos hotis situados nas principais capitais.
Cada hotel possui vrios tipos de apartamento (simples, luxo, suite, etc.) e um
apartamento, naturalmente, pertence a um nico hotel.
Toda vez que um cliente se hospeda, necessrio que ele informe o nmero da Carteira
de Identidade ou Passaporte, endereo, data de nascimento e o sexo. Para controle
interno, o hotel tambm registra o nmero do quarto alocado e a data da hospedagem.
Qualquer hotel da cadeia deve ser capaz de responder imediatamente a um pedido de
reserva (efetivando-a ou negando-a). A data em que foi feita a reserva deve ser
registrada.
O hspede pode utilizar os diversos servios do hotel (lavanderia, sauna, etc.),
pagando a conta apenas no check-out. Os servios oferecidos por toda a cadeia de
hotis so padronizados.
129
5.1.8.Modelo para uma biblioteca
Uma Empresa possui uma Biblioteca para uso exclusivo dos seus empregados que podem
levar emprestado um nmero qualquer de exemplares, e fazer solicitaes de emprstimo
(RESERVA) quando no houver exemplar disponvel.
Os Livros so classificados em Categorias e em Subcategorias. Eles devem pertencer a
uma nica categoria Principal e podem pertencer a vrias Categorias Secundrias.
Quando um Livro possui vrios Autores um deles e referido como Autor Principal e os
outros como Co-Autores.
130
5.1 EXERCCIOS DE NORMALIZAO:
5.2.1 - PEDIDOS(#Num-pedido, data-Pedido, Num-Cliente, Nome-Cliente,
End-Cliente, ((Cod-Produto, nome-Produto, Preo-Unitrio, Qtde-
Pedida,Valor-Total-Item)),Valor-Total-Pedido)
5.2.2 - CONTRATO(#Num-contrato, Cod-Cliente, Nome-Cliente, CPF-
Cliente, Dt-inic-contrato, Dt-term-contrato, ((Num-prestao, Valor-Prestao,
Dt-Venc-prest)), Valor-Total-Contrato)
5.2.3 - EMPREGADO(#Cod-Empregado, Nome-Empregado, Ttulo-
Empregado, ((Cod-Curso,Nome-Curso, data-incio-Curso, Resultado-Curso)))
5.2.4 - PEA-ESTOCADA(#Cod-Pea, #Cod-Armazem, Qtde-Estocada,
Tel-armazem)
5.2.5 - QUADRO-PESSOAL
#Cod-Orgo
Nome-Orgo
CARGO N vezes
Cod-Cargo
Nome-Cargo
Nmero-Vagas
FUNCIONRIO N vezes
Matricula-Emp
Nome-Emp
Data-Posse
131
5.2.6 - DADOS-EMPREGADO
#Matricula
Nome
Endereo
Cdigo-Cargo-Atual
Nome-Cargo-Atual
CURSOS N vezes
Cod-Curso
Nome-Curso
Data-Concluso
Nota-Final
HABILIDADES N vezes
Cod-Habilidade
Nome-Habilidade
Grau-Habilitao
Data-Admisso
Codigo-Orgo-Lotao
Nome-Orgo-Lotao
5.2.7 PROJETO
#Cod-Proj
Tipo-Proj
Desc-Proj
EMPREGADO N VEZES
Cod-Empregado
Nome-Emp
Cat-Emp
Sal-Emp
Data-ini-Proj
5.2.8 ARQ_CANDIDATO
#Cod-Curso
Nome-Curso
Num-Vagas-Curso
CANDIDATO N VEZES
Cod-Cand
Nome-Cand
Escore-Cand
132
5.2.9 ARQ_ALUNO
#Cod-Aluno
Nome-Aluno
CURSO N VEZES
Cod-Curso
Nome-Curso
Sem-Ingresso
DISCIPLINA N VEZES
Cod-Disciplina
Nome-Disciplina
SEMESTRE-CURSADO N VEZES
Sem-Disc-Cursada
Nota-Disc
133
5.2 EXERCCIOS DE SQL.
FORNECEDOR
Cod_forn Nome_forn Status_forn Cidade_forn
F1 PAVAN 20 JUIZ DE FORA
F2 ABC 10 RIO DE JANEIRO
F3 TUCANO 30 RIO DE JANEIRO
F4 MATIASE 20 JUIZ DE FORA
F5 RODOPAZ 30 SO PAULO
PEA
Cod_peca Nome_peca Cor_peca
P1 PARAFUSO PRETA
P2 PORCA AZUL
P3 ARRUELA BRANCA
P4 PREGO PRETA
P5 CANO VERDE
P6 FIO AZUL
EMBARQUE
Cod_Forn Cod_peca Qtde
F1 P1 300
F1 P2 200
F1 P3 400
F1 P4 200
F1 P5 100
F1 P6 100
F2 P1 300
F2 P2 400
F3 P2 200
F4 P2 200
F4 P4 300
F4 P5 400
134
0) Criar as tabelas.
CREATE TABLE fornecedor (
cod_forn CHAR(02),
nome_forn VARCHAR(50) UNIQUE KEY,
status_forn NUMBER(02) NOT NULL,
cidade_forn VARCHAR(30),
CONSTRAINT fornecedor_PK
PRIMARY KEY (cod_forn)
);
CREATE TABLE peca (
cod_peca CHAR(02) PRIMARY KEY,
nome_peca VARCHAR(50) UNIQUE KEY,
cor_peca NUMER(02) NOT NULL,
);
CREATE TABLE embarque (
cod_forn CHAR(02),
cod_peca CHAR(02),
qtde NUMBER(05) NOT NULL,
CONSTRAINT embarque_PK
PRIMARY KEY (cod_forn,cod_peca),
CONSTRAINT cod_forn_embarque_FK
FOREIGN KEY (cod_forn)
REFERENCES fornecedor(cod_forn),
CONSTRAINT cod_peca_embarque_FK
FOREIGN KEY (cod_peca)
REFERENCES peca(cod_peca)
);
135
1) Obtenha o Cdigo de todas as peas fornecidas
SELECT DISTINCT cod_peca
FROM embarque;
2) Obtenha o cdigo dos fornecedores do RIO DE JANEIRO com status > 20
SELECT cod_forn
FROM fornecedor
WHERE cidade = RIO DE JANEIRO and status_forn > 20;
3) Obtenha o nome dos fornecedores que fornecem a pea P2
SELECT DISTINCT nome_forn
FROM fornecedor F, embarque E
WHERE F.cod_forn = E. cod_forn and
E.cod_peca = P2;
4) ORDER BY
Obtenha o cdigo e o status dos fornecedores do RIO DE JANEIRO, por ordem
descendente de Status
SELECT cod_forn,status_forn
FROM fornecedor
WHERE cidade = RIO DE JANEIRO
ORDER BY status_forn DESC;
136
5). GROUP BY
Para cada Pea fornecida, obtenha o nmero da Pea e a quantidade total fornecida
daquela Pea.
SELECT cod_peca, SUM(Qtde )
FROM embarque
GROUP BY cod_peca;
Agrupa a tabela por Grupos, de forma que o:
1 Grupo contenha as linhas da Pea P1, o
2 Grupo contenha as linhas da Pea P2, e
assim sucessivamente
A Clausula SELECT ento aplicada a cada Grupo da tabela particionada.
6) HAVING
Obtenha os cod_peca das Peas, para todas Peas fornecidas por mais de um
fornecedor
SELECT cod_peca
FROM embarque
GROUP BY cod_peca
HAVING COUNT(*) > 1;
Funciona para Grupos da mesma forma que WHERE funciona para linha(Se
HAVING for especificado, GROUP BY tambm tem que ser especificado).
137
7)COUNT
Obtenha o nmero total de fornecedores que esto efetivamente fornecendo Peas.
SELECT COUNT(DISTINCT cod_forn)
FROM embarque;
8) LIKE
Obtenha todas as Peas, com nome comeando com a letra C
SELECT cod_peca
FROM peca
WHERE nome_peca LIKE C%;
9) IN
Obtenha o nome dos fornecedores que fornecem a Pea P2 .
SELECT nome_forn
FROM fornecedor
WHERE cod_forn IN
(SELECT cod_forn
FROM embarque E
WHERE E.cod_peca = P2);
138
5.3 - EXECCIOS DE ALGEBRA RELACIONAL
5.4.1 - Considere as seguintes relaes
FORN #FN Fnome Fcidade PEA #PN Pnome Pcor
1313 Pavan J. Fora P1 pia branca
1320 ABC T.Rios P2 vaso bege
1330 DEF J. Fora P3 sifo branca
1350 Gil J. Fora P4 fio preto
1360 Visart R.Janeiro
FORNECIMENTO #FN #PN QTDE
1313 P1 25
1313 P2 20
1320 P2 25
1320 P3 20
1360 P3 25
1313 P4 20
A) Quais os nomes dos fornecedores que fornecem pelo
menos 1 pea.
a.1) PROJECT FORNECIMENTO OVER FN GIVING R1
a.2) JOIN FORN AND R1 OVER FN GIVING R2
a.3) PROJECT R2 OVER Fnome GIVING R3
PRINT R3
a.1)R1 FN a.2) R2 FN Fnome Fcidade
1313 1313 Pavan J. Fora
1320 1320 ABC T. Rios
1360 1360 Visart R. Janeiro
a.3)R3 Fnome
Pavan
ABC
Visart
139
B) Quais os nomes de todos os fornecedores
PROJECT FORN OVER Fnome GIVING ARQ
C) Encontre o nome da cidade do fornecedor 1360
SELECT FORN WHERE FN = 1360 GIVING R1
PROJECT R1 OVER Fcidade GIVING R2
D) Encontre o nome dos fornecedores de J. Fora
SELECT FORN WHERE Fcidade=J. Fora giving R1
PROJECT R1 OVER Fnome GIVING R2
E) Encontre o nome das Peas fornecidas pelo
fornecedor 1313
F) Obtenha o nome dos fornecedores que fornecem
a pea P2
140
5.4..2 Considere as seguintes relaes
ALUNO #Matr Nome DISC#Codigo Nome
9516001 Jose ADMP Administ.
9516002 Juca LTPIV B.D
9516003 Joao TAPII Projeto
9616001 Pedro
9616002 Carlos
APROVADO #Matr #Codigo Nota Falta
9516001 LTPIV 55,0 2
9516001 TAPII 60,0 4
9516002 ADMP 80,0 0
9516002 LTPIV 90,0 1
9516002 TAPII 90,0 2
9516003 ADMP 70,0 2
A) Obter o nome dos alunos que j cursaram todas as
diciplinas.
141
5.4.3 - Considere as seguintes relaes
DEPTO #DN Dnome Dlocal Dchefe
1313 Informtica RJ 11310
1320 Pessoal SP 11560
1350 Material SP 11600
1360 Contbil JF 11650
EMPREGADO #EN Enome Esalrio DN
11310 Carlos 5.000,00 1313
11530 Adriana 3.000,00 1313
11540 Lo 3.500,00 1313
11560 Joo 5.000,00 1320
11570 Jlio 3.000,00 1320
11600 Pedro 5.000,00 1350
11620 Alyne 3.000,00 1350
11630 Juca 8.000,00 1350
11650 Mrio 5.000,00 1360
11700 Ricardo 3.000,00 1360
11750 Geraldo 7.000,00 1360
A)Obter o nome dos empregados que ganham mais do que
seus chefes.
142
6. BIBLIOGRAFIA
1 ELMASRI, Ramez e NAVATHE, Shamkant B. Fundamentals of
Database System. Third Edition. Ed. Addison-Wesley, 2000.
2 KORTH, H. F. e SILBERSCHATZ, A. Sistemas de Banco de
Dados. Terceira edio Ed. McGraw Hill, 1999.
3 HEUSER, Carlos Alberto.Projeto de Banco de Dados. Porto
Alegre. Ed. Sagra Luzzato, 1998.
4 -DATE, C. J. Introduo a Sistemas de Banco de Dados, Rio de
Janeiro, Ed. Campus, 1986.
5 - STEZER, Valdemar W.. Banco de Dados, So Paulo, Ed. Edgar
Blucher, 1986.
6 - COUGO, Paulo. Modelagem Conceitual, Rio de Janeiro, Ed.
Campus,1997.
7 - BARBIERI, Carlos. Modelagem de Dados, Rio de Janeiro, Ed. IBPI
Press,1994.
8 - MACHADO, Felipe Nery R. Projeto de Banco de Dados uma
viso prtica, So Paulo, Ed. rica, 1995.
9 - CEROLA, Vicente Osvaldo. Banco de dados relacional e
distribudo, So Paulo, LTC, 1995.
10 - CHEN, Peter. Gerenciando Banco de Dados. A abordagem
entidade e Relacionamento, So Paulo, Ed. McGraw Hill, 1990
11 Apostila Curso oracle(OR8) : SQL and PL/SQL, Volumes 1 e 2.
Oracle Corporation, 1998
12 Ramalho, Jos Antnio. Oracle 8i-Srie Ramalho , So Paulo,
1999.
13 SUNDERRAMAN, Rajshekhar. Oracle Programming, Gergia
Ed. Addison-Wesley, 1999

Apostila BD

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 BD

Enviado por

Direitos autorais:

Formatos disponíveis

1

Você também pode gostar