En dos artículos de 1985, Codd publicó reglas o principios que debe usar un sistema de ges- tión de base de datos para ser considerado “completamente relacional”. (Codd, E. F., “Is Your DBMS Really Relational?”, Computerworld, 14 de octubre de 1985; “Does Your DBMS Run by the Rules?”, Computerworld, 21 de octubre de 1985.) Codd quería mantener la inte- gridad del modelo relacional y dejar en claro que colocar una interfaz de usuario relacional por encima de un sistema que utilizaba algún otro modelo como su modelo de datos básico no era suficiente para hacer verdaderamente relacional un DBMS. Él identificó 12 reglas, junto con una regla abarcadora fundamental que llamó Regla Cero. Las reglas proporcionan un conjunto de estándares para juzgar si un DBMS es completamente relacional. Las reglas, que fueron tema de mucho debate, se resumen a continuación:
■ Regla Cero. Un sistema de gestión de bases de datos relacional debe gestionar sus datos almacenados sólo con el uso de sus capacidades relacionales. Éste es el princi- pio fundamental sobre el que se basan las 12 reglas restantes.
■ Regla 1-Representación de información. Toda información debe representarse, en el nivel lógico, sólo como valores en tablas.
■ Regla 2-Acceso garantizado. Debe ser posible acceder a cualquier ítem de datos en la base de datos al proporcionar su nombre de tabla, nombre de columna y valor de clave primaria.
■ Regla 3-Representación de valores nulos. El sistema debe ser capaz de representar valores nulos en una forma sistemática, sin importar el tipo de datos del ítem. Los valores nulos deben ser distintos de cero o cualquier otro número, y de cadenas vacías.
■ Regla 4-Catálogo relacional. El catálogo del sistema, que contiene la descripción lógica de la base de datos, debe representarse de la misma forma que los datos ordi- narios.
■ Regla 5-Sublenguaje de datos amplio. Sin importar el número de otros lenguajes que soporte, la base de datos debe incluir un lenguaje que permite enunciados expre- sados como cadenas de caracteres para soportar definición de datos, definición de vistas, manipulación de datos, reglas de integridad, autorización de usuario y un método de identificación de unidades para recuperación.
■ Regla 6-Actualización de vistas. Cualquier vista que sea teóricamente actualizable en realidad la puede actualizar el sistema.
■ Regla 7-Operaciones Insert, Delete y Update. Cualquier relación que se pueda manejar como un solo operando para recuperación (retrieval) también se pue- de manejar de esa forma para operaciones de inserción, borrado y actualización. ■ Regla 8-Independencia física de datos. Los programas de aplicación son inmunes a
cambios hechos a representaciones de almacenamiento o métodos de acceso.
■ Regla 9-Independencia lógica de datos. Los cambios efectuados a nivel lógico, como dividir tablas o combinar tablas, que no afectan el contenido de información a nivel lógico, no requieren modificación de aplicaciones.
■ Regla 10-Reglas de integridad. Las restricciones de integridad como la integridad de entidad y la integridad referencial deben especificarse en el sublenguaje de datos y almacenarse en el catálogo. Para expresar estas restricciones no se deben usar enun- ciados de programa de aplicación.
■ Regla 11-Independencia de distribución. El sublenguaje de datos debe ser tal que, si la base de datos se distribuye, los programas de aplicación y los comandos de los usuarios no necesitan cambiar.
■ Regla 12-No subversión. Si el sistema permite un lenguaje que soporte acceso a registro a la vez, cualquier programa que use este tipo de acceso no puede pasar por alto las restricciones de integridad expresadas en el lenguaje de nivel superior.
4.10 Resumen del capítulo
Una relación matemática se define como un subconjunto del producto cartesiano de con- juntos. En términos de base de datos, una relación es cualquier subconjunto del producto cartesiano de los dominios de los atributos. Una relación normalmente se escribe como un conjunto de n-tuplas, en las que cada elemento se elige del dominio adecuado. Las relacio- nes se representan físicamente como tablas, con las filas correspondientes a registros indi- viduales y las columnas a los atributos de la relación. La estructura de la tabla, con especificaciones de dominio y otras restricciones es la intensión de la base de datos, mien- tras que la tabla con todas sus filas escritas es una instancia o extensión de la base de datos. Las propiedades de las relaciones de las bases de datos son: cada celda tiene un solo valor, los nombres de columna son distintos, los valores de una columna vienen todos del mismo dominio, el orden de las filas es irrelevante y no hay filas duplicadas.
El grado de una relación es el número de atributos o columnas. Una relación unaria tiene una columna, una relación binaria tiene dos, una relación ternaria tiene tres y una relación
n-aria tiene n columnas. La cardinalidad de una relación es el número de filas o tuplas. El
grado es una propiedad de la intensión, mientras que la cardinalidad es una propiedad de la extensión de una relación. Una superclave es un conjunto de atributos que identifica de manera única las tuplas de la relación, mientras que una clave candidata es una superclave mínima. Una clave primaria es la clave candidata elegida para usar en la identificación de las tuplas. Una relación siempre debe tener una clave primaria. Una clave externa es un atributo de una relación que no es la clave primaria de dicha relación, pero es la clave pri- maria de alguna relación (usualmente otra), llamada su relación base. La integridad de
entidad es una restricción que establece que ningún atributo de una clave primaria puede
ser nulo. La integridad referencial afirma que los valores de las claves externas deben coin- cidir con los valores de la clave primaria de alguna tupla en la relación base o ser completa- mente nulos. Otras reglas de integridad incluyen restricciones de dominio, restricciones
Los lenguajes de manipulación de datos relacionales pueden ser procedurales o no proce-
durales, gráficos, de cuarta generación o de quinta generación. El álgebra relacional es
un lenguaje procedural formal. Sus operadores incluyen selección, proyección, producto, unión, intersección, diferencia, división y varios tipos de combinaciones, semicombinacio- nes y combinaciones exteriores. El cálculo relacional es un lenguaje no procedural formal que usa predicados. El tipo más común de consulta en el cálculo relacional orientado a
tupla tiene la forma {x|P(x)}, que significa “encontrar el conjunto de todas las variables de
tupla x tales que el predicado P(x) sea verdadero”. Una consulta típica en el cálculo relacio-
nal orientado a dominio tiene la forma {<x1,x2, . . ., xn>| P(x1,x2, . . ., xn)}, que significa
“encontrar el conjunto de todas las variables de dominio para las que el predicado sea ver- dadero”. El álgebra relacional es lógicamente equivalente a un subconjunto seguro de cálcu- lo relacional.
Una vista en el modelo relacional no es un modelo externo completo, sino una tabla vir-
tual. La vista protege la seguridad y permite al diseñador personalizar el modelo de un
usuario. Las vistas se crean dinámicamente cuando el usuario hace una petición de datos. Al convertir un modelo E-R a uno relacional, las entidades fuertes se convierten en tablas que tienen una columna por cada uno de los atributos simples univaluados de la entidad. Los atributos compuestos pueden almacenarse como un solo atributo o representar cada uno de los atributos simples que componen al compuesto mediante una columna, sin repre- sentación del compuesto. Cada atributo multivaluado se remueve y coloca en una tabla separada, junto con la clave primaria de la tabla original. Las tablas para entidades débiles tienen columnas para los atributos clave de la entidad propietaria asociada, así como para los atributos de la entidad débil. Las tablas de relación tienen columnas para los atributos de clave primaria de las entidades relacionadas, más una columna por cada atributo descripti- vo de la relación. Las relaciones muchos a muchos requieren una tabla de relación separada, pero las relaciones uno a uno y uno a muchos se pueden representar mediante claves exter- nas en lugar de mediante tablas. El diseñador puede elegir cualquier método que se ajuste mejor a la aplicación, y negociar flexibilidad por eficiencia. Las relaciones ternarias y n-arias se representan mejor como tablas separadas. Las relaciones recursivas se pueden representar mediante claves externas, siempre que sean uno a uno o uno a muchos, o mediante una tabla de relaciones separada, que se requiere si son relaciones muchos a muchos.
Ejercicios
4.1 Sean S = {rojo, amarillo, verde} y T = {cuadros, tiras, punto}. Encuentre el producto
cartesiano de S y T.
4.2 Sean Q = {Tom, Mary, Jim} y R = {caminar, correr}. Cree una relación con Q y R
como dominios.