Está en la página 1de 22

Las razones de las entidades de la mesa de ayuda

Usuario:

Almacena información sobre los usuarios del sistema, incluyendo técnicos y clientes.
Facilita la identificación y gestión de las personas que interactúan con el sistema.

TecnicoSoporte:

Registra datos específicos de los técnicos de soporte, como habilidades y nivel de


experiencia. Ayuda en la asignación adecuada de técnicos a los boletos según sus
competencias.

Cliente:

Contiene información sobre los clientes, lo que facilita la comunicación y la gestión de


los boletos generados por ellos.

Boleto:

Es la entidad central que representa cada solicitud de ayuda o incidente reportado por
un cliente. Contiene información vital para rastrear y resolver problemas.

CategoriaProblema:

Organiza los boletos en categorías predefinidas según el tipo de problema reportado.


Facilita la asignación y resolución eficiente.

Prioridad:

Define la importancia y la urgencia de los boletos, ayudando a establecer niveles de


servicio y tiempos de respuesta.

HistorialBoleto:

Mantiene un registro detallado de todas las acciones y actualizaciones realizadas en un


boleto, brindando un historial completo de su vida.

Solucion:

Registra las soluciones implementadas para resolver problemas específicos,


permitiendo la revisión y referencia futura.

Notificacion:

Envía alertas y comunicaciones a usuarios y técnicos sobre eventos importantes, como


cambios en el estado del boleto o actualizaciones críticas.

GrupoSoporte:

Agrupa a los técnicos de soporte según criterios específicos, facilitando la asignación


de boletos a equipos especializados.
ContratoSoporte:

Define los términos y condiciones del servicio entre la mesa de ayuda y sus clientes,
incluyendo fechas de inicio y vencimiento, así como servicios incluidos.

Comentario:

Permite a los usuarios y técnicos agregar información adicional o comentarios


relevantes a un boleto, mejorando la colaboración y la comprensión del problema.

Departamento:

Organiza a los técnicos en diferentes áreas funcionales, facilitando la asignación y


gestión de tareas.

CanalEntrada:

Define los canales a través de los cuales los clientes pueden ingresar solicitudes de
soporte, brindando claridad sobre la fuente de cada boleto.

EstadoSolucion:

Define los diferentes estados que puede tener una solución, lo que ayuda a realizar un
seguimiento del progreso y la resolución de problemas.

TipoTicket:

Clasifica los boletos según su naturaleza (incidentes, solicitudes de servicio, etc.),


permitiendo una mejor organización y análisis.

EvaluacionCliente:

Recoge la retroalimentación de los clientes sobre la calidad del servicio, lo que


contribuye a la mejora continua.

SLA:

Establece los compromisos de servicio, incluyendo tiempos de respuesta y resolución,


garantizando niveles consistentes de atención al cliente.

DocumentoAdjunto:

Almacena documentos relacionados con boletos, como capturas de pantalla o archivos,


proporcionando contexto adicional para la resolución.

EscalonTicket:

Registra la escalación de boletos a niveles superiores de soporte cuando es necesario


abordar problemas más complejos.

Habilidades:

Centraliza la información sobre las habilidades y certificaciones de los técnicos,


ayudando en la asignación adecuada de recursos.
InformacionContacto:

Almacena información de contacto esencial para los clientes y técnicos, facilitando la


comunicación y la gestión de la información personal.

Persona

Representa individuos en el sistema de ayuda

Aplicando la Primera Regla de Normalización


Teníamos una tabla que era Cliente y con un atributo muy
multivaluado “InformacionContacto”, llego a ser una nueva
entidad ya con sus atributos correspondientes. La idea era
evitar la redundancia de datos y asegurarse de que cada
atributo este representando por un conjunto mínimo y no
redundante de datos.
Al igual con la entidad Tecnico de Soporte que tenia el
atributo Habilidades y pues recurrió a la normalización de
datos.

Aplicando la Segunda Regla de Normalización


En este nuestras tablas o entidades no recurrieron a esta regla ya
que habías evitado eso para el exceso de entidades y con
muchos atributos con información de más. Esto significa que no
hay atributos no clave que dependan parcialmente de la clave
primaria en ninguna de las tablas. Dado que se han dividido los
atributos de manera adecuada y se han creado tablas separadas
para entidades relacionadas (por ejemplo, la separación de
"Habilidades" en una tabla independiente en lugar de incluirlo
directamente en la tabla "TecnicoSoporte"), se evita la
dependencia parcial de la clave primaria.
Un ejemplo si hubiéramos aplicado:

Tenemos la tabla cliente


TABLA:
CLIENTE
ID_CLIENTE NOMBRE CIUDAD PAIS
1 JUAN LIMA PERU
2 MARIA BOGOTA COLOMBIA

Aplicando la segunda regla formal


TABLA:
CLIENTE
ID_CLIENTE NOMBRE
1 JUAN
2 MARIA

TABLA:
UBICACION
ID_UBICACIO CIUDAD
ID_CLIENTE PAIS
N
1 1 LIMA PERU
2 2 BOGOTA COLOMBIA

Un ejemplo de cómo se puede aplicar la segunda regla de


normalización dividiendo la información en tablas separadas para
evitar dependencias parciales de la clave primaria.

Aplicando la Tercera Regla de Normalización


Al igual con la segunda regla, con esta también evitamos las
dependencias transitivas en ninguna de las entidades pero
que pasaría si hubiera aplicado, ejemplo.
TABLA:
CONTRATO DE
SOPORTE
ID_CONTRATO FECHA CLIENTE
FECHA INICIO
VENCIMIENTO DEPARTAMENTO
1 2023-12-31 DEPARTAMENTO
2023-01-01
A
2 2023-11-30 DEPARTAMENTO
2023-02-15
B

En este caso, tenemos una dependencia transitiva entre


“ClienteDepartamento” y “Departamento”. La información del cliente y el
departamento esta vinculada en una sola columna
Aplicando la tercera regla formal
TABLA:
CONTRATO DE
SOPORTE
ID_CONTRAT FECHA
FECHA INICIO
O VENCIMIENTO
1 2023-01-01 2023-12-31
2 2023-02-15 2023-11-30

TABLA: CLIENTE
DEPARTAMENT
O
ID_CONTRATO CLIENT DEPARTAMENTO
1 A DEPARTAMENTO A
2 B DEPARTAMENTO B

Después de aplicar la tercera regla de normalización, hemos dividido la


información del cliente y el departamento en dos tablas distintas:
"ContratoSoporte" y "ClienteDepartamento". Ahora, la información del
cliente y el departamento no está redundante, y las dependencias
transitivas se han eliminado.
Al dividir la información que tiene una dependencia transitiva en dos
tablas separadas, puedes cumplir con la tercera regla de normalización.
LAS ENTIDADES CON SUS ATRIBUTOS Y TIPO DE CAMPOS
1. Tabla: Usuario
Campos:
IDUsuario (PK)
Nombre
CorreoElectronico
Telefono
Tipo de dato y restricciones:
IDUsuario: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(255), NOT NULL
CorreoElectronico: VARCHAR(255), NOT NULL
Telefono: VARCHAR(20)
2. Tabla: TecnicoSoporte
Campos:
IDTecnico (PK)
Nombre
Habilidades (FK a Habilidades)
NivelExperiencia
Tipo de dato y restricciones:
IDTecnico: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(255), NOT NULL
Habilidades: INT (FK a Habilidades), NOT NULL
NivelExperiencia: INT
3. Tabla: Cliente
Campos:
IDCliente (PK)
Nombre
InformacionContacto (FK a InformacionContacto)
Ciudad
Tipo de dato y restricciones:
IDCliente: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(255), NOT NULL
InformacionContacto: INT (FK a InformacionContacto), NOT NULL
Ciudad: VARCHAR(255)
4. Tabla: Boleto
Campos:
IDBoleto (PK)
Estado
FechaCreacion
FechaCierre
Tipo de dato y restricciones:
IDBoleto: INT, AUTO_INCREMENT, NOT NULL
Estado: VARCHAR(50), NOT NULL
FechaCreacion: DATE, NOT NULL
FechaCierre: DATE
5. Tabla: CategoriaProblema
Campos:
IDCategoria (PK)
Nombre
Descripcion
Tipo de dato y restricciones:
IDCategoria: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(50), NOT NULL
Descripcion: VARCHAR(255)
6. Tabla: Prioridad
Campos:
IDPrioridad (PK)
Nombre
Descripcion
TiempoRespuestaObjetivo
Tipo de dato y restricciones:
IDPrioridad: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(50), NOT NULL
Descripcion: VARCHAR(255)
TiempoRespuestaObjetivo: INT
7. Tabla: HistorialBoleto
Campos:
IDHistorial (PK)
IDBoleto (FK a Boleto)
FechaHoraActualizacion
DescripcionActualizacion
Tipo de dato y restricciones:
IDHistorial: INT, AUTO_INCREMENT, NOT NULL
IDBoleto: INT (FK a Boleto), NOT NULL
FechaHoraActualizacion: DATETIME, NOT NULL
DescripcionActualizacion: TEXT
8. Tabla: Solucion
• Campos:
• IDSolucion (PK)
• IDBoleto (FK a Boleto)
• DescripcionSolucion
• FechaImplementacion
• Tipo de dato y restricciones:
• IDSolucion: INT, AUTO_INCREMENT, NOT NULL
• IDBoleto: INT (FK a Boleto), NOT NULL
• DescripcionSolucion: TEXT
• FechaImplementacion: DATE
9. Tabla: Notificacion
• Campos:
• IDNotificacion (PK)
• TipoNotificacion
• Destinatario
• FechaHoraEnvio
• Tipo de dato y restricciones:
• IDNotificacion: INT, AUTO_INCREMENT, NOT NULL
• TipoNotificacion: VARCHAR(50), NOT NULL
• Destinatario: VARCHAR(255), NOT NULL
• FechaHoraEnvio: DATETIME, NOT NULL
10. Tabla: GrupoSoporte
• Campos:
• IDGrupo (PK)
• Nombre
• Descripcion
• Tipo de dato y restricciones:
• IDGrupo: INT, AUTO_INCREMENT, NOT NULL
• Nombre: VARCHAR(50), NOT NULL
• Descripcion: VARCHAR(255)
11. Tabla: ContratoSoporte
• Campos:
• IDContrato (PK)
• FechaInicio
• FechaVencimiento
• ServiciosIncluidos
• Tipo de dato y restricciones:
• IDContrato: INT, AUTO_INCREMENT, NOT NULL
• FechaInicio: DATE, NOT NULL
• FechaVencimiento: DATE, NOT NULL
• ServiciosIncluidos: TEXT
12. Tabla: Comentario
• Campos:
• IDComentario (PK)
• IDBoleto (FK a Boleto)
• TextoComentario
• FechaHoraPublicacion
• Tipo de dato y restricciones:
• IDComentario: INT, AUTO_INCREMENT, NOT NULL
• IDBoleto: INT (FK a Boleto), NOT NULL
• TextoComentario: TEXT, NOT NULL
• FechaHoraPublicacion: DATETIME, NOT NULL
13. Tabla: Departamento
• Campos:
• IDDepartamento (PK)
• Nombre
• Descripcion
• Encargado (FK a Persona)
• Tipo de dato y restricciones:
• IDDepartamento: INT, AUTO_INCREMENT, NOT NULL
• Nombre: VARCHAR(50), NOT NULL
• Descripcion: VARCHAR(255)
• Encargado: INT (FK a Persona)
14. Tabla: CanalEntrada
• Campos:
• IDCanal (PK)
• NombreCanal
• Descripcion
• TipoCanal
• ConfiguracionNotificaciones
• Tipo de dato y restricciones:
• IDCanal: INT, AUTO_INCREMENT, NOT NULL
• NombreCanal: VARCHAR(50), NOT NULL
• Descripcion: VARCHAR(255)
• TipoCanal: VARCHAR(50), NOT NULL
• ConfiguracionNotificaciones: TEXT
15. Tabla: EstadoSolucion
• Campos:
• IDEstadoSolucion (PK)
• Nombre
• Descripcion
• Tipo de dato y restricciones:
• IDEstadoSolucion: INT, AUTO_INCREMENT, NOT NULL
• Nombre: VARCHAR(50), NOT NULL
• Descripcion: VARCHAR(255)
16. Tabla: TipoTicket
• Campos:
• IDTipoTicket (PK)
• Nombre
• Descripcion
• Tipo de dato y restricciones:
• IDTipoTicket: INT, AUTO_INCREMENT, NOT NULL
• Nombre: VARCHAR(50), NOT NULL
• Descripcion: VARCHAR(255)
17. Tabla: EvaluacionCliente
• Campos:
• IDEvaluacion (PK)
• Puntuacion
• Comentarios
• FechaEvaluacion
• IDBoleto (FK a Boleto)
• Tipo de dato y restricciones:
• IDEvaluacion: INT, AUTO_INCREMENT, NOT NULL
• Puntuacion: INT, NOT NULL
• Comentarios: TEXT
• FechaEvaluacion: DATETIME, NOT NULL
• IDBoleto: INT (FK a Boleto), NOT NULL
18. Tabla: SLA
• Campos:
• IDSLA (PK)
• TiempoRespuestaObjetivo
• TiempoResolucionObjetivo
• CondicionesEspecificas
• Tipo de dato y restricciones:
• IDSLA: INT, AUTO_INCREMENT, NOT NULL
• TiempoRespuestaObjetivo: INT, NOT NULL
• TiempoResolucionObjetivo: INT, NOT NULL
• CondicionesEspecificas: TEXT
19. Tabla: DocumentoAdjunto
• Campos:
• IDDocumento (PK)
• NombreArchivo
• Descripcion
• FechaCarga
• IDBoleto (FK a Boleto)
• Tipo de dato y restricciones:
• IDDocumento: INT, AUTO_INCREMENT, NOT NULL
• NombreArchivo: VARCHAR(255), NOT NULL
• Descripcion: VARCHAR(255)
• FechaCarga: DATETIME, NOT NULL
• IDBoleto: INT (FK a Boleto), NOT NULL
20. Tabla: EscalonTicket
• Campos:
• IDEscalon (PK)
• RazonEscalon
• NivelSoporte
• FechaHoraEscalon
• IDBoleto (FK a Boleto)
• Tipo de dato y restricciones:
• IDEscalon: INT, AUTO_INCREMENT, NOT NULL
• RazonEscalon: VARCHAR(255), NOT NULL
• NivelSoporte: INT, NOT NULL
• FechaHoraEscalon: DATETIME, NOT NULL
• IDBoleto: INT (FK a Boleto), NOT NULL
21. Tabla: Habilidades
• Campos:
• IDHabilidad (PK)
• Nombre
• Nivel
• Certificaciones
• Descripcion
• Tipo de dato y restricciones:
• IDHabilidad: INT, AUTO_INCREMENT, NOT NULL
• Nombre: VARCHAR(50), NOT NULL
• Nivel: INT
• Certificaciones: VARCHAR(255)
• Descripcion: VARCHAR(255)
22. Tabla: InformacionContacto
Campos:
IDInformacionContacto (PK)
Nombre
Correo
Telefono
Direccion
Tipo de dato y restricciones:
IDInformacionContacto: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(50), NOT NULL
Correo: VARCHAR(255), NOT NULL
Telefono: VARCHAR(20)
Direccion: VARCHAR(255)
23. Tabla: Persona
Campos:
IDPersona (PK)
Nombre
Correo
Telefono
Tipo de dato y restricciones:
IDPersona: INT, AUTO_INCREMENT, NOT NULL
Nombre: VARCHAR(50), NOT NULL
Correo: VARCHAR(255), NOT NULL
Telefono: VARCHAR(20)
RELACIONES:

Ejemplo de Datos:

Tabla: Usuario

IDUsuario Nombre CorreoElectronico Telefono

1 Juan juan.j@gmail.com 916645654

2 Pedro pedro.p@gmail.com 987134756

Tabla: TecnicoSoporte

IDTecnico Nombre Habilidades NivelExperiencia

1 Marco 1,2 5

2 Adrian 2 3

Tabla: Cliente

IDCliente Nombre InformacionContacto Ciudad

1 Mayra 1 Lima

2 Martin 2 Trujillo

Tabla: Boleto

IDBoleto Estado Fecha Creación Fecha Cierre CategoriaProblema Prioridad

1 Abierto 2023-01-01 NULL 1 1

2 En Proceso 2023-01-02 NULL 2 2

Tabla: CategoriaProblema

IDCategoria Nombre Descripcion

1 Hardware Problemas de hardware

2 Software Problemas de software


Tabla: Prioridad

IDPrioridad Nombre Descripcion TiempoRespuestaObjetivo

1 Baja Baja prioridad 24

2 Media Media prioridad 12

Tabla: HistorialBoleto

IDHistorial IDBoleto FechaHoraActualizacion DescripcionActualizacion

1 1 2023-01-03 09:00:00 Asignado a Tecnico1

2 2 2023-01-03 10:30:00 Comentario del cliente: Necesito ayuda

Tabla: Solucion

IDSolucion IDBoleto DescripcionSolucion FechaImplementacion

1 1 Reemplazado cable de red defectuoso 2023-01-05

2 2 Actualizado software a la última versión 2023-01-04

Tabla: Notificacion

IDNotificacion TipoNotificacion Destinatario FechaHoraEnvio

1 Alerta juan.j@gmail.com 2023-01-03 12:00:00

2 Actualizacion pedro.p@gmail.com 2023-01-03 11:00:00

Tabla: GrupoSoporte

IDGrupo Nombre Descripcion

1 GrupoHardware Equipo especializado en hardware

2 GrupoSoftware Equipo especializado en software

Tabla: ContratoSoporte

IDContrato FechaInicio FechaVencimiento ServiciosIncluidos

1 2023-01-01 2023-12-31 Soporte remoto, actualizaciones

2 2023-02-15 2024-02-14 Asistencia en sitio, consultoría

Tabla: Comentario
IDComentario IDBoleto TextoComentario FechaHoraPublicacion

1 1 Cliente: ¿Cómo va la solución? 2023-01-04 14:00:00

2 2 Tecnico2: Se ha solucionado el problema 2023-01-04 13:30:00

Tabla: Departamento

IDDepartamento Nombre Descripcion Encargado

1 Soporte Técnico Equipo de soporte técnico 1

2 Desarrollo Equipo de desarrollo 2

Tabla: CanalEntrada

IDCanal NombreCanal Descripcion TipoCanal ConfiguracionNotificaciones

1 Correo Correos electrónicos Email Config1

2 Teléfono Llamadas telefónicas Teléfono Config2

Tabla: EstadoSolucion

IDEstadoSolucion Nombre Descripcion

1 Pendiente Solución pendiente

2 Resuelto Problema resuelto

Tabla: TipoTicket

IDTipoTicket Nombre Descripcion

1 Incidente Incidente técnico

2 SolicitudServicio Solicitud de servicio

Tabla: EvaluacionCliente

IDEvaluacion Puntuacion Comentarios FechaEvaluacion IDBoleto

1 4 Buen servicio 2023-01-06 10:00:00 1

2 5 Rápida resolución del problema 2023-01-06 11:30:00 2

Tabla: SLA

IDSLA TiempoRespuestaObjetivo TiempoResolucionObjetivo CondicionesEspecificas

1 2 24 Respuesta en 2 horas
IDSLA TiempoRespuestaObjetivo TiempoResolucionObjetivo CondicionesEspecificas

2 4 48 Resolución en 4 horas

Tabla: DocumentoAdjunto

IDDocumento NombreArchivo Descripcion FechaCarga IDBoleto

1 Adjunto1.txt Descripción del problema 2023-01-03 15:00:00 1

2 Captura.png Captura de pantalla 2023-01-04 09:30:00 2

Tabla: EscalonTicket

IDEscalon RazonEscalon NivelSoporte FechaHoraEscalon IDBoleto

1 Problema no resuelto 2 2023-01-05 14:00:00 1

2 Escalado por solicitud 3 2023-01-05 12:30:00 2

Tabla: Habilidades

IDHabilidad Nombre Nivel Certificaciones Descripcion

1 Redes 3 Cisco CCNA Configuración de redes

2 Java 4 Oracle Certified Desarrollo en Java

Tabla: InformacionContacto

IDInformacionContacto Nombre Correo Telefono Direccion

1 Juan juan.j@gmail.com 916645654 Calle Principal 123

2 Pedro pedro.p@gmail.com 987134756 Avenida Secundaria 456

Tabla: Persona

IDPersona ID Cliente ID Técnico

1 1 2

2 2 1

Para representar las relaciones entre las tablas proporcionadas, es necesario


analizar las claves primarias (PK) y las claves foráneas (FK) en cada tabla. Aquí
están las relaciones con su cardinalidad y una breve descripción:

1. Usuario - InformacionContacto (FK a InformacionContacto):


 Usuario.IDUsuario (PK) ->
InformacionContacto.IDInformacionContacto (FK)
 Relación: 1 a 1 (Un usuario tiene una única información de
contacto, y una información de contacto está asociada a un único
usuario).
2. TecnicoSoporte - Habilidades (FK a Habilidades):
 TecnicoSoporte.Habilidades (FK) -> Habilidades.IDHabilidad (PK)
 Relación: N a M (Un técnico de soporte puede tener varias
habilidades, y una habilidad puede ser compartida por varios
técnicos).
3. Cliente - InformacionContacto (FK a InformacionContacto):
 Cliente.InformacionContacto (FK) ->
InformacionContacto.IDInformacionContacto (PK)
 Relación: 1 a 1 (Un cliente tiene una única información de
contacto, y una información de contacto está asociada a un único
cliente).
4. Boleto - CategoriaProblema (FK a CategoriaProblema):
 Boleto.IDBoleto (PK) -> CategoriaProblema.IDCategoria (FK)
 Relación: 1 a M (Un boleto pertenece a una categoría de
problema, pero una categoría puede estar asociada a varios
boletos).
5. Boleto - Prioridad:
 Boleto.IDBoleto (PK) -> Prioridad.IDPrioridad (FK)
 Relación: 1 a 1 (Un boleto tiene una única prioridad, y una
prioridad está asociada a un único boleto).
6. Boleto - HistorialBoleto:
 Boleto.IDBoleto (PK) -> HistorialBoleto.IDBoleto (FK)
 Relación: 1 a M (Un boleto puede tener múltiples entradas en el
historial, pero cada entrada en el historial está asociada a un único
boleto).
7. Boleto - Solucion:
 Boleto.IDBoleto (PK) -> Solucion.IDBoleto (FK)
 Relación: 1 a 1 (Un boleto tiene una única solución, y una solución
está asociada a un único boleto).
8. Boleto - Notificacion:
 Boleto.IDBoleto (PK) -> Notificacion.IDBoleto (FK)
 Relación: 1 a M (Un boleto puede tener múltiples notificaciones,
pero cada notificación está asociada a un único boleto).
9. TecnicoSoporte - GrupoSoporte:
 TecnicoSoporte.IDTecnico (PK) -> GrupoSoporte.IDGrupo (FK)
 Relación: N a M (Un técnico de soporte puede pertenecer a varios
grupos, y un grupo puede tener varios técnicos).
10. Cliente - ContratoSoporte:
 Cliente.IDCliente (PK) -> ContratoSoporte.IDContrato (FK)
 Relación: 1 a M (Un cliente puede tener múltiples contratos de
soporte, pero cada contrato está asociado a un único cliente).
11. Boleto - Comentario:
 Boleto.IDBoleto (PK) -> Comentario.IDBoleto (FK)
 Relación: 1 a M (Un boleto puede tener múltiples comentarios,
pero cada comentario está asociado a un único boleto).
12. TecnicoSoporte - Departamento (FK a Persona):
 TecnicoSoporte.IDTecnico (PK) -> Departamento.Encargado (FK)
 Relación: N a 1 (Un técnico puede ser el encargado de un
departamento, pero un departamento tiene un único encargado
que es un técnico).
13. Boleto - CanalEntrada:
 Boleto.IDBoleto (PK) -> CanalEntrada.IDCanal (FK)
 Relación: 1 a 1 (Un boleto se origina en un único canal de entrada,
y un canal de entrada está asociado a un único boleto).
14. Solucion - EstadoSolucion:
 Solucion.IDSolucion (PK) -> EstadoSolucion.IDEstadoSolucion (FK)
 Relación: 1 a 1 (Una solución tiene un estado específico, y un
estado de solución está asociado a una única solución).
15. Boleto - TipoTicket:
 Boleto.IDBoleto (PK) -> TipoTicket.IDTipoTicket (FK)
 Relación: 1 a 1 (Un boleto tiene un tipo específico, y un tipo de
boleto está asociado a un único boleto).
16. Boleto - EvaluacionCliente:
 Boleto.IDBoleto (PK) -> EvaluacionCliente.IDEvaluacion (FK)
 Relación: 1 a 1 (Un boleto puede tener una única evaluación de
cliente, y una evaluación de cliente está asociada a un único
boleto).
17. Boleto - SLA:
 Boleto.IDBoleto (PK) -> SLA.IDSLA (FK)
 Relación: 1 a 1 (Un boleto tiene un acuerdo de nivel de servicio
específico, y un SLA está asociado a un único boleto).
18. DocumentoAdjunto - Boleto:
 DocumentoAdjunto.IDDocumento (PK) -> Boleto.IDBoleto (FK)
 Relación: 1 a M (Un documento adjunto puede estar asociado a
varios boletos, pero cada documento está asociado a un único
boleto).
19. Boleto - EscalonTicket:
 Boleto.IDBoleto (PK) -> EscalonTicket.IDBoleto (FK)
 Relación: 1 a M (Un boleto puede tener múltiples escalones, pero
cada escalón está asociado a un único boleto).
20. TecnicoSoporte - Habilidades:
 TecnicoSoporte.Habilidades (FK) -> Habilidades.IDHabilidad (PK)
 Relación: N a M (Un técnico puede tener varias habilidades, y una
habilidad puede ser compartida por varios técnicos).
21. TecnicoSoporte - Persona:
 TecnicoSoporte.IDTecnico (PK) -> Persona.IDPersona (FK)
 Relación: 1 a 1 (Un técnico de soporte es una persona específica, y
una persona está asociada a un único técnico).
22. Cliente - Persona:
 Cliente.IDCliente (PK) -> Persona.IDPersona (FK)
 Relación: 1 a 1 (Un cliente es una persona específica, y una
persona está asociada a un único cliente).
23. ContratoSoporte - Persona:
 ContratoSoporte.Encargado (FK) -> Persona.IDPersona (PK)
 Relación: 1 a 1 (El encargado de un contrato de soporte es una
persona específica, y una persona está asociada a un único
contrato de soporte).
24. CanalEntrada - Notificacion:
 CanalEntrada.IDCanal (PK) -> Notificacion.IDCanal (FK)
 Relación: 1 a M (Un canal de entrada puede tener múltiples
notificaciones, pero cada notificación está asociada a un único
canal de entrada).
25. InformacionContacto - Persona:
 InformacionContacto.IDInformacionContacto (PK) ->
Persona.IDPersona (FK)
 Relación: 1 a 1 (La información de contacto está asociada a una
persona específica, y una persona tiene una única información de
contacto).
26. Cliente - ContratoSoporte:
 Cliente.IDCliente (PK) -> ContratoSoporte.IDContrato (FK)
 Relación: 1 a M (Un cliente puede tener múltiples contratos de
soporte, pero cada contrato está asociado a un único cliente).

También podría gustarte