Dimension Surrogate Key کلید جانشین
در جداول Dimension یک فیلد بایستی بعنوان کلید اصلی primary key معرفی گردد تا بعنوان Foreign Key در جداول Fact مرتبط با آن استفاده گردد .

کلید طبیعی( natural key) نمی تواند بعنوان primary key انتخاب گردد . به چند دلیل :

- عدم وابستگی کلید اصلی به قوانین کسب و کار سیستم های عملیاتی که در بالا به تفضیل توضیح داده شد .
- اگر بخواهیم تغییرات یک ویژگی موجود در یک جدول Dimension را در طول زمان ردیابی کنیم
( مثلا محل خدمت پرسنل در جدول DimEmployee ) ممکن هست چند رکورد ( اصطلاحا میگیم ورژن ) با مقدار natural key یکسان ایجاد شود ( SCD Type 2 ) .

- ممکن هست جدول Dimension مقادیر خود را از چند سیستم عملیاتی مختلف بگیرد که ابن امر ممکن موجب شود کلیدهای طبیعی ناسازگار گردیده ( مثلا data type های مختلف داشته باشند ) و یا تکراری باشند .

راه حل
برای اینکه در طول حیات DW کلید های اصلی جداول Dimension تحت کنترل سیستم DW باشند میتوان از همان روش ساده مرسوم استفاده کرد و از روش های پیچیده اجتناب کرد . یک فیلد جدید با Data Type از نوع integer ایجاد میکنیم که با مقدار یک شروع شده و بصورت متوالی افزایش یابد و پیچیدگی ها را به سیستم ETL انتقال میدهیم . البته در جداول کلید های طبیعی رو هم بعنوان یک ویژگی در جداول Dimension میاوریم

این کلید اصلی جدید ( و مستقل ) کلید جانشن Surrogate Key نامیده میشود .
در سیستم های ETL و در فاز Load میتوان بااستفاده از کلید طبیعی جدوال Fact را با مقادیر کلید های جانشین load کرد .

یکی از اهداف سیستم های DW/BI نمایش صحیح تاریخچه (history) اطلاعات میباشد . مثلا اگر در زمان های مختلف از یک بازه زمانی خاص گزارش ( مثلا گزارش فروش بر اساس دپارتمانها ) بگیریم مقادیر مندرج در این گزارش نبایستی با گذشت زمان تغیبر یابد .

تکنیک SCD Type 2 جهت پشتیبانی از این نیازمندی ابداع گردیده است .

تخصص و ابزارهای لازم جهت پیاده سازی هوش تجاری در یک سازمان بزرگ @BIMining

5 موردی که درباره فین تک ها باید بدانید
@BIMining
معنی فین تک دقیقا چیست؟ چه شرکتها و سازمانهایی از آن استفاده می کنند؟ فین تک ها چه کاری میکنند؟ در چه موضوعاتی فین تک ها فعالیت دارند؟

هوش تجاری اجتماعی ( social business intelligence)

BI‌ اجتماعی (SBI) که با تعبیر هوش کسب و کار ۲ (BI 2.0) نیز شناخته می شود. سیستمی مبتنی بر وب است که با استفاده از تحلیل اطلاعات تولید شده توسط کاربران در رسانه‌های اجتماعی و سایر محتوای موجود در بستر وب، انواع گزارشات مرتبط با یک برند، محصول، کسب و کار، روند یا رخداد اجتماعی سیاسی و موارد مشابه را تولید می کند. در واقع SBI به مثابه پلی است که رهبران بنگاه ها و سازمان ها را به میان مشتریان و مصرف کنندگان می برد. در حال حاضر صنعت SBI یکی از زمینه های رشد است که داده های بدون ساختار و نیمه ساخت یافته را از سایت های رسانه های اجتماعی در SBI می آورد و یکی از بسیار دلیل برای انجام این کار این است که، سایت های رسانه های اجتماعی مانند فیس بوک ، توییتر ، یوتیوب، وبلاگ ، مای اسپیس، و LinkedIn منابع با ارزش از هوش مشتری هستند.
از مزیت های SBI می توان به موارد زیر اشاره کرد :
۱٫ کاهش هزینه، صرفه جویی در زمان جمع آوری و پردازش اطلاعات و کاهش نیاز به تعداد زیادی تحلیلگر برای همه شرکت هایی که دچار محدودیت زمان، منابع مالی و منابع انسانی هستند.
۲٫ تسهیل فرآیندهای جمع آوری و تحلیل اطلاعات و گزارش دهی.
۳٫ کمک به کاهش ریسک صاحبان کسب و کار از طریق شناخت محیط و اقتضائات موجود.
۴٫ ارائه گزارش ها و تحلیل های به هنگام.
۵٫ ایجاد دسترسی بسیار گسترده به منابع متعدد اطلاعاتی.
۶٫ افزایش قابل توجه کارآیی و بازدهی به دلیل سرعت، دقت و گستردگی فعالیت و تحلیل های هوشمندانه برمبنای آن.

مدل کامل BI

سالیان زیادی است که دانشمندان فناوری به دنبال یافتن راه‌هایی هستند که بتوانند بیشترین حجم اطلاعات را بر روی فضایی بسیار کوچک، ذخیره کنند. این تلاش‌ها دستاوردهای زیادی به همراه داشته و در نمونه اخیر، آنها موفق شدند تا 2860 سال ویدئوی با کیفیت HD را تنها بر روی 1 گرم DNA ذخیره کنند!

یانیو الریش از دانشگاه کلمبیا با همکاری دینا زیلینسکی از مرکز ژنوم نیویورک این روش را طراحی کرده‌اند. آنها در این زمینه از روش جدید رمزگذاری دی‌ان‌ای استفاده کردند که بیشترین میزان اطلاعات به ازای هر نوکلئوتید را ذخیره می‌کند. این دو دانشمند در آزمایش‌ها با استفاده از الگوریتمی به نام DNA Fountain، شش فایل (یک فیلم کوتاه، کل یک رایانه OS و یک کارت هدیه آمازون) را درون یک ذره دی‌ان‌ای ذخیره کردند. الریش در این باره می گوید: «روش رمزگذاری ما ۱۰۰ بار کارآمدتر از روش‌هایی است که در سال ۲۰۱۲ ساخته شد و می‌تواند ۲۱۵ پتابایت اطلاعات را در یک گرم دی‌ان‌ای ذخیره کند.

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

ماشین‌های الیگونوکلئوتیدی نیز به نوبه خود برای ذخیره‌سازی و بازیابی اطلاعات دی‌ان‌ای به کار می‌رود. این نوع سیستم ذخیره، فشرده‌تر از نوارهای مغناطیسی و هارد درایوهاست، زیرا در دی‌ان‌ای اطلاعات بیشتری ذخیره می‌شود. دانشمندان معتقدند با استفاده از همین روش می‌توان به طور موثر تمام اطلاعات جهان را درون یک اتاق فشرده و ذخیره کرد! هر پتابایت معادل ۱۳.۳ سال ویدئو با کیفیت HD است.

@BIMining

10 فناوری اساسی و نوظهور که آینده ما را تغییر خواهند داد
@BIMining

ORACLE Big Data Platform

@BIMining

آخرین آمارهای بانک مرکزی نشان می‌دهد که میزان بدهی بانک‌ها به بانک مرکزی دردی‌ماه سال‌جاری نسبت به مدت مشابه سال قبل ۱/ ۳۰ درصد افزایش یافته است @BIMining

اولویت‌های هزینه‌ای حوزه‌ی IT در مؤسسات مالی @BIMining

تاریخچه و تعریفNo Sql :

اصطلاح NoSQL اولین بار در سال 1998 توسط Carlo Strozzi برای پایگاه‌داده‌های رابطه‌ای‌ای که از زبان SQL استفاده نمی‌کردند به کار رفت . بعدها مجدداً در سال 2009 در اجلاس در San Francisco که مدافعین پایگاه‌داده‌های غیر رابطه‌ای گرد هم آورده بود مورداستفاده قرار گرفت. ازجمله این مدافعین می‌توان به Jon Oskarsson و Eric Evans اشاره نمود. اخیراً NoSQL به معنای "نه‌فقط SQL"(Not Only SQL) به دسته بزرگی از پایگاه‌داده‌ها اطلاق می‌شود که خصوصیات پایگاه‌داده‌های رابطه‌ای را ندارند و برای جستار زدن(query) از زبان توصیفی(declarative language) SQL استفاده نمی‌کنند. ازجمله بارزترین ویژگی‌های این دسته از پایگاه‌داده‌ها می‌توان به موارد زیر اشاره نمود:
• مدل داده غیر رابطه‌ای (Non-relational data model): محدودیت مدل رابطه‌ای در پشتیبانی از ابر داده‌ها(big data) و داده‌هایی با ساختارهای ترکیب‌شده(mixed-structured data) یعنی داده‌های ساخت‌یافته(structured)، نیمه ساخت‌یافته(semi- structured) و غیر ساخت‌یافته(unstructured) یکی از دلایل اصلی معرفی NoSQL بود.

طراحی‌شده برای محیط‌های توزیع‌شده: جهش‌های صورت گرفته در توسعه معماری کامپیوتر، پردازش‌های توزیع‌شده و موازی(distributed and parallel processing)، محاسبات ابری(cloud computing) و همچنین نیاز به تکرار(replicate) و توزیع(distribute) داده‌ها میان سرویس‌دهنده‌های متعدد؛ نیاز به یک پایگاه‌داده باقابلیت وسعت پذیری افقی( scale horizontally : scale out) را بیش‌ازپیش روشن می‌ساخت. یعنی پایگاهی که به تواند به‌سادگی و ارزانی با افزودن گره‌های جدید به شبکه‌اش توسعه یابد برخلاف پایگاه‌داده‌های رابطه‌ای که تنها به وسعت پذیری عمودی(scale vertically : scale up) یعنی ارتقا کارایی یک تک گره با افزودن به منابع آن یا با فناوری‌های مجازی‌سازی (virtualization technology)اهتمام می‌ورزند.
• واسط سطح فراخوانی ساده‌تر : واسط سطح فراخوانی(CLI : call level interface) یک استاندارد نرم‌افزاری است که می‌گوید چه طور جستارها از سمت برنامه به سمت DBMS ارسال و چه طور مجموعه‌رکورد(record set) به برنامه مجدداً به‌طور سازگاری برگرد. در برنامه‌های شی‌ءگرا و پایگاه‌داده‌های رابطه‌ای لازم بود تا نگاشت شی رابطه (Object/Relational Mapping) صورت پذیرد.
• اهمیت کم‌تر به سازگاری داده‌ها: پایگاه‌داده‌های NoSQL ای از مدل هم‌روندی و تراکنشی ضعیف‌تری نسبت به ACID بهره می‌برند. خصوصیت ACID به معنای اتمیک بودن(atomic)، سازگاری(consistency)، انزوا(isolation) و پایداری(durability) برای تراکنش‌های پایگاه‌داده، همخوانی داده‌ها در بالاترین اولویت خود می‌دانست. پیاده‌سازی این خصوصیت برای پردازش‌های موازی و پاسخگویی سریع به جستارها کار دشواری بود. پس برای پردازش حجم بالایی از داده در یک محیط توزیع‌شده ناچار به تعدیل خصوصیت ACID بودیم که در پایگاه‌داده‌های NoSQL این امر صورت پذیرفته است.
• استفاده کاراتر از شاخص‌ها و حافظه اصلی توزیع‌شده: با استفاده از ساختارهای درون‌حافظه ای(in-memory) می‌توان حجم بالایی از داده‌ها را در حافظه اصلی نهان (cache) نمود و با سرعت بالاتری نسبت به دیسک آن‌ها را واکشی(fetch) کرد.
• شمای منعطف‌تر : بی شمایی(schema-less) یا شمای ضعیف(weak schema) در انبار داده‌ها(data warehouse) یک پیشرفت در جستارهای تحلیلی حرفه‌های فاقد عمومیت(ad-hoc business analytics query) به‌حساب می‌آمد که پایگاه‌داده‌های NoSQL ای نیز بدان توجه وافری داشته‌اند.

تقسیم بندی :

پایگاه های داده NoSQL را می توان بر اساس مدل داده (data model) به چهار دسته تقسیم می شوند:

• پایگاه‌داده جفت کلید مقدار (Key Value Pair) : ایده اصلی این مدل دهه‌ها است که در محاسبات وجود دارد، این یک ساختمان داده معمول است یا مفهومی است در توسعه file system ها به کار گرفته‌شده است [1]. ساختار این مدل از مدل رابطه ای ساده تر و سرعت به جواب رسیدن جستارها نیز بسیار بالاتر است. این مدل برای تغییر(modify)دادن و جستار زدن بر روی کلیداصلی(primary key) حجم سنگینی از داده ها(mass storage) در همزمانی بالا(high concurrency) عملکرد عالی ای از خود نشان می دهد [33]. در این نوع از پایگاه‌داده‌ها، داده به‌صورت جفتی از کلیدها و مقدارها ذخیره می‌گردد. هر یک از کلیدها در گردایه (collection) خود منحصربه‌فرد است. دسترسی به مقادیر به‌وسیله تجمیع (association)کلید-مقدار به دست می‌آید. کلیدها نیازمند آن هستند که در مخزن داده‌ای که قابل‌دسترسی سریع باشند نگهداری گردند شبیه جدول درهم (hash table). نمونه ای از پیاده سازی ها :

Redis
Voldemort(LinkedIn)
Membase
Coherence(Oracle)
Velocity
BigTable(Google)
TokyoCabinet

• پایگاه‌داده‌های گراف(graph database) : پایگاه‌داده‌های گراف بر اساس نظریه گراف‌ها ایجادشده‌اند که شامل گره (node)، یال(edge) و خصوصیات (properties)هستند.بخشی از شهرت شبکه‌های اجتماعی به دلیل احیای تحقیقات پایگاه‌داده‌های گرافی در دهه‌های 80 و 90 بوده است چراکه روابط دوستی و علاقه‌مندی‌های افراد را می‌توان به‌صورت یک گراف متصور شد. نمونه ای از پیاده سازی ها :

Neo4j
InfoGrid
Sesame
BigData
FlockDB
GraphDB
AllegroGraph
DEX

پایگاه‌داده‌های ستون-فامیل (Column-Family) : پایگاه‌داده‌های ستون-فامیل نوعی از پایگاه‌داده‌های جفت کلید-مقدار هستند. و شامل column،column family و super column هستند. ابرستون ها (super-columns) و ستون فامیل (column family) شمای پایگاه‌داده را تعیین می‌کنند. می‌توان ستون و ابرستون‌های جدیدی نیز به پایگاه‌داده‌ای قبلاً تولید است اضافه نمود. یکی از تفاوت‌های پایگاه‌داده رابطه‌ای با پایگاه‌داده ستون-فامیل این است که سطرهای(row) در پایگاه‌داده ستون فامیلی لزوماً نباید هم‌درجه باشند.یعنی می‌توانند شمار متغیر و متفاوتی از ستون‌ها و ابرستون ها را داشته باشند. ازاین‌رو پایگاه‌داده‌های ستون فامیل در برنامه‌هایی که با گردایه ای از داده‌های پر تهی (spars) کار می‌کنند بسیار کارا هستند. نمونه ای از پیاده سازی ها :

Cassandra(Apache)
Hypertable
HBase
Dynamo
Riak

پایگاه‌داده‌های ستون-فامیل (Column-Family) : پایگاه‌داده‌های ستون-فامیل نوعی از پایگاه‌داده‌های جفت کلید-مقدار هستند. و شامل column،column family و super column هستند. ابرستون ها (super-columns) و ستون فامیل (column family) شمای پایگاه‌داده را تعیین می‌کنند. می‌توان ستون و ابرستون‌های جدیدی نیز به پایگاه‌داده‌ای قبلاً تولید است اضافه نمود. یکی از تفاوت‌های پایگاه‌داده رابطه‌ای با پایگاه‌داده ستون-فامیل این است که سطرهای(row) در پایگاه‌داده ستون فامیلی لزوماً نباید هم‌درجه باشند.یعنی می‌توانند شمار متغیر و متفاوتی از ستون‌ها و ابرستون ها را داشته باشند. ازاین‌رو پایگاه‌داده‌های ستون فامیل در برنامه‌هایی که با گردایه ای از داده‌های پر تهی (spars) کار می‌کنند بسیار کارا هستند. نمونه ای از پیاده سازی ها :

Cassandra(Apache)
Hypertable
HBase
Dynamo
Riak


• پایگاه‌داده سندمحور : از مفهوم جفت کلید-مقدار استفاده می‌کند ولی ساختار خاصی را در ذخیره‌سازی داده شبیه سند مانند XML و JSON اعمال می‌کنند که موجب ذخیره اطلاعات بیش‌تری درباره ساختار خود داده می‌شود که آن را نسبت به ستون-فامیل ها جستار پذیر تر می‌کند چراکه آنجا تنها جستار با یک کلید(key) یا بازه کلید (key range) امکان‌پذیر است[1] . پایگاه‌داده‌های سند‌محور با وجود شباهت ساختاری زیاد به پایگاه داده های جفت کلید/مقدار با آن ها دو تفاوت دارند: اول این‌که مقادیر پایگاه‌داده‌های سند‌محور معنایی(semantic)هستند و دوم این‌که می توانند از شاخص‌ثانویه نیز استفاده کنند . MangoDB نمونه‌ای از این مدل است که توسط شرکت 10gen توسعه‌یافته است. وقتی از پیاده‌سازی MangoDB پایگاه‌داده‌های NoSQL ای استفاده می‌کنیم خبری از جداول و شماها در پایگاه‌داده نیست. MangoDB در عوض از "گردایه ها" (collection) ها که شبیه جداول هستند و نیز از "اسناد" (documents) که شبیه سطرها هستند برای ذخیره‌سازی داده‌ها و اطلاعات شما (schema information) استفاده می‌کند. MangoDB به‌صورت خودکار برای هر "سند" یک شناسه‌ی کلید اصلی تولید(primary key id) می‌کند تا به‌طور منحصربه‌فرد قابل‌شناسایی باشد. ازلحاظ مفهومی شناسه (id) و سند (document) شبیه جفت کلید‌مقدار (key-value pair)است. MangoDB سعی می‌کند تا داده را بر حافظه نگاه دارد بنابراین دیگر نیاز به بازیابی (retrieve) داده‌های از روی دیسک سخت (hard disk) نیست و زمان کمتری برای جستارها لازم نیاز است. یکی از مشکلات (caveat) زمانی است مجموعه داده بزرگ‌تر از حافظه موجود (available memory) می‌گردد که در این صورت MangoDB مجبور به شروع کردن جستار از روی دیسک سخت خواهد شد. نمونه ای از پیاده سازی ها :

MangoDB(10gen)
CouchDB(Apache)
Riak
eXist
SimpleDB(Amazon)
Terrastore
Lotus Notes