Formación informática

Java | Joomla | MySQL

Fundamentos de Desarrollo de Bases de Datos - Tema 5.4.7: restricciones

Con los elementos anteriores tenemos una primera aproximación a los diagramas E-R, en la que tenemos definidos sus elementos principales. Sin embargo, en el modelo E-R también se pueden definir numerosas restricciones sobre las entidades y las relaciones que sirven para dar mayor significado al diagrama

Las restricciones son propiedades que se asocian a una entidad o relación. Las instancias válidas del tipo de entidad o relación son aquellas en las que se verifique el conjunto de restricciones asociadas.

Las restricciones son parte del diseño de la base de datos al igual que los tipos de entidades o de relaciones. Los S.G.B.D. se encargan de comprobar que la instancia verifica las restricciones más usuales. Por lo tanto, una vez incluida la restricción, el S.G.B.D. no nos permitiría insertar la segunda tupla que incumpla la restricción.

Cardinalidad de un tipo de relación

La cardinalidad de una relación (nivel de instancias) se define como el número de ejemplares de una entidad que pueden relacionarse con un único ejemplar de la otra u otras entidades que participan en la relación. El análisis siempre se refiere a relaciones binarias puesto que se hace a través de la relación entre dos entidades y en ambos sentidos. Normalmente, se utilizan las formas activa y pasiva para leer las cardinalidades de una relación. Un alumno cursa una o varias asignaturas y una asignatura será cursada por uno, varios o muchos alumnos.

 

Se definen tanto las cardinalidades mínimas como máximas, es decir, los valores inferior y superior de valores que pueden tomar las relaciones. Para fijar este dato tendremos que acudir al Universo del Discurso para saber las condiciones que se han puesto para la resolución del problema puesto que esto influirá en la toma de decisiones. Siempre teniendo en cuenta la lógica de funcionamiento de cada negocio o caso particular. Así por ejemplo, una persona será considerada como alumno cuando curse al menos una asignatura y no antes. Es decir, una persona que no curse asignaturas no será considerado alumno.

El análisis de la cardinalidad hay que hacerlo en ambos sentidos de la relación. Se representa en el diagrama entidad-relación mediante dos números separados por una coma que encerramos entre paréntesis (x,y). Este dato se escribe en la entidad contraria a la que estamos analizando. En el modelo extendido, puede incluirse el valor de cardinalidad en la relación, siendo el resultado de juntar ambos valores.

Veamos un ejemplo. Cada persona tiene un único país de nacimiento, es decir, fijada una persona, existe sólo un país dónde ha nacido. Por lo que parece lógico fijar como cardinalidad máxima y mínima 1 para la relación entre las entidades país y persona a través de la relación nacida. En el sentido contrario, sin embargo, fijado un país hay una cantidad no determinada en general de personas nacidas allí, por lo que no ponemos ninguna restricción sobre el tipo de entidad personas. Será de una a muchas.

Tipos de cardinalidad

Existen tres tipos de cardinalidad: de una a muchas, de muchas a muchas, de una a una. La forma más gráfica de entender la cardinalidad es usando la teoría de conjuntos. En el gráfico adjunto puedes ver los tres tipos de cardinalidad.

 

Ejemplo de tipos de cardinalidad

La cardinalidad es una a una cuando solo se relaciona un elemento de una entidad con otro de la otra entidad. Ya hemos visto un ejemplo, una persona solo tendrá un país de nacimiento. Por tanto, la cardinalidad mínima es una y la máxima es una. Se representa como (1, 1). Un ejemplo sencillo es el país de nacimiento con la persona a través de la relación nació.

La cardinalidad es una a muchas cuando un elemento de una entidad se relaciona con muchas de otra. Es el caso, por ejemplo, del alumno que se matricula en varias asignaturas. Se representa cómo (1,m). Por ejemplo, un alumno cursa una o varias asignaturas.

La cardinalidad es muchas a muchas cuando muchos elementos de una entidad se relacionan con muchos elementos de otra. Se representa como (n, m).

Cardinalidad según la teoría de conjuntos en el modelo entidad-relación

Ya veremos las implicaciones que tiene este tipo de cardinalidad cuando pasemos el diagrama entidad-relación al diseño lógico.

Unicidad de entidades: Claves primarias

Las entidades deben poder distinguirse unas de otras a través de los valores de sus atributos. Además, cada tupla tendrá que venir identificada por un valor único que nos permitan recuperarla de  forma rápida y eficiente. Este valor único estará formado por uno o varios atributos que forman la clave principal o primaria de la entidad. Los atributos que forman parte de la clave principal se subrayan.

Como regla general, nos interesa encontrar una clave primaria de atributos lo más pequeño posible que nos permita distinguir unas entidades de otras. Este es debido a que los S.G.B.D. un índice que es reorganizado cada vez que se crea un valor nuevo. Por lo tanto, la sencillez o complejidad de la clave primaria influirá en el rendimiento de la base de datos.

Otra regla general es intentar evitar, en la medida de lo posible, el uso indiscriminado de los campos numéricos auto incrementales como clave primaria de una tupla. En primer lugar la razón es semántica ya que ese número no representa nada en la base de datos y está consumiendo un espacio en disco que puede ser valioso. Además, mediante este tipo de campo no introducimos ninguna restricción real en la introducción de los datos. Un uso razonable de un campo numérico auto incremental sería para almacenar registros de una base de datos de partidos de baloncesto para identificar cada partido con un número.

En los diagramas Entidad-Relación los atributos que forman parte de la clave primaria se representan con sus nombres subrayados con línea continua. Si queremos dejar constancia de aquellos atributos que hayamos considerado como parte de la clave candidata, los subrayaremos con una línea discontinua.

Durante el diseño conceptual podremos definir varias claves candidatas, siempre teniendo en cuenta que deben identificar inequívocamente al registro. Si solo tenemos una clave candidata este se convierte en la clave primaria. Se llama clave primaria a la clave candidata seleccionada por el diseñador para distinguir entre las entidades de cada instancia.

En el caso de existir varias claves candidatas el diseñador debe considerar todas las opciones posibles para tomar la decisión adecuada que dé como resultado una mayor eficiencia de la base de datos.

En nuestro ejemplo, la entidad de alumno solo tiene una única clave candidata {DNI} que será también la clave primaria. Con los profesor ocurre lo mismo, solo tenemos una única clave candidata {DNI} que será también la clave primaria.

En el caso de la entidad asignatura tenemos dos claves candidatas {código} y {Nombre}. Sin embargo elegimos como clave primaria {Código}, porque:

1) Es posible que en el futuro haya dos asignaturas con el mismo Nombre debido, por ejemplo a cambio de planes de estudio. Aunque la asignatura se llame igual parece sensato obligar a que siempre tengan códigos distintos. Así podremos hacer consultas más eficientes y distinguir entre asignaturas de los planes.

2) El código es más fácil de introducir y los índices generados serán más rápidos, pero aún no hemos hablado de índices. Los índices son objetos de cada S.G.B.D. que gestionan la forma en que se recuperan los datos.

En el caso de aulas, tenemos que formar una clave principal formada por sus dos campos {Edificio, numero aula} es la única clave candidata y la clave primaria.

Tema anterior: jerarquías    Tema siguiente: modelo entidad-relación extendido

Escribir un comentario

Aunque los comentarios no expresan la opinión del administrador del sitio web, éste si que tiene una responsabilidad legal sobre lo que aparece. Por lo tanto, habrá una labor de moderación de los mensajes. No se permitirán mensajes ofensivos ni publicidad


Código de seguridad
Refescar

Solicitamos su permiso para obtener datos estadísticos de su navegación en esta web, en cumplimiento del Real Decreto-Ley 13/2012, de 30 de marzo. Si continúa navegando consideramos que acepta el uso de cookies. . Más información