El Modelado de Datos y el Diseño Relacional de sus Estructuras. Un enfoque práctico e intuitivo

De Wikilibros, la colección de libros de texto de contenido libre.
Saltar a: navegación, buscar

== EL MODELADO DE DATOS Y EL DISEÑO RELACIONAL DE SUS ESTRUCTURAS. Un enfoque práctico e intuitivo
Autor: Lucía Rosario Malbernat

Impreso en el Departamento de Servicios Gráficos de la Universidad Nacional de Mar del Plata de la República Argentina en junio del año 2000. ==



CONTENIDO TEMÁTICO
PREFACIO
PRÓLOGO
AGRADECIMIENTOS

CAPÍTULO I: INTRODUCCIÓN AL MODELADO DE DATOS INTRODUCCIÓN INFORMAL A LAS BASES DE DATOS BASES DE DATOS MANUALES Y AUTOMATIZADAS LOS GESTORES DE BASES DE DATOS USUARIOS DE LA BASE DE DATOS INFORMACIÓN Y DATOS LAS BASES DE DATOS AUTOMATIZADAS BASES DE DATOS OPERACIONALES Y DATA WAREHOUSE LA BASE DE DATOS COMO MODELO MEMORIZACIÓN Y COMUNICACIÓN DE LA INFORMACIÓN MODELO DE DATOS

CAPÍTULO II: EL MODELO ENTIDAD-RELACIÓN MODELO ENTIDAD-RELACIÓN ENTIDADES RELACIONES DIAGRAMA ENTIDAD-RELACIÓN EL DICCIONARIO DE DATOS CARACTERÍSTICAS ESENCIALES DOMINIO TIPOS DE ATRIBUTOS, PROPIEDADES O CARACTERÍSTICAS ATRIBUTOS QUE CALIFICAN Y ATRIBUTOS QUE IDENTIFICAN ATRIBUTOS SIMPLES Y ATRIBUTOS COMPUESTOS ATRIBUTOS SINGULARES Y ATRIBUTOS MULTIVALUADOS ATRIBUTOS REQUERIDOS Y ATRIBUTOS OPCIONALES ATRIBUTOS DERIVADOS TIPOS Y OCURRENCIAS DE ENTIDADES Y RELACIONES CLASIFICACIÓN DE LAS ENTIDADES SUBTIPOS Y SUPERTIPOS Especialización Subclase compartida Categorías ENTIDADES FUERTES Y ENTIDADES DÉBILES CLASES DE RELACIONES GRADO DE LAS RELACIONES RESTRICCIONES ESTRUCTURALES Participación: Relaciones parciales y relaciones totales Cardinalidad de las relaciones: Un modo práctico de analizar la cardinalidad de una relación La cardinalidad en las relaciones de grado unario REFINAMIENTO DE UN DIAGRAMA EFICACIA EN LA OBTENCIÓN DE INFORMACIÓN ESTÉTICA Y FACILIDAD DE LECTURA ¿ATRIBUTO O ENTIDAD? ¿ATRIBUTO MULTIVALUADO O RELACIÓN? MODELOS PARA IMPLEMENTAR UN ESQUEMA CONCEPTUAL

CAPÍTULO III: EL MODELO RELACIONAL UBICACIÓN DEL MODELO EN LA HISTORIA DE BASES DE DATOS IMPLEMENTACIÓN RELACIONAL IMPLEMENTACIONES NO RELACIONALES EL MODELO RELACIONAL RELACIONES REPRESENTACIÓN DE LAS RELACIONES: LAS TABLAS CLAVE PRIMARIA Claves candidatas ORGANIZACIÓN DE LA INFORMACIÓN PROPIEDADES DE LAS RELACIONES

CAPÍTULO IV: LA INTEGRIDAD DE LA BASE DE DATOS LA INTEGRIDAD DE LA BASE DE DATOS REGLAS DE INTEGRIDAD REGLAS DE INTEGRIDAD ESPECÍFICAS REGLAS DE INTEGRIDAD GENERALES REGLA GENERAL DE INTEGRIDAD ENTIDAD Claves primarias REGLA GENERAL DE INTEGRIDAD REFERENCIAL Claves extranjeras Diagrama Referencial ACCIONES DEL DBMS PARA GARANTIZAR LA INTEGRIDAD REFERENCIAL

CAPÍTULO V: TRANSFORMACIÓN DE UN MODELO DE DATOS ENTIDAD-RELACIÓN EN UN MODELO RELACIONAL DEL MODELO ENTIDAD-RELACIÓN AL DISEÑO RELACIONAL DISEÑO DE TABLAS MEDIDAS INFORMALES DE CALIDAD ACTUALIZACIONES ANÓMALAS Inserciones, Borrados y Actualizaciones anómalos DISEÑO DE TABLAS CON CRITERIO DE CALIDAD LAS ENTIDADES LOS ATRIBUTOS MULTIVALUADOS ATRIBUTOS OPCIONALES REPRESENTACIÓN RELACIONAL DE ENTIDADES QUE CONFIGURAN SUBTIPOS DE OTRAS ENTIDADES REPRESENTACIÓN RELACIONAL DE ENTIDADES DÉBILES REPRESENTACIÓN RELACIONAL DE RELACIONES 1 EN 1 REPRESENTACIÓN RELACIONAL DE RELACIONES 1 EN N REPRESENTACIÓN RELACIONAL DE RELACIONES M EN N Un caso especial de relaciones m en n: Los formularios REPRESENTACIÓN RELACIONAL DE RELACIONES RECURSIVAS

CAPÍTULO VI: NORMALIZACIÓN DE DATOS METODOLOGÍA PARA ESTRUCTURAR DATOS EFECTOS INDESEABLES DE UN MAL DISEÑO QUÉ SON LAS FORMAS NORMALES PORQUÉ NORMALIZAR UN DISEÑO NORMALIZADO, ¿ES LA MEJOR SOLUCIÓN? NORMALIZACIÓN DE LAS RELACIONES DEPENDENCIA FUNCIONAL PRIMERA FORMA NORMAL (1FN) SEGUNDA FORMA NORMAL (2FN) TERCERA FORMA NORMAL (3FN) FORMA NORMAL DE BOYCE-CODD (FNBC) CUARTA FORMA NORMAL (4FN) QUINTA FORMA NORMAL (5FN) DIAGRAMAS ENTIDAD-RELACIÓN PARA DOCUMENTAR

APÉNDICE A: RELACIONES

APÉNDICE B: ALGUNAS NOTACIONES PROPUESTAS PARA EL DIAGRAMA ENTIDAD-RELACIÓN NOTACIÓN DE PETER CHEN NOTACIÓN DE JAMES MARTIN NOTACIÓN DE IDEF1X

BIBLIOGRAFÍA Y FUENTES

ÍNDICE ANALÍTICO

PREFACIO

Prologar un libro “técnico”, (que generalmente pensamos como destinado a lectores iniciados del área de las ciencias exactas), desde un ámbito tan particular como lo es la formación, parece a primera vista lejano y un tanto incomprensible.
Pero es desde el oficio de la capacitación, en todos los desarrollos asociados, y en sus diferentes modalidades, que observamos a medida que llegaban los años 90, cómo el efecto de la aplicación de las tecnologías de la información y la comunicación impregnaban todos los ámbitos de los desempeños profesionales, configurando esta sociedad o era de la información que ya nos es cotidiana. Su funcionamiento gira en torno a los mecanismos de producción, tratamiento y distribución de la información, y exige, paralelamente, habilidades apropiadas para su uso en todas las áreas de la vida social.
La utilización de herramientas y procesos educativos diferentes, contextualizados, apropiados para ser incorporados en diferentes momentos de la trayectoria laboral, como formación y actualización continua, comparten un elemento común, que es la cantidad avasallante de información disponible.
Tanto las organizaciones como los actores particulares, estamos rodeados de múltiples accesos a la información, de tantos datos relacionados directa o indirectamente con la actividad que desempeñamos, con las acciones o tareas que se suceden día a día en la empresa o en la institución, con los resultados obtenidos o con las nuevas demandas que surgen del contexto.
El desempaño técnico, laboral y/o profesional hoy conlleva una problemática asociada que no es exclusiva de un área de trabajo: El tratamiento de la información. Con este término referimos al acceso, a la manipulación y también su utilización práctica. Su dominio se considera como un conocimiento básico para el éxito profesional.
Todos necesitan (necesitamos...) saber, de la manera más clara posible cuáles son los requerimientos de información en término de datos, cuáles serán aquellos que realmente permitan generar procesos evaluativos del estado de una situación o de la dinámica de una organización o del comportamiento de una matrícula, por ejemplo. Cuando es menester tomar una decisión o simplemente reflexionar sobre la propia práctica es crucial disponer de la información adecuada.
Para poder generar estos procesos evaluativos, las instituciones, las organizaciones, los profesionales, los comerciantes, los docentes, en fin, todo trabajador que esté impregnado de información significativa, necesitan diseñar una base de datos que le permita acceder a ella cuando así lo requiera.
Es dentro de este panorama que la propuesta que aparece en este libro es sumamente atractiva. Nos involucra a todos “desde un enfoque práctico e intuitivo”, que permite acercarnos a cada uno de nosotros desde nuestro lugar, sin invocar como obstáculo insalvable la falta de formación en matemática avanzada, o de conocimientos técnicos informáticos.
Esto no significa que la tarea sea sencilla. Por cierto que hay que establecer estrategias de abordaje donde la abstracción estará muy enfocada en el problema, paso a paso. Pero hay herramientas conceptuales sencillas para lograr la abstracción necesaria.
El camino comienza con la propuesta de conocer a fondo los datos de los cuales disponemos (o queremos disponer), tanto como las vinculaciones que tienen con otros datos y sus restricciones. Si podemos establecer este conocimiento a fondo de las restricciones y vinculaciones interdata, (y parece que efectivamente así es) podemos analizar si es factible de obtener la información esperada y ¿por qué no? Armar con ella una base de datos a la medida de nuestras necesidades.
Reitero, la tarea que se nos presenta no es simple ni fácil, pero no podemos sustraernos al desafío de desarrollar mayores capacidades para el tratamiento de la información que nos es significativa.


Beatriz Graciela Banno

Lic. en Ciencias de la Educación


PRÓLOGO


Los años ’90 fueron propicios para el desarrollo de aplicaciones de bases de datos lo suficientemente poderosas como para resolver muchos requerimientos insatisfechos y muy deseados por los usuarios desde hacía años.
Las nuevas tecnologías extendieron el poder de las bases de datos relacionales, cuyo fundamento matemático se aplica a los problemas de redundancia, consistencia de las relaciones y derivaciones de información pero nada dicen acerca del hipertexto, de la hipermedia, de la multimedia o de la distribución de los datos.
Pero por sobre todas esas cosas nada dice acerca del rendimiento de la base de datos en las actualizaciones y particularmente de la productividad de las consultas para obtener información de los datos almacenados y nada, absolutamente nada— dice acerca de su eficacia.
Esto significa que podríamos tener una base de datos con un diseño relacional ejemplar y, sin embargo, no servir para definitivamente nada.
Hoy en día, ningún profesional de la informática puede abstraerse totalmente del modelado de datos sólo que hablar de modelado de datos para sistemas de bases de datos relacionales no debe significar sólo hablar acerca de un diseño relacional.
No tengo dudas de que el modelado de datos es de interés para quien programa, quien analiza y quien diseña sistemas e incluso para quien los opera, puesto que la línea divisoria entre una función y otra puede ser en algunas oportunidades muy difícil de establecer.
Y cuando no lo es, aún entonces, una interfase que permita la comunicación entre los usuarios que llevan a cabo las distintas funciones es de vital importancia en cualquier proyecto.
Por otra parte, las organizaciones generan en el paradigma actual volúmenes sorprendentes de datos tanto en el proceso de transacciones como en sus sistemas para el soporte de decisiones y los usuarios demandan buenos diseños de bases de datos. En ese contexto, el modelo relacional no es una herramienta suficiente para diseñar una base de datos.
Si el sistema de información de una organización no tiene bases de datos automatizadas, obviamente este modelo no tiene ninguna importancia pues es definitivamente inútil; si, en cambio, las bases de datos del sistema de información están informatizadas, es muy útil pero no se comporta como una herramienta cabal pues sólo garantiza el control de la redundancia de datos, de la integridad referencial y del resultado de las operaciones pero no el rendimiento del sistema.
En consecuencia, modelar una base de datos para gente del área de sistemas implica trabajar con algún modelo como puede ser el relacional pero también implica manejar otras herramientas para cubrir los aspectos que el modelo relacional no abarca, pues algunas aplicaciones, especialmente las nuevas, requieren conceptos adicionales y tecnología adicionales.
Pero... ¿Qué pasa con los usuarios de los sistemas de información que no son de las áreas informáticas?
Podemos ver a innumerables profesionales y técnicos de áreas ajenas a la informática y a las áreas de sistemas necesitar resolver sus problemas en términos de datos y no poder hacerlo por, –obviamente— no manejar ni la teoría ni la práctica que puede avalar un diseño de bases de datos, aún tratándose de aplicaciones triviales.
Desde hace algún tiempo ya, muchos de los usuarios de sistemas de información abocados a cualquier actividad relacionada con estos tienen que enfrentarse a una nueva forma de entender la información que se ha convertido en un centro de atención organizacional.
Pero esto no es todo: También tienen que vérselas con todo un paquete de tecnología hace unos años impensado: La informática y la telemática están en el orden del día de cada profesional.
La informática, esto es el tratamiento automatizado de la información, es materia obligada para todo profesional que tenga que competir en el mundo moderno. Sin embargo, esto no es un problema mayor: La computación ha sufrido una evolución muy marcada en los últimos 5 años que transita los caminos de la amigabilidad y la facilidad de operación de los sistemas.
En consecuencia, los profesionales de cualquier área de la ciencia y de la técnica ya no sólo tienen que manejar una computadora: Hoy, los profesionales quieren manejar una computadora.
Es en este marco en el que me he propuesto escribir este libro que no trata de los sistemas de bases de datos sino tan sólo discurre acerca de la elección de los datos, de las restricciones que deben imponérseles y de las estructuras de datos que conformarán una base de datos, en especial, si es no corporativa.
En el convencimiento de que la tarea de elección de los datos de una base de datos puede ser, en algún momento, un problema para cualquier persona involucrada o no con la informática, propongo que tomemos las ideas que he acopiado de los autores de referencia y trabajemos intuitivamente el tema.
Una de las principales labores en ese punto es descubrir la información que los usuarios necesitan y las políticas de negocio que pudieran existir en forma explícita o implícita y que nadie conoce mejor que los propios usuarios.

En el Capítulo I, “Introducción al Modelado de datos” intento acercar al lector una terminología con la que quizás no esté familiarizado e iniciarlo en el tema. En la primera sección de este capítulo, “Introducción informal a las bases de datos”, el lector puede relacionarse descuidadamente con temas que serán desarrollados a lo largo de todo el libro.

En el Capítulo II, “ El Modelo Entidad-Relación” trato acerca de una herramienta útil para construir modelos de información que fue propuesta por Peter Chen en el año 1976 y que ha sido tratada por numerosos autores y adaptada a diversas necesidades en variadas oportunidades.
Este modelo utiliza un diagrama sencillo de construir para cualquier persona con capacidad para abstraer del mundo que la rodea ciertos elementos basándose en reglas predefinidas y se puede completar con el uso de otra herramienta, textual esta, que documenta todos los aspectos relacionados con los elementos del modelo que se llama diccionario o repositorio de datos.
La mayor dificultad que presenta la confección de este modelo consiste en la necesidad de conocer y entender a fondo el ambiente –una organización o parte de una organización, por ejemplo— y los elementos que lo conforman.
Mi apreciación es que si en ello consiste el mayor problema, entonces, hacer el modelo de datos de un ambiente, cuando no se requieren tecnologías especiales, puede ser una tarea adecuada tanto para los “dueños” del ambiente, entendiendo por dueños a quienes intiman con él día a día, como para la gente de sistemas.
Cuando en una organización existe una persona que conoce y entiende acerca de los datos corporativos y que tiene por responsabilidad central la administración de dichos datos recibe el nombre de “Administrador de Datos”. El modelo Entidad-Relación puede permitirle a un administrador de datos –en cumplimiento formal o informal de la función– modelar gran variedad de aplicaciones de bases de datos sin mayores conocimientos adicionales.

A través del Capítulo III, “El Modelo Relacional” y del Capítulo IV, “La Integridad de la Base de Datos”, presento al lector en forma introductoria y sin grandes pretensiones, al modelo de diseño de bases de datos más difundido en la actualidad en las implementaciones comerciales.
Para profundizar el tema, el lector podrá recurrir a los autores de referencia.
Este modelo permite elegir en forma metodológica las estructuras de datos que formarán parte de una base de datos; puesto que para derivar esas estructuras es necesario conocer los datos del sistema, se requiere de una investigación previa de los datos y las relaciones entre los datos que puede realizarse mediante un modelo tal como el que se introdujo en el Capítulo II.
Dado que el modelo relacional tiene un fundamento matemático muy fuerte puede resultar difícil de interpretar y de resolver para la gente que no está involucrada con el diseño de bases de datos.
Por ese motivo, en el Capítulo V, “Transformación de un Modelo Entidad-Relación en un Modelo Relacional”, se propone volcar el análisis realizado con el modelo aprendido en el segundo capítulo en un modelo relacional, pero en forma intuitiva en lugar de seguir los pasos propuestos por el genial padre del modelo relacional, Edward F. Codd.
Para ello se analizan previamente ciertas medidas informales de calidad del diseño y se observa qué problemas puede ocasionar un mal diseño.

Por último, en el Capítulo VI, “Normalización de Datos” se trabaja un poco más la idea presentada en el capítulo anterior acerca de los efectos indeseables de un mal diseño y se presentan las formas normales.
Este capítulo pretende no sólo introducir al lector en el tema de la normalización sino también darle herramientas para rever su propio trabajo ya que habiendo interpretado las cuestiones de calidad tratadas y habiendo avanzado en el modelo de datos, será bastante sencillo aplicar la normalización.
La propuesta es, entonces, la siguiente: Cuando queramos crear una base de datos en un gestor de bases de datos, primero debemos tener en claro cuál será su estructura, y cuáles serán las propiedades y las restricciones de sus elementos. Diseñar las tablas no es tarea sencilla, pero... ¡A trabajar con esfuerzo y dedicación en un primer paso de modelado con el Modelo Entidad-Relación que luego será muy sencillo crear tablas de acuerdo al Modelo Relacional!

AGRADECIMIENTOS

No puedo dejar de expresar mi más profundo reconocimiento a todas las personas que han hecho posible que realizara este trabajo en el que he puesto un entusiasta esfuerzo y una apasionada dedicación y a todos los alumnos que tanto me han hecho pensar durante casi una década al lado de un pizarrón.
Quiero agradecer particularmente a quienes colaboraron en este proyecto contribuyendo con su tiempo, dedicación y conocimientos en la tarea de revisión de los borradores: A la Ing. Agustina Estradé, a quien a demás agradezco por distinguirme con su amistad, al Cr. Luis Prior, profesor adjunto de la Universidad Nacional de Mar del Plata y profesor titular del Mar del Plata Community College y, especialmente, a la Lic. Cecilia Ruz, profesora titular de la Universidad CAECE, cuyos aportes sustanciales posibilitaron el logro de un trabajo acabado.
Del mismo modo quiero expresar mi gratitud a todas las personas que me brindaron incondicionalmente su apoyo, dándome ánimos para la realización del trabajo desde su inicio, facilitándome así la tarea que estaba en marcha: Al Cr. Juan Carlos Elgarrista, profesor titular de la Universidad Nacional de Mar del Plata, a la Directora del Proyecto Universidad Abierta de la Universidad Nacional de Mar del Plata, Lic. Aída Emilia Garmendia y especialmente a la Lic. Beatriz Graciela Banno del equipo de procesamiento pedagógico del Proyecto Universidad Abierta, cuya profesionalidad me inspiró en la labor.
Gracias también a mi familia que fue el aliento para hacer esta tarea y son el aliento para hacer todas las que realizo.

Lucía Rosario Malbernat

Agosto del año 2000



Capítulo I:
INTRODUCCIÓN AL MODELADO DE DATOS


INTRODUCCIÓN INFORMAL A LAS BASES DE DATOS

Para hablar de una base de datos es necesario considerar alguna situación real donde haya entidades de cualquier tipo -Proveedores, Vendedores, Mercadería, Rubros, Sucursales, Zonas, Proyectos-, sin importar si se trata de personas, objetos concretos u objetos abstractos.
Todas esas entidades pertenecen a un mundo real y tienen cualidades que los identifican, -un proveedor tiene el legajo 127 o el CUIT 20-40.213.243-4- y cualidades o atributos que los caracterizan –Juan Pérez tiene 28 años, la zona Puerto tiene asignados 4 vendedores-.
Por otra parte, en esa realidad, pasan cosas. A los objetos les acontecen cosas. Juan gana $ 1.500. María obtiene $ 500 por comisiones. Existen 45 existencias del artículo 123.
Y en medio de esa realidad, podemos pensar en una base de datos. ¿Qué es una base de datos?


BASES DE DATOS MANUALES Y AUTOMATIZADAS

Una base de datos es el conjunto almacenado de una manera en particular de esos atributos que identifican y que caracterizan o califican a los objetos y también a los acontecimientos.
Pero para hablar de las características de los objetos y de los acontecimientos tuve que emitir juicios para expresar la información de ese mundo real:
Juan tiene 28 años. Pedro tiene 26 años. Ana tiene 30 años.
Y esa información que es, en definitiva, lo que quiero almacenar en una base de datos, tiene elementos distintivos, y elementos comunes.
¿Cuáles son los elementos distintivos? ¿Cuáles son los elementos comunes?
Juan, Pedro, Ana, 28, 26 y 30 son elementos distintivos; “tiene” y “años” son comunes; siempre serán los mismos para cualquier persona de cualquier edad.
El conjunto de los elementos distintivos son los datos que se van a almacenar en una base de datos pues permitirán codificar la información transmitida en los juicios.
Pero si hablamos nada más que de un conjunto de datos, podría tener Juan, Pedro, 30, Ana, 26, 28 porque los elementos de un conjunto no guardan orden.
Entonces, necesito almacenar de alguna forma, no sólo al dato, sino también a la relación que existe entre (nombre; Juan) y (edad; 28).
Imaginemos que queremos guardar a esas relaciones que existen entre nombres y edades, por ejemplo, en un papel. Podríamos, entonces, tener una tabla del tipo que puede verse en la Figura 1.


Figura 1




En esa tabla, cada renglón o fila toma distintos valores y es homogéneo con el siguiente renglón.
Por otra parte, las instancias que hay en cada una de las columnas también toman distintos valores todos del mismo tipo, pero entre una columna y la siguiente columna no hay necesariamente homogeneidad.
La tabla a) de la Figura 2 es un poco más compleja que la de tabla de la Figura 1 que guarda la relación que existe entre los nombres y las edades. Incluye la razón social y otros atributos de los proveedores, que son la edad, el domicilio, el código postal y la localidad, un número de factura emitida por el proveedor, el importe total de esa factura y la fecha de esa factura. En esa tabla se está guardando la relación que existe entre un proveedor y una compra que se le ha hecho a ese proveedor.
Y a estas relaciones podría representarlas de otras formas equivalentes , no forzosamente en una tabla única. Por ejemplo, Razón social, edad, domicilio y código postal podrían estar en una tabla, código postal y localidad en otra, Razón social, Número de factura, Importe total factura y fecha en otra. Nos quedarían, entonces, tres tablas tales como las que se dibujaron en la parte inferior de la Figura 2.
Si esta última representación –o alguna otra- estuviera hecha, como imaginamos recientemente, sobre papel, tendríamos una base de datos manual. Tratándose, entonces, de una base de datos no computarizada, es posible que la tabla b) forme parte, en realidad, de una carpeta con el legajo del proveedor, la tabla c), sea parte de una planilla de caja y la tabla d) una guía postal.


Figura 2

Si, en cambio, se tratara de una base de datos computarizada, entonces, posiblemente tendríamos, de alguna manera, las tres tablas de datos almacenadas en un dispositivo de almacenamiento secundario de una computadora (posiblemente un disco rígido). Existen distintas maneras de almacenar archivos de datos. Una alternativa puede estar basada en programas de aplicación estándar o a medida. Otra alternativa puede ser la basada en el uso de los gestores de bases de datos.

LOS GESTORES DE BASES DE DATOS:

Estamos considerando que se trata de una base de datos que está informatizada y, así como hay programas o conjuntos de programas que son especialistas en el manejo de archivos de texto -los procesadores de texto por ejemplo- también hay programas que son especialistas en el manejo de datos y que se ocupan de todas las cuestiones relacionadas con ellos.
Esos programas especialistas en administrar datos son los gestores de bases de datos o administradores de bases de bases datos también conocidos como DBMS.
Un DBMS es un programa de aplicación o herramienta que maneja todo los requerimientos que los usuarios hacen sobre una base de datos. Permiten, entre otras cosas, crear estructuras, hacer altas, bajas, modificaciones y realizar consultas de datos, Así, las funciones básicas de un DBMS son:

  • permitir que el usuario defina los datos de la base de datos,
  • proporcionar las herramientas para la manipulación de los datos manejando requerimientos previstos e imprevistos, posibilitando las actualizaciones de datos existentes y el agregado de nuevos datos en la base de datos y
  • garantizar la seguridad, la consistencia y la integridad de los datos.

Respecto de la definición de los datos, dijimos que era necesario mantener la relación atributo-valor del atributo, y tendremos que crear, para ello, una estructura de almacenamiento. Esa estructura, en una base de datos automatizada, se llama registro y está compuesta por campos.
Cada campo guarda datos de algún tipo en particular. Por ejemplo, en el campo edad, se tendrán datos de tipo numérico entero y en el campo Importe total factura se tendrá un tipo de dato también numérico, pero real.
En cuanto a la manipulación de datos, cuando en una estructura, se ingresan datos, se dice que se da de alta un registro y lo que efectivamente se hace es agregar una nueva fila de datos en la tabla.
Como contrapartida, también puede haber en la tabla bajas y modificaciones de los datos.
Pero los datos son almacenados para obtener, a partir de ellos, información de la realidad que representan. Así que, además de producirse altas, bajas y modificaciones, también se van a producir consultas de datos.
Incluso, si la base de datos tiene más de una tabla, posiblemente sea necesario hacer consultas que relacionen los datos de una tabla con los datos de otra tabla. Esa relación debería establecerse por algún campo común a ambas tablas.
Por ejemplo, si se definieron en un DBMS las tablas b), c) y d) de la Figura 2, y es necesario conocer de qué localidad es un proveedor, habrá que consultar las tablas b) y c) que tienen en común el campo Código postal. Entonces, veremos que Juan Pérez es de Mar del Plata pues en la tabla de proveedores tenemos su código postal (es 7600) y en la tabla de los códigos postales se observa que 7600 corresponde a la localidad de Mar del Plata.
Será el DBMS el que le proporcione a los usuarios los comandos para poder realizar, entre otras, todas las tareas sobre datos que vimos precedentemente (definición de estructuras, altas, bajas, modificaciones y consultas de datos), posiblemente a través de menues, de barras de herramientas o de algún editor de comandos.

USUARIOS DE LA BASE DE DATOS

En una base de datos de escritorio suele ser un único usuario el que realice todas las actividades vinculadas al diseño, al uso y a la administración de la base de datos. Sin embargo, cuando se trata de una base de datos corporativa, suelen requerirse usuarios con distintos niveles de conocimiento y de especialización.
Así, podrán existir una o más personas con capacidad para definir en la base de datos las estructuras de datos y sus correspondientes restricciones. La persona que se ocupa formalmente de las tareas de administración de la base de datos recibe el nombre de DBA.
También interactuarán con la base de datos los programadores de aplicaciones y los usuarios finales. Estos últimos podrán estar dedicados a la actualización de datos o la obtención de información y podrán tener distintos niveles de práctica.

INFORMACIÓN Y DATOS

En la introducción hablamos de información y hablamos de datos. Tratemos más específicamente a esos conceptos para vincularlos a la noción de base de datos.
La información puede ser pensada como el conocimiento obtenido a partir de datos a los que alguna persona, a través de algún procesamiento, les añadió significado, utilidad y propósito convirtiéndolos en un recurso muy caro para los objetivos de una organización e incluso, en el mundo de hoy, para los objetivos o propósitos particulares de sus miembros.
Los datos, por su parte, pueden pensarse como una codificación. Pueden codificar a las cosas que pasan en algún ambiente que podría ser, por ejemplo, una organización con cada actividad que realiza diariamente. Pueden codificar a las cualidades que caracterizan a las entidades de ese ambiente.
Los datos son, en ese contexto, un conjunto de símbolos que se usan para expresar o representar objetos (concretos o abstractos) o acontecimientos mediante ciertas características o propiedades que llamaremos esenciales.
Luego, ese conjunto de datos que codifica algún ambiente, si se le presenta a algún usuario receptor en forma inteligible, si está organizado en un contexto conocido o deducible, si está acompañado de un conjunto de reglas que le permitan al usuario interpretarlos para lograr alguna utilidad, se transforma en información.
El cometido de este libro es intentar dilucidar cómo los miembros de una organización y especialmente los usuarios particulares, pueden organizar, estructurar y mantener el archivo de datos personales o de la organización, para producir la información que se necesita, en el momento que se necesita y de la manera en que se necesita.

LAS BASES DE DATOS AUTOMATIZADAS

Una base de datos es, hablando superficialmente, y de acuerdo a lo que ya analizamos, una compilación de datos almacenados, conectados mutuamente por su significado y con alguna acepción implícita.
Sin embargo, cuando se habla de bases de datos automatizadas, generalmente se entiende tácitamente que esa colección de datos tiene ciertas propiedades adicionales:

  • Debe representar algunos aspectos del mundo real. Puede estar representando, por ejemplo, los datos almacenados por el sistema de información de alguna organización o de alguna de sus áreas,
  • no sólo debe existir un significado inherente a cada dato sino que también debe existir una coherencia lógica entre ellos,
  • debe haber sido diseñada, construida y mantenida para propósitos específicos,
  • debe poder satisfacer por medio de algún procesamiento los requerimientos de información programados o no programados de sus usuarios y
  • debe procurar garantizar la confiabilidad, la seguridad, la integridad y la protección de los datos.

La base de datos tiene que reflejar en todo momento los cambios que sufre el sistema que representa. Para que esto sea factible, debe tener un buen diseño y estar adecuadamente documentada.
La organización de los datos en una base de datos deberá representar el significado de fondo o subyacente de los datos, es decir, su semántica, en forma correcta y eficiente. Sino, simple y sencillamente, no servirá para resolver las recuestas de información de sus usuarios .

BASES DE DATOS OPERACIONALES Y DATA WAREHOUSE

Según el fin para el cual fue creada, una base de datos puede ser:

  • transaccional, operacional u orientada a la producción u
  • orientada a la exploración o del tipo data warehouse

En organizaciones comerciales, industriales, de servicios, gubernamentales, etc., la base de datos del tipo transaccional esta generalmente destinada a mantener y transmitir en forma permanente el estado de todas las actividades de la organización. Por su parte, una base de datos orientada a la exploración es un enorme almacén de datos que contiene informaciones de todas las fuentes relacionadas con la actividad de la organización.
Estas bases de datos están generalmente aplicadas a que los usuarios responsables de la toma de decisiones estratégicas puedan comprender el pasado y explorar posibilidades futuras para planificar las actividades de la organización. Para ello integran datos históricos de todas las fuentes disponibles y los procesa para que los usuarios puedan realizar el análisis que deseen. El data warehouse convierte, entonces, los datos operacionales de la organización en una herramienta competitiva, pues los hace aprovechables y adecuados para los usuarios que los requieren para el análisis y toma de decisiones.
Es decir, que mientras que las bases de datos operacionales están consagradas a reflejar la realidad y tienen un propósito específico y bien definido, las orientadas a la exploración intentan representar qué puede ser o qué puede pasar y tienen un menor nivel de previsión de operaciones a realizarse.
Nos ocuparemos sólo del modo en que se organizan y se estructuran los datos de las bases de datos operacionales típicas, que suelen requerir optimizar las actualizaciones de los datos garantizando su integridad, pues la tecnología del data warehousing, debido a su orientación analítica, impone un procesamiento y una conceptualización especial .

LA BASE DE DATOS COMO MODELO

La base de datos es, atendiendo a sus propiedades implícitas, un conjunto de datos que deben permanecer almacenados en forma más o menos permanente y deben ser relevantes para la organización.
Entonces, la base de datos puede ser vista ella misma como un modelo que se construye para reflejar una "realidad" en particular: La realidad de sus usuarios.
Por ese motivo, la base de datos debe contener información minimal, es decir, suficiente para construir toda la información que los usuarios soliciten acerca de la realidad que se representa y no más que esa.
Además, los datos que se almacenan deben ser relevantes, es decir, significativos para los usuarios. Pero, ¿Qué significa que sean relevantes o significativos? ¿Cuándo son relevantes o significativos?
La respuesta depende exclusivamente del contexto. Analicemos un caso: Una base de datos que almacene datos sobre los empleados de una organización seguramente incluirá sus nombres y apellidos. ¿Alguien puede dudar de que el nombre y apellido de un empleado es relevante? Creo que nadie dudará.
¿Incluirá, además, el color de ojos y el color de cabello del empleado? La respuesta es “depende”. ¿De qué depende? Si la base de datos es la una empresa pesquera, seguramente, el color de ojos y el color de cabello del empleado no sean datos relevantes. Sin embargo, si la base de datos es de una empresa dedicada a la organización de desfiles de moda, quizás, esos sean datos significativos.
Por otro lado, el principal método para el diseño de bases de datos es la construcción de modelos que representen su estructura. La herramienta más importante para el diseñador de bases de datos es, entonces, el modelo, tome este la forma que tome.
Nos abocaremos a la construcción de dos modelos útiles en el diseño de bases datos: El modelo Entidad-Relación y el Modelo Relacional.

MEMORIZACIÓN Y COMUNICACIÓN DE LA INFORMACIÓN

La base de datos debe satisfacer dos servicios que son propios de la problemática de la información: El de memorización de la información, (mantenerla almacenada en el tiempo) y el de comunicación de información (trasladarla en el espacio), que son dos actividades que surgen para lograr reducir incertidumbre o tomar decisiones.
La información que se adquiere de la realidad se transmite, según ya dijimos, en forma de juicios y los valores de los datos obtienen su significado a partir del vínculo que tienen con los otros datos que surgen de dichos juicios.
Retomemos el ejemplo de la edad que utilizamos en la introducción, para la proposición Juan tiene 28 años: Para ese juicio los datos son Juan y 28. 28 significa la edad de Juan.
Los datos surgen, entonces, de una codificación de los juicios que emitimos con información del contexto; en un entorno informático pueden ser interpretados como la representación computacional de dichos juicios y se expresan mediante registros lógicos.
Los registros lógicos son, entonces, estructuras compuestas por datos que están vinculados unos con otros por una relación surgida del contexto. Esto es, (Juan, 28) podría ser un registro lógico correspondiente a una estructura compuesta por (nombre, edad) denominada... “Edad de los invitados”.
Esto es, si quisiéramos almacenar las edades de los invitados a una fiesta, podríamos diseñar una estructura de datos compuesta por dos elementos que se llaman campos, crear esa estructura de datos con un programa que maneje bases de datos y guardar tantos registros como invitados haya.
Luego, de esa manera, un registro lógico más el contexto que agregan los usuarios o las interfaces de las aplicaciones, posibilitarán la reconstrucción del juicio original o alguna información relacionada; la conexión de los datos constituirá, entonces, información. Que Juan sea mayor de edad, por ejemplo, Juan tenía 28 años puede ser información para algún usuario.
Veamos otro ejemplo: La secuencia de dígitos 5402234749999 sin un contexto conocido no tiene significado. Si el contexto es compartido, ya sea en forma implícita o en forma explícita, como en el caso de la ficha de la Figura 3, su significado se puede interpretar.


Figura 3

Incluso, conociendo el sistema numérico de discado telefónico podremos deducir que esa cadena de dígitos numéricos correspondiente al teléfono de Juan Pérez corresponde a un abonado telefónico argentino (porque 54 es el código de país que le corresponde a la República Argentina). Además, podemos concluir que es de la ciudad de Mar del Plata pues 223 es el código de esta ciudad.
Sin embargo, como no lo conozco a Juan Pérez y no tengo intención de llamarlo por teléfono, esa secuencia de dígitos es un dato que no representa información para mi persona, al menos, no en este momento.

MODELO DE DATOS

Una base de datos, como ya se dijo, es un conjunto de datos relevantes para los propósitos de una organización o una persona, siendo los datos relevantes los que sirven para tomar decisiones: El modelo que se construye sólo tomará los datos relevantes, no teniendo el resto de los datos interés alguno.
Lo primero que debería construirse al diseñar una base de datos es el modelo de datos del sistema de información que se quiere representar. Se trata de un modelo conceptual que puede ser visto como el mapa de los datos relevantes del mundo que se describirá en la base de datos, que recién entonces se podrá construir.
Todo modelo es una abstracción de la realidad; es una representación. Lo que se está representando con el modelo de datos es la realidad del usuario del sistema en términos de sus datos relevantes, es decir, aquellos que requiera para obtener información. Un modelo de datos es, entonces, un conjunto de herramientas conceptuales que permiten describir datos, los vínculos con otros datos, el significado asociado a los datos y sus restricciones de consistencia. Para construirlo se debe interpretar la realidad que se representa y eso se puede lograr extrayendo las características esenciales de sus entidades y acontecimientos.
El modelado de datos, entonces, consistirá en aplicar reglas pre-definidas a las características esenciales extraídas de la realidad de los usuarios. A esa realidad se le hará una de-construcción analítica que brindará visiones con distintos grados de abstracción y completitud.
Luego, cuando se comprenda realmente la semántica de los datos, se podrá diseñar el conjunto de archivos que permitan registrar adecuadamente los eventos que le ocurren a cada entidad.




Capítulo II:

EL MODELO ENTIDAD-RELACIÓN

MODELO ENTIDAD-RELACIÓN

Para diseñar un modelo de datos, la ingeniería ha proporcionado varias técnicas. Una de ellas, presentada por Peter Chen bajo el título “The Entity-Relationship Model: Towards a Unified View of the Data” en el año 1976, es conocida como Modelo Entidad-Relación.
Se trata de una representación que permite modelar estáticamente los datos de un sistema de información sobre la base de entidades y de relaciones entre entidades. Para ello, propone analizar los datos que describen a dichas entidades y relaciones. Este modelo proporciona un lenguaje para expresar el modelo de datos que el usuario requiere para su sistema de información. De esta manera, se podrán analizar prematuramente sus necesidades para tener seguridad de que no le faltará información.
Mediante él se podrá componer y analizar la semántica de las estructuras de datos de una base de datos, si es que esta se implementa.
Para que este modelo efectivamente sirva, debe reflejar categóricamente la realidad de acuerdo con los requerimientos de información que los usuarios tengan de ella.

ENTIDADES

La componente primaria de un modelo Entidad-Relación es la entidad. Una entidad es una cosa que existe y es distinguible o identificable. Se trata de un objeto o un concepto reconocible del mundo real o imaginario.
Una entidad también ha sido definida como cualquier cosa sobre la que es necesario almacenar información, es decir, todo aquello que es importante para los usuarios de un sistema. Una entidad, bajo este concepto, puede ser:

  • un individuo (un cliente, un alumno, un proveedor),
  • un objeto real (una película, una mercadería, un libro),
  • un concepto abstracto (un proyecto, una materia, un film) pero también puede ser...
  • un acontecimiento (el alquiler de un video, la aprobación de un examen, la compra de algún artículo) ya que sobre los acontecimientos también es necesario almacenar información.

RELACIONES

Por su parte, los vínculos que se verifican entre las entidades, se denominan relaciones. Una relación es, entonces, una asociación entre entidades. Las entidades involucradas en una relación dada son partícipes de dicha relación.
Estos vínculos son bidireccionales. Es decir, si se verifica una relación entre una entidad A y una entidad B, entonces, necesariamente también se verifica una relación entre la entidad B y la entidad A.
Por ejemplo, si se evidencia que los Operarios reparan Máquinas, también acontecerá que las Máquinas son reparadas por Operarios.
Las relaciones también pueden tener atributos propios. En el ejemplo, “artista crea obra de arte” podría existir un atributo propio de la relación denominado “Año de creación” que en el caso del David de Michelangelo tomaría por valor 1504.

DIAGRAMA ENTIDAD-RELACIÓN

El modelo Entidad-Relación se representa gráficamente mediante los Diagramas Entidad-Relación (Diagramas E/R o DER).
Debido a su simplicidad, el DER podrá utilizarse como herramienta gráfica de análisis, de documentación o de comunicación de un sistema dado que tiene posibilidad de representar un sistema de información de manera accesible a cualquier tipo de usuario.
En estos diagramas, cuando se utiliza su simbología original, se representan a las entidades como rectángulos, a las relaciones que existen entre las entidades como rombos, y a las conexiones como líneas.
Algunos autores incluyen también en el diagrama las propiedades de las entidades con círculos o elipses, tal como puede observarse en la Figura 4.


Figura 4

Sin embargo, no siempre es posible incluir en el dibujo tantas elipses como atributos tengan las entidades y relaciones. Por ese motivo, creo que es conveniente acompañar siempre al diagrama que se bosqueja con una herramienta textual.
Desde que el modelo fue introducido por Chen hace casi 25 años, numerosas modificaciones han sido sugeridas para la confección del diagrama Entidad-Relación y, en consecuencia, se han propuesto variantes en la simbología.
Cuando en este mismo capítulo tratemos algunos elementos complementarios de la entidad y de las relaciones haremos referencia a la simbología propuesta para sus respectivas representaciones.
No creo que sea importante qué metodología se elija para documentar un modelo de datos. Sin embargo, una vez tomada la decisión de cómo se trabajará, se deben respetar los criterios elegidos y se debe procurar elaborar el modelo de manera homogénea, es decir, siempre de igual manera.
El modelo original fue revisado por el propio Chen y muchos otros especialistas, incluso para su incorporación a herramientas CASE por lo que en la actualidad no existe un estándar.
Los productos CASE y los DBMS con capacidades gráficas suelen tener opciones de dibujo para crear diagramas Entidad-Relación. Los símbolos gráficos originales no son idóneos para representar un modelo Entidad-Relación en un sistema de computación, en particular, si tienen interfase gráfica de usuario -estos no existían en la década del '70- por lo que se inventaron, por necesidad, nuevas simbologías.
En la Figura 5 puede verse el mismo caso representado en la Figura 4 con otra simbología basada en la propuesta de James Martin.

Figura 5

En el Apéndice B se detallan algunas simbologías utilizadas para realizar el diagrama Entidad-Relación y puede consultarse también la bibliografía fuente para analizar otras alternativas.
Las herramientas CASE, en general, listan los atributos, tal como puede verse en la Figura 6, en algún menú, ventana u objeto similar.


Figura 6

Mas allá del diagrama y el diccionario de datos, dado que cada entidad y cada relación pueden ser representadas como el conjunto de las propiedades que posee, se pueden expresar, también, por medio de la lista de dichos atributos. Algunos autores, por ejemplo, James Martin, llaman a esa lista, archivo plano. Martin define al archivo plano como matriz bidimensional o distribución bidimensional de elementos de datos.

EL DICCIONARIO DE DATOS

Un diccionario de datos o repositorio de datos es un registro organizado o catálogo de todas las estructuras de datos del sistema de información. Las estructuras de datos son conjuntos de uno o más datos que son tratados como unidades.
El diccionario de datos incluye la definición, la composición, las relaciones de una estructura con otras estructuras, los valores válidos y toda información adicional de cada elemento de la estructura que el usuario que lo confecciona crea que es necesaria.
Las estructuras de datos con un único elemento, es decir, con un único dato, por ser casos particulares, no suelen ser referenciadas como estructuras sino como datos elementales o simplemente datos.
Las estructuras de datos más complejas pueden estar representadas en la organización por un formulario o por algún método de almacenamiento de datos pero también pueden ser conjuntos de datos elementales asociados por ser usados por procedimientos comunes. Por ejemplo, “identificación de factura”, compuesto por tipo y número de factura podría ser una estructura de datos. Existen muchas propuestas para confeccionar un diccionario de datos. Algunos autores proponían en épocas de diccionarios de datos manuales la elaboración de una ficha por cada estructura de datos. En la actualidad, con el advenimiento de la informatización de las oficinas, esas propuestas son obsoletas.
Actualmente existen herramientas automatizadas para confeccionar estos inventarios que contienen metadatos, es decir, datos de los datos de la organización –o de su base de datos- en forma organizada.
Podría este registro, por ejemplo, tratarse de un mero listado ordenado alfabéticamente de cada estructura de datos indicando significado, valores válidos, relación con otros datos y cualquier otro elemento de interés. Tomaremos la notación que utiliza E. YOURDON y que puede ser vista en la Figura 7.

Figura 7

Con esa simbología, conocida como notación algebraica, debe interpretarse que el signo igual (=) significa “Está compuesto de” o “es igual a”, el signo más (+) representa “y”, los corchetes ([]) implican varias alternativas para seleccionar separadas por barras (|) y las llaves ({}) indican conjunto o iteración.
YOURDON también propone usar los paréntesis (()) para indicar opcionalidad, es decir, que lo que encierran puede estar presente o ausente, el signo arroba (@) para marcar los atributos identificadores (este tipo de atributos es tratado más adelante, en la próxima sección) y encerrar entre asteriscos (*) los comentarios.
Otros ejemplos representativos propuestos por YOURDON en el libro de referencia pueden verse en la Figura 8. En el ejemplo b) de esa figura puede verse un caso de dato opcional (domicilio para cuentas). Domicilio del cliente debe entenderse como una estructura que siempre toma valor en “Domicilio de envío” y que puede tomar o no tomar valor en “Domicilio de cuentas”.
Obsérvese que en el ejemplo a) de la Figura 8 se usan los asteriscos para indicar qué significa “Peso”. No todos los lectores obviamente hubieran interpretado que “Peso” era el peso de un paciente al ser admitido en un hospital. Sin embargo, cuando el significado de un dato es definitivamente claro por sí mismo no necesitará un comentario narrativo. Tal podría ser el caso de un dato que se identifique como “Fecha de nacimiento”.
En ese mismo ejemplo a) puede observarse, también, cómo los asteriscos están siendo utilizados para delimitar los valores válidos del atributo peso: Entre 1 y 200 Kg. Algo similar ocurre con el atributo Tratamiento de cortesía o título de la Figura 7 que presenta una lista de valores válidos con la simbología utilizada para presentar alternativas mencionada previamente.
Esos conjuntos de valores válidos de un atributo se denominan Dominio. Este concepto es tratado en la siguiente sección de este capítulo.

Figura 8

Otro uso que puede dársele a los asteriscos es el de indicar un alias para un atributo. Algunas propiedades pueden recibir, en ciertas oportunidades, más de un nombre. Un alias puede definirse en el diccionario de datos de la manera indicada en la Figura 9:

Figura 9

Un caso típico para que existan alias se presenta cuando una entidad participa en más de una relación y juega, en consecuencia, un rol particular en cada relación. Cuando una entidad desarrolla varios papeles suele ser referenciada de acuerdo al papel o función que esté desempeñando. Esto ocurre a menudo en las relaciones que más adelante llamaremos unarias o recursivas.
Otro motivo que puede llevar a la existencia de alias, puede ser que distintos grupos de usuarios utilizan un atributo y lo aluden de manera distinta. Sin embargo, esta situación no es adecuada por lo que debería, en general, preferirse la unificación de los nombres de atributos.
Obsérvese en el ejemplo c) de la misma Figura 8 que la estructura de datos “Solicitud” está compuesta por tres atributos, uno de los cuales, “Artículo”, puede tomar múltiples valores cada vez que el nombre del cliente y el domicilio de envío toman un valor pues se encuentra encerrado entre llaves.
Este tipo de atributo recibe el nombre de multivaluado. Los atributos multivaluados son tratados en la siguiente sección, cuando se analizan los distintos tipos de atributos que pueden encontrarse en una entidad o en una relación.
De este atributo multivaluado sabemos algo más: Puede tomar entre 1 y 10 valores –dijimos que los atributos multivaluados podían tomar múltiples valores- pero no puede tomar ningún valor ni puede tampoco tomar once o más valores. Obsérvese en la Figura 8 que el artículo esta precedido por un 1 y seguido por el número 10 (1{artículo}10)
YOURDON propone incluir en el diccionario los límites de la repetición o iteración de ocurrencias de valores del atributo, si es que esto se conocen.
Para ello, sugiere escribir un número a la izquierda de la llave que abre para indicar el límite inferior, que en este caso es 1, y / o escribir un número a la derecha de la llave que cierra para indicar el límite superior, que en este caso es 10.

CARACTERÍSTICAS ESENCIALES

Tanto las entidades como las relaciones, según vimos al inicio del capítulo, tienen propiedades o atributos comunes que describen sus características de manera fundamental.
Puede decirse, incluso, que las entidades y las relaciones se determinan por medio de los valores que toman sus atributos. Estudiar de qué tipo es cada atributo de una entidad o relación nos permitirá conocer mejor la realidad que analizamos y, en consecuencia, lograremos un modelo más acabado. Pero aún será mejor que eso: Si es nuestra pretensión crear una base de datos, estaremos resolviendo cuestiones de suma utilidad para definir las tablas correspondientes en un gestor de bases de datos. Al momento de definición de la base de datos, se puede ahorrar espacio de almacenamiento y mejorar las operaciones si se selecciona un tipo de datos apropiado para cada uno de los atributos.
Por otra parte, cada propiedad puede admitir valores, para cada entidad particular o relación particular, exclusivamente de un conjunto de valores posibles denominado Dominio.


DOMINIO

El dominio de un atributo es, conceptualmente, el conjunto universal de los valores que puede tomar un atributo. Ese dominio siempre puede establecerse aunque en la práctica no siempre es posible limitar sus valores fehacientemente.
Sin embargo, es muy importante analizar qué valores puede tomar y establecer los valores válidos. Hecho esto, podrá registrarse en el diccionario de datos.
Por ejemplo, si la edad es un atributo relevante para un estudiante, la edad puede tomar su valor de un conjunto de valores válidos que fácilmente –o no tan fácilmente puede circunscribirse: Será mayor o igual que cero y menor o igual que ¿150? Y, quizás, sólo pueda tomar valores enteros. Entonces, ese será su dominio: el conjunto de números enteros comprendidos en el rango [0;150].
Quizás, ese dominio pueda limitarse aún más: Si los estudiantes tienen que ser mayores de edad y no existen antecedentes de estudiantes mayores de 100 años ni se espera la inscripción de un estudiante tan longevo, el dominio podrá restringirse a los números naturales comprendidos en el rango [18;100].
Otro atributo relevante para un estudiante, quizás, sea su nacionalidad. En ese caso, el dominio sí podrá determinarse sin inconvenientes: El conjunto de valores válidos podrá ser definido como aquel al que pertenecen todas las nacionalidades del planeta.
¿Y qué pasa con su apellido? Es exiguo lo que podemos decir acerca del conjunto de valores válidos para un apellido: El dominio para el apellido será el conjunto de todas las cadenas de caracteres compuestas por una o más letras del alfabeto (podríamos suponer que no más de 30), con algunos caracteres adicionales tales como el espacio en blanco o el apóstrofo (').
Sin embargo, podríamos plantearnos, si un apellido puede ser, por ejemplo, Hfgklmfwpqs, que no tiene vocales, eioieoieouuua que no tiene consonantes o Akkkkkkkkki donde hay nueve letras k una a continuación de la otra. Quizás, lleguemos a la conclusión de que esos no son apellidos válidos pues no son habituales esas combinaciones de letras en nuestra lengua, o acaso consideremos que sí pueden ser apellidos válidos porque en ruso o en checoslovaco, por ejemplo, pueden ser combinaciones corrientes; será muy difícil encontrar reglas que restrinjan adecuadamente los valores válidos de un apellido.
En consecuencia, tendremos que conformarnos con el dominio que describimos anteriormente, lo cual no es poco: Bastante más sabremos del apellido o de cualquier otro atributo cuando analicemos su dominio que cuando no lo hagamos.

TIPOS DE ATRIBUTOS, PROPIEDADES O CARACTERÍSTICAS

Atributos que califican y Atributos que identifican
Según ya comentamos, los atributos son piezas de información que describen o califican una entidad. Algunos de esos atributos sirven, además, para identificar o distinguir a cada entidad particular o individuo.
En consecuencia podemos distinguir los atributos calificativos estrictos de los atributos identificativos. Estos últimos son llamados generalmente atributos clave.
Por ejemplo, el número de legajo de un chofer de micros de una empresa transportista es un atributo que, además de calificarlo, lo identifica pues dado un valor de número de legajo, sólo existe un chofer que lo posee. Sin embargo, su nombre y apellido es un atributo que sólo lo califica. ¿Porqué no lo identifica? Pues, porque cuando nombramos al estudiante Juan Pérez, ¿A quién nos referimos? ¿Al que tiene el legajo 1.456, o al que tiene el legajo 2.658?
Una entidad puede, en ocasiones, ser identificado por más de un atributo. Al chofer, quizás lo identifiquen también el número de su cédula de conductor, su CUIT, su DNI...
¿Qué pasa si no todos los choferes tienen DNI? Entonces, el DNI sencillamente no servirá como un atributo que identifique a los estudiantes.
Por otra parte, algunos atributos pueden asociarse para identificar una entidad: ¿Qué pasa si para un chofer, asociamos los atributos “tipo de documento” y “número de documento”?
Tenemos que suponer que todo chofer tiene, al menos, un documento pues si está indocumentado no será legítimo que la empresa lo contrate como empleado.
El problema es que ese documento puede ser una Cédula de Identidad, una Libreta Cívica, una Libreta de Enrolamiento, un Documento Nacional de Identidad, un Documento Único o, incluso, un pasaporte. Entonces, dado un tipo de documento y un número de documento, ¡Identificaremos a un chofer!

Atributos Simples y Atributos Compuestos
Esa asociación de atributos podría generar –no necesariamente será así—, un nuevo atributo que recibirá el nombre de atributo compuesto.
Este nuevo atributo podría denominarse sencillamente “Documento” pero deberíamos tener muy en claro que Documento significaría, en ese caso, en realidad, un tipo de documento y un número de documento.
Y hablando de “indocumentados”, esa situación que está implícita en el atributo documento (hay un tipo y un número) y que no es en sí mismo obvia, debe ser documentada para que todos los usuarios del modelo entiendan exactamente lo mismo. La herramienta típica para documentar el significado asociado a un dato, en particular cuando ese significado no es obvio, es el Diccionario de Datos que se trató en la sección anterior de este capítulo. La definición en el diccionario de datos para el atributo compuesto Documento se muestra en la Figura 10.


Figura 10

Una adecuada identificación no es el único motivo por el que podemos pensar en un atributo compuesto. Podría suceder que una colección de atributos sea procesada reiteradamente en forma colectiva y entonces puede ser deseable generar también para esas aplicaciones un atributo compuesto que los conglomere.
Por ejemplo, puede ser deseable tener un atributo denominado Datos del cliente, que conglomere un subconjunto de los atributos de la entidad Cliente que suelen utilizarse en forma conjunta. Por ejemplo, Número de cliente, Nombre y apellido, Domicilio, Código postal, Localidad y Provincia.


Figura 11

Al momento de definir la estructura de la base de datos, el atributo compuesto Datos del cliente no será utilizado. Sin embargo, su existencia podrá simplificar la documentación del diseño, pues cada vez que deban incluirse los atributos Número del cliente, Nombre y apellido, Domicilio, Código postal, Localidad y Provincia, se podrá indicar, en reemplazo de dichos atributos, al atributo Datos del cliente.

Atributos Singulares y Atributos Multivaluados

Los atributos de una entidad toman generalmente valores singulares para esa entidad. Por ejemplo, el domicilio de un cliente, es uno sólo. Pero ¿qué pasa si tiene un domicilio para la entrega de mercadería y otro para el cobro de facturas?
Entonces, tendrá un “domicilio de entrega” y tendrá un “domicilio de cobranzas” pero cada uno de ellos, será, por lo regular, uno único.
Sin embargo, algunos atributos efectivamente pueden tomar más de un valor. En ese caso, tal como ya se comentó en la sección anterior, se dice que esos son atributos multivaluados y, a diferencia de los atributos singulares, pueden tomar más de un valor. Para ser más específica, pueden tomar entre m y n valores, donde tanto m como n pueden ser cantidades conocidas.
Los atributos multivaluados, dado que en lugar de tomar un valor toman un conjunto de valores, se indican entre llaves ({}) Por ejemplo, supongamos que detectamos que un cliente tiene por atributo su número de teléfono. Seguimos indagando y llegamos a la conclusión que, en realidad, tiene o puede tener, varios teléfonos. Incluso puede no tener ningún teléfono.
En ese caso, el número de teléfono puede considerarse un atributo multivaluado y expresarse de esta manera {teléfono}.
Y ¿Cuántos valores puede tomar el atributo teléfono? Puede tomar entre 0 y n valores.
N, ¿no es conocido? Posiblemente no lo sea, pero podríamos suponer que si tiene más de 5 teléfonos, no nos interesan más que 5 de ellos.
Entonces, ¿sabemos cuántos valores puede tomar el atributo multivaluado {teléfono}? Si nos interesan no más de 5 teléfonos de un cliente, entonces, el atributo teléfono puede tomar entre 0 y 5 valores. Si nos interesan todos los teléfonos que pudiera tener, el atributo teléfono puede tomar entre 0 y n valores.
La pregunta, podría ser ahora, cómo decidir si nos interesan 5 o más teléfonos de un cliente. La respuesta no es sencilla. Hay muchos “depende” involucrados.
Depende de qué tan crítico sea tener que comunicarnos con ese cliente o qué tan crítico sea el tiempo de espera, cuál es la probabilidad de que fallen o estén ocupados al mismo tiempo los 5 teléfonos de un cliente, qué costo puede tener reservar espacio de almacenamiento para n (¿100?) teléfonos de cada uno de nuestros clientes, cuántos de nuestros clientes tienen más de 5 teléfonos (o más de 1), cuánto puede molestar a nuestros clientes tener que darnos todos y cada uno de sus teléfonos, cuánto tiempo pierde la recepcionista en tomar nota de cada uno de todos los teléfonos de cada cliente, etc.
El etcétera con que cierra el extenso párrafo anterior implica tantos coordinantes como la imaginación nos dé para pensar qué inconvenientes o trastornos pueda ocasionarnos el encapricharnos con que nos interesan todos los teléfonos de un cliente.
Pero hagamos otro planteo para el atributo teléfono de un cliente. Pensemos que se llama teléfonos y que un valor válido para ese atributo es “4921704/5”. ¿Qué es lo que ocurre entonces?
Entonces, teléfonos es un atributo singular que toma un único valor (4921704/5) pero, a diferencia de {teléfono} que tomaría dos valores (primer valor 4921704 y segundo valor 4921705) no nos permitirá, a posteriori, manejar como un dato el primer valor y como otro dato al segundo valor.
En el caso analizado, los datos (uno singular, el otro multivaluado) deberán procesarse de manera distinta para que el usuario pueda obtener la misma información, o sea, los dos números de teléfono.
En algunas ocasiones, puede ser muy difícil procesar en forma independiente valores que están representados en un atributo singular cuya semántica, en realidad, oculta múltiples valores. Incluso, puede llegar a ser imposible.
Imaginemos, entonces, otra situación: Supongamos que encontramos en el contestador automático del teléfono un mensaje que solicita que nos comuniquemos al teléfono 492-1705 ¿Podríamos averiguar a qué cliente pertenece? Peor aún: ¿Qué pasaría si quisiéramos hacer telemarketing y programar una computadora para que llame a cada cliente a su número de teléfono?
El atributo singular “teléfonos” nos estaría jugando una mala pasada pues limitaría la información obtenible del modelo, limitando su funcionalidad.
En consecuencia, reconocer a un atributo como multivaluado, puede ser conveniente en ocasiones en las que sabemos que los valores que puede tomar generarán información en forma independiente una de otra.
Tomemos otro ejemplo. A un video club le interesan ciertos datos de las películas porque con esos datos brinda información a los clientes para que puedan elegir una película.
Uno de los datos que le interesan son los directores que dirigen cada película. Respecto de los directores, la única información que brinda a sus clientes es esa: Para una película qué directores la dirigieron.
¿Necesita o le conviene pensar a los directores de las películas como un atributo multivaluado? La respuesta es No.
Si Directores, es simplemente un atributo singular, que toma como valor una lista de nombres de directores tiene su problema resuelto y a bajo costo.
Supongamos que otra información que le brinda a sus clientes es qué actores tienen papel protagónico en cada película.
Podríamos suponer que será nuevamente adecuada la solución que anteriormente aplicamos a los directores de películas. Sin embargo, también brinda información adicional: Qué películas tienen a un actor en particular en papel protagónico.
Entonces, ya no es conveniente para las películas que un atributo “actores” tome como valor la lista de actores protagónicos que tiene. Conviene pensar que las películas tienen un atributo {actor protagónico} que es multivaluado y que puede tomar más de un valor que pueden ser procesados en forma individual.
Por otra parte, no todas las aplicaciones automatizadas soportan un modelo Entidad-Relación con atributos multivaluados así como tampoco con atributos compuestos. Sin embargo, al momento de analizar una realidad y confeccionar un modelo Entidad-Relación que la represente pueden ser herramientas muy útiles para comprender el entorno.

Atributos Requeridos y Atributos Opcionales

Acaso se detecte en esta instancia de análisis de los datos del ambiente que algunos atributos de las entidades o de las relaciones pueden, en ocasiones, no tomar valor para algunas entidades particulares. Un ejemplo puede ser el número de fax. Esa propiedad no aplicable a algunas entidades particulares será, entonces, un atributo opcional. Estas propiedades, en caso de ser definidas como campos en una base de datos, deben tener prevista la posibilidad de tomar un valor nulo.
La existencia de atributos optativos puede ser un indicio de que, en realidad, el objeto detectado como entidad sea un subtipo de alguna otra entidad. Los conceptos de subtipo y supertipo son tratados en la próxima sección.
Algunos atributos requeridos pueden, en el momento de carga de datos, ser desconocidos. Que el valor de un atributo de una entidad o relación sea desconocido implica que existe y momentáneamente no tomará valor pero no supone que ese atributo sea inaplicable para una entidad en particular.

Atributos Derivados

Algunos autores, como Elmasri, 1994, y Date, 1990, mencionan a los atributos derivados como aquellos que surgen de otras propiedades.
Por ejemplo, el atributo Edad puede ser derivado de la propiedad Fecha de Nacimiento, si es que ésta existe, y el valor de la propiedad Saldo puede ser obtenido con un cálculo aritmético. Sin embargo, es mi opinión que, en realidad, estos no son atributos por mediar para su obtención algún tipo de procesamiento.
Creo que, en esta instancia, los atributos calificativos para los que se detecta que pueden ser obtenidos de alguna manera en base a otros datos, deben ser considerados información y no propiamente datos.
En consecuencia, no deben, en general, ser incluidos en el análisis del modelo de datos, sino no como un requerimiento más que debe satisfacer el modelo que se intenta diseñar.
En todo caso, puesto que en este momento se han analizado —sino no se sabría que surgen de algún cálculo o procesamiento—, pueden ser incluidos en el diccionario de datos preliminar con toda la información que sobre ellos se haya recabado, tal como vimos en una sección anterior de este capítulo.
Hay, sin embargo, casos para los que puede preferirse la inclusión del dato derivado en el modelo. Al momento del diseño de la base de datos, la existencia de estos atributos puede mejorar el rendimiento al momento de la obtención de información.
Tal es el caso del stock de un artículo. Repetidamente se requiere esa información (la cantidad que se dispone de un artículo) y el cálculo es muy complejo pues para obtener a cuánto asciende el stock hay que hacer una importante cantidad de sumas y restas.
Otro caso similar es el del saldo de la cuenta corriente de un cliente. Esa información, que debe tenerse exacta y oportuna, también puede requerir cuantiosas sumas y restas de datos que deben rastrearse por la base de datos, si es que no se almacena el dato calculado.
Como contrapartida a la mejora en el rendimiento al momento de obtener información, los datos derivados hacen más complejas las bases de datos que deben incluir en su seno la definición o el código que realice el cálculo.
Nada dice YOURDON de cómo indicar en el diccionario de datos si un atributo es derivado. Sin embargo, en caso de que el lector no comparta mi apreciación -los atributos derivados no forman parte de los datos sino que son propiamente información- o si se presume que el atributo derivado debe, por algún motivo de peso, permanecer de todos modos en el modelo, se podrán utilizar los asteriscos para indicar de qué manera se deriva.
Resumiendo, los atributos de una entidad pueden ser:

  • Calificativos o Claves. Todos los atributos son calificativos pero algunos de ellos son, además, identificadores porque permiten reconocer a cada entidad particular en forma unívoca y por eso de los indica como atributos clave. Cuando es difícil encontrar uno o más atributos que identifican una entidad, se suele inventar un atributo que numera a cada entidad (¿qué son, sino un invento para identificar, los números de legajo, los números de artículo, los documentos de identidad?)
  • Simples o Compuestos. Los primeros, a diferencia de los segundos, no pueden ser divididos en subpartes menores. Por ejemplo, Nombre puede ser un atributo simple y Dirección puede ser un atributo compuesto si su estructura se puede dividir en Provincia, Localidad, Calle, Número, Piso y Departamento. El valor de un atributo compuesto es la concatenación de los valores de los atributos simples que lo constituyen.
  • Singulares o Multivaluados. Los atributos son singulares cuando una entidad en individual toma un valor único para esa propiedad y son multivaluados cuando permiten grupos repetitivos de valores para un miembro de la entidad. Por ejemplo, la propiedad Nombre del cónyuge es singular, mientras que Nombre de los hijos puede ser multivaluada.
  • Requeridos u Opcionales. Los atributos son requeridos si, por lo regular, tomarán algún valor y sólo ocurrirá lo inverso en forma momentánea y por desconocimiento; en cuanto a los atributos opcionales son aquellos que pueden tomar o no tomar valor, dependiendo de qué entidad en particular o relación se trate.
  • Derivados. Son atributos calculados u obtenidos mediante algún procedimiento a partir de otros datos almacenados. A criterio personal se trata más bien de información que dato aunque en algunas ocasiones puede ser importante considerarlos de igual manera que a los atributos no derivados.



TIPOS Y OCURRENCIAS DE ENTIDADES Y RELACIONES

Hemos estado hablando de entidades. Vamos a diferenciar, ahora, los tipos de entidades de las entidades particulares.
Las entidades se agrupan en tipos de entidades a veces llamados clases de entidades cuando tienen propiedades o atributos que son comunes a todos los individuos que pertenecen a ese tipo.
Un tipo de entidad es la forma general o descripción de un ente mientras que una ocurrencia o instancia de un tipo de entidad es la representación de una entidad particular.
Hay múltiples ocurrencias de una entidad de un tipo de entidad. Sin embargo, la palabra entidad suele usarse en modo indistinto para referenciar a uno u otro concepto.
Por ejemplo, para una organización, en el área de Recursos Humanos, seguramente existirá el tipo de entidad Empleado. Este tipo de entidad posiblemente tendrá algunas cientos de instancias que se podrán identificar.
Así, Juan Pérez, con DNI diecinueve millones trescientos cincuenta y..., es una de esas ocurrencias, al igual que José Rodríguez, con DNI dieciocho millones doscientos treinta y...
Tanto Juan Pérez como José Rodríguez, por ser del tipo empleados, comparten características esenciales: Ambos tienen un nombre y apellido, un DNI, un domicilio, etc. y ambos pueden ser identificados.
También puede diferenciarse, como en el caso de las entidades, a un tipo de relación de una ocurrencia de relación, aún cuando se hace alusión a cualquiera de los dos conceptos cuando se dice “relación”.
Por ejemplo, un Artista puede asociarse con una Obra de Arte en el tipo de relación “Crea”. Una ocurrencia o instancia de esta asociación puede ser, Michelangelo crea David.
Cada instancia u ocurrencia de una relación representa el hecho de que una instancia de una entidad participante de la relación se vincula de una manera especial con una instancia de otra entidad participante, en el ambiente que se estudia.
Puede verse en la Figura 12 que un tipo de relación (Crea, en este ejemplo) entre n tipos de entidades (2 en este caso, Artista y Obra de Arte) define un conjunto de asociaciones entre entidades de los tipos dados. Cada instancia de la relación Crea es una asociación de las entidades Artista y Obra de Arte.


Figura 12

CLASIFICACIÓN DE LAS ENTIDADES

Subtipos y Supertipos

Las entidades, de acuerdo a lo que hemos comentado en el apartado anterior, se agrupan en tipos de entidades cuando comparten atributos en común. Toda entidad pertenece, al menos, a un tipo de entidad y puede simultáneamente pertenecer a varios tipos. Supongamos que en una organización se tiene un proveedor –sea ese proveedor José López, identificado quizás por su CUIT— que al mismo tiempo es un cliente. José López es, entonces, una entidad que pertenece a dos tipos de entidades.
Pero tomemos otro caso: supongamos que una instancia del tipo de entidad Clientes, digamos nuevamente José López, participa, también, del tipo de entidad Deudores. Este caso puede que no sea análogo al anterior ¿Porqué?
Esta situación no es equivalente a la anterior si sucede que toda instancia del tipo de entidad Deudores es inicialmente un cliente.
Cuando todas las instancias de un tipo de entidad pertenecen a otra entidad, se dice que la primera es un subtipo o subclase de la segunda y la segunda es el supertipo o superclase de la primera. Existe una relación con la forma “es un” entre los subtipos y los supertipos.
Todas las propiedades de un tipo de entidad se aplican a sus subtipos , pero no lo contrario. Los subtipos pueden, a su vez, ser tipos de otros subtipos, creándose jerarquías de tipos de entidades.
En el ejemplo anterior, la entidad Deudores, es en realidad, un subtipo de clientes, pues un deudor siempre es primitivamente un cliente. Dicho de otra manera, Clientes es el supertipo de Deudores.
Los subtipos y supertipos se agregaron al modelo Entidad-relación original en forma posterior y son parte de lo que se denomina modelo Entidad-Relación ampliado o extendido.
En la Figura 13 puede verse otro ejemplo de jerarquía de entidades y la simbología propuesta para su representación gráfica.

Figura 13

En el caso de los transportes presentado en dicha figura, todas las entidades participan de los atributos patente, alto, ancho, largo, marca, año y modelo. Sin embargo, sólo de los autos interesa el tipo, y los accesorios que incluye, sólo de los camiones y los chasis cabinas es importante qué peso máximo tienen autorizado y únicamente para las combis y los furgones es relevante el número de plazas que tienen y los servicios que brindan.
Que algunos atributos no sean aplicables a todas las instancias de un tipo de entidad no es el único motivo para detectar subtipos en un modelo de datos. También puede ser importante esta distinción cuando sólo algunas instancias de una entidad participan de alguna relación con otras entidades.
Por ejemplo, supongamos que a los socios de un club se les ofrece cursos sobre temas de interés. Algunos de esos cursos son dados con modalidad a distancia y requieren del uso del correo electrónico. Sólo podrán, en ese caso, inscribirse en un curso a distancia aquellos socios que tienen correo electrónico, mientras que de los cursos presenciales todos los socios pueden participar.
Este caso está representado en el modelo de la Figura 14.


Figura 14

Especialización

Los subtipos que se distinguieron para la entidad transporte configuran una especialización de dicha entidad pues están definidos en función de una característica (la funcionalidad) del transporte.
Podría ser necesario o conveniente para una entidad, la distinción de más de una especialización. Por ejemplo, en el caso del transporte que tomamos inicialmente, podría existir, tal como se presenta en la Figura 15, otra especialización basada en el tipo de combustible que utiliza (nafta, gas oil, gas) y se crearían, entonces, otros subtipos.

Figura 15

Una ocurrencia de la entidad podría pertenecer a más de un subtipo, incluso dentro de una misma especialización. Para algunas especializaciones, una instancia de una entidad puede tener que pertenecer necesariamente a un subtipo y para otras no.
Nótese que en el caso de los socios del club, la entidad Socio sólo tiene un subtipo. Una especialización puede consistir, en ocasiones, en la detección de un único subtipo al que una instancia del supertipo puede pertenecer o no.

Subclases Compartidas

No siempre una entidad subtipo mantiene relación con un único supertipo. Puede suceder que un subtipo, para existir deba ser de más de un “tipo”. Por ejemplo, en el caso del transporte, supongamos que algunas unidades son utilizadas como “vehículos de alquiler”. Las reglas del negocio establecen que sólo se alquilan las combis y los furgones que son de tipo diesel. En la Figura 16 se muestra un diseño para representar este contexto.


Figura 16

Vehículos de alquiler es una subclase compartida. Si una instancia de transporte es un vehículo de alquiler, también debe existir como combi/furgón y como transporte Diesel.

Categorías

Las subclases compartidas no son los únicos casos de subtipos que dependen de más de un supertipo. En Elmasri, 1995, se tratan las categorías, que son subtipos cuyas instancias, para existir, deben ser participantes de, al menos, uno de los supertipos de los que depende, y no necesariamente de todos como en el caso planteado precedentemente.
Podría por ejemplo, crearse una categoría “vehículos económicos” cuyas instancias tienen que existir, o bien como transportes Diesel, o bien como transportes gasoleros, situación está que está representada en el DER de la Figura 17.
Una categoría podría asociar, incluso supertipos que no configuran, tal como ocurre en este caso, la misma entidad (los diesel y los gasoleros son ambos transportes). Así, podría crearse una categoría “Bienes” cuyos supertipos sean, por ejemplo, transportes e inmuebles.

Figura 17

Entidades Fuertes y Entidades Débiles

Hemos visto que para el modelo Entidad-relación una entidad es una cosa que puede ser clara y unívocamente identificable. Pero no todas las entidades son del mismo tipo: las entidades pueden ser fuertes o débiles.
Una entidad débil, también llamada tipo de objeto asociativo, (TOA), es una entidad que, para existir, depende de alguna otra entidad. Es decir, sólo puede existir si otra entidad existe.
Una entidad fuerte, por su parte, es una entidad que existe por sí misma. Suele llamarse entidad padre a la entidad fuerte y entidad hijo a la entidad débil.
Hay dos tipos de entidades débiles:

  • Las entidades que dependen lógicamente de la existencia de otra entidad, sin que esto afecte a su identificación (tienen dependencia lógica).

Por ejemplo, en una compañía aseguradora, una entidad Siniestro, identificada por un número de siniestro, puede depender para existir de una entidad denominada Automóvil siendo, en consecuencia una entidad débil con dependencia lógica, y ...

  • ... las que no sólo dependen de otra entidad sino que, además, son determinables a partir de la identificación de la otra entidad, es decir, tienen dependencia de identificación.

Por ejemplo, en un sanatorio, una entidad denominada Tratamiento, identificada por un número de historia clínica de un paciente y una fecha, puede ser una entidad débil con dependencia de identificación, dependiente de una entidad denominada Paciente. Las entidades débiles se suelen representar con rectángulos dobles y pueden vincularse a los rombos por medio de una flecha que los apunta o simplemente con rectángulos con esquinas redondeadas. Pueden verse en el Apéndice B algunas simbologías propuestas para representar este tipo de entidades.
Veamos otro ejemplo: Se han detectado en una organización pública, tal como puede verse en la Figura 18, las entidades Área y Publicación interna, vinculadas por una relación denominada Realiza. La entidad Área tendrá entre sus atributos el Código (clave primaria), el nombre, la dirección y el teléfono. La entidad Publicación interna, por su parte, tendrá como atributos el nombre (clave primaria), la fecha de publicación, su autor, etc.


Figura 18

Si los nombre de una publicación no pueden repetirse, nombre de la publicación es una buena clave candidata para la entidad débil. Sin embargo, una publicación interna no puede existir sin un área que la haya publicado. En consecuencia, Publicación interna sería una entidad débil que depende lógicamente de la entidad Área.
Si, en cambio, la identificación de la publicación incluye el nombre -o el código- del área que la creó (por ejemplo, Balance Tesorería, Balance área de Personal, Presupuesto Contaduría, etc.) las publicaciones internas serían entidades débiles pero con dependencia de identificación de la entidad Área.
Una entidad débil que depende lógicamente de otra entidad debe ser detectada en el momento del análisis del modelo de datos. La existencia de una instancia de entidad débil implica la existencia de una instancia de la otra entidad y ninguna aplicación debería provocar una entidad débil sin un padre ni permitir que un padre se elimine sin que al mismo tiempo desaparezcan sus hijos.
Algunas herramientas CASE no soportan en sus diagramas Entidad-Relación la distinción de entidad débil para una entidad con dependencia lógica. Sin embargo, en el momento del análisis deben distinguirse pues será muy útil conocer esa condición de la entidad cuando se diseñe la base de datos pues permitirá establecer restricciones apropiadas a dicha condición.
Analicemos a continuación otro caso. Un profesional debe completar anualmente, en su caja de seguridad social, una ficha con datos de su situación actual por cada actividad que realiza. En la Figura 19 puede observarse el DER que representa a la situación con la simbología propuesta por P. Chen y utilizada por Yourdon, 1993, en el diagrama a). En el diagrama b) se representa al mismo caso con la simbología propuesta por J. Martin.


Figura 19

Los atributos de la entidad Profesional serán, su legajo (atributo clave o identificativo), su nombre, su dirección, su teléfono, etc. En el caso de la entidad Actividad, sus atributos serán su código, su nombre, sus características, etc.
En cuanto a la entidad Situación, sus atributos clave podrían ser el legajo del profesional, el código de la actividad y el año; sus atributos calificativos, serán, por supuesto, todo el resto de los datos que se recaban con al confeccionar la ficha.
La entidad Situación deberá tener, al menos, los atributos que identifican a cada uno de sus padres. Estos atributos no necesariamente formarán parte de la identificación de cada ficha que registra la situación de los profesionales en sus actividades.

CLASES DE RELACIONES

Hablaremos ahora de las relaciones que se verifican entre las entidades. Así como estas no son todas del mismo tipo, veremos que también existen distintas categorías o clasificaciones de relaciones.

Grado de las relaciones

Una relación puede involucrar a muchas entidades; Se llama grado de la relación al número de entidades que intervienen en la asociación. En general, la mayoría de las relaciones son binarias o de grado 2, aunque existen relaciones de distintos grados.
En el ejemplo a) de la Figura 20, “cliente solicita mercadería” es una relación binaria pues intervienen 2 entidades en la relación: cliente y mercadería; en cambio en la relación del ejemplo b) de la misma Figura, “médico receta medicamentos a un paciente” intervienen 3 entidades: medico, medicamento y paciente, por lo que esta relación es ternaria o de grado 3.


Figura 20

También existen relaciones que vinculan a una entidad consigo misma. En ese caso, el grado es 1 pues se tiene una relación unaria que es referenciada en ocasiones como relación recursiva. Puede verse en el ejemplo c) de la Figura 20 un caso de relación recursiva.

Restricciones Estructurales

En Elmasri/Navathe, 1994, se distinguen algunas restricciones estructurales para los tipos de relaciones que nos permitirá hacer ciertas clasificaciones muy útiles para los fines que perseguimos.
Las principales restricciones que mencionan los autores del libro de referencia son la Participación, que establece para una instancia de entidad si debe necesariamente o no participar de la relación, y la Cardinalidad, que especifica el número de ocurrencias de las entidades que pueden participar de una instancia de relación.
El contexto, las políticas de una organización o las reglas de negocio pueden determinar la necesidad de establecer para una relación una restricción estructural más específica aún que la cardinalidad y la participación: En algunas situaciones puede suceder que una entidad pueda participar de una relación con un mínimo de instancias, con un máximo de instancias o con una cantidad de instancias que se encuentre entre en un rango de mínima y máxima cantidad de instancias.
Por ejemplo, sea el caso en que una empresa pone en oferta ciertos artículos a un precio muy bajo. Los clientes, para poder participar de la oferta deben elegir al menos 2 artículos pero no pueden llevar más de 5. En la Figura 18 puede verse una notación para la situación propuesta.

Figura 21

Participación: Relaciones parciales y relaciones totales

Si cada instancia de un tipo de entidad de una relación participa en, al menos, una instancia de la relación, entonces, la entidad tiene una participación total de la relación y se dice que, esa entidad, tiene una relación total; si no necesariamente todas las instancias de la entidad participan de la relación, entonces se trata de una relación parcial.
Por ejemplo, en la Figura 22, Socio participará totalmente de la relación “Es responsable” cuando el Diagrama Entidad-Relación represente a los datos de un Jardín de Infantes dependiente de un sindicato pero seguramente tendrá una participación parcial si representa a los mismos socios para los usuarios del Departamento de Socios del sindicato.

Figura 22

El autor de referencia para las restricciones estructurales, cuando quiere distinguir en el diagrama una participación total de una parcial, dibuja la línea que conecta una entidad y una relación doble para el primer caso y simple para el segundo. Al analizar una notación para la cardinalidad, veremos otra simbología para registrar la participación en el diagrama.
Todas las entidades débiles presentan una relación de participación total con sus entidades padre. Las especializaciones, por su parte, determinarán si la relación “es un” que existe entre los subtipos y los supertipos es completa o parcial. Las especializaciones completas requieren que cada instancia de supertipo sea, a demás, instancia de, al menos, un subtipo.

Cardinalidad de las relaciones:

Las relaciones tienen otra restricción que limita a una instancia de entidad en las posibles combinaciones en las que puede participar de la relación. Esta restricción recibe el nombre de Cardinalidad y es determinada exclusivamente por el contexto al que representa la relación.
En consecuencia, la cardinalidad indica el número de veces en la que cada entidad relacionada puede participar de la relación. Para implementar una base de datos eficientemente es conveniente clasificar las relaciones de acuerdo a su cardinalidad.
Las relaciones entre entidades pueden ser de 1 en 1, de 1 en n, y de m en n según la cantidad de instancias de cada entidad que intervienen en la relación.
La cardinalidad más simple y rara que se presenta en la asociación de dos entidades es la de 1 en 1, que indica que para cada instancia de una entidad, hay, a lo sumo, una instancia asociada de la otra entidad.
Por ejemplo en el caso en el que Mujer es esposa de Hombre en una sociedad monogámica (María Rodríguez es la esposa de José Fernández), se tiene una relación del tipo 1 en 1.
Obsérvese en la Figura 23 que la cardinalidad para esta relación del tipo 1 en 1 se representa en el diagrama Entidad-Relación mediante un número 1 al lado de cada entidad. Debe leerse en ese diagrama que la entidad Mujer participa de la relación “es cónyuge” en una única oportunidad y que la entidad Hombre también participa de la relación “es cónyuge” con una única ocurrencia.


Figura 23

Esta notación utilizada para indicar la cardinalidad también permite introducir en el diagrama si se trata de una relación total o parcial. Si bien el número 1 ha sido utilizado por algunos autores para indicar tanto una relación total como una relación parcial, cuando se quiere hacer un análisis estricto como el que nos interesa a nosotros, puede indicarse de la manera escrita en la Figura 24 la participación parcial de las entidades en la relación.


Figura 24
Más comunes que las anteriores son las relaciones de 1 en n, también conocidas como relaciones de uno a muchos.
En una relación de 1 en n, una instancia de entidad se puede asociar con cero o más instancias de la otra entidad en una relación parcial o una instancia de entidad se asocia con una o más instancias de la otra entidad si se trata de una relación total.
Puede verse en la Figura 25 el caso Hombre es padre de Hijo, (José Fernández es padre de Juan, Pedro y Mercedes) en el que se presenta una relación del tipo 1 en n.

Figura 25

En el ejemplo visto de Hombre es padre de Hijo, puede aplicarse también la notación que permite distinguir entre relaciones totales y relaciones parciales antecediendo a la n y/o al 1 un número 0.
Recuérdese que tanto la cardinalidad como la participación de las entidades en la relación están dadas estrictamente por el contexto y, en consecuencia, no puede predecirse nada acerca de ellas si no es en base a las posibilidades que pueden darse en la realidad.
Por lo tanto, debemos hacernos estas dos preguntas si deseamos analizar la participación de las entidades en la relación: a) ¿Todos los hombres tienen hijos?
b) ¿Todos los hijos tienen padre?
La respuesta para a) puede ser Sí o puede ser No. La respuesta para b) puede ser Sí o puede ser No. ¿Por qué? Recordemos el ejemplo visto cuando analizamos en esta sección las relaciones parciales y las relaciones totales: “Socio es responsable de niño”. Este es un caso similar.
Si Hombres es una entidad detectada en una repartición pública abocada al registro de personas, ¡No puede haber dudas de que no todos los hombres tienen hijos!. En ese caso, Hombres debe participar parcialmente de la relación “es padre”.
Sin embargo, si Hombres fuera una entidad detectada en un club de padres... quizás, y sólo quizás, Hombre pudiera ser una entidad que siempre participa de la relación.
Analicemos la pregunta b), ¿Todos los hijos tienen padre?: En la repartición pública abocada al registro de personas es obvio que, por infortunio, no todos los hijos tienen padre. Pero pensemos nuevamente cual será el caso de una entidad Hijo, si es detectada en el Departamento de Servicios Sociales de un club masculino: Si existe un hijo, es porque es hijo de un socio, que, además, es hombre...
Por lo tanto, esta, al igual de la mayoría de las relaciones, puede ser para las entidades una relación total o parcial, dependiendo exclusivamente del contexto.
Son también habituales las relaciones de m en n de igual forma conocidas como relaciones de muchos a muchos, donde no hay restricciones para la cantidad de instancias de las entidades que pueden participar de la relación.
En el caso Hijos realizan Estudios (Juan, Luis, Ana, Pedro y Mercedes estudian inglés, computación, lengua y matemática) presentado en la Figura 26 puede verse una relación de m en n.
Este tipo de relaciones sólo es soportado con dificultades por algunos modelos de diseño de base de datos ya que se trata de relaciones complejas. Sin embargo, toda relación del tipo m en n puede verse como relaciones del tipo 1 en n. Esta situación será analizada más adelante, en el Capítulo V.
En el Apéndice B puede verse la simbología propuesta por J. Martin para registrar en un diagrama Entidad-Relación la cardinalidad y la participación de las entidades en las relaciones que las asocian.


Figura 26

Un modo práctico de analizar la cardinalidad de una relación

Una manera sencilla de determinar la cardinalidad de una relación es analizar el contexto en el que se desarrolla. Primero desde el punto de vista de una ocurrencia de entidad y luego desde el punto de vista de una ocurrencia de la otra entidad, en forma análoga a cuando, en esta misma sección, nos hicimos las preguntas a) y b) para investigar si la relación “Hombre es padre de Hijo” era o no completa.
Tomemos un caso nuevo a modo de ejemplo. Puede verse en la Figura 27 que “Ciudad es administrada por Municipio”. Hagamos, entonces, las preguntas adecuadas que indaguen acerca de lo que ocurre con una instancia en particular de cada entidad: a) Dada una ciudad, ¿Cuántos municipios la pueden administrar?
b) Dado un municipio, ¿Cuántas ciudades puede administrar?


Figura 27

Podemos decir, para responder a la primera pregunta, sin temor a equivocarnos, aún cuando esto es exclusivamente contextual, que, dada una ciudad, uno y sólo un municipio la administra y siempre hay un municipio para administrar una ciudad.
Para responder a la pregunta b), podemos decir que, dado un municipio, al menos una ciudad administrará pero no necesariamente una, o, lo que es lo mismo, podemos decir que administrará n ciudades con n distinto de 0.
Hasta esta instancia, el único problema es entender ciertamente cuál es el contexto para la relación. ¿Ocurre efectivamente siempre y en toda circunstancia lo que respondimos?
Si estamos de acuerdo con que respondimos acorde al contexto que rodea la relación, entonces, podemos continuar. Si no lo estuviéramos, lo que tendríamos que hacer es volver a escrutar el contexto analizando todas las posibles alternativas y modificar adecuadamente las respuestas.
Anotemos sobre el diagrama, seguros de las respuestas para ambas preguntas, el resultado de nuestro análisis: Puede verse en la parte superior de la Figura 28 una notación para la primera respuesta que dice que dada 1 ciudad habrá siempre 1 municipio para administrarla.
En la parte inferior de la misma figura puede verse, leyendo de derecha a izquierda, una notación para indicar que dado 1 municipio habrá n (con n distinto de 0) ciudades para administrar .

Figura 28

Veamos ahora como interpretamos lo que hemos anotado:
A) Si consideramos a la entidad Ciudad, esta puede participar en 1 ó en n ocurrencias de la relación, pero dado que n es cualquier número entero positivo distinto de 0 también puede ser igual a 1, entonces, puede decirse que Ciudad participa de la relación con n ocurrencias.
B) Por su parte, Municipio sólo puede participar de la relación en 1 ocurrencia. C) En consecuencia, La relación es de 1 en n.
Tomemos otro ejemplo. Sea la relación “Planta ornamental sufre Plagas” que se presenta en la Figura 29 ¿Cuál es la cardinalidad de la relación?


Figura 29

Realicemos las preguntas apropiadas para investigar acerca de lo que le puede pasar a una ocurrencia en particular de cada una de las dos entidades involucradas en la relación:
a) Dada una planta ornamental, ¿Cuánta plagas puede sufrir?
b) Dada una plaga, ¿Cuántas plantas ornamentales pueden sufrirla?

Supongamos ahora un contexto para esta relación y respondamos ambas preguntas.
La respuesta que tomaremos como correcta para la pregunta a) es que dada 1 planta ornamental, puede sufrir una, muchas o ninguna plaga. La respuesta para la pregunta b) es que dada 1 plaga, también pueden sufrirla entre ninguna y muchas, cualquier cantidad de plantas ornamentales.
Si concertamos que esas son las respuestas correctas podremos anotar sobre el diagrama la notación de la Figura 30.


Figura 30

Nótese que se registro m como variable de planta ornamental y n como variable de plaga. Esta distinción tiene por finalidad señalar que ambas variables pueden tomar valores distintos. Si se tomara para ambas entidades la misma letra, podría suponerse que ambas variables siempre toman igual valor, cosa que no tiene porqué ocurrir. El nombre de las variables, por otra parte, es irrelevante; es una mera convención utilizar n y m.

La cardinalidad en las relaciones de grado unario
Este análisis no presenta ninguna dificultad adicional pues una relación unaria puede ser pensada como una relación binaria donde la primera y la segunda entidad son coincidentes y depende, tal como vimos en el caso de las relaciones binarias, en forma exclusiva del contexto.
Tomemos un nuevo ejemplo: supongamos que un Profesor para realizar un trabajo de investigación debe ser tutorado por otro Profesor, tal como se observa en la Figura 31.


Figura 31

Si el caso es que un profesor puede tener uno o más tutores y un profesor, a su vez, puede ser tutor de más de un profesor, estamos en presencia de una relación de m en n: Dado 1 profesor, puede haber n tutores (ninguno, uno o varios) y dado 1 tutor, puede haber m discípulos (ninguno, uno o varios).
Si las reglas de negocio o las políticas de la institución establecen que un profesor sólo puede realizar por vez un trabajo de investigación –y esto implica que sólo puede tener un tutor y a su vez un profesor no puede tutorar a más de un catedrático por vez, entonces, estaríamos en presencia de una relación de 1 en 1. Siguiendo el esquema de razonamiento que venimos aplicando, podemos decir que, dado 1 profesor sólo puede haber uno o ningún tutor y que dado un tutor sólo puede haber un discípulo.
Supongamos ahora que un profesor sólo puede tener un trabajo de investigación por vez –y un único tutor- pero que un profesor puede ser tutor de más de un colega, o supongamos que un profesor puede tener múltiples trabajos de investigación pero un profesor sólo puede tutorar a un discípulo por vez. En ambos casos, esta relación unaria tendrá una cardinalidad del tipo 1 en n.
Puede observarse la notación para este último caso en la Figura 32 y los invito a completar con la notación adecuada las figuras correspondientes a cada uno de los contextos analizados precedentemente.

Figura 32

REFINAMIENTO DE UN DIAGRAMA

Una vez finalizada la diagramación de un modelo de datos podemos aún continuar trabajando en él para pulirlo.
Debe tenerse muy claro que si se pretende crear una base de datos, el mejor momento para detectar errores es éste. Cuanto más se avance, si existen errores, mayor será el costo de la corrección.
Por otra parte, no será extraño encontrar errores pues hasta el momento se venían teniendo visiones parciales del modelo y recién ahora se analiza en su totalidad. En consecuencia, no debe pasarse por alto esta etapa.
Además, cuanto mayor sea el nivel de detalle obtenido en el modelo de datos, menor será el trabajo a posteriori, si es que se lo utiliza como punto de partida para crear una base de datos.
Veamos, entonces, qué hacer y algunas situaciones que deben contemplarse.

Eficacia en la obtención de información

Si el modelo no satisface toda la información que los usuarios necesitan, simplemente, se trata de un modelo malogrado. Debe tenerse, en consecuencia, la seguridad de que permite responder todas las preguntas para las cuales los usuarios esperan respuesta. Si así no fuera, habrá que revisarlo.
Es conveniente verificar en el diccionario de datos uno por uno los datos elegidos, ver que sus nombres sean acordes con su semántica y no den lugar a confusiones, asegurarse de que todas las unidades de medida sean claras y obvias, que todas las entidades se puedan identificar, que no haya errores en cuanto a la elección del tipo de entidad, relación o atributo, etc.

Estética y Facilidad de lectura

Debemos observar si la diagramación es estéticamente agradable y fácil de leer, si está balanceado en su aspecto, que no haya líneas conectores que se crucen, etc.
La bidireccionalidad de las relaciones pueden ser un obstáculo para la lectura si no están adecuadamente redactadas las relaciones. Considérese la relación “Es hijo de” que se verifica entre las entidades Niño y Hombre.
EL diagrama debe prever que la entidad Niño esté a la izquierda o arriba de la entidad Hombre pues, en caso contrario, sería necesario redactar la relación que existe entre ambas entidades como “Es padre de” para facilitar la comprensión de la representación gráfica. El Diagrama debe poder ser leído de izquierda a derecha y de arriba abajo.
Debe lograrse tanto como sea posible la homogeneidad en los criterios que se tomen. Por ejemplo, debe respetarse la simbología que se elija, sea esta la que fuere.
Si se cree conveniente, debe dibujarse nuevamente, una y otra vez, el diagrama, redistribuyendo sus elementos. Esto puede colaborar, además, con la detección de errores.

¿Atributo o entidad?

Dado que el diagrama Entidad-Relación es una representación de una realidad que refleja la visión que sus usuarios tienen de ella, puede, en algunas circunstancias, ser posible confundir atributos con entidades y viceversa.
Analicemos el siguiente caso: Se ha detectado en el Office de enfermería de un sanatorio, una entidad llamada Paciente Internado. Esta entidad tiene, entre otros atributos, un número de historia clínica, un nombre, una fecha de nacimiento, una fecha de internación, un médico que solicita la internación y una cama asignada. Véase la Figura 33 para tener bien en claro al contexto.

Figura 33

Nos hacemos esta pregunta: Número de historia clínica, Nombre, Fecha de nacimiento, Fecha de internación, Médico que interna y Cama asignada, ¿son todos atributos? Una vez más, la respuesta es “Depende”.
Tomemos el primer atributo, Número de historia clínica. Creo que no hay dudas de que en un sanatorio, un número de historia clínica debe servir para identificar un paciente internado y, en consecuencia, se trataría de un posible atributo clave para el paciente.
Sin embargo, la historia clínica puede tener, además, algunos atributos propios que quizás sean relevantes para el modelo. Por ejemplo, la fecha en que fue abierta, la cantidad de páginas, el responsable de su apertura, etc.
Todo “atributo” detectado que tiene él mismo atributos si es de alguna manera identificable, se trata en realidad, por definición, de una entidad.
Si aquel fuera el caso, quizás, la historia clínica deba existir en el modelo como una entidad, tal como se ve en la Figura 34. Quizá, efectivamente fue detectada la historia clínica como una entidad pero analizando los requerimientos de información detectamos que esos atributos de la historia clínica no son relevantes para este modelo que corresponde al Office de enfermería del sanatorio y no a la administración general...


Figura 34

La solución que considera a la historia clínica como una entidad débil del paciente puede ser muy efectiva si un paciente puede tener más de una historia clínica. Ese sería el caso si cada médico del sanatorio le abriera una propia historia clínica al paciente. Médico, en tal situación, también sería padre de la entidad Historia clínica. Véase la Figura 35.


Figura 35

Historia clínica también puede ser una entidad débil dependiente de paciente en este caso: Se considera bajo el primer nombre –Paciente- a todos los datos personales del paciente (posiblemente identificado con un número que podría llamarse de historia clínica) y bajo el segundo nombre –Historia clínica- a todas las consultas y prácticas que el paciente realiza en el sanatorio.
En este caso, no sería suficiente para identificar a la entidad Historia Clínica lo que llamamos número de historia clínica pues deberíamos buscar un mecanismo para identificar a cada consulta o práctica en particular.
Tomemos otro atributo muy interesante. ¿Qué pasa con la cama? Este es otro problema. Supongamos que la cama, además de tener una identificación, tiene atributos propios. Por ejemplo, Tipo [de una plaza | de plaza y ½ | reclinable | etc.]. Entonces, Cama será candidata a ser una entidad, tal como se observa en la Figura 36, en lugar de ser una propiedad.


Figura 36

Sin embargo, no siempre la cama será una entidad, aún teniendo algún atributo propio. Debemos plantearnos si nos interesa conocer de una cama su tipo o si nos interesa conocer el tipo de cama que está ocupando un paciente. Parecería ser en este caso, que las dos cosas nos interesan y, en consecuencia, Cama, como dijimos, será una entidad.
Generalmente, de hecho, en casos como éste, estaremos en presencia de una entidad, aunque puede haber excepciones. Llevemos la entidad Paciente Internado a la administración de una obra social que paga a las clínicas las internaciones de sus afiliados y dicho pago tiene dependencia del tipo de cama.
Le interesa a la obra social el número de cama en que se encuentra el paciente para ubicarlo; le interesa el tipo de cama para realizar el pago. Pero... ¿le interesa de qué tipos son las camas de las clínicas, sanatorios y hospitales de la ciudad? Quizá, no le interese esa relación. Si esa es la situación, Cama –cuya semántica implica un número de cama y Tipo de cama son meros atributos del paciente.
Supongamos, ahora que no tiene atributos propios. Simplemente, cama es el número que identifica a un objeto concreto y es candidata a ser una propiedad pero no necesariamente lo es.
¿De qué depende que cama sea una entidad o un atributo?. Depende de la información que se requiere. Analicemos la información que puede requerirse del modelo:

a) Se quiere saber en qué cama está un paciente. Cama puede ser considerada como un atributo del paciente.
b) Se quiere saber qué camas están ocupadas. Cama puede seguir siendo considerada como un atributo del paciente. Sólo hay que listar las camas asignadas a los pacientes para obtener esa información.
c) Se quieren conocer las camas libres. Si Camas es un atributo del paciente, ¡No contamos con esa información! Cama, debe ser entonces, y a pesar de no tener más atributos que su propia identidad, una entidad.
Además, el hecho de considerar que Cama es una entidad implica que cada cama existe y es identificable. Si no se contara con la entidad cama, si cama fuera un atributo del paciente, cuando se diera un alta a un paciente indicando un número de cama erróneo, ¿De qué manera podría verificarse el error?. No sería posible determinar que se produjo un error al ingresar el número de cama pues las camas no existen sino como valores que toma un atributo de un paciente.

¿Atributo multivaluado o relación?

Todo atributo multivaluado puede ser pensado, también, como una relación con la forma “Tiene muchos/as”, “Es” o alguna equivalente con una cardinalidad de 1 en n.
Entonces, ¿Será conveniente incluirlo como atributo multivaluado o como relación? Adivinen la respuesta. Como siempre, depende.
Tomemos una vez más el caso de las películas que tenían actores protagónicos analizado en la sección de Características Esenciales bajo el título Tipos de Atributos, Propiedades o Características, Atributos Multivaluados.
Consideremos que en lugar de existir una entidad Película con un atributo multivaluado {Actor Protagónico} existe una entidad Película que participa de la relación “es protagonizado” con otra entidad denominada Actor. Ambas situaciones están respectivamente representadas en los casos a) y b), en la Figura 37.
El segundo diseño tiene el mismo significado —brinda la misma información— que el primero pero despliega algunas connotaciones distintas.
En ese caso, los actores tienen existencia por sí mismos, son relevantes para el sistema, deben poder ser identificados y deben ser definidos por sus características. En el diseño anterior, los actores eran importantes en cuanto se presentaban como atributos de una película.


Figura 37

¿Cuál de las dos soluciones debemos elegir? Como siempre, es el contexto el que nos resuelve el problema.
Si lo consideramos como un atributo multivaluado, el diagrama se presentará notoriamente más sencillo: Cuenta con una entidad y una relación menos; en consecuencia, si los actores no son realmente relevantes, ganaremos en claridad si los mantenemos como atributos.
Pero, ¡Cuidado! Ello va en detrimento del significado de Actor. Perderemos el universo de los actores. Según vimos cuando tratamos por primera vez el ejemplo, el hecho de representarlo como atributo multivaluado, a diferencia de representarlo como atributo singular con forma de lista, no permitía procesar los actores uno por uno.
Pero sigue teniendo una limitación: Sólo existen los actores protagónicos de las películas que han tomado valor para la entidad película. Si algún actor que nos interesa registrar no protagonizó alguna de las películas de la entidad película no podrá ser incluido.
Con la entidad Actor tendremos en la base de datos todos los actores, hayan participado o no de alguna de las películas de la entidad Película, además, por supuesto, de poderlos listar, ordenar, catalogar, etc.
En consecuencia, si no interesa el universo de actores —o de actores protagónicos— en virtud de la sencillez del diagrama, quizás sea conveniente el uso de un atributo multivaluado. Si, por el contrario, es importante todo actor, independientemente de que haya o no trabajado en alguna de las películas, quizás sea conveniente utilizar en el modelo, una relación del tipo “Tiene”.

MODELOS PARA IMPLEMENTAR UN ESQUEMA CONCEPTUAL

El modelo Entidad-Relación que estudiamos en este capítulo es un modelo semántico del mundo real de un usuario que describe el significado de los datos relevantes y las relaciones que se verifican entre unos y otros. Pero una vez creado el modelo es necesario implementarlo.
La ingeniería de Software ha ido proporcionando distintas técnicas para implementar un sistema que ha sido modelado semánticamente. Actualmente se pueden distinguir los modelos de implementación de bases de datos relacionales y no relacionales.
Veremos a continuación cómo han ido evolucionando los sistemas de bases de datos, cual es la situación actual y nos avocaremos luego al análisis del modelo relacional de datos.