Codd:
- Quais comandos estão relacionados com as regras abaixo:
- 01. Regra de informações: base em tabelas e campos em comum
- Create table
- 02. Regra de acesso garantido: referência a parâmetros específicos
- Todo e qualquer valor atômico possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e o nome do campo/coluna que se deseja acessar.
- Proposta de endereçamento baseado em campos com nomes e tipos bem definidos e um ou alguns obrigatoriamente compondo a chave primária
- 03. Tratamento de valores nulos: valores nulos devem ter tratamento diferente de valores em branco
- Valores nulos devem ser suportados de maneira sistemática e independente do tipo de dados para representar informações inexistentes ou inaplicáveis, lembrando que valor nulo é diferente de valor em branco.
- 04. Catálogo on-line baseado no modelo relacional
- Os metadados devem ser armazenados e gerenciados como dados comuns, ou seja, em tabelas no interior do BD. Esses dados devem estar disponíveis aos usuários autorizados, utilizando a linguagem relacional padrão do BD
- Todo o armazenamento e tratamento de qualquer informação de controle ou configuração deve ser feita em padrões similares à manipulação dos dados comuns
- 05. Sublinguagem Ampla de Dados: Inserção, exclusão e alteração em bloco
- O BD deve dar suporte à configuração do nível de inserções, atualizações e exclusões. Ou seja, a capacidade de manipular um conjunto de dados através de um comando, deve-se estender às operações de Linguagem de Manipulação de Dados (DML) como insert, update e delete.
- Deve propiciar uma linguagem que atenda relações entre tabelas que aceite definição e manipulação de dados
- 06. Linguagem de manipulação de dados abrangentes: permite manipulação de dados por meio de aplicativos
- O BDR pode suportar várias linguagens. No entanto deve suportar uma linguagem declarativa bem definida com suporte para definição de dados, definição de visualização, manipulação de dados (interativa ou por programa), restrições de integridade, autorização e gerenciamento de transações (iniciar, comprometer e desfazer).
- 07. Independência física dos dados: Transparência - Separa as aplicações de usuários da base de dados física
- Aplicativos e recursos ad hoc não são afetados logicamente quando os métodos de acesso ou as estruturas de armazenamento físico são alterados.
- Se houver qualquer modificação quanto ao local de armazenamento físico dos dados ou, ainda, uma mudança qualquer de índices de acesso, o programa de aplicação, logicamente estável, não sofrerá nenhuma paralisação nem precisará de alterações
- 08. Independência lógica dos dados: Transparência do esquema lógico do banco de dados, exemplo, visões
- Aplicativos e recursos ad hoc não são afetados logicamente quando de alterações de estruturas de tabela que preservem os valores originais da tabela (alteração da ordem ou inserção de colunas). Alterações nas relações e nas views causam pouco ou nenhum impacto nas aplicações.
- Os programas de aplicação também permanecem inalterados quando são feitos nas tabelas, mudanças de qualquer tipo para preservar a informação, ou seja, a junção de duas tabelas não afeta os programas, assim como a criação de novos campos e as operações de seleção que dividem uma tabela por linhas ou colunas, desde que se preservem as chaves primárias
- 09. Regra de atualização de visões: aplicativos devem ser capazes de alterar visões
- Qualquer visualização que teoricamente possa ser atualizada deve ser por meio do sistema.
- Pode-se criar visões em cima dos dados que tem as mesmas características de uma tabela comum
- 10. Independência de integridade: devem estar desvinculadas dos aplicativos
- Deve ser possível que todas as restrições de integridade relacional sejam definidas na linguagem relacional e armazenadas no catálogo de sistema, não no nível da aplicação. As aplicações não devem ser afetadas quando ocorrer mudanças nas restrições de integridade.
- Restrições de domínio e regras para validação de alguns ou todos os atributos devem ser armazenáveis no dicionário de dados. Definições, por exemplo, do tipo de caractere de um campo – se numérico, se inteiro ou de tamanho variável – devem estar especificadas nele
- 11. Independência de distribuição: a diversificação dos sistemas não pode afetar a funcionalidade dos aplicativos
- Os usuários finais e aplicativos não conhecem nem são afetados pela localização dos dados (BD Distribuídos VS. BD Locais).
- A sublinguagem deve permitir que os programas de aplicação permaneçam inalterados enquanto os dados são distribuídos, tanto na inicialização de um sistema quanto na ocorrência de uma redistribuição. Se um sistema, por sua implementação, tiver arquivos redistribuídos em meios ou máquinas diferentes, a sublinguagem do SGBD fará o controle e a ligação com os programas de aplicação, sem que seja necessário realizar nenhuma modificação neles
- 12. Regra não subversiva: sistema deve ser capaz de impedir transgressões nos mecanismos de segurança
- Se o sistema dá suporte a acesso de baixo nível aos dados, não deve haver um modo de negligenciar as regras de integridade do BD.
- Se processarmos registro a registro, isso não poderá implicar a burla de restrições específicas dos objetos do banco de dados. Por exemplo, a utilização de uma linguagem de baixo nível não poderá adicionar um registro sem os atributos definidos, no dicionário, como obrigatórios para uma determinada tabela.