Modelagem e Administração de Dados em PostgreSQL
Fundamentos e práticas em bases de dados lⅳresLeandro Guimarães Faria Corcete DUTRA
Conferência PostgreSQL Brasil
Sumário
Do que vamos falar
O Modelo Relacional
Administrativia
Administração de dados a la Unix
Bibliografia
Do que vamos falar
Tem bastante gente aqui… talvez muita gente ache que o título foi tão interessante que se decepcione com a palestra. Darei algumas informações sobre o que falarei, aposto que alguns perderão o interesse.
Modelagem é muito mais que diagramação. Mapeamento torna a administração impossível.
SQL não é relacional e contém muitos limites arbiários. Esta não é uma palestra sobre ORM, diagramas de classe ou entidade-relacionamento (DER). Entidade-relacionamento é apenas diagrama, um resumo, não captura todo o modelo; melhor deⅸar os DERs como resumos dum modelo mais detalhado, e aliás gerá-los automaticamente.
ORM tem causado muitos danos — tecnologias como Hybernate e Ruby on Rails, embora tenham seus usos, têm de ser usadas de modo a aceitar o modelo de dados projetado em vez de impô-lo, ou causam grandes desastres não só de
modelagem lógica como também de desempenho, escalabi-lidade e compleⅺdade de programação. Tenho cicaizes de Hybernate para mostrar. E isso, em parte, porque orien-tação a objetos é mais física que o modelo relacional, que é mais abstrato. Por exemplo, ORM costuma conduzir ao uso de chaves artificiais, que deveriam ser ⅵstas só pelo pro-gramador de sistemas; o modelo relacional lida com chaves naturais, que são úteis para o usuário e o aplicatⅳo.
O principal é que ORM não mapeia objetos ao modelo relacional, mas ao SQL — que não é relacional, mas contém limites arbiários não só dos produtos em relação ao padrão ISO SQL, mas do próprio padrão em relação ao modelo. E o mapeamento não leva em conta os conceitos do modelo relacional. Assim, o uso de um ORM como ferramenta de modelagem torna impossível por exemplo ter um dicionário de dados decente: afinal onde num ORM definem-se o co-meço de qualquer dicionário de dados, que são o glossário e o dicionário de tipos de dados?
Não significa que certas ferramentas não podem ter seu uso; o SQL Alchemy do Python no campo dos ORM, o pgDesigner no campo dos DER dedicados são interessantes. Só não podem ser usadas como ponto de partida nas tarefas de modelagem e administração de dados.
Algumas dicas:
Diagramadores têm de suportar dicionários de dados. Mapeadores têm de passar do modelo de dados para o de
classes.
Há muita ferramenta de DER ou UML que força o uso de tipos simples dos SGBDs ou do padrão ISO SQL, e mapeadores que não permitem fazer modelagem de dados propriamente dita. Escolha suas ferramentas levando isso em conta; se as ferramentas já foram escolhidas, principalmente no caso do mapeador, investigue a fundo a possibilidade de configurá-la para aceitar um modelo de dados são; muitas vezes a ferramenta permite pelo menos alguns ajustes mas
eⅺste toda uma cultura ene os usuários que acaba até es-condendo esse conhecimento.
Para entendermos porque um DER não serve como ponto de partida dum esforço sério de modelagem e ad-ministração de dados, comecemos com uma inodução ao problema da gestão de dados.
.
O problema da gestão de dados
Temos de definir a importância da administração de dados. Vejamos a opinião de duas autoridades, uma moderna, oua ‘antiga’. E nenhuma das duas é da área de bases de dados.
…o git é um projeto simples, com estruturas de dados estáveis e razoavelmente bem documen-tadas. …sou grande proponente de projetar o có-digo em torno dos dados, em vez do conário, e creio que é uma das razões para o git ter tido bastante sucesso.
…a diferença ene um mau e um bom pro-gramador é se considera o código ou as estruturas de dados mais importantes. Maus programadores preocupam-se com código. Bons programadores preocupam-se com estruturas de dados e seus re-lacionamentos.
— T, Linux.
Fred Brooks coordenou o projeto OS/, sistema ope-racional que, sob dⅳersos nomes, equipa os mainframes IBM desde os anos ., garantindo ⅵnte e cinco anos de domínio do mercado. Surpreendentemente, Brooks o con-siderou um acasso, e tirou algumas lições. Uma delas(??):
Mostra-me teus fluxogramas e esconda-me tuas tabelas, e continuarei no escuro.
Mostra-me tuas tabelas, e… não precisarei de teus fluxogramas: serão óbⅵos.
— B, Frederick Phillips, Jr.: The
Mythical Man-Month.
O ‘acasso’ do OS/ foi um dos eventos que prenun-ciou a Crise de Software, a percepção de que o progresso da Informática tem seu gargalo na programação. Até hoje, a falta de ênfase em, e organização dos, dados, tem sido um dos componentes dessa crise.
O Modelo Relacional
Edgar Frank ‘Ted’ Codd criou a solução: o Modelo Rela-cional(??). Embora o PostgreSQL não seja relacional ― é SQL, ⅵolando vários fundamentos do Modelo Relacional ― é talvez o SGBD que mais se aproⅺme do modelo, inclu-sⅳe usando a nomenclatura relacional em sua documentação e dicionário de dados.
Abstrato
Independência de dados Sem limites arbitrários
O Modelo Relacional é uma teoria geral de dados for-necendo os meios para organizar quaisquer dados — inclu-sⅳe os chamados ‘ricos’ ou ‘desestruturados’. Os SGBDs atuais são bastante primitⅳos, suportando apenas o SQL; isso, asssociado a uma ênfase geral em tecnologia em vez de conceitos, faz muitas equipes se concenarem nos me-canismos e esqueçam as questões de conceito, política, e projeto. Ironicamente, ignorar o modelo relacional dessa maneira muitas vezes leva a problemas inclusⅳe de desempe-nho, chegando ao desastre — e quase sempre a uma bagunça muito grande.
. Componentes
O modelo relacional é composto de(??):
Bases de dados ou conjuntos organizados de dados. Esquemas ou espaços de nomes para os objetos de dados. Domínios ou listas de valores aceitáveis numa determinada
variável.
Operadores ou operações possíveis sobre determinado do-mínio.
Tipos de dados ou domínio mais os operadores correspon-dentes.
Relvars ou variáveis de relação, ou estruturas de tabelas. Relações ou tabelas, com n aibutos.
Restrições de integridade de dados ou regras de negócio.
Notem que o Modelo Relacional não tem nada a ver com os relacionamentos dos Diagramas de Entidades e Rela-cionamentos, mas com as relações, subconjuntos do produto cartesiano de n domínios. Voltaremos a essa idéia quando fa-larmos de chaves.
Vamos analisá-los, não nessa ordem.
.. Bases de dados e esquemas
A definição de bases de dados pode parecer óbⅵa ― mas foi incluída para permitir discutir o primeiro problema da gestão de dados para a qual o PostgreSQL, implementando corretamente o padrão ISO SQL(??), oferece uma solução simples e elegante.
Muitos sistemas criados em MS SQL Server, Oracle ou principalmente MySQL soem de uma confusão ene usuá-rio, esquema e base de dados. Criam-se vários depositozi-nhos de dados ― por exemplo com CREATE DATABASE no MySQL ou CREATE USER no Oracle ― sem se dar conta de que esses na verdade são esquemas: espaços de no-mes com função meramente organizacional. Parece coisa de somenos, mas o efeito são vários ‘feudos’ de dados, criando uma colcha de retalhos inconsistentes. Ao manter uma única massa de dados, apenas organizada em esquemas, começa-mos a permitir uma gestão global dos dados de qualquer organização — inclusⅳe abrindo espaço para distribuição de dados e paralelização do processamento, sem expor tanto os problemas de escalabilidade para a aplicação. A menos que você seja o Skype ou o Google, deⅸe o SGBD se preocupar com escalabilidade e distribuição, conserve a simplicidade da aplicação.
Resista à tentação de rodar aquele script DDL duma ferramentinha web sem alterações no PostgreSQL… prova-velmente vai criar uma base de dados desnecessariamente, porque o MySQL chama um esquema incorretamente de base de dados. Altere-o para criar um esquema: você vai ter uma única base de dados com um esquema para cada apli-cação, facilitando muito integração, pesquisas &c.
Incidentalmente, essa agmentação de bases de dados é um dos motⅳos válidos para usar uma ferramenta de mo-delagem de dados: permite manter um dicionário unificado ene várias bases dispersas.
.
Restrições de integridade
É importante expressar todas as regras de negócio como res-ições de integridade de dados em vez de código de aplicação
por alguns motⅳos:
.. Vantagens
Restrições são declarativas mas aplicação é procedural. Centralização das regras no serⅵdor de dados.
Formalização das regras na análise.
Dizer o quê em vez de como facilita a otimização.
O uso das regras de negócio no aplicatⅳo, típico dos tempos pré-relacionais e que volta à moda por um enten-dimento muito cru, até errôneo da ‘arquitetura de ês ca-madas’, força a escrita de código procedural — aliás, OO
também é procedural — muito mais complexo de escrever;
abre a possibilidade para inconsistência de dados pela falha na aplicação de regras pelos aplicatⅳos; força a passagem da linguagem natural, imprecisa, dos requisitos, direto para a codificação; e impede o SGBD de otimizar o acesso aos da-dos.
Em conaste, o uso de restrições de integridade é de-claratⅳo, portanto relatⅳamente simples; cenaliza as regras de negócio no SGBD, impedindo sua ⅵolação por algum usuário ou aplicação; ajuda o analista de sistemas a forma-lizar as regras de negócio numa linguagem possível de se explicar ao usuário, prevenindo ambigüidades e omissões; e, sendo abstrato, permite ao SGBD uma otimização maior do acesso a dados.
.. Classificação
As regras de negócio podem ser de quao tipos diferen-tes(??)(??):
de tipo é a definição do próprio tipo.
de atributo é a definição do tipo dum aibuto. de relvar é uma restrição sobre uma relação.
de base de dados é uma restrição sobre várias relações.
.
Domínios, operadores e tipos de dados
Pelo menos para quem tem alguma formação matemática, estes ês também deⅵam ser óbⅵos. Mas aqui o próprio SQL inoduz alguma confusão, e a Orientação a Objetos mais ainda.
Toda informação ― armazenada numa variável ― tem de ter um tipo. O tipo vai definir, primeiro, valores válidos (domínio); segundo, operações válidas, inclusⅳe compara-ções com ouos tipos. Portanto, a primeira e mais impor-tante regra de negócio é o tipo. Tenho de saber que o meu salário não pode ser negatⅳo ou alfabético, que não dá para comparar salário de endereço, e que não posso subair um de meu endereço (por exemplo).
Para que a aplicação possa beneficiar-se das regras de negócio expressas como restrições de integridade, o pro-blema é que, em SQL:
Tipos de dados simples são muito poucos mesmo para co-meçar uma aplicação muito simples.
Falta de extensibilidade significa que muitas vezes não se conseguem criar tipos específicos para a aplicação. Extensibilidade de baixo nível eⅺge programação em
lin-guagens de sistema (C, D &c) — o ISO SQL não tem a capacidade de gerar seus próprios tipos!
DOMAINS e TYPES SQL são apenas gambiarra que pre-cisam ser combinadas para serem úteis.
O ISO SQL define apenas uns poucos tipos de dados muito simples, praticamente inúteis, a tal ponto que há quem os ignore e defina tudo como alfanumérico ― não reco-mendo isso! Deveria haver uma extensibilidade do sistema de tipos que permitisse nunca usarmos os tipos primitⅳos do SQL em nossas tabelas, mas sempre definirmos tipos es-pecíficos da aplicação, que reflitam as regras de negócio. En-etanto, poucos produtos são assim extensíveis, e quando o são, costumam:
Violar o padrão SQL com linguagens proprietárias de ex-tensão (C#, PL/SQL).
Violar o padrão com definições diferentes de tipos (objetos &c).
Exigir linguagens de baixo nível como C ou D em vez do próprio SQL/PSM.
Muitas vezes é necessário ⅵolar o padrão por esse ser estúpido ou ulapassado. Talvez a proposta do MS SQL Server seja interessante nesse sentido, de definir os tipos em MS.Net para que fiquem disponíveis não só ao SGBD como a todos os aplicatⅳos ― mas ainda não analisei a fundo o suficiente para ver quão bem funciona.
O ideal seria que a linguagem de dados fosse também a linguagem de programação de sistemas, ou pelo menos pudesse estender o sistema de tipos do sistema operacional como um todo. Mas enquanto isso, o PostgreSQL oferece algumas facilidades relatⅳas. Uma é o novo, na versão ., ENUM(??); ouos já são adicionais:
CREATE TYPE humor AS ENUM
( ' t r i s t e ' , ' n o r m a l ' , ' c o n t e n t e ' ) ; CREATE DOMAIN c e p AS TEXT
CHECK (VALUE ~ ' ^ \ \ d { } \ \ d { } ' ) ; Essa abordagem tem alguns problemas:
Cobre poucos valores aavés de ENUM. TYPE não usa CONSTRAINTs. DOMAIN não implementa operadores.
Combinando primeiro TYPE, depois DOMAIN.
O problema é que com o
CREATE …TYPE AS ENUM conseguimos apenas tipos discretos com relatⅳamente poucos valores. Oua possibilidade é o uso de uma linguagem de programação de sistemas, como C. Não vou mostrar como fazê-lo, mas há documentação a respeito(??). O problema: ter na equipe programadores capacitados para implementar a especificação dos tipos.
Ouo problema é que essa declaração não é su-ficiente para implementar as regras de negócios, algu-mas das quais eⅺgem associar ao tipo restrições como CONSTRAINT CHECK, as quais não podem ser de-claradas no CREATE TYPE — em ouas palavras, o CREATE TYPE do ISO SQL não é uma declaração su-ficiente.
Uma maneira de contornar essa limitação é definir pri-meiro um TYPE, e por cima dele um DOMAIN. Assim conseguimos uma boa aproⅺmação de um tipo de dados de-cente.
.
Outras restrições
Gastamos bastante tempo falando dos tipos. Proposital-mente, porque são a base de tudo. Vejamos alguns ouos tipos de restrições que ajudam a modelagem.
NOT NULL ajuda a normalização e eⅵta surpresas.
Chaves primárias ansformam simples tabelas em relvars. Chaves estrangeiras ou integridade referencial.
CHECK pode ser usado para implementar ouas restrições, com limites.
Gatilhos embora procedurais tapam alguns buracos. Algumas restrições ficam de fora.
NOT NULL deveria ser uma disciplina, incluído no DOMAIN sempre que possível. A nossa experiência mostra que tabelas contendo muitos NULLs geralmente são falhas em normalização — na qual falamos muito pouco, mas junto com as restrições de integridade são o que há de mais im-portante em modelagem de dados.
Um parêntese: não falamos em normalização porque nosso foco é PostgreSQL e os problemas de normalização em não são particulares ao PostgreSQL, e são interessantes demais para uma palestra tão curta.
Chaves são essenciais — não só na sabedoria popular dos DBAs, mas também porque simplificam em muito o acesso aos dados, eⅵtando todo tipo de anomalia. Elas pra-ticamente ansformam as reles tabelas SQL em boas apro-ⅺmações às relações que dão nome ao Modelo Relacional.
Quanto aos ouos tipos de restrição, temos um certo azar. O PostgreSQL implementa alguns tipos de restrições de base de dados e de relvar, mas falta muito ainda. Por exemplo, CHECK não suporta restrições multituplas, mas apenas deno da mesma tupla, muito menos para ouas re-lações. O ISO SQL nem suporta restrições de ansições(??), que têm de ser implementadas proceduralmente ⅵa gatilhos (TRIGGERs).
Administrativia
Por esse falso latim, administrativia, quero dizer o fecha-mento de toda essa técnica nos aspeos gerenciais e de ma-nutenção:
Dicionários de dados são essenciais.
Diagramas podem, e devem, ser gerados automaticamente. Ferramentas de modelagem podem unificar modelos de
dⅳersas bases.
Sobre ferramentas de modelagem já falamos acima: embora não sejam essenciais, podem ajudar principalmente
quando temos de lidar com várias bases de dados. Ene-tanto, não sei de nenhuma que suporte um modelo com-pleto, com todos os detalhes dos tipos de dados.
Glossários são úteis.
Dicionários de tipos de dados são essenciais. Dicionário geral de dados dão mais abalho. Diagramas te promovem: AutoDoc!
.
Glossários
Glossários unificam o entendimento da organização sobre os dados. São portanto mera informação em linguagem natu-ral, ambígua mas muito útil. Basta usar um LATEX ou, na
falta, BROffice.org aqui.
.
Dicionários de tipos de dados
Os tipos de dados devem ser todos dicionarizados. Em prin-cípio, nenhuma relação deve ser definida com aibutos que ainda não foram dicionarizados.
.
Diagramas
AutoDoc é a salvação. Sem ele, perde-se muito tempo fa-zendo o que não passa dum resumo parcial do modelo de dados: o DER. Com ele, criar DERs passa a ser uma rotina automática, que se coloca no crontab.
Onde o AutoDoc não atende, o SQL Fairy ajuda. Só se assegure ler sua página inicial num navegador com a carga de imagens desabilitada: ela queima um filme impressionante.
Proposta: Administração de dados a
la Unix
Esta é uma idéia bem incipiente, nascida na pgbr-geral. As ferramentas de modelagem ustram. As ‘profissi-onais’ são cerca de USK, chegando a USK com ‘luxos’ como versionamento ou suporte a sistemas lⅳres. As fer-ramentas lⅳres são quase ineⅺstentes, incompletas e (ou) imaturas; escolha pelo menos dois desses adjetⅳos.
O próprio fluxo de abalho dessas ferramentas é con-aprodutⅳo, forçando tudo a passar por diagramas. Seria
melhor abalhar em texto, e ter diagramas como saídas do processo.
O processo de modelagem de dados começa pela de-finição dum dicionário de dados. Usando-o dicionário de dados, cria-se um DER, que é então aduzido para o sabor SQL do SGBD relevante.
O problema é que diagramas são menos expressⅳos e mais abalhosos que um programa relacional. Então por que não escrever numa linguagem relacional?
Não seria fácil, mas possível, com planejamento e pa-ciência, criar um sistema mais produtⅳo e flexível usando a filosofia Unⅸ: cada tarefa deve ser bem feita por um com-ponente. As interfaces são bem definidas, e cada ferramenta pode ser substituída ou melhorada independentemente.
Começar‐se‐ia com uma gramática, por exemplo Tu-torial D ou D; talvez um derⅳado de Scheme ou ML para maior concisão e poder, como o SchemeQL. Nessa lingua-gem, definiríamos domínios, entidades, regras de negócio &c, enfim o modelo lógico (conceitual). Tendo-a definida, criam-se validadores e compiladores. A saída dos compi-ladores seriam programetas de definição de dados para os SGBDs alvo.
Dessa mesma definição, usaríamos um AutoDoc para gerar diagramas — DER, IDEFX &. Até aí é abalho do Administrador (ou Arquiteto) de Dados. Pode-se criar tam-bém auxílios, como IDEs (um modo Emacs, por exemplo). Findo o abalho do AD, começa o do DBA, que acres-centa à definição da base de dados o físico: índices, parâme-os de armazenamento &c. Não é especialmente difícil, seja numa extensão da nossa linguagem conceitual, seja na lin-guagem do sistema alvo.
Esse sistema seria o começo de coisas ainda melhores. O único SGBDR em produção é o Alphora Dataphor, que tem algo semelhante não para modelagem de dados mas para o sistema todo: escreve-se D e os comandos são executados num SGBD SQL. É proprietário e em MS .Net, mas uma boa idéia. Esta proposta poderia ser um primeiro passo.
