Моделирање података: објашњење техника, врста и употребе у стварном свету

Почетна » Питон » Моделирање података: објашњење техника, врста и употребе у стварном свету

Моделирање података је једна од оних дисциплина које тихо одлучују да ли ће ваши пројекти података успети или пропасти.Иза сваке аналитичке контролне табле, трансакционог система или пословне интелигенције (BI) стоји модел података који описује који подаци постоје, како се повезују и како се користе сваког дана. Када је тај модел јасан и добро дизајниран, развој постаје лакши, извештаји су поуздани и сви говоре истим језиком о послу.

У својој суштини, модел података је формални, визуелни начин описивања пословних информација: који ентитети постоје (купци, производи, складишта, фактуре...), који атрибути их дефинишу (име, адреса, капацитет, цена...) и како су међусобно повезани. Различите технике моделирања и типови модела су се развијали током година, вођени новим технологијама база података, потребама управљања и модерним случајевима употребе аналитике као што су пословна интелигенција (BI) и складиштење података.

Шта је модел података?

Модел података је апстрактни план о томе како су информације структуриране унутар системаДефинише елементе података, правила која њима управљају и односе који их повезују, много пре него што се било шта заправо имплементира у бази података или апликацији. Замислите то као архитектонски план који инжењер прати пре него што излије бетон.

У практичном смислу, модел података показује како се подаци чувају, повезују, приступају и ажурирају унутар система за управљање базама података. Користећи симболе, оквире, линије и текст, пружа пословним заинтересованим странама, аналитичарима, архитектама и програмерима заједничку слику информација које су организацији битне, тако да сви могу да размишљају о томе и рано уоче проблеме.

Један од главних циљева модела података је да експлицитно дефинише типове података који се користе и чувају у систему., како се ти типови групишу, како се могу организовати у структуре и које формате и атрибуте носе. Ово укључује дефинисање кључева, ограничења, кардиналности и конвенција именовања које ће касније покретати техничку имплементацију.

Модели података се не креирају у вакууму; они су вођени пословним захтевимаПре него што почне моделирање, правила и потребе се прикупљају од пословних заинтересованих страна и крајњих корисника. Та правила се затим преводе у структуре података које обликују дизајн новог система или еволуцију постојећег. У том смислу, модел података је веома сличан мапи пута: он не извршава ништа, али вам говори како да стигнете од тачке А до тачке Б.

Добро моделирање података ослања се на стандардизоване шеме и формалне техникеОва стандардизација пружа доследан, предвидљив начин дефинисања и управљања ресурсима података у тимовима, одељењима, па чак и спољним партнерима. Идеално би било да модели постану живи документи који се развијају како се организација мења, подржавајући побољшање процеса и водећи одлуке о ИТ архитектури.

Шта је моделирање података?

Моделирање података је процес мапирања и визуелизације где се подаци налазе и како се крећу кроз системИдентификујете сва места где ће апликација, интеграција или BI платформа чувати информације, а затим дизајнирате како се ти скупови података повезују и међусобно делују.

Унутар сваког ИТ пројекта, моделирање података је критична фаза дизајнирањаДок је решење још увек у фази цртања, тим одређује које пословне проблеме треба решити, који су подаци потребни за решавање тих проблема и како ће те податке користити корисници и други системи. То разумевање се затим претвара у дијаграме који описују како се различите групе података повезују и крећу између компоненти.

Резултат моделирања података је обично један или више дијаграма (или модела) који илуструју како се свака група података односи на остале.То могу бити концептуални дијаграми за пословну публику, логички модели који детаљније приказују структуре и односе или физички модели директно повезани са табелама и колонама базе података. Сваки ниво апстракције усавршава претходни, приближавајући се имплементацији.

Подаци се могу моделирати на неколико нивоа апстракције, од концепата веома високог нивоа до потпуно детаљних шемаЖивотни циклус моделирања обично почиње разумевањем захтева заинтересованих страна, претварањем пословних правила у структуре података, а затим усавршавањем тих структура у конкретан дизајн базе података. Успут, празнине, недоследности или недостајући елементи података постају видљиви и могу се исправити пре него што постану проблеми у производњи.

Пошто се захтеви развијају, моделе података треба третирати као живе артефактеОни се поново разматрају кад год се додају нове функције, појаве интеграције, промене прописи или појаве нове потребе за аналитиком. Дељени модели се чак могу размењивати са добављачима и партнерима како би се ускладио начин на који се подаци разумеју и размењују између организација.

Главне технике моделирања података и типови модела

Временом су се појавиле различите технике моделирања података, свака оптимизована за одређене технологије и случајеве употребеОд раних хијерархијских база података до модерних димензионалних и асоцијативних приступа који се користе у пословној интелигенцији, сваки стил нуди посебне предности и мане у погледу флексибилности, перформанси и лакоће разумевања.

У наставку ћете пронаћи детаљан преглед најважнијих типова модела података., илустровано конкретним примерима као што су ауто-салони, складишта и BI звездасте шеме, и објашњено пословним језиком тако да могу да прате и технички и нетехнички читаоци.

Хијерархијско моделирање података

Хијерархијски модел података организује информације у структуру сличну дрвету, са једним кореном на врху и више нивоа подређених чворова испод њега. Сваки родитељски чвор може имати више подређених чворова, али свако подређено чворово има тачно једног родитеља, што резултира строгим обрасцем односа један-према-више.

У овом приступу, односи се крећу дуж једне путање од родитеља до дететаНе постоји концепт записа који има више родитеља. Показивачи (или везе) повезују родитеље са њиховом децом, а ви прелазите преко тих показивача да бисте приступили подацима или их ажурирали. Пошто се сваки запис налази на дефинисаном месту у стаблу, једноставно је расуђивати о његовом пореклу.

Размотрите пример ауто-салонаЧвор највишег нивоа би могао да представља „Изложбене салоне“. Сваки чвор изложбеног салона би имао подчворове за „Аутомобиле“ и „Продавце“, пошто један изложбени салон може да угости много аутомобила и запосли много продаваца. Навигација би увек почела од изложбеног салона и кретала се надоле да би се видело који аутомобили и продајно особље му припадају.

Хијерархијски модели су одлични када је ваша структура у стварном свету природно у облику дрвета., као што су мапе сајтова веб-сајтова, организационе шеме, прегледи рецепата или категорије производа на сајту за е-трговину. На пример, „Ципеле“ могу бити матична категорија, са подређеним чворовима као што су „Женске ципеле“ и „Мушке ципеле“, и даљим подређеним чворовима као што су „Патике“, „Штикле“ или „Чизме“.

Овај стил има неке јасне карактеристике и ограничења: односи су строго један-према-више, добијате само једну путању од корена до било ког датог детета, а брисање родитеља обично аутоматски уклања сву његову децу. То каскадно брисање може бити згодно, али и ризично ако нисте пажљиви у вези са семантиком ваше хијерархије.

Моделирање мрежних података

Мрежни модел података проширује хијерархијски приступ тако што дозвољава да записи имају више родитељаУместо чистог стабла, добијате мрежу међусобно повезаних записа налик графу, као што је управљане графичке базе података, што олакшава представљање сложених ситуација из стварног света.

У мрежном моделу, могући су много више образаца односаМожете да обрађујете не само један-према-више, већ и један-према-један и више-према-више. Чворови могу бити повезани преко више рута, што значи да може постојати неколико начина да се дође до истог записа приликом навигације кроз структуру.

Замислите студента који је на одсеку за рачунарске науке, али такође има право позајмљивања књига у библиотеци.У мрежном моделу, тај запис „Студент“ може имати два родитељска записа: један за „Одељење за стручно образовање и образовање“ и други за „Библиотеку“. Ово је било немогуће у строгом хијерархијском стаблу где дете може имати само једног родитеља.

Основне операције у мрежним моделима се често имплементирају коришћењем кружних повезаних листаПрограм прати „тренутну позицију“ на тој листи и креће се кроз повезане записе у складу са дефинисаним односима. Ово чини прелажење брзим и флексибилним, јер можете пратити више могућих рута до истог податка.

Због веће повезаности, мрежни модели могу представљати нијансираније односе из стварног света., али такође постају сложенији за разумевање и управљање. Дизајнирање и одржавање свих веза може бити изазовно, посебно за велике шеме и пословна правила која се стално развијају.

Моделирање података ентитет-релација (ER)

Модел ентитет-релација је визуелни начин описивања захтева за подацима на високом нивоу коришћењем ER дијаграма.То је једна од најчешће коришћених техника за концептуално и логичко моделирање података, посебно када се ради са пословним заинтересованим странама којима је потребна јасна слика без техничке гужве.

У ER дијаграму, основни градивни блокови су ентитети, атрибути и односиЕнтитети представљају ствари из стварног света које су битне предузећу (као што су „Студент“, „Наставник“, „Курс“ или „Одељење“). Атрибути обухватају својства тих ентитета (као што су ИД наставника, плата, године), а односи показују како су ентитети повезани (на пример, „Наставник ради за одељење“).

Ентитети се обично цртају као правоугаоници, атрибути као овали, а односи као ромбови или означене линијеКардиналности (као што је један-према-више или више-према-више) показују колико инстанци сваког ентитета може бити повезано заједно. Ова нотација вам омогућава да забележите сложена правила у дијаграму који је и даље релативно лак за читање.

Архитекте података користе ER алате за дизајнирање и усавршавање ових моделаУ многим случајевима, ER дијаграми постају мост између пословне анализе и имплементације базе података: када се ER модел договори, он се може систематски трансформисати у релационе табеле, кључеве и ограничења.

Пошто ER моделирање функционише на релативно високом нивоу апстракције, одличан је за потврђивање разумевања са заинтересованим странама. Можете прегледати дијаграм на радионицама, питати да ли су присутни сви потребни ентитети и односи и прилагодити дизајн пре него што пређете на техничке слојеве.

Релационо моделирање података

Релациони модел је окосница већине традиционалних система база податакаОвде се подаци чувају у дводимензионалним табелама направљеним од редова и колона, а односи између табела су изражени преко кључева, а не преко експлицитних показивача као у хијерархијским или мрежним моделима.

Свака табела у релационом моделу се често назива „релација“, мада ћете у пракси чути људе да их једноставно називају табелама. Редови су познати као торке и представљају појединачне записе или инстанце, док су колоне атрибути (или поља) који дефинишу својства сачувана за сваки запис.

Узмимо поново ауто-салон као примерМожда имате табелу „Продавци“ са колонама као што су ИД продавца и Име, и посебну табелу „Аутомобили“ са колонама као што су ИД аутомобила и Марка. Сваки ред у табели Продавци представља стварног продавца, а сваки ред у табели Аутомобили представља стварно возило.

Примарни кључеви и страни кључеви играју кључну улогу у релационом моделуПримарни кључ јединствено идентификује сваки ред у табели (нпр. ID продавца или ID аутомобила). Ови кључеви се затим могу појавити као страни кључеви у другим табелама како би представили односе. На пример, табела „Изложбени салони“ може да садржи и ID продавца и ID аутомобила као стране кључеве, повезујући изложбени салон са продавцем који тамо ради и изложеним аутомобилом.

Сарадња између примарних и страних кључева је оно што омогућава релационим базама података да представљају сложене мреже пословних односа.Када упитујете базу података, можете спојити табеле на овим кључевима, користећи анализа података помоћу SQL-а и да реконструишу асоцијације из стварног света: који аутомобили су додељени ком салону, који продавац је обавио одређену продају и тако даље.

Сарадња између примарних и страних кључева је оно што омогућава релационим базама података да представљају сложене мреже пословних односа.Када упитујете базу података, можете спојити табеле на овим кључевима да бисте реконструисали асоцијације из стварног света: који аутомобили су додељени ком салону, који продавац је обавио одређену продају и тако даље.

Релациони модел је моћан, добро разумљив и снажно подржан од стране зрелих технологијаБлиста када су подаци високо структурирани и конзистентност је критична. Међутим, може наићи на ограничења код веома сложених објеката, мултимедијалног садржаја или ултра-флексибилних шема где се структура често мења.

Објектно оријентисано моделирање података

Објектно оријентисано моделирање података доноси концепте из објектно оријентисаног програмирања у свет податакаУместо да размишљате само у смислу табела и редова, моделујете информације као објекте који обједињују податке (атрибуте) заједно са понашањем (методе), одражавајући начин на који су написане модерне апликације.

У објектно оријентисаном моделу, сваки објекат представља ентитет из стварног светаЗа ауто-салон, можете имати објекат „Купац“ са атрибутима као што су име, адреса и број телефона, и методама за ажурирање тих података или израчунавање вредности животног века купца. Сваки стварни купац је тада инстанца класе Купац у систему.

Овај стил моделирања може превазићи неколико ограничења строго релационих дизајна, посебно када се ради о сложеним, угнежђеним структурама или мултимедијалним подацима који се не уклапају лепо у равне табеле. Објектне базе података и објектно-релациони мапери (ORM) користе ову парадигму да би смањили „неусклађеност импедансе“ између кода и складиштења података.

Објектно оријентисани модели су уобичајени у мултимедијалним и напредним сценаријима примене, где је чување слика, видео записа или угнежђених докумената као кохезивних објеката природније него дељење свега на бројне релационе табеле. Међутим, оне могу увести сложеност у упите, извештавање и интеграцију ако нисте пажљиви.

Зато што је објектни модел често веома близак начину на који програмери размишљају, може убрзати развој апликација. Компромис је у томе што су чисто објектне базе података мање уобичајене од релационих, а њихова интеграција у шире екосистеме података (посебно за пословну интелигенцију) може бити изазовнија.

Димензионално моделирање података за аналитику и пословну интелигенцију

Димензионално моделирање података је главни приступ за складишта података и решења за пословну интелигенцијуЊегов главни циљ је оптимизација структура података за брзо упите, агрегацију и извештавање, чак и ако то значи намерно дуплирање или денорализацију података.

У димензионалном моделу, подаци су организовани у табеле чињеница и табеле димензијаТабеле чињеница чувају квантитативне, мерљиве догађаје (продају, кликове, испоруке, трансакције), док димензионалне табеле пружају дескриптивне контексте (време, производ, купац, локација) који вам омогућавају да анализирате чињенице из више углова.

Замислите поново ауто-салон који гради складиште податакаТабела чињеница може да чува сваку продајну трансакцију, укључујући метрике попут количине и прихода, док табеле димензија могу да описују „Аутомобил“, „Изложбени салон“ и „Време“. Димензија „Аутомобил“ би укључивала атрибуте попут модела и бренда; димензија „Изложбени салон“ би садржала хијерархије попут државе, града, улице и назива изложбеног салона.

Димензионални модели често намерно дуплирају неке податке у табеламаОва редундантност је свестан избор дизајна како би се убрзали упити и анализа учинила једноставном за BI кориснике. Аналитичари могу филтрирати, агрегирати и ротирати атрибуте димензија без плаћања казне за перформансе високо нормализованих релационих шема.

Два класична физичка обрасца за димензионалне моделе су звездана шема и шема пахуљице., оба се широко користе у BI пројектима. Деле исто аналитичко језгро, али се разликују по томе колико су димензије нормализоване.

Модели података у пословној интелигенцији: звезда и пахуља

У свету пословне интелигенције (BI), када људи говоре о „моделу података“, често мисле на шему звезде или пахуљице која стоји иза њихових извештаја.Ове шеме дефинишу како су чињенице и димензије повезане и снажно утичу на перформансе, употребљивост и флексибилност аналитичких алата.

Звездана шема се врти око централне табеле чињеница који садржи мере које се анализирају на најнижем корисном нивоу детаља (зрно), плус стране кључеве који се повезују са околним табелама димензија. Све димензије се директно повезују са табелом чињеница, формирајући облик звезде.

Овај дизајн има велику предност: поједностављује филтрирање и агрегацијеПошто је свака димензија директно повезана са табелом чињеница, упити су једноставни и алати могу лакше генерисати SQL. На пример, можете имати табелу чињеница о продаји директно повезану са димензијама Аутомобил, Купац, Изложбени салон и Време, које се све шире попут звездастих тачака.

Када идентификујете димензије релевантне за чињеницу коју желите да анализирате, можете направити димензионални модел који одговара на стварна пословна питања: Колика је продаја по марки аутомобила и региону? Како се резултати крећу током времена? Који салони надмашују друге с обзиром на сличан инвентар?

Шема пахуљице користи исте концептуалне градивне блокове, али нормализује димензије у више повезаних табелаУместо једне димензије „Локација“ за сваки ниво географије, можете је поделити на „Земља“, „Регион“, „Град“ и тако даље, сваку сачувану у својој табели и повезану у нормализовану структуру.

Модели пахуљица су сложенији од звезданих шема али прате исту аналитичку логику. Користе се када су подаци димензија велики, дељени или им је потребна јача нормализација како би се избегла редундантност. На пример, димензија „Производ“ може се поделити у одвојене табеле за „Производ“, „Бренд“ и „Категорија“, свака нормализована и повезана преко кључева.

Практичари често упоређују шеме звезда и пахуљица према критеријумима као што су перформансе, складиштење, напор одржавања и једноставност коришћења.Звездасте шеме генерално побеђују због једноставности и брзине упита, док пахуљице могу уштедети простор за складиштење и смањити одржавање тамо где су хијерархије димензија сложене или се често поново користе у више табела чињеница.

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

Изван класичних хијерархијских, мрежних, ER, релационих, објектних и димензионалних модела, постоји још неколико стилова које вреди знати, посебно у модерним платформама података и сценаријима интеграције.

Равни модел података је најједноставнија могућа репрезентацијаСви подаци се чувају у једној табели са редовима и колонама, без икаквих експлицитних веза или структуре изван тога. Да би приступио одређеном подскупу информација, систем може морати да прочита велики део табеле, што успорава и чини операције неефикасним како количина података расте.

Полуструктурирани модел је флексибилнија еволуција релационог приступаКод полуструктурираних података, не постоји увек јасна разлика између података и шеме. Неким ентитетима могу недостајати одређени атрибути, док други могу имати додатна поља која нису присутна код њихових вршњака, и то је сасвим прихватљиво.

Ова флексибилност је типична за формате као што су JSON, XML или неке NoSQL базе података.Атрибут може да садржи једноставну атомску вредност или целу колекцију, а структура може да варира од записа до записа. Ово је моћно када се ради са изворима података који се мењају или су хетерогени, али компликује строгу валидацију и традиционалне релационе упите.

Асоцијативни модел података заузима још једну перспективу тако што дели податке на „ставке“ и „линкове“Све што може постојати независно третира се као ставка (или елемент), док се односи између ставки чувају као везе (или асоцијације). Сваки елемент има име и идентификатор, а свака веза има свој идентификатор плус атрибуте који указују на извор, глагол и циљ.

Размотрите реченицу „Светско првенство ће се одржати у Лондону почев од 30. маја 2022. године“Асоцијативни модел би могао да чува једну везу која каже „Светско првенство – одржава се у – Лондону“, где је „Светско првенство“ извор, „одржава се у“ је глагол, а „Лондон“ је циљ. Друга веза би повезала ту прву везу као извор са датумом почетка као циљем, преко глагола „од“.

Ова перспектива заснована на везама може бити веома експресивна за графове знања и семантичке односе.Уместо скривања односа унутар спајања табела или референци на објекте, третирате их као елементе података прве класе који се могу испитати, верзионисати и анализирати сами по себи.

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

Концептуално моделирање података фокусира се на снимање пословних концепата и њихових односа на веома високом нивоу, без бриге о техничким детаљима као што су типови података, индекси или физичко складиштење. Посебно је корисно током раних фаза пројекта када још увек валидирате обим и захтеве.

У окружењима попут Pega-е и сличних платформи, концептуални модел података почиње идентификацијом пословних ентитета и њихових атрибута.На пример, у сценарију складишта књига, можете дефинисати ентитет „Складиште“ са атрибутима као што су Назив, Град и Капацитет. Додатни ентитети попут „Адресе“ и „Залихе“ били би повезани са „Складиштем“ да би представили где се објекат налази и које књиге садржи.

Добијени дијаграм визуализује те ентитете, њихове основне атрибуте и кључне односе између њихНе морате моделирати сваку појединачну тачку података потребну за постизање пословног исхода; циљ је сагледати ширу слику како би заинтересоване стране могле да виде да ли нешто очигледно недостаје или је погрешно представљено.

Када се састанете са пословним заинтересованим странама, концептуални модел постаје заједничка референцаПомаже људима да визуализују како се њихови процеси пресликавају на податке: који ентитети су укључени у сваки корак, који атрибути су потребни за завршетак случаја и где постоје зависности између одељења или система.

Улагање довољно времена у концептуални дизајн података у раној фази значајно смањује ризик од каснијег прерађивања.Ако усред пројекта откријете да су захтеви за критичним подацима погрешно схваћени или превиђени, можда ћете морати да поновите значајне делове дизајна процеса, интеграција и корисничког интерфејса. Робустан концептуални модел ублажава тај ризик откривањем неспоразума док су промене и даље јефтине.

Наравно, концептуални модели нису статичниКако пројекат напредује и тим учи више, модел може (и требало би) да се развија. Та еволуција је знак здравог открића, а не неуспеха. Кључ је у одржавању концептуалног модела као живог документа који одржава дискусије о пројекту усидрене око јасног погледа на пословне податке.

Модели података као жива, стратешка средства

У свим овим техникама и типовима модела, појављује се заједничка тема: модели података нису само технички артефакти; они су стратешки комуникациони алатиБез обзира да ли скицирате једноставан ER дијаграм или одржавате богату димензионалну шему за BI, ви кодирате како организација разуме саму себе у облику података.

Добро изграђени модели података подржавају основне пословне процесе, воде ИТ архитектуру и омогућавају поуздану аналитикуОни пружају заједнички речник између пословних и технолошких тимова, смањују двосмисленост и чине будуће промене мање болним јер се утицај тих промена може пратити кроз јасно дефинисане ентитете и односе.

Од хијерархијских стабала и мрежних графова до релационих табела, хијерархија објеката, димензионалних звезда, равних структура, полуструктурираних формата и асоцијативних веза, сваки стил моделирања доноси своје предности за одређене случајеве употребе. Модерне организације ретко користе само један; уместо тога, комбинују више приступа у својим системима и платформама података.

На крају крајева, вредност моделирања података лежи у томе колико ефикасно претвара неуредне захтеве из стварног света у кохерентне, лако управљиве структуре.Када се раде са ригорозношћу, али и са пословним прагматизмом, модели података постају темељна средства која убрзавају развој, побољшавају квалитет података и оснажују доношење одлука у целом предузећу.