Bases II - Proyectos 2020-06-15

La infraestructura tecnológica que soportan los
DBMS, la optimización de los QUERY y los

conceptos de arquitecturas de bases de datos,
permiten responder de mejor manera los
requerimientos de información con la
inmediatez y seguridad del caso. Estos
conocimientos son los cimientos para ir de
DATA a DW DM BI y a BIG DATA con DATA
ANALITICA.
JW Cóndor
BASES DE 2020 junio 15
DATOS II
PROYECTOS
BASES DE DATOS II
Contenido:
Contenido
Contenido: ........................................................................................................................ 1
OBJETIVOS DE PROYECTOS DE BASES DE DATOS II: ......................................... 3
TIPOS DE EVIDENCIAS:............................................................................................... 3
1. EVIDENCIA TIPO INFORME: ........................................................................... 3
2. EVIDENCIA TIPO PRESENTACION: ............................................................... 3
3. EVIDENCIA TIPO VIDEO CLIP: ....................................................................... 3
4. EVIDENCIA TIPO SCRIPT SQL OPTIMIZACION DE <QUERYS>:.............. 4
5. EVIDENCIA TIPO IMPLEMENTACION: ......................................................... 5
CONDICIONES DE ENTREGA DE EVIDENCIAS:..................................................... 5
CONTEXTOS E INSTANCIAS: ..................................................................................... 6
MODELO BANCA PDM ............................................................................................ 6
INSTANCIAS A, B, C y D DE BANCA: .................................................................... 8
I.- INFRAESTRUCTURA y OPTIMIZACION DE <QUERYs> ................................... 9
P 1.1 RAID, STORAGE & SSD ................................................................................ 10
P 1.2 INDEX & VIEW. .............................................................................................. 11
P 1.3 <QUERY> EJECUCION .................................................................................. 13
P 1.4 <QUERY> OPTIMIZACION ........................................................................... 15
II.- TRANSACCIONES y CONCURRENCIA ............................................................. 17
P 2.1 TRANSACCION AISLADA ............................................................................ 18
P 2.2 TRANSACCION CONCURRENTE ................................................................ 20
EJ. COMPRAS – TRANSACCION O/C ............................................................... 22
TRANSACCIONES - Criterios de evaluación:...................................................... 24
P 2.3 ROLES, USUARIOS y AUTORIZACIONES ................................................. 25
ROLES y AUTORIZACIONES EN EL CONTEXTO BANCA ........................... 26
EJ.: ROLES EN CONTEXTO UNIVERSITARIO ................................................ 26
EJ. ROLES EN MODULO COMPRAS ................................................................ 27
P 2.4: PRUEBAS DE ESTRÉS .................................................................................. 29
III.- CONTINGENCIA: BDD Paralelas, Distribuidas y DBaaS. ................................... 31
P 3.1: PLANES DE CONTINGENCIA ..................................................................... 32
P 3.2 BDD PARALELAS .......................................................................................... 33
P 3.3 BDD DISTRIBUIDAS ...................................................................................... 35
P 3.4 BDD aaS ............................................................................................................ 37
IV.- SSD, DW, DM y BIG DATA ................................................................................. 38
P 4.1 DSS Decision Support System -BI- .................................................................. 39
JW CONDOR | Contenido: 1
BASES DE DATOS II
P 4.2 DW DATA WAREHOUSE .............................................................................. 40

P 4.3 DM DATA MINING ........................................................................................ 41
P 4.4 BIG DATA ........................................................................................................ 42
2 Optimización | JW CONDOR
BASES DE DATOS II
OBJETIVOS DE PROYECTOS DE BASES DE DATOS II:

1. Motivar la investigación, fomentando el uso de Internet y el trabajo en equipo.
2. Conocer las especificaciones para infraestructura de hardware y software base para los DBMS.
3. Optimizar el tiempo de respuesta de QUERYs en sentencias DML de SQL.
4. Profundizar el conocimiento de los DBMS:
a. SQL (MaríaDB → PostgreSQL → SQLServer → Oracle → DB2)
b. No-SQL (Hadoop, Mongo) y
c. DBaaS (Azzure, Cloud DB).
5. Verificar los límites de los DBMS, simulando un ambiente de 10 años o más de existencia
organizativa en:
a. Número de registros,
b. Número de usuarios concurrentes,
c. Número de transacciones concurrentes.
6. Conocer los conceptos de:
a. Business Intelligence
b. Data Warehouse,
c. Data Mining, y
d. Big Data.
TIPOS DE EVIDENCIAS:
Una evidencia es un archivo digital tipificado como:
1. Informe,
2. Presentación,
3. Videoclip,
4. Script SQL,
5. Implementación.
1. EVIDENCIA TIPO INFORME:

(Objetivo: Formato guía de evidencia tipo informe)
1. Documento en procesador de palabras
2. Tipo de letra Arial, 10 cpi. Margen normal de páginas.
3. Encabezado con el título del documento.
4. Pie de página con autor(es), numeración y fecha de exposición.
5. Estructura de informe:
a. Carátula: Tema, autor(es), Fecha de exposición.
b. Resumen
c. Desarrollo del tema.
d. Conclusiones y recomendaciones
e. Referencias y Bibliografía.
2. EVIDENCIA TIPO PRESENTACION:

(Objetivo: Formato guía de evidencia tipo presentación)
1. Documento en presentador de diapositivas
2. Tamaño de letras visibles para el asistente de la última fila.
3. Cada dispositiva con título conciso.
4. Pie de diapositiva con autor(es), numeración y fecha de exposición
5. Estructura de diapositivas:
a. Caratula: Tema, autor(es), Fecha de exposición.
b. Desarrollo del Tema.
c. Conclusiones y Recomendaciones
d. Agradecimiento, preguntas y respuestas.
e. Referencias y Bibliografía.
3. EVIDENCIA TIPO VIDEO CLIP:

(Objetivo: Formato guía de evidencia tipo Video Clip)
1. Formato video compatible, subido en OneDrive y LINK en la plataforma.
2. Duración del video hasta cuatro (4) minutos.
3. Guion del video:
JW CONDOR | OBJETIVOS DE PROYECTOS DE BASES DE DATOS II: 3

BASES DE DATOS II
Secuencia: Escena: Duración

[mm:ss]
1. Presentación del autor(es) 0:10
2. Resumen de la temática 0:30
3. Escena introductoria 1:00
4. Escena explicativa 2:00
5. Cierre de video clip 0:10
6. Referencias y Bibliografía 0:10
4. EVIDENCIA TIPO SCRIPT SQL OPTIMIZACION DE <QUERYS>:

(Objetivo: Registrar ejemplos, ejercicios y optimizaciones)
1. Encabezado con el título del documento.
2. Pie de página numerada en la parte inferior derecha.
3. Cada <QUERY> debe estructurarse de la siguiente manera:
a. El enunciado de la consulta (numeración consecutiva, entre símbolos << --- >>)
b. La sentencia(s) SQL aplicada(s); y,
c. El resultado de ejecución (Datos o mensajes)
d. Tiempos de respuesta para un mil, diez mil y cien mil registros.
e. Explicación de la ejecución del proceso
f. Optimización alternativa variante en SQL.
g. Optimización alternativa considerando INDICES.
h. Optimización alternativa considerando VISTAS.
4. Ejemplo CONSULTA:
ENUNCIADO << Determinar los clientes que viven en Quito>>
SQL:: SELECT *
FROM CLIENTES
WHERE cliciudad = ‘Quito’;
RESULTADO:
345 row afected
Número de Registros Mil registros Diez mil registros Cien mil registros
Tiempo en segundos 0.2458 1.2543 5.4578
SQL O1:: SELECT *

FROM CLIENTES
WHERE cliciudad LIKE ‘Quito%’;
BASES DE DATOS II

SQL O2:: CREATE INDEX IDX_01 ON CLIENTES (cliciudad);
SQL O3:: CREATE VIEW AS V1
(SELECT *
FROM CLIENTES
WHERE cliciudad = ‘Quito’;)
SQL 03> select * from v1;
5. EVIDENCIA TIPO IMPLEMENTACION:

(Objetivo: Implementar el concepto)
1. Como infraestructura se puede utilizar maquinas físicas, máquinas virtuales, servidores locales,
servidores en la nube. Especificándose sus características y ubicación.
2. Los DBMS deben ser seleccionados e indicados en cada máquina.
3. Si se utiliza un modelo ER debe indicarse las tablas principales sus relaciones y por lo menos
una carga de 1000 registros por tabla
4. La ejecución del concepto, debe ser aclarado para los asistentes.
5. Simularse condiciones similares al contexto geográfico, organizacional, transaccional.
6. Cualquier miembro del equipo se seleccionará para las modificaciones solicitadas.
CONDICIONES DE ENTREGA DE EVIDENCIAS:

Las condiciones para presentar y entregar una evidencia son:
1. La evidencia es individual,
2. La evidencia o LINK, se debe subir a la plataforma EVA en la sección correspondiente,
3. La fecha y hora de la recepción está indicadas,
4. Cada día de retraso se penaliza con el 10%,
5. Cada falta ortográfica se penaliza con el 1%.
La distribución semanal de los DBMS, se indica a continuación:
DBMS X SEMANAS
GRUPO S01 S02 S03 S04 S05 S06 S07 S08 S09 S10 S11 S12 S13 S14 S15 S16 S17 S18
GRUPO #1 MariaDB MySQL PostgreSQL SQLServer Oracle DB2
GRUPO #2 MySQL PostgreSQL SQLServer Oracle DB2 MariaDB
GRUPO #3 PostgreSQL SQLServer Oracle DB2 MariaDB MySQL
GRUPO #4 SQLServer Oracle DB2 MariaDB MySQL PostgreSQL
GRUPO #5 Oracle DB2 MariaDB MySQL PostgreSQL SQLServer
GRUPO #6 DB2 MariaDB MySQL PostgreSQL SQLServer Oracle
JW CONDOR | CONDICIONES DE ENTREGA DE EVIDENCIAS: 5

BASES DE DATOS II
CONTEXTOS E INSTANCIAS:
MODELO BANCA PDM
SUCURSALES
sucNombre sucCiudad sucCalle sucActivo sucGerente sucTelefono sucFechaCreacion
Alameda Quito Av. 12 de Octubre 400.00 CCJW 22224466 2000-01-01
Centro Babahoyo Conquistadores y 609000.00 ABCD 52224466 1998-01-01
Condado Quito Upano y Radison 1700.00 REBA 22224466 2010-01-01
Galápagos Babahoyo Conquistadores y 407100.00 ARGR 52224466 2029-01-01
Malacato Cuenca De las flores SN 0.00 ETDE 72224466 2005-01-01
Mariscal Cuenca Via a Guayaquil 2100.00 PPTR 22224466 2004-01-01
Metropoli Quito 6 Diciembre y Colon 8000.00 ZPFE 22224466 2005-01-01
Peninsula Orellana Conquistadores 427300.00 RTSA 92224466 1995-01-01
Rio Guayaquil Malecon 2000 3700.00 WZZR 62224466 1930-01-01
BASES DE DATOS II
CLIENTES
cliFecha
cliNombre cliCalle cliCiudad cliSexo Nacimiento cliTipo
Alomoto Av 12 Octubre Babahoyo M 1987-01-01 NAT
Alvarez Conquistadores Cuenca M 1999-01-01 NAT
Baldeón Toledo Cuenca M 1999-01-01 JUR
Cañizares Francisco Arévalo Quito DM M 2001-01-01 JUR
Enriquez Valladolid N23 UIO M 1945-01-01 NAT
Fernández Madrid Latacunga F 2008-01-01 NAT
González Av 10 Agosto Quito M 2004-01-01 NAT
López Manabí Portoviejo M 1972-01-01 NAT
Pérez Carretas Guayaquil F 1998-01-01 NAT
Ramos Eloy Alfaro Latacunga M 1955-01-01 NAT
Rodríguez Yasuní Quevedo M 2012-01-01 JUR
Santamaria Manabí Portoviejo F 2000-01-01 NAT
Torres Carretas Guayaquil F 2020-01-01 JUR
Valdivieso Simón Bolívar Zaruma M 1965-01-01 NAT
Zapata Malecon esquina Azogues F 2010-01-01 JUR
CUENTAS
CueNumero sucNombre cueSaldo cueTipo cueFecha
C-009 Alameda 347 C 2002-01-01
C-101 Centro 500 A 1945-01-01
C-102 Condado 400 A 1965-01-01
C-201 Galápagos 900 C 1999-01-01
C-215 Alameda 700 A 2010-01-01
C-217 Galápagos 750 A 1999-01-01
C-222 Mariscal 700 C 2015-01-01
C-305 Metropoli 350 C 2012-01-01
C-509 Rio 3 M 2019-01-01
PRESTAMOS
preNumero sucNombre preImporte preFecha
P-11 Metropoli 900.00 2010-01-01
P-14 Centro 1500.00 1980-03-01
P-15 Condado 1500.00 2014-05-01
P-16 Condado 1300.00 2016-07-01
P-17 Centro 1000.00 1990-09-01
P-23 Mariscal 2000.00 2012-11-01
P-93 Alameda 500.00 2020-12-01
JW CONDOR | CONTEXTOS E INSTANCIAS: 7

BASES DE DATOS II
TIENE
cueNumero cliNombre
DEBE
C-009 Torres
preNumero cliNombre
C-101 Zapata
P-11 Enriquez
C-102 Enriquez
P-14 Valdivieso
C-102 Zapata
P-15 Pérez C-201 Enriquez
P-16 Pérez C-201 Zapata
P-17 Enriquez C-215 Torres
P-17 Valdivieso C-217 Enriquez
P-23 Enriquez C-222 Enriquez
P-23 Pérez C-305 Torres
P-93 Torres C-305 Zapata
P-93 Valdivieso C-509 Ramos
INSTANCIAS A, B, C y D DE BANCA:
TABLA: A #Reg B #Reg C #Reg D #Reg

SUCURSALES 9 100 1.000 10.000
CLIENTES 15 1.000 10.000 100.000
CUENTAS 9 1.000 10.000 100.000
PRESTAMOS 7 1.000 10.000 100.000
TIENE 12 10.000 100.000 1’000.000
DEBE 10 10.000 100.000 1’000.000
BASES DE DATOS II
PRIMER APORTE
INFRAESTRUCTURA TECNOLOGICA PARA DBMS
QUERYS EJECUCION EQUIVALENCIAS Y OPTIMIZACION
I.- INFRAESTRUCTURA y OPTIMIZACION DE <QUERYs>
JW CONDOR | I.- INFRAESTRUCTURA y OPTIMIZACION DE 9

<QUERYs>
BASES DE DATOS II
P 1.1 RAID, STORAGE & SSD
INFRAESTRUCTURA TECNOLOGICA PARA SERVICIO DE BASES DE DATOS

Referencia:
https://es.wikipedia.org/wiki/RAID
CONSIDERACIONES:
a. Consultar sobre RAID:
1. Antecedentes
2. Estado del arte en RAID
3. Ventajas
4. Desventajas
b. Seleccionar e implementar RAID para el DBMS designado.
DEFENSA DE PROYECTO:
1. Tipo de RAID seleccionado e implementado.
2. Quitar un disco y verificar el funcionamiento.
3. ¿Funciona el DBMS sobre el RAID?
4. Recomendación sobre RAID.
5. Gestión de almacenamiento de estado solido
RUBRICA:
No. PLANTEAMIENTO REHACER REGULAR BUENO SATISFACTORIO

(0 puntos) (1 punto) (3 puntos) (5 puntos)
1 Presentar RAID No Presenta un Presenta Completo cubre
implementado con varios presenta. ejemplo. ejemplo con los numerales
discos. tiempos. anteriores.
2 Presentar un archivo No Presenta Presenta Concluye cubre los
TXT con caída de disco presenta. archivo. archivo con numerales
RAID. tiempos. anteriores.
3 Presentar su DBMS No Presenta un Presenta Completo cubre
funcionando con caída presenta. ejemplo. ejemplo con los numerales
de disco de RAID tiempos. anteriores.
4 Presentar BDD BANCA No Presenta un Presenta Completo cubre
funcionando con caída presenta. ejemplo. ejemplo con los numerales
de disco de RAID. tiempos. anteriores.
5 Gestión de No Aumenta Implementa Gestiona HD y
almacenamiento de presenta almacenamiento RAID con SSD de manera
estado solido de estado solido estado solido transparente.
BASES DE DATOS II
P 1.2 INDEX & VIEW.
La indexación permite tener organizada la información de manera lógica mediante

arreglos de punteros, para optimizar la búsqueda y recuperación de registros.
Referencia:
https://en.wikipedia.org/wiki/Database_index
CONSIDERACIONES Y SUGERENCIAS:
o Utilizar el DBMS asignado.

o Utilizar el MODELO ASIGNADO, similar al modelo BANCA.
o INSTANCIAS:
TABLA A #Reg B #Reg C #Reg D #Reg
SUCURSALES 1.000 10.000 100.000 1’000.000
CLIENTES 1.000 10.000 100.000 1’000.000
CUENTAS 1.000 10.000 100.000 1’000.000
PRESTAMOS 1.000 10.000 100.000 1’000.000
TIENE 1.000 10.000 100.000 1’000.000
DEBE 1.000 10.000 100.000 1’000.000
o Probar su DBMS en la nube.
o Se sugiere utilizar Store Procedure (SP) o funciones (f(x)) para la generación de registros.
CONSULTAR PARA SU DBMS:
1. Ventajas y Desventajas de INDEX HASH.

2. Sintaxis de Create, Drop o Alter de INDEX HASH para su DBMS.
3. Comando EXPLAIN o explicación gráfica de ejecución.
4. ¿Su DBMS indexa campos tipo: XML, BLOB, GPS? ¿Como lo hace?
5. Para que sirve los parámetros [ONLINE] [OFFLINE]
6. ¿Qué estructura utiliza su DBMS? ¿B, B+?
IMPLEMENTAR:
a. Implementar INDEX HASH sobre un campo de una tabla.

b. Implementar INDEX HASH sobre dos campos de una tabla.
c. Implementar INDEX HASH sobre tres campos de una tabla.
d. Probar las opciones DENSO, CLUSTER, ONLINE.
e. Tomar los tiempos de respuesta de las operaciones Insert, Delete, Update, Select sin y con
INDEX HASH para:
1. QUERY01 – Presentar la información de los clientes ORDE BY sexo, ciudad, dirección
domiciliaria.

<QUERYs>
BASES DE DATOS II
2. QUERY02 – Realizar el producto cartesiano entre las tablas SUCURSALES,

PRESTAMOS Y CUENTAS.
3. QUERY03 – Generar una VIEW para determinar los clientes que tiene cuentas
bancarias, pero no tienen préstamos.
DEFENSA RUBRICA:

1 Presentar y Explicar la No Presenta la Presenta Presenta Sintaxis con
SINTAXIS de su DBMS presenta. sentencia Sintaxis sin explicación de las
para INDEX | HASH SQL. explicación. opciones.
2 Crear un INDEX | HASH No Presenta Presenta Presenta INDEX HASH
sobre tres (3) campos de presenta. INDEX INDEX HASH sobre 3 campos asc desc
una tabla. Ej. CLIENTES HASH. sobre 3 campos asc. Utilizando las
asc desc asc. asc desc asc. opciones.
3 Crear un INDEX | HASH No Presenta Presenta Presenta INDEX HASH
para una juntura de tres (3) presenta. INDEX INDEX HASH sobre las 3 tablas.
tablas. Ej. CUENTAS, HASH. sobre las 3 Utilizando las opciones.
SUCURSALES, tablas.
PRESTAMOS.
4 Ver el listado de índices. No Presenta el Presenta el Presenta el objeto y el
Ver el contenido de un presenta. objeto objeto y el contenido INDEX
INDEX | HASH. INDEX contenido HASH. En modo gráfico
HASH. INDEX HASH. y por comando SQL.
5 Tiempos de respuesta DML No Presenta Presenta Presenta tiempos
para QUERY01 sin y con presenta. tiempos para tiempos para optimizados para
INDEX | HASH. comando comandos comandos DML.
SELECT. DML.
INDEX | HASH. comando comandos comandos DML.
SELECT. DML.
INDEX | HASH sobre la comando comandos comandos DML.
vista. SELECT. DML.
Ej. RUBRICA 1 PostgreSQL (BUENO):
BASES DE DATOS II
P 1.3 <QUERY> EJECUCION

Cada DBMS tiene una o más sentencias que son equivalentes para ejecutar <Query>
SQL; dependiendo de su orientación funcional y de la DATA a procesar.
Referencia:
https://en.wikipedia.org/wiki/Query_plan

o INSTANCIAS:
SUCURSALES 1.000 10.000 100.000 1’000.000
CLIENTES 1.000 10.000 100.000 1’000.000
CUENTAS 1.000 10.000 100.000 1’000.000
PRESTAMOS 1.000 10.000 100.000 1’000.000
TIENE 1.000 10.000 100.000 1’000.000
DEBE 1.000 10.000 100.000 1’000.000
CONSULTAR:
1. Estado del arte sobre PALABRAS RESERVADAS SQL EQUIVALENTES.

2. ¿Como el DBMS permite ver el costo de ejecución? Comando EXPLAIN, interface GUI.
3. ¿La última versión de DBMS que equivalencias ha incorporado?
4. Ventajas y Desventajas.
IMPLEMENTAR:
1. Implementar las consultas con número de registros iniciales.

2. Implementar las consultas con el número de registros propuesto en consideraciones.
3. Implementar las consultas con el número de registros en consideraciones multiplicado por diez
(10).
4. Implementar las consultas con el número de registros en consideraciones multiplicado por cien
(100).
5. Implementar las consultas con el número de registros en consideraciones multiplicado por mil
(1.000).
RUBRICA:

1 Comparar x>=y and x<=z No Presenta un Presenta Concluye que
vs. BETWEEN. presenta. ejemplo. ejemplo con alternativa es
tiempos. mejor. Explica
técnicamente lo
sucedido.
2 Analizar <Condición> No Presenta un Presenta Concluye que
AND TAUTOLOGIA. presenta. ejemplo. ejemplo con alternativa es
técnicamente lo
sucedido.
3 Analizar <Condición> OR No Presenta un Presenta Concluye que
TAUTOLOGIA. presenta. ejemplo. ejemplo con alternativa es

<QUERYs>
BASES DE DATOS II
técnicamente lo
sucedido.
4 Analizar <Condición> and No Presenta un Presenta Concluye que
FALASIA. presenta. ejemplo. ejemplo con alternativa es
técnicamente lo
sucedido.
5 Analizar <Condición> OR No Presenta un Presenta Concluye que
FALASIA. presenta. ejemplo. ejemplo con alternativa es
técnicamente lo
sucedido.
6 Sean T1, T2 tablas. No Presenta un Presenta Concluye que
Comparar T1 x T2 vs. T1 presenta. ejemplo. ejemplo con alternativa es
JOIN T2. tiempos. mejor. Explica
técnicamente lo
sucedido.
7 Sean T1, T2, T3 tablas. No Presenta un Presenta Concluye que
Comparar T1 x T2 x T3 vs. presenta. ejemplo. ejemplo con alternativa es
T1 JOIN T2 JOIN T3. tiempos. mejor. Explica
técnicamente lo
sucedido.
8 Comparar sentencias IN, No Presenta un Presenta Concluye que
EXIST, UNIQUE. presenta. ejemplo. ejemplo con alternativa es
tiempos. mejor.
9 Comparar ORDER BY sin No Presenta un Presenta Concluye que
y con INDEX presenta. ejemplo. ejemplo con alternativa es
técnicamente lo
sucedido.
10 Consultar DBMS usa No Presenta un Presenta Concluye que
buffer en DISCO, presenta. ejemplo. ejemplo con alternativa es
MEMORIA tiempos. mejor.
11 Comparar GROUP BY vs. No Presenta un Presenta Concluye que
VIEW presenta. ejemplo. ejemplo con alternativa es
técnicamente lo
sucedido.
BASES DE DATOS II
P 1.4 <QUERY> OPTIMIZACION
Cada DBMS tiene una o más estrategias para ejecutar determinados comandos SQL,
dependiendo de su orientación funcional.
Referencia: https://en.wikipedia.org/wiki/Query_optimization

o INSTANCIAS:
SUCURSALES 1.000 10.000 100.000 1’000.000
CLIENTES 1.000 10.000 100.000 1’000.000
CUENTAS 1.000 10.000 100.000 1’000.000
PRESTAMOS 1.000 10.000 100.000 1’000.000
TIENE 1.000 10.000 100.000 1’000.000
DEBE 1.000 10.000 100.000 1’000.000
o Realizar las consultas propuestas en el material SQL básico, medio y avanzado
CONSULTAR:
1. Estado del arte sobre COSTO DE EJECUCION.

2. ¿Como el DBMS permite ver el costo de ejecución? Comando EXPLAIN, interface GUI.
3. ¿La última versión de DBMS que estrategias ha incorporado?
4. Ventajas y Desventajas
IMPLEMENTAR:
Realizar las consultas propuestas en el material SQL básico, medio y avanzado.

1. Implementar las consultas con número de registros iniciales.
2. Implementar las consultas con el número de registros propuesto en consideraciones.
3. Implementar las consultas con el número de registros en consideraciones multiplicado por diez
(10).
4. Implementar las consultas con el número de registros en consideraciones multiplicado por cien
(100).
5. Implementar las consultas con el número de registros en consideraciones multiplicado por mil
(1.000).

<QUERYs>
BASES DE DATOS II
RUBRICA:

1 Ejecutar una sentencia SQL No Presenta un Presenta Concluye que
INSERT de 1000 registros presenta. ejemplo. ejemplo alternativa es
involucradas. Verificar sus con mejor. Explica
tiempos de respuesta con y sin tiempos. técnicamente lo
uso de INDEX o HASH de 2
campos.
sucedido.
DELETE de 1000 registros presenta. ejemplo. ejemplo alternativa es
campos.
sucedido.
UPDATE de 1000 registros presenta. ejemplo. ejemplo alternativa es
campos.
sucedido.
SELECT de 1000 registros presenta. ejemplo. ejemplo alternativa es
campos.
sucedido.
JOIN de 3 tablas involucradas. presenta. ejemplo. ejemplo alternativa es
Verificar sus tiempos de con mejor. Explica
respuesta con y sin uso de tiempos. técnicamente lo
INDEX o HASH de 2 campos y
de una VIEW equivalente.
sucedido.
SORT de 1000 registros presenta. ejemplo. ejemplo alternativa es
campos y con una VIEW
sucedido.
equivalente
BASES DE DATOS II
II Transacciones y
Concurrencia
II.- TRANSACCIONES y CONCURRENCIA
Consideraciones:
1. Cada grupo se especializa en el módulo designado; en caso del modelo BANCA todo el modelo.
2. Las tablas deben ser llenadas con 10.000 registros coherentes para simular un contexto real; en
caso del modelo BANCA referirse a la instancia C.
3. Si necesita hacer suposiciones, haga suposiciones RAZONABLES y documéntelas.
4. Utilice las herramientas:
a. Power Designer para modelo CDM
b. DBMS seleccionado
c. Lenguaje de programación adecuado
d. Framework o IDE en caso de ser necesario
No. MODULO GRUPO TRANSACCION

1 Compras G1 Orden de Compra
2 Ventas G2 Orden de Venta
3 Importaciones G3 Orden de Importación
4 Exportaciones G4 Orden de Exportación
5 Contabilidad G5 Asiento Contable
6 Producción G6 Orden de Producción
JW CONDOR | II.- TRANSACCIONES y CONCURRENCIA 17

BASES DE DATOS II
P 2.1 TRANSACCION AISLADA
A. PRESENTAR LA EJECUCIÓN DE UNA TRANSACCION, para BANCA una

transferencia de una cuenta bancaria a dos cuentas bancarias, así:
a. Transacción con finalización COMMIT.
b. Transacción con ejecución ROLLBACK.
c. Transacción con ejecución SAVE POINT.
B. GENERAR UN SCRIPT, FUNCION o STORE PROCEDURE PARA GENERAR:
a. 10 Transacciones.
b. 100 Transacciones.
c. 1.000 transacciones (el número de transacciones es un parámetro)
Referencias:
https://es.wikipedia.org/wiki/Transacci%C3%B3n_(inform%C3%A1tica)
1. Identifique las posibles transacciones de su contexto.

2. Identifique en un contexto real el número de transacciones anuales, mensuales, semanales, diarias
o por horas.
3. Determine el tiempo de ejecución de una transacción.
4. Generar pruebas de tiempo de acuerdo al número de transacciones (10, 100, 1.000 y 10.000).
5. Conclusiones
6. Recomendaciones.
TALLER UTILIZANDO EL MODELO BANCA:
En el modelo BANCA la transacción típica es la transferencia de una cuenta bancaria a

otra(s); como, por ejemplo:
ORDEN DE TRANSFERENCIA
cliente: CCJW No. 4578
ID: 17085548450 Fecha: 2018-05-21
Linea DESCRIPCION SALDO inicial Monto SALDO final

1 Cuenta C-101 $ 100,00 $ 100,00 $ -
2 Cuenta C-102 $ 75,00 $ 50,00 $ 125,00
3 Cuenta C-103 $ 50,00 $ 25,00 $ 75,00
4 Cuenta C-104 $ 25,00 $ 25,00 $ 50,00
1. EJECUTAR LA SIGUIENTE TRANSFERENCIA BANCARIA:
TRANSFERENCIAS
traCodigo traDescripcion traFecha trahora traMonto traUsuario
1 De 101 a 102 01/01/1945 10:00:00 100.00 jwcondor
2 De 201 a 222 01/01/2010 12:00:00 200.00 postgres
3 De A a B y C 01/01/1965 14:00:00 300.00 jwcondor
4 De 500 a 300 01/01/2012 16:00:00 600.00 xtcañari
5 De 300 a 222 01/01/1999 18:00:00 900.00 postgres
6 De 201 a 500 01/01/2015 20:00:00 -10.00 jwcondor
7 De 201 a 300 01/01/1999 22:00:00 -50.00 amacosta
8 De 500 a 222 01/01/2002 2:00:00 -90.00 jwcondor
9 De 300 a 222 01/01/2019 4:00:00 0.00 amacosta
BASES DE DATOS II
DET_TRANSFER
cueNumero traCodigo detTransferValor
C-201 2 700.00
C-305 2 -700.00
C-102 3 20.00
C-509 3 10.00
C-009 3 10.00
C-217 3 -40.00
C-222 6 400.00
C-201 6 200.00
C-305 6 -600.00
C-102 9 40.00
C-215 9 60.00
C-101 9 -100.00
a) Utilizando el concepto TRANSACCION de su DBMS.

b) Simular la caída de la transacción en cualquier punto.
DEFENSA: La defensa es por los literales A, B, y C. Cada numeral tiene el valor de 5 puntos.
A. EJECUCION DE UNA TRANSACCION CON 6 DETALLES

1. Ingresar una transacción.
2. Eliminar una transacción
3. Actualizar una transacción
4. Visualizar una transacción
5. ¿Cómo se compartan los campos totales resultado de los detalles?
6. ¿Cómo se comporta cuando se interrumpe una transacción?
7. ¿Cómo se cancela una transacción en proceso?
8. ¿Cómo se asegura la propiedad ACID de la transacción?
9. ¿Cómo se visualiza los estados de una transacción? (referencia lamina 20 capitulo 14)?
10. ¿Consulta adicional sobre su DBMS?

BASES DE DATOS II
P 2.2 TRANSACCION CONCURRENTE
A. PRESENTAR LA EJECUCIÓN DE UNA TRANSACCION, así:

a. Begin transaction
b. Save point
c. Roll back
d. Commit
B. PRESENTAR EL BLOQUEO POR TRANSACCIONES, así:
a. Sentencia SELECT ejecutando, que pasa con Insert, Delete, Update y Select de otra
transacción.
b. Sentencia INSERT ejecutando, que pasa con Insert, Delete, Update y Select de otra
transacción.
c. Sentencia DELETE ejecutando, que pasa con Insert, Delete, Update y Select de otra
transacción.
d. Sentencia UPDATE ejecutando, que pasa con Insert, Delete, Update y Select de otra
transacción.
C. SIMULAR UN DEAD LOCK:
a. Sean T1 y T2 transacciones
b. Ejecutar T1 con LOCK
c. Ejecutar T2 con LOCK
d. Las dos transacciones no pueden terminar porque estan en DEAD LOCK.
Referencias:
https://es.wikipedia.org/wiki/Transacci%C3%B3n_(inform%C3%A1tica)
1. Identifique las posibles transacciones de su contexto.

2. Identifique en un contexto real el número de transacciones anuales, mensuales, semanales, diarias
o por horas.
3. Determine el tiempo de ejecución de una transacción.
4. Generar pruebas de estrés de acuerdo al número de transacciones (10, 100, 1.000 y 10.000).
5. Consultar sobre métodos de balanceo de carga transaccional.
6. Consultar sobre métodos de distribución de carga transaccional.
7. Conclusiones
8. Recomendaciones.
TRANSFERENCIAS
traCodigo traDescripcion traFecha trahora traMonto traUsuario
1 De 101 a 102 01/01/1945 10:00:00 100.00 jwcondor
2 De 201 a 222 01/01/2010 12:00:00 200.00 postgres
3 De A a B y C 01/01/1965 14:00:00 300.00 jwcondor
4 De 500 a 300 01/01/2012 16:00:00 600.00 xtcañari
5 De 300 a 222 01/01/1999 18:00:00 900.00 postgres
6 De 201 a 500 01/01/2015 20:00:00 -10.00 jwcondor
7 De 201 a 300 01/01/1999 22:00:00 -50.00 amacosta
8 De 500 a 222 01/01/2002 2:00:00 -90.00 jwcondor
9 De 300 a 222 01/01/2019 4:00:00 0.00 amacosta
BASES DE DATOS II
DET_TRANSFER
cueNumero traCodigo detTransferValor
C-201 2 700.00
C-305 2 -700.00
C-102 3 20.00
C-509 3 10.00
C-009 3 10.00
C-217 3 -40.00
C-222 6 400.00
C-201 6 200.00
C-305 6 -600.00
C-102 9 40.00
C-215 9 60.00
C-101 9 -100.00
c) Utilizando el concepto TRANSACCION de su DBMS.

d) Simular la caída de la transacción en cualquier punto.
2. INSERTAR UN PRESTAMO NUEVO DE 10500 USD A SU NOMBRE COMO

CLIENTE, EN LA NUEVA SUCURSAL METRO-UIO.
3. ELIMINAR DE MANERA CONSISTENTE EL PRESTAMO ANTERIOR,

ELIMINANDO SU REGISTRO DE CLIENTE Y LA SUCURSAL METRO-UIO.

TRANSFERENCIA BANCARIA
CueNumero Saldo-Inicial Movimiento Saldo-Final
$ 347,00 $ 347,00
C-101 $ 500,00 -275,00 $ 225,00
C-102 $ 400,00 50,00 $ 450,00
C-201 $ 900,00 75,00 $ 975,00
C-215 $ 700,00 125,00 $ 825,00
C-217 $ 750,00 25,00 $ 775,00
$ 700,00 $ 700,00
$ 350,00 $ 350,00
$ 3,00 $ 3,00
TOTALES: $ 4.650,00 0,00 $ 4.650,00
a) Realizar una (1) transferencia.
b) Realizar diez (10) transferencias.
c) Realizar cien (100) transferencias.
d) Realizar mil (1.000) transferencias.
e) Realizar diez mil (10.000) transferencias.

BASES DE DATOS II
a. Realizar una (1) transacción.

b. Realizar diez (10) transacciones.
c. Realizar cien (100) transacciones.
d. Realizar mil (1.000) transacciones.
e. Realizar diez mil (10.000) transacciones.
B. PLANIFICACION Y EJECUCION
1. ¿Cómo planifico la ejecución de transacciones consecutivas?
2. ¿Cómo determina la carga seriable?
3. ¿Cómo se visualiza los recursos utilizados (CPU, RAM, DISCO)?
4. ¿Cómo procedería hacer tipo batch?
5. ¿Cómo se puede hacer en paralelo las transacciones?
6. ¿Cómo se puede distribuir las transacciones?
C. BLOQUEOS EN TRANSACCIONES CON 6 DETALLES

1. Bloqueo de una transacción con su misma transacción.
2. Bloqueo de una transacción con otra transacción.
3. Bloqueo de base de datos mutuo (dead lock).
4. ¿Cómo planifico el bloqueo de data?
5. ¿Cómo resolvió el bloqueo entre transacciones similares?
6. ¿Cómo resolvió el bloqueo entre transacciones distintas?
7. ¿Cómo resolvió el dead lock?
8. ¿Cómo planifico el bloqueo de escritura?
9. ¿Cómo planifico el bloqueo de actualización?
10. Consulta adicional sobre su DBMS.

11. Ingresar una transacción.
12. Eliminar una transacción
13. Actualizar una transacción
14. Visualizar una transacción
15. ¿Cómo se compartan los campos totales resultado de los detalles?
16. ¿Cómo se comporta cuando se interrumpe una transacción?
17. ¿Cómo se cancela una transacción en proceso?
18. ¿Cómo se asegura la propiedad ACID de la transacción?
19. ¿Cómo se visualiza los estados de una transacción? (referencia lamina 20 capitulo 14)?
20. ¿Consulta adicional sobre su DBMS?
EJ. COMPRAS – TRANSACCION O/C
Una orden de compra (O/C) es la transacción típica del módulo COMPRAS. Se considera
como un todo a la información de la tabla ORDEN_COMPRA, conjuntamente con el o
los detalles de la O/C en mención de la tabla ARTxOC. A continuación, la imagen de una
O/C:
BASES DE DATOS II
ORDEN DE COMPRA
O/C_CAB
PROVEEDOR: LA FABRIL S.A. No.: 4578
IDENTIFICACION: 170854578001 FECHA: 2016-11-11
Linea DESCRIPCION CANTIDAD U/M Valor Unitario IVA Subtotal

1 Arroz flor 6 qq $ 36,50 S $ 219,00
2 Agua enbotellada 12 uni $ 0,75 S $ 9,00
ARTxOC
3 Papel impresora A4 10 cajas $ 50,00 S $ 500,00
4 Computador HZ core i7 4 uni $ 750,62 S $ 3.002,48
5 Arroz flor 6 qq $ 36,50 S $ 219,00
6 Arroz flor 6 qq $ 36,50 S $ 219,00
SUMA: $ 4.168,48
7% DESCUENTO: $ 291,79
O/C
14% IVA: $ 542,74
TOTAL: $ 3.876,69
Los estados de la O/C son:

- Abierta, cuando la O/C se encuentra en proceso, se ha ingresado la cabecera y se
están ingresando el(los) detalle(s) de los artículos comprados.
- Cancelada, cuando el usuario determina que no quiere seguir manteniendo abierta
la O/C y deja registro de su actividad.
- Cerrada, cuando la O/C ha sido verificada por el usuario del módulo, en cuyo caso
se cambia de estado los detalles, se calcula los subtotales, totales, descuentos e
impuestos para actualizar los campos de la cabecera y el estado de este registro a
cerrado.
- Cuando una O/C se cierra se genera la información correspondiente para el
módulo de contabilidad como un asiento contable. Se presenta el asiento contable
de la O/C anterior:
ASIENTO CONTABLE
ASIENTO
DESCRIPCION: LA FABRIL S.A. No.: 4578

FECHA: 2016-11-11
TOTAL: $ 5.003,01 $ 5.003,01
Linea DESCRIPCION DEBE HABER ESTADO
CUExASI
1 INVENTARIOS $ 4.168,48 $ - ABI

2 DESCUENTO $ 291,79 $ - ABI
3 IVA $ 542,74 $ - ABI
4 BANCOS PICHINCHA1 $ - $ 5.003,01 ABI
- Cuando una O/C se cierra se genera la información correspondiente para el

módulo de inventarios en las tablas RECEPCIONES y ARTxREC. Como se
puede apreciar en el siguiente gráfico:
RECEPCION
REC_CAB
DESCRIPCION: LA FABRIL S.A. No.: 4578

FECHA: 2016-11-11
QTYTOTAL 44
Linea DESCRIPCION QtyOC U/M QtyRec Por_Recibir
1 Arroz flor 6 qq 0 6
ARTxREC
2 Agua enbotellada 12 uni 0 12

3 Papel impresora A4 10 cajas 0 10
4 Computador HZ core i7 4 uni 0 4

BASES DE DATOS II
TRANSACCIONES - Criterios de evaluación:
TRANSACCION ponderacion PUNTOS
ORDEN DE COMPRA MAX 14

Un registro de OC cabecera [1] 2
Seis registros de detalle detalles [6] 6
OC en memoria RAM cabecera [1] y detalles 2
OC calculo de subtotales
Actualiza cabecera 2
totales
OC en disco COMMIT cabecera [1] y detalles 2
DATA A CONTABILIDAD MAX 3
Un registro de cabecera de
cabecera [1] 1
asiento
Dos o mas registros de
detalles [>= 2] NA ó 2
detalle de asiento
DATA A INVENTARIOS MAX 3
cabecera [1] 1
recepcion
Seis registros de detalle de
detalles [6] NA ó 2
recepcion
DATA A OTRO MODULO MAX 3
cabecera [1] 1
otro modulo
Seis registros de detalle
detalles [6] NA ó 2
deotro modulo
WORKBENCH MAX 5
Hasta 9 transacciones 2
Mas de 999 transacciones 5
SUMA 25
BASES DE DATOS II
P 2.3 ROLES, USUARIOS y AUTORIZACIONES
A. GENERAR LA MATRIZ DE ROLES, TABLAS Y AUTORIZACIONES, así:

a. Cuatro (4) ROLES de usuarios finales.
b. Cuatro (4) ROLES de usuarios técnicos.
c. Cuatro (4) TABLAS con las autorizaciones por ROL de comandos SQL (DDL, DML,
AUTH, BACKUP).
d. Crear cuatro (4) usuarios por cada ROL de usuario final.
B. GESTION DE USUARIOS CONECTADOS, así:
a. Con cuatro (4) usuarios de distinto ROL, conectados a la base de datos.
b. Monitorear el consumo de CPU, STORAGE de cada usuario conectado.
c. Discriminar al usuario que puede detenerse o cancelar la conexión de acuerdo al uso
máximo de CPU o STORAGE, o por estar bloqueando los registros de la base de datos.
d. Determinar y verificar la pausa o inactivación del servicio de DBMS de acuerdo al uso
máximo de CPU o STORAGE, o por estar bloqueando los registros de la base de datos
C. CONEXIÓN REMOTA DE USUARIOS:
a. Conectar un usuario de cada ROL a la base de datos de manera remota.
b. Monitorear el consumo de CPU, STORAGE de cada usuario conectado.
c. Discriminar al usuario que puede detenerse o cancelar la conexión de acuerdo al uso
d. Determinar y verificar la pausa o inactivación del servicio de DBMS de acuerdo al uso
D. CONCURENCIA DE USUARIOS:
a. Con cuatro (4) usuarios del mismo ROL, ejecutando una misma transacción.
b. Dar prioridad a una transacción de un usuario en particular, para que su transacción
finalice primero.
c. Simular un bloqueo desde un usuario a otro.
d. Determinar el número máximo de usuarios concurrentes a su base de datos.
Referencias:
https://es.wikipedia.org/wiki/Computaci%C3%B3n_concurrente
Es necesario definir los ROLES que cumplen los diferentes colaboradores para de esta
manera definir los niveles de acceso a información, así como los permisos de ejecución
de comandos SQL. Los roles generalmente están asociados con el cargo o función que se
desempeña, por lo que se mantienen estables independientemente de la persona
designada.
La conexión e ingreso al sistema dependerá del rol asociado al usuario que ingrese. Cada
usuario tendrá su identificación userid con su respectiva contraseña que forzará a ser
cambiada cada 45 días.
Los roles se agrupan en: roles técnicos y roles de usuario final. Por lo cual es necesario
generar una matriz que especifique la autorización de los comandos SQL, respecto al rol
indicado y actuando a nivel de tabla de base de datos.
Los comandos SQL se agrupan en DDL, DML; así: DDL son Create, Drop, Alter; DML
son Insert, Delete, Update, Select; AUTH son Grant, Revoke; y Backup, Restore.
TALLER:
1. Identifique los ROLES de su módulo y las autorizaciones de comandos SQL. Referénciese en el

módulo COMPRAS presentado a continuación.
2. Identifique en un contexto real el número de concurrencias anuales, mensuales, semanales, diarias
o por horas.

BASES DE DATOS II
3. Determine el tiempo de ejecución de una concurrencia.

4. Generar pruebas de estrés de acuerdo al número de concurrencias (10, 100 y 1000).
5. Consultar sobre métodos de balanceo de carga de concurrencias por accesos y conexiones.
6. Consultar sobre métodos de distribución de carga de concurrencias.
7. Conclusiones
8. Recomendaciones.
ROLES y AUTORIZACIONES EN EL CONTEXTO BANCA
Los roles técnicos identificados son: operador, administrador de la base de datos,

programador, analista, jefe de sistemas, gerente de tecnología.
Los roles de usuario final, se agrupan en gerenciales: Gerente de Banco; Mandos Medios:
Jefe Operativo, Jefe de agencia y Nivel Operativo: cajero o cajera.
S, SELECT I, INSERT D, DELETE U, UPDATE C, CREATE D, DROP A, ALTER

G, GRANT RV, REVOKE B, BACKUP R, RESTORE
ROLES TIPO USUARIO ROLES TIPO TECNICO
TABLA Administrador
No. MODULO: Gerente Jefe Cajero DBA Programador Operador
MAESTRA: del Sistema
1 CUENTAS CUENTAS S, S, I, D, U S, U G, RV C, D, A S, I, D, U B, R
2 PRESTAMOS PRESTAMOS S, S, I, D, U S, U G, RV C, D, A S, I, D, U B, R
3 CLIENTES CLIENTES S, S, I, D, U S, U G, RV C, D, A S, I, D, U B, R
4 SUCURSALES SUCURSALES S, S, I, D, U S, U G, RV C, D, A S, I, D, U B, R
ROLES Y
10 USUARIOS
AUTORIZACIONES S, S, S, S, I, D, U C, D, A S, I, D, U B, R
EJ.: ROLES EN CONTEXTO UNIVERSITARIO
Los roles técnicos identificados son: operador, administrador de la base de datos,

programador, analista, jefe de sistemas, gerente de tecnología.
Los roles de usuario final, se agrupan en gerenciales: Rector, Prorector, Vicerrector,

Director General; Académicos: Decano, Subdecano, Director de Escuela, Coordinador,
Docente, Tutor, Estudiante, Graduado; Administrativo: Director General, Director,
Asistente, Secretaria, Coordinador; Investigación: Director de proyecto, investigador,
auxiliar de investigación; Vinculación: Director, Coordinador RSU, Docente RSU,
estudiante RSU, Coordinador de Practicas, Docente de Practicas, estudiante de Practicas.
Como lo presenta las tablas siguientes:
BASES DE DATOS II
AREAS ROLES
DIRECTOR DE PROYECTO DE INVESTIGACION
INVESTIGACION INVESTIGADOR
AUXILIAR DE INVESTIGACION
AREAS ROLES DIRECTOR
RECTOR ADMINISTRATIVOS ASISTENTE
PRORECTOR SECRETARIA
GERENCIAL VICERRECTOR COORDINADOR RSU
DIRECTOR GENERAL DOCENTE RSU
DIRECTOR ESTUDIANTE RSU
VINCULACION
DECANO COORDINADOR PRACTICAS
SUBDECANO DOCENTE PRACTICAS
DIRECTOR DE CARRERA ESTUDIANTE PRACTICAS
DIRECTOR DE LABORATORIO GERENTE DE TECNOLOGIA
ACADEMIA COORDINADOR DE AREA JEFE DE SISTEMAS
DOCENTE ANALISTA
IT PROFESIONALES
TUTOR PROGRAMADOR
ESTUDIANTE ADMINISTRADOR
GRADUADO OPERADOR
EJ. ROLES EN MODULO COMPRAS
En el módulo de compras se tienen los siguientes ROLES autorizados a los distintos

comandos SQL dependiendo de la tabla del módulo, así:
S, SELECT I, INSERT D, DELETE U, UPDATE C, CREATE D, DROP A, ALTER

G, GRANT RV, REVOKE B, BACKUP R, RESTORE
ROLES TIPO USUARIO ROLES TIPO TECNICO
Auxiliar Administrador
MODULO: No. TABLA: Gerente Jefe Compras DBA Programador Operador
Compras del Sistema
1 Proveedores S, S, I, D, U S, U G, RV C, D, A S, I, D, U B, R
2 Orden_Compra S, S, S, I, D, U G, RV C, D, A S, I, D, U B, R
COMPRAS
3 Art_x_Compra S, S, S, I, D, U G, RV C, D, A S, I, D, U B, R
4 Articulos S, S, S, G, RV C, D, A S, I, D, U B, R
El rol GERENTE tiene autorización a:

- SELECT de las tablas Proveedores, Órdenes de Compra, Artículos por orden de
compra, Artículos.
El rol JEFE DE COMPRAS tiene autorización a:
- SELECT de las tablas Órdenes de Compra, Artículos por orden de compra,
Artículos.
- SELECT, INSERT, DELETE, UPDATE de la tabla Proveedores.
El rol AUXILIAR DE COMPRAS tiene autorización a:
- SELECT, INSERT, DELETE, UPDATE de las tablas Orden de Compra y
Artículos por Orden de Compra
- SELECT, UPDATE de la tabla Proveedores.
El rol ADMINISTRADOR DEL SISTEMA tiene autorización a:
- GRANT, REVOKE, UPDATE de las tablas Órdenes de Compra, Artículos por
orden de compra, Artículos.
El rol DBA tiene autorización a:
- CREATE, DROP, ALTER de las tablas Proveedores, Órdenes de Compra,
Artículos por orden de compra, Artículos.
El rol PROGRAMADOR tiene autorización a:

BASES DE DATOS II
- INSERT; DELETE, UPDATE, SELECT de las tablas Proveedores, Órdenes de

Compra, Artículos por orden de compra, Artículos. De una base de datos en
ambiente de pruebas con datos de pruebas
El rol OPERADOR tiene autorización a:
- BACKUP, RESTORE de las tablas Proveedores, Órdenes de Compra, Artículos
por orden de compra, Artículos.
DEFENSA: La defensa es por los literales A y B. Cada numeral tiene el valor de 5 puntos.
A. VERIFICACION DE ROLES y USUARIOS

1. Presentar un ejemplo de rol técnico, usuario final y usuario especialista en la tabla
respectiva de su DBMS.
2. Presentar la pantalla de administración de usuarios conectados.
3. ¿Qué sucede cuando un usuario con permiso SELECT, mira un campo actualizado por
un usuario con permiso UPDATE?
4. ¿Del numeral 3 la información que ve es antes o después de UPDATE?
ROLES x 5.
TIPO ¿Qué sucede ponderacion
cuando un usuario con permiso UPDATE, quiere actualizar un campo
PUNTOS
actualizado por un usuario con permiso UPDATE?
6. ¿Del numeral 5 la información que actualiza es antes o después de UPDATE?
7. ¿Cómo se puede ver las contraseñas de los usuarios?
ROLES TIPO USUARIO MAX encriptadas?
8. ¿Las contraseñas de los usuarios están 16 ¿Qué encriptación utiliza su DBMS?
Permite comandos SQL
9. ¿Cómo se restaurarías las contraseñas olvidadas?
2
10. ¿Cómoasignados
Gerente se priorizaría a usuarios cuando hay urgencia de un proceso?
NO permite comandos SQL
2
desautorizados
B. USUARIOS CONCURRENTES
1. ¿Cómo se comporta su DBMS para usuarios 2 concurrentes del mismo ROL?
asignados
Jefe Compras
2. ¿Cómo se comporta con 1, 6, 9 o más del mismo rol?
3. ¿Cómodesautorizados
se comporta su DBMS para usuarios 2 concurrentes de distinto ROL?
4. ¿CómoPermite
se comporta con
comandos SQL
1, 6, 9 o más de distinto rol?
5. ¿Qué rol es el que tiene menos usuarios 2
potenciales?
asignados
Auxiliar Compras
6. ¿Qué rol
NO es el quecomandos
permite tiene másSQLusuarios potenciales?
7. ¿Con dos usuarios del mismo ROL ejecutando 2 un mismo comando quien tiene prioridad?
desautorizados
8. ¿Con dos usuarios de distinto
Permite comandos SQL ROL ejecutando un mismo comando quien tiene prioridad?
9. ¿Se puede asignar prioridad de ejecución a 2los ROLES?
asignados
Administrador del Sistema
10. ¿Su DBMS permite
NO permite priorizar
comandos SQL procesos por ROL?
2
desautorizados
ROLES TIPO TECNICO MAX 12
2
asignados
DBA
2
desautorizados
2
asignados
Programador
2
desautorizados
2
asignados
Operador
2
desautorizados
WORKBENCH MAX 22
Hasta 1 usuario 2
Hasta 2 usuarios 4
Hasta 9 usuarios 6
Mas de 99 usuarios 10
SUMA 50
BASES DE DATOS II
P 2.4: PRUEBAS DE ESTRÉS
Referencias:
https://en.wikipedia.org/wiki/Database_testing
http://www.cse.wustl.edu/~jain/cse567-08/ftp/db/index.html

BASES DE DATOS II
PLANTEAMIENTO: Enfocado a las pruebas TPC, verificar lo siguiente:
1. Estrategias de recuperación de consistencia de datos:

a. A nivel de atributo.
b. A nivel de registro.
c. A nivel de tabla
d. A nivel de base de datos.
2. Estrategias de recuperación de consistencia a nivel de transacción.
3. Estrategias de recuperación de consistencia a nivel de concurrencia.
TALLER: Utilizando el modelo banca. Realice las siguientes pruebas de estrés:
1. INSERTAR 9, 99, 999, 9999, 99999 … registros en la tabla debe o en la tabla tiene.
Sugerencia utilizar una función con parámetros o un store procedure.
2. REALIZAR 9, 99, 999, 9999, 99999 … TRANSACCIONES de actualización de cuentas
o de préstamos. Sugerencia utilizar una función con parámetros o un store procedure.
3. EJECUTAR un script con 9, 99, 999, 9999, 99999 … SENTENCIAS SQL.
DEFENSA: La defensa es relacionada con su DBMS y el modulo asignado del ERP. Cada numeral
tiene el valor de 5 puntos.
A. VERIFICACION DE:
1. Cambio de tipo de datos de carácter a numérico.
2. Cambio de tipo de datos de carácter a carácter con menor tamaño.
3. Cambio de tipo de datos de numérico a date.
4. Cambio de tipo de dato de date a numérico.
5. A nivel de registro implementar un constraint de clave foránea que no existía.
6. A nivel de registro implementar un constraint de validación de un campo vs otro de la
misma tabla. Por ejemplo, Fecha de venta > fecha de compra.
7. A nivel de transacción, como recuperar la cabecera.
8. A nivel de transacción, como recuperar los detalles.
9. A nivel de tabla como recuperar una tabla corrompida.
10. A nivel de tabla como recuperar una tabla que no existía en el backup.
BASES DE DATOS II
III.- CONTINGENCIA: BDD Paralelas, Distribuidas y DBaaS.
JW CONDOR | III.- CONTINGENCIA: BDD Paralelas, Distribuidas y 31

DBaaS.
BASES DE DATOS II
P 3.1: PLANES DE CONTINGENCIA
Referencias:
https://es.wikipedia.org/wiki/Recuperaci%C3%B3n_de_datos
PLANTEAMIENTO: Enfocado a la gestión de datos se plantean los siguientes criterios:
A. Estrategias de recuperación de consistencia de datos:

c. A nivel de tabla
B. Estrategias de recuperación de consistencia a nivel de transacción.
c. A nivel de tabla
C. Estrategias de recuperación de consistencia a nivel de concurrencia.
c. A nivel de tabla
D. Estrategia de migración de datos
c. A nivel de tabla
A. TALLER CON EL MODELO BANCA
10.000 REGISTROS TRANSACCIONALES. MIGRAR DE SU DBMS ANTERIOR AL

ACTUAL:
1. Utilizando backup.
2. Utilizando csv.
3. Utilizando XML.
4. Utilizando JSON.
DEFENSA: La defensa es relacionada con su DBMS y el modulo asignado del ERP. Cada numeral
tiene el valor de 5 puntos.
B. VERIFICACION DE:
1. Cambio de tipo de datos de carácter a numérico.
2. Cambio de tipo de datos de carácter a carácter con menor tamaño.
3. Cambio de tipo de datos de numérico a date.
4. Cambio de tipo de dato de date a numérico.
5. A nivel de registro implementar un constraint de clave foránea que no existía.
6. A nivel de registro implementar un constraint de validación de un campo vs otro de la
misma tabla. Por ejemplo, Fecha de venta > fecha de compra.
7. A nivel de transacción, como recuperar la cabecera.
8. A nivel de transacción, como recuperar los detalles.
9. A nivel de tabla como recuperar una tabla corrompida.
10. A nivel de tabla como recuperar una tabla que no existía en el backup.
BASES DE DATOS II
P 3.2 BDD PARALELAS
Referencia: https://en.wikipedia.org/wiki/Distributed_Data_Management_Architecture
TALLER 3.1.A REPLICACION:

o . Utilizar el modelo banca
o . Utilizar el DBMS asignado
o . Conectar dos equipos c/u con su DBMS local
o . Verificar Insert, Delete, Update y Select en Server_local replicado a
Server_esclavo
3.1.A ENTREGABLES:
* Un VIDEO CLIP con las validaciones presentadas en la rúbrica a continuación.
RUBRICA 10 6 3
Conexión de equipos – red Ping desde & Ping Ping desde Ping local
de datos hacia
Acceso remoto de Cliente SQL ok Cliente SQL local CMD SQL
Server_esclavo
Insert en Server_local OK local OK esclavo Ok cmd
Delete en Server_local OK local OK esclavo Ok cmd
Update en Server_local OK local OK esclavo Ok cmd
Select en Server_local OK local OK esclavo Ok cmd
Apagar Server_Local OK apagado
Revisar data actualizada en OK 100
Esclavo.
PROYECTO 3.1 BDD PARALELA:

o Utilizar el modelo banca
o Utilizar el DBMS asignado
o Generar la BDD “A” y la BDD “B”

DBaaS.
BASES DE DATOS II
o Implementar paralelismo a nivel de:

o Hardware (disco) ó
o Sistemas Operativo ó
o DBMS ó
o Capa de Aplicación
3.1 ENTREGABLES:
RUBRICA 10 5 0
Insertar un registro en Registro insertado en BDD Registro insertado en Registro insertado
paralelo. A y en BDD B. al mismo BDD A y luego BDD solo en BDD A.
tiempo B.
Eliminar un registro en Registro eliminado en Registro eliminado en Registro
paralelo. BDD A y en BDD B. al BDD A y luego BDD eliminado solo en
mismo tiempo B. BDD A.
Actualizar un registro en Registro actualizado en Registro actualizado Registro
paralelo. BDD A y en BDD B. al en BDD A y luego en actualizado solo
mismo tiempo BDD B. en BDD A.
Visualizar una tabla de la Todos los registros Todos los registros Los registros no
base de datos B tomados desde BDD B. tomados desde BDD aparecen en BDD
A. B.
BASES DE DATOS II
P 3.3 BDD DISTRIBUIDAS
Referencia: https://en.wikipedia.org/wiki/Distributed_Data_Management_Architecture
TALLER 3.3.A REPLICACION:

o . Utilizar el modelo banca
o . Utilizar el DBMS asignado
o . Conectar dos equipos c/u con su DBMS local
o . Verificar Insert, Delete, Update y Select en Server_local replicado a
Server_esclavo
3.3.A ENTREGABLES:
RUBRICA 10 6 3
Conexión de equipos – red Ping desde & Ping Ping desde Ping local
de datos hacia
Acceso remoto de Cliente SQL ok Cliente SQL local CMD SQL
Server_esclavo
Insert en Server_local OK local OK esclavo Ok cmd
Delete en Server_local OK local OK esclavo Ok cmd
Update en Server_local OK local OK esclavo Ok cmd
Select en Server_local OK local OK esclavo Ok cmd
Apagar Server_Local OK apagado
Revisar data actualizada en OK 100
Esclavo.
PROYECTO 3.1 BDD PARALELA:

o Utilizar el modelo banca
o Utilizar el DBMS asignado
o Generar la BDD “A” y la BDD “B”

DBaaS.
BASES DE DATOS II
o Implementar paralelismo a nivel de:

o Hardware (disco) ó
o Sistemas Operativo ó
o DBMS ó
o Capa de Aplicación
3.1 ENTREGABLES:
RUBRICA 10 5 0
Insertar un registro en Registro insertado en BDD Registro insertado en Registro insertado
paralelo. A y en BDD B. al mismo BDD A y luego BDD solo en BDD A.
tiempo B.
Eliminar un registro en Registro eliminado en Registro eliminado en Registro
paralelo. BDD A y en BDD B. al BDD A y luego BDD eliminado solo en
mismo tiempo B. BDD A.
Actualizar un registro en Registro actualizado en Registro actualizado Registro
paralelo. BDD A y en BDD B. al en BDD A y luego en actualizado solo
mismo tiempo BDD B. en BDD A.
Visualizar una tabla de la Todos los registros Todos los registros Los registros no
base de datos B tomados desde BDD B. tomados desde BDD aparecen en BDD
A. B.
BASES DE DATOS II
P 3.4 BDD aaS
Con una base de datos como modelo de servicio, los propietarios de las aplicaciones no tienen que instalar
y mantener la base de datos ellos mismos. En cambio, el proveedor del servicio de base de datos se
responsabiliza de la instalación y el mantenimiento de la base de datos, y los propietarios de las aplicaciones
pagan según el uso que hagan del servicio.
Por ejemplo, Amazon Web Services ofrece tres bases de datos como ofertas de servicios como parte de su
cartera en la nube: SimpleDB, una tienda de valores-clave NoSQL; Amazon RDS, un servicio de base de
datos relacional que incluye soporte para MySQL, Oracle y otros; y DynamoDB. Microsoft ofrece su base
de datos SQL Azure servicio de en su plataforma de servicios en la nube Azure. La plataforma de
computación en la nube Rackspace ofrece una base de datos como servicio para MySQL y MongoDB.
La base de datos como proveedores de servicios no está limitada a las plataformas de computación en la
nube. Por ejemplo, MongoDB como proveedor de servicios mLab les permite a sus clientes alojar sus bases
de datos en AWS, Azure o Google Cloud Platform. Los proveedores de bases de datos también han lanzado
sus propios servicios bajo este modelo. Oracle Cloud proporciona su propia base de datos como servicio,
lo que permite a los usuarios acceder a Oracle Database 11g y 12c como servicios en la nube. MongoDB
lanzó recientemente su propio MongoDB alojado como servicio, MongoDB Atlas.
Referencia: https://en.wikipedia.org/wiki/Cloud_database
TALLER 3.2 → PROYECTO:

. Utilizar el modelo banca o su módulo de ERP
. Utilizar el DBMS asignado
. Investigar su DBMS como servicio, condiciones del servicio.
. Si su DBMS no está como servicio. ¿que DBMS proponen?
1. ENTREGABLES:
RUBRICA 10 6 3
Proveedores de DBaaS Internacionales locales Otros
Precios Tarifa byte Tarifa transacción Tarifa usuario
Administración facilidad Amigable Complicada No entendible
Escalibilidad limites ilimitada Límite de disco Límite de CPU
Implementación con Módulo de ERP Módulo de Banca Módulo
módulo ejemplo
Solución hibrida Permitida Condicionada No permitida
Seguridad Encriptación total Encriptación No
conexión encriptación
Perdida de claves master Alternativa Servicio terceros No alternativa
recuperación

DBaaS.
BASES DE DATOS II
IV.- SSD, DW, DM y BIG DATA
APORTE FINAL
BI – DW – DM - BD
BASES DE DATOS II
P 4.1 DSS Decision Support System -BI-
Referencia: https://es.wikipedia.org/wiki/Inteligencia_empresarial
DEFENSA DE PROYECTO, REFERENCIA CONTEXTO BANCA:

1) Presentar el negocio analizado.
2) Explicación del negocio y su finalidad.
3) Ejemplo aplicado al negocio.
4) Operaciones SQL implicaciones.
5) ** Subir PDF con captura de pantallas a la plataforma.
RUBRICA DE EVALUACION:
No. CRITERIO (BANCA) 10 6 3 0
1 Campo depurado. Ej.: Valor Constraint y Constraint Datos Solo tipo
de activos >= $0. Datos de dato.
depurados
2 Coherencia entre campos. Ej.: Constraint y Constraint Datos Solo tipo
Fecha de Préstamo > Fecha de Datos de dato.
Cuenta. depurados
3 Regla de Negocio. Ej.: Constraint y Constraint Datos Solo tipo
Préstamos otorgados a clientes Datos de dato.
con edad menor a 65 años. depurados
4 Regla de Negocio. Ej.: Ofrecer Constraint y Constraint Datos Solo tipo
créditos con condiciones Datos de dato.
preferenciales a clientes que depurados
tienen mas de $5.000 USD en
sus cuentas.
JW CONDOR | IV.- SSD, DW, DM y BIG DATA 39

BASES DE DATOS II
P 4.2 DW DATA WAREHOUSE
Referencia: https://en.wikipedia.org/wiki/Data_warehouse
DEFENSA DE PROYECTO IaaS para DW

1) Presentar las fuentes de información. (Source System)
2) Presentar un ETL (Extraction Transformation Loading)
3) Presentar la infraestructura DW
4) Operaciones SQL especializadas para DW
No. RUBRICA DW 10 6 3 0
1 Numero de fuentes de Cuatro fuentes o Hasta dos Una fuente Cero
información más fuentes fuentes
2 Fuentes con relación Fuerte coherencia Coherencia Poca Nada de
coherente de datos media coherencia coherencia
3 Cantidad de registros Seis mil registros Hasta tres mil Hasta mil Cero
o más registros registros registros
4 Tipos de fuentes de datos Cuatro tipos de Hasta dos tipos Un tipo de Cero tipo
(BDD, XLS, CSV, PDF) fuentes diferentes de fuentes fuente de fuentes
BASES DE DATOS II
P 4.3 DM DATA MINING
Referencia: https://en.wikipedia.org/wiki/Data_mining
DEFENSA DE PROYECTO Data Cube

1) Presentar un Data Cube (BANCA ej.:
a. Sucursales {tiempo, ubicación, monto}
b. Clientes {tiempo, rangos edad, sexo}
c. Cuentas {tiempo, ubicación, montos}
d. Prestamos {tiempo, ubicación, montos}
2) Explicar el Data Cube
3) Definir información clasificada por ejemplo símil con mina de oro:
a. Arena $50 clientes con A
b. Cobre $500 clientes con prestamos no pagados
c. Plata $50.000 clientes con cuentas y no prestamos
d. Oro $500.000 clientes con garantes cruzados.
4) Operaciones SQL para DM
No. CRITERIO DM 10 6 3 0
(BANCA)
1 Cubo CLIENTES Información Información Información Información
tipo ORO tipo PLATA tipo tipo
BRONCE ARENA
2 Cubo #2 Información Información Información Información
BANCA 4 cubos. Uno x cada tipo ORO tipo PLATA tipo tipo
tabla maestra. BRONCE ARENA
JW CONDOR | IV.- SSD, DW, DM y BIG DATA 41

BASES DE DATOS II
P 4.4 BIG DATA
DEFENSA DE PROYECTO
1) Presentación del tema.
2) Explicación del tema.
3) Aplicativo ejemplo que aplica el tema.
4) Ventajas y desventajas.
5) Operaciones SQL implicaciones
6) Informe del tema.
1. ENTREGABLES:
RUBRICA
1) Acorde a normativa de presentación power point
2) Acorde a exposición.
3) Acorde a respuestas dadas al auditorio
4) Acorde a conclusiones y recomendaciones.

Bases II - Proyectos 2020-06-15

Cargado por

Copyright:

Formatos disponibles

Bases II - Proyectos 2020-06-15

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bases II - Proyectos 2020-06-15

Cargado por

Copyright:

Formatos disponibles

La infraestructura tecnológica que soportan los

DBMS, la optimización de los QUERY y los

P 4.2 DW DATA WAREHOUSE .............................................................................. 40

OBJETIVOS DE PROYECTOS DE BASES DE DATOS II:

1. EVIDENCIA TIPO INFORME:

2. EVIDENCIA TIPO PRESENTACION:

3. EVIDENCIA TIPO VIDEO CLIP:

JW CONDOR | OBJETIVOS DE PROYECTOS DE BASES DE DATOS II: 3

Secuencia: Escena: Duración

4. EVIDENCIA TIPO SCRIPT SQL OPTIMIZACION DE <QUERYS>:

SQL O1:: SELECT *

Tiempo en segundos 0.2458 1.2543 5.4578

5. EVIDENCIA TIPO IMPLEMENTACION:

CONDICIONES DE ENTREGA DE EVIDENCIAS:

La distribución semanal de los DBMS, se indica a continuación:

GRUPO #1 MariaDB MySQL PostgreSQL SQLServer Oracle DB2

GRUPO #2 MySQL PostgreSQL SQLServer Oracle DB2 MariaDB

GRUPO #3 PostgreSQL SQLServer Oracle DB2 MariaDB MySQL

GRUPO #4 SQLServer Oracle DB2 MariaDB MySQL PostgreSQL

GRUPO #5 Oracle DB2 MariaDB MySQL PostgreSQL SQLServer

GRUPO #6 DB2 MariaDB MySQL PostgreSQL SQLServer Oracle

JW CONDOR | CONDICIONES DE ENTREGA DE EVIDENCIAS: 5

MODELO BANCA PDM

JW CONDOR | CONTEXTOS E INSTANCIAS: 7

TABLA: A #Reg B #Reg C #Reg D #Reg

I.- INFRAESTRUCTURA y OPTIMIZACION DE <QUERYs>

JW CONDOR | I.- INFRAESTRUCTURA y OPTIMIZACION DE 9

P 1.1 RAID, STORAGE & SSD

INFRAESTRUCTURA TECNOLOGICA PARA SERVICIO DE BASES DE DATOS

No. PLANTEAMIENTO REHACER REGULAR BUENO SATISFACTORIO

P 1.2 INDEX & VIEW.

La indexación permite tener organizada la información de manera lógica mediante

o Utilizar el DBMS asignado.

CONSULTAR PARA SU DBMS:

1. Ventajas y Desventajas de INDEX HASH.

a. Implementar INDEX HASH sobre un campo de una tabla.

JW CONDOR | I.- INFRAESTRUCTURA y OPTIMIZACION DE 11

2. QUERY02 – Realizar el producto cartesiano entre las tablas SUCURSALES,

No. PLANTEAMIENTO REHACER REGULAR BUENO SATISFACTORIO

Ej. RUBRICA 1 PostgreSQL (BUENO):

P 1.3 <QUERY> EJECUCION

o Utilizar el DBMS asignado.

1. Estado del arte sobre PALABRAS RESERVADAS SQL EQUIVALENTES.

1. Implementar las consultas con número de registros iniciales.

No. PLANTEAMIENTO REHACER REGULAR BUENO SATISFACTORIO

JW CONDOR | I.- INFRAESTRUCTURA y OPTIMIZACION DE 13

P 1.4 <QUERY> OPTIMIZACION

o Utilizar el DBMS asignado.

1. Estado del arte sobre COSTO DE EJECUCION.

Realizar las consultas propuestas en el material SQL básico, medio y avanzado.

JW CONDOR | I.- INFRAESTRUCTURA y OPTIMIZACION DE 15

No. PLANTEAMIENTO REHACER REGULAR BUENO SATISFACTORIO

No. MODULO GRUPO TRANSACCION

JW CONDOR | II.- TRANSACCIONES y CONCURRENCIA 17

P 2.1 TRANSACCION AISLADA

A. PRESENTAR LA EJECUCIÓN DE UNA TRANSACCION, para BANCA una

1. Identifique las posibles transacciones de su contexto.

TALLER UTILIZANDO EL MODELO BANCA:

En el modelo BANCA la transacción típica es la transferencia de una cuenta bancaria a

Linea DESCRIPCION SALDO inicial Monto SALDO final