Chris Travers recentemente publicou uma série de artigos intitulados "Construindo Banco de Dados com princípios SOLID", que explicam diversas idéias de como aplicar alguns dos princípios comuns da programação orientada a objetos como o Princípio da Responsabilidade Única, Segregação de Interface e Inversão de Dependência para melhorar os modelos de dados e código no banco de dados. Algumas dessas idéias podem ser aplicadas parcialmente em qualquer banco de dados relacional, os artigos apresentam cenários que envolvem características como herança entre tabelas o qual estão disponíveis em produtos como o PostgreSQL.
No artigo Normalização e o Princípio de Responsabilidade Única (SRP), Chris explica as semelhanças e diferenças sutis existentes entre modelos de dados e modelos de classes. A normalização é normalmente suficiente para reunir a SRP em bancos de dados relacionais puros, porém a herança entre tabelas pode ser usada para gerenciar campos que normalmente ocorrem em mais de uma tabela e que são dependentes de outros campos no banco de dados. Chris Travers exemplifica com a seguinte declaração:
Um exemplo simples em que a composição faz uma grande diferença é no gerenciamento de notas. As pessoas desejam anexar notas em qualquer tipo dado existente em um banco de dados e dessa forma não há como afirmar que o texto ou o objeto de uma anotação é mutuamente dependente.
Uma abordagem típica e puramente relacional é a de querer ter várias tabelas gerenciadas independentemente ou a de ter uma tabela única global que armazena as notas de todos. E desta forma ter múltiplas junções de tabelas com o objetivo de adicionar dependências de junções.
Uma abordagem objeto relacional poderia ser a de ter várias tabelas de notas, porém que fosse capaz de herdar a estrutura de uma tabela comum como se fosse uma tabela de notas.
O artigo Princípio do Aberto / Fechado tem o objetivo de explicar como deixar o sistema extensível, sem criar extensões quebráveis quando a versão básica sofre alguma modificação. Novamente, herança em tabelas pode fornecer um caminho flexível capaz de promover pontos de extensão para os modelos de dados - o exemplo apresentado questiona como o pg_message_queue 0.2 pode manusear vários tipos de dados tendo uma tabela separada que suporte cada tipo de dado e todas as heranças que são comuns a uma determinada tabela. Chris fornece também um outro exemplo simples que uma API segura é mantida extensível para o controle da segurança e ao mesmo tempo está fechada para modificações.
Chris cita no artigo Princípio da Substituição de Liskov que este normalmente não é um problema para banco de dados puramente relacionais porém pode ser um problema que surgirá quando se faz uso de herança em tabelas. Como exemplo, Chris cita duas tabelas, my_square que herda my_rectangle:
CREATE TABLE my_rectangle ( id serial primary key, height numeric, width numeric ); CREATE TABLE my_square ( check (height = width) ) INHERITS (my_rectangle);
ao executar um update na tabela my_rectangle
UPDATE my_rectangle SET height = height * 2
Esta ação irá causar problemas de integridade referencial na tabela my_square e falhará. Formas de lidar com essa anomalia seria a de evitar atualizações completas (manter as linhas imutáveis) ou usar triggers para excluir linhas da tabela my_square e inserir em my_rectangle sempre que essas atualizações são executadas.
A Segregação de Interface quando aplicada a banco de dados envolveria principalmente funções definidas pelo usuário ou stored procedures. Chris as considera como interfaces para dados escondidos e sugere que a função ideal ou stored procedure teria uma grande consulta com uma lógica circundante mínima - nada mais que 5 consultas ou um grande número de parâmetros opcionais poderiam apontar para a complexidade reduzível que deve ser tratada por quebrar em várias funções separadas ou stored procedures, cada um com seu propósito específico. Mais uma vez, este princípio anda de mãos dadas com o Princípio da Responsabilidade Única.
No artigo Inversão de Dependência e Interfaces de BD Robustas, Chris detalha que fechar o vínculo entre a lógica da aplicação e stored procedures pode levar ao vazamento de abstrações e sugere algumas potenciais soluções. Algumas dessas soluções estão em fazer uso de algo semelhante a um localizador de padrões de serviços, por meio de views ou funções, utilizando tipos de dados customizados ou por meio de gatilhos e notificações.
A sugestão de Chris Travers é a de observar e estudar as inúmeras opções disponíveis e projetar o banco de dados como uma aplicação que expõe uma API devidamente apropriada.