Database
 sql >> база данни >  >> RDS >> Database

Защо имате нужда от моделиране на данни?

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

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

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

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

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

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

По-високо качество на информацията

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

Можете също така да гарантирате качеството на информацията, съхранявана в база данни, като налагате правила, така че в таблиците да влизат само валидни данни. За да направите това, когато проектирате модела на данни, задавате домейна на стойността за всяко поле и разграничавате полетата, които трябва да имат стойности, от тези, които могат да бъдат оставени празни.

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

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

Повторна употреба на активи от данни

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

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

Тази добра практика избягва генерирането на излишни данни в различни схеми, което води до непоследователна информация рано или късно (повече за това по-долу).

Миграция към облачни среди

С DaaS (данни като услуга) инфраструктури или бази данни в облака, определени изисквания, като поверителност на базата данни , динамична мащабируемост , иефективност при управление на множество наематели , станете по-критични.

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

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

Моделиране на бази данни за големи данни и NoSQL

Нерелационни бази данни, като NoSQL и диаменсионни схеми, може да ни принудят да оставим настрана (поне за момент) нашия традиционен релационен начин на мислене. Но това не означава, че можем без модели на данни. Напротив, моделирането на данни става още по-важно.

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

Съществува погрешно схващане, главно от програмисти, че NoSQL бази данни не използват схеми и следователно не изискват модели на данни. Нищо не може да бъде по-далеч от истината. Тъй като технологиите NoSQL не предоставят стандартизиран начин за преглед на метаданните (нещо, което всяка RDBMS прави), моделите на данни стават от съществено значение за позволяването на хората да използват и споделят информацията, съхранявана в базата данни.

Сливания и придобивания

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

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

Намалени разходи за разработка

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

Моделирането на данни е само 10% от бюджет на проект за развитие и има потенциал да намали действителните разходи по проекта до по-малко от една трета.

Просто помислете за следното. В повечето случаи разходите за моделиране на данни (тоест цената на усилията, необходими за изграждане и поддържане на модела) е по-малко от 10% от общия бюджет за софтуерен проект. За сравнение, икономиите на разходи, свързани с използването на модели на данни, са до 70%, всичко това от намалението на часовете за кодиране и поддръжка.

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

По-добри дефиниции на изисквания

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

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

По-бързо развитие

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

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

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

Повишаване на Agile методологии

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

Моделирането на бази данни е изправено пред значително предизвикателство при работа в гъвкави среди, тъй като дизайнерът трябва да може да работи върху „голямата картина“, докато разработчиците се нуждаят само от обектите с данни, необходими за всяка потребителска история. За да се постигне консенсус между моделисти на данни и разработчици, гъвкавите методологии използват техники като sandboxing иразклони .

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

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

Ами ако не използвам модели на данни?

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

  • Ненужно излишък:Тъй като няма модел, който да вижда ясно обектите с данни, ще се появят различни версии на едни и същи обекти с различна информация. Например, система за инвентаризация може да съобщи, че 500 единици от артикул са били продадени през последния месец, докато логистичната система може да съобщи, че 1000 единици от същия артикул са били изпратени през същия период. Което е правилно? Кой знае.
  • Бавни приложения:Липсата на модел на данни затруднява задачите за оптимизация, което намалява отзивчивостта на приложенията.
  • Невъзможност за изпълнение на стандартите за качество:Ако няма модел на данни, вашите бази данни няма да бъдат документирани, което е задължително в сценарии като миграции на бази данни.
  • Лошо качество на софтуера:Изискванията за разработка на софтуер ще бъдат лоши и потребителите няма да имат приложенията, от които се нуждаят или желаят.
  • По-високи разходи за разработка:Вече споменах значителните спестявания на разходи, които могат да бъдат постигнати в проект за разработка чрез използване на модели на данни. Ако решите да не ги използвате, ще трябва да решите кой плаща за допълнителните разходи за разработка и поддръжка. И кой ще се оправдава, когато сроковете не са спазени.

Все още не сте убедени?

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

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. 5 много често срещани грешки в дизайна на SQL заявка, които трябва да избягвате на всяка цена

  2. 4 начина да получите дефиницията на съхранена процедура с помощта на Transact-SQL

  3. Какво представляват тригерите в SQL и как да ги приложим?

  4. Свързване на .NET на Linux към ODBC източник на данни

  5. Въпроси за интервю за инженер по данни с Python