Problema con claves

Ya, por eso te lo decía :-)

Lo de los nulos complica la cosa, pero no creo que eliminar nulos se deba
de llamar normalizar. Es más bien "entrar" en el Modelo Relacional. Yo
creo
que "normalizar" es mejor usarlo solo para lo relacionado con las
dependencias funcionales.

Me gustaría haber visto que yo u otra persona fuera quien hubiese dicho que
normalizaba ese ejemplo para producir 4 tablas me imagino la sarta de
insultos y burlas por parte de ustedes.
Pero no!! ahora admiten su metida de pata y no pasa nada!

Mejor no entremos a la segunda FN...

Ves, por fin admites culpa en algo. eres digno de felicitarte!

pero no lo vuelvas a hacer, que no simpre puedo estarte explicando todo!
:)))

"Carlos M. Calvelo" escribió en el mensaje
news:
Hola Alfredo,

On 9 dec, 12:01, Alfredo Novoa wrote:

Yo creo
que "normalizar" es mejor usarlo solo para lo relacionado con las
dependencias funcionales.

Exactamente eso es lo que se me vino a la cabeza y me he dado cuenta
de la tontería que estaba haciendo/diciendo.
:-)

Yo mismo digo que la tabla está normalizada porque no hay
dependencias y mas tarde me pongo a "normalizarla", confundiendolo
con el problema de los nulos.

Y es que soy un gran artista! El que no vea eso... está ciego. :-)

Saludos,
Carlos

Hola Carlos M. Calvelo,

"Carlos M. Calvelo" wrote:

Aquí con los nulos obviamente hay un problema (como siempre con
los nulos) y a mi se me presenta el siguiente dilema:

empleados(empleado_id,...,numero_celular_1, numero_celular_2,
numero_celular_3)

Normalizemos:

empleados(empleado_id, ...)
emp_no_cel1(empleado_id, numero_celular_1)
emp_no_cel2(empleado_id, numero_celular_2)
emp_no_cel3(empleado_id, numero_celular_3)

Acabo con cuatro tablas con las que por medio de joins podría
reconstruir la tabla original.
Obviamente este no es el resutado que queremos. El resultado que
queremos sabemos todos bien cual es. Pero ese no lo conseguimos
normalizando.

Eso de las cuatro tablas es un lindo disparate.

Podemos normalizar.

Primero renombro cosas para escribir menos y los atributos con puntos
suspensivos no se sabe qué son asi que no los voy a considerar:

e(eid, nc1, nc2, nc3)

Si asumimos que un empleado va a tener como máximo 3 celulares, podemos
decir que si tiene menos, alguno de los valores van a ser nulos. En esta
situación el esquema no cumple la 1NF según la definición tradicional de Mr.
Date. El esquema deberá descomponerse en:

e1 (eid)
e2 (eid, nc)

Esto cumple 1NF según Date y según Codd (que prefiere tener valores
atómicos, por lo que no aceptará jamás una solución artificial como es poner
los números de teléfonos en un string separado por comas).

Ahora voy a asumir que tenemos este conjunto de 3 dependencias funcionales
no triviales:

F = {
fd1: eid -> nc1,
fd2: eid -> nc2,
fd3: eid -> nc3
}

La clave es { eid } pues su clausura transitiva es: { eid }+ = { nc1, nc2,
nc3 }. Además { eid } es superclave por cumplir con la definición de
superclave. No hay otras claves candidatas pues ninguno de los atributos
no-primos del esquema determina a otros. Dejo como ejercicio validar eso.

Entonces el esquema cumple la 2NF.

Los atributos no-primos no dependen transitivamente de la clave. Entonces el
esquema cumple 3NF y también cumple BCNF (ver la definición).

Ahora voy a asumir que tenemos este conjunto de dependencias (3 dependencias
funcionales y 1 dependencia multivaluada que expresa que "cada empleado tiene
un conjunto de celulares". El conjunto de dependencias aumentado es:

M = {
fd1: eid -> nc1,
fd2: eid -> nc2,
fd3: eid -> nc3,
md1: eid ->-> nc1 nc2 nc3
}

Como { eid } es la superclave y md1 es la única dependencia multivaluada, se
cumple la 4NF.

Para ver si se cumple la 5NF necesitamos ahora saber las dependencias de
conjunto. No me son dadas, ni me imagino, dependencias de conjunto para este
ejemplo... por lo que se cumple 5NF.

Saludos
~gux

Hola Gux,

El Tue, 9 Dec 2008 05:42:13 -0800, Gustavo Larriera (MVP) escribió:

Podemos normalizar.

Primero renombro cosas para escribir menos y los atributos con puntos
suspensivos no se sabe qué son asi que no los voy a considerar:

e(eid, nc1, nc2, nc3)

Si asumimos que un empleado va a tener como máximo 3 celulares, podemos
decir que si tiene menos, alguno de los valores van a ser nulos.

No, no podemos. Podemos usar valores para representar la falta de
información, como por ejemplo la cadena de longitud 0.

En esta
situación el esquema no cumple la 1NF según la definición tradicional de Mr.
Date. El esquema deberá descomponerse en:

e1 (eid)
e2 (eid, nc)

Bueno, esto ya quedó claro que no es así.

Esto cumple 1NF según Date y según Codd (que prefiere tener valores
atómicos, por lo que no aceptará jamás una solución artificial como es poner
los números de teléfonos en un string separado por comas).

Una cadena con números de teléfonos separados por comas es tan atómica o
antiatómica como una cadena con un solo número de teléfono.

El término "atómico" no es un término preciso y fue un error el que Codd lo
utilizase por que solo sirvió para que la gente lo entendiese mal. En
realidad lo que quería decir Codd con atómico es que el valor no fuese de
tipo colección, y una cadena no es un valor de tipo colección a no ser que
la consideres como una colección de caracteres individuales.

Es mejor que utilicemos la interpretación de Date o la de Kent que están
escritas con un lenguaje más preciso.

Además eso anularía la regla de que el cumplir una forma normal asegura el
cumplimiento de todas las anteriores.

Normalmente se empieza por comprobar la 3NF o la BCNF por que son muy
fáciles de comprobar y ya te aseguran el cumplimiento de todas las
anteriores.



Saludos

Hola Gustavo,

On 9 dec, 14:42, Gustavo Larriera (MVP)
wrote:

Hola Carlos M. Calvelo,


"Carlos M. Calvelo" wrote:
> Aquí con los nulos obviamente hay un problema (como siempre con
> los nulos) y a mi se me presenta el siguiente dilema:

> empleados(empleado_id,...,numero_celular_1, numero_celular_2,
> numero_celular_3)

> Normalizemos:

> empleados(empleado_id, ...)
> emp_no_cel1(empleado_id, numero_celular_1)
> emp_no_cel2(empleado_id, numero_celular_2)
> emp_no_cel3(empleado_id, numero_celular_3)

> Acabo con cuatro tablas con las que por medio de joins podría
> reconstruir la tabla original.
> Obviamente este no es el resutado que queremos. El resultado que
> queremos sabemos todos bien cual es. Pero ese no lo conseguimos
> normalizando.

Eso de las cuatro tablas es un lindo disparate.

Si. Ya me había dado cuenta que no tiene nada que ver con
normalización.

Pero si es una partición vertical de la tabla que nos deja
sin nulos. Esa partición la puedo hacer sin saber que las
columnas celular_1 .. 3 tienen el mismo significado, o sea
asumiendo que son cosas distintas.
Fué por ahí por donde se me escapó el pensamiento al
hacerlo. Pero ya he dicho que no hace falta para nada y
no es normalización. Una tontería, vamos.

Podemos normalizar.

Primero renombro cosas para escribir menos y los atributos con puntos
suspensivos no se sabe qué son asi que no los voy a considerar:

e(eid, nc1, nc2, nc3)

Si asumimos que un empleado va a tener como máximo 3 celulares, podemos
decir que si tiene menos, alguno de los valores van a ser nulos. En esta
situación el esquema no cumple la 1NF según la definición tradicional de Mr.
Date. El esquema deberá descomponerse en:

e1 (eid)
e2 (eid, nc)

Este paso no lo puedes dar. Esto no es normalización.

Por lo demás... buen ejercicio. Gracias. :-)

Saludos,
Carlos