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 la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y
las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección
describiremos los campos de cada tabla.

Campos para las entidades

Sólo describiré los campos más importantes, y no incluiré los campos de clave primaria y ajena que se
describen en el gráfico.

Cursos

 nombre: varchar(100)
 descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una
descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que
tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por
tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
 fecha_inicio: date
  fecha_fin: date

Formas de pago

 nombre: varchar(100)
 importe: float. Es el importe de cada recibo que se cobrará
 numero_meses: integer. El número de meses de cada recibo. Si es 1, se creará un recibo cada mes
mientras dure la matriculación, si es 3, uno cada tres meses, etc. En algún sistema hemos hecho, en
lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas.
Eso permite más flexibilidad y más control, pero el modelo es bastante más complejo.
 numero_orden: integer. A la hora de presentárselo al cliente, poder mostrar primero las que más nos
interesen.
 importe_matricula: float. Si además del importe del curso hay un importe de matrícula, se marca
aquí.
 concepto_matricula. El concepto del recibo de matrícula, si creamos uno.

Grupos

 nombre: varchar(100)
 codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en
algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
 fecha_inicio: date
 fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden
estar fuera de las fechas del curso al que pertenecen.
 lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo
ampliaré en otro artículo.
 notas: memo, del grupo
 horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta,
pero no voy a entrar en tanto nivel de detalle ahora.
 maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
 numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo
lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para
poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Clientes

 nombre: varchar(100). En nuestros sistemas, normalmente, este es el único campo requerido (por
código, no en la base) que tenemos. Así, el usuario puede dar de alta el registro aunque no tenga
todos los datos, y volver después.
 primer_apellido: varchar(100)
 segundo_apellido: varchar(100)
 nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para
poder coger de forma rápida el conjunto Nombre+’ ‘+primer_apellido+’ ‘+segundo_apellido
 direccion: memo
 codigo_postal: varchar(20): no hay que ser tacaño… de vez en cuando hay que meter una dirección
extranjera y el código postal puede ser más grande.
 poblacion: varchar(50)
 notas_internas: memo
 etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos

 nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en
clientes es sólo nombre por si
 primer_apellido: varchar(100)
  segundo_apellido: varchar(100)
 nombre_completo: varchar(300):
 etc. de datos personales (profesión, teléfonos, email, etc.)

Medios de pago

 tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que
suelen ser: Sin Pago, Contado, Banco
 nombre_titular: varchar(100)
 direccion_titular: memo
 entidad: varchar(4)
 oficina: varchar(4)
 dc: varchar(2)
 numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la información
bancaria del cliente.
 por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no
tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se crea un medio de pago
“contado”, y se le pone por defecto.

Matrículas

Además de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto último puede parece
redundante, pero no lo es… podemos tener el caso (yo lo he visto) de un alumno que se matricula para
estudiar, digamos, inglés y francés… el inglés lo paga el padre y el francés la madre. Así, es necesario que
cada matrícula esté asociada con el alumno, y también con el cliente), necesitamos los siguientes campos:

 fecha_inicio: date.
 fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse después o terminar
antes (si se da de baja, por ejemplo).
 importe: real. Por defecto, el de la forma de pago escogida, pero puede ser también distinto…
descuentos por familiares, cosas así. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda
cambiar.
 motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego
poder obtener estadísticas de número de bajas por tipo, cosas así.

Recibos

 fecha_emision: date
 fecha_cobro_completo: date
 numero_recibo: varchar(20)
 concepto: varchar(50)
 importe_recibo: float.
 importe_pendiente: float. Es un campo de sólo lectura, actualizado a través de triggers, que permite
acceder a la información sin tener que sumar.

Pagos

 fecha: date
 importe: real
 forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja.
Puede ser: contado, transferencia, tarjeta, talón, etc.

Alumnos en grupos

 fecha_inicio: date
  fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero
cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en
grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un
alumno pueda asistir a varios grupos (esto también lo he visto).

Casos Propuestos.

2- “Yo soy el administrador de una compañía de ventas al por mayor de productos deportivos, que opera en todo el mundo, la cual llena
órdenes para almacenes que venden al por menor estos productos. Los almacenes son nuestros clientes. Ahora tenemos 15 clientes
alrededor del mundo, pero estamos tratando de expandir nuestra base de clientes. Por cada cliente debemos registrar una identificación y
un nombre. Podemos registrar una dirección incluyendo el país y el número telefónico. Mantenemos bodegas en diferentes regiones para
satisfacer las órdenes de nuestros clientes. Por cada orden nosotros debemos registrar una identificación; también podemos registrar la
fecha de la orden, la fecha de envío y el tipo de pago cuando la información está disponible. Tenemos dividido el mundo en cinco (5)
regiones: Norte América, Sud- América, Africa-Medio Oriente, Asia y Europa. De ellas registramos la identificación de la región y el
nombre. Tratamos de asignar cada cliente a una región, así sabremos mejor desde cuál localización se llena cada orden. Para cada bodega
debemos tener una identificación; también podemos registrar una dirección ( incluyendo el país ) y el número telefónico. Actualmente
tenemos una bodega por región, pero esperamos tener más a corto plazo”.

3- La Asociación de profesores de la universidad ‘XXXX’ cuenta con más de 1000 asociados y para el manejo de la información sólo
cuenta con una secretaria que a diario requiere consultar información que se encuentra en documentos muy dispersos. Por ello se requiere
con urgencia un sistema que le facilite su labor diaria.

De cada asociado se debe guardar la identificación, nombre, título, dirección electrónica, teléfono de la oficina tipo de socio ( Tiempo
completo, medio tiempo, cátedra). También se necesita saber en cuál carrera trabaja y quién es su jefe inmediato. Por cada carrera se
registra su código, nombre, tipo (Ingeniería, Tecnología, Técnica,...). Aunque los profesores pueden servir asignaturas en varias carreras,
su contrato indica específicamente a cual está adscrito. Ciertos asociados trabajan en algunas empresas y de ellas se guarda el nombre la
dirección y el teléfono.

Durante el año la Asociación realiza varios eventos de los cuales se guarda información tal como el nombre, descripción, fecha de
realización, lugar, costo, número de asistentes y cualquier comentario alusivo al evento. Los comentarios se manejan en un formato
especial y contienen un texto de cualquier longitud y a cada uno de ellos se le asigna un número; con frecuencia se obtienen múltiples
comentarios por cada evento. Además se registra cuáles asociados asistieron a cuáles eventos ya que existen socios muy activos y otros
que asisten con poca frecuencia quedando satisfechos con los boletines informativos.

4- Una empresa de seguros tiene a su cargo la venta de diferentes tipos de seguros (Ej.: de vida, de automóvil, de incendio, ...). Para ello
cuenta con empleados que se encargan de visitar a sus clientes. Un vendedor puede visitar a varios clientes pero el cliente es visitado sólo
por un vendedor. Por cada tipo de seguro vendido se elabora una póliza de seguros que se identifica con un consecutivo, fecha de
expedición, fecha de terminación, valor total del seguro. Los vendedores ganan además de su salario básico, una comisión por sus ventas.
Por cada cliente se guardan sus datos personales tales como: cédula, nombre, dirección, teléfono, y actividad económica. El sistema de
BD debe proporcionar información sobre: Cuáles son los vendedores de la empresa; Qué tipo de seguros vende la empresa; Qué clientes
son visitados por cuál vendedor; Qué pólizas son de un determinado cliente; Cuáles clientes tiene la empresa.

Ing° Carlos Alberto Zelada Chavez

Taller de Programacio I – Esc. Ing° Civil.