Работата на дизайнера на база данни е да преведе бизнес изискванията на клиента в модел на данни, който не само съхранява правилно бизнес данните, но също така поддържа процесите, които използват данните.
Дизайнер на база данни, понякога наричан архитект на база данни или служител по данни, е отговорен за проектирането на базите данни в една организация. Той/тя внимателно оценява бизнес изискванията и изготвя моделите на данни. След това се провеждат първоначални дискусии с бизнеса, за да се потвърди разбирането на данните и бизнес процесите. Работата на дизайнера на база данни включва също изготвяне на подкрепяща документация при изграждането на физическата база данни.
Какво е моделиране на данни?
Моделирането на данни е процес, при който дизайнер на база данни създава модел на данни, който поддържа неговото/нейното приложение. Целта му е да представи как взаимодействат обектите на базата данни и как решават бизнес проблеми.
Моделът на данни описва структурата на данните в таблиците на базата данни и връзките между тях. Представен е от поредица от ER диаграми, които съдържат основните обекти, техните атрибути и връзките между обектите. Много е важно да изградите правилния модел на данни от самото начало.
Моделирането на данни трябва също да вземе предвид гъвкавостта. Никой модел на данни никога не е заложен в камък дори след внедряването на базата данни. Моделът на данни трябва да бъде коригиран с течение на времето, за да отразява нови данни и нови изисквания. Ето защо отчитането на гъвкавостта е важно, когато го проектирате.
Моделирането на данни ви помага да преведете бизнес изискванията в технически изисквания за изграждане на физическата база данни по-лесно. Той също така ви помага да намерите потенциални проблеми с производителността със заявки, преди дори да създадете базата данни. Поради всички тези причини моделирането на данни е много важно.
Типове модели на данни
Когато създавате нова база данни, работата ви като дизайнер на база данни ви превежда през поне три основни фази. Моделът на данни преминава през еволюционен процес, започвайки от концептуален модел на данни. След това се разширява в логически модел на данни. Това от своя страна се разширява допълнително във физически модел на данни, по-късно реализиран със SQL скриптове.
Всеки тип модел на данни е предназначен за взаимодействие с различни видове заинтересовани страни. По-долу ще опишем накратко и обясним използването на тези модели на данни. Ако искате по-задълбочено обяснение, разгледайте тази статия.
Концептуален модел на данни
Концептуалният модел на данни е първият модел на данни, който изграждаме. В концептуален модел на данни се дефинират основните обекти, обикновено с помощта на ER диаграми. Това е и когато основните заинтересовани страни от страна на бизнеса участват.
Концептуалният модел на данни помага да се идентифицира и дефинира първоначалния обхват на бизнес проблема, субектите, участващи в решаването на проблема, и как те взаимодействат. Тези обекти са общи представяния на понятия като поръчка, магазин и служител.
Връзките между тези обекти обикновено са представени с линии, свързващи обектите, които взаимодействат в реалния свят. Така че, като пример, обектите за поръчка, магазин и служители трябва да имат връзки, които свързват помежду си.
Логически модел на данни
Логическият модел на данни се основава на концептуалния модел на данни. Прилагат се техники за нормализиране като 3NF (третата нормална форма). Ние гарантираме, че всички връзки между обекти са представени в нашия модел на данни. Тази стъпка е ключовата разлика между концептуалния и логическия модел на данни.
Модел на физически данни
Физическият модел на данни е последната и най-подробна версия на нашия модел на данни. В тази стъпка ние дефинираме всички таблици в нашето приложение. Ние също така дефинираме връзките между таблиците, задаваме тяхната мощност, трансформираме атрибутите на обекта в колони и избираме или дефинираме типове данни за всяка колона. Ние се уверяваме, че задаваме стойности по подразбиране или ограничения за стойности на колони, ограничения между таблици и задаване на съпоставяне.
След като моделът на физически данни е проектиран, ние обикновено изграждаме набор от SQL скриптове, които дефинират тази структура, за да създадем нашата база данни. Вместо просто да пишете всичко на ръка, много по-добре е да използвате инструмент за моделиране на база данни като Vertabelo Database Modeler.
Работа на дизайнера на база данни
Задълженията на дизайнера на база данни не се ограничават до техническо развитие и дизайн на диаграма. Един типичен ден включва разглеждане на изоставането от бизнес изисквания и проверка дали нещо се е променило.
Един ден от живота на дизайнер на бази данни
Когато има промени, дизайнерът на база данни анализира изискванията и се среща с бизнеса, за да изясни последиците от промените върху модела на данни и базата данни. След тези разяснения дизайнерът на базата данни актуализира модела с промените. Това може да варира от просто промяна на един тип данни до преструктуриране на връзките на обекти и прилагане на нормализиране, ако промяната има по-голямо въздействие.
Ако има показател за производителност, който трябва да бъде изпълнен, тогава дизайнерът на базата данни може да трябва да намери и посочи индекси, които да бъдат създадени. Ако има ETL процес, който трябва да бъде картографиран, той/тя може да посочи кои съхранени процедури извършват трансформацията на данните.
Дизайнерът на база данни трябва да вземе предвид последиците от промените върху задачите за поддръжка на базата данни, като архивиране, възстановяване и доставка на регистрационни файлове. Ако промените са големи, тогава дизайнерът на база данни трябва да обсъди с административния екип на базата данни или с екипа за разработка, който наблюдава базата данни. Друга отговорност на дизайнера е да дефинира и поддържа речника на данните за базата данни.
Рискове и проблеми, пред които е изправен дизайнер на база данни
Както при всяка работа, някои проблеми са предвидими, така че можете да начертаете план. Но има проблеми, които не можете да предвидите и работата на дизайнер на база данни не е изключение.
Едно от най-рискованите неща, които дизайнерът на база данни може да направи, е да прави предположения. Това може да доведе до неочаквани проблеми по-късно в проекта. Когато имате съмнения, най-добре е да изясните с бизнеса, вместо да продължите напред. Виждал съм го да се случва много пъти, както на мен, така и на моите колеги.
Можем да правим малки предположения относно типовете данни или количеството данни за конкретна таблица. Ако грешим обаче, това може да повлияе на модела на физическите данни и да причини много преработка, за да се постигнат целевите показатели за ефективност.
Друг проблем е да приемем, че сте покрили всичко и че никога няма да има грешки. Проблемите обикновено се случват в края на проект, когато всичко вече е разгърнато.
Някои сценарии изискват корекции, дори след като вашата база данни вече е разгърната. Това може да се дължи на увеличаване на съхраняваните данни, промени в бизнес изискванията или нужда от нови отчети. Тези събития засягат не само вашите таблици, но и обектите на базата данни, вашите индекси, евентуално типове данни, връзки и много други неща.
Плюсите и минусите на това да бъдеш дизайнер на бази данни
Както при всяка работа, има плюсове и минуси в зависимост от това как гледате на нещата, какво ви харесва и как искате да живеете.
Плюсовете са, че винаги намирате интересни бизнес контексти, които да начертаете в модел на данни и да вградите в база данни. Това е страхотна работа за хора, които могат да се съсредоточат и обичат да решават трудни проблеми. Това е страхотна работа, ако обичате да общувате и решавате технически проблеми и ако можете и сте любопитни да разберете както бизнес, така и технологичен контекст.
Както при всяко трудно умение, заплащането е доста добро. Ако работите по проекти с клиенти от големи компании, бизнес пътуванията може да са бонус, ако обичате да пътувате и да се срещате с нови хора в нова среда.
Минусите не са много според мен. Но за някои хора някои от нещата, споменати в плюсовете, всъщност са минуси. Ако предпочитате да се съсредоточите дълбоко върху работата си и да сведете до минимум комуникацията или ако не можете или не искате да пътувате поради семейни ограничения, тогава работата с дизайнер на база данни може да не е подходяща за вас.
Станете дизайнер на бази данни!
С известен технически опит в областта, известен опит в програмирането и отвореност към комуникация, мисля, че всеки може да има кариера на дизайнер на база данни, дори ако не поставите отметка във всички квадратчета. Идеалните изисквания за умения за дизайнер на база данни са накратко изброени по-долу.
- Техници за моделиране и нормализиране на данни.
- Познания за заявки за база данни и настройка на производителността.
- Вътрешни елементи на базата данни, специфични за двигателя на базата данни, изисквани от клиента.
- Познаване на ETL процесите.
- Познания за бизнес разузнаване и отчитане.
- Познаване на общата софтуерна архитектура и дизайн.
- Умения за управление на проекти.
- Добри комуникационни умения.
Мислите ли да станете дизайнер на бази данни? Ако откриете, че сте отметнали някои елементи в списъка по-горе, не се колебайте – ние ви пазим! Независимо дали кандидатствате за първата си работа като дизайнер на база данни или просто искате да сте запознати с най-важните теми за ролята, ние сме подготвили списък с въпроси за интервю, свързани с моделирането на база данни.
Тепърва започвате с моделирането на база данни? Важно е да имате инструмент като Vertabelo Database Modeler, който да ви помогне при проектирането, споделянето и версията на вашите модели на данни.
Надяваме се, че статията ви е харесала! Чувствайте се свободни да разглеждате наоколо за повече информация за невероятния свят на базите данни.
