Duda sobre BDD y relaciones...

[TRaFuGa]

Tengo un poco oxidado el tema de BDD y me ha surgido una duda usando el programa de gestión de mi empresa.
Resulta que tiene ARTICULOS con su stock, que pueden tener o no numeros de serie (IMEIS), por lo que cada artículo tiene su código (en este caso son los EAN) y si son por ejemplo accesorios van directos del stock que haya, y si son por ejemplo terminales tiran del "stock de imeis" (y hace falta poner el imei concreto...)
La cuestión es que para el próximo año voy a terminar el ciclo de DAW que me queda (4 asignaturas y el proyecto) y pensé en hacer una mini versión de dicho programita (que por cierto es un truño como un puño...) y algo muy importante es el control de stock de terminales con sus correspondientes IMEIS, pero no consigo sacar el diseño de dicha relación... xD :lamer:
Llevo unos días dándole vueltas y no consigo ver que relación pueden tener o si es que son artículos distintos (unos con stock y otros con su relación de imeis) y el programa busca en ambos el código proporcionado...

[Molondro]

Si lo he entendido bien, por un lado tendrías que tener una tabla con los "modelos", con un código como PK, que puede ser el código de producto según lo da el fabricante, o el correspondiente que useis vosotros. Por otro lado otra tabla, la del "stock", que contiene IMEI (la PK), el código del modelo, y otros datos que necesiteis. En la tabla "modelos" sacas el stock de cada modelo con un SELECT COUNT(*) FROM tbl_stock WHERE modelo LIKE *inserta aqui el modelo en cuestion*

no se si es esto lo que pedias o que, pero no parece muy complejo.

[Aiken]

creo que lo que tienes no es un modelo relacional directo, el modelo ha sido simplificado a la hora de implementarlo.

en realidad el modelo relacional creo que seria algo como:

- Articulos {cantidad en stock}
- Relacion(es un movil) entre Articulos e IMEIS
- IMEIS

Traducido a tablas, 3 tablas, 1 para artuculos, 1 para imeis, 1 tabla para la relacion.

Este modelo de libro, se ha simplificado con los "si son moviles TIRAN DE".
Pero en mi opinion, "TIRAN DE" no es algo que se pueda modelar en la base de datos es algo del software.

Nota: es mi humilde opinion, no soy ni mucho menos experto en bbdd relacionales.

[TRaFuGa]

Aiken es lo que me da la sensacion a mi, dos tablas de productos diferentes, una para el stock normal y la otra con las relaciones de imeis, y es el propio software el que hace esa distinción.
Realmente me liaba el tema de tenerlo solamente con una tabla de productos relacionada con los imeis...

[akualung]

una idea que igual es disparatada y no sirve, pero la suelto. quiza podrias tenerlo todo en una tabla y hacer una vista que filtre todos los productos de esa tabla que tengan imei, y entonces trabajar con esa vista cuando tengas que hacer algo con terminales o trabajar con la tabla normal cuando sean productos que tiran de ean normal . No sé, por probar...

[Nathrezim]

creo que lo que tienes no es un modelo relacional directo, el modelo ha sido simplificado a la hora de implementarlo.

en realidad el modelo relacional creo que seria algo como:

- Articulos {cantidad en stock}
- Relacion(es un movil) entre Articulos e IMEIS
- IMEIS

Traducido a tablas, 3 tablas, 1 para artuculos, 1 para imeis, 1 tabla para la relacion.

Este modelo de libro, se ha simplificado con los "si son moviles TIRAN DE".
Pero en mi opinion, "TIRAN DE" no es algo que se pueda modelar en la base de datos es algo del software.

Nota: es mi humilde opinion, no soy ni mucho menos experto en bbdd relacionales.

Si la relación siempre es uno a uno o uno a cero (accesorios que no tienen IMEI), ¿No sería mejor y más optimo y simple hacer un campo nullable dentro de la misma tabla? La clave será siempre el EAN, pero se podría poner un índice a la columna de IMEI para no hacer un full scan cada vez que se quiera hacer una búsqueda de un móvil, si es que se hacen muchas búsquedas a partir del IMEI, si no dejarlo como un campo tal cual.

Algo así:

PK EAN | IMEI | FK MODELO

[TRaFuGa]

Es otra opción, un segundo campo, pero no podría ser único (irrepetible) y null a la vez (mayormente porque 2 null ya serían iguales...). Lo que había pensado es una relación 0-N y un campo que indique si el producto maneja imeis, en este caso el stock del producto sera un campo calculado sobre los imeis disponibles en la otra tabla (deben de tener un estado indicando si estan vendidos, reservados o disponibles).
Aún no he podido dedicarle tiempo al diseño, pero me voy haciendo una idea...

[Nathrezim]

Es otra opción, un segundo campo, pero no podría ser único (irrepetible) y null a la vez (mayormente porque 2 null ya serían iguales...). Lo que había pensado es una relación 0-N y un campo que indique si el producto maneja imeis, en este caso el stock del producto sera un campo calculado sobre los imeis disponibles en la otra tabla (deben de tener un estado indicando si estan vendidos, reservados o disponibles).
Aún no he podido dedicarle tiempo al diseño, pero me voy haciendo una idea...

Depende del SGBD que estés utilizando, en Oracle por ejemplo tienes el campo unique, que permite nulos y si intentas meter dos valores iguales salta la restricción (obviamente los nulos no los comprueba).

De todas formas ¿el EAN en vuestro sistema que representa? ¿el modelo o un producto concreto? ¿puede haber dos artículos con el mismo EAN (del mismo modelo)? El esquema que estoy describiendo es para tener un EAN único.

[TRaFuGa]

Usaría mysql para el proyecto, para hacerlo con php/symfony2.
En cuanto al ean es unico para cada producto, es el codigo de barras... claro que puede haber dos productos iguales con distinto ean, pero para el sistema son dos productos distintos... por ejemplo, tenemos cargadores que son iguales y vienen con ean distinto, supongo que por fecha de fabricacion o porque hay algo que los diferencia y aun no me di cuenta...

[Nathrezim]

Entonces lo que te he dicho no vale :rolleyes: la relacion EAN - IMEI es 1 - N, el mismo modelo de telefono tiene cero o varios IMEIS asociados, uno por terminal.