Suchen: Tool für DB reverse engeneering

[BenderD]

... auch da gilt: was nicht in Constraints hinterlegt ist, kann nicht als Key Beziehung sauber erkannt werden und Hilfskriterien wie Namensgleichheit von Feldern gehen auch in den Wind; das landet dann oft bei einem großen Haufen von Tabellen, die nix miteinader zu tun haben, sieht also eher nach Datenschrank als nach Datenbank aus, was ja auch oft die Realität widerspiegelt.

D*B

Hallo,
danke, dass Du den Leuten gleich mal den Wind aus den Segeln nimmst, denn der Oooooops Nerv kommt für uns absolut nicht in Frage. Das mit etwas erreichen wollen ist auch so eine Sache, nur haben wir leider einen Audit Task ausgefasst, der Besagt, dass uns ein Datenbankmodell fehlt. Und bei uns ist das in den Jahren natürlich historisch gewachsen und es gibt nur mehr sehr wenige, die alle Zusammenhänge kennen. Am allerwenigsten unsere Chefs und die wollen das jetzt haben.

mfg
Andreas

[Fuerchau]

Aus der Historie betrachtet hilft auch häufig Namensgleichheit nicht, da auf Grund der 6-stelligen Beschränkung Beziehungen dieser Art eher intern geregelt werden als dass sie extern erkannt werden können.
Häufig werden wegen RPG verschiedene Suffixe/Prefixe verwendet wo jede automatische Erkennung scheitert.

Hier hilft auch keine DB-Betrachtung alleine ohne ggf. die PGM-Quellen zur Verfügung zu haben.

LF's spielen in der Betrachtung auch eher nur eine untergeordnete Rolle.

[nico1964]

Aus der Historie betrachtet hilft auch häufig Namensgleichheit nicht, da auf Grund der 6-stelligen Beschränkung Beziehungen dieser Art eher intern geregelt werden als dass sie extern erkannt werden können.
Häufig werden wegen RPG verschiedene Suffixe/Prefixe verwendet wo jede automatische Erkennung scheitert.

Hier hilft auch keine DB-Betrachtung alleine ohne ggf. die PGM-Quellen zur Verfügung zu haben.

LF's spielen in der Betrachtung auch eher nur eine untergeordnete Rolle.

Hallo,
da unsere gesamte Anwendung in COBOL geschrieben ist und wir nicht mit den kurzen Datenbanknamen arbeiten, sonder mit ALIAS, habe wir gegenüber RPG wahrscheinlich ein kleinen Vorteil. Und die PGM-Sourcen sind bei uns auch vorhanden, da es sich um eine hausinterne Entwicklung handelt.
Also für Tipps, die uns in die richtige Richtung weisen, sind wir weiterhin dankbar.

mfg
Andreas

[Fuerchau]

Der ALIAS ist eine AS/400-Spezifikation, der aus SQL-Sicht (meines Wissens nach) nicht erkannt wird.
Für die DDS-Tabelle muss ich ja trotzdem 10-stellige Namen verwenden.

[nico1964]

Der ALIAS ist eine AS/400-Spezifikation, der aus SQL-Sicht (meines Wissens nach) nicht erkannt wird.
Für die DDS-Tabelle muss ich ja trotzdem 10-stellige Namen verwenden.

Bei SQL kommts darauf an, was du definiert hast:

Namenskonvention . . . . . . . *SYS *SYS, *SQL

Und wir haben schon mal mit Altova DATAirgendwas probiert und die können sehr wohl die ALIAS aus der DDS interpretieren und das meiner Meinung nach auch richtig. Nur dieses ALTOVA ist einfach zu kompliziert und meines Erachtens auch zu teuer, für was wir es einsetzen sollen.

mfg

[Pikachu]

Also für Tipps, die uns in die richtige Richtung weisen, sind wir weiterhin dankbar.

Da diese Datenbankdokumentationen ja sowieso meistens nicht mehr benützt und vor allem nicht mehr aktualisiert werden nachdem sie einmal erstellt sind, wie wärs damit: Alle DDS ausdrucken, in Ordner ablegen und in einem Schrank verstauen.

[Fuerchau]

Wenn du was billiges suchst, dann nimm doch einfach Access.

Verknüpfe einfach alle Tabellen (PF's mit weniger als 32 LF's, ansonsten Haupt-LF mit Keys) und definiere die Beziehungen über den Beziehungsmanager.
Bei Namensgleichheit erkennt Access automatisch die Schlüssel, ansonsten per Drag/Drop die Beziehung definieren.

Andere billige Tools bieten da wohl auch nicht viel mehr.

[nico1964]

Wenn du was billiges suchst, dann nimm doch einfach Access.

Verknüpfe einfach alle Tabellen (PF's mit weniger als 32 LF's, ansonsten Haupt-LF mit Keys) und definiere die Beziehungen über den Beziehungsmanager.
Bei Namensgleichheit erkennt Access automatisch die Schlüssel, ansonsten per Drag/Drop die Beziehung definieren.

Andere billige Tools bieten da wohl auch nicht viel mehr.

Bei ACCESS habe ich das Problem, dass wir einige Dateien haben, die die Aufnahmefähigkeit von ACCESS sprengen(m.w.n. unter 300 Spalten und wir haben Tabellen > 300 Spalten)

naja dann wünsch ich noch ein schönes wochenende, gruß aus dem sonnigen Wien
Andreas

[nico1964]

Da diese Datenbankdokumentationen ja sowieso meistens nicht mehr benützt und vor allem nicht mehr aktualisiert werden nachdem sie einmal erstellt sind, wie wärs damit: Alle DDS ausdrucken, in Ordner ablegen und in einem Schrank verstauen.

Das ist unser Problem, müssen das in Zukunft lt. unserem Audit hegen und pflegen, darum suchen wir ja ein Tool, das uns dabei unterstützt.

[BenderD]

... da solltet ihr euch schon mal mit ErWin befassen. Da geht es nach dem Reverse Engineering in umgekehrter Reihenfolge weiter; Dateien werden im Datenmodel gepflegt und dann die Erstellungsskripte (SQL oder DDS) generiert. ErWin ist auf allen Plattformen weit verbreitet (AS/400 weniger) und hat PlugIns für die AS/400 - ist natürlich kein LowCost und erst recht nicht gratis. Die OpenSource und Freeware Teile können kein AS/400, jedenfalls kenne ich da keines.

D*B

Das ist unser Problem, müssen das in Zukunft lt. unserem Audit hegen und pflegen, darum suchen wir ja ein Tool, das uns dabei unterstützt.

[UFK]

Warum nicht MySQL ?

Und im Übrigen, ich glaube, der unselige OpsNav kann, wenn ich mich nicht irre, ein komplettes SQL-Script erstellen, mit dem das Schema der ganzen Collection exportiert werden kann.

[holgerscherer]

Und im Übrigen, ich glaube, der unselige OpsNav kann, wenn ich mich nicht irre, ein komplettes SQL-Script erstellen, mit dem das Schema der ganzen Collection exportiert werden kann.

Schon, das kann er. Nur gelegentlich ranzt er dabei ab oder braucht RAM ohne Ende. Zumindest als Anfang gehts.

Ach ja, der IBM Systems Director Navigator for i (AKA: Port 2001) unter V7R1 ist da inzwischen recht gut gelungen und erstellt notfalls SQLs für eine ganze Bibliothek. Sogar schneller als über den OpsNerv, man hat halt nur ein paar Sekunden Last auf der AS400.

-h