Въведение в релационната база данни на MySQL:
Концептуално релационната база данни не е нищо друго, освен поддържането изисква връзка между няколко таблици, като се използва някаква основна, уникална или чужда ключова концепция. Всяка база данни, която практически следва този подход и поддържа правилна връзка между всички създадени таблици, тогава тази база данни може да се счита за релационна база данни винаги. Релационната база данни MySQL също следва същата релационна структура, така че няма съмнение, че моят SQL също се счита за сървърна релационна база данни, докато терминът „отношение“ не е споменат в MySQL документи или не. Основна база данни, която няма понятие за релационна база данни, всяка таблица съдържа много данни, включително транзакционни и master и двете, разбирането на логическото обвързване на тези данни ще бъде много трудно, без да се знае правилната бизнес логика. Релационните бази данни гарантират този подход.
Система за контрол на отношенията на релационна база данни MySQL:
От конкретното определение на релационната база данни хората смятат, че е твърде критично за поддържане и ще създадат объркване. Но това не е вярно твърдение, основният дневен ред на релационната база данни, за да се избегне всякакъв вид объркване или усложнения между множество таблици, свързани с тази конкретна база данни, където той помага на програмиста да поддържа и проверява лесно без никаква борба. Ако разгледаме всеки релационен дизайн, който е много често срещан и поддържа строга връзка между всички свързани таблици, дефинирани в базата данни. Да предположим, че можем да разгледаме една система за контрол на инвентаризацията - в този случай трябва да поддържаме една много строга връзка между всички таблици, които участват с дадено повече описание, свързано с инвентара. Също така, тя трябва да поддържа по-строги взаимоотношения с онези дъщерни таблици, които допълнително са повлияни за всякакъв вид дейност за манипулиране на данни като вмъкване или изтриване от този конкретен инвентар. Като примери ще разгледаме три таблици, които участват в системата за контрол на инвентара, като приемем, че три са взаимосвързани.
Име на таблицата: Опис
| Идентификационен номер (първичен ключ) | описание | Цена | Наличност |
Име на таблицата: Sales_Staff
| Идентификационен номер (първичен ключ) | име | електронна поща | контакт |
Име на таблицата: Фактура
| Идентификационен номер (първичен ключ) | SalesStaff_ID (Външен ключ на Sales_Staff първичен ключ) | Inventory_ID (Външен ключ на първичния ключ на инвентара) | количество | Цена | коментар |
Като се има предвид горните три таблици, можем да планираме връзка между няколко таблици, като използваме първичен ключ и ограничение на чужд ключ. В горния пример, Фактура е основната таблица за транзакциите, където всички данни за транзакциите се съхраняват успешно за всяко генериране на фактура на отделен клиент или краен потребител, всъщност успешно съхраняват всички данни на фактурата за всякакъв вид справка. Сега фактурата трябва да генерира от някои детайли за инвентара, където е запаметено количество от цялото запитване за един цял магазин или организация. Сега като се имат предвид две ключови основни таблици като Inventory и Sales_Staff, и двете таблици поддържат основните данни за магазина за всеки конкретен артикул в този магазин или организация, докато Sales_Staff поддържа всички подробности за персонала, които работят в този магазин или организация. Вместо да поддържа един и същ персонал или конкретен артикул всеки път в подробности за транзакциите на инвентара, той всъщност държи една специфична справка за тези главни таблици, които се поддържат от някой администратор на магазина или организацията. Така че чрез този специфичен подход лесно можем да избегнем излишък на данни или повторение на данни, което винаги помага да се получат данни въз основа на поддържана връзка между множество таблици. Този пример даде една ключова характеристика на всяка релационна база данни като релационна база данни MySQL, която предполага, че една фактура данни винаги съдържа референцията на конкретен персонал за инвентаризация и продажби, но персоналът по продажбите или продажбите никога не могат да променят или актуализират нищо в създадената фактура.
Така че тук всъщност се поддържат връзки от един към много, при които една информация за инвентаризация може да съществува във фактура многократно, а същите данни за персонала по продажбите могат да съществуват във фактура за няколко пъти. Тази връзка помага на програмиста за извличане на данни безпроблемно със специфично условие за присъединяване, а също така разбиране или проектиране на всяка ER диаграма ще бъде много лесно за тях. Ето и един ключов момент, който трябва да споменем, да предположим, че всеки продавач, който се опитва да продаде нещо, което е в наличност, което също е осигурено чрез поддържане на този вид взаимоотношения. Както всеки път във фактурата ще бъде добавен някакъв инвентар, той автоматично изважда запасите от първоначалния инвентар, така че винаги ще предоставя правилно съобщение за валидиране, когато лицето, продаващо се опитва да създаде някакъв вид фактура за конкретен инвентар. Ако погледнем отблизо тези отношения на таблицата, тогава Инвентаризацията има едно име на първичен ключ е Id, а Sales_Staff имат едно име на първичен ключ е ID, но фактурата има два чужди ключа, които всъщност поддържат връзката с таблиците Inventory и Sales_Staff. Той също така гарантира, че може да се вмъкне каквото и да е в таблицата с фактури, която действително съществува в таблицата с инвентаризация или с продажби, без наличието на конкретни данни, не е възможно да се направи един запис в таблицата с фактури. Тъй като таблицата с фактури има една специфична връзка с външен ключ с двете таблици, така че всичко съществуващо само тези таблици може да може да направи записа в таблицата с фактури. Така че винаги помага на програмист в случай, че направи някаква грешна вмъкване, без да поддържа тези данни на дъщерните таблици.
Ръководство за инсталиране и изтегляне на My SQL Relational Database:
В интернет има много видове версии за инсталиране на MySQL във вашия локален компютър, но MySQL организация идва с една много интересна функция с безплатна извадка от релационна база данни, имат възможност за сортиране на методи, които са по-напреднали от други безплатни проби от релационна база данни, може да даде възможност за съхранение на филмови данни, един от ключовите моменти е безобидно потребителско изживяване, означава да предположим, че един потребител по някакъв начин направи някаква грешка, затова базата данни изцяло не работи, в този случай е много лесно или може да се каже 2 минути задача за възстановяване тази база данни от източника.
1. Изтеглете релационната база данни MySQL от линка по-долу:
- http://downloads.mysql.com/docs/sakila-db.tar.gz
2. Изпълнение по-долу скрипт за разопаковане на архивния пакет:
- катран –xzf xxxx-db.tar.gz
3. След като разопаковате същото, той ще създаде 3 директории като по-долу:
- XXXX / sakila-db.sql
- Sakila-schema.sql
- Sakila.mwb
4. Сега изпълнете MySQL основната команда:
- Mysql –p (парола)
5. Сега просто следвайте указанията, споменати в sakila-db.sql и sakila-schema.sql.
6. Ако всички инструкции следват правилно, тогава ще бъде създадена една нова база данни с името „sakila“, която ще бъде автоматично показана в списъка с релационни бази данни MySQL.
Препоръчителни статии
Тази статия е ръководство за релационна база данни MySQL. Тук сме обсъдили системата за контрол на отношенията и ръководството за инсталиране на релационна база данни MySQL. Можете също да разгледате следната статия, за да научите повече
- Въпроси и отговори за интервю за RDBMS
- Топ-най-различни разлики между MySQL и NoSQL
- Използване на Cheat Sheet MySQL
- Въпроси за интервю за СУБД