Как задокументировать эффективное датированное соединение

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

Примером соединения может быть:

Table_A
Key_ID - Primary Key
Employee_ID
Position_ID
Effective_DT
Unique Key -> Employee_ID, Position_ID, Effective_DT

Table_B
Employee_ID
Position_ID
Effective_DT
Table_A_Key_ID
Unique Key -> Employee_ID, Position_ID, Effective_DT

Table_A_Key_ID является внешним ключом из Table_A и не может быть нулевым. Другими словами, каждая запись в Table_B требует соответствующей записи в Table_A, но обратное неверно. Чтобы определить запись в Table_B, которая относится к записи в Table_A, у которой нет соответствующей записи, вам нужно получить запись с самой высокой эффективной датой меньше, чем Table_A.Effective_DT.


database join database-design oracle11g
person tp9    schedule 10.05.2012    source источник
comment
Инструменты диаграмм документируют не соединения, а таблицы (сущности) и отношения между ними. Для вашего примера просто создайте представление — это инкапсулирует ваше соединение в объект БД. Алос взгляните на stackoverflow.com/questions/10521401/   -  person Damir Sudarevic    schedule 10.05.2012
comment
Спасибо за исправление. Уточню мою основную цель с документацией — ускорить мой переход от одной части системы к другой. Например, я могу работать с таблицами сотрудников в течение нескольких месяцев и вдруг получить запрос на квалификационную часть базы данных, настроенную совсем по-другому. До сих пор мне требовалось как минимум полдня или около того, чтобы просто переключать передачи в зависимости от того, насколько хорошо были написаны спецификации. Как вы документируете свои присоединения? Кстати, как вы создали эту диаграмму для плана выполнения в другом посте?   -  person tp9    schedule 10.05.2012
comment
Диаграммы представляют собой ERD, диаграммы отношений сущностей, как я упоминаю ниже. Они сделаны с использованием инструментов, как я упомянул ниже. Эти инструменты также позволяют вам документировать, как таблицы соединяются (то есть отношения между таблицами). Они показывают кардинальность и то, какие таблицы являются родительскими, а какие имеют внешние ключи и т. д. Другие диаграммы выглядят так, как некоторые базы данных предоставляют, когда они показывают «планы объяснения». Итак, если под объединением документов вы понимаете, как связаны таблицы, инструменты для диаграмм ERD, которые он использовал для создания диаграмм, - это то, что вы ищете.   -  person Bill Rosmus    schedule 11.05.2012
comment
@BillR Спасибо за разъяснение. У меня есть бесплатная версия Toad, так что я посмотрю.   -  person tp9    schedule 11.05.2012
comment
@BillR На основе документа, который я просмотрел о Toad, диаграммы ER, которые он создает, основаны на ограничениях внешнего ключа в базе данных. Соединение, о котором я упоминал в своем OP, не основано на формальном ограничении таблицы. При использовании Toad мне придется вручную вводить информацию в поле комментариев таблицы?   -  person tp9    schedule 11.05.2012
comment
@tp9; Графический интерфейс БД делает это. Гугл oracle graphical explain plan.   -  person Damir Sudarevic    schedule 11.05.2012
comment
@ tp9 Да, почти любой инструмент моделирования баз данных, который вы найдете, требует какой-то информации, чтобы рассказать вам, как вещи соединяются вместе. Это если перепроектировать. Я знаю, что это отнимает много времени, но если вы ищете что-то только для собственной справки, вы можете вручную ввести таблицы и отношения и найти способ (возможно, именование), чтобы отметить, существует ли реальное ограничение или это просто для документации, поэтому вы можете посмотреть на это. Этим инструментам также можно указать не включать ограничения внешнего ключа, если вы используете их для создания сценариев DDL. то есть вы документируете их, но не включаете их.   -  person Bill Rosmus    schedule 11.05.2012
comment
Инструменты моделирования всегда хороши, поэтому люди, которые приходят и уходят из команды, могут быстро изучить схему. Кроме того, это помогает понять, проектируете ли вы что-то. Также хорошо, если у вас есть огромная схема и вам не обязательно часто просматривать ее и забывать об отношениях. Планы графического объяснения хороши, если вы пытаетесь выяснить, как база данных выполняет соединение, и это сильно отличается от документирования отношений между таблицами, что, я думаю, вы ищете. С Уважением.   -  person Bill Rosmus    schedule 11.05.2012
comment
Спасибо за все хорошие советы. Да, я пытаюсь реконструировать большую схему HR, которая не была хорошо задокументирована, и команда, в которой я работаю, теперь отвечает за ее поддержку.   -  person tp9    schedule 22.05.2012

Ответы (2)


arrow_upward
0
arrow_downward

инструмент моделирования ER будет документировать ссылочную целостность, но сам по себе не поможет вам документировать все JOIN, которые вы делаете в своем клиентском коде (не все они могут «лежать» поверх FK).

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

person Branko Dimitrijevic    schedule 11.05.2012

arrow_upward
0
arrow_downward

  • жаба модельер данных
  • erWin
  • Эмбаркадеро

Если вы работаете на предприятии, и они готовы раскошелиться на некоторые настоящие инструменты. В противном случае используйте комбинацию Visio для диаграммы ER и MS Word для словаря данных. И во всех случаях здоровое количество жира локтя.

Картинки стоят тысячи слов... но вам нужно научиться рисовать правильные картинки.

person Bill Rosmus    schedule 10.05.2012