Моделиране на данни: обяснение на техники, видове и приложения в реалния свят

Начало » Питон » Моделиране на данни: обяснение на техники, видове и приложения в реалния свят

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

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

Какво е модел на данни?

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

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

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

Моделите на данни не се създават във вакуум; те се ръководят от бизнес изискваниятаПреди да започне моделирането, правилата и нуждите се събират от заинтересованите страни в бизнеса и крайните потребители. След това тези правила се преобразуват в структури от данни, които оформят дизайна на нова система или еволюцията на съществуваща. В този смисъл, моделът на данни е много подобен на пътна карта: той не изпълнява нищо, но ви казва как да стигнете от точка А до точка Б.

Доброто моделиране на данни разчита на стандартизирани схеми и формални техникиТази стандартизация осигурява последователен и предвидим начин за дефиниране и управление на ресурсите от данни между екипи, отдели и дори външни партньори. В идеалния случай моделите се превръщат в „живи“ документи, които се развиват с промените в организацията, подпомагайки подобряването на процесите и насочвайки решенията, свързани с ИТ архитектурата.

Какво е моделиране на данни?

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

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

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

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

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

Основни техники за моделиране на данни и видове модели

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

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

Йерархично моделиране на данни

Йерархичният модел на данни организира информацията в дървовидна структура, с един корен в горната част и множество нива на дъщерни възли под него. Всеки родителски възел може да има множество дъщерни възли, но всяко дете има точно един родител, което води до строга връзка „един към много“.

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

Да разгледаме пример с автокъща: възел от най-високо ниво може да представлява „Шоурум“. Всеки възел на шоурума ще има дъщерни възли за „Автомобили“ и „Търговци“, тъй като един шоурум може да побере много автомобили и да наеме много търговци. Навигацията винаги ще започва от шоурума и ще се движи надолу, за да се види кои автомобили и търговски персонал принадлежат към него.

Йерархичните модели са чудесни, когато вашата реална структура е естествено дървовидна., като например карти на сайта на уебсайта, организационни схеми, разбивки на рецепти или категории продукти в сайт за електронна търговия. Например, „Обувки“ може да е родителската категория, с дъщерни възли като „Дамски обувки“ и „Мъжки обувки“ и допълнителни деца като „Маратонки“, „Токове“ или „Ботуши“.

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

Моделиране на мрежови данни

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

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

Представете си студент, който е в катедра „Компютърни науки“, но има и право да заема книги от библиотеката.В мрежов модел, този запис „Студент“ може да има два родителски записа: един за „Отдел CSE“ и друг за „Библиотека“. Това беше невъзможно в строго йерархично дърво, където детето можеше да има само един родител.

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

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

Моделиране на данни тип „обект-връзка“ (ER)

Моделът „Обект-Връзка“ е визуален начин за описание на изискванията към данните на високо ниво, използващ ER диаграми.Това е една от най-широко използваните техники за концептуално и логическо моделиране на данни, особено когато се работи с бизнес заинтересовани страни, които се нуждаят от ясна картина без технически хаос.

В ER диаграмата основните градивни елементи са обекти, атрибути и взаимоотношения.Обектите представляват реални неща, които са важни за бизнеса (като „Студент“, „Учител“, „Курс“ или „Отдел“). Атрибутите улавят свойствата на тези обекти (като идентификационен номер на учителя, заплата, възраст), а връзките показват как обектите са свързани (например „Учител работи за отдел“).

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

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

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

Релационно моделиране на данни

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

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

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

Първичните и външните ключове играят решаваща роля в релационния моделПървичният ключ уникално идентифицира всеки ред в таблица (напр. SalespersonID или CarID). Тези ключове могат да се появяват като външни ключове в други таблици, за да представят връзки. Например, таблица „Showrooms“ може да включва както SalespersonID, така и CarID като външни ключове, свързвайки шоурума с продавача, който работи там, и изложения автомобил.

Сътрудничеството между първичните и външните ключове е това, което позволява на релационните бази данни да представят сложни мрежи от бизнес взаимоотношения.Когато правите заявка към базата данни, можете да свързвате таблици по тези ключове, използвайки анализ на данни със SQL и да се реконструират асоциации от реалния свят: кои автомобили са разпределени към кой шоурум, кой продавач е обработил конкретна продажба и т.н.

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

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

Обектно-ориентирано моделиране на данни

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

В обектно-ориентирания модел всеки обект представлява реален свят.За автокъща може да имате обект „Клиент“ с атрибути като име, адрес и телефонен номер, както и методи за актуализиране на тези данни или за изчисляване на стойността на жизнения цикъл на клиента. Всеки действителен клиент е екземпляр на класа Customer в системата.

Този стил на моделиране може да преодолее няколко ограничения на строго релационните дизайни, особено когато се работи със сложни, вложени структури или мултимедийни данни, които не се вписват добре в плоски таблици. Обектните бази данни и обектно-релационните мапери (ORM) се възползват от тази парадигма, за да намалят „несъответствието на импеданса“ между кода и съхранението на данни.

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

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

Моделиране на многомерни данни за анализи и бизнес разузнаване

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

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

Представете си отново автокъща, която изгражда хранилище за данниТаблица с факти може да съхранява всяка транзакция за продажба, включително показатели като количество и приходи, докато таблиците с измерения могат да описват „Автомобил“, „Шоурум“ и „Време“. Измерението „Автомобил“ би включвало атрибути като модел и марка; измерението „Шоурум“ би съдържало йерархии като щат, град, улица и име на шоурума.

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

Два класически физически модела за тримерни модели са звездната схема и схемата на снежинката., и двата широко използвани в BI проекти. Те споделят едно и също аналитично ядро, но се различават по това колко нормализирани са измеренията.

Модели на данни в бизнес разузнаването: звезда и снежинка

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

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

Този дизайн има голямо предимство: опростява филтрирането и агрегациите.Тъй като всяко измерение е директно свързано с таблицата с факти, заявките са ясни и инструментите могат да генерират SQL по-лесно. Например, може да имате таблица с факти за продажби, директно свързана с измерения „Автомобил“, „Клиент“, „Шоурум“ и „Време“, всички разпръснати като звездни точки.

След като сте определили измеренията, релевантни за факта, който искате да анализирате, можете да изградите триизмерен модел, който отговаря на реални бизнес въпроси: Какви са продажбите по марка автомобили и регион? Как се променят резултатите с течение на времето? Кои шоуруми се представят по-добре от други, имайки предвид подобна наличност?

Схемата „снежинка“ използва същите концептуални градивни елементи, но нормализира измеренията в множество свързани таблици.Вместо едно измерение „Местоположение“ за всяко географско ниво, можете да го разделите на „Държава“, „Регион“, „Град“ и т.н., всяко от които да се съхранява в отделна таблица и да се свързва в нормализирана структура.

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

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

Плоски, полуструктурирани и асоциативни модели на данни

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

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

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

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

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

Помислете за изречението „Световното първенство ще се проведе в Лондон на 30 май 2022 г.“Асоциативен модел може да съхранява една връзка, която гласи „Световна купа – се провежда в – Лондон“, където „Световна купа“ е източникът, „се провежда в“ е глаголът, а „Лондон“ е целта. Друга връзка би свързала първата връзка като източник с началната дата като цел, чрез глагола „от“.

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

Концептуално моделиране на данни за бизнес анализ

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

В среди като Pega и подобни платформи, концептуалният модел на данни започва с идентифициране на бизнес обекти и техните атрибути.Например, в сценарий на склад за книги, можете да дефинирате обект „Склад“ с атрибути като Име, Град и Капацитет. Допълнителни обекти като „Адрес“ и „Наличности“ ще бъдат свързани със „Склад“, за да представят къде се намира съоръжението и какви книги съхранява.

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

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

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

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

Моделите на данни като живи, стратегически активи

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

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

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

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