1198893369_Apostila BD

1

1. BANCOS DE DADOS................................................................................41.1. Banco de Dados (BD)...................................................................................41.2. Sistema de Gerência de Banco de Dados (SGBD)....................................4

1.2.1.Processamento de Dados sem Banco de Dados....................................51.2.2.Processamento de dados com uso de SGBD.........................................51.2.3.Principais Componentes de um SGBD..................................................61.2.4.Funções de um SGBD.............................................................................6

1.3. Fluxo Operacional de Dados e Controle.....................................................81.4. Abstração de Dados....................................................................................101.5. Modelos de Bancos de Dados....................................................................111.6. Independência de Dados.............................................................................111.7. Especificação CODASYL para arquitetura BD.......................................121.8. Especificação ANSI/X3/SPARC para arquitetura BD............................121.9. Funções relacionadas ao SGBD ................................................................14

1.9.1.Administrador de Dados.......................................................................141.9.2.Administrador de Banco de Dados......................................................14

1.10.Arquiteturas para uso do SGBD ................................................................151.10.1.Mono-usuário.......................................................................................151.10.2.Multi-Usuário com Processamento Central ......................................151.10.3.Arquitetura Cliente/Servidor ..............................................................15

1.11.Fases do Projeto de BD ..............................................................................161.11.1.Construir o Modelo Conceitual.........................................................161.11.2.Construir o Modelo Lógico ................................................................161.11.3.Construir o Modelo Físico..................................................................161.11.4.Avaliar o Modelo Físico .....................................................................161.11.5.Implementar o BD...............................................................................16

2. MODELAGEM DE DADOS....................................................................172.1. Conceitos .....................................................................................................172.2. Requisitos para Modelagem de Dados......................................................172.3. Modelos Conceituais ..................................................................................172.4. Modelos Lógicos.........................................................................................18

2.4.1.Modelo Relacional.................................................................................182.4.2.Modelo de Rede.....................................................................................192.4.3.Modelo Hierárquico ..............................................................................20

2.5. Modelo de Dados Físico.............................................................................23

2

3. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)....................233.1. Introdução ....................................................................................................233.2. Entidade .......................................................................................................233.3. Relacionamento...........................................................................................24

3.3.1.Auto-relacionamento.............................................................................253.3.2.Cardinalidade de Relacionamentos......................................................253.3.3.Cardinalidade Máxima..........................................................................263.3.4.Classificação de Relacionamentos Binários .......................................273.3.5.Relacionamento ternário .......................................................................303.3.6.Cardinalidade mínima ...........................................................................30

3.4. Notações Alternativas.................................................................................313.5. Atributo........................................................................................................32

3.5.1.Domínio..................................................................................................323.5.2.Tipos de Atributos.................................................................................323.5.3.Atributo de Relacionamento.................................................................333.5.4.Identificador de Entidades ....................................................................333.5.5.Relacionamento Identificador (Entidade Fraca).................................343.5.6.Identificador de Relacionamentos........................................................34

3.6. Generalização/Especialização....................................................................353.7. Entidade Associativa (Agregação) ............................................................373.8. Relacionamento Mutuamente Exclusivo ..................................................38

4. O MODELO RELACIONAL....................................................................394.1. Características das Tabelas - Modelo Relacional ...................................404.2. Conceitos Básicos .......................................................................................41

4.2.1.Chave primária : (primary key) ............................................................414.2.2.Chave estrangeira : (foreign key) .........................................................414.2.3.Chave candidata ou alternativa ............................................................41

4.3. Normalização...............................................................................................424.3.1.Ilustração de um sistema a ser normalizado .......................................434.3.2.Análise de Dependência Funcional......................................................464.3.3.Formas Normais.....................................................................................504.3.4.Roteiro Prático para Normalização......................................................504.3.5.Exemplo de Normalização....................................................................52

4.4. Transposição D.E.R para D.T.R (Diagrama de Tabelas Relacionais)...564.4.1.Simbologia adotada no modelo relacional ..........................................564.4.2.Análise da Entidade no D.E.R..............................................................574.4.3.Análise de Relacionamento ..................................................................57

3

4.5. Restrições de integridade no modelo Relacional .....................................654.5.1.Integridade Lógica.................................................................................654.5.2.Integridade Física ..................................................................................65

4.6.Linguagens Relacionais................................................................................804.7.SQL (Structured Query Language) .............................................................85

4.7.1.DDL (Data Definition Language .........................................................864.7.2.DML (Data Manipulation Language).................................................934.7.3.DCL (Data Control Language).......................................................... 1074.7.4.Transaction Control............................................................................ 1104.7.5.Restrições de Integridade usando Stored Procedures e Triggers ... 113

5. EXERCÍCIOS:......................................................................................... 1275.1.Exercicios de Modelagem de Dados......................................................... 1275.2.Exercícios de Normalização:..................................................................... 1305.3.Exercícios de SQL...................................................................................... 1335.4.Execícios 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 coleção dedados interrelacionados, armazenados de forma centralizada ou distribuída,com redundância controlada, para servir a uma ou mais aplicações.

1.2. SISTEMA DE GERÊNCIA DE BANCO DE DADOS (SGBD)

Conjunto de software para gerenciar (definir, criar, modificar,usar) um BD e garantir a integridade e segurança dos dados. O SGBD é ainterface entre os programas de aplicação e o BD. Em inglês é denominadoDataBase Management System (DBMS).

5

1.2.1. PROCESSAMENTO DE DADOS SEM BANCO DE DADOS

Dados de diferentes aplicações não estão integrados, pois são projetadospara atender a uma aplicação específica.

Problemas da falta de integração de dados:O mesmo objeto da realidade é múltiplas vezes representado na base de

dados. Exemplo: dados de um produto em uma indústria.Redundância não controlada de dados: Não há gerência automática da

redundância, o que leva a inconsistência dos dados devido aredigitação de informações

Dificuldade de extração de informações: os dados são projetados paraatender aplicações especificas gerando dificuldades para ocruzamento de informações

Dados pouco confiáveis e de baixa disponibilidade

1.2.2. PROCESSAMENTO DE DADOS COM USO DE SGBD

Os dados usados por uma comunidade de usuários são integrados noBanco de Dados. Cada informação é armazenada uma única vez, sendo que aseventuais redundâncias são controladas pelo sistema em computador, ficandotransparentes para os usuários.

6

1.2.3. PRINCIPAIS COMPONENTES DE UM SGBD

Dicionário de dados (Data Dictionary):

Descreve os dados e suas relações em forma conceitual e independente deseu envolvimento nas diversas aplicações. Fornece referências cruzadas entreos dados e as aplicações.

Linguagem de definição de dados (DDL - Data Definition Language):

Descreve os dados que estão armazenados no BD. As descrições dos dadossão guardadas em um “meta banco de dados”.

Linguagem de acesso (DML - Data Manipulation Language):

Usada para escrever as instruções que trabalham sobre a base de dados,permitindo o acesso e atualização dos dados pelos programas de aplicação.

Linguagem de consulta (QUERY):

Permite que o usuário final, com poucos conhecimentos técnicos, possaobter de forma simples, informações do BD.

Utilitários administrativos:

Programas auxiliares para carregar, reorganizar, adicionar, modificar adescrição do BD, obter cópias de reserva e recuperar a integridade física emcaso de acidentes.

1.2.4. FUNÇÕES DE UM SGBD

Um princípio básico em BD determina que cada item de dado deveriaser capturado apenas uma vez e então armazenado, de modo que possa tornardisponível para atender a qualquer necessidade de acesso qualquer momento.

7

Alguns pontos importantes são:Independência dos dados: O SGBD deve oferecer isolamento das

aplicações em relação aos dados. Esta característica permitemodificar o modelo de dados do BD sem necessidade de reescreverou recompilar todos os programas que estão prontos. As definiçõesdos dados e os relacionamentos entre os dados são separados doscódigos os programas.

Facilidade uso/desempenho: Embora o SGBD trabalhe com estruturasde dados complexas, os arquivos devem ser projetados para atender adiferentes necessidades, permitindo desenvolver aplicações melhores,mais seguras e mais rapidamente. Deve possui comandos poderososem sua linguagem de acesso.

Integridade dos dados: O SGBD deve garantir a integridade dos dados,através da implementação de restrições adequadas. Isto significa queos dados devem ser precisos e válidos.

Redundância dos dados: O SGBD deve manter a redundância de dadossob controle, ou seja, ainda que existam diversas representações domesmo dado, do ponto de vista do usuário é como se existisse umaúnica representação.

Segurança e privacidade dos dados: O SGBD deve assegurar que estessó poderão ser acessados ou modificados por usuários autorizados.

Rápida recuperação após falha: Os dados são de importância vital enão podem ser perdidos. Assim, o SGBD deve implementar sistemasde tolerância a falhas, tais como estrutura automática de recover euso do conceito de transação.

Uso compartilhado: O BD pode ser acessado concorrentemente pormúltiplos usuários.

Controle do espaço de armazenamento: O SGBD deve mantercontrole das áreas de disco ocupadas, evitando a ocorrência de falhaspor falta de espaço 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 usuário comunica-se com o SGBD utilizando DMLpedindo a leitura de um registro lógico.

2 - O SGBD emite um comando para o S.O. para leitura dosesquemas (META DADOS).

3 - O S.O. acessa os esquemas.

4 - Os Meta-dados são transferidos para área de E/S do SGBD.

5 - O SGBD consulta os Meta-dados para saber como traduzir ocomando do usuário.

6 - O SGBD emite os comandos para que o S.O. leia os registros físicos necessários.

7 - O S.O. acessa a base de dados.

8 - Os registros físicos são transferidos para área de E/S do SGBD.

9 - O SGBD seleciona os dados necessários para formar o(s) registro(s) lógico(s) pedidos pelo usuário, se necessário faz a transformação, e coloca o registro lógico na área do usuário/aplicação.

10 - O SGBD envia ao programa de aplicação um código indicando fimde comando.

10

1.4. ABSTRAÇÃO DE DADOS

Um propósito central de um SGBD é proporcionar aos usuários umavisão abstrata dos dados, isto é, o sistema esconde certos detalhes de como osdados são armazenados ou mantidos. No entanto, os dados precisam serrecuperados eficientemente.

A preocupação com a eficiência leva a concepção de estruturas dedados complexas para representação dos dados no BD. Porém, uma vez queSGBD são freqüentemente usados por pessoas sem treinamento na área decomputação, esta complexidade precisa ser escondida dos usuários. Isto éconseguido definindo-se diversos níveis de abstração pelos quais o BD podeser visto:

NÍVEL FÍSICO: É o nível mais baixo de abstração, no qual se descrevecomo os dados são armazenados. Estruturas complexas, de baixonível, são descritas em detalhe.

NÍVEL CONCEITUAL: É o nível que descreve quais os dados sãorealmente armazenados no BD e quais os relacionamentos existentesentre eles. Este nível descreve o BD como um pequeno número deestruturas relativamente simples. Muito embora a implementação deestruturas simples no nível conceitual possa envolver estruturascomplexas no nível físico, o usuário do nível conceitual nãoprecisa saber disto.

NÍVEL VISÃO: Este é o nível mais alto de abstração, no qual se expõeapenas parte do BD. Na maioria das vezes os usuários não estãopreocupados com todas as informações do BD e sim com apenasparte delas (Visões dos Usuários)

11

1.5. MODELOS DE BANCOS DE DADOS

Um modelo de (banco de) dados é uma descrição dos tipos deinformações que estão armazenadas em um banco de dados, ou seja, é adescrição formal da estrutura de BD.

Estes modelos podem ser escritos em linguagens textuais ou linguagensgráficas. Cada apresentação do modelo é denominado “esquema de banco dedados”.

Se tomarmos como exemplo uma indústria, o modelo de dados devemostrar que são armazenadas informações sobre produtos, tais como código,descrição e preço. Porém o modelo de dados não vai informar quais produtosestão armazenados no Banco de Dados.

No projeto de um banco de dados, geralmente são considerados 3modelos: conceitual, lógico e físico.

Modelo conceitual: É uma descrição mais abstrata da base de dados.Não contém detalhes de implementação e é independente do tipo deSGBD usado. É o ponto de partida para o projeto da base de dados.

Modelo Lógico: É a descrição da base de dados conforme é vista pelosusuário do SGBD (programadores e aplicações). É dependente do tipode SGBD escolhido, mas não contém detalhes da implementação(uma vez que o SGBD oferece abstração e independência de dados).

Modelo físico (interno): Descrição de como a base de dados éarmazenada internamente. Geralmente só é alterada para ajuste dedesempenho. A tendência dos produtos modernos é ocultar cada vezmais os detalhes físicos de implementação.

1.6. INDEPENDÊNCIA DE DADOS

Independência de dados a nível físico: a capacidade de se modificar o modelofísico, sem precisar reescrever os programas de aplicação.

Independência dados a nível lógico: a capacidade de se modificar o esquemalógico, sem a necessidade de reescrever os programas de aplicação.Modificações no nível lógico são necessárias sempre que a estrutura lógicado BD for alterada. Em alguns casos a recompilação pode ser requerida.

12

1.7. ESPECIFICAÇÃO CODASYL PARA ARQUITETURA BD

Primeira especificação padrão 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 ( descrição completa do BD) e SUB-SCHEMA (descrição do dados que são conhecidos por um ou mais programasde aplicação)

1.8. ESPECIFICAÇÃO ANSI/X3/SPARC PARA ARQUITETURA BD

Proposta de modelo de referência para arquiteturas de BD. Teve início em 1972 (Relatório provisório ) e terminou em 1983 (Relatório final ).

Abordagem proposta por um grupo de trabalho estabelecido peloSPARC(Standard Planning and Requeriments Committe) doANSI/X3(American National Standards Committe on Computers andInformation Processing).

Os objetivos do grupo de estudo, foram os de determinar as áreas, seexistentes, de tecnologia de BD onde fosse apropriada uma atividade depadronização, e de produzir um conjunto de recomendações para ações emcada uma dessas áreas.

Trabalhando sobre estes objetivos, o grupo verificou que osINTERFACES seriam os únicos aspectos do SBD possivelmente passíveis deserem padronizados.

13

Grupo sugere três 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. FUNÇÕES 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 descentralização dos processos, mas manter centralizado os dados.

Permitir fácil e rápido acesso as informações a partir dos dados armazenados

O grande objetivo de administrador de dados é permitir que vários usuárioscompartilhem os mesmos dados. Deste modo, os dados não pertencem anenhum sistema ou usuário de forma específica, e sim, à organização comoum todo. Assim, o administrador de dados se preocupa basicamente com aorganização dos dados e não com o seu armazenamento.

1.9.2. ADMINISTRADOR DE BANCO DE DADOS

O DBA (DataBase Administrator) é pessoa ou grupo de pessoasresponsável pelo controle do SGBD. São tarefas do DBA:

Responsabilidade pelos modelos lógico e físico (definindo a estrutura dearmazenamento)

Coordenar o acesso ao SGBD (usuários e senhas)

Definir a estratégia de backup

Melhorar o desempenho do SGBD

Manter o dicionário de dados

15

1.10. ARQUITETURAS PARA USO DO SGBD

1.10.1. MONO-USUÁRIO

BD está no mesmo computador que as aplicaçõesNão há múltiplos usuáriosRecuperação geralmente através de backupTípico de computadores pessoais

1.10.2. MULTI-USUÁRIO COM PROCESSAMENTO CENTRAL

BD está no mesmo computador que as aplicaçõesMúltiplos usuários acessando através de terminaisTípico de ambientes com mainframe

1.10.3. ARQUITETURA CLIENTE/SERVIDOR

Multi-usuárioServidor dedicado ao Banco de Dados, executando o SGBDAs estações clientes executam apenas as aplicaçõesTráfego na rede é menorArquitetura atualmente em uso

16

1.11. FASES DO PROJETO DE BD

1.11.1. CONSTRUIR O MODELO CONCEITUAL

Modelo de alto nível, independente da implementaçãoEtapa de levantamento de dadosUso de uma técnica de modelagem de dadosAbstração do ambiente de hardware/software

1.11.2. CONSTRUIR O MODELO LÓGICO

Modelo implementável, dependente do tipo de SGBD a ser usadoConsidera as necessidades de processamentoConsidera as características e restrições do SGBDEtapa de normalização dos dados

1.11.3. CONSTRUIR O MODELO FÍSICO

Modelo implementável, com métodos de acesso e estrutura físicaConsidera necessidades de desempenhoConsidera as características e restrições do SGBDDependente das características de hardware/software

1.11.4. AVALIAR O MODELO FÍSICO

Avaliar o desempenho das aplicaçõesAvaliar os caminhos de acesso aos dados e estruturas utilizadas

1.11.5. IMPLEMENTAR O BD

Etapa de carga (load) dos dadosGerar as interfaces com outras aplicações

17

2. MODELAGEM DE DADOS

2.1. CONCEITOS

Abstração: processo mental através do qual selecionamos determinadaspropriedades ou características dos objetos e excluímos outras, consideradasmenos relevantes para o problema que esta sendo analisado.

Modelo: é uma abstração, uma representação simplificada, de uma parcela domundo real, composta por objetos reais.

Modelagem: atividade através da qual se cria um modelo.

Modelo de dados: Um modelo de dados é uma descrição das informações quedevem ser armazenadas em um banco de dados, ou seja, é a descriçãoformal da estrutura de BD (descrição dos dados, dos relacionamentos entreos dados, da semântica e das restrições impostas aos dados).

2.2. REQUISITOS PARA MODELAGEM DE DADOS

Entender a realidade em questão, identificando os objetos que compõe a parteda realidade que vai ser modelada..

Representar formalmente a realidade analisada, construindo um modelo dedados.

Estruturar o modelo obtido e adequá-lo ao SGBD a ser usado, transformando omodelo conceitual em modelo lógico.

2.3. MODELOS CONCEITUAIS

São usados para descrição de dados no nível conceitual. Proporcionamgrande capacidade de estruturação e permitem a especificação de restrições dedados de forma explícita. Exemplos:

Modelo Entidade-Relacionamento (M.E.R.)Modelo de Semântica de dadosModelo InfológicoModelos Orientados para Objetos (OO)

18

2.4. MODELOS LÓGICOS

São usados na descrição dos dados no nível lógico. Em contraste commodelos conceituais, esses modelos são usados para especificar tanto aestrutura lógica global do BD como uma descrição em alto nível daimplementação.

2.4.1. MODELO RELACIONAL

Um BD relacional possui apenas um tipo de construção, a tabela. Umatabela é composta por linhas (tuplas) e colunas (atributos). Os relacionamentosentre os dados também são representados ou por tabelas, ou através dareprodução dos valores de atributos.

Idéias básicas Edward F. Codd , laboratório pesquisas da IBM em 1970

Exemplo : Considere o BD composto de clientes e contas.

NOME RUA CIDADE Nº CONTAJosé Rua A JF 40Juca Rua B RJ 30Juca Rua B RJ 38 *Carlos Rua C SP 45Carlos Rua C SP 38 *

Nº CONTA SALDO40 1.000,0030 2.000,0038 2.500,0045 3500,00

* compartilham a mesma conta, devem ser sócios

19

2.4.2. MODELO DE REDE

O BD em rede é um grafo, onde os nós representam os registros e osarcos representam os relacionamentos entre os registros, através de ligaçõespai-filho. Diferente do modelo hierárquico, um registro pode possuir diversosregistros pai.

Origem na linguagem de programação Cobol, Primeiro SGBD comercialIDS (Integrated Data Store) projetado para a General Eletric na década de 60.

Extensão : DBTG-CODASYL(Data Base Task Group – Conference onData Systems and Languages) , 1º especificação padrão 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,00JUCA RUA B RJ

20

2.4.3. MODELO HIERÁRQUICO

Um BD hierárquico é uma coleção de árvores de registros. Os registrossão usados para representar os dados e ponteiros são usados para representar orelacionamento entre os dados, numa ligação do tipo pai-filho. A restrição é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,0038 2.500,00

38 2.500,00

21

EXEMPLOS DOS MODELOS

A) MODELO RELACIONAL :

FORNECEDOR ( fabricante )

RAZÃO TECNOLOGIAUnisys PropriaElebra Control DataFlex Disk ShugartIBM PropriaMicrolab Ampex

PEÇA (disco)

CODIGO TIPO ACIONAMENTO410 Flexível Step Motor416 Rígido Voice Coil Linear421 Rígido Step Motor427 Rígido Voice Coil Rotatório

FORNECIMENTO

RAZAO CODIGO PREÇOUnisys 416 6.360,00Elebra 416 2.480,00Elebra 410 230,00Flex Disk 421 250,00Flex Disk 427 900,00IBM 416 5.808,00Microlab 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 HIERÁRQUICO

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 FÍSICO

Usados para descrever os dados em seu nível mais baixo. Capturam osaspectos de implementação do SGBD.

3. MODELO ENTIDADE-RELACIONAMENTO (M.E.R.)

3.1. INTRODUÇÃO

Apresentado por Peter Chen, em 1976É a técnica mais difundida para construir modelos conceituais de bases de

dadosÉ o padrão para modelagem conceitual, tendo sofrido diversas extensõesEstá baseado na percepção de uma realidade constituída por um grupo básico

de objetos chamados ENTIDADES e por RELACIONAMENTOS entreestas entidades

Seu objetivo é definir um modelo de alto nível independente de implementaçãoO modelo é representado graficamente por um Diagrama de Entidade-

Relacionamento (DER), que é simples e fácil de ser entendido por usuáriosnão técnicos

Conceitos centrais do MER: entidade, relacionamento, atributo,generalização/especialização, agregação (entidade associativa)

3.2. ENTIDADE

Conjunto de objetos da realidade modelada sobre os quais deseja-se manterinformações no Banco de Dados

Uma entidade pode representar objetos concretos da realidade (pessoas,automóveis, material, nota fiscal) quanto objetos abstratos (departamentos,disciplinas, cidades)

A entidade se refere a um conjunto de objetos; para se referir a um objeto emparticular é usado o termo instância (ou ocorrência)

No DER, uma entidade é representada através de um retângulo que contém onome da entidade

PESSOA DEPARTAMENTO

24

3.3. RELACIONAMENTO

É toda associação entre entidades, sobre a qual deseja-se manter informaçõesno Banco de Dados.

Os relacionamentos representam fatos ou situações da realidade, onde asentidades interagem de alguma forma

Um dado por si só não faz uma informação, pois não tem sentido próprio; énecessário que haja uma associação de dados para que a informação sejaobtida.

Exemplos:Fornecimento: entre as entidades FORNECEDOR e MATERIALMatrícula: entre as entidades ALUNO e DISCIPLINAFinanciamento: entre as entidades PROJETO e AGENTE

FINANCEIRONo DER, os relacionamentos são representados por losangos, ligados às

entidades que participam do relacionamento

Diagrama de ocorrências de relacionamentos:

DEPARTAMENTO EMPREGADOLOTAÇÃO

25

3.3.1. AUTO-RELACIONAMENTO

Relacionamento entre ocorrências da mesma entidade.

Diagrama de ocorrências no auto-relacionamento:

O papel da entidade no relacionamento indica a função que umaocorrência de uma entidade cumpre em uma ocorrência de um relacionamento.

3.3.2. CARDINALIDADE DE RELACIONAMENTOS

A cardinalidade de uma entidade em um relacionamento expressa onúmero de instâncias da entidade que podem ser associadas a uma determinadainstância da entidade relacionada.

Devem ser consideradas duas cardinalidades:Cardinalidade mínima de uma entidade é o número mínimo de instâncias

da entidade associada que devem se relacionar com uma instância daentidade em questão.

Cardinalidade máxima de uma entidade é o número máximo deinstâncias da entidade associada que devem se relacionar com umainstância da entidade em questão.

marido

esposa

PESSOA

CASAMENTO

26

3.3.3. CARDINALIDADE MÁXIMA

No projeto para BD relacional (como neste curso) não é necessáriodistinguir as cardinalidades que sejam maiores que 1. Assim, são usadosapenas as cardinalidades máximas 1 e n (muitos).

27

3.3.4. CLASSIFICAÇÃO DE RELACIONAMENTOS BINÁRIOS

A cardinalidade máxima é usada para classificar os relacionamentosbinários (aqueles que envolvem duas entidades).

a) Relacionamentos 1:1 (um-para-um)

Uma instância da entidade “A” está associada com no máximo uma instânciada entidade “B”.Uma instância da entidade “B” está associada com no máximo uma instânciada entidade “A”.

A B

A1 B1

A2 B2

A3 B3

28

b) Relacionamentos 1:N (um-para-muitos)

. Uma instância da entidade "A" esta associada a qualquer número deinstâncias da entidade "B".. Uma instância da entidade "B", todavia, pose estar associada a nomáximo uma instância da entidade "A"

A1 B1

A2 B2

B3

B4

29

c) Relacionamentos N:N (muitos-para-muitos)

Uma instância da entidade "A" esta associada a qualquer númeroinstâncias da entidades "B". Uma instância da entidade "B" esta associada aqualquer número de instância da entidades "A"

A B

A1 B1

A2 B2

A3 B3

A4 B4

30

3.3.5. RELACIONAMENTO TERNÁRIO

É o relacionamento formado pela associação de três entidades

Cardinalidade em relacionamentos ternários:

3.3.6. CARDINALIDADE MÍNIMA

A cardinalidade mínima é usada para indicar o tipo de participação daentidade em um relacionamento. Esta participação pode ser:

Parcial ou Opcional: quando uma ocorrência da entidade pode ou nãoparticipar de determinado relacionamento; é indicado pelacardinalidade mínima = 0 (zero).

Total ou Obrigatória: quando todas as ocorrências de uma entidadedevem participar de determinado relacionamento; é indicado pelacardinalidade mínima > 0 (zero).

31

Exemplos:

Um cliente pode fazer pedidos ou não, mas todos os pedidos devemestar associados a um cliente.

Todos os departamentos devem possuir pelo menos um empregadoalocado, e todos os empregados devem estar alocados em um departamento.

Parcialidade mínima: para um departamento ser criado, devem existempelo menos 10 empregados alocados.

3.4. NOTAÇÕES ALTERNATIVAS

Notação Santucci/MERISE: semântica participativa

Notação Setzer: semântica associativa

Notação Heuser: semântica associativa

1 NCLIENTE REALIZA

PEDIDO

1 NDEPTO ALOCA EMPREGADO

10


(0,N)

(1,1)DEPTO ALOCA EMPREGADO


(1 (0,NDEPTO ALOCA EMPREGADO

32

3.5. ATRIBUTO

É um dado que é associado a cada ocorrência de uma entidade ourelacionamento.Os atributos não possuem existência própria ou independente - estão sempreassociados a uma entidade ou relacionamento

Exemplos:Funcionário: Matrícula, Nome, EndereçoMaterial: Código, DescriçãoFinanciamento: Valor total, MesesFornecedor: Nome, Endereço

3.5.1. DOMÍNIO

É o conjunto de valores válidos que um atributo pode assumir.Ex: Estado civil: solteiro, casado, divorciado, viúvo

3.5.2. TIPOS DE ATRIBUTOS

a) Opcional/MandatórioOpcional: o atributo pode possuir um valor nulo (vazio). Ex: número de

telefoneMandatório: o atributo deve possuir um valor válido, não nulo. Ex:

nome do cliente

b) Monovalorado/MultivaloradoMonovalorado: o atributo assume um único valor dentro do domínio.

Ex: data de nascimentoMultivalorado: o atributo pode assumir um número qualquer de valores

dentro do domínio. Ex: Telefone para contato

33

c) Atômico/CompostoAtômico: o atributo não pode ser decomposto em outros atributos. Ex:

IdadeComposto: o atributo é composto por mais de um atributo. Ex: Endereço

3.5.3. ATRIBUTO DE RELACIONAMENTO

Assim como as entidades, os relacionamentos também podem possuiratributos.

3.5.4. IDENTIFICADOR DE ENTIDADES

Conjunto de atributos que tem a propriedade de identificar univocamente cadaocorrência de uma entidade

Toda entidade deve possuir um identificadorO identificador deve ser mínimo, único, monovalorado e mandatório

34

3.5.5. RELACIONAMENTO IDENTIFICADOR (ENTIDADE FRACA)

Existem casos em que uma entidade não pode ser identificada apenascom seus próprios atributos, mas necessita de atributos de outras entidades comas quais se relaciona. Este relacionamento é denominado RelacionamentoIdentificador. Alguns autores denominam uma entidade nesta situação deEntidade Fraca.

3.5.6. IDENTIFICADOR DE RELACIONAMENTOS

Uma ocorrência de relacionamento diferencia-se das demais pelasocorrências das entidades que participam do relacionamento. No exemplo

No exemplo, uma ocorrência de ALOCAÇÃO é identificada pelaocorrência de Engenheiro e pela ocorrência de Projeto. Ou seja, para cada par(engenheiro, projeto) há no máximo um relacionamento de alocação.

Em certos casos, será necessário o uso de atributos identificadores derelacionamentos. Por exemplo:

Como o mesmo médico pode consultar o mesmo paciente em diversasocasiões, é necessário o uso de um atributo que diferencie uma consulta daoutra.

35

3.6. GENERALIZAÇÃO/ESPECIALIZAÇÃO

A generalização é um processo de abstração em que vários tipos de entidadesão agrupados em uma única entidade genérica, que mantém as propriedadescomuns

A especialização é o processo inverso, ou seja, novas entidades especializadassão criadas, com atributos que acrescentam detalhes à entidade genéricaexistente

A entidade genérica é denominada superclasse e as entidades especializadassão as subclasses. A superclasse armazena os dados gerais de uma entidade,as subclasses armazenam os dados particulares

Este conceito está associado à idéia de herança de propriedades. Isto significaque as subclasses possuem, além de seus próprios atributos, os atributos dasuperclasse correspondente.

Usada quando é necessário caracterizar entidades com atributos próprios ouparticipação em relacionamentos específicos

36

Uma generalização/especialização pode ser total ou parcial:

É total quando, para cada ocorrência da entidade genérica, existe sempreuma ocorrência em uma das entidades especializadas.

É parcial quando nem toda ocorrência da entidade genérica possui umaocorrência correspondente em uma entidade especializada.

37

3.7. ENTIDADE ASSOCIATIVA (AGREGAÇÃO)

O uso desta abstração é necessário quando um relacionamento deve serrepresentado como uma entidade no modelo conceitual. Isto ocorre quando énecessário estabelecer um relacionamento entre uma entidade e umrelacionamento.

Para atender a esta situação foi criado o conceito de Entidade Associativa ouAgregação. A agregação é simplesmente um relacionamento que passa a sertratado como entidade.

Considerando o exemplo

Se for necessário adicionar a informação que, a cada consulta um oumais medicamentos podem ser prescritos ao paciente, será necessário criar umanova entidade (MEDICAMENTO). Esta entidade deve se relacionar com asconsultas, mas CONSULTA é um relacionamento. Deve ser criada então umaentidade associativa.

38

Outra forma alternativa de se representar a entidade associativa é

3.8. RELACIONAMENTO MUTUAMENTE EXCLUSIVO

Neste tipo de relacionamento uma ocorrência de um entidade pode estarassociada com ocorrências de outras entidades, mas não simultaneamente.

AVIÃO

PASSAGEIRO

CARGATRANSPORTE

TRANSPORTE

39

4. O MODELO RELACIONAL

Foi introduzido pelo pesquisador da IBM Edward F. Codd, 1970.Duas características marcantes, razões de sucesso :

. estrutura de dados simples e uniforme

. fundamentação teórica sólida

É o modelo que opera com os dados organizados como um conjunto derelações.O modelo de dados Relacional representa o banco de dados com uma coleçãode tabelas

Representação tabular :

Toda relação pode ser vista como uma tabela, onde cada linha é uma tupla e emcada coluna estão valores de um mesmo domínio.

Exemplo :

FORNECIMENTO

FORNECEDOR PEÇA PROJETO QUANTIDADE1 2 5 182 3 7 254 1 1 4

Relação = tabelaTupla = linhaAtributo = coluna

40

4.1. CARACTERÍSTICAS DAS TABELAS - MODELO RELACIONAL

a) Cada Tabela tem um nome único através do qual ela é referenciada.b) Cada Tabela contém um número fixo de colunas(grau tabela).c) Não existem linhas iguais.d) A ordem das linhas é irrelevante(identificação não é feita pela

localização, mas sim pelo valor da chave primária).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 contém valores atômicos(não são permitidos grupos de

valores).h) Cada valor de coluna é extraido de um determinado DOMÍNIO(conjunto

de valores possíveis).i) Duas ou mais colunas podem ser definidas sobre um mesmo Domínio.j) Operações sobre colunas diferentes exigem que as colunas pertençam ao

mesmo Domínio,k) Conexões entre Tabelas somente serão expressas através de valores das

colunas(Chave Estrangeira).

41

4.2. CONCEITOS BÁSICOS

4.2.1. CHAVE PRIMÁRIA : (PRIMARY KEY)

É um atributo(coluna) ou uma combinação de atributos cujos valoresdistinguem uma linha das demais dentro de uma tabela.

NUMFUNC NOMEFUNC CPFFUNC DEPTOFUNCChave primária

4.2.2. CHAVE ESTRANGEIRA : (FOREIGN KEY)

É um atributo ou uma combinação de atributos, cujos valores aparecemnecessariamente na chave primária de uma tabela.A chave estrangeira é o mecanismo que permite a implementação derelacionamentos(navegabilidade) em um banco de dados relacional.

NUMFUNC NOMEFUNC CPFFUNC DEPTOFUNCChave primária Chave estrangeira

DEPTO NOMEDPTOChave primária

4.2.3. CHAVE CANDIDATA OU ALTERNATIVA

Em alguns casos, mais de um atributo ou combinações de atributos podemservir para distinguir uma linha das demais. Um dos atributos (ou combinaçãode atributos) é escolhido como chave primária, os demais atributos (oucombinações) são denominados chaves CANDIDATAS

NUMFUNC NOMEFUNC CPFFUNC DEPTOFUNCChave primária Chave candidata Chave estrangeira

42

4.3. NORMALIZAÇÃO

O que é ?É o processo formal de exame e agrupamento de dados numa forma capaz

de suportar melhor as mudanças futuras, minimizando o impacto destasmudanças sobre a base de dados.

Segundo Edward F. Codd , normalização é um processo sistemático ereversível, que consiste em substituir um determinado conjunto de relações porsucessivos conjuntos nos quais as relações tenham uma estrutura mais simplese regular.

Principais objetivos :

Reduzir as redundânciasReduzir a necessidade de reestruturar as relações quando novos tipos de

dados são introduzidos

Escopo :

A partir deste processo pode-se, gradativamente, substituir um conjuntode entidades e relacionamentos por um outro, o qual se apresenta “purificado”em relação as anomalias de (inclusão, alteração, exclusão)

Conclusão :

Durante a Modelagem Conceitual poderemos estar trabalhando sobreestruturas não normalizadas, pois o objetivo deste modelo é com arepresentação semântica da realidade da empresa em primeiro lugar.

Nossa proposta é que seja feita uma revisão a nível de transposição doDER para o DTR, verificando as regras de normalização antes da transposiçãoentre os modelos Conceitual e Lógico da realidade modelada.

43

4.3.1. ILUSTRAÇÃO DE UM SISTEMA A SER NORMALIZADO

PEDIDO(Num-Ped, Data-Ped, Num-Cli, Nome-Cli, End-Cli ((Cod-Prod, Nome-Prod, Qtde-Ped,Preço-Prod, Total-Prod)), Total-Ped)

( ) Dentro dos parenteses estão os Ítens de dados que constituem oPedido

(( )) Os parenteses duplos envolvem os atributos do item da tupla doPedido. Esses (( )) são utilizados para indicar que mais do que um Pedido delinha pode compor um Pedido:

O Ítem de linha do Pedido é chamado de ‘GRUPO DE REPETIÇÃO’

ProdutosNum-Ped

Data-Ped

Num-Cli

Nome-Cli

End-CliCod-Prod

Nome-Prod

Qtde-Ped

Preço-Prod

Total-prod

Total-Ped

100 1/3/99 100 João Rua A, 19 102030

BananaMaçaLaranja

101520

0,101,000,20

1,0015,00 4,00

20,00200 2/4/99 100 João Rua A, 19 20

40MaçaMamão

2010

1,000,50

20,00 5,00

25,00300 3/5/99 200 Júlio Rua B, 19 10

50BananaPêra

2010

0,100,50

2,00 5,00

7,00400 4/7/99 300 Carlos Rua C, 20 10 Banana 10 0,10 1,00 1,00

44

Nesta EstruturaO que acontece se:

- O Cliente mudar o endereço

Estes problemas ocorrem na vida real

Devemos analisar também a redundância, um mesmo Cliente cadavez que fizer um pedido vamos guardar (nome-cli, end-cli).

Anomalias de armazenamento.

1 – Inclusão :Só é possível incluir um novo Cliente a partir de um pedido.

Se nosso sistema fosse, única e exclusivamente baseado na tabelaapresentada até o momento, não poderíamos cadastrar um novo Cliente emnossa tabela, a menos que surgisse um pedido para ele.

2 – Exclusão :Se houver a exclusão do Pedido número 400, toda a informação do

Cliente Carlos será perdida.

Neste caso, podemos perceber que o fato de um pedido conter, em suaestrutura, os dados do Cliente, vinculados diretamente a sua existência, podenos levar simplesmente, perder esses dados quando um pedido for excluído.

3 – Alteração :Se algum dado do Cliente 100 mudar, teremos que efetuar esta operação

em várias linhas da tabela.

Neste caso será necessário processar a alteração em cada uma das linhasde cada um dos pedidos pertencentes a esse cliente

45

Um analista experiente, intuitivamente separaria os váriosatributos do Pedido em arquivos(TABELAS) distintos.

CLIENTEPEDIDOITEM-PEDIDOPRODUTO

A Normalização realiza formalmente esta separação dos atributosem registros normalizados(CLIENTE, PEDIDO, ITEM-PEDIDO, PRODUTO)baseado na Dependência existente entre cada atributo e sua chave primária.

Ela consegue essa separação de ENTIDADES baseada não naintuição(como acontece com um analista de sistemas experiente), mas atravésde uma metodologia formal, que não requer experiência anterior comcomputadores.

46

4.3.2. ANÁLISE DE DEPENDÊNCIA FUNCIONAL

Técnica de normalização adotada em nosso curso.

Dependência Funcional :

O atributo B é funcionalmente dependente do atributo A se, em qualquerinstante, um valor em A determina, de modo único, o valor correspondente emB, na mesma relação.

Exemplo:

EMPREGADO#Num-Emp Nome-Emp Vlr-Sal-Emp

O Nome-Emp é funcionalmente dependente do Num-Emp, pelo fato de cadaNum-Emp está associado sempre ao mesmo Nome-Emp.

Para denotar esta dependência funcional, usa-se uma expressão na formaNum-Emp à Nome-Emp. A expressão denota que a coluna Nome-Empdepende funcionalmente da coluna Num-Emp. Diz-se que a coluna Num-Empé o determinante da dependência Funcional.De forma geral, o determinante de uma dependência funcional pode ser umconjunto de colunas e não somente uma coluna como na definição acima.

47

Propõe três tipos de dependências entre os atributos de uma tabela.

a) Dependência Funcional Total:

Os atributos de uma tabela tem que depender da chave primária e somente dachave primária.Um atributo C é totalmente funcionalmente dependente da chave primáriacomposta pelo atributos A e B , quando for funcionalmente dependente de Ae B e não dependente funcionalmente de qualquer parte da chave primária.Exemplo :

ALOCAÇÃO# Num-Emp# Cod-Proj Qtde-horas-trab

- A quantidade de horas trabalhadas num projeto não é funcionalmentedependente do cod-proj, porque não significa o total de horas do projeto enão é funcionalmente dependente da matrícula do funcionário, porque nãosignifica o total de horas trabalhadas pelo empregado.- A quantidade de horas trabalhadas é determinada, de modo único, pelacomposição da matrícula do empregado e do código do projeto, porquesignifica a quantidade de horas trabalhadas por empregado em umdeterminado projeto.

b) Dependência Funcional Parcial :O atributo C é parcialmente funcionalmente dependente da chave primária

composta pelos atributos A e B quando for funcionalmente dependente deA ou B e não de ambos A e B

# Cod-mat # Cod-forn

Nom-forn

Prc-mat

O atributo nom-forn é funcionalmente dependente somente do atributocod-forn. O nome do fornecedor é determinado, de modo único pelo códigodo fornecedor, independente dos materiais que são fornecidos.

48

A dependência funcional parcial ocorre quando a chave primária darelação é composta e se constitui numa anomalia que se deve ser evitada.

A solução para o problema da dependência parcial consiste na criaçãode uma nova relação, que será composta pelo atributo ou atributos quedependem de parte da chave e a chave que determine, de modo único estesatributos

# Cod-mat # Cod-forn

# Cod-forn Nom-forn

Prc-mat

c) Dependência Funcional Transitiva

- O atributo C é dependente funcional transitivo de A se C é funcionalmentedependente de B e B funcionalmente dependente de A, na mesma relação.

# 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 atributocod-proj, que por sua vez é funcionalmente dependente do atributo Num-emp. Então data-term-proj é dependente transitivo de Num-emp.- A dependência funcional transitiva constitui numa anomalia que deve serevitada.- A solução para o problema da D.F.T. consiste na criação de uma novarelação que será composta pelo atributo ou atributos que são dependentesfuncionais transitivos tendo como chave primária o atributo que determina atransitividade.

# Num-emp # Cod-proj

Nom-emp Data-term-proj

Data-adm-emp

Cod-proj

49

Resultado da análise da dependência Funcional:

Uma relação estará normalizada segundo a análise da dependência funcional,quando possuir uma única chave primária, todos os atributos não chavesforem totalmente funcionalmente dependentes da chave primária eindependentes entre si, ou seja, após a eliminação da dependência funcionalparcial e transitiva, caso exista.

50

4.3.3. FORMAS NORMAIS:

1a Forma Normal :

Uma relação estará na 1a FN se não houver atributo representandoagrupamento e nem atributo repetitivo(multivalorado).

2a Forma Normal :

Uma relação estará na 2a FN, se e somente se, estiver na 1a FN e os seusatributos não chaves forem dependentes funcionais completos da chaveprimária.

3a Forma Normal :

Uma relação estará na 3a FN, se e somente se, estiver na 2 FN e todos osseus atributos não chaves forem dependentes não transitivos da chave primária.

4.3.4. ROTEIRO PRÁTICO PARA NORMALIZAÇÃO:

A)TRANSFORMAÇÃO DE RELAÇÕES NÃO NORMALIZADAS EMRELAÇOES NA 1ª FN.- Escolher uma chave primária para a relação

- Separar da relação os atributos(ou grupos) repetitivos, transformando arelação em outras duas relações.

. Uma delas contendo o grupo repetitivo e que terá como chave acombinação da chave primária da relação não 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 ATÔMICOS

51

B)TRANSFORMAÇÃO DAS RELAÇÕES EM 1ª FN PARA RELAÇÕESNA 2ª FN.- Examinar as relações com chave primária composta e verificar se todos osatributos dependem funcionalmente de toda a chave ou apenas de parte dela.

- Os atributos que dependem de parte da chave, formam uma nova relação, cujachave primária é a parte da chave da relação em 1ª FN da qual dependem.

- Apenas os atributos que dependem totalmente da chave compostapermanecem na relação original.

C) TRANSFORMAÇÃO DAS RELAÇÕES EM 2ª FN PARA RELAÇÕESEM 3ª FN.- Examinar as dependências funcionais entre todos os atributos das relações em2ª FN.

- Aqueles atributos que dependem de outro atributo da relação, que não a suachave, vão constituir uma nova relação cuja chave é o atributo do qualdependem.ATENÇÃO : Esta chave continua como atributo na tabela Base pois é oelo de ligação entre ambas.

52

4.3.5.EXEMPLO DE NORMALIZAÇÃO:

ENTIDADEATRIBUTO

PEDIDO

Num-Ped XData-Ped \Num-Cli \Nome-Cli \End-Cli \Cod-Prod ( \ )Nome-Prod ( \ )Qtde-Ped ( \ )Preço-Prod ( \ )Total-Prod ( \ )Total-Ped \

53

1ª FN – Ëliminar atributos multivalorados e atributos representam agrupamento

ENTIDADEATRIBUTO

PEDIDO ITEM PED

Num-ped X XData-Ped \Num-Cli \Nome-Cli \Nome-log \Numero-log \Cidade-log \Estado-log \Cep-log \Cod-Prod XNome-Prod \Qtde-Ped \Preço-Prod \Total-Prod \Total-Ped \

54

2 ª FN – Eliminar D.F.P

ENTIDADEATRIBUTO

PEDIDO ITEM PED PRODUTO

Num-Ped X XData-Ped \Num-Cli \Nome-Cli \Nome-Log \Numero-Log \Cidade-Log \Estado-Log \Cep-Log \Cod-Log X XNome-Prod \Qtde-Ped \Preço-Prod \Total-Prod \Total-Ped \

55

3 ª FN – Eliminar D.F.T- Redundância deve ser evitada. Não devo guardar o que posso

calcular(Cuidado - carroça)

ENTIDADEATRIBUTO

PEDIDO ITEM PED PRODUTO CLIENTE

Num-Ped X XData-Ped \Num-Cli \ XNome-Cli \Nome-Log \Numero-Log \Cidade-Log \Estado-Log \Cep-Log \Cod-Prod X XNome-Prod \Qtde-Ped \Preço-Prod \Total-ProdTotal-Ped

56

4.4. TRANSPOSIÇÃO D.E.R PARA D.T.R (DIAGRAMA DE TABELAS

RELACIONAIS)

4.4.1. SIMBOLOGIA ADOTADA NO MODELO RELACIONAL

. James Martin

.

um opcional

um obrigatório

vários

N : N

1 : N

1 : 1

Bachman Notação de setas

57

4.4.2. ANÁLISE DA ENTIDADE NO D.E.R

Toda Entidade vai virar uma Tabela no D.T.R

4.4.3. ANÁLISE DE RELACIONAMENTO

As ligações entre as tabelas assumem um papel importante, pois ‚através delas que são representados os relacionamentos do modelo relacional.

Regra Geral : Toda vez que um relacionamento tiver atributo, este relacionamentovai ser representado por uma TabelaRepresentação 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 relações possuem a mesma chave primária.Há uma forte razão para unir as duas relações em uma só. Combinam-se

os atributos permanecendo uma única chave primária.

PRODUTO

#COD-PRODDESC-PROD

PRC-UNIT

ESTOQUE-PROD

#COD-PRODQTDE-EST

DATA-ULT-MOV

PRODUTO

#COD-PRODDESC-PROD

PRC-UNITQTDE-EST

DATA-ULT-MOV

58

B) - As duas relações possuem diferentes chaves primáriasB.1) - Pelo menos uma das entidades possue participação total no

relacionamento. O atributo Num-emp foi transposto para a relaçãodepartamento, com o objetivo de representar a restrição de que tododepartamento possui um gerente que é empregado da empresa.

B.2) - Ambas entidades possuem participação parcial no relacionamentoDefine-se uma terceira relação correspondendo ao relacionamento.

DEPTO CHEFIA EMPREGADO

DEPTO

#COD-DEPTONOME-DEPTO

NUM-EMP

1 1

EMPREGADO

#NUM-EMPNOME-EMP

HOMEM MULHERCASAMENTO

HOMEM

#CPF-HNOME-H

MULHER

#CPF-MNOME-M

HOMEM

#CPF-HNOME-H

CASAMENTO

#CPF-H#CPF-M

DATA-CAS

MULHER

#CPF-MNOME-M

1 1

59

4.4.3.2 – Mapeamento Relacionamento 1 p/ N

A) - A entidade do lado 1 possui participação total no relacionamento.A chave primária da relação do lado "um" é parte integrante da relação dolado muitos.

B) - A entidade do lado um possui participação parcial norelacionamento. Define-se uma terceira relação correspondendo aorelacionamento.

CLIENTE PEDIDOFAZ

CLIENTE

#COD-CLINOME-CLICGC-CLI

PEDIDO

#NRO-PEDDATA-PEDCOD-CLI

1 N

HOMEM MULHERCASAMENTO

HOMEM

#CPF-HNOME-H

MULHER

#CPF-MNOME-M

HOMEM

#CPF-HNOME-H

CASAMENTO

#CPF-H#CPF-M

DATA-CAS

MULHER

#CPF-MNOME-M

1 N

60

4.4.3.3 – Mapeamento Relacionamento N p/ N- Um relacionamento N:N sempre pode ser resolvido em dois relacionamentos1:N. Uma relação de interseção deverá ser implementada.

4.4.3.4 – Mapeamento Relacionamento Múltiplo

FORNECEDOR MATERIALFORNECIMENTO

PROJETO

N N

N

FORNECEDOR

#COD-FORNNOME-FORN

FORNECIMENTO

#COD-FORN#COD-MAT#COD-PROJ

QTDE

MATERIAL

#COD-MATDESC-MAT

PROJETO

#COD-PROJNOME-PROJ

FORNECEDOR MATERIALFORNECIMENTO

FORNECEDOR

#COD-FORNNOME-FORN

FORNECIMENTO

#COD-FORN#COD-MAT

QTDE

MATERIAL

#COD-MATDESC-MAT

N N

61

4.4.3.5 – Mapeamento Agregação

MEDICO PACIENTEATENDE

EXAME

SOLICITA

MEDICO

#COD-MEDNOME-MED

ATENDE

#COD-MED#COD-PAC

DATA-CONS

PACIENTE

#COD-PACNOME-PAC

SOLICTA

#COD-MED#COD-PAC

#COD-EXAMERESULTADO-EX

EXAME

#COD-EXAMEDESC-EXAME

N N

N

N

62

4.4.3.6 – Mapeamento Auto Relacionamento

DISCIPLINA

PRE-REQUISITO

DISCIPLINA

#COD-DISCNOME-DISC

PRE-REQUISITO

#COD-DISC-P#COD-DISC-S

DATA-PRE

NN

63

4.4.3.7 – Mapeamento Hierarquia de Classe

CLIENTE

TIPO FISCAL

PESSOA FÍSICA

PESSOA JURÍDICA

COD-CLI

NOME-CLI

CPF CGC

64

a) Mapear em uma única Relação

CLIENTE# COD-CLI NOME-CLI CPF-CLI /CGC-CLI

b) Mapear nas Subclasses as relações

PESSOA FÍSICA # COD-CLINOME-CLI CPF-CLI

PESSOA JURÍDICA# COD-CLI NOME-CLI CGC-CLI

c) Mapear como Relações distintas

CLIENTE# COD-CLI NOME-CLI

PESSOA FÍSICA # COD-CLI CPF-CLI

PESSOA JURÍDICA# COD-CLI CGC-CLI

65

4.5. RESTRIÇÕES DE INTEGRIDADE NO MODELO RELACIONAL

4.5.1. INTEGRIDADE LÓGICA

. Conjunto de regras que existem para o modelo de dados, assim como umconjunto de regras de negócio, que regem a manipulação do BD, de forma anão ferir nenhuma destas regras estabelecidas

4.5.2. INTEGRIDADE FÍSICA

. Conjunto de procedimentos operacionais que garantem a integridade do BD,mesmo em situações de falha de algum componente do ambiente onde o BD émanipulado

4.5.1- INTEGRIDADE LÓGICA

a) Restrição de ChaveUma relação deve ter pelo menos uma chaveb) Restrição de Integridade de EntidadeNenhum valor da chave primária de uma relação pode ser nulac) Restrição de Integridade de ReferênciaA chave estrangeira deve ter correspondência com a chave primária em outratabela ou ser nulad) Restrição de Integridade Semântica ou Regras do NegócioSão regras ditadas pelo negócio e não são mapeadas pelo M.E.R por se tratarde condições especiais

EX: . Valor mínimo de depósito 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, através domecanismo de Regras ou gatilhos (Triggers), hoje existentes no SQL

66

4.5.1.1 - INTEGRIDADE REFERENCIAL DE INSERÇÃO

1 - Respeitar as cardinalidades mínimas2 - Antes de INSERIR uma nova linha em uma tabela que contem um valor dechave estrangeira, é necessário que já exista uma linha em uma tabela com estevalor de chave primária.Caso contrário, a operação de INSERÇÃO deve ser rejeitada ou uma linhacom a chave primária deverá ser inserida na respectiva tabela.

DEPARTAMENTONUM-DEPTO

DESCRIÇÃO

100 R.H200 COBRANÇA300 INFORMÁTICA

FUNCIONÁRIONUM-FUNC

NOME NUM-DEPTO

9999 LUIZ 1008888 VERA 3009898 ALBERTO 200

4.5.1.2 - INTEGRIDADE REFERENCIAL DELEÇÃO

. Quando uma linha de uma tabela é deletada então:

a) Todas as ocorrências de chave estrangeira desta chave primária tambémdevem ser deletadas (CASCATA)b) Os valores de chave estrangeira devem ser atualizados para nulo(SETNULL)c) A operação de deleção pode ser rejeitada, se existir uma ocorrência de chaveestrangeira da chave primária a ser deletada. (RESTRITA)

67

4.5.1.3 - INTEGRIDADE REFERENCIAL ATUALIZAÇÃO:

. Se uma chave primária é atualizada, então

a) Mudar para nulas todas as ocorrências existentes de chave estrangeira comoantigo valorb)Mudar todas as ocorrências de chave estrangeira do antigo valor para o novovalorc)Rejeitar a atualização

68

SISTEMAS DE BANCOS DE DADOSFORMULÁRIOS PARA OS MODELOS CONCEITUAL E LÓGICO DE BANCO DE DADOS

Este texto visa apresentar os formulários usados para documentação do projeto deBanco de Dados.

Dentro do projeto pretende-se abordar duas fases básicas:- O Modelo Conceitual: um modelo de alto nível, independente da implementação. O

principal objetivo desta fase é uma produção de uma descrição formal dos dados levantados apartir dos requisitos dos usuários. O modelo adotado é o Modelo de Entidades eRelacionamentos (MER), estendido com o conceito de abstração de dados. Nesta fase égerado um Diagrama de Entedidades e Relacionamentos (DER).

- O Modelo Lógico: um modelo implementável, que seja processável por determinadaclasse de SGBD. O modelo adotado é o Modelo Relacional. Nesta fase do projeto é gerado umDiagrama de Tabelas Relacionais (DTR), derivado do DER da fase anterior. Durante o projetológico, deverão ser levadas em consideração as necessidades de processamento, anormalização dos dados e as restrições de integridade das tabelas.

A documentação do projeto de dados constará então de 3 formulários:a) O Modelo Conceitual de Dados (Anexo 1), composto pelo Diagrama de Entidades e

Relacionamentos (DER) - entidades, relacionamentos, cardinalidade, participação dasentidades nos relacionamentos, abstrações de dados (agregação,generalização/especialização).

b) O Modelo Relacional (Anexo 2), composto pelo Diagrama de Tabelas Relacionais(DTR), com a identificação das tabelas e das ligações entre as mesmas.

c) A Descrição da Tabela (Anexo 3), sendo usado um formulário para cada tabela,composto pela descrição dos dados da tabela e as restrições aplicáveis. As restrições paragarantir a integridade dos dados serão consideradas sob 3 aspectos:

- Integridade de chave:Em cada tabela será definida uma chave primária, com valores não-nulos.

- Restrição de existência:Devem ser analisadas as restrições no caso de inclusão de uma nova tupla

ou de alteração de uma tupla existente.Deve ser mantida a integridade referencial, no caso de tabelas que

possuam chaves estrangeiras.- Restrição de persistência:

Devem ser analisadas as restrições no caso de exclusão de uma tupla, afim de ser mantida a integridade referencial.

3 situações podem ser consideradas:

a) Remoção em CASCATA: propaga a remoção ocorrida em uma tabelapara as outras tabelas relacionadas através de uma chave estrangeira.

b) Bloqueio total (Regra Restrita): a remoção não é permitida se a tupla éreferenciada por outra tabela através de uma chave estrangeira; caso contrário aremoçao é permitida.

c) Nulificação (Regra SET NULL): a remoção de uma tupla que éreferenciada por outra tabela, através de uma chave estrangeira, implica ematribuir valores nulos para estas chaves estrangeiras.

69

Anexo 1Modelo de Dados Nome Sistema Data

CES Diagrama de Entidades e Relacionamentos - DER

70


CES Diagrama de Tabelas Relacionais - DTR

71


CES Descrição de Tabela- DT

Nome daTabela

Código daTabela

Descrição Sumária da Tabela

Composição da Tabela

Nome do Elemento de Dado Tipo Códigos para o Tipo de Elemento de Dado:CP - Chave PrimáriaCS - Chave SecundáriaPO - Preenchimento ObrigatórioCE - Chave Estrangeira

Restrições de Integridade da Tabela

Código daTabela

Código do Restrições em relação à Tabela Relacionada

Relacionada Relacionamento

XX YY Inclusão:Alteração:Exclusão:

72

Exercício Padrão – Seção Eleitoral

EXERCÍCIO - UMA SEÇÃO ELEITORAL

A narrativa a seguir descreve o funcionamento de uma seção eleitoral durante uma eleição:

Um eleitor fornece a sua identificação e esta é validada. Se for um eleitor válido ele recebeautorização para votar. Um eleitor válido é aquele cadastrado na seção, identificado pelo número de seuTítulo de elitor (Num_Tit_Ele). Para cada eleitor existem informações armazenadas: nome (Nome_Ele),Data de nascimento (Data_Nasc_Ele), Endereço(End_Ele), Zona Eleitoral(Num_Zona_Ele) e SeçãoEleitoral(Num-Seção_Ele).

Os votos recebidos são armazenados, sendo gerado um comprovante de votação, entregue aoeleitor. O voto é uma associação entre um eleitor com os candidatos. Cada voto tem uma data (Data_Vot)associada e é válido quando o candidato citado é válido. Os candidatos são identificados através de suainscrição na Justiça Eleitoral (Num_Insc_Cand), além de seu nome (Nome_Cand) e partido ao qual sefilia (Partido_Cand).

Se o eleitor não comparecer à seção para votar, ele pode justificar-se, enviando um documento àJustiça Eleitoral. Se a justificativa é aceita, ela é registrada, sendo gerado um comprovante dejustificativa, enviado ao eleitor. As justificativas são registradas através de um número de identificação,além de informações sobre o eleitor e do local de origem. Existem eleitores que não comparecem àvotação e que, ainda assim, não justificam sua abstenção.

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

1VALIDARELEITOR

ELEITOR

3GERAR

CONFIRMAÇÃOVOTO

4VALIADAR

JUSTIFICATIVA

5REGISTRAR

JUSTIFICATIVA

2REGISTRAR

VOTO

6GERAR

CONFIRMAÇÃPJUSTIFICATIVA

ELEITORES

ELEITORES

JUSTIFICATIVAS

VOTOS

CANDIDATOS

ELEITOR

ELEITOR NÃOAUTORIZADO

AUTORIZAÇÃO

IDENTIFICAÇÃOELEITOR

VOTO

CONFIRMAÇÃOVOTO

COMPROVANTEVOTO

JUSTIFICATIVA

JUSTIFICATIVANAO ACEITA

JUSTIFICATIVAACEITA

CONFIRMAÇÃOJUSTIFICATIVA

COMPROVANTEJUSTIFICATIVA

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

Modelo de Dados Nome Sistema DataCES Descrição de Tabela- DT Eleição MMM/AA

Nome daTabela

Eleitor Código daTabela

T1

Descrição Sumária da TabelaCadastro dos eleitores válidos


Nome do Elemento de Dado Tipo Códigos para o Tipo de Elemento de Dado:Num-Tit-Ele CP,PO CP - Chave PrimáriaNome-Ele PO CS - Chave SecundáriaData-Nasc-Ele PO PO - Preenchimento ObrigatórioEnd-Ele PO CE - Chave EstrangeiraNum-Zona-Ele PONum-Seção-Ele PO


Código daTabela

Código do Restrições em relação à Tabela Relacionada [ I - Inclusão A - AlteraçãoE - Exclusão]


T2 R2 I : Sem restriçõesA : Não é permitida a alteração da CPE : Restrita


77


Nome daTabela

Voto Código daTabela

T2

Descrição Sumária da TabelaVotos realizados pelos eleitores


Nome do Elemento de Dado Tipo Códigos para o Tipo de Elemento de Dado:Num-Tit-Ele CP,CE,PO CP - Chave PrimáriaNum-Insc-Cand CP,CE,PO CS - Chave SecundáriaData-Voto PO PO - Preenchimento Obrigatório

CE - Chave Estrangeira


Código daTabela

Código do Restrições em relação à Tabela Relacionada [ I - Inclusão A -Alteração E - Exclusão]


T1 R2 I : O eleitor deve estar cadastrado e não deve possuir nenhumajustificativaA : Não é permitida a alteração das CPE : Sem restrições

T3 R3 I : O candidato deve estar cadastradoA : Não é permitida a alteração das CPE : Sem restrições

78


Nome daTabela

Candidato Código daTabela

T3

Descrição Sumária da TabelaCandidatos cadastrados para a eleição


Nome do Elemento de Dado Tipo Códigos para o Tipo de Elemento de Dado:Num-Insc-Cand CP,PO CP - Chave PrimáriaNome-Cand PO CS - Chave SecundáriaPartido-Cand PO PO - Preenchimento Obrigatório

CE - Chave Estrangeira


Código daTabela

Código do Restrições em relação à Tabela Relacionada [ I - Inclusão A -Alteração E – Exclusão]



79


Nome daTabela

Justif Código daTabela

T4

Descrição Sumária da TabelaJustificativas apresentadas pelos eleitores ausentes à eleição


Nome do Elemento de Dado Tipo Códigos para o Tipo de Elemento de Dado:Num-Justif CP,PO CP - Chave PrimáriaLocal-Justif PO CS - Chave SecundáriaData-Justif PO PO - Preenchimento ObrigatórioMotivo-Justif PO CE - Chave EstrangeiraNum-Tit-Ele CE,PO


Código daTabela

Código do Restrições em relação à Tabela Relacionada [ I - Inclusão A -Alteração E - Exclusão]


T1 R1 I : O eleitor deve estar cadastrado e não deve possuir nenhum votoA : Não é permitida a alteração das chaves CP ou CEE : Sem restrições

80

4.6.LINGUAGENS RELACIONAIS

- FORMAIS ÁLGEBRACÁLCULO TUPLAS

DOMÍNIO- - COMERCIAIS SQL

QUEL (Linguagem Consulta) INGRES (1976)QBE (Query by Example) – IBM (1975)

HISTÓRICO. 1970: Edward F. Codd

Artigo Modelo Relacional de Dados para grandes BD compartilhados1º protótipo de um SGBD relacional. SYSTEM/R

. 1974/1975 : Criada a Linguagem SEQUEL

. 1975: QBE(Qurey by Example) - IBM

. 1976/1977: Versão SEQUEL/2 (alterado SQL)

. 1976: Criada a Linguagem QUEL - INGRES

. 1978/1979: ORACLE (Oracle Corporation)

. 1981: Diversos fabricantes lançam produtos baseados no SQL

. 1982: Criação comitê na ANSI para proposta padrão

. 1983: DB2 (IBM)

. 1986: O padrão ANSI SQL é utilizado – SQL 1

. 1988: DB2 versão 2 (IBM)

SQL 1: Padrão original não havia cláusula para especificar chave; modificadoem 1989SQL 2: aprovado em 1992: implementa conexão cliente/servidorSQL 3: em fase de aprovação; implementa o Modelo Orientado a Objeto

81

4.6.1 - ÁLGEBRA RELACIONAL

Matemáticamente falando, uma tabela (relação) é um conjunto , um conjuntode linhas.No modelo relacional temos o B.D. representado como uma coleção 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 operações e relações.

4.6.1.1 - Operações tradicionais- union- intersection- diference- cartesian

4.6.1.2- Operações 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 domínio, chave, ...)- Uma linguagem que seja pelo menos tão potente quanto a álgebra.

4.6.1.1 - Operações Tradicionais

. UNIONR1 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

. INTERSECTIONR1 intersection R2 giving R4

R4 COD NOME CIDADE

S1 JOAO RJ

. DIFERENCER1 diference R2 giving R5

R5 COD NOME CIDADE

S2 JOSE RJ

83

4.6.1.1 - Operações 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- Operações Especiais

. PROJECTProject R1 over Cod giving R9

R1 COD NOME R9 COD

F1 JOSE F1

F2 JOAO F2

F3 MARIA F3

F4 PEDRO F4

. SELECTSelect 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- Operações Especiais

. DIVIDEDivide 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 NATURALO JOIN na verdade duplica a coluna que ‚ passada como argumento. (

Nós adotamos que não )

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 JUNÇÃO baseada em igualdade de valores(EQUI-JOIN). Mas poderíamos ter JUNÇÃO "maior que", JUNÇÃO "nãoigual", etc...

Uma EQUI-JOIN com uma das colunas idênticas eliminadas chama-seJOIN NATURAL.

85

4.7.SQL (STRUCTURED QUERY LANGUAGE)

Mais que uma linguagem de consulta, oferece funções para DEFINIÇÃO,MANIPULAÇAO e CONTROLE dos dados de um Banco de dados.

DDL (Data Definition Language)

- CREATE : criação de novas estruturas- ALTER : alteração de estruturas- DROP : remoção de estruturas

DML (Data Manipulation Language)

- INSERT : Inserção de registros- DELETE : deleção de registros- UPDATE : atualização de registros- SELECT : Seleção de registros

DCL (Data Control Language)

- GRANT : concessão de privilégios a tabelas e visões- REVOKE : revogação de privilégios a tabelas e visões

Transaction Control

- COMMIT : efetiva uma alteração no banco de dados- ROLLBACK : desfaz uma alteração antes de ser efetivada no banco- SAVEPOINT : permite uma subdivisão lógica de uma transação longa

Restrições de integridade usando

-.STORED PROCEDURES-.TRIGGERS

86

Dicionário de Dados (Catálogo)

. É um BD de sistema, que pode ser consultado por meio de comandosSELECT da SQL, contendo:

.informações sobre as tabelas básicas

.as visões

.os direitos de acesso

.as identificações dos usuários, etc. Sua forma exata é uma característica de cada sistema e não da SQL

4.7.1 - DDL (DATA DEFINITION LANGUAGE)

a)CREATE

a-1) CREATE TABLE nome_tabela(nome_coluna tipo [(tamanho)] [restrição_coluna],nome_coluna tipo [(tamanho)] [restrição_coluna],[restrição_tabela] );

.restrição: É um mecanismo pelo qual você limita ou restringe o tipo de dadoque uma coluna pode armazenar.

.restrição_coluna: referencia somente uma coluna, aceitando todos os tipos derestrições.

[CONSTRAINT nome_restrição] tipo_restrição

.restrição_tabela: referencia uma ou mais colunas. Só não aceita o tipo NOTNULL.

[CONSTRAINT nome_restrição] tipo_restrição (coluna, ...)

Tipos de restrições[NOT] NULL :

Indica se a coluna pode ou não receber valores nulos. O default é NULLUNIQUE :

Indica que a coluna ou combinação de colunas não pode ter valoresrepetidos.

87

PRIMARY KEY :Indica que a coluna ou combinação de colunas forma a chave primária.

Chave Estrangeira

REFERENCES nome_tabela_pai(nome_coluna_pai)[ON DELETE CASCADE]

Usada a nível 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 nível de tabela, indica que a coluna ou combinação de colunas éuma chave estrangeira.

ON DELETE CASCADEIndica quando uma linha na tabela_pai é deletada haverá uma deleção das

linhas correspondentes (chave estrangeira) na tabela_filho.Obs : O default na ausência da clausula ON DELETE CASCADE é

RESTRICT...EExxiissttee aaiinnddaa ooppççããoo nnoo ppaaddrrããoo SSQQLL//22 OONN DDEELLEETTEE SSEETT NNUULLLL ee

OONN UUPPDDAATTEE CCAASSCCAADDEE..

CHECKNão permite que valores que violem a condição estabelecida sejam gravados nacoluna.

Tipos de dados permitidosCHAR(n): Tipo de dado caracter de tamanho fixo.VARCHAR(n): Tipo de dado caracter de tamanho variável, sendo sempredefinido seu tamanho máximo(n).NUMBER(n): Tipo numérico.NUMBER(p,q): Tipo numérico de ponto decimal (p : posições sendo q: casasdecimais).DATE: Tipo data

88

Exemplos

a) Restrições a nível 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) Restrições a nível 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_índiceON nome_tabela (nome_coluna1, nome_coluna2, ...);

Sugestões criação índices:. Colunas usadas frequentemente na cláusula WHERE. FOREIGN KEYS pois estão geralmente envolvidas em JOINS. PRIMARY KEYS e UNIKE KEYS (normalmente o Sistema criaautomaticamente um UNIQUE INDEX).

Exemplo:

CREATE INDEX emp_nome_emp_idxON emp (nome_emp);

Observações:1 – índices não podem ser alterados; devem ser removidos (com DROP) erecriados2 – A decisão de se usar ou não um índice em resposta a uma solicitaçãoespecífica de dado não é tomada pelo usuário mas sim pelo sistema

91

b)ALTER Comando usado para alterar a estrutura de uma tabela:

. adicionando ou alterando colunas.

. inserindo ou removendo restrições

b.1) Adicionando ou modificando colunas de uma tabelaALTER TABLE nome_tabela

[ ADD (nome_coluna tipo[(tamanho)],...)][ MODIFY (nome_coluna tipo[(tamanho)],...)]

Exemplo:ALTER TABLE emp

ADD (data_nasc_emp date);

ALTER TABLE empMODIFY (nome_emp(60) NOT NULL);

b.2) Adicionando ou removendo uma restrição de uma tabelaALTER TABLE nome_tabela

[ ADD restrição_tabela][ DROP PRIMARY KEY | UNIQUE (nome_coluna) |

CONSTRAINT nome_restrição [CASCADE] ];Exemplo:

ALTER TABLE deptoADD CONSTRAINT depto_local_depto_UK

UNIQUE (local_depto);

ALTER TABLE deptoDROP PRIMARY KEY CASCADE;Neste exemplo o comando remove a restrição PRIMARY KEY na tabela

Depto e remove a restrição FOREIGN KEY associada na tabela Emp.Obs : Aqui estamos removendo apenas as constraints associadas as

tabelas e não os registros de fato.

92

b.3) Habilitando e desabilitando uma restrição em uma tabela

ALTER TABLE nome_tabelaENABLE | DISABLE nome_restrição [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 também são excluídosDROP 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

restrições FOREIGN KEY que fazem referência a PRIMARY KEY destatabela.

Obs : Aqui CASCADE CONSTRAINTS desfaz apenas as restriçõesassociadas à chave primária e não excluiu os registros associados pelas chavesestrangeiras.

c.2) Exclui um índiceDROP 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 tabelaINSERT 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 gerenteSelect num_emp, nome_empFrom empWhere cargo_emp = ‘GERENTE’;

94

b)DELETE

DELETE FROM nome_tabela[WHERE condição] ;

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 tabelaUPDATE nome_tabela

SET nome_coluna = valor [, nome_coluna = valor][WHERE condição];

ExemploUPDATE emp

SET nome_emp = ‘JAIR BATISTA’ , sexo_emp = ‘M’WHERE num_emp = 1313;

Obs : Todas as linhas de uma tabela são atualizadas se você omitir a cláusulaWHERE.

c.2) Atualizar linhas a partir de uma SubqueryUPDATE nome_tabela

SET (nome_coluna, nome_coluna ...) =(SELECT nome_coluna, nome_coluna, ...

FROM nome_tabelaWHERE condição);

Exemplo:UPDATE emp

SET (cargo_emp, num_depto) =(SELECT cargo_emp, num_depto

FROM empWHERE num_emp = 1313)

WHERE num_emp = 1320;

96

d)SELECT

Comando usado para fazer consultas as bases de dados

d.1) Forma Básica:

SELECT [DISTINCT] nome_coluna [,nome_coluna...] FROM nome_tabela

Seleção de colunas específicas : Basta relacionar as colunas desejadasExemplo:

SELECT num_emp, nome_empFROM emp;

Seleção de todas as colunas : Substituir os nome das colunas por *Exemplo:

SELECT *FROM emp;

Evitando duplicações: Usar a palavra DISTINCT na cláusula SELECTExemplo:

SELECT DISTINCT nome_emp, cargo_empFROM emp;

Usando Pseudônimos: Uma consulta SQL normalmente usa o nome da colunacomo cabeçalho; é possível definir um pseudônimo para a coluna queaparecera no cabeçalhoExemplo:

SELECT num_emp “Numero do Empregado”FROM emp;

97

d.2) Uso cláusula WHEREUsada para filtrar um subconjunto de linhas de uma tabela

SELECT nome_colunasFROM nome_tabela

[WHERE condição]

Operadores:

= igual a< > diferente de> maior que< menor queBetween ... and... entre dois valoresIn(lista) qualquer valor da listaLike corresponde a um gabarito% : corresponde a uma seqüência de zero ou mais caracteres- : corresponde a um caracterIS NULL é valor nulo

Obs : Os quatro últimos podem ser negados através do operador NOT:. NOT BETWEEN, NOT IN , NOT LIKE, IS NOT NULL

Conjunção de Condições: várias condições podem ser conectadas na cláusulaWHERE usando o operador AND

Exemplo:WHERE nome_cargo = ‘GERENTE’ AND num_depto > 1000;

Disjunção de Condições : usando operador OR

Exemplo:WHERE num_depto = 1313 OR local_depto LIKE ‘_J %’;Obs: _ :primeira posição, J: segunda posição

98

d.3 ) Uso Cláusula ORDER BYOrdenando o resultado de uma consulta

SELECT nome_colunasFROM nome_tabela

[WHERE condição][ORDER BY {nome_coluna, ...} [ASC|DESC]]

Exemplo:ORDER BY nome_emp

d.4) Junção de TabelasAs linhas de uma tabela podem ser combinadas(JOIN) às linhas de outra tabelaatravés de valores comuns em colunas correspondentes.Exemplo:

SELECT emp_name, depto_nameFROM emp e, depto dWHERE e.num_depto = d.num_depto;

d.5) Produto CartesianoTodas as linhas da primeira tabela são combinadas com todas as linhas dasegunda tabela.Ocorre na omissão da cláusula WHERE.

Exemplo:Tabela EMP com 14 registrosTabela DEPTO com 4 registros

SELECT nome_emp, nome_deptoFROM emp, depto;

99

d.6) Funções de Manipulação de Valores

Operadores aritméticos

+ soma- subtração* multipllicação/ divisão

Funções Numéricas

SIGN(número) : -1 se negativo, 1 se positivo

MOD(dividendo, divisor) retorna o resto da divisão

ROUND (número, [n_casas]) retorna o numero arrendondado com n casas

TRUNC(número,[n_casas] retorna o número truncado com n casas

Funções Alfanuméricas

CHR(número) retorna o caracter cujo código ASCII seja igual ao númeroEx: CHAR(75) à k

LOWER(string) retorna a string toda em letra minusculaEx: LOWER(EXEMPLO FUNC) à exemplo func

UPPER(string) retorna a string toda em letra maisculaEx: UPPER(exemplo func) à EXEMPLO FUNC

LENGH(sring) retorna o tamanho da string

Funções de GrupoRetornam um valor para um grupo de linhas

SELECT função_grupo(nome_coluna)FROM nome_tabela[WHERE condição][ORDER BY nome_coluna]

100

Obs: Se a cláusula SELECT contiver funções de grupo, o resultado serásomente uma linha. Assim na cláusula SELECT não podem aparecer resultadosindividuais junto com expressões que contenham funções de grupo. Neste casodeveríamos usar GROUP BYExemplo : SELECT nome-emp, AVG(salario_emp)

FROM emp WHERE num_depto = 30;

COUNT(* | [DISTINCT] nome_coluna) : Retorna a quantidade de linhas dogrupo

COUNT(*) : inclui linhas duplicatas e linhas que contenham valores NULL.

COUNT(nome_coluna) : retorna o número de linhas com valores NOT NULLpara a coluna(expressão) especificada.

COUNT(DISTINCT nome_coluna) : retorna o número de linhas com valoresdistintos.

MAX([DISTINCT] expressão) : Retorna o valor máximo dessa expressão oucoluna dentro do grupo

MIN([DISTINCT] expressão) : Retorna o valor mínimo dessa expressão oucoluna dentro do grupo

SUM([DISTINCT] expressão) : Retorna o somatório da expressão de todas aslinhas do grupo

AVG([DISTINCT] expressão) : Retorna a média aritmética de todas as linhas.Valores NULL são ignorados.

AVG(NVL(nome_coluna,0)) : considera como zero os NULL na médiaaritmética.

101

d.7) Uso da Cláusula GROUP BYUsada para dividir as linhas de uma tabela em grupos menores.O SQL recupera cada grupo de linhas de acordo com os valores da(s)expressão(ões) especificada(s) na cláusula GROUP BY.

SELECT nome_colunas , função_de_grupo(nome_coluna)FROM nome_tabela

[WHERE condição][GROUP BY exp1, exp2...]

A cláusula GROUP BY deverá vir sempre após a cláusula WHERE (ou após acláusula FROM quando não existir WHERE)Quando a cláusula GROUP BY é utilizada é possível combinar resultadosindividuais com funções de grupo na cláusula SELECT.

Quando a cláusula GROUP BY é utilizada, é possível combinar resultadosindividuais com funções de grupo na cláusula SELECT, desde que aquelesresultados individuais sejam usados no GROUP BY.

ExemploSELECT num_ depto, COUNT(nome_emp)

FROM empGROUP BY num_depto;

Observação:Quando estiver usando o GROUP BY certifique-se que todas as colunas nãousadas na função de grupo estejam incluídas na clausula GROUP BY

Usando a cláusula WHERE você pode selecionar linhas antes de agrupar.

Usando GROUP BY para múltiplas colunas:SELECT num_depto, cargo_emp, SUM(salario_emp)

FROM empGROUP BY num_depto, cargo_emp;

102

d.8) Uso da Cláusula GROUP BY com HAVING

A cláusula WHERE não pode ser usada para restringir funções de grupo.Exemplo:

SELECT num_depto, AVG(salario_emp)FROM empWHERE AVG(salario_emp) > 2000GROUP BY num_depto;

Os grupos definidos pela cláusula GROUP BY podem ser filtrados pelacláusula HAVING.

Exemplo:

SELECT num_depto, AVG(salario_emp)FROM empGROUP BY num_deptoHAVING AVG(salario_emp) > 2000

SELECT nome_colunas , função_de_grupo(nome_coluna)FROM nome_tabela

[WHERE condição][GROUP BY exp1, exp2...][HAVING função_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_empHAVING SUM(salario_emp) > 5000ORDER BY SUM(salario_emp);

103

d.9) Uso de Subqueries

SubqueriesSão comandos SELECT que são utilizados em condições de cláusulas

WHERE ou HAVING para prover resultados que são utilizados para completara consulta principal.

Exemplo

SELECT nome_emp, cargo_empFROM empWHERE cargo_emp = ( SELECT cargo_emp

FROM empWHERE nome_emp = ‘JONES’);

Operadores ANY e ALLQuando a subquery retornar mais de um valor, os operadores ANY e ALLpodem ser utilizados para compatibilizar o resultado da subquery com o tipo dooperador de comparação.

Exemplosalario_emp > ANY <subquery>

Essa condição será verdadeira quando salario_emp for maior que qualquer umdos resultados da query.

salario_emp < ANY <subquery>Essa condição será verdadeira quando salario_emp for menor que qualquer umdos resultados da query.

salario_emp > ALL <subquery>Essa condição será verdadeira quando salario_emp for maior que todos osresultados da subquery.

salario_emp < ALL <subquery>Essa condição será verdadeira quando salario_emp for menor que todos osresultados da subquery.

104

Exemplo

SELECT num_emp, nome_emp, cargo_empFROM emp

WHERE salario_emp < ANY (SELECT salario_empFROM emp

WHERE cargo_emp = ‘GERENTE’);

Operadores IN e NOT INÉ igual para qualquer membro da lista

... WHERE cargo_emp IN (SELECT cargo_emp

FROM empWHERE nome_emp LIKE ‘A%’);

SELECT nome_emp, salario_empFROM empWHERE salario_emp IN (800, 950, 13000);

Operadores de ConjuntosComo o resultado de um query é um conjunto de linhas você pode realizaroperações de conjuntos entre queries:

UNION : União entre os resultados das queries;INTERSECT : Interseção entre os resultados das queries;MINUS : Subtração entre os resultados das queries.

105

ExemploSELECT nome_emp, cargo_emp, salario_emp

FROM empWHERE salario_emp IN(

SELECT salario_empFROM empWHERE nome_emp = ‘CARLOS’

UNIONSELECT salario_emp

FROM empWHERE nome_emp = ‘MARIO’);

Operador EXIST e NOT EXISTEXIST: retorna “verdadeiro” se uma determinada subquery retornar ao menosuma linha e “falso” caso contrárioNOT EXIST: retorna o resultado contrário do EXIST.

106

d.10) Criação e Uso de Visões

OBJETIVORestringir acesso à certas porções dos dados por questões de segurança. Pré definircertas consultas definindo tabelas virtuais que poderão ser utilizadas por outrasconsultas.

VISÃOPode ser vista como uma tabela virtual, isto é, uma tabela que realmente não existecomo tal, mas sim como derivação de uma ou + tabelas básicas.Uma definição da visão fica armazenada no dicionário, esta definição mostra comoela é derivada das tabelas básicas.

CRIAÇÃO

CREATE VIEW nome_visão [(nome_coluna [, nome_coluna..])]AS <SELECT ...>

Obs : Na cláusula AS a Subquerie não pode conter : ORDER BY

Exemplo

A) CREATE VIEW emp_visaoAS SELECT num_emp, nome_emp, cargo_empFROM emp WHERE cod_depto = 20;

B) Depois de criada uma visão, ela estará disponível no Dicionário de Dados;até este ponto a instrução SELECT não foi executada.

SELECT * FROM emp_visao;

REMOÇÃO

DROP VIEW <nome visão>

A definição será removida do Dicionário de Dados.

107

4.7.3. DCL (DATA CONTROL LANGUAGE)

Responsável pela segurança das informações no Banco de dadosInformando ao SGBD, quais operações que um usuário terá sobre umadeterminada tabela do BD

Quando um usuário cria seus objetos(tabelas, visões, procedures,...) diz-se que ele éo OWNER(dono) destes objetos.O conjunto de todos os objetos que pertencem a determinado usuário é chamado deESQUEMA deste usuário.

Para acessar os objetos de outro esquema( de outro usuário ) basta prefixar o nomedo objeto com o nome do usuário que o criou ( seu owner).

Exemplo

SELECT * FROM CARLOS.emp;

Você pode evitar a repetição da prefixação de uma tabela de outro usuário criandoum sinônimo para ela:

CREATE SYNONYM emp1FOR CARLOS.emp;

SELECT * FROM emp1;

a) Criação de objetos

a.1) Criação um usuário (CREATE USER)CREATE USER userIDENTIFIED BY password;

Exemplo:

CREATE USER carlos ALTER USER carlosIDENTIFIED BY solrac; IDENTIFIED BY newsenha;

O DBA cria o usuário e concede privilégios ao usuário que determinam o que esteusuário pode fazer a nível de Banco de dados

108

b) Concessão de privilégios (GRANT)

b.1) Concessão de privilégios de sistema

GRANT privilégio[, privilégio...]TO usuário[, usuário..]

privilégios: . CREATE SESSION, CREATE TABLE, CREATE SEQUENCE,CREATE VIEW, CREATE PROCEDURES.

Exemplo :GRANT create table, create viewTO carlos;

b.2) Concessão de privilégios sob objetos

O OWNER tem todos os privilégios de um objeto.

GRANT <lista_privilégios>ON objetoTO {<lista de usuários> | grupo | PUBLIC }[WITH GRANT OPTION];

109

lista_privilégiosSELECTINSERTUPDATEDELETEALTERINDEXALL

A opção WITH GRANT OPTION : permite que o usuário que está recebendoo privilégio, possa dar GRANT neste objeto a outros usuários.

Exemplo

GRANT SELECT, INSERTON deptoTO julio, mario;

c) Revogação de privilégios

REVOKE <lista_privilégios>ON objetoFROM {<lista_usuarios> | grupo | PUBLIC };

OBS : Privilégios concedidos a outros com a opção WITH GRANT OPTIONtambém serão revogados.

Exemplo

REVOKE SELECT, INSERTON deptoFROM mario;

110

4.7.4 - TRANSACTION CONTROL

A linguagem SQL possui também comandos que permitem o controle doresultado de uma transação.Uma transação é uma seqüência ATÔMICA de operações no BD que constituia unidade lógica de trabalho dos SGBDs.

Exemplo

Transferencia de dinheiro entre duas contas.Conta A = 1000 e Conta B = 2000 .Consistência Somatório Contas A e B igual 3000.

Transação de Transferência A à B

Passo 1 da transaçãoRead(A,a)a:= a-100Write(A,a)

Passo 2 da transaçãoRead(B,b)B:= b+100Write(B,b)

Imagine o que aconteceria se o primeiro passo fosse executado com sucesso,mas por algum motivo não fosse possível completar o segundo passo. Odinheiro da conta A haveria desaparecido e a consistência do BD estariacomprometida.

O esquema de transações garante que isso não acontecerá, pois enquanto oCOMMIT não for executado, as atualizações não serão efetivadas. No caso deuma falha, o primeiro passo seria desfeito.

111

a) COMMITSempre que um comando COMMIT é executado :

. A transação em andamento é implicitamente terminada.

. As alterações realizadas pelas transações são tornadas permanentes eirreversíveis.Os possíveis bloqueios que a transação mantinha são liberados.Apaga todos os savepoints.

b) ROLLBACK [to SAVEPOINT point_name]Sempre que um comando ROLLBACK é executado:

. Encerra a transação

. As alterações realizadas pela transação em andamento são desfeitascomo se nunca tivessem ocorrido.. Os possíveis bloqueios que a transação mantinha são desfeitos.. Apaga todos os SAVEPOINTs.

Se você executar comando ROLLBACK TO SAVEPOINT :. Desfaz todas as alterações até o SavePoint especificado.. Apaga todos os SavePoints criados após o especificado e mantém os

demais.

c)SAVEPOINT point_nameEm muitas implementações de SQL, existe o comando SAVEPOINT parapermitir a subdivisão lógica de transações longas.

112

Exemplo

INSERT UPDATE INSERT DELETE|<----------------------------------transação------------------------------------------- >|. Commit . Savepoint A . Savepoint B

< --------------------RollBack to Savepoint B

< ----------------------------------------------------------------------RollBack to Savepoint A

< ---------------------------------------------------------------------------------------------RollBack

Commit : Termina a corrente transação tornando permanentes as alterações.

Savepoint : Marca um Savepoint na corrente transação

RoolBack : Termina a corrente transação descartando todas as alterações nãoefetivadas.

RollBack to Savepoint name : descarta as alterações não efetivadas até osavepoint indicado

113

4.7.5 – RESTRIÇÕES DE INTEGRIDADE USANDO STORED PROCEDURES E

TRIGGERS

. Conforme foi mostrado anteriormente as restrições de integridade sãoespecificadas de forma declarativa no momento da definição dos dados(CREATE) ou depois (ALTER). SQL/92..Uma outra forma de especificar restrições de integridade é a formaprocedimental, através de TRIGGERS e STORED PROCEDURES.. A maioria dos SGBDs relacionais de ponta disponíveis no mercado suportaeste tipo de regras ativas mas infelizmente a SQL/92 não previu a suapadronização.

4.7.5.1 - STORED PROCEDURES

114

.Quando uma aplicação solicita a execução de uma QUERY, todo o texto damesma é enviado pela rede ao servidor onde será finalmente compilado eexecutado.. Stored Procedures são na verdade uma seqüência de comandos SQL,armazenados no Dicionário de Dados (DD), agrupados de forma que executar astored procedure é executá-los todos seqüencialmente no servidor. Podem ser também usadas para implementar regras de negócios que nãopodem ser especificadas declarativamente na descrição das tabelas.- - Criando uma Stored Procedured- CREATE PROCEDURE <Nome_procedure>

[(argumento [IN|OUT|IN OUT] tipo)]AS Comandos_SQL;

IN : argumento é de entradaOUT : argumento é de saídaIN OUT argumento é utilizado como entrada na chamada da procedure ecomo saída após sua execução.

115

a) Exemplo de procedure sem parâmetro

Criar uma procedure que aumente o salário dos empregados em 10%

CREATE PROCEDURE aumento_salarioASBEGIN

UPDATE empSET salario_emp = salario_emp * 1.1;

END;

EXEC aumento_salario;

b)Exemplo de procedure com parâmetro de input:

Criar uma procedure para aumentar os salários de apenas um departamento ecom um percentual diferente

CREATE PROCEDURE aum_sal_depto(var_depto IN number, percentual IN number)AS

BEGINUPDATE empSET 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

.São tipos especiais de Stored Procedures que são executados automaticamentepelo servidor quando um comando INSERT, UPDATE ou DELETE éexecutado em uma tabela ou visão..Permite especificar regras de negócios do tipo EVENTO-CONDIÇÃO-AÇÃO, em que o SGBD detecta a ocorrência de um EVENTO, avalia umaCONDIÇÃO no banco de dados e, se esta for satisfeita, executa uma AÇÃOpredeterminada.

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 (condição)] ]Comandos SQL

BEFORE : o trigger é disparado antes de executar o comando associado aotrigger (quando for necessário fazer algum pré-processamento antes docomando)AFTER: o trigger é disparado depois de executar o comando associado aotrigger

DELETE : o trigger é associado ao comando DELETEINSERT : : o trigger é associado ao comando INSERTUPDATE : o trigger é associado ao comando UPDATE. UPDATE OF associao trigger a colunas específicas; caso contrário, o trigger será associado àalteração de qualquer coluna

STATMENTEste trigger é disparado apenas uma vez.Exemplo:Se um comando UPDATE atualizar 15 linhas, os comandos contidosno trigger serão executados apenas uma vez, e não a cada linha processada.

ROWEsse trigger tem os seus comandos executados para todas as linhas que sejamafetadas pelo comando que gerou o acionamento do triggerDentro de um trigger do tipo ROW_LEVEL é possível acessar o valor de umcampo de uma linha. Normalmente é necessário preceder o nome da colunacom o sufixo :new ou :old, pois em determinado instante pode-se obter tanto ovalor antigo como o valor novo do campo.

118

No comando INSERT, os valores dos campos que serão gravados deverão serprecedidos pelo sufixo :new

No comando DELETE os valores dos campos da linha que está sendoprocessada devem ser precedidos do sufixo :old

No comando UPDATE, o valor original que será gravado é acessado com osufixo :old; os novos valores que serão gravados devem ser precedidos dosufixo :new

WHENSó é valida para FOR EACH ROWEspecifica a restrição do trigger, onde a condição é avaliada para cada linha ese a condição for verdadeira a expressão SQL associada ao trigger é executada.

119

a)Exemplo

Regra: Nenhum funcionário pode ganhar mais que oito mil reais.Além de ativar o trigger de inclusão (INSERT), evitando que um novofuncionário tenha um salário superior ao limite, as rotinas de atualização(UPDATE) devem ser verificadas para evitar que os salários dos funcionáriosexistentes sejam alterados para valores não permitidos.

CREATE TRIGGER testa_salarioBEFORE INSERT OR UPDATE OF salario_empON empFOR EACH ROWBEGIN

IF :NEW.salario_emp > 8000 THENraise_application_error (-20000, ‘valor incorreto’);

END IFEND;

Disparo do gatilho

UPDATE empSET salario_emp = 30000WHERE num-emp = 2500;

Saída do comando:Update emp

ERRO na linha 1ORA-20000 : valor incorretoORA-04088 : erro durante a execução do trigger ‘testa_salario’

120

b)ExemploApós incluir um registro na tabela emp vamos replicar este registro na tabelaempdup.

CREATE TRIGGER repins_empAFTER INSERT ON empFOR EACH ROWBEGIN

INSERT INTO empdupVALUES(: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 também na tabela repins_emp

INSERT INTO emp(1313, ‘CARLOS’, 4000,00 ,’M’, ‘GERENTE’, 30);

c)Exemplo

Após deletar um registro na tabela emp vamos deletar este registro na tabelaempdup.

CREATE TRIGGER repdel_empAFTER DELETE ON empFOR EACH ROWBEGIN

DELETE FROM empdupWHERE num_emp = :old.num_emp;

END;

121

d)Exemplo

Regra: Não é permitido aumentar o limite de crédito em mais de 50%.

CREATE TRIGGER T_monitora_limiteBEFORE UPDATE OF limite_creditoON contaREFERENCING OLD AS antes, NEW AS depoisFOR EACH ROWBEGIN

IF :depois.limite_credito > 1,5 * :antes.limite_credito THEN raise_application_error (-20001, ‘Aumento inválido);

END IFEND;

.Esta característica da SQL é fundamental em sistemas Cliente-Servidor.

.Uma regra de negócios global, válida para todo o banco de dados, pode serespecificada no servidor, não havendo a necessidade de ser replicada em todosos programas de aplicação que potencialmente possam violar a regra..Isto confere modularidade na especificação de regras, o que implica emfacilidade de manutenção, já que a regra é especificada apenas uma vez eautomaticamente executada no servidor.

Ativando/desativando um trigger

ALTER TRIGGER <nome-trigger> ENABLE/DISABLE;

Removendo um trigger

DROP TRIGGER <nome_trigger>;

122

Exercício:Suponhamos que exista uma regra no Banco de Dados BANCO: Quando umaregistro de PESSOA é excluído, seu CPF, nome e endereço devem sergravados num tabela de histórico EX_CLIENTES.

Com uso de STORED POCEDURECREATE PROCEDURE P_exclui_pessoa(X_CPF IN VARCHAR)ASX_Nome VARCHAR;X_End VARCHAR;BEGIN

SELECT nome, endereço INTO X_nome , X_endFROM pessoa WHERE CPF = X_CPF;

INSERT INTO ex_cliente VALUE (X_CPF, X_nome, X_end);DELETE FROM pessoa WHERE CPF = X_CPF;

EXCEPTIONWHEN NO_DATA_FOUND

THEN raise_application_error(-20002, ‘CPF inválido’);END exclui_pessoa;

Sendo assim qualquer exclusão de PESSOA deve ser feito através doprocedimento P_exclui_pessoa.

Com uso do TRIGGER T_exclui_pessoaCREATE TRIGGER T_exclui_pessoa

BEFORE DELETEON pessoaFOR EACH ROWBEGIN

INSERT INTO ex_clienteVALUES (:old.CPF, :old.nome, :old.endereco);

END T_exclui_pessoa;

A diferença entre P-exclui_pessoa e T_exclui_pessoa é que o trigger executa aregra automaticamente toda vez que um registro de PESSOA é excluído,enquanto o “procedure” requer uma chamada explícita do usuário ou de umaaplicação.

123

4.7.6 - SQL EMBUTIDA

As instruções da SQL EMBUTIDA são prefixadas por um sinal $(para quepossa ser facilmente reconhecida pelo pré compilador) e as instruções SQLpodem referenciar variáveis do programa utilizando o prefixo %Observação:Estes prefixos podem variar de linguagem para linguagem.1 - A instrução $SELECT inclui uma clausula INTO especificando variáveis asquais são atribuídos valores recuperados do BD.2 - A maioria das instruções SQL pode ser embutida em linguagenshospedeiras(COBOL, PASCAL, C, ...) de uma forma bastante direta (isto é,com apenas algumas alterações sobre sua sintaxe)Entretanto a instrução SQL SELECT faz com que seja retornada uma tabela aousuário(dai, conceito CURSOR: mecanismo que permite acesso aos registrosdo conjunto 1 por 1)

* DefiniçãoLET <cursor nome> BE <expressão>

* AtivaçãoOPEN <cursor nome>Posiciona antes do 1º registro que satisfaça a condição

* AvançoFETCH <cursor nome>Avança e extrai campos para INTO

* DesativaçãoCLOSE <cursor nome>

@ SQLCODE :Status da pesquisa :

0 ok!+100 problema

124

Exemplo 1

BD Empresa Bancária

Type Nome = String[25];Var Aumento : IntegerContinua : Char

D : RecordAnome, Cnome :Nome;

Conta :String[07];Saldo :Real;

end;

C : RecordCnome :Nome;Rua :String[20];Cidade :String[15];

end;

125

A) Segmento de programa que lê o Nome de um Cliente e imprime seuendereço.

$ DECLARE CLIENTE TABLE(Nome-Cliente :Char[50] NOT NULL, Rua-Cliente :Char[10], Cidade-Cliente :Char[10]);

C1: Continua := ‘S’;WHILE Continua = ‘S’ DOBEGIN

WRITELN(‘Entre com o nome do Cliente’);READLN(C.Cnome);$ SELECT Rua-Cliente, Cidade-ClienteINTO %C.Rua, %C.CidadeFROM CLIENTEWHERE 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 várias tuplas.O que fazer?Seja um Segmento de programa que lê um nome de agência e lista os Clientesque tem depósito nesta agência.Este segmento também lê uma quantidade utilizada para aumentar o saldo decada 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 DEPOSITOWHERE Nome-Agencia = % D.Anome

FOR UPDATE OF Saldo;$ OPEN DEPCUR;$ FETCH DEPCUR INTO %D.Conta, %D.Cnome,%D.Saldo;WHILE SQLCODE = 0 DOBEGINWRITELN(‘NomeEmpregado’,D.Cnome,D.Conta);

WRITELN(‘Entre com o aumento :’);READLN(Aumento);

$ UPDATE DEPOSITO SET Saldo=Saldo+%AumentoWHERE CURRENT OF DEPCUR;$ FETCH DEPCUR INTO %D.Conta,%D.Cnome,%D.Saldo;

END;$ CLOSE DEPCUR;

127

5. – EXERCÍCIOS:

5.1. – EXERCICIOS DE MODELAGEM DE DADOS

5.1.1.Projetos

Este texto descreve uma Empresa de Projetos de grande porte, envolvendo diversosprojetos como Engenharia, Urbanismo, Transporte. A Empresa é organizada em Deptos.Cada Depto coordena (é responsável) por vários projetos e um projeto é coordenadoobrigatoriamente por um único Depto.Cada Depto tem um Empregado que o gerencia. Um empregado deve pertencerobrigatoriamente a um Depto, mas pode estar alocado à vários Projetos.

5.1.2.Loja

Uma loja especializada em computadores resolveu automatizar seus procedimentos devenda e aluguel de computadores. Através de entrevistas com seu diretor, gerente efuncionários, observou o seguinte:Os clientes da loja podem alugar ou comprar computadores.Se o cliente faz opção por alugar então obrigatoriamente tem que fazer um contrato demanutenção 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 várias máquinas.Dado uma máquina de um determinado contrato este par pertence a várias máquinas.Dado um Cliente e uma máquina este par pertence a um único contrato.

5.1.3.A Universidade Milenium

Os diversos institutos da Universidade Milenium estão organizados em Departamentos.Cada departamento possui um corpo docente e um dos professores é o Chefe doDepartamento.Um Departamento é responsável pelo ensino de diversas disciplinas. Cada disciplinapode ser lecionada por vários professores. Um professor pode lecionar mais de umadisciplina.Os alunos cursam as disciplinas de acordo com os pré-requisitos já alcançados. Osalunos podem optar com qual professor ele cursará determinada disciplina.A Universidade mantém, para cada aluno, um Histórico Escolar, que relaciona asdisciplinas que ele já cursou, com as respectivas notas e a freqüência.

5.1.4.Controle de Projetos

Uma Empresa manufatureira funciona num esquema de Projeto, nos quais são alocadosseus empregados com um certo percentual de dedicação.Administrativamente, os empregados estão lotados em departamentos e podem gerenciarum ou mais projetos que são gerenciados por um único empregado.As Peças utilizadas nos projetos são armazenadas nos vários armazéns.A Empresa mantém um controle do fornecimento Efetivo de Peças feito aos projetospelos fornecedores, e um controle de fornecimento Potencial de Peças de cada umdos seus fornecedores.Deve-se controlar a composição das peças, onde uma peça pode ser simples ou composta.As peças compostas são montagens de peças simples. Cada peça simples pode serutilizada para compor várias peças compostas.

128

5.1.5. Empresa do ramo de alimentação

Deseja-se controlar as principais atividades de uma empresa do ramo de alimentação,que possui várias lojas de varejo e vários armazéns para guardar seus produtos. Estesarmazéns são especializados (por exemplo, frigorífico) de maneira que um produto sópode ser armazenado em um único armazém e um armazém pode armazenar vários produtos.As lojas podem emitir vários pedidos, sendo que um pedido deve pertencerobrigatoriamente a uma loja. Um Pedido é composto de vários produtos e um produtopode fazer parte de vários pedidos.Para entregar os pedidos a empresa conta com uma frota de caminhões dos mais variadostipos. Um caminhão pode atender a vários pedidos, e um pedido pode ser atendido pormais de caminhão (por exemplo, no caso em que pedido não caiba em um único caminhão).Observe que o sistema deve ser capaz de informar quais os produtos de determinadopedido estão em determinado caminhão. O sistema deve permitir ainda que existampedidos que não sejam atendidos por nenhum caminhão.Cada caminhão tem um obrigatoriamente um funcionário que é o responsável pelo mesmo,e um Funcionário pode ser responsável por mais de um caminhão.

5.1.6.Restaurante

Deseja-se desenvolver um Sistema de Controle das principais atividades de umrestaurante, atendendo às seguintes considerações:Os Clientes novos deverão ser cadastrados pelo sistema para efeito decorrespondências futuras, sendo necessário armazenar os dados pessoais. Sabe-se quecada cliente pode fazer vários pedidos, ou nenhum, e um pedido sempre estaráassociado a um único cliente.Um pedido está associado obrigatoriamente a vários itens de cardápio. Cada item docardápio pode estar associado a vários pedidos ou nenhum, sendo necessário armazenarquais itens foram pedidos, a quantidade de cada um e a data do pedido, a fim de que aconta, com o valor total, possa ser gerada no final do atendimento.Cada item do cardápio possui um código, um nome, um tipo (indicando se é bebida oucomida), uma descrição detalhada e um preço unitário.Cada pedido está obrigatoriamente associado a uma mesa, sendo possível associarvários pedidos a uma mesma mesa. Cada mesa é atendida por um único garçon, que podeatender a várias mesas. O número de identificação do garçon também deve constar naconta a ser gerada.

5.1.7.A cadeia de Hotéis Imperador

A cadeia de Hotéis Imperador possui diversos hotéis situados nas principais capitais.Cada hotel possui vários tipos de apartamento (simples, luxo, suite, etc.) e umapartamento, naturalmente, pertence a um único hotel.Toda vez que um cliente se hospeda, é necessário que ele informe o número da Carteirade Identidade ou Passaporte, endereço, data de nascimento e o sexo. Para controleinterno, o hotel também registra o número do quarto alocado e a data da hospedagem.Qualquer hotel da cadeia deve ser capaz de responder imediatamente a um pedido dereserva (efetivando-a ou negando-a). A data em que foi feita a reserva deve serregistrada.O hóspede pode utilizar os diversos serviços do hotel (lavanderia, sauna, etc.),pagando a conta apenas no check-out. Os serviços oferecidos por toda a cadeia dehotéis são padronizados.

129

5.1.8.Modelo para uma biblioteca

Uma Empresa possui uma Biblioteca para uso exclusivo dos seus empregados que podemlevar emprestado um número qualquer de exemplares, e fazer solicitações de empréstimo(RESERVA) quando não houver exemplar disponível.Os Livros são classificados em Categorias e em Subcategorias. Eles devem pertencer auma única categoria Principal e podem pertencer a várias Categorias Secundárias.Quando um Livro possui vários Autores um deles e referido como Autor Principal e osoutros como Co-Autores.

130

5.1 – EXERCÍCIOS DE NORMALIZAÇÃO:

5.2.1 - PEDIDOS(#Num-pedido, data-Pedido, Num-Cliente, Nome-Cliente,End-Cliente, ((Cod-Produto, nome-Produto, Preço-Unitário, 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-prestação, Valor-Prestação,Dt-Venc-prest)), Valor-Total-Contrato)

5.2.3 - EMPREGADO(#Cod-Empregado, Nome-Empregado, Título-Empregado, ((Cod-Curso,Nome-Curso, data-início-Curso, Resultado-Curso)))

5.2.4 - PEÇA-ESTOCADA(#Cod-Peça, #Cod-Armazem, Qtde-Estocada,Tel-armazem)

5.2.5 - QUADRO-PESSOAL#Cod-Orgão Nome-Orgão CARGO N vezes

Cod-CargoNome-CargoNúmero-VagasFUNCIONÁRIO N vezes

Matricula-EmpNome-EmpData-Posse

131

5.2.6 - DADOS-EMPREGADO#Matricula Nome Endereço Código-Cargo-Atual Nome-Cargo-Atual CURSOS N vezes

Cod-CursoNome-CursoData-ConclusãoNota-Final

HABILIDADES N vezesCod-HabilidadeNome-HabilidadeGrau-Habilitação

Data-Admissão Codigo-Orgão-Lotação Nome-Orgão-Lotação

5.2.7 – PROJETO#Cod-Proj Tipo-Proj Desc-Proj EMPREGADO N VEZES

Cod-EmpregadoNome-EmpCat-EmpSal-EmpData-ini-Proj

5.2.8 – ARQ_CANDIDATO#Cod-Curso Nome-Curso Num-Vagas-Curso CANDIDATO N VEZES

Cod-CandNome-CandEscore-Cand

132

5.2.9 – ARQ_ALUNO#Cod-Aluno Nome-Aluno CURSO N VEZES

Cod-CursoNome-CursoSem-Ingresso

DISCIPLINA N VEZESCod-DisciplinaNome-Disciplina

SEMESTRE-CURSADO N VEZESSem-Disc-CursadaNota-Disc

133

5.2 – EXERCÍCIOS DE SQL.

FORNECEDORCod_forn Nome_forn Status_forn Cidade_fornF1 PAVAN 20 JUIZ DE FORAF2 ABC 10 RIO DE JANEIROF3 TUCANO 30 RIO DE JANEIROF4 MATIASE 20 JUIZ DE FORAF5 RODOPAZ 30 SÃO PAULO

PEÇACod_peca Nome_peca Cor_pecaP1 PARAFUSO PRETAP2 PORCA AZULP3 ARRUELA BRANCAP4 PREGO PRETAP5 CANO VERDEP6 FIO AZUL

EMBARQUECod_Forn Cod_peca QtdeF1 P1 300F1 P2 200F1 P3 400F1 P4 200F1 P5 100F1 P6 100F2 P1 300F2 P2 400F3 P2 200F4 P2 200F4 P4 300F4 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_FKFOREIGN KEY (cod_peca)REFERENCES peca(cod_peca)

);

135

1) Obtenha o Código de todas as peças fornecidas

SELECT DISTINCT cod_peca FROM embarque;

2) Obtenha o código dos fornecedores do RIO DE JANEIRO com status > 20

SELECT cod_fornFROM fornecedorWHERE cidade = ‘RIO DE JANEIRO’ and status_forn > 20;

3) Obtenha o nome dos fornecedores que fornecem a peça P2

SELECT DISTINCT nome_forn FROM fornecedor F, embarque E WHERE F.cod_forn = E. cod_forn and

E.cod_peca = ‘P2’;

4) ORDER BYObtenha o código e o status dos fornecedores do RIO DE JANEIRO, por ordemdescendente 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 Peça fornecida, obtenha o número da Peça e a quantidade total fornecidadaquela Peça.

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 Peça P1, o2º Grupo contenha as linhas da Peça P2, eassim sucessivamente

A Clausula SELECT é então aplicada a cada Grupo da tabela particionada.

6) HAVINGObtenha os cod_peca das Peças, para todas Peças fornecidas por mais de umfornecedor

SELECT cod_peca FROM embarque GROUP BY cod_peca HAVING COUNT(*) > 1;

Funciona para Grupos da mesma forma que WHERE funciona para linha(SeHAVING for especificado, GROUP BY também tem que ser especificado).

137

7)COUNT

Obtenha o número total de fornecedores que estão efetivamente fornecendo Peças.

SELECT COUNT(DISTINCT cod_forn) FROM embarque;

8) LIKE

Obtenha todas as Peças, com nome começando com a letra C

SELECT cod_peca FROM peca WHERE nome_peca LIKE ‘C%’;

9) INObtenha o nome dos fornecedores que fornecem a Peça P2 .

SELECT nome_forn FROM fornecedor WHERE cod_forn IN

(SELECT cod_forn FROM embarque E WHERE E.cod_peca = ‘P2’);

138

5.3 - EXECÍCIOS DE ALGEBRA RELACIONAL

5.4.1 - Considere as seguintes relações

FORN #FN Fnome Fcidade PEÇA #PN Pnome Pcor1313 Pavan J. Fora P1 pia branca1320 ABC T.Rios P2 vaso bege1330 DEF J. Fora P3 sifão branca1350 Gil J. Fora P4 fio preto1360 Visart R.Janeiro

FORNECIMENTO #FN #PN QTDE1313 P1 251313 P2 201320 P2 251320 P3 201360 P3 251313 P4 20

A) Quais os nomes dos fornecedores que fornecem pelomenos 1 peça.

a.1) PROJECT FORNECIMENTO OVER FN GIVING R1a.2) JOIN FORN AND R1 OVER FN GIVING R2a.3) PROJECT R2 OVER Fnome GIVING R3

PRINT R3

a.1)R1 FN a.2) R2 FN Fnome Fcidade1313 1313 Pavan J. Fora1320 1320 ABC T. Rios1360 1360 Visart R. Janeiro

a.3)R3 FnomePavanABCVisart

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 R1PROJECT R1 OVER Fcidade GIVING R2

D) Encontre o nome dos fornecedores de J. Fora

SELECT FORN WHERE Fcidade=‘J. Fora’ giving R1PROJECT R1 OVER Fnome GIVING R2

E) Encontre o nome das Peças fornecidas pelofornecedor 1313

F) Obtenha o nome dos fornecedores que fornecema peça P2

140

5.4..2 Considere as seguintes relações

ALUNO #Matr Nome DISC#Codigo Nome9516001 Jose ADMP Administ.9516002 Juca LTPIV B.D9516003 Joao TAPII Projeto9616001 Pedro9616002 Carlos

APROVADO #Matr #Codigo Nota Falta9516001 LTPIV 55,0 29516001 TAPII 60,0 49516002 ADMP 80,0 09516002 LTPIV 90,0 19516002 TAPII 90,0 29516003 ADMP 70,0 2

A) Obter o nome dos alunos que já cursaram todas asdiciplinas.

141

5.4.3 - Considere as seguintes relações

DEPTO #DN Dnome Dlocal Dchefe1313 Informática RJ 113101320 Pessoal SP 115601350 Material SP 116001360 Contábil JF 11650

EMPREGADO #EN Enome Esalário DN11310 Carlos 5.000,00 131311530 Adriana 3.000,00 131311540 Léo 3.500,00 131311560 João 5.000,00 132011570 Júlio 3.000,00 132011600 Pedro 5.000,00 135011620 Alyne 3.000,00 135011630 Juca 8.000,00 135011650 Mário 5.000,00 136011700 Ricardo 3.000,00 136011750 Geraldo 7.000,00 1360

A)Obter o nome dos empregados que ganham mais do queseus chefes.

142

6. BIBLIOGRAFIA

1 – ELMASRI, Ramez e NAVATHE, Shamkant B. Fundamentals ofDatabase System. Third Edition. Ed. Addison-Wesley, 2000.

2 – KORTH, H. F. e SILBERSCHATZ, A. Sistemas de Banco deDados. Terceira edição Ed. McGraw Hill, 1999.

3 – HEUSER, Carlos Alberto.Projeto de Banco de Dados. PortoAlegre. Ed. Sagra Luzzato, 1998.

4 -DATE, C. J. Introdução a Sistemas de Banco de Dados, Rio deJaneiro, Ed. Campus, 1986.

5 - STEZER, Valdemar W.. Banco de Dados, São Paulo, Ed. EdgarBlucher, 1986.

6 - COUGO, Paulo. Modelagem Conceitual, Rio de Janeiro, Ed.Campus,1997.

7 - BARBIERI, Carlos. Modelagem de Dados, Rio de Janeiro, Ed. IBPIPress,1994.

8 - MACHADO, Felipe Nery R. Projeto de Banco de Dados umavisão prática, São Paulo, Ed. Érica, 1995.

9 - CERÍOLA, Vicente Osvaldo. Banco de dados relacional edistribuído, São Paulo, LTC, 1995.

10 - CHEN, Peter. Gerenciando Banco de Dados. A abordagementidade e Relacionamento, São Paulo, Ed. McGraw Hill, 1990

11 – Apostila Curso oracle(OR8) : SQL and PL/SQL, Volumes 1 e 2.Oracle Corporation, 1998

12 – Ramalho, José Antônio. Oracle 8i-Série Ramalho , São Paulo,1999.

13 – SUNDERRAMAN, Rajshekhar. Oracle Programming, GeórgiaEd. Addison-Wesley, 1999

1198893369_Apostila BD

Documents

Transcript of 1198893369_Apostila BD