Vall d’Hebron Institut de Recerca (VHIR) Institut d’Investigació Sanitària acreditat per l’Instituto de Salud Carlos III (ISCIII)

BASES DE DATOS RELACIONALES EN LA CLÍNICA

Alex Sánchez y Santi Perez-Hoyos Unitat d’Estadística i Bioinformàtica (UEB) 18-19/06/2014

1

Contenido • • • • • •

Introducción: Quien, que, que no… Bases de datos relacionales. Acceso y recuperación de la información. Problemas con las bases de datos. Directrices para el manejo de datos. Conclusiones.

http://ueb.ir.vhebron.net/bdclinica 2

La Unitat d’Estadística I Bioinformàtica

http://ueb.vhir.org 3

Introducción • Todos los procesos en que participamos implican gestión de información. • Las bases de datos y los

sistemas para gestionarlas permiten

un manejo eficiente de la información.

Bases de datos • Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. • Ejemplos – Contactos del móvil – Pacientes del hospital – Datos de un estudio clínico

5

SGBD • Un sistema gestor de bases de datos (SGBD) es un programa para la – [creación] y – administración (entrada, edición, salida)

de datos de forma rápida y estructurada. • Ejemplos [http://es.wikipedia.org/wiki/Sistema_de_gestión_de_bases_de_datos]

– Access (MS), Base (LO), Filemaker – MySQL, PstgreSQL, Oracle, –…

6

Qué/Que no • En esta sesión – Presentamos algunas ideas para diseño de bases de datos relacionales de tipo “personal” – Ilustramos con ejemplos como llevarlo a cabo. – Valoramos algunos problemas que conlleva la mala praxis en la gestión de los datos

• NO discutimos – Bases de datos pre-existentes en el entorno clínico u hospitalario. – Aspectos legislativos o de regulación.

7

Un caso de estudio • The “Infant Jaundice Study” – Estudio de cohorte (nested double cohort). – Sujetos: Niños de 5 años • con ictericia neonatal o sin ella • seleccionados al azar • de igual edad.

– Variable predictiva: Presencia/Ausencia de Ictericia – Variable respuesta: Puntuaciones neurofisiológicas (IQ [55145]). Newman, T. B., P. Liljestrand, et al. (2006). "Outcomes among newborns with total serum bilirubin levels of 25 mg per deciliter or more." N Engl J Med 354(18): 1889-900.

8

Datos del estudio • Unos 400 niñ@s

– Nombre, Fecha nac., Sexo, Etnia, Raza

• 5 médic@s para examinarlos. • Unos 700 exámenes neurofisiológicos – Fecha examen, Peso, Altura, Edad, IQ

• Los examinadores no se repiten nunca. • Si el niño ha fallecido antes de los 5 años se registra su edad y circunstancia de la muerte. 9

10

Como almacenar los datos • Paso 0: decidir un formato para almacenar los datos. • Dos opciones obvias – Hoja de cálculo o “base de datos” de SPSS – Base de datos relacional

11

Aproximación “naïf” • Usar hoja de cálculo  Importar SPSS/R Intuitivo y directo pero... Dificil de compartir datos entre usuarios Integridad de los datos difícil de mantener Un “ordenar” mal aplicado deshace la BD

Poco control sobre pequeñas variaciones Sánchez Sanchez SANCHEZ Puede aceptar un 30-02-2012

Mala gestión de los datos redundantes Nombre o dirección repetidos en muchas filas 12

Alternativa: Bases de datos relacionales • Colección de tablas parecidas a hojas de cálculo en donde – Filas = registros = “entidades” – Columnas = características = “atributos”

• En cada tabla: – Columna con un valor único: clave primaria – Columna con valor de clave primaria de otra tabla: clave externa. – Las tablas pueden relacionarse a través de sus claves

13

Tabla de sujetos del estudio • Común a cualquier estudio. • Nombre, Fecha. Nac., Sexo, Afectado, … • Clave principal? – DOB o Nombre estan repetidos – Mejor crear una clave única y artificial para cada registro.

Clave principal • Asignando una ID distinta a cada participante se garantiza la identidad única de cada sujeto en el estudio.

Las variables del estudio (1) • Mediciones realizadas sobre los sujetos – Pueden incluirse en la tabla si hay tan sólo una por sujeto. – Puede ser recomendable mantenerlas aparte si cambian dinámicamente a lo largo del estudio. – No es recomendable incluirlas en esta tabla si puede haber más de una (en nº variable) por sujeto.

16

Sujetos y variables juntos

17

De una a varias tablas • Si el número de campos crece en exceso – Puede ser conveniente fraccionar la tabla en varias más pequeñas y homogéneas.

• Si aparecen medidas repetidas en número variable o fijo por sujeto – Puede ser conveniente almacenarlas en una tabla relacionada

18

Lo que no hay que hacer

…

19

Tampoco hay que duplicar datos

• Al duplicar nombres o fechas  posibles errores • El ID de sujeto no es único para esta tabla. • Los sujetos sin examen no aparecen

Solución : Normalización Relación “uno-a-muchos”

• La tabla con información redundante se descompone en dos tablas menores enlazadas por una clave que es: – externa en la tabla “hija”. – principal en la tabla “padre”

Definir una relación una-a-muchos

Otras formas de relación • La relación “uno-a-muchos” aparece fácilmente. • Sugiere que pueda haberlas – “uno-a-uno” – “muchos-a-muchos”

23

Relación “uno-a-uno”

• Algunos campos son propios del sujeto pero sólo unos pocos lo presentan. – La mayoría de los sujetos no tienen valores para ellos – Se desperdicia espacio en la base de datos

Relaciones “uno-a-uno”

• Si creamos una tabla aparte eliminamos los campos vacíos y el gasto de espacio

Una BD relacional

26

Integridad referencial • Un buen SGBD mantiene la integridad referencia, es decir: – No asigna revisión a pacientes inexistentes, – No les asigna un doctor no registrado, – No permite eliminar un paciente sin antes borrar sus revisiones,

• Una base de datos con integridad referencial reduce al mínimo la necesidad de depurar y limpiar la BD después de introducir los datos.

27

La base de datos final

28

Algunas ideas más • Campos calculados – No hay que almacenarlos sino calcularlos

• Conceptos básicos – Diccionario de datos – Tipos de datos – Dominios

• [Las formas normales de los datos]

29

¿Campos calculados?-No gracias • Muchos valores son calculables a partir de otros campos – Duración tr.= Fecha Fin Tr- fecha Inicio Tr.

• Los SGBD permiten obtenerlos dinámicamente en vez de definirlos como campos – Se actualizan si cambian los valores en que se basan.

30

No usar campos calculados!

• Un campo como “edad en meses” se debería evitar pues no se actualiza si cambia la fecha de edad.

Diccionarios, Tipos y Dominios de datos

32

Entrada y salida de información Lo hacen los SGBD, no las BD!!!

Manejando la información • Un usuario quiere manejar sus datos, – Entrar y modificar datos – Verlos, Ordenarlos, Seleccionarlos, – Extraer o listados o exportarlos.

• La mayoría de las BD permiten extraer información mediante consultas • Algunos SGBD permiten – La entrada de datos mediante formularios. – El listado de datos mediante informes. 34

Consultas o “queries” • La ventaja de un sistema bien hecho basado en múltiples tablas es la posibilidad de extraer la información de muchas formas. – “Nombre y edad de todos los sujetos examinados entre enero y febrero del 2010” (Siendo muy específico no tiene sentido crear una tabla para esto) 35

Consulta en access o SQL

• SELECT Baby.SubjectID, Baby.DOB, Exam.ExDate FROM Baby INNER JOIN Exam ON Baby.SubjectID = Exam.SubjectID WHERE Exam.ExDate Between #1/1/2010# And #2/28/2010# ORDER BY Exam.ExDate;

Resultado de la consulta • Los resultados de una consulta son como “tablas virtuales” – No existen físicamente – Creadas dinámicamente

• Pueden exportarse como tablas o hojas de cálculo.

Una consulta de actualización

38

Resultado: valores calculados

39

Resumiendo: directrices básicas 1. 2. 3. 4. 5. 6.

Establecer las tablas de la bases de datos y las relaciones correctamente desde el principio. Establecer y seguir las convenciones de nombres para las columnas y tablas. Obtener información de base demográfica y clínica sobre los miembros de la población de estudio a partir de bases de datos informáticas existentes. Minimizar el grado en que las mediciones de estudio se registran en formularios de papel. Utilizar convenciones estándar de entrada de datos. Realizar copias de seguridad de la base de datos con regularidad.

40