Die Datenmodellierer von FastChangeCoTM haben immer wieder das Problem, dass im PowerDesigner Mappings von Views zu Tabellen verloren gehen.
Xuefang Kaya (eine der Datenmodelliererinnen im Data Management Center of Excellence (DMCE) Team) stellte fest, dass dies nur im Zusammenhang mit Views als Source Data Objects auftritt.
Was ist das Problem?
Xuefang erklärt dem DMCE-Team anhand eines einfachen Beispiels, wie und warum PowerDesigner Mappings verliert. Sie hat eine „Standard View“ als Source Data Object erstellt, das eine einfache SELECT-Anweisung enthält. Mit dem Mapping Editor erstellte Xuefang ein Mapping auf das Target Data Object „Standard View“ (Tabelle).
Source Data Object (View)
SELECT Column_1 AS Column_1 ,Column_2 AS Column_2 ,Column_3 AS Column_3 FROM MyDummyOwner.MyTable
Einfache SELECT-Anweisung der View
Target Data Object (Table)
„Die folgende Abbildung zeigt ein intaktes Mapping. Alle Spalten sind korrekt verbunden und zeigen den vorgesehenen Datenfluss von der Quelle zum Ziel“ führt Xuefang aus.
„Nach der Änderung der einfachen SELECT-Anweisung in eine etwas komplexere Anweisung verliert der PowerDesigner ein Data Item Mapping (Column_3). Das liegt daran, dass der PowerDesigner - aus mir unbekannten Gründen - die GUID des Source Data Items verliert, auf das sich das Data Item Mapping bezieht. Das eigentliche Mapping existiert ja noch, nur das ursprüngliche Source Data Item (GUID) existiert nicht mehr“, erklärt sie weiter.
SELECT Column_1 AS Column_1 ,Column_2 AS Column_2 ,CASE WHEN Column_3='X' THEN 'Z' ELSE Column_3 END AS Column_3 FROM MyDummyOwner.MyTable
Etwas komplexere SELECT-Anweisung der View
Dieses Phänomen verursacht viel zusätzlichen Aufwand im DMCE-Team und hat immer wieder nicht unerhebliche Auswirkungen, wenn das verlorene Mapping beim Testen nicht bemerkt wird.
Was ist die Lösung?
„Meine Recherchen haben folgende Workarounds ergeben, die sich als recht stabil erwiesen haben. Leider kann ich nicht ausschließen, dass trotzdem noch Mappings verloren gehen. Aber wir können ja nicht warten, bis der Hersteller uns eine Lösung anbietet“, zuckt Xuefang mit den Schultern.
„Als erstes solltet ihr immer die entsprechenden Views auf User-Defined stellen. Das findet ihr in den View-Properties auf der Registerkarte General“, und sie demonstriert es gleich im PowerDesigner.
„Der zweite wichtige Schritt, um das Verschwinden von Mappings zu verhindern, besteht darin, die SELECT-Anweisung zu ‘kapseln’. Damit meine ich, dass man entweder eine Table Subquery erstellt oder eine Common Table Expression (CTE) verwendet. Auf diese Weise bleibt das eigentliche (äußere) SELECT immer unverändert, egal ob man eine CASE-Anweisung oder JOINS zum SELECT hinzufügt“.
Das Team folgt gespannt den Ausführungen von Xuefang. Mit zwei Beispielen veranschaulicht sie, was sie meint.
Lösung mit einer Table Subquery
SELECT Column_1 ,Column_2 ,Column_3 FROM ( SELECT Column_1 ,COALESCE(Column_2,'') ,CASE WHEN Column_3='X' THEN 'Z' ELSE Column_3 END AS Column_3 FROM MyDummyOwner.MyTable ) AS SubTable
Lösung mit einer CTE
WITH myCte AS ( SELECT Column_1 AS Column_1 ,COALESCE(Column_2,'') AS Column_2 ,CASE WHEN Column_3='X' THEN 'Z' ELSE Column_3 END AS Column_3 FROM MyDummyOwner.MyTable ) SELECT Column_1 ,Column_2 ,Column_3 FROM myCte
Das DMCE Team und Xuefang sind mit dem Workaround nicht wirklich zufrieden, da das eigentliche Problem nicht gelöst ist. Aber sie können damit leben und sind den zusätzlichen Aufwand los, den die verlorenen Mappings verursacht haben.
Bei der Umsetzung mit den CTEs tauchte dann ein neues Problem auf. Aber das ist eine andere Geschichte. Mehr darüber im nächsten Artikel der Serie. Ihr müsst unbedingt wieder vorbeischauen.
Bis dahin
Euer Dirk