Diseño de Base "Compleja"

[NA1TM3R]

Saludos Expertos!

Hasta ahora había estado manejando diseños de bases con tablas relacionales sin problemas . . .

Con datos que rara vez eran modificados, y de los cuales podíamos ver un historial íntegro . . .

Pero ésta vez estoy a punto de hacer algo no hecho antes . . . por lo cual busco la mejor de las recomendaciones. . .

Una base . . . la cual sufrirá modificaciones diarias en la tabla de usuarios . . . afectando otras tablas claro está . . .

Ésto no es problema alguno . . . hasta el punto en que quieren consultar por fecha . . .

En x fecha, éste usuario tenía tales características, generando x reportes.
En y fecha, el mismo usuario tenía otras características, generando y reportes.

Que recomiendan para que ésto sea posible ? ? ?

Porque había pensado que los datos que sifrirán mas modificaciones puedo mandarlos a otra tabla "MovimientosDeUsuarios" de donde sólamente utilizaría los datos con la fecha mas reciente para reportes actuales, y en caso de consultar por mes . . . buscar en ésta tabla, el IDUsuario con . . . que fecha . . . tal vez limitar a la última fecha encontrada que sea menor a la que estoy consultando . . .

Será ésta la solución ó alguien ya ha pasado por algo así ? ? ?

Muchas Gracias por las respuestas . . .

Nos estamos leyendo . . .

PD. Si no me explico bien . . . háganmelo saber . . . aún no armo las tablas . . . mucho menos Queries de ejemplo :( . . .

[oscarbt]

primero dime, a que te refieres con eso de las tales caracteristicas??.....para ver los movimientos de un usuario lo ideal no es modificar la tabla, simplemente hacer INSERT en una tabla, solo con el codigo de ese usuario, las caracteristicas nuevas que tenga, y el reporte de movimiento nuevo, de esa forma no vas a tener que ni eliminar ningun movimiento del usuario y por tanto podrias hacer una consulta segun las fechas, de todos sus movimientos

[gnzsoloyo]

Hasta ahora había estado manejando diseños de bases con tablas relacionales sin problemas . . .
Con datos que rara vez eran modificados, y de los cuales podíamos ver un historial íntegro . . .

En otras palabras, tenías un esquema de base de datos sin demasiadas incidencias, que solamente tendría alguna que otra tabla de actualización constante (sesiones, por ejemplo).

Una base . . . la cual sufrirá modificaciones diarias en la tabla de usuarios . . . afectando otras tablas claro está . . .
Ésto no es problema alguno . . . hasta el punto en que quieren consultar por fecha . . .
En x fecha, éste usuario tenía tales características, generando x reportes.
En y fecha, el mismo usuario tenía otras características, generando y reportes.

Eso no representa ningún problema. Lo único que hace es requerir una normalización de la tabla. Nada más.
Sin un usuario tiene atributos que pueden variar en el tiempo, eso implica que hay un conjunto de atributos hoy asignados a USUARIO y que en realidad pertenecen a otra tabla. Esa tabla, a su vez debe contar con otros atributos que le den entidad a la existencia de la misma, y por lo que describes esos atributos tiene que ver con el período de vigencia de la información.
Así, si la dirección del usuario fuese importante y modificable, hay que establecer una tabla DIRECCION_USUARIO que contenga los atributos de la dirección del usuario durante un período de tiempo determinado (userid, fecha_inicio y fecha_fin como determinantes).
¿Se comprende la idea?
Lo que deberías hacer es describirnos más en detalle la estructura de las tablas a modificar y cuáles son las modificaciones que se producirían por el nuevo INPUT del sistema.
Pero la cosa no parece ser demasiado complicada, por lo que describes. Como dije, parecen problemas de normalización...

Porque había pensado que los datos que sifrirán mas modificaciones puedo mandarlos a otra tabla "MovimientosDeUsuarios"

Mala idea. Estarías probablemente poniendo redundancia de datos. Lo que tienes que establecer es cuáles atributos serían constantes, cuales opcionales y cuáles variantes.
Así, un dato constante es el userid o username, otros el nombre y apellido del usuario, su sexo, nacionalidad, estudios, profesión, etc. En ciertos contextos la dirección es opcional, como el teléfono o el e-Mail. En otros casos no, y según establezcas cuáles son los campos variantes y cuáles de ellos opcionales, sabrás qué datos son los que realmente deberás derivar a otra tabla.
Supongamos el caso de la dirección. Si consideras variante la dirección, eso puede que implique considerar variante un teléfono fijo (según el país), pero no un celular. ASí en ese caso puede que el fijo se deba derivar a otra tabla, mientras que el celular puede dejarse en la tala primaria y la dirección a una tercera tabla.

Resumiendo:
1) Postea las estructuras de las tablas.
2) Describe qué tipo de influencia tiene el nuevo input del sistema.
3) Repasa normalización y vuelve a analizar el sistema. Propone los cambios y vemos.

[NA1TM3R]

Saludos y Muchas gracias por las respuestas ! ! ! !

. . . al parecer veo con mas claridad el como estructurarlas . . .
(claro . . . espero eliminar éste "al parecer") . . .

Como comentaba . . . aún no existen dichas tablas . . . apenas comenzaba con mis bocetos . . .

Ésto de la normalización era a lo que deseaba llegar con lo de la tabla "MovimientoDeUsuarios"(claro que es un mal nombre, pero fué para generalizar un poco), . . .

Imaginando un poco en la tabla de constantes y la de variables:

Usuarios
IdUsuario
Nombre
FechaNacimiento
Telefono
Status

Usuarios_Var
FechaIngreso
Sector
Cargo
FechaInicia
FechaTermina
Saldo

Las otras tablas si son independientes de los datos principales del usuario . . . por ejemplo una de Ingresos, Egresos . . . etc . . .

Como influye(n) la(s) tabla(s) de Usuarios en los reportes . . .
Sectores activos en el mes x . . .
Consultas mensuales a cualquier usuario.
Así como sumas de Saldos por mes, Ingresos,Egresos . . . etc . . .

Así que. . . ahora la tabla clave es la de Usuarios con datos variables, ya que lo demás si está en sus respectivas tablas . . .

Con sus respectivos JOINS en base a las fechas de ésa tabla se generará el historial . . .

Si se me ha pasado algún detalle . . . pueden recordarmelo





Una vez mas . . . gracias a los 2 por las respuestas . . .

Nos seguimos leyendo . . .

[NA1TM3R]

Oops!

No me gusta tener 2 posts seguidos . . . pero lo que pasa es que acabo de leer unos tips sobre los 5 Niveles de normalización . . . y creo que sigo en el nivel 1 de normalización . . . y se tendrán que duplicar algunos datos . . .
( . . . volviendo a nuestro ejemplo anterior . . . )


Usuarios
IdUsuario
Nombre
FechaNacimiento
Telefono
Status



Usuarios_Var
FechaIngreso
Sector
Cargo
FechaInicia
FechaTermina
Saldo


En caso que sólo se modificara el Sector, los otros 5 campos duplicarían la información . . . además de que me faltó el campo escencial para un historial "FechaModificado"(por llamarle de alguna manera) . . .

Pero tambien sería una exageración irnos al nivel 5 y descomponer cada campo en tablas . . . (Bueno que Para Sector y Cargo si las hay . . .)y generar la tabla "RelacionModificaciones", donde viniera la relación de IDs + la FechaModificado . . .


Usuarios
IDUsuario
Nombre
FechaNacimiento
Telefono



Inicios
IDInicio
FechaInicio



Terminos
IDTermino
FechaTermino



Sectores
IDSector
DescripcionSector



Cargos
IDCargo
DescripcionCargo



Saldos
IDSaldo
MontoSaldo



RelacionModificaciones
IDRelacionModificaciones
IDUsuario
IDIngreso
IDTermino
IDSector
IDCargo
IDSaldo
FechaModificado
Status


Algo así me imagino . . . aún no llego a la creación . . . para comenzar a generar mis SELECTs para los reportes . . . pero creo que por ahí iba la cosa . . . aunque aún tengo duda con las Fechas . . . si la fecha que se ingresará ya existe, entonces solamente habría que relacionar el IDInicio (que contiene x fecha), con el IDRelacionModificaciones.


Lo divertido serán los INSERT, ya que tendría que consultarse los últimos ID de cada inserción para agregarlos a RelacionModificaciones...


Nos seguimos leyendo ! ! !