کتابخانه pixel-flow
یک JavaScript Image Gallery
چگونگی ذخیره عکس در دیتابیس با mvc4
شروع به کار با RavenDB
- مروری بر مفاهیم مقدماتی NoSQL
- ردهها و انواع مختلف بانکهای اطلاعاتی NoSQL
- چه زمانی بهتر است از بانکهای اطلاعاتی NoSQL استفاده کرد و چه زمانی خیر؟
لطفا یکبار این پیشنیازها را پیش از شروع به کار مطالعه نمائید؛ چون بسیاری از مفاهیم پایهای و اصطلاحات مرسوم دنیای NoSQL در این سه قسمت بررسی شدهاند و از تکرار مجدد آنها در اینجا صرفنظر خواهد شد.
RavenDB چیست؟
RavenDB یک بانک اطلاعاتی سورس باز NoSQL سندگرای تهیه شده با دات نت است. ساختار کلی بانکهای اطلاعاتی NoSQL سندگرا، از لحاظ نحوه ذخیره سازی اطلاعات، با بانکهای اطلاعاتی رابطهای متداول، کاملا متفاوت است. در اینگونه بانکهای اطلاعاتی، رکوردهای اطلاعات، به صورت اشیاء JSON ذخیره میشوند. اشیاء JSON یا JavaScript Object Notation بسیار شبیه به anonymous objects سی شارپ هستند. JSON روشی است که توسط آن JavaScript اشیاء خود را معرفی و ذخیره میکند. به عنوان رقیبی برای XML مطرح است؛ نسبت به XML اندکی فشردهتر بوده و عموما دارای اسکیمای خاصی نیست و در بسیاری از اوقات تفسیر المانهای آن به مصرف کننده واگذار میشود.
در JSON عموما سه نوع المان پایه مشاهده میشوند:
- اشیاء که به صورت {object} تعریف میشوند.
- مقادیر "key":"value" که شبیه به نام خواص و مقادیر آنها در دات نت هستند.
- و آرایهها به صورت [array]
همچنین ترکیبی از این سه عنصر یاد شده نیز همواره میسر است. برای مثال، یک key مشخص میتواند دارای مقداری حاوی یک آرایه یا شیء نیز باشد.
JSON: JavaScript Object Notation document :{ key: "Value", another_key: { name: "embedded object" }, some_date: new Date(), some_number: 12 } C# anonymous object var Document = new { Key= "Value", AnotherKey= new { Name = "embedded object" }, SomeDate = DateTime.Now(), SomeNumber = 12 };
یک نکته مهم
اگر پیشنیازهای بحث را مطالعه کرده باشید، حتما بارها با این جمله که دنیای NoSQL از تراکنشها پشتیبانی نمیکند، برخورد داشتهاید. این مطلب در مورد RavenDB صادق نیست و این بانک اطلاعاتی NoSQL خاص، از تراکنشها پشتیبانی میکند. RavenDB در Document store خود ACID عملکرده و از تراکنشها پشتیبانی میکند. اما تهیه ایندکسهای آن بر مبنای مفهوم عاقبت یک دست شدن عمل میکند.
مجوز استفاده از RavenDB
هرچند مجموعه سرور و کلاینت RavenDB سورس باز هستند، اما این مورد به معنای رایگان بودن آن نیست. مجوز استفاده از RavenDB نوع خاصی به نام AGPL است. به این معنا که یا کل کار مشتق شده خود را باید به صورت رایگان و سورس باز ارائه دهید و یا اینکه مجوز استفاده از آنرا برای کارهای تجاری بسته خود خریداری نمائید. نسخه استاندارد آن نزدیک به هزار دلار است و نسخه سازمانی آن نزدیک به 2800 دلار به ازای هر سرور.
شروع به نوشتن اولین برنامه کار با RavenDB
ابتدا یک پروژه کنسول ساده را آغاز کنید. سپس کلاسهای مدل زیر را به آن اضافه نمائید:
using System.Collections.Generic; namespace RavenDBSample01.Models { public class Question { public string By { set; get; } public string Title { set; get; } public string Content { set; get; } public List<Comment> Comments { set; get; } public List<Answer> Answers { set; get; } public Question() { Comments = new List<Comment>(); Answers = new List<Answer>(); } } } namespace RavenDBSample01.Models { public class Comment { public string By { set; get; } public string Content { set; get; } } } namespace RavenDBSample01.Models { public class Answer { public string By { set; get; } public string Content { set; get; } } }
PM> Install-Package RavenDB.Client PM> Install-Package RavenDB.Server
اکنون به پوشه packages\RavenDB.Server.2.5.2700\tools مراجعه کرده و برنامه Raven.Server.exe را اجرا کنید تا سرور RavenDB شروع به کار کند. این سرور به صورت پیش فرض بر روی پورت 8080 اجرا میشود. از این جهت که در RavenDB نیز همانند سایر Document Stores مطرح، امکان دسترسی به اسناد از طریق REST API و Urlها وجود دارد.
البته لازم به ذکر است که RavenDB در 4 حالت برنامه کنسول (همین سرور فوق)، نصب به عنوان یک سرویس ویندوز NT، هاست شدن در IIS و حالت مدفون شده یا Embedded قابل استفاده است.
خوب؛ همین اندازه برای برپایی اولیه RavenDB کفایت میکند.
using Raven.Client.Document; using RavenDBSample01.Models; namespace RavenDBSample01 { class Program { static void Main(string[] args) { using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { using (var session = store.OpenSession()) { session.Store(new Question { By = "users/Vahid", Title = "Raven Intro", Content = "Test...." }); session.SaveChanges(); } } } } }
کار با ایجاد یک DocumentStore که به آدرس سرور اشاره میکند و کار مدیریت اتصالات را برعهده دارد، شروع خواهد شد. اگر نمیخواهید Url را درون کدهای برنامه مقدار دهی کنید، میتوان از فایل کانفیگ برنامه نیز برای این منظور کمک گرفت:
<connectionStrings> <add name="ravenDB" connectionString="Url=http://localhost:8080"/> </connectionStrings>
سپس با ایجاد Session در حقیقت یک Unit of work آغاز میشود که درون آن میتوان انواع و اقسام دستورات را صادر نمود و سپس در پایان کار، با فراخوانی SaveChanges، این اعمال ذخیره میگردند. در RavenDB یک سشن باید طول عمری کوتاه داشته باشد و اگر تعداد عملیاتی که در آن صادر کردهاید، زیاد است با خطای زیر متوقف خواهید شد:
The maximum number of requests (30) allowed for this session has been reached.
در یک برنامه واقعی، ایجاد DocumentStore یکبار در آغاز کار برنامه باید انجام گردد. اما هر سشن یا هر واحد کاری آن، به ازای تراکنشهای مختلفی که باید صورت گیرند، بر روی این DocumentStore، ایجاد شده و سپس بسته خواهند شد. برای مثال در یک برنامه ASP.NET، در فایل Global.asax در زمان آغاز برنامه، کار ایجاد DocumentStore انجام شده و سپس به ازای هر درخواست رسیده، یک سشن RavenDB ایجاد و در پایان درخواست، این سشن آزاد خواهد شد.
برنامه را اجرا کنید، سپس به کنسول سرور RavenDB که پیشتر آنرا اجرا نمودیم مراجعه نمائید تا نمایی از عملیات انجام شده را بتوان مشاهده کرد:
Raven is ready to process requests. Build 2700, Version 2.5.0 / 6dce79a Server started in 14,438 ms Data directory: D:\Prog\RavenDBSample01\packages\RavenDB.Server.2.5.2700\tools\Database\System HostName: <any> Port: 8080, Storage: Esent Server Url: http://localhost:8080/ Available commands: cls, reset, gc, q Request # 1: GET - 514 ms - <system> - 404 - /docs/Raven/Replication/Destinations Request # 2: GET - 763 ms - <system> - 200 - /queries/?&id=Raven%2FHilo%2Fquestions&id=Raven%2FServerPrefixForHilo Request # 3: PUT - 185 ms - <system> - 201 - /docs/Raven/Hilo/questions Request # 4: POST - 103 ms - <system> - 200 - /bulk_docs PUT questions/1
عملیات PUT حتما نیاز به یک Id از پیش مشخص دارد و این Id، پیشتر در سطری که Hilo در آن ذکر شده (یکی از الگوریتمهای محاسبه Id در RavenDB)، محاسبه گردیده است. برای نمونه در اینجا الگوریتم Hilo مقدار "questions/1" را به عنوان Id محاسبه شده بازگشت داده است.
در سطری که عملیات Post به آدرس bulk_docs سرور ارسال گردیده است، کار ارسال یکباره چندین شیء JSON برای کاهش رفت و برگشتها به سرور انجام میشود.
و برای کوئری گرفتن مقدماتی از اطلاعات ثبت شده میتوان نوشت:
using (var session = store.OpenSession()) { var question1 = session.Load<Question>("questions/1"); Console.WriteLine(question1.By); }
نگاهی به بانک اطلاعاتی ایجاد شده
در همین حال که سرور RavenDB در حال اجرا است، مرورگر دلخواه خود را گشوده و سپس آدرس http://localhost:8080 را وارد نمائید. بلافاصله، کنسول مدیریتی تحت وب این بانک اطلاعاتی که با سیلورلایت نوشته شده است، ظاهر خواهد شد:
و اگر بر روی هر سطر اطلاعات دوبار کلیک کنید، به معادل JSON آن نیز خواهید رسید:
اینبار برنامه را به صورت زیر تغییر دهید تا روابط بین کلاسها را نیز پیاده سازی کند:
using System; using Raven.Client.Document; using RavenDBSample01.Models; namespace RavenDBSample01 { class Program { static void Main(string[] args) { using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { using (var session = store.OpenSession()) { var question = new Question { By = "users/Vahid", Title = "Raven Intro", Content = "Test...." }; question.Answers.Add(new Answer { By = "users/Farid", Content = "بررسی میشود" }); session.Store(question); session.SaveChanges(); } using (var session = store.OpenSession()) { var question1 = session.Load<Question>("questions/1"); Console.WriteLine(question1.By); } } } } }
اگر برنامه فوق را اجرا کرده و به ساختار اطلاعات ذخیره شده نگاهی بیندازیم به شکل زیر خواهیم رسید:
نکته جالبی که در اینجا وجود دارد، عدم نیاز به join نویسی برای دریافت اطلاعات وابسته به یک شیء است. اگر سؤالی وجود دارد، پاسخهای به آن و یا سایر نظرات، یکجا داخل همان سؤال ذخیره میشوند و به این ترتیب سرعت دسترسی نهایی به اطلاعات بیشتر شده و همچنین قفل گذاری روی سایر اسناد کمتر. این مساله نیز به ذات NoSQL و یا غیر رابطهای RavenDB بر میگردد. در بانکهای اطلاعاتی NoSQL، مفاهیمی مانند کلیدهای خارجی، JOIN بین جداول و امثال آن وجود خارجی ندارند. برای نمونه اگر به کلاسهای مدلهای برنامه دقت کرده باشید، خبری از وجود Id در آنها نیست. RavenDB یک Document store است و نه یک Relation store. در اینجا کل درخت تو در توی خواص یک شیء دریافت و به صورت یک سند ذخیره میشود. به حاصل این نوع عملیات در دنیای بانکهای اطلاعاتی رابطهای، Denormalized data هم گفته میشود.
البته میتوان به کلاسهای تعریف شده خاصیت رشتهای Id را نیز اضافه کرد. در این حالت برای مثال در حالت فراخوانی متد Load، این خاصیت رشتهای، با Id تولید شده توسط RavenDB مانند "questions/1" مقدار دهی میشود. اما از این Id برای تعریف ارجاعات به سؤالات و پاسخهای متناظر استفاده نخواهد شد؛ چون تمام آنها جزو یک سند بوده و داخل آن قرار میگیرند.
DocerMaster : OS : CentOS7 IP: 192.168.64.3 DockerWorker: OS: CentOS7 IP: 192.168.64.4
sudo yum install docker
$ sudo service docker start $ sudo systemctl start docker.service
firewall-cmd --permanent --add-port=2376/tcp firewall-cmd --permanent --add-port=2377/tcp firewall-cmd --permanent --add-port=7946/tcp firewall-cmd --permanent --add-port=7946/udp firewall-cmd --permanent --add-port=4789/udp firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload
systemctl restart docker
~]# firewall-cmd --permanent --add-port=2376/tcp ~]# firewall-cmd --permanent --add-port=7946/tcp ~]# firewall-cmd --permanent --add-port=7946/udp ~]# firewall-cmd --permanent --add-port=4789/udp ~]# firewall-cmd --permanent --add-port=80/tcp ~]# firewall-cmd --reload ~]# systemctl restart docker
sudo docker swarm init –advertise-addr 192.168.64.3
همانطور که مشاهده میکنید، پس از راه اندازی، اعلانی مبنی بر اینکه این نود به عنوان Manager شناخته شده و اینکه برای اضافه کردن یک نود Worker چه دستوری را باید اجرا کرد، نمایش داده شدهاست.
اکنون کافیاست این خط کد را در نود Worker کپی کنیم:
بعد از موفقیت آمیز بودن اجرای آن، میتوانید در کامپیوتر Master، با دستور زیر تمام نودها را مشاهده کنید:
$ sudo docker node ls
همانطور که مشاهده میکنید، دو نود وجود دارد که یکی به عنوان Leader شناخته میشود. هر زمانی که نیاز بود، میشود به راحتی یک Worker دیگر را اضافه کرد.
برای راه اندازی یک کانتینر، swarm از CLI کاملی برخوردار هست؛ اما مایلم اینجا از یک ابزار خوب، برای مدیریت Swarm استفاده کنم. Portainer به عنوان یه ابزار عالی برای مدیریت Imageها و Containerهای داکر محسوب میشود که کاملا swarm را پشتیبانی میکند.
برای راه اندازی portainer کافی است کد زیر را در سیستم Master اجرا کنید:
$ docker volume create portainer_data $ docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
البته به دلیل عدم دسترسی به داکر هاب از کشور ایران، عملا امکان pull کردن این image، مستقیما از داکر هاب و بدون وی پی ان وجود ندارد.
بعد از موفقیت آمیز بودن راه اندازی portainer میتوانید از طریق آدرس http://192.168.64.3:9000 به آن دسترسی داشته باشید. در اولین ورود، پسورد ادمین را تنظیم میکنید و بعد از وارد شدن، صفحهای مطابق شکل زیر را خواهید دید:
اگر بر روی منوی swarm کلیک کنید، همهی نودها را مشاهده خواهید کرد و در صورتیکه بر روی Containers کلیک کنید، همهی Container هایی را که بر روی این سرور وجود دارند، خواهید دید. مهمترین قسمت، بخش Service هاست که مشخصات Container هایی که روی swarm توزیع شدن را نشان میدهد و همینطور تعداد Container هایی از این image که Scale شدند. همینطور که میبینید فعلا فقط همین Portainer در حال اجراست.
اجازه دهید یک مثال کاربردیتر بزنیم و یک سرویس را ایجاد کنیم.
من بر روی کامپیوتر شخصیام و نه سرورها، با دستور زیر یک پروژهی MVC را با دات نت Core ایجاد میکنم:
dotnet new mvc
و سپس دستور dotnet publish را اجرا میکنم و به پوشهای که محتویات پابلیش شده در آن قرار دارند رفته و یک فایل بدون پسوند را به نام dockerfile ایجاد میکنم و متن زیر را در آن مینویسم:
همینطور که میبینید من از image مخصوص اجرای دات نت Core در این container استفاده میکنم. پوشهی کانتینر را تنظیم میکنم و همهی فایلهایی که در پوشهی جاری سیستم خودم وجود دارند را به پوشهی جاری کانتینر منتقل میکنم و سپس دستور دات نت را با پارامتر اسم dll پروژهام اجرا میکنم. این کل محتویات فایل داکر من هست.
ترمینال را در همین پوشهی publish باز میکنم و دستور زیر را اجرا میکنم:
docker build –t swarmtest:dev .
docker save swarmtest:dev –o swarmtest.tar
طبق شکل زیر یک فایل tar که حاوی image برنامه من هست، ایجاد شد:
حالا با دستور زیر این فایل رو به سرور Master منتقل میکنم:
scp –r swarmtest.tar root@192.168.64.3:/srv/images
همانطور که میبینید، فایل tar به پوشهای که قبلا در سرور ایجاد کردم، منتقل شد.
حالا به سرور و پوشهای که فایل tar آنجا قرار دارد رفته و با دستور زیر این image را بر روی سیستم load میکنم:
sudo docker load –i swarmtest.tar
همانطور که در تصویر میبینید، بعد از load شدن، image مورد نظرمان به داکر اضافه شدهاست.
حالا برای اجرا کردن این سرویس بر روی swarm، آدرس portainer را باز میکنیم و به قسمت services میرویم و بر روی دکمهی add service کلیک میکنیم:
در قسمت نام، نام سرویس و در قسمت imageConfiguration از منوی imageها، ایمیجی را که ایجاد کردیم، انتخاب میکنیم. در قسمت Replicas تعداد instanceهای container ای را که میخواهیم از روی image ایجاد شوند، مشخص میکنیم. (این قسمت را بر روی هر وضعیتی میتوانیم قرار دهیم و زیاد و کم کنیم) و در قسمت port mapping، پورت درون Container و پورتی را که میخواهیم بر روی هاست به نمایش درآید، وارد میکنیم.
همانطور که میبینید من به راحتی میتوانم تعداد Containerها را Scale کنم و نگرانیای بابت load balancing و اینکه کدام container بر روی کدوم سرور ایجاد میشود، نخواهم داشت.
برای نمایش برنامه کافی است پورتی را که برای هاست وارد کردیم، با آی پی Master وارد کنیم:
بررسی علت CPU Usage بالای برنامه در حال اجرا
<script src="cordova.js"></script>
مثال برای اندروید
(function () { "use strict"; document.addEventListener( 'deviceready', onDeviceReady.bind( this ), false ); function onDeviceReady() { // Handle the Cordova pause and resume events document.addEventListener( 'pause', onPause.bind( this ), false ); document.addEventListener('resume', onResume.bind(this), false); document.addEventListener('menubutton', onMenuButton.bind(this), false); document.addEventListener('backbutton', onBackButton.bind(this), false); //document.addEventListener('searchbutton', onResume.bind(this), false); //document.addEventListener('endcallbutton', onResume.bind(this), false); //document.addEventListener('offline', onResume.bind(this), false); //document.addEventListener('online', onResume.bind(this), false); //document.addEventListener('startcallbutton', onResume.bind(this), false); //document.addEventListener('volumedownbutton', onResume.bind(this), false); //document.addEventListener('volumeupbutton', onResume.bind(this), false); // TODO: Cordova has been loaded. Perform any initialization that requires Cordova here. }; function onPause() { // TODO: This application has been suspended. Save application state here. alert("paused"); }; function onResume() { alert("resume"); }; function onMenuButton() { alert("menu"); }; function onBackButton() { alert("back button"); }; } )();
.در مقالات آینده از افزونههای موجود، برای مدیریت رخدادهای باتری سیستم استفاده خواهیم کرد
jQuery Mobile
Phones/Tablets
Android 1.6+
BlackBerry 5+
iOS 3+
Windows Phone 7
WebOS 1.4+
Symbian (Nokia S60)
Firefox Mobile Opera Mobile 11+
Opera Mini 5+
Desktop browsers
Chrome 11+
Firefox 3.6+
Internet Explorer 7+
Safari
برای نصب jQuery Mobile کافی است دستورات زیر را در package manager console ویژوال استودیو استفاده کنید:
PM>install-package jquery
PM>install-package jquery.mobile.rtl
بعد از دانلود فایلهای مورد نظر خود، فولدری بنام jquery.mobile.rtl در ریشه پروژه ایجاد خواهد شد. به ترتیب فایل های rtl.jquery.mobile-1.4.0.css و rtl.jquery.mobile-1.4.0.js موجود در زیر شاخههای فلدر مذکور را به head و آخر body فایل index.html اضافه کنید.
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>CordovaApp01</title> <!-- CordovaApp01 references --> <link href="css/index.css" rel="stylesheet" /> <link href="jquery.mobile.rtl/css/themes/default/rtl.jquery.mobile-1.4.0.css" rel="stylesheet" /> </head> <body> <div data-role="page" id="page1"> <div data-role="header"> <h1>اولین برنامه</h1> </div> <div data-role="content"> <p>سلام من محتوای اولین برنامه هستم</p> </div> <div data-role="footer"> <h1>من فوتر هستم</h1> </div> </div> <!-- Cordova reference, this is added to your app when it's built. --> <script src="scripts/jquery-2.1.3.min.js"></script> <script src="cordova.js"></script> <script src="scripts/platformOverrides.js"></script> <script src="scripts/index.js"></script> <script src="jquery.mobile.rtl/js/rtl.jquery.mobile-1.4.0.js"></script> </body> </html>
نتیجهی نهایی به شکل زیر خواهد بود:
در مقالهی بعد به استفاده از pluginها خواهیم پرداخت.
ادامه دارد...
مفاهیم مقدماتی 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
تا اینجا در قسمت سوم، نحوهی قراردادن یک کامپوننت را در کامپوننتی دیگر، توسط مقدار دهی خاصیت directives مزین کنندهی Component بررسی کردیم. همینقدر که یک کامپوننت دارای selector باشد، قابلیت قرارگرفتن در یک کامپوننت دیگر را دارد. اما چگونه باید بین این کامپوننتها ارتباط برقرار کرد؟
تهیه کامپوننت نمایش ستارهای امتیازهای محصولات
مثال نمایش لیست محصولات سری جاری، دارای ستون «5Star Rating» است. در این قسمت میخواهیم بجای نمایش عددی این امتیازها، کامپوننتی را طراحی کنیم که نماش ستارهای آنها را سبب شود. این کامپوننت باید بتواند یک مقدار ورودی، یا همان عدد امتیاز محصول را از کامپوننت دربرگیرندهی آن دریافت کند. همچنین میخواهیم اگر کاربر بر روی این ستارهها کلیک کرد، کامپوننت در برگیرنده را نیز مطلع سازیم.
در این مثال در فایل product-list.component.html چنین سطری تعریف شدهاست:
<td>{{ product.starRating }}</td>
با توجه به اینکه کامپوننت نمایش ستارهای امتیازها، قابلیت استفادهی مجدد را دارد و الزامی ندارد که حتما در لیست محصولات، بکار گرفته شود، بهتر است محل تعریف آنرا به خارج از پوشهی products فعلی منتقل کنیم. برای مثال میتوان پوشهی app\shared را برای آن و تمامی کامپوننتهای با قابلیت استفادهی مجدد ایجاد کرد.
برای شروع، فایل جدید App\shared\star.component.ts را اضافه کنید؛ با کدهای کامل ذیل:
import { Component, OnChanges, Input, Output, EventEmitter } from 'angular2/core'; @Component({ selector: 'ai-star', templateUrl: 'app/shared/star.component.html', styleUrls: ['app/shared/star.component.css'] }) export class StarComponent implements OnChanges { @Input() rating: number; starWidth: number; @Output() ratingClicked: EventEmitter<string> = new EventEmitter<string>(); ngOnChanges(): void { this.starWidth = this.rating * 86 / 5; } onClick() { this.ratingClicked.emit(`The rating ${this.rating} was clicked!`); } }
سپس مسیر template و مسیر فایل css ویژهی آن، در تزئین کنندهی Component مشخص شدهاند. محتوای کامل این دو فایل را در ذیل مشاهده میکنید:
الف) محتوای فایل App\shared\star.component.html
<div class="crop" [style.width.px]="starWidth" [title]="rating" (click)='onClick()'> <div style="width: 86px"> <span class="glyphicon glyphicon-star"></span> <span class="glyphicon glyphicon-star"></span> <span class="glyphicon glyphicon-star"></span> <span class="glyphicon glyphicon-star"></span> <span class="glyphicon glyphicon-star"></span> </div> </div>
.crop { overflow: hidden; } div { cursor: pointer; }
معرفی مقدماتی life cycle hooks در قسمت قبل صورت گرفت. در اینجا چون نیاز است به ازای هر بار رندر شدن این کامپوننت، عرض آن متفاوت باشد، بنابراین نیاز است راهی را پیدا کنیم تا بتوان مقدار خاصیت starWidth را متغیر کرد. به همین منظور از hook مخصوص این تغییرات یا همان OnChanges استفاده میشود. بنابراین باید کلاس این کامپوننت، اینترفیس OnChanges را پیاده سازی کند. پس از آن، importهای لازم جهت تعریف OnChanges به ابتدای فایل اضافه شده و همچنین متد ngOnChanges نیز جهت تکمیل کار پیاده سازی اینترفیس OnChanges، به کلاس جاری اضافه میشود.
کار متد ngOnChanges، تبدیل عدد امتیاز یک محصول، به عرض div نمایش ستارهها است.
مکانیزم کار رخداد ngOnChanges و دریافت اطلاعات از والد
متد ngOnChanges، تنها به خواص ویژهای به نام «input properties» واکنش نشان میدهد. اگر یک کامپوننت تو در توی قرار گرفتهی در یک کامپوننت دیگر، بخواهد اطلاعاتی را از والد خود دریافت کند، باید خاصیتی را در معرض دید آن دربرگیرنده قرار دهد. این کار توسط decorator ویژهای به نام ()Input@ انجام میشود.
به همین جهت است که پیش از خاصیت rating در کلاس StarComponent، شاهد درج مزین کنندهی ویژهی ()Input@ هستیم:
export class StarComponent implements OnChanges { @Input() rating: number;
پس از آن، کامپوننت دربرگیرنده یا والد، این خاصیت ورودی ویژه را از طریق روش property binding متداول، مقدار دهی میکند:
[rating]='product.starRating'
بدیهی است در اینجا چون خاصیت starWidth از نوع ورودی تعریف نشدهاست، قابلیت property binging فوق را در کامپوننت والد، ندارد.
اکنون به ازای هر بار نمایش این کامپوننت فرزند، خاصیت rating ورودی آن مقدار دهی شده و مقدار آن در رخداد ngOnChanges قابل دسترسی و استفاده خواهد بود. اینجا است که میتوان از این مقدار تغییر یافته، جهت ترجمهی آن به عرض div نمایش ستارهها، استفاده کرد.
ارسال دادهها از کامپوننت فرزند به کامپوننت والد
تا اینجا با استفاده از «خواص ورودی» امکان دسترسی به مقادیر ارسالی از طرف والد را در کامپوننت فرزند، پیدا کردیم. عکس آن نیز امکان پذیر است؛ اما توسط رخدادها.
کامپوننت فرزند، با استفاده از decorator ویژهی دیگری به نام ()Output@ امکان ارسال رخدادها را به کامپوننت والد پیدا میکند:
export class StarComponent implements OnChanges { @Input() rating: number; starWidth: number; @Output() ratingClicked: EventEmitter<string> = new EventEmitter<string>();
در مثال جاری اگر کاربر بر روی div ستارههای نمایش داده شده کلیک کند، اتصال به آن از طریق event binging متداول انجام میشود (متد جدید onClick به رخداد click متصل شدهاست):
<div class="crop" [style.width.px]="starWidth" [title]="rating" (click)='onClick()'>
onClick() { this.ratingClicked.emit(`The rating ${this.rating} was clicked!`); }
تا اینجا مرحلهی تنظیمات رخدادها در کامپوننت فرزند صورت گرفت. ابتدا خاصیتی از نوع Output تعریف شد. سپس در کدهای قالب این کامپوننت جدید، متد onClick به رخداد click متصل گردید و سپس در کدهای مدیریت کنندهی این متد، متد ratingClicked.emit جهت ارسال اطلاعات نهایی به والد، فراخوانی گردید.
اکنون در کامپوننت والد، باید این مراحل برای دریافت اطلاعات از کامپوننت فرزند خود، طی شوند:
الف) ابتدا نام خاصیت مزین شدهی با Output، به عنوان مقصد event binding مشخص میشود و سپس متدی در کلاس کامپوننت والد، به آن متصل میگردد:
(ratingClicked)='onRatingClicked($event)'
ب) در ادامه، تعریف این متد جدید متصل شده را به کلاس ProductListComponent اضافه میکنیم:
onRatingClicked(message: string): void { this.pageTitle = 'Product List: ' + message; }
به این ترتیب با کلیک بر روی div هر کامپوننت نمایش ستارهای امتیازها، خاصیت pageTitle درج شدهی در صفحه تغییر میکند.
استفاده از کامپوننت نمایش ستارهای امتیازها
نکات کلی افزودن این کامپوننت جدید، تفاوتی با مطالب عنوان شدهی در قسمت سوم، در حین بررسی مراحل افزودن دایرکتیو نمایش لیست محصولات، به کامپوننت ریشهی سایت ندارد و یکی هستند.
برای افزودن و استفاده از این کامپوننت جدید، ابتدا قالب product-list.component.html را گشوده و سپس سطر نمایش عددی امتیاز یک محصول را به نحو ذیل تغییر میدهیم:
<td> <ai-star [rating]='product.starRating' (ratingClicked)='onRatingClicked($event)'> </ai-star> </td>
سپس باید به کلاس کامپوننت لیست محصولات (کامپوننت در برگیرنده) اعلام کرد که این کامپوننت جدید را باید از کجا پیدا کند. برای این منظور فایل product-list.component.ts را گشوده و خاصیت directives این کامپوننت را مقدار دهی میکنیم:
import { Component, OnInit } from 'angular2/core'; import { IProduct } from './product'; import { ProductFilterPipe } from './product-filter.pipe'; import { StarComponent } from '../shared/star.component'; @Component({ selector: 'pm-products', templateUrl: 'app/products/product-list.component.html', styleUrls: ['app/products/product-list.component.css'], pipes: [ProductFilterPipe], directives: [StarComponent] })
نمونهای از اجرای برنامه را در تصویر ذیل مشاهده میکنید:
در اینجا ستون امتیازهای محصولات با کامپوننت نمایش ستارهای این امتیازها جایگزین شدهاست و همچنین با کلیک بر روی یکی از آنها، عنوان panel جاری تغییر کردهاست.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MVC5Angular2.part6.zip
خلاصهی بحث
در اینجا نحوهی طراحی API عمومی یک کامپوننت را بررسی کردیم. تا زمانیکه خواص کلاس یک کامپوننت به نحو متداولی تعریف میشوند، میدان دید آنها محدود است به قالب تعریف شدهی متناظر با آنها. اگر نیاز است خاصیتی خارج از این قالب و به صورت عمومی در کامپوننت دربرگیرندهی دیگری در دسترس قرار گیرد، آنرا با مزین کنندهی ()Input@ مشخص میکنیم و اگر قرار است این کامپوننت فرزند، اطلاعاتی را به کامپوننت والد ارسال کند، اینکار را توسط رخدادها و با تعریف ویژگی ()Output@ و EventEmitter انجام میدهد. نوع آرگومان جنریک EventEmitter، تعیین کنندهی نوع اطلاعاتی است که قرار است به کامپوننت دربرگیرنده ارسال شوند.
پس از تعریف کامپوننت فرزند، برای تعریف آن در کامپوننت والد، از نام selector آن به عنوان یک المان جدید HTML استفاده میشود و سپس با استفاده از property binding، اطلاعات لازم، به خاصیت از نوع ()Input@ کامپوننت فرزند ارسال میگردد. از event binding برای دریافت رخدادها از کامپوننت فرزند استفاده میشود. در اینجا هر رخدادی که توسط مزین کنندهی ()Output@ تعریف شده باشد، میتواند به عنوان مقصد event binding تعریف شود و اگر نیاز است به رخدادهای property binding از والد به فرزند، گوش فرا داد، میتوان اینترفیس OnChanges را در کلاس کامپوننت فرزند پیاده سازی کرد.