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

Но здесь будет правомочен вопрос о том, что не слишком ли это увеличивает объемы работ, не затрудняет ли это работу?

Отчасти этот вопрос резонен. Хранить два списка записей труднее, чем один. Но давайте посмотрим еще раз на журнал, (см. рис 1.2). Разве вы уже не храните два набора записей? Рассмотрим такие факты.

Результаты отслеживаются в ячейках матрицы результатов. Каждая ячейка отмечена именем учащегося и датой (строки - имена, а столбцы - даты). Это один набор данных. Его аналог - содержимое таблицы score.

Как можно узнать, какой тип события представляет каждая дата? Ага, над каждой датой надписано маленькое Т или Q ! Таким образом вы отслеживаете взаимосвязь между датой и типом результата. Это второй набор данных. Его аналог - содержимое таблицы event.

Другими словами, даже невзирая на то, что вы думаете обо все этом, на самом деле вы не делаете ничего, отличного от того, что предлагает автор. Единственным различием является то, что в журнале эти два набора данных не столь явно разделены.

Страничка журнала иллюстрирует наше понимание информации и сложность переноса этих данных в базу данных. Обычно мы стараемся объединить различные типы информации и представить все это как единое целое. Базы данных так не работают. Вот почему они кажутся искусственными и неестественными. Природная человеческая потребность унифицировать информацию делает страшной мысль о множестве типов данных вместо одного. Поэтому для читателя может быть проблематично думать так, как думает база данных .

Единственное требование к таблице event: даты должны быть уникальными. Это требование имеет место потому, что по дате производится связывание записей из таблиц score и event. Другими словами, нельзя провести две викторины или викторину и тест в один день. В противном случае, у вас получится два набора записей в таблице score и две записи в таблице event, все с одной и той же датой. И у вас не будет возможности связать записи таблицы score с записями таблицы event.

Эта проблема не возникнет, если делать в один день не больше одного экзамена, но насколько вероятно обратное? На первый взгляд, это достаточно правдоподобно; в конце концов, не садист же вы, чтобы назначать и викторину, и тест на один и тот же день. Но я верю, что читатель простит мой скепсис. Очень часто я сталкивался с такой ситуацией, когда мне говорят, что этого никогда не случится, но это вдруг происходит, и мне приходится переделывать структуру таблиц.

Проблемы, которые могут возникнуть в будущем, надо предвидеть и заранее продумать, как избежать их возникновения. Итак, предположим, что вам может понадобиться записать два результата за день. Что делать в этом случае? Оказывается, эту проблему рещить не так трудно. С минимальными изменениями в структуре данных мы разрешаем хранить много событий для одной даты.

1. Добавим столбец в таблицу event и будем в ней хранить номер, уникальный для каждой записи в таблице. Это присвоит каждой записи таблицы свой собственный идентификационный номер. Назовем ее event id. (Просмотрите журнал на рис. 1.2, если читателю покажется это странным: идентификационный номер события очень напоминает номер столбца на матрице результатов вашего журнала. Номер может быть записан явно, даже назван идентификатор события , но это именно он.)

2. При записи результатов в таблицу score вводите идентификатор, а не дату события.

Результат этих изменений показан на рис. 1.6. Связь между таблицами score и event осуществляется с помощью идентификатора. Теперь в таблице event будет храниться не только тип события, но и дата, когда оно произошло. Кроме того, уникальность должна соблюдаться теперь не для даты события, а для его идентификатора. Это означает, что у вас может быть дюжина тестов и викторин в один и тот же день. (Без сомнения, ваши учащиеся начнут нервничать, узнав это.)

К сожалению, с моей точки зрения, структура таблицы на рис. 1.6 кажется менее удовлетворительной, чем предыдущая. Таблица score является более абстрактной, чем ее предьщущие воплощения. Это явилось следствием того, что стало меньше столбцов с явным содержанием. Структура таблицы score, представленная на рис. 1.4, более понятна, так как содержит столбцы с датами и типами результатов. Последняя структура таблицы (см. рис. 1.6) имеет столбцы, назначение которых объяснить уже трудно. Она достаточно далека от понятных категорий. Кому захочется смотреть на таблицу score с Идентификатором события ? Для непосвященного это ничего не значит.

Таблица score

Таблица event

Рис. 1.6. Таблицы score и event, связанные по идентификатору события Глава 1. Знакомство с СУБД MySQL и SQL

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

Возникает естественный вопрос; Насколько целесообразно использовать базу данных? Может быть, СУБД MySQL не для нас? Как можно догадаться, мой ответ может быть только отрицательным, иначе эта книга теряет свой смысл. Ведь когда вы обдумываете, как сделать работу, не мешает рассмотреть различные альтернативы, например, выбор какой-либо базы данных (предположим, СУБД MySQL) или что-то наподобие электронных таблиц.

Электронная таблица тоже может хранить данные в виде строк и столбцов. Это делает электронную таблицу и журнал успеваемости концептуально и визуально подобными.

Используя электронную таблицу, можно производить вычисления. Это позволит суммировать оценки учашихся. Задача немного усложняется присутствием весового коэффициента. Но и это преодолимо.

Однако если читателю захочется посмотреть только на какие-то определенные данные (только на тесты или викторины), провести сравнения оценок девочек с оценками мальчиков, отобразить суммарные данные различными способами - это уже другое дело. Электронной таблице с этими задачами будет уже справиться труднее. А СУБД с этим справляются запросто.

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

Например, при выборке результатов из таблицы scores идентификаторы событий читателю не нужны, а нужны даты. Это нетрудно. По идентификатору события база данных просмотрит даты из таблицы event и выдаст их. Может просмотреть, с какими результатами вы имеете дело? С результатами тестов или результатами викторин? Это не проблема. База данных найдет типы результатов аналогичным образом, - пользуясь идентификатором события. Помните для чего удобна СУБД, подобная СУБД MySQL: для связывания информации из одного источника с информацией из другого. В случае с данными по успеваемости СУБД MySQL связывает информацию с помошью идентификатора события.

Теперь посмотрим, как работает связь одной таблицы с другой в СУБД MySQL. Для этого сделаем запрос. Предположим, нам требуются все результаты за 23 сентября 1999 года. Получится вот такой запрос: