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
2 000,000,000-02 Mariana 3222-5050 4004-2662
3 000,000,000-03 Antônio 9999-9595 [email protected]
4 000,000,000-04 Stela 4004-6565 9292-6014
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.