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 ......................................................................................................................................... 4
12/08/2019 ......................................................................................................................................... 6
14/08/2019 ....................................................................................................................................... 10
Fecha: 21/08/2019 ............................................................................................................................ 12
Séptima Clase - Fecha: 26/08/2019 .................................................................................................. 14
Fecha: 28/08/2019 ............................................................................................................................ 16
- Fecha: 02/09/2019 .......................................................................................................................... 25

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 normalizacion

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
CLASE2
1
R
id (pk)

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);

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

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);

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

values(204,'2019/10/18',40000,100,10);

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

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
Clientes

Idcli PK
Nomcli
Teleli
Activ FKD

Modelo relacional

vehiculos

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;

create table actividad

activ int,

infoactiv varchar(30),

primary key (activ)

);

create table clientes

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”:

Select t1.ced,t1.nom,t1.tel,

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”

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

On t1.cargo=t2.cargo and t1.estrato=t3.estrato ;

Código :

create database base1;

use base1;

create table cargos

cargo int,

nomcargo varchar(30),

primary key (cargo)

);

create table estratos

estrato int,

nomestrato varchar(30),

primary key (estrato)

);

create table clientes

(
 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