0007 consejo para_futuros_instructores_genexus
•Descargar como PPTX, PDF•
0 recomendaciones•369 vistas
Recomendados
Más contenido relacionado
Similar a 0007 consejo para_futuros_instructores_genexus
Similar a 0007 consejo para_futuros_instructores_genexus (20)
Más de GeneXus
Más de GeneXus (20)
0007 consejo para_futuros_instructores_genexus
- 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!
- 7. Se creantablasfísicas de más
- 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”
- 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…
- 35. ¿Preguntas?
- 36. ¡Muchas gracias! A/S Maia Shuster mshuster@artech.com.uy
Notas del editor
- 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.