Ciencia Latina Revista Científica Multidisciplinar
Septiembre- Octubre, 2023, Volumen 7, Número 5.
https://doi.org/10.37811/cl_rcm.v7i5.7778
pág. 949
Modelo de Datos para Gestionar Cursos Impartidos por el CCPGRO
Joel Carrillo Luna1
MM21320004@acapulco.tecnm.mx
https://orcid.org/0000-0002-0137-1992
Departamento de Posgrado e Investigación
del TecNM campus Acapulco
Acapulco de Juárez, Guerrero, México.
Rafael Hernández Reyna
rafael.hr@acapulco.tecnm.mx
https://orcid.org/0000-0002-4427-384X
Departamento de Posgrado e Investigación
del TecNM campus Acapulco
Acapulco de Juárez, Guerrero, México.
Miriam Martínez Arroyo
miriam.ma@acapulco.tecnm.mx
https://orcid.org/0000-0002-1781-804X
Departamento de Posgrado e Investigación
del TecNM campus Acapulco
Acapulco de Juárez, Guerrero, México.
José Antonio Montero Valverde
jose.mv@acapulco.tecnm.mx
https://orcid.org/0009-0000-5357-3257
Departamento de Posgrado e Investigación
del TecNM campus Acapulco
Acapulco de Juárez, Guerrero, México.
RESUMEN
El presente artículo describe el diseño del modelo de datos para automatizar los procesos
asociados a la venta y administración de cursos y diplomados que ofrece e imparte el CCPGRO
(Colegio de Contadores Públicos del Estado de Guerrero) (CCPGRO, 2023). El diseño del modelo
de datos representa la primera etapa para desarrollar el sistema web para gestionar todos los
procesos asociados a la venta y administración de cursos y diplomados. El desarrollo del
modelado de datos se dividió en tres etapas, a la par que se ejecuta la metodología cascada. Como
primera etapa se muestra el análisis y definición de requerimientos; en la segunda etapa se muestra
el marco conceptual donde se identifican las clases, atributos y métodos; y en la tercera etapa se
muestra como resultado el diagrama entidad-relación que muestra el modelo de datos de alto nivel
de la base de datos a implementar. Los diagramas obtenidos, se elaboran utilizando el Lenguaje
de Modelado Unificado (UML) (Rumbaugh, Jacobson, & Booch, 1999) y el estándar BPMN
(Business Process Model Notation) (Analitica, 2011).
Palabras clave: modelado de datos; modelo relacional; modelo entidad-relación.
1
Autor principal
Correspondencia: williambz@hotmail.es
pág. 950
Data Model to Manage Courses Taught by the CCPGRO
ABSTRACT
The present article describes the design of the data model to automate the processes associated
with the sale and administration of courses and diplomas offered by CCPGRO (Public
Accountants College of the State of Guerrero.) (CCPGRO, 2023). The design of the data model
represents the first stage in developing the web system to manage all the processes related to the
sale and administration of courses and diplomas. The development of the data modeling was
divided into three stages, following the execution of the waterfall methodology. The first stage
encompasses the analysis and definition of requirements, while the second stage presents the
conceptual framework where classes, attributes, and methods are identified. The third stage results
in the entity-relationship diagram, which displays the high-level data model of the database to be
implemented. The obtained diagrams are created using the Unified Modeling Language (UML)
(Rumbaugh, Jacobson, & Booch, 1999) and the Business Process Model Notation (BPMN)
standard (Analitica, 2011).
Keywords: courses; web; waterfall; database
Artículo recibido 20 agosto 2023
Aceptado para publicación: 05 setiembre 2023
pág. 951
INTRODUCCIÓN
Actualmente y por motivo de la contingencia denominada el SARS-CoV-2, también llamada la
COVID-19 o con el nombre común de la familia de virus “Coronavirus” (Gobierno de México,
2022) que inició en el mes de marzo de 2020 en México, las plataformas digitales han aumentado
su demanda, esto debido a que, una de las medidas implementadas por el gobierno para evitar
contagios fue el de confinamiento, es decir, evitar el contacto entre personas.
Las plataformas digitales han tenido un auge, el uso de herramientas digitales, como el programa
Microsoft Teams, aumentó el número de usuarios diarios un 70% (alcanzando los 75 millones en
el tercer trimestre de 2020), así también, el programa Zoom, el cual superó los diez millones de
usuarios en abril 2020 (Digital Future Society y Banco Interamericano de Desarrollo, 2021).
Dado el aumento de las plataformas digitales, el CCPGRO, enfrenta la necesidad de impartir y
difundir los cursos y diplomados de manera automatizada. Estos tienen un costo, los cuales varían
dependiendo de la especialidad y del perfil de la persona que lo adquiere.
Para conocer la mecánica operativa que el CCPGRO sigue para impartir los cursos, se realizó una
consulta al personal experto que interviene en este proceso, obteniéndose el resultado que se
muestra en la Figura 1.
Figura 1:
Modelo de Procesos de Negocios (BPM) para la gestión de cursos y diplomados que ofrece el
CCPGRO.
Fuente: Elaboración propia. Realizado con EA (Enterprise Architect).versión: 15.0.1509, versión UML 2.1. (Sparx
Systems Pty Ltd., 2023)
pág. 952
La Figura 1 muestra el Diagrama que representa el Modelo de Procesos de Negocios (BPM-
Business Process Model), en el cual se aplica el estándar BPMN (Analitica, 2011). En el BPM se
representa el flujo de las actividades que se realizan para la venta y administración de cursos y
diplomados que ofrece el CCPGRO. Como primer paso, inicia al anunciar los cursos y
diplomados a través de medios digitales como Facebook y WhatsApp, lo anterior como medio de
difusión. Como segundo paso sigue elección y pago del curso, donde, el participante elige a través
de la publicidad el curso y/o diplomado. Posteriormente, para adquirir el curso, la persona paga
el costo del curso mediante un depósito bancario, una vez pagado, de manera personal, el
interesado lleva su recibo de pago a las oficinas del CCPGRO, y se solicita la factura en caso de
requerirla. El tercer paso consiste en el confirmar su pago y registro al curso; una vez que el
interesado entrega su recibo de pago, el asistente administrativo registra sus datos en un libro
físico, en el cual anota la información del interesado, como son: nombre, correo electrónico,
institución de procedencia, entre otros. Una vez que la persona queda registrada. El quinto paso
es enviar toda la información referente al curso, por lo que, el asistente administrativo, envía un
correo electrónico al interesado, en el cual se adjunta el enlace de ZOOM para que se una al curso,
así también, un archivo con el material que utilizará para completarlo. Hasta este momento, el
interesado ya puede tomar el curso. El sexto paso es completar el curso, al finalizarlo, se registra
su puntuación y se solicita de nueva cuenta los datos al interesado. El séptimo paso es generar la
constancia de participación, la cual es realizada en la aplicación de Microsoft Word, una vez
generada es firmada por el presidente y secretario del CCPGRO. El octavo y último paso es
entregar la constancia al interesado.
Lo descrito anteriormente, se realiza de manera manual, por lo que las formas que se han utilizado,
son insuficientes para atender la demanda de los cursos, generando problemas durante la gestión
de estos, tales como: la pérdida o captura errónea de la información de los participantes,
constancias de cursos no generadas, constancias con información errónea o entregadas de forma
tardía, así también, la facturación se realiza con demora debido a que la información se encuentra
extraviada o inconsistente. Por lo anterior, se plantea como solución, automatizar mediante un
sistema web, la gestión de los cursos y diplomados que imparte el CCPGRO.
pág. 953
Con el propósito de aportar lo último en trabajos similares al que se desea desarrollar, se realizó
la investigación de aplicaciones similares, entre los que se encuentra el sistema e-commerce para
la gestión de ventas (Saavedra-Gonzales, 2016), el cual propone de manera correcta y sistemática
el proceso para poder implementar un sistema de venta en línea, desde la organización y
planeación hasta la puesta en marcha, sin embargo, no se realiza un análisis que clarifique las
mejoras que conlleva implementar ventas en línea, lo cual provoca que se pueda parametrizar la
mejora en las ventas, las visitas o el consumo de productos. Otro trabajo similar es el desarrollo
del sistema integral de control escolar y servicios (SICES) (Blanco Reyes, 2018), en el cual se
detalla todo el proceso para el desarrollo del proyecto, metodologías, fases, herramientas de
desarrollo, bases de datos y diseño de interfaces; detalla con precisión los requisitos necesarios
para usar correctamente el software desarrollado, lo cual ayuda en la toma de decisiones, sin
embargo, no es un sistema que se ajuste a los requerimientos específicos que solicita el CCPGRO.
Así también se encuentra el prototipo de un sistema de registro escolar (Domínguez Domínguez,
2018), el cual consiste en un prototipo que abarca todas las necesidades de los requerimientos
solicitados, abarcando las soluciones a las problemáticas que el sistema anterior no pudo resolver,
personalizando y adaptando las configuraciones (CCPGRO, 2023) y lógica de datos. Sin embargo,
al igual que los anteriores, aunque aporta recursos importantes para implementarse en el
desarrollo del sistema web para la gestión de los cursos en línea, este no se adapta a las
especificaciones de los requerimientos del sistema que necesita el CCPGRO, los cuales se
describen en la sección de resultados de este trabajo.
El sistema de venta de cursos en línea puede proporcionar una mayor eficiencia en el proceso de
gestión y administración de los cursos. La tecnología puede ayudar en la gestión de la inscripción
de los estudiantes, el seguimiento de su progreso, la entrega del material de enseñanza, la
evaluación y el seguimiento de los resultados de aprendizaje.
Por lo anterior, para establecer las bases sobre las cuales se desarrolla el sistema web para la venta
de cursos en línea, se presenta el modelo de datos del sistema.
pág. 954
MARCO REFERENCIAL
De acuerdo con Catherine M., un modelo de datos refleja con precisión el funcionamiento de la
organización en el mundo real, mediante la creación de una base de datos que requiere una
metodología adecuada, de tal forma que, la base de datos diseñada pueda evolucionar y cambiar
para futuras necesidades de información. Para poder crear esta base de datos, se debe crear un
modelo conceptual que tenga las siguientes características (M. Ricardo, 2009):
El modelo muestra las operaciones de la organización.
Es flexible, de tal forma que permite cambios conforme van surgiendo nuevas necesidades de
información.
Permite diversas visiones de usuario diferentes.
Es de forma independiente de la implementación física.
No depende de un modelo de datos usado por un sistema de gestión de base de datos particular.
En este orden de ideas, según Silberschatz, bajo la estructura de la base de datos se encuentra el
modelo de datos: una colección de herramientas conceptuales para describir datos, las relaciones,
la semántica y las restricciones de consistencia. Dos ejemplos de modelo de datos son: el modelo
entidad-relación y el modelo relacional (Silberschatz, Korth, & Sudarshan, 2006).
Así también, Sánchez menciona en su trabajo de diseño conceptual de base de datos, que un
modelo de datos se utiliza con la finalizad de simbolizar una parte del mundo real de forma que
sea más fácilmente manipulable (Sánchez, 2004). Esta definición, es muy similar a la de Catherine
M. Además, Sánchez clasifica los modelos de datos como muestra a continuación la Figura 2.
Figura 2: Clasificación de los modelos de datos
Fuente: Extraído del documento electrónico Diseño Conceptual de bases de datos, página 15 (Sánchez, 2004).
pág. 955
La Figura 2, muestra como a partir del mundo real se realizan distintos esquemas para obtener
una base de datos física.
Para realizar cada esquema se utilizan los modelos de datos, dado que, entre cada esquema se
deben seguir directrices específicas, para adaptar un esquema hacia otro. Sin embargo, existen
dos modelos fundamentales, el modelo de datos conceptual y el modelo de datos lógico, los dos
son conceptuales, a fin de representar mediante abstracciones el mundo real y entender los datos
para su representación en la base de datos física. Un ejemplo de modelo conceptual es el Modelo
entidad-relación, y un ejemplo de modelo lógico es el Modelo relacional (Sánchez, 2004).
Es importante mencionar que, el modelo de datos es un conjunto de conceptos, los cuales son
utilidad para describir la estructura de la base de datos (Marqués, 2011), por lo que, para describir
la estructura de la base del sistema a desarrollar, es fundamental definir el tipo de modelo de datos
a diseñar. El tipo de modelo de datos elegido, el cual es objeto del presente artículo es el modelo
de datos entidad-relación.
Modelo de datos entidad-relación(E-R)
Este modelo proporciona un esquema de la empresa el cual representa el diseño o estructura lógica
completa de la base de datos. Es un modelo de datos semántico, ya que por medio de su
representación muestra el significado de los datos. Este modelo se basa en una percepción del
mundo real, el cual consiste en objetos básicos denominados entidades y las relaciones que existen
entre estos objetos.
Una entidad es un objeto en el mundo real, el cual se distingue de todos los demás objetos. Cada
entidad tiene un conjunto de propiedades, los cuales contienen valores que identifican de manera
unívoca una entidad. Por ejemplo, un participante que va a tomar un curso o diplomado que ofrece
el CCPGRO, debe estar identificado con un identificador único, de lo contrario, existiría
información duplicada. Cada entidad se representa por medio de un conjunto de atributos, los
cuales describen propiedades que posee cada miembro del conjunto de entidades. Por lo tanto,
una base de datos incorpora una colección de conjuntos de entidades, cada una con entidades del
mismo tipo (Silberschatz, Korth, & Sudarshan, 2006).
pág. 956
Para representar un diagrama entidad-relación se utiliza un lenguaje especifico como es UML
(Lenguaje de Modelado Unificado) (Rumbaugh, Jacobson, & Booch, 1999), el cual mediante
vistas creadas con este lenguaje, se representan las abstracciones mediante elementos que
capturan el comportamiento de distintos escenarios que se requieren para desarrollar un sistema
software, en este caso, para representar el diagrama entidad-relación para mostrar el modelado de
datos.
Bases de datos relacionales
Por otro lado, se eligió el modelo entidad-relación, ya que, para cumplir con la definición de
requerimientos, es importante crear una base de datos de tipo relacional, por lo que, este modelo
permite el cumplimiento de este requerimiento.
Una base de datos relacional está formada por un conjunto de relaciones, en donde a las relaciones
en SQL (Lenguaje de consulta estructurado, (Microsoft, 2023) ), se les llama tablas y cada una de
estas contiene una serie de columnas, las cuales representan sus atributos. Las columnas tienen
nombres distintos y cada una de ellos es definida por un tipo de datos (entero, real, carácter, fecha,
etc.). Con los datos de las tablas, se pueden realizar operaciones, como insertar filas (tuplas), que
después se pueden consultar, modificar o borrar (Rocha C., 2017).
Para realizar una base de datos relacional, primero se definen el esquema conceptual,
estableciendo relaciones y la semántica de los datos con el modelo entidad-relación, a partir del
cual, se puede transformar a un modelo relacional al momento de crear la base de datos de forma
física en SQL. Para obtener bases de datos no redundantes se realiza el proceso de normalización.
Normalización
La normalización es el proceso de organizar los datos en una base de datos. Esto incluye la
creación de tablas y el establecimiento de relaciones entre esas tablas de acuerdo con reglas
diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible al
eliminar la redundancia y la dependencia inconsistente (Microsoft, 2023).
Existen 4 niveles de normalización de base de datos, llamadas también formas normales, donde
la cuarta forma normal es el nivel requerido, a fin de evitar datos duplicados y permitiendo que
los datos se mantengan íntegros.
pág. 957
Requerimientos del sistema
Los requerimientos del sistema se definen a partir del análisis de los procesos que se van a
automatizar para el desarrollo del sistema web para los cursos en línea. De acuerdo con
Sommerville, los requerimientos son descripciones de lo que el sistema debe hacer: el servicio
que ofrece y las restricciones en su operación. Así mismo, estos se clasifican en requerimientos
del sistema y del usuario, donde los requerimientos del sistema de software se clasifican como
requerimientos funcionales y no funcionales (Sommerville, 2011).
Los requerimientos funcionales son enunciados sobre los servicios que debe de proveer el sistema,
así también sobre cómo debe de interactuar con respecto a los datos de entrada y su
comportamiento en ciertas situaciones. Los requerimientos no funcionales describen las
restricciones del sistema, las limitaciones sobre funciones o servicios. Se suelen aplicar al sistema
como un todo.
De acuerdo con lo dice (Leach, 2016), se debe determinar la forma más eficiente de desarrollar
los requerimientos en el dominio de la aplicación. Esta determinación se puede considerar como
texto plano, descripciones gráficas y métodos formales.
Lo anterior descrito forma parte del marco referencial sobre el cual se basa el presente trabajo.
Objetivo general
El objetivo del presente trabajo consiste en realizar a partir de la definición de requerimientos del
sistema, el diseño del modelo de datos entidad-relación, con el fin de proporcionar la estructura
de datos para crear la base de datos física, la cual servirá para almacenar la información de los
cursos para su gestión sobre el sistema web a desarrollar para el CCPGRO.
A continuación, se describe la metodología de desarrollo de software a utilizar, y que etapas están
implicadas en este primer trabajo.
METODOLOGÍA
Con el propósito de desarrollar el sistema web para la gestión de los cursos en línea que ofrece el
CCPGRO, se eligió la metodología de desarrollo de software en cascada.
De acuerdo con (Sommerville, 2011), el modelo cascada se conforma de las siguientes estas,
mismas que se muestran a continuación en la Figura 3.
pág. 958
Figura 3: El modelo en cascada.
Fuente: (Sommerville, 2011)
La metodología cascada permite desarrollar el sistema web de forma dirigida, esto a partir de una
planeación, por lo que elegir esta metodología es la conveniente debido a que ya se tienen
definidos los requerimientos del sistema sin cambios radicales que puedan afectar el desarrollo
del sistema.
Como se puede observar en la Figura 3, la primera etapa consiste en la definición de
requerimientos, es decir, definir las metas del sistema de forma detallada; la segunda etapa
consiste en el diseño del sistema y del software, la cual consiste en el proceso de diseñar el sistema
a partir de los requerimientos definidos en la primera etapa, además, en esta etapa se definen las
abstracciones primordiales del sistema software y sus relaciones.
De acuerdo a lo anterior, para realizar el diseño del modelo de datos, se debe realizar la primera
y segunda etapa de la metodología cascada, es decir, una vez definidos los requerimientos del
sistema, el diseño del modelo de datos va implícito en la segunda etapa de la metodología cascada
(diseño del sistema y del software), por lo que, con el propósito de realizar el diseño del modelo
de datos entidad-relación, el trabajo se dividió en tres etapas:
Etapa1: Análisis y definición de requerimientos. A partir del diagrama del Modelo de Procesos
de Negocio (BPM) se definen los requerimientos funcionales y no funcionales. Esto como parte
inicial de la metodología cascada.
pág. 959
Etapa 2: Marco conceptual. A partir de los requerimientos funcionales y mediante el diagrama
de casos de uso se identifica el cumplimiento de los requerimientos funcionales para determinar
el diagrama de clases y así definir las entidades, atributos y la relación entre estos.
Etapa 3: Modelo entidad-relación. Muestra el diagrama entidad-relación con las entidades,
atributos y sus relaciones, a fin de mostrar cómo es que se asocian entre sí.
A continuación, en la sección de resultados y discusión se desarrollan las etapas mencionadas
anteriormente con los resultados obtenidos de cada una de ellas.
RESULTADOS Y DISCUSIÓN
De acuerdo a lo expuesto en las secciones anteriores, a continuación, se muestra el resultado de
las tres etapas en las que se dividió el desarrollo del diseño de modelo de datos, descritas en la
sección de metodología.
Etapa 1: Análisis y definición de requerimientos.
De acuerdo al análisis de los procesos que intervienen en la gestión de los cursos en línea que
ofrece el CCPGRO representados en el diagrama BPM, ver Figura 1, a continuación, se definen
los requerimientos funcionales (RF#) y los requerimientos no funcionales (RNF#) del sistema.
Tabla 1: Lista de Requerimientos funcionales del sistema de gestión de cursos en línea que ofrece
el CCPGRO.
Requerimientos funcionales
ID del
requerimiento
Sub
requerimientos
Descripción
RF1
No aplica
En el módulo Inicio de sesión se debe permitir al usuario
administrador ingresar al sistema con su correo electrónico y
una contraseña.
RF2
No aplica
En el módulo Inicio de sesión se debe permitir al usuario
administrador mantener la sesión activa.
RF3
No aplica
En el módulo Inicio de sesión no se debe permitir recuperar la
contraseña, en caso de olvidarla, se deberá solicitar al usuario
con perfil administrador.
pág. 960
RF4
No aplica
El sistema debe contar con un módulo para Eventos.
RF4.1
El sistema debe contar con un submódulo para registrar nuevos
eventos.
RF4.1.1
El usuario podrá dar de alta un nuevo evento.
RF4.1.2
El usuario podrá modificar los datos de un evento.
RF4.1.3
El usuario podrá eliminar un evento siempre y cuando aún no
se hayan inscrito a él.
RF4.1.4
El usuario podrá consultar los datos de un evento.
RF4.1.5
El usuario podrá visualizar la cantidad de participantes que se
han registrado al evento.
RF4.1.6
El usuario podrá actualizar el estatus de un evento.
RF4.1.7
El usuario podrá exportar la lista de eventos a un archivo de
Excel.
RF4.2
El sistema debe contar con un submódulo para Videos.
RF4.2.1
El usuario podrá dar de alta un video.
RF4.2.2
El usuario modificar los datos del video.
RF4.2.3
El usuario podrá actualizar el estatus del video.
RF4.2.4
El usuario administrador podrá consultar cuántos participantes
han comprado el video.
RF5
No Aplica
El sistema debe contar con un módulo para Participantes.
RF5.1
El usuario podrá dar de alta un nuevo participante.
RF5.2
El usuario podrá aceptar, denegar o modificar la solicitud de un
tipo de perfil de un participante que se acaba de registrar.
RF5.3
El usuario podrá consultar la lista de los participantes
registrados al sistema.
RF5.4
El usuario podrá modificar la información de algún participante
en particular.
RF5.5
El usuario podrá generar una nueva contraseña para el
participante, esta contraseña será generada automáticamente
por el sistema y enviada por correo, el usuario no podrá verla ni
acceder a ella.
RF6
No Aplica
El sistema debe contar con un módulo de Inicio.
RF6.1
Se deben mostrar el total de participantes inscritos al sistema.
RF6.2
Se debe mostrar el total de eventos dados de alta.
RF6.3
Se deben mostrar gráficas mostrando los datos anteriores.
RF6.4
El usuario administrador podrá descargar la información en
formato Excel para posterior uso en plataforma externa.
pág. 961
RF7
No Aplica
El sistema debe contar con un módulo para generar constancias.
RF7.1
El usuario administrador podrá generar una nueva constancia a
partir de cada evento realizado.
RF7.2
El usuario administrador reenviar las constancias por correo ya
generadas.
RF7.3
El usuario administrador podrá consultar las constancias
utilizando filtros.
RF7.4
El sistema debe contar con un módulo para videos.
RF7.4.1
El usuario administrador podrá dar de alta un nuevo video.
RF7.4.2
El usuario administrador ver la lista de videos dados de alta.
RF7.4.3
El usuario administrador podrá eliminar un video dado de alta.
RF7.4.4
El usuario administrador podrá modificar la información de un
video dado de alta.
RF7.4.5
El usuario administrador podrá consultar el número de
participantes que han comprado los videos dados de alta.
Fuente: Elaboración propia.
Tabla 2: Lista de Requerimientos no funcionales del sistema de gestión de cursos en línea que
ofrece el CCPGRO.
Requerimientos no funcionales
ID del
requerimiento
RNF1
RNF2
RNF3
RNF4
RNF5
RNF6
RNF7
Fuente: Elaboración propia.
En las Tablas 1 y 2 se observa la definición de requerimientos funcionales y no funcionales,
resultado de un análisis realizado sobre los procesos que intervienen en la venta de cursos en línea
pág. 962
y, además, de la consulta que se realizó al cliente con respecto a sus necesidades, por lo que, una
vez que se han definido estos, a continuación, como parte de la etapa 2 de este trabajo, se muestra
el diagrama de casos de uso que se obtuvo a partir del diagrama BPMN de la Figura 1 y de la
especificación de requerimientos.
Etapa 2: Marco conceptual
En la Figura 4 se observa que, a diferencia del modelo de procesos de negocio de la Figura 1, se
colocan nuevos actores a partir de los requerimientos definidos y que se involucran en el
desarrollo del sistema a desarrollar.
Figura 4: Diagrama de casos de uso para gestionar cursos en línea del CCPGRO.
Fuente: Elaboración propia en la aplicación Enterprise Architect (EA) (Sparx Systems Pty Ltd., 2023).
En la Figura 4, se muestran los actores siguientes: el “tesorero”, quien se encargará de validar el
pago por medio de la facturación electrónica que se genera con el “PAC” (Proveedor Autorizado
de Certificación) (Facturama, 2021), que representa a la persona moral autorizada por el SAT
(Servicio de Administración Tributaria) con el fin de procesar y generar los comprobantes fiscales
de manera digital. Además, se coloca el actor de la “pasarela de pago”, el cual representa el medio
por el cual se valida el pago por medio de tarjeta bancaria. Todos los actores tienen que estar
registrados mediante un usuario y contraseña para poder iniciar sesión en el sistema. El
“participante” podrá solicitar los cursos que requiera, hacer el pago con opción de tarjeta bancaria,
pág. 963
inscribirse al curso una vez validado su pago, así como solicitar su constancia vía electrónica. El
actor “administrativo” se encarga de validar los perfiles de los usuarios, registrar los cursos y
emitir las constancias. En este caso no se incluye el actor del usuario “secretario”, ya que las
constancias ya tendrán su firma de forma digital en el formato. El “Director” podrá solicitar el
reporte de los ingresos que se generan de los cursos que se han pagado hasta en el momento de
su consulta.
A partir del diagrama anterior, se definen las clases a mostrar en el diagrama de clases, y con sus
atributos y métodos.
Tabla 3: Clases, atributos y métodos para realizar el modelo de datos para el desarrollo del
sistema de gestión de cursos en línea del CCPGRO.
Clases, atributos y métodos
Clase
Atributos
Métodos
Curso
id, costo, fechainicio, nombre, tipo
getcurso(), listacursos(), setcurso()
Inscripción
id, idcurso, idparticipante
getparticipante(), listaparticipantes(),
setparticipante()
Pago
id, fecha, formadepago, idinscripcion,
idtransaccion, metodopago, usocfdi
getpago(), listarpagos(), setpago()
Factura
id, estado, fecha, numfactura, UUID
Getfactura(), listarfacturas(), setfactura(),
timbrar()
Administrativo
id, rol
getadministrativo(),
listaadministrativos(),
setadministrativos()
Participante
id, idperfil, RFC
getparticipante(), listaparticipantes(),
setparticipante()
Constancia
id, idcurso, idparticipacion, folio
getconstancia(), listaconstancia()
setconstancia()
Video
id, enlace, fechacaducidad, nombre,
precio
NO APLICA
Fuente: Elaboración propia.
En la Tabla 3 se describen las clases definidas a partir del diagrama de casos de la Figura 4, donde
se destacan las clases Curso, Inscripción, Pago, Factura, a través de las cuales existe una relación
una tras otra, es decir, a un curso puede tener de 0 a muchas inscripciones, una inscripción está
pág. 964
asociada a un solo pago y un pago esta asociados a una sola factura. Estas son las clases
fundamentales para gestionar los cursos que los participantes podrán adquirir a través del sistema
web a desarrollar.
A continuación, se muestra en la Figura 5 el diagrama de clases elaborado a partir de lo descrito
en la Tabla 3.
Figura 5: Diagrama de clases para el sistema de gestión de cursos para el CCPGRO
. Fuente: Elaboración propia. Realizada con la aplicación EA (Sparx Systems Pty Ltd., 2023).
En la Figura 5 se muestran además de las clases, sus atributos y métodos, las relaciones existentes
entre cada una de estas y su cardinalidad.
Es importante señalar, que la clase video, corresponde a los videos de los cursos que se proveen
a los participantes una vez inscritos a estos.
A partir de las clases descritas, sus atributos y métodos, para crear el diagrama entidad-relación,
es fundamental definir las entidades, atributos y sus relaciones, esto se muestra en la Etapa 3, que
se muestra a continuación.
Etapa 3: Modelo entidad-relación
De acuerdo con (Pressman, 2002), el diseño de datos que en ocasiones también se le llama como
arquitectura de datos, crea el modelo de datos o modelo de información representado en un nivel
pág. 965
de abstracción elevado, el cual se refina de forma progresiva para que pueda ser implementado y
procesado por el sistema basado en la computadora.
En esta etapa, como se menciona en el párrafo anterior, se representa el modelo de datos en un
nivel de abstracción de alto, la estructura de los datos que será implementado en el sistema para
la gestión de los cursos en línea.
Así también, debido a que el modelo de datos representa relaciones, es decir, asociaciones entre
entidades, donde las relaciones del modelo permiten relacionar los datos del modelo (Sánchez,
2004). Es importante realizar el proceso de normalización. De acuerdo con (Silberschatz, Korth,
& Sudarshan, 2006), cuando se definen correctamente las entidades, las tablas que se puedan
generar a partir del diagrama E-R no necesitan más normalización, sin embargo, esta (la
normalización) puede dejarse a la intuición del diseñador durante el modelado E-R, de manera
formal sobre las relaciones generadas a partir del modelo E-R.
A continuación, en la Tabla 4, se muestran las entidades, atributos, así también aquellos atributos
que son llaves primarias (PK – Primary Key) y sus llaves foráneas (FK – Foreign Key).
Tabla 4: Descripción de las entidades y sus relaciones
Descripción de las entidades y sus relaciones
Entidad
Atributos
Llave primaria
Llaves foráneas
Participante
participante_id, nombre, correo,
perfil, numero, teléfono
participante_id
Constancia
constancia_id, link, folio,
fecha_expedicion
constancia_id
participante_id, curso_id
Inscripción
inscripción_id, fecha,
id_participante, id_curso
inscripción_id
participante_id, curso_id
Pago
pago_id, monto, fecha_pago,
estatus_aprobacion
pago_id,
participante_id, curso_id
Factura
factura_id, monto, fecha
factura_id
participante_id
Video
video_id, titulo, duración, link,
curso_id
video_id
curso_id
Curso
curso_id, titulo, descripción,
fecha_inicio, fecha_fin, costo
curso_id
Administrativo
Id_administrativo, nombre, correo
administrativo_id
Fuente: Elaboración propia.
pág. 966
De acuerdo con lo descrito en la Tabla 4, a continuación, se muestra el resultado obtenido al crear
el diagrama entidad-relación de la Figura 6.
Figura 6: Diagrama entidad-relación para el sistema de gestión de los cursos en línea que ofrece
el CCPGRO.
Fuente: Elaboración propia realizada con la aplicación MySQL. (2021). MySQL Workbench
(Versión 8.0)
CONCLUSIONES
Cada una de las etapas descritas en la sección de resultados del presente artículo, se realizaron
con el fin de obtener el diseño del modelo de datos entidad-relación, de tal forma, que se pueda
implementar para la creación de base de datos del sistema para la gestión de cursos que ofrece el
CCPGRO. El modelo de datos se desarrolla partiendo de un análisis a través del diagrama del
modelo de procesos de negocios (BPM), posteriormente se definieron los requerimientos
funcionales y no funcionales a partir de los cuales se definió el marco conceptual con la detección
de las clases, atributos y métodos representados en el diagrama de clases, y así identificar sus
pág. 967
relaciones las cuales se muestran en el diagrama entidad-relación, para así finalmente mostrar de
una forma normalizada los datos.
El modelo de datos permite cumplir con la primera etapa de la metodología cascada, para
continuar con el diseño del sistema y del software que corresponde a la segunda etapa de dicha
metodología, aunque el diseño del sistema requiere la representación del diseño completo del
sistema, el objetivo del presente trabajo es mostrar como resultado el modelo de datos como
primera entrega para establecer las bases para continuar con el diseño del sistema. El modelo de
datos que se muestra en el presente trabajo tiene un impacto de tipo tecnológico en el CCPGRO,
debido a que esta primera entrega proporciona que la información que se maneja durante la
gestión de los cursos en línea se encuentre de forma consistente y homogénea, aportando un gran
beneficio para quienes participan en los cursos en línea.
REFERENCIAS
Analitica. (2011). Manual de diagramación de procesos bajo estándar BPMN. Obtenido de
www.analitica.co: chrome-
extension://efaidnbmnnnibpcajpcglclefindmkaj/http://www.analitica.co/website/images/
stories/documentosTecnicos_SGP/Manual%20de%20Diagramacion%20de%20Proceso
s%20Bajo%20Estandar%20BPMN.pdf
Blanco Reyes, C. (05 de abril de 2018). REInI. Obtenido de reini.utcv.edu.mx:
http://reini.utcv.edu.mx/bitstream/123456789/641/1/004662.pdf
CCPGRO. (2023). Colegio de Contadores Públicos del Estado de Guerrero, A.C. Obtenido de
web.facebook.com/CCPEGRO: https://web.facebook.com/CCPEGRO?locale=es_LA
Digital Future Society y Banco Interamericano de Desarrollo. (2021). Economía de plataformas
y COVID-19. Una mirada a las actividades de reparto, los cuidados y los servicios
virtuales en España y América Latina. Barcelona, España.
Domínguez Domínguez, J. M. (Mayo de 2018). Repositorio Informático Institucional UACH.
Obtenido de repositorio.uach.mx:
http://repositorio.uach.mx/188/1/Formato%20de%20Tesis%202018.pdf
pág. 968
Facturama. (2021). Facturama Blog. Obtenido de facturama.mx: https://facturama.mx/blog/que-
significa/pac/
Gobierno de México. (2022). COVID-19 - Coronavirus. Obtenido de coronavirus.gob.mx:
https://coronavirus.gob.mx/covid-19/
Leach, R. J. (2016). Introduction to Software Engineering . Washington, DC, USA: CRC Press.
M. Ricardo, C. (2009). Bases de datos. México, D.F.: McGraw Hill.
Marqués, M. (2011). Bases de datos. Castellón de la Plana, España: Universidad Jaume I.
Microsoft. (2023). Learn Microsoft . Obtenido de learn.microsoft.com:
https://learn.microsoft.com/en-us/office/troubleshoot/access/database-normalization-
description
Microsoft. (2023). Microsoft. Obtenido de support.microsoft.com:
https://support.microsoft.com/es-es/office/access-sql-conceptos-b%C3%A1sicos-
vocabulario-y-sintaxis-444d0303-cde1-424e-9a74-e8dc3e460671
Pressman, R. S. (2002). Ingeniería del Software. Un enfoque práctico (Quinta ed.). Aravaca,
Madrid: McGraw-Hill/Interamericana de España, S.A.U.
Rocha C., R. (Febrero de 2017). Universidad Nacional de Colombia. Obtenido de
medellin.unal.edu.co:
https://www.medellin.unal.edu.co/~fjmoreno/bd1/ModeloERRochav8.pdf
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). El lenguaje unificado de modelado. Manual de
referencia. Pearson Educación, S.A.
Saavedra-Gonzales, A. (noviembre de 2016). Repositorio Institucional de la Universidad de
Piura. Obtenido de pirhua.udep.edu.pe:
https://pirhua.udep.edu.pe/bitstream/handle/11042/2740/ING_571.pdf?sequence=1&is
Allowed=y
Sánchez, J. (2004). CN. Obtenido de ciberninjas.com:
https://drive.google.com/file/d/177YFW1w002Kz0_Z4DQ2V4XmztZOen5dt/view
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2006). Fundamentos de bases de datos. Aravaca,
Madrid: McGraw-Hill/Interamericana de España, S.A.U.
pág. 969
Sommerville, I. (2011). Ingeniería de software. México: Pearson Education, Inc.
Sparx Systems Pty Ltd. (2023). sparxsystems. Obtenido de sparxsystems:
https://sparxsystems.com/products/ea/