FACNET FACULDADE DE NEGCIOS E TECNOLOGIA DA INFORMAO

ATPS SISTEMAS DE BANCO DE DADOS Cid, Hugo, Gilberto, Anderson, Ludimila

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 aplicaes utilizavam sistemas de arquivos do Sistema Operacional. Atravs de arquivos, as aplicaes armazenavam seus dados atravs das interaes com a aplicao. Sendo armazenados em diversos arquivos, precisando de diferentes programas de aplicaes para extrair e acrescentar registros, elevando de formas os custos destas aplicaes.

Dados e Meta-dados na base

Os dados e a descrio correspondente so armazenadas na base e gerenciadas pelo SGBD.

Independncia de Dados-Programas

Modificaes como incluso de um novo campo no afetam os programas.

Abstrao de Dados

Representao conceitual atravs de um modelo de dados que s usa conceitos lgicos.

Mltiplas Vises

So vises, de como os usurios vem o banco de dados; - Cada um v o banco de dados ao seu modo. Representam a abstrao de mais alto nvel da arquitetura; Construdos de forma que sejam removidos os conflitos entre duas ou mais vises.

Sistema de Banco de Dados

Vantagens Dados podem ser compartilhados; Redundncia pode ser reduzida; Inconsistncia pode ser vista (Ate certo ponto); Suporte a transaes pode ser fornecido; Integridade pode ser mantida; Segurana pode ser reforada; Requisitos contraditrios podem ser equilibrados; Padres podem ser reforados.

Desvantagens Os sistemas de banco de dados so complexos, difceis e demorados para projetar; Custos Iniciais de softwares e hardwares altos; Danos ao banco de dados afetam virtualmente todos os programas; Custos altos para a converso de sistemas baseados em arquivos para banco de dados;

Treinamento inicial necessrios aos programadores e usurios.

Sistemas de Arquivos

Vantagens padro aberto, no sendo preciso pagar por nenhum software; Existem varias ferramenta e editores bons no mercado; Simplicidade e legibilidade, tanto para usurios como para computadores; Separao do contedo para a formatao; Possibilidade de criar sua prpria sintaxe de dados; Possui suporte a Unicode; Permite validao, o que torna os testes mais efetivos, e a construo de aplicaes bem mais fceis.

Desvantagens Problemas de Integridade; A redundncia pode afetar a eficincia para armazenamento, afetando a transmisso e processamento, elevando os custos; Redundncia e inconsistncia dos dados Dificuldade no acesso aos dados; Isolamento dos dados; Anomalias de acesso concorrente; Problemas de segurana.

Passo 2 Modelo de dados consiste na especificao das estruturas de dados, contendo uma coleo de ferramentas conceituais descrevendo dados, relaes de dados, semntica de dados e restries de consistncia. Um modelo de dados oferece uma maneira de descrever o projeto de um banco de dados do nvel lgico, fsico e de view. Especificando tambm a atividade de regras de negcios, necessrias para suportar uma rea de negcios. Representada tambm, por um conjunto de requerimentos de informaes de negcios. uma parte importante do desenho que compem o sistema de informao. 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.

J os trs modelos de dados mais conhecidos, quanto ao objetivo, podemos identificar os De dados

entidade-relacionamento

(MER),

(Leitura,

construo e validao dos modelos). O modelo entidade-relacionamento baseado em uma percepo de um mundo real que consiste em uma coleo de objetos bsicos chamados entidades, e em relacionamentos entre estes objetos. Uma entidade um objeto que distinguvel de outro objeto por um

conjunto especfico de atributos. Por exemplo, os atributos nmero e saldo descrevem uma conta particular em um banco. Um relacionamento uma associao entre vrias 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 so denominados conjuntos de entidades e conjuntos de relacionamentos, respectivamente.

Em acrscimo a entidades e relacionamentos, o modelo ER representa certas restries com os quais os contedos de bancos de dados precisam estar de acordo. Uma restrio importante o mapeamento de cardinalidade (ou multiplicidade de um conjunto de relacionamentos) que expressa o nmero de entidades ao qual outra entidade pode estar associada via um conjunto usa uma coleo de tabelas para a representar os dados e as relaes 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;

a informao armazenada na forma de objetos. Sendo o gerenciador de banco de dados para um orientado a objetos. Sendo dois

fatores principais que levam a adoo da tecnologia de banco de dados orientados a objetos. A primeira, que em um banco de dados relacional se torna difcil de manipular com dados complexos. Segundo, os dados so manipulados pela aplicao escrita usando linguagens de programao orientada a objetos, e o cdigo precisa ser traduzido entre a representao do dado e as tuplas da tabela relacional, o que alem de ser uma operao tediosa de ser escrita, consome tempo. Softwares como C++, C#, Java, Python ou Delphi, so bem utilizados para esta aplicao.

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 informao ou que pertenam a um domnio. Sendo a representao grfica sua principal ferramenta. Baseado na percepo de um universo constitudo por um grupo bsico de objetos chamados de entidades e por relacionamento entre esses objetos.

Controle de Estacionamento

Entidade

Atributos cpf_proprietario, nome_proprietario, telefone_com, telefone_res,

Estacionamento telefone_cel, e-mail. vaga modelo_veiculo, cor_veiculo, tipo_veiculo, ano_veiculo.

Passo 4 Esquema Descrio (Textual ou Grfica) da estrutura de um banco de dados de acordo com um determinado modelo de dados.

Armazenamento no catalogo; Mudanas muito menos freqentes. Instncia Conjunto de dados armazenados em um banco de dados em

um determinado instante de tempo.

Dados do banco em qualquer ponto do tempo; Inicialmente vazio; Muda freqentemente; Validade parcialmente garantida pelo SGBD

Modelos de Dados Regra para estruturao dos dados

Esquema Regra para verificao das instncias

Instncia

Entidades Cliente Produto

Instncias cpf_proprietario Vaga_estacionamento

Passo 5

Relatrio

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 relatrios, modificaes, bem como atualizaes.

Apresentando a vocs, todas as vantagens e desvantagens para esta confeco, Junto a este relatrio, ser enviado, parte de nosso estudo de caso, para a melhor compreenso, bem como com suas definies e exemplificaes.

J apresentado, nosso relatrio, e todos os levantamento para a confeco 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

CodigoCadastro *#nro_ficha

*#nro_vaga *#placa_veiculo modelo_veiculo

*#nro_ficha *#cpf_proprietario nome_proprietario tel_com tel_res tel_cel e_mail

CadastroVaga *#nro_vaga

cor_veiculo tipo_veiculo ano_veiculo

Passo 2 Entidade Objeto do universo de interesse do Banco de Dados, cujas caractersticas se deseja armazenar. Pode ser definida como qualquer coisa do Mundo real, abstrata ou concreta, na qual se deseja guardar informaes. Exemplos de entidades: Cliente, Produto, Contrato, Vendas, etc. Representao Grfica Relacionamento entre conjuntos de entidades

Atributos - Caractersticas das entidades, Exemplos de atributos: Cdigo do Produto (Entidade Produto), Nome do Cliente (Entidade Cliente). Representao Grfica

Atributo Chave - Atributo nico para a entidade Representao Grfica

Atributo Composto - Atributos com tipos de dados diferentes Representao Grfica

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.

Representao Grfica

Passo 3

Cadastro

possui

Vaga Estacionamento

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 relao, devido existirem vrios cadastros, para com relao a diversas vagas de estacionamento. Uma pessoa poder ter diversas vagas, da mesma forma que uma vaga no privativa, possa ter vrios nmeros de placas (*#nro_placa).

Passo 4 cpf_proprietario

nome_proprietario E_mail

telefone

nro_placa nro_ficha

Cadastro tipo_veiculo modelo_veiculo

possui

Vaga Estacionamento

nro_placa

nro_vaga ano_veiculo

cor_veiculo

Passo 5

Relatrio Na etapa anterior fora desenvolvido, a parte conceitual e uma breve introduo, do que seria desenvolvido, para o SGBD da Empresa LFL, como foi dito em relatrio 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 atribuda. Apresentamos tambm, 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, Smbolos, 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 descrio informal estamos preocupados com aspectos prticos da utilizao e usamos os termos tabela, linha e coluna. Na descrio formal estamos preocupados com a semntica formal do modelo e usamos termos como relao(tabela), tupla(linhas) e atributo(coluna).

Tabelas (ou relaes, ou entidades)

Todos os dados de um banco de dados relacional (BDR) so armazenados em tabelas. Uma tabela uma simples estrutura de linhas e colunas. Em uma tabela, cada linha contm 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 disponveis no equipamento.

As tabelas associam-se entre si atravs de regras de relacionamentos, estas regras consistem em associar um ou vrios atributo de uma tabela com um ou vrios atributos de outra tabela.

Exemplo: A tabela cadastro relaciona-se com a tabela vaga no estacionamento. Atravs 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 no precisam conter informaes em todas as colunas, podendo assumir valores nulos quando assim se fizer necessrio.

Resumidamente, um registro uma instncia de uma tabela, ou entidade.

Exemplo: O Cliente cpf_proprietario uma instncia (registro) da tabela cadastro, e a nro_vaga a instncia (registro) da tabela vaga do Estacionamento. Uma associao entre estas duas tabelas criaria a seguinte instncia de relacionamento: cpf_proprietario o nro_vaga, onde o verbo ser representa uma ligao entre os registros distintos.

Colunas (tribunas)

As colunas de uma tabela so tambm chamadas de Atributos. Ao conjunto de valores que um atributo pode assumir chama-se domnio. Por exemplo: em um campo do tipo numrico, sero somente armazenados nmeros.etc

O conceito mais similar a domnio o de Tipo Abstrato de Dados em linguagens de programao, ou seja so meta-

cpf_proprietario,

ano_veiculo,

placa_veiculo,

nro_ficha,

telefone(s), nro_ficha, nro_vaga.

Chave

As tabelas relacionam-se umas as outras atravs 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 insero de dados o sistema de gerenciamento de banco de dados ir fazer uma consulta para identificar se o registro j no se encontra gravado na tabela. Neste caso, um novo registro no ser criado, resultando esta operao apenas da alterao do registro existente.

A unicidade dos registros, determinada por sua chave, tambm fundamental para a criao dos ndices.

Temos dois tipos de chaves:

1. Chave primria: (PK - Primary Key) a chave que identifica cada registro dando-lhe unicidade. A chave primria nunca se repetir.

2. Chave Estrangeira: (FK - Foreign Key) a chave formada atravs de um relacionamento com a chave primria de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave primria seja composta na origem, a chave estrangeira tambm o ser.

Passo 2 Grande parte das extenso aproximaram o MER do modelo Orientado Objeto, no sendo muito utilizados, pois os SGBDs Relacionais no suportam diretamente extenses, ento se faz necessrio antes de implementar mapear esta extenses para o MER original. Uma limitao do modelo E-R que no possvel expressar relacionamentos entre relacionamentos. A agregao uma abstrao atravs das quais relacionamentos so tratados como entidades de nvel superior. Usando Agregao

Cadastro

Proprietrio

nro_vaga

Utiliza

Vaga Estacionamento

Passo 3

Cadastro

Proprietrio

nro_vaga

Utiliza

Vaga Estacionamento

Identificamos que h nesta forma descrita na figura uma co-relao entre suas entidades e relacionamentos, sendo possvel relacionar todos eles. Sendo assim as entidades no so tratadas de uma forma to superior como na relacional.

Passo 4 Relatrio

Bem como em relatrios anteriores, se fazendo em comum todo o assunto tratado, foram importante para que se desenvolvessem alguns conceitos, neste, no se fazendo diferente, pois nossa equipe desenvolveu conceitos do Modelo Relacional, sendo aplicados e demonstrados na forma de representao grfica de um banco de dados, sendo assim mapeados os Modelos (DER e Modelo relacional). Descrevendo todos os itens que as compem, na forma de uma estrutura Relacional, apontando funes e as relacionando com as entidades propostas no projeto. Descrevendo limitaes existentes na execuo do processo de Mapeamento do modelo MER para o Relacional. Criando representaes grficas e demonstrando converses do DER em Modelo Relacional e assim vice-versa, descrevendo tais processos passo-apasso. Apresentando sempre o ponto de vista na facilidade de compreenso da modelagem e estrutura funcional, por parte da equipe.

Etapa 4 Passo 1

Normalizao de dados o processo formal passo a passo que examina os atributos de uma entidade, com o objetivo de evitar anomalias observadas na incluso, excluso e alterao 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 "no misturar assuntos em uma mesma Tabela". Por exemplo: na Tabela Cadastro devemos colocar somente campos relacionados com o assunto de cadastro do cliente. No devemos misturar campos relacionados com outros assuntos. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetio desnecessria dos dados bem como inconsistncia dos dados. Normalmente aps a aplicao das regras de normalizao de dados, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um nmero maior de tabelas do que o originalmente existente. Este processo causa a simplificao dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manuteno. Objetivos

Uma relao estar na Primeira forma normal 1FN, se e somente se todos os domnios bsicos contiverem somente valores atmicos (no contiver grupos repetitivos). Em outras palavras podemos definir que a primeira forma normal no admite repeties ou campos que tenha mais que um valor.

Considere a tabela cadastro abaixo: Cadastro: nro_ficha; nome_proprietario; telefone; endereo Agora a tabela com os dados: Nro_ficha Nome_propri Telefone Endereo

Tabela desnormalizada, ou seja, no est na 1 forma normal Analisando teremos: Todos os clientes possuem Rua, CEP e Bairro, e essas informaes esto na mesma clula da tabela, logo ela no est na primeira forma normal. Para normalizar, deveremos colocar cada informao em uma coluna diferente, como no exemplo a seguir:

Nro_ficha

Nome_propri

Telefone

Rua

Bairro

CEP

Tabela ainda no est na primeira forma normal Mesmo com o ajuste acima, a tabela ainda no est na primeira forma normal, pois h clientes com mais de um telefone e os valores esto em uma mesma clula. Para normalizar ser necessrio criar uma nova tabela para armazenar os nmeros dos telefones e o campo-chave da tabela cliente. Veja o resultado a seguir: Nro_ficha Nome_propri Rua Bairro CEP

Tabela na primeira forma normal Nro_ficha Telefone

Tabela na 1 forma normal No exemplo acima foi gerado uma segunda entidade para que a primeira forma normal fosse satisfeita, contudo possvel manter a tabela original, admitindose valores duplos em uma mesma coluna, como exemplo o campo telefone ficaria assim: 113400-3563 e 19-3500-9650. Neste caso a tabela ficaria

desnormalizada, mas muitos acabam preferindo assim, principalmente quando h poucos casos de repetio. Passo 2

Uma tabela est na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os atributos no chave forem totalmente dependentes da chave primria (dependente de toda a chave e no apenas de parte dela). Se o nome do produto j existe na tabela produtos, ento no necessrio que ele exista na tabela de produtos. A segunda forma normal trata destas anomalias e evita que valores fiquem em redundncia no banco de dados. Procedimentos:

a) Identificar os atributos que no so funcionalmente dependentes de toda a chave primria;

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

A chave primria da nova entidade ser o atributo do qual os atributos do qual os atributos removidos so funcionalmente dependentes. Exemplo de segunda forma normal

Considere a tabela vendas abaixo: Estacionamento Nro_ficha Cdigo_vaga

vaga Quant Valor_unit Subtotal Agora a tabela com os dados:

Nro_ficha Codigo_vaga

Vaga Imprensa Diretoria Empresarial Funcionrios

Quant

Valor_unit

Subtotal

Tabela no est na segunda forma normal

Analisando teremos: O nome do produto depende do cdigo da vaga, porm no depende de Nro_ficha que a chave primria da tabela, portanto no est na segunda forma normal. Isto gera problemas com a manuteno dos dados, pois se houver alterao 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 Cdigo_vaga e vaga e na tabela Vaga manteremos somente os atributos Nro_ficha, cdigo_vaga, quant, valor_unit e subtotal. Veja o resultado abaixo:

Codigo-vaga

Vaga Imprensa Diretoria Empresarial Funcionrios

Tabela na segunda forma normal Nro_ficha Codigo_vaga Quant Valor_unit Subtotal

Tabela na 2 forma normal Conforme visto na Primeira forma normal, quando aplicamos normalizao comum gerar novas tabelas a fim de satisfazer as formas normais que esto sendo aplicadas. Passo 3

Uma tabela est na Terceira Forma Normal 3FN se ela estiver na 2FN e se nenhuma coluna no-chave depender de outra coluna no-chave. Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equao de outros campos da mesma tabela. Procedimentos:

a) Identificar todos os atributos que so funcionalmente dependentes de outros atributos no chave;

b) Remov-los.

A chave primria da nova entidade ser o atributo do qual os atributos removidos so funcionalmente dependentes. Exemplo de normalizao na terceira forma normal

Considere a tabela abaixo: Nro_ficha Codigo_vaga Quant Valor_unit Subtotal

Tabela no est na terceira forma normal Considerando ainda a nossa tabela Vaga, veremos que a mesma no est na terceira forma normal, pois o subtotal o resultado da multiplicao Quant X Valor_unit, desta forma a coluna subtotal depende de outras colunas no-chave. Para normalizar esta tabela na terceira forma normal teremos de eliminar a coluna subtotal, como no exemplo a seguir: Nro_ficha Codigo_vaga Quant Valor_unit

Tabela na terceira forma normal

Passo 4 Relatrio

Aprendemos nesta etapa, a desenvolver a organizao de entidades no Banco de Dados baseando nas regras de normalizao, fazendo com que minimize a duplicidade dos dados e mantenha as devidas dependncias das informaes nas vrias entidades do Banco de Dados. A proposta dessa etapa transformar tuplas no normalizadas em tuplas na 3 Forma Normal (3FN). Passamos ai, a transformar as tuplas no normalizadas das entidades propostas, passando para a 1 Forma Normal (1FN), e conceituando-as para melhor entendimento de normalizao, j tnhamos as tuplas na 1 Forma Normal, a equipe seguiu o prximo passo e colocamos na 2 Forma Normal (2FN). J o prximo passo era coloc-las na 3 Forma Normal, atravs de conhecimentos extrados de livros e apostilas, podemos enfim deixar bem claro, o que normalizao e de como faremos, para normalizar um Banco de Dados.

Etapa 5 Passo 1 Nro_ficha(FK) Nome_proprietario(FK) Endereo 1 2 3 4 5 6 7 8 9 10 Joo Mariana Antnio Stela Joaquim Marlene Gil Pedro Matheus Cludio Quadra X Quadra YZ Quadra Z Quadra W Quadra G Quadra XY Quadra S Quadra X Quadra E Quadra Z Saldo 125 224 52 210 15 7 66 85 199 59 Cod_vaga 1.001 1.002 1.001 1.002 1.003 1.004 1.001 1.002 1.003 1.004

m condio de seleo;

pode envolver operadores de comparao (=, , , , ); pode combinar condies usando-

Relao Cliente cliente (nro_ficha, nome_proprietario, endereo, saldo, cod_vaga) Nro_ficha 1 2 3 Nome_proprietario Endereo Joo Mariana Antnio Quadra X Quadra YZ Quadra Z Saldo 125 224 52 Cod_vaga 1.001 1.002 1.001

rietrio de nmero 02.

Relao Resultado cliente (nro_ficha, nome_proprietario, endereo, saldo, cod_vaga) Nro_ficha 1 Nome_proprietario Endereo Joo Quadra X Saldo 125 Cod_vaga 1.001

Grau: Mesmo grau da relao argumento

Nmero de tuplas: menor ou igual ao nmero de tuplas da relao argumento.

argumento, sem duplicaes:

lista_atributos ( relao argumento )

Lista de atributos; Os atributos so separados por vrgula.

Relao; Resultado de alguma operao de lgebra relacional.

Nro_ficha 1 2 3

Nome_proprietario Joo Mariana Antnio Nmero de tuplas: menor ou igual ao nmero de tuplas da relao argumento.

Grau: nmero de atributos listados em lista_atributos

s.

Eliminao de repeties

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

Nro_ficha Nro_vaga

12

C015 L002 S021

as tuplas pertencentes a R quanto a S:

Etapa 6 em R que fazem referncia a todos os valores de um atributo S;

m atributo

ficha_vaga Nro_ficha 9 1 1 4 5 8

Nro_vaga 66 04

pedido_pea pea Nro_ficha 1

Nro_vaga 12 04 66 03 11 04

Diviso:utilizada para consultas que incluam o termo para todos ou em todos

tuplas pertencentes a R que no pertencem a S:

Relao argumento 1 Relaes Estacionamento e Vaga

Estacionamento (nro_ficha; CPF_proprietrio; telefone_com; telefone_res; telefone_cel; email.

nome_proprietrio;

Nro_ficha 1 2 3 4

CPF_proprietario 000,000,000-01 000,000,000-02 000,000,000-03 000,000,000-04

Nome_proprietario Joo Mariana Antnio Stela

telefone 9999-9999 3222-2525 4004-0001 3222-5050 4004-2662 9999-9595 4004-6565 92926014

e-mail joo@joao.com.br mariana@mariana.com.br antonio@antonio.com.br stela@stela.com.br

Vaga (nro_vaga; placa_veiculo; modelo_veiculo; cor_veiculo; tipo_veiculo; ano_veiculo) Nro_vaga C001 E003 Placa_veiculo Modelo_veiculo Cor_veiculo JDF-5151 KBJ-2121 Corsa Hillux Azul Preta Tipo_veiculo Chevrolet Toyota Ano_veiculo 2010/2011 2010

Relao argumento 1

Estacionamento (nro_ficha; CPF_proprietrio; nome_proprietrio; nro_vaga; cod_vaga

Nro_ficha 1 2 3 4

CPF_proprietario 000,000,000-01 000,000,000-02 000,000,000-03 000,000,000-04

Nome_proprietario Joo Mariana Antnio Stela

nro_vaga C001 L005 H012 A021

cod_vaga 1.001 1.002 1.001 1.002

Vaga (cod_vaga; nro_ficha ; nome_proprietario. cod_vaga 1.001 1.004 nro_ficha 01 10 Nome_proprietario Joo Cludio

Estacionamento

Vaga

Nro_ficha 1 2 3 4

Nome_proprietario Joo Mariana Antnio Stela

endereo Quadra X Quadra YZ Quadra Z Quadra W

nro_vaga C001 L005 H012 A021

cod_vaga 1.001 1.002 1.001 1.002

Grau: nmero de atributos diferentes de estacionamento e de vagas + (nmero de atributos comuns)

Nmero de tuplas: entre zero e (nmero de tuplas de estacionamento * nmero de tuplas de cdigo da vaga

Passo 4 Relatrio

Nesta nova etapa fora construdo mecanismos de pesquisas capazes de manipular dados existentes em banco de dados. Criamos nesta etapa, diversas operaes de lgebra relacional que sejam aplicveis em banco de dados, utilizados como base do Modelo Relacional. Desenvolvemos atividades de criao de tuplas para cada relao (Tabela) existente, seguindo os conceitos tratados nas etapas anteriores. Fora criada uma operao, para cada operao de

entendimento da equipe, e conceituada de suas funes exercidas no Modelo Relacional Banco de Dados.