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: XXXX - NOMBRE ESTUDIATNE 4
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.................................................................................................................4
A. Análisis de requerimientos...................................................................................................5
Formato 1: Definición y Descripción de Entidades..............................................................5
Formato 2: Descripción de atributos y sus restricciones..................................................6
Formato 3: Matriz de Relaciones...............................................................................................6
Formato 4: Descripción de las relaciones determinadas en la Matriz de Relaciones
...............................................................................................................................................................7
B. Diseño modelo Entidad Relación y modelo Relacional...............................................7
1 - Modelo Entidad Relación........................................................................................................7
2 - Modelo Relacional.....................................................................................................................8
Técnicas de normalización...........................................................................................................8
C. Desarrollo de la base de datos relacional.......................................................................8
Evidencias de la participación en el foro.....................................................................................9
CONCLUSIONES.....................................................................................................................................12
BIBLIOGRAFÍA........................................................................................................................................13
 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 Moderador Calificar de 1 a 5
Moreno
Estudiante 2 María Camila Merchán Evaluador 5
Estudiante 3 Galo José Muñoz Colaborador 4,5
Farley Giovanni Gonzalez Londoño Creativo Calificar de 1 a 5
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?

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 el 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, explicación Ejemplo de Ejemplares Extensión INTENCION
de Entidad de su existencia en el (Instancias)
Mundo del Problema

Andrés Felipe Zabala Moreno

Vendedores Es importante porque el  Claudia Moreno 150 Realizar ventas y
concesionario debe  Julián Perdomo asesoramiento a
tener un registro de los  Vanessa Ramírez cambio de una
vendedores con los que  Marcela Cárdenas remuneración
cuenta y realizan las  Fredy Manjarrez
ventas.

Autos_Vendido Es una de las tablas más  Audi 1000 Ser un bien que
s importantes ya que se  Chevrolet pueda adquirir
lleva un registro de los  Renault un cliente
autos que el  Mazda
concesionario ha  Mercedes-Benz
vendido y el valor de su
venta
Proveedores Es indispensable ya que  Johann Rudi 150 Surtir a los
se lleva un el registro de  Evan Henderson diferentes
 donde llegan cada  Edith Barraud. almacenes del
vehículo y herramientas  Kenji Rokujo. concesionario a
al concesionario y quien  Edwin Lehner cambio de una
es el encargado de este remuneración y
proceso aumento de
ventas
Galo José Muñoz
Cliente Es muy indispensable  Raúl Pérez 1000 Comprar los
que es el que genera los  Milena López diferentes
ingresos y muy  Martha Rodríguez vehículos con
importante tener el  Carlos Avila los que cuenta
registro de los clientes  Edwar Orozco del
que vistan y compran el concesionario y
producto adquirir
servicios de él
Almacén Es una tabla requerida  Barrio Saturno 40 Recibir la
para saber en qué punto mercancía o
se encuentra ubicado el vehículos que
almacén del llegan por parte
concesionario de los
proveedores
para así tener
un punto de
venta en el
departamento.
MARIA CAMILA MERCHÁN RIVERA
Admin Importante porque  Luis Felipe Cueva 100 Tener control
registra los datos del  Sofía Alvares del personal
empleado que se  Miguel Posada administrativo y
encarga de la parte funciones en el
administrativa del 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 más  3002 de compra
detallada de lo que 3003 como cantidad,
refiere a cantidad, subtotal,
subtotal, etc. servicios, etc.
Nombre Estudiante 4:

Nombre Estudiante 5:
Departamento Es importante para  Tolima 40 Llevar la
saber en qué parte del  Antioquia distribución de
país tiene puntos de  Cundinamarca los diferentes
venta el concesionario  Valle puntos de venta
Risaralda
Revisiones Es importante llevar el  Cambio de filtro 30 Hacer
conteo de las veces que  Revisiones de frenos reparaciones a
llevan un vehículo a  Cambio de Aceite los
realizar una revisión y  Revisión de Luces inconvenientes
que tipo Revisión de del vehículo a
amortiguación cambio una
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 123478
Almacen 41-4
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
Cargo_admin   cargos T 30 Si M Gerente  4-30 permite
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
  N 15 Si 1 105433  2-10 permite
cionC cionCs
numero
Solo
Cod_vended Cod_vendedo
  N 5 Si 1 401  2-5 permite
or res
numero
Solo
Nombre_ven Nombrevende
  T 30 Si 1 Carlos  3-30 permite
dedor dores
texto
Permite
Matricula   Matriculas N, T 10 Si 1 TOY347  4-10 números
y texto
12-jul- Fecha_ex
Fecha_expe   Fechas_expe F 30 Si 1  3-30
19 pedición
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
870000
Total   Totales N 10 Si 1  3-10 permite
00
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
 clientes le
cliente? puede
proceso que estamos
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.
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

Tabla admin

Nit_admin Nombre_admin Apellido_admin Cargo_admin

101 Luis Cueva Gerente

Tabla admin_concesionario
Num_detafa
ct Cod_NIT
12347841-
3001 4

Tabla factura

Cod_factu Nit_adm No_Identificaci Cod_vende Nombre_vende Matricu Fecha_ex

ra in onC dor dor la pe
TOY34
301 101 105433 401 Carlos 12-jul-19
7

Tabla Detalle_factura
Num_detafa Cod_factur
ct a Cantidad Total
3001 301 1 8,7E+07

Detafact_factura
Num_detafa Cod_factu
ct ra
3001 301

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)

);
DEPARTAMENTO
create table departamento
(Cod_departamento NUMBER (5) not null,
Nombre VARCHAR (20) not null,
constraint departamento_pk primary key (Cod_departamento)
);

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

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

Nombre Estudiante 3:
Script DDL

Script DML

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

CREATE TABLE "CLIENTES"

( "NO_IDENTIFICACIONC" NUMBER(15,0) NOT NULL ENABLE,
"NOMBRE_CLIENTE" VARCHAR2(15) NOT NULL ENABLE,
"APELLIDO_CLIENTE" VARCHAR2(15) NOT NULL ENABLE,
"DIRECCION" VARCHAR2(40) NOT NULL ENABLE,
"DEPARTAMENTO" VARCHAR2(15) NOT NULL ENABLE,
 "CIUDAD" VARCHAR2(15) NOT NULL ENABLE,
"TELEFONO" NUMBER(10,0) NOT NULL ENABLE,
"COD_VENDEDOR" NUMBER(5,0) NOT NULL ENABLE,
CONSTRAINT "CLIENTES_PK" PRIMARY KEY
("NO_IDENTIFICACIONC")
USING INDEX ENABLE
)
/
ALTER TABLE "CLIENTES" ADD FOREIGN KEY ("COD_VENDEDOR")
REFERENCES "VENDEDORES" ("COD_VENDEDOR") 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
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)

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ám

Nombre Estudiante 3: Galo José Muñoz

Nombre Estudiante 4:
Imagen 1 Imagen 2

Nombre Estudiante 5:
 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