Дизайнът на базата данни надхвърля просто чертане на линии и кутии. В тази статия разсъждавам върху процеса на моделиране на данни с акцент върху най-добрите практики, както и върху това как да използвам инструменти за прилагане на тези най-добри практики за създаване на добър дизайн на база данни.
Проектирането на база данни е процесът на създаване на подробен модел на база данни. Началото на моделирането на база данни включва разбиране на бизнес областта и функционалността, която се разработва.
Ако не сте сигурни относно стъпките, включени в процеса на проектиране на база данни, бих ви препоръчал това описание на стъпките за проектиране на база данни.
Започнете да моделирате:Говорете с бизнеса
Това е ключов принцип в информационните технологии. Ние решаваме бизнес проблем от страна на данните, така че необходимите данни да са налични. Трябва да говорим с хората от бизнеса, за да разберем техните нужди.
Трябва да задаваме въпроси като:
- „Какъв е домейнът?“
- „Какви са предизвикателствата в този домейн?“
- „Какви са проблемите, които трябва да бъдат решени?“
- „Каква информация трябва да съхраняваме?“
Като разговаряме с бизнеса, можем да обмислим компромиси, които могат да повлияят на модела на базата данни. Полагаме и основата за моделиране.
Нека използваме конкретен пример. Вземете счетоводно приложение за компания:ще трябва да моделирате клиенти, доставчици, фактури, плащания, сметки, салда и т.н. Трябва да научите за тези концепции и за счетоводството. Можете да направите това само сговор на хората от бизнеса.
Привеждане в ред на концепциите
Тази първоначална работа с бизнеса ще ви доведе до модел на това какви „концепции“ трябва да се съхраняват в базата данни (прочетете това обяснение за различните нива на модели). От концепцията за това какво трябва да съхраняваме в базата данни, тоест нашия концептуален модел, преминаваме към логически. Логическият модел документира бизнес концепциите и правилата, върху които наслояваме детайли (може да ви е интересно да прочетете тази дискусия относно това дали моделирането на логически данни е остаряло).
Ако не сте сигурни относно различните типове модели на данни, вижте нашата статия за това как да внедрите концептуални, логически и физически модели на данни с Vertabelo.
Логическият модел на данни добавя повече информация към концепциите, които вече сме документирали. Той описва как са структурирани данните и как обектите са свързани помежду си. Освен това включва информация за видовете данни, които управляваме.
Във Vertabelo можем да създадем логически модел на данни чрез диаграма на логически обект-връзка (ERD). Проверете подробностите за това как да извършвате моделиране на логически данни с Vertabelo.
Ето един прост и все още не завършен логически модел на данни за клиенти, доставчици, фактури, плащания и сметки.
Друго предимство, което намирам от работата с Vertabelo, е, че не е нужно да се тревожа твърде много за точните нотации. Инструментът за моделиране ви позволява да се притеснявате за дизайна, а не за спецификата на нотациите и символите на диаграмата на обект-връзка (ERD), което очевидно би трябвало да е най-малкото ви притеснение по време на процеса на проектиране на база данни.
Нека физически
За да работим реално с базата данни, трябва да преминем от нашия логически модел към физически. Инструментът Vertabelo ни позволява лесно да генерираме физически модел на данни от логически. Първо създавате логически модел на данни, след което можете „автомагически " генерирате физически, като изберете логическия модел и щракнете върху "Генериране на физически модел на данни" (вижте това подробно ръководство за точните стъпки).
Очевидно генерираният модел на физически данни ще бъде подобен на логическия модел; обаче логическите типове данни ще бъдат преведени в типове данни, които са разрешени за конкретната система за управление на база данни (СУБД), за която генерирате физическия модел. Физическият модел също така ще посочи кои атрибути са външни ключове между таблиците. Може също да пожелаете да извършите допълнително моделиране, свързано с физическите аспекти на базата данни – например индекси и изгледи.
Освен това е възможно директно да се създаде физически модел на данни; не е нужно първо да създавате логичен. Преминаването направо към физически модел ще има смисъл за по-малки, по-насочени дейности по моделиране, където бизнес домейнът е по-добре дефиниран. Процесът на моделиране на физическа база данни е лесен и не трябва да представлява твърде много предизвикателства. Наличието на логически модел на данни ще се окаже полезно за по-големи проекти, но да имате поне физически такъв е по-добре, отколкото да нямате изобщо.
Еволюция на дизайна на вашата база данни
Разработчиците обикновено смятат, че моделът на базата данни трябва да се върти около действителния код, докато моделистите на данни смятат, че кодът трябва да бъде създаден на базата на относително статичен модел на данни. Моделирането на данни днес трябва да е съвместно . Кодът и моделът на данни влияят взаимно напред-назад.
И така, имаме нужда от инструмент, който поддържа съвместен процес на проектиране и моделиране на база данни. Освен че работят с бизнеса за създаване на концептуалния дизайн, разработчиците на модели на данни трябва да си сътрудничат по време на цикъла на разработка, за да актуализират логическите и физическите модели на данни според нуждите. Разработчиците на модели и разработчиците трябва да адаптират модела, докато той наистина поддържа бизнес и нефункционалните изисквания на системата.
Очевидно промените могат да доведат до грешки. Отново, наличието на инструмент може да помогне; инструмент, който постоянно потвърждава вашия модел на данни, е безценен. Vertabelo има вградено онлайн валидиране на живо както за логически, така и за физически модели на данни, така че проблемите да се откриват по време на моделиране, а не по време на внедряването. И грешките остават видими за всички, които си сътрудничат по него. Освен това можете да коригирате настройките за валидиране според нуждите. Ето пример за моя непълен модел на данни с няколко грешки и предупреждения.
Връщайки се към счетоводния пример, може да откриете по време на разработката, че не е достатъчно да моделирате една валута като евро или долари за фактури и плащания. По-скоро ще трябва да съхранявате суми в съответната им валута и да ги конвертирате в „основната“ валута, в която се води счетоводството на компанията. Може също да имате нужда от валутните курсове и историческа информация за курсовете, които са били използвани за конвертиране на валути в миналото.
Това е мястото, където инструмент за съвместно моделиране на база данни като Vertabelo наистина доказва своята стойност. Можете да намерите повече информация за използването на Vertabelo за съвместно моделиране. Просто щракнете и споделите своя модел с членовете на вашия екип.
Физически до внедряване
След като имате първата си версия на физическия модел, вероятно ще имате нетърпение да започнете да работите с действителната база данни. За да направи това, Vertabelo ще генерира SQL DDL (език за дефиниране на данни) скриптове за създаване на базата данни. Няма да пиша всички подробности тук, тъй като можете да ги намерите в статията в онлайн базата знания как да генерирате SQL скрипт за създаване на база данни.
Нека ви кажа от опит – това е толкова добре дошла функция. Избягвате да се налага да се справяте с капризите на различните SQL DDL синтаксиси на базата данни и можете да се съсредоточите върху своя дизайн .
Версиониране
Сега, както написах по-горе, вашите модели ще се развиват, независимо дали става дума за дизайн на база данни, по време на разработка на софтуер или след това по време на действителното използване на вашата база данни. Има две страхотни функции на Vertabelo, за които искам да съм сигурен, че сте наясно.
Първо, Vertabelo включва управление на версиите. Можете да проследявате модификациите и да управлявате версии на моделите на данни, така че е лесно да „въртите времето назад“ и да се върнете към предишна версия, ако е необходимо. Ако сте дисциплинирани, можете да маркирате различните версии с точни имена, независимо дали това може да са чернови или действителни версии на базата данни.
Другата функция, за която мечтаех от много години по време на моето моделиране на база данни, е способността на инструмента Vertabelo да автоматично генерирайте скриптове за миграция между версиите на вашия модел на данни. Изгубих броя на пъти, когато трябваше да пиша и коригирам ръчно скриптове за миграция многократно. Ето пример за генериране на скриптове за миграция между две версии на база данни за онлайн проучване.
Каква полза за специалистите по моделиране на данни да имат инструмент, който ефективно управлява версиите и установява въздействието на промените между версиите!
Големи модели
Първо, нека бъда честен. Не винаги работя с големи модели, но понякога се налага да ги създавам. Тук отново Vertabelo ни предлага решение за организиране на нашите модели.
Можем визуално да групираме таблици с предметни области; ако искате да видите как да направите това, можете също да гледате видеоклип за управлението на големи модели на данни във Vertabelo.
Можете също да използвате тази техника, когато извършвате обратно инженерство от SQL DDL скрипт в модел на данни.
Започнете с дизайна на база данни
Ако търсите някои най-добри практики за проектиране на бази данни, бих ви препоръчал да разгледате тази статия. За съвети за по-добър дизайн на база данни не трябва да търсите повече от тази статия. И вижте този за съвет как да започнете да използвате Vertabelo за дизайна на вашата база данни.
