An install data script is what gets run immediately after upgrade schema. We define install data schema within the app/code/Foggyline/Office/Setup/InstallData.php file with (partial) content as follows:

namespace FoggylineOfficeSetup;

use MagentoFrameworkSetupInstallDataInterface;
use MagentoFrameworkSetupModuleContextInterface;
use MagentoFrameworkSetupModuleDataSetupInterface;

class InstallData implements InstallDataInterface
{
    private $employeeSetupFactory;

    public function __construct(
        FoggylineOfficeSetupEmployeeSetupFactory $employeeSetupFactory
    )
    {
        $this->employeeSetupFactory = $employeeSetupFactory;
    }

    public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context)
    {
        $setup->startSetup();
        /* #snippet1 */
        $setup->endSetup();
    }
}

InstallData conforms to InstallDataInterface, which requires the implementation of the install method that accepts two parameters of type ModuleDataSetupInterface and ModuleContextInterface.

The install method is run when this script gets triggered. Within this method, we would add any relevant code we might want to execute.

Going further, let's replace the /* #snippet1 */ part from the preceding code with the following code:

$employeeEntity = FoggylineOfficeModelEmployee::ENTITY;

$employeeSetup = $this->employeeSetupFactory->create(['setup' => $setup]);

$employeeSetup->installEntities();

$employeeSetup->addAttribute(
    $employeeEntity, 'service_years', ['type' => 'int']
);

$employeeSetup->addAttribute(
    $employeeEntity, 'dob', ['type' => 'datetime']
);

$employeeSetup->addAttribute(
    $employeeEntity, 'salary', ['type' => 'decimal']
);

$employeeSetup->addAttribute(
    $employeeEntity, 'vat_number', ['type' => 'varchar']
);

$employeeSetup->addAttribute(
    $employeeEntity, 'note', ['type' => 'text']
);

Using the addAttribute method on the instance of FoggylineOfficeSetupEmployeeSetupFactory, we are instructing Magento to add a number of attributes (service_years, dob, salary, vat_number, note) to its entity.

We will soon get to the inners of EmployeeSetupFactory, but right now notice the call to the addAttribute method. Within this method, there is a call to the $this->attributeMapper->map($attr, $entityTypeId) method. attributeMapper conforms to MagentoEavModelEntitySetupPropertyMapperInterface, which looking at vendor/magento/module-eav/etc/di.xml has a preference for the MagentoEavModelEntitySetupPropertyMapperComposite class, which further initializes the following mapper classes:

Since we are defining our own entity types, the mapper class we are mostly interested in is MagentoEavModelEntitySetupPropertyMapper. A quick look inside of it reveals the following mapping array in the map method:

[
    'backend_model' => 'backend',
    'backend_type' => 'type',
    'backend_table' => 'table',
    'frontend_model' => 'frontend',
    'frontend_input' => 'input',
    'frontend_label' => 'label',
    'frontend_class' => 'frontend_class',
    'source_model' => 'source',
    'is_required' => 'required',
    'is_user_defined' => 'user_defined',
    'default_value' => 'default',
    'is_unique' => 'unique',
    'note' => 'note'
    'is_global' => 'global'
]

Looking at the preceding array keys and value strings gives us a clue as to what is happening. The key strings match the column names in the eav_attribute table, while the value strings match the keys of our array passed to the addAttribute method within InstallData.php.

Let's take a look at the EmployeeSetupFactory class within the app/code/Foggyline/Office/Setup/EmployeeSetup.php file, (partially) defined as follows:

namespace FoggylineOfficeSetup;
use MagentoEavSetupEavSetup;

class EmployeeSetup extends EavSetup
{
    public function getDefaultEntities()
    {
        /* #snippet1 */
    }
}

What's happening here is that we are extending from the MagentoEavSetupEavSetup class, thus effectively telling Magento we are about to create our own entity. We do so by overriding getDefaultEntities, replacing /* #snippet1 */ with content as follows:

$employeeEntity = FoggylineOfficeModelEmployee::ENTITY;
$entities = [
    $employeeEntity => [
        'entity_model' => 'FoggylineOfficeModelResourceModelEmployee',
        'table' => $employeeEntity . '_entity',
        'attributes' => [
            'department_id' => [
                'type' => 'static',
            ],
            'email' => [
                'type' => 'static',
            ],

            'first_name' => [
                'type' => 'static',
            ],
            'last_name' => [
                'type' => 'static',
            ],
        ],
    ],
];
return $entities;

The getDefaultEntities method returns an array of entities we want to register with Magento. Within our $entities array, the key $employeeEntity becomes an entry in the eav_entity_type table. Given that our $employeeEntity has a value of foggyline_office_employee, running the following SQL query should yield a result:

SELECT * FROM eav_entity_type WHERE entity_type_code = "foggyline_office_employee";

Only a handful of metadata values are required to make our new entity type functional. The entity_model value should point to our EAV model resource class, not the model class. The table value should equal the name of our EAV entity table in the database. Finally, the attributes array should list any attribute we want created on this entity. Attributes and their metadata get created in the eav_attribute table.

If we look back at all those foggyline_office_employee_entity_* attribute value tables we created, they are not the ones that actually create attributes or register a new entity type in Magento. What creates attributes and a new entity type is the array we just defined under the getDefaultEntities method. Once Magento creates the attributes and registers a new entity type, it simply routes the entity save process to proper attribute value tables depending on the type of attribute.