Pregunta basica sobre claves primarias, foraneas y relaciones
#1
Escrito 26 septiembre 2009 - 11:57
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
#2
Escrito 27 septiembre 2009 - 06:47
Saludos.
#3
Escrito 27 septiembre 2009 - 09:07
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
#4
Escrito 27 septiembre 2009 - 10:24
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,
#5
Escrito 27 septiembre 2009 - 11:12
#6
Escrito 27 septiembre 2009 - 12:37
"Espere.... estamos procesando la información"
"¡ALERTA!, SISTEMA SOBRECALENTADO, ¡NO HAY ESPACIO DE MEMORIA SUFICIENTE!"
"ERROR 186941. ¡FATAL ERROR! EL SISTEMA SE REINICIARA"
#7
Escrito 27 septiembre 2009 - 12:49
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
#8
Escrito 27 septiembre 2009 - 01:55
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.
#9
Escrito 27 septiembre 2009 - 01:58
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.
#10
Escrito 27 septiembre 2009 - 02:13
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,
#11
Escrito 27 septiembre 2009 - 02:28
Saludos.
#12
Escrito 27 septiembre 2009 - 02:41
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?Cuando se habla de datos complementarios se refiere a que son informaciones adicionales a lo que ya existe en la Tabla A.
Saludos.
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,
#13
Escrito 27 septiembre 2009 - 03:03
+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
#14
Escrito 27 septiembre 2009 - 08:22
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
#15
Escrito 27 septiembre 2009 - 08:34
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,
#16
Escrito 30 septiembre 2009 - 09:29
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
#17
Escrito 01 octubre 2009 - 09:28
¿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!!!
#18
Escrito 01 octubre 2009 - 09:37
Grax ! , ese es todo el pedido
Saludox !
#19
Escrito 01 octubre 2009 - 09:50
La birria la surto de con Chololo alla en Las Juntas.
#20
Escrito 01 octubre 2009 - 10:02
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 !