República Bolivariana de Venezuela

Universidad Santa María “Núcleo Oriente”

Facultad Ingeniería
Estructura de datos

REGLA DE CODD

Docente: Alumna:
Luis Bucott Barbara Dorantes
28.302.222
 REGLAS DE CODD

¿QUÉ SON ESTAS REGLAS?

Son un sistema de reglas (numeradas del 0 al 12) propuestas acerca del modelo

relacional para las bases de datos, diseñado para definir qué requiere un sistema de

administración de base de datos.

HISTORIA

Edgar Frank "Ted" Codd, Nacido en Inglaterra el 19 de agosto de 1923 fue un

científico informático inglés, Considerado el padre de las bases de datos relacional.

En 1969 Edgar Codd inventó el modelo relacional, el modelo de bases de datos más

usado hoy en día y para muchas personas, el único que conocen. Más tarde IBM

anunció SQL/DS, su primer producto relacional comercial en 1981, seguido de DB2

en 1983. Sin embargo, esta tardanza en adoptar el modelo relacional significó

perder un mercado que tomaron otros. El trabajo inicial de Codd fue publicado en

Communications of the ACM en 1970. Su trabajo sobre normalización de bases de

datos fue publicado como un informe técnico de IBM en 1971. Ocho años más tarde,

en ACM Transactions of Database Systems, publicó varias extensiones al modelo

relacional.

En 1985 postuló una lista de 13 reglas que debía cumplir un producto de bases de

datos para ser llamado relacional. Hace algunas décadas existían bases de datos
que se decían ser relacionales. Sin embargo, carecían de características

consideradas importantes en una base de datos relacional, tal como la

normalización. Fue entonces, cuando Edgar F. Codd propuso una serie de 12 reglas

que contenían las características que debía contener un verdadero Sistema Gestor

de Base de Datos para ser auténticamente relacional. se percató de que existían

bases de datos en el mercado las cuales decían ser relacionales, pero lo único que

hacían era guardar la información en las tablas, sin estar estas tablas literalmente

normalizadas. La medida en que un SGBD puede ser considerado como relacional

está en el número de reglas que cumpla, aunque realmente es complicado llevarlas

a la práctica.

REGLAS

REGLA 0

El sistema debe ser relacional, base de datos y administrador de sistema. Ese

sistema debe utilizar sus facilidades relacionales (exclusivamente) para manejar la

base de datos. Ejemplo Oracle, MySQL, PostgreSQL, entre otros.

REGLA 1 “La regla de la información”

Toda la información en la base de datos es representada unidireccionalmente, por

valores en posiciones de las columnas dentro de filas de tablas. Toda la información

en una base de datos relacional se representa explícitamente en el nivel lógico

exactamente de una manera: con valores en tablas.

 CLIENTES
CEDULA_CLIENTE NOMBRE_CLIENTE APELLIDO_CLIENTE TLFN_CLIENTE
V-2875282 BARBARA DORANTES 0412-9084672
V-9972672 ARIADNA ALVIZU 0424-9004781
V-1827891 SERGIO DA SILVA 0416-9904715

REGLA 2 “La regla del acceso garantizado”

Todos los datos deben ser accesibles sin ambigüedad. Esta regla es esencialmente

una nueva exposición del requisito fundamental para las llaves primarias. Dice que

todo dato (valor atómico) debe ser accesible mediante una combinación de tabla, un

valor de su clave y el nombre de una columna.

MATERIAS

CODIGO_MATERIA NOMBRE_MATERIA CREDITOS_MATERIA

002 Matemáticas 2 6
459 Estructura de datos 5
067 Física 1 3

REGLA 3 “Tratamiento sistemático de valores nulos”

El sistema de gestión de base de datos debe permitir que haya campos nulos. Es

decir, debe soportar la representación y manipulación de información desconocida

y/o no aplicable, independientemente del tipo de dato.

EMPLEADOS
CEDULA_EMPLEADO NOMBRE_EMPLEAD APELLIDO_EMPLEA EMAIL_EMPLEADO
O DO
V-994762 Jesús Dorantes Hola@gmail.com
V-9127858 Garbis Boyadjian null
V-2188758 Ronald Pacheco Rp95@gmail.com
 REGLA 4 “Catálogo dinámico en línea basado en el modelo relacional”

El sistema debe soportar un catálogo en línea, el catálogo relacional debe ser

accesible a los usuarios autorizados. Es decir, los usuarios deben poder tener

acceso a la estructura de la base de datos (catálogo).

MEDICAMENTOS

CODIGO_MEDIC NOMBRE_MEDIC FORMULA_MEDI TIPO

C
8649 KYG Clorfenamina Pastillas

DICCIONARIO DE DATOS

TABLA: MEDICAMENTOS
ATRIBUTO DESCRIPCION TIPO PK NULL
CODIGO_MEDIC Identificador del INT SI NO
medicamento
NOMBRE_MEDI Nombre VARCHAR(15) NO NO
C comercial del
medicamento
FORMULA_MEDI Nombre del VARCHAR(20) NO NO
C ingrediente activo
TIPO Forma física NO NO

REGLA 5 “Sublenguaje de datos completos”

El sistema debe soportar por lo menos un lenguaje relacional que:

 Tenga una sintaxis lineal.

 Puede ser utilizado de manera interactiva.
  Soporte operaciones de definición de datos, operaciones de manipulación de
datos actualización, así como la recuperación, seguridad e integridad y
operaciones de administración de transacciones.

REGLA 6 “Regla de actualización”

Todas las vistas que son teóricamente actualizables deben ser actualizables por el

sistema. Ejemplo: Vistas simples, vistas complejas, vista estándar, vista indizada,

vista con particiones, ETC.

REGLA 7” Inserción, modificación y borrado de tuplas de alto niveL”

Alto nivel de inserción, actualización, y cancelación, el sistema debe soportar

suministrar datos en el mismo tiempo que se inserte, actualiza o esté borrando. Esto

significa que los datos se pueden recuperar de una base de datos relacional en los

sistemas construidos de datos de filas múltiples y/o de tablas múltiples. Es decir,

Todas las operaciones de manipulación de datos deben operar sobre conjuntos de

filas.

NOMBRE APELLINO PATERNO APELLIDO MATERNO

Juan Rosas Gómez
Carlos Duran González
Carla Ponce Peña

NOMBRE APELLIDO PATERNO APELLIDO MATERNO

Juan Rosas Gómez
Carlos Duran González
 REGLA 8“Independencia física de los datos”

Los programas de aplicación y actividades del terminal permanecen inalterados a

nivel lógico cuando quiera que se realicen cambios en las representaciones de

almacenamiento o métodos de acceso. EJEMPLO: Por las necesidades de la base

de datos de la biblioteca municipal, se le desea agregar un campo destinado para

guardar el número de veces que se ha prestado cada libro, este dato, para el

bibliotecario al realizar algún préstamo es irrelevante, ya que esta información

servirá solamente para adquirir más títulos del ejemplar más solicitado, entonces, en

la interfaz de la base de datos, este campo seguirá siendo invisible para el usuario,

es decir, el hecho de que ya se encuentre almacenado no afectará la lógica de la

interfaz.

REGLA 9 “Independencia lógica de los datos”

Los cambios al nivel lógico (tablas, columnas, filas, etc.) no deben requerir un

cambio a una solicitud basada en la estructura. La independencia de datos lógica es

más difícil de lograr que la independencia física de datos.

NOMBRE APELLINO PATERNO APELLIDO MATERNO
Juan Rosas Gómez
Carlos Duran González
Carla Ponce Peña

APELLINO PATERNO NOMBRE APELLIDO MATERNO

Rosas Juan Gómez
Duran Carlos González
Ponce Carla Peña

ALUMNO:158965891 Peña Ponce Carla

 REGLA 10 “Independencia de la integridad”

Las limitaciones de la integridad se deben especificar por separado de los

programas de la aplicación y se almacenan en la base de datos. Debe ser posible

cambiar esas limitaciones sin afectar innecesariamente las aplicaciones existentes.

Ejemplo: Las reglas de integridad combinadas aseguran que haya integridad

referencial:

• Ningún componente de una clave primaria puede tener valores en blanco o nulos

(esta es la norma básica de integridad).

• Para cada valor de clave foránea deberá existir un valor de clave primaria

concordante.

REGLA 11 “Independencia de la distribución”

La distribución de las porciones de la base de datos a las varias localizaciones debe

ser invisible a los usuarios de la base de datos. Los usos existentes deben continuar

funcionando con éxito:

 Cuando una versión distribuida del SGBD se introdujo por primera vez
 cuando se distribuyen los datos existentes se redistribuyen en todo el
sistema.

REGLA 12 “La regla de la no subversión”

 Si el sistema proporciona una interfaz de bajo nivel de registro, a parte de una

interfaz relacional, que esa interfaz de bajo nivel no se pueda utilizar para subvertir

el sistema, por ejemplo: sin pasar por seguridad relacional o limitación de integridad.

Esto es debido a que existen sistemas anteriormente no relacionales que añadieron

una interfaz relacional, pero con la interfaz nativa existe la posibilidad de trabajar no

relacionalmente.