Er модель для нашей системы пользователь user и сообщение post

Обновлено: 04.07.2024

В этом разделе вы подробно познакомитесь с ER-диаграммами и моделями, их истоками, сферами применения, примерами, компонентами и ограничениями. Здесь же вы узнаете, как создать собственную ER-диаграмму на нашей платформе.

Читается за 12 мин.

Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.

Что такое ER-диаграмма?

В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:

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

Обращаем ваше внимание на тот факт, что похожие уровни масштаба и детализации встречаются и в других видах схем (например, в диаграммах DFD), однако данная классификация отличается от трехсхемного подхода в разработке ПО, где деление информации осуществляется по несколько иному принципу. Правда, иногда разработчики применяют ER-диаграммы с дополнительными иерархиями, если дизайн базы данных требует больше информационных уровней. К примеру, разработчик может добавить новые группы по принципу расширения вверх (суперклассы) и вниз (подклассы).

Только реляционные данные. Следует четко понимать, что цель ER-диаграмм — показать связи и отношения между элементами, поэтому они отображают только реляционную структуру.
Только для структурированных данных. Данные должны быть четко разбиты на поля, столбцы и строки, иначе пользы от ER-диаграммы будет мало. Это касается и частично структурированных данных, так как только некоторые из них будут пригодны для работы.
Сложность интеграции с существующей базой данных. Применение ER-моделей для интеграции с существующей базой данных — непростая задача по причине различия в архитектурах.

Проектирование баз данных. ER-диаграммы применяются для моделирования и проектирования реляционных баз данных, причем как в плане логических и бизнес-правил (логические модели данных), так и в плане внедрения конкретных технологий (физические модели данных). В сфере разработки программного обеспечения ER-диаграмма, как правило, служит первым шагом в определении требований проекта по созданию информационных систем. На дальнейших этапах работы ER-диаграммы также применяются для моделирования конкретных баз данных. Реляционная база данных сопровождается соответствующей реляционной таблицей и при необходимости может быть представлена в этом формате.
Отладка баз данных. ER-диаграммы применяются для анализа уже имеющихся баз данных с целью выявить и устранить ошибки в логике или развертывании. Диаграмма позволяет выявить, где именно закрались ошибки.
Информационные системы для бизнеса. ER-схемы используются для проектирования и анализа реляционных баз данных, применяемых в бизнес-процессах. Реляционные базы данных могут пригодиться в любом бизнес-процессе, где задействованы данные, разбитые на поля, включая сущности, действия и взаимосвязи. Базы данных помогают оптимизировать процессы, извлекать данные и повышать качество результатов.
Реорганизация бизнес-процессов (BPR). ER-диаграммы помогают анализировать базы данных, применяемые при реорганизации бизнес-процессов и моделировании новых баз данных.
Образование. Базы данных — широко распространенный в наши дни способ хранения реляционной информации, применяемой в целях образования и для последующего извлечения данных, поэтому ER-диаграммы играют не последнюю роль в планировании подобных структур данных.
Исследовательская деятельность. Поскольку исследовательская работа во многом опирается на четко структурированные данные, ER-диаграммы играют ключевую роль в построении оптимальных баз данных для анализа информации.

Символы и способы нотации ERD

Символы ERD-сущностей

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

Символы ERD-связей

Отношение между сущностями.

Символы ERD-атрибутов

ERD-атрибуты характеризуют сущности, позволяя пользователям лучше разобраться в устройстве базы данных. Атрибуты содержат информацию о сущностях, выделенных в концептуальной ER-диаграмме.

Характеризует сущность, а также отношения между двумя или более элементами.

Атрибут, которому может быть присвоено несколько значений.

Атрибут, чье значение можно вычислить, опираясь на значения связанных с ним атрибутов.

Отношение между сущностями.

Символы физических ER-диаграмм

Ключи

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

Первичные ключи

Первичный ключ — это атрибут или сочетание атрибутов, идентифицирующих один конкретный экземпляр сущности.

Внешние ключи

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

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

Нотация ER-диаграмм

Кардинальность и ординальность

Под кардинальностью подразумевается максимальное число связей, которое может быть установлено между экземплярами разных сущностей. Ординальность, в свою очередь, указывает минимальное количество связей между экземплярами двух сущностей.

Кардинальность и ординальность отображаются на соединительных линиях согласно выбранному формату нотации.

Как создать простую ER-диаграмму

2. Определитесь со связями (они показывают, как сущности взаимодействуют между собой)

3. Добавьте атрибуты (они иллюстрируют конкретные характеристики сущности, фокусируя внимание на важной информации в контексте модели)

4. Внесите последние штрихи

Как создать ER-диаграмму в Lucidchart

Lucidchart — онлайн-платформа, где удобно создавать схемы баз данных. Регистрируйтесь и пользуйтесь нашими услугами бесплатно! Достаточно завести учетную запись — и вы сможете тут же приступить к схематизации своих баз данных.

Активация библиотек ERD-фигур

Перетаскивание фигур

Соединение фигур

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

Дополнительные советы по созданию ER-диаграмм

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

Избегайте лишних сущностей и связей.

Если схема создается с целью отладки базы данных, обращайте внимание на пробелы в связях или отсутствие сущностей или атрибутов.

Сопровождайте все сущности и связи необходимыми ярлыками.

Вы можете конвертировать реляционные таблицы в ER-диаграммы и обратно, если вам удобнее работать таким образом.

Убедитесь, что ER-диаграмма поддерживает все виды данных, которые подлежат хранению.

Шаблоны и примеры ER-диаграмм

Шаблон ER-диаграммы базы данных

Схема ER-диаграммы базы данных позволяет продемонстрировать, как сущности в пределах базы данных связаны между собой и какие атрибуты характеризуют каждую из них. На примере ниже показаны сущности в составе школьной системы.

Шаблон ER-диаграммы заказа на покупку

На этой ER-диаграмме показано, какие сущности, связи и атрибуты задействованы в документе заказа на покупку. Схема позволяет наглядно представить задействованную информацию, чтобы ее было проще понять и объяснить.

Шаблон ER-диаграммы для библиотеки

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

Lucidchart позволяет беспрепятственно упорядочивать фигуры, соединительные линии и ярлыки и тем самым с легкостью создавать ER-диаграммы. Весь процесс разворачивается онлайн, и поэтому вы без труда сможете редактировать свою схему вместе с коллегами. Готовым результатом затем можно поделиться в цифровом или печатном формате.

Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.

Ни. Здесь мы имеем дело с самостоятельностью.

Как только вы расчлените его, то есть, как только вы выполните декомпозицию с логической моделью, вы получите следующий случай:

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

Хочу описать правила, по которым можно построить реляционную схему базы данных. Правила эти, наверное, мало кому нужны, поскольку они используются разработчиками на интуитивном уровне, но интересны даже тем, что формализуют процесс построения схемы БД.

ER-модель

Сущность — это реальный, либо воображаемый объект, информацию о котором необходимо хранить в базе данных. На диаграмме ER-модели сущность изображается в виде прямоугольника, содержащего имя сущности.
Связь — отображаемая графически на диаграмме ассоциация между двумя (чаще всего) сущностями, или между одной и той же сущностью (рекурсивная связь). Связь изображается ромбом, на котором выделяются два конца, по одному на каждую сущность. Для каждой стороны этой связи устанавливаются:
1. Степень связи — сколько экземпляров данной сущности связывается
2. Обязательность связи — обязательно ли данная сущность должна участвовать в связи.

Рис.1

Отношение (обычно оно соответствует таблице в базе данных) не следует путать с сущностью. Сущность переходит в отношение путем выделения её из ER-диаграммы.

Этапы проектирования

Концептуальное проектирование

Строится ER-диаграмма, включающая в себя все сущности и связи. Мы получаем концептуальную (инфологическую) модель. Следует понимать, что такая модель может далеко не соответствовать реляционной структуре проектируемой базы данных.

Допустим, нужно построить базу данных, в которой будет необходимо хранить полную информацию о заказах, клиентах, сотрудниках. Для каждого заказа есть список элементов этого заказа (несколько изделий), каждому из которых сопоставлен список израсходованных материалов, и произведенных операций.

У меня получилась следующая диаграмма.

Рис. 2

Логическое проектирование

Строится набор предварительных отношений с указанием первичного ключа для каждого отношения. Составляется список атрибутов, затем эти атрибуты распределяются по отношениям. Необходимо, чтобы все отношения оставались в НФБК.

Переход к реляционной структуре (построение набора отношений) производится по следующим правилам:

Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения.
Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения — по одному для каждой сущности — ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности.
Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности.
Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
Если степень бинарной связи равна М: М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то — два отношения (т.е. достаточно будет двух таблиц).
В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности.

Воспользуемся правилами, сведем данные в таблицу.

Модель сущность-связь (Entity-Relationship, ER) применяется для моделирование предметной области (разработки словаря системы) и логической структуры базы данных.

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

Цель статьи — помочь в ситуации, когда по каким-то причинам вам нужно построить ER-диаграмму, но вы не знаете как это правильно сделать.

ER-модель описывает сущности и отношения между ними с использованием графической нотации. Сущности содержат атрибуты (свойства). Например, если вы разрабатываете систему для спортивных клубов — то:

Проблемы с разработкой ER-модели возникают потому что:

Существует несколько нотаций, но нет единого стандарта (системы обозначений) для ER-модели:
- В старых книгах чаще всего встречается нотация Чена, на мой взгляд это наименее удобный способ, кроме того, мне не удалось найти нормальных инструментов для построения диаграмм в этой нотации.
- Можно натолкнуться на нотацию Бахмана, нотацию min-max и ряд других. Встречаются они достаточно редко, стандарта на них нет, говорить про них не будем.
- Нотация IDEF1X, нотация диаграммы классов UML, нотация Мартина (вороньи лапки). Все эти три нотации очень часто встречаются и используются. Есть инструменты, в которых их удобно строить.
1 Основные возможности. Нотация Чена

В качестве единственного примера этой нотации рассмотрим ER-диаграмму базы кинотеатра из соседней статьи [Chen_model]. Кстати, в статье описан процесс проектирования структуры БД.

В этой нотации сущность отображается прямоугольником, ее атрибуты — овалами, а отношения между сущностями — ромбами. Имена ключевых атрибутов подчеркиваются. На дугах можно проставить арности (кратности) связей, а также ограничения типа « film и screening . Это ошибка, ведь один фильм в кинотеатре показывается много раз и в разных залах. Еще одна ошибка — один кассир продает лишь один билет. Скорее всего вы не заметили эти ошибки так как даже диаграмма для сильно упрощенной системы оказалась перегружена и сработал закон Миллера. Попробуйте найти эти же недочеты на диаграмме в нотации Миллера.

Ключевые поля на диаграмме помещаются в верхнюю секцию прямоугольника, видно что у Билета используется составной ключ. Кроме того, эта нотация позволяет описать типы полей (у Чена только названия).

3 Нотация диаграммы классов UML

Нотация Мартина во многом похожа на нотацию диаграммы классов UML, ознакомиться с которой можно в статье [UML_class]. Однако, ее применение для моделирования предметной области и структуры БД имеет ряд особенностей:
- сущности и их свойства изображаются точно также как в нотации Мартина (прямоугольник с секциями). Нижняя (третья) секция символа класса часть остается пустой, так как она предназначена для записи функций класса, однако иногда в нее помещают описание индексов и триггеров БД со стереотипами > и .
- используется очень маленькое подмножество системы обозначений, так как для предметной области не имеют особого смысла виртуальные функции, абстрактные классы, статические поля, агрегация, закрытое наследование, …;
- обычно возникает потребность в отображении ограничений, для этого используются стереотипы (первичный ключ), > (внешний ключ) и
Диаграмма классов активно используется при объектно-ориентированном проектировании и для ее построения существует множество инструментов. Это очень удобно если вы при изучении программирования уже успели познакомиться с нотацией диаграммой классов. В качестве ER-модели эта ноация исопльзуется, например, в инструментах серии Rational от IBM. Самое главное отличие этой нотации от предыдущих — на нее существует международный стандарт [UML_ISO_1, UML_ISO_2]. Дополнительно рекомендую прочитать статью [ER_Krivishein], так как мной были упущены некоторые аспекты — например, особенности использования агрегации и наследования на этих диаграммах (лично я считаю, что в 99% случаев они будут лишними).

4 Нотация IDEF1X

Существует масса других нотаций, которые от описанных выше отличаются системой обозначений и лишь в редких случаях вносят какие-либо новые возможности. Рассматривать их нет никакого смысла. Однако, нельзя не упомянуть про IDEF1X так как на него существует международный стандарт [IDEF1X_ISO]. Очень хороший материал по использованию этого стандарта приведен в [Anisimov_IDEF1X].

Из неприятного, в стандарте IDEF1X исопльзуются символы и типы связей, не поддерживаемые многими инструментальными средствами. Инструмент ERwin Data Modeler целиком и полностью посвящен моделированию БД с исопльзованием IDEF1X. При этом ERwin работает только под Windows и имеет проприетарную лицензию.

На мой взгляд, наиболее удобные инструментальные средства используют нотации Мартина или UML. Я рекомендую выбирать для работки модели одну из этих двух нотаций исходя из того, насколько вам важна стандартизация — на UML есть стандарт, а на нотацию Мартина нет.

Django предоставляет из коробки систему аутентификации и авторизации(permission) пользователей. Эта система позволяет проверять учетные данные пользователей и определять права доступа для пользователей. Ввод логина и пароля - это аутентификация пользователей , а права доступа на редактирование записей , создание новых и удаление - это уже авторизация. Поэтому,с помощью permissions мы указываем какие действия могут выполнять пользователи на сайте , а к каким запрещен доступ.

После создания нового проекта на Django , то в файле settings.py вы можете увидеть , что система аутентификации django.contrib.auth уже включена . Также по умолчанию включена система типов контента Django django.contrib.contenttypes, которая позволяет связывать разрешения(permissons) с создаваемыми вами моделями.

С этими настройками после выполнения команды python manage.py migrate в базе данных создаются необходимые таблицы для моделей связанных с аутентификацией и с разрешениями(permissions)

Таким образом , Django имеет встроенную систему разрешений(permissions). Эта система позволяет назначать разрешения конкретным пользователям и группам пользователей.

Эту систему использует Django admin

Django по умолчанию для модели создает 4 разрешения. Давайте посмотрим это на примере и потом подробно обсудим все 4 разрешения предоставляемых для модели по умолчанию

Создадим в нашем проекте новое приложение(application)

В файле models.py создадим модель Post

После выполнения миграции в базе данных создается таблица blog_post. Также в таблицу auth_permission добавляются четыре разрешения(permissions) ассоциированных с моделью Post.

Django для нашей модели Post после выполнения миграций создала четыре разрешения
- Разрешение add(в нашем случае add_post) позволяет пользователям добавлять экземпляры модели.
- Разрешение change(в нашем случае change_post) позволяет пользователям редактировать экземпляры модели
- Разрешение delete(в нашем случае delete_post) позволяет пользователям удалять экземпляры модели
- Разрешение view(в нашем случае view_post) позволяет пользователям просматривать экземпляры данной модели. Это разрешение появилось в Django 2.1
Имена разрешений следуют особому соглашению об именах: ._

В нашем случае для модели Post разрешения будут выглядеть следующим образом:

В админке Django , если мы зайдем под правами суперпользователя , то мы можем назначать эти права определенным пользователям.

Также мы можем создать группу . Этой группе добавить права(разрешения). И у всех пользователей , которые будут принадлежать этой группе будут соответствующие права.

К примеру , мы можем создать группу moderators и этой группе добавим все разрешения на добавления , редактирования , просмотра и удаления постов. И все пользователи , которых мы добавим группу moderators будут иметь возможность в админке добавлять , редактировать , просматривать и удалять посты.

Разрешения пользователям мы можем задавать не только в административной панели Django, но также программно. Мы можем управлять разрешениями следующими методами:

В приложении blog для модели Blog создадим вьюху для добавления поста. Добавлять пост может только пользователь у которого будет разрешение add_post

Здесь мы используем миксин PermissionRequiredMixin , потому что мы используем CreateView для создания нового объекта модели поста. У миксина PermissionRequiredMixin в поле permission_required мы задаем разрещение : blog.add_post.Если пользователь аутентифицирован , но при этом у него нет разрешения добавлять посты , то ему будет отказано в доступе к этой вьюхе и будет возвращен код 403(Доступ воспрещен). А если у него будет разрещение blog.add_post , то он сможет создать новый пост

Если бы мы использовали вьюху создания поста в функциональном стиле , то для разграничения доступа , мы могли использовать декоратор permission_required

Также мы можем проверять есть ли у данного пользователя определенное разрешение или нет , с помощью метода has_perm

Для неаутентифицированного пользователя AnonymousUser метод has_perm всегда будет возвращать false.

Заключение

В данной статье мы рассмотрели Django permissions , которые позволяют разграничивать доступ к объектам. Это очень мощная штука , которая позволяет нам легко ограничивать доступ к добавлению,редактированию, удалению объектов разных моделей.

Читайте также: