Transformação ER para Relacional

Transformação ER para Relacional
Aula 8 - Unidade 3: Modelagem Lógica no Modelo Relacional
Capítulo 1
Introdução à Transformação ER → Relacional
Por que transformar?
A transformação do modelo conceitual (ER) para o modelo lógico (Relacional) é essencial para implementar bancos de dados funcionais e eficientes nos sistemas reais.
Importância estratégica
Garante que o design conceitual seja convertido em estruturas de dados otimizadas, prontas para implementação em SGBDs relacionais.
Objetivos do processo
Preservar a semântica do modelo ER enquanto cria estruturas de tabelas eficientes, íntegras e livres de redundâncias desnecessárias.
O que é o Modelo Entidade-Relacionamento (ER)?
Origem e propósito
Criado por Peter Chen em 1976, o modelo ER revolucionou a forma como modelamos dados. Trata-se de um modelo conceitual de alto nível, independente de implementação.
Componentes principais
Entidades: objetos do mundo real
Atributos: características das entidades
Relacionamentos: associações entre entidades
O modelo ER facilita a comunicação entre stakeholders técnicos e não-técnicos, criando uma linguagem visual comum para o design de dados.
Exemplo Visual: Diagrama ER Básico
Um diagrama ER simples mostrando as entidades Cliente, Pedido e Produto conectadas por relacionamentos que representam as regras de negócio do domínio.
O que é o Modelo Relacional?
Fundamentos
Modelo lógico proposto por Edgar Codd em 1970, baseado em teoria de conjuntos e álgebra relacional. Organiza dados em estruturas tabulares chamadas relações.
Estrutura básica
Composto por tabelas (relações) com linhas (tuplas) e colunas (atributos). Cada tabela possui chaves primárias para identificação única e chaves estrangeiras para relacionamentos.
Aplicação prática
Base para a maioria dos SGBDs comerciais (Oracle, MySQL, PostgreSQL, SQL Server), permitindo armazenamento estruturado e consultas eficientes através de SQL.
Por que mapear ER para Relacional?
Abstração vs Implementação
O modelo ER é abstrato e independente de tecnologia, focando em conceitos de negócio.
Necessidade prática
O modelo Relacional fornece estruturas concretas necessárias para implementação em SGBDs.
Garantias de qualidade
Assegura integridade referencial, evita redundância e otimiza consultas e desempenho.
Capítulo 2
Regras Gerais de Mapeamento ER → Relacional
01
Entidades fortes
Cada entidade forte se transforma em uma tabela independente, com todos os seus atributos simples como colunas.
02
Chaves primárias
A chave primária da entidade se torna a chave primária (PK) da tabela correspondente, garantindo unicidade.
03
Entidades fracas
Geram tabelas com chave primária composta: combinação da chave da entidade forte (FK) + chave parcial própria.
04
Relacionamentos
Tratados de forma específica conforme a cardinalidade: 1:1, 1:N e N:N têm estratégias distintas de mapeamento.
Transformação de Entidades Fortes
Processo de conversão
Para cada entidade forte no diagrama ER, criamos uma tabela correspondente no modelo relacional.
Mapeamento de atributos
Atributos simples tornam-se colunas diretas
Atributos compostos são desmembrados em componentes atômicos
Atributos derivados geralmente não são armazenados
Definição de chave
A chave primária da entidade é preservada como PK da tabela, garantindo identificação única de cada registro.
Exemplo: Entidade Cliente
Entidade CLIENTE
Representa os clientes no modelo conceitual ER
Tabela CLIENTE no Modelo Relacional
O atributo CPF funciona como chave primária única, identificando inequivocamente cada cliente no sistema.
Transformação de Entidades Fracas
Identificar dependência
Entidade fraca depende existencialmente de uma entidade forte (proprietária) para existir.
Criar tabela
Gerar tabela para a entidade fraca incluindo todos os seus atributos próprios.
Chave composta
PK composta por: chave da entidade forte (FK) + chave parcial discriminadora da entidade fraca.
Manter relacionamento
Incluir todos os atributos da entidade fraca e garantir integridade referencial.
Exemplo: Entidade DEPENDENTE
Tabela DEPENDENTE (entidade fraca)
A chave composta (CPF_Funcionario + Nome_Depend) garante que cada dependente seja único dentro do contexto do seu funcionário responsável. CPF_Funcionario é chave estrangeira referenciando a tabela FUNCIONÁRIO.
Diagrama ER: Entidade Fraca
Visualização da relação de dependência entre FUNCIONÁRIO (entidade forte) e DEPENDENTE (entidade fraca), mostrando como a existência do dependente está condicionada ao funcionário.
Transformação de Relacionamentos 1:1
Estratégia principal
Para relacionamentos um-para-um, inserimos chave estrangeira na tabela da entidade que participa de forma total ou obrigatória no relacionamento.
Alternativa de fusão
Quando ambas as entidades têm participação total, pode-se considerar fundir as duas tabelas em uma única, evitando joins desnecessários.
Escolha da direção
Se ambas participam parcialmente, escolha a entidade com menor número de valores nulos esperados para receber a FK.
Exemplo: Relacionamento GERENCIA (1:1)
Tabela FUNCIONÁRIO
CPF (PK)
Nome
Salário
Data_Admissão
Tabela DEPARTAMENTO
Codigo_Depto (PK)
Nome_Depto
Mgr_CPF (FK)
Data_Inicio_Gerencia
A tabela DEPARTAMENTO recebe o atributo Mgr_CPF como chave estrangeira, referenciando o CPF do funcionário gerente na tabela FUNCIONÁRIO. Cada departamento tem exatamente um gerente.
Transformação de Relacionamentos 1:N
1
Identificar lado N
Determinar qual entidade está no lado "muitos" do relacionamento um-para-muitos.
2
Adicionar FK
Inserir chave estrangeira na tabela do lado N, referenciando a PK da tabela do lado 1.
3
Incluir atributos
Adicionar eventuais atributos próprios do relacionamento como colunas na tabela do lado N.
Exemplo: Relacionamento REALIZA (1:N)
Cliente realiza múltiplos Pedidos
CLIENTE (lado 1)
PEDIDO (lado N)
A tabela PEDIDO recebe o atributo CPF_Cliente como chave estrangeira, estabelecendo que cada pedido pertence a exatamente um cliente, mas cada cliente pode ter vários pedidos.
Transformação de Relacionamentos N:N
Criar tabela associativa
Relacionamentos muitos-para-muitos exigem uma tabela intermediária (tabela de junção ou associativa) para implementação correta.
Chaves estrangeiras
A tabela associativa recebe as chaves primárias de ambas as entidades participantes como chaves estrangeiras.
Chave composta
A combinação das duas FKs geralmente forma a PK composta da tabela associativa.
Atributos próprios
Pode incluir atributos específicos do relacionamento como colunas adicionais.
Exemplo: Relacionamento PRATICA (N:N)
Sócios praticam múltiplos Esportes
1
SÓCIO
CPF (PK)
Nome
Matrícula
2
PRATICA
CPF_Socio (PK, FK)
Codigo_Esporte (PK, FK)
Data_Inicio
Nivel_Habilidade
3
ESPORTE
Codigo_Esporte (PK)
Nome_Esporte
Categoria
A tabela associativa PRATICA possui chave composta (CPF_Socio + Codigo_Esporte) e pode incluir atributos como Data_Inicio e Nivel_Habilidade, que pertencem especificamente ao relacionamento.
Visualização: Tabela Associativa N:N
Representação visual de como uma tabela associativa conecta duas entidades em um relacionamento muitos-para-muitos, eliminando a necessidade de armazenamento redundante.
Tratamento de Atributos Multivalorados
Problema dos multivalorados
Atributos que podem ter múltiplos valores para uma mesma entidade violam a primeira forma normal (1FN) do modelo relacional.
Solução: Tabela separada
Criar uma nova tabela específica para o atributo multivalorado, contendo:
Chave estrangeira da entidade principal
O valor do atributo multivalorado
Chave composta para unicidade
Exemplo: Cliente com Múltiplos Telefones
Tabela CLIENTE
Tabela TELEFONE_CLIENTE
Esta estrutura permite armazenar quantos telefones forem necessários para cada cliente, mantendo a normalização e evitando valores nulos ou campos repetitivos como Telefone1, Telefone2, etc.
Especialização
Tratamento de Especializações (Herança)
Especialização representa relacionamentos de tipo "é-um" (is-a), onde entidades filhas herdam atributos e relacionamentos da entidade pai, adicionando características específicas.
Conceito fundamental
Permite modelar hierarquias de generalização/especialização, onde subtipos compartilham características comuns mas possuem atributos e comportamentos próprios.
Três estratégias de mapeamento
Existem três abordagens principais para transformar hierarquias de especialização em tabelas relacionais, cada uma com vantagens e desvantagens específicas.
Estratégia 1: Tabela Única
Descrição
Criar uma única tabela contendo todos os atributos da entidade pai e de todas as entidades filhas.
Coluna discriminadora
Adicionar uma coluna tipo para identificar qual subtipo cada registro representa.
Vantagens
Simplicidade de implementação
Consultas sem joins complexos
Facilita polimorfismo
Desvantagens
Muitos valores nulos
Tabela pode ficar muito larga
Desperdício de espaço
Exemplo: FUNCIONÁRIO
Estratégia 2: Tabelas Separadas
Tabela pai
Criar tabela para a entidade pai (superclasse) contendo apenas atributos comuns a todos os subtipos.
Tabelas filhas
Criar uma tabela para cada entidade filha (subclasse) com atributos específicos de cada subtipo.
Relacionamento
Cada tabela filha referencia a tabela pai através de chave estrangeira que também é sua chave primária.
Vantagens e desvantagens
Vantagens:
Sem valores nulos
Melhor normalização
Extensibilidade
Desvantagens:
Requer joins em consultas
Mais tabelas para gerenciar
Performance pode ser afetada
Estratégia 3: Tabelas Apenas para Subtipos
Abordagem
Criar tabelas apenas para as entidades filhas, cada uma contendo os atributos herdados do pai mais os próprios atributos específicos.
Sem tabela pai
Não há tabela para a entidade pai - os atributos comuns são duplicados em cada tabela filha.
Aplicação ideal
Funciona melhor quando a especialização é total (todo registro pertence a algum subtipo) e disjunta (sem sobreposição).
Atenção: Esta estratégia pode causar redundância de dados comuns e dificultar consultas que envolvem todos os tipos de funcionários, mas elimina completamente a necessidade de joins.
Exemplo Prático: Especialização FUNCIONÁRIO
Hierarquia: FUNCIONÁRIO → GERENTE e TÉCNICO
Tabela FUNCIONÁRIO
Atributos comuns a todos os funcionários
Tabela GERENTE
Atributos específicos de gerentes
Tabela TÉCNICO
Atributos específicos de técnicos
Diagrama Completo: Especialização no Modelo ER e Relacional
Visualização da transformação de uma hierarquia de especialização do modelo ER (com entidade pai e filhas) para o modelo relacional (com tabelas correspondentes e chaves estrangeiras mantendo a integridade).
Resumo das Regras de Transformação
1
Entidades fortes
Transformam-se em tabelas com chave primária derivada da chave da entidade.
2
Entidades fracas
Geram tabelas com chave primária composta (FK da entidade forte + chave parcial).
3
Relacionamentos 1:1
Chave estrangeira na entidade com participação total ou opcionalmente fusão de tabelas.
4
Relacionamentos 1:N
Chave estrangeira inserida na tabela do lado N do relacionamento.
5
Relacionamentos N:N
Criação de tabela associativa com FKs de ambas as entidades formando PK composta.
6
Atributos multivalorados
Tabela separada com FK da entidade principal mais o valor do atributo.
7
Especializações
Três estratégias: tabela única, tabelas separadas ou tabelas apenas para subtipos.
Dicas para Modelagem Lógica Eficiente
Evite redundância
Elimine duplicação de dados para prevenir anomalias de inserção, atualização e exclusão. Use normalização adequada sem perder desempenho.
Nomenclatura clara
Use nomes descritivos e consistentes para tabelas, colunas e constraints. Siga padrões de nomenclatura estabelecidos (ex: singular/plural, snake_case/camelCase).
Defina chaves corretamente
Garanta que chaves primárias sejam únicas e imutáveis. Configure chaves estrangeiras com ações de integridade referencial (CASCADE, RESTRICT, SET NULL).
Balance normalização e performance
Considere desnormalização estratégica em casos específicos onde o ganho de desempenho justifica redundância controlada.
Conclusão
Base fundamental
A transformação ER → Relacional é um passo crucial na jornada do design conceitual até a implementação real de bancos de dados.
Regras consistentes
Seguir regras claras e sistemáticas facilita o processo de mapeamento e garante integridade e qualidade do modelo resultante.
Flexibilidade com especializações
Compreender as diferentes estratégias para mapear hierarquias de especialização amplia as possibilidades de design e otimização.
Prática contínua
A consolidação do aprendizado vem com a prática constante, preparando você para enfrentar projetos reais com confiança e competência técnica.
Continue praticando, experimentando e refinando suas habilidades em modelagem de dados!