Espe tecnicas siia_2

3,525 views
3,233 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,525
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Espe tecnicas siia_2

  1. 1. Programa para la Normalización de la Información AdministrativaMódulo de recursos humanos Las funciones fueron agrupadas en cuatro subsistemas; el primero se refiere a todasaquellas funciones exclusivas para el personal docente, en el siguiente se agrupan aquellasfunciones exclusivas para el personal administrativo y/o trabajadores, el tercer subsistemaincluye todos los procedimientos y funciones para la elaboración de la nómina y el últimoabarca todas aquellas prestaciones de carácter general para quienes laboran dentro de lainstitución. Cabe aclarar que este agrupamiento no es el único válido y que dependerá delas características, funcionamiento y estructura orgánica de cada universidad.Registro y control del personal administrativoMovimientos de personal A través de este proceso el usuario podrá dar altas, bajas y modificar la información delos diferentes campos que integran la base de datos de personal administrativo conformea los procedimientos que establezca cada institución. A continuación se describen algunos de los movimientos que permitirá registrar elsubsistema: • Altas de personal administrativo (eventuales) Consiste en otorgar una plaza eventual para efecto de una obra determinada duranteun periodo de tiempo determinado. Una vez autorizado este movimiento el trabajadordeberá ser dado de alta en la base de datos de la institución, así también el contrato detrabajo 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 almomento de su contratación queda establecido el periodo del contrato por lo que al arribara 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 debase. Aun cuando este tipo de movimiento no resulta muy común, en ocasiones se llega apresentar. Estos movimientos habrán de generar pagos extraordinarios por concepto deliquidación. P R O N A D P R O N A D74
  2. 2. 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 dentrodel 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ónpara jubilarse, mas no la cantidad de años señalada por el ISSSTE. Por lo que a pesar dealcanzar 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 aquellostrabajadores eventuales cuyo contrato hubiera concluido. • Cambios de adscripción Se refiere al proceso mediante el cual un trabajador cambia de lugar de adscripción alque 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 recibenlos trabajadores por los riesgos de laborar en unidades orgánicas con lugares insalubresy laboratorios donde se manejen sustancias químicas tóxicas que pudieran atentar contrala salud y el bienestar de los trabajadores. • Primas especiales Este tipo de beneficios lo otorgan algunas instituciones a aquellos trabajadores quecumplen alguna condición de trabajo especial. Por ejemplo, la prima sabatina y dominicalque se ofrece en algunas instituciones para aquellos trabajadores que laboran los finesde 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 serequieran conforme al tipo de movimiento. Este sistema deberá contemplar las siguientes facilidades: 1. Confirmación de movimientosP R O N A DP R O N A D 75
  3. 3. Programa para la Normalización de la Información Administrativa 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 através de los cuales se acote el universo de empleados. Los criterios podrán ser tanestrechos como lo requiera el usuario, por ejemplo, podrá seleccionar todos aquellosempleados 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 obtenidosu 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 cadauno de los trabajadores administrativos.Expedientes del personal El sistema deberá registrar los documentos que ingresan al archivo de personaladministrativo, tales como acta de nacimiento, título, oficios, nombramientos, etc. Paraesto se recomienda la digitalización de los documentos.Subsistema de personal docente La funcionalidad y características de este subsistema deberá ser semejante al delsubsistema de personal administrativo, sólo que referente a los movimientos y datos delpersonal docente. A continuación describimos algunas de las funciones y procesos a loscuales 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 D76
  4. 4. Especificaciones técnicas del SIIA Descripción del sistema computacional integral • Asignación de cargas de trabajo a docentes Se refiere al proceso mediante el cual se determinan las cargas de trabajo de losdocentes de todas las unidades orgánicas de la institución. Para cada uno de los docenteshabrá 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 controlescolar y asuntos financieros. Las horas de clase y/o laboratorio que se asignen en elmó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 financieropresupuestado 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 casoajustadas por la unidad orgánica responsable. • Basificación de docentes Procedimiento mediante el cual un docente pasa a formar parte de la planta permanentede profesores de una institución. Desde el punto de vista de este módulo la operaciónresulta 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 Esteprocedimiento se aplica sólo en aquellas instituciones en las cuales las basificaciones seasignan 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 losdocentes. Así también controlar qué documentos se encuentran físicamente en poder dela universidad. Estos expedientes deberán actualizarse siendo lo más deseable que losdocumentos 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 • Publicaciones11 Cambio de unidad orgánicaP R O N A DP R O N A D 77
  5. 5. Programa para la Normalización de la Información Administrativa • Proyectos e investigaciones • Becas y estímulos • Especialidad Además de esta información se podrán consultar todos los datos laborales de losdocentes, 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 instanciacorrespondiente, se modifica el grupo laboral, categoría o nivel del docente. Cualquierade las anteriores modificaciones resultan de gran relevancia ya que se reflejarán en lanómina. El sistema deberá registrar la fecha del movimiento, la vigencia, el responsablede 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 lasatribuciones para autorizarlo podrá revisar, a través del sistema, que éste cumpla losrequisitos 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 otorgamientode becas a sus docentes, una vez aprobadas por el área correspondiente, se tendrá queingresar el movimiento al sistema, señalando entre otros el monto, periodo, fondo dedonde proviene, etcétera. • Proyectos de investigación Este procedimiento se refiere a la asignación de un docente a algún proyecto deinvestigació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 vezexpedida la convocatoria y evaluados los docentes que hicieron el trámite, se ingresará P R O N A D P R O N A D78
  6. 6. Especificaciones técnicas del SIIA Descripción del sistema computacional integralen el sistema el monto y periodo de los estímulos para aquellos docentes que se hubieranvisto beneficiados. En aquellas instituciones en donde además de personal administrativo (trabajadores) ypersonal docente exista otra clasificación (por ejemplo empleados de confianza), se deberáagregar un subsistema adicional, en donde se den los movimientos conforme a lascaracterí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 detabuladores, estímulos y descuentos, los procesos para el cálculo y aplicación dedescuentos 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 queen muchas de las universidades el porcentaje más alto de recursos lo constituye el pagode este rubro. La generación de la nómina es un procedimiento ligado de manera muy especial con elmódulo financiero. Conforme a la contabilidad de fondos el sistema tendrá que dejarperfectamente establecido el desglose por unidad responsable y fondo, así como corroborarque 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 oen 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, querecibirán su pago. El usuario entrará a una pantalla, donde podrá teclear el periodo para lanómina que se elaborará. Tendrá la opción de generar una nómina en forma general o porunidad 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 lageneración de la nómina realizarán diferentes tipos de movimientos para las cuales seutilizará 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 (estesalario será con base en la categoría nivel de los trabajadores, el cual existe en tablas yadeterminadas y calculadas por cada institución). Estos movimientos se registrarán a nivelsistema en la base de datos de movimientos, el cual almacenará cada uno de losmovimientos que se realizaron para cada trabajador. Cuando se llegue a la quincena yP R O N A DP R O N A D 79
  7. 7. Programa para la Normalización de la Información Administrativasea necesario elaborar la prenómina o nómina, a cada trabajador se le calculará su sueldofinal, una vez que se haya sumado (o restado, según sea el caso) el monto de cada unode los movimientos en los que participó a lo largo de la quincena. El Catálogo dePercepciones y Deducciones se caracteriza porque se aplica de manera general a todoslos 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 basede datos de movimientos se transferirán a una tabla histórica de movimientos, la cualcontendrá la información de todas las nóminas que ha generado la institución. En la tablade movimientos se borrará toda la información, por lo cual ya estará lista para que durantela 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 unestatus (cerrado, abierto), lo cual para poder realizar los movimientos es necesario queeste “Abierta”, ya que a la quincena a la hora de generar la nómina, se cerrará la base dedatos, 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ána 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 D80
  8. 8. Especificaciones técnicas del SIIA Descripción del sistema computacional integral Usuario que dio la alta Fecha de modificación del catálogo Usuario que realizó la modificaciónAsignació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á registradoen 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 • UsuarioEmisió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 prestacionesa las que tiene derecho todo el personal, como pueden ser préstamos en efectivo, enespecie, 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 delcatá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 delsalario.P R O N A DP R O N A D 81
  9. 9. Programa para la Normalización de la Información Administrativa 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 depercepciones 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ónAsignación de prestaciones Se refiere al manejo y control de las prestaciones comunes para todos los empleadosde la universidad (docentes, administrativos y trabajadores) ya sea que se trate deprestaciones 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 D82
  10. 10. Especificaciones técnicas del SIIA Descripción del sistema computacional integral Se refiere al proceso de asignar al trabajador las prestaciones que se merece. A travésde una pantalla, se tecleará la clave del docente y de la prestación, y al relacionarla (alpresionar el botón de Actualizar) quedará la asignación registrada en la base de datos delsistema.Datos de entrada: • Clave o número del trabajador (docente y administrativo) • Clave de la prestaciónReportes 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 quepermitan tener un control sobre el personal de la institución. Entre otros los que acontinuación se describen: Se requiere que el sistema muestre una pantalla de reportes, en donde se puedaseleccionar el tipo de consulta o reporte que se desea. Con base en el tipo de reporte enla 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 sehagan las consultas, los departamentos que tengan acceso a realizar modificaciones enel sistema podrán efectuar los cambios de algún registro en particular con sólo dar dobleclick 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 sehubieran realizado a la base de datos en un período determinado.Módulo de control escolarAdmisionesRegistro de aspirantes Se refiere al procedimiento por el cual se registra la información básica de los aspirantesa ingresar a cada institución. En caso de que se requiera de un pago para realizar estetrámite el sistema deberá verificar que exista o se deberá presentar una ficha del banco ola tesorería que avale el mismo.P R O N A DP R O N A D 83
  11. 11. Programa para la Normalización de la Información AdministrativaSelecció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 seleccionadosestos alumnos el sistema habrá de ingresarlos a la base de datos de alumnos.InscripcionesInscripciones a ciclo escolar Se refiere al procedimiento mediante el cual los alumnos se inscriben para ingresar aun nuevo ciclo escolar. Este procedimiento deberá ir acompañado con el o los pagoscorrespondientes, 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 escogidosiempre y cuando haya cupo, el plan de estudios lo permita y haya realizado los pagoscorrespondientes.Revalidaciones Aquí se dan de alta todos los alumnos que ingresan a la institución sin el proceso deselecció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 oreconocimiento).Control de grupos Mediante este procedimiento se asigna una materia/grupo a un salón y a un profesordeterminado. • 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.13Acopio de calificaciones e impresión de actas Proceso por el cual se recopilan las calificaciones entre los profesores universitarios alfinal 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 cuentecon las características necesarias de acuerdo con el tipo de curso a impartir. P R O N A D P R O N A D84
  12. 12. Especificaciones técnicas del SIIA Descripción del sistema computacional integral • 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 todoslos alumnos de cada institución. Este expediente estará conformado con toda la informaciónexistente 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 dedocumentos 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 DP R O N A D 85
  13. 13. Programa para la Normalización de la Información Administrativa 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, entreotros aspectos, para cada una de las materias cursadas, el número de acta en la queapareció 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 digitalizadosEstadí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ísticadetallada o total. El detalle es un listado con datos, asimismo permitirá almacenar lasestadísticas por si alguna de ellas se quisiera comparar en una gráfica. P R O N A D P R O N A D86
  14. 14. Especificaciones técnicas del SIIA Descripción del sistema computacional integral Para poder graficar estadísticas, éstas se debieron haber grabado con anterioridad, seasignan las estadísticas que se encuentran almacenadas y que se quieran graficar y elsistema la ejecuta inmediatamente poniendo en el espacio el resultado. Pueden hacersecomparaciones hasta de 24 columnas, esto es, que se pueden crear 24 estadísticasdiferentes, grabarlas y compararlas en una gráfica. Una vez que se asignan todas lasestadísticas, se presiona el botón graficar y se obtiene el resultado, que puede mandarsea 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 siguientesdocumentos: • 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óny 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.1414 El sistema mantendrá el registro histórico de los planes de estudio.P R O N A DP R O N A D 87
  15. 15. Programa para la Normalización de la Información AdministrativaExpedición de credencial Es recomendable que los sistemas de control escolar contemplen la credencializacióncomo 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 financieroy de recursos humanos. La información de los docentes se obtendrá, partir de ligas con labase de datos de recursos humanos. Todos los movimientos de control escolar querequieran de la realización de un pago se tendrán que reflejar conforme a la cuenta, fondoy función que se maneja en el módulo de financiero. P R O N A D P R O N A D88
  16. 16. Especificaciones técnicas del SIIA Contabilidad matricialIV. CONTABILIDAD MATRICIALIntroducción La contabilidad es un medio para brindar información en relación con las actividadesfinancieras realizadas por las instituciones públicas o privadas. En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidadinformación financiera más completa y detallada. Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayudaa preparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos ymetas financieras. La calidad de la información financiera ha sido fuertemente criticada por los directivosque suelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan propuestoy 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 necesidadesinternas y externas de la administración con orientación pragmática, destinada a facilitar lasfunciones 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 mismascaracterí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 empresascomerciales. a) Las empresas comerciales tienen fines de lucro.P R O N A D 89
  17. 17. Programa para la Normalización de la Información Administrativa 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 unade ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienesy servicios y son su principal fuente de recursos, y sus ganancias están determinadas por larelación que guardan sus ingresos respecto a sus gastos, para una institución de educaciónmás del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados deacuerdo 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 deacuerdo con los principios de contabilidad generalmente aceptados. Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en lamanera de presentar situaciones especiales. En tales situaciones la metodología contabledifiere de un campus a otro. El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de lainstitución, así como de su historia. Un sistema de contabilidad no necesariamente refleja todas las operaciones financierasque 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 legadosa 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 incluidosen los estados financieros. Esto nos lleva a pensar que el sistema de contabilidad de la institución puede noproporcionar una realidad completa de la situación financiera. Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a queaquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, queestán restringidas para su uso, ya que su utilización está asociada a propósitos, funciones yactividades en particular. Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamentepara becas. P R O N A D90
  18. 18. Especificaciones técnicas del SIIA Contabilidad matricial Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recursoque no sea para el fin que fue dado. Dada esta característica en particular, que distingue la contabilidad que debe seguir unainstitució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 debase para la codificación de una operación financiera. Para estructurar el código, esnecesario haber diseñado ya los catálogos. El código a utilizar debe tener los siguientesdatos: 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 ydentro del patrimonio lo relativo a sus adiciones y/o disminuciones, es decir, ingresos ygastos. El número de dígitos que se estimen para cada componente, dependerá de lasnecesidades de información de cada institución. Por otro lado, no es necesario seguir elorden presentado, ya que cada institución lo puede adaptar a su sistema actual. Lo importantees el nivel de agrupamiento y lo que cada posición signifique. La única condicionante es queel código inicie con el fondo.Fondo Es una entidad contable que tiene un grupo de cuentas autobalanceables, es decir, quetiene 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 relacionadascon subsidios que tengan restricciones particulares para su uso, fuentes de recursosrestringidos, o importes designados que han sido establecidos por la junta de gobierno de lainstitución. Esas entidades contables se establecen para asegurarse de que los recursosserán utilizados de acuerdo con las restricciones impuestas, en este caso, por el otorganteP R O N A D 91
  19. 19. Programa para la Normalización de la Información Administrativadel recurso o bien por la junta de gobierno. Los fondos utilizados en contabilidad matricialson: 1. De operación 2. De reservas 3. Activos fijos 4. Otros fondosFunción Agrupación, clasificación y registro de los gastos asociados al cumplimiento de la misióninstitucional. 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 auxiliaresUnidad orgánica Es un organismo académico, académico-administrativo o administrativo de una institucióneducativa, que tiene a su cargo una o varias de las funciones que realiza la institución, o bienen las que participa.Cuenta Identifica al conjunto homogéneo y ordenado de bienes y servicios, el cual, de acuerdocon 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 D92
  20. 20. Especificaciones técnicas del SIIA Contabilidad matricial • 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 procesosadministrativos para a su vez eficientar la operación de la universidad. Para lo cual, entreotras cosas, es necesario contar con información acerca del desempeño financiero deinstituciones similares. Contribuir a la homologación y estandarización del sistema deinformación financiera de las universidades, indudablemente proporcionará un mejor usode los recursos y una participación mas útil en el esfuerzo de la educación superior en elpaís.P R O N A D 93
  21. 21. Programa para la Normalización de la Información Administrativa P R O N A D P R O N A D94
  22. 22. 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 entidadesque se refieran a personas. Lo anterior en función de que existe una disposición a unificartodos 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ónque se asigna a todas las personas que viven en el territorio nacional, así como a losmexicanos que residen en el extranjero. El Registro Nacional de Población (RENAPO) es lainstancia 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, quese generan a partir de los datos contenidos en el documento probatorio de identidad (actade 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 sucorrecta integración.¿Qué datos contiene la CURP? Un ejemplo de esto sería el siguiente: tenemos a una persona con nombre Ricardo AlamánPérez, que nació en el Distrito Federal, el 21 de marzo de 1963, su CURP sería AAPR630321 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 PersonalP R O N A DP R O N A D 95
  23. 23. Programa para la Normalización de la Información Administrativa¿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 lasinstituciones públicas. La CURP se incorporará paulatinamente a todos los documentos oficiales, como sedescribe a continuación como ejemplo, a fin de fortalecer las condiciones de seguridadjurídica de la población; mejorar los vínculos entre ésta y las instancias de gobierno, parafacilitar la prestación de los bienes y servicios, y simplificar la administración pública al eliminarla 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 laatribución para registrar y acreditar la identidad de todas las personas residentes en el paísy 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 D96
  24. 24. 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 AcuerdoPresidencial 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 elterritorio 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 deintegrar 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 cualquierregistro de personas.P R O N A DP R O N A D 97
  25. 25. Programa para la Normalización de la Información Administrativa P R O N A D98
  26. 26. Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de softwareVI. CONSIDERACIONES GENERALES SOBRE LA INGENIERÍA DE SOFTWARE La ingeniería de software es una disciplina que integra proceso, método y herramientaspara el desarrollo del software de computadoras. Sobre ésta, se está llevando a cabo unafuerte 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 vercon una epistemología basada en el principio de autoridad, ya que la mayoría de los tratadosde ingeniería de software están basados en una combinación de experiencia anecdótica yautoridad humana, raramente se acompañan de evidencia lógica o experimental. Estoprovoca la carencia de una base sólida que le dé un carácter científico a la ingeniería desoftware. El segundo tiene que ver con un principio práctico aplicado de manera generalizada en laingeniería de software y es el famoso precepto de divide y vencerás, es decir, se ha venidoaplicando dogmáticamente este principio, separando las actividades propias del análisisde las actividades de diseño. Por otra parte se presupone que una vez establecido el algoritmo, que se obtiene de ladivisión del proceso de desarrollo de software en diversas etapas, se asume que es factibledesarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmoque 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 lasactividades de diseño y las de análisis. Dado lo anterior se puede entonces establecerque 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á necesariamentereferido 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 porla 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 deun sistema de información no puede ser tajante ni rígida. A continuación describimos deforma muy general algunos modelos y metodología para la construcción de un sistema. Cadaparadigma exhibe ventajas y desventajas, sin embargo, mantiene una serie de fasesgenéricas en común.Modelos de ingeniería de softwareEl modelo lineal secuencial Llamado algunas veces “ciclo de vida básico” o “modelo en cascada”, el modelo linealsecuencial es un enfoque sistemático, secuencial del desarrollo del software que comienzaen un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas yP R O N A D 99
  27. 27. Programa para la Normalización de la Información Administrativamantenimiento. Modelo según el ciclo de ingeniería convencional, el modelo lineal secuencialacompaña a las actividades siguientes: Ingeniería y modelado de sistemas/información. Como software siempre forma parte deun sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todoslos elementos del sistema y asignando al software algún subgrupo de estos requisitos. Estavisión del sistema es esencial cuando el software se debe interconectar con otros elementoscomo hardware, personas y bases de datos. La ingeniería y el análisis de sistemas acompañaa los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis yde diseño. La ingeniería de información acompaña a los requisitos que se recogen en elnivel 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 intensificay 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 deinformació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 yde software. Diseño. El diseño del software es realmente un proceso de muchos pasos que se centraen cuatro atributos distintos de un programa: estructura de datos, representaciones de interfazy detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en unarepresentación del software que se pueda evaluar por calidad antes de que comience lageneración del código. Al igual que los requisitos, el diseño se documenta y se hace partede la configuración del software. Generación de código. El diseño se debe traducir en forma legible por la máquina. Elpaso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de unaforma 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, asegurandoque todas las sentencias se han comprobado, en los procesos externos funcionales, esdecir, que la realización de las pruebas para la detección de errores y sentirse seguro de laentrada definida produzca resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El software individualmente sufrirá cambios después de ser entregado alcliente (una excepción posible es el software empotrado). Se producirán cambios porque sehan encontrado errores, porque el software debe adaptarse para acoplarse a los cambiosde su entorno externo ( p. ej.: se requiere un cambio debido a un sistema operativo o dispositivoperiférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. Elmantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existentey no a uno nuevo. El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizadoen 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 D100
  28. 28. Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de softwareeficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencialse 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ásicotiene un lugar definido e importante en el trabajo de la ingeniería de software. Proporcionauna plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebasy mantenimiento. El ciclo de vida clásico sigue siendo el modelo de proceso másextensamente utilizado por la ingeniería del software. Pese a tener debilidades, essignificativamente 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 noidentifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, elresponsable 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 tomarsela interacción hombre-máquina. En éstas y en muchas otras situaciones, un paradigma deconstrucción de prototipos puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la recolección de requisitos. Eldesarrollador 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ásdefinición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en unarepresentació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 unP R O N A D 101
  29. 29. Programa para la Normalización de la Información Administrativaprototipo. El prototipo lo evalúa el usuario y lo utiliza para refinar los requisitos de software adesarrollar. 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 requisitosdel software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso delos fragmentos del programa ya existentes o aplica herramientas (p.ej.: generadores deinformes, 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 alternativasino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estosproblemas. Cuando se utiliza un concepto nuevo de sistema o de una tecnología nueva, setiene que construir un sistema que no sirva y se tenga que tirar, incluso la mejor planificaciónno es omnisciente como para que esté perfecta la primera vez. Por tanto, la pregunta sobrela gestión no es si construir un sistema piloto y tirarlo. La única pregunta es si planificar deantemano 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 paradigmaefectivo 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 paraservir como un mecanismo de definición de requisitos. Entonces se descarta (al menos enpartes) y se realiza la ingeniería del software con una visión hacia la calidad y facilidad demantenimiento. P R O N A D P R O N A D102
  30. 30. Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de softwareEl modelo DRA El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development, RDA) esun modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo dedesarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” delmodelo lineal secuencial en el que se logra el desarrollo rápido, utilizando un enfoque deconstrucció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 “sistemacompletamente 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 enfoqueDRA comprende las siguientes fases. Modelado de gestión. El flujo de información entre las funciones de gestión se modela deforma que responda a las siguientes preguntas: ¿Qué información conduce al proceso degestión? ¿Qué información se genera? ¿Quién la genera? ¿Adónde va la información? ¿Quiénla procesa? Modelado de datos. El flujo de información definido como la parte de la fase de modeladode 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 relacionesentre estos objetos. Modelado de proceso. Los objetos de datos definidos en la fase de modelado de datosquedan transformados para lograr el flujo de información necesario para implementar unafunció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 cuartageneració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 todoslos 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 comprobadomuchos 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 detiempo impuestas en un proyecto DRA demandan “ámbito en escalas”. Si una aplicación degestión puede modularse de forma que permita completarse cada una de las funcionesprincipales en menos de tres meses (utilizando el enfoque descrito anteriormente), es uncandidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo delDRA 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
  31. 31. Programa para la Normalización de la Información Administrativa • 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 deherramientas de software y la especificación de algunas características del software de altonivel. Luego, la herramienta genera automáticamente el código fuente basándose en laespecificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel enel que se especifique el software, más rápido se podrá construir el programa. El paradigmaT4G para la ingeniería del software se orienta hacia la posibilidad de especificar éste usandoformas de lenguaje especializado o notaciones gráficas que describan el problema que sedebe resolver en términos entendibles para el cliente. Actualmente, un entorno para eldesarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de lassiguientes 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 deaplicación muy específicos, aunque actualmente los entornos T4G se han extendido a todasla 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 directamentea un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El clientepuede no estar seguro de lo que necesita; ser ambiguo en la especificación de hechos quele son conocidos, y no ser capaz o no estar dispuesto a especificar la información en laforma 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 enfoqueT4G. Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección derequisitos al paso de implementación, usando un lenguaje de cuarta generación noprocedimental ( L4G). Sin embargo, es necesario un mayor esfuerzo para desarrollar unaestrategia 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 desarrollasoftware mediante los enfoques convencionales. P R O N A D P R O N A D104
  32. 32. Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de software La implementación mediante L4G permite, al que desarrolla el software, centrarse en larepresentación de los resultados deseados, lo que se traduce automáticamente en un códigofuente que produce dichos resultados. Obviamente, debe existir una estructura de datos con información relevante y a la que elL4G pueda acceder rápidamente. Para transformar una implementación T4G en un producto, el que lo desarrolla debeapoyarse 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 softwaredesarrollado con T4G debe ser construido de modo que facilite la realización delmantenimiento de forma expeditiva. Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas einconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollodel 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 utilizarque los lenguajes de programación, que el código fuente producido por tales herramientases “ineficiente” y que el mantenimiento de grandes sistemas de software desarrolladosmediante 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 parteimportante del desarrollo del software. Cuando se combinan con enfoques de ensamblajede componentes, el paradigma T4G se puede convertir en el enfoque dominante hacia eldesarrollo 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 durantelas tres primeras décadas. Antiguamente el diseño se centraba en los criterios de desarrollode programas modulares y métodos para refinar la arquitectura software de una maneradescendente en la jerarquía. Los aspectos procedimentales de la definición del diseño delP R O N A D 105
  33. 33. Programa para la Normalización de la Información Administrativamodelo evolucionaron hacia una filosofía denominada programación estructurada. Algunostrabajos posteriores proponían métodos para la transformación de flujo de datos o de laestructura 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 anteriormentese aplican en la industria. Al igual que los métodos de análisis, todos los métodos de diseñode software presentan unas heurísticas y notaciones únicas. Así como una visión algo particularde cómo lograr la calidad del diseño. Sin embargo, todos estos métodos tienen unascaracterísticas comunes: (1) un mecanismo para la transformación de un modelo de análisisen una representación del diseño, (2) una notación para representar componentes funcionalesy sus interfaces, (3) heurísticas para el refinamiento y la participación y (4) consejos paramejorar la calidad . Independientemente del método del diseño que se emplee, un ingeniero de softwaredebería aplicar un conjunto de principios fundamentales y conceptos básicos al diseño dedatos, arquitectónico, de interfaz y procedimental. Estos principios y conceptos se consideranen las siguientes secciones. El diseño del software es un proceso y un modelo a la vez. El proceso de diseño es unconjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos delsoftware a construir. Hay que aclarar, sin embargo, que el proceso del diseño no es unsimple “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. Empiezarepresentando la totalidad de lo que se va construir (p.ej.: una representación tridimensionalde la casa) y lentamente lo va refinando para proporcionar una directriz y construir cadadetalle (p.ej.: el plano de las cañerías ). Similarmente, el modelo de diseño creado para elsoftware proporciona varias visiones diferentes del programa de computadora. Los principios básicos del diseño permiten al ingeniero del software navegar en el procesode diseño. Davis sugiere un conjunto de principios para el diseño del software que hansido 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 D106
  34. 34. Especificaciones técnicas del SIIA Consideraciones generales sobre la ingeniería de software 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, elingeniero 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 observarlos usuarios (p. ej.: velocidad, fiabilidad, corrección, utilidad). Los factores de calidad internosson importantes para los ingenieros del software, permiten un diseño de alta calidad desdela perspectiva técnica. Para conseguir los factores de calidad interna, el diseñador debeentender los conceptos básicos de diseño.P R O N A D 107
  35. 35. Programa para la Normalización de la Información Administrativa P R O N A D P R O N A D108
  36. 36. Especificaciones técnicas del SIIA Conceptos básicos sobre las bases de datos relacionalesVII. CONCEPTOS BÁSICOS SOBRE LAS BASES DE DATOSRELACIONALES El modelo relacional es un modelo muy elegante y claro, ha constituido los cimientos de laindustria de las bases de datos durante casi 20 años. El relativamente pequeño número deconceptos existentes en la teoría relacional ha ayudado a convertir esta técnica en un estándarindustrial. Los diseñadores relacionales han sido capaces de aislar la complejidad deldesarrollo físico de las bases de datos respecto al diseño lógico del sistema, proporcionandoasí una interfaz sencilla para los diseñadores de aplicación. Durante las dos últimas décadas hemos madurado como industria. Muchos de nosotroshemos sentido la necesidad de contar con un entorno de modelización más rico que seadaptara 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íanintroducirse en el mundo de las bases de datos y que podrían mejorar la eficiencia de lasmismas. Las bases de datos relacionales cuentan con un vocabulario relativamente limitado. Hemosimplementado estructuras utilizando archivos planos diseñados juiciosamente yposteriormente, hemos introducido algunos tipos de índices distintos en varios campos deesos archivos. En lo referente al acceso, los vínculos entre tablas sólo se especificaban deforma lógica, por lo que los punteros de referencia se llevaban a cabo mediante clavesexternas. No necesitábamos contar con vínculos explícitos entre las tablas. Las limitacionesde integridad referencial eran, simplemente pequeños trozos de código que evitaban laintroducció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ícitamentealguna actividad cuando se insertaba, actualizaba o borraba algún registro, y se almacenabanunidades de programa en la base de datos. Finalmente, podíamos agrupar tablas para mejorarel rendimiento. Todas estas estrategias limitaban nuestra forma de pensar. En una base dedatos relacional, cada tabla es virtualmente una estructura independiente. En la creación de modelos de relaciones lógicas de entidades (ER) teníamos entidadesque eran subconjuntos de otras entidades. Por ejemplo, los empleados asalariados eranun subconjunto de todos los empleados. De la misma forma, teníamos entidades quedependían de otras entidades, tales como detalles OC, que dependían de órdenes decompra. Sin embargo, nuestra capacidad para representar estas estructuras utilizandobases de datos es limitada . Paradójicamente las bases de datos orientadas a objetosretienen 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 deobjetivo 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 listasvinculadas y los punteros. Tenemos que recordar cómo era el mundo de las bases de datosantes de la aparición de la metodología relacional a principios de la década de los añosP R O N A D 109
  37. 37. Programa para la Normalización de la Información Administrativaochenta. Todavía siguen existiendo (al menos hasta que el problema del año 2000 acabecon ellas) bases de alto rendimiento que utilizan archivos CODASYL, ISAM y VSAM escritosen COBOL. Las modificaciones a las bases de datos CODASYL suelen exigir meses deesfuerzo. Hace ya algunos años nos encontramos con un antiguo proyecto COBOL en el quesurgió un nuevo requisito, cambiar la anchura de un campo de 10 a 12 caracteres. Estapequeñ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 algunosdías de trabajo. Si la aplicación se generó con una herramienta CASE integrada, la realizaciónde 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ónde informes era una tarea muy difícil. Si un determinado informe no había sido tomado encuenta durante las especificaciones originales del diseño, podría exigir semanas de trabajoescribir un nuevo informe (suponiendo que fuera posible escribirlo). Las modificaciones alas estructuras de datos subyacentes eran muy engorrosas. Los cambios más pequeñosparecían exigir un rediseño importante del sistema. No estamos afirmando que todos estosproblemas 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 dearchivos planos. La normalización se consideraba como una curiosidad académica. Contiempo, al menos con la tercera forma normal, se pudo constatar que la normalización no erauna idea tan mala. En la era de las desnormalizaciones, ocurrida en la década de los añosochenta, tuvimos los mismos problemas con las estructuras relacionales que con los archivosplanos. Modificar una estructura de datos seguía siendo una labor difícil y cara, lo mismoocurría si se deseaba modificar una aplicación. En la década de los noventa, la mayoría delos diseñadores de datos habían podido comprobar que las fuertes desnormalizacionesefectuadas en los ochenta estaban pasando factura, causando problemas de forma masivaen 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 aobjeto comenzaron a introducirse en las bases de datos relacionales. Este tema implicó lageneralización de modelos creando estructuras abstractas, a la vez que todavía seguíamostrabajando en el entorno de bases de datos relacionales. En los últimos años, parte de lacomunidad de diseñadores de base de datos relacionales han abrazado ya la metodologíaorientada a objeto. En la actualidad, es frecuente ver cierto nivel de modelización genérica en la mayoría delos sistemas. Por ejemplo, existe un estándar industrial para representar las unidadesorganizativas como una simple estructura recursiva, en lugar de utilizar tablasindependientes para regiones, divisiones y departamentos (o sea cual sea la estructura parauna determinada empresa). Incluso, cada vez son más frecuentes los modelos más abstractos. En una conferenciacelebrada recientemente, alguien que diseñaba una base de datos de cuestionarios mepreguntó cómo podría manejar una tabla como varios cientos de columnas. Cada cuestionarioconsta de cientos de preguntas. Varias personas que se encontraban entre los asistentes P R O N A D P R O N A D110
  38. 38. Especificaciones técnicas del SIIA Conceptos básicos sobre las bases de datos relacionalesrespondieron que se debía modelizar el cuestionario introduciendo las preguntas en unatabla 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 estabaencontrando 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 funcionesorientadas a objeto. En segundo lugar, disponemos de un nuevo lenguaje de modelizaciónmás rico; nos referimos a UML frente al antiguo ERD. Como mencionamos anteriormente,estos nuevos conceptos incluyen realmente algunos de los viejos conceptos del pensamientoprerrelacional con listas vinculadas y punteros. Esta nueva integración de lo nuevo y de loviejo representa una gran oportunidad, pero también se debe tomar con precaución. En laactualidad, podemos construir estructuras relacionales que funcionan de manera más eficaz.Pero si no somos cuidadosos, podremos perder parte de la flexibilidad de las estructurasque 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 datosfrente al físico. El modelo lógico de datos representa el diseño de la base de datos, mientrasque el modelo físico representa la realización del diseño. Se utilizan palabras distintas paracomparar el diseño lógico y el diseño físico. Todo esto puede ser algo confuso. El siguienteesquema ayuda a clarificar esta terminología para poder seguir con nuestro debate:Lógico relacional Lógico objeto FísicoEntidad Clase TablaAtributo Atributo Columna, campoInstancia Objeto Fila Para asegurar la consistencia es importante clarificar las definiciones que son importantespara este análisis: Entidad. Se trata de algo que tiene interés para la empresa, tal como un empleado, undepartamento 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 pensaren entidades. Es mejor pensar que una entidad es algo que tiene correspondencia en elmundo real. Cada instancia de la entidad departamento, por ejemplo, se corresponde conun departamento específico en la organización (o en el caso de la entidad persona, a unapersona específica). Existe una correspondencia directa entre entidades e instancias de lateoría relacional y clases y objetos, respectivamente, en teoría de objetos. Por ejemplo, parala entidad departamento podemos hablar de la clase departamento, que incluirá el objetocontabilidad. Atributo. Se trata de una pieza de información que podemos extraer de un objeto o instanciade 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
  39. 39. Programa para la Normalización de la Información Administrativa Clave primaria. Se trata de un concepto de teoría relacional que describe los atributos deuna 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 apropiadapara 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 hansido 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 datosrelacionales. 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 puedaservir 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 clavescandidatas.Creación de un diagrama entidad-relación El diagrama de entidad-relación permite que un ingeniero de software especifique losobjetos de datos que entran y salen de sistema, y las relaciones entre los objetos. Al igualque la mayoría de elementos del modelo de análisis y las relaciones entre objetos, el DERconstruye 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 D112
  40. 40. Especificaciones técnicas del SIIA Conceptos básicos sobre las bases de datos relacionalesReglas de normalización Cuando decimos que una base de datos ha sido normalizada, no nos estamos refiriendoa normal en el sentido de regular u ordinario. En este contexto, normalizado (adjetivo derivadode la notación matemática de normal) significa ortogonal. Volviendo a nuestras olvidadasclases de álgebra lineal, recuerde que el término normalizado se utilizaba conjuntamentecon los vectores ortogonales en un espacio vectorial y en análisis del tipo: ¿puede unacombinació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, eneste caso, se está intentando desarrollar un conjunto de tablas en la base de datos que no sesuperpongan de manera inapropiada y que nos permitan almacenar toda la información quepueda contener la base de datos en la misma forma en que tres vectores unitarios ortogonalespueden generar un espacio de tres dimensiones. No vamos a entrar en discusiones formales sobre normalización. Podrá encontrar estetipo 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 losnumerosos libros académicos que analizan las bases de datos. Iremos presentandodefiniciones de normalización con un sentido más práctico y más apropiado para los objetivosperseguidos por este libro. ¿Por qué queremos construir bases de datos normalizadas? La normalización nació enconjunción con el lenguaje de programación denominado SEQUEL. El teorema fundamentalde la teoría relacional es que si su base de datos se encuentra normalizada, podrá extraercualquier subconjunto de datos de ella utilizando operadores básicos de SEQUEL. Por estemotivo la normalización es tan importante. Puede ser muy complicado extraer informaciónde una base de datos no normalizada sin tener que desarrollar un código complejo, estasreglas de normalización fueron importantes en los modelos relacionales y siguen siendoimportantes en los modelos objeto-relacionales. Todavía seguimos utilizando SQL+ o una extensión orientada a objeto de SQL (una versiónde SEQUEL) para manipular la información contenida en las bases de datos. Si no trabajamoscon bases de datos normalizadas, SQL puede no funcionar. Aunque una persona hayatrabajado durante toda su carrera profesional en entornos de DBMS, puede no conocer losentornos existentes antes de la aparición de las bases de datos racionales. El cambio deorientación del papel en la impresión de un informe llevaba, al menos, dos semanas. Confrecuencia, los intentos de realizar pequeñas modificaciones en una estructura de datosllevaban meses e incluso años de tiempo de desarrollo. Si la intención era incluir nuevasfunciones, nos encontrábamos con miradas vacías, movimientos de cabeza y respuestasdel tipo “dada la actual arquitectura del sistema, las modificaciones que usted propone no sepueden llevar a cabo”. Si abandonamos las reglas de normalización para la creación debases de datos orientadas a objeto, corremos el riesgo de dar un paso de gigante haciaatrás en términos de flexibilidad de los sistemas que desarrollaremos.P R O N A D 113

×