SQL für Ref.-Integrity
- Dieses Thema hat 3 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre von
Anonym.
-
AuthorPosts
-
15. Juni 2005 um 8:11 Uhr #2559
AnonymInaktivHallo 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,
TBNAMEFROM 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
AnonymInaktivSowas 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
AnonymInaktivHallo,
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
AnonymGastHallo 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;
-
AuthorPosts
You must be logged in to reply to this topic.
