ER-модель (от англ. Entity-Relationship model, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области.
Составим простую схему сущности связи.
1. Без отношения множества. Один к одному. Один ко многим. Многие ко многим.
2. Без направления связей. Указаны стрелочками.
3. Без указания количества ссылок на одну и ту же сущность. Обычно число справа вверху над сущностью.
Сокращаем схему до сущностей
Далее вопрос, а так ли нужны.
1. Отношения.
2. Атрибуты.
В конечном счёте.
1. На понимание этих нюансов и как следствие перерисовку тратится время.
2. Не факт, что удастся определить, что это не сущность, а именно отношение или атрибут.
3. Нарушается правило монотонности дизайна, что в теории дизайна как раз затрудняет восприятие схем.
Решение переделать всё в сущности.
Монотонный дизайн
По факту конечная диаграмма в которой есть некая сущность играющая роль сущностей, отношений, атрибутов, и любых других элементов должна выглядеть так.
Раскраска сущностей
И под конец можно раскрасить схему цветами для удобства восприятия, хотя делать это не обязательно.
Для чего нужны подобные схемы
Различие в языках.
1. В русском языке часто упоминаются слово схемы.
2. В иностранном встречается упоминание диаграмм.
Подобные схемы нужны для того же, для чего и метод боксов. Хотя на десктопе в силу разрешения и размера дисплея их можно рассматривать как более продвинутый аналог метода боксов, позволяющий охватить тысячи понятий. Впрочем на смартфоне можно делать тоже самое, разрешение там уже давно 2K. Вопрос лишь в хорошем программном обеспечении, которое для них до сих пор не существует.
Здравствуйте, velkin, Вы писали:
V>Составим простую схему сущности связи. V>1. Без отношения множества. Один к одному. Один ко многим. Многие ко многим. V>2. Без направления связей. Указаны стрелочками. V>3. Без указания количества ссылок на одну и ту же сущность. Обычно число справа вверху над сущностью.
V>Image: entity_relation_02.svg
V>
Сокращаем схему до сущностей
V>Далее вопрос, а так ли нужны. V>1. Отношения. V>2. Атрибуты.
V>В конечном счёте. V>1. На понимание этих нюансов и как следствие перерисовку тратится время. V>2. Не факт, что удастся определить, что это не сущность, а именно отношение или атрибут. V>3. Нарушается правило монотонности дизайна, что в теории дизайна как раз затрудняет восприятие схем.
По-моему, вы просто не поняли, что такое ER-модель. Отсюда надуманная "проблема" и неадекватное "решение".
Вместо рисования абстрактной схемы в стиле "ехал сущность через сущность, сущность сущность сущность сущность" попробуйте нарисовать ER-модель простейшей предметной области.
Ну, там, классика — покупатель, товар, заказ.
И посмотрите, во что превращается эта модель при отказе от связей и атрибутов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>По-моему, вы просто не поняли, что такое ER-модель. Отсюда надуманная "проблема" и неадекватное "решение".
Проблема здесь сложнее, чем описано в статье. Это решение появилось после разбора ER, UML, BMPN и прочих. И что особенно важно, в эту схему заложена улучшенная EBNF. Для последнего я даже свои слова подобрал отвечающих критериям краткости, понятности и русскоязычности
1. Состав.
2. Выбор.
3. Повтор.
С примерами схем по принципу перевода слоями. Перевод слоями это тоже моё понятие для объяснения которого нужно писать статью.
А изначальный вопрос можно поставить так, как заменить все схемы и диаграммы одной? И ответ вот так. Только конкретных примеров для других схем и диаграмм не хватает. Но мои статьи это обычно промелькнувшие мысли. Я редко делаю сверхдетальный разбор с описаниями, так как на это может уйти не один день.
Конечная цель заключается в text processing, хотя в принципе понимание ручного режима до автоматизации тоже хороший вариант.
В вычислительной технике термин обработка текста относится к теории и практике автоматизации создания или обработки электронного текста. Текст обычно относится ко всем буквенно-цифровым символам, указанным на клавиатуре человека, занимающегося практикой, но в целом текст означает уровень абстракции непосредственно над стандартной кодировкой символов целевого текста. Термин обработка относится к автоматизированной (или механизированной) обработке, в отличие от тех же манипуляций, выполняемых вручную.
V>А изначальный вопрос можно поставить так, как заменить все схемы и диаграммы одной? И ответ вот так.
Вы переизобретаете RDF?
Для каких-то внутренних представлений такое может подойти. Для работы с человеком — нет.
Это всё равно, как заставлять человека общаться на языке из двух звуков. Формально доказано, что этого набора достаточно для передачи любой информации — но выразительность будет гораздо ниже, чем у обычного языка.
Так и тут — ER диаграммы позволяют компактно выразить устройство предметной области. Элементы отличаются не только формой, но и смыслом.
Фразы "У Пети есть машина" и "у машины есть цвет" звучат похоже, но имеют разную семантику.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вы переизобретаете RDF? S>Для каких-то внутренних представлений такое может подойти. Для работы с человеком — нет.
Дело в том, что все виды схем или диаграмм имеют какую-то парадигму. Про ту же RDF (не графическая схема) можно было бы говорить ещё проще, граф. Естественно я не изобретаю граф, просто потому, что всё уже давно изобрели до меня. Так же как и различные реализации вроде списка смежности и так далее. И на мой взгляд обсуждение этого вопроса больше бы подошло теме Словесный поток и чёткие структуры.
Компиляция (сборка).
1. Лексический анализ. Словесный разбор.
2. Синтаксический анализ. Составной разбор.
3. Семантический анализ. Смысловой разбор.
(Книга "Хантер Робин.Основные концепции компиляторов")
(Монотонный дизайн, который я упоминал в топике из книги "Купер Алан. Интерфейс. Новые направления в проектировании компьютерных систем")
Мысль у меня такая, обычный человек не сможет сразу уйти с текстового представление на графически представленный граф. Да и в принципе это не особо и нужно на начальном этапе. В конце концов основной "граф" у нас в памяти и именно он определяет, что мы можем сделать, а что нет. И именно нашему мозгу нужно помочь, но именно помочь, так как программы не сделают всё за нас.
Существует огромное количество проблем. Начать хотя бы с представления данных. Они ведь не только на английском языке, будь они даже на русском, это не значит, что выбор слов был наилучшим для конкретного человека. Например, append и push back частный случай insert в самый конец, а то и какой нибудь add со своими нюансами.
Взять тот же UML, что он делает. А ничего, он просто обёртывает всё по старому методу боксов, то есть список с заголовком. Но людям скажут, что это теперь не список с заголовком, а класс со свойствами и методами. Тоже самое и с ER, мне то какая разница что они там нарисовали прямоугольник или ромб с овалом, если внутри всё тот же текст. Есть ещё блок-схемы, диаграммы потоков и многое другое.
Действительно ли форма элементов, то есть вершин как-то решает. Вот здесь я сильно сомневаюсь. Ну или вместо этого можно было бы делать подпись как у стереотипа в UML, или изобрести цветовую кодировку. Если рассуждать в стиле я человек простой, то если это атрибут я мог бы просто делать дополнительную подпись "атрибут", а не выдумывать овал. Тоже самое касается отношения и чего угодно. По сути форма фигур ограничивает количество вариантов количеством форм.
И тем не менее графическое представление по прежнему работает точно так же как и метод боксов у которого основное назначение сопоставление понятий.
А можно сказать по другому используя логические (мыслительные) приёмы.
1. Разбор (анализ).
2. Сбор (синтез).
3. Сравнение.
Вот именно для этого все вышеупомянутые мной диаграммы и нужны. Только каждая пытается следовать какой-то парадигме заложенной авторами по своему разумению. И скажем так, эволюция им бы не помешала, так как простые вещи они выражают довольно криво.
Здравствуйте, velkin, Вы писали:
V>Дело в том, что все виды схем или диаграмм имеют какую-то парадигму.
Все виды диаграмм визуализируют какую-то модель.
Вы же говорите не про "картиночки", а про устройство самой модели.
V>Про ту же RDF (не графическая схема) можно было бы говорить ещё проще, граф.
RDF — это не просто граф, и не всякий граф — это RDF.
V>У меня же речь идёт о парсинге (синтаксический анализ) с точки зрения обработки текста (text processing).
Диаграммы и обработка текста связаны между собой примерно никак.
V>Мысль у меня такая, обычный человек не сможет сразу уйти с текстового представление на графически представленный граф.
"Графическое" представление позволяет ускорить восприятие некоторых вещей, замедляя восприятие других.
Повторюсь: вопрос не столько в "картинках", сколько в устройстве и топологии модели.
V>Существует огромное количество проблем. Начать хотя бы с представления данных. Они ведь не только на английском языке, будь они даже на русском, это не значит, что выбор слов был наилучшим для конкретного человека. Например, append и push back частный случай insert в самый конец, а то и какой нибудь add со своими нюансами.
Пока что всё ещё непонятно, в какой области возникают проблемы, и какие решения вы предполагаете.
В целом, мы говорим о какой-то модели. Модель выражена в терминах каких-то "частей", которые тем или иным образом складываются в цельную картину.
Чтобы модель передать от одного разума к другому, нам нужен некоторый язык.
Может быть — текстовый, может быть — звуковой, может быть — графический.
Или комбинация тех и других.
Но есть два разных аспекта: структура самой модели (метамодель), и устройство языка, которым эта модель описывается.
ER-модель можно описывать текстом, можно — диаграммой с фигурами и линиями. Но модель будет одна и та же.
Если в мета-модели у вас есть понятия "атрибут", "тип атрибута", "сущность", "тип сущности", "связь", "тип связи", "роль", то модель строится именно в этих терминах.
Мы можем выбирать разные способы изображения этих понятий — формой, цветом, текстом. Но если вы говорите, "давайте откажемся от этих понятий", то вы теряете в выразительности модели, независимо от конкретного языка, которым вы её описываете.
V>Взять тот же UML, что он делает. А ничего, он просто обёртывает всё по старому методу боксов, то есть список с заголовком.
Ничего подобного. Без мета-модели, то есть некоторой договорённости о том, что означают "боксы", UML-диаграммы не имеют никакого смысла. V>Но людям скажут, что это теперь не список с заголовком, а класс со свойствами и методами. Тоже самое и с ER, мне то какая разница что они там нарисовали прямоугольник или ромб с овалом, если внутри всё тот же текст. Есть ещё блок-схемы, диаграммы потоков и многое другое.
Совершенно верно. И все они означают совершенно разные вещи. Я не понимаю, как вы собираетесь "заменить все диаграммы одной диаграммой" без потери смысла.
V>Действительно ли форма элементов, то есть вершин как-то решает. Вот здесь я сильно сомневаюсь. Ну или вместо этого можно было бы делать подпись как у стереотипа в UML, или изобрести цветовую кодировку. Если рассуждать в стиле я человек простой, то если это атрибут я мог бы просто делать дополнительную подпись "атрибут", а не выдумывать овал. Тоже самое касается отношения и чего угодно. По сути форма фигур ограничивает количество вариантов количеством форм.
Вы явно путаете форму и суть. Любую ER-диаграмму можно записать в текстовом представлении; для того, чтобы она описывала именно ER-модель, на это текстовое представление придётся наложить какие-то ограничения.
Например, в обычной ER-диаграмме нельзя использовать фигуру "звезда". Это никак не связано с формой — в текстовом описании модели вы точно так же не сможете, к примеру, привязать что-то с припиской "метод" к типу сущности. Потому что в мета-модели ER нет понятия "метод". Есть только "атрибут", "тип атрибута", "сущность", "тип сущности", "связь", "тип связи", "роль". А в диаграмме классов UML (или в описании класса ООП модели) вы к классу привязать "метод" вполне можете.
V>Вот именно для этого все вышеупомянутые мной диаграммы и нужны. Только каждая пытается следовать какой-то парадигме заложенной авторами по своему разумению. И скажем так, эволюция им бы не помешала, так как простые вещи они выражают довольно криво.
Вы всё ещё даже не попробовали повыражать хоть какие-то вещи при помощи этих диаграмм. Практика — критерий истины, а не абстрактные рассуждения "можно ли заменить форму цветом". Кстати, нет, нельзя — это сделает вашу диаграмму нечитаемой значительной долей целевой аудитории.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вы всё ещё даже не попробовали повыражать хоть какие-то вещи при помощи этих диаграмм. Практика — критерий истины, а не абстрактные рассуждения "можно ли заменить форму цветом". Кстати, нет, нельзя — это сделает вашу диаграмму нечитаемой значительной долей целевой аудитории.
Пробовал выражать тысячи понятий, но это было много лет назад. Про цвет очень верное замечание. Цвет позволяет очень быстро находить нужные схемы, когда масштаб 10%. Позволяет быстрее понимать схему, если помнишь цветовой код. Но понять схему с нуля не позволяет. Искать цветовые коды тоже непонятно где. Потому цветовые коды нужны как дополнение к тексту, а не как основу для понимания.
Между прочим тоже самое могу сказать и о форме вершин. Я потому и говорю, что смысла во всех этих овалах, ромбах и прочих нет. Имеет значение только то, что написал текстом и связи между текстовыми элементами. И раз уж речь зашла об этом, думаю подобное можно распространить и на иконки в элементах. Я как раз над этим думал, а вот и ответ.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>Вы всё ещё даже не попробовали повыражать хоть какие-то вещи при помощи этих диаграмм. Практика — критерий истины, а не абстрактные рассуждения "можно ли заменить форму цветом". Кстати, нет, нельзя — это сделает вашу диаграмму нечитаемой значительной долей целевой аудитории.
V>Пробовал выражать тысячи понятий, но это было много лет назад.
Пора вернуться к истокам. Мы же работаем в рамках инженерных дисциплин. Перед тем, как проектировать новую библиотеку/фреймворк/язык/платформу, нужно озаботиться её применением к типичным задачам.
По легенде, Delphi начинался с того, что Хейльсберг на доске написал Form1.OkButton.Font.Color := clRed. Из обсуждения того, что это должно означать, и как среда исполнение это значение "поймёт", и родился весь язык Object Pascal вместе со стандартом сериализации объектов и VCL.
Так и тут — если вы изобретаете новую нотацию, поупражняйтесь в её применении к существующим задачам.
Без этого ваш проект обречён на неудачу. Только в результате маловероятной случайности спроектированная вами конструкция станет обладать какими-либо полезными свойствами.
V>Между прочим тоже самое могу сказать и о форме вершин. Я потому и говорю, что смысла во всех этих овалах, ромбах и прочих нет. Имеет значение только то, что написал текстом и связи между текстовыми элементами. И раз уж речь зашла об этом, думаю подобное можно распространить и на иконки в элементах. Я как раз над этим думал, а вот и ответ.
Вы неверно меня поняли. Текст тоже не имеет смысла до тех пор, пока кто-то его не прочтёт и не осознает.
Речь идёт о том, что лежит в основе придумываемого вами языка. ER-модель можно описывать и текстом — но в этом тексте будут какие-то ключевые слова для ссылок на понятий "тип атрибута", "тип сущности", "тип связи", "роль", "значение".
Если в вашем языке таких понятий не будет — то у вас будет не ER-модель. Возможно, на вашем языке можно описать в том числе и ER-модель, добавив к собственно описанию модели описание правил трансляции вашей модели в ER-модель. Но будет ли это удобнее и практичнее, чем сама ER-модель — это большой вопрос. И самый простой способ на него ответить — это попытаться привести описание несложной ER-модели на вашем языке.
С вероятностью процентов в 95% ваше описание будет менее удобным, чем ER-модель. То есть будет более многословным, чреватым ошибками, и хуже выражающим намерения разработчика.
А выбор символики тут вторичен. Оттого, что вы замените форму на цвет, или на стиль линий границы, или на шрифт, которым пишутся надписи на фигурах, структура языка не поменяется.
Это как получать "новый" язык при помощи замены ключевых слов C# на русскоязычные аналоги — вы не получите никакого нового языка; это будет тот же C#, записанный другими буквами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>По легенде, Delphi начинался с того, что Хейльсберг на доске написал Form1.OkButton.Font.Color := clRed. Из обсуждения того, что это должно означать, и как среда исполнение это значение "поймёт", и родился весь язык Object Pascal вместе со стандартом сериализации объектов и VCL.
Это легенда. Паскаль умел такое задолго до Дельфи. Там по другому собственно и нельзя было. В turbo vision было много чего такого.
Здравствуйте, Pauel, Вы писали:
P>Это легенда. Паскаль умел такое задолго до Дельфи.
Простите, но ничего подобного Паскаль не умел. Концепция Property появилась только в Object Pascal из Delphi 1.0.
А вместе с ней — и концепция метаданных через published, привязки обработчиков событий через procedure of object, а также class virtual методы и конструкторы.
P>Там по другому собственно и нельзя было. В turbo vision было много чего такого.
В Turbo Vision из "такого" были только обработчики событий, и то на ручном приводе.
Приведённая строчка в Паскале означала всего лишь присваивание значения в поле — а вот возможность динамически перерисовать контрол, одновременно с установкой ParentFont в false, появилась только в Delphi.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
