Ich versuche, eine endgültige Version der ersten Normalform zu erhalten. Alles, was ich lese, hat einen etwas anderen Dreh.

Viele Behörden wie Date geben an, dass eine Beziehung per Definition immer in der ersten Normalform vorliegt, während andere eine Liste der Anforderungen enthalten. Dies bedeutet, dass für 1NF null bis viele Anforderungen bestehen.

Ich nehme an, der Unterschied besteht darin, dass zwischen Tabellen und Beziehungen: Tabellen können ein komplettes Durcheinander sein, während eine Beziehung bestimmten Einschränkungen folgt. Die Tatsache, dass eine Beziehung in SQL als Tabelle dargestellt wird, führt daher zu Verwirrung.

Ich konzentriere mich speziell auf 1NF, da es sich um SQL-Datenbanken handelt. Die Frage ist: Welche Eigenschaften sind erforderlich, um sicherzustellen, dass eine Tabelle in der ersten normalen Form vorliegt?

Viele Behörden schlagen vor, dass eine Tabelle, die eine Beziehung darstellt , bereits in 1NF enthalten ist. Dies führt die Definition von 1NF zurück zur Definition einer Beziehung.

Hier sind einige Eigenschaften einer Tabelle in 1NF:

• Spaltenreihenfolge ist unbedeutend [1]
• Zeilenreihenfolge ist unbedeutend
• Alle Zeilen sind gleich lang (dh Zeilendaten stimmen mit Spaltenüberschriften überein).
• Es gibt keine doppelten Zeilen (dies kann mit einem Ersatzprimärschlüssel garantiert werden, aber die PK selbst ist nicht erforderlich)
• Es gibt keine sich wiederholenden Spalten
• Jede Spalte enthält einen einzelnen Wert (atomar)

[1] Technisch gesehen sind Attribute ungeordnet, aber in einer Tabelle müssen die Zeilendaten in derselben Reihenfolge wie die Spaltenüberschriften sein. Die tatsächliche Reihenfolge ist jedoch unerheblich.

Bei mehreren Daten :

Das Konzept der Atomdaten besteht darin, dass ein Gegenstand nicht weiter zerlegt werden kann. Dieses Konzept wurde dahingehend qualifiziert, dass zwar technisch alles ad nauseum aufgeschlüsselt werden kann , die fraglichen Daten jedoch praktisch nicht weiter aufgeschlüsselt werden können, je nachdem, wie die Daten verwendet werden.

Beispielsweise sollte eine vollständige Adresse oder ein vollständiger Name normalerweise weiter aufgeschlüsselt werden, aber die Komponenten wie der angegebene Name oder der Name der Stadt sollten wahrscheinlich nicht weiter aufgeschlüsselt werden, obwohl sie als Zeichenfolgen verwendet werden können.

In Bezug auf Spalten zu wiederholen, ist es ein schlechtes Design Spalte haben fast Wiederholung Spalten, wie phone1, phone2usw. Im Allgemeinen wiederholte Daten , die die Notwendigkeit einer zusätzlichen verknüpften Tabelle anzeigt.

Abhängigkeit

Es sollte keine Beziehung zwischen Zeilen geben, außer dass sie denselben Überschriften entsprechen.

Es sollte auch keine Beziehung zwischen Spalten geben, aber ich glaube, dass dies das Thema höherer Normalformen ist.

Die Frage ist: Wie viel davon ist in der Definition von 1NF enthalten? Kommt auch das unabhängige Zeilenbit hinein?

Vorläufig

Die Definition der Normalform (die aus der Darstellung der „weiteren Normalisierung des relationalen Datenbankmodells“ im Jahr 1971 als erste Normalform bekannt ist ) und die Definition des relationalen Paradigmas selbst wurden 1970 in dem wissenschaftlichen Artikel veröffentlicht, der eine starke Form lieferte Grundlage für die Praxis der Datenbankverwaltung, dh „Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken“ (RM der Kürze halber), erstellt von Dr. EF Codd , einem Turing-Preisträger und der Autorität in Bezug auf den relationalen Rahmen.

Ja, es gibt viele Erklärungen, Interpretationen, Darstellungen, Abweichungen und Meinungen zu Dr. Codds Text, aber ich persönlich halte mich lieber an die Originalquelle und empfehle dringend, dass Sie sie selbst analysieren, damit Sie Ihre eigenen Schlussfolgerungen ziehen können.

Ich verstehe das RM sicherlich nicht in seiner Gesamtheit, aber was ich davon verstehe, erlaubt es mir, seine Exzellenz, Vision, Absicht und Reichweite zu schätzen, und obwohl man Jahrzehnte später feststellen kann, dass es einige leichte Ungenauigkeiten aufweist, verringern sie sich nicht. in jeder Hinsicht sein Genie und Eleganz. Auf seinem Gebiet hat der RM den Test der Zeit auf einzigartige Weise bestanden und ist unerreicht geblieben.

Das Hervorheben der oben genannten Ungenauigkeiten wäre - unter Verwendung eines gemeinnützigen Begriffs - unfair , da dieses wegweisende Material aus beträchtlicher Entfernung einige Verfeinerungen und Erweiterungen erforderte, ja, aber der Hauptteil der Arbeit war von Grund auf solide sehr Konzeption (und in der Tat machte Dr. Codd die meisten - wenn nicht alle - solcher Verfeinerungen und Erweiterungen selbst).

Ich lese das RM ständig neu, um mein Verständnis für diese außergewöhnliche Wissensquelle zu verbessern (und meine Wertschätzung dafür wächst mit jedem erneuten Lesen). Ziel ist es, auf den Schultern der Riesen zu stehen.

Beziehungen und Tabellen

Da Beziehungen abstrakte Ressourcen sind, stellte sich Dr. Codd die Nützlichkeit ihrer Darstellung in tabellarischer Form vor (er verwendete zunächst den Begriff „Array-Darstellung“, später jedoch „Tabelle“ oder „R-Tabelle“) Die Benutzer, Designer und Administratoren einer relationalen Datenbank (RDB) können sich ihnen vertrauter oder konkreter nähern . Daher ist es im Kontext einer RDB-Implementierung gültig, die Tabelle als Abkürzung für die Beziehung zu verwendensolange diese Tabelle für eine tatsächliche Beziehung steht. Dieses Merkmal ist - obwohl offensichtlich - ziemlich bedeutsam, da es vor der Bewertung, ob eine Tabelle eine Beziehung darstellt, die der ersten Normalform (1NF) entspricht oder nicht, genau eine Beziehung darstellen muss.

Das RM enthält natürlich die Eigenschaften, die eine Tabelle haben muss, um festzustellen, ob es tatsächlich eine Beziehung darstellt, aber ich werde hier eine informelle und unprätentiöse Interpretation darüber anbieten (eine andere, ja!):

• Es muss einen Namen haben (jede bestimmte Beziehung in einer Datenbankstruktur muss vom Rest unterschieden werden).
• Jede ihrer Zeilen muss genau ein Tupel der relevanten Beziehung darstellen.
• Die Reihenfolge der Zeilen ist überhaupt nicht wichtig.
• Jede ihrer Spalten muss einen Namen haben, der für die Bedeutung genau einer Domäne der betreffenden Beziehung steht, und dieser Name muss sich von den Namen der übrigen Spalten der Tabelle unterscheiden (eine Spalte muss eindeutig differenziert sein und tragen eine besondere Bedeutung und, ja, die Rolle, die ein Datenbankmodellierer und die Geschäftsexperten spielen, um jeden Bereich von Bedeutung mit Genauigkeit zu definieren, ist von größter Bedeutung.
• Die Reihenfolge seiner Spalten hat keine Bedeutung.
• Alle Zeilen müssen die gleiche Anzahl von Spalten haben.
• Es muss mindestens eine Spalte oder eine Kombination von Spalten enthalten, die jedes der über Zeilen dargestellten Tupel eindeutig identifiziert. Auf diese Weise müssen alle Zeilen unterschiedlich sein (ja, dies unterstreicht die Wichtigkeit, mindestens einen KEY deklariert zu haben, und wenn zwei oder mehr KEYs vorhanden sind, sollte einer aus pragmatischen Gründen als PRIMARY definiert werden, während der Rest sein kann als ALTERNATIV eingestuft; aber ja, bevor die Entscheidung getroffen wurde, war jeder der SCHLÜSSEL ein „Kandidat“ für eine Definition als PRIMÄR).

Eine Tabelle zu haben, die tatsächlich eine Beziehung darstellt, ist entscheidend, da das Ergebnis wiederum eine Tabelle ist, die eine Beziehung darstellt, wenn sie Manipulationsoperationen relationaler Art durchläuft. Auf diese Weise ist das Verhalten dieser Tabelle vorhersehbar .

Atomdomänen (Spalten)

In den ersten Abschnitten des RM stellt Dr. Codd verschiedene Beispiele für Beziehungen vor, um einige Konzepte vorzustellen. Um die Bedeutung der Atomdomäne zu verstehen , beginnen wir mit dem folgenden Auszug aus dem RM, in dem einige relevante Punkte aufgeführt sind:

Bisher haben wir Beispiele für Beziehungen diskutiert, die in einfachen Domänen definiert sind - Domänen, deren Elemente atomare (nicht zerlegbare) Werte sind. Nichtatomare Werte können im relationalen Rahmen diskutiert werden. Daher können einige Domänen Beziehungen als Elemente haben. Diese Beziehungen können wiederum auf nicht einfachen Domänen usw. definiert werden.

Auf diese Weise kann man sagen, dass jede der oben genannten Expository-Beziehungen in eine von zwei Arten passt , entweder Art A oder Art B :

• Art A gruppiert nur Relationen (Tabellen), die mit Domänen (Spalten) strukturiert sind, die in jedem ihrer Tupel (Zeilen) ausschließlich einfache Werte enthalten , dh solche Domänen (Spalten) enthalten keine Relationen (Tabellen) als Werte, die in Dieser Kontext bedeutet, dass die Werte atomar sind, da sie nicht nacheinander in neue Beziehungen (Tabellen) zerlegt werden können . Daher sind die Beziehungen dieser Klasse diejenigen, die normalisiert sind , dh sie entsprechen 1NF, ihre Form ist wünschenswert.

• Art B wird ausschließlich durch Relationen (Tabellen) integriert, die eine oder mehrere Domänen (Spalten) haben, die Relationen als Werte in jedem jeweiligen Tupel (Zeile) enthalten, und dies bedeutet, dass diese Werte nichtatomar sind, da sie anschließend in neue Relationen zerlegt werden können (Tabellen), dh sie sind zerlegbar . Somit sind die Beziehungen dieser Art nicht normalisiert, dh sie verletzen 1NF, sie liegen in einer unerwünschten Form vor.

Normalisierung

Dr. Codd führt den Abschnitt über die Normalisierung im RM mit dem folgenden Absatz ein:

Eine Beziehung, deren Domänen alle einfach sind, kann im Speicher durch ein zweidimensionales spaltenhomogenes Array der oben diskutierten Art dargestellt werden. Eine kompliziertere Datenstruktur ist für eine Beziehung mit einer oder mehreren nicht einfachen Domänen erforderlich. Aus diesem Grund (und anderen unten zu zitierenden Gründen) erscheint die Möglichkeit, nicht einfache Domänen zu eliminieren, eine Untersuchung wert! Tatsächlich gibt es ein sehr einfaches Eliminierungsverfahren, das wir als Normalisierung bezeichnen werden.

Dann zeigt er weiter:

1. Eine Gruppe von Beziehungen, in denen eine nicht normalisiert ist (sie hat Domänen, die Beziehungen als Werte enthalten, dh sie sind nichtatomar; dh sie sind nicht einfach).

2. Eine Gruppe von Beziehungen, die normalisiert sind (dh eine, die zerlegt wurde; dh eine, deren Domänen mit Beziehungswerten in einfache unterteilt wurden, was bedeutet, dass sie atomar sind).

Und dann beschreibt er das Verfahren, um normalisierte Beziehungen von nicht normalisierten zu erhalten.

In dieser Hinsicht sind die Beziehungen, die er zur Veranschaulichung einer Normalisierungsübung und der Übungsbeschreibung selbst verwendet hat, ziemlich klar, und ich empfehle erneut, dass Sie sie selbst analysieren (und ich hoffe auch, dass dies einige Leser dazu ermutigt, sich mit dem Text auseinanderzusetzen).

Nacheinander zeigt er an:

Weitere Operationen normalisierender Art sind möglich. Diese werden in diesem Artikel nicht behandelt.

Und diese Operationen, dh die zweite und dritte Normalform (2NF und 3NF), werden tatsächlich in "Weitere Normalisierung des relationalen Datenbankmodells" und wie oben erwähnt nach der Präsentation (und dem späteren Drucken und Veröffentlichen) dieses Papiers detailliert beschrieben wurde die ursprüngliche Normalform als erste Normalform bekannt.

Wie ein Praktiker beobachten kann, führt eine nicht normalisierte Beziehung (Tabellen) zu einer (fast immer unnötigen) Faltung in RDB-Implementierungen.

Eine Beziehung, die 1NF erfüllt, erleichtert die Definition von Einschränkungen und Datenmanipulationsoperationen, die mithilfe einer Datensprachsprache implementiert werden können, die weniger komplex ist als die für nicht normalisierte Beziehungen (Tabellen) erforderliche, wie Dr. Codd in den folgenden Zeilen ausführt:

Die Übernahme eines relationalen Datenmodells, wie oben beschrieben, ermöglicht die Entwicklung einer universellen Datensprachsprache auf der Grundlage einer angewandten Prädikatenrechnung. Ein Prädikatenkalkül erster Ordnung reicht aus, wenn die Sammlung von Beziehungen in normaler Form vorliegt. Eine solche Sprache würde einen Maßstab für die Sprachkraft aller anderen vorgeschlagenen Datensprachen liefern und wäre selbst ein starker Kandidat für die Einbettung (mit entsprechender syntaktischer Modifikation) in eine Vielzahl von Hostsprachen (Programmierung, befehls- oder problemorientiert). […]

[…]

Die Universalität der Datensprachsprache liegt in ihrer Beschreibungsfähigkeit (nicht in ihrer Rechenfähigkeit).

Die Verwirrung

Aus meiner Sicht ist die Verwirrung aufgrund (a) des oben erwähnten Überschusses an Interpretationen, Erklärungen usw. über 1NF und des RM selbst und aufgrund (b) weiterer Versuche, 1NF neu zu definieren , die besagen, dass Beziehungen bestehen, entstanden bei Domänen, die Werte enthalten, die wiederum Beziehungen sind, die 1NF entsprechen, solange sie ein einzelner Wert für jedes entsprechende Tupel sind.

Meine Meinung zu Ihren anderen Punkten

Es sollte keine Beziehung zwischen Zeilen geben, außer dass sie denselben Überschriften entsprechen.

Ich bin nicht sicher, ob ich die Absicht dieser Aussage richtig verstehe, aber abgesehen von der Übereinstimmung mit denselben Überschriften muss eine Verbindung zwischen den (Tupel-) Zeilen einer Beziehung (Tabelle) bestehen, da jede von ihnen eine Behauptung über a sein sollte besonderes Vorkommen des spezifischen Entitätstyps (definiert im Hinblick auf den interessierenden Geschäftskontext), den die Beziehung (Tabelle) darstellen soll.

Es sollte auch keine Beziehung zwischen Spalten geben, aber ich glaube, dass dies das Thema höherer Normalformen ist.

Ich weiß nicht , ob ich richtig die Bedeutung dieser Aussage zu interpretieren bin entweder aber in der Tat, und in Übereinstimmung mit meiner Antwort auf den vorherigen Aspekt, es muss auch eine Beziehung zwischen den Domänen (Spalten) einer Relation (Tabelle) sein Genau deshalb handelt es sich um eine Beziehung (die wesentliche Struktur des relationalen Modells und einer konkreten RDB-Implementierung).

Zum Beispiel in Bezug auf die hypothetische Beziehung (Tabelle)

• Salary (PersonNumber, EffectiveDate, Amount)

das Tupel (Reihe)

• Salary (x, y, z)

würde die Bedeutung vermitteln

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Daher muss jedes Tupel (Zeile) der SalaryBeziehung (Tabelle) in die Struktur der oben gezeigten Behauptung passen, und der Unterschied wäre das Ersetzen der relevanten Domänen- (Spalten-) Werte, aber es muss eine Beziehung zwischen (a) bestehen. alle SalaryDomänen (Spalten) und auch zwischen (b) alle ihre entsprechenden Werte in Bezug auf jedes Tupel (Zeile); Eine solche Beziehung ist unverzichtbar.

Höhere Normalformen (2NF und 3NF) sind nützlich, um funktionale Abhängigkeiten zwischen Domänen (Spalten) einer Beziehung (Tabelle) zu beseitigen. Sie helfen dabei, unerwünschte Verbindungen zwischen Domänen (Spalten) zu vermeiden , da diese unerwünschten Verbindungen die Einführung von Aktualisierungsanomalien ermöglichen . Sowohl 2NF als auch 3NF sind hilfreich, um die Solidität der Struktur der Beziehungen (Tabellen) in einer bestimmten RDB-Implementierung zu testen.

Eine Illustration. Nehmen Sie eine Textzeichenfolge, die eine typische US-Adresse enthält:

"123 Cornhusk Rd., South Succotash, NY 12345"

Eine Anfrage zu schreiben, um alle Einwohner der Cornhusk Road oder einen bestimmten Einwohner der Stadt South Succotash oder des Bundesstaates New York zu finden, wäre eine entmutigende Aufgabe. Insbesondere, wenn Sie folgende Zeichenfolgen in den Daten haben:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Jede dieser Adressen gibt dieselbe tatsächliche Adresse an (und dies berücksichtigt nicht einmal wahrscheinliche Rechtschreibfehler wie "Succatash"), aber das Schreiben des Algorithmus zum erfolgreichen Vergleich ist etwas, für das ich meine letzten verbleibenden Jahre auf dieser Erde NICHT widmen möchte.

Geben Sie das erste normale Formular ein. Ich werde nicht näher darauf eingehen, wie es gemacht wird, sondern nur eine gängige Form betrachten, wie sie in den meisten Datenbanken zu finden ist:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Dies ist keine vollständige Normalisierung. Zum Beispiel könnten Sie Street weiter in StreetNum und StreetName unterteilen, aber dies ist weit genug für eine einfache Darstellung und es geht wirklich darum, wie der Normalisierungsprozess im wirklichen Leben durchgeführt wird. Es gibt immer noch ein kleines Problem, alle Bewohner der Cornhusk Road zu finden, aber wenn Sie Street nach dem Teilstring "Cornhusk" durchsucht haben und es irgendwo eine Stadt namens Cornhusk gibt, würde das zumindest keine Verwirrung stiften.

Das Problem bei der Definition von Date et al. Besteht darin, dass sie nicht in ein Datenelement schauen und die Bedeutung dieser Daten berücksichtigen. Nicht dass ich ihnen besonders die Schuld geben würde, es kann ziemlich schwierig sein.

Also müssen wir eine "Zeichenfolge" nehmen und daraus eine "Adresse" machen. Es ist jedoch nicht so einfach, eine umfassende Definition der Adresse zu finden, wie es aussieht. Besonders wenn Sie mit Adressen in mehr als einem Land arbeiten.

Zuerst korrigieren wir den Kontext. Ohne Kontext hat nichts Bedeutung. Unser Kontext hier ist Adresse . In diesem Kontext können wir Teile der Daten sehen, die bestimmte Bedeutungen haben, wie z. B. Straße , Stadt usw. Wir weisen jeder Bedeutung ein eigenes Feld zu.

Der schwierige Teil ist, dass Daten wie Wörter für verschiedene Personen unterschiedliche Bedeutungen haben können oder dass einige Personen Bedeutungen sehen können, wo andere dies nicht tun. Es kann ein Projekt für sich sein und erfordert viel Zusammenarbeit. Es ist jedoch ein entscheidendes Element für ein gutes Datenbankdesign.

Der Punkt der Normalisierung besteht darin, anomale Daten zu eliminieren oder zumindest zu minimieren . Beachten Sie, dass in der obigen Tabelle möglicherweise eine Stadt oder Postleitzahl eingegeben wird, die in dem ausgewählten Bundesstaat nicht vorhanden ist. Oder eine Straße, die in der ausgewählten Stadt nicht vorhanden ist. Ah, aber jetzt kommen wir in die zweite und dritte Normalform und das ist ein anderes Thema.

Stellen Sie sich 1NF als Einführung in das mathematische Konzept von Beziehungen vor und nicht als eine bestimmte Datenstruktur oder ein festes Regelwerk. Mathematische Strukturen wie Beziehungen können auf verschiedene Arten dargestellt werden - Tabellen sind nur eine der bequemsten Möglichkeiten. Bei der Verwendung von Tabellen gibt es Einschränkungen, um sicherzustellen, dass sie ihre beabsichtigten Beziehungen klar darstellen und dass Operationen an Tabellen in Bezug auf die dargestellten Beziehungen logisch einwandfrei sind.

Wenn wir sagen, dass die Reihenfolge und Duplizierung von Spalten und Zeilen unbedeutend ist, soll sichergestellt werden, dass alle wichtigen Informationen als Werte in der Tabelle aufgezeichnet werden und für unsere Abfragen zugänglich sind und nicht in die Darstellung der Tabelle codiert werden. Während nur wenige Autoren die Verwendung von Farben in Tabellen ausdrücklich verboten haben, würde das Verständnis des Zwecks der oben genannten Einschränkungen dazu führen, dass wir die Verwendung aussagekräftiger Präsentationsfarben ebenfalls ausschließen, sodass signifikante Farbwerte explizit aufgezeichnet werden müssen. Aus demselben Grund lehnen Date und andere Autoren auch versteckte Zeilenbezeichner ab.

Beim Konzept der Atomizität geht es darum, sicherzustellen, dass alle signifikanten Strukturen als Beziehungen ausgedrückt werden, damit wir Abhängigkeiten in all unseren Daten analysieren und Anomalien verhindern können und dass alle sinnvollen Strukturen für relationale Operationen einheitlich zugänglich sind. Zusammengesetzte Werte sind nicht ungültig, erfordern jedoch das Entpacken domänenspezifischer Operatoren, was die Komplexität erhöht und Redundanz einführen kann. In der Praxis sind natürlich einige einfache zusammengesetzte Typen und zugehörige Operatoren praktisch und tragen dazu bei, die Kompaktheit und Ausdruckskraft von Abfragen zu erhöhen, aber dies widerspricht nicht der Theorie.

Zeilenabhängigkeiten wie mehrwertige Abhängigkeiten verletzen nicht 1NF, sind jedoch wie Abhängigkeiten zwischen Spalten Gegenstand höherer Normalformen. Fast Wiederholung Spalten mögen phone1, phone2usw. nicht verletzen 1NF entweder, obwohl sie sind schlechtes Design.

Die Definition und Erklärung von WikiPedia zu 1NF finde ich ziemlich gut. - Joanolo

Erweiterung eines Satzes im Wikipedia-Artikel:

Als Telefonnummer betrachtet ist der Text nicht atomar

Dies kann Ihnen einen Überblick darüber geben, warum es so viel Verwirrung gibt. Wenn dies nur ein Tropfen Text ist, dann ist es atomar. Aber wenn es als Telefonnummer gesehen wird, dann ist es nicht atomar. Date und andere umgehen dieses Problem. Es hat damit zu tun, was die Daten bedeuten. Wenn Sie das Thema analysieren, müssen Sie sich mit der Bedeutung der Daten auseinandersetzen.

Ob es sinnvoll ist, es weiter aufzuschlüsseln, ist relevant für die Frage, ob die erste Normalform erfüllt wurde. Der Punkt hinter 1NF besteht darin, einen verschlüsselten Zugriff auf alle Daten bereitzustellen. Wenn das Objekt, das Sie über den Schlüsselzugriff abrufen, eine Unterstruktur hat, haben Sie keinen Schlüsselzugriff auf die Unterstruktur. - Walter Mitty

"1NF" bedeutet eine Reihe verschiedener Dinge , von denen viele gleichzeitig unsinnig und häufig sind. Siehe meine Antwort auf "Normalisierung im Datenbankverwaltungssystem" , einschließlich seiner Links. Eine davon ist meine Antwort auf "Was ist Atomizität in DBMS" . (Beide bei Stack Overflow.) - philipxy

_{Community-Wiki- Antwort erstellt aus Kommentaren zu der Frage}