Konzept für Materialdatenbank



  • Hallo zusammen,

    ich möchte für Ingenieurberechnunen eine Materialbasis aufbauen. Nun stellt sich die Konzeptfrage.

    Wenn ich die Materialien in "ist-ein"-Relationen aufbaue, erhalte ich einen Baum:

    Material (Wurzel) <--Stoff
                      <--Metall
                      <--Isolator
                      <--...
    

    Metall könnte man z. B. weiter unterteilen

    Metall <--Eisen
           <--Nicht-Eisen
           <--Elektroblech
    

    Ich bin unsicher, wie ich weiter vorgehe, hier wären die vielleicht zu naheliegenden Ideen basierend auf dem Template-Pattern:

    1. Wie unterteile ich weiter? Ist es sinnvoll, dass z. B. Kupfer und Aluminium eine eigene Klasse bekommen oder sind sie vielmehr eine "enum" innerhalb von "Nicht-Eisen"?
    2. Beispiel: Ein Stoff hat eine Viskosität, ein Metall nicht. Bringe ich nun eine virtuelle Funktion "gib_viskositaet" in der Basisklasse "Material" unter und überschreibe sie nur für "Stoff"?
    3. Wie wäre eine ganz allgemeine Funktion "gib_wert(...)", die dann als Argument übergeben bekommt, was genau verlangt ist, also z. B. "gib_wert(VISKOSITAET)"? Dann müsste es aber eine Liste mit allen physikalischen Größen geben?
    4. Auch die Abhängigkeiten von der Umgebung sind nicht einheitlich, Stoffwerte hängen von Temperatur und/oder Druck ab, magnetische Werte des Elektroblechs von der Flussdichte und der Frequenz. Da die Umgebungsparameter im Laufe einer Berechnung häufig konstant sind, möchte ich sie auch irgendwo speichern, also z. B. in einer Klasse "Umgebung"?

    Meine Frage ist einfach: Wie bekomme ich einen sauberen Entwurf, der später das Hinzufügen von entweder neuen Materialen und auch neuen physikalischen Größen ermöglicht?

    Danke für eure Hilfe!


  • Mod

    Das klingt mir sehr nach einer Frage über objektorientierte Programmierung, wenn das Thema doch eine Datenbank ist. Mach einfach eine allgemeine Datenbank, in der die Stoffe stehen und die Stoffe haben dann jeweils die für sie angemessenen Eigenschaften. Dann hat Quecksilber eben einen Eintrag für Viskosität und einen für Ist-Metall, und Eisen hat hingegen einfach keinen Eintrag für Viskosität. Das Programm zum Zugriff auf diese Datenbank kennt alle möglichen Eigenschaften und wie es damit umzugehen hat, wenn ein Stoff diese Eigenschaft aufweist (oder wie es mit unbekannten Eigenschaften umgeht).



  • RungeZipperer schrieb:

    Metall <--Eisen
           <--Nicht-Eisen
           <--Elektroblech
    

    Wenn man bedenkt, dass die meisten chemischen Elemente Metalle sind, dann ist diese Einteilung doch etwas überraschend. Da sie für Dich sinnvoll erscheint, ist es wohl so, dass Du aus einem Bereich kommst, in dem diese Aufteilung sinnvoll ist. Das heißt aber auch, dass man ohne genaue Kenntnisse Deines Bereichs nicht sagen kann, wie eine gute Strukturierung der Daten für Dich aussehen sollte. Magst Du die Anwendung für Deine Datenbank etwas genauer skizzieren?



  • Dieser Thread wurde von Moderator/in Jester aus dem Forum Mathematik und Physik in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Gregor schrieb:

    RungeZipperer schrieb:

    Metall <--Eisen
           <--Nicht-Eisen
           <--Elektroblech
    

    Wenn man bedenkt, dass die meisten chemischen Elemente Metalle sind, dann ist diese Einteilung doch etwas überraschend. Da sie für Dich sinnvoll erscheint, ist es wohl so, dass Du aus einem Bereich kommst, in dem diese Aufteilung sinnvoll ist. Das heißt aber auch, dass man ohne genaue Kenntnisse Deines Bereichs nicht sagen kann, wie eine gute Strukturierung der Daten für Dich aussehen sollte. Magst Du die Anwendung für Deine Datenbank etwas genauer skizzieren?

    Die Einteilung kommt durch die stark unterschiedlichen Eigenschaften: Beim Eisen/Elektroblech gibt es eine Magnetisierungskurve, die abgebildet werden muss, beim Nicht-Eisen geht es bei mir vorrangig um die Eigenschaften als elektrischer Leiter und seine Temperaturabhängigkeit.

    Es geht um ein Projekt zur Berechnung von elektrischen Maschinen. In diesen Maschinen gibt es viele unterschiedliche Materialien, die je nach Betriebspunkt der Maschine sich ändern. Da ist also z. B. das Elektroblech, das je nach Frequenz und Flussdichte andere Verlustwerte aufweist. Dann gibt es Isolationsmaterialien, dann Kupfer und Aluminium als elektrischre Leiter. Als Kühlmedium entweder Luft oder Waser oder...

    Die Materialdatenbank soll sowohl einige vordefinierte Standardgrößen beinhalten als auch vom Benutzer Eingaben ermöglichen (Zunächst einfach über die Angabe in einem Textfile).

    Ziel ist, alles so allgemeingültig aufzubauen, dass es nicht nur für dieses Berechnungsprojekt funktioniert sondern auch für andere technische Problemstellungen. Ich denke mal ganz weit nach vorne, vielleicht eine Kabelauslegung, vielleicht thermische Berechnungen...

    Dafür ringe ich nun mit mir, wie ich das ganze am besten anlege.



  • Eine Materialdatenbank ist etwas sehr komplexes. Ich glaube, Du solltest da am Anfang relativ fokussiert bleiben, was die Anwendung betrifft. Es existieren ja auch diverse Materialdatenbanken, zum Beispiel die Inorganic Crystal Structure Database. Ich weiß nicht, ob Du darauf Zugriff hast und daher ein paar Ideen beziehen könntest. ...und die ICSD hat wohl auch einen anderen Fokus als Du benötigst.

    RungeZipperer schrieb:

    Die Einteilung kommt durch die stark unterschiedlichen Eigenschaften: Beim Eisen/Elektroblech gibt es eine Magnetisierungskurve, die abgebildet werden muss, beim Nicht-Eisen geht es bei mir vorrangig um die Eigenschaften als elektrischer Leiter und seine Temperaturabhängigkeit.

    Dann benenne die die Einteilung auch nach den Eigenschaften. 😉 Es gibt nämlich jenseits von Eisen noch weitere magnetische Materialien. Zum Beispiel Cobalt und Nickel oder aber auch jede Menge komplexere Materialien.



  • Gregor schrieb:

    Dann benenne die die Einteilung auch nach den Eigenschaften. 😉 Es gibt nämlich jenseits von Eisen noch weitere magnetische Materialien. Zum Beispiel Cobalt und Nickel oder aber auch jede Menge komplexere Materialien.

    OK, ich war nicht exakt, unter "Eisen" fällt alles, was mit Stahl zu tun hat, unter Nicht-Eisen würde auch Nickel fallen, unter Elektroblech die ferritischen Bleche. Damit würde es auch bei Nicht-Eisen magnetische Eigenschaften geben, trotzdem ist meine Einteilung technisch ok, in meinem Bereich wird es kein Nickel oder Cobalt geben ;). Das sind auch schon Feinheiten, die mich gar nicht so bedrücken, mir geht´s eher wirklich um die Muster, die sich für den Entwurf eignen würden!



  • RungeZipperer schrieb:

    Ziel ist, alles so allgemeingültig aufzubauen, dass es nicht nur für dieses Berechnungsprojekt funktioniert sondern auch für andere technische Problemstellungen. Ich denke mal ganz weit nach vorne, vielleicht eine Kabelauslegung, vielleicht thermische Berechnungen...

    Zu viel vorauszuplanen geht oft in die Hose.
    Man macht sich dadurch die Arbeit die man gerade hat oft unnötig schwer (kann so weit gehen dass man das aktuelle Projekt dadurch tötet). Und oft kann man auch jetzt noch gar nicht sagen was später kommen wird.



  • hustbaer schrieb:

    RungeZipperer schrieb:

    Ziel ist, alles so allgemeingültig aufzubauen, dass es nicht nur für dieses Berechnungsprojekt funktioniert sondern auch für andere technische Problemstellungen. Ich denke mal ganz weit nach vorne, vielleicht eine Kabelauslegung, vielleicht thermische Berechnungen...

    Zu viel vorauszuplanen geht oft in die Hose.
    Man macht sich dadurch die Arbeit die man gerade hat oft unnötig schwer (kann so weit gehen dass man das aktuelle Projekt dadurch tötet). Und oft kann man auch jetzt noch gar nicht sagen was später kommen wird.

    Jetzt kommen wir doch ein wenig vom Thema ab, aber wie betont mein Chef stets:

    So viel Grips zu Beginn eines Projekts in die Konzepte zu stecken, um möglichst alle Eventualitäten auszuschließen, ist gut angelegte Zeit. Denn jeder Fehler im Projekt selbst erhöht den Aufwand um ein Vielfaches der zu Beginn vermeintlich gesparten Zeit.

    Ansichtssache, ich denke, es gibt natürlich irgendwo einen Punkt, wo man sich entscheiden muss. Pareto...

    Aber zurück zum Thema: Hat jemand noch Ideen für Entwurfsmuster, die ich mir vielleicht noch nicht angesehen habe und die mir weiterhelfen könnten?



  • RungeZipperer schrieb:

    Jetzt kommen wir doch ein wenig vom Thema ab, aber wie betont mein Chef stets:

    So viel Grips zu Beginn eines Projekts in die Konzepte zu stecken, um möglichst alle Eventualitäten auszuschließen, ist gut angelegte Zeit. Denn jeder Fehler im Projekt selbst erhöht den Aufwand um ein Vielfaches der zu Beginn vermeintlich gesparten Zeit.

    Dein Chef hat das falsch verstanden. Wenn man weiß, was man erreichen will, lohnt es sich in Ruhe zu überlegen, wie man da hin kommt. Du weißt das aber gar nicht und versuchst deine Unsicherheit unbewusst mit Over-Engineering zu überdecken. Verbrauchte Zeit ist nicht automatisch sinnvoll investierte Zeit, egal wie viele "Entwurfsmuster" man anwendet.

    Versuche das eigentliche Problem deiner Kunden zu verstehen. Danach versuchst du eine einfache Lösung für genau dieses Problem zu finden. Je einfacher die Lösung, desto wahrscheinlicher ist sie später wiederverwendbar. Die Lösung ist ein funktionierendes Programm, nicht möglichst ausgefeilte Modelle auf dem Papier.



  • TyRoXx schrieb:

    Versuche das eigentliche Problem deiner Kunden zu verstehen. Danach versuchst du eine einfache Lösung für genau dieses Problem zu finden. Je einfacher die Lösung, desto wahrscheinlicher ist sie später wiederverwendbar. Die Lösung ist ein funktionierendes Programm, nicht möglichst ausgefeilte Modelle auf dem Papier.

    OK, vielleicht war ich nicht ausführlich genug: Ich bin in diesem Fall mein eigener Kunde und will mich selbst für die nächsten Jahre richtig aufstellen.

    Ich habe hier Projekte von vor 10 Jahren liegen, bei denen ich konzeptionell einfach gar nicht mehr zufrieden bin. So etwas will ich zukünftig vermeiden.

    Ich würde mal so sagen: Ein gutes Konzept vereinfacht das Programmieren und schafft mir Ruhe über Jahre. Ich bin zu oft mit meinen eigenen "Schnellschüssen" auf die Nase gefallen.

    Mein Doktorvater z. B. hat ein großes Ingenieurpaket für sich über Jahre geschnürt und profitiert immer wieder von vermutlich jahrzehntealtem Code. Das finde ich genial!

    Aber ich seh mich auch schon wieder irgendwann "einfach loslegen" 😃



  • Die Alternative zu "alles vorausplanen" ist zwar "nicht unnötig vorausplanen". Nur "nicht unnötig vorausplanen" heisst nicht dass man alten Code entweder 1:1 wiederverwendet oder wegwirft.

    Man kann bestehenden Code ja auch überarbeiten wenn man Schwachstellen darin erkennt. Oder neue Dinge integrieren will, die irgend welche Designänderungen nötig machen. Wenn du das sauber machst, anstatt die neuen Features auf Biegen und Brechen reinzuhacken, dann hast du nach mehreren solchen Iterationen ein Design das genau die Dinge löst die du benötigt hast. Und auch halbwegs schön löst, weil du zu dem Zeitpunkt wo du Feature X umgesetzt hast schon genug über Feature X gewusst hast um es eben sinnvoll umsetzen zu können.

    Wenn du dagegen megaviel vorausplanst, dann implementierst du nicht nur haufenweise Zeug das du vermutlich nie brauchen wirst. Du implementierst auch Dinge schlecht die du später hättest viel besser machen können. Und je mehr Code du anfangs schreibst, desto aufwendiger (und damit auch unwahrscheinlicher) wird es das ganze anzupassen.

    Starre Schnittstellen sind ein grosses Problem, nichts was man anstreben sollte. Manchmal gibt es gute (wichtige) Gründe dafür, und dann muss man halt. Dann zahlt es sich aus sich hinzusetzen und ordentlich und gründlich darüber nachzudenken wie man die Schnittstellen aufbaut. So lange man es aber nicht muss, sollte man sich das aber auf keinen Fall selbst einbrocken, aus dem Glauben heraus es sei etwas Gutes.


Log in to reply