Съвети за по-добър дизайн на база данни

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

1. Планирайте напред

Неуспешното планиране означава провал.

Алан Лейкин

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

При разработването на приложения е изключително важно да се разбере естеството на данните.

Планирането често се игнорира, така че разработчиците да могат просто да „започват да кодират“. Проектът стартира и когато възникнат проблеми, няма забавяне в графика за разрешаването им. Разработчиците използват преки пътища с намерението да ги коригират по-късно, но това рядко се случва, ако изобщо се случва.

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

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

Времената се промениха; Agile методологиите са по-разпространени, така че екипите на бази данни трябва да преосмислят подхода си към моделирането на данни. В Agile се използва моделът на домейна от случаи на употреба вместо диаграми за връзки на обекти. Необходимостта от планиране обаче не е намаляла. Трябва да разберем данните и какво трябва да правят. Като цяло, първите няколко спринта трябва да се съсредоточат върху дизайна на данни.

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

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

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

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

2. Документирайте своя модел

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

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

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

До известна степен документацията няма много общо с моделирането на данни. Документацията е свързана с предаването на дизайна и превръщането му в разбираем в бъдеще.

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

Като пример, моделите на данни често имат поле „ID“ като първичен ключ за таблица или част от името на ключ. Това може да е първичен ключ като TransactionID на Transaction маса. Ако някои таблици използват „Число“ като част от името на ключ, тогава е добре да се документира защо. Може би ReferenceNumber се използва като име на първичния ключ в съобщението, защото така се нарича препратката в бизнес областта. Например във финансовите услуги финансовите съобщения обикновено включват референтен номер.

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

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

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

3. Следвайте конвенциите

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

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

Когато „ID“ се използва за някои изкуствени ключове, но някои таблици използват различна конвенция за именуване (като номер), разработчиците, анализаторите и администраторите на данни може да губят време, за да разберат изключенията. Слабите конвенции за именуване също водят до грешки в разработката, тъй като именуването не е последователно.

Ръка за ръка с документацията, използването на конвенция за именуване позволява в бъдеще някой да разбере модела. Не превключвайте произволно между използването на „ID“ (като CustomerID ) и „Номер“ (AccountNumber ) като ключове за таблици. Правете изключения от конвенциите само когато са оправдани. Документирайте какво е изключението и защо конвенцията не се спазва.

Същото важи и за загадъчни имена като „XRT1“ – това ли са разширените референтни таблици? Вашето предположение е толкова добро, колкото и моето. Надявам се, че дизайнерът е знаел защо е избрал такова загадъчно име, но се съмнявам, че следващият човек, който има достъп до базата данни, може да отгатне причината.

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

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

4. Помислете внимателно за ключовете

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

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

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

И така, трябва ли да използваме естествен ключ като първичен ключ? Едно предизвикателство възниква, ако естественият ключ трябва да бъде променен. Ако естественият ключ се състои от много колони, може да се наложи да направите промени на много места. Друго предизвикателство е използването на изкуствен ключ като единствен ключ за маса.

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

5. Използвайте внимателно проверките за целостта

За да гарантираме целостта на данните, имаме нужда от външни ключове и ограничения. Внимавайте да не използвате прекомерно или недостатъчно тези проверки за цялост.

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

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

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

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

6. Не забравяйте индексите във вашия дизайн

Някои дизайни на индексиране са полезни по време на моделиране на база данни, дори ако индексите могат да се променят по време на реалното внедряване и използване. Разбира се, възможно е да имате твърде много индекси, точно както е възможно да имате твърде малко.

Индексирането е непрекъснат процес. По време на проектирането започвате процеса на вашия модел. Работата по проектиране е върху първичните ключове и ограничения.

Индексите са важни при разглеждане на заявки за данните. Когато моделирате, трябва да вземете предвид как данните ще бъдат запитани. Внимавайте да не индексирате прекалено. Индексирането се върти около оптимизирането на заявки.

7. Избягвайте общи справочни таблици

Често съм виждал обща таблица за търсене на двойки атрибути. Определянето на една обща таблица с общи домейни се възприема като опростяване на дизайна. Този стил на таблица на домейн прави абстрактна дефиниция за задържане на текст. Чувал съм да я наричат ​​таблица „Разрешена стойност“ или „Валидни стойности“, но терминът „MUCK“ таблица е измислен за този анти-модел през 2006 г.:Масово унифициран кодов ключ.

MUCK таблици съдържат несвързани данни.

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

Сега добавете записи за друг домейн:

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

Само за забавление моделирах прост пример за MUCK таблица (или OTLT, „Една истинска таблица за търсене“, ако сте фен на Толкин) и включих някои коментари. Моля, имайте предвид, че това е анти-модел и не ви препоръчвам да го използвате във вашия модел на данни.

С MUCK таблици ограниченията не могат да бъдат дефинирани. MUCKs могат да станат много редове без никакво значение. Когато трябва да направите заявка към друга таблица, за да разберете значението на полето, това не е идеално.

Тези таблици „всичко върви“ правят проверките на целостта сложни или дори невъзможни. Една от причините, поради които тези таблици могат да бъдат създадени, е, че няколко таблици в базата данни имат подобна дефиниция. Тогава проверките на целостта на данните стават невъзможни. Освен това размерът им може да стане доста голям.

Нормализирането трябва да води далеч от MUCK таблиците. Една таблица трябва да представлява един домейн; вместо единична (MUCK) таблица, представяща всички домейни. Без MUCK таблици можем да поставим ограничения на външния ключ.

Използвайте отделни таблици за обекти на домейна, вместо да ги тъпчете в една таблица. Това позволява правилни типове колони, ограничения и връзки. Таблица „Разрешени стойности“ е просто мръсотия и няма място в модел на данни.

8. Определете стратегия за архивиране

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

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

Това избягва необходимостта от препроектиране на архивиране във вашата база данни върху оригиналния дизайн.

9. Тествайте рано, тествайте често

За да перифразирам Ал Капоне (или Джон Ван Бюрен, син на 8-ия президент на САЩ), „тествайте рано, тествайте често“. По този начин вие следвате пътя на непрекъснатата интеграция. Тестването на ранен етап на разработка спестява време и пари.

Тестването винаги е предизвикателство в плана за развитие. Често има тестова фаза в края на Agile Sprint и системно тестване в края на разработката. Тестването обикновено е първото нещо, което трябва да се притисне, когато времето стане малко.

При тестването на базата данни целта трябва да бъде да се симулира производствена среда:„Един ден от живота на базата данни“. Какви обеми могат да се очакват? Какви взаимодействия с потребителите са вероятни? Обработват ли се граничните случаи?

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

Заключение

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

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

Какво е мнението ви за тези съвети?

Имате ли свои собствени съвети?