RECOMENDACIONES TÉCNICAS PARA LA CREACIÓN DE MODELOS DE DATOS

Transcripción

1 RECOMENDACIONES TÉCNICAS PARA LA CREACIÓN DE MODELOS DE DATOS

2 ÍNDICE Objetivos... 3 Modelo de datos: niveles existentes... 3 Modelo de datos lógico... 3 Normalización... 3 Desnormalización... 4 Tratamiento de valores inaplicables o faltantes... 4 Restricciones de integridad... 5 Creación de dominios... 5 Identificación de elementos... 6 Nomenclatura de campos... 6 Formato de campos... 7 Codificación de los ficheros de datos

3 Objetivos Este documento establece una serie de recomendaciones a la hora de elaborar o evaluar un modelo de datos de cara a la integración de la información en la REDIAM. Modelo de datos: niveles existentes Comúnmente se identifican tres niveles en los modelos de datos, aunque existen otras clasificaciones posibles: Modelo conceptual. Se describe la base de datos desde un punto de vista organizativo, se identifican las entidades participantes en el modelo de datos, sus atributos y las relaciones entre ellas (por ejemplo, un modelo Entidad-Relación). Modelo lógico. Se describe la base de datos tal y como se representa por una tecnología de bases de datos concreta. Por ejemplo, consistirá en una descripción de tablas, columnas y relaciones, en un modelo relacional. Es el concepto más comúnmente usado cuando se habla de modelo de datos. Nivel físico. El nivel más bajo de abstracción describe cómo se almacenan realmente los datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel (archivos de bases de datos, por ejemplo). Generalmente únicamente los administradores de bases de datos y otro personal con perfil técnico informático diseñan y conocen este nivel. Aquí nos centraremos en el nivel lógico. Modelo de datos lógico Normalización La normalización de un modelo de datos consiste en su adscripción a una serie de reglas que persiguen garantizar el diseño de un esquema (una estructura de datos) consistente y sin redundancias, libre por tanto de las anomalías que pueden estar presentes en esquemas no normalizados, y que se manifiestan durante la actualización de la base de datos. Por ejemplo, en un modelo de datos normalizado existirán tablas diccionario para los valores de un campo que se repitan una y otra vez y existirá una relación que asegure que no se introducen valores extraños en el campo. En un modelo de datos no normalizado esas restricciones no se establecen, y por tanto se corre el riesgo de que por desconocimiento o error se introduzcan valores extraños que dificultarán el uso posterior de los datos. Un nivel común de normalización es lo que se denomina tercera forma normal (para más información se puede consultar el artículo de la Wikipedia Normalización de bases de datos). 3

4 Desnormalización La desnormalización de los datos se plantea a menudo como una solución a ciertas dificultades que se presentan con las bases de datos completamente normalizadas: - Necesidad de mejora del rendimiento de la base de datos. Dada la potencia de los equipos informáticos actuales y el ritmo al que crece, salvo en casos de bases de datos muy grandes en las que el rendimiento sea crítico o con una carga de uso muy grande, parece razonable implementar las bases de datos en su forma normalizada a costa de un tiempo adicional de proceso. - Facilitar la utilización de la información, tanto para su explotación mediante aplicaciones (escritorio, servidores de mapas, etc.) como para uso de los técnicos (análisis). En estos casos una alternativa a la desnormalización del modelo de datos es la creación de información de resumen (como ocurre, por ejemplo, con SIOSE). Tratamiento de valores inaplicables o faltantes En la mayoría de los SGBD actuales la información inaplicable o ausente puede ser representada a través de valores nulos. No obstante, la utilización de campos que admiten nulos tiene otros problemas como es una mayor complejidad en las operaciones con datos, lo que conlleva una mayor probabilidad de errores. Por ello es interesante minimizar el empleo de valores nulos. Si la frecuencia de valores inaplicables o faltantes en un campo excede de lo anecdótico, se puede considerar la separación de dicho campo en una tabla aparte. Además, dado que en ocasiones será necesaria la transformación a formatos de datos que no soportan valores nulos (por ejemplo, shapefiles, para la difusión de la información geográfica) la utilización de valores nulos podría generar problemas de interpretación, al transformarse éstos en ceros o cadenas vacías durante la conversión. En esos casos en los que se puedan producir interpretaciones erróneas o cuando el soporte de base de datos no lo permita, se recomienda utilizar valores concretos para la representación de valores inaplicables o faltantes; se deberán seleccionar de tal modo que no puedan confundirse con un dato válido: por ejemplo, para un campo COTA. El uso y el significado de los valores nulos o de los valores concretos seleccionados debe documentarse debidamente en el modelo de datos. Si el campo en concreto utiliza un dominio de valores codificados, se añadirán entradas en el dominio para representar los casos anteriores; se recomienda evitar utilizar los valores 0 y para representar estos casos por lo que se apuntaba anteriormente de la conversión de valores nulos en formatos que no lo soportan. En esos casos se evitará el empleo de valores nulos. 4

5 Restricciones de integridad Las restricciones de integridad son reglas que se establecen para proteger la base de datos, de modo que no pueda llegar a un estado inconsistente. La forma de definir y forzar el cumplimiento de estas reglas dependerá del sistema de gestión de bases de datos que se esté empleando (MS Access, Geodatabase ESRI, Oracle, MySQL, etc.). En cada campo de cada elemento de la base de datos es conveniente definir las reglas de integridad que aseguren la coherencia de los datos: Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir, no admiten nulos. Como caso concreto de éste se cuenta la integridad de entidades: el identificador de una entidad no puede ser nulo, por lo tanto, las claves primarias de las tablas no pueden admitir nulos. En general se recomienda evitar el uso de campos que admitan valores nulos. Restricciones de dominios. Algunos atributos tienen un dominio asociado, que es el conjunto de los valores que el atributo puede tomar (ver el apartado Creación de dominios). Las restricciones de dominios pueden ser un rango de valores (por ejemplo, 0 a 100 en un campo que almacena porcentajes) o una lista de valores codificados (por ejemplo un listado de códigos referidos a usos del suelo). Integridad referencial. Se debe considerar la acción a llevar a cabo cuando se elimina un registro que está siendo referenciado por otro registro a través de un campo común (por ejemplo, borrar una entrada de una tabla de diccionario). De modo general se puede seleccionar dos comportamientos diferentes: o Propagar: se borra el registro deseado y se propaga el borrado a todos los registros que le hacen referencia. o Anular: se borra el registro deseado y todas las referencias que tenía se ponen, automáticamente, a nulo (esta alternativa sólo es válida si el campo correspondiente acepta valores nulos). La elección de una opción u otra dependerá de cada caso concreto. Creación de dominios Los dominios de valores únicos se implementan normalmente como tablas diccionario asociadas. Sólo parece aceptable omitir la creación de la tabla o el dominio en el caso de dominios con un conjunto muy reducido de valores y cuya interpretación sea obvia (por ejemplo: un campo que permite los valores Sí y No, codificados como S y N respectivamente). En cualquier caso el dominio debe quedar debidamente documentado en la descripción del modelo de datos indicando el listado de posibles valores o la tabla que los recoge. 5

6 Identificación de elementos Es importante utilizar nombres descriptivos, evitando las codificaciones numéricas o crípticas como P6948_T25670_UC87_LEY. Se recomienda ser consistente con el criterio seguido para separar las palabras; por ejemplo se puede utilizar guiones bajos ( _ ), como en RED_ESTACIONES_MEDICION, o bien poner en mayúscula la primera letra de cad palabra y en minúscula el resto como en RedEstacionesMedicion. En los nombres de tablas es importante no emplear tildes, diéresis ni otros caracteres especiales (Ñ, Ç, &, ) y reemplazarlos por otros caracteres de manera que se mantenga la legibilidad (N, C, Y, la misma vocal sin tilde o diéresis ). Esos caracteres pueden ocasionar problemas a la hora de utilizar la información, dependiendo del software empleado. Como se ha indicado, es importante que el nombre identifique la información para el usuario de la forma más clara e inequívoca posible ya que será la etiqueta que permitirá a éste reconocerla. La fecha (generalmente sólo el año) es un dato a considerar para su inclusión en el nombre de todos aquellos contenidos que no estén sometidos a una actualización continua. Las tablas diccionario (de dominio) pueden identificarse mediante un prefijo, por ejemplo DICC (por ejemplo DICC_UNIDADES_GEOMORFOLOG ). De este modo es más fácil distinguir entre estas tablas y el resto de los datos. Se sugiere proceder de igual manera con las tablas intermedias usadas en las relaciones muchos a muchos, añadiendo por ejemplo el prefijo RELAC (de relación ), por ejemplo RELAC_PROPIETARIO_A_PARCELA). En esos casos es interesante que el nombre describa los elementos que relaciona la tabla, como en el ejemplo anterior; ya que estas tablas se compondrán al menos de dos campos, que son claves foráneas correspondientes a las entidades relacionadas (en el ejemplo PROPIETARIO y PARCELA ), por claridad, se sugiere que el orden de las entidades en el nombre sea el mismo que el de los campos correspondientes en la tabla. Las vistas o consultas pueden identificarse de forma similar, por ejemplo con un prefijo como INFO. Nomenclatura de campos Se debe usar en la medida de lo posible nombres descriptivos, evitando las codificaciones numéricas o crípticas. En los nombres se recomienda emplear sólo mayúsculas, letras (A Z), números (0 9) y guiones bajos para separar palabras ( _ ). Aunque algunos sistemas lo soportan correctamente (por ejemplo MS Access) es importante no emplear tildes ni otros caracteres especiales (Ñ, Ç, &, ) que serán reemplazados por otros caracteres que mantengan la legibilidad (N, C, Y, ). Esto es así para evitar problemas si es necesario un cambio de formato de la información (por ejemplo para su difusión en formatos interoperables). Es importante que los nombres de los campos se diferencien, en la medida de lo posible, dentro de los primeros 10 caracteres. Es decir, que los primeros 10 caracteres sean únicos para cada campo; por ejemplo, en lugar de ESPECIES_NOM, ESPECIES_AUT y ESPECIES_DESCR que comienzan todos por ESPECIES_ se podrían emplear los nombres NOM_ESPECIES, 6

7 AUT_ESPECIES y DESCR_ESPECIES o bien emplear abreviaturas como SPP_NOM, SPP_AUT y SPP_DESCR. Con ello, además de mejorar la legibilidad, se persigue que en una conversión de formato (por ejemplo a shapefile, que es un formato común de información geográfica) los campos mantengan su legibilidad. Siguiendo el ejemplo anterior, en el primer caso el shapefile contendría los campos ESPECIES_1, ESPECIES_2 y ESPECIES_3, en el segundo NOM_ESPECI, AUT_ESPECI y DESCR_ESPECI, y en el último caso los nombres no sufrirían alteración alguna: SPP_NOM, SPP_AUT y SPP_DESCR. Formato de campos Se debe procurar emplear el formato de campo más adecuado para el tipo de dato que almacenan. Por ejemplo, no emplear campos de números en coma flotante para el almacenamiento de valores enteros. Codificación de los ficheros de datos En aquellos formatos en los que sea posible seleccionar la codificación de los ficheros se recomienda utilizar UTF8. 7