Download base de datos - UEB-UAT

Bases de datos relacionales en la
clínica
Alex Sánchez
Statistics and Bioinformatics Research Group
Statistics department, Universitat de Barelona
Statistics and Bioinformatics Unit
Vall d’Hebron Institut de Recerca
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
Y quien es él…
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
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
– Access (MS), Base (LO), Filemaker
– SQL, Oracle
–…
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.
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 predictora: Presencia/Ausencia Ict.
– Variable respuesta: Puntuaciones neurofisiológicas
(IQ [55-145]).
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.
Datos del estudio
• Unos 400 niños
– Nombre, Fecha nac., Sexo, Etnia, Raza
• 5 médicos para examinarlos.
• Unos 700 examenes 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.
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
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
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
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
• Aignando 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.
Sujetos y variables juntos
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
Lo que no hay que hacer …
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-amuchos
Otras formas de relación
• La relación “uno-a-muchos” aparece
fácilmente.
• Sugiere que pueda haberlas
– “uno-a-uno”
– “muchos-a-muchos”
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
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.
La base de datos final
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]
¿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.
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
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.
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)
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
Resultado: valores calculados
Directrices para la gestión de bases
de datos en la clínica
Algunas directrices
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.