По моему, концептуальная схема = логическая модель

В статье http://www.intuit.ru/department/database/rdbdev/6/ о логической модели данных, которую Вы мне дали, написано:
«Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.»
А как же наличие связи многие-ко-многим в логической модели? Это же не нормальная форма. В ERWin также на логическом уровне разрешены субкатегории. И то и другое пропадает на физическом уровне.

P.S. спасибо большое всем за развернутые ответы. 

Получается логическая модель будет такой?

«Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.»
А как же наличие связи многие-ко-многим в логической модели? Это же не нормальная форма. В ERWin также на логическом уровне разрешены субкатегории. И то и другое пропадает на физическом уровне.

А так же там написано:

На практике часто рассматривают только две модели - логическую и физическую модели данных. При этом информационная и логическая модели данных не различаются и считаются синонимами. В рамках такого подхода некоторые специалисты в области баз данных считают, что информационная модель данных должна быть нормализована. Это означает, что проектировщики баз данных должны требовать от аналитиков, чтобы они приводили информационную модель данных к третьей нормальной форме! Такой подход имеет ряд недостатков. Во-первых, аналитики, являясь экспертами в предметной области, как правило, не представляют, что такое нормализация данных. Во-вторых, информационная модель данных должна быть независимой от физической модели данных, в рамках которой она будет реализовываться. Для реализации информационной модели данных может быть выбрана не реляционная, а, например, сетевая (СУБД ADABAS) или многомерная (СУБД Teradata) модели данных, тогда нормализация отношений модели не столь актуальна. В-третьих, проектировщики базы данны х должны иметь логическое представление данных, посредством которого, с одной стороны, общаться с аналитиками и пользователями в понятных для них терминах, и, с другой стороны, превращать полученные логические отношения в физические объекты базы данных.

Здесь есть ответы на два ваших вопроса:
1. Концептуальная модель (информационная модель) = логическая модель
2. Нормализацию не рекомендуют делать на лог уровне, с чем я согласен

Получается логическая модель будет такой?

НЕТ. Я же вроде не двусмысленно сказал, что к предпоследней модели "надо еще добавить слова к связям и их направленность".
Последняя Д у вас получилась больше похожая на физ представление.

Спасибо, вроде разобрался.

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

Результат тестирования должен фиксировать Вариант Ответа, а НЕ Тестовое Задание.

А теперь добьем композицию и агрегацию:
На вашем примере Тестовое задание состоит из Вариантов ответов, и это правильно, и это композиция, т.е. "состоит из" - это композиция.
А Группа, НЕ "состоит из", она включает в себя Студентов, и это агрегация, Т.е. Студет "учится" в Группе, так будет правильнее
Т.е. если Вы будете руководствоваться этими правилами, то сразу отличите агрегацию от композиции. Еще раз:
* агрегация - это когда Части "включаются/собираются" в Целое, и Части могут существовать без Целого.
* композиция - это когда Целое "состоит из" частей, и Части НЕ могут существовать без Целого.

З.Ы. Получился прям мини ФАК по ДК

Результат тестирования должен фиксировать Вариант Ответа, а НЕ Тестовое Задание.

Связью «фиксирует» я хотел отразить то, что студент может ответить не на все вопросы теста. Необходимо зафиксировать на какие задания он отвечал, и если неверно ответил, то какие варианты ответов он выбрал. Подскажите как лучше это отобразить.

А теперь добьем композицию и агрегацию:
На вашем примере Тестовое задание состоит из Вариантов ответов, и это правильно, и это композиция, т.е. "состоит из" - это композиция.
А Группа, НЕ "состоит из", она включает в себя Студентов, и это агрегация, Т.е. Студет "учится" в Группе, так будет правильнее
Т.е. если Вы будете руководствоваться этими правилами, то сразу отличите агрегацию от композиции. Еще раз:
* агрегация - это когда Части "включаются/собираются" в Целое, и Части могут существовать без Целого.
* композиция - это когда Целое "состоит из" частей, и Части НЕ могут существовать без Целого.

  Спасибо, обязательно запомню.

З.Ы. Получился прям мини ФАК по ДК

Это отлично, другим начинающим тоже будет хороший пример. А то в книжках не расписывают, почему именно так, а не по-другому.
Вот закончу с логическим уровнем, потом физический нарисую с применением суррогатных ключей.

Необходимо зафиксировать на какие задания он отвечал, и если неверно ответил, то какие варианты ответов он выбрал. Подскажите как лучше это отобразить.

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

З.Ы. Сам немного забыл про навигацию, поэтому нашел достаточно хорошее описание, когда и куда надо применять стрелки. Там разбирается пример композиции Circle -> Point:

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.

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.

Если я пишу базу данных, то в отношении студент группа первичный ключ сущности «Группа» заносится атрибутом в сущность «Студент», но не наоборот. Это понятно, стрелка от студента к группе. Но если взять приложение (диаграмму классов приложения), то у класса «Группа» вполне логично запросить список всех её студентов, также как у класса «Студент» запросить его группу. Здесь не очень понятно.
Ещё непонятно направление стрелки при класс-ассоциации «Проходит»

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

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

Для того, чтобы понять направление  стрелки, т.е. навигация, полезно построить OCL выражения.

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

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

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

Ребята, мне кажется все-таки надо все начать сначала. А сначала - это значит понять что за систему мы делаем, для чего, каково ее предназначение.

Если отталкиваться от первых моделей, то я мог бы представить такую постановку. На кафедре информатики все студенты, обучающиеся информатики, для получения зачета должны пройти некий набор тестов. При этом каждый студент обращается к лаборанту, получает очередной тест, проходит его и сдает лаборанту. Лаборант передает тесты преподавателю, преподаватель проверяет и отдает их лаборанту. Лаборант вводит результаты прохождения теста в систему.

Преподавателям кафедры показалась такая ситуация не очень эффективна, напрягает лаборантов, преподавателей да и студентов. Решено сделать автоматическую систему сдачи тестов, т.е. студент регистрируется в системе и в удобное для себя время проходит тесты. Система следит, чтобы студент не мог сдать очередной тест пока не сдал предыдущий. Студент разрешается пересдать тест (дается не более 3 попыток).

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

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

Важно или не важно хранить историю ответов на вопросы. Если оценка определяется на основании сравнения ответа на вопрос с контрольным ответом, то ясно что нужно хранить не оценку, а именно ответ на вопрос теста, тогда оценка будет вычисляться.

Система тестирования может охватывать не одну дисциплину, а целый набор дисциплин с разными авторами тестов, с разным набором тестов для разных групп. Все это важно для будущего приложения и модели данных

Потому предлагаю сначала описать эту предметную область как можно более точно и полно.

Если описать предметную область полно то получится достаточно большой размах, и никто из посетителей форума не захочет даже читать это описание. Я же вижу целью изучение проектирования, а не решение какой-то задачи. Для начала проще понять что 2*2=4 чем вычислять интегралы. Поэтому наоборот пытаюсь сузить предметную область до минимума, главное на примере уловить все особенности.

Попытаюсь сейчас описать этот минимум:
Задача системы - хранение данных о студентах, тестах, и том как студенты проходили эти тесты. Только хранение и просмотр, ни о каком процессе тестирования, назначения студенту теста для прохождения речи пока не идёт.

Значит данные о студентах: номер студенческого (уникален), Фамилия, Имя, Отчество. Студенты объединяются в группы, которые имеют свой уникальный номер, и номер курса на котором обучается группа.

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

 После тестирования студента по определённому тесту фиксируется результат в виде оценки и даты проведения тестирования. Также данные о том, на какие тестовые задания ответил студент правильно или нет, и какие варианты ответа он выбрал, в случае неверности ответа. Студент может ответить не на все задания теста.
 
Поступление данных в систему прошу не рассматривать, оценка не высчитывается, она просто хранится. Вся задача хранить эффективно эти данные и просматривать:
1.   Просмотр списка групп, сведений о группе (номер, курс, кол-во студентов, список студентов в группе)
2.   Просмотр списка всех студентов (номер студ. ФИО, группа, курс)
3.   Просмотр результатов тестирования студента (тест, дата тестирования, оценка, список пройденных заданий, у неверных выбранные варианты ответов)
4.   Просмотр списка тестов (Наименование, сложность, кол-во заданий)
5.   Просмотр заданий теста (задание, список вариантов ответов)
Всё.

а кто фиксирует данные прохождения теста? как студент проходит тест? какие типы тестовых заданий бывают? одновариантный, многовариантный, точный ответ, сопоставление и т.п.

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

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

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

Т.е. вариантов море.

Если Вы хотите понять как проектировать то я вижу два пути: у вас есть документы на базе которых вы строите модель данных, у вас есть описание предметной области, которое вы анализируете, строите матрицу связей, получаете модель: сначал сущность связь, потом модель основанную на ключах, потом полную атрибутивную модель.

Почитайте Крёнке Теория и практика баз данных - по-моему лучшей книги не придумаешь

а кто фиксирует данные прохождения теста? как студент проходит тест? какие типы тестовых заданий бывают? одновариантный, многовариантный, точный ответ, сопоставление и т.п.

Никто не фиксирует, уже прошли миллионы лет назад, возьмут данные из другой БД и пакетно зальют в эту созданную структуру. И надо только ПРОСМАТРИВАТЬ. Тестовые задания закрытой формы, с несколькими правильными ответам. Для правильности должны быть выбраны все правильные варианты. Я уже говорил.
Веря я в ваш богатый опыт создания таких систем, НУ НЕХОЧУ Я ИЗ МУХИ СЛОНА ДЕЛАТь. Просто хочу разобраться на простом примере.
Уже года 3 занимаюсь разработкой БД (MS SQL, ORACLE). Сделал не одну систему, причём реально используемые. Но проектированием систем детально не занимался, теперь решил заполнить пробел. Читаю про Rational Rose и Data Modeler. Если Вы готовы помочь мне в этом советом, а также сделать на форуме неплохой пример для кучи других жаждущих понять это, пожалуйста помогите. Буду очень благодарен.