Cita: y siguiendo con el ejemplo que mencione en el primer post, que pasa cuando te piden al menos 5 teléfonos de espacio para cada tipo de persona y toma en cuanta que obviamente no siempre se llenan todos los teléfonos en el formulario y para cada teléfono tipos de teléfono que van desde móvil, fijo, nextel, etc etc etc. Por lo que dejar esos campos en la tabla de empleados o de clientes, se traduciría en muchos espacios vacíos y de igual manera espacio reservado que no se utiliza. Esto, desde mi punto de vista, me obliga a separar la tabla de teléfonos,
Es un poquitín difícil sintetizar cuatro materias de la facultad en un post, pero voy a intentar describirlo de una forma simplificada:
Cuando analizas un sistema y defines las entidades que lo componen (ver
entidad en el
modelo entidad-relación), lo haces en base a atributos (datos o valores) que definen su existencia y que le
pertenecen. Es el caso de Nombre, Direccion, Documento, etc.; en ocasiones te encuentras con un atributo que es iterativo, es decir, que puede contener más de un valor asignable o incluso ninguno.
Esto, a nivel de
sistema, es aceptable, pero
el modelo relacional de bases de datos no admite iteraciones de valores en una tabla, es decir, no puede haber valores múltiples en un mismo campo. Por eso existen las
formas normales, que te permiten resolver eso.
En las Formas Normales se determina que
todo atributo iterativo debe forzosamente se extraído de la tabla y separado en una tabla propia. Pero eso
no implica necesariamente que ese atributo pueda ser derivado a una
tabla general, porque ese mismo atributo
le sigue perteneciendo a esa única entidad. En otras palabras, si esa tabla existe es porque ese atributo existe en ella, entonces depende de ella para existir.
En el contexto de Usuarios -> Telefonos, los teléfonos son de los usuarios, y nada más que de los usuarios. Lo mismo pasa con otro tipo de cosas, como estudios cursados, domicilios, etc.
En el caso de los teléfonos, el que sea fijo, celular, Nextel o lo que sea, es un
atributo del teléfono, lo que normalmente se implementa en la tabla de teléfonos sea como un campo ENUM, o una FK a otra tabla que contenga los tipos de teléfonos aceptados (es una decisión del diseñador del sistema). Por ello no es necesario hacer diferentes tipos de campo para diferentes tipos de teléfono. Además ten en cuenta que sea de donde sea, el sistema telefónico mundial sólo acepta una cantidad determinada de dígitos (creo que el máximo son 14) para marcado. O sea que no necesitas nunca mas de eso.
Este modelo de relación permite que haya cero o más teléfonos, por ejemplo. Eso surge de analizar si ese atributo es obligatorio u opcional.
Este tipo de esquema de razonamiento se repite siempre que haya un
conjunto de atributos que sea iterativo en el mismo contexto. Con esto me refiero que si hay un domicilio con varios numeros, pero el resto de los datos de la dirección no se repite, eso no es iteratividad. Uno sólo de los valores es lícito y el resto son optativos.
Cita: por otra parte en mas de una ocasión he escuchado y leído ( no encontré esos artículos para referenciarlo ) que una base de datos es mas funcional si se va clasificando la información en tablas, es decir personas con personas, direcciones con direcciones o teléfonos con teléfonos y las relaciones hacen el trabajo.
Hay que tener mucho cuidado con la atomización innecesaria de las entidades. La normalización de las tablas tiene un límite práctico (demasiadas tablas innecesariamente complican la base), y un límite analítico.
El límite práctico está dado por la normalización. Si no es estrictamente necesario, no se debe hacer. El analítico está dado por los requerimientos del cliente, ya que ciertas separaciones de datos pueden surgir de lo que el cliente pide, y porque el sistema toma los datos de una determinada forma (Caso: ventas telefónicas. Los datos del cliente pueden llegar a separarse en tablas, dependiendo de los formularios de entrada que el sistema considere).
Lo que no hay es una regla o ley general, pero si te remarco algo que ya dije: Si, por ejemplo, un usuario sólo puede tener una dirección (reglas de negocio), no tiene ningún sentido separar la dirección en otra tabla. Si tiene más de una tarjeta de crédito, sí, las tarjetas van en otra tabla.
¿Se va entendiendo un poco?