27 respuestas en este tema

[FGarcia]

Hola!

Una base de datos, dos tablas:

======================
Tabla A    | Tabla B  |
======================
ID_A        | ID_B    |
FOLIO      | FOLIO    |
Campo A  | Campo X  |
Campo B  | Campo Y  |
Campo C  | Campo Z  |

ID_A e ID_B son las claves primarias de cada tabla.
FOLIO es un numero unico de documento. El "original" es creado en la tabla A.

La pregunta ¿Que cosa es FOLIO en la tabla B? ¿Una clave foranea? ¿Una Relacion?

Si es una relacion ¿que debo hacer en firebird para declararla? (IBExpert)

Aun me hago pelotas con las BD 

[enecumene]

Pues eso depende del uso que le des a FOLIO , puede ser una clave foránea, relación e incluso un índice, si nos explicas cual será el uso de ella.

Saludos.

[eduarcol]

Hola,

Folio es una clave foranea, por definicion las claves foraneas son las que determinan las relaciones, segun el ejemplo la relacion vendria siendo de uno en A a muchos en B,  para definirla en IbExpert es sencillo, abre la tabla y entras en la pestaña Constraints, dentro de estas veras otra llamada Foreign Keys, creas una nueva y rellenas los siguientes datos:

OnField Es el campo que sera la relacion en Tabla A
FkTable Es la tabla que relacionaras (Tabla B)
FkField el campo que se relacion en tabla B
Update y Delete Rule: Es la forma como se comportara la tabla B ante un cambio de la tabla A, tienes tres opciones
                Not Action: No hace nada y deja todo como esta
                Cascade: Replica los cambios del registro A en todos los relacionados en el registro B
                Set Null: elimina la relacion haciendo Nulo el campo.

Luego le das commit a la transaction y listo 
                 

[Delphius]

Hola FGarcia,
A me queda la duda si la estructura de tus tablas y sus campos son los adecuados.

Por empezar, si el campo FOLIO de tabla B debe ser foránea debería apuntar a la clave primaria de A. Y si fuera, el campo ID_A debería, conceptualmente expresar el número de folio por tanto podría llegarse a la conclusión de que el campo FOLIO en A es redundante y podría eliminarse.

Pero por el otro lado, la existencia de campos comunes por lo general implica la existencia, conceptual, de una tercera entidad (y relación) entre ambas. Lo cual constituye a una relación (M:M) o "muchos a muchos". Si FOLIO es un campo en común para A y B, debería estar presente en una tercera tabla intermedia C que posea al menos a este campo FOLIO, sus dos claves foráneas (una para A y otra para B) y posiblemente un campo ID.

Es posible, que dado el contexto que estás interpretando que exista una relación que no estás viendo. Sería de mucha utilidad que nos comentases más sobre el problema, el contexto, el dominio o ambiente. Que se espera de dichas tablas, y a que entidades concretamente hacen referencia o representan.

Considero oportuno bajar a tierra la abstracción. ¿Quien es A y quién es B?

Saludos,

[eduarcol]

Planteado de esa forma pareciese que ID_A  es un correlativo autonumerico, mientras que folio es realmente el numero de documento, entonces tratando de explicar un poco mas claro lo que dice nuestro amigo Delphius es que la clave foranea deberia ser ID_A que es la que realmente identifica el registro

[FGarcia]

"Espere.... estamos procesando la información"

"¡ALERTA!, SISTEMA SOBRECALENTADO, ¡NO HAY ESPACIO DE MEMORIA SUFICIENTE!"

"ERROR 186941. ¡FATAL ERROR!  EL SISTEMA SE REINICIARA"

[FGarcia]

    +1 

Bueno si, ID_A e ID_B son autoincrementables, unicos para cada tabla.

FOLIO es un numero unico de documento que se origina en la tabla A.

Los Campos X,Y,Z en la tabla B son datos complementarios para la tabla A. FOLIO es el campo que los relaciona.

Espero que este mas claro porque para mi se me resetea el sistema por Overflow

[luk2009]

hola

entiendo que deberias quitar el campo folio de la tabla B y poner en su lugar ID_A como llave foranea.
ya con eso estarias ralacionando correctamente las dos tablas.

[luk2009]

hola

entiendo que deberias quitar el campo folio de la tabla B y poner en su lugar ID_A como llave foranea.
ya con eso estarias ralacionando correctamente las dos tablas.

[Delphius]

Hola,
Mil disculpas si he provocado algunas sobrecargas.

Debo decir que ahora mi cerebro hizo una descarga, porque lo que dice eduarcol y luk2009 me confunde.

Yo, para poder entender apropiadamente las tablas y sus campos necesitaría de una explicación más detallada y precisa.

Si no es mucha molestia ¿a que te refieres cuando dices que los campos X,Y,Z son datos complementarios?
Yo no quisiera interpretar erroneamente y es por ello que pido que bajemos la abstracción. Nada de A,B,X,YZ.... las cosas por su nombre.

Si nos puedes comentar sobre las entidades y el contexto, ambiente va a ser mejor para poder interpetar adecuadamente el problema.

Cuando me dices que es información complementaria, mi cabeza entiende estas dos cosas:
1. Existe una relación (1:M) siendo la tabla B la "esclava" y A la maestra. O bien,
2. Se trata en realidad de una única tabla y lo mejor sería disponer de todos los campos en una sola.

Son dos situaciones mutuamente excluyentes. Si es el caso 1, B debería tener una clave foránea y no A. Obviamente, si es el caso 2, lo mejor es disponer de una sola tabla con los campos.

Recuerden que bajo las reglas normales, una relación 1-1 no existe.

Pido claridad por favor, se necesita de una visión concreta de las necesidades y uso de las tablas.

Saludos,

[enecumene]

Cuando se habla de datos complementarios se refiere a que son informaciones adicionales a lo que ya existe en la Tabla A.

Saludos.

[Delphius]

Cuando se habla de datos complementarios se refiere a que son informaciones adicionales a lo que ya existe en la Tabla A.

Saludos.

Eso lo entiendo perfectamente amigo. Quizá no se entendió el contexto y a lo que iba. La pegunta del millón de dólares es: ¿Que relación debe existir entre la tabla A y B? ¿Se puede, o debe, permitir añadir mucha más información adicional o complementaria?

Es decir: ¿Se espera, o se tiene pensado ir añadiendo información adicional a un registro?
Si es el caso es evidente la relación (1:M). Siendo la tabla B quien disponga de un campo ID_TablaA que actue de clave foránea hacia el campo ID_A de tabla A.

Pero he aquí, que si la información complementaria es de única vez, y no se espere más que una simple relación 1-1 es conveniente que esta información quede en A como un campo más. El ejemplo más evidente de información complementaria es el campo "Observaciones", que en ocasiones ni se llena. Este campo se añade, normalmente, para brindar información adicional sobre el registro. No se necesita, o mejor dicho, no se contempla, que puedan existir muchas observaciones.
Si fuera el caso de que se necesitaran más de una posible observación, allí si es es necesario y obligatorio el disponer de una segunda tabla (tal vez llamada Observaciones) con su propia clave primaria y la correspondiente clave foránea hacia la clave primaria de la primera tabla.

¿Me explico?

Saludos,

[Wilson]

    +1 

Bueno si, ID_A e ID_B son autoincrementables, unicos para cada tabla.

FOLIO es un numero unico de documento que se origina en la tabla A.

Los Campos X,Y,Z en la tabla B son datos complementarios para la tabla A. FOLIO es el campo que los relaciona.

Espero que este mas claro porque para mi se me resetea el sistema por Overflow

Amigo si las cosas son así, simplemente te sobra la tabla B, lo único que debes hacer es agregar los campos X, Y y Z a la tabla A.
Y si lo que quieres es obtener por separado X,Y y Z con una Vista bastaría.

Saludos

[eduarcol]

nos estams haciendo rollo sin necesidad, 

la relacion es 1 a M, el unico error es que lo relaciona con FOLIO la solucion esta como lo explico Luk2009,  las campos de la tabla B no sobran ya que se pueden tener varios datos en B para un solo registro en A

No se si hay algo que no este viendo

[Delphius]

¿Pues no molesta que lleve la contraria?

A mi humilde modo de ver, por las breves y abstractas explicaciones de FGarcía no puedo juzgar y afirmar con total certeza de que la relación sea (1:1), (1:M) o (M:M).

Si es necesario brindar mis fundamentos para cualesquiera de estas tres opciones las doy.

Puede ser cualesquiera. La cuestión es que no se puede deducir correctamente la relación sin una descripción y debida interpretación del contexto que se está analizando.

Lo correcto sería analizar el contexto y descubrir la relación y armar las tablas de forma adecuada. Aquí estamos en el caso inverso: tenemos las tablas y se pretende analizar y deducir el contexto. Es posible en ciertos casos deducirlo, pero en cuanto aparece un campo en común y con nombres tan abstractos las interpretaciones variarán por las tres tipos de relaciones posibles.

Con el perdón de FGarcia, y espero que me disculpe, creo que es necesario analizar mejor el problema.

Saludos,

[tmsanchez]

Aun me hago pelotas con las BD 

Que tal FGarcia, te paso éste link interesante que trata precisamente del diseño de bases de datos http://www.php-hispa...ales.html?pag=1

[FGarcia]

Mil disculpas por no haber respondido antes, pero en realidad he tenido que dejar de lado esto por otras cosas del trabajo, en cuanto lo retome les confirmo que es lo que ha pasado. Ahora me continuo preparando para salir de viaje.

¿Alguien gusta un tequilita de Arenal? o tal vez una birria de Guadalajara? ¿Que tal una torta ahogada? ¿o media ahogada?

Para refrescarme un rico y exquisito Tejuino!!!

[Fenareth]

Siiiiii, yo quiero una torta ahogada por favooooooor... o un delicioso plato de birria con tortillas recién hechas.... o ya de perdis un lonche de pierna que se me antoja a morir !!!!!!!!!!!!!!!!!!!!!!!

Grax ! , ese es todo el pedido

Saludox !

[FGarcia]

El lonche de pierna de con Amparito? alla donde la fuente de los niños "miones" o de algun otro lado en especial?

La birria la surto de con Chololo alla en Las Juntas.

[Fenareth]

El lonche de pierna de con Amparito? alla donde la fuente de los niños "miones" o de algun otro lado en especial?

La birria la surto de con Chololo alla en Las Juntas.

Excelentes opciones...

Y las tortas ahogadas ??? Claro ! de "Las Famosas", puede ser en Tlaquepaque

Ahhhh que buenos y sobre todo, deliciosos recuerdos

Saludox !