-
Suchen: Tool für DB reverse engeneering
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
Andreas
Ein AS/400 Dinosaurier since 1989
-
... 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
Zitat von 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
-
Zitat von 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,
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
Andreas
Ein AS/400 Dinosaurier since 1989
-
... 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
Zitat von nico1964
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
-
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.
-
Zitat von 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.
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
Andreas
Ein AS/400 Dinosaurier since 1989
-
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.
-
Zitat von 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.
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
Andreas
Ein AS/400 Dinosaurier since 1989
-
Zitat von nico1964
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.
-
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.
-
Zitat von Pikachu
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.
Andreas
Ein AS/400 Dinosaurier since 1989
-
Zitat von 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.
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
Andreas
Ein AS/400 Dinosaurier since 1989
Similar Threads
-
By Kirsten Steer in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 11-12-06, 08:51
-
By Kirsten Steer in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 11-12-06, 08:28
-
By Mickey in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 13-07-06, 12:37
-
By Toschie in forum NEWSboard Programmierung
Antworten: 9
Letzter Beitrag: 21-06-06, 11:53
-
By becama in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 12-05-06, 19:46
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks