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

Базите данни са навсякъде: от простички блогове и директории до надеждни информационни системи и големи социални мрежи. Важно е не толкова дали базата данни е проста или сложна, а колко добре е проектирана. Когато базата е създадена без ясна идея и цел, тя не само не е ефективна, но и работата с нея става истинско мъчение, непроходима гора за потребителите. Ето няколко съвета за проектиране на бази данни, които ще помогнат за създаването на полезен и лесен за ползване продукт.
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
