У студента есть номер зачетки. Напрмер 023110 (моя). Как правило он используется в качестве внешнего ключа. Соответственно - атомарное значение
Но вот возник геморой головного мозга: помимо номера зачётки в базе есть запись группа, факультет и год поступления. Но собственно номер зачётки содержит всё это:
0231 - Номер группы вообще. 2 - год поступления (2002). 3 - факультет. 1 - номер группы на потоке. Соответственно номер зачётки - не атомарное значение. И в качестве ключа использоваться не должно. Если добавить записи с факультетом, группой и иже с ними, то получим не нужную избыточность. Если добавим автоинкрементный id сделаем работу, которую уже сделал ректорат:) Если разбить номер зачётки типа вот:
то лишимся ключа.

А так ключь не атомарный использовать можно?

В принципе, что не читал, везде (в том числе вузовские учебники) номер зачётки - ключ внешний.

Мне вот, что интересно: можно ФАКТИЧЕСКИ не атомарное значение хранить в реляцеонной базе?
Можно неатомарное значение использовать в качестве ключа.

Зачем изобретать велосепед?
Ведь есть хороший ключь.

Насчёт атомарных значений слышал/читал. Они нужны, чтоб база была в 1НФ.

Правильно?

softwarer SarinНасчёт атомарных значений слышал/читал. Они нужны, чтоб база была в 1НФ.
1НФ - не самоцель. Важно понимать, что они дают - или от чего придется отказаться.

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

Соответственно, в данном случае нет особых причин возражать против структуры "похожей на 3НФ, но с неатомарным значением". Возражения сводятся к естественным недостаткам естественных ключей.

Самоцелью вроде является ликвидация возможности возникновения аномалий.

Я серьёзные базы не лепил. Всё, что делал сразу получалось в 5НФ.

Купил себе умную книжку. Там, кстати, в сетевых ресурсах sql.ry четвёртой строкой:)
Читаю и внимаю. Мне очень интересну базы данных, а вуз не профильный. Вот и учусь по книгам, статьям да на форуме.

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

Глупое понятие номер студента в группе как раз есть. Это две последнии цифры номера зачётки.

Теоретически должны номер зачётки сменить.
Ведь в другой группе есть студент с таким же номером_студента_в_группе. А он используется для определения варианта задачи на курсовик, или контрольную. И ещё много где.

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

Веришь, не я это придумал.

Вообще-то я не пишу сейчас ничего такого. Просто возник вопрос. Я, как уже говорил, на форуме учусь

Понял.

Ну 25 байт это я так, с потолка взил. На самом деле 10-15.

Лафа у нас по другой причине Вуз халявный. А вариантов заданий 10 штук минимум. И совпадают они у двух трёх человек:)