SQLServer08_DM_Nesterov

жет использовать заданный столбец в формуле регрессии; значение MODEL_EXISTENCE_ONLY указывает, что само присутствие атрибута важнее, чем конкретное его значение;

prediction флаг прогнозирования, указывающий, что данный столбец содержит прогнозируемую величину. Может принимать значение PREDICT (столбец является как входом, так и выходом) или PREDICT_ONLY (столбец является только выходом). Столбец без флага считается входом.

Если в определении модели стоит WITH DRILLTHROUGH, то пользователям разрешается проводить детализацию (т.е. просматривать не только параметры модели, но и данные вариантов в этой модели).

Определение фильтров позволяет использовать при обработке модели только варианты, соответствующие условиям фильтрации.

Ниже приводится пример создания модели интеллектуального анализа данных Naive Bayes Women в структуре интеллектуального анализа данных New Mailing. Модель использует упрощенный алгоритм Байеса и ограничивается только теми вариантами из структуры, в которых клиентами являются женщины старше 50 лет (значение столбца Gender, содержащего информацию относительно пола клиента, равно F, от англ. Female – женщина). Предсказываться будет значение атрибута Bike Buyer, т.е. купит ли эта клиентка велосипед или нет.

ALTER MINING STRUCTURE [New Mailing]

ADD MINING MODEL [Naive Bayes Women]

(

CustomerKey,

Gender,

[Number Cars Owned],

[Bike Buyer] PREDICT

)

USING Microsoft_Naive_Bayes

WITH FILTER([Gender] = 'F' AND [Age] >50)

61

Как уже отмечалось, модель можно создать и с помощью инструкции CREATE MINING MODEL. Ее формат следующий:

CREATE [SESSION] MINING MODEL <model>

(

[(<column definition list>)]

)

USING <algorithm> [(<parameter list>)] [WITH DRILLTHROUGH]

Все параметры уже разбирались выше, поэтому сложностей в понимании синтаксиса здесь быть не должно.

Кроме того, этот оператор можно использовать для создания модели, описанной с помощью основанного на XML языка разметки прогнозирующих моделей (Predictive Model Markup Language,

PMML). Тогда его формат будет следующим:

CREATE MINING MODEL <model> FROM PMML <xml string>

где XML string – описание модели, закодированное на языке PMML. Строка должна быть заключена в одиночные кавычки ('). Этот вариант описания рекомендуется только для опытных пользователей.

Пример использования первого варианта записи оператора

CREATE MINING MODEL для создания модели

MyAssociationModel приведен ниже. Модель основана на алгоритме взаимосвязей (Association Rules), и в ней используется вло-

женная таблица Products. Значения MINIMUM_PROBABILITY (ми-

нимальная вероятность) и MINIMUM_SUPPORT (минимальная поддержка) являются параметрами алгоритма Association Rules (подробнее, см. раздел посвященный данному алгоритму).

CREATE MINING MODEL MyAssociationModel

(

OrderNumber TEXT KEY,

[Products] TABLE PREDICT ([Model] TEXT KEY)

)

USING Microsoft_Association_Rules (Minimum_Probability = 0.1, MINIMUM_SUPPORT = 0.01)

62

Здесь хотелось бы обратить внимание на одну особенность, которая появляется при создании модели, использующей только ключевой столбец из вложенной таблицы. В приведенном примере флаг PREDICT установлен для вложенной таблицы Products, а не ее ключа Model. Это указывает на то, что модель прогнозирует множество строк, составляющих вложенную таблицу для варианта.

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

3.4. ОБРАБОТКА, ОЧИСТКА, УДАЛЕНИЕ И ВОССТАНОВЛЕНИЕ СТРУКТУР И МОДЕЛЕЙ

Следующим шагом после определения структур и моделей, является их обработка, включающая заполнение структуры интеллектуального анализа данными, секционирование данных (если это было определено при создании структуры), применение в отношении полученных данных алгоритмов интеллектуального анализа (при обработке модели). Это делается с помощью инструкции 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 запрос, описывающий загружаемый набор исходных данных.

63

Если в операторе указана структура интеллектуального анализа данных, то обрабатывается эта структура и все связанные с ней модели. Если задана модель, инструкция обрабатывает только эту модель. В случае, когда не указан аргумент MINING MODEL или MINING STRUCTURE, службы Analysis Services производят поиск типа объекта на основе имени, и затем обрабатывают корректный объект. Если сервер содержит структуру и модель интеллектуального анализа данных с одинаковыми именами, возвращается ошибка.

Форма INSERT INTO <объект>.COLUMN_VALUES, позволя-

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

Элементы списка <mapped model columns> представимы в

виде:

<column identifier> | SKIP | <table identifier> (<column identifier> | SKIP)

где column identifier название столбца; table identifier название вложенной таблицы;

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

Элемент <source data query> может включать следующие типы источников данных:

1) OPENQUERY инструкция запрашивает данные, являющиеся внешними для экземпляра служб Analysis Services, при помощи существующего источника данных. Эта инструкция работает аналогично инструкции OPENROWSET, но имеет ряд преимуществ. В частности, DMX-запрос легче записать с помощью OPENQUERY. Кроме того администратор имеет больший контроль над доступом к данным на сервере;

64

2)OPENROWSET инструкция запрашивает данные, являющиеся внешними для экземпляра служб Analysis Services, при помощи существующего источника данных;

3)SHAPE инструкция, позволяющая совместить данные из нескольких источников в одну иерархическую таблицу, т.е. появляется возможность заполнить структуру с вложенными таблицами;

4)любой запрос к службам Analysis Services, возвращающий набор строк.

В нашем курсе мы чаще всего будем использовать первый вариант при отсутствии в структуре вложенных таблиц и третий – при их наличии. Рассмотрим эти форматы более подробно, начав с первого.

OPENQUERY(<named datasource>, <query syntax>)

где named datasource источник данных, существующий в базе служб Analysis Services (например, определенный с помощью кон-

структора в BI Dev Studio);

query syntax текст запроса, возвращающего набор строк (например, запроса на SQL).

В следующем примере инструкция OPENQUERY применяется для обучения модели упрощенного алгоритма Байеса на основе данных о целевой рассылке из базы данных AdventureWorksDW (то, что это модель, а не структура, SQL Server определит в результате анализа доступных моделей и структур).

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-запроса, выполнение которого приведет к получению требуемого набора строк.

65

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>

...

]

где master query запрос, возвращающий родительскую таблицу (таблицу вариантов);

child table query запрос, возвращающий вложенную таблицу;

master column столбец в родительской таблице с которым связаны строки из результата запроса дочерней таблицы (часто это потенциальный ключ, на который ссылается внешний ключ из вложенной таблицы);

child column столбец в дочерней таблице для определения родительской строки из результата главного запроса (как правило – внешний ключ в таблице, используемой в качестве вложенной); column table name – имя столбца вложенной таблицы в родительской таблице.

Инструкция SHAPE требует, чтобы результаты запросов были упорядочены по столбцам, используемым для связи между родитель-

66

ской и вложенной таблицами. Для этого в SQL используется инструк-

ция ORDER BY.

Рассмотрим еще один пример [1]. В нем сначала создается структура People3 c двумя вложенными таблицами Purchases и Movie Ratings. После чего с помощью оператора INSERT INTO MINING STRUCTURE производится заполнение и обработка структуры и ее моделей. Обратите внимание, что внешние ключи, используемые для связи таблиц (это столбец CustID в таблицах Purchases и MovieRatings), в структуру не попадают. Для этого используется ключевое слово SKIP, подставляемое вместо названия столбца: (…[Purchases](SKIP, [Product], …),[Movie Ratings](SKIP, [Movie], [Rating])…). Также хочется обратить внимание на наличие в запросах SELECT инструкции ORDER BY, упорядочивающей результат запроса, о чем говорилось выше.

// Создание структуры с двумя вложенными таблицами

CREATE MINING STRUCTURE [People3]

67

//обработка структуры

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]

где model – имя модели; structure – имя структуры.

Если не указан аргумент MINING MODEL или MINING STRUCTURE, Analysis Services производит поиск типа объекта на основе

68

имени и затем обрабатывает корректный объект. Если сервер содержит структуру и модель интеллектуального анализа данных с одинаковыми именами, возвращается ошибка.

В таблице 3.2 описываются различные варианты использования данного оператора [12]. Следующий пример удаляет все содержимое структуры People1.

DELETE FROM MINING STRUCTURE [People1]

Инструкция DROP позволяет удалить модель или структуру интеллектуального анализа данных из базы данных. Синтаксис для того и другого случая, соответственно, приведен ниже.

DROP MINING MODEL <model>

или

DROP MINING STRUCTURE <structure>

где model имя модели; structure имя структуры.

В следующем примере из базы данных удаляется структура New Mailing.

DROP MINING STRUCTURE [New Mailing]

Инструкции EXPORT и IMPORT позволяют сохранить модель или структуру интеллектуального анализа в файл резервной копии служб Analysis Services (*.abf) и восстановить модель или структуру из файла. Синтаксис команд [12]:

EXPORT <object type> <object name>[, <object name>] [<object type> <object name>[, <object name] ] TO <filename> [WITH DEPENDENCIES]

и

IMPORT FROM <filename>

где object type тип экспортируемого объекта (модель или структура интеллектуального анализа данных);

object name имя экспортируемого объекта;

filename имя и расположение файла для экспорта (аргумент типа string, берется в одинарные кавычки).

69