¿La proyección de tipo tiene un opuesto, o sigue siendo una proyección (o solo un mapeo)?

Question

Esto se basa en mi suposición de que la toma de un objeto de tipo:

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; } 
} 

... y de ella se crea un objeto de tipo:

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

... que se conoce como "proyección" , o "tipo proyección" (esa proyección se aplica no solo a tipos anónimos).

Ahora, digamos que envío un serial BasicFruit desde un servidor a mi aplicación cliente, donde se realiza una lógica de granja altamente sofisticada en esas dos cadenas, y luego se envía de vuelta al servidor, donde el ORM no está al tanto del tipo BasicFruit, solo del tipo de entidad Fruit. Si creo un nuevo objeto Fruit basado en mi objeto BasicFruit (ignorando las propiedades que no existen en BasicFruit), entonces mi ORM puede persistir, es lo contrario de la proyección, porque voy de un subconjunto a un superconjunto, o ¿Todavía se considera proyección, o es solo un mapeo?

¿Se podría considerar la proyección como una forma de mapeo?

Answer 1

En algebra relacional, la proyección es una operación que toma una relación y un subconjunto de las columnas de esa relación y devuelve una nueva relación. La nueva relación es la misma que la relación de entrada, excepto que solo tiene las columnas especificadas.

projection : Relation -> Column list -> Relation 

puede haber menos filas de la relación de salida de la relación de entrada porque el proyecto varias filas a la misma fila si sus valores para las columnas especificadas son los mismos.

Consideremos ahora la operación invertida:

inverse_projection : Relation -> Column list -> Relation 

Aquí tenemos una relación de entrada cuyos nombres de columna son un subconjunto de las columnas en la relación de salida. Ahora necesitamos que Column list sean columnas de la relación de salida, que ahora es un superconjunto de las columnas en la relación de entrada. Esto es un poco peculiar porque tenemos que crear filas para la relación de salida donde algunos de los valores de columna quedan sin especificar. Puramente desde una perspectiva de álgebra relacional, esto no tiene mucho sentido. Después de todo, ¿de dónde vienen los datos para estas columnas no especificadas? Además, a diferencia de la operación de proyección, las relaciones de entrada y salida siempre tienen el mismo número de filas.

En SQL, podemos insertar datos especificando solo algunas de las columnas de la tabla. Las columnas no especificadas adquieren sus valores predeterminados.

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

Volviendo al álgebra relacional esto es como tomar más como el producto vectorial de la relación ...

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

con la relación ...

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

que hacer una la llamada proyección invertida. De nuevo, son conceptualmente similares, pero en realidad está tomando un producto cruzado con los valores predeterminados.