Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Правильно называть такую таблицу „Машина“
У Криса есть другая версия, которая мне более симпатична. Таблица — есть описание типа объектов. По сути таблица содержит перечень параметров. Но это по-определению и есть тип Аристотеля!
Таблицу надо таки называть «Машины». Потому что таблица — это вообще другой уровень, это реализация, а не концептуальная модель. А вот перечень заголовков её столбцов — это описание класса «Машина».
Раз так, то лучше называть таблицу в единственном числе из-за возможных неоднозначностей в форме множественного числа -es -s. Подразумевая что в ней лежат машины.
Если так, то что имеется ввиду под термином машины? любая машина класса, или класс машин?
«Машины» я предложил именно для заголовка таблицы БД, то есть это обозначение понятия из реализации, это индивид совершенно другой онтологии. В онтологии реального мира класс «Машина», индивид «машина VIN 6786786786767677878».
На самом деле формально-логически таблица должна называться «Некоторые машины», или «Машины, учтённые в АСУ ГАИ г. Москвы», и представлять подкласс класса «Машина».
На самом деле формально-логически таблица должна называться «Некоторые машины», или «Машины, учтённые в АСУ ГАИ г. Москвы», и представлять подкласс класса «Машина».
Да, таблица «Машина» реализует именно перечень параметров (т.е. реализует аристолевский тип), но с помощью этой таблицы чаще всего моделируются и «Список машин», и «Машины».
Возможное взаимное непонимание как раз из-за путаницы терминов и может происходить.
Возможное взаимное непонимание как раз из-за путаницы терминов и может происходить.
Сама таблица, а точнее ее структура — это описание типа объектов, или типа типов, типа связей, или типа типов связей. Иерархию типов можно продолжать до бесконечности. С помощью таблицы моделируются объекты, типы и так далее данного типа. Связи также имеют смысл и ровно тот же)) От этого иногда возникает головокружение, но это, блин, реальность)) А связи, которые реализуются ключами тоже)).
Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
класс/таблицу вида «Список машин»;
класс/таблицу вида «Машина».
Эээ, а зачем это все реализовывать? Я что-то не сталкивался с задачами, которые бы одновременно требовали реализации сразу всех трех сущностей (и более того, которые бы их выделяли).
Очень просто указать на такой класс задач. Вам может понадобиться одновременно хранить в системе ограничение «машина имеет ровно 4 колеса», а также в таблице для каждой конкретной машины хранить серийные номера всех колёс. И, разумеется, хранить информацию о том, что машина и колёса в ограничении — это те же самые машина и колёса, что в таблице конкретных машин.
Ограничение «машина имеет ровно четыре колеса» закладывается либо на уровне «у сущности машина есть четыре различных связи с сущностью колесо» либо на уровне «связь машина-колесо имеет множественность 0..1-4». Соответственно, таким образом и реализуется в коде и хранилище.
Разумеется, моё утверждение на русском языке можно и в UML нарисовать. Это не называется «закладывается».
Реализацию в коде через жёсткую прошивку ограничения мы сразу не рассматриваем, это не про эту задачу, надеюсь, это понятно.
А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
Реализацию в коде через жёсткую прошивку ограничения мы сразу не рассматриваем, это не про эту задачу, надеюсь, это понятно.
А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
Кто ж так делает-то? Есть две сущности, между ними есть связи.
Какие именно связи вы можете использовать для связывания объектов в БД с именами колонок и таблиц в этой же БД?
Эээ, а зачем?
Я написал: Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка.
Вы ответили: Есть две сущности, между ними есть связи.
Какие именно сущности вы имели в виду?
Вы ответили: Есть две сущности, между ними есть связи.
Какие именно сущности вы имели в виду?
Вот когда придумывается структура хранения, тогда нелепые противоречия «машина — это таблица, колесо — это колонка» и снимаются.
И машина, и колесо — это сущности. В терминах реляционной БД — таблицы. Отношение «это колесо прибито к [полу]оси в этой машине» выражается связью между сущностями. В терминах реляционной БД — это либо дополнительный атрибут, либо таблица связей.
И машина, и колесо — это сущности. В терминах реляционной БД — таблицы. Отношение «это колесо прибито к [полу]оси в этой машине» выражается связью между сущностями. В терминах реляционной БД — это либо дополнительный атрибут, либо таблица связей.
«И машина, и колесо — это сущности. В терминах реляционной БД — таблицы.»
И как после этого записывается факт
«у сущности машина есть четыре различных связи с сущностью колесо»
Отношение «это колесо прибито к [полу]оси в этой машине»
Нам надо записать факт про машину вообще и про колесо вообще, не про «это» колесо. В той же БД. Отразив, что это те же самые машины и колёса, что таблицы для записи «этих» машин и колёс.
Нам надо записать факт про машину вообще и про колесо вообще, не про «это» колесо. В той же БД.
Внешние ключи несут именно эту информацию.
Этого утверждения я уже не понимаю. Возможно, мои познания в клссических СУБД слишком ограничены :-(
Если возможно, нарисуйте пример.
Если возможно, нарисуйте пример.
Вот смотрите, если взять современную реляционную СУБД, то:
В них есть данные (для конкретной машины — VIN 1237890 и черный цвет, для конкретного колеса — вес 15 кг и серийный номер АБ879, для связей — колесо с номером АБ879 прибито к машине с VIN 1237890).
А еще в них есть метаданные: у машин есть VIN и цвет, у колес есть вес и серийный номер, между машинами и колесами есть связь «колесо прибито к машине». Это, собственно, структура БД и данные о ней.
В них есть данные (для конкретной машины — VIN 1237890 и черный цвет, для конкретного колеса — вес 15 кг и серийный номер АБ879, для связей — колесо с номером АБ879 прибито к машине с VIN 1237890).
А еще в них есть метаданные: у машин есть VIN и цвет, у колес есть вес и серийный номер, между машинами и колесами есть связь «колесо прибито к машине». Это, собственно, структура БД и данные о ней.
Смотрите. Я знаю, что на этапе дизайна СУБД есть инструменты для работы с такими ограничениями, и для генерации проверок. Мой сценарий — про другое. Мне нужны хранимые правила, которые могут вноситься и меняться в процессе работы с готовой базой, а не её авторами.
О, вы хотите настраиваемую систему. Окей, просто поднимаемся на уровень выше, и в БД храним абстрактные «сущности», «атрибуты» и «связи», а также метаданные обо всем это, все остальное делаем в рантайме. Все минусы конфигурируемых в рантайме систем — с вами.
Но концептуально это ничем не отличается, мы просто двигаем момент модифицируемости той или иной информации (и всего, что от нее зависит) в разные стороны.
Но концептуально это ничем не отличается, мы просто двигаем момент модифицируемости той или иной информации (и всего, что от нее зависит) в разные стороны.
Вот об этом и речь в моём кейсе в ответ на ваш исходный вопрос " а зачем это все реализовывать?".
В этом сценарии и необходимы выделение, реализация и вынесение в интерфейс всех сущностей, обычно разносимых на разные уровни «мета».
А у кого такой задачи нет — тот, разумеется, и не реализует все уровни, а использует классические интрументы настройки СУБД, работающие на уровне модели данных.
В этом сценарии и необходимы выделение, реализация и вынесение в интерфейс всех сущностей, обычно разносимых на разные уровни «мета».
А у кого такой задачи нет — тот, разумеется, и не реализует все уровни, а использует классические интрументы настройки СУБД, работающие на уровне модели данных.
Заметим, что нет. Для вашего сценария из трех перечисленных вещей необходимо реализовать одну — описание (метаданные) сущности. Сами сущности из него в любом случае получаются автоматом, а списки вообще в вашей задаче не участвуют.
Т.е. в таких сценариях все равно есть разделение на две составляющих — интерфейс работы с метаданными (аналогично дизайнеру БД) и интерфейс работы с данными (аналогично формам ввода информации с БД), и каждая из них существует ровно в своем пласте.
Т.е. в таких сценариях все равно есть разделение на две составляющих — интерфейс работы с метаданными (аналогично дизайнеру БД) и интерфейс работы с данными (аналогично формам ввода информации с БД), и каждая из них существует ровно в своем пласте.
В сфере САПР, где я с этим сталкивался, базовые типы оборудования могут быть зашиты и недоступны пользователю, их подтипы — пополняемы, включая новые атрибуты, а новые правила доступны для создания пользователю и могут ссылаться и на зашитые типы, и на их кастомизированные подтипы. То есть в продукте таки есть минимум три уровня, не считая индивидуальные объекты.
Про «в своём пласте» я вообще не понимаю. Разумеется управление разными слоями разнесено между экранами и ролями, но хранилище под этим одно, и в его модели надо решить все эти проблемы.
Про «в своём пласте» я вообще не понимаю. Разумеется управление разными слоями разнесено между экранами и ролями, но хранилище под этим одно, и в его модели надо решить все эти проблемы.
Чем вас не устраивает такой вариант:
Таблица Машин:
{VIN (ID машины, ключ),
модель,
число осей,… и т.д.}
Таблица колес:
{Номер (ID колеса, ключ),
Диаметр,
Ширина,… и т.д.}
Таблица связей «Колеса машин»:
{VIN (ID машины, внешний ключ),
Номер (ID колеса, внешний ключ),
Вариант установки}
Таблица (или перечисление) «Варианты установки»:
{Первая ось — левое,
Первая ось — правое,
Вторая ось — левое,
Вторая ось — правое, и т.д.}
?
Таблица Машин:
{VIN (ID машины, ключ),
модель,
число осей,… и т.д.}
Таблица колес:
{Номер (ID колеса, ключ),
Диаметр,
Ширина,… и т.д.}
Таблица связей «Колеса машин»:
{VIN (ID машины, внешний ключ),
Номер (ID колеса, внешний ключ),
Вариант установки}
Таблица (или перечисление) «Варианты установки»:
{Первая ось — левое,
Первая ось — правое,
Вторая ось — левое,
Вторая ось — правое, и т.д.}
?
А если появится трехосный грузовик с удвоенными колесными парами? Переписывать все?
А почему-бы не перейти к парадигме онтологий — «ключ — тип связи — значение»? OWL, RDF?
Связи, которые есть у всех машин — базовый класс. Добавление специфичных связей к специфичной машине — наследование. Более того — список машин и одна машина в обработке никак не отличаются. Запросы простые — похожи на SQL (SPARQL). Есть и стандарт на эту тему ISO15925
Связи, которые есть у всех машин — базовый класс. Добавление специфичных связей к специфичной машине — наследование. Более того — список машин и одна машина в обработке никак не отличаются. Запросы простые — похожи на SQL (SPARQL). Есть и стандарт на эту тему ISO15925
Как вариант, да. Однако, пост о том, что хотелось бы реализаций этих продвинутых онтологий в мейнстриме уровня C#/Java/SQL Server — речь не о конкретных языках/СУБД, а об уровне мейнстрима.
Да, именно это решение для такого класса задач и применяется. Правда, пока в извращённой форме. Отдельно дизайнится реляционная или объектная система хранения ограничений. Отдельно — система хранения данных о конкретных машинах. А в RDF хранится общая концептуальная модель предметной области и мэппинг, который отдельный engine может использовать для извлечения правил из первой БД и верификации данных во второй.
Как важное понятие «поведение» ложится на язык теории множеств? Теория множеств вообще оперирует понятиями принадлежности, булевых операций, мощности, функций. Даже беглый взгляд на коддовскую алгебру показывает, что это нечто более богатое, чем стандартная теория множеств. Тем более ООП.
Думаю, этот вопрос лучше задать в исходной статье: habrahabr.ru/post/249165/
Здесь же я предложил обсудить вопросы моделирования, связанные с описанием сущностей и их признаков.
Но давайте попробует поговорить и о поведении:
Вы знаете, что поведение, которое в ООП наследуется, а также может перекрываться (полиморфизм), часто подвергается критике?
И есть такой подход, когда поведение не наследуется, наследования вообще как бы нет,
но каждый объект может реализовывать множество разных интерфейсов.
Такой подход реализован в т.ч. и в таком потенциальном кандидате на будущий мейнстрим, как Golang?
В этом случае у нас при моделировании предметной области снимаются сложные вопросы, связанные с реализацией поведение в части наследования и полиморфизма.
В общем, какое нужно, такое и добавляем поведение через интерфейсы.
Здесь же я предложил обсудить вопросы моделирования, связанные с описанием сущностей и их признаков.
Но давайте попробует поговорить и о поведении:
Вы знаете, что поведение, которое в ООП наследуется, а также может перекрываться (полиморфизм), часто подвергается критике?
И есть такой подход, когда поведение не наследуется, наследования вообще как бы нет,
но каждый объект может реализовывать множество разных интерфейсов.
Такой подход реализован в т.ч. и в таком потенциальном кандидате на будущий мейнстрим, как Golang?
В этом случае у нас при моделировании предметной области снимаются сложные вопросы, связанные с реализацией поведение в части наследования и полиморфизма.
В общем, какое нужно, такое и добавляем поведение через интерфейсы.
Это не ответ. Вопрос ведь не в том, чем плохи или хороши механизмы ООП, а в том, каким образом специфицировать поведение на языке теории множеств?
Вы пишете: «Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в «нативных» для себя терминах реализовывать модель предметной области в терминах именно теории множеств.»
Существует метод, основанный напрямую на аксиоматике Цермело-Френкеля дял теории множеств, это Z-нотация. К сожалению, я не специалист по этой теме, но беглый взгляд на мануал spivey.oriel.ox.ac.uk/mike/zrm/zrm.pdf не позволяет сказать, что этот метод заточен под динамические аспекты систем. Возможно, я ошибаюсь.
Вы пишете: «Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в «нативных» для себя терминах реализовывать модель предметной области в терминах именно теории множеств.»
Существует метод, основанный напрямую на аксиоматике Цермело-Френкеля дял теории множеств, это Z-нотация. К сожалению, я не специалист по этой теме, но беглый взгляд на мануал spivey.oriel.ox.ac.uk/mike/zrm/zrm.pdf не позволяет сказать, что этот метод заточен под динамические аспекты систем. Возможно, я ошибаюсь.
Если вас не удовлетворяет мой ответ, то это связано с тем, что я являюсь специалистом по ООП и реляционным БД (а также моделированию предметной области в той части, где это можно сделать путем средствами ООП и реляционной модели), но не являюсь специалистом по теории множеств.
Поэтому ответы на вопросы, которые вы задаете, мне тоже были бы интересны.
Повторюсь, идея публикации в том, что работа с ООП и реляционными БД выявила их недостатки, связанные с моделированием предметной области или реализацией в коде/схеме БД уже имеющихся моделей, полученных от бизнес-аналитиков.
И поэтому вопрос
Ответ на ваш вопрос дадут, видимо, специалисты по теории множеств, а мне как разработчику по-прежнему хотелось иметь такие средства и платформы разработки, которые нативным образом позволяли бы реализовывать «метод, основанный напрямую на аксиоматике Цермело-Френкеля» или любой другой, который вас устроит в части реализации поведения в теории множеств.
Поэтому ответы на вопросы, которые вы задаете, мне тоже были бы интересны.
Повторюсь, идея публикации в том, что работа с ООП и реляционными БД выявила их недостатки, связанные с моделированием предметной области или реализацией в коде/схеме БД уже имеющихся моделей, полученных от бизнес-аналитиков.
И поэтому вопрос
чем плохи или хороши механизмы ООПимеет место быть.
Ответ на ваш вопрос дадут, видимо, специалисты по теории множеств, а мне как разработчику по-прежнему хотелось иметь такие средства и платформы разработки, которые нативным образом позволяли бы реализовывать «метод, основанный напрямую на аксиоматике Цермело-Френкеля» или любой другой, который вас устроит в части реализации поведения в теории множеств.
Осталось найти этих специалистов и подключить к дискуссии :) Лично я, будучи знаком с теорией множеств как математик, не нахожу ее саму по себе достаточной, для того чтобы заменить существующие практики, выросшие из или рядом с ООП. Но с другой стороны, я всегда смотрел на теорию множеств как на внутренний инструмент самой математики…
Насколько я понимаю, никаким. ISO 15926 направлен на стандарты описания и передачи данных, а не описание их обработки. Я сильно подозреваю, что эта парадигма неплохо ложится на функциональное программирование, когда данные (в частности, описанные в терминах принадлежности ко множествам) прогоняются через не имеющие собственного состояния обработчики.
поведение в логической парадигме описывается при помощи 4-Д объектов. В лекции очень хорошо про это рассказано.
дубль.
что-то вроде orientdb.com?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На тему моделирования предметной области в терминах ООП