Максим Y

-- Уровень источников --
Таблицы в том виде, в котором уни уже есть в БД источниках.

-- Детальный уровень (нормализованные данные, снежинка) --
Фактом у вас может быть некое событие с достаточным для ешго идентификации набором сведений - (Дата выплаты, Сумма выплаты, Ид сотрудника).
Все остальное - измерения. Пол, дата_рождения, нанят_дата - атрибуты измерения Сотрудник. Все даты действия (от, до) хранятся в таблицах измерений и определяют состояние атрибутов конкретной записи для выборки на дату совершения какого-то факта или на дату отчета.

-- Уровень OLAP кубов (денормализованная таблица, храним только ид) --
Здесь вы, на основании своего детального уровня (фактов и измерениий), собираете куб.
(ДатаГод, ДатаМесяц, СуммаВыплаты, Ид_сотрудника, Ид_отдела, Ид_должности, ... )

Это пример варианта. Могут быть варианты без детального уровня. с заливкой из источников прямо в куб. Да и еще много какие варианты.

Должно помочь избавление от конкатенации.

SELECT DISTINCT CITY, AREA, REGION FROM youtube
или

SELECT CITY,  AREA, REGION
FROM youtube
GROUP BY CITY,  AREA, REGION

Если сильно нужно получать именно конкатенированный результат, то подзапрос все-равно будет быстрее

SELECT  "CITY" || ' | '  || "AREA" || ' | ' || "REGION" FROM (
    SELECT CITY,  AREA, REGION
    FROM youtube
    GROUP BY CITY,  AREA, REGION) t

Подумайте над добавлением дополнительной сущности "рабочая группу" с атрибутами "дата начала" и "дата конца".
В общем случае, так перекрываются нестандартные ситуации, вроде
- кто-то заболел и напарник работал сам
- в группу добавили третьего
- кто-то работает на двух проектах

Но тут от конкретного бизнес-кейса зависит. Надо знать ограничения.

#team

team_id	|	start_date	|	end_date
--------------------------------------------------
	1	|	01.01.2018	|	05.01.2018

#team_worker

team_id	|	worker_id	
--------|---------------
	1	|	101			
	1	|	102

P.S. В ваших вариантах поле "ид связи", похоже, избыточное. Уникальность связи делают по ( worker_1_id, worker_2_id, start_date).