Основите на Добрия Дизайн на Бази от Данни за Уеб Разработка

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

В тази статия ние ще обхванем основите на това как да проектираме добър план за база от данни, без значение от крайното и предназначение. За всички разработки на бази от данни има пакет от стандартни правила и добри практики, които да бъдат следвани, които могат да допринесат за това базата от данни да бъде организирана и да се сработи със съответния сайт по-ефективно.

Каква функционалност е нужна от базата данни?

Първият метод на планиране за база от данни е да избистрим, на хартия или по друг начин, какво точно трябва да съхранява базата от данни и какво уеб сайтът ще търси от нея. Опитайте се за сега да не мислите за индивидуалните полета или таблици, който ще бъдат нужни – цялото това специфично планиране ще бъде на по-късен етап. Целта е да започнем с голямата, цялостна картина и да стесняваме до все по-дребни и дребни детайли. Много често е по-трудно да се добави по-късно, отколкото да бъде направено правилно от първия път.

Мислете извън базата от данни. Опитайте се да мислите за това какво уеб сайта ще трябва да прави. Например, ако е нужен уеб сайт, в който ще се регистрират потребители, първият инстинкт може да бъде да се замислите за всичката информация, която трябва всеки потребител да съхрани. Забравете за това, оставете го за по-късно. По-добре запишете, че потребителите и тяхната информация трябва да бъде съхранена в базата от данни. Друго? Какво друго ще трябва да правят в уеб сайта тези потребители? Ще пишат статии, ще качват файлове или снимки, или ще изпращат съобщения? Тогава базата от данни ще има нужда от място за файлове/снимки, статии и съобщения.

Каква информация ще имат нужда те да получават от уеб сайта? Ще имат ли нужда да търсят тяхната любима рецепта, да достъпват потребителско съдържание, достъпно само за регистрирани потребители или да търсят продукти и техните последни покупки? Тогава базата от данни ще има нужда от място, за да съхранява тези рецепти, място за съдържание, което да е дефинирано само за регистрирани потребители или не, или да съхранява всички продукти и да създаде метод за свързване на определени продукти към определени потребители.

Определяне на Таблици и Полета

Следващата фаза би била да започнем да определяме точно какви таблици и полета ще бъдат нужни в базата от данни. Това е основата на дизайна на бази от данни и най-трудната част. Използването на правилния метод за свързване на таблиците помежду им, правилното съхранение на информацията в таблиците и групирането или умишленото им разделяне са все назряващи проблеми, когато става въпрос за дизайн на бази от данни. Към този момент е добре да се опишат известните към момента таблици и полета, като се опитваме да бъдем колкото се може по-конкретни. През този процес, артикулите могат да бъдат пренаредени или реорганизирани, за да се подобри ефективността и сигурността на базата от данни.

Използвайте инструмент за моделиране на данни

Сега, след като знаете какво сайтът ще трябва да прави, дойде време да организираме точната информация, която трябва да бъде съхранена. Един добър инструмент за моделиране на бази от данни може да ни бъде само от полза, конкретно такъв, който може да ни помогне да изградим визуални модели на базите от данни, като например MySQL Workbench или DBDesigner4. Gliffy също е чудесно безплатно онлайн приложение за създаване на модели на бази от данни.

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

Релационните (свързаните) бази от данни

Почти всички бази от данни са релационни (свързани) бази от данни. Това означава, че таблиците в една база от данни са свързани една с друга по някакъв начин. Например, ако имате потребител на уеб сайт за електронна търговия, този потребител може да е свързан с определени продукти, на базата на това какво са поръчали последно или какво са посочили, че ги интересува. За база от данни на блог, авторите трябва по някакъв начин да бъдат свързани със статиите, които са написали, а вписаните в уеб сайта потребители могат да бъдат свързани с коментарите, които са оставили.

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

Всеки запис във всяка таблица се нуждае от основен ключ. Това е „Единния Граждански Номер“ или „бар код“ за всеки запис. Той е уникален за всеки запис и никой друг запис не може да има същия ID в същата таблица. Уникалните потребителски имена или наименования на продукти не са достатъчни. Далеч по-ефективно е, а също е и най-добра практика, да се използват уникални основни ключове. Дори с други видове уникални полета, базата от данни все още е уязвима към дублирани записи, които по-късно да повредят кода в уеб сайта.

За да свържем две таблици ние използваме външен ключ, който е обикновено число ID свързващо уникален ключ в друга таблица, обикновено нашият основен ключ. Като пример, по-долу може да видим, че нашата първа таблица за автори има трима автори с техни уникални ID. В отделната таблица за статии, ние свързваме всяка статия с автор чрез това ID. Сега можем да открием автора на конкретна статия и обратно, всички статии на даден автор. Вижте, че Том има две статии, Мери има една, а Джейн все още няма написана статия.

Това е прост пример за връзка в модела един-към-един . Също така има модели един-към-много и много-към-много.

Групиране или разделяне на информацията в полета

Много е важно да знаем кога да групираме определени части от информацията заедно и кога да я държим разделена. Добър начин да определим коя информация би могла да бъде в едно поле или не е да мислим за това какво би било необходимо, за да я променим, ако е необходимо. Например, би ли било необходимо да поставим целия адрес в отделни полета, базирано на 1) улица, 2) квартал, 3) град, 4) пощенски код и накрая 5) страна?

Съществено ли е за функционалността на сайта (може би потребителите или администраторите ще имат нужда да търсят адреси само по град) или ще бъде просто загуба на полета и пространство на базата от данни? Ако не е важно, просто за да промените адрес базата от данни ще трябва да обнови пет отделни полета, когато може да обнови само едно в стрингов формат. За да бъде запазен реда, потребителя може да въведе информацията посредством HTML форма с тези пет отделни полета, но те да бъдат съединени в един единствен низ преди да бъдат поставени като адрес в базата от данни.

Това е просто един пример, но винаги имайте едно наум и се старайте да организирате таблиците по най-ефективния начин, кога да ги комбинирате, кога да ги разделяте, всичко това в името на функционалността на уеб сайта.

Нормализиране на бази от данни

Нормализирането на бази от данни е група от напътствия създадени от общността за ефективно организиране на информация в бази от данни. Ние вече споменахме няколко от най-важните и основни практики, които са включени в някои от най-стандартни форми на нормализация. Има пет форми на нормализация и е добра идея да се запознаете с тях с цел да придържате всеки дизайн на бази от данни към най-добрите практики.

Нормализирането на бази от данни е доста голяма тема, но научаването на основите може да помогне ужасно много. За да прегледате всяка от формите на нормализация и основния поглед върху концепцията, можете да се отправите към Database Normalization Basics.

Заключение

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

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