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

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

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

релационни

Фиг. един

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

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

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

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

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

маса 1

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

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

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

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

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

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

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