Доброго времени суток. Разбираюсь в проектировании и очень хочу услышать вашего мнения по следующему вопросу.
Предметная область простая - хранение данных по резульататм тестирования студентов. Вот диграмма классов.

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

Класс "Результат тестирования" получается частью двух классов, "Тест" и "Студент", без которых он не может существовать. Но в определени комозиции также говорится, что часть может принадлежать только одному композиту.
И мне ненравится миграция первичного ключа в таблицу "Результат тестирования" в результате идентифицируеший связи.

Alexey123
И мне ненравится миграция первичного ключа в таблицу "Результат тестирования" в результате идентифицируеший связи.
Имею в виду поле "Номер группы"

Первая - диаграмма классов, вторая ER-диаграмма

Сначала анализ предметной области, моделирование бизнесс процессов, вариантов использования, потом выявление классов и их связей - для ООП. Потом модель данных для реализции реляционной БД.

Т.е. вы считаете использование такой технологии бесмысленной? Я только начинаю понимать её суть, хоть базами данных (MS SQL и ORACLE) занимаюсь уже года 3. Стоит ли вообще продолжать, или её использование приводит только к проектированию ради проектирования?

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

Спасибо. Если-бы ещё кто-то немного помог ответом, было-бы совсем замечательно.

apapacyАлексей. Тест является просто некоторым измерением, координатой х по которой оценивается студент. Поэтому тест не агрегирует результаты теста. Но говоря это я имею в виду систему ориентированную на анализ успеваемости студента. Может быть другой (-ие) случай. Например, статистический анализ валидности теста. Тогда тест будет ведущей сущностью, а студент - мыслится по-другому - не могу сходу сказать как. Все идет от конкретики задачи.

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

Leshij
Как-то привычнее жить с суррогатными ключами, но раз ты взял
естественные...

К суррогатным я тоже привык, но они тоже мигрируют. :)

Leshij
Почему номер студенческого билета не может один, без номера группы, работать
первичным ключом?
[достает студенческий из куртки] Он ведь такой длинный :)

Может конечно, вопрос о идеологии проектирования. Если студент связан с группой композицией, то идентифицирующая связь и мигрирует ключ.

Leshij
Ну если все-таки не может, то все нормально -- составной ключ мигрирует в
ссылающуюся таблицу, и никакого нарушения тут нет, опять же, если
выполняется условие (см выше).

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

Leshij
Ну и по второй картинке: Имя VARCHAR(1)? Отчество SMALLINT??? Да и для
фамилии 50 символов мало. Мало ли какие фамилии бывают...

Уж простите за оплошности.

РуматаАлексей, а что ты хотел получить изначально? Т.е. нарисуй модельку с первичными и внешними ключами руками, а не то, что предлагает ERWIN(или какой программой пользовался?)

Ведь вроде по смыслу Студент и Тест должны быть связаны "многие-ко-многим" через промежуточную таблицу, которая помимо первичных ключей из этих двух таблиц, будет еще иметь оценку за тест(кстати, а попробуй именно эту связь указать в программе для проектирования, может все нормально и будет)

Это Rational Rose с использованием Data Modeler. Если не занимать проектированием по правилам то я бы эту задачу решил так, с использованием суррогатных ключей. В сущности "Результат тестирования" ключ "ИД Результата" необходим так как в один день, по одному тесту может протестировать один студент два раза.

Прошу прощения, вот диаграмма.