ЮЖНО-УРАЛЬСКИЙ МНОГОПРОФИЛЬНЫЙ КОЛЛЕДЖ
ЛЕКЦИИ ПО ТЕОРИИ БАЗ ДАННЫХ
ПМ 02 Инфокоммуникационные системы и сети
МДК 02.02 Разработка и администрирование баз данных
Разработала:
Сухорослова Л.В.
преподаватель ЮУМК
г. Челябинск
2014 год
2
Аннотация:
Лекции разработаны для студентов специальности 230115
«Программирование
в
компьютерных
системах»
для
освоения
профессионального модуля «Разработка и администрирование баз данных».
Профессиональный модуль предусматривает освоение следующих
профессиональных компетенций:
ПК 1.1. Выполнять разработку спецификаций отдельных компонент.
ПК 1.2. Осуществлять разработку кода программного продукта на
основе готовых спецификаций на уровне модуля.
ПК 1.3. Выполнять отладку программных модулей с использованием
специализированных программных средств.
ПК 1.4. Выполнять тестирование программных модулей.
ПК 1.5. Осуществлять оптимизацию программного кода модуля.
ПК 1.6. Разрабатывать компоненты проектной и технической
документации с использованием графических языков спецификаций.
Лекции разработаны с использованием учебной литературы по теме
«Базы данных». Включают сложные для понимания темы по теории баз
данных, такие как:
 проектирование базы данных;
 понятие реляционной базы данных;
 понятие ключевого элемента;
 нормализация базы данных.
Информация иллюстрирована схемами и рисунками для облегчения
восприятия и усвоения знаний по данному курсу.
3
СОДЕРЖАНИЕ:
1. Введение. Основные понятия и определения.
2. Архитектура баз данных.
3. Реляционная модель баз данных.
4. Теория проектирования БД.
5. Приведение БД к уровню нормальной формы.
6. Принцип поддержки целостности в реляционной модели БД.
7. Создание взаимосвязанных отношений в БД между таблицами. Понятие
индекса.
8. Управление данными в БД.
9. Создание взаимосвязей.
10.Проект как средство объединения элементов приложения.
11.Основные технологии доступа к данным.
12.Физическая организация удаленных баз данных.
13.База данных — хранилище объектов.
4
Лекция 1.
Тема: ”Введение. Основные понятия и определения.”
План лекции:
1. История развития баз данных.
2. Понятие базы данных и системы управления базами данных –
СУБД
3. Компоненты среды СУБД.
4. Распределение обязанностей в системах с базами данных.
5. Преимущества и недостатки СУБД.
1.История развития баз данных
Теория баз данных - молодая область знаний. Возраст её около 30 лет,
но в наше время такая молодая область практически является обязательной
для изучения студентами всех технических специальностей, тем более
включена в стандарты всех специальностей связанных с подготовкой
специалистов по вычислительной технике.
Одна из основных функций вычислительной техники – это хранение и
быстрая обработка информации. В современном мире информация – это
основа любой организации.
Примеры: супермаркеты, банки, туристические агентства, библиотеки,
учебные заведения, страховые компании, больницы и т.д.
В любой из этих организаций необходима правильно организованная
база данных.
Основные задачи вычислительной техники при работе с информацией:
o Надежное хранение информации в памяти компьютера;
o Выполнение преобразований и вычислений;
o Удобство для пользователя.
2.Понятия Базы данных и Системы управления базами данных
В 1968 году была введена в эксплуатацию первая промышленная СУБД
фирмы IBM. В дальнейшее развитие теории баз данных большой вклад был
сделан американским математиком Э.Ф.Коддом, который является
создателем реляционной модели данных.
Как только компьютеры стали доступнее, появилось множество
программ предназначенных для работы неподготовленных пользователей.
Эти программы были просты в использовании и интуитивно понятны.
Конечно, это сказалось и на работе с системами данных. Появился спрос на
удобные программы обработки данных. Особенности этого этапа
следующие:
1. Все СУБД были рассчитаны на монопольный доступ.
2. Большинство имели развитый и удобный интерфейс, где
существовал интерактивный режим как для создания БД, так и
для обработки данных.
5
3. Отсутствовали средства поддержки ссылочной и структурной
целостности. Эти функции должны были выполняться
пользователем, требуя от него дополнительного контроля.
4. Монопольный режим не требовал администрирования БД.
5. СУБД первого поколения имели очень скромные требования к
аппаратному обеспечению.
Примеры: Dbase, FoxPro, Clupper.
3.Компоненты среды СУБД
В среде СУБД можно выделить 5 основных компонентов:
o Аппаратное обеспечение
o Программное обеспечение
o Данные
o Процедуры
o Пользователи
Аппаратное обеспечение зависит от требований данной организации и
используемой СУБД. Это может быть единственный персональный
компьютер или целая сеть из многих компьютеров. Каждая СУБД
представляет свои требования к объему оперативной и дисковой памяти.
Чаще всего используется архитектура клиент-сервер, где сервером
является компьютер с серверной частью СУБД, а клиентом – с клиентской
частью.
Сервер (СУБД)
Клиент
Клиент
клиент
Программное обеспечение включает в себя программное обеспечение
СУБД, прикладные программы, операционную систему, сетевое
программное обеспечение.
Данные самый важный компонент среды СУБД.
База данных содержит как рабочие данные, так и метаданные (т.е.
данные о данных).
Необходимо различать такие понятия как:
o Структура базы данных
o Таблица
o Поля (атрибуты)
o Связь между таблицами (ключи)
6
Метаданные:
o Имена, типы, размеры элементов данных;
o Имена связей;
o Ограничения целостности данных;
o Имена пользователей;
o Используемые индексы и структуры хранения;
Процедуры: правила, которые должны учитываться при
проектировании и использовании базы данных. Например:
o Как правильно регистрироваться в СУБД.
o Использование приложений СУБД.
o Запуск и остановка СУБД
o Создание резервных копий СУБД
o Изменение структуры таблицы, реорганизация базы
данных, методы архивирования данных на вторичных
устройствах хранения.
Пользователи базы данных – это как правило 4 различных группы:
1. Администратор данных
2. Администратор базы данных
3. разработчики программных приложений (прикладные
программисты)
4. разработчики базы данных
5. конечные пользователи.
Распределение обязанностей
Администратор данных:
Отвечает за управление данными, включая планирование базы данных,
разработку и сопровождение стандартов, бизнес правил и проектирование
базы данных.
Администратор базы данных:
Отвечает за физическую реализацию базы данных, включая физическое
проектирование; за обеспечение безопасности и целостности данных, а так
же за максимальную производительность приложений и пользователей.
Разработчики баз данных:
Занимаются идентификацией данных (т.е. сущностей и их атрибутов).
Устанавливают связи между данными, ограничения на хранимые данные,
проектируют любые требуемые меры защиты данных.
Прикладные программисты:
Разрабатывают прикладные программы на созданной базе данных. Эти
программы могут делать расчеты, выборки, анализ на основе базы данных.
Пользователи:
Это клиенты базы данных. Они делятся на два вида:
1. Наивные пользователи – не подозревают о наличие базы данных.
Такие пользователи используют информацию, либо выбирают
информацию из меню или считывают сканером.
7
2. Опытные пользователи – знают структуру базы данных и
возможности СУБД. Они могут для выбора нужной информации
использовать язык запросов или писать свои собственные
прикладные программы.
Лекция 2
Тема: ”Архитектура баз данных”
План лекции:
1. Трехуровневая архитектура организации БД
2. Архитектура многопользовательских СУБД
1. Трехуровневая архитектура организации БД
В процессе научных исследованных посвященных тому, как именно
должна быть устроена СУБД
предлагались различные способы
реализации. Самым жизненным
из них оказалась
предложенная
Американским
комитетом по стандартизации ANSI, трехуровневая
система организации БД
Внешняя
модель данных
Внешняя модель
данных
Внешняя
модель данных
Концептуальный уровень
База
данных
Модель системы управления базой данных состоит из трех уровней:
1 уровень
Уровень внешней модели самый верхний уровень, где каждая модель
имеет свое видение данных каждое приложение видит и
обрабатывает только те данные, которые необходимы этому
приложению.
Пример: система распределения работ видит данные о квалификации
сотрудника,
но ее не интересует сведения о доме, адресе, телефоне
8
2 уровень
Концептуальный уровень – центральное управляющие звено, здесь база
данных представлена в более общем виде который объединяет
данные, используемые
всеми приложениями, работающими с данной базой данных
3 уровень
Физический уровень - собственно данные, расположенные в файлах
или в страничках структурах, расположенных на внешних носителях
информации.
Далее мы познакомимся с различными типовыми архитектурными
решениями, которые возможно
использовать
при
реализации
многопользовательских СУБД:
2.Архитектура многопользовательских СУБД
1.Телеобработка - т. е. вся обработка происходит на одном
компьютере,
а присоединенные
к
нему
компьютеры являются
компьютерными терминалами, т.е. устройствами не способными
самостоятельно функционировать, а только отображают информацию
на экране.
Термин 1
Э
Термин 2
В
М
Термин3
Термин 4
2.Файловый сервер
Файловый сервер содержит файлы, необходимые для работы
приложений и самой СУБД. Базовая часть СУБД и сама СУБД
размещены на отдельных рабочих станциях, файловой сервер
используется как совместно доступный общий диск.
9
Рабочие станции
Рабочие станции
Сервер
Локальная
сеть
База данных
3.Клиент-сервер.
Функция
клиента - управлять пользовательским интерфейсом, т.е.
принимает от пользователя запрос на языке БД типа SQL? генерирует его
и передает серверу. Сервер принимает, обрабатывает запросы к БД
затем представляет полученные данные пользователю.
Сервер(СУБД)
Клиент
Клиент
клиент
Лекция 3
Тема: ”Реляционная модель баз данных”
План лекции:
1.Математическое понятие отношения
2.Реляционная модель данных
1.Математическое понятие отношения:
Реляционная модель впервые была предложена американским ученым
Коддом. Его статья опубликованная в 1970 году «Реляционная модель
данных для больших совместно используемых банков данных» принято
считать поворотным пунктом в истории развития систем баз данных.
Основной структурой данных в модели являются отношения. Именно
поэтому модель получила название реляционной (relation(англ) - отношение).
Физическим представлением отношения
является – таблица.
Математическое понятие отношения выражено определением:
10
N-арным отношением R называют подмножество декартова произведения
D1*D2*…*Dn множеств D1, D2,…, Dn необязательно различных.
Исходные множества D1, D2, …, Dn называются доменами.
Рассмотрим некоторое отношение па примере:
Имеем три домена:
D1 – содержит три фамилии
D2 – набор из двух учебных дисциплин
D3 – набор из трех оценок
D1 = {Иванов, Крылов, Степанов}
D2 = {Информатика, математика}
D3 = {3, 4, 5}
Полное декартово произведение – это набор всевозможных сочетаний из n
элементов каждое, где каждый элемент берется из своего домена.
Используя пример составим полное декартово произведение оно будет
содержать содержит 18 троек, где первый элемент одна из фамилий, второй –
учебная дисциплина, третий – оценка.
<Иванов, информатика, 3>
<Иванов, информатика, 4>
<Иванов, информатика, 5>
<Крылов, информатика, 3>
и т.д. …..
Но в реальности отношение R может содержать гораздо меньше строк, т.к. по
одному предмету ученик может получить не более одной оценки.
Поэтому наше отношение имеет простую графическую интерпретацию и
может быть представлено в виде таблицы:
Фамилия
Иванов
Иванов
Крылов
Крылов
Степанов
Степанов
Дисциплина
Информатика
Математика
Информатика
Математика
Информатика
Математика
Оценка
4
3
5
4
4
4
Таким образом, мы убедились, что любое отношение можно представить в
виде таблицы.
Отношение-это двумерная таблица, имеющая уникальное имя и состоящая из
строк и столбцов, где строки соответствуют записям, а столбцы атрибутам.
2.Реляционная модель данных
11
Хотя в теории баз данных понятия “отношение” и “таблица “ иногда
рассматривают как синонимы, их следует различать : отношением является
не любая таблица, а таблица, обладающая определенными свойствами.
Свойства таблиц являющихся реляционным отношением:
1. В таблице нет двух одинаковых строк
2. Таблица имеет столбцы, соответствующие атрибутам отношения
3. Каждый атрибут в отношении имеет уникальное имя
4. Порядок строк в таблице произвольный.
Итак, в реляционной модели отношения используются для хранения
информации об объектах, представленных в БД.
При этом атрибуты могут располагаться в любом порядке и независимо от их
переупорядочивания, отношение будет оставаться одним и тем же, а потому
иметь тот же смысл.
Реляционная модель представляет базу данных в виде множества
взаимосвязанных отношений, где связи поддерживаются не явным образом
Первичный ключ – это потенциальный ключ, который выбран для
уникальной идентификации картежей внутри отношений.
Внешний ключ – это атрибут
отношения, который соответствует
первичному ключу некоторой таблицы в базе данных.
Если некоторый атрибут присутствует в нескольких таблицах, то его наличие
отражает определенную связь между данными этих таблиц.
Лекция 4
Тема: “Теория проектирования БД”
План лекции:
1. Этапы проектирования БД.
2. Построение информационной модели. Определение сущностей.
3. Определение взаимосвязей.
4. Понятие ключевого элемента. Задание первичных ключей.
1.Этапы проектирования БД
При создании БД необходимо выполнить строго определенную
последовательность действий, называемых этапами проектирования.
Поскольку
база
данных
является
связующим
звеном
между
пользовательскими приложениями и аппаратными средствами, ее
проектирование можно разделить на два направления: проектирование
структуры и пользовательских приложений и распределение данных по
12
аппаратным средствам (в случае баз данных на сетях). В данном разделе мы
рассмотрим вопросы проектирования структуры базы данных. В дисциплине
АСОЭИ, рассматривая основы реляционной алгебры и разработки
реляционных моделей, мы коснулись вопросов проектирования реляционных
баз данных. Одной из распространенных технологий разработки БД является
следующая:
1. Построение информационной модели и определение сущностей;
2. Определение взаимосвязей между сущностями;
3. Задание первичных и альтернативных ключей;
4. Приведение модели к требуемому уровню нормальной формы;
5. Физическое описание модели.
2.Построение информационной модели. Определение сущностей.
На первом этапе проектирования базы данных ставится задача по
разработке и созданию базы данных, т.е. доказывается актуальность
и необходимость использования Базы Данных и определяется круг
задач решаемых при использовании хранимых в ней данных.
Для этого собираются концептуальные требования, на их основе
строится концептуальная модель.
Концептуальное требование – это одно свойство объекта, которое
необходимо хранить в БД. Концептуальные требования зависят от задач,
которые должна выполнять БД.
В общих чертах База данных должна:
– удовлетворять требованиям заказчика, содержать сведения только о тех
объектах, которые интересуют заказчика.
– обладать приемлемым быстродействием.
– иметь возможность последующего расширения без существенной
переделки.
– не зависеть от количества вводимых в неё данных.
– легко перестраиваться при изменении программной и аппаратной
среды.
– содержать только достоверные данные. Достоверность данных должна
обеспечиваться как при вводе новых данных, так и при редактировании
уже имеющихся.
Результатом выполнения первого этапа проектирования БД является
информационная модель данных и список основных сущностей.
Чаще всего под сущность подразумевается отдельный тип объекта реального
мира (человек, вещь, понятие, событие)
Модель “сущность-связь” имеет несколько базовых понятий, которые
образуют более сложные объекты по заранее определенным правилам.
С помощью сущности моделируется класс однотипных объектов. Сущность
имеет имя, уникальное в пределах моделируемой системы. Объект, которому
13
соответствует понятие сущности, имеет свой набор атрибутов, характеристик
или свойств.
Например:
Сущность – сотрудник
Атрибуты – фамилия, имя, отчество, кол-во детей
3.Определение взаимосвязей между сущностями
На этом этапе проектирования определяются направления движения потоков
информации между структурными подразделениями фирмы – заказчика базы
данных, источники получения информации, места её модификации и
потребления.
Результатом выполнения этого этапа проектирования будет функциональная
схема движения потоков информации между подразделениями фирмы.
Группа
планирования
Группа
маркетинга
Торговая
группа
Материальная
группа
Взаимосвязи в БД
Существует 3 вида взаимосвязей по множественности:
1. Взаимосвязь «один к одному», т.е. экземпляр одной сущности может
быть связан только с одним экземпляром другой сущности.
Пример:
личность
паспорт
2. Взаимосвязь «один ко многим»,т.е. один экземпляр сущности может
быть связан с несколькими экземплярами другой сущности
клиент
авто
3. Взаимосвязь «многие ко многим», т.е. один экземпляр первой
сущности может быть связан с несколькими экземплярами второй
сущности и наоборот один экземпляр второй сущности связан с
несколькими экземплярами первой сущности.
студент
преподаватель
4.Понятие ключевого элемента. Задание первичных ключей
14
Как мы уже знаем, каждая таблица БД содержит информацию о свойствах
некоторого объекта или сущности. Для того, чтобы осуществить поиск
необходимых данных надо установить связи между таблицами с помощью
ключевого элемента – атрибута, по значению которого можно определить
значения других атрибутов.
Т.о. хорошо разработанная таблица должна содержать столбец или несколько
столбцов уникально идентифицирующих каждую запись. Такой столбец
является ключевым полем.
Различают три вида ключевых элементов:
Первичный (Primary) – уникальный атрибут или группа атрибутов,
который определяет каждую запись таблицы.
Альтернативный ключ – отличный от первичного, но тоже уникальный, он
также определяет запись таблицы.
Если база данных содержит более одной таблицы, то они связаны между
собой с помощью внешнего ключа.
Внешний ключ - это столбец ссылающийся на первичный ключ другой
таблицы и связывающий таким образом две таблицы.
Чтобы определить связь между таблицами необходимо чтобы был общий
ключевой элемент.
Лекция 5.
Тема:”Приведение БД к уровню нормальной формы”
План лекции:
1. Нормализация отношений в БД.
2. Три основных уровня нормальной формы.
1.Нормализация отношений в БД.
Классическая технология проектирования реляционных баз данных связана с
теорией нормализации, основанной на анализе функциональных
зависимостей между атрибутами отношений. Функциональные зависимости
(связи) определяют устойчивые отношения между объектами и их
свойствами.
Каждой нормальной форме соответствует некоторый определенный набор
ограничений и отношение находится в нормальной форме, если
удовлетворяет свойственному ей набору ограничений.
Основные свойства нормальных форм:
–
Каждая следующая нормальная форма улучшает свойства предыдущих.
–
При переходе к следующей нормальной форме свойства предыдущих
нормальных форм сохраняются.
15
2.Три уровня нормальной формы
Всего существует 5 нормальных форм таблицы. Рассмотрим 3 первые и
основные из них
Первая нормальная форма (1NF)
Отношение находится в первой нормальной форме, если:
–
на пересечении каждого столбца и каждой строки находится только
элементарное значение атрибута, или каждое поле неделимо.
–
отсутствуют повторяющиеся поля или группы полей.
Пример: Расписание (ненормализованное отношение)
Преподаватель День недели Номер пары
Дисциплина
Петров
Пн
1
Математика
Вт
1
Геометрия
Ср
2
Геометрия
Иванов
Пн
2
Информатика
Вт
3
Технология
Ср
4
Информатика
Группа
10
11
12
11
10
12
Чтобы привести таблицу к уровню первой нормальной формы необходимо
прописать фамилию преподавателя для каждой записи таблицы.
Вторая нормальная форма.(2NF)
Отношение находится во 2 нормальной форме, если:
–
Выполняется условие 1 нормальной формы.
–
Первичный ключ однозначно определяет всю запись.
–
Все поля зависят от первичного ключа.
–
Первичный ключ не должен быть избыточным.
Пример:
Рассмотрим отношение моделирующее сдачу студентами текущей сессии.
Набор атрибутов:
–
ФИО
–
Номер зачетки
–
Группа
–
Дисциплина
–
Оценка
Первичный ключ – номер зачетной книжки, т.к. однозначно определяет
каждую строку.
По условию 2НФ от ключа должны зависеть все атрибуты, т.к. оценка и
дисциплина не зависят от номера зачетной книжки.
Имеем пример неполной функциональной зависимости.
16
Для приведения отношения ко 2 НФ следует разбить его на проекции, при
этом должно быть соблюдено условие восстановления исходного отношения
без потерь. Получаем 2 отношения:
ФИО, номер зачетной книжки, Группа
Номер зачетной книжки, дисциплина, оценка.
Третья нормальная форма (3NF)
Отношение находится в третьей нормальной форме тогда и только тогда,
когда оно находится во 2 нормальной форме и не содержит транзитивных
зависимостей, т.е. каждое не ключевое поле не должно зависеть от другого не
ключевого поля.
Пример:
Рассмотрим отношение связывающее студентов с группами, факультетами и
специальностями, на которых они учатся.
ФИО, номер зачетной книжки, Группа, факультет, специальность, кафедра.
Создать набор нормализованных отношений, если одну специальность могут
выпускать разные кафедры.
При выполнении третьей нормальной формы должны быть разрушены
транзитивные связи внутри каждой таблицы. При этом зависимые
неключевые поля выделяются в отдельную таблицу, с обязательным
добавлением первичных ключей, для связи с другими таблицами.
В процессе нормализации получим 3 таблицы:
Атрибуты 1 таблицы: ФИО, Специальность, Группа
Атрибуты 2 таблицы: Кафедра, Группа
Атрибуты 3 таблицы: Кафедра, Факультет
Лекция 6.
Тема: ” Принцип поддержки целостности в реляционной модели БД.”
План лекции:
1. Понятие целостности базы данных
2. Задание ограничений целостности.
1.Понятие ссылочной целостности
Понятие целостности является одним из основополагающих понятий в
технологии баз данных.
Это понятие связано с тем, что база данных отражает некоторый объект
реального мира в информационном виде. В реляционной модели объекты
реального мира представлены в виде совокупности взаимосвязанных
отношений.
Под целостность будем понимать соответствие информационной модели
объектам реального мира в каждый момент времени. Т.е.в Базе Данных
должны содержаться только достоверные данные. Также необходимо
17
отслеживать только существенные, т.е. значимые изменения предметной
области.
Например, в информационной системе «библиотека» если не стоит задачи
отслеживать местонахождение книги на конкретном стеллаже, то в БД не
отражен номер стеллажа и полка. В данной ситуации важен факт наличия
каждого экземпляра в библиотеке на данный момент времени.
В модели данных должны быть предусмотрены средства, которые позволят
получить объективную информацию в любой момент времени.
Поддержка целостности в реляционной модели данных в ее классическом
понимании включает в себя 3 аспекта.
Во-первых, это поддержка структурной целостности, которая требует того
что реляционная СУБД должна допускать работу только с однородными
структурами данных типа «реляционное отношение», т.е. в нем отсутствуют
повторяющиеся картежи, нет упорядоченности картежей и обязательно
наличие первичного ключа.
Во-вторых – поддержка языковой целостности, которая состоит в том, что
реляционная
СУБД
должна
обеспечивать
языки
описания
и
манипулирования данными не ниже стандарта SQL.
В-третьих – поддержка ссылочной целостности, которая означает
обеспечение одного из принципов взаимосвязи:
– Картежи подчиненного отношения уничтожаются при удалении
картежа основного отношения, связанного с ними.
– Картежи основного отношения модифицируются при удалении картежа
основного отношения, связанного с ним, при этом на месте ключа
родительского отношения ставится неопределенное (NULL) значение.
Ссылочная целостность обеспечивает поддержку непротиворечивого
состояния БД в процессе модификации данных, при выполнении операций
добавления и удаления.
2.Задание ограничений целостности базы данных.
Структурная, языковая и ссылочная целостность определяют правила работы
СУБД с реляционными структурами данных. Требования поддержки этих
трех видов целостности должна уметь делать каждая СУБД, а разработчики
должны это учитывать при построении БД.
Вообще, ограничения целостности данных представляют собой такие
ограничения, которые вводятся с целью предотвратить помещение в базу
противоречивых данных.
Рассмотрим следующие типы ограничений целостности данных:
- Обязательные данные
- Ограничения для доменов атрибутов
18
- Целостность сущностей
- Ссылочная целостность
Обязательные данные - т.е. некоторые атрибуты всегда должны содержать
одно из допустимых значений и не могут иметь пустого значения.
Задать это ограничение, значит при формировании структуры таблицы
такому атрибуту установить проверку возможными для конкретной
программы способами.(пример: поле должность сотрудника не может быть
пустым).
Ограничения для доменов атрибутов – некоторые атрибуты имеют
множество допустимых значений. Например поле «пол» может иметь одно
из двух допустимых значений «м» или «ж». Данные ограничения
устанавливаются при определении доменов атрибутов присутствующих в
модели данных.
Целостность сущностей – первичный ключ любой сущности не может
иметь пустое значение. Подобные ограничения должны учитываться при
определении первичных ключей.
Ссылочная целостность- это ограничение означает, если внешний ключ
содержит некоторое значение, то оно обязательно должно присутствовать в
родительской таблице. Важная проблема связанная с поддержкой ссылочной
целостности, это ее поддержка при операциях вставки, обновления или
удаления первичного или внешнего
ключей. Существует несколько
стратегий обработки попыток удаления строки родительского отношения,
которые однозначно приведет к нарушению целостности отношения. При
создании базы данных необходимо воспользоваться функциями для
поддержки ссылочной целостности:
- CASCADE (при удалении первичного ключа удаляются все строки из
дочерних таблиц связанные по удаляемому ключу)
- RESTRICT (блокирует удаление ключа если есть связанные по нему
данные)
- NO ACTION (не контролируются связи)
Лекция 7.
Тема: ”Создание взаимосвязанных отношений в БД между таблицами.
Понятие индекса”
План лекции:
1. Понятие индексного файла
2. Создание индексов. Типы индексов.
1.Понятие индексного файла
Взаимосвязь между таблицами осуществляется по индексам, которые
называются ключами.
19
Индекс – это указатель записи и представляет собой порядковый номер
записи в таблице.
Индекс - строится по значению одного поля или по значению нескольких
полей.
Индекс, построенный по значению одного поля называется простым, а
индекс построенный по значению нескольких полей – сложным.
Во время построения индекса, записи в таблице сортируются по значениям
поля (или полей) будущего индекса. При этом первой строке таблицы
присваивается индекс №1, второй строке – индекс №2 и т.д. до конца.
Построенный индекс хранится в специальном файле, который называется
индексным.
Если индексный файл хранит только один индекс, то он называется
одноиндексным и имеет расширение *.idx. Индексные файлы, которые
хранят несколько индексов, называются мультииндексными и имеют
расширение *.cdx.
Каждый индекс, который хранится в мультииндексном файле называется
тегом. Каждый тег имеет свое уникальное имя.
Мультииндексные файлы бывают двух типов: простые мультииндексные
файлы и структурные мультииндексные файлы, которые имеют одинаковое
имя с таблицей, которой он принадлежит (отличие только в расширении
файла) и обладает следующими свойствами:

Автоматически открывается со своей таблицей.

Его нельзя закрыть, но можно сделать не главным.
Одна таблица может иметь много индексных файлов как одноиндексных, так
и мультииндексных.
2.Создание и установка индексных файлов с помощью команд.
Создать индексный файл можно с помощью команды:
Index on (идентификатор выражения) to <имя ind файла>
TAG <имя тега> [of <cdx-файл>]
FOR (условие)
COMPACT
DESCENDING
UNIQUE
ADDITIVE
NOOPTIMIZE
Индексное выражение – имя поля (или полей), по значениям которых надо
строить индекс
При построении сложного индекса имена полей перечисляются через знак
«+»

Если сложный индекс построен по числовым полям, то индекс
строится по сумме значений полей.
20

Если индекс строится по символьным полям, то индекс строится
сначала по значению 1 поля, при повторяющихся значениях 1 поля, по
значению второго поля при повторяющемся значении 2 по значению третьего
поля и т.д.
Длина идентификатора выражения не должна превышать 254 символа.
TO <idx-файл> указатель имени одноиндексного файла
TAG <имя тега> OF <cdx-файл> указатель имени тега в мультииндексном
файле

По полям разных типов, сначала значения полей приводится к одному
типу, как правило символьному, а затем строится индекс.
TO <idx-файл> имя одноиндексного файла
TAG <имя тега> [OF <cdx-файл>] указатель имени тега в мультииндексном
файле.
Если используется опция [OF<cdx-файл>], то создаваемый тег помещается в
указанный мультииндексный файл, если требуемый мультииндексный файл
отсутствует, то будет построен структурный мультииндексный файл.
Если опция [OF <cdx-файл>] опущена, то созданный тег будет помещен в
текущий мультииндексный файл.
Ключевые слова:
FOR (условие) устанавливает режим отбора в индекс тех записей таблицы,
которые удовлетворяют условию
DESCENDING строит индекс по убыванию. По умолчанию установлено
ACCENDING (используется только в мультииндексных файлах) для
одноиндексного необходима установка SET COLLATE
UNIQUE строит уникальный индекс (из всех повторяющихся записей в
индекс попадает одна).
ADDITIVE вновь создаваемый индексный файл не закрывает открытые к
этому времени индексные файлы.
Если опция опущена, то созданный индексный файл становится главным.
NOOPTIMIZE отключает используемые технологии RUSHMORE для
ускоренного доступа к данным.
Открыть или установить индексный файл можно только после открытия
соответствующей ему таблицы. В противном случае будет выдано сообщение
об ошибке.
Команда установки индексного файла:
SET INDEX TO (список индексных файлов)
ORDER <выражение №> <ind-файл>
TAG <> OF <cdx> ASCENDENG
ADDITIVE
Для закрытия всех инд. файлов надо выполнить команду
SET INDEX TO или CLOSE INDEX
Для каждой таблицы одновременно может быть открыто несколько индексов,
но текущим (активным) будет один.
21
По умолчанию принять, что текущим будет тот, который стоит первым в
команде SET INDEX TO.
Чтобы сделать текущим любой другой надо дать команду
SET ORDER TO <выражение 1> <idx>
TAG <> OF <> IN <выражение 2> <выражение C>
Значение опций:
<выражение 1> задает текущий индекс по его порядковому номеру в
мультииндексном файле.
<idx-файл> делает текущим одноиндексный файл.
TAG <имя тега> OF <cdx> делает текущим по имени тега из указанного
мультииндексного файла.
IN <выражение 2> указывает номер рабочей области, в которой находится
индексный файл. Опция используется в случае, если таблица открыта в
одной рабочей области, а индексный файл в другой.
Текущим индекс можно сделать в приложении в диалоговой панели TABLE
DESIGNER, переместив строку описания нужного индекса на первое место.
Перестройка индексных файлов
При внесении изменений в большие таблицы тратится много времени, т.к.
при внесении каждого изменения заново перестраиваются все открытые
индексные файлы.
Для экономии времени индексные файлы закрывают и вносят изменения в
таблицу. Однако в этом случае возникает несоответствие между обновленной
таблицей и индексными файлами.
Для устранения указанного несоответствия необходимо заново перестраивать
индексные файлы следующим образом:
-открыть все индексные файлы, принадлежащие измененной таблице и
подать команду
REINDEX
Команду действует на все индексные файлы открытые в текущей рабочей
области.
Переиндексировать можно так же, подав команду из главного меню TABLE
→ Rebuild Index.
Лекция 8.
Тема: “Управление данными в БД”
План лекции:
1. Сортировка данных
2. Поиск данных
22
3. Фильтрация данных
1.Сортировка данных.
Сортировать данные в таблице в FoxPro можно двумя способами:
1. в соответствии с индексом
2. с помощью команды SORT
Сортировка в соответствие с индексом – это наиболее удобный вид
сортировки, т.к. для своего выполнения требует мало времени и не требует
дополнительных затрат памяти, а также исключена потеря информации.
Чтобы посмотреть данные в отсортированном виде нужным нам способом
достаточно сделать текущим соответствующий индекс, затем вывести
данные на экран.
Если сортировать данные нужно по полю, для которого нет индексного
файла, пользуются командой
SORT TO <имя файла> OF <имя поля>
ASCENDING
DISCENDING
For (условие)
FIELDS (список полей)
Опция FIELDS указывает, какие поля поместить во вновь созданный файл.
При использовании этой команды на диске дополнительно сохраняется
отсортированный файл. Эта команда используется редко, т.к.
дополнительный файл занимает достаточно много места на диске и для его
создания необходимо дополнительное время
2.Поиск данных.
В FoxPro существует две методики поиска:
– метод последовательного перебора
– метод деления пополам
Для каждой методики поиска предусмотрена своя команда.
Первую методику поиска использует команда LOCATE FOR <условие>
В условии поиска пишется имя поля для поиска значения, далее указывается
один из логических знаков (<, >, <=, >=, =) и само искомое значение.
Если искомое значение имеет символьный тип, то оно указывается в двойных
кавычках. Если искомое значение имеет тип даты, то оно указывается в
апострофах. Числовое значение значками не выделяется.
Если поиск закончился успешно, то курсор устанавливается на найденной
записи.
23
Вывести запись на экран можно командой DISPLAY или BROWSE.
Для поиска следующей записи удовлетворяющей этому условию надо
выполнить команду CONTINUE.
Если таблица имеет индексный файл по искомому полю, можно
воспользоваться вторым методом поиска, для этого необходимо подать
команду
SEEK <искомое значение>
или
FIND <искомое значение>
В этих командах не нужно указывать условие, а только значение, которое
необходимо найти.
3.Фильтрация данных.
Если таблица большая, то работать с ней неудобно. Поэтому производят
фильтрацию данных, т.е. выборку и предъявление на экран группы записей,
отвечающих определенным требованиям.
Существует 2 вида фильтрации:
– ограничение на количество строк
– ограничение на количество полей
Для установки фильтра данных используют команду
SET FILTER TO <выр L>
В опции выражение L указывают имя поля и его значение, по которому надо
выполнить фильтрацию.
Для восстановления первоначального вида таблицы команду пишут без
опций.
Чтобы вывести не все поля нужно выполнить команду SET FIELDS TO
(список полей).
Лекция 9.
Тема: “Создание взаимосвязей”
План лекции:
1. Понятие рабочей области
2. Установление взаимосвязи в приложении с помощью команд
3. Создание связей с помощью меню
4. Работа с данными в связанных таблицах.
1.Понятие рабочей области.
В современных системах баз данных допускается одновременная работа с
несколькими таблицами. При этом каждая таблица помещается в свою
рабочую область и между таблицами могут быть установлены взаимосвязи.
24
Указатели записей во взаимосвязанных таблицах будут двигаться синхронно.
В старшей (родительской) таблице указатель перемещается произвольно, в
дочерней таблице указатель перемещается в соответствии с перемещением в
старшей.
Если таблица имеет первичный ключ, то она может быть родительской, если
имеет внешний ключ, то может быть дочерней. В один и тот же момент одна
и та же таблица может быть дочерней к одной таблице и родительской к
другой. Допускается подключать к одной старшей таблице несколько
младших.
Перед установлением связей надо выполнить следующие условия:
– Все таблицы должны быть открыты, причем каждая в своей
области.
– Все таблицы попарно должны иметь общее поле (хотя бы одно)
– Для общего поля должен быть построен индекс.
Каждая таблица вместе со своими индексными файлами открывается в
отдельной рабочей области. Рабочие области имеют порядковые номера.
Первые десять рабочих областей имеют однобуквенные имена от A до J.
В FoxPro некоторые команды не могут обрабатывать порядковые имена
рабочих областей, поэтому при открытии табличного файла рабочей области
можно присваивать псевдоним ALIAS.
Желательно в качестве псевдонима присваивать осмысленное сочетание из 3
-4 букв.
В любой момент времени может быть открыто много рабочих областей, но
главной будет одна.
Для назначения текущей рабочей области используют команду
SELECT <номер рабочей области или псевдоним>
Для доступа к полям таблицы следует указывать псевдоним рабочей области,
в которой открыта таблица, затем точка и потом имя нужного поля.
2.Установление взаимосвязи в приложении с помощью команд
Для установления взаимосвязи текущей делают ту рабочую область, где
находится дочерняя таблица и с помощью команды
SET RELATION TO
Подключают одну или несколько таблиц, открытых в пассивной рабочей
области.
SET RELATION TO <выр 1> INTO <псевдоним рабочей области> / <выр 2>
INTO <псевдоним рабочей области>
<выр 1> и <выр 2> - имена общих полей между дочерней таблицей и
несколькими родительскими.
INTO <псевдоним> - псевдонимы рабочих областей, где открыты
соответствующие родительские таблицы.
25
С помощью команды RELATION можно установить взаимосвязь один к
одному, т.е. даже если в дочерней таблице общим полем является внешний
ключ типа REGULAR и имеется несколько записей с одинаковыми
значениями на экран будет выводится только одна запись из дочерней
таблицы.
Для разрыва всех взаимосвязей «один к одному» активной таблицы, надо
подать команду SET RELATION TO без опций.
Если надо разорвать одну конкретную взаимосвязь между активной
(дочерней) таблицей и пассивной (родительской), необходимо подать
команду SET RELATION OF INTO <псевдоним рабочей области>
Взаимосвязь один ко многим устанавливается поверх взаимосвязи один к
одному, т.е. сначала устанавливается взаимосвязь один к одному, затем дают
команду
SET SKIP TO <псевдоним рабочей области>
При этом на экран будет выводиться для одной записи из родительской
таблицы несколько записей дочерней.
Для удаления взаимосвязи «один ко многим» надо подать команду SET SKIP
TO без опций.
3.Создание связей с помощью меню
Установить связи можно с помощью главного меню. Для этого в каждой
таблице предварительно строят первичный и внешний ключи, затем выводят
на экран диалоговую панель TABLE DESIGNER. Курсор мыши нужно
разместить на имени первичного ключа родительской таблицы и вести на
имя соответствующего внешнего ключа дочерней таблицы.
Затем на экран выводится панель EDIT RELATIONSHIP, где надо проверить,
а при необходимости уточнить, параметры взаимосвязи.
После нажатия на кнопке Ok, на экран выводится диалоговая панель
DATABASE DESINER, между именами соответствующих индексов
автоматически прорисовывается прямая линия.
Со стороны один линия начинается с символа +, а со стороны много с
символа - . Обратная буксировка не допустима (от дочерней к родительской).
Тип взаимосвязи устанавливается автоматически в зависимости от типа
индексов.
Если в родительской и в дочерней таблицах индексы уникальны, создается
связь «один к одному». Если в родительской индекс уникальный, а в
дочерней таблице – регулярный, получается связь «один ко многим».
Чтобы редактировать существующую взаимосвязь необходимо вызвать
диалоговую панель EDIT RELATIONSHIP. Для этого установите курсор на
линию связи, щелкните левой кнопкой (линия утолщается). Затем правой
кнопкой вызвать меню, в котором выбрать пункт EDIT RELATIONSHIP.
Для удаления взаимосвязи её надо выделить, а затем нажать на кнопку DEL.
26
Создание ссылочной целостности в приложении.
Выполнение условий ссылочной целостности гарантирует помещение в базу
данных только достоверной информации. Ссылочная целостность
обеспечивается механизмом каскадных воздействий: каскадное удаление и
каскадное редактирование ключевых полей.
Каскадное удаление – это одновременное удаление записи из родительской
таблицы с удалением соответствующих записей из всех дочерних таблиц.
Удаление записи из дочерней таблицы не ведет за собой удаление её из
родительской. Аналогично для редактирования.
Для установления каскадных воздействий надо выделить линию взаимосвязи
левой кнопкой мыши и вызвать на экран меню, выбрав пункт REFERENTIAL
INTEGRITY. На экран выводится диалоговая панель REFERENTIAL
INTEGRITY BUILDER, в которой расположена таблица со следующими
графами:
– Parent Table – имя родительской таблицы.
– Child Table – имена дочерних таблиц.
– UpDate – содержит один из возможных типов каскадного воздействия
при редактировании поля.
– Delete – содержит один из возможных типов каскадного воздействия
при удалении поля.
– Insert – содержит один из возможных типов каскадного воздействия
при вставке поля.
– Parent Tag – содержит имя тега в родительской таблице.
– Child Tag – содержит имя тега в дочерней таблице.
Возможные типы каскадного воздействия:
Cascade – при изменении значения поля первичного или альтернативного
ключа в родительской таблице автоматически выполняется изменение
соответствующего поля в дочерней таблице.
Restrict – запрещает изменение значений полей первичного или
альтернативного ключа в родительской таблице, если в дочерней имеются
соответствующие во внешнем ключе.
Ignore – допускаются любые изменения. Условия ссылочной целостности не
контролируются.
4. Работа в связанных таблицах
Чтобы получить одновременно информацию из разных таблиц, необходимо
выполнить следующие действия. Одна таблица размещается в активной
рабочей области, а вторая – в пассивной. С помощью команды
JOIN WITH (псевдоним пассивной рабочей области)
TO <имя нового файла>
FOR <условие>
27
FIELDS <список имен полей>
будет получен новый (третий) табличный файл, который будет записан по
указанному адресу. В состав его будут включены любые указанные поля из
обеих таблиц, в соответствии с условиями прописанными в операторе FOR.
Особенности выполнения команды:
1. Если в пассивной таблице нет записи с каким-либо значением общего
поля, а в активной таблице такое значение общего поля имеется, то
запись из активной таблицы не помещается в результирующую
таблицу.
2. Если в активной или пассивной таблице имеются записи с
дублирующим значением общего поля, то в результирующий файл
помещается всё.
Корректирование данных в связанных таблицах.
Иногда бывает нужно внести большое количество изменений в одну таблицу,
используя данные из другой таблицы. Для этого корректируемую таблицу
необходимо поместить в активную рабочую область, а таблицу-источник для
исправления данных – в пассивную, и выполнить команду
UPDATE ON <имя общего поля>
FROM <пассивная рабочая область>
REPLACE <имя поля 1 в активной таблице> WITH <выражение 1> <имя
поля 2 в активной таблице> WITH <выражение 2>
ON указывает имя общего поля, причем обе таблицы должны быть
проиндексированы по этому полю в порядке возрастания.
FROM указывает имя поля в активной области, куда надо внести изменения в
соответствии с <выражение 1> указанным в опции WITH и соответственным
по значениям полей пассивной таблицы.
К недостаткам этой команды следует отнести отсутствие контроля на
достоверность данных после внесения изменений.
Для обеспечения достоверности должны быть предприняты дополнительные
меры.
Создание итогового табличного файла
При создании отчетов необходимо иметь итоговые суммы по некоторым
числовым полям.
Команда TOTAL создает итоговый табличный файл, содержащий суммы по
указанным полям.
Предварительный табличный файл должен быть отсортирован по ключевому
полю. При работе команды подсчитывается сумма по указанным числовым
полям, поля других типов копируются в итоговый файл.
Формат команды:
TOTAL ON <имя поля> TO <имя итогового файла>
FIELDS <список имен полей>
FOR <выражение 1>
WHILE <выражение 2>
28
Лекция 10. Проект как средство объединения элементов приложения
План:
1. Создание проекта приложения
2. Управление проектом с помощью меню
3. Задание общих параметров в приложении
Создание проекта приложения
При создании приложения используется проект, который объединяет
элементы приложения VFP и группирует их по типам.
Информация о проекте хранится в специальной таблице, которая в отличие
от обычных таблиц имеет расширение *.pjx.
Мемо-поля таблицы содержат поименованные элементы проекта, его
описание и другие текстовые элементы. Файл с мемо-полями таблицы имеет
расширение *.PJT.
Использование проекта упрощает разработку приложения, т.к. в проекте
базы данных программы, формы, отчеты, запросы и другие элементы
приложения располагаются в соответствующих разделах, а также
запоминается расположение каждого включенного в проект элемента.
Создав проект и определив входящие в него элементы, вы можете
использовать его для сборки приложения, построив файл с расширением
*.APP или для создания исполняющего файла с расширением *.exe.
Для создания нового проекта можно использовать мастер Application Wizard
или дать команду
File → New.
Откроется диалоговое окно с перечислением всех возможных типов
элементов. По умолчанию устанавливается опция Project (проект)
Вкладки окна Project Manager
Вкладка
ALL
DATA
DOCUMENTS
CLASSES
CODE
OTHER
Отображаемые файлы
Все
Базы данных, таблицы, запросы, представления данных,
хранимые процедуры.
Формы, отчеты, этикетки
Классы
Программы
Меню
На следующем уровне находятся типы файлов данной категории. Например,
для категории DOCUMENTS имеются следующие типы файлов:
Forms – формы
29
Reports – отчеты
Labels – этикетки
Некоторые типы файлов могут иметь последующие уровни иерархии.
Например, база данных может содержать таблицы, представления данных, а
каждая таблица – поля.
Управление проектом с помощью меню
При открытии окна проекта в основное меню VFP добавляется новый пункт
меню Project, который содержит команды, позволяющие работать с файлами,
входящими в проект
Назначение команд меню Project
Команда
New File
Add File
Modify File
Browse File
Preview File
Run File
Remove File
Rename File
Set Main
Edit Description
Project info
Errors
Build
Refresh
Clear Un project
Управление элементами проекта
Назначение
Создает новый файл, который
автоматически добавляется в проект
Добавляет в проект ранее созданный
файл
Модифицирует выбранный файл
проекта
Открывает таблицу в режиме Browse
Открывает файл (например отчет) в
окне предварительного просмотра
Запускает файл на выполнение
Удаляет файл из проекта
Переименовывает файл, входящий в
проект
Устанавливает файл в качестве
основной программы
Открывает окна редактирования
описания файла
Отображает информацию о проекте
Отображает ошибки, возникшие при
построении проекта
Строит приложение или
перестраивает проект
Обновляет информацию в окне
проекта
Упаковывает проект, убирая из него
удаленные файлы.
30
Для управления элементами проекта используются кнопки, расположенные в
правой части окна проекта.
Назначение кнопок меню Project
Кнопка
New
Add
Modify
Remove
Run
Preview
Browse
Назначение
Создает новый файл, который
автоматически добавляется в проект
Добавляет созданный ранее файл в
проект
Модифицирует выбранный файл
проекта
Удаляет файл из проекта
Запускает на выполнение
пополняемые файлы
Открывает файл в окне
предварительного просмотра
Открывает таблицу в режиме Обзора
Основные параметры проекта
Вкладки диалогового окна Application Builder
Вкладки
General
Credits
Data
Forms
Reports
Advanced
Характеристика
Основные параметры создаваемого
проекта
Информация об авторах проекта
Параметры создания баз данных и
таблиц
Информация о формах входящих в
проект
Информация об отчетах, входящих в
проект
Параметры создания справочной
системы меню проекта
Вкладка General предназначена для задания таких параметров проекта, как
его имя, размещаемый в проекте рисунок, тип создаваемого приложения,
общие диалоговые окна, значок проекта.
Поле ввода Name позволяет задать имя приложения, отображаемое в его
заголовке, диалоговом окне о программе, а так же внутри программы.
В поле ввода Image можно задать имя файла рисунка, который будет
появляться в окне при запуске приложения и в диалоговом окне о программе.
Область Application Type позволяет задать тип создаваемого приложения
31
Опции Application Type
Опция
Normal
Module
Top Level
Тип приложения
Созданное приложение будет
запускаться в главном окне VFP,
заменяя всё окружение и системное
меню VFP
Приложение добавляется в
существующий проект или будет
вызываться из другого приложения.
Меню приложения добавляется в
системное меню и его функции
используются как компоненты
другого приложения.
Приложение будет запускаться как
отдельное приложение Microsoft
Windows
Назначения флажков группы Common Dialogs
Флажок
Splash Screen
About Dialog
Quick Start
User Logins
Назначение
При запуске приложения появляется
окно, содержащее логотип
приложения и сведения об авторе
Приложение содержит диалоговое
окно о программ, в котором будут
располагаться логотип приложения и
сведения о разработчиках
Проект содержит диалоговое окно
Quick Start, в котором определяются
права доступа к документам
приложения и остальным файлам.
При установлении флажка в проект
добавляется форма предназначенная
для ввода пароля при запуске
приложения
В области Icon можно определить значок приложения
На вкладке Credits указывается следующая информация:
– Autor – список авторов
– Company – предприятие
– Version – номер версии
– Copyright – права
32
– Trade Mark – торговая марка
Вкладка Data позволяет сформировать список баз данных и таблиц,
включенных в проект
Назначение столбцов вкладки
Столбец
Назначение
Data Source
Имя таблицы
Form
Содержит флажок, который
указывает на необходимость
автоматического создания формы для
данной таблицы
Report
Содержит флажок, который
указывает на необходимость
автоматического создания отчета
Кнопки вкладки Data
Кнопка
Назначение
Запускает мастер баз данных
Запускает мастер создания таблицам
Select
Clear
Generate
Открывает диалоговое окно для
выбора уже существующих баз
данных или таблиц
Очищает диалоговое окно от таблиц,
которые были добавлены в проект
При нажатии происходит добавлении
в проект всех размещенных на
вкладке таблиц. Осуществляется
создание форм и отчетов для тех
таблиц, в которых установлены
соответствующие флажки
Списки Form Style, Report Style содержат возможные стили для создаваемых
форм и отчетов.
Вкладка Forms предназначена для создания списка форм проекта.
Назначение флажков и кнопок вкладки Forms
33
Single Instance
Use Navigation toolbar
Use Navigation menu
Appear in File New dialog
Appear in File Open dialog
Пользователь может открыть форму
не более одного раза
При открытии формы на экране
появляется панель инструментов,
позволяющая перемещаться по
записям
Во время выполнения формы в
строку меню добавляется пункт GO,
содержащий команды для управления
работой формы
Имя формы добавляется в список,
вызываемый при выборе команды
New из меню File.
Имя формы добавляется в список,
вызываемый при выборе команды
Open из меню File
Настройка дополнительных параметров проекта
Вкладка Advanced позволяет задать дополнительные параметры настройки
проекта.
Поле ввода Help File используется для указания имени и расположения файла
справки
Default data Directory (каталог данных по умолчанию) отображает название
папки, в которой расположены базы данных и таблиц.
Лекция 11
Тема: “Основные технологии доступа к данным”
План лекции:
1. Система управления передачи данных
2. Распределенные базы данных
3. Процесс прохождения пользовательского запроса.
1. Система управления передачей данных.
Запросы к базе данных от конечных пользователей передаются в форме
коммуникационных сообщений: от рабочей станции пользователя, которая
может быть удалена от самой системы, к некоторому операционному
приложению, а от него к СУБД.
Ответы пользователю так же передаются в форме таких сообщений.
34
Передача этих сообщений происходит под управлением другого
программного компонента – диспетчера передачи данных.
Диспетчер передачи данных – это не часть СУБД, а автономная система со
своими собственными правилами.
Передача данных между отдельными системами (т.е. между отдельными
машинами в сети передачи данных) осуществляется по структуре состоящей
из двух частей:
1. Сервер – машина БД
2. Клиент – машина, содержащая внешний интерфейс.
Сервер поддерживает все основные функции СУБД:
– Определение данных
– Обработку данных
– Защиту и целостность данных.
Поэтому сервер в этом контексте – это просто другое имя СУБД.
Клиент – это различные приложения, которые выполняются, используя
СУБД:
Например:
– приложения написанные пользователями
– программы, с помощью которых осуществляются запросы к БД.
– обработка информации, с использованием специального
интерфейса.
База
данных
СУБД
сервер
Приложения
клиенты
пользователи
3. Распределенные базы данных
Термин распределенная обработка означает, что разные машины можно
соединить в коммуникационную сеть так, что одна задача обработки данных
распределяется на несколько машин в сети.
Распределенная обработка может быть самой разнообразной.
Самый простой способ распределенной обработки данных представлен на
схеме:
Клиент
Сервер
База данных
35
Чаще всего используется система, где к одному серверу обращаются
несколько пользователей.
База данных
Компьютер сервера
Сеть
Компьютер
клиента
Компьютер
клиента
Компьютер
клиента
Возможна организация БД таким образом, что каждая машина будет и
клиентом и сервером
клиент
клиент
сервер
клиент
сервер
сеть
сервер
клиент
сервер
Итак: Полная поддержка для распределенных баз данных означает, что
отдельное
приложение
может прозрачно обрабатывать
данные,
распределенные на множестве различных баз данных, управление которыми
осуществляют разные СУБД, работающие на многочисленных машинах с
различными
операционными
системами,
соединенными
вместе
коммуникационными системами.
36
3.Процесс прохождения пользовательского запроса.
Иллюстрация взаимодействия СУБД, ОС и пользователя при обработке
запроса
2
1
Внешняя
модель
3
Рабочая область
12
4
СУБД
10
Системный
буфер
5
9
7
6
Концепт
модель
БМД
пользователь
ОС
БД
8
Физическая
модель
В базе метаданных хранится вся информация об используемых структурах
данных, логической организации данных, правах доступа пользователей и,
наконец, физическом расположении данных.
Для управления БМД существует специальное программное обеспечение для
администрирования баз данных. Оно предназначено для корректного
использования информации всеми пользователями.
Последовательность взаимодействия:
1. Пользователь посылает СУБД запрос на получение данных из БД.
2. СУБД проверяет права пользователя, достаточно ли их для
использования именно этих данных.
3. Если прав нет, т.е. произошел запрет на использование информации,
СУБД сообщает об этом пользователю, если прав достаточно, СУБД
определяет
часть
концептуальной
модели
затрагиваемой
пользователем.
4. СУБД получает информацию о запрошенной части концептуальной
модели.
5. СУБД запрашивает информацию о местоположении данных на
физическом уровне (файлы или физические адреса).
6. В СУБД возвращается информация о местоположении данных в
терминах операционной системы.
7. СУБД просит ОС предоставить необходимые данные, используя
средства ОС.
8. ОС осуществляет перекачку информации из устройства хранения и
пересылает её в системный буфер.
9. ОС оповещает СУБД об окончании пересылки.
37
10.СУБД выбирает из доставленной информации, находящейся в
системном буфере, только то, что нужно пользователю, и пересылает
эти данные в рабочую область пользователя.
Лекция 12.
Тема: “Физическая организация удаленных баз данных”
План лекции:
1. Физическая организация данных и структура хранения данных в SQL
Server 7.0
2. Доступ к базе данных
3. Технология com
1. Физическая организация и структура хранения данных в SQL Server
Физическая организация современных баз данных является наиболее
закрытой, она определяется как коммерческая тайна для большинства
поставщиков СУБД. И здесь не существует никаких стандартов, поэтому
каждый поставщик создает свою уникальную структуру и пытается
обосновать её наилучшие качества по сравнению со своими конкурентами.
Физическая организация является в настоящий момент наиболее динамичной
частью СУБД.
При распределении дискового пространства рассматриваются две схемы
структуризации:
- физическая (определяет хранимые данные);
- логическая (определяет концептуальную модель данных).
SQL Server организует следующую иерархию хранения:
База данных – объем физического пространства, на котором размещаются
данные.
Файл – каждая база данных имеет не менее 2-х файлов. Один
непосредственно данный и журнал транзакций.
Страница. Файлы делятся на страницы по 8 Кбайт
Блоки – некоторая область для оперативной памяти.
Различают 7 типов страниц:
– Страница данных (Data page)
– Индексные страницы (Index Page)
– Страницы журнала транзакций (Log page)
– Текстовые страницы (Text / image page)
– Карты распределения блоков
– Карты свободного пространства
– Индексные карты размещения
2. Доступ к базе данных
Поиск и предоставление данных пользователю осуществляется с помощью
программ доступа к данным – диспетчера файлов и диспетчера дисков. В
38
целом работа СУБД построена стандартным образом и включает 3 основных
этапа:
1. Сначала в СУБД определяется искомая запись, а затем для её
извлечения запрашивается диспетчер файлов.
2. Диспетчер файлов определяет страницу, на которой находится искомая
запись, а
затем для извлечения этой страницы запрашивается
диспетчер дисков.
3. Диспетчер дисков определяет физическое положение искомой
страницы на диске и посылает соответствующий запрос на ввод-вывод
данных.
Итак, с точки зрения СУБД база данных выглядит как набор записей,
которые могут просматриваться с помощью диспетчера файлов.
С точки зрения диспетчера файлов БД выглядит как набор страниц, которые
могут просматриваться с помощью диспетчера дисков.
СУБД
Запрос записи
Возвращение записи
Диспетчер файлов
Запрос страницы
Возвращение страницы
Диспетчер диков
Дисковая операция
ввода-вывода
Чтение данных с
диска
БД
Диспетчер дисков является компонентом ОС, с помощью которого
выполняются все дисковые операции ввода-вывода. Если диспетчер файлов
запрашивает некоторую страницу p, для её извлечения диспетчеру дисков
необходимо знать, где конкретно находится страница p на физическом диске,
но диспетчеру файлов необязательно знать физические адреса.
Диспетчер файлов рассматривает диск как набор страниц фиксированного
размера, с уникальным номером набора страниц. Соответствие физических
адресов на диске и номеров страниц достигается с помощью диспетчера
дисков.
Итак, операции, выполняемые диспетчером дисков с набором страниц,
следующие:
– Извлечение страницы p из набора страниц s;
– Замена страницы p из набора страниц s;
– Добавление новой страницы p в набор страниц s;
– Удаление страницы p из набора страниц s.
39
Первые две операции являются базовыми операциями ввода-вывода на
уровне страниц, а две другие позволяют увеличивать или уменьшать наборы
страниц по мере необходимости.
Диспетчер файлов может содержаться либо в составе ОС, либо входить в
состав СУБД.
Каждый хранимый файл имеет имя (file name) и идентификационный номер
(ID).
Основные операции с файлами, выполняемые диспетчером файлов, т.е.
операции, на выполнение которых поступил запрос со стороны СУБД,
следующие:
– Извлечение хранимой записи z из хранимого файла f;
– Запоминание хранимой записи z в хранимом файле f;
– Добавление записи;
– Удаление записи;
– Создание нового файла f;
– Удаление хранимого файла.
С помощью этих простых операций с файлами в СУБД можно создавать
структуры хранения и управления данными.
3.Технология com
Сom – Component Object Model (компонентная модель объектов)
Эта технология разработана корпорацией Microsoft. Она выполняет важную
задачу, а именно передачу данных от одной программы (клиента) в другую
(сервер) независимо, где она находится (возможно в другой части света).
Клиент является инициатором общения, он обращается к одной из служб
сервиса сервера с требованием получить некоторые данные.
COM-технология - это объектная модель компонентов. Технология СОМ
применяется при описании API и двоичного стандарта для связи объектов
различных языков и сред программирования. СОМ предоставляет модель
взаимодействия
между
компонентами
и
приложениями.
Технология СОМ работает с так называемыми СОМ-объектами. СОМобъекты похожи на обычные объекты визуальной библиотеки компонентов
Delphi.
СОМ-объекты содержат свойства, методы и интерфейсы.
Обычный СОМ-объект включает в себя один или несколько интерфейсов.
Каждый
из
этих
интерфейсов
имеет
собственный
указатель.
Технология
СОМ
имеет
два
явных
плюса:
- создание СОМ-объектов не зависит от языка программирования. Таким
образом, СОМ-объекты могут быть написаны на различных языках;
- СОМ-объекты могут быть использованы в любой среде программирования
под Windows. В число этих сред входят Delphi, Visual C++, C++Builder,
Visual Basic, и многие другие.
40
Лекция 13
Тема: ”База данных — хранилище объектов“
1.Основные принципы физического проектирования базы данных.
Прежде всего, необходимо сформулировать основные принципы, на которых
будет строиться проектируемая БД.
1. Каждая сущность, информация о которой хранится в БД, — это объект.
2. Каждый объект уникален в пределах БД и имеет уникальный
идентификатор.
3. Объект имеет свойства (строковые, числовые, временные,
перечислимые), которые описывают атрибуты сущности.
4. Объекты могут быть связаны между собой произвольным образом.
Связь характеризуется связанными объектами и типом связи.
Например, сотрудник фирмы может быть связан с отделом, в котором
он работает, связью типа «сотрудник в отделе» и т.п. Связь в
определенном смысле аналогична понятию ссылки на таблицусправочник в традиционной модели БД.
5. Объект может быть хранилищем. В этом случае допускается хранение
в нем других объектов (например, товара на складе).
6. Такая БД не привязана ни к какой бизнес-модели и позволяет
реализовать «над собой» практически любую бизнес-логику. Логика
выделяется в отдельный программный слой и, как правило, реализуется
на сервере приложений, где по запросу клиента создаются объекты,
загружающие информацию о себе из БД и реализующие «поведение»
объектов реального мира. В то же время, в силу однообразности
модели хранения, эти объекты довольно легко создаются на основе
базовых классов, инкапсулирующих функциональность по загрузке и
сохранению свойств и связей в БД.
Объекты
Объект в нашей БД — понятие скорее логическое, его основное назначение
— предоставить уникальный идентификатор, по которому его можно будет
отличить. Кроме того, каждый объект обладает типом. Типы описываются
при создании структуры базы данных.
Свойства
Свойства объектов отражают реальные атрибуты описываемых ими
сущностей. Все они принадлежат к какому-то объекту и содержат некую
информацию об атрибуте и его величине, причем список атрибутов является
общим для всех объектов одного и того же типа.
41
Величина же может выражаться данными различного типа. Будем хранить в
БД атрибуты следующих типов:




Строковые
Числовые. Различия между целыми и вещественными числами делать
не будем, полагая целые подмножеством вещественных. Если задача
диктует невозможность применения данного подхода — придется
выделять эти атрибуты в различные типы
Исторические (дата и время)
Перечислимые (например, форма собственности фирмы)
Контрольные вопросы.
1.Поясните основные концепции технологии проектирования баз данных.
2.Чем характеризуется современное состояние технологии баз данных?
3. Какими возможностями обладает современная СУБД?
ИСПОЛЬЗУЕМЫЕ ИСТОЧНИКИ:
1. Голицына, О.Л. и др. Базы данных; Форум; Инфра-М, 2013. - 399 c.
2. Гринченко, Н.Н. и др. Проектирование баз данных. СУБД Microsoft
Access; Горячая Линия Телеком, 2012. - 613 c.
3. Дейт, К.Дж. Введение в системы баз данных; К.: Диалектика; Издание
6-е, 2012. - 360 c.
4. Дэвидсон, Луис проектирование баз данных на SQL Server 2000;
Бином, 2009. - 631 c.
5. Дюваль, Поль М. Непрерывная интеграция. Улучшение качества
программного обеспечения и снижение риска; М.: Вильямс, 2008. - 497
c.