Diskussion:Structured-Entity-Relationship-Modell

Zu ergänzen

• Methodik & Vorgehen, daß in 3NF modelliert wird
• stärker herausarbeiten: bei SER modelliert man Existenzabhängigkeiten von Datentypen, bei ER Verbindungen von Datentypen
  • Bei Fertigstellung des Schemas ist offensichtlich, in welcher Reihenfolge die Tabellen "befüllt" werden müssen: von links nach rechts.
  • Auch die Referenzielle Integrität (Schlüsselvererbung) ist unmittelbar ersichtlich
  • Löschungen innerhalb der vernetzten Tabellen erfolgen von rechts nach links; ON DELETE CASCADE problemlos nutzbar (keine Zyklen)
• Metamodell
• Generalisierung & Spezialisierung
• Die 6-7 Vorteile gegenüber ER kurz gefaßt
• Kurz erklären
  • einfacher Einstieg (immer links)
  • extrem leichte Entdeckung von Zyklen (Kante führt nach links)
  • leichtes Verständnis der Existenzabhängigkeiten (von links nach rechts) und Schlüsselvererbung
• Ein größeres Beispiel (20 bis 60 Entitäten) als ERM und SERM, damit der Vorteil des ER-Typen (Reduktion der Elemente um ca 1/3) visuell sichtbar wird
• Vorgehen um ERM in SERM zu überführen und andersherum
• Literaturverweise für Details (u.a. exitieren frei zugängliche PDFs von Fachbeiträgen)

Grafische SERM-Symbole, Beispiel Datenmodell

ad Symbole: Es sollte besser herausgearbeitet werden, was genau der Unterschied zwischen Entitytyp und Entity Relationship Typ ist. So wie ich das sehe ist unabhängig (originär) dabei der Knackpunkt, ja?

ad Beispiel: Da leuchtet mir etwas nicht ganz ein:

• Kunde 0 → * Rechnung ... Rechnung die keinem Kunden zugeordnet ist? Sollte lt. Beschreibung eher 1 → * heißen, oder?

Nein: 0:1 bedeutet, dass von dem abhängigen Element 0 ODER 1 existiert. Es sind hier nicht die beiden Enden der Kante gemeint. Das linke Ende der Kante muss nicht quantifiziert werden, da sich die Anforderungen direkt aus den Existenzabhängigkeiten ergeben. Die restlichen Punkte analog (nicht signierter Beitrag von 141.13.6.237 (Diskussion) 9. Jan. 2008, 12:36)

Tut mir leid, verstehe ich nicht ganz. "Die Existenzabhängigkeiten" sollen ja gerade eben dargestellt werden, vorausgesetzt ich verstehe Ziele, Pkt. 2 richtig, also woraus sollen sich die direkt ergeben? --Geri, 13:40, 11. Jan. 2008 (CET)

Man muss die Pfeile nur richtig lesen: Pfeil von Kunde zu Rechnung bedeutet "1 Kunde ist mit n Rechnungen verknüpft", Pfeil von Rechnung zu Rechnungsposition "1 Rechnung ist mit n Rechnungspositionen" verknüpft. Kunde braucht keine Rechnung zu haben, aber einer Rechnung muss mindestens eine Rechnungsposition haben. --Peholz 17:51, 20. Sep. 2011 (CEST)

• Kunde 0 → * Auftrag ... Auftrag der keinem Kunden zugeordnet ist? Sollte lt. Beschreibung eher 1 → * heißen, oder?
• Artikel 0 → * Artikelposition ... Art.pos. die keinem Artikel zugeordnet ist? Sollte lt. Beschreibung eher 1 → * heißen, oder?
• Rechnung 1 ⇒ * Rechnungsposition ... * kann auch 0 heißen, ja? Eine Rechnung ohne Positionen?
• Auftrag 1 ⇒ * Auftragsposition ... * kann auch 0 heißen, ja? Ein Auftrag ohne Positionen?
• Auftragsposition ––– Rechnungsposition...welche Seite is 0, welche 1? Lt. Beschreibung sollte das eher 1:1 sein, nicht? Und wie man daraus eine mögliche Berechung ableiten kann ist mir auch schleierhaft.

--Geri, 01:52, 10. Jul. 2007 (CEST)

Kategorisierung

Wäre Kategorie:Diagramm nicht sinnvoll? Ist bei Entity-Relationship-Modell ja auch gegeben. --Fleasoft 13:10, 16. Aug. 2007 (CEST)

Gute Idee! Done. --Geri, 13:28, 11. Jan. 2008 (CET)

Fragwürdiger Mehrwert von SERM gegenüber ERM

Die Aussage, daß ERM keine Existenzabhängigkeiten berücksichtigt, ist schlicht falsch.

Die Min-max-Notation wie auch UML beschreiben Existenzabhängigkeiten.

Eher kann man fragen, worin der Mehrwert von SERM liegt.
Auch die Links-rechts-Anordnung kann im ERM vorgenommen werden, was von einigen Autoren auch empfohlen wird. tzeh 08:44, 20. Apr 2006 (CEST)

Der wesentliche Mehrwert dürfte im Entity-Relationship-Datentyp liegen. Dadurch wird erreicht, daß die Komplexität des Diagramms deutlich reduziert wird und ein Element im Diagramm genau einer Tabelle in der Datenbank entspricht. Daraus resultiert auch, daß die Anordnung der Elemente von links nach rechts Sinn macht und leidlich eindeutig ist, was im normalen ER nicht funktioniert.
Ich kann versichern, wenn man einmal damit gearbeitet hat, ist es so logisch, daß man sich wirklich zwingen muß, wieder mit dem deutlich primitiveren normalen ER zu arbeiten, falls auf Kundenwunsch, etc. erforderlich. Mh 03:24, 19. Okt. 2008 (CEST)

Lieber Mh, mir ist schleierhaft, wie durch zusätzliche Strukturelemente (hier Entity-Relationship-Datentyp) die Komplexität reduziert werden kann. Zeige bitte konkret den Mehrwert von SERM gegenüber ERM auf. Die Links-rechts-Anordnung kann im ER-Diagramm anhand der 1:n-Beziehungen ebenfalls vorgenommen werden. Sie macht auch dort Sinn. Was soll im "normalen ER" nicht funktionieren? Bitte belege dies möglicht durch ein Beispiel. Dank im voraus und freundliche Grüße. tzeh 21:11, 19. Okt. 2008 (CEST)

Hallo tzeh, vielleicht kann ich ein wenig ergänzen.

Die Komplexität wird IMHO reduziert, da die reine Anzahl von Elementen in einem Diagramm reduziert wird, erfahrungsgemäss um 1/3. Bei kleinen Diagrammen mag das unterheblich sein, bei 50 oder 200 Entitäten ist es dagegen eine massive Entlastung. :::Die Formulierungen "Die Links-rechts-Anordnung kann im ER-Diagramm ..." und "...was von einigen Autoren auch empfohlen wird." drücken ganz deutlich einen weiteren Vorteil von SERM aus: Die quasi-hierarchische Ordnung ist bei ERM optional (und mir in der betrieblichen Praxis noch nie über den Weg gelaufen), bei SERM verpflichtend (und immer eingehalten) - damit sind beim SERM die Vorteile des einfachen Einstiegs (immer links), der extrem leichten Entdeckung von Zyklen (Kante führt nach links) und des leichten verständnisses der Existenzabhängigkeiten (von links nach rechts) und Schlüsselvererbung immer gegeben, beim ERM leider fast nie.

Ein weiterer Vorteil, der im Artikel leider nicht sichtbar wird, ist die Darstellungen von Generalisierung/Spezialisierung, die bei SERM vorhanden ist, bei ERM dagegen nicht (nur in Erweiterungen wie SERM auch eine ist - wenn man sowieso Erweiterungen nutzt, wieso nicht gleich eine, die viele Dinge auf einmal kann, also zB SERM?).

Ganz nebenbei: Ich kenne wenige Menschen, die bei ER sauber in 3. Normalform modellieren. Beim SER macht man das automatisch, wenn man sich an die Methodik hält. Das sehe ich durchaus als Vorteil, denn ein bestehendes ERM bis zur 3NF zu normalisieren ist mit gehörigem Aufwand verbunden - das ERM muss dabei verändert werden und das zieht Diskussionen nach sich.

Ich hoffe, ein bissl weitergeholfen zu haben. Der Artikel müsste massiv überarbeitet werden, damit diese Dinge als auch die Methodik klar werden - leider habe ich momentan nicht die Muße, das zu erledigen, aber schonmal einige TODOs notiert. --Schoschi 12:04, 6. Nov. 2008 (CET)

Hallo Schoschi, Dank für Deinen Versuch, mir und der Gemeinschaft das SERM schmackhaft zu machen!

Hallo tzeh, gern.

Zur Reduktion der Anzahl der Elemente: dies bezweifle ich, es sei denn mit Informationsverlust. Bitte belege Deine Behauptung durch ein nachvollziehbares Beispiel.

Der ER-Typ ist eine kompakte Repräsentation für schwachen E-Typ und zugehörigen R-Typ, d.h. aus 2 wird 1 Element, ohne Informationsverlust. In jedem Diagramm mit schwachen E-Typen ist SERM zwangsläufig kompakter als ERM. Modelliere doch bitte das Vertriebs-bsp mit Deinem ERM-Tool (ich habe keines) in ERM und lade es hier hoch. Vergleiche dann Dein ERM mit dem SERM und Du siehst daß ERM 12 Elemente und SERM bloß 6 hat. Du kannst gern das SERM auf verlorene Information prüfen; solltest Du da etwas finden, sag bitte bescheid.

Von Dir bestätigt: Die links-rechts-Anordnung ist auch bei ERM möglich. Somit ist dies kein Vorteil bei SERM.

"möglich" ist ungleich "immer vorhanden", d.h. die Erleichterung ist bei ERM praktisch nur gelegentlich vorhanden, bei SERM immer. Darin sehe ich einen Vorteil des SERM.

Generalisierung/Spezialisierung: Ist in einigen ERM-Varianten (z.B. ISOTEC von Ploentzke) möglich ... und dazu noch einfach und elegant.

Genau, ERM kann's nicht, sondern Erweiterungen, wie eben auch SERM. ISOTEC kenne ich nicht, ist dies eleganter als SERM?

"Ich kenne wenige Menschen, die bei ER sauber in 3. Normalform modellieren." Das mag sein, dass Du nur wenige kennst; so hast Du auch mich erst hier auf der Diskussionsseite kennengelernt.  ;-)) Wichtiger jedoch ist, dass "saubere Modellierung" keine Frage der Darstellungsmethodik (ob ERM oder SERM) sondern der semantischen Analyse ist (mit der ich über 30 Jahre beschäftigt bin). Insofern bezweifle ich die von Dir behauptete "automatisch" richtige Modellierung bei SERM. Wenn dem so wäre, gäbe es hierfür bereits Automaten (sprich Programme)

Automaten/Automatisierbarkeit sind hier nicht relevant, sondern die Modellierungs-Methodik, also das Vorgehen. Daß bei SERM in 3NF modelliert wird, wurde AFAIK in der Habil-Arbeit von Prof Sinz formal bewiesen. Willst Du mehr als einen formalen Beweis? ;-)

"Der Artikel müsste massiv überarbeitet werden...": Dem kann ich hier bei SERM nur zustimmen; insbesondere muß m.E. die Sinnfälligkeit des Entity-Relationship-Typs herausgearbeitet werden, wenn dieser denn sinnfällig ist...

Siehe oben zu Reduzierte Zahl von Elementen in Diagrammen.

Ich grüße Dich freundlich tzeh 17:24, 6. Nov. 2008 (CET)

Viele Grüße, Georg -- Schoschi 21:24, 12. Nov. 2008 (CET)

Bildbeschreibung fehlt bei [[Bild:SERM_Typen.svg|SERM-Symbole|400px]] und [[Bild:SERM_Beispiel2.svg|SERM-Beispiel|600px]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:SERM_Typen.svg|SERM-Symbole|400px]] und [[Bild:SERM_Beispiel2.svg|SERM-Beispiel|600px]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 10:29, 2. Mär. 2009 (CET)

Frage zu den Kanten

Im Abschnitt "Darstellungsregeln für SER-Diagramme" heißt es

Die Kanten eines SER-Diagrammes geben Aufschluss über die Relation zwischen den Typen.

Was ist hier mit Relation gemeint? Die Relation aus der Datenbanklehre oder eher Relation im Sinne von Kardinalität? -- Black Monk Theme 23:04, 23. Jun. 2009 (CEST)

Unteres Beispiel austauschen

Ich finde das untere Beispiel ist unglücklich gewählt, wie der erklärende Satz ("Das Unternehmen rechnet sehr genau mit dem Personal") zeigt. Es sollte ein Beispiel sein, das von seiner Natur her verständliche Kardinalitäten hat, und nicht welche, die in einem Klammersatz erläutert werden müssen. Hat jemand ein besseres? (nicht signierter Beitrag von 217.13.175.94 (Diskussion) 16:33, 8. Jul 2015 (CEST)) Ich glaube, dass im ERM-Beispiel die Kardinalitäten vertauscht sind. Wenn ich den Text richtig interpretiere, müsste es doch folgende Reihenfolge sein: Fachkraft (1,1) kann (1,*) Leistung und Leistung (1,*) besteht aus (0,*) Bestandteil. Die Kardinalität steht wie hier immer vor dem Entity auf das es sich bezieht, oder? --RayonDerDritte (Diskussion) 22:07, 23. Jul. 2015 (CEST)