Modelo Relacional.

Apresentação em tema: "Modelo Relacional."— Transcrição da apresentação:

1 Modelo Relacional

2 Modelo de Dados Tipos de Estruturas de Dados Operadores Regras de
Integridade

3 Estruturas de Dados do Modelo Relacional
Tipos de Estruturas de Dados RELAÇÕES implementadas na forma de TABELAS Operadores Regras de Integridade

4 Relação (1) Dada uma colecção de conjuntos D1,D2, ,Dn (não necessariamente disjuntos), R é uma relação naqueles conjuntos se fôr constituida por um conjunto de n-uplos ordenados < di1, di2, .....,din> tais que: "i "j dij e [ Dj ou é nulo (null) Cardinalidade ¬¾® Número de n-uplos da relação Domínios de R ¬¾® D1, D2, , Dn

5 Relação (2) Relação Tabela de valores, com algumas características especiais: Os valores de cada coluna têm todos o mesmo domínio (conjunto de valores possíveis) e cada coluna tem um título Não existe a noção de "posição" em relação às colunas, i.e., a ordem das colunas é arbitrária - não existe a noção de "próxima coluna" ou "coluna anterior" Não existe a noção de "número de linha", i.e., a ordem das linhas é arbitrária - não existe a noção de "próxima linha" ou "linha anterior" Podemos alterar a ordem das linhas ou das colunas, sem que isso afecte o conteúdo da informação

6 Exemplo de Relação Empregado
NºEmp Nome Telef Categ Salario Commissão Função 10 Antunes B Analista 20 Bento A Director 30 Correia E Porteiro 40 Dias C Programador 50 Edmundo B Contabilista Domínio Domínio Cadeias de caracteres de comprimento inferior ou igual a 20 Números inteiros positivos

7 Conjunto de Esquemas de Relação
Conceitos Grau da Relação Número de colunas Atributo Coluna Esquema de Relação Definição de uma relação Exemplo: Empregado ( NºEmp, Nome, Telef, Categ, Salario, Commissão, Função ) Esquema Relacional Definição de uma Base de Dados Relacional = Conjunto de Esquemas de Relação

8 Chave Candidata Chave (candidata) de uma Relação Atributo ou conjunto de atributos que identificam cada ocorrência da relação, i.e., não podem existir duas linhas da relação com o mesmo conjunto de valores neste(s) atributo(s) Cliente Ex: num_cli nome_cli morada cidade país tipo_cli n_contrib António Abreu R.Alberto Antunes Andorra Andorra Bernardo Bento R.Beta Brás Bruxelas Belgica Carlos Castro R. Clara Campos Camberra Canadá 20 Manuel Matos R.Marco Moita Maputo Moçamb Chaves

9 Chave Primária Chave Primária de uma Relação De entre as chaves candidatas de uma relação, escolhe-se uma para ser a chave efectiva da mesma (a que for mais útil, no sistema em questão). A essa chave, dá-se o nome de Chave Primária

10 Chave Estrangeira Chave Estrangeira de uma Relação Em algumas relações, temos um atributo (ou conjunto de atributos) cujas ocorrências são referências a uma chave candidata (normalmente a chave primária) de uma outra relação. A esses atributos damos o nome de Chaves Estrangeiras Empregado Categoria n_emp nome cod_categ 01 João ... c3 02 José ... c1 03 Gil ... c2 04 Júlio ... c1 cod_cat design venc_base c1 Director 300 c2 Técnico 200 c3 Admin 120 c4 Auxil 90 Chave Estrangeira

11 Base de Dados Relacional
Conjunto de Relações, cujo conteúdo varia ao longo do tempo

12 Exemplo de Base de Dados Relacional

13 Exemplo Esquema Relacional
Factura ( num_factura, data_emissão, data_pagamento, num_cli ) Cliente ( num_cli, nome_cli, morada, cidade, país, tipo_cli ) Produto ( cod_prod, nome_prod, preço, qtd_existe ) CREATE TABLE Cliente ( num_cli integer(5) PRIMARY KEY, nome_cli char(30) NOT NULL, morada char(40) NOT NULL, cidade char(15) NOT NULL, país char(20) tipo_cli integer(2)); Linha_Factura ( num_factura, cod_prod, quant ) CREATE TABLE Produto ( cod_prod integer(4) PRIMARY KEY, nome_prod char(30) NOT NULL, preço numeric(7,2) NOT NULL, qtd_existe integer(10)); CREATE TABLE Factura ( num_factura integer(5) PRIMARY KEY, data_emissão date NOT NULL, data_pagamento date, num_cli integer(5) REFERENCES Cliente(num_cli)); CREATE TABLE Linha_Factura ( num_factura integer(5) NOT NULL REFERENCES Factura(num_factura), cod_prod integer(4) NOT NULL REFERENCES Produto(cod_prod), quant integer(10), PRIMARY KEY (num_factura, cod_prod));

14 Operadores do Modelo Relacional
sobre RELAÇÕES Tipos de Estruturas de Dados Operadores Regras de Integridade Structured Query Language (SQL) SQL é uma linguagem normalizada para definição, acesso, manipulação e controlo de Bases de Dados Relacionais. Em suma é a tradução para a área das linguagens de programação, que inclui os operadores do modelo relacional. Na maioria dos SGBDR, esta linguagem pode ser utilizada: interactivamente embutida em linguagens de programação Linguagem não procedimental em que se especifica O QUÊ e não COMO Existe uma clara abstracção perante a estrutura física dos dados, isto é, não é necessário especificar caminhos de acesso nem algoritmos de pesquisa física Operações sobre estruturas lógicas As operações efectuam-se sobre conjuntos de dados (tabelas), não sendo necessário (nem possível) manipular linha-a-linha

15 Operações sobre Relações
Operandos Resultado R1 Operador Relacional Rfinal R2 SQL - Manipulação de Dados SELECT Acesso aos dados da BD INSERT Manipulação dos UPDATE dados da BD DELETE A instrução SELECT construir interrogações a serem colocadas directamente à base de dados: SELECT [ DISTINCT ] coluna1, coluna2, coluna3, | * FROM tabela1, tabela2, tabela3, ... O símbolo * é utilizado quando se pretende seleccionar todos os atributos da tabela especificada na cláusula FROM. O DISTINCT é aplicado a todas as colunas especificadas na cláusula SELECT e elimina as repetições existentes. R3 Relações

16 Projecção A partir de UMA relação, obter apenas algumas colunas (com eliminação de repetições) Cliente num_cli nome_cli morada cidade país tipo_cli António Abreu R.Alberto Antunes Andorra Andorra 1 Bernardo Bento R.Beta Brás Bruxelas Bélgica 2 Carlos Castro R. Clara Campos Camberra Canadá 1 20 Manuel Matos R.Marco Moita Maputo Moçamb 2 21 Mario Martins R.Maria Mendes Manga Moçamb 3 Cliente[nome_cli, morada] nome_cli morada António Abreu R.Alberto Antunes Bernardo Bento R.Beta Brás Carlos Castro R. Clara Campos Manuel Matos R.Marco Moita Mario Martins R.Maria Mendes Cliente[País] SELECT nome_cli, morada FROM Cliente; SELECT DISTINCT País País Andorra Bélgica Canadá Moçamb

17 Projecção Seja R (X,Y) com X = A1, A2, , Ak e Y = Ak+1, , An A projecção de R sobre os atributos X é representada pelo conjunto R[X] = { x: $ y : (x,y) existe em R (X,Y) }

18 Restrição ou Selecção A partir de UMA relação, obter apenas algumas linhas (eliminando as restantes), utilizando para isso uma qualquer condição booleana SELECT * FROM Linha_Factura WHERE num_fact=2;

19 Restrição ou Selecção Seja R (A1, A2, , An) e P uma expressão lógica definida sobre D1 * D2 * * Dn, com Di domínio de Ai. A restrição de R a respeito de P é representada pelo conjunto R[P] = { x: x em R e P(x) é verdadeira }

20 "q" poderá ser um dos seguintes operadores:
O Operador "q " "q" poderá ser um dos seguintes operadores: 1. Igualdade 2. Desigualdade 3. Menor que 4. Menor ou igual que 5. Maior que 6. Maior ou igual que Predicados O predicado de comparação é, dos predicados do SQL, o que melhor se assemelha a um operador q. Um predicado de comparação (WHERE NOME_EMP = ´Manuel Silva´) Outros predicados são: Um predicado de BETWEEN (WHERE COD_EMP BETWEEN 1 AND 5) Um predicado de LIKE (WHERE NOME_EMP LIKE ' M%') Um teste de valor nulo (WHERE COMISSÃO IS NULL) Um predicado de IN (WHERE COD_CAT IN (1,2))

21 Restrição ou Selecção (cont)
Poderemos também restringir o conjunto das linhas que queremos obter, utilizando os operadores lógicos ("e", "ou", "negação" ) sobre duas ou mais condições SELECT [ DISTINCT ] coluna, ...| * FROM tabela, [tabela,....] WHERE condição-de-pesquisa Uma condição-de-pesquisa é basicamente uma colecção de predicados, combinados através dos operadores booleanos AND, OR, NOT e parêntesis. SELECT * FROM Linha_Factura WHERE num_fact=2 AND quant>= 20;

22 Produto Cartesiano "Combinação de TODAS as linhas de uma tabela com TODAS as linhas da outra" Referenciação de Colunas: Caso o nome de uma coluna seja igual em várias tabelas então é obrigatório colocar Nome_Tabela.Nome_Coluna em qualquer sítio da cláusula SELECT. Como disciplina própria é aconselhável, qualquer que seja a dimensão e complexidade da query, prefixar toda e qualquer coluna com o nome da tabela respectiva. O produto cartesiano quando transposto para SQL, fica: SELECT * FROM Cliente, Produto;

23 Junção Natural ou "Equi-Join"
A partir de duas tabelas, obter uma terceira, concatenando as colunas e restringindo apenas às linhas com o mesmo valor em algum atributo SELECT * FROM Linha_Factura F_P, Produto P WHERE F_P.cod_prod=P.cod_prod; Para se conseguir efectuar uma junção parte-se de um produto cartesiano entre duas tabelas e restringe-se a selecção às linhas que verificam a igualdade nas colunas comparadas. Em SQL92 já existe a operação INNER JOIN, e a query poderia ser escrita: SELECT * FROM Linha_Factura AS LF INNER JOIN Produto AS P ON LF.cod_prod=P.cod_prod; Aliases (Correlation Names) A utilização de “aliases” (no exemplo F_P e P para as tabelas Linha_Factura e Produto) é aconselhável sempre que o nome das tabelas é extenso. Existe, porém uma situação em que é obrigatória a sua utilização, quando pretendemos usar a mesma tabela com significados distintos. Ex: Pretende-se o nome de cada empregado e o nome do respectivo chefe: SELECT E.nome, CH.nome FROM empregado E, empregado CH WHERE E.cod_emp_chefe = CH.cod_emp

24 Junção Natural ou "Equi-Join"
Seja R1 (A, B1) e R2 (B2,C) duas relações e B1 e B2 conjuntos de atributos compatíveis. A Junção Natural das relações R1 e R2 sobre os conjuntos de atributos B1 e B2 é representada pelo conjunto R1[B1 = B2] R2 = { (a, b1, c) : (a, b1) em R1 e (b2, c) em R2 e b1 = b2 } Seja X = {X1,..... Xn} com DXi domínio de Xi e Y = {Y1,...,Yn} com domínio DYj domínio de Yj, conjuntos de atributos. X e Y denominam-se conjuntos de atributos compatíveis se DXi = DYi

25 q - Junção Podemos extender a noção de Junção, de forma que a condição de restrição das linhas não seja apenas a igualdade, mas uma qualquer operação "q" SELECT * FROM Linha_Factura, Produto WHERE Linha_Factura.cod_prod<Produto.cod_prod; Em SQL92: SELECT * FROM Linha_Factura AS LF INNER JOIN Produto AS P ON LF.cod_prod< P.cod_prod;

26 q - Junção Seja R1 (A, B1) e R2 (B2,C) duas relações, B1 e B2 conjuntos de atributos compatíveis e Q um operador binário { =, <,<=,<> ,>, >=} aplicável aos domínios de B1 e B2. A operação Q-junção das relações R1 e R2 sobre os conjuntos de atributos B1 e B2 é representada pelo conjunto R1[B1 Q B2] R2 = { (a, b1,b2, c) : (a, b1) em R1 e (b2, c) em R2 e b1 Q b2 }

27 Divisão Relacional Forneceu Prods-especiais cod_fornec cod_prod f1 p1 f1 p2 f1 p3 f1 p4 f1 p5 f1 p6 f2 p1 f2 p2 f3 p2 f4 p2 f4 p4 f4 p5 ÷ cod_prod p2 p4 = Resultado f1 f4 Fornecedores que forneceram TODOS os produtos da tabela "Prods-especiais" Resultado ¬ Forneceu[ cod_fornec, cod_prod / cod_prod ]Prods-especiais Notação ®

28 Divisão Relacional Seja R1 (A, B) e R2 (C) duas relações e B e C conjuntos de atributos compatíveis A Divisão de R1 por R2 sobre B e C é representada pelo conjunto R1[B : C] R2 = R3 (A) : r3 (a) e R3 (A) se "c e R2 (C), R1 (a,c) e R1 }

29 União União de duas relações é a relação composta por todas as linhas de ambas (com eliminação de repetições ) Clientes Nome Morada Alberto Alves Alameda Carlos Odorico Campo d´Ourique Alves Bernardo Av. Berna Fernando Fontes Figueira da Foz Clientes - UNION - Fornecedores Nome Morada Alberto Alves Alameda Carlos Odorico Campo d´Ourique Alves Bernardo Av. Berna Fernando Fontes Figueira da Foz Manuel Mendes Madeira Júlio Jaime Jamaica Rui Rodrigues Ribeirinha Fornecedores Nome Morada Manuel Mendes Madeira Carlos Odorico Campo d´Ourique Júlio Jaime Jamaica Alves Bernardo Av. Berna Rui Rodrigues Ribeirinha SELECT Nome, Morada FROM Clientes UNION FROM Fornecedores; Os clientes e os Fornecedores Nota: as relações terão que ser compatíveis

30 Nota: as relações terão que ser compatíveis
Intersecção Intersecção de duas relações é a relação composta pelas linhas que pertencem a ambas as relações Clientes Fornecedores Nome Morada Alberto Alves Alameda Carlos Odorico Campo d´Ourique Alves Bernardo Av. Berna Fernando Fontes Figueira da Foz Nome Morada Manuel Mendes Madeira Carlos Odorico Campo d´Ourique Júlio Jaime Jamaica Alves Bernardo Av. Berna Rui Rodrigues Ribeirinha Clientes - Intersecção - Fornecedores SELECT Nome, Morada FROM Clientes INTERSECT FROM Fornecedores; Ainda não disponível em MySQL Os clientes que também são fornecedores Nome Morada Carlos Odorico Campo d´Ourique Alves Bernardo Av. Berna Nota: as relações terão que ser compatíveis

31 Nota: as relações terão que ser compatíveis
Diferença Diferença de duas relações é a relação composta pelas linhas que pertencem à primeira e NÃO pertencem à segunda Clientes Fornecedores Nome Morada Alberto Alves Alameda Carlos Odorico Campo d´Ourique Alves Bernardo Av. Berna Fernando Fontes Figueira da Foz Nome Morada Manuel Mendes Madeira Carlos Odorico Campo d´Ourique Júlio Jaime Jamaica Alves Bernardo Av. Berna Rui Rodrigues Ribeirinha Clientes — Fornecedores SELECT Nome, Morada FROM Clientes EXCEPT FROM Fornecedores; Ainda não disponível em MySQL Os clientes que não são fornecedores Nome Morada Alberto Alves Alameda Fernando Fontes Figueira da Foz Nota: as relações terão que ser compatíveis

32 O Conceito de valor "NULL"
Numa relação podemos, em determinado momento, ter um atributo cujo valor é desconhecido ou não aplicável no momento. Diz-se então que esse elemento tem o valor NULL Características dos valores NULL's: Independente do domínio - inteiro, real, caracter, data, etc. Não comparáveis entre si, i.e., nunca poderemos dizer que um valor NULL é igual a outro valor NULL Recordando, o predicado que permite verificar se um determinado valor numa coluna se encontra a NULL é: IS NULL Ex: Pretende-se saber quais os clientes que não possuem morada na nossa Base de Dados: SELECT Nome FROM Cliente WHERE Morada IS NULL A cláusula ORDER BY é usada para ordenar os dados referentes a uma ou mais colunas. É a última cláusula a ser especificada SELECT [ DISTINCT ] coluna, ... | * FROM tabela WHERE condição ORDER BY coluna [ASC | DESC ], ... Agora a interrogação anterior, só com os nomes a serem listados por ordem alfabética inversa: ORDER BY Nome DESC

33 Outer Equi-Join S ( A B ) Considere as seguintes relações : T ( C D )
-- -- a2 b2 b2 d1 Junção Natural a2 b2 b2 d2 ou Outer Equi -Join Em SQL2 escrever-se: SELECT * FROM S outer join T on S.B =T.C ; . Inner Equi -Join a3 b3 b3 d3 -- -- b4 d4 Valores Inexistentes (NULL)

34 "Left " e "Right" Outer Join a1 b1 -- -- a2 b2 b2 d1 Left Outer Join
— -- b4 d4 S [ b =\ C ] T ( A B C D ) S [ b /= C ] T ( A B C D ) Outer Join SQL2 SELECT * FROM S left outer join T on S.B =T.C ; FROM S right outer join T on S.B =T.C ; Em SQL.92 será : SELECT * FROM empregado RIGHT OUTER JOIN departamento on empregado.cod_dept = departamento.cod_dept S [ b /=\ C ] T ( A B C D )

35 Outer q - Join Podemos extender o conceito de Outer-Join para os casos em que a comparação é outra além da simples igualdade Em SQL92: SELECT * FROM S left outer join T on S.B <T.C ;

36 Resumo das Operações Relacionais abordadas
Selecção Projecção Produto Junção inner e outer * x União Intersecção Diferença R R R S S S

37 Tipos de Estruturas de Dados
Regras de Integridade Tipos de Estruturas de Dados Operadores Regras de Integridade Entity Domain Column Referencial User Defined

38 Integridade de Entidades
Nenhuma componente de uma chave primária de uma relação poderá em algum momento ter valor NULL

39 Integridade de Domínio
Cada coluna de cada relação tem um domínio, isto é, um conjunto (limitado ou não) de valores possíveis. Em todas as linhas dessa relação, o valor dessa coluna terá que pertencer SEMPRE a esse domínio. Ex (SQL2): Create Domain D_Contribuinte as number(9); Não disponível em MySQL

40 Integridade de Colunas
A integridade de colunas permite definir, para cada coluna, o conjunto dos valores possíveis. Ex: empregado( n-emp, nome, morada, salário, diuturnidades , ...) n-emp -> Positivo salário -> Positivo diuturnidades -> 0 e 5 ® Š Domínio : Inteiros Regras de Integridade de colunas :

41 Integridade Referencial
Numa relação, qualquer ocorrência de uma chave estrangeira deverá obrigatoriamente existir como ocorrência de uma chave candidata (normalmente a primária) da relação à qual se refere (ou ser nula no caso de não obrigatoriedade)

42 Integridade Definida pelo Utilizador
Qualquer outra regra a que as ocorrências de uma determinada base de dados deverão obedecer. Estão intimamente ligadas a regras do negócio. Estas restrições definidas pelo utilizador, sendo independentes do modelo de dados usado, são conhecidas como “regras de integridade explícitas” (ao contrário das implícitas, próprias de cada modelo de dados). São classificadas em dois tipos: restrições estáticas restrições dinâmicas

43 Integridade Definida pelo Utilizador
Restrições estáticas Correspondem a restrições que asseguram a integridade dos vários estados pelos quais passa a BD. Exemplo: O preço de venda de um determinado artigo não pode ser inferior ao valor de compra desse artigo acrescido de 3%.

44 Integridade Definida pelo Utilizador
Restrições dinâmicas Correspondem a restrições que asseguram que a transição entre dois estados é válida e preserva a integridade da BD face às regras de negócio. Exemplo: O estado civil de um indivíduo, não pode assumir o valor de solteiro, após ter sido divorciado, viúvo ou casado. Os dois tipos de restrições de integridade descritos têm uma fraca correspondência em termos de suportepor parte dos SGBD’s actuais. As restrições que mais facilmente se implementam são as de natureza estática (o uso de CHECK permite resolver a maior parte destas restrições). Já as restrições de natureza dinâmica só conseguem ser implementadas utilizando stored procedures e triggers.

45 O Que é realmente um SGBD relacional?
Segundo Codd (*) um SGBD pode ser considerado minimamente relacional se satisfaz as seguintes condições: Estrutura: Ao utilizador são apresentadas apenas tabelas e nada mais do que tabelas Manipulação: Operações de restrição, projecção e junção natural, sem necessidade de definição de caminhos físicos de acesso que suportem essas operações (*) E.F. Codd."Relational Database: A Practical Foundation for Produtivity." CACM 25, Nº 2 (Fevereiro 1982)

46 O que é realmente um SGBD relacional?
Sistemas Relacionais E M E M E M E M I I I I Minimamente Relacional Completamente Relacional Tabular Relacional (*) C.J.Date. An Introduction to Database Systems . Reading, Mass: Addison Wesley, 5ª ed. (1990)

47 O que é realmente um SGBD relacional?
A partir da definição de Codd, Chris Date(*) sugere uma classificação para SGBD relacionais: Tabular: Suporta a estrutura tabular, mas não os operadores relacionais Minimamente relacional: Suporta a estrutura tabular e os operadores de restrição, projecção e junção (apenas estes) Relacional: Suporta a estrutura tabular e todos os operadores da algebra relacional Completamente Relacional: Suporta todos os aspectos do modelo relacional (estrutura tabular e domínios, todos os operadores da algebra relacional e a integridade de entidades e referencial) (*) C.J.Date. An Introduction to Database Systems . Reading, Mass: Addison Wesley, 5ª ed. (1990)

48 Em que medida é um SGBD Relacional
Segundo um artigo posterior de Codd(*) um SGBD é completamente relacional (fully relational) se gere a base de dados utilizando apenas e só as possibilidades oferecidas pelo modelo relacional. Assim sendo tem de satisfazer as seguintes 12 regras 1. Informação 2. Garantia de acesso 3. Tratamento sistemático de valores nulos 4. Catálogo on-line e activo baseado no modelo relacional 5. Sublinguagem de manipulação de dados compreensível 6. Actualização de views (continua) 1. Informação Toda a informação da bd relacional deve ser representada de uma única forma: valores em tabelas 2. Garantia de acesso Qualquer valor de uma bd relacional deve poder ser endereçável apenas através de nome da tabela, nome da coluna, chave primária da linha 3. Tratamento sistemático de valores nulos Um SGBD relacional tem de suportar a representação de "informação desconhecida ou inexistente" de forma sistemática e independente do tipo de dados 4. Catálogo on-line e activo baseado no modelo relacional O sistema deve suportar um catálogo on-line e relacional, acessível por utilizadores autorizados, através da linguagem normal de interrogação 5. Sublinguagem de manipulação de dados compreensível O sistema deve suportar, pelo menos uma linguagem relacional que: (1) tenha uma sintaxe simples, (2)possa ser usada quer interactivamente, quer embebida em programas de aplicação, (3) suporte as operações de definição de dados (incluindo views), de manipulação (interrogação e actualização), regras de integridade e segurança e gestão de transacções (begin, commit, rollback) 6. Actualização de views Todas as views "teoricamente actualizáveis" devem poder ser actualizáveis pelo sistema (*) E.F. Codd. "Is Your DBMS Really Relational?." (Computerworld, Outubro 14, 1985); "Does Your DBMS Run by the Rules." (Computerworld, Outubro 21, 1985)

49 Em que medida é um SGBD Relacional
(continuação) 7. Insert, Update e Delete de alto nível 8. Independencia física dos dados 9. Independencia lógica dos dados 10. Independencia da Integridade 11. Independência da distribuição 12. Não subversão 7. Insert, Update e Delete de alto nível O sistema deve suportar as operações relacionais de insert, update e delete 8. Independencia física dos dados 9. Independencia lógica dos dados 10. Independencia da Integridade As regras de integridade devem ser definidas separadamente dos programas de aplicação e guardadas no catálogo. Devem poder ser modificadas sem que isso afecte esses mesmos programas 11. Independência da distribuição As aplicações existentes devem manter-se inalteradas quando (1) uma primeira versão distribuida do SGBD é introduzida, (2) os dados são redistribuidos 12. Não subversão Se o SGBD disponibilizar também uma linguagem de baixo nível (manipulação de um registo de cada vez), não será permitido que essa linguagem seja utilizada para subverter a base de dados (sobrepondo-se às regras de integridade e/ou segurança definidas na linguagem de alto nível) (*) E.F. Codd. "Is Your DBMS Really Relational?." (Computerworld, Outubro 14, 1985); "Does Your DBMS Run by the Rules." (Computerworld, Outubro 21, 1985)