Hi Leute,

kennt ihr eine gute Software mit der man ganz einfach ein ER-Diagramm erstellen kann?
Habe es mal unter die Rubrik Datenbankprogrammierung gesteckt. Ich finde hier passt es am besten hin, anstelle von "Sonstiges"

Grüße
Confuzi Us

Guck mal hier:

informatik-forum.at/showthread…ches-Grafik-Tool-Programm

ich nehme einfach immer den Dataset-Designer. Ist vlt. kein High-End ER-Diagramm-Tool, aber fandich bislang vollkommen hinreichend.
Vor allem codet der mir gleich die Klassen, die ich brauche
Daten laden, speichern, verarbeiten

Hab's mit Access gemacht,
was mir aber nicht gefällt

okay, ich schau mir mal den DataSet-Designer an.
Ist ja denke ich einfacher für die Entwicklungen.

Was hält ihr denn von dem "Diagramm"..?
Ist das erste mal das ich eine Datenbank anlege, etc.

Grüße.

Entity Developer ist sehr gut, finde ich.

wenn du anfängerst - Finger weg vonne Datenbank! Datenbänkerei-Einstieg

Und dein Diagramm-Tool ist imo unzureichend:
Es geht nicht draus hervor, welche Tabelle übergeordnet ist.
Ich sehe auch garkeine Spalten, die als ForeignKey taugen würden.

Also das stimmt so nicht ganz.
Der Kunde (nennen wir Ihn mal BMW) hat unter Umständen ZICH Adressen und auch ZICH Ansprechpartner

Bei mir ist das ganze so aufgebaut:

1. Adressstamm
2. Kundenstamm
3. Ansprechpartnerstamm

Ein Kunde kann mehrere Adressen haben (Rechnungsadresse, Lieferadresse usw.)
Ein Kunde kann mehrere Ansprechpartner haben
Ein Ansprechpartner wiederum kann auch mehrere Adressen haben.

EDIT:
Jede Tabelle sollte eine ID haben, die von anderen Tabellen verwendet wird um Verknüpfungen herzustellen.
Verknüpfungen in anderen Tabellen sind so genannte Foreign Keys.

Beispiel: Kunde-Adresse

Der Kunde hat eine eindeutige ID und einen ForeignKey-Adresse
Der Adress-Key in der Kunden-Tabelle ist mit der ID der Adress-Tabelle verknüpft.
Jeder Kunde hat dann mehrere Adress-Keys wie zB.
RechnungsKey
MahnungsKey
VertriebsKey
usw...

Und für jeden davon wird ein Datensatz in der Adress-Tabelle angelegt.
Wenn natürlich Rechnungs- und Mahnungs-Adresse identisch sind, steht in beiden logischerweise der gleiche Adress-Key.

Ich verwende entweder MySQL-Workbench oder Managementstudio.

MemoAnMichSelbst schrieb:

Also das stimmt so nicht ganz.

ups - sorry - falls du auf mein Post antwortest:
Ich hab meine Überlegungen zum Datenmodell wieder weg-editiert, weil die lenken von meiner wesentlichen Aussage ab: nämlich dasser die Finger weglassen soll von Datenbanken.
Solange das Datenmodell noch nicht steht und zigfach erprobt ist - bindet man sich mit einer DB nur endlos zusätzliche Komplexität ans Bein - meist verbaut man sich auch jeglichen Zugang zu einer überhaupt tragfähigen Anwendungs-Architektur.
Und weil man sich Wurstel-Lösungen ebenso angewöhnt wie ordentliches ist damit für den TE der Zugang zu tragfähiger Architektur insgesamt verbaut - nicht nur für dieses (Spiel-?)Projekt.

Jap, war auf deinen Post bezogen

Ich denke mal aus diesem Grund sucht er ein Tool um ER-Diagramme zu erstellen.
Ich hatte mal ein ganz gescheites und suche gerade aufm Rechner.
Ich finde zu überladen sollte so ein Tool nicht sein.
Der Designer in VS selber ist ganz angenehm und bildet das Meiste schon ab.

Ein Spielprojekt trifft es ganz genau.
Ich hab noch eine Woche Urlaub und möchte mir eigentlich dieses Datenbank bezogene programmieren angewöhnen..

weswegen ich auch hier im Forum öfter etwas über Datenbanken nachfrage, in letzter Zeit.
Ich hab mir auch schon "Datenbank in 10 Minuten" angesehen.
Verstehen tu ich das eigentlich schon, behaupte ich mal.

Würde gern irgendetwas "basteln" das sinnvoll ist. Da dachte ich mir, wäre ja eine "Kundenerfassung" ganz okay.


Sollte ich zuerst eine riesige Datenbank mit mehreren Tabellen anlegen,
oder zuerst eine riesige Tabelle?
Das mit den PKs und FKs verstehe ich von der Logik her schon, aber praktisch anwenden kann ich es irgendwie noch nicht..

Also ne riesige Tabelle macht ja keinen Sinn

Es kommt auch immer darauf an, was du vor hast.
Visual Studio ist was so Datenbank-Programmierung angeht sehr angenehm, da man viel im Designer erledigen kann.
Deshalb haut der gute EDR denke ich auch immer in die Kerbe... erstmal mit ner XML anfangen

Wenn du aber die Datenhaltung von der Programmierumgebung losgelöst haben willst (oder wie in meinem Fall musst), dann ist es natürlich sinnvoll, so viel Logik wie möglich direkt inner DB zu verbauen und das "Programm" nur als Viewer zu verwenden.

Es sind einfach zwei total unterschiedliche Herangehensweisen.

Wenn ich eine doofe Datenbank möchte brauche ich die Schlüssel nicht?

also ich hab schon etwas kleines womit ich suchen, abrufen/ausfüllen, hinzufügen und löschen kann.
...aber halt auch nichts geniales..^^'

Also...
egal wo du ein Modell zur Datenhaltung entwickelst...
Die Verknüpfungen brauchst du.

Wenn du die Logik in eine Datenbank auslagerst, musst du dort die Verknüpfungen pflegen und nicht im Programm.
Wenn du mit VS+XML anfängst, legst du dort im Designer eben diese Verknüpfungen an.

Natürlich kannst du auch ganz auf soetwas verzichten, jedoch macht DIR das dann extrem viel Arbeit, die durch eben diese Verknüpfungen zur Verfügung gestellten Funktionen nachzubauen. Davon würde ich strikt abraten!

Confuzi Us schrieb:

Ein Spielprojekt trifft es ganz genau.
Ich hab noch eine Woche Urlaub und möchte mir eigentlich dieses Datenbank bezogene programmieren angewöhnen..

Finger weg von Datenbank - Datenbänkerei-Einstieg
Und als ER-Tool reicht der Dataset-Designer.
Externe Tools haben den Nachteil, dasse extern sind - also kannste schön Datenmodell drin konzipieren - ins Dataset holen musstes trotzdem.
Auch bieten die evtl. Features an, wo olle Dataset passen muß.

Also ich rate strikt zum Einfachsten, und bei Dataset und DatasetDesigner und sonst nix kannste auch Screenshots einstellen, und kannst zurnot auch das ganze Modell hier anhängen, oder sogar lauffähige Solution, und kannman bei Probs mal reingugge.
Mit DB dahinter wird das nicht so einfach.

Und zum Datenmodell rate ich auch zum einfachsten: Ehe du die Kunde-Entität in 4 sehr fragwürdige Entitäten zerstückelst, lass den Kunden doch erstmal zusammen, und konzipiere Produkt, Mitarbeiter, Auftrag und so Sachen.
Aber machs konkret, also lege dich fest, dass du Autozulieferer spielst, oder ZeitungsDruckerei oder Vermessungsbüro, TanteEmmaLaden, Dachdecker oder Leihbücherei.

Weil wie MAMS bemerkt, bei Autozulieferer ists vlt. sinnvoll, Kunde iwie zu zerstückeln, bei Leihbücherei würdichdas nochmal diskutieren wollen.

Wenn du dich so bisl einfuchsen willst, funde ich das garnicht so verkehrt sowas zu splitten.
Wenn du nur ne Kundenverwaltung machen möchtest.

Vielleicht eine Beispielidee die du ja versuchen kannst umzusetzen.

Du hast einen Kundenstamm den du Programmieren willst...
Jeder Kunde hat bestimmte Daten die ihn Kennzeichnen und die man immer sehen möchte...
ZB: Kundennummer, Suchbegriff, Name, Straße, Hausnummer, Land, Plz, Ort, Telefon(Zentrale), Fax(Zentrale), EMail(Zentrale)
Dann hat er noch verschiedene zusätzliche Informationen, welche du auf einzelne Reiter setzen könntest...
Basisdaten:
Branche, Region, Sachbearbeiter, Sprache, Währung, Kunde_seit, Steuernummer, ABC-Klasse (als Top Kunde oder eher zu vernachlässigender Kunde usw.)
Rechnungsdaten:
Rechnungsintervall, Sammelrechnung, Steuergruppe, EU-Staat, Zahlungsziehl, Zahlungsart, Kreditlimit....
Lieferdaten:
Versandart, Lieferbedingung, Restriktionen (Teillieferungen, Komplettlieferungen usw.) abweichende Versandadresse...
Bankdaten:
Bank, Kontonummer, IBAN, BLZ, SWIFT-BIC, Ort...
Preisfindungsdaten:
Preisliste, Rabattgruppe usw.

Damit biste dann erstmal bisl beschäftigt und kannst das alles in logische Tabellen unterteilen und verknüpfen lernen.

Wenn das dann klappt... Kannst du es ja erweitern... Dann kannst du dir überlegen, welche dieser Daten könnte man so verdrahten, dass der Anwender nurnoch "Auswählen" braucht... Hierfür müsstest du dann wiederum Stamm-Tabellen erstellen, welche mit Unterprogrammen gepflegt werden können.

@ErfinderDesRades
ich schau mir das mal an, lerne die IDE von VB.NET auch erst richtig kennen.

Werde mir zuerst auch nun ein klares Konzept ausdenken, denke ich werde das was
@MemoAnMichSelbst
vorgeschlagen hat übernehmen.

So auf "nichts" entwickeln ist immer etwas unproduktiv, klares Konzept-> klare Ziele

Ich bedanke mich erst einmal,
für eure Zeit, Mühen und Tipps

Confuzi Us