Departamento de Engenharia de Eletrónica e Telecomunicações e de Computadores Licenciatura em Engenharia Informática e de Computadores

Transcrição

1 Departamento de Engenharia de Eletrónica e Telecomunicações e de Computadores Licenciatura em Engenharia Informática e de Computadores Trabalho prático (Fases 1,2 e 3) Sistemas de Informação I Semestre de Verão 2016/2017 Versão 1.00 Docentes: Afonso Remédios e Nuno Leite

2

3 Planeamento As datas importantes a recordar são: Publicação do enunciado: 27 de março de 2017 Entrega intermédia (Fase 1): Entrega intermédia (Fase 2): Entrega intermédia (Fase 3): 17 de abril de 2017 (3 semanas) 12 de junho de 2017 (8 semanas) 3 de julho de 2017 (3 semanas) Cada entrega intermédia deve apresentar o relatório e código (se houver) referentes exclusivamente a essa fase. O relatório deve ser conciso e apresentar a justificação de todas as decisões tomadas. Deve indicar a composição do grupo, a unidade curricular e a fase do trabalho que relata. Caso tenha adendas e/ou correções a fazer a modelos já entregues, deve indicá-las de forma explícita no relatório seguinte.

4

5 Sistemas de Informação I Primeira fase do trabalho prático 2016/2017 Verão Objectivos de aprendizagem No final da primeira fase do trabalho, os alunos devem ser capazes de: Identificar corretamente as entidades relevantes para os requisitos pretendidos; Identificar corretamente os atributos chave para cada uma das entidades; Identificar corretamente os atributos descritivos de cada uma das entidades; Identificar o domínio de cada atributo; Identificar corretamente as associações entre entidades, incluindo respetivas obrigatoriedades e cardinalidades; Desenvolver um modelo Entidade-Associação (EA) que cumpra os requisitos enunciados, capturando o maior número de restrições possível; Identificar os requisitos e restrições que não conseguem ser garantidos no modelo EA. Enunciado do trabalho (Documento de requisitos do sistema) Em Portugal existem várias empresas de aluguer de barcos. Uma Empresa possui locadoras de barcos nos diferentes portos de Portugal e a associação das empresas de aluguer pretende criar um sistema de informação centralizado que auxilie na gestão dos serviços destas empresas. A empresa tem um Número de Identificação Fiscal (NIF) único para todas as locadoras, uma frota e a morada da sede. Cada locadora é identificada por um código único dentro da empresa, pelo nome do porto onde está instalada, pelo responsável local, pela frota que nesse momento está ancorada no seu porto, pelo número de telefone e pela morada para correspondência. O responsável é identificado pelo cartão de identificação (Bilhete de Identidade BI, ou o cartão de cidadão) e caracterizado pelo nome, pelo número de telefone para contacto e pela morada de residência. Na empresa existem vários funcionários que podem prestar serviço numa locadora; os funcionários são caracterizados da mesma forma que o responsável mas com uma função diferente; as funções permitidas são responsável, administrativo, moço de doca e monitor; estas funções não são exclusivas. A frota tem embarcações de quatro categorias: gaivotas, a remos, a motor, e à vela, todas caracterizadas por um código de matrícula único a nível nacional, por um nome (único no sistema) e por um estado: livre, reservado, alugado, fora de serviço; à exceção do estado livre todos os outros têm um período temporal associado. O período temporal tem sempre uma hora e uma data de início (para gaivotas e barco a remos) ou uma data de início (para barco a motor e barco à vela), tendo o aluguer

6 uma hora e data de fim para o primeiro caso (gaivotas e barco a remos, que não podem ser reservados, apenas alugados), e tendo o aluguer e reserva uma data de fim nos restantes (barco a motor e barco à vela). As duas primeiras categorias têm um preço hora associado. Associado às duas últimas categorias existem um preço por dia. A reserva tem sempre um funcionário administrativo responsável. A hora e data finais são automaticamente preenchidas pelo sistema quando o aluguer/reserva terminam. A empresa tem uma carteira de clientes, que podem alugar barcos em qualquer uma das suas locadoras. Um cliente é identificado por um dos seus cartões de identificação (BI, NIF, ou passaporte), pelo nome, pela morada, pelo número de telefone/telemóvel e, eventualmente, pelo número da carta de marinheiro. Associado a uma reserva ou a um aluguer podem estar outros artefactos (skis, motas de água, canoas, frigoríficos, etc.). Um artefacto é descrito por um código único dentro da locadora e por um nome; quando não está alugado encontra-se no estado livre; tem um preço hora ou um preço por dia consoante o tipo de embarcação a que está associado. Todas as moradas têm um campo para o nome da rua, outro para o número de polícia, outro para o andar se existir e ainda um campo para o código postal e outro para a localidade. Cada locadora pode ter um conjunto de atividades para os clientes (por exemplo, visitas turísticas, formações, etc.). Cada atividade é paga, devendo ficar registado o custo por pessoa no sistema. Além disso, cada atividade é caracterizada por uma data de realização, um nome, uma descrição e a lotação máxima. Associado a uma atividade estão um ou mais moços de doca e monitores que organizam e levam a cabo a atividade. Uma atividade pode envolver múltiplas embarcações. Não existem duas atividades com o mesmo nome na mesma data dentro de uma locadora. Deve ser possível obter do sistema as atividades que cada cliente requereu, assim como o número de participantes nelas envolvidos. Resultados pretendidos Tendo em conta os objetivos de aprendizagem, deverão ser produzidos os seguintes resultados: 1. O modelo de dados concetual, incluindo o diagrama entidade-associação, a descrição das entidades, os seus atributos e associações; 2. Descrição das regras de negócio aplicáveis, para além das que são implícitas no resultado do ponto 1; 3. Informação complementar fornecida pelo cliente e que seja importante para clarificar aspetos do domínio de aplicação; 4. Discussão de alternativas de modelação e razões da escolha da solução apresentada no ponto 1. Data limite para entrega: 17 de abril de 2017 até às 23:59. A entrega deve incluir um relatório e o modelo EA, enviados de forma eletrónica. Nota: Sugere-se que o relatório seja organizado de acordo com os pontos anteriores. Deve ser possível aferir cada um dos objetivos de aprendizagem no material que entregar.

7 Sistemas de Informação I Segunda fase do trabalho prático 2016/2017 Verão Objectivos de aprendizagem No final da segunda fase do trabalho, os alunos devem ser capazes de: Aplicar corretamente as regras de passagem de EA para relacional; Identificar as dependências funcionais existentes no sistema; Determinar as chaves primárias, alternativas e estrangeiras; Garantir que não existem perdas de dependências funcionais; Desenvolver modelos relacionais normalizados até à 3NF; Utilizar corretamente SQL/DDL para criar as tabelas num SGDB; Escolher corretamente os tipos de dados para cada atributo; Garantir as restrições de integridade identificadas, não esquecendo as que resultam da passagem do EA para o relacional, enumerando aquelas que têm de ser garantidas pelas aplicações; Utilizar corretamente a álgebra relacional, com os seus vários operadores, para expressar interrogações sobre um modelo relacional; Utilizar corretamente a ferramenta ARIs (processador de Álgebra Relacional) para validar as expressões produzidas em álgebra relacional; Inserir dados em lote através da cláusula SQL INSERT, garantindo que as restrições de integridade são cumpridas; Garantir a atomicidade de instruções, utilizando processamento transacional; Utilizar corretamente as cláusulas INNER JOIN e OUTER JOIN; Utilizar correctamente sub-interrogações correlacionadas; Utilizar correctamente funções de agregação; Utilizar correctamente a cláusula HAVING; Utilizar correctamente a cláusula ORDER BY; Utilizar correctamente o termo DISTINCT; Utilizar correctamente os predicados IN e EXISTS.

8 Enunciado do trabalho (2ª fase) Após a realização da 1ª fase do trabalho, os alunos têm agora a oportunidade de refletir sobre o modelo que apresentaram. Após realizarem as correções e alterações que considerem necessárias e/ou relevantes, devem prosseguir para a passagem do modelo concetual para o modelo lógico. O modelo lógico a apresentar será o modelo relacional e deverá ser acompanhado de todas as restrições que não são garantidas pelo modelo, incluindo aquelas já apresentadas em conjunto com o modelo concetual. Após a obtenção do modelo lógico, os alunos deverão fazer o levantamento do conjunto de dependências funcionais que julguem adequadas para o domínio de aplicação e, com base nelas, verificar a normalização do modelo lógico, fazendo-lhe as alterações necessárias para garantir a sua normalização até à 3ª forma normal (3NF). Os alunos poderão ainda decidir fazer alterações, simplificações ou otimizações ao modelo, desde que devidamente indicadas e fundamentadas. Com base no modelo lógico obtido, deverá ser construído em SQL, o modelo físico do sistema, contemplando todas as restrições que consigam garantir na forma declarativa. Nota: Deverão preencher a base de dados com informação que permita em seguida realizar interrogações que apresentem resultados pertinentes. Na etapa de preenchimento da base de dados, os alunos deverão ter particular atenção ao cumprimento das restrições de integridade, utilizando de forma adequada o controlo transacional. Resultados pretendidos Tendo em conta os objetivos de aprendizagem, deverão ser produzidos os seguintes resultados: 1. O modelo de dados concetual final, incluindo diagrama entidade-associação, descrição das entidades, seus atributos e associações, descrição final de todas as regras de negócio aplicáveis. 2. O modelo de dados lógico, obtido por transformação do modelo concetual apresentado. Devem ser indicadas, de forma clara, todas as chaves estrangeiras, as chaves candidatas e primárias, incluindo todas as restrições que não são garantidas pelo modelo lógico obtido e que derivem da passagem do modelo concetual para o modelo lógico, nomeadamente as obrigatoriedades. Devem também ser apresentadas as dependências funcionais associadas aos atributos do modelo lógico. 3. A análise da normalização do modelo lógico produzido na alínea 2, tendo em conta o conjunto de dependências funcionais. Deverá ser garantida a normalização até à terceira forma normal. Todas as simplificações e otimizações que forem realizadas ao modelo devem ser igualmente indicadas e justificadas. 4. Construção dum modelo físico simplificado do sistema, para testar o modelo usando a ferramenta ARIs. Este modelo físico deverá conter os atributos que representam as chaves estrangeiras. Nota: todos os atributos dos esquemas de relação produzidos deverão ter nomes distintos e começar com letra minúscula.

9 5. Construção do modelo físico do sistema, contemplando todas as restrições de integridade passíveis de ser garantidas de forma declarativa. Produza dois scripts SQL: um para a criação e outro para a destruição do modelo. 6. Criação de um script SQL para preencher o modelo físico. Os dados devem permitir validar todas as interrogações pedidas nesta fase do trabalho. Crie também um script SQL para apagar todos os dados existentes nas tabelas. 7. Considerando o esquema relacional obtido nesta fase, apresente as expressões em álgebra relacional que produzam: (a) Para o cliente com o cartão de cidadão com o número , o seu nome, a data das suas reservas, o tipo e nome da embarcação utilizados. (b) O NIF e o nome do(s) cliente(s) com mais reservas e alugueres na locadora de código 123 da empresa com o NIF (c) A lista de clientes que realizaram alugueres ou reservas em 2016 e que ainda não efetuaram alugueres ou reservas em (d) A lista com todas as embarcações, apresentando para cada o número de vezes que foi utilizada (alugada ou reservada). (e) Nome e tipo da(s) embarcação(ões) que em 2017 esteve (estiveram) mais vezes fora de serviço. (f) Os clientes que reservaram as mesmas embarcações que o cliente com o cartão de cidadão durante o ano de (g) Implemente e valide, usando o ARIs, as expressões realizadas nas alíneas anteriores. 8. Conceba, na linguagem SQL, as interrogações que produzam os resultados a seguir indicados, utilizando apenas uma instrução SQL. Para cada instrução deve ser também apresentada a descrição do raciocínio seguido. (a) Apresente em SQL as interrogações pedidas na alínea 7. (b) Apresente a lista das locadoras (porto e morada) incluindo, se existirem, as atividades nelas desenvolvidas no 3.º trimestre de Das atividades, apresente apenas o nome e a descrição. A lista deve vir ordenada por nome da locadora (1.º critério) e nome da atividade (2.º critério). (c) Apresente as embarcações da(s) locadora(s) situadas no porto de Sesimbra que tiveram reservas ou alugueres todos os dias entre e Apresente o número de alugueres e reservas. Sugerimos a utilização da função datediff para obter o número de dias entre duas datas.

10 (d) Para embarcações da categoria gaivotas ou a remos, obter a lista contendo o nome da embarcação e número médio de horas em que esteve alugada, por dia. Devem ser excluídas as embarcações que tenham um tempo médio inferior a 2 horas. A lista produzida deve vir ordenada de forma decrescente pelo segundo atributo (número médio de horas). Poderá usar funções auxiliares (por exemplo, a função datediff). (e) A lista das atividades de 2016, cujo número de participantes é igual à lotação máxima da atividade, e onde estejam envolvidos mais do que um monitor. (f) Crie uma vista que permita ao gestor da empresa ver os valores pagos pelos clientes para as reservas que já terminaram. Deve ser possível visualizar, para além do valor pago, quem foi o cliente, em que locadora fez a reserva e a data da reserva. A programação da vista deverá incluir a lógica de cálculo do valor da despesa do cliente, não devendo este ser armazenado na tabela associada ao cliente. Data limite para entrega: 12 de junho de 2017 até às 23:59. A entrega deve incluir um relatório, o código ARIs e o código SQL, enviados de forma eletrónica. Nota: Sugere-se que o relatório seja organizado de acordo com os pontos anteriores. Deve ser possível aferir cada um dos objetivos de aprendizagem no material que entregar.

11 Sistemas de Informação I Terceira fase do trabalho prático 2016/2017 Verão Objectivos de aprendizagem No final da terceira fase do trabalho, os alunos devem ser capazes de: Estabelecer uma ligação ao SGBD pretendido, corretamente parametrizada, utilizando JDBC; Utilizar corretamente comandos parametrizados para executar operações em JDBC; Utilizar corretamente transações para garantir atomicidade nas operações, utilizando JDBC; Gerir corretamente o tempo de vida das ligações JDBC; Garantir a libertação de recursos, quando estes não estejam a ser utilizados; Utilizar corretamente o tipo ResultSet; Implementar restrições de integridade aplicacionais. Enunciado do trabalho (3ª fase) Após a realização da 2ª fase do trabalho, os alunos têm agora a oportunidade de utilizar a API JDBC para, através de uma aplicação Java, acederem e manipularem os dados existentes no modelo físico criado na fase anterior. Sempre que se justificar devem ser usados os mecanismos transacionais necessários para garantir a atomicidade das operações. Também devem utilizar mecanismos que evitem ataques de SQL injection, bem como que evitem problemas de formatações, e.g., campos de datas. Resultados pretendidos Uma aplicação Java (em modo linha de comandos ou GUI) que permita realizar as seguintes operações: 1. Opção para registar clientes na empresa; 2. Opção para criar uma embarcação; 3. Opção para efetuar alugueres e reservas numa dada locadora, para clientes eventualmente não registados no sistema. Deve fazer o registo do cliente caso seja necessário. As datas são especificadas pelo utilizador da aplicação. A inserção do cliente e dos alugueres deve ser feita de forma atómica;

12 4. Opção para terminar o aluguer/reserva duma dada embarcação, colocando-a no estado livre e atualizando os dados da reserva; 5. Opção para criar atividades em locadoras; 6. Opção para remover uma atividade. 7. Opções para listar alugueres, reservas e atividades, apresentando a informação das entidades associadas que entender ser relevante; 8. Opção que permita obter, para uma dada embarcação da categoria gaivotas ou a remos, a lista contendo o nome da embarcação e número médio de horas em que esteve alugada, por dia. Devem ser excluídas as embarcações que tenham um tempo médio inferior a 2 horas. A lista produzida deve vir ordenada de forma decrescente pelo segundo atributo (número médio de horas). (implementação da alínea 8d da 2ª fase do trabalho). Data limite para entrega: 3 de julho de 2017 até às 23:59. A entrega deve incluir um relatório e o código, enviados de forma eletrónica. Notas: 1. Não deve ser descuidado o acesso aos dados de forma correcta, ou seja, não deve ser feito demasiado investimento na interface com o utilizador, sem antes garantir a correcta implementação de todas as funcionalidades. 2. Deve criar em Java um modelo de dados que mapeie as tabelas utilizadas. 3. A lógica de interface com o utilizador deve estar em classes separadas da lógica de acesso a dados. 4. Sugere-se que o relatório seja organizado de acordo com os pontos anteriores. Deve ser possível aferir cada um dos objetivos de aprendizagem no material que entregar.