ejercicio

Planteamiento del problema

Imaginemos que trabajamos en un hospital y se nos pide hacer el modelo de la base de datos para registrar el kardex de un paciente atendido por enfermería, entonces debemos modelar las tablas respectivas, siendo este un kardex:

Resolviendo…

Para resolver esto, debemos ver qué entidad, objeto o concepto se encuentran involucrados en el kardex, así que analizamos.

Podemos ver que hay campos como nombre del paciente, por lo que podemos deducir que una de las tablas es paciente. Entonces analizamos todos los demás campos para ver cuáles sí pertenecen al paciente, pero no hay más campos relacionados con ingreso…

• Entonces tenemos que al paciente le pertenecen campos como Nombres, CC, Edad. Algo que se podría pensar es que la fecha de ingreso también vaya a esta tabla, pero no va, porque este atributo terminaría siendo efímero, lo que para agregar un segundo dato tendrías que romper la regla de normalización. Es decir, que si después el paciente vuelve, esta fecha se va a sobrescribir. Otro dato es que no es ideal crear la columna de edad, ya que esta debería ser calculada a partir de la fecha de nacimiento.
• En cuanto a las alergias, un paciente puede tener 0, 1, 2 o más alergias, así como una alergia puede ser tenida por muchos pacientes. Entonces crearemos un catálogo de alergias, con un id, un nombre de alergia y otra tabla que relacione pacientes con alergias.

Para una segunda tabla podemos usar nuestra columna huérfana de fecha de ingreso para crear una tabla ingreso, que podríamos nombrar tabla ingreso.

• Entonces tenemos la tabla de ingreso con la columna de fecha de ingreso, un id de ingreso y el que ingresó, que será el paciente como foráneo.

Podemos ver que otro campo es cama, y que de esta no se menciona nada más que el número de cama en el kardex, así que simplemente la llamaremos cama.

• Entonces tenemos una tabla llamada cama, que naturalmente tendrá de atributo el id de la cama, tipo de cama (lo supondremos) y estado. También, como en una cama seguramente se le asignó en la entrada, llevaremos una llave foránea de cama a la tabla de ingreso. ¿Y por qué llevamos una fk de cama a ingreso y no al revés? Porque en un ingreso la cama va a ser ocupada por un paciente, y no van a usar muchos pacientes la misma cama en un ingreso. También se podría decir que es por la regla de que la llave foránea siempre viaja a la tabla que representa los Muchos (N).

Entonces ahora, como otro campo que no modelamos aún es el diagnóstico, y un diagnóstico tiene una categoría.

• Podemos crear una tabla de Catálogo de diagnóstico para tener la lista de posibles diagnósticos (lista de enfermedades).
• En tanto a diagnóstico, puede haber muchos diagnósticos para el ingreso, así que otra vez usamos la regla de que N obtiene la fk. Entonces tendríamos la tabla de ingreso-diagnóstico con una fk de ingreso, una fk del catálogo de diagnósticos, una fecha de registro para el diagnóstico (lo vamos a suponer, no nos lo dicen en el kardex), un tipo de diagnóstico (tampoco lo especifica, pero lo vamos a suponer, que puede tomar valores como principal o secundario).

Entonces ahora el campo que nos falta es nivel de independencia, que este se refiere a qué tan independiente es el paciente y aquí hay una evolución. Es decir, un paciente puede ser muy dependiente y luego mejorarse y dejar de ser dependiente; este campo evoluciona con el tiempo. Podría ser una tabla como un historial, en el que también podríamos involucrar el estado del paciente.

• Para el nivel de independencia, como solo hay pocos posibles estados y para evitar que un usuario ponga un texto que no sea el estándar, podemos crear la tabla catálogo de nivel de independencia.
• Podemos crear una tabla evolución estado paciente con un id de evolución, un id del ingreso, una fecha y hora de registro, una fk de la tabla de catálogo de nivel de independencia, y en cada salto de evolución seguramente se cambiará la dieta y el oxígeno, por lo que pondremos esas columnas aquí.

Hasta este punto lo que nos falta es analizar esas dos tablas.

En la primera tabla se puede ver que hay muchas filas para las columnas de Motivo de consulta médica. También se ve la fecha y también apoyos diagnósticos/laboratorios. Entonces, en el motivo, para ir a consulta no solo se debe tener 1 motivo, puede haber más. Y para fecha, muy probablemente va la fecha en que se hizo la consulta médica. Y diagnóstico o laboratorios debe ser muy probablemente los análisis que recibió el paciente, o ambos en el mismo campo… La fecha: solo vas una vez y te dan uno o varios diagnósticos y recetas, pero hay múltiples cuadros para la fecha, lo que significa que los diagnósticos pueden haber sido evaluados una vez para cada cierta fecha, así como un historial.

• Entonces tenemos que sería una tabla de consulta médica, con id, una llave foránea de ingreso (porque en cada ingreso se tuvo una consulta), fecha de consulta, motivo de la consulta y también los análisis.
• Entonces, para tener algo normalizado, podemos crear una tabla catálogo_analisis que tuviese un id análisis y un nombre, y otra tabla que una tanto consulta y análisis para mantener la normalización.

En la segunda tabla se ven las columnas de medicamento, dosis, frecuencia y horario, y todo esto en la tabla de tratamiento farmacológico. Podemos pensar que el tratamiento se asigna en un ingreso. Y en tanto a los horarios, se suelen manejar en formatos de cada 8 horas o algo como 08:00 - 16:00 - 24:00, lo que rompería la normalización.

• Entonces primero crearemos una tabla de medicamentos, con un id, un nombre y por ejemplo la presentación, para ver si es tableta o ampolla u otro.
• Entonces tenemos que tendremos una tabla de tratamiento farmacológico con un id, un id de ingreso como fk, un id de medicamento como fk, la dosis, la frecuencia y hora de inicio (que si bien no está en la tabla, sí se puede asumir que es necesario).
• Para el horario tomaríamos una nueva tabla de tratamiento horarios en la que toma, que tendría su id, su fk de tratamiento y la hora que está programada, y quizás el estado si se administró o no.

Resultado

TABLAS MAESTRAS (Catálogos y Entidades Fuertes)

• Paciente

• id_paciente (PK)

• nombres

• cc (este si significa cedula ciudadana, entonces debe ser unica)

• fecha_nacimiento

• Cama

• id_cama (PK)

• numero_cama

• tipo

• estado

• Catalogo_Alergia

• id_alergia (PK)

• nombre_alergia

• Catalogo_Diagnostico

• id_diagnostico (PK)

• nombre_diagnostico

• codigo_cie10

• Catalogo_Nivel_Independencia

• id_nivel (PK)

• descripcion

• Catalogo_Analisis

• id_analisis (PK)

• nombre_analisis

• Catalogo_Medicamento

• id_medicamento (PK)

• nombre_medicamento

• presentacion

TABLAS TRANSACCIONALES Y PIVOTES (Relaciones)

• Paciente_Alergia

• fk_paciente (PK, FK)

• fk_alergia (PK, FK)

• Ingreso

• id_ingreso (PK)

• fk_paciente (FK)

• fk_cama (FK)

• fecha_hora_ingreso

• Ingreso_Diagnostico

• id_ingreso_diag (PK)

• fk_ingreso (FK)

• fk_diagnostico (FK)

• fecha_registro

• tipo

• Evolucion_Estado_Paciente

• id_evolucion (PK)

• fk_ingreso (FK)

• fecha_hora_registro

• fk_nivel_independencia (FK)

• dieta

• oxigeno

• Consulta_Medica

• id_consulta (PK)

• fk_ingreso (FK)

• fecha_consulta

• motivo_consulta

• Consulta_Analisis

• fk_consulta (PK, FK)

• fk_analisis (PK, FK)

• resultado_observacion

• Tratamiento_Farmacologico

• id_tratamiento (PK)

• fk_ingreso (FK)

• fk_medicamento (FK)

• dosis

• frecuencia

• fecha_hora_inicio

• Tratamiento_Horarios

• id_horario (PK)

• fk_tratamiento (FK)

• hora_programada

• estado_administracion