Artigo SQL Magazine 50 - Estudos de Caso de Projetos de Bancos de Dados

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Neste artigo abordaremos o projeto de um banco de dados para uma biblioteca e para um sistema de ordens de serviço, com algumas restrições de escopo.

Esse artigo faz parte da revista SQL Magazine edição 50. Clique aqui para ler todos os artigos desta edição

Modelagem

Estudos de Caso de Projetos de Bancos de Dados

 

É sabido que o objetivo de um projeto de banco de dados é obter um conjunto de esquemas de relações que nos permita armazenar dados sem redundância e que as informações necessárias para tomadas de decisões possam ser geradas facilmente. Assim, para que um projeto de banco de dados possa atender a estes pressupostos, aplicamos o que podemos chamar de normalização dos dados.

Na edição número 47 desta revista, apresentamos os conceitos envolvidos na normalização de um projeto de banco de dados.

Neste artigo, utilizaremos os conceitos citados na referida edição e abordaremos o projeto de um banco de dados para uma biblioteca e para um sistema de ordens de serviço, com algumas restrições de escopo, que detalharemos a seguir.

Escolhemos estes projetos devido ao fato das regras de negócio serem de fácil compreensão. Entretanto, eles possuem vários pontos de questionamento por parte dos projetistas de bancos de dados. Uma grande parcela destes profissionais tende a cometer grandes erros nos mais diversos projetos de bancos de dados e nestes dois exemplos, conseguiremos abordar os pontos que devem ser considerados, desde projetos de pequeno porte, até grandes projetos de bancos de dados.

Assim, inicialmente apresentaremos o estudo de caso para a biblioteca e posteriormente o de ordens de serviço.

Biblioteca

Todos nós já freqüentamos bibliotecas em algum momento de nossa vida acadêmica. Em linhas gerais, uma biblioteca possui livros que devem ser emprestados e devolvidos. Neste estudo de caso em particular, reduziremos o escopo de uma biblioteca com a finalidade de facilitar a compreensão do modelo de dados que apresentaremos. Entretanto, nada impede que o leitor acrescente outras funcionalidades no modelo aqui apresentado.

Assim, um sistema de bibliotecas, para este estudo de caso, consiste das seguintes funcionalidades:

·     Cadastro de Livros: Um cadastro de livro deve armazenar informações relativas ao Título do livro, Editora, Edição, Ano de Publicação, Autores, Assunto. Sabe-se também que um livro pode possuir vários exemplares e neste caso, são emprestados os exemplares e não os títulos.

·     Cadastro de Alunos: Um cadastro de aluno deve possuir número de matrícula, nome, endereço, telefone, telefone celular, CPF, RG, e-mail.

·     Cadastro de Professores: Um cadastro de professor deve possuir nome, endereço, telefone, telefone celular, CPF, RG, e-mail, titulação.

·     Empréstimo de Livros: Esta funcionalidade refere-se ao empréstimo de livros propriamente dita aos alunos ou professores da instituição. Este empréstimo deve armazenar a data do empréstimo, data prevista de devolução, exemplar emprestado.

·     Devolução de Livros: Após serem emprestados, os livros podem ser devolvidos. Neste ponto, os livros podem ter devoluções parciais, ou seja, um aluno pode pegar emprestado 3 livros diferentes e querer devolver apenas um.

 

Desta forma, neste artigo não abordaremos o pagamento de multas, assim como o cadastro de periódicos que também existem em bibliotecas, pelo fato de entendermos que fogem do objetivo deste exemplo. Também não será tratado o empréstimo de livros a funcionários com regras distintas, pelo mesmo motivo. Em diversas instituições existem critérios distintos de empréstimos para professores, alunos e funcionários e neste artigo também não serão tratadas estas diferenciações de regras.

Também não serão abordadas outras funcionalidades como empréstimo de exemplares únicos, empréstimo de férias, reserva e renovação de livros.

A partir desta pequena definição das regras de negócio em questão, iremos iniciar a modelagem de dados. Não formalizamos esta definição das regras de negócio também por fugir dos objetivos deste artigo.

Na Figura 1 apresentamos a primeira parte do modelo de dados, que compreende o cadastro de livros.

 

 Figura 1. Tabela Livro Desnormalizada

 

Em posse da Tabela Livro (Figura 1), precisaremos verificar se ela esta normalizada. O primeiro passo é verificar se ela está na 1FN (Primeira Forma Normal). A 1FN diz que “Uma tabela se encontra na 1FN se todos os atributos possuírem apenas valores atômicos (simples e indivisíveis) e os valores de cada atributo no registro também deve ser um valor simples (ou seja, o atributo não é composto)”.

Podemos perceber que esta tabela possui os atributos Autores e Assunto, que são multivalorados, ou seja, para cada livro, podemos ter mais de um autor e mais de um assunto. Assim, devemos separar estes atributos em outras tabelas. Assim, na Figura 2 temos o modelo de dados normalizado segundo a 1 FN.

 

Figura 2. Modelo de Dados Livro – Assunto – Autores

 

Podemos perceber que no modelo de dados da Figura 2 foram inseridas as tabelas Assunto, Autor, Livro_Assunto e Livro_Autor. A tabela Autor armazena o cadastro básico dos autores, assim como a tabela assunto armazena os mais diversos assuntos de livros. A tabela Livro_Autor é responsável por resolver o relacionamento n:m entre livro e autor, ou seja, um livro pode ter vários autores e cada autor pode ter vários livros publicados. Da mesma forma, a tabela Livro_Assunto.

O próximo passo é verificar se o modelo de dados da Figura 2 se encontra na 2FN (Segunda Forma Normal). A 2FN diz que “Uma tabela se encontra na 2FN se estiver na 1FN e não possuir dependência funcional parcial. Caso existam atributos que não dependam integralmente da chave primária, devemos retirar da tabela todos eles e dar origem a uma nova tabela.” Entretanto, na Figura 2 percebemos que apenas as tabelas Livro_Autor e Livro_Assunto possuem chaves primárias compostas. Além disso, ambas possuem apenas os atributos que compõem a chave. Logo, elas estão na 2FN.

Agora, iremos verificar se o modelo de dados da Figura 2 encontra-se na 3FN (Terceira Forma Normal). A 3FN diz que “Uma tabela está na 3FN se estiver na 2FN e não possuir nenhuma dependência funcional transitiva”. Isto quer dizer que nenhum atributo pode depender de outro atributo que não seja a chave primária. Assim, percebemos que na tabela Livro da Figura 2 existe o atributo Editora que não depende de CodL, que é chave primária. Desta forma, precisaremos criar outra tabela para armazenar o cadastro de Editoras.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?