Software- bzw. Datenbankmodellierung

[Nayko]

Hallo!
Ich hatte mein Problem bereits im Forum schon gepostet, aber wahrscheinlich unter dem falschen Topic. Hier nochmal die Problemstellung:

Das Problem, das ich habe, ist, dass ich eine Webanwendung schreiben soll. Der komplette Sachverhalt ist schwierig darzustellen, aber ich versuchs mal...Und zwar dreht es sich um Testapparaturen für elektronische Bauteile. Es gibt verschiedene Tests, die auf unterschiedlichen Maschinen ausgeführt werden. Es können mehrere verschiedene Tests pro Bauteil durchgeführt werden. Für jede Testart gibt es mehrere Tester, die entweder baugleich oder -ungleich sind. Nun kann es sein, dass Elektronikbauteile entweder auf allen baugleichen oder -ungleichen Testern getestet werden kann. Allerdings kann es auch sein, dass das Testen nur auf einem bestimmten Tester durchgeführt werden kann.
Als Beispiel:
Es gibt TesterA1-A5, TesterB1-B3 und TesterC1.
Das Testen des Bauteils A soll auf den TesternA stattfinden. Aus techn. Gründen kann jedoch nur auf TesterA1 und TesterA3 getestet werden. Alternativ kann Bauteil A auch auf TesterB2 und TesterC1 geprüft werden. Der Nutzer soll nun eine Anzeige erhalten, dass Bauteil A auf A1 oder A3 getestet werden kann, alternativ auf B2 oder C1. Alle anderen Tester dürfen nicht verwendet werden (A2, A4, A5, B1, B3).
Soweit der Sachverhalt. Letztendlich soll dem Nutzer angezeigt werden, welches Bauteil auf welchem Tester geprüft werden kann und auf welchem nicht.
Nutzer können unterschieden werden in informative und administrative. Das bedeutet User, die die Informationen nur abrufen und User, die neue Bauteile und deren Tester erfassen.
Klar ist, dass dafür eine Datenbank benötigt wird.
Mein Problem ist nun meine Herangehensweise. Ist es falsch eine relationale Datenbanklogik aufzubauen? Sprich soll die Verwaltung etc. auf (relationaler) Datenbankebene geschehen oder ist das dann Aufgabe der Programmlogik (ASP.NET/C#/VB oder Perl)?
Ich wäre sehr dankbar für Anregungen und Kritik.

Mit freundlichen Grüßen

[hwoess]

Eine Datenbank wirst du wohl brauchen und relationale Datenbanken sind heutzutage der Standard. Ich bin ein Fan von "soviel Regeln wie möglich in die Datenbank legen". So würde ich zB die Datenbank so aufbauen, dass diese, um bei deinem Beispiel zu bleiben, keine Messdaten eines Tests von Bauteil_A auf TesterA2 einfügen lässt, aber eine entsprechende Anzeige dieser Einschränkung sollte natürlich bereits das Erfassungsprogramm machen, damit der Anwender das gar nicht probiert. Und sollte es vielleicht jemand per "Fremdzugriff" (zB duch eine Datenimport) probieren, wird das eben durch die Datenbank abgelehnt.

bye,
Helmut

[edit]: die Regeln zB. so hinterlegt, dass man eine Tabelle mit den gültigen Kombinationen hat, in der würde sich dann eben "Bauteil A / TesterA1", "Bauteil A / TesterA3", .... finden und wenn man später den Test auf Tester A2 freigeben will, dann braucht man diese Kombination nur mehr in diese Tabelle einfügen. Ganz Ordentliche statten die Kombination dann vielleicht noch mit einer Zeitdefinition aus, wie zB "gilt Ab" bzw. "gilt Bis" :-)

[Nayko]

Hallo, Danke und entschuldige meine verspätete Antwort.
Die Idee ist ganz gut, aber ich glaube mein Hauptproblem ist es, dass ich noch nie eine komplexere relat. DB modelliert habe...Bisher eher im kleinen Stil, wie bspw. Firma hat Kunden und bietet Produkte und best. Ansprechpartner an.
Gibt es dafür evtl. einen Einstiegspunkt, wie ich beginnen könnte? Soetwas wie eine Nominalphrasenanalyse in der OO nur für relat. DB

[Thomas Rith]

Ich nutze beim MS SQL-Server immer die Diagramme. Dort fängst Du einfach an zu werkeln, von der kleinsten Einheit (Bauteil, Tester) und baust die immer komplexeren Gebiete zusammen. Wenn Du feststeckst im Aufbau, schauen wo der Fehler ist und korrigieren, oder gleich nochmal anfangen... Erst, wenn man denkt, das Konstrukt passt, die Anwendung bauen.

ps: Bin ein Fan von Datenbanken und lege da soviel ab, wie nur geht... ^^

[fanderlf]

Hallo zusammen,

Wenns ums Editieren von irgendwelchen Daten geht, dann müssen die ja auch irgendwo persistiert werden, sonst sind sie beim nächsten mal Programm starten nicht mehr da. Also brauchst Du wohl eine Art Datenspeicherung. Wie genau die geartet ist sollte man sich von Fall zu Fall überlegen. Wenn das Programm z.B. exakt an einem Platz läuft reichen auch Dateien aus. Heutzutage kann man sich dazu auch mal eine NoSQL Datenbank anschauen, da relationale Datenbanken einen gewissen Overhead erzeugen den man oft gar nicht braucht. Zumal NoSQL Datenbanken im allgemeinen wesentlich einfacher einzusetzen sind als relationale Datenbanken (noch dazu sind sie meist Open Source und damit kostenfrei).

Ich glaube die Diskussion hatten wir schon mal, aber ich würde meine Logik auf gar keinen Fall in die Datenbank packen. Ich denke dass Logik am Besten im Programmcode aufgehoben. Heutzutage gibt es O/R-Mapper mit denen man Objekte auf relationale Datenbanken mappen kann (z.B. NHibernate oder Entity Framework), in NoSQL Datenbanken werden sowieso nur Objekte abgespeichert - dort kann man keine Logik ablegen.
Dadurch dass ich also quasi direkt Objekte speichern kann, kann ich im Programm ganz normal mit meinen Objekten programmieren die ich mir ohne Datenbank so (oder so ähnlich) auch geschrieben hätte. Hier wäre dann der Ansatz zuerst mit den Objekten zu beginnen und die DB hinterher aufzuziehen (natürlich sollte man auch einen Blick drauf haben, dass man die Objekte gemapped bekommt). Trotzdem der Ansatz Model-First.
Für diesen Ansatz spricht auch, dass man den Persistenzlayer auch mal austauschen kann. Habe ich die ganze Logik in der DB wird es sehr schwierig einen neuen Persistenzlayer zu bauen (z.B. weil man die Datenbank wechselt oder von Filebasierter Persistenz auf DB umsteigt)

Wie gesagt das sind alles Glaubensfragen und da muss wohl jeder seinen eigenen Weg finden.

[jogi01]

hi...

aber ich würde meine Logik auf gar keinen Fall in die Datenbank packen

ich muss fanderlf an dieser stelle wiedersprechen.
die businesslogik gehört zu den daten. denn die daten gehören auf jedenfall in ihrer konsistens geschützt.

und je komplexer das ER-model um so wichtiger ist es die nicht in Apps zu legen.

sicher sollte die App dem anwender nicht mögliche anwahlen gar nicht erst zulassen.

Daten, Parameter, referenz-codes alles in die DB packen.

ggf sogar mit einer zwischenschicht an code auf der DB agieren damit auch APP-erweiterungen die durch andere dienstleister erstellt werden, nicht an der businesslogik rütteln können.

zur erstellung eines Datenmodells kann ich nur zu einem tool wie ErWin oder im Oraclebereich zum Designer raten.
und weiterhin solltest du versuchen an die 3 Normierungsform ran zu kommen.
dies stellt die möglichkeiten zur DM-Erweitung einfacher bereit und DM-Änderungen werden weniger.

Achte weiterhin darauf dass du mit Contraints (PK, UK, FK, Check) agierst.

Vermeide PK welche über mehrere Spalten gehen.
Am besten ist es dass der PK Numerisch ist und aus der Datenbank heraus "selbstständig" erstellt wird.

und noch einige weitere punkte.. das würde aber hier den rahmen sprengen.

greetz

Jogi

DM-Architekt, Oracle DBA, Oracle Entwicklung

[hwoess]

Ich bin da vollinhaltlich bei jogi01 - baue meine Applikationen auch nach diesen Grundsätzen.

bye,
Helmut