Projeto de banco de dados - Database design

O design do banco de dados é a organização dos dados de acordo com um modelo de banco de dados . O designer determina quais dados devem ser armazenados e como os elementos de dados se relacionam. Com essas informações, eles podem começar a ajustar os dados ao modelo de banco de dados. O sistema de gerenciamento de banco de dados gerencia os dados de acordo.

O design do banco de dados envolve a classificação de dados e a identificação de inter-relacionamentos. Essa representação teórica dos dados é chamada de ontologia . A ontologia é a teoria por trás do design do banco de dados.

Determinando os dados a serem armazenados

Na maioria dos casos, uma pessoa que está fazendo o design de um banco de dados é uma pessoa com experiência na área de design de banco de dados, em vez de experiência no domínio do qual os dados a serem armazenados são extraídos, por exemplo, informações financeiras, informações biológicas, etc. Portanto, os dados a serem armazenados no banco de dados devem ser determinados em cooperação com uma pessoa que tenha experiência nesse domínio e que saiba quais dados devem ser armazenados no sistema.

Este processo é geralmente considerado parte da análise de requisitos e requer habilidade por parte do projetista do banco de dados para obter as informações necessárias daqueles com o conhecimento do domínio . Isso ocorre porque aqueles com o conhecimento de domínio necessário frequentemente não podem expressar claramente quais são seus requisitos de sistema para o banco de dados, pois não estão acostumados a pensar em termos de elementos de dados discretos que devem ser armazenados. Os dados a serem armazenados podem ser determinados pela Especificação de Requisitos.

Determinando relacionamentos de dados

Depois que um designer de banco de dados está ciente dos dados que devem ser armazenados no banco de dados, ele deve determinar onde está a dependência nos dados. Às vezes, quando os dados são alterados, você pode alterar outros dados que não são visíveis. Por exemplo, em uma lista de nomes e endereços, assumindo uma situação em que várias pessoas podem ter o mesmo endereço, mas uma pessoa não pode ter mais de um endereço, o endereço depende do nome. Quando fornecido um nome e a lista, o endereço pode ser determinado de forma única; no entanto, o inverso não é válido - quando é fornecido um endereço e a lista, um nome não pode ser determinado exclusivamente porque várias pessoas podem residir em um endereço. Como um endereço é determinado por um nome, um endereço é considerado dependente de um nome.

(NOTA: Um equívoco comum é que o modelo relacional é assim chamado por causa das relações entre os elementos de dados nele. Isso não é verdade. O modelo relacional é assim chamado porque é baseado nas estruturas matemáticas conhecidas como relações .)

Dados de estruturação lógica

Artigo principal: Esquema lógico

Uma vez que os relacionamentos e dependências entre as várias informações tenham sido determinados, é possível organizar os dados em uma estrutura lógica que pode então ser mapeada nos objetos de armazenamento suportados pelo sistema de gerenciamento de banco de dados . No caso de bancos de dados relacionais, os objetos de armazenamento são tabelas que armazenam dados em linhas e colunas. Em um banco de dados Object, os objetos de armazenamento correspondem diretamente aos objetos usados ​​pela linguagem de programação orientada a objetos usada para escrever os aplicativos que irão gerenciar e acessar os dados. Os relacionamentos podem ser definidos como atributos das classes de objetos envolvidas ou como métodos que operam nas classes de objetos.

A maneira como esse mapeamento é geralmente executado é tal que cada conjunto de dados relacionados que dependem de um único objeto, real ou abstrato, é colocado em uma tabela. Os relacionamentos entre esses objetos dependentes são armazenados como links entre os vários objetos.

Cada tabela pode representar uma implementação de um objeto lógico ou um relacionamento que une uma ou mais instâncias de um ou mais objetos lógicos. Os relacionamentos entre as tabelas podem então ser armazenados como links que conectam as tabelas filho aos pais. Como os relacionamentos lógicos complexos são, eles próprios, tabelas, eles provavelmente terão links para mais de um pai.

Diagrama ER (modelo entidade-relacionamento)

Um exemplo de diagrama Entidade-relacionamento

Os designs de banco de dados também incluem diagramas ER ( modelo de entidade-relacionamento ). Um diagrama ER é um diagrama que ajuda a projetar bancos de dados de maneira eficiente.

Os atributos em diagramas ER são geralmente modelados como um oval com o nome do atributo, vinculado à entidade ou relacionamento que contém o atributo.

Os modelos ER são comumente usados ​​no projeto de sistemas de informação; por exemplo, eles são usados ​​para descrever os requisitos de informação e / ou os tipos de informação a serem armazenados no banco de dados durante a fase de projeto da estrutura conceitual.

Uma sugestão de processo de design para o Microsoft Access

  1. Determine a finalidade do banco de dados - Isso ajuda a se preparar para as etapas restantes.
  2. Encontre e organize as informações necessárias - Reúna todos os tipos de informações para registrar no banco de dados, como nome do produto e número do pedido.
  3. Divida as informações em tabelas - Divida os itens de informações em entidades ou assuntos principais, como Produtos ou Pedidos. Cada assunto então se torna uma mesa.
  4. Transforme os itens de informação em colunas - decida quais informações precisam ser armazenadas em cada tabela. Cada item se torna um campo e é exibido como uma coluna na tabela. Por exemplo, uma tabela Funcionários pode incluir campos como Sobrenome e Data de contratação.
  5. Especificar chaves primárias - Escolha a chave primária de cada tabela. A chave primária é uma coluna, ou um conjunto de colunas, que é usada para identificar exclusivamente cada linha. Um exemplo pode ser ID do produto ou ID do pedido.
  6. Configure os relacionamentos da tabela - Observe cada tabela e decida como os dados em uma tabela estão relacionados aos dados em outras tabelas. Adicione campos às tabelas ou crie novas tabelas para esclarecer as relações, conforme necessário.
  7. Refine o design - analise o design em busca de erros. Crie tabelas e adicione alguns registros de dados de amostra. Verifique se os resultados vêm das tabelas conforme o esperado. Faça ajustes no design, conforme necessário.
  8. Aplicar as regras de normalização - aplique as regras de normalização de dados para ver se as tabelas estão estruturadas corretamente. Faça ajustes nas tabelas, conforme necessário.

Normalização

Artigo principal: normalização de banco de dados

No campo do design de banco de dados relacional , a normalização é uma forma sistemática de garantir que uma estrutura de banco de dados seja adequada para consultas de propósito geral e livre de certas características indesejáveis ​​- anomalias de inserção, atualização e exclusão que podem levar à perda de integridade dos dados .

Uma parte padrão da orientação de design de banco de dados é que o designer deve criar um design totalmente normalizado; a desnormalização seletiva pode ser realizada posteriormente, mas apenas por motivos de desempenho . A compensação é espaço de armazenamento versus desempenho. Quanto mais normalizado for o design, menos redundância de dados haverá (e, portanto, ocupa menos espaço para armazenar), no entanto, os padrões comuns de recuperação de dados agora podem precisar de junções, mesclagens e classificações complexas - o que ocupa mais dados ler e calcular ciclos. Algumas disciplinas de modelagem, como a abordagem de modelagem dimensional para projeto de data warehouse , recomendam explicitamente projetos não normalizados, ou seja, projetos que em grande parte não aderem ao 3NF. A normalização consiste em formas normais que são 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF e 5NF

Os bancos de dados de documentos têm uma abordagem diferente. Um documento armazenado em tal banco de dados normalmente conteria mais de uma unidade de dados normalizada e, freqüentemente, os relacionamentos entre as unidades também. Se todas as unidades de dados e os relacionamentos em questão são frequentemente recuperados juntos, essa abordagem otimiza o número de recuperações. Também simplifica como os dados são replicados, porque agora existe uma unidade de dados claramente identificável cuja consistência é independente. Outra consideração é que ler e gravar um único documento nesses bancos de dados exigirá uma única transação - o que pode ser uma consideração importante em uma arquitetura de microsserviços . Em tais situações, muitas vezes, partes do documento são recuperadas de outros serviços por meio de uma API e armazenadas localmente por razões de eficiência. Se as unidades de dados fossem divididas entre os serviços, uma leitura (ou gravação) para dar suporte a um consumidor de serviço poderia exigir mais de uma chamada de serviço e isso poderia resultar no gerenciamento de várias transações, o que pode não ser preferido.

Esquema conceitual

Artigo principal: Esquema conceitual

Design físico

Artigo principal: Esquema físico

O design físico do banco de dados especifica a configuração física do banco de dados na mídia de armazenamento. Isso inclui especificações detalhadas de elementos de dados , tipos de dados , opções de indexação e outros parâmetros residentes no dicionário de dados DBMS . É o projeto detalhado de um sistema que inclui módulos e as especificações de hardware e software do banco de dados do sistema. Alguns aspectos que são abordados na camada física:

  • Segurança - usuário final, bem como segurança administrativa.
  • Replicação - quais dados são copiados para outro banco de dados e com que freqüência. Existem vários mestres ou um único?
  • Alta disponibilidade - se a configuração é ativo-passivo ou ativo-ativo, a topologia, o esquema de coordenação, as metas de confiabilidade, etc., todos devem ser definidos.
  • Particionamento - se o banco de dados é distribuído, então para uma única entidade, como os dados são distribuídos entre todas as partições do banco de dados e como a falha de partição é levada em consideração.
  • Esquemas de backup e restauração.

No nível do aplicativo, outros aspectos do design físico podem incluir a necessidade de definir procedimentos armazenados ou visualizações de consulta materializadas, cubos OLAP , etc.

Veja também

Referências

Leitura adicional

  • S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. ISBN  0-12-369389-6
  • M. Hernandez, " Database Design for Mere Mortals : A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. ISBN  0-321-88449-3

links externos