Как построить концептуальную модель данных для проектируемой базы данных?

[swame]

Искренне жаль ваших студентов

[HADGEHOGs]

Если я усну и меня разбудят через 100 лет и спросят - как дела - я отвечу - седые кедры в Вузах пишут научные работы по составлению расписания.

Иронично, что 24 года назад один старший преподаватель кафедры АСУиИ защищал аспирантуру по теме "составление расписания ВУЗа при помощи нейронных сетей". И даже писал прогу на C++.

[punhin]

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

[swame]

У меня шеф завкафедрой в МГУ (ядерная физика) где - то 1989-1990 писал расписание на Прологе.

[CrushBy]

Проблема, на мой взгляд, ещё и в том, что ER-подход слишком рано заставляет студента думать существительными: сущность, таблица, атрибут. Бизнес-правила и отношения большей арности появляются потом, поэтому их начинают искусственно запихивать в дополнительные «сущности».

В lsFusion, например, концептуальная модель строится из классов и типизированных свойств, то есть функций над объектами. price(Item, Supplier, Date) или balance(Item, Stock, Date) не обязаны изображаться атрибутом какой-то заранее придуманной сущности. Это просто отношения предметной области. А физические таблицы — уже отдельный уровень хранения этих свойств.

Для обучения такой подход, по-моему, полезен именно тем, что не даёт спутать отношение предметной области с таблицей. Тогда нормализация становится способом физического представления модели, а не самой моделью.