Учимся проектированию Entity Relationship-диаграмм

[lair]

Приведём пример: [...] Думаю, Вы поняли, что к чему. Наш Программист учит Python

Да, я понял. Питон учит программиста.

А знаете, почему? Потому что стрелочки надо рисовать.

Entity Relatioship — целый стандарт,

Вот прямо вот стандарт? А какой организацией он принят, в каком документе описан?

[Doctor_IT]

1) Про ошибку в примере — соглашусь. Сделаю правку с «Учит» на «Обучение», но вот "стрелочки" в данной модели не используются.

2)Стандарт не обязательно должен быть прописан, но тут больше подходит выражение «Сколько людей, столько и мнений». Тем не менее данная модель давольно популярна и очень гибкая.
В любом случае, спасибо, за указанную ошибку.

[lair]

Про ошибку в примере — соглашусь. Сделаю правку с «Учит» на «Обучение»

… и эта правка сделает еще хуже, потому что понять, кто кого учит, будет окончательно невозможно.

вот "стрелочки" в данной модели не используются.

Вы, наверное, хотели сказать, вы не используете, и не встречали, чтобы использовали?

Стандарт не обязательно должен быть прописан

Ну то есть нет никакого "стандарта", а есть какая-то модель, которая вам понравилась, и которую вы понимаете каким-то удобным вам образом.

Сколько людей, столько и мнений

… так почему же надо учить именно эту модель, и именно в том виде, который вы предлагаете, если у него прямо вот очевидно есть недостатки?

[Doctor_IT]

Хорошо, про стандарт уберу.
Ну, про «надо» я не говорил, прямо. Я советовал. В первую очередь читателю решать, использовать ли эту модель в будущем. Я лишь написал статью про привычную мне модель, про которую в Рунете, а особенно на Хабр(Российский Сигмент), информации либо почти нет, либо нет вообще

[lair]

Ну так может потому и нет (хотя на самом деле — есть, и легко находится поиском), что она не так удобна, как вам кажется?

[sshikov]

>информации либо почти нет, либо нет вообще

Угу, угу. Я вот просто ткнул в поиск по хабру, набрал «ER-диаграммы», и получил десяток ответов минимум.

Так что вопрос скорее стоит так: зачем было это писать, если информации на первый взгляд как раз навалом? Чем ваша статья лучше чем те 10 или больше, которые уже были прямо тут опубликованы? Не говоря уже про другие ресурсы (собственно, первая книга, где я видел описание этой модели, была издательства Мир, и примерно 1980 года издания). Вы считаете, что никто про ER модели не знает, и поэтому не использует?

[Doctor_IT]

Я не говорю, что лучше. Читать или нет — выбор пользователей.

[sshikov]

Ну, я собственно отвечал на ваш же комментарий чуть выше, что информации мало. На мой взгляд, тему уже много раз разжевали и в рот положили, всем кому было интересно.

[megaentwickler]

Вот бы ещё во всех конторах документировали схемы данных в такие диаграммы…
Ни одной ещё не встретил, которая могла бы похвастать этим.

[Doctor_IT]

У всех свои методы

[akryukov]

Зачем во всех и почему именно в такие?
Большинство инструментов для работы с СУБД могут вам сделать диаграмму базы данных автоматически по уже существующим таблицам.

[Doctor_IT]

Как я и говорил ранее:
Данная модель проектирования очень гибкая и используется не только при проектировании Баз Данных. Однако, тот же MySQL Workbench унаследовал типы связи, которые чуть иным образом обозначены, но сохраняют смысл

[akryukov]

Главный плюс модели проектирования Entity Relationship — это то, что она универсальна. Вы можете проектировать БД(Базы данных), работу какой-либо программы, принципы взаимодействия и др.

Что именно понимается под "работой какой-либо программы"? Если подразумевается последовательность действий и изменение состояния какой-то сущности, то в ER будет затруднительно это нарисовать.
Попробуйте, например, выразить ER-диаграммой "Человек забронировал билет на сайте и указал свою почту. Ему пришло письмо с подтверждением брони. После перехода по ссылке из письма, место стало забронировано человеком. Если перехода по ссылке не было, то место остается свободным. За час до начала сеанса человек выкупил билет в кассе. Забронированное место было помечено как выкупленное. Если за 40 минут до начала сеанса бронь не была выкуплена, то место считается свободным."

Было бы неплохо подробнее описать применимость ER-диаграммы к реальной работе, уточнить для чего она больше подходит и дать ссылки на смежные темы.

Источники
— ru.wikipedia.org/wiki/Заглавная_страница

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

[Doctor_IT]

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

Насчет источников — исправил. Впервые написал статью, пока что набираюсь опыта. Спасибо за указания.

[nickavery]

В курсовой по проектированию БД активно использовали ER-диаграммы. Подробное руководство приводилось, например, в книге Т.Коннолли «Базы данных. Проектирование, реализация и сопровождение. Теория и практика». В других областях использование ER пока не встречал.

[Doctor_IT]

так или иначе, в описании некоторых «блоков», написанной программы, помочь может.

[VolCh]

На практике встречал использование при применении DDD.

[keydet]

Подскажите, а зачем выделять relationship в ромб? Почему нельзя написать над линией?

Какие преимущества перед UML composite structure diagram?

[Doctor_IT]

Иногда приходится и обособлять, даже ошибочно, но так, чтобы было понятно. Хотя, вернее, было описать как: «характеризует действие»… но тогда все бы использовали только промежуточные сущности.

[zloylemon]

Интересная модель проектирования, использовать я ее, конечно, не буду