Введение в SQL Server Analysis Services для разработчика. Ограничения Discover.

Article
07/06/2010

Содержание предыдущей серии. Речь идет о втором типе XMLA-запросов – Discover – и его дочернем элементе Restrictions, позволяющем фильтровать выборку, оговоренную в RequestType.

Отличие Restrictions от Properties проще всего показать на следующем примере. У меня на сервере есть две базы - Adventure Works DW 2008R2 и Test. При помощи запроса

<RequestType>MDSCHEMA_CUBES</RequestType>

<CATALOG_NAME>Adventure Works DW 2008R2</CATALOG_NAME>

<CUBE_NAME>Adventure Works</CUBE_NAME>

</RestrictionList>

</Restrictions>

</Discover>

Скрипт 1

я хочу посмотреть информацию по кубику Adventure Works в БД Adventure Works DW 2008R2. Этот запрос возвращает пустоту:

Рис.1

Видите – там только XSD пришел в ответ, значимых элементов row за ним не последовало. Это происходит потому, что я не указал базу в свойствах запроса, а то, что она была указана в ограничениях, его не волнует. Свойства задают область определения запроса, а ограничения позволяют отфильтровать затем результат. Если переписать запрос в таком виде

<RequestType>MDSCHEMA_CUBES</RequestType>

<CUBE_NAME>Adventure Works</CUBE_NAME>

</RestrictionList>

</Restrictions>

<Catalog>Adventure Works DW 2008R2</Catalog>

</PropertyList>

</Properties>

</Discover>

Скрипт 2

то он работает:

Рис.2

Кстати, от комбобокса выбора базы в SSMS в данном XMLA тоже ни жарко, ни холодно.

Разнотипные ограничения связываются союзом «и», поэтому, например, такой запрос

<RequestType>MDSCHEMA_CUBES</RequestType>

<CATALOG_NAME>Test</CATALOG_NAME>

<CUBE_NAME>Adventure Works</CUBE_NAME>

</RestrictionList>

</Restrictions>

<Catalog>Adventure Works DW 2008R2</Catalog>

</PropertyList>

</Properties>

</Discover>

Скрипт 3

вернет пустоту.

Однотипные ограничения не связываются ни союзом «и», ни союзом «или». Из них тупо выбирается последнее, а на все предыдущие AS забивает, как будто их и не было.

<RequestType>MDSCHEMA_CUBES</RequestType>

<CUBE_NAME>Adventure Works</CUBE_NAME>

<CUBE_NAME>Mined Customers</CUBE_NAME>

</RestrictionList>

</Restrictions>

<Catalog>Adventure Works DW 2008R2</Catalog>

</PropertyList>

</Properties>

</Discover>

Скрипт 4

Рис.3

Также ограничения не понимают wildcardов, чтобы их можно было использовать в likeподобных условиях. Представим себе для сравнения SQL-условие WHERE, в котором каждое поле может появиться не более, чем однажды, при этом из операций возможно только =. Вырисовывается довольно скудный набор сценариев применения ограничений. Например, нас интересует, какой гуид у схемного роусета MDSCHEMA_DIMENSIONS. Чтобы не тащить лишнюю инфу из Рис.4 предыдущего поста, можно написать

<RequestType>DISCOVER_SCHEMA_ROWSETS</RequestType>

<SchemaName>MDSCHEMA_DIMENSIONS</SchemaName>

</RestrictionList>

</Restrictions>

</Discover>

Скрипт 5

Рис.4

В зависимости от RequestType некоторые ограничения являются обязательными. Их нельзя опускать, они непременно должны присутствовать в запросе. Например, если выполнить

<RequestType>DISCOVER_INSTANCES</RequestType>

</Discover>

Скрипт 6

возникнет ошибка

XML for Analysis parser: The INSTANCE_NAME restriction is required but is missing from the request.

Рис.5

Как мы видим, обязательным ограничением для схемного роусета DISCOVER_INSTANCES выступает INSTANCE_NAME. Мне непонятен смысл этого ограничения. Чтобы обнаружить все установленные на машине экземпляры AS, требуется наложить ограничение на имя экземпляра. Какой же это тогда, вообще говоря, discover? Все равно, что для MDSCHEMA_CUBES обязательным ограничением сделать CUBE_NAME. Много у нас получится надискаверить с таким ограничением? Разумнее было ожидать, что ограничением для DISCOVER_INSTANCES выступает не имя инстанса, а имя машины, а этот риквест показывает все установленные на ней инстансы. Более того, даже с этим нелогичным ограничением мне не удалось заставить этот риквест тайп работать ни в 2008 R2, ни в 2008 (на 2005-м не проверял). Предположим, на машине стоит единственный дефолтный инстанс Analysis Services. Дефолтный инстанс называется либо никак, либо MSSQLSERVER. Пишем:

<RequestType>DISCOVER_INSTANCES</RequestType>

<INSTANCE_NAME>MSSQLSERVER</INSTANCE_NAME>

</RestrictionList>

</Restrictions>

</Discover>

Скрипт 7

а в ответ – пустота. Ничего, кроме XSD. Можно перепробовать в качестве имени инстанса пустую строчку, точку, localhost, имя машины - глухо. В Books On-Line на тему Analysis Services обращаться чаще всего бестолку. Ну значит, нет у меня установленных инстансов, а XMLA-запросы выполняются космическим разумом.

Еще один вопрос – как априори, до выполнения запроса на Discover, понять, какие ограничения являются обязательными для данного риквест тайпа? Я возлагал надежды на элемент <RestrictionsMask>. Он появляется в конце каждого <row> риквест тайпа DISCOVER_SCHEMA_ROWSETS. Казалось логичным предположить, что это битовая маска всех присущих данному риквесту ограничений, в которой обязательные ограничения имеют флаг 1, например. К сожалению, официальная документация на тему RestrictionsMask в графе Description ничего не объясняет.

рис.6

На всякий случай посмотрел английскую версию - там тоже пустота, что хорошо согласуется с общим качеством BOL по Analysis Services. Кстати, спецификация XMLA 1.1 тоже не знает такого слова – RestrictionsMask. В ней есть информация о том, что бывают обязательные свойства (стр.44), а про обязательные ограничения и как их отличить от необязательных, ничего , увы, найти не удалось. Но, товарищи, как мы с вами помним, XMLA – очень дальновидный, стройный и логичный стандарт, поэтому если вы все-таки отыщете способ, как программно отличить обязательные ограничения от необязательных, не сочтите за труд поделиться. RestrictionsMask здесь оказывается не при делах, потому что она везде тупо равна 2**N – 1, где N – общее число Restrictions данного роусета.

Вы можете сказать, что в BOL на этой странице перечислены все риквест тайпы (схемные роусеты). Если кликнуть по каждому, на открывшейся странице будет раздел «Столбцы ограничений», где для каждого ограничения указано, является ли оно обязательным либо нет:

Рис.7

Я не знаю, насколько можно доверять BOL в данном вопросе. Например, только что мы с вами воочию наблюдали, что для DISCOVER_INSTANCES ограничение INSTANCE_NAME является обязательным (см. Рис.5). Теперь смотрим, что пишут BOL на эту тему (Рис.8). Если на клетке слона увидишь надпись буйвол...

Рис.8

Ладно, не переживайте. Все не так сложно, как может показаться. Все еще сложнее. Чтобы служба разработчика не казалась медом, помимо обязательных ограничений метода Discover, существуют значения ограничений по умолчанию. Например, когда делается запрос перечислить имеющиеся кубы

<RequestType>MDSCHEMA_CUBES</RequestType>

<Catalog>Adventure Works DW 2008R2</Catalog>

</PropertyList>

</Properties>

</Discover>

Скрипт 8

вы наивно полагаете, что не наложили на кубы никаких ограничений. Не тут-то было. Суслика тоже, к примеру, не видно, а он есть. В данном случае действует дефолтное ограничение <CUBE_SOURCE>1</CUBE_SOURCE>, как можно видеть из Рис.7. Сделайте

<RequestType>MDSCHEMA_CUBES</RequestType>

< CUBE_SOURCE > 2</CUBE_SOURCE>

</RestrictionList>

</Restrictions>

<Catalog>Adventure Works DW 2008R2</Catalog>

</PropertyList>

</Properties>

</Discover>

Скрипт 9

чтобы в этом убедиться.

Рис.9

В BOL говорится, что CUBE_SOURCE = 2 означает измерения куба. BOL в своем репертуаре. Строго говоря, это не измерения, а фиктивные группы мер, соответствующие измерениям уровня базы. Про них можно почитать в Мошином блоге.

Переход на следующую серию.

Алексей Шуленин

Partager via

Введение в SQL Server Analysis Services для разработчика. Ограничения Discover.

Ressources supplémentaires