none
duda sobre fact table data warehouse RRS feed

  • Pregunta

  • Hola 

    Estoy iniciandome en el  diseño de data warehouse y quiero realizar alguno por mi cuenta, sin embargo estoy un poco confundido, quisiera usar como base lo siguiente:

    TablaEmpleado

    idTienda, iddepto, idpuesto

    TablaCursos

    IdCurso, Curso

    TablaCalificacion

    IdEmpleado,IdCurso, Calificacion

    TablaDetalleIncidencias

    IdEmpleado,IdCurso,Fecha,IdIncidencia

    TablaIncidencias

    IdIncidencia, CharIncidencia(F=falta por ejemplo=

    DimCurso

    idCurso, Descripción, FechaIni, Fechafin

    Sin embargo los ejemplos que he visto básicamente son para facts de ventas, mi idea es la siguiente:

    DimTiempo

    DateKey, demas campos básicos de esta dimensión.,

    DimEmpleado 

    DimKeyemp, idempleado,demás datos empleado

    Mi idea es tener una fact donde pueda consultar una "lista de asistencia" de los empleados, aquí es donde entran mis dudas,ya que necesito recuperar las incidencias por sesión (un curso podría tener 3 sesiones por ejemplo y alguien fue a 2 y falto a una), y también necesito su calificación final (almacenada en TablaCalificacion), mi fact debería redundar la calificación? por ejemplo

    FactAsistencia

    Key, DimKeyemp,idcurso, fecha(tomada de TablaDetalleIncidencias), charincidencia, calificacion

    lo que daría algo así: para el empleado 1521 que fue al curso 10 que consta de 2 sesiones

    1,1521,10,2015-10-10,"A",9.5

    1,1521,10,2015-10-11,"F",9.5

    Cual seria su consejo?



    Gracias



    Para que algo tenga sentido, no es necesario que tenga sentido

    jueves, 11 de mayo de 2017 3:57

Respuestas

  • Para empezar con el diseño te has ido a uno de los escenarios mas complejos, las relaciones muchos a muchos.

    Para iniciarte en la teoría de los DW yo empezaría leyendo el Datawarehouse Toolkit de Ralph kimball. En este caso concreto, como en todos, depende de que información quieras que te de  tu datawarehouse.

    Lo mejor en tu caso es crear dos tablas de hechos, porque las incidencias tienen un nivel de granularidad distinto (sesión) que las calificaciones (asignatura). 

    Para solventar el tema de las sesiones, crearía una dimensión sesiones (idasignatura,idcurso??) y simplemente cuentas asistencias. Si tienes en la tabla de calificaciones las sesiones totales , restando ambos valores tienes, sesiones, faltas y asistencias.

    Espero haberme explicado.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    • Propuesto como respuesta HunchbackMVP jueves, 11 de mayo de 2017 12:32
    • Marcado como respuesta Joyce_ACModerator jueves, 18 de mayo de 2017 13:52
    jueves, 11 de mayo de 2017 6:08
    Moderador

Todas las respuestas

  • Para empezar con el diseño te has ido a uno de los escenarios mas complejos, las relaciones muchos a muchos.

    Para iniciarte en la teoría de los DW yo empezaría leyendo el Datawarehouse Toolkit de Ralph kimball. En este caso concreto, como en todos, depende de que información quieras que te de  tu datawarehouse.

    Lo mejor en tu caso es crear dos tablas de hechos, porque las incidencias tienen un nivel de granularidad distinto (sesión) que las calificaciones (asignatura). 

    Para solventar el tema de las sesiones, crearía una dimensión sesiones (idasignatura,idcurso??) y simplemente cuentas asistencias. Si tienes en la tabla de calificaciones las sesiones totales , restando ambos valores tienes, sesiones, faltas y asistencias.

    Espero haberme explicado.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    • Propuesto como respuesta HunchbackMVP jueves, 11 de mayo de 2017 12:32
    • Marcado como respuesta Joyce_ACModerator jueves, 18 de mayo de 2017 13:52
    jueves, 11 de mayo de 2017 6:08
    Moderador
  • Agregando al comentario hecho por Miguel, enfocate en el proceso de negocio que deseas modelar y no en la aplicacion o herramienta que se use para manejar la parte transaccional que soporta ese proceso.

    Me explico, si deseas modelar asistencias entonces la tabla de hechos tratara sobre esto y como bien dice (tabla de hechos) pues esta no contemplara las ausencias que seria otra tabla de hechos y lo mismo a nivel de calificaciones.

    Te pongo otro ejemplo, pudieras modelar cada transaccion en las cajas de un supermercado pero en caso de devoluciones se deberia modelar otra tabla de hechos. Como vez dos procesos diferentes Ventas y Devoluciones. Lo mismo pasaria si tratas de reponder "Que productos no se vendieron en cierto periodo" pues como bien dice no hay hechos en la tabla sobre ventas asi que para responder sobre lo que no ocurrio tendriamos que hacer de eso un hecho.

    Cuando te enfocas en un proceso, tienes la oportunidad de trabajar sobre un dominio mas pequenio y te permitira avanzar mas rapido que si tratas de modelar todo de un golpe.

    Ademas del libro recomendado por Miguel (tercera edicion), tambien te recomiendo Star Schema The Complete Reference.


    AMB

    Some guidelines for posting questions...

    AYÚDANOS A AYUDARTE, guía básica de consejos para formular preguntas

    jueves, 11 de mayo de 2017 12:46