تعداد صفحات: ۱۰۱ | قابل ویرایش
فهرست مطالب
عنوان صفحه
فصل اول : سیستم های اطلاعاتی
- مفاهیم و تعاریف …………………………………………………………………………۲
- سیستم های اطلاعاتی – داده پردازی…………………………………………۶
- دادگان ، پایگاه داده………………………………………………………………….. ۱۶
- تاریخچه پایگاه داده………………………………………………………………….. ۱۷
- انواع دادگان ها………………………………………………………………………….. ۱۹
- مدل های پایگاه داده………………………………………………………………… ۱۹
- مبانی مدل سازی……………………………………………………………………….۲۱
فصل دوم : معرفی نرم افزارهای مورد استفاده
الف – معرفی نرم افزار Access……………………………………………………………………24
- آشنایی با اکسس………………………………………………………………………..۲۵
- انواع عملگرها……………………………………………………………………………..۳۱
- آشنایی با طراحی Query……………………………………………………………35
ب – معرفی ویژوال بیسیک (VB)
- شروع کار با Visual Basic (VB) ……………………………………………..42
فصل سوم : توضیحات پروژه
- دستورات سورس کد بهمراه فرم های پروژه…………………………… ۶۷
ضمیمه ۱ : نحوه ساخت و اتصال دیتا بیس در ویژوال بیسیک………..۸۴
ضمیمه ۲ : نحوه ساخت گزارشگیری (DataReporter)………………91
موجودیت (Entity)
به هر چیزی (شی ، شخص ، محل و …) که می خواهیم در یک سیستم راجع به آن اطلاعاتی را جمع آوری ، پردازش و نگهداری نمائیم ، یک موجودیت گفته می شود . تعریف فوق ، متداولترین برداشت اولیه از موجودیت می باشد.
مجموعه موجودیت های یک سیستم، ساختار اطلاعاتی آن سیستم را مشخص می کند . هر موجودیت شامل اجزاء و المان هائی است که آن موجودیت را توصیف می کند که به آنها خصیصه و یا Attribute گفته می شود . هر موجودیت بسته به این که در سیستم مورد مطالعه چه میزان اطلاعات راجع به آن می خواهیم داشته باشیم ، شامل حداقل یک و یا چند خصیصه خواهد بود.
از آنجا که هر موجودیت راجع به یک موضوع به خصوص می باشد ، بنابراین یک ارتباط منطقی بین کلیه خصایص موجودیت وجود خواهد داشت .در واقع ، تمام خصائص یک موجودیت توصیف کننده آن موجودیت خواهد بود . برای روشن شدن موضوع بد نیست به نمونه مثال ذیل توجه نمائید:
– موجودیت مشتری شامل خصلت های نام مشتری ، آدرس مشتری ، تلفن مشتری و … است.
– موجودیت سفارش شامل خصلت های شماره سفارش ، تاریخ سفارش ، نام مشتری ، کالای سفارش شده ، تعداد کالای سفارش شده و … است.
همانگونه که در مثال فوق مشاهده گردید ، تمام خصلت های موجودیت مشتری توصیف کننده یک مشتری و تمام خصلت های موجودیت سفارش توصیف کننده یک سفارش می باشند.
کلید (Key)
هر رخداد از یک موجودیت را باید بتوان به وسیله یک و یا ترکیبی از چند خصیصه آن به صورت یکتا شناسائی نمود . به تعبیر دیگر ، هر یک از رخدادهای یک موجودیت باید یکتا باشد ، در غیر اینصورت تغییر و یا حذف یک رخداد از موجودیت (در مثال فوق یک مشتری) غیر ممکن خواهد بود . از اینرو از بین خصلت های یک موجودیت یک و یا ترکیبی از چند خصیصه به عنوان کلید آن موجودیت انتخاب می شود.
این خصلت (و یا ترکیب خصلت ها) باید بتواند یکتائی هر رخداد از موجودیت را تضمین نماید . در موجودیت سفارش مثال فوق ، خصلت شماره سفارش می تواند بعنوان کلید انتخاب شود.
توضیح : در برخی از موارد در یک موجودیت چندین کلید وجود دارد که به هر یک از آنها یک Candidate Key یا Alternate Key گفته می شود.
در برخی از حالات نمی توان در یک موجودیت هیچ کاندیدی برای کلید یافت ، مانند موجودیت مشتری در مثال فوق . در این موجودیت هیچیک از خصلت ها و یا هیچ ترکیبی از آنها نمی تواند صد درصد تضمین کننده یکتائی آن باشد (با اینکه احتمال وجود دو مشتری هم نام در یک آدرس و با یک شماره تلفن بسیار کم است ، اما باز هم احتمال وقوع دارد).
ارتباط (Relationship)
منظور ارتباط بین دو Relation و یا جدول است که بر اساس برابری فیلدهای یکسان در هر جدول تعریف و دارای انواع مختلفی است . ( به دلیل اهمیت و گستردگی ، در مقاله ای جداگانه تشریح خواهد شد).
این ارتباط ها در مدل منطقی مابین موجودیت ها (خصوصا” موجودیت های نرمال شده ) تعیین می گردند و به آن Entity Relation یا ER سیستم می گویند. مدل ER سیستم توسط ابزارهای مستند سازی جهت درک بهتر مدل داده ای سیستم ترسیم می گردد که به آنها ERD می گویند.
پس از تشریح برخی از مفاهیم اولیه و در عین حال مهم بانک های اطلاعاتی رابطه ای ، به اختصار می توان گفت که یک بانک اطلاعات رابطه ای مجموعه ای از رابطه ها (Relations) و یا جداول به همراه تمامی ارتباط هائی (Relationship) است که بین آنها وجود دارد.
هر بانک اطلاعاتی در خصوص یک سیستم مورد نظر طراحی و ایجاد می گردد ، اما در برخی از سازمان های بزرگ که بین سیستم های مختلف آن ارتباط وجود دارد (نظیر سیستم پرسنلی ، حقوق و دستمزد و مالی و …) ممکن است بانک های اطلاعاتی با یکدیگر تجمیع و پس از طی فرآیند یکپارچه سازی به صورت یک بانک اطلاعاتی جامع و یکپارچه برای آن سازمان تعریف و ایجاد گردد.
دیتامارت
دیتا مارت اغلب کوچک است و بر یک موضوع یا دپارتمان خاص متمرکز است. بنابراین پاسخگوی یک نیاز داخلی است. طرح بانک اطلاعات برای یک دیتامارت حول ساختار اتصال ستاره ای ساخته شده است که بهینه برای نیازهای کاربران دپارتمان است.
دیتامارت معمولا با ابزارهای کامپیوتری که انعطاف پذیری تحلیل را تامین میکنند اما ممکن است برای سازماندهی حجم بالای داده ها مناسب نباشند؛ نیرومند میشود. رکوردهای ذخیره شده در دیتامارتها بخوبی نمایه شده اند.
یک دیتامارت در صورتیکه داده ها را از منابع داده ای بسیار سازماندهی شده مثل انبار داده ها بگیرد؛ دیتامارت وابسته نامیده میشود. مسلما دیتامارتهای وابسته از لحاظ ساختاری و معماری منطقی هستند.
منبع دیتامارتهای وابسته تکنولوژِی بانک اطلاعات دپارتمانی است. دیتامارتهای مستقل ثابت نیستندو از لحاظ معماری بسیار با هم متفاوتند. این مساله هنگام یکپارچه سازی دیتامارتهای مستقل، مشکل ایجاد میکند. بنابراین با یکپارچه سازی ساده دیتامارتها یک انبار داده ایجاد نخواهد شد.
