Modelagem e Administração de Dados em PostgreSQL

Modelagem e Administração de Dados em

PostgreSQL

Fundamentos e práticas em bases de dados lⅳres

Leandro Guimarães Faria Corcete DUTRA

Conferência PostgreSQL Brasil 

Sumário

I Do que vamos falar



 O problema da gestão de dados 

II O Modelo Relacional



 Componentes 

⒉ Bases de dados e esquemas . . . 

 Restrições de integridade 

⒊ Vantagens . . .  ⒊ Classificação . . . 

 Domínios, operadores e tipos de dados 

 Outras restrições 

III Administrativia



 Glossários 

 Dicionários de tipos de dados 

 Diagramas 

IV Uma proposta: Administração de dados a la Unix



Parte I

Do que vamos falar

Tem bastante gente aqui… talvez muita gente ache que o título foi tão interessante que acabe se decepcionado com a palestra. Vou dar algumas informações sobre o que vou falar, aposto que alguns perderão o interesse.

Modelagem é muito mais que diagramação.

Mapeamento torna a administração praticamente impossível. SQL não é relacional e portanto contém muitos limites arbitrários.

Em primeiro lugar, esta não é uma palestra sobre ORM, diagramas de classe ou entidade-relacionamento (DER). Como costumo dizer na lista de discussões pgbr-geral, entidade-relacionamento é apenas diagrama, apenas um resumo, não captura todo o mo-delo; melhor deⅸar os DERs como meros resumos dum modelo muito mais detalhado, e aliás gerá-los automaticamente.

Em segundo lugar, ORM tem causado muitos danos — tecnologias como Hybernate e Ruby on Rails, embora possam ter seu uso, têm de ser usadas de modo a aceitar o modelo de dados projetado em vez de impô-lo, ou acabam causando grandes desastres não só de modelagem lógica como também desempenho, escalabilidade e compleⅺdade de programação. Tenho algumas cicatrizes de Hybernate para mostrar. E isso, em parte, porque na verdade orientação a objetos é muito 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, no caso, é que ORM não mapeia objetos ao modelo relacional, mas ao SQL — que não é relacional, mas contém muitos limites arbitrá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 mape-amento nem sequer 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?

Isso 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 parecem ser interessantes. Só não podem ser usadas como ponto de partida nas tarefas de modelagem e administração de dados.

Para quem quer dicas, aqui vão algumas:

Diagramadores têm de incluir suporte a um dicionário de dados.

Mapeadores têm de permitir passar do modelo de dados para o de classes.

Tem muita ferramenta de DER ou UML por aí que força o uso de tipos simples dos SGBDs ou do padrão ISO SQL, e muito mapeador que não te permite fazer modelagem de dados propriamente ditas. Escolha suas ferramentas levando isso em conta; se as fer-ramentas 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 ferra-menta permite pelo menos alguns ajustes mas eⅺste toda uma cultura entre os usuários que acaba até escondendo esse conhecimento. E entra-se numa fria.

E 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 introdução ao pro-blema da gestão de dados.

 O problema da gestão de dados

Antes de falarmos de administração de dados, temos de definir sua importância. Vejamos a opinião de duas autoridades, uma moderna, outra ‘antiga’ ― porque, em Informática, o futuro é sigiloso, o passado é obsoleto, e portanto ⅵvemos um eterno presente. E interessantemente, nenhuma das duas é da área de bases de dados, o que creio aumenta a credibilidade de seu uso por nós.

Linus Torvalds dispensaria apresentações, mas se você ⅵveu numa caverna durante os últimos quinze anos, é o autor dum certo sistema operacional relatⅳamente popular()…

I’d also like to point out that unlike every single horror I’ve ever witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I’m a huge proponent of designing your code around the data, rather than the other way around, and I think it’s one of the reasons git has been fairly successful.

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more

important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

So it’s easy enough to just write whatever Java code or something to just access the databases yourself. The object model of git may be smart, but it’s neither proprietary nor patented. I suspect it’s often a lot easier to integrate git into other projects that way, rather than try to actually port the code itself.

…o git é um projeto simples, com estruturas de dados estáveis e razoa-velmente bem documentadas. …sou grande proponente de projetar o código em torno dos dados, em vez do contrário, e creio que é uma das razões para o git ter tido bastante sucesso.

…a diferença entre 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 estru-turas de dados e seus relacionamentos.

— T, Linux.

Já Fred Brooks foi o coordenador do projeto do OS/, sistema operacional que, sob dⅳersos nomes, equipa os mainframes IBM desde o final dos anos ⒈, tendo assim garantido à IBM ⅵnte e cinco anos de domínio do mercado de Informática. Surpreenden-temente, Brooks o considerou um fracasso, e escreveu as lições que tirou deles. Uma das mais importantes():

Show me your flowcharts and conceal your tables, and I shall continue to be mystified.

Show me your tables, and I won’t usually need your flowcharts; they’ll be obⅵous.

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 ‘fracasso’ do OS/ foi um dos muitos eventos que prenunciava a Crise de Software, a percepção de que o progresso da Informática tem seu gargalo na programação. E até hoje, a falta de ênfase em, e organização dos, dados, tem sido um dos componentes dessa crise.

Parte II

O Modelo Relacional

Edgar Frank ‘Ted’ Codd apareceu com a solução: o Modelo Relacional(). Embora o Post-greSQL não seja relacional ― é baseado no SQL, que ⅵola vários pontos fundamentais 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 que fornece os meios para organizar quaisquer dados — inclusⅳe os chamados ‘dados ricos’, ou ‘desestruturados’. Entretanto, os SGBDs atuais são ainda bastante primitⅳos, suportando apenas o SQL; isso, asssociado a uma ênfase cultural geral em tecnologia em vez de conceitos, faz com que muitas equipes se concentrem 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 atributos.

Restrições de integridade de dados ou regras de negócio.

Notem especialmente que o Modelo Relacional não tem nada a ver com os relaci-onamentos dos Diagramas de Entidades e Relacirelaci-onamentos. Mas com as relações, que são subconjuntos do produto cartesiano de n domínios. Vamos voltar a essa idéia quando falarmos de chaves.

Vamos analisá-los, não necessariamente nessa ordem.

. Bases de dados e esquemas

A primeira definição acima, de bases de dados, pode parecer óbⅵa ― mas foi incluída propositalmente, para me 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 so-frem de uma confusão entre usuário, esquema e base de dados. Acabam-se criando 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 permi-tir 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.

Assim, resista à tentação de simplesmente pegar aquele script DDL duma ferramen-tinha web e rodar sem alterações no PostgreSQL… provavelmente ele 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 fragmentaçã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 entre várias bases dispersas.

 Restrições de integridade

É importante expressar todas as regras de negócio como restriçõ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 três cama-das’, 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 apli-caçã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 contraste, o uso de restrições de integridade é declaratⅳo, portanto relatⅳamente simples; centraliza 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 abstrato, permite ao SGBD uma otimização maior do acesso a dados.

. Classificação

As regras de negócio podem ser de quatro tipos diferentes()():

de tipo é a definição do próprio tipo.

de atributo é a definição do tipo dum atributo. 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 três também deⅵam ser óbⅵos. Mas aqui o próprio SQL introduz 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 com-parações com outros 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 subtrair 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

se-rem ú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 recomento 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. Entretanto, 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 ultrapassado. Tal-vez 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(); outros já são tradicionais:

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 {  }  '

) ;

Cobre poucos valores atravé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. Outra possibilidade é o uso de uma linguagem de programação de sistemas, como C ou D. Não vou mostrar como fazê-lo, mas há extensa documentação a respeito(). O problema aí torna-se outro: ter na equipe programadores capacitados para implementar a especificação dos tipos.

Outro 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 outras 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.

 Outras restrições

NOT NULL ajuda a normalização e eⅵta surpresas. Chaves primárias transformam simples tabelas em relvars. Chaves estrangeiras ou popular para a integridade referencial.

CHECK pode ser usado para implementar outras restrições, com limites. Gatilhos embora procedurais tapam alguns buracos.

Algumas restrições ficam de fora.

Gastamos bastante tempo falando dos tipos. Propositalmente, porque são a base de tudo. Mas agora vejamos alguns outros tipos de restrições que ajudam a modelagem.

NOT NULL| deveria ser uma disciplina , incluído no \ lstinline DOMAIN!

sem-pre que possível. A nossa experiência mostra que tabelas contendo muitos NULLs ge-ralmente 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.

Cabe aqui um parênteses: não falamos em normalização porque nosso foco é greSQL e os problemas de normalização em primeiro lugar não são particulares ao Post-greSQL, e em segundo são muito interessantes para uma palestra tão curta.

Chaves são essenciais — não só na sabedoria popular dos Administradores de Bases de Dados, mas também porque simplificam em muito o acesso aos dados, eⅵtando todo tipo de anomalia. Elas praticamente transformam as reles tabelas SQL em boas aproⅺmações às relações que dão nome ao Modelo Relacional.

Quanto aos outros tipos de restrição, temos um certo azar. O PostgreSQL imple-menta 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 dentro da mesma tupla, muito menos para outras relações. O ISO SQL nem suporta restrições de transições(), que têm de ser implementadas proceduralmente ⅵa gatilhos (TRIGGERs).

Parte III

Administrativia

Por esse falso latim, administrativia, quero dizer o fechamento de toda essa técnica nos aspectos 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.

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. Entretanto, 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 trabalho. 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 LA_{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 atributos que ainda não foram dicionarizados.

 Diagramas

AutoDoc é a salvação da lavoura. Sem ele, você perde uma quantidade de dados absurda fazendo o que não é mais que um resumo parcial do modelo de dados: o DER. Com ele, criar DERs passa a ser uma rotina automática, que se coloca no crontab para deⅸar os gerentes felizes.

Se por acaso o AutoDoc não atender, o SQL Fairy pode ajudar bastante. Só se asse-gure de entrar na página deles usando um navegador com a carga de imagens desabilitada: a página inicial do SQL Fairy pode queimar um filme impressionante.

Parte IV

Uma proposta: Administração de dados

a la Unix

Eſta é uma idéia bem incipiente, nascida na lista de discussões da comunidade.

As ferramentas de modelagem fruſtram. As ferramentas ‘profißionais’ eſtão por volta de US4K, chegandof acilmenteaU SK ſe se quer ‘luxos’ (¡não!) como verſionamento ou suporte a sistemas lⅳres. As ferramentas lⅳres são quase ineⅺſtentes, incompletas e (ou) imaturas; eſcolha pelo menos dois deßes adjetⅳos. por aí afora.

O que mais irrita é o próprio fluxo de trabalho deßas ferramentas. Não são nada práticas, forçando tudo a paßar por diagramas. Seria melhor fazer tudo em texto, e ter diagramas como ſaídas do proceßo, não entradas. Tⅳe a idéia maluca de eſcrever uma propoſta a reſpeito, mas queria ſaber ſe alguém já ⅵu algo aßim, ou ſe é abſurdo.

Hoje, numa ferramenta de modelagem de dados, o proceßo começa com a definição de

um dicionário de dados. Uſando eße dicionário de dados, cria-ſe um DER. Eße diagrama é então traduzido para o ſabor SQL do SGBD relevante.

O problema óbⅵo é que diagramas são menos expreßⅳos e mais chatos de fazer que um programa SQL ou (idealmente) relacional. Então por que não eſcrever ISO SQL, Tutorial D ou meſmo D (deſculpem os idealiſtas, também ſou idealiſta mas…)?

Não ſeria fácil, mas creio que ſeria poßível, com planejamento e paciência, criar um ſiſtema muito mais produtⅳo e flexível uſando a filoſofia Unⅸ: cada tarefa deve ſer bem feita por um componente. As interfaces são bem definidas, e cada ferramenta pode ſer ſubſtituída ou melhorada independentemente.

No caſo, começar‐ſe‐ia com uma gramática (por exemplo) Tutorial D ou D⒋ Tal-vez uſar um derⅳado de Scheme ou ML para obter mais concisão e poder programático, creio que já fizeram um SchemeQL ou coiſa aßim. Mas talvez um ſubconjunto do ISO SQL:, deⅸando de lado tudo o que for físico como ponteiros, índices &c; embora eu não creia que o SQL seja ſuficientemente expreßⅳo de todas as ſituações com que um SGBD deva lidar — eſpecificamente, todos os tipos de reſtrições de integridade.

Neßa linguagem, definiríamos domínios, entidades, regras de negócio &c, tudo o que tem a ver com o modelo lógico (conceitual). O básico é ter a linguagem definida; a partir daí criam-ſe validadores e compiladores. O reſultado dos compiladores ſeria um programeta de definição de dados para o⒮ SGBD⒮ alvo de eſcolha, por exemplo noßo caro Dumbo.

Deßa meſma definição, uſaríamos um AutoDoc ou SQL Fairy (cuidado, a página inicial dele cega!) para gerarmos todos os diagramas que quiséßemos: DER, IDEFX &c para benefício dos uſuários. Até aí é trabalho do Adminiſtrador (ou Arquiteto) de Dados. A partir da linguagem, podemos criar todo tipo de auxílios, como IDEs (um modo Emacs, por exemplo).

Até aí foi conceitualmente tranqüilo. O que me preocupa, além da poßibilidade deßa idéia ſer muito pior do que me parece, é o ſegundo paßo: findo o trabalho do AD, começa o do Adminiſtrador de Baſes de Dados, o ſempre popular ABD (ou DBA, para os anglófilos). Ele teria de pegar eßa definição da Baſe de Dados (BD) e acreſcentar tudo o que é físico: índices, parâmetros de armazenamento &c. Não me parece eſpecialmente difícil; ele poderia fazê-lo ſeja numa extensão da noßa linguagem conceitual, ſeja na linguagem do ſiſtema alvo. Ou meſmo através de remendos a aplicar ao modelo conceitual, como ſe faz em programação tradicional meſmo.

Tenho certeza de que há muitos percalços nos quais não penſei, mas queria ſaber de vocês o que acham.

Para concluir, creio que um ſiſtema aßim poderia ſer o começo de coiſas muito me-lhores. Por exemplo, o único quaſe‐SGBDR hoje em produção é o Alphora Dataphor, que tem algo ſemelhante não para modelagem de dados mas para o ſiſtema como um todo: a gente eſcreve D (que é uma D válida) e os comandos são executados num SGBD SQL (infelizmente ainda não ſuporta o Jumbo). É um ſiſtema proprietário e complexo, e ainda por cima em MS .Net, mas é uma boa idéia. Não conſigo imaginar hoje um projeto

dum clone ou equⅳalente lⅳre dele, mas eße noßo ſiſtema eventualmente poderia ſer um primeiro paßo.

Referências

 TORVALDS, L. Lista de discussões git. jul  hmins UTC ⒍ Disponı́vel em: <http://article.gmane.org/gmane.comp.version-control.git/>.

 BROOKS JR, Fred. P. Ten pounds in a five-pound sack: Representation is the essence of programming. In: . The Mythical Man-Month: Essays on software engineering. ª. ed. Reading, MA, EUAN: Addison-Wesley, ⒌ cap. , pp. –⒊ ISBN ⒉

 CODD, Ed. F. A relational model of data for large shared data banks. Communications

of the ACM, ACM, Nova Iorque, NY, EUAN, v. , n. , pp. –, jun . ISSN

-⒉ Disponı́vel em: <http://info.acm.org/classics/nov/toc.html>.

 DATE, Chris. J. What is the relational model?: The relational model defined. In: . Database in Depth: Relational theory for practitioners. Sebastopol, CA, EUAN: O’Reilly, ⒌ (Theory in Practice), cap. , p. ⒋ ISBN ---⒋

 LEFFLER, J. BNF Grammar for ISO/IEC -:: Database Language SQL (SQL--) SQL/Foundation. jul. ⒌ Disponı́vel em: <http://savage.net.au/SQL-/sql--.bnf% -.html>.

 DATE, Chris. J.; DARWEN, H.; LORENTZOS, N. A. A reⅵew of relational concepts: Integrity constraints. In: . Temporal Data and the Relational Model: A detailed investigation into the application of interval and relation theory to the problem of temporal database management. São Francisco, CA, EUAN: Morgan Kaufmann, ⒊ cap. , p. –⒊ ISBN ---⒐

 DATE, Chris. J. Integrity: A constraint classification scheme. In: . An

Introduction to Database Systems. ª. ed. Reading, MA, EUAN: Addison-Wesley, ⒊

(Systems Programming), cap. ⒐ ISBN -⒐

 Data types: Enumerated types. In: POSTGRESQL, C. (Ed.). PostgreSQL .β

Documentation. [s.n.], ⒎ cap. , § ⒎ Disponı́vel em:

<http://www.postgresql.org-/docs/./static/datatype-enum.html>.

 Extending sql: User-defined types. In: POSTGRESQL, C. (Ed.). PostgreSQL .β

Documentation. [s.n.], ⒎ cap. , § ⒒ Disponı́vel em:

<http://www.postgresql.org-/docs/./static/datatype-enum.html>.

 PASCAL, F. The rule of rules: Integrity. In: . Practical Issues in Database

Management: A reference for the thinking practitioner. Reading, MA, EUAN:

Addison-Wesley, . cap. , p. . ISBN ---⒐