ER-Modellierungsproblem Entität vs Attribut

A

AdventureTime

Benutzer
Beiträge
6
Hallo Ihr fleißigen Datenbankbienen,
ich hoffe mir kann bei dem folgendem Problem jemand weiterhelfen:

Zu modellieren sind Messtationen die über Sensoren verfügen.

Jede Station kann unterschiedliche Sensoren beherbergen.

Ein Sensor liefert Messgrößen (e.g. Windgeschwindigkeit) und den Messwert.

Die Wertebereiche und Messgrößen sollen einzeln zu konfigurieren sein.

Ein Mitarbeiter kann diese Geräte konfigurieren und auch den Messintervall festlegen.

Das Probem ist jetzt, dass wenn ich eine Entität namens Sensor erstelle, weiß ich nicht wie ich darstellen soll, dass ein Sensor womöglich mehrere Messgrößen liefern kann (e.g. Luftfeuchtigkeit+Temperatur). Als Attribut passt das wohl nicht - widerspricht doch der ersten NF? (Oder sind auf Normalformen, beim logischen Konzept, keine Rücksicht zu nehmen?)

Meine Lösung wäre, dass ich eine eigene Entität "Messpezifikation" erstelle, diese hat die Attribute "Messgröße" und "Wertebereich". Es kommt zu einer M:N Beziehung zwischen "Messpezifikation" und "Sensor".
sensor1.png

Ein Problem bei dieser Lösung ist, dass ich nun ja den Wertebereich aller Sensoren festlege?
Also wenn ich mit einen Sensor bei Standort A nur Windspitzen von 120km/h erfassen will, mit einen anderen Sensor aber bei Standort B jegliche Windgeschwindigkeit erfassen will, das nicht möglich ist, da die Messpezifikation, die für Windmessungen zuständig ist entweder auf 120 oder auf alle Bereiche geschaltet ist und somit auch für alle zuständigen Sensoren gilt?

Weiteres Problem: Der Mitarbeiter soll ja die Sensoren konfigurieren können - also auch die Messpezifikation einstellen. Daraus folgt eine M:N Beziehung "konfiguriert" zwischen "Mitarbeiter" und "Sensor". Aber kann dieser Mitarbeiter dann tatsächlich auch den Wertebereich ändern? Er hat doch nur eine Beziehung zu den Sensoren, nicht zur "Messpezifikation".
Soll ich einfach noch eine Beziehung zu "Messpezifikation" ziehen?

Edit:
Noch eine Frage: Die Tatsächlichen Messdaten, die die Sensoren liefern sind irgendwo zentral zu speichern. Muss man nun eine Entität "Datenspeicher" mit einer Relation "liefert Daten" von "Sensor" zu "Datenspeicher" erstellen, oder ist das (zu) trivial, da man sowieso eine Datenbank erstellt..? Ich modelliere ja auch nicht den Kunden, für den die Datenbank ist?
 
Werbung:
Hallo AdventureTime,

vielleicht helfen Dir in diesem Falle die Antworten aus folgendem Thread:
https://www.datenbankforum.com/threads/guid-über-mehere-tabellen.796/

Hier wurde das Problem mit mehreren, dynamisch zu vergebenen Attributen zu Entitäten besprochen.
In dem Thread ist auch ein anpassbares DB-Schema zu finden.

Schau's Dir mal und und gib mal ein Feedback, ob Dir das so schon reicht.

Viele Grüße,
Tommi
 
Wollte ich auch erwähnen. Ergänzend würde ich sagen: Du solltest auch den "Datenspeicher" als solchen mit modelieren, da diese Informationen ja wesentlicher Bestandteil der DB sind. Den Kunden nicht, der steht ja nicht in der DB :)
 
Danke für eure Hilfe,
also bin ich mit meiner Lösung garnicht so weit daneben, da "Messpezifikation" einen FK für Sensor besitzt und somit im Relationenmodell einfach zu realisieren sei, dass ein Sensor mehrere Messpezifikationen besitzt?
Auch der Mitarbeiter könnte mittels Join so leicht die Messpezifikation eines Sensors ändern.

Trotzdem habe ich ein mulmiges Gefühl dabei, denn angenommen ich modelliere eine Garage die mehrere Autos unterbringen kann, zusätzlich noch eine Reinigungskraft, welche die Autos pflegen soll (Reinigungskraft hat beziehung zu Auto, Auto zu Garage), so impliziere ich doch nicht, dass die Reinigungskraft auch die Garage pflegt?
Aber eben genau dieses Prinzip soll hier schon klappen?
Fehlt vielleicht also doch eine Beziehung zwischen (um beim Beispiel zu bleiben) Reinigungskraft und Garage - und eben auf mein Modell umgemappt, eine "direkte" Beziehung zwischen Mitarbeiter und Messpezifikation?

Es geht mir wirklich darum ein korrektes ERD darzustellen (nicht schon das Relationenmodell).
 
Hi,

zur Info: ERD = Entity Relationship Diagram -> Entitäten-Relations-Diagramm(Schema/Modell)

Ein korrektes ERD ist also ein Relationen-Diagramm. Hier gibt es allerdings verschiedene Darstellungs-Tiefen (ERD-0 ... ERD-x).
Und es gibt natürlich auch verschiedene Darstellungs-Möglichkeiten eines solchen ERD.

Lass in der Grafik des anderen Threads (Beispiel Attribute.jpg) einfach die Spaltennamen der Tabellen weg und zu hast ein ERD mit geringerer Tiefe.
Generell müssen die Beziehungen in der Grafik noch ergänz werden (1-1, 1-n, n-m).
In dem dargestellten Diagramm sind jedoch alle Beziehungen 1-n. (und es fehlt in den Beziehungs-Stichen natürlich noch die wundeschöne Raute in der Mitte und der Richtungs-Pfeil, aber dafür gibts ja Kulis ;))

Viele Grüße,
Tommi
 
Ich würde Mitarbeiter nur modelieren wenn es ein Rechtesystem gibt das über die DB abgebildet wird. Wenn jeder Mitarbeiter einfach die selbe Konfigurationsoberfläche hat sind die Beziehungen eher uninteressant. Wichtiger wäre es hier, die eigentlichen Sensordaten abzubilden (nämlich das ein Sensor mehrere Informationen haben kann wenn ich das richtig verstanden habe).
 
Hallo Adventuretime,

ich habe jetzt verstanden (glaube ich).
Das ergibt sich aus den Anforderungen.

Fall 1:
Jeder Mitarbeiter darf für einen Sensor seine eigenen Mess-Spezifikationen festlegen.
Dann ist die Aufteilung der Mess-Spezifikationen pro Mitarbeiter zu sehen. Für einen Sensor können also mehrere Mess-Spezifikationen von verschiedenen Mitarbeitern existieren.

Fall 2:
Für einen Sensor darf nur eine Mess-Spezifikation existieren. Welcher Mitarbeiter diese festgelegt hat, soll jedoch erkennbar sein

Für Fall 1 muss dann dein erstes Diagramm (links) gelten, for Fall 2 reicht das 2. Diagramm (rechts) aus.

Viele Grüße,
Tommi
 
Werbung:
Zurück
Oben