• پایگاه داده های رابطه ای کلیدهای اصلی

    • ترجمه

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

    4. جداول و کلیدهای اولیه

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

    6 درس در جدول وجود دارد. هر 6 مورد متفاوت هستند، اما برای هر درس، مقادیر همان فیلدها در جدول ذخیره می شود، یعنی: tutorial_id (شناسه درس)، عنوان (عنوان) و دسته (رده). tutorial_idکلید اصلیجداول درس کلید اصلی مقداری است که برای هر رکورد در جدول منحصر به فرد است.
    در جدول مشتری زیر، customer_id کلید اصلی است. که در این موردکلید اصلی نیز یک مقدار (عدد) منحصر به فرد برای هر رکورد است.

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

    چند نمونه

    • شماره سفارشی که هنگام خرید از فروشگاه اینترنتی دریافت می کنید می تواند کلید اولیه برخی از جدول سفارشات در پایگاه داده این فروشگاه باشد، زیرا. این یک ارزش منحصر به فرد است.
    • شماره تامین اجتماعی می تواند کلید اصلی در برخی از جدول های پایگاه داده سازمان دولتی باشد، زیرا همچنین مانند مثال قبلی منحصر به فرد است.
    • شماره فاکتور را می توان به عنوان کلید اصلی در جدول پایگاه داده استفاده کرد که فاکتورهای صادر شده برای مشتریان را ذخیره می کند.
    • شماره مشتری عددی اغلب به عنوان کلید اصلی در جدول مشتری استفاده می شود.

    این مثال ها چه وجه اشتراکی دارند؟ این واقعیت که در همه آنها یک مقدار منحصر به فرد و غیر تکراری برای هر رکورد به عنوان کلید اصلی انتخاب می شود. از نو. مقادیر یک فیلد جدول پایگاه داده انتخاب شده به عنوان کلید اصلی همیشه منحصر به فرد هستند.

    یک کلید اصلی چیست؟ ویژگی های کلید اولیه
    کلید اصلی برای شناسایی رکوردها استفاده می شود.

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

    کلید اصلی منحصر به فرد است.

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

    | نام_نام | نام خانوادگی |
    | واسیا | کدو تنبل |
    | واسیا | کدو تنبل |

    آن ها دو واسیاس وجود دارد. شما می خواهید یک Vasya خاص را از جدول انتخاب کنید. چگونه انجامش بدهیم؟ رکوردها تفاوتی ندارند. اینجاست که کلید اصلی به کار می آید. یک ستون id (نسخه کلاسیک یک کلید اولیه مصنوعی) اضافه می کنیم و ...

    شناسه | نام_نام | نام خانوادگی |
    1 | واسیا | کدو تنبل |
    2 | واسیا | کدو تنبل |

    اکنون هر Vasya منحصر به فرد است.

    انواع کلیدهای اصلی

    معمولاً کلید اصلی یک مقدار عددی است. اما می تواند هر نوع داده دیگری نیز باشد. استفاده از رشته به عنوان کلید اصلی معمول نیست (رشته یک قطعه متن است)، اما از نظر تئوری و عملی این امکان وجود دارد.
    کلیدهای اولیه مرکب
    اغلب کلید اصلی از یک فیلد تشکیل شده است، اما می تواند ترکیبی از چندین ستون، به عنوان مثال، دو (سه، چهار ...) باشد. اما شما به یاد داشته باشید که کلید اصلی همیشه منحصر به فرد است، به این معنی که ترکیب n ام فیلدها، در این مورد 2، باید منحصر به فرد باشد. بعداً در این مورد بیشتر به شما خواهم گفت.

    شماره گذاری خودکار

    فیلد کلید اولیه اغلب، اما نه همیشه، توسط خود پایگاه داده مدیریت می شود. به طور نسبی می توانید به پایگاه داده بگویید که به طور خودکار یک مقدار عددی منحصر به فرد را به هر رکورد هنگام ایجاد آن اختصاص دهد. پایگاه داده معمولاً شماره گذاری را از 1 شروع می کند و آن عدد را برای هر ورودی یک عدد افزایش می دهد. چنین کلید اولیه ای افزایش خودکار یا شماره گذاری خودکار نامیده می شود. استفاده از کلیدهای افزایش خودکار - راه خوببرای تنظیم کلیدهای اولیه منحصر به فرد نام کلاسیک چنین کلیدی یک کلید اصلی جایگزین است [همانطور که در بالا ذکر شد. - تقریبا ترجمه.]. این کلید شامل نمی شود اطلاعات مفید، مربوط به موجودیت (شیء) است که اطلاعات مربوط به آن در جدول ذخیره می شود و به همین دلیل به آن جانشین می گویند.

    5. پیوند جداول با کلیدهای خارجی

    زمانی که توسعه پایگاه داده را شروع کردم، اغلب سعی می کردم اطلاعاتی را که مرتبط به نظر می رسید در یک جدول ذخیره کنم. برای مثال می‌توانم اطلاعات سفارش را در جدول مشتری ذخیره کنم. پس از همه، سفارشات متعلق به مشتریان است، درست است؟ خیر مشتریان و سفارشات موجودیت های جداگانه ای در پایگاه داده هستند. هر دو به میز خود نیاز دارند. و رکوردهای این دو جدول را می توان به هم پیوند داد تا رابطه ای بین آنها برقرار شود. طراحی پایگاه داده راه حلی برای دو سوال است:
    • تعریف اینکه کدام موجودیت ها را می خواهید در آن ذخیره کنید
    • چه روابطی بین این موجودات وجود دارد؟
    یک به چند.
    مشتریان و سفارشات به هم متصل هستند (آنها در یک رابطه هستند) یک به چندزیرا یکیمشتری ممکن است داشته باشد بسیاری ازسفارشات، اما هر سفارش خاص (آنها یک دسته از) فقط قاب شده است یکیمشتری، یعنی فقط می تواند یک مشتری داشته باشد. نگران نباشید اگر این لحظهدرک این ارتباط مبهم است. در قسمت های بعدی بیشتر در مورد اتصالات صحبت خواهم کرد.

    اکنون یک چیز مهم است - اینکه برای یک رابطه یک به چند، دوجداول جداگانه یکی برای مشتریان، دیگری برای سفارشات. بیایید با ایجاد این دو جدول کمی تمرین کنیم.

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

    ما در حال طراحی میز مشتری هستیم.

    سفارشاتواقعا متعلق به مشتریان است، اما سفارش نیست حداقل بلوک اطلاعات، که به مشتریان اشاره دارد (یعنی این بلوک را می توان به بلوک های کوچکتر تقسیم کرد: برای مثال تاریخ سفارش، آدرس تحویل سفارش و غیره).
    فیلدهای زیر حداقل اطلاعاتی است که برای مشتریان اعمال می شود:

    • customer_id (کلید اصلی) – شناسه مشتری
    • first_name - نام
    • نام خانوادگی - نام خانوادگی
    • آدرس - آدرس
    • کد پستی- کد پستی
    • کشور - کشور
    • تولد_تاریخ - تاریخ تولد
    • نام کاربری - نام کاربری ثبت نام (ورود به سیستم)
    • رمز عبور - رمز عبور

    بیایید به ساخت این جدول در SQLyog ادامه دهیم (البته می توانید از هر برنامه دیگری استفاده کنید). در زیر نمونه ای از این است که یک جدول در SQLyog پس از ایجاد چه شکلی است. همه برنامه های گرافیکیبرای مدیریت پایگاه داده تقریباً ساختار رابط یکسانی دارند. شما همچنین می توانید یک جدول با خط فرمانبدون استفاده از ابزار گرافیکی


    ایجاد جدول در SQLyog توجه داشته باشید که چک باکس کلید اصلی (PK) برای قسمت customer_id انتخاب شده است. فیلد customer_id کلید اصلی است. چک باکس Auto Incr نیز انتخاب شده است، به این معنی که پایگاه داده به طور خودکار یک مقدار عددی منحصر به فرد را جایگزین می کند، که با شروع از صفر، هر بار یک عدد افزایش می یابد.

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

    • order_id (کلید اصلی) – شناسه سفارش
    • order_date - تاریخ و زمان سفارش
    • مشتری - مشتری که سفارش داده است

    در زیر یک جدول نمونه در SQLyog آمده است.

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

    یک رابطه کلید خارجی ایجاد کنید.

    ممکن است تعجب کنید، "چگونه می توانم مطمئن شوم یا چگونه می توانم ببینم که فیلد مشتری در جدول سفارشات با فیلد customer_id در جدول مشتری ارجاع داده شده است." پاسخ ساده است - شما نمی توانید این کار را انجام دهید زیرا من هنوز به شما نشان نداده ام که چگونه یک اتصال ایجاد کنید.
    در زیر پنجره SQLyog با پنجره ای است که برای ایجاد رابطه بین جداول استفاده کردم.


    یک رابطه کلید خارجی بین جداول سفارشات و مشتریان ایجاد کنید.

    در پنجره بالا، می توانید ببینید که چگونه فیلد مشتری جدول سفارشات در سمت چپ به کلید اصلی (customer_id) جدول مشتری در سمت راست مرتبط است.

    حال، وقتی به داده هایی که می توانند در جداول باشند نگاه می کنید، می بینید که این دو جدول به هم مرتبط هستند.


    سفارشات از طریق فیلد مشتری که به جدول مشتری اشاره دارد با مشتریان مرتبط می شود.

    در تصویر می بینید که مشتری مريمسه سفارش داد، مشتری پابلویک و مشتری قرار داده است جان- هیچکس.
    ممکن است بپرسید: «الف چیاین همان چیزی است که این همه دستور دادند؟» این سؤال خوبی بود. ممکن است انتظار داشته باشید که اقلام سفارش داده شده را در جدول سفارش مشاهده کنید. اما این مثال بدطرح. چگونه چندین محصول را در یک ورودی قرار می دهید؟ کالاهاموجودیت های جداگانه ای هستند که باید در یک جدول جداگانه ذخیره شوند. و رابطه بین جداول سفارشاتو کالاهارابطه یک به چند خواهد بود. در این مورد بیشتر صحبت خواهم کرد.

    6. ایجاد یک نمودار موجودیت پیوند

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

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

    بیایید یک فروشگاه آنلاین را به عنوان مثال در نظر بگیریم. فروشگاه اینترنتی می فروشد کالاها. تولید - محصولمی تواند به یک موجودیت آشکار در سیستم فروشگاه آنلاین تبدیل شود. کالاها سفارش داده شدهمشتریان. در اینجا ما با شما هستیم و دو موجودیت واضح دیگر را دیدیم: سفارشاتو مشتریان.

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

    اگر مطمئن نیستید، فقط به این فکر کنید که چه نوع اطلاعات پرداختی را می خواهید ذخیره کنید. ممکن است بخواهید نگه دارید روش پرداختیا تاریخ پرداخت. اما اینها هنوز هم حداقل اطلاعاتی هستند که می تواند مرتبط باشد سفارش. می توانید جمله بندی را تغییر دهید. روش پرداخت - روش پرداخت سفارش. تاریخ پرداخت - تاریخ پرداخت سفارش. بنابراین، من نیازی به ساختن نمی بینم مبلغ پرداختیدر یک جدول جداگانه، اگرچه از نظر مفهومی می‌توانید پرداخت‌ها را به عنوان یک نهاد مشخص کنید، زیرا می توانید پرداخت ها را به عنوان یک ظرف اطلاعاتی (روش پرداخت، تاریخ پرداخت) در نظر بگیرید.

    زیاد آکادمیک نباشیم.

    همانطور که می بینید، بین یک موجودیت و یک جدول در خود پایگاه داده تفاوت وجود دارد، i.e. این یک چیز نیست متخصصان صنعت فناوری اطلاعاتمی تواند در این موضوع بسیار آکادمیک و معقول باشد. من آن جور متخصص نیستم. این تفاوت به دیدگاه شما در مورد داده ها، اطلاعات شما بستگی دارد. اگر به مدل سازی داده ها از نظر نرم افزار، سپس می توانید با بسیاری از موجودیت ها روبرو شوید که نمی توانند مستقیماً به پایگاه داده منتقل شوند. در این آموزش، ما به داده ها دقیقاً از منظر پایگاه داده نگاه می کنیم، و در دنیای کوچک ما، موجودیت جدول است.


    منتظر بمانید، شما واقعاً به گرفتن دکترا در پایگاه داده نزدیک شده اید.

    همانطور که می بینید، تعیین اینکه سیستم شما دارای چه موجودیت هایی است کمی یک فرآیند فکری است که به تجربه نیاز دارد و اغلب در معرض تغییر، تجدید نظر، تفکر است، اما البته این علم موشکی نیست.


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

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

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

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

    1) رادیک نهاد مستقل است. نام ها در یک مستطیل قرار می گیرند.

    2) انجمنیرابطه چند به چند بین دو یا چند موجودیت. انجمن ها به عنوان یک نهاد کامل در نظر گرفته می شوند. آنها می توانند در انجمن های دیگر شرکت کنند و مجموعه ای از ویژگی ها را داشته باشند.

    آ. تعیین ها (نشان دهنده یک موجودیت) روابط چند به یک یا یک به یک بین دو موجودیت هستند. تفاوت آن با مشخصه این است که به موجودیت نشان دهنده بستگی ندارد.

    3) مشخصه(ویژگی) - رابطه چند به یک یا یک به یک بین دو موجودیت. این یک مورد خاص از یک انجمن است. تنها هدف یک مشخصه توصیف یا شفاف سازی موجودیت دیگری است. وجود یک مشخصه کاملاً به موجودی که مشخص می شود بستگی دارد.

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

    حداقلی به این معناست که از نظر لغوی، از مجموعه هیچ صفت، امکان شناسایی موجودیت با بقیه صفات را نمی دهد.

    یکی از کلیدها به عنوان کلید اصلی و بقیه جایگزین نامیده می شوند. به طور بالقوه، یک کلید متشکل از یک ویژگی ساده نامیده می شود. مجاز نیست که کلید اولیه موجودیت اصلی مقدار نامشخصی بگیرد، در غیر این صورت یک وضعیت متناقض ایجاد می شود - یک غیر هویت، و بنابراین نمونه غیر موجود از موجودیت اصلی ظاهر می شود. به همین دلایل، لازم است از منحصر به فرد بودن کلید اصلی اطمینان حاصل شود.

    اگر موجودیت C موجودیت های A و B را به هم پیوند دهد، باید شامل کلیدهای خارجی مربوط به کلیدهای اولیه موجودیت های A و B باشد.

    برای هر کلید خارجی، سه سوال باید مطرح شود:

    1) آیا یک کلید خارجی اضافی می تواند مقادیر نامشخص (مقادیر تهی) را بگیرد، به طور خلاصه، آیا موجودیتی وجود دارد که موجودیت هدف مشخص شده توسط کلید خارجی برای آن شناخته شده باشد.

    2) چه اتفاقی باید بیفتد هنگامی که می خواهید نهاد مورد نظر را که توسط کلید خارجی به آن ارجاع داده شده است حذف کنید.

    سه راه حل ممکن وجود دارد این مساله:

    آبشاری

    محدودیت

    تنظیم روی یک مقدار خاص

    3) هنگام تلاش برای به روز رسانی کلید اصلی موجودیت هدف که توسط برخی از کلیدهای خارجی ارجاع شده است، چه اتفاقی باید بیفتد.

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

    انواع داده ها و دامنه ها

    مدل داده های رابطه ای با ساختار داده ساده و ارائه کاربر پسند مشخص می شود.

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

    1) هر عنصر جدول یک عنصر داده است

    2) همه ستون های یک جدول همگن هستند - همه عناصر در یک ستون دارای نوع داده و طول یکسان هستند

    3) هر ستون یک نام منحصر به فرد دارد

    4) هیچ ردیفی در جدول وجود ندارد

    5) ترتیب ردیف ستون ها می تواند دلخواه باشد

    انواع داده ها

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

    به طور کلی انواع داده ها به سه گروه تقسیم می شوند:

    1) انواع داده های ساده

    2) انواع داده های ساخت یافته

    3) انواع داده های مرجع

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

    ساختار انواع داده ها برای تعریف ساختارهای داده پیچیده ای در نظر گرفته شده است که از عناصر تشکیل دهنده ساخته می شوند، که به نوبه خود ممکن است یک ساختار داخلی (آرایه ها، رکوردها، ساختارها) داشته باشند.

    نوع داده مرجع برای ارائه توانایی اشاره به داده های دیگر در نظر گرفته شده است. این نوع داده برای زبان های نوع رویه ای در نظر گرفته شده است که دارای مناطق حافظه برای ذخیره داده ها هستند.

    برای مدل رابطه اینوع داده استفاده شده چندان مهم نیست. شرط ساده بودن نوع داده باید به این معنا باشد که در عملیات رابطه ایساختار داده داخلی نباید در نظر گرفته شود.

    دامنه porno.ru

    در مدل داده‌های رابطه‌ای، مفهوم نوع داده ارتباط نزدیکی با مفهوم دامنه دارد که می‌توان آن را به‌عنوان پالایش یک نوع داده در نظر گرفت.

    دامنه -مفهوم معنایی می توان آن را به عنوان زیر مجموعه ای از مقادیر برخی از انواع داده در نظر گرفت.

    ویژگی های دامنه:

    1) دامنه دارای یک نام منحصر به فرد در پایگاه داده است

    2) دامنه بر روی یک نوع داده ساده یا در دامنه دیگری تعریف شده است

    3) یک دامنه ممکن است شرایط منطقی داشته باشد که امکان توصیف زیرمجموعه‌ای از داده‌ها را که برای یک دامنه معین معتبر هستند را فراهم می‌کند.

    4) دامنه مقداری بار معنایی را حمل می کند

    به عنوان مثال، برخی از دامنه های D به معنای "سن کارمند" را می توان به عنوان زیر مجموعه ای از مجموعه اعداد طبیعی توصیف کرد.

    D=(nεN: n ≥ 18 و n ≤ 60)

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

    5. روابط و خصوصیات، صفات و اقسام آنها.
    مفهوم رابطه یک مفهوم اساسی از مدل داده های رابطه ای است. ویژگی رابطه:<Имя_атрибута: Имя_домена>. نام ویژگی ها باید در یک رابطه منحصر به فرد باشد. غالباً نام ویژگی ها با نام های دامنه مربوطه یکسان است. برخی از رابطه های R تعریف شده در مجموعه دامنه های D 1 ,D 2 ,…D n شامل دو بخش است: سرصفحه و بدنه. هدر رابطه حاوی تعداد ثابتی از ویژگی های رابطه است.

    (,,…)

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

    <Имя_атрибута: Значение_атрибута>

    (,,… ).

    مقدار Val i متعلق به ویژگی A i D i است. مقدار نوشته شده است:

    R( ,,…).

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

    پایگاه داده رابطه ای مجموعه ای از روابط است. طرح واره پایگاه داده رابطه ای مجموعه ای از هدرهای رابطه است که در یک پایگاه داده گنجانده شده است.

    اگرچه هر رابطه ای را می توان به عنوان یک جدول نشان داد، اما رابطه یک جدول نیست. اینها مفاهیم نزدیک هستند اما متناظر نیستند. اصطلاحاتی که مدل داده‌های رابطه‌ای بر روی آن‌ها عمل می‌کند، مترادف‌های «جدولی» مربوطه دارند.

    ویژگی های رابطه

    ویژگی های رابطه تفاوت های اصلی بین روابط هستند.

    1) با توجه به کارت های غیر یکسان.

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

    2) کارتژها (از بالا به پایین) مرتب نمی شوند زیرا بدنه رابطه یک مجموعه است.

    نمی توان همان رابطه را به تصویر کشید جداول مختلف، که در آن خطوط به ترتیب مختلف

    3) صفات از چپ به راست مرتب نمی شوند. از آنجایی که هر ویژگی یک نام منحصر به فرد در یک رابطه دارد، ترتیب صفات مهم نیست. یک رابطه مشابه را می توان با جداول مختلفی که در آنها ستون ها به ترتیب متفاوتی هستند نشان داد.

    4) همه مقادیر مشخصه اتمی هستند.

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

    مشکل طراحی منطقی پایگاه داده رابطه ایداده کاوی شامل تصمیم گیری آگاهانه در مورد اینکه پایگاه داده از چه روابطی باید تشکیل شده باشد و این روابط چه ویژگی هایی باید داشته باشند.

    مدل داده‌های رابطه‌ای دو الزام یکپارچگی اساسی را که باید در هر DBMS رابطه‌ای پشتیبانی شود، برطرف می‌کند.

    1) شرط یکپارچگی موجودیت، این است که هر تاپلی از هر رابطه باید از هر تاپلی دیگر این رابطه قابل تشخیص باشد، یعنی هر رابطه ای باید حاوی یک کلید اولیه باشد.

    2) شرط یکپارچگی ارجاعی (شرایط یکپارچگی کلید خارجی) این است که برای هر مقدار کلید خارجی در رابطه ارجاع شده، . باید یک تاپل با همان مقدار کلید اصلی وجود داشته باشد یا مقدار کلید خارجی باید null باشد.

    کلید اصلی یک ویژگی منحصر به فرد برای هر رکورد در یک جدول است. Access از دو نوع کلید اصلی پشتیبانی می کند: ساده و مرکب.

    قالب کلید سادهدر صورتی که مقادیر خالی و تکراری در این قسمت وجود نداشته باشد، یکی از فیلدهای موجود جدول می تواند عمل کند. نمونه هایی از این فیلدها می تواند شماره ماشین، شماره موجودی، کد شناسایی باشد. یک کلید ترکیبی به صورت ترکیبی از دو یا چند عنصر داده ساخته می شود. برای مثال برای جدول Employees، از نظر تئوری می توان از ترکیب دو فیلد Last Name و First Name به عنوان کلید اصلی استفاده کرد. با این حال، کاملاً ممکن است که کارمند دیگری با نام و نام خانوادگی مشابه فردی که قبلاً کار می کند در شرکت ظاهر شود.

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

    قوانین اساسی برای کلیدها در Access وجود دارد:

      برای راحتی، فیلد کلید معمولاً ابتدا در ساختار جدول ذکر می شود.

      اگر یک جدول دارای کلید اصلی تعریف شده باشد، Access به طور خودکار ورود مقادیر تکراری یا مقادیر تهی (خالی) را در آن فیلد مسدود می کند.

      Access به طور خودکار سوابق جدول را بر اساس کلید اصلی مرتب می کند.

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

    برای تنظیم جدول روی کلید اصلی و تکمیل ساخت آن در نمای طراحی، مراحل زیر را دنبال کنید:

      در حالت طراحی، فیلدی را انتخاب کنید که نقش کلید اصلی را بازی می کند.

      روی دکمه فیلد کلید در نوار ابزار جدول ساز کلیک کنید یا دستور منوی اصلی ویرایش - فیلد کلید را انتخاب کنید (یک نماد کلید در کنار نام فیلد انتخاب شده ظاهر می شود).

      پس از تعیین فیلد کلید، جدول باید ذخیره شود که برای این کار باید روی دکمه Save در نوار ابزار Table Designer کلیک کنید و در پنجره باز شده نام جدول را وارد کرده و دکمه OK را بزنید.

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

    17. انواع اتصالات و اجرای آنها. تمامیت ارجاعی و اجرای آن.

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

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

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

    انواع روابط بین جداول

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

    سه نوع رابطه بین جداول وجود دارد. نوع رابطه ایجاد شده به نحوه تعریف ستون های مرتبط بستگی دارد.

    روابط یک به چند

    رابطه یک به چند رایج ترین نوع رابطه است. با چنین رابطه ای، هر سطر از جدول A می تواند با سطرهای زیادی از جدول B مطابقت داشته باشد، اما هر سطر از جدول B می تواند تنها با یک ردیف از جدول A مطابقت داشته باشد، برای مثال، یک رابطه یک به چند بین جداول برقرار می شود. «ناشران» و «کتاب»: هر یک از ناشران می توانند کتاب های زیادی منتشر کنند، اما هر کتاب تنها توسط یک ناشر منتشر می شود.

    یک رابطه یک به چند زمانی ایجاد می شود که تنها یکی از ستون های مرتبط دارای یک محدودیت منحصر به فرد یا کلید اصلی باشد.

    در مایکروسافت اکسس، طرف رابطه یک به چند که کلید اصلی مربوط به آن است با نماد کلید نشان داده می شود. طرف رابطه ای که کلید خارجی با آن مطابقت دارد با نماد بی نهایت نشان داده می شود.

    روابط چند به چند

    هنگام ایجاد یک رابطه چند به چند، هر ردیف از جدول A می تواند با بسیاری از ردیف های جدول B مطابقت داشته باشد و بالعکس. چنین رابطه ای با استفاده از جدول سومی به نام join ایجاد می شود که کلید اصلی آن از کلیدهای خارجی مرتبط با جداول A و B تشکیل شده است. برای مثال، یک رابطه چند به چند بین جداول "نویسندگان" و "کتاب" برقرار می شود. با استفاده از روابط یک رابطه یک به چند بین هر یک از این جداول و جدول BookAuthors. کلید اصلی جدول BookAuthors ترکیبی از ستون‌های AuthorID (کلید اصلی جدول نویسنده‌ها) و BookID (کلید اصلی جدول عنوان‌ها) است.

    روابط یک به یک

    هنگام ایجاد یک رابطه یک به یک، هر ردیف از جدول A می تواند تنها با یک ردیف از جدول B مطابقت داشته باشد و بالعکس. یک رابطه یک به یک زمانی ایجاد می شود که هر دو ستون مرتبط کلیدهای اولیه باشند یا دارای محدودیت های منحصر به فرد باشند.

    این نوع رابطه به ندرت مورد استفاده قرار می گیرد، زیرا در چنین شرایطی معمولاً داده های مرتبط را می توان در یک جدول ذخیره کرد. در موارد زیر می توانید از رابطه یک به یک استفاده کنید.

    برای تقسیم جدولی که تعداد ستون‌های زیادی دارد.

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

    برای ذخیره داده های استفاده کوتاه مدت، ساده ترین راه برای حذف آن پاک کردن جدول است.

    برای ذخیره داده های مربوط به تنها زیر مجموعه ای از جدول اصلی.

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

    ایجاد روابط بین جداول

    هنگام برقراری رابطه بین جداول، فیلدهای مرتبط نباید نام یکسانی داشته باشند. با این حال، آنها باید نوع داده یکسانی داشته باشند، مگر اینکه فیلدی که کلید اصلی است از نوع "Counter" باشد. یک فیلد از نوع "Counter" را تنها در صورتی می توان با فیلدی از نوع "Numeric" مرتبط کرد که خاصیت FieldSize (اندازه فیلد) هر یک از آنها روی یک مقدار تنظیم شده باشد. به عنوان مثال، اگر ویژگی FieldSize هر یک روی Long Integer تنظیم شده باشد، می توانید ستون هایی از نوع Count و Numeric را به هم مرتبط کنید. حتی اگر هر دو ستون مرتبط از نوع Numeric باشند، مقدار ویژگی FieldSize برای هر دو فیلد باید یکسان باشد.

    کلید اصلی فیلدی در جدول است که هر ردیف/رکورد در جدول پایگاه داده را به طور منحصر به فرد شناسایی می کند. کلیدهای اصلی باید حاوی مقادیر منحصر به فرد باشند. کلید اصلی یک ستون نمی تواند مقدار داشته باشد.

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

    اگر یک جدول دارای یک کلید اصلی تعریف شده در هر فیلد(هایی) باشد، نمی توانید دو رکورد دارای مقدار یکسانی با آن فیلد(ها) داشته باشید.

    توجه داشته باشید- می توانید از این مفاهیم در هنگام ایجاد جداول پایگاه داده استفاده کنید.

    ایجاد یک کلید اصلی

    در اینجا دستوری برای تعریف ویژگی ID به عنوان کلید اصلی در جدول مشتریان وجود دارد.

    CREATE TABLE CUSTOMERS(ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25) , SALARY Decimal (18, 2), PRIMARY KEY (ID));

    برای ایجاد یک محدودیت کلید اصلی در ستون "ID" زمانی که جدول CUSTOMERS از قبل وجود دارد، از دستور SQL زیر استفاده کنید:

    ALTER TABLE CUSTOMERS ADD PRIMARY KEY (ID);

    توجه داشته باشید

    اگر از عبارت ALTER TABLE برای افزودن کلید اصلی استفاده می کنید، ستون(های) کلید اصلی باید قبلاً غیر تهی اعلام شده باشند (اگر جدول ابتدا ایجاد شده باشد).

    برای تعریف یک کلید اصلی در چندین ستون، از دستور SQL زیر استفاده کنید:

    CREATE TABLE CUSTOMERS(ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25) , SALARY Decimal (18, 2), PRIMARY KEY (ID, NAME));

    برای ایجاد یک محدودیت کلید اصلی در ستون های "ID" و "NAME" زمانی که جدول CUSTOMERS از قبل وجود دارد، از دستور SQL زیر استفاده کنید.

    ALTER TABLE CUSTOMERS ADD CONSTRAINT PK_CUSTID PRIMARY KEY(ID, NAME);

    حذف کلید اصلی

    شما می توانید محدودیت های کلید اولیه را از یک جدول با استفاده از نحو ارائه شده در زیر پاک کنید.

    ALTER TABLE CUSTOMERS DROP PRIMARY KEY;

    InterBase می تواند از انواع محدودیت های زیر استفاده کند:
    • کلید اولیه - کلید اصلی جدول.
    • UNIQUE - کلید جدول منحصر به فرد.
    • کلید خارجی- کلید خارجی، پیوندی به جدول دیگری ارائه می دهد و یکپارچگی ارجاعی را بین والد و تضمین می کند میزهای کودک.

    نکته ای در مورد اصطلاحات

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

    این احتمالاً به دلیل نحوه تفسیر این تعاریف در DBMS محلی و سرور SQL است.

    در DBMS محلی، جدول اصلی، جدولی است که حاوی داده های اصلی است و جدول فرعی، جدول اضافی است. برای مثال سه مورد را در نظر بگیرید جداول مرتبط. اولی شامل داده‌های فروش، دومی حاوی داده‌های محصول، و سومی حاوی داده‌های مشتری است:


    برنج. 18.1.

    در اینجا، اطلاعات اصلی در جدول فروش ذخیره می شود، بنابراین، اصلی (والد) است. اطلاعات اضافیدر جداول اجناس و خریداران ذخیره می شوند، بنابراین کودک هستند. این قابل درک است: یک دختر نمی تواند دو مادر بیولوژیک داشته باشد، اما یک مادر کاملاً قادر به به دنیا آوردن دو دختر است.

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

    بنابراین در مثال بالا، جدول فروش دارای دو کلید خارجی است: شناسه محصول و شناسه مشتری. و هر دو جدول سمت راست شکل دارند کلید والد"مشخص کننده". از آنجایی که یک مشتری یا محصول می تواند بیش از یک بار در جدول فروش ظاهر شود، معلوم می شود که هر دو جدول سمت راست شکل والدین هستند و جدول سمت چپ یک کودک است. چون الان داریم درس میخونیم InterBase-SQLسرور پایگاه داده، در سخنرانی های بعدی با این تعاریف هدایت خواهیم شد. برای اینکه بیشتر در مورد این سردرگمی گیج نشویم، بلافاصله موافقت خواهیم کرد: میز کودکدارای یک کلید خارجی (FOREIGN KEY) به جدول دیگری.

    کلید اولیه

    کلید اولیه- کلید اصلی، یکی از انواع اصلی محدودیت ها در پایگاه داده است. کلید اصلی برای شناسایی منحصر به فرد یک رکورد در جدول در نظر گرفته شده است و باید منحصر به فرد باشد. کلیدهای اولیه PRIMARY KEY در جداولی قرار دارند که به آنها والد (Parent) می گویند. کلید اولیه را با شاخص های اولیه پایگاه های داده محلی اشتباه نگیرید، کلید اولیه یک شاخص نیست، بلکه یک محدودیت است. هنگام ایجاد یک کلید اصلی InterBaseبه طور خودکار برای او ایجاد می کند شاخص منحصر به فرد . با این حال، اگر ایجاد کنیم شاخص منحصر به فرد، این ایجاد نمی کند محدودیت های کلید اولیه. یک جدول فقط می تواند یک کلید اصلی داشته باشد.

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

    کلید اصلی - این یک یا چند فیلد در جدول است که ترکیب آنها برای هر رکورد منحصر به فرد است.

    اگر کلید اصلی دارای یک ستون واحد باشد (همانطور که اغلب مورد است)، مشخص کننده کلید اولیه زمانی استفاده می شود که تعریف ستون:

    CREATE TABLE Prim_1(Stolbec1 INT NOT NULL PRIMARY KEY، Stolbec2 VARCHAR(50))

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

    CREATE TABLE Prim_2 (Stolbec1 INT NOT NULL، Stolbec2 VARCHAR(50) NOT NULL، PRIMARY KEY (Stolbec1، Stolbec2))

    همانطور که از مثال ها می بینید، کلید اصلی است باید الزاماً یک محدودیت ستون(های) NOT NULL داشته باشد.

    منحصر بفرد

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

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

    CREATE TABLE Prim_3(Stolbec1 INT NOT NULL PRIMARY KEY، Stolbec2 VARCHAR(50) NOT NULL UNIQUE، Stolbec3 FLOAT NULL UNIQUE)

    کلید خارجی

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