TRABAJO DE DISEÑO

Y ADMINISTRACION
DE BASES DE DATOS

CENSO 2001
(Trabajo en grupo
nº2)
ROBERTO AMOR MARCOS

ANTONIO IGNACIO CAMBRILS ORUÑA

DANIEL TEJEDO GONZÁLEZ

ÍNDICE

1 – DESCRIPCIÓN DEL PROBLEMA

2 – DISEÑO DEL MODELO CONCEPTUAL

- ENTIDAD VIVIENDA

- ENTIDAD HOGAR

- ENTIDAD PERSONA

3 – REGLAS DE NEGOCIO

4 – ACERCA DE LA CORRECCIÓN QUE NOS FUE ENTREGADA

5 – PASO DEL MODELO CONCEPTUAL AL FÍSICO

1 – DESCRIPCIÓN DEL PROBLEMA

Se nos ha planteado llevar a cabo la realización de la base de datos

que pueda recoger la información recogida en el censo de población
español de 2001.

El censo de población es un recuento de población que se realiza

cada 10 años con el propósito de conocer las actividades económicas
de los habitantes, el conocimiento, desplazamiento, nivel de estudios,
infraestructura, poder adquisitivo, entre otros, con el fin de saber la
cantidad actual de habitantes de ese país o nación., en este caso
España.

Para ello, se envían unos cuestionarios a las viviendas, con una serie
de preguntas sobre la vivienda, el hogar (es decir, el conjunto
familiar) y los habitantes entre 16 y 64 años. Transcurrido cierto
plazo, los cuestionarios habrán de enviarse a la central otra vez para
almacenar la información recogida en ellos en la base de datos.

En 2001 los cuestionarios fueron los siguientes:

Vivienda: http://www.ine.es/censo2001/rvivicast.pdf
Hogar: http://www.ine.es/censo2001/chpcasres.pdf
Datos patronales: http://www.ine.es/censo2001/hppcasres.pdf

Individual: http://www.ine.es/censo2001/indivcasres.pdf
Así pues, nuestro problema pasa por analizar cada cuestionario
detenidamente, y lograr almacenar en una base de datos consistente
y estructurada todos y cada uno de los datos y todas y cada una de
las opciones que pueden ser rellenadas en cada uno de los
cuestionarios.

El primer paso para ello es realizar un modelo conceptual en el que

todos estos datos tengan cabida.

2 – DISEÑO DEL MODELO CONCEPTUAL

Hemos construido nuestro modelo conceptual siguiendo un esquema

de Entidad-Relación. Para modelizarlo, intentamos ir pregunta a
pregunta del cuestionario viendo que información se pedía,
intentando eliminar posibles informaciones repetidas, e intentado
agrupar todo lo máximo posible. Intentaremos mostrar todos los
problemas de decisión que nos hemos encontrado, así como nuestra
actuación ante ellos. (El modelo Entidad-Relación puede ser
encontrado en el mismo archivo comprimido en que estaba el
documento).

De los cuestionarios enseguida se deduce que hace falta una entidad

para cada una de las partes que engloban (Persona, Hogar y
Vivienda), pues en cada una se recoge información distintas y están
relacionadas directamente. Son las tres entidades más importantes,
y las demás son solo un apoyo para completar la información que
precisan.

Hay que aclarar que no todos los datos de la entidad Hogar se

encuentran dentro del cuestionario Hogar, por ejemplo también
preguntan por el hogar en el cuestionario de vivienda. Los datos de
una entidad estarán recogidos de varios cuestionarios, no solo del
cuestionario que lleva su nombre.

ENTIDADES VIVIENDA Y VIVIENDA/ALOJAMIENTO

Estas dos entidades representan a las viviendas, pero lo hacen de

diferente manera. Vivienda representa la información permanente de
la vivienda, que son iguales en todos los censos (como la dirección o
la superficie). La entidad Vivienda_alojamiento refleja los datos que
se preguntan en el cuestionario, no permanentes. Por eso incluye un
atributo año_censo, para saber a cuales de los cuestionarios
pertenecen los datos, y saber así los cambios acaecidos en la
vivienda con el paso de los años.

Una vivienda_alojamiento solo es una vivienda, pero como esta puede

tener muchos cambios, puede tener n viviendas_alojamientos.

Vivienda (datos permanentes) posee los siguientes atributos:

• Id_Vivienda: Número entero que identifica la vivienda.

• Dirección: Campo multivaluado que contiene los campos

"calle" (nombre de la calle en que está ubicada la vivienda),
"número" (número de la vivienda), "bloque"(número de
bloque de la vivienda, permite nulos), "piso" (número de piso
de la vivienda, permite nulos), "letra" (letra dentro del piso,
permite nulos) y cp (código postal de la residencia). Esta
información no se recoge directamente del cuestionario, sino
que se sabe porque los cuestionarios se envían por correo
(ahora se podrá hacer por internet, en cuyo caso habría que
rellenarlo). La información del municipio de la vivienda se
puede encontrar a través de la relación de la entidad
Persona, que se comentará más adelante.

• Numero Habitaciones: Campo entero que recoge el

número de habitaciones de que dispone la vivienda.

• Superficie: Número entero que indica el número de

metros cuadrados que ocupa la vivienda.

Vivienda_alojamiento (datos de cada censo en concreto) posee los

siguientes atributos:

• Id_Vivienda_alojamiento: Número entero que identifica la

vivienda.

• Año Residencia: Indica el año en que la familia (hogar)

 empezó a vivir en la vivienda en cuestión.

• Refrigeración: Campo que puede tomar los valores "sí" o

"no", y que indica si la vivienda dispone o no de aire
acondicionado

• Calefacción: Campo que puede tomar los valores "si" o

"no", y que indica si la vivienda dispone de calefacción.

• Tipo Calefacción: Campo que puede tomar los valores

"individual", "colectiva" o "aparato calentador", y que indica
el tipo de calefacción de que dispone la vivienda. Admite
nulos.

• Año_censo: Indica el año del censo al que pertenecen los

datos de esta vivienda.

En el cuestionario vivienda se puede observar que se pregunta por

varios detalles sobre la edificación, detalles que cambian con el paso
del tiempo. Por ello, todos estos datos irán relacionados a la entidad
Vivienda_alojamiento y no a Vivienda. Se pide información sobre los
problemas que tiene la vivienda, el régimen de tenencia y los
combustibles que se usan en ella. Para modelizar esta información,
hemos decidido crear entidades aparte para favorecer la consistencia
de la información y mantener fielmente las opciones del cuestionario,
y un atributo de relación. Las dos nuevas entidades (Problemas y
Tipo_Combustible) tendrán un id identificativo, un nombre y una
descripción de su significado. El régimen de tenencia será un valor de
la relación "vive" entre el hogar y la vivienda_alojamiento, y tendrá el
dominio de valores que se define en el formulario (alquiler, etc.).

ENTIDAD HOGAR
La vivienda se relaciona 1 a 1 con la entidad Hogar. El hogar
representa a la familia, al número de personas como conjunto familiar
que ocupan una vivienda. En una vivienda solo hay un hogar, y un
hogar solo tiene una vivienda. El hogar solamente tiene dos atributos,
un id identificativo y "num_transportes", que indica el número de
coches de los que el hogar dispone para desplazarse (3 como
máximo).

Hogar completa el resto de información que se pide en los

cuestionarios mediante la entidad Segunda Vivienda.

La entidad SegundaVivienda contiene información relativa a la

vivienda alternativa del hogar, si la hubiere. La SegundaVivienda
tiene un identificativo y un campo año_censo que indica en que año
se realizó el censo en que el hogar ocupaba esa segunda vivienda. El
valor del número de días que se pasan en la segunda vivienda se
guarda como atributo de la relación "vive" entre hogar y vivienda. El
motivo de guardarlo tan alejado es que si ese número vale 0, la
relación de Hogar con Segunda Vivienda no tiene sentido, y así se
puede controlar que no haya inconsistencia en la información
(además de evitar la posible aparición de valores nulos).

Además, la entidad Segunda Vivienda está relacionada con las

entidades de localización (Municipio y Pais), para guardar la
información sobre su ubicación.

ENTIDADES PERSONA Y PERSONA CENSO

Hogar se relaciona también con la entidad principal de la base de

datos, que es Persona Censo. Un hogar está formado por un conjunto
de personas, y una persona pertenece a un único hogar.

El concepto de Persona y Persona Censo es similar al de

Vivienda/Alojamiento y Vivienda. Persona guarda los datos
temporales del sujeto (nombre, apellidos, sexo, etc.), y Persona Censo
guarda los datos del sujeto que cambian o son susceptibles de
cambiar con el paso del tiempo.

Una persona puede tener varias Personas Censos, pero una Persona
Censo solo puede tener una persona (que son sus datos
permanentes).

La entidad Persona posee los siguientes atributos:

• Id_Persona: Número entero que identifica a la persona.

• Nombre: Nombre de la persona

• Apellido1: Primer apellido de la persona.

• Apellido2: Segundo apellido de la persona. Permite nulos.

• Fecha Nacimiento: Tipo de dato fecha que indica cuando

nació la persona.

• Tipo Documento: Campo que puede adoptar los valores

"DNI", "Pasaporte" o "Tarjeta de Residencia", e indica qué
tipo de documento identifica a la persona.

• Numero: Numero del documento identificativo (letra

incluida si la hubiere).

• Sexo: Representa el sexo de la persona. Puede tomar los

valores "Masculino" o "Femenino".

La entidad Persona solo se relaciona con las entidades municipio y

pais, en relación exclusiva. Así se sabe su lugar de nacimiento.

La entidad Persona Censo tiene los siguientes atributos.

 • Año Residencia Pais: Año desde el cual la persona reside
en España.

• Año Residencia Comunidad: Año desde el cual la persona

reside en la comunidad autónoma en la que vive.

• Año Residencia Municipio: Año desde el cual la persona

reside en el municipio en el que vive.

• Estado Civil: Campo que indica el estado civil de la

persona. Puede tomar los valores "Soltero", "Casado",
"Viudo", "Divorciado" o "Separado".

• Año_censo: Año en que fue realizado el cuestionario al

que pertenecen estos datos.

El resto de información que se guarda sobre la persona (que es

mucha) se recoge a través de diversas entidades y relaciones.

La relación de Persona Censo con Hogar contiene dos atributos, que

son el orden y el parentesco. Una persona puede tener un orden
dentro del hogar, siendo el orden 1 el correspondiente a la cabeza de
familia. Los órdenes que no son 1 no significan nada, solo se guardan
para mantener la consistencia con el cuestionario de Hogar. El orden
es único para cada hogar (sólo puede haber un orden 1 en cada
hogar, un orden 2, etc.). El atributo parentesco significa la relación
que tiene esa persona dentro del hogar con la persona de orden 1 (la
cual no tiene parentesco). El atributo parentesco posee el dominio de
valores que se indican en el cuestionario.

Mucha información sobre la procedencia de la persona se recoge a

través de diversas relaciones de esta con las tablas Municipio y Pais.
Hay una relación llamada nacionalidad de Persona con Pais, y el resto
son 4 relaciones excluyentes dos a dos. Esto es, si se va por una
relación no se puede ir por la otra. Esto lo hacemos porque en los
cuestionarios, en la siguiente información se pide rellenarla para un
municipio en concreto o para un país en concreto, pero nunca para
ambos (si se pone municipio el pais se supone España, puesto que la
tabla Municipios solo contiene municipios españoles). Los 2 pares de
relaciones excluyentes con Municipio y Pais son "residencia censo
anterior" y "residencia anterior". También existe la relación de
"nacionalidad" con Pais (diferente a la de lugar de nacimiento).

El resto de relaciones están pensadas para satisfacer a las preguntas

del cuestionario sobre estudios y trabajo de la persona. Hay cierta
información que se pregunta varias veces en sitios diferentes (como
el nivel de estudios), y algunos campos solo se han de rellenar bajo
ciertas condiciones, por eso es necesario separar todo esto en
entidades separadas.
La entidad "Nivel estudios" recoge la información sobre los estudios
ya acabados por la persona, y se relaciona con la entidad
TipoEstudios, que recoge que tipo de estudios son los que tiene. Estas
entidades recogen la información de las tablas 3 y 4 del cuestionario
de hogar.

La entidad "Estado" recoge la información de la tabla 7 del

cuestionario de Hogar. Recoge la situación laboral actual de la
persona.

Las siguientes entidades corresponden a los datos del cuestionario

individual, el cual solo se podrá rellenar si el valor de la persona para
la entidad "Estado" (una persona solo tiene un estado) es 1 ó 2.

En ambos casos, una persona estará relacionada con la entidad

"Datos Trabajo-Estudio", que recogerá los valores de las preguntas
1,2,3 y 4 del cuestionario individual (datos sobre como es el viaje al
trabajo/lugar de estudio). Contiene el atributo "año_censo", que indica
en qué año se hizo el cuestionario. Se relaciona con la entidad Viajes,
que contiene los atributos "tiempo" que representa la duracion del
viaje (toma los valores concretos del cuestionario) y "numero viajes",
que representa el valor de viajes de ida y vuelta que se hacen de
casa al trabajo (3 como máximo, aunque sean más). Estos campos
tendrán valores por defecto porque a veces no se rellenan, en cuyo
caso valdrán 0 (acorde con la semántica del problema, ya que si se
trabaja en el domicilio no hay que rellenarlos). Datos Trabajo-Estudio
también se relaciona con la entidad "Medios de Transporte", para
recoger el modo en que se hace el viaje.

Si el estado de la persona es 1, se tendrá en cuenta la entidad

"Estudios Actuales", que será el equivalente a la pregunta 5 del
cuestionario individual. Una persona puede tener 3 estudios actuales.

Si el estado de la persona es 2, se tendrá en cuenta la entidad "Datos

Trabajo". Esta entidad se relacionara con una tabla de ocupaciones y
con otra de actividades, tal y como se indica en las preguntas 6 y 8
del cuestionario individual. Por si la ocupación o la actividad no se
encontraran en las tablas, se habilitan dos campos en la entidad
"Datos Trabajo" llamados "descripción actividad" y "descripción
ocupación" que serán nulos si los datos estaban en la tabla que se
ofrece con el cuestionario. "Datos Trabajo" tendrá también un campo
"horas semanales" (horas que se trabaja a la semana), un campo
"año_censo" que guardará el año en que se hizo el cuestionario y se
relacionará con la entidad "Situación Profesional", que contendrá los
campos de la pregunta 7 del cuestionario individual.

3 – REGLAS DE NEGOCIO

• En la entidad Vivienda, el campo "Tipo Calefacción" solo

puede valer nulo si el campo "Calefacción" vale "no".

• Una Vivienda solo puede tener un combustible (relación

 Vivienda con Tipos Combustible) solamente si el campo
"Calefacción" para esa vivienda vale "sí".

• Para que una persona pueda estar relacionado con

"Estudios Actuales", el valor de la persona en la entidad
"Estado" ha de ser 1 (que corresponde con el 1 de la tabla 7
del cuestionario de Hogar)

• Para que una persona pueda estar relacionada con "Datos

Trabajo", el valor de la persona en la entidad "Estado" ha de
ser 2 (que corresponde con el 2 de la tabla 7 del cuestionario
de Hogar)

• Para que una persona pueda estar relacionada con "Datos

Trabajo-Estudio" (entidad que recogía la información sobre el
viaje hacia el lugar de trabajo-estudio), el valor de la persona
en la entidad "Estado" ha de ser 1 ó 2 (que corresponde con
los valores 1 y 2 de la tabla 7 del cuestionario de Hogar).

• Una persona solamente puede tener un parentesco si su

orden en el Hogar es distinto de 1.

• El campo "descripción actividad" dentro de la entidad

"Datos Trabajo" solo puede valer null si no existe una
actividad relacionada a esos Datos de Trabajo

• El campo "descripción ocupación" dentro de la entidad

"Datos Ocupación" solo puede valer null si no existe una
ocupación relacionada a esos Datos de Trabajo.

• Un "Nivel de Estudios" solamente puede tener asociado

un "Tipo de estudios" si el valor de ese nivel de estudios está
entre 6 y 10 (pregunta 3 del cuestionario de hogar). (Esto no
se controlará mediante trigger, sino mediante la propia
inserción de los datos)

• Un hogar solo puede tener segunda vivienda si su valor de

"días en segunda vivienda" en la relación entre hogar y
vivienda es mayor que cero.

• Una persona solo puede estar en un curso para la

empresa si se encuentra ocupado

4 – ACERCA DE LA CORRECCIÓN QUE NOS FUE ENTREGADA

Se nos comenta que deberíamos quitar el campo "descripción de

actividad/ocupación" en la entidad Datos Trabajo debería eliminarse,
e introducirse una actividad/ocupación nueva en caso de ser
necesario, ya que en la mayoría de las ocasiones va a valer nulo. Lo
que nos dicen es cierto, pero creemos que merece la pena tener ese
campo que valdrá nulo casi siempre. Si insertamos una
ocupación/actividad nueva en las tablas que no venga en el
formulario, corremos el riesgo de repetir información, y de no ser
exactos con la respuesta del censado (si dos censados tienen 2
actividades prácticamente idénticas se les asociaría un campo nuevo,
y lo mejor es recoger exactamente lo que han dicho, para evitar los
problemas descritos). Así pues, creemos que es mejor dejar ese
campo como está, aunque vaya a valer nulo en la mayoría de las
ocasiones.

Lo siguiente que se nos sugiere es la eliminación de uno de los

campos referentes a calefacción, ya que en el cuestionario se nos da
a escoger entre 4 posibles valores sin más complicaciones. Si hemos
puesto un campo calefacción (que vale si o no) y otro tipo_calefacción
(que indica que tipo de calefacción hay, en caso de haberla), es para
poder realizar mejores consultas. Tal y como lo tenemos, se puede
buscar quién tiene calefacción y quien no consultando sobre un
campo, de la otra manera habría que tener en cuenta a los que no
tienen calefacción pero sí estufa, y la consulta se haría más
complicada. Creemos que por la agilidad de las consultas es mejor
así.

En cuanto a la siguiente consideración, es cierto que en el modelo

Entidad/Relación se nos había olvidado incluir la relación excluyente
"lugar de nacimiento" entre Persona-País y Persona-Municipio. En la
versión que entregamos ahora la incluimos.

Respecto a lo que se nos indica sobre el cuestionario de datos

patronales, que no hemos incluido la información relativa al cambio
de hogar de una persona, es correcto. Sin embargo lo hemos hecho
por un motivo, y es que esos datos proceden del registro de
empadronamiento, que no tiene relación con los datos del censo de
habitantes que se recogen en esta base de datos. En caso de tener
que rellenar esos datos, sería que la persona en cuestión no vive
donde está empadronada, y esta nueva información se recogería por
el registro de empadronamiento, no por el censo de vivienda, que es
lo que estamos implementando.

Por último se nos comenta que no es necesaria la entidad Parentesco.

Discrepamos con esta observación, ya que si se incluye un atributo
en la relación como se nos sugiere, para la información "Padre"
alguien podría insertar "Padre", y a lo mejor otra persona puede
insertar "Progenitor". Así pues, tendríamos la misma información con
dos nombres distintos, y ello haría que los datos reflejados en las
consultas fueran incorrectos. Consideramos que para favorecer la
consistencia e integridad de la información es necesario mantener
estrictamente acotados los tipos de parentesco existentes mediante
la entidad Parentesco.

5 – PASO DEL MODELO CONCEPTUAL AL FÍSICO

Una vez desarrollado el modelo conceptual de nuestra base de datos,

el siguiente paso es pasar al modelo físico.

Para ello nos hemos ayudado de la herramienta de Microsoft Visio,

que permite generar una serie de tablas, definirles campos, foreign
keys, dominio de datos y primary keys, y te genera el script de
creado de la base de datos automáticamente.

En cuanto a los tipos de datos de los atributos hay algunas

consideraciones a tener en cuenta. La primera, es que se han creado
algunos tipos de datos nuevos, correspondientes a los campos de
tablas que tienen valores fijos (como por ejemplo tipo_calefacción).
Son siempre datos char, y recogen la información de los cuestionarios
fielmente, evitando así posibles errores de coherencia.

Además, hemos preferido usar el tipo de datos bit para respuestas del
tipo sí o no en lugar de un char(1), puesto que creemos que el
significado se entiende a la perfección igualmente, y el ahorro de
memoria es significativo.

En este punto también consideramos la distribución de nuestra base

de datos en diversos grupos de ficheros. Hemos decicido crear 4
grupos de ficheros:

- Uno para la tabla de log de errores de la que hablaremos más

adelante, la cual creemos que puede tener un crecimiento muy
grande, cuyos datos ocupan mucho (son char de 300), así que es
conveniente tenerla en un grupo de ficheros aparte.

- Otro para las tablas maestras o estáticas, es decir, las que contienen
las opciones de los cuestionarios, cuyo crecimiento va a ser
prácticamente nulo, pero que sus datos ocupan mucho.

- Otro para las tablas permanentes, vivienda y persona, que tendrán

un crecimiento anual y que no dependen del censo. Son tablas que
guardan bastante información, pero que son un poco independientes
de las demás por el hecho de no recoger información del cuestionario,
por ello es mejor agruparlas juntas.

- Por último, un filegroup para todas las tablas que contienen la

información de las encuestas, es decir, persona_censo,
vivienda_alojamiento y hogar, así como las que contienen un atributo
año censo y las tablas de relación. Cada tupla de persona_censo
ocupa un total de 124 bytes (correspondientes a 16 columnas tipo int,
a 4 bytes cada una, y dos columnas de tipos definidos por nosotros,
una de ellas ocupa 20 bytes y la otra 40 bytes). No es un tamaño muy
elevado, puesto que casi todo son foreign keys. y es una tabla que
solo crece cada 10 años, no como la persona anterior. Se estima que
hay 44 millones de personas en España, luego la tabla persona_censo
crecería 520'3 MB cada diez años, lo cual es un tamaño mucho menor
a un crecimiento anual, y por eso se agrupa en un fichero distinto.
Con hogar se ha seguido el mismo razonamiento, cada tupla ocupa
42 bytes, a 15 millones de hogares hace un crecimiento de 60 MB
cada diez años. En general, en este grupo de ficheros irán las tablas
con un crecimiento fijado por cada diez años.

Todo lo correspondiente al creado de la base de datos se halla en el

fichero GeneraDB.sql

Una vez decididos los tipos de datos a usar, el siguiente paso es

meter información en la base de datos, para poder realizar las
pruebas pertinentes. El llenado de las tablas con los datos se
encuentra en el fichero Llenado-DB.sql.

Lo siguiente que nos planteamos fue como recoger fielmente las

reglas de negocio. Creemos que usar triggers que echen para atrás la
inserción no es una opción válida, pues aunque haya alguna regla que
no se cumpla, puede ser debido a un error de la máquina al leer el
cuestionario, o a un mero error humano del sujeto, pero su
información ha de estar presente obligatoriamente en la BD (aunque
no sea correcta).

Guardar información no válida sin llevar algún tipo de registro

tampoco parece muy adecuado, así que nuestra solución ha sido
crear una tabla llamada tablaLogDeErrores en la que se apunte
exactamente cual ha sido el error cometido, y la tupla en la que se
encuentra ese error. La inserción de datos en esta nueva tabla se
realiza a través de triggers, que en lugar de echar para atrás la
transacción, apuntan el error en la tabla de log y meten los datos
erróneos en la BD, para que así figure toda la información.

Los triggers se encuentran en el fichero triggers.sql

En cuanto a los índices, aparte de los clustered que se crean por

defecto en las primary keys, hemos creido oportuno crear los
siguientes:

- Índice unclustered sobre el campo "nombre" en las tablas municipio

y provincia. Creemos oportuno poner un índice clustered sobre esos
campos porque se van a realizar un montón de búsquedas por
municipios/provincias, siendo clustered para que los campos se
ordenen y sea más eficiente, puesto que el tamaño de estas tablas va
a ser enorme. Para ello habría que poner a nombre como primary
key, lo cual no sería posible, porque hay pueblos en provincias
diferentes con el mismo nombre. Así que escogemos una opción
válida pero menos eficiente, que es hacerlo unclustered.

- Indice non-clustered sobre el campo sexo en persona. Sin duda

muchas de las búsquedas se realizarán por el sexo de la persona, así
que creemos que es necesario tener un índice en ese campo. Como
solo hay dos valores posibles no creemos necesaria la inclusión de un
índice clustered que ocupa más en memoria.