Enunciado do Projecto

Transcrição

1 Bases de Dados 2006/2007 Enunciado do Projecto Parte 1 O projecto de implementação da disciplina de Bases de Dados para ano ano lectivo 2006/2007 divide-se em duas partes. Este documento contém o enunciado da 1 a parte. 1 Problema a Resolver A primeira parte do trabalho consiste no desenho e implementação de uma base de dados para uma instituição. Segue-se uma descrição do domínio de aplicação e das consultas e actualizações que devem ser suportadas pela base de dados. 1.1 Domínio de Aplicação O vosso grupo foi contactado pela empresa de actividades circenses Irmãos Bigodelli. Ruibarbo Bigodelli, o irmão mais velho e presidente da empresa, pretende modernizar a sua actividade e, entre outras medidas, deseja encomendar um sistema de base de dados que permita gerir toda a informação que envolve o funcionamento da empresa. Depois de várias entrevistas, chegou-se à seguinte descrição do domínio a ser representado na base de dados: A empresa Irmãos Bigodelli gere um circo. No circo trabalham artistas e funcionários. Para ambos, é necessário saber o nome, número e país de emissão do passaporte, data de nascimento, salário, data de contratação pelo circo e data de saída do circo (se existir). Alguns artistas são também funcionários. Os artistas são artistas principais ou ajudantes, mas não ambos. Os artistas principais têm que exercer pelo menos uma actividade. As actividades têm um código que as identifica e um nome (e.g., domador, malabarista, mulher das barbas, etc.). Uma mesma actividade pode ser exercida por apenas um artista. Normalmente, um artista tem um ou mais ajudantes para cada actividade que exerce. Algumas actividades são incompatíveis, isto é, não podem ser exercidas pelo mesmo artista. Por exemplo o anão não pode ser domador de elefantes. É importante registar quais as actividades incompatíveis. 1

2 As actividades envolvem adereços. Estes podem ser de três tipos: animais, materiais ou vestuário. Cada adereço é identificado por um código. Os animais podem também ser identificados pelo nome. Os restantes adereços têm uma curta descrição. Para os animais, para além do nome, deve ser guardada a sua data de nascimento, a espécie ( tigre, elefante, pulga, etc.) e o sexo ( m ou f ). Cada animal pode ter vários tratadores, que podem ser artistas ou funcionários, mas têm que trabalhar no circo há, pelo menos, cinco anos. É necessário saber há quantos anos cada tratador se dedica a cada animal. Um tratador pode ser responsável por vários animais. Cada animal tem uma jaula individual. A jaula é limpa por um funcionário e é necessário saber a data da última limpeza. As jaulas são identificadas pelo seu número. É necessário também guardar a constituição dos espectáculos dados pelo circo. Os espectáculos têm uma data de entrada e uma data de saída de cartaz. Deve ser guardado o nome da cidade em que ocorrem e o funcionário responsável pela sua execução. Não podem existir vários espectáculos em simultâneo. Um espectáculo é constituído por várias actuações e deve ser guardada a ordem em que estas são apresentadas ao público. Cada actuação é composta por uma ou mais actividades, mas cada actividade pode pertencer a apenas uma actuação. 1.2 Consultas e Actualizações O sistema de base de dados implementado deverá ser capaz de executar as seguintes consultas: 1. Listar os funcionários actuais do circo. A listagem deve conter a sua identificação, data de contratação e número de espectáculos em que participaram. 2. Dada a data de um espectáculo, listar todas as actividades que o constituiram. A listagem deve conter o nome da actividade, o artista que a executou (nome), o número de ajudantes que participaram e o número de adereços utilizados. 3. Dado o identificador de um tratador (assuma que é tratador), listar todos os tratadores que são responsáveis pelos mesmos animais. 4. Dada a data de um espectáculo, listar todos os artistas que nele actuaram e, se forem tratadores, incluir na listagem o nome dos animais de que são responsáveis. 5. Listar todos os pares de actividades incompatíveis. A listagem deve incluir o nome das actividades. Deverá também ser capaz de executar as seguintes actualizações: 2

3 1. Inserir um novo artista principal (nome, número e país de emissão do passaporte, data de nascimento, salário, data de contratação pelo circo e nome de uma actividade existente). 2. Inserir um novo artista ajudante (nome, número e país de emissão do passaporte, data de nascimento, salário e data de contratação pelo circo). 3. Inserir uma nova actividade (código e nome). 4. Associar uma actividade a um artista e, opcionalmente, a um ajudante. 5. Apagar um artista ou funcionário, dado o seu identificador. 6. Apagar uma actividade, dado o seu identificador. 2 Trabalho a Desenvolver Para a 1 a parte do projecto deve ser apresentado um relatório contendo os seguintes itens: 1. Modelo de classes E-R Diagrama E-R correspondente ao problema apresentado na Secção 1.1. Pode utilizar, se quiser, uma ferramenta de modelação (e.g. Visio, PowerDesigner, etc.). Todas as restrições de integridade que não podem ser modeladas no diagrama devem ser descritas. As restrições de integridade devem ser devidamente numeradas, para que possam ser referidas nos itens seguintes. Por exemplo RI 1: O atributo X não pode ser NULL, RI 2: O valor de Y tem que ser maior que 0, etc. 1 Todas as decisões não triviais devem ser justificadas. Tamanho máximo: 2 páginas. 2. Modelo Relacional Modelo relacional, convertido segundo as regras a partir do modelo E-R do domínio do problema. O modelo deve apresentar todas as chave primárias, chaves estrangeiras, not null s e uniques. Deve ser seguido o seguinte formato na apresentação das relações: relacao(atributo 1, atributo 2, atributo 3,... ) atributo i : F K(relacao X ) unique(atributo j ) not null(atributo k )... 1 Restrições de integridade semelhantes podem ser agrupadas. Por exemplo, RI 1: Todos os atributos da entidade X têm valores maiores que 0. 3

4 em que os atributos que compõem a chave primária são sublinhados e F K(relacao X ) significa que o atributo em questão é uma chave estrangeira da relação relacao X. Todas as restrições de integridade descritas no Item 1 e que se mantêm devem ser indicadas. Quaisquer outras restrições de integridade que não podem ser captadas no modelo relacional devem ser descritas. Todas as decisões não triviais devem ser justificadas. Tamanho máximo: 2 páginas. 3. Tabelas em SQL Instruções SQL necessárias para criar as tabelas respectivas na base de dados. Não se esqueça de especificar todas as restrições de integridade (chave, integridade referencial, e outras) suportadas pelo SGBD escolhido, assim como todas as validações e valores por omissão. Todas as restrições de integridade descritas no Item 1 e que não não são suportadas directamente pelo SGBD devem ser indicadas. Tamanho máximo: 6 páginas. 4. Interrogações e Actualizações Implementação em SQL das interrogações e actualizações listadas na Secção 1.2. Todas as consultas devem ser acompanhadas por uma breve descrição do seu funcionamento. Devem também ser implementadas de forma simples e eficiente. Recomenda-se que o aluno crie a sua própria base de dados e insira alguns registos para testar as consultas implementadas. Tamanho máximo: 2 páginas. 3 Regras de Implementação do Trabalho Regras gerais Na resolução deste problema, devem ser tidas em conta as seguintes regras gerais: O trabalho deverá ser feito em grupos de três alunos; O trabalho deverá ser entregue até às 23:59 do dia 31 de Outubro de 2006 na portaria do IST Tagus. 4

5 Formato do relatório O relatório a entregar deverá conter uma secção para cada uma dos itens referida na secção 2. Deverá conter também uma folha de rosto com a indicação Projecto de Bases de Dados 2006/ Parte 1, o número do grupo e o nome e número dos alunos. As folhas impressas deverão ser apenas agrafadas. Não utilize capas rígidas ou transparentes, não encaderne, nem intercale folhas em branco dentro do relatório. O relatório deverá obedecer rigorosamente aos critérios de espaço definidos na Secção 2. A fonte utilizada deverá ser, preferencialmente, de tamanho 12 e nunca deverá ser de tamanho inferior a 10 (excepto no diagrama E-R). Além disso, não deverá conter listagens dos dados usados para testes nem resultados de consultas SQL. Formato do código Todo o código entregue deverá ser correctamente formatado de modo a facilitar a legibilidade. Código de difícil legibilidade não será corrigido. Todas as consultas SQL presentes no relatório devem ser devidamente anotadas com um breve comentário explicativo do seu funcionamento. 4 Critérios de Avaliação A primeira parte do projecto será avaliada com uma pontuação de 0 a 20 valores. Cada parte do relatório terá a seguinte pontuação e critérios de avaliação: Modelo de classes E-R: 7 valores Modelo completo: 3 valores Todas as entidades, associações e atributos presentes. Correcção: 2,5 valores Não há erros nos elementos que estão no diagrama. Clareza: 0,5 valores O diagrama é legível e fácil de compreender Restrições de integridade: 1 valor São apresentadas correctamente todas as restrições de integridade. Modelo Relacional: 4 valores Modelo completo: 0,5 valores Todas as relações necessárias para representar o modelo estão presentes. Correcção: 1,5 valores A conversão do diagrama E-R para o modelo relacional foi feita correctamente. 5

6 Chaves estrangeiras: 1 valor Todas as chaves estrangeiras estão presentes e completas. Not nulls e uniques: 0,5 valores Todas as restrições do tipo not null e unique estão presentes e correctas. Restrições de integridade: 0,5 valores São apresentadas correctamente todas as restrições de integridade. Tabelas em SQL: 3 valores Correcção: 1 valor Todas as tabelas correctamente implementadas. Chaves estrangeiras: 0,4 valores Todas as chaves estrangeiras correctamente implementadas. Not nulls e uniques: 0,3 valores Todas as restrições do tipo not null e unique correctamente implementadas. Restrições suportadas pelo SGBD: 0,8 valores Todas as restrições suportadas pelo SGBD correctamente implementadas. Restrições não suportadas pelo SGBD: 0,5 valores São indicadas correctamente todas as restrições de integridade não suportadas directamente pelo SGBD. Interrogações e Actualizações: 6 valores Correcção: 4 valores As interrogações estão implementadas correctamente. Clareza: 1 valor As interrogações são legíveis e estão devidamente explicadas. Eficiência: 1 valor As interrogações são eficientes e não usam operações desnecessárias. 5 Cronograma Apresentamos agora um cronograma recomendado para o desenvolvimento do trabalho. Note-se que este cronograma é apenas uma sugestão, não tendo os alunos a obrigação de cumprir as metas propostas, a não ser a data de entrega. Fase do trabalho Data de finalização Modelo E-R 6/10 Modelo Relacional 13/10 Tabelas em SQL 20/10 Interrogações 30/10 Entrega 31/10 6