Category: философия

Category was added automatically. Read all entries about "философия".

flow

Части в пространстве и времени

Так подумал, что для дальнейшего продвижения в тему стандартов желательно сначала продемонстрировать, что такое загадочные термины "3D+1" и "4D", которые там по ходу встретятся. Начнём.

Представьте себе каталог моделей мобильных телефонов. У каждого телефона есть некие атрибуты: "разрешение дисплея", "тип дисплея", etc. Это важные потребительские характеристики самого телефона. Однако, мы можем выделить "дисплей" как отдельную сущность (отдельным атрибутом), и уже к нему назначить атрибуты "разрешение", ...; при этом соблюдая их вывод inplace в характеристиках телефона (а не "параметры дисплея QQQ123 вы можете посмотреть отдельно по ссылке"). Так цепочка работы с данными становится длиннее, что изначально приводит к затратам времени разработчика.

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

Выше был пример нарезки частей в пространстве. Можно дробить атрибуты ("разрешение дисплея" вместо "разрешение"), а можно сами сущности - сначала выделяя identity "дисплей мобильного телефона модели N900" из identity "мобильный телефон модели N900".

Причём, глубина разбиений в обе стороны не ограничена. Где проводить границу в вашей модели данных - этот вопрос придётся каждый раз решать отдельно. Может сложиться ситуация с очень похожими данными, когда для потребительских характеристик выгоднее создавать новые атрибуты, а для инженерных параметров выделять новые identity.

Однако, кроме пространства есть ещё и время, этим добавляются новые возможности/необходимости разбиения.

Основных парадигм при работе со временем три:

1) 3D.
Есть некий константный срез рассматриваемого мира. В пределах среза существует отношение R, связывающее сущности a и b. Или, если сказать иначе, есть предикат R, и утверждение R(a, b) is True. Значение неизменно. Для описания модели мобильника в каталоге этого достаточно. Но при появлении темпоральных характеристик придётся строить новые виды отношений: Rt(a, b, tx), Rtt(a, b, tstart, tend), etc.
Например:
к
Есть_соединение(клиент, сервер)
придётся добавлять по мере необходимости
Есть_соединение_в_момент_времени(клиент, сервер, tx)
Есть_соединение_с_момента_времени(клиент, сервер, tstart)
Есть_соединение_в_период_времени(клиент, сервер, tstart, tend)

2) 3D+1.
Здесь появляется возможность использования темпоральных характеристик поверх существующих отношений, R(a, b)@t.
Есть_соединение(клиент, сервер)@tx
Есть_соединение(клиент, сервер)@(tstart..)
Есть_соединение(клиент, сервер)@(tstart..tend)

Как 3D+1 встречается в обычной речи: "мы занимаемся этим проектом @ с 1 апреля 2012 года".

3) 4D.
Здесь появляется возможность использования темпоральных характеристик поверх cущностей, R(a@t, b@t).
Есть_соединение(клиент@tx, сервер@tx)
Есть_соединение(клиент@(tstart..), сервер@(tstart..))
Есть_соединение(клиент@(tstart..tend), сервер@(tstart..tend))

Таким образом получаем атемпоральные отношения между темпоральными частями, имеющими свои identity.

Как 4D встречается в обычной речи: : "я @сегодня не такой, как @вчера...".

В естественных языках это есть, но до философов доходило традиционно долго, так что некоторые логики и философы считают такой подход относительно недавним прорывом, а другие ересью. Рекомендую почитать http://plato.stanford.edu/entries/temporal-parts/ Для философов выбор между 3D, 3D+1 и 4D является отдельной темой срача специальной олимпиады. Для модельеров данных - осознанным выбором для конкретной ситуации или сразу для стандарта (4D в ISO 15926).

Как и в случае с пространством, нельзя однозначно заявить, что один из подходов лучше. Для отношений, атемпорально связывающих темпоральные части, например, причина_следствие(активность1@t1.start..t1.end), активность2@t2.start..t2.end)), в 3D+1 приходится возвращаться к 3D. Темпоральные n-ary отношения R(a, b, c, d, ...)@t в 4D превращаются в кашу R(a@t, b@t, c@t, d@t, ...). А 3D прекрасно подходит там, где все необходимые реификации заранее включены в отношение, т.е. не бывает R1(a, b, c) со временем или R2t(a, b, c, d, t) без времени, что в свою очередь оптимальнее для хранения в реляционных СУБД и табличного ввода/вывода в пользовательских интерфейсах.