PROYECTO TRIMESTRAL BASE de DATOS

ATDF 103 2315

CASO 1
Semana 6
Evaluación sumativa 4 y 5
Facultad de Ingeniería
Curso: ATDF103.202325.3310.EL.ON
Estudiantes:
Ricardo Araya Valenzuela

Grupo :
Fecha : 19 de Noviembre 2023
TABLA DE CONTENIDO

1. Introducción ........................................................................................................................... 3

2. Usuarios finales ......................................................................................................................3

3. Desarrollo................................................................................................................................4

4. Conclusión............................................................................................................................ 15

5. Bibliografía… ....................................................................................................................... 15

2
 1. Introducción
El siguiente informe presenta el proyecto de diseño e implementación de una base de datos para la
"Fundación del Corazón", una institución sin fines de lucro dedicada a la prevención y seguimiento
de pacientes hipertensos en Chile. La iniciativa tiene como objetivo principal desarrollar un sistema
informático que optimice el seguimiento de los pacientes y facilite la gestión de servicios
relacionados con la venta de recetas con precios rebajados. Este proyecto se enmarca en la
necesidad de mejorar la atención a los pacientes hipertensos, contribuyendo así a la reducción de
la morbimortalidad cardiovascular en el país.

Presentación del Proyecto:

La Fundación del Corazón busca implementar un sistema informático eficiente y centrado en datos
para gestionar de manera integral la información relacionada con sus pacientes hipertensos y el
proceso de venta de recetas con descuentos en fármacos. La base de datos propuesta pretende ser
una herramienta clave para mejorar la eficiencia operativa y la toma de decisiones dentro de la
fundación.

Usuarios a Quien Va Dirigido el Proyecto:

Este proyecto está dirigido principalmente a dos categorías de usuarios:

1. Personal Médico y Administrativo:

 Médicos cardiólogos tratantes.

 Personal administrativo encargado del registro de pacientes y ventas de recetas.

 Especialistas encargados del control de inventario y registro de fármacos.

2. Pacientes Hipertensos:

 Personas diagnosticadas con hipertensión que serán beneficiarias de los servicios

de la fundación.

3
Función que Realizará la Base de Datos:

La base de datos cumplirá con las siguientes funciones principales:

1. Almacenamiento Eficiente de Datos:

 Registrar y organizar la información demográfica y clínica de los pacientes

hipertensos.

 Mantener un catálogo actualizado de fármacos disponibles.

2. Facilitar la Compra de Recetas:

 Permitir la compra mensual de recetas con descuentos para los pacientes.

 Calcular automáticamente el descuento aplicado en las recetas.

3. Control de Inventario y Stock de Fármacos:

 Gestionar el inventario de fármacos en las sucursales de la fundación.

 Registrar las compras mensuales de fármacos por parte de los pacientes.

4. Generación de Informes para la Toma de Decisiones:

 Crear informes mensuales detallados sobre los montos con y sin rebaja de las
recetas, considerando variables como sucursales y ciudades.

2. Usuarios Finales
Médicos Cardiólogos Tratantes:
Funciones:
Ingresar y validar información de diagnóstico de hipertensión para nuevos pacientes.
Acceder a los registros de pacientes asignados para seguimiento médico.
Consultar información demográfica y clínica relevante de los pacientes.

Personal Administrativo:
Funciones:
Registrar nuevos pacientes en la base de datos.
Validar la inscripción de médicos cardiólogos tratantes.
Registrar la compra mensual de recetas por parte de los pacientes.
Generar informes mensuales sobre las transacciones y descuentos aplicados.

4
 Especialistas en Control de Inventario:
Funciones: Mantener actualizado el catálogo de fármacos en la base de datos.
Registrar la entrada de nuevos fármacos a la bodega.
Supervisar y mantener el stock actualizado en todas las sucursales.

Pacientes Hipertensos:
Funciones: Comprar recetas mensuales con descuentos.
Consultar su historial de compras y descuentos aplicados.
Actualizar datos demográficos en caso de cambios.

Personal de Atención al Cliente:

Funciones: Brindar soporte y asistencia a pacientes con consultas sobre el proceso de
compra.
Asistir en la actualización de datos personales de los pacientes.

Especialistas en Informes y Análisis:

Funciones: Analizar la información almacenada para generar informes mensuales
detallados.
Identificar patrones y tendencias relacionadas con las ventas y descuentos.

3. Entidades
 Entidad: Paciente
Atributos:
ID_Paciente (PK)
Nombre
Apellido Paterno
Apellido Materno
RUN
Dirección
Ciudad
Región
Fecha de Nacimiento
Sexo
Estado Civil
Nacionalidad
Trabajo Actual
Teléfono Fijo
Teléfono Celular

5
  Entidad: Médico Tratante
Atributos:
ID_Medico (PK)
Nombre
Especialidad
Número de Registro

 Entidad: Diagnóstico de Hipertensión

Atributos:
ID_Diagnostico (PK)
ID_Paciente (FK)
ID_Medico (FK)
Etapa de Hipertensión
Fecha del Diagnóstico
Peso del Paciente
Presión Promedio

 Entidad: Receta Mensual

Atributos:
ID_Receta (PK)
ID_Paciente (FK)
Número de Receta
Fecha de la Receta
Total de la Receta

 Entidad: Fármaco
Atributos:
ID_Farmaco (PK)
Código
Nombre
Descripción
Precio de Compra
Stock Actual

 Entidad: Compra de Fármacos

Atributos:
ID_Compra (PK)
ID_Receta (FK)
ID_Farmaco (FK)
Prescripción
Cantidad
Precio de Compra

6
 Nota:

(PK): Clave Primaria

(FK): Clave Foránea

Estas entidades representan las diferentes tablas que compondrán la base de datos del
proyecto. Cada entidad almacena información específica y se relaciona con otras entidades
para construir un sistema integral de seguimiento y gestión de pacientes hipertensos en la
Fundación del Corazón.

4. Identificación y definición de atributos

 Entidad: Paciente
 ID_Paciente (PK): Identificador único del paciente.
 Nombre: Nombre del paciente.
 Apellido Paterno: Apellido paterno del paciente.
 Apellido Materno: Apellido materno del paciente.
 RUN: Número de Registro Único Nacional del paciente.
 Dirección: Dirección de residencia del paciente.
 Ciudad: Ciudad de residencia del paciente.
 Región: Región de residencia del paciente.
 Fecha de Nacimiento: Fecha de nacimiento del paciente.
 Sexo: Género del paciente.
 Estado Civil: Estado civil del paciente.
 Nacionalidad: Nacionalidad del paciente.
 Trabajo Actual: Información sobre el trabajo actual del paciente.
 Teléfono Fijo: Número de teléfono fijo del paciente.
 Teléfono Celular: Número de teléfono celular del paciente.

 Entidad: Médico Tratante

 ID_Medico (PK): Identificador único del médico tratante.
 Nombre: Nombre del médico tratante.
 Especialidad: Especialidad médica del médico tratante.
 Número de Registro: Número de registro médico.

7
  Entidad: Diagnóstico de Hipertensión
 ID_Diagnóstico (PK): Identificador único del diagnóstico.
 ID_Paciente (FK): Clave foránea que relaciona el diagnóstico con un paciente.
 ID_Medico (FK): Clave foránea que relaciona el diagnóstico con un médico tratante.
 Etapa de Hipertensión: Etapa en la que se encuentra el paciente (1, 2, 3).
 Fecha del Diagnóstico: Fecha en que se diagnosticó la hipertensión.
 Peso del Paciente: Peso del paciente al momento del diagnóstico.
 Presión Promedio: Presión arterial promedio del paciente al momento del diagnóstico.

 Entidad: Receta Mensual

 ID_Receta (PK): Identificador único de la receta.
 ID_Paciente (FK): Clave foránea que relaciona la receta con un paciente.
 Número de Receta: Número de identificación de la receta.
 Fecha de la Receta: Fecha en que se emitió la receta.
 Total de la Receta: Monto total a pagar por la receta.

 Entidad: Fármaco
 ID_Farmaco (PK): Identificador único del fármaco.
 Código: Código identificador del fármaco.
 Nombre: Nombre del fármaco.
 Descripción: Descripción del fármaco.
 Precio de Compra: Precio de compra del fármaco.
 Stock Actual: Cantidad actual de unidades en stock del fármaco.

 Entidad: Compra de Fármacos

 ID_Compra (PK): Identificador único de la compra de fármacos.
 ID_Receta (FK): Clave foránea que relaciona la compra con una receta.
 ID_Farmaco (FK): Clave foránea que relaciona la compra con un fármaco.
 Prescripción: Indicaciones de uso del fármaco.
 Cantidad: Cantidad de unidades compradas del fármaco.
 Precio de Compra: Precio total pagado por el fármaco en la compra.

8
Requisitos y Supuestos para Obtener un Modelo Entidad-Relación (MER):

Requisito: Identificación de Entidades Principales:

 Descripción: Identificar las entidades principales del sistema, que representan los objetos o
conceptos clave en el contexto del negocio. Por ejemplo, en el caso de la Fundación del
Corazón, las entidades principales podrían incluir "Paciente", "Médico Tratante", "Receta
Mensual", etc.

Requisito: Definición de Atributos Clave:

 Descripción: Para cada entidad identificada, se deben definir los atributos clave que
permitirán la distinción única de cada instancia. Por ejemplo, el ID_Paciente, ID_Medico, o
ID_Receta podrían ser atributos clave que proporcionen identificación única a las entidades
correspondientes.

Requisito: Establecimiento de Relaciones y Cardinalidades:

 Descripción: Determinar las relaciones entre las entidades identificadas y establecer las
cardinalidades de esas relaciones. Por ejemplo, definir que un paciente puede tener
múltiples recetas mensuales, pero cada receta está asociada a un único paciente.

Requisito: Identificación de Atributos Relevantes:

 Descripción: Identificar los atributos relevantes para cada entidad, considerando la

información necesaria para satisfacer los objetivos del negocio. En el caso de la Fundación
del Corazón, los atributos relevantes podrían incluir datos demográficos del paciente,
detalles de diagnósticos, información sobre recetas y fármacos, etc.

Requisito: Captura de Reglas de Negocio y Restricciones:

 Descripción: Documentar las reglas de negocio y restricciones que afectan la estructura y

comportamiento de la base de datos. Por ejemplo, establecer reglas sobre la frecuencia de
emisión de recetas, restricciones en la relación entre médicos y pacientes, o condiciones
para la venta de fármacos con descuentos.

9
Supuestos:

Supuesto: Consistencia y Precisión de los Datos:

Descripción: Se asume que los datos ingresados en la base de datos serán consistentes y precisos.
Esto implica que se espera que el personal médico y administrativo registre información de manera
correcta y actualizada.

Supuesto: Validez de Relaciones y Cardinalidades:

Descripción: Se parte del supuesto de que las relaciones y cardinalidades establecidas reflejan
fielmente la dinámica operativa del negocio. Esto implica que la información sobre recetas,
diagnósticos, y demás está alineada con la realidad de la Fundación del Corazón.

Supuesto: Mantenimiento de Reglas de Negocio:

Descripción: Se asume que las reglas de negocio establecidas se mantendrán vigentes y serán
respetadas a lo largo del tiempo. Cualquier cambio en las reglas de negocio deberá ser reflejado en
la estructura de la base de datos.

Supuesto: Acceso Seguro a la Base de Datos:

Descripción: Se supone que se implementarán medidas de seguridad para garantizar el acceso

autorizado a la base de datos. Esto incluye la protección de información sensible como datos
médicos y personales.

Supuesto: Integración con Sistemas Existentes:

Descripción: Se supone que la base de datos se integrará de manera efectiva con otros sistemas
existentes en la Fundación del Corazón, como sistemas de gestión de inventario, sistemas de
facturación, etc. Esto asegura la coherencia y flujo eficiente de datos en la organización.

10
 5. Identificación de relaciones y cardinalidades
Relación entre Paciente y Diagnóstico de Hipertensión:

 Cardinalidad: Uno a Uno (1:1)

 Descripción: Un paciente puede tener un único diagnóstico de hipertensión, y cada
diagnóstico está asociado a un único paciente.

Relación entre Paciente y Receta Mensual:

 Cardinalidad: Uno a Muchos (1:N)

 Descripción: Un paciente puede tener múltiples recetas mensuales, pero cada receta está
asociada a un único paciente.

Relación entre Médico Tratante y Diagnóstico de Hipertensión:

 Cardinalidad: Uno a Muchos (1:N)

 Descripción: Un médico tratante puede realizar diagnósticos de hipertensión para múltiples
pacientes, pero cada diagnóstico está asociado a un único médico tratante.

Relación entre Médico Tratante y Receta Mensual:

 Cardinalidad: Uno a Muchos (1:N)

 Descripción: Un médico tratante puede estar asociado a múltiples recetas mensuales, pero
cada receta está asociada a un único médico tratante.

Relación entre Fármaco y Compra de Fármacos:

 Cardinalidad: Uno a Muchos (1:N)

 Descripción: Un fármaco puede ser comprado en múltiples ocasiones, pero cada compra de
fármacos está asociada a un único fármaco.

Relación entre Receta Mensual y Compra de Fármacos:

 Cardinalidad: Uno a Muchos (1:N)

 Descripción: Una receta mensual puede estar asociada a múltiples compras de fármacos,
pero cada compra está asociada a una única receta mensual.
6. Extensión del Modelo Entidad-Relación con
Disyunción/Solapamiento y Completitud/Parcialidad:

1. Entidad: Paciente
 Atributos:
 ID_Paciente (PK)
 Nombre
 Apellido Paterno
 Apellido Materno
 ...
2. Entidad: Diagnóstico de Hipertensión
 Atributos:
 ID_Diagnostico (PK)
 ID_Paciente (FK)
 ID_Medico (FK)
 ...
 Relaciones:
 Relación con Paciente:
 Disyunción/Solapamiento: Solapamiento
 Completitud/Parcialidad: Total
3. Entidad: Receta Mensual
 Atributos:
 ID_Receta (PK)
 ID_Paciente (FK)
 ...
 Relaciones:
 Relación con Paciente:
 Disyunción/Solapamiento: Solapamiento
 Completitud/Parcialidad: Total
4. Entidad: Fármaco
 Atributos:
 ID_Farmaco (PK)
 Código
 Nombre
 ...
 Relaciones:
 Relación con Compra de Fármacos:
 Disyunción/Solapamiento: Disyunción Total
 Completitud/Parcialidad: Parcial

2
5. Entidad: Compra de Fármacos
 Atributos:
 ID_Compra (PK)
 ID_Receta (FK)
 ID_Farmaco (FK)
 ...
 Relaciones:
 Relación con Fármaco:
 Disyunción/Solapamiento: Solapamiento
 Completitud/Parcialidad: Total

 La entidad "Diagnóstico de Hipertensión" tiene una relación con "Paciente" con

solapamiento, ya que un paciente puede tener múltiples diagnósticos de hipertensión
(solapamiento).
 La entidad "Receta Mensual" tiene una relación con "Paciente" con solapamiento, ya que
un paciente puede tener múltiples recetas mensuales (solapamiento).
 La entidad "Compra de Fármacos" tiene una relación con "Fármaco" con disyunción total,
ya que cada compra está asociada a un único fármaco (disyunción total).
 Las relaciones con "Paciente" tienen completitud total, ya que se espera que cada
diagnóstico y receta esté asociado a un paciente.
 La relación con "Fármaco" desde "Compra de Fármacos" es parcial, ya que una compra no
necesita estar asociada a todos los fármacos existentes en la base de datos.

3
 7. Justificación de Decisiones en el Modelo Entidad-Relación
Extendido:
1. Entidad: Diagnóstico de Hipertensión:
 Disyunción/Solapamiento: Se eligió el solapamiento, ya que un paciente puede
recibir múltiples diagnósticos de hipertensión en diferentes momentos, y cada
diagnóstico es independiente de los demás.
 Completitud/Parcialidad: Se estableció como total, ya que se espera que cada
paciente tenga al menos un diagnóstico de hipertensión.
2. Entidad: Receta Mensual:
 Disyunción/Solapamiento: Se eligió el solapamiento, ya que un paciente puede
tener múltiples recetas mensuales, y cada receta es independiente de las demás.
 Completitud/Parcialidad: Se estableció como total, ya que se espera que cada
paciente tenga al menos una receta mensual.
3. Entidad: Fármaco:
 Disyunción/Solapamiento: Se eligió la disyunción total, ya que cada compra de
fármacos está asociada a un único fármaco, y un fármaco puede ser comprado en
diferentes ocasiones.
 Completitud/Parcialidad: Se estableció como parcial, ya que no es necesario que
cada fármaco esté asociado a todas las compras de fármacos.
4. Entidad: Compra de Fármacos:
 Disyunción/Solapamiento: Se eligió el solapamiento, ya que una compra de
fármacos puede incluir múltiples fármacos, y cada compra es independiente de las
demás.
 Completitud/Parcialidad: Se estableció como total, ya que se espera que cada
compra de fármacos esté asociada a al menos un fármaco.
Justificación General:
 Las decisiones de disyunción/solapamiento se basaron en la naturaleza de las relaciones y
la independencia entre las instancias de las entidades. En casos donde una entidad puede
tener múltiples instancias independientes, se optó por el solapamiento.
 Las decisiones de completitud/parcialidad se tomaron considerando las expectativas del
negocio. Se estableció completitud total en aquellas relaciones donde se espera que cada
instancia de la entidad esté asociada a al menos una instancia de la entidad relacionada.
8. Conclusión
Conclusiones Asociadas a la Funcionalidad del Proyecto:

Optimización del Seguimiento de Pacientes:

La implementación del modelo entidad-relación propuesto permitirá optimizar el

seguimiento mensual de pacientes hipertensos. La estructura de la base de datos facilita la
organización y recuperación eficiente de información relevante para el seguimiento médico.

Centralización de Información Clínica:

La base de datos propuesta centraliza la información clínica de los pacientes, incluyendo

diagnósticos, recetas mensuales, y compras de fármacos. Esto mejora la accesibilidad y la
consistencia de la información, facilitando la toma de decisiones médicas.

Eficiencia en la Gestión de Recetas y Fármacos:

El sistema de base de datos permite una gestión eficiente de las recetas mensuales y los
fármacos asociados. La relación entre entidades como "Receta Mensual" y "Compra de
Fármacos" facilita el control de la dispensación de medicamentos con descuento.

Integración con Sistemas Existentes:

El modelo entidad-relación está diseñado para integrarse de manera efectiva con sistemas
existentes en la Fundación del Corazón, asegurando coherencia en la gestión de información
y servicios relacionados con la atención a pacientes hipertensos.

Apoyo a la Toma de Decisiones:

La estructura de la base de datos proporciona una base sólida para la generación de

informes y análisis, lo que facilita la toma de decisiones estratégicas en la Fundación del
Corazón. La información consolidada sobre pacientes, diagnósticos y tratamientos
contribuye a una gestión más informada.

Cumplimiento de Reglas de Negocio:

El modelo de base de datos se alinea con las reglas de negocio establecidas, asegurando que
las operaciones y relaciones reflejen fielmente los procesos y procedimientos definidos en la
Fundación del Corazón. Esto contribuye al cumplimiento de los objetivos y políticas de la
institución.

2
 Beneficios Financieros:

La gestión eficiente de recetas y la compra de fármacos con descuento no solo mejora la

atención a los pacientes, sino que también puede traducirse en beneficios financieros para
la Fundación del Corazón. La optimización de procesos puede llevar a un mejor control de
costos y recursos.

9. Bibliografía
 Transformación modelo entidad relación a relacional
 Teoría de la normalización
 Modelo entidad relación extendido
Pinto, O. y Costa, G. (2020) Modelo entidad relación
extendido. [Apunte], Universidad Andrés Bello, Santiago, Chile.

3
Modelo entidad-Relación MERE

Primera forma Normal:

• Paciente
• Médico Tratante
• Receta mensual

4
Primera forma Normal:
• Diagnóstico
• Fármaco
• Compra de Fármaco

5
2da Forma Normal:
• Paciente
• Médico Tratante
• Receta Mensual

6
2da Forma Normal:
• Paciente
• Médico Tratante
• Receta Mensual

7
3ra Forma Normal:
• Paciente
• Médico Tratante
• Receta Mensual

8
3ra Forma Normal:
• Diagnóstico
• Fármaco
• Compra de fármaco