7 Modelamiento de datos y datos ordenados

7.1 Objetivos

En este capítulo veremos:

  • Conceptos básicos del modelamiento de datos relacionales y datos ordenados (tidy data).
  • Como diseñar y crear tablas de datos efectivas.

7.2 Beneficios de los sistemas de datos relacionales

  • Poderoso sistema de filtrado y búsqueda.
  • Manejo de sets de datos grandes y complejos.
  • Obliga a la integridad de los datos.
  • Disminuye los errores producto de las actualizaciones redundantes.

7.3 Organización de datos

Planilla excel infernal.

Figure 7.1: Planilla excel infernal.

##3 Tablas múltiples

Múltiples tablas en una misma planilla. Otro caso de un excel infernal.

Figure 7.2: Múltiples tablas en una misma planilla. Otro caso de un excel infernal.

##3 Observaciones inconsistentes

Observaciones diferentes en una misma fila de la tabla. Otro caso de un excel infernal.

Figure 7.3: Observaciones diferentes en una misma fila de la tabla. Otro caso de un excel infernal.

7.3.1 Inconsistencia en las variables

Variables diferentes en la misma columna.

Figure 7.4: Variables diferentes en la misma columna.

7.3.2 Estadísticas y sumas al margen

Valores que pueden ser calculados partir de los datos de la tabla. Otra mala práctica.

Figure 7.5: Valores que pueden ser calculados partir de los datos de la tabla. Otra mala práctica.

7.4 Modelamiento de datos adecuado

7.4.1 Datos De-normalizados

En la figura 7.6 se presenta una tabla donde existen diferentes entidades medidas o muestreadas que se combinaron en una misma fila.

Valores obtenidos en diferentes entidades en la misma fila.

Figure 7.6: Valores obtenidos en diferentes entidades en la misma fila.

En el ejemplo presentado en la figura 7.6, se puede ver como cada columna tiene información tanto de los sitios (site) donde se registraron las observaciones, así como de 2 individuos, aparentemente de diferentes especies, que fueron encontrados en el sitio. Estos son datos no estan normalizados.

La gente se refiere comúnmente a esto como formato ancho o de mantel de cocina, porque las observaciones están repartidas a lo ancho de las columnas. Nótese que si encuentra una nueva especie en un muestreo, tendríamos que agregar una nueva columna en la tabla. Esto es muy difícil de analizar, entender y mantener.

7.4.2 Datos tabulares

Observaciones. Una forma mucho más efectiva de modelado de datos es organizando las observaciones acerca de cada tipo de entidad en su propia tabla. Esto resulta en:

  • tablas separadas para cada entidad medida.
  • Cada fila representa una única observación de la entidad.
  • Las observaciones (filas) son únicas.
  • Esto es lo que se conoce como datos normalizados (tidy data).

Variables. Además, en el caso de datos normalizados, podemos esperar que las variables estén organizada de tal forma que:

  • Todos los valores en una columna representan lo mismo.
  • Todas las columnas pertenecen a la misma entidad observada (ej. fila).
  • Cada columna representa o una variable identificadora o una variable medida.

En la figura 7.7 hay un ejemplo de datos normalizados, la primera tabla se refiere a la colección de datos sobre los individuos de varias especies y la segunda tabla son las observaciones que contienen las propiedades de los sitios donde las especies estaban presentes.

Ejemplo de tablas con datos normalizados.

Figure 7.7: Ejemplo de tablas con datos normalizados.

7.5 Claves primarias y foráneas

Cuando se usan datos normalizados, es común usar identificadores únicos para hacer referencia a observaciones particulares, esto nos permite hacer uniones entre dos o más tablas. Los dos tipos de identificadores que se usan comúnmente con datos relacionales son:

  • Clave primaria: Identificador único para cada una de las observaciones de la entidad, es uno por fila.
  • Clave foránea: Hace referencia una clave primaria que está en otra tabla (referencia para unir).

Por ejemplo, en la segunda tabla de la figura 7.8, la columna site es la clave primaria (primary key) de esa tabla. La puede identificar como tal porque es un identificador único para una observación realizada en un sitio y que corresponde a una fila de la tabla. En la primera tabla, sin embargo, la columna sitio (site) es una clave foránea (foreign key) que hace referencia a la clave primaria presente en la segunda tabla. Esta relación nos permite identificar que la primera medición de la altura (height) para la especie DAPU se realizó en el sitio con el nombre Taku.

Explicación de la relación entre clave primaria y foranea entre dos tablas con datos normalizados.

Figure 7.8: Explicación de la relación entre clave primaria y foranea entre dos tablas con datos normalizados.

7.5.1 Modelo de Relación-Entidad

Un modelo de Relación-Entidad nos permite representar en forma compacta la estructura de las tablas en una base de datos relacional, incluyendo las claves primarias y foráneas de cada una de las tablas.

Representación gráfica de una relación-entidad de dos tablas, incluyendo las claves con que se unen..

Figure 7.9: Representación gráfica de una relación-entidad de dos tablas, incluyendo las claves con que se unen..

En el modelo presentado en la figura 7.9, se puede ver que cada sitio en la tabla SITES debe tener uno o más observaciones en la tabla PLOTOBS, donde cada PLOTOBS tiene un y solo un SITE.

7.6 Combinando datos

Frecuentemente, los análisis de datos requieren que se combinen estas tablas que se manejan en forma separada. Esto se puede hacer de múltiples formas y estas uniones van a depender de como las tablas estén relacionadas (fig. 7.10).

Cuando se conceptualizan las uniones, uno puede pensar en dos tablas, una a la izquierda (left) y otra a la derecha (right). La unión más común (generalmente usada) es cuando se combina un subgrupo de filas que tienen parejas en ambas tablas (a la izquierda y derecha): esto se conoce como INNER JOIN (unión interna). Existen otros tipos de uniones posibles. Un LEFT JOIN (unión a la izquierda), toma todas las filas de la tabla a la izquierda y las combina con los datos que se emparejan en la tabla a la derecha. Un RIGHT JOIN (unión a la derecha) es lo mismo, sólo que en este caso se mantienen todas las filas presentes en la tabla de la derecha y se agregan aquellas que tienen parejas en la izquierda. Finalmente, un FULL OUTER JOIN (unión total) incluye todas las filas en ambas tablas, esta unión es raramente de uso práctico.

Las regiones en azul representan las filas que son incluidas en el resultado. Para un INNER join, las filas resultantes son todas las filas en A que tienen una pareja en B.

Figure 7.10: Las regiones en azul representan las filas que son incluidas en el resultado. Para un INNER join, las filas resultantes son todas las filas en A que tienen una pareja en B.

7.7 Guía simple para datos efectivos

7.8 Ejercicio de modelamiento de datos

  • Forme grupos.

Trabajaremos con datos correspondientes a una versión normalizada de datos con capturas comerciales de salmón entre 1878 y 1997 reportadas por Byerly (1999), de ADF&G (Alaska Department of Fish and Game o Departamento de Pesca y Caza de Alaska). El set de datos y las referencias a la fuente original puede ser vista en el archivo de acceso público en: https://knb.ecoinformatics.org/#view/df35b.304.2. Este sitio incluye los metadatos que describen todo el set de datos, incluyendo la descripción de las columnas. Aquí esta la primera tabla de capturas (catch):

Y aquí la tabla que define las regiones (region_defs):

  • Dibuje un modelo RE para las tablas.
    • Indique cuales son las claves primarias y foráneas.
    • ¿Está la tabla catch en una forma normalizada?
      • Si es así ¿Cuál es la entidad (única) que fue observada?
      • Si no ¿Como reestructuraría los datos para que queden normalizados?
  • Dibuje un nuevo diagrama RE mostrando esta estructura de datos re-diseñada
Guí de nomenclatura para el direño de un modelo de Relación-Entidad (RE).

Figure 7.11: Guí de nomenclatura para el direño de un modelo de Relación-Entidad (RE).

Referencias

Byerly, Mike. 1999. “Alaska Commercial Salmon Catches by Management Region (1886- 1997).” KNB. https://knb.ecoinformatics.org/view/df35b.304.2.