informe seminario de grado modelo entidad relacion
TRANSCRIPT
INFORME SEMINARIO DE GRADO MODELO ENTIDAD RELACION
DIAGRAMA DE CLASES CASOS DE USO SV-AMBU
ALVARO FELIPE CRUZ CUBIDES
BRAYAN ANDRES AVENDAÑO SILVA
MANUEL STIVEN GONZALEZ MAHECHA
SEMINARIO DE GRADO
SV-AMBU
UNIVERSIDAD COOPERATIVA DE COLOMBIA
FACULTAD DE INGENIERIA
PROGRAMA INGENIERIA DE SISTEMAS
IBAGUE -TOLIMA
2017
INFORME SEMINARIO DE GRADO MODELO ENTIDAD RELACION
DIAGRAMA DE CLASES CASOS DE USO SV-AMBU
PRESENTADO POR:
ALVARO FELIPE CRUZ CUBIDES
CODIGO: 370506
BRAYAN ANDRES AVENDAÑO SILVA
CODIGO: 371630
MANUEL STIVEN GONZALEZ MAHECHA
CODIGO: 371567
PRESENTADO A:
JORGE MANUEL PACHECO CASADIEGO
SEMINARIO DE GRADO
SV-AMBU
UNIVERSIDAD COOPERATIVA DE COLOMBIA
FACULTAD DE INGENIERIA
PROGRAMA INGENIERIA DE SISTEMAS
IBAGUE -TOLIMA
2017
Esta obra está bajo una Licencia Creative Commons Atribución-
NoComercial-CompartirIgual 4.0 Internacional.
1. INDICE
1. INDICE ............................................................................................................. 3
2. INTRODUCCIÓN ............................................................................................. 6
3. PLANTEAMIENTO DEL PROBLEMA .............................................................. 8
4. OBJETIVO GENERAL ..................................................................................... 9
5. OBJETIVOS ESPECIFICOS .......................................................................... 10
6. MARCO TEORICO ........................................................................................ 11
6.2. PLATAFORMA ............................................................................................ 12
7. METODOLOGIA ............................................................................................ 14
7.1. ANALISIS DEL SISTEMA ............................................................................ 14
7.1.1. ALCANCE ................................................................................................ 14
7.1.2. REQUERIMIENTOS FUNCIONALES ...................................................... 15
7.2. DISEÑO ....................................................................................................... 26
7.2.1. ARQUITECTURA MODULAR .................................................................. 28
7.2.1.1. DIAGRAMA DE JERARQUIA DE MODULOS ......... ¡Error! Marcador no definido.
7.3. CONSTRUCCIÓN ....................................................................................... 34
7.3.1. CAPA DE ALMACENAMIENTO .................. ¡Error! Marcador no definido.
7.3.2. CAPA LOGICA ......................................................................................... 34
7.3.2.1. PROCEDIMIENTOS ............................................................................. 34
7.3.3. CAPA DE PRESENTACIÓN .................................................................... 35
7.3.3.1. INTERFAZ MENU PRINCIPAL ............................................................. 35
7.3.3.2. INTERFAZ DE EDICION ....................................................................... 41
7.3.3.2.1. GENERADA DE FORMA AUTOMATICA .......................................... 42
7.3.3.2.2. GENERADA CON LLAMADO A PROCEDIMIENTOS PL/SQL ......... 47
8. CONCLUSION 9. REFERENCIAS
LISTA DE FIGURAS
FIGURA 01. EDITAR GRUPOS ESPECIALIZADOS DE VENTAS……………………………..14
FIGURA 02. EDITAR UBICACIONES DE VENTAS AMBULANTES…………………………..15
FIGURA 03. EDITAR INFORMACIÓN BÁSICA DE LOS VENDEDORES………………………16
FIGURA 04. EDITAR INFORMACIÓN SOCIAL DE LOS VENDEDORES……………………...18
FIGURA 05. EDITAR GRADOS DE ESCOLARIDAD…………………………………………19
FIGURA 06. EDITAR SEGURIDAD SOCIAL……………………………..…………………..20
FIGURA 07. EDITAR NORMAS………………………………..……………………………21
FIGURA 8. MODELO CONCEPTUAL PARTE 1……………………………..………………..22
FIGURA 9. MODELO CONCEPTUAL PARTE 2……………………………..………………..23
FIGURA 10. MODELO RELACIÓN……………………………..……………………………24
FIGURA 11. ARQUITECTURA DE INSERCIÓN VENDEDOR…………………………………..25
FIGURA 12. ARQUITECTURA DE CONSULTA VENDEDOR…………………………….…….26
FIGURA 13. ARQUITECTURA DE INSERCIÓN GRUPO DE VENDEDOR ………………....…..27
FIGURA 14. ARQUITECTURA DE CONSULTA DE UN GRUPO DE VENDEDOR……………….28
FIGURA 15. PÁGINA DE INGRESO……………………………..…………………………..33
FIGURA 16. PÁGINA MENÚ……………………………..…………………………………34
FIGURA 17. INFORMACIÓN SOBRE EL SITIO………………………………………………35
FIGURA 18. JURÍDICO……………………………..………………………………………35
FIGURA 19. GALERÍAS……………………………..……………………………………..36
FIGURA 20. CONTACTOS……………………………..…………………………………..37
FIGURA 21. REPORTES……………………………..…………………………………….38
FIGURA 22. EDICIÓN……………………………..……………………………................39
FIGURA 23. FORM UBICACIÓN……………………………..……………………………..39
FIGURA 24. REPORTE 1……………………………..…………………………………….40
FIGURA 25. REPORTE 2……………………………..……………………………………40
FIGURA 26. FORM FAMILIAR……………………………..……………………………….41
FIGURA 27. FORM NORMAS……………………………..………………………………..41
FIGURA 28. FORM EDICION NORMA…………….……..…………………………………42
FIGURA 29. FORM VENDEDOR……………………………………………………………42
FIGURA 30. REPORTE 3 ……………………………..……………………………..….…43
FIGURA 31. GESTIÓN DE VENDEDOR……………………………..………………………44
FIGURA 32. GESTIÓN FAMILIARES ……………………………………………………….45
2. INTRODUCCIÓN
En la actualidad se ha podido evidenciar que a través del tiempo se ha presentado
en nuestra ciudad la proliferación o el aumento de los vendedores ambulantes, los
cuales originan algunas situaciones de orden público en cuanto a la invasión del
espacio púbico el cual no ha podido ser controlado por las autoridades
gubernamentales que no han creado estrategias o centros de ubicación que
permitan conocer las necesidades reales de esta población que labora en las calles
de manera no formalizada.
Aun teniendo en cuenta los avances en el manejo de información y la
implementación de las diversas tecnologías cuyo objetivo ha sido mejorar la
accesibilidad a estos grandes volúmenes de datos, que le permitan al hombre, en
las empresas o comunidades, tener un mayor control mediante los diferentes
elementos de hardware y software para procesarlos más rápido, obtener
información precisa, oportuna y confiable que contribuya al planteamiento y a la
toma de decisiones. A diferencia de lo que solía ser antiguamente los sistemas de
información y el manejo de estos, era más complicado, eran precarios, lentos, no
del todo seguros y sobre todo costosos.
Es aquí donde las autoridades gubernamentales deberán contar con una base de
datos y sistema de información que permita cuantificar en forma clara y precisa el
potencial de vendedores ambulantes que habitan en la ciudad y que generan
problemas de competencia al sector de comercio formalizado. Para esto se requiere
un estudio socioeconómico apoyado en herramientas de informática moderna y
tecnológicas de información que cuente con un software avanzado y robusto de
gran capacidad que permita clasificar a dichos vendedores por actividad comercial,
grupo de población, norma que regula su actividad y por ubicación, donde este
sistema cuente con un repositorio de información, sistema de captura, manejo y
reporte de estos.
A la vez tratar de evitar que la población infantil recurra a estos tipos de trabajo
donde algunos casos son apoyados por sus padres y no permiten que la niñez asista
a centros de educación y formación; por tal motivo se hace perentorio que las
autoridades municipales planifiquen y cree programas de apoyo, capacitación,
información y además brinden los mecanismos necesarios para que este grupo de
mercado logre desempeñar una actividad comercial de manera digna responsable
y segura.
3. PLANTEAMIENTO DEL PROBLEMA
Debido al constante crecimiento de la población Ibaguereña se ha notado que el
sector de vendedores ambulantes se encuentra invadiendo las calles de la ciudad,
en razón a que no se cuenta con otros medios de trabajo ni posibilidades laborales
que les permitan lograr un nivel de vida aceptable para su familia.
Es por esto que mucho de los ciudadanos que ejercen esta labor se ven abocados
a tener que vender sus productos de manera ambulante, invadiendo el espacio
público que es muy reducido por el alto crecimiento urbanístico en la ciudad.
Este problema se ha generalizado y en algunas ocasiones se observa el abuso de
autoridad quienes decomisan los productos a los vendedores, los privan de su
libertad y los humillan de manera inhumana; por tal razón la administración
municipal deberá crear fuentes de empleo que permitan combatir este flagelo laboral
como es el incremento de vendedores ambulantes sobre todo en temporadas de
fiestas como el mes de junio y temporada navideña.
La ciudad no cuenta con una herramienta que facilite el control del crecimiento de
esta población y gracias a que no hay un minucioso seguimiento de esta información
no es fácil tomar decisiones con las personas que usan este medio para la obtención
del sustento diario, pese al esfuerzo que han hecho las autoridades encargadas no
se ha podido dar una mejor calidad de vida a estas personas.
4. OBJETIVO GENERAL
Desarrollar un sistema de información que controle la gestión de datos de los
vendedores ambulantes en el centro de la ciudad de Ibagué.
5. OBJETIVOS ESPECIFICOS
Categorizar por grupos de ventas a los vendedores ambulantes.
Detallar las ubicaciones donde más se agrupan estas personas.
Identificar posibles ideas que solucionen la reubicación de estas personas
para librar el espacio público.
6. MARCO TEORICO
6.1. ANTECEDENTES
En [1] contempla el “espacio público el conjunto de inmuebles públicos y los
elementos arquitectónicos y naturales de los inmuebles privados, destinados por su
naturaleza, por su uso o afectación, a la satisfacción de necesidades urbanas
colectivas que transcienden, por tanto, los límites de los intereses, individuales de
los habitantes.”
Por ende, se define este espacio público como las áreas que están siendo
requeridas no solo por peatonales sino vehicular, también se tienen en cuenta las
áreas para la recreación publica, ya sea activa o pasiva para la tranquilidad
ciudadana. Se reconocen a los vendedores informales ambulantes como [2] “Sin
confianza legítima, aquellas personas naturales que se dediquen a la
comercialización de bienes de uso y/o consumo que no se encuentren debidamente
acreditados con la prenda o chaleco entregado por la secretaria de Gobierno
Municipal”
[3]“En Bogotá el 35% de los trabajadores están en la informalidad. En Medellín el
15,3%; Barranquilla el 13%; Bucaramanga 4%; Cúcuta e Ibagué 17%, Pereira y
Pasto 8%. Mientras que en Cali este indicador descendió 2,5% y en Manizales
4,5%.”
Las cifras en algunas ciudades disminuyen, pero en otras aumentan gracias al
crecimiento que cada una de estas tiene, aumentando el desplazamiento de
personas que usan este método para adquirir su sustento diario, la ciudad siempre
se verá enfrentada al crecimiento o desarrollo ilegal de barrios en lugares de esta,
e invasión de los mismos en lugares públicos.
[4] Gracias a esto nace la duda de como poder tener un mayor control de esto. Los
sistemas de gestión de información de mano de las tecnologías que avanzan día a
día son un gran aporte para estos temas.
Estos sistemas han cambiado la manera en que se mueven las organizaciones
actualmente, por su fácil uso se obtienen importantes mejores, ya que estas
optimizan los procesos operativos y suministran la información necesaria para la
toma de decisiones.
6.2. Plataforma
Según un artículo en Gestiopolis “Un Sistema de Información es un conjunto de
elementos que interactúan entre sí con el fin de apoyar las actividades de una
empresa o negocio. En un sentido amplio, un sistema de información no
necesariamente incluye equipo electrónico. Sin embargo, en la práctica se utiliza
como sinónimo de “sistema de información computarizado”.
Oracle Application Express
[5] Oracle Application Express te permite diseñar, desarrollar e implantar
aplicaciones responsivas sobre la base de datos usando sólo tu navegador web.
Entérate de cómo tomar ventaja de esta característica gratuita y totalmente
soportada de la base de datos de Oracle.
[6] Esta aplicación nos permite desarrollar en un moderno y poderoso entorno de
desarrollo para implantar aplicaciones de manera muy rápida, personalizable y fácil.
Maneja un entorno de desarrollo basado en web, editor de código con resaltado de
sintaxis y sugerencias de código, diseño intuitivo con herramientas de tipo “arrastrar
y soltar”, haz cambios al momento sin tener que compilar o implantar la aplicación,
generación de reportes sobre los metadatos de la aplicación, soporte completo de
SQL, PL/SQL y Javascript, integración perfecta con las características de la base
de datos de Oracle (Data Mining, Spatial, RAS, y más), integración con servicios
REST y SOAP, extensible con Plug-ins, interfaces de usuario para dispositivos
móviles con jQuery Mobile.
[7] PL / SQL es un lenguaje de procedimientos diseñados específicamente para
abrazar las sentencias SQL dentro de su sintaxis. PL / SQL unidades de programa
son compilados por el servidor de base de datos Oracle y almacenados dentro de
la base de datos. Y en tiempo de ejecución, tanto de PL / SQL y SQL se ejecutan
dentro del mismo proceso de servidor, con lo que la eficiencia óptima. PL / SQL
hereda automáticamente la solidez, seguridad y portabilidad de la base de datos
Oracle.
El motivo porque se utilizan estos lenguajes es porque una aplicación que utiliza
bases de datos Oracle es inútil a menos que se conserva sólo los datos correctos y
completos. La manera tradicional de asegurar esto es para exponer la base de datos
sólo a través de una interfaz que oculta los detalles de implementación - las tablas
y las sentencias SQL que operan en éstos.
7. METODOLOGIA
7.1. ANALISIS DEL SISTEMA
7.1.1. ALCANCE Elaboración de un sistema de información, el cual facilite la administración de la
información referente a los aspectos comerciales, sociales y normativos pertinentes
a los vendedores ambulantes del centro de Ibagué. Lo mismo que agregar,
visualizar, modificar datos de un usuario.
Este sistema de información pretende además mantener y actualizar la información
de eventos, decretos, leyes y todo el ámbito jurídico que está detrás del sector
económico de los vendedores ambulantes y el espacio público.
Con el desarrollo de este proyecto se pretende diseñar el SI y BD que permitan
tener un control efectivo sobres las personas que ejercen esta profesión en el centro
de la cuidad de Ibagué, logrando un mejoramiento en las soluciones de estadísticos,
otorgamiento de permisos, y reubicación de los vendedores informales.
7.1.2. REQUERIMIENTOS FUNCIONALES EDITAR GRUPOS ESPECIALIZADOS DE VENTAS
Registrar Grupos:
Se requieren los siguientes datos para el registro de grupos especializados de ventas: nombre, descripción, productos, ubicación, hora de inicio y hora de finalización.
Modificar Grupos:
Se podrá realizar modificación de datos respecto a los grupos especializados de ventas en cualquier momento, además cada acción quedará guardada en una bitácora.
Consultar Grupos
Se podrán consultar los siguientes datos de los grupos: nombre, descripción, productos, ubicación, hora de inicio y hora de finalización.
Generar Reporte de Grupos
Al momento de generar el reporte los usuarios tendrán la opción de visualizarlo por sea por pantalla o imprimirlo, para así tener un soporte de la información que haya en el sistema de información
Reportes
Por sexo
Fecha ingreso
Edades
Situación familiar
Antecendentes
Normas que los acobijan
Cumplimientos de dichas normas
Figura 01. Editar Grupos especializados de Ventas.
En este caso de uso en la figura 01 se puede apreciar que está diseñado para realizar registro, modificación, consulta sobre los diferentes grupos especializados de ventas, pero también es posible generar reportes de los mismos.
EDITAR UBICACIONES DE VENTAS AMBULANTES
Registrar Ubicación de Venta
Se requieren de los siguientes datos para el registro de Ubicación de Veta: nombre y descripción de ubicación.
Modificar Ubicación de Venta
Se podrá realizar modificación de datos respecto a la Ubicación de Venta en cualquier momento, además cada acción quedará guardada en una bitácora.
Figura 02. Editar Ubicaciones De Ventas Ambulantes
En este caso de uso en la figura 02 se puede apreciar que está diseñado para realizar registro y modificación sobre la ubicación de las ventas ambulantes.
EDITAR INFORMACION BASICA DE LOSVENDEDORES
Registrar Información Básica de los Vendedores:
Se requieren de los siguientes datos para el registro de la información básica de los vendedores: nombre, tipo de identificación, identificación, grupo de venta al que pertenece.
Modificar Información Básica de los Vendedores
Se podrá realizar modificación de datos respecto a la Información Básica de los Vendedores en cualquier momento, además cada acción quedará guardada en una bitácora.
Consultar Información Básica de los Vendedores
Se podrán consultar los siguientes datos de la Información básica de los Vendedores: nombre, tipo de identificación, identificación, grupo de venta al que pertenece.
Generar Reporte de Información Básica de los Vendedores
Figura 03. Editar Información Básica De Los vendedores
En este caso de uso en la figura 03 se puede apreciar que está diseñado para realizar registro, modificación, consulta de la información básica de los vendedores, pero también es posible generar reportes de los mismos.
EDITAR INFORMACION SOCIAL DE LOS VENDEDORES
Registrar Información Social de los Vendedores
Se requieren de los siguientes datos para el registro de la información social de los Vendedores: municipio de procedencia, dirección de residencia, nivel de escolaridad, seguridad social, estrato socioeconómico, integrantes del núcleo familiar.
Modificar Información Social de los Vendedores
Se podrá realizar modificación de datos respecto a la Información Social de los Vendedores en cualquier momento, además cada acción quedará guardada en una bitácora.
Consultar Información Social de los Vendedores
Se podrán consultar los siguientes datos de la Información Social de los Vendedores: municipio de procedencia, dirección de residencia, nivel de escolaridad, seguridad social, estrato socioeconómico, integrantes del núcleo familiar.
Figura 04. Editar Información Social De Los Vendedores
En este caso de uso en la figura 04 se puede apreciar que está diseñado para realizar registro, modificación y consulta sobre la información social de los vendedores.
CONSULTAR DATOS DEL VENDEDOR
Consultar Ubicación de los Vendedores:
Se podrán consultar los siguientes datos de la Ubicación de los Vendedores: nombre del vendedor, nombre y descripción de ubicación.
Generar Reporte de la Ubicación de los Vendedores
Generar Reporte del Grupo al que Pertenecen los Vendedores
EDITAR GRADOS DE ESCOLARIDAD
Registrar Grados De Escolaridad
Se requieren de los siguientes datos para el registro de Grados de Escolaridad: id del grado, nombre del grado de escolaridad, descripción del grado de escolaridad.
Modificar Grados De Escolaridad
Se podrá realizar modificación de datos respecto a los Grados de Escolaridad en cualquier momento, además cada acción quedará guardada en una bitácora.
Figura 05. Editar Grados De Escolaridad
En este caso de uso en la figura 05 se puede apreciar que está diseñado para realizar registro y modificación de los grados de escolaridad de cada vendedor.
EDITAR SEGURIDAD SOCIAL
Registrar Seguridad Social
Se requieren de los siguientes datos para el registro de la Seguridad Social: id de la seguridad social, tipo de seguridad social, detalle de la seguridad social.
Modificar Seguridad Social
Se podrá realizar modificación de datos respecto a la Seguridad Social en cualquier momento, además cada acción quedará guardada en una bitácora.
Figura 06. Editar Seguridad Social
En este caso de uso en la figura 06 se puede apreciar que está diseñado para realizar registro y modificación de la seguridad social de cada vendedor
EDITAR NORMAS
Registrar Normas:
En el registro de normas se debe ingresar el código de la norma, tipo, numero, año de inicio de vigencia.
Modificar Normas:
Al modificar las normas se actualizarán los mismos datos que se ingresaron en el registro.
Figura 07. Editar Normas
En este caso de uso en la figura 07 se puede apreciar que está diseñado para realizar registro y modificación de las diferentes normas que debe cumplir cada uno de los vendedores ambulantes.
7.1.3. MODELO CONCEPTUAL DE DATOS
Figura 8. Modelo conceptual parte 1
pertenece
se organiza
comercializanreferenciado
aplica
ejecuta
contiene
pertenece a
tip_norma
id_tipo_norma
cod_tipo
<pi> Short integer
Integer
<M>
Identifier_1 <pi>
norma
cod_norma
num_norma
año_norma
descrip
direccion_archivo
<pi> Integer
Integer
Date
Variable characters (150)
Variable characters (90)
<M>
Identifier_1 <pi>
acciones
id_accion
descripcion_accion
<pi> Short integer
Variable characters (150)
<M>
Identifier_1 <pi>
tema
id_tema
descripcion_tema
<pi> Short integer
Variable characters (150)
<M>
Identifier_1 <pi>
grupo_norma
id_grupo_norma <pi> Short integer <M>
Identifier_1 <pi>
grupo_venta
id_grupo
nombre_grupo
descrip
<pi> Short integer
Variable characters (50)
Variable characters (150)
<M>
Identifier_1 <pi>
producto
id_producto
nombre_producto
<pi> Short integer
Variable characters (50)
<M>
Identifier_1 <pi>
gurpo/ubicacion
id_grupo/ubicacion
frecuencia
hora_inicio
hora_final
<pi> Short integer
Variable characters (100)
Time
Time
<M>
Identifier_1 <pi>
ubicacion
id_ubicacion
nombre_ubicacion
descripcion_ubicacion
<pi> Short integer
Variable characters (50)
Variable characters (150)
<M>
Identifier_1 <pi>
Parte uno y dos del modelo conceptual en la figura 08 y figura 09, diseño realizado en Sqldeveloper donde se muestran las relaciones y los atributos de cada entidad presente en la base de datos. Encontramos la estructura de la base de datos, contando con las entidades, vendedor, familiar, seguridad social, grupo de venta, grupo de vendedor, estrato, municipio, familia del vendedor, norma, tipo de norma, se encuentran debidamente relacionadas según sea
7.2. DISEÑO
se identifica
pertenecee
pertenece aa
pertenece--
ultimo grado
corresponde a
proviene de
pertenece
vive en
se ubica
grupo_venta
id_grupo
nombre_grupo
descrip
<pi> Short integer
Variable characters (50)
Variable characters (150)
<M>
Identifier_1 <pi>
grupo_vendedor
id_grupo_vendedor <pi> Short integer <M>
Identifier_1 <pi>
municipio
id_municipio
nombre_municipio
<pi> Short integer
Variable characters (20)
<M>
Identifier_1 <pi>
vendedor
tipo_id
id_vendedor
nom_vendedor
<pi>
Variable characters (20)
Integer
Variable characters (50)
<M>
Identifier_1 <pi>
estrato
id_estrato
estrato
<pi> Short integer
Variable characters (10)
<M>
Identifier_1 <pi>
escolaridad
id_escolaridad
nivel_escolaridad
descrip
<pi> Short integer
Variable characters (10)
Variable characters (150)
<M>
Identifier_1 <pi>
seguridad_social
id_seguridad
nombre_entidad
descrip
<pi> Short integer
Variable characters (50)
Variable characters (150)
<M>
Identifier_1 <pi>
familia/vendedor
consecutivo <pi> Integer <M>
Identifier_1 <pi>
familiar
id_familiar
nombre_familiar
identificacion
<pi> Integer
Variable characters (50)
Integer
<M>
Identifier_1 <pi>
tipo_familiar
id_tipo_familiar
tipo_familiar
<pi> Short integer
Variable characters (20)
<M>
Identifier_1 <pi>
Figura 9. Modelo conceptual parte 2
tip_norma
id_tipo_norma
cod_tipo
SMALLINT
INTEGER
<pk>
norma
cod_norma
id_tipo_norma
id_tema
num_norma
año_norma
desc_grupo_venta
direccion_archivo
INTEGER
SMALLINT
SMALLINT
INTEGER
DATE
VARCHAR2(150)
VARCHAR2(90)
<pk>
<fk1>
<fk2>
acciones
id_accion
id_tema
descripcion_accion
SMALLINT
SMALLINT
VARCHAR2(150)
<pk>
<fk>
tema
id_tema
descripcion_tema
SMALLINT
VARCHAR2(150)
<pk>
grupo_norma
id_grupo_norma
cod_norma
id_grupo
SMALLINT
INTEGER
SMALLINT
<pk>
<fk1>
<fk2>
grupo_venta
id_grupo
nombre_grupo
desc_grupo_venta
SMALLINT
VARCHAR2(50)
VARCHAR2(150)
<pk>
grupo_vendedor
id_grupo
id_grupo_vendedor
id_vendedor
SMALLINT
SMALLINT
INTEGER
<pk,fk1>
<pk>
<fk2>
producto
id_producto
id_grupo
nombre_producto
SMALLINT
SMALLINT
VARCHAR2(50)
<pk>
<fk>
grupo/ubicacion
id_grupo
id_grupo/ubicacion
id_ubicacion
frecuencia
hora_inicio
hora_final
SMALLINT
SMALLINT
SMALLINT
VARCHAR2(100)
DATE
DATE
<pk,fk1>
<pk>
<fk2>
ubicacion
id_ubicacion
nombre_ubicacion
descripcion_ubicacion
SMALLINT
VARCHAR2(50)
VARCHAR2(150)
<pk>
municipio
id_municipio
nombre_municipio
SMALLINT
VARCHAR2(20)
<pk>
vendedor
tipo_id
id_vendedor
id_municipio
id_escolaridad
mun_id_municipio
id_estrato
id_seguridad
nom_vendedor
ape_vendedor
genero
telefono
VARCHAR2(20)
INTEGER
SMALLINT
SMALLINT
SMALLINT
SMALLINT
SMALLINT
VARCHAR2(50)
VARCHAR2(45)
VARCHAR2(45)
VARCHAR2(45)
VARCHAR2(45)
<pk>
<fk1>
<fk4>
<fk2>
<fk3>
<fk5>
estrato
id_estrato
estrato
SMALLINT
VARCHAR2(10)
<pk>
escolaridad
id_escolaridad
nivel_escolaridad
desc_grupo_venta
SMALLINT
VARCHAR2(10)
VARCHAR2(150)
<pk>
seguridad_social
id_seguridad
nombre_entidad
desc_grupo_venta
SMALLINT
VARCHAR2(50)
VARCHAR2(150)
<pk>
grupo_familiar
consecutivo
id_vendedor
id_familiar
INTEGER
INTEGER
INTEGER
<pk>
<fk1>
<fk2>
familiar
id_familiar
id_tipo_familiar
nombre_familiar
identificacion
INTEGER
SMALLINT
VARCHAR2(50)
INTEGER
<pk>
<fk>
tipo_familiar
id_tipo_familiar
tipo_familiar
SMALLINT
VARCHAR2(20)
<pk>
Figura 10. Modelo Relación
7.2.1. ARQUITECTURA MODULAR 7.2.1.1. Arquitectura de inserción de vendedor Figura 11. Arquitectura de inserción vendedor
En la figura 11 se aprecia la arquitectura que se utiliza para la inserción de un vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)
INSERTAR VENDEDOR
REG_VENDEDOR
MSG REG_VENDEDOR
CAPA PRESENTACIÓN
CONTROLADOR DE LA INSERCIÓN
VERIFICAR VENDEDOR
DESPLEGAR MENSAJE
MEN
RES
Id_vendedor
7.2.1.2 Arquitectura de consulta Vendedor. En la figura 12 se aprecia la arquitectura que se utiliza para la consulta de un vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)
Figura12.Arquitectura de consulta a un VENDEDOR
DESPLEGAR VENDEDOR
Id_vendedor
RES
Id_vendedor
V_REG
V_REG
MSG Id_vendedor
CAPA PRESENTACIÓN
CONTROLADOR VERIFICADOR DE LA
CONSULTA
VERIFICAR VENDEDOR CONSULTAR VENDEDOR
7.2.1.3 Arquitectura de inserción Grupo de Vendedor En la figura 13 se aprecia la arquitectura que se utiliza para la inserción de un grupo de vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)
Figura 13. Arquitectura de inserción GRUPO DE VENDEDOR
INSERTAR GRUPO DE VENDEDOR
REG_GRUPOVENDEDOR
MSG REG_GRUPOVENDEDOR
CAPA PRESENTACIÓN
CONTROLADOR DE LA INSERCIÓN
VERIFICAR GRUPO DE VENDEDOR
DESPLEGAR GRUPO DE VENDEDOR
MEN
RES
Id_GRUPOVENDEDOR
7.2.1.4 Arquitectura de consulta de un Grupo de Vendedor. En la figura 14 se aprecia la arquitectura que se utiliza para la consulta de un grupo vendedor, con su paso a paso en cada capa (Presentación, lógica, acceso a datos)
Figura 14. Arquitectura de consulta a un GRUPO DE VENDEDOR
DESPLEGAR GRUPO DE VENDEDOR
Id_GRUPOVENDEDOR
RES
Id_GRUPOVENDEDOR
V_REG
V_REG
MSG Id_GRUPOVENDEDOR
CAPA PRESENTACIÓN
CONTROLADOR VERIFICADOR DE LA
CONSULTA
VERIFICAR GRUPO DE VENDEDOR
CONSULTAR GRUPO DE VENDEDOR
7.2.1.5 DESCRIPCIÓN DE MÓDULOS
7.2.1.5.1 Funcionalidad consulta proyecto Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador verificador de la consulta, por medio de la variable ID_PROYECTO, después el módulo controlador verificador de la consulta invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje. Controlador verificador de la consulta: Este módulo facilita el control de la secuencia para hacer el procedimiento consultar un proyecto a la base de datos, atreves de la invocación de los módulos VERIFICAR PROYECTO, CONSULTAR PROYECTO Y DESPLEGAR MENSAJE. Verificar proyecto: Este módulo es llamado atreves de la variable ID_PROYECTO, que trae acoplamiento de datos (atributos), para constatar la existencia o no del proyecto, enviando así, una bandera de control por medio de la variable RES para continuar el proceso. Consultar Proyecto: Permite la consulta de datos del proyecto a la base de datos por medio de la variable ID_PROYECTO que trae los atributos correspondientes al proyecto. Desplegar Mensaje: Generar y muestra el mensaje en la capa gráfica.
7.2.1.5.2 Funcionalidad inserción proyecto Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador de la inserción por medio de la variable REG_PROYECTO, después el módulo controlador de la inserción invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje.
Capa de presentación: Permite la captura de datos de un proyecto, invocando el módulo controlador de la inserción por medio de la variable REG_PROYECTO, después el módulo controlador de la inserción invoca esta capa por medio de la variable MSG la cual genera y despliega el mensaje. Controlador de la Inserción: Este módulo facilita el control de la secuencia para hacer el procedimiento de insertar a la base de datos, atreves de la invocación de los módulos VERIFICAR PROYECTO, INSERTAR PROYECTO Y DESPLEGAR MENSAJE. Verificar Proyecto: Este módulo es llamado atreves de la variable ID_PROYECTO, que trae acoplamiento de datos (atributos), para constatar la existencia o no del proyecto, enviando así, una bandera de control por medio de la variable RES para continuar el proceso. Insertar Proyecto: Permite el registro de datos del proyecto a la base de datos por medio de la variable REG_PROYECTO que trae los atributos correspondientes al proyecto. Desplegar Mensaje: Generar y muestra el mensaje en la capa gráfica.
7.3. CONSTRUCCIÓN 7.3.1. CAPA DE ALMACENAMIENTO “Script de la base de datos Vendedores (Ver Anexo A)”.
7.3.2. CAPA LOGICA
7.3.2.1. PROCEDIMIENTOS Se muestran a continuación los procedimientos utilizados para la inserción de algunas entidades o atributos del aplicativo, con su respectivo procedimiento diseñado el SQLDEVELOPER. -------------------------------------------------------------------------------------------------------------- Insertar municipio create or replace procedure insertarmunicipio(reg_municipio municipio%rowtype) is begin insert into municipio values(reg_municipio.id_municipio, reg_municipio.nombre_municipio); commit; end;
Insertar Familiar create or replace PROCEDURE PRINSERTAFAMILIAR (rgfamiliar in familiar%rowtype, omsn OUT varchar2) IS BEGIN INSERT INTO FAMILIAR(ID_FAMILIAR,ID_TIPO_FAMILIAR,NOMBRE_FAMILIAR,IDENTIFICACION) VALUES(rgfamiliar.ID_FAMILIAR,rgfamiliar.ID_TIPO_FAMILIAR,rgfamiliar.NOMBRE_FAMILIAR,rgfamiliar.IDENTIFICACION);
omsn := 'Familiar asignado satisfactoriamente'; EXCEPTION WHEN OTHERS THEN omsn := SQLERRM; END; -------------------------------------------------------------------------------------------------------------- Insertar vendedor create or replace PROCEDURE PRINSERTAVENDEDOR (rgvendedor in vendedor%rowtype, omsn OUT varchar2) IS BEGIN INSERT INTO VENDEDOR(ID_VENDEDOR,ID_MUNICIPIO,ID_ESCOLARIDAD,MUN_ID_MUNICIPIO,ID_ESTRATO,ID_SEGURIDAD,NOM_VENDEDOR,APE_VENDEDOR,GENERO,TELEFONO,MAIL) VALUES (rgvendedor.ID_VENDEDOR,rgvendedor.ID_MUNICIPIO,rgvendedor.ID_ESCOLARIDAD,rgvendedor.MUN_ID_MUNICIPIO,rgvendedor.ID_ESTRATO, rgvendedor.ID_SEGURIDAD,rgvendedor.NOM_VENDEDOR,rgvendedor.APE_VENDEDOR,rgvendedor.GENERO,rgvendedor.TELEFONO,rgvendedor.MAIL); omsn := 'VENDEDOR Creada Satisfactoriamente'; EXCEPTION WHEN OTHERS THEN omsn := SQLERRM; END;
7.3.3. CAPA DE PRESENTACIÓN
7.3.3.1. INTERFAZ MENU PRINCIPAL Página Ingreso
Figura 15. Página de ingreso
En la Figura 15 se muestra donde el usuario deberá ingresar con los datos que se le van a brindar para tener total acceso a la aplicación, claramente los usuarios tendrán un rango de permisos y de acceso al aplicativo, ocultando áreas según el rol que cumplan.
Página Menú Figura 16. Página Menú.
En la figura 16 se encuentran las áreas de información para los usuarios visitantes de la página, a continuación, se presenta cada una de ellas. Sobre el sitio
Figura 17. Información sobre el Sitio
En la Figura 17 se muestra la información básica sobre el sitio de aplicación, sobre su uso y lo que se puede encontrar dentro de este. Jurídico Figura 18. Jurídico
En la figura 18 se muestra la información respecto a el ámbito jurídico que implementa el sistema de información y en parte definiciones establecidas por el ente gubernamental, donde se referenciaran las normas que acobijan las distintas clasificaciones de los vendedores. Galerías Figura 19. Galería.
En la figura 19 se muestra la página donde se podrán observar distintas fotos de cómo se encuentra la ciudad en donde más se concentran los vendedores ambulantes, el estado en que se encuentran, la ubicación y la manera en la que obstruyen el espacio público.
Contáctenos Figura 20. Contactos
En la figura 20 se muestra el área donde el usuario invitado podrá enviar solicitudes de información o de petición de registro en la base de datos o modificaciones, fácilmente se podrá contactar el usuario y brindar información respecto a la solicitud.
Reportes Figura 21. Reportes
En la figura 21 se muestra el área donde se generarán algunos reportes de información básica para los demás usuarios visitantes, como tales la lista de normas, ubicaciones y alguna otra información no tan comprometedora de los vendedores.
7.3.3.2. INTERFAZ DE EDICION Figura 22. Edicion.
En la figura 22 se muestra la interfaz de edición se encuentran algunas pestañas donde se podrán hacer modificaciones y entre estas hay dos (Social, Vendedor) las cuales están elaboradas por procedimientos PL/SQL pero de igual manera están del modo automático en los “Form”
7.3.3.2.1. GENERADA DE FORMA AUTOMATICA Figura 23. Form Ubicación
En la figura 23 se muestra el formulario donde se puede evidenciar como la aplicación al seleccionar una ubicación el permitirá realizar la edición del nombre de esta y también su descripción.
Figura 24. Reporte 1
En la figura 24 se muestra el Reporte 1 generado con edición habilitada se muestra en la figura 24, para que liste las ubicaciones en las cuales se encuentran ubicados los vendedores ambulantes, con el nombre de la ubicación y la descripción de esta, claramente este reporte permite la adición, edición y eliminación de estas mientras el rol en el cual haya ingresado tenga los permisos. Form Social Figura 25. Reporte 2
En la figura 25 se muestra el reporte de la información social del vendedor, se listará la información de este y de igual manera tambien es posible modificar esta para facilitar la actualización de la información en la base de datos, encontramos información general de los familiares de cada vendedor, con numero de identificación, nombres y tipo de familiar. Figura 26. Form Familiar
Edición de un familiar según la lista anterior en la Figura 26, en esta muestra el tipo de familiar, el id del familiar, el nombre del familiar, y el número de identificación, permitiendo actualizar estos datos en caso de algún ingreso erróneo. Form Normas Figura 27. Form Normas
En la figura 27 se encuentra la lista de normas que acobijan las distintas clasificaciones de los vendedores ambulantes, según tipo, tema, n° de norma, año y descripción de esta, de igual manera permite la modificación de cada una de estas. Figura 28. Form edición Norma
En la figura 28 se muestra como se puede editar la información de la norma registrada, claramente estas solo podrán modificarla usuarios con los permisos adecuados ya que se habla de algo legal y no deberá tener modificaciones fácilmente a menos de que a nivel nacional haya una actualización de esta. Form Vendedor Figura 29. Form Vendedor
En esta figura 29 se puede realizar la edición de la información del vendedor en la cual se registra el municipio, escolaridad, estrato, seguridad social, nombres, apellidos, genero, teléfono y e-mail. Facilitando así la actualización de datos de los vendedores registrados en el sistema. Figura 30. Reporte 3
En la figura 30 se muestra el reporte generado de los vendedores que se encuentran actualmente inscritos en la base de datos, con toda su información incluyendo información social, ubicación y las normas que los acobijan.
7.3.3.2.2. GENERADA CON LLAMADO A PROCEDIMIENTOS PL/SQL Figura 31. Gestión de Vendedor
En la Figura 31 se visualiza el formulario en el que se podrá ingresar un nuevo vendedor con los datos que solicita, claramente es obligatorio rellenar cada campo ya que se encuentra señalizado como requerido.
Figura 32. Gestión Familiares
En la Figura 32 se muestra el formulario para el ingreso de un nuevo familiar agregando la conexión directamente con el vendedor para que así quede relacionado a la hora de realizar búsquedas.
CONCLUSIONES
Este proyecto el cual tiene como bases principales el proceso de registro, almacenamiento y control de los datos de los vendedores ambulantes del centro de la cuidad de Ibagué, mejorando la administración de esta información y de lo que podemos concluir:
Con el diseño y desarrollo de este sistema de información; si se logra implementar
y se registran los datos correspondientes se obtendrán reportes que ayudarán a la
administración municipal a tomar mejores decisiones en determinado momento.
Para los trabajadores del área de Dirección de Espacio Público y Control Urbano,
se hace cada vez más evidente la necesidad de contar con un sistema automatizado
que les permita registrar los datos y obtener los informes de manera ágil, para dar
respuestas rápidas y llevar un control más riguroso de este tipo de información.
REFERENCIAS [1] Ley N° 9 de 1989, Capitulo II, Articulo 5. enero 11, Tomado 14 febrero de 2017. [2] Decreto No. 0091 de 2005, febrero 21 de 2005. Artículo Tercero, Tomado 14 de febrero de 2017. [3] Barranquilla, Cúcuta e Ibagué con el mayor número de informales, tomado de www.dinero.com [4] Sitio oficial de la alcaldía municipal de Ibagué - Por Ibagué con todo el Corazón. (2017). Alcaldía caracteriza vendedores informales de la ciudad. [online] Disponible en: http://www.ibague.gov.co/portal/seccion/noticias/index.php?Idnt=1537 [5] Oracle.com. (2017). Oracle APEX (Aplication Express in Oracle DB) [online] Disponible en: http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html [6] Oracle.com. (2017). Oracle PL/SQL. [online] Disponible en: http://www.oracle.com/technetwork/issue-archive/2011/11-mar/o21plsql-242570.html [7] Oracle.com. (2015). Oracle PL/SQL. [online] Disponible en: http://www.oracle.com/technetwork/database/features/plsql/index.html