Работа с СУБД Oracle. Обзор
Характеристика особенностей сетевого программного обеспечения. Исследование файлов базы данных. Ознакомление с процессами разделяемого сервера. Изучение свободного пространства и автоматической организации непрерывных участков. Анализ целостности данных.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курс лекций |
| Язык | русский |
| Дата добавления | 15.06.2018 |
| Размер файла | 602,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Московский Государственный Строительный Университет (МГСУ)
Факультет «Экономика, организация и управление в строительстве» (ЭОУС)
Кафедра «Информационные системы и технологии управления строительством» (ИСТУС)
Лекции по курсу: «Информационные технологии и информационное обеспечение АСУ»
Работа с СУБД Oracle. Обзор
Преподаватель: ассистент Никитина Светлана Владимировна
Москва 2004 год
- Содержание
- Введение
- 1. Реляционная модель данных
- 1.1 Иерархические и сетевые модели
- 1.2 Элементы реляционной модели
- 1.2.1 Реляционные структуры данных
- 1.2.2 Ключевые значения и ссылочная целостность
- 2. Реляционная алгебра
- 3. Компоненты RDBMS
- 3.1 Ядро rdbms
- 3.2 Словарь данных
- 3.3 Непроцедурный доступ к данным (SQL)
- 4. Краткий обзор обработки данных в среде клиент/сервер
- 4.1 Базы данных в архитектуре клиент/сервер
- 4.2 Oracle и обработка данных в среде клиент/сервер
- 5. Сервер СУБД Oracle
- 6. Сетевое программное обеспечение
- 7. Инструменты разработки систем клиент/сервер
- 8. Развитие Oracle
- 9. Общий обзор архитектуры Oracle
- 9.1 Файлы Oracle
- 9.2 Системные и пользовательские процессы
- 9.3 Память
- 9.4 Системная память
- 9.5 Память пользовательского процесса
- 9.6 Сетевое программное обеспечение и SQL*Net
- 10. Файлы Oracle
- 10.1 Файлы базы данных
- 10.2 Управляющие файлы
- 10.3 Журнальные файлы
- 10.3.1 Оперативные журнальные файлы
- 10.3.2 Автономные/архивные журнальные файлы
- 10.4 Другие файлы поддержки
- 10.5 Системные и пользовательские процессы
- 10.5.1 Обязательные системные процессы
- 10.5.2 DBWR - процесс записи в БД
- 10.5.3 SMON - системный монитор
- 10.5.4 PMON - монитор процессов
- 10.5.5 Необязательные системные процессы
- 10.5.6 ARCH - архиватор
- 10.5.7 СКРТ-процесс выполнения контрольных точек
- 10.5.8 RECO - процесс восстановления
- 10.5.9 LCK - процесс блокировки
- 10.5.10 Listener - процесс прослушивания сети ("слушатель")
- 10.5.11 Пользовательские процессы
- 10.5.12 Однозадачная конфигурация
- 10.5.13 Конфигурация с выделенным сервером
- 10.5.14 MTS (Multi-Threaded Server) - многопотоковый сервер
- 10.5.15 Процессы-диспетчеры
- 10.5.16 Процессы разделяемого сервера
- 11. Оперативная память Oracle
- 11.1 Системная глобальная область (SGA)
- 11.1.1 Кэш буферов данных
- 11.1.2 Журнальный кэш
- 11.1.3 Область разделяемого пула
- 11.1.4 Область SQL
- 11.1.5 Кэш словаря
- 11.1.6 Глобальная область процесса
- 11.1.7 Программы Oracle
- 12. Внешняя память Oracle
- 12.1 Табличные пространства и файлы базы данных
- 12.1.1 Сегменты
- 12.1.2 Экстенты
- 12.1.3 Блоки Oracle
- 12.1.4 ROWID - идентификатор строки
- 12.1.5 Свободное пространство и автоматическая организация непрерывных участков
- 13. Системные объекты базы данных
- 13.1 Словарь данных
- 13.2 Сегменты отката
- 13.3 Временные сегменты
- 13.4 Сегмент начальной загрузки/кэша
- 14. Защита данных
- 14.1 Транзакции, фиксация и откат
- 14.2 Целостность данных
- 14.2.1 Ограничения целостности
- 14.2.2 Ограничения NOT NULL (не пусто)
- 14.2.3 PRIMARY KEY (первичный ключ)
- 14.2.4 UNIQUE (уникальный)
- 14.2.5 FOREIGN KEY (внешний ключ)
- 14.2.6 CHECK
- 14.3 Индексы
- 14.4 Триггеры базы данных
- 14.5 Привилегии системного уровня
- 14.6 Привилегии объектного уровня
- 14.7 Пользователи и роли
- 14.8 Протоколирование (аудит)
- 15. Резервное копирование и восстановление
- 15.1 Различные типы сбоев
- 15.1.1 Сбой оператора SQL
- 15.1.2 Сбой пользовательского процесса
- 15.1.3 Машинный сбой
- 15.1.4 Сбой экземпляра
- 15.1.5 Сбой распределенной транзакции
- 15.1.6 Дисковый сбой/потеря файла
- 15.2 Холодное резервное копирование
- 15.2.1 Архивирование
- 15.3 Горячее резервное копирование
- 15.4 Экспорт и импорт
- 16. Мультиплексирование
- 16.1 Управляющие файлы
- 16.2 Журнальные файлы
- 17. Распределенные базы данных
- 17.1 Поддержка национальных языков
- 17.2 Прохождение оператора SQL через архитектуру
- 18. Безопасность
- 18.1 Управление работой пользователей
- 18.2 Аутентификация пользователей
- 18.2.1 Аутентификация по паролю
- 18.2.2 Аутентификация операционной системы
- 18.2.3 Аутентификация глобального имени пользователя
- 18.3 Табличная область пользователя
- 18.3.1 Табличная область по умолчанию
- 18.3.2 Временная табличная область пользователя
- 18.4 Блокированные и разблокированные учетные сведения пользователей
- 18.5 Работа с привилегиями
- 18.5.1 Типы привилегий
- 18.5.2 Системные привилегии
- 18.5.3 Объектные привилегии
- 18.5.4 Предоставление и отмена привилегий
- 18.5.5 Работа с привилегиями при помощи ролей
- 18.6 Система ролей в базе данных
- 18.6.1 Предварительно установленные роли базы данных
- 18.6.2 Роли, определяемые пользователями
- 18.6.3 Разрешение и запрещение ролей
- 18.6.4 Роли по умолчанию
- 18.6.5 Аутентификация ролей
- 18.7 Ограничение использования ресурсов
- 18.7.1 Квоты для табличных областей
- 18.7.2 Наборы параметров для ограничения ресурсов
- 18.7.3 Робота с учетными сведениями пользователей
- 18.7.4 Набор параметров для ограничения ресурсов по умолчанию
- 19. Аудит баз данных
- 19.1. Избирательный аудит
- 19.2 Записи аудита и журнал аудита
- 20. Схемы - организующие объеты базы данных
- 20.1 Соотношение схем и учетных сведений пользователей баз данных
- 20.2 Словарь данных -- уникальная схема
- 20.3 Таблицы баз данных
- 20.3.1 Столбцы и типы данных
- 20.3.2 Наиболее часто используемые типы данных Oracle
- 20.3.3 CHAR и VARCHAR2 -- символьные типы данных Огасlе
- 20.3.4 NUMBER -- числовой тип данных Oracle
- 20.3.5 DATE -- временной тип данных Oracle
- 20.3.6 CLOB, BLOB и другие -- мультимедийные типы данных Oracle
- 20.3.7 Сравнение типов денных LOB со старыми типами данных больших объектов Oracle
- 20.3.8 Поддержка национальных языков для символьных типов данных
- 20.3.9 Значения по умолчанию для столбцов
- 20.3.10 Целостность данных и ограничения целостности
- 20.3.11 Целостность доменов, null-значения и сложные домены
- 20.3.12 Сущностноя целостность, первичные и дополнительные ключи
- 20.3.13 Ссылочная целостность, внешние ключи и действия по обеспечению ссылочной целостности
- 20.4 Действия по обеспечению ссылочной целостности
- 20.4.1 Механизм проверки ограничений целостности
- 20.5 Представления как один из способов отображения табличных данных
- 20.5.1 Представления только для чтения
- 20.5.2 Обновляемые представления
- 20.5.3 Триггеры INSTEAD OF и обновляемые представления
- 20.5.4 Обновляемые представления и ограничения целостности
- 20.5.5 Представления других типов
- 20.6 Индексы -- повышение производительности доступа к таблицам
- 20.6.1 Другие возможности индексирования
- 20.6.2 Кластеры данных -- уникальный способ хранения табличных данных
- 20.7 Последовательности -- эффективная генерация уникальных значений
- 20.8 Синонимы -- объекты с различными именами
- 21. Хранение баз данных
- 21.1 Табличные области
- 21.1.1 Табличная область SYSTEM
- 21.1.2 Другие табличные области
- 21.1.3 Оперативные и отключенные табличные области
- 21.1.4 Постоянные и временные табличные области
- 21.1.5 Табличные области только для чтения и чтения/записи
- 21.1.6 Дополнительные сведения о файлах данных
- 21.1.7 Число файлов данных для табличной области
- 21.1.8 Размеры файлов данных
- 21.1.9 Повреждение файлов данных
- 21.1.10 Оперативные и отключенные файлы данных
- 21.2 Управляющие файлы
- 21.2.1 Зеркально отображенные управляющие файлы
- 21.2.2 Сегменты, экстенты и блоки данных
- 21.2.3Сегменты данных и индексные сегменты
- 21.2.4 Временные сегменты
- 21.2.5 Временные табличные области
- 21.2.6 Сегменты отката
- 21.2.7 Запись информации в сегменты отката
- 21.2.8 Сегмент отката SYSTEM
- 21.2.9 Несколько сегментов отката
- 21.2.10 Назначение конкретных сегментов отката
- 21.3 Блоки данных
- 21.3.1 Сцепление строк и размер блока данных
- 21.4 Параметры хранения объектов
- 21.4.1 Размещение табличных областей
- 21.4.2 Параметры для экстентов
- 21.4.3Установки по умолчанию для хранения объектов
- 21.4.4 Установки по умолчанию для пользователей
- 21.4.5 Установки по умолчанию для табличных областей
- 21.5 Разделение данных
- 21.5.1 Разделенные таблицы
- 21.5.2 Размещение строк в разделах данных
- 21.6 Разделенные индексы
- 21.7 Имена таблиц с учетом разделов
- 21.8 Управление разделением
- 22. Основные компоненты SQL*Loader
- 22.1 Входные данные
- 22.2 Управляющий файл
- 22.3 Файл протокола загрузки
- 22.4 Файлы отвергнутых и отсеянных записей
- 22.5 Физические записи и логические записи
- 22.6 Сцепленные записи
- 22.7 Типы загрузки SQL*Loader
- 22.7.1 Обычная загрузка
- 22.7.2 Прямая загрузка
- 22.7.3 Параллельная загрузка данных
- 22.8 Синтаксис управляющего файла
- 22.9 Метод загрузки для таблицы
- 22.10 Индексные опции
- 22.11 Условия, относящиеся к полям
- 22.12 Спецификации столбцов
- 22.13 Установка значений столбца
- 22.14 Спецификации типа данных
- 22.15 Использование функций SQL
- 22.16 Операторы загрузки в несколько таблиц
- 22.17 Опции командной строки и файлы параметров
- 22.18 Производительность SQL*Loader
- 23. Импорт и экспорт
- 23.1 Цели и возможности операций импорта и экспорта
- 23.2 Механизм выполнения операций
- 23.3 Управление и задание конфигурации импорта и экспорта
- 23.4 Описание параметров утилиты экспорта
- 23.5 Описание параметров утилиты импорта
- 23.6 Что происходит в том случае, когда таблица существует
- 23.7 Упорядочивание фрагментированного табличного пространства
- 23.8 Перемещение объектов базы данных из одной схемы в другую
- 23.9 Перемещение большого количества объектов и объектов различных типов
- 23.10 Случай, когда табличные пространства не соответствуют друг другу
- 23.11 Перемещение объектов БД из одного табличного пространства в другое
Список литературы
Введение
В последние годы системы управления базами данных (СУБД, DBMS) утвердились как основные средства для хранения данных в информационных системах различного масштаба -- от больших приложений обработки транзакций в банковских системах до персональных систем на PC. Сердцем большинства сегодняшних информационных систем является система управления реляционными базами данных (Relational Database Management System -- RDBMS). Системы RDBMS последние 10 лет стали популярны при выполнении операций управления данными и продолжают развиваться и совершенствоваться, обеспечивая реализацию сложных функций хранения, поиска и распределения данных в информационных системах уровня предприятия. По сравнению с файловыми системами RDBMS обеспечивают возможность легкой интеграции и обработку значительных объемов операционных данных в реальных информационных системах. Развитие мощных процессоров баз данных, таких как Oracle, сделало возможным применение таких технологий, как архитектуры клиент/сервер, оперативной аналитической обработки, организации корпоративных хранилищ данных - словом, все, что определяет лицо современных информационных систем.
База данных -- это рассматриваемое как единое целое собрание данных, между которыми существуют отношения. Структура базы данных облегчает доступ к данным, относящимся к некоторому объекту, например, "студент" и "все изучаемые им курсы" или "служащий" и "его иждивенцы". Далее, реляционная база данных -- тип базы данных, основанный на реляционной модели, нереляционные базы данных обычно основаны на иерархической, сетевой или объектно-ориентированной модели. Наконец, система управления реляционными базами данных -- программное обеспечение, которое управляет реляционной базой данных. Эти системы делятся на несколько классов, от однопользовательских персональных систем до полнофункциональных, глобальных корпоративных систем, каковой и является Oracle.
1. Реляционная модель данных
Большинство систем управления базами данных, используемых в современных приложениях, основано на одной из трех основных моделей: иерархической, сетевой или реляционной.
1.1 Иерархические и сетевые модели
Первые коммерчески доступные системы управления базами данных соответствовали стандарту CODASYL, и многие из них по-прежнему используются в написанных на КОБОЛе приложениях, работающих на мэйнфреймах. Сложность как сетевых, так и иерархических баз данных объясняется тем, что они построены с использованием внутренних физических указателей, связывающих записи между собой. Например, в системе учета счетов-фактур запись о продавце могла бы содержать физический указатель на записи о заказах. Каждая запись заказа, в свою очередь, содержит указатели на записи строк товаров в заказе.
Процесс вставки, изменения и удаления записей при использовании этих типов баз данных требует обновления значений указателей -- задача, которая должна выполняться самим приложением. Как можно предположить, это требует разработки и сопровождения значительного объема кода приложения, что иногда может стать совершенно непосильным бременем.
1.2 Элементы реляционной модели
Реляционные базы данных для организации связей между записями применяют фактические значения атрибута, а не внутренние указатели. Вместо внутреннего указателя от записи продавца к записи заказа можно связать запись заказа с записью продавца, используя общий атрибут в каждой из записей, например номер идентификации продавца.
По сути, существуют три базовых компонента реляционной модели: реляционные структуры данных; ограничения, налагаемые на структуру данных; oпeрации, которые выполняются над этими структурами данных.
1.2.1 Реляционные структуры данных
Реляционная модель поддерживает единственную "логическую" структуру, которая называется отношением. Это двумерная структура данных, соответствующая таблице в "физической" базе данных. Атрибуты представляют атомарные (неделимые) элементы данных, которые связаны отношением. Например, отношение Customer могло бы содержать такие атрибуты заказчика, как его номер, имя, регион, состояние кредита и т.д.
Фактические значения данных атрибутов отношения хранятся в кортежах, или строках, таблицы. Необязательно, чтобы отношение фактически содержало данные; даже если фактические данные для отношения не существуют, отношение остается определенным набором атрибутов.
1.2.2 Ключевые значения и ссылочная целостность
Атрибуты группируются с другими атрибутами на основании их зависимости от значения первичного ключа. Первичный ключ -- атрибут или группа атрибутов, который уникально идентифицирует строку в таблице. Таблица имеет единственный первичный ключ, и, как правило, каждая таблица имеет такой ключ. Поскольку значения первичного ключа используются как идентификаторы, они не могут быть пустыми. При использовании стандартной нотации для указания, что данный атрибут -- первичный ключ отношения, атрибут подчеркивается. Если первичный ключ состоит из нескольких атрибутов, подчеркивается каждый атрибут.
Можно определять другие атрибуты в отношении как уникальные ключи отношения. В отличие от первичных ключей уникальные ключи могут содержать пустые значения. Практически уникальные ключи используются, чтобы предотвратить дублирование в таблице, а не для идентификации строк. Рассмотрим отношение, которое содержит атрибут United States Social Security Number (SSN) (номер в системе социального обеспечения США ). В некоторых строках этот атрибут может быть пустым, так как не каждый человек в США получает SSN; однако для строк, которые содержат непустое значение атрибута SSN, оно должно быть уникальным для данного отношения.
Связь между отношениями обычно организуют с помощью атрибута, общего для обоих отношений. Этот общий атрибут обычно является первичным ключом одной таблицы и внешним ключом другой. Правила ссылочной целостности требуют, что бы значения внешнего ключа одного отношения ссылались на значения первичного ключа другого отношения. Внешние ключи могут также ссылаться на первичный ключ того же отношения.
Реляционные базы данных проектируются с использованием правил нормализации, определяющих перечень отношений и вхождение в них атрибутов. Существуют несколько форм нормализации, которым может соответствовать модель данных. Большинство проектов баз данных соответствует третьей нормальной форме. Эта форма предназначена для устранения избыточности в модели данных. Она требует, чтобы каждый атомарный элемент данных входил в модель данных один раз и зависел от одного и только от одного первичного ключа. Использование нормализованной модели данных гарантирует выполнение операций вставки, модификации и удаления без аномалий, которые могут появляться вследствие некорректно определенных отношений.
2. Реляционная алгебра
Реляционная модель определяет операции, которые разрешаются выполнять над отношением или группой отношений. Реляционные операторы делятся на унарные и бинарные. Результатом применения оператора к отношению (к отношениям) является другое отношение. Эти операции достаточно интуитивны и очень схожи с операциями над множествами. Бинарный тип оператора указывает, что в операции участвуют в качестве операндов два отношения; унарный тип -- что одно отношение.
Операция тип результирующее отношение
Объединение Бинарный Строки из двух отношений объединяются с удалением дублированных строк
Пересечение Бинарный Строки, общие для двух отношений
Разность Бинарный Строки, которые существуют в первом отношении, но не во втором
Проекция Унарный Строки, которые содержат некоторые столбцы исходного отношения
Выбор(Селекция) Унарный Строки исходного отношения, которые соответствуют критерию запроса
Произведение(декартово) Бинарный Конкатенация каждой строки одного отношения с каждой строкой другого
Соединение Бинарный Конкатенация строк одного отношения и соответствующих строк другого
Исходные отношения используемые в операциях объединения, пересечения и разности, должны иметь списки атрибутов, совпадающие по количеству и типам данныхю
3. Компоненты RDBMS
Две важные части архитектуры RDBMS -- ядро, которое является программным обеспечением, и словарь данных, который состоит из структур данных системного уровня, используемых ядром, управляющим базой данных.
3.1 Ядро rdbms
RDBMS можно рассматривать как операционную систему (или подсистему), разработанную специально для управления доступом к данным; ее основные функции -- хранение; выборка и обеспечение безопасности данных. Подобно операционной системе, Огас1е управляет доступом одновременно работающих пользователей базы данных к некоторому набору ресурсов. Подсистемы RDBMS очень схожи с соответствующими подсистемами ОС и сильно интегрированы с предоставляемыми базовой ОС сервисными функциями доступа на машинном уровне к таким ресурсам, как память, центральный процессор, устройства и файловые структуры. RDBMS такого уровня, как Огас1е, поддерживают собственный список авторизованных пользователей и их привилегий; управляют кэшем памяти и страничным обменом; управляют блокировкой разделяемых ресурсов; принимают и планируют выполнение запросов пользователя; управляют использованием табличного пространства.
2.2 Словарь данных
Фундаментальное различие между RDBMS и другими БД и файловыми системами заключается в способе доступа к данным. RDBMS позволяет обращаться к физическим данным в более абстрактной, логической форме, обеспечивая легкость и гибкость при разработке кода приложения. Программы, использующие RDBMS, обращаются к данным через "машину" базы данных без непосредственной зависимости от фактического источника данных, изолируя приложение от деталей "нижележащих" физических структур данных. Вместо обращения к номеру заказчика как к байтам с 1 по 10 в записи о заказчике приложение просто обращается к атрибуту Customer Number. RDBMS сама заботится о том, где поле хранится в базе данных. Рассмотрим объем модификаций программного обеспечения, который потребуется для изменения структуры записи в приложении, использующем файловую систему. Например, если поле номера заказчика перемещается из байтов с 1 по 10 в байты с 11 по 20, чтобы разместить дополнительное поле, во всех программах, использующих атрибут номера заказчика, потребуются модификации. Однако при использовании RDBMS приложение продолжало бы обращаться к атрибуту по имена, а не по позиции в записи, что исключает потребность в каких-либо изменениях.
Такая независимость данных возможна благодаря словарю данных RDBMS, который хранит мета-данные (данные о данных) для всех объектов, расположенных в базе данных. Словарь данных Огас1е -- множество таблиц и объектов базы данных, которое хранится в специальной области базы данных и ведется исключительно ядром Огас1е. Запросы чтения или обновления базы данных обрабатываются ядром Oracle с использованием информации из словаря данных. Информация в словаре данных предназначена для подтверждения существования объектов, обеспечения доступа к ним и описания фактического физического расположения в памяти.
RDBMS не только обеспечивает размещение данных, но также определяет оптимальный путь доступа для хранения или выборки данных. Огас1е использует сложные алгоритмы, которые позволяют выбирать информацию с наибольшей производительностью, исходя из критерия скорейшего получения первых строк результата или критерия минимального времени выполнения запроса в целом.
3.3 Непроцедурный доступ к данным (SQL)
Характерной чертой RDBMS является способность обработки данных как множества; файловые системы и СУБД с другими моделями обрабатывают данные способом "запись-за-записью". С RDBMS можно общаться, используя структурированный язык запросов (Structured Query Language -- SQL; произносится "сиквел". Sequel -- по английски "результат"). SQL -- непроцедурный язык, который разработан специально для операций доступа к нормализованным структурам реляционных баз данных. Основное различие между SQL и традиционными языками программирования состоит в том, что операторы SQL указывают, какие операции с данными должны выполниться, а не способ их выполнения. Уменьшая объем программирования, мы уменьшаем общие издержки разработки и сопровождения модулей приложения, отвечающих за доступ к данным. Репутация Oracle Corporation как компании-разработчика СУБД основана на полнофункциональном высокопроизводительном сервере RDBMS. Начав с СУБД, краеугольного камня своей производственной деятельности, Oracle Corp. превратилась в нечто большее, чем просто компания, разрабатывающая СУБД. Теперь сервер RDBMS дополняется разнообразными хорошо интегрированными программными продуктами, которые созданы специально для организации распределенной обработки данных и разработки приложений клиент/сервер. По мере того как сервер базы данных Oracle развивается, ориентируясь на поддержку крупномасштабных ("уровня предприятия") систем обработки транзакций и поддержки принятия решений, корпорация Oracle также разрабатывает другие программные продукты, что позволяет предлагать завершенные решения для развертывания приложений клиент/сервер. В этой главе содержатся краткие сведения об особенностях СУБД в среде клиент/ сервер и об архитектуре программных продуктов Oracle, которая поддерживает их реализацию.
4. Краткий обзор обработки данных в среде клиент/сервер
Основная идея среды клиент/сервер состоит в распределении выполняемой задачи между несколькими процессорами в сети. Каждый процессор предназначен для определенного набора подзадач, с которыми он справляется наилучшим образом, а конечный результат выражается в увеличении производительности и эффективности системы в целом. Распределение выполнения задач между процессорами осуществляется с использованием протокола сервисных запросов; один процессор, клиент, запрашивает обслуживание у другого процессора, сервера. Чаще всего при построении систем клиент/сервер часть приложения, отвечающая за пользовательский интерфейс, отделяется от части, отвечающей за доступ к данным.
Клиент в типичной конфигурации клиент/сервер -- это автоматизированное рабочее место, использующее графический интерфейс (Graphical User Interface - GUI), обычно Microsoft Windows, Macintosh или Motif. Сервером является сервер базы данных, часто управляемый операционной системой UNIX, NetWare, Windows NT или VMS.
Архитектура клиент/сервер также может быть построена в конфигурации сервер-сервер. В этой компоновке один сервер играет роль клиента, который запрашивает данные (или вообще "сервис") у другого сервера. Несколько серверов базы данных могут образовывать единую логическую базу данных, обеспечивая прозрачный доступ к данным, которые распределены по сети.
Цель проектирования эффективного приложения клиент/сервер -- равномерно распределить задачи между процессорами при оптимальном использовании имеющихся ресурсов. Учитывая возрастающую сложность и соответственно требуемую вычислительную мощность для поддержки графического интерфейса пользователя (GUI), а также возрастающие требования к производительности серверов баз данных и сетей, поиск соответствующего распределения задач становится проблемой. Разработка и поддержка системы клиент/сервер более трудна по сравнению с традиционной централизованной системой по следующим причинам:
- Компоненты системы клиент/сервер распределяются по процессорам различных типов. Имеется также множество компонентов программного обеспечения, которые выполняют функции клиентов, сетей и серверов. Эти функции должны быть распределены по нескольким уровням инфраструктуры и соответствующим образом сконфигурированы, чтобы обеспечивалась правильная совместная работа.
- Приложения, работающие с GUI, значительно сложнее своих предшественников, работающих с алфавитно-цифровыми терминалами. GUI способен представить пользователю намного больше информации и предлагает много дополнительных навигационных элементов интерфейса.
- Анализ проблем производительности и ошибок затруднен вследствие большего количества компонентов и уровней в системе.
4.1 Базы данных в архитектуре клиент/сервер
Технологии клиент/сервер изменили облик и архитектуру прикладных систем: существенным изменениям подверглись поддерживающее архитектуру аппаратное, обеспечение, а также сами подходы к проектированию логики приложения.
До появления технологии клиент/сервер большинство приложений Oracle функционировало на одной ЭВМ. Обычно приложение, использующее алфавитно-цифровой, интерфейс, обращалось к экземпляру базы данных, работающему на той же машине, и конкурировало с сервером RDBMS за тот же центральный процессор и ресурсы памяти. Одна система отвечала не только за всю обработку базы данных, но также и за выполнение логики приложения. Кроме того, та же система обрабатывала весь обмен с каждым терминалом; все нажатия клавиш и элементы отображения обслуживались тем же процессором, который обрабатывал запросы к базе данных и логику приложения.
Системы клиент/сервер значительно изменили эту архитектуру, переместив все интерфейсные функции и часть обработки приложения с основного процессора системы на процессор клиента.
Наряду с качественным улучшением аппаратных средств, расширение возможностей серверов RDBMS также повлияло на архитектуру приложений. До выпуска 7-й версии RDBMS Oracle обладала не столь изощренными возможностями поддержки логики обработки, необходимой для обеспечения целостности данных. Например, контроль соответствия первичного и внешнего ключей выполнялся приложением. Поэтому база данных чрезмерно зависела от приложения при поддержании целостности, а код приложения становился громоздким и сложным. Следующий рисунок иллюстрирует различия между традиционными централизованными приложениями и приложениями клиент/сервер. Приложения базы данных клиент/сервер могут использовать преимущества Огас1е Server для реализации некоторых функций логики приложения.
До Oracle7 базы данных выполняли на уровне ядра только контроль типа данных, однако с приходом Oracle7 значительная часть логики приложения может выполняться ядром базы данных. Огас1е предоставляет такие возможности, как хранимые процедуры, поддержка ограничений целостности, определяемые пользователем функции и триггеры базы данных. Все это позволяет приложению хранить большое количество бизнес-правил (или семантику модели данных) на уровне базы данных. В результате приложение освобождается для выполнения более тонких задач обработки, таких как управление интерфейсом GUI и взаимодействие с другими приложениями и инструментальными средствами, поддерживающими модель "клиент-сервер". Как показано на рисунке выше, такая СУБД намного более устойчива; она уже не использует код приложения для, поддержания целостности.
4.2 Oracle и обработка данных в среде клиент/сервер
Oracle Corporation стала лидером во внедрении усовершенствованных технологий баз данных клиент/сервер и предлагает средства проектирования, разработки и администрирования БД. Программные продукты Oracle охватывают все основные компоненты архитектуры клиент/сервер:
¦полнофункциональный высокопроизводительный сервер RDBMS, масштабируемый от портативных ЭВМ до мэйнфреймов;
¦средства для разработки и запуска клиентских приложений, поддерживающие несколько сред GUI;
¦программный компонент для организации связи между БД на различных ЭВМ, который обеспечивает эффективную и безопасную связь с помощью широкого набора сетевых протоколов.
Программные продукты, предлагаемые Oracle, высоко масштабируемы, что позволяет строить законченные приложения в диапазоне от задач небольшой рабочей группы до глобальных систем уровня предприятия.
5. Сервер СУБД Oracle
Oracle Server - полнофункциональная RDBMS, которая идеально подходит для сложных сред клиент/сервер. Особенности внутренней архитектуры Oracle ориентированы на обеспечение готовности, максимальной пропускной способности, безопасности и эффективного использования ресурсов компьютеров. Oracle также присущи черты, связанные с используемым языком программирования, которые способствуют ускорению разработки и улучшению эффективности серверной части приложений:
- Язык PL/SQL. Главный компонент Oracle Server - его процессор PL/SQL. (PL -- Procedural Language - процедурный-язык.) PL/SQL - язык Oracle четвертого поколения, объединяющий структурированные элементы процедурного языка программирования с языком SQL. PL/SQL разработан специально для организации вычислений в среде клиент/сервер. Он позволяет передать на сервер программный блок PL/SQL, содержащий логику приложения, как оператор SQL, одним запросом. Используя PL/SQL, можно значительно уменьшить объем обработки в клиентской части приложения и нагрузку на сеть. Например, может понадобиться выполнить различные наборы операторов SQL в зависимости от результата некоторого запроса. Запрос, последующие операторы SQL и операторы условного управления могут быть включены в один блок PL/SQL и пересланы серверу за одно обращение к сети.
PL/SQL широко используется в этих инструментальных средствах для разработки выполняемых клиентской частью приложения процедур и подпрограмм-триггеров. Общность языка программирования клиентской и серверной частей приложения обеспечивает большую гибкость. Синтаксис языка клиента расширен средствами управления пользовательским интерфейсом, обращения к объектам-формам и навигации.
- Хранимые процедуры. Версия 6 Oracle поддерживала работу PL/SQL на сервере. Oracle 7 позволяет, хранить блоки PL/SQL как объекты базы данных в форме хранимых процедур, функций и пакетов. Часть логики приложения, особенно нуждающаяся в доступе к базе данных, может храниться там, где она обрабатывается (на сервере). Использование хранимых процедур значительно увеличивает эффективность системы клиент/сервер по нескольким причинам:
а) вызов хранимой процедурой из приложения-клиента порождает минимальный сетевой трафик. Приложению не нужно передавать весь программный блок PL/SQL от клиента к серверу; требуется единственный вызов процедуры или функции со списком параметров;
б) хранимые процедуры обеспечивают удобный и эффективный механизм безопасности. Одна из характеристик хранимого PL/SQL -- он всегда выполняется с привилегиями владельца процедуры. Это позволяет непривилегированным пользователям получать контролируемый доступ (через код процедуры) к привилегированным объектам.
Эта возможность обычно используется, чтобы уменьшить объем администрирования привилегиями, которое должен выполнить DBA.
в) откомпилированные хранимые процедуры и их исходные тексты содержатся в базе данных. Так как откомпилированная процедура готова к исполнению, потребность в разборе и компиляции, блоков PL/SQL на этапе выполнения сводится к минимуму.
- Триггеры базы данных. Похожи на хранимые процедуры тем, что они являются блоками PL/SQL, резидентными в базе данных; различие между ними в том, что триггеры запускаются автоматически ядром RDBMS в ответ на события, образующие транзакцию (такие как операции вставки, модификации или удаления). Можно использовать триггеры, чтобы организовать сложный контроль целостности, выполнять протоколирование (аудит) и другие функции безопасности, реализовать в приложениях выдачу предупреждений и мониторинг. Подобно хранимым процедурам, триггеры базы данных значительно уменьшают объем кода и обработки, необходимых для клиентской части приложения.
Реализация триггеров базы данных Огас1е несколько отличается от принятой у других разработчиков. В большинстве баз данных триггеры поддерживаются на уровне всего оператора языка SQL. Огас1е также предоставляет функциональную возможность запуска триггеров на уровне, одной строки таблицы. Рассмотрим оператор UPDATE, который обновляет значения в наборе из 100 строк. Ядро запустило бы на выполнение триггер уровня оператора лишь однажды для всего оператора (до и/или после того, как оператор выполняется). Триггер уровня строки, с другой стороны, запускается ядром для каждой строки, на которую воздействует оператор -- 100 раз. Oracle позволяет применять триггеры уровня оператора и уровня строки совместно.
- Декларативная целостность. Когда определяется таблица в Огас1е, ограничения целостности могут быть заданы как часть определения таблицы. Ограничения активизируются сервером всякий раз, когда записи вставляются, обновляются или удаляются. В дополнение к ограничениям ссылочной целостности, которые проверяют соответствие первичного и внешнего ключей, можно также накладывать ограничения на значения, содержащиеся в столбцах таблицы.
Поддержка целостности на сервере уменьшает размер кода клиентской части, необходимого для проверки допустимости данных, и увеличивает устойчивость бизнес-модели, определенной в базе данных. С помощью ограничений часто можно повысить производительность и обеспечить гибкость при работе с несколькими внешними пользовательскими интерфейсами.
- Функции, определяемые пользователем. Блоки PL/SQL также применяются в функциях, определяемых пользователем. Такие функции подобны хранимым процедурам и также уменьшают объем кода клиентской части приложения. Эти функции можно не только вызывать из PL/SQL, но и расширять ними стандартный набор функций Oracle SQL.
Проектирование приложения Oracle с использованием возможностей сервера повышает эффективность системы клиент/сервер и упрощает саму задачу разработки и развертывания приложения.
6. Сетевое программное обеспечение
В системе клиент/сервер на основе Oracle для обеспечения связи между узлами сети, вероятно, будут использоваться программные средства Oracle. Ряд программных продуктов и инструментальных средств упрощают задачу подключения приложений-клиентов к серверам баз данных через сеть.
¦SQL*Net. Программное обеспечение, которое выполняет оптимальную, надежную передачу сообщений базы данных в сети, использующей любые популярные сетевые протоколы. SQL*Net предназначено для обеспечения прозрачности расположения сервера в сети и использует компоненты, которые расположены как на клиенте, так и на сервере приложения.
В дополнение к обеспечению соединений между рабочими станциями и серверами в среде клиент/ сервер, SQL*Net также используется для поддержания связи между серверами при обработке распределенных транзакций, удаленных вызовах процедур и тиражировании (репликации) таблиц. Серверы обращаются к другим серверам, используя механизм "связи баз данных" (database link), определяющий имена удаленных баз данных, узлы сети, через которые эти базы данных обслуживаются, и сетевой протокол, применяемый для обращения к удаленным узлам. Механизм связи баз данных упрощает распределенную обработку, обеспечивая прозрачный доступ к удаленным объектам, таким как таблицы и процедуры, позволяя приложениям обращаться к ним точно так же, как если бы они находились в локальной базе данных приложения.
¦Oracle Names. С выпуском версии 7.1 Огас1е появилась возможность делать доступной во всей сети информацию о связях баз данных и об узлах сети, используя общий глобальный словарь Oracle Names. Эта возможность особенно эффективна для больших сетей из многих узлов.
¦Multi-Protocol Interchange. В то время как SQL*Net версии 1 обеспечивает соединения между узлами; с одним сетевым протоколом, SQL*Net версии 2 позволяет связать базы данных, находящиеся в узлах разных сетей, работающих с различающимися сетевыми протоколами. Multi-Protocol Interchange (MPI) обеспечивает связь, транслируя сообщения SQL*Net из одного протокола в другой. Например, автоматизированное рабочее место клиента в ЛВС с Token-Ring может "прозрачно" обратиться к серверу в сети DECnet или TCP/IP, изолируя приложение от сложностей поддерживающей его сетевой инфраструктуры. Кроме мультипротокольной коммуникации, MPI выполняет маршрутизацию сообщений по критерию наименьших издержек и использует альтернативные маршруты, когда оптимальные пути в сети недоступны.
¦Oracle Network Manager. Сложная задача конфигурирования и управления топологией сети распределенной базы данных упрощается с Network Manager, средством администрирования SQL*Net с графическим интерфейсом. Network Manager используется не только для управления словарем Oracle Names, но также для генерирования файлов конфигурации клиентских и серверных компонентов SQL*Net, и описания маршрутов соединения узлов для Multi-Protocol Interchange.
7. Инструменты разработки систем клиент/сервер
Кроме сервера СУБД и сетевого ПО, Oracle предлагает ряд продуктов с графическим интерфейсом для разработки клиента, что логически завершает его интегрированную архитектуру клиент/сервер. Эти комплекты программных продуктов включают полнофункциональные инструментальные средства автоматизированн6го проектирования программного обеспечения (Computer Assisted Software Engineering -- CASE), объектно-ориентированные среды разработки и компоненты времени выполнения, которые, могут работать c_Огас1е Server, а также с другими базами данных SQL.
1) Designer/2000. Для разработки сложных приложений среда CASE Designer/2000 предоставляет репозитарий (repository -- хранилище) и мощный набор инструментальных средств, который позволяет выполнять анализ, моделирование, проектирование и генерацию как клиентских, так и серверных компонентов приложения.
Designer/2000 -- сложный инструмент с широкими возможностями. Если его освоить, то задача разработки сложного приложения решается быстрее и намного эффективнее, чем с использованием традиционных методов разработки. Информация, собираемая с помощью графических диаграмм, моделирующих данные и приложение, используется для генерирования сложных, свободных от ошибок определений данных и приложений. Designer/2000 генерирует полнофункциональное приложение для инструментальных средств Developer/2000, содержащее меню, средства обеспечения безопасности и управления транзакциями, возможности использования OLE-контейнеров. Генераторы приложений разработаны для Visual Basic и Power Objects.
2) Developer/2000. Пакет Developer/2000 организует Oracle Forms, Oracle Reports, Oracle Graphics и Oracle Book в единую интегрированную среду разработки. Можно создать приложение, используя только эти инструментальные средства, или применять их вместе с Designer/2000, чтобы автоматически генерировать формы и отчеты.
Инструментальные средства Developer/2000 используют PL/SQL в качестве языка написания программ. Приложения, разработанные на одном программно-аппаратном типе платформы, могут работать на других платформах (Microsoft Windows, Macintosh и Motif).
3) Power Objects. В дополнение к Designer/2000 и инструментальным средствам Developer/2000, комплект программных продуктов Oracle включает другую объектно-ориентированную среду разработки приложений Power Objects, который предоставляет среду быстрой разработки приложений с большим количеством элементов технологии перетаскивания (drag-and-drop) и автоматическим управлением транзакциями.
8. Развитие Oracle
Oracle Corporation продолжает оставаться лидером, внедряющим новые технологии, которые обеспечивают расширенные функциональные возможности и лучшие средства для управления, разработок, коммуникаций и производительности масштабируемых систем баз данных клиент/сервер. Вот некоторые из этих технологии:
1) Беспроводные системы клиент/сервер. Oracle представила средства связи и передачи сообщений, которые поддерживают удаленный доступ в системах клиент/сервер. Эта технология, которая работает в сотовых сетях передачи данных, особенно полезна пользователям портативных ЭВМ. В продукте Oracle Mobile Agents реализована архитектура "клиент-агент-сервер", которая позволяет клиенту работать автономно и периодически соединяться через сеть, чтобы посылать запросы и получать результаты от сервера. Компонент "агент" этой архитектуры функционирует в сети от имени клиента в его отсутствие.
2) Интерфейс Internet/World Wide Web. Oracle Web Interface Kit предназначен для интеграции серверов World Wide Web с базами данных Огас1е. В состав ПО входят утилиты для создания Web-страниц и связывания с ними данных Огас1е, обеспечивая для пользователей Web-возможность помещения данные в БД Oracle, а также их выбора.
3) Multimedia Server. По мере того как в приложениях используются все более разнообразные типы данных, особенно мультимедиа-данные, технологии сервера базы данных также соответствующим образом развиваются. Эта быстродействующая технология высокопроизводительного сервера поставляет "видео по запросу" потребителям.
9. Общий обзор архитектуры Oracle
Сведения об архитектуре Oracle, относятся ко всем платформам, на которых работает Oracle. Отличия в платформах обусловливают отличия в архитектуре, но основа всюду одна.
Что такое база данных?
База данных -- собрание данных, между которыми существуют (смысловые) связи. Эти данные используются вместе одной или несколькими прикладными системами. Физическое расположение и реализация базы данных прозрачны для прикладных программ; физическую базу данных можно перемещать и реорганизовывать и это не окажет влияния на работоспособность программ.
Следующий рисунок иллюстрирует понятие базы данных, содержащей данные для многих (возможно, несвязанных) приложений.
Физически база данных Oracle -- не более чем набор файлов где-то на диске. Расположение этих файлов несущественно для функционирования (хотя важно для производительности) базы данных. Это двоичные файлы, к которым обращаются только через программное обеспечение ядра Oracle. Запрос данных из файлов БД обычно выполняется одним из инструментальных средств Oracle (таких как SQL*Plus), использующих структурированный язык запросов (SQL).
Логически база данных -- это множество пользовательских разделов Oracle, каждый из которых идентифицируется именем пользователя (с паролем), уникальным в данной БД. Таблицы и другие объекты принадлежат некоторому пользователю Oracle. Доступ к СУБД возможен только после регистрации посредством ввода имени и пароля пользователя. Если введенные имя и пароль не проходят проверку на соответствие, доступ к БД не предоставляется. Имя и пароль пользователя СУБД Oracle отличаются от имени и пароля пользователя операционной системы. Например, если база данных работает Ha UNIX машине, то необходимо сначала зарегистрироваться в UNIX, используя имя и пароль для операционной системы UNIX, а затем зарегистрироваться в Oracle и лишь тогда можно "увидеть" объекты базы данных. (Регистрация в UNIX может не требоваться при соответствующей настройке системы клиент/сервер.). Эта процедура регистрации, или подключения к БД, выполняется всегда независимо от того, используются для доступа к серверу-СУБД инструментальные средства Oracle или других изготовителей. Таблицы с одинаковыми именами могут существовать в двух разных учетных разделах Oracle; хотя имя у них одно, это -- разные таблицы. Иногда одну БД (один набор физических файлов базы данных) используют для хранения различных версий таблиц (в отдельных учетных разделах Oracle) для разработчиков, тестирования системы или обучения пользователя; иногда одно имя таблицы используется в различных прикладных системах.
Часто учетный раздел пользователя Oracle называют базой данных, но это не совсем правильно. Можно, например, создать два учетных раздела Oracle, чтобы хранить данные для двух совершенно различных прикладных систем; получились бы две логические базы данных, реализованные в одной физической базе данных.
9.1 Файлы Oracle
Существуют три основные группы файлов на диске, составляющие базу данных.
- Файлы базы данных
- Управляющие файлы
- Журнальные файлы
Наиболее важные из них -- файлы базы данных, где располагаются собственно данные. Управляющие и журнальные файлы поддерживают функционирование архитектуры.
Для доступа к данным БД все три набора файлов должны присутствовать, быть открытыми и доступными Oracle. Если эти файлы отсутствуют, обратиться к базе данных нельзя, и администратор базы данных должен будет восстанавливать часть или всю БД, используя файлы резервных копий (если их сделали!). Все эти файлы двоичные.
9.2 Системные и пользовательские процессы
Для работы с файлами базы данных на машине должны существовать системные процессы Oracle и один (или больше) пользовательский процесс. Системные процессы Oracle (их называют фоновыми) обеспечивают функционирование пользовательских процессов - выполняют функции, которые иначе пришлось бы выполнять пользовательским процессам непосредственно. Чтобы можно было работать с БД фоновые процессы PMON, SMON, DBWR и LGWR должны быть активными. Другие фоновые процессы поддерживают необязательные средства, улучшающие функционирование СУБД.
Дополнительно к фоновым процессам Oracle в простейшем случае на одно подключение к базе данных должен существовать один пользовательский процесс. Пользователь должен подключиться к базе данных прежде чем он сможет обратиться к какому-либо объекту. Если один пользователь регистрируется в Oracle, используя SQL*Plus, другой пользователь выбирает Oracle Forms, а еще один пользователь открывает электронную таблицу Excel, значит имеется три пользовательских процесса для работы с этой базой данных -- по одному для каждого подключения.
9.3 Память
Oracle использует память системы (как реальную, так и виртуальную) для выполнения пользовательских процессов и самого программного обеспечения СУБД, и для кеширования объектов данных. Существуют две главные области памяти Oracle: разделяемая память, которая используется всеми процессами, работающими с базой данных, и локальная память для каждого пользовательского процесса.
9.4 Системная память
Системная память Oracle для всей базы данных называется SGA (system global area -- системная глобальная область или shared global area -- разделяемая глобальная область). Данные и управляющие структуры в SGA являются разделяемыми, и все фоновые процессы Oracle и пользовательские процессы могут к ним обращаться.
Область SGA и фоновые процессы Oracle вместе образуют экземпляр Oracle. Этот термин часто упоминается в литературе no Oracle. Хотя обычно существует один экземпляр для каждой базы данных, нередко запускают много экземпляров (выполняющихся на различных процессорах или даже на различных машинах), и они работают с одним набором файлов базы данных.
9.5 Память пользовательского процесса
Для каждого подключения к базе данных Oracle выделяет PGA (process global area -- глобальную область процесса или program global area -- глобальную область программы) в памяти машины и, кроме того, -- PGA для фоновых процессов. Эта область памяти содержит данные и управляющую информацию одного процесса и между процессами не разделяется.
9.6 Сетевое программное обеспечение и SQL*Net
В простой конфигурации Oracle файлы базы данных, структуры памяти, фоновые и пользовательские процессы располагаются на одной машине без использования сети. Однако намного чаще встречается конфигурация, когда БД расположена на машине-сервере, а инструментальные средства Oracle -- на другой машине (например, PC с Microsoft Windows). При такой клиент/серверной конфигурации машины связываются посредством некоторого сетевого программного обеспечения (не относящегося к семейству ПО Oracle), которое позволяет двум машинам поддерживать связь. Также требуется организовать диалог между двумя базами данных на различных машинах -- например, есть обращение к таблицам из обеих баз данных в одной транзакции или даже в одном операторе SQL. Кроме того, здесь две машины нуждаются в программном обеспечении (разработанном не-Oracle) для организации сети и поддержания связи.
Какой бы тип сетевого ПО и набор протоколов не использовались для связи машин (например, TCP/IP) с целью организации взаимодействия клиент/сервер или сервер-сервер, нужно иметь программный продукт Oracle SQL*Net, который позволяет СУБД Oracle взаимодействовать с сетевым протоколом. SQL*Net поддерживает большинство сетевых протоколов для локальных вычислительных сетей PC (таких как IPX/SPX) и для мэйнфреймов (например, SNA). По существу, SQL'Net является промежуточной программной прослойкой между Oracle и сетевым ПО, обеспечивающей связь между клиентской машиной Oracle Сна которой работает, например, SQL*Plus) и сервером базы данных или между серверами баз данных.
...Подобные документы
Резервные базы данных под управлением Oracle Data Guard. Создание физической резервной базы. Защита резервных копий баз данных и базы данных разработчиков. Восстановление базы данных на удаленной машине. Стратегия резервирования и восстановления.
дипломная работа [499,7 K], добавлен 04.06.2013Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.
презентация [609,2 K], добавлен 14.02.2014Обзор и сравнительная характеристика программного обеспечения для создания СУБД. Принципы организации данных. Основные возможности MS Access. Разработка структуры и реализация средствами SQL базы данных для учета заказов, наличия и продажи автозапчастей.
курсовая работа [2,5 M], добавлен 27.05.2013Анализ реляционных баз данных и способов манипулирования ими. Основные понятия баз данных, архитектура СУБД, модели данных. Модель сущность-связь, характеристика связей, классификация сущностей, структура первичных и внешних ключей, целостности данных.
курсовая работа [166,6 K], добавлен 18.07.2012Инфологическая модель предметной области. Схемы простых объектов и их свойства. Построение реляционных отношений на основе инфологической модели базы данных. Сетевая и иерархическая даталогическая модели БД. Структура таблиц, реализованных в СУБД Oracle.
курсовая работа [1,0 M], добавлен 10.06.2014Базы данных (БД) и системы управления базами данных (СУБД) как основы современной информационной технологии, их роль в хранении и обработке информации. Этапы реализации БД, средств ее защиты и поддержки целостности. Протоколы фиксации и отката изменений.
презентация [364,2 K], добавлен 22.10.2013Анализ данных предметной области. Информационно-логическая модель базы данных. Физическое проектирование и мероприятия по защите и обеспечению целостности базы данных. Приложение интерфейса для SQL-сервера базы данных на языке программирования Delphi.
курсовая работа [2,2 M], добавлен 30.05.2013Объекты модели хранения данных базы данных ORACLE. Взаимосвязь между логическими структурами. Средства манипулирования данными языка SQL, данными языка SQL. Структура выполнения простейших запросов. Формирование критерия отбора. Сортировка данных.
презентация [120,1 K], добавлен 14.02.2014Общая характеристика системы управления базами данных MySQL, ее основные особенности и возможности, касающиеся обеспечения целостности данных. Реализация ограничений семантической и ссылочной целостности в СУБД MySQL на примере фрагмента ИС "Салон магии".
курсовая работа [981,0 K], добавлен 14.10.2012Процесс поступления пациента в больницу. Программное обеспечение, используемое в разработке. Обзор Borland Delphi7, MS SQL Server 2008. Динамическое изменение и расширение структуры базы данных. Обоснование выбора СУБД и программного обеспечения.
курсовая работа [875,4 K], добавлен 21.04.2013Разработка информационного обеспечения для формирования базы данных для государственной итоговой аттестации 9 классов. Обзор методов репликации и синхронизации баз данных. Преимущества алгоритма шифрования Rijndael. СУБД Microsoft SQL Server и Firebird.
дипломная работа [3,3 M], добавлен 27.06.2012Архитектура и функции СУБД. Инфологическая модель данных "Сущность-связь". Ограничения целостности. Характеристика связей и язык моделирования. Манипулирование реляционными данными. Написание сервера на Java.3 и приложения-клиента на ActoinScript 3.0.
курсовая работа [935,3 K], добавлен 09.07.2013Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Характеристика реляционной, иерархической и сетевой моделей баз данных. Анализ методов проектирования (декомпозиция, синтез, объектная связь), организации, обновления, восстановления, ограничений, поддержания целостности данных на примере СУБД Ms Access.
дипломная работа [347,4 K], добавлен 13.02.2010Порядок проектирования и разработки базы данных и программного обеспечения. Информация о структуре базы данных, созданных таблицах, формах, отчетах, запросах, хранимой информации. Логическая и концептуальная модели данных; выбор программного обеспечения.
курсовая работа [906,6 K], добавлен 20.01.2010Определение состава реляционных таблиц и логических связей между ними. Создание схемы (пользователя) базы данных. Особенность получения таблиц и ограничения целостности. Выполнение загрузки, модификации и удаления. Поддержка транзакций в Oracle.
лабораторная работа [4,8 M], добавлен 25.10.2021Понятие базы данных, их цели и задачи, требования к БД; система управления базами данных. Файловые системы: именование и структуры файлов, программное обеспечение. Уровни абстракции в СУБД, функции абстрактных данных. Экспертные системы и базы знаний.
презентация [301,6 K], добавлен 17.04.2013Структура и функции системы управления базами данных (СУБД). Управление хранением данных и доступом к ним. Защита и поддержка целостности данных. Надежность хранения данных во внешней памяти. Классификация СУБД по способу доступа к базе данных.
презентация [3,7 M], добавлен 05.06.2014Определение, свойства и характеристики распределенных систем баз данных. Основная задача систем управления ими. Архитектура распределения СУБД. Сравнение технологий файлового сервера и "клиент-сервера". Стратегия распределения данных по узлам сети ЭВМ.
курсовая работа [601,3 K], добавлен 24.05.2015Изучение основных понятий баз данных: структура простейшей базы данных, компоненты базы данных Microsoft Access. Проектирование базы данных "Туристическое агентство" в СУБД Access 2010, в которой хранятся данные о клиентах, которые хотят поехать отдыхать.
курсовая работа [3,3 M], добавлен 20.09.2013
