Релационни бази данни за манекени

По правило всяко уеб приложение може да бъде разделено на 2 основни части: преден край, където се показва цялата информация на сайта, и заден край, където тази информация се генерира и поставя. В тази статия ще говорим за това какво представляват релационните бази данни и как да ги проектираме.

Базата данни съхранява записите по специално организиран начин, така че информацията да може лесно да бъде намерена и извлечена. Всяка база данни се състои от една или повече таблици. Електронната таблица се състои от редове и колони. Всички редове имат еднакви колони и всяка колона съдържа данни. Като цяло, за по-добро разбиране, нека дефинираме, че таблиците в базата данни са много подобни на тези, които сте виждали в Excel.

Фиг. един

Табличните данни могат да се вмъкват, възстановяват, актуализират и изтриват. За пакета от тези операции беше създадено специално съкращение CRUD (Create-Read-Update-Delete).

Релационните бази данни са бази данни, при които цялата информация се съхранява в таблици, свързани помежду си чрез специални връзки. Тези взаимоотношения ни позволяват да извличаме и комбинираме данни от една или повече таблици с една заявка.

Но всичко това са само думи. За да разберете наистина какво представляват релационните бази данни, трябва да практикувате повече. Нека започнем и да видим с какви данни трябва да работим.

Стъпка 1: Подгответе данните

За да има с какво да работим, написах заявката „#databases“ в Twitter и оформих таблица от 10 записа:

маса 1

Първо, нека се справим с колоните:

пълно име: Потребителско име
потребителско име: Twitter вход
текст: текст за туит
created_at: време за създаване на туитове
след_потребителско име: разделен със запетая списък на потребители, които са следвали този туит. За краткост намалих този списък на 2 имена.

Това са реални данни. Можете да ги намерите и актуализирате, ако искате.

Добре. Сега всички наши данни са на едно място. Улеснява ли ни това да ги търсим? Не точно. Тази маса далеч не е идеална. Първо, в някои колони имаме дублиращи се записи: например в x "потребителско име" и "след_потребителско име". Също така, колоната next_username нарушава правилата на релационните модели, тъй като съдържа повече от 1 стойност в клетки (записите са разделени със запетаи).

Освен това в редовете срещаме дубликати.

Дублиращите се данни наистина са проблем, защото те правят процеса CRUD труден. Например при търсене в дадена таблица ще отнеме допълнително време за обработка на дубликати. Освен това, ако потребителят актуализира туит, ще трябва да презапишем всички дубликати.

Решението на този проблем е да се разделят Таблици 1 в множество таблици. Нека се справим с първия проблем, който е премахването на дублиращи се колони.

Стъпка 2: Отървете се от дублиращи се колони

Както беше посочено по-горе, колоните „потребителско име“ и „следно_потребителско име“ съдържат дублирани данни. Те се появиха, защото исках да покажа връзката между туитове и потребители. Нека подобрим структурата на нашата база данни, като разделим съществуващата таблица на две: в едната ще съхраняваме информация, а в другата - връзката между записите.

Фиг. 2

Тъй като @Brett_Englebert е абониран за @RealSkipBayless, тогава в таблицата „по-долу“ ще го покажем по следния начин: поставете името @Brett_Englebert в колоната „от_потребителя“ и @RealSkipBayless в „до_потребителя“. Нека да видим как ще изглежда таблицата „по-долу“ след разделянето Таблици 1:

Таблица 2: по-долу

Таблица 3: потребители

По-добре сега. Сега в таблицата „потребители“ (Таблица 3), ние съхраняваме само информация за туитове и следното (таблица 2) - потребителска зависимост.

Основателят на теорията на релационните бази данни, Едгар Код, ще извика този процес (премахване на дубликати от колони на таблици), намалявайки базата данни до първата нормална форма.

Стъпка 3: Премахнете дубликати от низове

Сега ще решим други проблеми, а именно да се отървем от дубликати в редовете на таблицата „потребители“. Тъй като потребителите @ AndyRyder5 и @Brett_Englebert са публикували по няколко туитове, имената им са в таблицата „потребители“ (Таблица 3) се дублират в колоната full_name. Този проблем се решава и чрез разделяне на таблицата "потребители".

Фиг. 3

Тъй като текстът на туита и времето, когато е създаден, са уникални данни, ние ще ги поставим в една и съща таблица. Също така трябва да уточним връзката между туитове и потребители. За това създадох специално потребителско име в колона:

Таблица 4: туитове

Таблица 5: потребители

След разделяне на потребителите (Таблица 5) имаме уникални (не повтарящи се) редове.

Този процес на премахване на дубликати от низове се нарича преобразуване на втора нормална форма.

Стъпка 4: присъединете се към таблици въз основа на ключове

И така, в резултат на нашите действия, маса 1 беше разделен на 3 части: след (таблица 2), туитове (Таблица 4), потребители (Таблица 5). Всички дубликати са премахнати. За да можем да извличаме лесно данни от тази структура в бъдеще, трябва да свържем независими таблици със специални връзки, които ще ни дадат информация за това кой потребител принадлежи към кой туит и кой е абониран за кого.

За да създадем връзки между записи, трябва да въведем уникален идентификатор, наречен първичен ключ.

Най-общо казано, в таблици 4 и 5 вече сме направили това. В таблицата „потребители“ първичният ключ е колоната „потребителско име“, тъй като потребителското име трябва да е уникална стойност и не може да се повтаря. В таблицата „туитове“ използваме този ключ, за да посочим връзката между потребител и туит. Колоната „потребителско име“ в таблицата „туитове“ се нарича външен ключ.

Ако някога сте работили с бази данни, може да имате въпрос: можем ли да използваме колоната „потребителско име“ като първичен ключ?

От една страна, това може да опрости процеса на търсене, защото не използваме никакви цифрови идентификатори. От друга страна, какво, ако потребителят иска да промени потребителското си име? Това може да доведе до огромен брой проблеми. За да не изпаднете в подобна ситуация, по-добре е да използвате цифрови идентификатори. Всичко зависи от вашата система. Ако предоставите на потребителите си възможност да променят данните за вход, по-добре е да използвате автоматично увеличаващо се числово поле ID като първичен ключ. В противен случай колоната „потребителско име“ е подходяща за тази роля. Ще го оставя както е.

Таблица 6: туитове с колона id