انجام عملیات Pivot توسط MDX :
برای این منظور کافی است فقط جای سطر و ستون را با هم عوض کنیم.برای مثال، کوئریهای زیر را اجرا نمایید.
Select [Date].[Calendar].[Calendar Year] on columns, [Product].[Product Categories].[Category] on rows From [Adventure Works] GO Select [Product].[Product Categories].[Category] on columns, [Date].[Calendar].[Calendar Year] on rows From [Adventure Works]
خروجی به صورت زیر میباشد.
چگونگی استفاده از ساختارهای سلسله مراتبی در محورهای مختلف :
برای روشن شدن مطلب چندین نمونه کوئری زیر را باهم اجرا میکنیم.
در ابتدا به خاطر داشته باشید که امکان استفاده از یک ساختار سلسله مراتبی در دو محور (Axis ) مجزا وجود ندارد. برای روشنتر شدن این مطلب کوئری زیر را اجرا کنید:
Select [Date].[Calendar].[Calendar Year] on columns, [Date].[Calendar].[Month] on rows From [Adventure Works]
در توضیح مثال بالا دقت داشته باشید که واکشی [Calendar Year] و [Month] از یک ساختار سلسله مراتبی یکسان به نام [Date].[Calendar] انجام شده است و این کار در MDX ها غیر مجاز میباشد.
البته استفاده از دو ساختار سلسله مراتبی متفاوت از یک دایمنشن در دو محور مجزا امکان پذیر میباشد برای مثال :
Select [Date].[Calendar].[Calendar Year] on columns, [Date].[Month of Year].[Month of Year] on rows From [Adventure Works]
در مثال بالا واکشی از دو ساختار سلسله مراتبی مختلف اما از یک دایمنشن در دو محور مجزا صورت گرفته است.
امکان استفاده از دو ساختار سلسله مراتبی یکسان در یک محور مجاز میباشد.
Select [Measures].[Internet Sales Amount] on columns, {[Date].[Calendar].[Calendar Year],[Date].[Calendar].[Month]} on rows From [Adventure Works]
همچنین استفاده از دو ساختار سلسله مراتبی مختلف از یک دایمنشن در یک محور مجاز نمیباشد.
Select [Measures].[Internet Sales Amount] on columns, {[Date].[Calendar].[Calendar Year],[Date].[Month of Year].[Month of Year]} on rows From [Adventure Works]
در مثال بالا از دو ساختار سلسله مراتبی [Date].[Calendar] و [Date].[Month of Year] استفاده شده است.
در صورتی میتوانیم از دو ساختار سلسله مراتبی متفاوت از یک دایمنشن در یک محور استفاده کنیم که آنها را باهم Cross Join کنیم.
Select [Measures].[Internet Sales Amount]on columns, crossjoin( [Date].[Calendar].[Calendar Year], [Date].[Month of Year].[Month of Year] )on rows From [Adventure Works]
دقت داشته باشید که امکان استفاده از دو ساختار سلسله مراتبی یکسان از یک دایمنشن در Cross Join وجود ندارد همان گونه که در دو مثال قبل مشاهده نمودید. (و البته نیازی هم به استفاده از Cross Join وجود ندارد)
Select [Measures].[Internet Sales Amount] on columns, crossjoin( [Date].[Calendar].[Calendar Year], [Date].[Calendar].[Month] )on rows From [Adventure Works]
به طور کلی استفاده از Cross Join مانند استفاده از () می باشد . بنابر این می توان کلمه ی Cross Join را ننوشت .
Select {[Measures].[Internet Sales Amount],[Measures].[Reseller Sales Amount]} on columns, crossjoin( [Date].[Calendar].[Calendar Year], [Date].[Month of Year].[Month of Year] )on rows From [Adventure Works] GO Select {[Measures].[Internet Sales Amount],[Measures].[Reseller Sales Amount]} on columns, ( [Date].[Calendar].[Calendar Year], [Date].[Month of Year].[Month of Year] )on rows From [Adventure Works]
دو کوئری بالا مشابه هم میباشند.
می توان از دو Cross Join در دو محور مختلف نیز استفاده کرد.
Select crossjoin( [Product].[Product Categories].[Category], {[Measures].[Internet Sales Amount],[Measures].[Reseller Sales Amount]} )on columns, crossjoin( [Date].[Calendar].[Calendar Year], [Date].[Month of Year].[Month of Year] )on rows From [Adventure Works]
دقت داشته باشید نوع محصول در ستونها بالای سر ستون [ Internet Sales Amount] و [Reseller Sales Amount] قرار گرفته است.
استفاده از Cross Join های تودر تو نیز وجود دارد.
Select crossjoin( [Sales Territory].[Sales Territory].[Country], crossjoin( [Product].[Product Categories].[Category], { [Measures].[Internet Order Count], [Measures].[Reseller Order Count] } ) )on columns , crossjoin( [Date].[Calendar].[Calendar Year], [Date].[Month of Year].[Month of Year] ) on rows From [Adventure Works]
در کوئری زیر به جای Cross Join از () استفاده شده است
Select crossjoin( [Sales Territory].[Sales Territory].[Country], [Product].[Product Categories].[Category], { [Measures].[Internet Order Count], [Measures].[Reseller Order Count] } ) on columns, ([Date].[Calendar].[Calendar Year],[Date].[Month of Year].[Month of Year]) on rows From [Adventure Works]
استفاده از عملگر * مانند استفاده از Cross Join می باشد.
Select crossjoin( [Sales Territory].[Sales Territory].[Country], [Product].[Product Categories].[Category], { [Measures].[Internet Order Count], [Measures].[Reseller Order Count] } ) on columns, [Date].[Calendar].[Calendar Year] * [Date].[Month of Year].[Month of Year] on rows From [Adventure Works]
در مقالات بعدی آموزش MDX Query را ادامه خواهیم داد.
مقدمه
در لینکی که چندی پیش به اشتراک گذاشته بودم؛ به مطلبی تحت این عنوان اشاره شده بود: "آیا از KPI باید به انباره داده و هوش تجاری رسید؟" (بر گرفته از وبلاگ آقای جام سحر) که در آن به موانع پیش روی انجام پروژههای BI در ایران پرداخته شده است.این مقاله بر گرفته از فصل سوم یکی از White Paperهای ماکروسافت با عنوان Microsoft EDW Architecture, Guidance and Deployment Best Practices میباشد. که به شرح عملیات Loading در فاز ETL میپردازد. از آنجا که به منظور پیاده سازی این نوع پروژهها معمولاً در ایران برون سپاری صورت میگیرد و مدیران شرکتها بیشتر درگیر سیستمهای OLTP هستند و مجری پروژه (شرکت پیمانکار) معمولاً کوتاهترین مسیر را جهت انجام پروژه انتخاب میکند(و امروزه نیک میدانیم که "انتخاب مسیرهای کوتاه در زمان کم میتواند به پیچیدگیهای بسیار جدی در دراز مدت منجر شود!") و همچنین از آنجا که متاسفانه به دلیل عدم ثبات مدیریت در ایران معمولاً "مدیریت برای تحویل پروژه تحت فشار است و نه برای مسائل پشتیبانی " و مسائل دیگری از این دست؛ چنانچه در تحویل گیری محصول به درستی تست نرم افزار صورت نگیرد، در نظر گرفتن موارد زیر:
Validation: Are we building the right product? ~ Software is traceable to customer requirements
2- Detecting Net Changes
2-1- Pulling Net Changes – Last Change Column
2-2- Pulling Net Changes – No Last Change Column
2-3- Pushing Net Changes
3- ETL Patterns
3-1- Destination load Patterns
3-2- Versioned Insert Pattern
3-3- Update Pattern
3-4- Versioned Insert: Net Changes
4- Data Integration Best Practices
4-1- Basic Data Flow Patterns
4-1-1- Update Pattern
4-1-2- Update Pattern – ETL Framework
4-1-3- Versioned Insert Pattern
4-1-4- Update vs. Versioned Insert
4-2- Dimension Patterns
4-3- Fact Table Patterns
4-3-1- Managing Inferred Members
1- Full Load vs Incremental Load
نسلهای اولیه DW (اختصار Data Warehouse) به شکل Full Loads پیاده سازی میشدند، به این طریق که هر بار عملیات بارگذاری صورت میگرفت، DW از نو دوباره ساخته میشد. شکل زیر مراحل مختلف انجام شده در این روش را نمایش میدهد:
پروسه Full Load شامل مراحل زیر بود:
- Drop Indexes: از آنجا که Indexها زمان بارگذاری را افزایش میدادند، این عمل صورت میپذیرفت.
- Truncate Tables: تمامی رکوردهای موجود در جداول حذف میشدند.
- Bulk Copy
- Load Data
- Post Process: شامل عملیاتی نظیر شاخص گذاری روی داده هایی است که اخیراً بارگذاری شده اند و....
روی هم رفته Full Load مسئله ای مشکل ساز بود، زیرا نیاز به زمانی برای بارگذاری مجدد دادهها داشت و مسئلهی مهمتر نداشتن امکان دستیابی به گزارشاتی تاریخچه ای با ماهیت زمان برای مشتریان کسب وکار بود. به این دلیل که همواره یک کپی از آخرین دادههای موجود در سیستم عملیاتی درون DW قرار میگرفت؛ که با بکارگیری Full Load اغلب قادر به ارائهی این نوع از گزارشات نبودیم، بدین ترتیب سازمانها به نسل دوم روی آورند که در این دیدگاه از مفهوم Incremental Load استفاده میشود. اشکال زیر مراحلی که در این روش انجام میشود را نمایان میسازد:
Incremental Load with an Extract In area
Incremental Load without an Extract In area
مراحل Incremental Load شامل:
- بارگذاری تغییرات نسبت به آخرین فرآیند بارگذاری انجام شده
- درج / بروزرسانی تغییرات درون Production area
- درج / بروزرسانی Consumption area نسبت به Production area
تفاوتهای اصلی میان Full Load و Incremental Load در این است که در Incremental Load:
- نیازی به پردازشهای اضافی جهت حذف شاخص ها، پاک کردن تمامی رکوردهای جداول و ساخت مجدد شاخصها نیست.
- البته نیاز به رویه ای جهت شناسایی تغییرات میباشد.
- و همچنین نیاز به بروزرسانی بعلاوه درج رکوردهای جدید نیز میباشد.
ترکیب این عوامل برای ساخت Incremental Load کارآمد تر، منجر به پیچیدهتر شدن پیاده سازی و نگهداری آن نیز میشود.
2- Detecting Net Changes
فرآیند لود افزایشی ETL، بایست قادر به شناسائی رکوردهای تغییریافته در مبداء باشد، که این عمل با استفاده از هر یک از تکنیکهای Push یا Pull انجام میشود.
- در تکنیک Pull، فرآیند ETL رکوردهای تغییریافته در مبداء را انتخاب میکند:
- ایدهآل وجود داشتن یک ستون Last Changed در سیستم مبداء است؛ که از آن میتوان جهت انتخاب رکوردهای تغییر یافته استفاده نمود.
- چنانچه ستون Last Changed وجود نداشته باشد، تمامی رکوردهای مبداء باید با رکوردهای مقصد مقایسه شود.
- در تکنیک Push، مبداء تغییرات را شناسائی میکند و آنها را به سمت مقصد Push میکند؛ این درخواست میتواند توسط فرآیند ETL انجام شود.
2-1- Pulling Net Changes – Last Change Column
بیشتر جداول در سیستمهای مبداء حاوی ستون هایی هستند که زمان ایجاد و یا اصلاح رکوردها را ثبت میکنند. در نوع دیگری از سیستمهای مبداء ستونی با مقدار عددی وجود دارد، که هر زمان رکوردی تغییر یافت به آن ستون مقداری اضافه میشود. هر دوی این تکنیکها به فرآیند ETL اجازه میدهند، بطور کارآمدی رکوردهای تغییریافته را انتخاب کند. (با مقایسه، بیشترین مقدار قرار گرفته در آن ستون؛ که در طول آخرین اجرای فرآیند ETL بدست آمده است). نمونه ای از جداول سیستم مبداء که دارای تغییرات زمانی است در شکل زیر نمایش داده میشود.همچنین شکل زیر نشان میدهد، چگونه یک مقدار عددی میتواند به منظور انتخاب رکوردهای تغییریافته استفاده شود.
2-2- Pulling Net Changes – No Last Change Column
شکل زیر گردش فرآیند را هنگامی که ستون Last Change وجود ندارد؛ نمایش میدهد.این گردش فرآیند شامل:
- Join میان مبداء و مقصد با استفاده از یک دستور Left Outer Join است.
- تمامی رکوردهای مبداء که در مقصد وجود ندارند، پردازش میشوند.
- زمانی که رکوردی در مقصد وجود داشته باشد مقادیر دادههای مبداء و مقصد مقایسه میشوند.
- تمامی رکوردهای مبداء که تغییر یافته اند پردازش میشوند.
2-3- Pushing Net Changes
دو متد متداول Push وجود دارد که در تصویر زیر نمایش داده شده است.
تفاوت این دو روش به شرح زیر است:
- در سناریو اول (شکل سمت چپ)؛ بانک اطلاعاتی رابطه ای سیستم مبداء Transaction Log را مرتب مانیتور میکند تا تغییرات را شناسائی کرده و در ادامه تمامی این تغییرات را در جدولی در مقصد درج میکند.
- در سناریو دوم؛ توسعه دهندگان Trigger هایی ایجاد میکنند تا هر زمان که رکوردی تغییر یافت، تغییرات در جدولی که در مقصد وجود دارد درج گردد.
مسئله ای که در هر دو مورد وجود دارد Load اضافه ای است؛ که روی سیستم مبداء وجود دارد و میتواند Performance سیستمهای OLTP را تحت تاثیر قرار دهد. به هر روی سناریو نخست معمولاً کاراتر از سناریویی است که از Trigger استفاده میکند.
3- ETL Patterns
پس از شناسائی رکوردهایی که در مبداء تغییر یافته اند، نیاز داریم تا این تغییرات در مقصد اعمال شود. در این قسمت به معرفی الگوهایی که برای اعمال این تغییرات وجود دارد میپردازیم.
3-1- Destination load Patterns
تشخیص چگونگی اضافه نمودن تغییرات در مقصد تابع دو عامل زیر است:
- آیا رکورد هم اینک در مقصد وجود دارد؟
- الگوی استفاده شده برای جدول مقصد به کدام شکل است؟ (Update یا Versioned Insert)
فلوچارت زیر نشان میدهد، به چه شکل جداول مقصد متاثر از چگونگی پردازش رکوردهای مبداء قرار دارند. توجه داشته باشید که عمل بررسی بطور جداگانه و در یک لحظه صورت میگیرد.
3-2- Versioned Insert Pattern
Kimball Type II Slowly Changing Dimension نمونه ای از الگوی Versioned Insert است؛ که در آن نمونه ای از یک موجودیت دارای ورژنهای متعددی است. مطابق تصویر زیر؛ این الگو به ستونهای اضافه ای نیاز دارند که وضعیت نمونه ای از یک رکورد را نمایش دهد.
این ستونها به شرح زیر هستند:
- Start Date: زمانی که وضعیت آن نمونه از رکورد فعال میشود.
- End Date: زمانی که وضعیت آن نمونه از رکورد غیر فعال میشود.
- Record Status: وضعیتهای یک رکورد را نشان میدهد، که حداقل به شکل Active یا Inactive است.
- # Version: این ستون که اختیاری میباشد، ورژن آن نمونه از رکورد را ثبت میکند.
برای مثال شکل زیر؛ بیانگر وضعیت اولیه رکوردی در این الگو است:
فرض کنید که این رکورد در تاریخ March 2 , 2010 در سیستم مبداء تغییر میکند. فرآیند ETL این تغییر را شناسائی میکند و همانند تصویر زیر؛ به شکل نمونه ای ثانویه از این رکورد، اقدام به درج آن میکند.
توجه داشته باشید زمانی که رکورد دوم در جدول درج میشود، به منظور بازتاب این تغییر؛ رکورد اول به شکل زیر بروزرسانی میگردد:
- End Date: تا این زمان وضعیت این رکورد فعال بوده است.
- Record Status:که Active به Inactive تغییر پیدا میکند.
در برخی از پیاده سازیهای DW عمدتاً از الگوی Versioned Insert استفاده میشود و هرگز از الگوی Update استفاده نمیشود. مزیت این استراتژی در این است که تمامی تاریخچه تغییرات ردیابی و ثبت میشود. به هر روی غالباً هزینه ثبت کردن این تغییرات منجر به ایجاد نسخههای زیادی از تغییرات میشود. تیم DW برای مواردی که تغییرات متاثر از گزارشات تاریخچه ای نیستند، میتوانند الگوی Update را در نظر گیرند.
3-3- Update Pattern
الگوی Update روی رکورد موجود، تغییرات سیستم مبداء را بروزرسانی میکند. مزیت این روش در این است که همواره یک رکورد وجود دارد و در نتیجه باعث ایجاد Queryهای کارآمدتر میشود. تصویر زیر بیانگر ستون هایی است که برای پشتیبانی از الگوی Update بایست ایجاد کرد.
این ستونها به شرح زیر هستند:
- Record Status: وضعیتهای یک رکورد را نشان میدهد که حداقل به شکل Active یا Inactive است.
- # Version: این ستون که اختیاری میباشد، ورژن آن نمونه از رکورد را ثبت میکند.
موارد اصلی الگوی Update عبارتند از:
- تاریخ ثبت نمیشود. ابزاری ارزشمند برای نظارت بر داده ها، تغییرات تاریخی است و زمانی که ممیزی داده رخ میدهد؛ میتواند مفید واقع شود.
- بروزرسانیها یک الگوی مبتنی بر مجموعه هستند. استفاده از بروزرسانی هر بار یک رکورد در ابزار ETL خیلی کارآمد (موجه) نیست.
یک روش دیگر برای در نظر گرفتن موارد فوق؛ اضافه کردن یک جدول برای درج ورژنها به الگوی Update است که در شکل زیر نشان داده شده است.
اضافه نمودن یک جدول تاریخچه، که تمامی تغییرات سیستم مبداء را ثبت میکند؛ نظارت و ممیزی دادهها را نیز فراهم میکند و همچنین بروزرسانیهای کارآمد مبتنی بر مجموعه را برای جداول DW به ارمغان میآورد.
3-4- Versioned Insert: Net Changes
این الگو غالباً در جداول حجیم Fact که بروزرسانی آنها پر هزینه است استفاده میشود. شکل زیر منطق استفاده شده در این الگو را نشان میدهد.
توجه داشته باشید در این الگو:
- مقادیر مالی و عددی محاسبه شده؛ به عنوان یک Net Change از نمونه قبلی رکورد در جدول Fact ذخیره میشود.
- هیچ گونه فعالیت Post Processing صورت نمیگیرد (از قبیل بروزرسانی جداول Fact پس از کامل شدن Data Flow). هدف استفاده از این الگو اجتناب از بروزرسانی روی جداول بسیار حجیم میباشد.
- عدم بروزرسانی و همچنین اندازه جدول Fact زمینه ای را فراهم میکند که منطق شناسائی رکوردهای تغییریافته پیچیده تر میشود. این پیچیدگی از آنجا ناشی میشود که نیاز به مقایسه رکوردهای جدول Fact آتی با جدول Fact موجود میباشد.
4- Data Integration Best Practices
هم اکنون پس از آشنایی با مفاهیم و الگوهای توزیع دادهها به ارائه تعدادی نمونه میپردازیم؛ که بتوان این ایدهها و الگوها را در عمل پوشش داد.
4-1- Basic Data Flow Patterns
هر یک از الگوهای Update Pattern و Versioned Insert Pattern میتوانند برای انواعی از جداول بکار روند که معروفترین آنها توسط Kimball ساخته شده اند.
- (Slowly Changing Dimension Type I (SCD I: از Update Pattern استفاده میکند.
- (Slowly Changing Dimension Type II (SCD II: از Versioned Insert Pattern استفاده میکند.
- Fact Table: نوع الگویی که استفاده میکند به نوع جدول Fact ای که Load خواهد شد بستگی دارد.
4-1-1- Update Pattern
مطابق تصویر زیر جدولی که تنها حاوی ورژن فعلی رکورد هاست؛ از Update Dataflow Pattern استفاده میکند.
مواردی که در مورد این گردش کاری باید در نظر داشت به شرح زیر است:
- این Data Flow فقط سطرهایی را به یک مقصد اضافه خواهد کرد. SSIS دارای گزینه “Table or view fast load” میباشد که بارگذاریهای انبوه و سریع را پشتیبانی میکند.
- درون یک Data Flow بروزرسانی رکوردها را میتوان با استفاده از تبدیل OLE DB Command انجام داد. توجه داشته باشید خروجیهای این تبدیل در یک دستور Update به ازای هر رکورد بکار میرود؛ مفهوم بروزرسانی انبوه در این Data Flow وجود ندارد. بدین ترتیب الگوی فعلی ارائه شده؛ تنها رکوردها را درج میکند و هرگز در این Data Flow رکوردها Update نمیشوند.
- هر جدول دارای یک جدول تاریخچه است که برای ذخیره همه فعالیتهای مرتبط با آن بکار میرود. یک رکورد در جدول تاریخچه زمانی درج خواهد شد؛ که رکورد مبداء در مقصد وجود داشته باشد ولی دارای مقداری متفاوت باشد.
- راه دیگر فرستادن تغییرات رکوردها به یک جدول کاری است که پس از پایان یافتن فرآیند Update ، خالی (Truncate) میشود.
- مزیت نگهداری تمامی رکوردها در یک جدول تاریخچه؛ ایجاد یک دنباله ممیزی است که میتواند برای نظارت بر دادهها به منظور نمایان ساختن موارد مطرح شده توسط مصرف کنندههای کسب و کار استفاده شود.
- گزینههای متفاوتی برای تشخیص تغییرات رکوردها وجود دارد که در ادامه به شرح آنها میپردازیم.
شکل زیر نمایش دهنده چگونگی پیاده سازی Update Dataflow Pattern در یک SSIS میباشد:
این SSIS شامل عناصر زیر است:
- Destination table lookup:
به منظور تشخیص اینکه رکورد در جدول مقصد وجود دارد از “lkpPersonContact” استفاده میکنیم.
- Change detection logic:
با استفاده از “DidRecordChange” مبداء و مقصد مقایسه میشوند. اگر تفاوتی بین مبداء و مقصد وجود نداشت؛ رکورد نادیده گرفته میشود. چنانچه بین مبداء و مقصد تفاوت وجود داشت؛ رکورد در جدول تاریخچه درج خواهد شد.
- Detection Inserts:
رکوردها در جدول مقصد درج خواهند شد در صورتیکه در آن وجود نداشته باشند.
- Destination History Inserts:
رکوردها در جدول تاریخچه مقصد درج خواهند شد، در صورتیکه (در مقصد) وجود داشته باشند.
پس از اتمام Data Flow یک روال Post-processing مسئولیت بروزرسانی رکوردهای جدول اصلی و رکوردهای ذخیره شده در جدول تاریخچه را بر عهده دارد که میتواند مطابق تصویر زیر با استفاده از یک Execute Process Task پیاده سازی شود.
PostProcess مسئولیت اجرای تمامی فعالیتهای زیر را در این الگو برعهده دارد که شامل:
- بروزرسانی رکوردهای جداول با استفاده از رکوردهای درج شده در جدول تاریخچه.
- درج تمامی رکوردهای جدید (نسخه اولیه و در درون جدول تاریخچه). کلید اصلی جداولی که ستون آنها IDENTITY است مقدار نامشخصی دارد؛ تا زمانی که درج صورت گیرد، این به معنای آن است که پیش از انتقال آنها به جدول تاریخچه نیاز است منتظر درج شدن آنها باشیم.
4-1-2- Update Pattern – ETL Framework
تصویر زیر بیانگر انجام این عملیات با استفاده از ابزارهای ETL است.
در نگاه نخستین ممکن است Data Flow از نوع اصلی خود پیچیدهتر به نظر آید؛ که در واقع این گونه نیز هست، زیرا در فاز توسعه بیشتر Frameworkها جهت پیاده سازی به یک زمان اضافهتری نیاز دارند. به هر روی این زمان جهت اجتناب از هزینه روزانه تطبیق دادهها گرفته خواهد شد.
مزایای حاصل شده از افزودن این منطق اضافی عبارت است از:
- پشتیبانی از ستون هایی که کارهای ممیزی و نظارت بر دادهها را آسانتر میکنند.
- تعداد سطرها شاخص مناسبی است که میتواند بهبود آن Data Flow خاص را فراهم کند. ناظر اطلاعات با استفاده از تعداد رکوردها میتواند ناهنجاریها را شناسائی کند.
بهره برداران ETL و ناظران اطلاعات میتوانند با استفاده از خلاصه تعداد رکوردها درک بیشتری درباره فعالیتهای آن کسب کنند. پس از آنکه تعداد رکوردها، مشکوک به نظر آمد؛ تحقیقات بیشتری میتواند اتفاق افتد. (با عمیقتر شدن در جزئیات گزارشات)
4-1-3- Versioned Insert Pattern
جدولی که به صورت Versioned Insert پر شده است میتواند از Versioned Insert Dataflow Pattern استفاده کند. همانند شکل زیر که گردش کار در آن برای کارآئی بیشتر بازنگری شده است.
توجه داشته باشید Data Flow در این روش شامل:
- تمامی رکوردهای جدید و تغییر یافته در جدول Versioned Insert قرار میگیرند.
- این روش دارای Data Flow سادهتری نسبت به الگوی Update میباشد.
شکل زیر SSIS versioned insert data flow pattern را نشان میدهد:
تعدادی نکته در Data Flow فوق وجود دارد که عبارتند از:
- در شیء “lkpDimGeography” گزینه “Redirect rows to no match output” با مقدار “Ignore Failures” تنظیم شده است.
- شیء “DidRecordChange” بررسی میکند چنانچه ستونهای مبداء و مقصد یکسان باشند، آیا کلید اصلی جدول مقصد Not Null است. اگر این عبارت True ارزیابی شود، رکورد نادیده گرفته میشود.
- منطق شناسائی تغییرات دربردارنده تغییرات ستون داده ای در مبداء نمیباشد.
- ستون و تعداد رکوردها مشابه با Data Flow قبلی (ETL Framework) میباشد.
4-1-4- Update vs. Versioned Insert
الگوی Versioned Insert نسبت الگوی Update دارای پیاده سازی سادهتر و فعالیتهای I/O کمتری است. از منظر دیگر، جدولی که از الگوی Update استفاده میکند، دارای تعداد رکوردهای کمتری است که میتواند به معنای Performance بهتر نیز تعبیر شود. ممکن است سوالی مطرح شود، اینکه چرا برای انجام کار به جدول تاریخچه نیاز است؛ این جدول را که نمیتوان Truncate نمود، پس چرا به منظور بروزرسانی از جدول اصلی استفاده میشود؟ پاسخ این پرسش در این است که جدول تاریخچه، ناظر اطلاعات و ممیزین داده را قادر میسازد، تغییرات در طول زمان را پیگیری نمایند.
4-2- Dimension Patterns
بروزرسانی Dimension موارد زیر را شامل میشود:
- پیگیری تاریخچه
- انجام بروزرسانی
- تشخیص رکوردهای جدید
- مدیریت surrogate keys
چنانچه با یک Dimension کوچک مواجه هستید (با مقدار هزاران رکورد یا کمتر، که با صدها هزار رکورد یا بیشتر ضدیت دارد)، میتوانید از تبدیل “Slowly Changing Dimension” که بصورت Built-in در SSIS موجود است، استفاده نمائید. به هر روی با آنکه این تبدیل چندین ویژگی محدودکننده Performance دارد، اغلب کارآمدتر از پروسسه هایی که توسط خودتان ایجاد میشود. در واقع فرآیند بارگذاری در جداول Dimension با مقایسه دادهها بین مبداء و مقصد انجام میشود. به طور معمول مقایسه روی یک ورژن جدید و یا مجموعه ای از سطرهای جدید یک جدول با مجموعه دادههای موجود در جدول متناظرش صورت میگیرد. پس از تشخیص چگونگی تغییر در داده ها، یک سری عملیات درج و بروزرسانی انجام میشود. شکل زیر نمونه ای از پردازش سریع در Dimension را نمایش میدهد؛ که شامل مراحل اساسی زیر است:
- منبع فوقانی سمت چپ، رکوردها را در یک SSIS از یک سیستم مبداء (یا یک سیستم میانی) به شکل Pull دریافت میکند. منبع فوقانی سمت راست، دادهها را از خود جدول Dimension به شکل Pull دریافت میکند.
- با استفاده از Merge Join رکوردها از طریق Source Key شان مقایسه میشوند. (در شکل بعدی جزئیات این مقایسه نمایش داده شده است.)
- با استفاده از یک Conditional Spilt دادهها ارزیابی میشوند؛ سطرها یا مستقیماً در جدول Dimension درج میشوند (منبع تحتانی سمت چپ) و یا در یک جدول عملیاتی (منبع تحتانی سمت راست) جهت انجام بروزرسانی درج میشوند.
- در گام پایانی (که نمایش داده نشده) مجموعه ای از بروزرسانی بین جدول عملیاتی و جدول Dimension صورت میگیرد.
با Merge Join ارتباطی بین رکوردهای مبداء و رکوردهای مقصد برقرار میشود. (در این مثال “CustomerAlternateKey”). هنگامی که از این دیدگاه استفاده میکنید، خاطر جمع شوید که نوع Join با مقدار “Left outer join” تنظیم شده است؛ بدین ترتیب قادر هستید تا رکوردهای جدید را از مبداء تشخیص دهید؛ از آنجا که هنوز در جدول Dimension قرار نگرفته اند.
گام پایانی به منظور تشخیص اینکه آیا رکورد، جدید یا تغییر یافته است (یا بلاتکلیف است)، مقایسه داده هاست. شکل زیر نمایش میدهد چگونه این ارزیابی با استفاده از تبدیل “Conditional Spilt” صورت میگیرد.
Conditional Spilt مستقیماً با استفاده از یک Adapter تعریف شده روی مقصد یا یک جدول کاری بروزرسانی که از یک Adapter تعریف شده روی مقصد استفاده میکند؛ توسط مجموعه دستور Update زیر، رکوردها را در جدول Dimension قرار میدهد. دستور Update زیر مستقیماً با استفاده از روش Join روی جدول Dimension و جدول کاری، مجموعه ای را بصورت انبوه بروزرسانی میکند.
UPDATE AdventureWorksDW2008R2.dbo.DimCustomer SET AddressLine1 = stgDimCustomerUpdates.AddressLine1 , AddressLine2 = stgDimCustomerUpdates.AddressLine2 , BirthDate = stgDimCustomerUpdates.BirthDate , CommuteDistance = stgDimCustomerUpdates.CommuteDistance , DateFirstPurchase = stgDimCustomerUpdates.DateFirstPurchase , EmailAddress = stgDimCustomerUpdates.EmailAddress , EnglishEducation = stgDimCustomerUpdates.EnglishEducation , EnglishOccupation = stgDimCustomerUpdates.EnglishOccupation , FirstName = stgDimCustomerUpdates.FirstName , Gender = stgDimCustomerUpdates.Gender , GeographyKey = stgDimCustomerUpdates.GeographyKey , HouseOwnerFlag = stgDimCustomerUpdates.HouseOwnerFlag , LastName = stgDimCustomerUpdates.LastName , MaritalStatus = stgDimCustomerUpdates.MaritalStatus , MiddleName = stgDimCustomerUpdates.MiddleName , NumberCarsOwned = stgDimCustomerUpdates.NumberCarsOwned , NumberChildrenAtHome = stgDimCustomerUpdates.NumberChildrenAtHome , Phone = stgDimCustomerUpdates.Phone , Suffix = stgDimCustomerUpdates.Suffix , Title = stgDimCustomerUpdates.Title , TotalChildren = stgDimCustomerUpdates.TotalChildren FROM AdventureWorksDW2008.dbo.DimCustomer DimCustomer INNER JOIN dbo.stgDimCustomerUpdates ON DimCustomer.CustomerAlternateKey = stgDimCustomerUpdates.CustomerAlternateKey
4-3- Fact Table Patterns
جداول Fact به پردازشهای منحصر به فردی نیازمند هستند، نخست به کلیدهای Surrogate جدول Dimension نیاز دارند تا Measureهای محاسبه شدنی را بدست آورند. این اعمال از طریق تبدیلات Lookup، Merge Join و Derived Column صورت میگیرد. با بروزرسانی ها، تفاضل رکوردها و یا Snapshot بیشتر این فرآیندهای دشوار انجام میشوند.
4-3-1- Inserts
روی اغلب جداول Fact عمل درج صورت میگیرد؛ که کار متداولی در جدول Fact میباشد. شاید سادهترین کار که در فرآیند ساخت ETL صورت میگیرد، عملیات درج روی تنها تعدادی از جدول Fact میباشد. درج کردن در صورت لزوم بارگذاری انبوه داده ها، مدیریت شاخصها و مدیریت پارتیشنها را شامل میشود.
4-3-2- Updates
بروزرسانی روی جداول Fact معمولاً به یکی از سه طریق زیر انجام میگیرد:
- از طریق یک تغییر یا بروزرسانی رکورد
- از طریق یک دستور Insert خنثی کننده (Via an Insert of a compensating transaction)
- با استفاده از یک SQL MERGE
در موردی که تغییرات با فرکانس کمی روی جدول Fact صورت میگیرد و یا فرآیند بروزرسانی قابل مدیریت است؛ سادهترین روش انجام یک دستور Update روی جدول Fact میباشد. نکته مهمی که هنگام انجام بروزرسانی باید به خاطر داشته باشید، استفاده از روش بروزرسانی مبتنی بر مجموعه است؛ به همان طریق که در قسمت الگوهای Dimension ذکر آن رفت.
در طریقی دیگر (درج compensating) میتوان اقدام به درج رکورد تغییر یافته نمود، تا ترجیحاً بروزرسانی روی آن صورت گیرد. این استراتژی به سادگی دادههای جدول Fact میان سیستم مبداء و مقصد را که تغییر یافته اند، به صورت یک رکورد جدید درج خواهد کرد. تصویر زیر مثالی از اجرای موارد فوق را نمایش میدهد.
در آخرین روش از یک دستور SQL MERGE استفاده میشود که در آن با استفاده از ادغام و مقایسه، تمامی دادههای جدید و تغییر یافته جدول Fact، درج و یا بروزرسانی میشوند. نمونه ای از استفاده دستور Merge به شرح زیر است:
MERGE dbo.FactSalesQuota AS T USING SSIS_PDS.dbo.stgFactSalesQuota AS S ON T.EmployeeKey = S.EmployeeKey AND T.DateKey = S.DateKey WHEN MATCHED AND BY target THEN INSERT(EmployeeKey, DateKey, CalendarYear, CalendarQuarter, SalesAmountQuota) VALUES(S.EmployeeKey, S.DateKey, S.CalendarYear, S.CalendarQuarter, S.SalesAmountQuota) WHEN MATCHED AND T.SalesAmountQuota != S.SalesAmountQuota THEN UPDATE SET T.SalesAmountQuota = S.SalesAmountQuota ;
4-3-3- Managing Inferred Members
زمانیکه یک ارجاع در جدول Fact به یک عضو Dimension که هنوز بارگذاری نشدهاست بوجود آید؛ یک Inferred Member تعبیر میشود. به سه طریق میتوان این Inferred Memberها را مدیریت نمود:
- رکوردهای جدول Fact پیش از درج اسکن شوند؛ ایجاد هر Inferred Member در Dimension و سپس بارگذاری رکوردها در جدول Fact
- در طول عملیات بارگذاری روی Fact؛ هر رکورد مفقوده شده به یک جدول موقتی ارسال شود، رکوردهای مفقوده شده به Dimension اضافه شود، در ادامه مجدداً آن رکوردهای Fact در جدول Fact بارگذاری شوند.
- در یک Data Flow زمانی که یک رکورد مفقود شده، بلاتکلیف تعبیر میشود؛ آن زمان یک رکورد به Dimension اضافه شود و Surrogate Key بدست آمده را برگردانیم؛ سپس Dimension بارگذاری شود.
شکل زیر این موارد را نمایش میدهد:
protected override IQueryable<BlogModel> BuildReadQuery(FilteredPagedQueryModel model) { return EntitySet.AsNoTracking().Select(b => new BlogModel {Id = b.Id, RowVersion = b.RowVersion, Url = b.Url, Title = b.Title}); }
- bit
- All integer types: tinyint, smallint, int, bigint
- All money types: money, smallmoney
- All floating types: float, real
- date/time types: datetime, smalldatetime, datetime2, date, time
- numeric and decimal types
- String types: char(n), varchar(n), nchar(n), nvarchar(n), sysname, varchar(MAX), nvarchar(MAX)
- Binary types: binary(n), varbinary(n), varbinary(MAX)
- Uniqueidentifier
در این مقاله چه چیزی را پوشش خواهیم داد:
· راه اندازی داکر
· پیکرهبندی container image
· وصل شدن به sql
· ساخت یک پروژه ساده net core.
· ایجاد دیتابیس
· ثبت رکورد در دیتابیس
قبل از هرچیز باید داکر را بر روی سیستم عامل خود (لینوکس) نصب نماید. چون نصب داکر بر روی لینوکس از حوصلهی این مقاله خارج میباشد، میتوانید با مراجعه به این لینک docker را نصب کنید. پس از نصب docker، برای اطمینان حاصل نمودن از نصب، با دستور docker version میتوان کانفیگ داکر را مشاهده کرد:
دانلود و نصب sql server بر روی داکر
قبل از هرچیز باید Image اسکیوال سرور را بر روی داکر دانلود نمائید. برای این کار وارد سایت dockerhub شوید و عبارت microsoft/mssql-server-linux را جستجو کنید.
همانطور که در تصویر نیز مشاهد میکنید، این بسته 10 میلیون بار دریافت شدهاست! در ادامه دستور زیر را در ترمینال خود Paste کنید و منتظر بمانید تا دانلود شود:
docker pull microsoft/mssql-server-linux:2017-latest
برای اجرای image sql از دستور زیر استفاده میکنیم:
sudo docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=<YourStrong!Passw0rd>' \ -p 1433:1433 --name sql1 \ -d mcr.microsoft.com/mssql/server:2017-latest
Set the SA_PASSWORD : پسورد environment variable ای که شما انتخاب میکنید.
p 1433:1433- : شماره پورتی که Docker container بر روی آن اجرا میشود.
-d microsoft/mssql-server-linux:2017-latest : نام Image ای که میخواهیم اجرا کنیم.
همانطور که ملاحظه میکنید، در قسمت status، عبارت up به معنای در حال اجرا بودن container است. اگر عبارت دیگری را مشاهده کردید، با دستور dockr start id و وارد کردن شماره image خود میتوانید آن را اجرا کنید.
تا اینجا توانستیم sql server را اجرا کنیم. برای توضیحات بیشتر به این لینک مراجعه کنید.
وصل شدن به sql
برای وصل شدن به دیتابیس باید connection string دیتابیس مربوطه را داشته باشیم. با توجه به کانفیگهایی که در بالا انجام دادیم، connection string ما به شکل زیر خواهد بود:
Server Host: localhost Port: 1433 Authentication: SQL Server Authentication Login: SA Password: <StrongPasswordYouSet>
sudo docker exec -it sql1 "bash"
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P '<YourNewStrong!Passw0rd>'
تا اینجای کار sql server آمادهی اجرا دستورات شما میباشد. در ادامه میخواهیم چند دستور سادهی sql را بر روی آن اجرا کنیم.
ساخت دیتابیس
با دستور sqlcmd زیر، ابتدا یک دیتابیس را میسازیم:
CREATE DATABASE TestDB
ساخت جدول
در ادامه، دستور زیر را برای ساخت جدول مینویسیم:
CREATE TABLE Inventory (id INT, name NVARCHAR(50), quantity INT)
ایجاد رکورد
مرحله بعدی، ایجاد یک رکورد جدید در دیتابیس میباشد:
INSERT INTO Inventory VALUES (1, 'banana', 150); INSERT INTO Inventory VALUES (2, 'orange', 154);
در آخر با استفاده از دستور go، کوئریهای بالا را اجرا میکنیم. اکنون باید یک دیتابیس جدید به نام TestDB و یک جدول جدید نیز به نام Inventory همچنین یک رکورد جدید در آن ثبت شده باشد. برای مشاهدهی تغییرات بالا، از دستورات زیر استفاده میکنیم:
- با دستور زیر لیست دیتابیسهای موجود را میتوان دید:
SELECT Name from sys.Databases
SELECT * FROM Inventory WHERE quantity > 152;
تا اینجا توانستیم docker را بر روی سیستم راه ندازی و همچنین sql server را بر روی آن نصب و اجرا کنیم. همچنین با دستورات sqlcmd توانستیم بر روی sql کوئری بزنیم.
ساخت و وصل شدن یک پروژهی net core. و وصل شدن به sql server
حال میخواهیم با یک پروژهی سادهی net core. به sql server فوق وصل شده و یک جدول را به دیتابیس مذکور اضافه کرده و یک کوئری اضافه کردن رکوردی را به آن جدول بنویسیم. برای شروع، یک پروژهی خالی net core. را ایجاد میکنیم. برای مثال یک پروژهی api را ایجاد میکنیم:
dotnet new webapi -o dockerapi
dotnet add package Microsoft.EntityFrameworkCore.SqlServer dotnet add package Microsoft.EntityFrameworkCore.Design
public class Students { public int Id { get; set; } public string Name { get; set; } public string Phone { get; set; } }
dotnet ef dbcontext scaffold "Server=localhost,1433\\Catalog=tutorial_database;Database=<YOUR_DATABASE_NAME>;User=SA;Password=<StrongPasswordYouSet>;" Microsoft.EntityFrameworkCore.SqlServer
"ConnectionStrings": { "TestingDatabase": "Server=localhost:1433\\Database=<YourDatabaseName>;User=SA;Password=<StrongPasswordYouSet>;" }
dotnet ef migrations add <NAME_OF_MIGRATION>
همانطور که مشاهده میکنید، migrations اضافه شده و موجودیت هم اضافه شدهاست. حال باید بر روی migrations خود آپدیت بزنیم:
ef database update
SELECT TABLE_NAME FROM dockerdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE'
ایجاد فرم لاگین
فرم لاگینی را که به برنامهی نمایش لیست فیلمهای تکمیل شدهی تا قسمت 17، اضافه خواهیم کرد، یک فرم بوت استرپی است و میتوانید جزئیات بیشتر مزین سازی المانهای این نوع فرمها را با کلاسهای بوت استرپ، در مطلب «کار با شیوهنامههای فرمها در بوت استرپ 4» مطالعه کنید.
در ابتدا فایل جدید src\components\loginForm.jsx را ایجاد کرده و سپس توسط میانبرهای imrc و cc در VSCode، ساختار ابتدایی کامپوننت جدید LoginForm را ایجاد میکنیم:
import React, { Component } from "react"; class LoginForm extends Component { render() { return <h1>Login</h1>; } } export default LoginForm;
import LoginForm from "./components/loginForm"; //... function App() { return ( <React.Fragment> <NavBar /> <main className="container"> <Switch> <Route path="/login" component={LoginForm} /> <Route path="/movies/:id" component={MovieForm} /> // ... </Switch> </main> </React.Fragment> ); }
<NavLink className="nav-item nav-link" to="/login"> Login </NavLink>
اکنون نوبت به افزودن فرم بوت استرپی لاگین به فایل loginForm.jsx رسیدهاست:
import React, { Component } from "react"; class LoginForm extends Component { render() { return ( <form> <div className="form-group"> <label htmlFor="username">Username</label> <input id="username" type="text" className="form-control" /> </div> <div className="form-group"> <label htmlFor="password">Password</label> <input id="password" type="password" className="form-control" /> </div> <button className="btn btn-primary">Login</button> </form> ); } } export default LoginForm;
- ابتدا المان form به صفحه اضافه میشود.
- سپس هر ورودی، داخل یک div با کلاس form-group، محصور میشود. کار آن تبدیل یک برچسب و فیلد ورودی، به یک گروه از ورودیهای بوت استرپ است.
- در اینجا هر برچسب دارای یک ویژگی for است. اما چون قرار است عبارات jsx، به معادلهای جاوا اسکریپتی ترجمه شوند، نمیتوان از واژهی کلیدی for در اینجا استفاده کرد. به همین جهت از معادل react ای آن که htmlFor است، در کدهای فوق استفاده کردهایم؛ شبیه به نکتهای که در مورد تبدیل ویژگی class به className وجود دارد. مقدار هر ویژگی htmlFor نیز به id فیلد ورودی متناظر با آن تنظیم میشود. به این ترتیب اگر کاربر بر روی این برچسب کلیک کرده و آنرا انتخاب کند، فیلد متناظر با آن، دارای focus میشود.
- فیلدهای ورودی نیز دارای کلاس form-control هستند.
با این خروجی نهایی در مرورگر:
مدیریت ارسال فرمها
به صورت پیش فرض و استاندارد، دکمهی افزوده شدهی به المان form، سبب ارسال اطلاعات آن به سرور و سپس بارگذاری کامل صفحه میشود. این رفتاری نیست که در یک برنامهی SPA مدنظر باشد. برای مدیریت این حالت، میتوان از رخداد onSubmit هر المان فرم، استفاده کرد:
class LoginForm extends Component { handleSubmit = e => { console.log("handleSubmit", e); e.preventDefault(); // call the server }; render() { return ( <form onSubmit={this.handleSubmit}> //...
دسترسی مستقیم به المانهای فرمها
پس از فراخوانی متد preventDefault، کار مدیریت ارسال فرم به سرور را باید خودمان مدیریت کنیم و دیگر رخداد full post back استاندارد به سمت سرور را نخواهیم داشت. در جاوا اسکریپت خالص برای دریافت مقادیر وارد شدهی توسط کاربر میتوان نوشت:
const username = document.getElementById("username").value;
برای دسترسی به یک المان DOM در React، باید یک reference را به آن نسبت داد. برای این منظور یک خاصیت جدید را در سطح کلاس کامپوننت، ایجاد کرده و آنرا با React.RefObject، مقدار دهی اولیه میکنیم:
class LoginForm extends Component { username = React.createRef();
<input ref={this.username} id="username" type="text" className="form-control" />
handleSubmit = e => { e.preventDefault(); // call the server const username = this.username.current.value; console.log("handleSubmit", username); };
class LoginForm extends Component { username = React.createRef(); componentDidMount = () => { this.username.current.focus(); };
البته روش بهتری نیز برای انجام اینکار وجود دارد. المانهای JSX دارای ویژگی autoFocus نیز هستند که دقیقا همین کار را انجام میدهد:
<input autoFocus ref={this.username} id="username" type="text" className="form-control" />
تبدیل المانهای فرمها به Controlled elements
در بسیاری از اوقات، فرمهای ما state خود را از سرور دریافت میکنند. فرض کنید که در حال ایجاد یک فرم ثبت اطلاعات فیلمها هستیم. در این حالت باید بر اساس id فیلم، اطلاعات آن را از سرور دریافت و در state ذخیره کرد؛ سپس فیلدهای فرم را بر اساس آن مقدار دهی اولیه کرد. برای نمونه در فرم لاگین میتوان state را با شیء account، به صورت زیر مقدار دهی اولیه کرد:
class LoginForm extends Component { state = { account: { username: "", password: "" } };
ابتدا ویژگی value فیلد برای مثال username را به خاصیت username شیء account موجود در state متصل میکنیم:
<input value={this.state.account.username}
<input value={this.state.account.username} onChange={this.handleChange}
handleChange = e => { const account = { ...this.state.account }; //cloning an object account.username = e.currentTarget.value; this.setState({ account }); };
مدیریت دریافت اطلاعات چندین فیلد ورودی
تا اینجا موفق شدیم اطلاعات state را به تغییرات فیلد username در فرم لاگین متصل کنیم؛ اما فیلد password را چگونه باید مدیریت کرد؟ برای اینکه تمام این مراحل را مجددا تکرار نکنیم، میتوان از مقدار دهی پویای خواص در جاوا اسکریپت که توسط [] انجام میشود استفاده کرد:
handleChange = e => { const account = { ...this.state.account }; //cloning an object account[e.currentTarget.name] = e.currentTarget.value; this.setState({ account }); };
<input id="password" name="password" value={this.state.account.password} onChange={this.handleChange} type="password" className="form-control" />
یک نکته: میتوان توسط Object Destructuring، تکرار e.currentTarget را حذف کرد:
handleChange = ({ currentTarget: input }) => { const account = { ...this.state.account }; //cloning an object account[input.name] = input.value; this.setState({ account }); };
آشنایی با خطاهای متداول دریافتی در حین کار با فرمها
فرض کنید خاصیت username را از شیء account موجود در state حذف کردهایم. در زمان نمایش ابتدایی فرم، خطایی را دریافت نخواهیم کرد، اما اگر اطلاعاتی را در آن وارد کنیم، بلافاصله در کنسول توسعه دهندگان مرورگر چنین اخطاری ظاهر میشود:
Warning: A component is changing an uncontrolled input of type text to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component. More info: https://fb.me/react-controlled-components
دقیقا چنین اخطاری را با ورود null/undefined بجای "" در حین مقدار دهی اولیهی username در شیء account نیز دریافت خواهیم کرد:
Warning: `value` prop on `input` should not be null. Consider using an empty string to clear the component or `undefined` for uncontrolled components.
ایجاد یک کامپوننت ورود اطلاعات با قابلیت استفادهی مجدد
هر چند در پیاده سازی فعلی سعی کردیم با بکارگیری مقداردهی پویای خواص اشیاء، تکرار کدها را کاهش دهیم، اما باز هم به ازای هر فیلد ورودی باید این مسایل تکرار شوند:
- ایجاد یک div با کلاسهای بوت استرپی.
- ایجاد label و همچنین فیلد ورودی.
- در اینجا مقدار htmlFor باید با مقدار id فیلد ورودی یکی باشد.
- مقدار دهی ویژگیهای value و onChange نیز باید تکرار شوند.
بنابراین بهتر است این تعاریف را استخراج و به یک کامپوننت با قابلیت استفادهی مجدد منتقل کرد. به همین جهت فایل جدید src\components\common\input.jsx را در پوشهی common ایجاد کرده و سپس توسط میانبرهای imrc و sfc، این کامپوننت تابعی بدون حالت را تکمیل میکنیم:
import React from "react"; const Input = ({ name, label, value, onChange }) => { return ( <div className="form-group"> <label htmlFor={name}>{label}</label> <input value={value} onChange={onChange} id={name} name={name} type="text" className="form-control" /> </div> ); }; export default Input;
سپس به کامپوننت فرم لاگین بازگشته و ابتدا آنرا import میکنیم:
import Input from "./common/input";
render() { const { account } = this.state; return ( <form onSubmit={this.handleSubmit}> <Input name="username" label="Username" value={account.username} onChange={this.handleChange} /> <Input name="password" label="Password" value={account.password} onChange={this.handleChange} /> <button className="btn btn-primary">Login</button> </form> );
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-18.zip
public class CustomerInfo { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public DateTime BirthDate { get; set; } }
public interface IModelBinder { object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext); }
using System; using System.Web; using System.Web.Mvc; using ModelBinderExample.Models; using Persia; namespace ModelBinderExample.CustomModelBinder { // Article written for www.dotnettips.info public class CustomerInfoModelBinder : IModelBinder { public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { HttpRequestBase request = controllerContext.HttpContext.Request; string firstName = request.Form.Get("FirstName"); string lastName = request.Form.Get("LastName"); DateTime birthDate = this.GetMiladiDate(request); return new CustomerInfo() { FirstName = firstName, LastName = lastName, BirthDate = birthDate }; } private DateTime GetMiladiDate(HttpRequestBase request) { int day = int.Parse(request.Form.Get("Day")); int month = int.Parse(request.Form.Get("Month")); int years = int.Parse(request.Form.Get("Years")); //Convert shamsi to miladi return Persia.Calendar.ConvertToGregorian(years, month, day, DateType.Gerigorian); } } }
protected void Application_Start() { AreaRegistration.RegisterAllAreas(); WebApiConfig.Register(GlobalConfiguration.Configuration); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); //Register New ModelBinder ModelBinders.Binders.Add(typeof(CustomerInfo), new CustomerInfoModelBinder()); }
[HttpPost] public ActionResult Create([ModelBinder(typeof (CustomerInfoModelBinder))] CustomerInfo customerInfo) { if (ModelState.IsValid) { ViewBag.FirstName = customerInfo.FirstName; ViewBag.LastName = customerInfo.LastName; ViewBag.BirthDate = customerInfo.BirthDate; } return View(); }
SASS #2
متغیرها (Variables)
متغیرها در SASS با استفاده از $ در ابتدای نام آن، به عنوان یک مقدار مورد استفادهی در CSS تعریف میشوند. شما در SASS میتوانید متغیرهایی را برای margin ،font-size و یا padding و غیره، تعریف کنید. استفاده از متغیرها این امکان را به شما میدهد که خیلی راحتتر از styleهای تعریف شده، مجدد استفاده کنید.
شما 6 نوع مختلف متغیر را میتوانید با استفاده از SASS بکار ببرید.
- Strings (مثال: ;"myString: "your text here$ )
- Numbers (مثال: ;myNum: 16px$)
- Colors (مثال: ;myColor: aqua$)
- Booleans (مثال: ;myBool: true$)
- Lists (مثال: ;myItemList: 1px solid red$)
- Nulls (مثال: ;myVar: null$)
برای مثالی از استفادهی از این متغیرها، یک فایل را با نام styles.scss ایجاد کرده و کدهای زیر را در آن وارد کنید:
$myColor: #FFF726; $myBackColor: #2B14FF; $myString: "I Love "; $myFontSize: 13px; $myMargin: 0px auto; $myWidth: 300px; h1 { color: $myColor; margin: 0; padding: 0; } h1:before{ content: $myString; } #container { width: $myWidth; margin: $myMargin; background-color:$myBackColor; text-align:center; }
ریاضی (Math)
برخلاف SASS ،CSS به ما امکان استفاده از عبارات ریاضی را میدهد. عملگرهای جمع + ، تفریق - ، تقسیم / ، ضرب * ، باقیمانده % ، مساوی == ، نامساوی =! را SASS پشتیبانی میکند. در هنگام استفاده از عبارات ریاضی چند نکته وجود دارد که باید رعایت کنید:
نکته1: چون علامت / در CSS به عنوان یک کوتاه کننده استفاده میشود مانند font: 14px/16px، در صورتیکه بخواهید عمل تقسیم را بر روی مقدار ثابتی انجام دهید باید آنها را درون پرانتر قرار دهید.
$fontDiff: (14px/16px);
$container-width: 100% - 20px;
حال میخواهیم براساس عرض container، ستونهای پویایی را ایجاد کنیم:
$container-width: 100%; .container { width: $container-width; } .col-4 { width: $container-width / 4; }
.container { width: 100%; } .col-4 { width: 25%; }
مشاهدهی پیاده سازی مثال بالا اینجا.
توابع (Functions)
یکی از بهترین قسمتهای SASS، توابع پیاده سازی شدهی آن است. شما میتوانید لیست بزرگی از توابع SASS را در اینجا مشاهده کنید.برای نمونه برخی از توابع مربوط به کار با رنگها را توضیح میدهیم:
- (darken ($color, $amount: این تابع برای تیرهتر کردن یک کد رنگ میباشد. شما برای استفادهی از این تابع باید دو مقدار را به آرگومانهای ورودی این تابع که به ترتیب کد رنگ و میزان تیرهتر شدن آن به صورت درصد از %0 تا %100 میباشند، ارسال کنید و خروجی آن کد رنگ تولید شده است. توجه داشته باشید نوع سیستم رنگی ارسال شده به عنوان پارامتر color$، خروجی این تابع نیز همان نوع میباشد.
darken(hsl(25, 100%, 80%), 30%) => hsl(25, 100%, 50%) darken(#800, 20%) => #200
- (lighten ($color, $amount: این تابع برای روشنتر کردن یک رنگ میباشد و دقیقا برعکس تابع darken عمل میکند.
lighten(hsl(0, 0%, 0%), 30%) => hsl(0, 0, 30) lighten(#800, 20%) => #e00
- (alpha ($color) / opacity($color: با استفاده از این دو تابع میتوانید میزان شفافیت/کدری را مشخص کنید.
- (mix ($color1, $color2, $weight:50% : با استفاده از این تابع
میتوانید دو رنگ را با هم ترکیب کنید. مقدار پیش فرض آرگومان weight$
برابر %50 میباشد و تعیین آن اختیاری است. محدودهی پذیرش مقدار weight$
هرچه به %0 نزدیکتر باشد، باعث نزدیکتر بودن رنگ خروجی به رنگ دوم و
هرچه به %100 نزدیکتر باشد رنگ خروجی به رنگ اول نزدیکتر میشود. توجه:
میزان شفافیت/کدری را نیز میتواند تشخیص دهد.
mix(#f00, #00f) => #7f007f mix(#f00, #00f, 25%) => #3f00bf mix(rgba(255, 0, 0, 0.5), #00f) => rgba(63, 0, 191, 0.75)
تو در تو (Nesting)
SASS امکان تعریف استایلهای تو در تو را به شما میدهد که باعث خواناتر شدن استایلهای نوشته شده میشود. به عنوان مثال به کد CSS زیر توجه کنید:
#container { width: 500px; margin: 0 auto; } #container p { font-family: Arial; font-size: 13px; } #container h1 { font-family: Tahoma; font-size: 15px; } #container h2 { font-family: Helvetica; font-size: 14px; }
$myFontsize1: 13px; $myFontsize2: 18px; $myFontsize3: 25px; $myWidth: 500px; $myMargin: 0px auto; #container { width: $myWidth; margin: $myMargin; p { font-family: Arial; font-size: $myFontsize1; } h1 { font-family: Tahoma; font-size: $myFontsize3; } h2 { font-family: Helvetica; font-size: $myFontsize2; } }
در صورتیکه نیاز به دسترسی به والد داشته باشید کافیست از علامت & استفاده کنید.
a.myAnchor { color: blue; &:hover { text-decoration: underline; } &:visited { color: purple; } }
at-root@
قبل استایلی که میخواهید به صورت تو در تو تعریف نشود، استفاده کنید..first-component { .text { font-size: 1.4em; } .button { font-size: 1.7em; } .second-component { .text { font-size: 1.2em; } .button { font-size: 1.4em; } } }
.first-component .text { font-size: 1.4em; } .first-component .button { font-size: 1.7em; } .first-component .second-component .text { font-size: 1.2em; } .first-component .second-component .button { font-size: 1.4em; }
at-root@
به صورت زیر میشود:.first-component .text { font-size: 1.4em; } .first-component .button { font-size: 1.7em; } .second-component .text { font-size: 1.2em; } .second-component .button { font-size: 1.4em; }
و اگر از ویندوز سرور استفاده میکنید، باید Application Initialization را در قسمت Application Development فعال کنید:
- Open the Add Roles and Features Wizard. - In the Select role services panel, open the Application Development node. - Select the checkbox for Application Initialization.
سپس به تنظیمات application pool برنامه مراجعه کرده و دو تغییر زیر را اعمال کنید:
Start Mode -> AlwaysRunning Idle Time-Out (minutes) -> 0
Connections panel -> Sites node -> Right-click the app -> Manage Website > Advanced Settings -> Set Preload Enabled -> True