Problema con claves

El Sun, 7 Dec 2008 10:39:01 -0800, Alejandro Mesa escribió:

Estas seguro?

Sí.

Para estar en 5NF, debe cumplir con las formas normales anteriores, y creo
que este modelo no cumple con la forma normal 1

La 1 no cuenta y la estás interpretando mal. Además si cumples una forma
normal entonces automáticamente estás cumpliendo todas las anteriores.

La tabla cumple obviamente la tercera y por lo tanto cumple también la
segunda y la primera, que se cumple siempre que una tabla representa una
relación.

Mira esto que es un caso parecido:

http://www.dbdebunk.com/page/page/622301.htm

The commonly used example is wrong: such a table may be poorly designed,
but it is in 1NF.

dado la existencia de grupos
variables y repetitivos (telefono_1, telefono_2, telefono_3). Variables
porque no todos los empleados tienes la misma cantidad de telefonos, y
repetitivos porque la entidad o relacion telefono se repite.

Eso no son grupos repetitivos. Grupos repetitivos habría si la tabla fuese
algo como esto:

empleados(empleado_id,...,Telefonos)

Empleado Telefonos
Pepe 66666666
69696969
Manolo 55555555
88888888
99999999
Paco 11111111


Y esto no se puede hacer con SQL Server ni con una base de datos
relacional, si no que es cosa de los viejos sistemas tipo PICK.

Aunque se te ocurra poner los teléfonos en un campo Varchar(MAX) separados
por comas sigues estando en 1NF

En lo que sigue habiendo algo de controversia es en si una tabla que tenga
dentro otras tablas está en 1NF y la mayoría de los expertos y sobre todo
los mejores dicen que sí.


Saludos

Carlos M. Calvelo,

Estas claro, no expuse nada complicado ni de el otro mundo. Algo cotidiano
diria yo. En cuanto a la nueva columna [tipo], pues esta tendria un valor por
defecto [celular]
, o el [id] correspondiente al tipo [celular] en la tabla de [tipos de
telefonos] :-)

La mayoria de las veces que en un diseño vemos campos con nombres similares
y ademas un numero consecutivo anexado a ellos, como en el caso (empleado_id,
telefono_1, telefono_2, telefono_3), es una indicacion de que la tabla no
esta correctamente normalizada. Eso fue lo que me hizo pensar al principio
sobre la necesidad de normalizar esa tabla, pero sin saber lo que se modela
creo que no tengo razon en tal sugestion.


AMB


"Carlos M. Calvelo" wrote:

Hola Gustavo,

On 7 dec, 21:19, Gustavo Larriera (MVP)
wrote:
> Hola Alfredo Novoa,
>
> "Alfredo Novoa" wrote:
> > El Sun, 7 Dec 2008 09:57:00 -0800, Gustavo Larriera (MVP) escribió:
>
> > > No encuentro mención alguna en los posts al conjunto de dependencias
> > > (funcionales, de valores múltiples, de producto...) entonces cómo pueden
> > > ustedes sostener que el diseño está en una cierta FN ?
>
> > Por que en estos ejemplos son muy fáciles de deducir.
>
> > Todos sabemos que es empleado_id y telefono_1.
>
> No estoy de acuerdo, pues no creo que las dependencias sean fáciles de
> deducir, tampoco en estos ejemplos. Considerar que soy muy malo adivinando :-)
>
> Aunque todos sepamos qué pueda contener empleado_id o numero_celular_1 en
> base al nombre elegido, estamos a mucha distancia de poder conocer cuáles son
> las dependencias partiendo solamente de eso.
>
> De nuevo, el ejemplo a normalizar que puso Alejandro:
>
> empleados(empleado_id,...,numero_celular_1, numero_celular_2,
> numero_celular_3)
>
> Hasta que no sepamos bien cuáles son las dependencias que se cumplen, no que
> se pueda asegurar nada de qué FN se cumple. Qué sucederá si hay una
> dependencia entre los celulares?
>
> Debemos interpretar que lo que se quiso modelar es que el empleado tiene N
> teléfonos celulares y normalmente 3 es la cantidad de celulares que tiene?
> Puede tener solamente 2 o puede también no tener celulares? Los celulares son
> independientes entre sí? Puede un empleado usar el celular de otro empleado?
>
> Por ejemplo, qué decir si yo tengo un celular secundario cuyo número depende
> del celular principal al cual se le factura (el secundario es una especie de
> "extensión del servicio" y no factura por sí mismo). También es posible que
> yo use un celular un fin de semana cuando estoy de guardia, y otro empleado
> podrá usar ese celular en otro momento?
>
> A eso me refiero cuando digo que no se puede decir a tontas y a locas que se
> cumple una FN X. Simplemente es moverse en territorio imaginario :-)
>

Tienes toda la razón. No se pueden suponer esas dependencias
funcionales. Por eso yo he dado una posible interpretación al
problema que expone el OP, solo para dejar ver que si puede ser
un buen diseño para algún problema y que no se puede juzgar como
mal diseño o no normalizado sin saber de que situación se trata.
Que era lo que estaba pasando y creo que era simplemente porque
el OP tenía dos foreign keys haciendo referencia a la misma tabla.
Al menos esa es la impresión con la que me he quedado.

Sin embargo ahora la situación con el ejemplo de Alejandro es
diferente. Se supone que Alejandro está poniendo un ejemplo con
el que si hubiera esas dependencias funcionales lo hubiera dicho.
Y si no lo dice es porque su intención es que lo interpretemos
intuitivamente. La intención de Alejandro es simplemente dejarnos
ver que un empleado puede tener 0 o más teléfonos y que ese diseño
supuestamente no normalizado solo aceptará 3 teléfonos y que para
los empleados con menos de 3 teléfonos algunas columnas se quedarán
sin valor. Eso es todo.

Que esa es su intención se deduce además del diseño que presenta
como mejor y que supuestamente es resultado de haber normalizado
el primero.

Como todos entendemos el ejemplo intuitivamente, pues claro que
es un diseño mejor. Pero no tiene nada que ver con normalización
lo que está pasando aquí.
Hasta ha introducido nuevas tipos de datos (tipo de telefono) cuando
en el diseño original eran todos telefonos celulares.
Repito... mucho mejor diseño, porque todos intuimos lo que quiere
decir, yo diría que exactamente. Pero que eso sea el resultado de
normalización... no.

Vamos... que creo que mi mensaje es que no le busquemos cinco
pies al gato.

Saludos,
Carlos

El Sun, 7 Dec 2008 14:58:00 -0800, Alejandro Mesa escribió:

La mayoria de las veces que en un diseño vemos campos con nombres similares
y ademas un numero consecutivo anexado a ellos, como en el caso (empleado_id,
telefono_1, telefono_2, telefono_3), es una indicacion de que la tabla no
esta correctamente normalizada.

Que no, hombre. ¿No has leido todo lo que te he puesto?

Es una indicación de que la tabla no está bien diseñada, pero puede estar
normalizada igual, y de hecho lo está.


Saludos

Hola Alejandro,

On 7 dec, 23:58, Alejandro Mesa
wrote:

Carlos M. Calvelo,

Estas claro, no expuse nada complicado ni de el otro mundo. Algo cotidiano
diria yo. En cuanto a la nueva columna [tipo], pues esta tendria un valor por
defecto [celular]
, o el [id] correspondiente al tipo [celular] en la tabla de [tipos de
telefonos] :-)

Entiendo Alejandro. Lo del tipo es solo un detalle más.

La mayoria de las veces que en un diseño vemos campos con nombres similares
y ademas un numero consecutivo anexado a ellos, como en el caso (empleado_id,
telefono_1, telefono_2, telefono_3), es una indicacion de que la tabla no
esta correctamente normalizada.

Casi siempre es una indicación de mal diseño. Y un diseño que es
mejor es como el de tu ejemplo. Pero sigue sin tener nada que ver
con normalización. El diseño es malo pero la tabla está normalizada.

Normalización es un método de rediseño aplicando ciertas reglas.
Eso no quiere decir que normalización sea el único método para
conseguir mejores diseños.
Con sentido común y el conocimiento exacto de una situación
también podemos rediseñar y a menudo de tal manera que simplemente
normalizar no nos hubiera ayudado. Y es que un diseño puede estár
normalizado y ser malo. O un diseño puede ser malo y no hay
normalización que ayude.

Yo diría que después de que ya tenemos un diseño que consideramos
bueno, normalización es el método que nos ayudará a mejorarlo si
todavía tenemos dudas.

El método de rediseño que se está aplicando aquí es el del
sentido común.

Eso fue lo que me hizo pensar al principio
sobre la necesidad de normalizar esa tabla, pero sin saber lo que se modela
creo que no tengo razon en tal sugestion.

Supongo que te refieres al ejemplo del OP. Ese caso no es igual al
de los teléfonos. En el caso de los teléfonos el primer diseño es
malo porque todas las columnas repesentan el mismo tipo de dado sin
diferencia alguna en significado por estar un teléfono en una
columna o en la otra y porque para algunos registros tenemos
columnas de más y para otros de menos.
En el caso del OP (recuerda que dice tabla2 'relaciona' registros en
tabla1) las dos columnas repesentan el mismo tipo de dato pero que
dependiendo de en que columna esté un valor juega otro papel en la
relación. Imagínate relaciones como 'A es hijo de B', 'A le debe
dinero a B' o 'A invitó a una cerveza a B'. Que no es lo mismo que
decir que 'B es hijo de A', etc.

Como vés los casos son muy distintos y mi interpretación del
problema original es esta última. Pero el OP no aprecere. :-)

Saludos,
Carlos

Hola Carlos,

On 8 dic, 12:19, "Carlos M. Calvelo" wrote:

Normalización es un método de rediseño aplicando ciertas reglas.
Eso no quiere decir que normalización sea el único método para
conseguir mejores diseños.
Con sentido común y el conocimiento exacto de una situación
también podemos rediseñar y a menudo de tal manera que simplemente
normalizar no nos hubiera ayudado. Y es que un diseño puede estár
normalizado y ser malo. O un diseño puede ser malo y no hay
normalización que ayude.

Las reglas de normalización no son más que la formalización de unas
cuantas reglas de sentido común. Pero hay muchas más.

No hace falta saber sobre normalización para crear diseños
normalizados si se usa el sentido común. Pero por supuesto saber
ayuda :-)

Normalizar consiste en arreglar errores de diseño, y es mejor no
cometerlos desde el principio.



Saludos