Does type projection have an opposite, or is it still projection (or just mapping)?

Question

This is based on my assumption that taking an object of type:

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

... and from it creating an object of type:

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

... is known as "projection", or "type projection" (that projection applies not only to anonymous types).

Now, let's say I send a serialized BasicFruit from a server to my client application, where some highly sophisticated farm logic is performed on those two strings, and then it gets sent back to the server, where the ORM is not aware of the BasicFruit type, only of the Fruit entity type. If I create a new Fruit object based on my BasicFruit object (ignoring the properties that do not exist in BasicFruit), so my ORM can persist it, is that the opposite of projection, because I am going from subset to superset, or is it still considered projection, or is this just mapping?

Could projection be considered a form of mapping?

Answer 1

In relational algebra projection is an operation that takes a relation and a subset of that relation's columns and returns a new relation. The new relation is the same as the input relation, except it only has the specified columns.

projection : Relation -> Column list -> Relation

There may be fewer rows in the output relation than the input relation because multiple rows project to the same row if their values for the specified columns are the same.

Now consider the inverted operation:

inverse_projection : Relation -> Column list -> Relation

Here we have an input relation whose column names are a subset of the columns in the output relation. Now we need the Column list to be columns of the output relation, which is now a superset of the columns in the input relation. This is a bit peculiar because we have to create rows for the output relation where some of the column values are left unspecified. Purely from a relational algebra perspective, this doesn't make much sense. After all, where does the data come from for these unspecified columns? Also, unlike the projection operation the input and output relations always have the same number of rows.

In SQL we're allowed to insert data by specifying only some of the table's columns. The unspecified columns take on their default values.

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

Going back to relational algebra this is like more like taking the cross product of the relation...

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

with the relation...

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

than doing a so-called inverted projection. Again, they're similar conceptually, but you're really taking a cross product with the default values.