Tarefas básicas no design de banco de dados

1.1 Introdução

Projetar um banco de dados é um pouco semelhante a projetar a arquitetura de um projeto Java. Você pode colocar todos os dados em algumas tabelas ou pode criar uma bela estrutura de dados a partir de esquemas e dezenas de tabelas.

Aqui estão as tarefas que um desenvolvedor geralmente enfrenta ao projetar um banco de dados:

1. Garantir que todas as informações necessárias sejam armazenadas no banco de dados.
2. Assegurando a possibilidade de obter dados sobre todos os pedidos necessários.
3. Redução da redundância e duplicação de dados.
4. Garantindo a integridade do banco de dados
5. Otimização da velocidade de acesso aos dados

A principal coisa a lembrar é que você não pode fazer uma estrutura de banco de dados ideal, porque. ele, como seu código, também mudará constantemente. Há três coisas que você deve ter em mente ao projetar sua estrutura de banco de dados:

1. A estrutura deve ser boa o suficiente.
2. Deve haver uma lógica em tudo que outras pessoas possam entender.
3. Otimização prematura é a raiz de todo o mal.

Você não precisa criar a melhor estrutura de banco de dados do mundo. Ela ainda vai mudar. Sua tarefa é garantir que, após 20 alterações na estrutura de seu banco de dados, seja fácil descobrir.

Provavelmente, nos primeiros anos de seu trabalho, ninguém confiará em você para projetar uma base do zero. Você fará alterações em um esquema existente. Você precisa tentar entender com base em quais princípios ele é organizado e aderir a eles . Com sua carta, eles não sobem no mosteiro de outra pessoa.

Não otimize o banco de dados até que seja necessário. Se a tabela tiver apenas algumas centenas de linhas, provavelmente o DBMS irá mantê-la na memória e fazer consultas em cache para ela.

Por outro lado, você deve ser capaz de acelerar o trabalho de solicitações importantes em dezenas ou até centenas de vezes. E seria bom se você soubesse como fazer isso. Como se diz no ensino médio no primeiro ano? "Esqueça tudo o que lhe ensinaram na escola..."

Se você sabe o que é normalização de banco de dados, apresso-me em agradá-lo, em seu trabalho você provavelmente lidará com a desnormalização . Nada é mais importante para os santuários do projeto do que a velocidade do banco de dados. E se, para agilizar a seleção dos dados do banco de dados, você precisar combinar 200 (!) Tabelas em uma (com redundância monstruosa), terá que fazer isso.

1.2 Projeto da Biblioteca

Vamos mergulhar um pouco na área de assunto e pensar sobre o design do banco de dados usando algo tão simples quanto uma biblioteca de livros típica.

A principal tarefa de qualquer biblioteca é o processamento do fundo do livro. É fácil distinguir três grupos principais de usuários do sistema: leitor, bibliotecário, administrador . A atividade de cada um é mostrada em um diagrama de caso de uso.

Já agora, algumas entidades e relacionamentos do futuro banco de dados podem ser distinguidos:

Com essa abordagem, não fica claro como conectar o leitor com o livro (o leitor não tem aridade na relação “emissão / recepção”. Se o livro tiver vários exemplares, pode ser emitido para vários leitores. Mesmo se um livro for entendido como uma cópia, quando salvo na tabela de livros do leitor atual, será impossível obter informações sobre quem (e quantas vezes) pegou este livro antes.

A solução pode ser a introdução de uma entidade adicional - um cartão para emissão de um livro. Quando o livro é entregue ao leitor, é criado um cartão e, quando o livro é entregue, é colocada uma marca correspondente. Com a ajuda destes cartões, determinam-se as dívidas de cada utilizador e calculam-se estatísticas sobre a utilização dos livros. Ao reservar literatura pelo leitor, também é iniciado um cartão; se a literatura reservada não for retirada pelo leitor dentro de um determinado período, o cartão é destruído. Há um limite no número de livros que um leitor pode reservar.

Ao selecionar a literatura, o usuário visualiza o catálogo de literatura com a possibilidade de filtrar os resultados da pesquisa por autor, título, ano de publicação.

É possível calcular estatísticas para todos os livros da biblioteca, enquanto o número de exemplares emitidos do livro por um determinado período de tempo. Você também pode definir o número mínimo de instâncias de livro para as quais o cálculo é executado. Com base nessas estatísticas, os livros não utilizados são baixados da biblioteca.

As seguintes entidades principais da área temática podem ser distinguidas:

• usuário (bibliotecários e administradores);
• leitor;
• sala de leitura;
• livro;
• cartão de emissão de livros;
• cartão de reserva de livros.

O diagrama ER modificado do banco de dados é mostrado na figura.

De acordo com os casos de uso mostrados na Figura 1, o banco de dados deve implementar as seguintes consultas (lista não exaustiva):

• exibir livros que correspondam às condições especificadas;
• exibir usuários que possuem cartões de emissão de livros que não foram fechados no prazo (o bibliotecário procura devedores);
• exibir todos os livros que correspondem aos cartões de empréstimo de livros do usuário informado que não foram fechados a tempo (o usuário veio à biblioteca buscar novos livros - você precisa ver se ele é devedor e informá-lo sobre isso);
• excluir todos os cartões de reserva criados há mais de N segundos;
• exibir todos os livros correspondentes aos cartões de reserva de livros não fechados do usuário especificado (o leitor encomendou livros e veio buscá-los na biblioteca - o bibliotecário precisa obter esta lista para distribuí-la).

1.3 Formação do esquema

Para formar um esquema de dados, você deve primeiro complementar o diagrama ER com os detalhes das entidades (refiná-lo). Às vezes, ao mesmo tempo, é possível encontrar erros na construção de um diagrama ER - nessa tarefa, verificou-se que o livro precisava estar “de alguma forma” conectado ao corredor da biblioteca.

Isso pode ser feito colocando o "número do hall" necessário no livro, porém, com essa abordagem, o mesmo livro terá que ser descrito no banco de dados várias vezes (se ocorrer em diferentes halls). Uma abordagem mais correta é introduzir uma entidade adicional "colocação de livro". A figura mostra um diagrama ER com uma entidade adicionada e adereços.

O diagrama ER acima reflete as principais tabelas, relacionamentos e atributos; com base nele, você pode construir um modelo de banco de dados. Não há padrão para o diagrama ER, mas há várias notações (Chen, IDEFIX, Martin, etc.), mas nem o padrão nem as notações foram encontradas para o modelo de domínio. No entanto, durante a construção de tal diagrama, campos-chave (externos e internos) são necessariamente destacados, às vezes índices e tipos de dados.

Neste caso, no esquema a seguir:

• para links, a notação de Martin ("pés de galinha" é usado);
• tabelas são mostradas como retângulos divididos em 3 seções:
• Nome da tabela;
• chaves internas (marcadas com um marcador);
• os demais campos, enquanto os obrigatórios são marcados com marcador.

Ao desenvolver este modelo, houve o desejo de unir a tabela de administradores com a tabela de bibliotecários - adicione a tabela de usuários, porém:

• o administrador não está associado a uma sala específica (teria que preencher o campo correspondente com valores nulos);
• isso provavelmente complicaria a distribuição dos direitos de acesso - agora apenas o administrador do banco de dados (que trabalha por meio de um painel especial do DBMS e não possui uma conta no sistema que está sendo desenvolvido) tem acesso à tabela de administradores. No entanto, ao unir tabelas, as consultas do usuário exigiriam acesso à nova tabela.

Ao construir este diagrama, uma falha no diagrama ER foi encontrada e corrigida - foi adicionada uma tabela librarians_roomsque une bibliotecários e corredores. Isso é necessário porque um bibliotecário pode trabalhar em várias salas, mas vários bibliotecários podem trabalhar na mesma sala.

Ao projetar bancos de dados, você deve ser capaz de raciocinar pelo menos como no exemplo acima. Se você acha que conseguiu, vamos além: ainda mais teoria.