apostila bancodados

CURSO TÉCNICO

ESCOLA ESTADUAL PROFESSOR JOSÉ MONTEIROPrefeitura Municipal de Campo Belo, Secretaria Municipal de Educação e

Secretaria Estadual de Educação de Minas Gerais

INFORMÁTICABanco de Dados I

Juliano Porto [email protected]

mailto:[email protected]

Curso Técnico em Informática E. E. Professor José Monteiro

INTRODUÇÃO

Ao longo dos tempos a informática deixou as áreas exclusivamente técnicas e científicas

para se tornar uma ferramenta de uso geral em qualquer setor da atividade humana. Se

há alguns anos atrás o grande problema residia na limitação à quantidade e capacidade

de processamento de informação que era possível tratar num computador, hoje em dia a

tecnologia permite ultrapassar isso, criando, no entanto, outro problema que é a

qualidade dessa informação.

As novas tecnologias permitem também explorar melhor as capacidades do computador.

A informação deixou de ser apenas texto (símbolos ou caracteres), e passou a incluir

imagens e sons. Abrindo novos campos para a exploração dos sistemas de informação.

Sendo as organizações os locais onde mais intensivamente se utiliza a informática, é

também nelas que as necessidades e quantidades de informação são maiores. O aumento

de potência dos sistemas informáticos, assim como a sua aplicação a todas as áreas da

organização, atualmente proporciona uma grande quantidade de informação quando

comparadas com alguns anos atrás.

A necessidade das organizações em possuir um sistema de gestão mais eficaz torna-as

cada vez mais dependentes da informação existente e dos métodos para tratá-la. Hoje a

informação tem de ser compreensível, completa, fácil e rápida de se obter.

É num contexto de necessidade de informação cada vez maior, que se insere o

aparecimento dos Bancos de Dados, em que desempenham um papel critico nas áreas da

ciência onde a informática é aplicada, e também no mundo dos negócios,

principalmente nos últimos anos, com a grande valorização das informações. Grande

parte das mudanças foi impulsionada pela necessidade das aplicações que vêm se

tornando cada vez mais complexas.

CONCEITOS BÁSICOS

Alguns dos principais conceitos da área de banco de dados serão apresentados a seguir

com o intuito de diferenciar os termos mais utilizados, que normalmente podem ser

confundidos.

Bancos de Dados – são conjuntos de dados relacionados e acessíveis. Dados são fatos

conhecidos, que podem ser registrados e possuem significado.

Disciplina: Banco de Dados 1


Sistemas Gerenciadores de Banco de Dados (SGBD) – são sistemas que gerenciam

BD, ou são linguagens utilizadas para manter os BDs.

Mini-Mundo ou Universo de Discurso – é uma parte do mundo real sobre o

qual o BD será criado e a aplicação será desenvolvida. A figura 1.1 expressa

a idéia de que o Mini-Mundo é um ambiente.

Uma definição mais completa para o termo Banco de Dados é um conjunto de dados

armazenados, cujo conteúdo informativo representa, a qualquer instante, o estado de

uma determinada aplicação. Um BD é um modelo de uma determinada parte da

realidade, geralmente denominada de Universo de Discurso.

Um primeiro exemplo apenas para fixar estes primeiros conceitos, poderia considerar

um Universo de Discurso de uma livraria. Esta livraria possui diversas características

que a define, tais como, o seu nome, a sua localização, os proprietários, os funcionários,

os livros e outros produtos que estão sendo comercializados, etc.

Algumas características deverão ser descritas num banco de dados, porém nem todas

devem ser de interesse, como, por exemplo, a cor da pintura da livraria, pois este é um

dado que não possui importância nos negócios realizados na livraria. Um primeiro

passo, então, na criação de um BD da livraria, seria a identificação das características de

interesse para seus negócios, pois estes geralmente são os utilizados num programa de

aplicação.

Uma vez definidos quais são os dados que constituirão o BD, definem-se também as

suas estruturas, tais como, que tipo de dado este será, se um texto formado por palavras,

ou um valor numérico, ou um valor de data, etc.

Resumindo, os passos para a criação de um Banco de Dados:

Análise a Estrutura da Empresa;

Escolha do SGBD;


Bancos de Dados

Mini-Mundo

Modelagem


Coleta de Informações (Entrevistas);

Modelo Conceitual (MER);

Modelo Lógico (Relacional);

Implementação.

MODELOS

O conceito de modelo de dados é de fundamental importância na estrutura de um banco

de dados, pois fornece as ferramentas conceituais para a descrição de dados,

relacionamentos de dados, semântica de dados e restrições de consistência. Sendo o

objetivo principal de um SGBD modelar precisamente o mundo real, a forma como o

banco de dados está estruturado determina a qualidade do modelo.

Um modelo de dados é uma estrutura básica para a execução do modelo. Uma analogia

é a caixa de ferramentas de um carpinteiro. Uma caixa de ferramenta pode conter

martelo e pregos, enquanto outra caixa pode ter chave de fenda e parafusos. O

carpinteiro pode construir diferentes peças com qualquer uma das caixas. Entretanto,

construir uma casa apenas com parafusos pode ser bastante difícil, enquanto construir

uma bela escrivaninha usando apenas pregos e martelo seria inviável.

A adequabilidade do modelo de dados depende, portando, da realidade que se está

tentando modelar. Não existe nenhum modelo ideal, da mesma forma que não existe

nenhuma caixa de ferramentas ideal de carpinteiros.

Em relação aos dados, o planejamento estratégico de informações está preocupado

basicamente com a obtenção do modelo de dados corporativo que dá suporte à empresa

como um todo, incorporando todas as informações necessárias para o andamento dos

negócios, considerando-se tanto o ambiente interno - onde os dados são mais estáveis ou

facilmente controlados e planejados, como o ambiente externo - onde as restrições são

mais sensíveis e os dados se apresentam instáveis e mais difíceis de serem obtidos.

Diversos modelos de dados têm sido propostos, os quais dividem-se em três grupos

principais: Modelo Conceitual, Modelos Lógicos baseados em Registros e Modelos

Físicos de Dados.

MODELO CONCEITUAL



Estes modelos são usados na descrição de dados nos níveis: conceitual e de visões.

Estes modelos fornecem capacidades de estruturação flexíveis e admitem restrições de

dados para serem explicitamente especificados. Alguns dos mais conhecidos são:

modelo entidade-relacionamento;

modelo orientado a objeto;

modelo binário;

modelo semântico de dados;

modelo infológico;

modelo funcional de dados.

Como representantes da classe de modelos conceituais, examinar-se-á o modelo

entidade-relacionamento (ênfase) e o modelo orientado a objeto.

MODELO ENTIDADE-RELACIONAMENTO (MER)

Este modelo é baseado numa percepção de um mundo real que consiste em uma coleção

de objetos básicos chamados entidades, e em relacionamentos entre esses objetos. Uma

entidade é um objeto que se distingue de outro por um conjunto específico de atributos.

Por exemplo, os atributos matrícula e sit_tesouraria descrevem uma situação financeira

particular em uma universidade. Um relacionamento é uma associação entre várias

entidades. Por exemplo, um relacionamento AlunoNotas associa um aluno a cada

disciplina/nota que ele possui. O conjunto de todas a entidades de um mesmo tipo e o

conjunto de relacionamentos do mesmo tipo são denominados conjuntos de entidades e

conjuntos de relacionamentos, respectivamente.

A estrutura lógica geral de um banco de dados pode ser expressa graficamente por um

diagrama E-R (DER), que consiste nos seguintes componentes:

Retângulos: representam conjuntos de entidades;

Elipses: representam atributos;

Losangos: representam relacionamentos entre conjuntos de entidades;

Linhas: ligam atributos a conjuntos de entidades e conjuntos de entidade a

relacionamentos.

Considere parte de um sistema de banco de dados de uma instituição de ensino,

consistindo em alunos e notas que eles possuem. O diagrama E-R:



MODELO ORIENTADO A OBJETO

Este modelo está baseado em um conjunto de objetos, onde um objeto contém valores

armazenados em variáveis de instância dentro do objeto. Então, objetos contêm objetos

para um nível arbitrário de encaixamento. Um objeto também possui trechos de código

que operam sobre o objeto. Estes trechos de código são chamados métodos.

Os objetos que contêm os mesmos tipos de valores e os mesmos métodos são agrupados

em classes. Uma classe pode ser vista como uma definição de tipo para objetos. Esta

combinação de dados e código em uma definição de tipo é similar ao conceito de tipos

abstratos de dados em linguagem de programação.

O único modo pelo qual um objeto pode fazer o acesso ao dado de outro objeto é

invocando o método desse objeto. Isto é chamado de enviar uma mensagem ao objeto.

A interface de chamada dos métodos de um objeto define sua parte externa visível. A

parte interna do objeto - as variáveis de instância e o código do método - não são

visíveis externamente.

Para ilustrar o conceito, considere o objeto representando uma situação financeira. Tal

objeto contém variáveis de instância matrícula e sit_financeira. Este objeto contém um

método taxa-juros, que adiciona juros a sit_financeira. Conforme for modificada esta

taxa de juro, sob o modelo orientado a objetos, uma única mudança é feita - dentro do

método taxa-juros. Na maioria dos modelos de dados, esta mudança envolveria

alterações no código de um ou mais programas aplicativos.



MODELOS LÓGICOS BASEADOS EM REGISTRO

Neste modelo o banco de dados é estruturado em registros de formato fixo de diversos

tipos. Cada tipo de registro define um número fixo de campos, ou atributos, sendo cada

campo usualmente de um tamanho fixo. O uso de registros com tamanho fixo simplifica

o nível de implementação física dos bancos de dados.

Os três modelos de dados mais aceitos são o relacional, o de rede e o hierárquico. Por

ser o modelo relacional o mais usado nos últimos anos, receberá um maior enfoque.

REDES

No modelo de redes os dados são representados por coleções de registros (como em

linguagens como Pascal), e os relacionamentos entre os dados são representados por

ligações, que podem vistas como ponteiros. Os registros são organizados como grafos

arbitrários.

HIERÁRQUICO

O modelo hierárquico é similar ao modelo de redes, pois os dados e relacionamentos

são representados por registros e ligações, respectivamente. Ele difere do modelo de

redes no sentido que os registros são organizados como coleções de árvores em vez de

grafos arbitrários.

RELACIONAL

O modelo relacional representa dados e relacionamentos entre dados por um conjunto

de tabelas, cada uma tendo um número de colunas com nomes únicos. Por não utilizar

ponteiros este modelo permite a definição de um fundamento matemático formal.

O Modelo Relacional é claramente baseado no conceito de matrizes, onde as chamadas

linhas (das matrizes) seriam os registros e as colunas (das matrizes) seriam os campos.

Os nomes das tabelas e dos campos são de fundamental importância para nossa

compreensão entre o que estamos armazenando, onde estamos armazenando e qual a

relação existente entre os dados armazenados.


Cod_cid e Cod_est são chaves primárias respectivamente das tabelas Cidade e Estado, enquanto Cod_est é chave estrangeira na tabela de cidades. É precisamente por este campo (atributo, ou coluna), que será estabelecida a relação entre as tabelas Cidade-->Estado.


Cada linha de nossa relação será chamada de TUPLA e cada coluna de nossa relação

será chamada de ATRIBUTO. O conjunto de valores passíveis de serem assumidos por

um atributo será intitulado de DOMÍNIO.

Instância da relação consiste no conjunto de valores que cada atributo assume em um

determinado instante. Portanto, os dados armazenados no Banco de Dados, são

formados pelas instâncias das relações.

As relações não podem ser duplicadas (não podem existir dois estados do Pará, no

conjunto de estados brasileiros, por exemplo), a ordem de entrada de dados no Banco de

Dados não deverá ter qualquer importância para as relações, no que concerne ao seu

tratamento.

Chamaremos de Chave Primária ao Atributo que definir um registro, dentre uma

coleção de registros. Chamaremos de Chave Composta, aquela chave que contém mais

de um atributo (Por exemplo, um cadastro ordenado alfabeticamente por Estado, Cidade

e Nome do Cliente, necessitaria de uma chave composta que contivesse estes três

atributos). Chamaremos de Chave Estrangeira, aquela chave que permitir a ligação

lógica entre uma tabela (onde ela se encontra) com outra na qual ele é chave primária.

Exemplo:

Cidade Estado

*Cod_cid *Cod_est

Nome_cid Nome_est

Cod_est (E)

MODELOS FÍSICOS DE DADOS

Os modelos físicos de dados são utilizados para descrever dados no nível mais baixo.

Estes modelos captam aspectos da implementação de sistemas de banco de dados não

abordados neste estudo.

LINGUAGENS DO SGBD

Depois de concluído o projeto do BD, um SGBD deve ser escolhido para que o sistema

seja implementado. Nos SGBDs existem três tipos de linguagens, que serão explicadas a

seguir.



DCL (Data Control Language) – é a linguagem de controle de dados, usada pelo DBA

para controlar o acesso aos dados pelos usuários. Possui comandos de atribuição e

remoção de privilégios.

DDL (Data Definition Language) – é a linguagem de definição de dados que descreve

a estrutura do BD, usada pelo DBA e pelos projetistas. Possui comandos de criação,

alteração e exclusão de tabelas e visões. Gera um catálogo a partir da descrição dos

dados.

DML (Data Manipulation Language) – é a linguagem de manipulação de dados, que

permite especificar operações de recuperação e alteração dos dados do BD. A DML

pode ser de alto nível, podendo ser utilizada sozinha para especificar operações

complexas de dados; ou de baixo nível, que é embutida em uma linguagem de

programação de uso geral.

A SQL (Structed Query Language) é chamada de linguagem de consulta, por causa do

termo em inglês “query”, que poderia ser traduzida para o português como “consulta”,

mas que na verdade significa não só recuperar ou consultar dados, mas também

atualizá-los. A SQL é formada pelas linguagens: DDL, DML e DCL.

MODELO ENTIDADE-RELACIONAMENTO (MER)

Em 1976 o modelo entidade-relacionamento foi definido por Peter Cher que teve como

base à teoria relacional criada por Edgard F. Codd (1970).

O principal objetivo era levar aos “projetistas ou analistas” a possibilidade de ter uma

única visão de uma realidade; sem redundância e bem resumida.

Para aplicação de banco de dados o modelo entidade-relacionamento é mais utilizado

para representação e entendimento de dados que compõem a essência de um sistema de

informação, porém, é importante reconhecer em um SI (Sistema de Informação) os

objetos que o compõem, que são: Entidades e Relacionamento.

“O modelo entidade-relacionamento é baseado numa percepção de um

mundo real que consiste em uma coleção de objetos básicos chamados

entidades, e em relacionamentos entre esses objetos. Uma entidade é um



objeto que é distinguível de outro objeto por um conjunto específico de

atributos. Um relacionamento é uma associação entre várias entidades.

Em acréscimo a entidades e relacionamentos, o modelo entidade-

relacionamento define certas restrições com as quais os conteúdos de

bancos de dados precisam estar de acordo. Uma restrição importante é o

mapeamento de cardinalidade que expressa o número de entidades ao

qual outra entidade pode estar associada. ”

Consiste em mapear o mundo real do sistema em um modelo gráfico que irá representar

o modelo e o relacionamento existente entre os dados.

DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)

O modelo de entidade-relacionamento consiste nas seguintes etapas:

Identificar tipos de entidades.

Identificar tipos de relacionamentos.

Desenhar um diagrama E-R com tipos de entidade e relacionamentos.

Identificar tipos de valor e atributos.

Traduzir o diagrama E-R em um diagrama de estrutura de dados.

Uma das definições mais importantes para o projeto de sistemas de informação é a

definição dos objetos de informação de interesse da empresa ou organização para a qual

o sistema será construído, pois para satisfazer os objetivos do sistema precisa-se

armazenar dados a respeito deles.

Os objetos de informação são geralmente entidades ou eventos, tais como: clientes,

fornecedores, produtos, vendas, compras e cobranças. As entidades são “coisas” que

existem durante um determinado tempo. Os eventos são “coisas” que ocorrem num

determinado momento específico. Uma entidade poderá ter um ou mais eventos a ela

associados (uma ou mais vendas, uma ou mais cobranças etc.). Por outro lado, um

evento pode representar a associação de uma ou mais entidades (uma venda de diversos

produtos para um cliente, ou uma compra de diversos produtos de um fornecedor).

Normalmente, cada entidade que compõe a base de dados de um sistema aplicativo

poderá estar relacionada com outras. Assim, por exemplo, um cliente poderá estar

relacionado com várias vendas, uma venda com vários produtos, um vendedor com

várias vendas, e assim por diante.


Clientes

CPF

ClienteCliente


Portanto, tendo em vista que as entidades de uma base de dados estão relacionadas e

que, através desse relacionamento, são geradas informações, como, por exemplo, todos

os produtos vendidos a um cliente, é importante definir todos os relacionamentos entre

as entidades e relacionamentos (diagrama E-R) é fundamental para o projeto de

qualquer base de dados.

CONCEITOS

a) Entidade - Identifica o objeto de interesse do sistema e tem "vida" própria, ou seja, a

representação abstrata de um objeto do mundo real sobre o qual desejamos guardar

informações.

Ex: Clientes, Fornecedores, Alunos, Funcionários, Departamentos, etc.

Não são entidades:

- Entidade com apenas 1 elemento;

- Operações do sistema (inserção, deleção);

- Saídas do sistema (relatórios, impressão);

- Pessoas que realizam trabalhos (usuários do sistema);

- Cargos de direção.

Representação gráfica para Entidade representada por um retângulo.

b) Instância de Entidade - São os elementos da entidade, os valores. Ex: Cliente 10,

Funcionário João, etc.

c) Atributo - Informações que desejamos guardar sobre a instância de entidade. Ex:

Nome do aluno, Número da turma, Endereço do fornecedor, Sexo do funcionário, etc.

Representação gráfica para Atributo representado por um círculo ou elipse.

d) Domínio do Atributo - Universo de valores que um atributo pode armazenar.

Ex:- Conjunto de valores do atributo Sexo do funcionário: M ou F;

- Conjunto de valores do atributo Nome do aluno: 40 caracteres alfanuméricos.

- Conjunto de valores do atributo salário: inteiro maior que 500.


CPF


Um Atributo pode ser:

Simples ou Composto

Simple: Não pode ser dividido em partes. Ex: valor_filme,

Categoria_filme.

Composto: Podem ser divididos em partes. Ex: Nome pode ser dividido

em prenome, nome, nome intermediário e sobrenome. Endereço (Bairro,

rua, nº da residência, complemento).

Nulos: É usado quando uma entidade não possui valor para determinado

atributo. Ex: tel_cli: se o cliente não possui telefone, o valor é nulo (null).

Monovalorado e Multivalorado

Monovalorado: Possui um único valor. Ex: nome do cliente.

Multivalorado: Quando um atributo possui um conjunto de valores para

uma única entidade. Ex: um empregado pode ter nenhum ou vários

dependentes, um filme pode ter vários gêneros.

Em geral a partir de um atributo multivalorado cria-se uma nova entidade: Ex: telefone,

gênero, dependente.

Na pratica, atributos não são representados graficamente, para não sobrecarregar os

diagramas, já que existem entidades com muitos atributos.

e) Relacionamento - Representa a associação entre os elementos do conjunto de uma

entidade com outra entidade.

Ex: O João está matriculado na disciplina de REDES, onde:

- João - (instância) - Elemento do conjunto de valores do atributo Nome do

aluno da entidade Aluno;

- REDES – (instância) - Elemento do conjunto de valores do atributo Nome

da disciplina da entidade Disciplina;

- matriculado - Ligação existente entre um aluno e uma disciplina.

Representação gráfica para Relacionamento representado por um losango.


Aluno Disciplinamatriculado

Casament

o

Esposa

1 n


f) Auto Relacionamento – Relacionamentos entre ocorrências de uma mesma entidade.

No auto relacionamento se faz necessário ter o papel da entidade. Para o exemplo os

papéis são: marido e esposa.

Ex:

Marido

CARDINALIDADE DE RELACIONAMENTO

Para fins de projeto de banco de dados, uma propriedade importante de um

relacionamento é a de quantas ocorrências de uma entidade podem estar associadas a

uma determinada ocorrência através de um relacionamento. Esta propriedade é chamada

de cardinalidade de uma entidade em um relacionamento. Há duas cardinalidades a

considerar: a cardinalidade máxima e a cardinalidade mínima.

CARDINALIDADE MÁXIMA

A cardinalidade máxima é expressa por 1 e n (muitos). Exemplo:

A cardinalidade máxima 1 – significa que uma ocorrência de Empregado pode estar

associada a no máximo 1(uma) ocorrência de Departamento, ou seja, um empregado

pode estar lotado em no máximo um departamento.


PESSOA

Departamento Empregadolotação


A Cardinalidade máxima n – significa que uma ocorrência de Departamento pode

estar associada a no máximo várias(>1) ocorrências de empregado, ou seja, em um

departamento pode ter nele lotado muitos empregados.

Observe que a cardinalidade vai anotada “do outro lado” do relacionamento a

qual se refere.

CARDINALIDADE MÍNIMA

Além da cardinalidade máxima, uma outra informação que pode ser representada por

um modelo ER é o número mínimo de ocorrências de entidade que são associadas a

uma ocorrência de uma entidade através de um relacionamento. A cardinalidade mínima

é representa por 0(zero) e 1.

A cardinalidade mínima 1 - recebe o nome de “associação obrigatória”, já que ela

indica que o relacionamento deve obrigatoriamente associar uma ocorrência de entidade

a cada ocorrência da entidade em questão.

A cardinalidade 0 - recebe o nome de “associação opcional”.

A cardinalidade mínima é anotada no diagrama junto à cardinalidade máxima. Exemplo:

Um aluno está inscrito em exatamente um curso e um curso pode ter nele inscritos

muitos alunos (inclusive nenhum).

IDENTIFICANDO ENTIDADES

Cada entidade deve possuir um identificador ou chave. Um identificador é um conjunto

de um ou mais atributos cujos valores servem para distinguir uma ocorrência da

entidade das demais ocorrências da mesma entidade. Na verdade, uma chave ou

identificador de registro tem a finalidade de organizá-los e de localizá-los com rapidez

dentro do sistema.


ALUNO CURSOinscrição

(0,N) (1,1)


Todo arquivo deverá ter pelo menos um campo definido como chave primária ou

identificadora.

Assim, uma chave identificadora deverá ser exclusiva, ou seja, única por registro do

arquivo e, uma vez designada, nunca deverá ser alterada. Além disso, um dado que faça

parte dessa chave nunca deverá possuir um valor ausente ou nulo, pois perderá sua

utilidade, tanto como identificador de registros como apontador de relacionamento entre

arquivos de dados.

Se uma chave identificadora não existir “naturalmente” entre os elementos de dados que

descrevem as entidades e os eventos de interesse do sistema, uma chave identificadora

exclusiva deverá ser criada, como código do produto, número do funcionário, número

do pedido, etc. Esta chave poderá ser arbitrária, designada possivelmente pelo próprio

sistema, incrementando um número seqüencial para cada novo registro do arquivo, com

o único objetivo de poder acessá-los inequivocamente. Em qualquer caso, a chave

identificadora assim criada deverá ser concisa para facilitar a digitação sem erros e o

acesso o aos dados de cada registro.

O caso mais simples é o da entidade que possui um único atributo como identificador.

No DER, atributos identificadores são representador por um círculo preto. Na figura

abaixo, o atributo código é identificador ou chave. Isso significa que cada pessoa possui

um código diferente. Já os atributos nome e endereço não são identificadores – o mesmo

nome (ou o mesmo endereço) pode ser associado a diferentes pessoas. Exemplo:

Podemos ter também um identificador composto por diversos atributos. Em algumas

situações, há mais de um campo ou conjunto de campos que será utilizado para

identificar exclusivamente cada registro num arquivo de dados. Neste caso, devem ser

certificados de que todos os campos que formarão a chave não sejam nulos, não sejam

alterados e que sua combinação seja exclusiva (não deve ser repetido) para identificar

cada registro inequivocamente. Exemplo:


PESSOACódigoNomeEndereço

PRATELEIRANúmero do corredorNúmero da Prateleiracapacidade

11

EMPREGADO DEPENDENTESPOSSUI

1 N


Para este exemplo temos que produtos ficam armazenados em prateleiras. Estas

prateleiras encontram-se em armários organizados em corredores. Os corredores são

numerados seqüencialmente a partir de um e as prateleiras são numerados

seqüencialmente a partir de um, dentro de um corredor. Assim, para identificar uma

prateleira é necessário conhecer seu número e o número do corredor em que se

encontra.

Finalmente, há casos em que o identificador de uma entidade é composto não somente

por atributos da própria entidade, mas também por relacionamentos dos quais a entidade

participa. Exemplo:

Um dependente é identificado pelo empregado ao qual ele está relacionado e pelo

código do dependente que distingue os diferentes dependentes de um mesmo

empregado.

Como os conjuntos não têm elementos duplicados, cada tupla de uma determinada

relação é única no que tange àquela relação, e conseqüentemente obter-se-á a

propriedade de identificação única. Por isso toda relação possui uma chave primária

(possivelmente composta).

CLASSIFICAÇÃO DE RELACIONAMENTOS BINÁRIOS

Um relacionamento binário é aquele cujas ocorrências contêm duas ocorrências de

entidades. Podemos classificar os relacionamentos binários em:

1:1 (um-para-um);

1:n (um-para-muitos)

n:n(muitos-para-muitos).

EXEMPLO DE RELACIONAMENTOS

RELACIONAMENTO 1: 1: Cada departamento possui apenas um chefe e cada chefe

é chefe de apenas um departamento.


1 N


RELACIONAMENTO 1 : N: Cada venda envolve no máximo vários itens/produtos

vendidos e cada item/produto é parte de apenas uma venda.

RELACIONAMENTO N: N: Cada Fornecedor vende vários produtos e cada produto

é fornecido por no máximo por vários fornecedores.

UM-PARA-UM

Ao ser identificado um relacionamento um-para-um, deve-se inicialmente verificar se os

dois objetos relacionados são realmente distintos ou se podem ser unidos em um único.

Se cada objeto for identificado pela mesma chave identificadora e se ambos se

completam, há uma forte razão para unir os dois objetos em um único. Por exemplo, as

entidades PRODUTO e ESTOQUE:

PRODUTO ESTOQUE

CÓDIGO CÓDIGO

NOME NOME

PREÇO SALDO


DEPTO CHEFIApossui

VENDA ITENS DE VENDA

envolve

FORNECEDOR

PRODUTOvendeN N

1 1


Como os PRODUTOS são armazenados no ESTOQUE, pode-se considerar apenas uma

entidade PRODUTOS no ESTOQUE:

PRODUTO NO ESTOQUE

CÓDIGO

NOME

SALDO

PREÇO

Neste caso, as entidades PRODUTO e ESTOQUE não são distintas e, por esse motivo,

deve-se armazená-las num único arquivo de dados, pois o saldo em estoque é apenas um

atributo dos produtos.

Se os dois objetos forem realmente distintos, o relacionamento deverá ser mantido na

base de dados do sistema por um identificador ou chave de relacionamento. Esta chave

de relacionamento deverá estar indicada nas extremidades da linha que representa o

relacionamento, nos dois objetos relacionados, como ilustra a figura a seguir.

No caso do relacionamento um-para-um entre um CARRO e o SEGURO que ele

possui, caso admita-se que os dados (nome, chassi, placa, marca) para o carro sejam

armazenados com os dados dos outros carros num arquivo de CARROS, então uma

chave identificadora, denominada codcarro, seria armazenada no arquivo que descreve o

seguro e apontaria para o registro do carro no arquivo de Carros, como apresentado a

seguir.

CARROS SEGUROS

Codcarro (chave) Codseg(chave)

Nome Tipo


PRODUTO ESTOQUEcontém


Placa Valor

Chassi Data validade

Marca Codcarro(APONTADOR)

Exemplo de chave estrangeira na entidade Seguro

CHAVE ESTRANGEIRA SEGURO – CARRO

No arquivo de SEGUROS, o dado codcarro é conhecido como “chave externa ou

estrangeira” significando que se trata de um dado deste arquivo que também é chave em

outro arquivo a ele relacionado, no caso o de CARROS.

UM-PARA-MUITOS

Como cada objeto de informação sempre possui um arquivo de dados contendo seus

atributos, a chave identificadora do “objeto um” deve ser parte do arquivo que descreve

o “objeto muitos”, podendo ser parte de sua chave identificadora ou não.

RELACIONAMENTO EMPREGADO-DEPENDENTE


EMPREGADO DEPENDENTE

CODEMP(CHAVE) CODDEP (CHAVE)

NOMEEMP CODEMP (APONTADOR)

ENDEMP NOMEDEP

NºDEPENDENTE PARENTESCODEP

TELEMP IDADEDEP

... ...

EMPREGADO DEPENDENTESPOSSUI

1 N

nome codseg

codcarro

Data validade valor

codcarro

placa

marca

1 1CARRO SEGUROPOSS

UI

chassi

tipo


Normalmente, no projeto da base de dados de um sistema aplicativo, deve-se incluir

diversos dados ou chaves externas nos arquivos, com o objetivo de simplificar a

programação necessária para a obtenção das informações que deverão ser fornecidas aos

usuários. A análise das chaves externas ou estrangeiras que deverão ser incluídas em

cada arquivo de dados deve ser feita já nesta fase, com a ajuda do diagrama de entidade-

relacionamento (E-R).

MUITOS-PARA-MUITOS

Um relacionamento muitos-para-muitos sempre deve ser resolvido por dois

relacionamentos um-para-muitos. Neste caso, inicialmente, as chaves de ambos os

objetos deverão ser identificadas e, a seguir, um “objeto de interseção” deverá ser

descoberto ou criado. A chave do objeto de interseção é a combinação ou concatenação

das chaves dos dois objetos originais.

RELACIONAMENTO FORNECEDOR - PRODUTO

Para determinar os dados que deverão estar contidos no objeto de interseção a ser

descoberto ou criado, deve-se analisar o relacionamento muitos-para-muitos entre

FORNECEDOR e PRODUTO fazendo as seguintes perguntas:

Qual deve ser o objeto que possui uma chave que corresponde à concatenação de um

determinado código de fornecedor (codforn) e de um determinado código de produto

(codprod)?

Quais os dados ou atributos que dependem exclusivamente desta combinação ou

relação?

Ao tentar responder estas perguntas verifica-se que diferentes fornecedores podem

fornecer diferentes produtos a determinados preços e prazos de entrega ou, por outro

lado, diferentes produtos são fornecidos por diferentes fornecedores a determinados

preços e prazos de entrega.


FORNECEDOR

PRODUTOfornece

N N


Portanto, como um dado produto estará disponível em diferentes fornecedores a

diferentes preços e com diferentes prazos de entrega, pode-se criar um objeto de

interseção denominado ORIGEM DO PRODUTO. Desta forma, um determinado

fornecedor poderá ofertar vários produtos, cada um com o seu respectivo preço e prazo

de entrega, assim como cada produto poderá ser ofertado por vários fornecedores, e para

cada fornecedor haverá um determinado preço e prazo de entrega.

A Figura seguinte ilustra o relacionamento muitos-para-muitos entre

FORNECEDORES e PRODUTOS resolvido por um relacionamento um-para-muitos

entre FORNECEDOR e ORIGEM DO PRODUTO e um relacionamento um-para-

muitos entre PRODUTO e ORIGEM DO PRODUTO.

FORNECEDOR ORIGEM DO PRODUTO PRODUTO

CODFORN (CHAVE) CODFORN (CHAVE) CODPROD (CHAVE)

NOME CODPROD (CHAVE) NOME

ENDEREÇO PREÇO UNIDADE

TELEFONE PRAZOENTREGA PESO

CEP DESCONTO VOLUME

... ...

RELACIONAMENTO N : N RESOLVIDO

ENTIDADE ASSOCIATIVA

Na modelagem ER não foi prevista a possibilidade de associar uma entidade com um

relacionamento ou então de associar dois relacionamentos entre si. Na prática, quando,

quando está construindo um novo modelo ER ou modificando um modelo ER existente,

surgem situações em que é desejável permitir a associação de uma entidade a um

relacionamento. Considere o exemplo:

Disciplina: Banco de Dados 20MÉDICO PACIENTEconsul

ta

n n

MÉDICO PACIENTE

1 1

n n


Suponha que seja necessário modificar este modelo da seguinte forma. É necessário

saber que medicamentos existem e que medicamentos foram prescritos em cada

consulta. Para saber que medicamentos existem, cria-se uma nova entidade,

MEDICAMENTO. A questão agora é: com que entidade existente deve estar

relacionada a nova entidade? Se MEDICAMENTO fosse relacionado a MÉDICO, ter-

se-ia apenas a informação de que médico prescreveu que medicamentos, faltando a

informação do paciente que os teve prescritos. Por outro lado, se MEDICAMENTO

fosse relacionado a PACIENTE, faltaria a informação do médico que prescreveu o

medicamento. Assim, deseja-se relacionar o medicamento à consulta, ou seja, deseja-se

relacionar uma entidade (MEDICAMENTO) a um relacionamento (CONSULTA), o

que não está previsto na abordagem ER. Para tal, foi criado um conceito especial, o de

entidade associativa. Uma entidade associativa nada mais é que a redefinição de um

relacionamento, que passa a ser tratado como se fosse também uma entidade.

Graficamente, isso é feito como mostrado na figura abaixo.

Observa-se que, caso não se desejasse usar o conceito de entidade associativa, seria

necessário transformar o relacionamento CONSULTA em uma entidade, que então

poderia ser relacionada a MEDICAMENTO, conforme mostrado na figura abaixo. No

modelo da figura, o relacionamento foi substituído por uma entidade homônima, junto

com dois relacionamentos.


n

MÉDICO PACIENTEconsulta

n n

prescrição

MEDICAMENTO

n

nPrescrição


Observe-se que, para manter equivalência com o modelo anterior, uma consulta está

relacionada com exatamente um médico e exatamente um paciente. Uma consulta é

identificada pelo paciente e pelo médico a ela ligada. Tendo substituído o

relacionamento CONSULTA pela entidade, basta relacionar a entidade CONSULTA

com a entidade MEDICAMENTO. Observe que as figuras acima são equivalentes.

Equivalente aqui significa que ambos geram o esmo banco de dados relacional.

GENERALIZAÇÃO/ESPECIALIZAÇÃO

Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades

através do conceito de generalização/especialização. Através deste conceito é possível

atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de

uma entidade genérica. No DER, o símbolo para representar

generalização/especialização é um triângulo isósceles, conforme mostra a figura abaixo.

A generalização/especialização mostrada nesta figura expressa que a entidade

CLIENTE é dividida em dois subconjuntos, as entidades PESSOA FÍSICA e PESSOA

JURÍDICA, cada uma com propriedades próprias.

Associada ao conceito de generalização/especialização está a idéia de herança de

propriedades. Herdar propriedades significa que cada ocorrência da entidade

especializada possui, além de suas próprias propriedades (atributos, relacionamentos e

generalizações/especializações), também as propriedades da ocorrência da entidade

genérica correspondente. Assim, segundo o DER abaixo, a entidade PESSOA FÍSICA

possui, além de seus atributos particulares, CIC e sexo também todas as propriedades da

ocorrência da entidade CLIENTE correspondente, ou seja, os atributos nome e código, o

seu identificador (atributo código), bem como o relacionamento com a entidade

FILIAL. Resumindo, o diagrama expressa que toda pessoa física tem como atributos

nome, código, CIC e sexo, é identificada pelo código e está obrigatoriamente

relacionada a exatamente uma filial. Da mesma maneira, toda pessoa jurídica tem como


CONSULTAMEDICAMENTO

n

(1,1) (0,n)


atributos nome, código, CGC e tipo de organização, é identificada pelo código e está

obrigatoriamente relacionada a exatamente uma filial.

CIC sexo CGC tipo de organização

A Generalização/especialização pode ser classificada em dois tipos, total ou parcial, de

acordo com a obrigatoriedade ou não de a cada ocorrência da entidade genérica

corresponder uma ocorrência da entidade especializada.

Em uma generalização/especialização total para cada ocorrência da entidade genérica

existe sempre uma ocorrência em uma das entidades especializadas. Esse é o caso do

exemplo acima, no qual a toda ocorrência da entidade CLIENTE corresponde uma

ocorrência em uma das duas especializações, ou seja, todo cliente é ou Pessoa Física ou

Pessoa Jurídica. Esse tipo de generalização/especialização é simbolizado por um “t”.

Em uma generalização/especialização parcial, nem toda ocorrência da entidade genérica

possui uma ocorrência correspondente em uma entidade especializada. Esse é o caso da

figura abaixo, no qual nem toda entidade Funcionário possui uma entidade

correspondente em uma das duas especializações (nem todo o funcionário é motorista

ou secretária). Este tipo de generalização /especialização é simbolizado por um “p”.

Usualmente, quando há uma especialização parcial, na entidade genérica (no caso do

exemplo, em Funcionário) aparece um atributo que identifica o tipo de ocorrência da


FILIAL CLIENTE Código

Nome

PESSOAFÍSICA

PESSOAJURÍDICA

t


entidade genérica (no caso do exemplo, trata-se do atributo tipo de funcionário). Este

atributo é necessário no caso de especializações totais, já que a presença da ocorrência

correspondente a entidade genérica em uma de suas especializações é suficiente para

identificar o tipo da entidade.

Uma entidade pode ser especializada em qualquer número de entidades, inclusive em

uma única. Exemplificando, no caso da generalização do Funcionário, se apenas

motoristas possuíssem propriedades particulares, haveria apenas uma entidade

especializada, a de motoristas.

Além disso, não há um número de níveis hierárquicos da generalização/especialização.

Uma entidade especializada em uma generalização/especialização, pode, por sua vez,

ser entidade genérica em uma outra generalização/especialização.

DICIONÁRIO DE DADOS (DD)

Um dicionário de dados é um repositório de dados sobre dados. Adicionalmente

entende-se como "dicionário de dados", também o conjunto de procedimentos para criar

e manter este repositório.

Diz-se então que um sistema de dicionário de dados (SDD) é um software para coletar,

manter e publicar informações sobre dados. As informações sobre os dados são

denominadas de metadados (dados sobre os dados).

O dicionário de dados é um instrumento para administrar dados como recursos da

organização e um reservatório para todas as informações definitivas sobre dados da

organização, incluindo identificação sobre características, relacionamentos e

autorizações, em alguns casos, constitui uma ferramenta capaz de armazenar, além dos

dados sobre os dados, também formatos de telas, descrições de relatórios, verificações


FUNCIONÁRIO

MOTORISTA SECRETÁRIA

p

Tipo de funcionário


de validade, controle de segurança, etc.

Portanto, os sistemas de dicionários de dados são muito mais do que simples

ferramentas de documentação de dados, são complexos sistemas de informação,

gerenciamento e controle de dados.

De uma maneira geral, a maioria dos dicionários de dados (DD) é concebida para dar

apoio a um determinado sistema de gerência de banco de dados (SGBD).

Os usos de um dicionário de dados são múltiplos. A seguir relacionamos as áreas onde

ele pode ser utilizado:

• Planejamento e análise de negócios - (Planejamento de dados; Modelagem de

processos).

• Administração de banco de dados (ABD) - (Geração e documentação das

estruturas de dados; Geração das definições sobre segurança de dados).

• Desenvolvimento de sistemas.

• Auditorias e controles.

• Sistemas de teleprocessamento.

Um dos benefícios de se usar um Dicionário de Dados é que além do apoio essencial à

administração de dados e administração de banco de dados, o DD (suas extensões)

proporciona um local centralizado para documentar todas as informações referentes

à fase de análise.

ESTRUTURA DO DICIONÁRIO DE DADOS

Neste item é apresentado um exemplo de Dicionário de Dados responsável pela

estrutura física de um sistema contendo o nome da entidade, atributos, descrições dos

atributos, o tipo de cada atributo, tamanho e domínio dos mesmos. As chaves

primárias e/ou estrangeiras estão identificadas com um "*". Veja exemplo na tabela o

Exemplo de Dicionário de Dados

ENTIDADE

FORNECEDOR

ATRIBUTO DESCRIÇÃO TIPO TAMANHO OPÇÃO DOMÍNIO

Codfor* Código do

Fornecedor

Numérico 03 OB > 0

Nf Nome Fantasia Caracter 50 OB



Rs Razão Social Caracter 50 OB

Dtcad Data de

cadastro

date OB > 01/01/00

IE Inscrição

Estadual

Numérico 12 OP

Rua Endereço Caracter 50 OB

CEP Código Postal Numérico 10 OB 00000-000

Tel Telefone Numérico 13 OB (00)0000-

0000

DEFINIÇÃO DAS ENTIDADES

Nesta etapa deve ser definido o conteúdo exato de cada arquivo de dados que irão

compor a base de dados do sistema. Deve-se definir todos os dados ou elementos de

dados que serão armazenados em cada arquivo de dados para descrever os atributos de

cada entidade ou evento do modelo entidade-relacionamento. Além disso, deve-se

também detalhar os dados que formarão a chave apontadora de relacionamentos entre

arquivos.

Após a verificação dos elementos de dados que descrevem todas as entidades e os

eventos deve-se fazer o seguinte questionamento: “Se eu dirigisse esse negócio, o que

gostaria que fosse armazenado no sistema?” Certamente, quanto mais você conhecer

o negócio e compreender os objetivos dos usuários em requisitar o sistema, tanto melhor

poderá responder esta pergunta. Contudo, você não deverá tentar dizer a um empresário

como a empresa deve ser administrada, mas poderá certamente fazer sugestões. Em

geral é mais fácil oferecer uma lista de sugestões de elementos de dados ao usuário e

solicitar que ele elimine e/ou acrescente itens na lista. Deste modo, você estará dizendo

ao usuário “Segundo meus limitados conhecimentos do seu negócio, parece que

seria útil ter essas informações armazenadas no sistema. Há alguma coisa que eu

esqueci? E considerando o custo de coletar e armazenar informações há alguma

coisa na lista que pode ser omitida sem lhe fazer falta no futuro?” Ao formular estas

perguntas, você estará efetivamente envolvendo o usuário no projeto do sistema fazendo

com que ele se sinta comprometido com sua definição e, portanto, sendo mais

cuidadoso e responsável ao respondê-las. A partir dos resultados obtidos, você poderá



produzir uma definição preliminar do conteúdo de cada arquivo de dados que descreve

uma entidade.

NOME DOS ELEMENTOS DE DADOS ATRIBUTOS

Cada dado ou elemento de dado deve possuir um nome exclusivo, e ser tão significativo

quanto possível. Há muitas formas e convenções que foram propostas para dar nomes

aos dados, você poderá utilizar uma delas ou criar a sua própria. Porém, definindo-se

por uma, procure mantê-la em todos os seus sistemas.

Recomenda-se que cada dado tenha uma descrição resumida que deverá explicar

inteiramente a natureza do dado e será utilizada para descrever o dado num dicionário

de dados que fará parte da documentação do sistema. Por exemplo:

ATRIBUTO DESCRIÇÃO

CODPRO Código de Identificação do Produto

NOMPRO Nome que identifica o Produto

UNID Unidade de medida do produto. ex: metros, quilos, caixas.

DOMÍNIO E INFORMAÇÕES DOS ELEMENTOS DE DADOS

O domínio de um elemento de dado é o conjunto de valores válidos para aquele

elemento. Assim, o domínio de uma data pode ser qualquer data válida posterior a

01/01/1900, o domínio do preço de um produto pode ser um valor entre R$ 100 e R$

200, e assim por diante. Se for possível determinar o domínio de um elemento de dado,

você poderá definir critérios de validação para determinar valores de dados aceitáveis

durante a entrada ou edição de dados no sistema.

Outras informações relativas a cada elemento de dado devem ser definidas para

descrever completamente o conteúdo de um arquivo de dados.

1. Tipo de dado: refere-se ao conteúdo do elemento de dado, podendo ser,

dependendo da ferramenta, numérico (N), cadeia de caracteres (C), data (D),

lógico (L), memo (M), entre outros.

2. Tamanho do dado: refere-se ao número máximo de posições que poderá

assumir.



3. Responsabilidade do dado: revela a pessoa ou a unidade da empresa

responsável pela correção do dado, que tenha a autoridade final pela correta

maneira de como o dado deve ser inserido e atualizado no sistema. Por exemplo,

o gerente de pessoal é responsável pelo dado salário, uma vez que somente ele

pode autorizar uma alteração do valor do salário de qualquer funcionário.

MODELO RELACIONAL

Publicado em 1970 por Edgard F. Codd, na época matemático membro do laboratório

de pesquisa da IBM, objetivava:

a) fornecer base teórica sólida para a área de BD;

b) separar os aspectos lógicos da implementação física;

c) comunicabilidade - todos os usuários e programadores possam acessar o BD a

partir da compreensão de um modelo estruturalmente simples;

d) processamento de conjuntos - linguagem de 4º geração, onde um único comando

processa vários conjuntos de registros de uma só vez.

O Banco de Dados Relacional é um Banco de Dados visto pelo usuário como um

conjunto de tabelas e nada além de tabelas, cada qual designada por um único nome.

CONCEITOS BÁSICOS

Na maior parte da literatura relacional, as tabelas são tratadas como relações. Cada linha

de nossa relação será chamada de TUPLA e cada coluna de nossa relação será chamada

de ATRIBUTO. O conjunto de valores passíveis de serem assumidos por um atributo

será intitulado de DOMÍNIO.

Instância da relação consiste no conjunto de valores que cada atributo assume em um

determinado instante. Portanto, os dados armazenados no Banco de Dados, são

formados pelas instâncias das relações.

Para exemplificar melhor, utilizar-se-á um banco de dados contendo fornecedores, peças

e embarques. Os quadros nº 02, 03 e 04 mostram os dados de teste em forma relacional,

isto é, elas representam uma visão relacional dos dados.

Tabela – FORNECEDORES



Código- S# S_Nome Status Cidade

F1 SMITH 20 LONDON

F2 JONES 10 PARIS

F3 BLAKE 30 PARIS

Tabela – PEÇAS

Codigo – P# P_Nome Cor Peso Cidade

P1 NUT RED 12 LONDON

P2 BOLT GREEN 17 PARIS

P3 SCREW BLUE 17 ROME

P4 SCREW RED 14 LONDON



Tabela – EMBARQUES

Código - S# Codigo - P# Quantidade

F1 P1 300

F1 P2 200

F1 P3 400

F2 P1 300

F2 P2 400

F3 P2 200

Pode-se ver que os dados estão organizados em três tabelas: Fornecedores, Peças e

Embarques.

A abordagem relacional aos dados está baseada na observação de que arquivos que

obedecem a certas limitações podem ser considerados como relações matemáticas, e

conseqüentemente a teoria elementar de relações pode ser usada para lidar com vários

problemas práticos com os dados desses arquivos.

O Quadro a seguir apresenta uma Relação de Funcionário.

MATR NOME SEXO IDADE CPF C_ PROF SALÁRIO

20 MARCOS JOSÉ M 20 123456789 53246 2.5000.00

32 ANTONIO CARLOS M 32 345623456 65423 36000.00

40 JOAQUIM MANOEL M 19 239483732 36763 40000.00

16 PEDRO PAULO M 46 231938234 84632 18000.00

19 ALICE MARIA F 19 432938345 65834 16000.00

Esquema de dados: Funcionário (Matrícula, Nome, Sexo, Idade, CPF, Cart_Prof.,

Salário).

Exemplo de domínio: SEXO [M, F] e IDADE [18,60]

Existem algumas condições que devem ser satisfeitas por uma Relação:

a) cada Relação só deve conter um tipo de Tupla;

b) cada Relação deverá conter um número fixo de domínios;

c) cada Relação só possuirá uma Chave Primária (sem duplicatas);



d) uma Relação não deve representar mais que um Relacionamento;

e) todos os Atributos que formam a Chave Primária, devem identificar cada um

dos demais Atributos da Relação.

Algumas características do Modelo Relacional:

Uma tabela é acessível por qualquer campo (atributo) independente se este é

declarado como chave ou não;

O relacionamento entre conjunto de dados (tabelas) não existe fisicamente,

pois este relacionamento é apenas lógico e representado através das chaves

estrangeiras;

Utilização de linguagens não procedurais;

Os ambientes relacionais possuem um otimizador estratégico para escolher o

melhor caminho para recuperação dos dados.

Existem diversas linguagens para expressar as operações de consulta, inserção, remoção

e atualização de tuplas, como por exemplo, o cálculo relacional e a álgebra relacional.

Como exemplos têm SQL, QBE e Quel.

OBS: Como a SQL é a mais utilizada daremos ênfase nela posteriormente.

CONVERSÃO MER PARA MODELO RELACIONAL

1 - Integridade de Identidade (ou entidade)

A chave primária não pode conter um valor nulo (NULL). O NULL não é valor 0 (zero)

nem o caractere branco, é simplesmente a não-existência de conteúdo neste campo.

2 - Integridade Referencial

Se uma determinada tabela A possui uma chave estrangeira, a qual é chave primária em

outra tabela B, então deve:

Ser igual a um valor de chave primária existente em B; Ou

Ser NULA (NULL).

Não pode existir na chave estrangeira, um valor que não exista na tabela na qual ela é

chave primária.

As regras de integridade do modelo relacional representam a garantia de que as tabelas

guardam informações compatíveis. São de extrema importância para a confiabilidade



das informações contidas no banco de dados.

REGRAS DE CONVERSÃO

Existem regras precisas que não dão margem a erros, sendo que uma vez projetado o

ER, as tabelas que representam o ER num nível mais baixo podem ser obtidas de forma

clara.

A) Mapeamento das entidades

Toda entidade torna-se uma tabela carregando todos os atributos (definidos para a

entidade). Cada atributo vira um campo da tabela criada. Cada uma das chaves gera

“estruturas de acesso”. A chave primária e as chaves candidatas são projetadas para não

permitirem ocorrências múltiplas e nem admitem nulos.

Você vê um retângulo, o que fazer? Transformá-lo em uma tabela, não tem como errar.

B) Mapeamento dos atributos

Os atributos das entidades e relacionamentos (que possuem atributos) devem ser

gerados na ordem que minimize o consumo de espaço de armazenamento e torne mais

eficiente a recuperação. Devem ser exploradas todas as características de SGBD em uso.

Para tanto, deve ser considerado se os campos têm ou não a especificação de extensão

em bytes, se existe localização no interior do registro que propicie vantagens na

recuperação e se existe compactação de espaços não ocupados.

C) Mapeamento dos relacionamentos

Navegação incorporada: trabalha diretamente com o conceito de chave estrangeira.

RELACIONAMENTO – 1: N (ENVOLVENDO ENTIDADES

DISTINTAS)

A entidade (tabela) cuja conectividade é N carrega o identificador da entidade (tabela)

cuja conectividade é 1 (chave estrangeira), e os atributos do relacionamento, se houver

(é praticamente impossível aparecer em relacionamentos 1:N e 1:1 algum atributo, pois

neste nível já se consegue enxergar quem é o dono do dado). Ou seja, quem está com

‘N’ do lado carrega a chave do outro.



Exemplo de Modelo E-R:

1 N

Departamento Funcionário

Cod Nome do Departamento Mat. Nome Etc. CDEP

SFT ANÁLISE 4534 Soraia Matos ... SFT

COB-2 PROGRAMAÇÃO 6547 Breno Medeiros ... ADP

ADP DIRETORIA SISTEMAS 7734 Gustavo Borges ... COB-2

1198 Ana Ferreira ... SFT

3289 Telma Ribeiro ... ADP

RELACIONAMENTO – 1: N (ENVOLVENDO AUTO

RELACIONAMENTO)

Incluir a chave primária da entidade na própria entidade como chave estrangeira,

gerando uma estrutura de acesso a partir desta chave estrangeira.

Peça

Cód. Nome Etc. Códch

4534 Correia ...

6547 Parafuso ...

7734 Freio ... 6547

1198 Carburador ... 6547


Departamentotem

Funcionário

Peça

Compõe

1 N


RELACIONAMENTO – 1:1 (ENVOLVENDO ENTIDADES DISTINTAS)

As entidades (tabelas) envolvidas neste relacionamento carregarão identificador da

outra conforme a conveniência do projeto (de acordo com o acesso a essas tabelas).

CARRO SEGURO

PLACA

(CHAVE)

NOME Etc. Apólice Tipo Etc. PLACA

GPP-1212 GOL ... 4534 Total ... GPP-1212

GHH-1515 PALIO ... 6547 Parcial ... GHH-1515

DLL-1818 VECTR

A

... 7734 Total ... DLL-1818

RELACIONAMENTO - 1:1 (ENVOLVENDO AUTO-RELACIONAMENTO)

Incluir a chave primária da entidade na própria entidade (chave estrangeira) e gerar uma

estrutura de acesso para ela.


Pessoa

Casada com

1 1

CARRO SEGUROpossui1 1


Papel de Marido Papel de Esposa

Cód Nome Códcj Cód Nome Códcj

P2 Maurício P2 Maurício P1

P3 Celso P3 Celso P4

P1 Susana P2 P1 Susana

P4 Edna P3 P4 Edna

P5 Carlos P5 Carlos

RELACIONAMENTO - N: N (ENVOLVENDO ENTIDADES DISTINTAS E

AUTO-RELACIONAMENTOS)

O relacionamento torna-se uma tabela carregando os atributos (se houver) e os

identificadores das tabelas (entidades) que ele relaciona. Esse é o único caso em que um

relacionamento torna-se uma tabela.

Funcionário Alocado

Mat. Nome Etc MAT CODP DTALOC Projeto

4534 Soraia Mattos ... 4534 PRIB ... Codp Nome do projeto

6547 Breno Medeiros ... 1198 PRIB ... PRIB Ribeira

7734 Gustavo Borges ... 4534 PLV 05/05/94 PLV Linha Vermelha

1198 Ana Ferreira ... 6547 PRIB ... PPIR Piratininga

3289 Telma Ribeiro ... 7734 PPIR 17/02/92 PBG Guanabara

3289 PPIR ...

7734 PRIB 04/05/94


Funcionário Alocado

ProjetoN N


Disciplina Pré-Requisito

Cód.

Disciplina

Nome

Disciplina

Cód. CPré

666 Química I 123 888

123 Cálculo III 491 324

324 Física I 491 888

888 Cálculo II 666 324

491 Física II

AS GENERALIZAÇÕES

Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao qual pertencem.

FuncionárioMat. Nome Funçã

oCDEP

4534 Soraia Matos Eng SFT6547 Breno

MedeirosVem ADP

7734 Gustavo Borges

Ven COB-2

1198 Ana Ferreira Sec SFT3289 Telma Ribeiro Ven ADP

DepartamentoCod Nome do DepartamentoSFT ANÁLISECOB-2 PROGRAMAÇÃOAPD DIRETORIA SISTEMAS

Matric. Matric. Matric.

Ajuda de Custo Hora extra Ling. Estran.

Especialidade Desp. Extra Curso


Pré-Requisi-to

Disciplina

N N

Departa-mento Tem Funcioná-

rio

Engenheiro Vendedor Secretária

1:1

N1


Placa Carro

ENGENHEIRO VENDEDOR SE

Mat. Aj.Custo Espec Mat. HRExt DPext PI Carro Mat. Ling. Est. Curso

4534 120 Eletr. 6547 34 240 AH4232 4534 Inglês Comp.

7734 YR5701

3289 5 23 JK5839

A garantia de não-sobreposição dos subconjuntos é uma restrição de integridade que

deve ser expressa na linguagem de acesso ao banco de dados (ex: SQL).

O conjunto ‘funcionário’ vira uma tabela (regra padrão) e os subconjuntos serão

transformados em outras tabelas, carregando a chave primária matrícula.

NORMALIZAÇÃO DE ARQUIVOS DE DADOS

Normalmente um sistema de informação utiliza um conjunto de arquivos de dados

relacionados, nos quais são armazenados os dados que descrevem as entidades e eventos

sobre os quais se deseja obter informação. Podemos definir uma base de dados ou banco

de dados como sendo este conjunto de arquivos de dados vinculados ou relacionados,

dentro de um determinado contexto, definido pelos objetivos do sistema em questão.

Definidos os arquivos e os respectivos elementos de dados que formará a base de dados,

o próximo passo do projeto do sistema é simplificar os arquivos para remover elementos

de dados redundantes e grupos repetitivos. Esse processo de simplificação de arquivos

que compõem uma base de dados é denominado NORMALIZAÇÃO. Ou seja, consiste

em definir o formato lógico adequado para as estruturas de dados identificados no

projeto lógico do sistema, com o objetivo de minimizar o espaço utilizado pelos dados e

garantir a integridade e confiabilidade das informações.

Os conceitos e as técnicas de normalização foram desenvolvidos pelo Dr. E. F. Codd da

IBM e sua equipe, quando pesquisavam sobre a matemática de conjuntos. No conjunto

matemático, nenhuma duplicata de qualquer objeto é permitida. Como um arquivo é

um conjunto de registros, na teoria nenhum registro, num arquivo de dados, pode ser

uma duplicata de qualquer outro registro.

A normalização é feita, através da análise dos dados que compõem as estruturas

utilizando o conceito chamado "Formas Normais (FN)". As FN são conjuntos de

restrições nos quais os dados devem satisfazê-las. Pode-se dizer que a estrutura está na



primeira forma normal (1FN), se os dados que a compõem satisfizerem as restrições

definidas para esta etapa.

Através da normalização, os arquivos de dados tornam-se mais adequados para o

armazenamento e a atualização de dados, evitando-se redundâncias e inconsistências na

base de dados. O processo de normalização consiste basicamente em regras para definir

adequadamente os elementos de dados ou campos que comporão os arquivos de dados.

As regras de normalização de arquivos visam a:

a) Minimizar redundâncias;

b) Eliminar anomalias de atualização;

c) Prover o melhor caminho de acesso a qualquer elemento de dado;

d) Assegurar resistência a manutenções no modelo de dados;

e) Evitar dados não identificáveis através de definição rigorosa de

identificadores e relacionamentos.

A normalização completa dos dados é feita, seguindo as restrições de 5 formas normais

existentes, sendo que a passagem de uma FN para outra é feita tendo como base o

resultado obtido na etapa anterior, ou seja, na FN anterior.

Em geral, apenas as três primeiras regras básicas de normalização são suficientes para

resolver a grande maioria dos casos. Poderíamos resumir estas três formas normais mais

utilizadas da seguinte maneira:

a) Eliminar campos repetitivos;

b) Eliminar dados redundantes;

c) Eliminar atributos não dependentes.

PRIMEIRA FORMA NORMAL (1FN)

Consiste em retirar da estrutura os elementos repetitivos até que cada dado tenha uma

chave identificadora para cada ocorrência, ou seja, aqueles dados que podem compor

uma estrutura de vetor. Podemos afirma que uma estrutura está normalizada na 1FN, se

não possuir elementos repetitivos. Exemplo:

Estrutura original:

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Cod. do Cliente, Nome do

cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias vendidas (onde

para cada mercadoria temos: Código da Mercadoria, Descrição da Mercadoria,



Quantidade vendida, Preço de venda e Total da venda desta mercadoria) e Total Geral

da Nota).

Analisando a estrutura acima, observamos que existem várias mercadorias em uma

única Nota Fiscal, sendo, portanto elementos repetitivos que deverão ser retirados.

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome

Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria,

Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Obs. Os campos sublinhados identificam as chaves das estruturas.

Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas, a

saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Dados que compõem a estrutura

original, excluindo os elementos repetitivos.

- Segunda estrutura (Arquivo de Vendas): Dados que compõem os elementos

repetitivos da estrutura original, tendo como chave o campo chave da estrutura original

(Num. NF) e o campo chave da estrutura de repetição (Código da Mercadoria).

SEGUNDA FORMA NORMAL (2FN)

Consiste em retirar das estruturas que possuem chaves compostas (campo chave sendo

formado por mais de um campo), os elementos que são funcionalmente dependente de

parte da chave. Podemos afirmar que uma estrutura está na 2FN, se ela estiver na 1FN e

não possuir campos que são funcionalmente dependentes de parte da chave. Exemplo:

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do

cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)



Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria,

Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Estrutura na segunda forma normal (2FN):



Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da

venda desta mercadoria)

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de

venda)

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo

de Notas Fiscais, não foi alterado, por não possuir chave composta) em duas estruturas,

a saber:

- Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo

excluídos os dados que são dependentes apenas do campo Código da Mercadoria.

- Segunda estrutura (Arquivo de Mercadorias): Contém os elementos que são

identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota

Fiscal, a descrição e o preço de venda serão constantes.

TERCEIRA FORMA NORMAL (3FN)

Consiste em retirar das estruturas os campos que são funcionalmente dependentes de

outros campos que não são chaves. Podemos afirmar que uma estrutura está na 3FN, se

ela estiver na 2FN e não possuir campos dependentes de outros campos não chaves.

Para verificar se um arquivo da segunda forma normal também está na terceira forma

normal devemos perguntar: algum campo não-chave é dependente de qualquer outro

campo não-chave? Exemplo:

Estrutura na segunda forma normal (2FN):








venda)

Estrutura na terceira forma normal (3FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente e Total

Geral da Nota)




venda)

Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e CGC

do cliente)

Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por

ser o único que possuía campos que não eram dependentes da chave principal (Num.

NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e CGC do cliente

são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos

e economizar espaço por eliminar o armazenamento freqüente e repetidas vezes destes

dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados

e poderá ocorrer divergência entre eles.

As estruturas alteradas foram pelos motivos, a saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos originais, sendo

excluído os dados que são dependentes apenas do campo Código do Cliente

(informações referentes ao cliente).



- Segunda estrutura (Arquivo de Clientes): Contém os elementos que são identificados

apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço

e CGC dos clientes serão constantes.

RESULTADO DA NORMALIZAÇÃO DE ARQUIVOS

Apesar de existirem as simplificações da quarta e da quinta forma normal, que ainda

poderão ser feitas em arquivos de dados, geralmente, os arquivos que estiverem na

terceira forma normal não contém redundâncias, são simples de serem compreendidos,

simples de serem atualizados e seus dados podem ser facilmente recuperados. Já estão,

portanto, numa forma adequada para serem implementados num sistema de

informações.

Ao adquirir experiência no desenvolvimento de sistemas, a simplificação de arquivos

até a terceira forma normal se tornará praticamente automática e inconsciente, pois esta

forma garante a implementação mais fácil dos programas. Contudo, a simplificação dos

dados também requer conhecimento da empresa, dos métodos e regras por ela utilizado,

os quais determinam os relacionamentos entre os elementos de dados, e as possíveis

alterações que esses relacionamentos possam sofrer.

A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades

específicas do sistema, a critério do analista de desenvolvimento durante o projeto físico

do sistema.



ROTEIRO PARA SE CHEGAR ATÉ A TERCEIRA FORMA NORMAL


ARQUIVO NÃO NORMALIZADO (Grupos

repetidos)

Desmembrar o arquivo em mais arquivos sem grupos de dados repetidos. Designar um ou mais campos (elementos de dados) como a chave primária a menor chave que identifique exclusivamente cada registro (instância).

ARQUIVO NA PRIMEIRAFORMA NORMAL

(Sem Grupos Repetidos)

Para arquivos cujas chaves sejam concatenadas, verificar se cada campo não-chave é dependente da chave como um todo e não apenas de parte dela. Se necessário, desmembrar o arquivo para conseguir isto.

ARQUIVO NA SEGUNDAFORMA NORMAL

(Campos não-chave dependentes da chave

primária)

Verificar se todos os campos não chave são dependentes entre si. Remover campos redundantes ou, se necessário, desmembrar o arquivo para conseguir isto.

ARQUIVO NA TERCEIRAFORMA NORMAL

(Campos não-chave dependentes da chave primária e independentes entre si)


O que é INTERBASE?

O Interbase é um poderoso banco de dados Cliente/Servidor relacional que é compatível com SQL-ANSI-93, e foi desenvolvido para ser um banco de dados independente de plataformas e de sistemas operacionais.

Este banco de dados dispensa maiores estruturas dentro da empresa, (DBA), onde basta instalar o software e usá-lo, sem a interferência freqüente de profissionais, especializados na manutenção do banco de dados de produção.

Acompanhando, isso tudo ele ainda dispensa o uso de super servidores, usando pouco espaço em disco para sua instalação e utilizando pouca memória em situações normais de uso. Por isso a plataforma necessária para a sua instalação e utilização pode ser reduzida diminuindo consideravelmente os custos do projeto.

Seu desenvolvimento iniciou em meados de 1985 por uma equipe de engenheiros da DEC (Digital Equipament Corporation). Tendo como nome inicial de Groton, esse produto veio sofrendo varias alterações até finalmente em 1986 receber o nome de Interbase® iniciando na versão 2.0. Nesta época, a idéia era produzir um SGBDR (Sistema Gerenciador de Bancos de Dados Relacionais) que oferecesse benefícios não encontrados em outros da época.

O Interbase tem o seu código distribuído gratuitamente pela Internet (o tão falado Open Source) sendo que as licenças de utilização e distribuição agora são totalmente FREE! Isso mesmo, custo 0, de graça.

Outra grande vantagem do Interbase é que ele é multiplataforma, ou seja, funciona em vários Sistemas Operacionais, dentre eles destacamos: Windows 9x, Windows NT, Linux, Solaris.

1. IBCONSOLE - O QUE É? E PRA QUE SERVE?

O IBConsole é o gerenciador de Dados que acompanha o InterBase. No IBConsole, você realmente aprende a linguagem SQL, pois, toda e qualquer criação, relacionamento, manutenção, é feito no ISQL, tudo via Linha de Comando. Existem outras ferramentas no mercado, como IB Admin, IBExpert´s, muito boas e de fácil aprendizado e, com criação automática da grande maioria dos Comandos de DML “Linguagem de Manipulação de Dados”.

Primeiramente criaremos uma pasta na unidade C onde ficara o banco de dados e os arquivos do nosso sistema, esta pasta se chamará Exemplo, então o diretório do nosso sistema será C:\Exemplo.

Vamos abrir agora o IBConsole que é o gerenciador do InterBase, eis a janela do IBConsole.



Basta dar dois cliques em Local Server e abrirá a seguinte tela:

No IBConsole o usuário master é “SYSDBA” e a sua senha é “masterkey”, o seu uso é bastante simples, inicialmente você precisa se “logar” no IBConsole para isso clique com o botão direito sobre a opção “Local Server” e escolha “login” em USERNAME você informa o usuário master e a sua senha acima descrita.

Abrirá a tela para criarmos o banco:



Vamos criar nosso banco de dados (neste exemplo criaremos um banco de dados Local) que é um arquivo com a extensão GDB, clique com o botão direito em cima de Databases e seleciona Create Database e abrirá essa tela:

Preencha como na figura acima, em Alias digite Exemplo em Filename(s) digite o caminho do banco e o nome do banco seguido da extensão GDB, C:\Exemplo\Exemplo.GDB clique em OK pronto nosso banco de dados esta criado, agora é só criar as tabelas. Com o Database criado a tela tem que ficar com essa aparência.



Agora vamos criar nossa tabela, o sistema de exemplo terá apenas uma tabela, mas você pode criar várias tabelas dentro de um Database, clique no ícone SQL aquele ícone verde e amarelo que parece com um marciano correndo com as letras SQL de amarelo embaixo ou escolher a opção “interactive SQL” no menu Tools ou clicar no ícone SQL. Com ela, podemos enviar comandos SQL para o servidor Interbase administrar nossos dados. Ao carregarmos o Interbase Windows ISQL, veremos uma tela dividida em duas partes, a parte superior aceita comandos SQL e os resultados aparecerão na parte inferior.

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



1. Volta ao(s) comando(s) anteriores;2. Mostra o(s) próximo(s) comando(s);3. Executa o(s) comando(s);4. Prepara a corrente consulta para ser executada;5. Fetch all faz uma busca de tudo.6. Commit;7. Rollback;8. Abre algum arquivo;9. Salva um arquivo;10. Localizar palavras;11. Alterna entre as janelas;12. Impressão.

Vamos agora ao código da nossa tabela:

CREATE TABLE CLIENTE(CodCli INTEGER NOT NULL PRIMARY KEY,NomCli VARCHAR (40),EndCli VARCHAR (40),BairroCli VARCHAR (25),TelCli VARCHAR (15),DatCli DATE);

Fica assim:

Com isso estamos criando seis campos, CodCli do tipo inteiro, NomCli, EndCli, BairroCli e TelCli do tipo texto e DatCli do tipo date, clique em Execute Query ( aquele ícone com um raio amarelo e um ponto de interrogação azul ), se tudo estiver ok a tela que digitamos o código para criação da tabela deve ficar em branco, para visualizar a tabela que criamos nesta tela digite: SELECT * FROM CLIENTE e execute a query, você vai poder visualizar os campos no Grid abaixo.



TIPOS DE DADOS DO INTERBASE

O Interbase 6.5 suporta a maioria dos tipos de Dados do SQL. O Interbase, apenas não tem como tipo de dado, o tipo Boolean. Mas, isto não é uma falha do Interbase, outro SGDB´s também não tem este tipo de dado. Apesar de não ter este tipo de dados, podemos criar o nosso “tipo boolean” através de DOMAINS.

BLOB Este tipo de campo é o tipo indicado para armazenar Textos Grandes “Memos”, Fotos, Gráficos, Ícones, isto é, aparentemente não tem um tipo de dado que não possa ser armazenado no Campo Blob. Campos Blob´s não podem ser indexados.

Subtipo 0 - Armazena dados em formato binário – Fotos, etc.Subtipo 1 - Armazena dados em formato texto – Memos.

A única consideração que deve ser tomada é a de se certificar de sempre armazenar o tipo pré-determinado de informação no respectivo subtipo de BLOB. O Interbase não faz nenhuma análise dos dados que estão sendo gravados, portanto essa é uma responsabilidade do aplicativo. Nenhum erro será retornado pelo Interbase se um tipo errado de dado for inserido em um BLOB de subtipo incorreto, mas um aplicativo pode ser prejudicado se ao recuperar as informações do BLOB, a mesma não corresponder ao formato esperado.Sintaxe : Estas declarações são usadas na criação de tabelas : Create table (...,texto_MEMO BLOB SUB_TYPE 1, FOTO BLOB SUB_TYPE 0 …) CHAR(n) e VARCHAR(n)Ex : CREATE TABLE … ( … SEXO CHAR(01), NOME VARCHAR(50) NOT NULL ...)



DATEDATE armazena a Data, e seu tamanho é de 32 bits inteiros longos.Ex : CREATE TABLE … (… DATA_ADMISSAO DATE)

TIMETIME armazena a hora, e seu tamanho é de 32 bits inteiros longos.Ex : CREATE TABLE … (… HORA_ENTRADA TIME, HORA_SAIDA TIME)

TIMESTAMPO tipo de Dado TIMESTAMP, armazena a Data e a hora ao mesmo tempo, e seu tamanho é de 32 bits inteiros longos.Ex : CREATE TABLE … (… DATA_HORA_MOVIMENTACAO TIMESTAMP ...)

DECIMAL e NUMERICDECIMAL e NUMERIC armazena dígitos a serem gravados na precisão especificada na criação da tabela.Ex : CREATE TABLE … (… SALARIO DECIMAL(15,02) ...) ou CREATE TABLE … (… SALARIO NUMERIC(15,02) ...)

SMALLINTEx : CREATE TABLE … (… ALTURA SMALLINT ...)

INTEGEREx : CREATE TABLE … (… ID INTEGER NOT NULL PRIMARY KEY )

FLOAT Ex : CREATE TABLE … (… VLR_ULT_CMP_ITEM FLOAT ...)

DOUBLE PRECISIONEste é o tipo de campo recomendado para uso monetário/valores com muitas casas depois da vírgula no InterBase. Ex: CREATE TABLE …(…VALOR_TOTAL_MOVIMENTACAO_DIA DOUBLE PRECISION...)



A LINGUAGEM SQL

INTRODUÇÃO

A Linguagem de Consulta Estruturada - SQL (Structured Query Language) é a

linguagem comum do gerenciamento de banco de dados cliente/servidor. A SQL,

inicialmente chamada Sequel, foi criada, porque no início da década de 1970, a IBM

queria um método por intermédio do qual as pessoas sem conhecimento de programação

pudessem extrair as informações que desejassem obter a partir de um banco de dados.

A principal vantagem da SQL é o fato de ser uma linguagem padronizada – você pode

usar um conjunto comum de instruções em SQL com todos os sistemas de

gerenciamento de banco de dados que obedecem ao padrão vigente da SQL. O primeiro

padrão de SQL, nos EUA, foi estabelecido em 1986, como ANSI X3,135-1986. Em

1992 foi estabelecida como ANSI1 X3.135-1992, conhecido como SQL/92 ou SQL 2.

O SQL passou em 1999 por uma nova revisão e é conhecido atualmente com SQL/99

ou SQL 3.

A SQL é uma linguagem padrão de aplicações para banco de dados relacionais e não

uma linguagem de programação.

A implementação da SQL é independente de qualquer linguagem de sistema com a qual

possa ser utilizada. E se você trabalha com banco de dados de qualquer tipo, é quase

certo que terá necessidade de aprender a SQL.

Embora nos refiramos à linguagem SQL como uma “linguagem de consulta”, ela possui

muitos outros recursos além da consulta ao banco de dados, como meios para a

definição da estrutura de dados, para modificação de dados no banco de dados e para a

especificação de restrição de segurança.

Os comandos de SQL são divididos em seis categorias de utilização:

DQL – Data Query Language – (Linguagem de Consulta aos Dados) obtêm dados de

tabelas e determinam como os resultados da recuperação devem ser apresentados. O

comando SELECT é a principal instrução dessa categoria.

1 O ANSI (que significa American National Standards Institute) é o órgão dedicado a estabelecer e manter padrões científicos e de engenharia.



DDL – Data Definiton Language – (Linguagem de Definição de Dados) incluem as

instruções CREATE, DROP e ALTER, que definem a estrutura dos objetos de dados.

DML – Data Manipulation Language – (Linguagem de Manipulação de Dados)

incluem os comandos INSERT e DELETE, que acrescentam ou eliminam linhas inteiras

das tabelas, e o comando UPDATE que pode alterar os valores dos dados em colunas

especificadas no interior das linhas.

TPL – Transaction Processing Language – (Linguagem de Processamento de

Transações) os comandos incluem BEGIN TRANSACTION, COMMIT e

ROLLBACK, os quais agrupam várias operações de DML. Se uma operação de DML

falha em uma transação, as operações precedentes de DML são canceladas (o que se

denomina rollback).

CCL – Cursor Control Language – (Linguagem de Controle de Cursor) As

construções de controle de cursor são implementadas pelo mecanismo de banco de

dados conhecido como Engine (motor); assim, esses comandos não serão discutidos.

DCL – Data Control Language – (Linguagem de Controle de Dados) garantem e

revogam privilégios para uso do banco de dados. Comandos Grant e Revoke.

Deve-se ressaltar que a linguagem SQL é utilizada tanto pelos profissionais

responsáveis pelos dados, onde é ressaltada a figura do Administrador do Banco de

Dados e dos Analistas de Dados, como também pelos desenvolvedores de Aplicações.

DOMÍNIOS EM SQL

O Padrão SQL 3 aceita uma variedade de tipos de domínios embutidos, incluindo os

seguintes:

blob para armazenamento de grande quantidade de dados como áudio, vídeo,

gráficos, etc.



char(n) é uma cadeia de caracteres de tamanho fixo, com o tamanho n definido

pelo usuário. Reserva previamente o tamanho definido por n, mesmo que o dado

armazenado não preencha totalmente o campo.

varchar(n) é uma cadeia de caracteres com tamanho variável, sendo o tamanho

máximo definido pelo usuário. Armazena somente a quantidade de caracteres que

conter o dado, no máximo o valor de n.

integer é um inteiro. Para armazenamentos de números inteiros no intervalo de (-

2.147.483.648 até 2.147.483.648).

smallint é um inteiro pequeno. Para armazenamentos de números inteiros no

intervalo de (-32.768 até 32.767).

numeric(p,d) é um número de ponto fixo cuja precisão é definida pelo usuário. O

número consiste de p dígitos (mais o sinal), sendo que d dos p dígitos estão à direita

do ponto decimal. Assim, numeric(3,1) permite que 44,5 seja armazenado de modo

exato, mas 0,32 não pode ser armazenado corretamente em um campo desse tipo,

pois ele armazena 0,3. O maior número representado é 99,9.

double precision para armazenamento de números no intervalo de (1.7 x 10 -308 até

1.7 x 10308) com precisão de 15 dígitos.

float para armazenamento de números no intervalo de (3.4 x 10-38 até 3.4 x 1038)

com precisão de 7 dígitos.

date é um calendário contendo um ano (com quatro dígitos), mês e dia do mês.

time representa horário, em horas, minutos e segundos.

A SQL permite-nos definir domínios usando a cláusula create domain, como mostra o

exemplo:

Ex: create domain nome_pessoa char(20);



REGRAS E NOMENCLATURAS

Para criação de objetos do banco de dados, variáveis e quaisquer outros identificadores

devem ser observadas as seguintes regras:

Iniciar cada nome com caracteres alfabéticos (A-Z, a-z);

Restringir o tamanho dos nomes a 31 caracteres, incluindo sinal de cifrão ($), o

sublinhado (_), os dígitos 0-9 e os caracteres alfabéticos.

Não coloque acento e nem mesmo use ç (cedilha).

CONSTRAINTS (RESTRIÇÕES)

As constraints são declarações de “restrições” ou “bloqueios”, que se faz juntamente

(embutido) à definição dos objetos Table (tabela), e têm como fundamento à imposição

de alguma regra de validação aos dados que serão manipulados nesses objetos.

Constraint é uma especificação opcional, fornecida durante a fase de criação dos

objetos de dados de um banco de dados, que tem como objetivo aumentar o conjunto de

validações ou checagens que o banco de dados faz, quando seus usuários estiverem

manipulando (inserindo ou modificando) dados dentro do objeto de dados.

Deve-se ter em mente que para manipular dados durante a inclusão ou alteração essas

“validações” assumem a dianteira na questão da aceitação da operação, de forma que ela

tenha prosseguimento ou não. Caso não tenha aceitação o banco de dados interromperá

a operação e disparará um erro de violação de Constraint.

A finalidade das Constraints é garantir a integridade do banco de dados. Existem três

tipos de integridade:

Integridade de Entidade: Controla a inclusão de valores em uma tabela,

impedindo a redundância de informações. Na linguagem SQL este tipo de restrição

(constraint) é definido pela chave primária (PRIMARY KEY) e pelos índices.

Integridade de Domínio: Tem por objetivo impor regras de validação para os

dados inseridos nos campos de uma tabela. No SQL tais restrições são definidas por

instruções do tipo CHECK, DEFAULT.



Integridade Referencial: Consiste na definição de regras que garantam o perfeito

funcionamento dos relacionamentos entre as diversas tabelas que compõem o banco

de dados, implementada pelo SQL por intermédio da restrição FOREIGN KEY.

KEY CONSTRAINTS

Definem a criação de chaves e relacionamentos existentes entre tabelas. São eles:

PRIMARY KEY: Define que o valor da coluna em questão estará presente em um

índice, ocorrendo uma única vez nesse índice e necessitam serem definidos como

não nulos. Esta constraint se adequa perfeitamente ao conceito de chave

primária para uma tabela.

FOREIGN KEY: Define que o valor da coluna em questão obrigatoriamente estará

presente no índice da PRIMARY KEY da tabela que se refere. Uma ou mais colunas

que sofrem esta imposição podem admitir valores nulos.

A chave primária de uma tabela é um atributo do ente a que se refere à tabela, e serve

para permitir que se consiga chegar a um único ente dessa tabela, caso se conheça um

valor desse atributo.

A chave estrangeira é um atributo que mantém uma relação de continuidade de

descrição em outra tabela. Uma chave estrangeira nada mais é do que uma restrição

(Constraint) que se impõe a uma coluna, fazendo com que o banco de dados passe então

a checar automaticamente se valores manipulados nessa coluna existem na tabela que a

coluna referencia (aponta). Se a coluna recebe NULL, a checagem é válida, pois a

menos que se diga algo contrário, uma chave estrangeira admite NULL. Se a coluna

recebe algum valor, este obrigatoriamente tem que existir na tabela relacionada, pois, do

contrário, a restrição foi violada.

COLUMN CONSTRAINTS

Bloqueios (restrições) a valores operados em uma coluna. São eles:



NOT NULL impõe a obrigatoriedade de ocorrência de valor para a coluna. Na

tentativa de “anular” um valor da coluna ou de inserir uma linha com a indicação de

NULL para essa coluna, haverá uma violação a esta restrição.

Ex: código numeric(2) not null

CHECK valida o valor a ser admitido por uma coluna, contra uma regra

(expressão/equação). Verifica se o dado fornecido à coluna condiz com a expressão

que é apresentada para a constraint.

Ex: CHECK(value>10) somente admitiria valores maiores que 10.

UNIQUE impõe a coluna que seus valores (dados) não poderão ser repetidos.

Ex: cpf varchar(14) unique

DEFAULT Implica em fazer com que o banco de dados forneça um valor

declarado para uma coluna toda vez que inserir uma linha de dados que omita dado

para essa coluna, ou seja, se uma coluna UF contiver a declaração DEFAULT ‘MG’,

quando não se informar nada para ela, o banco de dados a preenche com ‘MG’.

Exemplos:

create domain uf as char(2) default 'MG' se dado omitido, a coluna é preenchida com

MG.

create domain x as numeric(2) default 99 se dado omitido, a coluna é preenchida

com 99.

create domain data date default ‘now’ se dado omitido, a coluna é preenchida com a

data atual.

A Column Constraint funciona assim, depois de definida a uma coluna, toda vez que

ocorrer uma inserção ou modificação de dados, a restrição será testada.

DRI CONSTRAINTS



Impõe ações que serão automaticamente desencadeadas em função da manutenção da

Integridade Referencial de Dados (DRI). São eles:

ON DELETE

Especifica os procedimentos que devem ser feitos pelo SGDB quando houver uma

exclusão de registro na tabela pai quando existe um registro correspondente nas tabelas

filhas. Opções:

o ON DELETE CASCADE impõe a exclusão, em cascata, de todas as Foreign

Keys que apontem para uma Primary Key que estiver sendo excluída. Determina

se uma exclusão feita na chave primária da tabela pai será replicada

automaticamente na tabela filha. No relacionamento cliente e cidade, a tabela

pai é cidade e a filha é cliente (onde está a chave estrangeira). Então ao usar esta

constraint se apagar uma cidade (Lavras) todos os clientes existentes nesta

cidade serão automaticamente apagados.

o ON DELETE SET NUL Então ao usar esta constraint se apagar uma cidade

(Lavras) todos os clientes existentes nesta cidade terá o código da cidade como

nulo. Observação: para isso é necessário que está chave estrangeira dentro da

tabela cidade possa receber valor nulo.

o ON DELETE SET DEFAULT Então ao usar esta constraint se apagar uma

cidade (Lavras) todos os clientes existentes nesta cidade terá o código da cidade

como o número que foi determinado pelo default. Observação: para isso é

necessário que o valor do default exista dentro da tabela cidade.

ON UPDATE

Especifica os procedimentos que devem ser feitos pelo SGDB quando houver uma

alteração da chave primária do registro na tabela pai quando existe um registro

correspondente nas tabelas filhas. Opções:

o ON UPDATE CASCADE Impõe uma alteração (de conteúdo), em cascata, a

todas as Foreign Keys que estiver sendo alterada. Determina se uma atualização



feita na chave primária da tabela pai será replicada automaticamente na tabela

filha. Então ao usar esta constraint será possível alterar a chave primária de uma

cidade (Lavras) todos os clientes existentes com o código dessa cidade serão

modificados automaticamente com o novo código.

o ON UPDATE SET NUL Então ao usar esta constraint se alterar o código de

uma cidade (Lavras) todos os clientes existentes nesta cidade terá o código da

cidade como nulo. Observação: para isso é necessário que está chave estrangeira

dentro da tabela cidade possa receber valor nulo.

o ON UPDATE SET DEFAULT Então ao usar esta constraint se alterar o

código de uma cidade (Lavras) todos os clientes existentes nesta cidade terá o

código da cidade como o valor determinado pelo default. Observação: para isso

é necessário que o valor do default exista dentro da tabela cidade.

EXEMPLO:

Todos comandos SQL terão seus exemplos baseados no MER apresentado abaixo:

Tabela Acessório

ACESSÓRIO TIPO TAMANHO OPÇÃO

CODACE N 5 OB

DESCACE V 30 OB

Tabela Cliente

CLIENTE TIPO TAMANHO OPÇÃO

CODCLI N 5 OB

NOMCLI V 30 OB

ENDCLI V 50 OB

FONECLI V 15 OP


CLIENTE ClienteN 1

Acessório VeiculoN N

veic/acess vendido


EMAILCLI V 30 OP

... ... ... ...

Tabela Veículo

VEÍCULO TIPO TAMANHO OPÇÃO

PLACAVEIC V 9 OB

CODCLI N 5 OP

NOMVEIC V 20 OB

MARCAVEIC V 20 OB

VALORVEIC valor OB

... ... ... ...

Tabela VeicAcess

VEICACESS TIPO TAMANHO OPÇÃO

CODACE N 5 OB

PLACAVEIC N 5 OB

... ... ... ...

Obs: : indica que o atributo é chave primária.

: indica que o atributo é chave estrangeira.

OBS: SERÃO VISTOS AGORA OS COMANDOS DA LINGUAGEM SQL

COMANDO CREATE

O comando CREATE da DLL permite criar um objeto do banco de dados.

CREATE <tipo_de_objeto> <definição_do_objeto>

CREATE DATABASE:

Cria um novo banco de dados.

create database ‘nome_do_database.gdb’ user usuário password senha;

Ex: create database ‘c:\bd.gdb’ user SYSDBA password masterkey



CREATE DOMAIN

Cria um domínio, ou seja, uma definição de um “novo tipo de dado”.

create domain nome_do_domain as [especificação_do_domain]

Exemplos:

create domain sexo as varchar(1) check(value=‘M’ or value=‘F’);

create domain x as integer not null check(value>=10);

create domain uf as char(2) default 'MG'

create domain valor as numeric(8,2) default 8000 (será usado na criação da tabela

veículo)

CREATE TABLE

Cria uma nova tabela com seus campos e define as restrições de campo.

create table nome_tabela (nome_do_campo_1 [tipo] [restrições] ,

nome_do_campo_n [tipo] [restrições])

Obs: A chave primária não pode ser nula, e se for chave composta, estas devem vir entre

( ) parênteses. Deve-se observar se a tabela a ser criada referencia alguma chave

estrangeira, caso ocorra referência, deve-se certificar que a tabela pai seja criada

primeiro.

Exemplos:

Tabela acessório

create table acessorio (codace numeric(5,0) not null,

descace varchar(30) not null unique,

primary key (codace));

Tabela cliente

create table cliente (codcli numeric(5,0) not null primary key,



nomcli varchar(30) not null,

endcli varchar(50) not null,

fonecli varchar(15),

emailcli varchar (30));

Tabela veiculo

create table veiculo (placaveic varchar(9) not null primary key,

nomveic varchar(20) not null,

marcaveic varchar(20) not null,

valorveic valor not null,

codcli numeric(5,0),

foreign key (codcli) references cliente(codcli));

Tabela veicacess

create table veicacess (codace numeric(5,0) not null,

placaveic varchar(9) not null,

primary key (codace, placaveic),

foreign key (codace) references acessorio(codace) on update

cascade,

foreign key (placaveic) references veiculo(placaveic) on update

cascade);

Observações:

Para o atributo valorveic foi utilizado o domínio acima.

Existe uma opção chamada computed by que guarda uma operação.

Ex: create table x ( ..., L1 integer, L2 integer, L3 computed by ( L1+L2), ...)

COMANDO ALTER

ALTER DOMAIN

Altera as definições de um domínio que já tenha sido criado. Pode-se alterar qualquer

elemento de domínio, exceto os domínio de NOT NULL e a troca do tipo de dado. Para

redefinir o tipo de domínio e/ou alterar o NOT NULL, deve apagar o domínio e criá-lo

novamente.



alter domain nome_do_domínio {[set default|drop default] [add check]}

Exemplos:

alter domain x set default 10 adiciona ao domínio o default de 10

alter domain x drop default apaga o default

alter domain valor add check(value>=8000)

ALTER TABLE

Altera as definições de campos e de restrições, ou seja altera a estrutura da tabela.

alter table nome_da_tabela

{ADD nome_do_campo [tipo] [restrições]}

{ALTER nome_do_campo TYPE [tipo] }

{ALTER nome_do_campo TO novo_nome_do_campo}

{DROP nome_do_campo}

Exemplos:

1) Adiciona um novo atributo a tabela referenciada.

alter table nome_da_tabela ADD nome_do_campo [tipo] [restrições]

Ex: alter table acessorio add preço numeric(3,2) not null;

2) Altera o tipo de um atributo da tabela referenciada.

alter table nome_da_tabela ALTER nome_do_campo TYPE [tipo]

Ex: alter table acessorio alter preço type integer;

3) Altera o nome de um atributo da tabela referenciada.

alter table nome_da_tabela ALTER nome_do_campo TO novo_nome_do_campo

Ex: alter table acessorio alter preço to preço_ace ;

4) Apaga um atributo da tabela referenciada.



alter table nome_da_tabela drop nome_do_campo

Ex: alter table acessorio drop preço_ace;

COMANDO DROP

DROP DATABASE

Apaga o banco de dados.

drop database

Ex: drop database No Interbase para apagar o bd este deve estar conectado.

DROP DOMAIN

Apaga o domínio. Se o domínio estiver sendo usado por alguma tabela, para solucionar

este problema, o campo tem que ser excluído e após isto apagar o domínio.

drop domain nome_do_domínio

EX: drop domain valor

DROP TABLE

Exclui uma tabela, ou seja, são perdidos os dados e a estrutura da tabela.

drop table nome_da_tabela.

Ex: drop table acessorio;

COMANDO DELETE

Remove um ou mais registros da tabela referenciada, ou seja, somente os dados são

excluídos, a estrutura da tabela permanece intacta.

delete from nome_da_tabela where critérios

Exemplos:



delete from veiculo where marcaveic=‘fiat’; Apaga todos os registros dos veículos da

marca Fiat.

delete from acessório; Apaga todos os registros da tabela acessório.

COMANDO INSERT

Adiciona registros a uma tabela. Os valores que forem omitidos recebem valores nulos

ou o valor do default.

OBS: os textos devem vir entre apóstrofes.

insert into nome_tabela_destino (nome_dos_campos) values (valores);

Exemplos:

insert into cliente values (1,‘João’,‘R. das Amoreiras’,null, ‘joã[email protected]’);

insert into cliente (codcli,nomcli,endcli) values (2,‘Pedro’, ‘R. das Amoreiras’);

insert into acessorio values (1,‘calota’);

insert into veiculo values (‘ggp-4040’,‘uno’,‘fiat’,14000,1)

insert into veicacess values (1, ‘ggp-4040’)

COMANDO UPDATE

Altera (atualiza) valores de campos em uma tabela, com base em critérios especificados.

Caso não seja usado nenhum critério, serão alterados todos os registros da tabela.

update nome_da_tabela set novo_valor where critérios

Exemplos:

update veiculo set valorveic=valorveic*1.3; Altera o valor de todos os veículos em

30%

update veiculo set valorveic=valorveic*1.3 where valorveic>=19000;

update cliente set endcli= ‘R. das Flores’ where endcli=‘R. das Aimoreiras’;

update veiculo set valorveic= ‘15000’ where nomveic <> ‘uno’

OBS: <> diferente, >= maior ou igual



COMANDO COMMIT

Torna permanente todas as alterações (como os comandos insert, delete e update) feitas

desde o início desta conexão.

Ex: commit;

COMANDO ROLLBACK

Descarta todas as alterações (como os comandos insert, delete e update) feitas desde o

início desta conexão, ou do último comando COMMIT.

Ex: Rollback

COMANDO SELECT

Procura na tabela ou tabelas especificadas, extrai as colunas escolhidas, seleciona as

linhas que atendem aos critérios e classifica ou agrupa as linhas resultantes na ordem

especificada. Ou seja, ele é responsável pelas consultas, obtenção de dados das tabelas.

select atributos from relação de tabelas where critérios

select t1.a1, t1.a2 ..., t2an from t1, t2 ..., tn where c1 and c2 or cn

Observações:

Então entre o SELECT e o FROM são colocados todos os atributos que se deseja

visualizar no final da consulta. Entre o FROM e o WHERE são colocadas todas as

relações das tabelas necessárias para execução da consulta. E depois do WHERE

são colocadas todas as condições que o select deve atender para mostrar o resultado

da consulta.

No Interbase o resultado do select é visualizado em um grid, como mostra a figura

abaixo:



CLÁUSULA SELECT

Será explicado o que vem antes da cláusula WHERE.

O DISTINCT

Se desejar forçar a eliminação de duplicidade em uma consulta, devemos inserir a

palavra-chave DISTINCT depois de select.

select marcaveic from veiculo; (mostra todas as marcas dos veículos, mas de forma

repetida).

select distinct marcaveic from veiculo; ( as duplicidades de marcas serão

eliminadas).

O ASTERISCO

O asterisco (*) pode ser usado para denotar “todos os atributos”. Se usado em

expressões aritméticas ele vira um operador de multiplicação.

select nomveic from veiculo; (mostra só o nome dos veículos existentes na tabela

veiculo)

select * from veiculo; (vai mostrar todos os atributos de veículo, nome,marca, etc)

AS

Renomeia o nome dos atributos que aparecerão no cabeçalho.



Ex: select nomcli as nome from cliente (no cabeçalho ao invés de nomcli aparecerá

nome).

CLÁUSULA WHERE

Na cláusula WHERE são colocadas as condições que devem ser obedecidas para

execução da consulta.

Podem ser usados os operados lógicos and (e), or (ou) e not (negação) entre as várias

condições encontradas na cláusula WHERE.

Considere o exemplo abaixo, onde queremos encontrar todos os veículos da marca Fiat

e com valor igual ou acima de 15000.52, mostrando apenas os campos nome do veículo

e seu valor.

select nomveic,valorveic from veiculo where marca=‘fiat’ and valor>=15000.52

O USO DE VÁRIAS TABELAS

No uso de várias tabelas no select se faz necessário, indicar de qual tabela o atributo faz

parte. Então é conveniente que se use do artifício de colocar apelidos na tabela. Pois

antes de cada atributo deve vir o nome da tabela.

Exemplos:

a) Sem usar apelidos:

select cliente.nomcli, veiculo.nomveic from cliente, veiculo where

cliente.codcli=veiculo.codcli;

Mostra os nomes dos clientes e seus respectivos carros

b) Usando apelidos:

select c.nomcli, v.nomveic from cliente c, Veiculo v where c.codcli=v.codcli;

Mostra os nomes dos clientes e seus respectivos carros

GROUP BY

Organiza os registros através do atributo indicado. Combina registros com valores

idênticos na lista de campos especificada em um único registro. GROUP BY é opcional.

Exemplos:



select nomcli from cliente group by nomcli

mostra todos os clientes ordenados pelos nomes, e omite os que têm nomes iguais

select nomveic from veiculo group by nomveic

mostra todos os veiculos ordenados pelos nomes, e omite os que têm nomes iguais.

ORDER BY

Classifica os registros resultantes de uma consulta em um campo ou campos

especificados, em ordem crescente ou decrescente. ORDER BY é opcional. A ordem de

classificação padrão é ascendente (de A a Z, de 0 a 9).

Ex: select * from Cliente order by nomcli desc;

mostra todos os clientes, com os nomes em ordem decrescente

OPERADORES

OPERADOR BETWEEN

A SQL possui o operador de comparação BETWEEN (entre), que especifica que um

valor esta entre os outros valores especificados.

Ex: select nomveic from veiculo where valorveic between 14000.52 and 18000.00

Mostra os veículos cujos valores estejam entre 14000.52 e 18000, inclusive os com

estes valores

OPERADOR IN

Determina se o valor de uma expressão é igual a algum dos vários valores de uma lista

especificada (conjunto). Se expressão for encontrada na lista de valores, o operador In

retornará True; caso contrário, retornará False. Você pode incluir o operador lógico Not

para avaliar a condição oposta (isto é, se a expressão não está na lista de valores).

Exemplos:

select * from cliente where nomcli in ('Maria','João','Marta')

mostra os todos os dados dos clientes com esses nomes, caso eles existam



select nomcli from cliente where codcli not in (select codcli from veiculo)

mostra os clientes que não possuem carro

select * from cliente where codcli in (select codcli from veiculo where marca='fiat')

mostra os clientes que possuem carro da marca Fiat

OPERADOR LIKE

As operações em strings mais usadas são as checagens para verificação de coincidências

de pares, usando o operador like.

Identificamos esses pares por meio de dois caracteres especiais:

Porcentagem (%) o caracter % compara qualquer substring.

Sublinhado(_) o caracter _ compara qualquer caracter.

Comparações desse tipo são sensíveis ao tamanho das letras; isto é, minúsculas não são

iguais a maiúsculas, e vice-versa.

Para ilustrar considere:

“Fi%” corresponde a qualquer string que comece com “Fi”.

“%mar%” corresponde a qualquer string que possua uma substring “mar”, por

exemplo, mar, maravilha, comarca, etc.

“%re” corresponde a qualquer string que termine com “re”

“_ _ _” corresponde a qualquer string com exatamente três caracteres;

“_ _ _%” corresponde a qualquer string com pelo menos três caracteres.

Exemplos:

select * from cliente where nomcli like ‘Re%’

seleciona todos os clientes cujos nomes iniciam com Re

select * from veiculo where nomveic not like ‘%a’

seleciona todos os veículos que não terminam com a letra a

select * from cliente where nomcli like ‘%Reis%’

seleciona todos os clientes que tenham em seu nome o sobrenome Reis



select * from veiculo where nomveic like ‘_ _ _ _’

seleciona todos os veiculos que tenham no seu nome exatamente 4 caracteres

OPERADOR IS NULL

Determina se o valor de uma expressão é nulo.

Você pode incluir o operador lógico Not para avaliar a condição oposta (isto é, se a

expressão não é nula).

Exemplos:

select * from veiculo where codcli is null

mostra os veículos cujo código do cliente é nulo,ou seja, os veículos que ainda não

foram vendidos

select * from cliente where fonecli is not null

mostra os clientes que possuem telefone

FUNÇÕES

FUNÇÃO AVG

Calcula a média aritmética de um conjunto de valores contido em um campo

especificado em uma consulta.

Ex: select avg(valorveic) from veiculo

FUNÇÃO MAX

Retorna o maior valor de um conjunto de valores contido em um campo especificado

em uma consulta.

Ex: select max(valorveic) from veiculo; mostra o valor mais caro de carro

FUNÇÃO MIN

Retorna o menor valor de um conjunto de valores contido em um campo especificado

em uma consulta.



EX: select min(valorveic) from veiculo; mostra o valor mais barato de carro

FUNÇÃO SUM

Retorna a soma de um conjunto de valores contido em um campo especificado em uma

consulta. A função Sum ignora os registros que contenham campos Null.

Ex: select sum(valorveic) from veiculo where marcaveic='fiat'; mostra o valor total

da soma dos carros as marca fiat.

FUNÇÃO COUNT

Calcula o número de registros retornado por uma consulta. A função count não conta registros que tenham campos Null, exceto quando for usado o asterisco (*). Separe o nome de campos por um e comercial (&).

Ex: select count(*) from veiculo where valor>13000 (conta quantos veículos tem valor maior que 13000)

select count('codcli & valor') from veiculo (conta quantos veículo tem o valor e o código do cliente não nulos)


apostila bancodados

Documents