Un sistema de control de salidas de alumnos de escuelas (TACS)

 

TACS – A System to Authorize Students to Leave the School Building

 

Ayala–Hernández C.C.¹, y Bauer–Mengelberg J.R.²

 

¹ Colegio de Postgraduados, Montecillo, Estado de México. Emails: claudiocah@colpos.mx

² Colegio de Postgraduados, Montecillo, Estado de México. Emails: jbauer@colpos.mx

 

Información del artículo: Recibido: octubre de 2007.
Aceptado: septiembre de 2010.

 

Resumen

Uno de los temas que aquejan a los colegios es el peligro de que sea secuestrado alguno de sus estudiantes o que alguien se lo lleve contra la voluntad de uno de sus tutores. Sin embargo, la mayoría de los productos y servicios enfocados a la seguridad en las escuelas no restringen la salida de alumnos cuando no los recoge alguien autorizado para hacerlo. Se describen los elementos fundamentales del sistema TACS (Total Access Control for Schools) que provee una función de autorización que permitirá o prohibirá la salida de un alumno de una escuela, basando dicho permiso en la presencia de alguna persona autorizada para recogerlo, pero también en los datos del entorno: día de la semana, mes, hora y como dato excepcional, si se trata de una situación de emergencia. Contempla un módulo especial para controlar los alumnos que viajan en transporte escolar y agilizar la subida de los alumnos al camión apropiado. El sistema forma parte de un esquema de seguridad adicional para escuelas, donde se contemplan también las restricciones en los accesos a las áreas de la escuela. Cuenta con los procesos para actualizar todos los datos, especialmente la asignación de permisos para recoger a un alumno con las restricciones de entorno que procedan y autorizar a los que a su vez delegan o asignan tales permisos. El énfasis e interés principal del trabajo está en el diseño del modelo de datos que soporta estas funciones y ofrece un soporte ágil a la función de decisión, objetivo del sistema, es decir, la que autorizará o no la salida de un alumno. El sistema contempla las conexiones con dispositivos para la autenticación de personas y la apertura de puertas, pero no están implementadas.

Descriptores: seguridad en escuelas, control de salida, control de acceso, delegadores, permisos, RBAC, horarios.

 

Abstract

Schools are increasingly concerned about the possibility of a student being abducted, or picked up by someone against the wish of his tutor. However, most products and services offered as part of school security systems do not even address this problem. The main elements of the system TACS (Total Access Control for Schools) whose objective is to prevent kids leaving a school if they are not picked up by somebody authorized to do so, are described. A special component dedicated to school buses helps control and speed up boarding the students that should be in a bus before it departs is planned but not yet included. Constraints on such permits may include limitations of the date and time of day in which a particular kid may be picked up. Special circumstances such as emergencies are also considered. The system is the main component of an additional security scheme for schools, where access to some areas of the school may be restricted in some way. The system includes all processes necessary to update the data, especially the permits of persons who may pick up a particular student, with the appropriate constraints. It also provides the functionality to have others delegate or assign these permits to third parties. The emphasis and main interest of the paper is on the design of the data model to support these functions so as to provide efficient use of the information by the resulting decision function – let the student pass or not according to the date and presence of a certain person. Connection to control devices to authenticate persons and to activate the opening of doors is planned but not implemented.

Keywords: school security, access control, exit control, delegators, authorizations, RBAC, schedules.

 

Introducción

Ante la creciente preocupación de padres de familia, maestros y autoridades académicas por aspectos de seguridad de los alumnos en las guarderías, colegios y otras instituciones de tipo escolar, se ha observado que un aspecto preponderante no está entre los más comentados o estudiados en cuanto a cuidados y controles. Se trata de restringir la posibilidad de que alguien recoja a un alumno sin tener la correspondiente autorización para hacerlo y de evitar que un alumno o niño abandone la escuela sin que lo recoja alguien autorizado para hacerlo, excepto si tiene permiso especial para irse sin esa circunstancia. La National School Safety and Security Services (http://www.schoolsecurity.org/) dedicada al tema de la seguridad en escuelas, ni siquiera menciona el aspecto de la salida no autorizada de alumnos. G2 Integrate Solutions tiene, entre otros productos, algunos que ofrecen la posibilidad de restringir entradas no autorizadas, tanto al colegio como a áreas del mismo: monitorean a los alumnos y al personal que labora dentro de la institución (Campbell, 2006). Sin embargo, estos sistemas no están enfocados a restringir la salida de alumnos de escuelas; se concentran en quién entra y a quién visita.

En otro aspecto de la seguridad, hay sistemas recientes que están elaborados para monitorear a todo individuo dentro de los colegios, utilizando cámaras de seguridad o un cuerpo de vigilancia, además de utilizar dispositivos que registran el paso de personas por diversos puntos de control. Compass Technologies, Inc., anuncia que el control de acceso electrónico EAC (Electronic Access Control), proporciona un componente importante para un plan integral de seguridad, no sólo informando quiénes entran al edificio y a qué hora lo hacen, sino creando además un historial de las personas que entran a ciertas áreas, detectando vandalismo y revocando permisos en caso de que haya extravíos o destrucciones de las tarjetas de identificación (Cheung, 2005).

Cabe agregar que estos sistemas utilizan distintos dispositivos electrónicos de detección y autenticación de personas, pero no se ha podido concluir cuáles de éstos son los más convenientes. En el caso de alumnos de escuelas, especialmente niños pequeños, el problema sigue latente: por un lado, no portarán ningún dispositivo removible si lo pueden evitar, y por el otro, no se puede usar uno no removible, como un implante de una microficha, porque hay mucha oposición por parte de la sociedad basada en consideraciones éticas y de derechos humanos (Fusaro, 2004). Por eso se han contemplado –y en muchas escuelas se han usado– diversos procedimientos de seguridad para recoger a los niños, de los cuales destaca colocar dentro de la mochila del niño una tarjeta con información particular del tutor y en la que éste mantendrá actualizada una lista con un máximo de tres personas a las que puede delegar el permiso de recogerlo. Si alguien intentara llevarse al niño y éste no lo conociera, el pequeño debería avisar a su maestro o padre de familia solicitando ayuda (Fitzgerald, 2009). Sin embargo, estos procedimientos no son seguros y su aplicación está limitada por las tareas adicionales que imponen a los encargados de aplicarlos. Esto sugiere la conveniencia de contar con un sistema que contemple dichas autorizaciones y que sea sencillo de utilizar.

Precisamente para coadyuvar con la responsabilidad de las autoridades de la escuela en este sentido, se decidió desarrollar el sistema de información TACS (Total Access Control for Schools) que se describe en este artículo, cuya función principal es la de otorgar o negar a un alumno el permiso de salir del colegio, dependiendo de la presencia de una persona autorizada para recogerlo ese día. Como caso particular, se contempla un módulo dedicado al transporte escolar, que no sólo controla que los alumnos que deben viajar en un camión, y sólo ellos, estén cuando el camión parte de la escuela. Esto también afectará el problema de estacionamiento temporal del vehículo, puesto que no acudirá a la puerta hasta que no estén presentes todos los alumnos que deben subir.

El diseño del sistema presentó suficientes aspectos interesantes como para motivar este trabajo, con el objeto de compartir con otros el tipo de modelo desarrollado y algunas consideraciones tanto en relación con la funcionalidad, como con el modo de incluirla en los procesos de actualización y uso de los datos involucrados. Puesto que el funcionamiento del sistema depende en gran escala de los procedimientos o mecanismos utilizados para identificar a los involucrados en un permiso, la persona que está presente para recoger a un alumno y el alumno mismo, el sistema se diseñó contemplando cualquier tipo de dispositivos de autenticación y detección de la presencia de personas.

Primero se detallan los requisitos que se impusieron al sistema para esta primera versión y que afectaron el diseño del modelo y las funciones mencionadas. Posteriormente, se describen los componentes principales del modelo de datos. Se incluyeron descripciones consideradas dignas de mención de actividades del proceso que condujo al modelo seleccionado. Se ilustra la función principal del sistema, la que autoriza o no la salida del alumno. Algunas conclusiones y reflexiones completan el trabajo.

 

Requisitos que se formularon para el sistema

Sólo usuarios autorizados pueden iniciar una sesión de trabajo del sistema. Éstos tendrán un número único y el sistema contendrá datos para su autenticación. Inicialmente se usarán fotografías y palabras claves, pero se contempla el uso de otros dispositivos (microchips, dispositivos biométricos, etc.) Cada usuario tendrá permisos para ciertas funciones, al tiempo que no podrá usar las restantes. Esto se implementará con un modelo tipo RBAC (Role Based Access Control) basado en roles que se definen para los diversos tipos de usuarios (Bauer Mengelberg, 2005).

Para cada alumno, habrá personas que lo pueden recoger: los llamaremos "recalu". Sin embargo, se podrán imponer restricciones en cuanto a los días en los que pueden hacerlo y agregar horarios para algunos o todos esos días. No se podrá establecer más de un rango de horas por día (ya sea para permitir o prohibir ese rango de horas.) Los horarios no tendrán minutos. Para habilitar a una persona para recoger a un alumno, el que efectúa la operación deberá ser un "delegador".

Hay un procedimiento definido por la escuela para introducir los primeros delegadores de cada alumno, que a su vez, podrán delegar esta condición a otras personas. Los primeros delegadores no tienen restricción en cuanto a los días en los que pueden delegar a terceros los permisos, pero podrán imponer tales restricciones a los que reciben el nuevo permiso. Finalmente, un delegador puede restringir o autorizar a un recalu para algún horario de algunos días, pero sólo en aquellos días en los que tiene permiso para hacerlo. Se usará el término genérico "portero", para indicar a la persona (o dispositivo) que autoriza o no la salida de un alumno. También podrá haber tantos porteros como sean necesarios en alguna instancia del colegio (por ejemplo, en varias puertas).

El sistema deberá proveer al portero los datos necesarios para identificar al alumno y al que lo viene a recoger. El alumno podrá salir si está presente cualquiera de los recalu autorizados para ese día y en ese horario. El sistema usará datos de un año escolar. Se especifica el mes inicial, al que el sistema considera el mes 1. Por lo tanto, el sistema no incluye el año en ninguna de las fechas que se registran y ordenará correctamente cualesquiera datos de acuerdo al calendario escolar. Habrá procesos para iniciar un ciclo escolar: los alumnos, las personas que pueden ser los recalu iniciales y algún procedimiento aceptable para indicar los "delegadores iniciales" para cada alumno. Habrá usuarios que actuarán como "delegadores sustitutos" para introducir datos de delegadores que no tienen la oportunidad de hacerlo ellos mismos, es decir a distancia.

Como componentes útiles, pero no incluidos en la presente versión del sistema, se contempla el concepto de "lotes de alumnos" que deberán salir en forma simultánea. Esto será especialmente aplicable a los que usan el transporte escolar.

Entre otros motivos para incluir esta funcionalidad está la de reducir problemas de tránsito: el autobús no llegará a la puerta hasta que no estén presentes todos los alumnos que se subirán a dicho vehículo. Lo mismo pasa con los autos que recogen alumnos: no se aproximan a la puerta mientras no estén esperando los alumnos que viajarán en dicho auto.

 

Funciones del sistema

A partir de estos requisitos, se definieron las principales funciones que necesita el sistema para ofrecer la posibilidad de limitar la salida de los alumnos. Naturalmente hay muchas otras funciones en el sistema, pero aquí sólo se detallan las que afectaron el diseño del modelo de datos con las entidades fundamentales. Cabe agregar que el diseño se efectuó comenzando con un método estructurado, pero aquí se describe vía requisitos, que se transforman en funciones, mismas que son las que debe soportar el modelo de datos adoptado. Las funciones se presentan en una lista para obviar la adopción de una sintaxis tipo oraciones. El orden en el que están enlistadas no tiene ningún significado: no indica ni precedencias ni algún tipo de dependencia entre ellas, aunque las hubiera.

1. Actualización de "personas" de todo tipo que usa el sistema, incluyendo especialmente a los alumnos y a los que serán delegadores y/o recogedores de alumnos.

2. Introducción de delegadores iniciales para cada uno de los alumnos, sin restricciones de periodo ni horario para delegarlos a otros.

3. Proceso para crear otros delegadores por delegadores, ahora sí con la posibilidad de restringir periodos, pero únicamente dentro del periodo o días permitidos al que los crea.

4. Proceso para autorizar a recalus en ciertos periodos. Deberá contemplar autorizaciones por mes, día, rango de días o días de semana. Los días en los cuales esa persona puede recoger al alumno se podrán introducir por inclusión o exclusión. Se podrán indicar restricciones de horario de dos modos: un rango de horas en el que puede recogerlo, o uno en el que no lo puede hacer.

5. Proceso con el cual se informa al sistema que hay una persona presente, que pudiera ser un recalu de algún alumno.

6. Proceso que se invoca cuando un alumno pretende salir del colegio.

Puesto que esta última función es la que da lugar al sistema, comenzaremos por su descripción. Es una función verdadero–si/falso–no, y empleando la notación: alu = código del alumno, recalu= código de la persona para la cual se valida que tenga la autorización para este alumno, se tiene:

F (alu, recalu, mes, día, hora) = falso/verdadero

Tomará el valor "verdadero" o "si" cuando la persona indicada como "recalu" tiene registrado el permiso para recoger a ese alumno, ese día y a esa hora. En la figura 1 se presenta este concepto en forma esquemática.

Observación: para incluir la posibilidad de que un alumno pueda salir solo (sin que lo recojan) en ciertos horarios, se crea una persona "virtual" (llamada nadie) que siempre está presente y que puede recoger a cualquier alumno en los horarios autorizados.

 

Los datos principales y las dificultades que se presentaron al formular el modelo de datos

Se trataba de diseñar el sistema TACS que tuviera como función primordial la anunciada: evitar que un alumno saliera de la escuela sin que lo recogiera alguien autorizado para ello. Se describen las dificultades que presentó el diseño de un modelo de datos que permitiera definir e implementar las funciones críticas: la actualización y uso de los datos relacionados con los llamados recalus y los delegadores. Puesto que muchas veces los delegadores serán padres de familia que usarán el sistema solamente para ese efecto, en todo momento se asignó una prioridad elevada al hecho de poder ofrecerles los modos más comprensibles y sencillos para introducir los permisos y para autorizar a terceros para que fungieran como delegadores. Sin embargo, se tomó muy en cuenta la eficiencia computacional que proporcionaría el modelo de datos seleccionado. Para formular el modelo, naturalmente se concentraron los requisitos para poder determinar exactamente cuáles datos serían necesarios.

Para cada persona se guardarán los permisos concedidos para cada uno de sus alumnos. Adicionalmente, para la formulación del modelo se tomarían en cuenta las facilidades dadas a los usuarios que asignan tales permisos; en el TACS se llaman delegadores de permisos. Entre otros, se pretende que un delegador pueda permitir o prohibir un rango de días, un día de semana o todo un mes. Por ejemplo, se puede indicar a X la facultad de asignar a Y el permiso de recoger a Z en septiembre, pero no los jueves. Puede suceder que el 7 de septiembre (que es un viernes), la mamá de Z decide que Y lo recogerá el día jueves 13 de septiembre. En otras palabras, hay dos instrucciones inconsistentes o aún contradictorias (no puede los jueves pero sí puede el jueves 13.)

En una etapa del diseño del modelo de datos, se usaba una tabla que tenía como índice primario: recalu + alumno + mes + día + día–de–semana, donde algunos de los últimos 3 campos podían tener valor 0 (cero), lo que indicaría "todos". Además, tenía los campos para especificar el día inicial y final del periodo que se autorizaba o prohibía y un campo de "permitido" o "prohibido" para esas fechas, que indicaba si el período establecido era de exclusión o de inclusión de esos días.

Al intentar determinar si puede salir el alumno A, dada la presencia de una persona con identificación P, el sistema buscaría en las autorizaciones de P como recalu del alumno A. Con el modelo que permite la introducción de datos contradictorios, esto se podría ver afectado por datos de ese tipo. Se intentó adjudicar prioridades a los diversos registros. Primero se usó el criterio: prohibiciones tienen prioridad sobre los permisos. Como esto resultó insuficiente o equivocado, se adoptó un criterio cronológico, el dato más reciente tenía precedencia sobre los que ya estaban. Al diseñar los programas con los que se actualizaban estos datos, surgieron dificultades que pusieron en evidencia que el modelo no era el que se adoptaría. De hecho, había que crear una estructura para poder determinar la validez de un período nuevo que se agregaba o un cambio a los que tenía ya el recalu.

Con esta experiencia, se llegó a la conclusión de que, para evitar contradicciones o problemas, convenía almacenar los datos "al revés". En lugar de guardar los horarios permitidos o prohibidos, se almacenarían, para cada día, si el recalu tenía o no permiso para ese alumno. De hecho, se probaron dos modelos parecidos. En uno, la ausencia de un día significaba que no tenía permiso. En el otro, se podrían incluir prohibiciones para cualquier día. Este modelo se desechó porque no agregaba funcionalidad al sistema, sólo complicaba el modelo.

El esquema: "guardar los permisos" por día, se concretó en un modelo de datos que sólo se muestra como etapa intermedia, puesto que no fue el adoptado. La tabla donde se almacenaban los datos de los permisos de un recalu–alumno tenía como índice principal (recalu + alumno + mes + día). Esto no sólo resultó extraordinariamente ineficiente –¡la mamá de un niño tenía 250 registros en esta tabla!– sino que, una vez más, el proceso de actualización, en muchos casos, exigía una reestructuración después de conseguir los datos, para permitir su uso posterior. Esto sucedía, por ejemplo, cuando había que introducir una prohibición del tipo "no puede recogerlo los jueves". Esto causó un rediseño del modelo en cuanto a su diseño físico, pero se conservaron los datos que se almacenarían.

 

Modelo de datos

Lo anterior condujo al diseño de la base de datos adoptado para el TACS, cuyas tablas relacionadas con la parte sustantiva, es decir, las autorizaciones a alumnos para salir de la escuela, que se describen a continuación. En lugar de usar un registro para cada día permitido, se guarda un indicador de "sí o no tiene permiso", representado por un valor 0/1, para cada día de cada mes, en un arreglo de 31 días por mes. La representación por una cadena de 31 caracteres se reemplazó por una cadena de bits, representada por un número de 32 bits, que se almacena como un entero de 4 bytes.

Resumiendo, para cada recalu, tendremos 12 campos de tipo entero de 4 bytes, uno para cada uno de los meses, mismos que como ya se dijo se numeran por ciclo escolar y no por calendario. Esto resultó en una reducción considerable en cuanto a espacio en disco. Esta circunstancia carece de importancia en muchas instancias, por las cardinalidades típicas involucradas y por la enorme capacidad de los dispositivos. Sin embargo, es una tradición de sistemas bien diseñados no desperdiciar recursos. Lo mismo se puede afirmar de la reducción de los procesos, que aunque es muy grande proporcionalmente, tiene poco impacto sobre el desempeño de los mismos. Típicamente, reducir un proceso en un factor de 20 no se nota si inicialmente demoraba 20 milisegundos, especialmente en operaciones que no se realizan simultáneamente en forma masiva. Sin embargo, el impacto es grande en los que desarrollan el sistema, puesto que tienen la constancia de que han hecho bien su trabajo. Cabe agregar que la eficiencia que proporciona el modelo podría ser importante en su uso para otras puertas de una escuela, es decir, no solamente la de salida. En estas otras puertas podrían llegar muchos niños simultáneamente, donde esto naturalmente significa que el intervalo entre los arribos es muy corto, puesto que cualquier dispositivo utilizado para identificar a los que desean pasar por la puerta, lo haría en forma secuencial, uno tras otro.

Para determinar si un recalu tiene permiso en un día de un mes, se determina si el bit correspondiente a ese día es 0 ó 1. Puesto que los bits se usan de derecha a izquierda, es decir, el día 1 será representado por el bit 0 del número, para determinar si el bit correspondiente a un día tiene el valor 1 se interseca el entero que contiene los permisos de cada día con el valor correspondiente de 2^dia–1. Si el bit estaba encendido, el resultado será igual a 2^dia–1. De lo contrario, será 0 (cero.) Observe que para no tener que calcular la potencia de 2 en cada uso, se almacenan las potencias en un arreglo Arr_potencias_de_dos (0 to 30) de valores enteros de 4 bytes, en el cual se almacena la potencia de 2 correspondiente al índice del arreglo. De este modo, se ejecuta la instrucción: Puede salir = (N Arr_Potencias_de_dos (día – 1) > 0).

En el ejemplo que se ilustra en la figura 2, se permiten sólo los días 3, 7 y 23 de algún mes. Por lo tanto, el campo entero resultante tendrá el valor 2^3–1 + 2^7–1 + 2^23–1 = 4194372

Para los delegadores, es decir, los días para los cuales una persona puede delegar en otro los permisos para un alumno dado, se utilizó exactamente el mismo esquema de los 12 números que, vía sus dígitos, representan cada uno de los días del mes.

 

Restricciones de horario

En algunos casos será necesario limitar el horario en el que una persona puede recoger a un alumno dado. El modelo que se adoptó es un tanto complicado, pero es eficiente y satisface todas las restricciones impuestas al sistema relacionadas con estos horarios. Es importante resaltar que la complejidad es interna y que los usuarios del sistema, al no conocer el modelo, no sufrirán por sus complicaciones.

Para poder guardar horarios se incluyó, por cada recogedor–alumno, una marca que permite identificar los casos tales como: el delegador quiere o no restringir el horario del recogedor, y en caso afirmativo, cuando la autorización aplique sólo a ciertos días o a todos ellos del mismo modo.

A la tabla RECALU se le agregó un campo llamado "tiene_restric_horarias" (tiene o no restricciones horarias) que toma uno de los 4 valores:

0 = no hay restricciones horarias.

1 = puede en el horario que se puso en el campo

"horario_todos_sus_dias"

Aplicable a todos los días.

2 = no puede en el horario colocado en el campo

"horario_todos_sus_dias"

Aplicable a todos los días.

9 = hay restricciones en una tabla "horperalu"

Aplicable sólo a ciertos días.

Para el caso en el que hay un horario que se aplica a todos los días, se usa un campo entero (horario_todos_ sus_dias) de 1 byte que toma el valor: 10 * hora inicial + número de horas del periodo. No se pueden incluir, ni se necesitan, periodos de más de 9 horas. Naturalmente se usan las horas indicadas como 00 a 23. Por ejemplo, el valor 105 indica un horario desde 10 a 15 hrs. (10am a 3pm). El sistema no permite restringir horarios especificados en minutos. Si el indicador dice que "puede", el recogedor sólo podrá recoger al alumno en el horario indicado en el otro campo (horario_todos_sus_dias), mientras que si el indicador vale 2 (no puede) podrá recoger al alumno sólo antes o después del periodo indicado. Por ejemplo un valor de 114 significa que entre las 11 de la mañana y las 15 de la tarde, dependiendo del indicador, podrá o no recoger al alumno en ciertos horarios.

Indicador = 1: sólo puede recogerlo de 11 a.m. a 3 p.m.

Indicador = 2: sólo puede antes de las 11 o después de las 3pm.

Cuando el indicador vale 9, los horarios aplicables están en otra tabla de la base de datos (horperalu), donde se podrán almacenar horarios que se aplican sólo a ciertos días. Por lo tanto, para éstos, será necesario especificar los días a los cuales se aplica, además del horario mismo. También, se usó un artificio aritmético para indicar si "puede o no" en ese horario: un valor positivo indica que puede, mientras que uno negativo que indica no puede recogerlo en ese horario (es decir, sólo lo podrá recoger antes de la primera hora o después de la última que define el período.) Otra vez se optó por almacenar varios horarios en un mismo registro y por una decisión técnica se limitó el número de tales horarios a un máximo de 20. Cada uno de los campos que indican uno de estos horarios, llamados "horario_día", tiene un valor formado por la hora inicial * 10 + la duración en horas del periodo, de modo análogo al descrito anteriormente para los horarios que se aplican a cualquier día. El otro campo, llamado simplemente "días", contiene datos que especifican a qué mes, día o días y día de semana, corresponde el horario respectivo. En la tabla 1 se muestra como se almacenan los horarios en los distintos casos para los cuales se aplica el horario indicado, y en la tabla 2 se ilustra un ejemplo de cada uno de ellos, donde se observa que el signo negativo indica una prohibición. Los meses están numerados de acuerdo al periodo escolar: el mes 1 es el mes en el que inicia el ciclo escolar.

Los días de semana se indican a nivel bit (7 bits=7 días de la semana), donde el día inicial de la semana es el lunes, representado por el bit 0. Por ejemplo, para indicar los días 1 (lunes) y 4 (jueves), se usaría el valor 9 (0001001), mientras que para todos los días de la semana, el valor apropiado sería 127 (1111111).

El programa de actualización de las restricciones por horarios aplicables a ciertos días no permitirá que se introduzcan horarios contradictorios. Por ejemplo, un dato válido para todos los meses no admite uno contrario para algún día de algún mes específico. Un ejemplo más sencillo sería: si hay un horario que se aplica a todos los martes de un mes y se desea cambiar el horario de uno de dichos martes, el sistema lo rechaza o arregla el problema grabando cada uno de los "otros" martes como horario individual y luego agregando el horario para el martes en cuestión.

Adicionalmente, el programa que usa los horarios siempre da prioridad al dato más específico: un día tiene prioridad sobre un día de semana, un día de un mes la tiene sobre el mismo día de todos los meses. Si se desea agregar una restricción horaria pero están ocupados los 20 campos disponibles, primero se eliminan los horarios vencidos (de días anteriores) y se recorren las restricciones. De hecho, se aprovecha cualquier proceso que usa estos datos para eliminar horarios vencidos. Si después de comprimir el arreglo aún no cabe el dato nuevo, se deberá posponer su inserción o eliminar uno que se aplique a una fecha posterior a la que indica el dato que deseamos introducir. Cabe señalar que no es probable que se presenten tantas restricciones de este tipo para alguna combinación de un alumno y un recalu, de modo que la restricción impuesta por el diseño (no permitir más de 20 tales valores) no afectará la aplicabilidad del modelo.

 

Descripción del contenido de las tablas que constituyen el modelo de datos

En la figura 3, la tabla PERSONAS: contendrá el registro de todas las personas, tanto usuarios del sistema (delegadores, capturistas de datos) como personas de quienes se guardan datos en el TACS (recogedores, alumnos). Los datos incluyen datos personales, de localización, de descripción "física" y de autenticación. Para el sistema definitivo se contemplan otros datos, por ejemplo, datos sobre el auto que conducen, o si son varios, los de cada uno de éstos.

Tabla DELEGADORES: además del par al que se aplica (recogedor y alumno) almacenará la información que indica el periodo para el que puede delegar a otra persona un permiso. Los permisos se almacenan en 12 campos numéricos de 4 bytes cada uno, mismos que se llaman "mes_1", "mes_2", etcétera.

Tabla RECALU (permiso–persona–alumno): almacena un registro por cada par recogedor–alumno y contiene la información necesaria para autorizar o prohibir la salida del alumno en presencia de esta persona y las restricciones horarias, ya sea anotadas en el mismo registro o en uno de la tabla Horperalu. Los permisos se almacenan en 12 campos numéricos de 4 bytes cada uno, con los mismos nombres que los descritos para la tabla "delegadores".

Tabla HORPERALU (horarios para un recalu): complementa a la tabla Recalu cuando hay que almacenar horarios aplicables a ciertos días y no a todos los que tiene autorizado ese recogedor.

Los campos denominados "audit" que se incluyeron en las tablas son cifras de auditoría calculadas a partir de los otros campos. El sistema de protección de datos contra actualizaciones no autorizadas, es decir, efectuadas sin utilizar las funciones del sistema y que están protegidas contra el uso por personas no autorizadas tiene, entre otros artificios que recomienda y usa uno de los autores de este trabajo en sus apuntes no publicados (por ser secretos), el cálculo de números obtenidos por operaciones secretas sobre los valores de los campos. Estos cálculos los efectúan los programas y son casi imposibles de reproducir sin ellos. En cuestiones como las de seguridad escolar, es crítico el tema de impedir que alguien pudiera alterar los permisos para obtener algún tipo de beneficio o, lo que no es equivalente pero igualmente indeseable, causar un perjuicio a otro.

Naturalmente el sistema TACS utiliza otras tablas, tanto de esta misma base de datos como de otras. Entre ellas se pueden mencionar la de Usuarios del TACS, las bitácoras (de salidas autorizadas, de asignación de permisos y otras que surjan) que constituirán una parte importante del sistema de seguridad integral de una escuela. En las conclusiones se menciona el tema de lotes de alumnos, mismo que da lugar a otras estructuras de datos y por ende, tablas adicionales en la base de datos.

 

Conclusiones

La identificación y el registro del movimiento de personas han pasado a resultar una necesidad crítica en todo colegio. En muchas situaciones, hay que conocer en todo momento el contexto del movimiento y dado el caso, proporcionar la información para la autorización o prohibición del movimiento.

En particular, el TACS contempla el uso de cualquier tipo de dispositivo de autenticación, tanto para un alumno que desea salir como para la persona que se presenta para recogerlo. Por otro lado, la necesidad de poder restringir los permisos de una persona para recoger a un alumno, planteó un problema de diseño de bases de datos, que se resolvió con el modelo descrito, mismo que resultó eficiente en cuanto a almacenamiento y proceso de la información, pero en especial, facilitó el uso de los datos tanto para sus usuarios, que deben actualizarlos, como para los programadores que tuvieron que hacer los programas correspondientes.

Como investigación futura se propone ampliar la funcionalidad, y por ende, el modelo para incluir el concepto de "lote de alumnos": los que se deben ir juntos, con una persona que los recoge a todos. El caso más crítico es cuando llega un camión escolar, que se lleva a todos los alumnos que están inscritos para tal efecto, pero contemplando todas las excepciones que se pudieran presentar, tales como que un alumno no fue al colegio ese día, lo recogieron antes o tiene alguna obligación en el colegio y no se irá a esa hora. También se ampliará el uso del sistema para controlar las entradas y salidas a otros espacios, como un laboratorio o un patio, para saber quiénes los ocuparon, o en su caso, prohibir el acceso. Esto podría estar condicionado a la presencia de algún maestro o encargado, o estar limitado por la capacidad del área protegida de este modo. Estas investigaciones incluyen en modo preponderante el uso de dispositivos que permitan detectar la presencia o llegada de una persona a un punto de control, no sólo cuando el arribo se produce en forma individual, sino también cuando llegan personas en tropel, como sucedería en un colegio.

 

Referencias

Bauer–Mengelberg J.R. Issues in Informing Science and Information Technology. Teaching System Access Control 2005 [en línea]. [Consultada el 25 de Agosto de 2010]. Disponible en: http://proceedings.informingscience.org/InSITE2005/I12f27Baue.pdf        [ Links ]

Campbell S. G2 Integrated Solutions Ltd, Access Control: ESi Access Control System 2006 [en línea]. [Consultada el 16 de julio de 2010]. Disponible en: http://www.g2is.co.uk/solutions/access–control–system/access–control–systems.html        [ Links ]

Cheung C. Compass Technologies, Inc. The Right Direction in Access Control and Security Management: A Critical Element in Security Planning 2005 [en línea]. [Consultada el 16 de Marzo de 2007]. Disponible en: http://www.compasstec.com/pdf/K12.pdf        [ Links ]

Fitzgerald P. Child Safety Tips: Back to School Part 2 2009 [en línea]. [Consultada el 28 de Julio de 2010]. Disponible en: http://instantamber.com/news/child–safety–tips–back–to–school–part–2/        [ Links ]

Fusaro R.A. Harvard Business Review. None of Our Business? (HBR Case Study and Commentary) 2004 [en línea]. [Consultada el 23 de Agosto de 2010]. Disponible en: http://hbr.org/2004/12/none–of–our–business/ar/1.         [ Links ]

 

Bibliografía sugerida

Albrecht K. Consumers against Supermarket Privacy Invasion and Numbering. Implantable rfid chips: human branding 2007 [en línea]. [Consultada el 24 de Agosto de 2010]. Disponible en: http://www.antichips.com/        [ Links ]

Breen O.J. Preschool and Kindergarten Camp Forms 2010. [en línea]. [Consultada el 25 de Julio de 2010]. Disponible en: http://www.st–charlesparks.org/Information/pdfs/campforms2010_preschoolE.pdf        [ Links ]

Raghu–Ramakrishnan J.G. Databases Management Systems. Second Edition. McGrawHill Higher Education. 2006. ISBN 007246535–2.         [ Links ]

Silverman–Scott R. VeriChip Corporation. Rfid for people: Delivering Rfid Solutions for people 2007 [en línea]. [Consultada el 24 de Septiembre de 2007]. Disponible en: http://digital.virtualmarketingpartners.com/nxbooks/vmp/verichip/index.php.         [ Links ]

 

Semblanza de los autores

Claudio César Ayala–Hernández. Ingeniero en computación por la Universidad Autónoma del Estado de México. Maestro en ciencias por el Colegio de Postgraduados. Actualmente es Crop Informatics Specialist en el Centro Internacional de Mejoramiento de Maíz y Trigo (CIMMYT, Int.). Sus áreas de interés son: tecnologías, sistemas de información y datos moleculares.

Juan Ricardo Bauer–Mengelberg. Licenciado en matemáticas por la Universidad de Buenos Aires, Argentina, obtuvo su PhD en estadística e investigación de operaciones por la Universidad de Wisconsin, Madison, Wis. Tras dedicarse a la cátedra en ambos países, ahora lo hace en México, en el Colegio de Postgraduados, desde 1971 en el área de computación estadística y aplicada, especialmente en sistemas de información. Ha desarrollado numerosos sistemas para el sector privado, gubernamental y universitario, es creador de paquetes para distintos usos. Como miembro del Informing Science Institute, se dedica a la comunicación vía computadora y al uso de datos provenientes de fuentes y estructuras heterogéneas.