Atividade:  Design de Banco de Dados

Os passos apresentados abaixo pressupõem a utilização de um modelo de dados relacionais. Os passos para um banco de dados de objetos são de natureza semelhante, mas diferem nos detalhes.

Supõe-se que o leitor esteja familiarizado com os conceitos e a terminologia de banco de dados, abordados em referências como [DAT99].

Mapear Classes de Design Persistentes para o Modelo de Dados

Depois que a estrutura das classes de design persistentes (classes de design cuja propriedade persistente esteja definida) se estabiliza, elas devem ser mapeadas para o modelo de dados. As diretrizes apresentadas acima descrevem uma estratégia de granulação graúda para a realização do mapeamento. Em último caso, são necessários um framework e ferramentas para fazer o mapeamento conceitual e gerar chamadas para que o framework faça o mapeamento em tempo de execução. A importância de ferramentas e frameworks de acesso a dados em tempo de execução passa a ser essencial quando o trabalho fica altamente iterativo, já que não possível gerenciar o processo de mapeamento nem a geração de códigos da interface relacionada sem um framework e um conjunto de ferramentas confiáveis.

Otimizar o Desempenho do Modelo de Dados

Os objetos recuperados em conjunto podem ser armazenados juntos para melhorar o desempenho.

No caso de um modelo de dados relacionais, o mapeamento inicial, em geral, é simples e de classes para tabelas. Se os objetos de classes distintas precisarem ser recuperados ao mesmo tempo, o RDBMS usará uma operação denominada ligação de tabela, para recuperar as linhas relacionadas aos objetos de interesse. Para os dados acessados com freqüência, as operações de ligação podem ser computacionalmente muito dispendiosas. Para eliminar o custo da ligação, uma técnica relacional padrão é a desnormalização.

A desnormalização combina colunas de duas ou mais tabelas distintas na mesma tabela, ligando previamente as informações. A desnormalização reflete uma troca das operações de atualização mais caras em favor de operações de recuperação menos caras. A desnormalização também reduz o desempenho do sistema em consultas interessadas apenas nos atributos de um dos objetos que estão efetivamente ligados na tabela desnormalizada, já que todos os atributos são recuperados em todas as consultas. No entanto, nos casos em que o aplicativo normalmente deseja obter todos os atributos, pode haver uma significativa melhora 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. Uma boa política é limitar a desnormalização a duas tabelas, a não ser que haja evidência forte e convincente sobre suas vantagens.

A desnormalização pode ser inferida a partir das Classes de Design, em casos nos quais as classes estão aninhadas. As classes aninhadas sempre devem 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 de uso é semelhante: para reduzir o tempo de recuperação de objetos, pois diminui o trabalho do sistema para recuperar objetos relacionados do banco de dados.

Em alguns casos, a otimização do modelo de dados pode desmacarar problemas no Modelo de Design, em forma de gargalos de desempenho, modelagem inadequada ou designs incompletos. Nesse caso, discuta os problemas com o Designer da classe, acionando as solicitações de mudança quando apropriado.

Otimizar o Acesso aos Dados

Depois de projetar a estrutura da tabela, determine os tipos de consultas que serão executadas nos dados. A indexação é usada pelo banco de dados para agilizar o acesso. Considere as seguintes estratégias de indexação:

• A coluna de 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.
• Para as tabelas com menos de 100 linhas e com apenas algumas colunas, a indexação não é um procedimento vantajoso. Geralmente, as tabelas pequenas se ajustam facilmente ao cache do banco de dados.
• As tabelas com menos de 100 linhas se beneficiam pouco da indexação, porque elas tendem a ser armazenadas na memória cache do banco de dados (o número real de linhas está relacionado a quantas linhas caberão em um bloco de dados, que, em geral, tem entre 512 e 2048 bytes de tamanho. A unidade de entradas e saídas executadas pelo banco de dados não é uma linha mas um bloco, quando observada por uma perspectiva física).
• Os índices também devem ser definidos para as consultas executadas com freqüência ou para as consultas que devem recuperar dados rapidamente (consultas realizadas enquanto alguém espera um outro evento). Um índice deve ser definido para cada conjunto de atributos usados como critérios de pesquisa. Por exemplo, se o sistema precisa localizar todos os Pedidos de determinado produto, deve haver um índice na tabela Item, na coluna com números de produtos.
• Os índices devem ser definidos apenas em colunas usadas como identificadores e não em valores numéricos (saldos bancários) ou informações textuais (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.
• Os índices devem ser números simples (inteiros ou tipos de dados numéricos), e não números com pontos flutuantes. Raramente devem aparecer em seqüências de caracteres. As operações de comparação ficam bem mais simples e rápidas com números do que com seqüências de caracteres, além de fornecerem grandes volumes de dados processados em uma consulta ou em uma grande ligação. Pequenos recursos que significam eficiência. Os índices em colunas numéricas tendem também a ocupar menos espaço.

O uso de índices não é livre, e este é um aspecto negativo. Quanto mais índices houver em uma tabela, mais demorado será o processamento de inserções e atualizações. Tome os seguintes cuidados para diminuir a utilização de índices:

• Não utilize índices para agilizar uma consulta pouco executada, a menos que ela ocorra em um ponto crítico e um máximo de velocidade seja necessário.
• 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 referentes à qualidade são obtidos em tempo real. Nesses sistemas, as consultas on-line são ocasionais, e a maioria dos dados é analisada periodicamente por aplicativos de relatórios em lote que fazem a análise estatística dos dados. Para os sistemas de aquisição de dados, remova todos os índices a fim de obter a taxa máxima de transferência de dados. Se houver necessidade de usar índices, eles poderão ser recriados antes de os aplicativos de análise/relatórios em lote serem executados. Em seguida, poderão ser eliminados quando o relatório/a análise estiver concluído.
• Lembre-se de que os índices têm um custo embutido: levam tempo para serem atualizados (uma taxa paga a 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 em árvore B. O tipo mais utilizado baseia-se em estruturas de dados balanceadas de índices em árvore B. São indicados quando os valores-chave do índices são distribuídos aleatoriamente e tendem a variar muito. Seu desempenho não é bom quando os dados que estão sendo indexados já estão em uma ordem seqüencial.
• Índices de hashing. 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. Esse procedimento baseia-se na utilização do valor-chave para calcular o endereço dos dados desejados. Devido à necessidade de previsibilidade, os índices de hashing são úteis apenas para as tabelas de pesquisa médias, com poucas mudanças.

A escolha da estratégia de indexação, assim como o tempo de criação de índices, pode causar um forte impacto sobre o desempenho. As cargas de dados volumosas devem ser realizadas sem índices (para isso, você elimina o índice, carrega os dados e, em seguida, recria o índice). O motivo para isso é que quando cada linha é adicionada, a estrutura do índice é rebalanceada. 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 eficiente carregar dados sem índices e recriar o índice quando a carga de dados estiver concluída. Alguns bancos de dados possuem carregadores para grandes volumes de dados que fazem isso automaticamente.

Definir Características de Armazenamento

Os bancos de dados realizam operações de entrada e saída não em linhas ou registros, ou mesmo em tabelas inteiras, mas em blocos de disco. O motivo é simples: as operações de entrada e saída nos blocos costuma ser otimizada 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. Há várias dimensões:

• A densidade das informações nas páginas de disco
• A localização das páginas no disco e nas unidades de disco
• O volume de espaço em disco alocado para a tabela

Densidade de Página de Disco

A densidade das páginas de disco depende da extensão das mudanças esperadas para os dados ao longo do tempo. Sem entrar em detalhes, uma página menos densa aceita melhor mudanças de valores ou inclusão de dados no decorrer do tempo. Ao passo que uma página de dados mais cheia melhora o desempenho de leitura, pois mais dados são recuperados por leitura de bloco.

Para simplificar o gerenciamento de discos, agrupe as tabelas de acordo com sua probabilidade de sofrer mudanças. Três grupos são um bom ponto de partida: muito dinâmicas, pouco dinâmicas e principalmente estáticas. As tabelas muito dinâmicas devem ser mapeadas para as páginas de disco com bastante espaço vazio (talvez 30%). As tabelas pouco dinâmicas para as páginas com menos espaço vazio (talvez 15%). As tabelas principalmente estáticas precisam de muito pouco espaço vazio (talvez 5%). Os índices para as tabelas devem ser mapeados da mesma forma.

Localização da Página de Disco

Em seguida, determine onde as páginas de disco serão colocadas. O objetivo é tentar balancear a carga de trabalho entre várias unidades e cabeças para reduzir ou eliminar gargalos. Considere algumas diretrizes:

• Nunca coloque dados no mesmo disco do sistema operacional, seus arquivos temporários ou os dispositivos de troca. Essas unidades já estão ocupadas o suficiente, mesmo sem a inclusão de uma carga extra de trabalho.
• Tente colocar os dados acessados simultaneamente em unidades distintas para balancear a carga de trabalho. Alguns sistemas suportam canais de entrada e saída paralelos, de forma que, se possível, coloque os dados em canais distintos.
• Tente colocar os índices em uma unidade diferente daquela que contém os dados que ela indexa, para também distribuir a carga de trabalho.
• Tente usar operações brutas de entrada e saída se possível. Essas operações ignoram o armazenamento normal em buffer de arquivos feito pelo sistema operacional. Como o DBMS mantém seus próprios buffers, não é preciso que o sistema operacional também use o seu. As operações brutas de entrada e saída são um tanto mais complexas de serem administradas. Portanto, sua utilização deve ser considerada com cuidado.
• No caso de consultas complexas, considere fazer o striping dos dados. Esse procedimento envolve a colocação de páginas de dados das mesmas tabelas (ou conjunto de objetos) em diversas unidades, a fim de reduzir o tempo de procura na cabeça do disco e, possivelmente, tirar proveito dos controladores inteligentes que suportam operações paralelas de entrada e saída.

A principal regra é que nunca há unidades suficientes para a distribuição de entradas e saídas. O balanceamento das operações de entrada e saída é um processo iterativo e experimental. A criação do protótipo do desempenho do acesso a dados durante a fase de elaboração, junto com a instrumentação apropriada para monitorar operações de entrada e saída físicas e lógicas, evidenciará problemas de desempenho enquanto ainda há tempo de ajustar o design do banco de dados.

Alocação de Espaço em Disco

Usando as características do Mecanismo de Design de persistência, estime o número de objetos que precisam ser armazenados. O volume de espaço em disco necessário para armazenar os objetos varia de acordo com o banco de dados, mas a estimativa de tamanho é geralmente uma função de:

tamanho = (carga fixa por tabela) + (número de linhas * (tamanho médio de linha/densidade média dos dados))

em que densidade média dos dados corresponde ao percentual de densidade por página. Além disso, certifique-se de considerar também o tamanho dos índices. O manual do Administrador de Banco de Dados (DBA) referente ao produto fornecerá fórmulas para calcular tamanhos com precisão. Ao calcular o espaço em disco, considere o crescimento decorrente da inclusão de dados.

Use os cálculos de alocação de espaço em disco junto com a localização de páginas para inserir dados também. Alguns bancos de dados permitem que as tabelas usem unidades físicas, e outras não. Se o seu não permite, será preciso subotimizar a inserção de dados para acomodar os volumes. Uma outra alternativa é usar as unidades RAID (matrizes redundantes de discos independentes), pois permitem que várias unidades de disco independentes atuem como um grande disco único que pode ser facilmente expandido. As unidades RAID fazem um striping de dados automático e eficiente, mas oferecem menor controle do posicionamento físico dos dados, o que dificulta a otimização.

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. Como os dados dessas tabelas tendem a ser acessados freqüentemente, mas são pouco modificados, é bom considerá-las. No modelo de design, elas são itens como tabelas com códigos padrão de produto, de estado ou de município, códigos postais ou de endereçamento, com informações de tarifas, validação de códigos locais ou outras acessadas com freqüência. Nos sistemas financeiros, elas podem ser listas de códigos de diretivas, categorias de classificação de apólices de seguro ou taxas de conversão. No modelo de design, procure classes que sejam principalmente de leitura, que forneçam informações de validação a um grande número de clientes.

Para fazer uma vinculação nos passos iniciais, os dados devem ficar localizados em uma unidade rápida, em páginas de dados relativamente compactas. Se a tabela for pequena, não precisa ser indexada, pois a indexação de tabelas pequenas, na verdade, aumenta a carga. Uma tabela pouco acessada também tende a permanecer na memória, pois os algoritmos menos usados (LRU) costumam mantê-las no cache de dados.

Certifique-se de que o cache do banco de dados possa armazenar todas as tabelas de referência e, se possível, o "espaço de trabalho" normal para consultas e transações. Um dos segredos de aumentar o desempenho do banco de dados é diminuir as operações de entrada e saída. Em termos relativos, a memória não é algo dispendioso, portanto, se precisar, adquira mais.

Depois de definir as estraturas das tabelas de referência, determine uma estratégia para preenchê-las. Como elas são acessadas no início do projeto, determinar os valores de referência e carregá-las também são tarefas executadas mais ou menos no início do projeto. Embora o Designer de Dados não seja responsável pela obtenção de dados, ele deve determinar como e quando as tabelas de referência serão atualizadas.

Definir Regras para a Integridade Referencial e de Dados

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. (Não quer dizer que a validação de dados não deva ser efetuada no aplicativo. Significa apenas que o banco de dados pode agir como um 'validador' caso o aplicativo não funcione corretamente). Se houver regras de validação de dados, defina as restrições de banco de dados para impô-las.

Além disso, as regras de integridade referencial também podem ser impostas pelo banco de dados. Elas garantirão que para todo valor de chave estrangeira haverá um valor de chave primária em uma tabela referenciada. A definição de restrições de chave estrangeira também são usadas pelo otimizador de consultas para acelerar o desempenho da consulta. Com base nas associações do Modelo de Design, crie restrições de relacionamento de chave estrangeira nas tabelas associadas do Modelo de Dados. Em muitos casos, as regras de chave estrangeira impostas usarão as tabelas de referência abordadas no passo anterior.

Distribuir o Comportamento de Classe no Banco de Dados

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

Há dois tipos de procedimentos armazenados: procedimentos propriamente ditos e triggers. Os procedimentos são executados explicitamente por um aplicativo, geralmente possuem parâmetros e podem fornecer um valor de retorno explícito. Os triggers são disparados implicitamente quando ocorre algum evento do banco de dados (inserção, atualização, exclusão de linha, por exemplo), não possuem parâmetros (pois são disparados implicitamente) e não fornecem valores de retorno explícitos.

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.

As classes de Design devem ser examinadas para verificar se possuem operações que devem ser implementadas com o recurso de procedimentos armazenados ou triggers. Sugestões:

• Operações que tratam principalmente de dados persistentes (criação, atualização, recuperação ou exclusão desses dados).
• Operações em que há consultas envolvidas em um processo computacional (como o cálculo da quantidade e do valor médios de um produto em estoque).
• Operações que precisam acessar o banco de dados para validar dados.

O aumento de desempenho do banco de dados está, freqüentemente, associado à redução de operações de entrada e saída. Como conseqüência, se a execução de uma tarefa computacional no servidor DBMS reduzir o volume de dados transferidos por rede, essa tarefa computacional provavelmente poderá ser executada no servidor.

Trabalhe com o Designer da classe para discutir como o banco de dados pode ser usado para melhorar o desempenho. O Designer atualizará o método de operação para indicar que um ou mais procedimentos armazenados poderão/deverão ser usados para implementar a operação.

Revisar os Resultados

Durante toda a atividade, considere os Pontos de Verificação: Modelo de Dados para avaliar o nível de conclusão e qualidade do esforço.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process