نظرات مطالب
EF Code First #1
- زمانیکه از Trusted_Connection=true استفاده می‌شود (در حالت Windows authentication)، مشخصات کاربر IIS Identity (همان کاربر Application Pool سایت) بجای تنظیمات دیگر استفاده خواهد شد.
- برای حل مشکل Login failed for user ALIPC\ali ،‌دقیقا باید به «همین کاربر» در تنظیمات امنیتی SQL Server، دسترسی‌های لازم را بدهید:
  management studio -> select server -> expand Security -> right click Logins ->  select "New Login..."
در قسمت security و Logins سرور، باید یک لاگین جدید را ایجاد کنید و در اینجا دقیقا همین نام ALIPC\ali را وارد کرده و ok کنید (این کاربر را جستجو نکنید؛ به همین نحو فقط آن‌را وارد کنید). تا اینجا مشکل login failed برطرف می‌شود. اما این لاگین جدید دسترسی خاصی را ندارد. بنابراین در مرحله‌ی بعد:
Right click on db-> properties -> permission -> View Server permission
در اینجا باید به خواص بانک اطلاعاتی مراجعه کرده و در لیست permissions آن، این کاربر جدید اضافه شده را یافته و به آن، دسترسی‌های لازم مانند db owner را داد.
نظرات مطالب
پیاده سازی اسکرام با شیرپوینت
نه آنچنان. پایه کار همان است. برنامه نویسی شیرپوینت بیشتر مبتنی است بر ASP.NET Webforms و Work flow foundation و نگارش جدید آن WCF هم دارد.
و در کل شرکتی که می‌خواهد از SharePoint درست استفاده کند باید متخصص‌هایی با این توانایی‌ها داشته باشد:
- توانایی راه اندازی دومین ویندوز سرور
- توانایی راه اندازی Exchange server
- توانایی راه اندازی SQL Server
- آشنایی کامل با IIS
- تسلط کامل به برنامه نویسی ASP.NET و وب پارت نویسی.
- آشنایی با برنامه نویسی Workflow foundation

به نظر من مایکروسافت بسیاری از کتابخانه‌هایی را که به دات نت فریم ورک اضافه کرده فقط و فقط به خاطر SharePoint بوده نمونه‌اش همین Workflow foundation . من کمتر دیدم از این مورد خارج از SharePoint استفاده شود. یا اگر دقت کرده باشید ASP.NET 2.0 وب پارت هم دارد ولی باز هم ... کاربردش جای دیگری است.
یا در SQL Server 2008 یک سری از قابلیت‌های file stream ایی که اضافه شده فقط به خاطر مدیریت ساده‌تر و بهینه‌تر حجم بالای دیتابیس شیرپوینت در نگارش 2010 آن بوده که همه چیز داخل آن ذخیره می‌شود.
مطالب
آموزش MDX Query - قسمت اول

در طول این سری آموزش‌های MDX (البته هنوز نمی‌دانم چند قسمت خواهد بود) تلاش خواهم کرد تمامی موارد موجود در MDX‌ها را به طور کامل با شرح و توضیح مناسب پوشش دهم.

امیدوارم شما دوستان عزیز پس از مطالعه‌ی این مجموعه مقالات به دانش کافی در خصوص MDX Query‌ها دست پیدا کنید.

در قسمت اول این آموزش‌ها در نظر دارم در ابتدا مفاهیم اولیه OLAP و همچنین مفاهیم مورد نیاز در Multi Dimentional Data Base  ها برای شما عزیزان توضیح دهم و در قسمت‌های بعدی این مجموعه در خصوص MDX Query‌ها صحبت خواهم کرد.

انباره داده (Data Warehouse)

عملا یک یا چند پایگاه داده می‌باشد که اطلاعات تجمیع شده از دیگر پایگاه‌های داده را درخود نگه داری می‌کند. برای ارایه گزارشاتی که از پایگاه داده‌های OLTP نمی‌توانیم به راحتی بگیریم.

(OLTP (Online transaction processing

سیستم پردازش تراکنش بر‌خط می‌باشند . که عملا همان سیستم هایی می‌باشند که در طول روز دارای تغییرات بسیار زیادی می‌باشند (مانند سیستم‌های حسابداری، انبار داری و ... که در طول روز دایما دارای تغییرات در سطح داده می‌باشند.)

(OLAP (OnLine Analysis Processing 

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

تفاوت انبار داده (Data Warehouse) و پایگاه داده(Data Base)

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

موارد تفاوت انبار داده (Data Warehouse) و پایگاه داده(Data Base)

• از لحاظ مدل‌های داده: پایگاه‌های داده برای مدل  OLTP بهینه سازی شده‌است. که بر اساس مدل داده رابطه‌ای امکان پردازش تعداد زیادی تراکنش همروند، که اغلب حاوی رکورد‌های اندکی هستند را دارد. اما در انبارهای داده که برای پردازش تحلیلی بر خط، طراحی شده‌اند امکان پردازش تعداد کمی کوئری پیچیده بر روی تعداد بسیار زیادی رکورد داده فراهم می‌شود. سرورهای OLAP می‌توانند از دو نوع رابطه‌ای  (ROLAP)  یا چند‌بعدی باشند (MOLAP).
• از لحاظ کاربران: کاربران پایگاه‌داده کارمندان دفتری و مسؤولان هستند در حالی‌که کاربران انبار‌داده مدیران و تصمیم‌گیرنده‌ها هستند.
• از لحاظ عملیات قابل اجرا بر روی آن‌ها: عملیات انجام شده برروی پایگاه‌های داده عمدتا عملیات (Select/Insert/Update/Delete) می‌باشد ، در حالی که عملیات روی انبار داده عمدتا Select  ها می‌باشند.
• از لحاظ مقدار داده‌ها: مقدار داده‌های یک پایگاه‌داده در حدود چند مگابایت تا چند گیگابایت است در حالی که این مقدار در انبار داده در حدود چند گیگابایت تا چند ترابایت است.
• از لحاظ زمان پرس و جو : به طور کلی سرعت پرس و جو  ها روی انباره‌ی داده بسیار بالاتر از کوئری مشابه آن روی پایگاه داده می‌باشد.
مراحل ساخت یک انباره‌ی داده (Data WareHouse) به شرح زیر می‌باشد 



• پاکسازی داده (Data Cleansing)

پاکسازی داده‌ها عبارت است از شناسایی و حذف خطاها و ناسازگاریهای داده ای به منظور دستیابی به داده‌ها‌یی با کیفیت بالاتر.

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

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

در این بخش عملیات مختلفی برای پاکسازی داده‌ها  قابل انجام است:

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

یکپارچه سازی داده‌ها از سه فاز کلی تشکیل شده است:
• شناسایی فیلدهای یکسان: فیلدهای یکسان که در جدول‌ها ی مختلف دارای نامهای مختلف میباشند. 

• شناسایی افزونگی‌ها ی موجود در داده‌ها ی ورودی:  داده‌های ورودی گاهی دارای افزونگی است. مثلا بخشی از رکورد در جداول مختلف وجود دارد.

• مشخص کردن برخورد‌های داده ای: مثالی از  برخوردهای داده ای یکسان نبودن واحدهای نمایش داده ای است. مثلا فیلد وزن در یک جدول بر حسب کیلوگرم و در جدولی دیگر بر حسب گرم ذخیره شده است.


• تبدیل داده‌ها(Data Transformation)
در این فاز، داده‌های ورودی طی مراحل زیر به شکلی که مناسب عمل داده کاوی باشند، در می‌آیند:
• از بین بردن نویز داده¬ها(Smoothing)
• تجمیع داده¬ها(Aggregation)
• کلی¬سازی(Generalization)
• نرمال¬سازی(Normalization)
• افزودن فیلدهای جدید
در ادامه به شرح  هر یک می‌پردازیم:
1. از بین بردن نویزهای داده ای(Smoothing): منظور از  داده‌های نویزی، داده هایی هستند که در خارج از بازه مورد نظر قرار می‌گیرند. مثلا اگر بازه حقوقی کارمندان بین یک صد هزار تومان و یک میلیون تومان باشد، داده‌های خارج از این بازه به عنوان داده‌های نویزی شناخته شده و در این مرحله اصلاح می‌گردند. برای اصلاح داده‌های نویزی از روشهای زیر استفاده می‌شود:
• استفاده از مقادیر مجاور برای تعیین یک مقدار مناسب برای فیلدهای دارای نویز
• دسته بندی داده‌های موجود و مقداردهی فیلد دارای داده نویزی با استفاده از دسته نزدیکتر
• ترکیب روشهای فوق با ملاحظات انسانی، در این روش، اصلاح مقادیر نویزی با استفاده از یکی از روشهای فوق انجام می‌گیرد اما افرادی برای بررسی و اصلاح نیز وجود دارند
2. تجمیع داده ها(Aggregation): تجمیع داده‌ها به معنی بدست آوردن اطلاعات جدید از ترکیب داده‌های موجود می‌باشد. به عنوان مثال بدست فروش ماهانه از حساب فروش‌های روزانه.
3. کلی سازی(Generalization): کلی سازی به معنی دسته بندی داده‌های موجود براساس ماهیت و نوع آنها است. به عنوان مثال می‌توان اطلاع رده‌های سنی خاص (جوان، بزرگسال، سالخورده) را از فیلد سن استخراج کرد. 
4. نرمال سازی(Normalization): منظور از نرمال سازی، تغییر مقیاس داده‌ها است. به عنوان مثالی از نرمال سازی، می‌توان به تغییر بازه یک فیلد از مقادیر موجود به بازه 0 تا 1 اشاره کرد.

5. افزودن فیلدهای جدید: گاهی اوقات برای سهولت عمل داده کاوی می‌توان فیلدهایی به مجموعه فیلدهای موجود اضافه کرد. مثلا می‌توان فیلد میانگین حقوق کارمندان یک شعبه را به مجموعه فیلدهای موجود اضافه نمود.

• کاهش داده‌ها(Reduction)

در این مرحله، عملیات کاهش داده‌ها انجام می‌گیرد که شامل تکنیکهایی برای نمایش کمینه اطلاعات موجود است

. این فاز از سه بخش  تشکیل می‌شود:

• کاهش دامنه و بعد: فیلدهای نامربوط، نامناسب و تکراری حذف می‌شوند. برای تشخیص فیلدهای اضافی، روشهای آماری و تجربی وجود دارند ؛ یعنی  با اعمال الگوریتمهای آماری و یا تجربی بر روی داده‌های موجود در یک بازه زمانی مشخص، به این نتیجه می‌رسیم که فیلد یا فیلدهای خاصی کاربردی در انباره داده ای و داده کاوی نداشته و آنها را حذف می‌کنیم. 

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

مدل داده‌ای رابطه‌ای (Relational) وچند بعدی (Multidimensional)  :

1. مدل داده رابطه‌ای (Relational data modeling)  بر اساس دو مفهوم اساسی موجودیت (entity)  و رابطه (relation) بنا نهاده شده است. از این رو آن را با نام مدل ER نیز می‌شناسند.

• موجودیت (entity) : نمایانگر همه چیزهایی که در پایگاه داده وجود خارجی دارند یا به تصور در می‌آیند. پدیده‌ها دارای مشخصاتی هستندکه به آن‌ها صفت (attribute) گفته می‌شود.

• رابطه (relation) : پدیده‌ها را به هم می‌پیوندد و چگونگی در ارتباط قرار گرفتن آن‌ها با یکدیگر را مشخص می‌کند.

2. مدل داده چند‌بعدی ( Multidimensional modeling ) یا MD بر پایه دو ساختار جدولی اصلی بنا نهاده شده است: 



• جدول حقایق (Fact Table)

• جداول ابعاد (Dimension Table)


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

جدول حقایق : قلب حجم داده‌ای ما را تشکیل می‌دهد و شامل دو سری فیلد است : کلیدهای خارجی به ابعاد و شاخص‌ها (Measure). 

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

بعد (Dimension) : هر موجودیت در این مدل می‌تواند با یک بعد تعریف شود. ولی بعدها با موجودیت‌های مدل ER متفاوتند زیرا آن‌ها سازمان شاخص‌ها را تعیین می‌کنند. علاوه بر این دارای یک ساختار سلسله مراتبی هستند و به طور کلی برای حمایت از سیستم‌های تصمیم گیری سازمان‌دهی شده‌اند.

اجزای بعدها member نام دارند و تقریباٌ همه بعدها، memberهای خود را در یک یا چند سطح سلسله مراتبی (hierarchies) سازمان‌دهی می‌نمایند، که این سلسله مراتب نمایانگر مسیر تجمیع (integration) و ارتباط بین سطوح پایین‌تر (مثل روز) و سطوح بالاتر (مثل ماه و سال) است. وقتی یک دسته از memberهای خاص با هم مفهوم جدیدی را ایجاد می‌‌کنند، به آنها یک سطح (Level) می‌گوییم. ( مثلاٌ هر سی روز را ماه می‌‌گوییم. در این حالت ماه یک سطح است. ) 

حجم‌های داده‌ای (Data Cube)

حجم‌های داده‌ای یا Cube از ارتباط تعدادی بعد با تعدادی شاخص تعریف می‌‌شود. ترکیب memberهای هر بعد از حجم داده‌ای فضای منطقی را تعریف می‌کند که در آن مقادیر شاخص‌ها  ظاهر می‌‌شوند. هر بخش مجزا که شامل یکی از memberهای بعد در حجم داده‌ای است ، سلول (cell) نامیده‌می‌شود. سلول‌ها شاخص‌های مربوط به تجمیع‌های مختلف را در خود نگهداری می‌نمایند. در واقع مقادیر مربوط به حقایق (Fact) که در جدول حقایق (Fact) تعریف می‌شوند در حجم داده‌ای (Data Cube) در سلول‌ها (Cell) نمایان می‌گردند.

     

شماهای داده‌ای (Data Schema)  : سه نوع Schema در طراحی Data Warehouse وجود دارد 

1. Stare
2. Snowflake
3. Galaxy
1. شمای ستاره‌ای (Star Schema) : متداولترین شما، همین شمای‌ستاره‌ای است. که در آن انبار‌داده با استفاده از اجزای زیر تعریف می‌شود:
• یک جدول مرکزی بزرگ به نام جدول حقایق که شامل حجم زیادی از داده‌های بدون تکرار است.

• مجموعه‌ای از جدول‌های کمکی کوچک‌تر به نام‏ جدول بعد ، که به ازای هر بعد یکی از این جداول موجود خواهد بود.

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

مشکل این مدل احتمال پیشامد افزونگی در آن است.

2. شمای دانه‌برفی ( Snowflake Schema ) : در واقع شمای دانه‌برفی، نوعی از شمای ستاره‌ای است که در آن بعضی از ‏ جداول بعد نرمال شده‌اند. و به همین خاطر دارای تقسیمات بیشتری به شکل جداول اضافی می‌باشد که از ‏ جداول بعد‏ جدا شده‌اند. 

تفاوت این دو شما در این است که جداول شمای دانه برف نرمال هستند و افزونگی در آن‌ها  کاهش یافته است. که این برای کار کردن با داده‌ها و از لحاظ فضای ذخیره‌سازی مفید است. ولی در عوض کارایی را پایین می‌آورد، زیرا در محاسبه کوئری‌ها به joinهای بیشتری نیاز داریم. 

3. شمای کهکشانی (galaxy schema) : در کاربرد‌های پیچیده برای به اشتراک گذاشتن ابعاد نیاز به جداول حقایق چندگانه احساس می‌شود که یک یا چند ‏ جدول بعد‏ را در بین خود به اشتراک می‌گذارند. این نوع شما به صورت مجموعه‌ای از شماهای ستاره‌ای است و به همین دلیل شمای کهکشان یا شمای منظومه‌ای نامیده‌می‌شود. این شما به ما این امکان را می‌دهد که جداول بعد بین جداول حقایق مختلف به اشتراک گذاشته شوند.

عملیات بر روی حجم‌های داده‌ای :

• Roll Up  (یا Drill-up) : با بالا رفتن در ساختار سلسله مراتبی مفهومی یک حجم داده‌ای، یا با کاهش دادن بعد، یک مجموعه با جزئیات کمتر (خلاصه شده) ایجاد می‌نماید. بالا رفتن در ساختار سلسله مراتبی به معنای حذف قسمتی از جزئیات است. برای مثال اگر قبلاٌ بعد مکان بر حسب شهر بوده آن را با بالا رفتن در ساختار سلسله مراتبی بر حسب کشور درمی‌آوریم. ولی وقتی با کاهش دادن بعد سروکار داریم منظور حذف یکی از ابعاد و جایگزین کردن مقادیر کل است. در واقع همان عمل تجمیع (aggregation) است. 
• Drill Down : بر عکس عملRoll-up است و از موقعیتی با جزئیات داده‌ای کم به جزئیات زیاد می‌رود. این کار با پایین آمدن در ساختار سلسله مراتبی( به سمت جزئیات بیشتر) یا با ایجاد ابعاد اضافی انجام می‌گیرد.

نمونه‌ای از عملیات Drill Down و Roll Up

• Slice : با انتخاب و اعمال شرط بر روی یکی از ابعاد یک subcube به شکل یک برش دو بعدی ایجاد می‌کند. در واقع همان عمل انتخاب (select) است.

• Dice : با انتخاب قسمتی از ساختار سلسله مراتبی بر روی دو یا چند بعد یک subcube ایجاد می‌نماید.

نمونه‌ای از عملیات Dice و Slice

• Pivot (یا Rotate) : این عملیات بردارهای بعد را در ظاهر می‌چرخاند.

نمونه‌ای از عملیات pivot

• Drill-across : نتیجه اجرای کوئری‌هایی که نتیجه اجرای آنها حجم‌های داده‌ایهای مرکب با بیش از یک fact-table است.

• Ranking : سلول‌هایی را باز می‌گرداند که در بالا یا پایین شرط خاصی واقع هستند. مثلاٌ ده محصولی که بهترین فروش را داشته‌اند.

سرورهای OLAP :

در تکنولوژیOALP داده‌ها به دو صورت چند‌بعدی (Multidimensional OLAP) (MOLAP) و رابطه‌ای (Relational OLAP) (ROLAP) ذخیره می‌شوند. OLAP پیوندی(HOLAP) تکنولوژیی است که دو نوع قبل را با هم ترکیب می‌کند.

MOLAP : روشی است که معمولاٌ برای تحلیل‌های OLAP در تجارت مورد استفاده قرار می‌گیرد. در MOLAP، داده‌ها با ساختار یک حجم داده‌ای ( Data Cube ) چند بعدی ذخیره می‌شوند. ذخیره‌سازی در پایگاه‌داده‌های رابطه‌ای انجام نمی‌گیرد، بلکه با یک فرمت خاص انجام می‌شود. اغلب محصولات موفق MOLAP از یک روش چند‌بعدی استفاده می‌نمایند که در آن یک سری حجم‌های داده‌ای کوچک، انبوه و از پیش محاسبه‌شده، یک حجم داده‌ای بزرگ (hypercube  ) را می‌سازند. 

علاوه بر‌این MOLAP به شما امکان می‌دهد داده‌های دیدهای (View) تحلیل‌گران را دسته بندی کنید، که این در حذف اشتباهات و برخورد با ترجمه‌های پرغلط کمک بزرگی است.

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

از آنجا که یک کپی از داده‌های منبع در کامپیوتر Analysis server ذخیره‌می‌شود، کوئری‌‌ها می‌توانند بدون مراجعه به منابع مجدداً محاسبه شوند. کامپیوتر Analysis server ممکن است کامپیوترسرور که تقسیم بندی‌ها در آن انجام شده یا کامپیوتر دیگری باشد. این امر بستگی به این دارد که تقسیم‌بندی‌ها در کجا تعریف شده‌اند. حتی اگر پاسخ کوئری‌ها از روی تقسیمات تجمیع (integration) شده قابل دستیابی نباشند، MOLAP سریع‌ترین پاسخ را فراهم می‌کند. سرعت انجام این کار به طراحی و درصد تجمیع تقسیم‌بندی‌ها بستگی دارد. 

مزایا : کارایی عالی-  حجم‌های داده‌ای MOLAP برای بازیابی سریع داده‌ها ساخته شده‌اند و در فعالیت‌های slice و dice به صورت بهینه پاسخ می‌دهند. ترکیب سادگی و سرعت مزیت اصلی MOLAP است.

در ضمنMOLAP  قابلیت محاسبه محاسبات پیچیده را فراهم می‌کند. همه محاسبات از پیش وقتی که حجم‌های داده‌ای ساخته می‌‌شود، ایجاد می‌شوند. بنابراین نه تنها محاسبات پیچیده انجام شدنی هستند بلکه بسیار سریع هم پاسخ می‌دهند.

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

ROLAP : محدودیت MOLAP در حجم داده‌های قابل پرس‌و‌جو و نیاز به روشی که از داده‌های ذخیره‌شده به روش رابطه‌ای حمایت کند، موجب پیشرفت ROLAP شد.

مبنای این روش کارکردن با داده‌هایی که در پایگاه‌داده‌های رابطه‌ای ذخیره‌شده‌اند، برای انجام اعمال slicing و dicing معمولی است. با استفاده از این مدل ذخیره‌سازی می‌توان داده‌ها را بدون ایجاد واقعی تجمیع در پایگاه‌داده‌های رابطه‌ای به هم مربوط کرد.

مزایا : با این روش می‌توان به حجم زیادی از داده‌ها را رسیدگی کرد. محدودیت حجم داده در تکنولوژی ROLAP مربوط به محدودیت حجم داده‌های قابل ذخیره‌سازی در پایگاه‌داده‌های رابطه‌ای است. به بیان دیگر، خود ROLAP هیچ محدودیتی بر روی حجم داده‌ها اعمال نمی‌کند.

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

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

تفاوت ROALP و MOLAP : تفاوت اصلی این دو در معماری آن‌ها است. محصولات MOLAP داده‌های مورد نیاز را در یک حافظه نهان (cache) مخصوص می‌گذارد. ولی ROLAP تحلیل‌های خود را بدون استفاده از یک حافظه میانی انجام می‌دهد، بدون آن که از یک مرحله میانی برای گذاشتن داده‌ها در یک سرور خاص استفاده کند. 

با توجه به کند بودن ROLAP در مقایسه باMOLAP ، باید توجه داشت که کاربرد این روش بیشتر در پایگاه داده‌های بسیار بزرگی است که  گاه‌گاهی پرس و جویی بر روی آن‌ها شکل می‌گیرد، مثل داده‌های تاریخی و کمتر جدید سال‌‌های گذشته.

نکته: اگر از Analysis Services که به وسیله Microsoft OLE DB Provider مهیا شده استفاده می‌کنید، تجمیع‌ها نمی‌توانند برای تقسیم‌بندی از روش ROLAP استفاده نمایند.

HOLAP : با توجه به نیاز رو به رشدی که برای کارکردن با داده‌های بلادرنگ (real time) در بخش‌های مختلف در صنعت و تجارت احساس می‌شود، مدیران تجاری انتظار دارند بتوانند با دامنه وسیعی از اطلاعات که فوراً و بدون حتی لحظه‌ای تأخیر در دسترس باشند، کار کنند. در حال حاضر شبکه اینترنت و سایر کاربرد‌ها یی که به داده‌هایی از منابع مختلف مراجعه دارند و نیاز به فعالیت با یک سیستم بلادرنگ هم دارند، همگی از سیستم HOLAP بهره می‌گیرند.

named set :

Named Set مجموعه‌ای از memberهای بعد یا مجموعه‌ای از عبارات است که برای استفاده مجدد ایجاد می‌شود.

Calculated member 

Calculated Memberها memberهایی هستند که بر اساس داده‌ها نیستند بلکه بر اساس عبارات ارزیابی MDX هستند. آنها دقیقاَ به سبک سایر memberهای معمولی هستند. MDX یک مجموعه قوی از عملیاتی را تامین میکند که میتوانند برای ساختCalculated Memberها مورد استفاده قرار گیرند به طوری که به شما امکان داشتن انعطاف زیاد در کار کردن با داده‌های چند بعدی را بدهد. 

امیدوارم در این قسمت با مفاهیم نخستین OLAP آشنا شده باشید.

تلاش خواهم کرد در قسمت بعدی در خصوص نصب SQL Server Analysis Services و نصب پایگاه داده‌ی Adventure Work DW 2008 شرح کاملی را ارایه کنم.

 

مطالب
دقت نوع داده‌ی decimal در SQL Server و EF Core
از نوع داده‌ا‌ی decimal در SQL Server، بیشتر برای انجام کارهای تجاری و ذخیره‌ی قیمت‌ها و مبالغ استفاده می‌شود؛ جائیکه اعداد و ارقام خیلی سریع بزرگ می‌شوند و گاهی از اوقات ممکن است به همراه اعشار هم باشد. اما ... کار با آن‌ها در SQL Server نیازمند نکات ویژه‌ای است که اگر ندید گرفته شوند، محاسبات نادرستی را سبب خواهند شد!


مفهوم تعریف نوع decimal پیش‌فرض در SQL Server

فرض کنید از EF پیش از EF Core استفاده می‌کنید که به صورت پیش‌فرض، نوع System.Decimal را در مدل‌های شما به همان decimal در SQL Server نگاشت می‌کند. فکر می‌کنید در این حالت خروجی کوئری‌های زیر چه چیزی خواهد بود؟
select '0.4400' as Expected , cast(0.4400 as decimal) as Actual
select '1.3200' as Expected, cast(1.3200 as decimal) as Actual
select '1.7600' as Expected, cast(1.7600 as decimal) as Actual
select '65.0000' as Expected, cast(65.0000 as decimal) as Actual
select '99.50' as Expected, cast(99.50 as decimal) as Actual

این خروجی را در تصویر ذیل مشاهده می‌کنید. در اینجا خصوصا به مورد صفر دقت کنید:


 علت اینجا است که از دیدگاه SQL Server، نوع decimal پیش‌فرض، دقیقا به معنای decimal(18,0) است که به آرگومان اول آن، precision و به آرگومان دوم آن، scale می‌گویند. یعنی حداکثر چه تعداد رقم دسیمال، پیش از ممیز و چه تعداد عدد دسیمال، پس از ممیز قرار است در این نوع داده ذخیره شوند.
بنابراین باتوجه به اینکه در حالت پیش‌فرض، مقدار scale و یا همان تعداد ارقام مجاز پس از ممیز، صفر است، عدد ارائه شده، به نزدیک‌ترین عدد صحیح ممکن، گرد خواهد شد.

به همین جهت برای رفع این مشکل، باید دقیقا مشخص کرد که scale نوع داده‌ای decimal مدنظر چیست. برای مثال می‌توان از decimal(10,4) استفاده کرد که در اینجا، نتایج صحیحی را ارائه می‌دهد:


همچنین به عنوان تمرین، مثال زیر را حل کنید!
 select iif(cast(0.1 + 0.2 as decimal) = 0, 'true', 'false')

بنابراین باید به‌خاطر داشت، اگر از EF 6x (پیش از EF Core) استفاده می‌شود، حتما نیاز است مقادیر precision و scale را دقیقا مشخص کنیم؛ وگرنه حالت پیش‌فرض آن decimal(18,0) است:
modelBuilder.Properties<decimal>().Configure(x => x.HasPrecision(18, 6));


رفتار EF Core با نوع داده‌ای decimal

رفتار EF Core با نوع داده‌ای decimal بهبود یافته و حالت پیش‌فرض آن، بدون هیچگونه تنظیمی، نگاشت به decimal(18,2) است. به علاوه اگر این پیش‌فرض را هم تغییر ندهیم، در حین اعمال Migration، پیام اخطاری را نمایش می‌دهد:
No store type was specified for the decimal property 'Price' on entity type 'Product'.
This will cause values to be silently truncated if they do not fit in the default precision and scale.
Explicitly specify the SQL server column type that can accommodate all the values in 'OnModelCreating'
using 'HasColumnType', specify precision and scale using 'HasPrecision',
or configure a value converter using 'HasConversion'.
اگر می‌خواهید دیگر این اخطار نمایش داده نشود، می‌توان از EF Core 6x به بعد، به صورت زیر و سراسری، تنظیم زیر را اعمال کرد:
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Properties<decimal>().HavePrecision(18, 6);
}
و یا روش دیگر تنظیم آن، استفاده از ویژگی جدید [Precision(18, 2)] است که می‌توان آن‌ها را بر روی خواص decimal قرار داد. اگر از نگارش‌های پیش‌از EF Core 6x استفاده می‌کنید، می‌توان از ویژگی [Column(TypeName = "decimal(5, 2)")] نیز استفاده کرد.




دو مطلب مرتبط
- از نوع‌های داده‌ا‌ی float و یا double در مدل‌های EF خود استفاده نکنید.
- همیشه مراقب بزرگ شدن اعداد و مبالغ و جمع نهایی آن‌ها باشید!
مطالب
کار با بانک‌های اطلاعاتی فاکس‌پرو و OleDB در دات نت 7
فرض کنید قصد خواندن اطلاعات یک بانک اطلاعاتی قدیمی فاکس‌پرو را با آخرین نگارش دات نت دارید. اگر سعی کنید از روش‌های و مطالب موجود استفاده کنید، هیچکدام جواب نخواهند داد! در این مطلب تغییرات صورت گرفته را بررسی می‌کنیم.


نیاز به درایور OleDB مخصوص بانک‌های اطلاعاتی قدیمی

برای کار با بانک‌های اطلاعاتی قدیمی از طریق ADO.NET، نیاز است بتوان به نحوی با آن‌ها ارتباط برقرار کرد و اینکار از طریق استاندارد OleDB که صرفا مختص به ویندوز است، قابل انجام است. برای مثال برای کار با فاکس‌پرو نیز در ابتدا باید درایور OleDB آن‌را نصب کرد که ... هیچکدام از لینک‌های قدیمی مایکروسافت در این زمینه دیگر وجود خارجی ندارند! آخرین نگارش مرتبط را می‌توانید در این آدرس و ذیل نام VFPOLEDBSetup.msi دریافت کنید (نگارش 9 را نصب می‌کند).


نیاز به دریافت بسته‌ی System.Data.OleDb

در اولین قدم جهت کار با درایور OleDB نصب شده، باید یک اتصال را توسط نمونه سازی شیء OleDbConnection ایجاد کرد که ... این شیء هم شناسایی نمی‌شود. به همین جهت باید بسته‌ی نیوگت مرتبط با آن‌را به صورت جداگانه‌ای دریافت و نصب کرد:
<ItemGroup>
   <PackageReference Include="System.Data.OleDb" Version="7.0.0"/>
</ItemGroup>


برنامه‌ی مبتنی بر درایور OleDB فاکس‌پرو اجرا نمی‌شود!

اولین سعی در برقراری ارتباط با درایور OleDB نصب شده، با خطای زیر خاتمه می‌یابد:
The 'VFPOLEDB' provider is not registered on the local machine.
مشکل اینجا است که درایور ارائه شده، 32 بیتی است و ما سعی داریم آن‌را در یک محیط 64 بیتی اجرا کنیم. به همین جهت خطای فوق ظاهر می‌شود. برای رفع آن باید PlatformTarget را به x86 تنظیم کرد:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
   <PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
البته این تنظیم هم اگر پیشتر تنها runtime و یا SDK پیش‌فرض 64 بیتی را نصب کرده‌اید، سبب اجرای برنامه نخواهد شد. برای فعالسازی آن باید SDK x86 را هم جداگانه دریافت و نصب کنید.



روش یافتن نام پروایدر OleDB نصب شده

رشته‌های اتصالی OleDB، با =Provider، شروع می‌شوند. اکنون این سؤال مطرح می‌شود که پس از نصب VFPOLEDBSetup.ms یاد شده، دقیقا چه پروایدری به سیستم اضافه شده‌است و نام آن چیست؟
برای اینکار می‌توان از چندسطر زیر برای یافتن نام تمام پروایدرهای OleDB نصب شده‌ی بر روی سیستم استفاده کرد:
var oleDbEnumerator = new OleDbEnumerator();
using var elements = oleDbEnumerator.GetElements();
foreach (DataRow row in elements.Rows)
{
    Console.WriteLine($"{row["SOURCES_DESCRIPTION"]}: {row["SOURCES_NAME"]}");
}
که برای مثال یک خروجی آن می‌تواند به صورت زیر باشد:
Microsoft OLE DB Provider for SQL Server: SQLOLEDB
MSDataShape: MSDataShape
SQL Server Native Client 11.0: SQLNCLI11
Microsoft OLE DB Provider for Visual FoxPro: VFPOLEDB
OLE DB Provider for Microsoft Directory Services: ADsDSOObject
Microsoft OLE DB Driver for SQL Server: MSOLEDBSQL
Microsoft OLE DB Driver for SQL Server Enumerator: MSOLEDBSQL Enumerator
SQL Server Native Client 11.0 Enumerator: SQLNCLI11 Enumerator
Microsoft OLE DB Provider for Search: Windows Search Data Source
Microsoft OLE DB Provider for ODBC Drivers: MSDASQL
Microsoft OLE DB Enumerator for ODBC Drivers: MSDASQL Enumerator
Microsoft OLE DB Provider for Analysis Services 14.0: MSOLAP
Microsoft OLE DB Provider for Analysis Services 14.0: MSOLAP
Microsoft Jet 4.0 OLE DB Provider: Microsoft.Jet.OLEDB.4.0
Microsoft OLE DB Enumerator for SQL Server: SQLOLEDB Enumerator
Microsoft OLE DB Simple Provider: MSDAOSP
Microsoft OLE DB Provider for Oracle: MSDAORA
که در اینجا ما به دنبال یک سطر زیر هستیم:
Microsoft OLE DB Provider for Visual FoxPro: VFPOLEDB
یعنی نام دقیق پروایدر مرتبط با فاکس‌پرو، VFPOLEDB است.


روش خواندن اطلاعات یک بانک اطلاعاتی فاکس پرو

پس از این مقدمات و تنظیمات، اکنون می‌توانیم از قطعه کد متداول ADO.NET زیر، جهت خواندن اطلاعات یک بانک اطلاعاتی فاکس‌پرو، استفاده کنیم:
var connectionString = "Provider=VFPOLEDB;Data Source=" +
       @"C:\path\Db.DBF;Password=;Collating Sequence=MACHINE";
using var dbConnection = new OleDbConnection(connectionString);
using var dataAdapter = new OleDbDataAdapter("select family from Db.DBF", dbConnection);
using var dataset = new DataSet();
dataAdapter.Fill(dataset, "table1");

var sb = new StringBuilder();
foreach (DataRow dataRow in dataset.Tables[0].Rows)
{
    var iranSystem = dataRow[0] as string;
    var unicode = iranSystem.FromIranSystemToUnicode();
    if (!string.IsNullOrWhiteSpace(unicode))
    {
       sb.AppendLine($"[DataRow(\"{iranSystem}\", \"{unicode}\")]");
    }
}
توضیحات:
- نام پروایدر در رشته اتصالی، به VFPOLEDB تنظیم شده‌است.
- select انجام شده بر روی نام فایل dbf انجام می‌شود. یعنی هر فایل dbf، یک جدول را تشکیل می‌دهد.
- اگر نام فیلدهای موجود را نمی‌دانید، بجای select family از * select استفاده کنید و سپس بر روی DataSet پر شده، یک break-point را قرار دهید تا بتوانید نام تمام ستون‌ها را از آن استخراج کنید.
- رشته‌ای را که توسط درایور فاکس‌پرو دریافت می‌کنید، یک رشته‌ی اسکی سیستم عامل داس است که در دات نت، با encoding مساوی 1252 شناخته می‌شود. یعنی encoding این رشته‌ی دریافتی، یونیکد پیش‌فرض دات‌نت نیست و باید توسط متد Encoding.GetEncoding(1252).GetBytes پردازش شود. که در نگارش‌های جدید دات نت، این کد‌پیج‌ها به صورت پیش‌فرض مهیا نیستند و باید در ابتدا ثبت شوند تا قابل استفاده شوند:
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)
- متد FromIranSystemToUnicode استفاده شده، جزئی از «DNTPersianUtils.Core» است که در صورت نیاز به تبدیل اطلاعات قدیمی ایران سیستمی به یونیکد، می‌تواند مورد استفاده قرار گیرد.
مطالب
SharePoint2010 و قابلیت FileStream

اگر خاطرتان باشد یک مقاله سه قسمتی در مورد قابلیت جدید FileStream مربوط به SQL Server 2008 چندی قبل در این سایت منتشر شد (+ و + و +).
خبر خوش این است که این قابلیت تحت عنوان Remote Blob Storage یا RBS در شیرپوینت 2010 (که نسخه‌ی بتای آن یکی دو روزی است که به مشترکین MSDN ارائه شده) قابل استفاده می‌باشد و به این صورت می‌توان به سادگی از مزایای این فناوری جدید بهره‌مند شد.
مستندات رسمی فعال سازی این قابلیت در شیرپوینت 2010:


این قابلیت Remote Blob Storage در شیرپوینت 2007 هم قابل پیاده سازی است اما پشتیبانی رسمی نمی‌شود:


پ.ن.
ارزش این چند سطری که مطالعه فرمودید حدود یک میلیون و 200 هزار تومان مطابق قیمتی است که از یکی از شرکت‌های داخلی مدعی اختراع این فناوری برای شیرپوینت 2007، دریافت شده است!

مطالب
تنظیمات پیشنهادی حداکثر حافظه‌ی مصرفی اس کیوال سرور

به صورت پیش فرض تنظیمات حافظه‌ی اس کیوال سرور به صورتی است که به آن اجازه می‌دهد تمامی حافظه‌ی مهیای سیستم عامل را مصرف کند! اگر شخصی با این مساله آشنایی نداشته باشد احتمالا تصور خواهد کرد که اس کیوال سرور نشتی حافظه دارد یا کلا مشکلی در سیستم روی داده است که تا این حد مصرف حافظه بالا رفته است.
برای مشاهده‌ی این تنظیمات روی instance سرور مورد نظر کلیک راست کرده و گزینه خواص را انتخاب کنید. سپس در صفحه‌ی باز شده گزینه memory را مشاهده نمائید.
البته این‌کار را با استفاده از دستورات T-SQL هم می‌توان انجام داد:

EXEC sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE

EXEC sp_configure 'max server memory (MB)'

EXEC sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE

نتیجه‌ی آن بر روی سیستم برنامه نویسی من به صورت زیر است:



که البته عمدا آن‌را بر روی یک گیگ تنظیم کرده‌ام تا عملکرد سیستم مختل نشود. (چون اگر غیر از این باشد، تعارفی نداشته و هر آنچه را که صلاح بداند مصرف می‌کند!)
کمی در بلاگ‌های رسمی برنامه نویس‌های اس کیوال سرور در سایت MSDN در این‌‌باره جستجو کردم و نتیجه آن به صورت زیر است:

تنظیمات حداکثر حافظه‌ی مصرفی اس کیوال سرورهای 2005 و 2008
برای یک سیستم عامل 64 بیتی:

Physical RAM MaxMem Setting
2GB 1500
4GB 3200
6GB 4800
8GB 6700
12GB 10600
16GB 14500
24GB 22400
32GB 30000
48GB 45000
64GB 59000


برای سروری 32 بیتی این اعداد حداکثر را تقریبا منهای 300 مگابایت نمائید. (و البته همانطور که مطلع هستید در سیستم عامل‌های سرور 32 بیتی، اگر بیشتر از 2 گیگا بایت رم داشتید سوئیچ 3GB و اگر بیشتر از 4 گیگابایت رم مهیا بود، سوئیچ PAE باید در boot.ini تنظیم شوند. در غیر اینصورت هزینه‌ی سخت افزاری بیهوده‌ای را متحمل شده‌اید، زیرا استفاده‌ی بهینه‌ای از آن در یک سیستم عامل 32 بیتی نخواهد شد)

و این اعداد را همانطور که ذکر شد، در تنظیمات سرور می‌توان وارد نمود ( از طریق management studio ) و یا با استفاده از دستورات T-SQL نیز این امر میسر است: (در مثال زیر حداکثر حافظه مجاز مصرفی به 2300 مگابایت تنظیم می‌شود)

EXEC sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE

EXEC sp_configure 'max server memory (MB)', 2300

EXEC sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE

و البته لازم به ذکر است که اعداد فوق برای حالتی پیشنهاد شده است که سرور مورد نظر فقط یک کار و آن‌هم اجرا و سرویس دهی اس کیوال سرور را به عهده داشته باشد. بدیهی است اگر از این سرور استفاده‌های دیگری هم می‌شود این اعداد را باید کمتر نیز در نظر گرفت.


برای مطالعه‌ی بیشتر
http://sqlnerd.blogspot.com/2006/07/memory-use-in-sql-server.html
http://blogs.msdn.com/axperf/archive/2008/03/10/welcome-database-configuration-checklist-part-1.aspx
http://technet.microsoft.com/en-us/library/bb124810.aspx

نظرات اشتراک‌ها
StructureMap 3.0 منتشر شد
سلام
چرا این خبر تو سایت رسمی structure map منتشر نشده؟ چرا سایت و  documentation رو بروز نمیکنن؟
به نظر میرسه از سال 2009 به اینور سایت رو آپدیت نکردن
مطالب
کدامیک از محصولات مهم تجاری 2010 مایکروسافت از ASP.Net MVC استفاده می‌کنند؟

پاسخ : هیچکدام!
برای نمونه دو مورد از محصولات مهم تجاری و پر درآمد مایکروسافت در مقیاس سازمانی SharePoint و Exchange server هستند (البته اینجا منظور برنامه web access مربوط به Exchange server است). جالب اینجا است که هر دو محصول، مبتنی بر دات نت فریم ورک سه و نیم بوده و از ASP.Net WebForms استفاده می‌کنند. تفاوت مهم آن‌ها با نگارش سال 2007 هر کدام، استفاده از ASP.Net Ajax مایکروسافت در این محصولات است و همچنین استفاده‌ی وسیع از توانمندی‌های پاورشل 2 خصوصا امکان مدیریت از راه دور پاور شل 2 که برای مثال در برنامه web access مربوط به exchange server 2010 ، امکان مدیریت خود exchange server را نیز فراهم آورده است یا در SharePoint 2010 جایگزین stsadm شده است (هر چند stsadm هنوز موجود است اما منسوخ شده در نظر گرفته می‌شود).
به علاوه هر دو محصول فقط با ویندوزهای سرور 2008 به بعد، آن هم نسخه‌ی 64 بیتی کار می‌کنند. (البته از آنجائیکه هسته‌ی ویندوز 7 با هسته‌ی ویندوز سرور 2008 نگارش R2 یکی است (یا حداقل بر مبنای یک code base هستند)، SharePoint 2010 را بر روی ویندوز 7 شصت و چهار بیتی هم می‌توان جهت آزمایش و توسعه نصب کرد)
یک دوره‌ی مدیریتی SharePoint 2010 را می‌توانید در آدرس زیر مشاهده نمائید:
Microsoft SharePoint 2010 Administration

جهت اثبات این مدعا (استفاده از WebForms و نه MVC) دو تصویر ذیل به اندازه‌ی کافی گویا هستند:

شیرپوینت 2010



Web Access در Exchange server 2010