Aula 27: Analisando Casos Reais: De Requisitos ao MER II
Após identificar as entidades e seus atributos básicos, a análise de casos reais deve se aprofundar na dinâmica das associações. Nesta fase, o projetista deve determinar as restrições estruturais dos relacionamentos: a razão de cardinalidade e a participação. Estas regras não são inventadas pelo técnico, mas extraídas rigorosamente do comportamento do negócio. Se o gerente diz que "um empregado pode gerenciar apenas um departamento", isso define uma cardinalidade 1:1 para o relacionamento 'Gerencia'.
A identificação de entidades fracas é outro ponto crítico nesta segunda etapa da análise. Muitas vezes, um requisito descreve objetos que não fazem sentido sozinhos, como os 'Dependentes' de um funcionário. Na análise real, percebemos que um dependente só é mantido no sistema enquanto o funcionário existir, caracterizando uma dependência existencial. Modelar isso corretamente com retângulos de linha dupla no diagrama evita que dados inúteis fiquem "poluindo" o banco no futuro.
Também é o momento de lidar com atributos de relacionamento. Se o caso real diz que "precisamos saber quantas horas por semana cada funcionário trabalha em cada projeto", as 'Horas' não podem ser um atributo de 'Empregado' nem de 'Projeto'. Elas pertencem ao momento do encontro entre ambos, ou seja, ao relacionamento 'Trabalha-em'. Esquecer esse detalhe geraria uma redundância impossível de gerenciar.
Ao finalizar o MER de um caso real complexo, como o esquema da Companhia, o projetista deve revisar todas as conexões. O diagrama resultante é a intenção do banco de dados (o esquema), que permanecerá estável, enquanto os dados reais inseridos serão a extensão. Um MER bem refinado é o segredo para um banco de dados que não "quebra" quando o volume de dados começa a crescer.
Comentários
Postar um comentário