?Regra 6 - Todas as “views” que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema.
?Regra 8 - Programas de aplicação permanecem LOGICAMENTE INALTERADOS quando ocorrem mudanças no método de acesso ou na forma de armazenamento físico.((ISOLAMENTO) -MVC BD=model=classe de entidade)
?Regra 10 - As aplicações NAO SAO AFETADAS qdo ocorrem mudanças nas regras de restrições de integridade.
?Regra 12 - Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto.
Regra 6: Regra de atualização das views
A regra diz que todas as views teoricamente possíveis de existir devem ser possíveis de atualizar pelo sistema usuário. A view deveria suportar o mesmo conjunto completo de manipulação de dados disponível ao acesso direto a tabela.
Os dados podem ser apresentados ao sistema usuário em diferentes combinações lógicas chamadas views. Na aparência são tabelas convencionais porém são construídas no momento da consulta. Isto significa que a view é sempre construída já atualizada. Porém, a view pode representar apenas uma parte de alguma tabela sem incluir sua chave primária. Este é o motivo porque é muito difícil permitir update ou delete em view que não viole a integridade. Assim esta regra não é totalmente suportada por nenhuma base de dados.
Regra 8: Independência dos dados físicos
O sistema usuário está isolado do método físico de armazenar e recuperar as informações da base de dados. Podem ocorrer mudanças na arquitetura de suporte tal como hardware, método de armazenamento em disco, etc. sem afetar o sistema usuário que acessa a base de dados. A camada física de implementação é de responsabilidade do sistema gerenciador da base de dados e o sistema usuário não tem nada com ela.
Regra 10: Integridade independente
A linguagem usada na base de dados como SQL por exemplo, deveria suportar todas as restrições para manter a integridade da base de dados. As constraints de integridade deveriam ficar todas em catálogos e não dentro dos programas. As alterações nestas constraints seria feita fora do sistema usuário de modo a simplificar os programas. Porém esta regra não é totalmente implementada pela maioria dos fornecedores de sistemas de bases de dados.
Eles apenas preservam no mínimo 2 constraints através do SQL:
Nenhum componente da primary key pode ser nulo. (regra 3)
Se uma chave estrangeira é definida em uma tabela, qualquer valor dela deve existir como chave primária em outra tabela.
Regra 12: Não subversão
Não pode haver nenhum outro meio de modificar a estrutura da base de dados a não ser usando a linguagem de acesso do tipo SQL.
Na prática isto também é violado porque a maioria dos sistemas gerenciadores de bases de dados possuem ferramentas administrativas que permitem algum tipo de manipulação direta da estrutura dos dados.