A finalidade do Modelo de Dados Lógico é fornecer uma visualização ideal das principais entidades de dados lógicas e suas relações, o que independe da implementação de qualquer banco de dados ou software específico. Geralmente, é na terceira forma normal (consulte Conceito: Normalização), que é uma forma de modelagem de dados que minimiza a redundância e assegura a ausência de dependências transitivas. Tal modelo diz respeito à aparência que o banco de dados terá quando capturar dados, e não aos aplicativos que utilizam os dados e sua respectiva execução. Observe que um Modelo de Dados Lógico é considerado parte do Produto de Trabalho: Modelo de Dados e não é um produto de trabalho separado do RUP. Entretanto, muitas vezes, é importante definir Modelos de Dados Lógicos para:

• projetos nos quais os designs de aplicativo e de banco de dados são desenvolvidos por equipes separadas.
• projetos nos quais vários aplicativos compartilharão um banco de dados comum.

Se você estiver criando um Modelo de Dados Lógico, poderá começar do zero, utilizando os elementos de modelo abordados em Diretrizes do Produto de Trabalho: Modelo de Dados ou você pode iniciar com entidades para cada classe persistente no Modelo de Análise ou Modelo de Design.

Você poderá optar por não criar um Modelo de Dados Lógico separado, principalmente se estiver projetando um banco de dados que seja adequado para um aplicativo individual. Nesse caso, o Designer de Banco de Dados desenvolve Modelo de Dados Físico, com base no conjunto de classes persistentes e em suas associações no Modelo de Design.

Em qualquer abordagem, é importante que o Designer de Banco de Dados e o Designer colaborem em todo o processo de design e análise para identificar quais classes no Produto de Trabalho: Modelo de Design precisam armazenar informações em um banco de dados. Conforme descrito na etapa com o título, "Identificar classes persistentes da Tarefa: Design de Classe," o designer de banco de dados trabalha com o designer para identificar quais classes de design no Modelo de Design Model são consideradas persistentes e possíveis candidatas a transformarem-se em tabelas no banco de dados.

O design físico do banco de dados inclui os elementos de modelo (como tabelas, visualizações e procedimentos armazenados), que representam a estrutura física detalhada do banco de dados, e os elementos de modelo (como esquemas e espaços de tabelas), que representam o design básico de armazenamento de dados do banco de dados.  Coletivamente, esses elementos de modelo formam o Modelo da Dados Físico do banco de dados.  Esse Modelo de Dados Físico está contido no Produto de Trabalho: Modelo de Dados e não é um produto de trabalho de modelo separado.

As etapas detalhadas do desenvolvimento do design físico do banco de dados são as seguintes:

• Defina os domínios.
• Criar elementos de design de banco de dados inicial.
• Definir tabelas de referência
• Criar chave primária e restrições exclusivas
• Definir regras de cumprimento de integridade referencial e dados.
• Desnormalizar o design de banco de dados para otimizar para o desempenho.
• Otimizar acesso a dados.
• Definir características de armazenamento
• Projetar procedimentos armazenados para distribuir comportamento de classe ao banco de dados.

Definir Domínios

Domínios poderão ser utilizados pelo designer de banco de dados para impor padrões de tipo em todo o design do banco de dados. Domínios são tipos de dados definidos pelo usuário que podem ser aplicados a uma coluna de uma tabela.  Os domínios contêm propriedades de uma coluna sem o nome. 

Criar Elementos de Design do Banco de Dados Físico Inicial

O designer de banco de dados modela os elementos do Modelo de Dados Físico utilizando tabelas e colunas em tabelas, conforme descrito em Diretrizes do Produto de Trabalho: Modelo de Dados. 

Se um Modelo de Dados Lógico foi criado, suas entidades lógicas poderão ser utilizadas como a base para um conjunto inicial de tabelas.

Como alternativa, o designer do banco de dados poderá pular para o início do Modelo de Dados Físico, utilizando as classes persistentes no Modelo de Design como um ponto de partida para as tabelas no Modelo de Dados Físico.  O designer de banco de dados modela as classes persistentes e seus atributos, como tabelas e colunas respectivamente.  O designer de banco de dados precisa também definir as relações entre as tabelas, com base nas associações entre as classes persistentes no Modelo de Design.  Uma descrição de como os elementos e as relações do Modelo de Design são mapeados para os elementos e as relações do Modelo de Dados é fornecida em Diretrizes do Produto de Trabalho: Encaminhar Bancos de Dados Relacionais de Engenharia.

Se você estiver iniciando o modelo partindo das classes persistentes e não de um Modelo de Dados Lógico normalizado, será necessário aplicar uma normalização a fim de eliminar redundâncias de dados e dependências de campo não-chave. Consulte Conceito: Normalização, para obter informações adicionais sobre normalização de banco de dados.

Definir Tabelas de Referência

É freqüente a existência de um padrão para as tabelas de pesquisa, tabelas de validação e tabelas de referência usadas no projeto. Visto que os dados dessas tabelas costumam ser acessados com freqüência, mas raramente são alterados, vale a pena dar uma atenção especial a eles. No Modelo de Design, essas tabelas poderão conter códigos padrão de produto, códigos de estado ou município, códigos postais, tabelas de tarifas, tabelas de validação de códigos de área ou outras informações acessadas com freqüência. Nos sistemas financeiros, essas tabelas poderão conter listas de códigos de política, categorias de classificação de apólices de seguro ou taxas de conversão. No Modelo de Design, procure pelas classes que são fundamentalmente de leitura, que forneçam informações de validação para um grande número de clientes.

Se a tabela de referência for pequena, não se dê ao trabalho de indexá-la, já que a indexação pode efetivamente acrescentar uma sobrecarga adicional a tabelas pequenas. Uma tabela pequena, acessada com freqüência, costuma permanecer na memória, visto que os algoritmos de armazenamento em cache muitas vezes mantêm essas tabelas no cache de dados.

Se for possível, certifique-se de que o cache do banco de dados seja grande o suficiente para manter na memória todas as tabelas de referência, junto com o "espaço do conjunto de trabalho" normal destinado a consultas e transações. Em geral, o segredo para aumentar o desempenho do banco de dados é reduzir a E/S do disco.

Depois de definidas as estruturas das tabelas de referência, defina uma estratégia para preenchê-las. Como essas tabelas são acessadas logo no começo do projeto, definir os valores de referência e carregar as tabelas são tarefas que muitas vezes precisam ser executadas mais ou menos no início do projeto, durante o tempo de execução do aplicativo. Embora o designer de banco de dados não seja responsável pela obtenção de dados, é sua responsabilidade determinar como e quando as tabelas de referência serão atualizadas.

Criar Chave Primária e Restrições Exclusivas

Chave primária é uma ou mais colunas que identifica exclusivamente as linhas de uma tabela. Uma tabela possui uma única chave primária. Muitas vezes, existe uma chave "natural" que pode ser utilizada para identificar exclusivamente uma linha de dados (por exemplo, o código postal em uma tabela de referência). A chave primária não deve conter dados que possam ser alterados com o ambiente de negócios. Se a chave "natural" for um valor que pode ser alterado (por exemplo o nome de uma pessoa), recomenda-se que o designer do banco de dados crie uma coluna sem sentido exclusiva, não digitada por usuário, ao criar uma chave primária. Isso gera uma estrutura de dados com maior capacidade de adaptação a mudanças ocorridas no ambiente, nas regras e na estrutura de negócios.

Utilizar como chave primária sem sentido e não digitada por usuário é um conceito fundamental no design de um armazém de dados. Sistemas transacionais em geral optam por uma chave primária "natural" que pode estar sujeita a alterações mínimas em uma coluna sem significado, não digitada por usuário.

Uma limitação exclusiva designa que os dados na coluna ou na coleção de colunas sejam exclusivos por linha. Se a limitação exclusiva estiver em uma coluna, os dados em uma linha específica na coluna especificada deverão ser exclusivos dos dados contidos em uma linha diferente na mesma coluna. 

Quando um limite exclusivo é definido para um grupo de colunas, a exclusividade se baseia no todo coletivo dos dados nas colunas que compõem essa limitação exclusiva. Os dados que estão em uma linha específica, em uma coluna específica, não precisam ser exclusivos dos dados em uma linha diferente na mesma coluna. O designer do banco de dados utiliza a limitação exclusiva para garantir a exclusividade dos dados aplicativos.

Definir Dados e Regras de Cumprimento de Integridade Referencial

As regras de integridade de dados, também conhecidas como restrições, garantem que os valores dos dados permaneçam dentro de limites definidos. Onde forem identificados, esses limites serão impostos pelo banco de dados. (Isso não quer dizer que a validação de dados não deva ser feita no aplicativo, quer dizer apenas que o banco de dados pode servir de "validador do último local", no caso de funcionamento incorreto do aplicativo.) Quando houver regras de validação de dados, as limitações do banco de dados devem ser projetadas para impô-las.

Chave estrangeira é uma ou mais colunas em uma tabela que é mapeada para a chave primária em outra tabela. Uma só tabela pode ter várias chaves estrangeiras, sendo que cada chave estrangeira é um mapa para uma tabela diferente. O mapeamento ou a relação, entre as tabelas é referido quase sempre como uma relação entre pai e filho. A tabela-filho contém a chave estrangeira, que é mapeada para a chave primária na tabela-pai. 

A definição das limitações de chave estrangeira também é utilizada com freqüência pelo otimizador de consultas para aumentar o desempenho de consulta.  Em muitos casos, as regras de imposição de chave estrangeira utilizam as tabelas de referência.

Desnormalizar o Design de Banco de Dados para Otimizar para o Desempenho

No caso de um Modelo de Dados relacional, o mapeamento inicial geralmente produz um mapeamento simples, de classe para tabela. Se objetos de classes diferentes precisam ser recuperados ao mesmo tempo, o RDBMS utiliza uma operação chamada "junção de tabelas" para recuperar as linhas relacionadas aos objetos de interesse. No casos de dados acessados com freqüência, operações de junção podem ser dispendiosas em termos computacionais. Para eliminar o custo da junção, muitas vezes emprega-se uma técnica relacional padrão chamada "desnormalização".

A desnormalização combina colunas de duas ou mais tabelas diferentes na mesma tabela, pré-ligando efetivamente as informações. A desnormalização reflete um tradeoff entre operações de atualização mais caras em favor das operações de recuperação menos caras. Essa técnica reduz também o desempenho do sistema em consultas interessadas apenas nos atributos de um dos objetos que de fato sofreram junção na tabela de desnormalização, já que todos os atributos são recuperados normalmente em cada consulta. Nos casos em que o aplicativo normalmente deseja obter todos os atributos, pode haver uma melhora significativa do desempenho.

A desnormalização de mais de duas tabelas é um procedimento raro e aumenta o custo de inserções e atualizações, como também das consultas não ligadas. Limitar a desnormalização a duas tabelas é uma boa política, a menos que haja evidência incontestável sobre outras vantagens.

A desnormalização pode ser deduzida das classes de design nos casos em que as classes estão aninhadas. Classes aninhadas podem ser mapeadas para uma tabela desnormalizada.

Alguns bancos de dados de objetos permitem um conceito semelhante ao de desnormalização, no qual os objetos relacionados são organizados nos mesmos clusters do disco e recuperados em uma única operação. O conceito em uso é semelhante , ou seja, reduz-se o tempo de recuperação do objeto com a redução do trabalho que o sistema deve executar para recuperar objetos relacionados do banco de dados.

Em alguns casos, a otimização do Modelo de Dados pode descobrir problemas no Modelo de Design, inclusive gargalos no desempenho, modelagem insatisfatória ou designs incompletos. Se isso ocorrer, discuta os problemas com o Designer da classe, acionando controles de mudanças, quando apropriado.

Otimizar Acesso a Dados

Depois de projetar a estrutura da tabela, é necessário determinar os tipos de consultas que serão executadas nos dados. A indexação é usada pelo banco de dados para agilizar o acesso. A indexação é mais eficaz quando os valores dos dados na coluna que está sendo indexada são relativamente distintos.

Considere os seguintes princípios de indexação:

• A coluna da chave primária da tabela sempre deve ser indexada. As colunas de chave primária são freqüentemente usadas como chaves de pesquisa e em operações de ligação.
• Tabelas com menos de 100 linhas e com poucas colunas não se beneficiam muito da indexação. Geralmente, as tabelas pequenas se ajustam facilmente ao cache do banco de dados.
• Os índices também devem ser definidos para consultas executadas com freqüência ou para consultas que precisam recuperar dados rapidamente (em geral, qualquer procura feita enquanto uma pessoa pode estar aguardando). Deve ser definido também um índice para cada conjunto de atributos utilizados juntos como critério de procura. Por exemplo, se o sistema precisa localizar todos os pedidos de um determinado produto, um índice na tabela Item de Linha, na coluna de números de produtos, seria necessário.
• Índices em geral devem ser definidos apenas nas colunas utilizadas como identificadores, não em valores numéricos, como saldos bancários ou em informações textuais, como comentários sobre pedidos. Os valores identificadores tendem a ser atribuídos quando o objeto é criado e permanecem inalterados durante o tempo de vida do objeto.
• Índices em números simples (inteiros e tipos de dados numéricos) são muito mais simples e rápidos do que índices em cadeias. Por causa do grande volume de dados processado em uma consulta ou em uma grande junção, pequenos recursos significam eficiência.  Índices em colunas numéricas costumam ocupar significativamente menos espaço do que índices em caracteres.

O lado negativo é que o uso de índices não é livre; quanto mais índices em uma tabela, mais demorado será o processo de inserções e atualizações. Quando pretender utilizar índices, não deixe de tomar as seguintes precauções:

• Não utilize índice apenas para agilizar uma consulta executada com pouca freqüência, a menos que a consulta ocorra em um momento crítico, tornando essencial a velocidade máxima.
• Em alguns sistemas, o desempenho de atualizações e inserções é mais importante do que o de consultas. Um exemplo comum são os aplicativos de aquisição de dados de manufatura, onde os dados relacionados à qualidade são capturados em tempo real. Nesses sistemas, somente consultas on-line ocasionais são executadas e a maior parte dos dados é analisada periodicamente por aplicativos de relatório em batch que fazem a análise estatística dos dados. Em sistemas de aquisição de dados, remova todos os índices para obter rendimento máximo. Se houver necessidade de índices, eles poderão ser reconstruídos imediatamente antes da execução dos aplicativos de análise e relatório em batch e depois eliminados quando o relatório e a análise estiverem concluídos.
• Lembre-se sempre dos custos por trás dos índices. Por exemplo, eles levam tempo para serem atualizados (paga-se uma taxa por cada inserção, atualização ou exclusão) e ocupam espaço em disco. Esteja certo de que usá-los será vantajoso.

Muitos bancos de dados oferecem vários tipos de índices. O mais comuns são:

• Índices B-tree - O tipo mais utilizado baseia-se em estruturas de dados compensadas de índices em árvore B. São úteis quando os valores-chave do índice são distribuídos aleatoriamente e tendem a variar muito. Contudo, seu desempenho é fraco nos casos em que os dados que estão sendo indexados já estão em uma ordem seqüencial.
• Índices Hashed - Com menos freqüência, os valores-chave do índice são misturados. Com o hashing, o desempenho é melhor do que quando vários valores-chave de índice são conhecidos, e permanecem relativamente inalterados e exclusivos. Essa técnica conta com o uso do valor-chave para calcular o endereço dos dados desejados. Devido à necessidade de previsibilidade, os índices hash costumam ser úteis apenas em tabelas pesquisa de tamanho médio, que são pouco alteradas.

A escolha da estratégia de indexação e do tempo de criação de índices pode ter grande impacto sobre o desempenho. Carregamento de dados em massa devem ser executados sem índices (isso pode ser conseguido com a eliminação do índice, o carregamento dos dados e depois a recriação do índice). O motivo é que a estrutura de índice é rebalanceada conforme a inclusão de linhas. Como linhas subseqüentes mudarão a estrutura ideal do índice, o trabalho com o rebalanceamento do índice, devido à inserção de novas linhas, será em grande parte desperdiçado. É mais rápido e mais eficiente carregar os dados sem índices e depois recriar o índice quando o carregamento estiver concluído. Alguns bancos de dados possuem carregadores para grandes volumes de dados que fazem isso automaticamente.

Outra estratégia para otimizar o desempenho do acesso ao banco de dados é utilizar visualizações. Visualizações de banco de dados são tabelas virtuais que não possuem armazenamento independente próprio. Para o programa de chamada (ou o usuário), entretanto, a visualização se comporta como uma tabela. Uma visualização suporta recuperação de dados e pode ser utilizada para atualizar dados também - dependendo da estrutura do banco de dados e de seu fornecedor. A visualização contém dados de uma ou mais tabelas que podem ser acessadas por meio de uma única instrução de seleção. O ganho em desempenho ocorre durante a seleção dos dados, especialmente em tabelas consultadas com freqüência. Os dados são recuperados de um único local - a visualização - e não na procura feita em várias tabelas ou em tabelas grandes existentes no banco de dados.

Visualizações também desempenham uma função importante na segurança do banco de dados. Uma visualização que contém partes de uma tabela pode restringir o acesso a dados sensíveis contidos na tabela base.

Definir Características de Armazenamento

Um designer de banco de dados utiliza espaços de tabela para representar a quantidade de espaço de armazenamento alocada para tabelas, índices, procedimentos armazenados e assim por diante. Um ou mais espaços de tabelas são mapeados para um banco de dados. O designer de banco de dados deve analisar as tabelas no Modelo de Dados para determinar como distribuí-las, junto com outros elementos de suporte do banco de dados, no espaço de armazenamento no banco de dados.

Na determinação das estruturas de espaço de tabela para o banco de dados, lembre-se de que os bancos de dados não executam E/S em linhas, registros ou mesmo em tabelas inteiras. Em vez disso, executam E/S em blocos de discos. O motivo é simples: as operações de E/S em blocos geralmente são otimizadas no software e no hardware do sistema. Como conseqüência, a organização física das tabelas e dos índices no banco de dados podem causar um impacto significativo sobre o desempenho do sistema.

Ao planejar a alocação de espaço e a organização de página de disco do banco de dados, leve em conta os seguintes fatores:

• a densidade das informações nas páginas de disco
• o local das páginas no disco e através dos vários discos
• a quantidade de espaço em disco a ser alocada para a tabela

Esses fatores serão discutidos nas próximas seções.

Densidade da Página do Disco

A densidade das páginas de disco depende da extensão das mudanças esperadas para os dados ao longo do tempo. Basicamente, uma página menos densa aceita melhor mudanças de valores ou inclusão de dados no decorrer do tempo, enquanto uma página de dados mais cheia oferece melhor desempenho de leitura, visto que mais dados são recuperados por leitura de bloco.

Para simplificar o gerenciamento de disco, o designer do banco de dados pode agrupar as tabelas de acordo com sua probabilidade de sofrer mudanças. O três grupos a seguir são considerados um bom começo para esse tipo de organização:

• tabelas altamente dinâmicas
• tabelas relativamente dinâmicas
• tabelas quase inteiramente estáticas

As tabelas altamente dinâmicas devem ser mapeadas para páginas de disco que contam com uma grande parte de espaço vazio (talvez 30%); as tabelas relativamente dinâmicas devem ser mapeadas para páginas de disco que contam com menos espaço vazio (talvez 15%); e as tabelas em sua maior parte estáticas devem ser mapeadas para páginas de disco que contam com muito pouco espaço (talvez 5%). Os índices para as tabelas devem ser mapeados de forma semelhante.

Local da Página do Disco

Depois que os grupos de tabelas são mapeados, o designer do banco de dados deve determinar onde colocar as páginas de disco. O objetivo é tentar balancear a carga de trabalho entre várias unidades e cabeças para reduzir ou eliminar gargalos. Leve em conta as seguintes diretrizes:

• Nunca coloque dados no mesmo disco do sistema operacional, seus arquivos temporários ou os dispositivos de troca. Essas unidades já ficam ocupadas o bastante sem a inclusão de carga de trabalho extra.
• Coloque os dados acessados simultaneamente em unidades diferentes para equilibrar a carga de trabalho. Alguns sistemas suportam canais de E/S paralelos. Se for esse o caso, coloque os dados em canais diferentes.
• Coloque os índices em uma unidade diferente daquela que contém os dados que ela indexa, a fim de distribuir a carga de trabalho.
• Consulte as diretrizes contidas na documentação do fornecedor do banco de dados.
• O tipo de armazenamento utilizado (por exemplo, RAID-5, RAID-10, SAN, NAS e canal conectado) afeta o desempenho do banco de dados. Siga as diretrizes sobre desempenho fornecidas pelo provedor do armazenamento.

A E/S do banco de dados geralmente é o fator de limitação no desempenho do banco de dados. O equilíbrio da E/S é um processo iterativo e experimental. A criação do protótipo do desempenho do acesso ao banco de dados durante a fase de elaboração, em conjunto com a instrumentação apropriada para monitorar a E/S física e lógica, permite descobrir problemas de desempenho enquanto ainda há tempo de ajustar o design do banco de dados.

Alocação de Espaço em Disco

Utilizando as características do mecanismo de design de persistência, calcule o número de objetos que devem ser armazenados. A quantidade de espaço em disco exigida para armazenar os objetos varia de RDBMS para RDBMS. Ao calcular o espaço em disco, certifique-se de incluir no cálculo o crescimento causado pela adição de dados.  Para calcular o espaço em disco para um banco de dados, calcule primeiramente o espaço em disco necessário para cada tabela e, em seguida, calcule os requisitos de espaço para todas as tabelas.  Consulte o manual do administrador do banco de dados para obter o produto RDBMS específico para a definição da fórmula de cálculo preciso do tamanho.  Seguem algumas etapas gerais para o cálculo dos requisitos de espaço para uma tabela:

• Calcule o tamanho médio de linhas.  Esse cálculo deve incluir qualquer informação de controle no nível de registro, bem como qualquer informação de controle exigida para colunas de comprimento variável.
• Calcule o número de linhas que se ajustarão a uma página ou a um bloco de E/S. Como a maioria dos bancos de dados armazena apenas registros completos em uma página ou em um bloco de E/S, esse valor deve ser o número inteiro de linhas que se ajustarão a uma página ou a um bloco de E/S.
• Calcule o número de páginas ou blocos de E/S exigidos para armazenar o número estimado de registros no banco de dados.  O número estimado de registros deve incluir cada fator de carregamento.
• Multiplique o número de páginas ou blocos de E/S necessários ao tamanho da página ou do bloco de E/S.
• Some a sobrecarga de índices adicionais.
• Some a sobrecarga fixa da tabela.

Depois de definidos os requisitos de espaço de tabelas:

• Calcule a soma do espaço exigido pelas tabelas.
• Inclua a quantidade fixa necessária de espaço para gerenciamento do banco de dados.
• Inclua o espaço em disco necessário para o log de transações e a trilha de auditoria. 

Em um ambiente atualizado com freqüência, os requisitos de retenção para a trilha de auditoria exigem quantidades significativas de armazenamento. A documentação que aborda os principais sistemas de gerenciamento de bancos de dados comerciais normalmente oferece instruções detalhadas sobre tamanho. Não deixe de consultar essas instruções ao calcular as estimativas dos requisitos de espaço em disco do banco de dados.

Projetar Procedimentos Armazenados para Distribuir Comportamento de Classe ao Banco de Dados

A maioria dos bancos de dados suporta um recurso de procedimento armazenado. Procedimento armazenado é o código executável que é executado no espaço de processos do sistema de gerenciamento de banco de dados. Ele permite executar ações relacionadas ao banco de dados no servidor, sem necessidade de transferir dados pela rede. Se utilizados com critério, os procedimentos armazenados podem aprimorar o desempenho do sistema.

Procedimentos armazenados em geral se referem a dois tipos, procedimentos reais ou disparos. Procedimentos são executados explicitamente por um aplicativo, normalmente possuem parâmetros e oferecem um valor de retorno explícito. Disparos, por outro lado, são chamados implicitamente quando ocorre um evento do banco de dados (por exemplo, inserção, atualização ou exclusão de uma linha), não possuem parâmetros que não seja a linha que está sendo modificada (já que são chamados implicitamente) e não oferecem um valor de retorno explícito.

Em sistemas de banco de dados sem restrições, os triggers são geralmente usados para impor a integridade referencial e de dados. Caso contrário, eles podem ser usados quando um evento precisa acionar (ou provocar) um outro evento. Disparos também são utilizados com freqüência para fins de segurança, por meio da auditoria do evento do disparo.

As classes de design no Modelo de Design devem ser examinadas para saber se possuem operações que devem ser implementadas utilizando o procedimento armazenado ou recurso de disparo. Sugestões:

• qualquer operação que trate principalmente de dados persistentes (criação, atualização, recuperação ou exclusão de dados).
• qualquer operação na qual uma consulta está envolvida em um processo de cálculo (como o cálculo da média de quantidade e valor de um produto em estoque).
• operações que devem acessar o banco de dados para validar dados.

Lembre-se de que aprimorar o desempenho do banco de dados normalmente significa reduzir a E/S. Como conseqüência, se a execução de um cálculo no servidor DBMS reduzir a quantidade de dados transmitidos pela rede, essa tarefa de cálculo provavelmente deverá ser executada no servidor.

Trabalhe com o designer da classe de design para discutir como o banco de dados pode ser utilizado para aprimorar o desempenho. O designer atualizará o método de operação para indicar que um ou mais procedimentos armazenados poderá ser utilizado para implementar a operação.

Continuamente, em toda esta tarefa, é preciso considerar os Lista de Verificação: Modelo de Dados, para avaliar a inteireza e qualidade do esforço.  Além disso, o designer do banco de dados deve revisar com regularidade a estrutura implementada do banco de dados, assegurando-se de que o Modelo de Dados esteja consistente com todas as mudanças feitas diretamente do banco de dados.  Se o projeto estiver utilizando ferramentas de modelagem de dados que suportam sincronização do Modelo da Dados com a estrutura física do banco de dados, o designer do banco de dados deverá verificar periodicamente o estado do Modelo de Dados com o banco de dados e fazer os ajustes necessários. 

Os defeitos identificados que não forem corrigidos nesse momento devem ser documentados em Controles de Mudanças e eventualmente designados a alguém que toma e controla as decisões.