Modelagem e Administração de Dados em PostgreSQL Fundamentos e práticas em bases de dados lⅳres Leandro Guimarães Faria Corcete DUTRA Ⅱ Dia PostgreSQL Distrito Federal Sumário Do que vamos falar O Modelo Relacional Administrativia Administração de dados a la Unix Bibliografia Do que vamos falar 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). Entidaderelacionamento é 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, escalabilidade e compleⅺdade de programação. Tenho cicaizes de Hybernate para mostrar. E isso, em parte, porque orientaçã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 programador 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 começ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é escondendo esse conhecimento. Para entendermos porque um DER não serve como ponto de partida dum esforço sério de modelagem e administraçã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 programador é 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 relacionamentos. T, Linux. Fred Brooks coordenou o projeto OS/, sistema operacional 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 considerou 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 prenunciou 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 Relacional[?]. 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, inclusⅳ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 fornecendo os meios para organizar quaisquer dados inclusⅳ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 mecanismos 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 desempenho, 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 domínio. Tipos de dados ou domínio mais os operadores correspondentes. 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 Relacionamentos, mas com as relações, subconjuntos do produto cartesiano de n domínios. Voltaremos a essa idéia quando falarmos 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 depositozinhos 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 nomes 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çamos 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 provavelmente 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 aplicaçã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 modelagem 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 entendimento muito cru, até errôneo da arquitetura de ês camadas, 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 dados. Em conaste, o uso de restrições de integridade é declaratⅳ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 formalizar as regras de negócio numa linguagem possível de se explicar ao usuário, prevenindo ambigüidades e omissões; e, sendo abs- ato, permite ao SGBD uma otimização maior do acesso a dados... Classificação As regras de negócio podem ser de quao tipos diferentes[?][?]: 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 importante 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 problema é que, em SQL: Tipos de dados simples são muito poucos mesmo para começ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 linguagens 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 precisam 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 recomendo 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 especí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 extensã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 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. 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 importante em modelagem de dados. CREATE TYPE humor AS ENUM ( ' t r i s t e ', ' normal ', ' c o n t e n t e ' ) ; 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 praticamente 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 relaçõ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 fechamento de toda essa técnica nos aspeos gerenciais e de manutençã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.. Outras restrições 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 é suficiente para implementar as regras de negócios, algumas das quais eⅺgem associar ao tipo restrições como CONSTRAINT CHECK, as quais não podem ser declaradas no CREATE TYPE em ouas palavras, o CREATE TYPE do ISO SQL não é uma declaração suficiente. Uma maneira de contornar essa limitação é definir primeiro um TYPE, e por cima dele um DOMAIN. Assim conseguimos uma boa aproⅺmação de um tipo de dados decente. Gastamos bastante tempo falando dos tipos. Propositalmente, porque são a base de tudo. Vejamos alguns ouos tipos de restrições que ajudam a modelagem. 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. Enetanto, não sei de nenhuma que suporte um modelo completo, 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 natural, ambígua mas muito útil. Basta usar um L A TEX ou, na falta, BROffice.org aqui.. Dicionários de tipos de dados Os tipos de dados devem ser todos dicionarizados. Em princí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 fazendo 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. Não seria fácil, mas possível, com planejamento e paciência, criar um sistema mais produtⅳo e flexível usando a filosofia Unⅸ: cada tarefa deve ser bem feita por um componente. 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 Tutorial D ou D; talvez um derⅳado de Scheme ou ML para maior concisão e poder, como o SchemeQL. Nessa linguagem, 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 compiladores 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 também auxílios, como IDEs (um modo Emacs, por exemplo). Findo o abalho do AD, começa o do DBA, que acrescenta à definição da base de dados o físico: índices, parâmeos de armazenamento &c. Não é especialmente difícil, seja numa extensão da nossa linguagem conceitual, seja na linguagem 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. Proposta: Administração de dados a la Unix Esta é uma idéia bem incipiente, nascida na pgbr-geral. As ferramentas de modelagem ustram. As profissionais são cerca de USK, chegando a USK com luxos como versionamento ou suporte a sistemas lⅳres. As ferramentas 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 definiçã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?