2009-11-01

Потерянная семантика

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

Потерянная "сила" и другие атрибуты связей. Как в реляционных СУБД, так и в языках программирования, понятие ссылки сводится к идентификации и не позволяет добавлять дополнительные атрибуты связей. Однако, на практике часто бывает полезно учитывать силу, давность или стойкость связи между объектами. Атрибуты связей можно разделить на параметры и классифицирующие атрибуты связей, но и те и другие очень просто моделируются средствами реляционных СУБД, декларативными языками описания как XML, JSON, CLEAR, или активными языками программирования. Главное, не забыть, о том, что ссылки не равносильны, структурно сложны и не могут быть сведены к простым указателям. Есть и исключения, например, во многих СУБД можно определить операции Cascade, Restrict, Update для связей между сущностными, но эти операции описывают не атрибуты, а действия и не могут быть условными или содержать формулы, вложенные запросы, динамические вычисления или алгоритмы. Они хороши только для самых простых случаев, а как только появляется условие, то потерянную семантику приходится реализовывать в виде хранимых процедур и триггеров.

Потерянная целостность объектов. Реляционная декомпозиция и объектная декомпозиция размещает атрибуты одной сущности во многих таблицах и многих классах, однако, это приводит к тому, что обратная операция в большинстве случаев уже не возможна без человека или алгоритма, подготовленного как дополнение к информационной модели. Часть атрибутов описаны как поля таблицы, другие же атрибуты - вынесены в другие таблицы, которые ссылаются на описываемую сущность. Но связи в реляционной модели используются не только для внутреннего моделирования объектов и их сложных свойств, но и для описания внешних отношений между разными объектами. Таким образом по связи невозможно однозначно определить, является ли дочерняя таблица частью родительской сущности или отдельной сущностью. На практике приходится даже раскрашивать ER-диаграммы и структуры баз данных, выделяя цветами группы таблиц описывающих отдельные сущности. Но масштабность задач требует вводить не только такую одноранговую группировку, предметная область может быть разделена на зоны, что мы задаем как префиксы к именам таблиц или вообще помещаем в разные базы данных.

Потерянная семантика крупных объектов. При декомпозиции нам приходится решать задачу определения оправданной глубины. Какие-то данные имеет смысл разукрупнять, а какие-то можно хранить цельными объектами, такими как длинные текстовые поля, изображения, документы и т.д. Если мы разукрупняем - то часто теряем атрибуты, создавая упрощенные модели, а если храним целиком - то теряем возможность машинной обработки средствами реляционной алгебры, т.е. к таким данным невозможно строить запросы, делать анализ и сложные выборки внутри СУБД, а приходится перекладывать их обработку на активные языки, т.е. вынимать сущности в память приложения и обрабатывать алгоритмически.

Потерянный источник. СУБД не предоставляет возможности записывать источник получения данных в полях таблиц. А ведь данные могут быть взяты из импорта, введены вручную, получены из внешней системы и т.д. Приходится выходить из положения добавляя поле, описывающее источник данных другого поля. Реряционная модель не предусматривает формально указать, что одно поле является атрибутом другого поля. Задача "понимания" этой логики ложится на приложение. Чтобы упростить операции можно применять суффиксы и префиксы в именовании полей, например поле Frequency содержит значение частоты, FrequencySource - указывает на источник данных (пользовательский ввод, автоматическая оцефровка, импорт и т.д.), а FrequencyUser - пользователя, отредактировавшего поле вручную или NULL, если значение было получено не от пользователя.

Потерянное время и история изменения данных. Аналогичным образом, как в описанном выше примере может храниться и время фиксации измеренной величины (например FrequencyTime). Однако, часто может быть необходимо хранить одно или несколько предыдущих значений, если одно то можно добавить поле (FrequencyPrevious), а если нам нужна история, то нужна отдельная таблица, и вот логика уже определяется приложением, т.е. на уровне СУБД невозможно задать что таблица хранит историю параметра. Главное, обеспечить целостность данных при декомпозиции, т.е. удалять историю при удалении сущности, атрибут которой имеет историю и слудить за очисткой устаревших не нужных записей.


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

Потерянные группировки. Теряется так семантика группировых связей, когда несколько связей описывают обно физическое явление, а инструментов для объединения связей в группы нет. Сложности есть в формальном описании сложных свойств, когда свойство распадается на несколько полей, а описать их группировку или определить ее мы не можем. В таких случаях нам нужно использовать метаданные, которые будут интерпретированы в сервере приложений или в клиенте. Метаданные можно хранить в именах полей, в именах таблиц, в именах индексов или комментариях к ним (но не все СУБД поддерживают комментарии или дают возможность программно причитать комментарии).

Итак, все приведенные выше случаи говорят нам о сложностях, которые решаются введением метаданных, но если в активных языках (в частности в объектно-ориантированных) у нас развязаны руки для моделирования метаданных, то в СУБД нам часто их просто некуда поместить и приходится выдумывать нестандартные решения. Хотя на практике, в каждом конкретном случае задачу всегда удается решить, но общего решения пока нет.

2009-10-18

Интеграция на уровне вызовов или мета-данных?

Архитектура ИС на основе Web-сервисов позиционируется как поддерживающая динамическое связывание с помощью мета-языков WSDL, UDDI и SSDL, а так же принципы CRUD/REST, однако, это распространенное мнение обманчиво, о чем писал еще в 2002 году Густаво Алонсо в статье "Мифы про веб-сервисы" (Gustavo Alonso - Myths around Web Services). К сожалению, сейчас все материалы, на английском языке по этому вопросу в интернете ведут на битые ссылки, а кое-какие даже на страницу 404 на сайте Microsoft Research (о причинах остается догадываться... а для того, чтобы привести тут ссылку, мне пришлось достать копию статьи из своего бекапа и разместить у себя на сервере). Не буду повторять тут пять основных критических тезисов Алонсо, но постараюсь рассмотреть саму теоретическую возможность динамического связывания в разных архитектурах, безотносительно конкретных реализаций, проприетарных технологий и торговыхмарок.


Рассмотрим композитную информационную систему, состоящую из нескольких слоев или модулей. Каждый модуль имеет интерфейс, через который к нему обращаются другие, а так же тело, содержащее логику работы модуля (состоящее из кода и данных). Все входящие вызовы к модулю изут через интерфейс, а все исходящие - рассеяны по логике. Таким образом, если меняется логика, то это может происходить "прозрачно" для вышестоящих слоев, которые имею дело все с тем же интерфейсом (или с интерфейсом, поддерживающим обратную совместимость). Но вот если функциональность модуля изменилась существенно, т.е. не только старые функции были модифицированы, но и появились принципиально новые, вышестоящие слои просто не будут "знать" этой логики без соответствующей доработки (не будут знать имен новых функций, набора параметров и семантики или смысловой нагрузки вызовов). Эту задачу и призваны решать WSDL и UDDI, они ее и решают, но на две трети: применяя эти средства описания интерфейсов, мы получаем каталог функций и их параметров, но опять остается "потерянна семантика". Задача связывания веб-сервисов опять остается на человеке, который принимает решение на основе договоренностей между разработчиками модулей, т.е. задача выходит с технологического уровня на организационно-технологический и другого решения пока нет.


CRUD/REST"интерфейсом сверху" пытается решить ту же проблему, ограничивая модуль не только , но и "нижним интерфейсом", более того, оба этих интерфейса становятся идентичными между собой и одинаковыми для всех систем. Ограниченный набор команд не решает проблему связывания, он просто смещает ее с уровня вызовов к уровню мета-данных. Действительно, связывание на уровне вызовов предельно простое, например, в HTTP протоколе набор команд сводится к GET, POST, PUT, PATCH, DELETE, LINK, UNLINK, HEAD, OPTIONS, TRACE, CONNECT. Параметры этих команд так же формализованы и фиксированы. Но принципиальная проблема в том, что логика одного модуля ничего не "знает" о логике другого, кроме того алгоритма, который "зашил" программист. Как же может произойти динамическое связывание, если новая функциональность остается невостребованной, а старую, тем временем, приходится поддерживать. Сформулируем задачу яснее: как две системы, имеющие разные языки, разную логику и разную лексику, т.е. просто - разную информационную модель могут договориться? Ответ очевиден: без установления правил отображения информационных моделей двух систем друг в друга, динамическое связывание просто не имеет смысла. А когда таких информационных систем не две, а больше? А нам интересен именно общий случай автоматизации межсистемной интеграции. Гораздо проще решить проблему введя во все системы одну информационную модель, тогда мы получаем выигрыш в количестве правил отображения: вместо (N2-N)/2 нам нужно будет всего N двухсторонних конвертеров. Но все интегрируемые системы должны иметь разные модели, т.к. решают разные задачи и даже одни и те же объекты и явления описывают с разных сторон, классифицируют и формализуют иначе.


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

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

2009-10-16

Литература 2

Еще хочу порекомендовать:

1. Д. Тапскотт "Электронно-цифровое общество" (Don Tapscott "The digital economy") 1999. На каждой странице этой книги Вы найдете десяток готовых идей для бизнеса.
2. У. Эшби "Введение в кибернетику" (William Ross Ashby Introduction to Cybernetics) 1962. Классическое произведение по самоорганизующимся системам.
3. Ибн ал-Араби. "Геммы мудрости" и другие работы, особенно что касается теории единства бытия, даже если Вам кажется, что это от информационных систем далеко, но в то время и в тех местах любая наука была богословской дисциплиной, поэтому и лексика и абстракции у ал-Араби такие, что предварительно нужно изучить Торру, Книги пророков, Новый завет, Коран.
4. Н. Винер "Кибернетика, или Управление и связь в животном и машине" (Norbert Wiener "Cybernetics: Or Control and Communication in the Animal and the Machine") 1948. Замечательная книга, которую просто обязан прочитать каждый ИТ архитектор, тут даже комментировать нечего, лучше автора не скажешь.

2009-10-15

Конец индустриального века

Ни для кого уже не новость, что нам выпало жить во времена информационной революции, однако мало кто задумывается, что индустриальный век, характеризующийся крупносерийным производством подходит к концу. Глобализация, вызванная, прежде всего, появлением новых средств связи, стиранием границ и сокращением расстояний, привела к чрезмерному увеличению масштабов массового производства. Однако, любая система, подходящая к пику своего развития, одновременно, движется и к переломному моменту, после которого следует или распад или перерождение системы. Быстро растущие количественные показатели производства совсем скоро обратятся в качественный скачек. Для этого требуется только, чтобы экспансия системы упёрлась в пределы ресурсов, спроса или технологий. В пределы технологий пока упереться не удастся, т.к. они сейчас переживают стремительный рост и имеют достаточно большой запас жизнеспособности, однако ресурсы и спрос уже не поспевают за производством. Понять, как же изменится отрасль автоматизации производства и как это повлияет на бизнес - мы попытаемся в данной статье. Прежде всего нужно проанализировать возможности информационных технологий, которые и ведут к отказу от крупносерийного производства, далее же мы рассмотрим тенденции фундаментальных преобразований в производстве и экономике и те средства, с помощью которых можно будет реализовать успешную стратегию в сфере производства и услуг.

Информационная революция произвела на свет Интернет - всеобъемлющую паутину сетевой инфраструктуры, мощные технологии оцифровки данных - глаза, уши и руки глобальной сети, дешёвые средства хранения цифровых данных, и конечно же, сверхбыстрые микропроцессоры - множественные сердца единого организма. На стыке технологий появилась человеко-машинная распределённая информационная система, которой уже не может управлять один центр, а тенденции её развития не поддаются корректировке и регуляции. Интеллектуальная сеть начала плотно покрывать всю поверхность планеты, распространяясь в виде кабельных и беспроводных коммуникаций, персональных и серверных ЭВМ, множества отдельных устройств промышленного и бытового назначения управляемых микропроцессорами и микроконтроллерами размером с булавочную головку.

Что же нам дают все эти новшества? Теперь расстояния, скорость обработки данных и человеческий фактор перестали быть проблемой в системах автоматизации производства. Все процессы становятся процессами реального времени, в том числе и массовое производство товаров и услуг. Появилась возможность, не сокращая темпов производства, учитывать любые персональные требования заказчика, индивидуальные предпочтения и личные особенности, которые, без всякой переналадки, прямо в реальном времени поступают от потребителя и массово материализуются в поток выпущенных по единичному заказу продуктов. Крайняя степень персонализации приводит к тому, что каждый клиент получает в точности то, в чем нуждается. Любой потребитель сможет принять участие в интерактивной "примерке" изделия на свои нужды, скомпоновать продукт и откорректировать все подвижные параметры в заданных системой диапазонах и, как в доиндустриальную эпоху, получить уникальный заказной товар от "мастера", который никогда не повторяется.

В данном случае мы можем говорить о промышленном товаре, об услуге или информационном продукте - от этого не меняются ни технологии ни принципы изготовления и продажи в новой сетевой инфраструктуре. Цена тоже формируется персонально, тарифный план разрабатывается системой для каждого потребителя в отдельности, а после получения товара, потребитель становится не просто постоянным клиентом или регулярным потребителем услуги, а полноценным партнером производителя, от которого в реальном времени поступает обратная связь о качестве и эксплуатационных показателях продукта. Устанавливаются долгосрочные информационно-финансовые партнёрские отношения, выгодные обоим сторонам. Грань между потребителем и поставщиком постепенно стирается, т.к. клиент сам становится поставщиком информации и генератором новых идей для производителя.

В таких условиях информационные системы поддержки производства становятся центральным составляющим успешного предприятия. На первый план выходят интеллектуальные программно-аппаратные комплексы, заменяющие собой долгий путь инженерной и технологической подготовки. Резко сокращается время от заказа до выпуска изделия, а человеческий труд применяется только в качестве источника творческих идей, ведь такая роль машине никогда не будет доступна. Вся рутинная работа по стыковке требований, выбору инструментария, технической реализации, даже по выбору самого дешёвого и эффективного места производства происходит незримо для клиента. Система назначает задания различным, доступным ей, производственным мощностям, расположенным в удалённых друг от друга местах, координирует создание отдельных узлов продукта, транспортировку, сборку, настройку и доставку. Каждый субъект производства при этом получает надлежащую ему компенсацию потраченных ресурсов. Производство становится онлайновым, а его структура динамической. Партнёрские связи между субъектами устанавливаются автоматически исходя из принципов наибольшей взаимной выгодности, а так же наименьшей стоимости транспортировки между промежуточными местами технологической обработки в процессе производства.

Каковы же должны быть эти мета-технологии, позволяющие сделать описанную схему реальностью? Вот ключевые особенности:
1. Использование онлайновых "мастеров" для персональной компоновки заказа
2. Автоматизированное планирование технологических процессов и поставки сырья
3. Динамическое связывание производственных мощностей с минимизацией затрат
4. Исчезновение торговых площадок и переход к доставке готового товара непосредственно в место потребления
5. Отслеживание перемещения сырья, товаров, контейнеров, средств производства и транспорта с помощью систем GPS и чипов радиочастотной идентификации RFID
6. Контроль качества и сервисное сопровождение товаров на протяжении всего цикла: (заказ, производство, поставка, использование, обслуживание и утилизация) что достигается благодаря идентификации товаров, производителей и клиентов
7. Обеспечение обратной связи от потребителей товаров и услуг, которая влияет на алгоритмы принятия решений при повторном цикле производства уже модифицированных версий товара. Ведь кто является экспертом в удобстве и улучшении эксплуатационных характеристик товаров? Конечно же - это потребитель, а значит он наиболее ценный специалист для компаний производителей.

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

REST и CRUD против RPC

Развитие сетевых коммуникаций началось со специализированных протоколов, заточенных под прикладные нужды и повторяющих функциональность друг друга во многих случаях. Концепция эта называется RPC (Remote Procedure Call) или вызов удаленных процедур. Характеризуется RPC тем, что функциональность приложения полностью отображена в наборе команд протокола, например: FTP, POP, NNTP, протоколы СУБД, не говоря уже про многочисленные протоколы систем промышленной автоматизации или прикладных систем. Более поздние RPC стали абстрактными, т.е. появился некий стандарт, описывающий протокол, а уже на его основе разрабатывались прикладные службы, обладающие конкретным набором команд, например: SunRPC, DCOM, CORBA, Java RMI, и т.д.

Следующий шаг заключался в ограничении набора команд до "универсального минимума" и перенесении всей смысловой нагрузки в параметры вызовов. Подход этот получил название CRUD по первым буквам команд (create, read, update and delete), а архитектура информационных систем, построенная на базе подхода - REST (Representational State Transfer). Клеинт-серверные приложения в CRUD/REST архитектуре работают ресурсом и вызовом, как основными абстракциями. Ресурс (чаще всего файл) - это ответ сервера, содержащий данные и текущее состояние. Состояние - это набор параметров ресурса, которые изменяются во времени. Запрос приводит к передаче ресурса на клиентскую сторону, где пользователь с ним работает и при следующем запросе отправляет ресурс обратно на сервер вместе с состоянием.

Таким образом, архитектура REST полностью отвергает возможность установления сессии, а следовательно не дает возможности хранения состояния на стороне сервера. В отличие от REST, сервера RPC ставят в соответствие определенную область памяти сервера с каждым подключенного пользователем, создают идентификатор сессии и устанавливают соединение: виртуальное (по идентификатору) или постоянное (не закрывая сокет между вызовами).

Преимуществом CRUD/REST архитектуры является простое масштабирование на кластеры, возможность применения облачных вычислений, простота применения для информационных, гипертекстовых и других типичных задач. Из недостатков можно привести: невозможность создания систем реального времени, избыточность трафика, отсутствие машины состояний, как необходимого средства при разработке сложных систем. Преимуществом же RPC архитектуры является отсутствие ограничений на набор команд, установление соединений и хранение состояния на сервере, в следствии чего, RPC до сих пор являются единственным средством разработки прикладных, промышленных и других сложных систем. А очевидным недостатком RPC является сложность разработки, отладки и внедрения, что естественно при большей гибкости.

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

2009-10-14

Иерархия и эгалитарность

В архитектуре систем вопрос о двух подходах, иерархическом и сетевом (с равноправными узлами), встает давно и в самых разных аспектах:
1. В задаче классификации (taxonomy) - Классификация с единым корневым элементом против классификации на основе равноправного списка.
2. В задаче моделирования данных (data modeling) - Иерархическая вложенность, подчиненность или порождение объектов против сетевой модели данных с произвольными связями.
3. В задаче взаимодействия подсистем (distributed systems) - Архитектура клиент-сервер, многоранговая иерархия против одноранговых (пиринговых или peer-to-peer) сетей.
4. В задаче управления (control theory) - Централизованное управление (с единым целеполаганем или же с единым центром управления высокого уровня и каскадной иерархией разукрупнения задач управления) против независимых систем управления отдельными технологическими процессами без единого центра.
5. В задаче организационного менеджмента (project management) - Принцип единоначалия и иерархии против соревновательного принципа и равноправной конкуренции.

Я в скобках указал англоязычные ключевые слова, чтобы вызвать адекватные ассоциации у большинства. Ибо, например, различие "менеджмента" и "управления" не сразу для всех очевидно. И конечно же, нет однозначного ответа на поставленные вопросы ни в одном из аспектов. Для принятия решения всегда нужно рассмотреть конкретный случай или группу однотипных случаев. А решение, как в диалектической триаде "тезис-антитезис-синтез", должно быть посередине.

Принцип иерархии распространен в природе везде, где речь идет о внутренней организации "гомеостата" (автономной самоорганизующейся системы, которая поддерживает свою внутреннюю структуру, функции и параметры в заданных диапазонах в течении жизни системы). Примеры приводит нам К. Леонтьев, отмечая, что в мире все системы построены иерархически, и в организме человека, растений, животных и социальные институты и планеты, звездные системы и т.д. Однако в середине IXX века он не был знаком с работами У. Эшби и Н. Вишера по кибернетике, вводящими понятие гомеостата. С другой стороны, принцип конкуренции между равноправными системами в природе так же имеет место: конкуренция за зону обитания, за ресурсы, за преобладание определенных религиозных, социальных или политических идеологий, экономическая конкуренция. Общая картина представляется мне такой, что одноранговая конкуренция не противоречит иерархии, а является для нее дуальной парой. Т.е. организация объектов или явлений в иерархию приводит к появлению конкуренции, а появление конкуренции - к организации иерархии. Оба этих дуальных понятия способствуют развитию структуры, в противовес хаосу или энтропии.

Таким образом, и модель мира, которую мы строим с помощью вычислительной техники, должна отображать оба типа структур, как иерархическую, так и сетевую (с равноправными связями). Другое дело, что мы вынуждены использовать декомпозицию для отображения обоих этих структур в реляционных СУБД, т.к. реляционная модель находится на один уровень абстракции выше, чем модели сетевые и иерархические (такие СУБД тоже существуют). Однако, декомпозиция приводит всегда к потере части семантики модели. Даже используемая нами для проектирования баз данных методология ER (сущность-связь) напрямую связана с реляционным подходом и не позволяет без декомпозиции описать системы. Т.е. на уровне ER-диаграммы все сущности равноправны, хотя часть сущностей составляют "внутренность" описываемой системы, другая часть - "внутренность" параллельно существующей системы, а третья часть описывает надсистемные атрибуты или же параметры системы более крупной, включающей в себя множество других. Поэтому нам часто приходится делать префиксы к таблицам, разукрашивать ER-диаграммы разными цветами, чтобы сгруппировать таблицы, классифицировать связи. Этому способствует и введение мета-данных, которые описывают недостающие атрибуты и "потерянную семантику". Например: сила связи, тип связи, группа связей, направление связи, и все, что связано с применением нечеткой логики. Все это не ложится в реляционную модель и требует от архитектора системы специальных уловок. Но об этом будет дальше.

2009-10-13

Язык Моделирования

Моделирование подразумевает наличие формального языка для описания модели. Таким языком может выступать как графическое представление модели в виде блок-схемы или графа, так и аудио/видео сигнал цифровой или аналоговый, регулярная грамматика или же бинарный файл. Ни один язык не может быть ни полным, ни универсальным, ни самым лучшим. Язык может быть только адекватным или не адекватным для решения конкретной задачи или достижения поставленной цели. Цель языка - хранить модель или передать ее от одного модуля системы управления к другому. Конечно же, каждый модуль или слой не может "понимать" модель целиком. Более того, вычислительная техника далека от понимания семантики модели и работает на уровне той абстракции, какую может обрабатывать алгоритм программного обеспечения (представленный на активном языке). Это не значит, что цифровая обработка не в состоянии создать модель объекта, совсем наоборот, задачи автоматизации зачастую сводятся к формализации вводимых и выводимых данных, к преобразованию между представлениями на разных языках, искусственных и природных, к обработке и анализу, оцифровке, конвертации, парсингу и другим операциям, приводящим к формированию модели объектов на используемых в системе языках. Что же остается пока прерогативой человека, так это - построение языков и построение абстракций. Мое убеждение, что это не будет доступно компьютерам никогда.

2009-10-05

Модель и мета-модель

Разберемся теперь с понятиями "модель" и "мета-модель".

Перефразирую всем известное определение чтобы оно было в согласии с нашей тематикой. Модель - это отображение прототипа, адекватное для решаемой задачи. Как прототип, так и его модель может быть объектом или явлением (другими словами: сущностью или процессом). В свою очередь, объект или явление может быть физическим или информационным. Нас, конечно же, интересуют информационные модели. Адекватность, как требование к модели, прямо приводит к тому, что любая модель всегда субъективна.

Мета-модель - это модель модели, задающая правила, ограничения, закономерности и элементы для построения моделей. Таким образом, для построения любой информационной модели, необходимо построить цепочку мета-моделей от прототипа до базового алфавита (символьного письма, аналоговой, цифровой или бинарная записи). Например: для моделирования склада, необходимо отобразить в реляционную модель: сущности (такие как помещения, стелажи, контейнеры, персонал и т.д.), атрибуты сущностей (объем, количество, грузоподъемность) и связи (размещение товаров в контейнерах, расписание работы). Но это не все, реляционная модель имеет свою мета-модель - это язык, на котором описана структура базы данных (например SQL). Для языка, мета-моделью является его синтаксис, описанный в форме Бакуса-Наура и раскладывающий все нетерминальные конструкции через набор правил до терминалов (базового алфавита).
 
Таким образом, любая информационная система строится с применением мета-моделей и ничего необычного тут нет. Другое дело, что мета-модель часто остается скрытой, т.е. человек, работающий в системе имеет дело с моделью, но повлиять на ее структуру или функции уже не в состоянии без инженера, построившего систему.  Но нас интересует как раз мета-данные или мета-информация, добавляющие гибкость в этот слоеный пирог, позволяя проводить изменения на несколько уровней в глубину без перепроектирования.

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

В заключении кратко приведу стратегический архитектурный подход, который считаю оправданным в смете вышеизложенного:
1. Широкое применение интерпретируемых мета-данных (скриптовых языков и формальных грамматик) в моделировании предметной области.
2. Отделение абстрактных алгоритмов от бизнес-логики. Например, модуль для работы с изображениями в формате PNG должен быть написан на компилируемом коде, а вот модуль для статистической обработки сигналов, приходящих от датчика температуры - это типичный интерпретируемый алгоритм, который лучше всего сделать частью информационной модели и погрузить в базу данных.
3. Отказ от полной формализации данных на каждом слое абстракции в информационной системе. Ведь данные могут транзитно проходить сквозь слой, чтобы быть интерпретированы на другом слое. Нужно заметить, что максимальное понимание и интерпретация данных может быть достигнута только человеком, который работает с информационной системой.

2009-10-04

Литература

Для начала дискуссии хочу привести несколько ссылок, которые раскрывают различные аспекты моделирования данных. Это и антологические источники и учебники, а так же научные труды, отличаются полнотой и объективностью:

1. Д. Цикритзис и Ф. Лоховски "Модели данных" 1982 (русскоязычное издание "Финансы и статистика" 1985). Это замечательный обзор, включающий реляционные, сетевые, фреймовые, иерархические, бинарные, семантические, инфологические модели данных в аспекте моделирования с помощью вычислительной техники.
2. Умберто Эко "Поиски совершенного языка" 2007 (оригинальное издание "La ricerca della lingua Perfetta" 1993). Эссе об истории лингвистических моделей данных, начиная от каббалистов и искателей первоязыка, создателей комбинаторных моделей и алфавитов, полиграфий и философских языков, попыток всеобщей классификации и кодификации знаний, до гипертекста и современных течений.
3. К. Дж. Дейт "Введение в системы баз данных" 2006 ("Introduction to Database Systems" 2003) Знаменитый учебник по базам данных, на котором основываются курсы во многих университетах мира.
4. Э. Кодд "A Relational Model of Data for Large Shared Data Banks" 1970 (на русском языке "Реляционная модель данных для больших совместно используемых банков данных" 1995). Статья, в которой Кодд впервые развернуто объясняет принципы реляционного подхода.
5. Г.Буч "Объектно-ориентированный анализ и проектирование" (оригинальное издание Booch, Grady  "Object-Oriented Analysis and Design with Applications" 1997). Классическая книга по объектно-ориентированному анализу и моделированию, предназначенная больше для программистов и раскрывающая на примерах принципы моделирования данных в памяти ПК, а так же процесс анализа предметной области в ходе построения моделей.

Если Вы специалист в моделировании данных, то наверняка знакомы с этими источниками, исключая, разве что книгу Эко, которую я Вам настоятельно рекомендую, а для начинающих "архитекторов данных" каждая из этих книг должна стать находкой!