anÁlisis funcional del proyecto avanza … · intercambio previamente establecidos. del mismo...

Secretaria de Estado de Telecomunicaciones y para la Sociedad de la información

Avanza LOCAL PADRÓN

Página 1 de 55

ANÁLISIS FUNCIONAL DEL PROYECTO AVANZA LOCAL-PADRÓN

Versión 0 Revisión 1

ÍNDICE

1. Introducción .......................................................................................... 2

2. Descripción de la situación actual del sistema ............................................ 4

3. Proyecto................................................................................................ 6

4. Requisitos comunes de los módulos .........................................................11

1. Gestión de históricos ........................................................................11 2. Gestión de identificadores .................................................................13 3. Datos de control ..............................................................................14 4. Gestión de documentos ....................................................................15 5. Idioma............................................................................................16 6. Terminología usada ..........................................................................17

5. Módulos funcionales...............................................................................18

1. Territorio ........................................................................................18 2. Personas.........................................................................................23 3. Identificación y localización de Personas .............................................26 4. Exportaciones de datos para Censo Electoral - Cierres ..........................28

6. Módulos de gestión ................................................................................30

1. El sistema Transaccional ...................................................................30

7. Construcción del sistema. Punto de partida. ..............................................35

8. Propuesta de definición de tablas.............................................................39

1. Territorio- Diagrama Entidad – Relación..............................................40 2. Territorio – Definición de las tablas ....................................................41 3. Tablas de Personas. Diagrama Entidad – Relación ................................46 4. Tablas de Personas. Definición de tablas .............................................47 2. Tablas del Módulo Transaccional. Modelo Entidad-Relación ....................52 3. Tablas del Módulo Transaccional. Definición de las tablas ......................53



Página 2 de 55

1. Introducción

El equipo redactor del presente documento ha pretendido plasmar en el mismo las líneas generales que desarrollará el análisis funcional del proyecto Avanza-Padrón, fruto de su interpretación del Pliego de Condiciones y los requerimientos formulados por los interlocutores, a los que agradecen la dedicación que les han dedicado. Es cierto que al tratarse de una aplicación en la que se interrelacionan tantos organismos de la Administración General del Estado, multitud de entes locales, la Administración autonómica y, los propios ciudadanos, en el momento actual la solicitud de requerimientos que se ha efectuado ha sido principalmente del INE, se ha iniciado con la Federación de Municipios y aún no se ha llevado a cabo con el Ministerio de Administraciones Públicas. Esta priorización no es casual, sino que hemos entendido que al corresponder al INE la coordinación de los Padrones Municipales por una parte y por otra le corresponde la formación del Censo Electoral, debía ser este organismo el eje de formación del sistema Censo Padrón, obviamente junto con los Ayuntamientos, responsables de la formación, mantenimiento y custodia de los Padrones Municipales. Y, una vez conocidos los requerimientos que deben contemplar los subsistemas, se comenzará a la solicitud del resto de interlocutores del subsistema Otras Administraciones y Ciudadano. El esquema de organización planteado en la presentación del proyecto Avanza-Padrón, sigue completamente vigente. Existen pocos cambios que debamos añadir a la estructura de relaciones planteada por este esquema desde su presentación.



Página 3 de 55

Nucleo territorial Común

PADRÓN

CENSO

Subsistema INE

Mód

ulo

Tran

sacc

iona

l

Ayuntamiento

Ayuntamiento

Ayuntamiento

Consulado

Ayuntamiento

Consulado

Consulado

ConsuladoMA

ED

iput

ació

n

Subsistema Municipal

Subsistema Consular

Otras Administraciones

Sub

sist

ema

Ciu

dada

noSu

bsis

tem

a co

nsul

ta A

APP

.

CATASTRO

Esquema general del Sistema

En la descripción de las Tablas donde se integra toda la información que conforma el nuevo sistema y que venía recogida en la Base padronal del INE, Censo Electoral y Padrones Municipales de Habitantes básicamente, se ha intentado denominar a las cosas en primer lugar siempre de la misma manera, en segundo de forma inteligible y respetando la denominación oficializada por la legislación, la práctica administrativa y su divulgación en cada una de las ramas científicas en que puedan estar compendiadas, dada la heterogeneidad de los términos que aquí se manejan. Nos estamos refiriendo básicamente a la descripción de algunas características socio-culturales y de origen geográfico del conjunto de personas que residen en España, todo ello sustentado en una base territorial que es el conjunto de la Nación, y, además permite localizar y nombrar territorio situado fuera de ella, donde pueden residir ciudadanos españoles o de donde pueden ser originarias o nacionales personas que residen o han residido en España. A la Tabla resultante de la integración de los Padrones Municipales, la Base padronal del Ine y el Censo Electoral, la hemos denominado tabla de PERSONAS , por entender que como tanto podían provenir de Censo Electoral como de Base padronal del INE – o de ambos- es una denominación que puede englobarlos sin decantarse por una u otra base de datos.



Página 4 de 55

2. Descripción de la situación actual del sistema

El sistema actual de conservación y mantenimiento de los Padrones de Habitantes, Censo Electoral y Base padronal del INE es sobradamente conocido por todas las entidades que intervienen en el mismo, como es lógico. No obstante y dada la multiplicidad de entidades afectadas con competencias y responsabilidades diferentes, se ha creído conveniente intentar ofrecer una visión global del modelo vigente. En 1996, como consecuencia de la modificación de la Ley de Bases de Régimen Local 7/85, se da un gran paso adelante en el sistema de gestión de padrones, fruto de la voluntad de todos los agentes intervinientes que exterioriza la confianza en la fiabilidad de las bases de datos, al tiempo que se intensifica la puesta en común de la información entre Ayuntamientos e INE. Con la puesta en marcha del sistema de mantenimiento permanente de los padrones de habitantes a partir de la renovación de 1996, última que se efectúa, se van introduciendo por cada uno de los organismos encargados las altas, bajas y modificaciones referidas a los habitantes y sus datos territoriales, conforme se van produciendo. Y, se van comunicando al INE mensualmente, mediante los formatos de intercambio previamente establecidos. Del mismo modo, las Administraciones Públicas competentes, van suministrando al INE aquella información que poseen y que es de relevancia para el mantenimiento de los padrones y el censo (básicamente Registro Civil, Ministerio del Interior, siendo deseable la participación de más agentes; por ejemplo los responsables de emitir titulaciones académicas que acreditan el nivel de instrucción), información que –una vez centralizada por el INE- se remite a las administraciones territorialmente competentes. Dada la multiplicidad y heterogeneidad de agentes implicados en estos procesos, se puso de manifiesto la necesidad de una tarea de coordinación, que se encomendó al INE. La posibilidad de que existieran diferencias de criterio entre todas las organizaciones, dio lugar a la creación de un organismo que sirviera de enlace y en el que todos pudieran sentirse representados: el Consejo de Empadronamiento que emite informes vinculantes si deben resolverse discrepancias y propone los cambios legislativos que sean procedentes en materia padronal. El Censo Electoral continuó en esta fecha siendo competencia de la Oficina del Censo Electoral, organismo encuadrado dentro del INE. A partir de 1996 con la entrada en vigor del Padrón continuo, Censo Electoral procesa las variaciones a través de los ficheros que a su efecto remiten los Ayuntamientos. La estructura de la información que este modo de gestión ha producido es:

• 8.110 Padrones de Habitantes aproximadamente, que contienen tanto los datos recogidos en el Reglamento de Población como obligatorios para integrar el Padrón de Habitantes y el Censo Electoral, como aquéllos que cada municipio haya estimado conveniente añadir de entre los datos voluntarios.

• Una Base padronal del INE formada por la agregación de todos los padrones

municipales generados en la renovación de l996, al que se han ido añadiendo todas las variaciones enviadas por los Ayuntamientos y Oficinas Consulares y que, de acuerdo con los criterios de actuación del INE, hayan podido admitirse.

• Un Censo Electoral, mantenido por la Oficina del Censo Electoral en colaboración

con los Ayuntamientos y Oficinas Consulares, de manera físicamente independiente, aunque coordinada, al mantenimiento de la Base padronal del INE.



Página 5 de 55

• 8.110 sistemas de información territorial (correspondientes a los 8.110 padrones

de habitantes aproximadamente) donde se reflejan las divisiones territoriales de los municipios necesarias por una parte para permitir los procesos electorales y por otra, para situar en el territorio a cada uno de los habitantes.

• Un sistema de información territorial en el INE, gestionado coordinadamente con la

Base padronal del INE y Censo Electoral y que no permite su gestión al margen de la de la base de datos poblacional.

La experiencia acumulada en este período, la evolución de la tecnología y, sobre todo, la voluntad común de los agentes que participan en la gestión de censos y padrón ha aconsejado avanzar un paso más. Se pretende conseguir varios hitos:

• el mantenimiento permanente de cada uno de los Padrones Municipales de habitantes , aumentando la seguridad, ya que antes de llevar a cabo una variación puede examinarse la Base Integrada de Población (en el modo que autorice la Agencia de Protección de Datos), y simultáneamente, dicha variación, tendrá reflejo en la propia base y en las de otros Padrones Municipales que pudieran verse afectados, eliminándose los intercambios mensuales de información, sus reenvíos con las incidencias producidas, etc.

• La integración de la Base padronal del INE y de Censo Electoral lo que dará lugar a

que se asegure que los datos personales y territoriales de inscripción de las personas en ambos registros coincidan. Esta coincidencia lo será así mismo con los Padrones Municipales si la actualización se realiza simultáneamente.

Puntos débiles que se han detectado en el modelo actual de gestión:

• Actualmente se dispone de un callejero incompleto y no existe un directorio de viviendas ni una base cartográfica que permita su gestión integral.

• El comportamiento de la Oficina del Censo Electoral y el Ine-Padron con respecto a

la información intercambiada con los Ayuntamientos seguía criterios diferentes, pudiendo incluso en un caso no admitirse la información y en otro sí (debido, como es sabido, a las diferentes competencias que los dos organismo tienen).

• Falta de un identificador común y fiable para cada habitante y habitante/elector en

la Base padronal del INE, Censo Electoral y Oficinas Consulares.

• Terminología diferente en la utilización de algunos conceptos: local, vivienda, hueco…

• Asincronía en la actualización y producción de efectos de los mismos datos en

ficheros diferentes, que además genera un gran volumen de trabajo tanto en los municipios como en el INE.

• Movimientos en espera de confirmación por los distintos agentes.

• En los procesos electorales, donde por cierto la premura de los plazos es

importantísima, tienen lugar muchos intercambios de información que aún ahora se producen mediante envío masivo de documentación en formato papel, por medio de las oficinas de correos, que quizá podría llevarse a cabo por medios telemáticos.



Página 6 de 55

3. Proyecto

El sistema que se está analizando, pretende –tal como se especifica en el Pliego de condiciones- dar solución a los `puntos débiles’ que se han detectado al describir la situación actual y que son:

• Deficiencias en el sistema territorial existente que no está aislado de la gestión de las personas y no puede garantizar su coherencia interna.

• Las Bases Poblaciones no están suficientemente interrelacionadas: Base padronal

del INE, Censo Electoral, Padrones Municipales de Habitantes, Matrículas Consulares.

• Diferente incidencia de la base territorial en las bases poblacionales. • Falta de un Identificador de las personas que garantice la univocidad en todas las

Bases Poblacionales. • Diferencia de criterio a la hora de gestionar los ‘errores’ por parte de la Base

padronal del INE y de Censo Electoral, atribuido a las diferentes competencias que ostentan los organismos responsables de ambos.

• Asimetría en la organización y funcionamiento de los muchos agentes que

intervienen en la formación y mantenimiento de las bases poblaciones y las territoriales que les sirven de base.

• Asincronía entre la actualización de todas las bases de datos implicadas en los

cambios, debido a que los procesos de intercambio no pueden realizarse on-line y están pensados para garantizar cambios entre dos entes exclusivamente.

• Excesiva producción de intercambio de información en papel especialmente con

ocasión de elecciones. A estas cuestiones hay que añadir los requerimientos que formalmente ha expresado la Oficina del Censo Electoral, que se superponen a los anteriormente aludidos y que constan en el Pliego de condiciones: • Depuración previa a la carga de las discrepancias entre la Base padronal del INE y

Censo Electoral e incorporar los históricos de Censo Electoral y de la Base padronal de INE.

• Permitir actualizaciones a iniciativa de Censo Electoral relativas a acuerdos de la

Junta Electoral Central, reclamaciones, sentencias judiciales y certificaciones censales específicas en período electoral que impliquen actualizaciones en la base de datos y comunicaciones a los agentes.

• Gestión documental asociada a toda la tramitación. • Debe asegurarse que los datos de domicilio de los electores estén dentro del

callejero y del numerero para garantizar las asignaciones de las mesas. • La gestión de los datos del callejero y su referenciación territorial deberá quedar

garantizada, pudiendo beneficiarse de la gestión del sistema de información



Página 7 de 55

realizada por el sistema Geopista y deberá dar respuesta a las necesidades de las actualizaciones del seccionado requeridas por el Censo Electoral.

• Cambios masivos derivados de actuaciones de origen administrativo, fusiones y

particiones de secciones, variaciones de los datos de vías y pseudovías, renumeración de las vías….

Por su parte, para la gestión de la Base Integrada de Población se estima imprescindible que el sistema garantice:

• Que se pueda prestar conformidad, o no, a los movimientos de Padrón de

Habitantes efectuados por los Ayuntamientos, poniendo de manifiesto en caso negativo el por qué de la disconformidad.

• Permitir la conexión al mismo de herramientas y procesos de depuración de datos

externos o desarrollados por el INE y aprobados por el Consejo de Empadronamiento.

• Control de las altas por omisión, mediante una búsqueda exhaustiva del

habitante/elector. En el caso de que se encuentre, el alta iniciada por omisión, se transformará en alta por cambio de residencia.

• Si se tratase de altas de oficio, debe acreditarse que se ha tramitado expediente y

se ha solicitado Informe al Consejo de Empadronamiento cuando proceda. • En cuanto a las bajas por inclusión indebida, se seguirán los procedimientos que

figuran en el Pliego del Proyecto. • Recepción de información suministrada por otras AAPP: Registro Civil, Ministerio

del Interior, Mº de Justicia, Mº de Educación etc. . A partir de esta información, el INE funciona como un usuario más del sistema, formalizando los movimientos correspondientes, que el Sistema comunicará a los Ayuntamientos afectados.

• Gestión de discrepancias: creación de un buzón en el subsistema que corresponda

para recibir las comunicaciones que envíen los Ayuntamientos en respuesta a las discrepancias que les afecten.

• Preaviso de extranjeros con permiso de residencia temporal.

• Módulo de cesión de datos a otras Administraciones Públicas en los casos que sea

procedente.

• Listados, estadísticas, etc para INE, Ayuntamientos, y otras Administraciones Públicas.

A estos requerimientos, la aplicación ofrece soluciones del modo que queda detallado al analizar cada uno de los módulos de la misma y ahora solo se enunciarán brevemente:

• Deficiencias del sistema territorial actual, esta cuestión se ha puesto de manifiesto por todas las partes implicadas en el proyecto (Base padronal del INE, Censo Electoral y Ayuntamientos) y por ello ha sido objeto de amplio debate y multitud de reuniones de trabajo que, en primera instancia, lograron consensuar un documento de mínimos (incluido íntegramente en este documento) que refleja un procedimiento de gestión del territorio lo suficientemente versátil como para



Página 8 de 55

permitir que, dada la heterogeneidad de los entes encargados de la gestión del mismo (Ayuntamientos), ayudará a dar un paso adelante a aquéllos que aún no disponían de herramientas adecuadas para hacerlo; sin que por otra parte, implique que aquellos municipios que realizan una satisfactoria gestión corporativa del territorio deban substituirla por la descrita en el documento de consenso de gestión de territorio, sino que bien al contrario, los productos que deban entregar al INE para una correcta referenciación geográfica de los habitantes y la gestión electoral serán un resultado de su propia gestión.

• Existencia de bases poblacionales sin interrelación. Entendemos que ésta era

una de las motivaciones principales de estudiar un nuevo aplicativo. A partir de su implantación, la Base Integrada de Población, en la medida que se permita su actualización en paralelo con las bases municipales, al mismo tiempo que los agentes municipales pueden realizar previamente la consulta de la base nacional, garantizará la coherencia entre ambas. Sin perjuicio, naturalmente, de los procesos de depuración de información de la Base Integrada de Población. La interrelación del censo electoral con la Base Integrada de Población, también producirá efectos beneficiosos ya que resultará imposible que la misma persona pueda tener características personales y/o territoriales diferentes en una u otra base de datos, al ser ésta común. Y, por fin, se realiza en la aplicación un módulo para la integración en la Base Integrada de Población del PERE.

• Falta de un identificador común para las personas en las diferentes bases

de datos. A priori, era complicado que bases de datos gestionadas por organismos diferentes dispusieran de un identificador común a todas. Muestra de que era una cuestión que a todas las partes implicadas preocupaba, es que cada una de ellas, proporcionó a su propia base de datos de un identificador. Así, la Base padronal del INE estableció el NIDEN, pero no hay que olvidar que frente a los muchos años de existencia de los Padrones Municipales y del Censo Electoral, ésta comienza a formarse en 1996; y, que el NIDEN era una matrícula de uso interno, que no estaba contenido en los formatos de intercambio de información con el resto de administraciones implicadas, que por tanto no lo conocían. Censo electoral por su parte, asigna también una matrícula a cada una de las personas, que sí utiliza en los formatos de intercambio de información con los Ayuntamientos, el NIE. Su desventaja como identificador de todas las personas contenidas en la Base Integrada de Población frente al NIDEN es evidentísima, el universo de electores es sólo una parte de los habitantes. Los Ayuntamientos, por su parte, también intentaron establecer un identificador único, y así lo hicieron: el NIA, que permite reconstruir todos los movimientos históricos de las personas que alguna vez han estado empadronadas en sus municipios. Pero, su ineficacia como identificador común cae por su peso, ya que lo es dentro de cada municipio, por lo tanto no es común a todo el territorio. Y por fin, el PERE que utiliza también el NIE. Fruto del consenso entre las partes implicadas, se ha estimado que debe optarse por la utilización del NIDEN como identificador en la tabla de Personas –por su universalidad- y facilitar esta información a los Ayuntamientos y Consulados, que siempre la utilizarán cuando se relacionen con esta base de datos, al tiempo que mantendrán su identificador propio para mantener la coherencia de sus bases de datos y no romper la cadena de históricos.

• Asincronía entre la actualización de todas las bases de datos implicadas en

los cambios: Éste es sin duda alguna uno de los temas clave en el nuevo modelo de gestión. Se consiguió pasar en 1996 a la gestión continua de los padrones municipales, padrones que al tiempo recogen la información necesaria para la elaboración del Censo Electoral y de la Base padronal del INE, mientras que la actualización de estas bases, que se lleva a cabo mensualmente ( pero en realidad



Página 9 de 55

con la información del mes anterior al momento en que se está llevando a cabo la misma) al intervenir tantos agentes, que no tienen a la vista la base de datos que están intentando modificar, provoca una inmensa cantidad de reparos, solicitudes de conformidad, generación de errores, etc. que complican enormemente la situación, al mismo tiempo que impiden que el sistema durante todo ese tiempo pueda estar dedicado a tareas de depuración de información. A partir del momento de la implantación del nuevo sistema, la modificación de las bases de datos municipales y nacional (tanto la territorial como la que se refiere a las personas) se realizará simultáneamente, con lo que las ventajas que el mantenimiento continuo del padrón de habitantes ha proporcionado a 8110 Ayuntamientos, también se producirán en la Base Integrada de Población.

• Depuración previa a la carga de las discrepancias entre la Base padronal

del INE y Censo Electoral, incorporar históricos de censo, y posibilitar la continuidad de la generación de los mismos: El proceso de carga de datos se describirá en el apartado “Construcción del Sistema Inicial”. Por lo que ahora se hará una breve síntesis: las discrepancias que se encuentren en el cruce de la Base padronal del INE con el Censo Electoral se cruzarán con la información existente en los Padrones Municipales correspondientes por parte del INE. Se enviará a cada Ayuntamiento aquellas discrepancias no resueltas con este contraste. La aplicación contempla igualmente, la conservación de los registros históricos existentes y la formación de nuevos, tal como se contempla en el apartado “Gestión de Históricos”. La cuestión relativa al método actual de gestión de cierres de Censo Electoral, es decir, mantenimiento en la tabla de electores de la situación en la misma en un proceso electoral, se estudiará en profundidad en el momento de analizar el subsistema de Censo Electoral, y se consensuará su solución definitiva.

• Permitir actualizaciones a iniciativa de Censo Electoral relativas a

acuerdos de la Junta Electoral Central, reclamaciones, sentencias judiciales y certificaciones censales específicas en período electoral que impliquen actualizaciones en la base de datos y comunicaciones a los agentes: El sistema contempla a la Oficina del Censo Electoral como un gestor más de la base de datos, con la salvedad de que cuando se produzca una modificación en la Base Integrada de Población que implique algún cambio en las bases municipales, el sistema se encargará de llevar a cabo los traspasos de información necesarios para llevar a cabo las modificaciones que sean precisas. El mantenimiento del Censo electoral en periodos electorales será objeto de análisis en el susbsistema INE-Censo Electoral.

• Excesiva producción de intercambio de información en papel y envío postal

de la misma con ocasión básicamente de los procesos electorales. Para este sistema se propone usar mecanismos telemáticos encriptados de envío de información entre los distintos subsistemas.

• Cambios masivos en los datos territoriales de las personas, provocados por

cambios en la información territorial, cambio del seccionado, del nombre de la calle, de entidades territoriales….. El sistema territorial descrito en el correspondiente subsistema garantiza que, al llevar incorporado el registro de personas el código de vivienda, las tablas del sistema territorial devolverán siempre la información vigente en cada momento, por lo que no será preciso efectuar cambios masivos de información territorial en las tablas de personas cuando se produzcan modificaciones.



Página 10 de 55

• Gestión documental asociada a toda la tramitación: La herramienta de Gestión documental TIDOCS, de producción propia, garantiza que cualquier documento generado por el sistema o importado pueda ser incorporado al mismo, asociándose al expediente correspondiente.

• Que se pueda prestar conformidad a los movimientos de la Base Integrada

de Población efectuados por los Ayuntamientos: el sistema solo permitirá movimientos en la base, cuando éstos sean conformes con los protocolos que se establezcan en la gestión de altas, bajas y modificaciones. Si se rechazara la acción a realizar en la base nacional, el sistema enviará automáticamente un mensaje al organismo afectado notificando la discrepancia observada. El Sistema Transaccional garantiza la integridad de las comunicaciones.

• Control de las altas por omisión: si desde un Ayuntamiento se inicia un alta por

omisión el sistema buscará el habitante en toda la base de datos, y si lo encuentra, ofrecerá al Ayuntamiento en cuestión la posibilidad de continuar el trámite como un alta por cambio de residencia.

• Bajas por inclusión indebida: el sistema garantizará que se ha solicitado

informe del Consejo de Empadronamiento cuando sea necesario.

• Incorporación de la información suministrada por el Registro Civil y Ministerio del Interior y comunicación a los subsistemas afectados..

• Gestión de discrepancias: El sistema contará con una base de datos de

discrepancias en cada uno de los subsistemas, identificando claramente el motivo de la misma y el subsistema afectado.

• Gestión de duplicados: El sistema contará con una base de datos de Duplicados

en cada uno de los subsistemas, permitiendo relaciones de n a 1. • Necesidad de incorporar un control sobre duplicados falsos, personas que

tienen las mismas características identificativas pero que son distintas, garantizando que no se pueden incluir en procesos posteriores de tratamiento de duplicados.

• Incorporación de resoluciones del INE con el informe del Consejo de

Empadronamiento.

• Generación de propuestas de variación resultantes de operaciones de control de los Padrones sobre el terreno.

• Generación de los preavisos de caducidad para los Extranjeros No

Comunitarios Sin Autorización de Residencia Permanente (ENCSARP)



Página 11 de 55

4. Requisitos comunes de los módulos

1. Gestión de históricos El sistema de gestión de históricos incluido en el proyecto AVANZA-PADRÓN contempla que todas las tablas del sistema en las que sea necesaria información a una fecha determinada, dispongan de una tabla histórica asociada a la misma y gestionada con una herramienta común para todas ellas. En la tabla histórica se almacenarán todos los movimientos ocurridos para cada registro, mientras que en la tabla maestra dispondremos exclusivamente de los datos vigentes a fecha de hoy. Para ello, se establecen los siguientes parámetros que serán usados a lo largo del análisis del sistema:

FECHA DE GRABACIÓN: Fecha del sistema, intalterable, e indica la fecha en la que se introducen los datos en el mismo. FECHA DE VARIACIÓN: Fecha de efectos administrativos de la variación (también usado como fecha de documento). FECHA FIN VALIDEZ: Fecha en la que toda la información o parte de ella del registro al que se refiere, deja de tener validez porque existe otra variación que modifica el registro.

La información correspondiente a estas tres variables se encuentra dispuesta en la estructura de datos de control común a todas las tablas del sistema especificado en el capítulo “Datos de control” de este mismo documento.

Todas las tablas que tengan Histórico asociado, tendrán la siguiente estructura:

1. Identificador del registro de la tabla Histórica 2. Copia íntegra del registro de referencia. Se contemplará siempre que el

orden, distribución y tipología de las variables contenidas en este grupo sea el mismo entre la tabla histórico y la actual.

3. Fecha de Fin de validez del registro, que corresponde a la fecha de inicio

de validez o fecha de variación del registro posterior y se encuentra localizada en los datos de control del registro de referencia.

Esta visión de las tablas de histórico y actual del sistema permite que se disponga de una visión total de todas las variaciones existentes en la misma. Todas las variaciones efectuadas en tablas que tengan histórico asociado, realizadas cronológicamente, insertaran los datos previos a la modificación en la tabla de histórico correspondiente, modificando la información existente en el registro de referencia. Todas las variaciones realizadas en las tablas origen tendrán pues su reflejo en la tabla de histórico.



Página 12 de 55

El funcionamiento de las tablas de Histórico permitirá que se introduzcan en ellas, variaciones anteriores a otras existentes, para garantizar el reflejo de movimientos producidos anteriormente a otros ya grabados. Es decir, el sistema garantiza que modificaciones de registros con fecha de documento anterior a una existente, pueda insertarse en la tabla de histórico realizando las modificaciones necesarias para garantizar la coherencia de la cadena en la que se encuentra. En el caso de aquellas tablas en las que sea necesario modificar el contenido de los registros históricos por inserción de datos anteriores, se prevé la creación de una tabla de Notario que refleje la situación anterior a la modificación del mismo. Este sistema de tablas está pensado de forma inicial para garantizar la coherencia de la tabla de personas pudiendo modificar los datos históricos de los mismos cuando sea necesario, controlando las modificaciones efectuadas en todo momento. El uso de este mecanismo es necesario para garantizar que la recuperación de la información para una fecha de variación determinada, filtrando el acceso a la misma por fecha de grabación, dé siempre el mismo resultado.



Página 13 de 55

2. Gestión de identificadores Todos los registros de todas las tablas disponen de un identificador único. Este identificador, cumple los siguientes requisitos:

• Para cada tabla, el nombre del identificador es <nombre corto de tabla>+‘_ID’ • El identificador es una variable numérica del mismo tamaño para todas las

tablas, de asignación automática, que identifica físicamente el registro, y no se repite en la tabla.

Aunque todas las tablas dispongan de un identificador único interno, existen algunas excepciones relacionados con su uso que se relacionan a continuación:

La tabla de Personas, dispone de un identificador adicional que identifica la persona, de forma que todos los registros tanto de la tabla actual como de la tabla histórica, tienen el mismo identificador. Este identificador, como se explica en el capítulo correspondiente, es el NIDEN, actualmente usado por la Base padronal del INE y que se va a hacer extensivo a todos los registros de la nueva Base Integrada de Población. Las tablas de países, provincias y municipios, disponen de unos códigos conceptuales sobradamente conocidos por todos, que persisten en el tiempo, y que están muy identificados con su significado. Debido a ello, se ha considerado oportuno que la relación con dichas tablas pueda ser tanto por código como por identificador puesto que ambas relaciones pueden ser correctas y garantizan la comprensión de los datos en el momento de la visualización. Las tablas de vías, numerero y de viviendas-locales, tienen también la estructura descrita: identificador y resto de atributos. El enlace con la tabla de personas se llevará a cabo mediante la inserción en esta tabla del identificador de las correspondientes tablas territoriales. Si se produce alguna variación en los datos que conforman estas tablas territoriales, se guardarán en el histórico de las mismas, por lo que siempre será posible, mediante la consulta a las tablas históricas, conocer sus datos a una fecha determinada.



Página 14 de 55

3. Datos de control Todas las tablas del sistema dispondrán de los siguientes datos de control:

• FECHA DE VARIACIÓN: Fecha de efectos administrativos de la variación.

• FECHA DE GRABACIÓN: Fecha del sistema en la que se ha producido la grabación de los datos. Campo de asignación automática.

• FECHA FIN VALIDEZ: Fecha en la que toda la información o parte de ella del

registro al que se refiere, deja de tener validez porque existe otra variación que modifica el registro.

• TIPO DE VARIACIÓN: Tipo de variación realizada sobre el registro en cuestión. Es un campo de asignación automática y sus valores pueden ser: “A” , “M” o “B” para Altas, Modificaciones o bajas.

• CAUSA DE VARIACIÓN: Este Campo, añade información al anterior, precisando

de los diferentes tipos asignados a la variación a cuál se está haciendo referencia.

• MOTIVO DE GRABACIÓN: Texto adicional que contempla aquellos valores que el usuario –si es procedente- añade para complementar la grabación de los datos

• ENTIDAD: Identificacior de la entidad que efectúa la variación

• USUARIO: Identificador del usuario que ha realizado la variación

• EXPEDIENTE: Identificador del expediente asociado a la variación producida en el

registro.



Página 15 de 55

4. Gestión de documentos El sistema usa la herramienta TiDOCS para la gestión documental integrada en el mismo, tal como se hizo constar en la oferta presentada. La organización de la documentación que plantea esta herramienta, permite que el sistema relaciona, para cada registro de cada tabla del mismo, todos los documentos asociados que se necesiten en formato digital.



Página 16 de 55

5. Idioma

El sistema es multiidioma a nivel del aplicativo, y permite la introducción de los términos en el idioma que cada una de las administraciones haya decidido. Es decir, la aplicación en los subsistemas municipales soporta la posibilidad de mostrarse en el idioma elegido por la administración a la que pertenece el operador dentro de los posibles idiomas oficiales del Estado y de la Comunidad autónoma a la que pertenezcan. Por lo que respecta a datos, si estos hacen referencia al territorio, su identificación corresponderá al organismo competente en cada caso. Si nos referimos a datos personales, estos irán acompañados del correspondiente documento que acredite como deben escribirse.



Página 17 de 55

6. Terminología usada La terminología usada debe garantizar una correcta programación de tareas, y una comprensión y organización del sistema en base a diferencias lógicas y/o físicas de los elementos que lo componen. De esta forma, con el sistema de nomenclatura propuesto, se establecen los mecanismos para organizar la información tal como se expone a continuación. Actualmente, se está trabajando en la construcción de un diccionario de datos que permitirá la navegación entre las distintas tablas del sistema, identificando las relaciones entre las mismas y la propia estructura. Las tablas se han organizado en grupos lógicos y/o físicos de las mismas, respondiendo a la propia estructura del sistema, donde cada una de las posibles agrupaciones de tablas, se identifica con una abreviatura de 3 caracteres. Actualmente, y siguiendo las pautas de definición del documento actual, las abreviaturas usadas son: TRR Para tablas relacionadas con Territorio BIP Para tablas relacionadas con la gestión de Personas STC Para tablas relacionadas con el Sistema Transaccional Todas las tablas del sistema disponen de un nombre de tabla y un nombre corto de la misma, usado en la terminología de enumeración de campos para identificar a cada uno de ellos. Las tablas de histórico tienen el mismo nombre que las tablas de las cuales dependen, con una ‘H’ previa identificativa de su condición de Histórico. Los nombres de columnas de una tabla, siguen la nomenclatura siguiente: TTTTTT_CCCCCCCC especificando el nombre corto de la tabla y el nombre de la columna. Las columnas comunes a distintas tablas, como los identificadores relacionados, tendrán el mismo nombre específico de columna en todas las tablas, añadiendo en las tablas con clave ajena, la abreviatura del nombre de tabla correspondiente, respetando el criterio anterior, de la forma TABLA_COLUMNA, TABLA_TABLA_COLUMNA



Página 18 de 55

5. Módulos funcionales 1. Territorio La geo-referenciación permitirá la ubicación concreta en el territorio de cada habitante, primero en la Provincia, descendiendo al Municipio y dentro de éste a la Vía correspondiente; en un Edificio a través del Numerero, e incluso en una Vivienda, lo que permitirá su relación con la base de datos Catastral a través del sistema Geopista así como la agregación de habitantes en cada una de las porciones de territorio que se han mencionado. Obviamente, la información se contendrá obligatoriamente en sistemas alfanuméricos y opcionalmente en una primera fase en sistemas gráficos que pueden o no estar digitalizados, cuestión esta que se irá detallando a medida que avance el análisis del sistema. Dicha geo-referenciación se llevará a cabo según el esquema siguiente, que se describirá a continuación

PROVINCIA

MUNICIPIO

CALLEJERO

CATASTRO

NUMERERO

VIVIENDAS/LOCALES

CENSO /HABITANTES

Unidades Poblacionales

Secciones electorales

GeoPista

Otros sistemas

Estructura del Territorio – Sistema de Información Geográfica

PROVINCIAS



Página 19 de 55

La tabla de Provincias contiene la información correspondiente al código y la descripción de todas y cada una de ellas. Este sistema permite la agrupación de provincias por comunidades autónomas. MUNICIPIOS Dentro de cada Provincia contiene el código y descripción de cada uno de ellos. Este sistema permite la agrupación de Municipios por Comarcas u otras divisiones territoriales que pudieran conformarse por agrupación de Municipios. CALLEJERO Este sistema codifica las Vías i/o Pseudovías dentro del Municipio. La existencia de al menos un elemento de callejero (Vía o PseudoVía) es un requisito indispensable para el correcto funcionamiento del sistema de Georreferenciación. La codificación de las calles de un municipio permite el enlace de las mismas y de los elementos territoriales asociados a ellas con Geopista, Catastro y otros sistemas de información. El nexo de unión entre ambas realidades debe ser un sistema de equivalencias de códigos de calle entre INE, Catastro y Ayuntamiento (cuando especificamos calle significa código de calle y nombre). En función del grado de integración de la información territorial de los Municipios, ésta será más fácil o más difícil de construir y de mantener. Las Pseudovías son vías ficticias que sustituyen la vía, cuando esta no existe. A efectos prácticos se tratarán como las vías. No se contemplan en este sistema aquellas Pseudovías que complementan la dirección, ya que este tipo de información reside en la estructura de Viviendas como texto no estructurado. Los Municipios en los que actualmente no exista vía alguna o bien haya parcelas de territorio sin especificación de la misma, deberán crear Pseudovías para garantizar el correcto funcionamiento del sistema. El caso especial de los Municipios en los que el territorio se define mediante las Unidades Poblacionales, se crearán las Pseudovías a partir de la información contenida en la Unidad Poblacional. La creación de la Tabla de Callejero, se realizará a partir de la información existente en el callejero actual del INE, de los Ayuntamientos y de la Dirección General de Catastro, estableciendo las correspondientes equivalencias entre las tres realidades territoriales. Esta tabla puede ser proporcionada por los Ayuntamientos, y en su defecto por la base de información existente en el Estudio Demográfico Longitudinal (si está disponible en su momento, o en su defecto, de los censos de población 2001) por Geopista, completándose la información necesaria en su caso por el propio sistema Avanza Local-Padrón. Los Ayuntamientos son las administraciones autorizadas y responsables de garantizar la integridad del callejero de su Municipio. A partir de estos callejeros se mantendrá esta dualidad de códigos (código Ayuntamiento/INE y Código Catastro) en la nueva base de datos, informando cuando se modifique y a través de los canales que se establezcan a Dirección General de Catastro. Se especifica código Ayuntamiento/INE para dejar constancia de que el INE asume como propio en este proyecto el código de vía asignado por los Ayuntamientos.



Página 20 de 55

NUMERERO

La localización del Edificio/Portal, se produce mediante la asignación del Número de Policía. A cada número de cada calle, se añade como atributo el resto de Divisiones Territoriales donde este número esté ubicado: Distrito, Sección, , Unidad Poblacional, Distrito Postal.

La información específica de la tabla de Numerero, es la que sigue:

• Identificador de Numerero • Identificador del registro existente en el Sistema de Callejero • Número • Calificador • Kilómetro • Hectómetro • Bloque • Portal • Escalera • Distrito • Sección • Código Postal • Unidad de Población • Referencia Catastral de la parcela • Coordenadas geográficas X,Y

La inclusión de la Referencia Catastral en el Numerero se consigue pues, a partir de las equivalencias establecidas y la posible comunicación con Catastro a través de alguno de los sistemas aludidos.

Debido a las múltiples interpretaciones por parte de todas las administraciones de los términos escalera, bloque, portal e incluso calificador, se ha optado por mantener a todas ellas en la estructura del Numerero y garantizar que cualquier interpretación del territorio cabe en ellas, ya que la posible normalización del mismo es muy compleja y no añade precisión a la concepción que se está planteando de Gestión del Territorio. La estructura de la información planteada, permite establecer al nivel necesario para cada administración las agregaciones y desagregaciones desde cada uno de los ámbitos territoriales descritos. VIVIENDAS/LOCALES Se ha optado por el nombre Viviendas/locales para identificar el lugar donde pueden vivir los habitantes, y que aglutina términos como: ‘Hueco’, ‘vivienda’, ‘local’, ‘sublocal’, ’clase de local’. La vivienda/local añade la información correspondiente a Planta, Puerta y otra información descrita a continuación para garantizar la correcta identificación de la misma. La información específica de la tabla de Viviendas es la que sigue:



Página 21 de 55

• Identificador de vivienda • Identificador del registro existente en el Numerero • Planta • Puerta • Complemento de texto para la dirección. Identifica características especiales y

complementarias de la dirección de la Vivienda. • Tipo de vivienda/local • Referencia Catastral

La referencia Catastral incluida en esta tabla se puede localizar del mismo modo que se ha descrito para la información contenida en el numerero. El sistema propuesto trata la gestión del Territorio de forma independiente de la gestión de los Habitantes/Electores. Esta situación permite informar independientemente de las variaciones territoriales de las variaciones de habitantes. CREACIÓN DE LAS TABLAS DE NUMERERO Y VIVIENDAS La información residente en las tablas de Numerero y Viviendas, se obtiene a partir de la información existente de las direcciones en las que se encuentran empadronados los habitantes y/o figuren en el Censo Electoral. Esta dirección, deberá disponer del enlace correspondiente en el Callejero, es decir, no existirá ningún registro de Numerero que no disponga de un enlace con Callejero. La tabla de Viviendas dispondrá de la información correspondiente a todas las Viviendas en las que haya algún habitante empadronado. Si el municipio ha establecido las equivalencias a nivel de callejero con el Callejero de Catastro, existe la posibilidad de cargar la información actual de todas las viviendas, vacías o no existentes en Catastro. Para evitar la posibilidad de que al incorporar los datos de cada registro de la Base Padronal del INE y Censo Electoral para formar la dirección, pudiera suceder que se generase más de un registro de vivienda para personas que tienen asignada la misma Hoja Padronal, se seguirá el criterio de crear un único registro de vivienda para todas las personas que están en la misma Hoja. Los datos de la dirección –comunes a todas las personas- serán los de aquella persona que los tenga más completos. El sistema descrito se refiere al momento de la carga inicial de datos. En el mantenimiento posterior de la Base Integrada de Población, se asegurará que no se cree más de un registro de vivienda para todas las personas que tengan asignada la misma Hoja padronal. La estructura de territorio que se ha descrito tiene por objeto la ubicación geográfica de las personas, identificando la Administración territorial competente para empadronarlos –o no- y en qué lugar deben ser inscritos para ejercer el sufragio activo. Esta localización, dado que generalmente las personas residen en viviendas, u otros tipos de locales, podrá verificar esto y pretende conseguir enlazar con el Catastro, ya que éste es el más completo registro de locales y viviendas que existe. El enlace entre ambas bases de datos, nos proporcionará una radiografía completa del reparto de la población en las unidades urbanas, pudiendo conocerse densidades, parque inmobiliario ocupado, y toda la información que se desee mediante la explotación de las variables contenidas en las mismas.



Página 22 de 55

Para conseguir el enlace mencionado, se partirá del Numerero, completando la información en ellos contenida con la que ofrezcan los registros de viviendas (de padrón de habitantes/censo electoral) más los de dirección completa de las unidades urbanas del catastro. Ello será fácil en principio en aquellos Ayuntamientos que hayan construido un sistema de información geográfica, que a estos datos podrán añadir la referencia catastral de las unidades urbanas a cada registro de vivienda. Para los Ayuntamientos que aún no tengan construido un sistema de información geográfico que cumpla los requisitos señalados, la solución que ofrece el sistema, es la utilización de Geopista, sistema abierto a todos los entes territoriales que quieran utilizarlo y que vendría a producir los mismos resultados. Para servir de apoyo al Censo Electoral, contaremos con las tablas de circunscripción electoral, que serán los Terçons, EATIMS u otro tipo de entidades inferiores al Municipio en función del tipo de elecciones de que se trate. Si bien inicialmente, el intercambio de información territorial entre el INE y los Ayuntamientos se ha diseñado mediante la implementación de tablas alfanuméricas, nada impide añadir al sistema un módulo mantenimiento e intercambio de esta información sustentado en cartografía digitalizada. Todos los movimientos y actualizaciones ejecutados sobre el sistema de Territorio, serán guiados por expedientes, descritos en el capítulo relacionado con la descripción del Módulo transaccional.



Página 23 de 55

2. Personas En la Base Integrada de Población se incorporarán los registros de la Base padronal del INE y del Censo Electoral. En tanto el MAEC no se incorpore al Sistema, la incorporación del Padrón de Españoles Residentes en el Extranjero (PERE), constituido por el Censo de Españoles Residentes Ausentes (CERA) más los menores residentes ausentes, se realizará mediante la conversión de los formatos de los registros de variaciones que proceden del MAEEC en tanto no se adhiera al Sistema. En la base de datos poblacional se integrarán la base padronal del INE, el Censo Electoral y el PERE. El identificador de la tabla resultante será el NIDEN de conformidad con lo expuesto en el momento de análisis de esta cuestión. Debe añadirse toda la información que con carácter de mínima recoge el art. 57 del vigente Reglamento de Población, y Demarcación Territorial:

a) Nombre y apellidos.- En el caso de personas españolas se utilizará el nombre y dos apellidos., mientras que en el caso de extranjeros regirá la ley personal, informándose cuando sea preciso de la no obligatoriedad de cumplimentación del segundo apellido. Además se añadirá un campo informativo del apellido de soltera/casada de las personas que lo pierdan/adopten

b) Sexo.- se seguirá la codificación actual (1 para varones y 6 para mujeres).

c) Domicilio habitual: esta variable recogerá la codificación de vivienda empleada en

el sistema territorial que se ha descrito: código de provincia, de municipio, de vía, número postal, calificador, escalera, planta puerta. Ello permitirá enlazar con todas las entidades territoriales asociadas-

d) Nacionalidad: información que se implementará mediante la asociación a la tabla

de países, de la nacionalidad derivada de cada uno de ellos.

e) Lugar y fecha de nacimiento: el lugar se informará con el código de municipio, provincia y país respectivo. Si el nacimiento hubiera tenido lugar en un país diferente de España, el código de país deberá cumplimentarse en todo caso, mientras que el resto de la información será descriptiva, sin normalizarse el modo de entrada de la misma. La fecha de nacimiento se expresará con el día, mes y año en que hubiera ocurrido.

f) número de documento nacional de identidad o, tratándose de extranjeros, del

documento que lo sustituya. Se informará en primer lugar del tipo de documento a que se hace referencia (DNI, pasaporte, tarjeta de residencia, inscripción al Registro Civil o bien ningún documento).

g) Certificado o título escolar o académico que se posea, de acuerdo con la

codificación establecida. Además de esta información se añadirá:

• NIA, código de identificación municipal/ Número de Registro de Matrícula Consular, codificación utilizada en los consulados.



Página 24 de 55

• NIE código de identificación de censo electoral que permitirá la conexión con los históricos generados por éste.

• Número de Hoja Padronal. Número de Hoja Padronal de la persona dentro de la

vivienda, que garantiza la compatibilidad con el sistema anterior. • Fecha de variación.

• Identificación de la inscripción del registro civil.

• Representante. Debe existir la posibilidad de identificar los representantes de las

personas, caso que tuvieran. Todos los sistemas implicados en la Gestión de Personas, comunicarán las actualizaciones de las mismas a través del Módulo Transaccional.

El sistema utilizará todos los canales de entrada de información que puedan proporcionar criterios para incorporar registros a la tabla, dar de baja en la misma o bien modificar los datos existentes. Incorporación de defunciones: Se llevará a cabo desde la información de los registros civiles, generándose la baja por defunción correspondiente. Incorporación y control de nacimientos .- Permitirá la incorporación de los nacimientos a los padrones municipales y a la Base Integrada de Población así como el control de los mismos. Todos los movimientos y actualizaciones ejecutados sobre el sistema de Personas, serán guiados por expedientes, descritos en el capítulo relacionado con la descripción del Módulo transaccional. DUPLICADOS

La gestión de duplicados se analizará en los Subsistemas INE y Municipal. No obstante se hace a continuación un esbozo de la misma. De manera automática, en la tabla que al efecto se cree, se irán incorporando aquellos registros en los que sean coincidentes, al menos, los siguientes datos:

o DNI o documento identificativo o Nombre (depurado según los filtros actualmente empleados por el INE) o Lugar y fecha de nacimiento.

Esta tabla permitirá incorporar tantos registros como sea necesario , si presentan las características señaladas. El subsistema que detecte registros duplicados, iniciará el expediente correspondiente a través del Módulo Transaccional que será el que –tal como se ha contado-, distribuirá la ejecución de las acciones necesarias en los subsistemas correspondientes.



Página 25 de 55

Se entenderá que una vez efectuada la comparación entre ellos, persistirá únicamente el registro cuya fecha de variación sea más alta, o el que se decida en el momento de la unificación.

A la tabla se podrán incorporar sucesivamente los registros que no se detecten por procedimientos automatizados.



Página 26 de 55

3. Identificación y localización de Personas

Si los Ayuntamientos en el momento de comunicar sus movimientos padronales al INE adjuntan el identificador de la persona asociada al movimiento, se agilizará la gestión de expedientes relacionados a éstos puesto que la localización de la persona en los diferentes entes será mucho más rápida y fiable que si se realizara con el sistema tradicional, es decir, mediante el resto de datos de identificación de la persona en cuestión.

Es por todo ello que el SubSistema INE proporciona un mecanismo que los Ayuntamientos puedan utilizar para consultar la Base Integrada de Población a efectos de identificación de la persona solicitada a partir de los datos de identificación informados por éstos. La propia identificación de la persona, llevará pareja la obtención del NIDEN para el Ayuntamiento en el caso que dicha persona no sea del municipio en cuestión.

Este mecanismo no formará parte del Sistema Transaccional, sino que es una herramienta previa a la notificación del movimiento al INE a través del Sistema Transaccional.

Los Ayuntamientos, tanto los que utilizan el sistema AVANZ@ como los que no, deberán antes de notificar los movimientos padronales al INE, realizar una consulta a la Base Integrada de Población, para obtener el NIDEN de la persona en el caso que no dispongan de información de ella (por ejemplo en las altas por cambio de residencia).

Para ello el Ayuntamiento consultará en la Base Integrada de Población a partir de la siguiente información de la persona:

• Nombre • Apellidos • Documento de identidad • Los menores de edad notificarán en este apartado los datos de Registro Civil si constan o

el municipio de nacimiento o nombre de los padres (en el caso de menores extranjeros no nacidos en España sin documentación).

• Fecha de nacimiento

A partir de esta información, se realizará una búsqueda de la persona en la Base Integrada de Población, el resultado de la cual será:

Persona no encontrada. Se notificará al Ayuntamiento la no localización de la persona en Base Integrada de Población con los criterios solicitados y será este último quien decidirá qué hacer en este caso:

1. Validar de nuevo los datos de identificación de la persona aprovechando que tiene a ésta presente durante el desarrollo del proceso y volver a consultar con los nuevos datos de identificación de ésta en el caso de que difirieran de los originales.

2. Decidir inscribirla por omisión (habitante español) o bien por alta de extranjero

procedente del extranjero.

3. Es una inscripción por nacimiento y el INE todavía no la ha introducida en la base provinente de Registro Civil, por lo que se envía directamente el movimiento al INE.

En los casos 2 y 3, cuando el Ayuntamiento envía una propuesta de Alta sin NIDEN asociado (es decir, sin identificar a la persona) el Subsistema INE deberá de determinar el NIDEN de la persona y notificarlo posteriormente al Ayuntamiento a través del expediente correspondiente. Entendemos por determinar la tarea que debe ejecutar el INE para crear un



Página 27 de 55

NIDEN si se considera que la persona no existe en la Base Integrada de Población, o localizarla en el caso que exista y se pueda encontrar por otros medios. Persona encontrada. La búsqueda en la Base Integrada de población devuelve las personas que ha encontrado con los datos de identificación suministrados por el Ayuntamiento y será este último quién decidirá a cual de las personas posibles (en el caso de que haya más de una persona encontrada) asigna el movimiento. La información suministrada a los Ayuntamientos de las personas encontradas en la base es:

• Nombre • Apellidos • Documento de identidad • Fecha de nacimiento • Municipio de nacimiento SOLO en el caso de menores de edad sin documento

de identificación.

Es importante tener en cuenta que tanto la posibilidad de consulta de la Base Integrada de Población como la propia identificación a partir del retorno de los resultados de la misma, está, a día de hoy, sujeta a una consulta que se ha realizado desde el INE a la Agencia de Protección de datos para determinar la viabilidad de la misma.



Página 28 de 55

4. Exportaciones de datos para Censo Electoral - Cierres

Uno de los temas que debe resolver el proyecto es el de garantizar que se suministra la información necesaria para llevar a cabo los procedimientos de gestión de la Oficina de Censo Electoral con las herramientas que dispone actualmente y que no son objeto del proyecto. El sistema debe permitir al usuario la exportación de la base de datos de porciones de la misma atendiendo a criterios establecidos en cada momento. Dichos criterios se establecen en función de la fecha de grabación, fecha de variación, tipo de movimiento y grupo de población a seleccionar (en función de la necesidad establecida en cada momento). Además se debe permitir la selección de forma exclusiva de aquellas modificaciones válidas para el tratamiento en exclusiva del procedimiento de reclamaciones en periodo electoral. Los procesos de exportación de información deben recurrir a las tablas históricas correspondientes cuando sea necesario y en función de las fechas solicitadas en el proceso para garantizar que se extrae la información válida respecto del momento solicitado. Como se ha especificado en el apartado correspondiente, debemos tener en cuenta que la información existente en la tabla maestra corresponde exclusivamente al último movimiento y todos los demás movimientos de registros se encuentran en la tabla histórica correspondiente. El sistema debe garantizar que se puedan realizar las extracciones de información que se desee en el momento en el que se desee. Es decir, estos procesos no deben estar limitados cuantitativamente ni temporalmente. Y, para finalizar, el sistema debe preparar la información para garantizar que los procesos de control y de gestión electorales, se lleven a cabo correctamente, a partir de la modificación de la Base Integrada de Población, repercutiendo dichos cambios en las estructuras de datos creadas a tal efecto a petición y bajo supervisión del usuario correspondiente. La Base Integrada de Población es el origen de todos los datos y en ella deben reflejarse en primera instancia todas las modificaciones que puedan afectar a los habitantes, especificando el motivo y en su caso el tipo de reclamación en periodo electoral. El sistema propuesto, garantiza a través de la navegación con los históricos que se pueda recuperar la información válida a una fecha determinada, de forma que la extracción de información pueda realizarse en el momento en el que se desee. Para garantizar una mayor eficacia en la exportación, se propone un mecanismo en forma de estructura de datos que permita almacenar y tratar dicha información. Se ha incorporado en la Base Integrada de Población la información correspondiente al tratamiento de reclamaciones de electores para poder de esta forma tratar los habitantes en función del resultado de la reclamación. El esquema funcional parte de la base de establecer una tabla maestra de control de estas extracciones, o dicho de otra forma, de control de cierres. Este control de cierres identificará un proceso de extracción de datos, sea en periodo electoral y para unas elecciones o no. La extracción de datos inicial marcará los datos relativos al cierre y si incluyen o no las reclamaciones estimadas.



Página 29 de 55

Solamente los usuarios autorizados para ello podrán incluir en la Base Integrada de Población, las modificaciones que puedan ser tratadas como reclamaciones en periodo electoral y repercutir estas en las tablas de cierre ya creadas, seleccionando el cierre en el caso que hubiera varios.



Página 30 de 55

6. Módulos de gestión 1. El sistema Transaccional

En este apartado se realiza un breve planteamiento global del módulo transaccional que será desarrollado ampliamente en la base del análisis pormenorizado del mismo. El Módulo Transaccional es un Gestor de Expedientes en el que se puede parametrizar cualquier movimiento en la base de datos de cada uno de los subsistemas existentes y es a la vez un Centro de mensajería que distribuye a los subsistemas implicados en los expedientes, los mensajes necesarios para mantener la coherencia de la información en los mismos. El Módulo Transaccional se ha concebido para garantizar la integridad del sistema en lo que se refiere a la distribución y actualización de datos en los distintos subsistemas implicados en la Gestión de los expedientes que afectan a cada una de las entidades participantes en el proyecto. Para llevar a cabo la correcta gestión de los Expedientes, el sistema se basa en dos estructuras: por un lado los modelos de expedientes en la que se especifican los parámetros y se diseña el circuito del expediente, y por otro, el control de los expedientes creados a partir del modelo existente. El centro de Mensajería, está construido a partir de la base del sistema TQUEUE, herramienta elaborada y creada por TELVENT, que soporta y garantiza tanto la comunicación con el Gestor de Expedientes como con los distintos subsistemas del aplicativo a través de Webservices dedicados. El mecanismo de funcionamiento del Centro de Mensajería distribuye la información correspondiente al subsistema afectado de forma que éste ejecute la tarea programada. Un Expediente es una transacción que contiene tareas que ejecutan a su vez una acción cada una. Los expedientes se construyen a partir de un modelo en el que se establece todas y cada una de las tareas a realizar por cada uno de los agentes en un momento determinado según el esquema relacional expuesto a continuación:



Página 31 de 55

Mensajería TQUEUE

Módulo Transaccional

INE

Ges

tor E

xped

ient

es

Ayuntamiento Ayuntamiento AyuntamientoAyuntamiento

Web Service

Tipo

Tareas

Acciones

Ejecución

Expediente

Expe

dien

tes

Mod

elos


El Detalle de Ejecución contiene la información necesaria para que el subsistema responsable de la ejecución de la acción pueda realizarlo efectivamente. Cada registro de detalle de ejecución refleja la situación actual de la misma, con los siguientes atributos:

1. Acción informativa para el subsistema destinatario de la misma, no afecta al resultado de la transacción y no se espera resultado de la ejecución.

2. Acción que debe ejecutar el subsistema correspondiente, con espera de respuesta.

El sentido de la respuesta no afecta a la transacción. 3. Acción que debe ejecutar el subsistema correspondiente, con espera de respuesta,

el sentido de la cual si afecta a la transacción, pero no impide la ejecución de los pasos posteriores.

4. Acción que debe ejecutar el subsistema correspondiente, con espera de respuesta,

el sentido de la cual si afecta a la transacción, y que impide la ejecución de los pasos posteriores. Se trunca la transacción y se deja sin efectos toda ella. El mecanismo para reestablecer la situación anterior a la ejecución de un expediente puede efectuarse a través de la ejecución de otro expediente.

Dentro de cada expediente, las tareas están establecidas por prioridad. La ejecución de una dentro de un expediente puede depender del resultado positivo de otra anterior del mismo expediente.



Página 32 de 55

La ejecución de un expediente finaliza informando si la transacción se ha llevado a cabo o no, y el motivo de la misma. En una situación de conectividad efectiva de todos los subsistemas implicados en una transacción, ésta puede ejecutarse en tiempo real garantizando una respuesta inmediata. El sistema garantiza que, de no existir esta conexión los sistemas puedan trabajar con normalidad. Las transacciones son tareas que deben reflejarse en el sistema y que pueden desencadenar actualizaciones en base de datos o no por ser meramente informativas

Cada uno de los pasos de las transacciones tiene una respuesta para cada uno de los agentes, y estos informarán del resultado de la ejecución: correcta o incorrecta, suministrada por el Subsistema encargado de ejecutar una acción. En ambos casos se informará al Módulo transaccional tanto del resultado de la ejecución correspondiente como de la situación. En el modelo de Expedientes, identificamos tres objetos: El Modelo, las tareas asociadas a la transacción y las acciones que deben desarrollar las tareas. El Modelo es una tabla maestra que define y describe el tipo de transacción modelo que usará el Control de Transacciones para importar todas las tareas y acciones a realizar. Las Tareas identifican la acción a realizar dentro de la transacción, la priorizan, suministran criterios de evaluación de la misma y describen el agente y el momento de ejecución de la acción. Las tareas se copian en el Detalle de Ejecución del Control de Transacciones. Se puede modificar la parametrización de las tareas, puede efectuar dicha parametrización el administrador del sistema Transaccional. Los cambios de parametrización afectarán a expedientes de nueva creación. Las Acciones describen la acción a realizar de forma individualizada. El sistema dispone de un número de acciones tasado que conocen y ejecutan cada uno de los subsistemas. Por ejemplo: la acción de validación de habitante, las distintas acciones asociadas a los tipos de movimientos básicos, la acción de información… Para la mejor comprensión del esquema descrito se expone a continuación un ejemplo de un expediente de cambio de residencia: Un ciudadano se dirige al Ayuntamiento del municipio A en el cual desea empadronarse por haber adquirido una vivienda y trabajar allí. El ciudadano en cuestión procede del municipio B. El sistema parte de la premisa de que la base de datos de INE y la de los ayuntamientos afectados se encuentran sincronizadas tal como prevé el proyecto a través del módulo transaccional. Previo a la ejecución del expediente, el Ayuntamiento de destino puede comprobar on-line los datos del interesado en la base de datos de INE. Esta comprobación puede ser previa a la ejecución del expediente de alta en el municipio de destino o no llevarse a cabo a criterio del operador o sujeto a posibles inconvenientes técnicos. Es decir, dicha comprobación es ajena a la ejecución del expediente aunque puede minimizar la posibilidad de error del mismo por datos incorrectos.



Página 33 de 55

El Tipo de expediente, “ACR” puede tener asociadas las siguientes tareas, que conforman la transacción global y que ejecutan las acciones descritas en cada uno de los subsistemas afectados:

1. Acción de verificación de datos proporcionado por el municipio de destino en el subsistema INE

2. Realización de la acción BCR del habitante en la base de datos INE. Esta tarea

está sujeta a que la tarea número 1 haya finalizado correctamente.

3. Realización de la acción ACR del habitante en la base de datos INE. Esta tarea

tiene el mismo nivel de criticidad que la anterior. 4. Acción de verificación de datos proporcionado por el municipio de destino en el

subsistema del municipio de origen.

5. Realización de la acción BCR del habitante en la base de datos del subsistema

del municipio origen. Esta tarea está sujeta a que la tarea número 4 haya finalizado correctamente.

6. finalización del expediente. El expediente se cierra sin error una vez ejecutadas

todas las tareas cuyo nivel de criticidad no lo impide. El expediente se cierra con error si existe alguna tarea crítica no ejecutada correctamente.

La lógica asociada a los distintos tipos de movimiento o de acción, debe tratarse conjuntamente con el sistema global de movimientos Cada subsistema dispone de una tabla de control de expedientes, con la información del identificador del registro asociado con el expediente, el nombre corto de la tabla correspondiente y el identificador del registro de expedientes en el módulo transaccional. Esta tabla permite a cada uno de los subsistemas el control de ejecución y de cada uno de los expedientes asociados a su información, es decir dispone tanto de los expedientes creados por el subsistema como los expedientes que afectan a registros del mismo y creados por otro subsistema. Este control de expedientes se utilizará para conocer el estado actual de la transacción en función de la información recibida por el Módulo Transaccional. Las distintas fases de un expediente son:

1. Pendiente de iniciar: transacción enviada al Módulo Transaccional, pendiente de recibir respuesta del mismo conforme se ha iniciado. Puede deberse a una situación de no conexión o de parada del sistema. Esta situación solamente garantiza que el subsistema correspondiente ha lanzado la transacción

2- Iniciado: Transacción iniciada por el Módulo Transaccional sin ninguna

respuesta 3- En proceso: El Módulo Transaccional ha aceptado la transacción y la está

ejecutando. Para ver el detalle se debería consultar el log del Módulo Transaccional.



Página 34 de 55

4- Finalizado correctamente: La transacción ha finalizado y todos los

agentes participantes de la misma han sido notificados satisfactoriamente.

5- Finalizado con error: La transacción no ha finalizado correctamente por existir algún tipo de error, es decir alguna de las acciones realizadas en el subsistema correspondiente asociada a una tarea del expediente no se ha realizado con éxito. La finalización con error no incluye aquellas acciones que por problemas técnicos no se han ejecutado, sino que se refiere a aspectos funcionales, en el ejemplo de expediente A-CR anteriormente descrito, el paso 4 (Acción de verificación de datos proporcionado por el municipio de destino en el subsistema del municipio de origen), si esta acción que se ejecutará en el subsistema municipal del municipio origen, retorna error, significa que NO ha encontrado al habitante en dicho municipio o que no puede darlo de baja, en cambio si no retorna nada dicha acción durante el periodo de vigencia de la tarea asociada a ésta, el sistema transaccional entiende que ha habido un error de sistema por la razón que sea e intentará de nueva ejecutar dicha tarea, es por ello que el sistema Transaccional implementa mecanismo de control de vigencia de expedientes abiertos y en proceso.

Las acciones ejecutadas en cada subsistema asociadas a tareas de un expediente, podrán lanzar por si mismas nuevos expedientes, así una acción de verificación de habitante, si encuentra a éste duplicado, retornará un código de error y lanzará petición de apertura al Sistema Transaccional de expediente por duplicado de habitante.



Página 35 de 55

7. Construcción del sistema. Punto de partida.

Para pasar de la estructura de datos existente a la que se define en el nuevo sistema, deben realizarse una serie de operaciones que garanticen la coherencia de la información y permitan la correcta realización de todas las fases. En primer lugar, vamos a tratar la migración de datos correspondiente a la formación del territorio, de acuerdo con el sistema descrito. Formación de la base de datos territorial Para la definición del territorio, se tendrá en cuenta el trabajo realizado por el Estudio Demográfico Longitudinal. En particular, y en función de los calendarios, al menos se tendrá en cuenta la asignación de huecos (viviendas/locales) efectuada con ocasión de los censos de población del 2001, que constituyen el punto de partida del EDL. La pieza básica para la formación del sistema territorial, es la estructuración del callejero. Teniendo en cuenta que actualmente están mezclados los datos de territorio con los datos de población, será preciso aislar la información referente al territorio, de la forma siguiente: El callejero se crea a partir de las tablas de Vías y de Pseudovías (aquellas que no complementan a la Vía) actuales del INE. Para detectar las Pseudovías que complementan a la Vía, se usará su referencia en el Tramero. Se crea el sistema de Unidades Poblacionales a partir de las tablas de Unidades Poblacionales. Se crea el sistema de Seccionado a partir de las referencias en las mismas existentes en la tabla del Tramero. A partir del tramero, y como eje fundamental en la transformación de datos territoriales, detectamos y grabamos en el callejero como propuesta de Vías Ficticias aquellas que identifiquen porciones de territorio a las que no se había asignado vía. Básicamente nos referimos a los municipios que están usando la estructura planteada por las Unidades Poblacionales para definir su territorio. El tramero, se usará como conector con el nuevo sistema para la importación de las direcciones existentes en habitantes, asignándoles a éstas su correspondiente Distrito y sección, Código de unidad Poblacional y Distrito Postal. El siguiente paso es acudir a las tablas actuales de Padrón de Habitantes y de Censo Electoral para detectar vías que aún no estén incorporadas al sistema con los pasos anteriores, comparándose el código y nombre de estas vías, y si hubiera discrepancias, se ubicará la información no cargada al sistema en una tabla inicial de discrepancias de callejero para su resolución. Las tablas básicas de territorio establecidas, junto con las tablas de discrepancias correspondientes, se distribuyen a cada uno de los Ayuntamientos para su validación. El resultado de la validación será el territorio de cada municipio. Los Ayuntamientos que dispongan de Sistemas



Página 36 de 55

de información territorial que lo permitan, podrán añadir a los callejeros entregados, el código de calle de Catastro y el suyo propio si lo usan. La posibilidad de disponer de los códigos de calle del Ayuntamiento, permite la transformación de códigos de calle INE a códigos Ayuntamiento en el proceso de carga inicial, para disponer en el sistema únicamente de dos codificaciones: Ayuntamiento/INE y Catastro. En este punto, tenemos una estructura de territorio acorde con las dos visiones existentes (INE y Ayuntamientos) y preparada para introducir la información adicional correspondiente. Previa a la carga de las direcciones postales, que contempla la creación de la tabla de Numerero y de Viviendas, es preciso integrar las tablas de habitantes y electores en la de Personas. La Tabla de Personas integrará las actuales de Base padronal del INE y Censo de Electores. Para establecer el enlace entre ambas tablas se usarán los mecanismos de búsqueda actuales existentes en INE. Para la comprobación inicial de estas dos tablas, se realizará un doble contraste Censo-Padrón en las dos direcciones, para garantizar que se establece el máximo número de enlaces posibles entre las personas. A partir de esta identificación se crearán pares de registros, es decir personas que están incluidas en ambas tablas por ostentar la condición de electores al tiempo que de residentes en algún municipio. Si alguna parte de la información fuera divergente, se irá depositando en un fichero indicando la divergencia y la procedencia, para efectuar posteriormente su validación. Esta tarea de identificar registros de padrón con censo, se puede realizar en distintas fases, garantizando que una vez establecido dicho enlace, éste es persistente en el tiempo. Es decir, una vez identificada la misma persona en las dos bases actuales (Censo y Padrón), esta relación permanece estable puesto que se ha identificado que es la misma persona. La garantía de este enlace, se establecerá a partir de la asignación del NIDEN en los registros de Censo Electoral. A las personas incluidas en el PERE, se les aplicarán los mismos mecanismos de enlace establecidos para las personas incluidas en Censo Electoral, asignándoles el NIDEN cuando se haya podido establecer un enlace correcto con la Base padronal del INE. El número de personas de Censo Electoral Residentes en España sin NIDEN, o lo que es lo mismo, sin relación con Padrón de Habitantes, debe necesariamente, tender a cero. Habrá necesariamente un grupo de personas que no se encontrarán en Censo Electoral, los menores de 16 años y los residentes extranjeros que no ostentan la condición de elector. Los menores se validarán y se incorporarán al sistema y en cuanto a las personas que no sean electores, se comprobará si se trata de personas cuya nacionalidad es diferente a la española, comunitaria o con tratado de reciprocidad. Si se cumplen estos requisitos, se estima que la información es correcta. Si aún existieran personas que no están incluidas en los supuestos anteriores, pero no se encuentran en el fichero de Censo Electoral, se copiarán en un fichero de discrepancias indicándose cuáles para su posterior validación, presuponiendo que si se trata



Página 37 de 55

efectivamente de residentes, se incluirán en la Base Integrada de Población cuando se cree. Si resultara la hipótesis contraria, es decir alguna persona que se encuentra en Censo Electoral, pero no así en Padrón de Habitantes, se marcará también el registro con esta circunstancia, en un fichero, que se tratará de resolver mediante el contraste con los datos Municipales. En el momento de la carga de los registros claramente identificados en Censo y en Padrón, se establecerán los criterios necesarios para su incorporación única en la Base Integrada de Personas . En la descripción más detallada del sistema de creación de la Base Integrada de Personas se especificarán todos los procedimientos a ejecutar. Esta primera tabla provisional de Personas servirá de base para el contraste con la información de cada uno de los Ayuntamientos, información que se solicitará a modo de fichero de la misma forma que se está realizando actualmente en el proceso de cifras. En este contraste de información de la nueva base obtenida a partir de Censo y Padrón con la información de los Ayuntamientos, se usará la información de los Ayuntamientos para discernir las posibles discrepancias de datos entre Censo y Padrón. Una vez comparadas las dos bases nuevas: censo y padrón con Ayuntamientos, se remitirá a los Ayuntamientos la base obtenida a partir del contraste correspondiente, asignando y trasladando a los mismos, los NIDEN de los habitantes para su conocimiento y los ficheros de incidencias descritos para su depuración y validación. La información resultante, será la Tabla de Personas con la que arranque el nuevo sistema, cuyos integrantes serán todos residentes en España y españoles residentes en el extranjero (PERE), y, los que reúnan los requisitos exigibles para ello, serán además electores. La dirección de la tabla de carga de Personas, se extrae y se pasa por el filtro del tramero, que va a proporcionar integridad respecto de las divisiones territoriales existentes y del callejero. De las direcciones actuales se prevé que podamos encontrar 3 casos distintos:

1. La información encaja perfectamente con la existente en Tramero. Para cada persona, se carga la información territorial de la misma en Numerero y en Viviendas, en el caso de que no se haya cargado ya. En esta fase se podrán definir criterios para unificar codificadores a nivel de Escalera, planta y puerta que en realidad sean los mismos. Para identificar las viviendas podría ser necesario utilizar la hoja padronal, ya que si se hace a nivel de persona aumentaremos las viviendas por diferencias en los datos de domicilio de personas residentes en la misma vivienda.

2. La calle de personas existe pero está fuera de tramo. En este caso, se carga la

información en numerero y viviendas, asignando también códigos de Distrito-sección y Unidad poblacional si existe esta información en la tabla de personas, pero se marca para su posterior verificación.

3. La dirección existente en personas dispone de una dirección no reflejada en

tramero. En este caso, se propone la creación de una pseudovía para garantizar que la información pueda ser introducida correctamente en el sistema. Tanto la pseudovía como el número como la vivienda, se marcarán para su posterior verificación, como el caso anterior.



Página 38 de 55

Para la construcción de la dirección en viviendas, el sistema pasará por el filtro de asignar –si corresponde- la pseudovía que complementa la vía como texto en dirección no estructurado.

Habitantes

Tramero


Personas

Callejero

Numerero

Viviendas

Discrepanciascallejero

Territorio

Construcción del sistema

Electores

DiscrepanciasViviendas

DiscrepanciasNumerero

DiscrepanciasPersonas D

epur

ació

n A

yunt

amie

ntos



Página 39 de 55

8. Propuesta de definición de tablas

La propuesta de definición de tablas pretende ofrecer un planteamiento de inicio que sirva como herramienta de trabajo posterior en el análisis de cada uno de los módulos de todos los subsistemas. Esta primera versión de definición de tablas y sus relaciones, no es pues definitiva, ni tampoco abarca exhaustivamente todo el detalle que necesariamente contendrá el sistema. Por ejemplo, se ha prescindido en esta primera fase de establecer los campos y sistemas relacionados con las búsquedas de información, no se han añadido los campos de control en las tablas, no están representados los históricos en el diagrama entidad-relación, etc.



Página 40 de 55

1. Territorio- Diagrama Entidad – Relación

TRR_NUMERERO

CP NMR_ID

CE1 NMR_CALIDCE2 NMR_NUCIDCE3 NMR_SECC_ID

TRR_PROVINCIAS

CP PROVIN_CPRO

TRR_MUNICIPIOS

CP,CE1 MUNIC_CPROCP MUNIC_CMUN

TRR_CALLEJERO

CP CALLE_ID

CE1 CALLE_CPROCE1 CALLE_CMUN

1..*

1..*

1..*

TRR_DISTRITOS

CP DISTR_ID

DISTR_CDISCE1 DISTR_CPROCE1 DISTR_CMUN

TRR_SECCIONES

CP SECC_ID

CE1 SECC_DISTR_ID

1..*

TRR_ECOLECTIVA

CP ECOLE_ID

ECOLE_CENTCOLCE1 ECOLE_CPROCE1 ECOLE_CMUN

1

TRR_ESINGULAR

CP ESING_ID

CE1 ESING_ECOLE_IDESING_CENTSINESING_DCENTSI

1..*

TRR_NUCLEOS

CP NUCLEO_ID

CE1 NUCLEO_ESIIDNUCLEO_CNUCLEO_ID

1..*

TRR_VIV-LOC

CP VIV-LOC_ID

CE1 VIV-LOC_NMR_IDCE2 VIV-LOC_PCN_ID

*

TRR_CONSULADOS

CP CONSU_ID

CONSU_CCONSULADO

TRR_PAISES

CP PAIS_ID

PAIS_CPAIS

TRR_PAICON

CP PAICON_ID

CE1 PAICON_CONSU_IDCE2 PAICON_PAI_ID

1..*

1..* *

1..*

Unidad de Población

Distrito/sección

*

1..*



Página 41 de 55

2. Territorio – Definición de las tablas

PROVINCIAS (TRR_PROVINCIAS) Nombre Corto: PROVIN

Tabla de provincias. Contiene todas y cada una de las provincias del Estado Español. La codificación de las provincias es común a la que se usa en la Dirección General de Catastro. Nombre Tipo Descripción PROVIN_CPRO N2 Código de provincia PROVIN_DESCR25 A25 Descripción de provincia de 25 caracteres

MUNICIPIOS

(TRR_MUNICIPIOS)

Nombre corto: MUNIC Tabla de municipios. Dentro de la provincia, contiene los municipios de la misma según la codificación usada por INE. Se acompaña como atributo el código de municipio utilizado por la Dirección General de Catastro. Nombre Tipo Descripción MUNIC_CPRO N12 Código de provincia MUNIC_CMUN N3 Código INE de municipio MUNIC_CMUNDGT N3 Código DGC de municipio MUNIC_DESCR70 A70 Descripción de municipio de 70 caracteres

CALLEJERO (TRR_CALLEJERO) Nombre corto: CALLE

Tabla de vías y pseudovías que sustituyen a la vía tal como se ha explicado en el capítulo de definición de territorio. Nombre Tipo Descripción CALLE_ID N12 ID de la tabla CALLE_CPRO N2 Código de provincia CALLE_CMUN N3 Código de municipio CALLE_CVIAINE N6 Código de vía INE CALLE_CVIAAYTO N6 Código de vía ayuntamiento. Se mantiene

por compatibilidad CALLE_CVIADGC N6 Código de vía catastro. CALLE_VIAPSE A1 Tipo de vía. Normalizado(tabla auxiliar)

- V vía - P pseudovía - F Vía Ficticia

CALLE_TIPO A5 Sigla de la vía. Enlace con la tabla auxiliar de siglas.

CALLE_DESCR50 A50 Nombre oficial de la vía de 50 caracteres CALLE_DESCR25 A25 Nombre corto de la vía



Página 42 de 55

CALLE_POSSIGLA A1 Posición de la sigla de la vía en la construcción de la dirección asociada.

CALLE_DESCRNORM A25 Descripción corta de la vía normalizada para ordenación de las mismas.

NUMERERO

(TRR_NUMERERO)

Nombre corto:NUMER

Tabla de numerero. Identifica la Numeración y contiene los atributos asociados a la misma.

Nombre Tipo Descripción NUMER_ID N12 ID de la tabla NUMER_CALID N12 ID de la tabla de callejero NUMER_NUMERO N4 Número postal NUMER_CNUMER A1 Calificador del número NUMER_ESCALERA A2 Escalera. Normalizado (tabla auxiliar) NUMER_BLOQUE A2 Bloque. NUMER_PORTAL A2 Portal. NUMER_KILOMETRO N3 Kilómetro NUMER_HECTOMETRO N2 Hectómetro NUMER_REFCAT A14 Referencia Catastral de la parcela NUMER_SECC_ID N12 ID de la tabla de secciones. Todos los

registros deben de tener un enlace con la tabla de Secciones electorales.

NUMER_NUCLEO_ID N12 ID de la tabla de núcleos poblacionales NUMER_DISTP N5 Distrito postal al que pertenece el registro NUMER_X N10 Identificación de a las coordenadas

geográficas catastrales de la Parcela NUMER_Y N10 Identificación de las coordenadas

geográficas catastrales de la Parcela

VIVIENDA-LOCAL

(TRR_VIV-LOC)

Nombre corto: VIV-LOC

Tabla de direcciones. Pendiente de denominar de forma unívoca. Contiene todas las direcciones normalizadas de España además de las direcciones del Extranjero para localizar a los Españoles residentes en el Extranjero sin normalizar. Por dirección normalizada entendemos aquella que sigue la estructura propuesta de territorio, y por dirección no normalizada aquella en la que la dirección está contenida en un texto y por tanto no tienen enlace con Numerero.

Nombre Tipo Descripción VIV-LOC_ID N12 ID de la tabla



Página 43 de 55

VIV-LOC_NUMER_ID N12 ID de la tabla Numerero VIV-LOC_PCNID N12 ID de la tabla de país/consulado VIV-LOC_PLANTA A3 Planta. Normalizado(tabla auxiliar) VIV-LOC_PUERTA A4 Puerta. Normalizado (tabla auxiliar) VIV-LOC_DESCR A60 Texto con la dirección en texto para

localizar los Españoles residentes en el Extranjero.

VIV-LOC_CIUDAD A50 Ciudad extranjera. SOLO Si VIV_NMRID = NULL (PERE)

VIV-LOC_CODPOSTAL

A50 Código Postal del extranjero SOLO Si VIV_NMRID = NULL (PERE)

VIV-LOC_TIPO A2 Tipo de vivienda (local, vivienda familiar, …). Normalizado (tabla auxiliar)

VIV-LOC_TDNE A50 Texto en dirección no estructurado (antiguas Pseudovías que complementaban la vía)

VIV-LOC_REFCAD A20 Referencia Catastral de la Unidad Fiscal correspondiente

DISTRITOS (TRR_DISTRITOS) Nombre corto: DISTR Tabla de Distritos Censales

Nombre Tipo Descripción DISTR_ID N12 ID de la tabla DISTR_CPRO N2 Código de provincia DISTR_CMUN N3 Código de municipio DISTR_CDISTRITO N2 Código de distrito DISTR_DESCR A50 Descripción de distrito

SECCIONES

(TRR_SECCIONES)

Nombre corto: SECC

Tabla de Secciones y subsecciones censales

Nombre Tipo Descripción SECC_ID N12 ID de la tabla SECC_DISTR_ID N12 ID de la tabla de distritos SECC_CSECCION N3 Código INE de sección censal SECC_LSECCION A1 Letra de subsección

ENTIDADES COLECTIVAS



Página 44 de 55

(TRR_ECOLECTIVAS)

Nombre corto: ECOLE Tabla de entidades colectivas

Nombre Tipo Descripción ECOLE_ID N12 ID de la tabla ECOLE_CPRO N2 Código de provincia ECOLE_CMUN N3 Código de municipio ECOLE_CECOLECTIVA N2 Código INE de entidad colectiva ECOLE_DESCR50 A50 Descripción de entidad colectiva de 50

caracteres ECOLE_DESCR25 A25 Descripción corta de entidad colectiva

ENTIDADES SINGULARES

(TRR_ESINGULARES)

Nombre corto: ESING

Tabla de entidades singulares

Nombre Tipo Descripción ESING_ID N12 ID de la tabla ESING_ECOLE_ID N12 ID de la tabla de entidades colectivas ESING_CESINGULAR N2 Código INE de entidad singular ESING_CDCONTROL N1 Código de control de entidad singular ESING_DESCR50 A50 Descripción de entidad singular de 50

caracteres ESING_DESCR25 A25 Descripción corta de entidad singular

NUCLEOS/DISEMINADOS DE POBLACIÓN

(TRR_ENUCLEOS)

Nombre corto: NUCLEO Tabla de núcleos poblacionales

Nombre Tipo Descripción NUCLEO_ID N12 ID de la tabla NUCLEO_ESING_ID N12 ID de la tabla de entidades singulares NUCLEO_CNUCLEO N2 Código INE de núcleo poblacional NUCLEO_DESCR50 A50 Descripción de núcleo poblacional de 50

caracteres NUCLEO_DESCR25 A25 Descripción corta de núcleo poblacional

PAISES

(TRR_PAISES)

Nombre corto: PAIS Tabla de países



Página 45 de 55

Nombre Tipo Descripción PAIS_ID N12 ID de la tabla PAIS_CPAIS N3 Código INE de país PAIS_DESCR50 A50 Descripción de país de 50 caracteres PAIS_DESCR25 A25 Descripción corta de país PAIS_TIPO A1 Identificación de si un país es oficial o no.

Sólo los países oficiales pueden referenciarse a la tabla país-consulado.

CONSULADOS

(TRR_CONSULADOS)

Nombre corto: CONSU Tabla de consulados

Nombre Tipo Descripción CONSU_ID N12 ID de la tabla CONSU_CCONSULADO N3 Código INE de consulado CONSU_DESCRIP N50 Descripción de consulado

PAISES/CONSULADOS (TRR_PAICON) Nombre Corto: PAICON

Tabla de relación de paises/consulados. Tabla creada para satisfacer la necesidad de que un país podrá tener n consulados y un consulado podrá pertenecer a n paises. Nombre Tipo Descripción PAICON_ID N12 ID de la tabla PAICON_CONSU_ID N12 ID de la tabla de consulados PAICON_PAI_ID N12 ID de la tabla de paises



Página 46 de 55

3. Tablas de Personas. Diagrama Entidad – Relación

BIP_PERSONAS

CP PERSONA_ID

BIP_CIERRES

CP CCIERRE_ID

CE1 CCIERRE_PERSONA_ID

BIP_DISCREPANCIAS

CP DISCREP_ID

CE1 DISCREP_PERSONA_ID

1..*

1..* BIP_DUPLICADOS

CP DUPLICADO_ID

CE1 DUPLICADO_MAESTRO_PERSONA_IDCE2 DUPLICADO_DETALLE_PERSONA_ID

1..*

1..*



Página 47 de 55

4. Tablas de Personas. Definición de tablas PERSONAS (PNH_PERSONAS) Nombre Corto: PERSONA

Tabla de PERSONAS. Contiene las personas que conforman el Base padronal del INE, el Censo Electoral así como el PERE cuando se incorpore al sistema. Nombre Tipo Descripción PERSONA_ID N12 ID de la tabla.

PERSONA_NIDEN N10 Número de identificación del habitante PERSONA_VIVI_ID

N12 ID de la tabla de viviendas

PERSONA_HOJAP N10 Número de hoja Padronal de la persona dentro de la vivienda, que garantiza la compatibilidad con el sistema anterior.

PERSONA_CPRO N2 Código de provincia PERSONA_CMUN N3 Código de municipio PERSONA_CONPAI_ID N12 ID de la tabla de países/consulados PERSONA_NIE N11 Número de identificación electoral PERSONA_NIA N15 Número de identificación Ayuntamiento, o

número de matrícula del consulado. PERSONA_NOMBRE A33 Nombre del habitante (literal introducido

por Ayto.) PERSONA_PART1 A8 Partícula del primer apellido PERSONA_APE1 A33 Primer apellido del habitante (literal

introducido por Ayto.) PERSONA_PART2 A8 Partícula del segundo apellido PERSONA_APE2 A33 Segundo apellido PERSONA_COMPLEMAPE A25 Información del apellido de soltera/casada

de las personas que lo pierdan/adopten PERSONA_UNAPELLIDO A1 Campo de especificación de personas con

un solo apellido PERSONA_FUENTEDOC A1 Fuente de obtención del documento de

identificación de la persona. Inicialmente de carácter informativo aunque se estudiarán distintas funcionalidades. Posibilidades Ministerio Interior, Ciudadano, Ayuntamiento.

PERSONA_TIDEN A1 Tipo de documento de identificación de la Persona. Normalizado (tabla auxiliar) • Dni • Tarjeta Residencia • Pasaporte • Número de inscripción a Registro Civil

para menores sin DNI. PERSONA_NDOCU A25 Número de documento, con dígitos de

control correspondientes PERSONA_FNAC DATE Fecha de nacimiento PERSONA_SEXO A1 Sexo del habitante. Normalizado valores 1



Página 48 de 55

o 6 PERSONA_CPRON N2 Código de provincia de nacimiento PERSONA_CMUNN N3 Código de municipio de nacimiento. PERSONA_CPAIN N3 Código de país de nacimiento. PERSONA_COMPLNAC A60 Complemento del lugar de nacimiento. PERSONA_CNES A2 Código de nivel de estudios. Normalizado

(tabla auxiliar) PERSONA_CNACI N3 Código de Nacionalidad. PERSONA_CPRODP N2 Código de provincia de procedencia/destino PERSONA_CMUNDP N3 Código de municipio de

procedencia/destino. PERSONA_PAISDP N3 Código de país de procedencia/destino PERSONA_CONSULADOP N3 Cógido de Consulado de

procedencia/destino para Españoles residentes en el extranjero.

PERSONA_FALTMUN DATE Fecha de la último alta en el municipio/consulado.

PERSONA_FRENOV DATE Fecha de renovación de la inscripción padronal para el caso de ENCSARP (Extranjeros No Comunitarios Sin Autorización de Residencia Permanente)

PERSONA_PERMANENTE A1 Indica si la persona tiene autorización de residencia permanente.

PERSONA_FCADUCIDAD DATE Fecha de caducidad de la inscripción del ENCSARP

PERSONA_FAVISO DATE Fecha de aviso de notificación al habitante que debe renovar su inscripción padronal

PERSONA_CVAR A1 Código de variación. Normalizado (tabla auxiliar)

PERSONA_CAUV A2 Causa de variación. Normalizado (tabla auxiliar)

PERSONA_DUPLID_NIDEN N12 Niden del habitante con el que está duplicado. Solamente debe rellenarse en caso de un cambio por BDU

PERSONA_ININCAP DATE Fecha de inicio incapacitación a efectos electorales

PERSONA_FINICAP DATE Fecha de finalización de incapacitación a efectos electorales

PERSONA_ORGANOIN N12 Organo que dicta la sentencia de la incapacitación. Requiere Tabla Externa

PERSONA_INTENCIONVOTO Declaración de intención de voto para Municipales, parlamento Europeo, o las dos. Posibilidades Si,no, blanco o no haber contestado. Los noruegos pueden votar en las municipales pero en cada convocatoria deben manifestar si desean votar o no.

PERSONA_FECHARECLAM DATE Fecha de reclamación para periodos electorales.

PERESONA_RESOLRECLAM A1 Resolución de la reclamación (S/N) PERSONA_TIPORECLAM A1 Tipo de reclamación en periodo electoral

(si corresponde): • Reclamación • Certificación Censal



Página 49 de 55

• Orden judicial PERSONA_CPRO_VOTO N2 SOLO para CERA. Provincia española

asignada para el voto PERSONA_CMUN_VOTO N3 SOLO para CERA. Municipio español

asignado para el voto PERSONA_TELEFONO A13 Número de teléfono. Dato voluntario.

Pendiente de decisión por el Consejo de Empadronamiento para su disponibilidad en el INE

PERSONA_REPRESENTANTE N12 Identificación de la persona que realiza las tareas de representante del habitante en cuestión. Dato voluntario de información a incluir en el subsistema municipal

PERSONA_NOMBREPADRE A20 Nombre del padre para menores extranjeros, no nacidos en España sin documentación

PERSONA_NOMBREMADRE A20 Nombre de la madre para menores extranjeros, no nacidos en España sin documentación



Página 50 de 55

VOLCADO GENÉRICO DE INFORMACIÓN (PNH_CIERRESCENSO) La tabla de cierre, así como la de control del cierre, están pendientes de definir de forma efectiva su estructura de forma coordinada con la Oficina de Censo Electoral aunque la funcionalidad ya se ha expuesto en el capítulo correspondiente, y no alterará el enfoque expresado en su definición.

DUPLICADOS

(PNH_DUPLICADOS)

Nombre corto: DUPLICADO Tabla de duplicados

Nombre Tipo Descripción DUPLICADO_ID N12 ID de la tabla DUPLICADO_MAESTRO_PERSONA_ID N12 ID de la tabla Personas.

Persona maestra en la detección de duplicados

DUPLICADO_DETALLE_PERSONA_ID N12 ID de la tabla de Personas. Persona duplicada con la persona detalle

DUPLICADO_ESTADO A1 Estado final del duplicado: � Pendiente � Finalizado

Si está pendiente pero con número de expediente, éste significará que está en proceso de resolución

DISCREP_RESOL A1 Resolución final de duplicado: � Duplicado � Duplicado rechazado por

el subsistema externo � No duplicado

NODUPLICADOS

(PNH_NODUPLICADOS)

Nombre corto: NODUPLICADO Tabla de duplicados falsos

Nombre Tipo Descripción NODUP_ID N12 ID de la tabla NODUP_MAESTRO_PERSONA_ID N12 ID de la tabla Personas.

Persona maestra en la detección de duplicados

NODUP_DETALLE_PERSONA_ID N12 ID de la tabla de Personas. Persona no duplicada con la persona detalle



Página 51 de 55

DISCREPANCIAS (PNH_DISCREPANCIAS)

Nombre corto: DISCREP Tabla de discrepancias entre la información contenida en los diferentes SubSistemas producidas por el sistema. El contenido de la tabla de discrepancias está pendiente de un análisis más exhaustivo de la misma. Nombre Tipo Descripción DISCREP_ID N12 ID de la tabla DISCREP_PERSONA_ID N12 ID de la tabla Personas.

Persona sobre la que se discrepa su información padronal

DISCREP_PERSONA Registro de Persona sobre el que existe la discrepancia. Contendrá toda la información padronal de la persona discrepante provinent del SubSistema externo.

DISCREP_CONTROL_DISCREPANCIA Información de control de la discrepancia generada, incluirá información de:

� Tipo de discrepancia � Fecha de generación

discrepancia � …



Página 52 de 55

2. Tablas del Módulo Transaccional. Modelo Entidad-Relación

Con formato: Numeración yviñetas



Página 53 de 55

3. Tablas del Módulo Transaccional. Definición de las tablas

MODELOS DE TRANSACCIÓN

(STC_MODELOS)

Nombre corto: MODELO Tabla de modelos de Transacción

Nombre Tipo Descripción MODELO_ID N12 ID de la tabla MODELO_DESCR A255 Descripción del modelo MODELO_CADUCIDAD N4 Duración máxima que puede tardar en

ejecutar el expediente asociado a este modelo a partir de la fecha de creación del expediente

MODELO_FCADUCIDAD Fecha Fecha hasta la que se pueden generar expedientes del tipo asociado

TAREAS

(STC_TAREAS)

Nombre corto: TAREA Tabla de tareas que componen el modelo y conforman el expediente

Nombre Tipo Descripción TAREA_ID N12 ID de la tabla TAREA_MODELO_ID N12 ID de la tabla de modelos de expedientes TAREA_DESCR A255 Descripción de la tarea TAREA_ORDEN N3 Número de orden de la tarea dentro del

expediente TAREA_CRITICIDAD N12 Identificación de criticidad de la tarea en la

transacción tal como se ha explicado en la descripción del módulo transaccional. (requiere tabla auxiliar)

TAREA_SUBSISTEMA N12 Identificación del subsistema al cual va dirigida la tarea. (requiere tabla auxiliar)

TAREA_ACCION_ID N12 ID de la tabla de acciones. Indica la acción que debe ejecutarse en esta tarea.

TAREA_DEPENDENCIA N3 Identificador de la tarea dentro del modelo de la cual depende un resultado positivo antes de iniciar esta tarea.

ACCIONES

(STC_ACCIONES)

Nombre corto: ACCION

Con formato: Numeración yviñetas



Página 54 de 55

Tabla de enumeración de las posibles acciones a realizar por una tarea dentro del modelo de expediente. Identifica aquellas acciones que pueden ser ejecutadas en su integridad en alguno de los subsistemas.

Nombre Tipo Descripción ACCION_ID N12 ID de la tabla ACCION_DESCR A255 Nombre de la acción ACCION_TIPO A1 Tipo de acción:

1. Acción informativa. No espera respuesta de resultado de acción

2. Acción con espera de respuesta

CONTROL TRANSACCIONES (STC_EXPEDIENTES) Nombre corto: EXP Tabla de expedientes. Un expediente es una agrupación de tareas que ejecutan acciones con parámetros establecidos de entrada y /o de salida.

Nombre Tipo Descripción EXP_ID N12 ID de la tabla EXP_MODELO_ID N12 ID de la tabla de modelos de expediente EXP_FINICIO DATE Fecha y hora de inicio de la transacción EXP_FFIN DATE Fecha y hora de fin de la transacción EXP_ESTADO A1 Estado de la transacción

1. Pendiente 2. Iniciado 3. En proceso 4. Finalizado correctamente 5. Finalizado con error

EXP_PARAMINI A255 XML de parámetros de entrada EXP_PARAMFIN A255 XML de parámetros de salida EXP_FCADUCIDAD A22 Fecha de caducidad del expediente

DETALLE EJECUCIÓN (STC_DETEXPEDIENTES) Nombre corto: DEXP Tabla de tareas a ejecutar por expediente.

Nombre Tipo Descripción DEXP_ID N12 ID de la tabla DEXP_EXP_ID N12 ID de la tabla de expedientes DEXP_SUBSISTEMA N12 Subsistema al cual va dirigida la acción de la

tarea. Identificación del destinatario al que se realizará la petición de ejecución de la tarea.

DEXP_FINICIO DATE Fecha y hora de inicio de la transacción DEXP_FFIN DATE Fecha y hora de fin de la transacción DEXP_ESTADO A1 Estado de la tarea en ejecución



Página 55 de 55

6. En proceso 7. Pendiente respuesta 8. Finalizada con error 9. Finalizada con éxito

DEXP_ACCION_ID ID de la tabla de acciones DEXP_NORDEN N3 Número de orden de la tarea dentro del

expediente DEXP_PARAMINI A255 XML de parámetros de entrada DEXP_PARAMFIN A255 XML de parámetros de salida DEXP_DEPENDENCIA N3 Identificador de la tarea dentro del modelo de

la cual depende un resultado positivo antes de iniciar esta tarea.

DEXP_CRITICIDAD N12 Identificación de criticidad de la tarea en la transacción tal como se ha explicado en la descripción del módulo transaccional. (requiere tabla auxiliar)

anÁlisis funcional del proyecto avanza … · intercambio previamente establecidos. del mismo...

Documents