Моделирование базы данных (ERD) со странным поведением

Question

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

Одним из вариантов поведения является наличие таблицы «бронирования» и таблицы «счета-фактуры». При выставлении счета за «бронирование» запись вносится в таблицу «счетов-фактур», а затем удаляется из таблицы «бронирования».

Однако ссылка на номер бронирования по-прежнему сохраняется.

Как мы смоделируем это? Большая стрелка между таблицами и текст рядом с ней, описывающий, что происходит?

Нет, изменение схемы базы данных в данный момент невозможно

Редактировать : Это тип диаграммы, которую я хочу использовать: альтернативный текст http://img813.imageshack.us/img813/5601/erdartistperformssong.png Link

Answer 1

Я не знаю, о чем говорят эти люди.

1. Диаграмма отношений сущностей не описывает данные полностью;да, конечно, он показывает только сущности и отношения, он не показывает атрибуты.Вот почему это называется ERD, а не модель данных.Очевидно, что многие люди здесь не могут заметить разницу.

2. Модель данных должна показывать как можно больше.Но это зависит от (а) стандарта [если таковой имеется), который вы используете, и (б) нотации.Некоторые показывают больше, чем другие.IDEF1X, который является единственным стандартом реляционного моделирования (NIST 184 от 1993 года).Он является наиболее полным и показывает сложности и сложности, которые другие обозначения не показывают.В последнее время MS и другие выступили с «упрощенными» обозначениями, конечно, многое теряется в «ERD».

3. Это не «поток процесса», это отношение вбаза данных.

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

5. Это совершенно законно;это, возможно, не общеизвестно, но это законно и названо.Это отношение Supertype-Subtype , за исключением того, что мощность равна 1 :: 0-n вместо 1 :: 0-1.Обозначение IDEF1X (справа) имеет символ подтипа.Обратите внимание, что есть только одно отношение в родительском конце;и по одному на дочернем конце.И конечно же гусиные лапки показывают кардинальность.Эти отношения могут быть Эксклюзивные или Неисключительные ;ваш эксклюзив;это то, что означает X через полукруг.

   • ERwin - единственный инструмент моделирования (не построения диаграмм), который реализует IDEF1X и, таким образом, имеет полное дополнение нотации IDEF1X.

   • Конечно, стандарт, возможности моделирования - все это в уме, а не в инструменте.Я рисую модели данных, совместимые с IDEF1X, используя простой инструмент рисования.

6. Я нахожу, что некоторые разработчики оплакивают символ подтипа, поэтому я показываю упрощенную версию (слева) в моих моделях IDEF1X;он предназначен для передачи чувства исключительности, в то время как сохранение единственной строки на родительском конце указывает на то, что это подтип.

Лот: Нажмите здесь ▶ Ссылка на модель данных ◀ Лот: Нажмите здесь

Ссылка на нотацию IDEF1X дляте, кто не знаком со стандартом реляционного моделирования.

Answer 2

Если под ERD вы имеете в виду исходные диаграммы «Чен», в которых отношения были словами, написанными ромбом, то у вас есть связь между бронированием и счетом.Это особый тип отношений, который НЕ реализуется с простым внешним ключом;это реализовано посредством сложного движения и ограничения.

Если под ERD вы подразумеваете диаграммы, которые рисует ERwin, то у вас нет простого способа сделать это.Это имеет тенденцию фокусировать вас на рисовании отношений PK-FK.У вас есть отношения не PK-FK между этими вещами.Некоторая строка с текстом - это все, что вы можете сделать.

Стрелки, кстати, не подходят, потому что ERD показывает «состояние» базы данных.Передача данных не является частью ERD.У вас есть отношения, это просто не типичные отношения PK-FK.Это нетипичное отношение, основанное на строках, существующих в одних местах и ​​не существующих в других.

В UML вы можете легко нарисовать это как «ограничение» среди отношений.

Answer 3

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

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

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