Цели использования баз данных
Использование БД в основном обеспечивает:
1. независимость данных и программ;
2. реализацию отношений между данными;
3. совместимость компонентов БД;
4. простоту изменения логической и физической структур БД;
5. целостность, восстановление и защиту БД и др.
Большинство существующих приложений зависит от данных. Это означает, что способ организации данных и способ доступа к ним диктуются требованиями конкретного применения (т.е. приложений). Например, пусть в приложении используется индексно-последовательный набор данных. Различные процедуры доступа к этому набору данных и его обработка будут зависеть от особенностей программ индексно-последовательного метода доступа.
Будем говорить, что приложение, подобное этому, зависит от данных, если невозможно заменить структуру хранения набора данных (организацию) или стратегию доступа (способ доступа), не изменяя приложения. Например, невозможно заменить индексно-последовательную организацию набора данных прямой без изменения приложения.
Независимость данных и программ объясняется двумя основными причинами.
1. В разных приложениях одни и те же данные могут понадобиться в различной форме. Например, значения некоторой переменной в программе А нужны в десятичной, а в программе В — в двоичной форме. Эти две формы представления данных могут быть интегрированы, т.е. объединены в одном файле, а существующая избыточность устранена, если программное обеспечение системы данных выполняет необходимые преобразования данных.
2. В целях эффективности работы в СУБД должна существовать возможность изменения структуры хранения данных и стратегии доступа к ним без модификации приложений.
Отношения между данными. Данные об объектах в БД связаны между собой отношениями(связями). Отношение между объектами А и В обозначим следующим образом:
F(x)
A —— B,
G(x)
где F(х) — вид связи объекта А с объектом В; G(х) — вид связи объекта В с объектом А. Функции F(х) и G(х) могут принимать значения U и N — единичная и множественная связи соответственно. Обычно рассматривают четыре типа отношений.
1. Отношение
U
A —— B (1:1)
U
(один к одному) означает, что каждому экземпляру объекта А может соответствовать только один экземпляр объекта В и, наоборот, любому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например:
U
ПРЕДПРИЯТИЕ —— ДИРЕКТОР
U
2. Отношение
N
A —— B (1: N)
U
(один ко многим) означает, что могут существовать экземпляры объекта А, которым соответствует более одного экземпляра объекта В, но каждому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например:
N
ОРГАНИЗАЦИЯ —— ПОДРАЗДЕЛЕНИЕ (1:N)
U
3. Отношение
U
A —— B (1:N)
N
(многие к одному) означает, что каждому экземпляру объекта А может соответствовать только один экземпляр объекта В и среди экземпляров объекта В могут быть такие, которым соответствует несколько экземпляров объекта А. Очевидно, что если 1: N - тип отношения между А и В, то N : 1 — тип отношения между В и A. Например:
U
РАБОЧИЙ —— ПРЕДПРИЯТИЕ
N
4. Отношение
M
A —— B (M: N)
N
(многие ко многим, или групповое) означает, что может существовать экземпляр объекта А, которому соответствует несколько экземпляров объекта В, и, наоборот, одному экземпляру объекта В может соответствовать несколько экземпляров объекта А. Очевидно, что если М: N — тип отношения между объектами А и В, то N:М — тип отношения между объектами В и А. Например:
M
ПОСТАВЩИК —— ПРОДУКТ
N
Иногда применяют условное отношение С, которое означает, что каждый экземпляр объекта А может иметь один или не иметь ни одного экземпляра объекта В.
Совместимость компонентов БД.Проектирование БД должно осуществляться с учетом некоторой независимости от используемого оборудования и возможного появления изменений содержания и структуры БД.
Программное обеспечение СУБД обычно является надстройкой, расширением возможностей ОС в части управления данными.
Перечислим основные компоненты БД, которые должны быть совместимы, начиная с уровня представления данных: данные, техническое обеспечение, ОС, программное обеспечение методов доступа к данным, СУБД, приложения. Изменение в любом компоненте не должно влиять на последующие компоненты. Так, замена версии ОС не должна повлечь за собой замены СУБД или изменения в приложении.
Простота изменения логической и физической структур БД.База данных должна допускать изменение своих логической и физической структур с минимальными затратами и последствиями для связанных с нею программ.
Логическая структура БД отражает состояние некоторого объекта, явлений в реальном мире. Она достаточно стабильна, но в связи с переменами в реальном мире может изменяться. В связи с этим требуется модификация соответствующих логических схем, существующих элементов и их характеристик, суть которой заключается в появлении новых элементов и связей.
Изменение физической структуры БД необходимо для повышения эффективности процесса обработки информации, а это связано с реорганизацией БД, заменой устройств хранения данных и т. п. Так, добавление новых записей в БД может привести к разрастанию областей переполнения, что повлечет за собой увеличение времени доступа к данным. Когда это время превосходит интервал времени, установленный администратором, происходит физическая реорганизация БД. Такая же реорганизация требуется и для удаления записей, которые располагаются в БД, но не участвуют в обработке.
Добиться оптимальной физической структуры БД очень трудно, поскольку, во-первых, сложно предвидеть многие обстоятельства будущего реального процесса обработки информации и, во-вторых, динамика функционирования объекта может потребовать многочисленных изменений. Именно поэтому более целесообразно обеспечить гибкость изменения структуры и содержимого БД, что и позволяют СУБД. Данная проблема особенно важна при адаптации типовых логических и физических структур БД на различных объектах. Сложность широкого внедрения типовых проектных решений в индустриальную разработку информационных систем связана главным образом со слабыми возможностями систем программного обеспечения, допускающих лишь незначительные изменения логической и физической структур информации об объекте. Поскольку СУБД позволяют с небольшими затратами изменять логическую и физическую структуры БД объекта, появляется возможность использования типовых проектных решений в разрабатываемых информационных системах.
Независимость данных
Независимость данных должна обеспечиваться на логическом и физическом уровнях. Логическая независимость предполагает независимость приложений (внешнего представления) от изменения логической структуры данных. Схема, представленная на рис. 1.1 хорошо поясняет независимость данных. Видим, что независимость данных на логическом уровне обеспечивается тем, что внешнее представление данных не зависимо от способа организации данных. Поэтому изменения на первом и втором уровнях не повлияют на конечное представление данных, т.е. однажды разработанный интерфейс не придется переписывать заново.
Физический уровень независимости данных предполагает независимость данных от их конкретного размещения на физических носителях, их типа, организации и способа доступа. Независимость данных на этом уровне обеспечивается развязкой первого и второго уровней. При изменении физической модели не потребуется производить изменения на концептуальном и внешнем уровнях. В настоящее время этот уровень независимости обеспечивается СУБД и операционной системой, хотя на ранних порах развития баз данных представлял собой большую проблему. Первые БД появились в начале 60-ых годов. Для хранения данных применялись накопители на магнитных лентах, причем не существовало единых стандартов размещения данных на лентах и стандартов управления накопителями. Поэтому при смене типа носителя приходилось полностью переписывать все программы доступа к данным.