Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
А менеджеры проектов, это порой люди,вообще далекие от ИТ. К тому же они не уважаемы теми же программистами, и платят им меньше чем хорошему программисту...И вообще они так же вредны как и аналитики
Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently
from instances participating in links at the other ends of the association. The precise mechanism by which such access is
achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible,
and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating
associations from non-navigable ends.
Эд, если знаешь точный ответ, то поясни плиз.
Хорошо, только мыл на который кидать смайлы брось в лс.Сбросил. Здесь пишу еще раз bas_4all attttt inbox dottt ru
Необходимо зафиксировать на какие задания он отвечал, и если неверно ответил, то какие варианты ответов он выбрал. Подскажите как лучше это отобразить.В том то и дело, что лучше отоброзить - какие ответы Студен выбрал во время прохождения теста. Т.е. лучше направленная ассоциация от Результата тестирования к Варианту Ответа
The arrowhead on the other end (near Point) of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. In UML relationships are presumed to be bidirectional unless the arrowhead is present to restrict them. Had I omitted the arrowhead, it would have meant that Point knew about Circle. At the code level, this would imply a #include “circle.h” within point.h. For this reason, I tend to use a lot of arrowheads.
«Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.»А так же там написано:
А как же наличие связи многие-ко-многим в логической модели? Это же не нормальная форма. В ERWin также на логическом уровне разрешены субкатегории. И то и другое пропадает на физическом уровне.
На практике часто рассматривают только две модели - логическую и физическую модели данных. При этом информационная и логическая модели данных не различаются и считаются синонимами. В рамках такого подхода некоторые специалисты в области баз данных считают, что информационная модель данных должна быть нормализована. Это означает, что проектировщики баз данных должны требовать от аналитиков, чтобы они приводили информационную модель данных к третьей нормальной форме! Такой подход имеет ряд недостатков. Во-первых, аналитики, являясь экспертами в предметной области, как правило, не представляют, что такое нормализация данных. Во-вторых, информационная модель данных должна быть независимой от физической модели данных, в рамках которой она будет реализовываться. Для реализации информационной модели данных может быть выбрана не реляционная, а, например, сетевая (СУБД ADABAS) или многомерная (СУБД Teradata) модели данных, тогда нормализация отношений модели не столь актуальна. В-третьих, проектировщики базы данны х должны иметь логическое представление данных, посредством которого, с одной стороны, общаться с аналитиками и пользователями в понятных для них терминах, и, с другой стороны, превращать полученные логические отношения в физические объекты базы данных.Здесь есть ответы на два ваших вопроса:
Получается логическая модель будет такой?НЕТ. Я же вроде не двусмысленно сказал, что к предпоследней модели "надо еще добавить слова к связям и их направленность".
