Sollte eine SQL VIEW immer in 1NF sein?

Question

Eine SQL VIEW ist eine globale logische Tabelle, die möglicherweise persistent ist. Aber es ist immer noch ein Tisch. Sollte eine VIEW daher immer an der ersten Normalform (1NF) festhalten? d. h. keine doppelten Zeilen, nur skalare Typen, keine Anordnung von oben nach unten oder von links nach rechts. Was ist mit den höheren Normalformen?

Für mich "konsumieren" meine Anwendungen die Ergebnisse gespeicherter Prozeduren, meine VIEWs werden von SQL-Abfragen "konsumiert" und diese beiden Verwendungen schließen sich gegenseitig aus (dh ich frage die Ergebnismengen gespeicherter Prozeduren nicht mit SQL und Meine Anwendungen enthalten keinen SQL-Code. Ich habe gesehen, wie andere eine VIEW verwenden, um mehrere Werte in einer Spalte in eine einzelne Zeile zu "verketten", normalerweise durch Komma getrennt. Schreiben Prädikate in einer SQL-Abfrage gegen eine solche Spalte erfordert eine kludges ähnlich wie diese:

',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%' 

So scheint es mir sinnvoll, alle Tabellen zu erwarten, die abgefragt werden können nur skalare Typen bestehen. Bin ich zu "puristisch", wenn ich das denke?

Answer 1

Es ist vollkommen sinnvoll, sicherzustellen, dass Ihre Ansichten auf mindestens 1NF normalisiert sind. Das Zulassen von Duplikaten zum Beispiel hat den Nachteil, dass die Bedeutung der Ansicht mehrdeutig gemacht wird und Informationen von Benutzern falsch identifiziert werden können. Falsche Daten könnten auftreten, wenn Tabellen basierend auf solchen Unklarheiten aktualisiert werden.

E.F.Codd stimmte jedoch nicht unbedingt überein. In seinem RM Version 2 Buch schlägt er vor, Ansichten ohne Schlüssel zuzulassen - ein großer Fehler, denke ich. Codds Ansichten erlauben eigentlich keine Duplikate, aber sie erlauben, dass jede Spalte nullfähig ist und daher keine Schlüssel hat und nicht in 1NF ist.

Ein Zeichenfolgenwert, der eine durch Kommas begrenzte Liste enthält, ist selbst keine Verletzung von 1NF. Ein String-Wert ist ein Skalar wie jeder andere Wert auch immer. Die meisten SQL DBMS erlauben keine mehrwertigen Attribute.

Answer 2

Nein - Ich erstelle Ansichten, die mit der Ausgabe übereinstimmen, die mein Programm benötigt.

Answer 3

Der springende Punkt bei relationalen Systemen ist, dass Sie Daten in normalisierten Beziehungen für Effizienz und/oder Verwaltbarkeit aufbewahren und dann die relationalen Operatoren verwenden, um sie in die benötigten Beziehungen zu konvertieren.

Eine nicht materialisierte Ansicht wird nicht gespeichert, es ist eine Abfrage.

Deshalb sollten Sie es in der Form erstellen, die am besten zu Ihren Anwendungen passt.

Weitere Informationen finden Sie unter this answer.

Answer 4

Ich glaube nicht, dass dies eine Regel ist, aber wenn es war - Keine Regel sollte immer befolgt werden.

Answer 5

eine Ansicht (es sei denn, es/indizierte Sicht materialisiert) ist nichts anderes als eine gespeicherte Abfrage Ansichten können mehrere Tabellen enthalten, können selbst an den gleichen Tisch verbindet haben etc etc

Answer 6

Nein - Normalisierungsregeln gelten die Persistenz von Daten, nicht die Präsentation von Daten. Z. B. würden alle doppelten Zeilen in einer Ansicht 1NF brechen, was offensichtlich übermäßig restriktiv ist.

Weitere Informationen finden Sie unter First normal form.

Answer 7

Laut Chris Datum sollten Ansichten vollständig normalisiert werden:

Die Wahl, welche Beziehungen Sie die Basis zu knüpfen, und die die Ansichten, willkürlich ist. Als triviales Beispiel könnten Sie Mitarbeiter haben und Sie könnten eine Basisbeziehung haben, die alle Mitarbeiter enthält, und Sie haben möglicherweise East Coast Employees und West Coast Employees als zwei Ansichten. Oder Sie haben die Mitarbeiter der Ostküste und der Westküste als zwei Basisbeziehungen und leiten die Vereinigung aller von ihnen als Sichtweise ab. Es ist völlig willkürlich.

DBMS Interview mit Chris Datum - Oktober 1994