Умение анализировать и разрабатывать онтологии предметной области – комплекс довольно сложных навыков. Если ему учить как следует, то нужен как минимум семестр теории и практики. Запишу некоторые базовые идеи:
-
Любая теоретическая и практическая деятельность всегда оперирует понятиями какой-то онтологии. Эта онтология может быть неотрефлексирована, интуитивна, не описана, но она есть. «Онтология» у меня здесь = онтика = система понятий. Я знаю, что сам термин означает «описанную систему понятий» - логия. Но, в конце концов, хотя бы в форме нейронных связей в головах каждого человека складываются некоторые онтологии.
-
Разные люди как правило используют разные онтологии для одной предметной области. Разные онтологии (разная структура системы понятий и разная терминология) – одна из причин почему люди часто друг друга плохо понимают. Чтобы понимать друг друга быстрее для некоторых задач нужно договариваться об общей онтологии.
-
Онтология не может быть правильной или не правильной. Однако онтология может быть более эффективной или менее эффективной для решения некоторых практических задач.
-
Проектировщики баз данных и информационных систем (некоторые) «прокачали» свои онтологические навыки в связи с необходимостью моделирования данных. Раньше онтологическими вопросами занимались только философы, ученые и некоторые хорошо образованные люди.
-
Айтишники сосредоточены на разработке «предметных» онтологий в рамках задач автоматизации. Системы понятий многих видов человеческой деятельности, «гуманитарных», но не только, чрезвычайно сложны, ими айтишники не занимаются.
-
Разработка онтологии – это не разработка структуры БД. Одна и та же онтология предметной области может быть спроектирована чрезвычайно разным образом для одной и той же СУБД.
-
Значительная часть знакомых мне проектировщиков ИС разрабатывают структуры БД, не описывая онтологии, лежащие в их основы, полагая, что «хорошая» структура таблиц – это и есть правильное описание онтологии предметной области. Это ошибка. Наличие «концептуальной модели» –хотя бы частичного описания онтологии сильно упрощает взаимопонимание, а еще сильнее – проекты по развитию, интеграции, миграции данных ИС.
-
Онтология всегда многоуровневая. В задачах автоматизации уровни выглядят, например, так:
a. Первый уровень – реальные физические объекты (например, конкретная ложка с уникальным инвентарным номером. Или, например, конкретная задача по проекту, выполняемая конкретным человеком).
b. Второй уровень – типы объектов (например, для ложки: чайная ложка определенного дизайна; для задачи: задача по разработке API по протоколу SOAP).
c. Третий уровень – типы типов объектов (например, товары на реализацию, запчасти, задачи разработчика).
d. Четвертый уровень – типы типов типов объектов, например, базовые понятия методологии, по которой ведется разработка. Например, стандарт BABOK Guide задает некоторую базовую онтологию для задач по бизнес-анализу, PMBOK задает некоторую базовую онтологию для задач по управлению проектами и т.д. Между этим и предыдущим уровнем может быть еще некоторое количество уровней.
e. Пятый уровень - онтология методологии описания онтологий (например, например 3D- или 4D-протяженность, или, например, базовые типы объектов, приводимые в книгах Партриджа, Веста и проч. – о них дальше). Между этим и предыдущим уровнем также могут «затесаться» другие уровни.
-
Онтологии не всегда иерархия/дерево, может быть и сложный граф. Но об этом долго рассказывать.
-
Базовые понятия Партриджа (5 уровень): объект, отношение, состояние, событие, класс.
-
Базовые понятия Веста (7-5 уровни, сильно упрощенно):
a. Вещь (thing) – речь об абстрактной сущности – всё в этом мире «вещь», «нечто».
b. Пространственно-временные объекты, абстрактные объекты.
c. Абстрактные объекты: классы, отношения. Физические объекты: состояния, события, агрегации, индивиды.
i. Намеренно сконструированные объекты (физические): функциональные объекты, социально сконструированные объекты, собственность, соглашения, контракты, организации, продукты, репрезентации.
ii. Физические объекты: системы.
iii. Физические объекты: спецификации требований.
- Проектирование БД – это перенос части онтологической модели в структуру БД. Наличие концептуальной модели уменьшает вероятность плохого проектирования БД, но не исключает этого. Физическое проектирование на основе концептуального – задача не всегда простая. Объект онтологии не равно таблица. Отношение между объектами не равно отношение между таблицами (например, отношение между объектами в БД может быть спроектировано как несколько таблиц; например, некоторые типы объектов могут быть объединены одной таблицей и т.д.).
Мораль: онтологическое мышление не самая простая дисциплина для освоения, но она на порядок повышает «умность» проектировщика и повышает вероятность создания качественных ИС.
Ссылки:
-
Мэтью Вест. Разработка высококачественных моделей данных (русский перевод) - MATTHEW WEST - Google Documenten
-
Chris Partridge. Business Objects: Re-Engineering for Re-Use - https://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20(3rd%20Ed%20-%20early%20draft%20-%2020140927).pdf
партридж #уэст #бизнесанализ системнаяинженерия онтология