ایجاد دسترسی Dynamic RLS برای Multidimensional OLAP

ایجاد دسترسی Dynamic Row Level Security برای پروژه Multidimensional OLAP زمانی که نیاز دارید تعداد کاربرهای زیادی به پروژه BI شما دسترسی داشته باشند کاربرد فراوانی دارد.

در حالت های معمول با تعریف Role و ایجاد Member که از جنس لاگین ویندوزی بودند میتوانستیم به یک یا چند کاربر از طریق Active directory و Domain دسترسی RLS بدهیم. این کار ضریب خطای بالا و از طرفی زمان بر است. راه حل سریع تر و ایمن تر DRLS است.

در این مقاله مراحلی که برای این پیاده سازی گذرانده شد رو با شما به اشتراک میگذارم.

فرض بر این است که Cub بطور صحیح ایجاد شده و در حال کار کردن است.

در اینجا میخواهیم بر اساس Dimension project کاربران دیتا ها را مربوط به پروژه خود را مشاهده کنند.

حالا به دو چیز دیگر نیازمندیم :

1. به یک جدول که Account ها را برای ما مشخص کند.
2. و جدول دیگری که بگوید کدام Account به کدام پروژه دسترسی دارد.

این کار با استفاده از رابطه AccountId و ProjectId امکان پذیر است :

Resource 1 ----> Project A
Resource 1 ----> Project B
Resource 1 ----> Project C
Resource 2  ----> Project A
Resource 2  ----> Project E
Resource 3  ----> Project F

باید دقت داشت که جدول Fact / Measure با سطوح دسترسی مد نظر ایجاد و یک Dimension برای Account ها که منبع اصلی فیلتر ما هستند ایجاد نموده.

ایده ای که در اینجا وجود دارد این است که در زمان اتصال کاربر ابتدا AccountId او گرفته میشود و بعد گزارش به او نمایش داده میشود.

حالا باید رل داینامیک را ایجاد کرد.

با باز کردن Solution Explorer و کلیک راست بر روی رل یک رل جدید ایجاد کرده.

درتب data source گزینه read را انتخاب کنید

در تب Cub نیز دسترسی ها را به Read داده شود.

برای همه Dimension ها نیز دسترسی Read را تنظیم داده شود.

و مهمترین اتفاق و جادوی این تکنیک در اینجا اتفاق میافتد :

اگر به دیاگرام دقت کرده باشید ارتباط بین حساب ها با دسترسی پروژه ها و بعد از پروژه ها به ترتیب است.

حالا اگر بتوانیم حساب محدودی را معرفی کنیم آن وقت بر اساس دسترسی آن حساب به پروژه ها، فقط پروژه هایی فیلتر میشود که آن حساب به آن دسترسی دارد و بقیه جداول و ارتباطات نیز از همین روند استفاده میکنند. چرا که جدول پروژه به Fact های ما متصل است و از این مسیر این دیتاها محدود میشود.

حال Dimension Data را باز میکنیم :

حالا Attribute Hierarchy مورد نظر که ProjectName هست را انتخاب میکنیم.

حالا برروی تب Advanced رفته و در فیلد اول کوئری MDX زیر را مینویسیم:

NONEMPTY( 
        [Project].[Project Name].[Project Name].MEMBERS,
        ( [Measures].[Project ID], 
                       StrToMember(“[Users].[Resource NT Account].&[” + username() + “]”)
         )
)

برای تست این عملکرد در Visual studio میتوان خط NT Account را میتوان تغییر داد و نتیجه را بررسی کرد.

[Users].[Resource NT Account].&[ad\amirhossein]

و برای مشاهده بدون فیلتر میتوان یک رل متناسب با رل دیگری داشت که قاعدتا کوئری MDX مجزایی نیاز دارد. وارد بخش Cub شده، تب Browser را زده از Security Context گزینه Current User را انتخاب نمود.

اگر شما دسترسی ادمین داشته باشید همه دیتاها را مشاهده میکنید.

حالا دسترسی را به یک مدیر پروژه محدود میکنیم و انتظارباید داشته باشیم که دیتاهای متناسب با آن حساب فیلتر بشوند.

برای این کار کد MDX را تغییر و بجای amirhossein از حسابی به نام account استفاده میکنم.

این بار بجای current user از role استفاده کرده و رل dynamic را انتخاب کرده.

خوب این نتیجه نشان میدهد که با تغییر رخ داده در MDX متغییری که در جدول داشتیم میتواند مدیریت کند که کدام حساب چه دیتایی را نمایش دهد.

اکنون اگر این گزارش را در بستر هایی نظیر اکسل و گزارش سازها ارائه دهید فقط نیاز دارید که اطلاعات حساب کاربری برای user ها در جدول users قرار داده و هر فردی دیتای مورد نظر خود را مشاهده کند.

برگرفته از مقاله Diego Pereira