Какви са стъпките в дизайна на база данни?

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

Резултатът от упражнението за проектиране на база данни е модел на данни. Моделът на данни представя всички обекти, обекти, атрибути, връзки и ограничения в системата. Най-общо казано, моделите на данни могат да бъдат от два типа:логически илифизически . Представянето на модела на данните се извършва чрез създаване на ER диаграма, известна още като диаграма на взаимоотношенията на обекта, диаграма ERD или диаграма на база данни.

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

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

Имайки това предвид, нека преминем през стъпките в дизайна на база данни.

Стъпка 1:Съберете бизнес изисквания

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

• Бизнесът иска ли данните за проследяване на превозното средство в базата данни, независимо дали има активно пътуване или не? Ако отговорът е да, тогава полето vehicle_trip_id в таблицата vehicle_trips ще бъде нулева . В противен случай тя няма да бъде нулева .
• Бизнесът иска ли историята на промените в trip_status съхранявани в базата данни? Ако да, тогава всеки път trip_status промени, ще има друг запис в trips маса. В противен случай всеки път, когато trip_status промени, trip_status ще бъде актуализиран на място.

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

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

Стъпка 2:Разберете бизнес пътната карта

Бизнесът променя своите процеси през цялото време; способността им да се адаптират ги прави по-малко вероятно да се провалят. Промяната на бизнес процеси означава промяна на работните потоци и моделите на данни. Въпреки че не е възможно да се знаят тези промени много по-рано, със сигурност е възможно да сте в крак с пътната карта на бизнеса.

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

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

Стъпка 3:Идентифицирайте обекти и атрибути

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

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

Например, в модела за резервация на такси, ще трябва да идентифицирате атрибутите, които ще действат като задължителни полета за регистрация на потребители и шофьори от приложението за резервации. Регистрацията на потребителя ще се извърши с помощта на user_phone и регистрацията на драйвер ще се извърши с помощта на driver_phone .

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

Стъпка 4:Идентифицирайте взаимоотношенията

След идентифициране на обектите и техните атрибути, следващата стъпка е да се дефинират връзките между обектите въз основа на бизнес работните потоци, които са документирани във фазата на събиране на изискванията. В допълнение към установяване, че има връзка между две единици, също така е важно да се идентифицира кой от следните четири типа взаимоотношения съществува между тях. Помислете за две произволни субекти, A и B:

1. Едно към едно → Един запис в A съответства на най-много един запис в B.
2. Един към много → Един запис в A съответства на много записи в B.
3. Много към едно → Много записи в A съответстват на най-много един запис в B.
4. Много към много → Много записи в A съответстват на много записи в B.

В модела за резервация на такси е използван само един тип връзка, т.е. един към много. Вземете връзката между users и trips като пример. В модела има предположение, че само един потребител може да бъде свързан с пътуване, което предполага, че няма споделени или обединени кабини. Но ако имаше общи или обединени таксита, вероятно щеше да има връзка много към много между users и trips , ако много потребители споделят един и същ trip_id .

Стъпка 5:Създайте логическа ER диаграма

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

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

Стъпка 6:Потвърдете логическата ER диаграма

Логическото моделиране е процес, при който много бизнес информация трябва да бъде преведена в дизайн на база данни. Без задълбочени проверки тази фаза на разработване на база данни е предразположена към грешки, които могат да се окажат доста скъпи на по-късен етап.

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

• Имената на обекти, атрибути, връзки и т.н. не могат да бъдат нулеви и трябва да са уникални.
• Обектът трябва да има поне 1 атрибут.
• Идентификаторите (PK) трябва да бъдат дефинирани за всеки обект.
• Моделът трябва да използва един от изброените типове данни за атрибути.

Всички тези проверки са незадължителни и могат да бъдат конфигурирани да бъдат пропуснати, ако има друга рамка за валидиране. Правилното валидиране от Vertabelo ви помага да преминете към следващата стъпка с възможно минимално количество триене.

Стъпка 7:Създайте физическа ER диаграма

След като е създадена логическата ER диаграма, следващата стъпка е да се създаде физически модел на данни. Физическият модел на данни ще бъде специфичен за базата данни, където искате да разгърнете модела на данни. Всички бази данни имат уникална реализация на номенклатурни правила, типове данни и ограничения. Поради това езикът за дефиниране на данни (DDL) често се различава от една база данни в друга.

За да създадете физически модел на данни, изпълнете следните стъпки:

1. Намерете най-близкия тип данни в целевата база данни, за да замените общия тип данни, избран в логическия модел на данни.
2. Следвайте правилата на номенклатурата за таблици, колони и ограничения, както е предписано от целевата база данни.
3. Променете модела, за да се приведе в съответствие с предварително дефинирани работни потоци на заявка. Това обикновено води до увеличаване на излишъка за запазване на присъединения.
4. Накрая можете да създавате индекси, дялове, ключове за разпространение и ключове за сортиране. Това е моментът, когато можете да създадете всякакви модификации на модела, подобряващи производителността.

Тези стъпки могат да бъдат извършени с помощта на всеки инструмент за моделиране на данни, който можете да използвате, за да създадете модел на данни от нулата. Въпреки това, Vertabelo има опция да преобразува логически модел на данни в пълноправен физически модел на данни за всички основни системи за бази данни като MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery и др. След като логическият модел на данни бъде преобразуван във физически модел на данни, можете да продължите с четирите стъпки, които обсъдихме.

Vertabelo също има опция за добавяне на скриптове преди и след внедряване на ниво таблица, заедно с всякакви коментари на много детайлно ниво на модела. Коментарите се оказват полезни, когато се използва функцията за генериране на документация, предлагана от Vertabelo. Документът на базата данни може да бъде експортиран във всеки от следните три формата:HTML, PDF или DOCX.

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

Стъпка 8:Потвърдете физическата ER диаграма

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

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

Стъпка 9:Отстранете проблеми с физическата диаграма на ER

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

• Липсващи външни ключове, където са дефинирани връзки на обекти.
• Липсващи първични ключове от таблици.
• Неподдържани типове данни за избраната база данни.

След като тези и други подобни проблеми бъдат разрешени, моделът е готов за експортиране в разгръщащ се SQL скрипт за избраната система за управление на база данни.

Стъпка 10:Генерирайте DDL скриптовете за внедряване на модела

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

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

Сега, когато стигнахме до края на процеса на проектиране на база данни, нека да разгледаме SQL кода, генериран от Vertabelo.

Споделете вашите мисли

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

Ще се радваме да видим какъв е вашият опит в проектирането на бази данни. Пишете ни на [email protected].