Memorias

UNIVERSIDAD CENTRAL
FACULTAD DE INGENIERÍA, CIENCIAS BÁSICAS
CARRERA DE INGENIERÍA DE SISTEMAS
DOCUMENTACIÓN DISEÑO DE BASES DE DATOS
AUTOR:
Daniel David Ramos García
PROFESOR:
JHON JAIRO LONDOÑO PEREZ
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:
1. sistema (los procesos):

el sistema es entonces la materia prima para poder acceder al diseño de la base de datos y por supuesto al diseño del
software.
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:
sobre el “diseño” hay que decir que existen 2 tipos de diseños:
2.1.1 diseño relacional:
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.
2.1.1.1 bases de datos relacional:
no se repite la información
Cedula Nombre Profesión Profesión Definición

10 Juan 2 1 medico
20 María 1 2 abogado
30 Carlos 2
40 Sandra 1 TABLA 2
TABLA 1
2.1.2 diseño documental:

se utiliza para atender negocios de sistemas “no transaccionales”, en donde de la validacion y articulacion de la informacion
no es importante, por tanto, permite la “redundancia de informacion”, aunque exija de la identificacion de la de lo grabado
atraves de la eleccion de un campo clave. es posible vincular los conceptos de la validacion, articulacion y no redundancia de
la informacion incorporando esfuerzos de tiempo de programacion.
2.1.2.1 bases de datos documental
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
string: archivo plano
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:
- creacion de las tablas de diseño
- manejo de los datos dentro de las tablas
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
lo anterior trasciende cuando se incurre en la programacion a traves de:
-procedimientos almacenados elementales
-procedimientos almacenados con cursores
-procedimientos almacenados con trigger
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.
entrada  proceso  salida
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:
lectura, abstracción, modelo de la logica.
narrativa del cliente:
1.1 lectura y abstraccion:
-que se quiere controlar

Stickman -para quien se va a controlar
clase1 y clase2, son los escenarios que se quieran

CLASE 1 CLASE 2 contratar de la logica, los cuales en terminos de la
ingenieria de software, se denominan “clases”.
para quien se va a que se va a
controlar controlar
(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:
-primario: recursos naturales: agua, ganado, piscicultura...
-secundario: industria (maquinaria de explotación o transformacion), este tambien aprovecha lo primario
-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
forma normal 1fn y segunda
forma normal 2fn

esta clase que solo se procede a construir el diseño de la base y el diseño de software, si existe en el contexto del sistemas.
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
se construye de abajo hacia arriba y se lee de arriba hacia abajo.
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
no se ven por logica M 1

del negocio/se verian
por in CLASE 3
CLASE 4
representacion tradicional multifuncional simple:
representacion tradicional multifuncional extendida:

nomalizacion
la normalizacion es un ejercicio y permite garantizar, la “no redundancia” de la informacion, la “funcionalidad” de servicios

entre los datos, y los “negocios” coherentes y logica entre los escenraios de la informacion.
para cumplir con lo anterios se habla de las siguientes formas normales fn:
-primera forma normal 1fn:
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”.
las dependencias funcionales tambien de amstrong, pueden ser de 2 tipos:
dependencia funcional exclusiva – dfe:
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
nombre numero factura(pk)
fecha nacimiento fecha factura 1FN
lugar nacimiento (fkd) valor total
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.
(1) conjunto de la clase principal clientes:
idcliente(pk), nombre, fecha nacimiento, lugar nacimiento(fkd)
(2) conjunto de la clase secundaria lugares:
lugar(pke), nombrelugar
(3) conjunto de la clase principal facturas: (solucionar la dependencia funcional exclusiva):
numerofactura(pk), fechafact,valortotal, sucursal(fkd), idcliente(FKP)
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).
(4) conjunto de la clase secundaria sucursales:
sucursal(pk), direccion, telefono

CONCLUSION :
siempre el tipo de dependencia funcional exclusiva nos conduce a la tercera forma normal- 3fn y no existirá ninguna
posibilidad obtener 4fn y 5fn (4n y 5fn son propias de las dependencias funcionales no exclusivas).
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.
-Construcción del diseño: resolver los tipos de dependencias funcionales (DFE,

DFNE) reflexividad / transitividad.
- FKP:
PK de la clase antecesora, se refleja como FKP en la clase sucesora.
- Representación de la resolución de la reflexividad (DFE)
- Modelo pseudo matemático(conjuntos)
- Modelo conceptual evolucionado o asegurado: modelo entidad
relación.
Reglas:
1. Inicia el modelo de izquierda a derecha, ubicando en modo
“entidad” como primer conjunto, el que resuelve la última
clase del contexto.
2. Ubique en modo entidad, a la derecha del conjunto de la
entidad de la izquierda, el conjunto que la PK de lo FK de la
entidad de a izquierda.
3.Asigne las relaciones de derecha a izquierda.
4. En adelante el modelo, deberá ser leído de derecha a
izquierda.
Idcli nomcli
lugnac
nofac fechfac volt nomlug
c fechnac
Idcli
lugnac
Entidad Entidad Entidad

Factura clientes
Lugares
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
SÉPTIMA CLASE - FECHA: 26/08/2019

Notaciones UML - Notaciones Peter Chenn aplicado al DFE
1
CLIENTES Clase
M
FACTURAS principal
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
Peter Chenn: Disyunción

CLIENTE
facturas
Peter Chenn: Exclusividades FKD
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
cual estamos trabajando) genere 2 nuevas facturas
Use base1;
insert into clientes(idcli,nomcli,fechnac,lugnac)
values(100,'andres','1989/10/10',2);
insert into sucursales(sucur,dir,tel)
values(9,'av 6 calle 40',4120);
insert into facturas (nofac,fechfac,valt,idcli,sucur)
values(405,'2019/10/10',60000,100,10);
values(500,'2019/9/15',100000,100,10);
codigo entero
create table Test(id integer, title varchar(100));
insert into Test(id, title) values(1, "Hello");
select * from Test;
-- Your code here!
create database base1;
use base1;
create table lugares
lugnac int,
nomlug varchar(30),
primary key (lugnac)
);
create table clientes
idcli int,
nomcli varchar(20),
fechnac date,
lugnac int,
primary key(idcli),
foreign key(lugnac)
references lugares(lugnac)
);
create table sucursales
sucur int,
dir varchar(25),
tel int,
primary key(sucur)
);
create table facturas
nofac int(10),
fechfac date,
valt int(12),
idcli int,
sucur int,
primary key(nofac),
foreign key(idcli) references clientes(idcli),
foreign key(sucur) references sucursales(sucur)
);
Use base1;
insert into lugares (lugnac,nomlug)
values (1,'Bogota');
insert into clientes(idcli,nomcli,fechnac,lugnac)
values(100,'pedro','1979/10/10',1);
insert into sucursales(sucur,dir,tel)
values(10,'av 6 calle 40',4120);
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
La compañia de Colombiana automotriz fundada 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
establecer los mecánicos que han atendido determinadas ordenes de servicios , se generan
también los informes xxx yyy y zzzzz .
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
2- construya el diseño de bases de datos representado a través de los modelos

psdumatematico (el conjunto)
Modelo conceptual asegurado(entidad-relación)
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)
El Core de la lógica de la misión:

clientes
vehiculos
Ordenes de servicio
Idcli PK para reparar motores
Nomcli Placa PK
Teleli Modelo numord PK
Activ FKD Marca FKD fechaovd
Mecanico FKD
Idmotor FKD
psdumatematico (el conjunto)
(1) CONJUNTO DE LA CLASE PRINCIPAL CLIENTES:
IDeCli(PK), Nomcli,Teleli,activ FKD

(2) CONJUNTO DE LA CLASE SECUNDARIA :
Placa PK, Modelo, Marca FKD
(3) CONJUNTO DE LA CLASE Secundaria Ordenes de servicio para reparar motores:
Numord PK, fechaovd ,Mecanico FKD,IdMotor FKD
Modelo entidad relacion
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:
use base1;
create table actividad
activ int,
infoactiv varchar(30),
primary key (activ)
);
idcli int,
nomcli varchar(20),
telcli int,
activ int,
primary key(idcli),
foreign key(activ) references actividad(activ)
);
create table marca
marc int,
infomarc varchar(25),
primary key(marc)
);
create table vehiculo
placa int,
modelo varchar(10),
color varchar(12),
idcli int,
marc int,
primary key(placa),
foreign key(idcli) references clientes(idcli),
foreign key(marc) references marca(marc)
);
create table motor
idmotor int,
clasemotor varchar(25),
refer int,
primary key(idmotor)
);
create table mecanico
meca int,
nommeca varchar(25),
telmeca int,
primary key(meca)
);
create table ords
numord int(10),
fechord date,
volt int,
placa int,
idmotor int,
meca int,
primary key(numord),
foreign key(placa) references vehiculo(placa),
foreign key(idmotor) references motor(idmotor),
foreign key(meca) references mecanico(meca)
);
Use base1;
insert into actividad (activ,infoactiv)
values (1,'En reparacion');

insert into clientes(idcli,nomcli,telcli,activ)
values(100,'Daniel',411313123,1);
insert into marca(marc,infomarc)
values(103,'Renold');
insert into vehiculo (placa,modelo,color,idcli,marc)
values(14243,'DUSTER','Blanco',13,111);
insert into motor (idmotor,clasemotor,refer)
values(33192,'qwwweqweq',53456789);
insert into mecanico (meca,nommeca,telmeca)
values(3,'Hernan Cortez',320545630);
insert into ords (numord,fechord,volt,placa,idmotor,meca)
values(4442,'2016/04/10',30000,23313,1444,12);
select * from actividad;
select * from ords;
select * from mecanico;
select * from clientes;
select * from marca;
select * from vehiculo;
select * from motor;
Ejecución pantallazos
CONCLUSION:
Lo menos importante a la hora de diseñar es la codificación ya que es algo estándar, lo

importante es saber diferenciar entre que lógica puedo manipular entre CORE , lógica de
negocios . de esta forma se evita errores en el futuro, a la hora de codificar solo hay que
tener en cuenta de ciertos conceptos ya sabiendo todo lo teorico sobre diseño de bases
de datos por ejemplo las clases principales se denominan extend porque heredan y las
clases secundarias se denominan includ porque no heredan.,
3FN → Resuelve los tipos de dependencia funcional exclusiva.
La dependencia funcional exclusiva llega hasta 3FN ,4FN Y 5FN solo les para la
dependencia no exclusiva
Un modelo de dependencia se resuelve desde el modelo matemático.
- FECHA: 02/09/2019
DML (lenguaje para el manejo de datos gestión Motor)
Cruce de información entre tablas (alias-inner):
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
1. Asignar a las talas requeridas, un “Alias o apodo”

2. Vincular un inner(unidn) y a su vez adoptar “alias” para las tablas
Aplicación supóngase que se tiene el siguiente segmento de base de datos

1. Consulta cruce sencillo con “alias”:
Select t1.ced,t1.nom,t1.tel,
T1.cargo,t2.nomcargo
From clients as t1,t2.nomcargo
From clients as t1,cargos as t2
Where t1.cargo=t2.cargo;
2. consulta cruce sencillo con inner y alias}
select t1.nom,t1.tel,
T1.cargo,t2.nomcargo
From clientes as t1 inner cargos as t2
On t1.cargo= t2.cargo;
3. Consulta cruce multiple (mas de 2 tablas)utilizando “alias”:
t1.cargo,t2.nomcargo,
t1.estrato,t3.nomestrato
From clientes as t1,cargos as t2,estratos as t3
Where t1.cargo=t2.cargo and t1.estrato =t3.estrato;
4.consulta cruce multiple (mas de 2 tablas)
Utilizando “inner y alias”
T1.cargo,t2.nomcargo,
T1.estrato,t2.nomestrato
From clientes t1 inner cargos as t2 inner estratos as t3
On t1.cargo=t2.cargo and t1.estrato=t3.estrato ;
Código :
use base1;
create table cargos
cargo int,
nomcargo varchar(30),
primary key (cargo)
);
create table estratos
estrato int,
nomestrato varchar(30),
primary key (estrato)
);
ced int,
nom varchar(20),
tel int,
cargo int,
estrato int,
primary key(ced),
foreign key(cargo) references cargo(cargo),
foreign key(estrato) references sucursales(estratos)
);
Use base1;
insert into cargos(cargo,nomcargo)
values (1,'Gerente');
insert into estratos(estrato,nomestrato)
values (1,'4');
insert into clientes(ced,nom,tel,cargo,estrato)
values(1231,'pedro',3232323,1,1);
select t1.ced,t1.nom,t1.tel,t1.cargo,t2.nomcargo
from clientes as t1,cargos as t2
where t1.cargo=t2.cargo;
Include se ponen la flechas para arriba

incluide
incluide
CONCLUSIONES }
CORTE 2 CLASE 9/09/2019
PLSQL(DML) sentencias básicas /introducción o procedimientos almacenados
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
Supóngase que se tiene el siguiente segmento de base de datos:
Cedula Nombre Ciudad Sueldo

Ciudad Nombre ciudad
100 Pedro 2 800000
1 Yopal
200 Maria 3 900000
300 Sara 1 700000 2 Cauca
400 Andres 3 800000 3 Cali
500 Juan 2 700000

600 Carlos 1 900000 Antecesora
700 Ruth 2 700000
Sucesora
Delete from ciudades
Where ciudad=2;
Delete from empleados
Where cedula=400;
Select * from empleados;
Codigo:
use base1;
create table ciudades
ciudad int,
nomciudad varchar(30),
primary key (ciudad)
);
create table empleados
(
ced int,
nom varchar(20),
ciudad int,
sueldo int,
primary key(ced),
foreign key(ciudad) references ciudades(ciudad)
);
Use base1;
insert into ciudades(ciudad,nomciudad)
values (1,'Yopal');
values (2,'Cauca');
values (3,'Cali');
insert into empleados(ced,nom,ciudad,sueldo)
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 * from ciudades;
select * from empleados;
CODIGO CON ELIMINAR

delete from empleados
where cedula >500
and sueldo>700000;
select ‘---------------------------’;
delete form empleados
where cedula<500;
selec * from empleados;
select ‘---------------------------’;
delete from empleados ;
selec * from empleados;
Codigo con los eliminar
use base1;
ciudad int,
);
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);
select '---------------------------';
Where ced=400;
select '---------------------------';
where ced >500
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 //
create procedure proce1(in suelaux int)
begin
select * from empleados
where ced >suelaux;
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);
Call proce1 (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:
use base1;
ciudad int,
);
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);
select '---------------------------';
Where ced=400;
select '---------------------------';
where ced >500
and sueldo>700000;
select '---------------------------';
where ced<500;
select '---------------------------';
Delimiter //
create procedure proce1(in suelaux int)
begin
select * from empleados
where sueldo >suelaux;
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);
Conclusion:
Los reportes sirven para poder sacar los atributos
CLASE 16/09/2019
Procedimientos almacenados con manejo de “cursores”
Delimiter //
Créate procedure proce3()
Begin
Declare suel1,ced1 int ;
Declare fin int default 0;
Declare cursor1 cursor for select ced , suel from emple;
Declare continue handler for not found set fin=1; open cursor1
Repeat
Fetch cursor into ced1,suel1;
If suel1<850000 then
Update emple set suel = 900000 where ced =ced1;
End if ;
Until fin=1 end repeat;
Close cursor1;
End;
//
Delimiter ;
Call process ();
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”
Ced Nom Suel
100 Pedro 1000000

200 Maria 820000
300 Juan 850000
400 Carlos 9000000
500 Ruth 800000
600 Clara 920000
Fetch cursor1 into ced1,suel1; (pone ced y suel1 dentro de ced1 y suel1)
fetch :Lee cada registro de el cursor
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
use base1;
create table emple
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 //
create procedure proce3()
begin
declare suel1,ced1 int;
declare fin int default 0;
declare cursor1 cursor for
select ced, suel from emple;
declare continue handler for not found set fin=1;
open cursor1;
repeat
fetch cursor1 into ced1,suel1;
if suel1 < 850000 then
update emple set suel = 900000 where ced = ced1;
end if;
until fin = 1 end repeat;
close cursor1;
end;
//
delimiter ;
call proce3();
select * from emple;
Conclusion:
El cursor es dinamico se abre tanto como el numero de datos de el select

CLASE 23/09/2019
Dependencia funcional exclusiva (DFE)/lógica multifuncional del Core de la misión del negocio
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
idcli(pk), nomcli, telcli,Profecli(FKD)
(2) conjunto de la clase secundaria Profesión clientes:
Profecli (PK), nomprof
(3) conjunto de la clase principal facturas: (solucionar la dependencia funcional exclusiva):
nofac(pk), fechfac,totval sucur(fkd), idcli(FKP)
(4) conjunto de la clase secundaria sucursales:
sucur(pk), direccion, telefono
(5) conjunto de la clase principal sorteos: (solucionar la dependencia funcional exclusiva):
IDsorteo(PK), fechasorteo, tiposorteó(FKD), idcli(FKP)
(6) conjunto de la clase secundaria tipo sorteo:
Tipo sorteo (PK), nomsorteo

Modelo relacional
Sucursales
Facturas
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
DFE(3FN) /contexto multifuncional extendido
Contexto:” ministerio de Garrotazo”
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
Marca FKD Tipoinfr FKD

Ri: DFE
valinfr
1
Modelo de conjuntos
(1) conjunto de la clase principal propietarios:
Idpro (PK), nompro, telpro, Profpro (FKD)
(2) conjunto de la clase secundaria Profesión propietario:
Profpro (PK),nomprof
(3) conjunto de la clase principal inmueble: (solucionar la dependencia funcional exclusiva):
Nromatr (PK),dirinm,valorinm,localidad (FKD),idpro (FKP)
(4) conjunto de la clase secundaria localidad
Localidad(PK),nomloca
(5) conjunto de la clase principal impuestos: (solucionar la dependencia funcional exclusiva):
Nroreci (Pk), fechapag, valpa, banco(fkd), nromatr(FKP)
(6) conjunto de la clase secundaria banco:
Banco (PK), nombanco
(7) conjunto de la clase principal vehículos: (solucionar la dependencia funcional exclusiva):
Placa (PK), modelo,marca(FKD), idpro (FKP)
(8) conjunto de la clase marca
marca(PK),marcacar
(9) conjunto de la clase principal infracciones: (solucionar la dependencia funcional exclusiva):
Reconft(PK), fechainfr, tipoinfr(FKD), valorinfr, placa(FKP)

(10) conjunto de la clase secundaria tipo infracción:
Tipoinfr(PK), nominfrac
local
Modelo relacional
Localidad(PK)
banco
Impuestos nomloca
Banco (PK),
Nroreci (Pk), nombanco
fechapag,
valpa,
banco(fkd),
nromatr(FKP)
inmuebles propietarios
Nromatr(PK) Idpro (PK)

dirinm, nompro Profesión
Valorinm Telpro propietario
,localidad (FKD) Profpro (FKD)
Profpro (PK)
nomprof
,idpro (FKP)
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
banco nombanco localidad nomloca
Entidad Local
Entidad
banco
banco
nompro telpro profpro

Nroerci localidad
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
Con la DFE resuelvo la ley de la reflexividad
1 FN contexto de la lógica del Core del negocio asignación de atributos por ley de armtorm
2fn definir PK y FKD
3FN solucionar DFE por la ley de la reflexividad (cuando se refleja como clase sucesora como PK de una
clase antecesora)
Llaves secundarias son incluide
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
(1) conjunto de la clase principal facturas:
Nofac(PK), fechafac, idcliente FKD
(2) conjunto de la clase secundaria cliente:
Idcliente(PK), nomcliente, telcli
(3) conjunto de la tabla facturas-artículos:
(nofac(FKP)+codigoart(FKP)) (PKE), cantidadven
Se resolvió la reflexividad Atributos que dependen estrictamente de las dos

partes de la llave (4FN)
(4) conjunto de la clase principal artículo:
Codart(PK), nomart, valorart, tipoart (FKD)
(5) conjunto de la clase secundaria tipo artículo:

5FN atributos y depende estrictamente de la 2
parte de la llave primaria
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)
4FN atributos que dependen de las 2 partes de la tabla
5 Fn atributos que dependen de la 2 parte de la llave
CLASE 02/10/2019
DFNE (4FN-5FN)
PRIMARY KEY (UNA),” MULTIATRIBUTO”

nofac fechafac idcli
idcli Nomcli telcli
Entidad
facturas Entidad
clientes
Relación
fuerte
Fact-art
codart tipoart tipoart nomart
Entidad Entidad tipo

articulos articulos
nomart
valorart
entidad
Cuando se inscribe el rombo dentro del

rectángulo se dice que la relación fuerte deberá Agregación
ser agregada como una entidad
El rombo es la relación fuerte||||

deberá se agregada como una
entidad
Modelo ddl

use base1;
idcli int,
nomcli varchar(20),
telcli int,
primary key(idcli)
);
create table tipoartculo
(+
tipoart int,
nomart varchar(20),
primary key(tipoart)
);
nofac int,
fechfac date,
idcli int,
primary key(nofac),
foreign key (idcli)references clientes(idcli)
);
create table articulos
codart int,
nomart varchar(20),
valorart int,
tipoart int,
primary key(codart),
foreign key (tipoart)references tipoarticulo(tipoart)
);
create table factart
nofac int(8),
codart int(4),
cantvend int(4),
primary key(nofac,codart),
foreign key (nofac)references facturas(nofac),
foreign key (codart)references articulos(codart)
);
Use base1;
insert into clientes(idcli, nomcli,telcli)
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
(1) conjunto de la clase principal estudiantes:
Idest PK,Nomest,telest, codcarrera FKD
(2) conjunto de la clase secundaria codcarrera:
Codcarrera PK, nomcarrera
(3) conjunto de la tabla estudiantes-materias:
(idest(FKP)+codcarrera(FKP)) (PKE), calificacion

(4) conjunto de la clase principal materias:
Codmat PK,Nomat,Numcredi,calificacion,codfacul FKD

(5) conjunto de la clase secundaria codfacul:
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
idest codmatiera
codmateria nommater
Entidad
estudiantes
Entidad
codmateria
telest nomest
Relación
fuerte codfacul codfacul facultad
codmat
Estu-mater
Entidad Entidad
materias codfacul
numcredi calificacion nommat

DDL
use base1;
idcli int,
nomcli varchar(20),
telcli int,
primary key(idcli)
);
create table tipoartculo
(+
tipoart int,
nomart varchar(20),
primary key(tipoart)
);
nofac int,
fechfac date,
idcli int,
primary key(nofac),
foreign key (idcli)references clientes(idcli)
);
create table articulos
codart int,
nomart varchar(20),
valorart int,
tipoart int,
primary key(codart),
foreign key (tipoart)references tipoarticulo(tipoart)
);
create table factart
nofac int(8),
codart int(4),
cantvend int(4),
primary key(nofac,codart),
foreign key (nofac)references facturas(nofac),
foreign key (codart)references articulos(codart)
);
Use base1;
insert into clientes(idcli, nomcli,telcli)
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
Idcli PK, nomcli, telcli, profcli FKD
(2) conjunto de la clase secundaria profcli:

profcli PK, nomprof
(3) conjunto de la clase principal facturas:
Nofac PK, fechfac,totfac, sucur FKD,IDCLI FKP
(4) conjunto de la clase secundaria sucur:
Sucur PK, ciudad
(5) conjunto de la tabla facturas-articulos:
(nofac(FKP)+codart (FKP)) (PKE), cantvednart

(6) conjunto de la clase principal artículos:
Codart PK, nomart, valunart, cantvendart, tipoart FKD

(7) conjunto de la clase secundaria tipoart:
Tipoart PK, nomart
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

Memorias

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Memorias

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD CENTRAL

FACULTAD DE INGENIERÍA, CIENCIAS BÁSICAS

CARRERA DE INGENIERÍA DE SISTEMAS

DOCUMENTACIÓN DISEÑO DE BASES DE DATOS

Daniel David Ramos García

JHON JAIRO LONDOÑO PEREZ

1. sistema (los procesos):

sobre el “diseño” hay que decir que existen 2 tipos de diseños:

2.1.1 diseño relacional:

2.1.1.1 bases de datos relacional:

Cedula Nombre Profesión Profesión Definición

2.1.2 diseño documental:

2.1.2.1 bases de datos documental

string: archivo plano

- creacion de las tablas de diseño

- manejo de los datos dentro de las tablas

lo anterior trasciende cuando se incurre en la programacion a traves de:

-procedimientos almacenados elementales

-procedimientos almacenados con cursores

-procedimientos almacenados con trigger

entrada  proceso  salida

lectura, abstracción, modelo de la logica.

narrativa del cliente:

1.1 lectura y abstraccion:

-que se quiere controlar

clase1 y clase2, son los escenarios que se quieran

-primario: recursos naturales: agua, ganado, piscicultura...

-secundario: industria (maquinaria de explotación o transformacion), este tambien aprovecha lo primario

forma normal 1fn y segunda

forma normal 2fn

se construye de abajo hacia arriba y se lee de arriba hacia abajo.

no se ven por logica M 1

representacion tradicional multifuncional simple:

representacion tradicional multifuncional extendida:

la normalizacion es un ejercicio y permite garantizar, la “no redundancia” de la informacion, la “funcionalidad” de servicios

-primera forma normal 1fn:

las dependencias funcionales tambien de amstrong, pueden ser de 2 tipos:

dependencia funcional exclusiva – dfe:

nombre numero factura(pk)

fecha nacimiento fecha factura 1FN

lugar nacimiento (fkd) valor total

(1) conjunto de la clase principal clientes:

idcliente(pk), nombre, fecha nacimiento, lugar nacimiento(fkd)

(2) conjunto de la clase secundaria lugares:

(3) conjunto de la clase principal facturas: (solucionar la dependencia funcional exclusiva):

numerofactura(pk), fechafact,valortotal, sucursal(fkd), idcliente(FKP)

(4) conjunto de la clase secundaria sucursales:

sucursal(pk), direccion, telefono

-Construcción del diseño: resolver los tipos de dependencias funcionales (DFE,

Entidad Entidad Entidad

SÉPTIMA CLASE - FECHA: 26/08/2019

Peter Chenn: Disyunción

Peter Chenn: Exclusividades FKD

cual estamos trabajando) genere 2 nuevas facturas

insert into clientes(idcli,nomcli,fechnac,lugnac)

insert into sucursales(sucur,dir,tel)

values(9,&#39;av 6 calle 40&#39;,4120);

insert into facturas (nofac,fechfac,valt,idcli,sucur)

insert into facturas (nofac,fechfac,valt,idcli,sucur)

create table Test(id integer, title varchar(100));

insert into Test(id, title) values(1, &quot;Hello&quot;);

select * from Test;

-- Your code here!

values(9,'av 6 calle 40',4120);

insert into Test(id, title) values(1, "Hello");

values(10,'av 6 calle 40',4120);