Problema con claves

On 9 dec, 00:18, "Jose TH" <>>> wrote:

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

Pues hay que comenzar conociendo la PRIMERA normal.

http://es.wikipedia.org/wiki/1NF#cite_note-Kent-1

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.

Que quede claro, que he normalizado con el fin de deshacerme de
los nulos. Digo esto para contrastar con el problema de que no
se pueden tener mas de tres teléfomos. Eso sería rediseño que
no tiene nada que ver con normalización.

Ahora, que alguien me corrija, pero mi conclusión es que, aparte de
toda la controversia que pueda existir sobre la definición de 1NF,
el problema no es de normalización, sino de rediseño con sentido
común (si... de ese que no está formalizado)

Opiniones son bienvenidas.

On 9 dic, 01:45, "Carlos M. Calvelo" wrote:

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

> Pues hay que comenzar conociendo la PRIMERA normal.

>http://es.wikipedia.org/wiki/1NF#cite_note-Kent-1

A ver que dice aquí Kent:

<Cita>

First normal form [1] deals with the "shape" of a record type.

Under first normal form, all occurrences of a record type must contain
the same number of fields.

First normal form excludes variable repeating fields and groups. This
is not so much a design guideline as a matter of definition.
Relational database theory doesn't deal with records having a variable
number of fields.

</Cita>

Pues bien aquí dice que para que una tabla esté en 1NF todas las filas
tienen que tener el mismo número de campos (tablas rectangulares), y
que no es una guía de diseño por que con las bases de datos
relacionales no hay forma de hacer que una tabla no esté en 1NF.

Es lo mismo que le comentaba a Alejandro, que eso que él decía no eran
realmente campos repetidos. Por esta vez Jose TH nos ha proporcionado
un enlace a buena informacion :-)

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)

No hace falta complicarse tanto la vida. Creas un tipo de datos para
numeros de celular que permita dejar el numero en blanco y listo.

O simplemente usas un varchar y utilizas la cadena de longitud 0 para
indicar que esa información falta.


Saludos

Hola Alfredo,

On 9 dec, 02:32, Alfredo Novoa wrote:

On 9 dic, 01:45, "Carlos M. Calvelo" wrote:

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

> > Pues hay que comenzar conociendo la PRIMERA normal.

> >http://es.wikipedia.org/wiki/1NF#cite_note-Kent-1

A ver que dice aquí Kent:

<Cita>

First normal form [1] deals with the "shape" of a record type.

Under first normal form, all occurrences of a record type must contain
the same number of fields.

First normal form excludes variable repeating fields and groups. This
is not so much a design guideline as a matter of definition.
Relational database theory doesn't deal with records having a variable
number of fields.

</Cita>

Pues bien aquí dice que para que una tabla esté en 1NF todas las filas
tienen que tener el mismo número de campos (tablas rectangulares), y
que no es una guía de diseño por que con las bases de datos
relacionales no hay forma de hacer que una tabla no esté en 1NF.

Es lo mismo que le comentaba a Alejandro, que eso que él decía no eran
realmente campos repetidos. Por esta vez Jose TH nos ha proporcionado
un enlace a buena informacion :-)

Pues no creo que haya sido su intención que tu fueras
a seguir los enlaces abajo. :-)

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

No hace falta complicarse tanto la vida. Creas un tipo de datos para
numeros de celular que permita dejar el numero en blanco y listo.

O simplemente usas un varchar y utilizas la cadena de longitud 0 para
indicar que esa información falta.

Pues sí! Claro que no hace falta complicarse la vida.
Como tampoco hace falta hacer eso que haces tu. Se monta el diseño
que todos sabemos que es mejor (con una tabla para los teléfonos)
y ya está :-)

Pero que no se diga que ese nuevo diseño es resultado de
normalización. Que a su vez es lo que nos llevo a lo de la
primera forma normal.

Saludos,
Carlos

Hola Alfredo,

On 9 dec, 03:10, "Carlos M. Calvelo" wrote:

Pero que no se diga que ese nuevo diseño es resultado de
normalización. Que a su vez es lo que nos llevo a lo de la
primera forma normal.

Que por cierto, ahora que lo pienso, creo que lo que he hecho
yo ni normalización es. Simplemente he partido la tabla por lo
de los nulos.

Saludos,
Carlos

Hola Carlos,

El Mon, 8 Dec 2008 18:32:46 -0800 (PST), Carlos M. Calvelo escribió:

Que por cierto, ahora que lo pienso, creo que lo que he hecho
yo ni normalización es. Simplemente he partido la tabla por lo
de los nulos.

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.


Saludos