[SOLUCIONADO] Estructura de tablas óptima.

[asabervgz]

Os propongo una estructura de tablas y relaciones para solucionar un problema. Me podéis decir si está bien planteada o si por el contrario habría otra solución mejor? Gracias.

- Vamos a guardar en una base de datos por ejemplo el contenido de diferentes neveras.
- Cada nevera contendrá ciertos productos.
- Algunos productos podrán ser de diferentes tipos o no.
- Puede haber varios productos iguales pero de diferente tipo.
- Algún producto podría no tener el tipo especificado.

- Por ejemplo: La nevera 1 contiene fruta del tipo pera, también contiene fruta del tipo manzana. también hay leche que podría ser entera, desnatada o semidesnatada. También contiene huevos(sin tipo).

- La estructura que yo planteo es la siguiente:
* Una tabla NEVERAS con campos ID_Nevera y Nombre_Nevera.
* Una tabla PRODUCTOS con campos ID_Productos y Nombre_Productos.
* Una tabla NEVERAS_PRODUCTOS con campos ID_Nevera e ID_Productos para establecer una relación de muchos a muchos entre las dos tablas anteriores.

- Ahora es cuando me entra la duda de si la tabla PRODUCTOS debería contener todos los tipos de producto:
* fruta manzana
* fruta pera
* fruta melocotón
* fruta(sin especificar)
* fruta ........
* leche entera
* leche semi
* leche desnatada
* ...

- O si sería mejor que solo contuviese los productos en general:
*fruta
*leche
*huevos
*...

- Y a parte creara otras tablas para contener los tipos de cada producto:
TABLA FRUTA
*manzana
*pera
*melocotón
*...

TABLA LECHE
*entera
*semi
*desnatada

- Para después relacionar cada producto con su tipo.
- Esta relación es la que se me complica más. Quizás añadiendo a la tabla PRODUCTOS dos campos más TIPO e ID_TIPO para que cada producto tenga asignado su tipo (fruta, leche, ...) y la ID del tipo dentro de esa tabla (manzana, pera, melocotón).

- La primera solución me parece más sencilla pero creo que se repiten cosas y no es lo más adecuado y la segunda solución creo que se me está complicando demasiado o algo se me escapa.

- Lo que no me cuadra del segundo método es tener que utilizar dos columnas de más para determinar el tipo de producto.

[HackmanC]

Hola,

Posiblemente,

Iniciado por asabervgz

... Me podéis decir si está bien planteada o si por el contrario habría otra solución mejor? ...

En mi opinión personal, posiblemente, estás obviando algunos conceptos en esa estructura.

Acabo de ir al mercado, y vi que allí estaban todos los vendedores, y todos tenían diferentes productos, unos tenían productos similares pero no iguales y en otros casos los productos eran exactamente los mismos.

Así que me dispuse a comprar manzanas, me acerqué al primer vendedor, le solicité que me mostrara las manzanas y después la leche, pero por favor que los huevos no me los mostrara.

Lo que hizo el vendedor es pedirme amablemente que pasara a la sección de frutas, donde había un cartel que decía Frutas, un área grande y amplia donde habían todo tipo manzanas, peras, albaricoques y demás. Después que pasara a la sección de lácteos, también con un cartel y que decía Lácteos, el área era mucho mas pequeña, además me dijo que no me preocupara, que los huevos no me los iba a enseñar.

Así que al final me dí cuenta de algo, que la organización de los productos del vendedor tenía esta estructura:

Código:

Nevera1 -> Frutas  -> Manzanas -> Manzanas Orientales
                               -> Manzanas Occidentales
                   -> Peras
        -> Lacteos -> Leche    -> Leche de Muuu -> Descremada
                                                -> Pasteurizada
                               -> Leche de Bhee
        -> Otros   -> Huevos

Es decir, no tenía mezclada la Leche con las Frutas, y me pareció muy lógico; porque en sí la palabra Leche no es una palabra tan genérica como Frutas.

Es decir, con decir Frutas yo no sé a cual me refiero mientras que al decir Leche, ya sé que no es cualquier derivado de la vaca. Aún cuando todavía se puede dividir en varios tipos de leche, no es lo mismo que cualquier derivado de la vaca, como similitud con cualquier derivado de Frutas.

Por cierto, después le pregunté si tenía huevos, después de unos segundos de silencio, son sonreímos cada quien por su cuenta, sino hubiéramos actuado así sido una situación incómoda, y sin mencionar una palabra adicional me entregó una docena de huevos.

Ahora ya un poco más técnico, en tu punto de vista, de poner un tipo de producto, estarías produciendo que en algún momento, exista la posibilidad que al producto Leche se le ponga el tipo Frutas.

En la tabla Neveras y Productos, la estructura posiblemente sería así:

Código:

ID_Nevera
ID_Seccion
ID_Producto
ID_Tipo_Producto
ID_Sub_Tipo_Producto

Por la integridad referencial, no puedo meter en esa tabla un ID_Producto que no pertenezca a la ID_Seccion correspondiente, es decir no puedo meter Huevos en Frutas.

También depende de los lenguajes de programación que vayas a usar, en Java y .NET es pan comido esa estructura. Posiblemente no sea así en Python o PHP, aunque no voy a discutir eso, simplemente es mi punto de vista.

En resumen, si comprendes bien el objetivo de la estructura que deseas lograr, se te va a ser mas fácil tomar las decisiones de diseño correctas, no porque en general las manzanas sean frutas, tienes que obligadamente hacer el diseño que propuse, depende de muchas cosas.

Saludos,

ps:

Muchas personas, simplemente va a tener Nevaras, Productos y posiblemente Neveras X Productos. De allí se va como caiga y como Dios les dé licencia.

[asabervgz]

Gracias por la respuesta.

La parte lógica está muy bien, me parece muy lógica y normal y no tengo ningún problema con ella pero en la parte técnica, lo siento pero sigo igual que estaba.
Creo que me estás diciendo que cree la siguiente estructura:

tabla NEVERA con campos ID etc...
tabla SECCION con campos ID y NOMBRE(1 = frutería, 2 = lácteos, 3 = otros).
tabla PRODUCTO con campos ID y NOMBRE (1=manzanas, 2=peras, 3=melocotones, 4=lechedevaca, 5=lechedeoveja, 6=huevos).
tabla SUBPRODUCTO con campos ID y NOMBRE (1=orientales, 2=occidentales, 3=desnatada, 4=entera, 5=semi)

tabla NEVERAS_PRODUCTOS con campos NEVERA.ID, SECCION.ID, PRODUCTO.ID, SUBPRODUCTO.ID (1, 2, 4, 4)(Para la nevera 1, sección de lácteos, leche de vaca, entera).

- Aquí aún sigo sin verlo ordenado. Los productos están todos mezclados y los subproductos aún más.
- Quizás sean necesarias las tablas PRODUCTOS_FRUTERIA, PRODUCTOS_LACTEOS Y PRODUCTOS_OTROS. Siguiendo esta línea, con los subproductos ya sería una locura de tablas que aumentarían casi de forma exponencial.

¿Podrías describirme la estructura de tablas que tu crees más conveniente?

[leonardo_josue]

Hola asabervgz:

Voy a meter también mi cuchara en este asunto. Lamentablemente (o afortunadamente) no hay un "mejor modelo" o un "modelo ideal" de BD's para estas cuestiones... esto depende completamente de tus necesidades. Sin embargo, debes de tener cuidado con algunos puntos.

Hay que tener en claro qué es lo que quieres "guardar" o "administrar" con tu BD's. Tal como lo planteas, tu necesidad es controlar qué PRODUCTOS están en qué NEVERAS. Desde mi punto de vista, HackmanC se enfocó más bien en un sistema de CLASIFICACIÓN DE PRODUCTOS, utilizando no un modelo E-R, sino más bien un modelo Jerárquico, ese es un enfoque distinto.

El modelo de HackmanC, insisto, está pensado en saber qué producto DEBES DE PONER en qué nevera (lo que facilitaría encontrar fácilmente esos productos y no tener necesidad de preguntarle a los empleados acerca de los huevos), pero si entendí bien, lo que tú planteas es un modelo para saber qué productos ESTÁN en qué nevera (aunque no necesariamente esto implique que los productos tengan qué estar ordenados).

Partiendo de esto último, el modelo original que planteas, es correcto:

Código:

* Una tabla NEVERAS con campos ID_Nevera y Nombre_Nevera.
* Una tabla PRODUCTOS con campos ID_Productos y Nombre_Productos.
* Una tabla NEVERAS_PRODUCTOS con campos ID_Nevera e ID_Productos para establecer una relación de muchos a muchos entre las dos tablas anteriores.

Este como dice HackmanC sería un modelo bastante básico, y como tú mismo infieres, puede traer mucha información repetitiva, sin embargo, partiendo de este modelo, puedes hacer la NORMALIZACIÓN que te permita eliminar (o por lo menos minimizar) esta información aparentemente 'duplicada'

Del lado de las NEVERAS, creo que no hay problema... en el caso de los PRODUCTOS es donde puedes hacer aun varias desagregaciones. Al poner tu lista de productos, planteas algo como eso:

Código:

* fruta manzana
* fruta pera
* fruta melocotón
* fruta(sin especificar)
* fruta ........
* leche entera
* leche semi
* leche desnatada
* ...

por lo tanto, puedes observar que aquí hay información REPETITIVA... lo qué procede entonces es sacar esa información como un catálogo, de tal manera que tus tablas entonces quedarían así:

Código MySQL:

mysql> SELECT * FROM categorias;
+--------------+-------------+
| id_categoria | descripcion |
+--------------+-------------+
|            1 | frutas      |
|            2 | leche       |
+--------------+-------------+
2 rows in set (0.00 sec)
 
mysql> SELECT * FROM productos;
+-------------+--------------+-------------+
| id_producto | id_categoria | descripcion |
+-------------+--------------+-------------+
|           1 |            1 | manzana     |
|           2 |            1 | pera        |
|           3 |            1 | melocotón   |
|           4 |            2 | entera      |
|           5 |            2 | semi        |
|           6 |            2 | desnatada   |
+-------------+--------------+-------------+
6 rows in set (0.00 sec)
 

Tus tablas NEVERAS y NEVERAS_PRODUCTOs, no necesitan tener ninguna modificación.

Así, puedes continuar con el resto de los atributos que estás guardando en tu tabla, cuando encuentres datos repetitivos, estos los puedes sacar como CATALOGOS, y manejar solamente su índice.

Insisto, no hay un modelo único, ni mejor o peor... todo depende de tus necesidades.

Saludos
Leo.

[asabervgz]

En mi primer mensaje puede que mezclara un poco huevos(especifico) con leche(genérico) y con fruta(aún más genérico), sé que no es lo más lógico pero solamente era para dejar claro que ciertos productos podrían tener diferentes variantes y otros no. GRACIAS HackmanC por tu orden!!!

En el tema de relacionar las tablas para que tengan bien definida una jerarquía no iba yo muy desencaminado por lo visto, simplemente no había colocado la columna ID adecuada (id_categoría)en el sitio correcto para impedir tener la nevera llena de "HUEVOS DESNATADOS" o "LECHE DE PERAS". GRACIAS leonardo_josue!!!

Marco como solucionado antes de que se metan los huevos del tendero en las tablas :)

[HackmanC]

Hola,

Iniciado por leonardo_josue

... Lamentablemente (o afortunadamente) no hay un "mejor modelo" o un "modelo ideal" de BD's para estas cuestiones... esto depende completamente de tus necesidades. ...

Definitivamente no pudiste ponerlo mas claro, y exactamente ese era el punto clave en mi propuesta.

Iniciado por leonardo_josue

... Desde mi punto de vista, HackmanC se enfocó más bien en un sistema de CLASIFICACIÓN DE PRODUCTOS, utilizando no un modelo E-R, sino más bien un modelo Jerárquico, ese es un enfoque distinto.

El modelo de HackmanC, insisto, está pensado en saber qué producto DEBES DE PONER en qué nevera (lo que facilitaría encontrar fácilmente esos productos y no tener necesidad de preguntarle a los empleados acerca de los huevos), ...

Tienes razón en parte, el modelo que yo mostré no es un modelo, era una visión gráfica de la distribución de los productos que tiene uno de los vendedores del mercado que está cerca de mi casa. Yo no diseñe una estructura, no demostré las relaciones, ni la estructura de las tablas. Si de alguna forma se llega a la conclusión que esa debería ser la estructura de las tablas en ese caso pues entonces estamos bien, por mi no hay problema.

La única parte donde mostré algo relacionado al área técnica fue en la estructura de la tabla Neveras X Productos, pero no dije de donde venía Tipo_Producto, ni Sub_Tipo_Producto (que le llamas categorías). Igual si se llega a la conclusión que esas son tablas de relación entonces al parecer seguimos bien, entonces deberían ser tablas de relación E-R, por mi no hay problema tampoco en este caso.

Es decir, yo no te contradigo, posiblemente tu mires un modelo en jerarquía. Aunque un verdadero modelo en jerarquía es completamente diferente, como el caso de las bases de datos No-SQL, las cuales conozco muy bien.

La única diferencía en el concepto inicial y el mio es que yo metí un concepto adicional llamado Sección, que me permite seccionar las frutas de los lácteos, aunque repito, yo no dije en donde iba.

Iniciado por leonardo_josue

...

Código MySQL:

mysql> SELECT * FROM categorias;
+--------------+-------------+
| id_categoria | descripcion |
+--------------+-------------+
|            1 | frutas      |
|            2 | leche       |
+--------------+-------------+
2 rows in set (0.00 sec)
 
mysql> SELECT * FROM productos;
+-------------+--------------+-------------+
| id_producto | id_categoria | descripcion |
+-------------+--------------+-------------+
|           1 |            1 | manzana     |
|           2 |            1 | pera        |
|           3 |            1 | melocotón   |
|           4 |            2 | entera      |
|           5 |            2 | semi        |
|           6 |            2 | desnatada   |
+-------------+--------------+-------------+
6 rows in set (0.00 sec)
 

Tus tablas NEVERAS y NEVERAS_PRODUCTOs, no necesitan tener ninguna modificación.

El único problema que miro yo en eso es que puedes poner las peras en la categoría de leche mas fácilmente que en el concepto de meter un discriminador adicional llamado sección. La sección me va a dar un discriminador inicial, por ejemplo, en mi interface gráfica, primero tengo que pedir la sección, después el producto. Clásicos Combo's relacionados, como Pais, Departamento, Localidad, Zona, etc., en jerarquía o cascada.

Ojo que yo nunca dije en que lugar exactamente iba Sección, podría ser igual a tu concepto de categorías, pero yo propuse además de las categorías, también secciones. Adicionalmente, en mi caso, lo que llamas categorías se llaman Tipo_Producto, Sub_Tipo, etc.

Iniciado por asabervgz

... sé que no es lo más lógico pero solamente era para dejar claro que ciertos productos podrían tener diferentes variantes y otros no. ...

Si hay demasiadas variantes, es decir, no sabes exactamente cuantas cualidades van a tener los productos entonces no necesitas usar un tipo. En otras palabras, si no está normalizado, no se puede normalizar.

Saludos,

ps:

La parte de los huevos era un chascarrillo, común por estos lares.

Iniciado por HackmanC

ps:

Muchas personas, simplemente va a tener Nevaras, Productos y posiblemente Neveras X Productos. De allí se va como caiga y como Dios les dé licencia.

[HackmanC]

Hola,

Posiblemente,

Iniciado por asabervgz

¿Podrías describirme la estructura de tablas que tu crees más conveniente?

Posiblemente, y digo posiblemente, porque existen miles de formas de pensar y miles de forma de diseñar lo mismo, en lo que respecta al vendedor de la esquina, posiblemente así mires mas claro mi propuesta:

create table NEVERA (
ID_NEVERA
)
1

create table SECCION (
ID_SECCION
)
frutas
lácteos

create table PRODUCTO (
ID_SECCION
ID_PRODUCTO
)
frutas manzanas
lácteos leche

create table SUBPRODUCTO (
ID_SECCION
ID_PRODUCTO
ID_SUBPRODUCTO
)
frutas manzanas orientales
lácteos leche descremada

create table NEVERAXPRODUCTOS (
ID_NEVERA
ID_SECCION
ID_PRODUCTO
ID_SUBPRODUCTO
)
1 frutas manzanas orientales
1 lácteos leche descremada

SELECT * FROM NEVERAXPRODUCTOS
WHERE ID_SECCION = 1 -- 'frutas'
AND ID_NEVERA IN (SELECT * FROM PRODUCTO WHERE ID_PRODUCTO != 1 -- 'frutas manzanas')

Seguramente se mira una jerarquía allí, porque está pensado para ese vendedor de la esquina. Aunque no es una estructura de datos jerárquica per sé.

¿No te gustan las jerarquías?

create table NEVERA (
ID_NEVERA
)
1

create table SECCION (
ID_SECCION
)
frutas
lácteos

create table PRODUCTO (
ID_PRODUCTO
)
manzanas
leche

create table SUBPRODUCTO (
ID_SUBPRODUCTO
)
orientales
descremada

create table NEVERAXPRODUCTOS (
ID_NEVERA
ID_SECCION
ID_PRODUCTO
ID_SUBPRODUCTO
)
1 frutas manzanas orientales
1 lácteos leche descremada

Aprovechando que todavía puedo editar este post, posiblemente exista una confusión de mi parte con la palabra jerarquía, para mi las jerarquías son como los árboles binarios. De igual forma la estructura básica es la misma una vez no sean arboles binarios, la 'sección' la puedes cambiar de lugar a casi cualquier tabla.

Saludos,