DISEÑO PARA CARDINALIDAD MÍNIMA

DISEÑO PARA CARDINALIDAD MÍNIMA

Es considerado el ultimo de tres pasos necesarios para transformar modelos de datos en diseños de bases de datos, crear un plan para hacer cumplir la cardinalidad puede ser lo más difícil, esto debido a que las relaciones que han requerido entidades secundarias son particularmente problemáticas porque no podemos imponer tales restricciones con estructuras de base de datos. Las relaciones pueden tener una de cuatro cardinalidades mínimas: padre opcional e hijo opcional (OO), padre obligatorio e hijo opcional (MO), padre opcional e hijo obligatorio (OM), o padre obligatorio e hijo obligatorio (MM). En lo que respecta a la aplicación de la cardinalidad mínima, no es necesario realizar ninguna acción para las relaciones OO y no es necesario que las consideremos más. Las tres relaciones restantes plantean restricciones sobre las actividades de inserción, actualización y eliminación.

[pic 1]

DISEÑO DE BASE DE DATOS PARA DATOS DE VARIAS EMPRESAS

[pic 2] 

1. Acciones cuando se requiere padre

Cuando se requiere el padre, debemos asegurarnos de que cada fila de la tabla secundaria tenga un valor válido y no nulo de la clave externa. Para lograr esto, debemos restringir las acciones para actualizar o eliminar la clave principal del padre y las acciones para crear o modificar la clave externa del hijo. Considere primero las acciones sobre los padres.

• Acciones en la fila principal cuando se requiere la principal

Cuando se crea un nuevo padre, no es necesario hacer nada. Ninguna fila secundaria puede depender todavía de la nueva fila. En nuestro ejemplo, podemos crear un nuevo DEPARTAMENTO y no preocuparnos por la aplicación de cardinalidad mínima en EMPLEADO.

• Acciones en la fila secundaria cuando se requiere el padre 

Ahora considere las acciones en la fila secundaria. Si se requiere el padre, cuando se crea una nueva fila secundaria, la nueva fila debe tener un valor de clave externa válido. Cuando creamos un EMPLEADO nuevo, por ejemplo, si se requiere DEPARTMENTO, la nueva fila EMPLEADO debe tener un valor válido para el nombre de Departamento. De lo contrario, el inserto debe rechazarse. Por lo general, existe una política predeterminada para asignar padres a una nueva fila. En nuestro ejemplo, cuando se agrega una nueva fila a EMPLEADO, la política predeterminada podría ser agregar al nuevo empleado al departamento denominado 'Recursos humanos'.

1. Acciones para cuando se requiere niño

Cuando se requiere el hijo, debemos asegurarnos de que haya al menos una fila secundaria para el padre en todo momento. El último hijo no puede dejar a los padres. Por ejemplo, en la relación DEPARTAMENTO-EMPLEADO, si un DEPARTAMENTO requiere un EMPLEADO, entonces el último EMPLEADO no puede dejar el DEPARTAMENTO. Esto tiene ramificaciones en las acciones sobre el niño.

• Acciones en la fila principal para cuando se requiere el hijo

Si se requiere el niño, entonces no podemos crear un nuevo padre sin también crear una relación con un niño. Esto significa que debemos encontrar una fila secundaria existente y cambiar su clave externa para que coincida con la del nuevo padre o debemos crear una nueva fila secundaria al mismo tiempo que se crea el padre. Si no se puede realizar ninguna acción, entonces se debe prohibir la inserción del nuevo padre. Si se requiere el hijo, para modificar la clave principal del padre, también se debe cambiar la clave de al menos un hijo o no se debe permitir la actualización. Esta restricción nunca se aplica a los padres con claves sustitutas porque sus valores nunca cambian. Finalmente, si se requiere el hijo y el padre se elimina, no es necesario realizar ninguna acción. Debido a que es el hijo lo que se requiere, y no el padre, el padre puede desaparecer sin ninguna consecuencia.

• Acciones en la fila secundaria cuando se requiere hijo

Si se requiere el niño, no es necesario realizar ninguna acción especial al insertar un nuevo niño. El niño nace sin influir en ningún padre. Sin embargo, existen restricciones para actualizar la clave externa de un niño requerido. En particular, si el hijo es el último hijo de su padre actual, la actualización no puede ocurrir. Si ocurriera, el padre actual no tendría hijos y eso no está permitido. Por lo tanto, se debe escribir un procedimiento para determinar el número de hijos del padre actual. Si ese número es dos o más, se puede cambiar el valor de la clave externa secundaria. De lo contrario, la actualización está prohibida. Una restricción similar se aplica a la eliminación de los niños obligatorios. Si el hijo es el último hijo del padre, no se permite la eliminación. De lo contrario, el niño puede eliminarse sin restricciones.

1. Implementación de acciones para las relaciones con MO

Como se indicó anteriormente, las relaciones OO no plantean restricciones y no es necesario considerarlas. Necesitamos asegurarnos de que cada hijo tenga un padre y de que las operaciones en las filas padre o hijo nunca creen huérfanos. Resulta que podemos hacer cumplir estas acciones con solo dos limitaciones. Primero, necesitamos definir una restricción de integridad referencial que asegure que cada valor de clave externa tenga una coincidencia en la tabla principal. En segundo lugar, hacemos que la columna de clave externa NO sea NULA.

...