Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Matriculacin)
marzo 29, 2010 en General, Procesos
En el desarrollo de software para empresas, el almacenamiento de la informacin de un modo
organizado es fundamental la mayora 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 aplicacin. En este artculo voy a intentar
explicar, con un ejemplo prctico, un buen modelado de datos.
Como, de alguna forma, estamos especializados en el software de gestin de empresas de
enseanza, voy a utilizar un ejemplo de uno de esos modelos: la gestin de matriculacin de
los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos.
Voy a explicar en este artculo el funcionamiento del proceso (para que podamos hacer el
seguimiento de la implementacin), 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.
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 pequea cantidad del primer recibo.
En el siguiente da 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 descripcin de la estructura de tablas y columnas para almacenar la
informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos.
Generalidades
Hay algunas cosas bsicas a la hora de modelizar el modelo de datos que usamos como
convenciones (nomenclatura, cosas as). Por ejemplo:
1.
2.
3.
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.
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
o
no.
o
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.
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.
Slo describir los campos ms importantes, y no incluir los campos de clave primaria y
ajena que se describen en el grfico.
Cursos
o
nombre: varchar(100)
fecha_inicio: date
fecha_fin: date
Formas de pago
o
nombre: varchar(100)
importe_matricula: float. Si adems del importe del curso hay un importe de matrcula,
se marca aqu.
Grupos
o
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.
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.
Clientes
o
primer_apellido: varchar(100)
segundo_apellido: varchar(100)
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
Alumnos
o
primer_apellido: varchar(100)
segundo_apellido: varchar(100)
nombre_completo: varchar(300):
Medios de pago
o
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)
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:
o
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
o
fecha_emision: date
fecha_cobro_completo: date
numero_recibo: varchar(20)
concepto: varchar(50)
importe_recibo: float.
Pagos
o
fecha: date
importe: real
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).
En las prximas semanas continuar esta serie de artculos, describiendo otros submodelos
de sistemas que hemos desarrollado algunas ideas que tengo:
1.
2.
Facturacin
3.
4.
Stock