Преглед на методологии за дизајн на Agile DWH

Развојот на складиште е долг и сериозен потфат.

Голем дел од животот на проектот зависи од тоа колку добро се обмислени моделот на објектот и основната структура на почетокот.

Општо прифатениот пристап бил и останува различни варијанти на комбинирање на ѕвездената шема со третата нормална форма. Како по правило, според принципот: почетни податоци - 3NF, витрини - ѕвезда. Овој пристап, временски тестиран и поддржан од голем број истражувања, е првото (а понекогаш и единственото) нешто што му доаѓа на ум на искусен специјалист за DWH кога размислува за тоа како треба да изгледа аналитичкото складиште.

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

И ако во вашиот тивок и пријатен живот како развивач на DWH одеднаш:

• се појави задачата „да се направи барем нешто брзо, а потоа ќе видиме“;
• се појави проект кој брзо се развиваше, со поврзување на нови извори и преработка на бизнис моделот најмалку еднаш неделно;
• се појави клиент кој нема поим како треба да изгледа системот и кои функции треба да ги извршува на крајот, но е подготвен да експериментира и доследно да го усовршува посакуваниот резултат додека постојано се доближува до него;
• Менаџерот на проектот се појави со добрата вест: „И сега имаме агилни!“

Или ако сте само заинтересирани да дознаете како на друг начин можете да изградите капацитети за складирање - добредојдовте на сечењето!

Што значи „флексибилност“?

Прво, да дефинираме какви својства мора да има системот за да се нарече „флексибилен“.

Одделно, вреди да се спомене дека опишаните својства треба да се однесуваат конкретно на систем, не да процес нејзиниот развој. Затоа, ако сакавте да прочитате за Agile како развојна методологија, подобро е да прочитате други статии. На пример, токму таму, на Хабре, има многу интересни материјали (како преглед и практичниИ проблематична).

Ова не значи дека процесот на развој и структурата на складиштето на податоци се целосно неповрзани. Генерално, би требало да биде значително полесно да се развие Agile складиште за агилна архитектура. Сепак, во пракса, почесто има опции со Agile развој на класичниот DWH според Kimbal и DataVault - според Waterfall, отколку среќни коинциденции на флексибилност во нејзините две форми на еден проект.

Значи, какви способности треба да има флексибилното складирање? Тука има три точки:

1. Рана испорака и брз пресврт - тоа значи дека идеално првиот деловен резултат (на пример, првите работни извештаи) треба да се добие што е можно порано, односно дури и пред целиот систем да биде целосно дизајниран и имплементиран. Покрај тоа, секоја следна ревизија треба да одземе што е можно помалку време.
2. Итеративно префинетост - ова значи дека секое следно подобрување идеално не треба да влијае на функционалноста што веќе работи. Токму овој момент често станува најголемиот кошмар на големи проекти - порано или подоцна, поединечните објекти почнуваат да стекнуваат толку многу врски што станува полесно целосно да се повтори логиката во копија во близина отколку да се додаде поле на постоечка табела. И ако сте изненадени дека анализата на влијанието на подобрувањата на постоечките објекти може да потрае повеќе време отколку самите подобрувања, најверојатно сè уште не сте работеле со големи складишта за податоци во банкарството или телекомуникациите.
3. Постојано се прилагодува на променливите деловни барања - целокупната структура на објектот треба да биде дизајнирана не само земајќи го предвид можното проширување, туку со очекување дека насоката на ова следно проширување не може ни да се сонува во фазата на дизајнирање.

И да, исполнувањето на сите овие барања во еден систем е можно (се разбира, во одредени случаи и со одредени резерви).

Подолу ќе разгледам две од најпопуларните методологии за агилен дизајн за складишта на податоци - Модел на сидро и Сеф со податоци. Надвор од заградите се толку одлични техники како, на пример, EAV, 6NF (во чиста форма) и сè што е поврзано со решенијата NoSQL - не затоа што се некако полоши, па дури ни затоа што во овој случај статијата би се заканувала да се здобие волуменот на просечниот дисер. Само што сето ова се однесува на решенија од малку поинаква класа - или со техники што можете да ги користите во конкретни случаи, без оглед на целокупната архитектура на вашиот проект (како EAV), или на глобално други парадигми за складирање информации (како што се бази на податоци за графикони и други опции NoSQL).

Проблеми на „класичниот“ пристап и нивните решенија во флексибилни методологии

Под „класичен“ пристап мислам на старата добра ѕвезда (без разлика на специфичната имплементација на основните слоеви, нека ми простат следбениците на Кимбал, Инмон и ЦДМ).

1. Цврста кардиналност на врските

Овој модел се заснова на јасна поделба на податоците на Димензија и факти. И ова, по ѓаволите, е логично - на крајот на краиштата, анализата на податоците во огромно мнозинство случаи се сведува на анализа на одредени нумерички индикатори (факти) во одредени делови (димензии).

Во овој случај, врските помеѓу објектите се воспоставуваат во форма на односи помеѓу табелите со помош на странски клуч. Ова изгледа сосема природно, но веднаш доведува до првото ограничување на флексибилноста - строго дефинирање на кардиналноста на врските.

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

На пример, при дизајнирање на објектот „примање готовина“, вие, потпирајќи се на заклетвата на одделот за продажба, ја поставивте можноста за акција едно унапредување за неколку контролни позиции (но не и обратно):

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

(Сите изведени објекти во кои е приклучена проверката за промоција сега исто така треба да се подобрат).

Врски во Data Vault и Anchor Model

Избегнувањето на оваа ситуација се покажа како прилично едноставно: не мора да му верувате на одделот за продажба за да го стори тоа. сите врски првично се чуваат во посебни табели и обработете го како многу-на-многу.

Овој пристап беше предложен Ден Линстед како дел од парадигмата Сеф со податоци и целосно поддржан Ларс Ронбек в Модел на сидро.

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

Односите помеѓу објектите не се зачувани во атрибути на матичните ентитети, туку се посебен тип на објект.

В Сеф со податоци таквите табели за поврзување се нарекуваат линки внатре Модел на сидро - тај. На прв поглед, тие се многу слични, иако нивните разлики не завршуваат со името (за што ќе се дискутира подолу). Во двете архитектури, табелите за врски можат да се поврзат кој било број на субјекти (не мора 2).

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

2. Умножување на податоците

Вториот проблем решен со флексибилни архитектури е помалку очигледен и е својствен на прво место. Мерења од типот SCD2 (полека менување на димензиите од вториот тип), иако не само тие.

Во класичен магацин, димензијата е типично табела која содржи сурогат клуч (како PK) и збир на деловни клучеви и атрибути во посебни колони.

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

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

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

Обично ова води до истите информации се чуваат истовремено на неколку места. На пример, информациите за регионот на живеење и категоријата на клиентот можат истовремено да се складираат во димензиите „Клиент“ и фактите „Купување“, „Испорака“ и „Повици во Центарот за повици“, како и во „Клиент - менаџер на клиентите“. Табела за врски.

Општо земено, горенаведеното се однесува на редовните (неверзионирани) димензии, но во верзиските тие може да имаат различен размер: појавата на нова верзија на објектот (особено во ретроспектива) води не само до ажурирање на сите поврзани табели, но до каскадниот изглед на новите верзии на поврзани објекти - кога Табела 1 се користи за изградба на Табела 2, а Табела 2 се користи за изградба на Табела 3 итн. Дури и ако ниту еден атрибут од Табела 1 не е вклучен во изградбата на Табела 3 (и се вклучени и други атрибути на Табела 2 добиени од други извори), верзиирањето на оваа конструкција ќе доведе до минимум дополнителни трошоци, а максимум до дополнителни верзии во Табела 3. што нема никаква врска со тоа и понатаму низ синџирот.

3. Нелинеарна сложеност на преработката

Во исто време, секој нов излог изграден врз основа на друг го зголемува бројот на места каде што податоците може да се „разминуваат“ кога се прават промени во ETL. Ова, пак, доведува до зголемување на сложеноста (и времетраењето) на секоја следна ревизија.

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

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

Складирање објекти и атрибути во Data Vault и Anchor Model

Пристапот предложен од авторите на флексибилните архитектури може да се формулира на следниов начин:

Неопходно е да се одвои што се менува од она што останува исто. Тоа е, складирајте ги клучевите одделно од атрибутите.

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

Ставовите на гледање се разликуваат за тоа што точно може да се смета за непроменливо во Data Vault и Anchor Model.

Од архитектонска гледна точка Сеф со податоци, може да се смета за непроменета цел сет на клучеви - природен (TIN на организацијата, код на производот во изворниот систем итн.) и сурогат. Во овој случај, преостанатите атрибути може да се поделат во групи според изворот и/или зачестеноста на промените и Одржувајте посебна табела за секоја група со независен сет на верзии.

Во парадигмата Модел на сидро се смета за непроменет само сурогат клуч суштина. Сè друго (вклучувајќи ги и природните клучеви) е само посебен случај на неговите атрибути. При што сите атрибути се стандардно независни еден од друг, така што за секој атрибут a посебна табела.

В Сеф со податоци се повикуваат табелите кои содржат ентитети клучеви Хубами. Хабовите секогаш содржат фиксен сет на полиња:

• Клучеви за природни ентитети
• Сурогат клуч
• Линк до изворот
• Запишете го времето за додавање

Објави во Hubs никогаш не се менувајте и немајте верзии. Однадвор, хабовите се многу слични на табелите со тип на ID-мапа што се користат во некои системи за генерирање на сурогати, сепак, се препорачува да се користи хаш од збир на деловни клучеви како сурогати во Data Vault. Овој пристап го поедноставува вчитувањето на врските и атрибутите од изворите (не треба да се придружите на центарот за да добиете сурогат, само треба да го пресметате хашот на природниот клуч), но може да предизвика други проблеми (поврзани, на пример, со судири , букви и знаци кои не можат да се печатат во копчињата со низа итн. .p.), затоа не е општо прифатено.

Сите други атрибути на ентитети се зачувани во посебни табели наречени Сателити. Еден центар може да има неколку сателити кои складираат различни групи на атрибути.

Распределбата на атрибутите меѓу сателитите се случува според принципот промена на зглобовите — во еден сателит може да се складираат не-верзија атрибути (на пример, датум на раѓање и SNILS за поединец), во друг - ретко променливи верзии (на пример, презиме и број на пасош), во третиот - често менување (на пример, адреса за испорака, категорија, датум на последната нарачка итн.). Во овој случај, верзиите се вршат на ниво на поединечни сателити, а не на ентитетот како целина, па затоа се препорачува да се дистрибуираат атрибути така што пресекот на верзиите во еден сателит е минимален (што го намалува вкупниот број на зачувани верзии ).

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

Сателитите комуницираат со Hub преку странски клуч (што одговара на кардиналноста од 1 до многу). Ова значи дека повеќе вредности на атрибути (на пример, повеќе телефонски броеви за контакт за еден клиент) се поддржани од оваа „стандардна“ архитектура.

В Модел на сидро табелите што ги чуваат клучевите се нарекуваат Сидра. И тие чуваат:

• Само сурогат клучеви
• Линк до изворот
• Запишете го времето за додавање

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

На пример, ако податоците за истиот ентитет можат да доаѓаат од различни системи, од кои секој користи свој природен клуч. Во Data Vault, ова може да доведе до прилично незгодни структури од неколку хабови (еден по извор + обединувачка основна верзија), додека во моделот Anchor, природниот клуч на секој извор спаѓа во својот атрибут и може да се користи при вчитување независно од сите други.

Но, тука има и една подмолна точка: ако атрибутите од различни системи се комбинираат во еден ентитет, најверојатно има некои правила на „лепење“, со што системот мора да разбере дека записите од различни извори одговараат на една инстанца на ентитетот.

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

В Модел на сидро таков ентитет најверојатно ќе биде зачуван во единственото сидро. Ова значи дека сите атрибути, без разлика од кој извор доаѓаат, ќе бидат врзани за истиот сурогат. Одвојувањето на погрешно споените записи и, генерално, следењето на релевантноста на спојувањето во таков систем може да биде многу потешко, особено ако правилата се прилично сложени и често се менуваат, а истиот атрибут може да се добие од различни извори (иако сигурно е можно, бидејќи секоја верзија на атрибутот задржува врска до нејзиниот извор).

Во секој случај, ако вашиот систем треба да ја имплементира функционалноста дедупликација, спојување записи и други МДМ елементи, вреди да се обрне особено внимание на аспектите на складирање природни клучеви во агилни методологии. Веројатно е дека поголемиот дизајн на Data Vault одеднаш ќе биде побезбеден во однос на грешките во спојувањето.

Модел на сидро обезбедува и дополнителен тип на објект наречен Јазол во суштина е посебно дегенериран тип на сидро, кој може да содржи само еден атрибут. Јазлите треба да се користат за складирање на рамни директориуми (на пример, пол, брачен статус, категорија за услуги на клиентите итн.). За разлика од Сидро, јазол нема поврзани табели за атрибути, а неговиот единствен атрибут (име) секогаш се чува во истата табела со клучот. Јазлите се поврзани со Сидрата со табели за врзување (Tie) на ист начин како што Сидрата се поврзани едни со други.

Не постои јасно мислење во врска со употребата на Јазли. На пример, Николај Голов, кој активно ја промовира употребата на Сидро моделот во Русија, верува (не неразумно) дека за ниту една референтна книга не може со сигурност да се каже дека секогаш ќе биде статичен и на едно ниво, па затоа е подобро веднаш да се користи полноправно Сидро за сите предмети.

Друга важна разлика помеѓу Data Vault и моделот Anchor е достапноста атрибути на врски:

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

Складирање на факти

Пред ова, зборувавме главно за мерно моделирање. Фактите се малку помалку јасни.

В Сеф со податоци типичен објект за складирање на факти е Врска, во чии сателити се додаваат реални индикатори.

Овој пристап изгледа интуитивен. Овозможува лесен пристап до анализираните индикатори и генерално е сличен на традиционалната табела со факти (само индикаторите не се складираат во самата табела, туку во „соседната“). Но, има и замки: една од типичните модификации на моделот - проширување на клучот за факти - бара додавање нов странски клуч на Link. И ова, пак, ја „крши“ модуларноста и потенцијално предизвикува потреба од модификации на други објекти.

В Модел на сидро Врската не може да има свои атрибути, така што овој пристап нема да работи - апсолутно сите атрибути и индикатори мора да бидат поврзани со едно специфично сидро. Заклучокот од ова е едноставен - На секој факт му треба и свое сидро. За некои од она што сме навикнати да ги перципираме како факти, ова може да изгледа природно - на пример, фактот за купување може совршено да се сведе на предметот „нарачка“ или „прием“, посета на страница на сесија итн. Но, има и факти за кои не е толку лесно да се најде таков природен „предмет на превозникот“ - на пример, остатоци од стоки во магацините на почетокот на секој ден.

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

Како се постигнува флексибилност

Добиената конструкција во двата случаи содржи значително повеќе табелиотколку традиционалното мерење. Но, може да потрае значително помалку простор на дискот со истиот сет на верзии на атрибути како и традиционалната димензија. Секако, тука нема магија - се работи за нормализација. Со дистрибуција на атрибути низ сателити (во Data Vault) или поединечни табели (Anchor Model), ние го намалуваме (или целосно го елиминираме) дуплирање на вредностите на некои атрибути при промена на други.

За Сеф со податоци добивките ќе зависат од распределбата на атрибутите меѓу Сателитите и за Модел на сидро - е речиси директно пропорционална со просечниот број на верзии по мерниот објект.

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

Ова исто така наликува на преминот од производство на парчиња во масовно производство - ако во традиционалниот пристап секоја табела на моделот е единствена и бара посебно внимание, тогаш во флексибилните методологии тоа е веќе збир на стандардни „делови“. Од една страна, има повеќе табели, а процесите на вчитување и преземање податоци треба да изгледаат покомплицирани. Од друга страна, тие стануваат типичен. Што значи дека може да има автоматизирано и управувано со метаподатоци. Прашањето „како ќе го поставиме?“, одговорот на кој би можел да заземе значителен дел од работата за дизајнирање подобрувања, сега едноставно не вреди (како и прашањето за влијанието на промената на моделот врз работните процеси ).

Ова не значи дека воопшто не се потребни аналитичари во таков систем - некој сè уште треба да работи низ множеството објекти со атрибути и да открие каде и како да го вчита сето тоа. Но, обемот на работа, како и веројатноста и цената на грешка, се значително намалени. И во фазата на анализа и во текот на развојот на ETL, што во значителен дел може да се сведе на уредување на метаподатоци.

Темната страна

Сето горенаведено ги прави двата пристапи навистина флексибилни, технолошки напредни и погодни за итеративно подобрување. Се разбира, има и „буре во маста“, за кое мислам дека веќе можете да погодите.

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

Постојат неколку факти кои ја олеснуваат оваа ситуација:

Кога работите со големи димензии, сите негови атрибути речиси никогаш не се користат истовремено. Ова значи дека може да има помалку спојувања отколку што изгледа на прв поглед на моделот. Data Vault може да ја земе предвид и очекуваната фреквенција на споделување при доделување атрибути на сателити. Во исто време, самите Hubs или Anchors се потребни првенствено за генерирање и мапирање на сурогати во фазата на вчитување и ретко се користат во прашања (ова особено важи за Anchors).

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

На пример, овде внатре ова Статијата содржи детален компаративен тест за перформансите на моделот Anchor со примерок од една табела.

Многу зависи од моторот. Многу модерни платформи имаат внатрешни механизми за оптимизација на спојување. На пример, MS SQL и Oracle можат да „прескокнуваат“ спојувања на табели ако нивните податоци не се користат никаде освен за други спојувања и не влијаат на конечниот избор (елиминација на табела/приклучување) и MPP Vertica искуство на колегите од Авито, се покажа како одличен мотор за моделот Anchor, со оглед на одредена рачна оптимизација на планот за пребарување. Од друга страна, складирањето на моделот Anchor, на пример, на Click House, кој има ограничена поддршка за приклучување, сè уште не изгледа како многу добра идеја.

Покрај тоа, за двете архитектури постојат посебни потези, олеснувајќи го пристапот до податоците (и од гледна точка на перформансите на барањето и за крајните корисници). На пример, Табели во точка-во-време во Data Vault или специјални функции на табелата во моделот Сидро.

Во вкупен

Главната суштина на разгледуваните флексибилни архитектури е модуларноста на нивниот „дизајн“.

Токму овој имот овозможува:

• По некоја почетна подготовка поврзана со распоредување на метаподатоци и пишување основни ETL алгоритми, брзо да му обезбеди на клиентот првиот резултат во форма на неколку извештаи кои содржат податоци од само неколку изворни објекти. Не е неопходно целосно да се размисли (дури и на највисоко ниво) на целиот модел на објект.
• Моделот на податоци може да почне да работи (и да биде корисен) со само 2-3 објекти, а потоа расте постепено (во врска со моделот Сидро Николај Применето убава споредба со мицелиум).
• Повеќето подобрувања, вклучително и проширување на предметната област и додавање нови извори не влијае на постоечката функционалност и не претставува ризик од кршење на нешто што веќе работи.
• Благодарение на распаѓањето на стандардни елементи, процесите на ETL во таквите системи изгледаат исто, нивното пишување се посветува на алгоритмизација и, на крајот, автоматизација.

Цената на оваа флексибилност е изведба. Ова не значи дека е невозможно да се постигнат прифатливи перформанси на такви модели. Почесто отколку не, можеби едноставно ќе ви треба повеќе напор и внимание на деталите за да ги постигнете метриките што ги сакате.

Апликации

Типови на ентитети Сеф со податоци

Повеќе информации за Data Vault:
Веб-страницата на Ден Лиштад
Сè за сводот на податоци на руски
За сводот на податоци на Хабре

Типови на ентитети Модел на сидро

Повеќе детали за моделот сидро:

Веб-страница на креаторите на Anchor Model
Статија за искуството од имплементирање на Anchor Model во Avito

Збирна табела со заеднички карактеристики и разлики на разгледуваните пристапи:

Извор: www.habr.com