1

FACULDADE ANHANGUERA DE PORTO ALEGRE

TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

Jair Pereira RA:7581609868

Rodrigo da Silva Bueno RA: 7581610567
Luciano Fagundes RA: 6789414136
Andre Fagundes RA: 6576310339

ATPS SISTEMAS DE BANCO DE DADOS

RELATORIO FINAL

Tutor: Rosi Piber

PORTO ALEGRE RIO GRANDE DO SUL

22/04/2014

Jair Pereira RA:7581609868

Rodrigo da Silva Bueno RA: 7581610567
Luciano Fagundes RA: 6789414136
Andre Fagundes RA: 6576310339

ATPS SISTEMAS DE BANCO DE DADOS

Relatrio Final dos processos utilizados para resoluo

dos problemas propostos da Atividade Praticas
Supervisionadas da cadeira Sistemas de Banco de
Dados.
Orientador: Rosi Piber

PORTO ALEGRE RIO GRANDE DO SUL

22/04/2014

SUMRIO
1

INTRODUCAO..................................................................................................................4
1.1

Problema.......................................................................................................................4

1.2

Objetivos......................................................................................................................4

1.2.1
1.3
2

Geral......................................................................................................................4

Metodologia.................................................................................................................4

DESENVOLVIMENTO.....................................................................................................4
2.1

A Escolha do Tipo de Banco de Dados........................................................................4

2.1.1
2.2

Comparativo SGBD x Arquivos...........................................................................4

Modelo de Dados.........................................................................................................6

2.2.1

Conceito................................................................................................................6

2.2.2

Modelos de Dados mais Utilizados.......................................................................6

2.3

Escolha do Modelo Final..............................................................................................8

2.3.2

DER Diagrama Entidade Relacionamento.......................................................12

2.3.3

Normalizao de Dados......................................................................................15

2.3.4

Algebra Relacional..............................................................................................18

CONCLUSO..................................................................................................................22

BIBLIOGRAFIA..............................................................................................................23

ANEXO.............................................................................................................................24

INTRODUCAO

1.1

Problema
A empresa LFLXZ Ltda. est informatizando a parte de controle de seu
estacionamento. Diante disso est contratando sua equipe como uma consultoria que
desenvolver um Modelo de Dados de forma a organizar todas as informaes em um
SGBD (Sistema Gerenciador de Banco de Dados). A modelagem de dados dever ser
realizada a partir da entidade Estacionamento, gerada a partir do levantamento de
dados elaborado e com vistas a atender a demanda do cliente

1.2

Objetivos

1.2.1

Geral
Elaborar um modelo de dados para o sistema de informao para controle de um
estacionamento.

1.3

Metodologia
Utilizar as leituras obrigatrias e vivencias do grupo.

DESENVOLVIMENTO

2.1
2.1.1

A Escolha do Tipo de Banco de Dados

Comparativo SGBD x Arquivos

2.1.1.1 Sistemas de Gerenciamento de Arquivos

A implantao e interao com o sistema no fcil, no possvel saber quem
chave estrangeira, e quem chave primaria, qualquer dano ao banco de dados, todos
os programas so afetados virtualmente e todos os usurios podem usa-lo como
documentao.

No processamento tradicional de arquivos, o programa que ir manipular os dados

deve conter este tipo de informao, ficando limitado a manipular as informaes que
o mesmo conhece. A estrutura dos dados est incorporada
ao programa de acesso e desta forma, qualquer alterao na estrutura de arquivos
implica na alterao no cdigo fonte de todos os programas
2.1.1.2 SGBD Sistema Gerenciador de Banco de Dados
O SGBD mantm no somente os dados mas tambm a forma como os mesmos so
armazenados, contendo uma descrio completa do banco de dados. Estas informaes
so armazenadas no catlogo do SGBD, o qual contm informaes como a estrutura
de cada arquivo, o tipo e o formato de armazenamento de cada tipo de dado, restries,
etc. A informao armazenada no catlogo chamada de Meta Dados , integrao
com o sistema mais fcil, e as alteraes so mais claras.
Quadro 1 Prs e Contras de Cada Tipo de Banco de Dados

Tipo

Arquivo

SGBD

Prs
- Exclusividade sobre
a arquitetura
- No h custo com
licena, somente
custo de
desenvolvimento

-Aplicaes mais
genricas;
-Controle de
redundncia de
dados;
-Independncia de
dados e aplicativos;
-Mais segurana;
-O controle e a
manuteno integral
dos dados so feitos
pelo SGBD;
-O controle de
concorrncia feito
pelo SGBD.

Contras
-Banco de Dados
-Aplicaes especficas;
-Redundncia de dados;
-Dependncia entre dados e
aplicativos;
-Menos segurana;
-A integridade deve ser mantida em
cada programa;
-O controle de concorrncia deve ser
feito pelos programas.
- Exige capacidade tcnica apurada
dependendo do fornecedor da
soluo (ex: Oracle).
- Custo elevado para alguns tipos de
fornecedor

2.2

Modelo de Dados

2.2.1

Conceito
Modelar significa criar um modelo que explique as caractersticas de funcionamento e
comportamento de um software a partir do qual ele ser criado, facilitando seu
entendimento e seu projeto, atravs das caractersticas principais que evitaro erros de
programao, projeto e funcionamento. uma parte importante do desenho de um
sistema de informao.
A modelagem de dados a primeira etapa de um projeto que envolva banco de dados e
tem como seu principal objetivo o desenvolvimento de um modelo que contenha
entidades e relacionamentos, e que com isso seja possvel representas as
especificaes das informaes do negcio (OLIVEIRA,2002).A modelagem de dados
ajuda a organizar a forma de pensamento sobre os dados, demonstrando o significado.
A abordagem que se dispensa ao assunto normalmente atende trs perspectivas:
Modelagem Conceitual, Modelagem Lgica e Modelagem Fsica. A primeira e
conhecida e usada como representao de alto nvel e considera exclusivamente o
ponto de vista do usurio criador do dado, a segunda j agrega alguns detalhes de
implementao e a terceira demonstra como os dados so fisicamente armazenados.
Um modelo de dados a coleo de, pelo menos, 3 componentes:
1) Um conjunto de tipos de estruturas de dados
Define o tipo de dados e como se inter-relacionam
2) Um conjunto de operadores
Operaes que permitem manipular as estruturas de dados
definidas.
3) Um conjunto de regras de integridade
Regras que definem que dados so vlidos

2.2.2

Modelos de Dados mais Utilizados

2.2.2.1 Modelo Relacional

O Modelo Relacional foi introduzido por Edgar Frank Codd (1970) e tornou-se um
padro para aplicaes comerciais, devido a sua simplicidade e desempenho. um
modelo formal, bastante representativo e ao mesmo tempo bastante simples, foi o
primeiro modelo de dados descrito teoricamente.

Revelou-se ser o mais flexvel e adequado ao solucionar os vrios problemas que se

colocam no nvel da concepo e implementao da base de dados. A estrutura
fundamental do modelo relacional a relao (tabela). Uma relao constituda por um
ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instncia do
esquema (linha) chamada de tupla (registro).
Ex Software: MYSQL
2.2.2.2 Modelo Orientado a Objeto
A motivao para seu surgimento est em funo dos limites de armazenamento e
representao semntica impostas no modelo relacional. Antevia-se que tais sistemas
ofereceriam o ferramental necessrio para as novas categorias de aplicaes que no
estavam sendo adequadamente suportadas por bases de dados relacionais. Um aspecto
chave em programao orientada a objetos o conceito de abstrao, que permite
abstrair (nesta denio) substncia como declaraes de classes; valores e
propriedades mensurveis como declaraes de tipos; e aes como declaraes de
mtodos ou procedimentos. Um objeto encapsula uma estrutura que s manipulvel
atravs de mtodos componentes de uma interface pblica.
Ex Software: DB4O
DB4O, um poderoso SGBDOO para manipulao de objetos como base de dados,
fcil maneira de se armazenar objetos nativamente em JAVA ou.NET(Prxima Release
da suporte a PHP), possui uma performance ate 40X maior que qualquer banco de
dados relacional, processa aproximadamente 200.000 objetos por segundo, seu cdigo
aberto e seu custo muito baixo(praticamente zero).

2.2.2.3 Modelo Hierrquico

Uma base de dados hierrquica um tipo de sistema de gerenciamento de banco de
dados que conecta registos numa estrutura de dados em rvore atravs de ligaes de
tal modo que cada tipo de registo tenha apenas um possuidor. A base de dados se
baseia em um Modelo de Entidades e Relacionamentos: cada registro uma coleo

de atributos (campos), cada um dos quais contendo somente uma informao; uma
ligao a associao entre dois registros. Por exemplo: em uma dada base de dados
comercial, uma encomenda (i.e. registro) possuda por um nico cliente.
Ex Software: IMS
2.3

Escolha do Modelo Final

2.3.1.1 Justificativa
Para os dados a serem processados n SGBD vamos utilizar o modelo relacional pela
sua simplicidade de implantao e alto grau de compatibilidade com os maiores
softwares de SGBD do mercado.
Figura 1 Exemplo Modelo Relacional

2.3.1.2 Esquema do Banco de Dados

2.3.1.2.1 Tabela Estacionamento
Quadro 2 Esquema Tabela Estacionamento
Tabela:Estacionamento
Campo

Descrio

Tipo

Tamanho Restrio

Comentrios

pk id_estacionamento Nmero de cadastro do

interger cliente no estacionamento

Not null

Sequencial

fk

id_cliente

Nmero de cadastro do
cliente

interger -

Not null

Nmero do cadastro na tabela

Cliente

pk placa_veiculo

Nmero da placa do
veculo do cliente

varchar 7

Not null

Composto por 3 letras e 4

nmeros (AAA9999)

pk nro_vaga

Nmero do cadastro da
vaga

interger -

Not null

Nmero do cadastro na tabela

Vaga

Status da vaga no
varchar 3
estacionamento do cliente

Not null

Default:LBD(Liberada), outros
valores:OCP(Ocupada)
RES(Reservada)

status

PND(Pendente)

2.3.1.2.2 Tabela Vaga

Quadro 3 Esquema Tabela Vaga
Tabela:Vaga
Campo

Descrio

Tipo

Tamanho Restrio

Comentrios

pk nro_vaga

Nmero do cadastro da
vaga no banco de dados

interger

Not null

Sequencial

locl_vaga

Localizao da vaga no
estacionamento

varchar

250

Not null

Local onde est localizada a

vaga no mapa do
estacionamento. Ex.: Lote
A1...

fk

sigla_vaga

Descrio da sigla da vaga varchar

Not null

Apenas MEN(Mensalista)
ROT(Rotativa)

fk

status_vaga

Sigla do status da vaga no varchar

estacionamento

Not null

Sigla cadastrada na tabela

Status

2.3.1.2.3 Tabela Cliente

Quadro 4 Esquema Tabela Cliente
Tabela:Cliente
Campo
pk id_cliente

pk

pk

Descrio

Tipo

Tamanho Restrio

Comentrios

Nmero de cadastro do
interger cliente no banco de dados

Not null

Sequencial

nome_cliente

Nome completo do cliente varchar

250

Not null

cpf_cliente

Nmero do CPF do
cliente

varchar

12

Not null

Formatado com a mscara

999999999-99

telefone_coml

Nmero do telefone
comercial do cliente

interger 11

Not null

Composto pelo DDD e

nmero do telefone

telefone_resl

Nmero do telefone
residencial do cliente

interger 11

Not null

Composto pelo DDD e

nmero do telefone

telefone_celr

Nmero do telefone
celular do cliente

interger 11

Not null

Composto pelo DDD e

nmero do telefone

email

Endereo de e-mail do
cliente

varchar

200

null

Dever conter o smbolo @

placa_veiculo

Nmero da placa do
veculo do cliente

varchar

Not null

Composto por 3 letras e 4

nmeros (AAA9999)

modelo_veiculo Descrio do modelo do

veculo

varchar

40

null

cor_veiculo

Descrio da cor do
veculo

varchar

40

null

tipo_veiculo

Descrio do tipo do
veculo

varchar

40

null

ano_veiculo

Ano de fabricao do

year

null

Apenas o ano com 4

10

veculo

caracteres(YYYY)

2.3.1.2.4 Tabela Tipo Vaga

Quadro 5 Esquema Tabela Tipo Vaga
Tabela:Tipo_Vaga
Campo

Descrio

Tipo

Tamanho Restrio

Comentrios

pk nro_vaga

Nmero do cadastro da
vaga na tabela vaga

interger

Not null

Nmero do cadastro da vaga

feito na tabela vaga

pk tipo_vaga

Descrio completa do
tipo de vaga

varchar

50

Not null

Ex.: Mensalista, Rotativa

valor_vaga

Descrio da sigla do
status

float

10

Not null

sigla_vaga

Descrio da sigla da vaga varchar

Not null

Apenas MEN(Mensalista)
ROT(Rotativa)

2.3.1.2.5 Tabela Status

Quadro 6 Esquema Tabela Status
Tabela:Status
Campo
pk id_status
desc_status

pk sigla_status

Descrio

Tipo

Tamanho Restrio

Comentrios

Nmero do cadastro do
status no banco de dados

interger

Not null

Sequencial

Descrio completa do
status

varchar

50

Not null

Ex.: Liberada,
Pendente,Reservada,
Ocupada

Descrio da sigla do
status

varchar

Not null

Default:LBD(Liberada),
outros
valores:OCP(Ocupada)
RES(Reservada)
PND(Pendente)

2.3.1.3 Instancia do Banco de Dados

2.3.1.3.1 Tabela Estacionamento
Quadro 7 Instncia Tabela Estacionamento

id_estacionament
o
1
2
3

id_client
placa_veiculo
e
IIU6292
3
IKP6060
2
KPQ1616
1

nro_vaga

status

10
11
12

LBD
OCP
PND

11

2.3.1.3.2 Tabela Cliente

Quadro 8 Instncia Tabela Cliente

id_cl
iente

nom
e_cli
ente

cpf_cl
iente

telefo
ne_co
ml

telefo
ne_re
sl

telefon
e_celr

Fulan
o

12345
67891
0

51323
03030

5132
3030
30

659987
4561

Cicla
no

51325
40889

Beltr
ano

5132
5408
89
6132
5544
78

619874
5612

98765
43124
1
12378
94567
8

61325
54478

518456
1237

email
teste
@test
e.com
.
teste1
@test
e.com
teste3
@test
e.com

placa
_veic
ulo

model
o_veic
ulo

cor_
veic
ulo

tipo_ve
iculo

ano_vei
culo

IIU62
92

Corsa

Azul

Passeio

1998

IKP6
060

Celta

Cinz
a

Passeio

2012

KPQ1
616

Ford
Ka

Verm
elho

Passeio

2003

2.3.1.3.3 Tabela Vaga

Quadro 9 Instncia Tabela Vaga

nro_vaga
10
11
12

locl_vag
a
LOTE
A1
LOTE
A2
LOTE
A3

sigla_vaga

status_vaga

MEN

ROT
ROT

2.3.1.3.4 Tabela Tipo Vaga

Quadro 10 Instncia Tabela Tipo Vaga

nro_vaga

tipo_vaga valor_vaga sigla_vaga

10 Mensalista
300 MEN
11 Rotativa
5 ROT
12 Rotativa
5 ROT

2.3.1.3.5 Tabela Status

Quadro 11 Instncia Tabela Status

3
1

12

id_status

desc_status
1 Pendente
2 Liberada
3 Ocupada

2.3.2

sigla_status
PND
LBD
OCP

DER Diagrama Entidade Relacionamento

2.3.2.1 Conceito de Cardinalidade

um dos princpios fundamentais sobre o relacionamento de um banco de dados
relacional. Nela so definidos os graus de relao entre duas entidades ou tabelas. O
relacionamento vrios-para-vrios (N:N) entre os registros da tabela doutor e os
registro da tabela paciente, pois vrios mdicos podero atender vrios pacientes, um
mdico atende diversos paciente, assim como um paciente pode ser atendido por
diversos mdicos;
O relacionamento um-para-vrios (1:N) no relacionamento entre a tabela
departamento em relao a tabela de mdicos, pois um doutor, poder trabalhar em
somente um departamento do hospital, contudo, um departamento poder ter vrios
doutores.
O relacionamento um-para-um (1:1) ser usado nos casos onde o registro de uma
tabela s poder ter uma associao com um registro de outra tabela. No nosso caso,
isso caberia na relao entre um quarto de apartamento e um paciente. Pois um
paciente s poder estar em um determinado apartamento, e cada apartamento s
poder abrigar um determinado paciente (partindo do princpio de quartos
individuais).
O relacionamento zero-para-vrios (0:N) ser usado nos casos onde o registro de uma
tabela no precisa ter uma associao com um registro de outra tabela. No nosso caso,
isso caberia na relao entre um quarto de apartamento e uma televiso. Pois o quarto
poder no ter nenhuma televiso, e a televiso pode estar em vrios quartos.

13

2.3.2.2 Demonstrao Grfica do Modelo (DER)

Figura 1 Modelo DER

2.3.2.3 Cardinalidade para o Modelo (DER)

1. Entidade Cliente: o relacionamento dos dados da tabela cliente ser com a
entidade estacionamento, um-para-vrios(1:N), ou seja um cliente pode ter
mais de um estacionamento cadastrado para si mesmo.
2. Entidade

estacionamento:

relacionamento

dos

dados

da

tabela

estacionamento ser com as entidades cliente, vaga e status, onde o

relacionamento com cliente ser um-para-um (1:1), ou seja um

14

estacionamento pode estar somente cadastrado para um cliente. O

relacionamento com a vaga ser um-para-um (1:1), ou seja um estacionamento
pode estar somente cadastrado com uma vaga. O relacionamento com status
ser um-para-um (1:1), ou seja um estacionamento s pode ter um status
cadastrado para si mesmo.
3. Entidade vaga: o relacionamento dos dados da tabela vaga ser com as
entidades estacionamento, tipo_vaga e status, onde o relacionamento
com estacionamento ser zero-para-vrios(0:N), ou seja uma vaga pode estar
cadastrado em um ou nenhum estacionamento. O relacionamento com
tipo_vaga ser um-para-um(1:), ou seja uma vaga s pode ter um tipo de
vaga cadastrado para si mesma. O relacionamento com status ser um-paraum(1:1), ou seja uma vaga s pode ter um status cadastrado para si mesma.
4. Entidade tipo_vaga: o relacionamento dos dados da tabela tipo_vaga ser
com a entidade vaga, onde o relacionamento com vaga ser zero-paravrios(0:N), ou seja um tipo de vaga pode estar cadastrado em uma ou
nenhuma vaga.
5. Entidade status: o relacionamento dos dados da tabela status ser com as
entidades

estacionamento

vaga,

onde

relacionamento

com

estacionamento ser zero-para-vrios(0:N), ou seja um status pode estar

cadastrado em um ou nenhum estacionamento. O relacionamento com vaga
ser zero-para-vrios(0:N), ou seja um status pode estar cadastrado em uma ou
nenhuma vaga.

15

2.3.2.4 Demonstrao em MySql do (DER)

Figura 2 Modelo DER (MYSQL)

2.3.3

Normalizao de Dados

2.3.3.1 Conceito de Normalizao

uma srie de passos que se seguem no projeto de um banco de dados, que permitem
um armazenamento consistente e um eficiente acesso aos dados em bancos de dados
relacionais. Esses passos reduzem a redundncia de dados e as chances dos dados se
tornarem inconsistentes. No entanto, muitos SGBDs relacionais no tm separao
suficiente entre o projeto lgico da base de dados e a implantao fsica do banco de

16

dados, e isso tem como consequncia que as consultas feitas a um banco de dados
totalmente normalizado tm um mau desempenho. Nestes casos, usa-se por vezes a
desnormalizao para melhorar o desempenho, com o custo de menores garantias de
consistncia.

Os tipos de normalizao de dados so:

Primeira Forma Normal(1FN)

Segunda Forma Normal(2FN)

Terceira Forma Normal(3FN)

Quarta Forma Normal(4FN)

Forma Normal de Boyce-Codd (BCNF)

Quinta Forma Normal (5FNou PJ/NF)

Domain-Key Normal Form(DK/NF)

2.3.3.2 Normalizao (1FN) - Primeiro Forma de Normalizao

Uma tabela est na 1FN, se e somente se, no possuir atributos multivalorados.
Possveis problemas que a forma apresenta so redundncia e anomalias de
atualizao.
Quadro 12 (1FN)
cliente

-id_cliente
-id_estacionamento
-nome_cliente
-cpf_cliente
-telefone_coml
-telefone_resl
-telefone_celr
-email
-placa_veiculo
-modelo_veiculo
-cor_veiculo
-tipo_veiculo
-ano_veiculo

estacionamento

-id_estacionamento
-id_cliente
-placa_veiculo
-modelo_veiculo
-cor_veiculo
-tipo_veiculo
-ano_veiculo

17

-nro_vaga
-sigla_vaga
-status

2.3.3.3 Normalizao (2FN) - Segunda Forma de Normalizao

Uma relao est na 2FN se, e somente se, estiver na 1FN e cada atributo no chave
for dependente da chave primria inteira, isto , cada atributo no-chave no poder
ser dependente de apenas parte da chave. Maior independncia de dados,
Redundncias e anomalias: dependncias funcionais indiretas.
Quadro 13 (2FN)
estacionamento

-id_estacionamento
-id_cliente
-placa_veiculo
-modelo_veiculo
-cor_veiculo
-tipo_veiculo
-ano_veiculo
-nro_vaga
-sigla_vaga
-status

vaga

-nro_vaga
-locl_vaga
-sigla_vaga
-status_vaga

2.3.3.4 Normalizao (3FN) - Segunda Forma de Normalizao

Uma relao R est na 3FN, se estiver na 2FN e cada atributo no-chave de R no
possuir dependncia transitiva, para cada chave candidata de R. Maior independncia
de dados;3FN gera representaes lgicas finais na maioria das vezes;
Redundncias e anomalias: dependncias funcionais multivaloradas.
Quadro 14 (3FN)

18

2.3.4

cliente

-id_cliente
-nome_cliente
-cpf_cliente
-telefone_coml
-telefone_resl
-telefone_celr
-email
-placa_veiculo
-modelo_veiculo
-cor_veiculo
-tipo_veiculo
-ano_veiculo

estacionamento

-id_estacionamento
-id_cliente
-placa_veiculo
-nro_vaga
-sigla_vaga
-status

vaga

-nro_vaga
-locl_vaga
-sigla_vaga
-status

tipo_vaga

-nro_vaga
-tipo_vaga
-valor_vaga
-sigla_vaga

status

-id_status
-desc_status
-sigla_status

Algebra Relacional

2.3.4.1 Conceito de Algebra Relacional

uma linguagem de consulta formal, porm procedimental, ou seja, o usurio d as
instrues ao sistema para que o mesmo realize uma sequncia de operaes na base
de dados para calcular o resultado desejado.
A lgebra Relacional define operadores para atuar nas tabelas (semelhante aos
operadores +, -, etc. da lgebra que estamos acostumados) para chegar ao resultado
desejado.
A forma de trabalho desta linguagem de consulta a de pegar uma ou mais tabelas
(conforme necessidade) como entrada de dados e produzir uma nova tabela como
resultado das operaes.
2.3.4.2 Descrio das Operaes
2.3.4.2.1 Seleo

19

uma operao que para um conjunto inicial fornecido como argumento, produz um
subconjunto estruturalmente idntico, mas apenas com os elementos do conjunto
original que atendem a uma determinada condio (chamada de predicado). A seleo
pode ser entendida como uma operao que filtra as linhas de uma relao(tabela), e
uma operao unria, pois opera sobre um nico conjunto de dados.
Resultado subconjunto horizontal de uma relao
Operadores de comparao : =, <, <=, >, >=,
Operadores lgicos: ^ (and) V (or) (not)

2.3.4.2.2 Projeo
Produz um conjunto onde h um elemento para cada elemento do conjunto de entrada,
sendo que a estrutura dos membros do conjunto resultante definida nos argumentos
da operao. Pode ser entendida como uma operao que filtra as colunas de uma
tabela. Por operar sobre apenas um conjunto de entrada classificada como uma
operao unria.
2.3.4.2.3 Unio
Produz como resultado uma Relao que contm todas as linhas da primeira Relao
seguidas de todas as linhas da segunda tabela. A Relao resultante possui a mesma
quantidade de colunas que as relaes originais, e tem um nmero de linhas que no
mximo igual soma das linhas das relaes fornecidas como operandos, j que as
linhas que so comuns a ambas as relaes aparecem uma nica vez no resultado.
Obs: As relaes devem possuir o mesmo nmero de atributos.

2.3.4.2.4 Interseco
Esta uma operao adicional que produz como resultado uma tabela que contm,
sem repeties, todos os elementos que so comuns s duas tabelas fornecidas como
operandos. As tabelas devem ser unio-compatveis.
2.3.4.2.5 Diviso

20

Diviso uma operao da lgebra relacional utilizada quando se deseja extrair de

uma relao R1 uma determinada parte que possui as caractersticas (valores de
atributos) da relao R2.

2.3.4.2.6 Diferena
uma operao que requer como operandos duas relaes unio-compatveis, ou seja,
estruturalmente idnticas. O resultado uma relao que possui todas as linhas que
existem na primeira relao e no existem na segunda.
2.3.4.2.7 Juno
O resultado da operao juno natural uma relao com todas as combinaes das
tuplas na relao1 (R1) e relao2 (R2) nas quais os seus atributos em comum so
iguais.
uma operao que produz uma combinao entre as linhas de uma relao com as
linhas correspondentes de outra relao, sendo em princpio correspondente a uma
seleo pelos atributos de relacionamento sobre um produto cartesiano dessas
relaes:
A operao de juno foi criada porque esse tipo de combinao de tabelas muito
comum, facilitando com isso a escrita de expresses. A tabela resultante de uma
juno tem todas as colunas da primeira tabela e todas da segunda tabela.
2.3.4.3 Exemplos Prticos de Acordo com Problema Proposto
2.3.4.3.1 Seleo
Comando select * from estacionamento where id_cliente = 3.
Figura 3 Exemplo consulta Seleo

2.3.4.3.2 Projeo

21

Comando select nome_cliente, cpf_cliente, placa_veiculo from cliente where cor_veiculo =

'Vermelho'
Figura 4 Exemplo consulta Projeo

2.3.4.3.3 Unio
Comando

select

cli.nome_cliente,

es.placa_veiculo,

vg.locl_vaga

from

estacionamento as es inner join cliente as cli on cli.id_cliente = es.id_cliente

inner join vaga as vg on vg.nro_vaga = es.nro_vaga
Figura 5 Exemplo consulta Uniao

2.3.4.3.4 Interseco
Comando select vg.nro_vaga, vg.status_vaga, es.placa_veiculo from estacionamento
as es inner join vaga as vg on vg.status_vaga = es.`status`
Figura 6 Exemplo consulta Interseo

22

2.3.4.3.5 Diviso
Comando select es.id_cliente, es.placa_veiculo from estacionamento as es
inner join cliente as cli on es.placa_veiculo = cli.placa_veiculo
Figura 7 Exemplo consulta Diviso

2.3.4.3.6 Diferena
Comando select cli.nome_cliente, cli.placa_veiculo, es.nro_vaga from cliente as cli
inner join estacionamento as es on es.id_cliente = cli.id_cliente
Figura 8 Exemplo consulta Diferena

2.3.4.3.7 Juno
Comando select es.placa_veiculo, vg.sigla_vaga from estacionamento as es
left join vaga as vg on vg.status_vaga = es.`status`
Figura 9 Exemplo consulta Juno

23

CONCLUSO
O modelo relacional foi proposto por Edgar Codd em 1970, como uma nova maneira
de representao de dados. Neste seu trabalho Codd mostrou que uma viso relacional
dos dados permite a sua descrio em uma maneira natural, sem que sejam necessrias
estruturas adicionais para sua representao, provendo uma maior independncia dos
dados em relao aos programas. Em complementao, apresentou bases para tratar
problemas como redundncia e consistncia. Mais tarde, em outro trabalho, Codd
definiu uma lgebra relacional e provou, por meio de sua equivalncia com o clculo
relacional, que ela era relacionalmente completa, dando fundamentao terica ao
modelo relacional.
Este modelo, por suas caractersticas e por sua completitude, mostrou ser uma
excelente opo, superando os modelos mais usados quela poca: o de redes e o
hierrquico. A maior vantagem do modelo relacional sobre seus antecessores a
representao simples dos dados e a facilidade com que consultas complexas podem
ser expressas e foi utilizado para tratar o problema proposto das entidades
estacionamento e vaga.

BIBLIOGRAFIA
PRESSMAN, Roger S. Engenharia de Software. 6. ed. So Paulo: McGraw-Hill, 2006.
SILVA, Nelson Peres. Anlise e estrutura de sistemas de informao. So Paulo: rica,
2007.
SOARES, Mrcio V. et al. Algoritmos e Lgica de Programao. 2. ed. So Paulo:
Cengage
Learning, 2011.
WIKIPEDIA,
NORMA

FORMAL,

PRIMEIRA,

http://pt.wikipedia.org/wiki/Normaliza

%C3%A7%C3%A3o_de_dados#Primeira_Forma_Normal,

Ultima

Atualizao:

11/02/2014
http://www.devmedia.com.br/algebra-relacional-parte-i/2663,
01/04/2014

Ultima

Atualizao:

24

http://www.macoratti.net/13/06/sql_arcb.htm : Ultima Atualizao : 30/03/2012

https://dev.mysql.com/ : Ultima Atualizao 12/04/2012
http://www.heidisql.com/ : Ultima Atualizao: 30/03/2014

ANEXO
Comando de configurao do banco de dados utilizado no projeto com a ferramenta
open source MySql e HeidiSQL.
-- --------------------------------------------------------- Servidor:

127.0.0.1

-- Verso do servidor:

5.6.12-log - MySQL Community Server (GPL)

-- OS do Servidor:

Win32

-- HeidiSQL Verso:

8.2.0.4675

-- -------------------------------------------------------/*!40101

SET

@OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0 */;
/*!40101

SET

@OLD_SQL_MODE=@@SQL_MODE,

SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
-- Copiando estrutura do banco de dados para atps
CREATE DATABASE IF NOT EXISTS `atps` /*!40100 DEFAULT CHARACTER
SET utf8 COLLATE utf8_bin */;
USE `atps`;

-- Copiando estrutura para tabela atps.cliente

25

CREATE TABLE IF NOT EXISTS `cliente` (

`id_cliente` int(11) NOT NULL,
`nome_cliente` varchar(250) COLLATE utf8_bin NOT NULL,
`cpf_cliente` varchar(12) COLLATE utf8_bin NOT NULL,
`telefone_coml` int(11) NOT NULL,
`telefone_resl` int(11) NOT NULL,
`telefone_celr` int(11) NOT NULL,
`email` varchar(200) COLLATE utf8_bin DEFAULT NULL,
`placa_veiculo` varchar(7) COLLATE utf8_bin NOT NULL,
`modelo_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`cor_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`tipo_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`ano_veiculo` year(4) DEFAULT NULL,
PRIMARY KEY (`id_cliente`),
KEY `cpf_cliente` (`cpf_cliente`),
KEY `placa_veiculo` (`placa_veiculo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Exportao de dados foi desmarcado.

-- Copiando estrutura para tabela atps.estacionamento

CREATE TABLE IF NOT EXISTS `estacionamento` (
`id_estacionamento` int(11) NOT NULL,
`id_cliente` int(11) NOT NULL,
`placa_veiculo` varchar(7) COLLATE utf8_bin DEFAULT NULL,
`nro_vaga` int(11) NOT NULL,
`status` varchar(3) COLLATE utf8_bin NOT NULL,
KEY `id_estacionamento` (`id_estacionamento`),
KEY `id_cliente` (`id_cliente`),
KEY `placa_veiculo` (`placa_veiculo`),
KEY `nro_vaga` (`nro_vaga`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

26

-- Exportao de dados foi desmarcado.

-- Copiando estrutura para tabela atps.status

CREATE TABLE IF NOT EXISTS `status` (
`id_status` int(11) NOT NULL AUTO_INCREMENT,
`desc_status` varchar(50) COLLATE utf8_bin DEFAULT NULL,
`sigla_status` varchar(3) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id_status`),
KEY `sigla_status` (`sigla_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Exportao de dados foi desmarcado.

-- Copiando estrutura para tabela atps.tipo_vaga

CREATE TABLE IF NOT EXISTS `tipo_vaga` (
`nro_vaga` int(11) NOT NULL,
`tipo_vaga` varchar(50) COLLATE utf8_bin DEFAULT '0',
`valor_vaga` varchar(50) COLLATE utf8_bin DEFAULT NULL,
`sigla_vaga` varchar(3) COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`nro_vaga`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Exportao de dados foi desmarcado.

-- Copiando estrutura para tabela atps.vaga

CREATE TABLE IF NOT EXISTS `vaga` (
`nro_vaga` int(11) NOT NULL,
`locl_vaga` varchar(250) COLLATE utf8_bin NOT NULL,
`sigla_vaga` varchar(3) COLLATE utf8_bin NOT NULL,
`status_vaga` varchar(3) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`nro_vaga`)

27

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

-- Exportao de dados foi desmarcado.
/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS
IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT
*/;
-- --------------------------------------------------------- Servidor:

127.0.0.1

-- Verso do servidor:

5.6.12-log - MySQL Community Server (GPL)

-- OS do Servidor:

Win32

-- HeidiSQL Verso:

8.2.0.4675

-- -------------------------------------------------------/*!40101

SET

@OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0 */;
/*!40101

SET

@OLD_SQL_MODE=@@SQL_MODE,

SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
-- Copiando estrutura do banco de dados para atps
CREATE DATABASE IF NOT EXISTS `atps` /*!40100 DEFAULT CHARACTER
SET utf8 COLLATE utf8_bin */;
USE `atps`;

-- Copiando estrutura para tabela atps.cliente

CREATE TABLE IF NOT EXISTS `cliente` (
`id_cliente` int(11) NOT NULL,
`nome_cliente` varchar(250) COLLATE utf8_bin NOT NULL,

28

`cpf_cliente` varchar(12) COLLATE utf8_bin NOT NULL,

`telefone_coml` int(11) NOT NULL,
`telefone_resl` int(11) NOT NULL,
`telefone_celr` int(11) NOT NULL,
`email` varchar(200) COLLATE utf8_bin DEFAULT NULL,
`placa_veiculo` varchar(7) COLLATE utf8_bin NOT NULL,
`modelo_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`cor_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`tipo_veiculo` varchar(40) COLLATE utf8_bin DEFAULT NULL,
`ano_veiculo` year(4) DEFAULT NULL,
PRIMARY KEY (`id_cliente`),
KEY `cpf_cliente` (`cpf_cliente`),
KEY `placa_veiculo` (`placa_veiculo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Copiando dados para a tabela atps.cliente: ~15 rows (aproximadamente)
/*!40000 ALTER TABLE `cliente` DISABLE KEYS */;
INSERT INTO `cliente` (`id_cliente`, `nome_cliente`, `cpf_cliente`, `telefone_coml`,
`telefone_resl`, `telefone_celr`, `email`, `placa_veiculo`, `modelo_veiculo`, `cor_veiculo`,
`tipo_veiculo`, `ano_veiculo`) VALUES
(1, 'Paulo

Nunes

Maciel',

'84854911573', 2147483647,

2147483647,

2147483647, 'paulo.nunes@gmail.com', 'ILM4540', 'SpaceCross', 'Vermelho', 'Perua', '2005'),

(2, 'Rodrigo Sander Menegassi', '64952647200', 2147483647, 2147483647,
2147483647, 'rsander@gmail.com', 'DPV4540', 'Palio Weekend', 'Cinza', 'Perua', '2009'),
(3,

'Carlos

Alberto

Silva',

'74865728260',

512421138,

2147483647,

2147483647, 'casilva@hotmail.com', 'IAV1546', 'Ecosport', 'Preta', 'Perua', '2008'),

(4,

'Lucas

Klein

Pereira',

'05987430739',

512421149,

2147483647,

2147483647, 'lkpereira@terra.com.br', 'MHM0058', 'Spacefox', 'Amarelo', 'Perua', '2007'),

(5, 'Jorge Alberto do Santos', '34110981042', 2147483647, 2147483647,
2147483647, 'jorgeas@yahoo.com.br', 'IAQ3456', 'Focus', 'Branco', 'Perua', '2006'),
(6, 'Adriana Piccolo', '16482233627', 2147483647, 2147483647, 2147483647,
'apiccolo@gmail.com', 'JDO3211', 'Fiat Siena', 'Dourado', 'Perua', '2010'),
(7, 'Paula Borges de Almeida', '63836756218', 2147483647, 2147483647,
2147483647, 'paula.borges@hotmail.com', 'IAR0987', 'Palio ELX', 'Preto', 'Perua', '2011'),

29

(8, 'Amanda Maciel Fraga', '55313169920', 2147483647, 2147483647,

2147483647, 'amf@gmail.com', 'IAR7866', 'Ecosport', 'Prata', 'Perua', '2009'),
(9, 'Pablo Germiniani', '65838247797', 2147483647, 2147483647, 2147483647,
'pablogerminiani@hotmail.com', 'BEZ5433', 'Fiat Bravo', 'Vermelho', 'Perua', '2013'),
(10, 'Rodrigo Machado Santos', '44423864630', 2147483647, 2147483647,
2147483647, 'rsantos@gmail.com', 'AIP2344', 'Honda Civic', 'Dourado', 'Perua', '2004'),
(11, 'Vagner Alves', '16068251438', 2147483647, 2147483647, 2147483647,
'vagner.alves@gmail.com', 'ILM6577', 'Uno Vivace', 'Branco', 'Perua', '2006'),
(12, 'Paulo Nunes Maciel', '49040363951', 2147483647, 2147483647,
2147483647, 'paulo.nunes@gmail.com', 'IAV4523', 'Meriva Maxx', 'Cinza', 'Perua', '2010'),
(13, 'Paulo Nunes Maciel', '62537214021', 2147483647, 2147483647,
2147483647, 'paulo.nunes@gmail.com', 'ILM1345', 'Citroen C4', 'Verde', 'Perua', '2013'),
(14, 'Paulo Nunes Maciel', '76131936080', 2147483647, 2147483647,
2147483647, 'paulo.nunes@gmail.com', 'JDP3455', 'Fox', 'Vermelho', 'Perua', '2005'),
(15, 'Paulo Nunes Maciel', '60788850490', 2147483647, 2147483647,
2147483647, 'paulo.nunes@gmail.com', 'JDP6788', 'Kia Cerato', 'Prata', 'Perua', '2012');
/*!40000 ALTER TABLE `cliente` ENABLE KEYS */;

-- Copiando estrutura para tabela atps.estacionamento

CREATE TABLE IF NOT EXISTS `estacionamento` (
`id_estacionamento` int(11) NOT NULL,
`id_cliente` int(11) NOT NULL,
`placa_veiculo` varchar(7) COLLATE utf8_bin DEFAULT NULL,
`nro_vaga` int(11) NOT NULL,
`status` varchar(3) COLLATE utf8_bin NOT NULL,
KEY `id_estacionamento` (`id_estacionamento`),
KEY `id_cliente` (`id_cliente`),
KEY `placa_veiculo` (`placa_veiculo`),
KEY `nro_vaga` (`nro_vaga`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Copiando dados para a tabela atps.estacionamento: ~7 rows (aproximadamente)
/*!40000 ALTER TABLE `estacionamento` DISABLE KEYS */;

30

INSERT INTO `estacionamento` (`id_estacionamento`, `id_cliente`, `placa_veiculo`,

`nro_vaga`, `status`) VALUES
(1, 1, 'ILM4540', 1, 'OCP'),
(1, 3, 'IAV1546', 2, 'OCP'),
(1, 14, 'JDP6788', 5, 'OCP');
/*!40000 ALTER TABLE `estacionamento` ENABLE KEYS */;

-- Copiando estrutura para tabela atps.status

CREATE TABLE IF NOT EXISTS `status` (
`id_status` int(11) NOT NULL AUTO_INCREMENT,
`desc_status` varchar(50) COLLATE utf8_bin DEFAULT NULL,
`sigla_status` varchar(3) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id_status`),
KEY `sigla_status` (`sigla_status`)
)

ENGINE=InnoDB

AUTO_INCREMENT=7

DEFAULT

CHARSET=utf8

COLLATE=utf8_bin;
-- Copiando dados para a tabela atps.status: ~6 rows (aproximadamente)
/*!40000 ALTER TABLE `status` DISABLE KEYS */;
INSERT INTO `status` (`id_status`, `desc_status`, `sigla_status`) VALUES
(1, 'Liberada', 'LBD'),
(2, 'Ocupada', 'OCP'),
(3, 'Pendente', 'PND'),
(4, 'Reservada', 'RES'),
(5, 'Manutencao', 'MNT'),
(6, 'Inativa', 'INT');
/*!40000 ALTER TABLE `status` ENABLE KEYS */;

-- Copiando estrutura para tabela atps.tipo_vaga

CREATE TABLE IF NOT EXISTS `tipo_vaga` (
`nro_vaga` int(11) NOT NULL,
`tipo_vaga` varchar(50) COLLATE utf8_bin DEFAULT '0',

31

`valor_vaga` varchar(50) COLLATE utf8_bin DEFAULT NULL,

`sigla_vaga` varchar(3) COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`nro_vaga`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Copiando dados para a tabela atps.tipo_vaga: ~10 rows (aproximadamente)
/*!40000 ALTER TABLE `tipo_vaga` DISABLE KEYS */;
INSERT INTO `tipo_vaga` (`nro_vaga`, `tipo_vaga`, `valor_vaga`, `sigla_vaga`)
VALUES
(1, 'Mensalista', '100.00', 'MEN'),
(2, 'Mensalista', '100.00', 'MEN'),
(3, 'Mensalista', '100.00', 'MEN'),
(4, 'Mensalista', '100.00', 'MEN'),
(5, 'Mensalista', '100.00', 'MEN'),
(6, 'Rotativa', '10.00', 'ROT'),
(7, 'Rotativa', '10.00', 'ROT'),
(8, 'Rotativa', '10.00', 'ROT'),
(9, 'Rotativa', '10.00', 'ROT'),
(10, 'Rotativa', '10.00', 'ROT');
/*!40000 ALTER TABLE `tipo_vaga` ENABLE KEYS */;

-- Copiando estrutura para tabela atps.vaga

CREATE TABLE IF NOT EXISTS `vaga` (
`nro_vaga` int(11) NOT NULL,
`locl_vaga` varchar(250) COLLATE utf8_bin NOT NULL,
`sigla_vaga` varchar(3) COLLATE utf8_bin NOT NULL,
`status_vaga` varchar(3) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`nro_vaga`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- Copiando dados para a tabela atps.vaga: ~10 rows (aproximadamente)
/*!40000 ALTER TABLE `vaga` DISABLE KEYS */;
INSERT INTO `vaga` (`nro_vaga`, `locl_vaga`, `sigla_vaga`, `status_vaga`) VALUES

32

(1, 'A1', 'MEN', 'LBD'),

(2, 'A2', 'MEN', 'OCP'),
(3, 'A3', 'MEN', 'OCP'),
(4, 'A4', 'MEN', 'OCP'),
(5, 'A5', 'MEN', 'RES'),
(6, 'C1', 'ROT', 'LBD'),
(7, 'C2', 'ROT', 'LBD'),
(8, 'C3', 'ROT', 'LBD'),
(9, 'C4', 'ROT', 'LBD'),
(10, 'C5', 'ROT', 'LBD');
/*!40000 ALTER TABLE `vaga` ENABLE KEYS */;
/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;
/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS
IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT
*/;