SQL Server BIDS, SSIS агрегируют и группируют по

У меня есть таблица employee с employee_id, name и working_division, где employee_id является первичным ключом. У меня есть источник Excel с этими и другими столбцами, где сотрудник ввел свои часы, и какую работу они выполнили, для какого подразделения компании это было и так далее.

Таким образом, для любого конкретного дня сотрудника у меня может быть несколько строк, показывающих его тип работы, в каком подразделении они работали, и их начисленные часы для этого подразделения.

Как мне получить это в OLE DB, в которой employee_id является первичным ключом?

Я пытаюсь использовать совокупное преобразование для группировки по employee_id, однако employee_id и working_divisions не являются однозначными. Таким образом, группировка по операциям с обоими этими столбцами попытается вставить одни и те же employee_id в таблицу employee (employee_id является первичным ключом!). Если я не включу working_division для агрегатного преобразования, я потеряю данные.

Как я могу сгруппировать свои данные по employee_id и сохранить все остальные столбцы с этой строкой?

Спасибо за помощь!


person CodeKingPlusPlus    schedule 18.06.2012    source источник
comment
Первое, что приходит мне в голову: почему бы вам не изменить свой PK в таблице назначения? Если employee_id для working_division не один к одному, то вы не сможете получить все свои данные в любом случае, когда вы группируете. Может быть, я что-то упускаю.   -  person Marcel N.    schedule 18.06.2012
comment
@marceln Мне нужно, чтобы employee_id был ПК. По сути, у меня есть очень большой неорганизованный источник данных, и я разбиваю его на 4-5 отдельных таблиц, чтобы они соответствовали моей модели, чтобы я мог понять данные с помощью некоторых алгоритмов интеллектуального анализа данных.   -  person CodeKingPlusPlus    schedule 18.06.2012
comment
Ваши исходные данные могут выглядеть как 10, Bob, Div1 и 10, Bob, Div2, и вы хотите свернуть эти данные, чтобы они были 10, Bob, ? в таблице? Иными словами, как следует агрегировать данные, чтобы они соответствовали дизайну таблицы Employee?   -  person billinkc    schedule 20.06.2012
comment
@thecoon Любые отзывы по моему вопросу / комментарию, поскольку у вас есть награда?   -  person billinkc    schedule 22.06.2012
comment
Краткий ответ заключается в том, что его нельзя агрегировать без изменений в целевой таблице (таблицах). Другие возможные ответы: суррогатный ПК в таблице сотрудников (что также устраняет необходимость в Multicast) или составной ПК в ( employee_id, working_division). Я предпочитаю первый вариант, так как составные ПК могут отрицательно сказаться на производительности вставки в большие таблицы со случайными значениями для записей ПК. Итак, я начал награду, надеясь увидеть, какой из этих вариантов (или других, которые я, возможно, не вижу) является наиболее подходящим в такой ситуации.   -  person Marcel N.    schedule 22.06.2012
comment
@CodeKingPlusPlus: Есть что сказать по этому поводу? :)   -  person Marcel N.    schedule 23.06.2012


Ответы (1)


Мне нужно, чтобы employee_id был ПК. По сути, у меня есть очень большой неорганизованный источник данных, и я разбиваю его на 4-5 отдельных таблиц, чтобы соответствовать моей модели, чтобы я мог понять данные с помощью некоторых алгоритмов интеллектуального анализа данных.

Хорошо, тогда почему бы вам не разделить employee_id и working_division на две отдельные таблицы? Вторая таблица должна содержать FK для таблицы сотрудников (так что один ко многим).

Затем в пакет SSIS можно добавить компонент Multicast сразу после Агрегируйте на employee_id, чтобы разделить источник данных на 2 целевые таблицы.

Я думаю, что без модификации вашей целевой модели вы не сможете достичь того, чего хотите. Это в основном нарушает правила RDBMS. Та группировка, о которой вы говорите, не может быть выполнена даже в простом SQL и дает правильные результаты.

Примечание. Если вы беспокоитесь об изменении целевой модели данных, то, возможно, вы можете нормализовать ее, как я упоминал ранее, а затем денормализовать ее обратно через представление. Возможно, вы даже можете создать индексированное представление, чтобы ускорить работу во время чтения (насколько я вижу, индексированное представление должно быть возможным, поскольку все, что у вас есть, — это внутреннее соединение между двумя таблицами).

person Marcel N.    schedule 18.06.2012