Diretrizes:
|
Elemento do Modelo de Design |
Elemento do Modelo de Dados Correspondente |
---|---|
Classe | Tabela |
Atributo | Coluna |
Associação |
Relacionamento sem Identificação |
Classe de Associação |
Tabela de Interseção |
Agregação Composta |
Relacionamento de Identificação |
Associação de Muitos-para-Muitos |
Tabela de Interseção |
Multiplicidade |
Cardinalidade |
Associação Qualificada |
Tabela de Interseção |
Generalização (Herança) | Tabela Separada |
As classes persistentes no Modelo de Design representam as informações que o sistema deve armazenar. Conceitualmente, essas classes podem se assemelhar a um design relacional. (Por exemplo, as classes no Modelo de Design podem ser refletidas, de certa forma, como entidades no esquema relacional.) Entretanto, à medida que um projeto passa da elaboração para a construção, as metas do Modelo de Design e do Modelo de Dados Relacional divergem. Essa divergência ocorre porque o objetivo do desenvolvimento do banco de dados relacional é normalizar os dados, enquanto a meta do Modelo de Design é encapsular comportamentos cada vez mais complexos. A divergência entre estas duas perspectivas, dados e comportamento, gera a necessidade de mapeamento entre elementos relacionados nos dois modelos.
Em um banco de dados relacional gravado na terceira forma normal, cada linha das tabelas - cada "tupla" - é considerada um objeto. Uma coluna em uma tabela equivale a um atributo persistente de uma classe. (Observe que uma classe persistente pode ter atributos transientes.) Portanto, no simples caso de não haver associações com outras classes, o mapeamento entre os dois mundos é simples. O tipo de dados do atributo corresponde a um dos tipos de dados permitidos para colunas.
Exemplo
A classe Cliente a seguir:
quando modelada no RDBMS é convertida em uma tabela denominada Cliente, com as colunas Customer_ID, Nome e Endereço.
Uma instância dessa tabela pode ser visualizada como:
Para cada atributo persistente, deve-se fazer perguntas para obter informações adicionais que serão utilizadas para modelar adequadamente o objeto persistente em um Modelo de Dados relacional. Por exemplo:
As associações entre dois objetos persistentes são realizadas como chaves estrangeiras para os objetos associados. Uma chave estrangeira é uma coluna em uma tabela que contém o valor da chave principal do objeto associado.
Exemplo:
Suponha que exista a seguinte associação entre Pedido e Cliente:
Quando estas informações são mapeadas para tabelas relacionais, o resultado é uma tabela Pedido e uma tabela Cliente. A tabela Pedido possui colunas para os atributos listados, além de uma coluna adicional denominada Customer_ID, que contém referências de chave estrangeira para a chave principal da linha associada na tabela Cliente. Para um determinado Pedido, a coluna Customer_ID contém o identificador do Cliente ao qual o Pedido está associado. As chaves estrangeiras permitem que o RDBMS una informações relacionadas.
A agregação também é modelada usando relacionamentos de chaves estrangeiras.
Exemplo:
Suponha que exista a seguinte associação entre Pedido e Item de Linha:
Quando estas informações são mapeadas para tabelas relacionais, o resultado é uma tabela Pedido e uma tabela Line_Item. A tabela Line_Item possui colunas para os atributos listados, além de uma coluna adicional denominada Order_ID, que contém uma referência de chave estrangeira para a linha associada na tabela Pedido. Para um determinado Item de Linha, a coluna Order_ID contém o Order_ID do Pedido ao qual o Item de Linha está associado. As chaves estrangeiras permitem que o RDBMS otimize operações de união.
Além disso, é importante implementar uma restrição de exclusão em cascata que forneça integridade referencial no Modelo de Dados. Uma vez feito isso, sempre que o Pedido for excluído, todos os seus Itens de Linha também serão excluídos.
O Modelo de Dados relacional padrão não suporta a herança de modelagem de um modo direto. Várias estratégias podem ser utilizadas para modelar a herança. Elas podem ser resumidas conforme a seguir:
Uma técnica padrão na modelagem relacional é utilizar uma entidade de interseção para representar associações de muitos-para-muitos. A mesma abordagem pode ser aplicada aqui: Uma tabela de interseção é utilizada para representar a associação.
Exemplo:
Se Fornecedores podem oferecer muitos Produtos e um Produto pode ser oferecido por vários Fornecedores, a solução é criar uma tabela Fornecedor/Produto. Esta tabela deve conter somente as chaves principais das tabelas Fornecedor e Produto e serve para vincular os Fornecedores a seus Produtos. Não há uma tabela equivalente a essa no Modelo de Objeto; ela é utilizada apenas para representar as associações no Modelo de Dados relacional.
Depois que as classes de design foram transformadas em tabelas e nos relacionamentos apropriados no Modelo de Dados, o modelo é refinado, conforme necessário, para implementar a integridade referencial e otimizar o acesso a dados por meio de visualizações e procedimentos armazenados. Para obter informações adicionais, consulte Diretrizes: Modelo de Dados.
A maioria das ferramentas de design de aplicativo suportam a geração de scripts DDL (Data Definition Language) a partir de Modelos de Dados e/ou a geração do banco de dados a partir do Modelo de Dados. A engenharia avançada do banco de dados precisa ser planejada como parte das atividades gerais de desenvolvimento e integração de aplicativos. A sincronização e a freqüência para a engenharia avançada do banco de dados a partir do Modelo de Dados depende da situação específica do projeto. Para novos projetos de desenvolvimento de aplicativo que estejam criando um novo banco de dados, pode ser necessário executar a engenharia avançada inicial como parte do trabalho para implementar uma versão arquitetural estável do aplicativo no final da fase de elaboração. Em outros casos, pode ser necessário executar a engenharia avançada inicial logo no início das iterações da fase de construção.
Os tipos de elementos de modelo no Modelo de Dados que podem utilizar a engenharia avançada variam, dependendo das ferramentas de design específicas e do RDBMS utilizado no projeto. Em geral, os principais elementos estruturais do Modelo de Dados, incluindo tabelas, visualizações, procedimentos armazenados, acionadores e índices podem utilizar a engenharia avançada no banco de dados.
![]() |
Conteúdo desenvolvido ou parcialmente desenvolvido por Applied Information Sciences. |
Rational Unified Process
|