Espe tecnicas siia_2

Programa para la Normalización de la Información Administrativa

Módulo de recursos humanos

Las funciones fueron agrupadas en cuatro subsistemas; el primero se refiere a todas
aquellas funciones exclusivas para el personal docente, en el siguiente se agrupan aquellas
funciones exclusivas para el personal administrativo y/o trabajadores, el tercer subsistema
incluye todos los procedimientos y funciones para la elaboración de la nómina y el último
abarca todas aquellas prestaciones de carácter general para quienes laboran dentro de la
institución. Cabe aclarar que este agrupamiento no es el único válido y que dependerá de
las características, funcionamiento y estructura orgánica de cada universidad.

Registro y control del personal administrativo

Movimientos de personal
A través de este proceso el usuario podrá dar altas, bajas y modificar la información de
los diferentes campos que integran la base de datos de personal administrativo conforme
a los procedimientos que establezca cada institución.
A continuación se describen algunos de los movimientos que permitirá registrar el
subsistema:
• Altas de personal administrativo (eventuales)
Consiste en otorgar una plaza eventual para efecto de una obra determinada durante
un periodo de tiempo determinado. Una vez autorizado este movimiento el trabajador
deberá ser dado de alta en la base de datos de la institución, así también el contrato de
trabajo asociado al mismo.
• Basificación
Se refiere a la integración definitiva de un trabajador a una plaza tabulada o de base.
• Bajas de personal eventual
Se refiere a la rescisión o terminación de la relación de trabajo del personal eventual.
En términos del sistema este movimiento tendría que ser automático, esto debido a que al
momento de su contratación queda establecido el periodo del contrato por lo que al arribar
a la fecha de terminación, el sistema automáticamente los excluye de la nómina.
• Bajas del personal administrativo de base
Se refiere a la posible rescisión o terminación de la relación de trabajo del personal de
base.
Aun cuando este tipo de movimiento no resulta muy común, en ocasiones se llega a
presentar. Estos movimientos habrán de generar pagos extraordinarios por concepto de
liquidación.

P R O N A D
P R O N A D

74

Especificaciones técnicas del SIIA Descripción del sistema computacional integral

• Prejubilación
Este tipo de movimientos sólo se presenta en aquellas instituciones en dónde dentro
del contrato colectivo de trabajo, se establecen condiciones para lograr esta prestación.
Los prejubilados son trabajadores que acumulan los años requeridos por dicha institución
para jubilarse, mas no la cantidad de años señalada por el ISSSTE. Por lo que a pesar de
alcanzar el estatus de prejubilados siguen trabajando, pero bajo otras condiciones salariales.
• Jubilación
Se refiere al movimiento que se genera cuando el trabajador alcanza este estatus.
• Recontrataciones
Para la realización de contrataciones bastará con volver a dar de alta a aquellos
trabajadores eventuales cuyo contrato hubiera concluido.
• Cambios de adscripción
Se refiere al proceso mediante el cual un trabajador cambia de lugar de adscripción al
que se encontrará asignado.
• Cambio de categoría y /o nivel
Se refiere al procedimiento mediante el cual un trabajador modifica su nivel y/o categoría.
Para este tipo de movimiento tendrá que quedar registrado quién autorizó y quién ingresó
el movimiento.
• Pago de riesgos
Este beneficio sólo se otorga en algunas instituciones y se refiere al pago que reciben
los trabajadores por los riesgos de laborar en unidades orgánicas con lugares insalubres
y laboratorios donde se manejen sustancias químicas tóxicas que pudieran atentar contra
la salud y el bienestar de los trabajadores.
• Primas especiales
Este tipo de beneficios lo otorgan algunas instituciones a aquellos trabajadores que
cumplen alguna condición de trabajo especial. Por ejemplo, la prima sabatina y dominical
que se ofrece en algunas instituciones para aquellos trabajadores que laboran los fines
de semana.
Seleccionando el registro del trabajador sobre el cual se necesite realizar un movimiento,
el sistema deberá presentar los datos del mismo permitiendo modificar los campos que se
requieran conforme al tipo de movimiento.
Este sistema deberá contemplar las siguientes facilidades:
1. Confirmación de movimientos

P R O N A D
P R O N A D

75


2. Mantener un control estricto sobre todos los movimientos que afecten la base de
datos. Cada uno de estos movimientos deberá ser registrado, almacenándose, entre
otros datos, el RFC, tipo de movimiento, estatus anterior y actual, fecha del movimiento,
persona que autorizó el cambio y el usuario que lo registró en el sistema.10
3. Para aquellos casos en que los valores a ser modificados estén restringidos a ciertos
valores, las modificaciones se deberán realizar a través de menues de tipo “combo-
box” que desplegarán los catálogos correspondientes.
4. Los movimientos de baja deberán reflejarse en una base de datos “histórica” en
donde queden registrados los datos de aquellos docentes dados de baja.
5. El sistema deberá garantizar que los movimientos de altas no generen registros
duplicados. De preferencia se deberá utilizar la CURP como llave de acceso a las
bases de datos de personas.
6. Para cada uno de los movimientos el sistema deberá garantizar la completez de los
datos requeridos para el mismo. Se sugiere que siempre quede registrado quién
realizó el movimiento y quién autorizó el mismo.
Es conveniente que este subsistema cuente con una herramienta de búsqueda /
selección de los empleados en donde el usuario pueda introducir criterios de selección a
través de los cuales se acote el universo de empleados. Los criterios podrán ser tan
estrechos como lo requiera el usuario, por ejemplo, podrá seleccionar todos aquellos
empleados cuyo RFC sea un valor determinado y obtener como resultado un solo registro,
o seleccionar todos aquellos empleados de apellido “Martínez” y que hubieran obtenido
su basificación antes del “5 de mayo de 1994”.

Control de asistencias
El sistema de recursos humanos deberá permitir registrar el número de faltas de cada
uno de los trabajadores administrativos.

Expedientes del personal
El sistema deberá registrar los documentos que ingresan al archivo de personal
administrativo, tales como acta de nacimiento, título, oficios, nombramientos, etc. Para
esto se recomienda la digitalización de los documentos.

Subsistema de personal docente
La funcionalidad y características de este subsistema deberá ser semejante al del
subsistema de personal administrativo, sólo que referente a los movimientos y datos del
personal docente. A continuación describimos algunas de las funciones y procesos a los
cuales deberá hacer referencia este subsistema:

10 El registro de los movimientos permitirá auditar todos aquellos movimientos realizados sobre la base de datos

P R O N A D
P R O N A D

76


• Asignación de cargas de trabajo a docentes
Se refiere al proceso mediante el cual se determinan las cargas de trabajo de los
docentes de todas las unidades orgánicas de la institución. Para cada uno de los docentes
habrá que establecer cuántas horas de clase, investigación, laboratorio, asesoría, etc.,
les corresponden.
Este procedimiento deberá estar perfectamente vinculado con los módulos de control
escolar y asuntos financieros. Las horas de clase y/o laboratorio que se asignen en el
módulo de control escolar tendrán que corresponder con las que aquí se determinen. Así
también, las horas de clase que aquí se asignen no podrán exceder el techo financiero
presupuestado por función “docencia” y ejercicio histórico.
Las cargas de trabajo tendrán que ser validadas a través del sistema y en su caso
ajustadas por la unidad orgánica responsable.
• Basificación de docentes
Procedimiento mediante el cual un docente pasa a formar parte de la planta permanente
de profesores de una institución. Desde el punto de vista de este módulo la operación
resulta importante, ya que incidirá en la nómina y prestaciones que brinda cada institución.
• Cambio de adscripción de docentes
Se refiere al proceso mediante el cual un docente cambia de adscripción.11 Este
procedimiento se aplica sólo en aquellas instituciones en las cuales las basificaciones se
asignan por centro de trabajo.

Actualización de datos y del expediente de personal docente
El sistema deberá integrar los datos personales y curriculares para cada uno de los
docentes. Así también controlar qué documentos se encuentran físicamente en poder de
la universidad. Estos expedientes deberán actualizarse siendo lo más deseable que los
documentos entregados por el docente se encontraran digitalizados.
Entre otros datos se propone la inclusión de la siguiente información:
• Nivel académico
• Áreas de conocimiento
• Estudios actuales
• Congresos
• Seminarios
• Talleres
• Simposios
• Publicaciones

11 Cambio de unidad orgánica

P R O N A D
P R O N A D

77


• Proyectos e investigaciones
• Becas y estímulos
• Especialidad

Además de esta información se podrán consultar todos los datos laborales de los
docentes, tales como antigüedad, nivel, cargas laborales, fecha de jubilación, etcétera.
Entre otros, el sistema permitirá manipular y generar reportes como los siguientes:
• Docentes por categorías y áreas de conocimiento próximos a jubilarse.
• Docentes por categorías y áreas de conocimiento que estén en el sistema
nacional de investigadores.
• Docentes de la institución realizando estudios de posgrado con beca (con
descarga, por área del conocimiento).
• Docentes de la institución realizando estudios de posgrado con beca
complementaria de diversos programas (por área del conocimiento).
• Reporte de personal de carrera de tiempo completo con becas al desempeño
académico por centro, escuela o facultad.
• Cambio de grupo laboral, categoría y/o nivel para docentes.
Se refiere al proceso mediante el cual, una vez aprobado el movimiento por la instancia
correspondiente, se modifica el grupo laboral, categoría o nivel del docente. Cualquiera
de las anteriores modificaciones resultan de gran relevancia ya que se reflejarán en la
nómina. El sistema deberá registrar la fecha del movimiento, la vigencia, el responsable
de la autorización y el usuario que ingresa el cambio al sistema.
• Solicitud de año sabático
Ante la solicitud de año sabático por parte de un docente, la instancia que tenga las
atribuciones para autorizarlo podrá revisar, a través del sistema, que éste cumpla los
requisitos y en su caso ingresar el movimiento.
• Asignación de becas a docentes
En aquellos casos en que las instituciones cuenten con programas para el otorgamiento
de becas a sus docentes, una vez aprobadas por el área correspondiente, se tendrá que
ingresar el movimiento al sistema, señalando entre otros el monto, periodo, fondo de
donde proviene, etcétera.
• Proyectos de investigación
Este procedimiento se refiere a la asignación de un docente a algún proyecto de
investigación en que esté participando la institución.
• Otorgamiento de estímulos a docentes
En caso de que exista el otorgamiento de estímulos dentro de la institución, una vez
expedida la convocatoria y evaluados los docentes que hicieron el trámite, se ingresará

P R O N A D
P R O N A D

78


en el sistema el monto y periodo de los estímulos para aquellos docentes que se hubieran
visto beneficiados.
En aquellas instituciones en donde además de personal administrativo (trabajadores) y
personal docente exista otra clasificación (por ejemplo empleados de confianza), se deberá
agregar un subsistema adicional, en donde se den los movimientos conforme a las
características propias de la categoría.

Subsistema de nóminas
Comprende la generación de la nómina, creación y actualización de los catálogos de
tabuladores, estímulos y descuentos, los procesos para el cálculo y aplicación de
descuentos al personal de la institución, los reintegros y los retroactivos.
Esta función constituye una de las más importantes de todo el SIIA. Baste pensar que
en muchas de las universidades el porcentaje más alto de recursos lo constituye el pago
de este rubro.
La generación de la nómina es un procedimiento ligado de manera muy especial con el
módulo financiero. Conforme a la contabilidad de fondos el sistema tendrá que dejar
perfectamente establecido el desglose por unidad responsable y fondo, así como corroborar
que no se exceda el presupuesto programado para cada una de éstas.
El sistema tendrá que descontar o pagar de manera automática las cuentas a favor o
en contra para cada uno de los empleados de la institución.

Generación de la nómina
Se refiere al proceso de generar las nóminas y prenóminas de los trabajadores, que
recibirán su pago. El usuario entrará a una pantalla, donde podrá teclear el periodo para la
nómina que se elaborará. Tendrá la opción de generar una nómina en forma general o por
unidad orgánica.
Datos de entrada
• Periodo de la nómina
• Selección de nómina o prenómina
Durante la quincena, las diferentes áreas o departamentos relacionados con la
generación de la nómina realizarán diferentes tipos de movimientos para las cuales se
utilizará el Catálogo de Percepciones y Deducciones. Para cada movimiento, se calculará
(por medio de un algoritmo) un monto, lo cual afectará el salario base del trabajador (este
salario será con base en la categoría nivel de los trabajadores, el cual existe en tablas ya
determinadas y calculadas por cada institución). Estos movimientos se registrarán a nivel
sistema en la base de datos de movimientos, el cual almacenará cada uno de los
movimientos que se realizaron para cada trabajador. Cuando se llegue a la quincena y

P R O N A D
P R O N A D

79


sea necesario elaborar la prenómina o nómina, a cada trabajador se le calculará su sueldo
final, una vez que se haya sumado (o restado, según sea el caso) el monto de cada uno
de los movimientos en los que participó a lo largo de la quincena. El Catálogo de
Percepciones y Deducciones se caracteriza porque se aplica de manera general a todos
los trabajadores.
Una vez que se tiene la prenómina completa, es decir todos los movimientos agrupados,
se generará la nómina. Inmediatamente al generarla, los datos almacenados en la base
de datos de movimientos se transferirán a una tabla histórica de movimientos, la cual
contendrá la información de todas las nóminas que ha generado la institución. En la tabla
de movimientos se borrará toda la información, por lo cual ya estará lista para que durante
la próxima quincena, se realicen los cambios y acciones necesarias para cada trabajador.
Una aclaración pertinente respecto a esto, es que la prenómina y nómina tendrán un
estatus (cerrado, abierto), lo cual para poder realizar los movimientos es necesario que
este “Abierta”, ya que a la quincena a la hora de generar la nómina, se cerrará la base de
datos, para no permitir ninguna modificación y generar la nómina correcta.

Deducciones a largo plazo
A partir de este programa el usuario podrá registrar deducciones, las cuales se aplicarán
a un trabajador a largo plazo.
Datos de entrada
Clave deducción
Tipo
Descripción
Fecha en que autorizó la deducción
Fecha inicio deducción
Fecha fin deducción
Monto total
Algoritmo (para realizar el cálculo determinado)
Número de quincenas
Saldo
estatus
Autorizó (aprobado por)
Fecha en que se dio la alta

P R O N A D
P R O N A D

80


Usuario que dio la alta
Fecha de modificación del catálogo
Usuario que realizó la modificación
Asignación de deducciones

A través de esta pantalla, se tecleará la clave del docente, y se seleccionará la deducción
(a través de un combo box cerrado). Una vez confirmado el movimiento quedará registrado
en la base de datos. Así también la información relativa al movimiento.
• Datos de entrada
• Clave o número del trabajador (docente y administrativo)
• Clave de la deducción
• Autorizó
• Fecha
• Usuario

Emisión de reportes
• El principal reporte que se debe generar en este subsistema es la prenómina, para
la revisión de los diferentes departamentos involucrados con esta actividad. Además
de la nómina, la cual permitirá efectuar los pagos correspondientes por parte de
tesorería, la información de la prenómina podrá ser consultada a través del sistema.
• Se necesitará un reporte de los principales catálogos (bonificaciones, descuentos,
retroactivos, reintegros).
• Reporte de todos los trabajadores que cuentan con retroactivos, reintegros,
descuentos y bonificaciones.

Subsistema de prestaciones
En este subsistema se habrán de registrar los movimientos de todas las prestaciones
a las que tiene derecho todo el personal, como pueden ser préstamos en efectivo, en
especie, servicio médico, afiliaciones, jubilación, etcétera.
Catálogo de prestaciones generales12
A partir de este programa el usuario podrá realizar altas, bajas o modificaciones del
catálogo de prestaciones generales.

12 Estas prestaciones no requieren ningún tipo de solicitud para su disfrute. Por cuestiones prácticas se consideran como parte del
salario.

P R O N A D
P R O N A D

81


Datos de entrada
• Clave de prestación general
• Descripción de prestación general
• Monto (cantidad fija)
• Algoritmo correspondiente (para realizar el cálculo, cantidad no fija).
• Aplica (todos, docentes, administrativos)
• Autorizó

Catálogo de percepciones y deducciones
A partir de este programa el usuario podrá realizar actualizaciones al catálogo de
percepciones y deducciones.
Datos de entrada
Clave (de la percepción y deducción)
• Tipo
• Descripción
• Gravable
• Acumulado
• Algoritmo (que realice el cálculo)
• Autorizó (aprobado por)
• Fecha de alta de percepción y deducción
• Usuario que dio la alta
• Fecha de modificación del catálogo
• Usuario que realizó la modificación

Asignación de prestaciones
Se refiere al manejo y control de las prestaciones comunes para todos los empleados
de la universidad (docentes, administrativos y trabajadores) ya sea que se trate de
prestaciones en efectivo, especie o a través de vales.
Estas prestaciones se darán de alta a través de los catálogos correspondientes,
señalándose al hacerlo si se trata de una prestación individual o colectiva.

P R O N A D
P R O N A D

82


Se refiere al proceso de asignar al trabajador las prestaciones que se merece. A través
de una pantalla, se tecleará la clave del docente y de la prestación, y al relacionarla (al
presionar el botón de Actualizar) quedará la asignación registrada en la base de datos del
sistema.

Datos de entrada:
• Clave o número del trabajador (docente y administrativo)
• Clave de la prestación

Reportes del subsistema de prestaciones
Reporte del catálogo general de prestaciones
Reporte de todos los trabajadores que están asignados a cualquier prestación.

Subsistema de consultas y reportes de personal
A través de este subsistema se habrán de generar las consultas y los reportes que
permitan tener un control sobre el personal de la institución. Entre otros los que a
continuación se describen:
Se requiere que el sistema muestre una pantalla de reportes, en donde se pueda
seleccionar el tipo de consulta o reporte que se desea. Con base en el tipo de reporte en
la pantalla aparecerá una serie de catálogos donde se elegirá la información para el reporte,
así como los agrupamientos y ordenamientos que se requieran. Al tiempo de que se
hagan las consultas, los departamentos que tengan acceso a realizar modificaciones en
el sistema podrán efectuar los cambios de algún registro en particular con sólo dar doble
click en el mismo. Para todo tipo de reporte deberá haber una opción o botón de impresión.
• Reporte de movimientos de empleados, que han realizado algún cambio en sus
datos
El sistema generará un reporte que permita verificar todos los movimientos que se
hubieran realizado a la base de datos en un período determinado.

Módulo de control escolar

Admisiones

Registro de aspirantes
Se refiere al procedimiento por el cual se registra la información básica de los aspirantes
a ingresar a cada institución. En caso de que se requiera de un pago para realizar este
trámite el sistema deberá verificar que exista o se deberá presentar una ficha del banco o
la tesorería que avale el mismo.

P R O N A D
P R O N A D

83


Selección de aspirantes

Mediante este procedimiento se selecciona a los aspirantes que fueron aceptados.
Esto dependerá de la normatividad de cada una de las instituciones. Una vez seleccionados
estos alumnos el sistema habrá de ingresarlos a la base de datos de alumnos.

Inscripciones
Inscripciones a ciclo escolar

Se refiere al procedimiento mediante el cual los alumnos se inscriben para ingresar a
un nuevo ciclo escolar. Este procedimiento deberá ir acompañado con el o los pagos
correspondientes, ya sea a través de la tesorería o de una institución bancaria.
Inscripciones a materias/grupo

Procedimiento mediante el cual el alumno es registrado en la materia/salón/hora escogido
siempre y cuando haya cupo, el plan de estudios lo permita y haya realizado los pagos
correspondientes.

Revalidaciones
Aquí se dan de alta todos los alumnos que ingresan a la institución sin el proceso de
selección, y se integrarán entre otros, los siguientes datos: matrícula, nombre, escuela,
carrera, plan de estudios, semestre, periodo, grupo, turno y estatus (revalidación o
reconocimiento).

Control de grupos
Mediante este procedimiento se asigna una materia/grupo a un salón y a un profesor
determinado.
• El encargado de Control Escolar de la escuela revisa la lista de salones/inmuebles
disponibles.
• A cada salón se le asigna una materia/grupo, señalando el número de horas que se
ocuparán.
• Cada materia/grupo, asignada previamente a un salón y a un horario, es destinada a
un profesor, relacionándola con la lista de profesores activos disponibles, ingresada
a través del módulo de recursos humanos.13
Acopio de calificaciones e impresión de actas
Proceso por el cual se recopilan las calificaciones entre los profesores universitarios al
final de cada ciclo escolar.

13 El sistema verificará que el salón asignado cuente con la capacidad necesaria para los alumnos a inscribir, además de que cuente
con las características necesarias de acuerdo con el tipo de curso a impartir.

P R O N A D
P R O N A D

84


• Se imprime la lista de cada materia impartida por el maestro. La impresión se realiza
en formatos para lectura óptica14 (acta de calificaciones).
• El profesor registra las calificaciones en las actas rellenando los ovalitos
correspondientes. Firma la hoja y la regresa a la oficina de Control Escolar de la
escuela.
• El Departamento de Servicios Escolares recibe las actas de calificaciones firmadas
y llenadas por los profesores.
• Se capturan las actas en el sistema a través del lector óptico, se encuadernan y se
archivan.
• En caso de que el acta no pueda ser leída correctamente, se regresa al profesor
para que la vuelva a llenar y a firmar.
Control de expedientes
Procedimiento mediante el cual se mantienen actualizados los expedientes de todos
los alumnos de cada institución. Este expediente estará conformado con toda la información
existente referente a los alumnos. El sistema registrará además de los datos del alumno,
la relación de documentos que entregó y que integran el expediente físico y una serie de
documentos digitalizados.

Entre los datos de los alumnos que deberá integrar el sistema se encuentran:
• Escolares (escuela, carrera, grupo, generación, matrícula, nombre y CURP)
• Generales, (estado civil, sexo, dirección, teléfono, estado, municipio, código postal,
fecha y lugar de nacimiento, estado y municipio de nacimiento, nacionalidad y
fotografía)

P R O N A D
P R O N A D

85


Kárdex o historia académica, aquí se encuentran las tiras de materias de los alumnos,
clasificados por semestre o ciclo según sea el caso, el sistema deberá mostrar, entre
otros aspectos, para cada una de las materias cursadas, el número de acta en la que
apareció su calificación, la calificación y fecha de cada una de las oportunidades de examen
(ordinario, extraordinario, a título de suficiencia, etcétera).

Documentos digitalizados

Estadísticas
Deberá realizarse un módulo en donde se realice la selección de datos (alumnos, recibos,
auditoría), se determine la relación que deban tener y se ejecute para obtener la estadística
detallada o total. El detalle es un listado con datos, asimismo permitirá almacenar las
estadísticas por si alguna de ellas se quisiera comparar en una gráfica.

P R O N A D
P R O N A D

86


Para poder graficar estadísticas, éstas se debieron haber grabado con anterioridad, se
asignan las estadísticas que se encuentran almacenadas y que se quieran graficar y el
sistema la ejecuta inmediatamente poniendo en el espacio el resultado. Pueden hacerse
comparaciones hasta de 24 columnas, esto es, que se pueden crear 24 estadísticas
diferentes, grabarlas y compararlas en una gráfica. Una vez que se asignan todas las
estadísticas, se presiona el botón graficar y se obtiene el resultado, que puede mandarse
a impresión. La información queda soportada tanto con datos como gráficamente.

Expedición de constancias y certificaciones
Entre otros documentos los sistemas de control escolar deberán expedir los siguientes
documentos:
• Constancias que comprueben que es alumno de la institución, con calificaciones,
de servicio social, etc.
• Certificados (parciales y totales).
• Toma de protesta.
• Cartas de pasante.
• Kárdex (historial académico informal o certificado).
• Títulos.
Registro de planes de estudio
El Departamento de Servicios Escolares recopila la información relativa a la modificación
y la captura. La nueva versión del plan de estudios queda registrada en el sistema,
incluyéndose todos los requisitos o condiciones para cursar cada una de las materias.14

14 El sistema mantendrá el registro histórico de los planes de estudio.

P R O N A D
P R O N A D

87


Expedición de credencial
Es recomendable que los sistemas de control escolar contemplen la credencialización
como un componente de la solución integral. La fotografía correspondiente deberá
digitalizarse e integrarse a la base de datos de alumnos.
El módulo de control escolar guardará una estrecha relación con los módulos financiero
y de recursos humanos. La información de los docentes se obtendrá, partir de ligas con la
base de datos de recursos humanos. Todos los movimientos de control escolar que
requieran de la realización de un pago se tendrán que reflejar conforme a la cuenta, fondo
y función que se maneja en el módulo de financiero.

P R O N A D
P R O N A D

88

Especificaciones técnicas del SIIA Contabilidad matricial

IV. CONTABILIDAD MATRICIAL

Introducción
La contabilidad es un medio para brindar información en relación con las actividades
financieras realizadas por las instituciones públicas o privadas.
En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidad
información financiera más completa y detallada.
Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayuda
a preparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos y
metas financieras.
La calidad de la información financiera ha sido fuertemente criticada por los directivos
que suelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan propuesto
y ejecutado acciones específicas para mejorar la calidad de dicha información.

Objetivos
Generar el Subsistema de Información Financiera Contable al servicio de las necesidades
internas y externas de la administración con orientación pragmática, destinada a facilitar las
funciones administrativas internas de planeación y control, así como a la toma de decisiones.
Los objetivos de la contabilidad de una institución de educación tienen las mismas
características que para una empresa comercial:
a) Proveer información para la planeación y la elaboración del presupuesto, instrumentos
a través de los cuales se espera que el uso de los recursos disponibles sea más
eficiente.
b) Proporcionar información financiera para el control de las operaciones institucionales
a diferentes niveles.
c) Proporcionar información para la salvaguarda y control de los activos.
d) Proporcionar información para la asignación de los recursos.
e) Proporcionar información para la evaluación financiera de las operaciones.
f) Por otro lado, se espera que la información que se prepare cumple con los principios
de contabilidad generalmente aceptados.
Respecto a sus objetivos organizacionales, éstos presentan diferencia con las empresas
comerciales.
a) Las empresas comerciales tienen fines de lucro.

P R O N A D

89


b) Las instituciones de educación pública persiguen fines de servicio, por lo que no tienen
incentivos de lucro, y requieren cada vez de manejar, de una manera más eficiente, el
financiamiento que reciben a través del subsidio, ya sea federal, estatal o municipal.
También se presentan marcadas diferencias en cuanto a la forma de operar de cada una
de ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienes
y servicios y son su principal fuente de recursos, y sus ganancias están determinadas por la
relación que guardan sus ingresos respecto a sus gastos, para una institución de educación
más del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados de
acuerdo con las restricciones que se les ha impuesto para su utilización.
Diseñar un sistema de contabilidad es un arte.
El sistema puede esconder información o puede abrirla tanto como se desee.
Algunos sistemas de contabilidad pueden hacer ambas cosas.
La mayoría de los sistemas de contabilidad para universidades están diseñados de
acuerdo con los principios de contabilidad generalmente aceptados.
Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en la
manera de presentar situaciones especiales. En tales situaciones la metodología contable
difiere de un campus a otro.
El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de la
institución, así como de su historia.
Un sistema de contabilidad no necesariamente refleja todas las operaciones financieras
que pueden influir en el estado financiero de la institución.
Frecuentemente estas transacciones se describen en notas a los estados financieros.
Pueden incluir partidas tales como una adición significativa en la planta.
Partidas que no aparecen en los estados financieros pueden incluir un plan de legados
a alumnos que serán efectivos en un futuro, o una donación de libros raros u objetos de arte.
Estos últimos incrementan el valor de los activos de la institución pero no estarán incluidos
en los estados financieros.
Esto nos lleva a pensar que el sistema de contabilidad de la institución puede no
proporcionar una realidad completa de la situación financiera.
Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a que
aquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, que
están restringidas para su uso, ya que su utilización está asociada a propósitos, funciones y
actividades en particular.
Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamente
para becas.

P R O N A D

90


Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recurso
que no sea para el fin que fue dado.
Dada esta característica en particular, que distingue la contabilidad que debe seguir una
institución educativa, es que surge la llamada contabilidad universitaria o contabilidad matricial.

Estructura del código
Es la forma como se asociarán y relacionarán cada uno de los catálogos que servirán de
base para la codificación de una operación financiera. Para estructurar el código, es
necesario haber diseñado ya los catálogos. El código a utilizar debe tener los siguientes
datos:
I. Datos organizacionales:
Fondo
Función
Programa
Unidad responsable
II. Clasificación genérica de las cuentas:
Cuenta de mayor
Objeto del gasto
En esta parte se consideran las cuentas que forman el activo, el pasivo, el patrimonio y
dentro del patrimonio lo relativo a sus adiciones y/o disminuciones, es decir, ingresos y
gastos.
El número de dígitos que se estimen para cada componente, dependerá de las
necesidades de información de cada institución. Por otro lado, no es necesario seguir el
orden presentado, ya que cada institución lo puede adaptar a su sistema actual. Lo importante
es el nivel de agrupamiento y lo que cada posición signifique. La única condicionante es que
el código inicie con el fondo.

Fondo
Es una entidad contable que tiene un grupo de cuentas autobalanceables, es decir, que
tiene sus propias cuentas de activo, pasivo y patrimonio, además de las cuentas de resultados,
ingresos y gastos.
Se establecen fondos separados para contabilizar las actividades financieras relacionadas
con subsidios que tengan restricciones particulares para su uso, fuentes de recursos
restringidos, o importes designados que han sido establecidos por la junta de gobierno de la
institución. Esas entidades contables se establecen para asegurarse de que los recursos
serán utilizados de acuerdo con las restricciones impuestas, en este caso, por el otorgante

P R O N A D

91


del recurso o bien por la junta de gobierno. Los fondos utilizados en contabilidad matricial
son:
1. De operación
2. De reservas
3. Activos fijos
4. Otros fondos

Función
Agrupación, clasificación y registro de los gastos asociados al cumplimiento de la misión
institucional. De acuerdo con el modelo matricial son:
- Docencia
- Investigación y desarrollo
- Servicio a la comunidad
- Apoyo académico
- Apoyo institucional
- Operación y mantenimiento de la planta física
- Entidades auxiliares

Unidad orgánica
Es un organismo académico, académico-administrativo o administrativo de una institución
educativa, que tiene a su cargo una o varias de las funciones que realiza la institución, o bien
en las que participa.

Cuenta
Identifica al conjunto homogéneo y ordenado de bienes y servicios, el cual, de acuerdo
con el catálogo por objeto del gasto, se requiere para el logro de las metas establecidas.

Ventajas del uso de la contabilidad matricial
• Comparabilidad con instituciones similares.
• Posibilidad de llegar a sistemas de costeo unitario homogéneos.
• Posibilidad de establecer claramente centros de costos y centros de utilidades.

P R O N A D

92


• Compatibilidad entre el presupuesto y el desempeño real, lo cual permite generar
información de avance presupuestal por unidad orgánica.

Los retos
El gran reto para la universidad es, sin lugar a dudas, eficientar sus procesos
administrativos para a su vez eficientar la operación de la universidad. Para lo cual, entre
otras cosas, es necesario contar con información acerca del desempeño financiero de
instituciones similares. Contribuir a la homologación y estandarización del sistema de
información financiera de las universidades, indudablemente proporcionará un mejor uso
de los recursos y una participación mas útil en el esfuerzo de la educación superior en el
país.

P R O N A D

93


P R O N A D
P R O N A D

94

Especificaciones técnicas del SIIA La clave única de registro poblacional (CURP)

V. LA CLAVE ÚNICA DE REGISTRO POBLACIONAL (CURP)1

Para el diseño de la base de datos, se propone que la CURP sea la llave para las entidades
que se refieran a personas. Lo anterior en función de que existe una disposición a unificar
todos los registros de personas a través de esta clave.

¿Qué es la CURP?
La Clave Única de Registro de Población es un instrumento de registro e identificación
que se asigna a todas las personas que viven en el territorio nacional, así como a los
mexicanos que residen en el extranjero. El Registro Nacional de Población (RENAPO) es la
instancia responsable de asignar la CURP y de expedir la constancia respectiva.

¿Cómo se integra la CURP?
La CURP se integra con dieciocho elementos, representados por letras y números, que
se generan a partir de los datos contenidos en el documento probatorio de identidad (acta
de nacimiento, carta de naturalización o documento migratorio), y que se refieren a:
• El primero y segundo apellidos, así como el nombre de pila
• La fecha de nacimiento
• El sexo
• La entidad federativa de nacimiento

Los dos últimos elementos de la CURP evitan la duplicidad de la clave y garantizan su
correcta integración.

¿Qué datos contiene la CURP?
Un ejemplo de esto sería el siguiente: tenemos a una persona con nombre Ricardo Alamán
Pérez, que nació en el Distrito Federal, el 21 de marzo de 1963, su CURP sería AAPR
630321 H DF LRC 09
• Las primeras cuatro letras, AAPR, se refieren a la inicial y primera vocal interna del
primer apellido; inicial del segundo apellido e inicial del nombre de pila.
• Los siguientes seis dígitos 630321, se refieren a la fecha de nacimiento: año, mes y
día.
• La siguiente letra H, se refiere al sexo: (H) para hombre y (M) para mujer.
• Las siguientes letras, DF, se refieren a la entidad federativa de nacimiento.
• Las siguientes letras, LRC, se refieren a las primeras consonantes internas del primer
apellido, segundo apellido y del nombre de pila.
• Y los últimas dos dígitos 09, se refieren a la homoclave, que es el elemento para evitar
registros duplicados.

1 Fuente: Boletín de la Dirección General del Registro Nacional de Población e Identificación Personal

P R O N A D
P R O N A D

95


¿Qué datos se incorporan en la asignación de la CURP?
• La clave única de registro de población
• Nombre completo
• La fecha de inscripción a este sistema
• El número de folio de la constancia.
• Información que identifica los datos del documento probatorio (acta de nacimiento,
carta de naturalización o documento migratorio).

¿Para qué sirve la CURP?
La clave identificará individualmente a las personas en los registros a cargo de las
instituciones públicas.
La CURP se incorporará paulatinamente a todos los documentos oficiales, como se
describe a continuación como ejemplo, a fin de fortalecer las condiciones de seguridad
jurídica de la población; mejorar los vínculos entre ésta y las instancias de gobierno, para
facilitar la prestación de los bienes y servicios, y simplificar la administración pública al eliminar
la diversidad de claves de registro de personas, entre otros.
En materia de Tipo de documento
• Registro civil Acta de nacimiento, matrimonio, adopción, etcétera.
• Salud Cartilla de vacunación, expediente médico, identificación,
etcétera.
• Educación Registro escolar, constancia y certificado de estudios,
identificación, etcétera.
• Prestación de
servicios (trabajo) Solicitud de empleo, registro individual, expediente, nómina,
recibo de pago, identificación, etcétera.
• Seguridad social Cuenta individual del sistema de ahorro para el retiro,
expediente, identificación
• Desarrollo social Registro individual, identificación, etc., así como en el
pasaporte, cartilla del servicio militar, licencia para
conducir, etcétera.

¿Con base en qué se asigna y se expide la CURP ?
En nuestro país la Ley General de Población otorga a la Secretaría de Gobernación la
atribución para registrar y acreditar la identidad de todas las personas residentes en el país
y de los nacionales que residan en el extranjero, a través del Registro Nacional de Población.
La propia ley establece al incorporar a una persona en dicho registro, que se le asignará
una clave única de registro de población, para registrarla e identificarla de manera individual.

P R O N A D
P R O N A D

96

Especificaciones técnicas del SIIA La clave única de registro poblacional (CURP)

El 23 de octubre de 1999, se publicó en el Diario Oficial de la Federación el Acuerdo
Presidencial para la Adopción y Uso por la Administración Pública Federal de la Clave
Única de Registro de Población.
El acuerdo establece que la CURP se asignará a todas las personas que viven en el
territorio nacional, así como a los mexicanos residentes en el extranjero.
Por otra parte, señala que las instituciones públicas que lleven o en lo futuro hayan de
integrar algún registro de personas, deben adoptar el uso de la CURP.
Asimismo, el acuerdo dicta que una vez asignada la CURP por el RENAPO, éste expedirá
una constancia por escrito, que su titular deberá presentar para su incorporación en cualquier
registro de personas.

P R O N A D
P R O N A D

97


P R O N A D

98

Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de software

VI. CONSIDERACIONES GENERALES SOBRE LA INGENIERÍA
DE SOFTWARE

La ingeniería de software es una disciplina que integra proceso, método y herramientas
para el desarrollo del software de computadoras. Sobre ésta, se está llevando a cabo una
fuerte discusión teórica por la evidente debilidad de las bases que le dan fundamento.
Esta discusión se centra en dos aspectos fundamentales, el primero que tiene que ver
con una epistemología basada en el principio de autoridad, ya que la mayoría de los tratados
de ingeniería de software están basados en una combinación de experiencia anecdótica y
autoridad humana, raramente se acompañan de evidencia lógica o experimental. Esto
provoca la carencia de una base sólida que le dé un carácter científico a la ingeniería de
software.
El segundo tiene que ver con un principio práctico aplicado de manera generalizada en la
ingeniería de software y es el famoso precepto de divide y vencerás, es decir, se ha venido
aplicando dogmáticamente este principio, separando las actividades propias del análisis
de las actividades de diseño.
Por otra parte se presupone que una vez establecido el algoritmo, que se obtiene de la
división del proceso de desarrollo de software en diversas etapas, se asume que es factible
desarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmo
que implique un costo injustificado e irrealizable en la práctica.
Es claro entonces que hay una falta de comprensión de la relación que existe entre las
actividades de diseño y las de análisis. Dado lo anterior se puede entonces establecer
que durante la etapa de análisis se constituye el problema, pues no se obtiene un problema,
sólo hechos, y justamente este paso de constitución del problema está necesariamente
referido a su solución, es decir, a la etapa del diseño.
Sobre la ingeniería de software, se está llevando a cabo una fuerte discusión teórica por
la evidente debilidad de las bases que le dan fundamento (ver anexo correspondiente).
En este orden de ideas, la estrategia y metodología que se utilice para la construcción de
un sistema de información no puede ser tajante ni rígida. A continuación describimos de
forma muy general algunos modelos y metodología para la construcción de un sistema. Cada
paradigma exhibe ventajas y desventajas, sin embargo, mantiene una serie de fases
genéricas en común.

Modelos de ingeniería de software

El modelo lineal secuencial
Llamado algunas veces “ciclo de vida básico” o “modelo en cascada”, el modelo lineal
secuencial es un enfoque sistemático, secuencial del desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y

P R O N A D

99


mantenimiento. Modelo según el ciclo de ingeniería convencional, el modelo lineal secuencial
acompaña a las actividades siguientes:
Ingeniería y modelado de sistemas/información. Como software siempre forma parte de
un sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todos
los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esta
visión del sistema es esencial cuando el software se debe interconectar con otros elementos
como hardware, personas y bases de datos. La ingeniería y el análisis de sistemas acompaña
a los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis y
de diseño. La ingeniería de información acompaña a los requisitos que se recogen en el
nivel estratégico de empresa y en el nivel de área de negocio.
Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica
y se centra especialmente en el software. Para comprender la naturaleza de lo (s) programa(s)
(s) a construirse, el ingeniero (“analista”) del software debe comprender el dominio de
información del software (descrito en el capítulo 11), así como la función requerida,
comportamiento e interconexión. El usuario documenta y repasa los requisitos del sistema y
de software.
Diseño. El diseño del software es realmente un proceso de muchos pasos que se centra
en cuatro atributos distintos de un programa: estructura de datos, representaciones de interfaz
y detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en una
representación del software que se pueda evaluar por calidad antes de que comience la
generación del código. Al igual que los requisitos, el diseño se documenta y se hace parte
de la configuración del software.
Generación de código. El diseño se debe traducir en forma legible por la máquina. El
paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una
forma detallada, la generación de código se realiza mecánicamente.
Pruebas. Una vez que se ha generado un código, comienzan las pruebas del programa.
El proceso de pruebas se centra en los procesos lógicos internos del software, asegurando
que todas las sentencias se han comprobado, en los procesos externos funcionales, es
decir, que la realización de las pruebas para la detección de errores y sentirse seguro de la
entrada definida produzca resultados reales de acuerdo con los resultados requeridos.
Mantenimiento. El software individualmente sufrirá cambios después de ser entregado al
cliente (una excepción posible es el software empotrado). Se producirán cambios porque se
han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios
de su entorno externo ( p. ej.: se requiere un cambio debido a un sistema operativo o dispositivo
periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El
mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existente
y no a uno nuevo.
El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado
en la ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su

P R O N A D
P R O N A D

100


eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial
se incluyen:
1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
Aunque el modelo lineal puede acoplar interacción, lo hace indirectamente. Como
resultado, los cambios pueden causar confusión cuando el equipo del proyecto
comienza.
2. A menudo es difícil que el usuario exponga explícitamente todos los requisitos. El modelo
lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre
natural al comienzo de muchos proyectos.
3. El usuario debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará
disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser
desastroso si no se detecta hasta que se revisa el programa.
4. Los responsables del desarrollo del software siempre se retrasan innecesariamente.
En un interesante análisis de proyectos reales, Bradac dijo que la naturaleza lineal de
ciclo de vida clásico lleva a “estados de bloqueo” en el que algunos miembros del
equipo del proyecto deben esperar a otros miembros del mismo para completar tareas
dependientes. En efecto, el tiempo que se pasa esperando puede sobrepasar el tiempo
que se emplea en el trabajo productivo. Los estados de bloqueo tienden a ser más
importantes al principio y al final de un proceso lineal secuencial.
Cada uno de estos errores es real. Sin embargo, el paradigma del ciclo de vida clásico
tiene un lugar definido e importante en el trabajo de la ingeniería de software. Proporciona
una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas
y mantenimiento. El ciclo de vida clásico sigue siendo el modelo de proceso más
extensamente utilizado por la ingeniería del software. Pese a tener debilidades, es
significativamente mejor que un enfoque hecho al azar el desarrollo del software.

El modelo de construcción de prototipo
Un cliente a menudo define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el
responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo,
de la capacidad de adaptación de sistema operativo, o de la forma en que debería tomarse
la interacción hombre-máquina. En éstas y en muchas otras situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El
desarrollador y el usuario encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más
definición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para el cliente. (p. ej.:
enfoques de entrada y formatos de salida). El diseño rápido lleva la construcción de un

P R O N A D

101


prototipo. El prototipo lo evalúa el usuario y lo utiliza para refinar los requisitos de software a
desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del usuario,
a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos
del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de
los fragmentos del programa ya existentes o aplica herramientas (p.ej.: generadores de
informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.
En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar.
Puede ser demasiado lento, grande o torpe en su uso, o las tres a la vez. No hay alternativa
sino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estos
problemas. Cuando se utiliza un concepto nuevo de sistema o de una tecnología nueva, se
tiene que construir un sistema que no sirva y se tenga que tirar, incluso la mejor planificación
no es omnisciente como para que esté perfecta la primera vez. Por tanto, la pregunta sobre
la gestión no es si construir un sistema piloto y tirarlo. La única pregunta es si planificar de
antemano construir un desechable, o prometer entregárselo a los usuarios.
La construcción de prototipos también puede ser problemática por las razones siguientes:
1. El usuario ve lo que parece ser una versión de trabajo del software, sin tener
conocimiento de que el prototipo también está junto con “el chicle y el cable de embalar”,
sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad
del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa
que el producto se debe construir otra vez para que se puedan mantener los niveles
altos de calidad, el usuario no lo entiende y pide que se apliquen “unos pequeños ajustes”
para que se pueda hacer del prototipo un producto final. De forma demasiado frecuente
la gestión de desarrollo del software es muy lenta.
2. El desarrollador a menudo hace compromisos de implementación para hacer que el
prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de
programación inadecuado simplemente porque está disponible y porque es conocido;
un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad.
Después de algún tiempo, el desarrollo debe familiarizarse con estas selecciones, y
olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora
es una parte integral del sistema.
Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma
efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo;
el usuario y el desarrollador deben ponerse de acuerdo en que el prototipo se construya para
servir como un mecanismo de definición de requisitos. Entonces se descarta (al menos en
partes) y se realiza la ingeniería del software con una visión hacia la calidad y facilidad de
mantenimiento.

P R O N A D
P R O N A D

102


El modelo DRA
El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development, RDA) es
un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del
modelo lineal secuencial en el que se logra el desarrollo rápido, utilizando un enfoque de
construcción basado en componentes. Si se comprenden bien los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema
completamente funcional” dentro de los periodos cortos de tiempo (p. ej.: de 60 a 90 días).
Cuando se utilizan principalmente para aplicaciones de sistemas de información, el enfoque
DRA comprende las siguientes fases.
Modelado de gestión. El flujo de información entre las funciones de gestión se modela de
forma que responda a las siguientes preguntas: ¿Qué información conduce al proceso de
gestión? ¿Qué información se genera? ¿Quién la genera? ¿Adónde va la información? ¿Quién
la procesa?
Modelado de datos. El flujo de información definido como la parte de la fase de modelado
de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa.
Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones
entre estos objetos.
Modelado de proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una
función de gestión . Las descripciones del proceso se crean para añadir, modificar, suprimir.
o recuperar un objeto de datos.
Generación de aplicaciones. EL DRA asume la utilización de técnicas de cuarta
generación. En la creación de software con lenguajes de programación de tercera generación,
el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes
(cuando es posible ) o a crear componentes reutilizables (cuando sea necesario). En todos
los casos se utilizan herramientas automáticas para facilitar la construcción del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado
muchos de los componentes de los programas. Esto reduce tiempo de pruebas, sin embargo,
se deben probar todos los componentes nuevos y ejercitar todas las interfaces a fondo.
El modelo de proceso de DRA se ilustra en la figura 2.6. Obviamente, las limitaciones de
tiempo impuestas en un proyecto DRA demandan “ámbito en escalas”. Si una aplicación de
gestión puede modularse de forma que permita completarse cada una de las funciones
principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un
candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo del
DRA diferente y ser integradas en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el número correcto de equipos DRA.

P R O N A D

103


• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades
necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay
compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.
• No todas las aplicaciones son apropiadas para el DRA. Si un sistema no se puede
modularizar adecuadamente, la construcción de los componentes necesarios para
DRA será problemática. Si está en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de sistemas, puede suceder que
el enfoque DRA no funcione. DRA no es adecuado cuando los riesgos técnicos son
altos. Esto ocurre cuando una nueva aplicación hace uso de las tecnologías nuevas, o
cuando el nuevo software requiere un alto grado de interoperatividad con programas
de computadoras ya existentes.

Técnicas de cuarta generación
El término “técnicas de cuarta generación” (T4G) abarca un amplio espectro de
herramientas de software y la especificación de algunas características del software de alto
nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la
especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en
el que se especifique el software, más rápido se podrá construir el programa. El paradigma
T4G para la ingeniería del software se orienta hacia la posibilidad de especificar éste usando
formas de lenguaje especializado o notaciones gráficas que describan el problema que se
debe resolver en términos entendibles para el cliente. Actualmente, un entorno para el
desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las
siguientes herramientas: lenguajes no procedimentales de consulta a base de datos,
generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo.
Inicialmente, muchas de estas herramientas están disponibles, pero sólo para ámbitos de
aplicación muy específicos, aunque actualmente los entornos T4G se han extendido a todas
la categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos.
Idealmente, el cliente describe los requisitos que son continuación, traducidos directamente
a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente
puede no estar seguro de lo que necesita; ser ambiguo en la especificación de hechos que
le son conocidos, y no ser capaz o no estar dispuesto a especificar la información en la
forma en que se puede utilizar una herramienta T4. Por esta razón, el diálogo usuario-
desarrollador, descrito por los otros paradigmas, sigue siendo una parte esencial del enfoque
T4G.
Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de
requisitos al paso de implementación, usando un lenguaje de cuarta generación no
procedimental ( L4G). Sin embargo, es necesario un mayor esfuerzo para desarrollar una
estrategia de diseño (para grandes proyectos); causará las mismas dificultades (poca calidad,
mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla
software mediante los enfoques convencionales.

P R O N A D
P R O N A D

104


La implementación mediante L4G permite, al que desarrolla el software, centrarse en la
representación de los resultados deseados, lo que se traduce automáticamente en un código
fuente que produce dichos resultados.
Obviamente, debe existir una estructura de datos con información relevante y a la que el
L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo desarrolla debe
apoyarse en la documentación apropiada y ejecutar el resto de actividades de “integración
“requeridas en los otros paradigmas de ingeniería del software. Además el software
desarrollado con T4G debe ser construido de modo que facilite la realización del
mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e
inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollo
del software y una mejora significativa en la productividad de la gente que construye el mismo.
Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar
que los lenguajes de programación, que el código fuente producido por tales herramientas
es “ineficiente” y que el mantenimiento de grandes sistemas de software desarrollados
mediante T4G, es cuestionable.
1. El uso de T4G ha crecido considerablemente en la última década y ahora es un enfoque
viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas
de ingeniería de software asistida por computadora (Computer-Aided Software
Engineering, CASE) los generadores de código T4G ofrecen una solución fiable a
muchos problemas de software.
2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo
requerido para producir software se reduce mucho para aplicaciones pequeñas y
tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas,
también se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software existe el
mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del
software), perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación
de la codificación.
Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte
importante del desarrollo del software. Cuando se combinan con enfoques de ensamblaje
de componentes, el paradigma T4G se puede convertir en el enfoque dominante hacia el
desarrollo del software.

Breves comentarios a cerca del diseño de sistemas
La evolución del diseño del software es un proceso imparable que se ha expandido durante
las tres primeras décadas. Antiguamente el diseño se centraba en los criterios de desarrollo
de programas modulares y métodos para refinar la arquitectura software de una manera
descendente en la jerarquía. Los aspectos procedimentales de la definición del diseño del
P R O N A D

105


modelo evolucionaron hacia una filosofía denominada programación estructurada. Algunos
trabajos posteriores proponían métodos para la transformación de flujo de datos o de la
estructura de datos en una definición del diseño. Enfoques recientes del diseño proponen,
por ejemplo, un enfoque orientado a objeto para obtención del diseño.
Muchos métodos de diseño que han surgido de los trabajos mencionados anteriormente
se aplican en la industria. Al igual que los métodos de análisis, todos los métodos de diseño
de software presentan unas heurísticas y notaciones únicas. Así como una visión algo particular
de cómo lograr la calidad del diseño. Sin embargo, todos estos métodos tienen unas
características comunes: (1) un mecanismo para la transformación de un modelo de análisis
en una representación del diseño, (2) una notación para representar componentes funcionales
y sus interfaces, (3) heurísticas para el refinamiento y la participación y (4) consejos para
mejorar la calidad .
Independientemente del método del diseño que se emplee, un ingeniero de software
debería aplicar un conjunto de principios fundamentales y conceptos básicos al diseño de
datos, arquitectónico, de interfaz y procedimental. Estos principios y conceptos se consideran
en las siguientes secciones.
El diseño del software es un proceso y un modelo a la vez. El proceso de diseño es un
conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del
software a construir. Hay que aclarar, sin embargo, que el proceso del diseño no es un
simple “libro de cocina”. La capacidad creativa, la experiencia acumulada, el sentido del
“buen” software y un empeño global en la calidad, son factores críticos del éxito del diseño.
El modelo del diseño es el equivalente a los planos de una casa para un arquitecto. Empieza
representando la totalidad de lo que se va construir (p.ej.: una representación tridimensional
de la casa) y lentamente lo va refinando para proporcionar una directriz y construir cada
detalle (p.ej.: el plano de las cañerías ). Similarmente, el modelo de diseño creado para el
software proporciona varias visiones diferentes del programa de computadora.
Los principios básicos del diseño permiten al ingeniero del software navegar en el proceso
de diseño. Davis sugiere un conjunto de principios para el diseño del software que han
sido adaptados y ampliados en la siguiente lista:
• El proceso de diseño no debería ponerse “orejeras”. Un buen diseñador debería
considerar enfoques alternativos, juzgando cada uno con base en los requisitos del
problema, los recursos disponibles para hacer el trabajo y los conceptos de diseño.
• Se deberían seguir los pasos del diseño hasta el modelo de análisis. Como un solo
modelo del elemento de diseño se refiere a menudo a múltiples requisitos, es necesario
tener los medios para hacer un seguimiento de cómo ha satisfecho los requisitos dicho
modelo.
• El diseño no debe inventar nada que ya esté inventado. Los sistemas se construyen
usando un conjunto de estructuras de diseño, de las cuales muchas se han utilizado
anteriormente. Estas estructuras, a menudo denominadas componentes de diseño
reutilizables, deben considerarse siempre antes que reinventar nada. ¡El tiempo es

P R O N A D
P R O N A D

106


corto y los recursos limitados! El tiempo invertido en diseño debe concentrarse en
presentar ideas verdaderamente nuevas y en integrar aquellas estructuras que ya existen
• El diseño debería “minimizar la distancia intelectual” entre la estructura del diseño del
software (cuando sea posible) e imitar la estructura del dominio del problema.
• El diseño debería presentar uniformidad e integración. Un diseño es uniforme si parece
que sólo una persona desarrolló todo el conjunto. Se deberían definir normas de estilo
y de formato para un equipo de diseño antes de comenzar el trabajo de diseño.
• Un diseño está integrado si se tiene el cuidado en definir las interfaces entre los
componentes del diseño.
• El diseño debería estructurase para admitir cambios. Muchos de los conceptos de
diseño permite a éste conseguir este principio.
• El diseño debería estructurarse para degradarse poco a poco, incluso cuando se
enfrentan a datos, sucesos o condiciones operativas aberrantes. Un programa bien
diseñado no debería “explotar” nunca. Debería diseñarse para aceptar circunstancias
inusuales, y si debe terminar el procesamiento, hacerlo de una manera suave.
• El diseño no es escribir códigos y escribir códigos no es diseñar. Incluso cuando se
crean diseños procedimentales detallados para los componentes de un programa, el
nivel de abstracción del modelo de diseño es mayor que el del código fuente. Las
únicas decisiones del diseño hechas a nivel de código se refieren a los pequeños
detalles de implementación que permiten codificar el diseño procedimental.
• Se debería valorar la calidad del diseño mientras se crea, no después de terminarlo.
Existe una variedad de conceptos de diseño y medidas de diseño disponibles para
ayudar al diseñador en la valoración de la calidad .
• Se debería revisar el diseño para minimizar los errores conceptuales (semánticos). A
veces hay tendencia a concentrarse en minucias cundo se revisa el diseño, no dejando
los árboles ver el bosque. El diseñador debe asegurarse de que se revisen los elementos
conceptuales principales del diseño (omisiones, ambigüedades, inconsistencias) antes
de preocuparse por la sintaxis del modelo de diseño.
Cuando se aplican apropiadamente los principios del diseño señalados anteriormente, el
ingeniero de software crea un diseño que muestre factores de calidad externos e internos.
Los factores de calidad externos son aquellas propiedades del software que pueden observar
los usuarios (p. ej.: velocidad, fiabilidad, corrección, utilidad). Los factores de calidad internos
son importantes para los ingenieros del software, permiten un diseño de alta calidad desde
la perspectiva técnica. Para conseguir los factores de calidad interna, el diseñador debe
entender los conceptos básicos de diseño.

P R O N A D

107


P R O N A D
P R O N A D

108

Especificaciones técnicas del SIIA Conceptos básicos sobre las bases de datos relacionales

VII. CONCEPTOS BÁSICOS SOBRE LAS BASES DE DATOS
RELACIONALES

El modelo relacional es un modelo muy elegante y claro, ha constituido los cimientos de la
industria de las bases de datos durante casi 20 años. El relativamente pequeño número de
conceptos existentes en la teoría relacional ha ayudado a convertir esta técnica en un estándar
industrial. Los diseñadores relacionales han sido capaces de aislar la complejidad del
desarrollo físico de las bases de datos respecto al diseño lógico del sistema, proporcionando
así una interfaz sencilla para los diseñadores de aplicación.
Durante las dos últimas décadas hemos madurado como industria. Muchos de nosotros
hemos sentido la necesidad de contar con un entorno de modelización más rico que se
adaptara mejor a los recientes avances que tienden hacia una modelización genérica.
Además, reconocemos que existen conceptos de la teoría orientada a objeto que podrían
introducirse en el mundo de las bases de datos y que podrían mejorar la eficiencia de las
mismas.
Las bases de datos relacionales cuentan con un vocabulario relativamente limitado. Hemos
implementado estructuras utilizando archivos planos diseñados juiciosamente y
posteriormente, hemos introducido algunos tipos de índices distintos en varios campos de
esos archivos. En lo referente al acceso, los vínculos entre tablas sólo se especificaban de
forma lógica, por lo que los punteros de referencia se llevaban a cabo mediante claves
externas. No necesitábamos contar con vínculos explícitos entre las tablas. Las limitaciones
de integridad referencial eran, simplemente pequeños trozos de código que evitaban la
introducción en el modelo de datos de algunos tipos específicos de datos no válidos.
Podíamos agregar desencadenadores (triggers) a nuestras tablas para realizar explícitamente
alguna actividad cuando se insertaba, actualizaba o borraba algún registro, y se almacenaban
unidades de programa en la base de datos. Finalmente, podíamos agrupar tablas para mejorar
el rendimiento. Todas estas estrategias limitaban nuestra forma de pensar. En una base de
datos relacional, cada tabla es virtualmente una estructura independiente.
En la creación de modelos de relaciones lógicas de entidades (ER) teníamos entidades
que eran subconjuntos de otras entidades. Por ejemplo, los empleados asalariados eran
un subconjunto de todos los empleados. De la misma forma, teníamos entidades que
dependían de otras entidades, tales como detalles OC, que dependían de órdenes de
compra. Sin embargo, nuestra capacidad para representar estas estructuras utilizando
bases de datos es limitada . Paradójicamente las bases de datos orientadas a objetos
retienen algunos de los conceptos de la primera teoría de bases de datos.
Al igual que lo que ocurría en los días de CODASYL, cuando introducimos conceptos de
objetivo en el mundo de las bases de datos relacionales, nos volvemos a encontrar con
“viejos amigos”, tales como listas y punteros.
No nos podemos olvidar de por qué en aquella ocasión abandonamos ya las listas
vinculadas y los punteros. Tenemos que recordar cómo era el mundo de las bases de datos
antes de la aparición de la metodología relacional a principios de la década de los años
P R O N A D

109


ochenta. Todavía siguen existiendo (al menos hasta que el problema del año 2000 acabe
con ellas) bases de alto rendimiento que utilizan archivos CODASYL, ISAM y VSAM escritos
en COBOL. Las modificaciones a las bases de datos CODASYL suelen exigir meses de
esfuerzo. Hace ya algunos años nos encontramos con un antiguo proyecto COBOL en el que
surgió un nuevo requisito, cambiar la anchura de un campo de 10 a 12 caracteres. Esta
pequeña modificación supuso cientos de horas de trabajo de programación. En la actualidad,
con un entorno de base de datos relacional, este tipo de modificaciones sólo exigiría algunos
días de trabajo. Si la aplicación se generó con una herramienta CASE integrada, la realización
de este cambio podría llevar uno o dos días, incluso en un sistema de gran tamaño.
En los días de las bases de datos prerrelacionales, cumplir con los requisitos de elaboración
de informes era una tarea muy difícil. Si un determinado informe no había sido tomado en
cuenta durante las especificaciones originales del diseño, podría exigir semanas de trabajo
escribir un nuevo informe (suponiendo que fuera posible escribirlo). Las modificaciones a
las estructuras de datos subyacentes eran muy engorrosas. Los cambios más pequeños
parecían exigir un rediseño importante del sistema. No estamos afirmando que todos estos
problemas desaparecieran con la llegada de los diagramas de la relación de entidades
(ED) y de las bases de datos relacionales, pero la situación mejoró.
Las primeras bases de datos relacionales se parecían mucho a sus predecesoras de
archivos planos. La normalización se consideraba como una curiosidad académica. Con
tiempo, al menos con la tercera forma normal, se pudo constatar que la normalización no era
una idea tan mala. En la era de las desnormalizaciones, ocurrida en la década de los años
ochenta, tuvimos los mismos problemas con las estructuras relacionales que con los archivos
planos. Modificar una estructura de datos seguía siendo una labor difícil y cara, lo mismo
ocurría si se deseaba modificar una aplicación. En la década de los noventa, la mayoría de
los diseñadores de datos habían podido comprobar que las fuertes desnormalizaciones
efectuadas en los ochenta estaban pasando factura, causando problemas de forma masiva
en aquellos sistemas que necesitaban modificarse. La normalización fue, finalmente, en estilo.
A mediados de los noventa, algunas de las primeras ideas de la metodología orientada a
objeto comenzaron a introducirse en las bases de datos relacionales. Este tema implicó la
generalización de modelos creando estructuras abstractas, a la vez que todavía seguíamos
trabajando en el entorno de bases de datos relacionales. En los últimos años, parte de la
comunidad de diseñadores de base de datos relacionales han abrazado ya la metodología
orientada a objeto.
En la actualidad, es frecuente ver cierto nivel de modelización genérica en la mayoría de
los sistemas. Por ejemplo, existe un estándar industrial para representar las unidades
organizativas como una simple estructura recursiva, en lugar de utilizar tablas
independientes para regiones, divisiones y departamentos (o sea cual sea la estructura para
una determinada empresa).
Incluso, cada vez son más frecuentes los modelos más abstractos. En una conferencia
celebrada recientemente, alguien que diseñaba una base de datos de cuestionarios me
preguntó cómo podría manejar una tabla como varios cientos de columnas. Cada cuestionario
consta de cientos de preguntas. Varias personas que se encontraban entre los asistentes
P R O N A D
P R O N A D

110


respondieron que se debía modelizar el cuestionario introduciendo las preguntas en una
tabla separada y almacenando la estructura del cuestionario como datos en la base de datos.
Estaba teniendo lugar una revolución silenciosa. La metodología orientada a objeto estaba
encontrando su sitio entre los modelos de datos.
Recientemente, se han dado dos pasos más en la evolución hacia la orientación a objeto.
En primer lugar, las propias bases de datos han comenzado a concluir nuevas funciones
orientadas a objeto. En segundo lugar, disponemos de un nuevo lenguaje de modelización
más rico; nos referimos a UML frente al antiguo ERD. Como mencionamos anteriormente,
estos nuevos conceptos incluyen realmente algunos de los viejos conceptos del pensamiento
prerrelacional con listas vinculadas y punteros. Esta nueva integración de lo nuevo y de lo
viejo representa una gran oportunidad, pero también se debe tomar con precaución. En la
actualidad, podemos construir estructuras relacionales que funcionan de manera más eficaz.
Pero si no somos cuidadosos, podremos perder parte de la flexibilidad de las estructuras
que evolucionaron a partir del paradigma de las bases de datos relacionales.

Terminología y conceptos básicos
En el diseño de base de datos relacionales, analizaremos el modelo lógico de datos
frente al físico. El modelo lógico de datos representa el diseño de la base de datos, mientras
que el modelo físico representa la realización del diseño. Se utilizan palabras distintas para
comparar el diseño lógico y el diseño físico. Todo esto puede ser algo confuso. El siguiente
esquema ayuda a clarificar esta terminología para poder seguir con nuestro debate:
Lógico relacional Lógico objeto Físico
Entidad Clase Tabla
Atributo Atributo Columna, campo
Instancia Objeto Fila

Para asegurar la consistencia es importante clarificar las definiciones que son importantes
para este análisis:
Entidad. Se trata de algo que tiene interés para la empresa, tal como un empleado, un
departamento o una venta. Desde una perspectiva teórica, una entidad puede ser,
simplemente, un conjunto de atributos. Sin embargo no se trata de una forma útil de pensar
en entidades. Es mejor pensar que una entidad es algo que tiene correspondencia en el
mundo real. Cada instancia de la entidad departamento, por ejemplo, se corresponde con
un departamento específico en la organización (o en el caso de la entidad persona, a una
persona específica). Existe una correspondencia directa entre entidades e instancias de la
teoría relacional y clases y objetos, respectivamente, en teoría de objetos. Por ejemplo, para
la entidad departamento podemos hablar de la clase departamento, que incluirá el objeto
contabilidad.
Atributo. Se trata de una pieza de información que podemos extraer de un objeto o instancia
de una entidad, tales como los nombres de los departamentos o las edades de los empleados.
Observe que la palabra “atributo” se utiliza tanto en teoría relacional como en teoría de objetos.

P R O N A D

111


Clave primaria. Se trata de un concepto de teoría relacional que describe los atributos de
una entidad que identifican de manera única a cualquier instancia específica de dicha entidad.
Por ejemplo, el ID de Empleado (identificador de empleado) es una clave primaria apropiada
para la entidad empleado, porque no puede haber dos empleados que tengan el mismo ID.
Las claves primarias deben ser únicas. Ningún componente debe ser nulo y, una vez que han
sido asignadas, no podrán modificarse. Este requisito final es más práctico que teórico,
porque las claves primarias se utilizan en lugar de los punteros en las bases de datos
relacionales. Modificar la clave primaria significaría cambiarla en cualquier lugar a miles o,
incluso, a millones de registros.
Clave candidata. Con frecuencia, en una entidad, es posible que más de un atributo pueda
servir como clave primaria. Una de las claves candidatas se designará como clave primaria.
Otros atributos que pueden actuar como claves primarias se designarán como claves
candidatas.

Creación de un diagrama entidad-relación
El diagrama de entidad-relación permite que un ingeniero de software especifique los
objetos de datos que entran y salen de sistema, y las relaciones entre los objetos. Al igual
que la mayoría de elementos del modelo de análisis y las relaciones entre objetos, el DER
construye de una forma interactiva. Se toma el enfoque siguiente:
1. Durante la recopilación de requisitos, se pide que los clientes listen las “cosas” que
afronta el proceso de aplicación y/o del negocio. Estas “cosas” evolucionan en una
lista de objetos de datos de entrada y de salida así como entidades externas que
producen o consumen información.
2. Tomando un objeto cada vez, el analista y el cliente definen si existe una conexión (sin
especificarlo en ese momento) o no entre ese objeto de datos y otros objetos.
3. Siempre que existe una conexión, el análisis y el cliente crean una o varias parejas de
objeto-relación.
4. Para cada pareja objeto-relación se explora la claridad y la modalidad.
5. Interactivamente se continúan los pasos del 2 al 4 hasta que se hayan definido todas
las parejas objeto-relación. Es normal descubrir omisiones a medida que el proceso
continúa. Objetos y relaciones nuevos se añadirán invariablemente a medida que crezca
el número de interacciones.
6. Se definen los atributos de cada entidad.
7. Se formaliza y revisa el diagrama objeto-relación.
8. Se repiten los pasos del 1 al 7 hasta que se termine el modelado de datos.

P R O N A D
P R O N A D

112


Reglas de normalización
Cuando decimos que una base de datos ha sido normalizada, no nos estamos refiriendo
a normal en el sentido de regular u ordinario. En este contexto, normalizado (adjetivo derivado
de la notación matemática de normal) significa ortogonal. Volviendo a nuestras olvidadas
clases de álgebra lineal, recuerde que el término normalizado se utilizaba conjuntamente
con los vectores ortogonales en un espacio vectorial y en análisis del tipo: ¿puede una
combinación lineal de un conjunto de vectores constituir un denominado espacio vectorial?
La noción de normalización en una base de datos persigue una idea similar, ya que, en
este caso, se está intentando desarrollar un conjunto de tablas en la base de datos que no se
superpongan de manera inapropiada y que nos permitan almacenar toda la información que
pueda contener la base de datos en la misma forma en que tres vectores unitarios ortogonales
pueden generar un espacio de tres dimensiones.
No vamos a entrar en discusiones formales sobre normalización. Podrá encontrar este
tipo de análisis en libros tales como A First Course in Database Systems1, de Jeffrey D.
Ullman, en numerosos trabajos desarrollados por Chris J. Date, o en cualquier otro de los
numerosos libros académicos que analizan las bases de datos. Iremos presentando
definiciones de normalización con un sentido más práctico y más apropiado para los objetivos
perseguidos por este libro.
¿Por qué queremos construir bases de datos normalizadas? La normalización nació en
conjunción con el lenguaje de programación denominado SEQUEL. El teorema fundamental
de la teoría relacional es que si su base de datos se encuentra normalizada, podrá extraer
cualquier subconjunto de datos de ella utilizando operadores básicos de SEQUEL. Por este
motivo la normalización es tan importante. Puede ser muy complicado extraer información
de una base de datos no normalizada sin tener que desarrollar un código complejo, estas
reglas de normalización fueron importantes en los modelos relacionales y siguen siendo
importantes en los modelos objeto-relacionales.
Todavía seguimos utilizando SQL+ o una extensión orientada a objeto de SQL (una versión
de SEQUEL) para manipular la información contenida en las bases de datos. Si no trabajamos
con bases de datos normalizadas, SQL puede no funcionar. Aunque una persona haya
trabajado durante toda su carrera profesional en entornos de DBMS, puede no conocer los
entornos existentes antes de la aparición de las bases de datos racionales. El cambio de
orientación del papel en la impresión de un informe llevaba, al menos, dos semanas. Con
frecuencia, los intentos de realizar pequeñas modificaciones en una estructura de datos
llevaban meses e incluso años de tiempo de desarrollo. Si la intención era incluir nuevas
funciones, nos encontrábamos con miradas vacías, movimientos de cabeza y respuestas
del tipo “dada la actual arquitectura del sistema, las modificaciones que usted propone no se
pueden llevar a cabo”. Si abandonamos las reglas de normalización para la creación de
bases de datos orientadas a objeto, corremos el riesgo de dar un paso de gigante hacia
atrás en términos de flexibilidad de los sistemas que desarrollaremos.

P R O N A D

113


Primera forma normal
La primera forma normal se define como aquella que no tiene ningún atributo multivalor.
Ilustraremos este concepto mostrándole una estructura de tabla que va en contra de la primera
forma normal. Por ejemplo, queremos asociar a una entidad denominada orden de compra
(OC) un atributo denominado “elementos pedidos”. Como es posible solicitar varios artículos,
contará con la capacidad de almacenar varios elementos en la entidad. La tabla mostrada
en el ejemplo 2 ilustra este tipo de violación.
El problema surge si existe un tercer artículo. Tan sólo puede solicitar dos artículos
utilizando esta estructura. Naturalmente, siempre podemos añadir más columnas para
permitir la petición de más artículos. Podemos añadir suficientes columnas como para no
tener que preocuparnos nunca sobre la posibilidad de permitir más artículos de lo permitido.
Sin embargo, nos enfrentaríamos con un problema diferente. La única forma de conocer
el número de veces que se ha solicitado un determinado artículo sería mirar en todas las
columnas de artículos. Incluso, calcular el valor total de alguna factura exigirá mirar en varios
lugares.
En el modelo relacional existe una forma de satisfacer la primera forma normal. La
estructura necesaria para resolver las violaciones contra la primera forma normal.
Es posible construir buenas bases de datos sin tener que adherirse a la primera forma
normal. Los teóricos relacionales resolvieron hace mucho tiempo qué extensiones a la teoría
relacional son necesarias para poder trabajar con bases de datos que no cumplan la primera
forma normal. La idea es permitir que los arrays sean un tipo de datos. De esta forma se
pueden obtener mejores rendimientos que en el caso de utilizar una base de datos relacional
estándar, pero hay que elaborar consultas más complejas para extraer los datos.
Durante años la comunidad de bases de datos ha analizado el tema de si la primera
forma normal es incluso deseable. Simplemente, no puede coger una base de datos relacional
estándar y violar la primera forma normal sin un costo negativo. Sigue habiendo una pregunta
trascendental: ¿existe alguna ocasión en la que desee estructurar una tabla en la que una de
sus columnas sea realmente un array o un conjunto de valores o registros? La respuesta es
un “sí” incondicional.
Existen ocasiones en las que se necesita de manera inherente e inexcusable la utilización
de estructuras que no cumplan la primera forma normal. Hace años Cobb desarrolló las
extensiones de SQL necesarias para que los arrays pudieran ser un tipo de datos.
Realmente, el lenguaje SQL necesario para manejar estructuras que no cumplan la primera
forma normal es más complejo, pero es una decisión de cada diseñador determinar si desea
desarrollar estructuras de este tipo.
Esta tecnología es actualmente demasiado nueva como para que podamos proporcionar
directrices explícitas sobre cuáles son las situaciones más adecuadas para poder utilizarla.
Todavía estamos esperando la aparición de herramientas que faciliten en empleo de
estructuras que no cumplan la primera forma normal y que los diseñadores acaparen más
experiencia en el manejo de este tipo de estructuras.

P R O N A D

114

Espe tecnicas siia_2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Espe tecnicas siia_2

Ähnlich wie Espe tecnicas siia_2 (20)

Mehr von univ of pamplona

Mehr von univ of pamplona (14)

Espe tecnicas siia_2