Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
AUTOR:
PROFESOR:
BOGOTÁ - COLOMBIA
2019
TABLA DE CONTENIDO
Compromiso curso .............................................................................................................................. 2
31/07/2019 ......................................................................................................................................... 2
05/08/2019 ......................................................................................................................................... 5
12/08/2019 ......................................................................................................................................... 7
14/08/2019 ......................................................................................................................................... 9
Fecha: 21/08/2019 ............................................................................................................................ 12
Séptima Clase - Fecha: 26/08/2019 .................................................................................................. 13
Fecha: 28/08/2019 ............................................................................................................................ 16
- Fecha: 02/09/2019 .......................................................................................................................... 25
Corte 2 clase 9/09/2019 ................................................................................................................ 30
CLASE 16/09/2019......................................................................................................................... 37
Clase 23/09/2019 ........................................................................................................................... 40
CLASE 25/09/2019......................................................................................................................... 44
CLASE 30/09/2019......................................................................................................................... 48
clase 02/10/2019 ............................................................................................................................ 50
Taller 16/10/0219.............................................................................................................................. 59
COMPROMISO CURSO
1. Presencialidad.
2. Respeto biunivoco.
3. Complimiento trabajos.
4. Actitud y atención en clase (Disciplina).
Forma de calificación 1. Documento o memoria de la materia 40% : Edición en Word de c/u de las clases ( lo que escribe el
profesor ) / trabajos en clase y en casa / cada temática con una conclusión mínima de 5 líneas.
2. Apreciativa del rendimiento 20%.
3. Evaluación individual 40%.
31/07/2019
bases de datos
-definición:
cuando se habla de bases de datos, se debe involucrar varios escenarios y son estos:
desde la perspectiva de la ingeniería de sistemas, el “sistema” deberá ser concebido como el escenario encargado de contener
la “lógica de los procesos” a través de los cuales se maneja la información y permitirá cumplir con los propósitos “misionales”
de las diferentes “áreas” que hacen parte de la “organización” de la empresa.
antes de pensar que el diseño de software, se debera pensar en el diseño de la base de datos, queriendo con esto decir que
atraves de la elaboracion de los programas que hacen parte del producto de software, se hara posible conducir la informacion
a la base de datos.
2. diseño
el “diseño” de las bases de datos, es el segundo escenario relacionado con las generalidades de las bases de datos, y tiene
por objeto, organizar la informacion dentro de un “repositorio” o espacio, de manera funcionaly racional, utilizando la aplicación
de metodologias y tecnicas dispuestas para garantizar el buen uso de la informacion.
cuando el diseño corresponde a una base de datos relacional, hay que anteponer un “modelado” previo, que se relaciona con
el “modelo conceputal” y que esta de la mano con el denominado “modelo entidad relacion mer”, creado por “peter chenn”;
este modelo apoyado desde luego en las “logicas del negocio del sistema” y sustentando en la denominada “ley de la
autodeterminacion” y “ley de la reflexividad” propuesta por “amstrong”, que permite representar las “clases” del sistema como
“entidades” y la articulacion de las entidades como “relaciones”, de una manera muy grafica, pero obedeciendo a una
metodologia.
2.1 tipos:
se utiliza para entender negocios de sistemas “transaccionales”, en donde la tecnologia de estas bases de datos, colaborando
con validar la informacion, a fin de evitar “redundancias” y evitar el ingreso de informacion desarticulada, sin tener que recurrir
en los desgastes de la programacion.
no se repite la información
TABLA 1
se repite la informacion
Clave documento
30 30,pedro,2,abogado
20 20,juan,1,medico
10 10,maria,2,abogado
40 40,ruth,1,medico
3. el motor
el “motor” de la base de datos es el instrumento con el cual se hace posible llevar “el diseño” al computador. es el motor de
las bases de datos equiparable con lenguajes de computación, por tanto, su utilización solo es válida, cuando se ha construido
un diseño lógico de las bases de datos, con lo cual se define el orden de grabación de los datos y en consecuencia el orden
de cómo acceder a los mismos.
existen 2 grandes vertientes para el uso del motor en las bases de datos relacional:
4. la gestion
la “gestion” es el escenario y se compromete con el uso de la informacion a traves de un lenguaje relacionado con el motor.
lenguajes de las bases de datos relacionales, las cuales van de la mano con el “motor”, encontramos: mysql, sqlserver, oracle
y otros, los cuales se fundamentaron en unas clausulas y directivas estandares, que cambian muy poco dependiendo del
motor.
si bien el lenguaje se empieza a utilizar desde el mismo momento en que se crean dentro del computador las tablas del diseño
(create table), se hace mas interesante cuando se gestiona la informacion de las bases de datos de intrucciones tales como:
-insert
-update
-delete
-select
CONCLUSION:
Para diseñar y/o manipular una base de datos es importante como ingenieros de sistemas saber que antes de una
codificación primero hay que tener conocimiento del sistema que existen 4 escenarios que son los mas importantes al
diseñar una base de datos los cuales son el diseño , el motor , el sistema y la gestión. Estos 4 elementos se pueden definir
como una serie de datos que están bien organizados y se pueden dar una relación entre todos los 4 elementos , estos
elementos son recolectados y procesados por los sistemas de informacion de un cliente ya sea persona o una empresa .
las bases de datos que son de tipo relacionales permite que no exista un registro igual a otro registro ya almacenado
05/08/2019
bases de datos:
definicion de sistemas y construcción del contexto con base en la logica del negocio
1.sistema:
un sistema desde la perspectiva de la ingenieria de sistemas se debe concebir como un escenario compuesto por la
entrada, proceso y salida, en donde cada uno de estos elementos prima la logica que esta relaciona con los diferentes
procedimientos que hacen parte de su manejo.
PROCEDIMIENTOS
son los procedimientos entonces, los encargados de sugerir una sustencacion o automatizacion de los datos, obedeciendo
a un “contexto”.
el contexto (escenario dimensionado) define la dimension de lo que se debe hacer, por tanto, define el “largo y ancho” de lo
que se desea. para definir el contexto, se parte de la “narrativa” de necesidades del “cliente”, con base en la cual se
sucederan los incidentes:
(1) ejemplo:
la compañía esta interesada en controlar a traves del computador las facturas que se producen por las compras realizadas
por los clientes, de esta manera se facilita tanto a los vendedores y ejecutivos mantener una relacion mas directa con los
productos y los clientes, etc.
CLIENTE FACTURAS dependiendo de la abstraccion y
contexto puede existir mas de 2
clases
para quien se va que se va a controlar
a controlar
-clase
-clase
-entidad
-entidad
dentro de este contexto se debera mover diseño de base de datos y el diseño de software.
tengase en cuenta que los sistemas en su expresión absoluta, sin pensar en el computador, se hallan dentro de los sectores
productivos de la economia:
-terciario: logistica y servicios (educacion medicos transporte y energia), este gestiona y administra primario y secundario.
(2) ejemplo:
una empresa dedicada a la area de la construccion, tiene un equipo de trabajo que se relaciona con la operación de maquinas
excavadoras.
la empresa funciona en un edifico de cuatro pisos ubicado en un sector elegante de la ciudad, ademas goza de la presencia
de bellas secretarias, las cuales atienden de manera decorosa y profesional a los clientes.
los clientes son constructores de obras civiles los cuales de manera permanente alquilan equipos y maquinarias para la
excavacion de terrenos. el alquiler de los equipos se sucede a traves de un contrato de prestacion de servicios, lo cual a
motivado a la empresa a construir una solucion informatica que controle las maquinarias prestadas a traves de los contratos
suscritos con los clientes.
el departamento de contabilidad reclama con urgencia conocer de manera rapida y virtual la cantidad de contratos y los
diferentes tipos de equipos y maquinarias alquilados por los clientes.
CLIENTE
CONTRATOS
para quien se
va a controlar MAQUINARIA
para quien se
va a controlar/
que se va a
que se va a controlar
controlar
CONCLUSION:
Para poder empezar con un desarrollo de una base de datos primero toca identificar o hacer una abstracción de la lógica de
el Core, que es la que nos indica las entidades que la información sobre las entidades, y con esta información ya se puede
trabajar en un diseño a través de modelos, sin una buena base , es decir sin tener buenos modelos antes de ir a codificar lo
que se va a hacer la base de datos quedara mal , ya que al momento de plantear y hacer la abstracción de la lógica de el
Core y solo implementarlos en una base de datos no se tendrá en cuenta como se debe manipular los datos y esto en el
motor generara un error
12/08/2019
contexto del sistema/proceso
con base en el “contexto” se construye una expresion “exacta” de la logica del negocio del sistema, compuesta por las
clases principales, como sigue:
m
contexto: controlar facturas de los clientes sin
1 articulos.
CLIENTE1
M
CLASE2
PARA QUIEN
SE VA A
CONTROLAR
que se va a controlar
1
CLIENTE
M
FACTURA
M
R
existen muchos(m) clientes, y cada uno (1) de los clientes tiene muchas(m) facturas.
entre las “clases” del contexto de un sistema, siempre se define de “arriba hacia abajo”, una relacion(r) de una (1) o
muchas, esta relacion(r) se denomina relacion natural.
los contextos dependiendo de la abstraccion que se suceda a partir de la narrativa de lo clientes podran ser:
1.monofuncional simple:
1
CLIENTE1
M
CLASE2
M
R
2. monofuncional extendido
M
1
CLIENTE1 1
M
CLASE2 CLASE3
R
3.multifuncional simple:
CLASE 1
CLASE 2 no se relaciona por
lógica del negocio
se verían por
inteligencia del
negocio(in)
CLASE 3
4. multifuncional extendido:
M
1
CLASE 1 M 1
CLASE 2
M
1 CLASE 3
CLASE 4
para cumplir con lo anterios se habla de las siguientes formas normales fn:
se dice que el diseño de una bases de datos relacional se encuentra en 1fn cuando existe el contexto del sistema y cuando
hacen presencia la “ley de la autodeterminacion” de armstrong, que consiste en asignar atributos a cada una de las
clases del contexto, de manera “absoluta” (que los atributos o nombres de los datos de una clase determinada, son de esa
clase y no de otras).
(1) ejemplo: contexto facturas de los clientes de almacenes exitos (sin articulos):
M
1
CLIENTES
M
FACTURAS
id (pk)
R
nombre numero factura(pk)
fecha nacimiento fecha factura
lugar nacimiento(fkd) valor total
sucursal de la compra
1. elegir el “atributo identificador” de cada una de las clases del contexto, que se denominaran llaves primarias (primary
key pk).
2. elegir los “atributos” que se pueden expresar como “codigos” dentro de cada una de las clases, estos se llamaran llaves
secundarias o llaves foraneas fk, por ser identificados desde el mismo momento de la “autodeterminacion” las llamaremos
“foreign key por defecto fkd), siempre las fkd generan una pk en otro conjunto de clase. - aquellos atributos que desde
la autodeterminacion se manifiestan como posibles codigos.
CONCLUSION:
Para poder empezar a hacer un diseño de los modelos primero hay que identificar y abstraer los atributos de las entidades
de esta manera se puede hacer la normalización 1FN y 2FN para esto tenemos que identificar que es una PK o una FKD,
de esta manera se evitan que existan atributos duplicados y con esto se hace un filtro, es decir genera ciertas condiciones
para poder generar un diseño optimo .
14/08/2019
contexto y normalización
1fn y 2fn
DF (1-1)
DF
M 1 DFN(1-M)
1 1
CLIENTE1
M
CLASE2
R
atributos
atributos
PK PK
. .
FKD FKD
ETC ETC
contexto: identificacion y articulacion de las clases (que se va a controlar – para quien se va a controlar)
normalizacion:
1fn: identificacion y asignacion de “atributos” por la ley de la “autodeterminacion” de amstrong. identificacion de llaves
primarias (una pk por cada clase) / identificacion de llaves doraneas o secundarias por defecto(fkd), que son aquellos
atributos tipo “codigos”.
2fn: definicion del tipo de dependencia funcional- df, que corresponde a una relacion inversa que se sucede de abajo hacia
arriba, es decir entre la “clase sucesora” y la clase predecesora”.
cuando existiendo una “relacion natural” de uno (1) a muchos(m) se obtiene una “relacion inversa” de uno (1) a uno (1),
ejemplo:
-(muchos clientes) cada uno (1) de los muchos clientes tiene muchas(m) facturas = relacion natural
-cada una (1) de las muchas facturas de ese cliente, son unicamente de ese un (1) cliente y no de otros = relacion inversa.
dependencia funcional no exclusiva – dfn: cuando existiendo una relacion natural de uno (1) a muchos(m), se obtiene
una relacion inversa de uno (1) a muchos (m), ejemplo:
-(muchas facturas) cada una (1) de las muchas (m) facturas, tiene muchos (m) articulos = relacion natural.
-cada uno (1) de los muchos (m) articulos de cada una de las muchas facturas, pueden estar tambien en otras muchas(m)
facturas.
modelo matematico de las bases de datos: es un escenario fundamentado en la teoria de conjuntos, que permite
solucionar los tipos de dependencias funcionales vinculados en la “articulacion de las clases”.
dfe:
CONTEXTO (SIN ARTICULOS)
CLASE PRINCIPAL
M 1 DFE(R1)
CLIENTES 2FN
1 M CLASE PRINCIPAL
facturas
1
id (pk) R
sucursal de la compra
(fkd)
clase secundaria
clase secundaria
el modelo matematico solo es posible si se tiene 1fn y 2fn, conduce a expresar en funcion de conjuntos el diseño de la
base de datos solucionando(3fn-4fn-5fn) los tipos de dependencias funcionales vinculados enre las “clases, de arriba hacia
abajo.
lugar(pke), nombrelugar
una foreign key por proceso siempre solucionara en modo conjunto la clase sucesora que se encuentre en dependencia
funcional exclusiva respecto a la clase predecesora.
lo anterior muestra de que manera la primary key de la clase predecesora se refleja como foreign key por proceso en la
clase sucesora, a esto se le llama reflexividad (ley de la reflexividad de amstrong).
La utilización de los modelos conceptual ( Entidad- relación de Peter Chenn) y del modelo relacional ( Eddgar Cod) solo
serán posibles si existe el modelo de solución matemática.
La DPE permite establecer que un componente puede heredar la primary key de un componente sucesor pero armando
una nueva llave primaria con el componente que heredo la primary kaey de el sucesor
FECHA: 21/08/2019
Recordatorio: antes de hacer base de datos, necesitamos tener definido el contexto del
sistema.
Diseño de base de datos
Antecedentes: 1FN-2FN (Edgar Codd)
1FN:
- Contexto sistema
- Autodeterminación (Ley de Armstrong) por medio de- Algebra proposicional
2FN:
- PK-FKD
- Asignar DF (E, NE) es por Ley de Armstrong.
Idcli nomcli
lugnac
nofac fechfac volt nomlug
c fechnac
Idcli
lugnac
nomlug Entidad
Sucursale
s
sucur dir tel
Modelo relacional (MR): cumple las mismas reglas del MER, pero en modo “Tablas”:
facturas
clientes
Nofac PK Idcli PK
Fechafac Nomcli
Valt Fechnac
Idcli FK Lugnac FK
sucurFK
sucursales facturas
Sucur PK
Dir
tel Nofac PK
Fechafac
Valt
Idcli FK
sucurFK
CONCLUCION:
Para poder realizar un modelo de una forma buena tenemos que saber lo más importante, esto es el contexto que tiene el
sistema y luego usar la ley de autodeterminación que nos permite organizar el modelo que planteamos del problema , luego
la reflexividad nos brindara ayuda a la hora de construir los modelos conceptuales planteados por Peter chenn, que son
necesarios para llevar a cabo una buena codificación del sistema
1FN
Lugnac (FKD sucur (FK)
Clase Clase
secundaria(incluide) secundaria
UML:
Dependencia Funcional exclusiva.
UML la llama Asociación bilateral binaria
1
CLIENTE
M
FACTURA
M
R
Lugnac (FKD
Asociación por
composición
facturas
CONCLUSION:
Hay una importante diferencia que tiene el core de el sistema y los informes que son llamados inteligencia de negocios, la
cual es que el core de el sistema la tiene la misión la tiene el área o el cliente y nosotros no podemos modificar eso , por
esto nosotros tendremos que seguir todo lo que en el core este con exactitud a la hora de diseñar una base de datos ,
mientras que con el informes o la lógica de negocios es con lo que se trabaja al diseñar una base de datos y esa si se
puede manipular al gusto del codificador o programador
FECHA: 28/08/2019
Con base en los datos ya grabados en las tablas del diseño de BD en cuestión (sobre el
Use base1;
values(100,'andres','1989/10/10',2);
values(405,'2019/10/10',60000,100,10);
values(500,'2019/9/15',100000,100,10);
codigo entero
use base1;
lugnac int,
nomlug varchar(30),
);
idcli int,
nomcli varchar(20),
fechnac date,
lugnac int,
primary key(idcli),
foreign key(lugnac)
references lugares(lugnac)
);
sucur int,
dir varchar(25),
tel int,
primary key(sucur)
);
nofac int(10),
fechfac date,
valt int(12),
idcli int,
sucur int,
primary key(nofac),
);
Use base1;
values (1,'Bogota');
values(100,'pedro','1979/10/10',1);
values(204,'2019/10/18',40000,100,10);
values(50,'2019/10/18',60000,100,10),
(299,'2019/9/15',100000,100,10);
TRABAJO
Narrativa del cliente
El área del mantenimiento de motores es el que tiene a cargo el control de las ordenes de servicio
sobre reparación por conceptos diferentes que se suceden sobre esta parte de el vehículo y es
justamente esta área la encargada de generar los mencionados reportes.
1- Construya el contexto del sistema
Modelo relacional
Modelo DDL
SOLUCION
1.
clientes
vehículos
Ordenes de servicio
para reparar motores
2-El Core de este sistema la da el área de mantenimiento de motores, (en el área esta la misión y
la misión me da el Core)
Mecanico FKD
Idmotor FKD
mecani
fechao
numor
model
marca
Nomcli
Teleli
placa
placa
Activ
Idcli
dvd
idcli
coc
vd
o
Entidad Ordenes de
cliente vehiculo servicio para reparar
motores
Modelo relacional
Clientes
Idcli PK
Nomcli
Teleli
vehiculos
Activ FKD
Placa PK
Modelo
Marca FKD Ordenes de
servicio para
reparar
motores
Numord PK
fechaovd
Mecanico FKD
Idmotor FKD
Modelo DDL
Código fuente:
create database base1;
use base1;
activ int,
infoactiv varchar(30),
);
idcli int,
nomcli varchar(20),
telcli int,
activ int,
primary key(idcli),
);
marc int,
infomarc varchar(25),
primary key(marc)
);
placa int,
modelo varchar(10),
color varchar(12),
idcli int,
marc int,
primary key(placa),
);
idmotor int,
clasemotor varchar(25),
refer int,
primary key(idmotor)
);
meca int,
nommeca varchar(25),
telmeca int,
primary key(meca)
);
numord int(10),
fechord date,
volt int,
placa int,
idmotor int,
meca int,
primary key(numord),
);
Use base1;
values(100,'Daniel',411313123,1);
values(103,'Renold');
values(14243,'DUSTER','Blanco',13,111);
values(33192,'qwwweqweq',53456789);
values(3,'Hernan Cortez',320545630);
values(4442,'2016/04/10',30000,23313,1444,12);
Ejecución pantallazos
CONCLUSION:
- FECHA: 02/09/2019
DML (lenguaje para el manejo de datos gestión Motor)
Es normal acceder a las tablas de las bases de datos procurando escalar la información atraves de “criterios” de consultas
y exigen complementar lo solicitado mediante un cruce sencillo o múltiple entre las tablas requeridas; el cruce entre las
tablas se logra de manera práctica implementando una sentencia” select” que invucula insu sintaxis los siguientes
característicos
Select t1.ced,t1.nom,t1.tel,
T1.cargo,t2.nomcargo
Where t1.cargo=t2.cargo;
select t1.nom,t1.tel,
T1.cargo,t2.nomcargo
On t1.cargo= t2.cargo;
Select t1.ced,t1.nom,t1.tel,
t1.cargo,t2.nomcargo,
t1.estrato,t3.nomestrato
Select t1.ced,t1.nom,t1.tel,
T1.cargo,t2.nomcargo,
T1.estrato,t2.nomestrato
From clientes t1 inner cargos as t2 inner estratos as t3
Código :
use base1;
cargo int,
nomcargo varchar(30),
);
estrato int,
nomestrato varchar(30),
);
ced int,
nom varchar(20),
tel int,
cargo int,
estrato int,
primary key(ced),
);
Use base1;
values (1,'Gerente');
values (1,'4');
values(1231,'pedro',3232323,1,1);
select t1.ced,t1.nom,t1.tel,t1.cargo,t2.nomcargo
where t1.cargo=t2.cargo;
CONCLUSIONES }
CORTE 2 CLASE 9/09/2019
Insert, update, select(con where and, join ,etc) hacen parte de las “directivas “del PLSQL como también lo es el “delete”
la” directiva” delete , permite construir instrucciones simples o compuestas con where ,and ,etc, que permitan “borrar o
eliminar” registros de las tablas parcial o de manera total se advierte que como no podemos borrarse registros de tablas
antecesoras utilizados en tablas sucesoras .
Aplicación
Sucesora
Where ciudad=2;
Where cedula=400;
Codigo:
create database base1;
use base1;
ciudad int,
nomciudad varchar(30),
);
(
ced int,
nom varchar(20),
ciudad int,
sueldo int,
primary key(ced),
);
Use base1;
values (1,'Yopal');
values (2,'Cauca');
values (3,'Cali');
values (100,'Pedro',2,800000);
values (200,'Maria',3,900000);
values (300,'Sara',1,700000);
values (400,'Andres',3,800000);
values (500,'Juan',2,700000);
values (600,'Carlos',1,900000);
values (700,'Ruth',2,700000);
and sueldo>700000;
select ‘---------------------------’;
delete form empleados
where cedula<500;
select ‘---------------------------’;
use base1;
ciudad int,
nomciudad varchar(30),
);
ced int,
nom varchar(20),
ciudad int,
sueldo int,
primary key(ced),
);
Use base1;
values (1,'Yopal');
values (2,'Cauca');
values (100,'Pedro',2,800000);
values (200,'Maria',3,900000);
values (300,'Sara',1,700000);
values (400,'Andres',3,800000);
values (500,'Juan',2,700000);
values (600,'Carlos',1,900000);
values (700,'Ruth',2,700000);
select '---------------------------';
Where ced=400;
select '---------------------------';
and sueldo>700000;
select '---------------------------';
where ced<500;
select '---------------------------';
“procedimientos almacenados”
Dentro del escenario del PLSQL,existe la posibilidad de construir programas de computador , que podrán ser
guardados en el disco duro, Con lo cual se asegura su reutilización sin volver a escribir nuevamente el código
Aplicación:
Supóngase que de manera permanente se requiere leer de la tabla “empleados” las personas con un
determinado valor de sueldo /
Delimiter //
begin
select'------------------------';
end;
//
delimiter ;
values (100,'Pedro',2,800000);
values (200,'Maria',3,900000);
values (300,'Sara',1,700000);
values (400,'Andres',3,800000);
values (500,'Juan',2,700000);
values (600,'Carlos',1,900000);
values (700,'Ruth',2,700000);
Nota :Delimiter es la instruccion a través de la cual, se cambia el “delimitador “punto y coma (;)por otro
delimitador ejemplo doble slash(//),para poder utilizar punto y coma (;)dentro del procedimiento como “Fin de
instrucción ” y no como “Ejecutor de una sentencia”
Codigo entero:
create database base1;
use base1;
ciudad int,
nomciudad varchar(30),
);
ced int,
nom varchar(20),
ciudad int,
sueldo int,
primary key(ced),
);
Use base1;
values (1,'Yopal');
values (2,'Cauca');
values (3,'Cali');
values (100,'Pedro',2,800000);
values (300,'Sara',1,700000);
values (400,'Andres',3,800000);
values (500,'Juan',2,700000);
values (600,'Carlos',1,900000);
values (700,'Ruth',2,700000);
select '---------------------------';
Where ced=400;
select '---------------------------';
and sueldo>700000;
select '---------------------------';
where ced<500;
select '---------------------------';
Delimiter //
begin
select'------------------------';
end;
//
delimiter ;
values (100,'Pedro',2,800000);
values (300,'Sara',1,700000);
values (400,'Andres',3,800000);
values (500,'Juan',2,700000);
values (600,'Carlos',1,900000);
values (700,'Ruth',2,700000);
Conclusion:
CLASE 16/09/2019
Procedimientos almacenados con manejo de “cursores”
Delimiter //
Begin
Declare continue handler for not found set fin=1; open cursor1
Repeat
If suel1<850000 then
End if ;
Close cursor1;
End;
//
Delimiter ;
Select * from emple; Resultado : Todos los “sueldos “ menores a 850000 son
cambiados por 900.000
Entonces :
Tener una base de datos , con una sola table ,llamada “emple”
Fetch cursor1 into ced1,suel1; (pone ced y suel1 dentro de ced1 y suel1)
Cursor: es un “objeto” un arreglo tipo vector o matriz , que viene incorporado dentro del motor y se utiliza
cuando dentro de un procedimiento almacenado se quiere “materializar” en la RAM todos los registros de
una”tabla” leidos con un select
CODIGO
create database base1;
use base1;
ced int,
nom varchar(20),
suel int,
primary key(ced)
);
Use base1;
insert into emple(ced,nom,suel)
values(100,"Pedro",1000000);
values(200,"Maria",820000);
values(300,"Juan",850000);
values(400,"Carlos",9000000);
values(500,"Ruth",800000);
values(600,"Clara",920000);
delimiter //
begin
open cursor1;
repeat
end if;
close cursor1;
end;
//
delimiter ;
call proce3();
Conclusion:
Lo normal es encontrar un solo Core en la misión del negocio del área sobre la cual se está trabajando ,no
obstante , es posible que un área tenga más de un “Core” , o que en el momento del diseño de la base de
datos se deba tener en cuenta el “Core” de más de un área creando un “contexto” multifuncional con cada una
de las misiones , como sigue :
m 1
CLIENTE1 1
1 Nota: por
M context, no
1 Facturas
tiene en
Idcli PK RN cuenta los
articulos
Nomcli
Nofac PK
Telcli
Fechfac
Profecli FKD
Totfac
1
Sucur FKD
Nunca se verian
por logica de
M
Sorteos
sus negocios; se
verian mas
RN adelantada por
Idsorteo PK interligencia de
negocios
Fechasorteo (REPORTES)
RI: DFE
Tiposorteo FKD
1
Modelo de conjuntos
Sucur(PK)
Nofac(PK) Dirección
Fechfac telefono
Total
Sucur(FKD)
Idcli(FKP) Clientes
Profesion
cliente
Sorteos
Idcli (PK)
Profecli(PK)
Nomcli
nomprof
Telcli
Idsorteo(PK) Profecli(FKD)
Fechasorteo
Tiposrteo(FKD)
Idcli(FKP)
Tipo sorteo
Tiposorteo(PK)
nomsorteo
Modelo entidad relación
tel
dir
sucur
Entidad
Sucursales
volt
fechfac
c Idcli nomcli
profecli
nofac nomprof
telcli
Idcli
profecli
Entidad
Factura
idsorteo Entidad
clientes Entidad
Entidad
fechasort profesion
eo
Sorteos
tiposorte
o
idcli Entidad
tiposorteo
CONCLUCIONES
El modelo entidad relación es el mismo modelo conceptual mejorado y asegurado porque ya tiene una logica
No se puede llevar a 4 y 5 FN porque la llave primaria son mono atributo, 3 FN solo puede tener en su diseño
mono atributos en la llave primaria
CLASE 25/09/2019
Diseño de base de datos relacional
m
1
1
Propietarios 1 1
1
M inmuebles
1 M impuestos
1
Idpro PK 1
RN
Nromatr PK RN
Nompro Nroreci PK
Dirinm
Telpro Fechapga
Valorim
Profpro FKD Valpa
Localidad FKD
Banco FKD
1
M
vehículos Infracciones
1
RN M
RN
1
Placa PK Reciinfr PK
Modelo Fechinfr
Modelo de conjuntos
Profpro (PK),nomprof
(3) conjunto de la clase principal inmueble: (solucionar la dependencia funcional exclusiva):
Localidad(PK),nomloca
marca(PK),marcacar
Tipoinfr(PK), nominfrac
local
Modelo relacional
Localidad(PK)
banco
Impuestos nomloca
Banco (PK),
Nroreci (Pk), nombanco
fechapag,
valpa,
banco(fkd),
nromatr(FKP)
inmuebles propietarios
infracciones
vehículos
Recoinfr(PK),
fechainfr Placa (PK),
valorinfr modelo,
placa(FKP) marca(FKD),
idpro (FKP)
tipoinfr(FKD),
Tipo infracción
Marca
Tipoinfr(PK),
marca(PK)
nominfrac
marcacar
Modelo entidad relación
Entidad Local
Entidad
banco
banco
dirinm
valpa
Entidad Entidad
Fechapag
Impuestos Propietarios
o
nromatr
Entidad
idpro
inmuebles profpro
nromatr idpro
Entidad Profesión
Valorin
m
propietario
fechainf
r
nomprof
placa
valorinfr
Recoinfr
Entidad
placa modelo
tipoinfr Infracciones
Entidad
vehículos
Entidad
Marca
idsorteo marca
marca marcacar
Entidad
Tipo
infracción
tipoinfrac nominfrac
CONLUSIONES
1 FN contexto de la lógica del Core del negocio asignación de atributos por ley de armtorm
3FN solucionar DFE por la ley de la reflexividad (cuando se refleja como clase sucesora como PK de una
clase antecesora)
CLASE 30/09/2019
DFNE/4FN-5FN (dependencia funcional no exclusiva):
De manera determinante el diseño de un BD en 4FN y 5FN, deberá tener una PK “multiatributo”, a diferencia a
diferencia del diseño en 3FN, en donde la PK es “mono atributo”
Llave primaria
RI: DFNE compuesta
(M) M
1
FACTURAS
M artículos
Nofac PK
Fechfac
Idcliente FKD
RN
Codigoart(PK)
Nomart
Valorart
Cantidad
Tipoart FKD
Modelo de conjuntos
Tipoart(PKE), nomtipo
Modelo relacional
facturas clientes
Llave
compuesta/llave Nofac PK Idcli PKE
compartida Fechafac Nomcli
Idcli FKD telcli
Factu.art
(nofac,codart)PKE
cantidadven Tipo articulos
articulos
Tipoart PK
Codart PK nomart
Nomart
Valorart
Tipoart FKD
CONCLUSIONES
4FN y 5FN solo se resuelve con multiatributo (una primary key multiatributo)
CLASE 02/10/2019
DFNE (4FN-5FN)
Entidad
facturas Entidad
clientes
Relación
fuerte
Fact-art
nomart
valorart
entidad
Modelo ddl
idcli int,
nomcli varchar(20),
telcli int,
primary key(idcli)
);
(+
tipoart int,
nomart varchar(20),
primary key(tipoart)
);
nofac int,
fechfac date,
idcli int,
primary key(nofac),
);
codart int,
nomart varchar(20),
valorart int,
tipoart int,
primary key(codart),
);
nofac int(8),
codart int(4),
cantvend int(4),
primary key(nofac,codart),
);
Use base1;
values(100,"Pedro",1000000);
CONCLUSIONES
Cuando se inscribe el rombo dentro del rectángulo se dice que la relación fuerte deberá ser agregada como
una entidad(agregación)
Cuando se soluciona el DFNE entre las clases: concatenando las llaves primarias de la clase antecesora con
la llave primera de la clase sucesora
EJERCICIO SEMANA DE RECESO
RI: DFNE
(M) M
1
estudiantes
M materias
IDest PK
RN
Codmat PK
Nomest
Nommat
Telest
Numcredi
Codcarrera FKD
Calificación
Codfacul FKD
Modelo de conjuntos
codfacul(PKE), facultad
Modelo relacional
estudiantes codcarrera
Llave
compuesta/llave Idest PK Codcarrera PK
compartida Nomest nomcarrera
Telest
Codcarrera FKD
Estudiantes.
materias
(idest,codmat)PKE
numcredi codfacul
materias
Codfacul PK
facultad
Codmat PK
Nommat
Numcredi
Calificacion
Codfacul FKD
Modelo entidad relación
idest codmatiera
codmateria nommater
Entidad
estudiantes
Entidad
codmateria
telest nomest
Relación
fuerte codfacul codfacul facultad
codmat
Estu-mater
Entidad Entidad
materias codfacul
use base1;
idcli int,
nomcli varchar(20),
telcli int,
primary key(idcli)
);
(+
tipoart int,
nomart varchar(20),
primary key(tipoart)
);
nofac int,
fechfac date,
idcli int,
primary key(nofac),
);
codart int,
nomart varchar(20),
valorart int,
tipoart int,
primary key(codart),
);
nofac int(8),
codart int(4),
cantvend int(4),
primary key(nofac,codart),
);
Use base1;
values(100,"Pedro",1000000);
TALLER 16/10/0219
La compañia de Colombiana en vender productos alimenticiosfundada en el año xxx, localizada en
la dirección xxx, de propiedad de las personas xxxx , yyy,zzzzz genera mensualmente
determinados informes que permiten visualizar los diferentes automóviles de determinados
clientes que han ingresado a las instalaciones para determinado mantenimiento , así mismo se
producen reportes que permiten ver las facturas que peretecen a los clientes, se generan también
los informes xxx yyy y zzzzz .
El área de facturación de los productos es el que tiene a cargo el control de las ordenes de servicio
sobre los productos
(M) 1
1
clientes
M facturas
1
Idcli PK
RN
nofac PK
nomcli
fechfac
telcli articulos
totfac
profcli FKD M
sucur FKD
Codart PK
nomart
valunart
cantvendiart
tipoart FKD
Modelo de conjuntos
Modelo relacional
facturas
sucur
Llave
compuesta/llave Nofac PK
compartida Fechfac Sucur PK
ciudad
Totfac
Sucur
Sucur FKD
Facturas.articul
Idcli FKP
(nofac. codart)PKE
cantvendart clientes
artículos
Idcli PK
Nomcli
Telcli
Codmat PK
Nommat Profcli FKD
Numcredi Profcli
Calificacion
Codfacul FKD
Profcli PK
nomprof
tipoart
Tipoart PK
nomart