Projeto de banco de dados

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Projeto de banco de dados é a organização de 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 inter-relacionam. Com essas informações, eles podem começar a ajustar os dados ao modelo de banco de dados. [1] O sistema de gerenciamento de banco de dados gerencia os dados de acordo.

O projeto de banco de dados envolve a classificação de dados e a identificação de inter-relações. 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 [ editar ]

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 esteja ciente de quais dados devem ser armazenados no sistema.

Esse processo é geralmente considerado parte da análise de requisitos e requer habilidade por parte do projetista de banco de dados para extrair as informações necessárias daqueles com 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 Requisito. [2]

Determinando relacionamentos de dados [ editar ]

Uma vez que um designer de banco de dados esteja 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 exclusivamente; no entanto, o inverso não ocorre - quando dado 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 da declaração de relacionamentos entre os elementos de dados nele. Isso não é verdade. O modelo relacional é assim chamado porque é baseado em estruturas matemáticas conhecidas como relações .)

Dados de estruturação lógica [ editar ]

Uma vez determinadas as relações e dependências entre as várias informações, é possível organizar os dados em uma estrutura lógica que pode 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 de objetos 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 forma como esse mapeamento é geralmente realizado é tal que cada conjunto de dados relacionados que dependem de um único objeto, seja real ou abstrato, é colocado em uma tabela. Os relacionamentos entre esses objetos dependentes são então armazenados como links entre os vários objetos.

Cada tabela pode representar uma implementação de um objeto lógico ou um relacionamento unindo uma ou mais instâncias de um ou mais objetos lógicos. Relacionamentos entre tabelas podem ser armazenados como links conectando tabelas filhas com pais. Como relacionamentos lógicos complexos são tabelas, eles provavelmente terão links para mais de um pai.

Diagrama ER (modelo entidade-relacionamento) [ editar ]

Um exemplo de diagrama Entidade-relacionamento

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

Atributos em diagramas ER geralmente são modelados como uma forma 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. [3]

Uma sugestão de processo de design para o Microsoft Access [ editar ]

  1. Determinar 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ção em entidades ou assuntos principais, como Produtos ou Pedidos. Cada assunto torna-se então uma tabela.
  4. Transforme 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 de tabela - Observe cada tabela e decida como os dados em uma tabela estão relacionados aos dados em outras tabelas. Adicione campos a tabelas ou crie novas tabelas para esclarecer os relacionamentos, conforme necessário.
  7. Refinar 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.

[4]

Normalização [ editar ]

No campo do design de banco de dados relacional , a normalização é uma maneira 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 executada 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, padrões comuns de recuperação de dados podem agora precisar de junções, mesclagens e classificações complexas para ocorrer - o que ocupa mais dados ler e calcular ciclos. Algumas disciplinas de modelagem, como a abordagem de modelagem dimensional para data warehousedesign, recomendar explicitamente designs não normalizados, ou seja, designs que em grande parte não aderem à 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 adotam uma abordagem diferente. Um documento armazenado em tal banco de dados normalmente conteria mais de uma unidade de dados normalizada e, muitas vezes, também os relacionamentos entre as unidades. Se todas as unidades de dados e os relacionamentos em questão forem frequentemente recuperados juntos, essa abordagem otimiza o número de recuperações. Também simplifica como os dados são replicados, porque agora há uma unidade de dados claramente identificável cuja consistência é autocontida. Outra consideração é que ler e escrever um único documento em tais bancos de dados exigirá uma única transação - o que pode ser uma consideração importante em um Microservices .arquitetura. 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 motivos 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 o preferido.

Esquema conceitual [ editar ]

Projeto físico [ editar ]

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ção detalhada de elementos de dados, tipos de dados , opções de indexação e outros parâmetros que residem no dicionário de dados DBMS . É o projeto detalhado de um sistema que inclui módulos e 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 partes de dados são copiadas para outro banco de dados e com que frequência. Existem vários mestres ou um único?
  • Alta disponibilidade - se a configuração é ativa-passiva ou ativa-ativa, a topologia, esquema de coordenação, 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 consultas materializadas, cubos OLAP , etc.

Veja também [ editar ]

Referências [ editar ]

  1. ^ Teorey, TJ, Lightstone, SS, et al., (2009). Design de banco de dados: saiba tudo.1ª ed. Burlington, MA.: Morgan Kaufmann Publishers
  2. ^ Teorey, T.; Lightstone, S. e Nadeau, T.(2005) Database Modeling & Design: Logical Design , 4ª edição, Morgan Kaufmann Press. ISBN  0-12-685352-5
  3. ^ Javed, Muhammad; Lin, Yuqing (2018). "Processo iterativo para geração de diagrama ER a partir de requisitos irrestritos" . Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering . SCITEPRESS - Publicações de Ciência e Tecnologia: 192–204. doi : 10.5220/0006778701920204 . ISBN 978-989-758-300-1.
  4. ^ Noções básicas de design de banco de dados. (nd). Noções básicas de projeto de banco de dados. Recuperado em 1º de maio de 2010, de https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5

Leitura adicional [ editar ]

  • S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: o guia do profissional de banco de dados para explorar índices, visualizações, armazenamento e mais”, Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6 
  • M. Hernandez, " Design de banco de dados para meros mortais : um guia prático para design de banco de dados relacional", 3ª edição, Addison-Wesley Professional, 2013. ISBN 0-321-88449-3 

Links externos [ editar ]