Manteniendo la integridad referencial

rodri · #1 (**permalink**) 02/10/2006, 14:15

saludos a todos,

Me encuentro en un dilema con mi equipo, tenemos un modelo de datos que implica algunas tablas con llaves primarias compuestas de 6 a 8 campos. un grupo dice que podríamos reemplazar esta llave primaria compuesta por una llave simple, la misma que sería un identificador único. El otro dice que se debe mantener la llave compuesta para mantener el concepto de integridad referencial.

La segunda posición indica no podríamos controlar las referencias entre tablas dependientes, mientras que el primer grupo dice que sería un manejo de llaves foráneas y no afectaría en nada al modelo de datos.

alguna sugerencia, artículo o algo?

gracias de antemano

MACGREGOR · #2 (**permalink**) 03/10/2006, 04:08

Hola.
Buena pregunta la tuya.

Lo cierto es que las dos opciones que proponen en tu equipo son correctas.

Dependiendo del SGBD te recomendaría una u otra.
Yo suelo trabajar con Oracle y me decanto siempre por la primera opción.
Crear una clave primaria numérica y pensar en la clave compuesta simplemente como una clave alternativa.

Así se gana tiempo a la hora de realizar consultas que crucen esta tabla, especialmente si esa tabla contiene muchos registros (filas).

Piensa que la integridad referencial está asegurada, ya que esa tabla contendrá una clave primaria única, que podrá ser referenciada con claves foráneas (de una manera mucho más sencilla), y cumple las Formas Normales del esquema Relacional.

Para tranquilizar a los partidarios de la clave compuesta deberías asegurar que no se introduce ningún duplicado de la clave alternativa. Esto lo puedes hacer (dependiendo del SGBD) utilizando clausulas como CHECK y en caso de
Oracle existe la restricción UNIQUE que especifica una regla que obliga a un grupo de uno o más campos de una tabla a contener valores únicos.

Tal vez otra solución sería crear un índice único múltiple para los campos de la clave alternativa (la compuesta). Ahunque nunca lo he utilizado para eso.

Espero haber ayudado.
Un saludo.

rodri · #3 (**permalink**) 03/10/2006, 07:19

muchas gracias, es un buen argumento. acá existe el debate por la posibilidad de perder la semántica de la información en la base, es decir, perder el significado de cada tabla al reemplazar las claves compuestas que representan unicidad en cuanto a la información para el propósito de la entidad en cuestrión y la dificultad que significaría unir este modelo con otras bases de datos y por ende con otros sistemas.

gracias nuevamente, saludos

MACGREGOR · #4 (**permalink**) 03/10/2006, 08:42

Hola de nuevo.

Ahunque es un argumento válido para algúnas tablas (la posibilidad de perder la semántica de la información en la base de datos) personalmente creo que eso sucede en una minoría de casos ya que normalmente las tablas cuya clave primaria es compuesta son fruto del proceso de normalización.

Con esto quiero decir que casi siempre son tablas creadas para transformar el esquema conceptual en el esquema lógico.
Suelen ser fruto de la eliminación de relaciones con cardinalidad N-M.

Es decir, acostumbran a ser tablas intermedias que se utilizan para "codificar o representar" una relación entre entidades.
En los casos en que una entidad representa un "objeto físico" del mundo real si debe existir una relación semántica fuerte entre la tabla de DB y la entidad que se desea representar.

Respecto a las dificultades de unir este modelo a otras Bases de Datos y otros sistemas, en realidad no veo ninguna.
Y en cuanto a posibilidades de migración hacia otros sistemas, siempre y cuando sean SGBD's relacionales no habrá ningún problema, ya que en realidad se trata de crear un un esquema Entidad-Relación normalizado.

El único problema es que dependiéndo del SGBD las inserciónes pueden ser más costosas. Si no se puede utilizar algún tipo de cláusula como UNIQUE, de Oracle, se ha de comprovar la existencia de los datos antes de su inserción con algún tipo de programación en lugar de dejar al SGBD que lo haga automáticamente. (perdemos velocidad porque el SGBD optimiza al máximo esta comprovación no porque no se realice!)

En el caso que nuestro SGBD no nos facilite esa posibilidad se debe valorar qué es más molesto para nuestra aplicación.
Un retardo en las inserciones de algunas tablas y un aumento de la velocidad en consultas que impliquen esas tablas o lo contrario.

rodri · #5 (**permalink**) 03/10/2006, 10:00

muchisimas gracias, me aclaraste mucho el panorama. Espero que el equipo tome la decisión mas adecuada a la situación.

saludos cordiales.

MACGREGOR · #6 (**permalink**) 04/10/2006, 03:02

Hola de nuevo.

Tengo que puntualizar una cuestión respecto a la integridad de la DB.
Si se añade una clave numérica en lugar de una compuesta es cierto que
se desnormaliza la Base de Datos.

Si no recuerdo mal se incumple la BCNF 4ª Forma Normal (Boyce Codd Normal Form), pero no porque se pierda la integridad referencial, sino porque existe la posibilidad de añadir duplicidad de datos y por tanto la redundancia de los mismos. (No tiene porqué existir inconsistencia en los datos).

Esto sucede porque el SGBD ya no nos asegura que no puedan existir duplicados en lo que en mi anterior mensaje llamé la clave alternativa. De ahí
mi incapié en que debemos ser nosotros en ese caso los que realicemos esa
comprovación en lugar de dejar que el SGBD la realice de forma automática.

Personalmente creo que este punto no es crítico ya que se és consciente de
que hay que realizar una comprovación antes de cada inserción en ese tipo
de tablas.

Por otro lado también hay que tener en cuenta que los SGBD no implementan
todas las Formas Normales del esquema Relacional de Bases de Datos.

(Vuelvo a hacer referencia a Oracle ya que fué el primer SGBD y en mi opinion personal el más potente).

Por ejemplo, Oracle 8 únicamente implementaba las 3 primeras Formas Normales y en la versión 9i se incluyó la forma normal de Boyce codd, 3ª de Boyce Codd (BCNF) (a efectos practicos se pude considerar la 4ª forma normal).

Teniendo en cuenta estas consideraciones hay que ser conscientes de que no es una buena práctica añadir por sistema una clave primaria numérica e ignorar una clave compuesta.

Se puede tener en cuenta este "truco" si la clave compuesta lo está por muchos campos, especialmente si no són numéricos (en tu caso decías entre 6 y 8 campos) y la tabla contiene muchos registros que van a ser consultados con mucha frecuencia.

No me quedaba tranquilo si no explicaba esto.

Un saludo.