Вступ до реляційної бази даних MySQL:
Концептуально-реляційна база даних - це не що інше, як підтримка вимагає взаємозв'язку між декількома таблицями, використовуючи якусь основну, унікальну або зовнішню ключову концепцію. Будь-яка база даних, яка практично дотримується цього підходу та підтримує належні відносини між усіма створеними таблицями, тоді ця база даних завжди може вважатися реляційною базою даних. Реляційна база даних MySQL також має ту саму реляційну структуру, тому немає сумнівів, що мій SQL також розглядається як реляційна база даних сервера, тоді як термін "відношення" не згадується в документах MySQL чи ні. Основна база даних, яка не має жодного поняття реляційної бази даних, у кожній таблиці міститься багато даних, включаючи транзакційні та майстерні обидва, зрозуміти логічне прив'язування цих даних буде дуже важко, не знаючи належної логіки бізнесу. Реляційні бази даних забезпечують такий підхід.
Система управління відносинами реляційної бази даних MySQL:
З конкретного визначення реляційної бази даних люди думають, що це занадто критично для підтримання і створить плутанину. Але це не є правдивим твердженням, основний порядок денний реляційної бази даних, щоб уникнути будь-якої плутанини або ускладнень між декількома таблицями, пов'язаними з цією конкретною базою даних, де це допомагає розробнику легко підтримувати та перевіряти без будь-якої боротьби. Якщо ми розглянемо будь-яку реляційну конструкцію, яка є дуже поширеною, яка підтримує сувору залежність між усіма пов'язаними таблицями, визначеними в базі даних. Припустимо, ми можемо розглянути одну систему контролю запасів - у такому випадку ми маємо підтримувати одне дуже жорстке співвідношення між усіма таблицями, які брали участь у даному описі, пов'язаному з інвентаризацією. Крім того, потрібно підтримувати більш суворі стосунки з тими дочірніми таблицями, які додатково впливають на будь-яку діяльність з маніпулювання даними, наприклад, вставлення або видалення з цього конкретного інвентаря. В якості прикладів ми розглянемо три таблиці, які задіяні для системи контролю запасів, припустимо, що три взаємопов'язані.
Назва таблиці: Інвентар
| Ідентифікатор (первинний ключ) | Опис | Ціна | Запас |
Назва таблиці: Sales_Staff
| Ідентифікатор (первинний ключ) | Ім'я | Електронна пошта | контактний |
Назва таблиці: Рахунок-фактура
| Ідентифікатор (первинний ключ) | SalesStaff_ID (Іноземний ключ первинного ключа Sales_Staff) | Inventory_ID (Зовнішній ключ первинного ключа інвентаризації) | Кількість | Ціна | коментар |
Тепер, розглядаючи вищевказані три таблиці, ми можемо планувати взаємозв'язок між декількома таблицями, використовуючи обмеження первинного ключа та зовнішнього ключа. У наведеному вище прикладі Рахунок-фактура є основною таблицею транзакцій, де всі дані про трансакцію успішно зберігаються для кожного генерування рахунків-фактур на окремому клієнті або кінцевому споживачеві, вони фактично успішно зберігають усі дані рахунків для будь-якого типу довідки. Тепер рахунок-фактура повинен генеруватись із деяких деталей інвентаризації, де зберігається кількість всього запиту для одного цілого магазину чи організації. Тепер, розглядаючи дві ключові основні таблиці, такі як Інвентар та Продаж_Стафф, обидві таблиці містять основні відомості про магазин будь-якого конкретного товару в цьому магазині чи організації, тоді як Sales_Staff підтримує всі деталі персоналу, які працюють у цьому магазині чи організації. Замість того щоб підтримувати один і той же персонал або конкретний предмет кожен раз в інвентарях про транзакційні деталі, він фактично містить одне конкретне посилання на ті основні таблиці, які підтримує деякий адміністратор магазину чи організації. Таким чином, завдяки цьому специфічному підходу ми можемо легко уникнути надмірності даних або повторення даних, що завжди допомагає отримати дані на основі підтримуваного зв’язку між декількома таблицями. У цьому прикладі наведено одну ключову характеристику будь-якої реляційної бази даних, наприклад реляційну базу даних MySQL, яка передбачає, що одні дані рахунків завжди містять посилання конкретного інвентаря та торгового персоналу, але персонал з інвентаризації чи продажу ніколи не може нічого змінити чи оновити у створеному рахунку.
Таким чином, тут фактично підтримуються відносини один до багатьох, коли одні дані про запаси можуть існувати в Рахунку кілька разів, і ті самі дані торгового персоналу можуть існувати в Рахунку кілька разів. Цей взаємозв’язок, допомагаючи розробникові безперешкодно отримувати дані з конкретними умовами приєднання, а також розуміти або проектувати будь-яку діаграму ER буде для них дуже простим. Тут також є одним із ключових моментів, який слід згадати, припустимо, будь-яка продавець, яка намагається продати щось на складі, що також забезпечується підтримкою подібних відносин. Як і коли-небудь інвентар буде доданий у рахунку-фактурі, він автоматично віднімає запаси від первинного інвентарю, тому він завжди надасть належне повідомлення про підтвердження, коли продавець намагається створити будь-який рахунок-фактуру для конкретного товарного запасу. Якщо ми уважно подивимось на ці відносини таблиці, то в Інвентарі є одне ім'я первинного ключа Id, а у Sales_Staff одне ім'я первинного ключа - ID, але в рахунку-фактурі є два зовнішніх ключі, які фактично підтримують зв'язок із таблицями запасів та продажів-ставок. Він також забезпечує те, що в таблицю рахунків-фактур може бути вставлено все, що фактично існує в таблиці «Інвентар» або «Продаж_Staff», без наявності будь-яких конкретних даних, неможливо зробити один запис у таблиці рахунків-фактур. Оскільки таблиця рахунків-фактур має один специфічний зовнішній ключ із обома цими таблицями, тож будь-яка існуюча одна з цих таблиць може зробити запис у таблиці рахунків-фактур. Тож це завжди допомагає розробнику у випадку внесення помилкової вставки без збереження цих даних у дочірніх таблицях.
Керівництво встановленням та завантаженням моєї реляційної бази даних SQL:
В Інтернеті є багато видів версій для встановлення MySQL на вашому локальному ПК, але MySQL Organisation має одну дуже цікаву функцію з безкоштовним зразком реляційної бази даних, має можливість сортувати методи, які є більш досконалими, ніж інші безкоштовні зразки реляційної бази даних, це може дати можливість зберігати дані про фільми, один з ключових моментів - це нешкідливий досвід користувача, означає припустити, що один користувач якось помилиться, тому база даних повністю не працює, і в цьому випадку відновити відновлення дуже просто, або можна сказати, 2 хвилини. що база даних від джерела.
1. Завантажте реляційну базу даних MySQL за посиланням нижче:
- http://downloads.mysql.com/docs/sakila-db.tar.gz
2. Виконання нижче сценарію для розпакування архівного пакету:
- смола –xzf xxxx-db.tar.gz
3. Розпакувавши те саме, він створить 3 каталоги, як показано нижче:
- Xxxx / sakila-db.sql
- Сакіла-схема.sql
- Sakila.mwb
4. Тепер запустіть основну команду MySQL:
- Mysql –p (пароль)
5. Тепер просто дотримуйтесь інструкцій, згаданих у sakila-db.sql та sakila-schema.sql.
6. Якщо всі інструкції виконуються належним чином, тоді буде створена одна нова база даних з назвою “sakila”, яка автоматично відображатиметься у списку реляційних баз даних MySQL.
Рекомендовані статті
Ця стаття є посібником по реляційній базі даних MySQL. Тут ми обговорили систему управління відносинами та керівництво по встановленню реляційної бази даних MySQL. Ви також можете переглянути наступну статтю, щоб дізнатися більше
- RDBMS Інтерв'ю Питання та відповіді
- Найпопулярніші відмінності між MySQL та NoSQL
- Використання шпаргалки MySQL
- Питання для інтерв'ю СУБД