Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Ferreira da Silva RA: 3730701103 RA: 3770743484 RA: 4211797998 RA: 4211807488 RA: 4200063141
DESAFIO 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. Entidade: Estacionamento Atributos: nro_ficha, cpf_proprietario, nome_proprietario, telefone_com, telefone_res, telefone_cel, e-mail, (placa_veiculo, modelo_veiculo, cor_veiculo, tipo_veiculo, ano_veiculo) Entidade: Vaga Atributos: (nro_vaga, placa_veiculo, modelo_veiculo, cor_veiculo,
tipo_veiculo, ano_veiculo) Representao da estrutura da entidade: - Todos os atributos sublinhados so atributos chave. - Todos os atributos que estiverem entre parnteses, sero atributos repetitivos. Sua equipe de trabalho (consultoria contratada) dever ser composta com at 4 alunos, e essa entregar, ao final do desafio, sua proposta de modelo de dados.
Objetivo do Desafio: Elaborar um modelo de dados para o sistema de informao para controle de um estacionamento.
ETAPA 01
Passo 1 (Aluno)
Ler o artigo o captulo 1.1 Modelos de Dados da apostila Introduo Banco de Dados de Osvaldo Kotaro Takai, Isabel Cristina Italiano e Joo Eduardo Ferreira. 2005. Disponvel em:<https://docs.google.com/a/aedu.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B 9e1nJ9U5ACjZWMyN2ViZjYtYWMxMS00OTE4LWIwYzItNTc0ZGU0MjEyOTI2&hl=en _US>. Acesso em: 12 abr. 2012. Fazer tambm uma pesquisa na internet para conhecer os principais softwares de gerenciamento de Banco de Dados. Entre eles: <http://www.postgresql.org> e:
Passo 2 (Equipe) Desenvolver um comparativo entre a utilizao de arquivos convencionais (arquivo texto, por exemplo) e a utilizao de um SGBD (Sistema Gerenciador de Banco de Dados) para armazenamento de dados. Nesse comparativo essencial o apontamento de vantagens e desvantagens, bem como a aplicao de ambos os mtodos em uma operao empresarial, por exemplo, registro de vendas.
Antes dos Sistemas Gerenciadores de Banco de Dados (SGBD) 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.
Independncia de Dados-Programas
Abstrao de Dados
Mltiplas Vises
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.
Vantagens
Danos ao banco de dados afetam virtualmente a todos os programas; Elevados custos para a converso de
Integridade pode ser mantida; Segurana reforada; Requisitos contraditrios podem ser equilibrados; Padres poder ser reforados. Treinamento inicial necessrio aos programadores e usurios.
Sistema de Arquivos
A redundncia pode afetar a eficincia Existem vrias ferramentas e editores bons no mercado; para armazenamento, afetando a transmisso e o processamento, elevando os custos; Simplicidade tanto para usurio 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. Problemas de segurana. Anomalia de acesso concorrente; Dificuldade no acesso aos dados; Isolamento dos dados; Redundncia e inconsistncia dos dados;
Passo 3 (Equipe)
Modelagem de Dados representa um conjunto de requerimentos de informaes de negcio, uma parte importante do desenho de um sistema de informao.
Entre os principais objetivos da modelagem de dados temos a representao do ambiente observado, documentao e normalizao, fornecimento de processos de validao e observao dos processos de relacionamento entre objetos. As etapas envolvidas na construo de um modelo podem ser divididas em 3 modelos: Conceitual, lgico e fsico.
2. Citar os trs modelos de dados mais conhecidos descrevendo suas caractersticas e os softwares SGBD que utilizam cada um dos modelos.
A modelagem de dados normalmente atende a trs perspectivas: Modelagem Conceitual, Modelagem Lgica e a Modelagem Fsica. A modelagem conceitual usada como representao de alto nvel e considera exclusivamente o ponto de vista do usurio criador do dado, dentre os sistemas utilizados para facilitar o desenvolvimento desta etapa podemos citar o Visio e o DBDesigner. A modelagem lgica j leva em conta algumas limitaes e implementa reursos como adequao de padro e nomenclatura, para este os sistemas utilizados podem ser os mesmos da modelagem conceitual. A modelagem fsica demonstra como os dados so fisicamente armazenados, leva-se em conta as limitaes impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no modelo lgico, um exemplo de SGBD utilizado nesta etapa o SQL Server.
3. Com base na entidade proposta no enunciado do desafio e nos modelos de dados citados neste passo, definam qual modelo de dados dever ser utilizado na resoluo do desafio. Por qu? Justificar a resposta com apresentao de exemplo.
Modelo lgico pois, a primeira etapa j foi concluda com a definio das entidades e no momento no necessrio visar qual SGBD ser utilizado. A necessidade atual definir as chaves primrias, estrangeiras e seus respectivos relacionamentos, assim como o tipo de cada atributo, como exemplo ser necessrio haver um relacionamento entre a entidade estacionamento e a entidade vaga pois, no mesmo estacionamento existem varias vagas.
4. Definir Esquema e Instncia em banco de dados, utilizando-se das entidades propostas no desafio para representar e exemplificar suas definies.
Esquema a definio das estruturas que compem o banco de dados, espera-se que o esquema ir sobrar nenhuma ou poucas alteraes depois de implementado, o esquema independe dos dados a serem armazenados, como por exemplo podemos citar a entidade estacionamento e seus respectivos atributos, podendo haver relacionamento com outra entidade. Instancia a materializao do banco de dados composto pelas estruturas mais os dados armazenados, um retrato do banco de dados em um determinado momento, podemos ter a mesma estrutura reaplicada em vrios locais, cada uma com seu conjunto de dados, como exemplo podemos supor que j existem dados armazenados na entidades vaga, em determinado momento o estacionamento conter tais vagas preenchidas.
Passo 4 (Equipe)
Reunir as informaes levantadas nos passos anteriores e elaborem uma documentao com o nome de Relatrio 01 para utilizao nas prximas etapas. Entregar a documentao LFLXZ para apreciao.
Relatrio 01
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
Passo 1 (Equipe)
Criar um quadro para cada entidade proposta no desafio, identificando todos seus atributos com seus devidos tipos, chaves e relacionamentos esperados.
Passo 2 (Equipe)
1. Para a representao grfica do MER existem figuras que simbolizam cada um dos componentes do DER (Diagrama Entidade-Relacionamento). Demonstrar,
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.
Atributos Caractersticas das entidades, exemplos de atributos: Cdigo do Produto (entidade produto), Nome do Cliente (entidade cliente).
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.
2. Apresentar o(s) relacionamento(s) existente(s) entre as duas entidades identificando sua cardinalidade. Justificar o(s) relacionamento(s) apresentado(s) a partir do conceito de relacionamento e cardinalidade.
Passo3 (Equipe)
Desenvolver um DER completo (Entidade, Atributos, Chaves, Relacionamento, Cardinalidade, Smbolos etc.) partindo das entidades propostas no desafio e das informaes trabalhadas nos passos anteriores.
Passo 4 (Equipe)
Elaborar um relatrio (Relatrio 02) documentando as informaes levantadas nos passos anteriores, de forma a demonstrar a empresa o desenvolvimento da equipe. Entregar o relatrio ao cliente para apreciao na prxima reunio.
Relatrio 02
Na etapa anterior foi desenvolvida, a parte conceitual e uma breve introduo, do que seria desenvolvido, para o SGBD da Empresa LFLXZ Ltda., 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 (Equipe)
Descrever sobre cada um dos itens que compem a estrutura do Modelo Relacional, apontando suas funes e relacionando-os com as entidades propostas no desafio.
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).
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, quantos 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.
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-dados (dados acerca de dados).
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 Secundria: (FK - Foreign Key) a chave formada atravs de um relacionamento com a chave primria de outra tabela. Define um relacionamento entre as tabelas e podem ocorrer repetidas vezes. Caso a chave primria seja composta na origem, a chave estrangeira tambm o ser.
Passo 2 (Equipe)
Descrever qual(is) limitao(es) existem na execuo do processo de Mapeamento do modelo MER para o Relacional. Justificar sua resposta, utilizando-se tambm de exemplos, tendo em vista que possuem estruturas e caractersticas distintas.
Grandes partes das extenses 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 estas 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:
Passo 3 (Equipe)
Criar uma representao grfica que demonstre a converso do DER em Modelo Relacional descrevendo o processo passo a passo. Ao final, apresentar, em apenas um pargrafo, a opinio da equipe quanto ao modelo mais adequado, no ponto de vista de facilidade de compreenso da modelagem e estrutura funcional.
Modelo DER
Modelo Relacional
Passo 4 (Equipe)
Elaborar um relatrio (Relatrio 03) documentando as informaes levantadas nos passos anteriores, de forma a demonstrar a empresa o desenvolvimento da equipe. Entregar o relatrio ao cliente para apreciao na prxima reunio.
Relatrio 03
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 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 a passo. Apresentando sempre o ponto de vista na facilidade de compreenso da modelagem e estrutura funcional, por parte da equipe.
Etapa 4
Passo 1 (Equipe) Transformar as tuplas no normalizadas das entidades propostas, passando-as para a 1 Forma Normal (1FN). Explicar a ao da equipe baseando e citando a qual conceito se enquadra a aplicao da 1FN.
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 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 1 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 1 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 0001
Nome_proprietario Jos
Telefone 99999-0099
0002
Maria
98888-0088 4121-2112
Rua Oliveira, 32 Santo Andr 09700-000 Avenida da Paz, 1000 So Caetano 20201-200
0003
Joo
97000-6512 4234-2020
Analisando teremos:
Todos os clientes possuem Rua, CEP e Bairro, e essas informaes esto na mesma clula da tabela, logo ela no est na 1 forma normal. Para normalizar, deveremos colocar cada informao em uma coluna diferente, como no exemplo a seguir:
Nro_ficha 0001
Nome_proprietario Jos
Telefone
Rua
CEP 12345-567
0002
Maria
09700-000
0003
Joo
20201-200
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 0001
Nome_proprietario Jos
Cidade So Bernardo
CEP 12345-567
0002 0003
Maria Joo
09700-000 20201-200
Tabela na 1 forma normal Nro_ficha 0001 0002 0002 0003 0003 Telefone 99999-0099 98888-0088 4121-2112 97000-6512 4234-2020
No exemplo acima foi gerado uma segunda entidade para que a primeira forma normal fosse satisfeita, contudo possvel manter a tabela original, admitindo-se valores duplos em uma mesma coluna, como exemplo o campo telefone ficaria assim: 11-5432-5678 e 11-35003500. Neste caso a tabela ficaria desnormalizada, mas muitos acabam preferindo assim, principalmente quando h poucos casos de repetio.
Passo 2 (Equipe) Fazer as atividades a seguir: 1. Agora, com as tuplas na 1FN, a equipe dever coloc-las na 2 Forma normal (2FN). Explicar a ao da equipe baseando e citando a qual conceito se enquadra a aplicao da 2FN.
Uma tabela est na 2 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.
Estacionamento Nro_ficha, Cdigo_vaga, Vaga, Quant, Valor_unit, Subtotal Agora a tabela com os dados: Nro_ficha 0005 0006 0007 0008 Cdigo_vaga 101 102 104 105 Vaga Executivo Funcionrio Visitante Avulso Quant 5 3 1 15 Valor_unit 300,00 150,00 200,00 50,00 Subtotal 1500,00 450,00 200,00 750,00
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:
Quant 5 3 1 15
Conforme visto na primeira forma normal, quando aplicamos normalizao comum gerar novas tabelas a fim de satisfazer as formas normais que esto sendo aplicadas.
2. Com as tuplas na 2FN, a equipe dever coloc-las, quando possvel, agora na 3 Forma Normal (3FN). Explicar a ao da equipe baseando e citando a qual conceito se enquadra a aplicao da 3FN.
Uma tabela est na 3 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 0005 0006 0007 0008 Cdigo_vaga 101 102 104 105 Quant 5 3 1 15 Valor_unit 300,00 150,00 200,00 50,00 Subtotal 1500,00 450,00 200,00 750,00
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:
Quant 5 3 1 15
Modelo Relacional
Passo 3 (Equipe)
Elaborar um relatrio (Relatrio 04) documentando o passo a passo do desenvolvimento da normalizao. Entregar o relatrio ao cliente para apreciao na prxima reunio.
Relatrio 04
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 (Equipe)
Criar 10 tuplas para cada relao (tabela) de forma que sigam os conceitos tratados anteriormente (chave primria/estrangeira, relacionamento, redundncia e integridade).
Proprietrio
Nro_ficha(PK)
Nome_proprietario
Endereo Quadra 1 Quadra 5 Quadra 8 Quadra 12 Quadra 9 Quadra 7 Quadra 3 Quadra 11 Quadra 13 Quadra 2
Telefone
1 2 3 4 5 6 7 8 9 10
Jos Maria Joo Emanuel Andr Willian Marcelo Roberto Lucas Ricardo
2111-4444 3232-5656 2324-2121 2134-5678 8765-9876 5678-0987 9876-6767 9998-5454 7655-3232 3341-0099
Veiculo
Placa_veiculo FER-2005 BMW-2003 FOX-2012 UNO-2002 CLI-2011 KAL-2010 CEL-2009 CLA-2009 FIS-2011 GOL-2012
Cor_veiculo Vermelho Preto Vermelho Prata Cinza Prata Prata Preto Branco Cinza
Ano_veiculo 2005 2003 2012 2002 2011 2010 2009 2009 2011 2012
Nro_ficha(FK) 1 2 3 4 5 6 7 8 9 10
Vaga
Cod_vaga Placa_veiculo (FK)
101 102 103 104 105 106 107 108 109 110
FER-2005 BMW-2003 FOX-2012 UNO-2002 CLI-2011 KAL-2010 CEL-2009 CLA-2009 FIS-2011 GOL-2012
Passo 2 (Equipe)
1. Criar uma operao de SELEO para cada relao existente no modelo criado e descrever que ao essa operao est realizando.
SELECT Nro_ficha, Nome_proprietario, Endereo, Telefone FROM Proprietario WHERE Nome_proprietario ='Maria'
Cada operao apresentada ir selecionar apenas as linhas que contenha a palavra que queira encontrar. Como, por exemplo, no caso na primeira seleo (
nome_proprietario=Maria(Proprietrio)) o smbolo mostrado (), sigma, representa a seleo ou restrio da linha que contenha o que esteja procurando, que no caso Maria que est na coluna nome_proprietario, e na tabela, e o resultado apresentado ser a linha que contenha as informaes de Maria: Exemplo:
Nro_ficha
Nome_proprietario
Endereo Quadra 5
Telefone
Maria
3232-5656
Projeo Produz uma nova relao contendo um subconjunto vertical da relao argumento, sem duplicaes:
A operao de projeo apresentada ir projetar apenas as colunas chamadas, por exemplo, na projeo p nome_proprietario (proprietrio) est projetando a coluna nome_proprietario da tabela, que ir ficar assim:
Exemplo:
Nome_proprietario
Jos Maria Joo Emanuel Andr Willian Marcelo Roberto Lucas Ricardo
3. Criar uma operao de UNIO para cada relao existente no modelo criado e descrever que ao essa operao est realizando. Unio Une duas relaes R e S compatveis em uma relao que contm todas as tuplas pertencentes a R, a S, ou a ambas (R e S):
SELECT NRO_FICHA, MOD_VEICULO FROM VEICULO WHERE TIPO_VEICULO='FERRARI' UNION SELECT NRO_FICHA, MOD_VEICULO FROM VEICULO WHERE TIPO_VEICULO='VW'
Nro_ficha 1 3 10
Mod_veiculo
4. Criar uma operao de INTERSEO para cada relao existente no modelo criado e descrever que ao essa operao est realizando.
Interseo Une duas relaes R e S compatveis em uma relao que contm todas as tuplas pertencentes a R quanto a S.
(e.nro_ficha(estacionamento)) (v.modelo_veiculo(vaga))
SELECT e.nro_ficha, v.modelo_veiculo FROM VAGA v, ESTACIONAMENTO e WHERE v.nro_ficha = e.nro_ficha AND v.tipo_veiculo = 'VW'
Essa operao mostra os valores que contm na primeira e na segunda tabela ao mesmo tempo. Que vai ser:
Nro_ficha 3 10
modelo_veiculo VW VW
Passo 3 (Equipe)
Elaborar um relatrio (Relatrio 05) documentando com as informaes trabalhadas nesta etapa do desafio. Entregar o relatrio ao cliente para apreciao na prxima reunio.
Relatrio 05
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 lgebra relacional, so eles:
Para cada operao, fora criado uma tabela para melhor entendimento da equipe, e conceituada de suas funes exercidas no Modelo Relacional a Banco de Dados.
Etapa 6
Passo 1 (Equipe) Fazer as atividades a seguir: 1. Criar uma operao de DIVISO para cada relao existente no modelo criado e descrever que ao essa operao est realizando.
Diviso Diviso de duas relaes R e S, todos os valores de um atributo em R que fazem referncia a todos os valores de um atributo S;
(p nro_vaga, placa_veiculo (VEICULO)) (p nro_vaga(VAGA)) A operao de diviso acima est procurando todos os veculos que esto ocupando as vagas do estacionamento. No caso como todas as vagas esto sendo ocupados por veculos de placas diferentes e estacionados em vagas distintas, a projeo ser a seguinte:
Placa_veiculo
FER-2005 BMW-2003 FOX-2012 UNO-2002 CLI-2011 KAL-2010 CEL-2009 CLA-2009 FIS-2011 GOL-2012
2. Criar uma operao de DIFERENA para cada relao existente no modelo criado e descrever que ao essa operao est realizando.
Diferena Une duas relaes R e S compatveis em uma relao que contm todas as tuplas pertencentes a R que no pertencem a S: (p placa_veiculo(VEICULO)) (p placa_veiculo(VAGA))
No ter resultado nenhum essa operao, pois a operao de diferena das duas tabelas produz como resultado uma tabela que contm as tuplas presentes na primeira tabela (VEICULO) que no constam na segunda (VAGA).
3. Criar uma operao de JUNO para cada relao existente no modelo criado e descrever que ao essa operao est realizando.
Juno Natural
Concatena tuplas relacionadas de duas relaes em tuplas nicas; Simplifica consultas que requerem produto cartesiano: Forma um produto cartesiano dos argumentos; Faz uma seleo forando igualdade sobre os atributos que aparecem em ambos
Nro_ficha
CPF_proprietario
Nome_proprietario
Nro_vaga C001 L005 H008 G012 A009 V007 C003 N011 A013 J002
Cod_vaga
1 2 3 4 5 6 7 8 9 10
000.000.000-01 000.000.000-02 000.000.000-03 000.000.000-04 000.000.000-04 000.000.000-06 000.000.000-07 000.000.000-08 000.000.000-09 000.000.000-10
Jos Maria Joo Emanuel Andr Willian Marcelo Roberto Lucas Ricardo
101 102 103 104 105 106 107 108 109 110
Cod_vaga
Nro_ficha
Nome_proprietario
101 102 103 104 105 106 107 108 109 110
1 2 3 4 5 6 7 8 9 10
Jos Maria Joo Emanuel Andr Willian Marcelo Roberto Lucas Ricardo
Jos Maria Joo Emanuel Andr Willian Marcelo Roberto Lucas Ricardo
101 102 103 104 105 106 107 108 109 110
Passo 2 (Equipe) Elaborar um relatrio (Relatrio 06) documentando as operaes desenvolvidas nos passos anteriores e a ao realizada por elas. Entregar o relatrio ao cliente em sua ltima reunio.
Relatrio 06
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 lgebra relacional, so eles:
Para cada operao, fora criado uma tabela para melhor entendimento da equipe, e conceituada de suas funes exercidas no Modelo Relacional a Banco de Dados.