DMX. Обработка, очистка, удалениеи восстановление структур и моделей
После определения структур и моделей, следующим шагом является обработка, включающая заполнение структуры интеллектуального анализа данными, секционирование данных (если это было определено при создании структуры), применение в отношении полученных данных алгоритмов интеллектуального анализа (при обработке модели). Это делается с помощью инструкции INSERT INTO, формат которой приведен ниже:
INSERT INTO [MINING MODEL]|[MINING STRUCTURE] <model>|<structure> (<mapped model columns>) <source data query>
или
INSERT INTO [MINING MODEL]|[MINING STRUCTURE] <model>|<structure>.COLUMN_VALUES (<mapped model columns>) <source data query>
где
model | название модели; |
structure | название структуры; |
mapped model columns | список через запятую с названиями столбцов, в т.ч. вложенных таблиц с их столбцами; |
source data query | запрос, описывающий загружаемый набор исходных данных. |
Если в операторе указана структура интеллектуального анализа данных, обрабатывается эта структура и все связанные с ней модели. Если задана модель, инструкция обрабатывает только эту модель. В случае, когда не указан аргумент MININGMODEL или MININGSTRUCTURE, службы AnalysisServices производят поиск типа объекта на основе имени, и затем обрабатывается корректный объект. Если сервер содержит структуру и модель интеллектуального анализа данных с одинаковыми именами, возвращается ошибка.
Форма INSERT INTO<объект>.COLUMN_VALUES, позволяет производить вставку данных непосредственно в столбцы модели без ее обучения. При использовании этого метода, данные столбцов поставляются модели в сжатом и упорядоченном виде, что полезно при работе с наборами данных, содержащими иерархии или упорядоченные столбцы.
Элементы списка <mapped model columns> представимы в виде:
<column identifier> | SKIP | <table identifier> (<column identifier> | SKIP)
где
ключевое слово SKIP указывает на то, что соответствующий столбец исходного запроса (исходных данных) не будет использоваться для заполнения структуры или модели (т.е. пропускается).
Элемент <source data query> может включать следующие типы источников данных:
- OPENQUERY - инструкция запрашивает данные, являющиеся внешними для экземпляра служб AnalysisServices, при помощи существующего источника данных. Эта инструкция работает аналогично инструкции OPENROWSET, но имеет ряд преимуществ. В частности, DMX-запрос легче записать с помощью OPENQUERY. Кроме того администратор имеет больший контроль над доступом к данным на сервере;
- OPENROWSET - инструкция запрашивает данные, являющиеся внешними для экземпляра служб AnalysisServices, при помощи существующего источника данных;
- SHAPE - инструкция, позволяющая совместить данные из нескольких источников в одну иерархическую таблицу, т.е. появляется возможность заполнить структуру с вложенными таблицами.
- любой запрос к службам AnalysisServices, возвращающий набор строк
В нашем курсе мы чаще всего будем использовать первый вариант при отсутствии в структуре вложенных таблиц и третий - при их наличии. Рассмотрим эти форматы более подробно, начав с первого.
OPENQUERY(<named datasource>, <query syntax>)
где
named datasource | источник данных, существующий в базе служб AnalysisServices (например, определенный с помощью конструктора в BIDevStudio); |
query syntax | текст запроса, возвращающего набор строк (например, запроса на SQL). |
В следующем примере инструкция OPENQUERY применяется для обучения модели упрощенного алгоритма Байеса на основе данных о целевой рассылке из базы данных AdventureWorksDW (то, что это модель, а не структура SQLServer определит в результате анализа доступных моделей и структур).
INSERT INTO NBSample (CustomerKey, Gender, [Number Cars Owned], [Bike Buyer]) OPENQUERY([Adventure Works DW],'Select CustomerKey, Gender, [NumberCarsOwned], [BikeBuyer] FROM [vTargetMail]')
Другой пример [1] показывает вариант записи с явным указанием, что обрабатывается структура [People1] со столбцами [CustID], [Name] и т.д., для ее заполнения используется источник данных Chapter3Data, в апострофы заключен текст SQL-запроса, выполнение которого приведет к получению требуемого набора строк.
INSERT INTO MINING STRUCTURE [People1] ([CustID], [Name], [Gender], [Age], [CarMake],[CarModel]) OPENQUERY(Chapter3Data, 'SELECT [Key], Name, Gender, Age, CarMake, CarModel FROM People')
Инструкция SHAPE имеет более сложный по сравнению с OPENQUERY формат:
SHAPE {<master query>} APPEND ({ <child table query> } RELATE <master column> TO <child column>) AS <column table name> [ ({ <child table query> } RELATE <master column> TO <child column>) AS<column table name> ... ]
где
Инструкция SHAPE требует, чтобы результаты запросов были упорядочены по столбцам, используемым для связи между родительской и вложенной таблицами. Для этого в SQL используется инструкция ORDERBY.
Рассмотрим еще один пример [1]. В нем сначала создается структура [People3] cдвумя вложенными таблицами [Purchases] и [MovieRatings]. После чего с помощью оператора INSERT INTO MINING STRUCTURE производится заполнение и обработка структуры и ее моделей. Обратите внимание, что внешние ключи, используемые для связи таблиц (это столбец CustID в таблицах Purchases и MovieRatings), в структуру не попадают. Для этого используется ключевое слово SKIP, подставлемое вместо названия столбца (…[Purchases](SKIP, [Product], …),[MovieRatings](SKIP, [Movie], [Rating])…). Также хочется обратить внимание на наличие в запросах SELECT инструкции ORDERBY, упорядочивающей результат запроса, о чем говорилось выше.
// Создание структуры с двумя вложенными таблицами CREATE MINING STRUCTURE [People3] ( [CustID] LONG KEY, [Name] TEXT DISCRETE, [Gender] TEXT DISCRETE, [Age] LONG CONTINUOUS, [AgeDisc] LONG DISCRETIZED(EQUAL_AREAS,3), [CarMake] TEXT DISCRETE, [CarModel] TEXT DISCRETE, [Purchases] TABLE ( [Product] TEXT KEY, [Quantity] LONG CONTINUOUS, [OnSale] BOOLEAN DISCRETE ), [Movie Ratings] TABLE ( [Movie] TEXT KEY, [Rating] LONG CONTINUOUS ) ) //обработка структуры INSERT INTO MINING STRUCTURE [People3] ([CustID], [Name], [Gender], [Age], [AgeDisc], [CarMake], [CarModel] ,[Purchases](SKIP, [Product], [Quantity], [OnSale]) ,[Movie Ratings](SKIP, [Movie], [Rating]) ) SHAPE { OPENQUERY( Chapter3Data, 'SELECT [Key], Name, Gender, Age, Age, CarMake, CarModel FROM People ORDER BY [Key]') } APPEND ({ OPENQUERY( Chapter3Data, 'SELECT CustID, Product, Quantity, [On Sale] FROM Purchases ORDER BY CustID') } RELATE [Key] TO [CustID] ) AS Purchases , ({ OPENQUERY( Chapter3Data, 'SELECT CustID, Movie, Rating FROM MovieRatings ORDER BY CustID') } RELATE [Key] TO [CustID] ) AS MovieRatingsЛистинг .
Удалить данные, модель или структуру можно с помощью оператора DELETE. Его синтаксис приведен ниже:
DELETE FROM [MINING MODEL] <model>[.CONTENT] DELETE FROM [MINING STRUCTURE] <structure>[.CONTENT]|[.CASES]
где
Если не указан аргумент MININGMODEL или MININGSTRUCTURE, AnalysisServices производит поиск типа объекта на основе имени и затем обрабатывает корректный объект. Если сервер содержит структуру и модель интеллектуального анализа данных с одинаковыми именами, возвращается ошибка.
В таблице 19.1 описываются различные варианты использования данного оператора [12].
Инструкция | Результат выполнения |
---|---|
DELETE FROM MINING STRUCTURE <structure> DELETE FROM MINING STRUCTURE <structure>.CONTENT |
Выполняет функцию ProcessClear по отношению к структуре интеллектуального анализа данных. Все содержимое структуры интеллектуального анализа данных и связанных с ней моделей интеллектуального анализа данных удаляется. |
DELETE FROM MINING STRUCTURE<structure>.CASES |
Выполняет функцию ProcessClearStructureOnly по отношению к структуре интеллектуального анализа данных. Все содержимое структуры удаляется (т.е. кэш вариантов очищается), а связанные с ней модели остаются без изменений. После выполнения команды детализация моделей, связанных со структурой, становится невозможной. |
DELETE FROM MINING MODEL<model> DELETE FROM MINING MODEL<model>.CONTENT |
Выполняет функцию ProcessClear по отношению к модели интеллектуального анализа данных, но значения состояний оставляются без изменений. Значения состояний представляют собой возможные состояния столбца. Например, значениями состояний для столбца "Пол" являются "Мужской" и "Женский". |
Следующий пример удаляет все содержимое структуры People1.
DELETE FROM MINING STRUCTURE [People1]
Инструкция DROP позволяет удалить модель или структуру интеллектуального анализа данных из базы данных. Синтаксис для того и другого случая соответственно приведен ниже.
DROP MINING MODEL<model>
или
DROP MINING STRUCTURE <structure>
где
В следующем примере из базы данных удаляется структура NewMailing.
DROP MINING STRUCTURE [New Mailing]
Инструкции EXPORT и IMPORT позволяют соответственно сохранить модель или структуру интеллектуального анализа в файл резервной копии служб AnalysisServices (*.abf) и восстановить модель или структуру из файла. Синтаксис команд [12]:
EXPORT <object type><object name>[, <object name>] [<object type><object name>[, <object name] ] TO <filename> [WITH DEPENDENCIES]
и
IMPORT FROM<filename>
где
objecttype | тип экспортируемого объекта (модель или структура интеллектуального анализа данных); |
objectname | имя экспортируемого объекта; |
filename | имя и расположение файла для экспорта (аргумент типа string, берется в одинарные кавычки). |
Если инструкция указывает модель интеллектуального анализа данных, итоговый файл также содержит связанную структуру интеллектуального анализа данных. Если инструкция указывает WITH DEPENDENCIES, все объекты, необходимые для обработки объекта (например, источник данных и представление источника данных), включаются в ABF-файл. Чтобы экспортировать или импортировать объекты базы данных служб Microsoft SQLServer Службы AnalysisServices, необходимо иметь права администратора базы данных или сервера.
В следующем примере структуры интеллектуального анализа данных TargetedMailing и Forecasting, а также модель интеллектуального анализа данных Association экспортируются в определенный файл. Вследствие того, что модель Association является частью структуры интеллектуального анализа MarketBasket, в примере также экспортируется структура MarketBasket. Любые другие модели интеллектуального анализа данных, которые могут существовать как часть структуры MarketBasket, не будут экспортироваться, потому что модель Association была экспортирована при помощи инструкции MINING MODEL, а не MINING STRUCTURE.
EXPORT MINING STRUCTURE [Targeted Mailing], [Forecasting] MINING MODEL Association TO 'C:\TM_NEW.abf'
В следующем примере модель интеллектуального анализа данных Association экспортируется в определенный файл. Вследствие того, что в инструкции указывается WITH DEPENDENCIES, объекты источника данных и представления источника данных также включаются в ABF-файл.
EXPORT MINING MODEL [Association] TO 'C:\Association_NEW.abf' WITH DEPENDENCIES
В следующем примере выполняется импорт всего содержимого файла с моделью Association, структурой и дополнительными объектами на текущий сервер.
IMPORT FROM 'C:\Association_NEW.abf '
Также можно защищать экспортируемую копию паролем [1]:
EXPORT MINING STRUCTURE People2 TO 'C:\temp\People2.abf' WITH PASSWORD='People2'
Тот же пароль понадобится при импорте:
IMPORT FROM 'C:\temp\People2.abf' WITH PASSWORD='People2'