ingeniería de datos
TRANSCRIPT
INGENIERÍA DE DATOS GUÍA DE APRENDIZAJE VIRTUAL
DR. LUIS ENRRIQUE BOY CHAVIL DR. JUAN CARLOS OBANDO ROLDÁN
INGENIERÍA DE DATOS
1ra. Edición
Luis Enrrique Boy Chavil
Juan Carlos Obando Roldán
Derechos Reservados
Octubre del 2021
No está permitida la reproducción total o parcial de esta obra mediante ningún sistema electrónico
o mecánico ni puede ser fotocopiado, ni a través de algún tratamiento informático, sin
consentimiento expreso del autor.
Atención al cliente: 99-5959450 / 044-285249
Agradecimientos
Deseo presentar mi agradecimiento y respetos a mis queridos Padres, quienes desde allá en
el cielo, son mi principal fuente de inspiración; gracias a ellos aprendí que los valores individuales son
la virtud más importante de un ser humano.
Luis Boy Chavil
Dedicatoria
Dedico este libro a mi familia, por su paciencia y tanto amor hacia mi persona.
El Autor principal
ACERCA DEL AUTOR PRINCIPAL
Luis Boy Chavil es graduado en Computación en la Universidad Nacional Mayor de San Marcos;
también es graduado en Ingeniería de Sistemas en la Universidad Señor de Sipán, tiene una Maestría
en Docencia Universitaria de la Universidad César Vallejo y otra Maestría en Ingeniería de Sistemas
con mención en Administración de Tecnologías de la Información en la Universidad Nacional de
Trujillo. Además, tiene un Doctorado en Educación por la Universidad César Vallejo. Ha trabajado en
diversas empresas en desarrollo de aplicaciones informáticas desde el año 1981 y ha desempeñado
las labores de académicas de docente en el IST Cibertec, IST DataPro, IST San Agustín, Universidad
Garcilaso de la Vega, Universidad San Martín de Porres, IST Cima´s, Universidad Privada del Norte,
Universidad Antenor Orrego, Universidad Nacional de Trujillo, Universidad Privada San Pedro de
Chimbote, Universidad César Vallejo y Universidad Privada de Trujillo.
Asimismo, ha desempeñado cargos administrativos importantes en diversas Instituciones entre
las que se resumen el cargo de Jefe de la división de Informática de Carbell Ing. SRL, Director del
Centro de Investigación y Promoción de Estudios Superiores (CIPES), Director del Programa de
Educación a distancia de la Universidad San Martín de Porres, Jefe de Proyectos de la Unidad de
Informática de la UNMSM, Jefe del departamento de Informática del IST Cima´s, Jefe del
departamento de Computación y Jefe de la Carrera de Ingeniería de Sistemas de la Universidad
Privada del Norte, Director de la Escuela de Ingeniería de Sistemas de la Universidad Privada de
Trujillo, igualmente de la Universidad César Vallejo y Director en ejercicio de la Escuela de Ingeniería
de Sistemas de la Universidad Nacional de Trujillo. Actualmente, desarrolla las cátedras de Ingeniería
de datos en la Escuela de Ingeniería de Sistemas de la Universidad Nacional de Trujillo.
Sesión 1: Introducción al modelado de sistemas con la metodología RUP
…………………………………. 13
1.1 ¿Qué es UML? …………………………………. 13
1.2 Pero, ¿porqué son útiles los modelos? …………………………………. 13
1.3 ¿Qué es el proceso de desarrollo de software? …………………………………. 14
1.3.1 Modelos de los procesos de desarrollo de software …………………………………. 14
a) El Modelo en Cascada …………………………………. 14
b) Desarrollo Evolutivo …………………………………. 15
c) Ingeniería del software basada en componentes …………………………………. 16
1.4 El Proceso Unificado …………………………………. 17
1.4.1 Disciplinas …………………………………. 19
1.4.2 Fases del proceso de desarrollo del software …………………………………. 20
1.4.2.1 Fase de Inicio …………………………………. 20
1.4.2.2 Fase de Elaboración …………………………………. 21
1.4.2.3 Fase de Construcción …………………………………. 21
1.4.2.4 Fase de Transición …………………………………. 22
2. Proceso de relevamiento de datos para conocer el manejo de la información
…………………………………. 22
2.1 Concepto y objetivos del relevamiento …………………………………. 22
2.2 ¿Qué relevamos para realizar el diagnóstico de la situación actual?
…………………………………. 23
2.3 Metodología de la etapa de relevamiento: …………………………………. 23
2.4 Análisis documental del estudio preliminar de los procesos académicos de la Universidad Nacional de Trujillo.
…………………………………. 29
2.4.1 Revisión y Análisis documental …………………………………. 29
2.4.2 Concepto e identificación de requisitos de los principales procesos
…………………………………. 29
2.4.3 Elaboración de herramientas para el relevamiento detallado …………………………………. 31
3. El Modelo de Negocio …………………………………. 37
3.1 Actor de Negocio …………………………………. 38
3.2 Caso de uso de Negocio …………………………………. 38
3.3 Relación de Asociación …………………………………. 39
3.4 Paquetes …………………………………. 39
3.5 Diagrama de Paquetes …………………………………. 39
3.6 Diagrama de Caso de Uso de Negocio …………………………………. 40
3.7 Diagrama de Objetivos de Negocio …………………………………. 40
3.8 Diagrama de Caso de Uso de Negocio versus Objetivos de Negocio
…………………………………. 40
LABORATORIO Nº 01: Modelo de caso de uso del Negocio - MCUN
…………………………………. 41
Actividad Nº 1 …………………………………. 55
Autoevaluación 1 …………………………………. 56
Sesión 2: Modelado de Análisis del Negocio …………………………………. 57
1. El Modelo de Análisis del Negocio (MAN) …………………………………. 57
Contenido
1.1 ¿Cuáles son los elementos del MAN? …………………………………. 57
1.1.1 Los trabajadores del Negocio …………………………………. 57
1.1.2 Las Entidades del Negocio …………………………………. 59
1.1.3 Realizaciones de caso de uso de negocio …………………………………. 59
1.1.4 Organización del modelo de Análisis …………………………………. 60
1.1.5 Realizaciones del Negocio …………………………………. 60
LABORATORIO Nº 02: Modelo de Análisis del Negocio …………………………………. 61
Actividad Nº 2 …………………………………. 69
Autoevaluación 2 …………………………………. 70
Sesión 3: Diagrama de Estados y de Actividades del MAN …………………………………. 71
1. ¿Cómo define UML a una máquina de estados? …………………………………. 71
1.1 Componentes del diagrama de estados …………………………………. 71
1.1.1 Estado …………………………………. 71
1.1.2 Transición …………………………………. 71
1.1.3 Evento …………………………………. 72
1.1.4 Evento de Inicio …………………………………. 72
1.1.5 Evento de Finalización …………………………………. 72
1.1.6 Decisión …………………………………. 73
1.1.7 Región …………………………………. 73
1.1.8 Punto de salida …………………………………. 74
1.2 Máquina de estado …………………………………. 74
2. ¿Qué son los diagramas de actividades? …………………………………. 75
2.1 ¿Cuáles son los componentes de un diagrama de actividades?
…………………………………. 75
2.1.1 Partición …………………………………. 75
2.1.2 Nodo Inicial …………………………………. 75
2.1.3 Nodo Final …………………………………. 75
2.1.4 Acción …………………………………. 76
2.1.5 Flechas de conexión …………………………………. 76
2.1.6 Nodo de decisión …………………………………. 76
2.1.7 Envío de señal …………………………………. 76
2.1.8 Almacén de datos …………………………………. 76
2.2 Diagrama de Actividades para la solicitud de libros en una biblioteca de la Universidad
…………………………………. 77
LABORATORIO Nº 03: Diagrama de máquina de estado y Actividades
…………………………………. 78
Actividad Nº 03 …………………………………. 88
Autoevaluación 3 …………………………………. 88
Sesión 4: Modelo de Requerimientos …………………………………. 89
1. Requerimientos Funcionales …………………………………. 89
2. Requerimientos no Funcionales …………………………………. 89
3. Descripción de Actores …………………………………. 91
LABORATORIO Nº 04: Diagrama de casos de uso de requerimientos
…………………………………. 94
UNIDAD II: El Modelado de Datos …………………………………. 107
Sesión 5: El Modelado de datos …………………………………. 108
1. ¿Qué es el Modelado de datos? …………………………………. 108
1.1 ¿Qué es una base de datos? …………………………………. 108
1.2 ¿Qué es un sistema de administración de base de datos? …………………………………. 108
1.3 El Modelo Entidad - Relación …………………………………. 109
1.3.1 Las Entidades …………………………………. 109
1.3.2 Clase de Entidades …………………………………. 110
1.3.3 Atributos …………………………………. 110
1.3.4 Atributos Identificadores …………………………………. 110
1.3.5 Tipo de atributos Identificadores …………………………………. 110
1.3.5.1 Atributos de Clave Primaria …………………………………. 110
1.3.5.2 Atributos de Claves Foráneas …………………………………. 111
1.3.5.3 Atributos de Claves Concatenadas …………………………………. 111
1.3.6 Relaciones y Relacionamientos …………………………………. 111
2. Desarrollo de un caso de Modelado de datos …………………………………. 115
LABORATORIO Nº 05: Uso de herramientas CASE en Visual Basic NET para integrar la base de datos de una Biblioteca
…………………………………. 120
Actividad Nº 5 …………………………………. 133
Autoevaluación 5 …………………………………. 134
Sesión 6: Normalización de datos …………………………………. 135
1. ¿Cuáles son las condiciones apropiadas de una base de datos? …………………………………. 135
1.1 ¿Qué es la dependencia funcional? …………………………………. 135
1.1.1 Ley distributiva de las dependencias funcionales …………………………………. 136
1.1.2 Dependencias funcionales parciales …………………………………. 136
1.1.3 Dependencias funcionales multivaluadas …………………………………. 137
1.1.4 Claves Candidatas …………………………………. 137
1.2 ¿Qué es la Normalización de datos? …………………………………. 137
1.3 Reglas de la Normalización de datos …………………………………. 138
1.3.1 Entidad No Normalizada …………………………………. 138
1.3.2 Normalización en Primera Forma Normal - 1NF …………………………………. 139
1.3.3 Normalización en Segunda Forma Normal - 2NF …………………………………. 139
1.3.4 Normalización en Tercera Forma Normal - 3NF …………………………………. 140
1.3.5 Normalización en la Forma Normal de Boyce y Codd – BCNF
…………………………………. 140
1.3.6 Normalización en Cuarta Forma Normal - 4NF …………………………………. 141
1.3.7 Normalización en Quinta Forma Normal - 5NF …………………………………. 141
LABORATORIO Nº 6: Caso de Normalización de datos …………………………………. 142
Actividad Nº 6 …………………………………. 152
Autoevaluación 6 …………………………………. 153
Sesión 7: Lenguaje SQL …………………………………. 154
1. ¿Qué es SQL? …………………………………. 154
1.1 ¿Qué es SQL Server? …………………………………. 154
1.2 Creación de una Base de datos …………………………………. 155
1.3 ¿Qué es una Tabla de datos? …………………………………. 157
1.4 Creación de tablas de base …………………………………. 158
1.5 Alteraciones de Tablas de base …………………………………. 161
2. Consulta de datos …………………………………. 163
LABORATORIO Nº 07: Script de una base de datos y Consultas …………………………………. 168
Actividad Nº 7 …………………………………. 175
Autoevaluación 7 …………………………………. 176
Sesión 8: Integridad de datos …………………………………. 177
1. ¿Qué es la Integridad de datos? …………………………………. 177
1.1 ¿Cuáles son las clases de Restricción de Integridad de datos? …………………………………. 177
1.1.1 Restricciones Inherentes …………………………………. 177
1.1.2 Restricciones Programadas …………………………………. 178
LABORATORIO Nº 8: BASE DE DATOS CON RESTRICCIONES DE …………………………………. 182
Actividad Nº 8 …………………………………. 189
Autoevaluación 8 …………………………………. 190
UNIDAD III: PROGRAMACIÓN DE BASES DE DATOS …………………………………. 191
Sesión 9: Vistas de datos …………………………………. 192
1. ¿Qué es una vista de datos? …………………………………. 192
1.1 ¿Qué ventajas se obtiene con el uso de Vistas? …………………………………. 192
1.2 Sentencia CREATE VIEW para la creación de Vistas …………………………………. 193
1.3 Modificación de Vistas …………………………………. 195
1.4 Eliminación de Vistas …………………………………. 195
1.5 Vistas actualizables …………………………………. 195
2. ¿Qué son las Instantáneas? …………………………………. 196
LABORATORIO Nº 09: VISTAS DESARROLLADAS SOBRE LA BASE DE DATOS
…………………………………. 197
Actividad Nº 9 …………………………………. 200
Autoevaluación 9 …………………………………. 201
Sesión 10: Procedimientos Almacenados …………………………………. 202
1. ¿Qué son los procedimientos almacenados? …………………………………. 202
1.1 ¿Cuáles son los tipos de procedimientos almacenados? …………………………………. 202
1.2 Creación de procedimientos almacenados …………………………………. 203
1.3 ¿Qué restricciones se debe considerar para los procedimientos almacenados?
…………………………………. 203
2. Procedimiento almacenado y Vista de datos con una aplicación en Visual Basic
…………………………………. 205
LABORATORIO Nº 10: PROCEDIMIENTOS ALMACENADOS …………………………………. 209
Actividad Nº 10 …………………………………. 213
Autoevaluación 10 …………………………………. 214
Sesión 11: Funciones escalares y de tablas …………………………………. 215
1. ¿Qué es una Función definida por el usuario – UDF ? …………………………………. 215
1.1 ¿Cuáles son los componentes de una UDF? …………………………………. 215
1.2 ¿Qué es una Función Escalar? …………………………………. 215
1.3 Ejemplos de funciones escalares …………………………………. 216
2. ¿Qué es una función de tabla? …………………………………. 219
3. ¿Qué son las funciones integradas? …………………………………. 220
3.1 Función SUM …………………………………. 220
3.2 Función MAX …………………………………. 221
3.3 Función MIN …………………………………. 222
3.4 Función COUNT …………………………………. 222
3.5 Función AVG …………………………………. 223
3.6 Función CAST y CONVERT …………………………………. 223
3.7 Ejemplo de la función CONVERT …………………………………. 224
3.8 Función DateDiff …………………………………. 224
4. Funciones de cadenas …………………………………. 224
4.1 Función LEN …………………………………. 224
4.2 Funciones Upper y Lower …………………………………. 225
4.3 Función LEFT …………………………………. 225
4.4 Función Right …………………………………. 226
4.5 Función Substring …………………………………. 226
4.6 Función TRIM …………………………………. 226
4.7 Funciones LTrim y RTrim …………………………………. 227
4.8 Función Replace …………………………………. 227
4.9 Funcion Replicate …………………………………. 228
LABORATORIO Nº 11: IMPLEMENTACIÓN DE FUNCIONES …………………………………. 229
Actividad Nº 11 …………………………………. 231
Autoevaluación 11 …………………………………. 232
Sesión 12: Triggers …………………………………. 233
1. ¿Qué es un Triggers? …………………………………. 233
1.1 ¿Qué ventajas y desventajas se presentan con el uso de Triggers?
…………………………………. 234
1.2 Triggers para operaciones DML …………………………………. 234
LABORATORIO Nº 12: IMPLEMENTACIÓN DE TRIGGERS …………………………………. 235
Actividad Nº 12 …………………………………. 240
Autoevaluación 12 …………………………………. 241
Introducción
La presente obra pretende formar parte de la biblioteca de un estudiante universitario que
necesita construir bases de datos para desarrollar soluciones informáticas a diversos problemas de
las organizaciones empresariales; por esa razón he desarrollado una primera unidad donde hago un
análisis de la realidad problemática de una empresa y utilizo diversas herramientas para el
reconocimiento adecuado de esta problemática de tal manera que la solución que se plantea a
continuación se encuentre perfectamente alineada.
La obra se encuentra dividida en tres unidades; cada una de las cuáles aborda diversos temas en
04 sesiones de aprendizaje respectivamente. La primera unidad se denomina Modelado de Procesos
con la metodología RUP; ya que aquí se tratan temas relacionados a la empresa así como a la
identificación y descripción de problemas con el manejo de la información; y posteriormente al
planteamiento de soluciones desde la perspectiva del modelamiento de procesos con el uso de la
metodología RUP (Rational Unified Process). Concretamente, en esta primera unidad se desarrolla
las primeras 4 sesiones; entre las cuales tenemos: Sesión 1: Introducción al modelado de sistemas
con la metodología RUP, donde se aprenderá en primer lugar diversos conceptos relacionados a las
técnicas y metodologías del desarrollo de sistemas. En la parte práctica de la sesión se analiza un
problema relacionado a la compra de abastecimiento de almacenes de una empresa de abarrotes y
se construye una representación gráfica a través de la herramienta Rational Software Architec (RSA)
sobre el Modelado de casos de uso del Negocio, mostrando los diagramas de Actores del negocio,
casos de uso del negocio, y Objetivos del negocio; posteriormente, en la Sesión 2: Modelado de
Análisis del Negocio, se construye una vista interna del caso anterior a través del modelado de análisis
del negocio, en esta sesión se aprende a elaborar los diagramas de las Entidades del negocio, las
realizaciones del negocio, y los trabajadores del negocio. En la Sesión 3: Diagrama de estados y de
actividades del MAN, se construye los diagramas de máquinas de estado de cada una de las entidades
del negocio, así como se elaboran los diagramas de actividades de los respectivos casos de uso del
negocio. Finalmente, en la Sesión 4: Modelado de requerimientos, se construye una vista de casos
de uso de requerimientos del sistema.
La segunda unidad aborda los temas relacionados propiamente a las bases de datos, desde la
perspectiva del modelado de datos, hasta la implementación y uso de bases de datos. Esta unidad
contiene la Sesión 5: El modelado de datos, que se refiere a los objetos y técnicas utilizadas para la
representación gráficas de las bases de datos, a través de los modelados de datos ; en esta sección
se construye una aplicación en Visual Basic para consolidar en un menú de opciones las operaciones
de mantenimiento de tablas de una base datos, posteriormente, en la Sesión 6: Normalización de
datos; se desarrolla un conjunto de normas que se aplican de forma ordenada para asegurar la
reducción y control de la redundancia de una base de datos. En la Sesión 7: Lenguaje SQL, se explora
las bases de datos a través del uso adecuado de sentencias del SQL y en la Sesión 8: Integridad de
datos se desarrollan aplicaciones para asegurar que las bases de datos respondan adecuadamente a
las operaciones para las que fueron creadas.
La tercera unidad se denomina Programación de bases de datos, debido a que en esta unidad se
dá énfasis a la elaboración de scripts del lenguaje Transac SQL con la finalidad de construir, consultar
y dar mantenimiento a bases de datos. Esta unidad contiene la Sesión 9: Vistas de datos, con la
finalidad de realizar diversas consultas de datos que será solicitado en forma reiterada y que por
tanto su implementación se aplica en el lado del servidor para mejorar la performance del sistema,
también se desarrolla la Sesión 10: Procedimientos almacenados, para la implementación de diversas
aplicaciones con la base de datos , en la Sesión 11: Funciones escalares y de tablas se desarrolla
operaciones con el uso de funciones del sistema, y funciones escalares que devuelven datos
concretos, y funciones de tabla que devuelven conjuntos de datos desarrollados en respectivas tablas
de base. Finalmente, se desarrolla la Sesión 12: Triggers, con la finalidad de contribuir a la integridad
de una base de datos.
UNIDAD I
Modelado de Procesos con la metodología
RUP
Capacidades
▪ Aplica la metodología orientada a objetos al análisis y diseño de soluciones
informáticas.
▪ Desarrolla el modelado de artefactos de un sistema.
▪ Utiliza herramientas de la metodología RUP, para el desarrollo del modelado de
sistemas.
MODELADO DE PROCESOS Página 13
Sesión 1
Introducción al modelado de sistemas con la metodología RUP
1.1 ¿Qué es UML?
UML es un lenguaje unificado de modelamiento (Unified Modeling Languaje) que permite la
construcción debidamente documentada de sistemas orientado a objetos. Este lenguaje se ha
denominado Unificado debido a que está conformado principalmente por las herramientas de
tres grandes metodologías orientadas a objetos de los autores Booch, Rumbaugh y Jacobson;
aunque es importante aclarar que en este lenguaje unificado también han participado otros
grandes autores.
UML está provisto de un conjunto de herramientas denominados artefactos distinguidos
por una notación estándar y específica para la elaboración de sistemas orientados a objetos.
UML no es una Metodología, para ello se utilizará RUP como metodología orientada a la
construcción de sistemas orientada a objetos. UML se utiliza para comprender, diseñar, y
mantener los procesos y la información de los sistemas de software al facilitar las herramientas
y la notación estándar necesaria para el modelado de la estructura estática y el comportamiento
dinámico de los sistemas.
Figura 1: Notaciones de diversos autores de UML
1.2 Pero, ¿porqué son útiles los modelos?
Los modelos son representaciones visuales a través de gráficas, o imágenes de alguna
percepción; en nuestro caso, se trata de modelos de software, o por lo menos de algunas partes
del software. La importancia del uso de modelos del software radica en que es más entendible,
MODELADO DE PROCESOS Página 14
fácil de comunicar, más flexible y fácil de adaptar que un conjunto de líneas de código de los
prototipos de sistemas; incluso, resulta más barato para el mantenimiento de los sistemas, pues
gráficamente es más fácil ubicar anomalías en el software para corregirlos rápidamente. Frente
a todas estas ventajas, vale la pena destacar una desventaja de los modelos; pues al tratarse de
una representación gráfica de una percepción; puede ocurrir que si otras personas muestran
una gráfica diferente de su propia percepción particular de los objetos; esto llevaría a la
confusión o al caos; sin embargo, aquí es donde cobra una gran importancia el uso de estándares
como UML que siendo un lenguaje de modelado unificado proporciona las herramientas
adecuadas para la representación precisa de cada una de las partes del software. Si todos los
participantes hablan UML, entonces las imágenes tendrán el mismo significado para todos
aquellos que las observen.
1.3 ¿Qué es el proceso de desarrollo de software?
El proceso de desarrollo del software se refiere al conjunto de actividades conducentes a la
producción del producto software. Actualmente, existe una diversidad de procesos de
desarrollo de software; sin embargo, vale la pena distinguir aspectos comunes entre ellos:
- Especificación del software
En este punto, es primordial definir adecuadamente cuál será la funcionalidad del
software y cuáles serán las restricciones de su operación en el futuro.
- Diseño e implementación del software
El producto software debe estar perfectamente alineado a las especificaciones
establecidas.
- Evolución del software
El software debe responder adecuadamente a las condiciones cambiantes del cliente y
de las circunstancias en que dicho software operará.
1.3.1 Modelos de los procesos de desarrollo de software
Los modelos de procesos de desarrollo de software son abstracciones de los procesos que
se pueden utilizar para explicar diferentes enfoques para el desarrollo de software. Son en
realidad marcos de trabajo del proceso. Entre los más destacados, tenemos:
a) El Modelo en Cascada
Este modelo es uno de los más antiguos, pues la concepción del software se hacía muy
dependiente entre sus fases o etapas, ya que se pretendía terminar una fase como requisito
para continuar la siguiente fase. Este modelo está compuesto por las siguientes actividades:
MODELADO DE PROCESOS Página 15
- Análisis y definición de requerimientos
En esta fase, los servicios del sistema, así como las restricciones y metas del sistema se
definen en un proceso de relevamiento de datos que por lo general se desarrolla
directamente con los usuarios.
- Diseño del sistema y del software
El diseño del software y del sistema identifica y desarrolla la arquitectura de las
abstracciones del sistema y del software.
- Implementación y prueba de módulos
Se debe verificar que los módulos y demás unidades del software cumplan cada una de
sus propias especificaciones.
- Integración y prueba del sistema
Los módulos y demás unidades del software se deben integrar, así como debe existir
una prueba integral del sistema para asegurar que está cumpliendo los requerimientos
del software. Luego será entregado al cliente.
- Operación y Mantenimiento
El sistema integrado es instalado en las unidades de cómputo operativas y son puestas
en funcionamiento. El mantenimiento de las partes del sistema es un paso que se deberá
tener previsto a fin de corregir las fallas del software que permita adaptar el sistema a
nuevos desafíos.
b) Desarrollo Evolutivo
El desarrollo evolutivo del software elabora e implementa una versión inicial del
software y la expone a las críticas del usuario; luego se corrigen estas observaciones y se van
generando nuevas versiones del software a modo consecutivo hasta lograr la satisfacción
Figura 2: Modelo en Cascada del proceso de desarrollo del Software
MODELADO DE PROCESOS Página 16
plena de dichos usuarios del software. En la siguiente gráfica se muestra las actividades de
esta metodología:
c) Ingeniería del software basada en componentes
En todos los procesos de desarrollo de software existe la necesidad de la reutilización
de software lo que implica que algunas partes del software puede ser requerido en las
nuevas aplicaciones o que existen servicios que serán reutilizados en otros proyectos sin
importar sus características particulares.
El enfoque basado en la reutilización está formado por un conjunto de componentes de
software reutilizables y de algunos marcos de trabajo de integración para dichos
componentes. A continuación, se muestra las etapas de este enfoque:
- Especificación de requerimientos
Esta etapa se lleva a cabo con el apoyo de los usuarios para establecer los requisitos
para el software.
- Análisis de componentes
Se identifican aquellos componentes que le darán funcionalidad al software.
Figura 3: Desarrollo evolutivo del software
MODELADO DE PROCESOS Página 17
- Modificación de requerimientos
En esta etapa se analizan los componentes en base a los requerimientos establecidos
para ver su funcionalidad, y de ser posible se realiza su modificación; de lo contrario, se
vuelve a la etapa anterior para analizar nuevos componentes.
- Diseño del sistema con reutilización
En esta etapa se diseña un marco de trabajo para el sistema. Los diseñadores toman en
cuenta los componentes que se reutilizan y organizan el marco de trabajo para que los
satisfaga.
- Desarrollo e integración
En esta fase, los componentes desarrollados se integran.
- Validación del sistema
El proceso por el cuál el sistema es puesto a punto con un control de verificación de
calidad del software.
1.4 El Proceso Unificado
El proceso unificado conocido como RUP (Rational Unified Process) que significa Proceso
Unificado de Rational; es un producto del proceso de desarrollo del software que proporciona
el marco de trabajo genérico necesario para el desarrollo de sistemas de diversa índole.
El proceso unificado es un marco de trabajo estándar basado en la metodología orientada a
objetos que contiene los mecanismos necesarios para la construcción de software y su
documentación pertinente a fin de facilitar el mantenimiento y correcciones posteriores, en el
afán de conseguir su fácil adecuación a los cambios propios del desarrollo de la humanidad.
RUP está desarrollado bajo la tecnología de la ingeniería del software basado en
componentes, cuya interconexión se realiza por interfases; asimismo, RUP está dirigido por
casos de uso, centrado en la arquitectura y además es Iterativo e Incremental.
Figura 4: Ingeniería del software basada en componentes
MODELADO DE PROCESOS Página 18
- Proceso dirigido por Casos de Uso
Los casos de uso expresan básicamente los requerimientos del cliente; de ahí que, el
enfoque dirigido a través de los casos de uso permite una representación adecuada de
estos requerimientos y su relación con el entorno de los sistemas.
- Proceso Centrado en la Arquitectura
Teniendo en cuenta que el concepto Arquitectura de un sistema se refiere a la
organización o estructura de un sistema y cada una de sus partes interrelacionadas.
Asimismo, la arquitectura ejecutable del sistema se refiere a su implementación parcial
que se construye para identificar algunas funciones y propiedades propias del sistema.
RUP se ha concebido sobre la base de la arquitectura ejecutable por medio de la cuál se
construyen partes del sistema dentro de un mecanismo de prototipo evolutivo.
- Proceso iterativo e Incremental
RUP se ha desarrollado con el modelo iterativo e incremental debido a que este modelo
plantea la implementación del proyecto de software a través de diversas Iteraciones,
con lo cual se pueden definir objetivos por cumplir en cada iteración y así poder ir
completando todo el proyecto iteración por iteración. En cada iteración se produce un
ciclo de vida en cascada a menor escala, el cual se limita a través de sus propios objetivos
y las evaluaciones de las iteraciones precedentes. En la siguiente gráfica, se muestra la
secuencia de actividades hasta la realización de las fases del sistema.
Figura 5: Ciclo de vida iterativo e incremental
MODELADO DE PROCESOS Página 19
1.4.1 Disciplinas
Las disciplinas conllevan los flujos de trabajo que están conformados por un conjunto
de pasos o actividades para la culminación de cada fase. Entre las disciplinas de primer orden
tenemos: Modelado del Negocio, Requisitos, Análisis y diseño, Implantación, Pruebas y
Despliegue; asimismo, las disciplinas de segundo orden delimitan el sistema, la gestión del
proyecto, gestión de configuración y la gestión del cambio.
A continuación, se muestra la gráfica que detalla el progreso por iteraciones en la
implementación de proyectos de software.
Las disciplinas señaladas en el gráfico encajan en las siguientes fases del proceso de
desarrollo del software:
Figura 7: Fases del proceso de desarrollo del Software
Figura 6: Iteraciones del RUP
MODELADO DE PROCESOS Página 20
1.4.2 Fases del proceso de desarrollo del software
1.4.2.1 Fase de Inicio
En esta fase se elabora el análisis del negocio, así como la descripción general del
producto final. Aquí se debe responder las siguientes preguntas:
- ¿Cuáles son las principales funciones del sistema para los usuarios más importantes?
- ¿Cómo podría ser la mejor arquitectura del sistema?
- ¿Cuál es el plan del proyecto y cuánto será el costo de desarrollo del producto software?
Los artefactos que se desarrollan en esta fase son:
- Enunciado de los requerimientos funcionales y no funcionales del sistema;
generalmente planteados como casos de uso del negocio.
- Un esquema general de la arquitectura
- Descripción de los objetivos del proyecto
- Versión preliminar del plan del proyecto
- Modelo del Negocio
- Puntos de control, denominado hitos para el cumplimiento y evaluación de los objetivos
del proyecto; en este caso, se responderá las siguientes preguntas:
o ¿Cuáles son los límites del sistema?
o ¿Quiénes son los stakeholders (personas involucradas con el sistema)?
o ¿Cuáles son los requisitos funcionales del sistema?
o ¿La arquitectura planteada para el sistema soportará adecuadamente sus
características?
o ¿Cuáles son los riesgos críticos del sistema?
o ¿Cómo se ha previsto la mitigación de los riesgos identificados?
o ¿El uso del producto software justifica la relación beneficio-costo?
o ¿Cuáles son los alcances de los estudios de factibilidad económica, técnica, y
operacional del proyecto?, ¿Es factible el proyecto?
o ¿Hay aprobación de los usuarios del proyecto?
MODELADO DE PROCESOS Página 21
1.4.2.2 Fase de Elaboración
Durante la fase de elaboración se especifica en detalle los casos de uso del producto y se
diseña la arquitectura que dará soporte al producto. En esta fase se persigue las siguientes
responsabilidades:
- Afianzar de manera firme y precisa la concepción del problema.
- Elaborar la arquitectura más adecuada para el producto.
- Implementar un plan firme y detallado para las demás iteraciones del proceso de
desarrollo del software.
- Aplicar los planes de mitigación de riesgos a fin de eliminarlos al máximo.
- Los artefactos que se construyen en esta fase son:
o Prototipo de arquitectura final del proyecto
o Elaboración de casos de prueba
o Descripción detallada y precisa de la mayoría de los casos de uso del sistema.
o El plan del proyecto, detallado y preciso para las demás iteraciones.
o Puntos de control, denominado Hitos para el cumplimiento de esta fase; en este
caso, se responderá las siguientes preguntas:
▪ ¿Cuál es la línea base de la arquitectura del software?
▪ ¿Cuáles son las condiciones de robustez y adaptabilidad de esta línea
base?, ¿Puede evolucionar con facilidad?
▪ ¿Se ha identificado y mitigado los riesgos más graves para el desarrollo
del producto software?
▪ ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para
respaldar una agenda, costes y calidad del producto en forma realista?
▪ ¿El proyecto ha definido claramente la recuperación de la inversión a
través de un estudio económico y de factibilidad?
▪ ¿Hay aprobación de los financistas del proyecto y sus stakeholders más
relevantes?
1.4.2.3 Fase de Construcción
En esta fase, se crea el producto software. La línea base de la arquitectura crece hasta
convertirse en el sistema integrado y completo. Los artefactos producidos durante esta fase,
son:
- El sistema software
MODELADO DE PROCESOS Página 22
- Los casos de uso de prueba
- Los manuales de usuario
- Puntos de control, como Hitos para el cumplimiento de la capacidad operativa inicial;
en este caso, se responderá las siguientes preguntas:
o ¿El producto ha alcanzado su nivel de estabilidad para ser utilizado?
o ¿El producto provee alguna funcionalidad de valor?
o ¿Todas las partes están listas para comenzar la transición?
1.4.2.4 Fase de Transición
En esta fase se construye la versión Beta; es decir la primera versión del producto final;
sin embargo, las iteraciones de esta fase continuarán agregando características al software a
pesar de que el sistema ya se encuentra operativo por los usuarios. Los artefactos construidos
de esta fase son los mismos de la fase de construcción. El trabajo más relevante de esta fase
está orientado a corregir y extender la funcionalidad del sistema. Al finalizar esta fase; el control
se lleva a cabo con el lanzamiento oficial del producto al haber alcanzado los objetivos fijados
desde la fase de inicio y haber alcanzado la satisfacción plena de los usuarios del sistema.
2. Proceso de relevamiento de datos para conocer el manejo de la información
2.1 Concepto y objetivos del relevamiento
Cuando un empresario advierte un problema en el manejo de la información,
automáticamente analiza las posibilidades que implica su impacto en la toma de decisiones. En
este sentido, se requiere realizar un análisis del problema, que desde la perspectiva del
relevamiento, se puede desarrollar en tres etapas; de Relevamiento, de Diagnóstico y de
Propuestas. Sin embargo, dado que este trabajo se concentra en el aspecto de la etapa de
relevamiento, entonces conceptualizaremos el término relevamiento tal como lo utilizaremos
en este campo; que tiene que ver con la acción de relevar y de recolectar. Teniendo en cuenta
el significado que el diccionario de la RAE da de sus raíces etimológicas: “relevar. (Del lat.
relevāre). tr. Hacer de relieve algo.1, recolectar. (Del lat. recollectum, supino de recolligĕre,
recoger). tr. Juntar personas o cosas dispersas. En este contexto, se toman las acepciones
relacionadas con la acción de poner algo en relieve y la acción de recolectar.
1 Microsoft® Encarta® 2006. © 1993-2005 Microsoft Corporation. Reservados todos los derechos
MODELADO DE PROCESOS Página 23
El objetivo de la etapa de relevamiento es elaborar un informe descriptivo que permita
mostrar los detalles de la organización tal como es, dando a conocer cómo funcionan sus
procesos, sin distinguir problemas específicos.
2.2 ¿Qué relevamos para realizar el diagnóstico de la situación actual?
Es importante distinguir y reconocer los siguientes aspectos de la organización:
- Antecedentes históricos de la organización
- Aspectos sincrónicos de la organización
o Organización interna: Visión, misión, objetivos empresariales, cultura y valores
o Organización externa: Situación social, comercial, política, económica y
financiera.
- Aspectos diacrónicos de la organización
o Situación actual de la organización estructurada en procesos.
2.3 Metodología de la etapa de relevamiento:
El relevamiento requiere de amplitud de criterio con el objeto de acceder e incorporar
información significativa, pertinente, relevante y confiable, objetiva. Dentro de la etapa de
relevamiento se deben realizar las siguientes actividades específicas:
2.3.1 Captar datos pertinentes:
Según Jaime Podestá Castro y Héctor Luchessa2 recoger información, es el primer paso,
pero además es determinante de los resultados del análisis, por consiguiente, debe ser veraz,
completa y actualizada para poder alcanzar los resultados deseados. Requiere dedicación,
esfuerzos y meticulosidad, es como asegurarse que están todos los naipes para empezar a jugar.
Para captar datos3 es necesario saber ¿cuáles son?, ¿dónde están? y ¿con que herramientas?
Se debe detectar qué información se necesita y limitar el nivel de particularidad o
especificidad necesario, para evitar que la tarea sea infinita y se transforme en una autopsia.
Genéricamente podemos decir que se requiere de información para conocer el campo de
estudio, tanto del contexto próximo de la organización relacionado con la problemática a
estudiar, como interna y específica de la organización en cuestión. Puede ser de naturaleza
cuantitativa, como cualitativa.
2 “diagnóstico / evaluación sistemática de los problemas de la empresa” Edit. Macchi 1973 3 dato1. (Del lat. datum, lo que se da). Antecedente necesario para llegar al conocimiento exacto de algo o para deducir las consecuencias legítimas de un hecho. || 2. Inform. Información dispuesta de manera adecuada para su tratamiento por un ordenador.
MODELADO DE PROCESOS Página 24
2.3.2 Organizar y sistematizar los datos
Según Fernando Magdalena4 el relevamiento no es sólo recoger información, se
requiere que los datos colectados sean adecuadamente ordenados (armar el rompecabezas) y
sistematizados en esquemas coherentes que permitan describir y explicar la situación objeto de
estudio. La información que se va recolectando se debe ir registrando en soportes manuales o
electrónicos, para posibilitar la consulta en todo momento, yendo de lo general a lo particular o
específico.
2.3.2.1 Instrumentos de uso personal para captar datos
a) Los “cuadernos o fichas de trabajo” generados por el Ingeniero de proyecto
En ellos debe constar información cronológica y los contenidos específicos: Por ejemplo; en
caso de entrevistas: datos de la empresa, Plan de la entrevista, datos del entrevistado, otras
entrevistas alternativas previstas, datos obtenidos del tema abordado, conclusiones y
evaluación de las entrevistas.
b) Los “papeles de trabajo” con opiniones y comentarios privados
Son para uso personal del Ingeniero de proyecto y nunca pueden quedar al alcance del
empresario ni de extraños, incluye todos los instrumentos de recolección de datos: encuestas,
formularios, entrevistas, videos, grabaciones, etc. Salvo excepciones que no transgredan el
principio de anonimato y reserva de identidad.
c) Soportes computarizados y tecnológicos
Son registros en PC, CD, USB, Pen drive, grabadoras, videos, filmaciones, fotos, entre otros;
que permiten el almacenamiento de los datos, los resultados de combinaciones y análisis,
contemplando incluso la posibilidad de transferencias de datos.
4 “Sistemas Administrativos”, 3ra. Edición- Fernando Magdalena - Ediciones Macchi 1992 – pag. 39
MODELADO DE PROCESOS Página 25
5 “investigación en Administración para la toma de decisiones”, 5º Edición – Duane Davis – Edit. International Thomson 2000 6 “Sistemas Administrativos”, 3ra. Edición- Fernando Magdalena - Ediciones Macchi 1992 – pag. 39/43. “Manual de control Interno”, Rubén O. Rusenas - 1ra Edición, Editorial Cangallo 1978 – pag. 79/97. “Técnicas de investigación aplicadas a las ciencias sociales” Jorge Papua – Edit. Fondo de cultura económica - 1982 7 Administración teórica y práctica” 4º edición – Stephen P. Robbins 1994, pag. 179
INFORMACION PARA EL ANÁLISIS DE LA SITUACIÓN: Medio pertinente próximo, Antecedentes organizacionales, Aspectos fundacionales, Factores específicos s/ la naturaleza del problema (variables involucradas) - de
tipo: Cuantitativa y cualitativa
Tipo5 Inexistente:
Hay que crearla en forma directa Información Primaria
Existente: Hay que localizarla
Información secundaria
Fuentes Externa a la empresa
Interna de la empresa No registrada
Externa a la empresa: Producida por los gobiernos, corporaciones – gremios,
asociaciones empresariales, universidades, servicios de información
comercial
Interna: generada por la empresa y
Registrada
Herramientas de recolección (primaria), consulta (secundaria) y de reconstrucción (representaciones gráficas simplificadas) Herramientas de recolección (primaria), consulta (secundaria) y de reconstrucción (representaciones gráficas simplificadas)
Estudios de campo sobre aspectos relevantes – críticos para el problema – Instrumentos de recolección.
Estrategias de búsqueda, clasificación y almacenamiento Recolección manual o en línea6
Compilaciones propias o compradas
• Narración o Descripción detallada
• Observación directa, participante y otras
• Observación y revisión de informaciones peculiares pertinentes en prensa, radio y tv, para medir actitudes u opiniones
• Entrevistas a expertos en el tema
• Entrevistas estructuradas / no estructuradas a “personas claves”. Cuestionarios y encuestas abiertas / cerradas / mixtas.
• Grupos de interés: Grupos nominales, Delphi, foros virtuales, etc.7
• Representaciones gráficas estáticas
• Representaciones gráficas dinámicas
• Otras herramientas de análisis de gestión
• Bibliotecas públicas o privadas
• Archivos de documentos y carpetas de antecedentes, de otros casos aplicables o transferibles.
• Diccionarios, directorios, guías, publicaciones periódicas de especialistas, anuarios, fuentes estadísticas, reportes impresos,
• Archivos con información específica de proveedores, etc., para bajar en PC/CD
• Archivos públicos y de documentos oficiales, para extraer algunos datos considerados necesarios
• Bases de datos disponibles en Internet de muy variados temas: cartográficos, poblacionales, económicos, financieros, cambiarios, legales, políticos, fiscales, índices de precios, etc. (línea)
• Consultas de archivos disponibles, notas y memorias, estadísticas propias
• Bancos de datos internos, datos históricos y estadísticas de la empresa
• Sistema de información contable, balances, etc
Evaluar: Si los datos recolectados son
Específicos y relevantes, oportunos, precisos, confiables, grado de ocultamiento o sesgo en la respuesta Criterios de medición o de cuantificación
Accesibles, actualizados, pertinentes para nuestro caso de estudio, confiables, costos, objetivos del que produce el dato.
Tabla 1: Información para el análisis de la información existente
MODELADO DE PROCESOS Página 26
2.3.2.2 Herramientas para captar datos
Se utilizan estas herramientas para investigar las particularidades específicas relacionadas
al problema y que no han sido contempladas en la información secundaria recolectada. En
general estos instrumentos son adaptables al campo del contexto de la organización o para
concentrarse puertas adentro de ella. Las herramientas más usadas para recolectar datos
primarios son: narración o descripción detallada, entrevistas, cuestionarios y encuestas,
observación directa y participante, técnicas de opinión grupal, análisis documental como
representaciones gráficas estáticas y dinámicas y finalmente el uso de otras herramientas e
indicadores específicos según el eje temático de gestión.
Narración o descripción detallada8
Es el relato del modo de operar de la organización, proveniente de explicaciones solicitadas
a los miembros de la organización respecto de funciones, normas, operaciones, archivos,
custodia de bienes y seguridad, controles, etc. Todos los datos o información que se recopilan
son incorporados sin procesamiento alguno en los papeles de trabajo del Ingeniero del proyecto.
Desventajas:
- Capacidad para describir hechos o sucesos en forma clara y breve.
- Uso indebido de expresiones idiomáticas puede llegar a confundir al lector impidiendo que
se interprete correctamente lo que se quiso describir.
- Puede llegar a ser una recopilación de datos parcial o incompleta.
Entrevistas, Cuestionarios y Encuestas
Consiste en pactar una reunión con cada una de las personas involucradas en las tareas de
interés. La entrevista puede ser un relato donde comentan sobre los ejes temáticos solicitados,
o una encuesta con distintos grados de estructuración en el tipo de respuesta solicitada.
También se pueden clasificar9 por el medio con el que se hace el relevamiento: Personales, por
teléfono, por correo y computarizadas.
En la siguiente tabla se presenta la definición de cada herramienta y un análisis comparativo
desde algunas dimensiones importantes.
8 “Manual de control interno” Rubén Oscar Rusenas – Edit. Cangallo 1978 pag.79 en adelante 9 “Investigación en administración para la toma de decisiones”, Duane Davis – 5º Edición – Edit. Thomson, 2000, pag.268
MODELADO DE PROCESOS Página 27
Entrevistas / encuestas
Personal Telefónica Por correo Computarizada
Concepto Es un discurso de persona a persona, dirigido por el entrevistador, con el propósito de obtener información necesaria para su tema de estudio
Pueden servir para investigaciones preferiblemente estructuradas. Van a cuestiones puntuales, son más rápidas para su recolección, de menor costo.
Se entrega un cuestionario escrito por correo, con instrucciones para su llenado, suele presentarse en alguna bibliografía, como encuestas autoadministradas de respuesta abierta o cerrada. Los riesgos se relacionan con el nivel de retorno de las respuestas
Con los avances tecnológicos el proceso interrogatorio va desde: encuestas en línea por Internet, foros, Chat, etc. otras por correo electrónico, por fax, todas variaciones en función de los avances de los medios de comunicación a distancia.
Tabla 2: Análisis comparativo de herramientas
En general las entrevistas se utilizan para relevar información en los niveles gerenciales
de la organización y las encuestas y cuestionarios en los niveles operativos o para consultas
puntuales externas.
Observación directa, participante y otras clasificaciones
La observación, como método de recolección de datos, se aplica preferentemente en
aspectos conductuales o de procedimiento.
La observación directa: es realizada en forma visual y a tiempo real, (presencial o virtual) en
el campo se va testeando y registrando respuestas a preguntas previamente organizadas, o
representando gráficamente aspectos relevantes para la explicación del problema. En este caso
la observación es explícita, no se oculta la intención de registrar datos. Según Fernando
Magdalena, permite al analista tomar conocimiento por simple visualización sobre: la
disposición física del personal y elementos de trabajo, los espacios de circulación de personas e
insumos, las características de las interacciones personales intra y extramuros a la organización,
la cohesión del personal y el clima, características prácticas de los registros y documentos
generados, los criterios de archivo representación del layout (disposición física de personas y
equipos) en las áreas bajo estudio.
Desventajas: puede tener sesgos de percepción del observador o de cambios de actitud del
observado, sin embargo, la experiencia indica que aún alertado, los vicios adquiridos son difíciles
de ocultar cuando el tiempo de observación se extiende.
Observación participante: en muchos casos es recomendable tener un contacto viviendo o
experimentando la situación, por ejemplo; de cliente, proveedor, postularse para trabajar en..,
etc. Sin que sea identificado como observador. Permite sortear algunos filtros del informante
MODELADO DE PROCESOS Página 28
involucrado en la problemática. Duane Davis10 hace aportes para reclasificar los tipos de
observación, diferencia las observaciones en estructuradas o no. A continuación, se sintetiza su
tabla adaptada:
Variaciones metodológicas
de la observación
Humanos Computarizados
Estructurada No estructurada Estructurada No estructurada
Ocultas El observador vigila y registra hecho y aspectos específicos previamente planeados sin ser identificado
El observador vigila y registra acciones y actitudes sin ser identificado, tiene el carácter de exploratorio, de descubrimiento
Observaciones de conteo electrónico de sucesos, a través de sensores específicos
A través de grabaciones en video, con cámaras ocultas. Tiene el carácter de exploratorio, de descubrimiento
NO Oculta, explícita
El observador describe el propósito del estudio a los participantes, tomando nota de los hechos puntuales objeto de observación
El observador describe el propósito del estudio a los participantes, tomando nota de los hechos objeto de observación, tiene el carácter de exploratorio, de descubrimiento
El observado conoce el propósito del estudio y autoriza su participación. Con medios electrónicos se registran los hechos puntuales objeto de observación
El observado conoce el propósito del estudio y autoriza su participación. Con medios de video se registran los hechos objeto de observación. Tiene el carácter de exploratorio, de descubrimiento
Tabla 3: Tipos de observación
Grupos de interés11
Por lo general consta de 8 a 12 entrevistados que forman parte de la población de estudio
(recoge información interna o externa: empleados, clientes, etc.), la reunión tiene un objetivo
de estudio en mente, un coordinador dirige la sesión, dura como máximo 2 horas y media, se
suelen utilizar cámaras, en ambientes especiales y neutros, de manera que el entrevistado no
tenga temor de sus respuestas. Se utilizan según el tipo de problemas a resolver, no es para
todos los casos.
10 “Investigación en administración para la toma de decisiones”, Duane Davis – 5º Edición – Edit. Thomson, 2000, pag.303 11 “Investigación en administración para la toma de decisiones”, Duane Davis – 5º Edición – Edit. Thomson, 2000, pag.307
MODELADO DE PROCESOS Página 29
2.4 Análisis documental del estudio preliminar de los procesos académicos de la
Universidad Nacional de Trujillo.
2.4.1 Revisión y Análisis documental
Se revisaron los siguientes documentos de la Universidad Nacional de Trujillo: Estatuto
UNT, Ley Universitaria N° 30220, Ley de Procedimiento Administrativo General, Ley N° 27444,
Normatividad Académica, Directorio Institucional, Documentos de la oficina de Admisión,
Documentos de los centros productivos de la UNT: CEPUNT, CIDUNT, CEE Rafael Narváez
Cadenillas, CESTUNT, Unidad de Segunda especialización en Estomatología, Programa de
Segunda Especialidad en Tecnología Educativa, Bolsa de Trabajo, PORNAFCAP, ISACA-UNT.
2.4.2 Concepto e identificación de requisitos de los principales procesos
a) Proceso: Traslado Interno
- El traslado interno se refiere al cambio de carrera del estudiante, dentro de la misma sede.
- Los requisitos son: Recibo de pago por traslado interno, FUT dirigida al Decano de la
Facultad, y record de notas original, con la aprobación de 32 créditos como mínimo o dos
ciclos académicos consecutivos.
b) Proceso: Reanudación de estudios
- Es el proceso por el cual el estudiante solicita la reincorporación a los estudios después de
haberlos interrumpido por un lapso no mayor de 2 ciclos consecutivos.
- Los requisitos son: Recibo de pago, FUT dirigida al Decano de la Facultad.
c) Proceso: Traslado externo
- Es el proceso por el cual el estudiante obtiene la vacante a través de una prueba de selección
en el proceso de admisión bajo esta modalidad.
- Los requisitos son: Recibo de pago, Certificados originales, habiendo cursado mínimo de 32
créditos o 2 semestres consecutivos, Constancia de ingreso.
d) Proceso: Obtención de certificados de estudio
- Requisitos: Recibo de pago, FUT dirigida al Decano de su Facultad, Copia del DNI, y 06 fotos
a color, tamaño carnet.
e) Proceso: Examen de Suficiencia
- Es el pedido que solicita el estudiante en base al derecho que le asiste cuando ha culminado
los estudios de pregrado, pero adeuda una sola asignatura.
- Requisitos: Recibo de pago, FUT dirigida al Decano.
f) Proceso: Reserva de Matrícula
- La reserva de matrícula puede ser solicitada por el estudiante en los casos de trabajo o
estudios temporales en otras ciudades, o por razones de salud.
MODELADO DE PROCESOS Página 30
- Requisitos: Recibo de pago, FUT dirigida al Decano.
g) Proceso: Rectificación de Matrícula
- La rectificación de matrícula se lleva a cabo para modificar la matrícula registrada, siempre
y cuando se respete el calendario correspondiente.
- Requisitos: Recibo de pago, FUT dirigida al Decano.
h) Proceso: Registro de Matrícula
- El registro de la matrícula se lleva a cabo a través de la web de la Universidad.
- Requisitos: Recibo de pago, Registro de matrícula en línea, FUT dirigida al Decano.
i) Proceso: Revisión de notas
- La revisión de notas es el derecho que tienen los estudiantes para que sus exámenes sean
revisados por el docente, cuando no se encuentre conforme con la evaluación desarrollada.
- Requisitos: Recibo de pago, FUT dirigida al Decano.
j) Proceso: Trámite para justificación de inasistencias
- El trámite de justificación de inasistencia es el derecho que tienen los estudiantes para
justificar sus inasistencias.
- Requisitos: Recibo de pago, FUT dirigida al Decano.
k) Proceso: Trámite para optar el grado académico de bachiller
- El grado de Bachiller es el derecho de los estudiantes cuando han concluido
satisfactoriamente los estudios académicos.
- Requisitos: Recibo de pago, FUT dirigida al Decano, Constancia de no adeudo de las
Bibliotecas Central y de la Facultad, Resolución de nombramiento de jurado evaluador de
tesis de grado, Carpeta con las Actas de la tesis, 05 ejemplares empastadas de la tesis de
grado.
l) Proceso: Trámite para optar el título profesional
- El título profesional es el derecho de los estudiantes cuando han obtenido
satisfactoriamente su grado de bachiller.
- Requisitos: Recibo de pago, FUT dirigida al Decano, Resolución de nombramiento de jurado
para la tesis de título profesional, Carpeta con las Actas de la tesis, 05 ejemplares de la Tesis
de título profesional debidamente empastada.
MODELADO DE PROCESOS Página 31
2.4.3 Elaboración de herramientas para el relevamiento detallado
2.4.3.1 Modelo de guías de Entrevista
Guía de entrevista Nº 01
INVOCACIÓN-OBJETIVO
La presente investigación pretende desarrollar el estudio preliminar y relevamiento detallado
de los sistemas implementados para la gestión académica de la Universidad Nacional de Trujillo;
por lo cual, le agradeceremos responda las preguntas que se plantean en base a su experiencia
en el manejo de los sistemas de la Universidad.
FUENTE E INFORMANTE
Jefe de la Oficina de Sistemas Informáticos y Comunicaciones
CONTENIDO
1. Señale cuáles son las actividades previas que se desarrollan para la gestión de matrículas
de cada período académico, e indique quién o quienes se responsabilizan por estas
tareas.
______________________________________________________________________
______________________________________________________________________
2. Describa cada una de las tareas del módulo desarrollado actualmente para la gestión de
matrículas de los alumnos de pregrado.
______________________________________________________________________
______________________________________________________________________
3. Describa cuáles son los procedimientos para la gestión de las currículas de las Escuelas
académico profesionales.
______________________________________________________________________
______________________________________________________________________
4. Señale las características de los procesos para efectuar los pagos de los estudiantes a
través de la oficina de tesorería de la UNT o a través de las agencias bancarias.
______________________________________________________________________
______________________________________________________________________
5. Describa las operaciones que sigue un alumno para la regularización de su matrícula a
través de Secretaría de su Escuela.
______________________________________________________________________
______________________________________________________________________
MODELADO DE PROCESOS Página 32
6. Especifique cómo se realiza el registro de reanudación de estudios de los alumnos.
______________________________________________________________________
______________________________________________________________________
7. Señale cuáles son los reportes más importantes que solicitan las áreas académicas.
______________________________________________________________________
______________________________________________________________________
8. Describa los mecanismos de seguridad que se sigue en el proceso de registro de las
Notas que ingresan los docentes por el sistema académico de la Universidad.
______________________________________________________________________
______________________________________________________________________
9. Señale cuáles son los procedimientos que se sigue en la asignación de permisos y
derechos de usuarios a través de sus contraseñas.
______________________________________________________________________
______________________________________________________________________
10. Describa la forma como se lleva a cabo las copias de seguridad de los sistemas y de la
base de datos.
______________________________________________________________________
______________________________________________________________________
MODELADO DE PROCESOS Página 33
Guía de entrevista Nº 02
INVOCACIÓN-OBJETIVO
La presente investigación pretende desarrollar el estudio preliminar y relevamiento detallado
de los sistemas implementados para la gestión académica de la Universidad Nacional de Trujillo;
por lo cual, le agradeceremos responda las preguntas que se plantean en base a su experiencia
en las funciones inherentes a su cargo actual en la Universidad.
FUENTE E INFORMANTE
Directores de Escuela y directores de Departamentos Académicos.
CONTENIDO
1. Señale cuáles son los procedimientos que sigue ud. para la elaboración de los
requerimientos de cursos de cada semestre académico.
______________________________________________________________________
______________________________________________________________________
2. Señale las dificultades más relevantes que ha enfrentado en la elaboración de horarios
del semestre académico.
______________________________________________________________________
______________________________________________________________________
3. Señale las dificultades en la elaboración de la carga horaria del docente.
______________________________________________________________________
______________________________________________________________________
4. Señale cómo se lleva a cabo el proceso de convalidación de asignaturas, para los
estudiantes de traslado interno/ externo de la Universidad.
______________________________________________________________________
______________________________________________________________________
5. Describa los procesos que sigue un alumno para la regularización de su matrícula.
______________________________________________________________________
______________________________________________________________________
6. Especifique cómo se realiza el registro de reanudación de estudios de los alumnos.
______________________________________________________________________
______________________________________________________________________
7. Indique los pasos que debe seguir el estudiante para un examen de suficiencia.
MODELADO DE PROCESOS Página 34
______________________________________________________________________
______________________________________________________________________
8. Indique cómo se procesa la reserva de matrícula de los estudiantes.
______________________________________________________________________
______________________________________________________________________
9. Señale cuáles son los procedimientos que se sigue en gestión de documentos como
certificados de estudio, copia visada de sílabos; entre otros documentos.
______________________________________________________________________
______________________________________________________________________
10. Describa la forma como se lleva las peticiones de revisión de exámenes de los
estudiantes.
______________________________________________________________________
______________________________________________________________________
MODELADO DE PROCESOS Página 35
2.4.3.2 Modelo de Encuestas
Encuesta Nº 01
Para medir el nivel de satisfacción de los estudiantes de la UNT
INVOCACIÓN-OBJETIVO
La presente investigación pretende desarrollar el estudio preliminar y relevamiento detallado
de los sistemas implementados para la gestión académica de la Universidad Nacional de Trujillo;
por lo cual, le agradeceremos responda las preguntas que se plantean teniendo en cuenta el
manejo de los sistemas académicos de la Universidad.
FUENTE E INFORMANTE
Estudiantes de la Universidad Nacional de Trujillo.
CONTENIDO
1. Según su apreciación; indique cómo se siente con el servicio de matrícula en línea de la
Universidad Nacional de Trujillo.
a) Completamente en desacuerdo
b) En desacuerdo
c) Ni en desacuerdo, ni de acuerdo
d) De acuerdo
e) Completamente de acuerdo
2. En base a los servicios que recibe de la UNT, cómo aprecia la performance de la web.
a) Completamente en desacuerdo
b) En desacuerdo
c) Ni en desacuerdo, ni de acuerdo
d) De acuerdo
e) Completamente de acuerdo
3. Señale cómo se siente respecto a los sistemas de gestión académico de la UNT.
a) Completamente en desacuerdo
b) En desacuerdo
c) Ni en desacuerdo, ni de acuerdo
d) De acuerdo
e) Completamente de acuerdo
4. Identifique cómo aprecia el aspecto tecnológico de la UNT actualmente.
a) Completamente en desacuerdo
b) En desacuerdo
MODELADO DE PROCESOS Página 36
c) Ni en desacuerdo, ni de acuerdo
d) De acuerdo
e) Completamente de acuerdo
5. En líneas generales, especifique cómo se siente respecto a los servicios que desarrollan
las diversas áreas de la UNT, con el uso de los sistemas de información implementados.
a) Completamente en desacuerdo
b) En desacuerdo
c) Ni en desacuerdo, ni de acuerdo
d) De acuerdo
e) Completamente de acuerdo
MODELADO DE PROCESOS Página 37
3. El Modelo de Negocio
El Modelo de Negocio está definido a través de los modelos de casos de uso del negocio
y el modelo de objetos. El Modelo de Casos de Uso de Negocio describe los procesos de negocio
de una organización empresarial en términos de casos de uso del negocio y actores del negocio,
los cuáles se corresponden con los procesos del negocio y los clientes, respectivamente. Por otro
lado, el Modelo de Objetos del negocio es un modelo interno a un negocio, que describe cómo
cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que
utilizan un conjunto de entidades del negocio y unidades de trabajo, actualmente se denomina
Modelo de Análisis del Negocio.
El Modelo de Negocio es una técnica que permite comprender los procesos de negocio
de la organización. Describe como desarrollar una visión de la organización, y basado en esta
visión define los procesos, roles y responsabilidades de la organización. El conjunto de artefactos
del modelo de negocio captura y presenta el contexto del sistema. A continuación, se presenta
un modelo genérico del modelo de negocio para visualizar y especificar de manera precisa los
diversos artefactos que componen el modelo de negocio y sus relaciones.
Figura 8: Modelo genérico del Modelo de Negocio y sus Artefactos
MODELADO DE PROCESOS Página 38
Tabla 1: Sigla de los Artefactos del Modelo de Negocio
En cada iteración se desarrolla la disciplina de requerimientos (posiblemente luego de
realizar un modelado del dominio o del negocio). El objetivo de esta fase es determinar los
requerimientos del sistema. El Modelo de Caso de Uso de Negocio es utilizado por los
stakeholders, los analistas y los diseñadores de procesos de negocio, para entender y mejorar la
manera cómo funciona el negocio y cómo se relaciona con su ambiente; así como por el gerente
del proyecto, para planificar el volumen y contenido de las iteraciones durante el modelado de
negocio y hacer el seguimiento del progreso. El Modelo de Caso de Uso del Negocio muestra los
Casos de Uso de negocio, Actores del negocio, Trabajadores del negocio y las interacciones entre
ellos para una organización, modela lo qué hace una organización, quién está dentro y quién
está fuera de dicha organización.
3.1 Actor de Negocio
Un actor de negocio es cualquiera o algo que es externo
a la organización pero que interactúa con él. En RSA, un actor de
negocio se modela usando el icono:
Figura 9: Actor de Negocio
3.2 Caso de uso de Negocio
Un caso del uso de negocio representa un conjunto de
tareas relacionadas que generan un resultado de valor para los
actores de negocio, es decir, los casos de uso de negocio le
dicen al lector lo que la organización hace para proporcionarle
el valor de negocio que los individuos que interactúan con él
esperan.
Figura 10: Caso de Uso de Negocio
El conjunto de casos del uso de negocio para una organización debe describir
completamente lo que el negocio hace.
MODELADO DE PROCESOS Página 39
3.3 Relación de Asociación
Una línea que va desde un Actor de Negocio hacia un Caso de Uso de Negocio indica que
el actor activa el caso de uso. En RSA, la relación de asociación se muestra de la siguiente
manera:
3.4 Paquetes
Un paquete es utilizado para agrupar elementos del diagrama para permitir un
detalle más específico y ordenado de los diagramas más grandes. El símbolo utilizado
por RSA, es:
3.5 Diagrama de Paquetes
Los diagramas de paquetes permiten una gráfica consolidada de artefactos
agrupados. A continuación, se muestra un ejemplo:
Figura 11: Relación de Asociación
Figura 12: Paquete
Figura 13: Diagrama de Paquetes
MODELADO DE PROCESOS Página 40
3.6 Diagrama de Caso de Uso de Negocio
Un diagrama de caso de uso de negocio contiene la información de alto nivel y rápida
sobre el negocio sin entrar en detalles o confundir al lector con demasiada notación. En los casos
donde se requiera el uso de un número grande de casos de uso de negocio se utilizan Paquetes
de casos de uso para agruparlos adecuadamente. En RSA, un diagrama de caso de uso de negocio
se muestra de la siguiente manera:
3.7 Diagrama de Objetivos de Negocio
Un diagrama de objetivos de
negocio parte de un objetivo general y se
desarrolla hacia diversos objetivos
específicos, tal como se muestra en el
siguiente ejemplo:
3.8 Diagrama de Caso de Uso de Negocio versus Objetivos de Negocio
Figura 14: Diagrama de caso de uso de Negocio
Figura 15: Diagrama de Objetivos de Negocio
Figura 176: DCUN vs ON
MODELADO DE PROCESOS Página 41
LABORATORIO Nº 01
Modelo de caso de uso del Negocio
MCUN
1. DESCRIPCIÓN DEL CASO
La empresa “Distribuidora Luján SAC”, se dedica a la compra y venta de abarrotes en
general. Dicha empresa cuenta con una tienda principal ubicada en el centro de la ciudad de
Trujillo, y otras sucursales en los distritos de La Esperanza, Víctor Larco Herrera, Moche y
Salaverry. Se requiere la implementación de un sistema que dé soporte al área de Logística de
la empresa; para ello, se ha planteado como objetivo general el logro de una mejora en la gestión
del área; así también, se prevé como impacto la reducción del tiempo empleado para la
elaboración de órdenes de compra en un promedio de 5%, la reducción de la cantidad de
pedidos no atendidos por falta de existencias en almacén en el orden del 20%; así como mejorar
el nivel de distribución intertiendas en un 5%; y se espera lograr un incremento en el grado de
satisfacción de los colaboradores en un promedio de 15%.
Para la identificación de los procesos y otros aspectos de relevancia se aplicaron entrevistas
al jefe y a los encargados del área de logística de la empresa; de ahí que se pudo identificar las
siguientes operaciones:
El gerente comercial monitorea la demanda de los productos presentadas por el encargado
de cada sucursal y coordina su abastecimiento con el área de logística. Las órdenes de compra
que se dirige hacia los proveedores se llevan a cabo con una negociación previa entre el jefe de
logística y dichos proveedores; aquí, se discuten los precios, cantidades, plazos de pago, y tipos
de pago de la mercadería a ordenar. Una vez establecido un acuerdo, el jefe de logística elabora
el documento de orden de compra y lo envía al Gerente General de la empresa para su
aprobación. Posteriormente, las órdenes de compra aprobadas son enviadas a los proveedores,
al área comercial y al área de Contabilidad.
El jefe de logística define el medio de transporte de la mercadería adquirida a los
proveedores y establece el horario de recepción de dicha mercadería. Cuando una mercadería
es entregada por el proveedor, el asistente de almacén realiza la correspondiente recepción con
una evaluación de las cantidades y el estado de los productos remitidos.
MODELADO DE PROCESOS Página 42
Las órdenes de compra que fueron atendidas por los proveedores serán distribuidas por el
jefe de logística a las tiendas de la empresa con una evaluación previa de sus correspondientes
pedidos; para ello, el asistente de almacén prepara el despacho físico documentando dicho
despacho con el documento de Nota de Despacho interno y coordinando el transporte para la
distribución interna.
2. HOJAS DE DESCRIPCIÓN
2.1 Actores del Negocio
Dentro de los actores de negocio contamos con el proveedor y el transportista.
Actor del Negocio Proveedor Identificador: AN-01
Descripción El proveedor es quien atiende los requerimientos de compra establecidos por el jefe de logística en la orden de compra.
Características El proveedor es una persona o empresa (persona jurídica)
Relaciones No hay relación con otros actores
Referencias
Autor Dr. Luis Boy Chavil Fecha 15-Octubre-2020
Versión 1
Actor del Negocio Transportista Identificador: AN-02
Descripción Es quien traslada la mercadería compradas por la empresa al proveedor.
Características El transportista es una persona o empresa (persona jurídica)
Relaciones No hay relación con otros actores
Referencias
Autor Dr. Luis Boy Chavil Fecha 15-Octubre-2020
Versión 1
Actor del Negocio Gerente Comercial Identificador: AN-03
Descripción El Gerente Comercial establece las prioridades de evaluación de las órdenes de compra.
Características El Gerente Comercial es un empleado de la empresa.
Relaciones No hay relación con otros actores
Referencias
Autor Dr. Luis Boy Chavil Fecha 15-Octubre-2020
Versión 1
MODELADO DE PROCESOS Página 43
2.2 Casos de Uso del Negocio
- Casos de Uso
Los casos de uso son: Gestionar el Abastecimiento, Gestionar el transporte de
aprovisionamiento, y Gestionar la demanda.
Caso de Uso Gestionar la demanda Identificador: CUN-01
Actores Gerente Comercial
Tipo Primario
Descripción El gerente comercial monitorea la demanda de los productos y coordina el abastecimiento con logística.
Flujo principal Consiste en establecer las prioridades de compra de la empresa y el diseño de los planes de venta.
Flujo Alternativo En caso de un cierre temporal de la empresa las tareas de gestionar la demanda se suspenden.
Precondiciones
Postcondiciones
Autor Fecha 15-Octubre-2020
Versión 1
Caso de Uso Gestionar el Abastecimiento Identificador: CUN-02
Actores
Tipo
Descripción El proveedor acuerda los términos de una orden de compra de la empresa y la atiende.
Flujo Principal Consiste en confirmar los productos de la orden de compra que serán atendidos y fijar los precios de compra, así como la modalidad de despacho.
Flujo Alternativo En caso de no contar con los stocks necesarios el proveedor volverá a coordinar los detalles de la venta.
Precondiciones
Postcondiciones
Autor Fecha 15-Octubre-2020
Versión 1
MODELADO DE PROCESOS Página 44
Caso de Uso Gestionar el Transporte Identificador: CUN-03
Actores
Tipo
Descripción El transportista coordina los detalles del transporte de las mercancías.
Flujo Principal Consiste en establecer cada uno de los detalles con el transportista que fue elegido.
Flujo Alternativo Cuando en pleno traslado de las mercancías esta labor se ve afectada en su correcto cumplimiento el transportista deberá comunicar inmediatamente a la empresa.
Precondiciones
Postcondiciones
Autor Fecha 15-Octubre-2020
Versión 1
3. IMPLEMENTACIÓN DEL MODELO DE CASOS DE USO CON RSA
3.1 Carga de la aplicación IBM Rational Software Architect
3.2 Se carga la siguiente ventana:
3.3 Creación del Nuevo Proyecto
MODELADO DE PROCESOS Página 45
3.4 Ventana New Project
3.5 Escriba el Nombre del Proyecto: LogísticaLuján, luego hacer clic en Next; así:
MODELADO DE PROCESOS Página 46
3.6 Ahora, seleccionar la Categoría “Business Modeling” y escribir el Nombre del Modelo, luego
hacer clic en el botón Next; así:
3.7 Hacer clic en el botón Next:
MODELADO DE PROCESOS Página 47
3.8 Hay que hacer clic en los bloques de construcción de Diagramas y Elementos de UML:
MODELADO DE PROCESOS Página 48
3.9 Se requiere aplicar el Estereotipo “BusinessUseCaseModel”; así:
3.10 Clic derecho sobre el Modelo de Casos de Uso del Negocio → Add Diagram → Freeform
Diagram; para agregar un Diagrama de Formato Libre sobre el Modelo de Casos de Uso del
Negocio;
MODELADO DE PROCESOS Página 49
3.11 Colocar el Nombre: “Organización del MCUN”; quedará así:
3.12 Hacer doble clic sobre el diagrama de formato libre “Organización del MCUN”; y ahí colocar
tres paquetes, tal como se indica a continuación:
Nota: En el área de diagramas, hacer clic y cuando se muestre la ventana emergente; escoger
Add Package para agregar los paquetes.
3.13 Los Paquetes que se agregarán, son:
3.14 Hacer los cambios que se indican a continuación:
MODELADO DE PROCESOS Página 50
4. DIAGRAMA DE OBJETIVOS DEL NEGOCIO
4.1 Sobre el área de diagramas hacer clic y seleccionar el ícono de Objetivos; luego elegir la
opción “Create <<BusinessGoals>> Class”; tal como se indica a continuación:
4.2 Cambie la apariencia de los objetivos con la opción “Appearance” y “Shape Image”
MODELADO DE PROCESOS Página 51
4.3 El diagrama de Objetivos del Negocio, es:
MODELADO DE PROCESOS Página 52
5. ACTORES DEL NEGOCIO
5.1 Dar doble clic al diagrama de formato libre AN; y elegir los actores de negocio, tal como se
muestra:
5.2 Definir los Actores del Negocio: Proveedor, Gerente Comercial y Transportista; luego
estereotipar como “BusinessActor”
MODELADO DE PROCESOS Página 53
6. CASOS DE USO DEL NEGOCIO
6.1 Dar doble clic al diagrama de formato libre CUN; y elegir los Casos de Uso del negocio, tal
como se muestra:
6.2 Definir los Casos de Uso del Negocio: Gestionar la demanda, Gestionar el transporte, y
Gestionar el Abastecimiento; luego estereotipar como “BusinessUseCase”
MODELADO DE PROCESOS Página 54
7. DIAGRAMA: CASOS DE USO vs OBJETIVOS DEL NEGOCIO
7.1 En el siguiente diagrama se muestra la relación existente entre los casos de uso del negocio
y los objetivos específicos:
8. DIAGRAMA GENERAL DE CASOS DE USO DEL NEGOCIO
8.1 El siguiente diagrama muestra la relación entre los Actores del Negocio y los Casos de Uso
del Negocio:
MODELADO DE PROCESOS Página 55
Actividad Nº 1
1. Ud. Es un especialista en Sistemas Informáticos que tendrá como responsabilidad
primaria el desarrollo de una mesa de ayuda para atender la problemática más relevante
de los usuarios de una empresa proveedora de internet en el Perú; entonces, tomando
como base de su actividad, la propuesta establecida por el modelo CANVAS (Acceder a
este modelo por medio del siguiente link:
https://www.ucm.es/data/cont/media/www/pag-
1177/PREMIOS%202015/16%20Preguntas%20para%20el%20desarrollo%20de%20un%
20Modelo%20de%20Negocio.pdf); elabore un cuestionario de 10 preguntas para
recolectar información relevante que permita conocer el nivel de satisfacción de los
usuarios de los servicios de internet de dicha operadora de nuestro país. (Claro,
Telefónica, etc.) con el fin de que identifique la información necesaria para la
elaboración de su help desk o “mesa de ayuda”.
Observación.- Se pide la elaboración del cuestionario de preguntas, no la mesa de ayuda!!
2. En base a las preguntas planteadas en el cuestionario de la pregunta anterior, elabore
un primer esbozo del modelo de negocio de la mesa de ayuda (diseñado para atender
los principales requerimientos de atención de los usuarios de la operadora de los
servicios de comunicación seleccionado) a través de los diagramas de caso de uso de
negocio, objetivos de negocio y DCUN vs ON.
Observación.- Haga las suposiciones adicionales que considere pertinente en su propuesta
de trabajo.
o Utilice Rational Software Architec (RSA) para la implementación de su modelo de
negocio del caso planteado.
MODELADO DE PROCESOS Página 56
Autoevaluación 1
La presente auto evaluación consta de cinco preguntas de los temas tratados en la
sesión Nº 1 que permitirá reforzar tu aprendizaje.
1. No es una sigla de los artefactos del modelo de negocio:
A) VN B) ON C) DAN D) MEN E) AN
2. Se define un esquema general de la arquitectura, en:
A. Fase de construcción del software
B. Fase de Inicio
C. Fase de Transición
D. Fase de Pruebas
E. Fase de Ejecución
3. La información secundaria:
A. Debe ser localizada
B. Es interna a la empresa, pero no está registrada
C. Debe ser creada directamente
D. Debe ser creada internamente
E. N.A.
4. Es una técnica que genera versiones del software que son evaluadas hasta la satisfacción
plena de los usuarios:
A. Implementación y prueba de módulos
B. Modelo en Cascada
C. Desarrollo Evolutivo
D. Integración del Sistema
E. Operación del Sistema
5. Las observaciones quedan registradas en video y el observado autoriza su participación;
se trata de la metodología:
A. Oculta, no explícita y estructurada
B. No oculta, explícita computarizada y no estructurada
C. Oculta explícita no computarizada y estructurada
D. No oculta explícita humana y estructurada
E. Oculta no explícita humana y no computarizada.
MODELADO DE PROCESOS Página 57
Sesión 2: Modelado de Análisis del Negocio
1. El Modelo de Análisis del Negocio (MAN)
El Modelo de Análisis del Negocio, conocido con el acrónimo MAN, identifica y describe
a los trabajadores del negocio (BW: Business Worker) como actores internos del negocio e
identifican y describen la información (EN: Entidades del Negocio) que es utilizada por dichos
trabajadores del negocio. El MAN describe su organización estructural en unidades
independientes y definen cómo ellos interactúan para realizar el comportamiento descrito
en los casos de uso del negocio a través de los artefactos denominados Realizaciones de
Casos de uso de Negocio.
Otra forma de establecer la importancia del modelo de análisis del negocio es que
describe la realización de los casos de uso de negocio a través de la interacción entre los
trabajadores del negocio y las entidades de negocio. El modelo sirve de abstracción para
representar la forma cómo los trabajadores del negocio y las entidades del negocio
necesitan relacionarse y colaborar para lograr la ejecución de los casos de uso.
El modelo de análisis del negocio es utilizado por los stakeholders y los analistas de
procesos de negocio para entender cómo trabaja el negocio actual y para analizar el efecto
de hacer cambios al negocio. Asimismo, es utilizado por los analistas de sistemas en su afán
de hacer entregas al grupo de desarrollo sobre requerimientos de software en base al
comportamiento del sistema software. Finalmente, es utilizado por los arquitectos del
software para la identificación y definición de las diversas clases de procesos y de la base de
datos del sistema.
1.1 ¿Cuáles son los elementos del MAN?
Los elementos del MAN son:
1.1.1 Los trabajadores del Negocio
Un trabajador del Negocio (Business Worker) representa un rol desempeñado por
alguien o algo dentro del negocio ya que realiza una actividad en la organización. El
trabajador del negocio trabaja en una unidad organizacional y puede interactuar con otros
trabajadores de negocio; es el encargado de manipular la información de las entidades del
negocio. A continuación, se muestra el ícono que lo representa en RSA:
MODELADO DE PROCESOS Página 58
o ¿Cuál es el ámbito de los trabajadores de negocio?
En la siguiente figura ud. Podrá apreciar en qué parte del sistema se definen los
trabajadores de negocio:
o ¿Dónde encontrar trabajadores del Negocio?
Los trabajadores del negocio se encuentran perfectamente identificados a través de
los Roles que se desempeñan dentro del negocio, así también en las áreas de las
empresas representadas por el cargo que ocupan los empleados, y todas aquellas
personas que ejecutan los procesos de la organización o las actividades del negocio.
Otros trabajadores del negocio también puede ser un hardware (por ejemplo, un
marcador de huella dactilar para el control del personal) o interfaz de sistema que
ejecuta alguna operación al interior del negocio como, por ejemplo; el módulo de
registro de asistencias de participantes a un curso.
Una recomendación importante al momento de identificar a un trabajador del
negocio es que éstos no son personas sino Roles que se desempeñan dentro de la
organización; entonces, puede ser una persona (no su nombre propio), un software o
un hardware. Los trabajadores del negocio se encuentran dentro de las fronteras del
negocio o campo de acción de los sistemas. Un trabajador del negocio no representa un
MODELADO DE PROCESOS Página 59
área, sección o departamento de la organización; no olvidar que éstos están
representados por roles de ejecución. Por último, es importante tener en cuenta que
todos los trabajadores del negocio están vinculados, por lo menos, a algún caso de uso
de negocio.
1.1.2 Las Entidades del Negocio
Un Entidad de Negocio es un objeto que la organización utiliza para realizar su negocio o
que se desarrolla durante la ejecución de los procesos del negocio. Como objeto del sistema,
tiene propiedades que son establecidas por sus propios atributos que se utilizan para
describirlos con datos o instancias; y tiene comportamiento, que se representa por medio de
métodos u operaciones asociadas. Gráficamente, RSA lo representa de la siguiente manera:
1.1.3 Realizaciones de caso de uso de negocio
La realización de un caso de uso de negocio permite describir con mayor detalle el
comportamiento del caso de uso ya que está orientado al proceso interno del caso de uso
buscando su interacción entre los objetos que lo componen. Se debe tener en cuenta que
cada Realización de caso de uso de negocio se encuentra íntimamente relacionado a su
correspondiente caso de uso de negocio. RSA provee del siguiente ícono para su
representación:
MODELADO DE PROCESOS Página 60
1.1.4 Organización del modelo de Análisis
El Modelo de Análisis se muestra a través de un diagrama en el que se relacionan los
paquetes que se indican a continuación:
1.1.5 Realizaciones del Negocio
Como se ha indicado anteriormente, cada artefacto de Realización de caso de uso de
negocio está debidamente relacionado a su correspondiente caso de uso de negocio, tal
como se muestra a continuación:
MODELADO DE PROCESOS Página 61
LABORATORIO Nº 02
Modelo de Análisis del Negocio
MAN
1. IMPLEMENTACIÓN DEL MODELO DE ANÁLISIS DEL NEGOCIO CON RSA, DEL
CASO DESCRITO EN LA SESIÓN Nº 01
1.1 Carga de la aplicación IBM Rational Software Architect
1.2 Se carga la siguiente ventana:
1.3 Crear el Modelo de Análisis del Negocio (MAN)
1.4 Ventana Model
MODELADO DE PROCESOS Página 62
1.5 Pulsar clic en el botón Next nuevamente; y en la siguiente ventana activar las opciones
de bloques de construcción; así:
1.6 Finalmente, aplicar el estereotipo: Business Analysis Model; así:
MODELADO DE PROCESOS Página 63
1.7 Eliminar el diagrama Main; luego agregar un diagrama de formato libre y colocar el
nombre: Organización del MAN; de la siguiente manera:
1.8 Elaborar el diagrama de paquetes que se indica y cambiar el nombre de los diagramas:
MODELADO DE PROCESOS Página 64
2. ENTIDADES DEL NEGOCIO
Las Entidades del Negocio, son los objetos con características y comportamiento que
interactúan con los casos de uso del Negocio.
2.1 Hacer doble clic sobre el diagrama “EN”; luego hacer clic en el área de diagramas y
escoger la opción “Create <<BusinessEntity>>Class”.
2.2 Cambiar la apariencia de la Entidad de Negocio, así:
MODELADO DE PROCESOS Página 65
2.3 Cargar las siguientes Entidades del Negocio:
3. TRABAJADORES DEL NEGOCIO
Los trabajadores del negocio, pueden ser personas, o sistemas software que
representan un rol que es ejecutado dentro de la realización de un caso de uso de negocio.
3.1 Sobre el diagrama “TN”; dar doble clic y en área de diagramas dar un clic, luego
escoger la opción “Create <<BusinessWorker>> Class”
3.2 Se mostrará el Trabajador de Negocio como se indica a continuación
MODELADO DE PROCESOS Página 66
3.3 Ahora, cambiemos la apariencia:
3.4 Crear los siguientes trabajadores del negocio:
4. REALIZACIONES DEL NEGOCIO
Los objetos de Realizaciones del Negocio permiten describir cómo los trabajadores del
negocio, las entidades del negocio y otros eventos del negocio colaboran para desarrollar los
casos de uso de negocio.
4.1 Activar el “Modelo de Casos de Uso de Negocio”; luego ingresar a la carpeta “Casos de
Uso del Negocio”; ahora, dar doble clic sobre el diagrama “RN”, luego arrastrar los Casos
de Uso del Negocio al área de diagramas anterior; así:
MODELADO DE PROCESOS Página 67
4.2 Ahora, crear tres Casos de uso de Colaboración, colocar el nombre <<RN_”Nombre del
CUN”>>; según corresponda a cada uno de ellos, luego aplique la Apariencia Shape
Image. Finalmente, cambie el estereotipo de cada Colaboración a
BusinessUseCaseRealization; así:
4.3 Trazaremos una relación de Realización entre los elementos que están en el área de
diagramas. El diagrama de Realizaciones de negocio quedará así:
MODELADO DE PROCESOS Página 68
MODELADO DE PROCESOS Página 69
Actividad Nº 2
La compañía LB Motores se ha especializado en el servicio técnico de mantenimiento y
de reparación de motores, compresores, grupos electrógenos, así como de equipos mineros, de
construcción e Industria en general. El gerente del departamento de Informática solicita a usted
el desarrollo de una propuesta de Modelo de Casos de uso de Negocios, así como el Modelo de
Análisis de Negocios del sistema que permita realizar el seguimiento y costeo de los trabajos de
mantenimiento o reparación de motores y otros equipos que realiza para sus clientes. Para ello,
a continuación, se indica los procedimientos:
• El servicio inicia cuando una Orden de Trabajo ha sido generada por el recepcionista de la
compañía y es remitida a la planta, dicha orden de trabajo contiene: Nombre del cliente (o
empresa), fecha de recepción del equipo, tipo de servicio que puede ser de mantenimiento
o de reparación, características del equipo, si es motor se indicará; caballos de fuerza,
marca, modelo, tipo de alimentación (monofásica, trifásica), voltaje de trabajo y Nº de
revoluciones por minuto; en otro caso, se agregará otras características propias del equipo.
• Una vez que la orden de trabajo ha sido registrada en la planta, si el trabajo es de reparación
del equipo; se procede a diagnosticar el problema y establecer el método de solución, para
lo cual, el Técnico debe poder investigar dentro de su base de datos qué equipos ha
presentado problemas similares y cuáles fueron las soluciones implementadas. Una vez que
el técnico encargado ha elaborado el diagnóstico se procede a informar al cliente a través
de un email sobre el costo aproximado del servicio y solicita su aprobación para iniciar el
trabajo. Si el cliente da su aprobación, se procede a programar la reparación en base a la
carga de trabajo que tiene la planta. Los equipos que ingresan para mantenimiento tienen
una tarifa de pago preestablecida y son programados directamente teniendo en cuenta la
carga de trabajo de la planta.
• Durante el trabajo asignado, los técnicos solicitan sus requerimientos de materiales o
componentes, al jefe de almacén. Para ello, utilizan una hoja de pedidos, la cual indica el
número de orden de trabajo para el que solicita dichos materiales o componentes, el código
del técnico encargado que solicita, la fecha de pedido, el código del material solicitado y la
cantidad respectiva. Los materiales o componentes que no se han utilizado en su totalidad
serán devueltos al almacén, para ello los técnicos entregarán una hoja de reposición con el
detalle correspondiente.
• Los trabajos terminados deben registrarse en la base de datos.
MODELADO DE PROCESOS Página 70
Autoevaluación 2
1. Los trabajadores del negocio se encuentran en:
A. El mundo exterior
B. La organización objetivo
C. El campo de acción
D. En el interior de un CUN
E. N.A.
2. Señale cuál de las siguientes afirmaciones es verdadera:
A. El acrónimo del Modelo de Análisis del Negocio es MAB
B. La realización de un caso de uso de negocio no describe el comportamiento del CUN
C. Un trabajador de negocio puede no estar vinculado a ningún CUN
D. Una factura es una Entidad del Negocio
E. N.A.
3. Lo utilizan para comprender cómo trabaja el negocio actual y para evaluar el efecto de
hacer cambios al negocio.
A. MCU B. MAN C. CUN D. DCUN E. N.A.
4. Diga si la siguiente afirmación es verdadera o falsa: “Juan es un vendedor de la empresa,
entonces Juan es un trabajador del Negocio”
A. Verdadero B. Falso
5. Representa un Rol:
A. CUN B. EN C. RN D. BW E. N.A.
MODELADO DE PROCESOS Página 71
Sesión 3: Diagrama de Estados y de Actividades del MAN
1. ¿Cómo define UML a una máquina de estados?
Una máquina de estados es cualquier dispositivo que almacena el estado de un objeto
en un instante determinado y que puede reaccionar a un evento que actúa como estímulo
para producir un cambio de estado. Las máquinas de estados son también conocidas como
diagramas de estados o diagramas de transición de estados.
Un estado es en realidad un cambio dentro de la variedad de información que un objeto
puede tener en cada instante de tiempo. Los diagramas de estado reflejan para un objeto
determinado, todos los estados que ese objeto puede tener considerando cada uno de los
estímulos que hace cambiar su información en el tiempo. En resumen, los diagramas de
estado representan objetos basados en eventos actuando a manera de estímulos dentro de
un sistema reactivo, así también, permiten graficar diversos escenarios de casos de uso en
un contexto de negocios, en general, describen la forma cómo se mueven los objetos a
través de diversos estados a lo largo de su vida útil en los sistemas.
1.1 Componentes del diagrama de estados
1.1.1 Estado
Como ya se explicó con anterioridad, el estado refleja un valor específico en un instante
de tiempo dado. A continuación, se muestra el objeto según RSA:
1.1.2 Transición
Está representado con una flecha orientada para señalar el cambio de un estado a otro.
MODELADO DE PROCESOS Página 72
1.1.3 Evento
Es el estímulo que se dispara desde un estado anterior y va hacia un siguiente estado
del objeto.
1.1.4 Evento de Inicio
Toda máquina de estados debe tener siempre un único evento de inicio para señalar el
primer estímulo que permitirá su primer estado en el tiempo.
1.1.5 Evento de Finalización
El evento de finalización indica que la secuencia de estados ha concluido. En una
máquina de estados se permite que haya más de un evento de finalización.
MODELADO DE PROCESOS Página 73
1.1.6 Decisión
Es la capacidad que tiene una transición de estados para hacerlo condicionalmente al
haber efectuado una evaluación previa.
1.1.7 Región
Una región se utiliza para agrupar estados dentro de sub máquinas de estados.
MODELADO DE PROCESOS Página 74
1.1.8 Punto de salida
El punto de salida permite prevenir el caso en el que un objeto escapa desde una
máquina de estados o desde un estado compuesto. Por lo general, el punto de salida es
utilizado cuando el proceso no está completado, pero es necesario escapar debido a una
falla u cualquier otro caso.
1.2 Máquina de estado
A continuación, se muestra un ejemplo de la máquina de estado para un objeto Orden
de Compra:
MODELADO DE PROCESOS Página 75
2. ¿Qué son los diagramas de actividades?
Los diagramas de actividades son diagramas de flujo mostrando las diversas actividades
que se desarrollan en un caso de uso. Se utiliza mucho para comunicar a los interesados
sobre el comportamiento de los casos de uso frente a sus responsabilidades internas. Estas
actividades se desarrollan siguiendo una lógica precisa y coherente con los hechos reales y
relevantes del caso de uso; grafican fundamentalmente un proceso de negocios o flujo de
trabajo entre los usuarios y el sistema.
2.1 ¿Cuáles son los componentes de un diagrama de actividades?
A continuación, se presenta una lista de los componentes más relevantes de un
diagrama de actividades:
2.1.1 Partición
Denominado también Swimlane o camino. Es utilizado para indicar un stakeholder
relacionado con las actividades establecidas en su contenido.
2.1.2 Nodo Inicial
Es el nodo que marca el inicio del diagrama. Debe ser único.
2.1.3 Nodo Final
Este nodo señala el término del diagrama. Se permite más de un
nodo final en un mismo diagrama.
MODELADO DE PROCESOS Página 76
2.1.4 Acción
Es el nodo donde se describe la actividad a desarrollar.
2.1.5 Flechas de conexión
Se utiliza para establecer el flujo direccional entre los diversos nodos del diagrama.
2.1.6 Nodo de decisión
El nodo decisión siempre tiene, al menos, dos caminos que se separan en base a la
evaluación de una pregunta que se condiciona por alternativas de respuesta o de
posibilidades.
2.1.7 Envío de señal
Este nodo establece que se está enviando una señal a una actividad receptora.
2.1.8 Almacén de datos
Establece el almacenamiento de datos.
MODELADO DE PROCESOS Página 77
2.2 Diagrama de Actividades para la solicitud de libros en una biblioteca de la
Universidad
El siguiente diagrama muestra las actividades para solicitar un libro en la biblioteca de
una universidad.
MODELADO DE PROCESOS Página 78
LABORATORIO Nº 03
Diagramas de Máquinas de Estado
Diagramas de Actividades
1. IMPLEMENTACIÓN DE DIAGRAMAS DE MÁQUINAS DE ESTADO CON RSA DEL
CASO DESCRITO EN LA SESIÓN Nº 01
1.1 Carga de la aplicación IBM Rational Software Architect
1.2 Se carga la siguiente ventana, en base a lo que se ha desarrollado en los Laboratorios 01
y 02:
1.3 Crear el diagrama de Máquina de estado de la entidad: Orden de Compra, de la siguiente
manera:
MODELADO DE PROCESOS Página 79
1.4 Diagrama de Máquina de estado de la Entidad: Orden de Compra
1.5 Diagrama de Máquina de estado de la Entidad: Pedidos
MODELADO DE PROCESOS Página 80
1.6 Diagrama de Máquina de estado de la Entidad: Proveedor
1.7 Diagrama de Máquina de estado de la Entidad: Jefe de Logística
MODELADO DE PROCESOS Página 81
1.8 Diagrama de Máquina de estado de la Entidad: Producto
1.9 Diagrama de Máquina de estado de la Entidad: Transportista
1.10 Diagrama de Máquina de estado de la Entidad: Gerente Comercial
MODELADO DE PROCESOS Página 82
1.11 Diagrama de Máquina de estado de la Entidad: Gerente General
1.12 Diagrama de Máquina de estado de la Entidad: Tipo de Pago
1.13 Diagrama de Máquina de estado de la Entidad: Pagos
MODELADO DE PROCESOS Página 83
1.14 Diagrama de Máquina de estado de la Entidad: Asistente de Almacén
1.15 Diagrama de Máquina de estado de la Entidad: Nota de despacho interno
2. IMPLEMENTACIÓN DE DIAGRAMAS DE ACTIVIDADES CON RSA
2.1 Sobre el diagrama de Realizaciones de Negocio que se muestra a continuación:
MODELADO DE PROCESOS Página 84
2.2 Hacer clic derecho sobre el objeto “RN_Gestionar Abastecimiento”; luego elegir Add
Diagram y clic en Activity Diagram; así:
2.3 Colocar el Nombre: “DA_Gestionar Abastecimiento” Y poner el título: “DA para
gestionar el abastecimiento”.
2.4 Elabore el Diagrama de Actividades para Gestionar el Abastecimiento:
MODELADO DE PROCESOS Página 85
MODELADO DE PROCESOS Página 86
2.5 Diagrama de Actividades para Gestionar la Demanda:
MODELADO DE PROCESOS Página 87
2.6 Elaborar el Diagrama de Gestionar el Transporte:
MODELADO DE PROCESOS Página 88
Actividad Nº 03
Tomando en cuenta los requerimientos del gerente del departamento de Informática
de la compañía LB Motores planteado en la Actividad Nº 2; se pide la elaboración de las
máquinas de estados de cada una de las Entidades de Negocio y los diagramas de Actividades
de cada artefacto de Realización de caso de uso de negocio descritos en el modelo de análisis
del sistema que permita realizar el seguimiento y costeo de los trabajos de mantenimiento o
reparación de motores y otros equipos que la empresa realiza para sus clientes.
Autoevaluación 3
1. Se utiliza para abortar un proceso en casos no previstos:
A. Evento de finalización
B. Punto de Salida
C. Región
D. Decisión
E. N.A.
2. “Un diagrama de actividades puede tener uno o más eventos de Inicio”
A. Verdadero B. Falso C. Ni Verdadero, ni Falso
3. Establezca la veracidad o no de la siguiente afirmación “En los diagramas de actividades,
las decisiones pueden desviarse solamente en dos direcciones”
A. Verdadero B. Falso C. Ni Verdadero, ni Falso
4. Es un estímulo entre dos estados de un objeto:
A. Evento de Inicio
B. Evento de Finalización
C. Evento
D. Decisión
E. N.A.
5. En un diagrama de actividades, ¿una partición puede ser un caso de uso?
A. Verdadero B. Falso C. Ni Verdadero, ni Falso
MODELADO DE PROCESOS Página 89
Sesión 4: Modelo de Requerimientos
1. Requerimientos Funcionales
- Autenticarse con el sistema.
- Manejo de roles por usuarios y control de seguridad.
- Registrar documentos referentes al ingreso y salida de mercancías.
- Control de inventario en almacenes teniendo en cuenta stocks de exhibición.
- Mantenedor de productos.
- Mantenedor de proveedores.
- Mantenedor de almacenes.
- Mantenedor de transportistas.
- Emitir reportes de gestión de aprovisionamiento.
- Emitir reportes de gestión de atención de la demanda (Distribución interna).
- Emitir reportes gráficos de toma de decisiones.
2. Requerimientos no Funcionales
a. Requerimientos de Funcionalidad
- Actualización inmediata de stocks cuando se realice operaciones de almacén.
- Identificación de usuarios en cada operación.
b. Requerimientos de Facilidad de uso
- Deberá poder navegarse en el sistema mediante el teclado.
- El sistema deberá tener interfaces gráficas de navegación y en español.
c. Requerimientos de Confiabilidad
- El sistema deberá realizar backups de forma periódica y automatizada.
- El sistema deberá mantener una bitácora de los fallos que se vaya experimentado.
d. Requerimientos de Rendimiento
- El sistema deberá permitir el acceso concurrente de los usuarios.
- El sistema deberá soportar un estrés de carga para el escenario más extremo de la empresa.
MODELADO DE PROCESOS Página 90
e. Requerimientos de Soporte
- El sistema deberá ser capaz de trabajar independiente del navegador que se emplee (Sea
Chrome, Opera, Firefox o Internet Explorer).
- El sistema deberá estar claramente documentado en su código.
f. Requerimientos de Diseño
- El sistema deberá contemplar una estructura de tres capas bajo el patrón Modelo, Vista,
Controlador.
g. Requerimientos de Implementación
- El sistema deberá estar desarrollado en JSP a fin de permitir el soporte multiplataforma.
- Deberá trabajarse con la base de datos MySQL por su performance de este GBD para la
plataforma web.
h. Requerimientos de Interfaz
- El sistema deberá proporcionar la salida de los reportes a través documentos electrónicos
como Word, Excel y PDF.
- El sistema deberá usar colores y matices que no sean fuertes para la vista.
- Todo documento antes de ser guardado o exportado a un formato de documento
electrónico deberá permitir pre visualización.
i. Requerimientos Físicos
- Para que un cliente del sistema trabaje en el mismo deberá tener:
o Un procesador con arquitectura mayor o igual a 64 bits y 3.00 GHz en adelante.
o Memoria de 8GB como mínimo.
o Disco duro de 1 TB en adelante.
o Conexión a internet, mínimo de 100 mbps.
MODELADO DE PROCESOS Página 91
3. Descripción de Actores
A continuación se muestra la descripción de cada uno de los Actores del Sistema:
Tabla 1: HDAS Administrador
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Realizar mantenimiento de usuarios e ingresar al sistema como administrador.
- Controlar la asignación de los permisos a los demás usuarios.
Tabla 2: HDAS Jefe de Logística
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Elabora y genera las guías de remisión.
- Aprobar los documentos referentes al ingreso y salidos de mercancías de almacén.
- Visualizar el kardex de mercancías para el control de inventarios.
- Elabora las órdenes de compra.
- Genera los reportes de gestión logística.
MODELADO DE PROCESOS Página 92
Tabla 3: HDAS Asistente de almacén
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Registra el ingreso de mercancías a almacén.
- Registra nuevos productos.
- Registra el despacho de mercancías del almacén.
- Genera las actas de mermas.
- Registrar la asignación de transporte interno.
Tabla 4: HDAS Gerente general
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Modifica cantidades de ítems de órdenes de compra.
- Visualiza información de proveedores.
- Registrar prioridades de aprovisionamiento.
- Genera reportes de listados de reposición de tiendas.
MODELADO DE PROCESOS Página 93
Tabla 5: HDAS Jefe de tienda
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Visualizar los stocks de productos.
- Genera listados de reposición.
Tabla 6: HDAS Gerente General
Descripción del Actor:
Empresa: “Distribuidora Luján SAC”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 26/10/2020 Hoja: 1 de 1
Objetivos:
- Aprueba las órdenes de compra.
- Genera reportes gráficos de toma de decisiones.
- Ingresa métricas de control de desempeño.
MODELADO DE PROCESOS Página 94
LABORATORIO Nº 04
DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS
1. Creación del modelo de casos de uso de requerimientos
Para crear el modelo de requerimientos; debe hacer clic derecho sobre la carpeta
Models, luego elija “Create Model” y seleccione Standard template. Finalmente
pulse Next; así:
2. En la ventana Model; seleccione la carpeta Requeriments, y teniendo activada la
opción Blank Use Case Package, escriba en File name: “Modelo de casos de uso”;
lo que se muestra en la siguiente figura:
MODELADO DE PROCESOS Página 95
3. En la siguiente ventana, pulse el botón Next.
4. A continuación seleccione las opciones: UML Diagram Building Blocks, y UML Element
Building Blocks. Finalmente, pulse el botón Finish; así como se muestra en la siguiente
figura:
MODELADO DE PROCESOS Página 96
5. Agregar un diagrama de formato libre y colocar el nombre “Organización del MCU”;
luego acceda al diagrama y elabore los paquetes Actores y Casos de Uso. Así como se
indica en la siguiente figura:
MODELADO DE PROCESOS Página 97
6. Finalmente, renombre los diagramas de formato libre de cada paquete, así como el del
formato Main establecido como “Diagrama general de Casos de Uso”, y en el diagrama
“Actores”, elabore los estereotipos de cada uno de los siguientes Actores:
MODELADO DE PROCESOS Página 98
7. En el diagrama “Jerarquía de Actores”, elabore el diagrama jerárquico de actores del
sistema.
8. DIAGRAMA DE DEPENDECIA DE PAQUETES
El siguiente diagrama contiene los paquetes que conforman el sistema y sus respectivas
interrelaciones.
9. MODELO DE CASO DE USO POR PAQUETES
Presentamos a continuación los Diagramas de Casos de Uso del Sistema, por cada paquete
considerado en el diseño del sistema:
MODELADO DE PROCESOS Página 99
9.1 Paquete Seguridad
9.2 Paquete de Reportes
MODELADO DE PROCESOS Página 100
9.3 Paquete de Reutilizables
9.4 Paquete de Gestión del Transporte de Aprovisionamiento
MODELADO DE PROCESOS Página 101
9.5 Paquete de Gestión del Abastecimiento
9.6 Paquete de Gestión de la Demanda
MODELADO DE PROCESOS Página 102
10. DIAGRAMA GENERAL DE CASO DE USO
A continuación tenemos el diagrama general que agrupa a todos los casos de uso.
MODELADO DE PROCESOS Página 103
11. HOJA DE DESCRIPCIÓN DE CASO DE USO
En esta parte mostramos a continuación las Hojas de Descripción de los Casos de Uso.
Tabla 6: HDCU Emitir reportes de gestión
Descripción de Caso de Uso: Emitir
reportes de gestión
Empresa: “Distribuidora Luján”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 30/10/2020 Hoja: 1 de 1
Objetivo: Emitir reportes de la gestión de almacenes para la gestión logística.
Pre - Condiciones:
- Ingresar al sistema logeandose con su usuario y contraseña.
- Tener registrados en la base de datos los despachos realizados.
Flujo Principal:
- Seleccionar la fecha de límite inicial del intervalo de tiempo deseado.
- Seleccionar la fecha de límite final del intervalo de tiempo deseado.
- Ingresar el número top de productos más despachados.
- Elección del tipo de documento “.xls” o “.pdf” en el que se desea exportar el reporte.
Post - Condiciones: El reporte generado en el formato que se haya elegido quedara guardado
en la zona de descargas del sistema.
Requisitos satisfechos:
- Gestionar la información de los despachos realizados desde el almacén principal a los sub
almacenes de la empresa.
MODELADO DE PROCESOS Página 104
Tabla 7: HDCU Gestionar usuarios
Descripción de Caso de Uso:
Gestionar usuarios
Empresa: “Distribuidora Luján”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 30/10/2020 Hoja: 1 de 1
Objetivo: Registrar, editar o eliminar los usuarios.
Pre - Condición:
- Gestionar roles.
Flujo Principal:
- Listado de usuarios, con las opciones de registrar (F1), editar (F2) o eliminar (F3).
Flujo Secundario:
- F1: Registrar Usuario
- Muestra un formulario donde se ingresarán los datos del usuario.
- Dar clic en el botón “Grabar y Terminar”. (E1)
- F2: Editar Usuario
- Muestra un formulario donde se muestran los datos del usuario seleccionado
- Editar los datos necesarios y dar clic en el botón “Grabar y Terminar”. (E1)
- F3: Eliminar Usuario
- Muestra un mensaje, donde se pide confirmar la eliminación del usuario
seleccionado.
- Dar clic en el botón “Eliminar”.
Excepciones:
- E1: Los campos no deben estar vacíos y se debe seleccionar el rol.
Post - Condiciones: Ninguna.
Requisitos satisfechos:
- Permitir el acceso al sistema teniendo los usuarios registrados.
MODELADO DE PROCESOS Página 105
Tabla 8: HDCU Aprobar órdenes de compra
Descripción de Caso de Uso: Aprobar
órdenes de compra
Empresa: “Distribuidora Luján”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 30/10/2020 Hoja: 1 de 1
Objetivo: Aprobar órdenes de compra para su ejecución.
Pre - Condición:
- Elaboración de órdenes de compra.
- Las órdenes de compra por aprobar deberán estar guardadas en el sistema.
Flujo Principal:
- Listar las órdenes de compra pendientes por aprobar y registrar su aprobación F1 para luego
terminar archivándola después de aprobarla F2.
Flujo Secundario:
- F1: Registrar Aprobación
- Muestra todos los detalles de la orden de compra seleccionada
- Dar clic en el botón “Observación”. (E1)
- Se da click en el botón “Aprobar orden”.
- F2: Guardar orden de compra
- Se selecciona el botón “Guardar” y se registra con estado de aprobada en el sistema.
Excepciones:
- E1: Se detallada las observaciones y se envía al repositorio de órdenes observadas por
subsanar dando click en el botón “Enviar a órdenes observadas”.
Post - Condiciones: Las órdenes quedara guardadas mostrado su aprobación.
Requisitos satisfechos:
- Tener probadas las órdenes de compra elaboradas para su ejecución.
MODELADO DE PROCESOS Página 106
Tabla 9: HDCU Modificar cantidades de compra
Descripción de Caso de Uso: Modificar
cantidades de compra
Empresa: “Distribuidora Luján”
Sistema: Sistema de Gestión Logística
Elaborado por: Juan Alberto Pérez Chávez
Fecha: 30/10/2020 Hoja: 1 de 1
Objetivo: Editar y registrar las modificaciones de las cantidades a comprar.
Pre - Condición:
- La orden de compra deberá estar guardad en el sistema.
Flujo Principal:
- Se lista las órdenes de compra por revisar, se selecciona una y se edita F1, y se finaliza
comunicando la realización de las observaciones F2.
Flujo Secundario:
- F1: Editar cantidades
- Muestra un formulario donde se ingresarán las nuevas cantidades sugeridas.
- F2: Registrar revisión
- Muestra un formulario donde se selecciona la opción de comunicación al jefe de
logística.
- Editar los datos necesarios y dar clic en el botón “Grabar y Terminar”. (E1)
Excepciones:
- E1: Los campos deberán estar llenados solo con valores numéricos.
Post - Condiciones: Ninguna.
Requisitos satisfechos:
- Tener cantidades de compra mejor elaboradas y registradas.
UNIDAD II
El Modelado de Datos
Capacidades
Al término de la segunda unidad, el estudiante será capaz de diseñar e implementar una
base de datos a través del modelado de datos.
MODELADO DE DATOS Página 108
Sesión 5
El Modelado de datos
1. ¿Qué es el Modelado de datos?
El modelado de datos; también conocido como “Modelamiento de datos”, es el proceso
que se aplica para crear una representación gráfica de la visión que tienen los usuarios de los
datos, de esto se desprende que es la tarea más importante en el desarrollo de eficaces
aplicaciones de bases de datos. Su importancia nos permite afirmar que en caso se hiciera una
representación incorrecta de la visión que tienen los usuarios de los datos, este error nos llevaría
a la creación de aplicaciones difíciles de usar, incompletas y por supuesto frustrantes; por ello,
el modelado de datos es la base de todo el trabajo subsecuente en el desarrollo de bases de
datos y de sus aplicaciones.
1.1 ¿Qué es una base de datos?
Una base de datos es una fuente integral de datos que está pensada para que sea
compartida por muchos usuarios con una diversidad de aplicaciones. Sus principales objetivos,
son:
1. Asegurarse que esta base de datos pueda ser compartida entre los usuarios de una
diversidad de aplicaciones.
2. Mantener datos que sean precisos y consistentes.
3. Asegurarse que todos los datos requeridos para las aplicaciones actuales y futuras estén
fácilmente disponibles. Permitir que la base de datos evolucione y que las necesidades de
los usuarios crezcan.
4. Permitir que los usuarios construyan su vista personal de los datos sin preocuparse de la
forma en que los datos estén físicamente guardados.
5. Mantener una representación gráfica de la base de datos a través del Modelado de datos.
1.2 ¿Qué es un sistema de administración de base de datos?
Aunque algunos le llaman Sistema de Gestión de Bases de Datos (SGBD), también es
conocido como DBMS (Data Base Management System). Es la parte medular de la base de datos
ya que permite la creación, modificación y actualización de las bases de datos; así como, la
MODELADO DE DATOS Página 109
recuperación de datos y la generación de reportes. La persona que asegura que la base de datos
satisfaga sus requerimientos es el Administrador de la base de datos, también conocido como
DBA (Data Base Administrator).
En la figura anterior, el Mundo Real se refiere a las políticas, reglas de negocios y
procedimientos existentes, para llevar a cabo las actividades del negocio. El proceso de
recolección, clasificación, análisis y selección de los datos relevantes constituye la Abstracción
de esa realidad.
1.3 El Modelo Entidad - Relación
El Modelo Entidad – Relación es en sí, el modelado de datos, ya que se emplea para
interpretar, especificar y documentar los requerimientos en sistemas de procesamiento de base
de datos. A continuación, vamos a describir sus componentes.
1.3.1 Las Entidades
Una Entidad es cualquier objeto o evento acerca del cual recolectamos datos; así la entidad
puede ser una persona, lugar o cosa; por ejemplo, un cliente, un trabajador o un artículo.
También son entidades los eventos o acontecimientos que ocurren en el tiempo; por ejemplo,
una venta, un requerimiento de artículos de almacén o la matrícula de un alumno.
MODELADO DE DATOS Página 110
1.3.2 Clase de Entidades
Las clases de entidades son los grupos o conjuntos de entidades del mismo tipo.
Generalmente, usamos el término “Entidad” en vez de “Clases de Entidades”. Por ejemplo; a la
Entidad que representa a los datos de un alumno en particular, la podríamos llamar: ALUMNO,
luego, dado que un alumno pertenece a la clase de entidad ALUMNOS; entonces, podríamos
generalizar y referirnos al conjunto de entidades con el nombre: ALUMNOS.
1.3.3 Atributos
Los Atributos son las propiedades que describen las características de una Entidad. Por
ejemplos, en la Entidad PACIENTE, registraremos los atributos: Nombre, Dirección, Fecha de su
última consulta y los detalles de la consulta, diagnóstico y receta. Para la Entidad EMPLEADO,
nos podría interesar registrar su Nombre Completo, Fecha de Ingreso, Cargo y Área de Trabajo.
Para un CLIENTE, necesitaremos registrar su Número de RUC, Nombre Completo, Número de
DNI, Dirección, Teléfono y Fecha de Registro. En la Entidad PRODUCTO, requerimos almacenar
su Descripción, Unidad de Medida, Precio Unitario, entre otras características.
1.3.4 Atributos Identificadores
Los Atributos Identificadores, son aquellos Atributos que se usan para identificar la
ocurrencia de uno o más registros de datos. Estos Atributos también se conocen con el nombre
de Claves. Por ejemplo; para identificar a un Cliente podremos usar su Número de RUC. En
ocasiones se acostumbra el uso de un código de identificación único para reconocer a un cliente
específico, aunque otras veces, usaremos por ejemplo el Apellido Paterno para acceder a un
grupo de clientes. Los Pedidos de Venta, tienen: NúmeroPedido como Atributo Identificador.
1.3.5 Tipo de atributos Identificadores
1.3.5.1 Atributos de Clave Primaria
Estos Atributos se utilizan para identificar a uno y sólo un registro en el conjunto de
entidades. Una de sus características principales es que nunca deberán estar en blanco y no
tener valores repetidos. Por ejemplos; Podremos usar el Número del Seguro Social para
identificar a uno y sólo un Asegurado específico. Asimismo, usaremos el Código del Producto
para identificar a un Producto particular. Los Alumnos de una universidad se podrán identificar
por su Código de Matrícula. Finalmente, Identificaremos a los Libros de una biblioteca con el
Código de Libro.
MODELADO DE DATOS Página 111
1.3.5.2 Atributos de Claves Foráneas
Son aquellos Atributos que se usan para establecer una relación con otra Entidad, en la
cual estos Atributos se han definido como Clave Primaria. Por ejemplo; en la Entidad
FACTURA usamos el Número de RUC del cliente para identificar a quién se le ha vendido,
pero dicho Número de RUC es Clave Primaria en la entidad CLIENTES. Por lo tanto, el atributo
Número de RUC en la entidad FACTURA es una Clave Foránea. Asimismo, en la Entidad
NOTAS, usaremos el Atributo Código de Matricula para identificar a qué estudiante le
pertenece dichas notas y como el Código de Matricula es clave primaria en la entidad
ESTUDIANTE, entonces el Código de Matrícula será Clave Foránea en la Entidad NOTAS.
1.3.5.3 Atributos de Claves Concatenadas
Estos Atributos se forman con la unión de dos o más Atributos y juntos así formados, se
utilizan como Claves de alguna Entidad. Por ejemplo; usaremos el Atributo Número de
Pedido más el Atributo Código del Artículo para registrar una ORDEN DE PEDIDO. Así
también, el Atributo concatenado NumeroFactura más CodigoProducto, se usará para
registrar la VENTA de un Producto.
1.3.6 Relaciones y Relacionamientos
Las Relaciones son las asociaciones que podemos efectuar entre las Entidades.
1.3.6.1 Grado de una Relación
El grado de una Relación se refiere al número de entidades que se asocian a través de la
relación. Entre los diferentes tipos de relaciones según el grado, tenemos:
- Relaciones Binarias
Son aquellas relaciones de grado 2, es decir, se forman con dos
entidades diferentes. En este caso, un vendedor puede
efectuar cero, uno o más pedidos.
1.3.6.2 Relacionamientos
Los Relacionamientos se aplican a las asociaciones entre las ocurrencias de las
entidades.
MODELADO DE DATOS Página 112
- Relacionamiento uno-a-uno Relacionamiento uno-a-muchos
- Relacionamiento Muchos-a-Uno
- Relacionamiento Muchos-a-Muchos - Relacionamiento Muchos-a-Muchos
(Modelo Lógico) (Modelo Físico)
MODELADO DE DATOS Página 113
1.3.6.3 Las Entidades débiles
Las Entidades débiles están definidas en el modelo de datos para representar aquellas
entidades que dependen de la definición de otras entidades. Por ejemplo; examinemos la
relación entre los trabajadores y sus Salarios; aquí, la entidad SALARIO “depende” de la
presencia de la entidad TRABAJADOR, esto significa que los datos de SALARIO sólo pueden
almacenarse en la base de datos si el SALARIO se relaciona con un TRABAJADOR.
1.3.6.4 Las Entidades Fuertes
Decimos que las Entidades son fuertes si los
datos que contienen permanecerán a lo largo de
la vida útil de los sistemas. Por ejemplo; en el
caso anterior se define a la entidad TRABAJADOR
como una Entidad Fuerte, pues el trabajador es
una de las principales razones de la existencia del
modelado del sistema por lo que su permanencia
está garantizada.
1.3.6.5 Las Entidades de Sub tipos
Algunas Entidades requieren especificarse con
otro conjunto de atributos, por ejemplo, la entidad
PRODUCTO tiene los atributos: Código, Descripción,
Unidad de Medida, Ubicación y Stock. Sin embargo,
la empresa distingue claramente tres tipos
diferentes de productos; Materia Prima, que
aquellos productos que la empresa compra para
utilizarlos en su producción, Productos terminados,
que son los productos que la empresa fabrica. Estos
productos se distinguen por los siguientes datos
adicionales:
• MATERIA_PRIMA (Fecha de Expiración, Pedido Mínimo, Pedido, Pedido Máximo)
• PRODUCTO_TERMINADO(Tipo, Formato, Calidad, Espesor, Dimensión, Peso)
MODELADO DE DATOS Página 114
1.3.6.6 Tipo de Relacionamientos
El Relacionamiento entre las entidades puede ser de uno de los dos tipos siguientes:
A) Relacionamiento Identificatorio
Este tipo de Relacionamiento se presenta cuando la entidad destino es definida por el
atributo identificador de la entidad origen. Se representa gráficamente por medio de una
línea continua. Se aprecia que el Relacionamiento de tipo Identificatorio migra
automáticamente la clave primaria de la entidad origen hacia el área de claves de la entidad
destino.
B) Relacionamiento No Identificatorio
El Relacionamiento No Identificatorio, se presenta cuando la entidad destino NO está
definida por el atributo identificador de la entidad origen. Su representación gráfica es por
medio de una línea punteada. Se aprecia que el relacionamiento de tipo No Identificatorio
migra automáticamente la clave primaria de la entidad origen hacia el área de no-claves de
la entidad destino.
MODELADO DE DATOS Página 115
2. Desarrollo de un caso de Modelado de datos
La compañía de seguros “Ave Fénix” es una empresa de seguros de vida que brinda atención
médica a diversos usuarios a través de convenios con Instituciones educativas, ya sea Colegios,
Institutos de Educación Superior y Universidades. Las operaciones del negocio se rigen bajo el
siguiente régimen:
• Los usuarios que pueden acceder al seguro médico son: Estudiantes, Docentes y Personal
Administrativo de la Institución Educativa.
• El Seguro Médico es voluntario. Los estudiantes pagarán durante sus respectivas matrículas,
los docentes y personal administrativo pagarán con descuenta por planilla.
• El Seguro Médico tiene una duración de un año académico de 10 meses. Asimismo, este
Seguro cubre los siguientes servicios: Atención en consultorio externo; medicinas,
tratamiento médico, intervenciones quirúrgicas, exámenes, etc. por un monto máximo de
$ 4,000.00. El Seguro Médico no cubre el servicio de Vacunas o necropsia.
• Cuando el usuario requiere atención médica en un centro hospitalario autorizado (Clínica),
deberá presentar su carné del seguro y una ficha de atención expedida por la Institución
Educativa, en dicha ficha la clínica detallará todo lo relacionado al Tratamiento; las recetas,
medicamentos, diagnóstico, médico que atiende, exámenes efectuados, etc. Y sobre todo
se adjunta la Factura cuyo monto la compañía de seguros deberá pagar por dicho
tratamiento, el cual será descontado del monto del seguro.
• La compañía llevará cuenta del saldo del monto del usuario asegurado por cada atención
médica. En caso el usuario exceda el monto del seguro, el saldo deberá ser asumido por él
mismo.
• El jefe del centro de Informática de la Compañía le ha encargado a usted, la elaboración del
modelado de datos que le permita consultar cuáles han sido las atenciones médicas de los
usuarios asegurados, cuáles es su récord de pagos al seguro y el monto de las atenciones
brindadas por cada centro hospitalario.
2.7 Elaboración del Modelado de datos del caso
2.7.1 Identificación de Entidades potenciales
Después de un análisis minucioso al caso presentado, se ha identificado las siguientes
posibles entidades:
a) Usuarios; entre los cuales se identificaron: Usuarios Estudiantes, Usuarios Docentes y
Usuarios Administrativos.
b) Instituciones Educativas
MODELADO DE DATOS Página 116
c) Pagos al Seguro
d) Servicios
e) Clínicas
f) Carné del Seguro
g) Ficha de Atención
h) Facturas
i) Saldos del monto asegurado
2.7.2 Breve referencia de las Posibles Entidades
Tomando en cuenta el primer trabajo de selección de entidades, haremos un mejor
acercamiento a través de una breve referencia de las entidades identificadas, veamos:
a. Usuarios
Esta entidad es fuerte, pues contiene todos los datos que se refieren a los usuarios que
se han inscrito en el seguro médico. Los usuarios se han clasificado en tres tipos:
• Usuarios Estudiantes
Son aquellos estudiantes que registran matrícula actual en la Institución educativa.
• Usuarios Docentes
Son los docentes contratados o estables que trabajan actualmente en la Institución
Educativa.
• Usuarios Administrativos
Son todas las personas no docentes que se encuentran registradas en planilla de la
Institución Educativa.
b. Institución Educativa
Aquí se registrará los datos de las Instituciones Educativas que han firmado convenio
con la compañía aseguradora. Es una entidad Fuerte.
c. Pagos de los usuarios
Es una entidad Débil, pues registrará los pagos ya sea semestral ó anual que los usuarios
deberán efectuar a la compañía aseguradora quién se reservará los derechos de atención a
los usuarios impagos.
d. Servicios
Los servicios se describen en una entidad Fuerte, pues contiene la lista de aquellos
servicios habilitados a través del convenio, entre los cuáles tenemos; Atención médica
ambulatoria, medicinas, tratamiento médico, intervenciones quirúrgicas, exámenes, entre
otros. Es bueno recordar que las vacunas no son un servicio del seguro.
MODELADO DE DATOS Página 117
e. Clínicas Autorizadas
Es una entidad Fuerte. Aquí se registrará los datos de las clínicas que tiene contrato con
la compañía aseguradora.
f. Carné del Seguro
El carné del seguro contiene los datos de los usuarios contratantes, así como su vigencia.
Es una entidad fuerte.
g. Ficha de Atención
La ficha de atención será llenada por la Clínica después de cada atención efectuada. Es
una entidad Débil. Aquí se consignará los datos que se refieren al tratamiento,
medicamentos suministrados, exámenes efectuados, etc.
h. Factura
La factura contiene los datos de la Clínica, del usuario, el detalle de la atención efectuada
y el monto a pagar por dicho tratamiento. Es elaborada por la administración de la Clínica y
está dirigida a la compañía aseguradora para que asuma los gastos correspondientes. Es una
Entidad Débil.
i. Saldos del Monto Asegurado
Los saldos del monto asegurado se registran con el fin de llevar el control de los montos
de las atenciones brindadas al usuario. Es una entidad Débil.
2.7.3 Identificación de Relaciones y Relacionamientos
Las entidades seleccionadas serán evaluadas a fin de establecer cuáles son sus
relaciones con las demás entidades, veamos el siguiente análisis:
a. Los usuarios, tales como estudiantes, docentes y administrativos contienen datos comunes
tal como se indica en la gráfica siguiente:
b. Asimismo, un usuario tiene un carné del seguro, también un usuario tiene uno o más pagos
al seguro y tiene una o más fichas de atención. Veamos estas relaciones:
MODELADO DE DATOS Página 118
c. Las Fichas de Atención deberán contener
información acerca de las clínicas
autorizadas, los servicios habilitados, las
Instituciones Educativas a las que pertenece
el usuario, el tratamiento efectuado al
usuario, las Facturas generadas y los saldos
del usuario del seguro, entonces; todas estas
relaciones las podremos graficar de la
siguiente manera:
d. El gráfico del modelado obtenido se muestra a continuación:
MODELADO DE DATOS Página 119
2.7.4 Modelado de datos con Atributos
Los Atributos se consignarán según las características más relevantes de las Entidades y
teniendo en cuenta los requerimientos del sistema. El modelado lógico completo se muestra a
continuación, veamos:
MODELADO DE DATOS Página 120
LABORATORIO Nº 05
USO DE HERRAMIENTAS CASE EN VISUAL BASIC NET
PARA INTEGRAR LA BASE DE DATOS DE UNA BIBLIOTECA
1. DISEÑO DE LA BASE DE DATOS
a) Modelado de Datos en Erwin
MODELADO DE DATOS Página 121
b) Base de Datos en SQL Server
2. DISEÑO DEL MENÚ PRINCIPAL
MODELADO DE DATOS Página 122
3. IMPLEMENTACIÓN DEL MENÚ PRINCIPAL EN VISUAL BASIC .NET
3.1 Operaciones con Interfaz de Múltiples Documentos (MDI)
• Cargar un nuevo proyecto denominado: WinAppBIBLIOTECA
• Sobre el Formulario; colocar la propiedad IsMdiContainer en true
• Arrastrar el Objeto al formulario y diseñar el Menú; tal como
se indica en el cuadro anterior; de la siguiente manera:
3.2 Implementación del Menú principal
4. AGREGANDO ORÍGENES DE DATOS
• En el Menú Principal de Visual Basic, elija:
o Datos → Agregar nuevo origen de datos …
o En el Asistente para la configuración de orígenes de datos:
o Seleccione Base de datos y aplique el botón Siguiente
MODELADO DE DATOS Página 123
o En la ventana Elegir la conexión de datos; aplique en el botón: Nueva
Conexión… (Entonces, veremos:)
• Coloque un punto en el combo: Nombre del Servidor y elija la base de datos:
BIBLIOTECA; luego Click en Aceptar
• En la siguiente ventana, haga click en el botón Siguiente y luego otra vez.
• Finalmente:
MODELADO DE DATOS Página 124
• Seleccione Tablas y click en Finalizar.
• Ahora, elija: Datos → Mostrar orígenes de datos …
• Veremos entonces, la siguiente ventana:
• Agregaremos 14 formularios nuevos; uno por cada una de las 14 opciones del Menú
Principal; colocando a los formularios como MDI Hijo; de la siguiente manera:
o Proyecto → Agregar Windows Form (14 veces) y colocaremos en cada uno:
o Propiedad Name: frmLIBROS
o Propiedad Name: frmAUTORES
o Propiedad Name: frmCATEGORÍAS
o Propiedad Name: frmEDITORIALES
o Propiedad Name: frmUSUARIOS
o Propiedad Name: frmCARNETS
o Propiedad Name: frmPAGOS
o Propiedad Name: frmPRESTAMOS
o Propiedad Name: frmLECTURASALA
o Propiedad Name: frmLECTURADOMICILIO
o Propiedad Name: frmRESERVACIONES
o Propiedad Name: frmPEDIDOS
o Propiedad Name: frmGUIAS
o Propiedad Name: frmFACTURAS
MODELADO DE DATOS Página 125
• El título de cada formulario será ACTUALIZACIÓN DE …… (Tabla)
• Arrastraremos cada tabla de los orígenes de datos a su correspondiente formulario;
así:
5. CODIFICACIÓN DEL MENÚ PRINCIPAL EN VISUAL BASIC .NET
Public Class MDIFormBIBLIOTECA
Private Sub AutoresToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles AutoresToolStripMenuItem.Click
Dim objAutores As New frmAUTORES
objAutores.MdiParent = Me
objAutores.Show()
End Sub
Private Sub LibrosToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles LibrosToolStripMenuItem.Click
Dim objLibros As New frmLIBROS
objLibros.MdiParent = Me
objLibros.Show()
End Sub
MODELADO DE DATOS Página 126
Private Sub CategoríasToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles CategoríasToolStripMenuItem.Click
Dim objCategorias As New frmCATEGORIAS
objCategorias.MdiParent = Me
objCategorias.Show()
End Sub
Private Sub EditorialesToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles EditorialesToolStripMenuItem.Click
Dim objEditoriales As New frmEDITORIALES
objEditoriales.MdiParent = Me
objEditoriales.Show()
End Sub
Private Sub UsuariosToolStripMenuItem1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles UsuariosToolStripMenuItem1.Click
Dim objUsuarios As New frmUSUARIOS
objUsuarios.MdiParent = Me
objUsuarios.Show()
End Sub
Private Sub CarnetsToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles CarnetsToolStripMenuItem.Click
Dim objCarnets As New frmCARNETS
objCarnets.MdiParent = Me
objCarnets.Show()
End Sub
MODELADO DE DATOS Página 127
Private Sub PagosToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles PagosToolStripMenuItem.Click
Dim objPagos As New frmPAGOS
objPagos.MdiParent = Me
objPagos.Show()
End Sub
Private Sub PréstamosToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles PréstamosToolStripMenuItem.Click
Dim objPrestamos As New frmPRESTAMOS
objPrestamos.MdiParent = Me
objPrestamos.Show()
End Sub
Private Sub LecturaEnSalaToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles LecturaEnSalaToolStripMenuItem.Click
Dim objLecturaEnSala As New frmLECTURASALA
objLecturaEnSala.MdiParent = Me
objLecturaEnSala.Show()
End Sub
Private Sub LecturaADomicilioToolStripMenuItem_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles LecturaADomicilioToolStripMenuItem.Click
Dim objLecturaADomicilio As New frmLECTURADOMICILIO
objLecturaADomicilio.MdiParent = Me
objLecturaADomicilio.Show()
End Sub
MODELADO DE DATOS Página 128
Private Sub ReservasToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles ReservasToolStripMenuItem.Click
Dim objReservas As New frmRESERVACIONES
objReservas.MdiParent = Me
objReservas.Show()
End Sub
Private Sub PedidosToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles PedidosToolStripMenuItem.Click
Dim objPedidos As New frmPEDIDOS
objPedidos.MdiParent = Me
objPedidos.Show()
End Sub
Private Sub GuíasToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles GuíasToolStripMenuItem.Click
Dim objGuías As New frmGUÍAS
objGuías.MdiParent = Me
objGuías.Show()
End Sub
Private Sub FacturasToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles FacturasToolStripMenuItem.Click
Dim objFacturas As New frmFACTURAS
objFacturas.MdiParent = Me
objFacturas.Show()
End Sub
End Class
MODELADO DE DATOS Página 129
6. IMPLEMENTACIÓN DEL MENÚ CONTEXTUAL
Un Menú Contextual, es un menú que aparece flotante al dar clic derecho sobre un
objeto; para ello, seguiremos los siguientes pasos:
• Arrastrar el objeto ContextMenuStrip hacia el formulario
• Diseñe las siguientes opciones:
• Seleccione como objeto de activación el formulario frmBIBLIOTECA y configure la
propiedad ContextMenuStrip con el valor ContextMenuStrip1.
7. CODIFICACIÓN DE LAS OPCIONES DEL MENÚ CONTEXTUAL
Private Sub CascadaToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles CascadaToolStripMenuItem.Click
Me.LayoutMdi(0)
End Sub
Private Sub HorizontalToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles HorizontalToolStripMenuItem.Click
Me.LayoutMdi(1)
End Sub
MODELADO DE DATOS Página 130
Private Sub VerticalToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles VerticalToolStripMenuItem.Click
Me.LayoutMdi(2)
End Sub
Private Sub AlineaVentanasToolStripMenuItem_Click(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles AlineaVentanasToolStripMenuItem.Click
Me.LayoutMdi(3)
End Sub
8. FORMULARIO CON MENÚ CONTEXTUAL
MODELADO DE DATOS Página 131
9. OPCIONES DEL MENÚ EN VERTICAL
10. CREACIÓN DE BARRAS DE HERRAMIENTAS
• Arrastrar el control ToolBar hacia el formulario
• Agregar un control ImageList
• Configurar la propiedad Image, con una lista de imágenes; así:
MODELADO DE DATOS Página 132
• Ahora, veamos las propiedades de ToolBar1:
Objeto Propiedad Valor
ToolBar1 ImageList ImageList1
Buttons Colección … Asociar cada ImageIndex …
• Finalmente, tendremos:
MODELADO DE DATOS Página 133
Actividad Nº 5
Pizzería La Madonna prepara y vende pizzas al mejor estilo del gusto italiano. El jefe del
centro de Informática de esta compañía le ha encargado a usted que elabore un Modelo de
datos para la base de datos que permita registrar y controlar los pedidos de pizzas efectuadas
por sus clientes, para ello explicaremos el proceso siguiente:
a. Los clientes efectúan sus pedidos a través de una llamada telefónica. La recepcionista anota
el Nº de teléfono del cliente. Los datos de los clientes nuevos son ingresados
inmediatamente a la base de datos, estos datos son el nombre completo, dirección, distrito
y número de DNI.
b. Una vez que la recepcionista ha tomado la orden, se calcula el impuesto y el total a pagar;
luego ella pasará el pedido a la cocina y elaborará el recibo correspondiente en el que se
consigna el nombre del cliente, su dirección, número de teléfono, fecha actual, hora de
recepción del pedido, concepto, impuesto de ley y monto total a pagar.
c. Algunos clientes solicitan factura, en ese caso se anotará el número de ruc del cliente; así
como los datos del detalle del pedido, es decir, el producto, la cantidad, precio por unidad,
importe, el precio bruto, impuestos de ley, descuentos é importe neto a pagar.
d. Ocasionalmente se imprimen ofertas especiales a través de cupones para que el cliente
pueda obtener un descuento del 20 % del total a pagar, cuando ha juntado hasta 5 cupones.
e. El personal que hace las entregas de los pedidos alcanza a los clientes una copia del pedido,
el recibo de pago y un cupón para las ofertas en vigencia. Cuando un cliente ha acumulado
5 cupones los entregará al personal de reparto quienes actualizarán el recibo consignando
el valor del descuento obtenido y recalculando el monto a pagar respectivo.
f. Un compromiso de la empresa es que cada pedido es atendido en no más de 20 minutos,
desde el momento de iniciado el pedido, de tal manera que el cliente no pagará
absolutamente nada si el repartidor efectúa la entrega en un tiempo mayor.
g. La compañía contrata los servicios de varias empresas service’s distribuidas por áreas para
el reparto de las pizzas, a la cual le asigna el 25% del precio de las pizzas como pago de
comisión. La compañía y el service de reparto asumen el costo de las pizzas a 50% cada una,
de aquellas que se tuvieron que dejar en forma gratuita debido a entregas a destiempo.
h. Se reparten pizzas de tipo familiar, personales y especiales, además las hay Hawaianas,
Argentinas, Mexicanas, Italianas y con peperoni, mozzarella, etc. cuyos precios van desde
S/. 25.00 a S/. 90.00 cada una.
MODELADO DE DATOS Página 134
Autoevaluación 5
1. Responda si es verdadera o falsa la siguiente afirmación: “Un atributo de clave foránea
puede ser nulo en algunos casos”
A. Verdadero B. Falso C. Ni verdadero, ni falso
2. El proceso de análisis y selección de datos relevantes para el modelado de datos es
conocido como:
A. Implementación
B. Mundo real
C. Abstracción
D. Atributos
E. N.A.
3. Esta clave siempre se define en una entidad destino:
A. Clave Primaria
B. Clave Concatenada
C. Clave Secundaria
D. Clave Foránea
E. N.A.
4. Indique si la siguiente afirmación es verdadera o falsa. “Las entidades de sub tipos
siempre tienen atributos comunes”
A. Verdadero B. Falso C. Ni verdadero, ni falso
5. Indique si es verdadera o falsa la siguiente afirmación: “Una Entidad sólo tiene una Clave
Primaria”
A. Verdadero B. Falso C. Ni verdadero, ni falso
MODELADO DE DATOS Página 135
Sesión 6: Normalización de datos
1. ¿Cuáles son las condiciones apropiadas de una base de datos?
Sabemos que una base de datos es un almacén que permite guardar grandes cantidades
de datos de forma organizada con la finalidad de que se pueda recuperar y mantener con suma
facilidad; para ello, se requiere que el proceso de crecimiento de la base de datos esté
perfectamente controlado; veamos el detalle de las condiciones esperadas:
- La base de datos debe ser Flexible
La estructura de la base de datos debe poder facilitar su expansión o crecimiento natural,
sin inconvenientes de complejidad. Las estructuras actuales no tendrían que ser
modificadas, lo que se requiera, simplemente se debería poder agregar.
- La base de datos debe ser Eficiente
La eficiencia de una base de datos se logra cuando dicha base de datos responde a las
consultas requeridas con mucha facilidad y en la mejor brevedad posible. También podemos
hablar de eficiencia cuando los datos no están duplicados, y los espacios de almacenamiento
no se desperdician con casilleros nulos o vacíos.
- La base de datos debe ser Eficaz
La eficacia está referida al hecho de que la base de datos está cumpliendo sus objetivos
básicos.
1.1 ¿Qué es la dependencia funcional?
La dependencia funcional es la relación de dependencia que existe entre los atributos
de una Entidad; estas dependencias son definidas por el mismo modelo que es el reflejo de
los objetos y su comportamiento dentro de la realidad.
En términos de dependencia entre atributos diremos que, “un Atributo B es
funcionalmente dependiente de otro atributo A si cada valor de la columna A determina uno
y solamente un valor de la columna B”.
Gráficamente, una relación de dependencia funcional entre atributos como el que se ha
señalado en el ejemplo, se indica como: A → B. En este caso, el atributo A se denomina
Determinante.
Tal como se indicó en la lección anterior, toda entidad o tabla de datos tiene un atributo
identificador primario; es decir un atributo que no acepta valores nulos y que no tiene
valores repetidos. En base a ello, se dice que la entidad está perfectamente normalizada si
MODELADO DE DATOS Página 136
todos los demás atributos de esa entidad dependen funcionalmente de su atributo
identificador. Por ejemplo; consideremos la entidad:
CLIENTE (CodCliente, NombreCompleto, Dirección, Email)
En este caso, CodCliente → NombreCompleto, Dirección, Email; entonces el
determinante es CodCliente y la entidad así definida está Normalizada.
1.1.1 Ley distributiva de las dependencias funcionales
Esta regla establece que si un atributo A es determinante de un conjunto de dos o más
atributos; entonces A será determinante de cada uno de ellos; así:
Si: A → (B, C), Entonces: A → B ^ A → C
Veamos el ejemplo anterior:
Si CodCliente → (NombreCompleto, Dirección, Email); entonces
CodCliente → NombreCompleto ^ CodCliente → Dirección ^ CodCliente → Email
Nota importante
Lo contrario no se cumple, es decir; si (CodVendedor, TotalVentas) → Comisión
No es cierto que, CodVendedor → Comisión ^ TotalVentas → Comisión
1.1.2 Dependencias funcionales parciales
Una dependencia funcional se dice que es parcial, cuando el determinante está formado
por dos o más atributos y la dependencia funcional se presenta solamente en una parte de
dicho determinante. Veamos un ejemplo:
VENTA (NroFactura, CodProducto, NombreProducto, Precio, Stock, Cantidad)
En este caso el determinante está formado por un atributo compuesto; es decir por la
concatenación de los atributos: (NroFactura, CodProducto); pero las dependencias:
- (NroFactura, CodProducto) → NombreProducto; es Parcial porque el atributo
NombreProducto solamente depende del atributo CodProducto.
- (NroFactura, CodProducto) → Precio; también tiene dependencia funcional parcial.
- (NroFactura, CodProducto) → Stock; igualmente tiene dependencia funcional parcial.
- (NroFactura, CodProducto) → Cantidad; aquí si hay una dependencia funcional completa,
pues se requieren los valores de estos dos atributos para obtener el valor de la cantidad.
MODELADO DE DATOS Página 137
1.1.3 Dependencias funcionales multivaluadas
La dependencia funcional multivaluada se presenta cuando una entidad tiene dos o más
atributos independientes entre sí, pero que cada uno de ellos dependen funcionalmente de
un tercer atributo. Veamos el siguiente ejemplo:
Sea la entidad: POSTULANTE (CodPostulante, Nombre, WorksAnteriores, VacunasPuestas)
En este caso, los atributos: WorksAnteriores y VacunasPuestas son independientes
entre sí, pero los dos atributos dependen de CodPostulante ya que estos datos se refieren
al mismo postulante en cuestión.
Gráficamente, tenemos:
CodPostulante →→ WorksAnteriores
CodPostulante →→ VacunasPuestas
1.1.4 Claves Candidatas
Se dice que un atributo o clave es Candidata cuando no existen iguales filas en el
conjunto de atributos. Por ejemplo; Sea la Entidad:
CLIENTE (CodCliente, DNI, RUC, Nombre)
En este caso, la clave primaria es CodCliente, pero las propiedades de no nulo y valor
único también se presenta en el atributo DNI, de modo tal que este nuevo atributo también
sería una clave primaria; sin embargo, para el caso, sería Clave Candidata.
Importante
Toda entidad solo puede identificarse por una única clave primaria.
1.2 ¿Qué es la Normalización de datos?
La Normalización de datos se refiere a la aplicación de un conjunto de reglas bien definidas
sobre aquellas entidades que presentan anomalías en los atributos que las describen. El objetivo
principal apunta a la eliminación o disminución al máximo de la redundancia de datos y de datos
innecesarios. Una de las razones más importantes por las que se debe tener mucho cuidado en
el diseño de un modelado de datos es que siempre hay que proyectarnos al futuro de la
empresa, tomar en cuenta, por ejemplo, el nivel de crecimiento de la empresa, su capacidad de
expansión en nuevos mercados, con nuevos productos o con productos innovadores, la
implementación de nuevas políticas administrativas y de operaciones en el negocio; todo ello,
evidentemente afectará al modelado de datos e irremediablemente causará que en el futuro se
tenga que desarrollar cambios en el diseño de las bases de datos, por ello, es muy importante
MODELADO DE DATOS Página 138
que no nos enredemos con las entidades y sus relaciones pues de lo contrario todo nuestro
trabajo podría colapsar rápidamente por estas inconsistencias y redundancias no controladas.
1.3 Reglas de la Normalización de datos
Las reglas que se aplican para lograr una base de datos lo suficientemente consistente
como para afianzar su crecimiento y desarrollo sin dificultades son puestas en marcha en forma
ordenada, desde la primera forma normal, conocida como 1NF, luego de ella se aplicará la
segunda forma normal (2NF), se continua con la tercera forma normal (3NF). En este punto, se
puede decir que la base de datos ya se encuentra en un nivel medianamente sólida en su
definición; sin embargo, todavía hay algunos problemas adicionales que de no ser atendidas
desde la definición de la base de datos, podría producir errores e inconsistencias posteriores;
por ello, hay más reglas, como por ejemplo la normalización de Boyce y Codd, conocida como
forma normal extendida (BCNF), luego otras inconsistencias podrían solucionarse con la
aplicación de las reglas de la cuarta forma normal (4NF), y finalmente podemos llegar hasta la
quinta forma normal (5NF).
1.3.1 Entidad No Normalizada
Analicemos la Entidad PEDIDO cuyo detalle de atributos se
muestra en la siguiente figura.
PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección, Artículo, Descripción,
Precio, Stock, Cantidad)
MODELADO DE DATOS Página 139
En este caso observamos inconsistencia de datos para ingresar nuevas filas; pues
hay redundancia en los casos donde el pedido tiene muchos artículos.
1.3.2 Normalización en Primera Forma Normal - 1NF
Se dice que una Entidad o tabla de datos se encuentra normalizada en 1NF cuando no
existen filas de datos con grupos de atributos repetitivos.
Analizando el ejemplo anterior; se detecta que hay un grupo de datos repetitivos
conformado por los atributos: (Artículo, Descripción, Precio, Stock, Cantidad). La regla nos
indica que en estos casos deberíamos separar en dos entidades, tal como se indica en la
siguiente gráfica:
PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Descripción, Precio, Stock, Cantidad)
1.3.3 Normalización en Segunda Forma Normal - 2NF
La aplicación de la regla de la Segunda Forma Normal se desarrolla en aquellas entidades
que en primer lugar ya se encuentran normalizadas en 1NF y que ahora se definen con
atributos concatenados cuya inconsistencia que se debe resolver se encuentra en que las
dependencias funcionales esperadas de los atributos del cuerpo de la entidad, solo tiene
dependencia parcial de la clave concatenada. En estos casos, la regla establece que se debe
separar las entidades, tal como se muestra en el siguiente ejemplo:
PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Precio, Cantidad)
ARTICULO (Artículo, Descripción, Precio, Stock)
Gráficamente, tenemos:
MODELADO DE DATOS Página 140
1.3.4 Normalización en Tercera Forma Normal - 3NF
La regla de normalización en 3NF se aplica a las entidades que previamente se
encuentran en 2NF y establece que todos los atributos del cuerpo de la entidad deben
depender funcionalmente de su atributo de clave primaria, de lo contrario es mejor crear
nuevas entidades. Asimismo, la regla también establece que los atributos que se pueden
calcular pueden obviarse de la entidad. En el ejemplo; observamos que la entidad PEDIDO
tiene inconsistencia en cuanto al atributo DNICliente el cual actúa como atributo
identificador y los demás atributos (Nombre, Dirección) actúan con dependencia funcional.
En este caso, las entidades quedarían así:
PEDIDO (NroPedido, Fecha, DNICliente)
CLIENTE (DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Precio, Cantidad)
ARTICULO (Artículo, Descripción, Precio, Stock)
Gráficamente, tenemos:
En este punto, podremos decir que el proceso de normalización de la base de datos ha
concluido ya que en la mayoría de los casos las inconsistencias serían mínimas; sin embargo,
todavía podría presentarse otras anomalías que valen la pena ser analizadas, veamos:
1.3.5 Normalización en la Forma Normal de Boyce y Codd – BCNF
La regla de la normalización en BCNF se aplica a las entidades que previamente se
encuentran en 3NF y que tienen atributos determinantes que a su vez son claves candidatas.
El ejemplo que venimos analizando no tiene estas particularidades por ello decimos que se
encuentra normalizada en BCNF; Sin embargo, el ejemplo que se analiza más adelante si ha
sido propuesto con las características de esta mencionada forma normal.
MODELADO DE DATOS Página 141
1.3.6 Normalización en Cuarta Forma Normal - 4NF
La regla de la normalización en 4NF se aplica a las entidades que se encuentran
normalizadas en su forma BCNF y que no tienen dependencia de valores múltiples. Este tipo
de normalización facilita la relación entre las entidades con relacionamiento de muchos a
muchos. Este caso, se analiza con mayor detalle en el ejemplo que se presenta más adelante.
1.3.7 Normalización en Quinta Forma Normal - 5NF
Esta regla se aplica a las entidades que ya se encuentran en la forma 4NF. Se conocen
como la forma normal de proyección unión; pues las únicas dependencias que existe son las
dependencias de unión de la entidad con sus proyecciones cuya relación se lleva a cabo a
través de su clave primaria o de alguna de sus claves candidatas.
En el presente ejemplo no hay necesidad de evaluar estas proyecciones, por ello,
consideramos que el modelo descrito ya se encuentra en 5NF. Más adelante se presentará
este caso con mayor detalle.
MODELADO DE DATOS Página 142
LABORATORIO Nº 6
CASO DE NORMALIZACIÓN DE DATOS
La empresa Palermo S.A.C. Rent a Car, alquila autos y camionetas para ser utilizados por
sus clientes en el Perú; para ello, su departamento de Sistemas y Comunicaciones ha
encargado la elaboración del modelado de datos debidamente normalizado que pueda
permitir el procesamiento de la siguiente Hoja de Alquiler de Vehículos.
Consideraciones de importancia para comprender los detalles de la figura anterior
- El Tipo de Cliente es: N. Cliente Natural, J. Cliente Jurídico
- Un Cliente Natural; es una persona que no requiere el uso del Registro único del
contribuyente; es decir Número de RUC.
- Un cliente Jurídico; es básicamente una empresa. Aquí el Nº de RUC es fundamental e
indispensable.
- El tipo de documento (TipoDoc); puede ser uno de los siguientes:
o Para Clientes naturales: DNI o Pasaporte
o Para Clientes jurídicos: RUC
- El tipo de contrato puede ser: Contrato Personal, o contrato corporativo (para empresas)
MODELADO DE DATOS Página 143
- El Rubro de la empresa se refiere al giro de negocios; puede ser: 1. Textil, 2. Construcción,
3. Imprenta, 4. Metalurgia, 5. Educación, …. Etc.
- El tipo de vehículo puede ser: 1. Auto deportivo, 2. Auto convencional, 3. Camioneta 4 x 4,
4. Camioneta 4x2; … Etc.
- El código del vehículo es en realidad su número de placa.
- Los Accesorios del vehículo se refiere a aquellos que se agregan al vehículo en forma
adicional; como, por ejemplo: Palanca de seguridad contra robos para timón, Botiquín de
primeros auxilios, Extinguidor; etc.
- La duración en días será calculada en número de días a partir de la fecha de inicio hasta la
fecha de término del contrato de alquiler.
- El precio por día es el precio diario de alquiler del vehículo.
- SubParcial = Duración x PrecioDía
- El Número de días de reserva se calcula entre la diferencia de días de la fecha del contrato
y la fecha de inicio del alquiler. Se calcula en cantidad de días, para asignar un descuento
por reserva oportuna. Las reservas menores a 2 meses no tienen descuento, si el tiempo
está entre 2 y 4 meses, el descuento es de 10% del SubParcial, y si el tiempo es mayor a 4
meses, el descuento es de 15%.
- Importe = SubParcial – Descuento
- Un Garante puede avalar a más de un cliente, pero un cliente sólo puede presentar un
garante.
- Los clientes naturales solo pueden alquilar un vehículo, siempre y cuando su edad sea mayor
de 25 años, y cuente con licencia de conducir vigente.
- Sólo las empresas pueden hacer alquileres corporativos de varios vehículos dentro de un
mismo contrato.
Solución al caso planteado
La solución al caso planteado inicia con la elaboración de la entidad no Normalizada,
veamos:
1.4 Entidad no normalizada
Esta entidad está conformada por la relación de todos y cada uno de los atributos
necesarios para replicar el documento Hoja de Alquiler de vehículos.
MODELADO DE DATOS Página 144
1.5 Normalización en 1NF
Separando en una nueva entidad a los grupos de datos
repetidos, tenemos:
1.6 Normalización en 2NF
Separando en nuevas entidades a los datos que tienen dependencia funcional parcial en
entidades con atributos identificadores concatenados, tenemos:
MODELADO DE DATOS Página 145
1.7 Normalización en 3NF
Tomando en cuenta los atributos de las entidades normalizadas en 2NF, verificaremos
aquellos atributos que tienen dependencia funcional transitiva entre atributos no clave, y
otros atributos que podríamos eliminar si el proceso los puede calcular con cierta facilidad,
veamos:
MODELADO DE DATOS Página 146
1. Datos para los Clientes
CodCliente → (TipoCliente, NameCliente, DirCliente, TipoDoc, NroDoc, TfFijo, Email, Facebook,
Instagram, Twitter, Otro)
CLIENTE (CodCliente, TipoCliente, NameCliente, DirCliente, TipoDoc, NroDoc, TfFijo, Email,
Facebook, Instagram, Twitter, Otro)
2. Datos para los Tipos de Cliente
TipoCliente → (DescripcionTC)
TIPO_CLIENTE (TipoCliente, DescripcionTC)
3. Datos para Los Representantes Legales
DniRepLegal → (NameRepLegal, CelRepLegal, EmailRepLegal)
REPRESENTANTE (DniRepLegal, NameRepLegal, CelRepLegal, EmailRepLegal)
4. Datos para el Cliente Jurídico
CodCliente → (DniRepLegal)
CLIENTE_JURIDICO (CodCliente, DniRepLegal)
5. Datos para el Cliente Natural
CodCliente → (NroLicencia, VigLicencia, FechaNacim, LugarNacim, CodRegion, NameGarante,
TrabajoCliente)
CLIENTE_NATURAL (CodCliente, NroLicencia, VigLicencia, FechaNacim, LugarNacim,
CodRegion, DniGarante, TrabajoCliente)
6. Datos para las Regiones
CodRegion → (RegionProced)
REGION (CodRegion, RegionProced)
7. Datos para Los Garantes
DniGarante → (NameGarante)
GARANTE (DniGarante, NameGarante)
8. Datos del Trabajo del Cliente Natural
TrabajoCliente → (CodRubro, DirTrabCliente, EmailTrabCli, TfFijoTrabCli)
TRABAJO_CLIENTE (TrabajoCliente, CodRubro, DirTrabCliente, EmailTrabCli, TfFijoTrabCli))
9. Datos del Rubro de la Empresa donde trabaja el cliente natural
CodRubro → (DescripRubro)
RUBRO (CodRubro, DescripRubro)
10. Datos del Operador
CodOperador → NameOperador
MODELADO DE DATOS Página 147
OPERADOR (CodOperador, NameOperador)
11. Datos del Tipo de Vehículo
TipoVehiculo → DescripTipoVeh
TIPO_VEHICULO (TipoVehiculo, DescripTipoVeh)
12. Datos de la Garantía
(DniGarante, CodCliente) → CodVehiculo
GARANTIA (DniGarante, CodCliente, CodVehiculo)
Modelo de datos normalizado en 3NF
1.8 Normalización en BCNF
Observemos la entidad GARANTIA; podremos concluir lo siguiente:
- Un Garante puede garantizar a muchos Clientes; entonces: DniGarante → → CodCliente
- Un Garante puede ser garante de muchos Vehículos; luego: DniGarante →→ CodVehículo
- Pero DniGarante; NO puede ser clave primaria; ¡¡ya que se encuentra en una clave
Compuesta!!
- Por lo anterior, tenemos dos claves candidatas:
(DniGarante, CodCliente) → CodVehículo
MODELADO DE DATOS Página 148
(DniGarante, CodVehículo) → CodCliente
Además;
DniGarante →→ CodCliente ^ CodCliente → CodVehiculo
Entonces: CodCliente es un determinante.
- Se requiere conocer cuáles son los clientes de un garante y cuáles son los vehículos que ha
garantizado.
- Tomaremos la clave candidata: (DniGarante, CodCliente); como clave primaria.
Veamos los cambios a la tabla GARANTIA; al aplicar BCNF:
Sub modelo de datos para la normalización de BCNF
MODELADO DE DATOS Página 149
Modelo de datos normalizado en BCNF
1.9 Normalización en 4NF
El modelo de datos se encuentra en 2NF porque no existen dependencias funcionales
parciales. También se encuentra en 3NF porque no existe dependencias funcionales
transitivas; y se encuentra en BCNF ya que no existe determinantes que no son claves
primarias. Sin embargo, este modelo de datos no se encuentra en 4NF debido a que hay una
dependencia funcional multivaluada en la entidad DETALLE_ALQUILER, de la siguiente
manera: (NroHoja, CodVehículo) → → AccesoriosVeh.
El caso muestra que un Vehículo alquilado puede contener una lista de accesorios
adicionales solicitados por el cliente. Por ello, la entidad DETALLE_ALQUILER ha sufrido el
cambio en los atributos de la clave compuesta; así: (NroHoja, CodVehículo, AccesoriosVeh),
siendo los valores de AccesoriosVeh, un valor autogenerado por el mismo sistema de
administración de la base de datos. Lo anterior nos permitirá efectuar una relación de
muchos-a-muchos con la entidad ACCESORIO.
MODELADO DE DATOS Página 150
Recordemos que cuando se desarrolla una relación de muchos-a-muchos entre dos
entidades; su representación física obliga a crear una entidad intermedia para facilitar este
relacionamiento, tal como se indica a continuación:
Sub modelo de datos para la 4NF
Modelo de datos normalizado en 4NF
MODELADO DE DATOS Página 151
1.10 Normalización en 5NF
La Proyección Unión que se observa se encuentra en la entidad Operador; pero como
un Operador puede gestionar varias Hojas de Alquiler; entonces haremos la extensión a
través de una Operación, veamos:
Sub modelo de datos para la 5NF
Modelo de datos normalizado en 5NF
MODELADO DE DATOS Página 152
Actividad Nº 6
Elabore el modelado de datos normalizado, paso a paso, desde la entidad (Tabla) no
normalizada, hasta la 3NF, en el siguiente caso:
Consideraciones adicionales
- El Pedido contiene varias especificaciones.
- Los productos que se fabrican se encuentran en un mismo Lote de fabricación especificado
por un número. Un mismo Lote puede estar en muchas órdenes de producción.
- Cada orden de producción solamente contiene un Producto.
- En Materiales requeridos: SubTotal = Precio x Cantidad
- En Actividades: SubTotal = HorasTrabajadas x ValorHora
- En Gastos Indirectos: SubTotal = Cantidad x CostoUnitario;
- Los Items; de Gastos Indirectos, son: Materiales indirectos, Labor indirecta, Otros gastos
(por ejemplo: Renta, depreciación, Luz, Reparación, Seguros, Combustibles, Aceites, etc.)
MODELADO DE DATOS Página 153
Autoevaluación 6
1. Es un atributo de clave que puede ser clave primaria, en un momento dato:
A. Clave Normalizada
B. Clave Secundaria
C. Clave Candidata
D. Clave Externa
E. N. A.
2. Establezca la verdad o falsedad en la siguiente afirmación: “Se puede registrar un
espacio en blanco en una entidad declarada como nulo”
A. Verdadero F. Falso C. Ni verdadero, ni falso
3. Las dependencias funcionales transitivas, son controladas en:
A. 4NF B. 2NF C. 1NF D. 3 NF E. BCNF
4. Se define siempre en una entidad destino, después de una relación con otra entidad:
A. Clave Foránea
B. Clave Compuesta
C. Clave Candidata
D. Clave Secundaria
E. N. A.
5. El atributo que permite identificar a otro atributo de manera única se denomina:
A. Secundario
B. Normalizado
C. Nulo
D. Determinante
E. Consecuente
MODELADO DE DATOS Página 154
Sesión 7: Lenguaje SQL
1. ¿Qué es SQL?
SQL, es un lenguaje estructurado de consulta de datos (Structure Query Languaje). SQL
viene inmerso en casi todos los sistemas de administración de base de datos. Las
instrucciones del lenguaje SQL se dividen en tres partes, las cuales son:
a. Data Definition Languaje – DDL
Lo que quiere decir; Lenguaje de definición de datos. Es el sub lenguaje que provee a
SQL de las instrucciones requeridas para la creación, modificación y eliminación de objetos
de una base de datos.
b. Data Manipulation Languaje - DML
Lo que quiere decir; Lenguaje de manipulación de datos. En este caso tenemos el
conjunto de instrucciones para acceder a los datos a manera de consulta, además podremos
adicionar e insertar nuevos datos, eliminarlos, modificarlos, etc.
c. Data Control Languaje – DCL
Lo que quiere decir, lenguaje de Control de datos. Este sub lenguaje contiene las
sentencias para desarrollar operaciones de control de los objetos de la base de datos; por
ejemplo, creación de usuarios, permisos de acceso; entre otros aspectos.
1.1 ¿Qué es SQL Server?
SQL Server es un sistema de gestión de base de datos (SGBD), también conocido como
DBMS-Data Base Management System. Esta herramienta pertenece a la Suit de base de
datos de Microsoft. El lenguaje que se utiliza para desarrollar las operaciones de una base
de datos en SQL Server se llama Transact SQL; sin embargo, SQL Server también nos brinda
una plataforma para la gestión de los objetos y datos, como ya se verá más adelante. En el
mercado informático actual, existe otras herramientas para desarrollar estas mismas
operaciones con igual o mejores capacidades como, por ejemplo; Oracle, MySQL, Sybase,
Access; entre otras.
SQL Server desarrolla la gestión de los objetos de la base de datos en el marco de las
siguientes categorías de operaciones:
a) Gestión de los datos
En esta categoría SQL Server permite las operaciones de Creación, Eliminación y
Actualización de los objetos tales como Tablas y sus tipos de datos, dominios,
valores por defecto, Vistas, Funciones; entre otros objetos.
MODELADO DE DATOS Página 155
b) Gestión de las Consultas de datos
Las consultas de datos se desarrollan por operaciones que facilitan el acceso a los
datos, y también las Vistas de datos y Procedimientos Almacenados.
c) Gestión de la Integridad de datos
En esta categoría se encuentran las operaciones vinculadas al manejo de
transacciones que faciliten la implementación adecuada de las bases de datos,
teniendo en cuenta los diferentes criterios que resguarden los datos y sus
relaciones; estas operaciones se implementan a través de Triggers.
1.2 Creación de una Base de datos
Como se ha indicado líneas arriba; SQL gestiona la creación y mantenimiento de los
objetos de una base de datos a través de sus operaciones DDL, así también, gestiona los
contenidos de las tablas de datos a través de las diversas operaciones de acceso a los datos,
tales como, las consultas, vistas de datos, procedimientos almacenados, funciones, índices;
etc. Con las operaciones DML, y finalmente, gestiona los permisos y derechos de los diversos
usuarios de la base de datos con sus operaciones DCL. En este punto trataremos el tema de
la creación y modificación de una base de datos.
Sintaxis para la creación de una base de datos con Transact SQL
CREATE DATABASE <<NombreBDatos>>
[ ON
[PRIMARY] [ <EspecificaciónArchivo> [, n] ]
[LOG ON <EspecificaciónArchivo> [,n] ]
]
[ COLLATE intercalación ]
[; ]
<EspecificaciónArchivo>
A continuación, se muestra el detalle de la especificación de Archivo:
(NAME = nombreLógico,
FILENAME = ‘ruta+NombreArchivo’
[, SIZE = tamaño [ KB | MB | GB | TB ] ]
[, MAXSIZE = { tamañoMáximo [ KB | MB | GB | TB ] | UNLIMITED } ]
[, FILEGROWTH = pasoIncremento [ KB | MB | GB | TB | % ] ]
) [, n]
MODELADO DE DATOS Página 156
PRIMARY
Cuando se omite, el primer archivo de datos creado es el Primario con la extensión mdf.
NAME
Es el nombre lógico del archivo.
FILENAME
Para indicar el nombre y ubicación física del archivo.
SIZE
Por defecto, el tamaño es 8 MB.
MAXSIZE
Por omisión el archivo crecerá hasta la saturación del disco, con un máximo de 16 TB para
un archivo de datos.
FILEGROWTH
Indica el valor del factor de crecimiento del archivo. Por defecto, su valor es de 64 MB.
Ejemplo:
Crear la base de datos “VentasDB” cuyos archivos mdf y ldf sean definidos en la ruta:
“C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA”, su tamaño
base del archivo mdf debe ser 8 MB hasta un máximo de 32 MB con un nivel de crecimiento de
2 MB. El tamaño del archivo ldf debe ser de 4 MB a un máximo de 16 MB y un crecimiento del
20%.
Solución:
MODELADO DE DATOS Página 157
Ejemplo:
Crear la base de datos VentasNuevas, con todos los valores por defecto.
Solución:
use master go create database VentasNuevas go
1.3 ¿Qué es una Tabla de datos?
Las tablas de datos, conocidas también como tablas de base; son objetos de las bases de
datos donde se almacenan físicamente los datos. Las Tablas de base tienen básicamente dos
partes:
1.3.1 Estructura de datos
Una Estructura de datos está referida a todas las propiedades de la tabla de datos; aquí se
identifica el nombre de las columnas o atributos, así como el tipo de datos, tamaño y otras
funcionalidades de estas columnas o atributos de la tabla, tales como, por ejemplo; la definición
de atributos claves, valores por defecto, dominios, valores nulos, etc.
1.3.2 Contenido de datos
Es el área dónde se ingresan los datos; también se le conoce como Filas de datos; aquí se
permite el ingreso de los datos tomando en cuenta las restricciones y criterios de integridad
propiamente definido.
El siguiente esquema muestra una tabla de base, veamos:
Tabla de datos
MODELADO DE DATOS Página 158
1.4 Creación de tablas de base
- Sintaxis básica:
CREATE TABLE <Nombre de Tabla>
(Columna-1 TipoDato(Tamaño) [NOT] NULL,
Columna-2 TipoDato(Tamaño) [NOT] NULL,
. . . .
Columna-n TipoDato(Tamaño) [NOT] NULL,
PRIMARY KEY (Columna-x[, Columna-y [, . . .] ] ) );
- Descripción de parámetros
<Nombre de Tabla>
El nombre de la tabla se refiere al nombre físico almacenado, por tanto, se recomienda
que sea una palabra escrita sin espacios intermedios, en mayúscula y que no inicie con
número ni contenga caracteres especiales ni extraños.
Columna-n
Las columnas son los nombres de los atributos de la tabla. Se recomienda utilizar letras
en minúsculas combinadas con mayúsculas en caso de palabras compuestas.
Tipo de Dato
El tipo de dato depende del formato que maneja el Sistema de Gestión de Base de Datos
(DBMS) con el que estamos trabajando. En nuestro caso, utilizamos SQL Server. Se
recomienda que usted profundice el tema investigando los tipos de datos que provee SQL
Server, de la versión que se encuentre trabajando.
Tamaño
El tamaño es un número que delimita el ancho de la columna para el dato. En algunos
tipos de datos, este tamaño es opcional, como es el caso de los datos de tipo DATE y TIME,
así también para los datos de tipo INTEGER, entre otros.
[NOT] NULL
Esta cláusula se utiliza para aceptar o no algunos datos con valor nulo.
PRIMARY KEY
Permite definir cuál o cuáles serán los atributos que se usarán como clave primaria.
Recordemos que, de acuerdo con la integridad de la Entidad o tabla, estos datos no se deben
definir con valores nulos.
MODELADO DE DATOS Página 159
Ejemplo: Sobre la base de datos VentasDB, crear la tabla CLIENTE indicada en el modelo:
Hay otras formas para la creación de las claves primarias, veamos:
Ejemplo: Crear la Tabla EMPLEADO (IdEmpleado, Nombre, FechaIngreso, SueldoBase)
Ejemplo: Crear la Tabla PRODUCTO (IdProducto, Descripcion, UnidadMedida, Precio, Stock)
Ahora crearemos tablas con claves foráneas, veamos:
MODELADO DE DATOS Página 160
Ejemplo: Crear la tabla: VENTA (IdVenta, Fecha, IdEmpleado, IdCliente)
En este caso existe una relación No Identificatoria entre la tabla EMPLEADO y la tabla
VENTA, donde el atributo IdEmpleado es una clave foránea; así también, hay una relación entre
la tabla CLIENTE y la tabla VENTA donde el atributo IdCliente es una clave foránea, veamos:
Ejemplo: Crear la tabla CATEGORIA (IdCategoria, NameCategoria)
Se observa que hay una relación No Identificatoria entre la tabla CATEGORIA y la tabla
PRODUCTO, donde el atributo IdCategoria es una clave foránea, veamos:
Finalmente, crearemos la tabla DETALLE_VENTA(IdVenta, IdProducto, Cantidad, Precio)
Esta tabla tiene una clave primaria compuesta, y dos claves foráneas con relaciones
identificatorias entre las tablas VENTA y PRODUCTO; veamos:
MODELADO DE DATOS Página 161
El diagrama de la base de datos desde la plataforma de SQL Server, es:
1.5 Alteraciones de Tablas de base
Podremos alterar la definición de una tabla de base, con la instrucción ALTER TABLE, la cual
se describe enseguida:
ALTER TABLE <NombreTabla>
ADD
Columna TipoDato(Tamaño) [NOT] NULL;
Ejemplo: Agreguemos a la tabla CLIENTE, la columna Descuento de tipo smallmoney y que
aceptará datos nulos.
Solución:
MODELADO DE DATOS Página 162
Ejemplo: Agreguemos a la tabla CLIENTE, la columna Credito de tipo smallmoney y que no
aceptará datos nulos.
Solución:
Ahora, después de actualizar la base de datos VentasDB; echaremos un vistazo a la
estructura de la tabla CLIENTE, desde el explorador de objetos de la plataforma de SQL Server:
MODELADO DE DATOS Página 163
2. Consulta de datos
La consulta de datos se desarrolla a través de una operación SELECT que permite entre otras
propiedades el acceso a los datos por criterios preestablecidos. Select es una sentencia que
pertenece al área DML de SQL.
Sintaxis básica
SELECT [DISTINCT]
[NombreTabla.]Columna-1 [, [NombreTabla.]Columna-2, . . ]
FROM NombreTabla [,NombreTabla, . . ]
[WHERE <Expresión Condicional> ]
[GROUP BY Columna(s)]
[HAVING Condición]
[ORDER BY Columna(s) ] ;
Descripción de cláusulas de la sentencia
SELECT
La cláusula SELECT se utiliza para consultar todas o parte de un conjunto de columnas de
datos y de una o más tablas de base.
SELECT DISTINCT
Esta variedad muestra los datos de las columnas que se requieran, pero solamente se hace
referencia a las filas que tienen valor distinto.
NombreTabla.Columna
Permite hacer la referencia a una columna determinada. En algunos casos, cuando la
consulta requiera el acceso a las columnas de más de una tabla de base, se recomienda utilizar
como prefijo el valor de NombreTabla, seguido por el nombre de la columna respectiva. El valor
de NombreTabla puede referirse a un valor Alias de la tabla.
FROM
Esta cláusula es obligatoria y permite indicar cuál es la tabla o tablas requeridas para la
consulta.
WHERE <Expresión Condicional>
MODELADO DE DATOS Página 164
Aquí escribiremos la expresión condicional para establecer el “filtro” de selección del
conjunto de datos requerido para la consulta.
GROUP BY
Los datos consultados se pueden agrupar por criterios establecidos en las columnas
indicadas con HAVING. Los detalles de este caso, se verán más adelante.
ORDER BY
La información de la consulta aparecerá en forma ordenada ascendente o descendente por
la columna o conjunto de columnas indicadas.
2.1 Aplicaciones de las operaciones SELECT
Con la finalidad de poder elaborar un conjunto de operaciones Select que den solución a
diversos casos planteados, se utilizará una base de datos llamada NorthWind, la que usted
puede descargar con suma facilidad y en forma gratuita de internet. Las ventajas de esta base
de datos es que ya tiene datos incorporados para facilitar las operaciones de consulta.
Diagrama de una parte de la base de datos NorthWind
MODELADO DE DATOS Página 165
Ejemplos de Aplicación sobre la base de datos NorthWind
1. Mostrar algunas columnas de todos los clientes (Customers).
2. Mostrar la lista de apellidos de los empleados (Employees)
3. Mostrar algunas columnas de los Productos cuyo Stock esté entre 30 y 38 unidades.
4. Mostrar el Id de la Orden y la fecha; de las que se procesaron el mes actual del año 1998.
- Consultas con más de una tabla de datos
1. Lista de Empleados que ordenaron productos en el mes de enero o febrero del año 1997.
MODELADO DE DATOS Página 166
2. Listar los productos que no pertenecen a la categoria Beverages o Condiments
3. Listar los productos que pertenecen a las categorias Beverages o Condiments o Confections.
4. Mostrar los nombres de los productos que son de la categoría 'Condiments'.
- Uso de funciones en las consultas de datos
1. Obtener la lista de Categorías y la cantidad de Productos que contiene.
MODELADO DE DATOS Página 167
2. Mostrar las órdenes efectuadas y su resumen de importe procesado.
3. Mostrar el Nombre de todas las categorías y por cada una de ellas, el Promedio del
precio de los productos que contiene.
4. Mostrar la lista de los productos que pertenecen a la orden ‘10248’
MODELADO DE DATOS Página 168
LABORATORIO Nº 07
Script de una base de datos y Consultas
1. Creación de la base de datos BDContratos
La compañía RapidTaxi; ha elaborado los contratos de concesión entre los propietarios de
vehículos que son utilizados para el servicio de taxis en la ciudad de Trujillo. Se requiere la
instalación de una base de datos que registre estos contratos de la empresa de taxis, con los
propietarios de vehículos que prestarán el servicio.
1.1 Creación de la base de datos
1.2 Creación de la tabla PROPIETARIO
1.3 Creación de la tabla VEHICULO
MODELADO DE DATOS Página 169
1.4 Creación de la tabla CONTRATO
1.5 Diagrama de la base de datos
MODELADO DE DATOS Página 170
2. Ingreso de datos
MODELADO DE DATOS Página 171
3. Operaciones de consulta de datos
3.1 Recuperación simple de datos
Mostrar el número de DNI de todos los Propietarios con contrato.
Se puede apreciar que hay DNI de propietarios que están
repetidos, y eso se debe a que hay propietarios que tienen contrato
con más de un vehículo de su propiedad.
MODELADO DE DATOS Página 172
El caso anterior, se resolverá con el uso de la cláusula distinct; que permitirá mostrar
solamente los datos de valores distintos por cada fila, veamos:
Como puede apreciarse, esta vez solamente se muestran 10 filas de datos.
3.2 Consulta de datos calculados
Mostrar el Nº de placa y la carga máxima en kilos de los vehículos; teniendo en cuenta que
dichas cargas máximas se encuentran almacenados en toneladas.
3.3 Consulta Calificada
Obtener todos los datos de los propietarios; excepto de aquellos que son de sexo femenino.
MODELADO DE DATOS Página 173
3.4 Consulta con ordenamiento de datos y operador LIKE
Mostrar el nombre, dirección y correo de los propietarios cuyo email sea del operador
gmail.com. Mostrar la lista ordenada por nombre.
3.5 Cuenta de datos con selección de registros
Obtener la cantidad de propietarios que son de sexo femenino.
3.6 Consulta de datos con group by
Obtener el nombre completo de los propietarios y la cantidad de vehículos alquilados.
3.7 Consulta de datos con sub filtros
Mostrar el nombre de los propietarios y la cantidad de vehículos alquilados, pero solamente
de aquellos que tienen más de un vehículo alquilado.
MODELADO DE DATOS Página 174
3.8 Recuperación de datos con Like
Mostrar los datos de los vehículos, excepto de aquellos de la marca ‘TOYOTA’ y ‘KIA’.
3.9 Operaciones con subconsultas
Mostrar el nombre y Dirección de los propietarios cuyo contrato finaliza el año 2020.
3.10 Consultas con el uso de consultas anidadas
Mostrar el Nº de Placa y Nombre del propietario de los vehículos cuya CargaMax sea mayor
1.3 toneladas.
MODELADO DE DATOS Página 175
Actividad Nº 7
1. Elabore los Scripts en lenguaje Transact SQL de SQL Server, para crear la base de datos
BDCitasProgramadas del sistema de control de citas de pacientes de un hospital cuyo
diagrama se muestra a continuación:
OBSERVACIONES
- Usted podrá definir el tipo de datos y tamaño que más se ajuste al modelo.
- En una Hoja de Cita, hay una relación de Pacientes Citados.
2. Desarrolle los scripts en código SQL para resolver los siguientes casos sobre la base de datos
NorthWind:
a) Listar el nombre de las distintas Compañías de los clientes que efectuaron órdenes en
el año 1998.
b) Mostrar la cantidad de órdenes emitidas el mes de mayo del año 1998.
c) Obtener el IdCliente, Nombre de Compañía y Dirección de los clientes que no
compraron nada en el año 1998.
d) Consultar el número de Productos cuyo Número de Unidades en Stock sea mayor a
110.
MODELADO DE DATOS Página 176
Autoevaluación 7
1. Diga si es verdadera o falsa la siguiente afirmación: “Siempre se debe utilizar la función
AVG con Group by, dentro de la sentencia Select”
A. Verdadero B. Falso C. Ni verdadero, ni falso
2. Marque la respuesta correcta, en:
A. Una tabla de datos bien definida acepta filas duplicadas
B. Una Consulta de datos acepta filas duplicadas
C. Una relación múltiple acepta filas duplicadas
D. Una cláusula Where acepta filas duplicadas
E. N.A.
3. Por defecto, el tamaño de una base de datos creada en SQL Server, es:
A. 4 MB
B. 4 GB
C. 4 TB
D. Ilimitada
E. N.A.
4. Diga cuál es la cláusula para eliminar las filas duplicadas
A. unduplicate
B. unic
C. distinct
D. duplicate
E. N.A.
5. En una base de datos el nivel de crecimiento del archivo lógico puede definirse en:
A. Porcentaje
B. Binario
C. Float
D. Caracteres
E. N.A.
MODELADO DE DATOS Página 177
Sesión 8: Integridad de datos
1. ¿Qué es la Integridad de datos?
En el mundo real de nuestro contexto, existen ciertas reglas que deben cumplir sus
elementos; por ejemplo, una persona sólo puede tener un único número de DNI y una única
dirección oficial, aquella que figura en el padrón, asimismo, existe la restricción que una persona
no puede pasar directamente de soltera a viuda, ni estar casada a la edad de 4 años.
Así, al diseñar una Base de datos necesitamos reflejar adecuadamente esta realidad, la cual
se debe expresar en forma de reglas de negocio y que a partir de ahora conoceremos como las
Restricciones de Integridad de datos. La semántica de los datos se refiere a todo lo que
conocemos acerca de los datos, esta semántica se encontraba en un principio en la mente del
usuario, para comprobar mentalmente si los datos cumplían o no las reglas de negocios, pero
en el transcurso del tiempo esta semántica pudo implementarse como lógica de los programas
de aplicación. En la actualidad, esta semántica puede controlarse desde la base de datos.
1.1 ¿Cuáles son las clases de Restricción de Integridad de datos?
A continuación, se muestra la jerarquía de clasificación de las Restricciones de Integridad:
A continuación, se detalla las clases de Restricciones de integridad de datos, veamos:
1.1.1 Restricciones Inherentes
Las Restricciones Inherentes no necesitan ser definidas por el usuario, ya que se encuentran
en el propio modelo y se activan en el momento de la definición cuando se produce un intento
de violación; por ejemplo, si establecemos una Relación Identificatoria entre dos entidades,
entonces el atributo identificador de la entidad Padre se heredará como atributo identificador
MODELADO DE DATOS Página 178
en la entidad Hijo, con la Restricción Inherente que este atributo no podrá eliminarse de la
entidad hijo. Asimismo, si definimos un atributo como identificador primario, en esta situación
automáticamente se asume que dicho valor es No Nulo, pues sabemos que los atributos de tipo:
Identificadores Primarios deber ser no nulos; por la Regla de Integridad de la Entidad.
1.1.2 Restricciones Programadas
Las Restricciones Programadas son impuestas por el contexto del problema de acuerdo a
las Reglas de Negocios establecida y son definidas é implementadas por los diseñadores de la
base de datos. Entre las restricciones programadas tenemos:
- Restricciones Programadas en forma externa a la Base de Datos
Estas Restricciones se especifican en los programas de aplicación y ya que no están
almacenadas en la base de datos se corre el riesgo de que sean violadas por operaciones de
actualización de datos en las que no se haya programado la Restricción.
Analicemos el siguiente ejemplo; supongamos que estamos diseñando una base de datos
para el control de libros de una Biblioteca; pues bien, cuando un usuario lector devuelve un libro,
el estado de dicho libro deberá pasar de ‘prestado’ a ‘disponible’; de manera que durante el
proceso de actualización de préstamos se efectuará el cambio indicado con la ejecución del
programa de control respectivo.
- Restricciones Programadas al interior de la Base de Datos
Estas Restricciones de Integridad se especifican directamente en la misma Base de Datos,
por lo tanto; no pueden ser violadas por ninguna Actualización de datos. Entre las Restricciones
programadas dentro de la base de datos tenemos:
a) Restricciones Declarativas
En estas Restricciones no se especifica la Acción y la Condición y si se define, es de forma
declarativa. El no cumplimiento de la condición lleva a aplicar la acción en forma inmediata. Las
restricciones declarativas, son de los siguientes tipos:
a.1 De Dominios de Atributos
En este caso no es necesario especificar la Acción, la cuál es siempre el rechazo, sin
embargo, es obligatorio declarar la Condición mediante una proposición lógica.
MODELADO DE DATOS Página 179
El dominio de un atributo se refiere al conjunto de posibles valores que puede tener dicho
atributo; por ejemplo, el atributo SEXO solamente puede tomar el valor F (femenino) o M
(masculino); no existe otra posibilidad.
- Cláusula CHECK
Esta cláusula es utilizada para restringir los valores de un atributo.
Sintaxis
ALTER TABLE <<NombreTabla>>
ADD
CONSTRAINT <<NombreConstraint>>
CHECK <<Condición>>;
Ejemplo
Crear la tabla siguiente: VENDEDOR(IdVendedor, Nombre, Area, SueldoBase, Comision)
Luego verificar que el atributo Area pertenezca a uno de los siguientes valores: 'Ventas',
'Admisión', 'PostGrado'.
El Sueldo Base debe ser mayor o igual al sueldo mínimo; es decir, a 970.00.
La Comisión debe estar entre 0 y 15%.
Otra forma de programar lo mismo sería así:
MODELADO DE DATOS Página 180
a.2 De valores por defecto
Las restricciones de valor por defecto facilitan la programación de los atributos con un valor
cargado por defecto que es propiamente el de mayor moda; es decir, el valor de mayor
repitencia dentro del dominio respectivo. Por ejemplo, deseamos ingresar el dato
correspondiente al sexo de una persona, pero sabemos a priori que la mayoría de ellos son de
sexo masculino, entonces podremos ‘programar’ el ingreso de datos en el cuál para el atributo
SEXO el dato por defecto sea M, de manera que el usuario que ingresa los datos no necesitará
registrar dicho valor, salvo cuando el valor sea F (femenino).
- Cláusula DEFAULT
Esta propiedad permite registrar un valor por defecto u omisión para un atributo o columna
de la tabla de datos.
Sintaxis
ALTER TABLE <<NombreTabla>>
ADD
CONSTRAINT <<NombreConstraint>>
DEFAULT(<<Valor por Defecto>>) for Columna;
Ejemplo:
b) Restricciones Procedimentales
En las Restricciones Procedimentales es obligatorio especificar el aspecto Condicionador de
la restricción y la Acción que se ejecutará, veamos los siguientes casos:
b.1) Los Store Procedure
En los Store Procedure (Procedimientos Almacenados), es obligatorio especificar en qué
condiciones se ejecutarán las Acciones programadas.
MODELADO DE DATOS Página 181
b.2) Los Trigger’s
Los Trigger’s, también conocidos como Disparadores, se caracterizan porque combinan los
enfoques declarativos en la condición y procedimental en la acción. El cumplimiento de la
condición dispara la acción. Por ejemplo; durante la eliminación del registro de un cliente en la
tabla CLIENTES; se verificará que aquél no tenga efectuada ninguna compra registrada en la tabla
COMPRAS; de lo contrario se disparará el mensaje de error y se abortará la operación.
Del mismo modo, cada vez que se registra una venta efectuada, se actualizará la comisión
del vendedor que realizó la operación. Estas operaciones se programan teniendo en cuenta las
reglas de negocio establecidas para que se vayan desarrollando los cambios previstos en las
tablas asociadas, cuando se realice las operaciones Insert, Delete o Update en dichas tablas.
MODELADO DE DATOS Página 182
LABORATORIO Nº 8
BASE DE DATOS CON RESTRICCIONES DE
INTEGRIDAD DE DATOS
La Universidad Nacional de Trujillo dispone de una Biblioteca universitaria para ofrecer el
servicio de préstamo de libros a la comunidad de estudiantes, docentes, y administrativos; así
como a la colectividad en general. Se requiere la implementación de un sistema de base de
datos que responda a las solicitudes de préstamo de libros de sus diversos usuarios. Las
operaciones de control del servicio de préstamo de libros se llevan a cabo, de la siguiente
manera:
- Los bibliotecarios se registran con su login y contraseña.
- El servicio de préstamo de libros se lleva a cabo a través de la ficha de préstamo que es
llenada por el usuario (el cuál debe estar debidamente registrado, si no fuera así
inmediatamente se procederá a elaborar su registro en el sistema); donde se indica los
principales datos del libro requerido.
- Los libros son en realidad una representación de los ejemplares, los cuáles son los objetos
físicos que actúan en el servicio de préstamo. Asimismo, se puede establecer que un libro
puede tener uno o varios ejemplares en la biblioteca.
- Se identifica que un libro puede contener diversos autores; así como un autor, puede haber
escrito diversos libros. Es decir, hay una relación de muchos-a-muchos entre los libros y sus
autores.
- Un Usuario puede ser: 1. Alumno, 2. Docente o Administrativo, 3. Usuario externo.
- Se debe verificar que la fecha de ingreso (laboral) del bibliotecario debe ser menor o igual a
la fecha actual del sistema.
- El mismo control se debe realizar para la fecha de publicación de los libros, verificando que
su valor debe ser menor a la fecha actual obtenido del sistema.
- El atributo EstadoActual del Ejemplar tiene uno de los siguientes valores: 1. Libro OK, 2. Libro
con deterior leve, 3. Libro con deterioro moderado, 4. Libro Inservible, 5. Libro dado de baja.
- Verificar que el número de páginas del libro siempre sea mayor a 0.
- En el caso de los datos de los ejemplares, se debe verificar que el tipo de préstamo debe ser:
S. Para Lectura en Sala, y D. Para Lectura a Domicilio. Aquí también debe ser verificado el
valor de la disponibilidad, con los siguientes datos: P. El Libro se encuentra Prestado, y D. El
Libro está Disponible.
MODELADO DE DATOS Página 183
1.2 Script para la creación de la base de datos BDBiblioteca
La creación de la base de datos BDBiblioteca se debe hacer en la base de datos del
sistema denominada master, de la siguiente manera:
1.3 Script para la creación de la tabla USUARIO
La tabla USUARIO es denominada tabla fuerte debido a que sus datos originan las
ocurrencias de otras tablas, es decir, es una tabla origen. Los datos que se tendrán en cuenta
son:
- USUARIO (IdUsuario, TipoUsuario, Nombre, NroDNI)
- El dominio para el atributo TipoUsuario es: 1. Alumno, 2. Docente o Administrativo, y 3.
Usuario externo.
- El script para crear esta tabla es:
1.4 Script para la creación de la tabla BIBLIOTECARIO
Esta tabla también es fuerte porque es la que origina los préstamos de libros para los
diversos usuarios. Los datos mínimos son los siguientes:
BIBLIOTECARIO (IdBibliotecario, Nombre, FechaIngreso)
- El dominio de FechaIngreso es que es menor o igual al valor de la fecha actual del sistema.
Por defecto su valor debe ser el valor de la fecha actual del sistema.
- Se crea esta tabla con el siguiente script:
MODELADO DE DATOS Página 184
1.5 Script para la creación de la tabla LIBRO
La tabla LIBRO contiene la descripción general de los libros. Es una tabla fuerte que contiene
los siguientes datos mínimos:
LIBRO (IdLibro, Titulo, FechaPublic, NroPaginas)
- Verificar que FechaPublic sea menor a la fecha actual del sistema.
- Verificar que el número de páginas siempre sea mayor a cero.
1.6 Script para la creación de la tabla AUTOR
Esta tabla contiene los datos mínimos necesarios para identificar a un Autor. Se debe tener
en cuenta la creación de su clave primaria.
AUTOR (IdAutor, Nombre, Email)
MODELADO DE DATOS Página 185
1.7 Script para la creación de la tabla LIBRO_AUTOR
La tabla LIBRO_AUTOR aparece como tabla intermedia para facilitar la identificación de
cuáles son los autores de un libro determinado, o también que libros ha escrito un autor
determinado. Esta tabla tiene una clave primaria compuesta a su vez por dos claves foráneas
provenientes de manera respectiva desde las tablas LIBRO y AUTOR. Su contenido es:
LIBRO_AUTOR (IdLibro, IdAutor)
- A continuación, se muestra el script de creación:
1.8 Script para la creación de la tabla EJEMPLAR
La tabla Ejemplar tiene una relación muy cercana con la tabla Libro, debido a que un ejemplar
lo es particularmente de un libro. Sin embargo, debido a la naturaleza de que un Libro puede
MODELADO DE DATOS Página 186
tener uno o más Ejemplares; es necesario incluir en la clave primaria de Ejemplar además del
atributo IdLibro, un valor IdEjemplar. La estructura de esta tabla es:
EJEMPLAR (IdLibro, IdEjemplar, TipoPrestamo, EstadoActual, Disponibilidad)
- Se debe definir la clave primaria compuesta: (IdLibro, IdEjemplar).
- El atributo TipoPrestamo tiene los valores: S. Para Lectura en Sala, y D. Para Lectura a
Domicilio. Aquí también debe ser verificado el valor de la disponibilidad, con los siguientes
datos: P. El Libro se encuentra Prestado, y D. El Libro está Disponible.
- Finalmente, hay que verificar que EstadoActual puede tener uno de los siguientes valores:
1. Libro OK, 2. Libro con deterior leve, 3. Libro con deterioro moderado, 4. Libro Inservible,
5. Libro dado de baja.
1.9 Script para la creación de la tabla PRESTAMO
Esta es una tabla definida como tabla Débil debido a que es aquella que registra todas las
transacciones (operaciones) que se desarrolla en el sistema de base de datos. Los datos que
contiene son:
PRESTAMO (IdLibro, IdEjemplar, Autogenerado, FechaPrestamo, FechaDevolver,
FechaDevuelto, EstadoEjemplar, IdUsuario, IdBibliotecario)
MODELADO DE DATOS Página 187
- El valor Autogenerado servirá para poder hacer préstamo de ejemplares a diversos usuarios.
- FechaPrestamo, es la fecha actual del sistema.
- FechaDevolver, tiene el valor de FechaPrestamo más 3 días como máximo.
- FechaDevuelto, se actualiza cuando el ejemplar es devuelto por el usuario.
- EstadoEjemplar, tiene los valores de ‘1’ a ‘5’. Sirve para verificar el estado del ejemplar
cuando sea devuelto por el usuario.
MODELADO DE DATOS Página 188
2. Diagrama de la base de datos BDBiblioteca
MODELADO DE DATOS Página 189
Actividad Nº 8
Una empresa realiza pedidos delivery de Pizzas. Hay una promoción de la empresa que la
obliga a realizar las entregas a la hora puntual en un tiempo no mayor a 25 minutos, las tardanzas
se castigan con un descuento del 50% del ImporteTotal del pedido a los clientes. La oficina de
gestión de base de datos de la empresa le ha pedido el diseño de la base de datos:
Las restricciones de integridad de datos son:
- Los turnos de las recepcionistas son: T. Tarde, N. Noche. Su Código de Usuario es: primera
letra de su nombre, más 4 primeros dígitos de su DNI.
- El tipo de cliente es: P. Premium, V. Vip, y N. Normal.
- El peso de la categoría se registra en gramos, desde 180 gramos hasta 850.
- El tamaño que se registra en la categoría es: P. Personal, N. Normal, M. Mediana, G. Grande,
y E. Extragrande.
- El Precio de la Pizza debe ser siempre mayor a 0.
- El año del vehículo en la movilidad debe ser mayor o igual a 2015.
- La Fecha de Ingreso del repartidor debe ser menor o igual a la fecha del sistema. Por defecto
se carga la fecha del sistema.
- La fecha del Pedido debe ser menor o igual a la fecha del sistema y también es su valor por
defecto. La hora debe estar entre 14:00 hasta 23:00.
- La cantidad y el precio en el Detalle de Pedido, debe ser mayor a 0.
- En la tabla de Entregas; la HoraPedido = Hora de la tabla Pedido. Verificar que la Hora de
Salida sea mayor a la Hora del Pedido; y la Hora de Entrega sea mayor a la Hora de Salida.
En este caso, considere que los valores de Importe Total e Importe Pagado deben ser mayor
a 0. Finalmente, la condición de pago será uno de los valores: N. Normal, D. Descuento.
MODELADO DE DATOS Página 190
Autoevaluación 8
1. Es una restricción que se escribe en un programa externo, por ejemplo, en Java.
A. Restricción Inherente
B. Restricción Interna a la base de datos
C. Restricción Externa a la base de datos
D. Restricción Procedimental
E. N. A.
2. La siguiente propiedad tiene que ver con la moda de una columna de datos:
A. Default
B. Not Null
C. Check
D. Foreign Key
E. N. A.
3. Identifique la verdad o falsedad en “Una columna de datos puede tener más de una
restricción Check.
A. Verdadero B. Falso C. Ni verdadero, ni falso
4. Se utiliza para verificar la validez de los datos registrados en una columna de datos:
A. Default
B. Not Null
C. Check
D. Foreign Key
E. N.A.
5. Identifique cuál de las siguientes afirmaciones es Falsa:
A. Una Clave Foránea siempre va en una tabla destino
B. Una Clave Primaria solamente va en una tabla origen
C. Un valor autogenerado siempre es Not Null.
D. Las relaciones de muchos a muchos siempre requieren una tabla intermedia.
E. N. A.
UNIDAD III
PROGRAMACIÓN DE BASES DE DATOS Página 192
Sesión 9: Vistas de datos
1. ¿Qué es una vista de datos?
Una vista de datos es una tabla virtual derivada de una o varias tablas de base que se
desarrolla a través de una operación de consulta de datos; estos datos no requieren
almacenamiento físico en la base de datos; de ahí que se utiliza el término “tabla virtual” como
sinónimo para referirse a una vista. Una de las grandes ventajas del uso de vistas es que al ser
uno de los objetos de la base de datos, generalmente es creada en forma centralizada en el
servidor de datos; de esta manera, los usuarios que tienen los privilegios apropiados pueden
consumirlos cuando lo requieran. En estos casos, no será necesario su definición en forma local,
con ello, se podrá disminuir el tráfico de red mejorando la performance del sistema de gestión
de la base de datos en forma considerable. Esta arquitectura centralizada en el servidor se
muestra a continuación:
1.1 ¿Qué ventajas se obtiene con el uso de Vistas?
Existe importantes ventajas que se obtiene con el uso de las vistas de datos; entre las más
destacadas, tenemos:
- Mejoramiento de la performance del sistema de gestión de base de datos; pues cuando las
vistas se encuentran en el lugar físico donde se definió la base de datos, este es el caso de
las bases de datos distribuidas; se reduce el tráfico de red, descongestionándola.
- Reduce la complejidad desde la percepción del usuario, quien solamente se limita a
consumir los datos que produce las vistas.
- Dado que los datos que contiene una vista proceden de una operación select simple o
compleja; estos datos adquieren más importancia para el usuario.
- Las vistas pueden ser administradas con permisos desde los SGBD.
PROGRAMACIÓN DE BASES DE DATOS Página 193
1.2 Sentencia CREATE VIEW para la creación de Vistas
Sintaxis
CREATE VIEW [NameEsquema.]<<NameVista>> [ (columna1 [, …] ) ]
[ with <<Atributos de la Vista>> [, …] ]
AS
Sentencia SELECT
[ with Check option ] [; ]
Atributos de la Vista:
[encryption ] | [schemabinding] | [view metadata]
Descripción de parámetros
- Columna1 [, …]: Son los nombres de las columnas de la vista. Cuando no se indica, estos
nombres son los mismos a los que se definen en la sentencia Select de la vista.
- Sentencia SELECT
Es la operación que provee los datos para las vistas. Esta sentencia no admite el uso de la
cláusula Group By, salvo cuando es utilizada en conjunto con la cláusula TOP n.
- Encryption: Esta opción oculta el script de la vista para los usuarios.
- Schemabinding; Esta opción produce un vínculo entre los objetos, en este caso, la vista y
los demás objetos de la base de datos dentro del esquema donde se definieron. Significa
que no se puede eliminar cualquier objeto asociado a las tablas de la vista, a menos que se
cambie esta opción schemabinding. Los cambios efectuados requieren el uso del
procedimiento almacenado sp_refreshview.
- Ejemplo
Sobre la base de datos NorthWind; crear las siguientes vistas:
1.2.1 Crear la vista V_ProductosWithReorderLevel; con los datos ProductID, ProductName y
UnitsInStock de aquellos productos cuyo Nivel de Reorden está en el rango de 20 a 24.
Los datos de la vista son accesados así:
PROGRAMACIÓN DE BASES DE DATOS Página 194
- Resultados de la ejecución de la vista V_ProductosWithReorderLevel:
- Estos datos, sin embargo, podrían salir ordenados de acuerdo, por ejemplo, al Stock,
veamos:
- Hay que recordar que order by, sólo se permite con TOP.
1.2.2 Elaborar una vista conteniendo el resumen de las ventas indicando el Id de la Orden, el
Nombre completo del empleado que la procesó y el importe total de dicha orden
efectuada en el mes de marzo del año 1998, de la base de datos NorthWind.
PROGRAMACIÓN DE BASES DE DATOS Página 195
1.3 Modificación de Vistas
La modificación de vistas se refiere a la posibilidad de que posteriormente una vista pueda
ser redefinida, para ello se podrá utilizar la cláusula ALTER VIEW cuyo detalle tiene la misma
sintaxis de la instrucción create view.
Ejemplo:
Modificar el ejemplo 1.2.2, para que el reporte obtenido se muestre ordenado de mayor a
menor en base al nombre del empleado, veamos:
1.4 Eliminación de Vistas
La eliminación de una vista puede desarrollarse con la instrucción DROP VIEW; de la
siguiente manera:
Sintaxis:
DROP VIEW <<NameVista>>
1.5 Vistas actualizables
A través de una Vista es posible actualizar o modificar los datos de una tabla base, siempre
y cuando la vista provenga de una sola tabla y las columnas de referencia no procedan de
operaciones de cálculo, ni se haya obtenido con el uso de funciones.
PROGRAMACIÓN DE BASES DE DATOS Página 196
2. ¿Qué son las Instantáneas?
Una instantánea se refiere a la obtención de una consulta de datos desarrollada con
sentencias select de manera similar a las vistas, pero en el caso de las instantáneas la
información solo tiene validez para un instante en el tiempo, ya que un solo cambio en las tablas
que originan dicha instantánea provocaría que la información quede desactualizada.
Normalmente, las instantáneas son utilizadas en tablas temporales, que se desarrollan en la
etapa de programación de la base de datos como alternativas de pruebas.
Sintaxis
SELECT << Columna-1 [, … ]>>
INTO <<NameInstantánea>>
FROM <<NameTabla>>
[ WHERE <<Condición>> ];
Ejemplo:
2.1 Sobre la base de datos NorthWind, mostrar en una Instantánea las órdenes efectuadas y su respectivo detalle.
OBSERVACIÓN:
• Se crea la tabla temporal: OrdenesWithDetalles
• En este caso, podremos observar los datos que quedarán desactualizados cuando se
produzca una transacción en alguna tabla origen.
• Para ver los resultados, ejecutaremos:
PROGRAMACIÓN DE BASES DE DATOS Página 197
LABORATORIO Nº 09
VISTAS DESARROLLADAS SOBRE LA BASE DE DATOS
NORTHWIND
2.2 Mostrar en una VISTA; las órdenes efectuadas en el año 1998 y su respectivo detalle.
Línea de resultados:
PROGRAMACIÓN DE BASES DE DATOS Página 198
2.3 Elaborar la vista de datos para mostrar un resumen de las órdenes efectuadas. Los datos
que se mostrarán son: IdOrden, Fecha (en formato dd/mm/aaaa), nombre completo del
empleado que procesó la orden y el resumen del total de importe.
- Línea de Resultados:
PROGRAMACIÓN DE BASES DE DATOS Página 199
2.4 Mostrar el resumen de las órdenes efectuadas; pero solamente aquellas cuyo importe sea
menor a 1 000.00 que fueron ordenadas en el año 1997.
- Línea de resultados
PROGRAMACIÓN DE BASES DE DATOS Página 200
Actividad Nº 9
Utilizar la base de datos BDBiblioteca:
En la base de datos anterior; ingrese los datos en el siguiente orden:
1. Registrar 10 usuarios, 05 bibliotecarios, 12 libros alguno de los cuales tienen 2 o 3 autores;
pero todos los libros tienen por lo menos 1 autor. Registrar de 2 a 5 ejemplares por libro y
finalmente, registrar 40 préstamos de libros efectuados en cualquier fecha entre los años
2017 al 2019.
2. Elabore los scripts de las vistas que respondan a cada uno de los siguientes casos:
2.1 Vista de nombre de usuarios alumnos que solicitaron el préstamo de libros cuyo
número de páginas es mayor a 450.
2.2 Vista para acceder al número de DNI y nombre de los usuarios (de cualquier tipo de
usuario); que no devolvieron el préstamo de libros (ejemplares) durante el año 2019.
2.3 Vista para mostrar el título de los libros que no fueron solicitados por docentes durante
el año 2018.
2.4 Vista conteniendo el Nombre y correo del autor o autores de los libros que tuvieron
como máximo 4 préstamos durante los años 2018 y 2019.
2.5 Vista con el título y nombre del autor o autores con más de 3 ejemplares en la
biblioteca.
PROGRAMACIÓN DE BASES DE DATOS Página 201
Autoevaluación 9
1. Responda la verdad o falsedad en: “Una instantánea y una vista, siempre muestran los
mismos datos”
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
2. Marque la respuesta correcta:
A. Las instantáneas reemplazan a las vistas porque cuestan menos dinero producirlas
B. Las vistas no requieren cláusulas adicionales para usarlas con order by
C. Es recomendable que las vistas se instalen en el servidor de datos
D. Es recomendable que las vistas se instalen en el lado del cliente
E. N. A.
3. Indique la verdad o falsedad en: “Una tabla puede actualizarse desde una vista si
proviene de una sola tabla base”
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
4. Las vistas pueden contener columnas que provienen de una operación de cálculo con
otras columnas. Indique si la afirmación anterior es verdadera o falsa.
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
5. Indique si es verdad o falso en: “Una vista de datos puede hacer una llamada a otra vista
de datos”.
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
PROGRAMACIÓN DE BASES DE DATOS Página 202
Sesión 10: Procedimientos Almacenados
1. ¿Qué son los procedimientos almacenados?
Algunas operaciones de manejo de los objetos de la base de datos tienen dos formas de ser
desarrolladas; por un lado, estas operaciones pueden estar escritas en las propias aplicaciones
y ser instaladas en el lado del cliente generando un gran tráfico de red para ser consumidas con
la información de la base de datos del servidor; pero, por otro lado, pueden ser desarrolladas
en la propia base de datos como procedimientos almacenados y ser instaladas en el servidor,
luego hacer que las aplicaciones las puedan ejecutar desde el lado del cliente.
Los procedimientos almacenados están formados por un conjunto de sentencias del
lenguaje Transact-SQL y que permiten el desarrollo del código requerido en la manipulación de
ciertos objetos de la base de datos. De esta manera, es posible el uso de parámetros de entrada
o de salida para los procedimientos almacenados, los cuáles podrán ser ejecutados cuando se
requieran.
1.1 ¿Cuáles son los tipos de procedimientos almacenados?
Entre los diversos tipos de procedimientos almacenados, tenemos:
- Procedimientos almacenados del Sistema
Los procedimientos almacenados del sistema vienen con SQL Server. Permiten diversas
operaciones de mantenimiento, manejo de alertas; entre otras operaciones propias del
sistema DBMS. Estos procedimientos se muestran en el esquema sys; e incluso en el
esquema dbo usados para la programación de Jobs y alertas. Tienen el prefijo sp_.
- Procedimientos almacenados temporales
Estos procedimientos almacenados tienen el mismo comportamiento que los
procedimientos permanentes. Se crean en la base de datos tempdb. Existen los
procedimientos almacenados temporales locales; que se diferencian por el prefijo #
colocado en el nombre. Estos se eliminan automáticamente al momento de cerrar la
conexión. También existe los procedimientos almacenados temporales globales; los que
utilizan el símbolo ## en el nombre. Se eliminan cuando se cierra la sesión del usuario. Los
procedimientos creados en la base de datos tempdb, aun si no tuvieran el símbolo # o ##;
igual se eliminan al cerrar las conexiones, dado que tempdb se crea por cada conexión del
usuario.
- Procedimientos almacenados definidos por el usuario
Son aquellos procedimientos que define el usuario dentro de su propia base de datos.
PROGRAMACIÓN DE BASES DE DATOS Página 203
1.2 Creación de procedimientos almacenados
Sintaxis:
CREATE {PROC | PROCEDURE} [Esquema.]<<NameProcedimiento>>
[ { @parametro [ NameTipoEsquema. ] TipoDato }
[ VARYING ] [ = default ] [ OUT | OUTPUT | [READONLY] ] [, … n ]
[ WITH <<[ENCRYPTION] | [RECOMPILE] | [EXECUTE AS Cláusula]>> [ …] ]
[ FOR REPLICATION ]
AS
{ [ BEGIN ]
<< Sentencias SQL >> [ ; ] [ … n ]
[ END ] }
[ ; ]
Especificaciones adicionales
- Los parámetros son locales respecto al procedimiento almacenado.
- No es válido el uso de parámetros cuando se utiliza for replication.
- Todos los tipos de datos pueden definirse en los parámetros; incluso se puede definir un
tipo table para producir parámetros con valores de una tabla de datos.
- Los parámetros definidos como table son de tipo INPUT y se deben definir como readonly.
- Puede usarse default para definir un valor predeterminado para el parámetro.
- La cláusula output, indica que el parámetro es de salida.
1.3 ¿Qué restricciones se debe considerar para los procedimientos almacenados?
Los procedimientos almacenados son de una gran utilidad en el procesamiento por lotes;
sin embargo, hay ciertas consideraciones que se debe tener en cuenta, veamos:
- Las siguientes instrucciones no pueden formar parte del cuerpo de un procedimiento
almacenado: Create default, create Procedure, create rule, create Triggers, y create view.
- Al crear una tabla temporal dentro del procedimiento almacenado, la vigencia de esta tabla
temporal durará solamente mientras el procedimiento esté activo.
- El número máximo de parámetros para un procedimiento almacenado es de 2,100.
PROGRAMACIÓN DE BASES DE DATOS Página 204
Ejemplos:
1. Crear un procedimiento almacenado para insertar los siguientes registros en la tabla AUTOR
de la base de datos BDBiblioteca, descrita en la sesión Nº 09.
Solución:
- Crearemos el siguiente procedimiento almacenado:
- Ahora, haremos la ejecución del procedimiento almacenado, de la siguiente manera:
- Veamos la lista de datos que se ha registrado en la tabla AUTOR:
2. Elaborar un procedimiento almacenado para obtener el Nombre y Email de un autor,
cuyo IdAutor se ingresa como parámetro.
PROGRAMACIÓN DE BASES DE DATOS Página 205
3. Elaborar el procedimiento almacenado sobre la base de datos BDBiblioteca, para registrar
los datos de un nuevo Autor; pero si el Autor ya ha sido registrado; actualizar sus datos.
- Ejecutamos el procedimiento almacenado; así:
- El autor con el IdAutor='1013'; no existe en la tabla por tanto se agregará. El autor cuyo
IdAutor='1011' si existe; entonces sus datos serán actualizados, veamos:
2. Procedimiento almacenado y Vista de datos con una aplicación en Visual Basic
Sobre la base de datos NorthWind cuyo diagrama se encuentra en la sesión Nº 10, ítem 3.
Se pide desarrollar el siguiente Procedimiento Almacenado:
2.1 Mostrar el resumen de las ventas efectuadas de un año cuyo valor se debe registrar en
forma externa al igual que el nombre de un empleado.
PROGRAMACIÓN DE BASES DE DATOS Página 206
2.2 Construir una vista con el nombre completo de los
Empleados que procesaron órdenes.
2.3 Elaborar una vista conteniendo todos los años que se procesaron órdenes.
PROGRAMACIÓN DE BASES DE DATOS Página 207
2.4 Aplicación en Visual Basic .Net para el procesamiento de los procedimientos Almacenados
y la Vista de datos.
- Diseño del formulario
- Carga de datos en los cuadros combo:
Click en “usar elementos enlazados a datos”
En Origen de datos → Agregar origen de datos del proyecto
Base de datos → Siguiente Conjunto de datos → Siguiente
Botón Nueva conexión → Nombre del servidor: localhost → Seleccionar o escribir el nombre de
la base de datos → NorthWind → Aceptar → Siguiente → Siguiente
Vistas → V_AñosWithOrdenes → Finalizar
En la ventana: Tareas de Combobox; elegir:
Mostrar miembro: Años
Miembro de valor: Años
Al ejecutar, podremos procesar lo siguiente: →
Repetir el proceso para el cuadro combo
NOMBRE DE EMPLEADO; con la vista: V_EmpleadosWithOrdenes
- Procesamiento del botón Mostrar:
PROGRAMACIÓN DE BASES DE DATOS Página 208
Private Sub BtnMostrar_Click(sender As Object, e As EventArgs) Handles BtnMostrar.Click
Try Dim oConeccion As New SqlConnection Dim oComando As New SqlCommand Dim oLector As SqlDataReader Dim oFila As ListViewItem oConeccion.ConnectionString = "server=.; Integrated security=true; Initial Catalog=NorthWind" oConeccion.Open() oComando.CommandText = "PA_ResumenVentas" oComando.CommandType = CommandType.StoredProcedure oComando.Parameters.Add("@Año", SqlDbType.Char, 4).Value = Convert.ToString(CboAños.Text.Trim) oComando.Parameters.Add("@Empleado", SqlDbType.VarChar, 50).Value = CboEmpleados.Text.Trim oComando.Connection = oConeccion oLector = oComando.ExecuteReader() ListView1.Items.Clear() If oLector.HasRows = True Then While oLector.Read oFila = New ListViewItem oFila.Text = CStr(oLector.Item("Orden")) oFila.SubItems.Add(CStr(oLector.Item(1))) ListView1.Items.Add(oFila) End While End If oConeccion.Close() oConeccion.Dispose() Catch ex As Exception MessageBox.Show(ex.Message) End Try End Sub
NOTA:
--No olvidar que al inicio del programa debe escribir:
Imports System.Data.SqlClient
PROGRAMACIÓN DE BASES DE DATOS Página 209
LABORATORIO Nº 10
PROCEDIMIENTOS ALMACENADOS
1. Base de datos: VENTAS_V2021
DESARROLLO DE PROCEDIMIENTOS ALMACENADOS --Mostrar la relación de productos de la categoría Condiments use VENTAS_V2021 go create procedure PA_ConsultarProductos @Categoria nvarchar(15) as begin select C.Descripcion as 'Descripción de Categoría', P.IdProducto as IdProducto, P.Producto as 'Nombre de Producto', P.Precio as Precio, P.Stock as Stock from PRODUCTO P inner join CATEGORIA C on P.IdCategoria=C.IdCategoria where C.Categoria=@Categoria end go --Ejecución del PA execute PA_ConsultarProductos 'Condiments'
--Elabore un Procedimiento Almacenado para Mostrar la relación de --Categorías y la cantidad de productos que contienen alter procedure PA_NroProductosxCategoria as begin select C.Categoria as Categoría, count(P.IdProducto) as 'Nº de Productos' from CATEGORIA C inner join PRODUCTO P on C.IdCategoria=P.IdCategoria group by C.Categoria end go
PROGRAMACIÓN DE BASES DE DATOS Página 210
--1. Obtener una copia (foto) de la data de la tabla PRODUCTO --2. Aumentar el Precio en n% de los Productos cuyo valor es Mayor a 25.00 --Copia de la Tabla PRODUCTO en wPRODUCTO select * INTO wPRODUCTO from PRODUCTO --Aumentar el Precio en n% create procedure PA_ActualizarPrecio @Aumento float as begin UPDATE wPRODUCTO SET Precio+=@Aumento*Precio Where Precio>25.00 end go --Ejecución del PA exec PA_ActualizarPrecio 0.10
--PROCEDIMIENTOS ALMACENADOS CON USO DE PARÁMETROS DE ENTRADA --Mostrar los Pedidos que ha procesado un empleado cuyo nombre completo --debe ingresar por teclado. create procedure PA_PedidosDelEmpleado @Empleado nvarchar(31), @Año char(04) as begin select P.IdPedido as IdPedido, P.FechaPedido as [Fecha de Pedido], SUM(D.Precio*D.Cantidad) as Importe from PEDIDO P inner join EMPLEADO E on P.IdEmpleado=E.IdEmpleado inner join DETALLE D on P.IdPedido=D.IdPedido where E.Nombre+' '+E.Apellido=@Empleado and year(P.FechaPedido)=@Año group by P.IdPedido, P.FechaPedido end go --Ejecución del PA exec PA_PedidosDelEmpleado 'Nancy Davolio', '1996' --Crear una vista con el nombre completo de todos los empleados que procesaron pedidos alter view V_EmpleadosconPedidos as select distinct E.Nombre+' '+E.Apellido as Empleado from EMPLEADO E inner join PEDIDO P on P.IdEmpleado=E.IdEmpleado go --Ejecución de la vista select * from V_EmpleadosconPedidos --Mostrar la relación de años de procesamiento de pedidos
PROGRAMACIÓN DE BASES DE DATOS Página 211
create view V_AñosProcesamiento as select distinct year(P.FechaPedido) as Años from PEDIDO P go --Ejecución de la vista select * from V_AñosProcesamiento APLICACIÓN EN VISUAL BASIC:
Private Sub BtnConsultar_Click(sender As Object, e As EventArgs) Handles BtnConsultar.Click Try Dim oConexion As New SqlConnection Dim oComando As New SqlCommand Dim oLector As SqlDataReader Dim oFila As ListViewItem 'Configurando la conección con seguridad de Windows oConexion.ConnectionString = "server=.; integrated security=true; database=VENTAS_V2021" 'Configurando la conección con Seguridad de SQL Server 'oConexion.ConnectionString = "server=.; user id=sa; password='123456'; Initial Catalog=VENTAS_V2021" oConexion.Open() oComando.CommandText = "PA_PedidosDelEmpleado" oComando.CommandType = CommandType.StoredProcedure oComando.Parameters.Add("@Empleado", SqlDbType.NVarChar, 31).Value = CboEmpleado.Text oComando.Parameters.Add("@Año", SqlDbType.Char, 4).Value = CboAño.Text oComando.Connection = oConexion LwConsulta.Items.Clear() oLector = oComando.ExecuteReader If oLector.HasRows = True Then While oLector.Read oFila = New ListViewItem oFila.Text = CStr(oLector.Item("IdPedido"))
PROGRAMACIÓN DE BASES DE DATOS Página 212
oFila.SubItems.Add(oLector.Item(1)) oFila.SubItems.Add(oLector.Item(2)) Me.LwConsulta.Items.Add(oFila) End While End If oConexion.Close() oConexion.Dispose() oLector.Close() Catch ex As Exception MessageBox.Show(ex.Message) End Try End Sub
Importante
No olvidar escribir al inicio del programa:
Imports System.Data.SqlClient
PROGRAMACIÓN DE BASES DE DATOS Página 213
Actividad Nº 10
1. Utilizando la base de datos BDBiblioteca, de la actividad Nº 10, desarrolle una vista para
mostrar la lista de Nombre de Usuarios (sea alumnos, docente, administrativo, o usuario
externo); así también una vista de los años donde se ha registrado préstamo de libros
en la biblioteca.
2. Implementar el procedimiento almacenado que utilice los parámetros de Nombre de
Usuario y Año de préstamo para listar los IdLibro, títulos de libros y fecha de préstamo
respectivos.
3. Implementar un programa en Visual Basic .Net que resuma los objetos de vistas y
procedimientos almacenados de la base de datos anterior.
- Diseño del formulario:
PROGRAMACIÓN DE BASES DE DATOS Página 214
Autoevaluación 10
1. Responda si es verdadera o falsa la siguiente afirmación: “No es válido el uso de
parámetros cuando se utiliza for replication”
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
2. Es una cláusula utilizada para no descubrir el script de un procedimiento almacenado
A. VARYING
B. ENCRYPTION
C. RECOMPILE
D. REPLICATION
E. N. A.
3. El procedimiento almacenado cuyo nombre inicia con #, es un:
A. Procedimiento almacenado del Sistema
B. Procedimiento almacenado definido por el usuario
C. Procedimiento almacenado temporal
D. Procedimiento almacenado extendido
E. N. A.
4. Responda si es verdadera o falsa la siguiente afirmación: “Los parámetros definidos en un
procedimiento almacenado son globales, por defecto”
A. Verdadero
B. Falso
C. Ni verdadero, ni falso
5. Marque la afirmación incorrecta:
A. Una tabla temporal se elimina al cerrar la conexión del usuario
B. Es posible la creación de un procedimiento almacenado con 1,500 parámetros
C. Se pueden crear vistas en un procedimiento almacenado
D. No se puede crear un procedimiento almacenado dentro de otro procedimiento
almacenado
E. N. A.
PROGRAMACIÓN DE BASES DE DATOS Página 215
Sesión 11: Funciones escalares y de tablas
1. ¿Qué es una Función definida por el usuario – UDF ?
Una función definida por el usuario (UDF – User Definition Function) está formado por un
conjunto de instrucciones del lenguaje Transact SQL (en este caso de SQL Server) para facilitar
la reutilización de código script. Las funciones utilizan parámetros de entrada y devuelven un
valor escalar o una tabla. A diferencia de los procedimientos almacenados, las funciones no
aceptan parámetros de salida.
1.1 ¿Cuáles son los componentes de una UDF?
Los componentes de una función definida por el usuario son:
• La cabecera que se utiliza para definir el nombre de la función, así como el nombre de
los parámetros de entrada con sus respectivos tipos de datos, algunas opciones
adicionales del parámetro de entrada, y el tipo de datos de parámetro devuelto, con sus
respectivas opciones adicionales.
• El cuerpo de la función, que está conformado por el conjunto de instrucciones que
ejecutan la lógica de la función.
1.2 ¿Qué es una Función Escalar?
Una función se dice que es Escalar porque devuelve un único valor de datos. Este valor
devuelto puede ser de cualquier tipo de datos excepto text, ntext, image, cursor y
timestamp.
Sintaxis:
CREATE FUNCTION [ NameEsquema.]NameFunción ([{@NameParámetro
[ AS ]
[ NombreTipoEsquema.]TipoDatoParámetro [=default] [READONLY]} [, …n])
RETURNS <<TipoDatoRetorno>>
[WITH <function_option> [,…n]] [ AS ]
BEGIN
<<Cuerpo de la función>>
RETURN ExpresiónEscalar
END
[;]
PROGRAMACIÓN DE BASES DE DATOS Página 216
Especificaciones
• @NameParametro
La UDF puede tener un máximo de 2,100 parámetros.
• [ NameTipoEsquema.]TipoDatoParámetro
Es el tipo de datos del parámetro, y de forma opcional, el esquema al que pertenece
• [=default]
Es un valor predeterminado para el parámetro. Si se define un valor default, la función
se puede ejecutar sin especificar un valor para ese parámetro.
• READONLY
Indica que el parámetro no se puede modificar en la definición de la función.
• TipoDatoRetorno
Es el valor devuelto por la función a manera de resultado.
1.3 Ejemplos de funciones escalares
1.3.1 Implementar el script para obtener el valor del menor dígito de un número entero.
PROGRAMACIÓN DE BASES DE DATOS Página 217
1.3.2 Elabore el script de la función para calcular la suma de los dígitos de un número entero.
1.3.3 Implementar la función escalar para calcular la suma desde 1 hasta un número entero
positivo.
Ejemplo:
Sea num=4; entonces Suma = 1+2+3+4 → Suma=10
1.3.4 Elaborar el script para determinar si un número entero, es COMPLETO. Se dice que un
número entero es completo si y solamente si, es igual a la suma de sus dígitos más la
suma desde 1 hasta el valor de cada uno de sus dígitos.
Ejemplo:
25 es un número completo; pues: 25 = (2+5)+(1+2)+(1+2+3+4+5)
36 es un número completo; pues: 36 = (3+6)+(1+2+3)+(1+2+3+4+5+6)
PROGRAMACIÓN DE BASES DE DATOS Página 218
- Elaboramos una función que permita desarrollar la suma de los dígitos del número y las
sumas parciales desde 1 hasta cada uno de sus dígitos, veamos:
- Ahora, desarrollamos la función para determinar si un número entero es o no Completo.
1.3.5 Elaborar el script en T-SQL para obtener el número invertido de un número entero
PROGRAMACIÓN DE BASES DE DATOS Página 219
1.3.6 Un número es Capicúa cuando se lee igual de derecha a izquierda. Implementar un script
en T-SQL para determinar si un número entero es capicúa.
2. ¿Qué es una función de tabla?
Una función de tabla de datos es una función definida por el usuario que devuelve como
salida un tipo de dato: TABLE.
Sintaxis:
CREATE FUNCTION [NameEsquema.]NameFunción ( [{@NamePparametro [AS]
[nameTipoEsquema.]TipoDatoParámetro [=default] [READONLY]} [, …n] )
RETURNS @VariableReturn TABLE <DefiniciónTipoTabla >
[WITH <function_option> [,…n]] [AS]
BEGIN
<< Cuerpo de la Función >>
END [;]
Especificaciones
• TABLE
Especifica que el valor devuelto de la función con valores de tabla es una tabla. Sólo
se pueden pasar constantes y @local_variables a las funciones con valores de tabla.
En las funciones insertadas con valores de tabla, el valor devuelto de TABLE se
define mediante una única instrucción SELECT. Las funciones insertadas no tienen
variables de retorno asociadas.
PROGRAMACIÓN DE BASES DE DATOS Página 220
Ejemplo de función de tabla
Obtener una tabla de datos conteniendo los datos de los productos que pertenecen a una
categoría determinada cuyo Número de Unidades en Stock sea mayor o igual a un valor
StockMinimo ingresado también en forma externa.
3. ¿Qué son las funciones integradas?
Como ya tenemos conocimiento, las funciones integradas se refiere a las porciones de
código script que tienen la capacidad de recibir datos externos definidos como parámetros los
cuales son utilizados para producir operaciones específicas dentro de las funciones, otorgando
siempre un resultado. A continuación, veremos una lista de algunas funciones integradas de
utilidad.
3.1 Función SUM
Esta función calcula la suma de todos los valores o solo de los valores DISTINCT de la
expresión. Solamente se puede utilizar con columnas numéricas en las cuales se omite los
valores NULL.
PROGRAMACIÓN DE BASES DE DATOS Página 221
Sintaxis
SUM ( [ ALL | DISTINCT ] expression )
SUM ([ ALL ] expression) OVER ( [ partition_by_clause ] order_by_clause)
Ejemplo:
Sobre la base de datos NorthWind; mostrar la lista de productos e importes de una
Orden cuyo valor se debe identificar en forma externa.
3.2 Función MAX
La función MAX devuelve el valor máximo de la expresión.
Sintaxis
MAX( [ ALL | DISTINCT ] expression )
MAX ([ ALL ] expression) OVER ( [ <partition_by_clause> ] [ <order_by_clause> ] )
Especificaciones
Cláusula OVER partition_by_clause; divide el conjunto de resultados en particiones a las que se
aplica la función. Si no se especifica, la función trata todas las filas del conjunto de resultados de
la consulta como un único grupo.
Ejemplo:
Mostrar el valor del mayor precio de los productos de una categoría cuyo valor se
registra en forma externa.
PROGRAMACIÓN DE BASES DE DATOS Página 222
3.3 Función MIN
Esta función devuelve el valor mínimo de la expresión.
Sintaxis
MIN( [ ALL | DISTINCT ] expression )
MIN ([ ALL ] expression) OVER ( [ <partition_by_clause> ] [ <order_by_clause> ] )
Ejemplo:
Mostrar el valor del menor número de unidades en stock de los productos de una
categoría cuyo valor se registra en forma externa.
3.4 Función COUNT
Esta función devuelve el número de elementos encontrados en un grupo incluyendo los
valores NULL y los valores duplicados.
Sintaxis
COUNT ( { [ [ ALL | DISTINCT ] expression ] | * } )
COUNT ( [ ALL ] { expression | * } ) OVER ( [ <partition_by_clause> ] )
Ejemplo:
Mostrar los Id de las Categorías y la cantidad de productos que contienen.
PROGRAMACIÓN DE BASES DE DATOS Página 223
3.5 Función AVG
Esta función devuelve el promedio de los valores de un grupo.
Sintaxis
AVG ( [ ALL | DISTINCT ] expression )
[ OVER ( [ partition_by_clause ] order_by_clause ) ]
Ejemplo:
Mostrar los Id de las Categorías y el promedio de las unidades de reorden de productos que
contienen.
3.6 Función CAST y CONVERT
Estas funciones convierten una expresión de un tipo de datos a otro.
Sintaxis de la función CAST:
CAST (expression AS data_type [ ( length ) ] )
Sintaxis de la función CONVERT:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
Ejemplo de función CAST
Utilizar la función CAST para cambiar el tipo de datos de un valor decimal(5, 2).
PROGRAMACIÓN DE BASES DE DATOS Página 224
3.7 Ejemplo de la función CONVERT
Convertir un dato de fecha actual a otros formatos.
3.8 Función DateDiff
La función DateDiff compara y obtiene la diferencia entre elementos de fecha, como días,
semanas, minutos y horas.
Sintaxis:
DATEDIFF (datepart, startdate, endate)
Ejemplos
Obtener el número de meses, días y semanas entre dos fechas establecidas.
Línea de resultados
4. Funciones de cadenas
4.1 Función LEN
La función LEN devuelve el número de caracteres de la expresión de cadena especificada,
en el que se ha excluido los espacios finales.
Sintaxis:
LEN ( Expresión de cadena )
PROGRAMACIÓN DE BASES DE DATOS Página 225
Ejemplo:
Obtener el valor de una cadena de caracteres y la cantidad de caracteres que contiene.
4.2 Funciones Upper y Lower
La función Upper devuelve una expresión de caracteres convertidos a mayúsculas y la
función Lower devuelve la expresión de caracteres convertidos a minúsculas.
Sintaxis:
UPPER ( character_expression )
LOWER ( character_expression )
Ejemplo:
Obtener el apellido en mayúsculas y el nombre en minúsculas de los empleados de NorthWind.
4.3 Función LEFT
Esta función devuelve la parte izquierda de una
Cadena de caracteres con el número de caracteres requerido.
Sintaxis:
LEFT ( character_expression , integer_expression )
Ejemplo:
Mostrar las 14 primeras letras del nombre de la compañía cuyas primeras dos letras son: 'An' o
'Fr'.
PROGRAMACIÓN DE BASES DE DATOS Página 226
4.4 Función Right
La función Right devuelve la parte derecha de una cadena de caracteres con el número de
caracteres requerido.
Sintaxis:
RIGHT ( character_expression , integer_expression )
Ejemplo:
Mostrar las últimas letras del nombre de la compañía cuyas primeras dos letras son: 'An' o 'Fr'.
4.5 Función Substring
Esta función devuelve parte de una cadena de caracteres, desde una posición de inicio, una
cantidad específica de caracteres.
Sintaxis:
SUBSTRING ( expression ,start , length )
Ejemplo:
Mostrar el apellido y primera letra del nombre de los empleados que tuvieron participación en
las ventas del mes de mayo del año 1998.
4.6 Función TRIM
Eliminar espacios del inicio y del final de una cadena.
Sintaxis:
TRIM ( [ characters FROM ] string )
PROGRAMACIÓN DE BASES DE DATOS Página 227
Ejemplo:
Mostrar el mensaje excepto los caracteres del inicio y final de la cadena de caracteres.
4.7 Funciones LTrim y RTrim
Eliminan todos los espacios iniciales o finales en blanco respectivamente, de una cadena de
caracteres.
Sintaxis:
LTRIM ( character_expression )
RTRIM ( character_expression )
Ejemplo:
Mostrar una cadena de caracteres sin espacios en blanco a la izquierda y a la derecha.
4.8 Función Replace
Reemplaza todas las instancias de un valor de cadena especificado por otro valor de cadena.
Sintaxis:
REPLACE ( string_expression , string_pattern , string_replacement )
Ejemplo:
Reemplazar una palabra en el contenido de una cadena de caracteres.
PROGRAMACIÓN DE BASES DE DATOS Página 228
4.9 Funcion Replicate
Esta función repite un valor de cadena una cantidad especificada de veces.
Sintaxis:
REPLICATE ( string_expression ,integer_expression )
Ejemplo:
Mostrar el nombre completo de los empleados de la base de datos NorthWind; de modo que el
nombre y apellido quede lo más alineado posible.
Línea de Resultados
PROGRAMACIÓN DE BASES DE DATOS Página 229
LABORATORIO Nº 11
IMPLEMENTACIÓN DE FUNCIONES
--Función para obtener las órdenes procesadas con el importe de venta, de un mes y año
determinado por teclado
use Northwind
go
if OBJECT_ID('dbo.fnVerProdvendidos', 'fn') is not null
drop function dbo.fnVerProdvendidos
go
create function dbo.fnVerProdvendidos(@Mes int, @Año char(04))
returns table
as
return (
select OD.OrderID as 'IdOrden',
O.OrderDate as Fecha,
P.ProductName as 'Nombre de Producto',
sum(OD.Quantity*OD.UnitPrice) as Importe
from Orders O
join [Order Details] OD
on O.OrderID=OD.OrderID
join Products P
on OD.ProductID=P.ProductID
where month(O.OrderDate)=@mes
and year(O.OrderDate)=@Año
group by OD.OrderID, O.OrderDate, ProductName
)
Go
--Mostrar los resultados de la funcion
select *
from dbo.fnVerProdvendidos(11, 1997)
PROGRAMACIÓN DE BASES DE DATOS Página 230
--Crear una función para obtener la lista de productos, precios y stock; pero solamente
--de aquellos que pertenecen a una categoría definida por teclado.
use Northwind
go
if OBJECT_ID('dbo.fnListaProductosxCategoria', 'fn') is not null
drop function dbo.fnListaProductosxCategoria
go
create function dbo.fnListaProductosxCategoria(@Categoria nvarchar(15))
returns @ListadoProductos TABLE
(IdProducto int primary key,
NameProducto nvarchar(40),
Precio money,
Stock smallint)
as
begin
insert @ListadoProductos
select P.ProductID, P.ProductName, P.UnitPrice, P.UnitsInStock
from Products P
inner join Categories C
on P.CategoryID=C.CategoryID
where C.CategoryName=@Categoria
return
end
go
--Ejecución de la función
declare @Categ nvarchar(15)
set @categ='beverages'
select * from dbo.fnListaProductosxCategoria(@categ)
PROGRAMACIÓN DE BASES DE DATOS Página 231
Actividad Nº 11
A continuación, usted desarrollará los ejercicios propuestos acerca del uso de funciones
escalares.
1. NÚMEROS AMIGOS
Dos números son amigos cuando la suma de los divisores de uno de ellos es igual al otro
y viceversa. Se desea implementar un proceso para determinar si dos números cualesquiera
definidos en forma externa son amigos.
2. LISTA DE NÚMEROS CUBO PERFECTO
Un número es Cubo Perfecto cuando dicho número es igual a la suma del cubo de sus
dígitos. Por ejemplo; el número 153; es Cubo Perfecto debido a lo siguiente: 153 = 13 + 53 + 33
Se requiere implementar el script de una función en T-SQL para obtener la lista de números
Cubos Perfectos menores a 5,000.
3. LISTA DE NÚMEROS FIBONACCI
Un número pertenece a la serie de Fibonacci cuando es igual a la suma de los dos términos
inmediatamente anteriores. Tenga en cuenta que los dos primeros números de la serie
son: 2 y 3. Por ejemplo: Los 6 primeros términos de la serie son: 2, 3, 5, 8, 13, 21, . . .
Se requiere implementar el script de una función para mostrar la lista de los n primeros
números de la serie de Fibonacci. Tenga en cuenta que el valor de n se registrará en forma
externa.
4. LISTA DE NÚMEROS CON DÍGITOS IMPARES
Implementar el script de una función en T-SQL para mostrar la lista de números entre
1000 y 1500; cuyos dígitos intermedios sean impares.
PROGRAMACIÓN DE BASES DE DATOS Página 232
Autoevaluación 11
1. Elimina cualquier letra o carácter en blanco de la izquierda o de la derecha de una
cadena de caracteres.
A. LTRIM
B. RTRIM
C. TRIM
D. SUBSTRING
E. N.A.
2. Señale cuál de las siguientes expresiones en una sentencia select es incorrecta.
A. Substring('Prueba de sentencia', 1, 1)
B. Ltrim('Prueba de sentencia')
C. Trim('n' from 'Prueba de sentencia')
D. Replicate('&', 0)
E. N. A.
3. Indicar la verdad o falsedad en la siguiente afirmación: “Una función escalar puede
retornar más de un valor como resultado”
A. Verdadero B. Falso C. Ni verdadero, ni falso
4. La cantidad máxima de parámetros para una función escalar es:
A. 2,000 B. 2,100 C. 2,200 D. 2,300 E. N. A.
5. Señale con cuál de las siguientes funciones integradas se puede eliminar los espacios
intermedios de una cadena de caracteres.
A. LTRIM
B. RTRIM
C. TRIM
D. SUBSTRING
E. CUALQUIERA DE LAS ANTERIORES
PROGRAMACIÓN DE BASES DE DATOS Página 233
Sesión 12: Triggers
1. ¿Qué es un Triggers?
Los Triggers, también conocidos como Disparadores, son operaciones que se ejecutan
automáticamente a manera de efecto secundario al momento de realizar modificaciones a la
base de datos. En el diseño de un Trigger para un sistema de base de datos se debe tener bien
definido cuáles son las condiciones que motivará su ejecución o procesamiento, así como cuáles
son las operaciones que forman el propósito del Trigger.
Los Triggers entonces; facilitan la puesta en alerta a los usuarios al momento que se
encuentran operando con los datos para evitar actualizaciones fallidas. Las operaciones que
restringen el uso válido de los datos son; Inserción de registros, Eliminación de registros, o
Modificación de datos.
En resumen, se puede programar ciertas operaciones para estos casos, por ejemplo, para
validar los resultados de manera que estemos en capacidad de asegurar dentro de lo posible
que las operaciones de actualización de datos siempre se harán de forma exitosa.
Ejemplo:
Un proceso de matrícula semestral en la Universidad Nacional de Trujillo se valida de la
siguiente manera:
- Los cursos de la matrícula actual serán aquellos que se han programado para el presente
semestre. En este caso, nadie podrá matricularse en un curso que no está ofertando la
universidad.
- Una matrícula es válida y podrá ser insertada en la tabla de Matrículas si se ha verificado la
existencia del alumno, si existe la sección y cada uno de los cursos a matricular, así también,
si el alumno tiene nota aprobatoria en cada uno de los cursos que son prerequisito a los de
la matrícula actual. A los controles anteriores se debe agregar el hecho de que el alumno no
esté acumulando mayor cantidad de creditaje de cursos que aquellos que su condición le
permite. La condición del alumno debe estar vigente, es decir; el alumno no ha desaprobado
una asignatura por más de tres veces, en base a lo establecido en el estatuto de la
Universidad.
- En ocasiones, se restringirá la matrícula del alumno cuando el horario de los cursos que
requiere en dicha matrícula se encuentra superpuesto. Finalmente, la Inserción de un nuevo
registro de matrícula en la tabla de Matrículas, sólo será válida en la medida que se cumplan
las condiciones indicadas; si por alguna razón una o más de estas condiciones no se
PROGRAMACIÓN DE BASES DE DATOS Página 234
cumpliera, el sistema automáticamente deberá rechazar la operación de Inserción y mostrar
un mensaje indicando el error cometido.
- De igual manera, se necesitará programar un Trigger para las operaciones de Eliminación de
datos, así por ejemplo, supongamos que se desea eliminar el registro de matrícula de un
estudiante; en este caso no basta con seleccionar el registro y efectuar la eliminación, pues
aquel estudiante puede tener una o más notas o registros de asistencias en el semestre
matriculado, por tanto, las notas y asistencias del alumno también deberían quedar
automáticamente eliminadas o de lo contrario se producirían inconsistencias en la base de
datos.
1.1 ¿Qué ventajas y desventajas se presentan con el uso de Triggers?
A continuación, se analiza algunas ventajas y desventajas:
- Ventajas
- Facilitan los procesos de validación de la integridad de datos y de referencias de datos.
- Se activan en forma automática al insertar, actualizar o eliminar datos de una tabla de
la base de datos.
- Desventajas
- En ocasiones es necesario pedir la ejecución del procesamiento de un trigger, sin
embargo, ello no es posible.
- No es posible el desarrollo de Triggers en tablas temporales.
1.2 Triggers para operaciones DML
Los trigger de operaciones DML, son los más comunes y están asociados al desarrollo de
operaciones de control sobre sentencias Insert, Update y Delete.
Sintaxis
CREATE TRIGGER <<NameTrigger>>
ON [ TABLE | VIEW ]
FOR | AFTER | INSTEAD OF
[ INSERT ] [, ] [ UPDATE ] [, ] [ DELETE ]
AS
Begin
<<Cuerpo de sentencias >>
End
PROGRAMACIÓN DE BASES DE DATOS Página 235
LABORATORIO Nº 12
IMPLEMENTACIÓN DE TRIGGERS
Una compañía operadora de servicios telefónicos requiere la instalación de un sistema de
base de datos para registrar los servicios de mantenimiento, reparación, limpieza, u otro servicio
que los clientes solicitan, para ello se pide elaborar un pequeño sistema de gestión de base de
datos que ayude al control de estas operaciones.
A continuación, se detalla las características de la base de datos y otros objetos necesarios como,
por ejemplo; dominios, valores por defecto, funciones, Triggers entre otros objetos que se
deberá implementar.
1. Elaborar el script de la siguiente base de datos:
- Nombre de la base de datos: BDServicio
- Tablas de base:
CLIENTE (IdCliente, Nombre, TipoCliente, NroDoc)
EMPLEADO (IdEmpleado, Nombre, ApePaterno, ApeMaterno, NroDNI)
USUARIO (IdUsuario, Login, Contraseña)
SERVICIO (IdServicio, Fecha, IdEmpleado, IdCliente, TipoServicio, DetalleServicio)
- Restricciones de Integridad
- El tipoCliente puede ser: ‘N’: Natural, y ‘J’: Jurídico
- Si TipoCliente=’N’; entonces: NroDoc = DNI
- Si TipoCliente=’J’; entonces: NroDoc = RUC
- Implementar un Trigger para que, al ingresar un nuevo empleado, se pueda crear su
respectivo USUARIO; cuyos datos se registrarán teniendo en cuenta lo siguiente:
o Autogenerar el IdUsuario de la tabla USUARIO el cual debe ser igual al NroDNI que
se encuentra en la tabla EMPLEADO.
o Autogenerar el Login del Usuario, de la siguiente manera:
▪ PrimerNombre = Primera palabra del atributo Nombre del Usuario.
▪ Calcular n igual al tamaño del PrimerNombre
▪ Obtener el valor Fibonacci de n.
▪ Login=1ra letra del ApePaterno, (en minúscula)
+ 1ra letra del ApeMaterno + PrimerNombre + Fibonacci(n)
o Cálculo del Fibonacci(n): Sea n, se obtiene Fib(n); así:
PROGRAMACIÓN DE BASES DE DATOS Página 236
n: 1 2 3 4 5 6 7 . . . Fib 1 1 2 3 5 8 13 . . .
1 Si n==1
Fib(n) 1 Si n==2
Fib(n-1)+Fib(n-2) Si n>2
- Ejemplo: Si el Empleado se llama: Nombre=’Javier Fernando’; ApPaterno=’Flores’;
ApeMaterno=’Zegarra’; Entonces:
o PrimerNombre=’Javier’
o Tamaño de PrimerNombre=6
o Fibonacci(6)=8
o Entonces: Login=’fZJavier8’
- Contraseña=’123456’
- En la tabla SERVICIO; IdServicio se autogenera como entero.
- Por defecto, la fecha del servicio es la fecha actual del sistema.
- El TipoServicio puede ser: ‘M’: Mantenimiento, ‘R’: Reparación, ‘L’: Limpieza, ‘O’: Otro
- Solución al caso planteado
- Script para la creación de la base de datos BDServicio:
- Creación de la tabla CLIENTE con restricción de dominio y valor por defecto del atributo
TipoCliente.
PROGRAMACIÓN DE BASES DE DATOS Página 237
- Creación de la tabla USUARIO.
- Creación de la tabla EMPLEADO.
- Creación de la tabla SERVICIO y restricciones de integridad de dominio y valor por defecto
para los atributos Fecha y TipoServicio. También se incluye la integridad referencial con las
tablas EMPLEADO Y CLIENTE.
PROGRAMACIÓN DE BASES DE DATOS Página 238
- Diagrama de la base de datos
- Implementación de la función Fibonacci sobre la base de datos BDServicio.
- Ejecución de la función Fibonacci
PROGRAMACIÓN DE BASES DE DATOS Página 239
- Creación del Trigger para crear la tabla de Usuario a partir del registro de los Empleados.
PROGRAMACIÓN DE BASES DE DATOS Página 240
Actividad Nº 12
La Institución Educativa EduTec requiere la implementación de una base de datos para el
control de las matrículas, con las siguientes consideraciones:
1. Los estudiantes hacen un Diplomado en 3 ciclos de estudios en cada uno de los cuáles
pueden llevar hasta un máximo de 4 cursos. Estos cursos no tienen prerequisitos entre sí.
2. Cuando un nuevo alumno ingresa al programa; el área de Secretaría define su código de
alumno compuesto por un número de 5 cifras cuyos dos primeros dígitos son el año de
ingreso y los 3 restantes es un número correlativo. Asimismo, se definen sus datos
personales; entre los que se destacan: su nombre completo, la especialidad de estudios, el
tipo de admisión; que puede ser: 1. Regular, 2. Traslado Interno, 3. Traslado Externo, 4.
Segunda Especialidad y 5. Reincorporación. Así también se define su categoría de estudios
que puede ser: N. Normal, M. Media Beca, C. Cuarto de Beca B. Beca Integral y E. Especial.
3. Las matrículas se desarrollan teniendo en cuenta el número de vacantes ofrecidas según la
capacidad del aula asignada para el dictado de las clases. La duración de cada ciclo es de 3
meses.
4. Si un alumno desaprueba un curso lo repetirá hasta lograr su aprobación. Si el alumno
aprobó un curso; entonces cualquier matrícula en dicho curso será rechazada
automáticamente. Se debe verificar que el horario de los cursos no se encuentre cruzado.
5. La Institución tiene un registro de los docentes que laboran en ella. El diplomado solamente
será entregado a los estudiantes que acrediten haber aprobado el total de asignaturas del
programa establecido.
6. Implementar las siguientes restricciones de integridad:
- Verificar que el tipo de admisión sea un valor entre 1 y 5. Su valor por defecto es 1.
- El dominio de la Categoría del alumno es: ‘N’, ‘M’, ‘C’,’B’,’E’. El valor por defecto es: ‘N’
- El turno del curso es: ‘M’, ‘T’,’N’. Su valor por defecto es ‘M’.
- El Número de Créditos mínimo es 3 y máximo 6. Su valor por defecto es 3.
7. Implementar un trigger for Insert en la tabla DET_MATRICULAS para controlar:
- Verificar si el NroCuposLibres es mayor a cero; entonces:
• Disminuir en 1 el valor de: NroCuposLibres. Luego, Insertar los datos.
• Si el NroCuposLibres es Menor o Igual a 0; mostrar un mensaje de ERROR y rechazar la
operación de Inserción de datos en la tabla: DET_MATRICULAS.
PROGRAMACIÓN DE BASES DE DATOS Página 241
Autoevaluación 12
1. Verifique si es verdad la siguiente afirmación: “Los Triggers pueden hacer llamadas a
funciones escalares”
A. Verdadero F. Falso C. Ni verdadero, ni falso
2. Son cláusulas que hacen referencia a los datos en movimiento de un trigger:
A. Inserted
B. Deleted
C. Updated
D. A y B
E. Todas las anteriores
3. Las características de un trigger tienen mayor semejanza, con:
A. Las Funciones escalares
B. Las Funciones de Tabla
C. Los Procedimientos almacenados
D. Todas las anteriores
E. Ninguna Anterior
4. Una cláusula UPDATE solamente se puede utilizar en un:
A. Trigger for Update
B. Trigger for Insert
C. Trigger for Delete
D. Cualquiera de las anteriores
E. Ninguna Anterior
5. Indique la verdad o falsedad, en: “T-SQL admite el uso de Triggers anidados”
A. Verdadero B. Falso C: Ni verdadero, ni falso
Página 242
Bibliografía Kimmel, P. (2008). Manual de UML Guía de aprendizaje (2da. ed., Vol. 1). (P. C. Hernán, Trad.)
Santa Fé, Mexico: Mc. Graw Hill Iberoamericana. Recuperado el 04 de 2020
Larman, C. (1999). UML y PATRONES Introducción al Análisis y diseño orientado a objetos (2da.
ed., Vol. 1). (P. E. Vásquez, Ed., & L. M. Rodriguez, Trad.) Ciudad Juárez, México:
Prentice Hall Hispanoamerica S.A. Recuperado el 04 de 2020
Sommerville, I. (2005). Ingeniería del software (7ma. ed., Vol. 1). (M. Martín Romo, Ed., M. I.
Alfonso Galipienso, A. Botía Martínez, F. Mora Lizán, & J. P. Trigueros Jover, Trads.)
Madrid, España: Pearson Addison wesley.
Baum, G., Daniele, M., Martellotto, P. y Novaira, MM (2004). Un modelo genérico para el
modelo de negocio.
https://pdfs.semanticscholar.org/13d0/e1a929963b0f5eb4e5a296f90e450559d841.pdf
Arsaute, A., Daniele, M., Zorzan, F. y Riesco, D. (2010). Transformación del modelo de negocio
al modelo de caso de uso del sistema utilizando QVT.
https://pdfs.semanticscholar.org/6399/badb8f0d613c1980005e79f71809519cf638.pdf
Gómez, M. 2011. Análisis de requerimientos. Mexico D.F. 1ra. Edición.
http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf