حسام امامی حسام امامی
مطالب
2# آموزش سیستم مدیریت کد Git

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

تعاریف زیر هر چند برای Git نوشته شده‌اند، اما می‌توانند در بقیه DVCS‌ها نیز کاربرد داشته باشند.

Commit:

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

Pushing:

بعد از انجام عملیات Commit، معمولا برنامه نویسان می‌خواهند کد‌های نوشته شده را با دیگران به اشتراک بگذارند. این کار به وسیله عملیات Pushing صورت می‌گیرد. بنابراین pushing عبارت است از عملی که با استفاده از آن داده‌ها از یک Repository به Repository دیگر جهت به اشتراک گذاری انتقال می‌یابد. معمولا به این مخزن Upstream Repository می‌گویند. Upstream Repository یک مخزن عمومی برای تمامی برنامه نویسانی است که تغییرات فایل‌های خود را در آنجا push می‌کنند.

Pulling:

عملیات Pushing تنها نیمی از آن چیزی است که برنامه نویسان برای حفظ به روز بودن کدهای خود به آن احتیاج دارند. در بسیاری از موارد آن‌ها نیاز دارند تا تغییرات فایل‌ها و آخرین به روز رسانی‌ها را نیز دریافت کنند. این کار در دو مرحله متفاوت انجام می‌شود:

1)بازیابی داده‌ها از مخزن عمومی (fetch)

2)الحاق داده‌های دریافت شده با داده‌های فعلی

معمولا در بسیاری از سیستم‌های مدیریت کد، چون به هر دوی این عملیات توامان نیاز است، با یک دستور هر دو کار انجام می‌شود. به مجموع عملیات فوق Pulling گویند.

Branch‌ها (شاخه‌ها):

Branch و یا همان شاخه، به ما این امکان را می‌دهد که بتوانیم برای قسمت‌های مختلف یک پروژه که روند تولید آن‌ها با هم ارتباط مستقیمی ندارند، سوابق فایلی متفاوتی را ایجاد کنیم.

به عنوان مثال تصور کنید که در یک پروژه سه تیم متفاوت وجود دارد

1)تیم توسعه برنامه

2)تیم تست و اشکال یابی

3)واحد گرافیکی

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

در Git شاخه اصلی master نام دارد و فایل‌ها به صورت پیش فرض در این شاخه قرار داده می‌شوند. استاندارد کار بر آن است که در شاخه master تنها فایل‌های نهائی قرار گیرند.

Merging:

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

البته عملیات Merging  می تواند باعث ایجاد مشکلی به نام Conflict شود که خوشبختانه Git روش هایی را برای مدیریت این مشکل دارد که در مقالات بعد به آن اشاره خواهد شد.

Locking:

با استفاده از این کار می‌توان مانع تغییر یک فایل توسط برنامه نویسان دیگر شد. معولا Locking به 2 صورت است

1)Strict Locking

2) Optimistic Locking

در روش اول بعد از آن که فایلی قفل شد همان کسی که فایل را قفل کرده تنها امکان تغییر آن را خواهد داشت؛ که البته این روش مناسب سیستم‌های توزیع شده نیست.

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

تعاریف فوق بخشی از مفاهیم اولیه مورد نیاز Git بود. اما ما در ادامه به بررسی object‌های Git و همچنین نحوه ذخیره سازی و مدیریت فایل‌ها در این سیستم مدیریت کد خواهیم پرداخت.

‫۱۲ سال و ۳ ماه قبل، پنجشنبه ۱۲ مرداد ۱۳۹۱، ساعت ۲۱:۲۵
وحید نصیری وحید نصیری
مطالب
آشنایی با الگوی MVP

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

یکی از الگوهایی که شیوه‌ی صحیح این جدا سازی را ترویج می‌کند، الگوی MVP یا Model-View-Presenter می‌باشد. خلاصه‌ی این الگو به صورت زیر است:


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

View :
من می‌دانم که چگونه باید اطلاعاتی را به کاربر به شکلی بصری ارائه داد.
من می‌دانم که چگونه باید اعمالی مانند data binding و امثال آن را انجام داد.
من نمی‌دانم که چگونه باید منطق پردازشی موارد ذکر شده را فراهم آورم.

Presenter :
من می‌دانم که چگونه باید درخواست‌های رسیده کاربر به View را دریافت کرده و آن‌ها را به Model‌ انتقال دهم.
من می‌دانم که چگونه باید اطلاعات را به Model ارسال کرده و سپس نتیجه‌ی پردازش آن‌ها را جهت نمایش در اختیار View قرار دهم.
من نمی‌دانم که چگونه باید اطلاعاتی را ترسیم کرد (مشکل View است نه من) و نمی‌دانم که چگونه باید پردازشی را بر روی اطلاعات انجام دهم. (مشکل Model است و اصلا ربطی به اینجانب ندارد!)


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

الف) پیاده سازی به روش متداول (اسپاگتی کد)

      protected void btnGetData_Click(object sender, EventArgs e)
      {
          lblResult.Text = (Math.PI * double.Parse(txtRadius.Text) * double.Parse(txtRadius.Text)).ToString();
      }
بله! کار می‌کنه!
اما این مشکلات را هم دارد:
- منطق برنامه (روش محاسبه مساحت دایره) با رابط کاربر گره خورده.
- کدهای برنامه در پروژه‌ی دیگری قابل استفاده نیست. (شما متد یا کلاسی را این‌جا با قابلیت استفاده مجدد می‌توانید پیدا می‌کنید؟ آیا یکی از اهداف برنامه نویسی شیءگرا تولید کدهایی با قابلیت استفاده مجدد نبود؟)
- چگونه باید برای آن آزمون واحد نوشت؟

ب) بهبود کد و جدا سازی لایه‌ها از یکدیگر

در روش MVP متداول است که به ازای هر یک از اجزاء ابتدا یک interface نوشته شود و سپس این اینترفیس‌ها پیاده سازی گردد.

پیاده سازی منطق برنامه:

1- ایجاد Model :
یک فایل جدید را به نام CModel.cs به پروژه اضافه کرده و کد زیر را به آن خواهیم افزود:

using System;

namespace MVPTest
{
  public interface ICircleModel
  {
      double GetArea(double radius);
  }

  public class CModel : ICircleModel
  {     
      public double GetArea(double radius)
      {
          return Math.PI * radius * radius;
      }
  }
}
همانطور که ملاحظه می‌کنید اکنون منطق برنامه از موارد زیر اطلاعی ندارد:
- خبری از textbox و برچسب و غیره نیست. اصلا نمی‌داند که رابط کاربری وجود دارد یا نه.
- خبری از رخ‌دادهای برنامه و پاسخ دادن به آن‌ها نیست.
- از این کد می‌توان مستقیما و بدون هیچ تغییری در برنامه‌های دیگر هم استفاده کرد.
- اگر باگی در این قسمت وجود دارد، تنها این کلاس است که باید تغییر کند و بلافاصله کل برنامه از این بهبود حاصل شده می‌تواند بدون هیچگونه تغییری و یا به هم ریختگی استفاده کند.
- نوشتن آزمون واحد برای این کلاس که هیچگونه وابستگی به UI ندارد ساده است.


2- ایجاد View :
فایل دیگری را به نام CView.cs را به همراه اینترفیس زیر به پروژه اضافه می‌کنیم:

namespace MVPTest
{
  public interface IView
  {
      string RadiusText { get; set; }
      string ResultText { get; set; }
  }
}

کار View دریافت ابتدایی مقادیر از کاربر توسط RadiusText و نمایش نهایی نتیجه توسط ResultText است البته با یک اما.
View نمی‌داند که چگونه باید این پردازش صورت گیرد. حتی نمی‌داند که چگونه باید این مقادیر را به Model جهت پردازش برساند یا چگونه آن‌ها را دریافت کند (به همین جهت از اینترفیس برای تعریف آن استفاده شده).

3- ایجاد Presenter :
در ادامه فایل جدیدی را به نام CPresenter.cs‌ با محتویات زیر به پروژه خواهیم افزود:

namespace MVPTest
{
  public class CPresenter
  {
      IView _view;

      public CPresenter(IView view)
      {
          _view = view;
      }

      public void CalculateCircleArea()
      {
          CModel model = new CModel();
          _view.ResultText = model.GetArea(double.Parse(_view.RadiusText)).ToString();          
      }
  }
}

کار این کلاس برقراری ارتباط با Model است.
می‌داند که چگونه اطلاعات را به Model ارسال کند (از طریق _view.RadiusText) و می‌داند که چگونه نتیجه‌ی پردازش را در اختیار View قرار دهد. (با انتساب آن به _view.ResultText)
نمی‌داند که چگونه باید این پردازش صورت گیرد (کار مدل است نه او). نمی‌داند که نتیجه‌ی نهایی را چگونه نمایش دهد (کار View است نه او).
روش معرفی View به این کلاس به constructor dependency injection معروف است.

اکنون کد وب فرم ما که در قسمت (الف) معرفی شده به صورت زیر تغییر می‌کند:

using System;

namespace MVPTest
{
  public partial class _Default : System.Web.UI.Page, IView
  {
      protected void Page_Load(object sender, EventArgs e)
      {
      }

      public string RadiusText
      {
          get { return txtRadius.Text; }
          set { txtRadius.Text = value; }
      }
      public string ResultText
      {
          get { return lblResult.Text; }
          set { lblResult.Text = value; }
      }

      protected void btnGetData_Click(object sender, EventArgs e)
      {
          CPresenter presenter = new CPresenter(this);
          presenter.CalculateCircleArea();
      }
  }
}

در این‌جا یک وهله از Presenter برای برقراری ارتباط با Model ایجاد می‌شود. همچنین کلاس وب فرم ما اینترفیس View را نیز پیاده سازی خواهد کرد.

‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۲۸ مرداد ۱۳۸۸، ساعت ۱۷:۱۳
اردلان شاه قلی اردلان شاه قلی
مطالب
آموزش مفاهیم Data Warehouse

مفاهیم مقدماتی Data Warehouse :

OLTP   ( Online Transaction Processing ) : سیستم‌هایی می‌باشند که برای اهداف اصلی سازمان استفاده می‌شوند و این سیستم‌ها کار پردازش و ذخیره کردن داد‌ه‌ها را در OLTP Database انجام می‌دهند. مانند تمامی سیستم‌های ERP,MIS,…

OLTP Database  : پایگاه داده‌ی سیستم‌های OLTP می‌باشد. به طور معمول هر تراکنش کاربر در کمترین زمان ممکن برروی این سیستم‌ها ذخیره می‌گردد و در طول روز بار‌ها دستورات ( Insert/Update/Delete ) برروی آنها انجام می‌شود. این پایگاه‌های داده، همان Main Data ‌ها یا Source System ‌ها می‌باشند.

ETL  ( extract, transform, and load ) : مراحل انتقال داده از OLTP Database به پایگاه داده‌ی Stage می‌باشد. ETL سیستمی می‌باشد که توانایی اتصال به OLTP را دارد و اطلاعات را از OLTP واکشی می‌کند و به پایگاه داده‌ی Stage انتقال می‌دهد. سپس ETL داده‌ها را مجتمع ( integrates ) کرده و از Stage به DDS ( Dimensional Data Source ) انتقال می‌دهد .

Retrieves Data : عملیات واکشی داده‌ها طبق یک سری قوانین و قواعد می‌باشد .

برای انجام عملیات ETL دو روش وجود دارد

1. Data مجتمع ( Integrate ) و تمیز ( Data cleansing ) شود و در نهایت وارد Data Warehouse گردد.

2. Data وارد Data Warehouse گردد سپس مراحل مجتمع سازی و پاک سازی داده‌ها بر روی داده‌ها در خود Data Warehouse انجام گردد.

Consolidates Data : برخی شرکت‌ها داده‌های اصلی خودشان را در چندین پایگاه داده دارند. در این حالت برای انجام عملیات ETL باید داده‌ها تحکیم و مجتمع شوند و سپس در Data Warehouse  ذخیره شوند.

به طور کلی موارد زیر در فرایند   ETL در نظر گرفته می‌شود:

1. Data availability : برخی داده‌ها در یک سیستم وجود دارند ولی در سیستم دیگری وجود ندارند و یا تفاوت در نگهداری داده‌ها در سیستم‌های مختلف داریم. مثلا در یک سیستم آدرس در سه فیلد نگه داری می‌شود (کشور-شهر-آدرس) اما در سیستمی دیگر در دو فیلد(کشور-آدرس) نگه داری می‌شود. در این حالت باید ما در ETL راه کار هایی برای مجتمع کردن این موارد در نظر بگیریم.

2. Time ranges : در سیستم‌های مختلف امکان دارد بعد‌های زمانی مختلف باشد . مثلا در یک سیستم بررسی‌ها در بازه‌ی ساعتی و در سیستم دیگر بررسی‌ها در بازه‌ی روزانه یا ماهانه باشد . بنابر این در تجمیع داده‌ها باید این مورد مد نظر گرفته شود.

3. Definitions  : تعاریف در سیستم‌های مختلف می‌تواند متفاوت باشد. مثلا در یک سیستم، مبلغ کل فاکتور شامل مالیات می‌باشد ولی در سیستمی دیگر این مبلغ فاقد مالیات می‌باشد.

4. Conversion  : در فرآیند ETL باید باز از قواعد موجود در سیستم‌های مختلف آگاهی داشته باشیم. مثلا در یک سیستم ممکن است دما را به صورت سانتیگراد و در دیگری فارنهایت نگه داری کنند.

5. Matching : باید بررسی لازم را انجام دهیم که کدام داده مرتبط با کدام سیستم می‌باشد. به عبارت دیگر کدام سیستم مالک داده می‌باشد و دقیقا  داده‌ها در کدام سیستم معتبر‌تر می‌باشند. مثلا پرسنل، هم در سیستم حسابداری می‌باشند هم در سیستم پرسنلی؛ ولی معمولا داده‌های اصلی از سیستم پرسنلی می‌آیند.

Periodically : عملیات واکشی داده‌ها ( Retrieves Data ) و مجتمع سازی داده‌ها ( Consolidates Data ) در فرآیند   ETL فقط یکبار اتفاق نمی‌افتد و این مراحل در بازه‌های زمانی خاص تکرار می‌گردند. این واکشی و انتقال داده‌ها می‌تواند در روز چند بار تکرار شود یا می‌تواند چند روز یک بار اجرا گردد و این بستگی دارد به سیاست موجود در Data Warehouse .

DDS (Dimensional Data Source) (Data Warehouse) : یک پایگاه داده از نوع نرمال شده ( Normalized ) یا بعدی ( Dimensional ) می‌باشد. که داده‌های مجتمع شده و تمیز شده سیستم‌های OLTP را در خود جای داده است. این پایگاه داده برای واکشی‌های سیستم‌های آنالیز داده مورد استفاده قرار می‌گیرد. ورود اطلاعات در Data Warehouse به صورت Batch می‌باشد و به هیچ عنوان مانند پایگاه داده‌های OLTP ویرایش داده‌ها به صورت Online و هر زمان که داده‌ها تغییر می‌کنند، صورت نمی‌گیرد. اطلاعات در Data Warehouse معمولا به صورت تجمیع شده روزانه، ماهانه، فصلی یا سالانه می‌باشد. DDS ‌ها مجموعه ای از Dimensional Data Mart ‌ها هستند. و عمدتا به صورت denormalized می‌باشند.

Dimensional Data Mart : مجموعه ای از جداول Fact , Dimension می‌باشند که در یک بیزینس خاص باهم در ارتباط و مشترک می‌باشند.

dimensional data store schemas : طراحی‌های مختلفی از جداول Fact , Dimension در DDS وجود دارد که عبارتند از

1. Star schema : ساده‌ترین روش پیاده سازی Data Warehouse

2. Snowflake : در این روش جداول Dimension کمی نرمال سازی بیشتری دارند. سیستم‌های آنالیز داده با این روش بهتر کار می‌کنند.

3. Galaxy schemas : طراحی در این روش بسیار سخت و پیچیده می‌باشد. با این وجود فرایند ETL در این طراحی ساده‌تر انجام می‌شود.

نمونه‌ی طراحی Star به صورت زیر می‌باشد :

تفاوت‌های DDS و NDS :

1. در DDS ‌ها هیچ گونه نرمال سازی خاصی انجام نمی‌دهیم و عملا تمامی جداول را دینرمال کرده ایم، در حالی که در NDS تمامی جداول تا سطح سوم و گاهی تا سطح پنجم نرمال شده اند.

2. سرعت واکشی و پردازش کوئری‌ها روی DDS خیلی بیشتر از NDS ‌ها می‌باشد.

3. در صورتی که نیاز باشد Data Warehouse ‌های خیلی بزرگ طراحی کنیم با حجم بسیار زیاد توصیه می‌شود از NDS ‌ها استفاده شود در حالی که برای Data Warehouse ‌های کوچک و متوسط بهتر است از DDS ‌ها استفاده شود.

تصویر طراحی یک  (Enterprise Data Source = NDS) EDS در زیر آمده است :

History : جداول Data Warehouse میتوانند در طول زمان بسیار بزرگ شوند و دارای تعداد رکورد زیادی گردند. اینکه حداکثر داده‌های چند سال را در Data Warehouse نگه داری کنیم بستگی به سیاست‌های سازمانی دارد که سیستم OLAP برای آن تهیه می‌گردد. استفاده کردن از table partitioning می‌تواند در جبران افزایش تعداد رکورد کمک زیادی به ما بکند.

slowly changing dimension (SCD) : سه روش برای نگه داری سابقه‌ی تغییرات در جداول Dimension وجود دارد.

1. SCD type 1 : هیچ گونه سابقه‌ی تغییراتی را نگه داری نمی‌کنیم

2. SCD type 2 : سابقه‌ی تغییرات در ردیف‌ها نگه داری می‌شود. در این روش هر ردیف، شماره ردیف قبلی را دارد و تعداد نا محدودی از تغییرات را نگه داری می‌کنیم.

3. SCD type 3 : سابقه‌ی تغییرات در ستون‌ها نگه داری می‌شوند و فقط ردیف جاری و آخرین تغییرات را نگه داری می‌کنیم.

Query : فقط ETL حق تغییرات در Data Warehouse را دارد و کاربر نمی‌تواند Data Warehouse  را تغییر دهد. البته کاربران حق Query کردن از Data Warehouse را دارند.

دقت داشته باشید که کوئری‌های پیچیده در NDS ‌ها بسیار کندتر از همان کوئری در DDS می‌باشد.

Business Intelligence : مجموعه ای از فعالیت‌ها که در یک سازمان برای شناخت بهتر وضعیت Business آن سازمان انجام می‌شود. نتایج BI کمک بسیاری برای تصمیم گیری‌های تکنیکی و استراتژیکی درون سازمان می‌کند. همچنین کمک به بهبود فرایند‌های Business جاری می‌کند.

فعالیت‌های Business Intelligence در سه دسته بندی قرار می‌گیرند :

1. Reporting : گزارشاتی که از Data Warehouse گرفته می‌شود و به کاربر نمایش داده می‌شود و عمدتا این گزارشات به صورت tabular form می‌باشند.

2. OLAP : فعالیت‌های انجام شده روی MDB برای گرفتن گزارشات Drill-Down و ... می‌باشد.

3. Data mining : فرآیند واکشی و داده کاوی داده‌های درون سیستم می‌باشد، که منجر به کشف الگوها و رفتار‌ها و ارتباطات داده‌ها در سیستم می‌شود. توسط داده کاوی ما متوجه می‌شویم چرا برخی داده‌ها در سیستم تولید شده اند.

a. descriptive analytics : زمانی که از داده کاوی برای شرح وقایع گذشته و حال استفاده می‌شود.

b. predictive analytics : زمانی که از داده کاوی برای پیش بینی وقایع گذشته استفاده می‌شود.

Real time data warehouse  : به DW هایی گفته می‌شود که در کمترین زمان، تغییرات OLTP را در خود خواهند داشت. امروزه این نوع DW ‌ها تغییرات 5 دقیقه تا حداکثر 1 ساعت قبل را در خود دارند. برای دسترسی به چنین DW هایی دو راه زیر وجود دارد :

1. بر روی هر جدول، Trigger هایی باشد تا تغییرات را به DW انتقال دهد. (البته برای این منظور باید Business مربوط به ETL را در این تریگر‌ها نوشت)

2. سورس برنامه‌های اصلی کاربر ( OLTP ) تغییر کند تا علاوه بر OLTP Database ‌ها Data Warehouse را هم تغییر دهند.

روش‌های فوق بسیار روی سرعت و کارایی برنامه‌های اصلی تاثیر خواهند گذاشت.

NDS ( Normalize Data Source ) : در صورتی که طراحی Data Warehouse به صورت Dimensional نباشد و به صورت Normalize باشد، نوع Data Warehouse از نوع NDS می‌باشد.

روش ساخت MDB  :

OLTP Database -> ETL -> Stage Database ->  DDS (Dimensional Data Source = Data Warehouse) -> SSAS -> MDB

روش ساده‌تر ساخت Data Warehouse :

 

منظور از Source System  همان OLTP Database ‌ها می‌باشد.

به خاطر داشته باشید که Source System ‌ها جزئی از Data Warehouse نمی‌باشند.

از کاربرد‌های Data Warehouse می‌توان به موارد زیر اشاره کرد

1. Data Mining

2. استفاده در گزارشات

3. تجمیع داده ها

Data Mining کمک به درک بهتر Business جاری در سازمان می‌کند. همچنین منجر به کشف دانش از درون داده‌ها می‌شود.

برای Data Mining می‌توانید از انواع پایگاه داده‌های موجود مانند رابطه ای ، سلسله مراتبی و چند بعدی استفاده کرد . حتا می‌توان از فایل‌های XML , Excel نیز استفاده کرد.

Customer Relationship Management (CRM) :

منظور از مشتری، مصرف کننده‌ی سرویسی است که سازمان شما ارایه می‌کند. یک سیستم CRM شامل تمامی برنامه ایی می‌باشد که تمام فعالیت‌های مشتری را پشتیبانی می‌کند.

Operational Data Store (ODS) :

این پایگاه داده به صورت رابطه ای و نرمال شده می‌باشد و شامل تمامی اطلاعات پایگاه داده ای OLTP می‌باشد که در این پایگاه داده مجتمع شده اند. تفاوت ODS با Data Warehouse در این می‌باشد که داده‌ها در ODS با هر Transaction به روز می‌شوند (سرعت بروز رسانی اطلاعات در ODS بالاتر از DW می‌باشد).

Master Data Management (MDM)  :

در یک نگاه می‌توان داده‌ها را به دو دسته تقسیم کرد

1. transaction data

2. master data

transaction data : شامل داده ای transactional در سیستم‌های OLTP می‌باشد.

master data : توضیح دهنده‌ی Business جاری در سازمان می‌باشد.

برای تشخیص این دو نیاز است Business سازمان را به خوبی شناسایی نمایید. به عبارت دیگر رویداد‌های Business ی همان transaction data می‌باشند و master data شامل پاسخ‌های این سوال‌ها می‌باشد. چه کسی، چه چیزی و کجا در مورد Business transaction .

Customer data integration (CDI) : عبارت است از MDM در رابطه با مشتری داده ها. کار این قسمت عبارت است از واکشی، پاک سازی ، ذخیره سازی ، نگه داری و به اشتراک گذاشتن داده ای مشتری می‌باشد.

Unstructured Data : داده ای ذخیره شده در پایگاه داده ، structured Data می‌باشند و داده هایی مانند عکس و فیلم و صوت و ...

Service-Oriented Architecture (SOA) : یک متد ساخت برنامه می‌باشد که در این روش تمامی اجزا برنامه به صورت ماژول هایی دیده می‌شود که در آنها ارتباطات با دیگر سیستم‌ها به صورت سرویس می‌باشد و این زیر سیستم‌ها را می‌توان در پروژه‌های مختلف به کار برد.

Real-Time Data Warehouse : DW هایی که توسط ETL به روز می‌شوند در هنگامی که یک Transaction روی OLTP اتفاق می‌افتد.

مراحل انتقال داده از OLTP Database به MDB به صورت زیر می‌باشد.

Data quality : مکانیسم اطمینان بخشی از این که در DW دادهای مناسب و درست وارد می‌شوند. به عبارت دیگر DQ همان firewall برای DW در مقابل داده‌های نامناسب می‌باشد.

برای بهتر مشخص شدن مکان DQ شکل زیر را در نظر بگیرید

نحوه‌ی حرکت داده ای از OLTP به MDB اولین چیزی می‌باشد که شما باید به آن فکر کنید و برای آن روشی را انتخاب نمایید قبل از ساخت   Data Warehouse .

چهار روش برای معماری انتقال اطلاعات از OLTP به DW وجود دارد (البته به عنوان نمونه و شما می‌توانید از روش‌های دیگر و طراحی‌های مختلف و ترکیبی نیز بهره ببرید)

1. single DDS : در این روش فقط Stage , DDS وجود دارد.

2. NDS + DDS : در این روش علاوه بر Stage,DDS از NDS نیز استفاده می‌شود.

3. ODS + DDS : در این روش از Stage,ODS,DDS استفاده می‌گردد.

4. federated data warehouse (FDW ) : استفاده از چندین DW که با هم تجمیع شده اند.

تصویر Single DDS :

تصویر NDS + DDS :

تصویر ODS + DDS :

تصویر federated data warehouse (FDW ) :

منبع : Building a Data Warehouse With Examples in SQL Server  انتشارات Apress

‫۱۰ سال و ۱۰ ماه قبل، چهارشنبه ۱۱ دی ۱۳۹۲، ساعت ۱۴:۳۰
محمد دلیری محمد دلیری
نظرات نظرسنجی‌ها
از کدام یک از برنامه‌های issue tracker استفاده کرده‌اید؟
قبلا از trello استفاده می‌کردم ، بعد که یک نسخه ایرانی issue tracker به نام تسکولو دیدم به آن مهاجرت کردم. دلیل مهاجرتم از trello به تسکولو :
1 - به خاطر بومی بودن ، زبان فارسی ، تاریخ شمسی
2 - محیط بسیار ساده و زیبا و قدرتمند
3 - پشتیبانی خوب و سریع
4 - اتصال به trello
‫۵ سال و ۶ ماه قبل، دوشنبه ۲۶ فروردین ۱۳۹۸، ساعت ۱۶:۴۶
وحید نصیری وحید نصیری
اشتراک‌ها
مشکل امنیتی Log4j

«... چند روزی هست که یه مشکل امنیتی در کتابخانه بسیار محبوب Log4j پیدا شده. کتابخونه Log4j که یکی از صدها محصول بنیاد Apache هست، به برنامه نویسان جاوا اجازه میده که گزارش هاشون رو به صورت مجتمع، بدون نیاز به پیاده سازی مجزا و با یه قالب واحد داشته باشن. این مشکل امنیتی که اجازه Remote Code Execution رو به حمله کننده میتونه بده دارای بالاترین حد خطر یعنی 10 از 10 هست...»

مشکل امنیتی Log4j
‫۲ سال و ۹ ماه قبل، چهارشنبه ۲۴ آذر ۱۴۰۰، ساعت ۱۰:۵۹
وحید نصیری وحید نصیری
نظرات مطالب
MVVM و الگوی ViewModel Locator
سورس ASP.NET MVC‌ در سایت کدپلکس در دسترس هست. این مورد و نحوه طراحی باز آن، تابحال یک مزیت منحصربفردی رو به همراه داشته که میشه گفته بی سابقه هست:
چندین فریم ورک MVC جدید توسط برنامه نویس‌های مستقل برای ASP.NET طراحی شده.
مثلا:
FubuMVC
Nancy
Bistro MVC
OpenRasta
و ...

در کل این‌ها هم می‌تونه ایده‌ای باشه برای کسانی که نمی‌خواهند در چارچوب‌های بسته مایکروسافت کار کنند و علاقمند هستند کنترل بیشتری روی محصول نهایی داشته باشند.
‫۱۲ سال و ۱۱ ماه قبل، دوشنبه ۵ دی ۱۳۹۰، ساعت ۱۶:۱۵
بهمن خلفی بهمن خلفی
اشتراک‌ها
راست به چپ trello با استفاده از stylish

بی شک از ترلو که یکی از محبوبترین سیستم‌های مدیریت پروژه آنلاین هست استفاده میکنید اما یکی از دغدغه‌های ما ایرانیها ، استفاده از زبان راست به چپ در محیط‌های چپ به راست بوده و هست .

البته style‌های زیادی در این موضوع آمده اما باب میل نبوده !

با این روش میتوانید ترلو رو با کمترین تغییرات بصورت راست به چپ استفاده کنید.

راست به چپ trello با استفاده از stylish
‫۸ سال و ۳ ماه قبل، شنبه ۲۶ تیر ۱۳۹۵، ساعت ۱۸:۳۳
مهمان مهمان
نظرات مطالب
مدیریت ساده‌تر امور Async (غیر همزمان) در نسخه‌ی بعدی زبان‌های دات نتی
راستش اگه بخوام نظر شخصیم رو بگم باید بگم از سیاست جدید ماکروسافت مبنی بر تمرکز بر روی زبان برنامه نویسی به جای API ها زیاد خوشم نمیاد.
درسته که نتیجش سرعت بیشتر در برنامه نویسی اما یک مشکل بزرگ داره.تا قبل از این اگه شما یک زبان برنامه نویسی رو یاد میگرفتید می تونستید خیلی آسون و سریع اون رو در زبان های دیگه هم یاد بگیرید و ازش استفاده کنید چون بیشتر API ها با زبان های C/C++ نوشته شدن بنابرین زبان ها معمولا یک API رو فراخوانی می کردن فقط نحوه فراخوانی اون ها در زبان ها فرق می کرد .
به عنوان مثال برنامه نویسی سوکت در Java,CSharp,CPlusPlus ... کاملا شبیه هم هستش.MultiThreading هم به همین صورت.اگه شما با یکی از این زبان ها این Concept
ها رو یاد بگیرید می تونید همون Concept رو در بقیه زبان ها هم سریع یاد بگیرید.
اما با این سیاست جدید اگه شما مثلا برنامه نویسی ASync رو در CSharp یاد بگیرید نمی تونید معلومات خودتون رو در این زمینه به زبان های دیگه ببرید و فقط میتونید ازش در دات نت استفاده کنید.
خوشحال می شم نظر بقیه اساتید رو در این زمینه بدونم .
‫۱۳ سال و ۱۲ ماه قبل، چهارشنبه ۱۹ آبان ۱۳۸۹، ساعت ۱۵:۲۰
محمد صافدل محمد صافدل
اشتراک‌ها
آشنایی با ریاضیات مورد استفاده در برنامه نویسی بازیها
برنامه نویسی بازیها وابستگی بسیار زیادی به ریاضیات دارد در حقیقت برنامه نویسی بازی یعنی ریاضیات. نویسنده این سری مقالات که یک برنامه نویس حرفه ای بازیهای رایانه ای است، سعی دارد ریاضیات مورد استفاده در برنامه نویسی بازیها را به زبان ساده بیان کند
آشنایی با ریاضیات مورد استفاده در برنامه نویسی بازیها
‫۱۲ سال و ۲ ماه قبل، دوشنبه ۱۳ شهریور ۱۳۹۱، ساعت ۱۵:۰۲
علی یگانه مقدم علی یگانه مقدم
مطالب
بسته بندی نرم افزار الکترون
بعد از اینکه برنامه الکترون آماده شد، لازم است آن را به فایل‌های اجرایی پلتفرم‌های مختلف تبدیل کنیم. برای اینکار بسته معروف Electron-packager را مورد استفاده قرار می‌دهیم. برای نصب آن به شکل زیر اقدام کنید:
npm install electron-packager --save-dev
بعد از اینکه نصب شد، در فایل package.json در قسمت scripts، خصوصیت جدیدتری را وارد می‌کنیم:
"build":"electron-packager . myapp --platform=all --arch=all --overwrite"
این دستور شامل حداقل‌های آرگومان‌ها می‌باشد. در تشریح این دستور باید گفت اولین آرگومان، نام دایرکتوری است که برنامه شما در آن نوشته شده است و حاوی فایل package.json است و با قرار دادن علامت "." دایرکتوری جاری را معرفی کرده‌ایم. بعد از آن نام برنامه و فایل اجرایی برنامه است. بعد از آن فلگ‌ها آغاز می‌شوند که اولین فلگ مشخص میکند خروجی خود را برای چه پلتفرمی نیاز دارید و شامل مقادیر زیر می‌شود؛ یا اینکه عبارت all را برای در نظر گرفتن همه مقادیر وارد کنید.
darwin
سیستم عامل مکینتاش
linux
 سیستم عامل لینوکس
win32
 سیستم عامل ویندوز

فلگ بعدی معماری سیستم عامل را نشان میدهد که برای سیستم‌های 32 بیتی مقدار ia32 و برای سیستم‌های 64 بیتی مقدار x64 می‌باشد. ولی در صورتیکه همه مقادیر را در نظر دارید، می‌توانید همانند خط بالا از مقدار all استفاده کنید.

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

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

حال با دستور زیر در nodejs، عملیات بسته بندی را آغاز می‌کنیم:

npm run build
بعد از اجرای این دستور برای اولین بار، ممکن است برای هر پلتفرم، کتابخانه‌های مربوطه را دانلود کند تا بر اساس آن، عمل بسته بندی را انجام دهد. سپس در دایرکتوری پروژه، دایرکتوری‌های جدیدی را با نام‌های مشخصی خواهید یافت.
یکی از دیگر فلگ‌ها که کاربردی می‌باشد، برای نادیده گرفتن ورورد یک سری پکیج‌ها به بسته نهایی است که به طور پیش فرض جلوی ورود بسته‌های eletron-prebuilt و electron-packager را میگیرد. ولی اگر دوست دارید تا بسته‌های دیگری را نیز به این لیست اضافه کنید، دستو زیر را به کار ببرید:
--ignore=node_modules/<package_name>
یا
--ignore=node_modules/electron_[0-9]*

فلگ‌های پر استفاده دیگر این بسته:
 aap-version  نسخه برنامه
 app-copyright  متنی برای قانون کپی رایت
 asar موقعی که برنامه‌ای را بسته بندی می‌کنید، در دایرکتوری Resources/App، هنوز سورس برنامه وجود دارد که فایل اجرایی شما بدون آن قادر به ادامه فعالیت نیست. ولی اگر بخواهیم این سورس را در اختیار شخصی قرار ندهیم، باید از ویژگی asar استفاده کنیم. با استفاده از این فلگ، فایلی با نام app.asar جای این دایرکتوری ایجاد خواهد شد و دیگر نیازی نیست تا سورس برنامه همراه آن باشد.
 icon در صورتیکه قصد استفاده از آیکنی بجز آیکون الکترون را دارید.
 out به طور پیش فرض برنامه نهایی در دایرکتوری کاری پروژه اضافه می‌شود. در صورتیکه قصد دارید آن‌را در دایرکتوری بجز دایرکتوری کاری قرار دهید، از این ویژگی استفاده کنید.
 version-string این خصوصیت برای نسخه بندی برنامه است که فقط برای ویندوز کاربرد دارد و شامل خصوصیاتی چون نام محصول، نام سازنده، توصیف برنامه و ... می‌باشد:
--version-string.ProductName="Product"

                   Properties supported:
                   - CompanyName
                   - FileDescription
                   - OriginalFilename
                   - ProductName
                   - InternalName
prune
 استفاده از این فلگ باعث می‌شود کلیه بسته‌های معرفی شده در dev-dependency به بسته نهایی اضافه نشوند

دستور بسته بندی بالا را نیز می‌توان به طور خلاصه‌تر نیز نوشت :

electron-packager . --all
این دستور با در نظر گرفتن همه پلتفرم‌ها و معماری آن‌ها، برای دایرکتوری جاری اجرا شده و نام برنامه و دیگر اطلاعات را از طریق فایل package.json به دست می‌آورد.
‫۸ سال و ۴ ماه قبل، جمعه ۲۱ خرداد ۱۳۹۵، ساعت ۲۰:۰۵