BANCO DE DADOS

As regras de negócio são as diretrizes, políticas e restrições que governam as operações de uma organização. No contexto de banco de dados, elas são a "alma" do sistema, pois definem como as informações devem ser estruturadas para garantir a integridade semântica. Ignorar uma regra de negócio durante a modelagem conceitual resulta em um sistema tecnicamente funcional, mas organizacionalmente inútil. Por exemplo, se a regra diz que "um cliente só pode comprar se não tiver dívidas", o banco de dados deve ser capaz de sustentar essa lógica através de seus atributos e relacionamentos. A influência dessas regras é mais visível nas restrições de integridade. Existem regras que definem a obrigatoriedade de campos (NOT NULL) e a unicidade de identificadores (Primary Key). Se a empresa possui uma política de que "nenhum funcionário pode ser cadastrado sem CPF", essa regra de negócio dita que o atributo CPF deve ser obrigatório no nível físico do banco. A modelagem ...

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...

A transição da linguagem natural — a forma como os usuários descrevem seus problemas — para o Modelo Entidade-Relacionamento (MER) é um dos processos mais desafiadores na engenharia de dados. Esta etapa ocorre logo após a Obtenção e Análise de Requisitos, onde o projetista atua como um tradutor, identificando no "caos" de informações o que é essencial para o sistema. O objetivo aqui é extrair substantivos e verbos que darão origem às entidades e aos relacionamentos, respectivamente. Ao analisar um caso real, como o sistema de uma Companhia, o primeiro passo é identificar as entidades regulares (ou fortes), que são objetos com existência independente, como 'Empregado', 'Departamento' e 'Projeto'. Cada uma dessas entidades possui características específicas chamadas atributos, que precisam ser classificados como simples, compostos ou multivalorados para garantir que a modelagem capture a riqueza da informação. Um erro comum nesta fase inicial é tentar mo...

Nem todas as informações do mini-mundo "moram" dentro das entidades; algumas informações nascem apenas no momento em que duas ou mais entidades se encontram. Estes são os atributos de relacionamento. Eles não descrevem nenhuma das entidades isoladamente, mas sim a propriedade da associação entre elas. O exemplo mais clássico é o atributo 'Horas Trabalhadas' em um relacionamento 'Trabalha-em' entre 'Empregado' e 'Projeto'. As horas não pertencem apenas ao empregado (pois ele trabalha tempos diferentes em projetos diferentes) nem ao projeto (que recebe tempos diferentes de cada funcionário). No Diagrama Entidade-Relacionamento (DER), esses atributos são representados por elipses ligadas diretamente ao losango do relacionamento. Identificar esses dados é vital, pois colocá-los no lugar errado (como dentro da entidade 'Empregado') causaria uma redundância massiva e impediria o registro de múltiplos valores para diferentes projetos. O atribu...

A agregação é uma abstração do MER utilizada quando precisamos representar um relacionamento entre uma entidade e um outro relacionamento. O Modelo Entidade-Relacionamento básico não permite que um losango (relacionamento) se conecte diretamente a outro losango. No entanto, no mundo real, existem situações onde uma associação precisa ser tratada como se fosse uma entidade de nível superior para que possa participar de outros vínculos. A agregação resolve esse problema "envelopando" o relacionamento e as entidades envolvidas em uma caixa, transformando-os em uma única unidade lógica. Imagine um cenário onde 'Médicos' prescrevem 'Medicamentos' para 'Pacientes'. Até aí, temos um relacionamento ternário. Mas suponha que precisemos registrar qual 'Enfermeiro' acompanhou cada 'Prescrição' específica. O enfermeiro não está acompanhando apenas o médico ou apenas o paciente, mas sim o ato da prescrição (o relacionamento). Através da agregação, t...

Outro pilar das hierarquias é a restrição de disjunção, que define se uma instância da superclasse pode pertencer a mais de uma subclasse simultaneamente. A especialização exclusiva (ou disjunta) ocorre quando uma instância da entidade genérica pode ser membro de no máximo uma das subclasses. No diagrama, costuma-se colocar a letra 'd' (de disjoint) dentro de um círculo que conecta as entidades. Exemplo: um 'Funcionário' pode ser 'Atendente' ou 'Gerente', mas a regra da empresa proíbe que ele exerça as duas funções ao mesmo tempo. Por outro lado, temos a especialização sobreposta (overlap). Nela, uma instância da superclasse pode pertencer a duas ou mais subclasses ao mesmo tempo. É representada pela letra 'o' (de overlap). Um exemplo clássico é o de um 'Membro de Universidade': uma mesma pessoa pode ser 'Aluno' e 'Funcionário' simultaneamente (como um aluno bolsista que trabalha na biblioteca). O banco de dados deve estar...

Ao projetar hierarquias, devemos definir se a participação da superclasse na especialização é obrigatória ou opcional. A especialização total (representada por uma linha dupla ligando a superclasse ao triângulo de especialização) indica que toda instância da superclasse deve, obrigatoriamente, pertencer a pelo menos uma das subclasses. Por exemplo, se em uma empresa todo 'Funcionário' deve ser obrigatoriamente ou 'Mensalista' ou 'Horista', temos uma especialização total. Nenhum funcionário pode existir no sistema "puro", sem estar classificado. A especialização parcial, por sua vez, é representada por uma linha simples. Ela indica que uma instância da superclasse pode não pertencer a nenhuma das subclasses definidas no diagrama. Imagine uma hierarquia onde 'Pessoa' pode ser especializada em 'Engenheiro'. Se a empresa possui pessoas que não são engenheiros (como secretárias ou administradores que não foram mapeados como subclasses), a es...