تعداد بازدید : 14863
تعداد نوشته ها : 6
تعداد نظرات : 2
هدف دولت الکترونیک ارائه خدمات بهتر، با هزینه، کمتر و اثر بخشی بیشتر است؛ ولی
نمی‌توان استاندارد مشخصی برای سایر ویژگی‌های آن معرفی کرد، زیرا هر دولتی
می‌تواند با توجه به نیازهای جامعه خودش نظام دولت الکترونیک را پایه‌ریزی کند.
رشد و توسعه فناوری اطلاعات و مزایای زیاد کاربرد این فناوری در بهبود روند ارائه خدمات سازمانهای دولتی، سبب گرایش دولت‌ها به این فناوری و حرکت به سمت پیاده‌سازی دولت الکترونیک شده است. در این مطلب با مروری بر مفاهیم و اصطلاحات رایج در زمینه دولت الکترونیک مقدمه‌ای اجمالی بر این مبحث بیان میگردد.
1- تعاریف و اصطلاحات
• دولت الکترونیک (E- Government): دولت الکترونیک استفاده از فناوری‌های اطلاعاتی و ارتباطی به منظور ارائه خدمات دولتی، به صورت بهنگام و مستقیم به شهروندان، در 24 ساعته شبانه روز و 7 روز هفته است. دولت الکترونیک به افراد تسهیلات لازم جهت دسترسی مناسب به اطلاعات و خدمات دولتی و فرصت‌های گسترده‌تر برای مشارکت در فرایندها را ارائه می‌نماید.
• ذی‌نفع (Stakeholder): افراد، سازمان‌ها و گروه‌های خاصی هستند که به نحوی به طرح‌ها و برنامه‌های دولت علاقه‌مند هستند و تصمیمات دولت برای آنها اهمیت دارد و به عبارتی در فعالیت‌های دولتی ذی‌نفع هستند؛ مانند کارفرمایانی که مصوبات دولت در مورد حداقل حقوق کارگران برای آنها از نظر کاری و حرفه‌ای دارای اهمیت است.
• مشتری (Customer):استفاده‌کننده از سرویس‌های دولتی را مشتری می‌گویند، مانند بازنشستگانی که حقوق بازنشستگی دریافت می‌کنند و یا افرادی که برای معالجه به کلینیک‌های دولتی مراجعه می‌نمایند.
• شهروند (Citizen): فردی با حقوق و مسئولیت‌های تعریف‌شده و معین در جامعه؛ این حقوق شامل حق رأی، حق اظهار نظر آزاد و ... میشود. افرادی که در انتخابات شرکت کرده و رأی می‌دهند و یا اشخاصی که در یک تجمع سیاسی سخنرانی می‌کنند، مشتریان دولت نیستند؛ بلکه شهروندانی هستند که در فعالیت‌های جامعه شرکت می‌کنند.
• بنگاه (Business): شرکت‌های تجاری و خصوصی بوده که از یک سو با دولت و سازمانهای دولتی و از سوی دیگر با مصرف‌کنندگان (consrmers) یا مشتریان در ارتباط هستند. تمامی شرکت‌ها از زمان تأسیس شرکت برای ثبت و امور مالی و مالیاتی و رعایت استانداردها و قوانین و ... با دولت و ارگان‌های اداری در ارتباط هستند. همچنین برخی شرکت‌ها به عنوان پیمانکار با دولت در تعامل هستند مثل شرکت‌هایی که برخی پروژه‌های عمرانی دولت را بر عهده می‌گیرند.
2- ساختار و روابط دولت الکترونیک
در واقع ستون اصلی دولت الکترونیک، ارتباطی است که دولت با شهروندان، بنگاه‌های اقتصادی، کارکنان و سایر مؤسسات دولتی برقرار می‌سازد و این ارتباطات است که روح دولت الکترونیک را تشکیل می‌دهد. در این قسمت سعی می‌کنیم ابعاد مختلف دولت الکترونیک و روابط بین آنها را بشناسیم. دولت الکترونیک برای سرویس‌دهی به شهروندان، واحدهای خصوصی و سازمانهای دولتی دیگر، از مجراهای مختلفی استفاده می‌کند که این خود به روابطی مابین دولت و ارکان جامعه می‌انجامد که تحت عناوین زیر دسته بندی می‌شوند:
• G2E: رابطه دولت با شهروندان که طی آن دولت سرویسی را به شهروندان ارائه می‌دهد. در اینجا شهروند به عنوان عضوی از جامعه که حق او استفاده از سرویس‌های دولت الکترونیک است، این خدمات را به صورت رایگان دریافت می‌کند.
• G2B: رابطه‌ای بین دولت و بنگاه‌های تجاری وخصوصی است که طی آن دولت سرویسی رابه آن سازمان یا شرکت خصوصی ارائه می‌دهد. به عنوان مثال می‌توان به مزایده‌ای که از طرف دولت در اینترنت به اجرا گذاشته میشود و شرکت‌های خصوصی از طریق اینترنت در این مزایده شرکت می‌کنند اشاره کرد. خدماتی از قبیل ارائه مجوز وگواهی‌نامه‌ها، انجام خرید و فروش کالاها، خدمات وغیره دراین بخش انجام می‌گیرد.
• G2G: رابطه‌ای بین سازمانهای درون دولت و یا بین دولت‌های مختلف که طی آن، هریک از این سازمان‌ها یا دولت‌ها می‌توانند به دیگری سرویس دهند و یا روابطی در زمینه‌های مختلف داشته باشند. اکثر امور اداری دولت به نحوی به هم مربوط هستند. بدین معنی که اطلاعات یک سازمان یا بخش مورد استفاده، از سرعت و اطمینان کافی برخوردار نیست. به همین دلیل نیاز به اتصال سازمانهای مختلف دولتی احساس میشود.
• G2E: رابطه بین دولت با کارمندانش است و شامل سرویس‌هایی است که از طرف دولت به کارمندان اداری سازمانهای مختلف دولتی در رابطه با کار و شغل آنها ارائه میشود. این سرویس‌ها می‌توانند شامل امور مالی، حقوقی و مالیات و … مربوط به کارمندان باشد. رسیدگی به نحوه عملکرد کارمندان و ارتباطات داخلی یک سازمان دولتی جهت کاهش کاغذبازی و جلوگیری از اتلاف زمان و افزایش کارایی سازمان دولتی نیز می‌تواند از جمله کارکردهای GE باشد.
با توجه به روابطی که مطرح شد ارتباطات دیگری در جهت مخالف نیز بین دولت و ارکان جامعه وجود دارد که می‌توان به یکی از آنها اشاره کرد:
• C2G: عبارت است از ارتباطی میان دولت و مردم که طی آن شهروندان اطلاعاتی را به دولت ارائه می‌دهند. به عنوان مثال در یک رأی‌گیری الکترونیکی فرم‌ها و آرائی که شهروندان به دولت ارائه می‌دهند؛ یک ارتباط C2G را به وجود می‌آورد.
3- ویژگی‌های دولت الکترونیک
هدف دولت الکترونیک ارائه خدمات بهتر، با هزینه، کمتر و اثر بخشی بیشتر است؛ ولی نمی‌توان استاندارد مشخصی برای سایر ویژگی‌های آن معرفی کرد، زیرا هر دولتی می‌تواند با توجه به نیازهای جامعه خودش نظام دولت الکترونیک را پایه‌ریزی کند.
• (S (SMALL: دولت الکترونیک نباید گستردگی بیش از حد داشته باشد؛ تا بتواند از اتلاف نیروی انسانی و سرمایه جلوگیری کند. بنابراین بهتر است دولت‌های بزرگ به دولت‌های محلی کوچک‌تر تقسیم شوند.
• (M(MORAL: دولت الکترونیک باید مقید به اخلاق بوده و حریم اطلاعات خصوصی شهروندان را حفظ نماید.
• (A (AUDITABLE: دولت الکترونیک باید نسبت به فعالیت اجتماعی، اقتصادی و سیاسی که انجام می‌دهد جوابگو باشد؛ بدین معنی که شهروندان بتوانند تا حد امکان از روند پیشرفت این فعالیت‌ها آگاهی‌های لازم را کسب کنند.
• (R (RESPONSIBLE: دولت الکترونیک باید در صورت بروز مشکلاتی ناشی از فعالیت‌هایش به مردم پاسخگو باشد.
• (T (TRANSPARENT: دولت الکترونیک باید از موضع شفافی در رابطه با امور شهروندان برخوردار باشد.
4- مراحل تکامل دولت الکترونیک
در جریان گسترش کمی و کیفی سرویس‌هایی که دولت الکترونیک به جامعه ارائه می‌دهد، دولت از مراحل مختلفی عبور می‌کند که می‌توان آنها رابه چهار مرحله تقسیم کرد:
- به وجود آمدن وب‌سایت‌های دولتی که شامل اطلاعاتی درمورد سازمانهای مختلف دولتی است.
- ایجاد وب‌سایت‌های دولتی که شامل اطلاعات سازمان‌ها دریک محیط تعاملی هستند.
- ایجاد وب‌سایت‌هایی که به سرویس‌گیرندگان این اجازه را می‌دهند که بتوانند به اطلاعات شخصی مورد نیاز خود دست یابند.
- گسترش وب‌سایت‌ها و شبکه‌هایی که دائماً به شهروندان خدمات می‌دهند و شامل سازمانهای بسیار زیادی هستند که توسط این شبکه به یکدیگر متصل شده‌اند.
مراحل پیشرفت دولت الکترونیک و سرویس‌های ارائه‌شده در هر مرحله در شکل زیر به نمایش درآمده است.
شکل 1- مراحل تکامل دولت الکترونیک
سازمان ملل برای ارزیابی پیشرفت کشورها در برپایی دولت الکترونیک پنج مرحله زیر را شناسایی نموده است:
• مرحله نوظهور
طی این مرحله تعدادی وب‌سایت ساده و مستقل از هم توسط دستگاه‌های دولتی ایجاد میشود که بر روی آنها اطلاعاتی محدود و پایه‌ای گذاشته میشود.
• مرحله تکامل‌یافته
در این مرحله بر تعداد سایت‌های دولتی افزوده میشود. در این مرحله اطلاعات غنی‌تر و پویا هستند و تغییرات با تواتر بیشتری درسایت‌ها اعمال می‌شوند.
• مرحله تعاملی
در این مرحله کاربران از فرم‌های الکترونیکی استفاده می‌کنند و از طریق اینترنت با مقامات دولتی برای انجام کارهای خود تماس برقرار کرده و درخواست‌ها و قرار ملاقات‌های خود را به صورت on line تنظیم می‌نمایند.
• مرحله تراکنش
طی این مرحله کاربران می‌توانند پرداخت هزینه خدمات و یا انجام تبادلات مالی را از طریق شبکه و به صورت امن انجام دهند.
• مرحله یکپارچه
طی این مرحله کلیه فعالیت‌های دولتی به صورت یکپارچه بر روی شبکه اینترنت ارائه خواهد شد.
5- موانع گسترش دولت الکترونیک
از میان موانع گسترش دولت الکترونیک، می‌توان به سه مورد اصلی اشاره کرد که عبارتند از: فرهنگی، سازمانی و محدودیت منابع.
5-1- عوامل فرهنگی
5-1-1- موقعیت کنونی
بررسی دولت‌ها و مطالعات اولیه آنها برای به اجرا درآوردن طرح دولت الکترونیک نشان داده است که مشکل اصلی ایجاد وتوسعه دولت الکترونیک، تکنولوژی نیست، بلکه مشکل اصلی در این است که آیا فرهنگ جامعه آمادگی پذیرش تغییرات بسیار زیادی که ایجاد خواهد شد را دارد یا خیر.
این تغییرات تأثیر اصلی خود را بر کارمندان دولتی خواهند گذاشت. بررسی‌ها نیز نشان می‌دهد که عده‌ای از کارمندان دولت با تغییرات سریع در نظام اداری مخالفند. درحالی که عده‌ای دیگر با آن موافق بوده و از آن استقبال می‌کنند.
برای راضی کردن عموم مردم نیز باید جامعه را متقاعد کرد که انتقال اطلاعات به قدر کافی امن هست وحریم خصوصی افراد کاملاً رعایت میشود. در ساختار سازمانی یک دولت الکترونیک، کارمندان به جای جلوگیری از خطر و ریسک درکارهای اداری به مدیریت ریسک می‌پردازند.
درچنین محیطی افراد به خلاقیت و نوآوری در کارهای اداری تشویق می‌شوند. همچنین در جامعه اطلاعاتی پیشرفته، شهروندان و واحدهای خصوصی به امنیت سیستم دولت الکترونیک اطمینان داشته و اکثر امور خود را از طریق آن انجام می‌دهند، در چنین فضایی دولت نیز از خلاقیت و نوآوری حمایت می‌کند.
5-1-2- راه رسیدن به محیط فرهنگی مطلوب
عملی ساختن دولت الکترونیک بیش از هر چیز، به مدیریت و راهبری بسیار کارآمد نیاز دارد. این هیأت‌مدیره تنها از متخصصان IT تشکیل نمی‌شوند؛ بلکه در این هیأت افرادی با تخصص‌های اقتصاد، مدیریت و جامعه‌شناسی نیز حضور خواهند داشت. گام اصلی بعدی تنظیم یک برنامه همه جانبه برای ادامه عملی ساختن دولت الکترونیک است.
5-2- عوامل سازمانی و اداری
5-2-1- موقعیت کنونی سازمان‌ها وادارات
درحال حاضر، ادارات دولتی دارای روابط بین سازمانی نیستند و این به دلیل فقدان یک شبکه الکترونیکی مناسب بین آنها است. مسئولان این سازمان‌ها نیز تنها به مدیریت در حوزه درون‌سازمانی عادت کرده‌اند و ارتباط بین سازمانهای مختلف می‌تواند مشکلاتی را برای آنها ایجاد کند. روش تصمیم‌گیری بالا به پایین نیز عامل دیگری است که به مشکلات مدیریتی دامن زده است.
5-2-2- ساختار اداری مطلوب دولت الکترونیک
در یک نظام دولتی الکترونیک، موانع و حصارهای بین سازمانی برداشته میشود و دولت از یک نظام بسته و محتاط به یک نظام باز که در آن نوآوری حرف اول را می‌زند تبدیل میشود.
5-2-3- راه رسیدن به ساختار اداری مطلوب
یکی از راه‌های مؤثر می‌تواند دادن پاداش به کارمندان و مدیرانی باشد که به جا افتادن دولت الکترونیک در سازمان خود کمک می‌کنند. حتی برخی دولت‌ها ارگان‌های خاصی را جهت دنبال کردن این موضوع تاسیس کرده‌اند در همین حال به موازات این فعالیت‌ها، متخصصان IT درحال ساختن زیر بنای لازم برای مرتبط ساختن ارگان‌های مختلف به یکدیگر خواهند بود.
5-3- کمبود منابع
5-3-1- وضعیت حاضر
همانطور که گفته شد در حال حاضر- درجوامع پیشرفته‌ای مثل ایالات متحده - کمبودی از لحاظ منابع تکنولوژیک احساس نمی‌شود؛ اما کمبود نیروی انسانی متخصص چه از لحاظ فنی و چه از نظر مدیریتی یک مشکل عمده در راه سرعت بخشیدن به روند تغیر به دولت الکترونیک به شمار می‌رود. از طرفی به دلیل نو و بدیع بودن این موضوع در واقع می‌توان گفت که هیچ نیروی مدیریتی با تجربه‌ای، برای پیاده‌سازی دولت الکترونیک در سطح جامعه وجود ندارد.
5-3-2- وضعیت مطلوب برای پیاده سازی دولت الکترونیک
یک موج جدید از افراد تحصیل‌کرده در فناوری اطلاعات و مدیریت وارد دولت مرکزی خواهند شد. از طرفی بهتر است دولت تا حد امکان به وسیله آموزش و حقوق بیشتر به جذب افراد شایسته از بین کارکنان فعلی دولت اقدام کند؛ زیرا این افراد با ساختار دولتی و اداری آشنایی بیشتری دارند.
5-3-3- راه رسیدن به وضعیت مطلوب
گرچه استخدام مدیرانی که توانایی‌های گسترده‌ای در فناوری اطلاعات دارند، یک اقدام اساسی و اصولی محسوب میشود؛ اما آموزش مدیران قدیمی و استفاده از آنها این مزیت را دارد که این افراد می‌توانند درهزینه‌ها صرفه‌جویی کرده و اعتبارات مازاد را برای بهبود کیفیت زیرساخت‌های تکنولوژیک دولت الکترونیک به کار گیرند.
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
مقدمه‌ای بر معماری مبتنی بر سرویس (SOA)
معماری مبتنی بر سرویس رویکرد جدیدی در دنیای نرم‌افزار است که با رفع محدودیت‌ها و
نواقص معماری‌های پیشین به عنوان بهترین گزینه در این زمینه محسوب میگردد. در این
مقاله سعی شده است مفاهیم و اصول پایه‌ای این معماری به طور اجمالی مورد بررسی قرار
گیرد.
مقدمه
سیستم‌های اطلاعاتی به سرعت در حال رشد هستند؛ سازمان‌ها نیازمند پاسخگویی سریع به نیازمندیهای جدید کسب‌وکار هستند. این در حالی است که معماری‌های نرم‌افزاری موجود به حد نهایی قابلیت‌های خود رسیده‌اند. معماری مبتنی بر سرویس SOA قدم تکاملی بعدی برای کمک به سازمان‌ها جهت مدیریت چالش‌های پیچیده است.
معماری مبتنی بر سرویس حالت بلوغ یافته معماری مبتنی بر اجزا، طراحی مبتنی بر واسطه (شی‌گرا) و سیستم‌های توزیع شده است. در معماری مبتنی بر اجزا عملکرد کلی به کارهای کوچک‌تری تقسیم میشود که هر یک در یک جزء بسته‌بندی خواهند شد. یک سیستم توزیع‌شده، تعمیمی از یک معماری مبتنی بر اجزا است که به اجزائی که در موقعیت‌های فیزیکی مختلف وجود دارند، اشاره می‌کند.
مهمترین مزیت معماری مبتنی بر اجزا سهولت در استفاده مجدد و تغییر هدف اجزای خاص و سهولت در امر نگهداری سیستم است. استفاده مجدد و تغییر هدف معمولاً مهمترین پیشران‌های کسب‌و کار جهت استفاده از این نوع معماری در دهه 90 میلادی بوده است. بر اساس منطق معماری مبتنی بر سرویس، سیستم‌های نرم‌افزاری بزرگ می‌توانند از گردآوری مجموعه‌هایی از عملکردهای مستقل و قابل استفاده مجدد تشکیل گردند.
برخی از این عملیات می‌تواند از طریق سیستم‌های موجود و یا سیستم‌های دیگر فراهم گردد ولی سایر عملیات لازم باید پیاده‌سازی شوند. هر سرویس امکان دسترسی به مجموعه خوش تعریفی از عملیات را می‌دهد. سیستم به عنوان یک کل به صورت مجموعه‌ای از تعاملات بین این سرویس‌ها طراحی میشود. معماری مبتنی بر سرویس، سرویس‌هایی را که سیستم از آنها تشکیل شده را تعریف می‌کند و تعاملات لازم بین سرویس‌ها جهت ارائه رفتار مشخص را توصیف می‌کند و در نهایت سرویس‌ها را به یک یا چند پیاده‌سازی در تکنولوژی‌های خاص تصویر می‌کند.
SOA بر اساس استفاده از اشیاء و اجزا توزیع شده است و قدم تکامل بعدی در محیط‌های محاسبه‌ای است. این معماری در حال حاضر مدل مرجع استانداردی ندارد؛ اما پیاده‌سازی‌های موجود مفاهیم مشترکی را مورد استفاده قرار می‌دهند که در ادامه این مفاهیم پایه مورد بررسی قرار می‌گیرند.
2- مفاهیم اصلی در معماری مبتنی بر سرویس
در حال حاضر استاندارد مشخصی برای تعریف SOA وجود ندارد اما مواردی که در ادامه می‌آید مهمترین و سازگارترین موارد در پیاده‌سازی SOA هستند.
2-1- سرویس
یک سرویس رفتار تعریف شده قراردادی است که می‌تواند به‌وسیله یک جزء برای استفاده جزء دیگر پیاده‌سازی شده و فراهم گردد.
2-2- شرح سرویس
شرح سرویس پارامترهای فنی، قیود و سیاست‌هایی را شامل میشود که قالب‌های لازم برای فراخوانی سرویس را تعریف می‌کند. هر سرویس باید شامل تعریف سرویس در قالب استاندارد باشد. این موضوع کاربردها و کاربران انسانی را قادر می‌سازد تا با بررسی شرح سرویس و تعیین موضوعاتی نظیر این که سرویس چه کاری انجام می‌دهد، چگونه به آن انتصاب می‌یابند و اینکه چه پروتکل‌های امنیتی (در صورت وجود) باید به همراه آن مورد استفاده قرار گیرد، از آن سرویس استفاده کند.
این اعلان همچنین ممکن است شامل جزئیاتی در مورد هر فرایند ضمنی و دیگر واژه‌های کاری و قانونی باشد که ممکن است در زمان فراخوانی سرویس اتفاق بیفتد. به عنوان مثال، اگر یک استفاده‌کننده سرویس، سرویسی را فراخوانی کند که یک درخواست خرید را برای فراهم‌کننده سرویس ارسال نماید، و اجرا موفقیت‌آمیز باشد، این موضوع ممکن است منجر به مسئولیت مالی نسبت به فراهم‌کننده سرویس یا بخش قانونی دیگر میشود.
در حالیکه طبیعت سرویس‌ها ممکن است تغییر کند، استاندارد مشترکی جهت اعلان یک سرویس هنگام تهیه یک زیرساخت مطلوب است. دو نمونه از چنین استانداردهای موجود ebXML و WSDL هستند.
2-3- اعلان و یابش سرویس‌ها
شرح سرویس باید به شیوه‌ای قابل دسترسی در اختیار کاربران بالقوه قرار گیرد که به این امر اعلان سرویس اطلاق میشود.
یابش، زمانی انجام میشود که یک مشتری بالقوه اطلاعاتی در مورد وجود یک سرویس، پارامترهای قابل اعمال و واژگان آن به دست آورد. یافتن، بحث تصدیق هویت جهت اجرای سرویس را شامل نمی‌شود؛ گرچه این جزئیات ممکن است در الگوی یافتن قرار گیرد.
اجزای اعلان و یابش در SOA به شیوه‌های مختلف از جمله استفاده از روش ثبات / مخزن و یا روش دایرکتوری سرویس قابل پیاده سازی هستند.
• پیاده‌سازی به روش ثبات / مخزن
یک ثبات / مخزن جزئی است که در آن کاربران امکان ذخیره و مدیریت سرویس‌های لازم برای عملکرد سازمانشان را خواهند داشت. این موضوع شامل سرویس‌هایی است که تسهیم بین بیش از یک کاربر (نظیر xml schemas و شرح web-service) را فراهم می‌آورد که به ثبات به گونه‌ای منتسب میشود که ثبات در مورد تمامی رویدادهای قابل ارزیابی نسبت به محصولات در مخزن اطلاع دارد.
• پیاده‌سازی به روش دایرکتوری
دایرکتوری یک واسط است که اطلاعات انتساب به محصولات را فراهم می‌آورد. افرادی که مالک محصولات هستند و یا آنها را کنترل می‌کنند، می‌توانند یک مدخل به دایرکتوری باز کرده تا به محصولات ارجاع داده و خود انتسابات به آن را توضیح دهند. دیگران ممکن است این اطلاعات را بازیابی کرده و از آن جهت انتساب به محصولات استفاده کنند. مهمترین مشکل دایرکتوری این است که هیچ کنترل یا اطلاع‌رسانی در صورت حذف، تغییر و جایگزین شدن یک محصول انجام نمی‌دهد و قادر به اعلام این رویدادها به کاربران نیست.
هر دو پیاده‌سازی دایرکتوری و ثبات / مخزن امکان سازگاری با یکدیگر را دارند. به این معنا که عملکرد اجازه می‌دهد که محتوا از یک پیاده‌سازی توسط یک پیاده‌سازی دیگر مورد ارجاع قرار گیرد.
چندین استاندارد وجود دارد که پیاده‌سازی‌ها دایرکتوری و ثبات / مخزن را دارند. رایج‌ترین استانداردها عبارتند از:
• OASIS ebXML Registry-Repository Technical Specifications16
• OASIS Universal Description and Discovery Interface (UDDI) Technical Specification17.2
2-4- خصوصیات مدل داده‌ای مرتبط
در هنگام فراخوانی یک سرویس، پارامترهای مشخصی ممکن است برای انجام درخواست سرویس مورد نیاز باشد. سرویس همچنین ممکن است پارامترهایی را به کاربر سرویس بازگرداند. W3C WSDL یک نمونه شناخته شده از پیاده‌سازی این بخش است.
3- اصطلاحات رایج در معماری مبتنی بر سرویس
• فراهم‌کننده سرویس: یک موجودیت نرم‌افزاری که خصوصیات سرویس را پیاده‌سازی می‌کند.
• درخواست‌کننده سرویس: یک موجودیت نرم‌افزاری که یک فراهم‌کنندة سرویس را فراخوانی می‌کند، به‌طور سنتی این مورد به عنوان "کلاینت" شناخته میشود؛ اما یک درخواست‌کننده سرویس می‌تواند یک کاربر برنامه کاربردی و یا سرویس دیگر باشد.
• موقیعت‌یاب سرویس: یک نوع خاص از فراهم‌کننده سرویس که به‌عنوان یک ثبات عمل می‌کند و امکان جست‌وجوی واسطه‌های فراهم‌کننده سرویس و موقعیت سرویس را می‌دهد.
• واسط سرویس: یک نوع خاص از فراهم‌کننده سرویس است که می‌تواند درخواست سرویس را به یک یا چند فراهم‌کننده سرویس منتقل کند.
4- چارچوب SOA
4-1- زیرساخت SOA
4-1-1- نقشه مفهومی
شکل‌های 2 تا 4 نقشه‌هایی مفهومی هستند که مفاهیم پایه SOA را مستقل از معنی و تکنولوژی‌ها تشریح می‌کنند. نقشه‌های مفهومی غیر رسمی بوده و نمایش گرافیکی از مفاهیم و رابطه بین آنها را شامل میشود. شکل 2 مثالی از یک نقشة مفهومی است.
شکل1- مثالی از نقشه مفهومی
اغلب معماری‌هایی که SOA نامیده می‌شوند، شامل یک فراهم‌کننده سرویس، یک کاربر سرویس و برخی زیرساخت‌های پیام‌رسانی هستند.
شکل2- مدل مرجع معماری مبتنی بر سرویس پایه
4-1-2- مفاهیم اختیاری و زیرساخت‌های SOA اشتراکی
شکل3-مفاهیم اختیاری برای SOA و نمایش تعامل آنها با مفاهیم پایه این معماری
جهت اجرای تعهدات در زمان اجرا، اغلب SOAها ممکن است شامل مفاهیمی اضافه بر آنچه در شکل 3 نشان داده شده است، باشند. مفاهیم دیگر کاربران سرویس، کلاینت سرویس، قرارداد پذیرش سرویس و فراخوانی سرویس هستند. فراخوانی یک سرویس یا وجود کاربر سرویس در مدل SOAالزامی نیست. فراهم‌کننده یک سرویس، قرارداد سرویس جهت استفاده آن و شرح سرویس را ارائه می‌کند. شرح سرویس به مدل داده‌های مرتبط با فراخوانی سرویس ارجاع می‌کند.
شرح سرویس از طریق یکی از چندین روش اعلان میشود. کاربر سرویس خصوصیات سرویس را از طریق مکانیزم اعلان شناسایی می‌کند. شناسایی، پذیرش قرارداد را شامل نمی‌شود. همچنین فراخوانی سرویس را نیز القا نمی‌کند. این امر صرفاً عملی برای پیدا کردن اطلاعات در مورد سرویس است. این امر لزوماً در یک عمل اتفاق نمی‌افتد و ممکن است به تعدادی از کارها نیاز داشته باشد. همچنین ممکن است از طریق وسایل غیر الکترونیکی صورت پذیرد.
شکل 4 سایر عملکردهای خاص اختیاری را حذف کرده و از پیاده‌سازی‌های خاص نظیر پیام‌رسانیSOAP ، WDSL و ebXML خودداری می‌کند.
4-2- الگوهای SOA
شکل 5 یک الگوی ساده سرویس را نمایش می‌دهد. در جایی که یک فراهم‌کننده سرویس، سرویس را پیشنهاد می‌دهد و یک کاربر سرویس، از سرویس‌ها استفاده می‌کند. چندین نوع از پروتکل‌های ارتباطی ممکن است زوج درخواست/ پاسخ را مورد استفاده قرار دهد و روش‌های متنوعی نظیر سنکرون یا آسنکرون ممکن است استفاده شود. SOA به هیچ پروتکل ارتباطی خاص محدود نمی‌شود. شکل 5 الگوی "درخواست – پاسخ" را نمایش می‌دهد.
شکل4-الگوی پایه برای معماری مبتنی بر سرویس
5- چرخه حیات SOA
بر اساس طرح IBM، برای SOA می‌توان یک چرخه حیات در نظر گرفت. در فاز "مدل" نیازمندیهای کسب‌و کار جمع‌آوری شده و فرایندهای کسب و کار آنها طراحی میشود. بعد از بهینه شدن فرایندها، از طریق کنار هم قرار دادن سرویس‌های موجود و سرویس‌های جدید این فرایندهای کسب‌و کار شکل می‌گیرد. سپس این سرمایه‌ها در یک محیط امن و با قابلیت تجمیع بالا نصب میشود. بعد از نصب فرایندهای کسب و کار، کاربران IBM این فرایندهای کسب و کار را هم از منظر فنی و هم از منظر فرایندهای کسب و کار مورد نظارت و مدیریت قرار می‌دهند.
اطلاعات جمع‌آوری شده در فاز مدیریت به چرخه حیات بازخورد خواهد داشت تا بهبود پیوسته فرایندها را امکان‌پذیر سازد. در زیر همه این مراحل در چرخه حیات، حاکمیت و فرایندهایی هستند که رهنمود‌ها و افق‌های آینده را برای پروژه SOA فراهم می‌کنند.
شکل 5- چرخه حیات معماری مبتنی بر سرویس
6-1- مرحله مدل‌سازی
فاز مدل با جمع‌آوری و تحلیل نیازمندیهای کسب‌و کار آغاز میشود که بعداً برای مدل کردن، شبیه‌سازی و بهینه کردن فرایندهای کسب و کار مورد استفاده قرار می‌گیرند. فرایندهای کسب و کار حاصل برای طراحی سرویس‌های نرم‌افزاری مرتبط و سطوح سرویس جهت حمایت از این فرایندها مورد استفاده قرار می‌گیرند. در طول این فاز، مدلی جهت ایجاد درک مشترک بین کسب و کار و فناوری اطلاعات در فرایندهای کسب و کار، اهداف و خروجی‌ها استفاده میشود. به علاوه این مدل می‌تواند این اطمینان را به وجود آورد که کاربردهای حاصل، نیازمندیهای کسب و کار تعریف شده را براورده می‌سازد. این مدل همچنین می‌تواند مبنایی جهت اندازه‌گیری کارآیی کسب و کار باشد.
6-2- مرحله گردآوری
در طول فاز گردآوری، کتابخانه سرویس‌های موجود می‌تواند جهت یافتن سرویس‌های مورد نظر و موجود در سازمان بررسی شود. در صورتی که سرویس مورد نظر یافت نشد این امکان وجود دارد که یک سرویس جدید ایجاد و پس از تست به مجموعه افزوده شود. هنگامی که سرویس‌های مورد نیاز فراهم شد، سرویس‌ها جهت پیاده‌سازی فرایندهای کسب‌و کار هماهنگ می‌گردند.
6-3- مرحله نصب
در طول فاز پیاده‌سازی، مقیاس و محیط زمان اجرا جهت تأمین نیازمندیهای سطوح سرویس به وسیله فرایندهای کسب‌وکار پیکربندی میشود. پس از پیکربندی یک فرایند کسب‌وکار، امکان پیاده‌سازی آن در یک محیط امن، مطمئن و مقیاس‌پذیر سرویس‌ها وجود خواهد داشت. محیط سرویس‌ها به گونه‌ای بهینه‌سازی میشود که علاوه بر اجرای مطمئن فرایندهای کسب‌وکار، امکان انعطاف‌پذیری جهت بروز کردن به طور پویا و در صورت تغییر نیازمندیهای کسب‌وکار را فراهم می‌آورد. این رویکرد مبتنی بر سرویس همچنین هزینه و پیچیدگی نگهداری سیستم را نیز کاهش می‌دهد.
6-4- مرحله مدیریت
فاز مدیریت شامل نظارت و نگهداری از زمان پاسخ و در دسترس بودن سرویس میشود. همچنین مدیریت منابع سرویس‌های زیرین در این فاز انجام میشود. درک کارایی زمان واقعی فرایندهای کسب‌وکار امکان ایجاد بازخورد ضروری به مدل فرایند کسب و کار جهت بهبود دائمی را فراهم می‌آورد. این کار همچنین مدیریت و نگهداری کنترل نسخه برای سرویس‌های تشکیل دهنده فرایندهای کسب و کار را شامل میشود. فاز مدیریت در نهایت امکان اتخاذ تصمیمات کسب و کار بهتر و سریع‌تر را فراهم می‌سازد.
6-5- مرحله حاکمیت و فرایندها
حاکمیت و فرایندها جهت موفقیت هر نوع پروژه SOA ضروری هستند. جهت تخمین موفقیت، ممکن است یک مرکز تعالی در کسب‌وکار، برای پیاده‌سازی سیاست‌های حاکمیتی و دنبال کردن استانداردهای حاکمیتی بین‌المللی جهت اهداف کنترلی برای اطلاعات و تکنولوژی مرتبط ایجاد گردد. پیاده‌سازی سیاست‌های حاکمیتی قوی می‌تواند منجر به پروژه‌های SOA موفق گردد.
7- خصوصیات اساسی جهت استفادة بهینه از سرویس‌ها
• درشت‌دانه بودن: عملکردها روی سرویس‌ها به طور متفاوت پیاده‌سازی می‌شوند تا کارآیی بیشتری را در برگیرند و بر روی مجموعه‌های داده‌ای بزرگ‌تر در مقایسه با طراحی مبتنی بر اجزا عمل می‌کند. (شکل 8)
• طراحی مبتنی بر واسط: سرویس‌ها، واسط‌های مجزا تعریف‌شده را پیاده‌سازی می‌کنند. مزیت این امر آن است که چندین سرویس می‌توانند یک واسط مشترک را پیاده‌سازی کنند و یک سرویس می‌تواند چندین واسط را پیاده‌سازی کند. (شکل 9)
• قابل یافت بودن: سرویس‌ها لازم است هم در زمان طراحی و هم در زمان اجرا قابل یافت باشند، نه تنها با شناسة یکتا بلکه همچنین با شناسة واسط و با نوع سرویس.
• نمونه منفرد: بر خلاف توسعة مبتنی بر جزء که از اجزا بر حسب نیاز نمونه‌هایی ایجاد میشود، هر سرویس یک نمونه منفرد و همواره در حال اجرا است که مجموعه‌ای از کلاینت‌ها با آن ارتباط برقرار می‌کنند.
• اتصال ست: سرویس‌ها با دیگر سرویس‌ها و کلاینت‌ها از طریق تبادل اطلاعات استاندارد xml با یکدیگر در ارتباط هستند؛ این ارتباط باعث کاهش وابستگی و جداسازی بر اساس پیام‌رسانی میشود.
• آسنکرون: به طور کلی، سرویس‌ها از رویکرد انتقال پیام آسنکرون استفاده می‌کنند. اما این امر ضروری نیست. در بعضی مواقع در پیاده‌سازی سرویس‌ها از انتقال پیام سنکرون نیز استفاده میشود.
در شکل‌های زیر برخی از ویژگی‌های فوق نمایش داده شده است:
شکل 6- تأکید بر درشت‌دانه بودن در سرویس‌ها
شکل 7- طراحی مبتنی بر واسط در معماری سرویس‌گرا
8- مقیاس‌پذیری از طریق رفتار آسنکرون و صف‌بندی
بهتر است که از ماهیت آسنکرون در سرویس‌ها استفاده شود. با توجه به سربار انتقال اضافه و همچنین این انتظار که سرویس‌ها، ماهیتاً در فواصل فیزیکی دور از یکدیگر خواهند بود، کاهش زمان انتظار درخواست‌کننده برای پاسخ بسیار اهمیت دارد. از طریق آسنکرون کردن فراخوانی یک سرویس، با یک پیام بازگشت مجزا، به درخواست‌کننده امکان ادامة اجرا تا زمان فراهم شدن پاسخ داده میشود.
البته این به معنای اشتباه بودن رفتار سنکرون سرویس نیست، بلکه به این معنا است که رفتار سرویس آسنکرون مطلوب است، به خصوص در جایی که هزینه‌های ارتباطی زیاد است و یا تأخیر شبکه قابل پیش‌بینی نیست.
شکل8- روش سنکرون در مقابل روش آسنکرون
با استفاده از فراخوانی آسنکرون، به فراهم‌کننده این امکان داده میشود که از چندین رشتة کاری جهت مدیریت چندین درخواست کلاینت استفاده کند. جهت اجرای فراخوانی آسنکرون، درخواست‌کننده باید نشانی بازگشت را به سرویس پیاده‌ساز یک واسط ارسال کند.
9- جمع‌بندی
معماری مبتنی بر سرویس گام تکاملی بعدی در دنیای نرم‌افزار است. معماری‌های نرم‌افزاری فعلی قادر به حل تمامی مشکلات و چالش‌های فرا روی سازمان‌ها و سیستم‌های اطلاعاتی بزرگ و پیچیده نیستند. ویژگی‌های خاص معماری مبتنی بر سرویس این معماری را به عنوان بهترین گزینه برای این موضوع مطرح کرده است.
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
مبانی مدل سازی برای طراحی پایگاه داده
طراحی پایگاه داده و ایجاد نمودار ارتباط موجودیت ها (ERD) یکی از مهمترین بخش های چرخه حیات توسعه یک نرم افزار است که در برخی موارد از آن به عنوان مهمترین بخش نیز نام برده می شود . مدل صحیح و به هنگام (Up To Date) اطلاعات می تواند به عنوان مهمترین ابزار مرجع برای مدیران بانک اطلاعاتی (DBAs) ، پیاده کنندگان نرم افزار و سایر اعضاء تیم توسعه دهنده نرم افزار باشد . فرآیند ایجاد مدل داده به تیم توسعه دهنده کمک می کند تا به پرسش های مطرح شده توسط کاربران نهائی سیستم پاسخ دهند .همچنین طراحی کارا و موثر پایگاه داده به تیم توسعه دهنده این امکان را می دهد تا سیستم را از همان ابتدا در فرم مناسب پیاده سازی نمایند . ساخت سیستم با کیفیت فوق الذکر این امکان را به تیم توسعه دهنده خواهد داد تا زمان کلی انجام پروژه را کاهش دهند ، که در واقع این امر موجب کاهش هزینه های توسعه پروژه نیز خواهد شد .
با توجه به موارد فوق ، شعار طراحی خوب و جامع پایگاه داده این است که :
اول اندازه بگیر و بعد قیچی کن
طراحان خوب و خبره بانک های اطلاعاتی ، مبانی و اصول نرمال سازی پایگاه داده را همواره در خلال طراحی به خاطر داشته و آن را به کار خواهند گرفت . همانطور که در مقاله نرمال سازی بانک های اطلاعاتی به تفصیل بیان شد ، نرمال سازی فرآیندی در خلال طراحی پایگاه داده است که با چهار هدف عمده ذیل دنبال می شود :
• به حداقل رسانی افزونگی اطلاعات
• به حداقل رسانی تغییر ساختار اطلاعات
• به حداقل رسانی I/O سرور به منظور کاهش تعداد تراکنش ها (Transactions)
• و در نهایت حفظ یکپارچگی اطلاعات
برای طراحی بانک اطلاعاتی نرم افزار و مدل سازی آن می بایست اصول و تکنیک های ذیل را مد نظر داشت و از آنها استفاده نمود .
موجودیت (Entity) ، مجموعه ای از چیزهائی است که مربوط به بانک اطلاعاتی سیستم مورد نظر می باشد و یا به تعبیر دیگر هر آنچه که می خواهید در سیستم راجع به آن اطلاعات جمع آوری و نگهداری نمائید را شامل می شود . در مدل فیزیکی ، موجودیت تبدیل به جدول (Table) می شود .
خصلت (Attribute) یکی از مشخصه های توصیفی و یا مقداری موجودیت می باشد . در مدل فیزیکی یک خصلت به یک ستون (Column) و یا فیلد (Field) تبدیل می شود .
کلید اصلی (Primary Key) خصلت و یا ترکیبی از خصلت ها در یک موجودیت است که تضمین کننده یکتا بودن هر رخداد از موجودیت می باشد . خصلت یا خصلت های کلید اصلی نمی توانند فاقد ارزش باشند (NULL) و معمولا" کمتر تغییر می کنند . معمولا" سعی می شود جهت انتخاب کلید اصلی از خصلت هائی استفاده شود که کارائی بیشتری داشته و بهترین معرف موجودیت باشند (کارائی یک فیلد از نوع Integer به مراتب بیشتر از فیلدی از نوع Char است ) . در صورتیکه نتوان در یک موجودیت خصلت یا خصلت هائی برای کلید اصلی شدن یافت ، آنگاه کلیدهای دستی برای این کار را ایجاد می کنیم که به آنها کلید Artificial می گویند .
ارتباط ( Relationship) ، ارتباط منطقی بین دو موجودیت است . یک ارتباط در واقع نشان دهنده قوانین کاری حاکم بر پروژه و اطلاعات آن است که معمولا" به صورت جملات فعلی توصیف می گردد . مثل ارتباط بین موجودیت کارمند و دپارتمان که به صورت جمله ذیل بیان می شود :
"کارمند شاغل است در دپارتمان" در این مثال ارتباط بین موجودیت کارمند و دپارتمان با جمله "شاغل است" توصیف میگردد .
دو نوع ارتباط می تواند بین موجودیت ها وجود داشته باشد :
• ارتباط یک به چند (One To Many) در این نوع ارتباط ، هر رخداد از موجودیت والد با چندین رخداد در موجودیت فرزند ارتباط دارد . به عنوان مثال چندین کارمند می توانند در یک دپارتمان شاغل به کار باشند .
• ارتباط چند به چند (Many To Many) . در این نوع ارتباط ، چند رخداد از یک موجودیت با چند رخداد از موجودیت دیگر ارتباط دارند . به عنوان مثال اگر یک کارمند بتواند در چند دپارتمان شاغل به کار باشد ، آنگاه ارتباط بین موجودیت کارمند و دپارتمان یک ارتباط چند به چند است . ارتباط چند به چند در طراحی پایگاه داده پذیرفته شده نیست چراکه علاوه بر افزونگی اطلاعات موجب عدم یکپارچگی اطلاعات نیز می گردد ، از اینرو باید این ارتباط طبق فرم چهارم نرمال سازی تبدیل به دو ارتباط یک به چند شود . همانطور که در مقاله نرمال سازی بانک های اطلاعاتی اشاره گردید برای حل این مشکل کافی است یک موجودیت واسط که به آن موجودیت XREF می گویند ایجاد و خصلت های کلید اصلی هردو موجودیت را به این موجودیت رابط منتقل نمود . با این عمل هریک از موجودیت های اصلی به عنوان والد این موجودیت رابط تلقی شده و یک ارتباط یک به چند بین آنها برقرار خواهد شد. در نتیجه یک ارتباط چند به چند تبدیل به دو ارتباط یک به چند خواهد شد . لازم به ذکر است که بسیاری از سیستم های مدیریت بانک های اطلاعاتی رابطه ای ( نظیر MS SQL Server) از ارتباط چند به چند پشتیبانی نمی کنند .
کلید خارجی (Foreign Key) . هرگاه خصلت(های) کلید اصلی موجودیت والد در موجودیت فرزند وجود داشته باشد (بر اساس ارتباط تعریف شده بین دو موجودیت) آنگاه این خصلت ها در موجودیت فرزند ، کلید خارجی نامیده می شوند . در واقع نمی توان هیچ رخدادی در موجودیت فرزند (که دارای کلید خارجی است) ایجاد نمود که رخداد مربوط به آن (بر اساس محتوای خصلت کلید خارجی) قبلا" در موجودیت والد ایجاد نشده باشد . آنگونه که از توصیف فوق استنباط می شود کلید خارجی تضمین کننده یکپارچگی اطلاعات در داخل پایگاه داده است چرا که باعث می شود که هیچ فرزند بدون والدی در بانک اطلاعاتی نداشته باشیم .
ارتباط (RelationShip) بین دو موجودیت به دو مدل ذیل دسته بندی می گردد :
• ارتباط تعریف شده (identifying Relationship) . اگر کلید اصلی جدول والد بخشی (یا تمام) از کلید اصلی جدول فرزند باشد و یا به تعبیر دیگر بخشی از کلید اصلی موجودیت فرزند کلید خارجی نیز باشد ، در این حالت ارتباط مابین این دو موجودیت از نوع تعریف شده است .
• ارتباط تعریف نشده (Non-Identifying Relationship) ، برخلاف مورد فوق اگر کلید اصلی جدول والد در جدول فرزند وجود داشته باشد اما نه به عنوان بخشی از کلید اصلی آن و صرفا" به عنوان یک خصلت غیر کلید ، در این حالت ارتباط بین این دو موجودیت از نوع تعریف نشده می باشد . ارتباط تعریف نشده خود دارای دو حالت متفاوت به شرح ذیل است :
mandatory non-identifying relationship ، زمانی است که خصلت کلید خارجی در موجودیت فرزند نتواند فاقد ارزش باشد (Not Allow NULL)
non-mandatory non-identifying relationship ، زمانی است که خصلت کلید خارجی در موجودیت فرزند بتواند فاقد ارزش باشد (Allow NULL)
Cardinality ، به ما در فهم بیشتر ماهیت ارتباط مابین موجودیت والد و فرزند کمک می کند . جهت تشخیص Cardinality یک ارتباط کافی است به سئوال ذیل پاسخ داده شود :
" چه تعداد رخداد از موجودیت فرزند مرتبط است با هر رخداد از موجودیت والد؟ "
چهار نوع Cardinality مختلف به شرح ذیل وجود دارد :
• One To Zero or Many به این معنی که هر رخداد از موجودیت والد با هیچ و یا چند رخداد از موجودیت فرزند مرتبط است . به این نوع Common Cardinality می گویند.
• One To One Or Many به این معنی که هر رخداد از موجودیت والد با حداقل یک و یا چند رخداد از موجودیت فرزند مرتبط است . به این نوع P Cardinality می گویند .
• One To Zero Or One ، به این معنی که هر رخداد از موجودیت والد با هیچ و یا تنها یک رخداد از موجودیت فرزند مرتبط است . به این نوع Z Cardinality می گویند .
• One to Exactly N ، به این معنی که هر رخداد از موجودیت والد باید با N رخداد از موجودیت فرزند مرتبط باشد . به این نوع N Cardinality می گویند .
خلاصه
• طراحی خوب بانک اطلاعاتی می تواند به تیم توسعه دهنده نرم افزار در کاهش زمان انجام پروژه و هزینه های آن کمک کند .
• طراحی بانک اطلاعاتی و مدل سازی آن به تیم توسعه دهنده نرم افزار کمک خواهد کرد تا درک بهتر و عمیقتری نسبت به نیازمندیهای کاربران نرم افزار پیدا کرده و در نتیجه نرم افزاری را توسعه دهند که در برگیرنده قوانین کاری و خواسته آنها باشد .
• یکی از اهداف اصلی طراحی بانک اطلاعاتی و مدل سازی آن ، مستقل بودن آن از پلت فرم است ، بنابر این اختیار انتخاب محیط و پلت فرم پیاده سازی فیزیکی پایگاه داده با تیم توسعه دهنده بوده و در ماحصل کار هیچ تغییری ایجاد نخواهد کرد .
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
مفاهیم و تعاریف پایگاه داده
قبل از پرداختن به موضوع بانک های اطلاعاتی رابطه ای (Relational Data Base) ، بهتر است اشاره ای به مفاهیم ذیل داشته باشیم :
• موجودیت (Entity)
به هر چیزی (شی ، شخص ، محل و ...) که می خواهیم در یک سیستم راجع به آن اطلاعاتی را جمع آوری ، پردازش و نگهداری نمائیم ، یک موجودیت گفته می شود . تعریف فوق ، متداولترین برداشت اولیه از موجودیت می باشد . مجموعه موجودیت های یک سیستم ، ساختار اطلاعاتی آن سیستم را مشخص می کند . هر موجودیت شامل اجزاء و المان هائی است که آن موجودیت را توصیف می کند که به آنها خصیصه و یا Attribute گفته می شود . هر موجودیت بسته به این که در سیستم مورد مطالعه چه میزان اطلاعات راجع به آن می خواهیم داشته باشیم ، شامل حداقل یک و یا چند خصیصه خواهد بود. از آنجا که هر موجودیت راجع به یک موضوع به خصوص می باشد ، بنابراین یک ارتباط منطقی بین کلیه خصایص موجودیت وجود خواهد داشت .در واقع ، تمام خصائص یک موجودیت توصیف کننده آن موجودیت خواهد بود . برای روشن شدن موضوع بد نیست به نمونه مثال ذیل توجه نمائید :
- موجودیت مشتری شامل خصلت های نام مشتری ، آدرس مشتری ، تلفن مشتری و ... است .
- موجودیت سفارش شامل خصلت های شماره سفارش ، تاریخ سفارش ، نام مشتری ، کالای سفارش شده ، تعداد کالای سفارش شده و ... است
همانگونه که در مثال فوق مشاهده گردید ، تمام خصلت های موجودیت مشتری توصیف کننده یک مشتری و تمام خصلت های موجودیت سفارش توصیف کننده یک سفارش می باشند .
• کلید (Key)
هر رخداد از یک موجودیت را باید بتوان به وسیله یک و یا ترکیبی از چند خصیصه آن به صورت یکتا شناسائی نمود . به تعبیر دیگر ، هر یک از رخدادهای یک موجودیت باید یکتا باشد ، در غیر اینصورت تغییر و یا حذف یک رخداد از موجودیت (در مثال فوق یک مشتری) غیر ممکن خواهد بود . از اینرو از بین خصلت های یک موجودیت یک و یا ترکیبی از چند خصیصه به عنوان کلید آن موجودیت انتخاب می شود . این خصلت (و یا ترکیب خصلت ها) باید بتواند یکتائی هر رخداد از موجودیت را تضمین نماید . در موجودیت سفارش مثال فوق ، خصلت شماره سفارش می تواند بعنوان کلید انتخاب شود .
توضیح : در برخی از موارد در یک موجودیت چندین کلید وجود دارد که به هر یک از آنها یک Candidate Key یا Alternate Key گفته می شود .
در برخی از حالات نمی توان در یک موجودیت هیچ کاندیدی برای کلید یافت ، مانند موجودیت مشتری در مثال فوق . در این موجودیت هیچیک از خصلت ها و یا هیچ ترکیبی از آنها نمی تواند صد درصد تضمین کننده یکتائی آن باشد (با اینکه احتمال وجود دو مشتری هم نام در یک آدرس و با یک شماره تلفن بسیار کم است ، اما باز هم احتمال وقوع دارد) . در چنین مواردی مجبور هستیم یک خصلت به موجودیت اضافه کنیم تا تضمین کننده یکتائی رخدادهای آن باشد . در مثال فوق با اضافه کردن خصلت کد مشتری به موجودیت مشتری ، می توان یکتائی آن را تضمین نمود . به این نکته دقت شود که بسیاری از خصلت های یک موجودیت در کنترل سیستم نیست و از خارج به سیستم تحمیل می گردد . به عنوان مثال ما نمی توانیم تعیین کنیم که نام مشتری های سازمان تکراری نباشد . اما عدم تکراری بودن خصلت هائی که خود ما ایجاد نموده ایم را می توان تضمین کرد ( نظیر کد مشتری که توسط سیستم و یا سازمان مربوطه تولید می شود ) .
• کلید اصلی (Primary Key)
از بین کلیدهای یک موجودیت (Candidate Key) ، می بایست یک کلید را به عنوان کلید اصلی انتخاب نمود . معیارهای مختلفی در این انتخاب دخیل هستند ، اما معمولا" بهترین کلیدی که معرف مفهوم و ماهیت موجودیت باشد به عنوان کلید اصلی انتخاب می گردد .
• وابستگی تابعی (Functional Dependency)
وابستگی تابعی مفهومی است که مابین خصلت های یک موجودیت تعریف می گردد . به این معنی که می گوئیم خصلت A با خصلت B وابستگی تابعی دارد ، در صورتیکه به ازای هر مقدار مشخص از خصلت B بتوان مقدار مشخص و یکتائی از خصلت A را بدست آورد ، اما عکس آن ممکن است صادق نباشد . در موجودیت مشتری مثال قبل ، به ازای هر کد مشتری می توان نام او را بدست آورد در این صورت می گوئیم خصلت نام مشتری با خصلت کد مشتری وابستگی تابعی دارد . اما عکس آن صادق نیست چرا که به ازای یک نام مشتری مشخص ، نمی توان یک کد مشتری یکتا استخراج نمود (دو مشتری مختلف می توانند نام یکسان داشته باشند ، در این حالت یک نام مشتری ممکن است متناظر با دو و یا حتی چند کد مشتری باشد).
• انواع رابطه بین خصلت های یک موجودیت
بین خصلت های یک موجودیت سه نوع رابطه وجود دارد :
- رابطه یک به یک (One To One) : در حالتی اتفاق می افتد که خصلت A وابستگی تابعی به خصلت B داشته باشد و خصلت B نیز وابستگی تابعی به خصلت A داشته باشد . در این حالت هر دو خصلت A و B کاندیدای کلید شدن می باشند.
- رابطه یک به چند (One To Many) : اگر خصلت A وابستگی تابعی به خصلت B داشته باشد و عکس آن صادق نباشد ، یک ارتباط از نوع یک به چند وجود خواهد داشت . در این حالت ، خصلت B کاندید کلید شدن است و خصلت A صرفا" یکی از توصیف گرهای موجودیت محسوب می گردد .
- رابطه چند به چند (Many To Many) : اگر دو خصلت هیچکدام وابستگی تابعی به یکدیگر نداشته باشند آنگاه رابطه بین آنها چند به چند خواهد بود . در این حالت هیچیکدام از آنها کاندید کلید شدن نبوده (ممکن است ترکیب آنها کاندید کلید شدن باشد) و صرفا" توصیف کننده موجودیت خواهند بود .
• هنجار سازی (Normalization)
هنجار سازی ، فرآیندی است که طی آن یک موجودیت جهت به حداقل رسانی نابهنجاری های بوجود آمده در خلال تغییرات اعمال شده بر روی رخدادهای یک موجودیت مورد بررسی و تبدیل قرار می گیرد. اگر این فرآیند به طور صحیح بر روی یک موجودیت اعمال نگردد ، آنگاه نمی توان هیچ تضمینی در خصوص حفظ یکپارچگی اطلاعات آن موجودیت ارائه داد . فرآیند هنجار سازی به دلیل اهمیت و گستردگی آن در مقاله ای جداگانه تشریح خواهد شد.
• نا بهنجاری
به پیامدهای ناخواسته تغییر اطلاعات نابهنجاری گفته می شود .
• Relation
موجودیت ها در مدل منطقی داده های سیستم مورد بحث و بررسی قرار می گیرند و پس از طی فرآیند هنجارسازی در مرحله فیزیکی به صورت ماتریسهای دوبعدی مشتمل بر سطرها (رخدادهای مختلف یک موجودیت) و ستون ها (خصلت های مختلف آن موجودیت) تعریف می گردند . هر یک از این ماتریس ها را یک ارتباط یا Relation می نامند که در مدل فیزیکی معمولا" آنها را با نام جدول (Table) معرفی می کنند . همانطور که پیش از این اشاره شد تمام خصلت های یک موجودیت با یکدیگر ارتباط منطقی داشته و معرف آن موجودیت می باشند ، از اینرو به این جداول ارتباط می گویند .
• Tuple
هر یک از رخدادهای مختلف یک موجودیت را یک Tuple می گویند که در مدل فیزیکی معمولا" از آنها با نام ردیف (Row) و یا رکورد (Record) نام برده می شود . بنابراین Tuples ، ردیف های جدول دو بعدی هستند که آن را به عنوان Relation و یا Table می شناسیم .
• Attribute
هریک از خصلت های مختلف یک موجودیت را Attribute می نامند ( نظیر کد مشتری ) . معمولا" در مدل فیزیکی به جای Attribute از فیلد (Field) و یا ستون (Column) استفاده می شود . بنابراین Attributes ، ستون های جدول دو بعدی هستند که آن را به عنوان Relation و یا Table می شناسیم .
شکل زیر یک Relation را به همراه اجزاء آن نشان می دهد :
یک Relation به همراه اجزاء آن
• ارتباط (Relationship)
منظور ارتباط بین دو Relation و یا جدول است که بر اساس برابری فیلدهای یکسان در هر جدول تعریف و دارای انواع مختلفی است . ( به دلیل اهمیت و گستردگی ، در مقاله ای جداگانه تشریح خواهد شد) . این ارتباط ها در مدل منطقی مابین موجودیت ها (خصوصا" موجودیت های نرمال شده ) تعیین می گردند و به آن Entity Relation یا ER سیستم می گویند . مدل ER سیستم توسط ابزارهای مستند سازی جهت درک بهتر مدل داده ای سیستم ترسیم می گردد که به آنها ERD می گویند .
پس از تشریح برخی از مفاهیم اولیه و در عین حال مهم بانک های اطلاعاتی رابطه ای ، به اختصار می توان گفت که یک بانک اطلاعات رابطه ای مجموعه ای از رابطه ها (Relations) و یا جداول به همراه تمامی ارتباط هائی (Relationship) است که بین آنها وجود دارد . هر بانک اطلاعاتی در خصوص یک سیستم مورد نظر طراحی و ایجاد می گردد ، اما در برخی از سازمان های بزرگ که بین سیستم های مختلف آن ارتباط وجود دارد (نظیر سیستم پرسنلی ، حقوق و دستمزد و مالی و ...) ممکن است بانک های اطلاعاتی با یکدیگر تجمیع و پس از طی فرآیند یکپارچه سازی به صورت یک بانک اطلاعاتی جامع و یکپارچه برای آن سازمان تعریف و ایجاد گردد .
امروزه سیستم های مدیریتی بانک های اطلاعاتی رابطه ای مختلفی وجود دارد که هر یک ویژگی ها و قابلیت هایی خاص خود را دارند . به این سیستم ها و یا نرم افزارها اختصارا" RDBMS گفته می شود . MS ACCESS ، MS SQL ، ORACLE ، SYBASE ، نمونه هائی متداول در این زمینه می باشند .
تمامی سیستم های مدیریت بانک های اطلاعاتی رابطه ای به منظور ارائه قابلیت های خود و استفاده از آنها از زبان مشترکی که به آن SQL ( برگرفته شده از Structured Query Language ) گفته می شود ، استفاده می نمایند . تمامی نیازها و انتظارات کاربران از بانک های اطلاعاتی نظیر جستجوی اطلاعات ، ایجاد ، تغییر و یا حذف اطلاعات حتی ایجاد بانک اطلاعاتی و یا سایر اجزاء مرتبط با آن توسط زبان فوق تعریف و تحویل RDBMS داده خواهد شد تا پس از بررسی بر روی بانک اعمال گردد.
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
نرمال سازی بانک های اطلاعاتی
نرمال سازی ( Normalization ) یا به تعبیری هنجار سازی فرآیندی است در رابطه با بانک های اطلاعاتی که با دو هدف عمده زیر انجام می شود :
• کاهش افزونگی اطلاعات ، به این معنی که اطلاعات فقط در یک مکان (جدول) ذخیره و در تمام بانک با استفاده از روابط منطقی تعریف شده (RelationShip) قابل دسترسی باشد .
• حفظ یکپارچگی اطلاعات ، به این معنی که اعمال تغییرات بر روی اطلاعات ( نظیر ایجاد ، بهنگام سازی و حذف ) در یک مکان انجام و به دنبال آن آثار تغییرات در تمام بانک مشاهده گردد . برای روشن شدن مفهوم یکپارچگی بد نیست به مثال ذیل توجه نمائید :
فرض کنید در یک بانک اطلاعاتی دارای دو موجودیت کتاب و نویسنده باشیم . هر یک از موجودیت های فوق دارای المان های اطلاعاتی (Attribute) مختص به خود می باشند . به عنوان نمونه موجودیت "کتاب" دارای المان اطلاعاتی نام نویسنده و موجودیت "نویسنده " دارای المان های اطلاعاتی متعددی نظیر نام نویسنده ، آدرس نویسنده و ... باشد . در صورتی که در موجودیت "کتاب" یک رخداد (رکورد) ایجاد نمائیم بدون اینکه نام نویسنده آن را در موجودیت "نویسنده" ایجاد کرده باشیم ، دچار یک ناهمگونی اطلاعات خواهیم شد .
با توجه به اهداف فوق می توان گفت که فرآیند نرمال سازی از ناهنجاری های بوجود آمده به دلیل بروز تغییرات در بانک جلوگیری خواهد نمود . با اعمال فرآیند نرمال سازی ، یک بانک اطلاعاتی کارآ و مطمئن را خواهیم داشت .
فرآیند نرمال سازی ، فرم های متفاوتی دارد که انواع متداول آن به شرح ذیل است :
• فرم اول نرمال سازی 1NF
• فرم دوم نرمال سازی 2NF
• فرم سوم نرمال سازی 3NF
• فرم بویس کد نرمال سازی BCNF
• فرم چهارم نرمال سازی 4NF
فرم اول نرمال 1NF
موجودیت و یا جدولی در فرم اول نرمال است که تمامی المان های اطلاعاتی آن ( منظور Attribute است ) یکتا و یا اصطلاحا" atomic باشند . برای روشن شدن این موضوع فرض کنید دارای موجودیتی با نام "فاکتور فروش " باشیم .
فاکتور فروش
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری
کالای 1
تعداد کالای 1
قیمت واحد کالای 1
.
.
.
کالای n
تعداد کالای n
قیمت واحد کالای n
با مشاهده موجودیت فوق متوجه این موضوع خواهیم شد که المان های کالا ، تعداد کالا و قیمت واحد کالا بیش از یک مرتبه در موجودیت وجود داشته و اصطلاحا" یک گروه تکرار را تشکیل می دهند . برای اجرای مدل فیزیکی این موجودیت ناچار خواهیم بود در طراحی جدول آرایه ای به طول ثابت ( به عنوان نمونه با ده عضو ) تعریف و در آن به ترتیب کالای 1 تا 10 را تعریف نمائیم .
مشکل : طراحی فوق ما را با دو مشکل عمده روبرو خواهد ساخت : اول این که کارائی بانک اطلاعاتی پائین خواهد آمد (اگر در آینده تعداد کالاهای فاکتور فروش بیش از 10 کالا باشد ، آنگاه مجبور خواهیم بود طراحی جدول مربوطه و متعاقب آن نرم افزارهائی که از آن استفاده می کنند را تغییر دهیم ) و مشکل دوم این که بسیاری از فاکتورها لزوما" دارای 10 کالا نیستند و بنابراین محتوی بسیاری از فیلدها در جدول فوق خالی (دارای ارزش Null) خواهد ماند و حجم زیادی از فضای دیسک هدر خواهد رفت .
راه حل : برای حل این مشکل کافی است تمامی گروه های تکرار و یا آرایه ها را از موجودیت خارج کرده و به موجودیت دیگری منتقل نمائیم . در چنین مواردی ، کلید اصلی موجودیت اول را به عنوان بخشی از کلید اصلی موجودیت جدید قرار داده و با تلفیق یکی دیگر از آیتم های اطلاعاتی موجودیت جدید که تضمین کننده یکتا بودن رکوردهای آن موجودیت ( جدول ) است ، کلید اصلی موجودیت ایجاد می گردد . بدین ترتیب ، یک ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر برقرار خواهد شد .
مجددا" به موجودیت "فاکتور فروش " مثال قبل پس از تبدیل به فرم اول نرمال توجه نمائید :
ردیف های فاکتور فروش
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر
(فاکتور فروش) فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
قیمت واحد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری
به طور خلاصه می توان گفت که هدف از فرم اول نرم سازی حذف گروه های تکرار و آرایه ها از موجودیت یا جدول است . فرآیند فوق ، می بایست بر روی تمامی موجودیت های بانک اطلاعاتی اعمال گردد تا بتوان گفت بانک اطلاعاتی نرمال شده در فرم اول است .
فرم دوم نرمال 2NF
موجودیتی در فرم دوم نرمال است که اولا" در فرم اول نرمال باشد و ثانیا" تمامی آیتم های (Attribute) غیر کلیدی آن وابستگی تابعی به تمام کلید اصلی موجودیت داشته باشند نه به بخشی از آن .همانگونه که از تعریف فوق استنباط می گردد ، فرم دوم نرمال سازی در خصوص موجودیت هائی بررسی و اعمال می شود که دارای کلید اصلی مرکب هستند ( بیش از یک جزء ) . بنابراین در مثال فوق موجودیت "فاکتور فروش " به خودی خود در فرم دوم نرمال است ولی موجودیت "ردیف های فاکتور فروش " که دارای کلید اصلی مرکب است ، نیاز به بررسی دارد .
مشکل : در صورتی که موجودیت در فرم دوم نرمال نباشد ، آنگاه با تغییر اطلاعات قسمت های غیروابسته به تمام کلید ، این تغییرات در یک رکورد اعمال می شود ولی تاثیری بر روی سایر رکوردها و یا جداول نخواهد داشت . در مثال فوق با تغییر محتوی قیمت واحد در موجودیت "فاکتور فروش " ، قیمت واحد کالا در یک فاکتور فروش اصلاح می گردد اما در سایر فاکتورها اعمال نخواهد شد .
راه حل : برای حل این مشکل کافی است موجودیت جدیدی ایجاد نمائیم و کلید اصلی آن را برابر با آن بخش از کلید اصلی موجودیت مورد بررسی که دارای المان های وابسته به آن است قرار دهیم ، سپس تمام المان های اطلاعاتی وابسته تابعی به این کلید را از موجودیت مورد بررسی خارج کرده و به موجودیت جدید منتقل نمائیم . در این حالت بین موجودیت جدید ایجاد شده و موجودیت نرمال شده ، بر اساس کلید اصلی موجودیت جدید ایجاد شده یک ارتباط پدر فرزندی تعریف خواهد شد . دقت کنید که بر عکس نرمال سازی فرم اول ، در این جا موجودیت موردبررسی فرزند بوده و موجودیت جدید پدر خواهد بود .
به مثال فوق برمی گردیم و فرم دوم نرمال سازی را بر روی آن اعمال می نمائیم . موجودیت "فاکتور فروش" دارای کلید مرکب نیست پس در فرم دوم نرمال بوده و نیاز به بررسی ندارد ، اما موجودیت "ردیف های فاکتور فروش" نیاز به بررسی دارد . در این موجودیت آیتم اطلاعاتی "قیمت واحد" وابستگی تابعی به آیتم کالا دارد که بخشی از کلید است نه کل کلید ، پس لازم است تا این موجودیت را تبدیل به فرم دوم نرمال نمائیم . بدین منظور موجودیتی به نام "کالا" ایجاد کرده ، کلید اصلی آن را برابر کالا قرار داده و آیتم قیمت واحد را از موجودیت ردیف های فاکتور فروش خارج نموده و به این موجودیت منتقل می نمائیم. مثال فوق پس از تبدیل به فرم دوم نرمال به شکل ذیل خواهد بود :
ردیف های فاکتور فروش
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش) فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا)
کالا
کالا (کلید اصلی)
قیمت واحد
فرم سوم نرمال 3NF
موجودیت و یا جدولی در فرم سوم نرمال است که اولا" در فرم دوم نرمال بوده و ثانیا" تمام آیتم های غیر کلید آن وابستگی تابعی به کلید اصلی داشته باشند ، نه به یک آیتم غیر کلید .
مشکل : در صورتی که موجودیتی در فرم سوم نرمال نباشد ، آنگاه با تغییر آیتم یا آیتم های اطلاعاتی غیر وابسته به کلید اصلی در یک رکورد، تغییرات در سایر رکوردها اعمال نخواهد شد و دچار دوگانگی اطلاعات خواهیم شد (مثلا" یک مشتری با دو نام متفاوت) .
راه حل : کافی است آیتم های غیر کلیدی به هم وابسته را به موجودیت جدیدی منتقل و کلید اصلی موجودیت جدید را تعیین نمائیم ، آنگاه کلید اصلی موجودیت جدید را در موجودیت نرمال شده به عنوان یک کلید خارجی (Foreign Key) در نظر گرفت . در موجودیت "فاکتور فروش" مثال فوق آیتم نام مشتری وابستگی تابعی به آیتم کد مشتری دارد که خود یک آیتم غیر کلید است بنابر این باید نرمال سازی فرم سوم در خصوص آن اعمال شود . شکل ذیل نحوه انجام این کار را نشان می دهد :
ردیف های فاکتور فروش
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش) فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری (کلید خارجی)
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا) ارتباط بین موجودیت پدر
( مشتری ) و فرزند بر اساس کلید خارجی
کالا مشتری
کالا (کلید اصلی)
قیمت واحد کدمشتری (کلید اصلی)
نام مشتری
فرم بویس کد نرمال BCNF
فرم بویس کد دارای مفهوم جامع تری نسبت به فرم دوم و سوم نرمال است . در فرم دوم و سوم نرمال بحث بر سر وابستگی تابعی آیتم های غیر کلیدی به کلید اصلی است . اما در فرم بویس کد ، موجودیتی در فرم بویس کد نرمال است که اولا" در فرم اول نرمال بوده و ثانیا" تمام المان های غیر کلیدی آن کاملا" وابسته تابعی به یک کلید باشند و نه چیز دیگر . نکته حائز اهمیت در این فرم این است که بحث بر سر وابستگی تابعی با یک کلید است نه فقط کلید اصلی. مفهوم فوق در خصوص موجودیت هائی که دارای چندین کلید هستند (Alternate Key) مطرح می شود .
فرم چهارم نرمال 4NF
این فرم در خصوص موجودیت هائی است که ارتباط بین المان های آن یک ارتباط چند ارزشه و یا چند به چند باشد . به عنوان مثال ، موجودیت کلاس درس می تواند شامل چندین دانش آموز و چندین معلم باشد. در چنین مواردی ارتباط بین معلم و دانش آموز یک ارتباط چند به چند می باشد . در این حالت با ایجاد یک موجودیت رابط مابین موجودیت های مذکور، مشکل ارتباط چند به چند حل خواهد شد (بسیاری از سیستم های مدیریت بانک های رابطه ای نظیر MSSQL از رابطه چند به چند پشتیبانی نمی نمایند ، یعنی نمی توان بین دو جدول یک رابطه چند به چند ایجاد نمود). معمولا" تمام المان های موجودیت رابط ایجاد شده بخشی از کلید اصلی است .
خلاصه
نرمال سازی فرم های دیگری نیز دارد که به دلیل نادر بودن و خاص بودن آنها در این مقاله به آنها اشاره نشده است . آنچه در خصوص نرمال سازی عمومیت دارد تا فرم سوم آن است ، یعنی در هنگام طراحی بانک های اطلاعاتی حتما" می بایست فرآیند نرمال سازی تا فرم سوم را انجام داد .
فرآیند نرمال سازی یک فرآیند تکراری (Recursive) است یعنی پس از هر مرحله نرمال سازی که منجر به ایجاد موجودیت های جدید می گردد ، فرآیند را باید از ابتدا تا انتها بر روی موجودیت های تازه ایجاد شده نیز اجرا نمود.
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
هوش مصنوعی
هوش مصنوعی (artificial intelligence) را باید عرصهٔ پهناور تلاقی و ملاقات بسیاری از دانشها، علوم، و فنون قدیم و جدید دانست. ریشه‌ها و ایده‌های اصلی آن را باید در فلسفه، زبان‌شناسی، ریاضیات، روان‌شناسی، نورولوژی، و فیزیولوژی نشان گرفت و شاخه‌ها، فروع، و کاربردهای گونه‌گونه و فراوان آن را در علوم رایانه، علوم مهندسی، علوم زیست‌شناسی و پزشکی، علوم ارتباطات و زمینه‌های بسیار دیگر.
هدف هوش مصنوعی بطور کلی ساخت ماشینی است که بتواند «فکر» کند. اما برای دسته بندی و تعریف ماشینهای متفکر، می‌بایست به تعریف «هوش» پرداخت. همچنین به تعاریفی برای «آگاهی» و «درک» نیز نیازمندیم و در نهایت به معیاری برای سنجش هوش یک ماشین نیازمندیم.
با وجودی که برآورده سازی نیازهای صنایع نظامی، مهمترین عامل توسعه و رشد هوش مصنوعی بوده‌است، هم اکنون از فراورده‌های این شاخه از علوم در صنایع پزشکی، رباتیک، پیش بینی وضع هوا، نقشه‌برداری و شناسایی عوارض، تشخیص صدا، تشخیص گفتار و دست خط و بازی‌ها و نرم افزارهای رایانه‌ای استفاده میشود مباحث هوش مصنوعی پیش از بوجود آمدن علوم الکترونیک، توسط فلاسفه و ریاضی دانانی نظیر بول (Boole) که اقدام به ارائه قوانین و نظریه‌هایی در باب منطق نمودند، مطرح شده بود. در سال ۱۹۴۳، با اختراع رایانه‌های الکترونیکی، هوش مصنوعی، دانشمندان را به چالشی بزرگ فراخواند. بنظر می‌رسید، فناوری در نهایت قادر به شبیه سازی رفتارهای هوشمندانه خواهد بود.
با وجود مخالفت گروهی از متفکرین با هوش مصنوعی که با دیده تردید به کارآمدی آن می‌نگریستند تنها پس از چهار دهه، شاهد تولد ماشینهای شطرنج باز و دیگر سامانه‌های هوشمند در صنایع گوناگون هستیم.
نام هوش مصنوعی در سال ۱۹۶۵ میلادی به عنوان یک دانش جدید ابداع گردید. البته فعالیت درزمینه این علم از سال ۱۹۶۰ میلادی شروع شده بود.
بیشتر کارهای پژوهشی اولیه در هوش مصنوعی بر روی انجام ماشینی بازی‌ها و نیز اثبات قضیه‌های ریاضی با کمک رایانه‌ها بود. در آغاز چنین به نظر می‌آمد که رایانه‌ها قادر خواهند بود چنین اموری را تنها با بهره گرفتن از تعداد بسیار زیادی کشف و جستجو برای مسیرهای حل مسئله و سپس انتخاب بهترین آنها به انجام رسانند.
هنوز تعریف دقیقی که مورد قبول همهٔ دانشمندان این علم باشد برای هوش مصنوعی ارائه نشده‌است، و این امر، به هیچ وجه مایهٔ تعجّب نیست. چرا که مقولهٔ مادر و اساسی‌تر از آن، یعنی خود هوش هم هنوز بطور همه‌جانبه وفراگیر تن به تعریف نداده‌است. در واقع، می‌توان نسل‌هایی از دانشمندان را سراغ گرفت که تمام دوران زندگی خود را صرف مطالعه و تلاش در راه یافتن جوابی به این سؤال عمده نموده‌اند که: هوش چیست؟ اما اکثر تعریف‌هایی که در این زمینه ارایه شده‌اند بر پایه یکی از ۴ باور زیر قرار می‌گیرند:
سیستم‌هایی که به طور منطقی فکر می‌کنند
سیستم‌هایی که به طور منطقی عمل می‌کنند
سیستم‌هایی که مانند انسان فکر می‌کنند
سیستم‌هایی که مانند انسان عمل می‌کنند
شاید بتوان هوش مصنوعی را این گونه توصیف کرد:«هوش مصنوعی عبارت است از مطالعه این که چگونه کامپیوترها را می‌توان وادار به کارهایی کرد که در حال حاضر انسان‌ها آنها رابهتر انجام می‌دهند».
فلسفۀ هوش مصنوعی
بطور کلی ماهیت وجودی هوش به مفهوم جمع آوری اطلاعات, استقرا و تحلیل تجربیات به منظور رسیدن به دانش و یا ارایه تصمیم میباشد . در واقع هوش به مفهوم به کارگیری تجربه به منظور حل مسایل دریافت شده تلقی میشود. هوش مصنویی علم و مهندسی ایجاد ماشینهایی با هوش با به کارگیری از کامپیوتر و الگوگیری از درک هوش انسانی و نهایتا دستیابی به مکانیزم هوش مصنوعی در سطح هوش انسانی میباشد.
در مقایسه هوش مصنوعی با هوش انسانی می توان گفت که انسان قادر به مشاهده و تجزیه و تحلیل مسایل در جهت قضاوت و اخذ تصمیم میباشد در حالی که هوش مصنوعی مبتنی بر قوانین و رویه هایی از قبل تعبیه شده بر روی کامپیوتر میباشد. در نتیجه علی رغم وجود کامپیوترهای بسیار کارا و قوی در عصر حاضر ما هنوز قادر به پیاده کردن هوشی نزدیک به هوش انسان در ایجاد هوشهای مصنوعی نبوده ایم.
بطور کلّی، هوش مصنوعی را می توان از زوایای متفاوتی مورد بررسی و مطالعه قرار داد. مابین هوش مصنوعی به عنوان یک هدف، هوش مصنوعی به عنوان یک رشته تحصیلی دانشگاهی، و یا هوش مصنوعی به عنوان مجموعۀ فنون و راه کارهایی که توسط مراکز علمی مختلف و صنایع گوناگون تنظیم و توسعه یافته است باید تفاوت قائل بود.
مدیریت پیچیدگی
ایجاد و ابداع فنون و تکنیک‌های لازم برای مدیریّت پیچیدگی را باید به عنوان هستۀ بنیادین تلاش‌های علمی و پژوهشی گذشته، حال، و آینده، در تمامی زمینه‌های علوم رایانه، و به ویژه، در هوش مصنوعی معرّفی کرد. شیوه‌ها و تکنیک‌های هوش مصنوعی، در واقع، برای حلّ آن دسته از مسائل به وجود آمده است که به طور سهل و آسان توسط برنامه‌نویسی تابعی (Functional programming)، یا شیوه‌های ریاضی قابل حلّ نبوده‌اند.
در بسیاری از موارد، با پوشانیدن و پنهان ساختن جزئیّات فاقد اهمّیّت است که بر پیچیدگی فائق می‌آییم، و می‌توانیم بر روی بخش‌هایی از مسئله متمرکز شویم که مهم‌تر است. تلاش اصلی، در واقع، ایجاد و دستیابی به لایه‌ها و ترازهای بالاتر و بالاتر تجرید را نشانه می‌رود، تا آنجا که، سر‌انجام برنامه‌های کامپوتری درست در همان سطحی کار خواهند کرد که خود انسان‌ها به کار مشغولند.
به یاری پژوهش‌های گسترده دانشمندان علوم مرتبط، هوش مصنوعی از آغاز پیدایش تاکنون راه بسیاری پیموده‌است. در این راستا، تحقیقاتی که بر روی توانایی آموختن زبانها انجام گرفت و همچنین درک عمیق از احساسات، دانشمندان را در پیشبرد این علم، یاری کرده‌است. یکی از اهداف متخصصین، تولید ماشینهایی است که دارای احساسات بوده و دست کم نسبت به وجود خود و احساسات خود آگاه باشند. این ماشین باید توانایی تعمیم تجربیات قدیمی خود در شرایط مشابه جدید را داشته و به این ترتیب اقدام به گسترش دامنه دانش و تجربیاتش کند.
برای نمونه به رباتی هوشمند بیاندیشید که بتواند اعضای بدن خود را به حرکت درآورد، او نسبت به این حرکت خود آگاه بوده و با سعی و خطا، دامنه حرکت خود را گسترش می‌دهد، و با هر حرکت موفقیت آمیز یا اشتباه، دامنه تجربیات خود را وسعت بخشیده و سر انجام راه رفته و یا حتی می‌دود و یا به روشی برای جابجا شدن، دست می‌یابد، که سازندگانش، برای او، متصور نبوده‌اند.
هر چند مثال ما در تولید ماشینهای هوشمند، کمی آرمانی است، ولی به هیچ عنوان دور از دسترس نیست. دانشمندان، عموماً برای تولید چنین ماشینهایی، از تنها مدلی که در طبیعت وجود دارد، یعنی توانایی یادگیری در موجودات زنده بخصوص انسان، بهره می‌برند.
آنها بدنبال ساخت ماشینی مقلد هستند، که بتواند با شبیه‌سازی رفتارهای میلیونها یاخته مغز انسان، همچون یک موجود متفکر به اندیشیدن بپردازد.
هوش مصنوعی که همواره هدف نهایی دانش رایانه بوده‌است، اکنون در خدمت توسعه علوم رایانه نیز است. زبانهای برنامه نویسی پیشرفته، که توسعه ابزارهای هوشمند را ممکن می‌سازند، پایگاههای داده‌ای پیشرفته، موتورهای جستجو، و بسیاری نرم‌افزارها و ماشینها از نتایج پژوهش‌های هوش مصنوعی بهره می‌برند.
سیستمی که عاقلانه فکر کند. سامانه‌ای عاقل است که بتواند کارها را درست انجام دهد. در تولید این سیستم‌ها نحوه اندیشیدن انسان مد نظر نیست. این سیستم‌ها متکی به قوانین و منطقی هستند که پایه تفکر آنها را تشکیل داده و آنها را قادر به استنتاج و تصمیم گیری می‌نماید. آنها با وجودی که مانند انسان نمی‌اندیشند، تصمیماتی عاقلانه گرفته و اشتباه نمی‌کنند. این ماشینها لزوما درکی از احساسات ندارند. هم اکنون از این سیستم‌ها در تولید عامل‌ها در نرم افزارهای رایانه‌ای، بهره گیری میشود. عامل تنها مشاهده کرده و سپس عمل می‌کند.
سیستم‌های خبره
سیستم‌های خبره زمینه‌ای پرکاربرد در هوش مصنوعی و مهندسی دانش است که با توجّه به نیاز روز افزون جوامع بر اتخاذ راه حل‌ها و تصمیمات سریع در مواردی که دانش‌های پیچیده و چندگانهٔ انسانی مورد نیاز است، بر اهمیت نقش آنها افزوده هم میشود. سیستم‌های خبره به حل مسائلی می‌پردازند که به طور معمول نیازمند تخصّص‌های کاردانان و متخصّصان انسانی‌ست. به منظور توانایی بر حل مسائل در چنین سطحی (ترازی)، دسترسی هرچه بیشتر اینگونه سامانه‌ها به دانش موجود در آن زمینه خاص ضروری میگردد.
عامل‌های هوشمند
عامل‌ها (Agents) قادر به شناسایی الگوها، و تصمیم گیری بر اساس قوانین فکر کردن خود می باشند. قوانین و چگونگی فکر کردن هر عامل در راستای دستیابی به هدفش، تعریف میشود. این سیستم‌ها بر اساس قوانین خاص خود فکر کرده و کار خودرا به درستی انجام می‌دهند. پس عاقلانه رفتار می‌کنند، هر چند الزاما مانند انسان فکر نمی‌کنند.
ایلین ریچ، هوش مصنوعی(وتکنیک‌ها)، ترجمه آزاد از دکتر مهرداد فهیمی، نشر جلوه، ۱۳۷۵، وب‌گاه سیمرغ هوش مصنوعی: به شیوه‌ای مدرن هوش مصنوعی: راهنمائی برای سامانه‌های هوشمند این کتاب به صورتی ساده و روان نوشته شده‌است. Nisenfeld, A. E., Artificial Intelligence Handbook: Principles, Instrument Society of America, ۱۹۸۹. ISBN: ۱ - ۵۵۶۱۷
+ نوشته شده در ساعت توسط فرهاد شرف پور | نظر بدهید
________________________________________
بسم الله الرحمن الرحیم
بانام او آغاز کردیم ...
و با یاد او دل به راهی سپردیم که فقط امید به رسیدن ما را دلگرم کرده ، امید به نجات .
و با امید به یاری او قدم به عرصه عشاق گذاشتیم , تنها نجاتگر عالم , ابا صالح المهدی (عج)
و چه مهربان دوستانی ، چه با صفا ، همه پر شور و شر ، یک دل ، یک هدف ، دل از هر چه تعلق بود زدودیم تا هیچ چیز ما را از هدفمان منحرف نکند . با پایگاه بسیج شهدای سازمان خبرگزاری جمهوری اسلامی شکل گرفتیم ؛چه سخت بودند مشکلات و چه بزرگ روح بودند یاران که در مقابل شدائد چون کوه ایستادند و خشمناک بر مشکلات تاختند و تمام لحظه ها یاور یکدیگر بودند و هستند .
و اینک دور هم جمع شده ایم تا با تمام مشکلات و نا مردمی ها , پشتیبان ولایت باشیم
درباره وبلاگ
غروب نزدیک میشود
و تو گویی
تقدیر زمین از همین حاشیه‌ی اروندرود است که تعیین میگردد.
و مگر به‌راستی جز این است؟
دسته ها :
پنج شنبه دهم 11 1387