Las 12 reglas de Codd

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Las 12 reglas de Codd por Mind Map: Las 12 reglas de Codd

1. R2: Regla de la garantía de acceso

1.1. Todo valor escalar debería ser accesible a través del nombre de la tabla, el nombre de la columna y la clave primaria de la fila por esto debía existir al menos una clave candidata

2. • R3: Tratamiento sistemático de los valores NULL

2.1. Un RDBMS debe tener soporte para valores NULLdesconocidos o que no apliquen), deben ser independientes del tipo y deben implementarse de una forma diferente a cualquier valor válido de cualquier tipo

3. R4: Catálogo en línea basado en el Modelo Relacional

3.1. Una base de datos debe describirse a sí misma mediante un catálogo basado en el Modelo Relacional, accesible para los usuarios autorizados

4. • R5: Lenguaje de datos completo

4.1. Un RDBMS debe tener un lenguaje relacional (como SQL) que soporte DDL, DML, seguridad y restricciones de integridad, y transacciones (commit, rollback).

5. • R6: Actualización de vistas

5.1. Todas las vistas que sean teóricamente actualizables deben ser actualizables en la práctica (se demostró que esta regla no es decidible: Why Codd's Rule No. 6 Must be Reformulated)

6. • R1: Regla de la información

6.1. Toda la información se debe representar en tablas

7. • R7: INSERT, UPDATE y DELETE de alto nivel

7.1. Un RDBMS debe soportar operaciones INSERT, UPDATE y DELETE de alto nivel (de conjuntos) para cualquier conjunto recuperable de datos

8. • R8: Independencia de la representación física

8.1. Los usuarios y aplicaciones son inmunes a los cambios realizados en la representación física o métodos de acceso a los datos.

9. • R9: Independencia de las modificaciones lógicas

9.1. Los usuarios y aplicaciones son inmunes a los cambios en la estructura lógica de la base (agregado de una relación, agregado de un atributo a una relación, modificación del orden de los atributos de una relación).

10. • R10: Independencia de las restricciones de integridad

10.1. Las restricciones de integridad se deben almacenar en el catálogo, y su modificación no debe afectar a las aplicaciones existentes

11. • R11: Independencia distribuida

11.1. Las aplicaciones deben seguir funcionando bien cuando: (a) se introduce una versión distribuida del DBMS y (b) los datos distribuidos existentes son redistribuidos.

12. • R12: No subversión

12.1. No debe haber otra forma de modificar la base que a través de un lenguaje de múltiples tuplas como SQL (si la base provee cursores no deben poder usarse para evitar la integridad o seguridad).