Ejercicio

[jokerwad]

Hola a todos, es mi primer post, estoy teniendo problemas para poder realizar un ejercicio, soy totalmente nuevo en base de datos y estoy diagramando, el ejercicio es fácil pero tengo algunas dudas de como se debe diagramar.

Les dejo el enunciado:

• Una base de datos para una pequeña empresa debe contener información acerca de
clientes, artículos y pedidos. Hasta el momento se registran los siguientes datos en
documentos varios:
• • Para cada cliente: Número de cliente (único), Direcciones de envío (varias por cliente), Saldo, Límite de crédito (depende del cliente, pero en ningún caso debe superar los 3.000$), Descuento.
• • Para cada artículo: Número de artículo (único), Fábricas que lo distribuyen, Existencias
de ese artículo en cada fábrica, Descripción del artículo.
• • Para cada pedido: Cada pedido tiene una cabecera y el cuerpo del pedido. La cabecera
está formada por el número de cliente, dirección de envío y fecha del pedido. El cuerpo
del pedido son varias líneas, en cada línea se especifican el número del artículo pedido
y la cantidad.
• Además, se ha determinado que se debe almacenar la información de las fábricas. Sin
embargo, dado el uso de distribuidores, se usará: Número de la fábrica (único) y
Teléfono de contacto.
• Y se desean ver cuántos artículos (en total) provee la fábrica. También, por información
estratégica, se podría incluir información de fábricas alternativas respecto de las que ya
fabrican artículos para esta empresa

Mis principales dudas son:
En la entidad cliente, TODO lo que sigue serian atributos o también hay otras entidades? es decir, direcciones de envio seria un atributo? me cuesta darme cuenta de esas cosas.. y en caso que fuese otra entidad, calculo que seria foranea de cliente.
En articulo algo similar me pasa, fabricas seria otra entidad verdad?
Luego, la cabecera y cuerpo de pedido, serian dos entidades aparte? o serian atributos de pedido?

Si hace falta adjunto el diagrama que hice pero pensé que era super largo sino, ya quedo largo así.

Gracias gente! saludos.

[gnzsoloyo]

Lo siento pero no hacemos ejercicios ni trabajos prácticos. A nadie.

Si quieres una guía, podemos ayudarte, pero empieza por describir qué es lo que no entiendes, y postea la solución que tu propones para el ejecercicio. En base a ella te podremos hacer observaciones.
Pero fuera de eso, el trabajo es tuyo...

No te ofendas. Es la misma respuesta que le damos a todos los que vienen a plantear pedidos como este, sin excepciones.

[jokerwad]

Hola, gracias por la respuesta, no no me ofendo para nada!

Yo proponia hacer una entidad para cliente, articulo y pedido con los atributos que le corresponden en cada uno. Me cuesta darme cuenta, inclusive fuera de este ejercicio, donde tengo que utilizar entidades foraneas o si son atributos.

Mi resolucion son las entidades que utilizaria cliente, articulo, pedido, fabricas, cabecera, cuerpo y distribuidores.

[gnzsoloyo]

En este tiipo de ejercitaciones estás trabajando todavía a nivel de lógica, sin las tablas. Eso es algo que debes tener en cuenta, porque una gran parte de las confusiones surge de creer que al analizar los requerimeitnos del ssitema (lógica del negocio) estás viendo una base de datos física, y no es así.
Todavía falta para llegar a eso.
Veamos algunas deducciones:

• • Para cada cliente: Número de cliente (único), Direcciones de envío (varias por cliente), Saldo, Límite de crédito (depende del cliente, pero en ningún caso debe superar los 3.000$), Descuento.

De esto se infiere que tienes estas entidades: Clientes (fuerte), Direcciones (débil), y ciertas condiciones comerciales (credito, limite y descuentos) que pueden ser atributos del cliente. Si las quieres poner como entidad independiente hay que justificarlo.

• • Para cada artículo: Número de artículo (único), Fábricas que lo distribuyen, Existencias
de ese artículo en cada fábrica, Descripción del artículo.

De aquí se infieren: Productos y Proveedores. Se puede inferir mucho más, pero lo básico es eso. ID de producto, Descripcion y Existencia son atributos de Producto.

• • Para cada pedido: Cada pedido tiene una cabecera y el cuerpo del pedido. La cabecera
está formada por el número de cliente, dirección de envío y fecha del pedido. El cuerpo
del pedido son varias líneas, en cada línea se especifican el número del artículo pedido
y la cantidad.

Esto describe una relación maestro/detalle usual en todo tipo de documentación. La confusión surge porque esto no es una entidad, sino que ya habla de tablas. Como entidad es simplemente Pedidos. La transformación a tabla fisica requiere siemrpe dos tablas como minimo.
Obviamente si un pedido es de un cliente y tiene 1 a N artículos, esta entidad se relaciona con ambas (Clietne y Producto), pero no de la misma forma a nivel de tablas: Clietne con la cabecera, y Producto con Detalle_Pedido.
Pero eso es anivel físico. COmo DER lógico es una entidad y se relacionan ambas.

• Además, se ha determinado que se debe almacenar la información de las fábricas. Sin
embargo, dado el uso de distribuidores, se usará: Número de la fábrica (único) y
Teléfono de contacto.

Acá se vuelve a halblar de los proveedores, como "Fábrica". No está claro si un mismo proveedor opera con N fábricas o cada fábrica es a la vez proveedor.
Eso lo tendrás que describir en la solución como premisa de trabajo, y mi consejo es que iguales el concepto de proveedor con el de fabrica, para evitar complicaciones.
De todos modos, como hay una rrelacion 1:N entre Producto y Fabrica/Proveedor, la FK del proveedor va en la tabla producto.
Lo que si se infiere es la existencia de "distribuidores" que no está suficientemente explicada. Si son los proveedores, entonces hay que determinar si un mismo distribuidor trabaja con más de una Fábrica. Si no es así, pero hay 1 a N distribuidores por fabrica, se deberá crear una entidad débil relacionada con Fabrica, con su propio identificador discriminante, y relacionar esta entidad con el pedido.
La verdad es que noe stá suficientemente clara la funcion de este ente.

• Y se desean ver cuántos artículos (en total) provee la fábrica. También, por información
estratégica, se podría incluir información de fábricas alternativas respecto de las que ya
fabrican artículos para esta empresa

Esto no habla de entidades. Es la descripción de una consulta o una serie de ellas.
La base debe ser capaz de dar esa respuesta, pero sin crear ni entidades ni tablas nuevas. A lo más algunas vistas para simplificar procesos.
Nota: Los procesos no se representan en la base. Son temas de programación, no de arquitectura de datos.

¿Se va entendiendo el analisis?

Nota Bene: Cualquier supuesto sobre el que realices el trabajo, dejalo por escrito. Es decir, si vas a asumir que algo ocurre de una determinada forma, aunque no esté especificamente indicado en el planteo del problema, escribelo como premisa o supuesto de desarrollo. De ese modo te cubrirás de las objeciones que se puedan hacer a tu interpretación.

En la primera clase de Analisis de Sistemas I en la facultad, el profesor dijo: "Dos analistas, analizando el mismo problema, pueden llegar a soluciones diferentes y mutuamente excluyentes, y ambas ser correctas."
Y no e suna broma. Sucede todo el tiempo.

[jokerwad]

Gracias!! me vino de diez tu explicación, ahora voy entendiendo un poco más, me quedo super claro lo de pedidos que era lo que mas ruido me hacia.

Me surgió otra duda, las entidades débiles deben de ser SI O SI foráneas verdad? pero no toda entidad foránea es débil? es decir, en este caso, direcciones de envió es débil simplemente porque su FK hace referencia a la PK de cliente, o entiendo mal? en caso que una foránea no sea débil es porque cuenta con una PK que no hace referencia a la PK de la tabla padre, verdad?

Ademas, que una entidad debil, no tiene PK o si podria tenerla?

Gracias nuevamente!

[gnzsoloyo]

Me surgió otra duda, las entidades débiles deben de ser SI O SI foráneas verdad? pero no toda entidad foránea es débil? es decir, en este caso, direcciones de envió es débil simplemente porque su FK hace referencia a la PK de cliente, o entiendo mal? en caso que una foránea no sea débil es porque cuenta con una PK que no hace referencia a la PK de la tabla padre, verdad

Una entidad es débil no por poseer FK, sino por razón de existencia: Para existir debe existir su entidad fuerte correspondiente, de donde toma PK o parte de ella.
En el caso de las direcciones, éstas no peuden existir sin el Cliente, porque son direcciones del cliente.
Esencialmente se trata de datos opcionales, pero propios de una instancia de otra entidad. Ahora bien, la existencia de una cardinalida 1:N implica que además de heredar la PK de la entidad fuerte, debe poseer un discriminante que permita diferenciar cada tupla de la entidad débil. Esto se suele lograr agregando como parte de la PK, un campo identificatorio, que puede ser un numero secuencial (secuencia cerrada por cliente), o bien otro dato más.
Una entidad fuerte en un sistema es aquella que además de poseer PK propia, no requiere de la existencia de otra para ser instanciada.

Ademas, que una entidad debil, no tiene PK o si podria tenerla?

No confundir: Toda entidad tiene PK. Pero no todas tienen una PK propia, y no todas tienen una PK simple, ya que pueden requerir más de un atributo para ser definidas como tales.

A nivel físico, una tabla sin PK es una bolsa de datos basura. No pueden existir tablas sin PK.