banco de dados

Universidade Veiga de Almeida

Instituto de Ciência e Tecnologia

Modelagem e Projeto de Banco de Dados

e Sistemas de Gerenciamento de

Banco de Dados

Carlos Augusto B. Ribeiro Marcos Vinícius Ramos

Eduardo Corrêa Lima

Considerações Este conteúdo trabalho foi inicialmente elaborado pelo Coordenador e Professor Carlos Augusto B. Ribeiro. O professor Marcos Vinícius Ramos, DBA e especialista em ORACLE e SQL SERVER enriqueceu-a ainda mais e eu, inseri exercícios de modelagem conceitual, formas normais, engenharia reversa e diversos exemplos da linguagem SQL bem como modifiquei a forma de apresentação. Queremos aproveitar a oportunidade e dividir com vocês duas frases, que possivelmente permearão vários momentos das nossas vidas.

"Nada mais difícil de manejar, mais perigoso de conduzir ou de mais incerto sucesso, do que liderar a introdução de uma nova ordem de coisas. Pois, o inovador tem contra si todos os que se beneficiarão com a nova ordem".

NICOLAU MAQUIAVEL 1459 – 1527

“É muito melhor arriscar coisas grandiosas, alcançar triunfos e glórias, mesmo expondo-se à derrota, do que formar fila com os pobres de espírito que nem gozam muito nem sofrem muito, porque vivem nesta penumbra cinzenta que não conhece nem vitória nem derrota”.

THEODORE ROOSEVELT Esperamos que o material didático, que constantemente mantemos atualizado, seja útil para o seu aprendizado. Muito obrigado, Eduardo Corrêa Lima Carlos Augusto B. Ribeiro [email protected] [email protected]

Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos de dados, modelos para a construção de projetos físicos de banco de dados, técnicas de controle de dependência de dados e métodos de consultas. Para construção dos modelos lógicos, será estudado o modelo Entidade Relacionamento, utilizando a abordagem proposta em ELMAS89 que oferece uma notação rica em recursos, permitindo a modelagem de entidades normais, fracas, atributos simples, compostos, multivalorados, derivados e a modelagens de objetos mais complexos como classes e subclasses (modelo Entidade Relacionamento Estendido). Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por CODD. Para eliminar dependência de dados, utilizaremos a normalização, abordando a Primeira, Segunda e Terceira Formas Normais, propostas originalmente por COOD bem como a BCNF (Boyce-Cood Normal Form). Para a elaboração de consultas, será estudado a Álgebra Relacional, que nada mais é do que uma forma canônica para as linguagens de consulta e a linguagem de consultas SQL, padrão mundial nos gerenciadores de Bancos de Dados mais utilizados no mercado.

Universidade Veiga de Almeida Instituto Superior Politécnico

Sistemas de Gerenciamento de Banco de Dados

4

Capítulo 1

Introdução e Conceitos Gerais



6

Introdução e Conceitos Gerais A tecnologia aplicada aos métodos de armazenamento de informações vem crescendo e gerando um impacto cada vez maior no uso de computadores, em qualquer área em que os mesmos podem ser aplicados. Um banco de dados pode ser definido como um conjunto de dados devidamente relacionados. Por dados podemos compreender como fatos conhecidos que podem ser armazenados e que possuem um significado implícito. Porém, o significado do termo “banco de dados” é mais restrito que simplesmente a definição dada acima. Um banco de dados possui as seguintes propriedades: - um banco de dados é uma coleção lógica coerente de dados com um

significado inerente; uma disposição desordenada dos dados não pode ser referenciada como um banco de dados;

- um banco de dados é projetado, construído e povoado com dados para

um propósito específico; um banco de dados possui um conjunto pré definido de usuários e aplicações;

- um banco de dados representa algum aspecto do mundo real, o

qual é chamado de mini mundo; qualquer alteração efetuada no mini mundo é automaticamente refletida no banco de dados.

Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas especialmente para esta tarefa ou por um Sistema Gerenciador de Banco de Dados (SGBD). Um SGBD permite aos usuários criarem e manipularem bancos de dados de propósito geral. O conjunto formado por um banco de dados mais as aplicações que manipulam o mesmo é chamado de Sistema de Banco de Dados. Banco de Dados X Processamento Tradicional de Arquivos Auto Informação Uma característica importante da abordagem Banco de Dados é que o SGBD mantém não somente os dados, mas também a forma como os mesmos são armazenados, contendo uma descrição completa do banco de dados. Estas informações são armazenadas no catálogo do SGBD, o qual contém informações, como a estrutura de cada arquivo, o tipo e o formato de armazenamento de cada tipo de dado, restrições, etc. A informação armazenada no catálogo é chamada de Meta Dados. No processamento tradicional de arquivos, o programa que irá manipular os dados deve conter este tipo de informação, ficando limitado a manipular as informações que o mesmo conhece. Utilizando a abordagem banco de dados, a aplicação pode manipular diversas bases de dados diferentes.



7

Separação entre Programas e Dados No processamento tradicional de arquivos, a estrutura dos dados está incorporada ao programa de acesso. Desta forma, qualquer alteração na estrutura de arquivos implica na alteração no código fonte de todos os programas. Já na abordagem banco de dados, a estrutura é alterada apenas no catálogo, não alterando os programas.

Figura 1 Abstração de Dados O SGBD deve fornecer ao usuário uma representação conceitual dos dados, sem fornecer muitos detalhes de como as informações são armazenadas. Um modelo de dados é uma abstração de dados que é utilizada para fornecer esta representação conceitual utilizando conceitos lógicos como objetos, suas propriedades e seus relacionamentos. A estrutura detalhada e a organização de cada arquivo são descritas no catálogo. Múltiplas Visões de Dados Como um conjunto de informações pode ser utilizado por um conjunto diferenciado de usuários, é importante que estes usuários possam ter visões diferentes da base de dados. Uma visão é definida como um subconjunto de uma base de dados, formando deste modo, um conjunto virtual de informações. Usuários Para um grande banco de dados, existe um grande número de pessoas envolvidas: os encarregados com o projeto, quem o utiliza e os responsáveis pela manutenção.

Software paraprocessar amanipulação

Software paraacesso aos

dados

Programas deAplicação/Consulta

Sistema de Bancos de Dados

DadosMeta-Dados



8

Administrador de Banco de Dados (DBA) Em um ambiente de banco de dados, o SGBD é o recurso primário e os SOFTWARES de apoio são os recursos secundários. A administração destes recursos cabe ao Administrador de Banco de Dados, o qual é responsável pela autorização de acesso ao banco de dados e pela coordenação e monitoração de seu uso. Administrador de Dados (DA) O Administrador de Dados (DA ou AD) é responsável pela identificação dos dados que devem ser armazenados no banco de dados, escolhendo a estrutura correta para representar e armazenar dados. Muitas vezes, os administradores de dados atuam como STAFF do DBA, assumindo outras responsabilidades após a construção do banco de dados. É função do administrador de dados também avaliar as necessidades de cada grupo de usuários para definir as visões que serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usuários. Usuários Finais Existem basicamente três categorias de usuários finais que são os usuários finais do banco de dados, fazendo consultas, atualizações e gerando documentos: - Usuários casuais: acessam o banco de dados casualmente, mas que

podem necessitar de diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades;

- Usuários novatos ou paramétricos: utilizam porções pré definidas do

banco de dados, utilizando consultas preestabelecidas que já foram exaustivamente testadas;

- Usuários sofisticados: são usuários que estão familiarizados com o

SGBD e realizam consultas complexas. Analistas de Sistemas e Programadores de Aplicações Os analistas determinam os requisitos dos usuários finais e desenvolvem especificações para transações que atendam estes requisitos, e os programadores implementam estas especificações como programas, testando, depurando, documentando e dando manutenção no mesmo. É importante que, tanto analistas quanto programadores, estejam a par dos recursos oferecidos pelo SGBD. Vantagens e desvantagens do uso de um SGBD



9

Controle de Redundância No processamento tradicional de arquivos, cada grupo de usuários deve manter seu próprio conjunto de arquivos e dados. Desta forma, acabam ocorrendo redundâncias que prejudicam o sistema com problemas como: Toda vez que for necessário atualizar um arquivo de um grupo, então todos os grupos devem ser atualizados para manter a integridade dos dados no ambiente como um todo; A redundância desnecessária de dados leva ao armazenamento excessivo de informações, ocupando espaço que poderia estar sendo utilizado com outras informações. Compartilhamento de Dados Um SGBD multiusuário deve permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Este fator é essencial para que múltiplas aplicações integradas possam acessar o banco. O SGBD multiusuário deve manter o controle de concorrência para assegurar que os resultados de atualizações sejam corretos. Um banco de dados multiusuário deve fornecer recursos para a construção de múltiplas visões. Restrição a Acesso não Autorizado Um SGBD deve fornecer um subsistema de autorização e segurança, o qual é utilizado pelo DBA para criar contas de usuários e especificar as restrições destas contas; o controle de restrições se aplica tanto ao acesso aos dados (segurança lógica) quanto ao uso de software inerentes ao SGBD e acesso físico à instalação do servidor e/ou servidores de bancos de dados (segurança física). Representação de relacionamentos complexos entre dados Um banco de dados pode incluir uma variedade de dados que estão inter-relacionados de várias formas. Um SGBD deve fornecer recursos para se representar uma grande variedade de relacionamentos entre os dados, bem como, recuperar e atualizar os dados de maneira prática e eficiente. Tolerância a falhas Um SGBD deve fornecer recursos para recuperação de falhas tanto de software quanto de hardware. Quando não utilizar um SGBD Em algumas situações, o uso de um SGBD pode representar uma carga desnecessária aos custos quando comparado à abordagem processamento tradicional de arquivos, por exemplo:



10

- Alto investimento inicial na compra de software e hardware adicionais; - Generalidade que um SGBD fornece na definição e processamento de

dados; - Sobrecarga na provisão de controle de segurança, controle de

concorrência, recuperação e integração de funções. Problemas adicionais podem surgir caso os administradores de dados ou os administradores de banco de dados não elaborem os projetos corretamente ou se as aplicações não são implementadas de forma apropriada. Se o DBA não administrar o banco de dados de forma correta, tanto a segurança quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má administração justificam a utilização da abordagem processamento tradicional de arquivos em casos como: - O banco de dados e as aplicações são simples, bem definidas e não se

esperam mudanças no projeto; - A necessidade de processamento em tempo real de certas aplicações,

que são terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;

- Não haverá múltiplo acesso ao banco de dados. Conceitos e Arquiteturas de um SGBD Modelos de Dados Definição: conjunto de conceitos que descrevem a estrutura lógica e física de um banco de dados. Uma das principais características da abordagem banco de dados, é que a mesma fornece alguns níveis de abstração de dados omitindo ao usuário final, detalhes de como estes dados são armazenados. Um modelo de dados é um conjunto de conceitos que podem ser utilizados para descrever a estrutura lógica e física de um banco de dados. Por estrutura podemos compreender o tipo dos dados, os relacionamentos e as restrições que podem recair sobre os dados. Os modelos são classificados basicamente em três tipos: - Modelo de dados conceitual (alto nível), que fornece uma visão mais

próxima do modo como os usuários visualizam os dados realmente (Entidades e relacionamentos);

- Modelo de dados lógico (nível intermediário), que fornece uma visão

lógica da derivação das estruturas conceituais (Tabelas e chaves);



11

- Modelo de dados físico (baixo nível), que fornece uma visão mais detalhada do modo como os dados estão realmente armazenados no computador (Tabelas, índices, chaves, arquivos físicos, memória, etc.).

Esquemas e Instâncias Em qualquer modelo de dados utilizado, é importante distinguir a descrição do banco de dados do próprio SGBD. A descrição de um banco de dados é chamada de esquema de um banco de dados e é especificada durante o projeto do banco de dados. Geralmente, poucas mudanças ocorrem no esquema do banco de dados. Os dados armazenados em um banco de dados em um determinado instante do tempo formam um conjunto chamado de instância do banco de dados. A instância altera toda vez que uma alteração no banco de dados é feita. O SGBD é responsável por garantir que toda instância do banco de dados satisfaça ao esquema do banco de dados, respeitando sua estrutura e suas restrições. O esquema de um banco de dados também pode ser chamado de intenção de um banco de dados e a instância de extensão de um banco de dados. A Arquitetura Três Esquemas A principal meta da arquitetura três esquemas é separar as aplicações do usuário do banco de dados físico. Os esquemas podem ser definidos como: - Nível interno: ou esquema interno, o qual descreve a estrutura de

armazenamento físico do banco de dados; utiliza um modelo de dados e

Criação das tabelas

Requisitos do modelo conceitual (ERA)

Expressividade: grau de detalhamentoLegibilidade: todos devem entenderFlexibilidade: permitir mudançasMinimalidade: evitar redundânciasCorreção: utilizar a simbologia corretaCompleteza: atender às Regras de Negócioe aos Requisitos de Informação

- Entrevistas, questionários, observações diretas- Regras de Negócio- Requisitos de Informação

Transformação do ERA em tabelas

Modelo Descritivo

Modelo Conceitual

Modelo Lógico

ModeloFísico



12

descreve detalhadamente os dados armazenados e os caminhos de acesso ao banco de dados;

- Nível conceitual: ou esquema conceitual, o qual descreve a estrutura do banco de dados como um todo; é uma descrição global do banco de dados, que não fornece detalhes do modo como os dados estão fisicamente armazenados;

- Nível externo: ou esquema de visão, o qual descreve as visões do banco de dados para um grupo de usuários; cada visão descreve quais porções do banco de dados um grupo de usuários terá acesso.

Figura 3 Independência de Dados A independência de dados pode ser definida como a capacidade de se alterar um esquema em um nível em um banco de dados sem ter que alterar um nível superior. Existem dois tipos de independência de dados: - Independência de dados lógica: é a capacidade de alterar o esquema

conceitual sem ter que alterar o esquema externo ou as aplicações do usuário.

- Independência de dados física: é a capacidade de alterar o esquema

interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário.

As Linguagens para uso em bancos de Dados Para a definição dos esquemas conceitual e interno utiliza-se uma linguagem chamada DDL - DATA DEFINITION LANGUAGE - Linguagem

Visão externa Visão externa

EsquemaConceitual

EsquemaInterno

UsuáriosFinais

Banco de dados armazenado

Mapeamento conceitual externo

Mapeamento conceitual internoNível interno

Nível conceitual



13

de Definição de Dados. O SGBD possui um compilador DDL que permite a execução das declarações para identificar as descrições dos esquemas e para armazená-las no catálogo do SGBD. A DDL é utilizada nos SGBD, onde a separação entre os níveis interno e conceitual não é muito clara. Em um SGBD em que a separação entre os níveis conceitual e interno é bem clara, é utilizada uma outra linguagem, a SDL (STORAGE DEFINITION LANGUAGE - Linguagem de Definição de Armazenamento) para a especificação do esquema interno. A especificação do esquema conceitual fica por conta da DDL. Em um SGBD que utiliza a arquitetura três esquemas, é necessária a utilização de mais uma linguagem para a definição de visões, a VDL (VISION DEFINITION LANGUAGE - Linguagem de Definição de Visões). Uma vez que o esquema esteja compilado e o banco de dados esteja povoado, utiliza-se uma linguagem para fazer a manipulação dos dados, a DML (DATA MANIPULATION LANGUAGE - Linguagem de Manipulação de Dados). Os Módulos Componentes de um SGBD Um SGBD é um sistema complexo, formado por um conjunto muito grande de módulos. A figura 4 mostra um esquema da estrutura de funcionamento de um SGBD.

Figura 4

S G B D

UsuáriosSimples

Programadoresde Aplicação

Usuáriosocasionais DBA

Programasde Aplicação

Chamadas deRotina Consultas Esquemas de

bancos de dados

Pré-compilador dalinguagem de

manipulação de dados

Processador daConsultas

Compilador dalinguagem de

Definição de Dados

Código objeto dos programasde aplicação

Gerenciador de Bancos de Dados

Gerenciador deArquivos Arquivos

de dados Dicionáriode dados

Memóriade disco



14

Classificação dos SGBD O principal critério para se classificar um SGBD é o modelo de dados no qual é baseado. Existe o modelo hierárquico, e de rede e a grande maioria dos SGBD contemporâneos que são baseados no modelo relacional, alguns em modelos conceituais e alguns em modelos orientados a objetos. Modelo Hierárquico O modelo de dados Hierárquico está baseado na estrutura de dados: REGISTROS e relacionamentos PAI-FILHO, que consiste em uma coleção de registros conectados a outro através de ligações que representam o relacionamento PAI-FILHO.

Figura 5 Cada registro é composto por uma coleção de atributos mono valorados. O relacionamento PAI-FILHO é do tipo 1:N entre dois tipos de registro: o tipo do registro do lado 1 é chamado de PAI enquanto que o registro do lado N é chamado de FILHO. Este modelo apresenta problemas para representar relacionamentos M:N. No exemplo de banco de dados da figura 5, seria mais fácil obter as informações das visitas dos médicos efetuadas ao paciente 10 – José e mais complicado saber quais pacientes foram visitados pelo médico 1 – Fred. Modelo de Rede É baseado na estrutura de dados de REGISTROS e CONJUNTOS DE DADOS. Diferentemente do modelo Hierárquico, suporta tipos de dados complexos: vetores e grupos (atributos compostos). Veja o atributo ENDEREÇO no exemplo a seguir.

Cardiologia

10 José 11 Maria 12 João

1 Fred3 Carlos

2 Júlio

1 Fred

Divisão do Hospital

Pacientes

Médicos



15

Também é capaz de representar relacionamentos M:N. Estes relacionamentos podem ser simulados no modelo hierárquico pela duplicação de registros. Suporta o tipo de manipulação (DML) que trata um registro por vez, com linguagens de propósito geral (COBOL) chamada de linguagem HOST. No exemplo da figura 6, estão representados, com o diagrama de BACHMAN, o registro do tipo PACIENTE (proprietário) e o registro do tipo MÉDICO (membro).

Figura 6 Outras classificações - quanto aos Usuários: um SGBD pode ser mono-usuário, normalmente

utilizado em computadores pessoais (também chamados DESKTOP) ou multiusuário, utilizado em estações de trabalho, minicomputadores e máquinas de grande porte;

- quanto à Localização: um SGBD pode ser localizado (também

chamado centralizado) ou distribuído; se ele for localizado, então todos os dados estarão em uma máquina (ou em um único disco) ou distribuído, onde os dados estarão distribuídos por diversas máquinas (ou diversos discos);

- quanto ao Ambiente: homogêneo é o ambiente composto por um

único SGBD e um ambiente heterogêneo é composto por diferentes SGBD.

Modelagem de Dados Conceitual de Alto Nível O Modelo Entidade e Relacionamento (MER) O modelo Entidade Relacionamento é um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais próximo possível da visão que o usuário tem dos dados, não se preocupando em representar como estes dados estarão realmente armazenados. O modelo ER é utilizado principalmente durante o processo de projeto de banco de dados.

Paciente

Endereço

CEPCidadeRuaNome

Medicado por

CPF

Médico

DivisãoNome



16

Entidades e Atributos O objeto básico tratado pelo modelo ER é a entidade, que pode ser definida como um objeto do mundo real, concreto ou abstrato e que possui existência independente. Cada entidade possui um conjunto particular de propriedades que a descreve chamado de atributos. Um atributo pode ser dividido em diversas partes com significado independente entre si, recebendo o nome de atributo composto. Um atributo que não pode ser subdividido é chamado de atributo simples ou atômico. O atributo que pode assumir apenas um determinado valor em uma determinada instância é denominado atributo simplesmente valorado, enquanto que um atributo que pode assumir diversos valores em uma mesma instância é denominado atributo multivalorado. Um atributo que é gerado a partir de outro atributo é chamado de atributo derivado. TIPOS ENTIDADE, Conjunto de Valores, Atributo Chave Um banco de dados costuma conter grupos de entidades que são similares, possuindo os mesmos atributos, porém, cada entidade com seus próprios valores para cada atributo. Este conjunto de entidades similar define um TIPO ENTIDADE. Cada TIPO ENTIDADE é identificado por seu nome e pelo conjunto de atributos que definem suas propriedades. A descrição do TIPO ENTIDADE é chamada de esquema do TIPO ENTIDADE, especificando o nome do TIPO ENTIDADE, o nome de cada um de seus atributos e qualquer restrição que incida sobre as entidades. Uma restrição muito importante em uma entidade de um determinado TIPO ENTIDADE é a chave. Um TIPO ENTIDADE possui um atributo cujos valores são distintos para cada entidade individual. Este atributo é chamado atributo chave ou atributo identificador e seus valores podem ser utilizados para identificar cada entidade de forma única. Muitas vezes, uma chave pode ser formada pela composição de dois ou mais atributos. Uma entidade pode também ter mais de um atributo chave. Cada atributo simples de um TIPO ENTIDADE está associado com um conjunto de valores denominado domínio, o qual especifica o conjunto de valores que podem ser designados para este determinado atributo para cada entidade.

Figura 7

Entidade

Chave Primária (matrícula)

Atributo derivado (dígito)

Atributo ou propriedade (nome)

Atributo multi-valorado (telefone)(0,n)

Atributo composto (endereço)



17

Tipos e Instâncias de Relacionamento Além de conhecer detalhadamente os TIPOS ENTIDADE, é muito importante conhecer também os relacionamentos entre estes TIPOS ENTIDADE. Um TIPO RELACIONAMENTO entre entidades é um conjunto de associações entre TIPOS ENTIDADE. Informalmente falando, cada instância de relacionamento r1 em R é uma associação de entidades, onde a associação inclui exatamente uma entidade de cada TIPO ENTIDADE participante no TIPO RELACIONAMENTO. Isto significa que estes TIPOS ENTIDADE estão relacionadas de alguma forma no mini mundo. A figura 8 mostra um exemplo entre dois TIPOS ENTIDADE (Produto e Cliente) e o relacionamento entre eles (Venda). Repare que para cada relacionamento, participam apenas uma entidade de cada TIPO ENTIDADE, porém, uma entidade pode participar de mais do que um relacionamento.

Figura 8 Grau de um Relacionamento O grau de um TIPO RELACIONAMENTO significa o número de TIPOS ENTIDADE que participam do TIPO RELACIONAMENTO. No exemplo da figura 8, temos um relacionamento binário. O grau de um relacionamento é ilimitado, porém, a partir do grau 3 (ternário), a compreensão e a dificuldade de se desenvolver a relação corretamente se tornam extremamente complexas, conforme demonstrado nas figuras 9 e 10. Sempre que possível, modelar os relacionamentos ternários (ou superiores) em uma AGREGAÇÃO e relacioná-la com a terceira TIPO ENTIDADE, conforme demonstrado nas figuras 9 e 10.

Figura 9

Produto

código

(1,n)

descrição

Venda Cliente

CPF

(1,n)

nomedata da venda

Médico

CRM

(1,n)

nome

Consulta Paciente

CPF

(1,n)

nomedata

Senha

(0,1)



18

Figura 10 Outras Características de um Relacionamento Relacionamentos como Atributos Algumas vezes é conveniente pensar em um relacionamento como um atributo. Considere o exemplo da figura anterior. Podemos pensar departamento como sendo um atributo da entidade empregado, ou empregado, como um atributo multivalorado da entidade departamento. Se uma entidade não possuir existência muito bem definida, talvez seja mais interessante que ela seja representada como um atributo, para a manter a coesão do modelo lógico.

Figura 11 Nomes de Papéis e Relacionamentos Recursivos Cada TIPO ENTIDADE que participa de um TIPO RELACIONAMENTO desempenha um papel particular no relacionamento. O nome do papel representa a atuação desempenhada pela TIPO ENTIDADE no relacionamento. No exemplo da figura abaixo, nós temos o papel supervisor ou supervisionado para o TIPO ENTIDADE FUNCIONÁRIO. Nomes de papéis não são necessariamente importantes quando todas as entidades participantes desempenham papéis diferentes. Algumas vezes, o papel torna-se essencial para distinguir o significado de cada participação. Isto é muito comum em relacionamentos recursivos.

Médico

CRM

(1,n)

nome

Consulta Paciente

CPF

(1,n)

nomedata

Senha

Liberação

(1,1)

(0,1)

Depto

código

(1,n)

descrição

Empregado

CPF

(1,1)

nome



19

Um relacionamento recursivo é um relacionamento entre entidades do mesmo TIPO ENTIDADE. Veja o exemplo das figuras 12, 13, 14 e 15 a seguir. O relacionamento recursivo também é conhecido como auto relacionamento.

Figura 12

Figura 13

Figura 14

Figura 15 Cobertura Resumidamente, cobertura é o escopo da generalização, ou seja, quais entidades especializadas, estão em um determinado modelo conceitual, definidas (cobertas) pela generalização. As especializações podem ser: - Totais (T) ou Parciais (P): define se o modelo contempla totalmente ou

parcialmente, os tipos de entidades envolvidas na generalização;

Disciplina Pré-Req

(1,n)

(1,n)

É necessária

Necessita

Funcionário Chefia

(1,1)

(1,n)

supervisor

supervisionado

Pessoa Casada

(0,1)

(0,1)

Peça Compõe

(0,n)

(0,1)

É componente

É composta



20

- Exclusivas (E) ou Sobrepostas (S): determina se os elementos

participam exclusivamente de uma especialização ou se sobrepõem à outra.

Observe as figuras 16, 17, 18 e 19 a seguir, alguns exemplos de cobertura.

Figura 16

Figura 17

Figura 18

Figura 19 Restrições em Tipos Relacionamentos Geralmente, os tipos relacionamentos sofrem certas restrições que limitam as possíveis combinações das entidades participantes. Estas restrições são derivadas de restrições impostas pelo estado destas entidades no mini mundo.

Pessoa

(T,E)

Física Jurídica

Funcionários

(P,E)

RH INFO

Profissionalde Cinema

(P,S)

Diretor Ator

Cargo

(T,S)

Empregado Chefe



21

A este tipo de restrição, nós chamamos cardinalidade. A cardinalidade indica o número de relacionamentos dos quais uma entidade pode participar. A cardinalidade pode ser: 0:1, 1:1, 1:N, M:N.

Figura 20 Outra restrição muito importante é a participação. A participação define a existência de uma entidade através do relacionamento, podendo ser parcial ou total. Veja o a figura 21 abaixo, onde a participação do empregado é parcial, pois nem todo empregado gerencia um departamento, porém a participação do departamento neste relacionamento é total, pois todo departamento precisa ser gerenciado por um empregado. Desta forma, todas as entidades do TIPO ENTIDADE DEPTO precisam participar do relacionamento, mas nem todas as entidade do TIPO ENTIDADE EMPREGADO precisam participar do relacionamento. Já no exemplo da figura 22 ambas as participações são totais pois todo Empregado precisa trabalhar em um Projeto e todo Projeto tem que ter Empregado trabalhando nele. Estas restrições são chamadas de restrições estruturais.

Figura 21

Figura 22 Algumas vezes, torna-se necessário armazenar um atributo no TIPO RELACIONAMENTO. Veja o exemplo, da figura 21. Poderíamos desejar saber em que dia o Empregado passou a gerenciar o Departamento. Pode se tornar difícil estabelecer a qual TIPO ENTIDADE pertence atributo, pois o mesmo é definido apenas pela existência do relacionamento. Quando temos relacionamentos com cardinalidade 1:1, podemos colocar o atributo em uma das entidades, de preferência, na entidade com participação total.

Disciplina

código

(1,n)

descrição

Cursa Aluno

Matrícula

(1,n)

nome

Empregado(0,1)

Gerencia Depto(1,1)

Empregado(1,n)

Trabalha Projeto(1,n)



22

No caso, o atributo poderia ir para o TIPO ENTIDADE departamento. Isto porque nem todo empregado participará do relacionamento. Caso as cardinalidades máximas sejam 1:N, então podemos migrar o atributo no TIPO ENTIDADE com cardinalidade N para o de cardinalidade 1. Porém, se a cardinalidade for N:M, então o atributo deverá mesmo ficar no TIPO RELACIONAMENTO. Veja o exemplo da figura 22. Caso queiramos armazenar quantas horas cada empregado trabalhou em cada projeto, então este deverá ser um atributo do relacionamento. Tipos Entidade Fraca Alguns TIPOS ENTIDADE podem não ter um atributo chave por si só. Isto implica que não poderemos distinguir algumas entidades por que as combinações dos valores de seus atributos podem ser idênticas. Estes TIPOS ENTIDADE são chamados entidades fracas. As entidades deste tipo precisam estar relacionadas com uma entidade pertencente ao TIPO ENTIDADE proprietária. Este relacionamento é chamado de relacionamento identificador. O TIPO ENTIDADE DEPENDENTE é uma entidade fraca pois não possui um método de identificar uma entidade única. O EMPREGADO não é uma entidade fraca, pois possui um atributo para identificação (atributo chave). O número do RG de um empregado identifica um único empregado. Porém, um dependente de 5 anos de idade não possui necessariamente um documento. Desta forma, esta entidade é um TIPO ENTIDADE fraca. Um TIPO ENTIDADE fraca possui uma chave parcial, que juntamente com a chave primária da entidade proprietária, forma uma chave primária composta. Neste exemplo: a chave primária do EMPREGADO é o RG. A chave parcial do DEPENDENTE é o seu nome, pois dois irmãos não podem ter o mesmo nome. Desta forma, a chave primária desta entidade fica sendo o RG do pai ou mãe mais o nome do dependente.

Figura 23

Figura 24

Titular(0,1)

Venda Dependente(1,1)

Nome

Nascimento

Matrícula

Nome

Banco(1,n)

Possui Agência(1,1)

Código

Descrição

Código

Descrição

(1,n)Possui Conta

(1,1)

Código

Nome



23

Todos os exemplos vistos anteriormente foram para relacionamentos binários, ou seja, entre dois TIPOS ENTIDADE diferentes ou recursivos. Porém, o modelo entidade relacionamento não se restringe apenas à relacionamentos binários. O número de entidades que participam de um TIPO RELACIONAMENTO é irrestrito e armazenam muito mais informações do que diversos relacionamentos binários. Diagrama Entidade Relacionamento O diagrama Entidade Relacionamento é composto por um conjunto de elementos gráficos que visa representar todos os objetos do modelo Entidade Relacionamento tais como entidades, atributos, atributos chaves, relacionamentos, restrições estruturais, etc. O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um conceito mais generalizado de como estão estruturados os dados de um sistema. Observe abaixo, os elementos gráficos que compõem o diagrama ER.

Figura 25

TipoEntidade

TipoRelacionamento

Tipo EntidadeFraca

TipoRelacionamento

Identificador

Atributo chave(RG)

(0,1)

Atributo simples(nome)

Atributo multivalorado(telefone)

Atributo composto(endereço)

Atributo derivado(dígito verificador)



24

O Modelo Relacional O modelo relacional foi criado por CODD em 1970 (Edgar Frank Cood, recentemente falecido – 18 de abril de 2003, mais informações podem ser obtidas no site IBM) com a finalidade de representar os dados como uma coleção de relações, onde cada relação é representada por uma tabela, ou falando de uma forma mais direta, um arquivo. Porém, um arquivo é mais restrito que uma tabela. Toda tabela pode ser considerada um arquivo, porém, nem todo arquivo pode ser considerado uma tabela. Quando uma relação é pensada como uma tabela de valores, cada linha nesta tabela representa uma coleção de dados relacionados. Estes valores podem ser interpretados como fatos descrevendo uma instância de uma entidade ou de um relacionamento. O nome da tabela e das colunas desta tabela são utilizados para facilitar a interpretação dos valores armazenados em cada linha da tabela. Todos os valores em uma coluna são necessariamente do mesmo tipo. Na terminologia do modelo relacional, cada tabela é chamada de relação; uma linha de uma tabela é chamada de TUPLA; o nome de cada coluna é chamado de ATRIBUTO; o tipo de dado que descreve cada coluna é chamado de DOMÍNIO. Verifique estes conceitos na figura 26.

Figura 26 Domínios, Tuplas, Atributos e Relações Um domínio “D” é um conjunto de valores atômicos, sendo que por atômico, podemos compreender que cada valor do domínio é indivisível. Durante a especificação do domínio é importante destacar o tipo, o tamanho e a faixa do atributo que está sendo especificado.

DATABASE 1

Coluna, Atributo ou Propriedade

Tabela 1 Tabela 2Linha ouTUPLA

DATABASE 2

SGBDSGBD

CATÁLOGO



25

Por exemplo: COLUNA TIPO TAMANHO FAIXA RG Numérico 10,0 03000000-25999999 Nome Caracter 30 a-z, A-Z Salário Numérico 5,2 00100,00-12000,99 Um esquema de relação R, denotado por R(A1, A2,..., An), onde cada atributo Ai é o nome do papel desempenhado por um domínio D no esquema relação R, onde D é chamado domínio de Ai e é denotado por dom(Ai). O grau de uma relação R é o número de atributos presentes em seu esquema de relação. A instância r de um esquema relação denotado por r(R) é um conjunto de n-tuplas r = intt1, t2,..., tn onde os valores de intt1, t2,..., tn devem estar contidos no domínio D. O valor nulo também pode fazer parte do domínio de um atributo e representa um valor não conhecido para uma determinada tupla. Atributo Chave de uma Relação

Uma relação pode ser definida como um conjunto de tuplas distintas. Isto implica que a combinação dos valores dos atributos em uma tupla não pode se repetir na mesma tabela. Existirá sempre um subconjunto de atributos em uma tabela que garantem que não haverá valores repetidos para as diversas tuplas da mesma, garantindo que t1intSC ≠ t2intSC.

SC é chamada de super chave de um esquema de relação. Toda relação possui ao menos uma super chave - o conjunto de todos os seus atributos que identificam uma tupla única. Uma chave C de um esquema de relação R é uma super chave de R com a propriedade adicional que removendo qualquer atributo A de K, resta ainda um conjunto de atributos K’ que não é uma super chave de R. Uma chave é uma super chave da qual não se pode extrair atributos.

Por exemplo, o conjunto: (RA, Nome, Endereço) é uma super chave para estudante, porém, não é uma chave, pois se tirarmos o campo Endereço continuaremos a ter uma super chave. Já o conjunto (Nome da Revista, Volume, No da Revista) é uma super chave e uma chave, pois qualquer um dos atributos que retirarmos, deixaremos de ter uma super chave, ou seja, (Nome da Revista, Volume) não identifica uma única tupla.

Em outras palavras, uma super chave é uma chave composta formada por mais de um atributo.

Quando uma relação possui mais que uma chave (não confundir com chave composta) - como, por exemplo, RG e CIC para empregados - cada uma destas chaves são chamadas de chaves candidatas. Uma destas chaves candidatas deve ser escolhida como chave primária.



26

Uma chave estrangeira de uma tabela R1 em R2 ou vice-versa, especifica um relacionamento entre as tabelas R1 e R2.

Atributo Chave de uma Relação (resumo) CHAVE NOME DEFINIÇÂO PRIMÁRIA Primary Key Atributo que identifica uma única tupla CANDIDATAS Candidate Key Entidade que possui mais de um atributo

para identificá-la unicamente, porém apenas um deles deve ser definido como chave primária

SUPERCHAVE Super Key Conjunto de atributos que identificam uma única tupla;

ESTRANGEIRA Foreign Key chaves primárias das entidades envolvidas no relacionamento.

Derivação do modelo conceitual para o lógico O mapeamento do Modelo Entidade Relacionamento (conceitual) para o Modelo Relacional (lógico) segue sete passos básicos: a) Para cada entidade no modelo ER, é criada uma tabela no modelo

relacional que inclua todos os atributos simples desta entidade. Para cada atributo composto são inseridos apenas os componentes simples de cada um. Um dos atributos chaves da entidade deve ser escolhida como chave primária da tabela;

Figura 27 TB=EMPREGADOS (Matrícula, Nome, Telefone, CPF) b) Para cada entidade fraca com entidade proprietária é criada uma tabela

no modelo Relacional, incluindo todos os atributos desta entidade fraca. Para cada atributo composto são inseridos apenas os componentes simples de cada um. A chave primária desta relação será composta pela chave parcial da entidade fraca mais a chave da entidade proprietária;

Figura 28

TelefoneEmpregados

Matrícula

Nome

CPF

Dependentes(1,1)(0,n)

Número

Nome

Empregados

Matrícula

Nome

Telefone

CPF



27

TB=EMPREGADOS (Matrícula, Nome, Telefone, CPF) TB=DEPENDENTES(Matrícula, Número, Nome) FK=EMPREGADOS(Matrícula) DEPENDENTES (Matrícula) c) Para cada relacionamento regular com cardinalidades máximas 1:1

entre entidades E1 e E2 que geraram as tabelas T1 e T2 respectivamente, devemos escolher a chave primária de uma das relações (T1, T2)e inseri-la como chave estrangeira na outra relação; se um dos lados do relacionamento tiver participação total e outro parcial, então é interessante que a chave do lado com participação parcial seja inserido como chave estrangeira no lado que tem participação total;

Figura 29 TB=EMPREGADOS(Matrícula, Nome, Telefone, CPF) TB=SEGUROS-SAUDE(Apólice, Matrícula, Data opção) FK=EMPREGADOS(Matrícula) SEGUROS-SAUDE (Matrícula) d) Para cada relacionamento regular com cardinalidades máximas 1:N

entre entidades E1 e E2 respectivamente e que geraram as tabelas T1 e T2 respectivamente, deve-se inserir a chave primária de T1 como chave estrangeira em T2;

Figura 30 TB=EMPREGADOS(Matrícula, Nome, Telefone, CPF, Número) TB=NIVEIS-SALARIAIS(Número, Valor) FK=NIVEIS-SALARIAIS(Número) EMPREGADOS(Número) e) Para cada relacionamento regular com cardinalidades máximas N:N

entre entidades E1 e E2, cria-se uma nova tabela T1, contendo todos os atributos do relacionamento mais o atributo chave de E1 e o atributo chave de E2; a chave primária de T1 será composta pelos atributos chave de E1 e E2;

Seguro deSaúde

(1,1) (0,1)

Apólice

Data opção

Empregados

Matrícula

Nome

CPF

Telefone

NíveiSalariai

(1,n) (1,1)

Número

Valor

Empregad

Matrícula

Nome

CPF

Telefone



28

Figura 31 TB=EMPREGADOS(Matrícula, Nome, Telefone, CPF) TB=PROJETOS(Número, Nome) TB=ALOCACAO(Número, Matrícula) FK=EMPREGADOS(Matrícula) ALOCACAO(Matrícula) FK=PROJETOS(Número) ALOCACAO(Número) f) Para cada atributo multivalorado A1, cria-se uma tabela T1, contendo o

atributo multivalorado A1, mais o atributo chave C da tabela que representa a entidade ou relacionamento que contém A1; a chave primária de T1 será composta por A1 mais C; se A1 for composto, então a tabela T1 deverá conter todos os atributos de A1;

Figura 32 TB=EMPREGADOS(Matrícula, Nome, CPF) TB=TELEFONES-EMPREGADO(Matrícula, Telefone) FK=TELEFONES-EMPREGADO(Matrícula) EMPREGADOS (Matrícula) g) Para cada relacionamento n-ário, n > 2, cria-se uma tabela T1, contendo

todos os atributos do relacionamento; a chave primária de T1 será composta pelos atributos chaves das entidades participantes do relacionamento;

Figura 33 TB=MOTORISTA(CPF, Nome) TB=CAMINHÃO(Placa, Nome)

Projetos(0,n)

Alocação(0,n)

número

descrição

Empregados

Matrícula

Nome

CPF

Empregados

Matrícula

Nome

CPF

telefone (0,n)

Caminhão Direções(0,n)

Placa

Nome

Motorista

CPF

Nome

TrajetosNumero

Rodovia

Sentido

(0,n)

(0,n)



29

TB=TRAJETOS(Numero, Rodovia, Sentido) TB=DIRECOES(CPF, Placa, Número) FK=DIRECOES(CPF) MOTORISTAS(CPF) FK=DIRECOES(Placa) CAMINHÕES(Placa) FK=DIRECOES(Número) TRAJETOS(Número) Derivação do modelo conceitual para o modelo lógico (RESUMO) - para cada entidade é criada uma tabela; - para cada atributo composto será inserido cada componente

individualmente; - para cada entidade fraca é criada uma tabela cuja chave primária é

composta do seu atributo identificador concatenado com o atributo identificador da entidade proprietária;

- para relacionamentos com participação parcial, a chave da entidade com participação parcial será chave estrangeira da participação total;

- para relacionamentos com cardinalidade (1,1 : 1,N) a chave primária de (1,N) será chave estrangeira de (1,1)

- para relacionamentos com cardinalidade (1,N : 1,N) será criada uma nova tabela, cuja chave primária será a composição dos atributos identificadores das entidades envolvidas e seus próprios atributos, caso existam;

- para cada atributo multivalorado, cria-se uma nova tabela cuja chave primária será composta pela chave primária da entidade mais o atributo;

- para cada relacionamento de grau superior a 2, cria-se uma nova tabela contendo todos os atributos deste relacionamento mais as chaves primárias das entidades participantes deste relacionamento;

Figura 34

E E EF

c

E E

ou

E E

E E

ou

E E1 N

E EN N

1o Passo - Entidades Normais 2o Passo - Entidades Fracas

3o Passo - Relacionamentos 1:1 4o Passo - Relacionamentos 1:N 5o Passo - Relacionamentos N:N

E

c

mv

6o Passo - Atrbs. Multi Valorados

E E

E

7o Passo - Relacionamento n-ário



30

Exercícios

Aula inicial



31

Aula Inicial Objetos da vida real e seus relacionamentos I) Imagine quatro “planilhas” que correspondam a figura abaixo e

defina algumas de suas informações (características, propriedades ou atributos).

Figura 35 II) Abaixo, insira informações hipotéticas nestas “planilhas”, baseando-

se nas características citadas acima. Por exemplo: se você disse que Funcionário possui as características: CPF, Nome e Sexo, terá que preencher estes dados para CADA Funcionário e da mesma forma para as outras “planilhas”.

Projeto

Funcionário

Dependente

Material

Departamento

DRH



32

III) Problemas: 1) Como associar o Dependente ao Funcionário ? 2) Como e onde armazenar a informação “Horas Trabalhadas” de cada

Funcionário ao(s) Projeto(s) que porventura estejam alocados ? 3) Como e onde armazenar a informação “Data do Pedido” e “Quantidade”

para cada Material solicitado pelo Funcionário ? 4) Como determinar a qual Departamento o funcionário está alocado? Obs.: você pode criar novas “planilhas” se achar necessário.



33

Exercícios

Mini Mundos



34

Mini mundo 1 A administradora de imóveis "DoLar" é uma empresa que cuida principalmente, da compra e venda de imóveis residenciais e comerciais no Grande Rio, dentre outras atividades. O atendimento atualmente é demorado e muitas vezes incompleto devido a demora no manuseio de muitas fichas acarretando a perda de muitas oportunidades de negócio. Todos os imóveis são comprados pela imobiliária para então, serem colocados a venda. A direção da empresa definiu como prioridade automatizar o processo de comercialização (compra e venda) dos imóveis, envolvendo seus proprietários (novos e antigos). A imobiliária considera "proprietário" toda pessoa que participou de um processo de comercialização (compra ou venda) no papel de dono (antigo ou novo). Entre outras informações, o sistema deverá ser capaz de controlar os imóveis comprados, vendidos e os de se "interesse" (não foram comercializados) e emitir: - relação de todos os imóveis disponíveis para venda, contendo para cada um:

Endereço, Bairro, Área (m2), descrição, proprietário antigo (o atual é a administradora) e o preço mínimo para a venda;

- relação de todos os imóveis vendidos, por bairro, contendo para cada um: Bairro, proprietário antigo, proprietário novo, preço de venda (ao proprietário novo) e preço de compra (peal imobiliária);

- relação dos proprietários que compraram mais de um imóvel na imobiliária (nome , CPF, endereço e telefone);relação dos proprietários que venderam mais de um imóvel para a imobiliária (nome e telefone).



35

Mini mundo 2 Uma loja de venda de Eletrodomésticos quer automatizar o seu controle de compra e troca de aparelhos por parte de seus clientes. Todo aparelho vendido possui garantia de 1 ano, a partir da data de venda. Isto significa que qualquer troca só poderá ser realizada dentro deste período, mesmo que já tenha havido trocas em função desta compra. No termo de garantia é anotado a data da compra, marca modelo e número de série do aparelho vendido, juntamente com o nome e endereço do cliente que o comprou. A cada troca de aparelho, relativo a primeira compra, é verificado se ainda está no prazo de garantia e é registrado o cliente que realizou a troca. Qualquer cliente pode realizar uma troca, mesmo que não tenha sido o comprador. Os aparelhos defeituosos são devolvidos para a fábrica e não mais retornam para a loja. A loja quer saber: a) relação de aparelhos disponíveis na loja; b) relação de aparelhos que apresentaram defeitos contendo, data e o defeito

apresentado; c) relação de clientes cujas compras nunca apresentaram defeito.



36

Mini mundo 3 Um dos restaurantes mais tradicionais do Rio de Janeiro, resolveu informatizar o seu controle de atendimento. O restaurante possui atualmente 30 garçons que servem diariamente mais de 500 refeições e o cardápio oferece mais de 40 pratos diferentes. O restaurante dispõe de mesas de 2, 4 e 6 lugares num total geral de 80 mesas. Cada garçom é responsável por atender no mínimo à 4 mesas e no máximo 10 e não podem atender mesas fora de sua responsabilidade. A remuneração dos mesmos é um percentual fixo sobre o consumo das mesas que cada um atendeu (TRIGGER). Ao encerrar a conta o cliente preenche uma avaliação sobre o atendimento prestado pelo garçom. Ao final do mês os garçons que obtiveram as 3 melhores avaliações recebem uma gratificação extra (STORED PROCEDURE). Não é permitido que pessoas ocupem mesas sem consumir. Requisitos de informação: - relação de mesas que o garçom tem sob sua responsabilidade; - número de assentos que o garçom tem sob sua responsabilidade; - salário a pagar ao garçom no fim do mês; - lista de pratos mais consumidos por dia da semana; - mesas que estiveram mais tempo ocupadas; - garçons que devem receber bonificação extra no fim do mês;



37

Mini mundo 4 O Instituto “KPenga” de Seguridade Social, IKSS, está interessado em controlar os pacientes internados, e seus atendimentos, nos seus hospitais. Quando uma pessoa credenciado junto ao IKSS passa mal, ela se dirige a um dos hospitais e se consulta com algum médico. Dependendo da gravidade o(s) médico(s) pode(m) decidir pela internação. Os pacientes, pessoas credenciadas que foram internadas, podem receber atendimento de vários profissionais de saúde, particularmente de médicos e enfermeiras. Não há interesse em controlar as pessoas que não foram internadas, nem as consultas antes da internação. Cada médico ou enfermeira pode estar vinculado a, no máximo 3 hospitais. Não se admite um empregado com mais de um vínculo no mesmo hospital. Não há interesse em controlar as datas em que ocorreram os atendimentos. O Modelo deve prever as seguintes informações: - relação dos pacientes (nome, código do seguro social, idade) internado em um

hospital, juntamente com os nomes e números dos médicos responsáveis por cada internação e o período de internação;

- relação dos médicos (nome, matrícula, especialidade) e enfermeiras (nome, matrícula e cargo) que deram atendimento a um paciente durante a internação;

- relação dos hospitais (nome, código e endereço, que um médico ou enfermeira mantém vínculo



38

Mini mundo 5 (1 ponto) A corretora “Boa Ação”, deseja um sistema automatizado que a auxilie na venda de ações dos seus clientes durante o pregão. O sistema será reinicializado diariamente para que os clientes sem saldo e as ações que nenhum cliente possui saldo não apareçam nunca. Saldo é a quantidade de ação. Somente a tabela corretoras será preservada. O cliente expressa a intenção de vender uma ação pela ordem de venda. Nela o cliente informa a ação e a quantidade que ele quer vender e, a partir dela, a corretora tenta fechar negócios pelo preço mais alto que o mercado pagar. Para avaliar um ordem de venda o sistema deverá conferir se o cliente tem disponível a quantidade que colocou à venda. Como as compras feitas em um dia só estarão disponíveis para a venda no dia seguinte, o saldo das ações de cada cliente é calculado de madrugada e permanece válido por todo o pregão, e a quantidade disponível para venda, a qualquer momento do pregão, é sempre o saldo menos as quantidades das ordens já emitidas daquela ação por aquele cliente, naquele dia. Uma mesma ação pode ser posta a venda por um mesmo cliente em diversas ordens durante o pregão, desde que o saldo permita. Da mesma forma que uma mesma ordem pode ser negociada em vários lotes que somados não ultrapassem a quantidade da ordem. Com isso a mesma ordem pode acabar sendo negociada aos poucos por várias corretoras e ou pela mesma várias vezes. O sistema deve ser capaz de, ao final do pregão: - Listar matrícula cliente, código da ação, quantidade e momento (h/m)

das ordens cadastradas que não foram negociadas, nem parcialmente; - Listar matricula cliente, código ação, quantidade e momento (h/m) das

ordens cadastradas que foram parcialmente negociadas, juntamente com o CGC e nome da corretora, quantidade, momento e preço de cada lote negociado dentro desta ordem. Ao final de cada ordem, informar a quantidade que sobrou sem ser negociada.



39

Mini mundo 6 O Hospital “AkiCFicaBom” esta informatizando o controle de consultas médicas e o receituário que, eventualmente, o médico determina para o cliente. Cada médico cadastrado, possui mais de uma especialidade que segue o padrão da AMB: código com 8 dígitos e descrição com 100 caracteres e só podem estar vinculados a, no máximo, 4 Hospitais. Quando um médico começa ou deixa de clinicar uma determinada especialidade, é gravada a informação: especialidade ativa (A) ou inativa (I), para o médico. São gravadas também, informações para que o médico seja encontrado a qualquer momento: três telefones, um celular, um BIP e um eMail. Quando um médico perde o vínculo com um Hospital, a informação é eliminada do Banco de Dados. - As especialidades são cadastradas com as seguintes informações: código da

especialidade e sua descrição. - Quando o cliente procura o Hospital pela primeira vez, é mantido o seu cadastro

com as seguintes informações: código do cliente, nome do cliente, CPF e seu endereço. Ao final da consulta, que ocorreu em uma determinada data, o médico poderá emitir um receituário para o cliente, com um ou mais remédios.

- Os remédios são cadastrados com os seguintes dados: código do remédio, descrição do remédio, princípio ativo.

- Os hospitais cadastrados possuem as seguintes características: CGC, nome, endereço, 3 telefones, eMail.

São requisitos de informação: - Médicos que mais consultaram em um determinado período de tempo - Tempo de duração para cada consulta; - Remédios que foram mais receitados; - Clientes que mais se consultaram; - Hospitais e seu corpo clínico - Médicos que possuem a especialidade: CARDIOLOGIA.



40

Mini mundo 7 A loja de revenda de peças automotivas, está informatizando a sua revenda. Quer identificar também, caso uma peça esteja danificada, quantas outras, no caso peças componentes, poderão também estar afetadas. Esta loja efetua a venda, cadastrando apenas a data da venda e quantidade desejada da peça solicitada. O faturamento da venda ocorre apenas no final do mês, quando é gerada toda a documentação para que o comprador possa efetuar o pagamento na rede bancária. Infelizmente, estamos em um país onde a inflação é alta e o preços aumentam constantemente, porém, é necessário respeitar o preço de quando ocorreu a venda. O dono da loja pode não aumentar a peça, mesmo com a inflação alta. São requisitos de informação: - Relação de peças e seus componentes; - Peças que estão com o saldo abaixo da quantidade mínima; - Faturamento que deve ser emitido, baseado nas compras de um período; - Relação de compradores contendo: CPF ou CGC, nome e eMail; - Evolução dos valores de cada peça;



41

Mini mundo 8 Uma empresa de contabilidade “KontaOK” tem a seguinte definição para parte do seu sistema contábil: - Uma conta contábil, pode agregar diversas outras contas; - Uma conta contábil, pode possuir movimentação; - Cada movimentação está associada à um único Centro de Custo; São requisitos de informação: - Relação dos centros de custo contendo: código do centro, descrição e valor

consumido em um período; - Relação das contas contábeis (código e descrição) bem como das suas

agregadas (código e descrição); - Relação da movimentação contábil de um período de uma ou todas as contas; - Centro de Custo que não movimentou em um determinado período;



42

Mini mundo 9 Uma empresa que fabrica pesticidas, material altamente tóxico, resolve sistematizar três casos do seu sistema de pagamento. A cada departamento da empresa estão alocados diversos funcionários. Cada departamento possui um funcionário no cargo de chefia. O departamento possui de 1 a 5 ramais para comunicação interna. A empresa possui diversos setores mas a ADMINISTRAÇÃO, FÁBRICA e o setor de INVESTIMENTOS possuem algumas características específicas. - apenas os funcionários da ADMINISTRAÇÃO podem fazer horas extras que, ao

final do mês, caso ocorram, devem ser calculadas para que o pagamento possa ser efetuado. Sabemos que as horas extras dependem do dia da semana, e da quantidade de horas trabalhadas;

- os trabalhadores da FÁBRICA, podem manipular diversos produtos tóxicos que possuem um índice de toxicidade, utilizado tanto para o cálculo da quantidade máxima de horas para a exposição diária quanto para o cálculo de adicional de insalubridade do funcionário daquele setor. O número de horas de trabalho destes funcionários depende da demanda de produção, podendo trabalhar o máximo de horas em um dia ou não trabalhar no outro.

- os analistas financeiros da área de INVESTIMENTOS, acumulam bônus a cada negociação bem sucedida no mercado de ações. A cada venda diária, imediatamente o sistema de investimentos calcula e acumula o bônus do funcionário. Ao final do mês a quantidade ali acumulada é imediatamente creditada em conta corrente, fora da folha de pagamento. A informação do bônus, volta a zero para o próximo período.

São requisitos de informação: - Relação de ramais do departamento, ordenado por departamento, contendo

também o nome do chefe; - Relação de funcionários dos departamentos e seus telefones (3 no máximo) de

contato; - Relação de horas extras do período, de cada funcionário da administração; - Relação de materiais tóxicos contendo seu código, descrição, índice de

toxicidade (IT) e tempo máximo de exposição (TME); - Relatório com a quantidade de horas que cada funcionário ficou exposto ao

material tóxico e quanto isto custará, no período; - Relatório com matrícula, nome e bonificação em ordem decrescente de

bonificação dos funcionários da área de investimentos;



43

Mini mundo 10 Uma empresa deseja fazer um “bolão de apostas“ centre seus funcionários, com base na Copa do Mundo de Futebol. As apostas serão feitas pela Internet e o valor depositado em uma conta corrente definida pelo funcionário que gerenciará o “bolão”. Para registrar corretamente as informações, se faz necessário observar as seguintes questões: - Os apostadores podem fazer quantas cartelas de apostas desejar. Eles serão

identificados pelo CPF, NOME e ainda é necessário o registro do EMAIL para futuras comunicações;

- Cada cartela de apostas é identificada por um NÚMERO e, a medida em que os jogos forem se realizando, a PONTUAÇÃO TOTAL será registrada para facilitar o processo de obtenção do RELATÓRIO DOS APOSTADORES COM MAIS PONTOS (RANKING) e a informação se é uma cartela válida (ou não) dependendo se o valor da aposta foi depositado ou não;

- Para cada jogo, que possui um NÚMERO, é registrado o placar. Em cada jogo, obviamente participam dois times;

- Como a Copa do Mundo está definida com 64 jogos, foi definido que cada cartela, conterá os palpites dos 64 jogos, onde o apostador registrará seus placares e a cada jogo realizado, um processamento registrará a pontuação obtida naquele jogo, que também refletirá na pontuação total da cartela, mencionada acima;

- Cada time é registrado no banco de dados com um NÚMERO, NOME e a IMAGEM da bandeira do país;

- A regras que regulamentam a pontuação sobre os placares, não são relevantes neste momento. O importante é registar os palpites dos apostadores e o placar oficial para que possam ser comparados e a pontuação atribuída.

Podemos dizer a seguinte frase para resumir o problema: “O apostador joga várias cartelas que contém palpites individuais sobre o placar dos jogos que se realizam entre dois times” Requisitos de informação: - Relatório com o RANKING, (NÚMERO DA CARTELA, NOME DO APOSTADOR e

TOTAL DE PONTOS OBTIDOS) ordenado de forma descendente pela pontuação; - Time que fez mais gols - Time que fez menos gols - Times que mais participaram da COPA - O nome do apostador com mais pontos - O nome do apostador “lanterninha”



44

Mini mundo 11 A Rádio “FM Istério”, deseja guardar as informações de todas as músicas transmitidas por ela. Para isso é necessário montar um banco de dados de acordo como seguinte: As gravadoras são identificadas pelo CGC, razão social, endereço, uma pessoa de contato e um web site e são responsáveis pela produção de vários CDs. As músicas, podem estar em CDs diferentes e em faixas diferentes. Cada música possui uma codificação própria, um nome e o tempo de duração e podem ter mais de um autor. Os CDs recebem uma classificação que determina sua categoria (ROCK, POP, MPB, CLÁSSICA, SERTANEJO, PAGODE etc....). Esta categoria define inclusive, o maior e o menor preço para comercialização. São registradas também, as seguintes informações para cada CD: nome, preço, data de lançamento e a quantidade de indicações. Os ouvintes ao solicitarem as músicas acabam fazendo referência a um determinado CD, que recebe uma indicação a mais (um contador de indicações). Dos autores, são registradas as seguintes informações: CPF e nome São requisitos de informações: - Os CDs mais indicados - As músicas que compõem mais de 3 CDs - Os autores que possuem mais de 30 músicas - As gravadoras e os CDs produzidos por elas - A quantidade de CDs, por categoria



45

Capítulo 2

Dependência Funcional e Normalização



46

Dependência Funcional e Normalização Dependência Funcional Dados dois conjuntos de atributos (ou dois atributos) A e B de uma entidade, diz-se que B é funcionalmente dependente de A, ou que A determina B, ou que B depende de A, se a cada valor de A estiver associado um, e só um, valor de B. Se A determina B então B não é funcionalmente dependente de nenhum subconjunto de A. Uma dependência funcional é representada por : A B (A determina B) Exemplo de identificação de dependências funcionais: #Funcionário Nome_próprio Apelido Departamento 4022 Renata Reis 501 4023 Ari Reis 203 4024 Maria Cardoso 203

Departamento #Funcionário ? Não, pois o Departamento 203 {4023, 4024} #Funcionário Departamento ? Sim, pois conhecendo-se o #Funcionário (atributo unívoco) é possível determinar o Departamento (um funcionário só pode pertencer a um departamento). Nome_próprio #Funcionário ? Não, pois podem existir funcionários com o mesmo nome. Podem haver múltiplos valores de #Funcionário para o mesmo Nome_próprio. #Funcionário Apelido ? Apesar de dois funcionários terem o mesmo apelido, conhecendo-se o #Funcionário determina-se um só Apelido. #Funcionário todos os outros atributos Observação Importante: A identificação de dependências funcionais não pode ser obtida apenas a partir da inspeção de algumas instâncias, mas sim através das próprias propriedades dos atributos.



47

Outro exemplo de identificação de dependências funcionais: Papelaria Artigo Preço Colmeia Caneta BIC fina 150,00Central Fita cola 300,00Aguarela Borracha 215,00Silva Caneta BIC fina 175,00 O Preço é funcionalmente dependente de artigo (Artigo Preço) ? Não, pois o mesmo artigo pode ter preços diferentes em diferentes papelarias. O preço é funcionalmente dependente de papelaria (Papelaria Preço) ? Não, porque para cada papelaria há tantos valores para Preço quantos os artigos vendidos nessa papelaria. Preço depende funcionalmente de ambos {Papelaria, Artigo} Preço Normalização Os dados, no mundo real, não aparecem da forma que Codd preconizou. Assim, devem ser tratados, der forma a corrigir as anomalias resultantes do processo de derivação lógica das tabelas e atingir os objetivos propostos pelo modelo relacional. A este processo, chamamos normalização. Depois dos dados serem sujeitos a este tratamento, dizem-se normalizados. Para normalizar podemos seguir os 5 mandamentos de Codd: 1 No repeating (Sem repetições) 2 The fields depend upon the key (Os atributos dependem da CHAVE) 3 The whole key (Da chave inteira) 4 And nothing but the key (De mais nada a não ser da chave) 5 So help me Cood (Que Cood me ajude!) A normalização converte cada entidade gradualmente para “Formas Normais”, através da aplicação sucessiva de regras que alteram o formato dos dados da 1ªForma Normal até à 5ª Forma normal. Formas Normais 1a. Forma Normal Uma relação está na 1a. forma normal (1FN) quando os domínios de todos os atributos consistem apenas em valores atômicos e não existem subgrupos de atributos repetidos.



48

Passagem de uma entidade à 1FN Eliminar subgrupos repetidos, decompondo a relação em duas (ou mais) relações. Exemplo:

Consideremos assim a seguinte relação, representada sob a forma de uma tabela:

#Funcionário Nome Sexo Salário Ano Mês Dia #Função Anos F23 Fernanda F 33000 70 7 9 FUN01 3 F12 Amanda F 33000 57 5 6 FUN02 3 F43 Ari M 46000 70 9 8 FUN03 1 F56 Cassia F 33000 65 8 10 FUN01 1 F23 Fernanda F 33000 70 7 9 FUN02 1 F55 Paulo M 56000 70 7 9 FUN04 1 F54 Lucio M 56000 65 6 12 FUN05 5 F95 Angelo M 46000 57 5 6 FUN01 3 F54 Lucio M 56000 65 6 12 FUN02 5 F56 Cassia F 33000 65 8 10 FUN02 2 F36 Cassia F 44000 65 8 3 FUN01 1 F67 Domingos M 44000 65 6 6 FUN06 2 F95 Angelo M 46000 57 5 6 FUN06 3 F55 Paulo M 56000 70 7 9 FUN01 1 Esta relação pode ser considerada como estando na 1a. Forma Normal ? De fato, podemos encontrar grupos repetidos, especialmente, se olharmos para os dados, segundo uma organização diferente: #Funcionário Nome Sexo Salário Ano Mês Dia #Função Anos F23 Fernanda F 33000 70 7 9 FUN01 3 F23 Fernanda F 33000 70 7 9 FUN02 1 F12 Amanda F 33000 57 5 6 FUN02 3 F36 Cassia F 44000 65 8 3 FUN01 1 F43 Ari M 46000 70 9 8 FUN03 1 F54 Lucio M 56000 65 6 12 FUN05 5 F54 Lucio M 56000 65 6 12 FUN02 5 F55 Paulo M 56000 70 7 9 FUN04 1 F55 Paulo M 56000 70 7 9 FUN01 1 F56 Cassia F 33000 65 8 10 FUN01 1 F56 Cassia F 33000 65 8 10 FUN02 2 F67 Domingos M 44000 65 6 6 FUN06 2 F95 Angelo M 46000 57 5 6 FUN01 3 F95 Angelo M 46000 57 5 6 FUN06 3 Podemos olhar para o esquema de relação da seguinte forma: #Funcionário Nome Sexo Salário Ano Mês Dia #Função Anos #Função Anos #Função Anos



49

Para passar para a 1FN, temos que dividir a tabela em duas, eliminando os grupos repetidos: #Funcionário Nome Sexo Salário Ano Mês Dia #Funcionário #Função Anos A chave para o primeiro registro é facilmente identificável: #Funcionário Nome Sexo Salário Ano Mês Dia O segundo registro tem a chave concatenada #Funcionário, #Função. Não se pode saber o número de anos de experiência sem se saber qual o código desse funcionário e qual a função desempenhada: #Funcionário #Função Anos A informação ficaria da seguinte forma, na 1ª Forma Normal: Funcionário #Funcionário Nome Sexo Salário Ano Mês Dia F23 Fernanda F 33000 70 7 9 F12 Amanda F 33000 57 5 6 F36 Cassia F 44000 65 8 3 F43 Ari M 46000 70 9 8 F54 Lucio M 56000 65 6 12 F55 Paulo M 56000 70 7 9 F56 Cassia F 33000 65 8 10 F67 Domingos M 44000 65 6 6 F95 Angelo M 46000 57 5 6 Funcionário X Função #Funcionário #Função Anos F23 FUN01 3 F12 FUN02 3 F43 FUN03 1 F56 FUN01 1 F23 FUN02 1 F55 FUN04 1 F54 FUN05 5 F95 FUN01 3 F54 FUN02 5 F56 FUN02 2 F36 FUN01 1 F67 FUN06 2 F95 FUN06 3 F55 FUN01 1



50

2a. Forma Normal Uma relação está na 2a. forma normal (2FN) quando estiver na 1FN e, todos os atributos que não pertencem à chave dependem de toda a chave (e não de um subconjunto da chave). Assim, uma tabela estará na 2a. FN se cada atributo da relação depende totalmente da chave. Quando a chave é constituída por mais do que um atributo, a relação pode não estar na 2a. forma Normal. Daqui resulta que se a chave de uma tabela é constituída apenas por um atributo, está automaticamente na 2a. forma normal. Passagem de uma relação à 2FN Separar os atributos que dependem de um subconjunto da chave, decompondo a relação em duas (ou mais) relações. Exemplo: Consideremos a seguinte relação: #Peça #Fornecedor Nome Local Preço1 FOR10 Mauro PAlegre 20,001 FOR11 Basílio Minas 20,001 FOR13 Padreira Ceará 20,001 FOR19 Favos VRedonda 22,002 FOR31 BBC Natal 825,002 FOR10 Mauro PAlegre 723,002 FOR13 Padreira Ceará 589,003 FOR13 Padreira Ceará 213,004 FOR10 Mauro PAlegre 852,004 FOR31 BBC Natal 752,004 FOR19 Favos VRedonda 952,005 FOR11 Basílio Minas 1.236,005 FOR10 Mauro PAlegre 1.258,00 Em que forma normal se encontra a relação? Encontra-se na 1FN, pois não contém grupos repetidos e a chave é composta pelos atributos #Peça + #Fornecedor. No entanto, não temos qualquer garantia de que se encontra na 2FN, pois a chave é composta por mais do que um atributo. Repare-se nos problemas que se podem levantar, pelo fato de não se encontrar na 2FN: Não se pode inserir a ficha de um fornecedor sem que tenha fornecido pelo menos uma peça. Este campo nunca poderia ficar em branco, uma vez que faz parte da chave.



51

Existem problemas quando se pretende fazer a atualização dos dados de um fornecedor. Temos que procurar todas as ocorrências desse fornecedor e mudar tantas vezes quantas as necessárias. Estes tipos de irregularidades podem ser removidos se dividirmos o registro em dois, sendo necessário o conceito de dependências funcionais: Dependência Funcional: Um atributo ou um conjunto de atributos B, de um registro R, é funcionalmente dependente de um atributo, ou conjunto de atributos, A, do registro R se para cada instância de A em R é encontrada uma única instância de B. Consideremos ainda outro tipo de dependências Dependência Funcional Total Um atributo ou um conjunto de atributos, B, de uma relação, R, é totalmente funcionalmente dependente de um atributo, ou conjunto de atributos, A, da relação R se B é funcionalmente dependente de todo A e não de um subconjunto de A. Podemos, agora, identificar todas as dependências do exemplo dado anteriormente: #Peça #Fornecedor Nome Local Preço Para o registro estar na 2FN, todas as dependências da chave têm que ser totais. Reparemos que apenas o atributo Preço é totalmente dependente de toda a chave. Sendo assim, há necessidade de dividir o registro em dois: #Fornecedor Nome Local #Peça #Fornecedor Preço A relação na 2FN tem a seguinte forma: Fornecedor #Fornecedor Nome Local FOR10 Mauro PAlegre FOR11 Basílio Minas FOR19 Favos VRedonda FOR13 Padreira Ceará FOR31 BBC Natal



52

Peça/Fornecedor #Peça #Fornecedor Preço1 FOR10 20,001 FOR11 20,001 FOR13 20,001 FOR19 22,002 FOR31 825,002 FOR10 723,002 FOR13 589,003 FOR13 213,004 FOR10 852,004 FOR31 752,004 FOR19 952,005 FOR11 1.236,005 FOR10 1.258,00 3ª Forma Normal Uma relação está na 3a. forma normal (3FN) se estiver na 2FN e, os atributos que não pertencem à chave não dependem de nenhum atributo que também não pertence à chave. Assim, uma tabela que esteja na 2FN pode apresentar ainda um certo tipo de anomalia, de tal forma que possa existir um conjunto de atributos não chave, mas que são chave para um outro conjunto de atributos. Esta situação ocorre quando existem dependências transitivas. Uma tabela está na 3FN se não há dependências entre atributos não chave. Vamos supor que A, B e C são conjuntos de atributos de uma relação R. Se C é funcionalmente dependente de B e B é funcionalmente dependente de A, então C é transitivamente dependente de A:

A B C Para ser feita a conversão para a 3FN, o registro é dividido da seguinte forma:

A B

B C Passagem de uma relação à 3FN Separar os atributos que dependem de outro atributo não pertencente à chave, decompondo a relação em duas (ou mais) relações.



53

Exemplo: Consideremos a seguinte relação: #Empregado Nome Salário #Projeto Data do fim EMP01 João 120 PROJ01 17.07.97 EMP02 Maria 452 PROJ01 17.07.97 EMP03 Josefina 23 PROJ02 31.08.97 EMP04 Maria 614 PROJ01 17.07.97 EMP05 Luís 123 PROJ03 31.12.97 EMP06 Jorge 842 PROJ02 31.08.97 EMP07 José 120 PROJ03 31.12.97 EMP08 Reinaldo 452 PROJ01 17.07.97 EMP09 Nuno 65 PROJ03 31.12.97 EMP10 Fernando 52 PROJ01 17.07.97 EMP11 Mariano 52 PROJ02 31.08.97 EMP12 Jeremias 52 PROJ02 31.08.97 EMP13 Esaú 52 PROJ01 17.07.97 EMP14 Pedro 52 PROJ01 17.07.97 Identifiquemos as dependências funcionais que existem: #Empregado Nome Salário #Projeto Data do fim Verifica-se que existem dependências transitivas. A conversão para a 3ªFN é feita através da remoção das dependências transitivas, dividindo as tabelas. A relação fica com a seguinte forma : Empregado #Empregado Nome Salário#Projeto EMP01 João 120,00PROJ01 EMP02 Maria 452,00PROJ01 EMP03 Josefina 23,00PROJ02 EMP04 Maria 614,00PROJ01 EMP05 Luís 123,00PROJ03 EMP06 Jorge 842,00PROJ02 EMP07 José 120,00PROJ03 EMP08 Reinaldo 452,00PROJ01 EMP09 Nuno 65,00PROJ03 EMP10 Fernando 52,00PROJ01 EMP11 Mariano 52,00PROJ02 EMP12 Jeremias 52,00PROJ02 EMP13 Esaú 52,00PROJ01 EMP14 Pedro 52,00PROJ01 Projeto #Projeto Data do Fim PROJ01 17.07.97 PROJ02 31.08.97 PROJ03 31.12.97



54

As anomalias que podem ocorrer quando uma relação não está na 3FN são:

• Não podem ser inseridos dados relativos ao projeto antes de se ter selecionado os empregados para o executarem.

• Se todos os empregados abandonarem um determinado projeto, antes de serem selecionados outros, pode ocorrer uma situação de inconsistência que pode ocorrer em remoção de informação importante.

• Se a data de fim de projeto for alterada, tem que se fazer alteração tantas vezes quantas as necessárias.

Vantagens/Desvantagens da Normalização - Vantagens

- Estruturas de dados mais estáveis - Elimina a redundância - Obtém-se um modelo de dados mais natural e mais simples - Evitam-se os efeitos laterais da alteração - Evitam-se os efeitos laterais da inserção - Evitam-se os efeitos laterais da remoção

Conclusão: Facilita a exploração e manutenção de tabelas

- Desvantagens

- Favorece a proliferação do no. de tabelas - Favorece a fragmentação exagerada - Perigoso de seguir cegamente

Conclusão: Normalizar? Sim, mas com bom senso ...

Forma Normal Boyce Codd Uma relação está na forma normal de Boyce Codd (FNBC) quando todo o determinante da relação for uma chave candidata. A FNBC corresponde a m grau de normalização mais elevado do que a 3FN e é necessária quando: - uma entidade tem várias chaves candidatas; - as chaves candidatas são compostas; - as chaves candidatas sobrepõem-se porque possuem pelo menos um

atributo em comum. Exemplo de entidade que necessita da FNBC: Seminário Estudante Instrutor Participações S1 1022 Reis 12 S1 3088 Couto 12 S2 1022 Pires 14 S2 4325 Guedes 14



55

- Cada seminário é dirigido por dois instrutores, mas um instrutor só pode dirigir um seminário;

- Um estudante pode participar em mais do que um seminário mas é orientado somente por um dos instrutores.

Chaves candidatas: Seminário, Estudante Estudante, Instrutor Dependências funcionais Determinantes Seminário, Estudante Instrutor, Participações

São chaves candidatas

Estudante, Instrutor Seminário, Participações

São chaves candidatas

Instrutor → Seminário Não é chave candidata Passagem de uma relação à FNBC Separar o(s) atributo(s) que depende(m) de atributo que não é chave candidata, decompondo a relação em duas (ou mais) relações. No exemplo ficaríamos com as seguintes entidades: Participante (Estudante, Instrutor, Participações) Orientador (Instrutor, Seminário) Considerações relativamente a normalização A essência do processo de normalização consiste na decomposição sucessiva de uma coleção de relações, sem perda de informação, com base num conjunto de regras (formas normais). Benefícios do processo de normalização: - Estruturação da informação e melhoria da qualidade da representação

relacional; - Eliminação das possibilidades de ocorrência de anomalias na

manipulação dos dados (que comprometem a sua integridade); - Economia de espaço de armazenamento e de custos de manipulação.

Exemplos de custos evitados: manipulação de um volume de dados maior do que o efetivamente, atualização de dados redundantes, etc.).

- Potência a estabilidade do modelo lógico relacional, ao aumentar a

capacidade de um modelo se manter inalterado face a mudanças que



56

venham a ser percebidas ou introduzidas no ambiente que tenha sido modelado;

Observações importante

Normalização NÃO é um processo com finalidade restritiva, mas sim de caráter organizacional.

Fragmentação da informação e suas conseqüências é a principal

limitação do processo de normalização

Estratégias de Normalização Alguns aspectos a serem considerados: - O processo de normalização raramente percorre todas as formas

normais (da 1FN à 5FN); - Freqüentemente, o analista reconhece, por experiência própria, que uma

dada entidade não está normalizada e coloca-a diretamente na 3FN ou na FNBC;

- Uma estratégia muito usada consiste em normalizar para a FNBC em

iterações sucessivas, utilizando a análise de dependências funcionais. Estratégia de decomposição usando a análise de dependências funcionais

Figura 36

ModeloConcluído

Determinar todas as Dependências

Funcionais

Decompor a relação em duas

DesenvolverRelação Universal

SIM

NÃO

A relação está na FNBC



57

Decomposição de uma relação com vista à obtenção de relações na FNBC

- Consideramos a relação R (A, B, C, D, E, ...), que não está na FNBC; - Procura-se uma DF C D que seja responsável por a relação não estar

na FNBC; - Criam-se duas relações: R1(A, B, C, E, ...) e R2(C, D); - Verifica-se se R1 está na FNBC; - O processo continua até todas as relações obtidas por decomposição

estarem na FNBC. Diagrama de dependências funcionais

Figura 37 #Produto, #Fornecedor Preço

Exemplo de normalização usando a análise de dependências funcionais

Figura 38

Não está na FNBC porque existem determinantes que não são chave (Tipo)

Chave candidata #Produto, #Fornecedor Determinantes #Produto, #Fornecedor

#Produto #Fornecedor

#Produto

#FornecedorPreço

Q_Alerta

Existências

#Produto

#Fornecedor

Tipo

Preço

Local

Telefone



58

Tipo Decompondo as relações para a FNBC

Figura 39 Chave candidata e determinante: TIPO

Figura 40 Chave candidata e determinante: #PRODUTO

Figura 41 Chave candidata e determinante: #FORNECEDOR

Figura 42 Chave candidata e determinante: #PRODUTO, #FORNECEDOR

Modelo de dados final R2 (Tipo, Q_Alerta) R3 (#Produto, Existências, Tipo) R4 (#Fornecedor, Morada, Telefone) R5 (#Produto, #Fornecedor, Preço)

Q_AlertaTipo

Relação_01

Existências

#ProdutoTipo

Relação_02

#Fornecedor

Local

Telefone

Relação_03

#Produto

#FornecedorPreço

Relação_04



59

Exercícios

Normalização



60

Normalização 1 Suponha que temos os seguintes requisitos para um banco de dados de Universidade, que é usado para manter o histórico escolar dos alunos: a) A Universidade mantém de cada aluno, o nome (ALUNOME), número do

aluno (ALUNUM), número da identidade (ALURG), endereço atual (ALUENDER) e telefone (ALUFONE), data de nascimento (ALUDTNASC), sexo (SEXO), classe (CLASSE: calouro, veterano, ..., formando), centro universitário (CODCENTRO), departamento (CODDEPTO) e o tipo de graduação (TIPOGRAD: licenciatura, bacharelado, ..., doutorado). ALUNUM e ALURG são únicos para cada aluno.

b) Cada departamento é descrito pelo nome (NOMEDEPTO), código do

departamento (CODDEPTO), código da unidade (CODUNIDEPTO), telefone do departamento (FONEDEPTO) e centro universitário (CODCENTRO). Os nomes e códigos têm valores únicos para cada departamento.

c) Cada curso tem um nome de curso (CURNOME), descrição (CURDESC),

número de código (CURNUM), número de horas semestrais (CREDITOS), nível (NIVEL) e departamento que oferece (CODDEPTO). O número de código é único para cada curso.

d) Cada turma de oferecimento tem um instrutor (NOMEINSTRUTOR),

semestre (SEMESTRE), ano (ANO), curso (CURNUM) e número da turma (NUMTURMA). O número de turma distingue diferentes turmas de oferecimento de um mesmo curso que é oferecido durante o mesmo semestre / ano; seus valores são 1, 2, 3, ...., até o total de números de turmas oferecidas durante cada semestre.

e) Uma transcrição no histórico corresponde a um aluno (ALURG), os dados

do curso efetuado (NUMTURMA e CURNUM) e a média obtida no curso (NOTA).

Desenvolva um esquema de banco de dados relacional para essa aplicação de banco de dados. Primeiro mostre todas as dependências funcionais que devem existir entre os atributos. Então, desenvolva esquemas relacionais para o banco de dados que estão em 3NF ou FNBC. Especifique os atributos chaves de cada relação. Note qualquer requisito não especificado e faça suposições apropriadas para tornar a especificação completa.



61

Normalização 2 Normalize a relação até a 3NF: InfoIPTU = ( codinscIMV, nomepropIMV, ruapropIMV, bairropropIMV, cidpropIMV, estpropIMV, fonepropIMV, benfsIMV, ruaIMV, bairroIMV, vlrterreno, areaterreno, areaconstruida, padraoconstrucao, vlrIMV, codloteamento, quadraterr, loteterr, nomesmoradores, dtanivmoradores ) Legenda: - prop = proprietário - IMV = imóvel - cid = cidade - est = estado - benfs = conjunto de benefícios - vlr = valor - Bairro determina os vários loteamentos que o compõem. - As quadras são numeradas em ordem no loteamento e os lotes são

numerados em ordem de quadra. - CODLOTEAMENTO + QUADRA + LOTE são chave - Os terrenos que têm construção, têm alíquota de imposto diferenciada

dos que não tem construção. - O número de benfeitorias é importante para determinar a alíquota dos

terrenos em construção.



62

Normalização 3 Considere o esquema de relação EmpDepto = ( numat, nomemp, datanasc, endereço, ndepto, nomedep, nchefe)

e o seguinte conjunto G de dependências funcionais em EmpDepto: G = {numat {nomemp, datanasc, endereço, ndepto}, ndepto {nomedep, nchefe}}.

Calcule {numat}+ e {ndepto}+ em respeito a G. Normalização 4 Por que as dependências transitivas e dependências parciais são consideradas ruins no esquema relacional? Normalização 5 Considere a relação universal R = { A, B, C, D, E, F, G, H, I, J } e o conjunto de dependências funcionais F = {

{A, B} C A {D, E} B F F {G, H} D {I, J}

} Qual é a chave para R? Decomponha R em relação a 2NF e, então, em relação a 3NF. Normalização 6 Repita o exercício Normalização 5 para o seguinte conjunto de dependências funcionais: G = {

{A, B} C {B, D} {E, F} {A, D} {G, H} A I H J

}.



63

Normalização 7 Seja F o conjunto de dependências funcionais abaixo: codend, prefixo, numfone tipofone, numfone codend, numrua, cep tipofone nomerua, numrua, cep nomerua, cep codend, complemento complemento cidade, estado codcid codcid ddd codcid cepmin, cidade codcid cepmax, estado codcid, estado cepmin, cepmax, cidade cidade, codcid cepmin, cepmax, ddd ddd estado Aplique o algoritmo visto em sala de aula para produzir os fechos de cada dependência funcional acima. Então, analise os conjuntos resultantes e normalize o esquema até a 3NF.



64

Normalização 8 Normalize a relação PEDIDO até a 3NF: PEDIDO = (NÚMERO_PED, PRAZO_PED, COD_CLI, END_CLI, CGC_CLI, IE_CLI, {COD_PROD}, {DESC_PROD}, {UNID_PROD}, {QTD_PROD}, {VU_PROD}, COD_VEND, NOME_VEND) 1a. Forma Normal: ausência de atributos multivalorados PEDIDO (NÚMERO_PED, PRAZO_PED, COD_CLI, END_CLI, CGC_CLI, IE_CLI, COD_VEND, NOME_VEND) ITEM PEDIDO (NÚMERO_PED, COD_PROD, DESC_PROD, UNID_PROD, QTD_PROD, VU_PROD) 2a. Forma Normal: ausência de dependências funcionais parciais PEDIDO (NÚMERO_PED, PRAZO_PED, COD_CLI, END_CLI, CGC_CLI, IE_CLI, COD_VEND, NOME_VEND) ITEM PEDIDO (NÚMERO_PED, COD_PROD, QTD_PROD) PRODUTO (COD_PROD, DESC_PROD, UNID_PROD, VU_PROD) 3a. Forma Normal: ausência de dependências funcionais transitivas PEDIDO (NÚMERO_PED, PRAZO_PED, COD_CLI, COD_VEND) ITEM PEDIDO (NÚMERO_PED, COD_PROD, QTD_PROD) PRODUTO (COD_PROD, DESC_PROD, UNID_PROD, VU_PROD) CLIENTE (COD_CLI, NOME_CLI, END_CLI, CGC_CLI, IE_CLI) VENDEDOR (COD_VEND, NOME_VEND)



65

Normalização 9 Normalize a relação TURMA até a 3NF: TURMA = (COD_TURMA,DESC_TURMA,{COD_ALUNO}, NOME_ALUNO}, {NASC_ALUNO}, {TEL_ALUNO}, {COD_DISC}, {DESC_DISC}) 1a. Forma Normal: ausência de atributos multivalorados TURMA (COD_TURMA, DESC_TURMA) ALUNO (COD_ALUNO, NOME_ALUNO, NASC_ALUNO, COD_TURMA, COD_DISC, DESC_DISC) ALUNO_TELEFONE (COD_ALUNO, TEL_ALUNO) 2a. Forma Normal: ausência de dependências funcionais parciais Não existem dependências funcionais parciais 3a. Forma Normal: ausência de dependências funcionais transitivas TURMA (COD_TURMA, DESC_TURMA) ALUNO (COD_ALUNO, NOME_ALUNO, NASC_ALUNO, COD_TURMA) ALUNO_TELEFONE (COD_ALUNO, TEL_ALUNO) DISCIPLINA(COD_DISC, DESC_DISC) ALUNO_DISCIPLINA(COD_ALUNO, COD_DISC)



66

Normalização 10 Normalizar a relação ASSOCIADO até a 3FN Associados - Os TITULARES são vinculados aos PLANOS de saúde. - Os DEPENDENTES são ligados aos TITULARES e possuem um GRAU de

parentesco ASSOCIADOS = (MAT_TIT, NOM_TIT, {TEL_TIT}, {SEQ_DEP}, {NOM_DEP}, {COD_GRA}, {DES_GRA}, COD_PLA, DES_PLA) 1a. Forma Normal: ausência de atributos multivalorados TITULAR (MAT_TIT, NOM_TIT, COD_PLA, DES_PLA) TEL_TIT (MAT_TIT, TEL_TIT) DEPENDENTE (MAT_TIT, SEQ_DEP, NOM_DEP, COD_GRA, DES_GRA) 2a. Forma Normal: ausência de dependências funcionais parciais TITULAR (MAT_TIT, NOM_TIT, COD_PLA, DES_PLA) TEL_TIT (MAT_TIT, TEL_TIT) DEPENDENTE (MAT_TIT, SEQ_DEP, NOM_DEP, COD_GRA) GRAU (COD_GRA, DES_GRA) 3a. Forma Normal: ausência de dependências funcionais transitivas TITULAR (MAT_TIT, NOM_TIT, COD_PLA) TEL_TIT (MAT_TIT, TEL_TIT) DEPENDENTE (MAT_TIT, SEQ_DEP, NOM_DEP, COD_GRA) GRAU (COD_GRA, DES_GRA) PLANO (COD_PLA, DES_PLA)



67

Normalização 11 Normalizar a relação CLIENTES até a 3FN Clientes - Os CLIENTES são associados a determinadas CLASSES. - As CONTAS correntes pertencem aos CLIENTES e existem em um

determinado BANCO. CLIENTES = (COD_CLI, NOM_CLI, {TEL_CLI}, COD_CLA, DES_CLA, {NUM_CC}, {SALDO_CC}, {COD_BCO}, {DES_BCO}) 1a. Forma Normal: ausência de atributos multivalorados CLIENTE (COD_CLI, NOM_CLI, COD_CLA, DES_CLA) TEL_TIT (COD_CLI, TEL_CLI) CONTAS (COD_CLI, NUM_CC, SALDO_CC, COD_BCO, DES_BCO) 2a. Forma Normal: ausência de dependências funcionais parciais CLIENTE (COD_CLI, NOM_CLI, COD_CLA, DES_CLA) TEL_TIT (COD_CLI, TEL_CLI) CONTAS (COD_CLI, NUM_CC, SALDO_CC, COD_BCO) BANCO (COD_BCO, DES_BCO) 3a. Forma Normal : ausência de dependências funcionais transitivas CLIENTE (COD_CLI, NOM_CLI, COD_CLA) TEL_CLI (COD_CLI, TEL_CLI) CONTAS (COD_CLI, NUM_CC, SALDO_CC, COD_BCO) BANCO (COD_BCO, DES_BCO) CLASSE (COD_CLA, DES_CLA)



68

Normalização 12 Normalizar a relação FOLHA até a 3FN Folha de Pagamento (FOLHA) - Nos DEPARTAMENTOS trabalham vários FUNCIONÁRIOS - Na folha de pagamento dos FUNCIONÁRIOS constam várias rubricas de

PROVENTOS e DESCONTOS (PD). FOLHA = (MAT_FUN, NOM_FUN, {COD_PD}, {DES_PD}, {COMP_FOL}, {VALOR_FOL}, SIG_DEP, DES_DEP) 1a. Forma Normal: ausência de atributos multivalorados FUNCIONARIO (MAT_FUN, NOM_FUN, SIG_DEP, DES_DEP) FOLHA (MAT_FUN, COD_PD, DES_PD, COMP_FOL, VALOR_FOL) 2a. Forma Normal: ausência de dependências funcionais parciais FUNCIONARIO (MAT_FUN, NOM_FUN, SIG_DEP, DES_DEP) PD (COD_PD, DES_PD) FOLHA (MAT_FUN, COD_PD, COMP_FOL, VALOR_FOL) 3a. Forma Normal: ausência de dependências funcionais transitivas DEPARTAMENTO(SIG_DEP, DES_DEP) FUNCIONARIO (MAT_FUN, NOM_FUN, SIG_DEP) PD (COD_PD, DES_PD) FOLHA (MAT_FUN, COD_PD, COMP_FOL, VALOR_FOL)



69

Exercício de Engenharia Reversa Nos exercícios anteriores, obtivemos o Modelo Lógico normalizado. Para cada um deles, elabore o Modelo Conceitual.



70

Capítulo 3

Álgebra Relacional



71

A Álgebra Relacional A álgebra relacional é uma coleção de operações canônicas (do grego KÁNON - regra, regra geral onde se inferem regras especiais) utilizadas para manipular as relações. Estas operações são utilizadas para selecionar tuplas de relações individuais e para combinar tuplas relacionadas de relações diferentes para especificar uma consulta em um determinado banco de dados. O resultado de cada operação também pode ser manipulado pela álgebra relacional. É utilizada a letra grega σ (sigma) para demonstrar a condição de seleção e π (pi) para definir a lista de atributos. Portanto a “sintaxe” seria algo assim: CONSULTA = π atributos σ condição (relação ) Adotaremos o seguinte Banco de Dados para nossos primeiros exemplos:

Figura 43 MODELO LÓGICO DEPTO( cod_d, desc_d) PROJETO( cod_p, desc_p, local) EMPREGADO( rg, nome, salário, rg_sup, cod_d) DEPENDENTES ( rg, nome, nasc, relacao, sexo) TRABALHA ( rg, cod_p)

DEPTO

cod_d

(1,n)

EMPREGADO

POSSUI

desc_d

(1,1)

nome

Projeto(0,n)

cod_p des_p

Trabalha(0,n)

POSSUI

Dependente

nome

nasc

relacao

sexo

RG

salario(0,n)

(1,1)

local

POSSUI

supervisionado

supervisor

(1,n)

(1,1)



72

Conteúdo das bases de dados

EMPREGADO RG NOME SALARIO COD_D RG_SUP1 Rodrigo 1.000,00 1 62 Renato 1.500,00 3 23 Fernanda 2.500,00 2 34 Roberta 1.000,00 1 65 Flávia 500,00 3 26 Vera 3.000,00 1 67 Leonardo 1.000,00 1 68 Carla 500,00 3 29 Camilo 1.200,00 2 310 Lúcio 1.200,00 2 311 Cleôncio 5.000,00 - 11

DEPENDENTES

RG NOME NASC SEXO RELAÇÃO 1 Bruna 01/01/1987 F Filho(a) 1 Júlia 04/10/1960 F Esposa(o) 3 José 03/05/1991 M Filho(a) 4 João 10/10/1990 M Filho(a) 5 Verônica 15/08/1980 F Filho(a)

PROJETO

COD_P DESC_P LOCAL 1 FINANC SP 2 CONTAB RJ 3 SAUDE MG 4 ESTOQUE ES

DEPTO

COD_D DESC_D 1 Análise 2 Programação 3 Operação

TRABALHA

RG COD_P 1 1 2 2 3 3 4 3 5 2 6 1 7 3 8 2 9 1 10 1 1 2 6 3 5 1 7 2



73

A Operação Select A operação select é utilizada para selecionar um subconjunto de tuplas de uma relação, sendo que estas tuplas devem satisfazer uma condição de seleção. A forma geral de uma operação select é: σ condição_de_seleção (nome_da_relação) condição_de_seleção é uma expressão booleana aplicada sobre os atributos da relação nome_da_relação é o nome da relação sobre a qual será aplicada a operação select. As operações relacionais que podem ser aplicadas na operação select são:

< Menor que > Maior que

<= Menor ou igual >= Maior ou igual = Igual

<> ou != Diferente além dos operadores booleanos:

And E Or Ou Not Negação

A operação select é unária, ou seja, só pode ser aplicada a uma única relação. Não é possível aplicar a operação sobre tuplas de relações distintas. Exemplos: CONSULTA01 = σ salário < 1.500,00 (EMPREGADO)

EMPREGADO RG NOME SALARIO COD_D RG_SUP1 Rodrigo 1.000,00 1 64 Roberta 1.000,00 1 65 Flávia 500,00 3 27 Leonardo 1.000,00 1 68 Carla 500,00 3 29 Camilo 1.200,00 2 310 Lúcio 1.200,00 2 3

CONSULTA02 = σ relacao = “Filho(a)” e sexo = “F” (DEPENDENTES)

DEPENDENTES RG NOME NASC SEXO RELAÇÃO 1 Bruna 01/01/1987 F Filho(a) 5 Verônica 15/08/1980 F Filho(a)



74

A Operação Project A operação project seleciona um conjunto determinado de colunas de uma relação. A forma geral de uma operação project é: π lista_de_atributos (nome_da_relação) A letra grega π (pi) representa a operação project, lista_de_atributos representa a lista de atributos que o usuário deseja selecionar; nome_da_relação representa a relação sobre a qual a operação project será aplicada. CONSULTA03 = π nome, nasc (DEPENDENTES)

DEPENDENTES NOME NASC Bruna 01/01/1987 Júlia 04/10/1960 José 03/05/1991 João 10/10/1990 Verônica 15/08/1980 Seqüencialidade de Operações As operações project e select podem ser utilizadas de forma combinada, permitindo que apenas determinadas colunas de determinadas tuplas possam ser selecionadas. A forma geral de uma operação seqüencializada é: π lista_de_atributos σ condição_de_seleção (nome_da_relação) CONSULTA04= π nome, salário, cod_d σ salário >= 1.500,00 (EMPREGADO)

EMPREGADO NOME SALARIO COD_D Renato 1.500,00 3 Fernanda 2.500,00 2 Vera 3.000,00 1 Cleôncio 5.000,00 - Apesar de mais elegante, a consulta4 também pode ser escrita da seguinte forma: CONSULTA05 = σ salário >= 1.500,00 (EMPREGADO)



75

CONSULTA06 = π nome, salário, cod_d (CONSULTA05) Operações Matemáticas Levando em consideração que as relações podem ser tratadas como conjuntos, podemos então aplicar um conjunto de operações matemáticas sobre as mesmas. Estas operações são: união (∪) , interseção (∩) e diferença (−). Este conjunto de operações não é unário, ou seja, podem ser aplicadas sobre mais de uma tabela, porém, existe a necessidade das tabelas possuírem tuplas exatamente do mesmo tipo. Estas operações podem ser definidas da seguinte forma: união - o resultado desta operação representada por R ∪ S é uma relação T que inclui todas as tuplas que se encontram em R e todas as tuplas que se encontram em S; interseção - o resultado desta operação representada por R ∩ S é uma relação T que inclui as tuplas que se encontram em R e em S ao mesmo tempo; diferença - o resultado desta operação representada por R − S é uma relação T que inclui todas as tuplas que estão em R mas não estão em S. Selecione todos os empregados que trabalham no departamento número 2 ou que supervisionam empregados que trabalham no departamento número 2. Vamos primeiro selecionar todos os funcionários que trabalham no departamento número 2. CONSULTA07 = σ cod_d = 2 (EMPREGADOS)

EMPREGADO RG NOME SALARIO COD_D RG_SUP3 Fernanda 2.500,00 2 39 Camilo 1.200,00 2 310 Lúcio 1.200,00 2 3

Vamos agora selecionar o supervisor dos empregados que trabalham no departamento número 2. CONSULTA08 = π rg_sup (CONSULTA07) EMPREGADO

RG_SUP 3



76

Vamos projetar apenas o RG dos empregados selecionados: CONSULTA09 = π rg (CONSULTA07) EMPREGADO

RG 3 9 10

E por fim vamos unir as duas tabelas, obtendo o resultado final CONSULTA10 = CONSULTA08 U CONSULTA09 EMPREGADO

RG 3 3 9 10

Vamos selecionar todos os empregados que desenvolvem algum projeto e que trabalham no departamento número 2. Para isso, primeiro devemos selecionar todos os empregados que trabalham em algum projeto: CONSULTA11 = π rg (TRABALHA) TRABALHA

RG 1 2 3 4 5 6 7 8 9 10

Agora, vamos selecionar empregados que trabalham no departamento 2: CONSULTA12 = π rg σ (depto=2) (EMPREGADO) EMPREGADO

RG 3 9 10



77

Com a consulta a seguir, obteremos todos os empregados que trabalham no departamento 2 e que desenvolvem algum projeto CONSULTA13 = CONSULTA11 ∩ CONSULTA12 EMPREGADO

RG 3 9 10

Para selecionar todos os empregados que não desenvolvem projetos, devemos inicialmente selecionar os que trabalham em algum projeto CONSULTA14 = π rg (TRABALHA) TRABALHA

RG 1 2 3 4 5 6 7 8 9 10

...e a seguir, quem é empregado CONSULTA15 = π rg (EMPREGADO) EMPREGADO

RG 1 2 3 4 5 6 7 8 9 10 11



78

...finalmente, quem é empregado e não está trabalhando em nenhum projeto. CONSULTA16 = CONSULTA15 - COLSULTA14 CONSULTA16

RG 11

Produto Cartesiano O produto cartesiano é uma operação binária que combina todas as tuplas de duas tabelas. Diferentemente da operação união, o produto cartesiano não exige que as tuplas das tabelas possuam exatamente o mesmo tipo. O produto cartesiano permite então a consulta entre tabelas relacionadas utilizando uma condição de seleção apropriada. O resultado de um produto cartesiano é uma nova tabela formada pela combinação das tuplas das tabelas sobre as quais aplicou-se a operação. O formato geral do produto cartesiano entre duas tabelas R e S é:

R x S. Exemplo: CONSULTA17 =(PROJETO) x (DEPTO)

CONSULTA17 COD_D DESC_D COD_P DESC_P 1 Análise 1 Financ 1 Análise 2 Contab 1 Análise 3 Saude 1 Análise 4 Estoque 2 Programação 1 Financ 2 Programação 2 Contab 2 Programação 3 Saude 2 Programação 4 Estoque 3 Operação 1 Financ 3 Operação 2 Contab 3 Operação 3 Saude 3 Operação 4 Estoque Vamos agora selecionar as tuplas resultantes que estão devidamente relacionadas que são as que possuem o mesmo valor em número do projeto e número e cuja localização seja ‘SP’. CONSULTA18 = (TRABALHA x PROJETO)



79

CONSULTA19 = π t.rg, p.cod_p σ t.cod_p = p.cod_p e p.local = “SP” (CONSULTA18) A operação produto cartesiano não é muito utilizada por não oferecer um resultado otimizado. Veja o item seguinte. Operação Junção A operação junção atua de forma similar à operação produto cartesiano, porém, a tabela resultante conterá apenas as combinações das tuplas que se relacionam de acordo com uma determinada condição de junção. A forma geral da operação junção entre duas tabelas R e S é a seguinte:

R x [condição_de_ junção] S Vamos refazer as consultas 18 e 19. CONSULTA20 = π t.rg, p.cod_p σ t.cod_p = p.cod_p e p.local=“SP” (TRABALHA x PROJETO)

CONSULTA19 T.RG P.COD_P

1 1 6 1 9 1 10 1 5 1

O resultado será o mesmo, porém com mais eficiência.



80

Capítulo 4

Structured Query Language – SQL Data Definition Language - DDL

Data Manipulation Language- DML



81

SQL - Structured Query Language SQL é um conjunto de declarações que é utilizado para acessar os dados utilizando gerenciadores de banco de dados. Nem todos os gerenciadores utilizam SQL. SQL não é uma linguagem baseada em procedimentos, pois processa conjuntos de registros, ao invés de um por vez, provendo navegação automática através dos dados, permitindo ao usuário manipular tipos complexos de dados. SQL pode ser utilizada para todas as atividades relativas a um banco de dados podendo ser utilizada pelo administrador de sistemas, pelo DBA, por programadores, sistemas de suporte à tomada de decisões e outros usuários finais. Definição de Dados Utilizando SQL Comando CREATE TABLE O comando CREATE TABLE permite ao usuário criar uma nova tabela (ou relação). Para cada atributo da relação é definido um nome, um tipo, máscara e algumas restrições. Os tipos mais comuns de uma coluna são: char(n): caracteres e strings onde n é o número de caracteres; integer: inteiros float: ponto flutuante; decimal(m,n): onde m é o no. de casas inteiras e n o no. de casas decimais. A nomenclatura destes tipos varia de acordo com o banco de dados adotado. A restrição not null indica que o atributo deve ser obrigatoriamente preenchido; se não for especificado, então o default é que o atributo possa assumir o valor nulo. A forma geral do comando CREATE TABLE então é:

CREATE TABLE <nome_tabela> ( <nome_coluna1><tipo_coluna1><NOT NULL>, <nome_colunan><tipo_colunan><NOT NULL>);

Para criar a tabela EMPREGADOS teríamos o seguinte comando:

CREATE TABLE EMPREGADO ( rg integer NOT NULL, nome nvarchar(50) NOT NULL, salario money NOT NULL cod_d integer NOT NULL, rg_sup integer NOT NULL, );



82

Comando DROP TABLE O comando DROP TABLE permite a exclusão de uma tabela (relação) em um banco de dados. A forma geral para o comando DROP TABLE é:

DROP TABLE <nome_tabela>; Por exemplo, para eliminar a tabela EMPREGADOS faríamos:

DROP TABLE EMPREGADO; Observe que neste caso, a chave da tabela EMPREGADO, (rg) é utilizada como chave estrangeira ou como chave primária composta em diversos tabelas que devem ser devidamente corrigidas. Este processo não é assim tão simples pois, como vemos neste caso, a exclusão da tabela EMPREGADO implica na alteração do projeto físico de diversas tabelas. Isto acaba implicando na construção de uma nova base de dados. Comando ALTER TABLE O comando ALTER TABLE permite que o usuário faça a inclusão de novos atributos em uma tabela. A forma geral para o comando ALTER TABLE é a seguinte:

ALTER TABLE <nome_tabela> ADD <nome_coluna> <tipo_coluna>;

No caso do comando ALTER TABLE, a restrição NOT NULL não é permitida pois assim que se insere um novo atributo na tabela, o valor para o mesmo em todas as tuplas da tabela receberão o valor NULL. Manipulando dados utilizando a SQL Selecionando dados - SELECT O comando SELECT permite a seleção de tuplas e atributos em uma ou mais tabelas. A forma básica para o uso do comando SELECT é:

SELECT <lista de atributos> FROM <lista de tabelas> [WHERE <condições>];

Por exemplo, para selecionar o nome e o rg dos funcionários que trabalham no departamento número 2 na tabela EMPREGADOS utilizamos o seguinte comando:



83

SELECT nome, rg FROM EMPREGADO WHERE cod_d = 2; CONSULTA21= π nome, rg σ intdepto=2 (EMPREGADO)

EMPREGADO NOME RG Fernanda 3 Camilo 9 Lucio 10 Também é permitido o uso de condições múltiplas. Veja o exemplo a seguir: SELECT nome, rg, salario FROM EMPREGADO WHERE depto = 2 AND salario >= 2.500.00; CONSULTA22 = π nome, rg, salario σ depto=2 e salario >= 2.500,00 (EMPREGADO)

EMPREGADO NOME RG Fernanda 3 A operação select-from-where em SQL pode envolver quantas tabelas forem necessárias. Exemplo: selecione o código e o nome do departamento que controla projetos localizados em “MG”; SELECT DISTINCT d.cod_d, d.desc_d FROM depto d, projeto p, trabalha t, empregado e WHERE p.local = “MG” AND p.cod_p = t.cod_p AND t.rg = e.rg AND e.cod_d = d.cod_d;

DEPTO COD_D DESC_D 1 Análise 2 Programação Na expressão SQL acima, d, p, t e e são chamados alias (apelidos) e representam a mesma tabela a qual estão referenciando. Um alias é muito importante quando há redundância nos nomes das colunas de duas ou mais tabelas que estão envolvidas em uma expressão. Ao invés de utilizar o alias, é possível utilizar o nome da tabela, mas isto pode ficar cansativo em consultas muito complexas além do que, impossibilitaria a utilização da mesma tabela mais que uma vez em uma expressão SQL. Considere a seguinte consulta: selecione o rg, nome e nome do supervisor.



84

SELECT e1.rg, e1.nome, e2.nome FROM empregado e1, empregado e2 WHERE e1.rg_sup = e2.rg; em álgebra relacional: CONSULTA23 =π nome, rg σ e1.rg = e2.rg_sup(EMPREGADO e1 x EMPREGADO e2)

EMPREGADO RG NOME NOME_SUP 1 Rodrigo Vera 2 Renato Renato 3 Fernanda Fernanda 4 Roberta Vera 5 Flávia Renato 6 Vera Vera 7 Leonardo Vera 8 Carla Renato 9 Camilo Fernanda 10 Lúcio Fernanda 11 Cleôncio Cleôncio

O operador (*) especificado na cláusula select seleciona todos os atributos de uma tabela, enquanto que a exclusão da cláusula where faz com que todas as tuplas de uma tabela sejam selecionadas. SELECT * FROM empregado; Diferente de álgebra relacional, a operação SELECT em SQL permite a geração de tuplas duplicadas como resultado de uma expressão. Para evitar isto, devemos utilizar o especificador DISTINCT. Veja a seguir os exemplos. Sem DISTINCT SELECT cod_d FROM empregado; EMPREGADO

COD_D 1 3 2 1 3 1 1 3 2 2 -



85

Com DISTINCT SELECT distinct cod_d FROM empregado; EMPREGADO

COD_D 1 2 2

Podemos gerar consultas aninhadas em SQL utilizando o especificador IN, que faz uma comparação do especificador WHERE da consulta mais externa com o resultado da consulta mais interna. Considere a consulta a seguir: selecione o nome de todos os funcionários que trabalham em projetos localizados em Rio Claro; SELECT e.nome, e.rg, e.cod_d FROM empregado e, trabalha t WHERE e.rg = t.rg AND t.cod_p in (SELECT cod_p

FROM projeto WHERE local = “SP”);

EMPREGADO NOME RG COD_D Rodrigo 1 1 Flávia 5 3 Vera 6 1 Camilo 9 2 Lúcio 10 2 Para selecionar um conjunto de tuplas de forma ordenada devemos utilizar o comando ORDER BY. Leve em consideração a seguinte consulta: selecione todos os empregados por ordem alfabética: SELECT nome, rg, cod_d FROM empregado ORDER BY nome;

EMPREGADO Nome RG COD_D Camilo 9 2 Carla 8 3 Cleôncio 11 - Fernanda 3 2 Flávia 5 3 Leonardo 7 1 Lúcio 10 2 Renato 2 3 Roberta 4 1 Rodrigo 1 1 Vera 6 1



86

Inserções, Atualizações e Exclusões Para elaborar inserções em SQL, utiliza-se o comando INSERT INTO. A forma geral para o comando INSERT INTO é:

INSERT INTO <nome da tabela> <(lista de colunas)> VALUES <(lista de valores)>;

Insira na tabela empregados, os seguintes dados: RG NOME SALARIO COD_D RG_SUP21 Jorge G. 150,00 3 222 João da C. 200,00 3 -

INSERT INTO empregado VALUES (21,”Jorge G.”, 150,00, 3, 2);

INSERT INTO empregado (rg, nome, cod_d, salario) VALUES (22, ”Joao de C.”, 3, 200,00);

Como no primeiro exemplo, todos os campos foram inseridos e não foi necessário especificar o nome das colunas. Na segunda inserção, o campo rg_sup não foi inserido, então especificou-se as colunas. Outra forma de se elaborar esta inserção seria:

INSERT INTO empregado VALUES (22, “João de C.”, 200.00, 3, “”);

Neste caso, utilizou-se os caracteres “” (aspas) para informar que um valor nulo seria inserido nesta coluna. Para se efetuar uma alteração em uma tabela, é utilizado o comando UPDATE. A forma geral do comando UPDATE é:

UPDATE <tabela> SET <coluna> = <expressão> WHERE <condição>

Considere a seguinte declaração: atualize o salário de todos os empregados que trabalham no departamento 2 para R$ 3.000,00;

UPDATE empregado SET salario = 3.000,00 WHERE cod_d = 2;

Para se eliminar uma tupla de uma tabela, utiliza-se o comando DELETE. A forma geral do comando DELETE é:

DELETE FROM <tabela> WHERE <condição>;



87

Elimine os registros nos quais o empregado trabalhe no departamento 3 e possua salário <= R$ 200,00;

DELETE FROM empregado WHERE salario <= 200,00 AND cod_d = 3;

(estas inserções foram feitas anteriormente) Nos casos de atualização que foram vistos, todas as <condições> podem ser uma consulta utilizando o comando SELECT, onde o comando será aplicado sobre todos os registros que satisfizerem as condições determinadas pelo comando de seleção.

Banco de Dados VENDAS



89

SQL – Passo a passo ERA do Banco de dados Vendas

Figura 44

CLIENTE

COD_C NOME_C END_C CIDADE CEP UF CPF_CGC IE

720 Ana Rua Dez 19 Niteroi 25352-131 RJ 111111111111-11 54654

870 Flávio Av P Vargas 10

São Paulo 15546-464 SP 222222222222-22 32132

110 Jorge Rua Caiapo 13

Curitiba 30000-311 SP 333333333333-33 8979

222 Lucia Rua Itabira 123

Belo Horizonte

54654-812 MG 444444444444-44

830 Pedro Av Paulista 1235

São Paulo 98610-132 SP 555555555555-55 5646

130 Edmar Rua da Prai s/n

Salvador 12144-568 BA 666666666666-66 8987

410 Rodolfo Largo da Lapa 27

Rio de Janeiro

23546-876 RJ 777777777777-77 218

20 Elisabeth Av Climério 45

São Paulo 45665-455 SP 888888888888-88 21325

157 Livio Tv Moraes c/3

Londrina 12345-874 PR 999999999999-99 23121

180 Susana Av Baira Mar 200

Florianópolis

98511-321 SC 010101010101-01

260 Renato Rua Mendes 56

Niteroi 12131-545 RJ 020202020202-02 21544

290 Sebastião Rua Meireles 98

São Paulo 32012-112 SP 030303030303-03 184879

390 Jose Rua da Igreja 14

Uberaba 54645-477 MG 040404040404-04 189410

234 Paulo Av Rio Branco 1

Brasília 26448-253 DF 050505050505-05 21213

VENDEDOR

COD_V NOME_V SALARIO COMISSAO

CLIENTE

cod_d

PEDIDOFAZ

desc_d

(1,1)

POSSUI

ITENSPEDIDO

qtd

num_p

(0,n)

(1,1)

(0,n)

CGCIE

UFCEPcidadeend_c

PE

VENDEDOR

cod_v

PREENCHE

nome_v

(1,1)

salário

comissão

REQUISITA(1,1)

PRODUTO

cod_p desc_punidade

VU

(0,n)

(0,n)



90

209 Jose 1.800,00 C

111 Carlos 2.490,00 A

123 João Sinval 2.780,00 C

240 Antonio 900,00 C

720 Felipe 4.600,00 A

213 Jonas 2.300,00 A

101 João Silva 2.300,00 C

310 Josias 870,00 C

250 Bonifácio 2.930,00 B

PRODUTO

COD_P DESC_P UNIDADE VU

25 Queijo Kg 0,97

31 Chocolate Bar 0,87

78 Vinho L 2,00

22 Linho M 0,11

30 Açúcar Sac 0,30

53 Linha M 1,80

13 Ouro G 0,18

45 Madeira M 0,25

87 Cano M 1,98

77 Papel Res 1,05

PEDIDO

NUM_P PE COD_C COD_C

121 20 410 209

97 20 720 101

101 15 720 101

137 20 720 720

148 20 720 101

189 15 870 213

104 30 110 101

203 30 830 250

98 20 410 209

143 30 20 111

105 15 180 240

111 20 260 240

103 20 60 11

91 20 260 11

138 20 260 11

108 15 290 310

119 30 390 250

127 10 410 11

ITENS PEDIDO

NUM_P COD_P QTD



91

121 25 10

121 31 35

97 77 20

101 31 9

101 78 18

101 13 5

98 77 5

148 45 5

148 31 8

148 25 7

148 78 10

104 53 30

203 31 32

189 78 6

143 31 45

143 78 20

105 78 10

111 78 10

103 53 70

91 77 37

138 22 40

138 77 10

138 53 35

108 13 18

119 77 17

119 13 40

119 22 6

119 53 10

137 13 43

189 5 8

Selecionando informações de uma tabela - SELECT...FROM SELECT desc_p, unidade, VU FROM Produto SELECT nome_c, CGC FROM Cliente SELECT * FROM Vendedor Obs.: o caracter ‘*’ seleciona todas as colunas da tabela. Impondo condições à seleção das informações - WHERE SELECT *



92

FROM Produto WHERE desc_p = ‘PREGO’ Obs.: quando o tipo de <nome da coluna> for caracter, devemos colocar <valor> entre ‘ ‘ (aspas simples). Devemos lembrar também que, para o <valor>, letras MAIÚSCULAS diferem das minúsculas. Operadores Operadores Relacionais = Igual <> ou != Diferente < Menor que > Maior que <= Menor ou igual >= Maior ou igual

SELECT num_p, cod_p, qtd FROM item_pedido WHERE qtd >= 35 SELECT nome_c FROM cliente WHERE cidade = ‘RIO DE JANEIRO’

Operadores Lógicos AND E OR Ou NOT Negação

SELECT desc_p FROM produto WHERE unidade = ‘M’ and VU = 1.05 SELECT nome_c, endereco FROM cliente WHERE CEP >= ‘30077000’ AND CEP <= ‘30079000’ OR cidade = ‘SÃO PAULO’ SELECT num_p FROM pedido WHERE NOT pe = 15

Operadores EXISTS e NOT EXISTS



93

Selecionar pedidos de vendedores que não mais trabalham na empresa e já foram eliminados da tabela vendedores. SELECT * FROM pedido p WHERE NOT EXISTS ( SELECT v.cod_v

FROM vendedor v WHERE v.cod_v = p.cod_v )

Operadores BETWEEN e NOT BETWEEN

SELECT cod_p, desc_p FROM produto WHERE VU BETWEEN 0.32 AND 2.00

Operadores IN e NOT IN SELECT nome_v FROM vendedor WHERE comissao IN (‘A’, ‘B’) Operadores LIKE e NOT LIKE Obs.: atuam apenas sobre os campos do tipo caracter e pode ser utilizado com os caracteres “%”, na substituição de palavras ou o “_”, substituindo um caracter. SELECT cod_p, desc_p FROM produto WHERE desc_p LIKE ‘LAPIS%’ SELECT cod_p, desc_p FROM produto WHERE desc_p LIKE ‘BROCA N_’ SELECT cod_p, desc_p FROM produto WHERE unidade LIKE ‘K_’ SELECT cod_v, nome_v FROM vendedor WHERE nome_v NOT LIKE ‘Jo%’ Operadores IS NULL e IS NOT NULL SELECT * FROM cliente WHERE IE IS NULL Ordenando as informações selecionados - ORDER BY



94

SELECT nome_v, salario FROM vendedor ORDER BY nome_v SELECT nome_c, cidade, UF FROM cliente ORDER BY UF DESC, cidade DESC SELECT desc_p, VU FROM produto WHERE unidade = ‘M’ ORDER BY 2 ASC Obs.: o número 2 refere-se ao segundo atributo da cláusula SELECT Efetuando cálculos com a informação selecionada SELECT nome_v, salario * 1.75 + 120 AS aumento FROM vendedor WHERE comissao = ‘C’ ORDER BY nome_v Utilizando funções sobre conjuntos de informações - MAX e MIN (Máximo e mínimo)

SELECT MIN(salario), MAX(salario) FROM vendedor

- SUM (Somatório)

SELECT SUM(qtd) FROM item_pedido WHERE cod_p = 78

- AVG (Média) SELECT AVG(salario) FROM vendedor

- COUNT

SELECT COUNT(*) FROM vendedor WHERE salario > 2500.00

Eliminando as informações repetidas – DISTINCT

SELECT DISTINCT unidade FROM produto Agrupando as informações selecionadas – GROUP BY SELECT num_p, COUNT(*) AS Total_Produtos FROM item_pedido GROUP BY num_p Agrupando de forma condicional – HAVING SELECT num_p, COUNT(*) AS Total_Produtos FROM item_pedido



95

GROUP BY num_p HAVING COUNT(*) >= 3 Recuperando informações de várias tabelas – JOIN SELECT c.nome_c, p.cod_c, p.num_p FROM cliente c, pedido p WHERE c.cod_c = p.cod_c Clientes de SP ou RJ, com prazo de entrega superior a 15 dias. SELECT c.nom_c, c.UF, p.PE FROM cliente c, pedido p WHERE UF IN (‘SP’, ‘RJ’) AND p.PE > 15 AND c.cod_c = p.cod_c Utilizando apelidos – ALIAS Substitui o uso dos qualificadores, normalmente o nome da própria tabela, por apelidos. SELECT v.nome_v, p.PE FROM vendedor v, pedido p WHERE v.salario >= 1000 AND p.PE > 15 AND v.cod_v = p.cod_v Juntando várias tabelas SELECT c.nome_c FROM cliente c, pedido p, item_pedido ip, produto pr WHERE c.cod_c – p.cod_c AND p.num_p = ip.num_p AND ip.cod_p = pr.cod_p AND p.PE > 15 AND p.desc_p = ‘QUEIJO’ AND c.UF = ‘RJ’ ORDER BY c.nome_c Vendedores que venderam ‘CHOCOLATE’ com quantidade > 10 Kg. SELECT DISTINCT v.nome_v FROM vendedor v, pedido p, item_pedido ip, produto pr WHERE v.cod_v = p.cod_v AND p.num_p = ip.num_p AND ip.cod_p = pr.cod_p AND ip.qtd > 10 AND pr.desc_p = ‘CHOCOLATE’ Quantos clientes fizeram pedidos com o vendedor ‘JOAO’ SELECT COUNT(p.cod_c)



96

FROM cliente c, pedido p, vendedor v WHERE c.cod_c = p.cod_c

AND p.cod_v = v.cod_v AND v.nome_v = ‘JOAO’

Quantos clientes do RJ e ES tem pedidos com a vendedora ‘MARIA’ SELECT UF, COUNT(c.nome_c) FROM cliente c, pedido p, vendedor v WHERE v.nome_v = ‘MARIA’ AND UF IN (‘RJ’, ‘ES’) AND v.cod_v = p.cod_v AND p.cod_c = c.cod_c GROUP BY UF Utilizando consultas encadeadas (SubQueries) Produtos que foram pedidos com quantidade superior a 10

SELECT desc_p FROM produto WHERE produto IN (SELECT cod_p FROM item_pedido

WHERE qtd > 10) Vendedores com salário abaixo da média SELECT v.nome_v FROM vendedor v WHERE v.salario < (SELECT AVG(v1.salario) FROM vendedor v1 ) Produtos que NÃO estão presentes em nenhum pedido SELECT p.cod_p, p.desc_p FROM produto p WHERE NOT EXISTS (SELECT * FROM item_pedido ip WHERE p.cod_p = ip.cod_p ) Vendedores que só venderam produtos cuja unidade = ‘Gr’ (grama) SELECT DISTINCT v.cod_v, v.nome_v FROM vendedor v WHERE ‘G’ = ALL

(SELECT p.unidade FROM produto p,

item_pedido ip produto pr

WHERE p.num_p = ip.num_p AND ip.cod_p = pr.cod_p

AND p.cod_v =v.cod_v )



97

Produtos que não estão presentes em nenhum pedido SELECT p.cod_p, p.desc_p FROM produto p WHERE NOT EXISTS (SELECT * FROM item_pedido ip WHERE ip.cod_p = p.cod_p ) Clientes que estão presentes em mais de 3 pedidos SELECT c.nome_c FROM cliente c WHERE EXISTS (SELECT COUNT(*)

FROM pedido p WHERE p.cod_c = c.cod_c GROUP BY p.cod_c HAVING COUNT(*) > 3 )

Adicionando registros INSERT INTO produto VALUES (108,’Kg’,’PARAFUSO’,1.25) Adicionando registros de outra tabela INSERT INTO (cod_v, nome_v, salario, comissao) SELECT * FROM vendedor_old Atualizando um registro UPDATE produto SET VU = VU * 1.25 WHERE unidade = ‘Kg’ Excluindo um registro DELETE

FROM vendedor WHERE comissao IS NULL DELETE FROM pedido p WHERE NOT EXISTS (SELECT cod_v FROM vendedor WHERE cod_v = p.cod_v )



98

Como funciona o Produto Cartesiano Tabelas envolvidas

Funcionário F Trabalha T Projeto P COD_F NOM_F NASC_F COD_F COD_P COD_P DESC_P F1 Jose 01/12/1980 F1 P1 P1 Projeto 1 F2 Maria 15/06/1975 F1 P2 P2 Projeto 2 F3 João 26/11/1972 F2 P1 P3 Projeto 3 F3 P3 Produto Cartesiano

Produto Cartesiano entre F x T x P)

COD_F NOM_F NASC_F COD_F COD_P COD_P DESC_P

F1 Jose 01/12/1980 F1 P1 P1 Projeto 1












F2 Maria 15/06/1975 F1 P1 P1 Projeto 1












F3 João 26/11/1973 F1 P1 P1 Projeto 1














99

Problema proposto Desejo saber o nome dos funcionários e a descrição dos projetos nos quais trabalham SELECT f.nom_f, des_p FROM funcionario f, trabalha t, projeto p WHERE f.cod_f = t.cod_f AND t.cod_p = p.cod_p NOM_F DESC_P Jose Projeto 1 Jose Projeto 2 Maria Projeto 1 João Projeto 2 Como funcionam as funções de agregação (agrupamento) Problema proposto Desejo saber a quantidade de Funcionários e o somatório dos seus salários, por Departamento, exibindo também seu código e descrição.

FUNCIONÁRIO DEPARTAMENTO COD_F NOM_F SAL_F COD_D COD_D DES_D F1 Jose 5.000,00 D1 D1 DRH F2 Maria 2.500,00 D3 D2 ENG F3 João 1.500,00 D3 D3 INFO F4 Carla 2.700,00 D3 F5 Sergio 6.000,00 D2 F6 Antônio 1.500,00 D1 F7 Vera 2.500,00 D3 F9 Leo 600,00 D1 F10 Edu 1.200,00 D1 Um código fonte orientado a procedimentos, geraria um relatório assim... (talvez sem as repetições de códigos e descrições) D1 DRH 1.500,00

D1 DRH 600,00

D1 DRH 1.200,00

3 3.300,00

D2 ENG 5.000,00

D2 ENG 6.000,00

2 11.000,00

D3 INFO 2.500,00

D3 INFO 1.500,00

D3 INFO 2.700,00

D3 INFO 2.500,00

4 9.200,00



100

Observamos abaixo, a construção do comando SQL, com funções de agregação e o resultado obtido. SELECT d.cod_d,

d.des_d, count(d.doc_d) qtd, sum(f.sal_f) soma

FROM Funcionario F, Departamento D WHERE d.cod_d = f.cod_d GROUP BY d.cod_d, d.des_d ORDER BY d.cod_d COD_D DES_D QTD SOMA D1 DRH 3 3.300,00 D2 ENG 2 11.000,00 D3 INFO 4 9.200,00



101

SQL 1 Com base no Diagrama de Entidade, Relacionamento e Atributos abaixo, responda às questões a seguir.

Figura 45 1) Derive o modelo conceitual para o modelo lógico 2) Com base no ERA, resolva os SQL propostos abaixo. a) Funcionário (NOM_F) e os projetos nos quais Trabalha (COD_P), ordenado

por NOM_F b) Departamento (COD_D) e seus Funcionários (NOM_F), ordenado por Código

do Departamento (COD_D) c) Quantidade de projetos nos quais o Funcionário (NOM_F) Trabalha (QTD) d) Funcionário (COD_F, NOM_F) com somatório de QH >= a 50 HORAS e) Departamento (COD_D, DES_D) com custo salarial >= R$ 5.000 f) Funcionário (COD_F, NOM_F) com SAL_F entre R$200 e R$1.000 g) Departamento (COD_D, DES_D) com menos de 3 Funcionários h) Funcionário (COD_F, NOM_F) com o nome iniciado por JOAO i) Funcionário (NOM_F, SAL_F) e o salário aumentado em 23% j) Departamento (COD_D, DES_D) que não possui Funcionários

DEPARTAMENTO

POSSUI

FUNCIONÁRIO

COD_F

COD_D

(1,n)

(1,1)

DES_D

TRABALHA(1,1)

PROJETO

COD_P DES_P

(0,n)

NOM_F SAL_F

QH



102

SQL 1 – Área para respostas



103

SQL 2 Com base no Diagrama de Entidade, Relacionamento e Atributos abaixo, responda às questões a seguir.

Figura 46 1) Derive o modelo conceitual para o modelo lógico 2) Com base no ERA, resolva os SQL propostos abaixo. a) ESCOLA (CGC, RAZÃO) e os PROFESSORES (NOME) que nela trabalham b) ALUNO (NOME) e as DISCIPLINAS (DES) que cursa c) ALUNO (NOME) que ainda não cadastrou seu email d) PROFESSOR (NOME) e a exibição de seu salário aumentado em 25% e) DISCIPLINAS (DES) e seus PRE-REQUISITOS (DES) f) Quantidade (QTD) de PROFESSORES na ESCOLA (RAZÃO) g) PROFESSOR (NOME, SAL) que ganham mais de R$ 1.000,00, ordenado, de

forma descendente, pelo atributo SAL h) PROFESSOR (NOME) e as DISCIPLINAS (DES) que leciona i) ALUNOS (NOME) que NÃO estão cursando nenhuma disciplina j) PROFESSORES (NOME) que lecionam DISCIPLINAS (DES) que contenham na

sua descrição, a palavra “DADOS” k) ALUNOS (NOME, NASC) nascidos entre “01/01/75” e “31/12/80”

PROFESSOR

LECIONA

DISCIPLINAS

COD

(1,n)

(1,n)

CURSA(1,n)

ALUNO(1,n)

DES

ESCOLA

POSSUI

SAL

CGC

(1,n)

RAZÃO

NOMEMAT

(1,1)

EMAILNOMEMAT

CURSA

É requerida

Requer



104

SQL - Exercícios de SQL 2 – Área para respostas



105

Capítulo 5

Stored Procedures Triggers e

Views



106

Views - Visões Uma visão (VIEW) é uma forma alternativa de acessar os dados contidos em uma ou mais tabelas. Para definir uma visão, usa-se o comando SELECT que faz uma consulta sobre as tabelas. A visão aparece depois como se fosse uma tabela. Visões têm as seguintes vantagens: - Pode restringir quais as colunas da tabela que podem ser acessadas

(para leitura ou para modificação), o que é útil no caso de controle de acesso, como veremos mais tarde. Uma consulta SELECT que é usada muito freqüentemente pode ser criada como visão. Com isso, a cada vez que ela é necessária, basta selecionar dados da visão.

- Podem conter valores calculados ou valores de resumo, o que simplifica a operação.

- Pode ser usada para exportar dados para outras aplicações. Criando uma visão com o Enterprise Manager Para criar uma visão com o Enterprise Manager, expanda um grupo de servidores, então o servidor em que está o banco de dados onde será criada a visão. Clique com o botão direito em Views. Aparece uma tela quase idêntica a do Query Designer.

Figura ??

Na janela superior (logo abaixo dos ícones, chamada de seção do diagrama, clique com o botão direito, e selecione Add Table. Na guia Tables (ou Views, caso você já tenha criado alguma visão e queira que ela faça parte desta que está sendo criada), selecione a tabela (ou visão) a ser adicionada, e então clique Add. Caso você queira remover



107

alguma tabela adicionada ao diagrama, clique na mesma com o botão direito e selecione Remove. Repita tantas vezes quantas forem as tabelas (ou visões) a serem adicionadas à nova visão. Clique em Close quando tiver escolhido todas as tabelas (ou visões) desejadas. Na caixa Column da seção da grade (parte da janela logo abaixo de onde estão as tabelas adicionadas), selecione as colunas a serem referenciadas na visão. Note que caso haja mais de uma tabela na seção do diagrama, quando você for selecionar a coluna na seção da grade, aparecerá o nome completo da coluna (tabela. coluna). Marque a caixa Output se a coluna deve ser mostrada no resultado da visão. Note que você também pode escolher as colunas que farão parte da visão, selecionando-as na representação gráfica da tabela, mas as colunas selecionadas dessa maneira farão parte da saída por padrão. Para que não apareçam na saída, desmarque a caixa Output. Para agrupar por alguma coluna, clique com o botão direito na coluna (na seção da grade) e selecione Group By. Na coluna Criteria, digite o critério especificando quais linhas retornar; isso determina a cláusula WHERE. Se GROUP BY for especificado, isso determina a cláusula HAVING. Na coluna Or... entre com qualquer critério adicional para especificar quais linhas a serem retornadas. Clique com o botão direito em qualquer lugar da seção da grade, e então selecione Properties. - "Output all columns" mostrará todas as linhas da visão no resultado; - "DISTINCT values" filtra os valores duplicados no resultado; - "Encrypt view" criptografa a definição da visão; - Opcionalmente, em "Top", entre com o número de linhas a serem

retornadas no resultado. Digite a palavra PERCENT depois do número para mostrar uma porcentagem das linhas, no resultado.

Clique com o botão direito em qualquer lugar da seção do diagrama; clique então em Run (para ver o resultado) ou Save (para salvar a visão). Note que na seção SQL, aparece o código SQL do SELECT envolvido na criação da visão. Criando uma visão com comandos SQL Para criar uma visão através de SQL, use o comando CREATE VIEW. Esse comando tem a seguinte sintaxe:



108

CREATE VIEW nome_visão [(coluna [,...n])] [WITH ENCRYPTION] AS declaração_SELECT [WITH CHECK OPTION]

nome_visão é o nome a ser dados à visão coluna é o nome a ser usado para uma coluna em uma visão. Nomear uma coluna em CREATE VIEW só é necessário quando uma coluna é obtida por uma expressão aritmética, uma função, ou uma constante, ou quando duas ou mais colunas poderiam ter o mesmo nome (freqüentemente por causa de uma junção), ou quando a coluna em uma visão recebe um nome diferente do nome da coluna da qual se originou. Os nomes de colunas também podem ser atribuídos no comando SELECT. Caso você queira nomear mais de uma coluna, entre com o nome de cada uma separado por vírgulas. WITH ENCRYPTION: criptografa as entradas na tabela syscomments que contém o texto do comando CREATE VIEW. WITH CHECK OPTION: força todas as modificações de dados executadas na visão a aderirem aos critérios definidos na declaração_SELECT. Quando uma coluna é modificada através de uma visão, WITH CHECK OPTION garante que os dados permaneçam visíveis através da visão depois que as modificações forem efetivadas. Vamos criar uma visão no banco de dados Exemplo, usando as tabelas 'Produto', 'Fornecedor' e 'ProdutoFornecedor'. Essa visão vai mostrar o nome do fornecedor e o nome do produto. Crie-a digitando o texto abaixo no Query Analyzer:

create view VisaoFornecProduto as select f.Nome NomeFornecedor, p.Nome NomeProduto from Fornecedor f inner join ProdutoFornecedor pf

on f.CodFornecedor = pf.CodFornecedor inner join Produto p

on pf.CodProduto = p.CodProduto Para criar uma visão você deve estar posicionado no banco de dados onde a visão será criada ou então especificá-lo através da cláusula USES. Ao criar uma visão, o texto do comando acima é armazenado na tabela syscomments. Agora, para testar, digite:

select * from VisaoFornecProduto O resultado terá as colunas 'NomeFornecedor' e 'NomeProduto', mostrando os dados relacionados entre elas. Você pode também criar uma visão que calcula valores usando colunas das tabelas, ou usando GROUP BY e funções agregadas, na declaração SELECT.



109

Alterando ou excluindo uma visão Para alterar uma visão, você pode usar tanto o Enterprise Manager quanto o comando SQL, ALTER VIEW. Para alterá-la com o Enterprise Manager, selecione a visão que se quer alterar, clique na mesma com o botão direito e selecione Design View. Aparecerá a mesma janela vista na criação da visão com o Enterprise Manager, e aí você pode fazer as alterações que julgar necessárias à visão, salvar as alterações, executar a visão, etc.. Tudo da mesma forma que se você estivesse criando uma nova visão. O comando SQL ALTER VIEW tem a seguinte sintaxe:

ALTER VIEW nome_visão [(coluna [,...n])] [WITH ENCRYPTION] AS declaração_select [WITH CHECK OPTION]

Todas as considerações feitas a respeito do comando CREATE VIEW se aplicam aqui. Caso você não se lembre do comando usado na criação da visão (o comando CREATE VIEW) , você pode obtê-lo usando o procedimento sp_helptext, da forma:

sp_helptext VisaoFornecProduto Este texto é consultado na tabela syscomments. Algumas linhas podem aparecer quebradas no resultado. É importante considerar que a alteração de uma visão não afeta os procedimentos armazenados ou gatilhos dependentes da mesma e não altera as permissões atribuídas à mesma Modificando dados através de uma visão Você pode executar um comando UPDATE em uma visão. Se ela foi baseada em uma única tabela, isso não provoca grandes problemas. Se a opção WITH CHECK OPTION acima for usada, as atualizações devem satisfazer as condições da cláusula WHERE usada na criação da visão. Inserções com INSERT também podem ser feitas. Se a visão é baseada em duas ou mais tabelas, a atualização só é possível se o comando altera dados de apenas uma tabela. Colunas calculadas não podem ser alteradas. Se foram usadas funções de agregação, também não é possível modificar os dados através da visão. Na inserção, se uma coluna de uma tabela subjacente não permite nulos (NOT NULL), não é possível inserir linhas na visão, pois isso deixaria a coluna sem valor.



110

Stored Procedure - Procedimentos Armazenados Um procedimento armazenado (STORED PROCEDURE) é um conjunto de comandos SQL que são compilados e armazenados no servidor que podem ser chamados a partir de um comando SQL qualquer. Em versões anteriores do SQL Server, os procedimentos armazenados eram uma maneira de pré-compilar parcialmente um plano de execução. Quando da criação do procedimento armazenado, um plano de execução parcialmente compilado era armazenado em uma tabela de sistema. A execução de um procedimento armazenado era mais eficiente do que a execução de um comando SQL, porque o SQL Server não precisava compilar um plano de execução completamente, apenas tinha que terminar a otimização do plano armazenado para o procedimento. Além disso, o plano de execução completamente compilado para o procedimento armazenado era mantido na cache de procedimentos do SQL Server, significando que execuções posteriores do procedimento armazenado poderiam usar o plano de execução pré compilado. A versão 7.0 do SQL Server apresenta várias mudanças no processamento de comandos que estendem muitos dos benefícios de desempenho dos procedimentos armazenados para todos os comandos SQL. O SQL Server 7.0 não salva um plano parcialmente compilado para os procedimentos quando os mesmos são criados. Um procedimento armazenado é compilado em tempo de execução como qualquer outro comando Transact-SQL. O SQL Server 7.0 mantém planos de execução para todos os comandos SQL na cache de procedimentos, não apenas planos de execução de procedimentos armazenados. Ele então usa um algoritmo eficiente para comparação de novos comandos Transact-SQL com os comandos Transact-SQL de planos de execução existentes. Se o SQL Server 7.0 determinar que um novo comando Transact-SQL é o mesmo que um comando Transact-SQL de um plano de execução existente, ele reutiliza o plano. Isso reduz o ganho relativo de desempenho, na pré compilação de procedimentos armazenados, já que estende a reutilização de planos de execução para todos os comandos SQL. A vantagem de usar procedimentos armazenados é que eles podem encapsular rotinas de uso freqüente no próprio servidor, e estarão disponíveis para todas as aplicações. Parte da lógica do sistema pode ser armazenada no próprio banco de dados, em vez de ser codificada várias vezes em cada aplicação. Criando procedimentos armazenados Para criar um procedimento, use o comando CREATE PROCEDURE. Por exemplo, o procedimento abaixo recebe um parâmetro (@nome) e mostra todos os clientes cujo nome contenha o nome informado:



111

create procedure BuscaCliente @nomeBusca varchar(50) as

select CodCliente, Nome from Cliente where Nome like '%' + @nomeBusca + '%'

Note que os parâmetros são sempre declarados com @, logo após o nome do procedimento. Um procedimento pode ter zero ou mais parâmetros. Declara-se o nome do procedimento, e a seguir o tipo de dados do parâmetro. Nota: ao invés de CREATE PROCEDURE, pode-se utilizar CREATE PROC, com o mesmo efeito. Dentro do procedimento pode haver vários comandos SELECT e o resultado desses comandos será o resultado do procedimento. O corpo do procedimento começa com a palavra AS e vai até o final do procedimento. Não se pode usar os comandos SET SHOWPLAN_TEXT, e SET SHOWPLAN_ALL dentro de um procedimento armazenado, pois os mesmos devem ser os únicos comandos de um lote (BATCH). Dentro de um procedimento, nomes de objetos usados em alguns comandos devem ser qualificados com o nome do proprietário do objeto, se outros usuários utilizarão o procedimento armazenado. Os comandos são: ALTER TABLE CREATE INDEX DROP TABLE DROP INDEX TRUNCATE TABLE UPDATE STATISTICS Todos os comandos DBCC Executando procedimentos armazenados Para executar um procedimento, utiliza-se o comando EXEC (ou EXECUTE). A palavra "EXEC" pode ser omitida se a chamada de procedimento for o primeiro comando em um script ou vier logo após um marcador de fim de lote (a palavra "GO"). Por exemplo, execute o procedimento anterior da seguinte forma:

BuscaCliente 'an' O resultado será as linhas da tabela Cliente onde o valor de Nome contém 'an' (se existirem tais linhas). Ao executar um procedimento, você pode informar explicitamente o nome de cada parâmetro, por exemplo:

BuscaCliente @nomeBusca = 'an' Isso permite passar os parâmetros (se mais de um) fora da ordem em que eles foram definidos no procedimento.



112

EXEC também pode executar um procedimento em outro servidor. Para isso, a sintaxe básica é:

EXEC nome_servidor.nome_banco_de_dados..nome_procedimento Comandos para uso em procedimentos armazenados Você pode declarar uma variável em um procedimento e usá-la para guardar valores. Por exemplo, exclua o procedimento anterior e crie-o novamente como abaixo:

drop procedure BuscaCliente go create procedure BuscaCliente @nomeBusca varchar(50) as declare @contagem int, @mensagem char(100)

select CodCliente, Nome from Cliente where Nome like '%' + @nomeBusca + '%'

conta quantas linhas foram encontradas

select @contagem = count(*) from Cliente where Nome like '%' + @nomeBusca + '%' if @contagem = 0 begin

select @mensagem = 'Nenhum cliente contém "'+@nomeBusca+'"' print @mensagem print ""

end O comando DECLARE declara variáveis, que são sempre introduzidas pelo caractere @. No caso, @contagem é uma variável do tipo int e @mensagem do tipo char(100). Note que quando você usa um comando SELECT, o resultado pode ser colocado numa variável, como @contagem acima. Esse resultado não aparece no resultado do SELECT. Essa é também a única forma de alterar uma variável (você não pode escrever '@variável = valor' diretamente). O comando IF verifica uma condição e executa um comando caso a condição seja verdadeira. Se acompanhado da cláusula ELSE, executa um outro comando caso a condição seja falsa. O comando PRINT usado acima é geralmente usado para mostrar mensagens, que aparecem quando você chama o procedimento interativamente. Os comandos BEGIN e END são usados para delimitar uma lista de comandos, que passa a ser tratada como um comando único. No caso acima, eles são necessários para poder executar três comandos dentro do IF (o SELECT e os dois PRINT).



113

Criando procedimentos armazenados com o Enterprise Manager

Também é possível a criação de procedimentos armazenados através do Enterprise Manger. Para isso, deve-se expandir um grupo de servidores, um servidor, e o banco de dados onde o procedimento armazenado será criado. Clique então com o botão direito em Stored Procedures, e selecione New Stored Procedure. Aparece uma tela como abaixo Nessa tela você deve dar o nome que desejar ao procedimento, substituindo o texto em preto [PROCEDURE NAME] pelo nome que você quer dar ao procedimento armazenado sendo criado. Logo depois do AS, você deve entrar com o código do procedimento armazenado, conforme descrito acima. Você pode após entrar com o código desejado, clicar no botão Check Syntax, que verificará se há erros de sintaxe nas declarações SQL. Quando tiver terminado de entrar com o código do procedimento, basta clicar em OK que o mesmo será criado. Triggers - Gatilhos Um gatilho (TRIGGER) é um tipo de procedimento armazenado, que é executado automaticamente quando ocorre algum tipo de alteração em uma tabela. Gatilhos "disparam" quando ocorre uma operação INSERT, UPDATE ou DELETE sobre um determinada tabela.



114

Geralmente gatilhos são usados para reforçar restrições de integridade que não podem ser tratadas pelos recursos mais simples, como regras, DEFAULTS, restrições, a opção NOT NULL etc. Deve-se usar DEFAULTS e restrições quando eles fornecem toda a funcionalidade necessária. Um gatilho também pode ser usado para calcular e armazenar valores automaticamente em outra tabela, como veremos a seguir. Exemplo de gatilhos Para utilizar gatilhos, vamos criar antes algumas tabelas que serão usadas como exemplo. A tabela "NotaFiscal" conterá os cabeçalhos de notas fiscais. A tabela "ItemNotaFiscal" irá conter itens de nota fiscal relacionados com as notas fiscais. Execute o script abaixo para criar as tabelas:

create table NotaFiscal (NumeroNota numeric(10) primary key, ValorTotal numeric(10,2) default (0)

) GO create table ItemNotaFiscal

(NumeroNota numeric(10) foreign key references NotaFiscal, CodProduto int foreign key references Produto, Quantidade int not null check (Quantidade > 0), primary key (NumeroNota,CodProduto)

) Vamos usar gatilhos para duas finalidades: primeiro, quando for excluída uma nota fiscal, todos os seus itens serão excluídos automaticamente. Depois, quando for incluído um item, a coluna 'ValorTotal' será atualizada, na tabela 'NotaFiscal'. Criando gatilhos Gatilhos são sempre criados vinculados a uma determinada tabela. Se a tabela for excluída, todos os gatilhos dela são excluídos como conseqüência. Ao criar um gatilho, você pode especificar qual(is) a(s) operação(ões) em que ele será acionado: INSERT, UPDATE ou DELETE. Gatilhos para inserção Quando é feita a inclusão de uma ou mais linhas na tabela, o SQL Server cria uma tabela virtual chamada inserted, que contém as linhas que serão incluídas (mas ainda não foram). Essa tabela tem a mesma estrutura da tabela principal e pode-se consultar dados nessa tabela com o comando SELECT, da mesma forma que uma tabela normal.



115

Vamos criar um gatilho, chamado InclusaoItemNota, que será ativado por uma operação INSERT na tabela ItemNotaFiscal. Primeiro ele vai verificar se os valores sendo inseridos possuem uma NotaFiscal relacionada ou não. Para isso, digite o seguinte comando: create trigger InclusaoItemNota on ItemNotaFiscal for insert as

if not exists ( select * from inserted, NotaFiscal where inserted.NumeroNota =

NotaFiscal.NumeroNota) raiserror('Esse item não contém um número de nota válido') update NotaFiscal set ValorTotal = ValorTotal

+ (select i.Quantidade * p.Preço from Produto p, inserted i where p.CodProduto = i.CodProduto)

where NumeroNota = (select NumeroNota from inserted) Primeiro o gatilho usa as tabelas inserted e NotaFiscal para consultar se existe o valor de NumeroNota na tabela. Caso não exista, o comando RAISERROR gera um erro de execução, com uma mensagem que será retornada para a aplicação. Esse comando efetivamente cancela o comando INSERT que estiver sendo executado. Depois verifica a quantidade que está sendo inserida (inserted.Quantidade) e multiplica pelo preço do produto (Produto.Preço). Esse preço é obtido na tabela de produtos, usando como valor de pesquisa o código do produto inserido (inserted.CodProduto). Ele atualiza a nota fiscal relacionada com o item que está sendo inserido (para isso verifica where NumeroNota=(select NumeroNota from inserted)). Gatilhos para exclusão Na exclusão, as linhas da tabela são removidas e colocadas na tabela virtual deleted, que tem a mesma estrutura da tabela principal. Um gatilho para exclusão pode consultar deleted para saber quais as linhas excluídas. Vamos criar um gatilho, na tabela NotaFiscal para, quando a nota fiscal for excluída, todos os seus itens de nota relacionados, na tabela ItemNotaFiscal, sejam excluídos em cascata. Execute o seguinte:

create trigger ExclusaoNota on NotaFiscal for delete as -- excluir todos os itens relacionados -- (mesmo NumeroNota que deleted)

delete from ItemNotaFiscal where NumeroNota in (select NumeroNota from deleted)



116

Gatilhos para atualização As tabelas inserted e deleted, como já vimos, são tabelas virtuais que podem ser usadas dentro de um gatilho. A primeira contém os dados que estão sendo inseridos na tabela real e a segunda contém os dados antigos, que estão sendo incluídos. Num gatilho de atualização (FOR UPDATE), essas duas tabelas também estão disponíveis. No caso, deleted permite acessar os dados como eram antes da modificação e inserted permite acessar os dados depois da atualização. Podemos então considerar uma atualização como uma exclusão seguida de uma inserção (excluem-se valores antigos e inserem-se valores novos). Por exemplo, ao mudar a Quantidade em um ItemNotaFiscal, o total da nota deve ser recalculado. Para isso, é preciso levar em conta a diferença entre a quantidade antiga (deleted.Quantidade) e a nova (inserted.Quantidade). Vamos criar um gatilho em ItemNotaFiscal que faz isso:

create trigger AlteracaoItemNota on ItemNotaFiscal for update as if update(Quantidade) or update(CodProduto) begin

update NotaFiscal set ValorTotal = ValorTotal +

(select p.Preço * (i.Quantidade - d.Quantidade) from Produto p inner join inserted i on p.CodProduto = i.CodProduto inner join deleted d on i.CodProduto = d.CodProduto and i.NumeroNota = d.NumeroNota)

end Note acima o uso de 'if update(nome_da_coluna)'. Dentro de um gatilho de atualização, isso permite descobrir se a coluna está sendo alterada ou não. Isso para evitar trabalho desnecessário se não estiver sendo modificada uma dessas colunas. Criando gatilhos para múltiplas ações Um gatilho pode ser criado para uma tabela para múltiplas operações nessa tabela. Por exemplo, para criar um gatilho usado em INSERT, UPDATE e DELETE, usa-se uma sintaxe, como:

create trigger nome_do_gatilho on nome_da_tabela for INSERT, UPDATE, DELETE as texto_do_gatilho

Outros comandos



117

Em gatilhos, assim como em procedimentos armazenados, é possível declarar variáveis e usar comandos como IF, BEGIN..END etc. Alguns comandos não são permitidos dentro de um gatilho. Estes são: ALTER DATABASE ALTER PROCEDURE ALTER TABLE ALTER TRIGGER ALTER VIEW CREATE DATABASE CREATE DEFAULT CREATE INDEX CREATE PROCEDURE CREATE RULE CREATE SCHEMA CREATE TABLE CREATE TRIGGER CREATE VIEW DENY DISK INIT DISK RESIZE DROP DATABASE DROP DEFAULT DROP INDEX DROP PROCEDURE DROP RULE DROP TABLE DROP TRIGGER DROP VIEW GRANT LOAD DATABASE LOAD LOG RESTORE DATABASE RESTORE LOG REVOKE RECONFIGURE TRUNCATE TABLE UPDATE STATISTICS



118

Capítulo 6

Criação de um Banco de Dados

ORACLE SQL SERVER

ACCESS



119

Oracle SQL SERVER Access



120

Trabalhos

Trabalhos

- Acompanhamento de Processos - Solicitação de Serviços - Sistema de Estoque



121

Mini-mundo do Sistema de Acompanhamento de Processos Elabore o ERA e a Derivação das tabelas O departamento jurídico da empresa DataVenia está sendo informatizado. Verificou-se então a necessidade de controlar e acompanhar o andamento dos processos sob responsabilidade deste departamento. As informações básicas de um PROCESSO, extraídas da ficha ACOMPANHAMENTO DE PROCESSOS, são as seguintes: número do processo, se a DataVenia é Ré ou Autora (R ou A), nome da comarca, nome da vara de execução, código do tipo da ação, uf da filial (onde o processo ocorre), número do processo de origem, status do andamento, valor estimado, data início e data fim. A empresa DataVenia pode ser acionada ou estar acionando uma pessoa física/jurídica, que são chamadas de PARTE. As PARTES possuem as seguintes informações: código, nome, endereço, telefone, física/jurídica (F ou J), email. Na parte de trás da ficha, reservada para anotações de acompanhamento do processo, constam as seguintes informações: data do acompanhamento, que é uma anotação do fato ocorrido ou compromisso futuro, uma breve observação e a data de alerta, quando for o caso, para que toda a documentação possa ser preparada para o dia agendado (compromisso futuro). Em cada filial da empresa, são registradas as seguintes informações: sigla da uf, nome do gerente, telefone e email. Cada Tipo de Ação possui as seguintes informações: código do tipo da ação e descrição. Observações: a) somente são cadastradas informações necessárias; b) um PROCESSO pode ter várias PARTES envolvidas e a PARTE pode se envolver em vários

processos; c) os status possíveis de um PROCESSO são fixos e nunca mudarão cujos códigos

previstos são os seguinte códigos: AP-Arquivado e Procedente, AI-Arquivado e Improcedente, AA-Arquivado com Acordo, EA-Em andamento, AC-Ação cancelada d) os TIPOS DE AÇÃO serão determinados e cadastrados pelos usuários; São requisitos de informação: a) Partes envolvidas em quais processos; b) Acompanhamentos de um processo; c) Valor total estimado por UF; d) processos por tipo de ação; e) filiais com mais processos AP onde somos autores (A/R igual a A);



122

Mini-mundo do Sistema de Solicitações de Serviços Elabore o ERA e a Derivação das tabelas A empresa de consultoria CPEDE EUFAÇO, é responsável pelo desenvolvimento e manutenção de sistemas e o controle de todo o hardware de vários clientes. Os clientes são vistos como “usuários emissor”. Com o crescimento da quantidade de solicitações para estes serviços, estava sendo necessária a criação de um sistema que controlasse tais pedidos. As informações básicas de uma SOLICITAÇÃO, extraídas do formulário que atualmente é utilizado, são as seguintes: número da solicitação, data e hora de emissão, código do serviço solicitado, especificação do serviço, sistema ao qual a solicitação está associada, data e hora da recepção da solicitação, usuário emissor, usuário receptor, usuário que executará o serviço, data e hora do inicio do serviço, data e hora do final do serviço, solução dada à solicitação, algum tipo de observação, tempo utilizado para a conclusão do serviço e os STATUS, situações nas quais a solicitação pode ser encontrada. Os possíveis STATUS (situações) que as solicitações podem se encontar são os seguintes: N – Não foi recepcionada pela empresa (como um eMail não lido); R – Recepcionada pela empresa (usuário receptor) ; A – Alocada a um profissional (usuário executor); E – Encerrada pelo profissional, o trabalho foi totalmente executado; P - Encerrada pelo profissional, o trabalho foi parcialmente executado; C – O usuário solicitante cancelou a solicitação; F – O usuário solicitante concordou que tudo o que foi solicitado foi executado. Periodicamente, são gerados relatórios ou consultas exibidas no terminal. Observações: a) somente são cadastradas informações necessárias; b) uma SOLICITAÇÃO está alocada a somente um SISTEMA; c) uma SOLICITAÇÃO normalmente é emitida, recebida e executada por usuários distintos e

eventualmente recebida e executada pelos mesmos usuários ; d) os USUÁRIOS, os SISTEMAS, os TIPOS DE SERVIÇO e TIPOS DE STATUS, são criados e

mantidos por funcionários da empresa CPEDE EUFAÇO e) Solicitações anteriores a três anos e com a situação F, podem ser copiadas para uma

tabela de expurgo e devem ser eliminadas. São requisitos de informação: a) Nome do Executor e as solicitações em aberto, por executor; b) Nome do Sistema e a quantidade de solicitações em aberto, por Sistema; c) Nome do Executor e quantidade de solicitações em aberto, por Executor; d) Nome do Executor, a quantidade de solicitações encerradas e o tempo total consumido,

por Executor; e) Expurgar solicitações Canceladas, Fechadas ou Pendentes com três anos, ou mais, de

conclusão;



123

Mini-mundo do Sistema de Estoque Elabore o ERA e a Derivação das tabelas A empresa de CPRICIZA EUTIDÔ, deseja controlar as requisições de materiais feitas pelos seus diversos departamentos, por intermédio de um sistema informatizado permitindo aos usuários fazerem suas solicitação diretamente nas estações de trabalho. Foi elaborado um estudo, baseado em reuniões com o Departamento de Informática e deste trabalho, resultou a seguinte lista de premissas: - Deverão ser criadas CATEGORIAS e SUBCATEGORIAS, ambas contendo código e

descrição. É nas SUBCATEGORIAS que serão enquadrados os MATERIAIS; - Foi criada uma padronização para os tipos de UNIDADE DE ARMAZENAGEM com código,

descrição e sigla. Por exemplo: 001 - RESMA DE PAPEL XEROX – RES; - Cada MATERIAL possui as seguintes características: código, descrição, estoque mínimo,

ponto de compra, saldo atual e valor unitário; - As REQUISIÇÕES serão vinculadas aos DEPARTAMENTOS, código e descrição; - Uma REQUISIÇÃO, pertence a um DEPARTAMENTO, possui um número, data de emissão

e data de atendimento; - Cada REQUISIÇÃO pede no mínimo um ITEM, com a quantidade solicitada; - Os item solicitados estão associados a MATERIAIS preexistentes no sistema, ou seja, o

usuário não solicita materiais que NÃO estejam cadastrados; - Para efetivar a baixa do estoque, cada item solicitado e atendido, gera uma

MOVIMENTAÇÃO com a quantidade atendida, que pode ser diferente da quantidade solicitada e a data na qual foi efetivado o atendimento. Existem ITENS que podem não ser atendidos;

- Cada MOVIMENTO possui um TIPO DE MOVIMENTO, padronizado e cadastrado previamente com código e descrição. Por exemplo: 01-Entrada, 02-Saída, 03-Acerto a mais, 04-Acerto a menos etc...

- Cada MOVIMENTO, pode ter uma JUSTIFICATIVA, pois a quantidade atendida, pode estar completamente fora dos padrões e isto deve ser descrito e armazenado, para futuras auditorias.

Serão necessários, inicialmente, os seguintes relatórios: a) Lista de REQUISIÇÕES não atendidas e seus ITENS, para que o funcionário do setor

possa efetuar o atendimento; b) Relatório contendo a quantidade de MATERIAIS movimentados, por DEPARTAMENTO; c) Relatório com os MATERIAS que precisam ser repostos. Este materiais são identificados

quando o saldo atual fica menor ou igual ao ponto de compra; d) MATERIAIS que estão abaixo do estoque mínimo; e) DEPARTAMENTOS, a quantidade de itens consumidos e a soma de suas quantidades em

um determinado período de atendimento



124

Bibliografia recomendada

DATE, C. J., Introdução a Sistema de Bancos de Dados, Tradução da 7ª edição americana, Editora Campus, 2000

ELMASRI, R. e NEVATHE S.B., Fundamentals of Database System, LTC 2000

SILBERSCHATZ, A., KORTH, H. F. e SUDARSHAN, S., Sistemas de

Bancos de Dados, Editora Makron Books, 1999 HEUSER, C.A, Projeto de Banco de Dados, Sagra Luzatto, 1998 MELO, Rubens N., Bancos de Dados em Aplicações Cliente/Servidor,

IBPI, Infobook, 1997 KROENKE, D.M, Bancos de Dados: Fundamentos, Projetos e

Implementação, 6ª edição, Editora LTC – 1999 DATE, C. J., Guia para o padrão SQL, Editora Campus, 1999 RAMALHO, J.A., SQL: A Linguagem dos Bancos de Dados, Editora

Berkeley, 1999 ERWin – Logic Works – Platinum Technology Microsoft SQL Server – Books On Line

Bibliografia complementar

BARBIERI, Carlos – Modelagem e Administração de Dados – Ed. Infobook, 1994

COOD, E.F.; The Relational Model for Databases Systems,. Addison-Wesley

FURTADO, Antonio Luiz; Organização de Bases de Dados, Campus, 1993 HACKATHORN, Richard D.; Conectividade de Banco de Dados, Infobook,

1993 MACHADO, Felipe Nery Rodrigues, Projeto de Banco de Dados, Érica,

1998 SETZEK, Valdemar Waingort; Banco de Dados, E. Blücher, 1989 ORFALI, HARKEY, D. & Edwards J.;The Essential Client/Server Survival

Guide, Wiley Computer Publishing, 1996 RAMAKRISHNAN, R.;Database Managemente Systems, McGraw-Hill,

1998 MELO, Rubens N.;Bancos de Dados em Aplicações Cliente/Servidor O’NEIL, P. e O’NEIL, E., Database: Principles, Programming and

Performance, Editora Morgen Kaufmann Publishers, 2ª Edição, 2000 INMON, W.H.;Como Construir o Data Warehouse, Campus., 1997 System Architect, Data Architetch – Popkin Software & Systems Inc.



125

Respostas

- Mini mundos - Engenharia Reversa - Exercícios de SQL - Trabalhos



126

Resposta do Mini mundo 1


APARELHO TROCA CLIENTE

(0,1)

(0,n)

nomedata

endereço

DEFEITUOSO

marca

série

modelo

COMPRA (0,n)

Data

defeito(0,1)

SUBSTITUTO

(0,1)

IMÓVEL

COMPRA

PROPRIETÁRIO(1,1)

(0,n)

nome

data

Telefone (0,1)

preço

CPF

endereço

(0,n)

Preço mínimo (0,1)

descrição

endereço

bairro

VENDA(0,n)(0,n)

DataPreço



127



GRAÇOM RESPONSABILIDADE MESA(4,10) (1,1)

número

assentos

nome

ATENDIMENTO

hora_fim

data

(1,n)

PRATO

hora_ini

avaliação

(1,n)

númeronomepreço

(1,n)

EMPREGADO

MÉDICO

(T,S)

matricula

nome

RESPONSABILIDADE

(0,n)

(1,n) (1,1)INTERNAÇÃO

ATENDIMENTO

PESSOA

ENFERMEIRA

(1,n)

(0,n)

(0,n)

seguro social

nascimento

fiminicio código

endereço nome

especialidade cargo

VÍNCULO

(1,3)

HOSPITAL

(1,n)



128

Resposta do Mini mundo 5 (vale um ponto)

CORRETORA

ORDEM DEVENDA

CGC

código

EMITE

AÇÃO

(1,n)

(1,n) (1,n)DETEMCLIENTE

(0,n)

nome saldodt/hcódigo

qtd

desc

NEGOCIA

(1,1)

nome

lote

qtd

preço

(1,n)

seq



129



COMPRADOR

cpf/cgc

(0,n)

COMPOSIÇÃO

COMPRA

PEÇA

(1,n)

(1,n) codigo

statusminimo

saldo

nome

VALORES

POSSUI

(1,n)

(1,1)

data preço

data

qtd

(0,n)

É composta

É componente

email

HOSPITAL REMÉDIOS

CGC

codigo

RECEITUÁRIO

CLIENTE

(0,n)

(1,n) (1,n)CONSULTA

ATENDIMENTO

MÉDICO

(0,n)

(1,n)

(1,4)

nome

telefone

h_fimh_inicio codigo

eMail

CPF

pa

nomedata

celular bipemail

nome endereço

telefone

codigo descrição

ESPECIALIDADE

ESPECIALISTA(1,n)

(1,n)

codigo descricao

inicio status

endereço(1,3)

(1,3)



130



(0,n)

AGRUPAMENTOCONTACONTÁBIL

numero

descrição

MOVIMENTO

POSUI

(1,n)

(1,1)

(1,1)

agrupa

agrupada

seq data

valor

CENTRODE CUSTOVINCULADO

(1,1) (1,n)

codigo

descrição

(1,1)

ALOCA

FUNCIONÁRIO

matricula

telefone(1,3)

INVESTIMENTOS

(P,E)(0,n)

data

ini

MATERIALTÓXICO

MANIPULA

(1,n)

codigo

TME

DEPARTAMENTO

CHEFIA

(1,n)(1,1)

(0,1)

FÁBRICAADMINISTRAÇÃO

bonus

IT

descrição

(1,n)

HORA EXTRA

FAZ

fim

data

inicio

(1,1)

(1,n)

nome

codigo descricao ramal (1,4)

fim



131



CD

FAIXA

(1,n)

(1,n)

MUSICA

CRIA

AUTOR

(1,n)

(1,n)

COD_AUTNOM_AUT

PRODUZGRAVADORA(1,n) (1,1)

CATEGORIZA CATEGORIA(0,n)

MEP_CAT

(1,1)

COD_MUSNOM_MUSDUR_MUS

MAP_CAT

COD_CATCOD_GRA NOM_GRA

END_GRA CON_GRA

URL_GRA

COD_CD NOM_CD

PRE_CD LAN_CD

IND_CD

NUM_FAX

CARTELA

PALPITE

JOGO

numeropontos

conferido

(1,64)

(1,n)

valida

ParticipaTIME(2,2)

ApostaAPOSTADOR(1,n) (1,1)

numerogols_1gols_2

numeronomeimagem

(3,7)

(3,7)

codigonome

mandante

mandatário

email

palpite2pontos

palpite2



132

Respostas do exercício de Engenharia Reversa Normalização 8

Normalização 9

Normalização 10

VendedorCliente

cod_cli nome_cli

(1,n)

(1,n)

cgc_cli ie_cli

(1,n)

cod_vend nome_vend

Item

Possui

Pedido

(1,1)

Possui Produto(1,1) (1,n)

qtd_prod cod_prod desc_prod

unid prod vu prodFi 44

TurmaAluno

cod nome

(1,n)

(1,n)

nasc

(1,1)

cod desc

Disciplina

AlunoDisciplina

Compõe

tel (1,n)

(1,n)

cod desc

PlanoTitular

mat nom

(1,n)

(1,n)

(1,1)

cod des

Dependente

Tem

tel (1,n)

(1,1)

seq nom

Grau(1,n)

cod des

define(1,1)



133

Normalização 11

Normalização 12

ClasseCliente

mat nom

(1,n)

(1,n)

(1,1)

cod des

Contas

Pertence

tel (1,n)

(1,1)

num saldo

Banco(1,n)

cod des

Possui(1,1)

DEPARTAMENTO

SIG_DEP

(1,n)

FUNCIONÁRIO

DES_DEP

(1,1)

MAT_FUN NOM_FUN

PD(1,n)

COD_PD DES_PD

FOLHA(1,n)

COMP_FOL VALOR_FOL



134

SQL - Respostas do Exercício 1 1) DEPARTAMENTO ( COD_D, DES_D )

FUNCIONARIO ( COD_F, NOM_F, SAL_F, COD_D ) PROJETO ( COD_P, DES_P ) TRABALHA ( COD_F, COD_P, CH )

2) a) SELECT F.NOM_F, T.COD_P

FROM Funcionario F, Trabalha T WHERE F.COD_F = P.COD_F ORDER BY F.COD_F

b) SELECT D.COD_D, F.NOM_F FROM Departamento D, Funcionario F WHERE D.COD_D = F.COD_D ORDER BY D.COD_D

c) SELECT F.NOM_F, COUNT(T.COD_P) AS QTD FROM Funcionario F, Trabalha T WHERE F.COD_F = T.COD_F GROUP BY F.NOM_F

d) SELECT F.COD_F, F.NOM_F, SUM(T.CH) AS HORAS FROM Funcionario F, Trabalha T WHERE F.COD_F = T.COD_F GROUP BY F.COD_F, F.NOM_F HAVING SUM(T.CH) >= 50

e) SELECT D.COD_D, D.DES_D, SUM(F.SAL_F) AS CUSTO FROM Departamento D, Funcionario F WHERE D.COD_D = F.COD_D GROUP BY D.COD_D, D.DES_D HAVING SUM(F.SAL_F) >= 5000

f) SELECT F.COD_F, F.NOM_F, F.SAL_F FROM Funcionario F WHERE F.SAL_F BETWEEN 200 AND 1000

g) SELECT D.COD_D, D.DES_D FROM Departamento D WHERE EXISTS (SELECT COUNT(F.COD_F)

FROM Funcionario F WHERE F.COD_D = D.COD_D GROUP BY F.COD_D HAVING COUNT(F.COD_F) >= 3)

h) SELECT F.COD_F, F.NOM_F FROM Funcionario F WHERE F.NOM_F LIKE 'JOAO%'

i) SELECT F.NOM_F, F.SAL_F, F.SAL_F * 1.23 AS AUMENTO FROM Funcionario F

j) SELECT D.COD_D, D.DES_D FROM Departamento AS D WHERE NOT EXISTS (SELECT *

FROM Funcionario F WHERE F.COD_D = D.COD_D)

OU SELECT D.COD_D, D.DES_D FROM Departamento D WHERE D.COD_D NOT IN (SELECT DISTINCT F.COD_D FROM Funcionario F)



135

SQL - Respostas do Exercício 2 1) ESCOLA ( CGC, RAZÃO )

PROFESSOR ( MAT, NOM, SAL, CGC ) DISCIPLINAS ( COD, DES ) ALUNO ( MAT, NOME, EMAIL, NASC ) CURSA ( MAT, COD ) LECIONA ( MAT, COD ) PRE-REQ ( COD, COD_R )

2) a) SELECT E.CGC, E.RAZAO, P.NOM

FROM Escola E, Professor P WHERE E.CGC = P.CGC

b) SELECT A.NOME, D.DES FROM Aluno A, Disciplinas D , Cursa C WHERE A.MAT = C.MAT AND C.COD = D.COD

c) SELECT A.NOM FROM Aluno A WHERE A.EMAIL IS NULL

d) SELECT P.NOME, P.SAL * 1.25 FROM Professor P

e) SELECT D1.DES, D2.DES FROM Disciplinas D1, Pre-Req P, Disciplinas D2 WHERE D1.COD = P.COD AND P.COD_R = D2.COD

f) SELECT E.RAZÃO, COUNT(P.MAT) AS QTD_PROF FROM Professor P, Escola E WHERE E.CGC = P.CGC GROUP BY E.RAZAO

g) SELECT P.NOME FROM Professor P WHERE SAL > 1000 ORDER BY SAL DESCENDING

h) SELECT P.NOME, D.DES FROM Professor P, Leciona L, Disciplina D WHERE P.MAT = L.MAT AND L.COD = D.COD

i) SELECT A.NOME FROM Aluno A, Cursa C WHERE NOT EXISTS (SELECT *

FROM Cursa C WHERE A.MAT = C.MAT )

j) SELECT P.NOME, D.DES FROM Professor P, Leciona L, Disciplina D WHERE P.MAT = L.MAT AND L.COD = D.COD AND D.DES LIKE “%DADOS%”

k) SELECT A.NOME, A.NASC FROM Aluno A WHERE A.NASC BETWEEN “01/01/75” AND “31/12/80”



136

ACIONA

PARTE

(1,1)

vara

númerocomarca

codigo nome

PROCESSO

(1,n)

MOTIVA

origina

originado

(1,1)

(1,n)

ACOMPANHAMENTO

POSSUI

(0,n)

(1,1) data_acomp

data_alerta

observação

POSSUI TIPO ACAO(1,n)

codigo

descricao

POSSUI FILIAL(1,n)

siglatelefone

gerente

endereço

email

telefone

F/J

eMail

(1,1)

(1,1)

A/R

status

Trabalho – Acompanhamento de Processos Modelo Conceitual

Modelo Lógico PROCESSO ( número, comarca, vara, ar, status, tipoacao, siglauf, motivador ) FILIAL ( sigla, descricao, gerente, email ) TIPOACAO ( codigo, descricao ) PARTE ( codigo, nome, endereco, telefone, fj, email ) ACOMPANHAMENTO ( processo.numero, data_acomp, data_alerta, observação ) PARTE_PROCESSO ( processo.numero, parte.codigo )



137

- Criação do DATABASE CREATE DATABASE Processo ON PRIMARY (NAME=Processo_data, FILENAME='c:\mssql7\data\processo.mdf', SIZE=10MB, MAXSIZE=15MB, FILEGROUTH=25%) LOG ON (NAME=Teste_log, FILENAME='c:\mssql7\data\processo.ldf', SIZE=4MB, MAXSIZE=6MB, FILEGROUTH=2MB) - Criação das TABELAS (juntamente com os CONSTRAINTS) CREATE TABLE Gerencia ( Uf nvarchar (2) not null CONSTRAINT PK_Gerencia PRIMARY KEY NONCLUSTERED, Gerente nvarchar (40) null, Telefone nvarchar (20) null, Email nvarchar (50) null) ON PRIMARY CREATE TABLE Parte ( Parte int not null CONSTRAINT PK_Parte PRIMARY KEY NONCLUSTERED, Nome nvarchar (60) null ) ON PRIMARY CREATE TABLE TipoAcao ( Tipo int not null CONSTRAINT PK_TipoAcao PRIMARY KEY NONCLUSTERED, Descricao nvarchar (80) null ) ON PRIMARY CREATE TABLE Processo ( Processo int not null CONSTRAINT PK_Processo PRIMARY KEY NONCLUSTERED, Comarca nvarchar (30) null, Telefone nvarchar (20) null, TipoAcao int not null CONSTRAINT FK_Processo_TipoAcao FOREIGN KEY REFERENCES TipoAcao (intTipo), Valor money null, Objeto nvarchar (100) null, Uf nvarchar (2) not null CONSTRAINT FK_Processo_Uf FOREIGN KEY REFERENCES Gerencia (intUf), Status nvarchar (2) null, ProcessOrigem int null, DataInicio smalldatetime null, DataFim smalldatetime null, Observacao nvarchar (100) null ) ON PRIMARY CREATE TABLE Acompanhamento ( Processo int not null CONSTRAINT FK_Acompanhamento_Processo FOREIGN KEY REFERENCES Processo (Processo), DataAgenda smalldatetime not null CONSTRAINT PK_Acompanhamento PRIMARY KEY NONCLUSTERED (Processo, DataAgenda), AlertarEm smalldatetime null, Observacao nvarchar (100) null ) ON PRIMARY CREATE TABLE ProcessoParte ( Processo int not null CONSTRAINT FK_ProcessoParte_Processo FOREIGN KEY REFERENCES Processo (Processo), Parte int not null CONSTRAINT FK_ProcessoParte_Parte FOREIGN KEY REFERENCES Parte (Parte) CONSTRAINT PK_ProcessoParte PRIMARY KEY NONCLUSTERED (Processo,Parte) ) ON PRIMARY



138

- Criação das TABELAS (separadas dos CONSTRAINTS) CREATE TABLE Gerencia ( Uf nvarchar (2) not null, Gerente nvarchar (40) null, Telefone nvarchar (20) null, Email nvarchar (50) null) ON PRIMARY CREATE TABLE Parte ( Parte int not null, Nome nvarchar (60) null ) ON PRIMARY CREATE TABLE TipoAcao ( Tipo int not null, Descricao nvarchar (80) null ) ON PRIMARY CREATE TABLE Processo ( Processo int not null, comarca nvarchar (30) null, Telefone nvarchar (20) null, TipoAcao int not null, Valor money null, Objeto nvarchar (100) null, Uf nvarchar (2) not null, Status nvarchar (2) null, ProcessOrigem int null, DataInicio smalldatetime null, DataFim smalldatetime null, Observacao nvarchar (100) null ) ON PRIMARY CREATE TABLE Acompanhamento ( Processo int not null, DataAgenda smalldatetime not null, AlertarEm smalldatetime null, Observacao nvarchar (100) null ) ON PRIMARY CREATE TABLE ProcessoParte ( Processo int not null, Parte int not null ) ON PRIMARY



139

- Criação dos CONSTRAINTS ALTER TABLE Gerencia WITH NOCHECK ADD CONSTRAINT PK_Gerencia PRIMARY KEY NONCLUSTERED (UF) ON PRIMARY ALTER TABLE Parte WITH NOCHECK ADD CONSTRAINT PK_Parte PRIMARY KEY NONCLUSTERED (Parte) ON PRIMARY ALTER TABLE TipoAcao WITH NOCHECK ADD CONSTRAINT PK_TipoAcao PRIMARY KEY NONCLUSTERED (Tipo) ON PRIMARY ALTER TABLE Processo WITH NOCHECK ADD CONSTRAINT PK_Processo PRIMARY KEY NONCLUSTERED (Processo) ON PRIMARY ALTER TABLE Acompanhamento WITH NOCHECK ADD CONSTRAINT PK_Acompanhamento PRIMARY KEY NONCLUSTERED (Processo,DataAgenda) ON PRIMARY ALTER TABLE ProcessoParte WITH NOCHECK ADD CONSTRAINT PK_ProcessoParte PRIMARY KEY NONCLUSTERED (Processo,Parte) ON PRIMARY ALTER TABLE Processo ADD CONSTRAINT FK_Processo_Gerencia FOREIGN KEY (UF) REFERENCES Gerencia (UF), CONSTRAINT FK_Processo_TipoAcao FOREIGN KEY (TipoAcao) REFERENCES TipoAcao (Tipo) ALTER TABLE Acompanhamento ADD CONSTRAINT FK_Acompanhamento_Processo FOREIGN KEY (Processo) REFERENCES Processo (Processo) ALTER TABLE ProcessoParte ADD CONSTRAINT FK_ProcessoParte_Parte FOREIGN KEY (Parte) REFERENCES Parte (Parte), CONSTRAINT FK_ProcessoParte_Processo FOREIGN KEY (Processo) REFERENCES Processo (Processo)

- Eliminando as TABELAS (Primeiro elimina-se os CONSTRAINTS) ALTER TABLE Processo DROP CONSTRAINT FK_Processo_TipoAcao ALTER TABLE Processo DROP CONSTRAINT FK_Processo_Uf ALTER TABLE ProcessoParte DROP CONSTRAINT FK_ProcessoParte_Parte ALTER TABLE Acompanhamento DROP CONSTRAINT FK_Acompanhamento_Processo ALTER TABLE ProcessoParte DROP CONSTRAINT FK_ProcessoParte_Processo if exists (select * from sysobjects where id = object_id(N'Processo') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Processo GO if exists (select * from sysobjects where id = object_id(N'Acompanhamento') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Acompanhamento GO if exists (select * from sysobjects where id = object_id(N'ProcessoParte') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table ProcessoParte GO if exists (select * from sysobjects where id = object_id(N'TipoAcao') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table TipoAcao GO if exists (select * from sysobjects where id = object_id(N'Gerencia') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Gerencia GO if exists (select * from sysobjects where id = object_id(N'Parte') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Parte GO



140

- Inserindo informações - Tabela : TIPOACAO INSERT INTO TipoAcao VALUES (1,'Acoes Trabalhistas') INSERT INTO TipoAcao VALUES (2,'Acoes da Vara de Familia') INSERT INTO TipoAcao VALUES (3,'Acoes contra o INSS') INSERT INTO TipoAcao VALUES (4,'Acoes Criminais') INSERT INTO TipoAcao VALUES (5,'Acoes contra a Tele X') INSERT INTO TipoAcao VALUES (6,'Acoes contra o Ponto Quente') INSERT INTO TipoAcao VALUES (7,'Acoes contra o Bando do Breziu')

- Inserindo informações - Tabela : GERENCIA INSERT INTO Gerencia VALUES ('AC','Almir','33333333','[email protected]') INSERT INTO Gerencia VALUES ('AL','Alfredo','33333333','[email protected]') INSERT INTO Gerencia VALUES ('AM','Jair','33333333','[email protected]') INSERT INTO Gerencia VALUES ('AP','Raul','33333333','[email protected]') INSERT INTO Gerencia VALUES ('BA','Wander','44444444','[email protected]') INSERT INTO Gerencia VALUES ('CE','Jose Carlos','55555555','[email protected]') INSERT INTO Gerencia VALUES ('DF','Jaqueline','66666666','[email protected]') INSERT INTO Gerencia VALUES ('ES','Leia','77777777','[email protected]') INSERT INTO Gerencia VALUES ('GO','Maria da Graça','88888888','[email protected]') INSERT INTO Gerencia VALUES ('MA','Eva','999999999','[email protected]') INSERT INTO Gerencia VALUES ('MT','Mauro','10101010','[email protected]') INSERT INTO Gerencia VALUES ('MS','Tania Silene','12121212','[email protected]') INSERT INTO Gerencia VALUES ('MG','Reginaldo','13131313','[email protected]') INSERT INTO Gerencia VALUES ('PA','Roosevelt','14141414','[email protected]') INSERT INTO Gerencia VALUES ('PB','Maria Ana','15151515','[email protected]') INSERT INTO Gerencia VALUES ('PR','Mauro Pereira','16161616','[email protected]') INSERT INTO Gerencia VALUES ('PE','Sergio','17171717','[email protected]') INSERT INTO Gerencia VALUES ('PI','Raimundo','18181818','[email protected]') INSERT INTO Gerencia VALUES ('RJ','Carlos H','19191919','[email protected]') INSERT INTO Gerencia VALUES ('RN','Pedro Paulo','20202020','[email protected]') INSERT INTO Gerencia VALUES ('RS','Roberto','21212121','[email protected]') INSERT INTO Gerencia VALUES ('RO','Aluizio','23232323','[email protected]') INSERT INTO Gerencia VALUES ('RR','Rosinaldo','24242424','[email protected]') INSERT INTO Gerencia VALUES ('SC','Julio Cesar','25252525','[email protected]') INSERT INTO Gerencia VALUES ('SE','Gildelia','26262626','[email protected]') INSERT INTO Gerencia VALUES ('TO','Ivan','27272727','[email protected]')

- Inserindo informações - Tabela : PARTE INSERT INTO Parte VALUES (1,'Santos Rosendo') INSERT INTO Parte VALUES (2,'Jose Geraldo Junior') INSERT INTO Parte VALUES (3,'Jose Jorge da Silva') INSERT INTO Parte VALUES (4,'Alan Camargo Silva') INSERT INTO Parte VALUES (5,'Tatiana Mendonça Meneses') INSERT INTO Parte VALUES (6,'Sidnei Barbieri Math Jr') INSERT INTO Parte VALUES (7,'Misael Augusto Araujo') INSERT INTO Parte VALUES (8,'Leonardo Lima Oliveira') INSERT INTO Parte VALUES (9,'Carlos Roberto M Soares') INSERT INTO Parte VALUES (10,'Claudio Silva Soares') INSERT INTO Parte VALUES (11,'Katiucia Helena Rosa') INSERT INTO Parte VALUES (12,'Wallace da Silva') INSERT INTO Parte VALUES (13,'Roberto de Deus Leal') INSERT INTO Parte VALUES (14,'Milton Souza Santos') INSERT INTO Parte VALUES (15,'Michel Firmino Souza')

- Inserindo informações - Tabela : PROCESSO INSERT INTO Processo VALUES (1,'Comarca 1','11111111',1,10000.00,'Objeto do processo','RJ','EA','','09/26/2001','','Texto da observacao') INSERT INTO Processo VALUES (2,'Comarca 1','11111111',2,10200.88,'Objeto do processo','MA','EA','','09/25/2001','','Texto da observacao') INSERT INTO Processo VALUES (3,'Comarca 2','22222222',3,20000.00,'Objeto do processo','PI','EA','','09/25/2001','','Texto da observacao') INSERT INTO Processo VALUES (4,'Comarca 2','22222222',4,33000.00,'Objeto do processo','RJ','EA','','08/26/2001','','Texto da observacao') INSERT INTO Processo VALUES (5,'Comarca 3','33333333',5,15000.00,'Objeto do processo','ES','EA','','07/26/2001','','Texto da observacao') INSERT INTO Processo VALUES (6,'Comarca 4','44444444',6,17000.00,'Objeto do processo','MG','EA','','06/26/2001','','Texto da observacao') INSERT INTO Processo VALUES (7,'Comarca 5','55555555',7,23000.00,'Objeto do processo','PA','EA','','09/27/2001','','Texto da observacao')



141

- Inserindo informações - Tabela : PROCESSOPARTE INSERT INTO ProcessoParte VALUES (1,1) INSERT INTO ProcessoParte VALUES (2,2) INSERT INTO ProcessoParte VALUES (3,4) INSERT INTO ProcessoParte VALUES (3,5) INSERT INTO ProcessoParte VALUES (3,6) INSERT INTO ProcessoParte VALUES (4,6) INSERT INTO ProcessoParte VALUES (5,6) INSERT INTO ProcessoParte VALUES (5,9) INSERT INTO ProcessoParte VALUES (6,10) INSERT INTO ProcessoParte VALUES (7,10) INSERT INTO ProcessoParte VALUES (7,11) INSERT INTO ProcessoParte VALUES (7,11)

- Inserindo informações - Tabela : ACOMPANHAMENTO INSERT INTO Acompanhamento VALUES (1,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (2,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (3,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (4,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (5,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (6,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (7,'09/26/2001','10/10/2001','Entrada no FORUM') INSERT INTO Acompanhamento VALUES (1,'10/10/2001','11/10/2001',’1o acompanhamento') INSERT INTO Acompanhamento VALUES (2,'10/10/2001','11/09/2001',’1o Acompanhamento') INSERT INTO Acompanhamento VALUES (3,'10/10/2001','10/20/2001',’1o Acompanhamento') INSERT INTO Acompanhamento VALUES (3,'10/20/2001','11/10/2001',’2o Acompanhamento') INSERT INTO Acompanhamento VALUES (3,'11/10/2001','12/10/2001',’3o Acompanhamento') INSERT INTO Acompanhamento VALUES (4,'10/10/2001','10/15/2001',’1o Acompanhamento') INSERT INTO Acompanhamento VALUES (4,'10/15/2001','',’2o Acompanhamento') INSERT INTO Acompanhamento VALUES (4,'10/20/2001','10/30/2001',’3o Acompanhamento')



142

- Extraindo Informações

PARTES COM MAIS DE UM PROCESSO select pp.parte, pa.nome, count(pp.processo) #processos from processoparte pp, parte pa where pp.parte = pa.parte group by pp.parte, pa.nome having count(pp.processo) > 1

PARTES SEM PROCESSOS select pa.parte, pa.nome from parte pa where not exists ( select * from processoparte pp where pp.parte = pa.parte )

PROCESSOS E SUAS PARTES - Usando o INNER JOIN select pp.processo, pp.parte, pa.nome, pr.comarca from processoparte pp inner join processo pr on pp.processo = pr.processo inner join parte pa on pp.parte = pa.parte -- Usando a cláusula WHERE select pp.processo, pp.parte, pa.nome, pr.comarca from processoparte pp, parte pa, processo pr where pr.processo = pp.processo and pp.parte = pa.parte

PROCESSO COM MAIOR VALOR select TOP 1 uf, valor from processo order by valor desc

QUANTIDADE DE PROCESSOS POR UF (ORDENADO PELA QUANTIDADE) select uf, count(*) qtd

from processo group by uf order by count(*) desc

ELIMINADO UMA INFORMAÇÃO delete from parte where parte = 1 (deverá ocorrer um erro. A parte tem processo) delete from parte where parte = 3 (não ocorrerá erro. Não existem processos para a parte)



143

Trabalho – Solicitações de Serviços Modelo Conceitual

Modelo Lógico - SISTEMA (sis_cod, sis_des) - STATUS (sta_cod, sta_des) - TIPOS DE SERVICO (ts_cod, ts_des) - USUARIO (usu_mat, usu_nom) - SOLICITACAO (sol_num, sol_dtemi, sol_dtrec, sol_dtini, sol_dtfim, sol_hremi,

sol_hrrec, sol_hrini, sol_hrfim, sol_tempo, sis_cod, sta_cod, sol_mat, rec_mat, exe_mat, ts_cod)

ReceptorSolicitante

Usuários

Executor

Tipos deServiço

StatusSistema

Possui Possui

usu_mat

usu_nom

sta_cod

sta_des

sis_cod

sis_des

sol_num sol_dtemi

sol_hremisol_tempo(1,1)

(1,1)

(1,n)(1,n)

(1,n)

(1,n)

(T,S)

ts_cod ts_des

Solicitação

Emite Recebe Executa

(1,n) (1,n)

(1,1) (1,1)(1,1)

Possui

sol_dtrecsol_dtinisol_dtfim

sol_hrrecsol_hrinisol_hrfim



144

- Criação do DATABASE CREATE DATABASE Solicitacao ON PRIMARY (NAME=Solicitacao_data, FILENAME='c:\mssql7\data\solicitacao.mdf', SIZE=10MB, MAXSIZE=15MB, FILEGROUTH=25%) LOG ON (NAME=Teste_log, FILENAME='c:\mssql7\data\solicitacao.ldf', SIZE=4MB, MAXSIZE=6MB, FILEGROUTH=2MB) - Criação das tabelas (juntamente com os CONSTRAINTS) CREATE TABLE Sistema ( sis_cod int NOT NULL

CONSTRAINT PK_Sistema PRIMARY KEY NONCLUSTERED, sis_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE Status ( sta_cod int NOT NULL

CONSTRAINT PK_Status PRIMARY KEY NONCLUSTERED, sta_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE TipoServico ( ts_cod int NOT NULL

CONSTRAINT PK_TipoServico PRIMARY KEY NONCLUSTERED, ts_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE Usuario ( usu_mat int NOT NULL

CONSTRAINT PK_Usuario PRIMARY KEY NONCLUSTERED, usu_nom nvarchar (40) NULL ) ON PRIMARY CREATE TABLE Solicitacao ( sol_num int NOT NULL CONSTRAINT PK_Solicitacao PRIMARY KEY NONCLUSTERED, sol_dtemi smalldatetime NULL , sol_tempo int NULL , sis_cod int NOT NULL

CONSTRAINT FK_Solicitacao_Sistema FOREIGN KEY REFERENCES Sistema (sis_cod), sta_cod int NOT NULL CONSTRAINT FK_Solicitacao_Status FOREIGN KEY REFERENCES Status (sta_cod), sol_mat int NOT NULL

CONSTRAINT FK_Solicitacao_UsuarioS FOREIGN KEY REFERENCES Usuario (usu_mat) rec_mat int NOT NULL

CONSTRAINT FK_Solicitacao_UsuarioR FOREIGN KEY REFERENCES Usuario (usu_mat), exe_mat int NOT NULL CONSTRAINT FK_Solicitacao_UsuarioE FOREIGN KEY REFERENCES Usuario (usu_mat), ts_cod int NOT NULL CONSTRAINT FK_Solicitacao_TipoServico FOREIGN KEY (ts_cod) REFERENCES TipoServico (ts_cod), ) ON PRIMARY

- Criação das tabelas (separadas dos CONSTRAINTS) CREATE TABLE Sistema ( sis_cod int NOT NULL , sis_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE Solicitacao ( sol_num int NOT NULL , sol_dtemi smalldatetime NULL , sol_tempo int NULL , sis_cod int NOT NULL , sta_cod int NOT NULL , sol_mat int NOT NULL , rec_mat int NOT NULL , exe_mat int NOT NULL , ts_cod int NOT NULL ) ON PRIMARY



145

CREATE TABLE Status ( sta_cod int NOT NULL , sta_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE TipoServico ( ts_cod int NOT NULL , ts_des nvarchar (40) NULL ) ON PRIMARY CREATE TABLE Usuario ( usu_mat int NOT NULL , usu_nom nvarchar (40) NULL ) ON PRIMARY

- Criação dos CONSTRAINTS ALTER TABLE Sistema WITH NOCHECK ADD CONSTRAINT PK_Sistema PRIMARY KEY NONCLUSTERED (sis_cod) ON PRIMARY ALTER TABLE Solicitacao WITH NOCHECK ADD CONSTRAINT PK_Solicitacao PRIMARY KEY NONCLUSTERED (sol_num) ON PRIMARY ALTER TABLE Status WITH NOCHECK ADD CONSTRAINT PK_Status PRIMARY KEY NONCLUSTERED (sta_cod) ON PRIMARY ALTER TABLE TipoServico WITH NOCHECK ADD CONSTRAINT PK_TipoServico PRIMARY KEY NONCLUSTERED (ts_cod) ON PRIMARY ALTER TABLE Usuario WITH NOCHECK ADD CONSTRAINT PK_Usuario PRIMARY KEY NONCLUSTERED (usu_mat) ON PRIMARY ALTER TABLE Solicitacao ADD CONSTRAINT FK_Solicitacao_Sistema FOREIGN KEY (sis_cod) REFERENCES Sistema (sis_cod ), CONSTRAINT FK_Solicitacao_Status FOREIGN KEY (sta_cod) REFERENCES Status (sta_cod), CONSTRAINT FK_Solicitacao_TipoServico FOREIGN KEY (ts_cod) REFERENCES TipoServico (ts_cod), CONSTRAINT FK_Solicitacao_UsuarioE FOREIGN KEY (exe_mat) REFERENCES Usuario (usu_mat), CONSTRAINT FK_Solicitacao_UsuarioR FOREIGN KEY (rec_mat) REFERENCES Usuario ( usu_mat), CONSTRAINT FK_Solicitacao_UsuarioS FOREIGN KEY (sol_mat) REFERENCES Usuario (usu_mat)

- Eliminando as TABELAS (Primeiro elimina-se os CONSTRAINTS)

ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_Sistema ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_Status ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_TipoServico ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_UsuarioE ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_UsuarioR ALTER TABLE Solicitacao DROP CONSTRAINT FK_Solicitacao_UsuarioS if exists (select * from sysobjects where id = object_id(N'Sistema') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Sistema if exists (select * from sysobjects where id = object_id(N'Solicitacao') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Solicitacao if exists (select * from sysobjects where id = object_id(N'Status') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Status if exists (select * from sysobjects where id = object_id(N'TipoServico') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table TipoServico if exists (select * from sysobjects where id = object_id(N'Usuario') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table Usuario



146

- Inserindo informações - Tabela : SISTEMA INSERT INTO Sistema VALUES (1,'Faturamento') INSERT INTO Sistema VALUES (2,'Estoque') INSERT INTO Sistema VALUES (3,'Contabilidade') INSERT INTO Sistema VALUES (4,'Folha de Pag') INSERT INTO Sistema VALUES (5,'Lib. Senha') INSERT INTO Sistema VALUES (6,'Tb Financeiras') INSERT INTO Sistema VALUES (7,'Ativo') INSERT INTO Sistema VALUES (8,'Cobranca') INSERT INTO Sistema VALUES (9,'Emprestimo') INSERT INTO Sistema VALUES (10,'Protocolo') INSERT INTO Sistema VALUES (11,'Renda Fixa') INSERT INTO Sistema VALUES (12,'Compas')

- Inserindo informações - Tabela : STATUS INSERT INTO Status VALUES (1,'Nao recebida') INSERT INTO Status VALUES (2,'Recebida') INSERT INTO Status VALUES (3,'Alocada') INSERT INTO Status VALUES (4,'Encerrada') INSERT INTO Status VALUES (5,'Pendente') INSERT INTO Status VALUES (6,'Cancelada') INSERT INTO Status VALUES (7,'Fechada')

- Inserindo informações - Tabela : TIPOS DE SERVICO INSERT INTO TipoServico VALUES (1,'Desenv. Sistema') INSERT INTO TipoServico VALUES (2,'Alteracao Sistema') INSERT INTO TipoServico VALUES (3,'Desenv. Prog.') INSERT INTO TipoServico VALUES (4,'Alteracao Prog.') INSERT INTO TipoServico VALUES (5,'Manutencao Dados') INSERT INTO TipoServico VALUES (6,'Chamado Tecnico') INSERT INTO TipoServico VALUES (7,'Install') INSERT INTO TipoServico VALUES (8,'Executar Prog.')

- Inserindo informações - Tabela : USUARIO INSERT INTO Usuario VALUES (1,'Santos') INSERT INTO Usuario VALUES (2,'Jose') INSERT INTO Usuario VALUES (3,'Jose') INSERT INTO Usuario VALUES (4,'Alan') INSERT INTO Usuario VALUES (5,'Tatiana') INSERT INTO Usuario VALUES (6,'Sidnei') INSERT INTO Usuario VALUES (7,'Misael') INSERT INTO Usuario VALUES (8,'Leonardo') INSERT INTO Usuario VALUES (9,'Carlos') INSERT INTO Usuario VALUES (10,'Claudio') INSERT INTO Usuario VALUES (11,'Katiucia') INSERT INTO Usuario VALUES (12,'Wallace') INSERT INTO Usuario VALUES (13,'Roberto') INSERT INTO Usuario VALUES (14,'Milton') INSERT INTO Usuario VALUES (15,'Michel')

- Inserindo informações - Tabela : SOLICITACAO INSERT INTO Solicitacao VALUES (1,'09/26/2001',10,1,1,1,2,3,1) INSERT INTO Solicitacao VALUES (2,'09/25/2001',11,1,2,2,2,4,2) INSERT INTO Solicitacao VALUES (3,'09/24/2001',15,2,3,3,2,5,3) INSERT INTO Solicitacao VALUES (4,'09/23/2001',16,3,1,4,2,6,4) INSERT INTO Solicitacao VALUES (5,'09/22/2001',17,4,2,1,2,7,1) INSERT INTO Solicitacao VALUES (6,'09/21/2001',12,5,3,2,2,8,2) INSERT INTO Solicitacao VALUES (7,'09/20/2001',13,7,1,3,2,9,2) INSERT INTO Solicitacao VALUES (8,'09/19/2001',11,1,2,4,2,10,3) INSERT INTO Solicitacao VALUES (9,'09/18/2001',19,1,3,1,2,11,3) INSERT INTO Solicitacao VALUES (10,'09/17/2001',20,3,1,2,2,12,3) INSERT INTO Solicitacao VALUES (11,'09/16/2001',12,1,2,3,2,1,4) INSERT INTO Solicitacao VALUES (12,'09/15/2001',13,2,3,4,2,5,2) INSERT INTO Solicitacao VALUES (13,'09/14/2001',15,4,4,1,2,4,1) INSERT INTO Solicitacao VALUES (14,'09/13/2001',10,5,1,2,2,6,1) INSERT INTO Solicitacao VALUES (15,'09/12/2001',11,4,2,3,2,7,1) INSERT INTO Solicitacao VALUES (16,'09/11/2001',13,1,3,4,2,4,1) INSERT INTO Solicitacao VALUES (17,'09/10/2001',14,1,4,1,2,7,2) INSERT INTO Solicitacao VALUES (18,'09/09/2001',22,1,5,3,2,4,2)



147

- Extraindo informações

NOME DO SOLICITANTE E AS SOLICITAÇÕES EM ABERTO, POR SOLICITANTE select usu_nom, sol_num from usuario u, solicitacao s where u.usu_mat = s.sol_mat and sta_cod = 3 order by usu_nom NOME DO SISTEMA E A QUANTIDADE DE SOLICITAÇÕES EM ABERTO, POR SISTEMA select si.sis_des, count(so.sol_num) qtd from sistema si, solicitacao so where si.sis_cod = so.sis_cod and so.sta_cod = 3 group by si.sis_des

NOME DO EXECUTOR E QUANTIDADE DE SOLICITAÇÕES EM ABERTO, POR EXECUTOR select u.usu_nom, count(s.sol_num) qtd from usuario u, solicitacao s where u.usu_mat = s.exe_mat and sta_cod = 3 group by u.usu_nom

NOME DO EXECUTOR, A QUANTIDADE DE SOLICITAÇÕES ENCERRADAS E O TEMPO TOTAL CONSUMIDO, POR EXECUTOR select u.usu_nom, count(*), sum(s.sol_tempo) tempo from usuario u, solicitacao s where u.usu_mat = s.exe_mat and s.sta_cod = 5 group by u.usu_nom

EXPURGAR SOLICITAÇÕES CANCELADAS, FECHADAS OU PENDENTES DO ANO DE 2001 delete from solicitacao where year(sol_dtemi) = 2001 and sta_cod in (5,6,7)



148

Trabalho – Sistema de Estoque Modelo Conceitual

Modelo Lógico - CATEGORIA (cod_c, des_c) - SUBCATEGORIA ( cod_c, des_s ) - UNIDADE DE ARMAZENAMENTO ( cod_u, des_u ) - MATERIAL ( cod_c, cod_s, cod_m, des_m, min, pc, atu, vu, cod_u ) - DEPTO ( cod_d, des_d ) - RM ( cod_d, num_rm, emi_rm, atend_rm ) - ITENS ( cod_d, num_rm, cod_m, qtd_sol ) - TIPO DE MOVIMENTO ( cod_t, des_t ) - MOVIMENTO ( cod_d, num_rm, cod_m, qtd_ate, data_ate, cod_t ) - JUSTIFICATIVA ( cod_d, num_rm, cod_m, des )

CATEGORIA

ITENS

des

(1,n)

Contém

SUBCATEGORIAS

Contém

DEPTO

Faz

RM

Movimenta

MOVIMENTORequer

JUSTIFICATIVA

Possui

TIPO DEMOVIMENTO

cod_t

des_t

qtd_movdata_mov

cod_d

des_d

num_rm

emi_rmatend_rm

qtd_sol

(1,1)

(1,n)(1,n)

cod_c

des_c

cod_s

des_s

cod_m des_m

min pc atu vu

(1,n)

(1,1)

(1,n)

(1,n)

(0,1)

(1,1)

(0,1)

(1,1)

(1,1)

(1,n)

Possui

UNIDADE DEARMAZENAMENTO

(1,1)

(1,n)

MATERIAL

cod_u des_u

banco de dados

Documents