APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA CONSTRUCCIÓN DE BASES DE DATOS...

UNIVERSIDADALASPERUANAS

VICERRECTORADO DE INVESTIGACIÓN Y POSTGRADO

TESIS

APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA

EN LA CONSTRUCCIÓN DE BASES DE DATOS RELACIONALES POR

PARTE DE LOS ALUMNOS DEL V CICLO DE LA ESCUELA

PROFESIONAL DE INGENIERÍA INFORMÁTICA DE LA FACULTAD DE

INGENIERÍA INDUSTRIAL, SISTEMAS E INFORMÁTICA DE LA

UNIVERSIDAD NACIONAL JOSÉ FAUSTINO SÁNCHEZ CARRIÓN -

HUACHO-2012

PARA OPTAR EL GRADO ACADÉMICO DE

MAESTRO EN INGENIERÍA DE SISTEMAS

PRESENTADO POR: BACHILLER EDWIN IVAN FARRO PACIFICO

LIMA − PERÚ

2012

2

DEDICATORIA

Para mi abuelita (Quita) a quien amo mucho,

llevo en mi corazón, y debo lo que he

logrado hasta ahora.

ii

3

AGRADECIMIENTO

A mi familia, enamorada, amigos,

alumnos y al Dr. Roberto Katayama por

su paciencia y disponibilidad para

compartir su conocimiento en el desarrollo

de mi tesis; ya que sin su colaboración no

hubiera sido posible la culminación de mi

Trabajo.

iii

4

RESUMEN

La presente tesis buscar probar de qué forma se puede mejorar la

metodología tradicional de construcción de una base de datos para el

desarrollo de un sistema de información a través de nuevas herramientas

o instrumentos.

El modelo de datos entidad-relación es una metodología que nos permite

construir la base de datos y se divide en tres etapas: el modelo

conceptual, el modelo relacional y el diseño físico.

Debido a la experiencia he podido observar que el participante tiene

problemas de comprensión y elaboración en la construcción de la base de

datos, sin embargo esto podrá superarse con una etapa previa. En la

etapa previa se considera una matriz de procesos, donde se podrán

registrar las actividades en el proceso de negocio a estudiar, los actores

que intervienen, la relación que existe entre ellos y los documentos que

intervienen al inicio, durante y al final de la actividad.

La presente investigación tomó como referencia el curso de base de datos

del V ciclo de la escuela profesional de ingeniería informática de la

Universidad Nacional José Faustino Sánchez Carrión en el periodo lectivo

2012

Luego de haber tomado las muestras, evaluado y analizado los resultados

se llegó a la conclusión que la Matriz de Escenarios influye

positivamente en la optimización de la construcción de la base de datos.

Palabras claves: Base de datos, metodología, sistema de información,

matriz de procesos, modelo conceptual, modelo relaciona, diseño físico.

iv

5

ABSTRACT

This thesis seek to prove that the traditional methodology of building a

database for the development of a computer-based information can be

improved if modified.

The data model is an entity-relationship methodology that allows us to

build the database, the methodology in question passes through three

stages: conceptual model, the relational model and physical design.

Due to the experience I have observed that the participant has difficulty

understanding and development in building the database, however this

can be overcome with a previous stage. In the previous stage is

considered an array of processes, where you can record the activities the

business process to be studied, the actors involved, the relationship that

exists between them and the documents involved in the beginning, during

and after activity .

This research has been conducted on students of the V cycle current

database of the professional school of computer engineering at the

Universidad Nacional José Faustino Sánchez Carrión in the academic

year 2012

After taking the samples, evaluated and analyzed the results concluded

that the matrix process positively influences the optimization of the

construction of the database.

Keywords: Database, methodology, information system, matrix

processes, conceptual model, relational model, physical design.

v

6

ÍNDICE

Pag.

DEDICATORIA 2

AGRADECIMIENTO 3

RESUMEN 4

ABSTRACT 5

INDICE 6

INDICE DE TABLAS 8

INDICE DE GRÁFICOS 11

INDICE DE FIGURAS 13

CAPITULO I PLANEAMIENTO METODOLOGICO

1.1. Descripción de la Realidad Problemática 14

1.2. Delimitación de la Investigación 15

1.3. Formulación del Problema 17

1.3.1. Problema Principal 17

1.3.2. Problemas Secundarios 17

1.4. Objetivos de la Investigación 18

1.4.1. Objetivo principal 18

1.4.2. Objetivos secundario 18

1.5. Hipótesis de la Investigación 19

1.5.1 Hipótesis principal 19

1.5.2 Hipótesis secundarías 19

1.5.3 Identificación de Variables e Indicadores 20

1.6. Diseño de la Investigación 21

1.6.1 Tipo de Investigación 21

1.6.2 Nivel de Investigación 21

1.6.3 Método 22

1.7. Población y Muestra de la Investigación 22

1.7.1 Población 22

1.7.2. Muestra 22

vi

7

1.8. Técnicas e Instrumentos de la Recolección de Datos 23

1.8.1 Técnicas 23

1.8.2 Instrumentos 23

1.9. Justificación e Importancia de la Investigación 24

CAPITULOII MARCO TEORICO

2.1. Antecedentes de la Investigación 26

2.2. Base Teóricas 28

2.3. Definición de Términos Básicos 55

CAPITULO III PRESENTACIÓN, ANALISIS E INTERPRETACIÓN

DE RESULTADOS

3.1. Presentación e interpretación de resultados 64

3.2. Contrastación de hipótesis 76

CONCLUSIONES 107

RECOMENDACIONES 108

FUENTES DE INFORMACIÓN 109

ANEXOS

1. Cuestionario 111

2. Matriz de Consistencia 113

3. Matriz de escenarios 115

4. Proyecto final de base de datos 117

vii

8

ÍNDICE DE TABLAS

Tabla 1. Operacionalización de variables 21

Tabla 2. Ejemplo 41

Tabla 3. Ejemplos de Sistemas de Información de ventas y

marketing 47

Tabla 4. Ejemplos de Sistemas de Información de

manufactura y producción 51

Tabla 5. Ejemplos de Sistemas de Información de finanzas

y contabilidad 53

Tabla 6 Identifica Actividades 64

Tabla 7 Identifica los actores 65

Tabla 8 Identifica los documentos 66

Tabla 9 Relaciona correctamente los actores y actividades 67

Tabla 10 Identifica entidades 68

Tabla 11 Identifica atributos 69

Tabla 12 Establece relaciones entre entidades 70

Tabla 13 Genera nuevas entidades 71

Tabla 14 Agrega los atributos foráneos 72

Tabla 15 Elabora el mapa de instancia 73

Tabla 16 Elabora el diccionario de datos 74

Tabla 17 Influencia de la Matriz de Escenarios en la

construcción de la base de datos 75

viii

9

Tabla 18 Matriz de escenarios en relación a la construcción

de base datos 77

Tabla 19 Pruebas de chi-cuadrado 77

Tabla 20 Tabla de contingencia Identifica actividades - Influencia de la

Matriz de Escenarios en la construcción de la base de datos 79


Tabla 22 Identifica los actores * Influencia de la Matriz de Escenarios en la



Tabla 24 Identifica los documentos * Influencia de la Matriz de Escenarios

en la construcción de la base de datos 83


Tabla 26 Relaciona correctamente los actores y actividades * Influencia

de la Matriz de Escenarios en la construcción de la base de datos 85


Tabla 28 Prueba Matriz de escenarios en relación a la diseño del modelo

conceptual 87


Tabla 30 Relación entre la Identificación de entidades y la Matriz de

Escenarios en la construcción de la base de datos 89


Tabla 32 Relación entre la Identificación de atributos y la Matriz de



ix

10

Tabla 34 Establece relaciones entre entidades y la Matriz de Escenarios



Tabla 36 Matriz de escenarios en relación a la diseño del

modelo relacional 95


Tabla 38 Relación entre la generación de nuevas entidades y la Matriz de



Tabla 40 Relación entre la agregación de los atributos foráneos y la Matriz

de Escenarios en la construcción de la base de datos 99


Tabla 42 Matriz de escenarios en relación al diseño físico 101


Tabla 44 Relación entre la elaboración del mapa de instancia y la Matriz



Tabla 46 Relación entre la elaboración del diccionario de datos y la Matriz



x

11

ÍNDICE DE GRAFICOS

Gráfico 1. Identifica Actividades 65

Gráfico 2. Identifica los Actores 66

Gráfico 3. Identifica los Documentos 67

Gráfico 4. Relaciona correctamente los actores y actividades 68

Gráfico 5. Identifica Entidades 69

Gráfico 6. Identifica Atributos 70

Gráfico 7. Establece relaciones entre entidades 71

Gráfico 8. Genera nuevas entidades 72

Gráfico 9. Agrega los atributos foráneos 73

Gráfico 10. Elabora el mapa de instancia 74

Gráfico 11. Elabora el diccionario de datos 75

Gráfico 12. Influencia de la Matriz de Escenarios en la


Gráfico 13. Matriz de escenarios en relación a la construcción

de base datos 78

Gráfico 14. Matriz de escenarios en relación identifica actividades 80

Gráfico 15. Matriz de escenarios en relación identifica actores 82

Gráfico 16. Matriz de escenarios en relación identifica

Documentos 84

Gráfico 17. Matriz de escenarios en relación con relaciona correctamente

actores y actividades 86

x

xi

12

Gráfico 18. Matriz de escenarios en relación al diseño del

modelo conceptual 88

Gráfico 19. Relación entre la Identificación de entidades y la Matriz de


Gráfico 20. Relación entre la Identificación de atributos y la Matriz de


Gráfico 21. Establece relaciones entre entidades y la Matriz de Escenarios


Gráfico 22. Matriz de escenarios en relación a la diseño del

modelo relacional 96

Gráfico 23. Relación entre la generación de nuevas entidades y la Matriz


Gráfico 24. Relación entre la agregación de los atributos foráneos y la


Gráfico 25. Matriz de escenarios en relación al diseño físico 102

Gráfico 26. Relación entre la elaboración del mapa de instancia y la Matriz


Gráfico 27. Relación entre la elaboración del diccionario de datos y la


xii

13

ÍNDICE DE FIGURAS

Figura 1. Metodología de diseño de bases de datos 33

Figura 2. Proceso de Modelización Conceptual 36

Figura 3. Ejemplo de un sistema de información de ventas 49

Figura 4. Esquema de un sistema de inventario 51

Figura 5. Sistema de cuentas por cobrar 54

xiii

14

CAPÍTULO I

PLANTEAMIENTO METODOLOGICO

1.1. Descripción de la realidad problemática

Se ha podido constatar que los alumnos pertenecientes al curso de

Base de Datos del V ciclo de la Escuela Profesional de Ingeniería

Informática - Facultad de Ingeniería Industrial, sistemas e informática

de la Universidad Nacional José Faustino Sánchez Carrión de

Huacho tienen dificultades al momento de diseñar y construir una

base de datos, principalmente en el entendimiento del proceso de

negocios, punto vital para el moldeamiento de la base de datos en

sus etapas conceptual, relacional y física.

El curso de Base de Datos, pretende ofrecer a los alumnos los

conocimientos y destrezas necesarias que le permitirán Crear,

Mantener y Gestionar los objetos de una Base de Datos, así como

también, conocer su Arquitectura y su Funcionamiento.

15

Uno de los principales problemas encontrados es en lo referido a la

metodología de enseñanza del curso, donde los docentes

encargados del curso de base de datos, emplean una metodología

tradicional en la cual orientan a los alumnos a una interpretación

personal de la realidad en la etapa del moldeamiento conceptual del

modelo entidad-relación, habiendo la posibilidad de que ésta no sea

la correcta.

Otro de los problemas, es que los docentes no emplean ninguna

estrategia adicional que oriente a los alumnos a la construcción de

matrices y/o herramientas que sistematice cada una de los pasos y

actividades del desarrollo de una base de datos, que ayude en la

identificación de las entidades, atributos y relaciones entre las

entidades, y asimismo que brinde la facilidad de desarrollar el

modelo relacional para determinar las nuevas entidades si las

hubiera y/o agregar los atributos necesarios, hecho que permite

viabilizar el desarrollo del diseño físico para la creación del mapa de

instancia y diccionario de datos.

Estos problemas traerán como consecuencia que el alumno no se

encontrará en la capacidad de analizar datos y efectuar

recomendaciones concernientes a mejorar el rendimiento y la

eficiencia de los datos que se encuentran almacenados, apoyar en el

diseño y optimización de modelos de datos.

1.2. Delimitación de la investigación

1.2.1. Delimitación espacial

La presente investigación se realizó en la Escuela Profesional de

Ingeniería Informática de la Facultad de Ingeniería Industrial,

Sistemas e Informática de la Universidad Nacional José Faustino

Sánchez Carrión de Huacho.

16

1.2.2. Delimitación temporal

El desarrollo de la presente investigación se llevó a cabo entre los

meses de enero a octubre del 2012 y consta de dos fases:

PRIMERA FASE

Durante este tiempo se dio cumplimiento a todas las etapas

necesarias en el trabajo de investigación científica, es decir se

realizó una formulación y generalización del problema, el cual se

basa en la descripción de la realidad problemática, delimitaciones y

definición del problema, objetivos de la investigación, justificación e

importancia, estudio de viabilidad, etc., además del cronograma de

actividades, presupuesto, marco teórico, etc., así como la

correspondiente aprobación del proyecto de investigación.

SEGUNDA FASE

Durante este tiempo se llevó a cabo el análisis e interpretación de

los resultados, la contrastación de la hipótesis, las conclusiones,

las recomendaciones y la presentación del informe final, para luego

hacer el respectivo sustento del trabajo de investigación que se

realizó, durante la primera fase.

1.2.3. Delimitación social

La tesis se orientó al estudio de la población de alumnos del curso

de base de datos de la Escuela Profesional de Ingeniería

Informática de la Facultad de Ingeniería Industrial, Sistemas e

Informática de la Universidad Nacional José Faustino Sánchez

Carrión

17

1.3. Formulación del problema

1.3.1. Problema principal

¿De qué forma la aplicación de una Matriz de Escenarios influye en

la construcción de Base de Datos Relacional por parte de los

alumnos del V ciclo de la Escuela Profesional de Ingeniería

Informática de la Facultad de Ingeniería Industrial, Sistemas e

Informática de la Universidad Nacional José Faustino Sánchez

Carrión de Huacho-2012?

1.3.2. Problemas secundarios

a) ¿Cómo influye el uso de una Matriz de Escenarios en el

desarrollo del modelo conceptual en los alumnos del V ciclo

de la Escuela Profesional de Ingeniería Informática de la

Facultad de Ingeniería Industrial, Sistemas e Informática de

la Universidad Nacional José Faustino Sánchez Carrión de

Huacho-2012?

b) ¿Cómo influye el uso de una Matriz de Escenarios en el

desarrollo del modelo relacional en los alumnos del V ciclo




Huacho-2012?

c) ¿Cómo influye el uso de una Matriz de Escenarios en el

desarrollo del diseño físico en los alumnos del V ciclo de la

Escuela Profesional de Ingeniería Informática de la Facultad

de Ingeniería Industrial, Sistemas e Informática de la

Universidad Nacional José Faustino Sánchez Carrión de

Huacho-2012?

18

1.4. Objetivos de la investigación

1.4.1. Objetivo principal

Determinar en qué medida la aplicación de una Matriz de

Escenarios influye en la construcción de Base de Datos Relacional

por parte de los alumnos del V ciclo de la Escuela Profesional de



Sánchez Carrión de Huacho-2012.

1.4.2. Objetivos secundarios

a) Determinar en qué medida el uso de una Matriz de

Escenarios influye en el desarrollo del modelo conceptual en

los alumnos del V ciclo de la Escuela Profesional de


Sistemas e Informática de la Universidad Nacional José

Faustino Sánchez Carrión de Huacho-2012.

b) Determinar en qué medida el uso de una Matriz de

Escenarios influye en el desarrollo del modelo relacional en





c) Determinar en qué medida el uso de una Matriz de

Escenarios influye en el desarrollo del diseño físico en los

alumnos del V ciclo de la Escuela Profesional de Ingeniería

Informática de la Facultad de Ingeniería Industrial, Sistemas

e Informática de la Universidad Nacional José Faustino


19

1.5. Hipótesis de la investigación

1.5.1. Hipótesis principal

La aplicación de una Matriz de Escenarios influye

significativamente en la construcción de Base de Datos Relacional

por parte de los alumnos del V ciclo de la Escuela Profesional de




1.5.2. Hipótesis secundarias

a) El uso de una Matriz de Escenarios influye

significativamente en el desarrollo del modelo conceptual en





b) El uso de una Matriz de Escenarios influye

significativamente en el desarrollo del modelo relacional en





c) El uso de una Matriz de Escenario influye significativamente

en el desarrollo del diseño físico en los alumnos del V ciclo




Huacho-2012.

20

1.5.3. Identificación de variables e indicadores

Definición conceptual de las variables

a) Variable independiente: Matriz de Escenarios

Es una herramienta para el desarrollo de base de datos que

permite la identificación rápida de las actividades principales

del proceso de negocio, actores, documentos, el área donde

se realiza la actividad, las entidades y la interrelación entre

ellas.

b) Variable dependiente: construcción de la base de datos

La construcción de la base de datos tiene como objetivo

general ayudar a una organización en el logro de sus metas,

a través del almacenamiento y procesamiento de un

conjunto de información capaz de ayudar en la correcta toma

de decisiones.

La importancia de la construcción de la base de datos radica

en que permite una orientación metódica y una coordinación

adecuada de los recursos disponibles, identificación más

rápida de los problemas y evaluación cuantitativa de los

resultados

21

Operacionalización de variables

Tabla 1. Operacionalización de variables

VARIABLES DIMENSIONES INDICADORES

Variable independiente Matriz de Escenarios

Áreas

Área actividades Área de actores Área de objetos Área de relaciones de actores y actividades

Variable dependiente: Construcción de la Base de Datos

Modelo Conceptual Identifica entidades Identifica atributos Establece relaciones entre actividades

Modelo Relacional Genera nuevas entidades Genera nuevos atributos

Diseño Físico Crea mapa de instancia Crea diccionario de datos

Fuente: Ing. Edwin Farro Pacífico

1.6. Diseño de la investigación

1.6.1. Tipo de investigación

De acuerdo al propósito de la investigación, de la

problemática y del objetivo formulado, el tipo de

investigación será aplicada, debido a que se caracteriza

porque busca la aplicación o utilización de los conocimientos

que se adquieren, también porque se encuentra

estrechamente vinculada con la investigación básica, pues

depende de los resultados y avances tecnológicos; por lo

que toda investigación aplicada requiere de un marco

teórico. Además su propósito fundamental es dar solución a

problemas prácticos.

1.6.2. Nivel de investigación

El nivel del presente estudio es correlacional, porque se

buscó medir las variables: Matriz de Escenarios y

22

construcción de base de datos, estableciendo su grado de

relación.

El nivel del presente estudio es correlacional, porque se

buscó medir las variables: matriz de procesos y construcción

de base de datos, estableciendo su grado de relación.

Asimismo, es de diseño No experimental de carácter

transeccional ya que se recolectaron los datos, en un tiempo

único con el propósito de describir las variables, y analizar

su interrelación en un momento dado.

1.6.3. Método

Es Inductivo-comparativo porque se parte de la observación

de hechos, se generaliza y luego se comparan los

resultados.

1.7. Población y muestra de la investigación

1.7.1. Población

La población está conformada por todos los alumnos que se

encuentran matriculados en el curso de Base de Datos del V

ciclo de la Escuela Profesional de Ingeniería Informática de la

Facultad de Ingeniería Industrial, Sistemas e Informática de la

Universidad Nacional José Faustino Sánchez Carrión de

Huacho, conformada por 19 alumnos.

1.7.2. Muestra

Debido a que la población es pequeña se ha tomado como

muestra a todos los alumnos que se encuentran matriculados

en el curso de Base de Datos del V ciclo de la Escuela

23

Profesional de Ingeniería Informática de la Facultad de

Ingeniería Industrial, dicha cantidad está conformada por 19

alumnos.

1.8. Técnicas e Instrumentos de Recolección de Datos

1.8.1. Técnicas

Las técnicas que se emplearon para realizar el trabajo de

investigación fueron:

Entrevistas

Encuestas

Observación

1.8.2. Instrumentos

El instrumento que se empleó es un cuestionario con un

formato estructurado que se le entregará al informante para

que éste de manera anónima, por escrito, consigne por sí

mismo las respuestas

Para tal efecto se invocó al personal de alumnos encuestado

responder con la mayor objetividad, así como de la importancia

que tenía el responder con la mayor seriedad a los ítems del

cuestionario.

Se eligió la siguiente escala de puntuación (siempre-algunas

veces-pocas veces) por tener relación directa con la hipótesis,

ayudándonos a operacionalizar las variables a través de las

técnicas estadísticas y demostrar si hay relación entre las

variables.

24

1.9. Justificación e importancia de la investigación

1.9.1. Justificación

Las bases de datos son utilizadas como solución, o como

soporte a la solución de la mayor parte de los problemas que

se presentan en el mundo real. Por ello, el conocimiento de la

metodología es de suma importancia.

Se debe tomar en cuenta que la construcción de la base de

datos se debe realizar en forma correcta y en el menor tiempo

posible. Es por ello que se agregó la matriz de procesos, como

una etapa previa al modelamiento.

Por parte del alumno habrá una mejor comprensión, ya que

podrá plasmar en la matriz las actividades, los actores,

documentos y las relaciones entre los actores y documentos.

Por parte del docente, la matriz le permitirá explicar más

fácilmente las demás etapas, así como la identificación rápida

de los elementos necesarios para realizar el modelamiento de

la base de datos.

1.9.2. Importancia

La presente investigación es importante ya que los resultados

contribuirán a elevar y optimizar en los alumnos su nivel de

comprensión del proceso de negocio en la etapa previa al

modelo conceptual, redundando significativamente en la

construcción integral de la base de datos, asimismo permitirá

reducir el tiempo empleado, reducir errores y lograr la eficiencia

de este proceso.

Por el lado docente permitirá el logro de los objetivos del

aprendizaje por parte de los alumnos y la adquisición de nuevas

25

competencias y capacidades más eficiente y eficaces para la

aplicación de sus estrategias didácticas.

Asimismo, los resultados de esta investigación, servirá como

antecedentes para nuevas investigación que traten sobre

herramientas que optimices el desarrollo de base de datos.

26

CAPÍTULO II

MARCO TEÓRICO

2.1. Antecedentes de la investigación

Con relación a la temática estudiada, se ha procedido a investigar

las publicaciones existentes, consultando fuentes de información

primaria, secundaria y terciarias. Al respecto, se encontraron las

siguientes investigaciones:

Rubén Roberto Mellado Flores (2002), “El DataMart en una

empresa industrial del sector público”

El trabajo demuestra que con el uso de las TI se puede obtener

ventaja competitiva, utilizando como tecnología el Datamart.

En la investigación primero se plantea una metodología de

implementación, para luego desarrollar un prototipo de Datamart en

el área comercial de CIDELSA, empresa del sector industrial

plástico.

27

Posteriormente en la etapa de implementación se propone el

diagnóstico de la organización a través de la curva de Nolan y los

tipos de sistemas de soporte de decisiones.

La conclusión de este diagnóstico fue que CIDELSA como una

opción estratégica para obtener ventaja competitiva, debe

implementar un SI de ayuda a las decisiones si es que quiere

conservar su mercado actual y mejorar su participación en el mismo.

Werner Frien Cabezas Espinoza (2007), “Sistema distribuido para

la gestión del conocimiento inmerso en la web”

El objetivo principal de este trabajo de investigación es conseguir

una gestión sobre el conocimiento de una comunidad de usuarios

como resultado de las interacciones de los componentes de dicha

comunidad.

El sistema permite la construcción de sitios web, de tal manera que

se puede obtener un conocimiento relevante y de calidad del área o

tema de nuestro interés, sin la necesidad del trabajo de un

moderador o editor.

El sistema, ha sido probado en diferentes empresas e instituciones

del estado peruano. Las experiencias nos dan evidencia de que el

sistema es útil para motivar a comunidades de usuarios a que

aporten estructura a la web para construir un repositorio activo de

conocimiento de calidad en el área de su interés.

Se concluyó que la gestión del conocimiento debe ser entendida

como la instancia de gestión mediante el cual se obtiene y despliega

o utiliza una variedad de recursos básicos para apoyar el desarrollo

del conocimiento dentro de las empresas e instituciones. Es por ello

que entender como estructurar las iniciativas de gestión del

conocimiento generará una ventaja a la hora de considerar el

conocimiento dentro de la estrategia de la organización.

28

Jorge Víctor Mayhuasca Guerra, “Gestión de la información y

sistemas distribuidos para mejorar la calidad de servicios de

universidades”.

El objetivo es mejorar el desarrollo de las actividades y procesos de

sistemas de información que involucran a la gestión administrativa,

aplicando la metodología de la gestión de información y sistemas

distribuidos; a fin de optimizar los tiempos de respuesta al

requerimiento de información por la alta dirección. Se concluye que

la correcta aplicación de la tecnología de información en una

organización ofrecerá grandes beneficios al interior de éstas

transformándolas en entidades competitivas y generadoras de

recursos. En el caso nuestro estas herramientas nos permite el

mejoramiento continuo de nuestros servicios.

2.2. Bases teóricas

2.2.1. Base de datos

Según Luque, Irene1 (2002), el término de Bases de Datos no

apareció hasta mediados de los años sesenta, época en la cual

la información era representada haciendo uso de un conjunto

de archivos, generalmente planos. Estos archivos no estaban

relacionados entre sí, y los datos almacenados representaban

las relaciones existentes en la información que representaban

mediante referencias simbólicas y/o físicas. La redundancia era

grande y la integridad de la información representada dejaba

mucho que desear.

Aun así, muchos desarrolladores de software bautizaban a sus

sistemas de archivos como Bases de Datos, sin preocuparse de

1Luque, I., Gómez, M., López, N. &Cerruela, G. (2002). Bases de Datos desde Chen hasta Codd con

Oracle. México, pp 1-22

29

que cumplieran o no una serie de propiedades que deben

acompañar al uso de este término.

Para que se denomine a una base de datos como tal, debe

satisfacer una serie de propiedades, a las cuales fueron

incorporándose a estos sistemas a medida que el software para

la administración de la información que se desarrolló fue siendo

más eficaz. Hay que tener en cuenta que, hoy en día, no todas

las bases de datos satisfacen estas propiedades ideales, por lo

que el analista de sistemas se ve obligado a una armonización

de las cualidades deseables de una base de datos, a menudo

contrapuestas.

Los procedimientos y estructuras para el almacenamiento y

mantenimiento de la información correspondientes a un

determinado dominio de un problema han evolucionado a

medida que lo ha hecho la tecnología. Inicialmente los

dispositivos de almacenamiento sólo permitían un acceso serial

a la información, por lo que las estructuras de datos, mediante

las que se podía representar la información, debían ser muy

simples (archivos con organización de apilo o secuenciales) y

los procedimientos de acceso a esta información requerían un

alto tiempo de cómputo puesto que eran puramente seriales.

Además, los procedimientos encargados del mantenimiento

dela información eran totalmente dependientes del hardware

encargado utilizado para ello, lo que suponía una continua

modificación del software encargado de esta tarea cuando el

hardware cambiaba.

Con la aparición de los dispositivos de almacenamiento que

permitían el acceso directo, generalmente denominado

aleatorio, las estructuras mediante las cuales se podía

representar la información se fueron haciendo más complejas.

En esta época se desarrollaron procedimientos de acceso

30

directo a la información, si bien seguían siendo estos

procedimientos los encargados de describir la estructura cambia

debido a cualquiera de las múltiples razones posibles (cambios

en los requisitos del cliente del sistema o cambios en el entorno

del sistema, lo que puede suponer la modificación de la

estructura de los registros que se almacenan en los archivos),

los procedimientos debían ser modificados para reconocer la

nueva estructura de la información. En esta época, aunque el

almacenamiento de la información sí era independiente del

dispositivo hardware utilizado, la estructura de la información no

era independiente de los procedimientos que la manejaban.

Como los sistemas son dinámicos, los requisitos cambian con el

tiempo, la información a ser tratada en cada problema también

cambia y, por lo tanto, es necesario, de alguna manera,

independizar la estructura de la información(los archivos

encargados de almacenarla) de los procedimientos encargados

de su tratamiento, si no se estaría siempre abocado a la

dedicación de una gran cantidad de esfuerzo a la modificación

de todos aquellos procedimientos encargados del

mantenimiento de la información2.

Cuando se reconoce que los sistemas evolucionan y que, por lo

tanto, la información y la estructura de la misma no son

estáticas sino que va cambiando con el tiempo, es cuando

aparece el concepto de las Bases de Datos. Si se desea que

cualquier modificación en la calidad, contenido y estructura de

la información que desea mantener acerca de un determinado

problema no afecte a los procedimientos desarrollados

previamente para el mantenimiento de la misma, es necesario

tener en cuanto que existe una independencia de los datos con

respecto a los procedimientos. El software, por lo tanto, debe

2 Osorio, F. (2008). Bases de datos Relacionales Teoría y Práctica. Colombia: edit. ITM. Pág. 18.

31

referenciar los datos al nivel de ítem de datos; es decir, a nivel

de atributo o propiedad de los objetos que forman parte o

intervienen en el problema, y no a nivel de objeto. Así, la

descripción lógica de un registro (un objeto abstracto de interés

procedimental) puede contener, para un procedimiento, ítems

de datos que son distintos a los que aparecen para otro

procedimiento para este mismo registro.

La independencia de los datos con respecto a los

procedimientos supone, como se verá a lo largo de este

capítulo, que la visión conceptual de los datos, tal y como se

perciben de la observación del problema del mundo real, no

tiene por qué ser la misma que la visión física de los mismos, la

estructura de los archivos utilizados para su almacenamiento de

la información sólo “ven” la estructura física de los datos y si

ésta se realiza a nivel de ítem de datos, un cambio en la visión

conceptual no tiene por qué afectar, en principio, a estos

procedimientos.

Esta independencia de la información con respecto a los

procedimientos que la maneja debe satisfacerse a dos niveles

de abstracción para que sea efectiva; por tanto, se habla de:

Independencia lógica de los datos, por la que la modificación

de la representación lógica general del dominio del problema no

afecta a los programas de aplicación que la manipulan, siempre

que esta modificación no elimine ninguno de los ítems de datos

que estos programas requieran.

Independencia física de los datos; por la que la distribución de

los datos en las unidades de almacenamiento y la estructura

física de la información almacenada es independiente de los

cambios de la estructura lógica general de la información y, por

lo tanto, de los procedimientos que manejan la misma.

32

2.2.2. Características de una Base de Datos

Entre las principales características de una de base de datos

podemos mencionar:

Independencia lógica y física de los datos.

Redundancia mínima.

Acceso concurrente por parte de múltiples usuarios.

Integridad de los datos.

Consultas complejas optimizadas.

Seguridad de acceso y auditoría.

Respaldo y recuperación.

Acceso a través de lenguajes de programación estándar.

2.2.3. Metodología para el diseño de una Base de Datos

Esquema conceptual: Descripción de alto nivel del

contenido de información de la base de datos.

Modelo conceptual: Lenguaje que se utiliza para describir

esquemas conceptuales.

Propósito: Obtener un esquema completo que lo exprese

todo.

33

Figura 1. Metodología de diseño de bases de datos

Nota. Tomado de http://www3.uji.es/~mmarques/f47/teoria/tema6.pdf

2.2.4. El Modelo conceptual

El modelado conceptual permite describir, de un modo

totalmente independiente de la implementación, los datos que el

usuario quiere recoger en el sistema. Dependiendo de la

cantidad de información que se desee representar, tendremos

aplicaciones más o menos orientadas a los datos3.

Según Luque, Irene (2002)4, a este nivel son representados los

tipos o clases de objetos como entidades, y sus relaciones

desde un punto de vista estructural. En el nivel conceptual se

representa un modelo del sistema en el que se describen cada

uno de los tipos de objetos o elementos del mismo. Para cada

uno de estos tipos de objetos se describen sus propiedades y el

3 Esperanza, M. (2008). Modelado Conceptual. Escuela Técnica Superior de Ingeniería

Informática. Recuperado de http://www.kybele.etsii.urjc.es/docencia/BD_GIS_M/2012-2013/Material/[BD-2012-2013]Apuntes_ModeladoConceptual.pdf 4 Ibídem 1. Pág. 65

34

dominio o tipo de datos básico en el cual pueden ser medidas,

así como las restricciones o límites de los valores que pueden

presentarse para cada una de estas propiedades. Además, son

descritas las relaciones entre los tipos de objetos, relaciones

jerárquicas o no, apoyándose para ellos en los principios de la

abstracción.

A este nivel se representa el problema tal y como es; es decir,

se representa el mundo real del problema tal y como se percibe,

sin tener en cuenta cómo este problema puede ser

representado para que sea entendido por los programas se

computador.

Un modelo conceptual de un problema o la visón conceptual de

éste, es independiente de los procedimientos manuales o

automatizados que se utilicen o se vayan a utilizar para el

mantenimiento y tratamiento de la información correspondiente

al problema. La visón conceptual sólo es dependiente de:

Las características del problema o sistema que desea

representar.

El detalle de la representación, el cual sí depende de la

parte o partes o globalidad del problema que desea

representar para su posterior tratamiento.

Pero es independiente de las herramientas y mecanismos que

se vayan a utilizar para esa representación y tratamiento.

Etapas del Modelado Conceptual

El modelado conceptual, también denominado diseño

conceptual, puede subdividirse en dos etapas claramente

diferenciadas5:

5 Batini, C., Ceri, S. & Navathe, S. (1994). Diseño Conceptual de Bases de Datos. Un enfoque de

entidades-interrelaciones. Editorial Addison Wesley Iberoamericana. Pág. 16

35

a) Análisis de requisitos

Esta primera etapa, en general común para datos y procesos,

es la etapa de percepción, identificación y descripción de los

fenómenos del mundo real a analizar. En el análisis de

requisitos se ha de responder a la pregunta: “¿Qué

representar?”.

Mediante el estudio de las reglas de una empresa (que proveen

el marco para el análisis del sistema) y de entrevistas a los

usuarios de los diferentes niveles de la organización (que

proveen los detalles sobre los datos) se llega a elaborar un

esquema descriptivo de la realidad. Aunque son varias las

propuestas existentes respecto a la forma de expresar el

esquema descriptivo, en general se utiliza el lenguaje natural

para recoger esta primera información.

Uno de los problemas más importantes con los que nos

enfrentamos en esta etapa es la dificultad de comunicación

entre los usuarios y los analistas. Los problemas que presenta

esta primera especificación se irán solucionando a lo largo del

resto de las etapas de diseño de modo que este primer

esquema percibido se irá refinando hasta llegar a un esquema

más correcto: el esquema conceptual.

b) Etapa de conceptualización

En la etapa de conceptualización se transforma este primer

esquema descriptivo, refinándolo y estructurándolo

adecuadamente. Esta etapa responde a la pregunta:

36

“¿Cómo representar?”. En la Figura 1 se recoge el proceso de

modelado conceptual, distinguiéndose las dos etapas, así como

los distintos procesos que hay que realizar para pasar del

mundo real al esquema descriptivo, y de éste al esquema

conceptual.

Figura 2. Proceso de Modelización Conceptual

En esta etapa de conceptualización se habrá de buscar una

representación normalizada que se apoye en un modelo de

datos que cumpla determinadas propiedades, a saber:

coherencia, plenitud, no redundancia, simplicidad, fidelidad,

etc., para llegar así al denominado esquema conceptual. Un

modelo de datos que cumple tales requisitos es el modelo E/R.

Una característica importante del esquema conceptual es que

no debe describir los aspectos ligados a la implementación, sino

que debe permitir ver la información con todo su contenido

semántico.

En el proceso de modelado conceptual se parte del análisis del

universo del discurso (lo que también podría denominarse

37

realidad empresarial), analizando los listados, pantallas,

normativas, etc. y realizando un conjunto de entrevistas a varios

niveles de la empresa.

Posteriormente se elabora un esquema percibido, expresado en

lenguaje natural, que nos facilita la obtención del esquema

conceptual, esto es, delimita qué entidades, atributos,

interrelaciones y restricciones semánticas vamos a considerar.

Este proceso se realiza de forma iterativa hasta que se

introducen y clasifican todos los objetos del universo del

discurso de forma satisfactoria.

2.2.5. Modelo relacional

Fue ideado por Peter Chen en los años 1976 y 1977 a través de

dos artículos. Se trata de un modelo que sirve para crear

esquemas conceptuales de bases de datos. De hecho es

prácticamente un estándar para crear esta tarea6.

Se le llama modelo E/R e incluso EI (Entidad / Interrelación).

Sus siglas más populares son las E/R por qué sirven para el

inglés y el español.

Inicialmente (en la propuesta de Chen) sólo se incluían los

conceptos de entidad, relación y atributos. Después se

añadieron otras propuestas (atributos compuestos,

generalizaciones,...) que forman el llamado modelo entidad

relación extendido (se conoce con las siglas ERE)

Luque, Irene (2002)7 afirma que, en este nivel se representa el

problema bajo las limitaciones impuestas por la representación

y el tratamiento de la información que se vaya a realizar. Es

6 Piattini, M., Marcos, E., Calero, C. & Vela. B. (2006). Tecnología y Diseño de Bases de Datos.

Madrid, España: Ed. Ra-ma, Pág. 78. 7 Ibídem 1. Pág. 66

38

decir, en este punto se introducen en la representación las

limitaciones o restricciones que imponen los mecanismos y

soportes que se van a utilizar para la representación y

tratamiento de la información del problema.

Está claro que el tratamiento manual de la información

predispone unas restricciones, en cuanto al soporte y forma en

que ésta debe ser almacenada para su posterior tratamiento,

muy diferentes al tratamiento automatizado y mediante un

computador de la información correspondiente al mismo

problema.

Igualmente, es fácil advertir que en función del hardware y

software utilizado para el almacenamiento y tratamiento de esta

información, a la representación del problema se verá afectada

considerablemente. Por ejemplo, el uso de un sistema de

gestión de bases de datos relacionados supone la aplicación de

una serie de reglas para la representación de un determinado

problema del mundo real (red, jerárquico, orientado a objetos,

etc.) o estructuras clásicas de almacenamiento.

Mientras en el nivel conceptual el problema se representa tal y

como es captado desde el mundo real, en el nivel lógico esta

representación es filtrada o alterada para que se adapte a las

limitaciones existentes para llevar a cabo este proceso8. Por

ejemplo, en el nivel conceptual describiremos un árbol tal y

como lo apreciamos en el mundo real, mientras que en el nivel

lógico describiremos el mismo árbol en base a como los datos

que lo representan pueden ser almacenados para su posterior

tratamiento (una imagen, una descripción textual, tabular, etc.)

8 Silvershatz A., Korth, H. & Sudarshan, S.(2006). Fundamentos de Base de Datos. España. pp 18-

19

39

2.2.6. Modelo físico

Luque, Irene (2002)9 afirma que, en este nivel, el principio de

representación del problema está guiado tanto por el soporte

utilizado para su representación como por los métodos o

mecanismos que se van a utilizar para el tratamiento de la

información correspondiente a este.

En este nivel, el problema se representa en la forma en que es

visto por el sistema de representación y tratamiento utilizado, y

no como existe o es visto desde el mundo real. Por ejemplo, si

se quiere acceder posteriormente a la información

correspondiente a los árboles basándose en la ubicación de los

mismos, se deben establecer mecanismos y, por lo tanto,

representar la información de los árboles de forma muy

diferente a cuando se desee acceder a la misma información

basándose en la categoría a clase de árbol, de forma que el

criterio de ubicación o clase facilite el acceso y posterior

tratamiento de la información correspondiente a los árboles.

La visión o representación física de la información

correspondiente a un problema será determinante en el

desempeño del tratamiento de la misma. En los problemas

tratados por programas por programas de computador, la visión

física determina las estructuras utilizadas para el

almacenamiento de la información, al igual que en el

tratamiento manual, la visión física determina los documentos,

sus formatos, compaginación, ubicación y archivos utilizados

para el almacenamiento de la información.

2.2.7. Diccionario de datos

Según Luque, Irene (2002), El diccionario de datos es uno o un

conjunto de archivos que contienen información acerca de los

9 Ibídem 1. Pág. 69

40

datos que pueden ser almacenados en la base de datos. Se

trata de una metabase de datos; es decir, una base de datos

(intencional) que contienen información sobre otra base de

datos (extensional).

En el diccionario de datos se almacenan todas las definiciones

realizadas por el DDL sobre el problema que va ser tratado por

el SGBD y, algunas (las que se deseen) de las realizadas que

va a ser tratado por el SGBD y, algunas (las que se deseen) de

las realizadas por el DML. Así, en el diccionario de datos se

encuentra almacenado:

El esquema lógico de la base de datos

El esquema físico de la base de datos

Los subesquemas de la base de datos

Es decir, la representación de los datos a los tres niveles de

abstracción. Pero además, en el diccionario de datos se

encuentra mucha información almacenada; información

correspondiente con:

Las restricciones de privacidad y acceso a los datos

almacenados en la base de datos. Estas restricciones

han sido definidas haciendo uso del DDL y/o su

sublenguaje, el DCL.

Las reglas, normas o restricciones referentes a la

seguridad de los datos

Otra serie de información que permite garantizar la

integridad de los datos almacenados en la base de

datos.

41

2.2.8. Relación

Silvershatz Abraham, Korth Henry F. (y) Sudarshan S. (2006)10

afirman que, una relación es una asociación entre diferentes

entidades. Por ejemplo, se puede definir una relación que

asocie al cliente López con el préstamo P-15. Esta relación

especifica que López es un cliente con el préstamo número P-

15.

Tabla 2.

Ejemplo

Cliente préstamo

Fuente: Fundamentos de Bases de Datos, Abraham Silberschatz (2006)

Un conjunto de relaciones es un conjunto de relaciones del

mismo tipo. Formalmente, es una relación matemática con

n>=2(posiblemente no distinto) de conjuntos de entidades. Si

E1,E2,…En son conjuntos de entidades, entonces un conjunto

de relaciones R es un subconjunto de:

{(e1,e2,…,en)| E1, e2 E2,…, en En}

Donde (e1, e2,…, en) |es una relación.

10

Silberschatz, A. , Korth, H. & Sudarshan, S. (2003). Fundamentos de bases de datos. Madrid, España: MacGraw-Hill. Pág. 25

Cliente

Santos 32112312 Mayor Peguerinos

Gómez 19283746 Carreteras Cerceda

López 67789901 Mayor Peguerinos

Sotoca 12345678 Real Cádiz

Pérez 55555555 Carreteras Cerceda

Valdivieso 96396396 Goya Vigo

Fernández 33557799 Jazmin León

Préstamo

P-17 200,000

P-23 400,000

P-15 300,000

P-14 300,000

P-93 100,000

P-11 180,000

P-16 260,000

42

Considérense las dos entidades cliente y préstamo de la figura.

Se define el conjunto de relaciones prestatario para denotar la

asociación entre clientes y préstamos bancarios que los clientes

tengan. Esta asociación se describe la figura.

Como otro ejemplo, considérense los dos conjuntos de

entidades préstamo y sucursal. Se puede definir el conjunto de

relaciones sucursal-préstamo para denotar la asociación entre

un préstamo bancario y la sucursal en que se mantiene ese

préstamo.

La asociación entre conjunto de entidades se referencia como

participación; es decir, los conjuntos de entidades E1,E2,…,En

participan en el conjunto de relaciones R. un ejemplar de

relación en un esquema E-R representa que existe una

asociación entre las llamadas entidades en el desarrollo del

mundo real que se modela. Como ilustración, el cliente

individual López, que tienen DNI 67789901, y la entidad

préstamo P-15 participan en un ejemplar de relación de

prestatario. Este ejemplar de relación representa que, en el

mundo real, la persona llamada López cuyo número de DNI es

67789901 ha tomado un préstamo que está numerado como P-

15.

La función que desempeña una entidad en una relación se

llama papel de la entidad. Debido a que los conjuntos de

entidades que participan en un conjunto de relaciones son

generalmente distintos, los papeles están implícitos y no se

especifican normalmente. Sin embargo, son útiles cuando el

significado de una relación necesita aclaración. Tal es el caso

cuando los conjuntos de entidades de una relación no son

distintos; es decir, el mismo conjunto de entidades participa en

una relación más de una vez con diferentes papeles. En este

tipo de conjunto de relaciones, que se llama algunas veces

43

conjunto de relaciones recursivo, es necesario hacer explícitos

los papeles para especificar cómo participa una entidad en un

ejemplar de relación. Por ejemplo, considérese un conjunto de

entidades empleado que almacena información acerca de todos

los empleados del banco. Se puede tener un conjunto de

relaciones trabaja-para que se modela mediante pares

ordenados de entidades empleado. El primer empleado de un

par toma el papel de jefe, mientras el segundo toma el papel de

trabajador. De esta manera, todas las relaciones trabaja-para

son pares (jefe-trabajador); los pares (trabajador, jefe) están

excluidos.

Una relación puede también tener atributos descriptivos.

Considérese un conjunto de relaciones impositor con conjuntos

de entidades cliente y cuenta. Se podría el atributo fecha-

acceso a esta relación para especificar la fecha más reciente en

que un cliente accedió a una cuenta. La relación impositor entre

las entidades correspondientes al cliente García y la cuenta C-

217 se describen mediante {(fecha-acceso, 23 de mayo 1996)},

lo que significa que la última vez que García accedió a la cuenta

C-217 fue el 23 de mayo de 1996.

Los conjuntos de relaciones prestatarios y sucursal-

préstamo proporcionan un ejemplo de un conjunto de

relaciones binarias; es decir, uno que implica dos conjuntos

de entidades. La mayoría de los conjuntos de relaciones en

un sistema de bases de datos con binarios. Ocasionalmente,

sin embargo, los conjuntos de relaciones implican más de

dos conjuntos de entidades. Por ejemplo, se podrían

combinar los conjuntos de entidades prestatarias y sucursal-

préstamo para formar un conjunto de relaciones ternario

CPS entre los conjuntos de entidades cliente (C), préstamo

(P) y sucursal (S). así, la relación ternaria entre las entidades

44

correspondientes al cliente López, préstamo P-15 y sucursal

Navacerreda, específica que el cliente López tienen el

préstamo P-15 en la sucursal Navacerreda. El número de

conjuntos de entidades que participan en un conjunto de

relaciones es también el grado del conjunto de relaciones es

también el grado del conjunto de relaciones. Un conjunto de

relaciones binario tiene grado11; un conjunto de relaciones

ternario tienen grado 3.

2.2.9. Sistemas de Información

Un sistema de información se puede definir desde el punto

de vista técnico como un conjunto de componentes

interrelacionados que re12colectan (o recuperan), procesan,

almacenan y distribuyen información para apoyar la toma de

decisiones y el control en una organización. Además, los

sistemas de información también pueden ayudar a los

gerentes y los trabajadores a analizar problemas, visualizar

asuntos complejos y crear nuevos productos.

Los sistemas de información contienen información acerca

de las personas, lugares y cosas importantes dentro de la

organización o del entorno en que se desenvuelve.

Por información se entienden los datos que se han

moldeado en una forma significativa y útil para los seres

humanos. En contraste, los datos son secuencias de hechos

en bruto que representan eventos que ocurren en las

organizaciones o en el entorno físico antes de ser

11

García, V. (2008). Conjunto de Relaciones. Recuperado de http://www.victorgarcia.org/pfc/modeloER/relaciones.php 12

Kenneth C. Laudon, Jane P. Laudon, (2008). Sistemas de Información Gerencial. Madrid, España: MacGraw-Hill. Pág. 14,45-51

45

organizados y ordenados en una forma que las personas

puedan entender y utilizar de manera efectiva.

Un breve ejemplo que contrasta la información y los datos

ilustra la diferencia entre ambos. Las cajas de los

supermercados registran millones de piezas de datos, como

los códigos de barras que describen el producto. Dichos

datos se pueden totalizar y analizar para dar una información

significativa como el total de botellas de detergente para

trastes vendidas en una tienda en particular, qué marcas de

detergente para trastes se vendieron más rápidamente en

esa tienda o área de ventas, o la cantidad total de esa marca

de detergente para trastes vendida en esa tienda o región

Hay tres actividades en un sistema de información que

producen la información que esas organizaciones necesitan

para tomar decisiones, controlar operaciones, analizar

problemas y crear nuevos productos o servicios. Estas

actividades son entrada, procesamiento y salida

Tipos de Sistemas de Información Empresarial

Puesto que un negocio puede contar con decenas o incluso

centenas de diferentes procesos de negocios, y como hay

distintas personas, especialidades y niveles en una

organización, hay diferentes tipos de sistemas. Ningún

sistema por sí solo puede proporcionar toda la información

que requiere una organización.

De hecho, las empresas grandes y medianas tienen miles de

programas de cómputo y cientos de sistemas distintos.

Incluso las pequeñas empresas tienen un conjunto de

sistemas diferentes: uno para realizar campañas de correo

electrónico para los clientes, otro para supervisar los

anuncios publicados en Google, uno más para dar

46

seguimiento a las transacciones de ventas básicas, otro para

mantenerse al tanto de los distribuidores, etc. A primera vista

puede resultar complicado entender todos los distintos

sistemas de una empresa y, más difícil aún, comprender

cómo se interrelacionan.

Describiremos esta compleja situación teniendo presentes

estos diversos sistemas desde dos perspectivas: una

funcional que identifica los sistemas por sus principales

funciones empresariales y otra por parte de los usuarios, que

identifica los sistemas en términos de los principales grupos

de la organización a que dan servicio.

Los Sistemas desde una Perspectiva Funcional

Empezaremos por describir los sistemas desde la

perspectiva funcional, porque ésta es la manera más

probable en que los encontrará por primera vez en una

empresa. Por ejemplo, si usted tiene una licenciatura en

marketing y encuentra un trabajo en esta área,

probablemente trabajará primero con un sistema de

información de marketing. Si usted es licenciado en

contabilidad, primero trabajará con sistemas contables y

financieros. Desde una perspectiva histórica, los sistemas

funcionales fueron los primeros tipos de sistemas que

desarrollaron las empresas. Estos sistemas se establecieron

en departamentos específicos como contabilidad, marketing

y ventas, producción y recursos humanos. A continuación

analizaremos en detalle los sistemas desde esta perspectiva

funcional

47

Tabla 3.

Ejemplos de Sistemas de Información de ventas y marketing

SISTEMA DESCRIPCION GRUPOS A QUE SIRVE

Procesamiento de pedidos

Captura, procesa y da seguimiento a los pedidos

Gerencia y empleados de operaciones

Análisis de fijación de precios

Determina precio de productos y servicios

Gerencia intermedia

Pronóstico de las tendencias de ventas

Prepara pronósticos de ventas para cinco años

Alta dirección

Sistemas de ventas y marketing

La función de ventas y marketing es vender los productos o

servicios de la organización.

A marketing le corresponde identificar los clientes para los

productos o servicios de la empresa, determinar qué

necesitan o desean, planear productos y servicios para

satisfacer sus necesidades, así como anunciar y promover

estos productos y servicios. A ventas le atañe contactar

clientes, vender los productos y servicios, tomar pedidos y

llevar el registro de las ventas. Estas actividades se pueden

considerar como procesos de negocios. Los sistemas de

información de ventas y marketing dan apoyo a estos

procesos de negocios.

La tabla 3 muestra que los sistemas de información se

utilizan de diversas maneras en las áreas de ventas y

marketing. Los sistemas de ventas y marketing ayudan a

que los directores vigilen las tendencias que afectan a los

productos nuevos ya las oportunidades de ventas, apoyen la

planeación de nuevos productos y servicios y vigilen el

desempeño de sus competidores. Los sistemas de ventas y

marketing apoyan a la gerencia intermedia en la

48

investigación de mercados y el análisis de las campañas

publicitarias y promocionales, decisiones de fijación de

precios yel desempeño de las ventas. Los sistemas de

ventas y marketing auxilian a los gerentes y empleados

operativos en la localización y contacto de clientes

potenciales, el seguimiento de las ventas, el procesamiento

de pedidos y apoyo en el servicio a clientes. La figura 2

ilustra un sistema de información de ventas utilizado por

empresas minoristas como The Gap o Thrget. Dispositivos

en el punto de venta (por lo general, escáneres manuales en

las cajas registradoras) capturan los datos de cada artículo

vendido, con lo cual se actualizan las cifras en el sistema de

ventas y se envían datos sobre estas ventas a los sistemas

relacionados que controlan los artículos restantes en

inventario y la producción. Estas empresas utilizan esta

información para saber qué artículos se han vendido,

determinar los ingresos de las ventas e identificarlos

artículos más vendidos y otras tendencias de ventas.

Sistemas de manufactura y producción

La función de manufactura y producción es producir los

bienes y servicios de la empresa. Los sistemas de

manufactura y producción están relacionados con la

planeación, el desarrollo y el mantenimiento de las

instalaciones de producción; el establecimiento de las metas

de producción; la adquisición, almacenamiento y

disponibilidad de los materiales de producción, así como la

programación de equipo, instalaciones, materiales y mano

de obra requeridos para obtener productos terminados. Los

sistemas de información de manufactura y producción

apoyan estas actividades.

49

La tabla 4 muestra algunos sistemas de información de

manufactura y producción para cada grupo principal de la

organización. La Alta dirección utiliza sistemas de

manufactura y producción que se encargan de las metas de

manufactura a largo plazo de la empresa como dónde

instalar nuevas plantas, o si es necesario invertir en nueva

tecnología de manufactura. Los sistemas de manufactura y

producción para la Gerencia intermedia analizan y vigilan los

costos y recursos de manufactura y producción.

Figura 3. Ejemplo de un sistema de información de ventas

Datos de ventas A los sistemas de inventario y producción

Sistema de ventas

Archivo

de ventas Informes para la

administración

Elementos de base de un archivo de ventas: Número de tienda Número de artículo Descripción del artículo Color Tamaño Precio unitario Unidades vendidas Fecha Consultas en línea

Informe de ventas: Semana al 2/7/07 Artículo

Num Descripción Color Tamaño

Precio Unitario

Unidades Vendidas

Ventas Totales

294 Maleta deportiva Negra Chica 10.00 10,451 $ 104,510 295 Maleta deportiva Negra Mediana 20.00 21,800 $ 436,000 394 Maleta deportiva Roja Chica 10.00 5,331 $ 53,310

Este sistema captura datos de ventas en el momento que se realiza la venta para

ayudar a la empresa a monitorear las transacciones de ventas y ofrecer

información que ayude a los gerentes a analizar las tendencias de ventas y la

efectividad de las campañas de marketing

50

La Gerencia de operaciones utiliza sistemas de manufactura

y producción que tienen que ver con el estatus de las tareas

de producción. La mayoría de los sistemas de manufactura y

producción utilizan algún tipo de sistema de inventario, como

se muestra en la figura 2-3. Los datos relativos a cada

artículo en inventario, como la cantidad de unidades

agotadas a causa de un embarque o una compra, o la

cantidad de unidades reabastecidas por medio de un nuevo

pedido o por devoluciones, se escanean o teclean en el

sistema. El archivo maestro de inventarios contiene datos

básicos acerca de cada artículo, como el código de

identificación único de cada artículo, una descripción del

mismo, la cantidad de unidades disponibles, la cantidad de

unidades por surtir y el punto de venta del nuevo pedido (la

cantidad en inventario que activa la decisión de realizar un

nuevo pedido para evitar el agotamiento de existencias). Las

empresas pueden calcular la cantidad de artículos que

pedirán o utilizar una fórmula para calcular la cantidad

menos costosa por pedir denominada cantidad óptima a

ordenar. El sistema produce informes que proporcionan

datos sobre aspectos como la cantidad disponible de cada

artículo en inventario, la cantidad de unidades de cada

artículo que se debe pedir o los artículos en inventario que

se deben reabastecer.

51

Tabla 4.

Ejemplos de Sistemas de Información de manufactura y producción


Control de máquinas Controla las acciones de las máquinas y equipos

Gerencia de operaciones

Planeación de la producción

Decide cuándo y cuántos productos se deben elaborar

Gerencia intermedia

Ubicación de las instalaciones

Decide donde ubicar nuevas instalaciones de producción

Alta dirección

Figura 4. Esquema de un sistema de inventario

Informe del estatus del inventario Fecha de Informe: 1/14/2007

Código del artículo

Descripción Unidades

disponibles Unidades Por surtir

6361 Banda de ventilador

10,211 0

4466 Cable de corriente 55,710 88,660

9313 Condensador 663 10,200

8808 Pistola para pintar 11,242 0

Sistema de control de inventario

Archivo

de ventas Informes para la

administración

Elementos de datos en el archivo maestro del inventario: Código de artículo Descripción Unidades disponibles Unidades por surtir Punto de reabastecimiento

Consultas en línea

Este sistema captura datos de ventas en el momento que se realiza la venta para

ayudar a la empresa a monitorear las transacciones de ventas y ofrecer

información que ayude a los gerentes a analizar las tendencias de ventas y la

efectividad de las campañas de marketing

52

Otro ejemplo de un sistema de manufactura y producción es el sistema de

control de calidad de Kia Motors descrito en la Sesión Interactiva sobre

Organizaciones. Este sistema ayuda a identificar el origen de los defectos

en los automóviles Kia. Esta empresa utiliza la información del sistema

para mejorar sus procesos de producción y así eliminar o reducir los

defectos. La mejora en la calidad de los vehículos reduce los gastos de

Kia en reparaciones por garantía y al mismo tiempo incrementa la

satisfacción del cliente. A medida que lea este caso, procure identificarlos

problemas que enfrenta esta empresa, cómo colaboran los sistemas de

información en su solución, así como las cuestiones de administración,

organización y tecnología que debe abordar Kia Motors.

Sistemas financieros y contables

La función de finanzas es administrar los activos financieros de la

empresa como el efectivo, las acciones, bonos y otras inversiones, con el

fin de maximizar su rendimiento.

Finanzas también se encarga de administrar la capitalización de la

empresa(buscando nuevos activos financieros en acciones, bonos u otras

formas de deuda).

Para determinar si la empresa está consiguiendo el mejor rendimiento de

sus inversiones, la función de finanzas debe obtener una cantidad

considerable de información de fuentes externas a la empresa.

La función de contabilidad es mantener y administrar los registros

financieros dela empresa -ingresos, desembolsos, depreciación, nómina-

para dar cuenta de sus flujos de fondos. Finanzas y contabilidad

comparten problemas relacionados cómo dar seguimiento a los activos

financieros y los flujos de fondos de una empresa.

También proporcionan respuestas a preguntas como: ¿Cuál es el

inventario actual de los activos financieros? ¿Qué registros existen de

desembolsos, ingresos, nómina y otros flujos de fondos?

53

Tabla 5.

Ejemplos de Sistemas de Información de finanzas y contabilidad


Cuentas por cobrar Da seguimiento al dinero que se le adeuda a la empresa

Gerencia de operaciones

Elaboración de presupuestos

Prepara presupuestos de corto plazo

Gerencia intermedia

Planeación de utilidades

Planifica utilidades a largo plazo

Alta dirección

La tabla 5 muestra algunos de los sistemas de información de finanzas y

Contabilidad que se encuentran en organizaciones grandes. La Alta

dirección utiliza los sistemas de finanzas y contabilidad para establecer

objetivos de inversión alargo plazo para la empresa y para proporcionar

pronósticos a largo plazo del desempeño financiero de ésta. La Gerencia

intermedia utiliza los sistemas para vigilary controlar los recursos

financieros de la empresa. La Gerencia de operaciones utilizan los

sistemas de finanzas y contabilidad para dar seguimiento al flujo de

fondos de la empresa a través de transacciones como pago de sueldos,

pagos a proveedores, informes de valores e ingresos.

La figura 4 muestra un sistema de cuentas por cobrar, que da seguimiento

a los clientes que han realizado compras a crédito y que tienen adeudos

con una empresa.

Cada factura genera una "cuenta por cobrar" - es decir, el cliente adeuda

dinero a la empresa. Algunos clientes pagan de contado, pero a otros se

les otorga crédito.

El sistema de cuentas por cobrar registra cada factura en un archivo

maestro que también contiene información sobre cada cliente, incluyendo

su capacidad crediticia.

54

El sistema también da seguimiento a todas las facturas cobradas y puede

producir una diversidad de informes de egresos, tanto en papel como en

la computadora, para ayudar a la empresa a cobrar las facturas. El

sistema también responde consultas sobre la capacidad crediticia y el

historial de pagos de algún cliente.

Figura 5. Sistema de cuentas por cobrar

Datos de la factura y del cliente Al libro mayor

Sistema De cuentas por obrar

Archivo

maestro de

cuentas por

cobrar

Informes para la

administración

Elementos de datos en el archivo maestro de cuentas por cobrar: Número de cliente Nombre Dirección Capacidad crediticia Limite de crédito Días de atraso Numero de factura Cantidad pagada saldo

Consultas en línea

Informe de cuentas por cobrar vencidas Num.

cliente Nombre

Saldo actual

1-30 días De atraso

31-60 días De atraso

61+días De atraso

Total

5043 Mayes Co. 0 500 500 6219 JT Garden 1500 700 2200 6932 Best Home 1000 1000

Un sistema de cuentas por cobrar da seguimiento y almacena datos importantes

sobre los clientes, como su historial de pagos, capacidad e historial de facturación

55

2.3. Definición de términos básicos

2.3.1. Atributos

"Es una característica de una entidad. El valor especifico de un

atributo, conocido como elemento de datos, se puede encontrar

con los campos de registro que describe una entidad. Como ya

se planteo, un conjunto de campos de un objeto específico

representa un registro. Cuna clave es un campo o grupo de

campos en un registro que se utiliza para identificar a este."

"son las propiedades que describen a cada entidad en un

conjunto de entidades. Un conjunto de entidades dentro de una

entidad, tiene valores específicos asignados para cada uno de

sus atributos, de esta forma, es posible su identificación

unívoca."

Es una característica de una entidad, conocido como elemento

de datos (valor específico) para cada uno de sus atributos que

se encuentran en los campos de un registro que describen a

una entidad y así será posible su identificación única.

Se pueden utilizar para:

a) Nombrar una ocurrencia del objeto de datos

b) Describir la ocurrencia

c) Hacer referencia a otra ocurrencia en otra tabla

Además, se debe definir uno o más atributos como un

identificador; es decir, el atributo identificador se convierte en

una clave cuando se desea encontrar una ocurrencia del objeto

de datos. En algunos casos, los valores para el (los)

identificador(es) son únicos, aunque esto no es un requisito. En

referencia al objeto de datos auto, un identificador razonable

podría ser el número de serie.

56

Un conjunto de atributos apropiado para un objeto de datos se

determina mediante la comprensión del contexto del problema.

Los atributos para auto sirven bien para una aplicación que

utilice el departamento de vehículos de motor, pero estos

atributos serían inútiles para una compañía automotriz que

necesite un software para el control de fabricación. En este

último caso, los atributos para auto tal vez incluirán también

número de serie, tipo de carrocería y color, pero además

tendrían que adicionarse muchos más atributos (como código

interior, tipo de tren de manejo, designador de paquete de

ajuste, tipo de transmisión) para hacer de auto un objeto

significativo en el contexto de control de fabricación.

2.3.2. Base de Datos

"Es una herramienta para recopilar y organizar información, se

puede almacenar información sobre personas, productos,

pedidos, o cualquier otra cosa. Muchas bases de datos

empiezan siendo una lista en un programa de procesamiento de

texto o en una hoja de cálculo."

"Una base de datos es una colección de archivos relacionados

que permite el manejo de la información de alguna compañía.

Cada uno de dichos archivos puede ser visto como una

colección de registros y cada registro está compuesto de una

colección de campos. Cada uno de los campos de cada registro

permite llevar información de algún atributo de una entidad del

mundo real”

"Se le llama base de datos a los bancos de información que

contienen datos relativos a diversas temáticas y categorizados

de distinta manera, pero que comparten entre sí algún tipo de

57

vínculo o relación que busca ordenarlos y clasificarlos en

conjunto."

Interpretando las relaciones podemos definir que la Base de

Datos. Es una herramienta organizadora, y/o bancos de

informaciones que están relacionadas entre sí para que

permitan el manejo de los datos. Que por cierto al principio es

una aplicación de texto pero que no se pueden unir, por eso es

importante la auto descripción para que el programa del sistema

sea independiente a los datos.

2.3.3. Datos

El dato es una representación simbólica (numérica, alfabética,

algorítmica, entre otros.), un atributo o característica de una

entidad. Los datos describen hechos empíricos, sucesos y

entidades.

Los datos aisladamente pueden no contener información

humanamente relevante. Sólo cuando un conjunto de datos se

examina conjuntamente a la luz de un enfoque, hipótesis o

teoría se puede apreciar la información contenida en dichos

datos.

2.3.4. Información

En sentido general, es un conjunto organizado de datos

procesados, que constituyen un mensaje que cambia el estado

de conocimiento del sujeto o sistema que recibe dicho mensaje.

http://es.wikipedia.org/wiki/Sistema_simb%C3%B3lico

http://es.wikipedia.org/wiki/Conjunto_de_datos

http://es.wikipedia.org/wiki/Postulado

http://es.wikipedia.org/wiki/Datos

http://es.wikipedia.org/wiki/Mensaje

58

2.3.5. Entidad

Una entidad es un tipo de objeto (un conjunto) definido en base

a la agregación de una serie de atributos. Una entidad

corresponde a la caracterización de objetos del mundo real, los

cuales son definidos y diferenciados del resto de los objetos,

sobre la base del conjunto de atributos que se agregan. Las

entidades tienen, como los conjuntos, intenciones y

extensiones. La intención de una entidad es denominada Tipo

de entidad y representa el posible conjunto de objetos definidos

en base a la agregación de un mismo conjunto de atributos; es

decir, en términos de abstracción, un tipo de entidad representa

la clasificación de las entidades individuales. La extensión de un

Tipo de Entidades denominada Conjunto de Entidades, y se

corresponde con todos los valores que en un momento dado

están asociados con cada atributo que define el tipo de entidad.

2.3.6. Sistema de gestión de base de datos

Es una aplicación que permite a los usuarios definir, crear y

mantener la base de datos, y proporciona acceso controlado a

la misma.

El SGBD es la aplicación que interacciona con los usuarios de

los programas de aplicación y la base de datos. En general, un

SGBD proporciona los siguientes servicios:

Permite la definición de la base de datos mediante el

lenguaje de definición de datos. Este lenguaje permite

especificar la estructura y el tipo de los datos, así como las

restricciones sobre los datos. Todo esto se almacenará en la

base de datos.

Permite la inserción, actualización, eliminación y consulta de

datos mediante el lenguaje de manejo de datos. El hecho de

59

disponer de un lenguaje para realizar consultas reduce el

problema de los sistemas de archivos, en los que el usuario

tiene que trabajar con un conjunto fijo de consultas, o bien,

dispone de un gran número de programas de aplicación

costosos de gestionar.

Hay dos tipos de lenguajes de manejo de datos: los

procedurales y los no procedurales. Estos dos tipos se

distinguen por el modo en que acceden a los datos. Los

lenguajes procedurales manipulan la base de datos registro

a registro, mientras que los no procedurales operan sobre

conjuntos de registros. En los lenguajes procedurales se

especifica qué datos deben obtenerse sin decir cómo

hacerlo. El lenguaje no procedural más utilizado es el SQL

(StructuredQueryLanguage) que, de hecho, es un estándar y

es el lenguaje de los SGBD relacionales.

Proporciona un acceso controlado a la base de datos

mediante:

Un sistema de seguridad, de modo que los usuarios

no autorizados no puedan acceder a la base de datos;

Un sistema de integridad que mantiene la integridad y

la consistencia de los datos;

Un sistema de control de concurrencia que permite el

acceso compartido a la base de datos;

Un sistema de control de recuperación que restablece

la base de datos después de e se produzca un fallo

del hardware o del software;

Un diccionario de datos o catálogo accesible por el

usuario que contiene la descripción de los daros de la

base de datos.

60

A diferencia de los sistemas de archivos, el SGBD gestiona la

estructura física de los datos y su almacenamiento. Con esta

funcionalidad, el SGBD se convierte en una herramienta de

gran utilidad. Sin embargo, desde el punto de vista del usuario,

se podría discutir que los SGBD han hecho las cosas más

complicadas, ya que ahora los usuarios ven más datos de los

que realmente quieren o necesitan, puesto que ven la base de

datos completa. Conscientes de este problema, los SGBD

proporciona un mecanismo de vistas que permite que cada

usuario tenga su propia vista o visión de la base. El lenguaje de

definición de datos permite definir vistas como subconjuntos de

la base de datos.

Las vistas, además de reducir la complejidad permitiendo que

cada usuario vea sólo la parte de la base de datos que

necesita, tienen otras ventajas:

Las vistas proporcionan un nivel de seguridad, ya que

permiten excluir datos para que ciertos usuarios no los vean.

Las vistas proporcionan un mecanismo para que los

usuarios vean los datos en el formato que deseen.

Una vista representa una imagen consistente y permanente

de la base de datos, incluso si la base de datos cambia su

estructura.

Todos los SGBD no presentan la misma funcionalidad, depende

de cada producto. En general, los grandes SGBD multiusuario

ofrecen todas las funciones que se acaban de citar y muchas

más. Los sistemas modernos son conjuntos de programas

extremadamente complejos y sofisticados, con millones de

líneas de código y con una documentación consistente en

varios volúmenes. Lo que se pretende es proporcionar un

sistema que permita gestionar cualquier tipo de requisitos y que

61

tenga un 100% de fiabilidad ante cualquier fallo hardware o

software. Los SGBD están en continua evolución, tratando de

satisfacer los requerimientos de todo tipo de usuario. Por

ejemplo, muchas aplicaciones de hoy en día necesitan

almacenar imágenes, video, sonido, etc. Para satisfacer a este

mercado, los SGBD deben cambiar. Conforme vaya pasando el

tiempo irán surgiendo nuevos requisitos, por lo que los SGBD

nunca permanecerán estáticos.

2.3.7. Modelo Conceptual

"Se utilizan para representar la realidad a un alto nivel de

abstracción. Mediante los modelos conceptuales se puede

construir una descripción de la realidad fácil de entender."

2.3.8. Modelo Lógico

"Es una descripción de la estructura de la base de datos en

términos de las estructuras de datos que puede procesar un

tipo de SGBD. Un modelo lógico es un lenguaje usado para

especificar esquemas lógicos (modelo relacional, modelo de

red, etc.). El diseño lógico depende del tipo de SGBD que se

vaya a utilizar, no depende del producto concreto."

Es una descripción usada para especificar el esquema lógico

detallado del modelo conceptual, depende del tipo SGBD que

se va a utilizar y no depende del producto concreto.

2.3.9. Modelo Físico.

"Es una descripción de la implementación de una base de datos

en memoria secundaria: las estructuras de almacenamiento y

los métodos utilizados para tener un acceso eficiente a los

datos. Por ello, el diseño físico depende del SGBD concreto y el

esquema físico se expresa mediante su lenguaje de definición

de datos."

62

2.3.10. Relación

Se denomina relación a un conjunto que representa una

correspondencia entre dos o más conjuntos. Una relación es,

por tanto, un nuevo conjunto en el que cada elemento está

formado por la agregación de los elementos de los conjuntos

individuales que intervienen en la relación. Así, una relación

binaria define un conjunto de pares ordenados <c1, c2>, que se

forman en base a un criterio de correspondencia. El orden de la

relación es importante, por lo que el par <c1, c2> no tiene por

qué ser igual al par <c2, c1>. Las relaciones pueden ser

binarias, ternarias o n-arias.

2.3.11. Mapa de instancia

Es una matriz donde se muestra la información de cada entidad

de modelo de datos, para posteriormente ser implementada a

través de un sistema de gestión de base de datos. Aquí se

muestran los nombres de los campos, restricciones, tipos de

datos, longitud y ejemplos de cómo se almacenarán los datos

encada tupla.

2.3.12. Matriz de Escenarios

Permite Identificar los procesos de la organización, las

entidades de datos, representar de forma matricial los procesos

frente a las entidades de datos y mostrar los documentos

utilizados durante el proceso. Así de esta manera el analista

podrá realizar fácilmente el modelo de datos.

La matriz de escenarios es una herramienta que permite el

aprendizaje significativo por parte de los alumnos en la

construcción de base de datos relacionales.

63

2.3.13. Registro

Un registro es un conjunto de campos almacenados. Una vez

más distinguimos entre tipo y ocurrencia. Una ocurrencia (o

ejemplar) de registro almacenado consta de un grupo de

ocurrencias de campos almacenados relacionados. Por

ejemplo, una ocurrencia de registro almacenado dentro de la

base de datos "partes" podría consistieren una ocurrencia de

cada uno de los siguientes campos almacenados: número de

parte, nombre de parte, color de parte y peso de parte. Decimos

que la base de datos contiene muchas ocurrencias del tipo de

registro almacenado "parte" (una vez más, una ocurrencia

porcada clase de parte).

64

CAPÍTULO III

3.1. Presentación e interpretación de resultados

IDENTIFICA ACTIVIDADES

Tabla 6

Identifica Actividades

Frecuencia Porcentaje Porcentaje

acumulado

Si 11 57,9 57,9

A Veces 8 42,1 100,0

Total 19 100,0

65

Gráfico 1

Identifica Actividades

Interpretación: En la mayoría de alumnos (57.9%) siempre identifica las

actividades y el 42.1% lo hace algunas veces. Tal como se muestra en la

tabla 06 y gráfico 01.

IDENTIFICA LOS ACTORES

Tabla 7

Identifica los actores


acumulado

Si 14 78,9 78,9

A Veces 5 21,1 100,0

Total 19 100,0

66

Gráfico 2

Identifica los actores

Interpretación: El 78.9% de a los estudiantes siempre identifica los

actores y solo el 21.1% lo hace algunas veces. Tal como se muestra en la

tabla 07 y gráfico 02.

IDENTIFICA LOS DOCUMENTOS

Tabla 8

Identifica los documentos


acumulado

Si 4 21,1 21,1

A Veces 15 78,9 100,0

Total 19 100,0

67

Gráfico 3

Identifica los documentos

Interpretación: El 21.1% siempre identifica los documentos y el 78.9% lo

hace a veces. Tal como se muestra en la tabla 08 y gráfico 03.

RELACIONA CORRECTAMENTE LOS ACTORES Y ACTIVIDADES

Tabla 9

Relaciona correctamente los actores y actividades


válido

Porcentaje

acumulado

Válidos Si 16 84,2 84,2 84,2

A Veces 3 15,8 15,8 100,0

Total 19 100,0 100,0

68

Gráfico 4


Interpretación: El 84.2% siempre identifica las actividades y el 15.8% lo

hace algunas veces. Tal como se muestra en la tabla 06 y gráfico 04.

IDENTIFICA ENTIDADES

Tabla 10

Identifica entidades

Frecuencia Porcentaje Porcentaje acumulado

Si 14 73,7 73,7

A Veces 3 15,8 89,5

No 2 10,5 100,0

Total 19 100,0

69

Gráfico 5

Identifica entidades

Interpretación: El 73.7% siempre identifica las entidades, el 15.8% lo

hace a veces y el 10.5% no lo hace. Tal como se muestra en la tabla 10 y

gráfico 05.

IDENTIFICACION DE ATRIBUTOS

Tabla 11

Identifica atributos


Si 13 68,4 68,4

A Veces 6 31,6 100,0

Total 19 100,0

70

Gráfico 6

Identifica atributos

Interpretación: El 68.4% siempre identifica las entidades y el 31.6% lo


ESTABLECE RELACIONES ENTRE ENTIDADES

Tabla 12

Establece relaciones entre entidades


Si 13 68,4 68,4

A Veces 6 31,6 100,0

Total 19 100,0

71

Gráfico 7


Interpretación: El 68.4% siempre identifica las entidades y el 31.6% lo


GENERA NUEVAS ENTIDADES

Tabla 13

Genera nuevas entidades


Si 12 63,2 63,2

A Veces 4 21,1 84,2

No 3 15,8 100,0

Total 19 100,0

72

Gráfico 8

Genera nuevas entidades

Interpretación: El 63.2% siempre identifica las entidades, el 21.1%

algunas veces y el 15.8% no lo hace. Tal como se muestra en la tabla 10

y gráfico 08.

AGREGA LOS ATRIBUTOS FORANEOS

Tabla 14

Agrega los atributos foráneos


Si 12 63,2 63,2

A Veces 4 21,1 84,2

No 3 15,8 100,0

Total 19 100,0

73

Gráfico 9

Agrega los atributos foráneos

Interpretación: El 63.2% siempre identifica loa atributos foráneos, el

21.1% a veces y el 15.8% no lo hace. Tal como se muestra en la tabla 11

y gráfico 9.

ELABORA MAPA DE INSTANCIA

Tabla 15

Elabora el mapa de instancia


Si 12 63,2 63,2

A Veces 3 15,8 78,9

No 4 21,1 100,0

Total 19 100,0

74

Gráfico 10

Elabora el mapa de instancia

Interpretación: El 63.2% siempre identifica las entidades, el 21.1%

algunas veces y el 15.8% lo hace algunas veces. Tal como se muestra en

la tabla 11 y gráfico 09.

ELABORA EL DICCIONARIO DE DATOS

Tabla 16

Elabora el diccionario de datos


Si 13 68,4 68,4

A Veces 3 15,8 84,2

No 3 15,8 100,0

Total 19 100,0

75

Gráfico 11

Elabora el diccionario de datos

Interpretación: El 64.8% siempre identifica las entidades, el 15.8% a

veces y el 15.8% lo hace algunas veces. Tal como se muestra en la tabla

13 y gráfico 11.

INFLUENCIA DE LA MATRIZ DE ESCENARIOS EN LA

CONSTRUCCIÓN DE LA BASE DE DATOS

Tabla 17

Influencia de la Matriz de Escenarios en la construcción de la base de

datos


Si 13 68,4 68,4

A Veces 5 26,3 94,7

No 1 5,3 100,0

Total 19 100,0

76

Gráfico 12

Influencia de la Matriz de Escenarios en la construcción de la base de

datos

Interpretación: El 64.8% siempre identifica las entidades, el 26.3% a

veces y el 5.3% lo hace algunas veces. Tal como se muestra en la tabla

14 y gráfico 12.

Contrastación de hipótesis

HIPÓTESIS GENERAL: La aplicación de una Matriz de Escenarios influye

significativamente en la construcción de Base de Datos por parte de los

alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de

la Facultad de Ingeniería Industrial, Sistemas e Informática de la

Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.

77

Tabla 18

Matriz de escenarios en relación a la construcción de base datos

Recuento

constr_base_datos

Total Si A Veces No

matriz de escenarios Si 13 0 0 13

A Veces 0 4 1 5

No 0 1 0 1

Total 13 5 1 19

Tabla Nº 19

Pruebas de chi-cuadrado

Valor gl

Sig. asintótica

(bilateral)

Chi-cuadrado de Pearson 19,760a 4 0,001

N de casos válidos 19

78

Gráfico 13

Identifica actividades * Influencia de la Matriz de Escenarios en la

construcción de la base de datos

La Matriz de Escenarios en la construcción de la base de datos está

relacionada a la identificación de actividades; según la prueba chi-

cuadrado por ser la Significancia asintótica bilateral (Sig.=0.044) está por

encima del nivel de error máximo permisible (α=0.05), entonces no hay

evidencia suficiente para rechazar la hipótesis nula (Ho: La Matriz de

Escenarios en la construcción de la base de datos y la identificación de

entidades son independientes) y por tanto a un 95% de confianza

podemos afirmar que La Matriz de Escenarios en la construcción de la

base de datos no está relacionada significativamente a la identificación de

entidades.

79

Tabla 20

Tabla de contingencia Identifica actividades * Influencia de la Matriz de

Escenarios en la construcción de la base de datos

Influencia de la Matriz de Escenarios en la


Total Si A Veces No

Identifica actividades Si 10 1 0 11

A Veces 3 4 1 8

Total 13 5 1 19

Tabla Nº 21


Valor gl

Sig. asintótica

(bilateral)



80

Gráfico 14

Identifica los actores * Influencia de la Matriz de Escenarios en la



relacionada a la identificación de actores; según la prueba chi-cuadrado

por ser la Significancia asintótica bilateral (Sig.=0.004) está por debajo del

nivel de error máximo permisible (α=0.05), entonces no hay evidencia

suficiente para rechazar la hipótesis nula (Ho: La Matriz de Escenarios en

la construcción de la base de datos y la identificación de entidades son

independientes) y por tanto a un 95% de confianza podemos afirmar que

La Matriz de Escenarios en la construcción de la base de datos no está

relacionada significativamente a la identificación de actores

81

Tabla 22

Tabla de contingencia

Recuento

Influencia de la Matriz de Escenarios en la


Total Si A Veces No

Identifica los

actores

Si 12 1 0 13

A Veces 1 4 1 6

Total 13 5 1 19

Tabla 23


Valor gl

Sig. asintótica

(bilateral)

Chi-cuadrado de Pearson 11,025 2 0,004


82

Gráfico 15

Identifica los documentos * Influencia de la Matriz de Escenarios en

la construcción de la base de datos



por ser la Significancia asintótica bilateral (Sig.=0.044) está por encima

del nivel de error máximo permisible (α=0.05), entonces hay evidencia





relacionada significativamente a la identificación de documentos

83

Tabla 24


Influencia de la Matriz de Escenarios en la construcción de la base de datos

Total Si A Veces No

Identifica los documentos Si 1 3 0 4

A Veces 12 2 1 15

Total 13 5 1 19

Tabla 25


Valor gl

Sig. asintótica

(bilateral)

Chi-cuadrado de Pearson 6,226 2 ,044


84

Gráfico 16

Relaciona correctamente los actores y actividades * Influencia de la

Matriz de Escenarios en la construcción de la base de datos



por ser la Significancia asintótica bilateral (Sig.=0.007) está por encima

del nivel de error máximo permisible (α=0.05), entonces hay evidencia





relacionada significativamente en la relación de los actores y actividades

85

Tabla 26



Total Si A Veces No


Si 13 3 0 16

A Veces 0 2 1 3

Total 13 5 1 19

Tabla 27


Valor gl

Sig. asintótica

(bilateral)



86

Gráfico 17

HIPÓTESIS 01: El uso de una Matriz de Escenarios influye

significativamente en el desarrollo del modelo conceptual en los alumnos

del V ciclo de la Escuela Profesional de Ingeniería Informática de la

Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad

Nacional José Faustino Sánchez Carrión de Huacho-2012.

87

Tabla 28

Matriz de escenarios en relación a la diseño del modelo conceptual

Recuento

matriz de escenarios

Total Si A Veces No

hipo_01 Si 13 1 0 14

A Veces 0 4 1 5

Total 13 5 1 19

Tabla 29


Valor gl

Sig. asintótica

(bilateral)



88

Gráfico 18

Matriz de escenarios en relación a la diseño del modelo conceptual

Relación entre la Identificación de entidades y la Matriz de



relacionada a la identificación de entidades; según la prueba chi-cuadrado


nivel de error máximo permisible (α=0.05), entonces hay evidencia





relacionada significativamente a la identificación de entidades.

89

Tabla 30

Relación entre la Identificación de entidades y la Matriz de Escenarios en



Recuento


Total Si A Veces No

Identifica entidades Si 12 1 1 14

A Veces 0 3 0 3

No 1 1 0 2

Total 13 5 1 19

Tabla 31


Valor gl

Sig. asintótica

(bilateral)



90

Gráfico 19

Relación entre la Identificación de entidades y la Matriz de Escenarios en


Relación entre la Identificación de atributos y la Matriz de Escenarios

en la construcción de la base de datos


relacionada a la identificación de atributos; según la prueba chi-cuadrado


nivel de error máximo permisible (α=0.05), entonces hay evidencia


la construcción de la base de datos y la identificación de atributos son



relacionada significativamente a la identificación de atributos.

91

Tabla 32

Relación entre la Identificación de atributos y la Matriz de Escenarios en la



Recuento


Total Si A Veces No

Identifica atributos Si 12 1 0 13

A Veces 1 4 1 6

Total 13 5 1 19

Tabla 33


Valor gl

Sig. asintótica (bilateral)



92

Gráfico 20

Relación entre la Identificación de atributos y la Matriz de Escenarios en la


Establece relaciones entre entidades y la Matriz de Escenarios en la



relacionada al establecimiento de relaciones entre entidades; según la

prueba chi-cuadrado por ser la Significancia asintótica bilateral

(Sig.=0.000) está por debajo del nivel de error máximo permisible

(α=0.05), entonces hay evidencia suficiente para rechazar la hipótesis

nula (Ho: La Matriz de Escenarios en la construcción de la base de datos

y el establecimiento de relaciones entre entidades son independientes) y

por tanto a un 95% de confianza podemos afirmar que La Matriz de

Escenarios en la construcción de la base de datos está relacionada

significativamente al establecimiento de relaciones entre entidades.

93

Tabla 34




Recuento


Total Si A Veces No


Si 13 0 0 13

A Veces 0 5 1 6

Total 13 5 1 19

Tabla 35


Valor gl

Sig. asintótica

(bilateral)



94

Gráfico 21



HIPÓTESIS 02: El uso de una Matriz de Escenarios influye

significativamente en el desarrollo del modelo relacional en los alumnos

del V ciclo de la Escuela Profesional de Ingeniería Informática de la

Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad

Nacional José Faustino Sánchez Carrión de Huacho-2012.

95

Tabla 36

Matriz de escenarios en relación a la diseño del modelo relacional

Recuento


Total Si A Veces No

hipo_02 Si 11 0 0 11

A Veces 2 1 1 4

No 0 4 0 4

Total 13 5 1 19

Tabla 37


Valor gl

Sig. asintótica

(bilateral)



96

Gráfico 22

Matriz de escenarios en relación a la diseño del modelo relacional

Relación entre la generación de nuevas entidades y la Matriz de



relacionada a la generación de nuevas entidades; según la prueba chi-

cuadrado por ser la Significancia asintótica bilateral (Sig.=0.001) está por

debajo del nivel de error máximo permisible (α=0.05), entonces hay


Escenarios en la construcción de la base de datos y el establecimiento de

relaciones entre entidades son independientes) y por tanto a un 95% de

confianza podemos afirmar que La Matriz de Escenarios en la

construcción de la base de datos está relacionada significativamente al

establecimiento de relaciones entre entidades.

97

Tabla 38

Relación entre la generación de nuevas entidades y la Matriz de




Total Si A Veces No

Genera nuevas entidades Si 12 0 0 12

A Veces 1 2 1 4

No 0 3 0 3

Total 13 5 1 19

Tabla 39


Valor gl

Sig. asintótica (bilateral)



98

Gráfico 23

Relación entre la agregación de los atributos foráneos y la Matriz de



relacionada a la agregación de los atributos foráneos; según la prueba

chi-cuadrado por ser la Significancia asintótica bilateral (Sig.=0.001) está

por debajo del nivel de error máximo permisible (α=0.05), entonces hay


Escenarios en la construcción de la base de datos y la agregación de los

atributos foráneos son independientes) y por tanto a un 95% de confianza

podemos afirmar que La Matriz de Escenarios en la construcción de la

base de datos está relacionada significativamente a la agregación de los

atributos foráneos.

99

Tabla 40





Total Si A Veces No

Agrega los atributos foráneos Si 12 0 0 12

A Veces 1 2 1 4

No 0 3 0 3

Total 13 5 1 19

Tabla 41


Valor gl

Sig. asintótica

(bilateral)



100

Gráfico 24



HIPÓTESIS 03:El uso de una Matriz de Escenarios influye

significativamente en el desarrollo del diseño físico en los alumnos del V

ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de

Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional

José Faustino Sánchez Carrión de Huacho-2012.

101

Matriz de escenarios en relación al diseño físico

Tabla 42


Recuento


Total Si A Veces No

hipo_03 Si 11 0 0 11

A Veces 2 2 0 4

No 0 3 1 4

Total 13 5 1 19

Tabla N° 43


Valor gl

Sig. asintótica

(bilateral)



102

Gráfico 25

Matriz de escenarios en relación al diseño físico

Relación entre la elaboración del mapa de instancia y la Matriz de



relacionada a la elaboración del mapa de instancia; según la prueba




Escenarios en la construcción de la base de datos y la elaboración del

mapa de instancia son independientes) y por tanto a un 95% de


construcción de la base de datos está relacionada significativamente a la

elaboración del mapa de instancia.

103

Tabla N° 44

Relación entre la elaboración del mapa de instancia y la Matriz de




Total Si A Veces No

Elabora el mapade instancia Si 12 0 0 12

A Veces 1 2 0 3

No 0 3 1 4

Total 13 5 1 19

Tabla 45


Valor gl

Sig. asintótica

(bilateral)



104

Gráfico 26

Relación entre la elaboración del diccionario de datos y la Matriz de



relacionada a la elaboración del diccionario de datos; según la prueba




Escenarios en la construcción de la base de datos y la elaboración del

diccionario de datos son independientes) y por tanto a un 95% de


construcción de la base de datos está relacionada significativamente a la

elaboración del diccionario de datos.

105

Tabla 46

Relación entre la elaboración del diccionario de datos y la Matriz de



Influencia de la Matriz de Escenarios en la construcción de la

base de datos

Total Si A Veces No

Elabora el diccionario de datos Si 11 2 0 13

A Veces 2 0 1 3

No 0 3 0 3

Total 13 5 1 19

Tabla 47


Valor gl

Sig. asintótica

(bilateral)



106

Gráfico 27

107

CONCLUSIONES

Luego de haber tomado las muestras, evaluado y analizado;

respaldándose en los resultados estadísticos obtenidos llegamos a las

siguientes conclusiones:

Queda demostrado que el uso de la Matriz de Escenarios influye

directa y significativamente en la optimización del desarrollo del

modelo conceptual, ya que la herramienta permite la generación

rápida y eficientemente de nuevas entidades, facilitando

significativamente el aprendizaje.



modelo relacional.



modelo físico, los alumnos construyen sin ningún tipo de problema

el diccionario de datos.


directa y significativamente en la optimización de la construcción de

la base de datos.

109

RECOMENDACIÓN

a) Se recomienda a las autoridades de la facultad de ingeniería

industrial, sistemas e informática adoptar la aplicación de la Matriz

de Escenarios en el desarrollo del curso de base de datos

mediante disposiciones normativas que aseguren su permanencia

en el tiempo.

b) Se recomienda que las autoridades encargadas de la jefatura de

departamento desarrolle programas de capacitación permanente y

continua en para la aplicación de la Matriz de Escenarios en el

desarrollo del modelo conceptual para la construcción dela base de

datos

c) Los docentes deben estandarizar los criterios de aplicación de la

Matriz de Escenarios para optimizar de la generación de nuevas

entidades y atributos en el alumnado para el desarrollo del modelo

relacional.

d) Se recomienda que los docentes difundan y fomenten la aplicación

de la matriz en el modelo conceptual ya que se considera básico

para la construcción del modelo físico.

e) Que el decano de la facultad organice una junta de ingenieros

especialistas en el desarrollo de base de datos, encargados de

evaluar permanentemente la Matriz de Escenarios con el fin de

optimizar su aplicación o efectivizar su aplicación.

110

FUENTES DE INFORMACIÓN

1. Oscar Sánchez Estrella, Miguel Moro Vallina (2010) Aplicaciones

Informáticas de bases de datos relacionales. edit. Parainfo.

España.

2. Olga Pons, Silvia Acio, Nicolás Marín, Juan Miguel Medina, Amparo

Vila (2008). Introducción a los sistemas de bases de datos. edit.

Parainfo. España.

3. Victoria Nevado Cabello (2006). Introducción a las bases de datos

relacionales. edit. Visión Libros. España

4. David M. Kroenke(2003) . Procesamiento de Bases de Datos. edit.

Pearson. Mexico

5. Fray león Ososrio Rivero (2008). Bases de datos Relacionales

Teoría y Práctica. edit. ITM. Colombia

6. Olga Pons, Nicolás Marín, Juan Miguel Medina, Silvia Acid, Amparo

Vila (2005). Introducción a las Bases de Datos. El Modelo

Relacional. edit. Thomson. España

7. Peter Rob, Carlos Coronel (2006). Sistemas de Bases de Datos.

edit. Thomson. España.

8. Enrique Rivero Cornelio, Carlos Guardia Rivas, José Carlos Reig

Hernández (2004). Base de Datos Relacionales. edit. R.B.

Servicios Editoriales S.L.España

9. Date C.J.(2001)Introducción a los Sistemas de Base de Datos,edit.

México, p.

10. Jacobson Ivar, Booch Grady (y) RumbaughJames(2000). El

Proceso Unificado del Desarrollo de Software, España

11. Jaime Pantigoso Silva (2009). SQL Server 2008. Perú

12. Luque Ruiz Irene, Gómez Miguel Ángel, López Espinoza Nieto

Enrique (y) Cerruela García Gonzalo (2002). Bases de Datos desde

Chen hasta Codd con Oracle, México, pp 1-22

111

13. Pressman Roger S (2006), Ingeniería del Software. Edit. McGraw-

HillMéxico.

14. Silvershatz Abraham, Korth Henry F. (y) Sudarshan

S.(2006)Fundamentos de Base de Datos, España, pp 18-19

15. Kenneth C. Laudon, Jane P. Laudon (2008) Sistemas de

Información Gerencial, España, pp 14, 45-51

112

ANEXOS

113

ANEXO1. CUESTIONARIO

USO DE LA MATRIZ DE ESCENARIOS EN LA CONSTRUCCION DE LA

BASE DE DATOS

Dirigido a: Alumnos

INSTRUCCIONES:

El presente cuestionario tiene el objetivo de recabar información relacionada con la investigación

sobre “APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA

CONSTRUCCIÓN DE BASES DE DATOS RELACIONAL POR PARTE DE LOS ALUMNOS V

CICLO DE LA ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA DE LA FACULTAD DE

INGENIERÍA INDUSTRIAL, SISTEMAS E INFORMÁTICA DE LA UNIVERSIDAD NACIONAL

JOSÉ FAUSTINO SÁNCHEZ CARRIÓN - HUACHO-2012”

”. Tiene carácter anónimo. Marcar con una X la respuesta que considere correcta:

Matriz de procesos

MODELO CONCEPTUAL

N ITEM RESPUESTA

SI A

VECES NO

1 Considera usted que el área de actividades de la Matriz de Escenarios le favorece su modelamiento de la etapa conceptual del desarrollo de base de datos

2 Considera usted que el área de actores de la Matriz de Escenarios le favorece su modelamiento de la etapa conceptual del desarrollo de base de datos

3 Considera usted que el área de objetos de la Matriz de Escenarios le favorece su modelamiento de la etapa conceptual del desarrollo de base de datos

4

Considera usted que relaciona correctamente los actores y actividades de la Matriz de Escenarios , favoreciendo el modelamiento de la etapa conceptual en el desarrollo de base de datos

N ITEM RESPUESTA

SI A

VECES NO

5 Identifica usted con facilidad las entidades para el modelo conceptual

6 Identifica usted con facilidad atributos de las entidades para el modelo conceptual

7 Establece usted relaciones entre las entidades con facilidad

114

MODELO RELACIONAL

MODELO FISICO

N ITEM RESPUESTA

SI A

VECES NO

8 Genera rápida y eficientemente nuevas entidades para el modelo relacional

9 Genera rápida y eficientemente nuevos atributos para el modelo relacional

N ITEM

RESPUESTA

SI A

VECES NO

10 Crea eficientemente el mapa de instancia para el modelo físico de la construcción de base de datos

11 Crea eficientemente el diccionario de datos para el modelo físico de la construcción de base de datos

N ITEM

RESPUESTA

SI A

VECES

NO

12 ¿Considera usted que el uso de la matriz de procesos le permitiría optimizar la construcción de la base de datos?

115

ANEXO 2. MATRIZ DE CONSISTENCIA

APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA CONSTRUCCIÓN DE BASES DE DATOS POR PARTE DE LOS ALUMNOS V CICLO DE LA ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA DE LA FACULTAD DE INGENIERÍA INDUSTRIAL, SISTEMAS E INFORMÁTICA DE LA UNIVERSIDAD NACIONAL JOSÉ FAUSTINO SÁNCHEZ CARRIÓN -

HUACHO-2012

ANEXO 2. MATRIZ DE CONSISTENCIA

APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA CONSTRUCCIÓN DE BASES DE DATOS RELACIONALES POR PARTE DE LOS ALUMNOS DEL V CICLO DE LA ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA DE LA FACULTAD DE INGENIERÍA INDUSTRIAL,

SISTEMAS E INFORMÁTICA DE LA UNIVERSIDAD NACIONAL JOSÉ FAUSTINO SÁNCHEZ CARRIÓN - HUACHO-2012 PROBLEMA OBJETIVOS HIPOTESIS VARIABLES DIMENSION INDICADORES METODOLOGIA

GERENAL ¿De qué forma la aplicación de una Matriz de Escenarios influye en la construcción de Base de Datos Relacional por parte de los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012?

GENERAL Determinar en qué medida la aplicación de una Matriz de Escenarios influye en la construcción de Base de Datos Relacional por parte de los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.

GENERAL La aplicación de una Matriz de Escenarios influye significativamente en la construcción de Base de Datos Relacional por parte de los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.

VI Matriz de Escenarios

Área de actividades Área de actores Área de objetos

Enfoque: cuantitativo Tipo: aplicativo Nivel: Correlacional Diseño: No experimental Población: La población estuvo conformada por todos los alumnos que cursan el V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho, cuya cantidad es 65. Muestra: La muestra está conformada por el total de alumnos que se encuentran matriculados en el curso de Base de Datos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho, conformada por 19 alumnos. Técnica:

Entrevistas

Encuestas

Observación Instrumento: Cuestionario con un formato

ESPECIFICOS a) ¿Cómo influye el uso de una Matriz de Escenarios en el desarrollo del modelo conceptual en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012? b) ¿Cómo influye el uso de una Matriz de Escenarios en el desarrollo del

ESPECIFICOS a) Determinar en qué medida el uso de una Matriz de Escenarios influye en el desarrollo del modelo conceptual en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012. b) Determinar en qué medida el uso de una Matriz de Escenarios influye en el

ESPECIFICAS a) El uso de una Matriz

de Escenarios influye significativamente en el desarrollo del modelo conceptual en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino

VD Construcción de la base de datos MODELO

CONCEPTUAL

Identifica entidades Identifica atributos Establece relaciones entre entidades

MODELO RELACIONAL

genera nuevas entidades genera nuevos atributos

116

modelo relacional en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012? c) ¿Cómo influye el uso de una Matriz de Escenariosen el desarrollo del diseño físico en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012?

desarrollo del modelo relacional en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012. c) Determinar en qué medida el uso de una Matriz de Escenarios influye en el desarrollo del diseño físico en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.


b) El uso de una Matriz de Escenarios influye significativamente en el desarrollo del modelo relacional en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.

c) El uso de una Matriz de Escenario influye significativamente en el desarrollo del diseño físico en los alumnos del V ciclo de la Escuela Profesional de Ingeniería Informática de la Facultad de Ingeniería Industrial, Sistemas e Informática de la Universidad Nacional José Faustino Sánchez Carrión de Huacho-2012.

DISEÑO FISICO

Crea mapa de instancia Crea diccionario de datos

estructurado

117

ANEXO 3. MATRIZ DE ESCENARIOS

Actividad Actores Lugar Objetos

¿Quién lo hace? ¿Dónde lo hacen? Entradas Procedimiento Salida

¿Qué hacen?

Unidad Orgánica

¿Qué necesitan para

hacer?

¿Qué usa en el

procedimiento?

¿Qué da después de

hacer?

Listar las actividades en el

orden que sucede de acuerdo

al proceso que es materia de

estudio

Quienes son los actores

que intervienen en la

actividad

Donde se realiza la

actividad, para saber qué

áreas está involucradas en

el proceso de negocio que

se estudia Qué documento se utiliza

para iniciar la actividad (si

lo hubiera)

Qué documento se utiliza

durante la actividad (si lo

hubiera)

Qué documento se

obtiene al final de la

actividad (si lo hubiera)

Con respecto a la

matriz:

Sección de la actividad

o Primero se listan las actividades, que se realizan en el proceso de negocio a

estudiar.

o Las actividades se deben listar en orden desde la que da inicio al proceso hasta

que finaliza

Sección de los actores

o Se establecen los actores que participan en la actividad

o Se establecen la relación entre los actores y las actividades

o Cada uno de ellos es candidato a convertirse en una entidad

Lugar

o La unidad orgánica o área donde se realiza la actividad, esto nos permite saber

de qué área provienen algunos documentos o porque áreas pasan los

documentos. Esto nos ayuda a entender de forma más rápida las actividades del

proceso de negocio.

Objetos

o Se establecen los documentos que se utilizan durante las actividades. Cada uno

de ellos es candidato a convertirse en una entidad.

o A través de ellos y la relación con los actores, se pueden establecer la relación

entre las entidades.

Relaciones

o Las relaciones entre las posibles entidades, se analizan éntrela secciones de las

actividades, actores y objetos

BASE DE DATOS PARA EL SISTEMA DE COMPRAS DE LA BOTICA “FARMA MEDIC” Página 119


INTRODUCCIÓN

En la actualidad todas las empresas o negocios buscan ser más competitiva, tener la mayor

cantidad de clientes y ofrecer productos y/o servicios de calidad, conocer y controlar los costos y

gastos y evitar pérdidas o mal uso de sus capitales.

La información actualmente tiene gran importancia y es muy necesario en cualquier empresa

porque permite conocer la realidad, interactuar con el medio físico tomar decisiones más óptimas y en

menor tiempo posible.

Las Empresas que están dispuestos a ser competitivos en este mundo globalizado necesitan

manejar una gran cantidad de información de manera eficiente, rápida y confiable, objetivo que

lograría con la informática por su capacidad de procesamiento de datos.


ÍNDICE

Caratula ……………………………………………….…………………………………………………………...

Introducción ……………………………………………….………………………………………………………

Indice……………………………………………….………………………………………………………………

CAPITULO I

DATOS GENERALES

1.1. Titulo del Proyecto……………………………………………………………………….. 1.2. Nombre de la Entidad……………………………………………………………………. 1.3. Ubicación de la Entidad………………………………………………………………….. 1.4. Descripción…………………………………………………………………………………

CAPITULO II

DEL PROYECTO

2.1. Situación problemática existente………………………………………………………

2.2. Descripción detallada del proceso de negocio a estudiar………………………….

2.3. Cronograma de ejecución. ………………………………………………………………….

CAPITULO III

DISEÑO E IMPLEMENTACION DEL MODELO Y BASE DE DATOS

3.1 Matriz de procesos…………………………………………………………………. 3.2 Modelo conceptual………………………………………………………………….. 3.3 Modelo relacional……………………………………………………………………. 3.4 Diseño Físico………………………………………………………………………….

3.4.1 Diccionario de datos…………………………………………………

3.5 Implementación de la base de datos en MySQL…………………………………… 3.5.1 Creación de la base de datos………………………………………………… 3.5.2 Creación de vistas………………………………………………………………


CAPITULO I DATOS GENERALES

1.1. Título del Proyecto. Base de datos para el Sistema de Compras para la Botica “Farma Medic”.

1.2. Nombre de la Entidad. Botica “Farma Medic”

1.3. Ubicación de la Entidad. Av. Túpac Amaru #337 - Huacho.

1.4. Descripción La Botica “Farma Medic” es una empresa pequeña que realiza el Servicio de Compra y Venta de medicamentos para todo cliente en general. Los medicamentos que comercializa se distribuyen en función a su acción terapéutica (analgésico, Antiinflamatorio, Anestésico,etc). Esta empresa trabaja con una gran cantidad de proveedores por lo que necesita controlar la calidad de los productos, tener un mejor control de sus compras y sobe todo obtener la información precisa y exacta de sus compras cuando sea requerido. Tambien busca conocer los mercados y agilizar el proceso de compra y manejar una información actualizada y puntual, mejorar la satisfacción de los clientes y sobre todo maximizar las ganancias.


CAPITULO II DEL PROYECTO

2.1. Situación problemática existente.

La botica “MEDIFARMA” realiza constantemente compras de medicamentos a un

conjunto de proveedores en el que se da un conjunto de subprocesos y en cada procesos

se necesita conocer los detalles exactos sobre el estado de sus compras y también cuando

requiere datos de fechas anteriores.

En el proceso de compra el Jefe del área de compras sería el encargado de evaluar

las solicitudes de compras y también hacer el contrato con cada uno de los proveedores en

el que también evalúa la propuesta de sus productos y selecciona a los que pueden ofrecer

un mejor producto.

2.2. Descripción detallada del proceso de negocio a estudiar

COMPRA

El Jefe de Compras es el encargado de hacer los contratos con los proveedores y

manejar el flujo desde la nota de pedido hasta la entrega de los productos.

El Jefe de Compras recibe una solicitud de una lista de productos que se necesita

hacer una compra a la que evaluara para determinar si es necesaria la compra de

determinados productos.

Si está de acuerdo pedirá una licitación a sus proveedores solicitando los precios y

promociones de cada producto.

Al recibir las propuestas los evaluara y emitirá un orden de compra con los datos del

proveedor, el producto y la cantidad, considerando el tiempo oportuno de la entrega de

producto.

El encargado de caja es el que controla las operaciones financieras de la empresa

por lo que se encarga de concretar el depósito del monto total en el banco.

El transportista traerá los productos entregando al Jefe de Almacén quien es el

encargado de registrar los productos proveedores antes y después de cada operación.

El jefe de Almacen recibirá la guía de remisión y la factura entregando el voucher de

cancelación de los productos.

Al finalizar el Jefe de Compras registrara la guía de compra y terminara el proceso.


2.3.

Cronograma de ejecución.

Abril Mayo Junio Julio

Busqueda de Empresa

Solicitud de Datos

Analisis del proceso de negocio

Creacion de Base de Datos

Implementación y pruebas

CAPITULO III DISEÑO E IMPLEMENTACION DEL MODELO Y BASE DE DATOS

3.1. Matriz de escenarios

Actividades Actores Lugar Objetos

¿Quién lo hace? ¿Dónde lo hacen? Entradas Procedimiento Salida

¿Qué hacen?

Jefe A

lmacé

n

Jefe C

om

pras

Pro

vee

do

r

Caja

Unidad Orgánica

¿Qué necesitan para hacer?

¿Qué usan en el

procedimiento?

¿Qué da después de hacer?

Emitir Nota de pedido x x

almacén

Lista de productos Nota de pedido

Evaluación de proveedores

x x

Cotizaciones

Orden de compra

Evaluación de propuestas

x

Administración Datos de medicamentos

Información de compras anteriores

Orden de compra

Orden de pago

x x

Administración Listado de medicamentos

Contrato con los proveedores

orden de pago

Deposito por la compra

x Banco Dinero, orden de pago

Banco boucher de Pago

Entrega de los medicamentos x

x

Almacén

Factura Guía de remisión

Medicamentos

Verificación del estado de los medicamentos x

Almacén Medicamentos

Información de los medicamentos

Estado de los medicamentos

Registro de medicamentos x

Almacén Medicamentos, guía de remisión

Comprobante de pago

Stock Actualizado


3.2. Modelo Conceptual


3.3. Modelo Relacional


3.4. Diseño Fisico 3.4.1 Diccionario de Datos

Detalle_Nota_Pedido_Medicamento

ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

detalle_MNP N Int P S/R Identificador único para la calificación

del Detalle_Nota_Pedido.

Id_medicamento N Int F medicamento Identificador único para medicamento

de Detalle_MNP.

Id_nota_pedido N Int F Nota_Pedido Identificador único para nota_pedido

de Detalle_MNP.

Precio S Numeric(10,2) S/R Precion Actual del Medicamento

Cantidad S Int S/R Cantidad Total de Medicamento que

se va a Comprar

Fecha_vencimiento S Date S/R Fecha de Vencimiento del

medicamento

Total S Numeric(10,2) S/R Importe del Precio por la Cantidad

comprada

Estado_Nota_Pedido


Id_estado_nota_pedido N Int P S/R Identificador único para medicamento

de estado_nota_pedido

Nombre_estado S Varchar(100) S/R Nombre del estado de pedido


Factura_Recibida ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_factura N Int P S/R Identificador único de

factura_recibida

Código_factura_recibida S Varchar(50) S/R Código de la factura recibida

Fecha_entrega S Date S/R Fecha de entrega de la factura

Guia_Compra ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_guia_compra N Int P S/R Identificador único de guía_compra

Código_guia_compra S Varchar(50) S/R Código de la factura recibida

Id_proveedor S Date S/R Fecha de entrega de la factura

Id_personal N Int F Personal Identificador único para

guía_compra de personal

Id_nota_pedido N Int F Nota_Pedido Identificador único para

guía_compra de nota_pedido

Id_factura N Int F Factura Identificador único para

guía_compra de factura

Id_guia_remision N Int F Guia_Remision Identificador único para

guía_compra de guía_remision

Guia_Remision ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_guia_remision N Int P S/R Identificador único de

guía_remision

Código_remision S Varchar(50) S/R Código de guía_remision

Fecha_emision S Date S/R Fecha en que se emite la guía de

emision

Forma_envio S Varchar(50) SR Detalle de la forma de envio de los

productos

observacion S Varchar(50) S/R Observación sobre la entrega de

los productos

Id_proveedor N Int F Proveedor Identificador único para

guía_remision de proveedor


Medicamento


Id_medicamento N Int P S/R Identificador único de

medficamento

Nombre_medicamento S Varchar(100) S/R Nombre del medicamento

unidad S Varchar(50) S/R Unidad en que se presenta el

medicamento


medicamento de personal

Id_tipo_medicamento N Int F Tipo_medicamento Identificador único para

medicamento de

tipo_medicamento

Nota_Pedido


Id_nota_pedido N Int P S/R Identificador único de

nota_pedido

Código_nota_pedido S Varchar(50) S/R Código de nota_pedido

Fecja_compra S Date S/R Fecha en que se hace el contrato

de la compra

Fecha_recepcion S Date S/R Fecha pactado para la entrega de

los medicamentos

Importe S Decimal(10,2) S/R Importe por la compra de los

medicamentos


nota_pedido de personal

Id_estado_nota_pedido N Int F Nota_pedido Identificador único para

nota_pedido de

estado_nota_pedido


Pago ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_pago N Int P S/R Identificador único de pago

codigo_pago S Varchar(50) S/R Código del voucher por hacer el

pago

monto S Decimal(10,2) S/R Monto que se ha pagado

Id_personal N Int F Personal Identificador único para pago de

personal

Id_factura N Int F Factura Identificador único para pago de

factura

Personal ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_personal N Int P S/R Identificador único de personal

Nombre_personal S Varchar(100) S/R Nombre del Personal

Apelldio_paterno S Varchar(100) S/R Apellido paterno del personal

Apellido_materno S Varchar(100) S/R Apellido materno del personal

direccion S Varchar(50) S/R Dirección del personal

Teléfono S Int S/R Telefono del personal

Celuilar S Int S/R Celular del personal

Id_tipo_personal N Int F Tipo_personal Identificador único para personal

de tipo_personal

Proveedor ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_proveedor N Int P S/R Identificador único de proveedor

Nombre S Varchar(100) S/R Nombre del Proveedor

Numero _cuenta S Varchar(14) S/R Numero de cuenta del Proveedor

direccion S Varchar(50) S/R Dirección del proveedor

Teléfono S Int S/R Telefono del proveedor

Celuilar S Int S/R Celular del proveedor

email N Varchar(50) S/R Email del proveedor


Tipo_medicamento ATRIBUTO NULL TIPO DE DATO K REFERENCIAS DEFINICIÓN

Id_tipo_medicamento N Int P S/R Identificador único de

tipo_medicamento

Nombre_tipo_medicamento S Varchar(100) S/R Nombre del tipo_medicamento

Acción_terapéutica S Varchar(50) S/R Acción terapéutica del tipo de

medicamento

Modeo_uso S Varchar(50) S/R Modo de uso del tipo de

medicamento

Tipo_personal


Id_tipo_personal N Int P S/R Identificador único de

tipo_personal

codigo_tipo_personal S Varchar(50) S/R Código del tipo_personal

nombre_tipo_personal S Varchar(100) S/R Nombre de tipo_personal

Usuario


Usuario_id N Int P S/R Identificador único de usuario

Usuario S Varchar(50) S/R Usuario

password S Varchar(100) S/R Contraseña

Id_personal N Int F Personal Identificador único de personal

para usuario


3.5. Implementación de la base de datos MYSQL

3.5.1. Creación de la base de datos

-- Company : LSTR

-- Project : ModelFarmaMedic.dm1

-- Author : Lester Narvasta Ramirez

-- Date Created : Thursday, July 25, 2012 13:39:30

-- Target DBMS : MySQL 5.x

-- TABLE: Detalle_MNP

CREATE TABLE Detalle_MNP(

detalle_MNP INT NOT NULL,

id_medicamento INT NOT NULL,

id_nota_pedido INT NOT NULL,

precio DECIMAL(10, 2),

cantidad INT,

fecha_vencimiento DATE,

PRIMARY KEY (detalle_MNP)

)ENGINE=MYISAM;

-- TABLE: Estado_Nota_Pedido

CREATE TABLE Estado_Nota_Pedido(

id_estado_nota_pedido INT NOT NULL,

nombre_estado VARCHAR(50),

PRIMARY KEY (id_estado_nota_pedido)

)ENGINE=MYISAM;

-- TABLE: Factura_Recibida

CREATE TABLE Factura_Recibida(

id_factura INT NOT NULL,

codigo_factura_recibida VARCHAR(50),

fecha_entrega DATE,

PRIMARY KEY (id_factura)

)ENGINE=MYISAM;


-- TABLE: Guia_Compra

CREATE TABLE Guia_Compra(

id_guia_compra INT NOT NULL,

codigo_guia_compra VARCHAR(50),

id_proveedor INT NOT NULL,

id_personal INT NOT NULL,



id_guia_remision INT NOT NULL,

PRIMARY KEY (id_guia_compra)

)ENGINE=MYISAM;

-- TABLE: Guia_Remision

CREATE TABLE Guia_Remision(

id_guia_remision INT NOT NULL,

codigo_remision VARCHAR(50),

fecha_emision DATE,

forma_envio VARCHAR(100),

observacion VARCHAR(100),


PRIMARY KEY (id_guia_remision)

)ENGINE=MYISAM;

-- TABLE: Medicamento

CREATE TABLE Medicamento(

id_medicamento INT NOT NULL,

nombre_medicamento VARCHAR(100),

unidad VARCHAR(50),


id_tipo_medicamento INT NOT NULL,

PRIMARY KEY (id_medicamento)

)ENGINE=MYISAM;


-- TABLE: Nota_Pedido

CREATE TABLE Nota_Pedido(


codigo_nota_pedido VARCHAR(50),

fecha_compra DATE,

fecha_recepcion DATE,

importe DECIMAL(10, 2),


id_estado_nota_pedido INT, PRIMARY KEY (id_nota_pedido) )

ENGINE=MYISAM;

-- TABLE: Pago

CREATE TABLE Pago(

id_pago INT NOT NULL,

codigo_pago VARCHAR(50),

monto DECIMAL(10, 2),



PRIMARY KEY (id_pago)

)ENGINE=MYISAM;

-- TABLE: Personal

CREATE TABLE Personal(


nombre_personal VARCHAR(50),

apellido_paterno VARCHAR(50),

apellido_materno VARCHAR(50),

direccion VARCHAR(50),

telefono INT,

celular INT,

id_tipo_personal INT NOT NULL,

PRIMARY KEY (id_personal)

)ENGINE=MYISAM;


-- TABLE: Proveedor

CREATE TABLE Proveedor(


nombre VARCHAR(100),

numero_cuenta INT,

direccion VARCHAR(25),

telefono INT,

celular INT,

email VARCHAR(50),

PRIMARY KEY (id_proveedor)

)ENGINE=MYISAM;

-- TABLE: Tipo_Medicamento

CREATE TABLE Tipo_Medicamento(

id_tipo_medicamento INT NOT NULL,

nombre_tipo_medicamento VARCHAR(100),

accion_terapeutica VARCHAR(250),

modo_uso VARCHAR(100),

PRIMARY KEY (id_tipo_medicamento)

)ENGINE=MYISAM;

-- TABLE: Tipo_Personal

CREATE TABLE Tipo_Personal(

id_tipo_personal INT NOT NULL,

codigo_tipo_personal CHAR(2),

nombre_tipo_personal VARCHAR(100),

PRIMARY KEY (id_tipo_personal)

)ENGINE=MYISAM;

-- TABLE: Usuario

CREATE TABLE Usuario(

usuario_id INT NOT NULL,

Usuario VARCHAR(100),

Password VARCHAR(50),


PRIMARY KEY (usuario_id)

)ENGINE=MYISAM;


-- TABLE: Detalle_MNP

ALTER TABLE Detalle_MNP ADD CONSTRAINT RefMedicamento26

FOREIGN KEY (id_medicamento)

REFERENCES Medicamento(id_medicamento);

ALTER TABLE Detalle_MNP ADD CONSTRAINT RefNota_Pedido27

FOREIGN KEY (id_nota_pedido)

REFERENCES Nota_Pedido(id_nota_pedido);

-- TABLE: Factura_Recibida

ALTER TABLE Factura_Recibida ADD CONSTRAINT RefPago18

FOREIGN KEY (id_pago)

REFERENCES Pago(id_pago);

-- TABLE: Guia_Compra

ALTER TABLE Guia_Compra ADD CONSTRAINT RefProveedor12

FOREIGN KEY (id_proveedor)

REFERENCES Proveedor(id_proveedor);

ALTER TABLE Guia_Compra ADD CONSTRAINT RefPersonal13

FOREIGN KEY (id_personal)

REFERENCES Personal(id_personal);

ALTER TABLE Guia_Compra ADD CONSTRAINT RefNota_Pedido17

FOREIGN KEY (id_nota_pedido)

REFERENCES Nota_Pedido(id_nota_pedido);

ALTER TABLE Guia_Compra ADD CONSTRAINT RefFactura_Recibida33

FOREIGN KEY (id_factura)

REFERENCES Factura_Recibida(id_factura);

ALTER TABLE Guia_Compra ADD CONSTRAINT RefGuia_Remision34

FOREIGN KEY (id_guia_remision)

REFERENCES Guia_Remision(id_guia_remision);

-- TABLE: Guia_Remision

ALTER TABLE Guia_Remision ADD CONSTRAINT RefProveedor10




-- TABLE: Medicamento

ALTER TABLE Medicamento ADD CONSTRAINT RefPersonal4



ALTER TABLE Medicamento ADD CONSTRAINT RefTipo_Medicamento8

FOREIGN KEY (id_tipo_medicamento)

REFERENCES Tipo_Medicamento(id_tipo_medicamento);

-- TABLE: Nota_Pedido

ALTER TABLE Nota_Pedido ADD CONSTRAINT RefPersonal14



ALTER TABLE Nota_Pedido ADD CONSTRAINT RefProveedor15



ALTER TABLE Nota_Pedido ADD CONSTRAINT RefEstado_Nota_Pedido35

FOREIGN KEY (id_estado_nota_pedido)

REFERENCES Estado_Nota_Pedido(id_estado_nota_pedido);

-- TABLE: Pago

ALTER TABLE Pago ADD CONSTRAINT RefPersonal7



-- TABLE: Personal

ALTER TABLE Personal ADD CONSTRAINT RefTipo_Personal3

FOREIGN KEY (id_tipo_personal)

REFERENCES Tipo_Personal(id_tipo_personal);

-- TABLE: Usuario

ALTER TABLE Usuario ADD CONSTRAINT RefPersonal9


REFERENCES Personal(id_personal)


3.5.2. Creación de vistas

create view vMedicamento as

select m.id_medicamento,m.nombre_medicamento,m.unidad,p.nombre_personal,tm.nombre_tipo_medicamento from medicamento m

join personal p ON p.id_personal=m.id_personal

join tipo_medicamento tm ON tm.id_tipo_medicamento=m.id_tipo_medicamento;

create view vpago as

select pa.id_pago,pa.codigo_pago,pa.monto,pe.nombre_personal from pago pa

join personal pe ON pe.id_personal=pa.id_pago;

create view vpersonal as

select p.id_personal,p.nombre_personal,p.apellido_paterno,p.apellido_materno,p.direccion,p.telefono,p.celular,tp.nombre_tipo_personal from personal

p

join tipo_personal tp ON tp.id_tipo_personal=p.id_tipo_personal;

create view vnotapedido as

select np.id_nota_pedido, np.codigo_nota_pedido, np.fecha_compra, np.fecha_recepcion,

np.importe,p.nombre_personal,pr.nombre,enp.nombre_estado from nota_pedido np

join personal p on p.id_personal=np.id_personal

join proveedor pr on pr.id_proveedor=np.id_proveedor

join estado_nota_pedido enp on enp.id_estado_nota_pedido=np.id_estado_nota_pedido

create view vguiaremision as

select gm.id_guia_remision,gm.codigo_remision,gm.fecha_emision,gm.forma_envio,gm.observacion,pr.nombre from guia_remision gm

join proveedor pr on pr.id_proveedor=gm.id_proveedor

create view vfactura_recibida as

select fr.id_factura,fr.codigo_factura_recibida, fr.fecha_entrega,p.codigo_pago,p.monto from factura_recibida fr

join pago p on p.id_pago=fr.id_pago

create view vguia_compra as

select gc.id_guia_compra,gc.codigo_guia_compra, pr.nombre,p.nombre_personal,np.codigo_nota_pedido, f.codigo_factura_recibida,gr.codigo_remision

from guia_compra gc

join proveedor pr on pr.id_proveedor=gc.id_proveedor

join personal p on p.id_personal=gc.id_personal

join nota_pedido np on np.id_nota_pedido=gc.id_nota_pedido

join factura_recibida f on f.id_factura=gc.id_factura

join guia_remision gr on gr.id_guia_remision=gc.id_guia_remision

create view vdetalleMNP as select

dmnp.Detalle_MNP,dmnp.precio,dmnp.cantidad,dmnp.fecha_vencimiento,m.nombre_medicamento,m.unidad,np.id_nota_pedido from Detalle_MNP

dmnp

join medicamento m on m.id_medicamento=dmnp.id_medicamento

join nota_pedido np on np.id_nota_pedido=dmnp.id_nota_pedido;

APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA CONSTRUCCIÓN DE BASES DE DATOS...

Documents

Transcript of APLICACIÓN DE UNA MATRIZ DE ESCENARIOS Y SU INFLUENCIA EN LA CONSTRUCCIÓN DE BASES DE DATOS...