Може да мислите, че поддръжката на база данни не е ваша работа. Но ако проектирате моделите си проактивно, получавате бази данни, които улесняват живота на тези, които трябва да ги поддържат.
Добрият дизайн на база данни изисква проактивност, добре оценено качество във всяка работна среда. В случай, че не сте запознати с термина, проактивността е способността да предвиждате проблеми и да имате готови решения, когато възникнат проблеми – или още по-добре, да планирате и действате така, че проблемите да не възникнат на първо място.
Работодателите разбират, че проактивността на техните служители или изпълнители е равна на спестяване на разходи. Ето защо те го ценят и защо насърчават хората да го практикуват.
Във вашата роля на модел на данни, най-добрият начин да демонстрирате проактивност е да проектирате модели, които предвиждат и избягват проблеми, които рутинно тормозят поддръжката на базата данни. Или поне това значително опростява решението на тези проблеми.
Дори и да не носите отговорност за поддръжката на база данни, моделирането за лесна поддръжка на база данни извлича много предимства. Например, той ви предпазва от обаждане по всяко време за решаване на спешни случаи с данни, които отнемат ценно време, което бихте могли да отделите за задачите по проектиране или моделиране, които толкова харесвате!
Улесняване на живота на ИТ момчетата
Когато проектираме нашите бази данни, трябва да мислим отвъд доставката на DER и генерирането на скриптове за актуализиране. След като базата данни влезе в производство, инженерите по поддръжката трябва да се справят с всякакви потенциални проблеми и част от задачата ни като моделисти на бази данни е да сведем до минимум шансовете за възникване на тези проблеми.
Нека започнем, като разгледаме какво означава да създадеш добър дизайн на база данни и как тази дейност е свързана с редовните задачи за поддръжка на база данни.
Какво е моделиране на данни?
Моделирането на данни е задачата за създаване на абстрактно, обикновено графично, представяне на информационно хранилище. Целта на моделирането на данни е да разкрие атрибутите и връзките между обектите, чиито данни се съхраняват в хранилището.
Моделите на данни се изграждат около нуждите на бизнес проблем. Правилата и изискванията се дефинират предварително чрез принос от бизнес експерти, така че да могат да бъдат включени в дизайна на ново хранилище на данни или адаптирани при повторение на съществуващо.
В идеалния случай моделите на данни са живи документи, които се развиват с променящите се бизнес нужди. Те играят важна роля в подкрепата на бизнес решенията и в системната архитектура и стратегия за планиране. Моделите на данни трябва да се поддържат в синхрон с базите данни, които представляват, така че да са полезни за рутините за поддръжка на тези бази данни.
Общи предизвикателства при поддръжка на база данни
Поддържането на база данни изисква постоянен мониторинг, автоматизиран или по друг начин, за да се гарантира, че няма да загуби своите предимства. Най-добрите практики за поддръжка на бази данни гарантират, че базите данни винаги запазват своите:
- Интегритет и качество на информацията
- Ефективност
- Наличност
- Мащабируемост
- Адаптивност към промени
- Проследимост
- Сигурност
Налични са много съвети за моделиране на данни, които да ви помогнат да създавате добър дизайн на база данни всеки път. Обсъдените по-долу имат за цел да осигурят или улеснят поддържането на качествата на базата данни, споменати по-горе.
Интегритет и качество на информацията
Основна цел на най-добрите практики за поддръжка на база данни е да се гарантира, че информацията в базата данни запазва своята цялост. Това е от решаващо значение за потребителите да запазят вярата си в информацията.
Има два вида интегритет:физическа цялост и логическа цялост .
Физическа цялост
Поддържането на физическата цялост на база данни се извършва чрез защита на информацията от външни фактори като хардуер или прекъсване на захранването. Най-разпространеният и широко приет подход е чрез адекватна стратегия за архивиране, която позволява възстановяването на база данни в разумно време, ако катастрофа я унищожи.
За администратори на база данни и администратори на сървъри, които управляват съхранението на база данни, е полезно да знаят дали базите данни могат да бъдат разделени на секции с различни честоти на актуализиране. Това им позволява да оптимизират използването на хранилището и плановете за архивиране.
Моделите на данни могат да отразяват това разделяне чрез идентифициране на области с различна „температура“ на данните и чрез групиране на обекти в тези области. „Температура“ се отнася до честотата, с която таблиците получават нова информация. Таблиците, които се актуализират много често, са „най-горещите“; тези, които никога или рядко се актуализират, са „най-студените“.
Модел на данни на система за електронна търговия, която разграничава горещи, топли и студени данни.
DBA или системен администратор може да използва това логическо групиране, за да раздели файловете на базата данни и да създаде различни планове за архивиране за всеки дял.
Логическа цялост
Поддържането на логическата цялост на база данни е от съществено значение за надеждността и полезността на информацията, която предоставя. Ако на база данни липсва логическа цялост, приложенията, които я използват, рано или късно разкриват несъответствия в данните. Изправени пред тези несъответствия, потребителите не се доверяват на информацията и просто търсят по-надеждни източници на данни.
Сред задачите за поддръжка на база данни, поддържането на логическата цялост на информацията е разширение на задачата за моделиране на база данни, само че тя започва след въвеждането на базата данни в производство и продължава през целия й живот. Най-критичната част от тази област на поддръжка е адаптирането към промените.
Управление на промените
Промените в бизнес правилата или изискванията са постоянна заплаха за логическата цялост на базите данни. Може да се почувствате доволни от модела на данни, който сте изградили, знаейки, че той е перфектно адаптиран към бизнеса, че отговаря с правилната информация на всяко запитване и че пропуска всякакви аномалии при вмъкване, актуализиране или изтриване. Насладете се на този момент на удовлетворение, защото той е краткотраен!
Поддръжката на база данни включва изправяне пред необходимостта от ежедневни промени в модела. Принуждава ви да добавяте нови обекти или да променяте съществуващите, да променяте кардиналността на връзките, да предефинирате първичните ключове, да променяте типовете данни и да правите други неща, които карат нас, моделистите, да треперим.
Промените се случват през цялото време. Възможно е някакво изискване да е било обяснено погрешно от самото начало, да са се появили нови изисквания или неволно да сте въвели някакъв недостатък във вашия модел (в края на краищата ние, моделиращите данни, сме само хора).
Вашите модели трябва да бъдат лесни за модифициране, когато възникне нужда от промени. От решаващо значение е да използвате инструмент за проектиране на база данни за моделиране, който ви позволява да версиите вашите модели, да генерирате скриптове за мигриране на база данни от една версия към друга и правилно да документира всяко решение за проектиране.
Без тези инструменти всяка промяна, която правите във вашия дизайн, създава рискове за целостта, които излизат наяве в най-неподходящите моменти. Vertabelo ви предоставя цялата тази функционалност и се грижи за поддържането на историята на версиите на модел, без дори да се налага да мислите за това.
Автоматичното управление на версиите, вградено във Vertabelo, е огромна помощ за поддържане на промени в модел на данни.
Управлението на промените и контролът на версиите също са решаващи фактори за вграждането на дейности по моделиране на данни в жизнения цикъл на разработка на софтуер.
Рефакторинг
Когато прилагате промени към използвана база данни, трябва да сте 100% сигурни, че не се губи информация и че нейната цялост не е засегната в резултат на промените. За да направите това, можете да използвате техники за рефакторинг. Те обикновено се прилагат, когато искате да подобрите дизайн, без да засягате неговата семантика, но могат да се използват и за коригиране на грешки в дизайна или адаптиране на модел към новите изисквания.
Има голям брой техники за рефакторинг. Те обикновено се използват, за да дадат нов живот на наследените бази данни и има процедури в учебниците, които гарантират, че промените няма да навредят на съществуващата информация. За това са написани цели книги; Препоръчвам ви да ги прочетете.
Но за да обобщим, можем да групираме техниките за рефакторинг в следните категории:
- Качество на данните: Извършване на промени, които гарантират последователност и съгласуваност на данните. Примерите включват добавяне на справочна таблица и мигриране към нея на данни, повторени в друга таблица, и добавяне на ограничение към колона.
- Конструктивно: Правене на промени в структурите на таблици, които не променят семантиката на модела. Примерите включват комбиниране на две колони в една, добавяне на заместващ ключ и разделяне на колона на две.
- Цялост на препратка: Прилагане на промени, за да се гарантира, че рефериран ред съществува в свързана таблица или че ред без препратка може да бъде изтрит. Примерите включват добавяне на ограничение за външен ключ към колона и добавяне на ограничение за стойност, различна от нула, към таблица.
- Архитектурно: Извършване на промени, насочени към подобряване на взаимодействието на приложенията с базата данни. Примерите включват създаване на индекс, правене на таблица само за четене и капсулиране на една или повече таблици в изглед.
Техниките, които променят семантиката на модела, както и тези, които не променят модела на данните по никакъв начин, не се считат за техники за рефакторинг. Те включват вмъкване на редове в таблица, добавяне на нова колона, създаване на нова таблица или изглед и актуализиране на данните в таблица.
Поддържане на качеството на информацията
Качеството на информацията в базата данни е степента, до която данните отговарят на очакванията на организацията за точност, валидност, пълнота и последователност. Поддържането на качеството на данните през целия жизнен цикъл на базата данни е жизненоважно за нейните потребители за вземане на правилни и информирани решения, използвайки данните в нея.
Вашата отговорност като модел на данни е да гарантирате, че вашите модели поддържат качеството на информацията си на възможно най-високо ниво. За да направите това:
- Дизайнът трябва да следва поне 3-тата нормална форма, така че да не възникват аномалии при вмъкване, актуализиране или изтриване. Това съображение се отнася главно за бази данни за транзакционно използване, където данните се добавят, актуализират и изтриват редовно. Той не се прилага строго в бази данни за аналитична употреба (т.е. складове за данни), тъй като актуализирането и изтриването на данни се извършва рядко, ако изобщо се случва.
- Типовете данни на всяко поле във всяка таблица трябва да са подходящи за атрибута, който представляват в логическия модел. Това надхвърля правилното дефиниране дали полето е от числов, дата или буквено-цифров тип данни. Също така е важно правилно да дефинирате диапазона и прецизността на стойностите, поддържани от всяко поле. Пример:атрибут от тип Date, внедрен в база данни като поле за дата/час, може да причини проблеми в заявките, тъй като стойност, съхранена с неговата времева част, различна от нула, може да попадне извън обхвата на заявка, която използва диапазон от време.
- Измеренията и фактите, които определят структурата на хранилището за данни, трябва да съответстват на нуждите на бизнеса. При проектирането на хранилище за данни размерите и фактите на модела трябва да бъдат дефинирани правилно от самото начало. Извършването на модификации, след като базата данни започне да работи, е свързана с много високи разходи за поддръжка.
Управление на растежа
Друго голямо предизвикателство при поддържането на база данни е предотвратяването на нейния растеж от неочаквано достигане на лимита за капацитет за съхранение. За да помогнете с управлението на пространството за съхранение, можете да приложите същия принцип, използван при процедурите за архивиране:групирайте таблиците във вашия модел според скоростта, с която нарастват.
Обикновено е достатъчно разделяне на две области. Поставете таблиците с чести добавяния на редове в една област, тези, към които рядко се вмъкват редове, в друга. Секторът на модела по този начин позволява на администраторите за съхранение да разделят файловете на базата данни според скоростта на растеж на всяка област. Те могат да разпределят дяловете между различни носители за съхранение с различен капацитет или възможности за растеж.
Групиране на таблици по техния темп на растеж помага да се определят изискванията за съхранение и да се управлява растежът му.
Регистриране
Създаваме модел на данни, очаквайки той да предостави информацията такава, каквато е в момента на заявката. Въпреки това, ние сме склонни да пренебрегваме необходимостта от база данни, която да помни всичко, което се е случило в миналото, освен ако потребителите изрично не го изискват.
Част от поддържането на база данни е да се знае как, кога, защо и от кого е била променена определена част от данни. Това може да е за неща като например да разберете кога се е променила цената на продукта или да прегледате промените в медицинския картон на пациент в болница. Регистрирането може да се използва дори за коригиране на потребителски грешки или грешки в приложението, тъй като ви позволява да върнете състоянието на информацията до момент в миналото, без да е необходимо да прибягвате до сложни процедури за възстановяване на резервно копие.
Отново, дори ако потребителите не се нуждаят от това изрично, предвид необходимостта от проактивно регистриране е много ценно средство за улесняване на поддръжката на база данни и демонстриране на способността ви да предвиждате проблеми. Наличието на данни за регистриране позволява незабавни отговори, когато някой трябва да прегледа историческа информация.
Има различни стратегии за модел на база данни за поддръжка на регистриране, като всички те добавят сложност към модела. Един подход се нарича регистриране на място, което добавя колони към всяка таблица за записване на информация за версията. Това е проста опция, която не включва създаване на отделни схеми или специфични за регистриране таблици. Това обаче оказва влияние върху дизайна на модела, тъй като оригиналните първични ключове на таблиците вече не са валидни като първични ключове – техните стойности се повтарят в редове, които представляват различни версии на едни и същи данни.
Друга възможност за запазване на информацията в журнала е използването на сенчести таблици. Таблиците в сянка са копия на таблиците на модела с добавяне на колони за записване на данни за проследяване на журнала. Тази стратегия не изисква промяна на таблиците в оригиналния модел, но трябва да запомните да актуализирате съответните сенчести таблици, когато промените своя модел на данни.
Друга стратегия е да се използва подсхема от общи таблици, които записват всяко вмъкване, изтриване или модификация на всяка друга таблица.
Общи таблици за поддържане на одитна пътека на база данни.
Тази стратегия има предимството, че не изисква модификации на модела за записване на одитна пътека. Въпреки това, тъй като използва общи колони от типа varchar, той ограничава типовете данни, които могат да бъдат записани в пътеката на журнала.
Поддръжка на производителността и създаване на индекс
Практически всяка база данни има добра производителност, когато току-що започва да се използва и нейните таблици съдържат само няколко реда. Но веднага щом приложенията започнат да го запълват с данни, производителността може да се влоши много бързо, ако не се вземат предпазни мерки при проектирането на модела. Когато това се случи, администраторите на база данни и системните администратори се обръщат към вас, за да им помогнете да разрешат проблеми с производителността.
Автоматичното създаване/предлагане на индекси в производствените бази данни е полезен инструмент за решаване на проблеми с производителността „в разгара на момента“. Машините за бази данни могат да анализират дейностите на базата данни, за да видят кои операции отнемат най-дълго и къде има възможности за ускоряване чрез създаване на индекси.
Въпреки това е много по-добре да бъдете проактивни и да предвиждате ситуацията, като дефинирате индекси като част от модела на данните. Това значително намалява усилията за поддръжка за подобряване на производителността на базата данни. Ако не сте запознати с предимствата на индексите на базата данни, предлагам да прочетете всичко за индексите, като започнете от самите основи.
Има практически правила, които предоставят достатъчно насоки за създаване на най-важните индекси за ефективни заявки. Първият е да генерирате индекси за първичния ключ на всяка таблица. На практика всяка RDBMS генерира индекс за всеки първичен ключ автоматично, така че можете да забравите за това правило.
Друго правило е да се генерират индекси за алтернативни ключове на таблица, особено в таблици, за които е създаден сурогатен ключ. Ако дадена таблица има естествен ключ, който не се използва като първичен ключ, заявките за присъединяване към тази таблица с други много вероятно правят това с естествения ключ, а не с сурогата. Тези заявки не работят добре, освен ако не създадете индекс на естествения ключ.
Следващото правило за индексите е да ги генерирате за всички полета, които са външни ключове. Тези полета са чудесни кандидати за установяване на връзки с други таблици. Ако са включени в индекси, те се използват от анализаторите на заявки за ускоряване на изпълнението и подобряване на производителността на базата данни.
И накрая, добра идея е да използвате инструмент за профилиране в етапна или QA база данни по време на тестове за производителност, за да откриете всякакви възможности за създаване на индекс, които не са очевидни. Включването на индексите, предложени от инструментите за профилиране, в модела на данни е изключително полезно за постигане и поддържане на производителността на базата данни, след като тя е в производство.
Сигурност
В ролята си на модел на данни, вие можете да помогнете за поддържането на сигурността на базата данни, като осигурите солидна и сигурна база, в която да съхранявате данни за удостоверяване на потребителя. Имайте предвид, че тази информация е силно чувствителна и не трябва да бъде изложена на кибератаки.
За да опростите поддръжката на сигурността на базата данни, следвайте най-добрите практики за съхранение на данни за удостоверяване, основната сред които е да не съхранявате пароли в базата данни дори в криптиран вид. Съхраняването само на неговия хеш вместо паролата за всеки потребител позволява на приложение да удостовери потребителско влизане, без да създава риск от излагане на парола.
Пълна схема за удостоверяване на потребителя, която включва колони за съхранение на хешове на пароли.
Визия за бъдещето
Така че, създайте своите модели за лесна поддръжка на база данни с добър дизайн на база данни, като вземете предвид съветите, дадени по-горе. С по-поддържани модели на данни работата ви изглежда по-добре и вие печелите оценката на администраторите на база данни, инженерите по поддръжката и системните администратори.
Вие също инвестирате в спокойствие. Създаването на лесно поддържани бази данни означава, че можете да прекарате работните си часове в проектиране на нови модели на данни, вместо да вървите наоколо да коригирате бази данни, които не успяват да предоставят правилна информация навреме.
