Metabase

مطالعه بیشتر

نحوه رفتن از مدیریت ده‌ها کاربر به هزاران.

مدیریت مشتریان در متابیس

نحوه رفتن از مدیریت ده‌ها کاربر به هزاران.

این مقاله یک نمای کلی از نحوه راه‌اندازی و scale کردن تحلیل‌های self-service ارائه می‌دهد. ما در سطح بالا می‌مانیم و به راهنماهای دقیق‌تر درباره ویژگی‌های فردی لینک می‌دهیم، و تمرکز ما در اینجا بر مدیریت متابیس، به خصوص مشتریان در سازمان شما خواهد بود. برای scale کردن عملیاتی—اجرای واقعی برنامه متابیس—متابیس در مقیاس را بررسی کنید.

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

برای این منظور، توصیه می‌کنیم متابیس خود را با هدف ساده کردن مجوزها سازماندهی کنید. احتمالاً داده‌های حساس را به دلایل مختلف (پرداخت‌ها، مالیات‌ها، مسئولیت، و غیره) جمع‌آوری می‌کنید، اما آن داده برای هوش تجاری مرتبط نیست (اگرچه احتمالاً با داده‌ای که مرتبط است مخلوط شده است). ایده این است که مرزهای سخت در مکان‌های کلیدی قرار دهید تا نگران اینکه چه کسی چه چیزی را می‌بیند نباشید، سپس سیستم‌های سبک—یا حتی فقط قراردادها—را تنظیم کنید که مکان را مرتب نگه دارند با افزایش تعداد مشتریان.

1. ایجاد گروه‌ها در متابیس

متابیس مجوزها را با استفاده از گروه‌ها مدیریت می‌کند، که کارآمدتر و قابل مدیریت‌تر از تنظیم مجوزها برای هر شخص است. توصیه می‌کنیم متابیس خود را به گونه‌ای تنظیم کنید که گروه‌ها در ارائه‌دهنده هویت شما به همان گروه‌ها در متابیس map شوند. به طور کلی، گروه‌های شما باید به بخش‌های سازمان شما map شوند، و احتمالاً همچنین به تیم‌های پروژه یا مأموریت که در بخش‌ها می‌برند. به این ترتیب، وقتی شخص جدید در حسابداری شروع می‌کند، به متابیس وارد می‌شود و از قبل دسترسی به همان پایگاه‌های داده و مجموعه‌هایی که سایر مشتریان در حسابداری دارند را دارد.

مدیران گروه

در طرح‌های Pro و Enterprise، می‌توانید مدیران گروه را منصوب کنید که می‌توانند مشتریان را به گروه اضافه و حذف کنند.

2. اختصاص مجوزهای داده و مجموعه به آن گروه‌ها

اساساً دو نوع مجوز در متابیس وجود دارد: مجوزهای داده، که دسترسی به پایگاه‌های داده را تعیین می‌کنند، و مجوزهای مجموعه، که دسترسی به آیتم‌ها در متابیس مثل سؤال‌ها و داشبوردها را تعیین می‌کنند. این مجوزها در سطح جداول یا مجموعه‌ها کار می‌کنند، اما اگر نیاز به محدود کردن دسترسی به ردیف‌ها یا ستون‌ها دارید چه؟

پنهان کردن داده نامربوط یا فنی برای همه کاربران

اگر فیلدهایی (یا کل جداول) وجود دارند که خیلی مفید یا مرتبط نیستند، مدیران می‌توانند آن‌ها را در تب مدل داده پنهان کنند. توجه کنید که پرس‌وجوهای SQL تحت تأثیر این تنظیم قرار نمی‌گیرند—کاربران با دسترسی ویرایشگر SQL برای یک پایگاه داده همیشه می‌توانند به همه جداول و فیلدها در آن پایگاه داده دسترسی داشته باشند.

انتخاب Do not include فیلدها را در رابط‌های GUI پنهان می‌کند (اگرچه فیلد هنوز در پرس‌وجوهای SQL/بومی قابل دسترسی است.

تنظیم visibility یک فیلد به Do not include فیلد را از منوها و جداول در سؤال‌های ساخته شده با Query Builder حذف می‌کند. عیب تغییر visibility فیلد در سطح مدل داده این است که عمل global است، پس خیلی انعطاف‌پذیر نیست. اگر، با این حال، می‌خواهید دسترسی به ردیف‌ها یا ستون‌ها را به انتخابی به گروه‌های مختلف مشتریان بدهید، نیاز به استفاده از مجوزهای امنیت ردیف و ستون دارید.

امنیت ردیف و ستون

ردیف و ستون یک ویژگی در دسترس در طرح‌های Pro و Enterprise متابیس است که، وقتی با single sign-on (SSO) ترکیب می‌شود، به شما اجازه می‌دهد دسترسی به ردیف‌ها یا ستون‌ها را بر اساس attributeهای کاربر محدود کنید. می‌توانید این attributeها را به صورت دستی در متابیس، یا از طریق سرویس احراز هویت خود اضافه کنید. می‌توانید دسترسی سطح ردیف keyed به یک attribute کاربر تنظیم کنید، یا می‌توانید دسترسی به ستون‌ها را محدود کنید با ایجاد viewهای سفارشی از جداول که فیلدهای خاص را حذف می‌کنند. توجه کنید که سیاست‌های امنیت ردیف و ستون فقط به سؤال‌های ساخته شده با یک سازنده کوئری گرافیکی اعمال می‌شوند، که ما را به این می‌رساند:

دسترسی ویرایشگر SQL و امنیت ردیف یا ستون متقابلاً انحصاری هستند

یک چیز مهم که باید درباره مجوزها بدانید این است که گروه‌های با دسترسی SQL به یک پایگاه داده می‌توانند به همه داده در پایگاه داده دسترسی داشته باشند. حتی اگر یک فیلد در سازنده کوئری یا در مرورگر داده قابل مشاهده نباشد، مشتریان با دسترسی SQL هنوز می‌توانند جداول (و همه ردیف‌ها و ستون‌ها) را در پایگاه داده پرس‌وجو کنند. به طور خاص‌تر، آن‌ها می‌توانند هر داده‌ای را که برای حساب کاربری در پایگاه داده که از آن برای اتصال متابیس به آن پایگاه داده استفاده کردید در دسترس است پرس‌وجو کنند. که ما را به این می‌رساند:

مجوزهای SQL

متابیس فاقد مجوزهای SQL سطح جدول است: یا به یک گروه دسترسی ویرایشگر SQL به یک پایگاه داده می‌دهید، یا نمی‌دهید. اما چون می‌توانید مجوزهای ویرایشگر SQL را در سطح پایگاه داده تنظیم کنید، می‌توانید دو (یا بیشتر) اتصال به همان پایگاه داده ایجاد کنید، هر کدام با رشته‌های اتصال مختلف برای حساب‌های کاربری مختلف در آن پایگاه داده. به عنوان مثال، می‌توانید تنظیم کنید:

  • اتصال 1 با دسترسی به کل پایگاه داده
  • اتصال 2 با دسترسی فقط به جداول A، B، و C

سپس می‌توانید به بیشتر گروه‌های خود دسترسی به اتصال 2 (کم‌تر مجاز) بدهید، و به کاربران انتخابی (مثل تحلیل‌گران داده اختصاصی) دسترسی به اتصال 1 (کل پایگاه داده) بدهید. متابیس این اتصال‌ها را گویی که دو پایگاه داده جداگانه بودند رفتار می‌کند، حتی اگر فقط دو سطح دسترسی مختلف به همان پایگاه داده باشند. از دیدگاه هر شخص، با این حال، فقط یک پایگاه داده را می‌بینند (یکی که گروه آن‌ها به آن دسترسی دارد).

مجوزهای برنامه

در طرح‌های Pro و Enterprise، می‌توانید مجوزهای برنامه را به گروه‌ها اختصاص دهید تا دسترسی مشتریان به ابزارهای مدیریتی à la carte را بدهید، بدون دادن دسترسی به داده.

3. تنظیم SSO در متابیس خود

در حالی که امیدواریم متابیس همیشه جایگاه خاصی در قلب شما داشته باشد، می‌دانیم که تنها نرم‌افزاری نیست که استفاده می‌کنید. اگر سازمان شما شروع به رشد می‌کند، احتمالاً با یک ارائه‌دهنده هویت single sign-on (SSO) مثل Okta، Auth0، یا OneLogin کار می‌کنید که به مشتریان اجازه می‌دهد یک بار احراز هویت کنند و به همه برنامه‌هایی که سازمان شما استفاده می‌کند دسترسی پیدا کنند. متابیس با سرویس‌هایی که از استانداردهای SAML و JWT استفاده می‌کنند یکپارچه می‌شود، که کنترل دقیق بر دسترسی به داده را به شما می‌دهد.

گزینه‌های احراز هویت

در حال حاضر چهار گزینه پایه برای احراز هویت در متابیس وجود دارد. در نسخه open source، دارید:

در Pro و Enterprise، همچنین دارید:

SAML یک پروتکل باز برای تبادل داده بین ارائه‌دهندگان هویت و سرویس با استفاده از XML است. JWT مشابه است، اگرچه کمتر رسمی—یک token است، نه یک پروتکل. هر دو استاندارد توسط ارائه‌دهندگان هویت مثل Okta و Auth0 برای ایجاد سرویس‌های احراز هویت (اساساً یک مدیر رمز عبور global برای مشتریان در سازمان شما) استفاده می‌شوند. با Okta، به عنوان مثال، می‌توانند یک بار به ارائه‌دهنده هویت شما وارد شوند، سپس می‌توانند از همه سرویس‌هایی که به آن‌ها دسترسی دارند استفاده کنند بدون نیاز به مداوم re-enter کردن ورود و رمز عبور خود—یا ورودها و رمزهای عبور مختلف. ارائه‌دهنده هویت (در این مورد Okta) handshakeها را با هر ارائه‌دهنده سرویس handle می‌کند. برای یادگیری بیشتر، نمای کلی SAML Auth0 را بررسی کنید.

مزیت بزرگ با تنظیم SSO با SAML یا JWT این است که می‌توانید attributeهای کاربر را به متابیس پاس دهید، که به شما اجازه می‌دهد امنیت ردیف و ستون را بر اساس اینکه کاربر چه کسی است تنظیم کنید.

4. همگام‌سازی SSO و گروه‌های متابیس

حالا که گروه‌ها را ایجاد کردید، مجوزها را تنظیم کردید، و ارائه‌دهنده SSO خود را به متابیس متصل کردید، زمان همگام‌سازی گروه‌ها است. مستندات ما را برای یادگیری نحوه همگام‌سازی عضویت گروه با ارائه‌دهنده هویت خود بررسی کنید. توجه کنید که همچنین می‌توانید گروه‌ها را با استفاده از LDAP همگام‌سازی کنید (یک گزینه در دسترس برای نسخه رایگان، open source متابیس).

5. به مشتریان بگویید می‌توانند فقط با ورود یک حساب متابیس ایجاد کنند

در این نقطه، باید همه چیز را تنظیم کرده باشید. مشتریان باید بتوانند به متابیس وارد شوند و همه چیز را که نیاز دارند ببینند، و نه بیشتر.

6. استفاده از مجموعه Usage Analytics برای نظارت بر نحوه استفاده مشتریان از متابیس شما

در نهایت، در طرح‌های Pro و Enterprise، می‌توانید تحلیل‌های استفاده متابیس را کاوش کنید تا تأیید کنید مشتریان به چه چیزی نگاه می‌کنند و تأیید کنید که مجوزهای شما همانطور که انتظار دارید کار می‌کنند. می‌توانید ببینید کدام داشبوردها و سؤال‌ها مشتریان مشاهده می‌کنند، محتوای پرس‌وجوهای SQL که اجرا می‌کنند، و چه داده‌ای دانلود می‌کنند. همچنین راهی عالی برای دیدن نحوه پیشرفت rollout شما است، مثل اینکه چند کاربر جدید در طول زمان وارد می‌شوند، و چقدر همه به چیزها نگاه می‌کنند.

Usage Analytics همچنین برای بررسی عملکرد داشبوردها و سؤال‌های workhorse شما مفید است. یکی از مسائل با دموکراتیک کردن داده این است که مشتریان از همه محدوده‌های مهارت سؤال می‌پرسند، و این می‌تواند گاهی منجر به برخی پرس‌وجوهای کمتر کارآمد شود. می‌توانید از Usage Analytics برای پیدا کردن آیتم‌های معمولاً مشاهده شده که به کندی اجرا می‌شوند استفاده کنید، سپس پست‌های ما را برای نکات درباره سریع‌تر کردن داشبوردها و بهترین روش‌ها برای نوشتن پرس‌وجوهای SQL بررسی کنید.

برای یادگیری بیشتر درباره تحلیل‌های استفاده، مقاله ما درباره نحوه نگه داشتن tabs روی داده خود را بررسی کنید.

مطالعه بیشتر

[

](metabase-in-production.html)

[

](guide-to-sharing-data.html)