Artigo SQL Magazine 32 - Desafio SQL Magazine

Desafio SQL Magazine

Consultas em SQL: Utilização de relacionamentos 1:1 e 1:n

Leitura obrigatória: SQL Magazine 31, Desafio SQL Magazine.

Caros leitores, na edição anterior apresentamos um primeiro desafio de modelagem de dados onde a ênfase era exercitar a construção de relacionamentos 1:1 e 1:n.

Neste segundo desafio, vamos propor a construção de um conjunto de consultas em SQL a serem desenvolvidas utilizando o modelo proposto no primeiro desafio. Antes disso, precisamos discutir as possibilidades de solução do desafio anterior (leia na íntegra o desafio no Box 1), lembrando que não existe uma única solução correta. Assim, se sua solução estiver um pouco diferente da que estaremos apresentando a seguir, não quer dizer necessariamente que esteja errada.

Box 1. Desafio apresentado na edição 31 da SQL Magazine

Deseja-se construir um sistema de controle de biblioteca. Como requisitos iniciais foram identificados:

·Devem ser cadastradas as obras do acervo, que representam livros, periódicos (revistas, jornais) e qualquer outro elemento do acervo da biblioteca. Inicialmente, obras devem possuir um código que as identifique: título, autor principal, ano de publicação, situação (disponível, emprestada) e editora. Editoras, por sua vez, possuem um código, nome e cidade. Uma obra sempre é de uma editora e uma editora pode possuir diversas obras;

·Devem ser cadastrados usuários da biblioteca, que devem ter uma identificação única, nome, endereço completo, telefone de contato e CPF;

·Os funcionários da biblioteca também devem ser cadastrados. Funcionários têm um número de matrícula, seu nome completo e departamento em que trabalha. Departamentos, por sua vez, possuem código e nome. Todo funcionário obrigatoriamente é vinculado a um departamento, que pode ter vários funcionários. Além disso, todo departamento possui um único chefe;

·Usuários devem poder realizar empréstimo de obras. Um empréstimo deve conter uma única obra e ser de um único usuário, obrigatoriamente. Empréstimos ainda devem registrar a data e horário do empréstimo, data prevista de retorno, bem como o funcionário que o realizou. Quando da devolução da obra em empréstimo, deve-se registrar a data e horário da devolução, bem como o funcionário responsável;

·Usuários ainda podem realizar reservas de obras. Uma reserva deve conter uma única obra e ser de um único usuário, obrigatoriamente. Reservas ainda devem registrar a data e horário da reserva e data na qual a obra será retirada.

A Figura 1 apresenta o diagrama entidade-relacionamento contendo a solução para o desafio anterior. Optamos por não representar os atributos neste diagrama para não dificultar a legibilidade. Os atributos serão apresentados posteriormente na estrutura das entidades.

Figura 1. DER do desafio apresentado na SQL Magazine 31.

Vale lembrar que, apesar de uma prática comum, não é obrigatório nomear os relacionamentos, exceto quando estes irão originar tabelas, que é o caso de relacionamentos n:n ou relacionamentos que possuem atributos. Nestes casos, o nome dos relacionamentos normalmente são os nomes das tabelas resultantes. Entretanto, nomear relacionamentos é importante para uma melhor compreensão do modelo e vamos utilizar este recurso quando for necessário. Neste exemplo, nomeamos os relacionamentos entre as entidades Funcionario e Departamento, uma vez que seu entendimento fica dificultado se os relacionamentos não forem nomeados por existirem dois relacionamentos entre estas entidades.

A seguir, é descrita a estrutura inicial das entidades, onde o atributo determinante está sublinhado. Observe que, propositadamente, deixamos os atributos da editora dentro da entidade Obra:

·Obra (cod_obra, titulo, autor_principal, ano_publicacao, situacao_obra, tipo_obra, cod_editora, nome_editora, cidade);

·"