Programm zur DB-Modellierung

Hi Leute,

hat jemand einen Tipp für mich? Ich suche ein Pogramm, um grafisch eine rel. Datenbank mitsamt Tabellen etc zu modellieren. Dabei denke ich nicht an phpmyadmin, sondern eher sowas hier


voraussetzung: muss unter linux laufen, kostenlos sein…
ähm, achja, nicht DIA :wink:

gruß
emil

Warum suchst du eigentlich noch, wenn du schon einen Screenshot von Workbench gepostet hast?
dev.mysql.com/downloads/workbench/5.2.html

ich wollte ein paar programme vergleichen und persönliche meinungen haben :wink:
der screenshot ist nur ein schnelles google-ergebnis um zu demonstrieren was ich meine :stuck_out_tongue:

Für Postgres gibts PgAdmin III, das ist im kostenlosen Bereich praktisch unschlagbar (zumindest hab ich noch nichts besseres gefunden).

Kann PgAdmin auch aus ERD oder UML-Digrammen Datenbanken erzeugen und umgekehrt? In diesem Bereich war mir bisher nur die MySQL Workbench als gutes kostenloses Programm bekannt.

Wenn ich ehrlich sein darf… ERD und UML sind der größte Schrott den es gibt :ps:
Ein paar Zeilen gut dokumentierter Programmcode sagen viel mehr aus als diese verdammten Diagramme, die man nur braucht um die Programmstruktur Leuten zu erklären, die das ganze sowieso nicht interessiert.

[quote=„michi7x7“]Wenn ich ehrlich sein darf… ERD und UML sind der größte Schrott den es gibt :ps:
Ein paar Zeilen gut dokumentierter Programmcode sagen viel mehr aus als diese verdammten Diagramme, die man nur braucht um die Programmstruktur Leuten zu erklären, die das ganze sowieso nicht interessiert.[/quote]

Naja - Würde ich so nicht sagen. Wenn ich da an manche C/C++ Programme denke, dann bin ich froh das es diese Diagramme gibt :smoke:

Ich bin selbst c++ Programmierer und es ist unmöglich modernes C++ in Diagrammen nachzubilden.

@Emil: Zum Datenbankentwurf kann ich dir keine Software empfehlen. Ich hab dazu in den letzten 20 Jahren alles mögliche an kommerzieller und selbstgeschriebener Software ausprobiert. Aber etwas wirklich befriedigendes hab ich nicht gefunden. Gut, ich bin kein Wirtschaftsinformatiker, sondern komm aus dem systemorientierten technischen Zweig, entwickle Software für Industrieanlagen, und da sind die Anforderungen deutlich andere.

Aber vielleicht nützt dir folgendes etwas: Ich entwerfe Datenbanken nach der Methode von Prof. Kern. Das ist erst einmal das ganz gewöhnliche Entity Relationship Modell, und dann kommt Kern`s Methode zum Einsatz. Eine brauchbare (und kurze!) Beschreibung des ER Modells findest du in Moor, SQL Datenbanken. Interessant sind die ersten 30 oder 40 Seiten.

Zu Kern`s Methode gibt es nur Scripten der FH München, hab zumindest bei Amazon nichts gefunden.

Was du brauchst ist: Ein großes Blatt Papier, einen Stift, um den ersten Entwurf zu zeichnen und dann ein paar Buntstifte (und, falls vorhanden, ein paar farbige Marker). Damit kringelst du alle 1 zu 1 Relationen ein, markierst 1 zu n Relationen und überlegst dir, welche Eigenschaften du verschieben musst, welche Tabellen du zusätzlich brauchst, welche du zusammenfassen kannst und so weiter, bis du den Entwurf in 3NF hast. Üblicher weise musst du dazu den Entwurf 3, maximal 4 mal zeichnen, bis du ihn auf 3NF gebracht hast.

Den Rest kennst du ja.

Die Methode ist zwar sehr schnell, aber wenig flexibel. Wenn du irgend etwas ändern willst, geht das Spiel von vorne los. Anschließend kannst du ja den Entwurf mit irgend einer Software (Visio, Enterprise Architect, Workbench oder was auch immer) noch mal sauber zeichnen, falls dein Auftraggeber (oder Big Boss) das will.

@michi7x7: ERDs sind kein Schrott sondern zwingende Voraussetzung, um Datenbanken oder objektorientierte Software entwerfen zu können. Sobald ein Projekt mehr als 3 Klassendefinitionen enthält, kommst du beim Entwurf ohne ERD nicht mehr aus.

Bei UML muss ich dir jedoch (bedingt) zustimmen. Die 14 Diagramme von UML 2 sind deutlich zuviel, und trotzdem kann man nicht alles darstellen, was man gelegentlich braucht. Das gilt speziell für verteilte Prozesse mit nur zeitweise verfügbaren Resourcen. Trotzdem geht auch das: Mit etwas Nachdenken kann man auch das Problem der speisenden Philosophen in UML aufzeichnen. Nur: Besonders instruktiv wird das nicht…

Gar nicht zustimmen kann ich dir bei der Behauptung, es sei „unmöglich modernes C++ in Diagrammen nachzubilden“. Das Gegenteil ist der Fall. Solltest du eines deiner Projekte nicht in UML abbilden können, dann ist beim Entwurf etwas gewaltig in die Hose gegangen.

Selbst wenn du nicht innerhalb einer Gruppe arbeitest, sondern alleine, kann ich dir nur dringend empfehlen, strukturiert vorzugehen. Ich zwinge meine Mitarbeiter nicht umsonst, immer konsequent nach dem Baseball Modell zu arbeiten: OOA, OOD und zuletzt OOP. Wobei das Baseball Modell es nach jedem Schritt erlaubt, zum vorigen zurück zu springen und dort nötige Korrekturen vorzunehmen. Ich denk, dass das eine sehr intuitive Vorgehensweise ist. Wobei es sich empfiehlt, die einzelnen Schritte (in lesbarer Form!) zu dokumentieren, wenn man nicht selbst sehr schnell den Überblick verlieren will.

Ob man sich jetzt der UML Symbolik bedient, oder sein Projekt auf andere Art dokumentiert, sielt dagegen keine so große Rolle. Entscheidend ist nur, dass sie von allen Beteiligten verstanden wird. Eine Dokumentation halte ich auch für kleine Projekte, an denen man nur alleine bastelt, für unbedingt nötig, da das Programm sonst nach spätestens einem halben Jahr nicht mehr „wartbar“ ist, man es selber nicht mehr vollständig versteht. Kommentare in der Source reichen dazu nicht aus. Und ich kann es mit meiner angeborenen Faulheit nicht vereinbaren, dann erst wieder tagelang ein Programm zu analysieren, nur weil ich etwas am verwendeten Verfahren ändern will…

Schalom,

Schlomo

schlomo, ich programmiere kaum noch objekt-orientiertes C++., sondern fast nur noch generisch oder mit DESLs darstellend.
Dadurch sind Basiskomponenten schon komplett anders aufgebaut, freie Funktionen und Templates dominieren und UML-Diagramme mit Typklassen sind mir noch nicht bekannt.

Programmteile sind natürlich noch in OOP gehalten und da sind UML-Diagramme ab einer gewissen Größe natürlich sinnvoll, allerdings programmiere ich vorwiegend alleine und komme mit Interface-Beschreibungen bestens aus.

Ich will damit nicht sagen, dass es nicht notwendig ist die Programmstruktur zu planen, bevor man beginnt zu Entwickeln, allerdings muss man dabei bedenken, dass UML sehr eingeschränkt ist und es nur bedingt sinnvoll ist es einem Anfänger beizubringen.

Klingt spannend! DESL sagt mir jedoch nichts. Da hab ich eine echte Bildungslücke. Hab danach gegoogelt, aber ohne Ergebnis. Hm.

Was Typenklassen und Monaden angeht, da versagt UML wirklich. Ich hab mich da mal mit der Darstellung von Klassen mit „eingebetteter“ Statemachine beholfen, wobei ich die Operatoren als terminale Zeichen verwendet hab. Zugegeben, ist eine Notlösung.

Schalom,

Schlomo

DESL ist die Abkürzung für Domain-Embedded Specific Language, dabei werden C+±Operatoren verwendet um (vorwiegend) Typen zu erzeugen, die dann entsprechend ihres Syntax verwendet werden können.

Ein gutes Beispiel dafür ist Boost.Xpressive, dabei werden Reguläre Ausdrücke mittels DESL’s ausgedrückt.

sregex rex = sregex::compile( "(\\w+) (\\w+)!" ); //Regex als String
sregex rex = (s1= +_w) >> ' ' >> (s2= +_w) >> '!'; //Regex als DESL

Dabei kann der Compiler den kompletten Code durchoptimieren und der Code läuft i.d.R. um einiges schneller, außerdem ist diese Methode Typsicher und erlaubt direkte C+±Referenzen (wie hier s1 und s2 auf die Suchergebnisse)

WOW! Megastark! Da hab ich glatt eine wirklich spannende Entwicklung verpasst.

Hab`s gerade in Wikipedia nachgelesen und festgestellt: Da muss ich mir Literatur beschaffen! Die Idee ist zwar nicht neu, aber dass es inzwischen Tools dazu gibt, wusste ich nicht. Begeistert mich!

Ich hatte etwas Vergleichbares vor 30 Jahren als „Minisprachen“ bezeichnet, eine meiner ersten war zur Steuerung eines Roboter gedacht, basierend auf den Grafiksubset von LOGO, mit einer Syntax wie in HPGL.

Mittlerweile hab ich eine ganze Reihe von Modulen (in Delphi) für Minisprachen, angefangen von COLA (Compiler-Language), mit dem man aus einer EBNF einen Parser (Tabellarisch oder als prozeduralen Topdown Parser) erzeugen kann bis zum BORG Kern (unveröffentlicht). Weil: Die Aufgabe, eine besonders simple Sprache etwa zum Konfigurieren von Teilen einer Industrieanlage zu schreiben, gibt es ja doch relativ oft. Mich hat damals Wirth`s Idee von Compilern mit dynamischer Syntax begeistert (hat er – soweit ich mich erinnere – in seinem Compiler Buch kurz erwähnt).

Aber die Möglichkeit, aus der Minisprache heraus direkte Referenzen in das C++ (oder Delphi) Programm einzusetzen ist einfach genial! Das geht bei meinen Tools nicht so direkt. Die arbeiten alle auf einer virtuellen Maschine, die wiederum die Schnittstelle zur realen Hardware beinhaltet.

Muss ich haben! Werd mich jetzt mal auf Literatursuche begeben. (Schade, dass schon wieder so ein beknacktes Wochenende ist, aber zumindest Amazon hat ja immer offen…)

Schalom,

Schlomo

Ich kann dir diesen Artikel empfehlen: cpp-next.com/archive/2010/08/exp … roduction/ (Achtung, der ist 8-Teilig, ganz oben sind die Links)
Achtung: Das ganze ist schon extrem fortgeschrittenes C++. Bevor du dich damit befasst willst du evtl. dein Wissen über C+±Templates und damit verbundene Techniken (Tuples, Traits, Partielle Spezialisierung, …) auffrischen.

Der Artikel bezieht sich vor allem auf die Boost-Bibliotheken Proto (Bibliothek zum Erstellen von DESLs) und Spirit (Parser-Generator).

Tausend Dank für den Link! Ich bin megabegeistert! Hab mich beim Lesen sofort 20 Jahre jünger gefühlt. Da kommen alte Erinnerungen hoch, an die Vorlesungen zu den formalen Sprachen und zum Compilerbau…

An die C++ Nomenklatur muss ich mich erst gewöhnen, schreibe ja selbst hauptsächlich in den Wirthschen Sprachen, in erster Linie in Delphi. In C/C++ schreib ich meistens nur die Schnittstellen zu meinen DLLs, aber gerade jetzt im Moment hab ich den Eindruck, dass ich mich zu wenig um die Weiterentwicklungen in der C-Welt gekümmert hab. Da werd ich in den nächsten Tagen wohl ganz schön was zu Lesen haben.

Teile des Artikels erinnern mich irgendwie an einen Artikel über eine ganz simple Sprache, zu der jemand (hab den Namen vergessen) einen Compiler in OBERON geschrieben hat. Titel war: „Studentenfutter“. Damals war ich ähnlich begeistert, musste die Sprache natürlich sofort mit COLA in einen Compiler für eine virtuelle Maschine übersetzen (unter DOS, ja, lange ist`s her…)

Irgendwie hab ich den Eindruck, dass ich in den letzten Jahren zu wenig über den Tellerrand geblickt hab. Und jetzt ist es wieder da: Das „Wissen wollen, haben wollen, ausprobieren wollen“ aus den Studienzeiten. Was für einen C++ Compiler verwendest du aktuell? Ich hab hier nur den Borland C++ 3.0 Compiler und einen etwas älteren von Mikrosoft, der aber echter Extremmurx ist. Damit werd ich vermutlich nicht weit kommen.

Schalom,

Schlomo

Mit denen wirst du nicht besonders weit kommen :ps:
Wirklich brauchbar sind aktuell nur der neueste Visual-Studio Compiler (vc10) und GCC ab Version 4.5. Clang++ wird auch immer aktueller, aber das dauert wohl noch ein wenig.

Jeder dieser Compiler ist übrigens gratis (VC mit den Einschränkungen nur 32Bit und kein paralleles Kompilieren afaik)

Ich weiß nicht ob das was für dich ist.
Ich habe den Artikel gesehen und dabei an diesen Thread gedacht.
Schaus dir vllt mal an: linux-magazin.de/NEWS/UML-To … e-Software