El modelo de datos

A partir de aqu har una descripcin de la estructura de tablas y columnas para almacenar
la informacin de este proceso. Primero, algunas generalidades sobre cmo crear los
campos.

Generalidades (modelo entidad-relacin)

Hay algunas cosas bsicas 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 ms fciles de mantener.
2. En general, nosotros no solemos poner campos requeridos preferimos hacer la
gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se
nos han dado casos de campos de los que estbamos completamente seguros que
eran requeridos y hemos tenido que quitar la marca.
3. No se duplica informacin. Es decir, una de las reglas bsica es que la misma
informacin no puede estar en dos sitios, salvo
4. En muchos casos, creamos campos calculados, que permiten acceder de forma
rpida a informacin 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 clculo cada vez que nos hace falta ralentiza el funcionamiento del
sistema, hacemos un campo calculado que se mantiene automticamente (en nuestro
caso, a travs de Triggers de la base de datos). La informacin 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 dnde vas a tener que acceder.

Descripcin de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos
a tener. Segn 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 catlogo 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 tambin). 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 ms complejo que el que voy a
describir aqu en un artculo posterior lo describir en detalle.
 Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que
no.
Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para
pagar (contado, domicilacin bancaria, etc), incluyendo las cuentas bancarias del
cliente.
Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas
jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples
alumnos.
Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago,
etc. De forma fsica, 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 gestin de recibos y pagos que
hacemos en realidad es ms compleja de lo que voy a describir aqu. En otro
artculo har una descripcin ms completa.
Alumnos en grupos: refleja los alumnos que estn asignados a los distintos grupos.
El alumno puede cambiar de grupo, y no queremos perder esa informacin histrica,
as que necesitamos una tabla para gestionarlo.

Aqu podis ver el modelo grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas 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 podis ver, slo estn 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 seccin describiremos los campos de cada tabla.

Campos para las entidades

Slo describir los campos ms importantes, y no incluir los campos de clave primaria y
ajena que se describen en el grfico.

Cursos

nombre: varchar(100)
descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para
hacer una descripcin 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 tipologas, 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 nmero de meses de cada recibo. Si es 1, se crear un
recibo cada mes mientras dure la matriculacin, si es 3, uno cada tres meses, etc. En
algn sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos,
con fechas, descripciones, etc. personalizadas. Eso permite ms flexibilidad y ms
control, pero el modelo es bastante ms complejo.
numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero
las que ms nos interesen.
importe_matricula: float. Si adems del importe del curso hay un importe de
matrcula, se marca aqu.
concepto_matricula. El concepto del recibo de matrcula, si creamos uno.

Grupos

nombre: varchar(100)
codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre.
Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en
la Fundacin Tripartita.
fecha_inicio: date
 fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas
fechas no pueden estar fuera de las fechas del curso al que pertenecen.
lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de
aulas, pero eso lo ampliar en otro artculo.
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. Mximo nmero de alumnos permitidos en el grupo.
numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este
campo es de slo lectura para el usuario, y es calculado, a travs de una serie de
Triggers en la base de datos, para poder saber rpidamente el nmero 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 cdigo, no en la base) que tenemos. As, el usuario puede dar de alta
el registro aunque no tenga todos los datos, y volver despus.
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 rpida el conjunto Nombre+
+primer_apellido+ +segundo_apellido
direccion: memo
codigo_postal: varchar(20): no hay que ser tacao de vez en cuando hay que
meter una direccin extranjera y el cdigo postal puede ser ms grande.
poblacion: varchar(50)
notas_internas: memo
etc. de datos personales (profesin, telfonos, email, etc.)

Alumnos

nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y

primer apellido (en clientes es slo nombre por si
primer_apellido: varchar(100)
segundo_apellido: varchar(100)
nombre_completo: varchar(300):
etc. de datos personales (profesin, telfonos, 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 informacin 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.

Matrculas

Adems 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, ingls y francs el ingls lo paga el
padre y el francs la madre. As, es necesario que cada matrcula est asociada con el
alumno, y tambin con el cliente), necesitamos los siguientes campos:

fecha_inicio: date.
fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse
despus o terminar antes (si se da de baja, por ejemplo).
importe: real. Por defecto, el de la forma de pago escogida, pero puede ser tambin
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 estadsticas de nmero 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 slo lectura, actualizado a travs de
triggers, que permite acceder a la informacin 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, taln, etc.

Alumnos en grupos

fecha_inicio: date
 fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la
matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber
varios registros de alumnos en grupos. Hay que tener en cuenta tambin la
posibilidad de que en un mismo curso, pagando ms, un alumno pueda asistir a
varios grupos (esto tambin lo he visto).

Triggers y procedimientos almacenados

El modelo de datos y la lgica del negocio estn muy estrechamente relacionados. Los
sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados,
lo que es muy conveniente para dejar trozos de la lgica de negocio asociados con la base
de datos, tanto por motivos de organizacin del cdigo como por motivos de rendimiento
(un procedimiento almacenado es varios rdenes de magnitud ms rpido que hacer el
mismo proceso a travs de un lenguaje de programacin).

En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan:

Actualizacin de los campos NombreCompleto de alumnos y clientes:

normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza
el campo en base al contenido del nombre y los apellidos.
Actualizacin del campo ImportePagado de recibos, AFTER INSERT, UPDATE
y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la
suma de los pagos de ese recibo.
Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso
de creacin de la matrcula (o un trigger AFTER INSERT), que crea los recibos de
la matrcula en base al importe y forma de pago seleccionadas.

En las prximas semanas continuar esta serie de artculos, describiendo otros submodelos
de sistemas que hemos desarrollado algunas ideas que tengo:

1. Gestin de horarios y citas

2. Facturacin
3. Gestin de horas trabajadas
4. Stock

Espero que este ejemplo de modelo entidad-relacin os sirva de ayuda, me gustar leer
vuestros comentarios.