Atividades de aprendizagem
4. As tabelas mostradas na Figura 1.9 correspondem ao modelo relacional de BD.
2.2 Exemplos do modelo entidade-relacionamento
Considere um BD para manter informações atualizadas sobre os projetos de- senvolvidos por uma empresa e as equipes responsáveis por tais projetos. Todos os integrantes das equipes são funcionários da empresa. Cada projeto é gerenciado por um funcionário e as equipes podem ser formadas por vários funcionários. Independentemente dos projetos, cada funcionário possui uma função na empresa (diretor, analista de sistemas, contador, engenheiro, etc.). De cada projeto importa armazenar seu número identificador, nome, data de início, data prevista de conclusão e data efetiva de conclusão. Em relação a cada funcionário é importante guardar sua matrícula, nome, sexo e função. A Figura 2.13 apresenta um diagrama ER que modela o BD proposto. Nela há três relacionamentos, três entidades e uma relação. Observe que um funcio- nário pode gerenciar muitos projetos, mas um projeto pode ser gerenciado apenas por um funcionário. Entretanto, um funcionário pode trabalhar em muitos projetos simultaneamente e cada projeto pode ter muitos funcioná- rios nele trabalhando. Do mesmo modo, um funcionário possui apenas uma função, mas uma função pode pertencer a muitos funcionários. Portanto, um funcionário não pode ser programador de computadores e contador ao mesmo tempo, mas a empresa pode ter mais de um programador ou conta- dor dentre seus funcionários.
FUNCIONARIO MATRICULA NOME SEXO FUNCAO PROJETO NUMERO NOME DATA_INICIO DATA_FINAL_PREVISTA DATA_FINAL_EFETIVA ID_FUNCAO DESCRICAO EQUIPE possui gerencia trabalha em MATRICULA NUMERO N N N N 1 1
Figura 2.13: Exemplo de Diagrama ER
Fonte: Elaborada pelo autor
Como indicam os atributos do modelo, um projeto ainda em andamen- to apresentaria a DATA_FINAL_EFETIVA com valor nulo. A existência de DATA_FINAL_PREVISTA e de DATA_FINAL_EFETIVA permite avaliar o atra- so do projeto em andamento ou concluído.
Consideremos agora a modelagem de um BD desenvolvido para o geren- ciamento de uma biblioteca. Para simplificar, a biblioteca empresta apenas livros. Não há revistas ou DVDs em seu acervo. Também é vetado ao usuário dessa biblioteca reservar um livro indisponível no momento como nas biblio- tecas em que o usuário pode entrar em uma fila de reservas, de modo que, ao ser devolvido um exemplar do livro reservado, os usuários que fizeram a reserva podem, conforme sua ordem na fila, requisitar o livro. Por outro lado, o BD modelado deve prover os seguintes requisitos:
(1) Manter dados sobre as obras do acervo, como nome dos autores, data da aquisição, editora, edição e título.
(2) Manter registro de todos os livros de uma mesma obra.
(3) Efetuar o empréstimo e devolução de livros, mantendo registros detalha- dos ao longo do tempo.
(4) Consultar livros por código de identificação, título da obra, nome de au- tores e gênero da obra (autoajuda, dicionário, literatura, etc.).
(5) Manter dados sobre os usuários da biblioteca: matrícula, nome, sexo, data de nascimento, endereço e telefone.
A Figura 2.14 mostra o diagrama ER para o sistema de informação dessa biblioteca. OBRA NR_OBRA TITULO GENERO ID_GENERO DESCRICAO AUTOR ID_AUTOR NOME LIVRO NR_LIVRO DATA_AQUISICAO EDICAO AUTORIA referencia classifica escreve NR_OBRA ID_AUTOR N N 1 N N 1 EDITORA ID_EDITORA NOME FANTASIA publica N 1 USUARIO MATRICULA NOME SEXO DATA NASCIMENTO TELEFONE CELULAR E_MAIL ENDERECO MOVIMENTACAO movimenta MATRICULA NR_LIVRO DATA_EMPRESTIMO DATA PREVISTA DATA_DEVOLUCAO N N N
Figura 2.14: Diagrama ER do Sistema de Gerenciamento de Biblioteca
Fonte: Elaborada pelo autor
Nela foram usadas duas entidades: OBRA e LIVRO. A entidade LIVRO, por exemplo, refere-se a uma edição em particular de uma obra. Considere uma obra do século XIX, como Helena, de Machado de Assis. Ela já foi publica- da por diferentes editoras em mais de um século de existência. Portanto, a entidade EDITORA não poderia estar relacionada à entidade OBRA, mas sim à entidade LIVRO. Se fosse diferente, essa obra somente poderia ser publicada por uma editora.
Por analogia, o atributo EDICAO não pode estar na entidade OBRA, mas em LIVRO. Afinal, somente livros publicados de uma mesma obra podem ter edi- ções diferentes. No exemplo, podem existir 30 livros da obra Helena, cada um publicado por editoras diferentes ou com edições diferentes da mesma editora. A entidade AUTOR se relaciona à entidade OBRA, pois se relacionada a LIVRO implicaria o relacionamento pouco justificável de seus autores a cada livro. Nesse caso, se 50 livros da obra de Alexandre Dumas, Os Três Mosqueteiros, fossem doados para a biblioteca, um funcionário deveria relacionar o nome do autor a cada uma das 50 ocorrências de LIVROS. Com o relacionamento de AUTOR com OBRA, Alexandre Dumas seria relacionado a uma única obra e esta, por sua vez, aos 50 livros dessa mesma obra.
Ainda observando a Figura 2.14, notamos que um gênero pode classificar várias obras, mas uma obra pode ser classificada por um gênero. Assim, Helena e Os Três Mosqueteiros podem ser classificadas como literatura. Porém, nenhuma dessas obras pode ser classificada em mais de um gênero simultaneamente. Um autor pode escrever muitas obras, e uma obra, ser escrita por muitos autores. Devido à cardinalidade N:N surgiu a relação AUTORIA (retângulo tracejado), possibilitando obras com mais de um autor, como em livros didá- ticos ou coletâneas de artigos.
Um livro pode referenciar apenas uma obra, mas uma obra pode ser referen- ciada por muitos livros. Por outro lado, Uma editora pode publicar muitos livros, mas um livro pode ser publicado apenas por uma editora.
Um usuário pode movimentar vários livros e um mesmo livro pode ser movi- mentado por vários usuários ao longo do tempo. Mais uma vez a cardinali- dade N:N gerou a relação MOVIMENTACAO, a qual armazena empréstimos e devoluções de livros.
Ao emprestar um livro a um usuário, uma ocorrência de movimentação é gera- da com o atributo DATA_DEVOLUCAO nulo e DATA_EMPRESTIMO com a data atual do sistema. Na devolução do livro essa movimentação é atualizada com a alteração do atributo DATA_DEVOLUCAO para a data corrente do sistema. No exemplo de um diagrama ER da Figura 2.15, temos um BD modelado para suportar um sistema de gerenciamento da marcação de consultas médicas.
MEDICO CRM NOME SEXO TELEFOME CELULAR E-MAIL ESPECIALIDADE COD_ESPECIALIDADE DESCRICAO PLANO_SAUDE ID_PLANO NOME_FANTASIA ESPECIALISTA CRM COD_ESPECIALIDADE ID_PLANO ID_PACIENTE CRM DATA HORA CONSULTA possui N N N N PACIENTE ID_PACIENTE NOME SEXO TELEFONE CELULAR N
Figura 2.15: Diagrama ER para marcação de consultas médicas
Fonte: Elaborada pelo autor
O diagrama foi modelado a partir dos seguintes requisitos:
(1) Armazenar dados de médico: número de registro no Conselho Regional de Medicina (CRM), nome completo, sexo, telefone fixo, celular e e-mail para contato.
(2) Armazenar informações de paciente: número identificador, nome com- pleto, sexo, telefone fixo e celular.
(3) Identificar as especialidades de cada médico (um mesmo médico pode atuar, por exemplo, como clínico geral e dermatologista).
(4) Agendar consultas para um paciente, especificando o plano de saúde e o médico.
(5) Como simplificação do modelo não será necessário armazenar os horá- rios de atendimento semanal para cada médico. Consideraremos apenas que todos os médicos atendem todos os dias úteis da semana em um horário fixo e igual para todos.
Note que Consulta é uma relação gerada a partir de um relacionamento ternário entre as entidades MEDICO, PACIENTE e PLANO_SAUDE.