2.1. Design conceptual

O design do banco de dados é realizado em três etapas:

  1. design conceptual;
  2. projeto lógico;
  3. projeto físico.

O objetivo da fase de projeto conceitual é criar um modelo de dados conceitual com base nas ideias dos usuários sobre a área de assunto. Para alcançá-lo, uma série de procedimentos sequenciais são realizados. Um exemplo de um esquema de entidade (conceitual):

1. Definição de entidades e sua documentação. Para identificar entidades, são definidos objetos que existem independentemente dos outros. Tais objetos são entidades. Cada entidade recebe um nome significativo que os usuários podem entender. Os nomes e descrições das entidades são inseridos no dicionário de dados. Se possível, o número esperado de instâncias de cada entidade é definido.

2. Determinação das relações entre entidades e sua documentação. Somente os relacionamentos entre entidades são definidos e são necessários para satisfazer os requisitos de design do banco de dados. O tipo de cada um é definido. A classe de associação de entidades é revelada. Os links recebem nomes significativos expressos por verbos. Uma descrição detalhada de cada conexão, indicando seu tipo e a classe de pertencimento das entidades participantes da conexão, é inserida no dicionário de dados.

3. Criação de um modelo ER da área disciplinar. Diagramas ER são usados ​​para representar entidades e relacionamentos entre elas. Com base neles, uma única imagem visual da área de assunto modelada é criada - o modelo ER da área de assunto.

4. Definição de atributos e sua documentação. Todos os atributos que descrevem as entidades do modelo ER criado são revelados. Cada atributo recebe um nome significativo que os usuários podem entender. As seguintes informações são armazenadas no dicionário de dados para cada atributo:

  • nome e descrição do atributo;
  • tipo e dimensão dos valores;
  • o valor padrão para o atributo (se houver);
  • se o atributo pode ter valores NULL;
  • se o atributo é composto e, em caso afirmativo, em que atributos simples ele consiste. Por exemplo, o atributo "Nome completo do cliente" pode consistir em atributos simples "Sobrenome", "Nome", "Patronímico" ou pode ser simples, contendo valores únicos, como "Sidorsky Evgeniy Mikhailovich". Se o usuário não precisar acessar elementos individuais do "Nome", então o atributo é apresentado como simples;
  • se o atributo é calculado e, em caso afirmativo, como seus valores são calculados.
Java university

5. Definição dos valores dos atributos e sua documentação. Para cada atributo de uma entidade participante do modelo ER, um conjunto de valores válidos é determinado e um nome é atribuído a ele. Por exemplo, o atributo "Tipo de conta" só pode ter os valores "depósito", "corrente", "à vista", "conta cartão". As entradas do dicionário de dados relacionadas aos atributos são atualizadas com os nomes dos conjuntos de valores de atributos.

6. Definição de chaves primárias para entidades e sua documentação. Esta etapa é guiada pela definição de uma chave primária - como um atributo ou conjunto de atributos de uma entidade que permite a identificação única de suas instâncias. As informações da chave primária são colocadas no dicionário de dados.

7. Discussão do modelo de dados conceitual com usuários finais. O modelo de dados conceitual é representado por um modelo ER com documentação de acompanhamento contendo uma descrição do modelo de dados desenvolvido. Se forem encontradas inconsistências de domínio, são feitas alterações no modelo até que os usuários confirmem que o modelo proposto por eles reflete adequadamente suas opiniões pessoais.

2.2 Projeto lógico

O objetivo da etapa de projeto lógico é transformar o modelo conceitual baseado no modelo de dados selecionado em um modelo lógico independente das funcionalidades do SGBD utilizadas posteriormente para a implementação física do banco de dados. Para alcançá-lo, os seguintes procedimentos são realizados.

Um exemplo de um esquema de banco de dados lógico.

1. Escolhendo um modelo de dados. Na maioria das vezes, um modelo de dados relacional é escolhido devido à clareza da apresentação tabular dos dados e à conveniência de trabalhar com eles.

2. Definir um conjunto de tabelas baseadas no modelo ER e documentá-las. Uma tabela é criada para cada entidade do modelo ER. Nome da entidade é o nome da tabela. As relações entre tabelas são estabelecidas através do mecanismo de chaves primárias e estrangeiras. As estruturas das tabelas e as relações estabelecidas entre elas são documentadas.

3. Normalização de tabelas. Para realizar a normalização adequadamente, o designer deve entender profundamente a semântica e os padrões de uso dos dados. Nesta etapa, ele verifica a exatidão da estrutura das tabelas criadas na etapa anterior, aplicando a elas o procedimento de normalização. Consiste em trazer cada uma das mesas pelo menos até a 3ª NF. Como resultado da normalização, obtém-se um design de banco de dados muito flexível, o que facilita a realização das extensões necessárias.

4. Verificar o modelo lógico de dados para a possibilidade de realizar todas as transações fornecidas pelos usuários. Uma transação é um conjunto de ações executadas por um usuário individual ou programa aplicativo para alterar o conteúdo de um banco de dados. Assim, um exemplo de transação no projeto BANCO pode ser a transferência do direito de administrar as contas de um determinado cliente para outro cliente. Nesse caso, várias alterações precisarão ser feitas no banco de dados de uma só vez. Se um computador travar durante uma transação, o banco de dados ficará em um estado inconsistente porque algumas alterações já foram feitas e outras não. Portanto, todas as alterações parciais devem ser desfeitas para retornar o banco de dados ao seu estado consistente anterior.

A lista de transações é determinada pelas ações dos usuários na área de assunto. Usando o modelo ER, o dicionário de dados e os relacionamentos estabelecidos entre chaves primárias e estrangeiras, é feita uma tentativa de executar manualmente todas as operações necessárias de acesso aos dados. Se alguma operação manual falhar, então o modelo de dados lógicos compilado é inadequado e contém erros que devem ser eliminados. Talvez estejam relacionados a uma lacuna no modelo de uma entidade, relacionamento ou atributo.

5. Determinação dos requisitos de suporte à integridade de dados e sua documentação. Esses requisitos são restrições implementadas para evitar que dados conflitantes sejam inseridos no banco de dados. Nesta etapa, as questões de integridade de dados são abordadas sem levar em consideração aspectos específicos de sua implementação. Os seguintes tipos de restrições devem ser considerados:

  • dados requeridos. Descobrir se existem atributos que não podem ter valores NULL;
  • restrições nos valores de atributo. Valores válidos para atributos são definidos;
  • integridade da entidade. É alcançado se a chave primária da entidade não contém valores NULL;
  • integridade referencial. Entende-se que o valor da chave estrangeira deve estar presente na chave primária de uma das linhas da tabela da entidade pai;
  • restrições impostas pelas regras de negócios. Por exemplo, no caso do projeto BANCO, pode ser adotada uma regra que proíba o cliente de administrar, digamos, mais de três contas.

As informações sobre todas as restrições de integridade de dados estabelecidas são colocadas no dicionário de dados.

6. Criação da versão final do modelo lógico de dados e discussão com os usuários. Esta etapa prepara a versão final do modelo ER, que representa o modelo lógico de dados. O próprio modelo e a documentação atualizada, incluindo o dicionário de dados e o esquema de links da tabela relacional, são apresentados para revisão e análise pelos usuários, que devem garantir que ele represente com precisão a área de assunto.

2.3. Projeto físico

O objetivo da etapa de projeto físico é descrever uma implementação específica de um banco de dados localizado na memória externa de um computador. Esta é uma descrição da estrutura de armazenamento de dados e métodos eficientes de acesso aos dados do banco de dados. No design lógico, eles respondem à pergunta - o que precisa ser feito e no design físico - é escolhida uma maneira de fazer isso. Os procedimentos de projeto físico são os seguintes.

1. Projetando tabelas de banco de dados usando o DBMS selecionado. Um DBMS relacional é selecionado para ser usado para criar um banco de dados hospedado na mídia da máquina. Sua funcionalidade para projetar tabelas é profundamente estudada. Em seguida, é realizado o design das tabelas e o esquema de sua conexão no ambiente DBMS. O projeto de banco de dados preparado é descrito na documentação que o acompanha.

2. Implementação de regras de negócio no ambiente do SGBD selecionado. A atualização de informações em tabelas pode ser limitada por regras de negócios. A forma como são implementadas depende do SGBD escolhido. Alguns sistemas para implementar os requisitos da área temática oferecem mais recursos, outros menos. Em alguns sistemas, não há suporte para a implementação de regras de negócios. Neste caso, os aplicativos são desenvolvidos para implementar suas limitações.

Todas as decisões tomadas em conexão com a implementação de regras de negócios de domínio são descritas em detalhes na documentação que acompanha.

3. Desenhar a organização física da base de dados. Esta etapa seleciona a melhor organização de arquivos para as tabelas. As transações que serão realizadas no banco de dados que está sendo desenhado são identificadas, e as mais importantes são destacadas. É analisado o rendimento da transação - o número de transações que podem ser processadas em um determinado intervalo de tempo e o tempo de resposta - o período de tempo necessário para concluir uma transação. Eles se esforçam para aumentar o rendimento das transações e reduzir o tempo de resposta.

Com base nesses indicadores, são tomadas decisões para otimizar o desempenho do banco de dados, definindo índices em tabelas que agilizam a seleção dos dados do banco de dados ou reduzindo os requisitos do nível de normalização das tabelas. O espaço em disco necessário para acomodar o banco de dados criado é estimado. Esforce-se para minimizá-lo.

As decisões tomadas sobre as questões acima são documentadas.

4. Desenvolvimento de uma estratégia de proteção de banco de dados. O banco de dados é um recurso corporativo valioso e muita atenção é dada à sua proteção. Para fazer isso, os projetistas devem ter um entendimento completo e claro de todas as proteções fornecidas pelo DBMS selecionado.

5. Organização do monitoramento do funcionamento do banco de dados e seu ajuste. Após a criação do projeto físico do banco de dados, é organizado o monitoramento contínuo de seu funcionamento. As informações resultantes sobre o nível de desempenho do banco de dados são usadas para ajustá-lo. Para isso, também estão envolvidos os meios do SGBD selecionado.

As decisões de fazer quaisquer alterações em um banco de dados em funcionamento devem ser consideradas e ponderadas minuciosamente.