Размещено на http://www.allbest.ru/

Содержание

Введение

1. Основные понятия баз данных

1.1 Банк данных и его компоненты

1.2 Модели данных

1.3 Целостность баз данных

1.4 Внутренняя организация СУБД

1.5 Восстановление баз данных

1.6 Защита баз данных

2. Основы проектирования реляционных баз данных

2.1 Этапы проектирования

2.2 Построение концептуальной модели предметной области

2.3 Логическое проектирование базы данных

2.4 Нормализация отношений

3. Проектирование автоматизированной системы рабочего места менеджера кадрового агентства

3.1 Цель и задачи

3.2 Определение объектов базы данных

3.3 Проектирование моделей данных

3.4 Описание программы по автоматизации работы менеджера кадрового агентства

4. Экономическое обоснование

4.1 Общие сведения из теории сетевого планирования базы данных

4.2 Показатели сетевой модели и метод ее расчета

4.3 Формулы расчета показателей сетевых моделей

4.4 Анализ сетевой модели

4.5 Смета расходов на проектирование

5. Организация безопасности жизнедеятельности

5.1 Анализ опасных и вредных факторов, возникающих при работе с компьютером

5.2 Мероприятия по предотвращению и уменьшению влияния вредных факторов. Нормирование искусственного и естественного освещения

5.3 Организация рабочего места оператора

5.4 Пожаробезопасность

6 Заключение

Список литературы

база данные проектирование реляционный

Введение

Потребности и предложения на рынке трудовых ресурсов можно проследить на бирже труда. Целью дипломного проекта является анализ ситуации на рынке трудовых ресурсов с помощью автоматизации работы менеджера некоторого кадрового агентства.

Сейчас, в условиях рыночной экономики, когда везде требуются высококвалифицированные специалисты, очень много людей, не удовлетворяющих данным параметрам, остаются без работы. Именно они и обращаются к услугам кадрового агентства, причем их число значительно возрастает. Только регистрация безработных без использования автоматизации - очень трудоемкая работа, а ведь кадровое агентство не только производит регистрацию людей, у них много функций:

регистрация вакантных мест;

трудоустройство безработных и других лиц, желающих получить работу;

изучение конъюнктуры рынка труда и предоставление информации о ней;

тестирование лиц, желающих получить работу;

профессиональная ориентация и профессиональная переподготовка безработных;

При автоматизации значительно сократится время и трудоемкость осуществления этих операций. Финансовые расходы также сократятся, но это будет после того, как внедренный пакет прикладных программ в кадровое агентство полностью окупится.

Расходы на политику занятости часто относят к безвозвратным социальным расходам. Однако, возвращая безработного к работе, служба занятости решает и побочные задачи. Потеря гражданами работы, а, следовательно, и заработков, снижает покупательную способность населения. Получив новое рабочее место, безработный восстанавливает свой фонд заработной платы, а значит, и покупательную способность. Кроме того, безработный вновь становится налогоплательщиком. С заработной платы удерживаются подоходный налог, а его работодатель производит отчисления во внебюджетные социальные фонды. Если принять во внимание только эти два результата, можно в определенной степени судить о финансово-экономической эффективности деятельности кадрового агентства. Поэтому для лучшей работы кадрового агентства необходима автоматизация.

1. База данных

Деятельность специалистов, работающих в различных сферах экономики, неразрывно связана со сбором, хранением и обработкой больших объемов информации. Потребности общества, появление компьютерной техники, разработка и совершенствование методов и технологий решения перечисленных задач привели к созданию и быстрому развитию автоматизированных информационных систем (АИС), основной целью которых является информационное обеспечение основной деятельности пользователей.

Автоматизированные информационные системы обеспечивают формирование, хранение и обновление больших массивов информации, оперативный поиск в них необходимых пользователю сведений с возможным их дальнейшим обобщением и анализом.

В развитии АИС можно выделить два поколения.

Автоматизированные информационные системы первого поколения представляют собой наборы автономных файлов и управляющих ими прикладных программ. Недостатками этих АИС являются сложность эксплуатации системы, проблемы в обеспечении согласованности информации, высокая степень дублирования хранимых данных, зависимость прикладных программ от данных (при изменении структуры данных требуется переделывать все программы).

АИС второго поколения - банки данных. Это системы с высокой степенью интеграции данных и централизованным управлением ими, ориентированные на коллективное пользование. Под интеграцией данных понимается их объединение в единый информационный массив (базу данных), созданный по унифицированным правилам. Централизация управления предполагает передачу всех функций управления данными единому программному комплексу - системе управления базой данных (СУБД). Такая организация системы позволяет значительно облегчить работу пользователей с информацией, уменьшить избыточность данных, поддерживать эффективные технологии обеспечения согласованности и защиты данных.

Происхождение терминов «база данных» и «управление базами данных» окончательно не установлено. Возможно, впервые понятие базы данных было введено в июне 1963г., когда по инициативе военно-воздушных сил и службы аэрокосмической разведки США в г.Санта-Моника был организован симпозиум по теме «Разработка и использование машиноуправляемых баз данных».

1.1 Банк данных и его компоненты

Существует множество определений банка данных.

Банк данных - это система, предоставляющая услуги по хранению и поиску данных определенной группе пользователей и по определенной тематике (например, биологические виды, статистика торговли, цены на товары).

Банк данных - это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

Приводимые определения в какой-то мере дополняют друг друга, так как характеризуют понятие банка данных под разными углами зрения.

Основными функциями банка данных (БнД) являются:

1. Хранение информации, ее защита и восстановление после сбоев в работе.

2. Периодическое изменение хранимых данных.

3. Поиск и отбор необходимых данных по запросам пользователей и прикладных программ.

4. Обработка найденных данных и вывод результатов в заданной форме.

Основными особенностями банков данных являются многократное использование одной и той же информации для решения различных задач, независимость данных от прикладных программ.

Структуру банка данных можно представить в виде рис.1:

Рисунок 1 Схема банка данных

Следовательно, банк данных состоит из следующих компонентов:

1. Базы данных - именованной совокупности данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными.

2. Системы управления базами данных (СУБД) - комплекса программных и языковых средств, предназначенных для создания, ведения и использования баз данных.

3. Словаря (справочника) базы данных - информации о базе данных, используемой СУБД для доступа к хранимой в ней информации.

База данных обычно содержит информацию о некоторой конкретной части окружающего нас мира (обычно ее называют предметной областью). Физически база данных представляет собой один или несколько специальным образом организованных файлов, хранящихся во внешней памяти (например, на магнитных или оптических дисках). По возможности при создании и обновлении базы данных следует исключать дублирование хранящейся в ней информации.

Пользователи не работают с базой данных непосредственно. Процесс взаимодействия между ними реализуется через систему управления базами данных. При этом возможны два варианта организации этого процесса: пользователь работает с СУБД в интерактивном режиме, используя систему меню; взаимодействие осуществляется с помощью прикладных программ, называемых приложениями. С одной базой данных могут работать (часто параллельно) и большое количество пользователей, и множество различных приложений. При этом СУБД должна поддерживать независимость работы пользователей и приложений, обеспечивая корректность изменений, вносимых ими в базу данных.

СУБД должна также обеспечивать безопасность и согласованность информации в базе данных. Пользователям предоставляется возможность защиты их данных от несанкционированного доступа. При аппаратных или программных сбоях СУБД должна самостоятельно восстанавливать исходное согласованное состояние базы данных.

СУБД полностью отстраняет пользователей от проблем организации хранения данных на физическом уровне.

Система управления базами данных включает:

· ядро СУБД, обеспечивающее организацию ввода, обработки и хранения данных;

· компоненты, обеспечивающие настройку системы;

· средства тестирования;

· сервисные программы, обеспечивающие восстановление базы данных, ее защиту и т.д.;

· трансляторы для используемых языковых средств.

В качестве примеров СУБД можно привести MS Access, Paradox, FoxPro, Clarion, Clipper, MS SQL Server, Oracle, Informix и т. д.

При обращении к базе данных СУБД использует информацию, хранящуюся в ее словаре:

· логическую схему БД, описания структур хранения данных; сведения о допустимых значениях и форматах представления данных;

· сведения о полномочиях пользователей при работе с данными;

· характеристики физического размещения данных.

Словарь базы данных может храниться в отдельном файле или непосредственно в файле базы данных (MS Access).

Пользователей банков данных можно разделить на три большие группы.

1. Конечные пользователи. Это наиболее многочисленная группа пользователей, для обслуживания профессиональных задач которых создается конкретная база данных (менеджеры, торговые работники, финансисты и т. д.). Важно, чтобы СУБД предоставляла этой категории пользователей достаточно удобные, простые и эффективные средства работы с базой данных, не требующие от пользователей образования в области информационных технологий или длительного этапа специальных подготовки и обучения.

2. Прикладные программисты. В обязанности этой группы пользователей входит написание, отладка и внедрение прикладных программ (приложений), использующих информацию из базы данных. В основном для этого используются универсальные языки программирования: С++, Pasсal, Delphi и др.

3. Администраторы банка данных (АБД). Пользователи этой группы реализуют сложные задачи проектирования, создания, организации и поддержки работы банков данных. Администратор банка данных должен быть профессиональным специалистом в области информационных технологий и обеспечивать выполнение следующих функций:

· анализа предметной области, для которой создается банк данных;

· проектирования логической структуры БД;

· определения правил поддержания данных в согласованном состоянии;

· первоначальной загрузки и ведения БД;

· защиты данных;

· восстановления БД после сбоев;

· анализа функционирования БД с возможной ее модернизацией для увеличения производительности системы;

· взаимодействия с конечными пользователями;

· подготовки и поддержания системных средств.

При работе с настольной СУБД (например MS Access) функции конечного пользователя, прикладного программиста и администратора банка данных может осуществлять один человек. Если создается банк данных, предназначенный для информационного обслуживания деятельности крупной организации или фирмы, может потребоваться объединение усилий большого количества высококвалифицированных специалистов: системных аналитиков, проектировщиков структур данных и технологических процессов обработки информации, системных и прикладных программистов, инженеров по обслуживанию технических средств.

1.2 Модели данных

Данные, хранящиеся в БД, должны быть организованы по определенным правилам.

Организация данных и способы доступа к ним, обеспечиваемые конкретной СУБД, называются моделью данных.

Существующие базы данных разработаны на основе иерархической, сетевой, реляционной, объектно-ориентированной моделей данных или их подмножеств.

Иерархическая модель данных

Иерархическая модель данных (ИМД) представляет собой древовидную (иерархическую) структуру. В вершинах дерева находятся совокупности свойств данных, описывающих некоторый объект. В терминологии ИМД эти совокупности называются сегментами. Сегмент, у которого нет вышележащего уровня иерархии, называется корневым.

Рассмотрим структуру иерархической базы данных торгового предприятия, имеющего филиалы в нескольких городах, в каждом из которых есть несколько магазинов, имеющих склады для хранения товаров (рис.2).

Любой блок, изображенный на схеме, представляет собой сегмент, состоящий из нескольких полей, каждое из которых характеризует собой некоторое свойство сегмента. Например, для сегмента Филиал такими свойствами могут быть название города, где находится филиал торгового предприятия, его почтовый и юридический адреса, факс и т. д. Свойствами сегмента Склад могут быть номер склада, его площадь и т. д. Корневым является сегмент Филиал.

Совокупность конкретных значений полей сегмента называется экземпляром сегмента или записью. Следовательно, один блок на схеме отображает множество фактических записей (экземпляров сегмента).

Рисунок 2 Иерархическая база данных

Поиск нужной записи в иерархической базе данных всегда начинается от корневой записи. Например, необходимо выбрать запись с характеристиками конкретной партии товаров (количество, цвет, размер, цена и т. д.). Следует последовательно указать филиал, магазин, склад, где эти товары находятся. Для упрощения поиска, записи каждого сегмента упорядочиваются по данным некоторого поля.

Основные свойства иерархической модели данных.

1. Каждый из подчиненных сегментов связан только с одним сегментом вышележащего уровня иерархии. Связи между сегментами одного уровня не допускаются.

2. Между сегментами двух уровней могут поддерживаться только связи «один ко многим».

Недостатки иерархической модели данных:

1. Асимметричность запросов.

2. Сложность изменения.

3. Жесткость структуры, не позволяющая учесть в базе данных отдельные реальные ситуации.

4. Сложность эксплуатации.

Перечисленные причины привели к тому, что иерархическая модель данных в настоящее время практически не используется.

Сетевая модель данных

Стандарт сетевой модели данных впервые был определен в 1975 г. организацией CODASYL (Conference of Data System Languages).

В сетевой модели данных не накладывается никаких ограничений на количество связей, входящих в одну вершину. Следовательно, связи можно устанавливать не только между узлами соседних по подчиненности уровней, но и различных уровней (рис.3):

Рисунок 3 Сетевая база данных

Связи, изображенные на рис.3 и отсутствующие на рис.2, могут характеризовать вполне реальные взаимоотношения в работе торгового предприятия: представители дирекции могут курировать работу конкретных подразделений, подразделения предприятия (автохозяйство, ремонтная служба) обеспечивают работу складов, сотрудники подразделений (бухгалтеры, торговые агенты) взаимодействуют с магазинами. Таких связей можно определить много.

В результате формируется сеть, которая позволяет отображать связи между объектами предметной области практически любой степени сложности, в частности, кольцевые структуры. В сетевой модели, если на нее не накладывается никаких ограничений, в принципе любой объект может быть точкой входа в систему, каждый из объектов может быть связан с произвольным числом других объектов, и между записями связанных объектов могут быть любые отношения. Например, для сетевой базы данных, изображенной на рис.3, формируются связи «многие ко многим» (многие подразделения предприятия обеспечивают работу многих складов). На практике в реальных СУБД на модель накладываются определенные ограничения для преобразования связей «многие ко многим» в связи «один ко многим».

Достоинствами сетевой модели данных по сравнению с иерархической моделью являются ее гибкость, возможность образования произвольных связей, экономичность. Недостатки - высокая сложность, практически исключающая возможность ее эксплуатации пользователями, не являющимися специалистами в области информационных технологий, ослабленный контроль целостности связей между объектами базы данных.

По указанным причинам СУБД, построенные на основе сетевой модели (IDMS, db_VistaIII и др.), не получили широкого распространения.

Реляционная модель данных

Реляционная модель данных (РМД) положена в основу большинства современных СУБД. Достоинствами модели являются простота размещения данных и удобство их интерпретации.

Реляционная модель ориентирована на организацию данных в виде таблиц (отношений).

Для РМД существует довольно строгое теоретическое обоснование. Представление данных в виде отношений позволяет использовать для обработки данных формальный математический аппарат реляционной алгебры отношений и реляционного исчисления. Понятия таблицы и отношения с практической точки зрения представляют собой одно и то же, поэтому в дальнейшем будут употребляться оба эти термина.

Каждая таблица реляционной базы данных имеет имя и строку заголовков.

Табличная форма представления данных позволяет удобно описывать простейший вид связей между ними: информация об объекте, которая хранится в таблице (поставщики товаров), делится на множество подобъектов, каждому из которых соответствует одна строка таблицы (конкретный поставщик). При этом все подобъекты имеют одинаковую структуру или свойства.

В терминологии реляционной модели данных каждый столбец таблицы называется полем (атрибутом), каждая строка таблицы - записью (кортежем).

Данные в одном поле могут иметь значения только из некоторой совокупности допустимых значений, называемой доменом. Для каждого поля таблицы должен быть задан конкретный тип данных.

К таблицам РМД предъявляются следующие требования:

1. Значения данных, расположенные на пересечении любых строки и столбца, должны быть неделимыми (атомарными, элементарными). Это требование означает, что в каждой ячейке таблицы может находиться только одно значение.

2. В таблице не должно быть полей с одинаковыми названиями, порядок расположения полей является произвольным. Наличие этого требования определяется тем, что поиск информации в таблице реализуется в полях, имена которых указаны в запросе.

3. Порядок следования записей может быть произвольным.

4. В таблице не должно быть одинаковых записей.

Важным следствием отсутствия в таблице одинаковых записей является наличие в ней первичного ключа. Значение первичного ключа должно быть уникальным для каждой записи таблицы, следовательно, должно однозначно определять каждую запись таблицы.

Первичный ключ, определенный по нескольким полям, называется составным. В общем случае в таблице может быть несколько вероятных ключей, из которых один выбирается как первичный.

С помощью одной таблицы обычно не удается описать сложные структуры данных из предметной области. Поэтому реляционная модель данных предполагает создание нескольких таблиц, которые при необходимости связываются между собой по ключевым полям. Такая стратегия очень удобна, так как позволяет хранить постоянно и редко используемые данные в разных таблицах.

Объектно-ориентированная модель данных

Создание объектно-ориентированных СУБД считается одним из наиболее перспективных направлений в области разработки новых типов баз данных.

Объектно-ориентированные СУБД базируются на идеях, сформулированных в объектно-ориентированных языках программирования (наследования, инкапсуляции и полиморфизма). Предметная область представляется в виде множества классов объектов. Структура и поведение объектов одного класса (например, товаров базы данных торгового предприятия) являются одинаковыми.

Объект обладает следующими характеристиками:

1. Имеет уникальный идентификатор, однозначно определяющий объект.

2. Принадлежит к некоторому классу, обладающему определенными поведением и свойствами.

3. Может обмениваться сообщениями с другими объектами.

4. Имеет некоторую внутреннюю структуру. Объекты, внутренняя структура которых скрыта от пользователей (известно только, какие функции может выполнять данный объект), называются инкапсулированными.

Поведение объекта задается с помощью методов его класса - операций, которые можно применять к объекту. Способность применять один и тот же метод для разных классов называется полиморфизмом.

В объектно-ориентированной модели возможно создание нового класса объектов на основе уже существующего класса. Этот процесс называется наследованием. Новый класс, называемый подклассом существующего класса (суперкласса), наследует все свойства и методы суперкласса. Кроме того, для него могут быть определены дополнительные свойства и методы.

Объектно-ориентированная СУБД позволяет хранить объекты и обеспечивает их совместное использование различными приложениями. Для этого она должна обладать следующими компонентами:

1. Языком баз данных, который позволяет декларировать классы объектов, а затем создавать, сохранять, извлекать и удалять объекты.

2. Хранилищем объектов, к которому могут получить доступ разные приложения. Для ссылок на объекты используются их идентификаторы.

Для практической реализации объектно-ориентированных баз данных применяются два подхода:

1. Используется язык объектно-ориентированного программирования (например, С++), дополненный средствами, позволяющими при необходимости сохранять объекты после завершения программы, с помощью которой они были созданы.

2. Основой является реляционная система, к которой добавляются объектно-ориентированные компоненты.

Недостатки объектно-ориентированных баз данных:

1. отсутствуют необходимое унифицированное теоретическое обоснование и стандартизованная терминология;

2. не существует формально сформулированной методологии проектирования баз данных;

3. отсутствуют средства создания нерегламентированных запросов;

4. нет общих правил поддержания согласованности данных.

В заключение можно отметить, что объектно-ориентированные базы данных в настоящее время очень сложны в проектировании и эксплуатации, что ограничивает их практическое применение. Поэтому, несмотря на продолжающиеся интенсивные исследования, объектно-ориентированная модель данных пока поддерживается лишь немногими СУБД (POET, Jasmine, Versant, Iris).

1.3 Целостность баз данных

Одной из важнейших задач, решаемой СУБД, является поддержание в любой момент времени взаимной непротиворечивости, правильности и точности данных, хранящихся в БД. Этот процесс называется обеспечением целостности базы данных.

Следует различать проблемы обеспечения целостности базы данных и защиты базы данных от несанкционированного доступа. Поддержание целостности базы данных может интерпретироваться как защита данных от неправильных действий пользователей или некоторых случайных внешних воздействий. В обеих ситуациях нарушения целостности базы данных имеют непреднамеренный характер.

Целостность базы данных может быть нарушена в результате сбоя оборудования; программной ошибки в СУБД, операционной системе или прикладной программе; неправильных действий пользователей. Эти ситуации могут возникать даже в хорошо проверенных и отлаженных системах, несмотря на применяемые системы контроля. Поэтому СУБД должна иметь средства обнаружения таких ситуаций и восстановления правильного состояния базы данных.

Целостность базы данных поддерживается с помощью набора специальных логических правил, накладываемых на данные, называемых ограничениями целостности. Ограничения целостности представляют собой утверждения о допустимых значениях отдельных информационных единиц и связях между ними. Ограничения целостности хранятся в словаре БД.

Ограничения целостности могут определяться:

· спецификой предметной области;

· непосредственно информационными характеристиками.

В процессе работы пользователя с базой данных СУБД проверяет, соответствуют ли выполняемые действия установленным ограничениям целостности. Действия, нарушающие целостность базы данных, отменяются, при этом обычно выводится соответствующее информационное сообщение.

Ограничения целостности в реляционной модели данных могут относиться к полям, записям, таблицам, связям между таблицами.

Ограничения целостности для полей

Большая часть ограничений целостности для полей обеспечивает выполнение требования- данные в одном поле могут иметь значения только из некоторой совокупности допустимых значений, называемой доменом. Практическая реализация этого требования может осуществляться разными способами:

1. Для поля устанавливается конкретный тип данных: текстовый, числовой, дата/время, логический и т. д. Это не позволяет вводить, например, в числовое поле текст или даты, в поле с типом данных дата/время - числа.

2. Домен указывается непосредственно - перечислением входящих в него значений или с помощью указания диапазона допустимых значений.

Тип данных создаваемого поля выбирается из предложенного списка доступных типов. При необходимости с помощью свойства поля Размер поля можно уточнить область определения размещаемых в нем данных. Указывается максимальный размер данных, сохраняемых в поле: количество символов для тестовых полей; размеры поля для числовых полей: байт (целое число от 0 до 255), целое (число в диапазоне от минус 32768 до 32768), одинарное с плавающей точкой и т. д.

При непосредственном задании домена необходимые параметры можно указать в свойстве поля Условие на значение.

Частным случаем определения домена можно считать автоматическое (по умолчанию) задание конкретного значения данных в некотором поле (в MS Access свойство поля Значение по умолчанию).

Некоторые нарушения целостности полей таблиц базы данных СУБД контролирует автоматически.

В ситуациях, когда вводимое в некоторое поле значение данных не соответствует установленным для этого поля ограничениям целостности, СУБД Access выводит на экран сообщение «Введенное значение не подходит для данного поля». Пользователь может самостоятельно создать нестандартный текст этого сообщения с помощью свойства поля Сообщение об ошибке.

Для полей таблиц могут поддерживаться и другие ограничения целостности.

1. Контролируется, введены ли данные в поле. В MS Access это ограничение целостности создается для конкретного поля с помощью выбора значения Да свойства Обязательное поле.

2. Контролируется уникальность значений данных в поле. Если поле является простым первичным ключом таблицы, проверка уникальности значений данных в этом поле выполняется СУБД автоматически. При наличии в таблице вероятных простых ключей, можно исключить ввод в соответствующие поля повторяющихся значений данных. Для этого в MS Access для этих полей в свойстве Индексированное поле устанавливается значение Да (Совпадения не допускаются).

Все рассмотренные ограничения целостности проверяют не только правильность ввода новых данных в поля таблиц, но и контролируют процесс редактирования уже имеющихся в таблицах значений.

Ограничения целостности для записей

В рамках данного вида ограничений может контролироваться согласованность значений данных в разных полях записей. Для задания этого ограничения целостности в MS Access необходимо вызвать диалоговое окно свойств таблицы и в свойстве Условие на значение ввести необходимые условия:

Ограничения целостности для таблиц

Эти ограничения целостности проверяют согласованность данных в различных записях одной таблицы.

В рамках ограничений целостности данного вида может контролироваться также отсутствие одинаковых записей в таблице (на практике это реализуется с помощью создания простых или составных ключей таблицы).

Ограничения целостности для таблиц в основном реализуются специально созданными для этого программами.

Ограничения целостности для связей между таблицами

Ограничения целостности этого типа позволяют обеспечить согласованность данных в связующих полях (первичном и внешнем ключах) нескольких таблиц.

Нарушение целостности связи между таблицами возможно при возникновении следующих ситуаций:

1. В главной таблице удаляется запись, для которой существуют связанные записи в подчиненной таблице.

2. В главной таблице изменяются значения данных в поле (полях) первичного ключа, если существуют связанные с ними значения в поле (полях) внешнего ключа подчиненной таблицы.

3. В поле (полях) внешнего ключа подчиненной таблицы вводятся значения данных, отсутствующие в поле (полях) первичного ключа главной таблицы.

В СУБД MS Access для исключения возможности возникновения перечисленных ситуаций, нарушающих согласованность базы данных, при создании каждой конкретной связи между таблицами в диалоговом окне Связи устанавливается флажок Обеспечение целостности данных. После этого любая попытка выполнить действия, нарушающие целостность связей между таблицами, будет игнорироваться (при этом выводится сообщение об ошибке).

Если возникает необходимость удаления или обновления связанных записей в таблицах БД при сохранении целостности данных, в диалоговом окне Связи требуется установить флажки Каскадное обновление связанных полей и Каскадное удаление связанных полей. При установке первого из этих флажков изменения данных в поле (полях) первичного ключа главной таблицы приводят к автоматическому изменению соответствующих значений в связанных полях подчиненных таблиц. Установка второго флажка позволяет автоматически удалить все записи в подчиненных таблицах, связанные с удаляемой записью в главной таблице.

Для многотабличной БД могут быть созданы также ограничения целостности, проверяющие отсутствие логических противоречий между данными связанных таблиц.

В качестве ограничения целостности может быть использован запрет на обновление данных в отдельных полях, записях или таблицах БД. Очевидно, что должны быть защищены от случайных изменений.

1.4 Внутренняя организация СУБД

Общие положения

Данные на внешних носителях информации (например, магнитных или оптических дисках) хранятся в виде файлов. Запись данных во внешнюю память и чтение их из нее реализуются операционной системой компьютера, предоставляющей прикладным программам (в том числе и СУБД) услуги по вводу-выводу информации и управлению памятью. Обработка файлов операционной системой на логическом уровне выполняется с помощью файловой системы, на физическом уровне - системы управления файлами.

Наибольшую производительность работы СУБД обеспечивают физические устройства хранения данных прямого доступа (магнитные и оптические диски и т. д.), обеспечивающие непосредственное считывание необходимой информации, если известно ее местоположение. Оптимальным является размещение данных в файлах прямого доступа, позволяющих выбирать нужные записи базы данных без просмотра всего содержимого файла. Для ускорения поиска информации применяются различные структуры хранения данных (способы их упорядочивания). Существенное внимание специалистов к разработке структур хранения и технологий методов доступа к данным определяется необходимостью сокращения числа дисковых операций ввода-вывода данных из-за относительно большого времени доступа к внешним устройствам.

Данные в процессе работы считываются и записываются страницами - блоками фиксированных размеров (в зависимости от используемой системы обычно 2, 4 или 8 килобайт). Каждая страница, хранящаяся на диске, имеет свой уникальный идентификатор, указывающий на физическое место ее хранения. Этот идентификатор используется системой управления файлами для чтения страницы и ее записи после изменения размещенных на ней данных в то же место на диске, откуда страница была считана.

Файл базы данных представляет собой набор страниц. При создании файла по запросу файловой системы система управления файлами выделяет ему требуемое количество страниц. Каждой странице в полученном наборе страниц присваивается некоторый «логический» (например, порядковый) номер. Обычно система управления файлами ведет каталог, в котором содержатся сведения о наборах страниц и указателях к каждой странице в их пределах. Когда СУБД в рамках решения прикладной задачи взаимодействует с конкретным файлом, логические номера страниц используются файловой системой, не знающей, где физически на диске хранится нужная страница, для обращения к системе управления файлами, осуществляющей чтение и запись данных.

На одной странице могут храниться одна или несколько записей с данными. После считывания из внешней памяти в оперативную память необходимой страницы выполняется выборка и обработка нужной записи. Для этого используется идентификационный номер записи, состоящий из двух частей: номера страницы и параметра, определяющего место расположения записи на странице.

В очень редких случаях запись, размеры которой превышают размеры страницы, может размещаться на двух (но не более) страницах. В таких ситуациях используются страницы переполнения.

Линейный список

Линейный (последовательный) список - последовательность записей базы данных, сформированная по некоторым логическим принципам.

При поиске информации, соответствующей некоторым критериям (например, товаров с определенным названием или артикулом), линейный список необходимо просмотреть полностью от первой до последней записи. Это приводит к тому, что рассматриваемая структура хранения, обеспечивая оптимальные требования к минимальному объему выделяемой памяти на внешних устройствах, является неэффективной по быстродействию.

Инвертированный список

Инвертированные списки позволяют существенно ускорить процесс поиска необходимой информации по сравнению с линейными списками. Это достигается с помощью упорядочивания (сортировки) записей исходного списка по значениям данных в одном из не ключевых полей. Инвертирование исходного списка можно выполнить для отдельных (частичное инвертирование) или всех (полное инвертирование) не ключевых полей исходного списка.

Обеспечивая уменьшение времени выполнения запросов, инвертирование приводит к существенному увеличению объемов внешней памяти для хранения информации в результате ее дублирования. Это увеличение прямо пропорционально количеству полей, по которым производится инвертирование. Для частичного устранения данного недостатка применяется создание индексов.

Индексы

Индексы применяются для ускорения доступа к записям базы данных. Их можно сравнить с предметным указателем книги - упорядоченной последовательностью слов (словосочетаний) с перечнем номеров страниц, на которых встречается это слово (словосочетание).

Индекс базы данных представляет собой структуру, в которой содержатся рассортированные в заданном порядке значения данных в некотором поле и указатели адресов записей (страниц), где находятся эти значения. В отличие от инвертированных списков индексы занимают значительно меньшее место во внешней памяти.

Построение индекса и его обновление выполняется автоматически самой СУБД. Файл базы данных, для которого создан хотя бы один индекс, называется индексированным файлом.

Поиск и выборка нужных записей в базе данных осуществляются в следующей последовательности:

1. Выбирается индекс, соответствующий условию поиска

2. В индексе находится строка с заданным условием.

3. Из найденной строки выбираются номера страниц, где хранятся искомые записи.

4. Полученные номера страниц используются для чтения необходимой информации.

Большинство СУБД реализует этот процесс автоматически, без участия пользователя.

Если для таблицы определены несколько индексов по отдельным полям, при поиске записей в данной таблице по условиям поиска, заданным в этих полях, соответствующие индексы используются совместно.

Если поиск достаточно часто производится по одним и тем же полям, желательно создать составной индекс, включающий несколько полей. При использовании составного индекса сокращается время поиска, так как не приходится сравнивать значения данных из нескольких индексов.

Недостатком индексирования является необходимость выделения во внешней памяти дополнительного места для хранения индексов. Существуют оценки, что файл, в котором созданы индексы для всех полей размещенной в нем таблицы, занимает практически вдвое больше места на внешнем носителе по сравнению с исходным файлом. Кроме того, наличие индексов затрудняет обновление информации, хранящейся в базе данных, и требует дополнительных затрат времени на данный процесс.

Поэтому не рекомендуется индексировать все поля таблиц или поля, данные в которых часто изменяются. Наиболее эффективным является создание индексов для первичных и внешних ключей, для полей, по которым в основном выполняются запросы.

Хеширование

Хеширование (Hashing) - алгоритмическое преобразование значений некоторого поля записей (первичного ключа или любого другого поля) в адреса их размещения на внешнем носителе.

При вводе данных СУБД вычисляет адрес страницы, на которой будет храниться запись, и заносит запись на эту страницу. При выполнении запросов реализуются аналогичные расчеты адреса страницы с последующим чтением записей с этой страницы. Достоинством такого метода является быстрый прямой доступ к данным. При этом время доступа практически не зависит от количества хранимых записей.

Основной проблемой хеширования является сложность выбора оптимальной хеш-функции. При выполнении данной работы анализируются размеры записей и страниц внешней памяти, вероятное распределение получаемых адресов. Неудачно выбранная хеш-функция может вызвать неравномерное распределение записей в памяти или формирование слишком длинных цепочек синонимов.

Весьма сложной является ситуация, когда количество запоминаемых записей больше, чем предполагалось, и необходимо увеличить место в памяти для их хранения или размеры таблицы хеширования. В этой ситуации потребуется выполнить полное повторное хеширование.

Следует иметь в виду, что хеширование позволяет организовать быстрый поиск информации только по одному полю, данные которого использовались для хеширования. Нельзя хранить записи в порядке, определяемом несколькими хеш-функциями.

Несмотря на отмеченные недостатки хеширования, данный способ организации хранения и быстрого извлечения необходимых данных широко применяется, в первую очередь в объектно-ориентированных базах данных.

Кластеризация

Кластеризация использует принцип близкого размещения во внешней памяти логически связанных данных. Этим обеспечиваются быстрый поиск и извлечение необходимой информации.

Физически кластеризация достигается размещением логически связанных записей на одной странице (если сделать это позволяют размеры страниц и записей) или на страницах, расположенных рядом.

Для кластеризированных таблиц можно создать неплотные индексы с указателями на первые записи, входящие в каждый кластер (блок).

Если кластеризации реализуется для одного логического объекта (файла) базы данных. Такая кластеризация называется внутрифайловой. Иногда применяется межфайловая кластеризация, когда на одной странице во внешней памяти размещаются записи из нескольких логических объектов (файлов) базы данных. Такой принцип хранения данных может существенно ускорить выполнение запросов, включающих критерии отбора для характеристик, хранимых совместно, но он замедляет поиск информации для всех других запросов. Поэтому кластеризация является оправданной, если к базе данных наиболее часто выполняются запросы одного типа. При этом следует иметь в виду, что одновременно можно реализовать только один вариант кластеризации базы данных, так как речь идет о физическом хранении информации.

1.5 Восстановление баз данных

При работе с базой данных ее целостность может быть нарушена по ряду причин:

1) в результате несогласованности или ошибочности действий, выполняемых при обработке данных СУБД, прикладными программами или пользователями;

2) при аварийном завершении работы прикладной программы;

3) в результате потери содержимого оперативной памяти компьютера (мягкий сбой), например, при отключении питания;

4) при выходе из строя физического устройства внешней памяти, на котором хранится база данных (жесткий сбой).

При возникновении любой из перечисленных ситуаций СУБД должна автоматически выполнить процесс возвращения базы данных в исходное согласованное состояние. Этот процесс называется восстановлением базы данных и поддерживается с помощью журнала, в котором СУБД регистрирует все действия (транзакции), выполняемые с данными.

Транзакции

Транзакцией называется последовательность элементарных операций, выполняемых над базой данных и переводящих базу данных из одного непротиворечивого состояния в другое. Транзакция - это логическая единица работы с базой данных.

При успешном завершении транзакции полученные результаты сохраняются во внешней памяти (фиксация транзакций).

Если во время выполнения транзакции (до ее завершения) произойдет сбой, база данных останется в несогласованном состоянии. Это является следствием того, что в промежуточных точках выполнения транзакции целостность базы данных нарушается. Для восстановления базы данных (ее возвращения в исходное состояние), действия, уже выполненные такими транзакциями, отменяются (откат транзакций).

Транзакции должны обладать следующими свойствами:

1) атомарности (Atomicity) - транзакция должна выполняться полностью или не выполняться совсем;

2) согласованности (Consistency) - транзакция переводит базу данных из одного согласованного состояния в другое с возможным нарушением согласованности в промежуточных точках транзакции;

3) изолированности (Isolation) - транзакции должны выполняться автономно друг от друга, при этом изменения, вносимые в базу данных некоторой транзакцией, до ее фиксации должны быть скрыты от других транзакций;

4) долговечности (Durability) - после завершения и фиксации транзакции, все изменения, вызванные этой транзакцией в базе данных, сохраняются даже при возникновении сбоев в системе.

Транзакции, удовлетворяющие перечисленным требованиям, называют ACID-транзакциями.

Журнал транзакций

Как указывалось ранее, все транзакции регистрируются СУБД в журнале транзакций. Этот журнал недоступен пользователям, хранится во внешней памяти (иногда в виде двух копий на разных физических носителях) и содержит информацию обо всех изменениях базы данных, вызванных выполняемыми транзакциями. Сведения, содержащиеся в журнале транзакций, используются для восстановления последнего по времени согласованного состояния базы данных после аппаратных или программных сбоев.

Процесс восстановления базы данных заключается в отмене результатов незавершенных транзакций при сохранении в БД всех изменений, сделанных зафиксированными транзакциями.

Необходимость выполнения индивидуального отката транзакции может возникнуть в случаях возникновения ошибок при обработке данных, взаимной блокировки параллельно выполняемых транзакций или при аварийном завершении работы прикладной программы, не позволившем зафиксировать транзакцию. В этих ситуациях журнал транзакций используется для последовательной отмены действий (начиная с последнего из них), которые выполнялись в рамках транзакции, откат которой производится.

При внезапной потере содержимого оперативной памяти (мягкий сбой) поражаются все выполнявшиеся в это время транзакции, но физического нарушения базы данных не происходит. Согласованное состояние базы данных восстанавливается СУБД после перезагрузки операционной системы по журналам транзакций, хранящимся во внешней памяти. Если транзакция находилась в состоянии выполнения и не была завершена, все действия, выполненные этой транзакцией, отменяются с помощью рассмотренной ранее технологии индивидуального отката транзакций. В ситуации, когда транзакция успешно завершилась, но ее результаты не были физически сохранены в базе данных, СУБД реализует повторное выполнение этой транзакции.

При жестком сбое (произошли нарушения в работе аппаратных средств) некоторая часть базы данных может быть разрушена физически. В этом случае журнал транзакций не позволяет устранить все возникшие дефекты. Предварительно необходимо восстановить базу данных по ее резервной (архивной) копии, созданной в некоторый предшествующий момент времени, и хранящейся на независимом надежном устройстве внешней памяти. Журнал транзакций используется на втором этапе восстановления, когда предпринимается попытка повторной реализации транзакций, выполнявшихся после создания резервной копии базы данных.

Выполнение транзакций в многопользовательских системах

В процессе одновременной работы нескольких пользователей с одними и теми же объектами базы данных СУБД параллельно выполняет множество транзакций. При этом могут возникнуть следующие проблемы.

1. Проблема потери обновления.

2. Проблема зависимости от незафиксированных обновлений.

Эта проблема возникает, когда одна транзакция выполнила обновление данных, но не зафиксировала его, а другая транзакция начинает использовать эти данные. При отмене первой транзакции будет получен неправильный результат.

3. Проблема несогласованного анализа.

Данная проблема может возникнуть, когда одна транзакция получает доступ к множеству записей, некоторые из которых в это время обновляются другой транзакцией.

СУБД должна не только восстанавливать согласованное состояние базы данных после сбоев, но и обеспечивать корректную параллельную работу всех пользователей над одними и теми же данными. Идеальной является такая организация работы, когда действия одного пользователя не видны другим пользователям, а выполняемые одновременно транзакции изолированы друг от друга.

Для решения этой задачи обычно используется механизм блокировки - если объект базы данных (таблица, страница или отдельная запись) используется некоторой транзакцией, доступ к этому объекту со стороны других транзакций запрещается полностью или ограничивается (блокируется). После завершения транзакции все заблокированные ею объекты становятся доступными другим транзакциям для выполнения любых операций.

Возможны два вида блокировок:

1. Монопольная блокировка (X-блокировка, eXclusive locks).

В этом режиме объект базы данных, заблокированный некоторой транзакцией, может изменяться и удаляться только этой транзакцией, он недоступен для любых действий (включая чтение), выполняемых другими транзакциями.

2. Блокировка с взаимным доступом (S-блокировка, Shared locks).

Эта блокировка позволяет обращаться к объекту базы данных одновременно нескольким транзакциям, но только в режиме чтения (обновление и удаление информации запрещены).

Если транзакция обращается к объекту, к которому применена блокировка, она переходит в состояние ожидания момента снятия блокировки с этого объекта (исключением является ситуация, когда выполняемые транзакции предусматривают только чтение данных). Поэтому использование механизма блокировок приводит к задержке выполнения транзакций, следовательно, замедляет работу с базой данных.

Блокировки могут привести к возникновению тупиковых ситуаций. Предположим, первая транзакция в монопольном режиме блокирует объект А базы данных. Одновременно вторая транзакция в монопольном режиме блокирует объект В базы данных. Если затем первая транзакция пытается обратиться к объекту В, а вторая к объекту А, обе транзакции переходят в состояние бесконечного ожидания, так как они будут безрезультатно ждать прекращения выполнения другой транзакции и снятия блокировки с нужных им объектов.

Во время работы с базой данных может сложиться ситуация, когда при одновременном выполнении большого количества транзакций возникает множество тупиков. Эта ситуация разрешается непосредственно средствами СУБД. Из общей совокупности выполняемых транзакций выбираются и отменяются полностью или частично транзакции, которыми можно и нужно пожертвовать для устранения тупиков и продолжения работы других транзакций. Выбор транзакции для отката определяется многофакторным критерием, включающим приоритет и время выполнения транзакции, количество блокированных ею объектов.

1.5 Защита баз данных

Для успешной работы с базами данных, в особенности в многопользовательском режиме, любая СУБД должна включать средства защиты данных от несанкционированного доступа. При этом традиционно используются два подхода обеспечения безопасности данных - избирательный и обязательный.

В рамках избирательного подхода конкретный пользователь имеет разные права (полномочия) для работы с различными объектами базы данных (под объектами базы данных могут подразумеваться база данных полностью, отдельные таблицы, записи или значения данных). Полномочия отдельных пользователей при работе с одним и тем же объектом также могут быть различными. Поэтому избирательный подход достаточно гибок.

При обязательном подходе некоторый классификационный уровень присваивается самому объекту, а каждый пользователь имеет свой фиксированный уровень доступа. При обращении пользователя к объекту контролируется, соответствует ли уровень доступа пользователя классификационному уровню объекта. Обязательный подход применяется к базам данных, которые имеют жесткую или статичную структуру.

В конкретных СУБД могут поддерживаться или один из рассмотренных подходов обеспечения безопасности данных, или оба подхода.

Решения о полномочиях пользователей при доступе к объектам базы данных принимаются при разработке стратегии эксплуатации базы данных и не зависят от СУБД. СУБД только реализует принятые решения на практике. Для этого она должна иметь следующие средства:

1. Правила безопасности, сформулированные в процессе принятия решений о полномочиях пользователей. Эти правила обычно хранятся в словаре базы данных.

2. Механизмы контроля выполняемых действий, использующие имеющиеся правила безопасности.

3. Методы опознания и проверки подлинности пользователя.

Для опознания пользователя при его входе в систему СУБД обычно просит ввести идентификатор (например, фамилию, должность и т. д.) и пароль, известный только системе или сотрудникам с особыми полномочиями (например, администратору банка данных).

Несколько пользователей могут использовать одни и те же идентификатор и пароль. В результате создаются группы пользователей, обладающих одинаковыми правами доступа к данным. Состав группы может изменяться независимо от установленных для этой группы правил безопасности. Один пользователь может одновременно входить в несколько групп.

...