Leran2002 9 آوریل 2015 در 12:31 ب.ظ

کتاب درسی زبان SQL (DDL، DML) با استفاده از گویش MS SQL Server به عنوان مثال. بخش اول

• مایکروسافت SQL Server،
• SQL

• آموزش

این آموزش در مورد چیست؟

این آموزش چیزی شبیه "مهر حافظه من" در زبان SQL (DDL، DML) است. این اطلاعاتی است که در طول فعالیت های حرفه ای من جمع شده و دائماً در ذهن من ذخیره می شود. این حداقل برای من کافی است که اغلب هنگام کار با پایگاه داده استفاده می شود. اگر نیاز به استفاده از ساختارهای SQL کاملتر باشد، معمولاً برای کمک به کتابخانه MSDN واقع در اینترنت مراجعه می کنم. به نظر من نگه داشتن همه چیز در سر خیلی سخت است و نیاز خاصی به این کار نیست. اما دانستن ساختارهای اولیه بسیار مفید است، زیرا... آنها تقریباً به یک شکل در بسیاری از پایگاه های داده رابطه ای مانند Oracle، MySQL، Firebird قابل استفاده هستند. تفاوت ها عمدتاً در انواع داده ها است که ممکن است در جزئیات متفاوت باشد. ساختارهای اولیه SQL زیادی وجود ندارد و با تمرین مداوم آنها به سرعت به خاطر سپرده می شوند. به عنوان مثال، برای ایجاد اشیا (جدول، محدودیت ها، فهرست ها و غیره)، کافی است یک محیط ویرایشگر متن (IDE) برای کار با پایگاه داده در دسترس داشته باشید و نیازی به مطالعه ابزارهای بصری متناسب با کار با آن نیست. نوع خاصی از پایگاه داده (MS SQL، Oracle، MySQL، Firebird، ...). این نیز راحت است زیرا تمام متن در جلوی چشمان شما قرار دارد و برای ایجاد، به عنوان مثال، یک فهرست یا محدودیت، نیازی به اجرای چندین برگه ندارید. هنگامی که دائماً با یک پایگاه داده کار می کنید، ایجاد، تغییر و به خصوص ایجاد مجدد یک شی با استفاده از اسکریپت ها چندین برابر سریعتر از زمانی است که آن را در حالت بصری انجام دهید. همچنین در حالت اسکریپت (و بر این اساس، با دقت کافی)، تنظیم و کنترل قوانین برای نامگذاری اشیاء آسانتر است (نظر ذهنی من). علاوه بر این، استفاده از اسکریپت ها زمانی راحت است که تغییرات ایجاد شده در یک پایگاه داده (مثلاً آزمایش) باید به همان شکل به پایگاه داده دیگری (مولد) منتقل شود.

زبان SQL به چندین بخش تقسیم می شود، در اینجا به 2 قسمت مهم آن نگاه می کنم:

• DML – زبان دستکاری داده ها که شامل ساختارهای زیر است:
  • SELECT - انتخاب داده ها
  • INSERT - درج داده های جدید
  • به روز رسانی - به روز رسانی داده ها
  • DELETE - حذف داده ها
  • MERGE - ادغام داده ها

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

این کتاب درسی بر اساس اصل گام به گام، یعنی. شما باید آن را به صورت متوالی بخوانید و ترجیحاً فوراً مثال ها را دنبال کنید. اما اگر در طول مسیر نیاز به یادگیری یک دستور خاص با جزئیات بیشتری دارید، از یک جستجوی خاص در اینترنت، به عنوان مثال، در کتابخانه MSDN استفاده کنید.

هنگام نوشتن این آموزش، از پایگاه داده MS SQL Server نسخه 2014 استفاده کردم و از MS SQL Server Management Studio (SSMS) برای اجرای اسکریپت ها استفاده کردم.

مختصری درباره MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) یک ابزار برای Microsoft SQL Server برای پیکربندی، مدیریت و مدیریت اجزای پایگاه داده است. این ابزار شامل یک ویرایشگر اسکریپت (که ما عمدتا از آن استفاده خواهیم کرد) و یک برنامه گرافیکی است که با اشیاء و تنظیمات سرور کار می کند. ابزار اصلی SQL Server Management Studio Object Explorer است که به کاربر امکان مشاهده، بازیابی و مدیریت اشیاء سرور را می دهد. این متن تا حدی از ویکی پدیا به عاریت گرفته شده است.

برای ایجاد یک ویرایشگر اسکریپت جدید، از دکمه New Query استفاده کنید:

برای تغییر پایگاه داده فعلی می توانید از لیست کشویی استفاده کنید:

برای اجرای یک فرمان خاص (یا گروهی از دستورات)، آن را انتخاب کرده و دکمه "Execute" یا کلید "F5" را فشار دهید. اگر در حال حاضر تنها یک دستور در ویرایشگر وجود دارد، یا باید همه دستورات را اجرا کنید، دیگر نیازی به انتخاب چیزی ندارید.

پس از اجرای اسکریپت ها، به ویژه آنهایی که اشیاء (جدول، ستون ها، نمایه ها) را ایجاد می کنند، برای مشاهده تغییرات، از refresh از منوی زمینه با برجسته کردن گروه مناسب (مثلاً جدول ها)، خود جدول یا گروه Columns در آن استفاده کنید.

در واقع، این تنها چیزی است که برای تکمیل مثال های ارائه شده در اینجا باید بدانیم. مابقی ابزار SSMS به راحتی قابل یادگیری است.

کمی تئوری

پایگاه داده رابطه ای (RDB یا از این پس در زمینه به سادگی DB) مجموعه ای از جداول به هم پیوسته است. به طور کلی، پایگاه داده فایلی است که داده ها در یک فرم ساختار یافته ذخیره می شوند.

DBMS - سیستم مدیریت پایگاه داده، یعنی. این مجموعه ای از ابزارها برای کار با نوع خاصی از پایگاه داده (MS SQL، Oracle، MySQL، Firebird، ...) است.

توجه داشته باشید
زیرا در زندگی، در گفتار محاوره ای، ما بیشتر می گوییم: "Oracle DB" یا حتی فقط "Oracle" که در واقع به معنای "Oracle DBMS" است، سپس در متن این کتاب درسی گاهی اوقات از اصطلاح DB استفاده می شود. با توجه به زمینه، فکر می کنم مشخص خواهد شد که دقیقاً در مورد چه چیزی صحبت می کنیم.

جدول مجموعه ای از ستون ها است. ستون ها را می توان فیلد یا ستون نیز نامید؛ همه این کلمات به عنوان مترادف هایی استفاده می شوند که یک چیز را بیان می کنند.

جدول شیء اصلی RDB است؛ تمام داده های RDB سطر به سطر در ستون های جدول ذخیره می شوند. خطوط و رکوردها نیز مترادف هستند.

برای هر جدول و همچنین ستون‌های آن، نام‌هایی مشخص می‌شود که بعداً به آنها دسترسی پیدا می‌کنند.
نام شی (نام جدول، نام ستون، نام فهرست و غیره) در MS SQL می تواند حداکثر 128 کاراکتر داشته باشد.

برای مرجع- در پایگاه داده ORACLE، نام اشیاء می تواند حداکثر 30 کاراکتر داشته باشد. بنابراین، برای یک پایگاه داده خاص، باید قوانین خود را برای نامگذاری اشیا ایجاد کنید تا محدودیت تعداد کاراکترها را رعایت کنید.

SQL زبانی است که به شما امکان می دهد با استفاده از DBMS از پایگاه داده پرس و جو کنید. در یک DBMS خاص، زبان SQL ممکن است پیاده سازی خاصی (گویش خود) داشته باشد.

DDL و DML زیر مجموعه ای از زبان SQL هستند:

• زبان DDL برای ایجاد و اصلاح ساختار پایگاه داده استفاده می شود. برای ایجاد/تغییر/حذف جداول و روابط.
• زبان DML به شما اجازه می دهد تا داده های جدول را دستکاری کنید. با خطوط او به شما امکان می دهد داده ها را از جداول انتخاب کنید، داده های جدید را به جداول اضافه کنید و همچنین داده های موجود را به روز رسانی و حذف کنید.

در SQL می توانید از 2 نوع کامنت (تک خطی و چند خطی) استفاده کنید:

نظر یک خطی
و

/* نظر چند خطی */

در واقع، این برای تئوری کافی خواهد بود.

DDL - زبان تعریف داده

به عنوان مثال، جدولی را با داده های مربوط به کارمندان، به شکلی که برای شخصی که برنامه نویس نیست، در نظر بگیرید:

در این مورد، ستون های جدول دارای نام های زیر هستند: شماره پرسنل، نام کامل، تاریخ تولد، پست الکترونیکی، سمت، بخش.

هر یک از این ستون ها را می توان با نوع داده ای که در آن قرار دارد مشخص کرد:

• شماره پرسنل - عدد صحیح
• نام کامل - رشته
• تاریخ تولد - تاریخ
• ایمیل – رشته
• موقعیت - رشته
• بخش - خط

نوع ستون مشخصه ای است که نشان می دهد یک ستون معین چه نوع داده ای را می تواند ذخیره کند.

برای شروع، کافی است فقط انواع داده های اساسی زیر را که در MS SQL استفاده می شود، به خاطر بسپارید:

معنی	علامت گذاری در MS SQL	شرح
رشته با طول متغیر	varchar (N) و nvarchar (N)	با استفاده از عدد N می توانیم حداکثر طول رشته ممکن را برای ستون مربوطه مشخص کنیم. به عنوان مثال، اگر بخواهیم بگوییم که مقدار ستون "Name" می تواند حداکثر 30 کاراکتر داشته باشد، باید نوع آن را روی nvarchar(30) قرار دهیم. تفاوت بین varchar و nvarchar در این است که varchar به شما امکان می دهد رشته ها را با فرمت ASCII ذخیره کنید، جایی که یک کاراکتر 1 بایت را اشغال می کند، و nvarchar رشته ها را در قالب Unicode ذخیره می کند، جایی که هر کاراکتر 2 بایت را اشغال می کند. نوع varchar فقط در صورتی باید استفاده شود که 100% مطمئن باشید که این فیلد نیازی به ذخیره کاراکترهای یونیکد ندارد. به عنوان مثال، varchar را می توان برای ذخیره آدرس های ایمیل استفاده کرد زیرا ... آنها معمولاً فقط شامل کاراکترهای ASCII هستند.
رشته طول ثابت	کاراکتر (N) و nchar (N)	این نوع با یک رشته با طول متغیر متفاوت است زیرا اگر طول رشته کمتر از N کاراکتر باشد، همیشه در سمت راست به طول N با فاصله اضافه می شود و به این شکل در پایگاه داده ذخیره می شود. در پایگاه داده دقیقاً N کاراکتر می گیرد (که در آن یک کاراکتر 1 بایت برای char و 2 بایت برای nchar می گیرد). در عمل من، این نوع بسیار به ندرت استفاده می شود و در صورت استفاده، عمدتاً در قالب char(1) استفاده می شود، i.e. وقتی یک فیلد با یک کاراکتر تعریف می شود.
عدد صحیح	بین المللی	این نوع به ما اجازه می دهد که فقط از اعداد صحیح در ستون، مثبت و منفی استفاده کنیم. برای مرجع (اکنون این برای ما چندان مرتبط نیست)، محدوده اعدادی که نوع int اجازه می دهد از -2,147,483,648 تا 2,147,483,647 است. معمولاً این نوع اصلی است که برای تعیین شناسه ها استفاده می شود.
عدد واقعی یا واقعی	شناور	به زبان ساده، اینها اعدادی هستند که ممکن است دارای یک نقطه اعشار (کاما) باشند.
تاریخ	تاریخ	اگر ستون فقط باید تاریخ را ذخیره کند که از سه جزء تشکیل شده است: روز، ماه و سال. به عنوان مثال، 02/15/2014 (15 فوریه 2014). این نوع را می توان برای ستون "تاریخ پذیرش"، "تاریخ تولد" و غیره استفاده کرد، یعنی. در مواردی که برای ما مهم است که فقط تاریخ را ثبت کنیم، یا زمانی که جزء زمان برای ما مهم نیست و می توان آن را دور انداخت یا اگر مشخص نیست.
زمان	زمان	این نوع می تواند مورد استفاده قرار گیرد اگر ستون نیاز به ذخیره فقط داده های زمانی دارد، یعنی. ساعت، دقیقه، ثانیه و میلی ثانیه. به عنوان مثال، 17:38:31.3231603 به عنوان مثال، روزانه "زمان حرکت پرواز".
تاریخ و زمان	زمان قرار	این نوع به شما امکان می دهد همزمان تاریخ و زمان را ذخیره کنید. به عنوان مثال، 02/15/2014 17:38:31.323 به عنوان مثال، این می تواند تاریخ و زمان یک رویداد باشد.
پرچم	بیت	استفاده از این نوع برای ذخیره مقادیر به شکل "بله"/"خیر"، که در آن "بله" به عنوان 1 و "نه" به عنوان 0 ذخیره می شود، راحت است.

همچنین مقدار فیلد در صورت ممنوع نبودن ممکن است مشخص نشود؛ برای این منظور از کلمه کلیدی NULL استفاده می شود.

برای اجرای مثال ها، بیایید یک پایگاه داده آزمایشی به نام Test ایجاد کنیم.

با اجرای دستور زیر می توان یک پایگاه داده ساده (بدون تعیین پارامترهای اضافی) ایجاد کرد:

تست ایجاد پایگاه داده
می توانید پایگاه داده را با دستور حذف کنید (باید بسیار مراقب این دستور باشید):

تست DROP DATABASE
برای جابجایی به پایگاه داده ما، می توانید دستور زیر را اجرا کنید:

تست استفاده
همچنین، پایگاه داده تست را از لیست کشویی در ناحیه منوی SSMS انتخاب کنید. هنگام کار، من اغلب از این روش برای جابجایی بین پایگاه های داده استفاده می کنم.

اکنون در پایگاه داده خود می توانیم با استفاده از توضیحات همانطور که هستند، با استفاده از فاصله ها و کاراکترهای سیریلیک جدولی ایجاد کنیم:

ایجاد جدول [کارمندان]([شماره پرسنل] int، [نام] nvarchar(30)، [تاریخ تولد] تاریخ، nvarchar(30)، [مقام] nvarchar(30)، [بخش] nvarchar(30))
در این صورت، ما باید نام ها را در پرانتز قرار دهیم […].

اما در پایگاه داده برای راحتی بیشتر، بهتر است نام همه اشیا به لاتین مشخص شود و از فاصله در نام ها استفاده نشود. در MS SQL، معمولاً در این مورد، هر کلمه با یک حرف بزرگ شروع می شود، به عنوان مثال، برای قسمت "Personnel Number" می توانیم نام PersonnelNumber را تعیین کنیم. همچنین می توانید از اعداد در نام استفاده کنید، به عنوان مثال PhoneNumber1.

در یک یادداشت
در برخی از DBMS ها، قالب نامگذاری زیر "PHONE_NUMBER" ممکن است ارجح تر باشد؛ برای مثال، این قالب اغلب در پایگاه داده ORACLE استفاده می شود. طبیعتاً هنگام تعیین نام فیلد، مطلوب است که با کلمات کلیدی استفاده شده در DBMS منطبق نباشد.

به همین دلیل، می‌توانید نحو کروشه‌ها را فراموش کنید و جدول [Employees] را حذف کنید:

جدول رها کردن [کارمندان]
به عنوان مثال، جدولی با کارمندان را می توان "کارمندان" نامید و فیلدهای آن را می توان نام های زیر نامید:

• شناسه – شماره پرسنل (شناسه کارمند)
• نام - نام کامل
• تولد - تاریخ تولد
• ایمیل – ایمیل
• مقام - مقام
• بخش - بخش

اغلب از کلمه ID برای نامگذاری یک فیلد شناسه استفاده می شود.

حالا بیایید جدول خود را بسازیم:

ایجاد جدول کارکنان (ID int، نام nvarchar(30)، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30))
برای تعیین ستون های مورد نیاز می توانید از گزینه NOT NULL استفاده کنید.

برای یک جدول موجود، فیلدها را می توان با استفاده از دستورات زیر دوباره تعریف کرد:

فیلد ID به روز رسانی ALTER TABLE Employees ALTER COLUMN ID int NOT NULL -- به روز رسانی فیلد نام ALTER TABLE Employees ALTER COLUMN نام nvarchar(30) NOT NULL

در یک یادداشت
مفهوم کلی زبان SQL برای اکثر DBMS ها یکسان است (حداقل، این چیزی است که من می توانم از روی DBMS هایی که با آنها کار کرده ام قضاوت کنم). تفاوت‌های بین DDL در DBMS‌های مختلف عمدتاً در انواع داده‌ها نهفته است (نه تنها نام آنها ممکن است در اینجا متفاوت باشد، بلکه جزئیات پیاده‌سازی آنها نیز ممکن است متفاوت باشد)، و مشخصات اجرای زبان SQL نیز ممکن است کمی متفاوت باشد (یعنی ماهیت دستورات یکسان است، اما ممکن است تفاوت های جزئی در گویش وجود داشته باشد، افسوس، اما هیچ استانداردی وجود ندارد). با تسلط بر اصول اولیه SQL، می توانید به راحتی از یک DBMS به دیگری سوئیچ کنید، زیرا ... در این مورد، شما فقط باید جزئیات اجرای دستورات در DBMS جدید را درک کنید. در بیشتر موارد، صرف یک قیاس کافی است.

ایجاد جدول CREATE TABLE Employees(ID int, -- در ORACLE نوع int معادل (wrapper) برای عدد(38) است نام nvarchar2(30), -- nvarchar2 در ORACLE معادل nvarchar در MS SQL تاریخ تولد، ایمیل nvarchar2(30) , Position nvarchar2(30), Department nvarchar2(30)); - به روز رسانی فیلدهای ID و Name (در اینجا MODIFY(...) به جای ALTER COLUMN استفاده می شود) ALTER TABLE Employees MODIFY(ID int NOT NULL,Name nvarchar2(30) NOT NULL); -- اضافه کردن PK (در این مورد ساختار مشابه در MS SQL به نظر می رسد، در زیر نشان داده خواهد شد) ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY(ID);
برای ORACLE از نظر اجرای نوع varchar2 تفاوت هایی وجود دارد؛ رمزگذاری آن به تنظیمات پایگاه داده بستگی دارد و متن را می توان به عنوان مثال در رمزگذاری UTF-8 ذخیره کرد. علاوه بر این، طول فیلد در ORACLE را می توان هم به بایت و هم به صورت کاراکتر مشخص کرد؛ برای این کار از گزینه های اضافی BYTE و CHAR استفاده می شود که بعد از طول فیلد مشخص می شوند، به عنوان مثال:

NAME varchar2 (30 BYTE) -- ظرفیت فیلد 30 بایت خواهد بود NAME varchar2 (30 CHAR) -- ظرفیت فیلد 30 کاراکتر خواهد بود
اینکه کدام گزینه به صورت پیش‌فرض BYTE یا CHAR استفاده می‌شود، در مورد مشخص کردن نوع varchar2(30) در ORACLE، بستگی به تنظیمات پایگاه داده دارد و گاهی اوقات می‌توان آن را در تنظیمات IDE تنظیم کرد. به طور کلی، گاهی اوقات می توانید به راحتی گیج شوید، بنابراین در مورد ORACLE، اگر از نوع varchar2 استفاده می شود (و گاهی اوقات در اینجا توجیه می شود، به عنوان مثال، هنگام استفاده از رمزگذاری UTF-8)، ترجیح می دهم به صراحت CHAR را بنویسم (از آنجا که معمولاً محاسبه طول رشته به کاراکتر راحت‌تر است.

اما در این حالت، اگر قبلاً مقداری داده در جدول وجود داشته باشد، برای اجرای موفقیت آمیز دستورات لازم است که فیلدهای ID و Name در تمام ردیف های جدول پر شود. بیایید این را با یک مثال نشان دهیم: داده ها را در جدول در فیلدهای ID، Position و Department وارد کنید؛ این را می توان با اسکریپت زیر انجام داد:

درج کارکنان (شناسه، موقعیت، بخش) VALUES (1000، N"مدیر"، N"Administration")، (1001، N"برنامه نویس، N"IT")، (1002، N"حسابدار، N"حسابداری" )، (1003،N"برنامه نویس ارشد"،N"IT")
در این صورت دستور INSERT نیز خطا ایجاد می کند، زیرا هنگام درج، مقدار فیلد نام مورد نیاز را مشخص نکردیم.
اگر قبلاً این داده ها را در جدول اصلی داشتیم، دستور "ALTER TABLE Employees ALTER COLUMN ID int NOT NULL" با موفقیت اجرا می شد و دستور "ALTER TABLE Employees ALTER COLUMN Name int NOT NULL" یک پیام خطا ایجاد می کرد. که فیلد Name حاوی مقادیر NULL (نامشخص) است.

بیایید مقادیری را برای فیلد Name اضافه کنیم و دوباره داده ها را پر کنیم:

گزینه NOT NULL همچنین می تواند به طور مستقیم هنگام ایجاد یک جدول جدید استفاده شود. در زمینه دستور CREATE TABLE.

ابتدا جدول را با استفاده از دستور حذف کنید:

DROP TABLE کارمندان
حالا بیایید یک جدول با ستون های ID و Name مورد نیاز ایجاد کنیم:

ایجاد جدول کارکنان (ID int NOT NULL، نام nvarchar(30) NOT NULL، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30))
همچنین می توانید NULL را بعد از نام ستون بنویسید، به این معنی که مقادیر NULL (مشخص نشده) در آن مجاز است، اما این ضروری نیست، زیرا این ویژگی به طور پیش فرض دلالت دارد.

اگر برعکس، می‌خواهید یک ستون موجود را اختیاری کنید، از دستور دستور زیر استفاده کنید:

ALTER TABLE کارکنان ALTER COLUMN نام nvarchar(30) NULL
یا به سادگی:

ALTER TABLE Employees ALTER COLUMN نام nvarchar(30)
با این دستور می توانیم نوع فیلد را به نوع سازگار دیگری تغییر دهیم یا طول آن را تغییر دهیم. به عنوان مثال، اجازه دهید فیلد Name را به 50 کاراکتر گسترش دهیم:

ALTER TABLE Employees ALTER COLUMN نام nvarchar(50)

کلید اصلی

هنگام ایجاد یک جدول، مطلوب است که یک ستون منحصر به فرد یا مجموعه ای از ستون ها داشته باشد که برای هر یک از ردیف های آن منحصر به فرد است - یک رکورد را می توان به طور منحصر به فرد با این مقدار منحصر به فرد شناسایی کرد. این مقدار کلید اصلی جدول نامیده می شود. برای جدول کارکنان ما، چنین مقدار منحصر به فردی می تواند ستون ID باشد (که حاوی "شماره پرسنل کارمند" است - حتی اگر در مورد ما این مقدار برای هر کارمند منحصر به فرد است و قابل تکرار نیست).

می توانید با استفاده از دستور زیر یک کلید اصلی برای جدول موجود ایجاد کنید:

ALTER TABLE کارمندان ADD CONSTRAINT PK_Employees PRIMARY KEY(ID)
جایی که "PK_Employees" نام محدودیت مسئول کلید اصلی است. به طور معمول، کلید اصلی با استفاده از پیشوند "PK_" به دنبال نام جدول نامگذاری می شود.

اگر کلید اصلی از چندین فیلد تشکیل شده باشد، این فیلدها باید در داخل پرانتز فهرست شوند و با کاما از هم جدا شوند:

TABLE تغییر نام جدول_افزودن محدودیت_نام کلید اولیه (فیلد1، فیلد2،…)
شایان ذکر است که در MS SQL تمام فیلدهایی که در کلید اصلی قرار می گیرند باید دارای مشخصه NOT NULL باشند.

کلید اصلی همچنین می تواند به طور مستقیم هنگام ایجاد جدول تعیین شود، یعنی. در زمینه دستور CREATE TABLE. بیایید جدول را حذف کنیم:

DROP TABLE کارمندان
و سپس با استفاده از نحو زیر آن را ایجاد می کنیم:

ایجاد جدول کارمندان (ID int NOT NULL، نام nvarchar(30) NOT NULL، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30)، محدودیت PK_Employees PRIMARY KEY(PK پس از) -- توصیف تمام فیلدها به عنوان محدودیت)
پس از ایجاد، جدول را با داده ها پر کنید:

درج کارمندان (شناسه، موقعیت، بخش، نام) VALUES (1000، N"مدیر، N"Administration، N"Ivanov I.I.")، (1001، N"برنامه نویس، N"IT، N" Petrov P.P." )، (1002،N"حسابدار"،N"حسابداری،N"Sidorov S.S.")، (1003،N"برنامه نویس ارشد"،N"IT،N"Andreev A. A.")
اگر کلید اصلی در جدول فقط از مقادیر یک ستون تشکیل شده باشد، می توانید از نحو زیر استفاده کنید:

CREATE TABLE Employees(ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY، -- به عنوان مشخصه فیلد مشخص کنید نام nvarchar(30) NOT NULL، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30) )
در واقع، لازم نیست نام محدودیت را مشخص کنید، در این صورت یک نام سیستم به آن اختصاص داده می شود (مانند "PK__Employee__3214EC278DA42077"):

ایجاد جدول کارکنان (ID int NOT NULL، نام nvarchar(30) NOT NULL، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30)، کلید اصلی (ID))
یا:

ایجاد جدول کارکنان (ID int NOT NULL PRIMARY KEY، نام nvarchar(30) NOT NULL، تاریخ تولد، ایمیل nvarchar(30)، موقعیت nvarchar(30)، بخش nvarchar(30))
اما من توصیه می کنم که برای جداول دائمی همیشه نام محدودیت را به صراحت تنظیم کنید، زیرا با یک نام مشخص و قابل فهم، بعداً دستکاری آن آسان تر خواهد بود؛ به عنوان مثال، می توانید آن را حذف کنید:

ALTER TABLE کارمندان محدودیت را کنار می گذارند PK_Employees
اما چنین نحو کوتاهی، بدون تعیین نام محدودیت ها، هنگام ایجاد جداول پایگاه داده موقت (نام جدول موقت با # یا ## شروع می شود) راحت است که پس از استفاده حذف می شود.

بیایید خلاصه کنیم

تا اینجا دستورات زیر را بررسی کردیم:

• ایجاد جدول table_name (فهرست فیلدها و انواع آنها، محدودیت ها) - برای ایجاد یک جدول جدید در پایگاه داده فعلی استفاده می شود.
• میز رها کردن table_name – برای حذف جدول از پایگاه داده فعلی استفاده می شود.
• جدول تغییراتجدول_نام ستون جایگزینستون_نام... – برای به روز رسانی نوع ستون یا تغییر تنظیمات آن (مثلاً برای تنظیم مشخصه NULL یا NOT NULL) استفاده می شود.
• جدول تغییراتجدول_نام محدودیت را اضافه کنید constraint_name کلید اولیه(فیلد1، فیلد2،...) – افزودن کلید اصلی به جدول موجود.
• جدول تغییراتجدول_نام محدودیت افت constraint_name - یک محدودیت را از جدول حذف می کند.

کمی در مورد میزهای موقت

استخراج از MSDN.دو نوع جدول موقت در MS SQL Server وجود دارد: محلی (#) و جهانی (##). جداول موقت محلی فقط برای سازندگان آنها قابل مشاهده است تا زمانی که جلسه اتصال به نمونه SQL Server در اولین ایجاد آنها به پایان برسد. جداول موقت محلی پس از قطع ارتباط کاربر از نمونه SQL Server به طور خودکار حذف می شوند. جداول موقت سراسری در طول هر جلسه اتصال پس از ایجاد آن جداول برای همه کاربران قابل مشاهده است و زمانی که همه کاربرانی که به آن جداول ارجاع می دهند از نمونه SQL Server جدا می شوند حذف می شوند.

جداول موقت در پایگاه داده سیستم tempdb ایجاد می شوند، یعنی. با ایجاد آنها، پایگاه داده اصلی را مسدود نمی کنیم، در غیر این صورت، جداول موقت کاملاً مشابه جداول معمولی هستند؛ همچنین می توان آنها را با استفاده از دستور DROP TABLE حذف کرد. جداول موقت محلی (#) بیشتر مورد استفاده قرار می گیرند.

برای ایجاد یک جدول موقت، می توانید از دستور CREATE TABLE استفاده کنید:

CREATE TABLE #Temp(ID int, Name nvarchar(30))
از آنجایی که یک جدول موقت در MS SQL شبیه یک جدول معمولی است، می توان آن را با استفاده از دستور DROP TABLE نیز حذف کرد:

میز رها کردن #دمای

همچنین می توانید یک جدول موقت (مانند یک جدول معمولی) ایجاد کنید و بلافاصله با استفاده از دستور SELECT ... INTO آن را با داده های بازگردانده شده توسط پرس و جو پر کنید:

شناسه، نام به #Temp از کارکنان را انتخاب کنید

در یک یادداشت
پیاده سازی جداول موقت ممکن است در DBMS های مختلف متفاوت باشد. به عنوان مثال، در DBMS ORACLE و Firebird، ساختار جداول موقت باید از قبل با دستور CREATE GLOBAL TEMPORARY TABLE مشخص شود و مشخصات ذخیره سازی داده ها در آن مشخص شود، سپس کاربر آن را در بین جداول اصلی ببیند و با آن کار کند. مانند یک میز معمولی

عادی سازی پایگاه داده - تقسیم به جدول های فرعی (دایرکتوری ها) و شناسایی اتصالات

جدول کارمندان فعلی ما این عیب را دارد که در قسمت‌های موقعیت و بخش، کاربر می‌تواند هر متنی را وارد کند، که در درجه اول مملو از خطا است، زیرا برای یک کارمند او می‌تواند به سادگی «IT» را به عنوان بخش و برای کارمند دوم، برای به عنوان مثال، "بخش IT" را وارد کنید، سومی "IT" دارد. در نتیجه مشخص نخواهد شد که منظور کاربر چه بوده است. آیا این کارمندان کارمندان یک بخش هستند یا کاربر خودش را توصیف کرده است و اینها 3 بخش مختلف هستند؟ علاوه بر این، در این مورد، ما نمی‌توانیم داده‌ها را برای برخی گزارش‌ها به درستی گروه‌بندی کنیم، جایی که ممکن است لازم باشد تعداد کارکنان هر بخش نشان داده شود.

دومین عیب حجم ذخیره سازی این اطلاعات و تکراری بودن آن است. برای هر کارمند، نام کامل بخش مشخص شده است، که برای ذخیره هر کاراکتر از نام بخش، فضایی در پایگاه داده نیاز دارد.

اشکال سوم مشکل به روز رسانی این فیلدها در صورت تغییر نام موقعیت است، به عنوان مثال، اگر شما نیاز به تغییر نام موقعیت "برنامه نویس" به "برنامه نویس جوان" دارید. در این صورت باید در هر ردیف از جدول که موقعیت آن برابر با "برنامه نویس" است تغییراتی ایجاد کنیم.

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

بیایید 2 جداول دایرکتوری "Positions" و "Departments" ایجاد کنیم، بیایید موقعیت های اول و دومی را به ترتیب بخش ها صدا کنیم:

CREATE TABLE Positions(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Positions PRIMARY KEY, Name nvarchar(30) NOT NULL) CREATE TABLE Departments(ID int IDENTITY(1,1) NOT NULL CONSTRAINT Name ) تهی نیست)
توجه داشته باشید که در اینجا ما از گزینه جدید IDENTITY استفاده کردیم که می گوید داده های ستون ID به طور خودکار شماره گذاری می شوند و از 1 شروع می شوند و با افزایش 1، یعنی. هنگام افزودن رکوردهای جدید، به ترتیب مقادیر 1، 2، 3 و غیره به آنها اختصاص داده می شود. چنین فیلدهایی معمولاً افزایش خودکار نامیده می شوند. یک جدول فقط می تواند یک فیلد تعریف شده با ویژگی IDENTITY داشته باشد و معمولا، اما نه لزوما، آن فیلد کلید اصلی آن جدول است.

در یک یادداشت
در DBMS های مختلف، پیاده سازی فیلدها با شمارنده می تواند متفاوت انجام شود. برای مثال در MySQL چنین فیلدی با استفاده از گزینه AUTO_INCREMENT تعریف می شود. در ORACLE و Firebird، این قابلیت قبلاً با استفاده از SEQUENCE قابل تقلید بود. اما تا آنجا که من می دانم، ORACLE اکنون گزینه GENERATED AS IDENTITY را اضافه کرده است.

بیایید این جداول را به طور خودکار پر کنیم، بر اساس داده های فعلی ثبت شده در فیلدهای موقعیت و بخش جدول کارکنان:

فیلد نام جدول موقعیت‌ها را با مقادیر منحصربه‌فرد از فیلد موقعیت جدول کارکنان پر می‌کنیم. INSERT Positions(Name) SELECT DISTINCT Position FROM Employees WHERE Position IS NULL - سوابق را که موقعیت برای آنها مشخص نشده است کنار بگذارید.
بیایید همین کار را برای جدول بخش ها انجام دهیم:

درج بخش ها (نام) بخش متمایز را از کارمندان انتخاب کنید در جایی که بخش تهی نیست
اگر اکنون جداول Positions و Departments را باز کنیم، مجموعه ای از مقادیر شماره گذاری شده برای فیلد ID را خواهیم دید:

انتخاب * از موقعیت ها

انتخاب * از بخش ها

این جداول اکنون نقش کتاب های مرجع برای تعیین سمت ها و دپارتمان ها را ایفا خواهند کرد. اکنون به شناسه های شغلی و دپارتمان ها اشاره می کنیم. اول از همه، بیایید فیلدهای جدیدی در جدول Employees ایجاد کنیم تا داده های شناسه را ذخیره کنیم:

افزودن فیلد برای شناسه موقعیت ALTER TABLE Employees ADD PositionID int -- افزودن فیلد برای شناسه بخش ALTER TABLE Employees ADD DepartmentID int
نوع فیلدهای مرجع باید مانند دایرکتوری ها باشد، در این مورد int است.

همچنین می توانید چندین فیلد را به طور همزمان با یک دستور به جدول اضافه کنید و فیلدهای جدا شده با کاما را فهرست کنید:

ALTER TABLE Employees ADD PositionID int، DepartmentID int
حالا بیایید برای این فیلدها لینک (محدودیت های مرجع - FOREIGN KEY) بنویسیم تا کاربر فرصتی برای نوشتن در این فیلدها نداشته باشد که در بین مقادیر ID موجود در دایرکتوری ها نیستند.

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID)
و ما همین کار را برای فیلد دوم انجام خواهیم داد:

ALTER TABLE کارمندان اضافه کردن محدودیت FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) مراجع بخش ها(ID)
اکنون کاربر قادر خواهد بود فقط مقادیر ID را از دایرکتوری مربوطه در این فیلدها وارد کند. بر این اساس، برای استفاده از یک بخش یا موقعیت جدید، ابتدا باید یک ورودی جدید به فهرست مربوطه اضافه کند. زیرا موقعیت ها و بخش ها اکنون در دایرکتوری ها در یک نسخه ذخیره می شوند، بنابراین برای تغییر نام، کافی است آن را فقط در دایرکتوری تغییر دهید.

نام یک محدودیت مرجع معمولاً یک نام ترکیبی است که از پیشوند "FK_" و به دنبال آن نام جدول و به دنبال آن یک خط زیر و به دنبال آن نام فیلدی که به شناسه جدول مرجع اشاره دارد، می باشد.

شناسه (ID) معمولاً یک مقدار داخلی است که فقط برای روابط استفاده می شود و مقداری که در آنجا ذخیره می شود در بیشتر موارد کاملاً بی تفاوت است، بنابراین نیازی به تلاش برای خلاص شدن از سوراخ های دنباله اعدادی نیست که هنگام کار ایجاد می شود. با جدول، به عنوان مثال، پس از حذف رکوردها از فهرست.

جدول تغییر جدول افزودن محدودیت محدودیت_نام کلید خارجی (فیلد1، فیلد2،…) منابع مرجع_جدول (فیلد1، فیلد2،…)
در این حالت، در جدول “reference_table”، کلید اولیه با ترکیبی از چندین فیلد (field1, field2,...) نمایش داده می شود.

در واقع، اکنون اجازه دهید فیلدهای PositionID و DepartmentID را با مقادیر ID از دایرکتوری ها به روز کنیم. بیایید از دستور DML UPDATE برای این منظور استفاده کنیم:

UPDATE e SET PositionID=(SELECT ID FROM Positions WHERE Name=e.Position), DepartmentID=(SELECT ID FROM Departments WHERE Name=e.Department) FROM Employees e
بیایید ببینیم با اجرای درخواست چه اتفاقی می افتد:

انتخاب * از کارکنان

تمام است، فیلدهای PositionID و DepartmentID با شناسه‌های مربوط به موقعیت‌ها و بخش‌ها پر می‌شوند؛ فیلدهای Position و Department دیگر در جدول Employees مورد نیاز نیستند، می‌توانید این فیلدها را حذف کنید:

جدول تغییر کارکنان پست ستون، بخش
حالا جدول ما به شکل زیر است:

انتخاب * از کارکنان

شناسه	نام	روز تولد	پست الکترونیک	شناسه موقعیت	شناسه بخش
1000	ایوانف I.I.	خالی	خالی	2	1
1001	پتروف P.P.	خالی	خالی	3	3
1002	سیدوروف S.S.	خالی	خالی	1	2
1003	آندریف A.A.	خالی	خالی	4	3

آن ها ما در نهایت از ذخیره اطلاعات اضافی خلاص شدیم. اکنون، بر اساس شماره شغل و بخش، می توانیم نام آنها را با استفاده از مقادیر موجود در جداول مرجع به طور واضح تعیین کنیم:

SELECT e.ID,e.Name,p.Name PositionName,d.Name DepartmentName FROM Employees e LEFT JOIN بخش ها d ON d.ID=e.DepartmentID LEFT JOIN Positions p ON p.ID=e.PositionID

در بازرس آبجکت ما می توانیم تمام اشیاء ایجاد شده برای یک جدول داده شده را ببینیم. از اینجا می توانید دستکاری های مختلفی را با این اشیاء انجام دهید - به عنوان مثال، نام اشیاء را تغییر دهید یا حذف کنید.

همچنین شایان ذکر است که جدول می تواند به خود اشاره کند، یعنی. می توانید یک لینک بازگشتی ایجاد کنید. به عنوان مثال، بیایید یک فیلد ManagerID دیگر را به جدول خود با کارمندان اضافه کنیم، که نشان می دهد کارمندی که این کارمند به او گزارش می دهد. بیایید یک فیلد ایجاد کنیم:

ALTER TABLE Employees ADD ManagerID int
این فیلد یک مقدار NULL را مجاز می‌کند؛ اگر مثلاً هیچ برتری نسبت به کارمند وجود نداشته باشد، فیلد خالی خواهد بود.

حالا بیایید یک کلید خارجی برای جدول کارکنان ایجاد کنیم:

ALTER TABLE Employees ADD CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERENCES Employees(ID)
بیایید اکنون یک نمودار ایجاد کنیم و ببینیم که چگونه روابط بین جداول ما در آن به نظر می رسد:

در نتیجه باید تصویر زیر را ببینیم (جدول Employees به جداول Positions و Depertments متصل است و به خودش نیز اشاره دارد):

در نهایت، شایان ذکر است که کلیدهای مرجع می‌توانند شامل گزینه‌های اضافی ON DELETE CASCADE و ON UPDATE CASCADE باشند، که نشان می‌دهد هنگام حذف یا به‌روزرسانی رکوردی که در جدول مرجع به آن اشاره شده است، چگونه رفتار کنید. اگر این گزینه‌ها مشخص نشده باشند، نمی‌توانیم شناسه را در جدول دایرکتوری برای رکوردی که از جدول دیگری ارجاع داده شده است تغییر دهیم و همچنین نمی‌توانیم چنین رکوردی را تا زمانی که همه ردیف‌هایی را که به این رکورد ارجاع می‌دهند حذف کنیم، از فهرست حذف کنیم. یا، بیایید مراجع در این خطوط را به مقدار دیگری به روز کنیم.

به عنوان مثال، بیایید جدولی را دوباره ایجاد کنیم که گزینه ON DELETE CASCADE را برای FK_Employees_DepartmentID مشخص می کند:

DROP TABLE Employees CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), تاریخ تولد, Email nvarchar(30), PositionID int, DepartmentID int, ManagerID int, CONSTRAINT PK_Employees KRIMARY KEY (IDK_Employees KEY PRIMARY F, CONSTRAYDEEmploymentepart) ) REFERENCES بخش ها (ID) ON DELETE CASCADE, CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERENCES Positions(ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) EmployeINSEIDREGIN روز، شناسه موقعیت، شناسه بخش، شناسه مدیر )VALUES (1000،N"Ivanov I.I."،"19550219"،"2،1،"NULL)، (1001، "N"Petrov P.P."،"19831203،"3،3،1003)، (1002، N"Sidorov S.S." "19760607"، 1،2،1000)، (1003، N"Andreev A.A."،"19820417،4،3،1000)
بیایید بخش با شناسه 3 را از جدول بخش ها حذف کنیم:

بخش‌هایی که ID=3 هستند را حذف کنید
بیایید به داده های جدول کارمندان نگاه کنیم:

انتخاب * از کارکنان

شناسه	نام	روز تولد	پست الکترونیک	شناسه موقعیت	شناسه بخش	شناسه مدیر
1000	ایوانف I.I.	1955-02-19	خالی	2	1	خالی
1002	سیدوروف S.S.	1976-06-07	خالی	1	2	1000

همانطور که می بینید، داده های بخش 3 از جدول Employees نیز حذف شد.

گزینه ON UPDATE CASCADE به همین صورت عمل می کند، اما هنگام به روز رسانی مقدار ID در دایرکتوری موثر است. به عنوان مثال، اگر شناسه یک موقعیت را در دایرکتوری موقعیت تغییر دهیم، در این صورت شناسه Department در جدول Employees به مقدار ID جدیدی که در فهرست تعیین کرده ایم به روز می شود. اما در این مورد به سادگی امکان نشان دادن این وجود نخواهد داشت، زیرا ستون ID در جدول Departments دارای گزینه IDENTITY است که به ما اجازه نمی دهد پرس و جوی زیر را اجرا کنیم (تغییر شناسه بخش 3 به 30):

به روز رسانی بخش ها SET ID=30 WHERE ID=3
نکته اصلی درک ماهیت این 2 گزینه ON DELETE CASCADE و ON UPDATE CASCADE است. من از این گزینه‌ها به ندرت استفاده می‌کنم و توصیه می‌کنم قبل از تعیین آن‌ها در یک محدودیت مرجع، با دقت فکر کنید، زیرا اگر به طور تصادفی یک ورودی را از یک جدول دایرکتوری حذف کنید، این می تواند به مشکلات بزرگی منجر شود و یک واکنش زنجیره ای ایجاد کند.

بیایید بخش 3 را بازیابی کنیم:

ما اجازه افزودن/تغییر مقدار IDENTITY SET IDENTITY_INSERT بخش ها ON INSERT بخش ها(ID,Name) VALUES(3,N"IT") را می دهیم -- ما افزودن/تغییر مقدار IDENTITY SET IDENTITY_INSERT بخش ها OFF را ممنوع می کنیم
بیایید جدول Employees را با استفاده از دستور TRUNCATE TABLE کاملاً پاک کنیم:

TRUNCATE TABLE کارکنان
و دوباره با استفاده از دستور INSERT قبلی، داده ها را در آن بارگذاری می کنیم:

کارمندان (ID, Name, Birthday, PositionID, DepartmentID, ManagerID) VALUES (1000,N"Ivanov I.I.",19550219,2,1,NULL), (1001,N"Petrov P.P." "19831203" ,3,1003), (1002,N"Sidorov S.S.",19760607,1,2,1000), (1003,N"Andreev A.A.","19820417" ,4,3,1000)

بیایید خلاصه کنیم

در حال حاضر، چندین دستور DDL دیگر به دانش ما اضافه شده است:

• افزودن ویژگی IDENTITY به یک فیلد – به شما این امکان را می دهد که این فیلد را به صورت یک فیلد پر شده خودکار (فیلد شمارنده) برای جدول تبدیل کنید.
• جدول تغییراتجدول_نام اضافه کردن list_of_fields_with_characteristics – به شما امکان می دهد فیلدهای جدیدی را به جدول اضافه کنید.
• جدول تغییراتجدول_نام رها کردن ستون list_fields - به شما امکان می دهد فیلدها را از جدول حذف کنید.
• جدول تغییراتجدول_نام محدودیت را اضافه کنید constraint_name کلید خارجی(زمینه های) منابع table_reference (فیلدها) - به شما امکان می دهد رابطه بین جدول و جدول مرجع را تعریف کنید.

سایر محدودیت ها - منحصر به فرد، پیش فرض، بررسی

با استفاده از یک محدودیت UNIQUE، می توانید بگویید که مقدار هر ردیف در یک فیلد معین یا مجموعه ای از فیلدها باید منحصر به فرد باشد. در مورد جدول Employees، می توانیم چنین محدودیتی را در قسمت Email اعمال کنیم. فقط ایمیل را از قبل با مقادیری که قبلاً تعریف نشده اند پر کنید:

UPDATE Employees SET Email=" [ایمیل محافظت شده]" WHERE ID=1000 UPDATE Employees SET Email=" [ایمیل محافظت شده]" WHERE ID=1001 UPDATE Employees SET Email=" [ایمیل محافظت شده]" WHERE ID=1002 UPDATE Employees SET Email=" [ایمیل محافظت شده] WHERE ID=1003
اکنون می توانید یک محدودیت منحصر به فرد را در این زمینه اعمال کنید:

ALTER TABLE کارکنان اضافه کردن محدودیت UQ_Employees_Email UNIQUE(ایمیل)
اکنون کاربر نمی تواند یک ایمیل را برای چندین کارمند وارد کند.

یک محدودیت منحصر به فرد معمولاً به صورت زیر نامگذاری می شود - ابتدا پیشوند "UQ_" می آید، سپس نام جدول و پس از خط زیر نام فیلدی که این محدودیت روی آن اعمال می شود، می آید.

بر این اساس، اگر ترکیبی از فیلدها باید در زمینه ردیف‌های جدول منحصر به فرد باشد، آن‌ها را با کاما از هم جدا می‌کنیم:

ALTER TABLE جدول_نام ADD CONSTRAINT constraint_name UNIQUE (فیلد1، فیلد2،…)
با افزودن یک محدودیت DEFAULT به یک فیلد، می‌توانیم یک مقدار پیش‌فرض را تعیین کنیم که اگر هنگام درج رکورد جدید، این فیلد در لیست فیلدهای دستور INSERT قرار نگیرد، جایگزین می‌شود. این محدودیت می تواند به طور مستقیم هنگام ایجاد جدول تنظیم شود.

بیایید یک فیلد Hire Date جدید به جدول Employees اضافه کنیم و آن را HireDate بنامیم و بگوییم که مقدار پیش‌فرض این فیلد تاریخ فعلی خواهد بود:

ALTER TABLE کارکنان اضافه کردن تاریخ استخدام NOT NULL DEFAULT SYSDATETIME()
یا اگر ستون HireDate از قبل وجود داشته باشد، می توان از نحو زیر استفاده کرد:

ALTER TABLE کارکنان، SYSDATETIME() پیش فرض را برای HireDate اضافه کنند
در اینجا من نام محدودیت را مشخص نکردم، زیرا ... در مورد DEFAULT، من معتقدم که این خیلی مهم نیست. اما اگر این کار را به روشی خوب انجام دهید، فکر می کنم نیازی به تنبلی ندارید و باید یک نام معمولی تعیین کنید. این کار به صورت زیر انجام می شود:

ALTER TABLE کارمندان ADD CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME() FOR HireDate
از آنجایی که این ستون قبلا وجود نداشت، وقتی به هر رکورد اضافه می شود، مقدار تاریخ فعلی در قسمت HireDate درج می شود.

هنگام افزودن یک ورودی جدید، تاریخ فعلی نیز به طور خودکار درج می شود، البته، مگر اینکه ما به صراحت آن را تنظیم کنیم، یعنی. ما آن را در لیست ستون ها نشان نمی دهیم. بیایید این را با یک مثال بدون مشخص کردن فیلد HireDate در لیست مقادیر افزوده نشان دهیم:

INSERT Employees(ID,Name,Email)VALUES(1004,N"Sergeev S.S."," [ایمیل محافظت شده]")
ببینیم چی شد:

انتخاب * از کارکنان

شناسه	نام	روز تولد	پست الکترونیک	شناسه موقعیت	شناسه بخش	شناسه مدیر	HireDate
1000	ایوانف I.I.	1955-02-19	[ایمیل محافظت شده]	2	1	خالی	2015-04-08
1001	پتروف P.P.	1983-12-03	[ایمیل محافظت شده]	3	4	1003	2015-04-08
1002	سیدوروف S.S.	1976-06-07	[ایمیل محافظت شده]	1	2	1000	2015-04-08
1003	آندریف A.A.	1982-04-17	[ایمیل محافظت شده]	4	3	1000	2015-04-08
1004	سرگیف S.S.	خالی	[ایمیل محافظت شده]	خالی	خالی	خالی	2015-04-08

محدودیت چک CHECK زمانی استفاده می شود که لازم باشد مقادیر درج شده در فیلد بررسی شود. مثلاً این محدودیت را در قسمت شماره پرسنل که برای ما شناسه کارمند (ID) است اعمال کنیم. با استفاده از این محدودیت، می گوییم که تعداد پرسنل باید از 1000 تا 1999 ارزش داشته باشند:

ALTER TABLE کارمندان اضافه کردن محدودیت CK_Employees_ID چک (ID بین 1000 و 1999)
محدودیت معمولاً به همین صورت نامگذاری می شود، ابتدا با پیشوند "CK_"، سپس نام جدول و نام فیلدی که این محدودیت بر روی آن اعمال می شود.

بیایید سعی کنیم یک رکورد نامعتبر وارد کنیم تا بررسی کنیم که محدودیت کار می کند (باید خطای مربوطه را دریافت کنیم):

VALUES کارکنان (شناسه، ایمیل) را وارد کنید (2000" [ایمیل محافظت شده]")
حالا بیایید مقدار درج شده را به 1500 تغییر دهیم و مطمئن شویم که رکورد درج شده است:

VALUES کارکنان (شناسه، ایمیل) را درج کنید (1500" [ایمیل محافظت شده]")
همچنین می‌توانید محدودیت‌های UNIQUE و CHECK را بدون تعیین نام ایجاد کنید:

ALTER TABLE Employees ADD UNIQUE(Email) ALTER TABLE Employees ADD CHECK (ID بین 1000 و 1999)
اما این عمل خیلی خوبی نیست و بهتر است نام محدودیت را به صراحت مشخص کنید، زیرا برای اینکه بعداً آن را بفهمید، که دشوارتر خواهد بود، باید شی را باز کنید و ببینید مسئول چه چیزی است.

با یک نام خوب، می توان اطلاعات زیادی در مورد محدودیت به طور مستقیم از نام آن آموخت.

و بر این اساس، تمام این محدودیت ها را می توان بلافاصله هنگام ایجاد جدول ایجاد کرد، اگر هنوز وجود نداشته باشد. بیایید جدول را حذف کنیم:

DROP TABLE کارمندان
و ما آن را با تمام محدودیت های ایجاد شده با یک دستور CREATE TABLE دوباره ایجاد می کنیم:

CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), تاریخ تولد, Email nvarchar(30), PositionID int, DepartmentID int, HireDate NOT NULL DEFAULT SYSDATETIME(), -- برای DEFAULT من یک استثنا قائل می شوم PK_Employe PRIMARY KEY (ID)، CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) References Departments(ID), CONSTRAINT FK_Employees_PositionID CO FOREIGN KEY(PositionID) ReFERENCES Positions(ID)، CONSTRAINTEmployeesQUEINEmail es_ID چک (ID BETW EEN 1000 و 1999) )

کارمندان (ID,Name,Tirthday,Email,PositionID,DepartmentID)ارزشها (1000,N"Ivanov I.I.","19550219","[email protected]"2,1, (1001, N"Petrov P.P.""19831203"،" [ایمیل محافظت شده]",3,3), (1002,N"Sidorov S.S.","19760607"," [ایمیل محافظت شده]",1,2), (1003,N"Andreev A.A.","19820417"," [ایمیل محافظت شده]",4,3)

کمی در مورد شاخص های ایجاد شده در هنگام ایجاد محدودیت های کلید اولیه و UNIQUE

همانطور که در تصویر بالا می بینید، هنگام ایجاد محدودیت های کلید اصلی و UNIQUE، فهرست هایی با نام های یکسان (PK_Employees و UQ_Employees_Email) به طور خودکار ایجاد می شوند. به طور پیش فرض، ایندکس برای کلید اصلی به صورت CLUSTERED و برای همه شاخص های دیگر به صورت NONCLUSTERED ایجاد می شود. شایان ذکر است که مفهوم شاخص خوشه ای در همه DBMS ها موجود نیست. یک جدول فقط می تواند یک شاخص خوشه ای داشته باشد. CLUSTERED – به این معنی است که رکوردهای جدول بر اساس این شاخص مرتب می شوند، همچنین می توان گفت که این شاخص به تمام داده های جدول دسترسی مستقیم دارد. به اصطلاح این شاخص اصلی جدول است. به بیان دقیق تر، این یک شاخص است که به یک جدول متصل شده است. ایندکس خوشه‌ای ابزار بسیار قدرتمندی است که می‌تواند به بهینه‌سازی پرس و جو کمک کند، اما بیایید فعلاً این را به خاطر بسپاریم. اگر بخواهیم به ایندکس خوشه‌بندی‌شده بگوییم که نه در کلید اصلی، بلکه در شاخص دیگری استفاده شود، هنگام ایجاد کلید اصلی باید گزینه NONCLUSTERED را مشخص کنیم:

تغییر جدول جدول_نام افزودن محدودیت محدودیت_نام کلید اولیه غیرکلاستری (فیلد1، فیلد2،...)
برای مثال، بیایید فهرست محدودیت PK_Employees را غیر خوشه‌بندی کنیم، و فهرست محدودیت UQ_Employees_Email را خوشه‌بندی کنیم. اول از همه، اجازه دهید این محدودیت ها را حذف کنیم:

ALTER TABLE Employees DROP CONSTRAINT PK_Employees ALTER TABLE Employees DROP CONSTRAINT UQ_Employees_Email
حالا بیایید آنها را با گزینه های CLUSTERED و NONCLUSTERED ایجاد کنیم:

ALTER TABLE Employees ADD CONSTRAINT PK_Employees PRIMARY KEY NONCLUSTERED (ID) ALTER TABLE Employees ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (ایمیل)
حال با انتخاب از جدول Employees، مشاهده می کنیم که رکوردها بر اساس شاخص کلاستر UQ_Employees_Email مرتب شده اند:

انتخاب * از کارکنان

شناسه	نام	روز تولد	پست الکترونیک	شناسه موقعیت	شناسه بخش	HireDate
1003	آندریف A.A.	1982-04-17	[ایمیل محافظت شده]	4	3	2015-04-08
1000	ایوانف I.I.	1955-02-19	[ایمیل محافظت شده]	2	1	2015-04-08
1001	پتروف P.P.	1983-12-03	[ایمیل محافظت شده]	3	3	2015-04-08
1002	سیدوروف S.S.	1976-06-07	[ایمیل محافظت شده]	1	2	2015-04-08

قبلاً، زمانی که فهرست خوشه‌بندی شده، نمایه PK_Employees بود، رکوردها به‌طور پیش‌فرض بر اساس فیلد ID مرتب می‌شدند.

اما در این مورد، این فقط یک مثال است که ماهیت یک شاخص خوشه ای را نشان می دهد، زیرا به احتمال زیاد، با استفاده از فیلد ID، پرس و جوهایی در جدول Employees انجام می شود و در برخی موارد، شاید خود به عنوان یک دایرکتوری عمل کند.

برای دایرکتوری ها، معمولاً توصیه می شود که ایندکس خوشه ای بر روی کلید اصلی ساخته شود، زیرا در درخواست ها اغلب به شناسه دایرکتوری مراجعه می کنیم تا مثلاً نام (موقعیت، بخش) را بدست آوریم. اجازه دهید آنچه را که در بالا نوشتم در اینجا به یاد بیاوریم، که یک نمایه خوشه‌ای دسترسی مستقیم به ردیف‌های جدول دارد و نتیجه آن این است که می‌توانیم مقدار هر ستونی را بدون سربار اضافی دریافت کنیم.

استفاده از شاخص خوشه ای برای فیلدهایی که اغلب نمونه برداری می شوند سودمند است.

گاهی اوقات جداول با یک کلید بر اساس یک فیلد جایگزین ایجاد می شوند؛ در این مورد، ذخیره گزینه CLUSTERED index برای یک نمایه مناسب تر و تعیین گزینه NONCLUSTERED هنگام ایجاد یک کلید اصلی جایگزین می تواند مفید باشد.

بیایید خلاصه کنیم

در این مرحله با انواع محدودیت‌ها به ساده‌ترین شکل آن‌ها آشنا شده‌ایم که با دستوری مانند “ALTER TABLE table_name ADD CONSTRAINT constraint_name...” ایجاد می‌شوند:

• کلید اولیه- کلید اصلی؛
• کلید خارجی- راه اندازی اتصالات و نظارت بر یکپارچگی ارجاعی داده ها؛
• منحصر بفرد- به شما امکان می دهد منحصر به فرد ایجاد کنید.
• بررسی- به شما امکان می دهد از صحت داده های وارد شده اطمینان حاصل کنید.
• پیش فرض- به شما امکان می دهد یک مقدار پیش فرض را تنظیم کنید.
• همچنین شایان ذکر است که تمام محدودیت ها را می توان با استفاده از دستور حذف کرد. جدول تغییراتجدول_نام محدودیت افت constraint_name".

همچنین تا حدی به موضوع شاخص ها پرداختیم و مفهوم خوشه را بررسی کردیم ( خوشه ای) و غیر خوشه ای ( غیرکلاستری) فهرست مطالب.

ایجاد نمایه های مستقل

منظور ما از مستقل در اینجا شاخص هایی است که تحت محدودیت PRIMARY KEY یا UNIQUE ایجاد نمی شوند.

نمایه های یک فیلد یا فیلدها را می توان با دستور زیر ایجاد کرد:

CREATE INDEX IDX_Employees_Name ON Employees(Name)
همچنین در اینجا می توانید گزینه های CLUSTERED، NONCLUSTERED، UNIQUE را مشخص کنید و همچنین می توانید جهت مرتب سازی هر فیلد جداگانه ASC (پیش فرض) یا DESC را مشخص کنید:

ایجاد INDEX غیرکلاستری منحصر به فرد UQ_Employees_EmailDesc بر روی کارکنان (ایمیل DESC)
هنگام ایجاد یک شاخص غیر خوشه ای، گزینه NONCLUSTERED را می توان حذف کرد، زیرا این به طور پیش فرض دلالت دارد و در اینجا به سادگی برای نشان دادن موقعیت گزینه CLUSTERED یا NONCLUSTERED در دستور نشان داده شده است.

با دستور زیر می توانید ایندکس را حذف کنید:

DROP INDEX IDX_Employees_Name ON Employees
نمایه های ساده و همچنین محدودیت ها را می توان در زمینه دستور CREATE TABLE ایجاد کرد.

به عنوان مثال، بیایید دوباره جدول را حذف کنیم:

DROP TABLE کارمندان
و ما آن را با تمام محدودیت ها و فهرست های ایجاد شده با یک دستور CREATE TABLE دوباره ایجاد می کنیم:

CREATE TABLE Employees(ID int NOT NULL, Name nvarchar(30), تاریخ تولد, Email nvarchar(30), PositionID int, DepartmentID int, HireDate NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETEMTRATIDETRINS(مدیر) ), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERENCES Departments(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) ReFERENCES Positions(ID), CONSTRAINT FK_EmployeesMOREIGNIDAnaa CONSTRAINT UQ_Emp loyees_Email UNIQUE(ایمیل)، CONSTRAINT CK_Employees_ID CHECK (ID بین 1000 و 1999)، INDEX IDX_Employees_Name (Name))
در نهایت، اجازه دهید کارمندان خود را در جدول وارد کنیم:

درج کارمندان (شناسه، نام، تولد، ایمیل، شناسه موقعیت، شناسه دپارتمان، شناسه مدیر) VALUES (1000، N"Ivanov I.I.","19550219"،" [ایمیل محافظت شده]",2,1,NULL), (1001,N"Petrov P.P.","19831203"," [ایمیل محافظت شده]",3,3,1003), (1002,N"Sidorov S.S.","19760607"," [ایمیل محافظت شده]",1,2,1000), (1003,N"Andreev A.A.","19820417"," [ایمیل محافظت شده]",4,3,1000)
علاوه بر این، شایان ذکر است که می توانید مقادیر را با مشخص کردن آنها در INCLUDE در یک شاخص غیر خوشه ای قرار دهید. آن ها در این حالت ، شاخص INCLUDE تا حدودی یادآور یک شاخص خوشه ای خواهد بود ، فقط اکنون این شاخص به جدول وصل نشده است ، اما مقادیر لازم به شاخص وصل شده است. بر این اساس، چنین نمایه‌هایی می‌توانند عملکرد کوئری‌های انتخابی (SELECT) را تا حد زیادی بهبود بخشند؛ اگر تمام فیلدهای فهرست‌شده در فهرست باشند، ممکن است اصلاً نیازی به دسترسی به جدول نباشد. اما این به طور طبیعی اندازه شاخص را افزایش می دهد، زیرا مقادیر فیلدهای فهرست شده در ایندکس کپی می شوند.

استخراج از MSDN.دستور عمومی برای ایجاد نمایه ها

ایجاد [UNIQUE] [خوشه ای | NONCLUSTERED ] INDEX index_name روشن است