9.3.3Хронологические базы данных
Традиционные базы данных разрабатываются для обслуживания текущих записей. Например, традиционная инвентаризационная база данных используется для регистрации текущего списка предметов в целях поддержания надлежащего уровня запасов. В таких случаях записи о прошлых инвентаризациях можно найти только в архивных копиях базы данных или явно сохраняя дату инвентаризации как атрибут в базе данных. Существует множество приложений, в которых реализован более удобный доступ к данным и возможность записи данных в будущем. Этот пример иллюстрируется секретариатом университета, который должен планировать выполнение программы обучения, хранить составы групп, отслеживать назначение аудиторий, регистрировать выбор преподавателей и т. д., причем делать это не только для текущего семестра, но и для предыдущих и будущих семестров. Когда в хронологическую базу данных добавляются новые записи, старая информация не удаляется. Новые записи просто становятся последними в архиве, к любой части которого можно без труда обратиться,
В настоящее время ведутся активные исследования хронологических баз данных. Их цель — найти эффективные способы хранения и обработки прошлой, текущей и будущей информации, разработать способы для поиска необходимых данных в таких записях и создать языки запросов к хронологическим базам данных.
Другая, возможно, более серьезная проблема с расширенным отношением возникает, когда мы решаем удалить информацию из базы данных. Предположим, что Джо Е. Бэйкер — это единственный сотрудник, который занимал должность, обозначаемую D7. Если он уволится из компании и его запись будет удалена из базы данных, показанной на рис. 9.4, мы потеряем информацию о должности D7. Действительно, единственная строка, в которой указано, что для должности D7 требуется уровень квалификации К2, это строка, относящаяся к Джо Бэйкеру. То есть если мы удалим все упоминания о Джо Бэйкере и позже захотим получить из базы данных информацию о должности D7, то не найдем необходимых данных.
Вы можете возразить, что эту проблему можно решить, разрешив удалять только часть строки, но это, в свою очередь, приведет к новым сложностям. (Нужно ли оставлять информацию о должности F5 в частичной строке или она присутствует еще в каком-либо кортеже?) Кроме того, искушение использовать частичные строки явно указывает на то, что структуру базы данных можно улучшить.
Причина всех этих проблем в том, что мы объединили несколько представлений в одном отношении. Как уже говорилось, расширенное отношение на рис. 9.4 содержит информацию непосредственно о сотрудниках (имя, идентификационный номер, адрес, номер социального обеспечения), о должностях, существующих в компании (идентификатор должности, название должности, отдел, код
квалификации), и о связях между сотрудниками и должностями (дата начала, дата окончания). Основываясь на этом наблюдении, мы можем решить проблемы, перестроив систему с использованием трех отношений — по одному на каждую перечисленную выше совокупность информации. Мы сохраним отношение, показанное на рис. 9.3 (которое теперь назовем EMPLOYEE (служащий)), в исходном виде и введем дополнительную информацию в форме двух новых отношений JOB (должность) и ASSIGNMENT (назначение (на должность)), получив в итоге базу данных, представленную на рис. 9.5.
В базе данных, состоящей из этих трех отношений, вся информация о сотрудниках хранится в отношении EMPLOYEE, о должностях — в отношении JOB, и об истории этих должностей — в отношении ASSIGNMENT. Дополнительную информацию можно явно получить, совместив данные из разных отношений. Например, если мы знаем идентификационный номер сотрудника, то можем найти отделы, в которых он работал. Для этого сначала необходимо узнать все должности, которые занимал этот сотрудник, при помощи отношения ASSIGNMENT и затем найти отделы, с которыми связаны найденные должности, в отношении JOB (рис. 9.6).
Выполняя подобные процедуры, любую информацию, которую можно было бы получить из одного большого отношения, мы можем теперь восстановить из трех небольших отношений, избежав при этом ранее перечисленных проблем.
К сожалению, разделение информации на разные отношения не всегда так просто, как в предыдущем примере. Например (рис. 9.7), сравните исходное отношение с атрибутами Empild, JobTitie и Oept с предлагаемым разбиением на два новых отношения. На первый взгляд, система с двумя отношениями содержит ту же информацию, что и система с одним отношением, но на самом деле это не так. Возьмем проблему поиска отдела, в котором работает определенный сотрудник. Это легко сделать в системе с одним отношением, опросив строку, содержащую идентификационный номер сотрудника, и выбрав соответствующий отдел. Но в системе с двумя отношениями нужная информация не так легко доступна. Мы можем найти должность нашего сотрудника и отдел, которому принадлежит эта должность, но это не означает, что данный сотрудник работает именно в этом отделе, так как одна и та же должность может присутствовать в различных отделах.
В некоторых случаях отношение можно разделить на более мелкие части без потери информации, в других случаях какие-то данные теряются. (Первый вариант называется разбиением без потерь, или беспроигрышным разбиением.) Изучение свойств отношений было и остается темой исследований вычислительной техники. Цель изысканий — указать свойства отношений, которые могут привести к возникновению проблем в разработке базы данных, и найти способы реорганизации отношений для их устранения.