Размышления о докуметировании структуры БД

← →
Kostafey © (2008-04-15 15:21) [0]

Одна из вдумчивых частей языка Java в том, что его разработчики не предполагали, что написание кода будет единственно важным действием — они также подумали о его документации. Возможно, что наибольшая проблема с документированием кода - это поддержка этой документации. Если документация и код разделены, вы получаете трудности при изменении документации всякий раз, когда вы будете менять код. Решение выглядит легким: свяжите код с документацией.

Так вот существует ли реализация подобной идеи для проектирования структуры БД,
т.е. объединение собственно структуры (или вернее физической модели) и документации
по ней?

← →
Ega23 © (2008-04-15 15:23) [1]

Sybase Power Designer - лучше средства пока не видел.

← →
Kostafey © (2008-04-15 15:27) [2]

Пробовал.
Минус в том, что при построении диаграммы
стрелки рисует абстрактно между таблицами,
а требуется чтобы стрелки шли именно от/к
полям связи.

← →
Ega23 © (2008-04-15 15:38) [3]

> а требуется чтобы стрелки шли именно от/к полям связи.

Вот там возможностей по изменению интерфейса - хоть ж...й жуй, я до сих пор во всех не разобрался. Можно вырисовывать и от поля к полю, раньше так и делал.
Только скажу тебе честно: при размерах модели начиная от 50 таблиц у тебя, как правило, этих связей раза в 2-3 больше. И сам уже плюёшь на то, к какому визуально полю констрэйнт подходит. Лишь бы был. :)

Тем более, что всегда зависимости посмотреть можно...

← →
Kostafey © (2008-04-15 15:42) [4]

> [3] Ega23 © (15.04.08 15:38)

Гм. Значит не распробовал.
Ссылочек на литератеру не ней под рукой не найдется?

← →
Ega23 © (2008-04-15 15:46) [5]

> Ссылочек на литератеру не ней под рукой не найдется?

Признаться, я кроме хелпа другой литературы и не видел... :)

← →
Kostafey © (2008-04-15 15:50) [6]

Понял, будем копасться-сс потихоньку. :)

← →
Kostafey © (2008-04-15 21:48) [7]

Кстати, довольно полезная задумка ApexSQL Doc.
Весма близко к искомому решению.

← →
Игорь Шевченко © (2008-04-15 21:51) [8]

А если не секрет, что имеется в виду под документированием физической модели базы данных ?
Что от такой документации требуется и зачем ?

← →
Kostafey © (2008-04-15 22:03) [9]

> [8] Игорь Шевченко © (15.04.08 21:51)

Ну я себе это представляю примерно так.

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

Собственно я так и делал. В Word. Диграммки тупо принтскрином
из SQL Server Management Studio вынимал. Таблицы и поля ниже описывал.

Но чертовски это начинает бесить когда БД по 5 раз на дню перестраивается
и нужно иметь в 2-3-х местах актуальную структуру БД и еще документацию
по ней.

← →
Simpson © (2008-04-15 22:06) [10]

Пример JavaDoc /*по памяти*/

/**
* void foo();
* функция ничего не делает добавлена для обьема
*/

void foo(){

}

-- куда тут коменты ставить и как их выстраивать при сложных связях?
create table foo(
id integer not null auto_increment,
foo integer not null,
primary key(id)
);

← →
Kostafey © (2008-04-15 22:06) [11]

> Что от такой документации требуется и зачем ?

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

← →
Simpson © (2008-04-15 22:08) [12]

Kostafey © (15.04.08 22:03) [9]
Твой случай скорее в сторону кубов и датамайнинг развивать надо, а вообще кто нибудь анализом предметной области занимался?

← →
Kostafey © (2008-04-15 22:12) [13]

> [10] Simpson © (15.04.08 22:06)

При чем тут javadoc. В Вопросе я хотел лишь
провести некую параллель.

> [12] Simpson © (15.04.08 22:08)

При чем тут "датамайнинг".
Данные будут поступать позже.
Предметная область также известна.

← →
Игорь Шевченко © (2008-04-15 22:14) [14]

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

Может, лучше по старинке, в Ворде документировать предметную область, а на документацию базы данных плюнуть с высокой колокольни ? :)

← →
Kostafey © (2008-04-15 22:21) [15]

> [14] Игорь Шевченко © (15.04.08 22:14)

> И изменения в реализации всегда являются вторичными по отношению
> к документации модели

Как мы еще далеки от этого...

> Может, лучше по старинке, в Ворде документировать предметную
> область,

Предметная область существует только в голове 2-х человек -
разработчика и адимна.

> а на документацию базы данных плюнуть с высокой колокольни
> ? :)

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

← →
Игорь Шевченко © (2008-04-15 22:35) [16]

Kostafey © (15.04.08 22:21) [15]

> Предметная область существует только в голове 2-х человек
> -
> разработчика и адимна.

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

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

Если нашлось менее трех отличий - вам случайно повезло.

← →
Kostafey © (2008-04-15 22:48) [17]

> [16] Игорь Шевченко © (15.04.08 22:35)

Я вот про что подумал.

Во-первых что считать различиями?
Различия в сущностях - их... ну <<почти>> нет.
Различия в атрибутах - есть, НО
оно и логично, то что они есть система развивается,
появляются новые идеи, всплывают упущенные ранее моменты.
Так что это неизбежно приводит к тому, что с течением
времени состав атрибутов (а возможно и сущностей) будет
видоизменяться.

Конечно, мне бы хотелось чтобы структура БД
была досканально обсуждена, зафиксирована и
впредь воспринималась как Священная корова,
которая не может быть изменена.

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

← →
Simpson © (2008-04-15 22:53) [18]

Kostafey © (15.04.08 22:48) [17]
Писать прогу не имея четкого понимания "что пишем?" удовольствие ниже среднего беги от туда, или читай "Путь камикадзе".

>>Вместо жесткой структуры лучше придумать как быстрее всего
>>подстраивать документацию под постоянно изменяющуюся структуру
читай "Путь камикадзе" долго выжить там ты не сможеш

← →
Kostafey © (2008-04-15 22:57) [19]

> [18] Simpson © (15.04.08 22:53)

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

> долго выжить там ты не сможеш

До сих пор выживал.:)

← →
Игорь Шевченко © (2008-04-15 23:13) [20]

Kostafey © (15.04.08 22:48) [17]

> Конечно, мне бы хотелось чтобы структура БД
> была досканально обсуждена, зафиксирована и
> впредь воспринималась как Священная корова,
> которая не может быть изменена.

Это невозможно, в большинстве случаев. Но структура базы вряд ли изменяется сама по себе, от того, что загнившие биты заменяются свежими, верно ? Наверняка или "а вот это мы упустили", "а вот это мы не так поняли", "а вот это нас не так поняли", "с завтрашнего дня вводятся новые, слегка изменнные правила игры".

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

← →
Kostafey © (2008-04-15 23:22) [21]

> [20] Игорь Шевченко © (15.04.08 23:13)

Вот теперь вас понял.

> А какой смысл документировать отражение - я не совсем понимаю.

На то тоже есть по меньшей мере 3 причины:
1. Удобство программитрования
2. Удобство построения отчетов
3. Требования заказчика по предоставлению такой документации.

← →
Kostafey © (2008-04-16 00:38) [22]

> [3] Ega23 © (15.04.08 15:38)

> Вот там возможностей по изменению интерфейса - хоть ж...й
> жуй,

Это-то верно, но вот

> Можно вырисовывать и от поля к полю, раньше так и делал

хоть убей - не нашел.

Не подскажете как это сделать?

← →
XentaAbsenta (2008-04-16 12:56) [23]

Kostafey © (15.04.08 23:22) [21]
+1

← →
Павел Калугин © (2008-04-16 14:24) [24]

> Kostafey © (16.04.08 00:38) [22]

в настройках отображения связи указать галочку что писать и буде у тебя на стрелочке надпись поле - поле

← →
Mystic © (2008-04-16 15:39) [25]

> В программировании, например, есть неплохое решение - javadoc.
> ..

Честно говоря, в программировании с точки зрения документирования мне больше нравится предложенная Д. Кнутом концепция литературного программирования. Но аналогов для БД я не знаю.

← →
Anatoly Podgoretsky © (2008-04-16 16:34) [26]

> Mystic (16.04.2008 15:39:25) [25]

Это как? Базуля дашь? Дам.

← →
Kostafey © (2008-04-16 17:10) [27]

> Павел Калугин © (16.04.08 14:24) [24]
>
> > Kostafey © (16.04.08 00:38) [22]
>
> в настройках отображения связи указать галочку что писать
> и буде у тебя на стрелочке надпись поле - поле

Так то надпись, нужно чтобы сама стрелокча
от поля к полю (имеются в виду поля связи) шла.

← →
Mystic © (2008-04-16 19:42) [28]

> Anatoly Podgoretsky © (16.04.08 16:34) [26]

Например так:

@* Hi, people! @ Я тут решил накалякать базу банных для шахматного сервера. Должно получиться прикольно @!@^приколы@>. @ Итак, как и любая баз данных, наша база будет состоять из таблиц, хранимых процедур, связей. База данных не очень сложная, потому вьюх в ней не планируется. Хоть в этом пункте я ничего генитального не придумал, но все же эту схему необходимо оформить как полагается: @p @<Таблицы@> @<Связи@> @<Хранимые процедуры@> @ Подумаем о наших основных используемых сущностях. Их, в минимальном случае, две. Это игроки @^игрок@> и партии @^партия@>. Конечно, в будущем возможен вариант, когда появятся турниры и прочая байда, но на данном этапе я таких сверхсложных неоржинарных задач не рассматриваю. Пока все просто: игроки и партии. Партии и игроки. Это решение изображено на рис.~\ref{PlayersAndGames}. \begin{figure} \includegraphis{chessplayers.png} \label{PlayersAndGames} Рис.~\ref{PlayersAndGames}. Игроки за шахматной доской. \end{figure} @<Таблицы@> += @<Таблица игроков@> @<Таблица партий@> @* Игрок. @!@^Игрок@> @!@^Players@> Тут нет ничего военного, игрок это пользователи нашей системы. Легко перечислить список полей, которыми он обладает. Логично, что это в первую очередь |ID|. А во вторую это ник (|Nickname|), пароля (|Password|), ну и всякая другая справочная информация, которую мы добавим как-нить по настроению. Да, забыл отметить, что пароля хранится в закэшированом виде (MD5). Поэтому для его хранения выделено строго 32 символа. @<Таблица игроков@> += CREATE TABLE |Players| ( |ID| INT AUTO_INCREMENT PRIMARY KEY, |Nickname| VARCHAR(20), |Password| CHAR(32) ) @<Другие вспомогательные поля в таблице игроков@> @<Ограничения и проверки@> @ А дальше мне писать в лом.

Блин. Всю сеть перерыл. Нигде не сказано
как в Power Designer сделать так чтобы связи
между соответствующими полями рисовались.
ERWin - тоже самое автоматом свзи абстрактно
между таблицами строит.

DB Visualizer - делает построение такого рода схем,
но либо толькой для 1 таблицы и всех с ней всязанных,
либо для всех.

← →
ferr (2008-04-16 22:20) [30]

в эрвине есть два режима, физикал и логикал, вам нужен физикал. При создание связи в одну из таблиц добавляется поле..

> [30] ferr (16.04.08 22:20)
> в эрвине есть два режима, физикал и логикал, вам нужен физикал.
> При создание связи в одну из таблиц добавляется поле..

Речь о том как из имеющихся таблиц построить наглядную
диаграмму

← →
ferr (2008-04-16 22:44) [32]

Извините, недовъехал..
Т.е. Вы пользуетесь реверсом базы? Что-то кажется если она сгенерирована ервином то она нормально извлечёться..

> [32] ferr (16.04.08 22:44)
> Извините, недовъехал..
> Т.е. Вы пользуетесь реверсом базы? Что-то кажется если она
> сгенерирована ервином то она нормально извлечёться..

Не вопрос, нормально, но нужно чтобы
линии связей между таблицами рисовались
четко от одного поля связи к другому.
А этого автоматического построения я нигде
не нашел (частично лишь в DB Visualizer)

MS Visio for Enterprise Achitects 2003, ну или 2005

Проектируем БД прямо в ней, SP пишем тут же, после чего генерируем, или апдейтим базу непосредственно оттуда же. Все пояснения и комментарии делаем прямо на диаграмме связей.
Основные моменты, такие как порядок оплаты или отношения брокеров с делом выносятся на отдельные листы в том же документе.
К документу (vsd) прилагается пояснительная записка, вместе с тем содержащая уже реализованные фичи, и запланированные. Ко всему этому прилагается xls (MS Excel) файл содержащий листы для каждого разработчика со списком фич в колонке "A", в колонке "B" - предполагаемое время, в колонке "С" - время реализации.
Практика показывает что решение с экселевским файлом недостаточное, т.е. напр.: при реализации поиска были описаны классы, к конкретной фиче не относящиеся напр. CFilter и CFilterList, и их добавлять как бы некуда, а изначально они были незапланированы..

> Kostafey © (20.04.08 13:53) [35]

Нафиг оно нужно, объясни???
Была бы возможность - вообще бы с диаграммы все связи убрал, и без них места мало...

> [36] Ega23 © (20.04.08 13:55)

А по-моему так так действительно понятнее,
да и вообще какой смысл в диаграмме в которой
нет связей?

> А по-моему так так действительно понятнее,
> да и вообще какой смысл в диаграмме в которой
> нет связей?

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

> Mystic (21.04.2008 11:48:38) [38]

Встречался, матюгался и это не про соглашение/ограничение, а именно за то что не все связи указаны.

Вот что. Нормальное описание БД должно включать ИМХО следующее:
- Диаграммы (желательно 2-х типов: краткие и максимально детализированные).
- Таблицы и их поля с подробным описанием этих таблиц и полей.
При этом хорошо бы чтобы это описание хранилось не отдельно от БД
а прямо в ней (свойство Description поля), а докумен с описанием
гененился бы исходя из этого. В Sybase Power Designer есть
такя штука отчеты. Правда почему-то именно свойство Description
полей они не обрабатывают (или просто недоразобрался)
- Собственно прочие соглашения (триггеры, хранимые процедуры и т.п.)

Размышления о докуметировании структуры БД Найти похожие ветки