Para que normalizar???

[yaelkorin]

¿Para qué normalizar y relacionar las tablas, si al final se va a usar una consulta, con todos los campos tipo texto?
¿O no se debe usar la consulta, sino las mini tablas que componen cada campo? Estoy usando el D Ultradev, no entiendo demasiado de bases.

Muchas Gracias

[urjose]

Se normaliza para evitar redundancia, mantener la integridad de los datos y mejorar el rendimiendo del manejador.

Saludos

<center>
<p><a href=http://comunidadguru.com><img border=0 src=http://comunidadguru.com/urjose.gif></a></p>
</center>

[ceronne]

Se normaliza para evitar redundancia, mantener la integridad de los datos y mejorar el rendimiendo del manejador.

Mejor no lo pudiste haber contestado...... muy bien

[VAMP_01]

Exacto, y tambien cuando tu utilizas una consulta o cualquier tipo de pregunta a las tablas para extraer informacion (query o sql), la tablas relacionadas, obtienes mejores rendimientos, en cuanto a la rapides en ejecucion de los query......

[yaelkorin]

O sea que aunque la consulta tenga todos los datos repetidos, y la página ASP los extraiga de ahí, igualmente está mejorando el rendimiento?

¿Es entonces muy importante normalizar, en bases pequeñas (pocos miles de registros)?

[cubis]

Debes recordar el nivel de normalizacion para tu base de datos, un nivel muy alto para una BD pequeña, acabaria con tu maquina.

Salu2

PD: La normalizacion es importante siempre y cuando sepan usarla.

[urjose]

Ah caray.

Puedes explicarme esto:

Debes recordar el nivel de normalizacion para tu base de datos, un nivel muy alto para una BD pequeña, acabaria con tu maquina.

Saludos

<center>
<p><a href=http://comunidadguru.com><img border=0 src=http://comunidadguru.com/urjose.gif></a></p>
</center>

[piolin]

Normalizar:
Organizas la información de la base de datos de una manera coherente, de manera que evitas duplicidades o faltas de actualización de datos. En las bases de datos hay que tender a tener cada dato en un solo sitio y las reglas de normalización te ayudan a conseguir esto y más cosas.
Relacionar tablas (Integridad referencial):
Es la manera de asegurar la consitencia de los datos contenifdos en la base (P Ej no te permite borrar la cabecera de una factura dejando las líneas 'colgadas'). Esto te obliga a crear índices (Acceso rápido, como en los libros) en las tablas (Conjunto de datos identificadores de un registro), que es lo que te proporciona la velocidad.

[cubis]

Urjose:

La normalizacion tiene niveles, si pones un nivel de normalizacion muy alto tu maquina se pondria lenta

Eso es lo que trato de decir...

Entendiste??...

Salu2

[urjose]

Mmm no pos si así esta re claro we!
A mi me gusta ir mas a fondo de respuestas superficiales que no me convencen.

Saludos

<center>
<p><a href=http://comunidadguru.com><img border=0 src=http://comunidadguru.com/urjose.gif></a></p>
</center>

[drstock]

La Normalización solo tiene 4 niveles cada uno de ellos representa digamoslo así el &quot;performance&quot; que tendrán tus querys, el standart de las bases de datos son las bases de datos &quot;Relacionales&quot; y para cultura general el inventor de estas fué Oracle (de ahí que sea el rey) notese que digo &quot;Rey&quot; cuando hablo de bases de datos que son de gama alta, multiusuario, que pueda tener procedures y triggers, y herramientas de administración y monitorización.

Volviendo al tema y para que te quede claro un ejemplo:
Imagina que tienes 1000 clientes y cada cliente tiene unos fields definidos, nombre, direccion etc... ahora si tu tienes otros 1000 clientes que tienen esa misma descripción pero además otros flieds mas, sería correcto que hicieras una sola definición con TODOS los datos posibles??

De que se puede se puede pero imaginate la cantidad de definiciones inecesarias que crearías... mejor haces una tabla general otra que sea definicion1, definicion2 etc.. y la relacionas con el id del cliente y vualá!! ya te ahorraste tiempo dinero y memoria en hacer cada query, además que con unas cuantas lineas extiendes tus definiciones y cualquier cliente puede pasar de digamos: &quot;Cliente Normal&quot; a &quot;Cliente Gold&quot; cuando quieras y te evitas la rebusnancia ;) sorry que diga la redundancia.

La Normalización la vas a notar cuando tengas que expandir tu DB y dependiendo de los casos de uso que tengas verás la rapidez con que desarrollas y no modifiques tanto lo que ya está programado.

Por último alguíen conoce un buen sitio de bases de datos??? no que expliquen código si no todo este rollo de normalizar, definiciones, como sería bueno crear y relacionar, llaves, indices, catalogos etc etc...

Bytes...

[shahm]

Las ideas estan confusas...

Normaliar una bd no tiene nada que ver con el modelo relacional (que tiene mas de 30 años y por su puesto, no lo inventó oracle) pues se puede aplicar a cualquier modelo. La idea de normalizar responde simplemente a una mejora en el rendimiento de la bd. Me explico: Si tienes una tabla con los usuarios lo mas normal es que tenas un login un password y mas datos como el email, telefono, dirección, ... si el 90% de tus consultas solo acceden a esta tabla para validar a los usuarios, es decir, solo leen el login y el password, los accesos a esta tabla serán mas rápidos si solo contiene estos datos, entonces se normaliza: en una tabla estará el login y el password y en otra los demás datos.

Normalizar no reduce la redundancia de los datos sino que mas bien la hace augmentar. En el ejemplo anterior:

Tabla users:
login
password
email
telefono
...

Normalizando:
tabla users1:
login
password

tabla users2:
login
email
telefono
...

Puede verse que despues de normaliar el login aparece 2 veces mientras que antes solo aparece 1 vez --&gt; mas redundancia. Hay que llegar a un equilibrio entre la redundancia y el rendimiento.

La redundancia de los datos a un nivel lógico se ve claramete en tiempo de analisis en el diagráma entidad-relación. Cuanto mas se normalice en el diagráma entidad-relación aparecen mas relaciones lo que hace augmentar la redundancia.
En la literatura hay 4 niveles de normalización, pero en la práctica depende de cada problema en sí mismo para decidir que tablas normalizas y como lo haces. Al normalizar tb aparecen (en un modelo relacional) mas claves primarias mas claves foraneas y seguramente acabarán habiendo mas indices. Todo esto son ficheros que la bd tiene que mantener, por eso hay que normalizar con cuidado para que el rendimiento realmente augmente. De hecho a un nivel físico las bd's actuales normalizan las tablas en función de unas estadísticas de accesos de forma transparente.

[shahm]

Se me olvidaba una cosa, el ejemplo que pone drstock no me parece correcto como ejemplo de normaliación. La normalización solo afecta a la bd no hace cambiar los procesos que actuan sobre ella. Si hay que cambiar algún proceso implica que no se ha normalizado sino que hay un cambio en el diseño de la bd. Cuando se normaliza NO SE REDUCEN LOS REGISTROS solo se parten en mas tablas, pero el mismo número de registros. Es como segmentar una tabla en varias en función de algun critério. El hecho de que, por ejemplo, en una bd de música tenga una tabla que sea géneros musicales con todos las clasificaciones que se me ocurran (rock pop, clasica...) no es una normalización, esta tabla es una entidad nueva que tiene sentido por si misma no depende de las demás. Esto si reduce la redundancia, pero como ya he dicho es un tema de diseño no de normalización. las tablas se normalizan una vez ha acabado el diseño para hacer que los accesos sean mas rápidos. Cuanto mas pequeños sean los registros mas rápidos serán los accesos. Al menso así me lo enseñaron a mi y así lo he leido en multitud de libros.

[urjose]

Bueno creo que el concepto de redundancia que manejas en cuanto a que se incrementa ( por las llaves primarias) no es del todo correcto, creo que mas bien va encaminado a que por ejemplo:

Tabla1

|Usuario | Comentario | Firma | Direccion |

Tabla2

|Usuario | Password | Firma | Direccion|

Normalizada quedaría mas o menos así

Tabla1

| Usuario | Comentario

Tabla2

|Usuario | Password

Tabla3

|Usuario | Firma | Direccion|

Creo que el concepto de disminuir redundancia va mas encaminado al ejemplo que acabo de poner (Firma y Direccion), puesto que es lógico que las llaves primarias y foraneas van a crecer. El evitar redundancia como yo lo veo también es disminuir espacio

Saludos


<center>
<p><a href=http://comunidadguru.com><img border=0 src=http://comunidadguru.com/urjose.gif></a></p>
</center>

[Webstudio]

Bueno, me parece que hay un par de conceptos erróneos en este tema de la Normalización, espero no contribuir en el &quot;desconcierto&quot; general, sino todo lo contrario:

1) cubis : &quot;Debes recordar el nivel de normalizacion para tu base de datos, un nivel muy alto para una BD pequeña, acabaria con tu maquina.&quot;.

Esto es &quot;relativamente&quot; cierto para ciertas bases de datos. Algunas bases, como MySQL, en las que se extrañan ciertas caracteristicas, es posible que un nivel de normalizacion muy alto, provoque que se tengan que hacer más querys para obtener ciertos datos que (haciendo alguna trampita en la normalizacion), podrian obtenerse más sencillamente. No desesperen, esto se hace en muchas empresas.

2) drstock : &quot;La Normalización solo tiene 4 niveles ...&quot;

Hay un pequeño error alli. NO hay solo 4 niveles, de hecho hay algunos más, los mismos serian los siguientes:

1º paso, es quitar todos los campos que pueden ser calculados en base a otros. Si bien esto no determina una &quot;forma normal&quot;, si es necesario para una correcta normalización. Luego vienen la primera forma normal (1FN), 2FN, 3FN, BCNF, 4FN y 5FN.

3) drstock : &quot;el standart de las bases de datos son las bases de datos &quot;Relacionales&quot; y para cultura general el inventor de estas fué Oracle (de ahí que sea el rey)...&quot;

Error nuevamente. El Standar de las Bases de Datos ( en este caso relacionales, aunque hay otros ) no lo definió Oracle, sino que está determinado en el ANSI SQL, definido por el American National Standards Institute, de los cuales el más aceptado es el 92, pero el último es el 99 (también conocido como SQL3). En base a esto, la empresa ORACLE ( que en principio fue un proyecto de la milicia norteamericana ), creó una de las primeras Bases de datos relacionales.

[Webstudio]

4) sham : &quot;La idea de normalizar responde simplemente a una mejora en el rendimiento de la bd...Normalizar no reduce la redundancia de los datos sino que mas bien la hace augmentar.&quot;

No solo a eso. No importa si vas a utilizar una base de datos o no, la idea detrás de normalizar, es la de evitar la redundancia de datos y la menor utilización de claves necesarias para acceder a una fila de información.

El ejemplo que das no solo no es necesario separarlo en dos tablas, sino que no implica una redundancia, ya que las claves foráneas no se ven como redundantes. En tu ejemplo, si querías obtener una mejora de performance, con solo haber creado indices en base a esos dos campos, ya era suficiente.

5) shahm = &quot;El hecho de que, por ejemplo, en una bd de música tenga una tabla que sea géneros musicales con todos las clasificaciones que se me ocurran (rock pop, clasica...) no es una normalización, esta tabla es una entidad nueva que tiene sentido por si misma no depende de las demás&quot;

Error nuevamente, eso es PARTE de la normalización, el partir elementos repetitivos dentro de un registro, en una nueva tabla ( o entidad, como bien haces en llamarla ). Otro tema, una entidad de por si sola, casi no es útil, sin que exista una o más relaciones con otras entidades.

6) shahm : &quot;las tablas se normalizan una vez ha acabado el diseño para hacer que los accesos sean mas rápidos&quot;.

Vaya que hay problemas con los conceptos. Sucede que la normalización de una base de datos, es parte integral del Diseño de la misma y no un proceso aparte. Si resulta que YA tienes una base de datos, no creada por ti, sino anterior, y tienes que &quot;normalizarla&quot;, bueno, lamento informarte que la nueva base de datos normalizada ha pasado por una etapa de diseño previo ( sin que te hayas dado cuenta, has estado Diseñando, al menos mentalmente ) y la normalizacion a sido parte de ese rediseño.

Bueno, espero haber contribuido a aclarar un poco estos temas.

Saludos.

<hr><font size=2 face="verdana">- Pablo Daniel Rigazzi (Webstudio)
<font size=1 color="#333333">COORDINADOR PROYECTO REGIONALIZACION ARGENTINA
Visita <a href="http://www.web-studio.com.ar" target="_blank">Web Studio</a> - Tutoriales Photoshop</fo

[shahm]

Como yo lo veo (aunque es una cuestión mas filosófica que otra cosa) en una bd puede haber redundancia en cuanto a tuplas y en cuanto a propiedades. No es lo mismo tener una clave 1 vez que 10 veces, cada clave, sea primaria o foranea, tiene un fichero asociado que se tiene que mantener penalizando el rendimiento mas que el hecho de tener mas o menos registros en una tabla, dentro de unos margenes.
Los indices tb pueden penalizar el rendimiento en algunas circunstancias, no combiene abusar si no esta clara su necesidad.

Lo que dices de que la normalización es parte del diseño es cierto, no me he expresado bien. En el ejemplo de la bd musical, la existencia de una entidad &quot;generos&quot; perteneceria al análisi, y la normalización al diseño. Yo no creo que una tabla de este tipo sea un proceso de normalización pues tiene un sentido distinto al resto, es una tabla &quot;maestra&quot; que contiene ocurrencias que requieren de un proceso de mantenimiento, de administración ,... distintos que el resto de tablas, procesos que deben definirse claramente en el análisi. No se si me explico con claridad.

[cubis]

Pienso que Webestudio tiene toda la razon.

Salu2

[drstock]

Solo para aclarar cuando dije que el rey era el inventor de las bases de datos relacionales era por que precisamente Oracle fué el que la desarrollo primero, ejemplo te puedes imaginar un auto volador pero no por eso quiere decir que tu seas el inventor, el creador o inventor es el que lo desarrolla primero.

Y más que nada para no confundir terminos se le llama a las bases de datos relacionales también como &quot;Base de datos basada en el modelo Entidad - Relacion ó Entidad - Asociación&quot;... ahora antes de que la ANSI la aceptara como ESTANDART fué propuesto por Peter Chen en 1976 y hasta 1988 ANSI la adopto como estandart para desarrollar diccionarios de información que no es otra cosa que las bases de datos relacionales.

[DeadTonyLord]

Yo nunca esuche en la escuela nada parecido a esto, solo nos daban la burda explicacion de normalizar "porque si" pero aqui he aprendido el porque, las razones y las justificaciones, son exactamente las adecuadas, ni hablar, mis alabos para ustedes, hoy he aprendido algo más

[MACGREGOR]

Hola, he leido este post y creo que cualquiera que esté empezando o lleve poco tiempo "jugando" con Bases de Datos Relacionales acabará confundido.

De manera que espero aclarar algun concepto, y si estoy equivocado en algún punto no duden en hacermelo saber

Lo primero que quería aclarar es el motivo que OBLIGA a Normalizar una Base de Datos.

Principalmente son tres, la mejora del rendimiento, asegurar la consitencia de los datos guardados y la mantenibilidad de la DB.

Respecto a la consitencia e integridad de los datos (que son 2 cosas muy diferentes) no hablaré, pueden buscar información en San Google que seguro lo explicarán mejor que yo.

En cuanto a la mantenibilidad, si alguien crea una aplicación basada en una DB normalizada cuando otra persona (o la misma al cabo de un tiempo) deber retomar dicha aplicación para añadir funcionalidades ahorrará MUCHO tiempo a la hora de comprender qué significado tiene cada tabla y sus relaciones con otras tablas, ya que las reglas para crear la estructura de la DB son conocidas e iguales para todo el mundo.

Respecto al rendimiento, la normalización siempre lo aumentará. Se ahorrará espacio en disco, memoria y tiempo de CPU ya que se optimizará la cantidad de información a guardar en las tablas y el tiempo de acceso a los datos.

Vuelvo a decirles que le pregunten a Google si quieren más detalles que justifiquen el porqué.

Algunos de los mensajes que he leido hablan de niveles de normalización y que una normalización excesiva puede "tumbar" o acabar con tu máquina...

Esta frase es un grave error que mezcla conceptos que nada tienen que ver.

Intentaré explicarme con claridad.

La Normalización consiste en aplicar una serie de reglas.
Es cierto que existen varios niveles de normalización, en función de si aplicas más reglas o menos.
Estas reglas que originalmente eran 12 acabaron simplificandose en lo que se conoce como FORMAS NORMALES (no recuerdo si eran 5 o 6).

Lo más habitual es que una DB normalizada aplique como mínimo las 3 primeras Formas Normales. Nivel mínimo para una Normalización correcta.

Personalmente recomiendo que se aplique hasta la BCNF (Boyce-Codd Normal Form) o 4ª Forma Normal que lleva el nombre del AUTOR de las reglas de Normalización.

Se pueden aplicar todas Formas Normales de forma que conseguirás un Diseño "purista" de tu DB. No es lo habitual, ya que tu diseño será más estricto y menos flexible a futuras modificaciones.

De modo que es cierto que existen diferentes "NIVELES" de Normalización, de hecho Oracle en su versión 8 solo implementaba estas 3 primeras Formas Normales y no incluyó el resto hasta la versión "9i" de su SGBD (Sistema Gestor de Base de Datos).

La normalización excesiva "tumbará" tu máquina...

No existe una normalización excesiva, o se normaliza o no se hace. O se hace bién, o se hace mal.

Esto se verá más claramente con el siguiente ejemplo.
Supongamos que tenemos una tabla con datos de empresas en la que aprecen unos campos reservados para la dirección,(calle, número, código postal, ...). Si vemos que varias de estas empresas tienen el mismo valor en el campo "calle" o "código_postal" podríamos pensar que sería útil tener una tabla para las direcciones y crear una clave foranea que relacione la tabla empresas con esta nueva tabla.
A continuación vemos que sucede lo mismo para las direcciones de los clientes...
Vuelve a suceder con las direcciones de los proveedores...
Nos damos cuenta de que los empleados de nuestra empresa también tienen dirección!!
Cuantas tablas para direcciones tendriamos que crear?
Puedo hacer una para todos y dejar en blanco los campos que no necesite para un empleado y sí necesite para una empresa cliente....

Eso sería aplicar FATAL las reglas de la Normalización.
Si se hace una aplicación sistemática e INCORRECTA de las Formas Normales entonces el rendimiento de tu DB empeorará pero no es culpa de la normalización, es culpa tuya!

La normalización en realidad se considera una herramienta imprescindible en proceso de creación de una DB, ese proceso se compone por un análisis de las necesidades de lo que se desea crear y un diseño.
Cuando se tienen estas dos cosas es cuando se implementa, no se puede empezar la casa por el tejado creando tablas y luego "moviendo" campos a otras tablas de nueva creación.
Se debe estudiar previamente que "entidades" y relaciones entre ellas se necesitarán y la normalización nos dirá que tablas se deben crear.
(la 3FN y la BCNF nos dicen que las relaciones n-m se deben romper creando 2 relaciones 1-n y m-1 y una tabla intermedia, incluso nos dice qué campos debe tener esa tabla intemedia!!!).

Lamento haberme extendido tanto, pero espero que aclare algunos conceptos a quien no lo tenía del todo claro.

Para terminar quería hacer un pequeño comentario respecto a la historia de la informática y a quien creó la primera DB relacional...

Las primeras DB estaban basadas en ficheros, y todo el mundo vió que se hacian lentas y problematicas en cuanto crecian en número de datos.

De forma que los señores de IBM empezaron un proyecto para definir como deberían ser las Bases de Datos Relacionales.
En ese proyecto trabajaba el señor Boyce Codd que les comenté antes. En IBM estaban tan contentos con su trabajo que en su honor la 4FN lleva su nombre...
Cual fué su sorpresa cuando al cabo de muy poco tiempo de que IBM publicara su trabajo (Definición, Análisis y Diseño de como deberían ser las DB-Relacionales) apareció una IMPLEMENTACIÓN de la ESPECIFICACIÓN que ellos habían realizado.

Esa Implementación de la primera DB Relacional la puso en el mercado una empresa que si no recuerdo mal se llamaba "RELATIONAL SOFTWARE".

No se extrañen si no la conocen, ya que, su existencia fue breve. Le cambiaron el nombre a esta compañía y la llamaron ORACLE.

Espero que les haya interesado este post.

MAC.