Curiosamente, as 12 regras de Codd são 13, já que existe a regra “zero”. Essa regra é um conceito fundamental, que serve de base para todas as demais:
Regra 0: Para qualquer sistema que seja propagandeado ou nomeado como um SGBD relacional, esse sistema deverá gerenciar bancos de dados exclusivamente através de suas capacidades relacionais.
Essa regra é mais geral, então é mais difícil fazer o “teste” para verificar se determinado SGBD a atende ou não. Para isso, há as 12 regras restantes, que são mais específicas:
Regra 1 – A regra da informação
Todas as informações em um BD relacional são apresentadas logicamente de uma só maneira – como valores em uma tabela.
Isso quer dizer que tudo (mas tudo mesmo) que for armazenado em um SGBD relacional vai ficar em tabelas. Até mesmo os metadados do catálogo ficam em tabelas! O catálogo normalmente é implementado como um banco de dados, tendo suas informações distribuídas em linhas e colunas de tabelas como qualquer outro dado.
Por exemplo, geralmente existe nos SGBDs a tabela Colunas, que armazena informações a respeito dos atributos das diversas tabelas do BD. Simplificando, seria algo assim:
| NomeColuna | NomeTabela | TipoDados | PodeNULL |
|---|---|---|---|
| CPF | Funcionário | int | Não |
| Nome | Funcionário | varchar | Não |
| NomeDepartamento | Departamento | Int | Não |
Regra 2 – A regra do acesso garantido
Todo valor armazenado em um BD relacional pode ser acessado por uma combinação de nome de tabela, valor da chave primária e nome da coluna.
Essa é simples! Veja que os dados nos bancos de dados estão representados em linhas de tabelas. Essas linhas são conjuntos de valores, um para cada atributo ou coluna.
Assim, se soubermos o nome da tabela, a identificação única da linha (que é o valor da chave primária) e o nome da coluna da qual estamos buscando o valor, seremos capazes de extrair qualquer dado do nosso banco de dados relacional.
Regra 3 – Tratamento sistemático dos valores nulos
Os valores nulos (que são diferentes da cadeia de caracteres vazia, do valor zero ou de qualquer outro número) são suportados pelo SGBD Relacional para representar informação ausente ou não aplicável e tratados de uma maneira sistemática, independentemente do tipo de dados.
Regra tranquila! É o que já sabemos a respeito dos valores nulos. Um detalhe é que o desenvolvedor do banco de dados deve ser capaz de “dizer” se cada coluna pode permitir valores nulos ou não, independente do tipo de dados utilizado para a coluna (inteiro, cadeia de caracteres, etc.).
Regra 4 – Catálogo online dinâmico baseado no modelo relacional
A descrição do banco de dados está representada, no nível lógico, da mesma maneira que os dados comuns, para que os usuários autorizados possam aplicar a eles a mesma linguagem relacional que utilizam para os dados normais.
Bom, é o que citamos na regra 1. Se o catálogo está armazenado como um banco de dados normal, nós podemos utilizar a linguagem SQL para fazer consultas sobre ele.
Poderíamos criar consultas que extraem diversas informações do catálogo, como por exemplo quais são as colunas de uma determinada tabela, qual é o tipo de dados mais frequente, qual o total de tabelas do modelo e assim sucessivamente.
Regra 5 – Sublinguagem ampla/compreensiva de dados
O BD relacional pode oferecer suporte a múltiplas linguagens e meios de acesso. Contudo, deve existir pelo menos uma linguagem declarativa bem definida com suporte às seguintes operações:
– Definição de dados
– Definição de views
– Manipulação de dados
– Restrições de integridade
– Autorização
– Controle de transações
Essa regra determina que um SGBD pode até ser manipulado por múltiplas linguagens de programação, por meio de interface gráfica ou algum outro modo. Contudo, é necessário que exista pelo menos uma linguagem que englobe todas as funcionalidades listadas acima.
Com o padrão SQL fica fácil atender a essa regra! Essa linguagem, cujo nome é a sigla para Structured Query Language, atende a todos os requisitos descritos.
Regra 6 – Atualização de views
Toda view que é teoricamente atualizável, deve ser também atualizável na prática por meio do sistema.
Essa regra é peculiar. Ela diz mais ou menos o seguinte: se existir uma funcionalidade que permita que o usuário atualize as tabelas que a view consulta se utilizando da própria view, essa funcionalidade deve ser acessível por meio do sistema.
É meio complicada e acredito que tem menos chances de cair na sua prova em relação às demais, então sugiro que você somente memorize o texto da regra (é só uma frase, vai!) se quiser se garantir!
Regra 7 – Inserção, atualização e exclusão de alto nível
A capacidade de gerenciar uma relação base ou uma relação derivada com um só operando se aplica não somente à extração de dados, mas também à inserção, atualização e remoção dos dados.
O texto é um pouco estranho, mas a regra nem tanto. Ela diz que se você é capaz de extrair todos os registros de uma tabela do SGBD fazendo referência apenas ao conjunto dos dados, você também vai poder fazer isso para as operações de inserção, atualização e remoção de dados, sem precisar ir registro a registro.
Vamos explicar de uma forma mais didática. Vamos dizer que um comando SQL, traduzido em linguagem “de gente”, determina o seguinte:
Retorne todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE
Veja que não precisamos dizer ao banco de dados algo como “olhe, traga o funcionário José, a funcionária Maria, o funcionário João, etc.”, não foi? Até porque é improvável que saibamos de cabeça quais são todos os funcionários que moram em Pernambuco…
Dessa maneira, simplesmente “pedimos” ao SGBD que extraia tudo o que existe na tabela e satisfaz à condição de ter o atributo Estado com o valor PE.
Voltando à nossa regra, ela diz o seguinte: se você pode fazer isso com a extração de dados (trabalhar com conjuntos de dados, com a abstração deles), você deve ser capaz de fazer isso também para a inclusão, modificação ou remoção de dados. Assim, você não precisa ir lá no banco de dados e dizer “remova o registro de José, remova o registro de Maria, etc.”. Você pode simplesmente mandar um comando do tipo:
Remova todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE
Ou
Altere os telefones de todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE, adicionando “(81)” no começo
Ou mesmo
Adicione à tabela Funcionários_Pernambuco todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE
Entendido? Vamos para a próxima!
Regra 8 – Independência física de dados
Programas de aplicação e atividades terminais não são logicamente afetadas quando mudanças são feitas na representação de armazenamento ou nos métodos de acesso do banco de dados.
Já falamos sobre isso! A independência física diz que você pode alterar detalhes de implementação físicos dos dados, como a maneira que esses dados estão armazenados no disco ou os métodos de acesso internos do SGBD sem que o modelo lógico ou o conceitual (e, por consequência, os programas de aplicação) sejam afetados.
Regra 9 – Independência lógica de dados
Programas de aplicação e atividades terminais não são logicamente afetadas quando mudanças que preservem as informações são realizadas sobre as tabelas.
Essa regra é similar à anterior, mas diz que as alterações no modelo lógico, desde que preservem as informações presentes nas tabelas, não devem afetar as aplicações ou recursos ad hoc.
Regra 10 – Independência de integridade
As restrições de integridade de um banco de dados relacional devem ser definíveis na linguagem relacional e armazenável no catálogo, não nos programas de aplicação.
Essa regra é interessante. Ela diz que as restrições de integridade (que também vimos nesta aula) devem ser gerenciadas pelo SGBD, não pela aplicação. Por exemplo, não é necessário que o sistema de aplicação que utiliza o banco de dados “se preocupe” em gerenciar se as chaves primárias são realmente únicas ou não. O próprio SGBD que vai levantar um erro toda vez que você tentar duplicá-las ou deixar um valor nulo em alguma delas.
Regra 11 – Independência de distribuição
Um SGBD relacional tem independência de distribuição.
Os bancos de dados distribuídos são aqueles cujos dados armazenados em múltiplos locais, sejam múltiplas máquinas no mesmo local físico ou diferentes servidores espalhados por cidades, estados ou até mesmo países diferentes.
A regra diz, basicamente, que a localização física dos dados não deve ser da preocupação do usuário, ou seja, o usuário não enxerga nem é afetado pela localização dos dados. Ele vai simplesmente trabalhar com os dados e executar comandos SQL da mesma maneira que faria se estivessem todos armazenados no mesmo servidor.
Regra 12 – Regra da não subversão ou não transposição
Se um sistema relacional possui uma linguagem de baixo nível (uma linguagem que permite manipular registros individuais), esse baixo nível não pode ser utilizado para subverter ou contornar as restrições de integridade que foram criadas pela linguagem relacional de alto nível (aquela que permite manipular conjuntos de registros de uma vez).
Pode parecer confuso, mas essa regra foi definida porque o problema descrito era comum à época. O que você deve extrair dela é que, mesmo que haja uma outra linguagem no banco de dados, fora a SQL, essa não pode ser utilizada para infringir alguma das restrições de integridade definidas.
QUESTÃO CERTA: Uma das regras de Codd para o modelo relacional consiste: na independência de distribuição.
QUESTÃO CERTA:
Considere:
I. Regra 1 – Todas as informações são representadas de forma explícita no nível lógico e exatamente em apenas uma forma, por valores em tabelas.
II. Regra 2 – Cada um e qualquer valor atômico (datum) possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.
III. Regra 3 – Valores nulos não devem ser utilizados de forma sistemática, independentemente do tipo de dado ainda que para representar informações inexistentes e informações inaplicáveis.
Das regras de Codd para bancos de dados relacionais, está correto o que consta em: I e II, apenas.
A Regra 3, das 12 regras de Codd, diz que os valores nulos devem ser suportados de forma sistemática e não utilizados de forma sistemática como aparece na afirmativa III.
QUESTÃO CERTA: Dentre as regras de Codd que caracterizam Bancos de Dados Relacionais, a regra da Independência de Integridade estipula que as várias formas de integridade relacional de banco de dados: precisam ser definidas na linguagem relacional e armazenadas dentro do catálogo do sistema ou dicionário de dados, e ser totalmente independentes da lógica dos aplicativos.
As doze regras de Codd são:
-
Conceito de visão multidimensional;
-
Transparência;
-
Acessibilidade;
-
Performance consistente de relatório;
-
Arquitetura cliente/servidor;
-
Dimensionamento genérico;
-
Tratamento dinâmico de matrizes esparsas;
-
Suporte a multiusuários;
-
Operações de cruzamento dimensional irrestritas;
-
Manipulação de dados intuitiva;
-
Relatórios flexíveis;
-
Níveis de dimensões e agregações ilimitados.
QUESTÃO CERTA: As doze regras de Codd propostas em 1985 por Dr. E. F. Codd definem o que é necessário para que um sistema de gerenciamento de banco de dados seja considerado relacional. A regra 12, que trata da não transposição das regras, afirma que: se o sistema suportar acesso de baixo nível aos dados, não deve haver uma maneira de ignorar as regras de integridade do banco de dados.
QUESTÃO CERTA: No contexto de banco de dados relacional, das 12 regras definidas por Codd, aquela que determina que os programas de aplicação e as operações interativas devem permanecer logicamente inalteradas, quaisquer que sejam as trocas efetuadas nas representações de armazenamento e métodos de acesso, chama-se independência: física dos dados.
