Blog tecnológico

Modelo entidad-relación, un ejemplo práctico I

marzo 29, 2010 en Blog tecnológico

En el desarrollo de software para empresas, el almacenamiento de la información de un modo organizado es fundamental… la mayoría de los casos en los que el programador contesta “no se puede hacer” a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicación. En este artículo voy a intentar explicar, con un ejemplo práctico, un buen modelado de datos.

Como, de alguna forma, estamos especializados en el software de gestión de empresas de enseñanza, voy a utilizar un ejemplo de uno de esos modelos: la gestión de matriculación de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Voy a explicar en este artículo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementación), las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. De paso, daré una idea de los índices, procedimientos almacenados y triggers que nos pueden resultar útiles para que el rendimiento de la base de datos sea bueno.

Descripción del proceso de matriculación (el caso de uso)

Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman “grupos abiertos”, es decir, grupos en los que cualquiera se puede matricular (en oposición a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente).

Cuando llegamos a la academia, se nos ofrece un folleto o catálogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que más nos conviene, el horario al que vamos a asistir, y con esta información nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a través de nuestra cuenta bancaria.

En la academia, llegado este punto, introducen en su sistema de información nuestros datos y nos imprimen el contrato de prestación de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequeña cantidad del primer recibo.

En el siguiente día de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo… nos da la bienvenida, y empezamos a estudiar.

El modelo de datos

A partir de aquí haré una descripción de la estructura de tablas y columnas para almacenar la información de este proceso. Primero, algunas generalidades sobre cómo crear los campos.

Generalidades

Hay algunas cosas básicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas así). Por ejemplo:

1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen así un identificador interno, mantenido por el sistema. Así, las claves ajenas son más fáciles de mantener.

2. En general, nosotros no solemos poner campos requeridos… preferimos hacer la gestión dentro de la lógica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estábamos completamente seguros que eran requeridos y hemos tenido que quitar la marca.

3. No se duplica información. Es decir, una de las reglas básica es que la misma información no puede estar en dos sitios, salvo…

4. En muchos casos, creamos campos calculados, que permiten acceder de forma rápida a información… por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales… como hacer este cálculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automáticamente (en nuestro caso, a través de Triggers de la base de datos). La información está duplicada en dos sitios, sí, pero por motivos de rendimiento (y siempre está sincronizada).

5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dónde vas a tener que acceder.

Descripción de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Según el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos):

• Cursos: almacena la oferta formativa del centro. Representa el catálogo o folleto que te dan al llegar al centro.

• Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto también). Trimestral, mensual, anual, etc.

• Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante más complejo que el que voy a describir aquí… en un artículo posterior lo describiré en detalle.

• Clientes: el que paga… puede ser el mismo que el alumno, pero también puede que no.

• Medios de pago: Contiene los diferentes métodos que los clientes pueden usar para pagar (contado, domicilación bancaria, etc), incluyendo las cuentas bancarias del cliente.

• Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurídicas), los alumnos son personas físicas. Un mismo cliente puede tener múltiples alumnos.

• Matrículas: Refleja en qué curso nos matriculamos, las fechas, la forma de pago, etc. De forma física, se refleja en el contrato que te dan para firmar.

• Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro.

• Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestión de recibos y pagos que hacemos en realidad es más compleja de lo que voy a describir aquí. En otro artículo haré una descripción más completa.

• Alumnos en grupos: refleja los alumnos que están asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa información histórica, así que necesitamos una tabla para gestionarlo.

Aquí podéis ver el modelo gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con

...