Suchen: Tool für DB reverse engeneering

[nico1964]

Hallo Leute,

suchen mal wieder was schlaues und hoffen auf eure Hilfe.

Wir sind auf der Suche nach einem Tool für DB reverse engeneering und aus den Ergebnissen sollte dann ein Datenbankmodell erstellt werden.

Status Quo bei uns ist foglender:
V5R4
QDDSSRC mit ca. 830 PF-Sourcen und ca. 280 LF-Sourcen.

Für Tipps wären wir sehr dankbar.


Andreas

[BenderD]

... eh hier jemand ernsthaft den Ooops Nerv vorschlägt, am ehesten würde ich das noch ErWin zutrauen, die meiste Arbeit fängt damit aber erst an, wenn man was erreichen will.

D*B

Hallo Leute,

suchen mal wieder was schlaues und hoffen auf eure Hilfe.

Wir sind auf der Suche nach einem Tool für DB reverse engeneering und aus den Ergebnissen sollte dann ein Datenbankmodell erstellt werden.

Status Quo bei uns ist foglender:
V5R4
QDDSSRC mit ca. 830 PF-Sourcen und ca. 280 LF-Sourcen.

Für Tipps wären wir sehr dankbar.


Andreas

[nico1964]

... eh hier jemand ernsthaft den Ooops Nerv vorschlägt, am ehesten würde ich das noch ErWin zutrauen, die meiste Arbeit fängt damit aber erst an, wenn man was erreichen will.

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

[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]

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.

[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