Copy
Как сделать ER-диаграмму и Django models
View this email in your browser

Снова в деле.

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

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

Концепт вашей базы данных

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

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

Каждая сущность содержит набор атрибутов (по крайне мере один атрибут). Для товаров атрибутами могут быть: название, категория, цена, фото, описание и так далее. Атрибуты сущности категорий могут ограничиваться одним: название категории, а могут двумя: название и родительская категория.

Связи - взаимодействия сущностей между собой. Обычно связь можно как-то охарактеризовать парой слов, содержащих глагол:
  • товары -> входят в -> категории,
  • корзины -> создаются -> пользователям,
  • скидки -> применены к -> заказам.
Вообще говоря, почти любую связь можно назвать "принадлежит", но схема с кучей таких одинаковых связей малоинформативна, поэтому разумнее выбирать слова наилучшим образом характеризующие связь между конкретной парой сущностей. Также можно обозначать связь двумя названиями: как первая сущность относится ко второй и как вторая относится к первой. В случае с иерархиями категорий, родительская связь обозначается линией к самой себе. Сущность на ER-диаграмме обычно показывает, как количества объектов сущностей соотносятся между собой. Это как раз те типы, о которых шла речь на первых лекциях по БД: один-к-одному, многие-ко-многим, один-ко-многим.

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

Существует две нотации для описания ER-диаграмм:
  • Воронья лапка (по обозначению части связи "-ко-многим").
  • нотация Питера Чена (человека, придумавшего ER-диаграммы), пример.
Первая кажется более понятной, но вы можете выбрать сами, какая вам по душе, так как ваши проекты предполагают относительно немного сущностей.

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

Как из ER-диаграммы получить модели для Django

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

Django ORM прост в обращении, поэтому можно миновать многие этапы нормализации, которые будут предложены на лекциях и лабах по базам данных. Для того, чтобы преобразовать вашу ER-диаграмму в модели для Django, достаточно сделать следующее:

Указать типы для атрибутов (выбирайте подходящие отсюда). При этом для атрибутов, которые ссылаются на сущности типом связи "один-ко-многим" (например, атрибут "категория" в сущности "товар"), указывайте тип внешний ключ (в Django это называется ForeignKey), для связей "многие-ко-многим" указывайте ManyToMany.

Создать миграции:
 python manage.py makemigrations
Эта команда создаст скрипты, которые создадут схему за вас, каждый раз когда вы что-либо будете менять в своих моделях, запускайте создание миграций и ни о чем не думайте. Не забудьте добавить созданные скрипты в репозиторий.

Применить миграции:
 python manage.py migrate
Эта команда выполняет созданные скрипты и создает или меняет схему базы данных в вашей СУБД. У команды есть несколько опций, которые позволяют применять разные миграции, переключаться между ними и устранять разные проблемы.

Вообще говоря, это всё. Некоторые из вас уже пробовали создавать модели и достаточно успешно. Вы не задумывались о таких темах, как нормализация базы данных и выбор идентификатора - это все Django ORM делает за вас. Не все вещи, которые делаются Django "из коробки" нужны именно в таком виде, в котором они поставляются, но доработку можно отложить на пару недель, когда все из вас (кто ходит на лекции по БД) станут лучше себе представлять, как выглядит физическая схема создаваемой базы данных.

Ближайшее, что нужно сделать, это всего лишь нарисовать ER-диаграмму, но двигайтесь дальше самостоятельно и увереннее, если у вас есть желание.
Вы доскроллили письмо до исландской лошади, поздравляю! Успехов с концептуальной схемой!
Sincerely yours,
Ivan Savin

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list
 






This email was sent to <<Email Address>>
why did I get this?    unsubscribe from this list    update subscription preferences
HSE Projects · ул. Мясницкая, дом 20 · Москва 101000 · Russia

Email Marketing Powered by MailChimp