FACNET – FACULDADE DE NEGÓCIOS E TECNOLOGIA DA INFORMAÇÃO

ATPS

SISTEMAS DE BANCO

DE DADOS

Cid José Soares

RA:1091136653

Anderson Dantas de Oliveira

RA:1016804512

Gilberto Sousa Moreira

RA:1024874026

Hugo Satre de Sousa

RA: 9292601450

Ludimila Martins Lucas

RA: 9220682227

Turma: BSI 3º SEMESTRE

Turno: Noturno

TAGUATINGA, JUNHO 2011

ETAPA 01 – Passo 1

Sistema de Banco de Dados X Sistema de Arquivos

Antes de SGBDs as aplicações utilizavam sistemas de arquivos do Sistema

Operacional. Através de arquivos, as aplicações armazenavam seus dados

através das interações com a aplicação. Sendo armazenados em diversos

arquivos, precisando de diferentes programas de aplicações para extrair e

acrescentar registros, elevando de formas os custos destas aplicações.

Dados e Meta-dados na base

Os dados e a descrição correspondente são armazenadas na base e

gerenciadas pelo SGBD.

Independência de Dados-Programas

Modificações como inclusão de um novo campo não afetam os programas.

Abstração de Dados

Representação conceitual através de um modelo de dados que só usa

conceitos lógicos.

Múltiplas Visões

São visões, de como os usuários vêem o banco de dados;

- Cada um vê o banco de dados ao seu modo.

Representam a abstração de mais alto nível da arquitetura;

Construídos de forma que sejam removidos os conflitos entre duas ou mais

visões.

Sistema de Banco de Dados

Vantagens Desvantagens

Dados podem ser compartilhados; Os sistemas de banco de dados são

complexos, difíceis e demorados para projetar;

Redundância pode ser reduzida; Custos Iniciais de softwares e

hardwares altos;

Inconsistência pode ser vista (Ate certo ponto);

Danos ao banco de dados afetam virtualmente todos os programas;

Suporte a transações pode ser fornecido;

Custos altos para a conversão de sistemas baseados em arquivos para

banco de dados;

Integridade pode ser mantida;

Treinamento inicial necessários aos programadores e usuários.

Segurança pode ser reforçada;

Requisitos contraditórios podem ser equilibrados;

Padrões podem ser reforçados.

Sistemas de Arquivos

Vantagens Desvantagens

É padrão aberto, não sendo preciso pagar por nenhum software;

Problemas de Integridade;

Existem varias ferramenta e editores bons no mercado;

A redundância pode afetar a eficiência para armazenamento, afetando a

transmissão e processamento, elevando os custos;

Simplicidade e legibilidade, tanto para usuários como para computadores;

Redundância e inconsistência dos dados

Separação do conteúdo para a formatação;

Dificuldade no acesso aos dados;

Possibilidade de criar sua própria sintaxe de dados;

Isolamento dos dados;

Possui suporte a Unicode; Anomalias de acesso concorrente;

Permite validação, o que torna os testes mais efetivos, e a construção

de aplicações bem mais fáceis. Problemas de segurança.

Passo 2

Modelo de dados consiste na especificação das estruturas de dados,

contendo uma coleção de ferramentas conceituais descrevendo dados, relações

de dados, semântica de dados e restrições de consistência. Um modelo de

dados oferece uma maneira de descrever o projeto de um banco de dados do

nível lógico, físico e de view.

Especificando também a atividade de regras de negócios, necessárias

para suportar uma área de negócios. Representada também, por um conjunto de

requerimentos de informações de negócios. É uma parte importante do desenho

que compõem o sistema de informação.

A abordagem que se dispensa ao assunto normalmente atende três

perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A

primeira e conhecida e usada como representação de alto nível e considera

exclusivamente o ponto de vista do usuário criador do dado, a segunda já

agrega alguns detalhes de implementação e a terceira demonstra como os

dados são fisicamente armazenados.

Já os três modelos de dados mais conhecidos, quanto ao objetivo,

podemos identificar os seguintes:

Modelo de dados entidade-relacionamento (MER), (Leitura,

construção e validação dos modelos). O modelo entidade-relacionamento é

baseado em uma percepção de um mundo real que consiste em uma coleção

de objetos básicos chamados entidades, e em relacionamentos entre estes

objetos. Uma entidade é um objeto que é distinguível de outro objeto por um

conjunto específico de atributos. Por exemplo, os atributos número e saldo

descrevem uma conta particular em um banco. Um relacionamento é uma

associação entre várias entidades. Por exemplo, um relacionamento

ContaCliente associa um cliente a cada conta que ele possui. O conjunto de

todas as entidades de um mesmo tipo e o conjunto de relacionamentos do

mesmo tipo são denominados conjuntos de entidades e conjuntos de

relacionamentos, respectivamente.

Em acréscimo a entidades e relacionamentos, o modelo ER representa

certas restrições com os quais os conteúdos de bancos de dados precisam estar

de acordo. Uma restrição importante é o mapeamento de cardinalidade (ou

multiplicidade de um conjunto de relacionamentos) que expressa o número de

entidades ao qual outra entidade pode estar associada via um conjunto de

relacionamentos. Sendo os softwares BrModelo, BPWin, os utilizados;

Modelo relacional, usa uma coleção de tabelas para a representar os

dados e as relações entre ele. Cada tabela possui diversas colunas, e cada

coluna possui um nome único. O modelo relacional é um exemplo de modelo

baseado em registros, e é o modelo de dados mais usado, e uma grande maioria

dos sistemas de banco de dados atuais é baseada no modelo relacional, sendo

os softwares BPWin, Aris Tool Set, Visio da Microsoft e similares SmartDraw,

dentre outros;

Já o modelo de dados baseado em objeto (ODBMS ou OODBMS), um

banco de dados em que a informação é armazenada na forma de objetos. Sendo

o gerenciador de banco de dados para um orientado a objetos. Sendo dois

fatores principais que levam a adoção da tecnologia de banco de dados

orientados a objetos. A primeira, é que em um banco de dados relacional se

torna difícil de manipular com dados complexos. Segundo, os dados são

manipulados pela aplicação escrita usando linguagens de programação

orientada a objetos, e o código precisa ser traduzido entre a representação do

dado e as tuplas da tabela relacional, o que alem de ser uma operação tediosa

de ser escrita, consome tempo. Softwares como C++, C#, Java, Python ou

Delphi, são bem utilizados para esta aplicação.

Passo 3

Entidade e relacionamento – ER. Pois é um modelo abstrato cuja a

finalidade e descrever, de maneira conceitual, os dados a serem utilizados em

um sistema de informação ou que pertençam a um domínio. Sendo a

representação gráfica sua principal ferramenta. Baseado na percepção de um

universo constituído por um grupo básico de objetos chamados de entidades e

por relacionamento entre esses objetos.

Controle de Estacionamento

Entidade Atributos

Estacionamento cpf_proprietario, nome_proprietario, telefone_com, telefone_res,

telefone_cel, e-mail.

vaga modelo_veiculo, cor_veiculo, tipo_veiculo, ano_veiculo.

Passo 4

Esquema – Descrição (Textual ou Gráfica) da estrutura de um banco de

dados de acordo com um determinado modelo de dados.

Esquema do Banco :

Armazenamento no catalogo;

Mudanças muito menos freqüentes.

Instância – Conjunto de dados armazenados em um banco de dados em

um determinado instante de tempo.

Estado do banco :

Dados do banco em qualquer ponto do tempo;

Inicialmente vazio;

Muda freqüentemente;

Validade parcialmente garantida pelo SGBD

Entidades Instâncias

Cliente cpf_proprietario

Produto Vaga_estacionamento

Modelos

de Dados

Esquema Instância

Regra para

estruturação dos

dados

Regra para

verificação das

instâncias

Passo 5

Relatório

Até o presente momento, fora desenvolvido atividades de sondagem de

como será desenvolvido a base, para o real desenvolvimento do banco de

dados, tendo conhecimento do que se faz melhor para a Empresa LFL,

procuramos apresentar de forma clara e objetiva, do que já fora desenvolvido,

pela nossa equipe, bem como exemplificando, e diferenciando as diversas

formas de se montar o Servidor de Banco de Dados.

Procurando o melhor desempenho e praticidade, verificamos que o

melhor para a empresa é um sistema de banco de dados, bem como pela

facilidade de gerar relatórios, modificações, bem como atualizações.

Apresentando a vocês, todas as vantagens e desvantagens para esta

confecção, Junto a este relatório, será enviado, parte de nosso estudo de caso,

para a melhor compreensão, bem como com suas definições e exemplificações.

Já apresentado, nosso relatório, e todos os levantamento para a

confecção da base de banco de dados, iremos agora mais adiante, criando

modelos de entidades-relacionamento, mostrando graficamente todos os

processos pela nossa equipe desenvolvida.

ETAPA 02 – Passo1

*#nro_ficha

*#cpf_proprietario

nome_proprietario

tel_com

tel_res

tel_cel

e_mail

CodigoCadastro

*#nro_ficha

*#nro_vaga

*#placa_veiculo

modelo_veiculo

cor_veiculo

tipo_veiculo

ano_veiculo

CadastroVaga

*#nro_vaga

Passo 2

Entidade – Objeto do universo de interesse do Banco de Dados, cujas

características se deseja armazenar. Pode ser definida como qualquer coisa do

Mundo real, abstrata ou concreta, na qual se deseja guardar informações.

Exemplos de entidades: Cliente, Produto, Contrato, Vendas, etc.

Representação Gráfica

Atributos - Características das entidades, Exemplos de atributos: Código do

Produto (Entidade Produto), Nome do Cliente (Entidade Cliente).

Representação Gráfica

Atributo Chave - Atributo único para a entidade

Representação Gráfica

Atributo Composto - Atributos com tipos de dados diferentes

Representação Gráfica

Linhas - Ligam atributos a conjuntos de entidades e conjuntos de entidades a

relacionamentos. Alguns autores chamam as linhas de arestas, em analogia às

teorias de grafos e redes.

Representação Gráfica

Relacionamento

entre conjuntos de

entidades

cpf_proprietario

nro_vaga

nro_placa

nro_placa

nro_ficha

Passo 3

Relacionamento muitos-para-muitos

O relacionamento muitos-para-muitos é usado quando varias entidades A

se relacionam com varias entidades B. Este relacionamento é representado pelo

sinal: N:N ou N:M.

Percebemos essa relação, devido existirem vários cadastros, para com

relação a diversas vagas de estacionamento. Uma pessoa poderá ter diversas

vagas, da mesma forma que uma vaga não privativa, possa ter vários números

de placas (*#nro_placa).

Passo 4

Cadastro Vaga

Estacionamento possui

nome_proprietario

E_mail

telefone

tipo_veiculo

ano_veiculo

modelo_veiculo

cor_veiculo

Cadastro Vaga

Estacionamento possui

Passo 5

Relatório

Na etapa anterior fora desenvolvido, a parte conceitual e uma breve

introdução, do que seria desenvolvido, para o SGBD da Empresa LFL, como foi

dito em relatório anteriormente.

Já nesta etapa, criamos quadro de cada entidade propostas, identificando

todos seus atributos com seus devidos tipos, chaves e relacionamentos.

Representando graficamente os Modelos de Entidades Relacionais, identificando

as entidades propostas e a simbologia de cada figura atribuída.

Apresentamos também, os relacionamentos existentes entre as entidades

levantando sua cardinalidade (1:1, 1:N, N:M), seu grau de relacionamento,

justificando seus relacionamentos apresentando o conceito de relacionamento e

cardinalidade.

Desenvolvemos, a partir daí um Diagrama de Entidade e Relacionamento,

completo (Entidade, Atributos, Chaves, Relacionamento, Cardinalidade,

Símbolos, dentre outros), partindo da entidade proposta no programa e das

atividades desenvolvidas anteriormente.

Etapa 3 – Passo 1

O Modelo Relacional

A arquitetura de um banco de dados relacional pode ser descrita de

maneira informal ou formal. Na descrição informal estamos preocupados com

aspectos práticos da utilização e usamos os termos tabela, linha e coluna. Na

descrição formal estamos preocupados com a semântica formal do modelo e

usamos termos como relação(tabela), tupla(linhas) e atributo(coluna).

Tabelas (ou relações, ou entidades)

Todos os dados de um banco de dados relacional (BDR) são

armazenados em tabelas. Uma tabela é uma simples estrutura de linhas e

colunas. Em uma tabela, cada linha contém um mesmo conjunto de colunas. Em

um banco de dados podem existir uma ou centenas de tabelas, sendo que o

limite pode ser imposto tanto pela ferramenta de software utilizada, quanto pelos

recursos de hardware disponíveis no equipamento.

As tabelas associam-se entre si através de regras de relacionamentos, estas

regras consistem em associar um ou vários atributo de uma tabela com um ou

vários atributos de outra tabela.

Exemplo: A tabela cadastro relaciona-se com a tabela vaga no

estacionamento. Através deste relacionamento esta última tabela fornece

a lista de vagas para a tabela cadastro.

Registros (ou tuplas)

Cada linha formada por uma lista ordenada de colunas representa um

registro, ou tupla. Os registros não precisam conter informações em todas as

colunas, podendo assumir valores nulos quando assim se fizer necessário.

Resumidamente, um registro é uma instância de uma tabela, ou entidade.

Exemplo: O Cliente cpf_proprietario é uma instância (registro) da tabela

cadastro, e a nro_vaga é a instância (registro) da tabela vaga do

Estacionamento. Uma associação entre estas duas tabelas criaria a

seguinte instância de relacionamento: cpf_proprietario é o nro_vaga, onde

o verbo ser representa uma ligação entre os registros distintos.

Colunas (tribunas)

As colunas de uma tabela são também chamadas de Atributos. Ao

conjunto de valores que um atributo pode assumir chama-se domínio. Por

exemplo: em um campo do tipo numérico, serão somente armazenados

números.etc

O conceito mais similar a domínio é o de Tipo Abstrato de Dados em

linguagens de programação, ou seja são meta-dados (dados acerca de dados).

Exemplo: cpf_proprietario, ano_veiculo, placa_veiculo, nro_ficha,

telefone(s), nro_ficha, nro_vaga.

Chave

As tabelas relacionam-se umas as outras através de chaves. Uma chave

é um conjunto de um ou mais atributos que determinam a unicidade de cada

registro.

Por exemplo, se um banco de dados tem como chaves Nro_Vaga e

Nro_Ficha, sempre que acontecer uma inserção de dados o sistema de

gerenciamento de banco de dados irá fazer uma consulta para identificar se o

registro já não se encontra gravado na tabela. Neste caso, um novo registro não

será criado, resultando esta operação apenas da alteração do registro existente.

A unicidade dos registros, determinada por sua chave, também é

fundamental para a criação dos índices.

Temos dois tipos de chaves:

1. Chave primária: (PK - Primary Key) é a chave que identifica cada

registro dando-lhe unicidade. A chave primária nunca se repetirá.

2. Chave Estrangeira: (FK - Foreign Key) é a chave formada através

de um relacionamento com a chave primária de outra tabela. Define um

relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave

primária seja composta na origem, a chave estrangeira também o será.

Passo 2

Grande parte das extensão aproximaram o MER do modelo Orientado à

Objeto, não sendo muito utilizados, pois os SGBD’s Relacionais não suportam

diretamente extensões, então se faz necessário antes de implementar mapear

esta extensões para o MER original.

Uma limitação do modelo E-R é que não é possível expressar

relacionamentos entre relacionamentos.

A agregação é uma abstração através das quais relacionamentos são

tratados como entidades de nível superior.

Usando Agregação

Cadastro

Vaga Estacionamento

nro_vaga

Utiliza

Proprietá-

rio

Passo 3

Identificamos que há nesta forma descrita na figura uma co-relação entre

suas entidades e relacionamentos, sendo possível relacionar todos eles. Sendo

assim as entidades não são tratadas de uma forma tão superior como na

relacional.

Proprietá-

rio Cadastro

Vaga Estacionamento

nro_vaga

Utiliza

Passo 4

Relatório

Bem como em relatórios anteriores, se fazendo em comum todo o assunto

tratado, foram importante para que se desenvolvessem alguns conceitos, neste,

não se fazendo diferente, pois nossa equipe desenvolveu conceitos do Modelo

Relacional, sendo aplicados e demonstrados na forma de representação gráfica

de um banco de dados, sendo assim mapeados os Modelos (DER e Modelo

relacional).

Descrevendo todos os itens que as compõem, na forma de uma estrutura

Relacional, apontando funções e as relacionando com as entidades propostas

no projeto. Descrevendo limitações existentes na execução do processo de

Mapeamento do modelo MER para o Relacional.

Criando representações gráficas e demonstrando conversões do DER em

Modelo Relacional e assim vice-versa, descrevendo tais processos passo-a-

passo. Apresentando sempre o ponto de vista na facilidade de compreensão da

modelagem e estrutura funcional, por parte da equipe.

Etapa 4 – Passo 1

Normalização de dados é o processo formal passo a passo que examina

os atributos de uma entidade, com o objetivo de evitar anomalias observadas na

inclusão, exclusão e alteração de registros.

Uma regra de ouro que devemos observar quando do projeto de um

Banco de Dados baseado no Modelo Relacional de Dados é a de "não misturar

assuntos em uma mesma Tabela". Por exemplo: na Tabela Cadastro devemos

colocar somente campos relacionados com o assunto de cadastro do cliente.

Não devemos misturar campos relacionados com outros assuntos. Essa "Mistura

de Assuntos" em uma mesma tabela acaba por gerar repetição desnecessária

dos dados bem como inconsistência dos dados.

Normalmente após a aplicação das regras de normalização de dados,

algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no

final gera um número maior de tabelas do que o originalmente existente. Este

processo causa a simplificação dos atributos de uma tabela, colaborando

significativamente para a estabilidade do modelo de dados, reduzindo-se

consideravelmente as necessidades de manutenção.

Objetivos

Minimização de redundâncias e inconsistências;

Facilidade de manipulações do banco de dados;

Facilidade de manutenção do sistema de Informação.

Uma relação estará na Primeira forma normal 1FN, se e somente se

todos os domínios básicos contiverem somente valores atômicos (não contiver

grupos repetitivos).

Em outras palavras podemos definir que a primeira forma normal não

admite repetições ou campos que tenha mais que um valor.

Considere a tabela cadastro abaixo:

Cadastro:

nro_ficha; nome_proprietario; telefone; endereço

Agora a tabela com os dados:

Tabela desnormalizada, ou seja, não está na 1ª forma normal

Analisando teremos:

Todos os clientes possuem Rua, CEP e Bairro, e essas informações estão

na mesma célula da tabela, logo ela não está na primeira forma normal. Para

normalizar, deveremos colocar cada informação em uma coluna diferente, como

no exemplo a seguir:

Nro_ficha Nome_propri Telefone Endereço

Tabela ainda não está na primeira forma normal

Mesmo com o ajuste acima, a tabela ainda não está na primeira forma

normal, pois há clientes com mais de um telefone e os valores estão em uma

mesma célula. Para normalizar será necessário criar uma nova tabela para

armazenar os números dos telefones e o campo-chave da tabela cliente. Veja o

resultado a seguir:

Tabela na primeira forma normal

Tabela na 1ª forma normal

No exemplo acima foi gerado uma segunda entidade para que a primeira

forma normal fosse satisfeita, contudo é possível manter a tabela original,

admitindo-se valores duplos em uma mesma coluna, como exemplo o campo

telefone ficaria assim: 11-3400-3563 e 19-3500-9650. Neste caso a tabela ficaria

Nro_ficha Nome_propri Rua Bairro CEP

Nro_ficha Nome_propri Rua Bairro CEP Telefone

Nro_ficha Telefone

desnormalizada, mas muitos acabam preferindo assim, principalmente quando

há poucos casos de repetição.

Passo 2

Uma tabela está na Segunda Forma Normal 2FN se ela estiver na 1FN e

todos os atributos não chave forem totalmente dependentes da chave primária

(dependente de toda a chave e não apenas de parte dela).

Se o nome do produto já existe na tabela produtos, então não é necessário que

ele exista na tabela de produtos. A segunda forma normal trata destas

anomalias e evita que valores fiquem em redundância no banco de dados.

Procedimentos:

a) Identificar os atributos que não são funcionalmente dependentes de toda a

chave primária;

b) Remover da entidade todos esses atributos identificados e criar uma nova

entidade com eles.

A chave primária da nova entidade será o atributo do qual os atributos do qual os

atributos removidos são funcionalmente dependentes.

Exemplo de segunda forma normal

Considere a tabela vendas abaixo:

Estacionamento

Nro_ficha

Código_vaga

vaga

Quant

Valor_unit

Subtotal

Agora a tabela com os dados:

Tabela não está na segunda forma normal

Analisando teremos:

O nome do produto depende do código da vaga, porém não depende de

Nro_ficha que é a chave primária da tabela, portanto não está na segunda

forma normal. Isto gera problemas com a manutenção dos dados, pois se

houver alteração no nome do produto teremos que alterar em todos os registros

da tabela venda.

Para normalizar esta tabela teremos de criar a tabela Estacionamento que ficará

com os atributos Código_vaga e vaga e na tabela Vaga manteremos somente os

atributos Nro_ficha, código_vaga, quant, valor_unit e subtotal. Veja o resultado

abaixo:

Funcionários

Diretoria

Imprensa

Empresarial

Nro_ficha Codigo_vaga Vaga Quant Valor_unit Subtotal

Tabela na segunda forma normal

Tabela na 2ª forma normal

Conforme visto na Primeira forma normal, quando aplicamos normalização é

comum gerar novas tabelas a fim de satisfazer as formas normais que estão

sendo aplicadas.

Passo 3

Uma tabela está na Terceira Forma Normal 3FN se ela estiver na 2FN e se

nenhuma coluna não-chave depender de outra coluna não-chave.

Na terceira forma normal temos de eliminar aqueles campos que podem ser

obtidos pela equação de outros campos da mesma tabela.

Procedimentos:

a) Identificar todos os atributos que são funcionalmente dependentes de outros

atributos não chave;

b) Removê-los.

Nro_ficha Codigo_vaga Quant Valor_unit Subtotal

Codigo-vaga

Funcionários

Diretoria

Imprensa

Empresarial

Vaga

A chave primária da nova entidade será o atributo do qual os atributos removidos

são funcionalmente dependentes.

Exemplo de normalização na terceira forma normal

Considere a tabela abaixo:

Tabela não está na terceira forma normal

Considerando ainda a nossa tabela Vaga, veremos que a mesma não está na

terceira forma normal, pois o subtotal é o resultado da multiplicação Quant X

Valor_unit, desta forma a coluna subtotal depende de outras colunas não-chave.

Para normalizar esta tabela na terceira forma normal teremos de eliminar a

coluna subtotal, como no exemplo a seguir:

Tabela na terceira forma normal

Nro_ficha Codigo_vaga Quant Valor_unit Subtotal

Nro_ficha Codigo_vaga Quant Valor_unit

Passo 4

Relatório

Aprendemos nesta etapa, a desenvolver a organização de entidades no

Banco de Dados baseando nas regras de normalização, fazendo com que

minimize a duplicidade dos dados e mantenha as devidas dependências das

informações nas várias entidades do Banco de Dados. A proposta dessa etapa é

transformar tuplas não normalizadas em tuplas na 3ª Forma Normal (3FN).

Passamos ai, a transformar as tuplas não normalizadas das entidades

propostas, passando para a 1ª Forma Normal (1FN), e conceituando-as para

melhor entendimento de normalização, já tínhamos as tuplas na 1 Forma

Normal, a equipe seguiu o próximo passo e colocamos na 2ª Forma Normal

(2FN). Já o próximo passo era colocá-las na 3ª Forma Normal, através de

conhecimentos extraídos de livros e apostilas, podemos enfim deixar bem claro,

o que é normalização e de como faremos, para normalizar um Banco de Dados.

Etapa 5 – Passo 1

Nro_ficha(FK) Nome_proprietario(FK) Endereço Saldo Cod_vaga

1 João Quadra X 125 1.001

2 Mariana Quadra YZ 224 1.002

3 Antônio Quadra Z 52 1.001

4 Stela Quadra W 210 1.002

5 Joaquim Quadra G 15 1.003

6 Marlene Quadra XY 7 1.004

7 Gil Quadra S 66 1.001

8 Pedro Quadra X 85 1.002

9 Matheus Quadra E 199 1.003

10 Cláudio Quadra Z 59 1.004

Passo 2

Seleção Seleciona tuplas da relação argumento que satisfaçam à

condição de seleção;

• pode envolver operadores de comparação (=, <, >, ≤, ≥, ≠); • pode combinar condições

usando-se , , .

condição_seleção ( relação argumento)

• relação; • resultado de alguma

operação de álgebra relacional.

Relação Cliente

cliente (nro_ficha, nome_proprietario, endereço, saldo, cod_vaga)

Nro_ficha Nome_proprietario Endereço Saldo Cod_vaga

1 João Quadra X 125 1.001

2 Mariana Quadra YZ 224 1.002

3 Antônio Quadra Z 52 1.001

Listando todas as informações da relação de Vaga do Proprietário de

número 02.

nro_cli = 2 (Vaga)

Relação Resultado cliente (nro_ficha, nome_proprietario, endereço, saldo, cod_vaga)

Nro_ficha Nome_proprietario Endereço Saldo Cod_vaga

1 João Quadra X 125 1.001

Número de tuplas:

menor ou igual ao

número de tuplas da

relação argumento.

Grau: Mesmo grau da

relação argumento

Passo 3 Projeção Produz uma nova relação contendo um “subconjunto vertical” da relação

argumento, sem “duplicações”:

Nro_ficha Nome_proprietario

1 João

2 Mariana

3 Antônio

O resultado de uma operação de projeção é uma relação não devem existir

tuplas repetidas;

Se <atributos> contém chave de relação resultado não tem

tuplas repetidas;

Se <atributos> não contém chave possibilidade de tuplas

repetidas.

Eliminação de repetições

πlista_atributos ( relação argumento )

Lista de atributos;

Os atributos são separados

por vírgula.

Relação;

Resultado de alguma operação

de álgebra relacional.

Número de tuplas: menor

ou igual ao número de

tuplas da relação

argumento.

Grau: número de

atributos listados em

lista_atributos

Passo 4

União

Une duas relações R e S compatíveis em uma relação que contém todas

as tuplas pertencentes a R, a S, ou a ambas (R e S):

Passo 5

Interseção

Une duas relações R e S compatíveis em uma relação que contém todas

as tuplas pertencentes a R quanto a S:

Nro_ficha Nro_vaga

1 C015

2 L002

3

S021

Relação argumento 1 Relação argumento 2

Relação argumento 1 ∩Relação argumento 2

Etapa 6 – Passo 1

Divisão

Divisão de duas relações R e S:

o Todos os valores de um atributo em R que fazem referência a

todos os valores de um atributo S;

ficha_vaga nro_vaga(vaga)

Nro_vaga

66

04

Nro_ficha Nro_vaga

9 12

1 04

1 66

4 03

5 11

8 04

Nro_ficha

1

Relação argumento 1 ÷Relação argumento 2

pedido_peça ÷ peça

Divisão:utilizada para

consultas que incluam o

termo para todos ou em

todos

Passo 2

Diferença

Une duas relações R e S compatíveis em uma relação que contém todas

as tuplas pertencentes a R que não pertencem a S:

Relações Estacionamento e Vaga

Estacionamento (nro_ficha; CPF_proprietário; nome_proprietário;

telefone_com; telefone_res; telefone_cel; e-mail.

Vaga (nro_vaga; placa_veiculo; modelo_veiculo; cor_veiculo; tipo_veiculo;

ano_veiculo)

Nro_vaga Placa_veiculo Modelo_veiculo Cor_veiculo Tipo_veiculo Ano_veiculo

C001 JDF-5151 Corsa Azul Chevrolet 2010/2011

E003 KBJ-2121 Hillux Preta Toyota 2010

Nro_ficha CPF_proprietario Nome_proprietario telefone e-mail

1 000,000,000-01 João 9999-9999 3222-2525 4004-0001

joão@joao.com.br

2 000,000,000-02 Mariana 3222-5050 4004-2662

mariana@mariana.com.br

3 000,000,000-03 Antônio 9999-9595 antonio@antonio.com.br

4 000,000,000-04 Stela 4004-6565 9292-6014

stela@stela.com.br

Relação argumento 1 -Relação argumento 2

Passo 3

Junção Natural

Concatena tuplas relacionadas de duas relações em tuplas únicas;

Simplifica consultas que requerem produto cartesiano:

Forma um produto cartesiano dos argumentos;

Faz uma seleção forçando igualdade sobre os atributos que aparecem

em ambos argumentos;

Remove colunas duplicadas

Junção

Concatenação:

dos atributos comuns;

dos atributos especificados na condição de junção;

Estacionamento (nro_ficha; CPF_proprietário; nome_proprietário; nro_vaga;

cod_vaga

Nro_ficha CPF_proprietario Nome_proprietario nro_vaga cod_vaga

1 000,000,000-01 João C001 1.001

2 000,000,000-02 Mariana L005 1.002

3 000,000,000-03 Antônio H012 1.001

4 000,000,000-04 Stela A021 1.002

Relação argumento 1 condição_junçãoRelação argumento 2

Vaga (cod_vaga; nro_ficha ; nome_proprietario.

Estacionamento Vaga

cod_vaga nro_ficha Nome_proprietario

1.001 01 João

1.004 10 Cláudio

Nro_ficha Nome_proprietario endereço nro_vaga cod_vaga

1 João Quadra X C001 1.001

2 Mariana Quadra YZ L005

1.002

3 Antônio Quadra Z H012 1.001

4 Stela Quadra W A021 1.002

Grau: número de atributos

diferentes de

estacionamento e de vagas

+ (número de atributos

comuns)

Número de tuplas: entre zero

e (número de tuplas de

estacionamento * número de

tuplas de código da vaga

Passo 4

Relatório

Nesta nova etapa fora construído mecanismos de pesquisas capazes

de manipular dados existentes em banco de dados. Criamos nesta etapa,

diversas operações de álgebra relacional que sejam aplicáveis em banco

de dados, utilizados como base do Modelo Relacional.

Desenvolvemos atividades de criação de tuplas para cada relação

(Tabela) existente, seguindo os conceitos tratados nas etapas anteriores.

Fora criada uma operação, para cada operação de álgebra relacional, são

eles:

Seleção;

Projeção;

União;

Interseção;

Divisão;

Diferença;

Junção.

Para cada operação, fora criado uma tabela para melhor

entendimento da equipe, e conceituada de suas funções exercidas no

Modelo Relacional à Banco de Dados.