Hat die Typ-Projektion ein Gegenteil oder ist es immer noch Projektion (oder nur Mapping)?

Question

Dies ist auf meiner Annahme zugrunde, dass ein Objekt vom Typ unter:

public class Fruit : IBasicFruit, IFruitDetails 
{ 
    // IBasicFruit implementation 
    public string name { get; set; } 
    public string color { get; set; } 

    // IFruitDetails implementation 
    public string scientific_name { get; set; } 
    public bool often_mistaken_for_vegetable { get; set; } 
    public float average_grams { get; set; } 
    public int century_domesticated { get; set; } 
} 

... und daraus ein Objekt vom Typ erstellen:

public class BasicFruit : IBasicFruit 
{ 
    public string name { get; set; } 
    public string color { get; set; } 
} 

... wird als „Projektion“ bekannt oder "Typ Projektion" (diese Projektion gilt nicht nur für anonyme Typen).

Jetzt sagen wir, senden Sie eine serialisierte BasicFruit von einem Server an meine Client-Anwendung, wo einige hoch entwickelte Farm-Logik auf diese beiden Strings ausgeführt wird, und dann wird es zurück an den Server gesendet, wo das ORM nicht bewusst ist des BasicFruit Typs, nur des Fruit Entitätstyps. Wenn ich ein neues Objekt Fruit basierend auf meinem Objekt BasicFruit (ignorieren die Eigenschaften, die nicht in BasicFruit existieren), so dass mein ORM kann bestehen, ist das das Gegenteil der Projektion, weil ich von Teilmenge zu Supersatz, oder gehe wird es immer noch als Projektion betrachtet, oder ist dies nur ein Mapping?

Könnte die Projektion als eine Form des Mappings betrachtet werden?

Answer 1

Bei der relationalen Algebra-Projektion handelt es sich um eine Operation, die eine Relation und eine Teilmenge der Spalten dieser Relation verwendet und eine neue Relation zurückgibt. Die neue Beziehung ist dieselbe wie die Eingabebeziehung, außer dass sie nur die angegebenen Spalten enthält.

projection : Relation -> Column list -> Relation 

Es können weniger Zeilen in der Ausgabe-Beziehung als die Eingangs Beziehung, da mehrere Zeilen Projekt auf die gleiche Zeile, wenn ihre Werte für die angegebenen Spalten gleich sein.

Betrachten wir nun den umgekehrten Betrieb:

inverse_projection : Relation -> Column list -> Relation 

Hier haben wir eine Eingabe Beziehung, deren Spaltennamen sind eine Teilmenge der Spalten in der Ausgabe-Beziehung. Jetzt müssen wir Column list Spalten der Ausgangsrelation sein, die jetzt eine Obermenge der Spalten in der Eingangsrelation ist. Dies ist ein wenig merkwürdig, da wir Zeilen für die Ausgabebeziehung erstellen müssen, in der einige der Spaltenwerte nicht angegeben sind. Rein aus relationaler Algebra ist das wenig sinnvoll. Woher kommen die Daten für diese nicht näher spezifizierten Spalten? Im Gegensatz zur Projektionsoperation haben die Eingabe- und Ausgabe-Relationen immer die gleiche Anzahl von Zeilen.

In SQL dürfen Daten eingefügt werden, indem nur einige der Spalten der Tabelle angegeben werden. Die nicht angegebenen Spalten übernehmen ihre Standardwerte.

INSERT INTO fruit (name, color) VALUES 
('apple', 'red'), 
('apple', 'green'), 
('orange', 'orange'); 

zurück auf relationale Algebra gehen diese wie ist eher wie das Kreuzprodukt der Beziehung unter ...

NAME, COLOR 
apple, red 
apple, green 
orange, orange 

mit der Beziehung ...

SCIENTIFIC_NAME, OFTEN_MISTAKEN_FOR_A_VEGETABLE, AVERAGE_GRAMS, CENTURY_DOMESTICATED 
"", false, null, null 

als ein tun sogenannte invertierte Projektion. Auch hier sind sie konzeptionell ähnlich, aber Sie nehmen ein Cross-Produkt mit den Standardwerten.