Como implementar um banco de dados

Esse artigo descreve os passos práticos de como criar um banco de dados. Um banco de dados bem desenhado é “completo”, “usável”, “consistente”, “correto” e “flexível”. Os estágios do ciclo de desenvolvimento de um banco de dados podem ser visualizados como um modelo em cascata linear. Uma parte importante do desenho descrita no artigo é construir modelos de dados que cobrirão os dados em níveis cada vez menores de abstração.

Por quê banco de dados?

A abordagem via sistema de banco de dados para o gerenciamento de dados supera muitas das deficiências da abordagem antiga baseada em arquivos. Um dos recursos chaves de um sistema de banco de dados é que é armazenado como uma unidade lógica única. Isso significa que no lugar dos dados serem espalhados por múltiplos arquivos, o banco de dados converge todos eles para um único repositório. Organizar os dados em um único repositório permite manipulação fácil dos dados, em contraste com os sistemas de arquivos tradicionais onde o programador precisa especificar o que e como os dados devem ser recuperados. Com sistemas de banco de dados, é necessário apenas especificar o que precisa ser feito, e o SGBD (Sistema gerenciador de banco de dados) faz o resto. Outra vantagem da abordagem via banco de dados é que, pelos dados estarem localizados em um único local, dados em locais físicos diferentes não precisam ser duplicados. O sistema de banco de dados pode interagir com todos os dados da base. A não duplicação de dados é uma das formas de manter a integridade dos dados. Quando se permite duplicação dos dados, erros podem ocorrer se uma instância dos dados for alterada e outra permanecer a mesma. Por causa disso, mas recursos do sistema são necessários para garantir que a integridade dos dados.
Um dos grandes benefícios dos banco de dados é que os dados podem ser compartilhados de forma segura entre usuários ou aplicações. Existe mais controle sobre como os dados são gerenciados porque todos eles residem em uma única base.
Se existem deficiência em relação aos sistemas de banco de dados, é que eles requerem software muito mais poderosos e sofisticados para controla-los e desenhar o software e o banco de dados pode consumir bastante tempo. Um conhecimento mair de como usar o banco de dados é necessário, tornando assim o sistema de banco de dados menos amigável que os sistemas baseados em arquivos. Já que o banco de dados está em um repositório lógico, mesmo um pequeno erro pode danificar o banco de dados inteiro e reduzir a integridade dos dados. Um bom banco de dados é um que seja completo, integro, simples, entendível, flexível e implementável.  Seguindo a metodologia de desenvolvimento de software de banco de dados, e usando os modelos de dados, os ideais do design de banco de dados são alcançados e as desvantagens são minimizadas.

Banco de dados e o ciclo de desenvolvimento do software

 

Os passos do desenvolvimento que qualquer aplicação podem ser representadas em uma sequência linear onde cada passo da sequência é uma função, que passa sua saída para a função que a sucede. A aderência do “modelo de desenvolvimento Cascata” garante a qualidade do software, que deve ser “completo”, “eficiente”, “usável”, “consistente”, “correto” e “flexível”.  Esses traços são também alguns das bases fundamentais para um banco de dados bem construído. O modelo Cascata pode ser aplicado a teoria do design de banco de dados tão efetivamente quanto é aplicada a outras teorias de engenharia de software. Os passos podem ser resumidos da forma seguinte:
Especificação de requisitos -> Análise -> Desenho conceitual -> Implementação -> Desenho e otimização do esquema físico
 
Ao Consultar todos os potenciais usuários do banco de dados, o primeiro passo do desenhista do banco de dados é escrever um documento com os requisitos dos dados. Esse documento contém um sumário conciso e não técnico do quais itens serão armazenados na base de dados, e comno os vários itens relacionam-se entre si. Tomando o documento de requerimentos de dados, uma análise mais profunda é feita para dar significado a cada item, por exemplo, definir em detalhes os atributos dos dados e definir restrições se necessário. O resultado dessa análise é o documento de especificações preliminares. Tomando esse documento, o designer do banco de dados modela como a informação é vista pelo banco de dados e como é processada para o usuário final. Na fase da implementação do design, o design conceitual é traduzido para um nível mais baixo, o design específico do SGBD.

Modelos de dados e Esquemas como meios de captura de dados

As fases do design do banco de dados trazem a tona o conceito de ‘modelos de dados’. Modelos de dados são diagramas ou esquemas, que são usados para apresentar os requisitos dos dados em níveis diferentes de abstração. O primeiro passo do ciclo de desenvolvimento do banco de dados é escrever um documento de requisitos.
 

Figure 1: A basic example of a requirements document

O documento de requisitos pode então ser analisado e transformado em um conjunto de dados básicos (como mostrado na figura 2) que pode ser convertido em um modelo conceitual. O resultado final da fase do design conceitual é um modelo conceitual de dados (Figura3), que fornece algumas informações de como o banco de dados deve ser implementado. O modelo conceitual dos dados é simplesmente um visão geral em alto nível do sistema de banco de dados.

Figure 2: A Database Data Set is the Result of analysing the Information from the Requirements Phase. The Primary Keys are Underlined.
Figure 3: A Normalized Entity-Relationship model (ERD) in Crow’s Foot Notation is an Example of a Conceptual Data Model and provides no information of how the database system will eventually be implemented
Na fase de implementação, o modelo conceitual é traduzido em uma representação lógica do sistema de banco de dados. O modelo lógico cobre  a estrutura e funcionamento lógico do banco de dados, e descreve como os dados são armazenados (exemplo, quais tabelas são usadas, quais restrições são aplicadas) mas não é especifica de nenhum SGBD. O modelo lógico é um modelo conceitual de baixo nível, que precisa ser traduzido para um design físico.
Figure 4: In the implementation design phase, the conceptual data model (ERD) is translated into a ‘logical’ representation (logical schema) of the database system: a data dictionary.
A modelagem física lida com aspectos de representação e aspectos operacionais do banco de dados, isto é, as operações e processos específicos do SGBD e como ele interage com os dados, com a base de dados e com o usuário. A tradução do design lógico para o físico associa funções tanto para a máquina quanto para o usuário, funções como armazenamento e segurança, e aspectos adicionais como consistência (dos dados) e aprendibilidade são lidados com o modelo/esquema físico. De forma prática, um esquema físico é o código SQL usado para construir o banco de dados.
(i) Ao criar um modelo lógico, dados extras podem ser adicionados mais facilmente nesse modelo do que no modelo físico. Um design de banco de dados que pode mudar facilmente de acordo com as necessidades da companhia é importante, porque garante que o sistema de banco de dados final seja completamente atualizável.
(ii) Outra consideração é a entendibilidade. Pela criação inicial de um “modelo conceitual”, tanto o designer quanto a organização serão capazes de entender o design do banco de dados e decidir se ele está completo ou não. Se não houver um modelo conceitual, a organização pode não ser capaz de conceitualizar o design do banco de dados e garantir que ele represente de fato todos os requisitos de dados dela.
(iii) Pela criação de um modelo físico, os designers podem ter uma visão geral de baixo nível de como o sistema de banco de dados deve operar antes de ser implementado de fato.

Sentenças SQL – Implementando o banco de dados

O passo final é implementar fisicamente o design lógico, o que é ilustrado na figura 4. Para implementar fisicamente o banco de dados, o SQL pode ser usado. Esses são os passos principais na implementação da base de dados:

1. Criar as tabelas do banco de dados

As tabelas vem diretamente da informação contida no Dicionário de dados. Os blocos de código a seguir representam uma linha do dicionário de dados e são executados um após o outro. Os blocos de “create table” contém os detalhes de todos os itens de dados, seus atributos, o relacionamento entre eles, as chaves e as regras de integridade. Todas essas informações foram detalhadas no dicionário de dados, mas agora iremos de fato convertê-las e implementa-las em um sistema de banco de dados físico.

2. Popular as tabelas

Use as sentenças SQL para popular cada tabela com dados específicos (como nome, idade, salário, etc)

3. Consultar o banco de dados

Escreva sentenças SQL para obter informações e conhecimento sobre a companhia, exemplo, quantos empregados existem, total de lucro, etc.

Chaves e Regras de integridade dos dados

As regras de integridade de dados são um dos componentes mais importantes de um modelo de dados. As regras de integridade “definem, implicitamente ou explicitamente, o conjunto de estados consistentes do banco de dados”. Assim, as regras de integridade garantem que os estados dos banco de dados e as mudanças de estado ocorrem de acordo com as regras especificadas. As regras de integridade de dados podem ser de dois tipos: regras de integridade de Entidade ou regras de integridade Referencial.

Como as chaves se relacionam para garantir que as mudanças nos estados do banco de dados estejam de acordo com as regras especificadas?
Bem, por exemplo, você pode garantir que a chaves primária de uma entidade não possa ser nula. Essa é uma maneira de garantir integridade da entidade. Se as chaves primárias puderem ser nulas, então não haverão maneiras de garantir que entidades individuais sejam identificadas unicamente. Se você não puder garantir isso, então não pode garantir a integridade do banco de dados, que é uma propriedade básica do modelo de dados. Assim, garantindo que as chaves sigam certas regras, você pode garantir a integridade dos dados.
Outra maneira de forçar a integridade dos dados via chaves é garantir que, se duas tabelas são relacionadas uma a outra, um atributo de uma delas deve ser o atributo primário de outra (chave primária). Forças essa regra garante a integridade referencial dos dados.

Traduzido de: