Esta empresa cuenta con una sucursal que vende productos por pedido en general a una infinidad de clientes. De cada uno de estos productos la tienda desea guardar el precio, un ID de producto, categoría, existencias y un nombre. Así mismo requiere guardar los datos personales de cada uno de sus clientes a quien envía sus productos, un ID de cliente, su nombre, sus apellidos, su dirección y número de teléfono.

Cabe señalar que un cliente puede realizar varios pedidos, mientras que un pedido sólo puede ser enviado a un sólo cliente y cada vez que se realice un pedido se generará una factura con la fecha en la cual el artículo fue adquirido, así como un número de factura, un cliente puede obtener varias facturas, pero sólo una factura puede pertenecer a un cliente. A continuación, se asigno una entidad débil que guardará la cantidad de productos adquiridos y su precio. Una factura puede tener varios detalles, mientras que un detalle solo puede pertenecer a una factura.

El pedido será atendido por un vendedor, de él se quiere conocer un ID de vendedor, nombre, apellidos y número de teléfono. Se sabe que un vendedor puede atender varios pedidos y y un pedido sólo puede ser atendido por un vendedor. El pedido se conforma del producto en turno que fue solicitado, muchos pedidos se conforman de un sólo producto y sólo un producto puede estar en los pedidos.

Por último se conoce que la tienda de electrónicos cuenta con distintos proveedores que son los que suministran los productos que se solicitan. Por lo que un proveedor puede suministrar varios productos, y un producto sólo puede ser suministrado por un proveedor. De estos proveedores se requiere guardar su dirección, nombre, apellidos, ID de proveedor y su número de teléfono.

ACTUALIZACIÓN 15 DE MARZO DEL 2107

Al entregar nuestro modelo surgieron algunas dudas:

La relación "suministra" indica que que un producto lo suministran MUCHOS proveedores, lo cual indica que un el negocio debe tener un proveedor por cada producto, esto es real??

La afirmación es errónea, así que corregimos nuestro modelo, la cardinalidad es 1:N de la relación Proveedor-Producto, que indica que "un proveedor puede suministrar varios productos y un producto sólo puede ser suministrado por un proveedor", por lo que el modelo queda corregido y se puede ver en el siguiente enlace.

Descarga el siguiente modelo dando clic aquí

CONCLUSIONES

Al diseñar este Modelo E-R obtuvimos amplio conocimiento para identificar los datos más importantes y generales a tomar en cuenta al diseñar una base de datos. En cuanto al estructurar el modelo E-R la dificultad fue menor, porque obtuvimos información completa de páginas de Internet y ejemplos que nos llevaron a crear nuestro Modelo E-R de una tienda en particular. Concluimos que las bentidades que elegimos eran las correctas y las que tenían mayor importancia. Al calcular la cardinalidad tuvimos algunos problemas, pero las fuentes de información nos apoyaron para terminar de entender el tema de la cardinalidad dentro de las relaciones. Al final podemos decir que esta actividad la cumplimos porque aplicamos y analizamos el Modelo E-R, el cual más adelante nos ayudará a diseñar una base de datos.

Bibliografía

Páginas web:
Abel Emerit Tovilla & Marisol Wendoline Zamorano. (s/f). Modelo Entidad Relación. Recuperado de: http://tavoberry.com/MER/diseo_con_diagramas_er.html

Libro con autor:
Nevado Cabello María Victoria. (2010). Introducción a las Bases de Datos Relacionales. Madrid, España. Visión Libros.

Videos en Línea:
García Jorge (2011, Febrero, 04). modelo Entidad-Relación con DIA.
Recuperado de: https://www.youtube.com/watch?v=ZKy14SZCOiI

Acerca de:
Éste es un sitio creado por estudiantes del Instituto Tecnológico de Pachuca, para la asignatura en curso; Fundamentos de Bases de Datos.
Equipo New Jackers: Hernández Salinas Lucio y Sanchez Casañas Jose María
Actividades Unidad 2