Bases de datos

John Jairo Londoño

johnjairolondono@gmail.com

libros:

modelo seudomatematico para el diseño de BDR

Teoría de sistemas/enfoque para ingenieros

Contenido matemático

1/Definición rápida de los sistemas a partir de la construcción de contextos/modelos

2/normalización (refinamiento)de las BDR con base en el método de las dependencias funcionales
exclusivas DFE diseño relacional. diseño DDL diseño E/R

3/normalización (refinamiento)de las BDR con base en el método de las dependencias funcionales
no exclusivas DFNE diseño relacional, diseño DDL diseño E/R

4/normalización (refinamiento)de las BDR con base en el método de las dependencias funcionales
mixtas DFM(DFE/DFNE), diseño relacional. diseño DDL diseño E/R

5/ Diseño de las BD documentales (BD orientadas a objetos/BDNOSQL) /ingeniería con base en las
estructuras de los array

6/ Arquitectura de las bases de datos distribuidas/distribución y sincronización; fragmentación

horizontal, fragmentación vertical

7/ Datawarehouse como metodología para la inteligencia de negocios (arquitectura) tabla de

dimensiones, tablas de hechos, reportes(cubos), OLAP –Análisis program online

Compromisos en el curso:

1. Presencialidad
2. Puntualidad
3. Disciplina
4. Respeto
5. Cumplimiento de trabajos: (Documento de la materia)
5.1. Tematicas de la clase
5.2. Talleres de la clase en casa
5.3. Conclusiones de cada temática

Forma de calificación:

Cada corte (1,2,3):

50% Documento de la materia

30% Evaluación personal

20% Apreciativa

Desde la prespectiva de la ingeniería de software, la definición de un sistema se desliga

aparentemente de la notación universal que en comienzo lo expresa de la siguiente manera:

E P-S
---
--

Es esta notación la que antecede de manera impositiva al diseño de las BD y el diseño de software

Las metodologías con base en las cuales se define la “lógica de un sistema” corresponde a
lineamientos y recomendaciones, que deberán ser implementados mediante la creación de
formatos y adopción de modelos gtraficos o a través de los cuales se trata de obtener un resultado
que demuestre el inicio y fin del escenario y que se quiere comprender y entender para finalmente
construir el diseño de software y de BD esperadas.

No obstante lo anterior, en muchos de los casos, todo lo elaborado resulta sobredimensionado o

escaso, presentando incoherencia en lo que finalmente se quiere.

Si se retorna al concepto de la “notación universal” de un sistema, se puede simplificar el trabajo

de comprensión de un sistema, involucrando las siguientes preguntas, sobre cada uno de los
elementos del sistema (Estado-Proceso-Salida)

E----------------------------- P ------------------------- - S
--

Contexto monofuncional simple de un sistema:

Involucra sólo dos actores:

E m

Proveedores 1. Para quien

se va a
de semillas controlar

Factura de m. Qué se va
semillas acontrolar?
El contexto se construye de abajo hacia arriba

El contexto se lee de arriba hacia abajo:

- Hay muchos proveedores de semillas,

- Cada uno de los proveedores de semillas tienen muchas facturas

Cómo se comporta el proceso:

P m

Documentos 1.Para quien

se va a
de parcelas controlar

Cantidad de
m. Qué se va
semillas acontrolar?
sembradas

Cómo se comporta la salida:

S m

1.Para quien
Clientes se va a
controlar

Factura de la
m. Qué se va
venta de la acontrolar?
papa

Hay muchos clientes y cada uno de esos clientes tienen muchas facturas para la compra de papa

22-02-2019

Está claro que los negocios de sistemas, obedecen a contextos, que aparecen inmersos en la
entrada, proceso, salida. Los contextos entonces, pueden tener las siguientes arquitecturas.
1. Monofuncional simple:

2. Monofuncional extendida:

3. multifuncional simple
 4. multifuncional extendido:

Las diferentes arquitecturas de contextos podrán ser diferentes o iguales, dentro de la notación
universal del sistema, en sus etapas. Entrada – proceso - salida

Conclusiones…….

Capítulo 2:

1. Refinamiento /normalización del diseño de BDR/ Dependencia funcional exclusivo DFE

Aplicación al contexto monofuncional simple
La DF: es una regla de Amstrong – Algebra Relacional
El contexto: es una disfunción simple, ejemplo: clientes y factura
Atributos: Ley de la autodeterminación: Asignar atributos absolutos a cada contexto
Autodeterminación: Asignación de atributos a cada uno de los componentes o actores del sistema
bajo el principio de lo absoluto
FKD: Foreign key por defecto: atributos que desde la autodeterminación se pueden expresar como
códigos: EJEMPLO:
En factura: PK num_factura, FKD-sucursal, text fecha, text valor_total
En cliente: PK Cedula, text nombre,…

Normalización:

1FN: Debe tener: contexto y autodeterminación y tiene PK y FK

2FN: Debe tener: 1FN + PK, FKD + tipo de dependencia funcional DF

3FN: Debe tener: 1FN + 2FN + La construcción del diseño (nota 1), resolviendo la reflexividad
(Reflejar a través de las PK los atributos del actor antecesor en el actor sucesor)

(nota 1) Diseño: se saca de:

1. Modelo seudomatemático(Conjuntos)
2. Conjuntos
3. Modelo DDL(Lenguaje para definición de datos)
4. Modelo Entidad Relación

1. Diseño por el modelo seudomatemático:

 El primer conjunto (Clientes) se encuentra prácticamente normalizado, pues no tiene
ningún actor antecesor que lo obligue a través una DF

Clientes {PK cedula,tel, FK ciud}

Ciudades {PKE ciud, Nom_ciudad}(PK Emergente para solucionar la FKD)

Factura {PK num_fac, fecha,total, FKD sucursal, FKP cedula} (La PK del actor antecesor pasa
a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)

Sucursal { PKE sucursal, dir_sucursal,tel_sucursal}

2. Diseño modelo relacional:

- Se construye de izquierda a derecha iniciando en modo tabla con el conjunto del ultimo
actor del contexto (factura)
- Localizar a la derecha de las tablas de la izquierda, las tablas que tienen la PK de las FK de
las tablas de la izquierda
- Las relaciones se asignarán de derecha a izquierda, en sentido 1 a muchos (m -> 1)
- En lo sucesivo el diseño se leerá de derecha a izquierda
- El diseño ira al motor de derecha a izquierda
- Por ser un diseño no existirán relaciones que lleguen a las aristas superior, inferior,
posterior
Tarea hacer Script de:

FACTURA SUCURSALES

NumFact PK sucur PK

Fecha direc_sucur CIUDADES

Total tel_sucur ciud PK

sucur FKD nom_ciudad

CLIENTES
Cedula FKP
Cedula PK

nom

tel_cliente

ciud FKD
 3. Diseño modelo DDL: (MySQL)
Create database base1;
Use base1;

CREATE TABLE ciudades

(
ciud INT NOT NULL,
nom_ciud INT NOT NULL,
PRIMARY KEY (ciud)
);

CREATE TABLE clientes

(
cedu INT NOT NULL,
nom INT NOT NULL,
tel_cleinte INT NOT NULL,
ciud INT NOT NULL,
PRIMARY KEY (cedu),
FOREIGN KEY (ciud) REFERENCES ciudades(ciud)
);

CREATE TABLE sucursales

(
sucur INT NOT NULL,
 dir_sucur INT NOT NULL,
tel_sucur INT NOT NULL,
PRIMARY KEY (sucur)
);

CREATE TABLE factura

(
numfact INT NOT NULL,
fecha INT NOT NULL,
total INT NOT NULL,
sucur INT NOT NULL,
cedu INT NOT NULL,
PRIMARY KEY (numfact),
FOREIGN KEY (sucur) REFERENCES sucursales(sucur),
FOREIGN KEY (cedu) REFERENCES clientes(cedu)
);

4. Diseño modelo entidad relación:

Cumple la misma normatividad aplicada para la construcción del diseño por el modelo relacional
Diseño de bases de datos:

Refinamiento (normalización) con base DFE/contexto monofuncional/extendido

1. Construir diseño por modelo seudomatematico:

2. Constriur diseño relacional
3. Construir modelo DDL
4. Construir modelo E-R

1. Construir diseño por modelo seudomatematico:

Propietarios {PK cedula, nombre, telefono, FKD actividad}

Actividades {PKE actividad, nombre_actividad}

Inmuebles {PK matricula, dirección_inmueble, valor_inmueble, localidad FKD, cedula FKP}

(La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo
la DFE)

Localidades {PKE localidad, nombre}

Impuestos {PK num_recibo, fecha_pago, valor_pago, banco FKD, matricula FKP} (La PK del
actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)

Bancos {PKE banco, nombre_banco}

 2. Construir diseño relacional:

Impuestos Bancos Localidades Actividades

num_recibo PK banco PK localidad PK actividad PKE

fecha_pago nombre_banco nombre nombre_actividad

valor_pago

banco FKD
Inmuebles Propietarios
matricula FKP
matricula PK cedula PK
dirección_inmu nombre
eble
telefono
valor_inmueble
actividad FKD
localidad FKD

cedula FKP

3. Construir modelo DDL:

CREATE TABLE actividades
(
nombre_actividad INT NOT NULL,
actividad INT NOT NULL,
PRIMARY KEY (actividad)
);

CREATE TABLE bancos

(
banco INT NOT NULL,
nombre_banco INT NOT NULL,
PRIMARY KEY (banco)
);

CREATE TABLE localidades

(
localidad INT NOT NULL,
nombre INT NOT NULL,
PRIMARY KEY (localidad)
);

CREATE TABLE propietarios

(
cedula INT NOT NULL,
nombre INT NOT NULL,
telefono INT NOT NULL,
actividad INT NOT NULL,
PRIMARY KEY (cedula),
FOREIGN KEY (actividad) REFERENCES actividades(actividad)
);

CREATE TABLE inmuebles

(
 matricula INT NOT NULL,
dirección_inmmueble INT NOT NULL,
valor_inmueble INT NOT NULL,
cedula INT NOT NULL,
localidad INT NOT NULL,
PRIMARY KEY (matricula),
FOREIGN KEY (cedula) REFERENCES propietarios(cedula),
FOREIGN KEY (localidad) REFERENCES localidades(localidad)
);

CREATE TABLE impuestos

(
num_recibo INT NOT NULL,
fecha_pago INT NOT NULL,
valor_pago INT NOT NULL,
banco INT NOT NULL,
matricula INT NOT NULL,
PRIMARY KEY (num_recibo),
FOREIGN KEY (banco) REFERENCES bancos(banco),
FOREIGN KEY (matricula) REFERENCES inmuebles(matricula)
);

5. Diseño modelo entidad relación:

Cumple la misma normatividad aplicada para la construccion del diseño por el modelo relacional

Refinamiento (Normalizacion) con base en DFE/contexto multifuncional simple

1. Construir diseño por modelo seudomatematico:

Personas {PK cedula, nombre, telefono, FKD barrio}

Barrios {PKE barrio, nombre_barrio}

Matriculas_universidades {PK recibo_matricula, fecha_pago, valor_pago, universidad FKD,

cedula FKP} (La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor,
resolviendo la DFE)

Universidades {PKE universidad, nombre}

Citas_medicas {PK num_cita, fecha_cita, cedula FKP , tipo_cita FKD, eps FKD} (La PK del
actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)

Tipo_citas {PKE tipo_cita, nombre_cita}

Epss {PKE eps, nombre_eps}

2. Construir diseño relacional:

Matriculas_universidades Universidades
Recibo_matricula PK universidad PKE
Fecha_pago nombre
Valor_pago

Universidad FKD

cedula FKD

Personas Barrios
cedula PK barrio PK
Citas_medicas nombre nombre_barrio
Num_cita PK telefono
Fecha_cita barrio FKD
Cedula FKP

Tipo_cita FKD

eps FKD

Tipo_citas

Tipo_cita PKE

Nombre_cita

Epss

eps PKE

nombre_eps
 3. Construir modelo DDL:
Create database base3;
Use base3;

CREATE TABLE universidades

(
nombre INT NOT NULL,
univerisidad INT NOT NULL,
PRIMARY KEY (univerisidad)
);

CREATE TABLE tipo_citas

(
tipo_cita INT NOT NULL,
nombre_cita INT NOT NULL,
PRIMARY KEY (tipo_cita)
);

CREATE TABLE barrios

(
barrio INT NOT NULL,
 nombre_barrio INT NOT NULL,
PRIMARY KEY (barrio)
);

CREATE TABLE epss

(
eps INT NOT NULL,
nombre_eps INT NOT NULL,
PRIMARY KEY (eps)
);

CREATE TABLE personas

(
cedula INT NOT NULL,
nombre INT NOT NULL,
telefono INT NOT NULL,
barrio INT NOT NULL,
PRIMARY KEY (cedula),
FOREIGN KEY (barrio) REFERENCES barrios(barrio)
);

CREATE TABLE matriculas_universitarias

(
recibo_matricula INT NOT NULL,
fecha_pago INT NOT NULL,
valor_pago INT NOT NULL,
univerisidad INT NOT NULL,
cedula INT NOT NULL,
PRIMARY KEY (recibo_matricula),
FOREIGN KEY (univerisidad) REFERENCES universidades(univerisidad),
FOREIGN KEY (cedula) REFERENCES personas(cedula)
);
CREATE TABLE citas_medicas
(
num_cita INT NOT NULL,
fecha_cita INT NOT NULL,
tipo_cita INT NOT NULL,
cedula INT NOT NULL,
eps INT NOT NULL,
PRIMARY KEY (num_cita),
FOREIGN KEY (tipo_cita) REFERENCES tipo_citas(tipo_cita),
FOREIGN KEY (cedula) REFERENCES personas(cedula),
FOREIGN KEY (eps) REFERENCES epss(eps)
);
Diseño de bases de datos:

Refinamiento (normalización) con base DFE/contexto multifuncional/extendido

1. Construir diseño por modelo seudomatematico:

Propietarios {PK cedula, nombre, telefono, FKD actividad}

Actividades {PKE actividad, nombre_actividad}

Inmuebles {PK matricula, dirección_inmmueble, valor_inmueble, localidad FKD, cedula

FKP} (La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor,
resolviendo la DFE)

Localidades {PKE localidad, nombre_localidad}

Vehiculos {PK placa, modelo,color, cedula FKP , marca FKD } (La PK del actor antecesor pasa
a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)

Marcas {PKE marca, nombre_marca}

 Impuestos {PK num_recibo_imp, fecha_pago_imp,valor_pago_imp, matricula FKP , banco
FKD } (La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor,
resolviendo la DFE)

Bancos {PKE banco, nombre_banco}

Infracciones {PK num_recibo_inf, fecha_pago_inf,valor_pago_inf, placa FKP , tipo_inf FKD}

(La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo
la DFE)

Infracciones {PKE tipo_inf, nombre_inf}

2. Construir diseño relacional:

3. Construir modelo DDL:

Create database base4;
Use base4;

CREATE TABLE actividades

(
nombre_actividad INT NOT NULL,
actividad INT NOT NULL,
PRIMARY KEY (actividad)
);
CREATE TABLE bancos
(
banco INT NOT NULL,
nombre_banco INT NOT NULL,
PRIMARY KEY (banco)
);

CREATE TABLE localidades

(
localidad INT NOT NULL,
nombre_localidad INT NOT NULL,
PRIMARY KEY (localidad)
);

CREATE TABLE marcas

(
marca INT NOT NULL,
nombre_marca INT NOT NULL,
PRIMARY KEY (marca)
);

CREATE TABLE tipo_infracciones

(
tipo_inf INT NOT NULL,
nombre_inf INT NOT NULL,
PRIMARY KEY (tipo_inf)
);

CREATE TABLE propietarios

(
cedula INT NOT NULL,
nombre INT NOT NULL,
 telefono INT NOT NULL,
actividad INT NOT NULL,
PRIMARY KEY (cedula),
FOREIGN KEY (actividad) REFERENCES actividades(actividad)
);

CREATE TABLE inmuebles

(
matricula INT NOT NULL,
dirección_inmmueble INT NOT NULL,
valor_inmueble INT NOT NULL,
cedula INT NOT NULL,
localidad INT NOT NULL,
PRIMARY KEY (matricula),
FOREIGN KEY (cedula) REFERENCES propietarios(cedula),
FOREIGN KEY (localidad) REFERENCES localidades(localidad)
);

CREATE TABLE vehiculos

(
placa INT NOT NULL,
modelo INT NOT NULL,
color INT NOT NULL,
cedula INT NOT NULL,
marca INT NOT NULL,
PRIMARY KEY (placa),
FOREIGN KEY (cedula) REFERENCES propietarios(cedula),
FOREIGN KEY (marca) REFERENCES marcas(marca)
);

CREATE TABLE infracciones

(
num_recibo_inf INT NOT NULL,
 fecha_pago_inf INT NOT NULL,
valor_pago_inf INT NOT NULL,
placa INT NOT NULL,
tipo_inf INT NOT NULL,
PRIMARY KEY (num_recibo_inf),
FOREIGN KEY (placa) REFERENCES vehiculos(placa),
FOREIGN KEY (tipo_inf) REFERENCES tipo_infracciones(tipo_inf)
);

CREATE TABLE impuestos

(
num_recibo_imp INT NOT NULL,
fecha_pago_imp INT NOT NULL,
valor_pago_imp INT NOT NULL,
banco INT NOT NULL,
matricula INT NOT NULL,
PRIMARY KEY (num_recibo_imp),
FOREIGN KEY (banco) REFERENCES bancos(banco),
FOREIGN KEY (matricula) REFERENCES inmuebles(matricula)
);
 4. Construir E-R:

Diseño de bases de datos

DFNE (Dependencias funcionales NO exclusiva) /Contexto monofuncional simple:

Se dice que existe una DFNE entre el componente sucesor y el antecesor, cuando existiendo una
relación convencional (R) de uno(1) a muchos(m) entre el componente anteceso y sucesor, la
relación inversa entre el sucesor y antecesor es también de (1) uno a muchos (m)

La relación Inversa (DFNE) de uno(1) a muchos(m), siempre dará al solucionarse, una “llave
compuesta”, en donde cada unidad de la llave será a su vez una FKP(FK por Proceso); la pk del
componente antecesor, se refleja en el componente sucesor, “sumándose” a la pk

Existen muchas facturas

Cada una de las facturas tiene muchas (m) códigos de artículos

Cada uno de los muchos artículos de una factura en cuestión, también puede estar en muchas
otras facturas

1. Diseño modelo seudomatematico (conjuntos):

Facturas [ nofact PK, fechafac,valtfac, cedcli FKD]

Clientes [cedcli PKE, nomcli, telcli]
Fact_art[(nofact(FKP) + codart(FKP))PKE, cantart]
● cantart : atributos que dependen estrictamente de las dos partes de la llave REGLA
● nofact(FKP) + codart(FKP): cada una por separado adquiere la propiedad de FKP
● (nofact(FKP) + codart(FKP))PK: las dos FKP unidas, constituyen una PKE
● La tabla Fact_art resuelve el ultimo actor del contexto

Articulos [codart PK, nomart, valtart, bodega FKD]

● nomart, valtart, bodega FKD: atributos que dependen estrictamente de la segunda

parte de la llave REGLA2

bodegas [bodega PKE, dirbod, telbod]

 2. Diseño relacional:

facturas clientes

nofact PK cedcli PKE Llave compartida

factart fechafac nomcli
PKE: nofac FKP valtfac telcli
codart FKP
cedcli FKD
cantart
articulos bodegas
codart PK bodega PKE
nomart dirbod
valtart telbod
bodega FKD

3. Diseño modelo DDL

CREATE TABLE bodegas
(
bodega INT NOT NULL,
telbod VARCHAR(20) NOT NULL,
dirbod VARCHAR(20) NOT NULL,
PRIMARY KEY (bodega)
);

CREATE TABLE clientes

(
cedcli INT NOT NULL,
nomcli VARCHAR(20) NOT NULL,
telcli VARCHAR(20) NOT NULL,
PRIMARY KEY (cedcli)
);

CREATE TABLE facturas

(
fechafac VARCHAR(20) NOT NULL,
nofact INT NOT NULL,
valtfac INT NOT NULL,
cedcli INT NOT NULL,
PRIMARY KEY (nofact),
FOREIGN KEY (cedcli) REFERENCES clientes(cedcli)
);

CREATE TABLE articulos

(
codart INT NOT NULL,
nomart INT NOT NULL,
valtart INT NOT NULL,
bodega INT NOT NULL,
PRIMARY KEY (codart),
 FOREIGN KEY (bodega) REFERENCES bodegas(bodega)
);

CREATE TABLE factart

(
cantart INT NOT NULL,
nofact INT NOT NULL,
codart INT NOT NULL,
PRIMARY KEY (nofact, codart),
FOREIGN KEY (nofact) REFERENCES facturas(nofact),
FOREIGN KEY (codart) REFERENCES articulos(codart)
);
4. Diseño modelo entidad relacion(MER)
Taller de aplicación:

Asigne por autodeterminación, 4 atributos a cada uno de los actores de cada contexto. En cada
uno de los actores se define la PK y unas FKD
Resuelva la DFE Y DFNE de cada uno de los contextos y construya los diseños que correspondan a
cada uno de los modelos de BD.

Operaciones de vuelos en un aeropuerto

1. Construir diseño por modelo seudomatematico:

aerolineas {PK cod_aerolinea, nom_aerolinea, tel_aerolinea, flota, FKD pais}

paises {PKE pais, nombre_pais}

Vuelos {PK cod_vuelo, fecha_vuelo, valor_vuelo, placa_avion FKD, cod_aeropto FKD,

cod_aerolinea FKP} (La PK del actor antecesor pasa a ser FKP o FK por proceso en el actor
sucesor, resolviendo la DFE)

aviones {PKE placa_avion, marca, modelo}

aeropuerto {PKE cod_aeropto, nombre_aeropto}

2. Diseño modelo relacional:

 3. Construir modelo DDL:
Create database base4;
Use base4;

CREATE TABLE paises

(
nombre_pais VARCHAR(30) NOT NULL,
pais INT NOT NULL,
PRIMARY KEY (pais)
);

CREATE TABLE aviones

(
placa_avion INT NOT NULL,
marca VARCHAR(30) NOT NULL,
modelo INT NOT NULL,
PRIMARY KEY (placa_avion)
);

CREATE TABLE aeropuertos

(
cod_aeropto INT NOT NULL,
nombre_aeropto VARCHAR(30) NOT NULL,
 PRIMARY KEY (cod_aeropto)
);

CREATE TABLE aerolineas

(
cod_aerlinea INT NOT NULL,
nom_aerolinea VARCHAR(30) NOT NULL,
tel_aerolinea INT NOT NULL,
flota INT NOT NULL,
pais INT NOT NULL,
PRIMARY KEY (cod_aerlinea),
FOREIGN KEY (pais) REFERENCES paises(pais)
);

CREATE TABLE vuelos

(
cod_vuelo INT NOT NULL,
fecha_vuelo VARCHAR(30) NOT NULL,
valor_vuelo INT NOT NULL,
cod_aerlinea INT NOT NULL,
placa_avion INT NOT NULL,
cod_aeropto INT NOT NULL,
PRIMARY KEY (cod_vuelo),
FOREIGN KEY (cod_aerlinea) REFERENCES aerolineas(cod_aerlinea),
FOREIGN KEY (placa_avion) REFERENCES aviones(placa_avion),
FOREIGN KEY (cod_aeropto) REFERENCES aeropuertos(cod_aeropto)
);
 4. Diseño moldelo E-R

Operaciones de una constructora

1. Construir diseño por modelo seudomatematico:

Contratos_civiles {PK cod_contrato, fecha_contrato, val_contrato, FKD ced_cliente}

clientes {PKE ced_cliente, nom_cliente, tel_cliente}

contratos_tipos { (cod_contrato(FKP) + cod_obra(FKP))PKE, cantidad_obras}

 tipos_obras {PK cod_obra, nom_obra, val_obra, clasificacion FKD} (La PK del actor
antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)
(carreteras, pluviales, pistas peatonales )

clasificaciones {PKE clasificacion, nom_clasificacion}(adoqinado, asfaltico, enchape, etc…)

2. Diseño relacional:

3. Diseño modelo DDL:

Create database base5;

Use base5;

CREATE TABLE calsificaciones

(
clasificacion INT NOT NULL,
nom_clasificacion VARCHAR(30) NOT NULL,
PRIMARY KEY (clasificacion)
);

CREATE TABLE clientes

(
ced_cliente INT NOT NULL,
nom_cliente VARCHAR(30) NOT NULL,
tel_cliente INT NOT NULL,
 PRIMARY KEY (ced_cliente)
);

CREATE TABLE contratos_civiles

(
fecha_contrato VARCHAR(30) NOT NULL,
cod_contrato INT NOT NULL,
val_contrato INT NOT NULL,
ced_cliente INT NOT NULL,
PRIMARY KEY (cod_contrato),
FOREIGN KEY (ced_cliente) REFERENCES clientes(ced_cliente)
);

CREATE TABLE tipos_obras

(
cod_obra INT NOT NULL,
nom_obra VARCHAR(30) NOT NULL,
val_obra INT NOT NULL,
clasificacion INT NOT NULL,
PRIMARY KEY (cod_obra),
FOREIGN KEY (clasificacion) REFERENCES calsificaciones(clasificacion)
);

CREATE TABLE contratos_tipos

(
cantidad_obras INT NOT NULL,
cod_contrato INT NOT NULL,
cod_obra INT NOT NULL,
PRIMARY KEY (cod_contrato, cod_obra),
FOREIGN KEY (cod_contrato) REFERENCES contratos_civiles(cod_contrato),
FOREIGN KEY (cod_obra) REFERENCES tipos_obras(cod_obra)
);
 4. Diseño modelo E-R:

Conclusiones:

- La clave relevante para realizar el modelo seudomatematico DFE está en aplicar “(La PK del
actor antecesor pasa a ser FKP o FK por proceso en el actor sucesor, ya que esto resuelve
en totalidad la DFE)”

- La DFE se da al tener relaciones entre entidades que requieran que un grupo transaccional
dependa directamente de un actor

- La clave relevante para realizar el modelo seudomatematico DFNE está en aplicar la “llave
compuesta”, en donde cada unidad de la llave será a su vez una FKP(FK por Proceso); la pk
del componente antecesor, se refleja en el componente sucesor, “sumándose” a la pk

- La DFNE se da cuando un grupo transaccional depende del actor directamente y ese actor
también tiene una dependencia con el grupo transaccional, se resuelven siempre con la
llave compuesta
Normalización DFNE/Contexto extendido

Controlar las atenciones de los clientes y a su vez controlar lo clientes de los planes de viajes de
una agencia de turismo. Supongase que esta abstracción del contexto, se extrajeron de los
informes requeridos por el cliente, los atributos que despues fueron asignados por
autodeterminacion

1. Construir diseño por modelo seudomatematico:

planesviajes {PK id_plan, fechapl, FKD destipl, FKD aerolpl}

aerolineas {PKE aerol, nom_aerol }

destinos{PKE destipl, nom_aerol }

plan_pasajeros { (id_plan(FKP) + cedu(FKP))PKE, silla}(3FN)

pasajeros {PK cedu, nom, dir,tel, profesion FKD} (La PK del actor antecesor pasa a ser FKP
o FK por proceso en el actor sucesor, resolviendo la DFE)(carreteras, pluviales, pistas
peatonales )

profesiones {PKE profesion, nom_profesion}(adoqinado, asfaltico, enchape, etc…)

atenciones {PK cod_aten, nom_aten, valor_aten, responsable_aten FKD} (La PK del actor
antecesor pasa a ser FKP o FK por proceso en el actor sucesor, resolviendo la DFE)(las
atenciones pueden ser desayunos, almuerzos )

plan_pasajeros_atenciones { ((id_plan + cedu)(FKP)+ cod_aten(FKP) )PKE, cant_aten}

responsables {PKE responsable_aten, nom_responsable,tel_responsable}(que persona

reponde por esa atencion)

2. Diseño relacional:

3. Diseño modelo DDL:

Create database base5;

Use base5;

CREATE TABLE profesiones

(
profesion INT NOT NULL,
nom_profesion VARCHAR(30) NOT NULL,
PRIMARY KEY (profesion)
);

CREATE TABLE aerolineas

(
aerol INT NOT NULL,
nom_aerol VARCHAR(30) NOT NULL,
PRIMARY KEY (aerol)
);

CREATE TABLE destinos

(
nom_dest VARCHAR(30) NOT NULL,
destipl INT NOT NULL,
PRIMARY KEY (destipl)
);

CREATE TABLE reponsables

(
responsable_aten INT NOT NULL,
nom_responsable VARCHAR(30) NOT NULL,
tel_responsable INT NOT NULL,
PRIMARY KEY (responsable_aten)
);

CREATE TABLE planesviajes

(
 fechaplan VARCHAR(30) NOT NULL,
id_plan INT NOT NULL,
aerol INT NOT NULL,
destipl INT NOT NULL,
PRIMARY KEY (id_plan),
FOREIGN KEY (aerol) REFERENCES aerolineas(aerol),
FOREIGN KEY (destipl) REFERENCES destinos(destipl)
);

CREATE TABLE pasajeros

(
cedu INT NOT NULL,
nom VARCHAR(30) NOT NULL,
dir VARCHAR(30) NOT NULL,
tel INT NOT NULL,
profesion INT NOT NULL,
PRIMARY KEY (cedu),
FOREIGN KEY (profesion) REFERENCES profesiones(profesion)
);

CREATE TABLE plan_pasajeros

(
silla INT NOT NULL,
id_plan INT NOT NULL,
cedu INT NOT NULL,
PRIMARY KEY (id_plan, cedu),
FOREIGN KEY (id_plan) REFERENCES planesviajes(id_plan),
FOREIGN KEY (cedu) REFERENCES pasajeros(cedu)
);

CREATE TABLE atenciones

(
cod_aten INT NOT NULL,
 nom_aten VARCHAR(30) NOT NULL,
valor_aten INT NOT NULL,
responsable_aten INT NOT NULL,
PRIMARY KEY (cod_aten),
FOREIGN KEY (responsable_aten) REFERENCES reponsables(responsable_aten)
);

CREATE TABLE plan_pasajeros_atenciones

(
cant_aten INT NOT NULL,
cod_aten INT NOT NULL,
id_plan INT NOT NULL,
cedu INT NOT NULL,
PRIMARY KEY (id_plan, cedu, cod_aten),
FOREIGN KEY (cod_aten) REFERENCES atenciones(cod_aten),
FOREIGN KEY (id_plan, cedu) REFERENCES plan_pasajeros(id_plan, cedu)
);

4.
5. Diseño modelo E-R:
Normalización dependencias funcionales mixtas DFE-DFNE:
Contexto:

Controlar las materias matriculadas por los estudiantes de una universidad

Normalización dependencias funcionales mixtas DFNE-DFE:

1. Construir diseño por modelo seudomatematico:

 estudiantes {PK idest, nomest, direst, FKD localidad }

localidades{PKE localidad, nom_localidad }

matriculas {PK nrorecibo, fecharec, valorrecib, carrera FKD, idest FKP}

carreras {PKE carrera, nom_carrera}

materias {PK codmat, nommat, valormat, areaconocim FKD}

matriculas_materias { ((nrorecibo FKP) + codmat (FKP))PKE, nota}

areas_conocimientos {PKE areaconocim , nomarea}

2. Construir diseño por modelo seudomatematico:

planesviajes {PK idplan, fechaplan, FKD destipl , FKD aeropl }

aerolineas{PKE aeropl, nom_aerolinea }

destinos{PKE destipl, nom_destino }

planesviajes_pasajeros { ((idplan FKP) + idpasajero (FKP))PKE, silla}

pasajeros {PK idpasajero, nompas, telpas, profes FKD

profesiones {PKE profes, nom_profesion}

facturasconsumos {PK nrofact, fechafact, valorfact, codconsu FKD, ((idplan) + idpasajero)

FKP}

consumos {PKE codconsu, nomconsumo}

Facturasconsumos Consumos Planesviajes aerolineas

nrofact PK codconsu PK idplan PK aeropl PK

fechafact valorfact nomconsumo fechaplan nom_aerolinea

codconsu FKD aeropl FKD

destinos
(idplan + destipl FKD
destipl PK
idpasajero) FKP planesviajes_pasajer
nom_destino
os
pasajeros
(idplan FKP
idpasajero PK Profesiones
idpasajero FKP) PK
nompas profes PK
silla
telpas nom_profesion
profes FKD
 1. Diseño modelo DDL:

Create database base5;

Use base5;

CREATE TABLE profesiones

(
profesion INT NOT NULL,
nom_profesion VARCHAR(30) NOT NULL,
PRIMARY KEY (profesion)
);

CREATE TABLE aerolineas

(
aerol INT NOT NULL,
nom_aerol VARCHAR(30) NOT NULL,
PRIMARY KEY (aerol)
);

CREATE TABLE destinos

(
nom_dest VARCHAR(30) NOT NULL,
destipl INT NOT NULL,
PRIMARY KEY (destipl)
);

CREATE TABLE consumos

(
nomconsu VARCHAR(30) NOT NULL,
codconsu INT NOT NULL,

PRIMARY KEY (codconsu)

);
CREATE TABLE planesviajes
(
fechaplan VARCHAR(30) NOT NULL,
id_plan INT NOT NULL,
aerol INT NOT NULL,
destipl INT NOT NULL,
PRIMARY KEY (id_plan),
FOREIGN KEY (aerol) REFERENCES aerolineas(aerol),
FOREIGN KEY (destipl) REFERENCES destinos(destipl)
);

CREATE TABLE pasajeros

(
cedu INT NOT NULL,
nom VARCHAR(30) NOT NULL,
dir VARCHAR(30) NOT NULL,
tel INT NOT NULL,
profesion INT NOT NULL,
PRIMARY KEY (cedu),
FOREIGN KEY (profesion) REFERENCES profesiones(profesion)
);
CREATE TABLE planesviajes_pasajeros
(

idplan INT NOT NULL,

idpasajeros INT NOT NULL,

silla INT NOT NULL,

PRIMARY KEY (id_plan,idpasajero),

FOREIGN KEY (idplan) REFERENCES planesviajes(idplan),

FOREIGN KEY (idpasajeros) REFERENCES pasajeros(idpasajeros)

);

CREATE TABLE facturaconsumos

(
silla INT NOT NULL,

id_plan INT NOT NULL,

cedu INT NOT NULL,

PRIMARY KEY (nrofact),

FOREIGN KEY (id_plan,idpasajero) REFERENCES

planesviajes_pasajeros(id_plan,idpasajero),

FOREIGN KEY (codconsu) REFERENCES consumos(codconsu)

);

CREATE TABLE matriculas_materias

(
nrorecibo INT NOT NULL,
codmateria INT NOT NULL,
nota INT NOT NULL,

PRIMARY KEY (nrorecibo,),

FOREIGN KEY (nrorecibo) REFERENCES matriculas (nrorecibo),

FOREIGN KEY (codmateria) REFERENCES materias (codmateria),

 Segundo corte:

Bases de datos documentales

Tambien llamadas BD orientadas a objetos (BDOO) o BD NoSQL (Not only SQL), son
repositorios para el almacenamiento de la información, dispuestas fisiacamente
en arreglos (arrays o vectores) no en tablas que reciben los datos como
“cadenas”, utilizando un “separador” de concatenación como la “coma:,”, mediante
la cual permite abstraer información cuando se quiera.

Esa característica de “concatenación” es la que defina su condición de

“documento”, la cual marca la diferencia con las denominadas tablas de las BD
relacionales.

La utilización de las BD Dosumentales se sucede, cuando el ejercicio

“transaccional” no es lo más importante, significa entonces que los que se
quiere guardarno será “modificado”, tampoco utilizado en operaciones
aritméticas, aunque de ser requerido es probable, pero a un costo muy elevado de
programación.

Con base en los anterios las BD Documentales son “informativas” y por lo

general, cuando se hace referencia a una información ya existente, se crea un
documento o un “string” mejorándola, pero manteniendo su “string” antecedente.

Un escenario de abstracción que compara las BD Documentales y las BD

Relacionales es la siguiente:

BD Documental(No normalizado porque hay una redundancia, porque no hay codigos)

El primer valor no es una primary key)

200,pedro,docente,8000000
400,carlos,medico,7000000

100,maria,abogado,5000000
300,Ruth,docente,8000000

200,jose,medico,9000000
Permite repetir el 200 con otros datos, salvo que por programación se impidiera

BD Relacional(Normalizado)

Cod PK nom cargo

100 Maria 2
200 Pedro 1

300 ruth 1
400 carlos 3

cargo Nom_cargo sueldo

1 docente 80000
00
2 medico 70000
00

3 abogado 50000
00

No obstante lo anterior, el “Negocio del sistema” concebido de un “contexto” aplicaría para BD

Relacionales o BD Documentales, dependiendo de lo que se quiera, o involucrarlo dentro de las
dos arquitecturas de la BD, por razones de conveniencia inherentes a ejercicios específicos:

- Escenario:
Padre hijos

200, carlos,3430000,50, octubre,62000,20, noviembre,13000,30, marzo,88000

300, ruth,2440000,7, marzo,55000,80, agosto,43000,30, junio,71000

100, pedro,2494430,25, enero,4000,12, diciembre,6000,40, febrero,56000

-Motor BD Documentales

Instrucciones básicas: mongo db

Insert, find, update, remove

200, carlos,3430000,50, octubre,62000,20, noviembre,13000,30, marzo,88000

300, carlos,2440000,7, marzo,55000,80, agosto,43000,30, junio,71000

100, pedro,2494430,25, enero,4000,12, diciembre,6000,40, febrero,56000

Insertar 50 y 20

Luego 30
db.inventory.insertOne(
 { item: 200, name: "carlos", fact: [{ numfact: 50, fechafact:
"octubre", valfact: 62000 }, { numfact: 20, fechafact: "noviembre",
valfact: 13000 }] }
)
db.inventory.insertOne(
{ item: 200, name: "carlos", fact: [{ numfact: 30, fechafact:
"marzo", valfact: 62000 }] }
)

Esta entendido que las BDD, estructuran su aspecto fisico a manera de “jerarquias” con
repositorios que son “vectores o matrices”, tambien llamadas BD orientadas a objetos. La
“multifuncionalidad” del “contexto del sistema” es equiparable a la arquitectura de “PadreHijos”,
en dodnde los hijos no se verian por logica de negocio sino por inteligencias de negocio
De lo anterior la parte esquemática es la siguiente:

- Lenguaje de programación SQL(QuerySystemOnLine)

Cuando se habla de la programación a instancias del motor, se está haciendo referencia a
dos instancias de trabajo, la primera muy básica que permite el acceso a cualquier persona
que de alguna manera se relaciona con las base de datos relacionales y la segunda
deinitivamente para ingenieros, pues trata de la construcción de solucones con estructuras
de programación “bajo nivel”.
La programación para ingenieros hace referencia a la construcción de los Procedimientos
Almacenados PA y se hace más interesante cuando se involucra el “objeto cursor” que se
comporta como un vector y se utiliza para materializar los datos colectados a través de una
sentecia select

Ced Nom Ciudad Cedb Nomb Ciudadb

100 Pedro 2
200 Ruth 1
300 Maria 2
400 Juan 2
500 Carlos 1
Clientes(crearla e insertar datos) backup(crearla sin datos)

create table clientes(ced integer, nom varchar(100),ciu integer);

create table backup(cedb integer, nomb varchar(100),ciub integer);
insert into clientes(ced, nom,ciu) values(100, "pedro",2);
insert into clientes(ced, nom,ciu) values(200, "ruth",1);
insert into clientes(ced, nom,ciu) values(300, "maria",2);
insert into clientes(ced, nom,ciu) values(400, "juan",2);
insert into clientes(ced, nom,ciu) values(500, "carlos",1);

insert into backup select * from clientes;

delete from backup;
select * from backup;

delimiter //
create procedure pacur1()
begin

DECLARE ced1 INTEGER default 0;

DECLARE ciu1 INTEGER default 0; -- database name
DECLARE nom1 varchar(255) DEFAULT ""; -- path for backup files
DECLARE fin INTEGER default 0;-- filename for backup
DECLARE cursor1 CURSOR FOR SELECT * FROM clientes;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET fin = 1;

OPEN cursor1;
REPEAT
FETCH cursor1 into ced1,nom1,ciu1;
if not fin then
insert into backup(cedb,nomb,ciub) values (ced1,nom1,ciu1);
end if;
until fin=1 end repeat;
CLOSE cursor1;
end;
//
delimiter ;
call pacur1();
select * from backup;

insertar paso valor por parámetro, diciendo cuáles valores son los que quiero insertar:

create table clientes(ced integer, nom varchar(100),ciu integer);

create table backup(cedb integer, nomb varchar(100),ciub integer);

insert into clientes(ced, nom,ciu) values(100, "pedro",2);

insert into clientes(ced, nom,ciu) values(200, "ruth",1);
insert into clientes(ced, nom,ciu) values(300, "maria",2);
insert into clientes(ced, nom,ciu) values(400, "juan",2);
insert into clientes(ced, nom,ciu) values(500, "carlos",1);

insert into backup select * from clientes where ciu =1;

 delete from backup;
select * from backup;

delimiter //
create procedure pacur2(in ciuaux int)
begin

DECLARE ced1 INTEGER default 0;

DECLARE ciu1 INTEGER default 0; -- database name
DECLARE nom1 varchar(255) DEFAULT ""; -- path for backup files
DECLARE fin INTEGER default 0;-- filename for backup
DECLARE cursor1 CURSOR FOR SELECT * FROM clientes;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET fin = 1;

OPEN cursor1;
REPEAT
FETCH cursor1 into ced1,nom1,ciu1;
if not fin then
if ciu1 =ciuaux then
insert into backup(cedb,nomb,ciub) values (ced1,nom1,ciu1);
end if;
end if;
until fin=1 end repeat;
CLOSE cursor1;
end;
//
delimiter ;
call pacur2(1);
select * from backup;

Procedimiento almacenado con cursores

cedu nom ciu

100 Pedro 2
200 Carol 3
300 Luisa 1
300 Juan 2
400 ruth 1

ciu Nom_ciu
1 Medellin
2 Cali
3 Yopal

Resultado
cedu nom Ciudad Nom_ciu
100 Pedro 2 Cali
200 Carol 3 Yopal
300 Luisa 1 Medellin
300 Juan 2 Cali
400 ruth 1 Medellin

Forma 1:

Select clientes.cedu, clientes.nom,clientes.ciu,clientes.nom_ciu from clientes inner join ciudades

on clientes.ciu = ciudades.ciu;

Forma 2:

create table clientes(ced integer, nom varchar(100),ciu integer);

insert into clientes(ced, nom,ciu) values(100, "pedro",2);
insert into clientes(ced, nom,ciu) values(200, "carol",3);
insert into clientes(ced, nom,ciu) values(300, "luisa",1);
insert into clientes(ced, nom,ciu) values(400, "juan",2);
insert into clientes(ced, nom,ciu) values(500, "ruth",1);

create table ciudades(ciu integer, nom_ciu varchar(100));

insert into ciudades(ciu, nom_ciu) values(1, "medellin");
insert into ciudades(ciu, nom_ciu) values(2, "cali");
insert into ciudades(ciu, nom_ciu) values(3, "yopal");

-- Select clientes.ced, clientes.nom,clientes.ciu,ciudades.nom_ciu from clientes inner join ciudades

on clientes.ciu = ciudades.ciu;

delimiter //
create procedure proinner()
begin

DECLARE ced1 INTEGER default 0;

DECLARE ciu1 INTEGER default 0; -- database name
DECLARE nom1 varchar(255) DEFAULT ""; -- path for backup files
DECLARE nom_ciu1 varchar(255) DEFAULT "";
DECLARE fin INTEGER default 0;-- filename for backup
DECLARE cursor1 CURSOR FOR SELECT * FROM clientes;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET fin = 1;

OPEN cursor1;
REPEAT
FETCH cursor1 into ced1,nom1,ciu1;
 if not fin then
select nom_ciu into nom_ciu1 from ciudades where ciu=ciu1;
select ced1,nom1,ciu1,nom_ciu1;
end if;

until fin=1 end repeat;

CLOSE cursor1;
end;
//
delimiter ;
call proinner();

Concepto de contadores con rompimiento

Forma 1

Select count (*),ciu from clientes group by ciu,order by ciu;

1 2
2 2
3 1

Forma 2

create table clientes(ced integer, nom varchar(100),ciu integer);

insert into clientes(ced, nom,ciu) values(100, "pedro",2);
insert into clientes(ced, nom,ciu) values(200, "carol",3);
insert into clientes(ced, nom,ciu) values(300, "luisa",1);
insert into clientes(ced, nom,ciu) values(400, "juan",2);
insert into clientes(ced, nom,ciu) values(500, "ruth",1);

create table ciudades(ciu integer, nom_ciu varchar(100));

insert into ciudades(ciu, nom_ciu) values(1, "medellin");
insert into ciudades(ciu, nom_ciu) values(2, "cali");
insert into ciudades(ciu, nom_ciu) values(3, "yopal");

delimiter //
create procedure procontar()
begin

DECLARE ciu1 INTEGER default 0;

DECLARE contar INTEGER default 0;
DECLARE ciuaux INTEGER default 0; -- database name
DECLARE fin INTEGER default 0;-- filename for backup
DECLARE cursor1 CURSOR FOR SELECT ciu FROM clientes order by ciu;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET fin = 1;

OPEN cursor1;
FETCH cursor1 into ciu1;
set ciuaux = ciu1;
REPEAT
if ciuaux = ciu1 then
set contar = contar + 1;
else
select ciuaux,contar;
set ciuaux = ciu1;
set contar = 0;
set contar = contar+1;
end if;
fetch cursor1 into ciu1;

until fin=1 end repeat;

select ciuaux,contar;
CLOSE cursor1;
end;
//
delimiter ;
call procontar();

Bases de datos distribuidas

Las bd distribuidas no representan como tal una tecnologia, pero si tienen la caracteristica de una
metodologia o forma de trabajo que permite distribuir las transacciones que se suceden en sitios
foráneos , o sus sitios de origen.
Con base en lo anterior, lo que se distribuye es la “transacción”, para lo cual se deberá definir un
escenario con unos criterios de trabajo que hacen relación con:

- Identificar los sitios remotos que harán parte del escenario de las BDD.
- Garantizar un mismo diseño de BD en cada una de los sitios o puntos remotos
- Asegurar la presencia de un “Data Center” que garantice el éxito de las transacciones
- Garantizar la existencia de un software que esta del lado de la organización o del lado del
Data Center, encargado de ejecutar la sincronización de las transacciones (distribución de
transacciones) y de la seguridad de los mismos, mediante las opreaciones de
fragmentación horizontal FH y fragmentación vertical FV.
La implementación de las BDD es adapata por organizaciones relacionadas por lo general con el
uso de los saldos disponibles en tiempo real, de movimientos abundantes y redundantes que
necesitan de una respuesta inmediata para su ejecución.
En la actualidad son los data center los referentes capaces de adquirir y ofertar tecnologías fuertes
en capacidad y velocidad y están permanentemente dispuestas en cambiarlos o mejorarlas
Contexto negocio:
Clientes, productos, transacciones (FKD consignacion, FKD retiro)
TTF va a la tabla de transacciones

Crear bd bogota bd medellin vacias(transacciones),TTF bogota y medellin, auditoria.

Alimentamos TTF de bogota y medellin
Luego hacemos un select para ver si hay información en las TTF, si hay datos los envía de TTF
medellin a BD Medellin, envía de TTF bogota a BD bogota, y los envía a la BD auditoria, vacia las
TTF. Y toda la info esta en las BD:

create table ttf_bogota(cuenta integer,valor integer, tipo_transaccion varchar(100),fecha

varchar(100));
create table ttf_medellin(cuenta integer,valor integer, tipo_transaccion varchar(100),fecha
varchar(100));
create table bd_bogota(cuentab integer,valorb integer, tipo_transaccionb varchar(100),fechab
varchar(100));
create table bd_medellin(cuentam integer,valorm integer, tipo_transaccionm varchar(100),fecham
varchar(100));
create table bd_auditoria(tipo_transacciona varchar(100),fechaa varchar(100));

create table backup(cedb integer, nomb varchar(100),ciub integer);

insert into ttf_bogota(cuenta,valor, tipo_transaccion,fecha) values(1029302910,10000,

"consignacion","23/11/2019 08:00");
insert into ttf_bogota(cuenta,valor, tipo_transaccion,fecha) values(1043302910,300000,
"retiro","25/11/2019 12:00");
insert into ttf_medellin(cuenta,valor, tipo_transaccion,fecha) values(1041302910,450000,
"consignacion","23/11/2019 03:00");
insert into ttf_medellin(cuenta,valor, tipo_transaccion,fecha) values(1048302910,90000,
"retiro","25/11/2019 05:00");
insert into ttf_medellin(cuenta,valor, tipo_transaccion,fecha) values(1083302910,400000,
"consignacion","25/11/2019 05:50");

-- insert into bd_bogota select * from ttf_bogota;

-- delete from bd_bogota;
-- select * from bd_bogota;

delimiter //
create procedure pacur1()
begin

DECLARE cuenta1 INTEGER default 0;

DECLARE valor1 INTEGER default 0; -- database name
DECLARE tipo_transaccion1 varchar(255) DEFAULT ""; -- path for backup files
DECLARE fecha1 varchar(255) DEFAULT ""; -- path for backup files
DECLARE fin INTEGER default 0;-- filename for backup
DECLARE cursor1 CURSOR FOR SELECT * FROM ttf_bogota;
DECLARE cursor2 CURSOR FOR SELECT * FROM ttf_medellin;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET fin = 1;

OPEN cursor1;
REPEAT
FETCH cursor1 into cuenta1,valor1,tipo_transaccion1,fecha1;
if not fin then
insert into bd_bogota(cuentab,valorb,tipo_transaccionb,fechab) values
(cuenta1,valor1,tipo_transaccion1,fecha1);
insert into bd_auditoria(tipo_transacciona,fechaa) values (tipo_transaccion1,fecha1);
end if;
until fin=1 end repeat;
CLOSE cursor1;
delete from ttf_bogota;

set fin=0;
OPEN cursor2;
REPEAT
FETCH cursor2 into cuenta1,valor1,tipo_transaccion1,fecha1;
if not fin then
insert into bd_medellin(cuentam,valorm,tipo_transaccionm,fecham) values
(cuenta1,valor1,tipo_transaccion1,fecha1);
insert into bd_auditoria(tipo_transacciona,fechaa) values (tipo_transaccion1,fecha1);
end if;
until fin=1 end repeat;
CLOSE cursor2;
delete from ttf_medellin;

end;
//
delimiter ;
call pacur1();
select * from bd_bogota;
select * from bd_medellin;
select * from bd_auditoria;
select * from ttf_medellin;
select * from ttf_bogota;
Datawarehouse/inteligencia de negocios:
Dataware house no es una tecnologia , tampoco un concepto o modelo de base de datos, se debe
concebir como una forma de trabajo o metodologia , através de la cual se hace posible entender
de que manerase accede a lainformacionde bd de negocios diferentes, q tienen de manera
impositiva un atributi de articulación, a fin de consolidarlas a través de tablas “desnormalizadas”,
para obtener al final un repositorio de salida que consolida la desnormalizada, permitiendo
construir “reportes o analisis” de índices y cuantificadores que hacen parte de lainteligencia de
negocios.
Tres conceptos clave hacen parte del escenario de datawarehouse
1- E. Extracción: apartir de las tablas de bd estrae la información que hará parte de la “tabla
dimensiones” (dimensión= jerarquía o atributo criterio)
2- T. Transformación: unifica los tipos de datos de la información coincidente y asigna un
único nombre en caso de no ser el mismo
3- C. Carga: Construye el recurso de software que sea necesario para llenar los datos de las
tablas de la BD a las “tablas dimesionales” y de las tablas dimensionales a la “tabla hechos”
La anterior configura lo que se conoce con la sigla ETC.
De la “tabla hechos” se generan los reportes o informes de análisis , que hacen parte del concepto
grafico de “multivista” denominada cobo”OLAP” Analysis Process OnLine

Ejemplo de tablas dimensionales:

Negocio: citas medicas de los pacientes
numcita fechas Tipo cita eps cedulapaciente
100 11/2001 2 2 40
200 09/2001 1 2 20
300 05/2002 2 3 10
400 09/2004 2 2 20
500 08/2006 1 2 40
600 11/2008 2 1 30
700 11/2008 2 3 10
Tabla de la BD

Cedula Cantidad Nombre Cantidad Nombre eps nombre

paciente tipo 1 tipo cita 1 tipo 2 tipo cita 2 eps
10 2 ojos 3 sura
20 1 huesos 1 ojos 2 compensar
30 1 ojos 1 cafam
40 1 huesos 1 huesos 2 compensar
En este caso se puede decir que las FKD serian el tipo de cita y la eps. Esta FKD representan las
dimensiones del datawarehouse o los atributos criterio de agrupamiento
Infracciones ,borracho, tecnomecanica vencida, soat vencido
Eps=Soat
numinfraccion fechas Tipo infraccion soat cedulainfractor
100 11/2001 3 2 40
200 09/2001 1 4 50
300 05/2002 3 3 10
400 09/2004 2 4 50
500 08/2006 1 2 40
600 11/2008 2 1 30
700 10/2009 3 3 20
800 12/2009 3 3 20
900 05/2010 1 2 40
1000 05/2010 2 2 60
1100 03/2011 2 3 20
1200 01/2011 1 3 10

Cedula Cantidad Nombre Cantidad Nombr Cantida Nombr soat nombre

infractor tipo 1 tipo tipo 2 e tipo d tipo 3 e tipo soat
infrac 1 infrac 2 infrac 2
10 1 borracho 1 soat 3 liberty
vencido
20 1 tecno 2 soat 3 liberty
vencida vencido
30 1 tecno 1 Seguros
vencida estado
40 2 borracho 2 fasecolda
50 1 borracho 1 tecno 4 Seguros
vencida mundial
60 1 tecno 2 fasecolda
vencida
Count , group by para infracciones y citas