Duda creando una BD

[alyciashape]

Hola a todos, hace mucho tiempo que no hago una base de datos y tengo dudas.

Necesito generar unas estadísticas para una lista de empresas. Necesito el nombre del producto y la evolución del precio, el cual saco con cURL, para cada empresa. Supongo que recogiendo la fecha (dia - mes - año) y aparte la hora me será más que suficiente. Luego la idea es mostrar por días el precio con una gráfica pues con la hora y el precio en sí.

La duda son las tablas que necesito. Sobre el papel me salen dos pero en mi mente se que son 3.

Creo que sería así:

Empresa
id_empresa
nombre

articulo
id_articulo
nombre
fecha
hora
precio

Pero mentalmente me da que la fecha hora y precio sería con una tabla nueva. No estoy muy seguro. Como sería la mejor opción? Actualmente mi idea es hacerlo así:
EMPRESA
id_empresa
nombre

ARTICULO
id_articulo
nombre

EMPRESA_ARTICULO
id_empresa + id_articulo
fecha
hora
precio

Edicion:
Para esta última tabla tendría que poner otro id_empresa_articulo ya que sino se me repiten datos claro. Porque un precio del mismo articulo se repite muchas veces para la misma empresa, aunque a diferentes horas.
EMPRESA_ARTICULO
id_empresa_articulo
id_empresa
id_articulo
fecha
hora
precio

El problema es que así tendría muchos id_articulo duplicados. 1 por cada vez que se cambia de precio y para cada empresa. No se si es correcto. Alguna ayuda?

[Uncontroled_Duck]

Si la finalidad es estadísticas de precios, y estos han cambiado en el mismo articulo, necesitas tres tablas con relación OneToMany.

De la siguiente forma tendrás:
Una empresa con varios artículos.
Cada artículo, se asocia con la empresa mediante "id_empresa" de la tabla Articulo
Cada precio, se asocia con su artículo mediante "id_articulo" de la tabla Precio

Código:

-Empresa
id_empresa
nombre

-Articulo
id_articulo
id_empresa
nombre

-Precio
id_precio
id_articulo
fecha
hora
precio

Espero sea de ayuda.

Saludos,

[alyciashape]

Muchas gracias,
Ahora mismo lo tenía casi así, pero me sobraba el id_empresa del precio. Claro, ya queda relacionado con el artículo y este con la empresa, no es necesario volver a ponerlo.

EDIT: Algo no me cuadra bien. Tal como está, para saber el precio actual de un artículo para una empresa determinada es posible? Quiero decir. Así tendré que crear 1 artículo con el mismo nombre 1 vez por cada empresa. Y hay como 10. Lo veo como que muchos datos duplicados no? Tal vez me expresé mal, pero los artículos son los mismos para todos.

Es decir. Vuelvo a explicar aver si se me entiende mejor.
Tenemos empresas, articulos y precios. Una empresa puede tener 1 o mas articulos, y 1 articulo puede estar en 1 o mas empresas. Y un articulo tiene 1 o mas precios (segun la empresa) y un precio está en uno y solo un articulo supongo.

No se, algo no me cuadra :D sigo dandole vueltas

[alyciashape]

¿Poner los atributos en la relación en la nueva tabla que se crea (ya que es una relación N:M) sería correcto? Es decir me quedaría así:

EMPRESA
· id_empresa (PK)
· nombre

VENDE
· id_empresa (PK, FK)
· id_articulo (PK, FK)
· fecha (PK)
· hora (PK)
· precio

ARTICULO
· id_articulo (PK)
· descripcion
· fabricante

Es que me suena. Antes se me daban muy bien las DB pero hace tanto tiempo que no hago que soy un mar de dudas. Lo que no me cuadra así son tantas primary keys en VENDE

[jurena]

No sé si para las estadísticas te pedirán rangos de fechas, es decir, durante cuántos días estuvo vigente un precio en una empresa, media de días, etc. Esto te obligará a poner fechainicioempresa, fechafinempresa para cada precio.

ARTICULO
· id_articulo (PK)
· descripcion
· id_fabricante (FK)

EMPRESA
· id_empresa (PK)
· empresa

FABRICANTES
· id_fabricante (PK)
· fabricante


PRECIOS_EMPRESA
· id_empresa (FK)
· id_articulo (FK)
· fecha_hora_inicio_precio_empresa
· fecha_hora_fin_precio_empresa
· precio
PK (id_empresa, id_articulo, fecha_hora_inicio_precio_empresa)
Uso esta PK por no usar un autoincrementable, y puesto que una misma empresa no tendrá dos precios distintos para el mismo producto con la misma fecha_hora de inicio. Así no repetirás.
Preguntarás que cómo sabes la fecha de fin de precio de un producto para una empresa; pues con la fecha_hora_inicio_precio_empresa del siguiente precio en fecha para ese producto en la misma empresa, claro. Para cargar eso necesitarás algo de programación, creo.

[alyciashape]

Gracias me ha quedado más claro. La verdad es que estoy probando tal y como lo puse hace un rato y me va bastante bien. Aunque igual lo cambio por algunas cosas que pusiste como lo de inicio_precio. Pero no se si me será muy útil ya que cambian el precio cada 30 minutos o 60 minutos máximo. Pero la idea me parece fantástica, gracias.

Y los fabricantes por separado no me había dado cuenta pero es cierto, es lo más lógico. Aunque son muy pocos. Como 6. Pero aún así vale la pena ponerlos por separado ¿no?

[jurena]

ya que cambian el precio cada 30 minutos o 60 minutos máximo. Pero la idea me parece fantástica, gracias.

Tampoco sé yo exactamente cuáles son los datos y si cuando hablas de entre 30 o 60 minutos te refieres a una cifra exacta de media hora o de hora completa. Si es así, yo crearía el campo duración, de tipo time, que podría contener sólo dos valores o 00:30:00 01:00:00
En fin, tú eres quien ves los datos y tienes que establecer los rangos...

Como 6. Pero aún así vale la pena ponerlos por separado ¿no?

Esto siempre es conveniente. Me explicaré. Ahora solo tienes los nombres de los 6 fabricantes, sin atributos, pero mañana te piden que hagas estadísticas con los atributos de los fabricantes, fecha de creación de esa empresa, lugar de implantación, especialización, etc., y entonces lamentarás no haber creado esa simple tabla de fabricantes en la que podrías añadir fácilmente esos atributos. Por lo demás, si te resulta más conveniente usar el nombre del fabricante como Foreign key, pues lo haces también en la tabla de fabricantes..., aunque yo te aconsejaría cierta previsión por si el número de fabricantes aumentara y pudiera darse coincidencia de nombre. Una clave primaria única y más estable, aunque fuera una clave compuesta... Pero eso es quizás complicarte la cosa.