Ahora que ya conocemos la evolución histórica de las bases de datos y los diferentes tipos que hay gracias a la anterior entrada, es hora de centrarnos en el modelo Entidad-Relación, el primer esquema que realizaremos (o que realizarán los analistas) a la hora de crear una nueva base de datos. Pero antes, veamos las reglas que Edgar Codd publicó.
Las 12+1 reglas de Codd
Como mencionamos en la introducción a las bases de datos, en 1985 Edgar Codd publicó doce reglas (más una 0 inicial, de ahí las 12+1) para evaluar si un sistema de gestión de bases de datos puede considerarse relacional. Cabe decir que es muy difícil cumplirlas todas, pero cuantas más cumpla un SGBD, más relacional será. Veámoslas a continuación.
Regla 0 o Regla fundamental Cualquier sistema que se defina como un sistema de gestión de base de datos relacional debe gestionar las bases de datos exclusivamente mediante sus capacidades relacionales.
Regla 1 o Regla de la información Toda la información de una base de datos relacional se representa de forma explícita en el nivel lógico de una manera: con valores en tablas.
Regla 2 o Regla del acceso garantizado Se garantiza que cada valor atómico (cada uno de los datos) son accesibles a nivel lógico, combinando el nombre de la tabla, el valor de clave primaria y nombre de la columna.
Regla 3 o Regla del tratamiento sistemático de valores nulos En una base de datos relacional se permiten los valores nulos (distinto de cadena vacía, campos blancos, ceros o cualquier otro número) para representar la información desconocida o inaplicable de manera sistemática.
Regla 4 o Regla del catálogo dinámico en línea basado en el modelo relacional La descripción de la base de datos se representa de la misma manera que los datos comunes, a nivel lógico.
Regla 5 o Regla del sublenguaje de datos completo Un sistema relacional debe permitir varios lenguajes y varios modos de uso final (como rellenar un formulario), pero debe haber al menos un lenguaje cuyas declaraciones se puedan expresar mediante una sintaxis bien definida, como cadenas de caracteres y que respalde de forma integral la definición de datos, de vistas, manipulación de datos, restricciones de integridad y límites de transacción.
Regla 6 o Regla de actualización de vistas Todas las vistas que son teóricamente actualizables lo son también por el sistema.
Regla 7 o Regla de inserción, actualización y borrado de alto nivel El sistema debe permitir la manipulación de alto nivel en los datos, es decir, sobre conjuntos de tuplas. Esto significa que no solo se debe poder recuperar datos, si no que también pueden realizarse inserciones, actualizaciones y borrados sobre varias tuplas y/o tablas al mismo tiempo.
Regla 8 o Regla de independencia física de los datos Los programas de aplicación y terminal permanecen inalterados a nivel lógico cuando se hacen cambios en las representaciones de almacenamiento o métodos de acceso.
Regla 9 o Regla de independencia lógica de los datos Los programas de aplicación y terminal permanecen inalterados a nivel lógico cuando se hacen cambios en las tablas base que preservan la información. Esta es más difícil de lograr que la independencia física.
Regla 10 o Regla de independencia de la integridad Las restricciones de integridad se deben definir por separado de los programas de aplicación y se deben almacenar en el catálogo.
Regla 11 o Regla de independencia de la distribución El usuario debe tener la impresión de que los datos se encuentran en un solo lugar, no distribuido en varias ubicaciones.
Regla 12 o Regla de la no subversión Si el sistema tiene un lenguaje de bajo nivel no puede subvertir o eludir reglas y restricciones de integridad expresadas en el lenguaje relacional de nivel superior.
Elementos del modelo Entidad-Relación
En la primera versión propuesta por el doctor Peter Pin-Shan Chen en 1976, solo se tenían en cuenta tres elementos o constructores del modelo: entidades, atributos y relaciones.
Entidad
Es cualquier objeto del que se desea almacenar información de interés para la BD. Por ejemplo: si estamos construyendo la base de datos de una universidad, tendremos la entidades ALUMNO, PROFESOR, ASIGNATURA, etc.
Se representan mediante un rectángulo que encierra el nombre de la misma en mayúsculas.
Atributos
Son las propiedades, características o datos que posee una entidad y de las que se desea guardar información. Por ejemplo, para la entidad EMPLEADO de una empresa, nos resultará útil considerar los atributos NIF, Nombre, Dirección y Puesto.
Para su representación gráficas se suelen usar dos vertientes: una elipse horizontal con el nombre del atributo en el interior y unida por una línea recta a la entidad o, la más utilizada, círculos en blanco también unidos mediante líneas.
En el Modelo E-R se usan varios tipos de atributos: simples o compuestos, monovaluados o multivaluados y almacenados o derivados. Veámoslos.
Atributos simples o compuestos
Los atributos simples o atómicos son aquellos que no se pueden dividir, mientras que los compuestos se pueden dividir en componentes más pequeños.
Por ejemplo, el atributo Nombre Completo se puede subdividir en los atributos Nombre, Apellido 1 y Apellido 2.
Para elegir entre uno y otro, prestaremos atención a las posibles situaciones que se nos vayan a plantear, ya que si solo se va a hacer referencia al atributo como un todo, no hará falta dividirlo en subatributos y el atributo se definirá como atributo simple.
Atributos monovaluados o multivaluados
Los atributos monovaluados son aquellos que solo pueden tener un valor para cada entidad en particular, mientras que los multivaluados puede tener varios valores.
Por ejemplo, pensemos en el atributo Sexo de la entidad ALUMNO, donde solo puede tener un único valor. Sin embargo, el atributo Titulación Universitaria de la entidad EMPLEADO puede tener tantos valores como carreras haya cursado dicho empleado.
Los atributos multivaluados suelen representarse con una elipse de doble contorno.
Atributos almacenados o derivados
Los atributos almacenados son aquellos que se registran explícitamente ya que no pueden inferirse de otros atributos, mientras que los derivados pueden deducirse a partir de otro u otros atributos, de forma que su registro puede automatizarse.
Por ejemplo, el atributo Fecha de nacimiento de la entidad ALUMNO debe registrarse tal cual, mientras que el atributo Edad puede derivarse realizando un simple cálculo: diferencia entre fecha de nacimiento y fecha actual.
Estos atributos suelen representarse mediante un óvalo punteado.
Atributos nulos
Un detalle a tener en cuenta es que puede haber atributos cuyo valor sea nulo. Por ejemplo, es posible que la entidad ALUMNO tenga un atributo llamado Teléfono fijo, pero que una instancia de dicha entidad no tenga fijo en casa (algo cada vez más común si lo pensamos) o, simplemente, cuando rellenó la matrícula no lo apuntó. En los diagramas E-R, se representan con un asterisco al lado del nombre.
En resumidas cuentas, usamos el valor NULO para un atributo cuando:
a) El atributo no es aplicable en un caso concreto
b) El valor del atributo es aplicable y existe, pero se desconoce
c) El valor del atributo es aplicable pero no existe
Relaciones
También conocidas como interrelaciones o vínculos, representan asociaciones entre dos o más entidades que implican una conexión entre ellas. Por tanto, su existencia está ligada a la de las entidades: no puede haber relaciones de forma independiente de las entidades.
En los diagramas E-R, las relaciones se representan como rombos conectados mediante líneas rectas con las entidades participantes y poseen las tres características siguientes
Nombre de la relación Identifica la relación de forma única en toda la base de datos. Para identificar las relaciones se suele utilizar un verbo en primera persona del singular o en infinitivo. El nombre se escribe dentro del rombo.
Por ejemplo, si tenemos las entidades ESCRITOR y LIBRO en el Universo del Discurso correspondiente, podría existir una relación entre ellas denominada Escribe, que se representaría tal que así:
Grado de la relación Es el número de entidades que participan en la relación. Así, el vínculo Escribe es de grado 2 o, como se suele denominar, vínculo binario (que son los más frecuentes). También podemos encontrar de grado 3 o ternarios o un vínculo entre una instancia de una entidad con otras instancias de la misma entidad, las cuales se conocen como relaciones unitarias o reflexivas.
Cardinalidad de la relación También conocida como Tipo de correspondencia, indica la cantidad de instancias de cada entidad participante que están vinculadas con una instancia de la otra entidad participante. Esta cardinalidad puede ser de tres tipos:
- Relaciones Uno a uno (1:1) Cada instancia de la entidad ESCRITOR está relacionada con una instancia de la entidad LIBRO y cada instancia de la entidad LIBRO está relacionada con una instancia de la entidad Escritor.
- Relaciones Uno a ene (1:n) Cada instancia de la entidad ESCRITOR está relacionada con una o más instancias de la entidad LIBRO y cada instancia de la entidad LIBRO está relacionada con una instancia de la entidad ESCRITOR.
- Relaciones Ene a eme (N:M) Cada instancia de la entidad ESCRITOR está relacionada con una o más instancias de la entidad LIBRO y cada instancia de la entidad LIBRO está relacionada con una o más instancias de la entidad ESCRITOR.
La cardinalidad suele representarse en la parte superior del rombo que representa la relación, tal que así:
Mención especial para las relaciones 1:N, donde se dibuja una flecha indicando hacia donde se propaga la cardinalidad N. Para explicar de una forma más coloquial las relaciones, podríamos poner los siguientes ejemplos:
Relación 1:1 Donde un escritor ha escrito un solo libro y un libro ha sido escrito por un único escritor. O cogiendo la relación Profesor-Asignatura, un profesor puede enseñar una asignatura y una asignatura solo puede ser impartida por un profesor.
Relación 1:N Donde un escritor escribe uno o varios libros, pero un libro solo puede ser escrito por un único escritor o un profesor puede enseñar una o varias asignaturas pero cada asignatura solo puede ser impartida por un profesor.
Relación N:M Un escritor escribe uno o varios libros y cada libro puede ser escrito por uno o varios autores o un profesor puede enseñar una o varias asignaturas y cada asignatura puede ser impartida por uno o varios profesores.
En el caso de las relaciones 1:1 y N:M se denominan relaciones simétricas porque tienen la misma cardinalidad en ambos sentidos, por lo que no se representan con flechas.
Atributos de las relaciones
Las relaciones también pueden tener atributos como las entidades. Por ejemplo, para registrar la fecha de publicación de un LIBRO Escrito por un ESCRITOR, podemos incluir el atributo Fecha de publicación.
Tenemos que destacar que los atributos de las relaciones 1:1 o 1:N se pueden incluir en una de las entidades participantes en la relación. Concretamente, en las relaciones 1:1 podremos incorporar dicho atributo a cualquiera de las dos entidades, mientras que en relaciones 1:N se incorporará a la entidad que esté en el lado N de la relación.
Por ejemplo, si tenemos la relación Escribe entre ESCRITOR y LIBRO, donde la cardinalidad es 1:1, significa que el atributo puede estar en cualquiera de ellas. Sin embargo, si la relación fuese 1:N, donde cada autor ha podido escribir varios libros, el atributo solo podría incorporarse a la entidad LIBRO.
En las relaciones N:M el atributo no se puede incorporar a ninguna de las dos entidades y, por tanto, deberá especificarse obligatoriamente como atributo de la relación.
Otros elementos del modelo Entidad-Relación
Aunque hayamos definido los tres elementos básicos del modelo Entidad-Relación, no debemos olvidar otros dos que también juegan un papel importante: las claves y el dominio.
Claves. Definiciones y tipos.
Clave Primaria
Se denomina Clave Primaria o Clave Principal de una Entidad al atributo seleccionado por el diseñador de la BBDD para identificar, de forma inequívoca, a cada instancia de la Entidad. Por ejemplo, para la entidad EMPLEADO, el atributo NIF debería ser la clave principal, ya que es único identificando inequívocamente a cada empleado.
En otros casos, puede haber más de un atributo que identifique cada instancia, por lo que tendremos que elegir uno como clave principal. Por ejemplo, si para la entidad ALUMNO se recoge: DNI, Código Alumno, Nombre, Carrera, Curso, podemos decir que tanto DNI como Código Alumno servirían como identificadores inequívocos. Se dice que ambos son Claves Candidatas o, simplemente, Claves de la entidad ALUMNO. La elegida pasará a ser Clave Primaria y la que no se seleccione se denomina Clave Alternativa o Secundaria.
En los diagramas E-R, la clave principal se representa subrayando el atributo correspondiente y poniéndola en negrita, mientras que el resto de Claves Alternativas se representarían solo en negrita. Si usamos la notación alternativa, la clave principal se representa rellenando en negro el círculo del atributo.
La restricción que se impone a un atributo para ser clave principal es que NO PUEDE SER NULO. El resto de claves si que pueden tenerlos. Es decir, el atributo tiene restricción de unicidad.
Por ejemplo, si tenemos una entidad ALUMNO representada en el diagrama de la siguiente forma:
Sabemos que CodAlumn es la Clave Principal, DNI es un atributo con restricción de unicidad (es Clave Alternativa) que no puede tener valores nulos, los atributos Nombre y Curso no pueden tener valores nulos y que Teléfono si que los admite.
Si se tratase de alumnos que por edad pudieran no tener DNI, el atributo sería único con posibilidad de tener valores nulos, por lo que se representaría en negrita con un asterisco.
Hay ocasiones en que son varios atributos juntos los que constituyen una clave, es decir, la combinación de los valores de los atributos es distinta para cada instancia particular. Se dice en este caso que el conjunto constituye una Clave Compuesta
Clave Ajena
Se denomina Clave Ajena o Clave Foránea al atributo de una entidad que es clave principal en otra entidad de la base de datos. Este concepto se entenderá mejor cuando veamos como se transforma un E-R en el diseño lógico.
Clave Artificial
Es posible que una entidad no tenga ningún atributo con información relevante como para servir de principal. En estos casos, el diseñador de la BBDD debe crear uno que sea único e invariable para ser clave principal. Por ejemplo: código de artículo, número de orden, etc.
Dominio de un atributo
Cada uno de los atributos simples de un tipo de entidad está asociado a un conjunto de valores (o dominio) que especifica los valores que es posible asignar a dicho atributo para cada instancia individual.
Por ejemplo, para la entidad EMPLEADO el atributo Edad podría tener el dominio 16 a 65 años.
En los diagramas E-R no se representan los dominios de los atributos.
La evolución del modelo Entidad-Relación
Posteriormente, este modelo básico se amplió con un conjunto de constructores que ayudan a recoger más fielmente el Universo del Discurso, dando lugar a lo que conocemos como Modelo Entidad-Relación Extendido. Entre las novedades, encontramos las cardinalidades mínimas y máximas, especializaciones y generalizaciones, dependencia de existencia e identificación, etc.
Pero este modelo lo estudiaremos en una futura entrada, para no mezclar conceptos y asimilar bien los planteados en esta.
Teniendo en cuenta la representación
A lo largo de esta entrada os he contado como se representan los elementos del Diagrama Entidad-Relación, aunque esta simbología pertenece más a la hora de estudiar una asignatura de bases de datos en papel. A la hora de trabajar en el ordenador, se suelen utilizar elementos visuales más fáciles de representar y manejar en un programa de modelado, como son: tablas que engloban sus atributos, relaciones sin rombos, etc.
Me encantaría explicar este tema con los elementos utilizados en papel y lápiz, pero me retrasarían mucho a la hora de realizar ejercicios explicativos. Por eso, he decidido utilizar algún software de modelado para ir más rápido.
Pero recordad: el mejor método de aprendizaje siempre será el papel y el lápiz, sea bases de datos o programación. SIEMPRE.
Conclusión
Y hasta aquí esta nueva entrada sobre bases de datos relacionales.
Hemos explicado las 12+1 reglas de Codd para considerar una base de datos como relacional, hemos abordado los elementos del Diagrama Entidad-Relación (entidades, relaciones, atributos, claves…), así como detallado como se representan sus elementos.
Y ahora, como siempre, ¿me ayudas a difundir este post por redes sociales? Tienes los botones justo abajo.
Recuerda suscribirte a nuestra newsletter para no perderte ninguna novedad en nuestra web. Tienes el formulario justo aquí debajo y en el pie de página. Solo recibirás la notificación de que hemos publicado una nueva entrada, ¡nada más!
Hasta la próxima, ¡un saludo!
