- •Тема № 6 базы данных
- •Введение.
- •2. История создания баз данных.
- •Нулевое поколение: менеджеры записей (4000 г. До н.Э. – 1900 г.)
- •Первое поколение: менеджеры записей (1900 г. – 1955 г.).
- •Второе поколение: программируемое оборудование обработки записей (1955 г. – 1970 г.)
- •Архитектура субд.
- •2.3. Третье поколение: оперативные сетевые базы данных (1965 г.–1980 г.)
- •2.3.1. Иерархические субд.
- •2.3.2. Сетевые базы данных.
- •2.4. Четвертое поколение: реляционные базы данных (1980 г. – 1995 г.).
- •2.4.1. Таблицы.
- •Office city region mgr target sales
- •2.4.2. Первичные ключи.
- •2.4.3. Отношения предок/потомок.
- •Office cyti region
- •Empl_num name age rep_office
- •2.4.4. Внешние ключи.
- •Лекция 6.2. Язык aql как стандартный язык базы данных.
- •5.1. Язык sql.
- •5.2. Роль sql.
- •5.3. Достоинства sql,
- •5.3.1. Независимость от конкретных субд.
- •5.3.2. Переносимость с одной вычислительной системы на другие.
- •5.3.3. Стандарты языка sql.
- •5.3.4. Протокол odbc и компания Microsoft.
- •5.3.5. Реляционная основа.
- •5.3.6. Высокоуровневая структура, напоминающая английский язык.
- •5.3.7. Интерактивные запросы.
- •5.3.8. Программный доступ к базе данных.
- •5.3.9. Различные представления данных.
- •5.3.10. Полноценный язык для работы с базами данных.
- •5.3.11. Динамическое определение данных.
- •5.3.12. Архитектура клиент/сервер.
- •5.4. Пятое поколение: мультимедийные базы данных (1995 г. - …)
- •5.5. Основные требования.
- •5.5.1. Расширяемость.
- •5.5.2. Производительность.
- •5.5.3. Сопровождение в оперативном режиме.
- •5.5.4. Устойчивость.
- •5.6. Технология хранения данных. Корпоративные базы данных.
- •5.6.1. Современные требования к корпоративным базам данных.
- •5.6.2. Потребность в анализе данных.
- •5.6.3. Хранилища данных.
- •5.6.4. Хранилища и киоски данных.
- •5.6.5. Анализ данных в корпоративных системах.
- •5.6.6. Размышления и предсказания.
Архитектура субд.
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представения о:
- физическом размещении запрашиваемых данных;
- механизмах поиска запрашиваемых данных;
- проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
- способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
- поддержки баз данных в актуальном состоянии и множестве других функций СУБД.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют информационной моделью данных (рис.5.2).
Отдельные пользователи
базы данных
Администратор базы
данных
ИНФОЛОГИЧЕСКАЯ
МОДЕЛЬ ДАННЫХ
Обобщенное,
не привязанное к каким-либо ЭВМ и СУБД,
описание предметной области (набор
данных, их типов, длин, связей и т.п.)
ДАТАЛОГИЧЕСКАЯ
МОДЕЛЬ ДАННЫХ Описание на языке
конкретной СУБД
Модели и
описания
используе-
ФИЗИЧЕСКАЯ МОДЕЛЬ
ДАННЫХ Описание хранимых
данных
Рис.5.2. Уровни моделей данных.
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, показанные на рис.5.2, являются компьютерно-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое по инфологической модели данных, называют даталогической моделью данных.
Трухуровневая архитектура (инфологический, даталогический и физический уровни) позволяют обеспечить независимость хранимых данных от использующих их программ. АБД может, при необходимости, переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся “прозрачными” для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.