Форум Сообщества Аналитиков

×


Последние сообщения

Страницы: 1 2 3 4 5 6 7 8 9 10
1
Вопрос что нужно от инструмента? Автогенерация кода, прямой и обратный инжиниринг.
Нет, ничего этого не нужно.
Нужны только максимальная наглядность схемы и максимальное удобство "рисования" схемы.

В конце концов у каждой СУБД есть средства представления схемы БД.
СУБД нету никакой. Пока нужно создать логическую схему БД.
Логическая схема не привязана к физической структуре и к конкретной СУБД.

Нотаций моделирования есть множество. Но под реляционные БД наиболее заточена IDEF1x. Исходя из этого, нужно просто подбирать инструмент, который полно реализует эту нотацию.
Да, наверно вы правы.
Тогда вопрос так и переформулируем: какой инструмент удобен для создания схем IDEF1X?

...Среди таких мне нравится Erwin. Но есть и другие аналоги, В том числе и Visiual Pradigm и другие.
Спасибо, попробую поискать триальные версии этих продуктов и посмотреть.
Но насчет Erwin... Читал не очень хорошие отзывы про последние версии Erwin.
2
Нотаций моделирования есть множество. Но под реляционные БД наиболее заточена IDEF1x. Исходя из этого, нужно просто подбирать инструмент, который полно реализует эту нотацию. Среди таких мне нравится Erwin. Но есть и другие аналоги, В том числе и Visiual Pradigm и другие. Вопрос что нужно от инструмента? Автогенерация кода, прямой и обратный инжиниринг. В конце концов у каждой СУБД есть средства представления схемы БД.
3
"Приключения в ресторане" продолжаются.
Некто поместил в википедию свою версию диаграммы ВИ ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия со сплошными экстендами.  Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.
4
А я имел ввиду, что у самой связи (то есть у линии, связывающей две сущности) нету информации о ключах (столбцах), по которым осуществляется эта связь.
Ну в общем, как-то мне не очень эта идея.
После уточнения прояснилось, в чём именно видится дефект. Чтобы отразить эти сведения, можно допилить профиль и переложить эти tagged values в стереотипы для связей.

В копилку "не очень идей": рисовать в Visual Paradigm и моделировать категоризацию тем способом, который предложен разрабами VP. Красивые картинки a la IDEF1X получать экспортируя диаграммы в "рисовалки" вроде Visio, где явно пририсовывать категоризацию. Не думаю, что стоит так мучиться, но ничего другого не могу предложить.
5
У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).

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

Что-то еще можете порекомендовать?
6
Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.
[в продолжение трындежа]
У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).
7
Нашел программу Aqua Data Studio.
Вроде бы все в ней есть, судя по описанию. Но работает как-то криво.


8
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.

Интересное решение. Но я вижу в нем еще один минус.
Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.
9
[Вероятно, имеются в виду реляционные БД.]

Да, конечно.

Можно ставить в вершину угла выразительные возможности нотации

Именно это для меня важнее. По крайней мере пока.

10
[Вероятно, имеются в виду реляционные БД.]
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.
Страницы: 1 2 3 4 5 6 7 8 9 10