10 respuestas en este tema

[felipe]

Comparto con ustedes esta inquietud, ya que muchas veces me pongo en duda la verdadera utilidad de estas tablas y serí­a bueno saber los diferentes conceptos de cada uno.

Saludos!

[off-topic]Si lo consideran pueden mover el foro donde corresponda[/off-topic]

[poliburro]

Vale aclarar un poco.

Para mi las tablas pivote son aquellas resultantes de extraer las filas de una tabla X y convertirlas en las columnas de una Tabla Y. De ser así­ amigo felipe puedo asegurarte que son en determnados casos necesarias. Un ejemplo:

Tienes una tabla de checadas diarias. Donde la tabla se compone de las columnas

CodEmp, FechaCheq, HorCheq


Ahora se te pide que de esa tabla, para cada empleado Digas el promedio de hora en que realizó su checada. Esto nos daria una tabla resultante con la siguiente estructura:

CodEmp, PromChequFechEne, PromChequFechFeb,..,PromChequFechdic

Para obtener esa tabla resultante debes convertir la información de las filas en columnas. Bajo esta situación una consulta o tabla pivote son necesarias.

Mi punto de vista unicamente.

Saludos.
             

[felipe]

Bien amigo Edgar, entiendo tu ejemplo... yo pensé la duda más que todo, en el inicio de un diseño de BD al encontrarnos relaciones Muchos a Muchos, y dado tu ejemplo es una manera diferente de ver los conceptos  , gracias por el aporte, ¿alguién más? 

Saludos!

[enecumene]

Perdonen mi ignorancia, pero...es la primera vez que oigo mencionar ese tipo de tablas, ¿donde consigo una información completa sobre ella? :$

Saludos.

[felipe]

Perdonen mi ignorancia, pero...es la primera vez que oigo mencionar ese tipo de tablas, ¿donde consigo una información completa sobre ella? :$

Saludos.

Es fácil amigo, solo se trata de aquella tabla intermedia que creamos cuando en nuestro MER tenemos relaciones Muchos a Muchos.

Saludos!

[poliburro]

La siguiente imagen muestra el uso de las tablas de relación que menciona felipe. Este es un diseño en access.

[root]

digo po rlo general soy medio bruto para eso de las DB pero que no hay en el ejemplo
la relacion siempre es de uno a muchos ???

hay se ilustra de 1 a ( no se como sale el 8 de ladito ) infinito
osea de 1 a muchos
igual estoy mal

[felipe]

digo po rlo general soy medio bruto para eso de las DB pero que no hay en el ejemplo
la relacion siempre es de uno a muchos ???

hay se ilustra de 1 a ( no se como sale el 8 de ladito ) infinito
osea de 1 a muchos
igual estoy mal

Precisamente esa es la funcion de esa tabla.

Propongo el siguiente ejemplo:

DetalleFactura <---> Items

¿Cuantos items puede tener un detalle de factura? y ¿cuantas detalles de facturas pueden tener items?

Esto da: Muchos a Muchos, solución: tabla pivot DetalleFacturaItems

DetalleFactura ---> DetalleFacturaItems <--- Items

Ahora bien, sucede que se puede hacer solamente esto si quisieramos:

DetalleFactura ---> Items

Por lo cuál planteo mi pregunta.

Saludos!

[eduarcol]

por regla general una relacion muchos a muchos no puede existir, por lo cual debe romperse con una relación o pivot, esto se debe principalmente a la forma como se maneja la clave foranea en el MER y el MOdelo Relacional.  Se dice que la clave foranea va siempre del lado de la relacion muchos, si hubiese esta relacion de muchos a muchos se estaria cruzando la clave foranea cosa que convertiria eso en una relacion uno a uno automaticamente.  Asi que desde mi humilde punto de vista es la razon de la existencia de las Pivot o Relaciones.

El ejemplo que pones de detallefacturas  -- items esta mal planteado, ya que lo correcto es como lo hicistes al final.  Se diria que UN Detalle factura tiene un solo item, mientras que UN Item esta en muchos detalles factura.  Siempre la ENtidad que comparas lo haces con un solo registro

Espero que se entienda

[Delphius]

Hola,
Es la primera vez que "escucho" el término PIVOT para referirse a las tablas intermedias.

Habí­a escuchado sobre tablas dinámicas, y campos PIVOT, que son ampliamente usados en los cubos de datos para los sistemas de tomas de decisiones, data minning, etc.

Yo en una ocasión hablé sobre el tema de la relación muchos a muchos en YR, y también se trató de forma breve en clubdelphi (Véase desde el post 47).

En resumen, la relación M:N es una manifestación en lo general y debe romperse puesto que las bases de datos trabajan en lo particular. La relación M:N implica una serie de sucesos individuales y es por ello que se necesita un nuevo grado de abstracción a fin de representar y registrar la información detallada.

Ahora bien, la pregunta de si es útil o no... pues yo dirí­a... que será útil en la medida en que su presencia permita representar algún elemento de la realidad útil para el dominio.

Si se tiene la certeza de que la tabla intermedia no contendrá más de x registros (siendo x algún número bastante inferior como para justificar la no presencia de dicha tabla), puede, en un principio, obviarse y transformar dichos registros en campos para la tabla una de sus tablas maestras. Aunque deberí­a verse, si esto afecta en alguna otra parte de las relaciones con otras entidades.

Saludos,

[felipe]

por regla general una relacion muchos a muchos no puede existir, por lo cual debe romperse con una relación o pivot, esto se debe principalmente a la forma como se maneja la clave foranea en el MER y el MOdelo Relacional.  Se dice que la clave foranea va siempre del lado de la relacion muchos, si hubiese esta relacion de muchos a muchos se estaria cruzando la clave foranea cosa que convertiria eso en una relacion uno a uno automaticamente.  Asi que desde mi humilde punto de vista es la razon de la existencia de las Pivot o Relaciones.

El ejemplo que pones de detallefacturas  -- items esta mal planteado, ya que lo correcto es como lo hicistes al final.  Se diria que UN Detalle factura tiene un solo item, mientras que UN Item esta en muchos detalles factura.  Siempre la ENtidad que comparas lo haces con un solo registro

Espero que se entienda

Claro Eduardo, es entendible y obvio lo que expones... marque allí­ donde mencionas la relación ejemplo que propuse, no es que este mal planteada, solo es la base para definir las demás; allí¬ es donde podemos decir: Muchos items en el detalle y muchos detalles con un mismo item, espero se entienda 

Este tema se pone interesante 

Saludos!