Я понял мысль

Можно на ты, если не сложно? На вы очень непривычно...

Нет проблем, лучше на ты :)

Привет! У автора дошли руки написать )))
Короткий ответ: нет, таблицы сущностям не тождественны
Развернутый: Из контекста все правильно уловили - речь о сущностях. Ключевых. Если и таблицах - то базовых. Т.е. центральных для некой предметной области. Например: Клиент, Договор, Счет, Платеж и т.д.
И вот этих ключевых сущностей в некой отрасли немного.
(это не мое "открытие" - сказал один разумный уважаемый человек - и я с ним внутренне согласна)
А то что таблиц в реалии больше - то ну да - таковы реалии. И это тоже важно - ибо "дьявол скрывается в мелочах"

Всем бобра! :)

Можно узнать, в какой отрасли вы думаете, что 20-30 сущностей?

Т.е. сущность клиент это может быть набор таблиц для b2b клиентов, частных лиц, справочник типов клиентов и прочие таблицы, которые при большом уровне абстракции объединятся понятием - сущность клиент ?

Да, это центральная сущность бизнес-домена. И да, это вырастает в реалии в набор таблиц.

Вопрос провокационный 😉 И видимо, из какой-то особой "боли" вопрошающего. Поэтому, промолчу ))

@Verlena я правильно понимаю, что в разговоре про "20-30" сущностей речь идет о сущностях определенного направления бизнеса, а не всей компании в целом?
я к тому, что в. нашем хранилище, если распиливать по смыслу на линии бизнеса (логистика, производство, продажи, документооборот и тп) в каждой отдельной линии так и будет ±30, но во всем хранилище таких опорных сущностей кратно больше

Ну понятно, что бизнес может быть большим и разнообразным ))
Тут ключевая мысль - не в точном количестве сущностей, а что важно не погрязнув в деталях - выделить основные - и от них уже выстраивать более подробную картину - постепенно.
И хорошо бы иметь "картину сверху" - совсем верхним слоем.
Например, в терадатной реф. модели для банковской сфере - на самом верхнем уровне - всего 5ю оперируют (понятно, что всех подробностей это не отразит), но "сорганизует" мышление далее.

Ну это как карта. На отдалении - очертания материков. По мере приближения - можно видеть больше деталей

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

Да, это может быть проблемой.
Разного рода - начиная от выбора языка /нотации, которая будет всем понятна
Заканчивая глоссарием и балансом между уходом в облачные абстракции и излишним приземлением в тех реализации и термины систем-источников

можете поделиться опытом, как договаривались между разными подразделениями о взаимопонимании в терминах сущностей? чтобы говоря про "Клиента" из CRM, юристы понимали, что это их же "Юрлицо" и "Хозяйствующий субъект" из терминологии закупщиков

какие инструменты применяете, как выстраиваете оповещения, как отслеживаете логические связи в существующих и новых сущностях

Ох, не просто это... Это тема "архитектуры данных" и data governance. Она тяжело взлетает.
В качестве тулов, которые поддержат коллаборацию - это что-то вроде Alterix (в Райфе сейчас внедряют).
Т.е. важен некий процесс - когда бизнес посмотрит на свой словарь. И попробует договориться. И кто-то этим процессом порулит. И делать это лучше заранее - а не в рамках проектов , когда на это львиная доля времени уйдет... Ну или хотя бы переиспользовать эти результаты впоследствии.

На тему устройства бизнес-модели - это к ведению ЕДМ или бизнес-модели.. везде по-разному.

Еще можно зайти со стороны BI-отчетности. На уровне витрин/дашбордов - договориться о общей терминологии и специфике подразделений.

Начать в любом случае - имеет смысл с глоссария.

просто пока не оч понятно, как быть с кейсами, когда договориться нельзЯ. к примеру, crm-щики живут с Клиентом, они так привыкли, весь софт ориентирован на понятие Клиент. А ERP-шники всю жизнь живут с Юрлицами и весь их софт, заточен под это. и никто не желает идти на компромисс и начинать жить в терминах соседнего подразделения 🙂

Это отдельная большая тема, Ринат :)

Ладно :)

Если договориться с наскока не получается, надо искать заинтересованных в хороших данных кого-то из топов, кто поможет "договорить". Работа архитектора не только модельки строить, и печально, если у него нет "дубинки" или друга с ней же

Это может быть CDO, CAO, CIO либо transformation officer