ingeniería de datos

243
INGENIERÍA DE DATOS GUÍA DE APRENDIZAJE VIRTUAL DR. LUIS ENRRIQUE BOY CHAVIL DR. JUAN CARLOS OBANDO ROLDÁN

Upload: others

Post on 18-Jul-2022

25 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Ingeniería de datos

INGENIERÍA DE DATOS GUÍA DE APRENDIZAJE VIRTUAL

DR. LUIS ENRRIQUE BOY CHAVIL DR. JUAN CARLOS OBANDO ROLDÁN

Page 2: Ingeniería de datos

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

[email protected]

Page 3: Ingeniería de datos

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

Page 4: Ingeniería de datos

Dedicatoria

Dedico este libro a mi familia, por su paciencia y tanto amor hacia mi persona.

El Autor principal

Page 5: Ingeniería de datos

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.

Page 6: Ingeniería de datos

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

Page 7: Ingeniería de datos

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

Page 8: Ingeniería de datos

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

Page 9: Ingeniería de datos

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

Page 10: Ingeniería de datos

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

Page 11: Ingeniería de datos

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

Page 12: Ingeniería de datos

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.

Page 13: Ingeniería 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.

Page 14: Ingeniería de datos

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,

Page 15: Ingeniería de datos

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:

Page 16: Ingeniería de datos

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

Page 17: Ingeniería de datos

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

Page 18: Ingeniería de datos

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

Page 19: Ingeniería de datos

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

Page 20: Ingeniería de datos

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

Page 21: Ingeniería de datos

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?

Page 22: Ingeniería de datos

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

Page 23: Ingeniería de datos

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

Page 24: Ingeniería de datos

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.

Page 25: Ingeniería de datos

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

Page 26: Ingeniería de datos

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

Page 27: Ingeniería de datos

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

Page 28: Ingeniería de datos

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

Page 29: Ingeniería de datos

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

Page 30: Ingeniería de datos

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.

Page 31: Ingeniería de datos

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.

Page 32: Ingeniería de datos

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.

______________________________________________________________________

______________________________________________________________________

Page 33: Ingeniería de datos

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.

______________________________________________________________________

______________________________________________________________________

Page 34: Ingeniería 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.

Page 35: Ingeniería de datos

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.

______________________________________________________________________

______________________________________________________________________

Page 36: Ingeniería de datos

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

Page 37: Ingeniería de datos

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

Page 38: Ingeniería de datos

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

Page 39: Ingeniería de datos

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.

Page 40: Ingeniería de datos

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

Page 41: Ingeniería de datos

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

Page 42: Ingeniería de datos

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.

Page 43: Ingeniería de datos

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

Page 44: Ingeniería de datos

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

Page 45: Ingeniería de datos

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

Page 46: Ingeniería de datos

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í:

Page 47: Ingeniería de datos

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:

Page 48: Ingeniería de datos

MODELADO DE PROCESOS Página 47

3.8 Hay que hacer clic en los bloques de construcción de Diagramas y Elementos de UML:

Page 49: Ingeniería de datos

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;

Page 50: Ingeniería de datos

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:

Page 51: Ingeniería de datos

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”

Page 52: Ingeniería de datos

MODELADO DE PROCESOS Página 51

4.3 El diagrama de Objetivos del Negocio, es:

Page 53: Ingeniería de datos

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”

Page 54: Ingeniería de datos

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”

Page 55: Ingeniería de datos

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:

Page 56: Ingeniería de datos

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.

Page 57: Ingeniería de datos

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.

Page 58: Ingeniería de datos

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:

Page 59: Ingeniería de datos

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

Page 60: Ingeniería de datos

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:

Page 61: Ingeniería de datos

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:

Page 62: Ingeniería de datos

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

Page 63: Ingeniería de datos

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í:

Page 64: Ingeniería de datos

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:

Page 65: Ingeniería de datos

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í:

Page 66: Ingeniería de datos

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

Page 67: Ingeniería de datos

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í:

Page 68: Ingeniería de datos

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í:

Page 69: Ingeniería de datos

MODELADO DE PROCESOS Página 68

Page 70: Ingeniería de datos

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.

Page 71: Ingeniería 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.

Page 72: Ingeniería de datos

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.

Page 73: Ingeniería de datos

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.

Page 74: Ingeniería de datos

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.

Page 75: Ingeniería de datos

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:

Page 76: Ingeniería de datos

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.

Page 77: Ingeniería de datos

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.

Page 78: Ingeniería 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.

Page 79: Ingeniería de datos

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:

Page 80: Ingeniería de datos

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

Page 81: Ingeniería de datos

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

Page 82: Ingeniería de datos

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

Page 83: Ingeniería de datos

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

Page 84: Ingeniería de datos

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:

Page 85: Ingeniería de datos

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:

Page 86: Ingeniería de datos

MODELADO DE PROCESOS Página 85

Page 87: Ingeniería de datos

MODELADO DE PROCESOS Página 86

2.5 Diagrama de Actividades para Gestionar la Demanda:

Page 88: Ingeniería de datos

MODELADO DE PROCESOS Página 87

2.6 Elaborar el Diagrama de Gestionar el Transporte:

Page 89: Ingeniería de datos

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

Page 90: Ingeniería de datos

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.

Page 91: Ingeniería de datos

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.

Page 92: Ingeniería de datos

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.

Page 93: Ingeniería de datos

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.

Page 94: Ingeniería de datos

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.

Page 95: Ingeniería de datos

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:

Page 96: Ingeniería de datos

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:

Page 97: Ingeniería de datos

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:

Page 98: Ingeniería de datos

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:

Page 99: Ingeniería de datos

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:

Page 100: Ingeniería de datos

MODELADO DE PROCESOS Página 99

9.1 Paquete Seguridad

9.2 Paquete de Reportes

Page 101: Ingeniería de datos

MODELADO DE PROCESOS Página 100

9.3 Paquete de Reutilizables

9.4 Paquete de Gestión del Transporte de Aprovisionamiento

Page 102: Ingeniería de datos

MODELADO DE PROCESOS Página 101

9.5 Paquete de Gestión del Abastecimiento

9.6 Paquete de Gestión de la Demanda

Page 103: Ingeniería de datos

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.

Page 104: Ingeniería de datos

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.

Page 105: Ingeniería de datos

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.

Page 106: Ingeniería de datos

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.

Page 107: Ingeniería de datos

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.

Page 108: Ingeniería de datos

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.

Page 109: Ingeniería 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

Page 110: Ingeniería de datos

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.

Page 111: Ingeniería de datos

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.

Page 112: Ingeniería de datos

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.

Page 113: Ingeniería de datos

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)

Page 114: Ingeniería de datos

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)

Page 115: Ingeniería de datos

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.

Page 116: Ingeniería de datos

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

Page 117: Ingeniería de datos

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.

Page 118: Ingeniería de datos

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:

Page 119: Ingeniería de datos

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:

Page 120: Ingeniería de datos

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:

Page 121: Ingeniería de datos

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

Page 122: Ingeniería de datos

MODELADO DE DATOS Página 121

b) Base de Datos en SQL Server

2. DISEÑO DEL MENÚ PRINCIPAL

Page 123: Ingeniería de datos

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

Page 124: Ingeniería de datos

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:

Page 125: Ingeniería de datos

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

Page 126: Ingeniería de datos

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

Page 127: Ingeniería de datos

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

Page 128: Ingeniería de datos

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

Page 129: Ingeniería de datos

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

Page 130: Ingeniería de datos

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

Page 131: Ingeniería de datos

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

Page 132: Ingeniería de datos

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í:

Page 133: Ingeniería de datos

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:

Page 134: Ingeniería de datos

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.

Page 135: Ingeniería de datos

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

Page 136: Ingeniería de datos

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

Page 137: Ingeniería de datos

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.

Page 138: Ingeniería de datos

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

Page 139: Ingeniería de datos

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)

Page 140: Ingeniería de datos

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:

Page 141: Ingeniería de datos

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.

Page 142: Ingeniería de datos

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.

Page 143: Ingeniería de datos

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)

Page 144: Ingeniería de datos

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.

Page 145: Ingeniería de datos

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:

Page 146: Ingeniería de datos

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:

Page 147: Ingeniería de datos

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

Page 148: Ingeniería de datos

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

Page 149: Ingeniería de datos

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

Page 150: Ingeniería de datos

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.

Page 151: Ingeniería de datos

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

Page 152: Ingeniería de datos

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

Page 153: Ingeniería de datos

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.)

Page 154: Ingeniería de datos

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

Page 155: Ingeniería de datos

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.

Page 156: Ingeniería de datos

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]

Page 157: Ingeniería de datos

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:

Page 158: Ingeniería de datos

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

Page 159: Ingeniería 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.

Page 160: Ingeniería de datos

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:

Page 161: Ingeniería de datos

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:

Page 162: Ingeniería de datos

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:

Page 163: Ingeniería de datos

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:

Page 164: Ingeniería de datos

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>

Page 165: Ingeniería de datos

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

Page 166: Ingeniería de datos

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.

Page 167: Ingeniería de datos

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.

Page 168: Ingeniería de datos

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’

Page 169: Ingeniería de datos

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

Page 170: Ingeniería de datos

MODELADO DE DATOS Página 169

1.4 Creación de la tabla CONTRATO

1.5 Diagrama de la base de datos

Page 171: Ingeniería de datos

MODELADO DE DATOS Página 170

2. Ingreso de datos

Page 172: Ingeniería 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.

Page 173: Ingeniería de datos

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.

Page 174: Ingeniería de datos

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.

Page 175: Ingeniería de datos

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.

Page 176: Ingeniería de datos

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.

Page 177: Ingeniería de datos

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.

Page 178: Ingeniería de datos

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

Page 179: Ingeniería de datos

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.

Page 180: Ingeniería de datos

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í:

Page 181: Ingeniería de datos

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.

Page 182: Ingeniería de datos

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.

Page 183: Ingeniería de datos

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.

Page 184: Ingeniería de datos

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:

Page 185: Ingeniería de datos

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)

Page 186: Ingeniería de datos

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

Page 187: Ingeniería de datos

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)

Page 188: Ingeniería de datos

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.

Page 189: Ingeniería de datos

MODELADO DE DATOS Página 188

2. Diagrama de la base de datos BDBiblioteca

Page 190: Ingeniería de datos

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.

Page 191: Ingeniería de datos

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.

Page 192: Ingeniería de datos

UNIDAD III

Page 193: Ingeniería de datos

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.

Page 194: Ingeniería de datos

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í:

Page 195: Ingeniería de datos

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.

Page 196: Ingeniería de datos

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.

Page 197: Ingeniería de datos

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:

Page 198: Ingeniería de datos

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:

Page 199: Ingeniería de datos

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:

Page 200: Ingeniería de datos

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

Page 201: Ingeniería de datos

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.

Page 202: Ingeniería de datos

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

Page 203: Ingeniería de datos

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.

Page 204: Ingeniería 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.

Page 205: Ingeniería de datos

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.

Page 206: Ingeniería de datos

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.

Page 207: Ingeniería de datos

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.

Page 208: Ingeniería de datos

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:

Page 209: Ingeniería de datos

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

Page 210: Ingeniería de datos

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

Page 211: Ingeniería de datos

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

Page 212: Ingeniería de datos

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"))

Page 213: Ingeniería de datos

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

Page 214: Ingeniería de datos

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:

Page 215: Ingeniería de datos

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.

Page 216: Ingeniería de datos

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

[;]

Page 217: Ingeniería de datos

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.

Page 218: Ingeniería de datos

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)

Page 219: Ingeniería de datos

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

Page 220: Ingeniería de datos

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.

Page 221: Ingeniería de datos

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.

Page 222: Ingeniería de datos

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.

Page 223: Ingeniería de datos

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.

Page 224: Ingeniería de datos

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).

Page 225: Ingeniería de datos

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 )

Page 226: Ingeniería de datos

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'.

Page 227: Ingeniería de datos

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 )

Page 228: Ingeniería de datos

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.

Page 229: Ingeniería de datos

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

Page 230: Ingeniería de datos

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)

Page 231: Ingeniería de datos

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)

Page 232: Ingeniería de datos

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.

Page 233: Ingeniería de datos

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

Page 234: Ingeniería de datos

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

Page 235: Ingeniería de datos

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

Page 236: Ingeniería de datos

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í:

Page 237: Ingeniería de datos

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.

Page 238: Ingeniería de datos

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.

Page 239: Ingeniería de datos

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

Page 240: Ingeniería de datos

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.

Page 241: Ingeniería de datos

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.

Page 242: Ingeniería de datos

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

Page 243: Ingeniería de datos

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