مقاله
شروع کنید
شروع به یادگیری
JavaRush /وبلاگ جاوا /Random-FA /ما پایگاه داده ها و زبان SQL را تجزیه و تحلیل می کنیم. (ق...
Roman Beekeeper
مرحله

ما پایگاه داده ها و زبان SQL را تجزیه و تحلیل می کنیم. (قسمت 5 - اتصالات و اتصالات) - "پروژه جاوا از A تا Z"

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

انواع روابط در پایگاه داده

"پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 2برای درک اینکه روابط چیست، باید به یاد داشته باشید که کلید خارجی چیست. برای کسانی که فراموش کردند، به ابتدای سریال خوش آمدید .

یک به چند

بیایید مثال خود را با کشورها و شهرها به یاد بیاوریم. واضح است که یک شهر باید کشور داشته باشد. چگونه یک کشور را به یک شهر مرتبط کنیم؟ لازم است به هر شهر یک شناسه (ID) منحصر به فرد کشوری که به آن تعلق دارد پیوست شود: ما قبلاً این کار را انجام داده ایم. این یکی از انواع اتصالات نامیده می شود - یک به چند (همچنین خوب است نسخه انگلیسی آن را بدانید - یک به چند). به تعبیری می توان گفت: چند شهر می توانند متعلق به یک کشور باشند. اینگونه باید آن را به خاطر بسپارید: رابطه یک به چند. تا اینجا روشن است، درست است؟ اگر نه، پس "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 3این اولین عکس از اینترنت است: این نشان می دهد که مشتریان و سفارشات آنها وجود دارد. منطقی است که یک مشتری بتواند بیش از یک سفارش داشته باشد. یک به چند هست :) یا مثال دیگر: "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 4سه جدول وجود دارد: ناشر، نویسنده و کتاب. هر ناشری که نمی‌خواهد ورشکست شود و می‌خواهد موفق باشد بیش از یک نویسنده دارد، موافق نیستید؟ به نوبه خود، هر نویسنده ممکن است بیش از یک کتاب داشته باشد - در این مورد نیز شکی وجود ندارد. و این به معنای پیوند یک نویسنده با بسیاری از کتاب ها، یک ناشر به بسیاری از نویسندگان است . مثال های بسیار زیاد دیگری وجود دارد که می توان ارائه داد. مشکل درک در ابتدا ممکن است فقط در یادگیری تفکر انتزاعی باشد: نگاه کردن از بیرون به میزها و تعامل آنها.

یک به یک (یک به یک)

می توان گفت که این یک مورد خاص از ارتباط یک به چند است. وضعیتی که در آن یک رکورد در یک جدول فقط با یک رکورد در جدول دیگر مرتبط است. چه نمونه هایی از زندگی می تواند وجود داشته باشد؟ اگر تعدد زوجات را حذف کنیم، می توان گفت که بین زن و شوهر رابطه یک به یک وجود دارد. اگرچه حتی اگر بگوییم تعدد زوجات جایز است، باز هم هر زن می تواند تنها یک شوهر داشته باشد. همین را می توان در مورد والدین نیز گفت. هر فرد می تواند تنها یک پدر بیولوژیکی و تنها یک مادر بیولوژیک داشته باشد. رابطه صریح یک به یک در حالی که داشتم این را می نوشتم، فکری به ذهنم خطور کرد: پس چرا یک رابطه یک به یک را به دو رکورد در جداول مختلف تقسیم کنیم، اگر قبلاً یک رابطه یک به یک دارند؟ من خودم به جواب رسیدم. این رکوردها همچنین ممکن است به طرق دیگری به رکوردهای دیگر مرتبط شوند. من در مورد چه چیزی صحبت می کنم؟ نمونه دیگری از ارتباطات یک به یک، بین کشور و رئیس جمهور است. آیا می توان تمام داده های مربوط به رئیس جمهور را در جدول "کشور" نوشت؟ بله، شما می توانید، SQL یک کلمه نمی گوید. اما اگر فکر می کنید که رئیس جمهور هم یک نفر است... و ممکن است همسر (یک رابطه یک به یک دیگر) و فرزند (یک رابطه یک به چند دیگر) نیز داشته باشد و بعد معلوم شود که خواهد شد. لازمه ارتباط کشور با همسر و فرزندان رئیس جمهور… دیوانه به نظر می رسد، درست است؟ :D مثال های زیادی برای این ارتباط می تواند وجود داشته باشد. علاوه بر این، در چنین شرایطی، برخلاف رابطه یک به چند، می توانید یک کلید خارجی به هر دو جدول اضافه کنید.
Java-университет

چند به چند

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

اگر دو جدول A و B داشته باشیم.

A می تواند با B به عنوان یک به بسیاری ارتباط داشته باشد.

اما B همچنین می تواند با A ارتباط داشته باشد همانطور که یکی به بسیاری مربوط می شود.

این بدان معنی است که آنها یک رابطه چند به چند دارند.
نحوه تنظیم انواع اتصالات قبلی در SQL واضح بود: ما فقط شناسه آن یکی را به آن رکوردها ارسال می کنیم، که تعداد زیادی از آنها وجود دارد، درست است؟ یک کشور شناسه خود را به عنوان کلید خارجی به بسیاری از شهرها می دهد. با روابط چند به چند چه کنیم ؟ این روش مناسب نیست. باید جدول دیگری اضافه کنیم که این دو جدول را به هم متصل کند. به عنوان مثال، اجازه دهید به MySQL برویم، یک پایگاه داده جدید manytomany ایجاد کنیم، دو جدول نویسنده و کتاب ایجاد کنیم که فقط شامل نام ها و شناسه های آنها خواهد بود: CREATE DATABASE manytomany. استفاده از manytomany. CREATE TABLE نویسنده( شناسه INT AUTO_INCREMENT، نام VARCHAR(100)، PRIMARY KEY (id) ); کتاب CREATE TABLE( id INT AUTO_INCREMENT, name VARCHAR(100), PRIMARY KEY (id) ); "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 5حالا بیایید یک جدول سوم ایجاد کنیم که دارای دو کلید خارجی از جداول نویسنده و کتاب ما باشد و این لینک منحصر به فرد خواهد بود. یعنی نمی‌توان یک رکورد را با کلیدهای یکسان دو بار اضافه کرد: CREATE TABLE authors_x_books (book_id INT NOT NULL, author_id INT NOT NULL, FOREIGN KEY (book_id) REFERENCES book(id), FOREIGN KEY (author_id) REFERENCES نویسنده (id ), UNIQUE (book_id, author_id) ); "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 6در اینجا ما از چندین ویژگی جدید استفاده کردیم که باید به طور جداگانه در مورد آنها توضیح داده شود:
  • NOT NULL به این معنی است که فیلد باید همیشه پر شود، و اگر این کار را نکنیم، SQL این را به ما خواهد گفت.
  • UNIQUE می گوید که یک فیلد یا دسته ای از فیلدها باید در جدول منحصر به فرد باشند. اغلب اتفاق می افتد که علاوه بر شناسه منحصر به فرد، یک فیلد دیگر باید برای هر رکورد منحصر به فرد باشد. و UNIQUE دقیقاً مسئول این موضوع است.
از تمرین من: هنگام انتقال از یک سیستم قدیمی به یک سیستم جدید، ما به عنوان توسعه دهنده باید شناسه های سیستم قدیمی را ذخیره کنیم تا با آن کار کنیم و خودمان را ایجاد کنیم. چرا خودتان بسازید و از قدیمی ها استفاده نکنید؟ آنها ممکن است به اندازه کافی منحصر به فرد نباشند، یا این رویکرد برای ایجاد شناسه ممکن است دیگر مرتبط و محدود نباشد. برای این منظور، ID-name قدیمی را نیز در جدول منحصر به فرد ساختیم. برای بررسی این مورد، باید داده ها را اضافه کنید. یک کتاب و نویسنده اضافه کنید: NSERT INTO book (name) VALUES ("book1"); INSERT INTO نویسنده (نام) VALUES ("author1"); ما قبلاً از مقالات قبلی می دانیم که آنها دارای شناسه های 1 و 1 هستند. بنابراین، می توانیم بلافاصله یک رکورد به جدول سوم اضافه کنیم: INSERT INTO authors_x_books VALUES (1,1); و همه چیز درست می شود تا زمانی که بخواهیم دستور آخر را دوباره تکرار کنیم: یعنی دوباره همان شناسه ها را بنویسیم: "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 7نتیجه طبیعی خواهد بود - یک خطا. تکراری وجود خواهد داشت. ورودی ثبت نخواهد شد. به این ترتیب یک اتصال چند به چند ایجاد خواهد شد... همه اینها بسیار جالب و جالب است، اما یک سوال منطقی پیش می آید: چگونه می توان این اطلاعات را به دست آورد؟ چگونه داده های جداول مختلف را با هم ترکیب کنیم و یک پاسخ به دست آوریم؟ این همان چیزی است که در قسمت بعدی در مورد آن صحبت خواهیم کرد))

اتصالات (پیوستن)

در قسمت قبل شما را آماده کردم تا فوراً متوجه شوید که اتصالات چیست و کجا از آنها استفاده کنید. زیرا من عمیقاً متقاعد شده ام که به محض درک ، همه چیز بلافاصله بسیار ساده می شود و همه مقالات در مورد پیوستن به چشم یک کودک واضح می شود :D به طور کلی و به طور کلی ، پیوستن ها از چندین جدول نتیجه می گیرند. از یک JOIN (پیوستن از انگلیسی join). و این همه است...) و برای پیوستن، باید فیلدی را مشخص کنید که جداول توسط آن به هم متصل می شوند. شیطان به اندازه نقاشی ترسناکش نیست، درست است؟) بعد، ما فقط در مورد انواع اتصالات و نحوه استفاده از آنها صحبت خواهیم کرد. انواع مختلفی از اتصال وجود دارد و ما همه آنها را در نظر نخواهیم گرفت. فقط اونایی که واقعا بهشون نیاز داریم به همین دلیل است که ما علاقه ای به پیوندهای عجیب و غریب مانند Cross و Natural نداریم. من کاملاً فراموش کردم ، باید یک نکته ظریف دیگر را به خاطر بسپاریم: جداول و فیلدها می توانند نام مستعار داشته باشند - نام مستعار. آنها به راحتی برای اتصال استفاده می شوند. به عنوان مثال، می توانید این کار را انجام دهید: SELECT * FROM table1; اگر پرس و جو اغلب از table1 استفاده می کند، می توانید به آن یک نام مستعار بدهید: SELECT* FROM table1 به عنوان t1; یا حتی نوشتن آسان تر: SELECT * FROM table1 t1; و بعداً در پرس و جو امکان استفاده از t1 به عنوان نام مستعار برای این جدول وجود خواهد داشت.

پیوستن داخلی

رایج ترین و ساده ترین اتصال. می گوید که وقتی دو جدول و یک فیلد داریم که می توان آن را به هم متصل کرد، تمام رکوردهایی که روابط آنها در دو جدول وجود دارد انتخاب می شوند. گفتنش به نوعی سخت بود. بیایید به یک مثال نگاه کنیم: بیایید یک رکورد به پایگاه داده شهرهای خود اضافه کنیم. یک ورودی برای شهرها و یکی برای کشورها: $ INSERT INTO country VALUES(5, "Uzbekistan", 34036800); و $ INSERT INTO city (نام، جمعیت) VALUES ("Tbilisi", 1171100); ما کشوری را اضافه کردیم که شهری در جدول ما ندارد و شهری که با کشوری در جدول ما مرتبط نیست. بنابراین، INNER JOIN درگیر صدور تمام رکوردها برای اتصالاتی است که در دو جدول هستند. وقتی می‌خواهیم دو جدول table1 و table2 را به هم بپیوندیم، نحو کلی به این شکل است: SELECT * FROM table1 t1 جدول پیوستن داخلی2 ON t1.id = t2.t1_id; و سپس تمام رکوردهایی که در دو جدول دارای رابطه هستند برگردانده می شوند. برای مورد ما، وقتی می‌خواهیم اطلاعاتی را برای کشورها به همراه شهرها دریافت کنیم، به این صورت می‌شود: $ SELECT * FROM city ci INNER JOIN country co ON ci.country_id = co.id; "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 8در اینجا، اگرچه نام ها یکی است، اما به وضوح می توان دید که اول رشته های شهرها است، سپس رشته های کشورها. اما دو ورودی که در بالا اضافه کردیم وجود ندارد. زیرا JOIN داخلی دقیقاً اینگونه عمل می کند.

چپ پیوستن

مواردی وجود دارد و اغلب اوقات، به دلیل اینکه هیچ رکوردی برای آن در جدول مجاور وجود ندارد، از دست دادن فیلدهای جدول اصلی راضی نیستیم. LEFT JOIN برای همین است. اگر در درخواست قبلی به جای INNER، LEFT را مشخص کنیم، شهر دیگری را در پاسخ اضافه می کنیم - تفلیس: $ SELECT * FROM city ci LEFT JOIN country co ON ci.country_id = co.id; "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 9یک ورودی جدید در مورد تفلیس وجود دارد و هر چیزی که به این کشور مربوط می شود باطل است . اغلب این روش استفاده می شود.

راست بپیوندید

در اینجا تفاوتی با LEFT JOIN وجود خواهد داشت که همه فیلدها نه در سمت چپ، بلکه در سمت راست در اتصال انتخاب می شوند. یعنی نه شهرها، بلکه همه کشورها گرفته می شوند: $ SELECT * FROM city ci RIGHT JOIN country co ON ci.country_id = co.id; "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 10اکنون مشخص است که در این صورت تفلیس وجود نخواهد داشت، اما ازبکستان را خواهیم داشت. یه چیزی شبیه اون…))

ایمن سازی پیوستن ها

اکنون می‌خواهم یک عکس معمولی را به شما نشان دهم که نوجوانان قبل از مصاحبه می‌چینند تا آنها را متقاعد کنم که ماهیت پیوندها را درک می‌کنند: "پروژه جاوا از A تا Z": ما پایگاه های داده و زبان SQL را تجزیه و تحلیل می کنیم. قسمت 5 - اتصالات و اتصالات - 11در اینجا همه چیز به شکل مجموعه نشان داده می‌شود، هر دایره یک جدول است. و آن جاهایی که روی آن رنگ آمیزی می شود، قسمت هایی هستند که در SELECT نشان داده می شوند. بیایید نگاه بیندازیم:
  • JOIN داخلی فقط تقاطع مجموعه ها است، یعنی آن رکوردهایی که به دو جدول - A و B متصل هستند.
  • LEFT JOIN تمام رکوردهای جدول A است، از جمله تمام رکوردهای جدول B که دارای یک تقاطع (اتصال) با A هستند.
  • RIGHT JOIN دقیقاً برعکس LEFT JOIN است - همه رکوردهای جدول B و رکوردهای A که رابطه دارند.
بعد از همه اینها، این عکس باید واضح باشد))

مشق شب

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

وظیفه واقعی:

  1. یک اسکریپت SQL بنویسید تا جدول "Student" را با فیلدهای زیر ایجاد کنید: id (کلید اصلی)، نام، نام خانوادگی، ایمیل (یکتا).
  2. یک اسکریپت SQL بنویسید تا جدول «کتاب» با فیلدهای زیر ایجاد شود: شناسه، عنوان (id + عنوان = کلید اصلی). «Student» و «Book» را با یک رابطه «Student» یک به چند «کتاب» پیوند دهید.
  3. یک اسکریپت SQL بنویسید تا جدول "Teacher" را با فیلدهای زیر ایجاد کنید: id (کلید اصلی)، نام، نام خانوادگی، ایمیل (یکتا)، موضوع.
  4. «دانش‌آموز» و «معلم» را با یک رابطه «دانش‌آموز» چند به چند معلم پیوند دهید.
  5. "Student" را انتخاب کنید که "oro" در نام خانوادگی خود دارد، برای مثال "Sid oro v"، "V oro novsky".
  6. از جدول 'Student' همه نام‌های خانوادگی ('last_name') و تعداد تکرارهای آنها را انتخاب کنید. در نظر بگیرید که نام هایی در پایگاه داده وجود دارد. مرتب سازی بر اساس مقدار به ترتیب نزولی. می بایست شبیه به این باشه:
    نام خانوادگی تعداد
    پتروف 15
    ایوانف 12
    سیدوروف 3
  7. 3 نام برتر را که بیشترین تکرار را دارند از "Student" انتخاب کنید. مرتب سازی بر اساس مقدار به ترتیب نزولی. می بایست شبیه به این باشه:
    نام تعداد
    اسکندر 27
    سرگئی 10
    پیتر 7
  8. "دانش آموزان" را که بیشترین تعداد "کتاب" و "معلم" مرتبط را دارند انتخاب کنید. بر اساس تعداد به ترتیب نزولی مرتب کنید. می بایست شبیه به این باشه:
    نام خانوادگی معلم نام خانوادگی دانش آموز مقدار کتاب
    پتروف سیدوروف 7
    ایوانف اسمیت 5
    پتروف کانکاوا 2>
  9. «معلمی» را که بیشترین تعداد «کتاب» را از بین همه «دانش‌آموز» خود دارد، انتخاب کنید. مرتب سازی بر اساس مقدار به ترتیب نزولی. می بایست شبیه به این باشه:
    نام خانوادگی معلم مقدار کتاب
    پتروف 9
    ایوانف 5
  10. "معلم" را انتخاب کنید که تعداد "کتاب" برای همه "دانشجو" او بین 7 تا 11 باشد. مرتب سازی بر اساس مقدار به ترتیب نزولی. می بایست شبیه به این باشه:
    نام خانوادگی معلم مقدار کتاب
    پتروف یازده
    سیدوروف 9
    ایوانف 7
  11. تمام "نام_نام_طبیعی" و "نام" همه "معلم" و "دانش‌آموز" را با فیلد "نوع" (دانش‌آموز یا معلم) چاپ کنید. به ترتیب حروف الفبا بر اساس «نام_نام خانوادگی» مرتب کنید. می بایست شبیه به این باشه:
    نام خانوادگی نوع
    ایوانف دانشجو
    کانکاوا معلم
    اسمیت دانشجو
    سیدوروف معلم
    پتروف معلم
  12. یک ستون "نرخ" را به جدول "دانشجو" موجود اضافه کنید، که درسی را که دانشجو در حال حاضر در آن است ذخیره می کند (مقدار عددی از 1 تا 6).
  13. این مورد الزامی نیست، اما یک مزیت خواهد بود. تابعی بنویسید که تمام «کتابها» را طی کند و همه «عناوین» را که با کاما از هم جدا شده اند، خروجی دهد.

نتیجه

سری در مورد پایگاه داده کمی طولانی شده است. موافق. با این حال، راه درازی را پیموده ایم و در نتیجه با علم به موضوع ظهور می کنیم! از همه شما متشکرم که مطالعه کردید، به شما یادآوری می کنم که همه کسانی که می خواهند پروژه را ادامه دهند و دنبال کنند باید یک حساب کاربری در GitHub ایجاد کنند و در حساب من مشترک شوند :) بیشتر در راه است - بیایید در مورد Maven و Docker صحبت کنیم. با تشکر از همه برای خواندن. یک بار دیگر تکرار می‌کنم: کسی که راه می‌رود بر جاده مسلط می‌شود ;)

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

نظرات
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION