Тогда получилась бы статья 18+ :) так как речь идет об алкогольной продукции. Не вдаваясь в подробности можно смело сказать, что красное вино хорошо продается в паре с белым аналогичной марки. Так же вина хорошо продаются в паре с игристыми винами (шампанским). Кстати, в магазине, как правило выкладывают красные и белые вина на разных полках. Получается это не совсем правильно. По крайне мере я бы рассмотрел вариант создания отдельной полки для «неискушенных», где выкладка была бы согласно результатам анализа корзины. Так же вариант — сделать подарочные упаковки с уже приготовленными «джентльменскими» наборами. Здесь пусть профессионалы думают и решают, самое главное, что у них теперь есть инструмент.
Думаю да, если заполучить данные конкурентов, например, и с помощью них обнаружить, что товар А, хорошо продается с товаром Б, а у нас, к примеру, товар Б вообще слабо продается, потому что лежит непонятно где (не рядом товаром А).
Вопрос правильный. Если приоткрыть завесу, то в моем случае за кодами товаров скрываются как раз коды групп аналогов или, пользуясь вашей терминологией, группы товаров заменителей.
Я не писал, что поле с хешем не нужно, пусть оно остается. Как раз при вставке новой записи оно и потребуется. Я писал, что соединять две таблицы по хешу менее оптимально, чем по полю с типом int.
В случае с таблицами dbo.format_profile и dbo.format_history я бы поступил немного иначе. В таблицу dbo.format_profile добавил бы первичный ключ типа int, а в таблице dbo.format_history сделал бы внешний ключ так же типа int. Это немного увеличило бы размер таблиц, но в случае соединения таблиц при выборке дало бы большую производительность запросов, так как операции по считыванию с диска и размещению данных в buffer cache происходили бы по данным типа int (4 байта), а не BINARY(16) (16 байт).
Да, мне тоже было бы интересно сравнить эти продукты. Одно могу предположить смело, что решение на SQL Server и PivotTable Report в Excel будет работать быстрее. Еще один большой плюс решения на SQL Server — это возможность использования других «плюшек» от Microsoft, таких как интеграция с SharePoint, интерактивные отчеты на Power View, подписки на отчеты и т.д…
Если 1С: Консолидация умеет работать с другими источниками данных кроме баз данных на основе конфигураций 1С 8, то это хорошо, а если нет, то при переводе OLTP на другую платформу придется внедрять другой инструмент BI. Моё же решение будет работать вне зависимости от платформы, на которой работает OLTP.
Предполагаю, что 1С максимально упростила процесс настройки решения BI, и, возможно, внедрение этого продукта будет по трудозатратам выгоднее, однако нужно помнить, что 1С: Консолидация стоит денег, а в моем случае решение было построено без покупки дополнительного ПО.
Один критерий, по которому 1С однозначно выигрывает — это количество специалистов на рынке, которых очевидно больше, чем девелоперов Microsoft BI.
ETL-процесс собирает данные из источников, экспортирует их в хранилище и процессит куб. В таблице фактов есть поле с датой, это означает, что все продажи одного офиса по одному покупателю и одному товару за один день агрегируются в одну строку. Эта агрегация выполняется на уровне view в источнике. Т.е. view dbo.Sales в базе данных 1С представляет данные в сгруппированном виде по офису, клиенту, товару, дню. Агрегация по дням, месяцам, годам происходит не в хранилище, а в многомерной модели данных, путем создания иерархии в измерении «Календарь». Если вы агрегируете данные прямо в хранилище, то, вероятно, вы не используете SSAS, а строите отчеты непосредственно из хранилища данных. Если я прав, то советую вам использовать колоночные индексы в таблице фактов, при условии, что у вас SQL Server 2012.
SSRS мы используем. Собственно с него и началось мое знакомство с BI от Microsoft. Подписки действительно очень понравились пользователям, привыкшим работать в 1С. У 1С аналога я не видел. Кроме того, большой плюс SSRS заключается в возможности кеширования отчетов. Это позволяет существенно разгрузить SQL-сервер.
Спасибо. Деталей действительно не много. Описал, можно сказать, вершину айсберга, иначе бы статья получилась слишком большая.
По поводу снежинки. Я решил проверить, насколько быстро будет происходить обновление данных в хранилище и многомерной БД при снежинке. Получилось 20 минут, вполне приемлемо. Решил оставить как есть, но будущее учту ваше замечание. Microsoft в книжке «Implementing a Data Warehouse with Microsoft SQL Server 2012» пишет: «If you do not use OLAP cubes and your reports query your data warehouse directly, then using a Star instead of a Snowflake schema might speed up the reports, because your reporting queries involve fewer joins». Сейчас мы не используем хранилище непосредственно для отчетов.
Я использую суррогатные ключи типа int, 1С-вские char(9) используются только для сопоставления записей в хранилище и базах данных 1С.
За подсказку по поводу обработки NULL-ов большое спасибо, буду знать.
Поскольку это мое первое BI решение, очень хотелось бы услышать комментарии знатоков, на что еще обратить внимание. В том же вопросе с NULL-ами, как правильнее поступить? Оставить NULL-ы в хранилище и обрабатывать их в кубе при процессинге? Или сразу в хранилище от них избавляться?
Дело в том, что для целей упр. учета у нас используется очень доработанная конфигурация «1С: Торговля и склад 7.7». Нужно было конечно раньше переходить на 1С 8, но тогда у бизнеса были другие задачи и требования. Сейчас проект по переходу обсуждается, и будущая архитектура решения очень вероятно будет использовать стандартный механизм РИБ, но сколько будет длиться этот переход пока не понятно, очевидно что долго и мучительно. Кроме того, я не думаю, что стандартные отчеты в 1С могут в полной мере заменить возможности анализа данных с помощью многомерных данных, так что BI решение будет развиваться параллельно, вне зависимости от архитектуры решения 1С.
2. Ассортимент приблизительно 2 тыс. наименований.
Некоторый опыт работы с 1С у меня есть, поэтому описанное не вызывает вопросов. Очевидно в будущем мы будем использовать и РИБ и СКД.
Если 1С: Консолидация умеет работать с другими источниками данных кроме баз данных на основе конфигураций 1С 8, то это хорошо, а если нет, то при переводе OLTP на другую платформу придется внедрять другой инструмент BI. Моё же решение будет работать вне зависимости от платформы, на которой работает OLTP.
Предполагаю, что 1С максимально упростила процесс настройки решения BI, и, возможно, внедрение этого продукта будет по трудозатратам выгоднее, однако нужно помнить, что 1С: Консолидация стоит денег, а в моем случае решение было построено без покупки дополнительного ПО.
Один критерий, по которому 1С однозначно выигрывает — это количество специалистов на рынке, которых очевидно больше, чем девелоперов Microsoft BI.
По поводу снежинки. Я решил проверить, насколько быстро будет происходить обновление данных в хранилище и многомерной БД при снежинке. Получилось 20 минут, вполне приемлемо. Решил оставить как есть, но будущее учту ваше замечание. Microsoft в книжке «Implementing a Data Warehouse with Microsoft SQL Server 2012» пишет: «If you do not use OLAP cubes and your reports query your data warehouse directly, then using a Star instead of a Snowflake schema might speed up the reports, because your reporting queries involve fewer joins». Сейчас мы не используем хранилище непосредственно для отчетов.
Я использую суррогатные ключи типа int, 1С-вские char(9) используются только для сопоставления записей в хранилище и базах данных 1С.
За подсказку по поводу обработки NULL-ов большое спасибо, буду знать.
Поскольку это мое первое BI решение, очень хотелось бы услышать комментарии знатоков, на что еще обратить внимание. В том же вопросе с NULL-ами, как правильнее поступить? Оставить NULL-ы в хранилище и обрабатывать их в кубе при процессинге? Или сразу в хранилище от них избавляться?