Atividade:
|
Finalidade
|
|
Função: Designer de Banco de Dados | |
Freqüência: Uma vez por iteração. | |
Etapas
|
|
Artefatos de Entrada: | Artefatos Resultantes: |
Mentores de Ferramentas: |
Detalhes de Workflow: |
As etapas apresentadas nesta atividade supõem que o design de dados persistentes do aplicativo será implementado com o uso de um RDBMS (Relational Database Management System). Supõe-se que você esteja familiarizado com conceitos de banco de dados, incluindo normalização e desnormalização, e também com a terminologia de banco de dados, conforme abordado em referências como [DAT99].
As etapas desta atividade se referem também ao perfil da linguagem UML (Unified Modeling Language) para modelagem de banco de dados, que é abordado em [NBG01]. Além disso, [NBG01] contém uma descrição geral do processo de modelagem e design de bancos de dados relacionais utilizando a linguagem UML. Para obter informações complementares sobre a relação entre modelos de dados relacionais e modelos de objetos, consulte Conceitos: Bancos de Dados Relacionais e Orientação de Objetos.
Finalidade | Definir um modelo do design lógico do banco de dados. |
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 de normalização (consulte Conceitos: Normalização) que se encontra uma forma de modelagem de dados que diminui 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 Artefato: Modelo de Dados e não um artefato RUP separado. Entretanto, muitas vezes, é importante definir Modelos de Dados Lógicos para:
Se você estiver criando um Modelo de Dados Lógico, poderá começar do zero, utilizando os elementos de modelo abordados em Diretrizes: Modelo de Dados ou começar pelo início, ou seja, com entidades para cada classe persistente no Modelo de Análise ou no 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 o 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 as classes no Artefato: Modelo de Design que precisam armazenar informações em um banco de dados. Conforme descrito na etapa com o título "Identificar classes persistentes da Atividade: Design de Classe," o designer de banco de dados trabalho com o designer para identificar as classes de design no Modelo de Design que são consideradas persistentes e possíveis candidatas a transformarem-se em tabelas no banco de dados.
Finalidade | Definir o design físico detalhado do 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 Artefato: Modelo de Dados e não é um artefato de modelo separado.
As etapas detalhadas do desenvolvimento do design físico do banco de dados são as seguintes:
Finalidade | Definir tipos reutilizáveis definidos pelo usuário. |
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.
Finalidade | Criar as tabelas e relações iniciais do banco de dados. |
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: 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: Engenharia Futura de Bancos de Dados Relacionais.
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 Conceitos: Normalização para obter informações adicionais sobre normalização de bancos de dados.
Finalidade | Definir tabelas de referência padrão usadas no projeto. |
É 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.
Finalidade | Definir uma ou mais colunas que identifique exclusivamente uma linha na tabela. Definir limites sobre as colunas que garantam a exclusividade dos dados ou da coleta de dados. |
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, ao criar uma chave primária, crie uma coluna exclusiva, cujo significado não possa ser identificado e na qual o usuário não possa inserir dados. 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 uma coluna cujo significado não pode ser determinado e na qual o usuário não pode inserir dados é 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 mudanças mínimas em uma coluna sem significado e na qual o usuário não insere dados.
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.
Finalidade | Garantir a integridade do banco 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. (Isso não quer dizer que a validação de dados não deve 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.
Finalidade | Otimizar as estruturas de dados do banco de dados para melhorar o desempenho. |
No caso de um Modelo de Dados relacional, o mapeamento inicial geralmente produz um mapeamento simples, de classe para tabela. Quando 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 inferida 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, como gargalos no desempenho, modelagem insatisfatória ou designs incompletos. Se isso ocorrer, discuta os problemas com o designer da classe, solicitando mudanças quando for apropriado.
Finalidade | Permitir acesso eficiente aos dados por meio de indexação. Permitir acesso eficiente aos dados por meio de visualizações do banco de 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:
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:
Muitos bancos de dados oferecem vários tipos de índices. O mais comuns são:
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 um papel 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.
Finalidade | Projetar a alocação de espaço e a organização de página de disco do banco de dados. |
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:
Esses fatores serão discutidos nas próximas seções.
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. 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 de 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.
Finalidade | Determinar se os disparos ou procedimentos armazenados devem ser utilizados para implementar operações de classe de acesso 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:
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.
Finalidade | Assegurar a qualidade e a integridade do Modelo de Dados. |
Continuamente, em toda esta atividade, é preciso considerar os Pontos 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 rever 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.
![]() |
Conteúdo desenvolvido ou parcialmente desenvolvido por Applied Information Sciences. |
Rational Unified Process
|