it-swarm.com.ru

Какой из них ER диаграмма

Я начал изучать диаграмму ER, когда я просматривал учебники по диаграмме ER, я нашел что-то вроде рисунка 1 и узнал

Рисунок 1 enter image description here

И затем я попытался создать пример ER-диаграммы в MySQL, я получил компоненты, как на диаграмме ниже

Фигура 2 enter image description here

Затем я просмотрел в Google изображения как ER-диаграмму, я получил оба типа изображений ... Я не знаю сходства и различия между обеими диаграммами ..

Можете ли вы помочь мне разобраться в деталях и двигаться дальше .... Спасибо. Заранее ...

3
Monicka Akilan

Затем я просмотрел изображения Google как ER Diagram и получил оба типа изображения ... Я не знаю сходства и различия между ними диаграммы ..

Можете ли вы помочь мне разобраться в деталях и двигаться дальше .... Заранее спасибо...

Разрабатывая базы данных, администратор базы данных (или кто-то еще) может использовать моделирование данных метод, известный как диаграмма отношений сущностей

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

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

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

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

Процесс декомпозиции следует строгим правилам, предложенным Питером Ченом. Это говорит о том, что вы не рисуете глупости. Вы делаете модель и должны следовать правилам, чтобы разбить ее, чтобы перейти к следующему этапу.

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

  • Еще до существования Концептуальной модели мы должны Описать проблему (потребности бизнес-правил) на бумаге (или Документе). Именно здесь вы создадите/запустите концептуальную модель Этот документ может даже стать новой фазой, предшествующей Концептуальной .__ модели, называемой Описательной моделью (это не официально Питер Чен) . Здесь у вас будет контекст всего.
  • Контекст должен быть дан только для того, что должно быть сохранено (в базе данных ). Нет необходимости описывать вещи, которые не сохраняются Ваша описательная модель не должна содержать ненужных Вещей.
  • Во время разработки Концептуальной модели очень важно, чтобы Вы полностью забыли, что такое таблицы и внешние ключи. Эти вещи Только замедляют вас на этом этапе разработки. Они должны быть замечены позже, на следующих этапах.

Я советую вам узнать больше о модели отношения сущностей (A.K.A. Диаграмма отношений сущностей) и изучить ее. На эту тему есть классные книги и много материала в Интернете. Поняв это, поверьте мне, разработка баз данных станет чем-то гораздо более простым и приятным.

Если у вас есть серьезные вопросы, пожалуйста, оставьте комментарий, и я отвечу. Присоединяйтесь к сообществу. Следуйте тегу сущности-отношения. Есть много интересных вопросов, которые могут помочь вам в учебе. Кроме того, продолжайте спрашивать, продолжайте участвовать. Мы здесь для обмена знаниями!

О, еще одна вещь. Существуют разные обозначения, используемые разными профессионалами. Например, некоторые люди представляют количество элементов в виде N ... 1, как другие N-1, другие как (N, 1). Эти характеристики не изменяют конечный результат.

Правка

Я благодарю, кто показал мне это .

3
Loa

Ваша первая диаграмма - это правильная диаграмма ER, использующая концепции и обозначения, разработанные Питером Ченом в его статье The Entity-Relationship Model - Toward a Unified View of Data. В этой записи обозначены как сущности (прямоугольники), так и отношения (ромбы). Троичные и высшие отношения легко представляются и видны в этих обозначениях.

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

3
reaanb

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

Вот пример ERD очень высокого уровня, который просто устанавливает связь между различными частями вашей системы:

 Sample ERD

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

Вторым артефактом является диаграмма database, которая обычно очень конкретна с точки зрения деталей.

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

0
tadman