1
Banco de Dados
UFGD
2
Banco de Dados
UFGD
4
Banco de Dados
UNILASALLE
30
Banco de Dados
UNIVAG
32
Banco de Dados
UMG
1
Banco de Dados
UFGD
1
Banco de Dados
UNILASALLE
1
Banco de Dados
UFGD
1
Banco de Dados
USP
2
Banco de Dados
CEUN-IMT
Texto de pré-visualização
por passageiro Cada corrida tem ao menos um passageiro que a solicita passageiro principal e que portanto determina qual será o número sequencial da corrida Os demais passageiros quando existirem são considerados passageiros caronistas O preço total da corrida é fixo mas o valor por passageiro é arbitrário Cada passageiro principal ou caronista pode pagar uma quantia até que o valor total da corrida esteja completo Todos os passageiros saem da mesma origem e vão para o mesmo destino Um mesmo passageiro pode pedir várias corridas desde que em horas e dias diferentes e que não esteja atualmente realizando uma corrida em qualquer condição Um atendente é vinculado ao suporte de cada corrida sendo que os passageiros podem enviar questionamentos identificados por um número sequencial por corrida e texto da pergunta ao atendente durante a corrida O atendente deve responder com um texto da resposta O sistema armazena o histórico de corridas e consequentemente dos atendimentos realizados Consultas a serem respondidas 1 Dado uma seguradora identificar quais são os veículos com seguros sob sua responsabilidade e listar as vigências das apólices 2 Dado um atendente descubra se ele já usou o serviço de corridas e quando 3 Listar quais foram os passageiros que nunca fizeram uma corrida 4 Dado um passageiro mostrar a quantidade de vezes onde ele foi o passageiro principal ou o caronista 5 Dada uma corrida listar todas as perguntas e respostas feitas ao atendente responsável 6 Listar todos os passageiros e o valor percentual pago por eles em corridas com mais de um passageiro 7 Listar todos os passageiros e mostrar a quantidade de vezes onde ele foi o passageiro principal ou o passageiro caronista 8 Duas perguntas que o grupo julgar relevante para os requisitos Pontos extras NÃO são obrigatórios Somente serão considerados os pontos extras APÓS o grupo responder os oito itens obrigatórios 9 Ponto extra 01 Grau de dificuldade Baixo Repita as perguntas 6 e 7 com os resultados por passageiros e por ano durante a última década 20202025 10 Ponto extra 02 Grau de dificuldade Sofisticado Dado o modelo relacional final e a implementação do modelo no Postgres o grupo vislumbra alguma possibilidade de consultar os dados com consultas diretamente em português e sem usar SQL explicitamente ou via ORM Como seria isso Ilustre com uma prova de conceito TRABALHO FINAL DE DISCIPLINA Avisos Importantes Trabalho vale 50 da Nota Final Trabalho a ser realizado em grupo Não compartilhem suas respostas Haverá verificação de cópia entre os trabalhos inclusive implementação Vocês podem ser os maiores prejudicados em casos de plágio Não deixem de enviar o relatório por email no prazo especificado em aula Especificação do Trabalho Implementar um projeto de banco de dados relacional desde a sua modelagem lógica até a sua efetiva implementação em um SGBD relacional passando necessariamente pelas etapas de i mapeamento entre os Modelos EntidadeRelacionamentoRelacional e ii normalização 1FN 2FN e 3FN O relatório entregue deve conter todos os passos da modelagem de acordo com o algoritmo de projeto de banco de dados discutido em aula e resumido na figura abaixo mínimo mundo conjunto de necessidades independe do SGBD esquema conceitual depende do SGBD esquema em linguagem de implementação análise de requisitos projeto conceitual mapeamento para modelo projeto físico Modelo Entidade Relacionamento MER Mapeamento MER para o Modelo Relacional Modelo Relacional A implementação das tabelas deve seguir a especificação padrão da linguagem SQL 2003 em diante Recomendase o uso do SGBD PostgreSQL Cada tabela gerada deve ser povoada com pelo menos 20 tuplas que podem ser geradas a partir de dados fictícios Os scripts de criação e povoamento das tabelas devem ser entregues junto com os relatórios Os comandos SQL para responder às consultas especificadas ao final do trabalho devem ser entregues como um script separado e também devem ser incluídas no relatório Os scripts entregues serão utilizados na avaliação do trabalho Requisitos do banco de dados Desejase projetar a base de dados de um sistema de transporte de passageiros que reservam suas viagens por celular e são atendidos por motoristas autônomos que efetivamente realizam o traslado corrida em seus veículos particulares Esse sistema tem por objetivo atender corridas longas intermunicipais Construa o modelo ER referente à base de dados A base de dados não deve conter redundância de dados O modelo ER deve ser representado com a notação vista nas aulas Não é permitido o uso de chaves artificiais no modelo ER Mapeie o modelo ER para o modelo relacional Normalize o modelo relacional mapeado É permitido o uso de chaves artificiais no modelo relacional desde que sejam apresentadas justificativas adequadas A base de dados deve incluir motoristas identificados por seus CPFs RG endereço data de nascimento número da CNH e conta corrente para pagamento bem como passageiros identificados por seus CPFs RG endereço data de nascimento e número do cartão de crédito Além deles devese registrar os atendentes que são identificados por seus CPFs RG endereço data de nascimento e formação escolar Motoristas e atendentes podem usar os serviços de transporte como passageiros Um atendente pode ser um motorista nas horas vagas Um ou mais veículos são associados a um motorista sendo que cada veículo deve ser identificado pelo seu número de RENAVAM data de compra marca modelo ano preço e característica que deve ser um valor entre econômico SUV luxo rural Uma seguradora é identificada por um CNPJ nome telefone e endereço postal Uma seguradora pode ser responsável por um ou mais seguros de veículos que são identificados por número e valor da apólice O sistema não armazena o histórico de apólices dos veículos logo no máximo apenas um único número de apólice por veículo aparece no sistema por vez Uma corrida é registrada como o serviço de um motorista para um ou vários passageiros sendo identificada por um número sequencial de corrida definido por passageiro endereço de destino data de início data de fim hora de início hora de fim valor total da corrida e preço da corrida Relatório de Trabalho Final Modelo EntidadeRelacionamento Mapeamento Inicial Pessoa cpf rg dtnasc enderecologradouro bairro numero cep municipio Motorista cpf rg dtnasc enderecologradouro bairro numero cep municipio cnh ccorrentenumconta agencia Passageiro cpf rg dtnasc enderecologradouro bairro numero cep municipio cartaocrednumcartao cvv dtvalidade Atendente cpf rg dtnasc enderecologradouro bairro numero cep municipio formescolar Seguradora CNPJ nome telefone endereçologradouro bairro numero cep municipio Seguro numseguro vlrapolice seguradora Veiculo renavam dtcompra marca modelo ano preco caracteristica Corrida codcorrida precopassag valortotal totalpago dtinicio dtfim hrinicio hrfim destinologradouro bairro numero cep municipio origemlogradouro bairro numero cep municipio PassageiroCorrida passageiro corrida tipo passageiro valorpago Suporte dtsuporte codsuporte Pergunta codperg hrresp hrperg txtperg txtresp Normalização para 1FN Uma forma normal é uma regra a ser atendida para otimizar a construção da tabela Uma tabela está na 1FN quando ela não contém tabelas aninhadas Assim os valores dos atributos se tornam atômicos e não se repetem diversas vezes Um exemplo disso seria no registro de endereço criando uma tabela separada e associando somente o código como chave estrangeira nas tabelas que havia o atributo composto endereço Normalização para 2FN Já para uma tabela encontrarse na segunda forma normal 2FN além de estar na primeira forma normal cada coluna não chave deve depender da chave primária por completo Neste projeto foi verificado que as tabelas estão na 1FN e as que possuem apenas uma coluna como chave primária não contêm dependências parciais visto que nestas tabelas será impossível uma coluna depender de parte da chave primária se ela é única e não possui partes Não foram encontradas irregularidades para ajuste Normalização para 3FN Uma tabela encontrase na 3FN quando além de estar na 2FN toda coluna não chave depende diretamente de chave primária Para atender a esta etapa de normalização foram criadas as tabelas conta e cartão para que suas informações dependam da chave primária diretamente Ainda do modelo relacional para o diagrama foram adicionadas as tabelas geradas a partir de relacionamentos nn e também houve a apresentação das chaves primárias e estrangeiras Mapeamento atualizado Pessoa cpf rg dtnasc endereco endereço codendereco da tabela endereco Motorista cpf ccorrente cpf cpf da tabela pessoa ccorrente numconta da tabela conta Passageiro cpf cartaocred cpf cpf da tabela pessoa cartaocred numcartao da tabela cartão Atendente cpf formescolar cpf cpf da tabela pessoa Seguradora cnpj nome telefone endereco endereco codendereco da tabela endereco Seguro numseguro vlrapolice veiculo seguradora veiculo renavam da tabela veiculo seguradora cnpj da tabela seguradora Veiculo renavam dtcompra marca modelo ano preco caracteristicas proprietario proprietario cpf da tabela motorista Corrida codcorrida origem destino dtinicio dtfim hrinicio hrfim valortotal precopassag totalpago motorista origem codendereco da tabela endereco destino codendereco da tabela endereco motorista cpf da tabela motorista PassageiroCorrida passageiro corrida tipopassageiro valorpago Passageiro cpf da tabela passageiro corrida codcorrida da tabela corrida Suporte corrida atendente dtsuporte corrida codcorrida da tabela corrida atendente cpf da tabela atendente Pergunta codpergunta passageiro suporte txtperg txtresp hrperg hrresp Passageiro cpf da tabela passageiro suporte corrida da tabela suporte Diagrama EntidadeRelacionamento HIRING NOW Were hiring for our YANMAR School Excellence Program YSEP YSEP is designed to develop and fasttrack the careers of talented individuals by offering experience and training across our Sales Marketing Operations Finance teams We are looking for individuals who Are currently studying in a related field Are enthusiastic and driven Can work in a team environment Want to learn and develop in their career Interested Please email your CV to yantamyanmarcomau by Friday 22nd September 2023 For more details visit the careers page at wwwyanmarcomau Yanmar Australia Pty Ltd 1014 Reliance Drive Tuggerah NSW 2259 Phone 61 2 4351 2933 wwwyanmarcomau Yanmar School Excellence Program YSEP logo
1
Banco de Dados
UFGD
2
Banco de Dados
UFGD
4
Banco de Dados
UNILASALLE
30
Banco de Dados
UNIVAG
32
Banco de Dados
UMG
1
Banco de Dados
UFGD
1
Banco de Dados
UNILASALLE
1
Banco de Dados
UFGD
1
Banco de Dados
USP
2
Banco de Dados
CEUN-IMT
Texto de pré-visualização
por passageiro Cada corrida tem ao menos um passageiro que a solicita passageiro principal e que portanto determina qual será o número sequencial da corrida Os demais passageiros quando existirem são considerados passageiros caronistas O preço total da corrida é fixo mas o valor por passageiro é arbitrário Cada passageiro principal ou caronista pode pagar uma quantia até que o valor total da corrida esteja completo Todos os passageiros saem da mesma origem e vão para o mesmo destino Um mesmo passageiro pode pedir várias corridas desde que em horas e dias diferentes e que não esteja atualmente realizando uma corrida em qualquer condição Um atendente é vinculado ao suporte de cada corrida sendo que os passageiros podem enviar questionamentos identificados por um número sequencial por corrida e texto da pergunta ao atendente durante a corrida O atendente deve responder com um texto da resposta O sistema armazena o histórico de corridas e consequentemente dos atendimentos realizados Consultas a serem respondidas 1 Dado uma seguradora identificar quais são os veículos com seguros sob sua responsabilidade e listar as vigências das apólices 2 Dado um atendente descubra se ele já usou o serviço de corridas e quando 3 Listar quais foram os passageiros que nunca fizeram uma corrida 4 Dado um passageiro mostrar a quantidade de vezes onde ele foi o passageiro principal ou o caronista 5 Dada uma corrida listar todas as perguntas e respostas feitas ao atendente responsável 6 Listar todos os passageiros e o valor percentual pago por eles em corridas com mais de um passageiro 7 Listar todos os passageiros e mostrar a quantidade de vezes onde ele foi o passageiro principal ou o passageiro caronista 8 Duas perguntas que o grupo julgar relevante para os requisitos Pontos extras NÃO são obrigatórios Somente serão considerados os pontos extras APÓS o grupo responder os oito itens obrigatórios 9 Ponto extra 01 Grau de dificuldade Baixo Repita as perguntas 6 e 7 com os resultados por passageiros e por ano durante a última década 20202025 10 Ponto extra 02 Grau de dificuldade Sofisticado Dado o modelo relacional final e a implementação do modelo no Postgres o grupo vislumbra alguma possibilidade de consultar os dados com consultas diretamente em português e sem usar SQL explicitamente ou via ORM Como seria isso Ilustre com uma prova de conceito TRABALHO FINAL DE DISCIPLINA Avisos Importantes Trabalho vale 50 da Nota Final Trabalho a ser realizado em grupo Não compartilhem suas respostas Haverá verificação de cópia entre os trabalhos inclusive implementação Vocês podem ser os maiores prejudicados em casos de plágio Não deixem de enviar o relatório por email no prazo especificado em aula Especificação do Trabalho Implementar um projeto de banco de dados relacional desde a sua modelagem lógica até a sua efetiva implementação em um SGBD relacional passando necessariamente pelas etapas de i mapeamento entre os Modelos EntidadeRelacionamentoRelacional e ii normalização 1FN 2FN e 3FN O relatório entregue deve conter todos os passos da modelagem de acordo com o algoritmo de projeto de banco de dados discutido em aula e resumido na figura abaixo mínimo mundo conjunto de necessidades independe do SGBD esquema conceitual depende do SGBD esquema em linguagem de implementação análise de requisitos projeto conceitual mapeamento para modelo projeto físico Modelo Entidade Relacionamento MER Mapeamento MER para o Modelo Relacional Modelo Relacional A implementação das tabelas deve seguir a especificação padrão da linguagem SQL 2003 em diante Recomendase o uso do SGBD PostgreSQL Cada tabela gerada deve ser povoada com pelo menos 20 tuplas que podem ser geradas a partir de dados fictícios Os scripts de criação e povoamento das tabelas devem ser entregues junto com os relatórios Os comandos SQL para responder às consultas especificadas ao final do trabalho devem ser entregues como um script separado e também devem ser incluídas no relatório Os scripts entregues serão utilizados na avaliação do trabalho Requisitos do banco de dados Desejase projetar a base de dados de um sistema de transporte de passageiros que reservam suas viagens por celular e são atendidos por motoristas autônomos que efetivamente realizam o traslado corrida em seus veículos particulares Esse sistema tem por objetivo atender corridas longas intermunicipais Construa o modelo ER referente à base de dados A base de dados não deve conter redundância de dados O modelo ER deve ser representado com a notação vista nas aulas Não é permitido o uso de chaves artificiais no modelo ER Mapeie o modelo ER para o modelo relacional Normalize o modelo relacional mapeado É permitido o uso de chaves artificiais no modelo relacional desde que sejam apresentadas justificativas adequadas A base de dados deve incluir motoristas identificados por seus CPFs RG endereço data de nascimento número da CNH e conta corrente para pagamento bem como passageiros identificados por seus CPFs RG endereço data de nascimento e número do cartão de crédito Além deles devese registrar os atendentes que são identificados por seus CPFs RG endereço data de nascimento e formação escolar Motoristas e atendentes podem usar os serviços de transporte como passageiros Um atendente pode ser um motorista nas horas vagas Um ou mais veículos são associados a um motorista sendo que cada veículo deve ser identificado pelo seu número de RENAVAM data de compra marca modelo ano preço e característica que deve ser um valor entre econômico SUV luxo rural Uma seguradora é identificada por um CNPJ nome telefone e endereço postal Uma seguradora pode ser responsável por um ou mais seguros de veículos que são identificados por número e valor da apólice O sistema não armazena o histórico de apólices dos veículos logo no máximo apenas um único número de apólice por veículo aparece no sistema por vez Uma corrida é registrada como o serviço de um motorista para um ou vários passageiros sendo identificada por um número sequencial de corrida definido por passageiro endereço de destino data de início data de fim hora de início hora de fim valor total da corrida e preço da corrida Relatório de Trabalho Final Modelo EntidadeRelacionamento Mapeamento Inicial Pessoa cpf rg dtnasc enderecologradouro bairro numero cep municipio Motorista cpf rg dtnasc enderecologradouro bairro numero cep municipio cnh ccorrentenumconta agencia Passageiro cpf rg dtnasc enderecologradouro bairro numero cep municipio cartaocrednumcartao cvv dtvalidade Atendente cpf rg dtnasc enderecologradouro bairro numero cep municipio formescolar Seguradora CNPJ nome telefone endereçologradouro bairro numero cep municipio Seguro numseguro vlrapolice seguradora Veiculo renavam dtcompra marca modelo ano preco caracteristica Corrida codcorrida precopassag valortotal totalpago dtinicio dtfim hrinicio hrfim destinologradouro bairro numero cep municipio origemlogradouro bairro numero cep municipio PassageiroCorrida passageiro corrida tipo passageiro valorpago Suporte dtsuporte codsuporte Pergunta codperg hrresp hrperg txtperg txtresp Normalização para 1FN Uma forma normal é uma regra a ser atendida para otimizar a construção da tabela Uma tabela está na 1FN quando ela não contém tabelas aninhadas Assim os valores dos atributos se tornam atômicos e não se repetem diversas vezes Um exemplo disso seria no registro de endereço criando uma tabela separada e associando somente o código como chave estrangeira nas tabelas que havia o atributo composto endereço Normalização para 2FN Já para uma tabela encontrarse na segunda forma normal 2FN além de estar na primeira forma normal cada coluna não chave deve depender da chave primária por completo Neste projeto foi verificado que as tabelas estão na 1FN e as que possuem apenas uma coluna como chave primária não contêm dependências parciais visto que nestas tabelas será impossível uma coluna depender de parte da chave primária se ela é única e não possui partes Não foram encontradas irregularidades para ajuste Normalização para 3FN Uma tabela encontrase na 3FN quando além de estar na 2FN toda coluna não chave depende diretamente de chave primária Para atender a esta etapa de normalização foram criadas as tabelas conta e cartão para que suas informações dependam da chave primária diretamente Ainda do modelo relacional para o diagrama foram adicionadas as tabelas geradas a partir de relacionamentos nn e também houve a apresentação das chaves primárias e estrangeiras Mapeamento atualizado Pessoa cpf rg dtnasc endereco endereço codendereco da tabela endereco Motorista cpf ccorrente cpf cpf da tabela pessoa ccorrente numconta da tabela conta Passageiro cpf cartaocred cpf cpf da tabela pessoa cartaocred numcartao da tabela cartão Atendente cpf formescolar cpf cpf da tabela pessoa Seguradora cnpj nome telefone endereco endereco codendereco da tabela endereco Seguro numseguro vlrapolice veiculo seguradora veiculo renavam da tabela veiculo seguradora cnpj da tabela seguradora Veiculo renavam dtcompra marca modelo ano preco caracteristicas proprietario proprietario cpf da tabela motorista Corrida codcorrida origem destino dtinicio dtfim hrinicio hrfim valortotal precopassag totalpago motorista origem codendereco da tabela endereco destino codendereco da tabela endereco motorista cpf da tabela motorista PassageiroCorrida passageiro corrida tipopassageiro valorpago Passageiro cpf da tabela passageiro corrida codcorrida da tabela corrida Suporte corrida atendente dtsuporte corrida codcorrida da tabela corrida atendente cpf da tabela atendente Pergunta codpergunta passageiro suporte txtperg txtresp hrperg hrresp Passageiro cpf da tabela passageiro suporte corrida da tabela suporte Diagrama EntidadeRelacionamento HIRING NOW Were hiring for our YANMAR School Excellence Program YSEP YSEP is designed to develop and fasttrack the careers of talented individuals by offering experience and training across our Sales Marketing Operations Finance teams We are looking for individuals who Are currently studying in a related field Are enthusiastic and driven Can work in a team environment Want to learn and develop in their career Interested Please email your CV to yantamyanmarcomau by Friday 22nd September 2023 For more details visit the careers page at wwwyanmarcomau Yanmar Australia Pty Ltd 1014 Reliance Drive Tuggerah NSW 2259 Phone 61 2 4351 2933 wwwyanmarcomau Yanmar School Excellence Program YSEP logo