BD

CONTENIDO

1. INFORMACIÓN DEL DOCUMENTO.............................................................................2

2. INTRODUCCIÓN...........................................................................................................3

3. CONTEXTO...................................................................................................................4

4. ALCANCE DEL SISTEMA.............................................................................................5

5. REQUERIMIENTOS DEL SISTEMA.............................................................................6

5.1 REQUERIMIENTOS FUNCIONALES...........................................................................6

5.2 REQUERIMIENTOS NO FUNCIONALES....................................................................6

6. ARQUITECTURA...........................................................................................................7

7. MODELO CONCEPTUAL..............................................................................................8

8. MODELO LÓGICO........................................................................................................9

9. MODELO FÍSICO........................................................................................................10

9.1 DBMS..........................................................................................................................10

9.2 ENTIDADES................................................................................................................11

9.3 DICCIONARIO DE DATOS.........................................................................................12

10. USO DEL LENGUAJE DE CONSULTA – SQL..........................................................19

11. ANEXOS.....................................................................................................................20

11.1 REALES....................................................................................................................20

11.2 FICTICIOS..................................................................................................................20

1

1. INFORMACIÓN DEL DOCUMENTO

Proyecto: Sistema de Información para la gestión de permisos de Post -consumo de la Autoridad Nacional de Licencias Ambientales - ANLA

Nombre del Documento: Diseño de Base de Datos del SistemaEstado: RevisiónTipo de documento: MedianoEtapa: DiseñoElaborado por: Carolina Cantor Díaz

Cynthia López ParraFernando Cañón Celis

Responsable revisión: Carlos Infante

2

2. INTRODUCCIÓN

El presente documento muestra el diseño de base de datos del sistema, el cual determina los datos a emplear y/o almacenar, a través de procesos de definición, organización, estructuración y modelado de datos con el fin de permitir la centralización y gestión de información (datos relevantes), para ello se expondrán el modelo conceptual, el modelo lógico y el modelo físico del sistema. Adicionalmente, presenta ejemplos de manipulación de los datos por medio del uso del lenguaje de consulta (SQL).

3

3. CONTEXTO

Se requiere generar la base de datos de los permisos de Pos consumo que maneja la Autoridad Nacional de Licencias Ambientales –ANLA-. Los permisos pos consumo engloban dos grandes categorías, los GDP y SRS; los GDP corresponden al Seguimiento al Plan de Gestión Devolución de Productos Pos consumo de Baterías Usadas Plomo Acido y de medicamentos. Y los SRS corresponden a la Aprobación de los Sistemas de Recolección Selectiva y Gestión Ambiental de Residuos para bombillas, llantas usadas, pilas y/o acumuladores, y computadores o periféricos.

Los interesados en obtener alguno de los permisos listados anteriormente dentro de Pos consumo realizan ante la ANLA el radicado del formulario de solicitud de apertura del trámite para evaluación del permiso solicitado. El formulario tanto para GDP y SRS consta de múltiples secciones en donde se recoge información de interés sobre el titular o el vocero, empresas que conforman el colectivo de solicitante (titular), el tipo de residuo o producto sobre el que se realiza la solicitud realizando la descripción de ciertas características, adicionalmente se describe la forma de recolección de los residuos (mecanismo de recolección: centros o puntos de acopio), la ubicación de los puntos de gestión final de los residuos o productos, otros permisos asociados a la solicitud realizada (licencia ambiental, permiso de emisiones y permiso de vertimientos) y las metas mínimas proyectadas de recolección.

Posteriormente la ANLA evalúa la solicitud, para ello, asigna a un responsable de la entidad quien tiene la responsabilidad de emitir un concepto técnico por cada permiso asignado a su nombre, luego internamente el trámite pasa otro profesional jurídico para que genere un acto administrativo.

Cabe resaltar, que luego del acto administrativo que otorga el permiso, el solicitante está en la obligación de reportar las metas de recolección alcanzadas de forma anual a la ANLA, quien a su vez determina unas visitas de seguimiento y determina si cumple o no con el permiso otorgado.

4

4. ALCANCE DEL SISTEMA

Construir un sistema de información que permita gestionar toda la información referida en el contexto, como es; identificar, registrar y consultar los datos asociados a los procesos de consentimiento de permisos de los posconsumos (SRS y GDP) a las diferentes empresas a los que se les ha hecho seguimiento, indicando los puntos de recolección, sedes, centros de acopio y centros de almacenamiento visitados, así como el la información de los profesionales que hicieron el seguimiento.

5

5. REQUERIMIENTOS DEL SISTEMA

5.1 REQUERIMIENTOS FUNCIONALES

La especificación de los requerimientos funcionales no se contempla en este documento, pues es un entregable de la etapa de análisis que es bastante detallado y demanda bastante tiempo, pues está enfocada en especificar todas las acciones que el Sistema de Información para la gestión de permisos de Posconsumo de la Autoridad Nacional de Licencias Ambientales debe cumplir, en este caso hace referencia a la construcción de porlets, formularios e interfaces que le permitirán al usuario realizar acciones CRUD (Create, Read, Update, Delete) a los diferentes módulos de información del sistema, como por ejemplo:

“Se requiere que el sistema posea una herramienta que permita generar indicadores sobre el seguimiento a permisos de Posconsumo concedidos en un tiempo determinado (años) y que despliegue los resultados en una tabla y con un gráfico (diagrama estadístico), este último debe ser dinámico, es decir, se actualiza a medida que el usuario final cambié los datos en el formulario, adicionalmente debe incluir un control que permita seleccionar el tipo de gráfico a usar para la representación de los datos resultantes”.

En este ejemplo se pueden definir dos requerimientos específicos, uno para generar indicadores (independiente de la información que se utilice) y otro para generar salida gráfica de los indicadores, puesto que pueden ser muchos indicadores, lo que haría pensar que la relación de un caso de uso “Crear indicador” hacía un caso de uso “Generar gráfico estadístico” sería de tipo “include”.

No obstante, se pueden listar (a manera general) algunos de los requerimientos que implican diseñar y construir la base de datos para este proyecto:

Requerimientos para seguimiento:

- Crear una herramienta interna para identificar los posconsumos (SRS y GDP) a los que se les ha hecho seguimiento, señalando los puntos de recolección,

6

sedes, centros de acopio y centros de almacenamiento visitados, así como el la información de los profesionales que hicieron el seguimiento.

- Crear una herramienta para programar las visitas de seguimiento teniendo en cuenta la distribución geográfica los datos de referenciación, los seguimientos ya realizados, y criterios de programación establecidos por el grupo, para esta programación se tienen en cuenta los siguientes criterios.

1. Tipo de Plan o Sistema (Individual o Colectivo), al tipo colectivo es obligatorio el seguimiento año a año.

2. Se verifican los porcentajes de seguimiento que debe cumplirse anualmente, y con base a ello se define el número de expedientes a visitar. Para sacar los individuales es a partir seguimiento que debe cumplirse anualmente menos los Colectivos.

3. Se tiene en cuenta las siguientes variables para los individuales: Tamaño de Proyecto (meta de recolección –Aplica para los 5 trámites- o la cobertura de comercialización -Medicamentos-), seguimientos efectuados y el tipo de incumplimiento histórico.

4. Define las ciudades en las que se encuentran las sedes y la cantidad de cada plan o sistema que se encuentra en cada una de ellas y el tiempo que se requiere por revisión de cada expediente (en una semana se visitan de 2 a 3 sedes), es necesario incluir la herramienta de selección de ruta.

*Los cambios de los sitios de recolección se reportan en el informe anual, lo que implica que en la programación se tengan en cuenta lugares que ya no están en funcionamiento, por lo tanto estos cambios deben registrarse vía web (VITAL), tan pronto se haga y con ello reposar o mandar una alerta para la programación para no tener en cuenta estos puntos.

Además incluirse vía web el cambio por movilidad es decir pasar de un individual a un colectivo, para que actualice la base de datos de manera automática o mediante una alerta.

5. Se asigna los lugares de las visitas teniendo en cuenta el paso (4), visitas efectuadas en seguimientos anteriores y realizar el cruce de los cronogramas de

7

otros trámites del grupo de permisos, con el objeto de optimizar recursos (Eje: Sello Ambiental y Basilea –mov. transfronterizos de residuos peligrosos-), dado que trabajan este trámite junto a otros.

- El formato de seguimiento sea diligenciado mediante dispositivos móviles, en el que se incluya además registros fotográficos.

Concepto Técnico:

El evaluador que visita los colectivos (aprox. 12-14 visitas durante aprox. 7-10 días) o individuales (aprox. 2 y 6 visitas en 3-5 días), a partir de estas visitas quien genera el concepto técnico, es la persona que visita la sede, sin embargo a los que visitan los sitios de recolección diligencian un formato diferente al de la sede, el cual también varía de acuerdo a si es punto o centro; documentos que soportan el concepto.

En el concepto, se sustrae información contenida en la base de datos de seguimiento por ejemplo tablas.

No se finaliza el proceso hasta que no se acoja el concepto técnico por un Auto de seguimiento enumerado, montado y reportado en SILA.

5.2 REQUERIMIENTOS NO FUNCIONALES

Estos requerimientos no se consignan en el presente documento, sino en el documento de especificación de requerimientos, puesto que hacen referencia a pseudorequisitos, requisitos en cuanto a criterios de calidad de software, requerimientos de modelamiento, presentación (diseño gráfico, GUI, entre otros) , administrativos y documentales, los cuales se especifican en otros artefactos definidos en las etapas de planificación, análisis y diseño (arquitéctonico) del sistema. Ver numeral 11.2 en la sección Anexos.

8

6. ARQUITECTURA

Para la construcción del proyecto Sistema de Información para la gestión de permisos de Posconsumo de la Autoridad Nacional de Licencias Ambientales – ANLA, se plantea un sistema bajo tecnología web con arquitectura de tres capas usando el patrón Modelo Vista Controlador – MVC, puesto que:

La arquitectura de tres capas consiste en dividir los accesos y entes de comunicación de los diferentes componentes de un sistema por medio de la capa de presentación, lógica de negocio y persistencia. En este sentido, el equipo cliente actúa como frontal y no contiene ninguna llamada directa a la base de datos, en su lugar, el cliente se comunica con un servidor de aplicaciones que a su vez se comunica con la persistencia (capa de datos) para acceder a los datos.

Por otra parte, el modelo vista controlador es un patrón de arquitectura de software que aplica para arquitecturas de tres capas, pues separa los datos y la lógica de negocio de una aplicación, de la interfaz de usuario y del módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone definir componentes para la representación de la información, y componentes para la interacción del usuario. Éste modelo no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

9

7. MODELO CONCEPTUAL

En un diseño conceptual de base de datos se incluye la creación de un esquema o modelo conceptual, el cual es independiente de las consideraciones físicas, los sistemas de gestión de base de datos, los lenguajes de programación y las plataformas de hardware. Además, deben permitir que los usuarios no técnicos entiendan dicho esquema, para ello, prescinde de especificaciones sobre cómo se implementará la base de datos, pero, incluye el detalle en términos de la naturaleza, estructura y significado de los datos. A continuación, se expone el modelo conceptual del proyecto Sistema de Información para la gestión de permisos de Posconsumo de la Autoridad Nacional de Licencias Ambientales – ANLA.

Ilustración 1. Modelo Entidad Relación

Fuente: Elaboración propia con herramienta de software libre - DIA

10

8. MODELO LÓGICO

En este modelo se transforma el esquema genérico y/o conceptual en un modelo de datos determinado (relacional o no relacional) para un sistema de gestión de bases de datos determinado. El modelo lógico puede realizarse manualmente, o automáticamente a través del uso de herramientas CASE (Ingeniería de Software Asistida por Computadora) desde un diseño conceptual o un diseño físico; para este último se utiliza el concepto de ingeniería inversa. En cualquier caso, el resultado final es un junto de comandos de lenguaje de definición de datos, que puede ser usado de forma interactiva, o como parte de un software para crear la base de datos.

A continuación se presenta el modelo lógico de la base de datos relacional del proyecto Sistema de Información para la gestión de permisos de Posconsumo de la Autoridad Nacional de Licencias Ambientales – ANLA.

Ilustración 2. Modelo Relacional

Fuente: Elaboración propia con herramienta CASE de software libre - PgModeler

11

9. MODELO FÍSICO

En este modelo se realiza el proceso de implementación física del modelo de datos lógico en un sistema de gestión de bases de datos (DBMS). Incluye la selección y construcción de estructuras (esquemas, catálogos, disparadores, entre otros), tablas, relaciones y demás, de la base de datos; y el aseguramiento del acceso a las relaciones de forma rápida, eficiente y segura (p.ej. Número de transacciones procesadas por minuto y la cantidad de espacio que necesitará la base de datos).

Para ver el modelo físico del proyecto Sistema de Información para la gestión de permisos de Posconsumo de la Autoridad Nacional de Licencias Ambientales – ANLA, ver el numeral 11.1 de la sección Anexos que indica la ruta de acceso.

9.1 DBMS

Para la construcción del modelo físico de la base de datos del proyecto se empleó el Sistema de Gestión de Base de Datos PostgreSQL 9.3, pues éste posee características como:

Alta concurrencia: Mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en inglés) que permite que mientras un proceso escribe en una tabla, otros (muchos) accedan a la misma tabla sin necesidad de bloqueos.

Amplia variedad de tipos nativos: soporte para números de precisión arbitraria, texto de largo ilimitado, figuras geométricas (con una variedad de funciones asociadas), direcciones IP (IPv4 e IPv6), direcciones MAC y Arrays.

Creación de claves foráneas. Creación de triggers. Un disparador o trigger es una acción específica que

se realiza de acuerdo a un evento, cuando éste ocurra dentro de la base de datos.

Creación de vistas. Herencia de tablas. Integridad transaccional. Transacciones para BD distribuidas.

12

9.2 ENTIDADES

Una entidad es un objeto real o abstracto del que se requiere almacenar información. En el modelo físico las entidades son representadas a través de tablas que se construyen en el DBMS.

A continuación se definen las tablas construidas en el modelo físico del proyecto.

NOMBRE DESCRIPCIÓN

titular_permiso Representa la empresa, organización o Unidad de representación jurídica que solicita el permiso de Posconsumo

contacto Contiene la información para ubicar o contactar al titular o vocero.

empresa_plan Contiene información básica sobre la(s) empresa(s) que son representadas a través de un titular o vocero.

permiso Contiene características del permiso de Posconsumo.

sitio_recoleccion Posee información sobre los lugares en que se centraliza los productos de Posconsumo.

empresa_gestora Contiene características de las empresas que poseen o administran sitios de recolección.

seguimiento_tecnico Posee información de referencia sobre la auditoría que se realiza a los sitios de recolección.

permiso_gestora Posee información de referencia sobre los permisos de carácter ambiental que tienen las empresas gestoras.

concepto_tecnico Posee información de referencia sobre el dictamen técnico que poseen los permisos de Posconsumo.

acto_administrativo Posee información de referencia sobre el dictamen jurídico de un permiso de Posconsumo.

meta Posee información sobre las metas de recolección.

sitio_gestora Permite la relación de muchos a muchos entre sitio_recoleccion y empresa_gestora.

13

9.3 DICCIONARIO DE DATOS

Es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.

En este apartado se identifican y describen los atributos de cada tabla así:

Entidad: titular_permiso Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain

Values Notes

True nit_titular Integer True - - - Identificador único del Titular ovocero del permiso.

False

nombre_titular

Character varying

False

64 - - Nombre del Titular o vocero del permiso.

Entidad: contacto Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain

Values

Notes

True Id_contacto Serial True - - - Identificador único del contacto.

False

nombre_contacto Character varying

False

64 - - Nombre del contacto.

False

telefono_contacto Integer - - - Teléfono del contacto.

False

departamento_contacto

Character varying

False

64 - - Departamento del contacto.

False

municipio_contacto Character varying

False

64 - - Municipio del contacto.

False

correo_electronico Character varying

False

64 - - E-mail del contacto.

False

direccion Character varying

False

64 - - Dirección del contacto.

Entidad: empresa_plan Tipo Entidad: Alfanumérica

14

PK Name Type Not Null

Len

Prec

Domain Values Notes

True nit_empresa Integer True - - - Identificador único de la empresa que es representada por el titular.

False

razon_social Character varying

False

64 - - Nombre de la empresa que es representada por el titular.

False

año_presentacion

date False

- - - Año en que la empresa presentó la solicitud.

False

año_retiro date False

- - - Año en el que la empresa se retira del proceso.

False

tipo_participante Character varying

True 64 tipo_participante

Colectivo

Individual

Indica si la empresa representada por el titular es una sola o si es un grupo de empresas.

Entidad: permiso Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain Values Notes

True id_permiso integer True - - - Identificador único del permiso de Posconsumo.

False

numero_radicado

integer False

- - - Numero de radicado de la solicitud del permiso.

False

fecha_radicado date False

- - - Fecha en el que se realiza la solicitud del permiso.

False

tipo_permiso Character varying

True 64 tipo_permiso SRSGDP

Indica si el permiso es un sistemas de Recolección Selectiva o un Plan de Gestión Devolución de Productos Pos consumo

False

categoria Character varying

True 64 - categoria BupaMedicamentosPilas

Indica la categoría del producto de Posconsumo.

15

LlantasComputadoresBombillas

False

subcategoria Character varying

True 64 - subcategoria CelularesConvencionalesGas/medLHCLHIHMotocicletasMotocicletas-vehículosPCPilas/BotonPilas/Boton-convencionalesVehiculosVeterinarios

Indica la subcategoría del producto de Posconsumo.

False

estado_tramite Character varying

True 64 - estado_tramite

AprobadoNo aprobadoEn ejecución

Indica el estado de trámite del servicio.

False

fecha_estado Date False

- - - - Fecha de actualización del estado del trámite.

False

monto Integer False

- - - - Valor del seguimiento o evaluación del permiso.

Entidad: sitio_recoleccion Tipo Entidad: Alfanumérica

PK Name Type Not Null Len

Prec

Domain Values Notes

True id_sitio serial True - - - - Identificador único del sitio de recolección de Posconsumo.

False mecanismo_recoleccion

Character varying

True 64 - mecanismo_recoleccion

centro_acopiopunto_recoleccion

Indica los tipos de sitio (mecanismo) de recolección.

False departamento_sitio

Character varying

True 64 - Departamento_sitio

todos los 32 departamentos de colombia

Departamentos de Colombia en el que se ubica el sitio de recolección.

False municipio_sitio Character varying

False 64 - - - Municipios de Colombia en el que se ubica el sitio de

16

recolección.False teléfono_sitio Integer False - - - - Teléfono del sitio de

recolección.False latitud_grados Numeric False 2 0 - - Coordenada

geográfica, latitud, grados.

False latitud_min Numeric False 2 0 - - Coordenada geográfica, latitud, minutos.

False latitud_seg Numeric False 2 2 - - Coordenada geográfica, latitud, segundos.

False longitud_grados

Numeric False 2 0 - - Coordenada geográfica, longitud, grados.

False longitud _min Numeric False 2 0 - - Coordenada geográfica, longitud, minutos.

False longitud _seg Numeric False 2 2 - - Coordenada geográfica, latitud, segundos.

Entidad: empresa_gestora Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len Prec

Domain Values Notes

True id_gestora serial True - - - - Identificador único del sitio de la empresa gestora del sitio de recolección.

False nombre_gestora

Character varying

False 64 - - - Nombre de la empresa gestora

False tipo_gestion Character varying

True - - tipo_gestion AprovechamientoAlmacenamiento

Tipos de empresa gestora del sitio de recolección.

False departamento_gestora

Character varying

True - - departamento_gestora

todos los 32 departamentos de Colombia

Departamento en el que se ubica la empresa gestora.

False municipio_gestora

Character varying

False 64 - - - Municipio en el que se ubica la empresa gestora.

False dirección_gestora

Character varying

False 64 - - - Dirección en el que se ubica la empresa gestora.

17

Entidad: seguimiento_tecnico Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain Values Notes

True numero_seguimiento

Integer True - - - - Identificador único del seguimiento técnico.

False responsable_seguimiento

Character varying

False 64 - - - Nombre del responsable de hacer el seguimiento técnico.

False tipo_seguimiento

Character varying

True - tipo_seguimiento

DocumentalVisitaSin visitaModificacionEvaluaciónN/R

Tipos de seguimiento técnico.

False numero_actoseguimiento

Integer False - - - - Número del acto administrativo de seguimiento técnico.

False fecha_seguimiento

date False - - - - Fecha en que se realiza el seguimiento técnico.

False estado_seguimiento

Character varying

True - - estado_seguimiento

CumpleNo cumple

Tipos de estado del seguimiento técnico.

Entidad: permiso_gestora Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain

Values Notes

True id_pergestora serial True - - - - Identificador único del permiso de la empresa gestora.

False numero_resolucion

integer False - - - - Número de la resolución del permiso para la empresa gestora.

False fecha_resoluci date False - - - - Fecha de la resolución.

18

onFalse vigencia Character

varyingFalse 64 - - - Vigencia del permiso de la

empresa gestora.False autoridad_am

bientalInteger False 64 - Nombre de la entidad que otorga

los permisos a las empresas gestoras.

False tipo_pergestora

Character varying

True - - tipo_pergestora

LicenciaPermiso vertimientosPermiso emisiones

Tipos de permisos para las empresas gestoras.

Entidad: concepto_tecnico Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec Domain

Values Notes

True numero_concepto

Integer True - - - - Identificador único del concepto técnico

False fecha_evaluacion

date False - - - - Fecha de evaluación para realizar el concepto técnico al permiso de Posconsumo.

False responsable_concepto

Character varying

False 64 - - - Nombre del responsable de realizar el concepto técnico.

False fecha_concepto

date False - - - - Fecha de emisión del concepto técnico.

False fecha_actoconcepto

date False - - - - Fecha del acto administrativo sobre los conceptos técnicos.

False tiempo_elaboracion

Integer False - - - - Tiempo (días) de la ejecución de un concepto técnico.

Entidad: acto_administrativo Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain Values Notes

True numero_acto

Integer True - - - - Identificador único de acto administrativo.

False responsable Charact False 64 - - - Nombre del

19

_acto er varying

responsable del acto administrativo.

False fecha_resolucionacto

date False - - - - Fecha de resolución del acto administrativo.

False estado_acto Character varying

True - - estado_acto AprobadoRevisiónSeguimientoRequerimientoN/AN/R

Tipos de estado de los actos administrativos.

Entidad: meta Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain Values Notes

True id_meta serial True - - - - Identificador único de la meta.

False

año date False

- - - - Meta por año.

False

p_importado_unidad

integer False

- - - - Cantidad de productos importados.

False

p_importado_peso

integer False

- - - - Peso del producto importado.

False

p_mercado_unidad

integer False

- - - - Cantidad de productos en el mercado.

False

p_mercado_peso integer False

- - - - Peso del producto en el mercado.

False

estado_meta Character varying

True - - estado_meta

Alcanzada

No alcanzada

Tipos del estado de meta.

Entidad: sitio_gestora Tipo Entidad: Alfanumérica

PK Name Type Not Null

Len

Prec

Domain

Values Notes

20

True Id_sitio Integer True - - - - Identificador único de la tabla sitio_recoleccion.

Adicionalmente la clave foránea está vinculada también.

True Id_gestora Integer True - - - - Identificador único de la tabla empresa_gestora.

Adicionalmente la clave foránea está vinculada también.

21

10. USO DEL LENGUAJE DE CONSULTA – SQL

Para poder gestionar los datos de la base de datos el DBMS utiliza un lenguaje de manipulación de datos (DML) para realizar funciones como: buscar, añadir, suprimir y modificar dentro de su lógica, adicionalmente se emplea el lenguaje de consulta (SQL) por el usuario para extraer información de la base de datos. El lenguaje de consulta permite al usuario hacer requisiciones de datos sin tener que escribir un programa, usando instrucciones como por ejemplo, el SELECT.

La secuencia conceptual de operaciones que ocurren para acceder a cierta información que contiene una base de datos es la siguiente:

1. El usuario solicita cierta información contenida en la base de datos.

2. El DBMS intercepta este requerimiento y lo interpreta.

3. El DBMS realiza las operaciones necesarias para acceder y/o actualizar la información solicitada.

A continuación, se presentan algunos ejemplos de consultas (Querys) sobre la base de datos SI_Permisos_BD:

Enunciado:

Query:

22

11. ANEXOS

11.1 REALES

Modelo Entidad Relación, archivo: SI_Permisos_MER.dia Modelo Entidad Relación, archivo: SI_Permisos_MER.png Modelo Relacional, archivo: SI_Permisos_ML.dbm Modelo Relacional, archivo: SI_Permisos_ML.png Modelo Físico dentro de la Base de Datos, archivo: SI_Permisos_BD.backup

Ubicación: Carpeta comprimida: Trabajo_Final_BD_19092014

11.2 FICTICIOS

Los siguientes anexos refieren a documentación elaborada en otras fases o etapas del ciclo de vida de un proyecto de software (Planificación, Análisis, Diseño), para este caso; un trabajo académico, las referencias son “imaginarias”, no obstante, aplicarían siguiendo la metodología RUP.

Plan de Gestión. Documento de alcance del sistema. Documento de análisis del sistema. Documento de especificación de requerimientos. Documento de especificación de casos de uso. Documento de diseño arquitectónico del sistema.

23