مدیریت ارتباطات مشتری – CCM
راهنمای طراحی PPM
Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects, you can leverage NuGet’s central package management features to do all of this from the ease of a single location.
ایجاد helper برای Nivo Slider در Asp.net Mvc
Today, we’re excited to introduce GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code.
GitHub Package Registry is fully integrated with GitHub, so you can use the same search, browsing, and management tools to find and publish packages as you do for your repositories. You can also use the same user and team permissions to manage code and packages together. GitHub Package Registry provides fast, reliable downloads backed by GitHub’s global CDN. And it supports familiar package management tools: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), and Docker images, with more to come.
مقدمه
در سازمان ها، دادهها و اطلاعات معمولاً به دو شکل در سیستمها پیاده سازی میگردد:
• سیستمهای عملیاتی OLTP:
این سیستمها باعث میگردند تا چرخ کسب و کار بگردد. وجود این سیستمها سبب میشود تا دادههای مربوط به کسب و کار، به بانک اطلاعاتی وارد شوند. این سیستمها عموماً:
o به دلیل کوتاهی عملیات دارای سرعت قابل توجهی میباشند.
o محیطی جهت ورود دادهها میباشند.
o معمولاً اپراتورها، استفاده کنندههای آن هستند.
• سیستمهای اطلاعاتی OLAP ، DW/BI، DSS :
این سیستمها باعث میگردند تا چرخش کسب و کار را بنگرید. فلسفه بکارگیری این سیستمها در سازمان این است که اطلاعات مورد نیاز مدیران، از درون دادههای سیستمهای عملیاتی موجود، استخراج گردد. این سیستمها عموماً:
سیستمهای عملیاتی در جامعه ما سابقه بیشتری داشته و متخصصین فناوری اطلاعات عموماً با طراحی و تولید چنین سیستم هایی آشنایی کافی دارند. متاسفانه جایگاه سیستمهای اطلاعاتی در جامعه ما کمتر شناخته شده و متخصصین فناوری اطلاعات بندرت با مفاهیم و نحوه پیاده سازی آن آشنایی دارند.o به دلیل آنالیز حجم انبوهی از داده ها، معمولاً کندتر از سیستمهای عملیاتی میباشند.
o محیطی جهت تولید گزارشات تحلیلی و آماری میباشند.
o معمولاً مدیران و تصمیم گیرندگان سازمان ها، استفاده کنندگان آن میباشند.
این نکته حائز اهمیت است که سیستمهای اطلاعاتی یک سیستم یا محصول نیستند که بتوان آنها را خریداری کرد. بلکه یک راهبرد (Solution, Approach) هستند و در حقیقت هر راهبردی مربوط به یک نوع کسب و کار (Business) و یا سازمان میباشد و نمیتوان فرمول واحدی را برای حتی سازمانهای مشابه، ارائه نمود.
گارتنر در ابتدای سال 2011 گزارشی را منتشر کرده که نشان میدهد بازار BI با 9.7 % رشد، ارزشی بالغ بر 10.8 بیلیون دلار داشته، ولی متاسفانه پروژههای آن به طور متوسط با 75% شکست مواجه شده است. در حالیکه 4 سال پیش، این رقم حدود 50% بود. این موسسه BI را پنجمین اولویت مدیران IT ذکر کرده است.
مفاهیم و مباحث مربوط به Data Warehouse به اواسط دهه 1980 برمی گردد، به زمانی که IBM تحقیقاتی را در این زمینه شروع کرد و نتیجه آنرا «Information Warehouse» نامید و هنوز هم در برخی منابع از این واژه بجای Data Warehouse استفاده میشود. از این پس برای راحتی از اختصار DW بجای Data Warehouse استفاده میشود. انبارهای داده جهت رفع نیاز رو به رشد مدیریت دادهها و اطلاعات سازمانی که توسط پایگاههای داده سیستمهای عملیاتی غیر ممکن بود، ساخته شدند.
انبار داده به مجموعه ای از دادهها گفته میشود که از منابع مختلف اطلاعاتی سازمان جمع آوری، دسته بندی و ذخیره میشود. در واقع یک انبار داده مخزن اصلی کلیه دادههای حال و گذشته یک سازمان میباشد که برای همیشه جهت انجام عملیات گزارش گیری و آنالیز در دسترس مدیران میباشد. انبارههای داده حاوی داده هایی هستند که به مرور زمان از سیستمهای عملیاتی آنلاین سازمان، استخراج میشوند. بنابراین سوابق کلیه اطلاعات و یا بخش عظیمی از آنها را میتوان در انباره دادهها مشاهده نمود.
از آنجائیکه انجام عملیات آماری و گزارشات پیچیده دارای بار کاری بسیار سنگینی برای سرورهای پایگاه داده میباشند، وجود انبار داده سبب میگردد که این گونه عملیات تاثیری بر فعالیت برنامههای کاربردی سازمان نداشته باشد.
همانگونه که پایگاه داده سیستمهای عملیاتی سازمان (برنامههای کاربردی) به گونه ای طراحی میشوند که انجام تغییر، حذف و اضافه داده به سرعت صورت پذیرد، در مقابل انبار دادهها دارای معماری ویژه ای میباشند که موجب تسریع انجام عملیات آماری و گزارش گیری میشود. در حقیقت میتوان اینگونه بیان نمود که انباره داده یک مخزن فعال و هوشمند از اطلاعات است که قادر است اطلاعات را از محیطهای گوناگون جمع آوری و مدیریت کرده و نهایتا پخش نماید و در صورت لزوم نیز سیاستهای تجاری را روی آنها اجرا نماید.
Bill Inmon:
او را پدر DW مینامند، از دیدگاه او DW هسته مرکزی چیزی است که او آنرا CIF اختصار (Corporate Information Factory) مینامد، که پایه و اساس BI بر مبنای آن قرار دارد. وی از طرفداران Top-Down Design میباشد که معتقد است در زمان طراحی باید با دیدی سازمانی، CIF را مدل سازی، ولی بصورت دپارتمانی پیاده سازی کرد (Think Globally, Implement Locally). در این نوع طراحی از DW به Data Mart خواهیم رسید.
Ralph Kimball Ph.D:
به نظر وی DW چیزی نیست جز یک کپی از دادههای عملیاتی که به طرز خاصی برای گزارشات و تحلیلهای آماری، آماده و ساختمند شده است. به بیان دیگر DW سیستمی است جهت استخراج، پالایش، تطبیق و تحویل اطلاعات منابع داده ای به یک بانک اطلاعاتی Dimensional و اجرای Query و گزارشات آماری و تحلیلی برای اهداف تصمیم گیری و استراتژیک سازمان.
وی معرفی کننده یکی از اساسیترین مفاهیم طراحی یعنی Dimensional Modeling است؛ ماحصل چنین ایده ای، اساس شکل گیری مدلی است که امروزه کارشناسان آنرا به نام Cube میشناسند. وی از طرفداران Bottom-Up Design است که در این نگرش از Data Mart به DW میرسیم. این روش به نظر عملیتر از روشی میباشد که به یکباره DW جامع و کامل برای اهداف سازمانی طراحی و پیاده سازی گردد.
تعریف انبار داده:
W.H.Inmon پدر DW آنرا چنین تعریف میکند:
o انبار داده به طور فیزیکی، کاملاً جدا از سایر سیستمهای عملیاتی است.
o دادههای DW مجموعه ای Aggregated و Atomic از دادههای تراکنشهای سیستمهای عملیاتی است که سوای کاربرد آنها در سیستمهای عملیاتی، برای مقاصد مدیریتی نیز استفاده خواهد شد.
به بیان دیگر DW راهبردی است که دسترسی آسان به اطلاعات درست (Right Information)، در زمانی درست (Right Time) ، به کاربران درست (Right Users)، را فراهم میآورد تا «تصمیم گیری سازمانی» قابل انجام باشد. DW صرفاً یک محصول نرم افزاری و یا سخت افزاری نیست که بتوان آنرا خریداری نمود بلکه فراتر از آن و در حقیقت یک محیط پردازشی میباشد که کاربران میتوانند از درون آن اطلاعات مورد نیاز خود را بیابند.
DW اطلاعات خود را از سایر بانکهای اطلاعاتی از نوع OLTP و یا سایر DWهای لایه پایینتر و به صورت دسته ای (Batch) و یا انبوه (Bulk Loading) جمع آوری میکند. یک DW به صورت سنتی باید شامل دادههای Historic سازمان باشد و میتوان اینگونه بیان نمود که در DW هرچه دادههای قدیمیتری موجود باشد، اعتبار تحلیلهای آماری سیستم افزایش خواهد یافت.
دادههای سیستم عملیاتی را نمیتوان بلافاصله درون بانک اطلاعاتی DW لود نمود، چنین داده هایی باید آماده سازی، پالایش و همگون گردند تا شرایط لود در DW را داشته باشند. حداقل کاری که انتظار داریم یک DW در مورد دادهها برای ما برآورده سازد شامل موارد زیر است:
o استخراج دادهها از منابع مختلف (مبدإ)با هر با اجرای پروسه فوق یکی از سه مورد زیر، بسته به نیاز طراحی و محدودیتهای تکنولوژی رخ خواهد داد:
o تبدیل دادهها به فرمتی یکسان
o لود دادهها به جداول مربوطه (مقصد)
o تمام دادهها در DW با دادههای جدید جایگزین خواهند گردید(Full Load, Initial Load, Full Refresh).
o دادههای جدید به دادههای موجود اضافه خواهند گردید (Incremental Load (Inserted data.
o نسخه جدیدی از دادههای کنونی به سیستم اضافه خواهند گردید (Incremental Load (Updated data.
ویژگیهای دادههای درون DW
دادههای DW از نگاه Inmon دارای 4 ویژگی اصلی زیر هستند:
o فقط خواندنی (Non-Volatile):
هیچ رکوردی و یا داده ای Update نخواهد شد و صرفاً رکوردهایی که محتوای مقادیر جدید دادهها هستند، به سیستم اضافه خواهند شد.
o موضوع گرا (Subject-Oriented):
منظور از «موضوع» پایههای اساسی یک کسب و کار هستند، به شکلی که با حذف یکی از این پایه ها، شاید ماهیت آن کسب و کار از ریشه دگرگون شود. برای مثال موضوعاتی چون «مشتری» و یا «بیمه نامه» برای شرکتهای بیمه.
o جامع (Integrated):
باید تمامی کدهایی که در سیستمهای عملیاتی وجود دارند و معانی یکسانی دارند، برای مثال کد جنسیت، در DW به یک روش ذخیره و نمایش داده شوند.
o زمانگرا (Time Variant):
هر رکورد باید حاوی فیلد و یا کلیدی باشد که نمایانگر این باشد که این رکورد در چه زمانی ایجاد، استخراج و ذخیره شده است. از آنجا که دادههای درون سیستمهای عملیاتی آخرین و به روزترین داده هر سیستم میباشد، نیازی به وجود چنین عنصری در سیستمهای OLTP احساس نمیگردد، ولی چون در DW تمام دادههای نسخ قدیمی دادههای سیستمهای عملیاتی موجود میباشد، باید حتماً مشخص گردد که هر داده ای در سیستمهای عملیاتی در چه زمانی، چه مقادیری داشته است. این عنصر زمانی کمک میکند تا بتوانیم:
منبع: کتاب آقای خشایار جام سحر با عنوان بانک داده تجمیعیo گذشته را آنالیز کنیم.
o اطلاعات مربوط به حال حاضر را بدست آوریم.
o آینده را پیش بینی کنیم.
Inmon
Continuous & Discrete Dimension Management
Define data management via dates in your data
Continuous time
When is a record activeDiscrete time
Start and end dates
A point in time
Snapshot
Kimball
Slowly Changing Dimension Management
Define data management via versioning
Type I
Change record as requiredType II
No History
Manage all changesType III
History is recorded
Some history is parallel
Limit to defined history
Kimball | Inmon |
Business-Process-Oriented Stresses Dimensional Model, Not E-R | Subject-Oriented Integrated Non-Volatile Time-Variant |
Bottom-Up and Evolutionary | Top-Down |
Integration Achieved via Conformed Dimensions | Integration Achieved via an Assumed Enterprise Data Model |
Star Schemas Enforce Query Semantics | Characterizes Data marts as Aggregates |
Kimball | Inmon | |
Bottom-up | Top-down | Overall approach |
Data marts model a business process;enterprise is achieved with conformed dims | Enterprise-wide DW feeds departmental DBs | Architectural structure |
Fairly simple | Quite complex | Complexity of method |
Process oriented | Subject or data driven | Data orientation |
Dimensional modeling; departs from traditional relational modeling | Traditional ERDs and DIS | Tools |
High | Low | End user accessibility |
Slowly Changing | Continuous & Discrete | Timeframe |
Dimension keys | Timestamps | Methods |