Instituto Superior de Engenharia de Lisboa Departamento de Engenharia de Electrónica e Telecomunicações e de Computadores Licenciatura em Engenharia Informática e de Computadores Trabalho prático Sistemas de Informação 1 Semestre de Inverno 2013/2014 Versão 1.00
3 O Problema A KYIS (Keep Yourself In Shape) é uma nova empresa na área da nutrição, que pretende desenvolver planos alimentares adequados às necessidades dos seus clientes. O seu modelo de negócio assenta totalmente na Internet, pretendendo que os processos sejam automatizados, incluído as consultas, que são feitas através de aplicações video-chamada. Com base em informações recolhidas no mercado, requereu os serviços de consultadoria dos alunos de SI1 para planearem o sistema de informação e desenvolverem um protótipo em Java. Uma área onde pretende inovar é a apresentação detalhada, online, das receitas que constituem o plano alimentar, assim como apoiar os clientes na escolha de ementas e receitas alternativas compatíveis, com o seu plano alimentar. Primeira fase Objectivos de aprendizagem No final desta fase, os alunos devem ser capazes de: Identificar correctamente as entidades relevantes para os requisitos pretendidos; Identificar correctamente os atributos chave para cada uma das entidades; Identificar correctamente os atributos descritivos para cada uma das entidades; Identificar o domínio de cada atributo; Identificar correctamente as associações entre entidades, incluindo respectivas 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. Requisitos Mínimos O modelo EA a desenvolver deve contemplar as necessidades da empresa, descritas de seguida, incluindo as interrogações presentas na Terceira fase.
4 A base de um plano alimentar é a receita. Uma receita é descrita por um texto, tem um título, tem um tempo estimado de preparação, um nível de dificuldade e o número de pessoas a que se destina. É também importante ter a informação das Kilo-Calorias (KCal) por pessoa. Uma receita está categorizada por tipo de cozinha, e.g. Italiana, podendo em certas circunstâncias essa informação não estar disponível. Tem também a indicação do(s) tipo(s) de regime aplicável, e.g. Vegetariano. Uma receita é constituída por ingredientes, identificados por um nome, tendo para cada um, uma dada quantidade expressa numa unidade de medida. Por exemplo, 3 dl de água. Para ajudar na confecção das receitas, são registados os passos de cada uma, com uma ordenação e um texto descritivo. Além disso, é indicado o tempo em minutos e os ingredientes da receita utilizados no passo. De notar que cada passo é específico da receita a que diz respeito, e.g. passo 1 da receita 1. Uma receita está indicada para vários tipos de refeição, pelo menos um. Um tipo de refeição tem uma descrição única, e.g. Jantar. No registo de uma ementa diária, são indicadas as refeições que a constituem, assim como a sua ordem, e a receita associada a essa refeição. Além disso, as ementas são caracterizadas por uma descrição. Não pode existir uma ementa diária vazia. Um plano alimentar é constituído por uma sequência, não vazia, de ementas diárias. É caracterizado por uma descrição, por um código de 4 dígitos único e por uma determinada finalidade (e.g. prevenir a osteoporose). Nesse sentido, é importante indicar os públicos alvo a que se destina o plano e aqueles para o quais é contra-indicado. Um público alvo é caracterizado por uma faixa etária, por uma actividade e por um género (opcional). Uma faixa etária é definida em períodos de 10 anos, e.g. [15-24], sendo as faixas limite descritas como <15 e >64. É possível que as faixas etárias sofram alterações ao longo do tempo de vida do sistema, por exemplo, com a subdivisão de algumas faixas etárias em períodos mais curtos. A actividade indica o tipo de actividade física, podendo tomar os valores (i) Sedentário, (ii) Moderadamente Activo, (iii) Muito Activo, (iv) Alta Competição. A empresa regista alguma informação dos seus clientes, nomeadamente, o seu número de cliente, o BI, a morada, a altura (em metros), o nome e a data de nascimento. Sobre o peso dos clientes importa registar o seu valor e a data da pesagem, sendo que o sistema deverá manter registo dos vários pesos de um cliente ao longo do tempo. É também registado se é fumador e, para as clientes de sexo feminino, é importante saber a sua condição: (i) Grávida, (ii) Amamentar, (iii) Normal, (iv) Menopausa. Neste momento não há informação adicional a reter no caso dos clientes de sexo masculino, mas essa necessidade poderá vir a existir. De notar que a distribuição de clientes por ambos os sexos tende a ser equitativa. Cada cliente terá o seu plano alimentar, podendo ser alterado ao longo do tempo, ou mesmo não existir. Além disso, pode estar sinalizado como pertencente a vários público alvo.
5 Notas para a implementação: Para quaisquer esclarecimentos adicionais deve ser utilizado o email do cliente para esse efeito: Contacto para equipa LI31D e LI31N - kyis.li31@gmail.com Contacto para equipa LI32D - kyis.li32@gmail.com A informação complementar fornecida pelo cliente, e que seja importante para clarificar aspectos do domínio da aplicação, deve ser incluída no relatório. Segunda fase Objectivos de aprendizagem No final desta fase, os alunos devem ser capazes de: Aplicar correctamente 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 correctamente SQL/DDL para criar as tabelas num SGDB; Escolher correctamente 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. Requisitos Mínimos O objectivo desta fase é a construção do Modelo Lógico (Modelo Relacional), obtido a partir do modelo EA construído na fase anterior. O Modelo Lógico tem de estar normalizado até à 3NF, garantindo que preserva toda a informação, indicando-se as dependências funcionais associadas aos atributos. 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 Conceptual. Os alunos deverão identificar falhas, possíveis melhorias ou diferentes opções de modelação, relativamente ao modelo apresentado na primeira fase, apresentando a versão final do Modelo Conceptual. Os alunos poderão decidir fazer alterações, simplificações ou optimizações ao modelo, desde que devidamente indicadas e fundamentadas.
6 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 se consigam garantir na forma declarativa. Pretende-se que crie o Modelo Físico utilizando a ferramenta Microsoft SQL Server Management Studio. Notas para a implementação: Conceba o código SQL para que seja possível criar e destruir o modelo de dados. Utilize dois scripts: um para criar e outro para remover as estruturas de dados. Note que a sua execução, em qualquer ordem, não deve produzir nenhum erro. Terceira fase Objectivos de aprendizagem No final desta fase, os alunos devem ser capazes de: Utilizar correctamente a álgebra relacional, com os seus vários operadores, para expressar interrogações sobre um modelo 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 transaccional; Utilizar correctamente 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. Requisitos Mínimos Utilizando a linguagem SQL e o modelo físico anteriormente desenvolvido, apresente um script SQL que insira em todas as relações pelo menos 3 instâncias da relação. Procure inserir instâncias que lhe permita testar correctamente as interrogações, pedidas adiante.
7 Conceba na linguagem SQL as interrogações a seguir indicadas, utilizando apenas uma instrução SQL. 1. Quais os ingredientes (nome) que são comuns às receitas 1 e 3? 2. Quais os ingredientes (nome) que não entram em nenhuma receita? 3. A lista das receitas possíveis para almoço e jantar, compatíveis com um regime vegetariano, que demorem menos de 30m a serem confeccionadas, e que estejam a ser utilizadas em planos alimentares adequados a clientes do sexo masculino. Nota: Apresente o título das receitas. 4. Apresente receitas alternativas para o almoço da primeira ementa diária do plano alimentar 1. Considera-se que é alternativa quando tem o mesmo número de calorias por pessoa, o mesmo tipo de regime e é adequada para o mesmo tipo de refeição. Nota: Apresente apenas o título e a chave primária das receitas. 5. Apresente os planos alimentares (código) onde a média de KCal diária é superior a 2000, tendo em conta que o total de KCal de uma ementa diária resulta das KCal das suas receitas. Ordene por ordem descendente da média de calorias diária. 6. Quais os ingredientes que podem ser encontrados em todos os tipos de regime? Nota: Apresente o nome do ingrediente, ordenado por ordem alfabética. 7. Quais as receitas adequadas para almoço que não estão em nenhum plano alimentar de clientes do sexo masculino? Nota: Apresente a chave primária e o título das receitas, bem como a indicação se o tipo de regime é Vegan ou Outro. 8. Qual a receita que é utilizada em mais planos alimentares? Nota: Apresente a chave primária e o número de planos alimentares onde a receita entrou.. 9. Apresente as ementas diárias, compatíveis com mulheres pretendentes a um público alvo sedentário, onde o número de KCal diário seja inferior a 1800. Nota: Apresente toda a informação da ementa, ordenando os resultados de forma decrescente por KCal. 10. Proponha uma interrogação interessante e resolva-a. Para as interrogações 2, 3, 5, 6 e 8 apresente também a expressão em álgebra relacional. Note que em álgebra relacional não é possível apresentar o resultado ordenado. Notas para a implementação: Caso tenho verificado a necessidade de alterar o modelo físico, por forma a ser possível realizar as interrogações pedidas, apresente o novo script
8 de criação do modelo identificando as alterações e correcções realizadas relativamente à segunda parte do trabalho. Quarta fase Objectivos de aprendizagem No final desta fase, os alunos devem ser capazes de: Utilizar correctamente transacções para garantir atomicidade nas operações, utilizando JDBC; Utilizar correctamente comandos parametrizados para executar operações em JDBC; Estabelecer uma ligação o SGBD pretendido, utilizando JDBC; Gerir correctamente o tempo de vida da ligação; Garantir a libertação de recursos, quando estes não estejam a ser utilizados; Utilizar correctamente o tipo ResultSet; Implementar as restrições de integridade aplicacionais. Requisitos Mínimos Nesta etapa pretende-se que implemente uma aplicação que utilize o sistema de informação construído. A aplicação será realizada na linguagem Java, utilizando JDBC para ligação, acesso e comunicação com o servidor de base de dados. As restrições de integridade identificadas na Segunda fase devem de ser concretizadas, certificando-se que, quando necessário, um conjunto de operações são consideradas de forma atómica, ou seja todas as operações são realizadas ou nenhuma o é. O sistema deve estar preparado para suportar eventuais falhas na ligação com o servidor. O SGBD a utilizar é o SQL Server. As funcionalidades obrigatórias são: 1. Inserção de um novo cliente; 2. Inserção de uma nova receita; 3. Listar as receitas compatíveis para um determinado regime alimentar, disponível no sistema;
9 4. Associar um plano alimentar a um cliente, de entre os regimes alimentares compatíveis. Note que, no caso de o cliente já ter um plano alimentar, este deve ser substituído pelo novo plano. 5. Apresentar uma receita, contemplando os seus passos e respectivos ingredientes; 6. Remover um plano alimentar. Notas para a implementação: Sempre que sentir necessidade, pode implementar outras funcionalidades de suporte às funcionalidades obrigatórias, como por exemplo, listagens e inserções de novos valores. Note que, a aplicação deverá ter um menu com as opções e apenas terminar quando explicitamente indicado pelo utilizador. Planeamento As datas importantes a recordar são: Lançamento do enunciado: 18 de Setembro de 2013 Entrega da primeira fase: 21 de Outubro de 2013 Entrega da segunda fase: 18 de Novembro de 2013 Entrega da terceira fase: 09 de Dezembro de 2013 Entrega da quarta fase: 06 de Janeiro de 2014 Em cada entrega deve apresentar o relatório e código (se existir) referente às respectivas fases, e uma eventual errata e correcções a entregas anteriores. O relatório deve apresentar a justificação de todas as decisões tomadas. Deve ser possível encontrar evidências para os objectivos de aprendizagem enunciados. Na capa do relatório deverá constar: (i) nome da unidade curricular e curso, (ii) ano e semestre lectivo, (iii) identificação do grupo, (iv) número e nome de cada um dos elementos do grupo, (v) identificação da fase do trabalho. A entrega dos relatórios tem de ser feita até à data definida para o efeito. 18 de Setembro de 2013, Lara Santos e Nuno Datia.