Наконец –то это свершилось. Первая встреча группы. Организовать первую встречу, мне кажется, самое трудное. Она еще конечно не прошла, а только будет. Но чтоб это случилось, пришлось очень хорошо побегать, договорится и т.д.
И так:
Ну вот могу всех обрадовать, наконец-то, в городе Донецке появилось сообщество по SQL Server. Я являюсь лидером группы и буду стараться ее развивать.
Так что кому интересен Microsoft Sql Server, Integration Services, Analysis Services и все что связано с ними - присоединяйтесь! Минимум раз в месяц планируются доклады. На встречи буду стараться приглашать MVP по Sql Server, которые будут делиться своим опытом, а так же делать свои интересные доклады.
Регистрация и участие в семинарах бесплатное.
Регистрация в сообщество http://ineta.ru/DSSUG. Если вдруг не получается зарегистрироваться – пишите evgen.polonichko”at-commercial”gmail.com
В ходе работы над презентацией столкнулся с одной проблемой, необходимо было дать демо-доступ на SharePoint портал, но при этом пользователи, должны иметь минимальные права(то есть фактически просмотр).
Первая мысль, которая пришла, настроить доменного пользователя и все было бы красиво и легко, но …. клиентов может быть много, выдавать один и тот же логин всем, не очень красиво и хотелось бы проанализировать, что смотрят и что им интересно. Поэтому решил установить FBA(Form Based Authentication). Хорошо, если вы настраиваете ферму “с нуля”, тогда можно воспользоваться вот этими ссылочками:
Но в моем случае, все оказалось сложнее, у меня уже был сайт с настройками, с PerfomancePoint Services, с дашбордами, но он не поддерживал FBA. Поэтому пришлось его конвертировать для поддержки FBA.
Все выполняемые ниже действия вы делаете на свой страх и риск, прежде чем делать, сделайте бэкап.
И так
1 Настраиваем ASP.NET Membership Provider (как настроить смотри в выше приведенных блогах)
2 Необходимо запустить скрипт в powershell (после запуска скрипта откатится к предыдущей системе авторизации невозможно)
$App = get-spwebapplication “URL” – здесь указываем url вашего сайта, который вы хотите перевести на поддержку FBA $app.useclaimsauthentication = “True” $app.Update()
3 После обновления сайта, заходим Центр администрирования->Управления веб-приложениями. Выбираем веб-приложение, на котором крутится ваш сайт и нажимаем поставщики проверки подлинности.
4 В появившемся окне нажимаем на ссылку “по умолчанию” и переходим в "Изменение параметров проверки подлинности”
5 В "Изменение параметров проверки подлинности” разрешаем проверку подлинности на основе форм, прописываем поставщика контроля членства в ASP.NET и имя диспетчера ролей. Сохраняем
6 После чего вам необходимо настроить поставщиков через IIS( блог Donal Conlon начиная с главы Configure Membership Providers for Web App through IIS или попробуйте с помощью утилиты, которую предлагает Дмитрий Плотников). Название поставщиков должно совпадать с названиями, которые вы прописали в предыдущем шаге.
7 Дальше необходимо создать пользователя и группу. Для работы с пользователями, советую установить SharePoint 2010 FBA Pack для сайта, на котором включен FBA.
Теперь создаем группу демо-пользователей с ограниченными правами.
8 Заходим на сайт, для которого настроили FBA, под админом. Переходим меню “Действия сайта” –>” Разрешения сайта”-> “Уровни разрешения”
9 Создаем новый уровень разрешения, я назвал его у себя Демо, добавляем следующие разрешения и сохраняем
10 После этого возвращаемся в “разрешения сайта” создаем группу Демо пользователи и присваиваем ей разрешения демо
11 Все. Мы создали группу, теперь нам достаточно добавлять туда пользователей, которых мы создаем для просмотра демо. И они будут иметь ограниченный доступ. Например на моем сайте, пользователи могут смотреть дашборды и вики-страницы, не могут смотреть элементы списков, документы, загружать их и просматривать их.
В Tabular модели как-то не сложилось у Microsoft c writeback. Writeback mdx в данной модели нет (это подтверждается данной статьей на msdn). Утверждают, что запись в базу доступна через режим DirectQuery + XVelocity, но я этого не смог добиться. Но все по порядку….
Как было в первой части, для проекта берется база AdventureWorks.
Создаем проект
1. Определяем источник данных, добавляем таблицы в модель FactFinance, PlanFinace (таблицы фактов), DimOrganisation, DimDepartamentGroup,DimDate. Создаем связи.
2. Создадим показатели в таблице FactFinance - Amount агрегация Sum и Average, PlanFinance – Amount агрегация Sum.
Модель создали, вроде бы все ок. А вот теперь начинается самое интересное.
В Tabular модели есть 4 режима:
Первые два режима работают с DAX запросами и не поддерживают MDX, последних два режима как DAX, так и MDX. А теперь самое интересное - клиент, который может работать с режимами DirectQuery, это Excel 2013. Если у вас ниже офис, то тогда с такими режимами может работать PowerView или SSRS. Ну в принципе это было ожидаемо и я думаю в ближайшем будущем выйду дополнения для 2010 офиса. Также DirectQuery не поддерживают некоторые функции DAX, поэтому прежде чем писать формулы на DAX, включите directquery.
Данные режимы включаются следующим образом:
В свойствах модели DirectQueryMode поставить On, если выбудете работать с режимами DirectQuery или DirectQueryWithInMemory
В свойствах проекта выбираем QueryMode:
И делаем деплой.
Как обычно проект лежит здесь.
Так как же обратная запись – да в принципе никак. Потому что не один клиент ни в каком режиме не позволил сделать изменения в реляционном источнике. Поэтому вопрос, связанный с обратной записью, остается открытым. Я думаю вряд ли Microsoft оставит такой продукт без данной функции.
Поживем – увидим.
USE [AdventureWorksDW2012]
GO
/****** Object: Table [dbo].[PlanFinance] Script Date: 17.07.2012 13:10:23 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[PlanFinance](
[FinanceKey] [int] IDENTITY(1,1) NOT NULL,
[DateKey] [int] NOT NULL,
[OrganizationKey] [int] NOT NULL,
[DepartmentGroupKey] [int] NOT NULL,
[ScenarioKey] [int] NOT NULL,
[AccountKey] [int] NOT NULL,
[Amount] [float] NOT NULL,
[Date] [datetime] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[PlanFinance] WITH CHECK ADD CONSTRAINT [FK_PlanFinance_DimAccount] FOREIGN KEY([AccountKey])
REFERENCES [dbo].[DimAccount] ([AccountKey])
GO
ALTER TABLE [dbo].[PlanFinance] CHECK CONSTRAINT [FK_PlanFinance_DimAccount]
GO
ALTER TABLE [dbo].[PlanFinance] WITH CHECK ADD CONSTRAINT [FK_PlanFinance_DimDate] FOREIGN KEY([DateKey])
REFERENCES [dbo].[DimDate] ([DateKey])
GO
ALTER TABLE [dbo].[PlanFinance] CHECK CONSTRAINT [FK_PlanFinance_DimDate]
GO
ALTER TABLE [dbo].[PlanFinance] WITH CHECK ADD CONSTRAINT [FK_PlanFinance_DimDepartmentGroup] FOREIGN KEY([DepartmentGroupKey])
REFERENCES [dbo].[DimDepartmentGroup] ([DepartmentGroupKey])
GO
ALTER TABLE [dbo].[PlanFinance] CHECK CONSTRAINT [FK_PlanFinance_DimDepartmentGroup]
GO
ALTER TABLE [dbo].[PlanFinance] WITH CHECK ADD CONSTRAINT [FK_PlanFinance_DimOrganization] FOREIGN KEY([OrganizationKey])
REFERENCES [dbo].[DimOrganization] ([OrganizationKey])
GO
ALTER TABLE [dbo].[PlanFinance] CHECK CONSTRAINT [FK_PlanFinance_DimOrganization]
GO
ALTER TABLE [dbo].[PlanFinance] WITH CHECK ADD CONSTRAINT [FK_PlanFinance_DimScenario] FOREIGN KEY([ScenarioKey])
REFERENCES [dbo].[DimScenario] ([ScenarioKey])
GO
ALTER TABLE [dbo].[PlanFinance] CHECK CONSTRAINT [FK_PlanFinance_DimScenario]
GO
Кратко, немного теории:
SCD( slowly change dimension ) называются таблицы измерений, в которых некоторые атрибуты могут изменить свои значения по истечении некоторого периода времени, причем частота таких изменений является небольшой.
Существует три типа таких измерений:
Type 1 - относятся те измерения, в которых не поддерживается история изменений атрибута. То есть запись в таблице просто обновляется.
Type 2 - относятся те измерения, в которых поддерживается история изменений атрибута. То есть старая запись помечается как утратившая актуальность, и добавляется новая запись с тем же идентификатором, но уже с обновленными полями. Так же указывается время действия данной записи
Type 3 - относятся те измерения, в которых поддерживается история изменений атрибута, но в отличие от второго типа, в таблице добавляются новые поля, которые хранят старые значения.
Более подробней по поводу SCD-измерений можно почитать у Ralph Kimball. Информации очень много в сети по данной тематике, так что ищите.
Теперь вернемся к реализации SCD type2 с помощью ssis .
Создаем таблицу dim_Clients в MS SQL server 2012
CREATE TABLE [dbo].[dim_Clients]( [id] [int] IDENTITY(1,1) NOT NULL, --id клиента – уникальная запись, инкрементальная [ClientIDSource] [int] NOT NULL, -- id клиента в источнике [NameClients] [varchar](250) NOT NULL, –- имя клиента [TypeClients] [int] NULL, –-тип клиента [KodObl] [varchar](3) NULL, –-код области [DateRegistration] [int] NULL, –- дата регистрации [DateFrom] [datetime] NOT NULL, –- дата начала действия даты с [DateTo] [datetime] NOT NULL, –- дата окончания действия даты до [IsCurrent] [bit] NOT NULL, –- является текущей датой(0 – нет, 1 – да) CONSTRAINT [PK_dim_Clients] PRIMARY KEY CLUSTERED ( [id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO SET ANSI_PADDING OFF GO ALTER TABLE [dbo].[dim_Clients] ADD CONSTRAINT [DF_dim_Clients_DateFrom] DEFAULT ('30000101') FOR [DateFrom] GO
Теперь нам необходима дополнительная таблица, куда мы будем сливать данные из исходного источника, а потом обрабатывать и сохранять в таблицу в хранилище.
CREATE TABLE [dbo].[dim_ClientsStaging]( [id] [int] NOT NULL, [NameClients] [varchar](250) NOT NULL, [TypeClients] [int] NULL, [KodObl] [varchar](3) NULL, [DateRegistration] [int] NULL ) ON [PRIMARY] GO SET ANSI_PADDING OFF GO ALTER TABLE [dbo].[dim_ClientsStaging] ADD CONSTRAINT [DF_dim_ClientsStaging_DateRegistration] DEFAULT (datediff(day,'',getdate())) FOR [DateRegistration] GO
Создаем новый проект в SSIS 2012. Добавляем источник откуда мы получаем данные, и источник, куда мы будем заливать данные. После создаем два пакета.
В первом пакете для работы SCD2 используем конструкцию T-SQL merge.
Первым шагом очищаем предварительную таблицу, после делаем заливку данных из источника в staging таблицу, а потом с помощью скрипта T-SQL реализуем логику заполнения для SCD2. Скрипт ниже:
insert into dbo.dim_Clients
(
[ClientIDSource]
,[NameClients]
,[TypeClients]
,[KodObl]
,[DateRegistration]
,[DateFrom]
,[DateTo]
,[IsCurrent]
)
select
[ClientIDSource]
,[NameClients]
,[TypeClients]
,[KodObl]
,[DateRegistration]
,getdate()
,'30000101'
,1
from
(
merge into dim_Clients as dst
using dbo.dim_ClientsStaging as src
on
(
src.id=dst.[ClientIDSource]
)
--new records inserted
when not matched then
insert (
[ClientIDSource]
,[NameClients]
,[TypeClients]
,[KodObl]
,[DateRegistration]
,[DateFrom]
,[DateTo]
,[IsCurrent]
)
values(
src.id
,src.[NameClients]
,src.[TypeClients]
,src.[KodObl]
,src.[DateRegistration]
, getdate()
, '30000101'
,1
)
--existing
when matched
and isCurrent=1
and
(src.[NameClients]<>dst.[NameClients]
or src.[TypeClients]<>dst.[TypeClients]
or src.[KodObl]<>dst.[KodObl]
)
then update
set
dst.IsCurrent=0,
dst.DateTo=getdate()
output
src.id as clientidsource
,src.[NameClients]
,src.[TypeClients]
,src.[KodObl]
,src.[DateRegistration]
,$Action as MergeAction) as mrg
where mrg.MergeAction='update';
А теперь тестовый прогон:
1 Первый прогон –заполняются данные расставляются даты и указывается флаг текущая действующая запись isCurrent.
2 Теперь в исходниках изменим имя у записи Stefanie (это первая запись на рисунке ClientIDSource=1) и изменим код области у Dennis(это запись на рисунке ClientIDSource=2). Запускаем пакет и получаем следующие результаты.
Красным выделено на рисунке строки, которые не являются действующими, в DateTO указана дата до которой эта запись действует, а в флаге isCurrent=0, то есть эта записья уже не является текущей.
И зеленным выделены записи, которые являются действующими на текущей момент. У них указана дата действия с(DateFrom) и флаг iscurrent равен 1. То есть эти записи с новыми атрибутами начинают действовать с даты, указанной в DateFrom.
Плюсы данного метода:
1 Скорость
Минусы
1 Тяжеловатый и не всегда понятный код реализации логики SCD2 с помощью T-SQL
Второй пакет использует компонент из toolbox Slowly Change Dimension.
Всю структуру, которая указана на картинке выше, кроме OLE db source, создаст мастер Slowly Change Dimension. В мастере необходимо указать ключ - bussines key (ключ источника).
И атрибуты, которые будут изменятся
После указываем, что делать с fail записями
и наконец, указываем столбцы, которые отвечают за даты действия.
Также указываем,что делать с столбцом iscurrent
В итоге после нажатия на finish строится набор task-ов.
Плюсы данного метода
1 Понятный мастер, строит логику работы SCD2 сам.
Минус
1 Скорость. При больших объемах данных начинает жутко тормозить.
В своих проектах, я использую первый метод. Потому что у меня редко когда бывает маленький объем данных в справочниках. И если кто заинтересуется, что я изменил после работы с Slowly Change Dimension(второй пакет) ?![]()
Проект SSIS и скрипт по созданию источника данных: