Problema con claves

Hola Carlos M. Calvelo,

"Carlos M. Calvelo" wrote:

> Está clarísimo que el no poder hacer lo que mooonk quiere es un
> defecto de SQL Server que debería de ser arreglado. Y como no lo van a
> arreglar en muchos años o nunca entonces lo mejor será usar un
> trigger.
>

O pasarse a D4 (Dataphor) :-)

Dataphor es una interesante iniciativa sin dudas.

Pero, es un juguete adecuado para aprender teoría relacional (tal como dicen
sus propios autores) al que le faltan años para convertirse en un producto
mainstream como para acercarse a Oracle, DB2, SQL Server, y aún los DBMS open
source más populares.

Para las cosas en serio, seguiremos con los triggers pues :-)

Saludos
~gux

Hola Gux,

El Sun, 7 Dec 2008 12:38:05 -0800, Gustavo Larriera (MVP) escribió:

Pero, es un juguete adecuado para aprender teoría relacional (tal como dicen
sus propios autores) al que le faltan años para convertirse en un producto
mainstream como para acercarse a Oracle, DB2, SQL Server, y aún los DBMS open
source más populares.

No es así. Dataphor es un middleware que puede usarse con los DBMS que
citas y sí que se puede usar perfectamente para cosas serias.


Saludos

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 12:19:00 -0800, Gustavo Larriera (MVP) escribió:

No estoy de acuerdo, pues no creo que las dependencias sean fáciles de
deducir, tampoco en estos ejemplos.

A veces es muy fácil y otras imposible. En estos casos es normal suponer
que solo existen las dependencias obvias. Si hubiese más nos las habrían
dicho.

En el ejemplo de moooonk nos las dice él mismo.

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?

Si ocurriese una cosa tan absurda supongo que Alejandro nos habría avisado.
Así que supongo que los tres número de teléfono y lo que hay entre puntos
suspensivos depende de empleado_id y de nada más.

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?

Para lo que estamos discutiendo da igual. Nada de esto tiene que ver con
las formas normales. Excepto que un número de telefono dependa de otro,
cosa que es completamente absurda.

Ya me dirás en que afecta a la forma normal de la tabla a quien se le manda
las facturas de los teléfonos X-D

La verdad es que me dejas perplejo.


Saludos

Hola Gustavo,

On 7 dec, 21:38, Gustavo Larriera (MVP)
wrote:

Hola Carlos M. Calvelo,

"Carlos M. Calvelo" wrote:
> > Está clarísimo que el no poder hacer lo que mooonk quiere es un
> > defecto de SQL Server que debería de ser arreglado. Y como no lo van a
> > arreglar en muchos años o nunca entonces lo mejor será usar un
> > trigger.

> O pasarse a D4 (Dataphor) :-)

Dataphor es una interesante iniciativa sin dudas.

Es muy interesante. Y no por el ejemplo que puse que no es
nada.. sino por otras muchas mas cosas.

Pero, es un juguete adecuado para aprender teoría relacional (tal como dicen
sus propios autores) al que le faltan años para convertirse en un producto
mainstream como para acercarse a Oracle, DB2, SQL Server, y aún los DBMS open
source más populares.

Juguetes de esos si que existen. Pero este no es juguete.

Para las cosas en serio, seguiremos con los triggers pues :-)

Con los triggers seguiremos muchísimo tiempo. Pero por otras
razónes. No porque no haya alternativas, sino por razones de
mercado y porque todo lo que no sea SQL lo va a tener muy
difícil.

Saludos,
Carlos