“UNIVERSIDAD NACIONAL DE SAN AGUSTÍN”

FACULTAD DE INGENIERIA DE PRODUCCIÓN Y SERVICIOS

ESCUELA PROFESIONAL DE INGENIERÍA EN

TELECOMUNICACIONES

Curso: Programación Avanzada

Tema: Practica N°1Diseño SQL desde diagrama E-R

Docente: Ing. Ramiro Banda Valdivia

Grupo: ‘A’

Estudiante: Hancco Ttupa, Walter Alvaro CUI:20170777

Arequipa-Perú

2019

Programación Avanzada Práctica N° 1

1.- Objetivos de la práctica
1) Familiarizarse con una herramienta visual para desarrollo de la arquitectura de
bases de datos en esta caso Mysql. Existen otras herramientas para otros
gestores.

2) Transferir el diagrama E-R creado con la herramienta de arquitectura a SQL

3) Usar un cliente de bases de datos para generar consultas SQL e insertar contenido
a las tablas. Ahorrándonos recordar de memoria y digitar algunos comandos SQL.

4) Normalizar una tabla

Al ejecutar la Práctica envié su Informe en doc a [email protected] formando grupos de

máximo 5 personas.

2.- Elementos requeridos:

a) Hardware: Computador con Windows

b) Software:

 Instaladores de WAMP, busque una versión compatible con su sistema (32/64bits) en:

 HeidiSQL http://www.heidisql.com/

 MysqlWorkbech 5.2 o superior (Modelado SQL)

3.- Conceptos teóricos

Una relación identificadora (identifying relationship), es una relación de uno-a-muchos, en la que
la clave primaria de una entidad fuerte es absorbida por una entidad débil. Se dice que es una
entidad débil, porque por sí misma no tiene modo de identificarse de forma única (no tiene clave
primaria).

Un ejemplo: tenemos una aplicación que registra el ingreso de los empleados a las instalaciones
de la organización. he aquí el modelo:

empleado { id_empleado, nombre, apellido, departamento, cargo }

ingreso_a_instalaciones { id_empleado, hora_ingreso, puerta }

En este caso, existe una relación identificadora porque cada registro de ingreso_a_instalaciones
*requiere* que se especifique el id_empleado

De no especificarse, no se podría saber quién ingresó a las instalaciones. Eso convierte a cada
ingreso_a_instalaciones en una entidad débil, que depende de la existencia de otra entidad (el
empleado). El software para modelado usa este concepto.
Una relación no identificadora (non-identifying relationship) es una relación de uno-a-muchos
donde una entidad no depende de la existencia de otra, porque tiene su propia clave principal.

Un ejemplo: tenemos una aplicación que lleva la nómina:

empleado { id_empleado, nombre, apellido, cargo, departamento, id_empleado_jefe }

En este caso, yo puedo usar la clave foránea id_empleado_jefe para establecer qué otro
empleado es jefe de un empleado en particular, pero en sí, cada empleado tiene su id_empleado,
por lo que la relación con el *empleado jefe* no tiene para nada que ver con la existencia del
empleado común.

Propósitos de la normalización:

Eliminar registros redundantes y asegurar la dependencia de datos tal que se establezcan

relaciones lógicas entre las tablas con ayuda de relaciones, claves primarias, secundarias.

4.- Procedimiento parte A

Instale el paquete WAMP en su computadora Windows, Apache, Mysql y PHP en su computadora,
asimismo MysqlWorkbench.

Descargue HeidiSQL un administrador de bases de datos MySql y conéctese como root a su DBMS
local. Permita que los servicios de Wamp estén activos.

Cree en su PC una base de datos llamada TIENDA. Use el siguiente comando:

CREATE DATABASE TIENDA;

Nota: El comando tiene que ser ejecutado en la consola de comandos SQL

Figura 1: Creando una nueva base de datos mediante HeidiSQL

Deje por ahora la consola SQL, ahora pase a usar el Mysql Workbench y cree un nuevo Modelo -> Agregar
diagrama, ahora mediante la herramienta visual establezca la siguiente relación entre las tablas en notación
E-R. Dese cuenta si le conviene usar una relación identificadora o no,(refiérase a la teoría de la página 1)

Figura 2: Modelo E-R solicitado a implementar.

Figura 3: El resultado al crear las dos entidades

Las relaciones pueden ser 1:1, 1:n, etc.

Ahora exporte su diagrama (mire la figura 4) a un archivo SQL el modelo creado(omitiendo el

esquema calificador, es decir el prefijo de base de datos ), luego cargue el contenido en la consola
de comandos de HeidiSql. Previamente debe seleccionar la base de datos creada antes y dentro de
ella ejecutar el contenido de comandos SQL provenientes del Mysql WorkBech.
Figura 4: Exportando el modelo creado a SQL

Figura 5: La consola de comandos SQL desde HeidiSql

Proceda a insertar registros a las tablas creadas en HeidiSQL

TABLA: FABRICANTES

CLAVE_FABRICANTE NOMBRE

1 Microsoft

2 Samsung

3 Easy Mouse

4 Toshiba
 5 Kingston

6 Sony

TABLA: ARTICULOS

CLAVE_ARTICULO NOMBRE PRECIO CLAVE_FABRICANTE

1 Teclado $ 100 3

2 Disco duro 300 $ 500 5

Gb

3 Mouse $ 80 3

4 Memoria USB $ 140 4

500GB

5 Memoria RAM $ 290 1

(16GB)

6 Disco duro $ 650 5

extraíble 250 Gb

7 Memoria USB $ 279 1

8 DVD Rom $ 450 2

9 CD Rom $ 200 2

10 Tarjeta de red $ 180 3

Para insertar prueba usando la herramienta visual de HeidiSQL y también usando comandos Sql
como por ejemplo:

INSERT INTO FABRICANTES VALUES ( 1 , ‘Microsoft’);

Pruebe la diferencia, ¿explique en su informe, en qué casos conviene insertar datos mediante
commandos SQL?

Que tanto la interfaz grafica como la consola de líneas de comandos no tienes mucha diferencia ya que la
interfaz virtual crea una consulta insert para insertar los registros tomando en cuenta que se pueden generar
consultas mas complejas tan solo haciendo uso del mouse en menos tiempo que si lo estuvieran haciendo en
la línea de comandos

a) Obtener todos los datos de los productos de la tienda

SELECT * FROM ARTICULOS;

 Selecciona todos los registros de la tabla artículos como se mira en la imagen

b) Obtener los nombres de los productos de la tienda

SELECT Nombre FROM ARTICULOS;

c) Obtener los nombres y precio de los productos de la tienda

SELECT Nombre,Precio FROM ARTICULOS;

d) Obtener los nombres de los artículos sin repeticiones
SELECT DISTINCT Nombre FROM ARTICULOS;
e) Obtener todos los datos del artículo cuya clave de producto es ‘5’

SELECT * FROM ARTICULOS WHERE Clave_articulo=5;

f) Obtener todos los datos del artículo cuyo nombre del producto es ‘’Teclado”

SELECT * FROM ARTICULOS WHERE Nombre=’Teclado’;

g) Obtener todos los datos de la Memoria RAM y memorias USB

SELECT * FROM ARTICULOS WHERE Nombre=’Memoria RAM’ OR Nombre=’Memoria USB’ ;

h) Obtener todos los datos de los artículos que empiezan con ‘M’

SELECT * FROM ARTICULOS WHERE Nombre LIKE ‘M%’;

i) Obtener el nombre de los productos donde el precio sea $ 100

SELECT Nombre FROM ARTICULOS WHERE Precio = 100;

j) Obtener el nombre de los productos donde el precio sea mayor a $ 200

SELECT Nombre FROM ARTICULOS WHERE Precio > 200;

k) Obtener todos los datos de los artículos cuyo precio este entre $100 y $350

/* OPERADOR AND */

SELECT * FROM ARTICULOS WHERE Precio >= 100 AND Precio<=350;

/* OPERADOR BETWEEN */

SELECT * FROM ARTICULOS WHERE Precio BETWEEN 100 AND 350;

l) Obtener el precio medio de todos los productos

SELECT AVG(Precio) FROM ARTICULOS;

no resulta ya que como el valor del de la variable precio es varchar no

se puede hacer un promedio de caracteres
 m) Obtener el precio medio de los artículos cuyo código de fabricante sea 2

SELECT AVG(Precio) FROM ARTICULOS WHERE Clave_fabricante=3;

el mismo problema en la consulta el valor es varchar en el campo precio

n) Obtener el nombre y precio de los artículos ordenados por Nombre

SELECT Nombre, Precio FROM ARTICULOS ORDER BY Nombre;

o) Obtener todos los datos de los productos ordenados descendentemente por Precio

SELECT * FROM ARTICULOS ORDER BY Precio DESC;

p) Obtener el nombre y precio de los artículos cuyo precio sea mayor a $ 250 y ordenarlos
descendentemente por precio y luego ascendentemente por nombre
SELECT Nombre, Precio FROM ARTICULOS

WHERE Precio >= 250 ORDER BY Precio DESC, Nombre;

q) Obtener un listado completo de los productos, incluyendo por cada articulo los datos del articulo y del
fabricante
SELECT * FROM ARTICULOS, FABRICANTES

WHERE ARTICULOS.Clave_fabricante=FABRICANTES.Clave_fabricante
r) Obtener la clave de producto, nombre del producto y nombre del fabricante de todos los productos
en venta
SELECT ARTICULOS.Clave_articulo, ARTICULOS.Nombre, FABRICANTES.Nombre

FROM ARTICULOS, FABRICANTES

WHERE ARTICULOS.Clave_fabricante=FABRICANTES.Clave_fabricante
s) Obtener el nombre y precio de los artículos donde el fabricante sea Logitech ordenarlos
alfabéticamente por nombre del producto

SELECT ARTICULOS.Nombre, ARTICULOS.Precio FROM ARTICULOS, FABRICANTES

WHERE FABRICANTES.Nombre=’Easy Mouse’ AND

ARTICULOS.Clave_fabricante=FABRICANTES.Clave_fabricante
t) Obtener el nombre, precio y nombre de fabricante de los productos que son marca Lexar o Kingston
ordenados descendentemente por precio

SELECT ARTICULOS.Nombre, ARTICULOS.Precio, FABRICANTES.Nombre

FROM ARTICULOS, FABRICANTES

WHERE FABRICANTES.Nombre=’Microsoft’ OR FABRICANTES.Nombre=’Toshiba’

AND ARTICULOS.Clave_fabricante=FABRICANTES.Clave_fabricante

ORDER BY ARTICULOS.Precio DESC;

u) Añade un nuevo producto: Clave del producto 11, Altavoces de $ 120 del fabricante 2

INSERT INTO ARTICULOS VALUES (11 ,’Altavoces’, 120, 2);

v) Cambia el nombre del producto 6 a ‘Impresora Laser’

UPDATE ARTICULOS SET Nombre=’Impresora Laser’ WHERE Clave_articulo = 8

w) Aplicar un descuento del 10% a todos los productos.

UPDATE ARTICULOS SET Precio=Precio *0.10

x) Aplicar un descuento de $ 10 a todos los productos cuyo precio sea mayor o igual a $ 300

UPDATE ARTICULOS SET Precio=Precio – 10

WHERE Precio >= 300

y) Borra el producto numero 6

DELETE FROM ARTICULOS WHERE Clave_articulo= 6

Y1) Use un left Join y comente el resultado

select * from fabricantes left join articulos on

fabricantes.codigo=articulos.fabricantes_codigo
Y2) Cree una consulta que devuelva el producto má s caro
Select max(precio) from articulos

Y3) Cree otra tabla que relacione los artículos, fabricantes con clientes y una tabla
de ordenes.

4.1.- Procedimiento parte B

Investigue sobre las 3 formas normalizadas y normaliza la siguiente tabla de estudiantes.

Id Nombre Dirección Cursos

401 Adam Noida Bio
402 Alex Panipat Maths
403 Stuart Jammu Maths
404 Adam Noida Physics

La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en
nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si
nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros
datos del Cliente, es que no hemos aplicado esta Normalizaciòn.Si tenemos una tabla clientes,
en la tabla ventas, solo deberia figurar el codigo del cliente, para que el resto de los datos se
puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo
ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del
producto, con su descripción , medidas, etc…Tendriamos un desaprovechamiento de espacio y
recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo
grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.

La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma

Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender
de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal,
si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos
deberian atomizarse en una nueva tabla.Veamos un ejemplo
 VentaID ItemID  FechaVenta  ClienteVenta  ProductoId  Cantidad 

1  1  01/12/2007 2  2334  10 

1  2   01/12/2007 2 3333 2 

1  3   01/12/2007 2 66643  34 

1  4   01/12/2007 2  21  3 

2   1  02/12/2007 5  3566  6 

Tenemos un típico problema . ¿Acaso no se busca no repetir datos? Si toda una venta tendrá el
mismo número de Cliente y la misma Fecha…Por que no crear una Tabla de MAESTRO DE
VENTAS  y que contenga esos 2 datos ?Es evidente que la
columna ClienteVenta y FechaVenta se repetirán por cada venta realizada.Es por ello que
proponemos el siguiente esquema 

entaID ItemID  ProductoId  Cantidad 

1  1 2334  10 

1  2  3333 2 

1  3  66643  34 

1  4  21  3 

2   1 3566  6 
 Y ahora nuestra nueva tabla maestra
VentaId  FechaVenta  ClienteVenta 

1 01/12/2007  2

2  02/12/2007  5 

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender
de toda la clave y no constituir un dato unico para cada grupo de registros.

La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria
normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas
normales, ya que la 3ra Forma Normal nos habla de que :

 Ninguna Columna puede depender de una columna que no tenga una clave

 No puede haber datos derivados

En el 2do ejemplo hemos descubierto campos que dependian de la clave principal

(VentaID) y que podrian incluirse en una tabla maestra.Pero supongamos un ejemplo
donde ciertas columnas no dependen de la clave principal y si dependen de una columna
de nuestra tabla.

entaID ItemID  ProductoID  Cantidad  Descripcion  Medida  Proveedor 

 1 1  3455  12  Impresora HP LJ8000  122cm  1 

 1 2  2455  34  Scanner HP A3555  33cm  1 

 2 1 5444  21  Mouse HP Wireless  –  1 

Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos
DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no
deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no
se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion de
una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe
estar en otra tabla y no en nuestra tabla detalle.

Conclusión Finalmente si tomamos en cuenta que una tabla de detalle de venta (item x item)
puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos
estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado
notablemente la performance.
Conclusiones
 Existe solo una llave primaria por tabla

 Se debe tomas tomar en cuenta los campos de una tabla y si esta relacionadas con la llave
primaria de la tabla

 Se puede unir distintas tablas con la palabra reservada join pero teniendo en cuenta que
las tablas al relacionarse deben estar unidas mediante claves foráneas

 El uso del where en una consulta en importante ya que con esta palabra clave podemos
extraer registros mas específicos

 Debemos entender el uso de una llave primaria y su relación con los campos de su tabla
ya que como se sabe que la llave primaria contiene registros no repetidos

Informe Final

Responda las preguntas formuladas a lo largo de la presente Práctica, desarrolle las consulta SQL,
sus resultados y agregue sus conclusiones y observaciones. Finalmente envíe por email su trabajo
a [email protected]