Escolar Documentos
Profissional Documentos
Cultura Documentos
INTRODUCCIÓN .......................................................................................................................... 4
1. OBJETIVOS ............................................................................................................................ 5
GENERAL ........................................................................................................................... 5
ESPECIFICOS ..................................................................................................................... 5
2. METODOLOGÍA .................................................................................................................... 6
2.1. Fase Análisis de requisitos ............................................................................................... 6
Requerimientos Funcionales ............................................................................................ 6
Elaboración Modelo Conceptual de Datos ....................................................................... 6
2.2. Fase de Diseño ................................................................................................................. 6
Elaboración del modelo físico .......................................................................................... 7
Diseño CRUD .................................................................................................................. 7
2.3. Fase de Construcción ....................................................................................................... 7
3. ANÁLISIS DE REQUERIMIENTOS..................................................................................... 8
3.1. ALCANCE ....................................................................................................................... 8
3.2. REQUERIMIENTOS FUNCIONALES .......................................................................... 9
Descripción de procesos ................................................................................................... 9
3.3. MODELO CONCEPTUAL DE DATOS ....................................................................... 12
Concepto Modelo Conceptual ........................................................................................ 12
Diagrama Entidad relación E / R (Modelo Conceptual) ................................................ 13
Descripción de Entidades ............................................................................................... 13
4. DISEÑO................................................................................................................................. 14
4.1. MODELO FÍSICO DE DATOS .................................................................................... 14
Diagrama Relacional (Modelo Físico) ........................................................................... 15
Descripción De Las Tablas ............................................................................................ 15
4.2. ARQUITECTURA MODULAR.................................................................................... 19
Diagrama de Jerarquía de Módulos ................................................................................ 20
Descripción de Módulos................................................................................................. 22
5. CONSTRUCCIÓN ................................................................................................................ 24
5.1. PRUEBAS ...................................................................................................................... 24
Inserción ......................................................................................................................... 24
Actualización .................................................................................................................. 25
Eliminación .................................................................................................................... 26
Consultas ........................................................................................................................ 27
6. CONCLUSIONES ................................................................................................................. 29
7. REFERENCIAS .................................................................................................................... 30
8. ANEXOS ............................................................................................................................... 31
8.1. CAPA DE ALMACENAMIENTO ................................................................................ 31
Script de la Base de Datos .............................................................................................. 31
8.2. CAPA LÓGICA ............................................................................................................. 31
Procedimientos ............................................................................................................... 31
INTRODUCCIÓN
organización sin importar su objeto empresarial, por tal razón las tecnologías de la información
han ayudado a la creación de sistemas inteligentes que brinden a los usuarios la seguridad de
preservar y gestionar su información de la manera más eficiente. Para esto se ha optado por el
diseño e implementación de bases de datos que cumplan con el objetivo principal que es conservar
colegio de secundaria el cual tiene como fin satisface los requerimientos funcionales suministrados
por el tutor. Lo primero que se expondrá es el diseño de los modelos relacionales conceptual y
físico realizados con una herramienta CASE denominada Power Designer, seguido a estó se realiza
la capa de almacenamiento la cual consta del script para la generación de la base de datos la cual
es de tipo ORACLE, por último se encuentra la capa lógica en la cual se muestran los
GENERAL
Implementar las capas de almacenamiento de datos y lógica de un aplicativo que soporte los
colegio de secundaria.
ESPECIFICOS
elementos_devolutivos.
funcionarios, y elementos_devolutivos.
La metodología que se aplicará constará de tres fases las cuales serán análisis de
requerimientos, diseño y construcción; en cada una de las cuales se detallará lo desarrollado para
Requerimientos Funcionales
Los requerimientos funcionales fueron asignados por el tutor por medio de un documento
debidamente detallado con cada una de las necesidades del módulo con esto lo que se obtuvo
Se realizó basado en la técnica del diagrama relacional E/R, primero se identificaron las
entidades, luego sus relaciones entre sí y por último los atributos de cada entidad, definiendo sus
llaves primarias, su obligatoriedad y los tipos de datos q permiten ingresar en cada campo.
2.2.Fase de Diseño
En esta fase se desarrollaron las actividades de estructuración de los modelos de la Base de datos,
se obtuvo el modelo conceptual y el modelo físico de la BD y una base de datos relacional; para
el diseño de los modelos se empleó una herramienta CASE la cual es Power Designer.
Elaboración del modelo físico
El diseño físico de la base de datos se creó en base al modelo conceptual previo, también se
realizó aplicando la técnica del modelo entidad relación. Durante el diseño físico, se transforman
Diseño CRUD
Se realiza el diseño de los CRUD (Create, read, Update, delete) a través de diagramas de
Jerarquía de módulos los cuales tienen como fin explicar el camino que recorren los
2.3.Fase de Construcción
En esta fase se obtuvo el Script de la BD , se realizó la población de las tablas y se crearon los
El Script se obtiene a partir del modelo físico de datos por medio de la herramienta CASE
Para el cargue del script, se crea un usuario por medio de la consola de la herramienta
SQL*Plus de Oracle XE, luego se realiza la creación de una nueva base de datos en el entorno de
desarrollo en el entorno de desarrollo Sql Developer y se realiza la conexión de la DB con el
Población de tablas
Para la población de las tablas se realizaron los insert directamente desde el entorno de
programación incrustado en Oracle y que soporta todas las consultas. La estructura para la
("valor1", "valor2",...).
consulta y auditoría.
posterior a esto se realizaron las pruebas a cada uno de los procedimientos para comprobar
3. ANÁLISIS DE REQUERIMIENTOS
3.1. ALCANCE
aplicativo cliente servidor con tecnología de base de datos Oracle que soporte los procesos del
relacionados con el control de los elementos devolutivos, esto se realiza por medio de
transacciones para el préstamo o devolución de los elementos con una especificación detallada,
Descripción de procesos
REGISTRO DE FUNCIONARIOS
Todos los funcionarios que deseen pedir elementos al colegio deben estar o ser registrados
para llevar a cabo dicho proceso y tener un mejor control en cuanto a quien se le ha prestado y si
aún tiene o no algo pendiente. Los principales datos que deben aparecer en dicho registro son:
Se requiere tener un registro de los elementos que se van a prestar y que tienen carácter de
devolutivo. Para ello es necesario tener en cuenta los siguientes datos: identificador numérico del
devolutivo, nombre del devolutivo, descripción del devolutivo, año de adquisición, valor de
Al momento que un funcionario desee realizar un préstamo sobre algún elemento, se debe
del préstamo, tipo de documento y número de documento del funcionario a quien se le hace el
préstamo.
devolutivo a prestar, la cantidad prestada se asume con el valor de 1 y el estado de aplicación del
Al momento que un funcionario desee realizar una devolución de algún elemento devolutivo,
AP= aplicado)
APLICACIÓN DE LOS COMPROBANTES TRANSACCIONALES DE DEVOLUTIVOS
Por cada comprobante de préstamo, el sistema debe actualizar el estado de disponibilidad del
Una relación de los elementos devolutivos del colegio clasificado por tipo de devolutivo
Dado el identificador del elemento devolutivo, el sistema muestre los datos del elemento.
Dados el tipo de documento y el número de documento de un funcionario, el sistema
debe generar una relación donde se especifiquen los datos básicos de los elementos
transacción y los datos del funcionario relacionado con la transacción. Para la generación
del reporte, el sistema solicitará el identificador del elemento devolutivo para el que se
requiere el historial.
Identifica las relaciones de más alto nivel entre las diferentes entidades. El modelo entidad –
En esta sección se encontrará el modelo conceptual de datos del diagrama E/R (entidad –
Ilustración 1
Modelo Conceptual de Datos
Descripción de Entidades
Tabla 1
Descripción de Entidades
ENTIDADES DESCRIPCIÓN
Representa el cargo que se le asigne a cada
CARGO
funcionario del colegio.
Representa la dependencia a la cual pertenece el
DEPENDENCIA
funcionario.
Registra el detalle de la transacción que se
realiza, allí se especifica el elemento y la
DETALLE TRANSACCIÓN
cantidad de elementos solicitados por el
funcionario.
Representa los elementos devolutivos con los que
ELEMENTOS DEVOLUTIVOS
cuenta el colegio para su préstamo.
FUNCIONARIOS Registro de los datos básicos del funcionario.
IDENTIFICACIÓN Registra el tipo de identificación del funcionario.
MUNICIPIO Registra el nombre del municipio.
Registra el tipo al que pertenece el elemento
TIPO DE ELEMENTO devolutivo (ej, audiovisual, proyección,
mobiliario etc.)
Se registran el tipo de transacción que se pueden
TIPO DE TRANSACCIÓN realizar en el sistema (ej. Préstamos,
devoluciones, etc.)
Aquí se lleva a cabo el registro de la transacción
se incluirá el funcionario que la realiza, y que
TRANSACCIONES tipo de transacción realiza al igual que la fecha,
esto para que posteriormente sea asociado a un
detalle.
Fuente: Elaboración Propia
4. DISEÑO
El modelo de datos físico muestra una representación de cómo será construida la base de
datos. Este modelo especifica todas las estructuras de la tabla incluidos el nombre, tipo de datos
y restricciones de las columnas, la llave principal, la o las llaves foráneas y las relaciones entre
El modelo físico de datos se crea a partir del diagrama entidad relación en el cual las tablas
representan a las entidades y la interdependencia entre las tablas a las relaciones. Y sirve para
conocer los tipos de datos que almacenarán los campos de la base de datos. (Editorial, 2013)
módulo Elementos Devolutivos, así como la descripción de cada una de sus tablas.
Diagrama Relacional (Modelo Físico)
Ilustración 2
Modelo Físico de Datos
Cargo Tipo_Transaccion
Identificacion
Id_Identificacion CHAR(2) <pk> FK_TRANSACC_REFERENCI_TIPO_TRA
Tipo_Identificacion VARCHAR2(40)
FK_FUNCIONA_CARGO_ACT_CARGO
Transacciones
Funcionarios
Id_Funcionarios NUMBER(3) <pk> FK_DETALLE__GENERA_TRANSACC
Id_Municipio NUMBER(3) <fk3>
Id_Dependencias NUMBER(3) <fk4>
Id_Identificacion CHAR(2) <fk2> Detalle_Transaccion
Id_Cargo NUMBER(2) <fk1> Id_Transaccion NUMBER(10) <pk,fk3>
Nombres VARCHAR2(30) Id_Detalle NUMBER(10) <pk>
Apellidos VARCHAR2(30) Det_Id_Transaccion NUMBER(10) <fk2> FK_DETALLE__REGISTRA_ELEMENTO
Num_Identificacion NUMBER(10) Det_Id_Detalle NUMBER(10) <fk2>
Genero CHAR(1) Id_Elemento NUMBER(3) <fk1>
Cant NUMBER(1)
Elementos_Devolutivos
Id_Elemento NUMBER(3) <pk>
FK_FUNCIONA_NACIMIENT_MUNICIPI
Id_TipoElemento NUMBER(2) <fk>
FK_DETALLE__ANTECEDE_DETALLE_ Nombre VARCHAR2(30)
Año_Adquisicion NUMBER(4)
FK_FUNCIONA_PERTENECE_DEPENDEN Valor_Adquisicion NUMBER(10)
Estado_Disponibilidad VARCHAR2(10)
Municipio
Id_Municipio NUMBER(3) <pk>
Nombre_Municipio VARCHAR2(30) FK_ELEMENTO_CORRESPON_TIPO_ELE
Tipo_Elemento
Dependencias Id_TipoElemento NUMBER(2) <pk>
Descripcion VARCHAR2(100)
Id_Dependencias NUMBER(3) <pk>
Nombre_Dependencia VARCHAR2(30)
A continuación se presentará una tabla con la descripción de cada uno de los campos que
N/A: No aplica
Tabla 2
Descripción Tabla Cargo
CARGO
Tipo de Obligatorio u Tipo de
Nombre Descripción Longitud
Dato Opcional Llave
Código
Id_Cargo NUMBER 2 Obligatorio PK
identificador
Nombre del
Nombre_Cargo VARCHAR2 40 Obligatorio N/A
cargo
Fuente: Elaboración Propia
Tabla 3
Descripción Tabla Identificación
IDENTIFICACIÓN
Obligatorio
Tipo de Tipo de
Nombre Descripción Longitud u
Dato Llave
Opcional
Código
Id_Identificacion CHAR 2 Obligatorio PK
identificador
Tipo de
Tipo_Identificacion VARCHAR2 40 Obligatorio N/A
Identificación
Fuente: Elaboración Propia
Tabla 4
Descripción Tabla Municipio
MUNICIPIO
Tipo de Obligatorio u Tipo de
Nombre Descripción Longitud
Dato Opcional Llave
Código
Id_Municipio NUMBER 3 Obligatorio PK
identificador
Nombre del
Nombre_Municipio VARCHAR2 30 Obligatorio N/A
municipio
Fuente: Elaboración Propia
Tabla 5
Descripción Dependencias
DEPENDENCIAS
Obligatorio
Tipo de Tipo de
Nombre Descripción Longitud u
Dato Llave
Opcional
Código
Id_Dependencias NUMBER 3 Obligatorio PK
identificador
Nombre de la
Nombre_Dependencia VARCHAR2 30 Obligatorio N/A
Dependencia
Fuente: Elaboración Propia
Tabla 6
Descripción Tabla Funcionarios
FUNCIONARIOS
Obligatorio Tipo
Tipo de
Nombre Descripción Longitud u de
Dato
Opcional Llave
Id_Funcionarios Código identificador NUMBER 3 Obligatorio PK
Código identificador
Id_Municipio NUMBER 3 Obligatorio FK
del municipio
Código identificador
Id_Dependencias NUMBER 3 Obligatorio FK
de la dependencias
Código identificador
Id_Identificacion del tipo de CHAR 2 Obligatorio FK
identificación
Código identificador
Id_Cargo NUMBER 3 Obligatorio FK
del Cargo
Nombre del VARCHAR
Nombres 30 Obligatorio N/A
Funcionario 2
Apellidos del VARCHAR
Apellidos 30 Obligatorio N/A
Funcionario 2
Número de
Num_Identificaci
identificación del NUMBER 10 Obligatorio N/A
on
funcionario
Género del
Genero CHAR 1 Obligatorio N/A
funcionario
Fuente: Elaboración Propia
Tabla 7
Descripción Tipo Transacción
TIPO_TRANSACCION
Tipo
Tipo de Longitu Obligatorio u
Nombre Descripción de
Dato d Opcional
Llave
Id_TipoTransaccio NUMBE
Código identificador 3 Obligatorio PK
n R
Tipo de transacción
Nombre_Transacci VARCH
(Préstamo, 30 Obligatorio N/A
on AR2
Devolución, etc.)
Fuente: Elaboración Propia
Tabla 8
Tabla Transacciones
TRANSACCIONES
Tipo
Tipo de Obligatorio u
Nombre Descripción Longitud de
Dato Opcional
Llave
Código
Id_Transaccion NUMBER 10 Obligatorio PK
identificador
Código
Id_Funcionarios Identificador del NUMBER 3 Obligatorio FK
funcionario
Código
Id_TipoTransaccion identificador del NUMBER 3 Obligatorio FK
tipo de transacción
Fecha en que se
Fecha realiza la DATE N/A Obligatorio N/A
transacción
Fuente: Elaboración Propia
Tabla 9
Descripción Tipo Elemento
TIPO_ELEMENTO
Obligatorio Tipo
Tipo de
Nombre Descripción Longitud u de
Dato
Opcional Llave
Id_TipoElemento Código identificador NUMBER 2 Obligatorio PK
Descripción del tipo
Descripción de elemento VARCHAR2 100 Obligatorio N/A
devolutivo
Fuente: Elaboración Propia
Tabla 10
Descripción Elementos Devolutivos
ELEMENTOS_DEVOLUTIVOS
Obligatorio
Tipo de Tipo de
Nombre Descripción Longitud u
Dato Llave
Opcional
Id_Elemento Código identificador NUMBER 3 Obligatorio PK
Código identificador
Id_TipoElemento del tipo de elemento NUMBER 2 Obligatorio FK
devolutivo
Nombre del elemento VARCHAR
Nombre 30 Obligatorio N/A
devolutivo 2
Año en el que se
Año_Adquisicion NUMBER 4 Obligatorio N/A
adquirió el elemento
Costo del elemento al
Valor_Adquisicio
momento de su NUMBER 10 Obligatorio N/A
n
adquisición
Estado del elemento
Estado_Disponibili VARCHAR
(Disponible, No 10 Obligatorio N/A
dad 2
Disponible)
Fuente: Elaboración Propia
Tabla 11
Descripción Detalle Transacción
DETALLE_TRANSACCION
Obligatorio Tipo
Tipo de Longitu
Nombre Descripción u de
Dato d
Opcional Llave
Código identificador de la NUMBE PK -
Id_Transaccion 10 Obligatorio
transacción R FK
NUMBE
Id_Detalle Código identificador 10 Obligatorio PK
R
Código identificador de la
Det_ID_Transacc transacción con la que se NUMBE
10 Opcional FK
ion realiza la devolución del R
elemento
Código identificador del
NUMBE
Det_Id_Detalle detalle en el que se realiza 10 Opcional FK
R
la devolución del elemento
Código identificador del NUMBE
Id_Elemento 3 Obligatorio FK
elemento devolutivo R
NUMBE
Cant Cantidad de elementos 1 Obligatorio N/A
R
Fuente: Elaboración Propia
Consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea
refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y
El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces.
(ittgweb, 2016)
componente del mismo y definir los parámetros de entrada y salida de cada uno de los módulos.
La jerarquía entre los módulos se emplea de forma que los módulos de niveles superiores
coordinen a los de niveles inferiores. Al dividir los módulos jerárquicamente, es posible controlar
el número de módulos que interactúan con cualquiera de los otros. (Cillero, s.f.)
Ilustración 3
Diagrama de Módulo Eliminación
Teniendo en cuenta que un módulo es la división del software clara y manejable con
o rutina dependiendo del lenguaje a utilizar, y que además admite parámetros de llamada y
Tabla 12 Descripción
Diagrama Modular de Eliminación
ARQUITECTURA DE ELIMINACIÓN A LA TABLA FUNCIONARIOS
NOMBRE FUNCIÓN
Representa la parte pública, visible y accesible desde
Capa de Presentación afuera del mismo paquete, es la interfaz de interacción
entre el usuario y el sistema.
Este módulo realiza las validaciones controles y
Controlador, validador, y
verificación necesarios para concretar la eliminación del
verificador de la eliminación
registro correctamente.
Realiza la eliminación del registro seleccionado por el
Eliminar Funcionario
usuario.
Verifica que el registro seleccionado por el usuario exista y
Validar eliminación
se elimine correctamente.
Muestra en la consola los registros que existen en la tabla
Desplegar tabla funcionarios
una vez hecha la eliminación.
Fuente: Elaboración Propia
Tabla 13 Descripción
Diagrama Modular Inserción y Actualización
ARQUITECTURA DE INSERCIÓN Y ACTUALIZACIÓN
TABLA DETALLE_TRANSACCION
NOMBRE FUNCIÓN
Representa la parte pública, visible y accesible desde
Capa de Presentación afuera del mismo paquete, es la interfaz de interacción
entre el usuario y el sistema.
Controlador, validador, y Este módulo realiza las validaciones controles y
verificador de la inserción y verificación necesarios para concretar la inserción y
actualización actualización del registro.
Comprueba que el elemento devolutivo seleccionado
Verificar elemento devolutivo
exista.
Verificar transacción Comprueba que la transacción seleccionada exista.
Realiza la inserción del detalle de la transacción
Insertar detalle de transacción
seleccionada.
Si el elemento y el detalle seleccionados corresponden a un
Actualizar detalle transacción detalle anterior toma la inserción como una devolución por
tanto actualiza el registro de préstamo.
Despliega un mensaje para comprobar si se realizó o no
Desplegar Mensaje
correctamente el proceso.
Fuente: Elaboración Propia
Tabla 14 Descripción
Diagrama Modular Consulta
diseño para efectuar la implementación de la base de datos, se inicia con la generación del Script
el cual se obtuvo a partir del diagrama relacional físico y por medio de la herramienta Power
Designer.
Una vez conseguido el script se procede a crear la base de datos, para esto se empleó la
la población y se obtuvo un nuevo Script el cual contiene la base de datos pero con la inserción
creación de las consultas CRUD (Create, Read, Update & Delete) en base a estos modelos. La
descripción precisa de cada uno de los productos obtenidos a partir de esta fase se puede
evidenciar en la sección de anexos en la cual se exponen con más detalle a fin de obtener la
5.1.PRUEBAS
A continuación se muestran una serie de capturas correspondientes a las pruebas realizadas a los
Inserción
En las imágenes se muestra el resultado del proceso de inserción a la tabla funcionarios, para
ello se realizó la captura de datos por consola una vez ingresados el programa ejecuta una serie
de validaciones las cuales al ser superadas permiten la inserción del nuevo registro. Una vez
registrado nos muestra en la consola una pequeña tabla con los datos del funcionario ingresado.
Ilustración 6
Pruebas de Inserción de un Registro
Actualización
tabla funcionarios, para ello se realizó la captura de datos a actualizar por consola una vez
ingresados el programa ejecuta una serie de validaciones las cuales al ser superadas permiten la
actualización del registro. Una vez actualizado genera un mensaje que constata la actualización
del registro.
Ilustración 7
Actualización de un Registro
Eliminación
funcionarios, para ello se realizó la captura del código del funcionario a eliminar por medio de la
consola una vez ingresado el programa ejecuta una serie de validaciones las cuales al ser
superadas permiten la eliminación del registro. Una vez eliminado el registro el programa genera
Ilustración 8
Eliminación de un Registro
Consultas
A un registro
Ilustración 9
Consulta a Un Registro
A varios registros
Ilustración 10
Consulta a Varios Registros
un aplicativo con soporte a los procesos del subsistema de información para el control de
elementos_devolutivos.
funcionarios, y elementos_devolutivos.
log), los cuales involucran la creación de una tabla para controlar el historial de
Colombia.
Colombia.
https://www.tecnologias-informacion.com/modelos-datos.html
https://tareasuniversitarias.com/modelo-fisico-de-datos-modelo-relacional.html
wordpress.com/2016/05/29/descomposicion-modular/
3/tecnicas/diagrama-de-estructura/
8. ANEXOS
La imagen a continuación muestra una parte del script generado a partir del modelo físico
relacional en el cual se realiza la creación de las tablas con sus respectivas relaciones, para ver el
Script.sql:
Ilustración 11
Script SQL de la BD
Procedimientos
base de datos para ver los procesos completos de Creación, Actualización y Eliminación,
diríjase a la carpeta de construcción y posteriormente abra la carpeta Inserción, Actualización y
Ilustración 12
Creación Edición y Eliminación de un Registro
Consultas
transacciones de la base de datos para ver los procesos completos que generan la consulta,
Ilustración 13
Consulta a Un Registro Tabla Transacciones
de la base de datos para ver los procesos completos que generan la consulta, diríjase a la carpeta
de construcción y posteriormente abra la carpeta Consultas, allí se encuentran todos los procesos
debidamente organizados:
Ilustración 14
Consulta a Varios Registros de la Tabla Transacciones
Consultas Sumarias
elementos devolutivos y tipo de elemento de las cuales se extrajo el nombre del tipo de elemento
y se sumó la cantidad de elementos devolutivos que pertenecen a este, al igual que su valor de
adquisición y al final muestra una columna extra con el valor del IVA para ver los procesos
completos que generan la consulta, diríjase a la carpeta de construcción y posteriormente abra la
Ilustración 15
Consulta Sumaria
Transacciones
La imagen a continuación muestra el llamado a los procesos para ejecutar una transacción a
lo contrario simplemente inserta el nuevo registro; para ver los procesos completos que generan
la transacción, diríjase a la carpeta de construcción y posteriormente abra la carpeta
Ilustración 16
Procedimiento de Transacción
Auditoría
log_detalle_transaccion con el fin de registrar todos las acciones que se realicen a la tabla
la fecha exacta y el usuario que realiza la alteración; para ver los procesos completos que
generan la transacción, diríjase a la carpeta de construcción y posteriormente abra la carpeta
Ilustración 17
Procedimiento de Auditoría