Problema con claves

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.

Alfredo Novoa,

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

Esto está en 5NF (si no hay cosas raras en los puntos suspensivos).

Estas seguro?

Para estar en 5NF, debe cumplir con las formas normales anteriores, y creo
que este modelo no cumple con la forma normal 1, 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.


AMB


"Alfredo Novoa" wrote:

Hola Alejandro,

El Sun, 7 Dec 2008 08:26:01 -0800, Alejandro Mesa escribió:

>> Espero que tú no le llames normalizar a esto :-)
>
> Entonces te pregunto como le debo llamar?

Pues cambiar el diseño o algo así.

Pero desde luego no normalizar. Normalizar no significa aumentar el
número
de tablas sin más, sino que significa modificar un diseño para hacer que
las "tablas" estén en formas normales superiores.

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

Esto está en 5NF (si no hay cosas raras en los puntos suspensivos).

Otra cosa es si este diseño es bueno o no, y no lo parece mucho.

> Cuando ??????, quedaria:
>
> empleados(empleado_id)
> empleado_telefonos(empleado_id, numero_telefono, tipo)

Y esto también está en 5NF. No has alcanzado una forma normal superior,
por
lo tanto no has normalizado nada.



Saludos
Alfredo

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

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 :-)

Saludos,
~gux

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