AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.12.2016, 09:05   #21  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,619 / 3400 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
Это как? У энтитей могут быть и другие отношения.
какие?

Цитата:
Сообщение от belugin Посмотреть сообщение
Мне это тоже непонятно. Нельзя ли увидеть пример. Как правило у таких таблиц эта связь является отражением чего-то в предметной области (например обобщения). Но при этом платформа не содержит удобного способа работы с такими связями.
я ж приводил.
DimId - очень древний пример
DirParty - не очень древний.

Цитата:
Сообщение от belugin Посмотреть сообщение
Relation есть в предметной области. Entity для потребителя представляет такой relation как отсутствующий, как я понял. То есть вместо "У строки есть набор аналитик" получается "У строки есть подразделение". А сама группировка некого набора признаков в понятие "набор аналитик" исчезает.
угу.
только стоит отметить, что "исчезает" из логических рассуждений.
исчезает из концептуальной модели.
технически все остается на месте.
Старый 30.12.2016, 09:14   #22  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,991 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
какие?
Любые выразимые Relations в аксапте.

Например LendgerEntity\Relations\AccountingCurrency - RelationshipType=Association

Цитата:
я ж приводил.
DimId - очень древний пример
DirParty - не очень древний.
Аналитика есть в UI и в рассуждениях пользователя о системе. Это не чисто техническое понятие.

Адресная книга и виды ее элементов есть в UI.

Цитата:
угу.
только стоит отметить, что "исчезает" из логических рассуждений.
исчезает из концептуальной модели.
технически все остается на месте.
Вот, она есть в UI (то есть аналитика выделена в отдельную группу, и есть отдельный UI для работы с ней). Но для программиста она исчезает. Что неправильно
Старый 30.12.2016, 09:31   #23  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,619 / 3400 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
Это как? У энтитей могут быть и другие отношения
Цитата:
Сообщение от belugin Посмотреть сообщение
Любые выразимые Relations в аксапте.
не-не. давай про энтити
я утверждаю, что relations сводятся в энтити к семантике "принадлежит".
и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.

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

я так понимаю, что ты говоришь, что в энтити существуют relations-семантики.
какие типы семантик, кроме "принадлежит" существуют в энтити?

можешь сформулировать одним полным абзацем?
без отсылок к предыдущим и умолчаний?
так чтобы можно было точно понять твою мысль


Цитата:
Сообщение от belugin Посмотреть сообщение
Например LendgerEntity\Relations\AccountingCurrency - RelationshipType=Association
поясни?
как значение технического свойства влияет на уровень семантики?
с точки зрения понимания здесь будет - валюта принадлежит финансовой проводке.
разве не?

Цитата:
Сообщение от belugin Посмотреть сообщение
Аналитика есть в UI и в рассуждениях пользователя о системе. Это не чисто техническое понятие.
аналитика - да.
но не "комбинации аналитик" и не dimID.

с точки зрения рассуждений пользователя о системе - в каждой проводке указана аналитика. другими словами, аналитика принадлежит проводке.

а вот то, что это отдельная таблица - это сугубо технический аспект реализации.

Цитата:
Сообщение от belugin Посмотреть сообщение
Адресная книга и виды ее элементов есть в UI.
адресная книга - да.
но не разбивка на это безумное число таблиц, которые требуют связей между собой.

обрати внимание, как об этом думаешь:
адреса принадлежат поставке (поставка содержит адреса)
контактные лица клиента...
и т.п.

а вот внутри технической реализации будут нормализованные таблицы.

Цитата:
Сообщение от belugin Посмотреть сообщение
Вот, она есть в UI (то есть аналитика выделена в отдельную группу, и есть отдельный UI для работы с ней). Но для программиста она исчезает. Что неправильно
то, что выделено в отдельную группу - особенность реализации.
с точки зрения рассуждений пользователя особой разницы нет - будет ли аналитика в отдельной группе или не будет.

а почему неправильно?
Старый 30.12.2016, 11:00   #24  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,991 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.
LedgerEntity\Relations\AccountingCurrency

Это relation между LengerEntity и CurrencyEntity

Цитата:
я так понимаю, что ты говоришь, что в энтити существуют relations.
какие типы семантик, кроме "принадлежит" существуют в энтити?
Я не очень понял о каких отношениях мы говорим - между entity, внутри entity или что?

Между entity могут быть любые отношения. Внутри Entity тоже, просто для внешнего потребителя эти отношения превращаются в плоский список. Что плохо.

Цитата:
поясни?
как значение технического свойства влияет на уровень семантики?
Цитата:

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

Она не принадлежит. При изменении чего-то в финансовой проводки состояние валюты не меняется. Может только возникнуть отношение с другой валютой.

Цитата:
аналитика - да.
но не "комбинации аналитик" и не dimID.
Комбинация аналитик выделена в отдельную группу для пользователя. DimID - да, это технический аспект того, как именно организована связь.

У нескольких проводок может быть одна и та же комбинация аналитик.

То есть бессмыслено
X++:
transaction.DimensionID += 'a';
Осмысленно.

X++:
transactions.Where(x => x.Dimension == currentTransaction.Dimension);

foreach(value in transaction.Dimension)
{
    print $' {value.name} - {value.value}';
}

Цитата:
с точки зрения рассуждений пользователя о системе - в каждой проводке указана аналитика. другими словами, аналитика принадлежит проводке.
Не "принадлежит" а "связано".

Цитата:
адресная книга - да.
но не разбивка на это безумное число таблиц, которые требуют связей между собой.
Продемонстрируй связь, не являющуюся ничем для пользователя.

Цитата:
обрати внимание, как об этом думаешь:
адреса принадлежат поставке (поставка содержит адреса)
При удалении поставки адрес не исчезает и здание не сносят.
Один и тот же адрес может относиться к разным поставкам.

Это если слово "принадлежит" для тебя composition.

Цитата:
то, что выделено в отдельную группу - особенность реализации.
с точки зрения рассуждений пользователя особой разницы нет - будет ли аналитика в отдельной группе или не будет.
Есть. Аналитика выделена в отдельную группу не по техническим соображениям, а потому, что это важно для пользователя, это набор признаков по которым операцию классифицируют финансы.

Цитата:
а почему неправильно?
Потому, что это делает программную модель сложнее и не отражает ползовательскую модель.
Старый 30.12.2016, 11:14   #25  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,619 / 3400 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
ok. в целом, понятно.
Цитата:
Сообщение от belugin Посмотреть сообщение
LedgerEntity\Relations\AccountingCurrency
Это relation между LengerEntity и CurrencyEntity
да, внутри энтити. это аспект технической реализации.

Цитата:
Сообщение от belugin Посмотреть сообщение
просто для внешнего потребителя эти отношения превращаются в плоский список. Что плохо.
ничего.
я собственно о том, что это "превращается" и есть цель существования энтити. насколько я понимаю.
остальное - техническая реализация под капотом. насколько я понимаю.

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

=============
дальше ты говоришь о технической реализации.
я полностью с тобой согласен про техническую реализацию.
только энтити эти особенности технической реализации прячут внутри себя и не выставляют наружу.

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

=============
upd: про интерфейс аналитик не согласен. но в этой ветке интерфейс скорее оффтопик. ну их?

Последний раз редактировалось mazzy; 30.12.2016 в 11:22.
Старый 30.12.2016, 13:30   #26  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,991 / 2133 (79) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
и насколько я понимаю, энтити - это полный аналог перехода от указателей к ссылкам. только в области баз данных.
Цитата:

Энтити может скрывать и указатели и ссылки. А может и не скрывать. Но там нет никаких ссылок. Только указатели. Например, в складских журналах указатели на складскую аналитику скрываются, как и ссылки а на финансовую - нет.


и такое скрытие имеет и плюсы, и минусы.
ровно также как скрытие технических особенностей указателя в атомарной ссылке.
Если ссылка имеет бизнес значение (например, есть бизнес процесс, который оперирует аналитикой в целом), то ее скрытие вредно на данном уровне абстракции.
Старый 30.12.2016, 15:27   #27  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,693 / 539 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
не-не. давай про энтити
я утверждаю, что relations сводятся в энтити к семантике "принадлежит".
и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.

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

я так понимаю, что ты говоришь, что в энтити существуют relations-семантики.
какие типы семантик, кроме "принадлежит" существуют в энтити?

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

Есть связи обусловленные фактами (fact oriented) и есть связи обусловленные принадлежностью (object oriented).

"Принадлежит" это на мой вкус - "object oriented", там где есть логическое структурирование и обьектная модель,
а вот "fact oriented" - принадлежности не чувствуется.

То есть как минимум две основные семантики у связей
object oriented (принадлежность)
fact oriented (логическое указание на факт)

https://en.wikipedia.org/wiki/Semantic_data_model

Прошу прощения если увел не туда
Старый 30.12.2016, 16:11   #28  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,619 / 3400 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
То есть как минимум две основные семантики у связей
object oriented (принадлежность)
fact oriented (логическое указание на факт)
есть.
и как это относится к Data Entity?
Старый 30.12.2016, 17:09   #29  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,693 / 539 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
есть.
и как это относится к Data Entity?
Контекст я чуть упустил, это да.

Но строго говоря "аналитика принадлежит проводке" это misleading (сбивающее с толку) толкование. А вот если рассматривать эту связь как fact oriented то и термины сразу будут смотреть в корень. В каждой проводке указана аналитика как факт, не более того. Нет никакой принадлежности. Parent/Сhild - отражает лишь направление связи, но не принадлежность.

А Data Entity не более чем интерфейс, внутри может быть что угодно по какой угодно связи. Еще раз прошу прощения если не уловил нюансов и оттенков, просто вдруг свежий взгляд случится.

Цитата:
с точки зрения рассуждений пользователя о системе - в каждой проводке указана аналитика. другими словами, аналитика принадлежит проводке.

а вот то, что это отдельная таблица - это сугубо технический аспект реализации.
Старый 30.12.2016, 17:12   #30  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,619 / 3400 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Контекст я чуть упустил, это да.

Но строго говоря "аналитика принадлежит проводке" это misleading (сбивающее с толку) толкование.
напоминаю, тема про Data Entity.
Не надо в ЭТОЙ ветке рассматривать в других контекстах.
Пожалуйста.

Цитата:
Сообщение от ax_mct Посмотреть сообщение
внутри может быть что угодно по какой угодно связи
да, конечно.
:facepalm:
Старый 30.12.2016, 20:34   #31  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,693 / 539 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от mazzy Посмотреть сообщение
напоминаю, тема про Data Entity.
Не надо в ЭТОЙ ветке рассматривать в других контекстах.
Пожалуйста.

да, конечно.
:facepalm:
Один черт, Data Entity могут только что-то представлять как интерфейс
и содержать как некий набор данных.
Слово "принадлежать" - неуместно. А если рассматривать как fact oriented то и голова кружиться не будет
Все, пью. С Наступающим!
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: AX Performance - What information and data to collect when you want to open a support case Blog bot DAX Blogs 0 29.09.2015 15:11
Dynamics AX Sustained Engineering: Announcing an update to enable the use of SQL Server 2014 with the AX 2012 R2 CU7 version of the Data Import/Export Framework (DIXF) Blog bot DAX Blogs 0 23.03.2015 22:12
axsa: Power BI and Dynamics AX: Part 4: Data Refresh and Q&A Blog bot DAX Blogs 0 25.02.2015 20:12
emeadaxsupport: AX Performance Troubleshooting Checklist Part 2 Blog bot DAX Blogs 0 09.09.2014 16:11
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:26.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.