История развития баз данных: файлы и файловые системы, базы данных

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

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

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

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

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

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

•  определение данных;

•  определение представлений;

•  обработку данных (интерактивную и программную);

•  условия целостности;

•  идентификация прав доступа;

•  границы транзакций (начало, завершение и отмена).

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

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

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

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

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

11. Правило независимости  распространения. Реляционная СУБД  не должна зависеть от потребностей  конкретного пользователя.

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

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

В таблице 1 приведены сравнительные характеристики различных способов доступа к данным.

Таблица 1 Сравнительная характеристика способов обращения к данным

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

 

 

Преимущества и недостатки СУБД представлены в таблице 2.

Таблица 2 - Преимущества и недостатки СУБД

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

 

 

     Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети. РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

- каждый узел — это полноценная СУБД сама по себе;

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

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

     Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система. Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
11. Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.

 

 

 

 

 

 

 

 

 

 

 

 

 

2 РАСЧЕТ ПОВРЕМЕННОЙ ОПЛАТЫ

 

Задание.

1. Создать таблицы:

Таблица 1. Справочник работников

Структура таблицы: Табельный номер, Фамилия И. О., Разряд, Цех

Таблица 2. Справочник тарифов

Структура таблицы: Разряд, Тариф (руб./час.)

Таблица 3. Табель учета отработанного времени

Структура таблицы: Табельный номер, Отработанное время в часах, Номер месяца

Таблица 4. Ведомость начисления зарплаты

Структура таблицы: Месяц, Цех, Табельный номер. Фамилия И. О., Отработанное время, Тариф, Начислено (руб.)

2. Ввести в таблицу 1 сведения о 15-ти работниках из трех цехов, в таблицу 2 данные по пяти разрядам.
3. Создать форму «Табель» для ввода данных в таблицу 3, предусмотрев контроль вводимых данных (отработанное время) и выдачу сообщений при возникновении ошибок ввода. Для ввода табельного номера использовать поле со списком, содержащим табельные номера и фамилии, соответствующие таблице 1. Ввести данные о 15 рабочих за один месяц.
4. Создать запрос на добавление расчетных данных в четвертую таблицу за один месяц, номер которого должен вводится по запросу.
5. Создать форму (типа главная/подчиненная) только для просмотра сведений об одном работнике. Главная форма должна содержать: Табельный номер, Фамилия И. О., Разряд, Цех, Тариф. Подчиненная форма должна иметь  три графы  (номер месяца, отработанное время, начисленную сумму) и количество строк, соответствующее отработанным месяцам.
6. Создать отчет "Платежная ведомость по цеху  N … за месяц ..." с итогом по полю начислено. Цех и номер месяца должны вводиться по запросу. Платежная ведомость должна содержать графы: Номер по порядку, Табельный номер, Фамилия И.О., Сумма к выдаче, Подпись.
7. Создать отчет с итоговыми данными за два месяца, показывающий распределение сумм зарплаты в разрезе цехов по разрядам.

 

Решение.

1. Создание таблиц.

Создадим таблицы, исходя их условий задачи.

    В режиме «Конструктор» таблица «Справочник данных» имеет вид:

Рисунок 1 – Справочник данных

 

     В режиме  «Конструктор» таблица «Справочник  тарифов» имеет вид: