Modelado de datosYa que hemos definido cómo puede ser organizada la información que compone una base de datos, ahora es necesario saber cómo relacionarla y representarla de una manera lógica y coherente. Para ello se recurre al modelado pues éste define la estructura sobre la que realmente reside la esencia de la aplicación, incluso determina si el proyecto cumplirá su verdadero objetivo.

Seguramente te preguntarás ¿a qué se refiere el modelado? ¿Qué se modela?

En nuestro caso, el modelado es una abstracción de la realidad por medio de datos; una representación abstracta de la realidad.

Entonces tenemos que:

Modelo de datos es la descripción de un contenedor de datos así como de los métodos para almacenar y recuperar información de los mismos.

Por ejemplo:

Al elaborar una base de datos para una escuela se plantean los elementos que se desea utilizar —plantilla de profesores, asignaturas, etcétera— y se analiza la estructura que se utilizará para manejar los datos. En este caso, sabemos que los profesores se relacionan directamente con las asignaturas para llevar un registro acerca de qué profesor imparte determinada asignatura.

Los modelos de datos son abstracciones que permiten implementar un sistema eficiente de base de datos; por lo general se refieren a algoritmos y conceptos matemáticos. Mediante dichos modelos reflejaremos la estructura de la actividad de la organización por medio de datos y relaciones.

Uno de los puntos importantes que se debe indicar es que el modelado de datos debe ser llevado como una guía general. Esto implica desarrollar los Diagramas de Entidades y Entidad-Relación (se estudiarán más adelante), independientemente de la metodología a utilizar, pues son herramientas necesarias para entender las relaciones entre las diversas entidades en la base de datos.

Las bases de datos se pueden clasificar de acuerdo con su modelo de administración de datos.

A continuación estudiaremos algunos modelos utilizados frecuentemente para desarrollar bases de datos, algunos de los cuales, por su complejidad, no serán abordados a profundidad.

Modelo de Red

Representan los datos mediante colecciones de registros (entidades) en forma de nodos de un grafo; las asociaciones o interrelaciones entre éstos, mediante las líneas que unen dichos nodos.

En un modelo de red, llamada algunas veces estructura plex, un nodo hijo puede tener más de un padre.

La siguiente figura muestra un ejemplo simple de cómo está conformado tal modelo.

Para ejemplo:

Imagina una base de datos que administra las cuentas bancarias de algunas personas donde, para construir una modelo de red, basta conocer el nombre, apellido paterno y materno, número de cuenta y el saldo.

Así sería su representación:

Ejemplificando con datos:

Como podrás notar, los datos han sido organizados y relacionados; entonces la base de datos muestra que Marcos tiene la cuenta CN-555 con un saldo de 5600 en la sucursal SUC-30 ubicada en Monterrey.

Modelo jerárquico

En este modelo la información se almacena en una estructura jerárquica similar a un árbol invertido, donde un nodo padre de información puede tener varios hijos; dicho nodo padre es llamado raíz.

El modelo jerárquico es especialmente útil para implementar aplicaciones que manejan un gran volumen de información y datos muy compartidos; permite crear estructuras estables y de gran rendimiento.

Características del modelo jerárquico

El árbol se organiza en un conjunto de niveles.

1. El nodo raíz, el más alto de la jerarquía, se corresponde con el nivel 0.2. Las líneas representan las asociaciones jerárquicas entre dos entidades.

Sólo puede haber una interrelación.3. Mientras que un nodo de nivel superior (padre) puede tener un número

ilimitado de nodos de nivel inferior (hijos), al nodo del nivel inferior sólo le puede corresponder un único nodo de nivel superior.

4. Todo nodo, a excepción del nodo raíz, debe tener obligatoriamente un padre.

5. Se llaman hojas los nodos que no tienen descendientes.6. Se llama altura al número de niveles de la estructura jerárquica.7. Se denomina momento al número de nodos.8. Sólo están permitidas las interrelaciones 1:1 o 1:N.9. Cada nodo no terminal y sus descendientes forman un subárbol.

El árbol, en este modelo, se recorre en pre orden, es decir, subárbol izquierdo y subárbol derecho (recorrido A, B, C, D, E, F, G, H, I).

Para ejemplificar, volvamos al ejemplo de la base de datos que maneja cuentas bancarias; el modelo jerárquico quedaría:

Este modelo, como podemos observar, es bastante coherente y lógico, pero presenta grandes inconvenientes debido a su rigidez pues no admite:

1. Nodos hijos con mas de un padre.2. Relaciones reflexivas.3. Más de una interrelación entre dos nodos.4. Nodos hijos sin padre.

Razones por las cuales no se implementa en determinadas aplicaciones donde se maneja una cantidad considerable de información que necesita ser tratada de diversas formas.

Por ejemplo, en una aplicación de una biblioteca, si tuviéramos que guardar información de un libro tendríamos un nodo llamado libro o título que necesariamente tendría uno o más autores y pertenecería a una materia. Utilizar un modelo jerárquico resultaría muy complicado, debido a sus restricciones, mostrar este tipo de relaciones.

Modelo relacional

Para modelar problemas reales y administrar datos dinámicamente, donde el lugar y la forma en que se almacenen los datos no tiene relevancia, existe el modelo relacional, el cual presenta la considerable ventaja de que es más fácil de entender y de utilizar la información de la base de datos y puede, a su vez, ser recuperada o almacenada mediante consultas que ofrecen una amplia flexibilidad para administrar la información. Éste, junto con el modelo entidad (relación que se estudiará posteriormente), es el más utilizado actualmente.

En este modelo se representan los datos y las relaciones entre estos a través de una colección de tablas en las cuales las filas (tuplas) equivalen a cada uno de los registros que contendrá la base de datos; las columnas corresponden a las características (atributos) de cada registro localizado en la tupla. Observa la siguiente figura que representa este modelado:

Elementos:

1. Dominio

Se denomina así a un conjunto finito de valores, los cuales pueden ser:

1. Homogéneos (del mismo tipo)2. Atómicos (indivisibles en lo que al modelo se refiere)

Puede tomar un atributo.

Por ejemplo

El dominio de las ciudades de México toma los valores: México, Guadalajara, etcétera. Un atributo A será entonces el papel que juega un determinado dominio D en una relación.

Así, se dice que D es el dominio de A y se denota dom(A).

Por ejemplo:

En la siguiente tabla-cliente, el atributo Ciudad (definido sobre el dominio de ciudades) nos indica que dicho dominio tiene el papel de ciudad del cliente.

2. Relación

Representa un producto cartesiano de los dominios D1, D2,…, Dn donde cada elemento de la relación (tupla) es una serie de n valores ordenados.

Una relación se puede representar en forma de tabla, pero tendrá una serie de elementos característicos:

1. No puede haber filas duplicadas, es decir, todas las tuplas deben ser distintas.

2. El orden de las filas es irrelevante.3. La tabla es plana, es decir, en el cruce de una fila y una columna sólo

puede haber un valor (no se admiten atributos multivaluados).

3. Claves

Es conveniente que conozcas el concepto de clave o llave candidata de una relación; ésta representa un atributo que identifica unívocamente cada tupla de la relación.

Por ejemplo, veamos la tabla Cliente

En esta tabla los atributos CURP y Cuenta son claves candidatas ya que suponemos que no existen dos clientes con el mismo CURP o la misma cuenta.

Te preguntarás ¿pueden existir más de una clave candidata?

Sí, pero se clasifican en:

Clave o llave primaria. Cuando en una tabla sólo exista una clave candidata, ésta será denominada clave primaria. También puede ser seleccionada por el diseñador para ser la única clave que represente las tuplas de una relación. Su obligatoriedad es inherente al modelo relacional.

Claves o llaves alternativas. También llamadas secundarias, son aquellas claves escogidas que aún no han sido seleccionadas como claves primarias, pero representan una tupla de la relación.

Clave o llave ajena o foránea. Se denomina así a un conjunto no vacío de atributos cuyos valores deben coincidir con los valores de la clave candidata de otra relación.

Características y restricciones del modelo

A continuación enlistamos las características y restricciones de este modelo:

4. Normalización

Durante su diseño, una base de datos relacional pasa por un proceso conocido como normalización, en la que cada atributo de una tabla sólo puede tomar un valor único del dominio sobre el que está definido, no admitiéndose los grupos repetitivos.

Ejemplificando con el esquema siguiente, la relación de la tabla Cliente con Ciudad se encuentra normalizada en la primera forma normal. El atributo Ciudad es atómico (ya no lo podemos dividir más).

Como puedes ver, sería incorrecto incluir en este atributo campos como Guadalajara, Jalisco o Naucalpan, México; si lo hiciéramos, diríamos que la relación no está normalizada. Esta característica se estudiará más adelante.

Estructura del modelo relacional

En la siguiente figura se retoman los conceptos vistos anteriormente. Observa los dominios que se corresponden con sus respectivos atributos de la relación.

¿Consideras que este modelo se adecua más a la realidad? Analízalo.

Modelo Entidad–Relación

Este es el modelo que estudiaremos más a fondo pues constituye una de las formas de modelado de datos más utilizada en la actualidad, además representa una forma fácil y estandarizada de representar la realidad de la manera más fiel posible.

Este modelo está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. Se encuentra en un nivel de abstracción superior al modelo relacional, aunque está basado en él.

Para entender mejor este modelo, debemos definir el siguiente concepto.

Entidad. Cualquier tipo de objeto o concepto del mundo real (cosa, persona, concepto abstracto o suceso), distinguible de otros objetos, sobre el que se recopila información.

Por ejemplo:

Debemos elegir nombres que comuniquen, hasta donde sea posible, el significado de cada entidad. Normalmente se utilizan nombres en singular y no en plural.

Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior.

Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Gráficamente lo representamos así:

1. Tipos de entidades

a) Entidad fuerte. Existe por sí misma y no depende de otras. Se representa mediante un rectángulo sencillo.

b) Entidad débil. Su existencia depende de la existencia de otra entidad (por ejemplo, Familiar depende de Empleado; la desaparición de un empleado de la base de datos hace que desaparezcan también todos los familiares del mismo). Se representa mediante un rectángulo doble.

2. Atributos

Representan las propiedades básicas que describen a cada entidad o relación.

Gráficamente se representan mediante elipses ligadas a las entidades o relaciones a las que pertenecen, como se puede ver en la figura:

Un conjunto de entidades puede tomar valores específicos asignados para cada uno de sus atributos; cada atributo tiene un conjunto de valores asociados llamado dominio, así es posible su identificación unívoca.

Por ejemplo:

A la colección de entidades Cliente, con el siguiente conjunto de atributos en común (CURP, nombre, edad), pertenecen las entidades:

PEHEJUXX… Juan Pérez 40 años

HELOGEXX… Gerardo Hdz 20 años

Los atributos clave (clave o llave primaria) deben aparecer destacados —pueden ser subrayados—.

Por ejemplo:

Para una persona su atributo clave puede ser su identificador, por lo tanto debe aparecer subrayado.

Los atributos pueden clasificarse en simples o compuestos.

1. Un atributo simple es aquel que no se puede dividir en partes más pequeñas con significado propio.

Por ejemplo:

Supongamos que en una aplicación el identificador de una persona toma valores consecutivos del 1 en adelante, entonces no habría ninguna razón para que dicho atributo se descompusiera en otros.

1. Un atributo compuesto es aquel que consta de varios componentes, cada uno con un significado por sí mismo.

Por ejemplo:

Para una persona la fecha de nacimiento puede ser todavía descompuesta en día, mes y año los cuales, a su vez, pueden tener un significado para la aplicación.

Los atributos también pueden clasificarse de la siguiente manera:

Identificador

Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad.

Un identificador de una entidad debe cumplir dos condiciones:

1. No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.

2. Si se omite cualquier atributo del identificador la condición anterior deja de cumplirse.

Como podrás observar:

1. Un identificador no es más que la clave o llave primaria del modelo relacional.

2. Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos.

3. Las relaciones no tienen identificadores.

Retomando el ejemplo de una persona su atributo ID sería entonces el identificador.

Relación (interrelación)

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos; su nombre aparece en el interior.

Una característica importante es que dicho nombre debe ser un verbo que describa tal relación, por ejemplo: vende, pertenece, etcétera.

Una relación puede tener atributos descriptivos.

Por ejemplo, la relación anterior podría tener como atributo descriptivo la fecha de la venta.

1. Las entidades que están involucradas en una determinada relación se denominan entidades participantes

2. El número de participantes en una relación se denomina grado de la relación.

Así, una relación en la que participan dos entidades corresponde a una relación binaria. Si son tres las entidades participantes la relación es ternaria, etcétera.

En la figura se observa una relación binaria (consta de dos entidades):

Una relación recursiva es aquella donde la misma entidad participa más de una vez en la relación con distintos papeles. El nombre de estos papeles es importante para determinar la función de cada participación.

Por ejemplo, podemos concebir una entidad de empleado en la que tengamos la información de las personas que laboran en la organización. En esa entidad se encuentran los empleados, los supervisores, directivos, etcétera. Si queremos ilustrar una relación respecto a la acción de reportar, resulta que un empleado reporta a un supervisor, quien resulta ser otro empleado que se encuentra dentro de la misma entidad. De este modo, tenemos una relación recursiva, pues la entidad empleado se relaciona consigo misma.

La cardinalidad expresa el número mínimo y máximo de entidades que están relacionadas con una única entidad que participa en una relación específica.

La participación de una entidad en una relación es obligatoria (total). Por cada ocurrencia que existe se requiere al menos otra entidad participante, de lo contrario la participación sería opcional (parcial) y las reglas que definen la cardinalidad de las relaciones serían las de negocio.

Según su cardinalidad, podemos clasificar las relaciones de la siguiente forma:

Según lo anterior tenemos que:

Este nos muestra tres entidades: persona, vivienda y municipio. Surgen las preguntas: ¿Qué entidad es fuerte? ¿Cuál es débil? ¿Por qué?

Pues bien, la entidad persona es fuerte —una persona no necesariamente tiene vivienda propia por lo que no depende de la entidad vivienda, además dicha entidad puede existir por sí misma y por ende tampoco depende de la entidad municipio—.

La entidad municipio también es fuerte, pues no depende de las otras dos entidades.

Por el contrario, la entidad vivienda es débil ya que no depende totalmente de la entidad persona pues no toda vivienda pertenece a una persona; sí depende de la entidad municipio: forzosamente debe encontrarse en algún municipio.

Así quedaría el diagrama entidad relación:

En cuanto a la cardinalidad, vemos que en la relación de persona a vivienda la relación es de uno a muchos, pues una persona puede tener más de una vivienda.

Lo mismo ocurre en la relación en sentido opuesto: una vivienda puede estar habitada por una o más personas.

Del mismo modo podemos analizar las dos relaciones de la entidad municipio.

A veces surgen problemas cuando diseñamos un esquema conceptual. Éstos se denominan trampas; suelen producirse a causa de una mala interpretación en el significado de alguna relación, por lo tanto es importante comprobar que el esquema conceptual carece de dichas trampas.

En general, para encontrar las trampas debemos corroborar que entendemos completamente el significado de cada relación. Si no entendemos las relaciones, podríamos crear un esquema que no represente fielmente la realidad.

Una de las trampas ocurre cuando el esquema representa una relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. Para resolverla reestructuramos el esquema, así representamos correctamente la asociación entre las entidades.

Otra de las trampas se da cuando un esquema sugiere la existencia de una relación entre entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso se produce una pérdida de información, la cual se puede subsanar introduciendo la relación que sugería el esquema y que no estaba representada.

Parecería que ya tenemos toda la información para diseñar una base de datos, sin embargo aún falta algo importante: los atributos.

Ahora veamos el ejemplo anterior con atributos:

En este caso podemos ver que el identificador de la entidad Persona es Id_persona, el cual será único para cada registro.

El atributo Nombre es compuesto, ya que se compone de los atributos Nombre(s), Apellido paterno y Apellido materno.

El atributo Edad es simple debido a que no se compone de otros atributos.

Propuesta alternativa para diseñar bases de datos

Por su simplicidad y fácil interpretación de requerimientos, sugerimos la siguiente notación para diseñar bases de datos.

Entidades

Las entidades se clasifican en:

Atributos

Se representan mediante óvalos ligados a la entidad o relación de la cual forman parte.

Su formato mediante la norma ISO 10015 será:

3 caracteres para propiedad _ 3 caracteres para tabla _ dígito (de ser necesario).

XXX_XXX_99

Por ejemplo, para nombrar las propiedades RFC y Nombre pertenecientes a la entidad MCliente, su formato sería: rfc_cli y nom_cli respectivamente. Así la entidad quedaría construida de la siguiente forma:

Relaciones

Se representan mediante un rombo; asocian al dominio y al codominio escogiendo el atributo más particular e irrepetible que contiene la entidad.

Por ejemplo, si quisiéramos saber el país al que pertenece un cliente, debido a que la entidad MCliente almacena las características propias del cliente y la entidad CPaís almacena los nombres de los países, sería necesario relacionar dichas entidades mediante un atributo del dominio que identifique unívocamente cada registro, el cual también sería un atributo del codominio que tomaría el papel de clave foránea.

Así, teniendo las siguientes entidades:

Para hacer la relación, la entidad MCliente se convierte en el codominio o entidad débil pues necesita información de CPaís que toma el papel de entidad fuerte o dominio en la relación.

La elección del atributo identificador viene dada por la necesidad que requiere el codominio de su respectivo dominio, por lo que el identificador debe tomarse de ese último —en este caso de CPaís—.

Ahora bien, en la definición de relación se hizo énfasis en que se escoge el atributo más particular que contiene la entidad dominio; entonces, para evitar inconsistencia y duplicidad de la información, dicho atributo puede ser el atributo clave de la entidad dominio; éste se saca de dicha entidad y se indica en la relación de la siguiente forma:

Conclusión

El modelado de datos es la abstracción de elementos del mundo real para estructurar nuestros datos, almacenarlos y utilizarlos. Estas abstracciones nos facilitan entender las relaciones que existen en los datos y dependen del sentido que le demos a la información.

Las tareas a realizar para lograr el modelado son las siguientes:

1. Identificar las entidades.

2. Identificar las relaciones.

3. Identificar los atributos y asociarlos a entidades y relaciones.

4. Determinar los dominios de los atributos.

5. Determinar los identificadores.

6. Dibujar el diagrama entidad–relación.

7. Revisar el esquema conceptual local con el usuario.