Continuando a construção do projeto de banco de dados da livraria Book.NET, veremos mais alguns conceitos do modelo lógico, como restrições de integridade (RI), regras de derivação (RD), agregação, entidades fortes e fracas e dicionário de dados.
Restrições de Integridade
A princípio, qualquer regra do sistema pode ser qualificada como uma restrição de integridade. Por exemplo, o fato de um cliente não possuir mais de três dependentes ou um livro não possuir mais de um código ISBN são restrições de integridade. Essas duas regras já estão representadas no diagrama, através dos elementos básicos usados até aqui – a primeira está definida pela cardinalidade do auto-relacionamento de Cliente e a segunda é indicada pelo atributo identificador ISBN. No entanto, os elementos principais do diagrama não são suficientes para representar algumas restrições de integridade. Veja dois exemplos:
Os clientes só podem alugar no máximo três livros de uma vez, cuja duração não poderá ultrapassar o período de duas semanas.
Caso o cliente passe do tempo do aluguel e não o renove, pagará uma multa na devolução e/ou na renovação.
Para representar essas regras no diagrama podemos utilizar o símbolo RI, junto ao relacionamento ALUGA, conforme mostra a figura 1. Observe que a sigla possui um número seqüencial, indicando que o modelo pode conter várias restrições. No dicionário de dados devemos descrever cada RI, indicando seu número e a regra de negócio em questão. O ideal é que cada regra possua sua própria RI, facilitando a documentação no dicionário e a identificação da regra pelas pessoas envolvidas no projeto.
Figura 1 - Modelo de Entidade-Relacionamento parcial para Book.net
Representar a restrição de integridade no diagrama não é obrigatório, mas sua descrição no dicionário de dados é imprescindível.
Restrições de Integridade em Atributos
Embora sejam encontradas com mais freqüência em relacionamentos, as RIs também podem ser definidas para atributos. A idéia é a mesma: descrever uma regra de negócio que não seja possível representar com os elementos básicos do diagrama. Para exemplificar, usaremos o atributo valor multa, do relacionamento ALUGA. O cliente que ultrapassar duas semanas no aluguel de um ou mais livros deve pagar uma multa pelo atraso. Percebemos que o valor do atributo será preenchido somente se existir algum atraso na devolução do livro, representando uma restrição de integridade.
Outro atributo que também possui uma restrição é período aluguel, que não pode ser superior à duas semanas. Veja na figura 2 o modelo com as restrições de integridade nos atributos.
Figura 2- Modelo de Entidade-Relacionamento parcial para Book.net
Regras de Derivação
Regras de derivação descrevem atributos cujo valor depende de outro atributo ou de um cálculo. No diagrama, o símbolo RD é utilizado para identificar esse tipo de regra. A descrição completa da fórmula utilizada para compor o valor do atributo deve ser documentada no dicionário de dados.
Por exemplo, para modelar o valor total de uma compra, vamos acrescentar dois atributos no relacionamento COMPRA: quantidade comprada e total (o atributo preço já está modelado na entidade Livro). Esse último contém uma regra de derivação: seu valor é calculado através da soma da quantidade de livros comprados multiplicado pelo preço de venda e subtraído pelo desconto de promoção, caso o cliente tenha direito. Na figura 3 vemos o símbolo RD junto ao atributo total. Observe que, assim como na restrição de integridade, devemos numerar seqüencialmente cada regra de derivação do modelo. A descrição do cálculo do valor total será incluída no dicionário de dados.
Figura3- Modelo de Entidade-Relacionamento parcial para Book.net
Agregação
Até agora vimos relacionamentos apenas entre entidades, mas nada impede que haja relacionamentos entre relacionamentos. Por exemplo, imagine que o modelo inclua o controle de notas fiscais, que deverão ser emitidas para cada compra. A nota fiscal será uma nova entidade, possuindo as seguintes informações: uma numeração única, a data da compra, o cliente que comprou, os livros que foram comprados, a quantidade de cada livro, o valor de venda de cada livro e o valor total da compra. A nota será gerada apenas quando uma compra for efetuada, portanto, a entidade depende do relacionamento COMPRA.
Para modelar esse cenário utilizamos uma abstração, que trata um relacionamento como uma entidade de nível superior. Essa técnica, chamada de agregação, é representada no diagrama como um retângulo que envolve todos os componentes de um relacionamento, como podemos observar na figura 4. Em algumas literaturas, esse retângulo aparece pontilhado.
Figura 4 -Modelo de Entidade-Relacionamento parcial para Book.net
A linha que liga a entidade Nota Fiscal com a agregação vai até o retângulo, indicando que existe um relacionamento com COMPRA. Assim como em relacionamentos entre entidades, também devemos representar as cardinalidades. Nesse caso, uma nota fiscal é gerada por uma compra e uma compra gera apenas uma nota fiscal (1:1).
O retângulo da agregação deve conter apenas um relacionamento. Se precisarmos modelar o relacionamento entre Nota Fiscal e ALUGA devemos criar outro retângulo de agregação para ALUGA. Essa é uma limitação do MER: o diagrama tende a ficar pesado e pouco legível, se possuir muitas agregações. Uma forma de diminuir a poluição visual é colocar as entidades e relacionamentos em posições que facilitem o desenho do retângulo, ou mesmo substituí-lo por um polígono.
Outro fato importante é que o relacionamento que será agregado (no caso, COMPRA), terá sempre cardinalidade N:N. O motivo é que apenas nesse caso encontramos uma relação que seja relevante ao ponto de permitir um relacionamento próprio, como COMPRA, ALUGA ou RESERVA. Nas cardinalidades 1:N ou 1:1, os relacionamentos não possuem a importância necessária para que possam, eles próprios, se relacionarem. Veja um exemplo na relação entre Livro e Editora: não faz sentido uma entidade se relacionar com POSSUI, neste contexto.
Outro detalhe são os atributos de Nota Fiscal: apenas Número foi modelado, pois as demais informações já estão no relacionamento COMPRA.
Entidades Fortes e Fracas
Em alguns casos, uma entidade depende de outra entidade para existir. Quando isso acontece, chamamos a entidade dependente de entidade fraca e a entidade principal de entidade forte. A relação entre essas entidades é conhecida como dependência existencial.
Também podemos dizer que uma entidade fraca é aquela que não apresenta uma visão íntegra, pois precisa da informação de outra entidade para completar a ideia. Por exemplo, a entidade Cliente é forte porque não precisamos de nenhuma outra entidade para completar a ideia de cliente. Esse conceito é fundamental para identificar corretamente as entidades fracas. Por exemplo, poderíamos dizer que a entidade Assunto depende da entidade Livro para existir. No entanto, a entidade Assunto fornece uma ideia completa: ela mapeia um assunto.
Um exemplo de entidade fraca seria ITEM NOTA FISCAL. Essa entidade depende de NOTA FISCAL para existir; Além disso, um item de nota fiscal, por si só, não passa uma ideia completa; se olharmos somente para essa entidade não temos uma visão consistente do que ela representa.
A figura 5apresenta a nova entidade no diagrama. Observe que o relacionamento POSSUI, entre as entidades Nota Fiscal e Item Nota Fiscal, é representado com duas linhas, indicando uma dependência existencial. A entidade fraca também é representada com duas linhas, como podemos ver em Item Nota Fiscal. Como um item de nota possui um livro, essa entidade também se relaciona com Livro.
Figura 5- Modelo de Entidade-Relacionamento parcial para Book.net
NOTA: No Visio, para criar a representação da entidade fraca, basta clicar com o botão inverso do mouse sobre a entidade e selecionar a opção Set as Dependent Entity. Essa opção só está disponível para a entidade; a linha dupla do relacionamento deve ser feita manualmente.
Veja algumas dicas para identificar uma entidade forte/fraca:
- Toda entidade que estiver atrelada ao núcleo do negócio, será uma entidade forte. Na livraria, as entidades Cliente e Livro nunca serão fracas, pois pertencem a regra de negócio principal;
- Normalmente a entidade fraca é criada apenas para detalhar a entidade forte;
- A entidade fraca não existe sem a entidade forte;
- Muitas vezes, a entidade fraca não é identificada no levantamento de requisitos;
- A entidade fraca não fornece uma ideia completa.
Dicionário de Dados
O dicionário de dados está presente no modelo lógico e no modelo físico. Ele representa a descrição detalhada do modelo e possui a mesma importância de qualquer documentação em um projeto: padronizar e facilitar a comunicação entre a equipe. Nele identificamos todas as informações relevantes, como entidades, atributos, relacionamentos, restrições de integridade, regras de derivação, obrigatoriedade do relacionamento, cardinalidades, tipos de atributos e qualquer outra informação que o analista julgue importante. Apesar de algumas literaturas especificarem padrões para a criação do dicionário, na prática, não há um modelo formal para sua construção. No final da série, veremos um dicionário de dados detalhado.
Sugestão para o Dicionário de Dados
Como em toda documentação, inicie descrevendo o objetivo do projeto, indicando que tipo de sistema está sendo modelado e quais regras de negócio ele visa atender. Em seguida, crie as seções abaixo:
- Entidade – Descreva todas as entidades, informando seu objetivo, se é forte ou fraca, com quais entidades ou relacionamentos (agregação) se relaciona e, se possui especialização ou generalização, detalhe seu tipo e as subentidades envolvidas. Para os relacionamentos descreva o nome do relacionamento e as cardinalidades (o relacionamento deve ser detalhado em outra seção).
- Atributos - Para cada entidade, descreva todos os atributos, informando seu objetivo e seu tipo: obrigatório, multi-valorado, composto ou identificador. Defina sua cardinalidade e detalhe as regras de derivação e as restrições de integridade. Na regra de derivação informe a fórmula do cálculo e, caso seja necessário, quais atributos estão envolvidos. Na restrição de integridade descreva a regra em detalhes.
- Relacionamentos – Para cada um, informe seu objetivo e descreva suas restrições de integridade, atributos, entidades envolvidas e se o relacionamento faz parte de uma agregação.
Ao final, adicione todos os comentários considerados importantes para o projeto ou para a comunicação entre a equipe.
Nota: Como esse dicionário de dados pertence ao modelo lógico, não podemos usar termos como tabelas, campos ou tipos de campos.
Figura 6- Modelo de Entidade-Relacionamento completo para Book.net
Conclusão
Nesta edição chegamos ao final do modelo lógico. Vimos as restrições de integridade, regras de derivação, agregação, entidades fortes e fracas e dicionário de dados. Na próxima edição daremos continuidade ao projeto de banco de dados iniciando o modelo físico. Até lá!
