<#-- löscht aus 'trans_cifx' alle Mehrfahrvorkommen bzgl. der Gruppierung nach 'key', 'sourcesystem', 'sourcesystem_id' außer dem mit der "minimalen" 'apnr' -->\
<@cleanup_trans_cifx system=systeminfo_id />\
<@cleanup_trans_cifx system=systeminfo_id />\
\
\
update ${source_table} set druck=substring(druck from 1 for 100), lang_1=substring(lang_1 from 1 for 150);\
update ${source_table} set druck=substring(druck from 1 for 100), lang_1=substring(lang_1 from 1 for 150);\
\
\
<#-- Kommentarblock BEGINN: Alle nach 'key' zur "Transformation" ausgewählten Einträge von der 'source_table' nach 'tmp_cifx2' kopieren -->\
--bei HISinOne wird in erster priorität "uniquename" verwandt.\
--bei HISinOne wird in erster priorität "uniquename" verwandt.\
--bei SOSPOS ist im Entladescript "uniquename=apnr\
--bei SOSPOS ist im Entladescript "uniquename=apnr\
insert into tmp_cifx2(\
insert into tmp_cifx2(\
@ -513,40 +544,16 @@ where apnr is not null\
${c.key}\
${c.key}\
<#if c_has_next>,</#if>\
<#if c_has_next>,</#if>\
</#foreach>);\
</#foreach>);\
<#-- Kommentarblock ENDE -->\
\
\
--nun wird apnr auf Eindeutigkeit geprüft. Bei Datenquelle sospos muss dies gegeben\
--nun wird apnr auf Eindeutigkeit geprüft. Bei Datenquelle sospos muss dies gegeben\
--sein, bei HIS1 ggf. nicht, wenn in uniquename ein NULL oder ein Duplikat steht.\
--sein, bei HIS1 ggf. nicht, wenn in uniquename ein NULL oder ein Duplikat steht.\
\
\
--zuerst: Duplikate ermitteln:\
--zuerst: Duplikate ermitteln:\
create temp table tmp_doppelt\
<@tmp_cifx2_apnr_duplikate_nullen />\
(\
key integer, apnr char(255)\
) \
;\
insert into tmp_doppelt\
select key,apnr FROM tmp_cifx2\
group by 1,2\
having count(*)>1;\
\
\
<#if SQLdialect='Postgres'>\
--Postgres Dialekt:\
update tmp_cifx2 set apnr = NULL\
where (key, apnr) in (\
select key, apnr\
from tmp_doppelt);\
\
<#else>\
--Informix Dialekt:\
update tmp_cifx2 set apnr = NULL\
where '' || key || '_' || apnr in (\
select '' || key || '_' || apnr\
from tmp_doppelt);\
</#if>\
\
drop table tmp_doppelt;\
\
\
\
\
<#-- Kommentarblock BEGINN: WENN es für 'tmp_cifx2' mit 'apnr = NULL' passende Einträge (nach 'sourcesystem_id', 'key', 'systeminfo_id' und 'sourcesystem') in 'trans_cifx' gibt, werden diese gesetzt -->\
--nun: apnr=NULL oder sourcesystem_id bereits vorhanden:\
--nun: apnr=NULL oder sourcesystem_id bereits vorhanden:\
--gibt es den Schlüssel aus dem gleichen Quellsystem schon?\
--gibt es den Schlüssel aus dem gleichen Quellsystem schon?\
-- Wenn ja, vorhandene Schlüssel in Ladetabelle umsetzen:\
-- Wenn ja, vorhandene Schlüssel in Ladetabelle umsetzen:\
@ -564,34 +571,10 @@ and T.systeminfo_id=${systeminfo_id} --zul\
and T.sourcesystem=${Quellsystem_var} \
and T.sourcesystem=${Quellsystem_var} \
)\
)\
;\
;\
create temp table tmp_doppelt\
<#-- Kommentarblock ENDE -->\
(\
<@tmp_cifx2_apnr_duplikate_nullen />\
key integer, apnr char(255)\
) \
;\
insert into tmp_doppelt\
select key,apnr FROM tmp_cifx2\
group by 1,2\
having count(*)>1;\
\
\
<#if SQLdialect='Postgres'>\
--Postgres Dialekt:\
update tmp_cifx2 set apnr = NULL\
where (key, apnr) in (\
select key, apnr\
from tmp_doppelt);\
\
<#else>\
--Informix Dialekt:\
update tmp_cifx2 set apnr = NULL\
where '' || key || '_' || apnr in (\
select '' || key || '_' || apnr\
from tmp_doppelt);\
</#if>\
\
drop table tmp_doppelt;\
\
\
<#-- Kommentarblock BEGINN: WENN es für 'tmp_cifx2' mit 'apnr = NULL' passende Einträge (nach 'sourcesystem_id', 'key', und 'sourcesystem') in 'trans_cifx' gibt, werden diese gesetzt; d.h., der Kommentar unten ist vermutlich falsch: Hier wird nicht nach anderen _Quellsystemen_ geschaut, sondern ob eine anderen BI-Komponente denselben Schlüssel aus demselben Quellsystem "vorliegen hat" - bei Mehrfachtreffern wird hier wieder einfach per "min" auf 1 reduziert -->\
--gibt es den Schlüssel schon bei anderem Quellsystem?\
--gibt es den Schlüssel schon bei anderem Quellsystem?\
update tmp_cifx2 set apnr=(select min(apnr) from trans_cifx T\
update tmp_cifx2 set apnr=(select min(apnr) from trans_cifx T\
where T.sourcesystem_id=tmp_cifx2.sourcesystem_id\
where T.sourcesystem_id=tmp_cifx2.sourcesystem_id\
@ -607,34 +590,10 @@ and T.key=tmp_cifx2.key\
and T.sourcesystem=${Quellsystem_var} \
and T.sourcesystem=${Quellsystem_var} \
)\
)\
;\
;\
create temp table tmp_doppelt\
<#-- Kommentarblock ENDE -->\
(\
<@tmp_cifx2_apnr_duplikate_nullen />\
key integer, apnr char(255)\
) \
;\
insert into tmp_doppelt\
select key,apnr FROM tmp_cifx2\
group by 1,2\
having count(*)>1;\
\
\
<#if SQLdialect='Postgres'>\
--Postgres Dialekt:\
update tmp_cifx2 set apnr = NULL\
where (key, apnr) in (\
select key, apnr\
from tmp_doppelt);\
\
<#else>\
--Informix Dialekt:\
update tmp_cifx2 set apnr = NULL\
where '' || key || '_' || apnr in (\
select '' || key || '_' || apnr\
from tmp_doppelt);\
</#if>\
\
drop table tmp_doppelt;\
\
\
<#-- Kommentarblock BEGINN: wenn in 'trans_cifx' keine "passenden" 'apnr''s gefunden wurden, dann wird dies per Lookup auf 'cifx' anhand von 'uniquename', 'key' und dem aktuellen Datum versucht; interessant wäre: (JoWi) Wie kommt denn eine Konstellation, in der 'trans_cifx' leer ist aber 'cifx' nicht? Antwort: Die 'trans_cifx' ist praktisch eigentlich nur in der Konstellation mit zwei Vorsystemen (HISinOne plus Gx) in Verwendung - im anderen Fall wird sie wohl nicht benutzt - daher 'cifx' -->\
--Falls trans_cifx nicht gefüllt ist, Fallback Lösung:\
--Falls trans_cifx nicht gefüllt ist, Fallback Lösung:\
update tmp_cifx2 set apnr=(select min(apnr) from cifx T\
update tmp_cifx2 set apnr=(select min(apnr) from cifx T\
where T.uniquename=tmp_cifx2.uniquename\
where T.uniquename=tmp_cifx2.uniquename\
@ -648,33 +607,9 @@ and T.key=tmp_cifx2.key\
and today() between T.d_akt_von and T.d_akt_bis\
and today() between T.d_akt_von and T.d_akt_bis\
)\
)\
;\
;\
create temp table tmp_doppelt\
<#-- Kommentarblock ENDE -->\
(\
<@tmp_cifx2_apnr_duplikate_nullen />\
key integer, apnr char(255)\
<#-- Kommentarblock BEGINN: für die 'tmp_cifx2'-Einträge, die noch keine 'apnr' haben (NULL), wird diese erzeugt: Je 'key' werden Schlüssel der Form '_<number>' angelegt (z.B. '_12'), 'number' wird dabei hochgezählt; um nicht mit evtl. früher erzeugten Schlüsseln zu kollidieren, wird als minimale 'number' die höchste 'tid' des 'key' aus 'cifx' gesetzt; die (in einer "Hilfstabelle") generierten Schlüssel werden 'tmp_cifx2' über sie 'sourcesystem_id' zugeordnet; vermutlich weil diese evtl. nicht eindeutig ist (und evtl. mehrere Schlüssel für eine generiert werden) hier das "min" im UPDATE-Statement...(JoWi) aber wie kommt es, dass an dieser Stelle noch immer nicht von Eindeutigkeit auszugehen ist!? Die Prüfroutinenmeldung "...kann nicht erzeugt werden." dürfte eigentlich niemals auftreten, oder!?-->\
) \
;\
insert into tmp_doppelt\
select key,apnr FROM tmp_cifx2\
group by 1,2\
having count(*)>1;\
\
\
<#if SQLdialect='Postgres'>\
--Postgres Dialekt:\
update tmp_cifx2 set apnr = NULL\
where (key, apnr) in (\
select key, apnr\
from tmp_doppelt);\
\
<#else>\
--Informix Dialekt:\
update tmp_cifx2 set apnr = NULL\
where '' || key || '_' || apnr in (\
select '' || key || '_' || apnr\
from tmp_doppelt);\
</#if>\
\
drop table tmp_doppelt;\
--wenn es den Schlüssel noch gar nicht gibt, wird er künstlich erzeugt\
--wenn es den Schlüssel noch gar nicht gibt, wird er künstlich erzeugt\
--dabei wird für jeden key eine temp. Tabelle erzeugt, mit einem \
--dabei wird für jeden key eine temp. Tabelle erzeugt, mit einem \
--serial Feld, das hochzählt\
--serial Feld, das hochzählt\
@ -742,7 +677,9 @@ drop table tmp_keygen;\
\
\
delete from tmp_hilf;\
delete from tmp_hilf;\
</#list>\
</#list>\
<#-- Kommentarblock ENDE -->\
\
\
<#-- Kommentarblock BEGINN: fehlende Gültigkeiten in 'tmp_cifx2' setzen und Abgleich zwischen 'cifx' und 'tmp_cifx2': Wenn ein Satz in 'tmp_cifx2' einen (nach 'key', 'apnr') entsprechenden in 'cifx' hat, wird die 'tid' als 'tid_orig' nach 'tmp_cifx2' übernommen und der Satz aus 'cifx' entfernt -->\
--nun ist apnr immer gefüllt\
--nun ist apnr immer gefüllt\
\
\
--Zum Schluss der Insert:\
--Zum Schluss der Insert:\
@ -772,6 +709,7 @@ where '' || key || '_' || apnr in \
\
\
delete from ${target_table} where tid in (select tid_orig from tmp_cifx2);\
delete from ${target_table} where tid in (select tid_orig from tmp_cifx2);\
\
\
<#-- Kommentarblock BEGINN: jetzt kann es wohl noch Duplikate der Kombination 'key', 'apnr' in 'tmp_cifx2' geben - von diesen werden alle außer denen mit der jeweils niedrigsten 'tid' gelöscht -->\
@ -812,7 +750,9 @@ and 0=(select count(*) from tmp_dopp D where D.tid=tmp_cifx2.tid );\
\
\
</#if>\
</#if>\
drop table tmp_dopp;\
drop table tmp_dopp;\
<#-- Kommentarblock ENDE -->\
\
\
<#-- Kommentarblock BEGINN: hier werden die den Einträgen in 'tmp_cifx2' entsprechenden Sätze zuerst aus 'trans_cifx' gelöscht und dann durch die aus 'tmp_cifx2' ersetzt - anhand der Kriterien 'key', 'apnr' bzw. 'key', 'sourcesystem_id' (in Bezug auf 'tmp_cifx2') _und_ 'systeminfo_id', 'sourcesystem' (in Bezug auf die Komponente, in der das Skript läuft und das konfigurierte Vorsystem - genauer gesagt werden die 'trans_cifx'-Einträge durch Anreicherung mit diesen Daten aus 'tmp_cifx2' _generiert_); danach wird die 'tid' aus 'cifx' _als_ 'cifx_tid' _in_ 'trans_cifx' nachgetragen ((JoWi) was ich nicht verstehe: ich dachte, das hätten wir in 684 ff. bzgl. 'tmp_cifx2' gemacht - wird aber im INSERT nicht übernommen!? AUßERDEM: Sind nicht die 'cifx'-Einträge gelöscht worden???) -->\
--dann einfügen in trans_cifx\
--dann einfügen in trans_cifx\
--Zur Sicherheit zuerst Löschung über uniquename:\
--Zur Sicherheit zuerst Löschung über uniquename:\
<#if SQLdialect='Postgres'>\
<#if SQLdialect='Postgres'>\
@ -862,7 +802,9 @@ where key = trans_cifx.key and apnr = trans_cifx.apnr)\
where cifx_tid is null\
where cifx_tid is null\
and 0 < (select count(*) from tmp_cifx2\
and 0 < (select count(*) from tmp_cifx2\
where key = trans_cifx.key and apnr = trans_cifx.apnr);\
where key = trans_cifx.key and apnr = trans_cifx.apnr);\
<#-- Kommentarblock ENDE -->\
\
\
<#-- Kommentarblock BEGINN: hier werden die Schlüssel von 'parent'-Elementen gesetzt...(JoWi) vermutlich fachlich inkorrekt: Die 'apnr' als Schlüssel des 'parents' zu setzen, ignoriert, dass in HISinOne Elternelemente sich qua 'lid'-Logik auf _mehrere_ Datensätze beziehen können, während die 'apnr' ja ausweislich der ganzen Logik, mit der sie gepflegt wird, eindeutig sein sollte; das, was sich in dieser Setzung widerspiegelt ist also u.U./gewissen Konstellationen fachlich inkorrekt!? -->\
--nun die parents umsetzen:\
--nun die parents umsetzen:\
<#list cifx_keys_transform as cifx_key>\
<#list cifx_keys_transform as cifx_key>\
\
\
@ -873,8 +815,10 @@ and T.systeminfo_id=${systeminfo_id}\
and tmp_cifx2.parent::varchar(255)=T.sourcesystem_id)\
and tmp_cifx2.parent::varchar(255)=T.sourcesystem_id)\
where key = ${cifx_key.key}\
where key = ${cifx_key.key}\
and parent is not null;\
and parent is not null;\
<#-- Kommentarblock ENDE -->\
\
\
\
\
<#-- Kommentarblock BEGINN: hier werden in erster Linie die Sätze aus 'tmp_cifx2' nach 'cifx' geschrieben; mit der Zweiteilung hat es folgende Bewandtnis: für Einträge, die vorher ihre Entsprechung hatten, die aber (in vorhergehenden Schritten) aus der 'cifx' gelöscht worden sind, bleiben die originalen 'tid's erhalten (die werden _zuerst_ übernommen); für die restlichen Einträge werden neue 'tid's generiert - auf Basis der größten vorhandenen 'tid' in 'cifx' nach dem ersten Schritt -->\
</#list>\
</#list>\
--zuerst vorhandene Schlüssel:\
--zuerst vorhandene Schlüssel:\
insert into ${target_table}(tid,key,hs,apnr,kurz,druck,lang_1,\
insert into ${target_table}(tid,key,hs,apnr,kurz,druck,lang_1,\
<#-- Kommentarblock BEGINN: ein paar 'minor' Schritte!?: Texte kürzen, Schlüssel protokollieren, die nicht transformiert werden konnten, in 'trans_cifx' die dem Eintrag entsprechende 'cifx_tid' - also die 'tid' den entsprechenden 'cifx'-Eintrags hinzufügen ((JoWi) ich weiss leider nicht, wo das genutzt wird!?) -->\
update ${target_table} set druck=kurz, kurz=substring(druck from 1 for 10)\
update ${target_table} set druck=kurz, kurz=substring(druck from 1 for 10)\
where kurz is not null and druck is null;\
where kurz is not null and druck is null;\
\
\
@ -995,19 +941,21 @@ where key = trans_cifx.key and apnr = trans_cifx.apnr);\
drop table tmp_cifx2;\
drop table tmp_cifx2;\
drop table tmp_keys;\
drop table tmp_keys;\
drop table tmp_hilf;\
drop table tmp_hilf;\
<#-- Kommentarblock ENDE -->\
\
\
\
<#-- Kommentarblock BEGINN: Hochschulnummern aus 'hochschulinfo' in 'cifx' nachtragen und leere Gültigkeiten auf Maximalintervall setzen -->\
\
--Damit die Hochschulnummern in der CIFX und in der Hochschulinfo-Tabelle\
--Damit die Hochschulnummern in der CIFX und in der Hochschulinfo-Tabelle\
-- uebereinstimmen, ist folgender UPDATE notwendig:\
-- uebereinstimmen, ist folgender UPDATE notwendig:\
\
\
update ${target_table}\
update ${target_table}\
set hs = (select hs_nr from hochschulinfo)\
set hs = (select hs_nr from hochschulinfo)\
where hs != 0;\
where hs != 0 and (select count(*) from hochschulinfo) = 1;\
\
\
update ${target_table} set d_akt_von=date_val('01.01.1900') where d_akt_von is null;\
update ${target_table} set d_akt_von=date_val('01.01.1900') where d_akt_von is null;\
update ${target_table} set d_akt_bis=date_val('01.01.2900') where d_akt_bis is null;\
update ${target_table} set d_akt_bis=date_val('01.01.2900') where d_akt_bis is null;\
<#-- Kommentarblock ENDE -->\
\
\
<#-- Kommentarblock BEGINN: (JoWi) scheinbar gibt es noch eine 'cifx_customize', in der ergänzende Anpassungen an der 'cifx' hinterlegt werden können!? In den Musterdaten allerdings leer... -->\
