Введение в системы БД (542480), страница 12
Текст из файла (страница 12)
В этом случае процесс овеществления (ща!ег(а!!ха!!оп), т.е. построения экземпляра логического поля из соответствующего экземпляра хранимого поля и его передачи приложению, можно назвать прямым. Однако иногда логическое поле может не иметь соответствующего эквивалентного хранимого поля, а его значение будет овеществляться посредством некоторых вычислений, выполняемых над набором из нескольких экземпляров хранимых полей. Например, значение логического поля "общее количество" можно определить путем суммирования нескольких хранимых значений поля "количество". Поле "общее количество" — это пример виртуального (ч(ггца1) поля; процесс определения его значения называют непрямыль Заметим, однако, что пользователь может отличить реальное поле от виртуального, так как экземпляр виртуального поля нельзя добавить или изменить (по крайней мере, непосредственно).
° Структура хранимых записей Две существующие хранимые записи можно объединить в одну. Например, хранимые записи и Номер детали Вес детали можно представить в форме Номе етали Вес детали вет детали Такие изменения могут выполняться, когда в систему баз данных интегрируются некоторые ранее существовавшие приложения. При этом предполагается, что логическая запись приложения может состоять из определенного подмножества полей соответствующей хранимой записи, т.е.
некоторые поля хранимой записи будут "невидимы" для рассматриваемого приложения. И наоборот, одна хранимая запись может быть разделена на две. Воспользуемся записями из предыдущего примера. Тогда хранимую запись Часть 1. Основные понятия Вес детали Цвет детали Номе детали можно разбить на две: Номер детали Цвет детали и Номер детали Вес детали Такое разделение позволяет переместить редко используемые части исходной записи в другое место, например на более медленное устройство. При этом неявно предполагается, что логическая запись приложения может содержать поля из нескольких отдельных хранимых записей, т.е.
логическая запись является расширением любой из этих хранимых записей. ° Саруктура хранимых файзов Определенный хранимый файл может физически сохраняться в памяти разными способами. Например. его можно разместить на одном томе памяти (скажем, на одном диске) или распределить на нескольких томах, возможно, разных типов устройств.
Он может быть физически упорядочен в соответствии со значениями некоторого хранимого поля либо быть упорядоченным каким-либо иным способом, например с помощью одного либо нескольких индексов или встроенных цепочек указателей, или же доступ к его записям может быть организован по методу хеширования. Хранимые записи могут быть (а могут и не быть) физически объединены в блоки (по нескольку в одной физической записи). Но ни один из этих факторов не должен каким-либо образом влиять на приложение (за исключением, конечно, эффективности его выполнения). Этим мы ограничим перечень аспектов структуры хранения данных, которые могут подвергаться изменениям.
Здесь среди всего прочего предполагается, что база данных может расти (ягою) и развиваться, не оказывая влияния на приложения. В действительности возможность развития базы данных без логического ущерба для существующих приложений является одним из наиболее важных мотивов обеспечения независимости данных. Например, можно было бы расширить существующий тип хранимой записи, добавив новые хранимые поля, которые обычно представляют дополнительную информацию о некоторых существующих типах сущностей (скажем, к хранимой записи "деталь" можно добавить поле "цена"). Такие новые поля будут невидимы для существующих приложений.
Точно так же можно добавить новые типы хранимых записей (а следовательно, новые хранимые файлы), не изменяя существующих приложений. Подобные записи обычно представляют собой новые типы сущностей (например, к базе данных "детали" можно добавить тип записи "поставщик"). Эти изменения также будут незаметны для существующих приложений. Теперь легко понять, что независимость данных — одна из причин разделения модели данных и ее реализации, как уже указывалось в конце раздела ЬЗ, И очень важно отметить, что чем больше будет такое разделение, тем большая независимость данных будет обеспечена.
Недостаточное разделение модели и ее реализации — широко распространенный недостаток, свойственный, в частности, современным системам, использующим язык ЗОЬ, что особенно огорчает. Замечание. Последнее замечание (относительно использующих язык БЯЬ современных систем) вовсе не означает, что в подобных системах совершенно не обеспечена независимость от данных.
Оно лишь указывает, что эти системы обеспечивают независимость данных в значительно меньшей степени, чем теоретически возможно 55 Глава 1. Базы данны и управление ими в реляционных системах. Иными словами, независимость данных — понятие относительное. Различные системы обеспечивают ее в разной мере или не обеспечивают вообше. Системы, базирующиеся на языке ЯЯ(., более развиты в этом направлении, чем старые системы, однако, как мы увидим в последуюШих главах, все они еше далеки от совершенства.' 1.6. Реляционные и другие системы Как уже упоминалось в конце раздела 1.3, СУБД, базируюшиеся на реляционной модели данных ("реляционные системы"), в настоящее время стали преобладаюшими на рынке баз данных.
Более того, подавляющее большинство научных исследований в области баз данных в течение последних 30 лет было посвящено (иногда косвенно) именно этой модели. Фактически введение реляционной модели в 1969 н 1970 годах было, несомненно, наиболее важным событием в истории развития теории баз данных. По этим причинам, а также учитывая то, что реляционная модель основана на определенных математических н логических принципах и, следовательно, идеально подходит для изложения теоретических концепций систем баз данных, основное внимание в настояшей книге уделяется (как уже отмечалось в разделе 1.!) именно реляционным системам и реляционному подходу.
Что мы подразумеваем под реляционной системой? К сожалению, на данном этапе обсуждения невозможно дать полный ответ на этот вопрос. Однако можно (и нужно!) дать хотя бы приблизительный ответ, который в дальнейшем будет сушественно уточнен. Итак, кратко и не совсем точно реляционная система — это система, основанная на следующих принципах. 1. Данные передаются пользователю в виде таблиц (и никак иначе). 2. Пользователю предоставляются операторы (например, для выборки данных), позволяющие генерировать новые таблицы на основании уже сушествующих. Например, в системе обязательно должны присутствовать оператор ограничения, предназначенный для получения подмножества строк заданной таблицы, и оператор проекции, позволяюший получить подмножество ее столбцов.
Однако подмножество строк и подмножество столбцов некоторой таблицы, безусловно, можно рассматривать как новые таблицы. Замечание. Причина, по которой такие системы называют реляционными, состоит в том, что английский термин "ге!а!юп" (отношение), по сути, представляет собой принятое математическое название для таблицы.
Поэтому на практике термины отношение и таблица в большинстве случаев можно считать синонимами, по крайней мере для неформальных целей. (Обсуждение этого вопроса будет продолжено в главах 3 и 5.) Возможно, следует добавить, что причина, несомненно. заключается не в том, что термин отношение (ге!а!1оп) "по сушеству — просто математическое название для" связи (ге!а!!опзп!р) в терминах диаграмм "сущность-связь" (см.
раздел 1.3). На самом деле между реляционными системами н подобными диаграммами сушествует совсем незначительная прямая связь, что будет показано в главе 13. Как уже отмечалось, в дальнейшем будет дано более точное определение, а сейчас мы будем использовать приведенное выше. На рис. 1.7 представлен пример структуры данных и операторов, используемых в реляционных системах. Данные (рис.
1.7, а) пред- Часть 1. Основные понятия ставлены одной таблицей под названием СЕЬЫЫ (в действительности это еше одна версия таблицы СЕЬЬЕЕ (см. табл. 1.1), просто уменьшенная для того, чтобы с ней было легче работать). На рис. 1.7, б показаны два примера выборки данных: один — с получением подмножества строк (оператор ограничения), а другой — с получением подмножества столбцов (оператор проекции). Замечание. Оба варианта выборки осуществляются с помощью оператора БЕЬЕСХ языка БЯЬ, упомянутого выше в этой главе. Теперь мы можем различать реляционные и не реляционные системы по следуюшим признакам.
Как уже отмечалось, пользователь реляционной системы видит данные в виде таблиц и никак иначе. Пользователь не реляционной системы, напротив, видит данные, представленные в других структурах: либо вместо таблиц реляционной системы, либо наряду с ними. Для работы с этими другими структурами применяются другие операции. В частности, в иерархической системе (например,!МБ фирмы 1ВМ) данные представляются пользователю в форме набора древовидных структур (иерархий), а среди операций работы с иерархическими структурами есть операции перемещения па иерархическим указателям (навигации) вверх и вниз по ветвям деревьев. (Реляционные системы, как мы видели, не имеют таких указателей, и зто очень важная их отличительная особенность.) СЕ1Л АН а) Дана таблица: б) Примеры операторов: 1. Подмножество строк: Результат: БЕЬЕСХ М1ИЕ, ХЕЕЕ, ВОХХЬЕБ ЕЕОМ СЕЬЬЕЕ МНЕЕЕ ХЕЕЕ > 1995 2.
Подмножество столбцов: Результат: БЕЬЕСХ М1МЕ, ВОХХЬЕБ УМОМ СЕ11ЛЕ Рис. Ь 7. Структура данных и операторы в реляционной системе (примеры) Рассмотрим этот вопрос немного подробнее. На практике системы баз данных могут быть легко распределены по категориям в соответствии со структурами данных и операторами, которые они предоставляют пользователю. Прежде всего, старые (дореляционные) системы можно разделить на три большие категории, а именно: системы инвертированных списков (!пчег)ед 1В)), иерархические (п)егагс)з)с) и сетевые Глава 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
