Проектиране на бази данни. Най-добри практики

В навечерието на старта на поредния поток по курса «Бази данни» подготвихме малък авторски материал с важни съвети за проектиране на БД. Надяваме се този материал да е полезен за вас.

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

1. Определете за какво е таблицата и каква е нейната структура

Днес методи на разработка като Scrum или RAD (бърза разработка на приложения) помагат на ИТ екипите бързо да проектират бази данни. Въпреки това, в стремежа към време, изкушението да се потопите направо в изграждането на базата, без ясно разбиране за целта и крайния резултат, е голямо.
 
Като че ли екипът е насочен към ефективна, бърза работа, но това е мираж. Колкото по-дълбоко и по-бързо се потапяте в проекта, толкова повече време ще е нужно, за да идентифицирате и поправите грешките в проекта на базата.

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

Колкото по-рано екипът по проектиране отговори на тези въпроси, толкова по-гладко и плавно ще протече процесът на проектиране на базата данни.

2. Какви данни да изберете за съхранение?

Планирайте предварително. Помислете за това какво в бъдеще ще прави сайтът или системата, за която се проектира базата данни. Важно е да излезете извън рамките на простите изисквания на техническото задание. Но моля, не започвайте да размишлявате веднага за всички възможни типове данни, които потребителят някога ще съхранява. По-добре помислете дали потребителите ще могат да пишат постове, да качват документи или снимки, или да обменят съобщения. Ако да, то в базата трябва да се предвиди място за тях.

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

Неизбежно потребностите на потребителите дори в рамките на един департамент ще бъдат конфликтни. Ако се сблъскате с това, не се страхувайте да опрете на собствения си опит и да намерите компромис, който да задоволи всички страни и да отговаря на крайната цел на БД. Бъдете уверени: в бъдеще ще получите +100500 в кармата и куп бисквити.

3. Моделирайте данните внимателно

Има няколко ключови момента, на които трябва да обърнете внимание при моделирането на данни. Както вече споменахме, от целта на базата данни зависи какви методи да използвате при моделирането. Ако проектираме база данни за оперативна обработка на записи (OLTP), с други думи за тяхното създаване, редактиране и изтриване, тогава използваме моделиране на транзакции. Ако обаче базата данни трябва да бъде релационна, най-добре е да се прилага многомерно моделиране.

По време на моделирането се изграждат концептуални (CDM), физически (PDM) и логически (LDM) модели на данните. 

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

Ако елементът е много трудно да се класифицира с една дума или фраза, е време да се използват подтипове (дъщерни елементи).

Ако същността води собствен живот, има атрибути, които описват поведението и вида ѝ, както и отношенията с други обекти, смело можете да използвате не само подтип, но и супертип (родителска същност). 

Ако пренебрегнете това правило, други разработчици ще се объркат във вашата модел и няма да разберат напълно данните и правилата за тяхното събиране.

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

След това логическата модел на данните се съпоставя с предварително избраната платформа на СУБД (системи управление на бази данни) и се получава физическа модел. Той описва начина на физическо съхранение на данните.

4. Използвайте подходящи типове данни

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

Създавайте минимум празни колони с NULL стойности. Ако създавате всички колони като NULL, това е груба грешка. Ако обаче ви трябва празна колона, за да изпълнява конкретна бизнес функция, когато данните са неизвестни или все още нямат смисъл, смело я създавайте. В крайна сметка, не можем предварително да запълним колоните “Дата на смърт” или “Дата на уволнение”, ние не сме предсказатели да сочим на посоки в неясното :-).

Повечето софтуерни инструменти за моделиране (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) позволяват създаването на прототипи на области от данни. Така е гарантирано не само правилното типизиране на данните, логиката на приложението и добра производителност, но и задаване на задължителни стойности.

5. Предпочитайте естественото

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

Най-добре е да използвате естествен или бизнес ключ (natural key). Той има смислово значение, така че ще избегнете дублиране в базата данни. 

Ако бизнес ключът не е уникален (име, фамилия, позиция) и се повтаря в различни редове в таблицата или трябва да се променя, то първичният ключ трябва да бъде определен като генериран изкуствен, сурогатен ключ (artificial key).

6. Нормализирайте в умерени количества

За да организирате данните в БД ефективно, е необходимо да следвате набор от насоки и да нормализирате базата данни. Има пет нормални форми, които трябва да следвате.
С помощта на нормализацията ще избегнете излишността и ще осигурите целостта на данните, използвани в приложението или на сайта.

Както винаги, всичко трябва да бъде в разумни граници, дори и нормализацията. Ако в БД има твърде много таблици с еднакви уникални ключове, значи сте прекалили и излишно сте нормализирали базата данни. Прекомерната нормализация неблагоприятно влияе на производителността на базата данни.

7. Тествайте по-рано, тестувайте по-често

Тестовият план и правилното тестване трябва да бъдат част от проектирането на базата данни.

Най-добре е да тествате базата данни чрез Непрекъсната Интеграция (Continuous Integration). Моделирайте сценарий „Един ден от живота на базата данни“ и проверявайте дали всички гранични случаи се обработват, какви взаимодействия на потребителите са вероятни. Колкото по-рано откриете грешки, толкова повече ще спестите от време и средства.

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

Източник: habr.com