Apostila BancoDados

CURSO TÉCNICO
ESCOLA ESTADUAL PROFESSOR JOSÉ MONTEIRO

Prefeitura Municipal de Campo Belo, Secretaria Municipal de Educação e
Secretaria Estadual de Educação de Minas Gerais
INFORMÁTICA
Banco de Dados I
Juliano Porto Alvarenga

julianoporto@bol.com.br
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.
Mini-Mundo Bancos de
Dados
Modelagem
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;
• 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.

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: Cod_cid e Cod_est são chaves primárias respectivamente das

Cidade Estado tabelas Cidade e Estado, enquanto Cod_est é chave
estrangeira na tabela de cidades. É precisamente por este
*Cod_cid *Cod_est campo (atributo, ou coluna), que será estabelecida a relação
Nome_cid Nome_est entre as tabelas Cidade-->Estado.
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.
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.
Clientes
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.
Cliente Cliente
CPF
CPF
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.
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.
matricul
Aluno Disciplina
ado
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:
Esposa
Casament
PESSOA o
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:
1 n
Departamento lotaç Empregado
ão
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.

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.
(0,N) inscriçã (1,1)

ALUNO CURSO
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.

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:
Código
PESSOA Nome
Endereço
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:
Número do
corredor
PRATELEIRA Número da
Prateleira
capacidade

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:
1 N
POSSU
EMPREGADO DEPENDENTES
I
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

1
1
é chefe de apenas um departamento.
DEPTO poss CHEFIA

ui
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.
envol ITENS DE
VENDA
VENDA
RELACIONAMENTO N: N: Cada Fornecedor vende vários produtos e cada produto

é fornecido por no máximo por vários fornecedores.
FORNECEDO N N
vende PRODUTO
R
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

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.
1 1
conté
PRODUTO ESTOQUE
m
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
Placa Valor
Chassi Data validade
Marca Codcarro(APONTADOR)
Exemplo de chave estrangeira na entidade Seguro

CHAVE ESTRANGEIRA SEGURO – CARRO
1 1
CARRO POSS SEGURO
UI
codcar codse
nome g
ro codcarr tipo
o
plac Data
a marca validade
valor
chassi
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
EMPREGADO1 DEPENDENTE N
CODEMP(CHAVE) CODDEP
POSS (CHAVE)
EMPREGADO DEPENDENTES
NOMEEMP UI
CODEMP (APONTADOR)
ENDEMP NOMEDEP
NºDEPENDENTE PARENTESCODEP
TELEMP IDADEDEP
... ...
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
FORNECEDO N fornec N
PRODUTO
R
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.
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
ORIGEM DO
FORNECEDOR fornece contem PRODUTO
PRODUTO
codfor codfor codpro codpro
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:
n n
consul
MÉDICO PACIENTE
ta
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.
n n
consul
MÉDICO PACIENTE
ta
n
prescriç
ão
n
MEDICAMENT
O
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.
MÉDICO PACIENTE
1 1
n n
n n MEDICAMENT
Prescriç
CONSULTA ão 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
atributos nome, código, CGC e tipo de organização, é identificada pelo código e está
obrigatoriamente relacionada a exatamente uma filial.

(1,1) (0,n) Código

FILIAL CLIENTE
Nome
PESSOA PESSOA
FÍSICA JURÍDICA
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
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.
Tipo de funcionário

FUNCIONÁRIO
MOTORISTA SECRETÁRIA
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
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 ATRIBUTO DESCRIÇÃO TIPO TAMANHO OPÇÃO DOMÍNIO

FORNECEDOR
Codfor* Código do Numérico 03 OB >0
Fornecedor
Nf Nome Fantasia Caracter 50 OB
Rs Razão Social Caracter 50 OB
Dtcad Data de date OB > 01/01/00
cadastro
IE Inscrição Numérico 12 OP
Estadual
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 tem Funcionário

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
Comp
õe Cód. Nome Etc. Códch
4534 Correia ...
1 N 6547 Parafuso ...
7734 Freio ... 6547
1198 Carburador ... 6547
Peça

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).
1 1
CARRO possui SEGURO
CARRO SEGURO
PLACA NOME Etc. Apólice Tipo Etc. PLACA
(CHAVE)
GPP-1212 GOL ... 4534 Total ... GPP-1212
GHH-1515 PALIO ... 6547 Parcial ... GHH-1515
DLL-1818 VECTR ... 7734 Total ... DLL-1818
A
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.
Casada
com
1 1
Pessoa
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.
N N
Alocad
Funcionário o
Projeto
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
Pré-
Requi Disciplina Pré-Requisito
si-to
Cód. Nome Cód. CPré
N N Disciplina Disciplina
666 Química I 123 888
123 Cálculo III 491 324
Disciplina 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.
1: N
Funcionário
1
Departa- 1 Te Mat. Nome
Funcioná- Funçã CDEP
mento m rio o
4534 Soraia Matos Eng SFT
6547 Breno Vem ADP
Medeiros
7734 Gustavo Ven COB-2
Borges
1198 Ana Ferreira Sec SFT
3289 Telma Ribeiro Ven ADP
Departamento
Cod Nome do Departamento
SFT ANÁLISE
COB-2 PROGRAMAÇÃO
APD DIRETORIA SISTEMAS
Engenheiro Vendedor Secretária
Matric. Matric. Matric.

Ajuda de Custo Hora extra Ling. Estran.
Especialidade Desp. Extra Curso
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 PRIMEIRA
FORMA 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 SEGUNDA
FORMA 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 TERCEIRA
FORMA 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 ...)

• DATE
DATE armazena a Data, e seu tamanho é de 32 bits inteiros longos.
Ex : CREATE TABLE … (… DATA_ADMISSAO DATE)
• TIME
TIME armazena a hora, e seu tamanho é de 32 bits inteiros longos.
Ex : CREATE TABLE … (… HORA_ENTRADA TIME, HORA_SAIDA
TIME)
• TIMESTAMP
O 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 NUMERIC
DECIMAL 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) ...)
• SMALLINT
Ex : CREATE TABLE … (… ALTURA SMALLINT ...)
• INTEGER
Ex : CREATE TABLE … (… ID INTEGER NOT NULL PRIMARY KEY )
• FLOAT
Ex : CREATE TABLE … (… VLR_ULT_CMP_ITEM FLOAT ...)
• DOUBLE PRECISION
Este é 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:
N N N 1
Acessório veic/acess Veiculo
CLIENTE Cliente
vendido
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

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
PLACAVEI N 5 OB
C
... ... ... ...
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ão@vvv.com.br’);
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

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila BancoDados

Transféré par

Droits d'auteur :

Formats disponibles

CURSO TÉCNICO

ESCOLA ESTADUAL PROFESSOR JOSÉ MONTEIRO

Juliano Porto Alvarenga

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

Disciplina: Banco de Dados 1

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

Disciplina: Banco de Dados 2

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

Disciplina: Banco de Dados 3

MODELO ENTIDADE-RELACIONAMENTO (MER)

Disciplina: Banco de Dados 4

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

MODELO ORIENTADO A OBJETO

Disciplina: Banco de Dados 5

MODELOS LÓGICOS BASEADOS EM REGISTRO

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

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

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

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

Disciplina: Banco de Dados 6

Exemplo: Cod_cid e Cod_est são chaves primárias respectivamente das

MODELOS FÍSICOS DE DADOS

Disciplina: Banco de Dados 7

MODELO ENTIDADE-RELACIONAMENTO (MER)

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

Disciplina: Banco de Dados 8

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

DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)

O modelo de entidade-relacionamento consiste nas seguintes etapas:

Disciplina: Banco de Dados 9

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

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

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

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

Disciplina: Banco de Dados 10

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

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

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

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

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

Disciplina: Banco de Dados 12

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

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

(0,N) inscriçã (1,1)

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

Disciplina: Banco de Dados 13

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

Disciplina: Banco de Dados 14

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

CLASSIFICAÇÃO DE RELACIONAMENTOS BINÁRIOS

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

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

Disciplina: Banco de Dados 15

é chefe de apenas um departamento.

DEPTO poss CHEFIA

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

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

Disciplina: Banco de Dados 16

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

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

Disciplina: Banco de Dados 17

CHAVE ESTRANGEIRA SEGURO – CARRO

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