از امروز با یک سری آموزشی در خصوص چگونگی Query گرفتن از SQL Server در خدمت شما دوستان هستیم ، قبل از اینکه به سراغ شروع مفاهیم و دروس برویم بهتر است کمی در مورد محتویات این سری آموزشی و همچنین مفاهیم ابتدایی در خصوص SQL Server بپردازیم. در این آموزش SQL Server شما با مهمترین کوئری هایی که باید در SQL Server با آنها آشنا باشید ، آشنا خواهید شد.
تمامی عزیزانی که تا این مدت از منابع آموزشی که در انجمن تخصصی فناوری اطلاعات ایران توسط بنده و سایر تیم تولید محتوا ایجاد شده است استفاده کرده اند می دانند که اصل کار ما مبنی بر آموزش کیفی است و به همین علت در تمامی مراحل آموزش سعی می کنیم خودمان را به جای کاربری که از انجمن مدیریت پایگاه داده توسینسو بازدید می کند بگذاریم
و سعی کنیم تا حد امکان ابهامی در توضیح مسائل وجود نداشته باشد. اما انتظاراتی از شما دوستان نیز داریم ، امیدوار هستم که اگر از این منابع آموزشی که بصورت کاملا رایگان در اختیار شما قرار گرفته است استفاده کردید حداقل دعای خیرتان پشت سر ما باشد و همچنین قانون حق تالیف را رعایت کنید.
اگر قصد دارید بصورت حرفه ای وارد حوزه SQL و برنامه نویسی بانک اطلاعاتی شوید حتما پیشنهاد می کنیم بصورت جامع و کامل با مهندس احمدی از طریق زیر آموزش ببینید و به بهترین شکل تبدیل به یک کارشناس حرفه ای بانک اطلاعاتی شوید :
اما به سراغ دوره برویم ، اول سئوال کنیم که SQL Server چیست ؟ به چه دردی می خورد ؟ و آیا این سری آموزشی ارتباطی به من دارد یا برای من استفاده خصی ندارد ؟ در پاسخ به سئوال اول باید بگوییم که SQL Server یک سیستم مدیریت پایگاه داده است ، پایگاه داده یعنی محلی که شما اطلاعات خود را در آن ذخیره می کنید
و سیستم مدیریت پایگاه داده یعنی نرم افزاری که این داده ها را مدیریت می کند ، در تعاریف پیشرفته تر به SQL Server پایگاه داده رابطه ای یا Relational Database Management System یا RDBMS هم گفته می شود ، نمی خواهیم بحث را پیچیده کنیم فقط در همین حد بدانید که یک فایل متنی ساده نیز می توانید یک پایگاه داده یا Database باشد
اما بدون ساختار منظم و تعریف شده و در اصطلاح فنی یک فایل متنی پایگاه داده ای Flat یا تخت می باشد. در پایگاه داده های رابطه ای یا Relational Database ها شما ساختاری تعریف شده دارید ، ساختاری متشکل از ستون ها و سطر ها ، به مثال زیر توجه کنید ، یک پایگاه داده متنی ساده Flat است که در یک فایل متنی ذخیره می شود :
Lname, FName, Age, Salary|Mohammad, Nasiri, 35, $280|Hossein, Ahmadi, 38, $325|Hamidreza, Sadeghian, 41, $265
مدیریت فایلی با ساحتار بالا در حجم های بالا بسیار مشکل است و طبیعتا جستجو در آن می تواند فاجعه ای در پی داشته باشد ، اما در همینجا نگاهی به ساختار زیر بیندازید ، ساختار زیر یک پایگاه داده Relational یا رابطه ای را نمایش می دهد که همان اطلاعات فایل متنی قبلی را به شکلی ساختار یافته به شما نمایش داده است :
همانطور که در جدول بالا مشاهده می کنید این نمونه ای از یک پایگاه داده رابطه ای یا Relational Database می باشد که بر اساس ستون ها و سطر ها تعریف می شود ، البته اطلاعات موجود در این پایگاه داده طبیعتا واقعی نیستند ، نه محمد نصیری 35 سال دارم و نه حسین احمدی 38 ساله است و نه حقوق حمید رضا صادقیان 265 با هر معیاری است ( اگر این بود ما زیر زیر خط فقط بودیم به خداااا ).
انواع و اقسام RDBMS ها وجود دارد که از آن جمله به غیر از MSSQL Server که بحث دوره ما خواهد بود ما MySQL و Oracle را داریم که از جمله مهمترین RDBMS های معروف دنیا هستند. اما در پاسخ به اینکه این پایگاه داده ها به چه دردی می خورند باید بگوییم
که متمرکز کردن اطلاعات در یکجا و مدیریت یکپارچه و توانایی پرسش و پاسخ از این پایگاه داده ها مهمترین دلیلی است که از پایگاه داده استفاده می کنیم. قبل از اینکه ادامه دوره با جلو ببرید در همینجا مخاطبین دوره را به شما معرفی می کنیم تا در صورتیکه شما جزو این دسته ها نباشید وقت خود را برای خواندن ادامه بخش هدر ندهید. مخاطبین این دوره به سه دسته تقسیم می شوند :
خوب تا اینجا مخاطبین این سری آموزشی را به شما معرفی کردیم اما در ادامه باید بگوییم که قرار است در این سری آموزشی چه مسائلی مورد بحث و آموزش قرار بگیرد ، بصورت کلی ما مباحث آموزشی این سری آموزشی را به سه دسته تقسیم بندی کرده ایم
که کار کردن با داده های داخلی موجود در SQL Server یا SQL Data ، کار کردن با داده های خارجی یا External Data و در نهایت ایجاد و اعمال تغییرات در Object های SQL یا Create and Alter SQL Objects این دسته بندی را تشکیل می دهند.در این خصوص یک سری توضیحات اولیه در ادامه عنوان کرده ایم :
قبل از اینکه بخواهم این سری آموزشی را در انجمن مدیریت پایگاه داده وب سایت انجمن تخصصی فناوری اطلاعات ایران قرار بدهم چند نمونه آموزشی از سایر وب سایت های فارسی زبان را نگاه کردم ، نمی توانم بگوییم همگی اما اکثر دوستانی که شروع به آموزش SQL Server می کنند از همان اول شروع می کنند به روش های query گرفتن و مقدمه چندانی راجع به استاندارد کاری خود ارائه نمی دهند
به امید خدا قصد داریم استانداردترین سری آموزشی SQL Server را در این وب سایت شروع کنیم ، ما در این سری آموزشی طبیعی است که همیشه از دستوراتی مثل SELECT DELETE UPDATE INSERT و غیره استفاده می کنیم ، به ساختار زیر نگاه کنید تا هر موقع در هر کدام از آموزش های دچار ابهامی در Syntax یا نحوه نمایش دستورات داشتید این ابهام برطرف شود ، نمونه Syntax یا نحوه نگارش دستورات SQL زیر را ببینید :
SELECT
-Command name or option
<table>
-Required Value
[ ENCRYPTION | SCHEMABINDING ]
-Optional
{ INSERT | UPDATE | DELETE }
–Required
به مثال بالا دقت کنید ، هر جا دستور SELECT را مشاهده کردید در خط بعدی حتما یک دستور یا Command ، یک کلید واژه یا keyword و در نهایت یک امکان یا Option باید قرار بگیرد . در خط بعدی هر چیزی که در میان <> قرار گرفته باشد که در این مثال table است در واقع محتوایی است که ما می خواهیم به آن دسترسی پیدا کنیم در اصطلاح به <> ها یک Placeholder هم می گویند.
قطعا مشخص کردن محلی که قرار است تغییرات در اطلاعات ایجاد شود ضروری است بنابراین در خط بعدی اشاره کرده ایم که وارد کردن این قسمت الزامی یا Required است و ساختار شما بدون این قسمت ناقص خواهد بود.در خط بعدی مشاهده می کنید که دو گزینه ENCRYPTION و SCHEMABINDING در بین دو علامت [] قرار گرفته اند ، این علامت یعنی محتویات موجود در این قسمت اختیاری است همانطور که در خط بعدی به عنوان Optional عنوان کردیم .
اما در خط بعدی دستورات INSERT UPDATE DELETE در داخل علامت {} قرار گرفته اند به معنی اینکه وجود این دستورات الزامی است ، دقت کنید که علامت پایپ یا | به معنی اختیاری بودن انتخاب بین دو دستور است . ( این پایپ را با آن پایپ اشتباه نگیرید D: ) به هر حال این قالب استانداردی است که ما تا پایان سری آموزشی خود از آن استفاده خواهیم کرد.
در بخش قبلی ما با هم متوجه شدیم که SQL Server چیست و مفهوم کلی Relational Database Management System یا سیستم مدیریت پایگاه داده های رابطه ای را متوجه شدیم . در این بخش می خواهیم بصورت ویژه در خصوص پایگاه داده های رابطه ای یا Relational Database ها صحبت کنیم و علی الخصوص در مورد SQL Server که هدف اصلی سری آموزشی ما می باشد صحبت خواهیم کرد.
برای افرادی که به تازگی وارد حوزه مدیری پایگاه های داده شده اند این امر طبیعی است که بسیاری از واژه ها و اصطلاحات گنگ و نامفهوم به نظر می رسد ، ساختار پایگاه داده های Relational تا حدودی در اوایل شروع به کال پیچیده به نظر می رسد ، تعداد اشیاء یا Object ها بسیار زیاد است و درک همه این مفاهیم در بدو ورود به این حوزه فناوری اطلاعات کمی دشوار است .
همین پیچیدگی هاست که باعث می شود افراد کمی بخواهند حوزه مدیریت پایگاه های داده را برای حوزه کاری خود در نظر بگیرند. در این بخش قصد داریم تمامی اصطلاحات و واژه های اولیه مرتبط با این حوزه را برای شما تشریح کنیم تا به امید خدا در آینده در درک این مفاهیم مشکلی نداشته باشید.
ما در این بخش و قسمت ها بعدی سئوالاتی را می پرسیم و به آنها پاسخ می دهیم ، سئوالاتی از قبیل اینکه Database چیست ؟ Database به چه دردی می خورد ؟ منظور از Table و Column و Stored Procedures چیست ؟ در ادامه در خصوص موارد ساده ای در خصوص طراحی Database ها نیز اشاراتی خواهیم داشت.
یک Database مجموعه ای از اشیاء یا Object ها است ، طبیعی است که Database ها برای ذخیره سازی داده ها بکار می روند اما این ذخیره سازی در قالب جدول ها یا Table ها انجام می شود. جدول یا Table در واقع هسته اصلی پایگاه داده ای است که در SQL Server وجود دارد .
جدول یک شیء است اما اشیاء دیگری نیز در SQL Server داریم ، اشیائی مثل Trigger ها ، Stored Procedure ها که همگی آنها به ما کمک می کنند که دسترسی به داده های موجود در Database ها ساده تر باشد ، این اشیاء می توانند امکانات بسیار خوبی در خصوص ویرایش و اضافه کردن اطلاعات در Database ها را به ما ارائه دهند. در خصوص هر یک از این اشیاء یا Object ها در ادامه توضیحاتی را ارائه خواهیم دارد. انواع Object های موجود در Database های SQL Server بصورت کلی به شکل زیر می باشند :
جدول های یا Table ها همانطور که اشاره کردیم هسته اصلی پایگاه های داده هستند ، طبیعی است که این اهمیت به دلیل این است که داده های ما به همراه هر چیزی که با پایگاه های داده کار می کند درون این جدول ها ذخیره می شوند.
اگر فرض کنید که پایگاه داده ای برای ذخیره سازی اطلاعات یک فروشگاه داشته باشید تمامی مواردی از قبیل پیدا کردن مشتریان ، پیدا کردن سفارش ها ، پیدا کردن رابطه های بین پایگاه های داده و تمامی مواردی که فکر کنید همه و همه نیازمند کار کردن با جداول یا Table ها می باشد. اگر کمی حوصله کنید
و با این سری آموزشی جلو بروید خواهید دید که ما بیشتر زمان خود را صرف کار کردن با داده هایی می کنیم که درون Table ها ذخیره شده اند و به مرور متوجه خواهید شد که چرا Table ها هسته اصلی پایگاه داده هستند. به جدول فرضی زیر دقت کنید ، سعی می کنیم تمامی مثال های خود را برای درک مفاهیم موجود در RDBMS ها با همین جدول فرضی انجام دهیم :
خوب بعد از اینکه مفهوم جدول را متوجه شدیم ، که در آینده در خصوص زیر مجموعه های جدول یا Table بیشتر صحبت خواهیم کرد ، باید بدانید که ما علاوه بر Table ها اشیاء دیگری هم داریم که با داده های موجود در Database ها کار می کنند
برای مثال یکی از این Object ها به نام View می باشد. View ها در واقع Table های مجازی می باشند و هدف اصلی آنها ساده سازی ساختار پایگاه داده است. View می تواند مجموعه ای از داده های موجود در Table های مختلف باشد ، ممکن است شما به یک View نگاه کنید که اطلاعات آن از چندین table مختلف در Table های مختلف به شما بصورت یکجا نمایش داده شده است.
همانطور که گفتیم هدف View ها ساده سازی چهره داده ها است و طبیعتا نمایش دادن یک View از نمایش چندین Table بصورت تک به تک ساده تر است.در زیر نمونه ای از SYNTAX نوشتن یک VIEW را مشاهده می کنید :
CREATE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition
این نوع Object ها در SQL Server و البته در بسیاری دیگر از RDBMS ها قسمت هسته برنامه نویسی Database ها هستند. شما با نوشتن یک Stored Procedure می توانید بر روی اطلاعات موجود روی Database تغییرات اعمال کنید و حتی از آنها خروجی بگیرید ، Stored Procedure ها بر خلاف View ها که فقط خواندنی هستند قابل نوشتن و اعمال تغییرات نیز هستند.
در تعریف ساده تر یک Stored Procedure مجموعه ای از دستورات SQL است که یک وظیفه یا Task خاص و مد نظر نویسنده آن را انجام می دهد. به Stored Procedure ها در اصطلاح فنی proc, sproc, StoPro, StoredProc, sp هم گفته می شود. در آینده در خصوص شیوه نگارش این نوع Object ها بصورت مفصی صحبت خواهیم کرد. در زیر SYNTAX نگارش یک Stored Procedure را مشاهده می کنید :
--Transact-SQL Stored Procedure Syntax
CREATE { PROC | PROCEDURE } [schema_name.] procedure_name [ ; number ]
[ { @parameter [ type_schema_name. ] data_type }
[ VARYING ] [ = default ] [ OUT | OUTPUT | [READONLY]
] [ ,...n ]
[ WITH <procedure_option> [ ,...n ] ]
[ FOR REPLICATION ]
AS { [ BEGIN ] sql_statement [;] [ ...n ] [ END ] }
[;]
<procedure_option> ::=
[ ENCRYPTION ]
[ RECOMPILE ]
[ EXECUTE AS Clause ]
Function ها یا توابع مجموعه ای از دستورات هستند که اجرا می شوند و به شما خروجی می دهند ، مهمترین تفاوتی که با سایر Object ها دارند این است که Function ها فقط می توانند اطلاعات را خروجی بدهند و عملیات های بروز رسانی و یا وارد کردن اطلاعات در Database ها را نمی توانند انجام دهند.
خروجی Function ها می تواند در قالب های مختلفی باشد. در خصوص Function ها و کاربرد آنها در آینده بیشتر صحبت خواهیم کرد.استفاده از Function ها چندان سخت نیست در ادامه چند Function را مشاهده می کنید :
AVG() - بازگردانی مقدار میانگین COUNT() - بازگردانی تعداد رکوردها FIRST() - بازگردانی اولین مقدار LAST() - بازگردانی آخرین مقدار MAX() - بازگردانی بیشترین مقدار MIN() - بازگردانی کمترین مقدار SUM() - بازگردانی جمع مقدار
تمامی Object هایی که تا این لحظه به شما معرفی کردیم بصورت ماژولار و با امکان استفاده مجدد یا Reusable ایجاد می شوند و شما می توانید بعد ها بدون نیاز به اینکه کد اضافه ای تولید کنید مجددا از SP ها یا Function هایی که نوشته اید استفاده کنید.
در این قسمت تنها به صورت کلی مفاهیم و ساختار اصلی اشیاء Database ها را معرفی کردم در بخش بعدی به امید خدا در خصوص مفاهیم Table ها در database بصورت ویژه صحبت خواهیم کرد ، مفاهیمی مثل رکورد ها ، ستون ها و ردیف ها و موارد مشابه ، امیدوارم مورد توجه شما قرار گرفته باشد.
در قسمت های قبلی با مفاهیم اولیه Relational Database ها و Object های آنها مثل Stored Procedure ها ، Function ها و VIEW ها تا حدودی آشنایی اولیه پیدا کردیم ، قطعا در آینده در خصوص هر یک از این مفاهیم بصورت کامل صحبت خواهیم کرد.
اما یکی از مواردی که بیشتر در خصوص آن توضیح دادیم بحث جدول یا Table بود که در اصل هسته اصلی پایگاه داده ما محسوب می شود. در این قسمت قصد داریم کلیه مفاهیم مرتبط با جداول در SQL Server را با هم بررسی کنیم . مفاهیمی مثل Column و Row و Filed و ... را به امید خدا با هم یاد می گیریم.
سعی می کنیم تمامی مثال های خود را با استفاده از جدولی که در قسمت دوم به شما معرفی کردیم جلو ببریم ، جدولی که من و آقای احمدی و مهندس صادقیان و مهندس خلیفی جزو مشتریان ثابت آن هستند. شکل زیر همان جدول را نمایش می دهد :
یکی از هسته های اصلی Table ها در SQL Server و البته بسیاری دیگر از RDBMS ها ستون یا Column می باشد.ستون ها در واقع محتویات موجود در پایگاه داده ما را مشخص می کنند و توضیحاتی در مورد آنها ارائه می کنند. آنها به ما می گویند که شما چه نوع اطلاعاتی را می توانید در این Database ذخیره کنید و چه اطلاعاتی را نمی توانید ذخیره کنید .
برای اینکه درک بهتری از موضوع داشته باشید به Table بالا نگاهی بیندازید در اینجا ما چندین Column یا ستون داریم که به ترتیب به نام های Customer ID یا شناسه مشتری ، Last Name یا نام خانوادگی ، First Name یا نام ، Join Date یا تاریخ اولین خرید و State که محل زندگی مشتری ، می باشند.
در واقع با نگاه کردن به ستون یا Column ای به نام Last Name شما متوجه خواهید شد که اطلاعاتی که قرار است در این ستون ذخیره شود مربوط به نام خانوادگی مشتریان است و یا اگر ستونی به نام State یا محل زندگی دارید حتما در آن محل زندگی مشتری ذخیره می شود نه چیز دیگر ، این یعنی ستون یاColumn در خصوص محتویات database به شما توضیح می دهد. علاوه بر اینکه Column ها در خصوص نوع محتوای ذخیره شده در Table ها توضیح می دهند آنها را اجبار به استفاده از نوع خاصی از داده نیز می کنند .
برای مثال اگر Column ای که به نام Join Date است را مشاهده کنید قطعا اطلاعاتی که قرار است در این Column ذخیره شود باید از نوع داده Date یا Date//Time باشد و نمی توانیم نوع داده ای مثل رشته یا String را برای این ستون در نظر بگیریم.
برای مثال ما می توانیم برای Column های خود در همین جدول نوع داده یا Data Type تعریف کنیم ، ساده ترین مثال در این خصوص این این است که Customer ID از نوع داده Integer و Last Name از نوع داده String یا رشته ، First Name از نوع داده رشته یا String و Join Date از نوع داده Date یا Date //Time و State نیز از نوع داده String باشد.
در خصوص انواع داده ها یا Data Type ها در SQL Server در آینده صحبت خواهیم کرد اما اگر می خواهید در همین لحظه اطلاعات بیشتری در این خصوص داشته باشید می توانید به بخش مهندس رمضانی با عنوان انواع داده در SQL Server مراجعه کنید.
بنابراین بصورت خلاصه اگر بخواهیم column را تعریف کنیم : آنها درباره داده ها به ما اطلاعاتی ارائه می دهند ، نوع آنها را تعیین می کنند و در واقع به داده های ما هویت و معنا می دهند.
Row یا ردیف یا سطر در واقع داده های شما در یک Database هستند.برخی اوقات به این داده ها یا بهتر بگوییم به این Row ها رکورد یا Record هم گفته می شود حتی برخی اوقات از Row به عنوان موجودیت یا Entry هم نام برده می شود ، به هرحال همه این واژه ها یک منظور دارند و منظور داده اصلی ما است.
جدول زیر را در نظر بگیرید ، زمانیکه شما در رابط کاربری یک نرم افزار فروش برای مثال می خواهید یک مشتری را اضافه کنید بایستی برای مشتری یک Customer ID یک Last Name یک First Name یک Join Date و یک State در Table مربوطه وارد کنید
حال اگر همه این موارد را انجام دهید تنها یک رکورد وارد Database شما خواهد شد یعنی مجموعه ای از مقادیر که بصورت ردیفی کنار هم قرار گرفته اند و همه اینها در واقع نمایانگر یک مشتری هستند. در جدول زیر همانطور که مشخص شده است شما یک رکورد به صورت Customer ID برابر با 110 ، Last Name برابر Nasiri وFirst Name برابر Mohammad و Join Date برابر 1//1//1391 و در نهایت State ای برابر کرج دارید که همگی یک Row یا یک رکورد را با هم تشکیل می دهند.
سایر موارد دیگر هم به همین شکل تشکیل رکورد های مختلف پایگاه داده شما را خواهند داد . ساده ترین مثال برای درک مفهوم رکورد در Database همان موجودیت هایی است که در دفترچه تلفن مشاهده می کنید ، نام و نام خانوادگی به همراه شماره تلفن تشکیل یک رکورد از فرد مورد نظر را می دهند.
با اینکه خیلی جستجو کردم اما ترجیح دادم واژه فارسی را معادل کلمه Field در انگلیسی در متن قرار ندهم و همان بهتر که فیلد بنویسیم و فیلد بخوانیم. آخرین نکته برجسته ای که در خصوص Table ها وجود دارد بحث Field است ، یک فیلد نقطه تقاطع بین یک Column و یک Row می باشد
هر کدام از Field های ما در یک Database دارای مقادیر منحصر به فردی هستند ، برای مثال جدول زیر را در نظر بگیرید ، در Column ای به نام Customer ID و اولین Row فیلد اول با مقدار 110 مشخص شده است ، فیلد دوم در column ای به نام Last Name و Row اول به با مقدار Nasiri مشخص شده است ، به همین ترتیب هر یک از مقادیر موجود در Table های ما در قالب Field ها نمایش داده می شوند. توجه کنید که مقادیر یا Value ها در SQL Server به عنوان Filed شناخته می شوند.
در بخش قبلی از همین سری قسمت ها در خصوص مفاهیم اصلی موجود در Table ها از قبیل Column و Row و Field صحبت کردیم .اما Object ها و مفاهیم موجود در طراحی Table ها در پایگاه داده کم نیستند و اینها تنها موارد اولیه ای بودند که با هم بررسی کردیم .
در این بخش قصد داریم به مفاهیم مهمتری بپردازیم ، اشیاء و مفاهیمی از قبیل Constraint ها ، Trigger ها ، کلید های اصلی ای Primary Key ها و کلید های خارجی یا Foreign Key ها ، اگر فرصت شد در همین بخش به بررسی مفاهیم ارتباطات بین Table ها یا Table Relationship هم خواهیم پرداخت اگر هم که نرسیدیم به امید خدا در بخش بعدی حتما به این موارد خواهیم پرداخت.
یکی از مواردی که خیلی برای ما در طراحی پایگاه های داده مهم است این است که مطمئن شویم که اطلاعاتی که وارد Table های ما می شوند معتبر باشند ، اینجا دقیقا محلی است که مفهوم Constraint یا محدودیت به کار ما می آید. یک مثال را با توجه به جدولی که قسمت ها قبلی هم با آن کار کردیم صحبت می کنیم
گفتیم که ما با استفاده از تعیین Data Type یا نوع داده می توانیم تعیین کنیم که در این Column فقط مقادیری برای مثال از نوع Date یا Date//Time وارد شود و مقادیر دیگر نتواند وارد شود ، تا اینجای کار مشکلی نیست و همین تعیین Data Type کار ما را راه می اندازد
اما زمانیکه صحبت از این می شود که ما می خواهیم در فلان Column یا فلان Row داده ای از همین نوع داده نتواند از تاریخ تعیین شده ای عقبتر درج شود بحث Constraint ها پیش می آید ، در واقع Constraint ها قوانین درج داده در Database ها هستند .
برای مثال فرض کنید برای تاریخ استخدام یا تاریخ شروع به کار یا حتی تاریخ سابقه بیمه نباید افراد مجاز تاریخ را از زمان تعیین شده عقب تر وارد کنند و این محدودیت بایستی وجود داشته باشد. یا شما Row ای دارید که حتما باید تاریخ امروز در آن وارد شود و تاریخ دیگری قابل درج در آن نباشد. با استفاده از Constraint ها شما می توانید چنین محدودیت هایی را برای row ها یا Column های خاص خود در نظر بگیرید.
با اینکه Constraint ها خیلی خوب هستند اما قابلیت ها و عملیات های آنها محدود شده است ، در حقیقت ما کار زیادی نمی توانیم با Constraint ها انجام دهیم . خوب تصور کنید یک کار تقریبا پیچیده تر را می خواهیم انجام دهیم ، فرض کنید که می خواهیم اگر کاربر یک عملیات خاص را انجام داد و یا اینکه اگر یکی از فیلد های Table تغییر کرد .
یک Filed دیگر از یک Table دیگر مقادیرش تغییر کند ، اینجا دقیقا محلی است که از Trigger ها استفاده می کنیم. Trigger ها یک کد اجرای خاص را با توجه به تغییراتی که بر روی داده ها انجام می شود اجرا می کنند ، برای مثال فرض کنید که کاربری داده ای را در اطلاعات فروش ثبت می کند و ما می خواهیم در یک Table دیگر اطلاعات مربوط به بازرسی این کالا را داشته باشیم
و به همین دلیل با استفاده از یک Trigger کاری می کنیم به محض اینکه کاربر ثبت فروش را انجام داد ، اطلاعاتی مربوط به آن کالا در جدول بازرسی نیز ثبت شود ، این دقیقا کاری است که Trigger برای ما انجام می دهد. البته تعاریف دیگری نیز از Trigger وجود دارد که امیدوارم با توجه به اینکه تعاریف درستی از این مورد در وب سایت های فارسی وجود ندارد حق کپی رایت انجمن تخصصی فناوری اطلاعات ایران و بنده حقیر را حداقل رعایت کنید
و بعد مطلب را کپی کنید. در تعریفی دیگر از Trigger می توانیم بگوییم که Trigger ها یک نوع خاص از Stored Procedure ها هستند که کدهای تعیین شده ای را با توجه به یک Action یا عملیات خاص بر روی یک table تعیین شده انجام می دهند ، عملیاتی مانند INSERT یا DELETE یا UPDATE یا هر چیز دیگری در داده های ما ، Trigger ها جزو Object های یک Database محسوب می شوند و یه یک Table متصل می شوند و بصورت خودکار مانند یک اسکریپت اجرا می شوند.
تقریبا همه Table هایی که شما در یک Database ایجاد می کنید دارای یک مفهوم هستند به نام کلید اصلی یا Primary Key ، کلیدهای اصلی ای Primary Key ها در واقع شناسه های منحصر به فردی هستند که هر Row یا رکورد موجود در Table شما را مشخص می کنند.
ساده ترین مثال یعنی اینکه Primary Key در یک Table برای هر رکورد منحصر به فرد است ، اگر Database نیروی انسانی یک سازمان را در نظر بگیرید شناسه ملی یا Social Security Number افراد می تواند به عنوان Primary Key در جدول محسوب شود زیرا تنها یک فرد می تواند این شماره را به خود اختصاص دهد ( البته من در ایران این موضوع رو تایید نمی کنم ولی ما میگم هست شما هم بگین هست خوبیت نداره ) .
برای اینکه درک بهتری از موضوع Primary Key داشته باشید جدول همیشگی زیر را در نظر بگیرید ، در جدول زیر بهترین گزینه برای انتخاب به عنوان Primary Key کدام گزینه می تواند باشد ؟ ممکن است چندین نفر مشتری به نام Mohammad و نام خانوادگی Nasiri وجود داشته باشند .
بنابراین این گزینه نمی تواند به عنوان Primary Key باشد ، تاریخ عضویت یا Join Date هم نمی تواند شناسه منحصر به فردی باشد زیرا ممکن است در یک روز ده ها مشتری جدید به سیستم اضافه شود ، طبیعی است که State هم نمی تواند به عنوان Primary Key باشد زیرا فقط کرج میلیون ها نفر جمعیت دارد ، بهترین گزینه در جدول زیر برای انتخاب به عنوان Primary Key گزینه Customer ID می باشد که بصورت منحصر به فرد می تواند یک رکورد را برای ما مشخص کند.در تصویر زیر با رنگ قرمز Primary Key جدول مشخص شده است.
یکی دیگر از مفاهیمی که در برگیرنده بحث کلید است به نام Foreign Key یا کلید خارجی معروف است. در خصوص هر یک از این مفاهیمی که توضیح دادیم در آینده بصورت مفصل صحبت خواهیم کرد بنابراین اصلا نگران نباشید. اما به سراغ بحث اصلی برویم .
کلید خارجی یا foreign Key برای ارتباط برقرار کردن یا ایجاد Relationship بین Table ها مورد استفاده قرار می گیرد ، این مبحث جزو مهمترین مباحث در طراحی Database ها می باشد. یکی از مهمترین مسائلی که در طراحی پایگاه های داده بایستی در نظر گرفته بشود بحث جلوگیری از به وجود آمدن تکرار داده ها است.
برای مثال اگر شما Database ای دارید که در آن اطلاعات مشتریان قرار دارد و از طرفی Database دیگری دارید که در آن سفارش های مشتریان وجود دارد نباید داده های تکراری در خصوص مشتریان در این Database ها وجود داشته باشد اما در این میان قاعدتا مشتریان باید به اطلاعات سفارش ها و سفارش ها به مشتریان مورد نظر مرتبط باشند.
اینجا دقیقا زمانی است که کلید خارجی یا Foreign Key به کمک ما می آید. در واقع Foreign Key یک Table یا بهتر بگوییم یک Column است که به Primary Key یک Table دیگر اشاره می کند و به این ترتیب ارتباط بین دو Table برقرار می شود.
بنابراین در مثال ما ، ابتدا یک Column در جدول سفارش ها ایجاد می کنیم و آن را به عنوان کلید خارجی یا Foreign Key قرار می دهیم و این جدول را به Primary Key موجود در Table ای که Customer ها یا مشتریان در آن قرار دارند مرتبط می کنیم.
nر بخش قبلی در خصوص مفاهیمی مثل Trigger ، Constraint ، Primary Key و foreign Key صحبت کردیم. تمامی این مفاهیم در نهایت بر می گردد به موضوعی به نام رابطه بین Table ها یا Table Relationships ، یکی از مواردی که در انتهای بخش قبلی به آن اشاره کردیم بحث کلید خارجی یا Foreign Key بود که می توانست بین چندین Table مختلف ارتباط برقرار کند.
سئوال اصلی در اینجا پیش می آید که اصلا چرا ما باید بین چند Table ارتباط یا Relation برقرار کنیم و چه ضرورتی برای انجام اینکار می باشد؟ خوب دلایل استفاده از چنین قابلیتی زیاد هستند اما در این سری قسمت ها به مهمترین دلایل اشاره ای خواهیم داشت.
اولین دلیل بسیار مهم این است که با اینکار سرعت و کارایی فرآیند بروز رسانی رکوردها و فیلد ها که در اصطلاح Performance و Update می گوییم افزایش پیدا می کند. برای مثال اگر فرض کنیم که در یک Table اسامی مشتریان ما ذخیره شده اند
و ما می خواهیم اسم این مشتری را عوض کنیم ، اگر این اطلاعات فقط در یک Table ذخیره شده باشند کافیست یکبار تغییر کنند اما اگر در Table های مختلفی وجود داشته باشند بایستی تک تک بروز رسانی شوند و تغییرات در آنها اعمال شود ، اینکار باعث پایین آمدن کارایی و به ویژه کند کردن فرآیند کاری ما در پایگاه داده می شود.
علاوه بر این مورد تقسیم کردن داده ها به Table های مختلف انعطاف پذیری بیشتری به شما برای گرفتن Query ها و گزارش ها می دهد. برای مثال اگر قرار باشد شما برای تهیه یک گزارش Table ای که دارای محتوای انبار یا Storage است را در کنار Table دیگری که اطلاعات مشتریان یا Customer را در خود دارد قرار دهید
تا بتوانید برای مثال مشتریانی که از فروشگاه های خاص شما خرید می کنند را پیدا کنید و نزدیکترین فروشگاه را برای مثال به آنها معرفی کنید ، یا میزان خرید هفتگی و ماهیانه آنها را محاسبه کنید ، با تفکیک کردن Table ها این امر ساده تر می شود .
در چنین مواقعی شما اگر نقطه اشتراکی بین Table های خود می خواهید ایجاد کنید می توانید با استفاده از امکاناتی که در SQL Server به نام Join کردن Table ها وجود دارد این عملیات را انجام دهید ، در آینده در خصوص Join کردن Database ها بیشتر صحبت خواهیم کرد.
فرآیند Join کردن را زمانی انجام می دهیم که الزامی برای ایجاد کردن Relationship بین دو Table وجود ندارد اما داده هایی در Table های مختلف وجود دارد که می تواند برای گزارش گیری یا فرآیند های اینچنینی مفید باشند ، برای مثال شما می خواهید بدانید که مشتریان شما هر چند وقت یکبار از فروشگاه های شما خرید می کنند ، چه چیزهایی را معمولا خرید می کنند ؟
از کدام فروشگاه شما خرید می کنند ؟ و امثال اینگونه گزارش ها که نیازمند برقراری ارتباط بین Table های Customers و Orders و Storage می باشد در چنین مواقعی شما می توانید از Join کردن Table ها استفاده کنید. مزیت Join کردن در این است که شما الزامی برای طراحی اولیه درست برای Database خود ندارد و می توانید Join ها را بعدها انجام دهید.
آخرین دلیلی که در این قسمت می توانیم برای تقسیم بندی داده ها به Table های مختلف عنوان کنیم بحث صحت داده ها یا Data Integrity می باشد. اینکار شامل این مورد می شود که مطمئن شویم که اگر بر فرض مثال ما نام یک مشتری را در Table خود Update یا بروز رسانی می کنیم .
فقط نیاز باشد اینکار یکبار انجام شود و نیازی نباشد که شما این عملیات را برای چندین Table دیگر نیز انجام دهید. از طرفی دیگر می توانیم این مثال را برای مواردی بزنیم که شما می خواهید یک مقدار را در یکی از Table های خود تغییر دهید
اما می خواهید مقدار اولیه همیشه ثابت باقی بماند و شما می خواهید همیشه بدانید که داده اصلی شما چه بوده است. برای مثال اگر شما یک فروشگاه چند شعبه ای در سراسر کشور را در نظر بگیرید ، برای مثال فروشگاه انجمن تخصصی فناوری اطلاعات ایران که به امید خدا به زودی با آدرس shop.tosinso.com در دسترس خواهد بود .
شما برای پایگاه داده آن یک Table به نام سفارش ها یا Orders ایجاد می کنید ، در حقیقت برای من مهم این نیست که مشتری من اکنون در چه مکانی یا شهری قرار دارد بلکه برای من محلی مهم است که مشتری سفارش خود را ثبت کرده است ، ممکن است مشتری ما در کرج سفارش ثبت کرده باشد اما الان ساکن تبریز باشد.
خوب در همینجا یک مثال می زنیم ، ما می خواهیم به فروشندگانی که تا کنون موفق شده اند بیشترین محصول را به این مشتری بفروشند جایزه بدهیم و یا اینکه به اشخاصی که از فروشگاه ما بارها و بارها خرید کرده اند تخفیف های ویژه بدهیم .
اگر اطلاعات اصلی خرید این مشتری در شهر قبلی در اختیار نباشد و مشتری ما در شهر جدید خرید انجام دهد به عنوان یک مشتری جدید محسوب می شود و تمامی تخفیف هایی که باید شامل وی می شد را از دست داده است. با جدا کردن Table ها از همدیگر شما می توانید مطمئن باشید داده های اصلی شما دست نخورده باقی می مانند و مشتری جدید برای اینکه بررسی شود که قبلا مشتری شما بوده است یا خیر کاملا از Table دیگر قابل استعلام می باشد چون داده های اصلی Integrity خود را حفظ کرده اند.
اما نقطه منفی در خصوص تقسیم کردن Database به Table های مختلف می تواند جمع آوری اطلاعات و قرار دادن چندین Table در کنار هم است که معمولا بصورت متناوبی اینکار انجام می شود و شما مجبور هستید برای بدست آوردن اطلاعات در قالب و ساختاری خاص Table های متعددی را در کنار هم قرار دهید .
در خصوص اینکه چگونه می توانیم چنین کاری انجام دهیم بعد ها در همین سری قسمت ها صحبت خواهیم کرد ، قرار دادن Table ها در کنار هم یکی از هسته های اصلی Relational Database ها می باشد ، به اینکار که قبلا هم تا حدودی اشاره کردیم در اصطلاح Join کردن Table ها می گویند که بعدها در خصوص آنها بیشتر صحبت خواهیم کرد.
امروزه تقریبا همه Queryها از مجموعه ای از جداول Database گرفته می شوند.در SQL Server بصورت کلی سه نوع رابطه اصلی بین Table ها می توان برقرار کرد که به ترتیب شامل موارد زیر می باشند :
ساده ترین حالت ممکن برای این رابطه این است که یک رکورد در یک جدول به یک رکورد دیگر در جدول دیگر اشاره می کند.زمانی معمولا از چنین سناریو هایی استفاده می کنید که داده های تقسیم بندی شده در Table های دیگر معمولا به ندرت استفاده می شوند و یا اطلاعات موجود در آنها چندان اهمیتی ندارد.
برای اینکه درک بهتری از این مسئله داشته باشید فرض کنید که ما در Database یک سازمان Table ای داریم که اطلاعات هویتی افراد ، تحصیلات و محل کار و موقعیت شغلی فعلی آنها در آن ذخیره می شود ، طبیعی است که هر روز و هر ساعت قرار نیست به این اطلاعات دسترسی داشته باشیم و این اطلاعات از حیث میزان دسترسی اولویت پایین تری دارند و کمتر مورد استفاده قرار می گیرند .
از طرفی دیگر اطلاعاتی ممکن است وجود داشته باشد که هر روز بخواهیم به آنها دسترسی پیدا کنیم ، برای مثال اطلاعات مربوط به حضور و غیاب پرسنل ، شما در چنین شرایطی در صورت نیاز از Table ای که دسترسی به آن بصورت همیشگی و دائم انجام می شود یک ارتباط یک به یک به table ای که دسترسی به آن به ندرت انجام می شود برقرار می کنید تا در صورت نیاز به دسترسی به اطلاعات هویتی مشکلی پیش نیاید. در کل شما از ارتباطات یک به یک زمانی استفاده می کنید که داده های Table ها به ندرت مورد استفاده قرار می گیرند.
این رابطه زمانی پیش می آید که یک رکورد در یک Table به چندین رکورد در Table های دیگر ارتباط پیدا می کند. معمولا رابطه های والد و فرزند یا Parent Child از این نوع رابطه تعریف می شوند ، برای مثال شما در یک فروشگاه ممکن است Table ای به نام دسته بندی ها یا Categories داشته باشید که دارای چندین محصول یا Product متنوع باشند.
در چنین مواقعی ممکن است یک دسته بندی دارای چندین نوع محصول باشد و رابطه در این حالت یک به چند خواهد شد. یا در مثالی دیگر ما می توانیم مشتری را داشته باشیم که چندین سفارش متنوع داشته باشد ، اینها مثال هایی از رابطه یک به چند در Database ها هستند ، این نوع رابطه مرسوم ترین و معمولترین رابطه ای است که امروزه بیشترین استفاده را در RDBMS ها دارد.
این رابطه زمانی پیش می آید که چندین رکورد به چندین رکورد دیگر مرتبط می شوند. ساده ترین مثالی که می توان با توجه به مثال های قبلی در حوزه فروشگاه نام برد این است که محصولات و سفارش ها می توانند با هم رابطه چند به چند داشته باشند .
یک محصول می تواند چندین بار سفارش داده شود و یک سفارش می تواند شامل چندین محصول باشد. نکته بسیار مهم در خصوص رابطه های چند به چند در Table های SQL Server این است که SQL Server بصورت مستقیم رابطه های چند به چند را پشتیبانی نمی کند
و در نتیجه برای اینکه بتوانیم چنین رابطه ای ایجاد کنیم دو رابطه ی یک به چند بایستی ایجاد کنیم ، در چنین شرایطی ما یک Table بصورت رابط یا میانی ایجاد می کنیم که رابطه های بین محصولات و سفارش ها را بصورت یک به چند ایجاد کند. برخی اوقات به این Table میانی که برای ایجاد رابطه چند به چند استفاده می شود Join Table نیز گفته می شود.
در بخش های قبلی در خصوص مفاهیمی از قبیل رابطه های بین Table ها ، Trigger ها ، Constraint ها ، رابطه های یک به یک ، یک به چند ، چند به چند و همچنین مفاهیمی مثل کلید اصلی یا Primary Key و کلید خارجی یا Foreign Key صحبت کردیم .
در ادامه می خواهیم این مفاهیم را تا حدودی در حوزه طراحی پایگاه های داده مورد استفاده قرار بدهیم تا درک آنها ملموس تر باشد ، عجله نکنید ، اول مفاهیم و طراحی ها را خوب یاد بگیرید و سپس به سراغ کاربرد بروید وگرنه فقط یک کاربر خواهید شد
نه یک طراح ، خاطرم هست که در همین حوزه شبکه هر فردی که می توانست چهار تا Next Next Finish را بزند خود را به عنوان مشاور مایکروسافت معرفی می کرد ، دوستان درک عمقی از مفاهیم داشته باشید نه فقط کار تجربی بدون اینکه بدانید در پس زمینه چه اتفاقی می افتد.
رسالت بنده و وب سایت انجمن تخصصی فناوری اطلاعات ایران هم به این شکل می باشد که ابتدا مفاهیم را خوب توضیح می دهیم و سپس به سراغ مسائل کاربردی و عملی می رویم . خوب برای اینکه بتوانیم تمامی این مفاهیم را در کنار هم قرار دهیم بیایید با هم یک Table یا بهتر بگوییم یک Database طراحی کنیم .
به مرور مفاهیم جدیدی را با هم خواهیم آموخت از جمله سئوالاتی مثل : منظور از طراحی Database چیست ؟ ما چگونه می خواهیم داده های خود را ساختار بندی کنیم ؟ چرا باید اصلا داده ها را ساختار بندی کنیم ؟ چرا باید به روش هایی که می گوییم این ساختار بندی انجام شود ؟
اگر این ساختار وجود نداشته باشد ممکن است چه مشکلاتی پیش بیاید ؟ و پس از پاسخگویی به این سئوالات به مرور از تمامی مفاهیمی که در گذشته در همین سری آموزشی یاد گرفته اید برای پاسخ داده به مشکلات و مسائل استفاده خواهیم کرد.
یک پایگاه داده یا Database به اندازه ای کاربردی و مفید است که طراحی آن مفید و کاربردی است.البته هیچوقت یک استاندارد یکپارچه و دقیق برای طراحی Database ها وجود ندارد و این درست نیست بگوییم که یک طراحی Database همیشه درست است و مشکلات ما را حل می کند .
طراحی ها همیشه متنوع هستند و هیچوقت یک طراحی جامع و کامل وجود ندارد که بتوان از آن در تمامی Database ها استفاده کرد. ممکن است برخی از طراحی ها نسبت به سایر طراحی ها از ساختار بهتری برخوردار باشند اما شما نمی توانید این را ملاک قرار دهید.
در طراحی Database ها دو عامل اصلی نقش دارند ، ابتدا دانش طراحی Database است و سپس خلاقیت و تجربه طراح است. هیچوقت شما در طراحی Database ها چیزی به نام الزام مشاهده نمی کنید (به جز مواردی که به ندرت پیش می آید و در خصوص Database ها یا Component های خاصی مورد استفاده قرار می گیرند )
و این شما هستید که با استفاده از دانشی که با استفاده از مطالعه و تجربه بدست آورده اید و از طرفی خلاقیتی که بر حسب تجربه و مرور زمان به دست آورده اید می توانید یک طراحی زیبا را ارائه کنید. ممکن است برخی اوقات تنها به یک راهکار برای طراحی خود برسید
اما همین راهکار نیز می تواند با روش های مختلف انجام شود و الزامی برای گام به گام انجام شدن یک طراحی قبلا پیاده سازی شده بصورت همیشگی نیست. برای یک طراحی خوب مقداری احساس ، مقداری هنر و مقداری دانش نیاز است که در موقعیت های مختلف بتواند طراحی های درستی را ارائه کند.
یکی از مواردی که در طراحی Database ها بسیار مهم است این است که شما بتواند در بدو طراحی Database به درستی اینکار را انجام دهید ، اگر طراحی اولیه درست انجام نشود ، بازگشتن و طراحی مجدد آن کار ساده ای نیست و مشکلات بسیاری را در بر خواهد داشت ،
قبل از طراحی یک database برای یک نرم افزار بهتر است با برنامه نویس و طراحی نرم افزار به درستی ارتباطات لازم برقرار شود و اطلاعات لازم دریافت شود و از طرفی نیز انجام اینکار نیاز بسیاری به انجام پیشبینی ها و آینده نگری می باشد ، آینده نگری و برنامه ریزی درست برای Database ها در واقع هسته اصلی طراحی یک Database می باشد.
باید به این موضوع دقت کنید که طراحی یک چیز ثابت و از پیش تعریف شده نیست و یک طراح Database موفق در طراحی های خود قطعا فاکتوری به نام تجربه را دارد که بسیار به وی کمک خواهد کرد ، پاسخ داده به سئوالاتی از قبیل : چرا باید اینکار انجام شود ؟
چرا باید از انجام اینکار پرهیز شود ؟ چرا باید در خصوص فلان مورد تحقیق شود ؟ چرا باید پیشبینی چنین مواردی انجام شود ؟و امثال اینگونه سئوالات صرفا زمانی امکانپذیر است که شما تجربه لازم در خصوص طراحی Database ها را داشته باشید.
عجله نکنید و نگران هم نباشید ، درست است مفاهیم اولیه را با هم مرور می کنیم اما در نهایت شما در دنیای طراحی Database تازه وارد هستید و این را فراموش نکنید که طراحی کار افراد حرفه است نه افراد تازه کار ، در نتیجه طراحی های Database های امروزی یا توسط خود برنامه نویس یا مدیر Database انجام می شود
و شما صرفا نقش کاربری و استفاده از آن را در بیشتر موارد دارید ، هدف ما اینکه اینقدر در حوزه طراحی Database صحبت می کنیم این نیست که شما در همین ابتدای کار دانش عمقی نسبت به این مورد پیدا کنید بلکه هدف من از آموزش این قسمت این است که اگر DBA یا برنامه نویس شما به شما یک Database داد .
متوجه شوید که چگونه رابطه ها در آن ایجاد شده اند و چرا این رابطه ها ایجاد شده اند ، در اصل بحث اصلی ما این است که شما به عنوان یک فرد تازه کار حداقل باید از ساختاری که در اختیار شما قرار می گیرد سر در بیاورید و بر اساس آن بتوانید تصمیم گیری های خود را انجام دهید. دوره ای ویژه طراحی Database بصورت جداگانه وجود دارد که صرفا مبحث طراحی Database را در خود پوشش می دهد.
خوب در خصوص مفهوم اولیه و همچنین اهمیت طراحی یک Database با هم صحبت کردیم اما یکی از کارهایی که DBA یا برنامه نویس شما یا خود شما به عنوان یک مدیر پایگاه داده در اولین گام از طراحی یک Database بایستی انجام دهید فرآیندی به نام Normalization یا عادی سازی می باشد.
ترجمه کلمه Normalization عادی سازی می باشد اما در لفظ ساده به فرآیند طراحی و تعریف Table های موجود در Database های شما به گونه ای که بتوانید درک درستی از داده های موجود در دیتابیس را به شما ارائه دهد Normalization گفته می شود.
فرآیند Normalization در واقع لایه بندی کردن و سطح بندی Table ها و تفکیک کردن درست آنها می باشد که معمولا در 5 سطح به گفته Plural sight و در 7 سطح به گفته کتاب Wrox انجام می شود ، یعنی شما برای اینکه داده های شما دارای ساختار استانداردی باشند با استفاده از فرآیند Normalization در 5 سطح می توانید Table های خود را طراحی کنید تا درک آنها ساده تر شود.
مهمترین نکته در خصوص Normalization این است که در این فرآیند هدف اصلی کاهس داده های تکراری در جداول یا به نوعی کاهش Data Redundancy می باشد . عجله نکنید در خصوص تمامی ابهاماتی که الان دارید در خصوص اینکه منظور از سطح چیست.
منظور از فرم های Normalization چیست و امثال اینها در بخش بعدی شروع به انجام یک طراحی عملی می کنیم که بصورت گام به گام فرآیند Normalization و طراحی اولیه یک Database را به شما در قالب سناریویی کاربردی آموزش می دهد پس عجله نکنید.
خوب در بخش قبلی با مفاهیم اولیه طراحی Database ها آشنا شدیم و متوجه شدیم که فرآید Normalization به چه منظور انجام می شود اما تا نتوانید این مفاهیم را بصورت ملموس و عملی کار کنید همیشه برای شما ابهام وجود دارد. بهترین راهکار از نظر بنده و بسیاری دیگر از دوستان برای یادگیری بهتر بحث Normalization طراحی کردن یک سناریوی فرضی و جلو بردن درس بر اساس این سناریو است.
سناریوی ها به این شکل است که انجمن تخصصی فناوری اطلاعات ایران دارای یک فروشگاه بین المللی است که در سراسر ایران و جهان دارای شعبه است و شما می خواهید برای Database این مجموعه ضمن طراحی عملیات Normalization را نیز انجام دهید.
به این دلیل از فروشگاه معمولا به عنوان سناریو استفاده می شود زیرا ملموسترین حالت برای شما عزیزان برای انجام فرآیند های خرید و فروش است و حداقل یکبار در روز شما این فرآیند را انجام می دهید. خوب در این سناریو ما می خواهیم سفارش های مشتریان ( Customer Orders ) را در Database ذخیره کنیم
یک مشتری قاعدتا می تواند در هر سیستم فروشی چندین سفارش ( Order ) داشته باشد ، یک سفارش ( Order ) می تواند شامل چندین کالا ( Product ) باشد و در نهایت یک کالا ( Product) می تواند چندین بار سفارش ( Order ) داده شود.
دقت کنید برای سناریو های واقعی هیچوقت از زبان فارسی استفاده نکنید ، قاعدتا چیزی هم به نام فینگلیش و پینگلیش هم نخواهیم داشت بنابراین حداقل عناوین اصلی را به زبان انگلیسی بنویسید تا طراحی زیباتری داشته باشید. خوب به جدول اولیه زیر یا Table اولیه ما دقت کنید :
خوب جدول بالا را مشاهده کردید ، طبیعی است که اگر شما کمی در خصوص پایگاه داده و طراحی Database ها کار کرده باشید متوجه می شوید که جدول بالا اصلا یک طراحی مناسب و متناسب با نیاز یک فروشگاه نیست و برعکس بسیار طراحی افتضاحی در این زمینه است.
اما فراموش نکنید که این یک روش تدریس است و به مرور و با گذشت مراحل همین جدول به مجموعه ای از جدوال تفکیک شده و طراحی شده تبدیل خواهد شد. اگر تا به حال طراحی هایی متناسب با نیاز یک فروشگاه ساده انجام داده اید
و تا حدودی می دانید که چه اتفاقی قرار است در نهایت بر سر جدول بالا بیاید باز هم با ما تا انتهای بخش باشید تا حداقل برخی از نکات جدید را یاد بگیرید. خوب از اینها بگذریم و به سراغ طراحی Database خود بپردازیم ، در مرحله اول همانطور که در جدول بالا مشاهده می کنید
ما تمامی موجودیت های خود را در قالب یک Table در کنار هم قرار می دهیم. خوب جدول پیشفرضی که در بالا مشاهده می کنید شاید در حال حاضر کوچک به نظر برسد اما براحتی می تواند تبدیل به یک جدول بسیار بسیار پر حجم و پر از داده های تکراری شود. ابتدا نگاهی به موجودیت هایی که در این جدول وجود دارند می اندازیم.
خوب همانطور که مشاهده می کنید در اولین Column ما تاریخ سفارش ( Order Date ) را قرار داده ایم تا اطلاعات مربوط به زمان و یا تاریخ سفارش در آن ذخیره شود ، در دومین Column شما نام مشتری ( Customer ) را مشاهده می کنید که اطلاعات هویتی اشخاصی می باشد که از شما خرید می کنند .
سومین Column مربوط به نوع کالا یا محصول اول ( Product ) سفارش داده شده است ، چهارمین Column تعداد سفارش های مربوط به کالا یا محصول اول را نمایش می دهد که ما به عنوان Quantity 1 آن را نمایش داده ایم ، به همین ترتیب پنجمین Column نوع محصول و کالای دوم و ششمین Column تعداد سفارش محصول دوم را به شما نمایش می دهد.
برای مثال در جدول بالا مشاهده می کنید که مهندس احمدی عزیز برای بچه خود در تاریخ 1//1//1392 20 عدد پوشک بچه My Baby در وهله اول و تعداد 4 عدد پوشک بچه Molfix در وهله دوم سفارش داده است ( بسوزه پدر بچه داری D: ) . خوب تا اینجای کار مشکلی نیست ، شاید بتوانید نرم افزارهایی را پیدا کنید که با همین ساختار و فقط با شناسایی موجودیت ها Database خود را آماده کار می کنند
اما ما می خواهیم اصولی پیش برویم. خوب اگر یک مشتری بخواهد 3 درخواست کالای متفاوت را در لحظه داشته باشد چه اتفاقی می افتد ؟ یا شاید چهار یا شاید پنج و یا تعداد بیشتری درخواست در لحظه ! سئوالی که در اینجا یک طراح Database از خود می پرسد این است که در نهایت چه تعداد Column باید ایجاد شود ؟
کی باید این فرآیند متوقف شود ؟ چه مقدار فضای ذخیره اطلاعات نیاز خواهد بود ؟ سرعت کار در نهایت به چه اندازه خواهد شد ؟ خوب در اینجاست که ما با پرسیدن این سئوالات به مشکلات اولیه پی خواهیم برد. اولین مشکل این است که در Table اولیه اطلاعات بسیار زیادی تکراری خواهند بود.
چه تعداد Column باید ایجاد شود ؟ این همانجایی است که فرآیند Normalization شروع به کار می کند ، فرآیند Normalization در واقع یک راهنما برای بهینه سازی طراحی Database های ما می باشد. سئوالاتی که در انتهای پاراگراف قبلی با هم شنیدیم همه و همه در فرآیند Normalization به پاسخ خود خواهند رسید.
اولین فرم یا سطح Normalization این است که شما یک Table ایجاد کنید که در آن گروه ها یا Group های تکراری وجود نداشته باشد ، در واقع شما نباید در سطح Column های خود داده های تکراری داشته باشید. بنابراین ما در اولین مرحله یک Table ایجاد می کنیم که در آن Column های تکراری وجود نداشته باشد.
اما اینکار چگونه انجام می شود ؟ پاسخ ساده است ، در این مرحله شما Table اولیه را به دو Table به نام های Orders یا سفارشات و محصولات یا Products تفکیک می کنید.خوب همانطور که در تصویر پایین مشاهده می کنید ما اطلاعات مربوط به Products یا محصولات را از درون Orders یا سفارشات خارج کردیم و یک Table جدید ایجاد کردیم ، حالا کاری که باید انجام شود این است که اطلاعات مربوط به Order ها باید به اطلاعات موجود در Products دسترسی داشته باشند ، اما نکته در اینجاست که این اتصال یا بهتر بگوییم ارتباط چگونه ایجاد می شود ؟
همانطور که در مرحله قبلی مشاهده کردید ما Table اولیه را بررسی کردیم و با توجه به وجود داده های تکراری ، یک Table دیگر به نام Products را اضافه کردیم و همه اطلاعات مرتبط با Products ها در آن قرار دادیم. در این Table های جدیدی ایجاد شده شما چند Column جدید مشاهده می کنید
Column ای به نام Order ID به Table ها اضافه شده است. همانطور که در جداول بالا مشاهده می کنید جدول Orders دارای چند Column به نامهای Order ID یا شناسه سفارش ، Order Date یا تاریخ سفارش و Customer یا نام مشتری می باشد
ما علاوه بر داده های اولیه ، در مرحله اول Column ای به نام Order ID را هم در جدول Orders و هم در جدول Products داریم ، با توجه به اینکه رابطه بین Table ها از طریق کلید خارجی یا Foreign Key انجام می شود ، ابتدا برای هر یک از Table ها ما یک primary Key تعریف می کنیم
در مثال بالا Order ID کلید اصلی یا Primary Key ما می باشد که می توانیم از طریق این کلید بصورت منحصر به فرد هر سفارش را شناسایی کنیم. اما این ساختار جدول Orders بود ، جدول دوم که جدول Products می باشد همه اطلاعات مورد نیاز در خصوص کالاهای سفارشی را در خود نگه می دارد
اگر به این جدول نیز توجه کنید خواهید دید که یک Column مشابه چیزی که در جدول Orders وجود دارد به نام Order ID قرار گرفته است ، شما برای برقراری رابطه بین Orders و Products از این Column می توانید به عنوان Foreign Key برای ربط دادن دو جدول استفاده کنید. این Column که به نام Order ID می باشد به Order ID ای که در جدول Orders وجود دارد اشاره خواهد کرد.
تا اینجای کار مشکلی نیست اما قانون Normalization به ما می گوید که تا جاییکه ممکن است نبایستی داده تکراری وجود داشته باشد اما در این سناریو اگر در جدول Products دقت کنید مشاهده می کنید که تعدد و تکرار رکوردها به وضوح قابل مشاهده است
در واقع هر باری که مشتری شما یک سفارش در سیستم ثبت کند یکبار اطلاعات مجددا در جدول Products درج می شود ، به جدول بالا نگاه کنید در اولین نگاه متوجه می شوید که کاربر Mohammad Nasiri دوبار به عنوان سفارش Product ها در لیست Product Table ذخیره شده است و این به معنای زیاد شدن داده های تکراری به مرور زمان خواهد شد.
البته این تازه یک مثال ساده در خصوص این سناریو است ، در سناریو های واقعی شما برای جدول Products خود ممکن است اطلاعات دیگری از قبیل آدرس ایمیل ، شماره تلفن و بسیاری دیگر از موارد را داشته باشید
اما هر بار این داده ها بصورت تکراری در این جدول درج خواهند شد که این مورد عکس قانون Normalization می باشد. خوب ما همچنان داده های تکراری در مجموعه خواهیم داشت ! راهکار چیست ؟ این دقیقا همان زمانی است که Second Level Normalization یا Normalization سطح دوم شروع به کار می کند.
خوب در مرحله قبلی توجه کردید که Table ای که به نام Orders وجود دارد دارای تکرار رکورد Customers خواهد شد ، برای اینکه بتوانیم این دادها های تکراری مربوط به نام مشتری را از این مجموعه حذف کنیم نیازمند ایجاد و طراحی یک Table دیگر به نام Customers می باشیم که اطلاعات مشتریان یا Customers ما را در خود نگه می دارد .
این جدول همانطور که در شکل زیر نیز مشاهده می کنید دارای یک رابطه One TO Many می باشد . هر مشتری می تواند چندین Order و هر Order می بایست توان سفارش داده شدن بسیاری را داشته باشد. این رابطه بایستی بین Products و Orders ایجاد شود که یک رابطه چند به چند یا Many TO Many می باشد
بدین معنی که هر Products می تواند چندین بار Order داده شود و هر Order نیز می تواند شامل چندین Products باشد. خوب ایجاد کردن Table ای به نام Customers در واقع Second Normalization Form یا حالت دوم Normalization می باشد ، ما هنوز ارتباط چند به چند بین Orders و Products را ایجاد نکرده ایم
اگر به خاطر داشته باشید گفتیم که SQL Server توانایی ایجاد رابطه های چند به چند بصورت مستقیم را ندارد و می بایست این ارتباط از طریق یک Table میانی انجام شود که به Join Table معروف است ، دقت کنید در مرحله بعدی ما Join Table را ایجاد می کنیم که مشخصات کامل سفارش ها را در خود نگه دارد.
در بخش بعدی با هم مرحله سوم Normalization را تکمیل می کنیم و Table میانی که الان عنوان کردیم را با هم خواهیم ساخت و به سراغ مشکلات احتمالی نهایی و نکاتی که در خصوص این طراحی باید در نظر بگیرید خواهیم پرداخت. در نهایت طرح جامعی که ایجاد کرده ایم را در کنار هم قرار داده و به بررسی نهایی آن می پردازیم.
در بخش قبلی در خصوص ابتدا کمی در خصوص شیوه طراحی یک پایگاه داده معمولی صحبت کردیم ، سپس اشاره کردیم که بایستی تمامی موجودیت های خود را در قالب یک Table مجتمع کنیم و شروع کنیم به انجام فرآیند Normalization ، گفتیم که تا جاییکه امکان دارد نباید داده های تکراری یا بهتر بگوییم رکوردهای تکراری در Table های خود داشته باشیم
و این هدف اصلی Normalization نیز می باشد ، به همین دلیل در سطح اول جدوال Orders و Products را از جدول اولیه خارج کردیم، سپس برای اینکه این جداول بتوانند به همدیگر متصل شوند از ساختار Primary Key و Foreign Key که توسط Order ID ایجاد شده بود استفاده کردیم که در واقع سطح اول یا حالت اول Normalization ما بود .
در سطح دوم با توجه به وجود داده های تکراری در جداول تصمیم گرفتیم Table جداگانه ای به نام Customers هم ایجاد کنیم که اطلاعات مشتریان ما در آن قرار داشته باشد که به عنوان سطح دوم یا حالت دوم Normalization ما بود ، در این بخش که ادامه همان سری می باشد
ما سطح سوم Normalization را انجام می دهیم و در آن رابطه بین Table ها را از طریق یک Table میانی ایجاد می کنیم ، بعد از تکمیل این فرآیند شما را با نکاتی که در خصوص Normalization وجود دارد آشنا خواهیم کرد و به امید خدا ادامه قسمت ها را خواهیم داشت.
اگر به تصویر بالا توجه کنید متوجه می شوید که ما یک Table به نام Orders داریم که در آن یک Column به نام Customer ID یا شناسه مشتری وجود دارد. Customer ID در اینجا به عنوان کلید خارجی یا Foreign Key ها محسوب می شود که به Table ای به نام Customers اشاره می کند.
با استفاده از این روش شما Table های Orders و Customers را به هم مرتبط کرده اید و زمانیکه یک مشتری یا customer یک سفارش یا Order را می دهد با استفاده از Customer ID ای که در جدول Orders وجود دارد دقیقا به Customer یا مشتری که اطلاعات کامل آن در آن وجود دارد اشاره خواهد کرد.
با این روش شما دقیقا می توانید متوجه بشوید که چه مشتری چه سفارشی داده است و این Foreign Key وظیفه ارتباط این دو جدول را انجام می دهد. در همین جدول دقت کنید که Customer ID در جدول Customers به عنوان کلید اصلی یا Primary Key ما انتخاب شده است و این دقیقا مثال جامعی از رابطه یک به چند یا One To Many می باشد.
خوب حالا بیابید با هم یک تغییر بزرگتر در طراحی Table ها بدهیم ، خوب ما همچنان جدول Orders را خواهیم داشت اما یک جدول دیگر به نام Products به مجموعه جداول خود اضافه خواهیم کرد ، در این جدول ما اطلاعات محصولات خود را ذخیره سازی خواهیم کرد
و همچنان هم تاکید می کنم که ذخیره سازی ما در قالب یک Table جداگانه انجام می شود. خوب اگر به تصویر پایین دقت کنید که در آن جدول Products ما ایجاد شده است متوجه خواهید شد که ما همچنان یک Column در این جدول به عنوان Name یا نام کالا داریم اما یک Column جدید به نام قیمت کالا یا List Price نیز به Table خود اضافه کرده ایم که در آن اطلاعات قیمت کالای ما ذخیره خواهد شد.
در نهایت توجه کنید که ما یک Column به نام Product ID را همچنان داریم ، که این column در این Table در نقش Primary Key ما ایفای نقش خواهد کرد ، خوب مشکل ما از اینجا شروع می شود که ما قرار است جداول Orders و Products و Customers را در کنار هم قرار دهیم و به هم مرتبط کنیم .
خوب به نظر شما ما چگونه می توانیم این ارتباط را برقرار کنیم ؟ همانطور که از ابتدای قسمت ها هم اشاره کردیم یک Product می تواند چندین بار Order داده شود و از طرفی یک Order نیز می تواند شامل چندین Product باشد و این یعنی باید بین این جداول یک رابطه Many To Many برقرار شود
قبلا هم اشاره کرده ایم که SQL Server بصورت مستقیم نمی تواند رابطه های Many To Many را ایجاد کند و به همین دلیل ما مجبور با استفاده از یک Table میانی هستیم که بتواند به عنوان واسطه این جداول را به هم مرتبط کند. به تصویر زیر دقت کنید ، در اینجاست که Table ای به نام Order Details وارد مدار می شود. به Table های زیر دقت کنید.
خوب در جدول Order Details قسمت Order ID به جدول Orders و قسمت Product ID به جدول Products مرتبط شده اند. خوب با استفاده از این روش شما می توانید اطلاعات کاملی در خصوص سفارش ها و کالاهای خود داشته باشید ، اگر به جدول Order Details نگاه کنید در رکورد اول مشاهده می کنید
که مشخص است اولین سفارش ثبت شده ما یعنی Order ID = 1 به نوع محصول پوشک Molfix که Product ID = 1 است اشاره می کند و تعداد آن 5 عدد می باشد و قیمت هر واحد آن 10 هزار تومان و مجموع قیمت آنها که در Line Total نوشته شده است به 50 هزار تومان می رسد.
البته در خصوص بسیاری از نکات که در این جداول وجود دارد در آینده بسیار صحبت خواهیم کرد اما در اینجا همین مقدار کفایت می کند. اما نقطه قوت این طراحی در کجا است ؟ چه اتفاقی می افتد اگر Sale Price یکی از Product های شما تغییر کند ؟
ما می خواهیم همیشه مطمئن شویم که قسمت محصول در زمانیکه سفارش یا Order داده شده است چقدر بوده است ؟ به همین دلیل است که ما قیمت محصول را در قسمت Sale Price در قالب یک Column جداگانه ذخیره می کنیم. همچین دقت کنید که ما در همین جدول یک محاسبه کوچک نیز انجام دادیم و Sale Price را در Quantity ضرب کردیم و نتیجه را در یک Column به نام Line Total ذخیره کردیم . این دقیقا همان چیزی است که شما باید در یک طراحی خوب Database در نظر داشته باشید.
خوب Database نهایی که در بالا مشاهده می کنید را در نظر داشته باشید ، تقریبا تمامی فرآیند هایی که ما انجام داده ایم در این Table ها خلاصه شده اند. ما یک Table به نام Order Details ایجاد کردیم که دارای column هایی به نام Order ID یا شناسه سفارش ، Product ID یا شناسه کالا ، Quantity یا تعداد سفارش ، Sale Price یا قیمت فروش و در نهایت Line Total است که مجموع قیمت سفارش ها را در خود نگه می دارد ، این table دارای رابطه Many To Many است .
همچنین با ایجاد شدن این Table ما اطلاعات مربوط به Order ها را از Table ای که برای Product ها در نظر گرفته شده بود حذف کردیم و به جای آن در جدول Products یک Column جدید به نام List Price اضافه کردیم. اگر به جدول Order Details توجه کنید یک Column به نام Sale Price وجود دارد که نمایانگر قیمت فروش کالا است
ما در عین حال یک Column دیگر در جدول List Price داریم که قیمت حال کالا را نمایش می دهد ، حال اگر قیمت امروز محصول عوض شود و ارزش ریالی آن زیاد شود شما بر اساس قیمت و تاریخ سفارش می توانید قیمت اولیه محصول را بدست بیاورید.
همچنین ما برای اینکه بتوانیم Query های ساده تری بگیریم یک Column به نام Line Total به Order Details اضافه کرده ایم. زمانیکه صحبت از Normalization سطح سوم یا فرم سوم می شود یک قانون وجود دارد که با این جمله بیان می شود : در Normalization سطح سوم هر ارزش یا Value یا مقدار بایستی وابسته به یک کلید یا Key باشد.
این بدین معناست که یعنی column ای به نام Line Total وابسته به کلید های Column های دیگری مثل Quantity و Sale Price می باشد . البته در این مثال ما بر خلاف قانون Normalization کار کردیم و یک Column اضافه به جدول برای محاسبه مقدار اضافه کردیم. اما فراموش نکنیم که برخی اوقات برای اینکه بتوانیم کارایی Database خود را بیشتر کنیم مجبور هستیم Normalization را برعکس کنیم و فرآیند Denormalization را انجام دهیم.
خوب در قسمت قبلی در نهایت به یک نتیجه کلی رسیدیم و توانستیم در سطح سوم نیز یک Normalization بر روی داده های خود داشته باشیم ، البته درست است که عنوان قسمت های که تا کنون نوشته ایم به طراحی Database معروف است اما واقعا ما در اینجا فقط مبانی طراحی Database ها را کار کردیم و برای مباحث پیشرفته دوره های تخصصی خاص وجود دارد که بصورت ویژه فقط در مورد طراحی Database ها توضیح می دهند.
Normalization ای که ما انجام دادیم حداقل شما را تا حدودی با این فرآیند آشنا کرد. نکته مهم در خصوص Normalization این است که Normalization فقط یک راهنما است و هیچ قانون یا سیاست قطعی برای استفاده و طراحی آن وجود ندارد ، اگر بخواهیم با شما صادق باشیم باید بگوییم که بسیاری از افراد که با پایگاه های داده کار می کنند
حتی شاید واژه Normalization را نیز نشنیده باشند و اصلا به آن فکر نکنند ، اما افرادی که کار طراحی Database را انجام می دهند طبیعی است که بعد از مدتی انجام فرآیند Normalization برایشان مانند یک امر ذاتی می شود و بصورت ناخودآگاه طراحی های خود را Normalize می کنند.
توجه کنید که همیشه قرار نیست شما Table های خود را Normalize کنیم ، همانطور که قبلا هم اشاره کردیم برخی اوقات برای اینکه کارایی و سرعت بالا برود شما عکس این عملیات یا فرآیند Denormalization را انجام می دهید ، در واقع اگر شما یک طراح Database حرفه ای و با تجربه بودید به این شکل بصورت گام به گام عملیات Normalization را انجام نمی دادید بلکه به احتمال زیاد اولین نتیجه طراحی شما ، آخرین نتیجه طراحی بود که در این سری قسمت ها به دست آمد.
فراموش نکنید که حفظ کردن در فرآیند Normalization وجود ندارد ، این کار بایستی بصورت یک قانون در کار شما قرار بگیرد و شما نباید برای مثال حفظ کنید که سطح یک Normalization چه می کند و سطح دوم و .... این امر بعد از مدتی بصورت ذاتی در شما نهادینه می شود ( عین این لغات قلمبه سلمبه ای که مسئولین میگن : نهادینه :D )
بصورت خلاصه فرآید Normalization ای که ما در اینجا انجام دادیم چند قانون ساده اما اساسی داشتیم ،قانون اول : ما نباید اطلاعات Column های تکراری داشته باشیم . ما چند کالا داشتیم که سفارش می دادیم ؟ آیا قرار است به ازای هر سفارش یک Column به Table ما اضافه شود ؟
قانون دوم : ما نباید اطلاعات رکوردها یا Row های تکراری داشته باشیم. یک مشتری چند عدد سفارش دارد؟ آیا ما قرار است به ازای هر سفارش مشتری یک رکورد جداگانه ایجاد کنیم ؟ قانون سوم : تا جاییکه ممکن است مقادیر محاسبه شده را در Table های خود ذخیره نکنید. دلیل این امر کاملا مشخص است ، اینکار باعث بالا رفتن Load کاری و پایین آمدن سرعت و کارایی Database می شود، قانون آخر : داده اصلی ما بایستی استوار و پابرجا باقی بماند.
چه اتفاقی می افتد اگر قیمت فروش یک کالا تغییر کند ؟ من می خواهم بدانم در ابتدای کار قیمت فروش محصول مورد نظر چقدر بوده است ، فارق از اینکه داده امروزی چه اطلاعاتی به من می دهد. بنابراین بایستی مطمئن شویم که برای این مورد یک Column جداگانه در نظر گرفته شده باشد .
اگر شما این چهار قانون ساده را در ذهن داشته باشید و طراحی های خود رعایت کنید ، Database شما خوب طراحی می شود. البته من نمی خواهم بگویم که این طراحی و این قوانین کاملا قطعی و درست هستند و همچنین نمی خواهم بگویم که این قوانین برای همه Database ها و در تمامی سناریو ها قابل اجرا هستند اما به هر حال در بیشتر آنها کاربردی است ، همین فروشگاه انجمن تخصصی فناوری اطلاعات ایران نیز از چنین طراحی Database ای برای حداقل فروشگاه خود استفاده کرده است.
حواسم به این موضوع هست که شما خسته شده اید و می خواهید وارد مسائل کاربری تر و عملی مرتبط به SQL Server بشوید اما عجله نکنید ، این مفاهیم برای ادامه کار شما الزامی است و باید خوب آنها را درک کنید. حال برای اینکه مجموعه این قسمت های که نوشته ایم را به نوعی تا اینجا خاتمه بدهیم بیایید در مورد کار کردن با داده ها در SQL Server صحبت های اولیه را بکنیم تا بدانید در آینده قرار است با چه مسائلی مواجه شوید و چگونه قرار است با داده ها کار کنید. بصورت کلی برای کار کردن با Database ها شما با چهار دستور یا Statement بایستی آشنایی داشته باشید :
یکی از مهمترین مسائلی که در خصوص SQL Server باید بدانید منطق های جستجو و ایجاد تغییرات در Database ها در این RDBMS است. به صورت کلی ما در Database های SQL Server دو منطق جستجو و ایجاد تغییرات داریم که به منطق Row Based یا بر اساس ردیف یا رکورد و منطق نتیجه یکدست یا Result Set تقسیم بندی می شوند.
ساختار SQL Server به گونه ای است که برای استفاده از منطق Result Set بهینه سازی شده است ، در این منطق شما بعد از تعیین شرط یا دستور مورد نظر به SQL Server می گویید که تمامی رکوردهایی که دارای فلان شرط هستند را به یکباره تغییر و دستورات مورد نظر را بر روی آنها اعمال کند.
SQL Server بعد از اجرا دستور در منطق Result Set به یکباره و آنی دستور شما را اجرا و نتیجه را اعلام می کند. روش دوم منطقی به نام Row Based است که در آن شما می توانید یک بروز رسانی تکی ، یک حذف تکی یا مسائلی از این مورد را به سادگی انجام دهید.
اگر بخواهیم داده های SQL Server را بصورت مجزا برای دستور و SQL تک تک اجزا و جزئیاتی که می خواهیم تغییر و بروز رسانی کنیم تعیین کنیم ،برای اینکار از مفهومی به نام Cursor استفاده می کنیم . برای اینکه خیال شما راحت شود و راحت تر بتوانید از SQL Server استفاده کنید به عنوان یک قانون معمول به شما می گویم که از Cursor ها استفاده نکنید.
استفاده از Cursor ها باعث پایین آمدن کارایی و همچنین بالا رفتن پیچیدگی کارهای شما می شود و این قانون را که بنده همیشه می گویم و تبدیل به قانون شبکه کارهای ITPRO شده است را فراموش نکنید : KISS کنید ، البته نه به معنای Kiss معروف بلکه Keep It Simple Sysadmin ، تا جاییکه ممکن است برای خود کارها را ساده انجام دهید و از پیچیدگی ها پرهیز کنید.
آخرین چیزی که تا اینجای دوره می خواهم به شما آموزش بدهم مفهومی به نام متغیر یا Variable است که تا انتهای دوره یاد می گیرید که باید بارها از آن استفاده کنید. متغیر ها یا Variable ها برای ذخیره سازی داده های موقتی یا Temporary ساخته شده اند. اگر کمی برنامه نویسی کرده باشید حتما با مفهوم Variable آشنایی دارید ، در SQL Server Variable دارای سه قسمت مهم است که به شکل زیر می باشد :
برای اینکه درک بهتری از تعریف یک Variable در SQL Server داشته باشید می توانید به تعریف زیر نگاهی بیندازید ، البته اصلا عجله نکنید به مرور تمامی این مفاهیم را بصورت عملی با هم آموزش خواهیم دید :
DECLARE @<name> <DataType>; SET @<Name> = <Value>;
ما در این سری قسمت های که تاکنون داشته ایم نگاهی به انواع Database ها داشتیم و تفاوت Database های Flat و RDBMS ها را با هم یاد گرفتیم. با مفاهیم اولیه Database آشنا شدیم ، مفاهیمی مثل Table ، Row ، Column ، Field ، Primary Key و ... ساختار اولیه Object Type ها در SQL را با هم یاد گرفتیم.
کمی در خصوص طراحی پایگاه های داده و همچنین انجام فرآیند Normalization صحبت کردیم و در نهایت با اولین دستورات کاربردی در هنگام استفاده از SQL Server آشنا شدیم ، تا اینجا هر چیزی که یاد گرفته اید مباحث تئوری بوده است اما به امید خدا در ادامه قسمت ها مباحث کاربری و عملی می شود و شما درگیر محیط SQL Server خواهید شد ، اینجاست که مفاهیمی که تا کنون یاد گرفته اید را بصورت عملی در محیط واقعی آزمایش و درک خواهید کرد.با ما تا انتهای قسمت ها باشید
در ادامه دوره آموزشی خود در این بخش و بخش بعدی به معرفی محیط مدیریتی Management Studio ، روش های متصل شدن به Database ها در SQL Server ، روش های اتصال به سرور SQL و در نهایت آموزش قرار دادن Comment برای دستورات T-SQL خواهیم پرداخت
البته این بخش مقدمه ای برای قسمت ها بعدی است که در آنجا در خصوص روش استفاده از دستور SELECT و مخلفات آن توضیحاتی را ارائه خواهیم کرد ، انتخاب کردن رکورد ها و column ها با استفاده از دستور SELECT را به امید خدا در بخش بعدی آموزش خواهیم داد
فعلا عجله نکنید ما می خواهیم از ابتدای ابتدا مفاهیم را برای شما توضیح دهیم ، قابل توجه اساتید محترم دانشگاهی که از این سری قسمت ها به عنوان جزوه دانشگاهی خود استفاده می کنند ، حداقل استاد گرامی منبع و نویسنده را خودتان معرفی نکنید برای شما افت دارد ، فارق از همه این مسائل به ادامه بخش توجه کنید.
در ابتدای راه باید یاد بگیرید که SQL Server هم مانند سایر نرم افزارهای دیگر یک کنسول مدیریتی دارد که آن را به اسم Management Studio می شناسیم و در واقع اسم کامل آن Microsoft SQL Server Management Studio یا MSMS می باشد. شما با استفاده از این کنسول مدیریتی می توانید به انواع و اقسام سرویس هایی که SQL Server به شما ارائه می دهد متصل شوید
و از امکانات آن استفاده کنید ، توجه کنید که SQL Server فقط یک Database خالی نیست ، دارای انواع و اقسام سرویس هایی مثل Reporting Service ، Analysis Service و Integration Service می باشد که هنوز خیلی زود است وارد آنها شویم ، ما فعلا با یک سرویس اصلی کار داریم که Database Engine یا موتور دیتابیس ها و مدیریت Database ها می باشد.
با توجه به اینکه ما توسط انواع و اقسام نرم افزارهای مختلف می توانیم به Database های SQL Server دسترسی پیدا کنیم و در آنها تغییرات ایجاد کنیم نمی توانیم از Management Studio به عنوان تنها ابزار اینکار اسم ببریم اما قطعا این ابزار یا بهتر بگوییم کنسول مدیریتی مهمترین و پرکاربردترین ابزار برای دسترسی پیدا کردن و اعمال تغییرات بر روی Database های SQL Server می باشد.
همانطور که الان می دانید ما می توانیم چندین Database بر روی یک سرور SQL داشته باشیم ، بنابراین زمانیکه شما کنسول مدیریتی Management Studio را باز می کنید تا Query های خود را بگیرید ، از شما سئوال می شود که کدام Database را می خواهید باز کنید ؟
خوب در اولین گام شما براحتی می توانید از لیستی که به شما نمایش داده می شود و جلوتر به آن اشاره خواهیم کرد Database خود را انتخاب کنید ، البته به این موضوع توجه کنید که شما می توانید چندین فرآیند نصب SQL Server را بر روی یک سرور انجام دهید که به عنوان INSTACE هر کدام از این نصب ها شناخته می شود.
اگر شما چندین INSTACE از SQL Server را بر روی سرور خود نصب کرده اید بایستی اسم سرور به علاوه Back Slash و نام INSTACE را وارد کنید تا بتوانید به سرور مورد نظر متصل شوید ، ممکن است در جایی به عنوان DBA حضور پیدا کنید که شما مدیر شبکه یا مدیر DB های آن نباشید و شناختی از محیط و اسامی سرورها نداشته باشید
در چنین مواقعی حتما در این خصوص سئوال کنید تا اطلاعات مورد نظر در اختیار شما قرار بگیرد ، البته این کاملا به شعور این عزیزان دارد که بخواهند اطلاعات را در اختیار شما قرار بدهند یا ندهند ( باور کنید مورد داشتم پدرمو در آورد تا یه اسم داد بهم ) آدرس باید مشابه آنچه در تصویر پایین مشاهده می کنید باشد :
"Server Name \ Instace Name" ITPRODBSRV\ITPRODBA
بعد از اینکه اسم سرور و نام INSTACE خود را انتخاب کردیم نوبت به تعیین هویت کاربری است که قرار است به Database مورد نظر دسترسی پیدا کند. به زبان دیگر ما باید توسط SQL Management Studio احراز هویت بشویم. SQL Server دو روش احراز هویت یا Authentication را پشنیبانی می کند
روش SQL Server Authentication و Windows Authentication ، زمانیکه شما می خواهید از Windows Authentication استفاده کنید تنها کاری که باید انجام دهید این است که با کاربر Domain مربوطه یا کاربر Local سیستم وارد سیستم عامل ویندوز شوید و کنسول Management studio را باز کنید و بر روی دکمه Connect کلیک کنید. اطلاعات احراز هویتی ما بصورت خودکار توسط ویندوز به SQL Server ارسال می شود و دیگر نیازی به وارد کردن نام کاربری و رمز عبور نخواهیم داشت.
از طرفی دیگر شما می توانید نام کاربری و رمز عبور مورد نظر خود را در SQL Server ذخیره کنید که در این قسمت شما بایستی یک نام کاربری و رمز عبور در SQL Server تعریف کرده باشید و دسترسی های لازم به Database ها را نیز داده باشید ، به این روش SQL Authentication گفته می شود
به تصویر بالا نگاه کنید ، با انتخاب کردن Windows Authentication از شما نام کاربری و رمز عبور درخواست نمی شود اما همانطور که در تصویر پایین مشاهده می کنید بعد از انتخاب SQL Authentication از شما نام کاربری و رمز عبور مربوط به SQL Server سئوال خواهد شد.
اگر بخواهیم از Windows Authentication استفاده کنیم اما نه با کاربری که با آن Login کرده ایم می توانی زمانیکه Management Studio را اجرا می کنیم بر روی آن راست کلیک کرده و گزینه Run As را انتخاب و نام کاربری مورد نظرمان را وارد کنیم تا Management Studio با اطلاعات هویتی کاربر مورد نظر ما اجرا شود.
علاوه برمواردی که در بالا عنوان کردیم در همان بدو نمایش صفحه ورود Management Studio شما می توانید نام Database ای که می خواهید به آن متصل شوید را نیز انتخاب کنید و یا آن را تایپ کنید. اگر شما هیچ Database پیشفرضی را برای متصل شدن انتخاب نکنید
بصورت پیشفرض Database ای به نام Master به عنوان اولین Database انتخاب شده و به شما نمایش داده می شود. البته این در بیشتر مواقع اتفاق می افتد ممکن است بر حسب مورد Database دیگری به صورت پیشفرض در نظر گرفته شده باشد ، Master در واقع Database ای است که آن را می توان به عنوان قلب یا هسته اصلی SQL Server معرفی کرد ، اگر شما Master را نداشته باشید حتما با سرور خود به مشکل خواهید خورد.به هر حال این از مبانی صفحه اول Management Studio ، بیاید موارد دیگری را نیز با هم بررسی کنیم به تصویر زیر دقت کنید :
خوب حالا به تصویر بالا دقت کنید ، در اولین گام شما باید نوع سرویسی که می خواهید به آن متصل شوید را انتخاب کنید ، همانطور که قبلا هم اشاره کردم در اینجاست که شما می توانید تعیین کنید به کدام سرویس از سرویس های SQL می خواهید متصل شوید که Reporting Service ، Integration Service ، Analysis Service برخی از این سرویس ها هستند
در این قسمت ما گزینه Database Server را انتخاب می کنیم.بعد از انتخاب نوع سرویس بایستی اسم سرور و INSTACE ای که می خواهید به آن متصل شوید را وارد کنید که همانطور که در تصاویر بالا مشاهده می کنید
در این حالت با توجه به اینکه سناریو بصورت اختصاصی برای وب سایت انجمن تخصصی فناوری اطلاعات ایران طراحی شده است به صورت ITPRODBSRV//ITPRODBA می باشد. سپس Authentication Type را انتخاب کنید همانطوری که قبلا هم اشاره کردیم با وارد کردن حالت SQL Authentication از شما نام کاربری و رمز عبور سئوال می شود اما در حالت Windows Authentication این اتقاق رخ نمی دهد.
اگر بر روی دکمه Options کلیک کنید با تصویر بالا مواجه خواهید شد ، در این قسمت شما می توانید نام Database پیشفرضی که می خواهید به آن متصل شوید را مشخص کنید ، اینکار را هم می توانید از طریق منوی باز شو انجام دهید و
هم از طریق تایپ کردن که در اصل موضوع تفاوتی نمی کند.زمانیکه همه این موارد را انجام دادید ما آماده هستیم وارد محیط مدیریت Management Studio شویم ، می توانید بر روی دکمه Connect کلیک کنید. در بخش بعدی در خصوص اتصال به دیتابیس ها و برخی از ویژگی های محیط Management Studio صحبت خواهیم کرد.
در بخش قبلی یاد گرفتیم که چگونه به سرور SQL و Database های آن در بدو ورود به Management Studio متصل شویم . در این بخش ما دیگر دکمه Connect را زده ایم و وارد محیط Management Studio شده ایم ، شما قرار است در این بخش یاد بگیرید
که چگونه توسط محیط Management Studio اعمالی از قبیل متصل شدن به Database ها ، Query گرفتن و همچنین قرار دادن توضیحات یا Comment ها را انجام دهید. نکته بسیار مهم قبل از شروع دوره این است که با توجه به اینکه ما نمی خواهیم از صفر یک Database ایجاد کنیم و زمان خود را صرف آن کنیم از یک نمونه آماده از Database ها به نام AdventurWorks استفاده می کنیم که خود مایکروسافت برای انجام عملیات های آموزش و تست به شما ارائه داده است .
این نمونه Database یک مجموعه کامل برای آموزش و در واقع کاملترین Database در حوزه آموزش به حساب می آید و ما نیز بر اساس همین مورد کارهای خود را انجام می دهیم ، حالا که بر روی دکمه Connect کلیک کرده اید بهتر است
قبل از اینکه ادامه ماجرا را پیش ببریم این Database را به محیط Management Studio و Database های خود Attach کنید برای اینکار کافیست به آموزش بنده با عنوان چگونه یک Database را به SQL Server 2012 اضافه کنیم ؟ مراجعه کنید. بعد از اینکه اینکار را انجام دادید به تصویر زیر که اولین نمایش از محیط Management Studio است نگاه کنید :
خوب حالا ما آماده ایم که اولین Query را در SQL Server بگیریم ، به تصویر بالا نگاه کنید در Toolbar ای که مشاهده می کنید و مشخص شده است گزینه ای به نام New Query وجود دارد که با کلیک کردن بر روی آن شما می توانید Query های خود را در آن وارد کنید ، همین صفحه با استفاده از کلید های ترکیبی Ctrl+F5 هم قابل مشاهده است. بعد از کلیک کردن بر روی New Query یا زدن کلیدهای ترکیبی Ctrl+F5 صفحه زیر را مشاهده خواهید کرد :
برای نوشتن Query های خود از قسمت سفید تصویر بالا استفاده می کنیم. نکته اول این است که شما ابتدا باید به یک Database متصل شوید تا بتوانید دستورات خود را در آن اجرا کنید. برای متصل شدن به Database ها دو روش معمول وجود دارد
ابتدا استفاده از دستورات T-SQL یا همان دستوران SQL است و دومین راهکار استفاده از منوی بازشوی بالا همین تصویر است ، همانطور که در تصویر بالا مشاهده می کنید ما در حال استفاده از Database ای به نام master هستیم. با توجه به اینکه قرار است تمامی آموزش های ما بر اساس Database ای به نام AdventureWorks انجام شود ابتدا با استفاده از دستور در همین محیط به AdventureWorks متصل می شویم ، برای اینکار دستور زیر را وارد می کنیم :
USE AdventureWorks
بعد از اینکه دستور بالا را وارد کردید بایستی آن را اجرا کنید برای اجرا کردن دستورات در این محیط کافیست کلید F5 را بزنید و یا از Toolbar گزینه Execute را انتخاب کنید ، قاعدتا در آینده فقط از F5 استفاده خواهید کرد، بعد از اجرای دستور بالا نتیجه دستور با اعلام اینکه دستور با موفقیت انجام شد به شکل زیر نمایش داده می شود :
اگر به تصویر بالا دقت کرده باشید متوجه می شوید که شما می توانید بسیاری از اطلاعات در خصوص Database ها و موراد دیگر را با نگاه کردن به نوار ابزار و کادرهایی که باز شده اند بدست بیاورید. به نوار ابزار بالایی دقت کنید از این نوار ابزار شما متوجه خواهید شد که در حال استفاده کردن از Database ای به نام AdventureWorks2012 هستید
این گزینه با اجرای دستوری USE AdventureWorks بروز شده است و در تصویر قبلی مشاهده می کنید که نام master در این قسمت قرار گرفته است. در قسمت Object Explorer شما مشاهده می کنید که نام سرور به همراه INSTACE ای که به آن متصل شده اید به شما نمایش داده شده است
همچنین نام کاربری که به وسیله آن به Database مورد نظر متصل شده اید را نیز به شما نمایش داده است ، در تصویر بالا نام ITPRODBSRV به عنوان نام سرور ، ITPRODBA به عنوان نام INSTACE و AdventureWorks2012 به عنوان نام Database به همراه نام کاربری Administrator مشخص شده است.
اگر به تصویر دقت کنید در جلوی نام کاربری یک عدد داخل پرانتز نوشته شده است که به آن Process ID یا SPID گفته می شود. این دقیقا چیزی شبیه به همان Process هایی است که در داخل Task Manager ویندوز مشاهده می کنید ، شما می توانید از طریق شناسایی این شماره به مدیر شبکه یا مدیر DB شبکه خود بگویید
که در حال کار کردن بر روی چه Process ای هستید ، این امر عادی است با توجه به اینکه همیشه شما در همه جا مدیر نیستید و به عنوان مشاور و یا کارشناس حضور پیدا می کنید. از طریق این SPID مدیر شبکه براحتی می تواند فرآیند های در حال اجرای شما را متوقف کند.
خوب ممکن است تا به حال از خواندن بخش های بنده خسته شده باشید اما همیشه گفته ام و باز هم می گویم عجله نکنید. در این قسمت می خواهیم با هم یاد بگیریم که چگونه می توانیم برای دستورات T-SQL خود توضیحات اضافه کنیم. متاسفانه اکثر برنامه نویسان و مدیران Database ای که در حال فعالیت هستند
یک اصل حیاتی را فراموش می کنند ، آنها برای دستورات و Query های خود توضیحاتی وارد نمی کنند. توضیحات اجرا نمی شوند ، اضافه کردن Comment در انتهای دستور یا دستورات باعث مفهوم تر شدن عملکرد دستور می شود و از طرفی به دیگران هم در درک بهتر کد شما کمک خواهد کرد.
شما ممکن است امروز یک Query ایجاد کنید و بدانید که چه عملیاتی انجام می دهد اما اگر همین Query را یک سال دیگر جلوی شما بگذارند متوجه نشوید که دقیقا چه کاری انجام می داده است ، با استفاده از توضیحات یا Comment شما می توانید براحتی در خصوص هر خط دستور خود توضیحاتی ارائه کنید تا در آینده در صورت مراجعه به Script یا دستور وارد شده بدانید که چه کاری بر روی آن انجام شده است.
علاوه بر اینکه توضیحات را می توانیم به عنوان یک روش آموزشی بررسی کنیم از آن می توانیم برای جلوگیری از اجرا شدن برخی از کدها نیز استفاده کنیم.یکی از نکاتی که در خصوص SQL Server و دستورات T-SQL باید بدانید این است که در این زبان یا در این نرم افزار شما Undo ندارید
یعنی نمی توانید Ctrl+Z را بزنید و انتظار داشته باشید اتفاقی که افتاده است به حالت قبل برگردد ، SQL Server همیشه فرض را بر این می گذارد که شما می دانید چه کاری انجام می دهید ، بنابراین اگر در جایی از دستور DELETE برای حذف داده ای استفاده کردید تنها راه برای بازیابی آن داده نسخه Backup شما خواهد بود .
SQL Server دو روش مختلف برای قرار دادن Comment در دستورات دارد ، توضیحات تک خطی یا Single Line Comments و توضیحات چند خطی یا Multiline Comments ، هر کدام از این نوع Comment ها برای موارد خاصی مورد استفاده قرار می گیرند اما بیشترین کاربرد را توضیحات تک خطی دارند
فرض کنید که برای دستور زیر می خواهیم توضیحاتی را ارائه کنیم در یک خط، برای اینکار کافیست بعد از دستور خود دو علامت dash یا -- قرار داده و توضیحات خود را در یک خط ارائه کنیم ، تا انتخاب خط مورد نظر به عنوان توضیح در نظر گرفته خواهد شد و اینها اجرا نخواهند شد :
USE AdventureWokrs2012 --Selecting AdventureWorks Database
برای اینکه بتوانید توضیحات دستورات خود را در چند خط ارائه کنید از طریق قالب دستوری زیر کار می کنیم ، در این حالت شروع Comment با استفاده از علامت // و انتهای آن با علامت // مشخص خواهد شد به مثال زیر دقت کنید :
USE AdbentureWorks2012 /* Selecting AdventureWokrs Database For Queries */
البته شما می توانید با استفاده از کلید های ترکیبی Ctrl+K و Ctrl+C و Ctrl+U عملیات Comment گذاری را نیز انجام دهید.
قبل از اینکه به سراغ Query گرفتن از SQL Server برویم بایستی یاد بگیریم که چگونه به Object ها دسترسی پیدا کنیم یا در اصطلاح فنی به Object ها رجوع یا Refer کنیم. هر Object در داخل یک Database برای خود دارای 4 قسمت برای نامگذاری می باشد. اولین قسمت اسم سروری که در آن قرار گرفته است
دومین قسمت نام Database ای است که در آن قرار می گیرد ، سومین قسمت Schema ای است که Object در آن قرار گرفته است و در نهایت نام خود Object می باشد. نام سرور قطعا در اینجا سروری است که Database های ما را در خود نگه می دارد ، قرار دادن نام سرور برای مشخص کردن Object ها کاملا اختیاری است
و اگر شما برای Refer کردن به Object های خود نام سرور را نداشته باشید مشکلی پیش نخواهد آمد و دلیل این امر این است که SQL Server بصورت پیشفرض در صورت قرار ندادن نام سرور ، همین سروری که به آن متصل شده اید را به عنوان نام سرور در نظر می گیرد.
در ادمه در بیشتر Query هایی که می گیرد متوجه خواهید شد که تقریبا در هیچکدام از آنها شما نام سرور را قرار نمی دهید و همین موضوع دقیقا برای نام Database نیز صادق است ، شما باید تعریف کنید که Object شما در کدام Database قرار دارد اما اگر اینکار را انجام ندهید مشکلی نیست ، SQL در این حالت مانند مرحله قبلی نام Database ای را در نظر خواهد گرفت که شما در حال حاضر به آن متصل شده اید ، بنابراین برای اشاره دقیق به یک Object در SQL Server موارد زیر لازم می باشد:
Schema در SQL Server در واقع چیزی شبیه به پوشه یا Folder است که ساختار Object های ما را مشخص می کند در کنار اینکه ما می توانیم با استفاده از آنها Permission ها را ایجاد کنیم و همچنین استفاده مجدد از Name ها داشته باشیم. نکته ای که در خصوص Schema وجود دارد این است که در صورتیکه شما یک Schema برای Refer کردن به Object خود در نظر نگیرید
و یا اینکه Schema ای که در نظر گرفته باشید موجود نباشد از قبل می توانید یک Default Schema یا Schemaی پیشفرض برای Object خود در نظر بگیرید که در صورتیکه هر یک از موارد بالا مشاهده شد SQL Server از آن استفاده کند ، Schema ای به نام dbo وجود دارد که معمولا به عنوان پیشفرض از طریق SQL Server انتخاب شده است.
همیشه پیشنهاد می شود که برای Object خود Schema را تعریف کنید ، دلیل اصلی این مورد این است که شما تنها کاربر SQL Server مورد نظر نیستید و ممکن است افراد دیگری نیز از Schema ای که شما تعیین کرده اید استفاده کنند و در آن تغییرات اعمال کنند
و ممکن است در این حالت کدهای شما نیز دچار اختلال شود ، بنابراین پیشنهاد می شود که همیشه برای خود Default Schema تعریف کنید. در نهایت پس از تمامی این مراحل شما باید اسم Object را مشخص کنید که قرار دادن این اسم الزامی است و شما برای اتصال به Object حتما باید اسم آن را بدانید.
SQL Server نیز مانند سایر زیان های برنامه نویسی برای نامگذاری Object های خود دارای قواعد و قوانین خاص خود می باشد. از جمله برخی از این قوانین می توانیم به استفاده کردن از حروف و کاراکتر Underscore __ در ابتدای اسامی Object ها اشاره کرد
در ادامه کلمه Object شما می توانید از حروف ، اعداد و کاراکتر Underscore استفاده کنید ، اما نکته جالب در خصوص نامگذاری Object ها در SQL Server این است که درست است که شما نمی توانید در حالت عادی از این قوانین سرپیچی کنید
اما با رعایت کردن یک ساختار جالب می توانید تقریبا هر اسمی برای Object خود انتخاب کنید ، برای مثال فرض کنید من می خواهم یک Object به اسم ITPRO@IR! ایجاد کنم ، در حالت عادی نمی توانید به چنین Object ای Refer کنید اما اگر برای Refer کردن به این Object آن را در داخل براکت به شکل [] قرار بدهید و یا داخل دابل کوتیشن به شکل "" قرار بدهید می توانید از هر اسمی برای Object های خود استفاده کنید .
اما نکته بسیار مهم در خصوص استفاده از دابل کوتیشن این است که این حالت بصورت پیشفرض در SQL Server قابل استفاده نیست و شما بایستی ابتدا قابلیت آن را فعال کرده و سپس برای Refer کردن به SQL Object های خود از آن استفاده کنید.
به این قابلیت در اصطلاح فنی Quoted Identifiers گفته می شود. اما برای اینکه در ایجاد این موارد دچار ابهام نشوید دقت کنید که اکثر DBA ها از براکت های مربعی یا همان [] برای اینکار استفاده می کنند و شما هم بهتر است برای اینکه گیج نشوید از این روش برای Refer کردن به Object ها استفاده کنید.
البته تنها همین دلیل استفاده از براکت نیست ، تقریبا تمامی نرم افزارهایی که بصورت خودکار کدهای SQL تولید می کنند برای نمایش Object ها از براکت استفاده می کنند ، این قالب تقریبا بصورت یک استاندارد در آمده است و به همین دلیل که استاندارد است برنامه نویسی و کد نویسی برای این نرم افزارها نیز راحت تر خواهد بود ، سعی کنید فارق از همه مسائل در کارهای خود استاندارد کار کنید این کاری است که تقریبا هیچ DBA ایرانی انجام نمی دهد.
سئوال بعدی که همیشه در ذهن عزیزان پیش می آید این است که آیا SQL Server یا بهتر بگوییم زبان T-SQL به حروف بزرگ و کوچک حساس است یا خیر ؟ پاسخ این موضوع را بصورت جامع و همیشه به یک صورت می شود ارائه کرد ، همیشه فرض کنید نرم افزار یا زبان برنامه نویسی که با آن کار می کنید Case Sensitive است
و به وارد کردن حروف بزرگ و کوچک حساس است ، دلیل این تفکر بسیار ساده است ، اگر شما فرض را بر این بگذارید که زبان شما Case Sensitive است و همه کدهای خود را به این صورت وارد کنید در نهایت اگر Case Sensitive هم نباشد مشکلی برای کدهای شما پیش نمی آید ، اما اگر کدهای خود را بر فرض این بنویسید که زبان Case Sensitive نیست ، حتما بعدها به مشکل خواهید خورد.
علاوه بر این توجه کنید که در بسیاری از مواقع پیش می آید که محیط کاری شما یک محیط چند لایه اس و پیچیده است که از انواع کدها بایستی در آن استفاده شود ، در واقع به چنین محیط های ترکیبی یا Mixed Environment گفته می شود ، فرض کنید
در حال حاضر در محیطی کار می کنید که کدهای تولیدی شما Case Sensitive نیستند اما مجبور می شوید از محیط دیگری که کدهای آن Case Sensitive است یک فراخوانی داده یا Call داشته باشید ، اگر شما در همان محیط اولی Case Sensitive بودن را رعایت می کردید
در فراخوانی کدهای زبان دیگر مشکلی ندارید اما اگر کدهای خود را Case Sensitive وارد نکرده باشید مشکلات فراوانی به وجود خواهد آمد. اگر فرض کنیم همه زبان های کد نویسی از جمله T-SQL بصورت Case Sensitive باشند زندگی و کد نویسی ما بسیار راحت تر خواهد شد.
اما به هر حال سئوال اصلی اینجا بود که آیا T-SQL به حروف بزرگ و کوچک حساس است یا خیر ؟ جواب خیر است . زبان T-SQL به حروف بزرگ و کوچک حساس نیست اما ما بر حسب رعایت یک استاندارد من در آوردی تمامی کدها را با حروف بزرگ وارد می کنیم تا خوانایی کدهای ما بالاتر برود
البته به این نکته همچنان توجه داشته باشید که مقایسه رشته ها همچنان در SQL Server Case Sensitive می باشد ، شما می توانید قابلیت Case Sensitivity را در سطح سرور ، در سطح Database ها و حتی در سطح Column ها فعال یا غیر فعال کنید ، حتی شما می توانید در سطح Query های خود نیز Case Sensitivity را داشته باشید یا نداشته باشید.
خوب حالا که با روش متصل شدن به Database ها آشنا شدید نوبت به معرفی ساختار اولین دستور مهم از سری دستورات T-SQL به نام SELECT می باشد . توجه کنید که ما در بیان فارسی می گوییم دستور SELECT در صورتیکه این دستور مجموعه ای از دستورات است و به همین دلیل به خاطر ساختار آن به آن SELECT Statement گفته می شود .مهمترین نکاتی که در خصوص دستور SELECT باید مد نظر داشته باشید این است که این دستور از شش قسمت اصلی تشکیل شده است :
حالا شما اگر حتی بخواهید پیچیده ترین Query ها را نیز از SQL Server بگیرید تنها از همین شش قسمت استفاده خواهید کرد. در واقع حتی Query های پیچیده هم معمولا تنها از 3 عدد از این قسمت ها استفاده می کنند و از همه آنها استفاده نمی شود ، مهمترین قسمت ها FROM ، WHERE و GROUP BY می باشد. در بخش های بعدی بصورت ویژه با این دستورات کار خواهیم کردو بصورت عملی کاربرد آنها را درخواهید یافت. امیدوارم مورد توجه شما قرار گرفته باشد.