Artefato: Modelo de Dados

O Modelo de Dados é utilizado para descrever a estrutura lógica e física das informações persistentes gerenciadas pelo sistema. O modelo de dados pode ser criado inicialmente pela engenharia reversa nos armazenamentos de dados (bancos de dados) persistentes existentes ou a partir de um conjunto de Classes de Design persistentes no Modelo de Design.

O modelo de dados é necessário sempre que o mecanismo de armazenamento persistente é baseado em uma tecnologia não orientada a objetos. O modelo de dados é necessário especificamente quando a estrutura de dados persistentes não pode ser obtida mecânica e automaticamente da estrutura de classes persistentes no modelo de design. Além de definir estruturas de dados persistentes, ele é usado para definir o mapeamento entre classes de design persistentes e estruturas de dados persistentes.

A tabela de propriedades a seguir descreve os elementos do modelo de dados. As definições das propriedades do modelo incluídas nesta tabela estão consistentes com o perfil de modelagem de dados da versão 1.3 da especificação UML (Unified Modeling Language). Os elementos do perfil de modelagem de dados da UML versão 1.4 ainda não foram definidos.

Opções de Representação

Representação UML: Um pacote estereotipado como <<modelo>>.

O modelo de dados pode ter as seguintes propriedades:

Nome da Propriedade	Descrição Resumida	Representação UML
Introdução	É uma descrição textual que funciona como uma rápida introdução do modelo.	Valor rotulado, do tipo "texto curto".
Pacotes	Os pacotes usados para fins de agrupamento organizacional.	Incluídos por meio da associação "representa" ou recursivamente por meio da agregação "possui".
Tabelas	As tabelas do modelo de dados, pertencentes aos pacotes.	Classes, estereotipadas como «Tabela».
Relação	Associação simples entre tabelas no modelo.	Associação, estereotipada como «Não-identificando»
Forte Relação	Relação de Agregação Composta entre tabelas no modelo.	Associação, estereotipada como «Identificando»
Dependência (Visualização em Tabela)	Dependência entre Tabelas, Visualizações e outros elementos de modelo	Dependência, estereotipada como «Derivação» para relações de dependência entre Tabela e Visualização
Coluna	Os valores de dados das tabelas.	Atributo, estereotipado como «Coluna».
Domínio	Um tipo de dados definido pelo usuário.	Classe, estereotipada como «Domínio».
Visualização	Uma tabela virtual, composta por colunas de uma ou mais tabelas.	Classe, estereotipada como «Visualização».
Diagramas	Os diagramas do modelo, pertencentes aos pacotes.	Diagramas de classes, que representam tabelas e suas relações, e diagramas de componentes, que representam a realização das tabelas no modelo para componentes de espaços de tabelas e de banco de dados.
Índice	As estruturas de acesso a dados usadas para acelerar o acesso em caminhos especificados.	Operação, estereotipada como «Índice».
Disparo	Comportamento ativado por evento e associado a tabelas.	Operação, estereotipada como «Disparo».
Restrição de verificação	Uma regra de validação em uma coluna ou tabela. Pode consistir em um intervalo de valores ou cálculos válidos.	Operação, estereotipada como «Verificação».
Restrição exclusiva	Indica que os dados em uma coluna ou conjunto de colunas devem ser exclusivos.	Operação, estereotipada como «Exclusivo».
Pacote de Procedimento Armazenado	Uma Classe que é utilizada como um "contêiner" para operações de Procedimento Armazenado	Classe, estereotipada como «Contêiner_SP»
Procedimento Armazenado	Comportamento chamado de forma explícita, associado a tabelas ou ao modelo como um todo.	Operação, estereotipada como «SP».
Esquema	Contêiner para elementos do modelo de dados que representa a estrutura geral do banco de dados. Utilizado para gerenciar a segurança e a propriedade de tabelas.	Pacote estereotipado como «Esquema».
Banco de Dados	Elemento de modelo que representa o banco de dados físico	Componente, estereotipado como «Banco de Dados»
Espaço de Tabelas	Unidades de armazenamento físico em um banco de dados	Componente, estereotipado como «Espaço de Tabelas»

Para projetos com poucos dados persistentes, ou com uma transformação direta das classes de design para o mecanismo de persistência, um modelo de dados separado pode não ser necessário. Para projetos que utilizam um RDBMS para obter persistência, o modelo de dados precisará ser adaptado à semântica específica do banco de dados básico, que pode variar um pouco entre os RDMBSes.