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

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

Alexey123Никто не строит из объектной модели модель данных?

Строят... Просто в данном случае, может проблема в инструменте?

Что требуется? Как я понимаю, схема дана вот здесь :

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


1. Анализ предметной области.

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

2. Бизнес-процесс: прохождение теста. Описан чуть выше.

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

4. Из анализа предметной области вытекают следующие классы : студент, группа, тест, контейнер пройденных тестов. Связи - очевидны

5. Модель данных для РБД : 4 таблицы.

Да, есть специальные инструменты для выполнения всего этого разом... Но можно ведь и по отдельности сделать... И каждый пункт хоть в Ворде описывать и строить...

Alexey123Спасибо большое Румата за подробный ответ. Именно вот такой путь я пытаюсь пройти и разобраться.
Полностью с Вами согласен. Я использовал Rational Rose только как средство рисования диаграмм, можно было и на листочке ручкой рисовать, суть не в инструменте. Просто изучаю проектирование естественно по литературе, а в ней описываются различные правила, которым нужно следовать, на подобии представлении композиции в идентифицирующую связь. В результате я получил структуру БД, которая мне как программисту не нравится. Получается либо я что-то неправильно проектировал, либо следовать строго этим правилам не стоит? Отклонятся от них, если это позволит сделать систему лучше?

Понимаешь, Алексей(можно на "ты" ? Мы вроде по возрасту не сильно отличаемся ), стоит следовать правилам и стоит читать литературу... Но стоит фильтровать то, что тебе говорят, четко осознавать то, что пишут...

Я так сходу даже не скажу, что такое "представление композиции в идентифицирующую связь", хотя все это тривиально...

Ты читал Дейта? Его книга изобилует такими понятиями, как, например, кортеж... Но более ведь употребимо что-то вроде выборки, строки... Хочешь - оперируешь одним понятием, хочешь - другим. Главное, заранее договориться, чем оперировать.

Да, в какой-то момент следует отклоняться от правил, если что-то не нравится. Если ты понимаешь, что не все так гладко, как описано в книге. Нельзя быть обыкновенным кодером, наша задача быть _думающими_ программистами.

PS. Мы не имеем права не прислушиваться к Дейту, но иногда мы имеем право заменить "кортеж" на что-то свое...

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

Дейт - классика жанра :) Посмотри, обязательно!

Да, и расскажи потом ,чем эпопея с дипломом закончится :)