Diretrizes: Modelo de Dados
Tópicos
Modelos de Dados são utilizados para projetar a
estrutura dos data stores persistentes utilizados pelo sistema. O perfil UML (Unified Modeling
Language) para o design de banco de dados fornece aos designers do banco de dados
um conjunto de elementos de modelagem que podem ser utilizados para desenvolver o design
detalhado de tabelas no banco de dados e modelar o layout de armazenamento físico do banco de dados.
O perfil do banco de dados UML também fornece construções para modelar a integridade
referencial (restrições e acionadores), bem como procedimentos armazenados utilizados para
gerenciar o acesso ao banco de dados.
Os Modelos de Dados podem ser construídos no nível de aplicativo corporativo,
departamental ou individual. Os Modelos de Dados nos níveis corporativo e departamental podem
ser utilizados para fornecer definições padrão para as principais entidades de negócios (como cliente
e funcionário) que serão utilizadas por todos os aplicativos em um negócio ou uma unidade
de negócios. Esses tipos de Modelos de Dados também podem ser utilizados para definir
qual sistema na corporação é o "proprietário" dos dados para uma entidade de
negócios específica e quais outros sistemas são usuários (assinantes) dos dados.
Esta diretriz descreve os elementos do modelo do perfil UML para a modelagem de
banco de dados utilizada na construção de um Modelo de Dados para um banco de dados relacional. Como
existem inúmeras publicações sobre teoria geral de bancos de dados, essa área não
é abrangida. Para obter informações de segundo plano sobre Modelos de Dados
e Modelos de Objetos relacionais, consulte Conceitos:
Bancos de Dados Relacionais e Orientação de Objetos.
Nota: As representações de modelagem de dados contidas nesta diretriz baseiam-se
na UML 1.3. Quando esta diretriz foi desenvolvida, o perfil de modelagem de dados
UML 1.4 não estava disponível.
Conforme descrito em [NBG01], há três
estágios gerais no desenvolvimento de um Modelo de Dados: conceitual, lógico e
físico. Estes estágios de modelagem de dados refletem os diferentes níveis de
detalhes no design dos mecanismos de armazenamento de dados persistentes e de recuperação
do aplicativo. Uma discussão de modelagem de dados conceituais é fornecida em
Conceitos:
Modelagem de Dados Conceituais. Resumos de modelagem de dados físicos
e lógicos são fornecidos nas próximas duas seções desta diretriz.
Modelagem de Dados Lógicos

Na modelagem de dados lógicos, o designer de banco de dados
preocupa-se em identificar as principais entidades e os relacionamentos que capturam
as informações críticas que o aplicativo precisa para persistir no banco de dados.
Durante as atividades de análise de caso de uso, design de
caso de uso e design de classe,
o designer de banco de dados e o designer
devem trabalhar juntos para assegurar que os designs de evolução das classes de análise e
de design para o aplicativo suportem adequadamente o desenvolvimento do banco de dados.
Durante a atividade de design de classe, o
designer de banco de dados e o designer devem identificar o conjunto de classes no Modelo
de Design que precisará persistir dados no banco de dados.
Esse conjunto de classes persistentes no Modelo de Design fornece uma Visualização de
Modelo de Dados que, embora diferente do Modelo de Dados Lógicos tradicional, atende
a muitas das mesmas necessidades. As classes persistentes no Modelo de
Design funcionam da mesma maneira que as entidades tradicionais no Modelo de Dados
Lógicos. Essas classes de design refletem exatamente os dados que devem ser persistidos,
incluindo todas as colunas de dados (atributos) que devem ser persistidas e os principais
relacionamentos. Isso torna essas classes de design um excelente ponto inicial para
o design de banco de dados físico.
A criação de um Modelo de Dados Lógico separado é uma opção. No entanto, no melhor caso
isso acabaria capturando as mesmas informações de uma forma diferente. No pior
isso não ocorreria e, portanto, no final poderia não atender às necessidades de
negócios do aplicativo. Particularmente, se o banco de dados destina-se a servir um único
aplicativo, a visualização dos dados do aplicativo pode ser o melhor ponto
inicial. O designer de banco de dados cria tabelas a partir desse conjunto de classes de
design persistente para formar um Modelo de Dados Físicos.
Além disso, podem existir situações que exijam que o designer de banco de dados
crie um design idealizado do banco de dados que seja independente do design de
aplicativo. Nesse caso, o design de banco de dados lógico é representado em um
Modelo de Dados Lógicos que faz parte do Artefato:
Modelo de Dados geral. Esse Modelo de Dados Lógicos representa as principais entidades
lógicas e seus relacionamentos, que são necessários para atender aos requisitos do sistema
para persistência de dados consistentes com a arquitetura geral do aplicativo. O
Modelo de Dados Lógicos pode ser construído utilizando os elementos de modelagem do
perfil da UML para o design de banco de dados descrito nas seções posteriores desta diretriz. Para
projetos que utilizam esta abordagem, a colaboração estrita entre os designers de
aplicativo e de banco de dados é absolutamente crítica para o desenvolvimento
bem-sucedido do design de banco de dados.
O Modelo de Dados Lógicos pode ser refinado aplicando-se as regras padrão para
normalização, conforme definido em Conceitos:
Normalização antes de desenvolver os elementos do Modelo de Dados Lógicos para
criar o design físico do banco de dados.
A figura a seguir representa a abordagem principal de utilização das classes de
Modelo de Design como a origem das informações lógicas do design de banco de dados para
criar um Modelo de Dados Físicos inicial. Também ilustra a abordagem alternativa de utilização
de um Modelo de Dados Lógicos separado.

Abordagens de Modelagem de Dados Lógicos
Modelagem de Dados Físicos
A modelagem de dados físicos é o estágio final do desenvolvimento no design de banco
de dados. O Modelo de Dados Físicos consiste nos designs detalhados das tabelas
do banco de dados e seus relacionamentos criados inicialmente a partir das classes de
de design persistentes e seus relacionamentos. A mecânica para executar a transformação
das classes de Modelo de Design em tabelas é descrita em
Diretrizes: Bancos de Dados Relacionais de Engenharia Avançada. O Modelo
de Dados Físicos faz parte do Modelo de Dados;
ele não é um artefato separado.
As tabelas no Modelo de Dados Físicos possuem colunas bem definidas, além de
chaves e índices, conforme necessário. As tabelas também podem ter acionadores definidos, conforme necessário,
para suportar a funcionalidade do banco de dados e a integridade referencial do sistema.
Além das tabelas, os procedimentos armazenados foram criados, documentados
e associados ao banco de dados no qual residirão.
O diagrama a seguir mostra um exemplo de alguns elementos do Modelo de Dados
Físicos. Este modelo de exemplo é uma parte do Modelo de Dados Físicos de
um aplicativo de leilão on-line fictício. Ele representa quatro tabelas (Leilão, Lance,
Item e Categoria de Leilão), juntamente com um procedimento armazenado (sp_Auction) e
sua classe de contêiner (AuctionManagement). A figura também representa as colunas
de cada tabela, as restrições de chave principal e chave estrangeira e os índices
definidos para as tabelas.

Exemplo de Elementos do Modelo de Dados (Físicos)
O Modelo de Dados Físicos também contém mapeamentos das tabelas para unidades de
armazenamento físico (espaços de tabelas) no banco de dados. A figura a seguir mostra um exemplo
deste mapeamento. Neste exemplo, as tabelas Leilão e OrderStatus são
mapeadas para um espaço de tabelas denominado PRINCIPAL. O diagrama também ilustra a modelagem
da realização das tabelas no banco de dados (nomeado PearlCircle neste exemplo).

Exemplo de Elementos do Modelo de Armazenamento de Dados
Em projetos nos quais um banco de dados já existe, um designer de banco de dados pode reverter
a engenharia do banco de dados existente para preencher o Modelo de Dados Físicos. Consulte Diretrizes:
Bancos de Dados Relacionais de Engenharia Reversa para obter informações adicionais.
Esta seção descreve as diretrizes gerais de modelagem para cada elemento principal
do Modelo de Dados com base no perfil UML para modelagem do banco de dados. Uma descrição breve
de cada elemento do modelo é seguida por uma ilustração de exemplo do elemento do modelo
UML. A seção Relacionamentos desta diretriz
inclui uma descrição do uso dos elementos do modelo.
Os pacotes UML padrão são utilizados para agrupar e organizar elementos do Modelo de Dados.
Por exemplo, os pacotes poderiam ser definidos para organizar o Modelo de Dados em Modelos
de Dados Lógicos e Físicos. Os pacotes também poderiam ser utilizados para identificar
grupos logicamente relacionados de tabelas no Modelo de Dados que constituem as principais
"áreas de assunto" de dados de importância para o domínio de negócios do aplicativo
que está sendo desenvolvido. A figura a seguir mostra um exemplo de dois pacotes de
área de assunto (Gerenciamento de Leilão e Gerenciamento de Conta do Usuário) utilizados
para organizar visualizações e tabelas no Modelo de Dados.

Exemplo de Pacotes de Área de Assunto
No perfil UML para modelagem do banco de dados, uma tabela é modelada como uma classe com
um estereótipo de <<Tabela>>. As colunas na tabela são modeladas como atributos
com o estereótipo de <<coluna>>. Uma ou mais colunas podem ser designadas como
uma chave principal para fornecer entradas de linhas exclusivas na tabelas. As colunas também
podem ser designadas como chaves estrangeiras. As chaves principais e as chaves estrangeiras
possuem restrições associadas que são modeladas como operações estereotipadas como <<Chave
Principal>> e <<Chave Estrangeira>>, respectivamente. A figura a seguir representa a estrutura
de uma tabela de exemplo utilizada para gerenciar informações sobre itens vendidos em
leilão em um sistema de leilões on-line fictício.

Exemplo de Tabela
As tabelas podem estar relacionadas a outras tabelas pelos tipos de relacionamentos a seguir:
- identificação (agregação composta)
- sem identificação (associação)
A seção Relacionamentos desta diretriz fornece
exemplos de como esses relacionamentos são utilizados. As informações sobre como esses tipos de
relacionamentos podem ser mapeados para os elementos do Modelo de Design aparecem em Diretrizes:
Bancos de Dados Relacionais de Engenharia Reversa.
Um acionador é uma função de procedimentos projetada para ser executada como resultado de
alguma ação na tabela na qual o acionador reside. Um acionador é definido para ser executado
quando uma linha na tabela é inserida, atualizada ou excluída. Além disso, um acionador
é projetado para ser executado antes ou após a execução do comando da tabela.
Os acionadores são definidos como operações em uma tabela. As operações são estereotipadas
como <<Acionador>>.

Exemplo de Acionador
Os índices são utilizados como mecanismos para permitir acesso mais rápido às informações
quando colunas específicas são utilizadas para procurar a tabela. Um índice é modelado como
uma operação na tabela com um estereótipo de <<índice>>. Os índices poderiam
ser designados como exclusivos e como armazenados em cluster ou não armazenados em cluster.
Os índices armazenados em cluster são utilizados para forçar a ordem das linhas de dados
na tabela a ser alinhada com a ordem dos valores de índice. Um exemplo de uma operação de índice
(IX_auctioncategory) é mostrado na figura a seguir.

Exemplo de Índice
Uma visualização é uma tabela virtual sem armazenamento persistente independente. Uma visualização
possui as características e os comportamentos de uma tabela e acessa os dados nas colunas a
partir das tabelas com as quais a visualização possui relacionamentos definidos. As visualizações
são utilizadas para fornecer acesso mais eficiente às informações de uma ou mais tabelas
e também podem ser utilizadas para aplicar regras de negócios para restringir o acesso a dados
nas tabelas. No exemplo a seguir, uma AuctionView foi definida como uma "visualização"
de informações na tabela Leilão mostrada na seção de modelagem de dados físicos
desta diretriz.
As visualizações são modeladas como classes com o estereótipo de <<visualização>>. Os atributos
da classe de visualização são as colunas das tabelas referenciadas pela visualização. Os
datatypes das colunas na visualização são herdados das tabelas com uma dependência
definida com a visualização.

Exemplo de Visualização
Um domínio é um mecanismo utilizado para criar datatypes definidos pelo usuário que podem ser
aplicados a colunas em várias tabelas. Um domínio é modelado como uma classe com
o estereótipo <<Domínio>>. No exemplo a seguir, um domínio foi definido
para um CEP "CEP + 4".

Exemplo de Domínio
Um contêiner de procedimentos armazenados é um agrupamento de procedimentos armazenados no
Modelo de Dados. Ele é criado como uma classe UML com o estereótipo de
<<Contêiner de SP>>. Vários contêineres de procedimentos armazenados podem ser criados
em um design de banco de dados. Cada um deles deve ter pelo menos um procedimento armazenado.
Um procedimento armazenado é um procedimento independente que geralmente reside no
servidor de banco de dados. Os procedimentos armazenados são documentados como operações agrupadas
em classes estereotipadas como <<Contêiner de SP>>. As operações são estereotipadas como <<SP>>.
O exemplo a seguir mostra uma única operação de procedimento armazenado (SP_Auction) em
uma classe de contêiner denominada AuctionManagement. Ao projetar procedimentos armazenados,
o designer de banco de dados deve estar ciente de quaisquer convenções de nomenclatura utilizadas
pelo RDBMS específico.

Exemplo de Contêiner de Procedimentos Armazenados e de Procedimento Armazenado
Um espaço de tabelas representa a quantidade de espaço de armazenamento a ser alocado para
itens como tabelas, procedimentos armazenados e índices. Os espaços de tabelas estão vinculados a um
banco de dados específico por meio de um relacionamento de dependência. O número de espaços de tabelas
e como as tabelas individuais serão mapeadas para eles dependem da complexidade do
Modelo de Dados. Pode ser necessário particionar as tabelas que serão acessadas
com freqüência em vários espaços de tabelas. As tabelas que não contêm grandes quantidades
de dados freqüentemente acessados podem ser agrupadas em um único espaço de tabelas.
Um contêiner de espaços de tabelas é definido para cada espaço de tabelas. O contêiner de espaços de tabelas
é o dispositivo de armazenamento físico para o espaço de tabelas. Embora vários contêineres de
espaços de tabelas possam existir para um único espaço de tabelas, recomenda-se que um contêiner
de espaços de tabelas seja designado a apenas um único espaço de tabelas. Os contêineres de espaços de tabelas são
definidos como atributos para o espaço de tabelas; eles não são modelados explicitamente.

Exemplo de Espaço de Tabelas
Um esquema documenta a organização ou estrutura do banco de dados. Um esquema é
representado como um pacote com o estereótipo de <<Esquema>>. Quando um esquema é definido
como um pacote, as tabelas que compõem esse pacote deve estar contidas no
esquema. Uma dependência entre o banco de dados e o esquema é criada para
documentar o relacionamento entre o banco de dados e o esquema.

Exemplo de Esquema
Uma banco de dados é uma coleção de dados que são organizados de modo que as informações
contidas nele possam ser acessadas e gerenciadas. O gerenciamento e o acesso de informações
no banco de dados são executados utilizando-se um DBMS (Database Management System)
comercial. Um banco de dados é representado no Modelo de Dados como um componente
estereotipado como <<Banco de Dados>>.

Exemplo de Banco de Dados
O perfil UML para a modelagem do banco de dados define os relacionamentos válidos entre
os principais elementos do Modelo de Dados. As seções a seguir fornecem exemplos
dos diferentes tipos de relacionamentos.
Sem Identificação
Um relacionamento sem identificação é um relacionamento entre duas tabelas que
existem independentemente no banco de dados. Um relacionamento sem identificação é
documentado utilizando-se uma associação entre as tabelas. A associação é
estereotipada como <<Sem Identificação>>. O exemplo a seguir descreve um relacionamento
sem identificação entre a tabela Item e a tabela AuctionCategory.

Exemplo de Relacionamento Sem Identificação
Identificação
Um relacionamento de identificação é um relacionamento entre duas tabelas nas
quais a tabela-filha deve coexistir com a tabela-pai. Ele é documentado
utilizando uma agregação composta entre duas tabelas. A agregação composta
possui o estereótipo de <<Identificação>>. A figura a seguir é um exemplo
de relacionamento de identificação. Este exemplo mostra que as instâncias da tabela-filha
(CreditCard) devem ter uma entrada associada na tabela-pai (UserAccount).

Exemplo de Relacionamento de Identificação
Para a agregação de associação e composta, a
multiplicidade deve ser definida para documentar o número de linhas no
relacionamento. No exemplo acima, para cada linha na tabela UserAccount, pode haver
0 ou mais linhas CreditCard na tabela CreditCard. Para cada linha na
tabela CreditCard, há exatamente uma linha na tabela UserAccount.
A multiplicidade também é conhecida como cardinalidade.
Visualizações de Banco de Dados
Ao definir o relacionamento de uma visualização de banco de dados com uma tabela, utiliza-se um
relacionamento de dependência desenhado da visualização para a tabela. O estereótipo da dependência
é <<Derivar>>. Geralmente, a dependência de visualização é nomeada e o nome da
dependência é igual ao nome da tabela definida no relacionamento de dependência
com a visualização do banco de dados.

Exemplo de Relacionamento de Dependência entre a Visualização e a Tabela
Espaço de Tabelas
Um relacionamento de dependência é utilizado para vincular um espaço de tabelas a um banco de dados específico.
Conforme mostrado na figura a seguir, o relacionamento é desenhado para mostrar que o
banco de dados possui a dependência no espaço de tabelas. Vários espaços de tabelas podem estar relacionados
a um único banco de dados no modelo.

Exemplo de Relacionamento de Dependência entre o Espaço de Tabelas e o Banco de Dados
Um relacionamento de dependência é utilizado para documentar os relacionamentos entre
espaços de tabelas e as tabelas em um espaço de tabelas. Uma ou mais tabelas podem estar relacionadas
a um único espaço de tabelas e uma única tabela pode estar relacionada a vários espaços de tabelas.
O exemplo a seguir mostra que a tabela Leilão está designada a um único espaço de tabelas
denominado PRINCIPAL.

Exemplo de Relacionamento de Dependência entre a Tabela e o Espaço de Tabelas
Realizações
As realizações são utilizadas para estabelecer o relacionamento entre um banco de dados
e as tabelas que existem nele. Uma tabela pode ser realizada por vários banco de dados
no Modelo de Dados.

Exemplo de Relacionamento de Realização entre a Tabela e o Banco de Dados
Procedimentos Armazenados
Um relacionamento de dependência é utilizado para documentar o relacionamento entre
o contêiner de procedimentos armazenados e as tabelas sobre as quais os procedimentos nos
contêineres agem. O exemplo a seguir representa esse tipo de
relacionamento, mostrando que o procedimento armazenado SP_Auction será utilizado
para acessar informações na tabela Leilão.

Exemplo de Relacionamento de Dependência entre o Contêiner de Procedimentos
Armazenados e a Tabela
Na fase de iniciação, as atividades iniciais
da modelagem de dados podem ser executadas em conjunto com o desenvolvimento de quaisquer
protótipos de prova de conceito como parte das atividades para "Executar detalhes do
workflow da síntese arquitetural". Em projetos nos quais um banco de dados já existe,
o designer de banco de dados pode reverter a engenharia do banco de dados existente para
desenvolver um Modelo de Dados Físicos inicial com base na estrutura do banco de dados
existente. ConsulteDiretrizes: Bancos de Dados Relacionais de
Engenharia Reversa para obter informações adicionais. Os elementos do Modelo de Dados Físicos podem
ser transformados em elementos do Modelo de Design, conforme necessário, para suportar
quaisquer atividades de criação de protótipo de prova de conceito.
A meta da fase de elaboração é eliminar
o risco técnico e produzir uma arquitetura estável (com linha de base) para o
sistema. Em sistemas de larga escala, o desempenho insatisfatório resultante de um Modelo de
Dados projetado incorretamente é a principal preocupação arquitetural. Como conseqüência, a
modelagem de dados e o desenvolvimento de um protótipo arquitetural que permita que o desempenho
do banco de dados seja avaliado são essenciais para a obtenção de uma arquitetura estável. Como
os casos de uso arquiteturalmente significativos são detalhados e analisados em cada
iteração, os elementos do Modelo de Dados são definidos com base no desenvolvimento dos
designs de classe persistentes dos casos de uso. À medida que os designs de classe se estabilizam, o designer de
banco de dados pode, periodicamente, transformar os designs de classe em tabelas no Modelo
de Dados e definir os elementos apropriados do modelo de armazenamento de dados.
No final da fase de elaboração, as principais estruturas do banco de dados (tabelas,
índices e colunas de chave principal e estrangeira) devem ser utilizadas para suportar
a execução dos cenários definidos, significativos do ponto de vista arquitetural, para o aplicativo.
Além disso, volumes de dados representativos devem ser carregados no banco de dados para
suportar o teste de desempenho arquitetural. Com base nos resultados do teste de desempenho,
talvez o Modelo de Dados precise ser ajustado com técnicas de otimização, incluindo,
mas não se limitando a desnormalização, otimização de atributos de armazenamento físico
ou distribuição e indexação.
A reestruturação principal do Modelo de Dados não deve ocorrer durante a fase de
construção. Tabelas e elementos de armazenamento de dados adicionais podem ser
definidos durante as iterações da fase de construção com base no design detalhado do conjunto
de casos de uso e controles de mudanças alterados, alocados para a interação. O foco
principal do design de banco de dados durante a fase de construção é monitorar continuamente
o desempenho do banco de dados e otimizar o design de banco de dados, conforme necessário,
por meio da desnormalização, definição de índices, criação de visualizações de banco de
dados e outras técnicas de otimização.
O Modelo de Dados Físicos é o artefato de design que o designer de banco de dados mantém
durante a fase de construção. É possível mantê-los fazendo atualizações
diretas no modelo ou como resultado de uma ferramenta que lê atualizações que foram
feitas diretamente no banco de dados.
O Modelo de Dados, como o Modelo de Design, é mantido durante a fase de
transição em resposta a controles de mudanças aprovados. O design de banco de dados deve
manter o Modelo de Dados sincronizado com o banco de dados enquanto o aplicativo passa
pelo teste de aceitação final e é implementado na produção.
Se uma equipe de desenvolvimento estiver utilizando modernas ferramentas de modelagem visual que tenham
a capacidade de converter classes em tabelas (e vice-versa) e/ou tenham a capacidade para reverter
e encaminhar bancos de dados de engenharia avançada, a equipe precisará estabelecer diretrizes
para gerenciar os processos de transformação e engenharia. As diretrizes
são necessárias principalmente para projetos grandes em que uma equipe trabalha em
paralelo no design de banco de dados e de aplicativo. A equipe de desenvolvimento deve
definir os pontos no desenvolvimento do aplicativo (ciclo de construção/liberação) em que
será apropriado executar as transformações de classe em tabela e a engenharia
avançada do banco de dados. Após a criação do banco de dados inicial, a equipe
de desenvolvimento deve definir diretrizes para a equipe gerenciar a sincronização
do Modelo de Dados e do banco de dados à medida que o design e o código do sistema
evoluem no projeto.
|