• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
607
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
39
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Hemos visto entonces 2 alternativas de diseño para representar una relación 1-N entre 2 actores de la realidad. ¿Cómo elegimos cuál diseñar?¡Eso dependerá de la realidad a modelar!Por ejemplo, como sabemos y hemos mencionado, entre los actores de la realidad: clientes y facturas la relación es 1-N puesto que 1 cliente tiene N facturas y 1 factura es de 1 cliente…… y para diseñar esa realidad jamás se nos ocurriría hacer un diseño 1-N del 2do estilo que vimos… es decir: en el 1er nivel Customers y en el 2do nivel Invoices….porque una factura debe poder identificarse y poder ubicarse con tan solo su nro de factura.Las facturas tienen existencia propia por si mismas, sus nros son irrepetibles, y con solo tener el nro de una factura, ya debo poder ubicarla. Entonces para la relación 1-N que hay entre los actores de la realidad: clientes y facturas, no hay duda alguna de que elegiríamos la 1er alternativa de diseño propuesta. Es decir, la que establece la relación entre Customer e Invoice mediante la clave foránea CustomerId en Invoice.

Transcript

  • 1. Consejos para futuros instructores
    A/S Maia Shuster
    mshuster@artech.com.uy
  • 2. Veremos…
    Aportes útiles
    para la hora de dictarsuscursos GeneXus
    Sugerencias
    Tips para enseñar fácil
    Errores más comunes que cometen los alumnos… y recomendaciones!
  • 3. Diseño de transacciones
  • 4. Diseño de transacciones
    Errores comunes:
    • Alumnos que creen que con solo definir esta trn, están modelando una relación M-N:
    (A1*
    A2
    (B1*
    B2)
  • 5. Diseño de transacciones
    Errores comunes:
    • Alumnos que no terminan de entender diferencia:
    (A1*
    A2
    (B1*
    B2)
    (A1*
    A2
    (B1*
    B2)
    B1*
    B2
    +
  • 6. Diseño de transacciones
    Errores comunes:
    • Alumnos que definen transacciones de más:
    • 7. Se creantablasfísicas de más
    • 8. Se almacenandatosredundantes
    • 9. Quedandefinidascomplejidadesinnecesarias
  • Diseño de transacciones
    Errores comunes:
    • Alumnos que definen componentes de más en las claves
    • 10. Alumnos que no tienen fijados ciertos conocimientos puntuales, que les serían de gran ayuda
  • Diseño de transacciones
    Propuesta para enseñar fácil este tema:
    ENTERPRISE #1
    ENTERPRISE #2
    PROVIDER
    PRODUCT
    PROVIDER
    PRODUCT
  • 11. Diseño de transacciones
    PROVIDER
    PRODUCT
    ENTERPRISE #1
    ProductId*ProductName
    ProviderId*ProviderName
    (ProductId*
    ProductName)
    ProductId*ProductName
    (ProviderId*
    ProviderName)
    ProviderId*ProviderName
    ProductId*ProductName
    (ProviderId*
    ProviderName)
    ProviderId*ProviderName
    (ProductId*
    ProductName)
    ProductId*ProductName
    ProviderId*ProviderName
    ProviderId*ProductId*
  • 12. Diseño de transacciones
    PROVIDER
    PRODUCT
    ENTERPRISE #1
    Tablas fisicasresultantes:
  • 13. Diseño de transacciones
    Volviendo a esta duda de los alumnos…
    ¿ Con solo definir esta trn, están modelando una relación M-N ?
    (A1*
    A2
    (B1*
    B2)
  • 14. Diseño de transacciones
    ENTERPRISE #2
    2 ALTERNATIVAS DE DISEÑO DIFERENTES
    GENERAN TABLAS FÍSICAS DIFERENTES
    PROVIDER
    PRODUCT
  • 15. Diseño de transacciones
    ENTERPRISE #2
    ALTERNATIVA #1:
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    CustomerId*
    CustomerName
    InvoiceId*
    InvoiceDate
    ….
    CustomerId
    CustomerName
    PROVIDER
    PRODUCT
  • 16. Diseño de transacciones
    ENTERPRISE #2
    ALTERNATIVA #1:
    ProviderId*
    ProviderName
    ProductId
    ProductName
    ProductId*
    ProductName
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    PROVIDER
    PRODUCT
    PROVIDER
    PRODUCT
  • 17. Diseño de transacciones
    ENTERPRISE #2
    Nulls=Yes
    ALTERNATIVA #1:
    ALTERNATIVA #2:
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    ProviderId*
    ProviderName
    (ProductId*
    ProductName)
    PROVIDER
    PRODUCT
  • 18. Diseño de transacciones
    ENTERPRISE #2
    ALTERNATIVA #2:
    ProviderId*
    ProviderName
    (ProductId*
    ProductName)
    PROVIDER
    PRODUCT
  • 19. Diseño de transacciones
    PROVIDER
    PRODUCT
    ENTERPRISE #2
    CUSTOMER
    INVOICE
    ¿ ALTERNATIVA #1 ?
    ¿ ALTERNATIVA #2 ?
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    ProviderId*
    ProviderName
    (ProductId*
    ProductName)
    CustomerId*
    CustomerName
    (InvoiceId*
    InvoiceDate
    ….)
    CustomerId*
    CustomerName
    InvoiceId*
    InvoiceDate
    ….
    CustomerId
    CustomerName
    ¿Cómo elegimos cuál?

    Dependerá de la realidad a modelar…
  • 20. Diseño de transacciones
    ENTERPRISE #2
    CUSTOMER
    PHONE
    ¿ ALTERNATIVA #1 ?
    ¿ ALTERNATIVA #2 ?
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    ProviderId*
    ProviderName
    (ProductId*
    ProductName)
    CustomerId*
    CustomerName
    (CustomerPhoneId*
    CustomerPhoneNumber)
    CustomerId*
    CustomerName
    PhoneId*
    PhoneNumber
    ….
    CustomerId
    CustomerName

    PROVIDER
    PRODUCT
  • 21. Diseño de transacciones
    ENTERPRISE #2
    ¿ ALTERNATIVA #2 ?
    ¿ ALTERNATIVA #1 ?
    ProviderId*
    ProviderName
    (ProductId*
    ProductName)
    ProviderId*
    ProviderName
    ProductId*
    ProductName
    ProviderId
    ProviderName
    RELACIÓN 1-N “FUERTE”
    o
    “RELACIONADO CON”
    RELACIÓN 1-N “DÉBIL”
    O
    “PARTE DE”
    PROVIDER
    PRODUCT
  • 22. Diseño de transacciones
    Volviendo a esta duda de los alumnos…
    ¿ Cuál es la diferencia .. ?
    (A1*
    A2
    (B1*
    B2)
    (A1*
    A2
    (B1*
    B2)
    B1*
    B2
    +
    A
    B
    B
    A
    1-N “DÉBIL”
  • 23. Diseño de transacciones
    Veamos un error más que cometen los alumnos…
    • Definenclaves primarias con componentes de más…
    Realidad a ser descripta:
     Un médico en una fecha, solamente puede tener una consulta
     Se le asigna un consultorio para atender
    Solución de alumno:
    DoctorId*
    DoctorName
    MedicalAppointmentDate*
    DoctorId*
    RoomId*
    DoctorName
    RoomDescription
    RoomFloor
    RoomId*
    RoomDescriptionRoomFloor
  • 24. Diseño de transacciones
    Veamos un error común más…
    Para que alumno visualice su error de diseño
     recomendamos esquematizarle las tablas que se crean con datos
  • 25. Diseño de transacciones
    A raíz de lo anterior, surge también explicar…
    ¿Claves primarias compuestas por conjunto
    de atributos que determinan unicidad?
    ¿Claves primarias ficticias?
    MedicalAppointmentId *
    MedicalAppointmentDate
    DoctorId
    RoomId
    DoctorName
    RoomDescription
    RoomFloor
    MedicalAppointmentDate*
    DoctorId*
    RoomId
    DoctorName
    RoomDescription
    RoomFloor
  • 26. Reglas en transaccionesy eventos de disparo
  • 27. Reglas en transaccionesy eventos de disparo
    INTERACTIVAMENTE
    REGLAS SIN EVENTO DE DISPARO
    REGLAS CON EVENTO DE DISPARO (ON …. )
  • 28. Reglas en transaccionesy eventos de disparo
    Algunos errores comunes:
    ¿Hay atributos disponibles para pasar por parámetro en una invocación que tiene evento de disparo “onAfterComplete”?
    ¿No?
    ¿Si?
    ¿De cuáles niveles?
     Sí, del primer nivel
  • 29. Reglas en transaccionesy eventos de disparo
    Algunos errores comunes:
    ¿Es correcto asignar valores a atributos…
    … OnAfterComplete?
    … OnBeforeComplete?
     No, ya es tarde..
  • 30. Reglas en transaccionesy eventos de disparo
    Algunos errores comunes:
    Definiciones de reglas que involucran atributos del 2do nivel con eventos de disparo que no ocurren en dicho nivel
  • 31. Aplicación del conceptode tabla extendida
  • 32. Aplicación del conceptode tabla extendida
    Actualización directa de la tabla extendida
    En rules de transacciones
    En Foreach
    Foreach de más innecesarios
    Para navegar tablas que están disponibles en el contexto, por el concepto de tabla extendida
  • 33. Acerca de enseñar fácil…
  • 34. Sitio de capacitaciónhttp://training.genexus.com
  • 35. ¿Preguntas?
  • 36. ¡Muchas gracias!
    A/S Maia Shuster
    mshuster@artech.com.uy