0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Настал момент, когда нужно начинать проектировать приложение. И делать мы это будем, используя Entity-relationship Model</p>
1
<p>Настал момент, когда нужно начинать проектировать приложение. И делать мы это будем, используя Entity-relationship Model</p>
2
<blockquote><p>ERM - Модель данных, позволяющая описывать концептуальные схемы предметной области.</p>
2
<blockquote><p>ERM - Модель данных, позволяющая описывать концептуальные схемы предметной области.</p>
3
</blockquote><h2>Сущности</h2>
3
</blockquote><h2>Сущности</h2>
4
<p>Этот подход включает в себя два основных понятия: сущность и связь. Проще всего начать с примеров:</p>
4
<p>Этот подход включает в себя два основных понятия: сущность и связь. Проще всего начать с примеров:</p>
5
<ul><li>Пользователь</li>
5
<ul><li>Пользователь</li>
6
<li>Кинозал</li>
6
<li>Кинозал</li>
7
<li>Фильм</li>
7
<li>Фильм</li>
8
<li>Билет</li>
8
<li>Билет</li>
9
<li>Показ фильма</li>
9
<li>Показ фильма</li>
10
</ul><p>Это сущности нашей предметной области, с которыми предстоит работать в коде. Как видите, понятие сущность довольно интуитивно. Но также оно обладает и рядом формальных характеристик:</p>
10
</ul><p>Это сущности нашей предметной области, с которыми предстоит работать в коде. Как видите, понятие сущность довольно интуитивно. Но также оно обладает и рядом формальных характеристик:</p>
11
<ul><li>Идентификация</li>
11
<ul><li>Идентификация</li>
12
<li>Время жизни</li>
12
<li>Время жизни</li>
13
</ul><p>Идентификация означает, что мы можем рассматривать сущности независимо и выделять одни среди других. Например, у нас есть разные кинозалы, и это разные сущности. Другой пример это пользователи. Даже если два человека имеют одинаковые ФИО, мы всё равно сможем их различить на основе дополнительных признаков. В программировании обычно сущностям присваивается идентификатор (суррогатный ключ), который и используется для этой цели. Чаще всего эта задача возлагается на базу данных. В нашей ситуации базы нет, поэтому мы будем задавать его самостоятельно.</p>
13
</ul><p>Идентификация означает, что мы можем рассматривать сущности независимо и выделять одни среди других. Например, у нас есть разные кинозалы, и это разные сущности. Другой пример это пользователи. Даже если два человека имеют одинаковые ФИО, мы всё равно сможем их различить на основе дополнительных признаков. В программировании обычно сущностям присваивается идентификатор (суррогатный ключ), который и используется для этой цели. Чаще всего эта задача возлагается на базу данных. В нашей ситуации базы нет, поэтому мы будем задавать его самостоятельно.</p>
14
<p>Библиотека uuid позволяет генерировать уникальный идентификатор, который можно использовать для идентификации. Кстати<a>uuid</a>очень полезная штука, может пригодиться в некоторых типах задач.</p>
14
<p>Библиотека uuid позволяет генерировать уникальный идентификатор, который можно использовать для идентификации. Кстати<a>uuid</a>очень полезная штука, может пригодиться в некоторых типах задач.</p>
15
<p>Время жизни означает, что наша сущность в какой-то момент появилась и когда-то может исчезнуть.</p>
15
<p>Время жизни означает, что наша сущность в какой-то момент появилась и когда-то может исчезнуть.</p>
16
<h2>Связи</h2>
16
<h2>Связи</h2>
17
<p>Между собой сущности образуют связи. Например, человек может быть владельцем нескольких машин, но машина может принадлежать только одному человеку. Пользователи Хекслета проходят много курсов, каждый курс доступен всем пользователям.</p>
17
<p>Между собой сущности образуют связи. Например, человек может быть владельцем нескольких машин, но машина может принадлежать только одному человеку. Пользователи Хекслета проходят много курсов, каждый курс доступен всем пользователям.</p>
18
<p>Таким образом можно выделить три основных типа связи: один к одному (o2o), один ко многим (o2m) и многие ко многим (m2m).</p>
18
<p>Таким образом можно выделить три основных типа связи: один к одному (o2o), один ко многим (o2m) и многие ко многим (m2m).</p>
19
<p>Выше представлена диаграмма Entity-Relationship. Она входит в стандарт<em>UML</em>и неплохо помогает понять то, какие сущности составляют вашу предметную область и как они друг с другом связаны.</p>
19
<p>Выше представлена диаграмма Entity-Relationship. Она входит в стандарт<em>UML</em>и неплохо помогает понять то, какие сущности составляют вашу предметную область и как они друг с другом связаны.</p>
20
<p>Что можно сказать глядя на диаграмму?</p>
20
<p>Что можно сказать глядя на диаграмму?</p>
21
<ul><li>В одном зале может быть много показов фильмов;</li>
21
<ul><li>В одном зале может быть много показов фильмов;</li>
22
<li>Один фильм может быть показан много раз;</li>
22
<li>Один фильм может быть показан много раз;</li>
23
<li>Фильмы и залы связаны друг с другом как "многие ко многим". То есть один фильм показывается в разных залах, а в одном зале идут разные фильмы.</li>
23
<li>Фильмы и залы связаны друг с другом как "многие ко многим". То есть один фильм показывается в разных залах, а в одном зале идут разные фильмы.</li>
24
</ul><p>Всё это довольно очевидно и соответствует нашему опыту посещения кинозалов. В других предметных областях это уже не так просто, и то, как вы проектируете сущности и их связи, имеет сильное влияние на ваше приложение. Общее правило такое, чем больше связей и чем более они разнообразные, тем сложнее приложение. Часто бывает такое, что программисты "закладываются на будущее" (которое не факт, что наступит) и пытаются делать чуть ли не все связи<em>m2m</em>. Чаще всего такой подход оказывается примером<em>over-engineering</em>(гиперпроектирование), другими словами, не надо добавлять сложности там, где нет реальной потребности.</p>
24
</ul><p>Всё это довольно очевидно и соответствует нашему опыту посещения кинозалов. В других предметных областях это уже не так просто, и то, как вы проектируете сущности и их связи, имеет сильное влияние на ваше приложение. Общее правило такое, чем больше связей и чем более они разнообразные, тем сложнее приложение. Часто бывает такое, что программисты "закладываются на будущее" (которое не факт, что наступит) и пытаются делать чуть ли не все связи<em>m2m</em>. Чаще всего такой подход оказывается примером<em>over-engineering</em>(гиперпроектирование), другими словами, не надо добавлять сложности там, где нет реальной потребности.</p>
25
<p>Кроме влияния на логику работы, связи также сильно влияют на способ хранения сущностей в базе данных. Например, в реляционных базах данных, связь<em>m2m</em>всегда подразумевает наличие промежуточной таблицы. В свою очередь рефакторинг базы данных не такое простое занятие, как изменение кода.</p>
25
<p>Кроме влияния на логику работы, связи также сильно влияют на способ хранения сущностей в базе данных. Например, в реляционных базах данных, связь<em>m2m</em>всегда подразумевает наличие промежуточной таблицы. В свою очередь рефакторинг базы данных не такое простое занятие, как изменение кода.</p>
26
<h2>Пример</h2>
26
<h2>Пример</h2>
27
<p>На Хекслете есть курсы. Каждый курс состоит из уроков. Урок не может существовать без курса. Вот как может быть представлена эта модель в коде:</p>
27
<p>На Хекслете есть курсы. Каждый курс состоит из уроков. Урок не может существовать без курса. Вот как может быть представлена эта модель в коде:</p>
28
<p>Передача курса в конструктор удобна по двум причинам. Сразу становится видна и понятна связь урока с курсом. А также на уровне языка заложено бизнес-правило, что урок не может существовать без курса.</p>
28
<p>Передача курса в конструктор удобна по двум причинам. Сразу становится видна и понятна связь урока с курсом. А также на уровне языка заложено бизнес-правило, что урок не может существовать без курса.</p>
29
<h2>Объекты-значения (Справочники)</h2>
29
<h2>Объекты-значения (Справочники)</h2>
30
<p>Кроме сущностей в предметной области всегда есть и значения, или, как их обычно называют, объекты-значения. В отличие от сущностей у них нет идентификации. Возьмём такое понятие как деньги (Money). Если мы не являемся казначейством, то нужно ли нам отличать одни 100$ от других 100$? Вероятно, нет. Для нас не существует сущности 100$, всё, что имеет значение, это номинальная стоимость этих денег, другими словами, в случае объектов-значений сравнение происходит не по идентификации, а на основе фактического значения. То же самое применимо ко всем справочным данным. Имена стран (производители фильмов), адреса, список городов и многое другое.</p>
30
<p>Кроме сущностей в предметной области всегда есть и значения, или, как их обычно называют, объекты-значения. В отличие от сущностей у них нет идентификации. Возьмём такое понятие как деньги (Money). Если мы не являемся казначейством, то нужно ли нам отличать одни 100$ от других 100$? Вероятно, нет. Для нас не существует сущности 100$, всё, что имеет значение, это номинальная стоимость этих денег, другими словами, в случае объектов-значений сравнение происходит не по идентификации, а на основе фактического значения. То же самое применимо ко всем справочным данным. Имена стран (производители фильмов), адреса, список городов и многое другое.</p>
31
<p>Важно понимать, что это не абсолютная истина. Будет ли какое-то понятие сущностью или значением зависит от конкретной предметной области.</p>
31
<p>Важно понимать, что это не абсолютная истина. Будет ли какое-то понятие сущностью или значением зависит от конкретной предметной области.</p>