Cтраница 2
Таким образом, существует две возможности: логическое представление данных может содержать информацию о путях использования групп элементов данных ( сегментов, записей) или эта информация может быть не включена в логическое представление данных. В настоящее время программное обеспечение в большинстве случаев включает эту информацию, так как содержит средства обслуживания некоторых конкретных структур - древовидных, сетевых, наборов и так далее. В том случае, если логическое представление данных исключает информацию о путях использования, как, например, в реляционной базе данных, то для обеспечения хорошей производительности системы такую информацию должно содержать физическое представление данных. [16]
Прежде чем описывать физическую реализацию связей между данными, мы должны обсудить способ, с помощью которого конечные пользователи базы данных ( обращающиеся к ней с помощью терминалов или прикладных программ) представляют эти связи. Существуют различные способы представления логических связей. Одни из них вполне удовлетворительны, другие довольно запутанны и могут ввести в заблуждение, третьи ограниченны в том смысле, что с их помощью нельзя представить все реально существующие связи. В этой и в последующих главах обсуждается логическое представление данных. Часть II книги посвящена физическому представлению данных. [17]
Реляционная модель данных организует объекты и взаимосвязи между ними в виде таблицы, причем взаимосвязи также рассматриваются в виде объектов. В ее основе лежит хорошо проработанная теория отношений, формализующая взаимосвязи между объектами базы. При этом связи между данными могут быть также представлены в виде двумерных файлов. Заранее имеющаяся избыточность не должна настораживать, поскольку речь идет о логическом представлении данных, физическое же отображение данных, соответствующее этому логическому, может и должно быть избыточным. Процесс приведения произвольной структуры к табличному виду, выполняемый строгими методами, носит название нормализации. [18]
С помощью программ управления данными представление данных для пользователя может храниться отдельно от их физического представления; при этом физическое представление и аппаратура могут быть при необходимости изменены без изменения логического описания данных. Наряду с такой независимостью еще одно важное соображение говорит в пользу логического описания данных: удобство применения для большинства пользователей и прикладных программистов. Мы должны найти такой способ описания данных, который: 1) понятен пользователю, не имеющему особых навыков в программировании; 2) позволяет подсоединять новые элементы данных, записи, связи без изменения существующих подсхем и, следовательно, прикладных программ; 3) допускает максимальную гибкость при обработке непредсказуемых или случайных запросов с терминалов. Следует заметить, что представление данных в виде деревьев, сетевых и списковых структур в общем случае препятствует многим изменениям данных, необходимым при росте базы; рост базы может привести к нарушению логического представления данных и, как следствие, к изменениям в прикладных программах. [19]
Во-вторых, необходимое пользователю логическое представление требуемой части хранимых данных может отличаться от их логического представления, принятого в МД. Так, одних пользователей могут не интересовать информационные связи между данными, представленные в МД, в то время как эти связи интересны другим пользователям. В третьих, необходимо обеспечивать защиту данных, не имеющих отношения к конкретному пользователю, от его некомпетентных действий. Поэтому вводится еще один уровень логического представления данных - для каждого конкретного пользователя. [20]
ЪД и проведены изменения, запись о них в журнале будет отсутствовать. Для завершения журнала, как правило, предоставляются программы окончательного закрытия журнала, которые работают как автономные утилиты, определяют адрес несброшенного буфера, используя управляющие таблицы СУБД, записывают его в журнал и закрывают ленту. При этом важным моментом является то, что СУБД должна сначала формировать запись журнала, а потом проводить изменения БД. Очевидно, возможны отказы, при которых будет потеряно содержимое основной: памяти и журнал не будет успешно закрыт. В некоторых системах аппарат управления данными реализован таким образом, тобы избежать подобных ситуаций, о чем будет говориться ниже. В журнал может заноситься физическое и логическое представление данных БД. При физическом представлении данных в журнал помещается копия блока, содержащего изменения. При логической записи в журнал помещается некоторая сжатая информация, которая может быть использована для восстановления БД при применении специальных алгоритмов. При физической записи, например в IDMS [8], обеспечивается очень быстрое восстановление, но может потребоваться существенно больший объем внеш-ней и основной памяти и значительные накладные временные рас-ды на ведение журнала. [21]