UNIDAD 1 - BASES DE DATOS TRANSACCIONALES Y RELACIONALES

FASE 1 - MODELAMIENTO: MODELAR, DISEÑAR Y DESARROLLAR BASES DE

DATOS RELACIONALES

PARTICIPANTES:

CC: 1005825005 – ANDRES FELIPE ZABALA MORENO

CC: 1103950584 – MARÍA CAMILA MERCHÁN

CC: 73558594 – GALO JOSE MUÑOZ MARTINEZ

CC: 98.713.087 – FARLEY GIOVANNI GONZALEZ

GRUPO No. 301125_23

Tutor:

MARIANO ESTEBAN ROMERO

Universidad Nacional Abierta y a Distancia – UNAD

Escuela Ciencias básicas, tecnología e ingeniería

Programa Ingeniería de Sistemas

Base de datos avanzada 301125

Periodo 16-01

Colombia

2020
 TABLA DE CONTENIDO
INTRODUCCIÓN.............................................................................................................................3

RESULTADO DE LA ACTIVIDAD................................................................................................4

Publicación del rol escogido por el estudiante...............................................................................4

Selección y respuesta de la pregunta motivadora...........................................................................4

Proyecto para desarrollar................................................................................................................6

A. Análisis de requerimientos..................................................................................................7

Formato 1: Definición y Descripción de Entidades....................................................................7

Formato 2: Descripción de atributos y sus restricciones............................................................9

Formato 3: Matriz de Relaciones..............................................................................................10

Formato 4: Descripción de las relaciones determinadas en la Matriz de Relaciones...............11

B. Diseño modelo Entidad Relación y modelo Relacional....................................................13

1 - Modelo Entidad Relación....................................................................................................13

2 - Modelo Relacional..............................................................................................................14

Técnicas de normalización.......................................................................................................14

C. Desarrollo de la base de datos relacional..........................................................................16

Evidencias de la participación en el foro......................................................................................24

CONCLUSIONES...........................................................................................................................26

BIBLIOGRAFÍA.............................................................................................................................27
 INTRODUCCIÓN

El presente informe se presenta busca mostrar el diseño y desarrollo de bases de datos

relacionales, mediante algunos ejercicios; Este busca definir una base de datos que ayude a

resolver los requerimientos planteados en los ejercicios de la actividad, detallando tablas creadas

con base a los requerimientos del problema, los campos de cada tabla y sus atributos, también se

definen las relaciones entre ellas, definiendo llaves primarias y foráneas.

También se puede se implementa la ejecución de base de datos, bajo lenguaje SQL del script DLL

y lenguaje DML que se hace por medio del aplicativo https://apex.oracle.com/, una herramienta

RAD que se ejecuta con una base de datos Oracle, permitiendo desarrollar prototipos de

aplicaciones WEB de forma segura y rápida.

 RESULTADO DE LA ACTIVIDAD

Publicación del rol escogido por el estudiante.

Nombre Estudiante Rol Valoración del

Desempeño del Rol
Estudiante 1 Andrés Felipe Zabala Moreno Moderador Calificar de 1 a 5
Estudiante 2 María Camila Merchán Evaluador 5
Estudiante 3 Galo José Muñoz Colaborador 4,5
Farley Giovanni Gonzalez Londoño Creativo 4
Estudiante 5 Investigador Calificar de 1 a 5

Selección y respuesta de la pregunta motivadora.

Nombre Estudiante 1: ANDRES FELIPE ZABALA

Pregunta 1: ¿Cuál es la diferencia entre base de datos Transaccionales y base de datos
relacionales?
Una de las principales diferencias es que una base de datos relacional es una colección de
elementos de datos organizados en un conjunto de tablas formalmente descritas, allí podemos
acceder a los datos y modificarlos sin que tengamos que reorganizar tablas; cada tabla en esta
base de datos está relacionada con un atributo de otra entidad, cada tabla se identifica con un
atributo que lo hace único o lo diferencia de las demás entidades el cual es su clave principal.
Esta base de datos es relativamente fácil de crear y de acceder a ella. La base de datos
transaccional no tiene directamente una relación entre tablas, allí tenemos una información
generalizada y así podemos trabajarla y leerla. Otras diferencias muy importantes es que una
base de datos transaccional es muy rápida en todos sus procesamientos ya que maneja
milisegundos, es demasiado fiable con la información que contiene así brinda bastante
seguridad a sus usuarios sobre todo al momento de realizar una transacción y así cualquier
proceso erróneo lo detiene de inmediato, por eso su acceso es muy restringido y no acepta
información distinta a la establecida.

En conclusión, su diferencia va entre la información en las tablas, la eficacia y la fiabilidad.

Nombre Estudiante 2: MARIA CAMILA MERCHAN
Pregunta 2: ¿Qué se considera una base de datos relacionales?
Una base de datos relacional es una compilación de elementos de datos con relaciones
predefinidas entre ellos, los cuales se organizan como un conjunto de tablas con columnas y
filas, de la cuales las tablas se utilizan para almacenar información sobre los objetos que se van
a representar en la base de datos, cada columna de una tabla guarda un determinado tipo de
datos y un campo almacena el valor real de un atributo. Las filas de la tabla representan una
recopilación de valores relacionados de una entidad en la que cada fila de una tabla podría
marcarse con un identificador único denominado clave principal, mientras que filas de varias
tablas pueden relacionarse con claves extranjeras, de tal manera se puede conseguir acceso a
estos datos de muchas formas diferentes sin reorganizar las propias tablas de la base de datos.

El modelo relacional para bd se caracteriza por la claridad, tiene una base matemática y ha
probado su eficacia en la práctica, pero a pesar de todo el almacenamiento de datos en tablas
estructuradas no se ha apropiado a las necesidades de la tecnología de la información actual.

Asimismo son fundamentalmente la gestión de grandes volúmenes de datos en el marco de los

análisis de big data y el almacenamiento de datos abstractos los factores que saturan la
capacidad de los sistemas relacionales y es necesariamente aquí donde los sistemas
especializados, como las BD basadas en objetos o los conceptos desarrollados en la senda del
movimiento NoSQL, muestran su superioridad, si bien no es posible prescindir totalmente del
modelo relacional, las bases de datos relacionales extienden todo su potencial especialmente en
aquellos ámbitos corporativos ejercidos por el procesamiento de datos de transacciones.
Nombre Estudiante 3: GALO JOSE MUNOZ
Pregunta 3: ¿Cuál es la importancia del proceso de normalización en bases de datos?

Debemos recordar que la normalización es el proceso mediante el cual se toman decisiones en

sobre una base de datos con el objetivo de recoger de la manera más adecuada la información
de nuestra entidades y las relaciones entre ellas que conforman nuestra bases de datos , lo cual
lo podemos identificar desde el diagrama de E-R. por lo tanto considero que este proceso es de
vital importancia ya que conseguiremos mayor eficacia en la manipulación de nuestros datos y
a si se obtendrá una estructura muy bien organizada, de tal forma que serán manipulables
fácilmente, permitiendo realizar modificaciones a futuro sin mayores problemas, Además
favorecer la integridad de los datos, evitar lo máximo la posibilidad de introducir datos
repetidos o nulos, vale resaltar la integridad de la entidad lo cual pretende que cada entidad que
se guarda en la base de datos sea identificable de un modo único, es decir, que evitemos la
información redundante. La integridad de entidad define una fila o registro como una única
ocurrencia para una tabla en particular.

Puedo concluir que la importancia del proceso de normalización consiste en realizar la

distribución de los datos correctamente en las tablas que conforman nuestra base de datos sin la
necesidad de perdida de los datos, aunque se aumenten los números de las tablas intermedias.
Nombre Estudiante 4:
Pregunta 4: ¿Cuál es la diferencia entre el lenguaje de definición de datos y el lenguaje de
manipulación de datos?

Nombre Estudiante 5:
Pregunta 5: ¿Qué son las formas normales y cuál es su finalidad?
 Para mejorar el desempeño de una base de datos, así como evitar redundancia en la información
que contiene y, en consecuencia, generar condiciones para un mejor diseño, el analista de
sistemas debe conocer las formas de normalización y condiciones en las que la
desnormalización es recomendable.

En este tema se abordarán aspectos conceptuales básicos relacionados con las formas de
normalización, generalmente utilizadas en el análisis, desarrollo e implementación de sistemas
de bases de datos (1FN, 2FN y 3FN); además, particularidades y consideraciones que el analista
deberá evaluar para decidir normalizar a mayor grado una base de datos, mantener su forma
normal actual o la desnormalización en un modelo relacional.
Su finalidad es para que una tabla sea considerada una relación tiene que cumplirse lo siguiente:

1. Cada tabla tiene que tener un nombre único

2. No puede haber dos filas iguales – No se permiten duplicados
3. Todos los datos en una columna deben ser del mismo tipo

En conclusión, la normalización es una técnica utilizada para diseñar tablas en las que las
redundancias de datos se reducen al mínimo. Las primeras tres formas normales (1FN, 2FN y
3FN) son las más utilizadas. Desde un punto de vista estructural, las formas de mayor nivel son
mejores que las de menor nivel, porque aquellas producen relativamente pocas redundancias de
datos en la base de datos. En otras palabras, 3FN es mejor que 2FN y ésta, a su vez, es mejor
que 1FN. Casi todos los diseños de negocios utilizan la 3FN como forma ideal.

Proyecto para desarrollar

Un grupo de 5 ingenieros de la Universidad Nacional Abierta y a Distancia UNAD, requieren

diseñar una base de datos que sea de utilidad para concesionarios de automóviles. Un
concesionario puede vender automóviles de varias marcas (por ejemplo, Audi y Volkswagen).
Sobre los automóviles se desea mantener la siguiente información: marca, modelo, precio,
descuento (si es que lo tiene), los datos técnicos (potencia fiscal, cilindrada, etc.); al igual que
otras características importantes y accesorios. El concesionario tiene siempre automóviles de
varios modelos en stock (cada uno se identifica por su número de bastidor). Cuando se vende un
automóvil se quiere saber quién lo ha vendido; también se desea saber el precio que se ha cobrado
por él y el modo de pago: al contado o mediante financiera. Se debe almacenar la información
sobre la fecha de entrega, matrícula y si era de stock o se ha tenido que encargar a fábrica. De los
vendedores se almacenarán los datos personales (nombre, NIF, domicilio, etc.) y las ventas
realizadas.
Para el desarrollo del proyecto, el grupo de 5 ingenieros de sistemas deben:

Importante: se espera que cada estudiante desarrolle mínimo 2 entidades y le

aplique el proceso.

A. Análisis de requerimientos

Formato 1: Definición y Descripción de Entidades

Entidad o Tipo Justificación, Ejemplo de Ejemplares Extensión INTENCION

de Entidad explicación de su (Instancias)
existencia en el
Mundo del Problema
Andrés Felipe Zabala Moreno
Vendedores Es importante porque  Claudia Moreno 150 Realizar ventas
el concesionario debe  Julián Perdomo y
tener un registro de  Vanessa Ramírez asesoramiento
los vendedores con  Marcela Cárdenas a cambio de
los que cuenta y  Fredy Manjarrez una
realizan las ventas. remuneración
Autos_Vendido Es una de las tablas  Audi 1000 Ser un bien
s más importantes ya  Chevrolet que pueda
que se lleva un  Renault adquirir un
registro de los autos  Mazda cliente
que el concesionario  Mercedes-Benz
ha vendido y el valor
de su venta
Proveedores Es indispensable ya  Johann Rudi 150 Surtir a los
que se lleva un el  Evan Henderson diferentes
registro de donde  Edith Barraud. almacenes del
llegan cada vehículo  Kenji Rokujo. concesionario
y herramientas al  Edwin Lehner a cambio de
concesionario y una
quien es el encargado remuneración
de este proceso y aumento de
ventas
Galo José Muñoz
Cliente Es muy  Raúl Pérez 1000 Comprar los
indispensable que es  Milena López diferentes
el que genera los  Martha Rodríguez vehículos con
ingresos y muy  Carlos Avila los que cuenta
importante tener el  Edwar Orozco del
registro de los concesionario
clientes que vistan y y adquirir
compran el producto servicios de él
Almacén Es una tabla  Barrio Saturno 40 Recibir la
requerida para saber mercancía o
en qué punto se vehículos que
encuentra ubicado el llegan por
almacén del parte de los
concesionario proveedores
 para así tener
un punto de
venta en el
departamento.
MARIA CAMILA MERCHÁN RIVERA
Admin Importante porque  Luis Cueva 100 Tener control
registra los datos del  Sofía Alvares del personal
empleado que se  Miguel Posada administrativo
encarga de la parte y funciones en
administrativa del el sistema.
concesionario
Factura Importante registra  301 20 Tener datos del
datos de la compra y  302 básicos como
permite mostrar al 303 fecha,
cliente el gasto de la encargado,
compra vendedor, etc.
Detalle_Factura Importante registra  3001 20 Registrar datos
datos de compras  3002 de compra
más detallada de lo 3003 como cantidad,
que refiere a subtotal,
cantidad, subtotal, servicios, etc.
etc.
Nombre Estudiante 4:

Nombre Estudiante 5:
Departamento Es importante para  Tolima 40 Llevar la
saber en qué parte  Antioquia distribución de
del país tiene puntos  Cundinamarca los diferentes
de venta el  Valle puntos de
concesionario Risaralda venta
Revisiones Es importante llevar  Cambio de filtro 30 Hacer
el conteo de las veces  Revisiones de reparaciones a
que llevan un frenos los
vehículo a realizar  Cambio de Aceite inconvenientes
una revisión y que  Revisión de Luces del vehículo a
tipo Revisión de cambio una
amortiguación remuneración
mínima y
llevar un
conteo
Formato 2: Descripción de atributos y sus restricciones.

Nombre Atributos Identifi Nombre Tipo Tama Obligatori Cardinali Restricciones adicionales
Entidad cador dominio de ño edad dad
Único Dato (Si/No) (1 o Lista de Rango Restricció
(UID) (Texto Muchos) Valores de n de
, Valore Control
Núme s
ro,
Fecha
)
No_Bastidor X No_Bastidore N 5 Si 1 -- --- ---
s
Marca Marcas T 20 Si 1 -- --- ---
Autos_Vendi Modelo Modelos T 15 Si 1 -- --- ---
dos Color Colores T 15 Si 1 --- ---
Precio Precios N 30 Si 1 --- --- ---
Modo de Modo de T 15 Si 1 --- --- ---
Pago Pagos
Fecha_Entreg Fechas_Entre F Si 1 --- --- ---
a gas
Modo_Pedid Modo_Pedido T 2 Si 1 Contad --- ---
o s o,
Financi
era
Descuento Descuentos T 5 Si 1 --- --- ---
Total_Valor Total_Valores N 40 Si 1 --- ---- ---
Cod_Vended X Cod_Vendedo T 5 Si 1 --- ---
or res
Nombre_Ven Nombre_Ven T 15 Si 1 --- ---
dedor dedores
Apellido_Ven Apellido_Ven T 15 Si 1
Vendedores dedor dedores
Ventas_Reali Ventas_Realiz N 22 Si M
zadas adas
Departament Departament T 25 Si 1
o os
Ciudad Ciudades T 25 Si 1

Teléfono Teléfonos N 10 Si M

Cod_NIT Cod_NIT 9 Si 1

Doc_Identific X Doc_Identific N 15 SI 1 -- --- ---

ación ación
Proveedores Nombre_Pro Nombre_Prov T 15 SI 1 -- --- ---
veedor eedores
Apellido_Pro Apellido_Prov T 15 Si 1
veedor eedores
Teléfono Teléfonos N 10 Si M
Ciudad Ciudades T 15 Si 1
País Países T 15 Si 1
Email Emails T 30 No M
Cod_NIT
Departament Cod_Departa x Cod_Departa N 5 Si 1
o mento mentos
Nombre Nombres T 20 Si 1
No_Identifica x No_Identifica N 15 Si 1
cionC cionCs
Clientes Nombre_Clie Nombre_Clien T 15 Si 1
nte tes
Apellido_Clie Apellido_Clie T 15 Si 1
nte ntes
Direccion Direcciones T 40 Si 1
Departament Departament T 15 Si 1
o os
Ciudad Ciudades T 15 Si 1
Telefono Telefonos N 10 Si M
Cod_Vended Cod_Vendedo N 5 Si 1
or res
Modo_Pago Modo_Pagos T 15 si 1
Cod_Revision x Cod_Revision N 5 Si 1
es
Revisiones No_Revision No_Revisione N 1000 Si M
s
Cambio_Acei Cambio_Aceit T 2 Si 1 SI,NO
te es
Revisiones_F Revisiones_Fr T 2 Si 1 SI,NO
 renos enos
Cambio_Filtr Cambio_Filtro T 2 Si 1 SI,NO
o s
Otro Otros T 40 Si M
No_Bastidor No_Bastidore N 5 Si 1
s
Cod_NIT Cod_NITS T 12 Si 1 18562
Almacen Dirección Direcciónes T 30 Si 1
Telefono Telefonos N 10 Si M
Solo
Nit_admin X Nits_admin N 5 Si 1 101 2-5 permite
números
Solo
Nombre_ad Nombresadmi
Admin   T 30 Si 1 Luis 3-30 permite
min n
texto
P_ Solo
Apellido_ad
  Apellidoadmi T 30 Si 1 Cueva 3-30 permite
min
ns texto
Solo
Adminis
Cargo_admin   Cargos_admin T 30 Si M  4-30 permite
trador
texto
Solo
Cod_factura x Cod_facturas N 10 Si 1 301 2-10  permite
numero
Solo
Factura Nit_admin   Nits_admin N 10 Si 1 101  2-10 permite
numero
Solo
No_Identifica No_Identifica 104049
  N 15 Si 1  2-10 permite
cionC cionCs 4116
numero
Solo
Cod_vended Cod_vendedo
  N 5 Si 1 4568  2-5 permite
or res
numero
Solo
Nombre_ven Nombrevende
  T 30 Si 1 Julian  3-30 permite
dedor dores
texto
Permite
Matricula   Matriculas N, T 10 Si 1 TOY347  4-10 números
y texto

Fecha_ex
Fecha_expe   Fechas_expe F 30 Si 1 03/11/2  3-30
pedición
0
Solo
Num_detafac
X Ids_detafact N 10 Si 1 3001 2-10 permite
t
numero
Detalle_Fact Solo
ura Cod_factura   Id_facturas N 10 Si 1 301 2-10 permite
numero
Solo
Cantidad   Cantidades N 10 Si M 1  1-10 permite
texto
Solo
271600
Total   Totales N 10 Si 1  3-10 permite
000
numero

Formato 3: Matriz de Relaciones

Alma Automóv Proveed Departa Detalle_f

Vendedor Cliente Revisión Admin Factura
cen il or mento actura

Almacen R1 R2 R3 R4

Automovil R5 R6 R7

Vendedor R8

Cliente R9

Revisión

Proveedor

Departame
nto
Admin R10

Factura R11

Detalle_fa
ctura
Formato 4: Descripción de las relaciones determinadas en la Matriz de Relaciones

Pregunta
Pregunta para para
determinar determinar Relación es Ayuda a Identificar
Rta. Rta. Observación/Restricci
Relación Entidad 1 Rol Entidad 2 Opcionalidad Cardinalida Transferible Grado entidades
Opc. Card. ones/Atributos
(Preguntar si d (Si/No) Participantes
está obligado) (Pregunta
CUANTO )

 ¿Un
¿Un almacén Esta relación modela
almacén
está obligado a un hecho importante
Almacen Tiene Vendedor Si  cuantos  M Si 
tener un que sucede en el
vendedore Las dos entidades
vendedor? proceso que estamos
s tiene? participantes se
R1 1:M  analizando y es que en
¿Un identifican
¿Un vendedor almacén debe disponer
vendedor a plenamente 
Pertene está obligado a de vendedores para
Vendedor Almacen No cuantos 1 Si
ce pertenecer a un atender a los clientes
almacenes
almacén?
pertenece?
 
 ¿Un
¿Un almacén
almacén a Esta relación modela
está obligado a  
Almacen Compra Proveedor No  cuantos Si un hecho importante
comprar a un M 
proveedor que sucede en el
proveedor?  Las dos entidades
es les proceso que estamos
R2 N:M  participantes se
compra? analizando y es que un
identifican plenamente
¿Un almacén no está
¿Un proveedor
proveedor obligado a comprar a
Proveedo está obligado a
Surte Almacen No a cuantos N Si un proveedor
r surtir un
almacenes
almacén?
surte?
¿Un
¿Un almacén
almacén a
está obligado a
Pertene Departam cuantos Esta relación modela
Almacen pertenecer a un No M Si
ce ento departame un hecho importante
a un
ntos que sucede en el
departamento?  Las dos entidades
pertenece? proceso que estamos
R3 N:M participantes se
¿Un analizando y es que un
¿Un identifican plenamente
departame almacén puede tener
departamento
Departam nto otras sedes en otros
Tiene Almacen está obligado a No N Si
ento cuantos departamentos
tener un
almacenes
almacén?
tiene?
¿Un
¿Un almacén almacén Esta relación modela
está obligado a por un hecho importante
Almacen dirigido Admin Si  1  Si
ser dirigido por cuantos ad que sucede en el
 Las dos entidades
un admin? min es proceso que estamos
R4 1:M  participantes se
dirigido? analizando y es que un
identifican plenamente
¿Un admin está ¿Un admin almacén solo puede
obligado a a cuantos ser dirigido por el
Admin dirige Almacen Si M Si
dirigir un almacenes admin? 
almacén? dirige?
¿Un
automóvil Esta relación modela
¿Un automóvil
por un hecho importante
Autos_Ve está obligado a
Vendido Vendedor Si  cuantos  1 Si que sucede en el
ndidos ser vendido por
vendedore proceso que estamos
un vendedor?
s es  Las dos entidades analizando y es que el
R5 vendido?   1:M participantes se vendedor puede
¿Un identifican plenamente vender muchos
¿Un vendedor vendedor automoviles pero un
Autos_Ve está obligado a cuantos automóvil solo puede
Vendedor vender No M Si
ndidos vender un automovile ser vendido una vez
automóvil? s puede por el vendedor? 
vender?
¿Un
¿Un automóvil automóvil
Esta relación modela
Autos_Ve Compra está obligado a por
Cliente Si 1  Si un hecho importante
ndidos do ser comprado cuantos
que sucede en el
por un cliente? clientes es  Las dos entidades
proceso que estamos
R6 comprado?  1:M  participantes se
analizando y es que un
¿Un cliente identifican plenamente
¿Un cliente está cliente puede comprar
cuantos
Autos_Ve obligado a los automóvil que
Cliente Compra No automóvile M Si
ndidos comprar un desee
s puede
automóvil?
comprar?
 ¿Un
¿Un automóvil automóvil
Automovi está obligado a a cuantas  Esta relación modela
Pasa Revision Si 1  Si
l pasar a revisiones un hecho importante
revisión? puede que sucede en el
 Las dos entidades
pasar? proceso que estamos
R7 1:M  participantes se
¿Una analizando y es que un
identifican plenamente
¿Una revisión revisión a automóvil después de
realizad está obligada a cuantos ser comprado tiene
Revision Automovil Si M Si
a ser pasada al automóvile que pasar a revisión
automóvil? s es
realizada?
R8 Vendedor vender Cliente ¿Un vendedor No ¿Un M  Si    Las dos entidades  Esta relación modela
está obligado a vendedor a  1:M participantes se un hecho importante
vender a un cuantos identifican plenamente que sucede en el
cliente? clientes le proceso que estamos
 puede
vender? 
analizando y es que un
¿Un cliente
¿Un cliente está vendedor puede
a cuantos
obligado a venderle a muchos
Cliente Compra Vendedor No vendedore 1 Si
comprarle a un clientes
s les
vendedor?
compra?
¿Un cliente está ¿Un cliente Esta relación modela
obligado a cuantas M un hecho importante
Cliente Recibe Factura No Si
recibir una facturas que sucede en el
factura? recibe? Las dos entidades proceso que estamos
R9 ¿Una 1:M participantes se analizando y es que el
¿Una factura
factura en identifican plenamente cliente puede recibir
Generad está obligada a
Factura Cliente Si cuantos 1 Si muchas facturas y una
a ser generada al
clientes es factura es generada a
cliente?
entregada? un solo cliente
¿Un Admin está
¿Un admin
obligado a
cuantas
imprimir Esta relación modela
Admin Imprime Factura Si detalle_fac M Si
detalles en la un hecho importante
turas
factura del que sucede en el
imprime? Las dos entidades
cliente? proceso que estamos
R10 1:M participantes se
¿Un analizando y el
identifican plenamente
La factura está detalle_fac detalle_factura solo
Detalle_f Imprimi obligada ser tura en puede ser imprimida
Admin Si 1 Si
actura da imprimida por el cuantos por el admin
Admin? admin es
imprimida?
¿Una
¿La factura está factura Esta relación modela
Detafactu
Factura Tiene obligada a tener Si cuantos M Si un hecho importante
ra
Detafactura? detafatura que sucede en el
Las dos entidades
tiene? proceso que estamos
R11 1:M participantes se
¿Un analizando y es que
¿Un Detafactura identifican plenamente
detafactura una factura puede
Detafactu está obligado a
Pertenece Factura Si en cuantas 1 Si tener muchos
ra pertenecer a
facturas detafactura
una factura?
pertenece?
B. Diseño modelo Entidad Relación y modelo Relacional

1 - Modelo Entidad Relación

2 - Modelo Relacional
Técnicas de normalización

Se espera que los estudiantes relacionen las técnicas de normalización aplicadas.

Andres Felipe Zabala Moreno

En las tablas se puede observar que se presenta una situación en 3 relaciones que van muchos a

muchos por lo cual hay que realizar el proceso de normalización creando 3 tablas mas

(Vededores_Autos, Clientes_Autos, Prove_Almacenes)

Tabla Vendores_Autos

Cod_Vendedor
No_Bastidor
Tabla Clientes_Autos

Doc_IdentificacionC
No_Bastidor

María Camila Merchán Rivera

Tabla admin

Nit_admin Nombre_admin Apellido_admin Cargo_admin

101 Luis Cueva Gerente
102 Sofía Alvares Supervisor
103 Miguel Posada Coordinador

Tabla admin_concesionario

Nit_admin Cod_NIT
101 18562

Tabla admin_detafact

Num_detafact Nit_admin
3001 101
3002 101
3003 101
3004 101
3005 101

Tabla factura

Cod_fact Nit_adm No_Identific Cod_vended

Matricula Fecha_expe
ura in acionC or
301 101 1040494116 4568 TOY347 03/11/20
302 101 1040492546 4570 FXH455 11/12/19
303 101 1001741642 4567 VBC878 23/05/19
304 101 1040502143 4569 FUB604 23/05/19
304 101 98714039 4571 MFV3456 01/02/19

Tabla Detalle_factura
Num_detafact Cod_factura Cantidad Total
3001 301 1 271600000
3002 302 1 80655000
3003 303 1 35000000
3004 304 1 40500000
3005 305 1 29000000
Detafact_factura
Num_detafact Cod_factura
3001 301
3002 302
3003 303
3004 304
3005 305

C. Desarrollo de la base de datos relacional

Cada estudiante debe desarrollar mínimo 2 tablas de la base de datos.

Nombre Estudiante 1: ANDRES FELIPE ZABALA MORENO

Script DDL

AUTOS_VENDIDOS
create table autos_vendidos
(No_bastidor NUMBER(5) not null,
Marca VARCHAR (20) not null,
Modelo VARCHAR (4) not null,
Color VARCHAR (15) not null,
Precio NUMBER (30) not null,
Modo_pago VARCHAR (15) not null,
Fecha_entrega DATE not null,
Modo_Pedido VARCHAR (30) not null,
Descuento VARCHAR(5) not null,
Total_Valor NUMBER (30) not null,
constraint autos_vendidos pk primary key (No_bastidor)

);

PROVEEDORES
create table Proveedores
(Doc_identificacion NUMBER (15) not null,
Nombre_proveedor VARCHAR (15) not null,
Apellido_proveedor VARCHAR (15) not null,
Telefono NUMBER (10) not null,
Ciudad VARCHAR (15) not null,
Pais VARCHAR (15) not null,
Email VARCHAR (30) null,
Cod_NIT NUMBER (5) not null,
constraint proveedores_pk primary key (Doc_identificacion),
foreign key (Cod_NIT)
references almacen (Cod_NIT)

);

VENDEDORES
create table vendedores
(Cod_vendedor NUMBER (5) not null,
Nombre_vendedor VARCHAR (15) not null,
Apellido_vendedor VARCHAR (15) not null,
Ventas_Realizadas NUMBER (12) not null,
Departamento VARCHAR (25) not null,
Ciudad VARCHAR (25) not null,
Telefono NUMBER (10) not null,
Cod_NIT NUMBER (5) not null,
constraint vendedores_pk primary key (Cod_vendedor),
foreign key (Cod_NIT)
references almacen (Cod_NIT)

);

VENDEDORES_AUTOS
create table Vendedores_Autos
(Cod_vendedor NUMBER (5) not null,
No_bastidor NUMBER (5) not null,
foreign key (Cod_vendedor)
references vendedores (Cod_vendedor),
foreign key (No_bastidor)
references autos_vendidos (No_bastidor)

);

Script DML
AUTOS_VENDIDOS
insert all
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (87345, 'Audi', 'A3 2019', 'Rojo', 45000000,
'Contado o Financiera', '02-01-2019', 'Fabrica', '10%', 40500000)
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (76231, 'Chevrolet', 'Camaro 2020', 'Azul',
280000000, 'Contado o Financiera', '11-03-2020', 'Stock', '3%', 271600000)
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (83610, 'Renault', 'Clio Life 2019', 'Gris',
35000000, 'Contado o Fianciera', '05-23-2019', 'Stock', 'No', 35000000)
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (66793, 'Mazda', '3 2020', 'Rojo', 84900000,
'Contado o Financiera', '12-11-2019', 'Stock', '5%', 80655000)
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (73626, 'Chevrolet', 'Spark GT 2019', 'Negro',
29000000, 'Contado o Financiera', '02-05-2019', 'Stock', 'No', 29000000)
into autos_vendidos (No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega,
Modo_pedido, Descuento, Total_valor) values (27459, 'Mercedes-Benz', 'ClaseA 2020',
'Blanco', 95000000, 'Contado o Financiera', '05-02-2020', 'Fabrica', '2%', 93100000)

SELECT * from dual

PROVEEDORES
insert all
into proveedores (Doc_identificacion, Nombre_proveedor, Apellido_proveedor, Telefono,
Ciudad, Pais, Email, Cod_NIT) values (65803221, 'Johann', 'Rudi', 3124672104, 'Zwickau',
'Alemania', 'jhohan23@gmail.com', 18562)
into proveedores (Doc_identificacion, Nombre_proveedor, Apellido_proveedor, Telefono,
Ciudad, Pais, Email, Cod_NIT) values (93206783, 'Evan', 'Henderson', 3206782312, 'Detroit',
'Estados Unidos', 'Evan14@gmail.com', 18562)
into proveedores (Doc_identificacion, Nombre_proveedor, Apellido_proveedor, Telefono,
Ciudad, Pais, Email, Cod_NIT) values (68503778, 'Edith', 'Barraud', 3147893450, 'Boulogne',
'Francia', 'edithb67@gmail.com', 18562)
into proveedores (Doc_identificacion, Nombre_proveedor, Apellido_proveedor, Telefono,
Ciudad, Pais, Email, Cod_NIT) values (67999234, 'Kenji', 'Rokujo', 3132567692, 'Hiroshima',
'Japon', 'kenrokujo6@gmail.com', 18562)
into proveedores (Doc_identificacion, Nombre_proveedor, Apellido_proveedor, Telefono,
Ciudad, Pais, Email, Cod_NIT) values (93206789, 'Edwin', 'Lehner', 3045678912, 'Berlin',
'Alemania', 'edwlener45@gmail.com', 18562)
SELECT * from dual

VENDEDORES
insert all
into vendedores (Cod_vendedor, Nombre_vendedor, Apellido_vendedor, Ventas_realizadas,
Departamento, Ciudad, Telefono, Cod_NIT) values (04567, 'Claudia', 'Moreno', 7,
'Cundinamarca', 'Bogota', 3157892354, 18562)
into vendedores (Cod_vendedor, Nombre_vendedor, Apellido_vendedor, Ventas_realizadas,
Departamento, Ciudad, Telefono, Cod_NIT) values (04568, 'Julian', 'Perdomo', 4,
'Cundinamarca', 'Bogota', 3223458766, 18562)
into vendedores (Cod_vendedor, Nombre_vendedor, Apellido_vendedor, Ventas_realizadas,
Departamento, Ciudad, Telefono, Cod_NIT) values (04569, 'Vanessa', 'Ramirez', 2,
'Cundinamarca', 'Bogota', 3147421678, 18562)
into vendedores (Cod_vendedor, Nombre_vendedor, Apellido_vendedor, Ventas_realizadas,
Departamento, Ciudad, Telefono, Cod_NIT) values (04570, 'Marcela', 'Cardenas', 1,
'Cundinamarca', 'Bogota', 3042348712, 18562)
into vendedores (Cod_vendedor, Nombre_vendedor, Apellido_vendedor, Ventas_realizadas,
Departamento, Ciudad, Telefono, Cod_NIT) values (04571, 'Fredy', 'Manjarrez', 3,
'Cundinamarca', 'Bogota', 3106346731, 18562)
SELECT * from dual

VENDEDORES_AUTOS
insert all
into vendedores_autos (Cod_vendedor, No_bastidor) values (4567, 76231)
into vendedores_autos (Cod_vendedor, No_bastidor) values (4568, 66793)
into vendedores_autos (Cod_vendedor, No_bastidor) values (4569, 83610)
into vendedores_autos (Cod_vendedor, No_bastidor) values (4570, 87345)
into vendedores_autos (Cod_vendedor, No_bastidor) values (4571, 73626)
into vendedores_autos (Cod_vendedor, No_bastidor) values (4567, 27459)

SELECT * from dual

Script DCL

Después de diligenciar los registros en la BD realizar una consulta simple donde se pueda
evidenciar total de autos vendidos en el concesionario. (Código SQL)

select No_bastidor, Marca, Modelo, Color, Precio, Modo_pago, Fecha_entrega, Modo_pedido,

Descuento, Total_valor from autos_vendidos

Nombre Estudiante 2: María Camila Merchán

Script DDL

CREATE TABLE admin(

Nit_admin NUMBER (5) not null,
Nombre_admi CHAR(30) not null,
Apellido_admin CHAR(30) not null,
cargo_admin CHAR(30) not null,
CONSTRAINT admin_pk PRIMARY KEY ( Nit_admin )
);

CREATE TABLE factura (

Cod_factura NUMBER (10) not null,
Nit_admin NUMBER (10) not null,
Cod_vendedor NUMBER (10) not null,
No_IdentificacionC NUMBER (15) not null,
Matricula NUMBER (10) not null,
Fecha_expe DATE not null,
CONSTRAINT factura_pk PRIMARY KEY ( Cod_factura)
);

CREATE TABLE Detalle_factura (

Num_detafact NUMBER (10) not null,
Cod_factura NUMBER (10) not null,
Cantidad NUMBER (10) not null,
Total NUMBER (10) not null,
CONSTRAINT detalle_factura_pk PRIMARY KEY ( Num_detafact )
);

create table admin_defact

(Num_detafact NUMBER (10) not null,
Nit_admin NUMBER (5) not null,
foreign key (Num_detafact)
references detalle_factura (Num_detafact),
foreign key (Nit_admin)
references admin (Nit_admin)

);

create table admin_concesionario

(Nit_admin NUMBER (10) not null,
Cod_NIT NUMBER (5) not null,
foreign key (nit_admin)
references admin (Nit_admin),
foreign key (Cod_NIT )
references almacen (Cod_NIT )

);

create table detafact_factura

(Num_detafact NUMBER (10) not null,
Cod_NIT NUMBER (5) not null,
foreign key (Num_detafact)
references detalle_factura (Num_detafact),
foreign key (Cod_factura)
references factura (Cod_factura)

);
Script DML

ADMIN
- Insert into admin values (101, 'Luis', 'Cueva', 'Administrados')

- Insert into admin values(102, 'Sofía', 'Alvares', 'Supervisor')

- Insert into admin values(103, 'Miguel', 'Posada', 'Coordinador')

ADMIN_CONCESIONARIO
insert
Into admin_concesionario (Nit_admin,Cod_NIT ) values (101,18562)

FACTURA
insert all
Into Factura (Cod_factura, Nit_admin, No_IdentificacionC, Cod_vendedor, Matricula,
Fecha_expe) values (301,101,1040494116,4568,'TOY347',03/11/20)
Into Factura (Cod_factura, Nit_admin, No_IdentificacionC, Cod_vendedor ,Matricula,
Fecha_expe) values (302,101,1040492546,4570, 'FXH455',11/12/19)
Into Factura (Cod_factura, Nit_admin, No_IdentificacionC, Cod_vendedor, Matricula,
Fecha_expe) values (303,101,1001741642,4567, 'VBC878',23/05/19)
Into Factura (Cod_factura, Nit_admin, No_IdentificacionC, Cod_vendedor, Matricula,
Fecha_expe) values (304,101,1040502143,4569, 'FUB604',23/05/19)
Into Factura (Cod_factura, Nit_admin, No_IdentificacionC, Cod_vendedor, Matricula,
Fecha_expe) values (305,101,98714039,4571, 'MFV3456',01/02/19)

SELECT * from dual

DETALLE_FACTURA
insert all
into detalle_factura (Num_detafact, Cod_factura, Cantidad, Total) values (3001, 301, 1,
271600000)
into detalle_factura (Num_detafact, Cod_factura, Cantidad, Total) values (3002, 302, 1,
80655000)
into detalle_factura (Num_detafact, Cod_factura, Cantidad, Total) values (3003, 303, 1,
35000000)
into detalle_factura (Num_detafact, Cod_factura, Cantidad, Total) values (3004, 304, 1,
40500000)
into detalle_factura (Num_detafact, Cod_factura, Cantidad, Total) values (3005, 305, 1,
29000000)

select * from dual

DETAFACT_FACTURA
Insert all
Into Detafact_factura (Num_detafact, Cod_factura) values (3001, 301)
Into Detafact_factura (Num_detafact, Cod_factura) values (3002, 302)
Into Detafact_factura (Num_detafact, Cod_factura) values (3003, 303)
Into Detafact_factura (Num_detafact, Cod_factura) values (3005, 305)
Select *from dual

ADMIN_DEFACT
insert all
Into admin_defact (Num_detafact, Nit_admin) values (3001, 101)
Into admin_defact (Num_detafact, Nit_admin) values (3002, 101)
Into admin_defact (Num_detafact, Nit_admin) values (3003, 101)
Into admin_defact (Num_detafact, Nit_admin) values (3004, 101)
Into admin_defact (Num_detafact, Nit_admin) values (3005, 101)
select * from dual
Script DCL
Después de diligenciar los registros en la BD realizar una consulta simple donde se pueda
evidenciar los autos vendidos en el concesionario, el modelo y la marca. (Código SQL)

select Fecha_entrega, Total_valor, Modelo, Marca from autos_vendidos

Nombre Estudiante 3: Galo Jose Muñoz

Script DDL

CLIENTES
create table clientes
(No_Identificacionc NUMBER(15,0) not null,
Nombre_Cliente VARCHAR2(15) not null,
Apellido_Cliente VARCHAR2(15) not null,
Direccion VARCHAR2(40) not null,
Departamento VARCHAR2(15) not null,,
Ciudad VARCHAR2(15) not null,
Telefono NUMBER(10,0) not null,
Cod_Vendedor NUMBER(5,0) not null,
Constraint Clientes_Pk PRIMARY KEY (No_Identificacionc)

);

ALMACEN
create table almacen
(Cod_NIT NUMBER (5) not null,
Direccion VARCHAR (30) not null,
Telefono NUMBER (10) not null,
Cod_departamento NUMBER (5) not null,
constraint almacen_pk primary key (Cod_NIT),
foreign key (Cod_departamento)
references departamento (Cod_departamento)
);

CLIENTES_AUTOS
create table Clientes_Autos
(No_identificacionC NUMBER (15) not null,
No_bastidor NUMBER (5) not null,
foreign key (No_identificacionC)
references clientes (No_identificacionC),
foreign key (No_bastidor)
references autos_vendidos (No_bastidor)

);

Script DML

CLIENTES
Insert all
into Cliente (Cod_departamento, Nombre_Cliente, Apellido_Cliente, Direccion, Departamento,
Ciudad, Telefono, Cod_Vendedor) values (1040494116, ‘Milena’, ‘Lopez’, ‘Cra 58A N. 63B - 102
Apto 103’, ‘Cundinamarca’, ‘Bogotá’, 3193390135, 4568)
into Cliente (Cod_departamento, Nombre_Cliente, Apellido_Cliente, Direccion, Departamento,
Ciudad, Telefono, Cod_Vendedor) values (1040492546, ‘Carlos’, ‘Avila’, ‘Calle 20 N. 10 - 02
Barrio Los Molinos’, ‘Antioquia’, ‘Medellin’, 3148311548, 4570)
into Cliente (Cod_departamento, Nombre_Cliente, Apellido_Cliente, Direccion, Departamento,
Ciudad, Telefono, Cod_Vendedor) values (1001741642, ‘Raúl’, ‘Pérez’, ‘Cra 63 AA 44 Barrio
Porvenir’, ‘Antioquia’, ‘Bello’, 3147106145, 4567)
into Cliente (Cod_departamento, Nombre_Cliente, Apellido_Cliente, Direccion, Departamento,
Ciudad, Telefono, Cod_Vendedor) values (1040502143, ‘Martha’, ‘Rodriguez’, ‘Calle 30 N. 65-
96 Barrio El 20 de Julio’, ‘Atlántico’, ‘Barranquilla’, 3216047188, 4569)
into Cliente (Cod_departamento, Nombre_Cliente, Apellido_Cliente, Direccion, Departamento,
Ciudad, Telefono, Cod_Vendedor) values (98714039, ‘Edwar’, ‘Orozco’, ‘Cra 15 Sur Diag 30
Apto 110’, ‘Cesar’, ‘Valledupar’, 3216379863, 4571)

SELECT * from dual

ALMACEN
Insert all
into almacen (Cod_NIT, Direccion, Telefono, Cod_departamento) values (18562, ‘Cra 5 No 20-36 Barrio
Saturno’, 3204567892, 73001)
into almacen (Cod_NIT, Direccion, Telefono, Cod_departamento) values (17261, 'Cra 8 No 14-22 Barrio
Joaquin', 3157341043, 66001)
into almacen (Cod_NIT, Direccion, Telefono, Cod_departamento) values (25034, 'Cra 6 No 36-38 Barrio
San Antonio', 3047238927, 76036)
into almacen (Cod_NIT, Direccion, Telefono, Cod_departamento) values (78022, 'Cra 5 No 40-20 Barrio
El Salitre', 3128371022, 11011)
into almacen (Cod_NIT, Direccion, Telefono, Cod_departamento) values (17903,’ Cra 4 No 24-13 Barrio
El Poblado', 3239721234, 50001)

SELECT * from dual

CLIENTES_AUTOS
insert all
into clientes_autos (No_identificacionC, No_bastidor) values (1040494116, 76231)
into clientes_autos (No_identificacionC, No_bastidor) values (1040492546, 66793)
into clientes_autos (No_identificacionC, No_bastidor) values (1001741642, 83610)
into clientes_autos (No_identificacionC, No_bastidor) values (1040502143, 87345)
into clientes_autos (No_identificacionC, No_bastidor) values (98714039, 73626)
into clientes_autos (No_identificacionC, No_bastidor) values (1040494116, 27459)

SELECT * from dual

Script DCL

Después de diligenciar los registros en la BD realizar una consulta simple donde se pueda
mostrar cual es el vendedor con más autos vendidos. (Código SQL)

Nombre Estudiante 4:
Script DDL

Script DML

Script DCL

Después de diligenciar los registros en la BD realizar una consulta simple donde se pueda
obtener el valor total de las ventas. (Código SQL)

Nombre Estudiante 5: FARLEY GIOVANI GONZALEZ

Script DDL

DEPARTAMENTO

CREATE TABLE "DEPARTAMENTO"

( "COD_DEPARTAMENTO" NUMBER(5,0) NOT NULL ENABLE,
"NOMBRE" VARCHAR2(20) NOT NULL ENABLE,
CONSTRAINT "DEPARTAMENTO_PK" PRIMARY KEY ("COD_DEPARTAMENTO")
USING INDEX ENABLE
)
/
REVISIONES

CREATE TABLE "REVISIONES"

( "COD_REVISION" NUMBER(5,0) NOT NULL ENABLE,
"NO_REVISION" NUMBER(38,0) NOT NULL ENABLE,
"CAMBIO_ACEITE" VARCHAR2(2),
"REVISIONES_FRENOS" VARCHAR2(2),
"CAMBIO_FILTRO" VARCHAR2(2),
"OTRO" VARCHAR2(40),
"NO_BASTIDOR" NUMBER(5,0) NOT NULL ENABLE,
CONSTRAINT "REVISIONES_PK" PRIMARY KEY ("COD_REVISION")
USING INDEX ENABLE
)
/
ALTER TABLE "REVISIONES" ADD FOREIGN KEY ("NO_BASTIDOR")
REFERENCES "AUTOS_VENDIDOS" ("NO_BASTIDOR") ENABLE
/
Script DML

DEPARTAMENTO
Insert all
into departamento (Cod_departamento, Nombre) values (73001, ‘Tolima’)
into departamento (Cod_departamento, Nombre) values (50001, 'Antioquia')
into departamento (Cod_departamento, Nombre) values (11011, 'Cundinamarca')
into departamento (Cod_departamento, Nombre) values (76036, 'Valle')
into departamento (Cod_departamento, Nombre) values (66001, 'Risaralda')

SELECT * from dual

REVISIONES
Insert all
Into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (301, 103, ‘SI’, ‘NO’, ‘SI’,83610)
into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (306, 107, ‘NO’, ‘SI’, ‘NO’,27459)
into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (302, 102, ‘SI’, ‘SI’, ‘SI’ , 'Revisión de Mordaza de
freno', 83610)
into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (303, 103, ‘SI’, ‘SI’, ‘SI’ , 'Ajuste de Caja de Filtro',
87345)
into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (304, 105, ‘SI’, ‘NO’, ‘SI’ , 'Ajuste de Tablero', 73626)
into Revisiones (Cod_ Revision, No_Revision, Cambio_Aceite, Revisiones_Frenos,
Cambio_Filtro, Otro, No_Bastidor) values (300, 100, ‘SI’, ‘NO’, NO’ , 76231)

SELECT * from dual

Script DCL
Después de diligenciar los registros en la BD realizar una consulta simple
donde se pueda mostrar el mes con menos ventas. (Código SQL)

DEPARTAMENTO
select COD_DEPARTAMENTO,
NOMBRE
from "DEPARTAMENTO" a

REVISIONES
select COD_REVISION,
NO_REVISION,
CAMBIO_ACEITE,
REVISIONES_FRENOS,
CAMBIO_FILTRO,
OTRO,
(select "MARCA" from "AUTOS_VENDIDOS" x where x."NO_BASTIDOR" =
a."NO_BASTIDOR") "NO_BASTIDOR"
from "REVISIONES" a
Evidencias de la participación en el foro

Se espera que cada estudiante presente las evidencias de su participación en el foro con relación al

Desarrollo Fase 1 - Unidad 1, al igual que comentarios significativos a los aportes de los demás

compañeros del grupo.

Nombre Estudiante 1: ANDRÉS FELIPE ZABALA

Nombre Estudiante 2: MARÍA CAMILA MERCHÁN

Nombre Estudiante 3: GALO JOSÉ MUÑOZ

Nombre Estudiante 4:
Imagen 1 Imagen 2

Nombre Estudiante 5: FARLEY GIOVANI GONZALEZ

 CONCLUSIONES

Podemos concluir que para diseñar, modelar y relacionar una base de datos podemos implementar

modelo entidad relación lo cual es fundamental para en el diseño de las tablas, al igual que el

grado de cardinalidad que existen entre los atributos de las entidades, además con el proceso de

normalización depuramos las tablas sin el temor de incidir en la perdida de datos evitando tener

relaciones de mucho a a mucho facilitando la interpretación de nuestro modelo de datos.

Además, al diligenciar los formatos nos permite realizar de manera más organizada las tablas y sus

relaciones de nuestra base de datos al igual que su codificación en DDL, DML, DCL, en gestor de

bases de datos como es Oracle, permitiendo un desarrollo muy técnico en el proceso de creación

de la base de datos, pudiendo identificar sus entidades y las relaciones que ellas tienen, para así

tener acceso a la información de una manera más rápida y organizada.

BIBLIOGRAFÍA

Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.),
McGraw-Hill España, 2007. ProQuest Ebook Central, pag-16-24recuperado
http://bibliotecavirtual.unad.edu.co:2460/lib/unadsp/reader.action?
ppg=43&docID=3195347&tm=1531498461426

Sosa Flores, M. & López Vázquez, M. (2007) Diseño de bases de datos relacionales. Córdoba,
AR: El Cid Editor. pág. 20 -42. Recuperado de
http://bibliotecavirtual.unad.edu.co:2460/lib/unadsp/reader.action?
ppg=22&docID=3175111&tm=1531495677522

Jiménez, C. M. Y. (2014). Bases de datos relacionales y modelado de datos (uf1471). Recuperado

de https://bibliotecavirtual.unad.edu.co:2538/lib/unadsp/reader.action?
ppg=16&docID=4184006&tm=1542156304402