Чувствате се претоварени от времето, което ще ви отнеме, за да се научите да бъдете дизайнер на база данни? Прочетете за основните умения и таланти, от които ще се нуждаете – не е толкова ужасно!
Когато вървите по пътеките на супермаркета, пазарска количка в едната ръка и списък с хранителни стоки в другата, какво си мислите? Ако сте като мен, вие си представяте как да подобрите организацията на рафтовете, така че седмичното ви пазаруване да е по-малко времеемко. Или може би изпитвате същото желание да организирате и структурирате информация, когато приятел ви покаже голямата си колекция от списания. Или може би се появява, когато управлявате плейлистите си, за да отговарят по-добре на вашите предпочитания. Ако минавате през живота си мислейки как да представите реалността по отношение на същности, атрибути и взаимоотношения, тогава вашето призвание е да бъдете модел на база данни.
Може би не сте толкова екстремни, но все пак сте привлечени от идеята да се занимавате с дизайн на база данни като кариера. Така или иначе ще трябва да овладеете няколко нови умения. Някои от тях са чисто технически; можете да научите тези умения чрез изучаване или четене и да ги задълбочите чрез трудов опит. Други умения включват нетехнически знания, които можете да научите чрез курсове, статии в блогове или като наблюдавате други.
Ето обобщение на основните знания и умения, които всеки дизайнер на база данни трябва да притежава.
Необходими са дизайнерите на бази данни за твърди умения
Твърдите умения са тези, които се придобиват чрез обучение и се усъвършенстват чрез практика. Ако можете да демонстрирате с конкретни доказателства, че сте усвоили трудно умение, това означава, че сте способни да изпълнявате всяка задача, която включва това.
По отношение на знанията за база данни, твърдите умения включват основите на теорията на базата данни и различните техники, използвани за прилагане на теоретични концепции за решаване на конкретни проблеми. Нека разгледаме всяко от твърдите умения, от които се нуждаят дизайнерите на бази данни.
Теория на базите данни
Теорията на базите данни е пълна с абстрактни понятия, които могат да бъдат трудни за разбиране, ако не са свързани с факти от реалния живот. Релационният модел, домейните, атрибутите, отношенията и връзките, първичните и външните ключове, целостта на обекта, референтната цялост и ограниченията на домейна са само няколко примера. Ако добавите още по-сложни въпроси (като релационна алгебра или релационно смятане), може да се чудите дали не е по-добре да изберете кариера, занимаваща се с конкретни неща като градинарство или гурме готвене.
Не изпадайте в паника. Задълбочено познаване на теорията на базата данни е важно, ако планирате да преподавате курсове в колежа или да измислите нов начин за организиране на информация. Но за да проектирате бази данни, трябва само да овладеете теоретичните концепции, които се прилагат за решаване на проблеми от реалния живот. Най-важният – азбуката на дизайна на база данни – е релационният модел.
Релационният модел
Преподавателите от колежа ще ви кажат, че релационният модел е механизъм за организация на данни, базиран на теория на множеството и логика на предиката. Но това няма да ви помогне много в ежедневната ви работа като модел на база данни. На практика трябва да знаете, че релационният модел е интуитивен и ясен начин за организиране на данни под формата на таблици – наречени релации – които са съставени от редове (които също се наричат кортежи). Всяка таблица (или релация) се дефинира от своите атрибути (или колони).
Основни понятия на релационния модел.
Всички отношения трябва да имат един или повече изключителни атрибути, които представляват уникален идентификатор за всеки кортеж. На жаргон на базата данни това е ключът на таблицата. Неключовите атрибути зависят от ключовете в смисъл, че всяка ключова стойност определя една възможна стойност за всеки атрибут.
Представете си таблица с информация за превозното средство, в която ключът е регистрационният номер. Регистрационната табела определя атрибутите на всяко превозно средство (като производител, модел, собственик и т.н.), тъй като правилата на домейна не позволяват две различни превозни средства да споделят една и съща регистрационна табела.
Релационни бази данни
Системите за управление на релационни бази данни (RDBMS) реализират релационния модел, спазвайки неговите принципи. Те предлагат начини за извличане на информация чрез заявки и актуализиране на информация чрез транзакции. За да може информацията в релационна база данни да отразява факти и ситуации от реалния живот, можете да дефинирате условия или ограничения, специфични за домейна, за който се прилага базата данни. Например в таблица, която съхранява информация за ученици, може да се наложи ограничение, така че датите на раждане да не позволяват бъдещи дати или дати, които са твърде далеч в миналото.
Организацията на таблици в база данни обикновено се нарича схема на база данни. В допълнение към таблиците, схемата подробно описва ограниченията, включващи двойки таблици, наречени релации. Връзката свързва две таблици, като налага ограничението стойностите в полето на една от таблиците да съответстват на стойности в първичния ключ на другата таблица.
Схемите на базата данни обикновено са представени от диаграмата на обект-връзка (ERD), често срещан инструмент за всеки дизайнер на база данни.
ERD, представляващ модел на клиентски данни.
Аномалии и нормализиране
Всички концепции, които обсъждахме досега, са доста ясни, нали? Сега можем да говорим за аномалиите, които възникват в базите данни поради дефектен или неадекватен дизайн (т.е. базата данни не отразява адекватно реалността, която се опитва да представи).
Аномалии възникват, когато операция за вмъкване, актуализиране или изтриване генерира несъответствия в данните. Например, да предположим, че имате таблица за съхраняване на данни за продажбите. За всяка продажба (т.е. във всеки запис на таблицата) се записват името и адресът на клиентите. Аномалията е следната:
- Ако адресът на клиента е променен в една от продажбите, и
- Същият клиент има други продажби,
- Другите продажби ще имат неактуален адрес.
За да избегнете аномалии, можете да приложите техника за проектиране, наречена нормализиране на базата данни. Това включва разлагане на таблици и колони (т.е. разбиването им на по-малки части), за да се избегнат недостатъци в дизайна като:
- Колони, които съдържат повече от една информация (напр. идентификационен номер на артикул, както и неговото име).
- Съхраняване на една и съща информация повече от веднъж в една и съща таблица.
- Полета, които зависят от други неключови полета.
Ненормализирана таблица (вляво) спрямо нормализирана схема (вдясно).
Складове на данни и денормализация
Някои бази данни се използват за запитване на големи обеми информация вместо за онлайн обработка на транзакции (OLTP). Тези бази данни се наричат складове за данни.
Информацията в склад за данни не идва от потребителски интерфейси (например въведена директно от система за поръчки за електронна търговия). Той идва от пакетни процеси, които събират информация от различни източници, обработват я, почистват я и я съхраняват в таблици. Поради тази причина можем да предположим, че складовете за данни не са изложени на същите аномалии като конвенционалните бази данни.
Поради това не е необходимо складовете за данни да поддържат същите условия за нормализиране като OLTP база данни. От друга страна е по-важно да се оптимизира ефективността на заявките в складовете за данни. Ето защо денормализацията се прилага в хранилище за данни; тази техника използва известно количество излишък, за да опрости заявките и да избегне претрупването на схеми с прекомерен брой таблици.
Типична схема за склад на данни.
Големи данни
Подобно на съхранението на данни, концепцията за големи данни се отнася до хранилища, които съхраняват големи количества данни. Между двете понятия обаче има важна разлика. Складът за данни е предназначен за конкретна цел и е насочен към генериране на отчети, чието поведение и формат са известни предварително.
Големите данни, от друга страна, имат за цел да събират големи обеми данни, генерирани с висока скорост от различни източници – напр. информация от социални медии, микротранзакции или интелигентни сензори. Това огромно количество информация може да се използва за проучване и анализ или за обучение на модели за машинно обучение.
При проектирането на база данни с големи данни, икономията на пространството за съхранение и разделянето на данни (наред с други неща) са приоритетни, за да се даде възможност за паралелизъм и улавяне на данни в реално време. Освен това се използват нерелационни или NoSQL системи за бази данни, които предлагат по-добри алтернативи за работа с неструктурирана информация.
Технологии като NoSQL и самата концепция за големи данни са сравнително нови в сравнение с релационните бази данни, които вече са на повече от 40 години. Ето защо, като дизайнер на база данни, трябва да сте внимателни към новите разработки в тази област. Имайте предвид, че големите данни също са голям бизнес. Много компании искат да заемат водеща позиция в него и разработват нови инструменти и технологии за това.
Администриране на база данни
След като базата данни е стартирана и работи, някой трябва да се погрижи за ежедневното й управление. Това означава извършване на рутинни задачи, така че базата данни никога да не се превърне в пречка за приложенията, които я използват. Административните задачи включват поддържане на резервни копия, наблюдение на консумацията на място за съхранение, откриване на сривове между процесите и отстраняване на проблеми с данните, които пречат на нормалната работа на приложенията.
Човекът, който има уменията за база данни, за да се грижи за тези задачи, е администраторът на базата данни или DBA – когато има такъв. В много малки организации – или в среди за разработка, където работата на базите данни не е от решаващо значение за бизнеса – отговорността за поддръжката на база данни може да падне върху модела на база данни. Следователно, трябва да имате известни познания, които ще ви позволят да поемете управлението от DBA в определени ситуации. Въпреки това, при никакви обстоятелства не трябва да поемате отговорността за администриране на база данни в производствена среда, която поддържа бизнес или критични приложения .
Административните задачи варират значително в зависимост от системата на базата данни и инфраструктурата, на която е монтирана. Например задачите за управление на бази данни на Microsoft SQL Server са много различни от тези за управление на MySQL или Oracle бази данни. А управлението на сървър, който работите локално на вашия бележник, е много различно от управлението на сървър, който работи в облака.
Не препоръчвам да полагате много усилия, за да научите как да управлявате конкретен сървър на база данни, тъй като ще се справяте с много различни бази данни и среди през цялата си кариера. Няма да ви помогне да се специализирате само в едно.
Управление на паралелност и транзакции
Едновременният достъп до база данни може да причини проблеми в приложенията, когато няколко потребители се опитат да осъществят достъп до един и същ ресурс по едно и също време. Може да мислим, че като дизайнери това не е наша работа и че отговорността на DBA е да се справи с тези проблеми. Може също да мислим, че програмистите са виновни за създаването на приложения, които им позволяват.
Въпреки това, дизайнерите могат да направят своята част, за да намалят до минимум потенциалните проблеми с паралелността, като проектират схеми, които ги избягват.
Много проблеми с паралелността възникват, когато дълги и сложни транзакции се изпълняват в база данни; докато транзакцията се обработва, участващите таблици са блокирани за други процеси, които се нуждаят от тях, за да четат или записват информация. За да избегнете този вид проблем, най-доброто, което можете да направите, е да се уверите, че вашите дизайни отговарят поне до третата нормална форма. Тогава отговорността на програмиста ще бъде да обмисли правилно транзакциите, за да избегне блокиране.
Но можете също да използвате стратегии, които избягват едновременност, като например схеми за разделяне или групиране на таблици според функцията, която изпълнява всяка от тях.
Нека си представим база данни за сайт за електронна търговия. Можете да поставите таблиците с основни данни за продукти, запаси и цени в една схема и поръчки и продажби в друга, заедно с изгледи или копия само за четене на таблиците от първата схема. Това помага да се избегнат грешки при изпълнение на транзакции, които актуализират основните данни.
Инструменти за проектиране на база данни
Ако разбирате релационния модел, диаграмите на същност-връзка и техниките за нормализиране, можете да проектирате бази данни без друг инструмент освен молив и хартия. Въпреки това, вашата производителност ще бъде значително подобрена, ако използвате интелигентен инструмент, особено този, който може да автоматизира определени дизайнерски задачи като преместване или модифициране на обекти в диаграма, откриване на грешки в дизайна, генериране на SQL скриптове за създаване или актуализиране на база данни и обратно- проектиране на съществуващ дизайн на база данни.
Овладяването на специализиран инструмент като платформата Vertabelo ще ви позволи да работите много по-бързо. И това ще ви позволи да се откроите от другите дизайнери, които нямат тази помощ.
SQL и програмиране
Всички бихме искали да можем да представим дизайн на база данни, да кажем гордо „Работата ми тук е свършена“ и да си тръгнем на заслужена почивка. Но обикновено тази идеална ситуация никога не се случва. След като приключите с дизайна си, програмистите на приложения ще трябва да го използват и ще трябва да ви имат наоколо, за да им помогнете.
Един от начините, по които трябва да продължите да помагате в проект за разработка, е да пишете изгледи, тригери, съхранени процедури и други неща в SQL (Structured Query Language), за да решите конкретни нужди на приложението. Друг начин е да контролирате задачите по програмиране, които се изпълняват с нещо, наречено Обектно-релационни карти (ORM).
ORM са предназначени да абстрахират достъпа до данни от определена RDBMS. Добрата страна на това е, че програмистите не трябва да се притесняват за спецификата на базата данни, която ще използват – с други думи, не е нужно да се интересуват дали RDBMS е MySQL, Oracle, IBM DB2, MS SQL Server , или нещо друго.
Недостатъкът на ORM е, че обектите за проектиране на база данни – таблици, атрибути и връзки – са дефинирани в кода на език за програмиране от високо ниво като Java, Python, R или C#. С други думи, те са там, където ние, дизайнерите на бази данни, не можем да ги видим.
Решението на този проблем се крие в методологиите за Agile разработка и тяхната философия за сътрудничество. Те насърчават дизайнерите и програмистите, работещи заедно в хода на даден проект, така че ще искате да поддържате добри отношения с програмистите. Трябва да сте готови да седнете до тях, да разгледате програмния код и съвместно да напишете дефинициите на обектите с данни.
Конструкторите на база данни с меки умения трябва да имат
В допълнение към теоретичните и технически познания, специфични за дизайна на база данни, дизайнерът в идеалния случай трябва да има други умения, известни като „меки умения“. Тези умения – като добър комуникатор и разбиране на визията на бизнеса за крайния продукт – влияят косвено върху успеха на вашата работа. Тези, които споменавам по-долу, са само няколко примера, но има много повече меки умения, които са високо ценени от потенциалните работодатели.
Бизнес визия
Когато проектирате база данни, вие представяте реалността на бизнеса по отношение на взаимосвързани обекти от данни. Видяхме, че дизайнът трябва да отговаря на условията за стандартизация и че трябва да избягва несъответствия, аномалии и проблеми с едновременността. Но също толкова важно – или може би повече – е дизайнът да е в съответствие с бизнес визията на този, който ви плаща заплатата.
Разбирането на бизнес визията ще ви позволи да разберете по-добре важността на всяко изискване и да насочвате решенията си, така че вашите проекти да са по-добре в съответствие с целите на организацията.
Ето един прост пример за това как разбирането на бизнес визията ще оформи работата ви. Може да си мислите, че използването на сурогатен ключ в таблица затрупва вашия дизайн, добавяйки ненужен и досаден елемент. Но като пропуснете сурогатния ключ, можете да забавите заявките в тази таблица, тъй като ключът от тип INTEGER може да осигури превъзходна производителност. Ако бизнес визията е да предоставя бързи заявки, тогава сурогатният ключ е правилният начин.
Комуникационни умения
Не е достатъчно да се правят страхотни дизайни. Трябва също така да можете да обясните защо вашият дизайн работи. Начинът да направите това е да знаете как да го представите, както дискурсивно (говорено или писмено), така и визуално.
Направете списък със силните страни на вашия дизайн, така че да се открояват. Помислете за решенията, които сте взели, за да го създадете и запишете причините за тези решения. Бъдете готови да защитите своите решения и дизайна си пред тези, които не го разбират или искат да го променят, правейки го несъвършен или погрешен.
Но също така трябва да сте готови да приемете конструктивна критика и да вземете предвид гледни точки, които са различни от вашите. Понякога програмист може да забележи проблем, който не сте забелязали, и да ви даде добър съвет. Не уволнявайте колегите си, мислейки, че нямат познания за базата данни.
Междуличностни умения
Коментирах по-горе предимствата на добрата връзка с програмистите. Без значение колко напреднали сте във вашата област на опит, важно е да поддържате нагласа на приятелство с всички членове на екипа, независимо дали е тестер, който е открил дефект, който ви принуждава да преосмислите част от своя дизайн, или ръководител на проекта, който се нуждае да изпълните задача до определена дата. Накратко, трябва да сте отборен играч . Никой не иска да има примадони в екипа си, които се чувстват незаменими и искат да наложат своите правила.
Може да се случи, че не сте единственият дизайнер на база данни в екип за разработка. Може би трябва да ръководите подгрупа от вашите колеги. За да направите това, трябва да демонстрирате лидерски умения и да действате като мениджър на проекти, като гарантирате, че екипът от дизайнери на бази данни изпълнява целите си и остава мотивиран.
Как да научите умения за проектиране на база данни
Можете да придобиете уменията, от които се нуждаете, за да бъдете дизайнер на база данни от университетски степени, курсове, книги и специализирани статии. Предимството на университетските курсове е, че те ви дават всички необходими знания и потвърждават тези знания с призната степен. Недостатъкът е, че изискват голяма инвестиция на време и пари.
Ако предпочитате да учите сами, като четете книги и статии, ще спестите време и пари – но ще ви трябва ръководство, което да ви преведе през основните теми и да оцени знанията си. И ще трябва да демонстрирате знанията си по практичен начин, тъй като няма да имате диплома, която да ги подкрепи.
Във всеки случай, независимо дали учите чрез курсове или четене, това знание ще послужи само като основа. Ще научите най-много, като създавате модели, изправяте се пред реални проблеми и наблюдавате действията на вашите колеги и колеги.
