SQL fÃ¼r Ref.-Integrity

Dieses Thema hat 3 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahren, 10 Monaten von Anonym.

Ansicht von 4 Beiträgen - 1 bis 4 (von insgesamt 4)

Author

Posts
15. Juni 2005 um 8:11 Uhr #2559

Anonym
Inaktiv

Hallo zusammen
ich hÃ¤tte gerne eine MÃ¶glichkeit per SQL zu erfahren welche tabellen miteinander per RI verbunden sind.

In diesem Beispiel ist der Name einer Tabelle bekannt

SELECT
REFTBCREATOR,
REFTBNAME,
RELNAME,
CREATOR,
TBNAME

FROM SYSIBM.SYSRELS
WHERE (REFTBCREATOR = ‚I00‘ AND REFTBNAME = ‚ANTRAG‘)OR
(CREATOR = ‚I00‘ AND TBNAME = ‚ANTRAG‘) WITH UR;

Wenn Ich diesen SQL-Befehl absetze so bekomme ich alle relevganten Informationen

REFTBCREATOR REFTBNAME RELNAME- CREATOR TBNAME———-
I00 ANTRAG FKEKOVNR I00 VERM
I00 ANTRAG FKEKOVNR I00 AEF_URKUNDENTEXT
I00 ANTRAG FKEKOVNR I00 LEV
I00 ANTRAG FKEKOVNR I00 STAPZUG
I00 ANTRAG FKEKOVNR I00 VERTR
I00 ANTRAG FKEKOVNR I00 KINDER
I00 ANTRAG FKEKOVNR I00 FEHLER
I00 ANTRAG FKEKOVNR I00 KOOP
I00 ANTRAG FKEKOVNR I00 BEGDAT
I00 ANTRAG FKEKOVNR I00 AEF_ADRESSDATEN

——————————————————————-

Was ich allerdings nicht bekomme aber benÃ¶tige ist die Information
ob eine abhÃ¤ngige Tabelle zugleich auch wieder eine PrimÃ¤rtabelle ist und
dann deren weiteren AbhÃ¤ngikeiten.

Also in den obigen Beispiel hat die Tabelle I00.STABZUG eine weitere PrimÃ¤rtabelle
und die wird mit dem SQL nicht angezeigt.

Un nun die Frage: Wie kriege ich per SQL alle diese Inforamtionen,
also welche Tabelle ist mit welcher verknÃ¼pft.

Mfg
zefrim

15. Juni 2005 um 11:59 Uhr #3009

Anonym
Inaktiv

Sowas lÃ¤sst sich nur mit rekursivem SQL lÃ¶sen. Das gibt es in DB2 fÃ¼r z/OS ab Version 8.

( Hab ich leider noch nicht, darum kann ich Dir kein entsprechendes Statement zusammenbasteln ).

Ansonsten gibt es noch das REPORT TABLESPACESET Utility ( aber das ist natÃ¼rlich kein SQL … )

15. Juni 2005 um 13:48 Uhr #3323
Anonym
Inaktiv
Hallo,

um eine Ãœbersicht von per RI verbundenen Tabellen zu bekommen, verwende ich eine kleine selbstgeschriebene REXX/CMS Pipelines-Prozedur, welche mir zumindest drei Ebenen anzeigt – leider sieht das Ergebnis hier im Forum sehr schief aus:
```
	

	********************************************************************************

	 Information from SQLDBAP1 for table TSTEILESTAMMX              

	 max. 3 levels                                 

	********************************************************************************

	                                        

	                                        

	parent table      D   dependent table 1 S   D   dependent table 2 S

	-------------------  -   ----------------- -   -   ----------------- -

	                                        

	TSTEILESTAMMX   +-- C --- TSBEZUG      A +-- C --- TSBEZUGSCOLL    A

	                                        

	            C --- TSBEZUG      A +-- C --- TSBEZUGSMATERIAL  A

	                                        

	            C --- TSMODELL      A                

	                                        

	            C --- TSPROGRAMM     A +-- C --- TSPROGSTUELIWERK  A

	                                        

	            R --- TSARBEITSPLAN   A +-- C --- TSARBEITSGANG   A

	                                        

	            R --- TSDISPO      A                

	                                        

	            R --- TSLAGERORT     A                

	                                        

	            R --- TSWERK       A                

	                                        

	                                        

	+------------------------------------------------------------------------------+

	! explanation (for more information SQL Reference, Appendix C - SQL/DS-Catalog)!

	+------------------------------------------------------------------------------+

	!                                       !

	!      D = delete rule        S = status              !

	!      ---------------        -----------------------       !

	!      R = restrict         A = active              !

	!      C = cascade          I = inactive             !

	!      N = set null         D = implicitly inactive       !

	!                                       !

	+------------------------------------------------------------------------------+

	Ready; T=0.07/0.09 15:41:56                           

	Ready; T=0.01/0.01 15:41:56                           

	

	
```
GruÃŸ
Bunbury
22. September 2005 um 12:01 Uhr #3519

Anonym
Gast

Hallo zusammen,

hatte nun auch das Problem und hab mal das SQL dafÃ¼r zusammengebastelt. Ist ein bischen unÃ¼bersichtlich, habe mich dabei am IBM-Beispiel aus dem Application Programming and SQL Guide orientiert – deshalb sind die Correlation-Ids in diesem Zusammenhang auch etwas verwirrend (Root, Parent und Child). Sie beziehen sich nicht auf die RI, sondern auf die rekursiven Datenmengen.

Hier wird alle Tabellen mit dem gleichen Creator quasi nach unten hin untersucht. Dort, wo der Parent-Creator eingeschrÃ¤nkt wird, kann auch weiter auf eine Tabelle eingeschrÃ¤nkt werden (Column REFTBNAME), oder mit like die Auswahl verÃ¤ndert werden.

Probleme dÃ¼rfte es noch bei self-referencing RI geben – hier kommts wahrscheinich zum Loop (noch nicht getestet).

Hier nun das SQL:

WITH FKLIST
(PCREATOR,
PNAME,
CCREATOR,
CNAME,
CFK,
CDELRULE)
AS (SELECT
ROOT.REFTBCREATOR,
ROOT.REFTBNAME,
ROOT.CREATOR,
ROOT.TBNAME,
ROOT.RELNAME,
ROOT.DELETERULE
FROM
SYSIBM.SYSRELS ROOT
WHERE
ROOT.REFTBCREATOR = ‚Parent-Creator‘
UNION ALL
SELECT
CHILD.REFTBCREATOR,
CHILD.REFTBNAME,
CHILD.CREATOR,
CHILD.TBNAME,
CHILD.RELNAME,
CHILD.DELETERULE
FROM
FKLIST PARENT,
SYSIBM.SYSRELS CHILD
WHERE
PARENT.CCREATOR = CHILD.REFTBCREATOR AND
PARENT.CNAME = CHILD.REFTBNAME )

SELECT DISTINCT
SUBSTR (PCREATOR, 1, 8) AS PCREATOR,
SUBSTR (PNAME , 1, 18) AS PNAME ,
SUBSTR (CCREATOR, 1, 8) AS CCREATOR,
SUBSTR (CNAME , 1, 18) AS CNAME ,
SUBSTR (CFK , 1, 18) AS CFK,
CDELRULE
FROM
FKLIST;
Author

Posts

Ansicht von 4 Beiträgen - 1 bis 4 (von insgesamt 4)

You must be logged in to reply to this topic.

Kurzübersicht

Anmelden