No diagrama de classes, algumas classes são persistentes e outras não. As classes persistentes que pertencem a uma hierarquia de herança devem ser mapeadas de acordo com as opções descritas no item ComposiçãoCada classe persistente restante, de uma forma geral, se transforma em uma tabela. O nome da tabela deve seguir os padrões de nomenclatura do apêndice Padrões de Nomenclatura
O modelo relacional não trata a visibilidade dos atributos. Todos os atributos são públicos. De uma maneira geral, cada atributo de classe se transforma numa coluna da tabela correspondente. A seguir são analisados casos específicos:Para os atributos mono-valorados composto cria-se uma coluna na tabela base para cada um dos componentes do atributo composto.Para os atributos multi-valorados, cria-se uma nova tabela para cada atributo multi-valorado, que possui uma Chave Primária herdada da tabela base (estrangeira).
Deve-se analisar os atributos que obrigatoriamente não podem receber valores nulos e identifica-los no diagrama. Entre os atributos da classe, deve-se identificar a chave primária ou criar um atributo para este fim.
As classes enumeration serão tratadas em código pelo hibernate. Para cada classe que tenha relacionamento com a enumeração deve-se acrescentar uma coluna que armazene o código da enumeração (normalmente do tipo inteiro).
As associações geram a migração da chave primária de uma tabela para a tabela associada, formando uma chave estrangeira. Se a associação define uma dependência existencial, a chave estrangeira deve compor a chave primária da tabela associada.
Recomendado:
Vantagens: O esquema se torna mais extensível. Se houver mudança na cardinalidade não é necessário mudar a estrutura das tabelas.
Desvantagens: fragmentação do esquema e maior overhead de navegação (com joins)
Recomendado:
Existem várias opções de mapeamento:
Para facilitar o mapeamento é necessário identificar/criar um atributo que distingue os objetos de cada subclasse (atributo discriminador) e classificar o tipo de herança segundo os seguintes critérios:
Mutuamente exclusivo: Se um objeto da superclasse pertence a uma categoria representada por apenas uma subclasse. Com sobreposição: Se um objeto da superclasse pode pertencer a categorias representadas por mais que uma subclasse.Participação Total: Todos os objetos da superclasse pertencentes a pelo menos uma categoria representada por alguma subclasse.
Quando não utilizar:
Como mapear:
Considerações gerais:
Quando não utilizar:
Como mapear:
Considerações gerais:
Considerações – Hibernate:
Quando utilizar:
Mutuamente exclusivas
O atributo discriminador deverá fazer parte da relação que representa a superclasse, garantindo que receberá somente um valor. Como mapear:
Considerações gerais:
Existe sobreposição
Como mapear:
Considerações gerais:
Exitem duas opções para mapeamento:
Considerações – Hibernate
Mesmas opções de mapeamento da Agregação.
Numa herança, é possível criar uma View para cada relação que representa as subclasses, no sentido de consolidar os dados herdados e facilitar o acesso ao objeto. A mesma abstração pode ser utilizada para agregações e composições. Exemplo: CREATE VIEW VIEW_SUPERCLASSE ASSELECT A.ID_SUPERCLASSE, ATRIBUTO_SUBCLASSE, ATRIBUTO_SUPERCLASSEFROM SUPERCLASSE AS A JOIN SUBCLASSE AS B ON A.ID_SUPERCLASSE = B.ID_SUPERCLASSE
Um SGBD Relacional não permite encapsular operações (métodos) com classes, mas oferece meios de colocar alguma funcionalidade dos métodos no SGBD.A implementação de stored procedures pode contribuir para particionar o código entre o servidor de BD e as outras camadas da aplicação. As regras a seguir analisam quais funcionalidades são adequadas ou não para serem implementadas em stores procedures.
O que evitar:
O que pode ser colocado no SGBD: